Stream: patient empowerment
Topic: Re: What's the problem? Josh's Diagnosis
Josh Mandel (Dec 12 2020 at 14:53):
Reading through the #patient empowerment > Honest question: what's the problem? thread, I think the crux of the issue is that today, while every healthcare provider organization has some process for managing HIPAA amendment requests, the process is not standardized and not necessarily managed within a dedicated EHR-vendor-defined workflow (e.g., it may be managed in an administrative IT system health outside the EHR, or through internal email, or an ad hoc organizationally defined workflow within the EHR).
The implication of a new IG (regardless of what FHIR resources, operations, or interactions the IG uses -- as long as the IG is covering the full breadth of HIPAA amendment rights) is that there needs to be some kind of new, deep integration between the FHIR API and these varied, unspecified, externally managed organizational processes.
So the concern we're really hearing is a worry about the very substantial pain of trying to integrate a focused API endpoint with numerous, varied, diverse, internal organizational processes -- or put the other way, trying to dictate a new, vendor-defined, EHR-based process to the many healthcare provider organizations that have developed their own variations over the years.
Basically, the core issue for EHRs is this IG implicitly expects them to take on a new responsibility they have not previously (strictly) managed. Even though we try to say in the IG something like "beyond the API everything's a black box, anything goes, do what works in your product" ... the assessment above still stands, and the pain points are real.
The endless debate about "Is Task the right resource?" is a distraction.
Dave deBronkart (Dec 12 2020 at 15:40):
Brilliant, Josh - I'm so grateful. You put into my vague feeling into better words - more specific, more precise.
Dave deBronkart (Dec 12 2020 at 15:40):
What do others think? Especially provide orgs? @Virginia Lorenzi is the only provider rep I'm personally aware of.
Dave deBronkart (Dec 12 2020 at 15:44):
@Josh Mandel a fine point if I may. Strictly streaking, a red herring is an intentional diversion for rhetorical purposes - a form of changing the subject. I'm guessing that's not your intent, right? I suspect you mean something more like a side track?
Josh Mandel (Dec 12 2020 at 15:45):
Oh I love it! You are quite right.
Josh Mandel (Dec 12 2020 at 15:46):
(I have updated my final sentence to call it simply "a distraction".)
Dave deBronkart (Dec 12 2020 at 15:49):
Intentional diversion, not dissection. I too will fix it.
Lloyd McKenzie (Dec 12 2020 at 16:39):
As I think about it, I'm not sure that we're trying to dictate a new "process", but we are trying to define a new entry point and response point. I.e. we're asking the EHR to route information to and from an area of the healthcare organization they might not have previously been required to support (or at least, the API part of the EHR typically had no involvement with). That's (hopefully) not quite as scary, but it certainly is a new ask. And, of course, enabling the routing opens up the likelihood of being asked to do more in the future. So there's certainly pain there to be felt.
Josh Mandel (Dec 12 2020 at 16:48):
"Routing information to and from an [unknown, variable] area" is a new process.
Josh Mandel (Dec 12 2020 at 16:48):
That's exactly the issue.
Dave deBronkart (Dec 12 2020 at 16:55):
Process in the system sense or business/cultural sense?
Josh Mandel (Dec 12 2020 at 17:03):
I think it's some of both...
Michele Mottini (Dec 12 2020 at 17:33):
...and as long as EHR vendors are not taking that on (that seems to be the case) it makes no sense to keep going down that path, better to use whatever EHR vendors are already working on - that is some support for direct resource modifications - even if that won't cover the full HIPAA amendment rights
Brendan Keeler (Dec 12 2020 at 17:46):
Spot on, Josh.
There's an incentive for EHR vendors to limit FHIR workflows from requiring new user facing data structures or UI. If FHIR is just backend mapping to existing Epic/Cerner/etc data structure, it's an easier lift. If it requires new UI, there's more engineering effort and more documentation needed and more training for users (arguably for features they're not asking for).
FHIR and FHIR related regulation thus far hasn't done that, so I understand the sentiment. MU2 did that en masse, with many features unused and discarded afterwards.
If a standards body is starting to move from "how do we transport the data" to "let's impose data architecture, structure, and display", we start to look a lot less like HL7 and more like OpenEHR
Brendan Keeler (Dec 12 2020 at 17:47):
Screenshot_20201212-094648.png
Brendan Keeler (Dec 12 2020 at 17:47):
(who, ironically, has this on their homepage)
Brendan Keeler (Dec 12 2020 at 17:55):
Fwiw, i don't think Task itself is a red herring. The workflow piece of this discussion is one aspect that's causing problems. But task is a data structure foreign to most EHRs today, both for this context of patient correction, but also literally every other place it's used (see orders and results).
Epic and Cerner weren't originally designed in this technical era of notifications, where users have some task queue to work through. Provider and healthcare work admin are not task list driven, at least in the sense of a cross-resource task list. There are functional equivalents specific to users (as a scheduler, work through referrals/orders by scheduling appts. As an imaging tech, work through scheduled appts by taking images. As a radiologist, interpret the images that have been completed.) I get the sense that EHR vendors aren't super psyched to try and take the generalized Task and figure out business logic to map it to a hundred unique worklists. That's a data structure /architecture problem, on top of the aforementioned workflow imposition problem.
Josh Mandel (Dec 12 2020 at 17:58):
I take your point about Task @Brendan Keeler. Maybe I'd reframe my perspective as: "the use of Task vs Communication vs whatever is a secondary issue that we shouldn't get overly fussed about until we've addressed the crux".
Josh Mandel (Dec 12 2020 at 17:59):
(In general I find the FHIR workflow stuff super abstract and hard to understand, which I don't hesitate to mention to Lloyd frequently!)
Debi Willis (Dec 12 2020 at 18:02):
Just curious...how does a clinic work through the requests coming in from the portal? Wasn't that a new process the EHRs had to build and staff was trained on at some point? If we are saying that we don't want to do anything that causes any new work for an EHR vendor or new process for a clinic...i am a bit concerned about how we move forward in the future to make things better.
Abbie Watson (Dec 12 2020 at 18:02):
Entirely agreed, Josh. 100%
For the record, I could care less whether the IG contains Task or not. And if I came across as ‘anti-Task’ when I tapped the brakes earlier this week, that wasn’t the intention. I am much more... neutral. Unconvinced and skeptical that Task solves the problems that Josh outlines above.
What I’m passionate about though, is the use case. And whether at the end of the day, the record gets updated (by whatever means necessary), and documenting that process for other implementors. How that happens, I couldn’t care. So Task is much more of a yardstick; a conceptual tool to start the discussion.
@Dave deBronkart - I used to work at NYP for five years (same org as Virginia), doing EHR rollouts, and managing a medical records file room responsible for making HIPAA medical records corrections.
Lloyd McKenzie (Dec 12 2020 at 19:42):
For us to solve the use-case, there needs to be agreement that EHRs are willing to take on the responsibility of routing a request for change to the humans who will make the decision. If that's not something they're comfortable taking on, then the reality is we won't have an API to submit those requests. Task vs. asynchronous PUT vs. Communication are just the technical mechanism. We can't push forward with any mechanism if there isn't an agreement to take on the routing responsibility. (Because direct unmediated update of records by patients is (and should be) a non-starter for most data elements.)
Debi Willis (Dec 12 2020 at 20:32):
My understanding is that other groups are also building solutions using the Task resource. Are EHRs in agreement to route those tasks to the appropriate people?
Josh Mandel (Dec 12 2020 at 20:36):
Not that I'm aware of
Abbie Watson (Dec 12 2020 at 20:43):
Whose responsibility it is to make the corrections were exactly the kind of debates we (NYP/NYMH) had with Cerner for nearly 5 years, when we were beta-testing the Millennium architecture in the mid-aughts. I rotated through nearly every department at NYMH as we rolled out Millennium one department at a time (in a bioinformatics residency of sorts), and saw the argument get rehashed in nearly every department.
My intuition is that it's less of a strategic issue of whether the responsibility should be assumed at all (most everybody is in agreement it should); but more of a tactical issue of which department and which budget and how it gets rolled up with other legal requirements. i.e. Is this the Laboratory's responsibility to correct, or is it central Medical Records' responsibility? A state that also has ADA disability laws mandating that medical corrections be available via TTY devices for deaf people may rightfully say that corrections need to go through a phonebank, and it's the Communication department's responsibility. Not to mention that Business Associate Agreements muddle things, because a medical record that needs a correction might be in a system covered by the BAA but which isn't actually a Provider organization. SLA requirements say that the corrections have to be able to be made 24/7 for medical emergencies, so who has the budget that's running the help desk? And so forth.
That's why we're seeing Communication, CommunicationRequest, and DocumentReference come up repeatedly. Holdovers from document storage servers (PDF/blob storage replacing white paper), and phonebanks/switchboard/FAX infrastructure.
Lloyd McKenzie (Dec 12 2020 at 20:47):
@Debi Willis With CDex, we evolved to a place (after several months of discussion with EHR vendors) that Task was probably the best way to meet the requirement for submitting a request for data that required (at least potentially) human intervention prior to or after execution. We don't have a firm commitment from EHRs to implement that or a timeline for it. With CRD, there hasn't been objection to the notion of using Task to capture the meaning of a card that says "please fill out Questionnaire 123" but nor has there been agreement by EHRs that they'll support that particular capability any time soon (if ever).
Virginia Lorenzi (Dec 12 2020 at 22:01):
If Human Intervention is needed - healthcare workflow will be impacted @Brendan Keeler .
Debi Willis (Dec 12 2020 at 22:12):
@Lloyd McKenzie Is this a case of "Which comes first... the chicken or the egg?" Seems like we should test the FHIR workflow to see if we can accomplish what the law is requiring before we ask the vendors to implement it. Are we saying they have to agree to implement it before we demonstrate that it is the best option?
If we have a stable and effective use of FHIR to accomplish this important process, and there is a good argument for using it (patient safety, more efficient workflow for clinics, patient preference, etc.) it would be reasonable for vendors to implement it. Isn't patient safety and clinic optimization important to every vendor and clinic? Am I being too naïve?
I believe that having the ability to use FHIR to request changes to my record is as valuable to my health and safety as the ability to download my records using FHIR. We could get paper records in the past...yet the ONC mandated we should be able to get them via FHIR.
Are we saying we should not go down this path of using Task because the EHR vendors have not implemented it yet?
Josh Mandel (Dec 12 2020 at 23:08):
I wouldn't be too paralyzed by a need to build consensus or obtain broad commitments yet -- write an IG, try it at connectathon, iterate. It's all good experience. That said, I wouldn't advise pushing super hard to ballot this all as soon as humanly possible; I'd focus more on building community. The idea that the spec will be "there ready on the shelf when it's needed in the future" tends to be a fallacy. Specs, like software, rot when left on the shelf.
Lloyd McKenzie (Dec 13 2020 at 03:30):
I think we were taking a pause to re-evaluate because we were getting feedback that there was an alternative preferred direction. However, I haven't really understood how what was proposed by the vendors will actually work or will meet the use-case. However, that pause doesn't mean we can't proceed with the evaluation of Task at connectathon.
Virginia Lorenzi (Dec 13 2020 at 09:00):
We are not pausing. We are still testing Task as planned. But the goal is a solution that solves the problem, whatever that may be.
Virginia Lorenzi (Dec 13 2020 at 09:31):
@Brendan Keeler HL7 is all about impacting workflow. It defines the communication but workflow ends up impacted. At a hospital, if a V2 interface goes down its a serious problem. workflow is impacted. And the V2 orders interfaces send messages like new order, update order, hold order, discontinue order. And then we get back all the statuses on the order from the filler system - blood needs to be drawn, specimen collected, in lab, prelim results, final results, etc. They are telling the other systems stuff that impacts the workflow on those systems. CCDA feeds into clinical reconciliation, required in the US for PI in 2020. HL7 defined the CCDA spec. ONC required that it be used and that patient matching and clin rec be done. And even the FHIR read only API is impacting providers. With the FHIR Request for Corrections IG, its just an interface - we are not telling the ehr what it has to do, no more than orders interfaces do. This is an interface problem. This is not openehr. We can define the spec but how it is used is up to the industry or regulators. Also, I believe that this functionality will be useful to EHR customers since notes are starting to be released over the API. Provider needs to answer the patients requests for corrections and wants them to be happy. This could streamline for them.
Debi Willis (Dec 13 2020 at 20:01):
@Lloyd McKenzie We are not pausing. We are still going to evaluate if Task is a good resource to accomplish all the pieces required for a patient requesting to have their record amended.
You are correct, the other proposal to simply have the patient write to the EHR does not meet the use-case. I really think it got confused when some did not look at the full scope of what we are trying to accomplish. In fact, if we don't accomplish all the aspects that were presented earlier (which are required by US law), then we cannot say we are automating a patient's request to have their data amended. We can't do a part of the process and say it is complete. It won't fly legally. We really want to test to see if all the legally required pieces of communication can me done using Task.
The patient sending data to the EHR is also very important. But, it does not accomplish the use-case. Another project of our workgroup is "Patient Contributed Data". It matches the proposal to have the patient write to the EHR.
If we find that Task does not accomplish what is required by law, we can look at other options for the next connectathon.
Bart Carlson (Dec 13 2020 at 22:38):
No matter which approach we start with, I believe Debi Willis's point "In fact, if we don't accomplish all the aspects that were presented earlier (which are required by US law), then we cannot say we are automating a patient's request to have their data amended." should be our minimum viable standard for Version 1.
Dave deBronkart (Dec 14 2020 at 03:23):
Bart Carlson said:
No matter which approach we start with, I believe Debi Willis's point "In fact, if we don't accomplish all the aspects that were presented earlier (which are required by US law), then we cannot say we are automating a patient's request to have their data amended." should be our minimum viable standard for Version 1.
This is a sharp observation. Had we thought of it at the time, it might have been good to put into the project proposal! Maybe we can amend or append it" at some point, to make it official.
Abbie Watson (Dec 15 2020 at 14:58):
It’s HL7 International, and we don’t only cater to US law.
There’s different ways to approach Interoperability. One way is top-down, where one tries to engineer and mandate interoperability through law. Insisting that everybody speaks the language that you prefer, using the Queens English that is elegant and correct. Problem is, sovereign nations push back, and say ‘US law isn’t French law’ and such.
Another approach to Interoperability is the Rosetta Stone. Where we collect all the different approaches, in a Venn Diagram exercise, and we use the scientific method and a process of discovery. We make a map of sorts, and say ‘Here! This here is where all the different parts of the problem overlap. This is where we thread the needle. This is where Interoperability occurs. This is the specific amount of complexity we need to add, so that all the different concerns are addressed.’
One approach is focused around crafting a document that everybody agrees to, and mandating that everybody adopt one particular worldview (our way or the highway). The other approach seeks to collect documents from different world views, and create a Rosetta Stone that can translate those worldviews.
I would hope we’re careful in this regard, and don’t assume that US law is the only law. At best, it’s a topic for US Core.
Debi Willis (Dec 15 2020 at 16:52):
@Abigail Watson As discussed yesterday, no one is preventing you from trying the PUT method. As expressed many times, please test the PUT to see if it accomplishes all the things necessary in the conversation back and forth between the patient and the covered entity.
GDPR has similar requirements concerning patients' rights around their request to rectify their data....same requirements to explain a denial, include additional information on their right to make a complaint to the ICO or another supervisory authority, and their ability to seek to enforce their rights through a judicial remedy. They also recommend that notes be kept in the EHR.
Debi Willis (Dec 15 2020 at 17:00):
@Abigail Watson We are not trying to force the EHRs to provide patients the ability to create/update/patch by including it in this IG. According to your recent email, your intention is to do exactly that. You wrote, "Argonaut lists create, update, and patch as optional with a MAY requirement, when an IG that truly addresses patient needs regarding correcting medical records has got to treat it as a SHALL." You said you tried for 3 years to make this happen and now you want to force the issue by including it in our IG.
We are trying to accomplish testing Task to see if it meets the goal. You are trying to force EHR vendors to change MAY to SHALL. Those are two very different motives.
Test PUT please and let us test Task without ranting at us that we are requiring everyone "to speak the same language". This is simply not true (as well as many other statements you have made) and it takes away from collaboration. Having different views is good. Spreading lies is not good.
Lloyd McKenzie (Dec 15 2020 at 18:42):
The law piece is a bit of distraction. The key consideration is that workflow pretty much everywhere (regardless of law) is that patients can't drive changes to much (if any) of their clinical or administrative record without human review and approval. That fundamental fact is driven by the fact that patients don't have the training/understanding of the changes they might make and don't understand the ramifications of corrections on other parts of the record (e.g. other patients) they can't see. It's also driven by the fact that there isn't always trust between the patients and practitioners. Therefore, whatever solution we define needs to be focused on that human-to-human (i.e. Patient/Caregiver to provider/admin-staff) communication and enable a traceable conversation. Whether there's any interest from the EHR community in enabling that conversation to occur through the EHR is an open question. However, a synchronous PUT is not going to allow for human review. As such, it's not going to meet the use-case.
Virginia Lorenzi (Dec 15 2020 at 21:18):
I just want to note that we reviewed gdpr as well.
Virginia Lorenzi (Dec 15 2020 at 23:53):
@Cooper Thompson I am thinking exactly the same way and have reached out to some folk. I wonder if its tracked on ROI systems. I was even thinking if anyone is doing a homegrown system of spreadsheets there might be a provider side FHIR apportunity here.
Last updated: Apr 12 2022 at 19:14 UTC
