Stream: patient empowerment
Topic: List of Pros/Cons of different Resources
Debi Willis (Feb 07 2021 at 21:34):
We have not been able to find a time when many people can join the Patient Request for Corrections project at the same time. We are trying to facilitate consensus concerning the resource we should use to enable the bi-directional conversation between a patient and a covered entity when the patient has a request for a correction to their records.
In an effort to get more feedback, we are going to post specific questions on Zulip first and then find times to get together on calls to discuss the various answers.
There are several strong opinions about the resource(s) we should use, and we need to understand the strengths/weaknesses of each option. For now, we would like to document the pros and cons of each resource recommendation. This "first go-round" is not meant to be a debate about the thoughts listed by others. We simply want you to list what you think are the pros and cons of the choices. We will then present the full list in a meeting so there will be an opportunity for all to discuss the strengths/weaknesses of the different options.
I realize this may be a different way of researching the choices, but let’s give this a shot. Please don’t focus on what others are saying (and refrain from commenting on their choice). We will have a separate meeting to discuss the pros/cons. Just pretend you are listing the pros/cons of sports figures/desserts/animals…whatever. Be as objective as you can. The options are:
1) Use the Task resource only
2) Use the Task and Communication resources together
3) Use the Task resource with a custom operation for adding the bi-directional conversation to Task.notes
4) Use Communication only
5) Use PUT/POST/PATCH only
NOTE: items 1-4 include the ability to add PUT/POST/PATCH within the resource.
If you don’t want to answer globally, you can PM me or @Virginia Lorenzi . All items will be added to our document without names of authors. If you know of anyone who would like to comment on this, please forward this thread.
@Lloyd McKenzie @Vassil Peytchev @Jeffrey Danford @Isaac Vetter @Drew Torres @Jenni Syed @Josh Mandel @Lisa Nelson @Mark Scrimshire @Grahame Grieve @John Keyes @John Moehrke
Lloyd McKenzie (Feb 08 2021 at 00:27):
Have we thought about using a Google Doc for this? I expect there's going to be discussion/disagreement about a bunch of the pros/cons and also that it may be hard for people to visualize the complete lists as they're spread out across all of the posts. I'm happy to start one, if that works... (@Debi Willis)
Lloyd McKenzie (Feb 08 2021 at 00:38):
To heck with it, I'm creating a Google doc. It's getting too long/complex to make a reasonable Zulip post.
https://docs.google.com/document/d/1Q_Vln_Vb21JVu1rPgwPZ68_IyTlktuuSGGJLm9kGSY4/edit?usp=sharing
Lloyd McKenzie (Feb 08 2021 at 00:40):
Note: I'm splitting #2 into two options, because I've heard two very different approaches to mixing Task and Communication. One option is to use Task to manage the submission and monitoring of the request for change, but use Communication to support the back-and-forth communication. Second is to use Communication to initiate the request and share back the Task that was created in response, but then to monitor the Task and share information via the Task. (I suppose there's a third possibility to use Communication for both initiation and discussion, but still have the Task for tracking status, but I think we can just look at the pros and cons from the first two options to evaluate the possibility of combining them.)
Lloyd McKenzie (Feb 08 2021 at 04:23):
Splitting #5 as well - as these can be done through synchronous and asynchronous processes and pros/cons are quite different for each
Lloyd McKenzie (Feb 08 2021 at 04:38):
Finished my first pass - over 5 pages, so be glad it's a document and not a Zulip post... :smile:
John Moehrke (Feb 08 2021 at 12:57):
I prefer a nice comprehensive solution, but I know that will fail. So I recommend we go for a simple solution that addresses the points found in the paper world today. The closer we can get to the paper world, made digital, the more likely the solution will be implemented. Without implementations all our efforts to design a comprehensive solution will be a waste of time. Thus the only measure on the Pro and Con vectors should be Pro: Will it work?, and Con: Will it be implemented?.
I would prefer a #6 that defines a Questionnaire that is used to initiate the change request. We might be only able to define a well-known Questionnaire that would be expected at all EHR sites for submission of change requests. Much like how it is common for a web-site to have a well-known privacy policy location, well-known contact us, a well-known unsubscribe...
It might not be the most comprehensive solution. But it is better to move than waste energy and get no where.
Debi Willis (Feb 08 2021 at 15:30):
Thanks Lloyd. Some people have trouble with google docs and I don't want to limit their ability to give input. For those who want to place their ideas on the google doc, please feel free to do that. Others scan place their ideas here or PM me or Virginia.
Lloyd McKenzie (Feb 08 2021 at 16:21):
Happy to turn the Google doc into a PDF for whoever wants it.
Lloyd McKenzie (Feb 08 2021 at 16:22):
@John Moehrke QuestionnaireResponses can't initiate anything. They can be a payload to something, but can't drive behavior on their own
Debi Willis (Feb 08 2021 at 16:59):
Thanks @John Moehrke Please add that to the list as #6 and we will discuss the pros and cons of that option as well. Please also add your thoughts on the pros/cons of the other options too. We really want to understand and listen to all the thoughts on this topic as we move forward.
The goal here is to simply get the information in a single place so all can review and discuss it in a meeting.
Josh Mandel (Feb 08 2021 at 18:02):
I just squeezed in a different option as number 6, so maybe add that one as number seven? ;-)
Debi Willis (Feb 08 2021 at 18:20):
:) Thanks @Josh Mandel
Virginia Lorenzi (Feb 09 2021 at 03:18):
There is quite a detailed list already in the minutes from the WGM. We spent 3 hours of the WGM discussing pros and cons over 2 meetings. I will compare what you have and add in anything I see missing.
Abbie Watson (Feb 10 2021 at 20:12):
Debi Willis said:
The options are:
1) Use the Task resource only
2) Use the Task and Communication resources together
3) Use the Task resource with a custom operation for adding the bi-directional conversation to Task.notes
4) Use Communication only
5) Use PUT/POST/PATCH only
DocumentReference and Bundle/Composition are the other considerations, imo. Primarily because medical record amendment requests, when they are currently digitized, are likely happening via CDA or PDF documents, and being stored in a document server. And that whole infrastructure is accessed by DocumentReference. Bundle/Composition because Composition has a JSON/XML equivalent of a PDF document.
When I think of the different options, I think of it more in terms of the following:
1) Task only
2) Communication only
3) DocumentReference only
4) Bundle(Composition + Other) only
5) ServiceRequest only
6) Task + Communication
7) Task + DocumentReference
8) Task + Bundle(Composition + Other)
9) Task + Task.notes(Communication)
10) Task + Task.notes(DocumentReference)
11) Task + Task.notes(Bundle(Composition + Other))
12) Communication + DocumentReference
13) Communication + Bundle(Composition + Other)
14) ServiceRequest + DocumentReference
15) ServiceRequest + Bundle(Composition + Other)
This isn't to suggest any one specific approach from the above, but to suggest that the problem domain tends towards these particular combinations.
In particular, Communication is reflective of the presence of a phone bank or switchboard and the telecommunication department's role in routing requests, DocumentReference is reflective of PDF document servers and the medical record departments workflows going all the way back to microfiche machines.
Also, some systems have a Bundle service, which to implement requires a Bundle parser. And since the Bundle requires a Composition or cover letter, as it were, any system that has a Bundle service will naturally also have a minimal way to parse a Morgan Gleeson letter, as long as it's in Composition format.
Lloyd McKenzie (Feb 10 2021 at 21:17):
Documents, by themselves, can't drive behavior. You have to use an operation, message, Task or something else to say "please execute against this". That said, document + operation could be an option. A completely custom operation where the only input is Parameters is also possible.
I don't see Task + ServiceRequest, which would be a typical combination (ServiceRequest is the authorization and Task deals with managing the fulfillment process and captures status of execution.)
How many of these do implementers actually want us to flesh out pros and cons of? (We're already at 6 pages)
Virginia Lorenzi (Feb 10 2021 at 23:02):
@Abigail Watson please review the google doc lloyd created and add your thoughts there so we have it in one place.
Virginia Lorenzi (Feb 10 2021 at 23:08):
@Abigail Watson I think on 8) and 9) on your list you mean Task.input not notes - notes can't be a reference to a resource. Under option 1) in the google doc and pro is ability to incorporate other resources such as DocumentReference, Composition, QuestionaireResponse, and even Communication by reference via Task.input.
Debi Willis (Feb 15 2021 at 23:34):
Patient Corrections: It' time to Pick Your Favorite!
Thank you everyone for your detailed and thoughtful feedback! Now it is time to narrow down the many selections provided:
WHAT WE NEED YOU TO DO: Please fill out the chart at the top of the google doc (link at bottom) to help us with the narrowing process.
WHEN DO WE NEED IT BY: Deadline is 2/23/21.
WHEN WILL THE RESULTS BE DISCUSSED: We will discuss feedback on the next Patient Corrections Call on 2/25/21 at 10 ET
Join Zoom Meeting
https://hl7-org.zoom.us/j/93069166841?pwd=NnpNclVWNFhzNGhEYXVFMW84eWlHUT09
Meeting ID: 930 6916 6841
Passcode: 997467
One tap mobile
+16465588656,,93069166841# US (New York)
+13126266799,,93069166841# US (Chicago)
Thanks again.
https://docs.google.com/document/d/1Q_Vln_Vb21JVu1rPgwPZ68_IyTlktuuSGGJLm9kGSY4/edit?pli=1#
Virginia Lorenzi (Feb 26 2021 at 07:05):
We are still looking for feedback - please register your vote.
Last updated: Apr 12 2022 at 19:14 UTC
