Stream: patient empowerment
Topic: A way forward for patient corrections
Virginia Lorenzi (Jan 24 2021 at 23:34):
What about the following?
It allows us to build on what we already have designed:
Use the Task method we already have in the IG.
- support of official correspondence such as amendment report and denial report and official inputs like request for corrections form and letter of disagreement supported using inputs and outputs. (however, as much as possible inputs and outputs are optional and information could be communicated by another means)
- use notes on fulfiller side only to communicate information about the work done on the task which could include notation about patient correspondence.
- carefully design ability to update a request (Vassil and Lloyd have provided advice on this).
As a separate but related function or project, create a second capability to support a FHIR equivalent of secure messaging between patient portal and provide message boxes. This could be used for any number of purposes. One purpose could be to correspond with patient about clarifications on correction request. Provide capability in the Communication and/or CommunicationRequest resource to point to the RequestforCorrection Task.
Reflecting on this, I think there is another problem that could use the same paradigm: a patient's Request for Release of Information. Especially when data is not available to the portal or API, this is very much a manual process. And if data could come to the API, even as a PDF that would be valuable.
@Debi Willis @Dave deBronkart @Lloyd McKenzie @Vassil Peytchev @Jeffrey Danford @Lisa Nelson
Lloyd McKenzie (Jan 25 2021 at 03:07):
Why on the fulfiller side only? Allowing the Patient (or caregiver) to add comments seems like something we'd want to support.
No real 'careful design' is required. Updates that check for resource contention are a pretty typical way of doing things. We'd just need to say that it was mandatory for use with our IG.
Agree that if we're going to define a generic mechanism for supporting a back-and-forth discussion, it should be generic. There are a good number of things that patients and providers might find it useful to have a 'conversation' about.
I still want to better understand @Jeffrey Danford's concern about the Patient initiating the Task directly and his preference for indirect initiation instead.
Virginia Lorenzi (Jan 25 2021 at 07:41):
just saw more of case for notes on fulfiller side and trying to keep it simple. Excited to learn about resource contention. Want to know if anyone else is doing something like this.
Dave deBronkart (Jan 25 2021 at 12:31):
Lloyd McKenzie said:
Why on the fulfiller side only? Allowing the Patient (or caregiver) to add comments seems like something we'd want to support.
:100: ^^:100:
Dave deBronkart (Jan 25 2021 at 12:37):
Lloyd McKenzie said:
if we're going to define a generic mechanism for supporting a back-and-forth discussion, it should be generic. There are a good number of things that patients and providers might find it useful to have a 'conversation' about.
I want to note here, because the distinction is subtle and vital, that this is a signal of a shift from the old view "We know everything that's important, and we're right about it" to "To get this right, we need to collaborate." Participatory medicine.
In the early days of the "data liberación" movement, more than once a senior-looking physician said to me after a speech, "These are MY notes, for MY work! They're none of your business!" In that view, it made sense for long-ago vendors to create systems to do what their customers wanted: a system that had no need for dialog.
Dave deBronkart (Jan 25 2021 at 12:39):
Here's an artifact from "These are MY notes" days. The desk clerk actually laughed when I asked for a copy but readily provided it :-)
image.png
Bart Carlson (Jan 25 2021 at 19:00):
A great example of reality!
Josh Lamb (Jan 25 2021 at 19:43):
I am trying to incorporate the notes in this thread with the 'How message are IRL...' thread. I am now realizing I may have been posting in the wrong stream haha. I posted a flow that includes the fewest number of steps I can imagine to provide a simple, "lets chat about this bit of data, and let me know the status of updates" functionality. It's not grandiose but it will be more attractive to implementers because of ease of use (realistic first step). I will also take suggestions (as @Lloyd McKenzie has some ideas on how to change out the task/communication resources that will be helpful).
I will update the flow with lloyds notes (we add task.note[] instead of the more burdensome communication resources). This will cover the use cases specified in the IG.
Last updated: Apr 12 2022 at 19:14 UTC
