Stream: patient empowerment
Topic: A third role emerges in patient corrections
Virginia Lorenzi (Jan 31 2021 at 00:24):
Currently we have Correction Requestor and Correction Fulfiller. But what if we break it down a bit more and allow for a middleman - CorrectionRequestRepository - both of the other roles can interact with it. Of course you can merge any of these roles together. Or in a more generic sense (inspired by convo with @Josh Lamb ) this would really be TaskRequestor, TaskFulfiller, TaskRepository. Then the repository is the only server in the game and it would need to be able to provide a well-formed standard API endpoint interface for both Requester and Fulfiller but would not have to provide the user functionality - that could be in the Requestor and in the Fulfiller applications. An EHR Fhir server could play this role, as well as FHIR API middlemen/gateways.
Vassil Peytchev (Jan 31 2021 at 04:29):
That doesn't make any sense to me...
Vassil Peytchev (Jan 31 2021 at 04:52):
The request is from the patient to the responsible entity, and there is an endpoint for that request. What is behind that endpoint doesn't matter, does it?
Lloyd McKenzie (Jan 31 2021 at 05:07):
Who are we expecting would satisfy the role of the gateway? Typically, EHRs aren't set up to support looking at data from third-party systems and it's not sure why they'd want requests for change managed externally...
Virginia Lorenzi (Jan 31 2021 at 05:58):
It means an app could be written to do the correction fulfiller workflow and the app would not have to be the EHR. So long as the Task could be accessed in the FHIR server by that application/software. EHRs don't need to look. They don't all have the request for correction workflow. Thats the issue. If they don't build it maybe apps will.
Virginia Lorenzi (Jan 31 2021 at 06:00):
There are middlemen out there - intersystems, 1uphealth, careevolution, etc.
Josh Lamb (Jan 31 2021 at 15:57):
This is a good value proposition for the "middlemen" applications too since they can develop a single application that will function against all EHRs (that support this modified Patient Access API). The low implementation burden and hi reuse will also help.
Virginia Lorenzi (Feb 01 2021 at 04:16):
The problem I am seeing is that some EHRs do not have software to support the request for correction workflow. So providing a way for that software to be written, as a FHIR application, might be cool. I absolutely see the benefit of an EHR vendor supporting it. However, if that is the obstacle to getting this problem fixed we are brainstorming on other ways around it. At our expert panel, Kelly from CompliancePro demonstrated his standalone system used by HIM departments for numerous request and compliance workflows including Patient Request for Corrections. CompliancePro is not an EHR but a specialized system for the HIM department. HIM uses his system to manage the workflow. There are several systems like his, but he is the only one that includes corrections that I know of. However, his systems and others do support other patient HIM request workflows - the most common one is the Release of Information workflow. The ROI workflow may see an increase in volume as well as complexity to the kinds of requests allowed and the choices in how to handle due to infoblocking rules. In my experience in Health IT, it is not uncommon to have numerous systems supporting different users in the healthcare processes. I think adding in the ROI request is a natural progression of this spec. @Lloyd McKenzie @Vassil Peytchev Currently the corrections are being done manually and I don't see that changing at least not all parts and not for awhile, so the HIM person would interact both with an application for their workflow and would work with clinicians and others to have the EHR corrected (merge charts, have doctor amend his record). What we were trying to automate was the request and tracking process.
Lloyd McKenzie (Feb 01 2021 at 05:05):
I'm not saying the solution needs to be in the EHR software - it needs to be in whatever software HIMs use to manage the request for correction process. That may or may not be an EHR module. But supporting a third-party app should only be something we do if there's a belief that HIM departments would welcome yet another system. Otherwise, we should be focusing on working with whatever systems they use now.
Virginia Lorenzi (Feb 01 2021 at 05:52):
So my point is those I have asked, several do not. This is most likely because of the low volume of requests which is weird considering the studies on number of errors (except that the process is arduous)
Virginia Lorenzi (Feb 01 2021 at 05:53):
Lloyd, this is not what I had expected to find when we started out on this journey.
Lloyd McKenzie (Feb 01 2021 at 07:27):
That always makes the journey more interesting :) I guess the follow-up questions then, for those who don't have any system capability now are: do they have any interest in expending any resources to get such a capability and, if so, where would they want the capability to manifest?
Last updated: Apr 12 2022 at 19:14 UTC
