Stream: patient empowerment
Topic: How messy are IRL correction requests?
Dave deBronkart (Jan 24 2021 at 02:54):
The massive "awkward conversations" thread has become an .... awkward conversation. So I'm going to split out this IMPORTANT QUESTION that arose there and has become a blog post:
Dave deBronkart said:
Hey all - we've really grabbed the ball on this and started running with it , in a blog post. Please share in your circles of people who have real-world experience on this: we created a blog post to crowdsource people's front-line experience -
Is it easy or messy to negotiate fixes for medical record errors? Real-world experience needed.
We REALLY REALLY want to be driven by reality, so this question is important. Please help us gather info from people who deal with this in their day job!
AHIMA is circulating it. @Debi Willis @Virginia Lorenzi note that @Jim StClair responded in a reply on the post:
would love to examine this further. I shared with the team at OMG BPM+Health as the BPM/automation aspect is a good fit. I'm also interested to explore the mobile UX and workflow.
Hey @Jim StClair you (and/or they) should join in on the Patient Requests for Corrections IG project, at this week's WGM and/or going forward!
Vassil Peytchev (Jan 24 2021 at 04:09):
The reality is that anything related to legislatively regulated requests will be messy. Real life example: after being rear-ended, my license plate was quite bent out of shape. I wanted to request a new set of license plates (and pay for it), but wanted to retain the existing license plate number - a random combination, but one that I was used to. Seems fairly straight forward, but the outcome was that I still have the original hammered out license plates.
I see this as a distraction question - not because it is not important to facilitate the messy conversations that will accompany the request for corrections, but because trying to represent messy conversations in a complete, fully specified interoperability specification will take a long time. I think helping along the conversation is not the same as making that a core part of the first draft of the Patient Corrections IG.
Virginia Lorenzi (Jan 24 2021 at 05:04):
A fear I have is we will over design it with lots of resources and complex fields (coded inputs and outputs) - I am OK with the opportunity for complexity but want a low budget simple solution to start.
Josh Lamb (Jan 24 2021 at 14:46):
Sorry to jump into the middle of a substantial conversation.
I think you can break up the challenges around allowing patients to assist with medical data accuracy into a few steps (my guess below).
- patients need to see the data, so they can notice the errors
- when an error is noticed, patients need to know how to communicate the error
- providers need a way to receive the notification from patients
- providers need to communicate the update status to patients
- patients will need to verify the outcome (possibly negotiate with the provider and repeat the process)
Technology may not be the correct solution for all of these steps, immediately at least. The process will also need to fit into the provider's workflow. This can be much different between hospital and office settings (and EHR used).
Dave deBronkart (Jan 24 2021 at 19:36):
Thanks to all for their inputs. I have zero opinion of what it should do - I just know two things:
- We (the public) NEED to enable app-automating the submission and tracking of error fixes. We out here do not care how it gets done. It can be 99% manual OUTSIDE of the submission and tracking process.
- I want it to get adopted, so I want it to be worth the effort for system & app vendors to do.
Again, though non-technical, I'd again say I for one would be entirely okay with keeping our hands out of what happens outside the above.
We (as a society and as individuals) do need to ensure that a truthful record of the dialog exists and can be verified.
Virginia Lorenzi (Jan 24 2021 at 22:59):
@Josh Lamb Jump right in the water is warm. I think that the difference between office setting and hospital setting is important. In a shared medical record where multiple clinicians are responsible for your chart which is very much true for the inpatient hospital setting a mediator often plays a role - example, Health Information Management aka Medical Records. And the error could be an IT error or admitting error, etc. And bad data can be buried and repeated in past visits where the treating clinician is focused on documenting/currenting the current visit.
Josh Lamb (Jan 24 2021 at 23:44):
How about we let patients comment against a fhir ID. Thiz would look like chat functionality and would rely upon free text, to keep things simple. The provider and patient can reply dialog directly against the data used to support decision making.
This should be simple to implement if the provider and patient can see the same data.
Josh Lamb (Jan 24 2021 at 23:46):
Reading the other thread, a task sounds perfect to me. Just assign it to the data in question.
Virginia Lorenzi (Jan 25 2021 at 00:01):
@Josh Lamb so many threads and ideas out there, what were you referring too?
Virginia Lorenzi (Jan 25 2021 at 00:02):
Have no idea what "comment against a FHIR id means". Please explain - thanks!
Josh Lamb (Jan 25 2021 at 00:05):
When you are viewing data that needs corrected, the application showing the data will know the exact way to identify the data (so provider and patient are talking about same thing).
Josh Lamb (Jan 25 2021 at 00:07):
From a patient perspective they will see an error and send the provider a note about the error. The provider can reply directly against the data too.
Josh Lamb (Jan 25 2021 at 00:09):
The mechanism used to communicate a patient's comment can vary but @Lloyd McKenzie seemed to be discussing tasks for this, but maybe I misunderstood.
Josh Mandel (Jan 25 2021 at 01:25):
There's a lot of history here @Josh Lamb :-) Overall I think it's safe to say that the scope for an initial IG is allowing corrections in general rather than focusing on how to correct errors in a specific FHIR resources. (E.g., errors may span many resources, or may be about aspects of a record not captured in fhir at all). If you're brave and looking for diversion @Josh Lamb you could probably spend a couple of hours scrolling backwards in this stream.
Lloyd McKenzie (Jan 25 2021 at 03:03):
A separate Task for each comment is certainly possible, but seems like overkill. If it's not asking for something, it's not really a 'Task' and all of the notions of status, owner, etc. wouldn't make much sense. If we're just looking for general comments, I think Task.comment is probably enough - it captures who, when and what was said. Do we need more than that?
Bart Carlson (Jan 25 2021 at 03:32):
"Lloyd McKenzie10:03 PM
A separate Task for each comment is certainly possible, but seems like overkill. If it's not asking for something, it's not really a 'Task' and all of the notions of status, owner, etc. wouldn't make much sense. If we're just looking for general comments, I think Task.comment is probably enough - it captures who, when and what was said. Do we need more than that?"
It seems like a logical and straightforward way to get something adopted sooner than later. We can always add additional functionality in future releases.
Dave deBronkart (Jan 25 2021 at 12:42):
Lloyd McKenzie said:
If it's not asking for something, it's not really a 'Task' and all of the notions of status, owner, etc. wouldn't make much sense.
So astute / sharp / perspective! So glad to have you in these threads, @Lloyd McKenzie - the Patient Empowerment WG's first incursion into health data workflows and quality.
I'll note, too, that the Patient Contributed Health Data project is another expression of "The provider isn't the only source of clinically relevant information."
Josh Lamb (Jan 25 2021 at 15:42):
Is the goal to build out a workflow that will allow providers and patients to collaborate on chart corrections?
I agree that Task is too complex for phase one..do we have a phase one defined yet?? :-)
The communication resource seems ideal. We can use the following fields to allow patients to comment on an FHIR resource:
subject: Focus of message--The patient or person who the data is about
basedOn: The data (diagnosis, procedure, lab result, etc) that the communication is about
status: This can be used to communicate if the communication request is open or not.
sender: Who sent the communication (can be patient, provider, etc)
payload: A communication can contain multiple payloads:
1.) can contain the suggested correction;
2.) can contain the free text message the patient/provider wanted to communicate
Here is the FHIR definition of the communication resource:
This resource is a record of a communication even if it is planned or has failed. A communication is a conveyance of information from one entity, a sender, to another entity, a receiver. The sender and receivers may be patients, practitioners, related persons, organizations, or devices. Communication use cases include:
A reminder or alert delivered to a responsible provider
A recorded notification from the nurse to the on-call physician (or any other specified person) that a patient's temperature exceeds a value
A notification to a public health agency of a patient presenting with a communicable disease reportable to the public health agency
Patient educational material sent by a provider to a patient
Unable to deliver lab results to ordering physician
Josh Mandel (Jan 25 2021 at 15:44):
@Josh Lamb please start by reading http://build.fhir.org/ig/HL7/fhir-patient-correction/index.html -- the use cases and examples at least, to understand scope.
Josh Lamb (Jan 25 2021 at 15:45):
Thx, not sure where to start digging in.
Josh Lamb (Jan 25 2021 at 15:47):
I love workflows btw, that is why I picked this topic. We can flow all of these use cases out and make sure the resource status and constraints take everything into account. I do not think this will have to be extremely complex.
Josh Lamb (Jan 25 2021 at 15:48):
I started by using Task, which is in the current IG, but people are saying it is too complex. I am not sure how much of this IG is up for debate. We can make task or communication work.
Lloyd McKenzie (Jan 25 2021 at 15:50):
Communication doesn't give a good way of querying for 'current state' - it's really just taking emails to a provider and sending them over FHIR.
Josh Lamb (Jan 25 2021 at 16:08):
Patients can view that the correction has occurred by checking the source data again. Since the Patient Access API is the consumer-directed FHIR interface I am assuming the data originally was pulled from this API.
Health insurance providers, labs, and hospitals will not have a mechanism to accept inbound communications from a consumer device. I am not sure how the corrections will physically make it to the data producers system.
Lloyd McKenzie (Jan 25 2021 at 16:12):
Checking the source data isn't good enough. Requesting a change kicks off a process that can take weeks - or months. Patients want to have a sense of where their request is at even if the data isn't yet fixed.
Lloyd McKenzie (Jan 25 2021 at 16:13):
Patients can already email their providers asking for a correction (or phone or send a letter). The idea with the implementation guide is to come up with something that is better than that.
Josh Lamb (Jan 25 2021 at 16:15):
I will create a picture of the flow I am imagining. It is more than just email.
Josh Lamb (Jan 25 2021 at 17:19):
here is a rough outline of the flow I am imagining:
Blank-diagram-1.png
Lloyd McKenzie (Jan 25 2021 at 17:22):
That looks pretty much like "send an email, get an email back". How do you check for status? How do you update the request? How do you capture supplemental data for the request and adjust it?
Josh Lamb (Jan 25 2021 at 17:36):
POLLing (know its not great).
Josh Lamb (Jan 25 2021 at 17:37):
As an implementer, there will not be a single workflow that will support all data correction use cases. I can only see a highly generic implementation working, unless we get into fine-grained use cases (like here is an IG to update smoking status).
Josh Lamb (Jan 25 2021 at 17:39):
Letting patients comment directly against data via basic chat functionality is something. Maybe we can get more but as an implementer, I would struggle to support a large number of complex use cases initially.
Josh Lamb (Jan 25 2021 at 17:44):
Do we have providers/clinicians who can help provide feedback on the workflows they prefer? I know @Virginia Lorenzi shared a lot of great insights in another thread.
Lloyd McKenzie (Jan 25 2021 at 17:45):
But what would you poll on? If you're just using Communication, there's nothing that gets updated. There's no resource that would represent the 'status' of the request.
Lloyd McKenzie (Jan 25 2021 at 17:45):
(Note that polling or subscriptions would be used with Task - but with Task there's something that will be updated that you can query to see current state.)
Josh Lamb (Jan 25 2021 at 18:01):
I put Task in the diagram. I liked your idea earlier about adding messages to a task and the task has better status (and is pretty extensible).
Josh Lamb (Jan 25 2021 at 18:03):
the consumer app would poll based upon task id. or they would poll (if they lost the id) by status (and subject).
Data producers would have to poll by status (and use it as a work queue).
Lloyd McKenzie (Jan 25 2021 at 18:04):
Ok, so you're just talking about using Communication for the "emails about" bit, not for the base "request to please change"?
Josh Lamb (Jan 25 2021 at 18:05):
Yes, i am imagining that communication requests would carry the message, the task would carry the intent.
Lloyd McKenzie (Jan 25 2021 at 18:10):
I don't understand. There's zero value in wrapping a Task in Communication. If you want to create a Task, just post the Task. Communication is NOT a substitute for FHIR messaging.
Josh Lamb (Jan 25 2021 at 19:18):
Trying to use task for this, as per the decisions already made within this group, as i see in teh IG.
Task can meet this need : "Another example would be a Task that requests fulfillment of a CommunicationRequest to be performed between various actors."
Josh Lamb (Jan 25 2021 at 19:20):
I do not have a strong opinion on the FHIR resources used, but the options seem limited to communication requests/responses within a task. What other option do you have? I do not think that Payers and providers will universally begin accepting FHIR messaging communications. We have a patient access API, and we will have to modify it to accept inbound communications at some point anyway.
Lloyd McKenzie (Jan 25 2021 at 19:41):
My leaning is, in the short term, to support Task only. Any back-and-forth communication is done just using Task.note. If, in the future, we want to support a "secure email equivalent" that could point to Task (or other things), that could certainly be built on top if it were deemed useful.
Josh Lamb (Jan 25 2021 at 19:44):
I like that, in general, if you suggest anything simpler than I suggest I will be in favor (as long as it's not throwaway).
Virginia Lorenzi (Jan 25 2021 at 21:20):
I support that and note has author and timestamp. But @Jeffrey Danford had some reservations. Also would like @Vassil Peytchev opinion. Do not want to lose the dream on secure chat via FHIR which I think that Communication resource could help with but according to @Vassil Peytchev the world is not ready? @Debi Willis
Debi Willis (Jan 25 2021 at 21:35):
Lloyd McKenzie said:
That looks pretty much like "send an email, get an email back". How do you check for status?
Communication has a status: preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown
Couldn't we use that for a patient to check the status?
@Lloyd McKenzie @Vassil Peytchev @Jeffrey Danford @Josh Lamb @Virginia Lorenzi @Dave deBronkart
Josh Lamb (Jan 25 2021 at 22:14):
The communication statuses imply a workflow sequence. We will need to define our own statues sequence and limit the available options to the list of values we use in our workflow. We may want to remove some of teh options that are not final. For example, all of the following statues indicate some flavor of "not-complete": preparation | in-progress | not-done | on-hold | stopped | unknown
Here is a technical suggestion to perform the searches:
To Get data for all patients, if the status is 'not-done'
GET [base]/Communication?recipient=Provider/123&Status='not-done' (or the desired status)
To Get data for one patient, if the status is 'not-done'
GET [base]/Communication?subject=Patient/456789&Status='not-done' (or the desired status)
A patient can get the status by:
GET [base]/Communication?subject=Patient/456789&Status='not-done' (or the desired status)
Everyone can get a Communication by:
GET [base]/Communication/123
Debi Willis (Jan 25 2021 at 22:22):
@Josh Lamb I was responding to @Lloyd McKenzie question about "How do you check for status?" when using communication. Communication has a status.
Josh Lamb (Jan 25 2021 at 22:30):
Thanks, and sorry. I am not sure why I wrote the examples using tasks. Updated them above.
Debi Willis (Jan 25 2021 at 23:59):
Lloyd McKenzie said:
My leaning is, in the short term, to support Task only. Any back-and-forth communication is done just using Task.note. If, in the future, we want to support a "secure email equivalent" that could point to Task (or other things), that could certainly be built on top if it were deemed useful.
@Lloyd McKenzie Do you have any concern that if both the patient and the covered entity are writing to task.note that a sloppy consumer app might accidently overwrite task.note and the current "version" of the task will not contain all the information...causing both the provider and patient app to have to look through the history of all previous versions of the task to make sure nothing was lost? This was an issue what was brought up in the connectathon. This is the concern with both parties updating a single task. Both have "write" rights and can write over each other accidentally.
@Jeffrey Danford @Lisa Nelson @Virginia Lorenzi
Lloyd McKenzie (Jan 26 2021 at 04:58):
Communication.status reflects the status of "was this information delivered" - it has nothing to do with "is what I asked for done?" because Communication doesn't reflect the act of asking for anything, it only reflects the act of sharing the specific content specified with the end recipient.
Lloyd McKenzie (Jan 26 2021 at 05:01):
I have zero concerns about accidental overwrite - because you can guarantee that the system performing the update has the current record before they're allowed to make a change. It's certainly possible for them to deliberately delete data, but our specification can (and should) set expectations about the server prohibiting changes that we deem improper. (We'll have to explore what happens if a note is submitted that legitimately does need to be deleted - e.g. because someone said something inappropriate or disclosed data that shouldn't have been shared - though that will require a deeper cleaning than a mere update because the data might still be accessible through history.)
Josh Lamb (Jan 26 2021 at 06:29):
The status has to mean more than a boolean delivered or not delivered or I cannot see why there are 8 different statuses.
Josh Lamb (Jan 26 2021 at 06:30):
If it is not delivered, how will we even see it? We are not using messaging.
Josh Lamb (Jan 26 2021 at 06:32):
Status is always complete makes sense to indicate delivered.
Lloyd McKenzie (Jan 26 2021 at 14:42):
Communication is used to log the exchange of data. If you've mailed a letter, you know that communication has been started, but you don't know yet that it's been received. Communication can also be an ongoing process - e.g. "Share the the patients vital signs with organization X for the duration of the encounter". I agree that for many uses, Communication.status will be only 'completed'. The other statuses are there for those situations when they make sense. But the statuses reflect the status of the communication, not anything else.
Lloyd McKenzie (Jan 26 2021 at 14:42):
(If you want to submit a change request suggesting that an implementation note be added expanding on the use-cases for the statuses, that's not a bad idea.)
Josh Lamb (Jan 26 2021 at 17:25):
Can I help organize or put a flow around anything? I am not clear on what direction the group is leaning.
Josh Lamb (Jan 26 2021 at 17:26):
This is the first IG for this group, we can make it successful if it meets the patients needs, is extensible, and is easy to implement.
Josh Lamb (Jan 26 2021 at 17:27):
Also, these text discussions are great, but I should probably shy away till I get into the workgroups.
Debi Willis (Jan 26 2021 at 20:17):
Our first meeting is this evening at 6 PM ET. Please join us.
Abbie Watson (Feb 11 2021 at 02:42):
Catching up on some backlog.
My general $0.02 from the provider side on fielding these requests and being responsible for making the correction, is that the overall conversation is under-appreciating the role that the PDF document server has (and by extension, DocumentReference). When we talk about the healthcare industry propping up the FAX industry, keep in mind that a FAX can be hooked up to a PDF printer. So FAX messages can be routed directly to the PDF server. Anything paper or FAX related is effectively managed by a DocumentReference ID, and that includes any workflow that can be expressed as a series of pages of paper. So a Morgan Gleason letter. A medical malpractice subpoena. An IRB investigation. Or a verbal phonecall that is written down on a notepad. All can be expressed and tracked via a PDF document server. Workflow sucks and people complain about click count because it's not optimized for their particular workflow, but most any employee can learn it with training and willingness to click through a bunch of menus and link the appropriate documents together.
Generally speaking, errors occur in a power law distribution. Meaning that there are some types of errors, such as left/right errors and wrong-patient errors, that are orders of magnitude more common than other errors. Administrative errors such as dictating on the wrong patient can often be resolved by a manager without needing clinician co-signature. Upcoding is a bit more complicated, and depends on whether it was billing or clinical who did the upcoding on whether the manager can correct. An error that's truly clinical (including left/right) gets complicated, because then it's no longer an issue of the patient's record, but of the practitioner's reputation and license at stake. So there has to be clinician sign-off on the correction.
In practice, the requests for error corrections come in all forms. Post-it note is extremely common format within a department, especially among the help desks before/after they get converted into the ticket management system. Fax, emails, and certified mail are preferred and generally the official ways to communicate with a department. In person verbal complaints and phone calls also generally have to be supported (although its common for some workers to want as little to do with patients as possible, and they hide/sequester themselves). Sometimes the patients drop off the incorrect errors, and will deliver a CD or thumbdrive with the incorrect data or corrected data or a second opinion. Obviously, it becomes extra difficult when the patient speaks a foreign language (I've had to field requests in sign language, yiddish, spanish, and other languages.). Interdepartmental correction requests obviously have an extra layer of difficulty, when data is stored in an ancillary system that medical records doesn't have control of. That's when a manager or patient advocate is needed to follow up on the case; more so if it's inter-hospital or is historical (greater than 90 days, 1 year, 7 years, 17 years).
What the Task resource is really trying to do (imho), is replace/standardize the ticket management systems, not the EHR.
Lloyd McKenzie (Feb 11 2021 at 03:52):
I love that analogy. I completely agree that Task is essentially a FHIR interface over a ticket management system. It gives an ability to submit the ticket, add comments to it and monitor its progress. The question of whether to handle submission by phone, email, "FHIR email" (aka Communication), or "FHIR Fax" (aka DocumentReference) vs. Task really boils down to whether we're just trying to provide a mechanism to automate initial delivery of the raw data for the request that someone will later key into a 'private' ticket management system, or whether provider organizations are willing to open the interface to the ticket management to allow a patient to fill it out directly and monitor the ticket as it flows through the system. (Thereby significantly reducing the various phone calls, emails, etc. from patient's wanting to know the 'status' of their request, as well as eliminating all of the re-keying of the requests themselves and many of the subsequent back-and-forth communications.)
When an organization opens up their ticket management system to allow direct submission of tickets from "customers", there's a trade-off. Trained help-desk personnel typically know how to fill out tickets better than customers do and can also solicit information they know will be needed downstream, while the clients might not provide it initially. And there's still a help-desk function of performing initial triage. However, if the client-facing ticket interface is well designed, switching to a client-facing model can save resources and also significantly improve satisfaction (provided that insight into why a ticket is stalled results in insight/acceptance rather than frustration).
John Moehrke (Feb 11 2021 at 13:40):
I don't disagree. The Task as we are describing it is just an interface. I however think that we are over-engineering it to the point that our solution will be seen as overly complex and requiring too many internal process changes. I simply favor an approach where we start with something minimally viable and work toward Task in future generations.
Lloyd McKenzie (Feb 11 2021 at 15:22):
Minimally viable is "phone your provider". There are three possible objectives for our initiative:
- Standardized 'entry point' to kick off the process (so an app can do the kick-off regardless of system, provided it knows the base URL for that system)
- Support the flow of back-and-forth communication that tends to occur as a result of the request in a 'secure' way. (This could be just providing secure communication in general.)
- Allow patients to monitor the progress of their request and make certain updates to the request as it progresses
I had understood #3 as being a priority and also in-reach. If that's not true, then Task is not necessary.
Josh Mandel (Feb 11 2021 at 16:27):
There's a subset of (3) that I think is useful and practical: monitor whether the request has been completed (and when). This allows patients to know when deadlines aren't being met and escalate out of band, even if there's no in-band mechanism to "make certain updates".
Josh Lamb (Feb 11 2021 at 20:54):
Does the task need to account for #3? It can be an independent view of the source data instead (using existing API). Or am I missing something?
Lloyd McKenzie (Feb 11 2021 at 21:06):
Task gives the mechanism to expose the status over FHIR.
Josh Lamb (Feb 11 2021 at 21:08):
got it, just the status
Lloyd McKenzie (Feb 11 2021 at 21:09):
Well, it'll expose a lot of other things too. but it's one of the few mechanisms that allows you to query for status.
Debi Willis (Feb 11 2021 at 21:44):
Please remember to submit your ideas onto the google doc that will be used in our meeting to discuss pros/cons of the different options. Please refrain from correcting ideas that someone else had. Just add your pros/cons to the list if you don't see it already addressed by someone else. We will use this as a base to narrow down the choices as we move forward. Here is the link to the doc: https://docs.google.com/document/d/1Q_Vln_Vb21JVu1rPgwPZ68_IyTlktuuSGGJLm9kGSY4/edit?pli=1#
Vassil Peytchev (Feb 11 2021 at 21:47):
I don't see people answering the Doodle poll for when the next meeting will be: https://doodle.com/poll/w8m8akcxg46vg887?utm_source=poll&utm_medium=link
John Moehrke (Feb 11 2021 at 21:57):
first I am seeing the doodle poll
John Moehrke (Feb 11 2021 at 21:58):
next week is the IHE meeting. I can't make either of the two times offered
Debi Willis (Feb 11 2021 at 22:08):
Lloyd McKenzie said:
I had understood #3 as being a priority and also in-reach. If that's not true, then Task is not necessary.
@Lloyd McKenzie I don't think we ever stated that allowing a patient to monitor the progress of their request was a priority. A bi-directional conversation was/is definitely a priority. Using Task to enable the bi-directional conversation gives us the additional benefit of providing the task status, but it was/is not a priority. Task does give us some nice things. But the ability to give the patient a status is not a requirement. I am also not saying that scratches Task off the list. I am just clarifying an assumption, moving your #3 from "must have" to "nice to have" is important in the discussion.
Lloyd, you shared something really important in the Patient Empowerment Workgroup meeting today: Looking at all the pros and cons of the different options against what our priorities are, and the feasibility of implementing each resource option will help identify the most appropriate choice. I added "Scope" and "Feasibility" to the the top of the google doc so others can add comments.
@Jeffrey Danford @Vassil Peytchev @Drew Torres @Isaac Vetter @Jenni Syed Getting feedback from the EHR vendors, especially in the "Feasibility" section is critical. Please share your thoughts here: https://docs.google.com/document/d/1Q_Vln_Vb21JVu1rPgwPZ68_IyTlktuuSGGJLm9kGSY4/edit?pli=1#
Debi Willis (Feb 11 2021 at 22:12):
Vassil Peytchev said:
I don't see people answering the Doodle poll for when the next meeting will be: https://doodle.com/poll/w8m8akcxg46vg887?utm_source=poll&utm_medium=link
Thanks for the reminder to everyone! This next meeting will be really important because we will be working through the pros/cons of the googledoc: https://docs.google.com/document/d/1Q_Vln_Vb21JVu1rPgwPZ68_IyTlktuuSGGJLm9kGSY4/edit?pli=1
Vassil Peytchev (Feb 11 2021 at 22:21):
I don't think we ever stated that allowing a patient to monitor the progress of their request was a priority. A bi-directional conversation was/is definitely a priority. Using Task to enable the bi-directional conversation gives us the additional benefit of providing the task status, but it was/is not a priority.
If you want the ability to formally describe, distinguish and act upon the different outcomes of a request for corrections, you are stating that monitoring the progress of the correction request is the highest priority. If that is not the case, then this effort becomes to define a general solution for patient-provider communications in FHIR - which is very valuable and important, but a very different type of effort.
Debi Willis (Feb 12 2021 at 21:51):
If you think of the way it is done now with letters, faxes, and phone calls...there is no monitoring of the progress of the request. The most important aspect of this process is the conversation...the ability for each party to understand each other and share important information (which may take multiple threads). When it was recommended we try Task, we had the added bonus of monitoring a request. But, monitoring the progress was not the real focus. And with task, we really don't have an accurate view of the status of the request because we will likely have multiple changes requested by the patient but only one task status.
When looking at what we are trying to accomplish, we should not elevate the ability to monitor the task over the ability to have a secure conversation and sharing of files, images, etc. If we had to "score" the different resources to determine which is best, the criteria (in order of importance) would be: 1) bi-directional communication 2) sharing of files 3) monitoring task progress (optional). If you review the HIPAA guidelines (which is what the clinics must follow), there is no requirement for the patient to be able to monitor the task progress within the clinic but there are many pieces of information that are required to be communicated to the patient throughout the process. We are trying to build a secure FHIR-based model to duplicate the HIPAA implementation specification. It think somewhere along the road the monitoring of the task became a "must" when it never should have been interpreted that way.
Vassil Peytchev (Feb 12 2021 at 22:14):
I think I am not explaining this clearly - "monitoring of the progress" doesn't mean a view into the internal process of handling the request.
What I am trying to explain is that the ability to describe, distinguish, and act upon the different outcomes of a request (i.e. approved, denied, partially approved) is what I mean by "monitoring of the progress". Just that one thing - using FHIR to submit a request for corrections, and to understand that at some specific point (after possibly many other interactions between the patient and the responsible entity) the request has been approved, partially approved, or denied.
Is the above considered optional?
Lloyd McKenzie (Feb 12 2021 at 22:27):
Put another way, are we comfortable with passing arbitrary blobs of text back and forth with no 'discrete' elements to support automation. I.e. you can type whatever you like whenever you like, no constraints based on where you're at in the 'lifecycle' of the request. Essentially, just a FHIR interface for arbitrary email.
Debi Willis (Feb 12 2021 at 23:21):
Yes, monitoring the request is not a view into the internal process of handling the request. That is outside of our scope (as it should be). But, if the ability to monitor the task is thought to be that important, the problem that several requests could be included within a single task and may have different outcomes is not solved with task. In cases like this (which may be most cases), the benefit of the task status is diminished because it cannot accurately describe all the outcomes of the requests.
My understanding is there is the ability to have discrete elements in Communication with payload. Is that an accurate understanding?
There is also a status with Communication (preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown) that is being overlooked in the Zulip conversation.
The request for corrections could be coded to distinguish it from other communications coming in. Just like in the Epic portal. The user is allowed to pick a topic.
The consumer app would be able to link the specific conversation IDs together in the UI. They would not be arbitrary blobs of text.
Again, I am not saying we need to throw out Task as an option. I am simply bringing the focus back to the most important needs.
Lloyd McKenzie (Feb 12 2021 at 23:30):
Not really, no. Communication allows you to say "send this lab report, this consult note and these vitals", but it's all just "send stuff". There's no ability to assign distinct meaning to any content other than what's already intrinsic to the content. You can't send 3 lab reports and computably designate one of them as "baseline" and the other two as "for comparison". (Though you could send a text note that said "I'm sending you a baseline and 2 others for comparison" and a human would presumably be able to figure out which was which based on dates.)
So, in our use-case, you can't have separate elements called "reason for change" or "details of change" or "notice of disagreement" - unless you decided to transmit a resource that captured that content as discrete - which may tie into @John Moehrke's proposal to use QuestionnaireResponse. You could attach a single QuestionnaireResponse to a Communication and have discrete data within that.
John Moehrke (Feb 12 2021 at 23:32):
yes
Debi Willis (Feb 13 2021 at 15:43):
Thank you @Lloyd McKenzie . I would like to understand this better. Can you compare what is possible to send in Task.input to what is possible to send in Communication.payload? Could we send a CCD or image via Task.input and via communciation.payload? What is possible to send in Task.input that is not possible to send in communication. payload?
Can you give examples of when the different communication statuses might be used? (preparation | in-progress | not-done | on-hold | stopped | completed | entered-in-error | unknown)
Lloyd McKenzie (Feb 13 2021 at 16:02):
Task.input is a name/value pair. You specify a code that indicates the meaning of the input, an then specify the value of the input (which could be anything at all). With Communication, you can send send strings, attachments or references to resources, and you can't "name" them with a code. So all content sent is undifferentiated except by data type. (It's not allowed to assign meaning to the order in which the payload repetitions appear.) You can certainly send a CCD or image either way, but only with Task can you computably say what's to be done with it. Task also lets you send codes, integers, dates, ranges - any data type you wish. As an example, Task would let you communicate a date that a change needs to be applied by as a discrete computable element (that might drive prioritization within the target health system). With Communication, the date would need to be part of the body of string or PDF (or maybe in a QuestionnaireResponse, assuming the receiver knows how to do something computable with that).
The gist of Task is "please do". The gist of Communication is "for your reading pleasure".
preparation: I'm getting ready to share this information with recipients
in-progress: I'm the process of sharing information with recipients (we'd probably make this a fixed value if we use Communication)
not-done: I chose not to share this information with the specified recipients
on-hold: I started to share this information with recipients, but have temporarily quit
stopped: I started to share this information with recipients, but have permanently quit
completed: The specified information has been delivered to the specified recipients. In theory, the recipient could update the Communication received to 'completed' to say that it had actually been read by all recipients. Completed has nothing to do with any action other than "we read what was sent". Completed would also be the status of any Communications recorded retrospectively (notes about phone calls, faxes, external emails) that should be part of the record.
entered-in-error: This instance describes something that never happened, but someone may have acted on the belief that it did
unknown: My system has no idea whether the communication happened or not - primarily for exposing legacy data
Lloyd McKenzie (Feb 13 2021 at 16:02):
In short, most of the statuses on Communication are unlikely to be relevant to our use-case.
Vassil Peytchev (Feb 13 2021 at 16:48):
The request for corrections could be coded to distinguish it from other communications coming in. Just like in the Epic portal. The user is allowed to pick a topic.
I think there may be a confusion between what the patient-facing user interface is, vs. what the FHIR interface to the responsible entity is. Of course, for the patient it makes most sense if the user interface is familiar, as in any other patient-provider communications. This has very little to do with the shape of the FHIR interface exposed by the EHR. In the Epic patient portal example, the patient messages end up in many different places in the EHR, based on the topic/purpose of the message. None of them are currently exposed as Communication resources.
Lloyd McKenzie (Feb 13 2021 at 17:37):
@Vassil Peytchev How are they currently exposed (if exposed at all)?
Vassil Peytchev (Feb 13 2021 at 22:29):
Patient/provider messages are not exposed as FHIR resources. The outcome of certain types (e.g. a MedicationRequest for refill requests) would be exposed.
Bart Carlson (Feb 14 2021 at 00:26):
Would it be possible to create illustrative mockups of each scenario being described prior to our next meeting? I'm thinking the old adage "a picture is worth a thousand words" might help all of us better understand all the options.
Virginia Lorenzi (Feb 26 2021 at 07:01):
Thats a good idea Bart. It might be good to reduce the options somewhat first because there seems to be redundancy.
Last updated: Apr 12 2022 at 19:14 UTC
