Closed katiealoisi closed 4 years ago
Either on the Test Queue or patient check in one thing we need to think through is how to add/edit data if something has changed. It could be that the edit just takes you to the patient profile and all editing happens there, or some other solution.
Things that might need to change per test off the top of my head are: -Symptoms -Pregnancy Status -address -phone number
Trying to track this more strategically here: https://airtable.com/invite/l?inviteId=invRZoEMgd5O1ppty&inviteToken=4eba912ce77015c2062681c5c8f36b6951750981b49124a130a46a20fe3ac5aa
Are you talking about adding/editing test result data or the patient data? If it's the patient data, they could hit the patient name which is linked to the patient profile. They could then edit the data from there. Do you think that will suffice?
For the Airtable, does this include all of the required data fields that Alex sent over?
Not sure where the team landed on having our app be the system of record in terms of supporting edits to information. Long run, I think it's probably unavoidable given the list of items that Alicia mentioned, but maybe in the short run we can add all these fields in the CSV, and if its wrong, update the CSV and re-upload? This creates other complications around de-duping
If we do store information, or have to build edit flows, this would take longer to develop. Just FYI.
Yeah, the app needs to be the system of record. However, I think we can maybe get away with a thinner solution for the MVP so we can at least test it with a few folks. Being able to add patients one by one and edit their data is going to be the fast follow on to the MVP- we can't realistically roll this out to many test sites without that in it.
@katiealoisi and Heather- I updated the airtable to show which fields I think should be in the MVP here: https://airtable.com/tblcBkHsdhAo0gbpT/viwAlMe3FeswxAMgz?blocks=hide
I'm wondering if "system of record" is being tossed around a bit casually when what we really just mean is "we need to be able to modify records inside our app" - then every piece of data, every change, every addition, should be synchronized with a SOR.
IMO we should fight tooth and nail to avoid trying to build a SOR or have people treat something we build as a SOR (to the point where any potential partner that doesn't already have one isn't a good potential partner). Building a SOR for health records is orders of magnitude different from building an application that handles transitory data.
Let’s definitely talk about this in more detail.
Overall, I see the point of this project as building an SOR for these records, precisely because so many places doing testing do not have one. A k-12 school will not have one, just like a nursing home will not have one for their staff. I believe this is exactly the user pain point this system is designed to solve. If we’re not on the same page about this we need to talk about it ASAP, because it’s an underlying assumption for everything else.
From: Peter Waterman notifications@github.com Reply-To: CDCgov/prime-central reply@reply.github.com Date: Thursday, October 15, 2020 at 10:07 AM To: CDCgov/prime-central prime-central@noreply.github.com Cc: "Beckett, Alicia (CMS/OA)" Alicia.Beckett@cms.hhs.gov, Assign assign@noreply.github.com Subject: Re: [CDCgov/prime-central] Clarity on MVP elements that are relatively solid vs. likely to change vs. not even in scope for MVP (#43)
I'm wondering if "system of record" is being tossed around a bit casually when what we really just mean is "we need to be able to modify records inside our app" - then every piece of data, every change, every addition, should be synchronized with a SOR.
IMO we should fight tooth and nail to avoid trying to build a SOR or have people treat something we build as a SOR (to the point where any potential partner that doesn't already have one isn't a good potential partner). Building a SOR for health records is orders of magnitude different from building an application that handles transitory data.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://protect2.fireeye.com/v1/url?k=b0eae55f-ecbecc74-b0ead460-0cc47a6d17cc-15ae228783abbb6d&q=1&e=b0566e0a-01b0-4cec-8947-a416c16b743a&u=https%3A%2F%2Fgithub.com%2FCDCgov%2Fprime-central%2Fissues%2F43%23issuecomment-709347928, or unsubscribehttps://protect2.fireeye.com/v1/url?k=9654d269-ca00fb42-9654e356-0cc47a6d17cc-650678216888f679&q=1&e=b0566e0a-01b0-4cec-8947-a416c16b743a&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMCKUGDMFRMLGPZV6DWEFETSK36N7ANCNFSM4SJEIU2Q.
I'm rusty on this space, but as I recall any K-12 that receives funds from Ed should have a FERPA/PPRA compliant Student Information System (SIS) as their system of record for student information. I don't believe it's possible for a K-12 school of any size to operate without an SIS. Same for higher ed.
On nursing homes, I don't have any personal experience in this area - but a nursing home without some sort of Employee Management System (EMS) would seem a bit unusual to me. How are they doing payroll and paying taxes if they don't have a system of record with their staff? And how are they keeping track of patients and residents without a CRM?
Ideally we plug into those systems, and provide a framework for routing test data in them.
Background: I have a lot of design to-do's I have not yet worked through but don't want to slow down engineering unnecessarily! Neil said it would be helpful to have clarity on which parts of the designs are:
I don't think I have all the answers but this is my attempt at answering these questions:
Bulk upload + Add new patient: I think the concept of the bulk upload + the ability to add a new patient as a one-off isn't likely to drastically change in the short term. However, the specific fields we collect in "add new patient" may change.
Test queue: Same goes for the queue where an administrator can record the result. The only thing I want to add to the design is the ability to clear a result (per your suggestion). Other than that, unlikely to change drastically in the short term until we talk to users to get feedback.
Test history: I would hold on the Test History screen for a while. We need to design a Review and Submit screen which may be part of this screen or may have implications for how this screen is designed.
Outstanding to-do's for design:
**Non-MVP requirements (this is IMO but would like others to add):***