Stream: patient empowerment
Topic: Honest question: what's the problem?
Dave deBronkart (Dec 08 2020 at 14:59):
I'm going to step out of the leviathan Sequence diagram thread and ask a completely naive and innocent question, so don't yell at me, and please answer in relatively high-level terms, because I'm going to have some explaining to do to patient voices in the outside world.
What it SEEMS LIKE I hear (note "seems like", not "is") is "No matter which approach you try, it's too damn hard for some of us figure out how to let a patient say 'Hey, you screwed up, fix this'. There are too many complications."
If so, it would be a grotesque indictment of the whole health IT industry (in the eyes of "my people"), which (it would seem) is so wrapped up in how it does things to be able to do what the sick person needs.
Can we not come up with constraints that make it feasible? I mean, come on, we NEED some way for a patient to get important errors corrected! As we achieve interop, we better not be broadcasting errors!
So although it might make some people hate me or insult my ignorance, I'm going to step back and remind everyone of this post from 18 months ago, around the founding of the Patient Empowerment WG:
HL7 makes it official: #FHIR exists to serve patient needs.
How can we get this done, smart people?
Dave deBronkart (Dec 08 2020 at 15:00):
I will be offline in meetings most of the day so I apologize for exiting as I ask this fairly rude question. I hope it leads to something productive.
John Moehrke (Dec 08 2020 at 15:00):
don't despair. you are just watching the sausage get created... I know you have long history with this, surely postscript went thru similar
Abbie Watson (Dec 08 2020 at 15:01):
We're making really good progress Dave. The Sequence Diagram thread is uncovering a bunch of hidden assumptions, but everybody is working toward the same goal. It's just how the sausage get mades. Stay the course. Have confidence.
Dave deBronkart (Dec 08 2020 at 15:02):
John Moehrke said:
don't despair. you are just watching the sausage get created... I know you have long history with this, surely postscript went thru similar
Good point, but PostScript was "standard by fiat": It was Adobe's creation, violating EVERYTHING the industry valued. :smile: The standard I was involved with was PPML 15 years later.
Lloyd McKenzie (Dec 08 2020 at 15:35):
I think the short answer is that it's going to be messier than we might like. We'll be able to take some steps to make it easier and it'll cover some of the scenarios. But it's possible, at least in the near term, that some types of corrections will still involve making phone calls/writing letters. (In fact, it's likely - because in the near term even if we come up with an agreed solution that covers all the use-cases and everyone agrees to implement, it won't get rolled out everywhere/turned on everywhere.)
Lloyd McKenzie (Dec 08 2020 at 15:36):
But "making things better than they are now" is definitely doable. What we're figuring out now is how far we can reasonably get and how.
John Moehrke (Dec 08 2020 at 16:11):
My preference at this point is that we (a) have well defined "need" defined as written from the Patient perspective, and (b) use the FHIR Connectathon as a hackathon where many people bring THEIR solutions. These solutions do not need to be pre-coordinated more than that they satisfy (a). Thus we can see many alternatives, discuss them, and therefore have informed decisions. Trying to get to a pre-coordinated solution based purely on theory seems to not be working for us in this use-case.
Debi Willis (Dec 08 2020 at 16:36):
I think this got more complicated that it needs to be. Months ago, we started talking about how to provide a way for a patient to communicate (via FHIR) their request to have someone at a organization review and correct an error. We studied laws to get insight on what needed to be communicated by the patient and the responses that were needed by the organization. We also studied Morgan Gleason's nicely written request for corrections (which followed all the legal requirements). We requested feedback from others on the best FHIR resource to use and received recommendations. In September, we presented the information to the FHIR-I workgroup and the Task Resource was the ultimate recommendation. We had a follow-up call and invited others to confirm the direction. It was confirmed that we should test the Task Resource to enable this workflow.
We created a connectathon track proposal with that single view...testing Task as the resource. The track proposal was approved. This is directly from the track proposal: "The purpose of this Connectathon is to task a draft Implementation Guide that uses the Task Resource to see if this is the best resource to accomplish our goal."
I believe we need to follow the recommendations from the FHIR-I meeting (plus confirmation in other meetings) and stay with the approved track proposal as the goal. If others want to join the track and also want to test directly writing to the EHR, we do not intend to stop that...but again, that is not the purpose chosen for this track.
The connectathon is to test the theory...will Task work for this process or not. There are many pieces to this puzzle that need to be worked out. That is part of what the connectathon is for. A patient's request for a correction (delete this, add this, modify this, etc.) is NOT the end of the story. There needs to be a response (within a designated time period) from the organization. They need to basically say "your request is accepted and corrected", "We need more time because......", "your request is denied because.....". The patient can also submit a statement of disagreement if their request is denied. As you can see, a patient directly writing their desired data will not give us the full scope. I am really very happy that a patient can potential write data to the EHR. But, that probably would be a better fit for a "Patient Contributed Data" track in the future (which is another of the Patient Empowerment projects).
For those who do not understand why Task was chosen, please review the laws to understand the multiple steps we are trying to provide via FHIR:
HIPAA: https://www.law.cornell.edu/cfr/text/45/164.526
GDPR: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN#d1e2589-1-1
Abbie Watson (Dec 08 2020 at 17:23):
We understand the laws. And the Morgan Gleason example. More than you're giving people and companies credit for.
The connectathon track proposal also included use cases around correcting smoking status, which can theoretically be done in nearly 45% to 50% of EHRs in production in the US using currently published APIs.
And as track lead, I think it sets us up for failure and getting egg on our face by only focusing only on Task. Especially if/when EHR vendors don't show up to the table, because we've come up with a pie-in-the-sky approach that they don't support and goes against what they've already spent years and millions of dollars developing. Drew is a perfect example. Epic was telling us the same thing.
So. The reference server I'll be bringing to the connectathon will be testing both Task and the PUT API endpoints. As per the defined use case. And per the feedback that EHR companies have been consistently giving us.
However, I've got to say that I'm absolutely tired of being asked by the HL7 community to develop people's pet projects for free. AMA was the last group to pull this, with Gravity. If you want a Task-only connectathon where I provide a reference server, pay me as a consultant.
Otherwise, if I'm going to do this work as a volunteer, and am asked to be track lead, then the work I'll be doing will include testing the PUT endpoints, so that we can get something of value out of the connectathon. Because Task has close to no real-world value, since no EHRs support it. I'm glad your business is resourced enough to be able to treat this connectathon as a private R&D lab where you can rally everybody to test a single thesis because you can wait 6 or 12 months until it gets implemented and rolled out by the EHRs. But others of us aren't as resourced, and find that to be a giant waste of our time. Other participants are looking to actually use the results of this connectathon to bring systems into production; not as an academic exercise. Please be respectful of our time.
Honestly, I'd be embarrassed to have my name associated with a Task-only track where no EHR vendors showed up to participate. And I'm going to do everything I can to avoid getting egg on our face in that regard, and to make sure that we're meeting the EHR vendors half-way and they show up to the table to participate.
Lloyd McKenzie (Dec 08 2020 at 18:30):
Task is the best fit for the workflow as the use-case has been described. The challenge is that the existing systems don't seem to support the use-case as described (communicating from one human to another who will review the request, will need to understand the rationale, is under legal obligations to provide interim responses in certain timelines, etc.) It's not clear that there's agreement from the EHR vendors that those are in fact base requirements - so I think we should put aside the notion of Task vs. PUT vs. whatever and have some focused discussions around the base requirements of what must be accomplished in terms of data elements shared and what the workflow of the clinician or administrator on the other end will be. Trying to nail down the technical solution before we've got buy-off on the notion of "reason for change must be shared" or "solution must accept requests for change related to data not exposed through the API" isn't going to get us very far.
If the short term connectathon just focuses on helping patient apps better understand how to submit synchronous updates through the FHIR API, that's ok. There's no harm there, it's just not likely to cover a very large percentage of the space that I think the IG is setting out to cover.
Brendan Keeler (Dec 09 2020 at 06:30):
I'm just curious if EHR vendors and other servers are going to be comfortable with open PATCH/PUT (where any consumer facing app can do writes more directly without reconciliation) if ONC Cures style access (no app approval process, just patient authorization) is extended to this aspect of patient engagement.
If that's not the case, it seems like testing PUT/PATCH is ill-advised
Brendan Keeler (Dec 09 2020 at 06:31):
I personally prefer simple PUT, as the whole Task concept (both here and also with orders/results) seems to add complexity and don't seem well supported, although I increasingly understand the arguments for it
Dave deBronkart (Dec 09 2020 at 11:39):
FWIW, @Debi Willis reminded me yesterday that our WG didn't come up with Task on our own - it was recommended to us, somewhat to our surprise, during the last WGM when we were "guests" in another group's session. We could dig out the recordings or notes or something if it matters.
Debi Willis (Dec 09 2020 at 13:51):
@Dave deBronkart Yes, this was a discussion that happened over many months and meetings with several groups. We requested feedback and the consensus was to test Task to determine if this resource would best fit this need. This recommendation came from a variety of people and groups which included EHR vendors, seasoned HL7 experts, and consumer app builders.
Task is being tested for other purposes also. It may be true that Task is not currently supported in some EHRs, but it appears it will become more used in the future. If we wait until something is used before we start testing it, then nothing will progress forward.
Our connectathon proposal was very clear in its purpose. Our use cases are also very clear. They do not contain testing PUT/PATCH. They are solely focused on the recommendation from months of meetings in collaboration with others: "Test Task to see if it might be a good resource to allow a patient to communicate their request to have data corrected/supply the needed information concerning the error and what they would like done/and have others notified of the corrections, allow the organization to respond to that request with more information, allow the patient to disagree if a request is denied, and allow the patient to be able to know the progress/status of that request." The collaborative meetings decided that Task seems like a reasonable resource to test for this purpose.
Virginia and I are co-leads of this connectathon. Abby was added as a co-lead to help accomplish the goal of the track (test Task for the purpose listed above). It appears the goal of this January connectathon has been muddied. I want to bring us back to the decision and goal we made in collaboration with others in the past few months. We are going to test Task. It may be the right resource or we may find it is not the right resource. Only collaboration and testing will give us that answer. Making a decision now that it will not work is a bit premature.
I am hoping those who are interested in discovering a way to use FHIR to progress this very important mission will join us. Hundreds of thousands of people die every year because of medical errors. Many of those errors are attributed to incorrect or missing data. We can make a huge impact in the lives of patients by moving forward together. I am not saying that others cannot test PUT/PATCH. I am saying that is not the collaborative decision that was made months ago for this January track. It was not the track proposal that was accepted by HL7. Future tracks for this vision might include PUT/PATCH. But, we are not going to muddy this important goal of testing Task for this January connectathon.
Cooper Thompson (Dec 09 2020 at 14:13):
@Brendan Keeler Just because the API looks like an open PATCH/PUT, doesn't mean that we process it as a direct write to the chart. Many of our existing "write" FHIR APIs already file to a holding tank that requires provider review before making it into the chart. For this project, we could direct PATCH/PUT content with a specific extension to a Chart Correction review queue. I'm not saying that is our recommended approach, just that it is something that is possible with open PATCH/PUT.
Brendan Keeler (Dec 09 2020 at 14:30):
Yeah of course but that would be different than the track as Abigail's diagrams show it
Debi Willis (Dec 09 2020 at 14:59):
@Brendan Keeler Yes, that was where things got off track. We are going to update everything to bring it back to the decision that was made earlier and make sure it matches the track proposal as posted on Confluence: https://confluence.hl7.org/display/FHIR/2021-01+Patient+Empowerment%3A+Patient+Request+for+Corrections+to+their+Record
Debi Willis (Dec 09 2020 at 15:00):
Here is the link to the use cases that we are going to be testing: https://build.fhir.org/ig/HL7/fhir-patient-correction/
Abbie Watson (Dec 09 2020 at 20:12):
I'm happy to update the specifics of how that PATCH/PUT flow occurs and what it looks like. I'm just trying to document the conversations that I've been party to, wherein both Epic and Cerner have expressed interest/preference for API driven correction flows. The latest version of the TestScript has separated the flow out into two scenarios: one without structured data (HIPAA business flow; replaces paper flows) and one with structured data (ie. patient portals, PHR, etc).
Abbie Watson (Dec 09 2020 at 20:14):
But what I am sort of insisting on, is that if EHR vendors are saying that there are writable endpoints that are available for this use case, then we also investigate those and include them in the track, and don't simply spend the connectathon building out a hypothetical resource which nobody currently supports.
Abbie Watson (Dec 09 2020 at 20:17):
Here's the latest sequence diagram for Scenario 1 - Patient Corrections with No Structured Data. It's the simplified Task-only workflow, which I think some people will be happy to see.
Patient-Corrections-Smoking-Status-HIPAA-Workflow-No-Structured-Data-paper-only.png
Virginia Lorenzi (Dec 10 2020 at 06:57):
The problem we are trying to solve: My understanding of the problem we are trying to solve is that with the current FHIR IGs available, there is no way for a patient to request an amendment be made to their clinical record through the FHIR API. If they have an issue with their record, they need to fill out a correction form and will probably also call the medical records department. With the new infoblocking rule going in effect there will be much more data released to apps and most will be unstructured (notes) so there will be more to complain about. And complaint might be a better way of describing this - a patient's request for correction is a patient complaining to the provider - hey provider I don't think this is right I need you to take a look and fix. Ask E-Patient-Dave – he has a collection of stories from angry patients. This is a critical workflow in hospitals from a legal perspective as well as a patient recovery of service perspective. Once the request is received by whoever has the important responsibility of reviewing patient’s error complaints (using medical records departments or privacy department) and ensuring that the error is thoroughly investigated, that the closed charts are opened and reviewed, that the right person to fix the problem is identified. An error might mean a patient identification error such as documenting on the wrong chart, perhaps misinformation has been sent and used on multiple patients, maybe a merge will need to occur. Even if it seems simple all requests for corrections to clinical data must be manually reviewed, it must be responded to in a limited timeframe, patients must have ability to disagree and to ask for others to be notified. The clinician who created the data might not be available – another clinician may need to assume the review responsibility. Each error needs to be examined to determined if its an error and why the error occurred. And HIM has to make sure the patient's complaint is resolved in a timely manner, amend all the charts impacted (it could be a wrong chart or wrong encounter error that this uncovers, merges may be required, downstream recipients may need to be contacted). The patient needs an opportunity to disagree. Changing this workflow especially in a hospital would be a huge change. However, automating their inbound queue of requests from users of apps and providing an electronic way to communicate status of the request to the apps would provide a service both to the patient using the app and to the medical records personnel and clinicians. Much better to complain to your app at 1am on Sunday than having to make a phone call on Monday during business hours or worse printing and mailing a form waiting for a response by mail. I work in a large US hospital network and have interviewed our Medical Records folk and also some from a few other hospitals in my research on this project. We spent time studying several examples, the HIPAA workflows in detail, and GDPR rule. I have interviewed numerous folk about the process at the hospitals and they have many war stories of resolving the errors reported and making sure that in the end and most importantly, the patient is happy because when they complain they are not. Other than demographics, corrections need to be manually reviewed. When I suggested a patient might be able to update clinical data in their chart they got quite upset. And this is not usually a paper process. The HIT systems (usually the EHR) provide workflow where tasks are assigned to individuals who review and then routed to the right clinicians. Its not a simple update – it’s a legal amendment. The patient is then responded to so it is a closed loop. HIPAA is in place in the US to guarantee a patient has this right. NYS has tough laws in this regard as well. And GDPR has it. WHO has said the right for a patient to ask for the medical record to be corrected is important.
Here are some request forms out there - you can see how they inspired our design:
https://www.hhs.gov/sites/default/files/ihs917.pdf
https://www.memorialhermann.org/uploadedFiles/_Library/Memorial_Hermann/patient-amendment-request-form.pdf
https://www.premierhealth.com/docs/default-source/default-document-library/amendment-request-form.pdf?sfvrsn=728d9b8b_2
https://www.partners.org/Assets/Documents/For-Patients/Medical-Records/Medical-Record-Amendement-Instructions.pdf
https://www.hipaa.cumc.columbia.edu/file/1378/download?token=gKud-5h1
With the Promoting Interoperability related regulations, many vendors implemented rhe Argonaut DSTU Data Query Guide in the US. As a result patients are able to see their data on the app of their choice in the US. However, if the data is wrong, their only recourse is the correction forms and the calls. And now with the new US CORE R4 going live in many places and doctors and hospitals implementing notes and narrative result reports going out the APIs, the need for a patient to have a way to complain that their data looks erroneous and requesting correction – right from their API, is escalating. There might be a deluge of requests to correct records. So there is a need more than ever for apps to be able to electronically communicate with HIM (HIM=Health Information Management or Medical Records Dept) and tap into that important correction/amendment workflow that occurs when the clinicians are no longer focused on that patient. And an electronic way to track their request to completion and have that interactive conversation with HIM and the clinician as they work to resolve all the issues.
We needed a way to let the patient actually communicate their concern via their app whether structured or unstructured (with unstructured as the initial scope – we see unstructured as especially important so a patient can voice their concern in their own words) and a way to support the communication of the status, and all the steps in the HIPAA and GDPR process and the communication with the patient able why a rejection of their request occurs, and a chance to disagree. This is net new work for HL7 – we could not find anyone doing it. So we decided to create an IG that could support this new functionality. We have met weekly in project meetings and as a full group on a different weekday.
July 2020 - We created a PSS for this purpose – Patient Request for Correction which would follow the HIPAA workflow but also be open to workflow globally. We then carefully laid out our timeline to get the specification from idea to ballot by May 2021. This meant being ready for connectathon in January 2021. We understand that the purpose of connectathons is to test the specs and profiles with the goal of maturing the FHIR specifications and IGs. We need 2 connectathons prior to ballot open. So it was a short timeframe.
August and early Sept 2020 - We studied the use cases and examples and talked to patients and medical records people. On the technical side, we searched for what was the best way to represent that request process in FHIR. CommunicationRequest and ServiceRequest were considered and ruled out. We examined Task and were able to map fields from our use case to it and represent the workflow.
Fall WGM 2020 - we were already doing indepth mapping and creating our profile on Task.
October and November 2020: We continued to develop the use cases, profiles, sequence diagrams, and state machine. We began preparations for the connectathon. We planned a connectathon agreeing we would focus on testing our draft IG (which uses Task to represent the patient/HIM/clinician workflow) and with a focus on a simple unstructured narrative request (extra credit for more than that). We also got approval to create the IG based on the original PSS from FMG. I believe we have already made a lot of progress as a WG in the design and we are ready to start kicking the tires. I am hoping we can make it to ballot and have a new standard IG informing EHRs how to support this communication need.
Abbie pointed out that several EHR vendors now support the ability to update a FHIR resource – I agree with her that this is exciting new functionality. I also confirmed that this is documented and supported in the US Core IG. However, Abbie and several others have suggested that this update functionality could be used for patient correcton. If that was the case, we would not need this IG, because US Core (and other equivalents) support that. We would also not need a special Patient Corrections track. The US Core connectathon track is devoted to maturing that specification. IMO that testing would belong there.
But I have racked my brain on this and I do not see how PUTs to resources could support the Request for Correction we describe in our PSS and in our IG. @Drew Torres @Isaac Vetter
Virginia Lorenzi (Dec 10 2020 at 06:59):
That being said – I really like those US Core updates. They could be useful for many patient update use cases such as:
1) Patient demographics changes (although we need to carefully consider ramifications if there is wrong chart errors here).
2) Update of patient contributed data (update their advance directive perhaps).
3) Clinical reconciliation - at the start of the visit or admission a patient provides their version of current data. EHRs show the previously stored data side by side with the patient’s updated data and the clinician talks to the patient and decides what should be accepted into the record. Importantly this is something the clinician is paying attention to as a visit or admission is beginning. Usually focused on problems, medications, allergies, and immunizations.
None of these cases address the Patient Request for Correction Use Case. It is not the same as the request for correction is done outside the context of a visit or admission or conversation with a clinician. It is primarily for when the chart is no longer active. This is why the Patient Correction IG was created – to provide an electronic way to communicate and track a patient’s request to correct the medical record. And the purpose of our track, like all connectathon tracks is to develop and mature this new IG.
Also, people sometimes like to say “you are just trying to meet the regs” – I say the regs are there to defend us as patients and compliance is an ever present necessity. I also have heard, don’t repeat the paper process. I would argue this is not a paper process. But it isn’t fully automatic either, and the workflow that exists in hospitals for corrections has a purpose so I am worried that in the effort to make things fully automatic we could harm patients, hide safety errors, or lead someone to break the law. I have a hard time imagining a hospital would be comfortable with an automatic update to a clinician’s documentation of smoking status on a patient’s closed encounter – that has got to be out in the open and manually reviewed.
Lloyd McKenzie (Dec 10 2020 at 07:16):
I think there are two possibilities here:
- patients are given carte blanche to change whatever they like in their records with no human intervention; or
- this will be a human-mediated process where administrators and/or clinicians will need to respond to a request for change
I think the first scenario is very unlikely (and very unwise). Even the best intentioned of patients might not realize the ramifications of making certain changes. E.g. What's the difference in impact between 'deleting' an address vs. marking it as 'old'. So I think humans are going to have to be in the loop pretty much always. We can seek to make the process more automated, such that a change could be applied after review with a mere button-click by a reviewer, and have the requests for change automatically routed to the appropriate person so that, in many cases, there's only one human's time involved. But I don't think providers will ever be (or should ever be) comfortable with patients making changes without review.
However, I don't think all of the participants in this conversation have landed on the same conclusion. So this is the first thing we need to discuss further and land on.
If we make the assumption that human review will potentially be required for every single patient-initiated change request, then the focus of the standard needs to be "what is the information that needs to be present to allow routing to the appropriate human reviewer and to allow the human reviewer to evaluate the request and decide how to act on it?" The objective is to try to get as large a percentage of the requests to be "one touch" decisions as we can, while working within the reasonable capabilities of both patient apps and EHRs. This the second set of requirements we need to get consensus on.
Once those key decisions are landed, we can have more productive discussions about technologies.
Virginia Lorenzi (Dec 10 2020 at 07:49):
Not quite - there may be something a patient can change without human review. Here is an example - their address. But other than that most other stuff requires human review in the US today as far as I understand.
And then there is clinical reconciliation in which you could do a compare between a few structured data types that are new and what existed before. But that is a limited special workflow in the context of a current encounter, its not correcting a closed record outside of an encounter.
Virginia Lorenzi (Dec 10 2020 at 08:05):
Cooper Thompson said:
Brendan Keeler Just because the API looks like an open PATCH/PUT, doesn't mean that we process it as a direct write to the chart. Many of our existing "write" FHIR APIs already file to a holding tank that requires provider review before making it into the chart. For this project, we could direct PATCH/PUT content with a specific extension to a Chart Correction review queue. I'm not saying that is our recommended approach, just that it is something that is possible with open PATCH/PUT.
I thought about this all Monday night. I just think you will get stuck. You wouldn't have the benefits of being able to tell patient status of the request via a polling request to task - manual review might take awhile, or that the request was rejected and why, and patient would not have way to disagree. Also if a patient says something is wrong, they probably have some narrative to go along with that. Put if you nestled it inside Task you could have all that :)
Virginia Lorenzi (Dec 10 2020 at 08:07):
Brendan Keeler said:
I'm just curious if EHR vendors and other servers are going to be comfortable with open PATCH/PUT (where any consumer facing app can do writes more directly without reconciliation) if ONC Cures style access (no app approval process, just patient authorization) is extended to this aspect of patient engagement.
If that's not the case, it seems like testing PUT/PATCH is ill-advised
I would add to your question - will the healthcare providers be comfortable?
Lloyd McKenzie (Dec 10 2020 at 08:07):
Even for address - is the change because the old one was wrong (in which case no need to retain) or because they've moved (in which case it should be retained as an old address for search) or because they're temporarily staying somewhere else (in which case a new temporary address should be added). You can't presume patients will get that right.
Virginia Lorenzi (Dec 10 2020 at 08:10):
My feference to demographics changes is based on numerous conversations with medical records people and functionality I have seen. What I hear is oh demograhics thats fine. But I do wonder, especially since a correction request can really be uncovering the tip of the iceberg of a serious error. Like identity errors.
Debi Willis (Dec 10 2020 at 10:48):
@Lloyd McKenzie, for this IG, we are making the assumption that human review will potentially be required for change request. We have documented "what is the information that needs to be present to allow routing to the appropriate human reviewer and to allow the human reviewer to evaluate the request and decide how to act on it?" A patient facing app can guide the patient on what elements should be included in their initial request to try to get all information to enable (as much as possible) a "one touch" decision.
We are now at this point:
1) "Where do we place these bits of information within the Task resource?" and
2) "How do we link this potentially multi-phase conversation together to make sure the pieces don't get lost or confused with another change request from the same patient?"
This is what we plan to focus on in our session today at 1 PM ET. For anyone who would like to join this conversation to discuss the two items above, here is the meeting invite:
Please join my meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/322275573
You can also dial in using your phone.
United States: +1 (872) 240-3212
Access Code: 322-275-573
John Moehrke (Dec 10 2020 at 13:31):
I would focus on what the interface between the patient domain and the medical records domain need to be.I think it is not necessary, and highly distracting, to try to model the processes that will happen inside the medical records domain. We should leave that domain as a black-box. We know what must go in, we know what we would want to know about the progression, and we know what the success and failure output we want to happen. How it happens could be by magic, it could be by use of a FHIR task, it could be by an HL7 v2 process, it could be by monkeys turning cranks. I would expect that these monkeys could trigger all kinds of processes, all kinds of clinical re-decisions, possibly legal actions, etc... What happens inside the box does not matter. What matters is well defined interface behaviors between the patient domain and the medical records domain.
Brendan Keeler (Dec 10 2020 at 14:13):
Direct Messaging did a good job of staying out of the medical records domain and just touching the interface domain. Look how that turned out.
If not a requirement, a recommendation on behavior is smart in that it drives adoption of a standard behavior that can be counted on by developers and their patient app users.
Debi Willis (Dec 10 2020 at 14:24):
For those who have not been able to attend our meetings on this topic (which began mid summer), here is a document outlining what we are trying to accomplish with our IG. To reiterate what Virginia noted in an earlier chat: "This is not a simple update - it's a legal amendment." Another important comment from her: "This is net new work for HL7." Because of the newness of this work and the important impact it will have on patients and entities, and the potential to save lives by providing a better flow for the patient's request for correction, I want to clarify again what we are doing.
Once you take a look at what we are trying to accomplish in this document, I think it will become clear and you will see the great value it brings.
image.png
If you want to download the document, you can click on the link below.
What-we-are-trying-to-accomplish.docx
Dave deBronkart (Dec 10 2020 at 14:32):
Debi Willis said:
To reiterate what Virginia noted in an earlier chat: "This is not a simple update - it's a legal amendment."
To be clear, "this" refers to the correction that needs to be done. I believe Virginia's point is that this isn't just a casual chatty "by the way, could you fix this?" The transaction accomplishes a legally required amendment to the chart, which itself is a document that providers are required to amend when it's wrong.
Our IG project is to define the infrastructure to enable that communication.
@Debi Willis @Virginia Lorenzi please correct me if I have any detail of this wrong so I can edit it.
Debi Willis (Dec 10 2020 at 14:35):
You are spot on.
Lloyd McKenzie (Dec 10 2020 at 14:36):
@Debi Willis I understand that the group who's been doing the design work feels they have consensus on my questions. Do the EHR vendors share in that consensus? My impression is that that's the gap right now. (Though my impression could be wrong...)
Josh Mandel (Dec 10 2020 at 14:49):
This thread is too long and involved for your mention of "consensus on my questions" to be easily understandable @Lloyd McKenzie. I just caught up on the last day's worth of messages but don't know what this is referring to. Can you add a reference?
Lloyd McKenzie (Dec 10 2020 at 14:54):
@Josh Mandel
Lloyd McKenzie said:
I think there are two possibilities here:
- patients are given carte blanche to change whatever they like in their records with no human intervention; or
- this will be a human-mediated process where administrators and/or clinicians will need to respond to a request for change
I think the first scenario is very unlikely (and very unwise). Even the best intentioned of patients might not realize the ramifications of making certain changes. E.g. What's the difference in impact between 'deleting' an address vs. marking it as 'old'. So I think humans are going to have to be in the loop pretty much always. We can seek to make the process more automated, such that a change could be applied after review with a mere button-click by a reviewer, and have the requests for change automatically routed to the appropriate person so that, in many cases, there's only one human's time involved. But I don't think providers will ever be (or should ever be) comfortable with patients making changes without review.
However, I don't think all of the participants in this conversation have landed on the same conclusion. So this is the first thing we need to discuss further and land on.
If we make the assumption that human review will potentially be required for every single patient-initiated change request, then the focus of the standard needs to be "what is the information that needs to be present to allow routing to the appropriate human reviewer and to allow the human reviewer to evaluate the request and decide how to act on it?" The objective is to try to get as large a percentage of the requests to be "one touch" decisions as we can, while working within the reasonable capabilities of both patient apps and EHRs. This the second set of requirements we need to get consensus on.
Once those key decisions are landed, we can have more productive discussions about technologies.
Debi Willis (Dec 10 2020 at 16:42):
When we presented this to the FHIR-I group in the September WGM and to numerous other groups (which included EHR vendors and also app developers), there was a consensus to test Task to see if it would accommodate the pieces necessary (by law) for a patient's request to change their record.
The suggestion of moving to a direct post instead of using Task was debated here. But, I really don't think the problem we are trying to solve was fully presented in the argument for a direct post. And there was no transparency that this was a collaborative decision by FHIR-I and many other people. The Patient Empowerment workgroup did not come up with this decision. We followed the consensus.
But, i think your question deserves an answer. Which of the two scenarios presented by Lloyd makes more sense for this purpose? (And please remember what we are trying to accomplish...check out the document i posted in this chat earlier today)
Debi Willis (Dec 10 2020 at 16:44):
Dave deBronkart (Dec 10 2020 at 17:25):
Lloyd McKenzie said:
Josh Mandel
Lloyd McKenzie said:I think there are two possibilities here:
- patients are given carte blanche to change whatever they like in their records with no human intervention; or
- this will be a human-mediated process where administrators and/or clinicians will need to respond to a request for change
... I don't think all of the participants in this conversation have landed on the same conclusion. So this is the first thing we need to discuss further and land on.
I'm all for patient empowerment, but that doesn't mean unlimited patient authority, particularly over the content of a legal document that is the responsibility of the provider. What I personally stand for is partnership (participatory medicine), not flipping a one-sided relationship to be one-sided in the other direction. Partnership. Working together.
Aside from that philosophical aspect, the simple fact remains that some people are just plain nuts or misinformed, and should not have carte blanche to change things in their providers' systems. Sad current example:
South Dakota nurse says many patients deny the coronavirus exists — right up until death
I do not want that person to have the ability to delete the diagnosis from their chart, period. Nor any similar one-sided edit. I want, and we are tasked with enabling, the patient to be able to say "There's a mistake in your record about me. You need to fix it."
Virginia Lorenzi (Dec 10 2020 at 17:31):
Yup @Cooper Thompson That is the complexity I am referring to - like the lock down - good point! Patient thinks I don't have HIV. Medical Records looks and its true they don't - they have charts intermingled. HIM professionals are amazing people. I see automatic processes today I never saw in the 90s. But I also see how long it took to automate them even with technical innovation and the weight of regulation and patient activism. So the goal of our spec is to get something that helps today.
Dave deBronkart (Dec 10 2020 at 17:33):
Meta-comment: the complexity (as @Josh Mandel noted earlier) of a thread like this makes me yearn for Slack's ability to have side threads that sprout off of a "channel"/stream.
We now return you to your regularly scheduled programming.
Virginia Lorenzi (Dec 10 2020 at 17:48):
Brendan Keeler said:
Direct Messaging did a good job of staying out of the medical records domain and just touching the interface domain. Look how that turned out.
If not a requirement, a recommendation on behavior is smart in that it drives adoption of a standard behavior that can be counted on by developers and their patient app users.
Brendan which post were you commenting on?
Virginia Lorenzi (Dec 10 2020 at 17:50):
Task - It was recommended even before the WGM and confirmed there.
Jenni Syed (Dec 10 2020 at 23:27):
I was in one of the WGM conversations, and raised concerns about Task and the recommendations (because we would likely use Communication if there needed to be "text data or unstructured data" as it existed today, and a structured put/update. I've actually brought this up before as well (ie: before I think this PSS and IG existed). But Drew is also representing this same claim
Jenni Syed (Dec 10 2020 at 23:28):
I think that conversation at the WGM, without Lloyd, made you all re-meet or re-confirm where the conversation went. I believe the Epic representative at that time may have been @Isaac Vetter instead of Cooper... but I know we went back and forth a lot :) My mind is foggy and I would need to pull up the notes :)
Jenni Syed (Dec 10 2020 at 23:29):
I just don't want to forget that we (EHR vendors) have raised concerns before... I hope this isn't new/surprise. I know this part of making the sausage can be "fun"
Jenni Syed (Dec 10 2020 at 23:30):
I agree with the idea that you shouldn't try to regulate (control/limit) the process that actually happens in a hospital, but agree that there may (usually?) be human intervention
Jenni Syed (Dec 10 2020 at 23:31):
There's a difference between allowing for a process to happen and requiring the detailed steps
Jenni Syed (Dec 10 2020 at 23:32):
Much like @Cooper Thompson mentioned, writes through our APIs today don't always go direct to the patient's legal record. They're sometimes in a staging area in review. Generally, provenance tracks the progression of this from "unreliable" to "legal record" (or rejected?).
Dave deBronkart (Dec 10 2020 at 23:32):
Jenni Syed said:
There's a difference between allowing for a process to happen and requiring the detailed steps
Wisdom!
Jenni Syed (Dec 10 2020 at 23:32):
So it's definitely possible to do this in a structured way...
Lloyd McKenzie (Dec 11 2020 at 00:13):
It's a good thing sausage tastes so good when it's cooked... :>
@Jenni Syed If an inbound API request goes to a staging area, then are you using the async process (HTTP 202) to say the response will come back later? (Because it'd be inappropriate to respond to a PUT with a 200 if you haven't actually made the requested change.) Also, how do you handle the need for context by the humans reviewing a proposed change about why it's being made? How do you handle other HIPAA obligations?
Cooper Thompson (Dec 11 2020 at 00:26):
@Lloyd McKenzie The FHIR API doesn't need to be aware of the difference between the staging area and the legal chart. As far as the API concerned, the request has been stored to the overall EHR system. Which specific table (legal chart vs. staging area) within the EHR is an internal implementation detail.
Lloyd McKenzie (Dec 11 2020 at 00:28):
If I submit an update to Patient and the EHR responds with a 200, then that means the requested change has been made. Any system that receives back a 200 is going to assume that all downstream systems will receive the new data when they subsequently query.
Lloyd McKenzie (Dec 11 2020 at 00:28):
If you're doing a 'staging' approach, then returning a 200 is misleading (and potentially dangerous) because a system will believe that others will see new data, when in fact, they might not.
Jenni Syed (Dec 11 2020 at 00:30):
@Drew Torres can speak more to this for us, but our data is marked in this case as not part of the legal record, and apps that have the ability to see those types of data will see those (and marked as not validated/reliable at this point)
Jenni Syed (Dec 11 2020 at 00:30):
Not all applications have privs (nor the desire) to see this type of data, they only have interest in seeing the legal record in the EHR
Jenni Syed (Dec 11 2020 at 00:31):
Once it's part of the legal record, all apps would see it.
Cooper Thompson (Dec 11 2020 at 00:31):
Assuming that a 200 means that all downstreams are being updated as a result of their API request is a very bad assumption to make, staging or no.
Cooper Thompson (Dec 11 2020 at 00:34):
Our FHIR APIs are public interfaces with our overall EHR system. Apps should make no assumptions (unless those are based on our implementation-specific documentation) about what specific tables or records are affected by their API calls.
Lloyd McKenzie (Dec 11 2020 at 00:35):
It's not an assumption that all downstream systems are updated, but is is an assumption that the 'server' that owns that particular record id has updated its copy and that all queries against that server will return the current version.
Lloyd McKenzie (Dec 11 2020 at 00:36):
If you have a separate server for staging from the server that is queried when retrieving patient data, then perhaps it's less of an issue. (Especially if the staging server is read-only)
Cooper Thompson (Dec 11 2020 at 00:36):
Ah - if you are talking about updates, I might agree (or at least be in closer alignment). However we have vary sparse support for update because of exactly this problem. Our "write" support is generally just create.
Lloyd McKenzie (Dec 11 2020 at 00:37):
Ok, but this whole set of streams are talking about "patient correction" which generally means 'update'... :)
Lloyd McKenzie (Dec 11 2020 at 00:37):
(or occasionally delete - which would have the same issue)
Cooper Thompson (Dec 11 2020 at 00:41):
Even in Update though, I still think the FHIR API is an interface with the overall EHR system. Not any specific table, record, or sub-component.
Lloyd McKenzie (Dec 11 2020 at 00:52):
FHIR doesn't care what things look like behind the API, but it does define the expectations for behavior when the API is used. If an update is successful, then the expectation is that (logically) a new history entry is created with a new _lastUpdated, a new 'version' and that that new version will be returned in subsequent queries. It's legitimate to say that some users won't be able to see a given resource, but there's no mechanism in FHIR that says that when a two users have access to the same record, they'll see different versions when it's queried. Similarly, if someone successfully deletes a record, the expectation is that anyone who queries that interface won't see the record in their search results any longer.
Lloyd McKenzie (Dec 11 2020 at 00:52):
How that behavior gets implemented behind the scenes is totally up to the system.
Dave deBronkart (Dec 11 2020 at 01:01):
Meta-comment: I want to note that the advent of patient-requested corrections is naturally pulling back a curtain to reveal a world that has previously been able to assume that anything behind that curtain is inherently right.
I don't have any opinion (don't know enough to) about individual vendors' systems, but it will be interesting to see whose systems tolerate this paradigm shift relatively well and which go into panic mode :smile:
To be clear, this is no indictment - in a sense the advent of external corrections is a new requirement, added years after initial design. I just hope it will be relatively easy.
Jenni Syed (Dec 11 2020 at 01:09):
It's legitimate to say that some users won't be able to see a given resource, but there's no mechanism in FHIR that says that when a two users have access to the same record, they'll see different versions when it's queried
this exists today because of user privledges. Just because you can see some of a record, you may not be able to see all. EG: patients may not see clinical process comments that a doctor has access to, a parent may not see comments or some elements of a resource if the record is for an adolescent child if that data may compromise things that are illegal to disclose. And translation or conversion requests mean that some extensions may be added (no modification to source data) for specific requests, but the resource id and version are the same. FHIR doesn't recognize this first class, but this behavior is implied by security restrictions and functionality built into the spec (even requesting a specific profile could transform the resulting resource)
Jenni Syed (Dec 11 2020 at 01:14):
Note that this was true in V2 and V3 as well, as most provider systems customize per system they integrate with - from codings returned to what is mapped in a specific field (not ideal... obviously, but it was/is reality)
Jenni Syed (Dec 11 2020 at 01:17):
All of that to reinforce that If you both see the same version of the same record, you may NOT see the same thing
Jenni Syed (Dec 11 2020 at 01:18):
The same is true if 2 different people look at "all conditions for Sam" - different privileges may result in different sets of data returning.
Lloyd McKenzie (Dec 11 2020 at 02:17):
I totally agree @Jenni Syed that two people won't necessarily see the same thing, but the differences will be ones of filtering - different people see the subset they're allowed to see, rather than differences in version where one person sees new content and one sees old content. You don't want a situation where a patient believes they've updated a medical condition in their record, but the surgeon who's performing their procedure the following week still sees the old content.
Abbie Watson (Dec 11 2020 at 17:57):
Virginia Lorenzi said:
But I have racked my brain on this and I do not see how PUTs to resources could support the Request for Correction we describe in our PSS and in our IG.
Let’s go back to basics, and remember that POST/PUT/PATCH aren’t mandated to respond with a single server code. Rather, they can return any number of HTTP response codes. For those who don’t build web interfaces on a day-to-day basis, here’s a reference of available codes:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
I just went through, and pulled the codes that could be relevant to the HIPAA correction workflow and could be kludged into a workable approach.
200 OK
201 Created
202 Accepted
204 No Content
205 Reset Content
304 Not Modified
403 Forbidden
406 Not Acceptable
407 Proxy Authentication Required
409 Conflict
412 Precondition Failed
424 Failed Dependency
428 Precondition Required
451 Unavailable for Legal Reasons
As you can see, they don’t map quite as well as the TaskStatus value set. But it’s robust enough that if you squint a bit, one can see how we get the Accept/Reject/Rebuttal workflow, and the entire process could be done with HTTP codes, headers, and payloads. Also, the POST/PUT/PATCH approach may require multiple API endpoints (I.e. Condition and DocumentReference) instead of doing everything on a single endpoint. That’s a mild headache, but relatively doable.
Is the approach as elegant as the Task approach? No way. Is it as easy to reason through? Not even remotely.
Is it currently available? Yes. Is it currently supported by vendors and available today? Yes. Is it scalable? Probably one of the most scalable approaches every imagined by human ingenuity - currently some 50 billion internet nodes currently using this approach.
Are we suggesting that we abandoned the Task approach? No. The Task API semantics and ease of use are a clear improvement. We definitely need to stay the course in that regard.
But this POST/PUT/PATCH approach... it’s supported by pretty much every piece of equipment attached to the internet. If we want to talk about interoperability and standardization, piggy-backing on raw HTTP codes is as robust a solution as one can imagine. Literally every network router and web server and browser on the internet already supports this. And EHR vendors have already implemented it and have it in production.
To spell out the flow in even more detail, here is a HIPAA correction interpretation of the HTTP response codes:
200 OK - Here is the current state of the HIPAA record.
201 Created - An entry was made to the HIPAA record.
202 Accepted - Your proposed correction was accepted.
204 No Content - We didn’t recognize the format of the change request you sent.
205 Reset Content - Please reset and send the change request again.
304 Not Modified - Your proposed correction was received, but the HIPAA record was not modified.
403 Forbidden - This type of data correction is not available under any circumstance.
406 Not Acceptable - Your proposed correction was not accepted.
407 Proxy Authentication Required - You are trying to correct a claim made by a third person (I.e a nurse or doctor); they need to sign off on this correction request.
409 Conflict - The date you are suggesting this occurred is before you were born. Unprocessable.
412 Precondition Failed - The evidence you provided is insufficient.
424 Failed Dependency - The evidence you cited was not available.
428 Precondition Required - We need additional evidence to approve this.
451 Unavailable for Legal Reasons - For legal reasons, we cannot make this HIPAA correction (I.e. mental health laws, incarceration laws, etc)
Is this perfect? Hardly. Is it kludgy and doable? Sure looks like it to many of us who are building web interfaces on a day-to-day basis. Kludgy and doable and available is how most of the internet was built. And politically speaking, within the vendor organizations, it may be an easier lift to expand the list of supported HTTP response codes on existing API endpoints than creating new API endpoints.
Lloyd McKenzie (Dec 11 2020 at 18:44):
Abigail,
Write access to most resources is NOT supported by most vendors and write access with async is not supported, to my knowledge, by ANY vendors. As well, this doesn't give us an ability to capture 'reason' for the change which is pretty critical given that the use-case is communication with a human. Simply posting a new smoking status observation to an EHR (which is the only thing that is supported right now) doesn't actually deal with our use-case of patient correction. (No EHR allows updating existing observations nor deleting wrong ones, that I'm aware of).
Jenni Syed (Dec 11 2020 at 19:53):
You don't want a situation where a patient believes they've updated a medical condition in their record, but the surgeon who's performing their procedure the following week still sees the old content.
You want the surgeon to see what is accepted to the legal record, and the patient to see that their request isn't accepted yet. I do not want clinical staff making clinical decisions on something that isn't reviewed. Your model has this same issue - but don't assume that because task isn't there, the requester can't see their proposals.
Let's flip this a bit, because patient proposals seem new (at least, trying to make them better than they are today). If a medical student modifies an order, but it needs review by another medical professional before being applied/not being draft... how would that work? Would we expect them to use a task (not something in most EHRs today)?
Lloyd McKenzie (Dec 11 2020 at 19:56):
Oh, I agree that you don't want something that isn't accepted in the medical record to be seen by anyone. However, if someone sends an update and the server response is a 200, that means that the update is made. What I'm saying is that we probably don't want that to be the response - meaning that if we're going to use regular REST for submitting updates (or creates or deletes) that are going to get kicked into a human review process, then we need to be using some other sort of response mechanism.
Lloyd McKenzie (Dec 11 2020 at 19:57):
And yes, if a medical student wants to modify an order, they'd have to create a proposal or a task or both. They couldn't submit an update on the order and get back a 200 and have the change not applied.
Lloyd McKenzie (Dec 11 2020 at 19:59):
You'd want there to be two separate records (with distinct ids). One reflecting the proposed order and one reflecting the current order. And there's no equivalent of that for non-requests (no 'proposed' intent)
Jenni Syed (Dec 11 2020 at 20:00):
If a medical student creates an order today, a server would likely say it's created, and the order itself would indicate state and reliability (eg: draft? proposal? Unreliable tag?) - which the server can choose to hold to its own business rules. I don't have to write 1:1 with what an app requests. IE: even if the app tried to write this as an order, the server will look at privs (because the app doesn't know the user privs) and move this over to a state that makes sense (or deny it if there is no way this is allowed in the system today)
Jenni Syed (Dec 11 2020 at 20:01):
FHIR has a way in many places to handle this workflow on create. It falls down on modify (the modify will change order id X to a new version... but this is proposed)
Jenni Syed (Dec 11 2020 at 20:01):
you want those 2 things to be hard to separate
Jenni Syed (Dec 11 2020 at 20:02):
(eg: having 2 totally separate records could suck too - onus is on the app to know to tie them together... it's a "modifier" resource to another resource??)
Jenni Syed (Dec 11 2020 at 20:03):
I will say that the goal should be to make the API easy to use and hard to misuse. It seems easy to misuse the complete separation of the proposed modify (both in med student world and patient world)
Abbie Watson (Dec 11 2020 at 20:04):
@Lloyd McKenzie Last year I would have agreed with you. Things are moving rapidly though, with FHIR growing exponentially. I just registered our patient-testing server with Cerner, and set it up with Patient write scopes on Condition and DocumentReference.
Screen-Shot-2020-12-11-at-1.38.03-PM.png
And here's the dilemma I have... I was around in 2016 and 2017 for DSTU2, and was told _then_ to go 'check the Argonaut spec' and this functionality will be available 'a few years down the road'. And here it is a few years later, and we're just now getting a modicum of write access on the resources that were in DSTU2.
So, when I hear we're doing a new resource from scratch, that tells me we're looking at a 2 to 5 year implementation cycle. And yes... best to plant the seeds and make those investments now, and in 2024 and 2025 we'll reap the benefits. It's a great strategy for EHR companies. But patient implementors rarely want to wait 'a few years down the road'.
Like... if we published an IG that only documented Task, there's no way I could hand that IG to folks who come to the Chicago FHIR Users Group from our local startup incubators. If we handed patient implementors an IG that no vendors have implemented, it would damage my reputation, the user group's reputation, and HL7's reputation.
Meanwhile, we are beginning to see write access available to these other resources. The patient implementors I've met at our local user's group and at DevDays... I think they'd rather see an IG on how to use existing writeable Condition and DocumentReference resources that they can use to solve problems today.
Jenni Syed (Dec 11 2020 at 20:05):
(I have to sneak in here and say that we've had writes since our May 2015 Ballot version of FHIR, pre-DSTU 2 being published :) )
Jenni Syed (Dec 11 2020 at 20:05):
(we definitely have a ton more coming out on R4, with many more complicated workflows)
Abbie Watson (Dec 11 2020 at 20:08):
Agreed! Although, to be perfectly honest... was never quite able to get it working. It was a little more arcane and less clear to use than people are making it out to be.
Abbie Watson (Dec 11 2020 at 20:14):
@Jenni Syed - Question for you - what is the relative political lift with regards to creating a new resource from scratch versus expanding the supported HTTP response codes and server interactions on an existing resource?
Based on my experience with Cerner, I suspect there's a host of internal considerations... test scripts, integration testing, internal queues that go along with it, internal budgeting, support teams, departmental organization, etc.
Jenni Syed (Dec 11 2020 at 20:17):
@Drew Torres can speak to this a lot more now that he is product over the API side :) But it really does depend. Adding a new field is usually easiest, adding a new action is next (because we typically have mappings already), and adding a new resource is typically tough
Jenni Syed (Dec 11 2020 at 20:17):
However, some resources are far easier than others. EG: Immunizations? Not bad, pretty well understood, pretty in line with how FHIR thinks of it
Jenni Syed (Dec 11 2020 at 20:18):
Observation? Crosses like 5+ functional domains and/or tables internally, doesn't quite match with how we think of all of those concepts, and the modify/create flows usually have a lot of biz logic
Jenni Syed (Dec 11 2020 at 20:18):
which depend on what FHIR may call "category" (but are really different things internally)
Jenni Syed (Dec 11 2020 at 20:20):
This is why Drew is saying that "Task" is a mess/hard - the more generalized the resource, especially when it doesn't align with something in the software stack already, the harder it may be. The worst is if we have to add new functionality to the core EMR, which is likely where task is. That's also pretty disruptive to the clinicians and systems. When we change FHIR, we're generally exposing existing functionality that they already have and it doesn't actually affect any of their core EMR code
Jenni Syed (Dec 11 2020 at 20:21):
Making them enter data or perform a new workflow they don't want... generally doesn't go well
Lloyd McKenzie (Dec 11 2020 at 20:21):
@Jenni Syed Creating a net new order is easy - it gets created as draft and the 'real' provider later changes the status to 'active'. However, if the question is how to change an order, things get messier. There's no ability to log a change to a record without the change being made. If you want to propose a change, you need to use Task (and describe the target state in a distinct, possibly contained, instance)
Jenni Syed (Dec 11 2020 at 20:23):
The other downside is when we have to change core EMR code in our system, it takes a long time to roll out/clients to take the change. Whereas if it's isolated to our cloud FHIR stack or the hosted services under that, it's usually available everywhere within a week of code complete
Jenni Syed (Dec 11 2020 at 20:23):
That delay is because of workflow impact to core EMR - clients are very careful (understandably) with things that may affect clinician workflows
Jenni Syed (Dec 11 2020 at 20:27):
And to be clear, while I care very much how hard something is to do, if it's the right thing to do, we'll do it. But from just an API design perspective, separating proposals completely into a different model in FHIR from the thing that needs to be modified (and modified in a structured way ideally) seems like a mistake
Jenni Syed (Dec 11 2020 at 20:28):
And in the case of the med student ( and some patient corrections), how does the app know what they're supposed to do? They don't know if the person signed in to the system is allowed to do something or not
Jenni Syed (Dec 11 2020 at 20:29):
They don't know what types of orders the med student can and can't directly place
Jenni Syed (Dec 11 2020 at 20:29):
and they don't know what types of modifications are good to do directly and not
Jenni Syed (Dec 11 2020 at 20:31):
There will be places this is likely true for patient as well, which has been touched on here. A patient probably can modify their address directly, or some contact info... or their name spelling. They may be able to remove "reported" meds that they're our source for w/o approval... etc
Lloyd McKenzie (Dec 11 2020 at 20:37):
I understand your concerns. But with REST, when you submit a PUT, if you get back a 200, that means the update is made. We could have a workflow where if you're allowed to make the change you get a 200 and if you're not, you get a 202, but that then puts us into the 'async polling' space a la Bulk Data. With bulk data, you're only querying over the course of minutes or maybe an hour or so at worst. With this, you could be polling for over a month. Is that really where we want to go?
Lloyd McKenzie (Dec 11 2020 at 20:38):
And there's still a challenge of query. There's no 'id' for this pending change. It doesn't exist from a resource history perspective. It can't come back in any history because it hasn't been applied yet.
Lloyd McKenzie (Dec 11 2020 at 20:42):
I think the "no permission" issue is going to be the same as other places where you have permission to make some changes and for other things, you need to go through another process. If you try to 'correct' the patient on a prescription, you'll get an error and get told "no, you must cancel this prescription or mark it in error and create a new one". The same principle would hold here "no, you're not allowed to change your birth date via this interface, instead do X". We could look to standardize the error codes to allow systems "in the know" to handle that automatically. And we could explore whether the new CapabilityStatement might even allow clients to proactively discern nuances of what clients can and can't do to make the likelihood of the "try A, fail, try B" approach less common. But I really do think there's going to have to be a "try B" approach when a proposal for change needs to be looked at asynchronously.
Lloyd McKenzie (Dec 11 2020 at 20:59):
@Abigail Watson Are you saying there are existing EHRs that allow requesting updates of an existing record by a patient that trigger an asynchronous process? (EHRs should definitely not be allowing real-time updates to conditions or document references or most things by patients...)
Abbie Watson (Dec 11 2020 at 21:31):
Mmmm.... would need to ask the EHRs vendors if any of these endpoints supporting HTTP/2 for the async question. Might be there on the backend and none of us know about it. (Personally, I would be a little surprised.) But I think it's entirely worth asking the question and surveying the state of ecosystem, and it should be within the scope of the connectathon. It might be an easier lift for an infrastructure team with budget than spinning up a new product management group.
The answer is: I don't know. But I think we should be asking that question.
Lloyd McKenzie (Dec 11 2020 at 21:35):
The thing is that while the submitting the same request and returning either a 200 or a 202 gives the appearance of a very similar front end, the back end has to be completely different. And it doesn't really meet the need we have. So, if it's not already supported and it won't really do what's needed even if it is supported, it's not clear why we'd encourage implementers to write code to try it out at connectathon...
Dave deBronkart (Dec 11 2020 at 23:59):
A large part of this is way over my head, so please tolerate a high-level question.
My impression is that ALL we're trying to do is provide a way for a request to be transmitted, and the response(s) to be transmitted.
We're not saying a THING about what happens at either end, right?? We're solely creating a protocol for transmitting the request. So what's all the other discussion about?
Again, I may not be understanding what this is all about. If so, just let me know - "Don't worry about it, Dave, it's all in scope."
Lloyd McKenzie (Dec 12 2020 at 00:06):
Well, we're sort of saying something about what happens at the other end because that directs how the request comes in and what sort of interface needs to exist to monitor what's happening. If all we were doing was saying "change this" with an expectation it would happen instantly without human review, we certainly wouldn't have proposed using Task.
Lloyd McKenzie (Dec 12 2020 at 00:08):
We don't care about the specific details of what happens at the other end, only that it can potentially take quite awhile and that there's a likelihood of a human being involved who may need some context to evaluate the request.
Dave deBronkart (Dec 12 2020 at 00:12):
No no no @Lloyd McKenzie , as I've said many times, the LAST thing I want would be to give anyone the ability to unilaterally dictate a change.
Virginia Lorenzi (Dec 12 2020 at 04:10):
Dave deBronkart said:
A large part of this is way over my head, so please tolerate a high-level question.
My impression is that ALL we're trying to do is provide a way for a request to be transmitted, and the response(s) to be transmitted.
We're not saying a THING about what happens at either end, right?? We're solely creating a protocol for transmitting the request. So what's all the other discussion about?
Again, I may not be understanding what this is all about. If so, just let me know - "Don't worry about it, Dave, it's all in scope."
I would add we are solely creating a protocol for transmitting a request and tracking the request through to completion or rejection.
Dave deBronkart (Dec 12 2020 at 09:08):
Virginia Lorenzi said:
I would add we are solely creating a protocol for transmitting a request and tracking the request through to completion or rejection.
Are WE "tracking" it, or are we simply enabling the exchange of status messages?
This seems very important. I fully respect the importance of any burden a standard imposes on implementers. I hear that. If a standard mandates that XYZ shall happen, it might require ludicrous somersaults in the implementer's system, and that would be bad. (Ludicrous Somersaults: good band name.)
But are we?
I thought we're simply (literally no more than) defining how a sender delivers a request, which HIPAA and GDPR already require must be handled. Yes? And once it's received, we don't care whether the receiving system then puts it in some sort of folder, or spools it to a LaserJet for some dumb reason, or toots a factory whistle, or activates a WiFi-enabled Nespresso machine. WE don't even require a response - HIPAA/GDPR do. Right?
From all the discussion of Task, I'm naively guessing that people are thinking ahead to "Can we make the request machine executable in some way." Obviously that would be good if it's feasible. Is that where things are getting mucky?
Dave deBronkart (Dec 12 2020 at 09:15):
Personally I can't imagine a situation where any provider would want any proposed change to be blindly accepted. OTOH, I could imagine an inbox of requested changes, presented to an authorized clinician for review and yes/no/maybe action.
Like, my PCP gets a notice that three patients have requested changes pending; he sits down and each one pops to the screen. Imaginary work session:
- "Oh yeah, Dave did discontinue that med. Accept."
- "Hm, no, Jimmy's actual status is not _____."
- "Yikes, how did Morgan's chart suddenly gain two pregnancies?? Let's hold that one to see what happened."
And in THAT kind of optional, imagined workflow, which a vendor might want to enable, then it might be useful to have the submitted request in some machine executable format, so that each "yes" happens automatically. I suspect that bit of automation would be a slight improvement over the editing work that is already required under HIPAA/GDPR.
But at this stage we're not getting anywhere near that, right? Wrong?
Debi Willis (Dec 12 2020 at 14:10):
I am assuming when a task is placed in an EHR that someone is looking at it. (If not, that is a clinic workflow problem we can't fix.) It may be a task that a doctor is asking a nurse to do (an internally created task for another person at the org) or it could be a task created outside the org. How the EHR handles those tasks (requests to do something) is not something we want to dictate. EHRs (and possibly each clinic) might have their own workflow. We just want to get the task from the patient into the EHR for someone at the clinic to review (whoever the clinic decides should monitor tasks).
Because there is a legal mandate that they have to respond to the patient within 60 days (HIPAA) or 30 days (GDPR), we are expecting that at least the status of the task will be updated by someone in the clinic. The patient can then use the same consumer app to check on the status of their request (the app would poll for the status and pull back any information that was entered into the task on the EHR side). The clinic could also decide to call the patient and talk to them about the request. [In a case like this, the consumer app could allow the patient to indicate the task is complete and the app would not poll for that task in the future.]
Many of the errors will not be as simple as a PCP sitting down and accepting the correction. But, in those cases when the EHR has built the UI to display the error and correction request to automate the amendment, there is a place within the Task resource where we could send that specific piece of information. According to the many conversations and recommendations, we are going to test sending the patient's full request in the Task.description field. If the EHR has a way to handle accepting and displaying structured data to automate the process of a provider accepting the change directly into the EHR, then we can place that in the Task.input field. But, as you can imagine, that is a more complex workflow and requires a more savvy patient (the exact resource needs to be identified), a more complex workflow within the consumer app (to provide a mechanism for the patient to click on the exact element that was wrong and have it identified in the request), probably changes to the EHR UI, and acceptance/training of the EHR users on how to use the process and properly notify the patient concerning what was done.
We want to start with the simple process of creating a request that can be responded to. This will allow even the most basic consumer apps to use this process, allowing for more patients to have this improved workflow. After we have that working, we can see how to do other things to automate more of the process. My hunch is many of the EHR vendors will not have the UI and processes available for a while. My understanding is that several HL7 groups are now starting to use the Task resource to accomplish their needs. This will cause more focus on how the EHRs and clinics manage the task queue.
Lloyd McKenzie (Dec 12 2020 at 15:13):
We aren't defining what the business process is behind the interface. We're defining the interface for request and response and we're defining an interface that allows for a certain type of behavior behind the scenes - human review and taking a long time. If we chose to not allow for human review and to require an immediate response, we'd define a different interface. Exactly how the business flow executes once the request goes in isn't our concern. It could be handled by an automated process, could route through 10 peoples hands. It could get printed off and faxed somewhere. We don't care, so long as the final response (and any interim status updates that happen to fall out of the process) use the interface we've defined - i.e. they come back as updates to the Task. The interface will allow for the possibility of a request being submitted and going off into never never land and not being resolved.
Abbie Watson (Dec 12 2020 at 19:02):
@Jenni Syed - I really appreciate you explaining and sharing those insights. Thank you!
@Drew Torres - Following up on my question to Jenni... does the Cerner cloud FHIR stack currently support HTTP/2? Are async calls with promises supported? And can we use async syntax in our workflow discussions and documentation? Is there a timeout or refresh token? If we use one of your write interactions, is it possible to register a callback that gets called when the operation is completed? Or would that need Subscription?
Disclaimer: I have two degrees in medicine, and HTTP/2 and async is bordering on the limit of my knowledge of web specs. I'm not asking about HTTP/2 specifically, but about async and getting a response back for an HTTP call 30 or 60 days later.
Virginia Lorenzi (Dec 12 2020 at 21:56):
First I am hearing of aync in this! Providing some historical context: To keep it simple, we agreed the app would just periodically poll for their request for correction task. Inside Task they could find the current status , reason and other things like notes or specific patient communications like how to log a disagreement. We had decided that for a future version we would look at adding subscription/notification functionality.
Lloyd McKenzie (Dec 13 2020 at 03:31):
If we were to use PUT, we'd have to use PUT with async - because synchronous PUT wouldn't allow for the human review that will pretty much always be required. However, my impression is that what's currently proposed (by Cerner at least) is synchronous PUT plus review, which I really don't understand. (But I'd like to :>)
Dave deBronkart (Dec 14 2020 at 02:50):
Abigail Watson said:
Disclaimer: I have two degrees in medicine...
I did not know that! Say more??
Last updated: Apr 12 2022 at 19:14 UTC
