Stream: patient empowerment
Topic: project - patient corrections
Virginia Lorenzi (Sep 18 2020 at 22:30):
Hey FHIR architects - what is a good way to represent that data has been amended using FHIR?
Lloyd McKenzie (Sep 18 2020 at 22:30):
Provenance?
Virginia Lorenzi (Sep 18 2020 at 22:55):
Like this. My understanding is - A patient requests that their smoking status is corrected - I DON"T SMOKE! The clinician is not able to update the smoking status directly but instead amends the field with a corrected note.
Lloyd McKenzie (Sep 18 2020 at 23:05):
Have you ever seen a system that had the ability to capture correction notes on a per-field basis? (Or even a per record basis?)
Virginia Lorenzi (Sep 18 2020 at 23:14):
Perhaps - I am trying to figure that out.
Michele Mottini (Sep 19 2020 at 01:02):
(deleted)
John Moehrke (Sep 19 2020 at 15:22):
Provenance is the right solution. Given that the old and new version of the target resource exist (provided versioning FHIR), one can always see the DIFF. Thus the Provenance covers the DIFF made between old and new.
The Provenance would point at the old, and new as normal; but would also have an .entity that points at the patient request to change. Thus it is clear WHY.
I might argue that it is even appropriate to record a Provenance for a requested change that resulted in no change.
Virginia Lorenzi (Sep 20 2020 at 00:00):
Thanks guys for advice on provenance.
Lloyd McKenzie (Sep 20 2020 at 03:02):
The requested change would be a Task. If there was a Provenance it would be on the status change of the Task.
Virginia Lorenzi (Sep 23 2020 at 07:03):
@Lloyd McKenzie I have checked with medical records departments of two hospitals and I know certain data fields do not have the same formal process for correction. For example - demographics changes do not require the same formal process. I checked my patient portal to see what it would allow me to update (and then it auto-flows back to EHR) - I could update all demographics, emergency contact information, and insurance. I have a feeling I might be able to update my own med list as well but lets ignore that for now. Clinical correction requests fall into the formal process.
Virginia Lorenzi (Sep 23 2020 at 07:34):
Another question. There is a formal paper process in which a patient requests a change to a clinical part of their record. The provider sends correspondence saying request received and status. Clearly the response to the request will not be synchronous. And the actual change is not the indicator the change happened - a formal communication saying the change occurred. Lets say I use Task. Do I do an API PUT Task to the EHR?
Lloyd McKenzie (Sep 23 2020 at 13:00):
First step would be a POST of the Task to the EHR (to create it). Then the patient app would either poll the Task (query on a semi-regular basis) to see if it had changed or subscribe to the Task to receive a notification of when it had changed. (Because patient apps wouldn't likely have reliability availability or location, polling would presumably be most common.) The EHR would update the Task to change status & business status.
Vassil Peytchev (Sep 23 2020 at 15:10):
@Virginia Lorenzi if you want to see a visual representation of how to handle exchanges using Task between initiator and recipient, you can look at this part of a current ballot
Abbie Watson (Sep 23 2020 at 17:09):
And those formal processes differ by state. Not drastically, but to some degree.
Virginia Lorenzi (Sep 23 2020 at 17:29):
Abigail - yes I stumbled across NY state's ones and they are detailed. Can't wait to show @Debi Willis
Virginia Lorenzi (Sep 23 2020 at 17:29):
@Vassil Peytchev Thank You! If you are free come to our meeting at 2 today. We are getting geeky.
Virginia Lorenzi (Sep 23 2020 at 17:31):
Oh great Lloyd that is what I thought! Got my POST and PUT mixed up - smacking myself. Ouch.
Virginia Lorenzi (Sep 23 2020 at 17:33):
@Lloyd McKenzie I know you are busy but would love to have you at any of our patient corrections time slots. Today at 2 and for 45 minutes tomorrow in 10-11:30 timeslot. Also 2PM tomorrow. @Amit Popat @Jeffrey Danford @Vassil Peytchev Having a FHIR architect type around would be good. We will still bring FHIR-I questions to you at 4ET tomorrow.
Lloyd McKenzie (Sep 23 2020 at 17:44):
Today, I might be able to make 3-3:30. I can come tomorrow at at 10. Can't do 2pm tomorrow
Virginia Lorenzi (Sep 23 2020 at 23:32):
10AM works!
Virginia Lorenzi (Sep 24 2020 at 02:22):
So Task.intent does not include event. I thought you said we used Task for the event as well?
Lloyd McKenzie (Sep 24 2020 at 02:29):
A Task links both worlds. You can't have an 'event' Task. A Task is always a request - but it captures information about the event. So Task.intent captures the nature of the request.
Virginia Lorenzi (Sep 24 2020 at 04:18):
Wait that makes sense - its always about the request whether the requestor or the owner is talking about it. The actual correcting is outside of this.
Dave deBronkart (Sep 24 2020 at 21:31):
I just want to capture a signal moment on this subject from 2009.
The Parable of the Wicked EMR
After my Google Health / billing codes fiasco, HIT consultant David Kibbe drew a parallel with "the wicked Bible," a story from the early days of printing, in which every print shop did its own typesetting. In one edition, the printer omitted the word "not" from the 7th commandment, so that it read "Thou shalt commit adultery," and printed many copies.
Needless to say, the bishop was not pleased. The lesson is that once an error exists, it's all too easy for it to propagate. And the existence of a single source of truth does not guarantee that all copies derived from it will be accurate.
Virginia Lorenzi (Sep 25 2020 at 05:53):
hey Lloyd where were you last night? We went to FHIR I and they said use Communication and Composition with Tasks inside .
Lloyd McKenzie (Sep 25 2020 at 05:58):
Who did??
Lloyd McKenzie (Sep 25 2020 at 05:59):
Composition makes no sense at all, and Communication is also inappropriate based on current best practices.
Dave deBronkart (Sep 25 2020 at 13:45):
Game on! Where and how do we work this out?
Lloyd McKenzie (Sep 25 2020 at 13:48):
First I need to understand who made the recommendation so I can understand where they were coming from.
Dave deBronkart (Sep 25 2020 at 15:16):
Let's send it to the replay booth:)
Virginia Lorenzi (Sep 26 2020 at 00:29):
@Lloyd McKenzie Debi get a great presentation of the use case. You, Vassil, and Amit missed it. I think we should do it again on one of our regular calls you guys can attend and you can tell others. I think it will help give perspective and Debi can answer questions. The people who suggested various things knew those things especially well as it were. Example Rick said composition. In all fairness the workflow guys (you, Vassil) said Task. Others said do just Puts and posts of the resources and have business rules on server side behind the puts and posts. And I am not sure who mentioned Communication.
Dave deBronkart (Sep 26 2020 at 12:09):
(Virginia meant Debi did a great presentation.)
Why can we not start by getting the recording and finding the time-code for that spot?
Debi Willis (Sep 29 2020 at 20:03):
Do we know when the recordings will be available?
Virginia Lorenzi (Oct 03 2020 at 23:23):
Debi see your email
Virginia Lorenzi (Oct 03 2020 at 23:26):
Found this nice call to action on Morgan's blog: https://morgangleason.com/2018/02/17/medical-record-errors/
Virginia Lorenzi (Oct 06 2020 at 16:34):
There would also be provenance perhaps reflected in the actual data updated but not sure because it would have been updated by clinician as amendment. Perhaps for demographics.
John Moehrke (Oct 06 2020 at 16:51):
There would be an instance of Provenance for each update to the targeted data. Thus in the history on an updated resource would be many Provenance, one of which would be indicating the details of the patient request.
Dave deBronkart (Oct 06 2020 at 21:11):
Virginia Lorenzi said:
Found this nice call to action on Morgan's blog: https://morgangleason.com/2018/02/17/medical-record-errors/
Read this!! She was 19 when she wrote this!!
Other issues, however, are more significant.
Several years ago, a doctor accidentally marked Diabetes on an MRI order form, and somehow that added the problem to my health condition list. When that specialist sent the notes to my primary doctor and my rheumatologist, then they added Diabetes to my health conditions and suddenly people were asking me what my glucose levels were. They seemed very concerned when I told them I had no idea!
We need to create a way to solve this!
One factor is that evidently when clinicians see a new problem on the problem list, THEY ASSUME IT'S CORRECT without evaluating it. Is that a valid practice??
Would the erring provider feel embarrassed to know they had totally caused an important mistake in the patient's chart that could cause harm??
And this, in that post,
The office staff said that “the patient must have told us that if it is in the record.”
This is grotesque: "If it's in the chart it must be true," mixed with "If it's wrong in the chart, it's the patient's fault." No HL7 standard can fix that - it's not my point - but it sure does affect the challenges of getting people interested in implementing whatever we do.
Josh Mandel (Oct 06 2020 at 21:18):
It's always instructive to learn more details about how this problem came to be incorporated from an MRI order form into a problem list.
But managing problem lists is hard, often based on sketchy data, often for patients much less knowledgeable and engaged that Morgan -- and it's often a cross-organizational challenge where nobody is really responsible for the holistic result. https://library.ahima.org/doc?oid=104997#.X3zfCXWYVhE has some nice context -- e.g., "most organizations struggle to define content, responsibilities, and accountability for maintaining an accurate, updated problem list.").
(Add to this the fact that we have incentive systems that often pay more for higher-complexity cases, determined in part by problems documented in a problem list, so there's not always super-clear motivation to proactively clean things up.)
So my guess would be: yes, a clinician would probably be embarrassed to know they had done this, but at the same time, the problems are more systemic, and the erring clinician is only one piece of the story.
Josh Mandel (Oct 06 2020 at 21:21):
(To be clear, I'm in no way defending the system. What a total mess of a story, and the "office staff" quote, which came through on Zulip after I'd already drafted my initial response, is entirely inappropriate.)
Dave deBronkart (Oct 06 2020 at 21:21):
Do we need to start a "Stupidest Medical Data Error" award, naming the offending providers? "The Meddies," "The Derries", "The Derrierrors"?
"And the 2021 Mederrieres go to: (These are totally fictional - just insert your provider's name)
- The Mederriere for Biologically Impossible Condition goes to Cleveland Clinic, for asserting that Dave deBronkart is experiencing menopause
- The Mederriere for False Sense of Perfection goes to UCSF Radiology, for asserting ...
- The Mederriere for ...
Dave deBronkart (Oct 06 2020 at 21:31):
Josh Mandel said:
it's often a cross-organizational challenge where nobody is really responsible for the holistic result. https://library.ahima.org/doc?oid=104997#.X3zfCXWYVhE has some nice context -- e.g., "most organizations struggle to define content, responsibilities, and accountability for maintaining an accurate, updated problem list.").
Does the PE WG need to start advocating about the scope and complexity of the issue, to raise awareness?
Sometimes it's a granularity problem. My problem list includes MIGRAINES, a condition I do not have, in the usual sense. I get *ocular* migraines, which are a whole different thing - but "MIGRAINES" almost got me excluded from the drug that saved my life.
Would cleaning up problem lists be a worthy use case for a first implementation of a corrections IG?
Dave deBronkart (Oct 06 2020 at 21:33):
Seriously - it would take years (because articles always do) but should we start a project to get an article published in a journal? What journal? JAMIA? Other?
Dave deBronkart (Oct 06 2020 at 21:35):
@Debi Willis @Maria D Moen @John Keyes I'm tagging y'all on this thread, as people working on the project ... perhaps we should, separate from the IG and in parallel, create a white paper on the subject. It's something I'd be willing to work on.
Dave deBronkart (Oct 06 2020 at 21:37):
Josh Mandel said:
https://library.ahima.org/doc?oid=104997#.X3zfCXWYVhE has some nice context -- e.g., "most organizations struggle to define content, responsibilities, and accountability for maintaining an accurate, updated problem list.").
Does this pretty much say most organizations struggle to be competent at managing provenance?
Josh Mandel (Oct 06 2020 at 21:38):
I think a perspective piece in JAMIA would be an excellent place to start
Dave deBronkart (Oct 06 2020 at 21:43):
Josh Mandel said:
(To be clear, I'm in no way defending the system. What a total mess of a story, and the "office staff" quote, which came through on Zulip after I'd already drafted my initial response, is entirely inappropriate.)
But very, very common.
I keep telling this story - it PISSES ME OFF but it's true.
- My mom's eye doctor retires. She's referred to a new one. This is 2019 so interop doesn't exist.
- New eye doc's staff does the usual stupid "tell me your whole history" intake interview including med list
- Mom mentions a med that's usually prescribed for Type 2 diabetes, but not so in her case.
- Stupid clerk adds T2D to problem list without asking.
- An hour later, discussing her conditions, doc says "So I'm going to schedule you for surgery."
My mom, being my mom, asks why. He says "Ordinarily we'd use Drug X, but we can't because you have diabetes."
AND he said "Well you must have told her that, or it wouldn't be in the chart."
This is a real problem, folks. We out here have many such stories.
So please let's find a way to EXPRESS a needed correction, in a way that's feasible to implement - let's not come up with six years of study and 14 years of analysis.
Virginia Lorenzi (Nov 03 2020 at 06:20):
Mapping Task resource for Patient Correction Workflow and have some questions:
What's the difference between Task.for and Task.restrictions.recipient?
If a request is denied, that would show in Task.status. However, how do we provide an explanation for the denial?
Can you do conditional cardinality? (considering this because on fulfiller side, owner should be supported but requester might not know it)
Where in Task do you specify the Encounter this correction is in reference to? @Lloyd McKenzie said its not Task.encounter.
Vassil Peytchev (Nov 03 2020 at 14:47):
What's the difference between Task.for and Task.restrictions.recipient?
Task.for can be for a group, and in that case you may need Task.restrictions.recipient to specify one particular member of the group. For patient corrections, I don't think you need anything in Task.restrictions
If a request is denied, that would show in Task.status. However, how do we provide an explanation for the denial?
Task.statusReason can contain an explanation for the denial
Can you do conditional cardinality? (considering this because on fulfiller side, owner should be supported but requester might not know it)
The initial owner is the healthcare organization. It can then be updated to become more specific, but you probably don't need conditional cardinality.
Where in Task do you specify the Encounter this correction is in reference to? @Lloyd McKenzie said its not Task.encounter.
This is likely one of the Task.inputs - task.input.type is a code indicating "relevant encounter" and task.input.valueReference is a reference to the Ecnounter (or encounter identifier).
Lloyd McKenzie (Nov 03 2020 at 16:49):
Task.for is the 'record' the Task is associated with. Task.restrictions.recipient has different meaning depending on the type of Task. If the Task is "please fulfill", then it would be as Vassil said. If it said "please share with", then that would indicate who to communicate the information to.
If the owner is not known when the Task is created (e.g. posting somewhere for central dispatch), then you'd mark it 'mustSupport' but optional. In your case, the original owner should be known - though it may change as the Task gets punted around within an organization as they try to figure out who should actually ask on it.
Agree with Task.input to indicate relevant encounter or other filters
Virginia Lorenzi (Nov 04 2020 at 07:06):
A design best practice question. If there's a field in Task that we think is irrelevant and its cardinality is 0..something should we set it to 0..0 or leave it be?
Virginia Lorenzi (Nov 04 2020 at 07:18):
If we have a bunch of values in Task.input, how is the receiver going to know what to do with them? I guess we would need to define codes? For example, lets say I send text with a description of the desired correction, a picture of the error on the patient portal and an encounter reference of the encounter in which the error occurred. How will the receiver know how to process that? @Vassil Peytchev had also suggested we send other resources to give context, like send the Condition resource if the condition was in error...
What about Task.focus? Could Encounter go there? Or another resource?
Michele Mottini (Nov 04 2020 at 15:25):
Leave the irrelevant fields be - system might be generating or using them for their own purposes and you do not want to make those resources invalid
Virginia Lorenzi (Nov 05 2020 at 17:36):
Hey @Michele Mottini - any chance you guys want to participate in our corrections track in January?
Michele Mottini (Nov 05 2020 at 18:31):
We are interested, I am not sure we have the time - we'll try
Virginia Lorenzi (Nov 07 2020 at 21:58):
Thank you!
Virginia Lorenzi (Nov 10 2020 at 19:39):
@Lloyd McKenzie How do we fill out the FHIR IG Proposal item: FHIR Core version(s)?
R4? R5? Both?
Lloyd McKenzie (Nov 10 2020 at 19:44):
Presume we'd be targeting R4. R5 won't be available until spring 2022
Virginia Lorenzi (Nov 10 2020 at 19:46):
Great - thanks. Then we publish a new version if we want R5 when its time I guess.
Virginia Lorenzi (Nov 10 2020 at 19:49):
@Lloyd McKenzie We are balloting first time in Spring (hopefully), I assume again in Fall, earliest we would have guide is end of 2021. Considering that, R4 makes sense, right?
Lloyd McKenzie (Nov 10 2020 at 20:43):
Ideally you'd only ballot in the spring. Our usual target for FHIR IGs is one ballot and done (because the content is tested and pretty solid before it's balloted) and because some degree of substantive change between ballot and publication is acceptable). Certainly the first release timeframe would only let you build against R4. Also, R4 is all you'll see in production for the next 3 or so years.
Virginia Lorenzi (Nov 10 2020 at 20:51):
Interesting. I was not aware of that. Thanks.
Virginia Lorenzi (Nov 10 2020 at 21:02):
How do we implement partial accept and partial reject? Imagine the med rec dept gets a request for a correction from a patient - it is pros and refers to two errors. The med rec department, after working with clinicians determines that the first request is valid and accepts it, but that the second is not and rejects it. WOuld the request fulfiller system then spawn one or two subtasks with task.partof pointing to the master task and with one having status of accept and the other having status of reject? Or is there another way you would recommend? I do not think we have a failsafe way to ensure that the requester provides discrete atom level items for correction for each request so I think this problem will happen. @Vassil Peytchev @Lloyd McKenzie
Lloyd McKenzie (Nov 10 2020 at 21:09):
Ideally, they're handled as two different requests - as each may be independently routed and independently resolved. The other option is that the receiving systems spawns subtasks for each issue and managers and resolves them each. The overall Task gets marked as 'completed' when all of the child tasks are dealt with.
Michele Mottini (Nov 10 2020 at 21:37):
Just text 'we did this but not that'
Virginia Lorenzi (Nov 16 2020 at 18:07):
The problem with "we did this but that" is as follows: HIM can agree to do the correction, but it doesn't mean they've done it yet. If HIM (medical records) rejects a particular part, there is a disagreement process the patient could then initiate.
However, I do think there is merit in a way to do this inform low code as you suggest @Michele Mottini and maybe that is the best approach for now. @Lloyd McKenzie @Vassil Peytchev @Jeffrey Danford
Virginia Lorenzi (Nov 16 2020 at 18:12):
Should we use Task.description as a place for patients to express the correction they want in free text? @Lloyd McKenzie @Vassil Peytchev Also, should the patient's request task be separate from the fulfiller's fulfillment consideration task. Like the fulfiller spawns a task for its work and incudes a basedon relationship to the requestor task? Like the concept of lab order from doctor perspective (placer) and lab perspective (filler)? I see that the mechanism for that is there.
Virginia Lorenzi (Nov 16 2020 at 18:15):
Reminder that we have a call on Mondays at 3PM Eastern https://global.gotomeeting.com/join/322275573
Lloyd McKenzie (Nov 16 2020 at 18:29):
Yes, though I'd also include a 0..* Task.input that points to the specific data that's wrong - either as a FHIR reference or as a URL
Virginia Lorenzi (Nov 16 2020 at 18:49):
@Lloyd McKenzie Yes to the description? I asked you too many questions and I'm confused
Lloyd McKenzie (Nov 16 2020 at 21:58):
Yes to Task.description. There's generally only one Task - it is shared by placer and filler and both can edit it. (It's one of the few FHIR resources where that's typically the case)
Lloyd McKenzie (Nov 16 2020 at 21:58):
If the Task points to a Request, the filler might well clone the Request to create a 'filler' version that reflects their specific intention.
Lloyd McKenzie (Nov 16 2020 at 21:59):
However, I don't think that would be relevant in the "patient correction" situation as there wouldn't be anything other than the Task
Lloyd McKenzie (Nov 16 2020 at 21:59):
Note that the filler could spawn 'child' Tasks that tackle different parts of the request.
Virginia Lorenzi (Nov 17 2020 at 17:45):
OK @Lloyd McKenzie , so then when the Requester does polling of the Fulfiller, in the representation of Task sent back to the Requester, would the intent be set to Filler-Order or stay as Proposal? Personally I am not sure it matters much
Lloyd McKenzie (Nov 17 2020 at 18:53):
The Task would generally have an intent of 'order' and wouldn't distinguish placer vs. filler as it's used by both. Once 'intent' is set, it's generally not changed.
Virginia Lorenzi (Nov 19 2020 at 16:12):
@Jeffrey Danford @Lloyd McKenzie @Vassil Peytchev @Debi Willis @Abigail Watson @Lisa Nelson When we began our thinking on how to communicate requests for corrections with providers, Jeff had suggested we use CommunicationRequest. Looking at that resource, it appears to be a request to communicate with someone. That was not our intent. We actually wanted to communicate right then. More like, we want to message the provider. Currently, portals have secure message capability and through a patient portal you can send a message to your provider. However, in the fhir apis provided by EHRs, there is no way for a patient app to get a message into that provider inbox using fhir. Patients may have many different insights they would like to share with their doctor and there is no way to just send a basic message. The Communication resource seems the most like that. The Communication resource is not a request but represents the actual communication. I read in the definition: "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." So I got excited :grinning_face_with_smiling_eyes: and thought wow this could be that message. But the Communication resource went on to say: "This resource is a record of a communication that has occurred. It does not represent the actual flow of communication." :upside_down: Kind of like I called the doctor on the phone and then a communication resource was sent to document that. So what resource would be used to just send a free text message to a fhir enabled inbox? This is not to detract from all our work from Task, but it seems having a basic patient/provider messaging capability between patient apps and ehrs using FHIR and NOT direct protocol would be really useful.
Lloyd McKenzie (Nov 19 2020 at 16:28):
CommunicationRequest is not really appropriate here. CommunicationRequest is an authorization for data to be shared. What we're looking at here isn't an authorization to share, it's a request to make a change. CommunicationRequest is not the appropriate resource.
Keep in mind that we're always communicating information with FHIR. That doesn't mean that we're always using Communication or CommunicationRequest.
If your sole objective was to just represent "secure email" over FHIR, then you might use Communication to convey the text blobs from one place to another. You could use that to do pretty much anything - request an appointment, ask for a referral, ask a question about a lab result, request a correction. But it wouldn't accomplish anything more than an email would. No computability, no control over behavior, no searchability, etc.
Abbie Watson (Nov 19 2020 at 17:53):
We have an is/ought dilemma, between how people ought to implement the APIs in an ideal situation and what's formally defined and semantically consistent and ideal, versus what's currently available. Having a CommunicationRequest to discuss a Task might be a perfectly valid workflow for a file room somewhere that's operating a help desk and call log, and completely invalid elsewhere.
Before presuming what the provider workflow ought to be, maybe lets leverage the CapabilityStatement on /metadata, check to see if their system supports Task, CommunicationRequest, ServiceRequest, etc; send over whatever structured data that is available, and default to a workflow that mimics paper and phonecalls and faxes when more automated options aren't available.
Virginia Lorenzi (Nov 19 2020 at 19:14):
@Lloyd McKenzie I am not backing away from Task to support correction workflow and definitely not recommending CommunicationRequest as an alternative. My point is patient portals allow patients to send free form messages to their doctors for a multitude of reasons using the Secure Messaging Function (it was required in Meaningful Use). However, someone who uses a PHR which has data downloaded from many EHRs would need to go onto each portal to send such a message because the EHR vendors do not provide this simple communication mechanism through FHIR. As I have been looking at corrections, its make me think of that. So I want to know what resource or resources would be the best to send a message - like a secure email - from the patient app to the EHR - using FHIR - one that posts in that same inbox that already review from the patient portal. My daughter constantly using this feature to send questions about weird symptoms, is she doing something wrong in her self-care, questions about directions, etc. @Jeffrey Danford @Vassil Peytchev @Jenni Syed @Dave deBronkart @Debi Willis @Abigail Watson (Dave I am proud of my daughter for that).
Virginia Lorenzi (Nov 19 2020 at 19:39):
Additional Patient Corrections IG Meeting Tomorrow 5-6PM Eastern to review our work on profiling Task for the upcoming connectathon:
We will be "in the weeds". Anyone who is interested please join us from 5-6PM Eastern:
Join Zoom Meeting
https://columbiacuimc.zoom.us/j/5505166080
Meeting ID: 550 516 6080
One tap mobile
+16465588656,,5505166080# US (New York)
+13017158592,,5505166080# US (Washington D.C)
Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Washington D.C)
+1 312 626 6799 US (Chicago)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose)
Meeting ID: 550 516 6080
Find your local number: https://columbiacuimc.zoom.us/u/acHbDuY35
@Vassil Peytchev @Jenni Syed @Amit Popat @Michele Mottini
Jenni Syed (Nov 19 2020 at 20:22):
cc @Drew Torres
Lloyd McKenzie (Nov 19 2020 at 23:44):
If the use-case we're talking about is 'send a secure message using FHIR', then yes, Communication is appropriate. (Whether FHIR is the appropriate way to handle the 'send a secure message' use-case is a question I'll leave to the EHR vendors - I know that some environments are using it.)
Virginia Lorenzi (Nov 20 2020 at 17:43):
Yes Lloyd, that was the question. And I would say the definition of Communication is then misleading because it says "This resource is a record of a communication that has occurred. It does not represent the actual flow of communication." What other ways could a patient communicate with their doctors outside of fhir that works in their patient app workflow? I know direct messaging is one way but that requires patients to purchase a direct address.
Virginia Lorenzi (Nov 21 2020 at 00:07):
@Abigail Watson FYI You missed the slicing convo! @Lloyd McKenzie said with Task, its real important that you do slicing on input and output (because thats sort of how you provide additional fields).
Virginia Lorenzi (Nov 21 2020 at 05:57):
@Jenni Syed @Drew Torres @Amit Popat @Vassil Peytchev @Isaac Vetter Any chance you guys would be interested in participating in the Patient Corrections track in January? I know you are all quite busy but would love to have your insights and support.
Josh Mandel (Nov 21 2020 at 13:28):
Question for this group: would there be interest in proposing Patient Corrections as a project for Argonaut 2021? I think this would be a great fit, to get a certain set of the community to "make more room on their calendar" for discussing, testing, and iterating on specs for this use case. (On the other hand, you might decide it's a crowd or an imprimatur that you don't want.) Generally we start the project selection process toward the end of the calendar year, and if there is interest I'll be happy to include Patient Corrections on our list for review.
Josh Mandel (Nov 21 2020 at 13:28):
@Micky Tripathi FYI
Dave deBronkart (Nov 21 2020 at 13:37):
Heck yes!
I feel safe saying that without polling our project leads @Debi Willis and @Virginia Lorenzi and IG author @John Keyes :-) But we'll need support in understanding Argonaut and continuing support in our discussions of resources.
Michele Mottini (Nov 21 2020 at 16:20):
@Virginia Lorenzi can you convert that spreadsheet you were using yesterday in a Google sheet, so we can see and work on it together?
Lloyd McKenzie (Nov 21 2020 at 17:08):
I'd actually love Argonaut to take on Task generally - it's manifesting in quite a few IGs - a few Da Vinci ones, Gravity, SDC.
Debi Willis (Nov 21 2020 at 17:28):
@Josh Mandel I echo @Dave deBronkart to say we would love to have this support. This is a really important project because as patients begin to gather their data, there is going to be more visibility of all the errors in their charts. These errors could impact patient safety, health care choices, and insurance premiums. We really want to enable correction requests directly within the consumer apps instead of the patient printing out a form and mailing correction requests to the clinic. I also agree with Lloyd that Task will likely be used more in a variety of future use cases. Is there anything we need to do on our side to get this moving forward with Argonaut?
Virginia Lorenzi (Nov 21 2020 at 17:36):
@Josh Mandel as the US pivots toward greater data sharing with the information blocking rules, patients will be seeing more information and will see it more real-time, and have more to respond to. And I would assume that one important response will be that's not correct. I think providing patients will the ability to respond electronically in real-time would be empowering for patients as well as help with workflow management of incoming requests on provider side.
Virginia Lorenzi (Nov 21 2020 at 17:37):
@Michele Mottini yes I am supposed to do that conversion - will do.
Debi Willis (Nov 21 2020 at 18:47):
@Virginia Lorenzi @Lloyd McKenzie @Josh Mandel I love where Virginia is going with this question.This capability would bring so many benefits to patients. I have had several people ask me if they could use FHIR for secure communication between patients and organizations. They specifically referenced FHIR paralleling the Direct communication between a patient and a provider but using FHIR as an easier and cheaper way for patients to communicate with them within apps. This is even more important now with Covid causing patients to communicate remotely with their healthcare providers, social workers, and researchers.
Dave deBronkart (Nov 21 2020 at 23:17):
I'll repeat (just to keep it in-thread) a small part of the litany of errors to be fixed, because everywhere this comes up, there are earnest skeptical people who haven't yet discovered how many errors there are. (Everyone tends to believe that all people who put stuff in a chart are careful and not in a rush and that there's proofreading.)
- Screen capture attached: my 2003 x-ray identifying me as a woman.
image.png
2.My mother's hyper/hypothyroid mixup, which could have killed her.
3.My mother's wrong Problem List entry - a dumb clerk misinterpreted one medication and wrongly added DIABETES to her problem list, which caused her PCP to think something valid had been discovered elsewhere
-
Morgan Gleason's chart (at age 20) suddenly saying she'd had two pregnancies, one at age 13. Office clerk said "If it's in the chart, you must have said it."
-
@Grace Cordovano's Patient Impact Stories at Unblock Health, including Pat Sheridan dying after his dx was lost, and Grace's own anaphylactic morphine reaction, which she finds is often missing from a new provider's chart.
These are just off the top of my head. (Anyone, please add yours.) I want every reader to understand - this is not about outing the bad guys. This is about upgrading the accuracy of the data in EMRs that are about to become increasingly mobile.
Josh Mandel (Nov 21 2020 at 23:57):
Thanks for the feedback! I'll probably rope folks into proofreading (and of course if you like, re-writing entirely) a short project description for the Argonaut planning process. (Re: Task, I'll advocate for a bottom-up approach: let's use it in a project we care about and refine it through use, rather than trying to somehow tackle Task "in general".)
Michele Mottini (Nov 22 2020 at 00:32):
I think we all agree here that being able to send correction is a good thing, the issue is how to make that a reality: we'll figure out the technical part, it is not hard, the hard part is to have providers actually deploy it - I would love to see ideas about how to achieve that (because frankly, implementing things that would never be used is not that fun)
Josh Mandel (Nov 22 2020 at 00:34):
Agreed -- including even a small set of clinical provider orgs who want to make this work will be key.
Lloyd McKenzie (Nov 22 2020 at 03:17):
@Virginia Lorenzi An easy way for apps to initiate direct communications to providers isn't necessarily going to be seen as a positive for a lot of providers. Right now there are a lot of gatekeepers - and a lot of clinicians are quite happy for things to stay that way. Also, there aren't necessarily billing codes for reading and responding to patient queries. I'm not saying that providing a secure email-like functionality over FHIR would be a bad thing, but we'll need to think carefully about the business case from both sides of the exchange if we want it to be adopted.
Debi Willis (Nov 22 2020 at 15:11):
@Virginia Lorenzi @Lloyd McKenzie
I love where Virginia is going with this question. This capability would bring so many benefits to patients. I have had several people ask me if they could use FHIR for secure communication between patients and organizations. They specifically referenced FHIR paralleling the Direct communication between a patient and a provider but using FHIR as an easier and cheaper way for patients to communicate with them within apps. This is even more important now with Covid causing patients to communicate remotely with their healthcare providers, social workers, and researchers.
Dave deBronkart (Nov 22 2020 at 23:07):
I'm thrilled at the idea of Argonaut engagement. I don't know enough about how things work in the famed Argonaut world so I feel the need to bring myself up to speed, to be useful and not clueless. @Josh Mandel @Lloyd McKenzie @Micky Tripathi or anyone, any suggestions?
To be clear, this opportunity zooms instantly to the top of my interest list :-)
And I agree, it would be terrific to find both a use case that providers agree is indisputably legit and worth doing, and some provider orgs who are game to take it on. Although I often sound rabble-rousey, there is much value to be had by providers.
Would "missing allergy" be seen as undeniably valuable to providers? Would it need to be more specific?
Josh Mandel (Nov 23 2020 at 00:54):
Fixing allergy, med, and problem lists is an easy story and feels like a great start; I think we'd still want to keep something "less strucured" front and center as well, so we don't over-fit the workflow.
Dave deBronkart (Nov 23 2020 at 01:42):
LOL, okay chief, you’ve exceeded my vocabulary. Overfit?
I’ll take a guess. Are you concerned that we might make it trivially easy so people don’t have to flex their thinking?
There are LOTS of not very structured ones, but it’s easy to get into very debatable territory.
But how about this: remember @Morgan Gleason ‘s winning talk at DevDays June? It included discovering that her chart suddenly said she’d had two pregnancies, and she shared the documents she had used to precisely do what HIPAA requires. Is that an example of “less structured”?
Vassil Peytchev (Nov 24 2020 at 18:31):
I think an example of less structured is just being able to use simple text:
"My chart states that I am taking Lopressor. I have never taken any beta-blockers of any kind, please remove the entry for Lopressor from my chart."
Josh Mandel (Nov 24 2020 at 18:46):
(Yes, this is great -- and anticipating inevitable misuses like "I've been taking a half pill a day, but not sure if I should switch to a full pill"; having a Task based workflow here provides a good point for human review and, when needed, redirecting or rejecting a request.)
Ryan Howells (Dec 01 2020 at 01:16):
Let us know if we (CARIN) can help in anyway advance this project. I agree it's great Argonaut is considering this for 2021 and feel it's definitely the right place for this project to live. We'd be happy to work with @Josh Mandel @Micky Tripathi to bring our consumer-facing app community to the table to help test/refine the approach.
John Moehrke (Dec 01 2020 at 13:34):
I fully support Argonaut engaging with this project, but I do not agree that it should be owned by Argonaut. This project has been a hard fought victory of the Patient Empowerment family, who made an HL7 Workgroup that never existed before, so that they could OWN patient empowerment projects and HOST other workgroups.
John Moehrke (Dec 01 2020 at 13:36):
by Argonaut stomping in and taking this over, we just prove why the Patient Empowerment workgroup needs to exist.
Micky Tripathi (Dec 01 2020 at 15:49):
Hi @John Moehrke , would love to talk about how (or whether) Argonaut can be helpful in supporting the WG's work. Definitely don't want to stomp on anything. Pls DM me so we can connect. Thx!
Micky Tripathi (Dec 01 2020 at 15:57):
Thanks @Dave deBronkart . We're just at the beginning of deciding on our 2021 projects, so just exploring whether this would be helpful to the community and aligned with the WG's efforts. Really appreciate all of the feedback!
Lloyd McKenzie (Dec 01 2020 at 16:49):
I would see the PE work-group's work as being the international spec. Argonaut would localize it for US use. If they're working together, side-by-side, they can coordinate. I think that would be appropriate and useful.
Lloyd McKenzie (Dec 01 2020 at 16:50):
(Though it would be a somewhat new model for Argonaut to follow.)
Debi Willis (Dec 01 2020 at 22:07):
@Micky Tripathi, we would love Argonaut to help. Thank you for your interest and offer.
We are trying to press forward quickly in the next two weeks to be ready for the connectathon. ANY interested parties are invited to please join us to complete the specifications draft on the following dates:
Thursday December 3 @ 1 PM ET
Monday December 7 @ 3 ET
Tuesday December 8 @ 2 ET
Thursday December 10 @ 1 ET
GoToMeeting information for the sessions:
https://global.gotomeeting.com/join/322275573
You can also dial in using your phone.
United States: +1 (872) 240-3212
Access Code: 322-275-573
Michele Mottini (Dec 01 2020 at 22:35):
In preparation for those calls can we circulate a document with what need to be discussed / decided?
Michele Mottini (Dec 01 2020 at 22:36):
...and have a shared Google sheet with the Task elements must support / required?
Michele Mottini (Dec 01 2020 at 22:38):
I think we decided that Task.requester is required - this means that the servers must support openid and fhirUser, so that the client can know what to put in requester (that must be the current user)
Michele Mottini (Dec 01 2020 at 22:40):
Clients will need to query for pending tasks, so server must implement the requester search parameter (and/or patient? seems more difficult to use though)
Lloyd McKenzie (Dec 01 2020 at 22:45):
Task.requester could theoretically just be 'display'. Certainly mandating openid and fhirUser doesn't necessarily flow from saying that Task.requester is required.
Michele Mottini (Dec 01 2020 at 22:50):
Mhh, so each app can put just a piece of text there, like 'John Smith', so the server ends up with a bunch of Task with requester John Smith from different apps, and then how does it knows which is which? how do the apps query for the tasks of 'their' john smith ?
Michele Mottini (Dec 01 2020 at 23:02):
Or the user has access only to the task it created (that seems reasonable?), so the search is 'give me all tasks' - and there is no need for requester search parameter, nor to fill requester with anything unique - works from the app point of view
Lloyd McKenzie (Dec 01 2020 at 23:03):
I'm not saying it's ideal or desirable, just saying that there'll need to be some discussion if we want to make it tighter. Even if we assert a specific resource reference, that doesn't necessarily mean that openid is the only way. It should be a conscious choice that that's what we want. (I'm fine if it is.)
Michele Mottini (Dec 01 2020 at 23:05):
Discussing it is what I am doing - see another alternative above
Dave deBronkart (Dec 02 2020 at 02:07):
Josh Mandel said:
I'll probably rope folks into proofreading (and of course if you like, re-writing entirely) a short project description for the Argonaut planning process.
Thanks, @Josh Mandel - I have to say, for the record, that while I know you and absolutely trust your skillz and judgment, patient activists around the world are wary of others "taking over" a project they started, once the establishment discovers it has merit, then discovering the objectives and priorities had drifted.
So please yes do what needs to be done to move things along, and keep our WG and its intent actively involved! :smile:
And yes, absolutely happy to have expert advice on wordsmithing to fit the flow and accelerate adoption.
Virginia Lorenzi (Dec 02 2020 at 07:50):
Michele Mottini said:
In preparation for those calls can we circulate a document with what need to be discussed / decided?
This is the Profile spreadsheet we have been working on: https://docs.google.com/spreadsheets/d/1kPMzWTA8iXRzcra6SMehgIQDb6VxpNp6B_BQpCN3VRQ/edit#gid=114961663
Michele Mottini (Dec 02 2020 at 14:40):
Thanks @Virginia Lorenzi - I cannot access it though, you have to share it
Michele Mottini (Dec 02 2020 at 14:49):
Got access now, thanks. Adding some notes
Michele Mottini (Dec 02 2020 at 15:09):
and I added a sheet for searches and search parameters
Bart Carlson (Dec 02 2020 at 15:51):
@Virginia Lorenzi I can't access the Profile spreadsheet.
Virginia Lorenzi (Dec 02 2020 at 17:09):
@John Keyes @Dave deBronkart John can you change access to the google sheet so that anyone with link can see it?
John Keyes (Dec 02 2020 at 17:11):
Done
Virginia Lorenzi (Dec 02 2020 at 17:11):
If you are interested in signing up as part of our track, you can do that right on our track proposal under Expected Participants: https://confluence.hl7.org/display/FHIR/2021-01+-+Patient+Corrections
Josh Mandel (Dec 02 2020 at 18:19):
patient activists around the world are wary of others "taking over" a project they started,
100% agreed! (The proposals process hasn't begun but I'll keep this group involved from the start when it does.)
Dave deBronkart (Dec 02 2020 at 19:55):
@Josh Mandel as I'm sure you're aware, this is at least as much a practical matter of perception as anyone's alleged reality :smile:
Virginia Lorenzi (Dec 02 2020 at 21:28):
@Debi Willis @Dave deBronkart @Josh Mandel The ability to correct your data is considered an important empowerment lever - a chance to have control. In the new EHI Draft Consumer Privacy Framework: https://www.ehidc.org/resources/draft-consumer-privacy-framework-health-data#:~:text=August%2026%2C%202020%20%E2%80%93%20Today%20the,rules%20that%20should%20govern%20them., it describes the first right with respect to a consumer's health information as their right to "Access, Correct, and Delete Consumer Health Information". Through Argonaut and CARIN's efforts there has been focus on access. Our purpose is to address the other parts. Also, WHO did a study on Legal Frameworks for eHealth in 2012. It surveyed countries around the world about "rights that were granted to individuals, asking
if patients had a right to seek correction and deletion elements of the record". Sadly, this right seemed to be reserved more for individuals in wealthier countries. The study can be found here: https://www.who.int/goe/publications/legal_framework_web.pdf In the upcoming Patient Corrections Track at the January Connectathon, we are hoping to have representatives from countries other than the US.
John Moehrke (Dec 02 2020 at 21:34):
note that even in the USA the right is not equally distributed... those with more wealth can navigate the boundaries and pathways necessary, where those less well off can't. Our goal is to define a more automatable process based on interoperability, so that many applications can be developed that can leverage our specification, thus more likely that the functionality is available to everyone that has the legitimate right and/or authorization.
Josh Mandel (Dec 02 2020 at 22:22):
Note that at http://build.fhir.org/ig/HL7/fhir-patient-correction/specification.html#patient-correction-rebuttal-flow I see "Received/Disagreed" as a status/businessStatus, but I think this should say "Rejected/Disagreed". In general, it would be good to pull these details about state transitions out of the diagrams, or ensure they're not just in diagrams, since this makes it hard to search.
Josh Mandel (Dec 02 2020 at 22:23):
I'm also expecting to see details in the spec about when/how parties update fields on the Task other than statuses. What fields is each party allowed/expected to update, and when (with respect to status changes? Where are how are rationales/reasons captured (e.g., "Bob sends a statement disagreeing with the denial"?)
Josh Mandel (Dec 02 2020 at 22:24):
Where and how are requests to send downstream notifications tracked (e.g., "Bob then requests that Southside Clinic notify his insurance company (MyLifeInsurance.com) that his record has now been corrected.")?
Josh Mandel (Dec 02 2020 at 22:25):
(I expect the answers to some of these are "use .notes Annotations"; but it's worth spelling this out.)
Josh Mandel (Dec 02 2020 at 22:26):
It's also not clear to me why distinct profiles are provided for Task[request] and Task[disagreement]. Is the idea that one Task will fit (at least?) one of these profiles at any point in time, but it could switch between them when statuses change? It's hard to follow this kind of logic just from the profiles themselves.
Michele Mottini (Dec 02 2020 at 22:26):
I'm also expecting to see details in the spec about when/how parties update fields on the Task other than statuses.
I would _not_ specify those things - keep it simply
Michele Mottini (Dec 02 2020 at 22:27):
Where and how are requests to send downstream notifications tracked
Not supported / out of scope
Josh Mandel (Dec 02 2020 at 22:27):
@Michele Mottini you don't even want to say "Bob's client adds an annotation to the end of the .notes array"?
Michele Mottini (Dec 02 2020 at 22:27):
Nope
Josh Mandel (Dec 02 2020 at 22:27):
I'm assuming the use cases at http://build.fhir.org/ig/HL7/fhir-patient-correction/#use-cases define the scope! All of my questions are based on looking at these.
Josh Mandel (Dec 02 2020 at 22:27):
If you think the use cases are wrong, we should back up and discuss those. I was just taking those on faith, not trying to express an opinion one way or the other.
Dave deBronkart (Dec 02 2020 at 22:28):
@Josh Mandel being new to both IGs and Connectathons, I wonder how much of this stuff you anticipate being at this event (and thus specified before then).
(Could you help, at least by outlining what needs to be fleshed out??)
cc @Virginia Lorenzi @Debi Willis @John Keyes
Josh Mandel (Dec 02 2020 at 22:29):
The more essential bits we specify ahead of time, the less time we'll spend at connectathon scratching our heads. You need "good enough guesses" before the event, in order to drive the harder-to-reach questions/insights at the event.
Josh Mandel (Dec 02 2020 at 22:30):
Like... does the conversation happen through annotations? Or inputs/outputs? It can't be... just totally unspecified if we think the conversation matters.
Michele Mottini (Dec 02 2020 at 22:31):
Yeah, I would definitely remove 'Bob then requests that Southside Clinic notify his insurance company '
Dave deBronkart (Dec 02 2020 at 22:32):
Josh Mandel said:
The more essential bits we specify ahead of time, the less time we'll spend at connectathon scratching our heads. You need "good enough guesses" before the event, in order to drive the harder-to-reach questions/insights at the event.
That makes sense! We're just managing a desire to do a solid job in preparing for something we've never seen (some of us) so this dialog is useful.
Michele Mottini (Dec 02 2020 at 22:33):
What we discussed was using statusReason to explain why the status has been changed
Josh Mandel (Dec 02 2020 at 22:34):
Interesting, re: statusReason. That's yet another option -- highlights the point that it'll be important to say something about this!
Michele Mottini (Dec 02 2020 at 22:35):
Josh Mandel (Dec 02 2020 at 22:35):
I'm aiming to join tomorrow's call, BTW (thanks for the invite @Debi Willis). I have no specific agenda, just happy this is underway.
Josh Mandel (Dec 02 2020 at 22:35):
@Michele Mottini cool, where's that screenshot from? I have only been seeing/reviewing what's at http://build.fhir.org/ig/HL7/fhir-patient-correction
Michele Mottini (Dec 02 2020 at 22:36):
Josh Mandel (Dec 02 2020 at 22:38):
Thanks. Looking at the spreadsheet, one thing I worry about is "clobbering" the Task.description if it's being used to support a back-and-forth conversation as a Task changes states. It feels a bit odd, since the description (unlike status reason) seems designed to be more stable through the lifecycle of a Task.
Josh Mandel (Dec 02 2020 at 22:39):
(May be good to link to the spreadsheet from the IG if this is where the latest design is happening.)
Dave deBronkart (Dec 02 2020 at 22:40):
Josh Mandel said:
(May be good to link to the spreadsheet from the IG if this is where the latest design is happening.)
IG author @John Keyes note the suggestion
Michele Mottini (Dec 02 2020 at 22:41):
Each task will have only one status transition, there is really no back and forth. 'Bob sends a statement disagreeing' is a new task
Dave deBronkart (Dec 02 2020 at 22:42):
btw @Josh Mandel I believe that document is days old (not weeks/months) so you haven't been de-looped ... I also believe @John Keyes is in the process of transcribing it to a more appropriate home or format, as we speak.
Dave deBronkart (Dec 02 2020 at 22:44):
I'm a day late posting this - from this week's agenda - schedule for four calls between now and our self-imposed deadline Friday 12/11:
image.png
John Keyes (Dec 02 2020 at 22:46):
The spreadsheet is at https://docs.google.com/spreadsheets/d/1kPMzWTA8iXRzcra6SMehgIQDb6VxpNp6B_BQpCN3VRQ/edit?usp=sharing ...this is where the work is happening, but my intent is to update the FSH in the IG to match it as we go. @Dave deBronkart , the official home of the draft IG is http://build.fhir.org/ig/HL7/fhir-patient-correction
Dave deBronkart (Dec 02 2020 at 22:48):
John Keyes said:
the official home of the draft IG is http://build.fhir.org/ig/HL7/fhir-patient-correction
Yes, that's what Josh linked to above. He hadn't seen the Google Sheet because it's not mentioned in the IG, he sez. So I pinged you :smile:
Debi Willis (Dec 02 2020 at 23:46):
Part of a patient's rights (at least in the US) is to instruct the organization about who needs to be contacted concerning a correction in the chart. This is an important part of corrections so we want to address how to do that also. If I was denied insurance because of an error in my chart, I definitely want the org or notify the insurance company to set the record straight.
Lloyd McKenzie (Dec 03 2020 at 00:13):
@Michele Mottini I disagree that each Task will only have one state transition. There'll only be one Task instance through to completion or rejection. You only get a new Task if you move from rejection to a request for logging of a disagreement.
Lloyd McKenzie (Dec 03 2020 at 00:13):
The Task will be stored in the EHR and will be updated by multiple parties through its lifecycle.
Lloyd McKenzie (Dec 03 2020 at 00:13):
In general, the Task.description shouldn't change.
Lloyd McKenzie (Dec 03 2020 at 00:14):
(Though it could potentially be refined with additional detail if that could be done safely without losing the patient's original intention)
Michele Mottini (Dec 03 2020 at 00:31):
Mhh, the task can go received -> accepted, or received -> rejected - which other transitions there are?
What happens _internally_ to the provider system can be anything and everything of course, but not something that is interesting for the client to see or for the implementation guide to specify - the implementation guide is about client - server communication
Michele Mottini (Dec 03 2020 at 00:34):
This is an important part of corrections so we want to address how to do that also.
Leave it for version 2.0
Josh Mandel (Dec 03 2020 at 00:39):
I thought the write-up taking a single task into a rejected, disputed, and finally resolved state was compelling -- if you use a whole new Task, then you have the challenge of linking/referencing across them.
Michele Mottini (Dec 03 2020 at 00:46):
The decision was to use a separate task, referencing the original one using Task.input
Josh Mandel (Dec 03 2020 at 00:50):
Ok. Sounds like I should wait a bit until the spec incorporates these decisions, and will review then!
Debi Willis (Dec 03 2020 at 01:24):
I think everything is still in the phase of discussion to make sure we are considering all possible impacts to a particular option. We will dig deeper into the draft spec tomorrow. We value insight from each of you. We don't want to get bogged down, but we also don't want to miss important insight. Please show up and we can have some great minds working on this together.
Here is the call in information for the meeting tomorrow at 1 PM ET:
https://global.gotomeeting.com/join/322275573
You can also dial in using your phone.
United States: +1 (872) 240-3212
Access Code: 322-275-573
Lloyd McKenzie (Dec 03 2020 at 04:16):
Received -> accepted -> completed. Received -> Accepted -> in-progress -> on-hold -> in-progress -> completed
Lloyd McKenzie (Dec 03 2020 at 04:16):
And various other paths
Lloyd McKenzie (Dec 03 2020 at 04:17):
Logic for a distinct task is that the patient is actually asking for something different - and the wording the patient wants to be recorded in the record might be different once they see the initial rejection. As well, the data being submitted might be different.
Virginia Lorenzi (Dec 03 2020 at 04:39):
Michele Mottini said:
Mhh, the task can go received -> accepted, or received -> rejected - which other transitions there are?
What happens _internally_ to the provider system can be anything and everything of course, but not something that is interesting for the client to see or for the implementation guide to specify - the implementation guide is about client - server communication
You can go from received to accepted to completed. You can go from received to received - extended to accepted to completed. You can go from received to received-extended to rejected. For disagreement, rebuttal adds a shade to the state transition as well. Also, while the task is in a state, the requester could send an update. I need to update the state machine based on our last meeting and then will repost it.
Virginia Lorenzi (Dec 03 2020 at 04:47):
Josh Mandel said:
Thanks. Looking at the spreadsheet, one thing I worry about is "clobbering" the
Task.descriptionif it's being used to support a back-and-forth conversation as a Task changes states. It feels a bit odd, since the description (unlike status reason) seems designed to be more stable through the lifecycle of a Task.
We plan to give up the spreadsheet soon and just update the IG. Its our training wheels. @John Keyes in he meantime, see what Josh is suggesting - to link to the spreadsheet as the latest until we give it up. Sorry for the confusion!
Virginia Lorenzi (Dec 03 2020 at 04:51):
Virginia Lorenzi said:
If you are interested in signing up as part of our track, you can do that right on our track proposal under Expected Participants: https://confluence.hl7.org/display/FHIR/2021-01+-+Patient+Corrections
SORRY CHANGED NAME OF DOCUMENT: New link: https://confluence.hl7.org/display/FHIR/2021-01+-+Patient+Empowerment%3A+Patient+Corrections
Virginia Lorenzi (Dec 03 2020 at 05:11):
About the statuses and state diagram - we met last week and decided that the "received" status was not needed - requested was enough. I reviewed our original state diagram (which is in the draft spec now) and updated it in this powerpoint to reflect that as well as to fix an error on the Disagreement Flow. Rebuttal is an optional state. https://docs.google.com/presentation/d/1t1X4jn_8DTgaumaTN9hzQvVkB0LF7zFu/edit#slide=id.p4 We are currently using business status but perhaps its not needed - something to think about. Also, it is possible for a patient to cancel a correction request. A patient could also update a correction request. For example, when they learn their request is accepted, they might update their request to include who to notify with the corrections when they are completed (this example is from the HIPAA workflow guide).
Virginia Lorenzi (Dec 03 2020 at 07:25):
Josh Mandel said:
Ok. Sounds like I should wait a bit until the spec incorporates these decisions, and will review then!
Its in the profile for the disagreement - see the google sheet: https://docs.google.com/spreadsheets/d/1kPMzWTA8iXRzcra6SMehgIQDb6VxpNp6B_BQpCN3VRQ/edit#gid=114961663
John Keyes (Dec 03 2020 at 16:05):
I've added a note to the beginning of the draft IG with a link to the Task spreadsheet.
https://build.fhir.org/ig/HL7/fhir-patient-correction/
Dave deBronkart (Dec 03 2020 at 16:18):
John Keyes said:
I've added a note to the beginning of the draft IG with a link to the Task spreadsheet.
https://build.fhir.org/ig/HL7/fhir-patient-correction/
You are so collaborative!! Such a team player!
Abbie Watson (Dec 03 2020 at 18:13):
Debi Willis said:
Part of a patient's rights (at least in the US) is to instruct the organization about who needs to be contacted concerning a correction in the chart. This is an important part of corrections so we want to address how to do that also. If I was denied insurance because of an error in my chart, I definitely want the org or notify the insurance company to set the record straight.
This is an argument that we need to add Communication and CommunicationRequest to the IG. Or at least, add a CommunicationRequest within a transaction bundle within Task.input.
Michele Mottini said:
Yeah, I would definitely remove 'Bob then requests that Southside Clinic notify his insurance company '
Michele has a point, to the extent that Communication and CommunicationRequests are lower priority. Yet, if we're going to model the downstream communications mandated by HIPAA, then we need to include them.
John Moehrke (Dec 03 2020 at 18:21):
would seem this communication, which I agree is important, but I was expecting this to be patient-app side functionality. It does not seem to be critical to the workflow between the two actors we have. At least it should be considered an optional flow, as I do expect most patient-app that chose to implement this IG will already have a mechanism for this communication with the patient.
Lloyd McKenzie (Dec 03 2020 at 19:34):
CommunicationRequest might be a little heavy - depends how much information we need to convey. In terms of whether it should be the app or the provider that does the communication, it sort of depends who will have the mechanism to connect to the target and deliver it. It could be either side. For those situations where the provider can do it and the app can't, including that in the request is reasonable.
Lloyd McKenzie (Dec 03 2020 at 19:34):
Also, whether we like it or not, data coming from the EHR is likely to be more trusted than data coming from a patient app.
Abbie Watson (Dec 03 2020 at 20:43):
Okay, I just updated the sequence diagram with all the latest knowledge I have about what has been discussed by all the stakeholders. I've created a separate Zulip thread, where we can discuss particulars rather than bogging down this thread.
Debi Willis (Dec 03 2020 at 22:46):
The patient will be making the request to the provider to communicate with the people identified by the patient. The patient will not be communicating directly with the people on the list. An example might be: "Please let Dr. Spock (123 main street, mytown, USA) and AviationInsurance (patientservices@avi.org) know that you have corrected my chart to remove "substance use disorder" from my chart."
Abbie Watson (Dec 04 2020 at 18:57):
Sure. And if I have that provider's address is in a vCard or I'm fetching it via FHIR from Salesforce or Outlook? Or have extracted it from my Apple HealthRecords?
The patient may not be communicating directly with the downstream providers, but they may have the structured data on who to contact, and be sending that info along via a FHIR Person resource (rather than a text string or narrative text).
Virginia Lorenzi (Dec 07 2020 at 19:33):
John Moehrke said:
would seem this communication, which I agree is important, but I was expecting this to be patient-app side functionality. It does not seem to be critical to the workflow between the two actors we have. At least it should be considered an optional flow, as I do expect most patient-app that chose to implement this IG will already have a mechanism for this communication with the patient.
Just to clarify - this is not about communication with patient. Its a request by the patient that the provider communicate the corrected record to others that the patient designates.
Virginia Lorenzi (Dec 07 2020 at 19:35):
Abigail Watson said:
Debi Willis said:
Part of a patient's rights (at least in the US) is to instruct the organization about who needs to be contacted concerning a correction in the chart. This is an important part of corrections so we want to address how to do that also. If I was denied insurance because of an error in my chart, I definitely want the org or notify the insurance company to set the record straight.
This is an argument that we need to add Communication and CommunicationRequest to the IG. Or at least, add a CommunicationRequest within a transaction bundle within Task.input.
Michele Mottini said:
Yeah, I would definitely remove 'Bob then requests that Southside Clinic notify his insurance company '
Michele has a point, to the extent that Communication and CommunicationRequests are lower priority. Yet, if we're going to model the downstream communications mandated by HIPAA, then we need to include them.
@Abigail Watson I am confused when you say "a transaction bundle within task.input". I thought is would just be an array of task.input values - no need for a transaction since its in task and no need for a bundle. Also transaction is an operation so how would you put that in the task? Could be a limit on my FHIR knowledge here - thanks. @Lloyd McKenzie
Virginia Lorenzi (Dec 07 2020 at 19:40):
Lloyd McKenzie said:
CommunicationRequest might be a little heavy - depends how much information we need to convey. In terms of whether it should be the app or the provider that does the communication, it sort of depends who will have the mechanism to connect to the target and deliver it. It could be either side. For those situations where the provider can do it and the app can't, including that in the request is reasonable.
I agree - that's why I had it as a free text. However, CommunicationRequest is also an option but I think both need to be supported.
Abbie Watson (Dec 07 2020 at 19:40):
Hi. ‘Transaction bundle’ is totally up for interpretation at this point and my shorthand for a few ideas. So far, I’ve heard three main proposals... a) slicing the Task.input field, effectively making it typed, and adding resources or operation requests as an array; b) punting on the issue by putting a Bundle into Task.input, which is effectively a wildcard, or c) using Task.partOf and putting each operation request or resource into a sub-task.
Abbie Watson (Dec 07 2020 at 19:41):
I’m open to any/all of the above, if somebody puts the effort into putting an implementation together to test it.
Lloyd McKenzie (Dec 07 2020 at 23:07):
Task.input is going to need to be sliced regardless - there are multiple inputs we'll need and the profile will need to distinguish them. Going with sub-tasks would allow us to convey the status of each 'communication target' independently (e.g. I told Insurer A and Dr. Jones, but couldn't get hold of Insurer B and Dr. Smith isn't at that phone number any more). Don't know if that's an essential thing to have sent discretely. If a text blob in Task.note would suffice, then I'd avoid sub-tasks. CommunicationRequest is tricky because if you're going to have a CommunicationRequest you need to be able to indicate what you want communicated - which is something that doesn't yet exist. Also, technically, a CommunicationRequest is just an authorization for sharing, not a true 'request' to share. So using it 'right' is probably going to be somewhat big and ugly. That's why my leaning was to just use Task.input -either to list the individuals or to provide a text blob for that purpose.
Virginia Lorenzi (Dec 10 2020 at 08:28):
@Vassil Peytchev @Lloyd McKenzie there is still disagreement about the way to link disagreement to the initial request. Vassil thinks it should go in Task.partof. I think it should go in Task.partof or Task.basedon. Lloyd says Task.input. My logic - I think it is possible to do a bare bones unstructured request task with no inputs and that would be a feature for less sophisticated systems
Virginia Lorenzi (Dec 10 2020 at 08:29):
Also - do we need to look inside the DomainResource fields in task and profile those at all?
Lloyd McKenzie (Dec 10 2020 at 14:40):
@Vassil Peytchev The issue with putting it in Task.partOf is the state machine. Once a Task is rejected, then defining something as 'part of' that Task or 'based on' that Task doesn't get you anywhere. Also, 'based on' is about the chain of authorization, and we're not really talking about authorization when we say that Task B is a disagreement about information in the record that Task A was attempting to correct. There's no 'standard' semantic in Task for that relationship, so I think you pretty much have to use either Task.input or an extension.
Vassil Peytchev (Dec 10 2020 at 14:55):
What is it in the state machine that prevents a secondary task to be partOf a previously rejected/completed Task? The main point is the "disagreement" step cannot take place without the previously rejected request, and a profile-required Task.partOf seems the obvious way to express that.
Lloyd McKenzie (Dec 10 2020 at 14:57):
My understanding is that if a Task is rejected, everything that's part of it is rejected. That's not a 'hard' rule, but it's a pretty common expectation. Also "please flag my record as having a disagreement" isn't really part of the action "please fix this data".
Vassil Peytchev (Dec 10 2020 at 15:03):
Also "please flag my record as having a disagreement" isn't really part of the action "please fix this data".
"please flag my record as having a disagreement" is contingent on an existing rejected "please fix this data". It cannot exist on its own.
Lloyd McKenzie (Dec 10 2020 at 15:07):
I'm not sure that's strictly true, but even if it is "contingent on" is not the same as "part of" or "authorized by".
Last updated: Apr 12 2022 at 19:14 UTC
