Stream: patient empowerment
Topic: Awkward Conversations with Task
Virginia Lorenzi (Jan 15 2021 at 04:16):
@Lloyd McKenzie @Vassil Peytchev @Josh Mandel @Lisa Nelson @Debi Willis So in the connectathon track today, we noticed that there is alot of correspondence between the provider and the patient.
Example: patient makes a request for record to be corrected, claiming they quit smoking.
Provider responds - please provide us with the date you quite smoking
Patient responds with the date
Provider reviews and decides to correct the record starting at that date based on clinician review. They tell the patient this and also ask them who they would like the provider to notify (clinicians and their contact information)
Patient responds with two care team members and their contact information
Provider corrects record and then sends a report showing evidence of the amendment.
We know that using Task, inputs and outputs would be used and it would all be the same Task. There was concern expressed that should inputs or outputs be removed or how to read them - which goes first - and what if its written over and lost.
Then we started to talk about how for a dialogue which at least this component of the process felt like, Communication seemed to perhaps make more sense with each side sending a Communication resource linked to the one it is responding to.
Wanted your thoughts.
Virginia Lorenzi (Jan 15 2021 at 05:07):
I have entered the following Jira Issue on the FHIR Core Spec: https://jira.hl7.org/browse/FHIR-30393 asking that the definition of Communication be expanded to include actual conversations @Jeffrey Danford
Lloyd McKenzie (Jan 15 2021 at 05:57):
I think there's two things happening. The underlying structure is a "please do" - which is Task. Associated with that, there may be some intermediary back-and-forth Communication. The same would hold if a patient were making an appointment. They might book the appointment. There might be a bit of back-and-forth that's pure ad-hoc communication. (There could also be some Tasks assigned to the Patient - e.g. fill out these forms, get this lab order filled.)
If all you have is communications, then there's no "to do", no place to capture status of the request, no way to formally say "accepted/refused" or to provide a coded reason, no way to easily query to find when the request was initiated and when it was completed to determine compliance with regulated timeframes, etc.
now - if it turns out that the reality is that systems don't have any of those capabilities and have no intention of developing them, then Communication (i.e. 'secure email over FHIR') may be all you've got. But it's certainly not going to satisfy the use-case as it was defined.
Lloyd McKenzie (Jan 15 2021 at 06:00):
The notion of having 'communications about things' is also a useful thing to pursue - patients might have questions about prescriptions, their care plans, various other things. Providers might also initiate communications. E.g. "How are things going with that new drug we started you on last week". Such Communication instances would link to the Task/ServiceRequest/MedicationRequest/Appointment/etc. they're dealing with. But having the ability to have ad-hoc communications doesn't do away with the need for prescriptions, tasks, appointments, and all of the other resources.
Virginia Lorenzi (Jan 15 2021 at 07:32):
I guess it feels a bit like V2 repeating field in the inputs and outputs. Are other people using inputs and outputs for other use cases? We could next in Communication resources or have them associated in some way but that feels like overkill to me.
Dave deBronkart (Jan 15 2021 at 12:31):
It will be valuable to review the recording of that check-in session (Jan 14, 1-2 pm PT / 4-5 pm ET) when it's available.
Josh Mandel (Jan 15 2021 at 14:14):
Definitely agree that getting anything done in the real world requires a bunch of back and forth discussion! The common model for this in task tracking systems from Zendesk to Jira and beyond is to attach a discussion thread to the task, and indeed that applies here. functionally, the important thing is for anyone to be able to determine (quickly) an ordered list of all the messages in the thread up to this point, and for each message to know who sent it and what it says.
Out of all the designs discussed above, the one thing I would definitely avoid would be trying to interleave inputs and outputs to capture the discussion. If they are all mentioned in the Task, they should be in just one inputs array.
The alternative is for each message to point to the previous message in the thread, with something like Communication.inResponseTo.
Dave deBronkart (Jan 15 2021 at 14:31):
Josh Mandel said:
Definitely agree that getting anything done in the real world requires a bunch of back and forth discussion! The common model for this in task tracking systems from Zendesk to Jira and beyond is to attach a discussion thread to the task, and indeed that applies here....
Is that feasible and allowed, under the rules for EMR changes? (Not sure what you mean by "attach a thread" in this context - a pointer, or the actual dialog? My impression from our expert panel yesterday is that the entire dialog needs to be embedded in the EMR.)
Josh Mandel (Jan 15 2021 at 15:09):
I'm not making any claims about where it lives or who is responsible for it {comma} I'm just saying that oftentimes before you can get a task done you need to have a back and forth conversation about exactly how.
Lloyd McKenzie (Jan 15 2021 at 16:49):
I'm not advocating for the conversation to be handled as Task.inputs/outputs. Ad-hoc conversations are appropriate to use Communication for - and you could link the Communication to the Task/Request/whatever the Communication pertains to. However, the fact that there may be ad-hoc communication about something doesn't mean that the base request should be handled by Communication.
Debi Willis (Jan 15 2021 at 18:37):
The way the IG was designed was to capture all conversations in the Task.input and Task.output fields. The problem is there is only one task from the initial request to the final answer of "denied" or "accepted". There may be many conversations back and forth between those two points. With the communications all being in the input and output fields and the task simply being updated, this doesn't provide a clean conversation. With communication, we can create a new resource each time and point to the prior communication. We would not need to update the previous communication (as we need to do for task). After listening to the panel yesterday, it sounds like there is a lot of communication going on. This could get very very messy in the single task.
Debi Willis (Jan 15 2021 at 18:48):
Some thoughts brought up around other ways to solve the problem: The initial request could go as a communication. When the clinic gets the communication, they can create a task (or multiple tasks if the patient is requesting changes to multiple items). They could reply to the communication with the ID of the task (which may contain sub tasks). Once all tasks are complete, a final communication would be sent to the patient letting them know the task(s) is complete.
A more simple way is to see if communication by itself can do this workflow. It is all in discovery mode right now.
Biggest concerns with task by those trying it out right now:
- Conversations going back and forth in a single Task will be hard to manage.
- There may be several requests from a patient and each of their statuses may be different (accept some, deny some, need more time on others)
- Updating a task throughout the process of initial request to final decision seems a bit risky when there is a need to retain all past conversation.
Any ideas on whether task can solve these issues?
Lloyd McKenzie (Jan 15 2021 at 19:14):
My recommendation is to have the initial request go as a Task - because it is a request. You're asking specifically for something to be done and that's going to be the link point for all future conversation. That Task will have a status that reflects whether it's been accepted or not and whether it's been actually completed or not. Communication doesn't give you that. All subsequent 'discussion' can happen via Communication instances that reference the Task (unless they are, themselves, requests for action, in which case you might have sub-tasks or independent tasks).
Communication doesn't provide any workflow. It's like emails. You just have emails back and forth. There's no status. There's no linking of them other than they might share the same topic.
Lloyd McKenzie (Jan 15 2021 at 19:14):
Also, "conversations going back and forth" can be true for all sorts of other things, not just Task.
Vassil Peytchev (Jan 15 2021 at 19:28):
The way the IG was designed was to capture all conversations in the Task.input and Task.output fields.
I think there need to be several stages in developing the IG before you can "capture all conversations". The first stage is to get some "scaffolding" up specifically about formal correction requests, and that is where the efforts in the IG should be focused. This includes the ability to state the request, track the state of the request, and have the outcome of the request (including the additional steps for disagreement). The actual "conversations" at this point should be considered out of scope, and would be addressed in subsequent releases.
Besides the obvious benefit of having a tractable well-defined problem with clear boundaries to solve, approaching the end goal in stages will allow for cross-pollination and convergence with other projects both in this group and elsewhere. The Patient Contributed Data, for example, also has to address "conversations" - having a common approach will benefit both projects.
Virginia Lorenzi (Jan 15 2021 at 19:36):
Lloyd - its not just the adhoc communication.
It seems that the communication with the patient is a key part of this Request For Corrections flow. There appear to be 2 types that occur in today's manual process:
-
Formal communication which needs to be stored and represents the legal requirements and currently are documents:
For HIPAA this is:
--- The Request for Correction (currently a form is filled out)
--- A Formal Acceptance of the Amendment (sample letters out there)
--- Formal Denial of the Amendment (often a form)
---Formal Disagreement Letter from Patient (often a form)
--- Formal Rebuttal from provider (no HIM person I have talked to have ever seen this used) -
Less formal communication such as requests for status or requests for clarification
--- example: when did you quit smoking?
--- I quit last year
--- I want a status on this (patient can always call up - seems appropriate to log that)
Which input is linked with which step? which output is linked with which step?
Logging of the Communication seems appropriate whether its by mail, phone call, or via FHIR resource X.
Someone today compared it to Customer Service Management and I have compared it to Service Recovery.
It seems Task history becomes really important as well. @Lisa Nelson was feeling weird about the patient and provider sharing and updating the same Task resource.
Our hope is to have a very simplistic solution on either side with opportunity to scale up into more structured richer interoperability that can trigger semi-automation. I was hoping in the simplest solution one would not having to include any additional resources such as Tasks, Communication, DocumentReference or other resources. These would be included or associated or used in the more sophisticated implementations.
I also think we need a solution that scales especially because the first step may be to feed into, streamline, and highlight a manual process and the next step is to provide a vehicle for semi-automation.
Note that based on my interviews with others the amount of requests received today in an official manner is scarily low and highly manual.
Lloyd McKenzie (Jan 15 2021 at 21:24):
Both placer and filler (patient and provider, in this case) updating Task is normal. It's one of the few resources where that's an expectation.
When a set of information is specifically tied to a business state of the Task, use of input/output is probably appropriate. When it's just ad-hoc communication, then an independent Communication instance (whether to transmit the actual data shared, or to log data shared by other means - e.g. email, phone, text, whatever) is appropriate.
Virginia Lorenzi (Jan 16 2021 at 02:30):
I hear you but I think we need to talk about it more.
Debi Willis (Jan 16 2021 at 15:08):
What do you feel about creating both a communication and a task at the initial request? They could point to each other to keep them linked. This allows the conversation to go back and forth (creating a new communication with each request/response) instead of updating a single task resource. The task could then be fully managed by the provider and could be broken into multiple tasks if the patient requests several changes. Thoughts?
Vassil Peytchev (Jan 16 2021 at 16:13):
From what I understand about how things are handled in the real world, I think the use of Communication for this purpose would fit only a small subset of edge cases. I expect adding a Communication resource will happen as the IG evolves and the use of the actual clinical data resources starts to come under consideration.
What is the exact concern about both sides updating the Task resource?
Debi Willis (Jan 16 2021 at 21:35):
Vassil Peytchev said:
What is the exact concern about both sides updating the Task resource?
From the feedback we received, there is concern about the multiple inputs and outputs all updating a single task during the "conversation" back and forth with the patient. The expert panel on Thursday were representatives who joined us to discuss what really is happening in the real world right now. They said there is a lot (emphasized A LOT) of back and forth between the patient and the clinic before a decision is made. This entire conversation needs to be captured and easily retrieved. Using task, we need to look back at the history of that one task to see all the different revisions. It could get messy...especially if an app accidently overwrites something in the last version (which we tried and it can be done). Also there would be a problem if the app doesn't know there are multiple versions of that one task. They might grab the last version and miss the previous conversations. With communication, it is clean. No updating a communication. Another communication chain is started that links to the previous chain. Much cleaner.
To answer your question in a shorter response: There may be very many updates to the task. Some apps may not realize there may be 50 versions of that one task and could grab only part of the "conversation". There is a concern that an app may overwrite or drop important information during the task update and that information will be "lost" in subsequent versions of the task.
In reality, the task is done only by the covered entity. The conversation is between the patient and the covered entity and is as critical to capture as the completion of the task. Having "communication" to capture the conversations back and forth, and "task" to capture the request and the stages of the task(s) on the clinic side is much less complicated. Only the clinic is doing the task. They should be the only one that needs to update the task (eliminating the issue of an app not bringing all previous information forward with each update). The patient and the clinic are communicating...that can be captured separately in "communication".
It seems this would solve the problems. What do you feel about that solution?
Lloyd McKenzie (Jan 18 2021 at 22:44):
Why is there a believe that the whole conversation needs to live in the Task? The conversation is about the Task - but it's not part of it. Just as a conversation about a prescription or an appointment isn't part of the MedicationRequest or the Appointment instance.
That doesn't mean that a Task can't be updated by both sides. There are conventions in place to ensure you can't accidentally overwrite information (look at https://build.fhir.org/http.html#concurrency). However, updating the Task (to cancel it, to refine what's requested, to change the date it's needed by, etc.) is different than having a conversation about the Task - just as changing a prescription or changing an appointment is different than having a conversation about it - even if the conversation is what led to agreement about the need for the change.
Debi Willis (Jan 18 2021 at 23:10):
Lloyd McKenzie said:
Why is there a believe that the whole conversation needs to live in the Task?
We were told to put the conversation from the patient side in task.input and the conversation from the clinic side in task.output.
Lloyd McKenzie (Jan 18 2021 at 23:56):
That's not necessary. Task.input is information that is necessary to allow completion of the Task. Task.output indicates the results of executing the Task. Neither are really appropriate to just back-and-forth communication between the participants (and possibly others).
Debi Willis (Jan 19 2021 at 14:44):
@Virginia Lorenzi @John Keyes Please add to this if I am getting this wrong.
Hmmmm. That is not what we were told. We were told to use task.input and task.output for the communication. That has been the major stumbling block. We would like to now try using the communication resource for capturing the back and forth communications and let the clinic create the task resource(s) to keep track of their progress on completing the task. From reading your posts, it sounds like you are in line with that idea. Am I understanding that correctly?
John Moehrke (Jan 19 2021 at 14:50):
it would seem not ALL of the communications would need to be added to communication. But if a communication coming from the patient that clarifies the request, wouldn't that need to be added to input? This could be added by the custodian... And if a communication from the provider to the patient is the conclusion (okay, not-okay, go-away) then that would be proper to put into output. Again, by the custodian.
John Moehrke (Jan 19 2021 at 14:51):
but not, all... they all could have their communication*.basedOn pointing at the task.. right? Thus they are all discoverable
Lloyd McKenzie (Jan 19 2021 at 15:06):
I wouldn't expect the clinic to create the Task. The Task should be created by the patient app. They're the one initiating the request - and they're the ones that need to monitor for the final outcome. Initiating the request is not ad-hoc back and forth. It's specifically saying "Do this" and demands a response. Logging of phone-calls, emails and other back and forth, as well as direct FHIR transmitted discussion "about" the request can be handled by Communication is appropriate.
Lloyd McKenzie (Jan 19 2021 at 15:17):
The key thing to be aware of is that all data sharing in FHIR is "communication", but that doesn't mean that all data sharing in FHIR uses "Communication". Communication is sort of a fallback where the only thing you're trying to capture is "information X was shared from A to B on date Y". There's no demand for behavior, no follow-up, no 'state' other than "is the information delivered". For some kinds of things, that's fine. But unless your objective is solely a FHIR equivalent of an email system, it's not going to be enough on its own. If A is requesting something and B needs to be able to say 'yes' or 'no' and then deliver what was requested, then Communication isn't the right solution - though you can have Communications that tie into the base request.
Lloyd McKenzie (Jan 19 2021 at 15:18):
It would be helpful to expand on why there's a concern with multiple participants being involved in updating the Task. (Because it was definitely designed for that use.)
John Moehrke (Jan 19 2021 at 15:23):
I agree on create. I was speaking only to update due to communications beyond first create.
John Moehrke (Jan 19 2021 at 15:23):
Lloyd McKenzie said:
It would be helpful to expand on why there's a concern with multiple participants being involved in updating the Task. (Because it was definitely designed for that use.)
John Moehrke (Jan 19 2021 at 15:24):
Reality... EHRs don't tend to allow Write access by the Patient to the same data which is the Medical Record.
Lloyd McKenzie (Jan 19 2021 at 15:32):
Well, reality is that EHRs don't typically allow externally-invoked workflows. But that's the use-case here.
Vassil Peytchev (Jan 19 2021 at 15:36):
I think the "stumbling block" might be the expectation that any and all information exchanges between the patient and the healthcare organization as part of the correction process will be duly recorded and present as information inn FHIR resources on day one. As I tried to explain earlier, there is a lot of area to be covered between no standard interoperability and fully standardized patient corrections process.
In other words, to avoid trying to boil the ocean, I think the first iteration of the IG needs to focus on the ability on the patient to request a correction using FHIR, and the ability of the healthcare organization to provide the outcome as request applied, request denied, or partially applied. How exactly that outcome is achieved should be out of scope. The subsequent "disagreement" for requests that are not applied is also in scope.
The second part of the "stumbling block" seem to be that it has not been clarified that the actual changes to the patient chart that are part of the outcome are not recorded in the Task - they need to be represented using the commonly supported resources. That part I think can be in scope for the first iteration of the IG.
Debi Willis (Jan 19 2021 at 16:58):
Lloyd McKenzie said:
I wouldn't expect the clinic to create the Task. The Task should be created by the patient app. They're the one initiating the request - and they're the ones that need to monitor for the final outcome. Initiating the request is not ad-hoc back and forth. It's specifically saying "Do this" and demands a response. Logging of phone-calls, emails and other back and forth, as well as direct FHIR transmitted discussion "about" the request can be handled by Communication is appropriate.
That makes sense. So the consumer app would create the task and the communication resources, referencing the other by ID. The task would be updated by the clinic as the status changes. When the clinic needs more information, they would send a communication (referencing the task ID) to get more clarity. The patient app could query the task ID to monitory the progress of the task and also see the entire conversation. Using both seems to meet the specific needs. @Lloyd McKenzie Is that what you are saying?
Lloyd McKenzie (Jan 19 2021 at 17:23):
The consumer app would create the Task. Most of the Communication resources would likely be created by the EHR. They'd create all the ones they originate, as well as records of phone calls, emails, etc. they receive. However, the Patient, relatives, other providers, etc. could also create Communication instances that reference the Task. Solicitations for more information can be represented in different ways. You could do that as just a bunch of communications, or you could do that as a sub-task. What's appropriate sort of depends on how you plan to manage it. Will there be a status? a list of outstanding actions? If so, Task is appropriate. If it's just going to be a bunch of back-and-forth and the only way to understand what's outstanding is to read everything, then Communication is fine.
Dave deBronkart (Jan 20 2021 at 03:48):
I appreciate and respect all the knowledge, deep roots, and cultural implications of all this. I have none of these roots.
Having said that, my "spidey-sense" antennas are screaming that the awkwardness we're experiencing is due to fitting Goldilocks' oatmeal into Cinderella's slipper. That is, it feels like what we're doing here is a misfit for the way we do other things, and we should step back a moment. (I emphasize that I might be wrong!)
We started out wanting to do one simple thing: send a notification of an error, in the form of request to fix it, and then get a response on whether or not it was done.
My first question: are there other things in FHIR that do exactly that? Examples, please?
But quickly we ran into the need for a conversation: A says x to B, and B replies to A, and A responds, maybe many times. Are there other things in FHIR that do exactly that? Examples?
Lately I hear people saying it might not be A then B then A then B; perhaps A or B might at any moment send another thing, which may be a response to something 17 steps earlier in the thread: message 51 might be a response to message 34, with 4 other topics in between. Yoicks, it's a Zulip thread!
Are there other thing in FHIR like that? Or what am I getting wrong?
Dave deBronkart (Jan 20 2021 at 03:52):
And I find myself wondering: does it even make sense to try to itemize all the back and forth, or can it be treated as a free text BLOB? I would imagine any app (and EMR) would be happy for the simplicity of just modeling "Here's the request, here's the current status, and here's the truckload of dialog being conducted by the humans outside this tidy little FHIR exchange."
Josh Mandel (Jan 20 2021 at 04:06):
I adore the fairytale mixed metaphor. The thing is, you need to either capture the details of the conversation in band or out of band, or leave it out of scope; just quote unquote making it a blob doesn't help, because what you need is a specification explaining how that blob comes to be and how it gets upated over time.
-
In band -- the API specifies how each party can update a conversation thread over time
-
Out of band, but with hooks -- the API specifies how the app can obtain a link where the user can go to take the conversation forward. Generally this means the user leaves the app and is taken to some kind of a form that the healthcare provider offers to enable a subsequent conversational turn;
-
Out of scope -- the API provides no particular support for conversations; of course the healthcare provider can always call the patient or send a text message or whatever to follow up, but the details are not relevant or surfaced in any standard way
All of these are fine. There's absolutely a case to make for leaving this out of scope, which is not to say it is unimportant or even unnecessary. This is the balancing act of standards! You have to be really precise about what you want, and the smaller your wish the more likely it is to come true.
Lloyd McKenzie (Jan 20 2021 at 04:32):
I was picturing the look on Cinderella's face when she put on her slipper :laughing:
In a pure REST sense, asking for something to be done and getting a response - not much out there yet. Gravity and Da Vinci both have IGs that propose this and have had successful connectathons, but not much EHR uptake. Most of what I've seen in terms of asking for action has been in the area of prescriptions or referrals and in both cases the solutions have involved using messaging (which isn't terribly friendly for mobile clients/apps and has other challenges too).
In terms of supporting the capture of arbitrary back-and-forth, I've been involved in one solution and have heard of at least one other. Both also involved messaging.
So: you're treading relatively green fields here. FHIR can do it. But we definitely need to look closely at what the EHR systems are up for. I certainly have a hope that the solution we come up with will scale. So the "please do" mechanism we come up with for corrections should look similar to other "please do" things that might come from a patient - or other providers (please renew my prescription, please cancel this order). And the ad-hoc conversations around a correction should work the same way as ad-hoc conversations about other things.
Dave deBronkart (Jan 20 2021 at 11:07):
Josh Mandel said:
what you need is a specification explaining how that blob comes to be and how it gets updated over time.
Do we?? IIRC (I'll look it up later) the scope of this IG, mandated from above, is JUST the protocol for the request. But I might be "disremembering" that. @Debi Willis @John Keyes @Virginia Lorenzi @Abigail Watson help?
the smaller your wish the more likely it is to come true.
EXACTLY. And if I've heard one thing around here consistently, it's that "smaller" doesn't mean "don't dream big" - it does mean "Be practical, be achievable, be worth the effort."
Dave deBronkart (Jan 20 2021 at 11:08):
Lloyd McKenzie said:
I was picturing the look on Cinderella's face when she put on her slipper :laughing:
And now we could start a branch (in Social!) of the worst thing any of us has ever found upon putting a foot in a shoe or slipper. Extra points if the foot was bare.
Dave deBronkart (Jan 20 2021 at 11:14):
Lloyd McKenzie said:
FHIR can do it. But we definitely need to look closely at what the EHR systems are up for.
Absolutely! I want implementation a million times more than I want abstract purity. I want genuine help for patients who SERIOUSLY need important changes, and I absolutely don't want the work to be impeded by a spec that says "Stop that! I know you're doing it, but you're not being fancy enough! Go to your room and think about what you've done, and don't come out until you're sorry."
So, Epic and Cerner and Allscripts and everyone - what is worth the effort, to accomplish a straightforward amendment? And how might we capture the dialog - or even the fact that there is a dialog - for messier cases?
And, all, would it be a legit spec to ONLY point to the existence of a HIPAA-compliant dialog somewhere?
(The above is my opinion. I am not the sanctioned ambassador of TPTB at the Pt Empowermt WG.)
Josh Mandel (Jan 20 2021 at 14:22):
what you need is a specification explaining how that blob comes to be and how it gets updated over time.
Do we?? IIRC (I'll look it up later) the scope of this IG, mandated from above, is JUST the protocol for the request.
What I meant was conditional -- if you want to support in-app conversations then you need to specify how it works. The list of three options I provided below is probably a better summary of my position; I'm saying you should pick one of those three and then do what it takes to get there :-)
John Moehrke (Jan 20 2021 at 16:32):
The alternative I am viewing as most likely to succeed.... a well-known Questionnaire endpoint to be used by a patient when they wish to register a correction request. The content of the Questionnaire is organization specific, but there would be well established patterns such as identifying the id of resources that need corrections (as uncovered by a patient use of that organizations patient accessible FHIR api). The result is a QuestionnaireResponse. We indicate informally that some communications might happen to clarify, these communications are out-of-scope (at least of generation 1 of our solution). The QuestionnaireResponse is maintained as record of the correction request. The next thing we say must happen is a DocumentReference with the proper .subject, and a defined .category and .type -- most important the DocumentReference.context.related points at the QuestionnaireResponse, and the DocumentReference.content is the human readable conclusion of the correction request. Note that if the data was updated, those data would be pointed to with a Provenance with that Provenance explaining it was a patient correction request, and that Provenance.entity pointing at the QuestionnaireRepsponse AND the DocumentReference.
John Moehrke (Jan 20 2021 at 16:33):
patients having the ability to fill out a Questionnaire is well supported by EHRs today... my solution does not require any other patient Create/Update rights than that.
John Moehrke (Jan 20 2021 at 16:35):
if the organization chooses to use a Task internally, they can and they can add that to the Provenance and have that task point at the QuestionnaireResponse. But it is not required, which is recognition that the internal workings of an organization likely already has mechanism to handle this workflow.
Lloyd McKenzie (Jan 20 2021 at 16:49):
Posting a QuestionnaireResponse doesn't drive workflow - unless we define a custom operation. If we're going to define a custom operation, no need to use QuestionnaireResponse at all - as we can define a Parameters resource that passes in whatever we like. However, that still creates the question of how to monitor for a response.
John Moehrke (Jan 20 2021 at 17:23):
That seems odd. relative to other uses of Questionnaire/QuestionnaireResponse. I do need to yield to your expertise on this topic. It seemed a profiled Questionnaire/QuestionnaireResponse seemed the right solution. Seems this is the approach that EHR vendors are pursuing.
Lloyd McKenzie (Jan 20 2021 at 17:29):
Posting a QuestionnaireResponse just says "Store this set of answers" (and have the information available for subsequent query/update). There's no expectation in FHIR that any behavior happen other than "store this instance". It's not prohibited for an EHR or any other server to invoke custom behavior when data is created or updated, but that's outside the scope of the FHIR spec. I wouldn't be terribly comfortable with an implementation guide that depended on 'side effects' that are outside the scope of the standard. The 'standard' way of passing data to a system and triggering a side effect is a custom operation or using Task (which is the specific resource defined to say 'do something').
John Moehrke (Jan 20 2021 at 17:30):
I didn't expect FHIR core to have added that behavior. I expected our IG to add that behavior.
Lloyd McKenzie (Jan 20 2021 at 17:47):
Right - but that would mean an IG is defining a side effect to 'create', which isn't really good design. The base RESTful operations, for them to be generally useful, need to retain their clean functionality. If we want side effects, we should break those out. (Because the reality is, we're looking at custom code and behavior regardless)
Debi Willis (Jan 21 2021 at 00:25):
I think somewhere along the way we got lost in the woods with Hansel and Gretel. :fear:
We need to find a way to link conversations that go back and forth between the patient and the covered entity (which could be a very long chain) and still be able to track the task. This is very important. If we only solve for the simple onetime communication, we might find that it will never meet 80% of patients' needs.
We need to be able to send attachments also. We need a FHIR solution that mimics Direct. It seems that the communication resource can handle the linking to prior communications and also to the task, and task can link to the ID that started the initial request conversation. The patient can check the status of the task to know what is going on.
We tried Task and found some issues. We haven't abandoned Task. We just want to solve the communication problem with an added resource.
@Jeffrey Danford Can you help explain what you suggested during the connectathon? @Isaac Vetter I think you and Jeff were on the same page. We really need the EHR vendors to join the conversation.
Dave deBronkart (Jan 22 2021 at 02:01):
Debi Willis said:
We need to find a way to link conversations that go back and forth between the patient and the covered entity (which could be a very long chain) and still be able to track the task.
If I understand correctly, that's option 2 of @Josh Mandel's three options a few messages back: "out of band, but with hooks"
If we only solve for the simple onetime communication, we might find that it will never meet 80% of patients' needs.
So here's a juicy "is it worth it" parameter! DO 80% of patient needs require non-trivial back & forth?? Anyone know of any literature, or is practical experience all we have to go on? (I personally have zero experience)
John Moehrke (Jan 22 2021 at 12:26):
note, I did include in my proposal a way they are all linked.
Debi Willis (Jan 22 2021 at 14:07):
John Moehrke said:
note, I did include in my proposal a way they are all linked.
@John Moehrke Thank you John. I missed your proposal. Where can I find it?
John Moehrke (Jan 22 2021 at 14:22):
Debi Willis said:
John Moehrke said:
note, I did include in my proposal a way they are all linked.
John Moehrke Thank you John. I missed your proposal. Where can I find it?
see this thread at 10:32 (my time) yesterday.
Debi Willis (Jan 22 2021 at 16:11):
Thanks @John Moehrke How does that solve the linking of the multiple conversations back and forth? The initial request is not the problem. Task seems to handle that. It is the back and forth and back and forth (times x) that gets sloppy when trying to use the Task.input and Task.output fields.
John Moehrke (Jan 22 2021 at 16:13):
when the communication resources point at the QuestionnaireResponse (or task) that is linkage. In REST the linkages are one direction, but they are effectively bi-directional. Thus you do NOT need to update the QuestionnaireResponse (or task) for each communication. You just need to make sure (implementation guide constraint) that the communications refer to that QuestionnaireResponse (or task).
John Moehrke (Jan 22 2021 at 16:14):
to find all the conversatinos.. you would just look for communications that have a .baseOn that is equal to the id of the QuestionnaireResponse (or task) of interest.
Vassil Peytchev (Jan 22 2021 at 16:58):
I think there are a few areas that seem to bring up some misconceptions:
- "EHRs don't typically allow externally-invoked workflows." - the misconception here is that the Patient Corrections IG is limited to interactions with an EHR. In reality, it is describing the interaction with the healthcare provider's choice of handling patient corrections - in some cases it will the EHR, in others it might be a different system. The outcome must be recorded in the EHR in some way (what correction was applied, why it was denied, etc.), but that change to the EHR data is not exposed as an API to the patient - it is a side effect of patient correction request being handled. The part that I think is necessary to be addressed is how the recorded outcome in the EHR is exposed via an API to be consumed by a patient-facing app, Has this part been addressed in the IG?
- "If we only solve for the simple onetime communication, we might find that it will never meet 80% of patients' needs." - the misconception here is that the patient corrections IG must provide 100% coverage of the entire process of requesting, discussing and arriving to an outcome in order to be useful. There a several parts to this:
a. Focusing on the process for the patient corrections without addressing specifically how the back-and-forth needs to be handled is not "solving it for the simple onetime communications" - it is just providing the framework where more comprehensive additions can be made in future versions.
b. As far as I am aware, there is no requirement that the back-and-forth are to be recorded in some comprehensive fashion. I think that means that there is a wide range of existing functionality within the various healthcare provider IT systems - from recording the full back and forth, to a note stating "After discussion with the patient, we agreed to make the following correction" where both can reflect a month of negotiations.
c. Solving the problem of how the back-and-forth between the patient and the covered entity is to be represented in FHIR I think is a very large problem. If we try to solve it specifically for the patient corrections case, we are bound to get into a situation where a future general approach would be at odds with what might be present in the patient corrections IG
d. Apps are not bound to only use the FHIR API from the patient correction IG (or only FHIR APIs in general) to provide a comprehensive solution from the patient point of view. App design is not the same as an interoperability IG.
John Moehrke (Jan 22 2021 at 17:38):
I fully agree. We need to start simple. It might be unsatisfying, but making progress is more important than creating a complex IG that no one will ever implement. I would be happy with a well defined way a patient can see the correction-request-response report, where event that is nothing but a DocumentReference profile with a Binary attachment that is likely a PDF.
Dave deBronkart (Jan 22 2021 at 17:58):
Debi Willis said:
If we only solve for the simple onetime communication, we might find that it will never meet 80% of patients' needs.
Hey all - we've really grabbed the ball on this and started running with it . 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.
John Moehrke (Jan 22 2021 at 18:25):
Note there is a nice data model defined in LOINC for a "correction requests".
https://loinc.org/58197-5/
It does include data model for output reports
These codes would be good to use for the .code or .type elements in our IG, rather than .code.text which is not computer processable.
Jeffrey Danford (Jan 22 2021 at 21:47):
Late response, but my thoughts. I have two concerns with the patient using Task. The first is that most EHRs have highly evolved tasking systems that all function differently. Asking each of them to save a commonly defined Task may be a less than easy endeavor. I agree that Task is the obvious resource for working and tracking the patient's request but I at least would prefer allowing the EHR create it according to their own rules. The second concern is it just seems like we're pushing a lot of responsibility on the patient for what should be a simple process - they want their data corrected, they request the correction and the EHR takes care of it. Asking them to create and monitor a Task (even with the help of an app) just feels burdensome. One of the options we discussed last week (how time flies) is to use Communication or something like it to convey the request from the patient to the EHR. The EHR would then initiate their own internal process (i.e. doesn't need to be defined in the IG) to respond to that request. Logically that might include creating an internal tracking Task, the id of which could then be returned to the patient similar to the way tracking numbers are used in logistics. Any future communications (Communications?) between the patient and the EHR could reference that Task and everything could be linked to it. Once the patient's request has been completed the Task could be closed and a final communication could be sent to the patient notifying them of the outcome.
Lloyd McKenzie (Jan 22 2021 at 22:26):
The patient wants to submit a request, monitor the request for process and see what the result is when there's a final determination. Communication lets you send the equivalent of an email, but doesn't allow the patient to monitor what's happening. The patient is just sitting there waiting for an 'email' back - and that's not what the experts have said patients want. Note that no one is making patients monitor. They can submit the request and check on it only if/when they want.
I guess the fundamental question then is "Is it important for the patient to be able to see what's happening between tossing their request over the wall and (hopefully) eventually getting back a final response?"
Dave deBronkart (Jan 23 2021 at 00:07):
Lloyd McKenzie said:
I guess the fundamental question then is "Is it important for the patient to be able to see what's happening between tossing their request over the wall and (hopefully) eventually getting back a final response?"
Speaking only for myself, that seems like a softball / no-brainer question. Of course.
For years I've heard repeated appeals from patients who've said they've been unable to get mistakes corrected. It's essential to fulfillment of the legislative intent that patients be able to ask "What's up?" and get an answer, for which the provider can be held accountable.
Lloyd McKenzie (Jan 23 2021 at 00:18):
There are two ways you can do a "What's up?" - you can have the equivalent of another email request and (hopefully) response, or you can have an interface that allows you to 'query' into the relevant system and see immediately (instead of waiting for a response and hoping you get one). Note that I don't think current regulation mandates that clinical systems support status checks (could be wrong though) and, given that an email-equivalent would require paying a human to read the 'email', look up the status and then prepare a response, I'm not super confident in how timely or even if those statuses would be provided if there isn't something the patient (or their app) can directly query.
Lloyd McKenzie (Jan 23 2021 at 00:19):
@Jeffrey Danford - do you have thoughts about how best to manage an automated status mechanism if the request and response are just using Communication (secure email over FHIR)?
Virginia Lorenzi (Jan 24 2021 at 03:13):
I have been looking at the Task.notes field more. I think that if there is conversation with patients, notes could also be used to log that. It includes a place to specify author and it has a time stamp. So in notes you could have "Called Mrs. Allen to clarify request. No response. Left message asking for call back" (author Joe Smith date time 1/13/2021 9AM) " Mrs. Allen returned call. She explained she quit smoking in June 2020." (author Joe Smith date time 1/13/2021 11AM). If you are just logging phone calls, do you really need to use the Communication resource? You can have any number of notes. You could then have "Reviewed record. Contacted Dr. Jones and asked him to evaluate the request" (Joe Smith 1/13/2021 12PM) and later "Reviewed correction task - reached out to Dr. Jones again" (Mary Rodriguez 1/20/2021 9AM) and finally "Dr. Jones reviewed and determined that the record shows Mrs. Allen as a smoker on visits after June 2020. Record has been corrected and patient send amendment report by mail" (1/26/2021 10AM Mary Rodriquez). In the LAST case, there could also be an output with the amendment accepted report as an embedded document. with this approach, you would only need to use Communication if we want to use it to represent an a secure text type conversation between the patient and the person fulfilling the request.
Virginia Lorenzi (Jan 24 2021 at 03:16):
Maybe we should not allow the request for correction to be updated via the FHIR API - only canceled and resubmitted. Alternatively, maybe we could allow a new task to be created that amends the request for amendment. I think use of Communication and/or CommunicationRequest is certainly linkable nut not necessarily needed.
Lloyd McKenzie (Jan 24 2021 at 03:47):
(Moved to other thread)
Virginia Lorenzi (Jan 24 2021 at 06:55):
Interested about LOINC @John Moehrke I looked over it and not sure if it fits - gonna ask a friend.
Virginia Lorenzi (Jan 24 2021 at 06:58):
About questionaireresponse - seems to me that is a way to send the contents of a filled out request for correction form, but doesn't include the ability to check on the status of the request or get responses back. @John Moehrke @Lloyd McKenzie @Debi Willis . I see QuestionaireResponse, DocumentReference, and Composition all useful in communicating the contents of a document associated with the request or the response but not about the correction fulfillment process.
Jeffrey Danford (Jan 24 2021 at 14:21):
@Lloyd McKenzie that's were I was going with the EHR creating a Task and returning the id of the Task in the Communication response to the initial communication from the patient. The EHRs can continue to use whatever internal process they use to review the request and the patient has a tracker number (not my descriptive term, but it's catchy) that provides a mechanism for them to follow up on the status of their request. I'm leaning toward the idea of the EHR creating a Task instead of saving an externally generated one because I believe it will be easier to design a tracker Task that will work with every system.
Jeffrey Danford (Jan 24 2021 at 14:22):
@Virginia Lorenzi I'd be hesitant to go too far down the note path. Notes are the place were we put all the free-text stuff we can't categorize. It will be harder to break useful information out of that element.
Lloyd McKenzie (Jan 24 2021 at 21:32):
@Jeffrey Danford I don't understand. If the intention is to end up with a Task, why would you send a Communication which triggers the creation of a Task and is then communicated back with a Communication. Why not just allow the patient to initiate the creation of the Task? There's nothing that stops the EHR from adapting the Task as it gets stored - or revamping it if it needs to. What is the specific benefit of this level of indirection (which seems more complex to me - and is also somewhat abusing Communication...)
I don't see using QuestionnaireResponse accomplishing much. QuestionnaireResponses don't trigger workflow - you'd need to wrap them with either Task or a custom operation. QuestionnaireResponse for inputs would make sense if we expected there to be a need for wide variation in the inputs around requests for requesting a change. However, it's not clear that's needed here. It definitely can't be used on its own.
Jeffrey Danford (Jan 25 2021 at 18:56):
I believe there might be some difficulty in defining a Task that is applicable to all the internal processes of the various EHRs. If the EHR has to modify or adapt the Task to fit their workflow what's the benefit of giving them the Task to begin with over just letting them create one?
Lloyd McKenzie (Jan 25 2021 at 18:59):
The benefit is a standard API for doing the submission and keeping things neat and tidy. If I send you a Patient resource and ask you to create it, you're allowed to tune it some and echo back what you actually did. The same approach can be used in POSTing a Task.
Lloyd McKenzie (Jan 25 2021 at 18:59):
Can you give some concrete examples of the specific types of changes you'd expect to see?
Virginia Lorenzi (Jan 27 2021 at 05:38):
Task.note is defined as "Free-text information captured about the task as it progresses." We were specifically advised not to use Task.note to represent a conversation between requester and fulfiller using Task.note. So using it for this would be, at this point, an "off label" solution. @Vassil Peytchev @Lloyd McKenzie
Virginia Lorenzi (Jan 27 2021 at 06:08):
Just thinking outload I liked the Task.note idea but now its bugging me. Let's say we use Task.note correspondence between requester and fulfiller. But we already wanted to use it for notes about the task so now it will be weirdly intermingled. Let me pretend to try out our connectathon scenario:
- Requester send Create Task with Task.description set to "Please correct my record. It says I smoke, and I don't smoke".
- Fulfiller reviews the Task and adds notes - Task.note "assigned to Lucy Smith" authored by "Fred Jones" 1/20/21 10:00, "contacted doctor Gold" authored by "Lucy Smith" 1/20/21 11:00. Determine more information is needed from patient and asks for the additional information: Task.note = "Additional Information is needed to process your Amendment Request. Congratulations on quitting smoking. Please provide the date you last smoked" authored by "Lucy Smith" at 1/20/21 11:00
Soon after the requester polls the fulfiller and sees that the notes on the task. The requester responds by sending an update Task with perhaps a single Task.note = "I quit smoking on June 1st"
What if fulfiller then adds Task.note = "what year did you quit smoking?" Requester adds Task.note "in 1820" and Task.note "how soon can I expect my request to be corrected?" And then fulfiller adds Task.note "called patient and determined they quit smoking in 2020"
If all these updates to Task, I would worry that Requester might overwrite the description field or some other important field like inputs. I would worry about how each side processes receiving a list of notes - what if the list has changed? Does each side only send the notes it has added on this new update or do they always need to include all notes that are valid? Can either side delete notes in the Task?
My impression is notes about the task and correspondence with the requester are not the same thing. And allowing the requester or the sender to update fields in the Task is dangerous and needs to be carefully controlled who can update what when.
And if author and date/time not required or not specific enough you could have that repeating field not sure whether to add/update/delete problem with Task.note.
Josh Lamb (Jan 27 2021 at 13:34):
The provider and patient cannot have the possibility of adding task notes at the same time. It makes the workflow too confusing to follow. Maybe use the task status to indicate whose turn it is to update the Task update (outside of canceling request by the patient).
Lloyd McKenzie (Jan 27 2021 at 15:09):
We can set rules about what is allowed to be overwritten - once we figure out what the rules should be. All parties send the complete Task as a snapshot reflecting what it should be - unless we decide to use PATCH, which isn't as widely supported. But that's not a risky proposition - that's how all FHIR updates work. Allowing multiple parties to update the Task is not dangerous - it's normal and expected.
Lloyd McKenzie (Jan 27 2021 at 15:10):
Certainly the intention is that anyone who has something useful to say can add notes at any time. (That's true for anything that has notes - Observation, Procedure, whatever.)
Josh Lamb (Jan 27 2021 at 15:54):
I agree that Patch sounds ideal but would not be implemented. Many people do not even know about patch.
Josh Lamb (Jan 27 2021 at 15:55):
The one advantage of communication request/response is they can be added independent of updates to the task. But I do not think the increased complexity and relationships is justified for the minimal gains in transaction safety.
Josh Lamb (Jan 27 2021 at 15:56):
You can always use them later on too.
Josh Lamb (Jan 27 2021 at 15:57):
I would also rely upon the cleverness of app developers to handle most of the contention issues.
Vassil Peytchev (Jan 27 2021 at 19:38):
@Virginia Lorenzi I think the issues you are bringing up are some of the general issues that will arise in any attempt to fully cover the topic of patient - responsible entity conversations, regardless of the use on Task.notes or Communication.
John Moehrke (Jan 27 2021 at 19:45):
and perfection should not get in the way of good-enough
Lloyd McKenzie (Jan 28 2021 at 00:18):
CommunicationRequest shouldn't be part of the discussion. If we're doing something outside Task, it would just be a whole bunch of Communication instances, no CommunicationRequests. However, I agree that Communication is more overhead than we need right now. Only exception is if the only interest implementers have is in a secure email equivalent and have zero interest in supporting a 'request' resource that patient systems can query to determine status and will eventually be updated to reflect a final decision.
Dave deBronkart (Jan 28 2021 at 01:53):
John Moehrke said:
and perfection should not get in the way of good-enough
I'd tweak that: perfection shouldn't get in the way of "genuinely useful AND achievable at reasonable cost"!
Josh Lamb (Jan 28 2021 at 04:35):
Using Task.note[] only we can communicate when things are resolved (or pending provider/consumer feedback). We have multiple task statuses to play with.
The Task statuses do not seem to represent the workflow we are trying to define. Do we have any suggestions for the possbile task statuses and what they mean?
Virginia Lorenzi (Jan 28 2021 at 09:26):
@Lloyd McKenzie @John Moehrke Regarding the use of CommunicationRequest - I strongly agree with Lloyd. I do not feel CommunicationRequest lends anything to this. I think a chain of Communication resources to represent a conversation would work better. I really have trouble conceptualizing why CommunicationRequest/Communication pairs make any sense in this situation.
Virginia Lorenzi (Jan 28 2021 at 09:30):
@Vassil Peytchev the difference is, if we use communication resources, there is no shared updating of the same resource. Provider posts one patient posts one and refers to the provider one, etc. There's a nice linked list of resources. No chance of wiping out another one's note.
Virginia Lorenzi (Jan 28 2021 at 09:36):
The statuses do represent the workflow and when they don't we can use Task.businessStatus - http://build.fhir.org/ig/HL7/fhir-patient-correction/specification.html
We might need to tweak it some. We spent awhile thinking about this. And we also get to use status.reason to say why something has a certain status.
And Task.output to have the formal outcome of the Correction Request.
Lloyd McKenzie (Jan 29 2021 at 04:41):
Task.note doesn't mean you can only communicate when things are resolved. Task.notes can be added at any point in the life-cycle. Task.status is about the process of requesting action - which is what's happening here. The definitions of all the codes are in the code system, which you can access by clicking through the value set.
Shared updating of the same resource is going to happen no matter once. That's not something to avoid. If you're going to cancel, add missing inputs, update due date, etc. there's going to be shared updating. Shared updating is safe, so don't make any decisions based on a desire to avoid it. The complexity of working with multiple linked resources should be much more of a concern than multiple systems updating the same resource.
Josh Lamb (Jan 29 2021 at 15:55):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
