FHIR Chat · Sequence Diagram - Patient Corrections

Stream: patient empowerment

Topic: Sequence Diagram - Patient Corrections

Abbie Watson (Dec 03 2020 at 20:35):

I would like to submit the following sequence diagram for consideration. I've sat in most every call and am well versed in the specification, and were I to implement the use cases myself, this is how I'd go about it.

Patient-Corrections-.png

Michele Mottini (Dec 03 2020 at 20:46):

The implementation guide is about the interaction between patient phr and provider ehr - I don't think we should care about what happens inside the ehr

Abbie Watson (Dec 03 2020 at 20:49):

Sure, but we need to anticipate what happens inside if we're going to design something useful. This is more about identifying the actors and sequence of events. Otherwise, we're going to continue going around in circles.

The final implementation sequence diagram will be a scaled down version. But we need to have clarity and agreement about details like whether the EHR is architected with ancillary systems in mind, whether it has task queues, and inbound processing queues, and so forth.

Abbie Watson (Dec 03 2020 at 20:52):

Also, HIPAA regulations mandate what occurs within the EHR and downstream systems by law with regard to this flow. At least in the US.

Josh Mandel (Dec 03 2020 at 20:52):

Agreed! This sequence diagram is great, and for me it helps put a finer point on what's in scope for our IG. I'd suggest that our scope should be basically what you've included under "does the EHR support Task?" -- plus we need more details about the various workflows of rejection, follow-ups, and so on.

Abbie Watson (Dec 03 2020 at 20:56):

@Josh Mandel - The one caveat with scoping it down to Task, is that we basically set ourselves up for failure the first connectathon. How many participants are willing to commit to building out the Task resource in less than a month? It's not on Epic or Cerner's supported API documentation. But writable Condition and Observation are, which support LOINC and SNOMED codes for smoking, and therefore qualify for the usecase and are in production.

I don't want egg on my face, when we show up and there are no EHR vendors at the table because we're off specifying an IG that they haven't bought into, or have recommended alternative approaches.

This isn't simply the Task IG. It's the Patient Correction IG.

Michele Mottini (Dec 03 2020 at 20:58):

we need to anticipate what happens inside if we're going to design something useful.

I very much disagree - that's going to bog us with a ton of details that are irrelevant to the actual use. Patient submit request (1) and then, request is accepted (2a) or request is rejected (2a), if request is rejected submit complain (3)

Abbie Watson (Dec 03 2020 at 21:04):

@Michele Mottini We have vendors asking for different implementations of how that request is initiated. Some are asking for direct API writes, some are asking for CommunicationRequest, and then we have Lloyd and HL7 recommending Task, which isn't widely supported or used.

CapabilityStatement on /metadata addresses these things, and it can provide the necessary details to inform the PatientPortal in HOW to make that request.

John Moehrke (Dec 03 2020 at 21:08):

This IG should be transport agnostic. that is to say it should focus on the workflow and communication of critical facts. If that is communicated by Direct, IHE, FHIR POST, FHIR Message, HL7 v2 message, CDA ... should not matter.

John Moehrke (Dec 03 2020 at 21:09):

oh, avian carrier too.... carrier pigeons are important to keep employed.

Josh Mandel (Dec 03 2020 at 21:09):

Strongly disgree @John Moehrke. If we're not specific, we'll have a mess.

John Moehrke (Dec 03 2020 at 21:09):

but Not FAX

Abbie Watson (Dec 03 2020 at 21:09):

Some of us want to actually implement this thing and start correcting records.

John Moehrke (Dec 03 2020 at 21:10):

Josh, I am happy with a specific connectathon choosing a transport. My point was about the IG, not connectathon.

Josh Mandel (Dec 03 2020 at 21:10):

I don't want egg on my face, when we show up and there are no EHR vendors at the table

@Abigail Watson that's fair! @Michele Mottini would Careevolution be in a position to prototype the server side of a Task interface?

Josh Mandel (Dec 03 2020 at 21:13):

(Or, are there others from the vendor side who might try?)

Josh Mandel (Dec 03 2020 at 21:13):

Re: January, I wouldn't necessarily put "2+ EHR Vendors participating" as a success criterion. Even testing against a reference implementation of a server would be a fine sanity check; we're still very early.

John Moehrke (Dec 03 2020 at 21:15):

agree, as even one system can help us produce examples that can guide the profilng and guide others.

Michele Mottini (Dec 03 2020 at 21:16):

I was thinking to work on the client part, our app is much more used than our system-as-an-EHR. @Jeff Danford talked about implementing the server part

Abbie Watson (Dec 03 2020 at 21:16):

To be clear, I'm not trying to suggest the above sequence diagram is what EHR vendors aught to implement internally. I was documenting all the different flows that have been presented during conversations. I'm of the opinion that the solution should be a venn diagram of request mechanisms (avian carriers included), that helps onramp and harmonize the different approaches. Hoisting things up through protocols, depending on what's in the CapabilityStatement and whether the Patient has structured data on hand or is working from paper.

Josh Mandel (Dec 03 2020 at 21:21):

A spec like "A or B or C... depending on what the server supports" is IMHO the most common failure mode of the SDO consensus process.

Abbie Watson (Dec 03 2020 at 21:23):

Anecdotal, but I'm certainly willing to hear that out and change my opinion accordingly.

Is creating an IG the same as SDO consensus, though? Should this be split into separate IGs?

Josh Mandel (Dec 03 2020 at 21:23):

I mean, as the IG(s) makes it through formal review, it will come to represent the "best" consensus we're able to achieve.

Abbie Watson (Dec 03 2020 at 21:24):

I feel like this has become the Task IG, and not the PatientCorrection IG though.

Josh Mandel (Dec 03 2020 at 21:24):

I think it's becoming the "Patient Corrections IG, (descriptive clause) which is best implemented via Task" IG.

Josh Mandel (Dec 03 2020 at 21:25):

And if Task isn't in fact a good fit, we should pick something else; but darn it we should pick something.

Abbie Watson (Dec 03 2020 at 21:26):

Both IGs are needed. But Task isn't the only game in town. And separate from the IG, is the tangible need to make the corrections. Some of us are concerned about the pragmatic realistic aspects of putting this into production; not simply maturing the spec, or semantic integrity, etc.

Abbie Watson (Dec 03 2020 at 21:27):

As an implementor, I'd take an IG that supports 50% of current EHRs via existing API endpoints, over an IG that supports 0% of current EHRs with an experimental API endpoint.

John Moehrke (Dec 03 2020 at 21:27):

where the IG starts does not need to be where it ends up.

Josh Mandel (Dec 03 2020 at 21:28):

This is why building consensus is important! If EHR vendors see a path to supporting Task because it's easy and fits the problem well... then perfect. If there's a better approach (pragmatically assessed) then let's instead drive toward consensus on that.

John Moehrke (Dec 03 2020 at 21:28):

I have seen IG start very basic and end up comprhensive... I have seen IGs start with glory in the eyes of everyone and they ended up with twitter

Josh Mandel (Dec 03 2020 at 21:29):

I think right now, our best focus is to get out a spec with conceptual integrity, that's small and so straightforward that people see it and say "oh, I can do that".

Josh Mandel (Dec 03 2020 at 21:30):

That's the input to a longer and more complex consensus process.

Abbie Watson (Dec 03 2020 at 21:30):

I can certainly recut the sequence diagram to focus on just the Task portion for the connectathon. No problem there.

John Moehrke (Dec 03 2020 at 21:30):

Josh, would be very educational if we could get a Task resource with instances all along the pathway

Michele Mottini (Dec 03 2020 at 21:30):

What is the way to send corrections with existing API end points?

John Moehrke (Dec 03 2020 at 21:30):

FSH should make that real easy

Josh Mandel (Dec 03 2020 at 21:30):

Agreed, that's a set of examples (and narrative around them) that belongs in the IG.

John Moehrke (Dec 03 2020 at 21:30):

yes

Abbie Watson (Dec 03 2020 at 21:31):

Michele Mottini said:

What is the way to send corrections with existing API end points?

POST /Observation
POST /Condition
PUT /Observation
PUT /Condition

Which are supported by Epic and Cerner. We've had one request from Epic that we use those endpoints, when possible.

Josh Mandel (Dec 03 2020 at 21:31):

Those don't enable corrections though, right? They just create new data.

Abbie Watson (Dec 03 2020 at 21:32):

And therein is the rub.

Josh Mandel (Dec 03 2020 at 21:32):

Oh, you slipped the PUTs in later :)

Abbie Watson (Dec 03 2020 at 21:32):

lmao.... getting there, getting there!

Josh Mandel (Dec 03 2020 at 21:32):

The PUTs conceivably help, but I think they fall well short.

Abbie Watson (Dec 03 2020 at 21:32):

Yeah, even in a best case scenario, they're not sufficient. But they are currently available.

Abbie Watson (Dec 03 2020 at 21:33):

Hence my interest and thinking they should be part of the IG, so that we're setting implementors up for success.

John Moehrke (Dec 03 2020 at 21:33):

fun to think that one could use PUT with the Provenance x-header

Abbie Watson (Dec 03 2020 at 21:34):

I wish we were having more discussions about those sorts of things.

John Moehrke (Dec 03 2020 at 21:34):

I have to get Provenance mentioned in all streams

John Moehrke (Dec 03 2020 at 21:35):

see http://build.fhir.org/provenance.html#header

Abbie Watson (Dec 03 2020 at 21:35):

I debated putting it in the test scripts, but for the time being I think it goes in Task.input. That's been my concession to brevity and keeping the scope simple to start.

John Moehrke (Dec 03 2020 at 21:35):

the provider could look at the provenance (which we would profile for this use) and say YEAH, NA, or maybe

Michele Mottini (Dec 03 2020 at 21:38):

Which are supported by Epic and Cerner

Cerner does not (?) - see http://fhir.cerner.com/millennium/r4/general-clinical/condition/#create

Abbie Watson (Dec 03 2020 at 21:39):

Documentation may be out of date? It's writable when you set up an app.

Screen-Shot-2020-12-03-at-3.38.50-PM.png

Abbie Watson (Dec 03 2020 at 21:39):

Ooops! Condition only, not Observation. I think it's Epic that recently added support for writing Observations.

John Moehrke (Dec 03 2020 at 21:41):

in my case I can write to the PHR and provide links to clinican EHR... or send a "message".. but thinking that we had one place where a Task could be cooperatively CRUD is folly.

Abbie Watson (Dec 03 2020 at 21:41):

@Michele Mottini - thank you. I'd take that as an argument for removing Observation and the smoking status LOINC codes, and only focusing on Condition and SNOMED codes then.

Abbie Watson (Dec 03 2020 at 21:43):

@John Moehrke - Which is why the optional Communication block should be in there. I hear you that some systems are going to be messaging only.

Michele Mottini (Dec 03 2020 at 21:43):

According to the Cerner R4 documentation both Observation and Condition are writable but only by provider or system apps, not patient ones

Michele Mottini (Dec 03 2020 at 21:44):

Epic docs say that they are both writable but 'they might behave differently for patient apps'

Michele Mottini (Dec 03 2020 at 21:45):

Never tried either

Abbie Watson (Dec 03 2020 at 21:45):

Honestly, I think that PUT Condition is the only API endpoint that could currently resolve a patient generated request to correct smoking status.

I'm almost at the point of voting against any IG or track that doesn't have at least that API endpoint in it. Otherwise it's just setting everybody up for failure. Especially me as a track lead. $0.02

Vassil Peytchev (Dec 03 2020 at 21:52):

I don't think any existing APIs support the use case for a formal request for corrections, is that correct?

Josh Mandel (Dec 03 2020 at 22:00):

I strongly agree @Vassil Peytchev

Lloyd McKenzie (Dec 03 2020 at 23:58):

I don't think the IG should try to standardize anything around the use of PUT or PATCH, but it shouldmention that EHRs may sometimes allow patients to make corrections to data directly, specifically for demographics, patient-sourced data, etc. and that, if available, these should be used. We can similarly call out the option of using batch/transaction if desired, but no need for our IG to constrain/profile/test these.

I don't think the IG should talk about using CommunicationRequest at all. It's not the right resource. "It's wrong but it's implemented" means it's still wrong. It may be that the initial connectathon doesn't have a ton of participants, but that's ok. If all you've got is one on each side and you can test out some scenarios, that's a valid win for connectathon #1. Throwing Communication in the mix just means that a) implementers waste time building something that's throw-away, or b) we fork the implementation community and get no interoperability. Neither are desirable.

In terms of notifying downstream providers, we shouldn't specify how that's done. The mechanism used will be the same mechanism the provider uses to notify those downstream systems normally - could be POST/PUT, could be subscription notification, could be message, could be v2. We don't care. Not our problem.

Brendan Keeler (Dec 04 2020 at 05:45):

If we list thirty ways to do it, it will be done thirty different ways.

Brendan Keeler (Dec 04 2020 at 05:47):

Just catching up on this chain but optionality here is kinda silly. Which of these flows are the baseline requirement that can be counted on and which are the optional enhanced offerings?

Brendan Keeler (Dec 04 2020 at 05:55):

We inherently build in complexity into the system by not having prescriptive baseline capabilities that can be counted on across organizations and EHRs.

Debi Willis (Dec 04 2020 at 18:26):

@Josh Mandel , @Jeffrey Danford has offered to set up a server for our track and he knows that we are going to use Task. My assumption is that he is going to prototype the server side of the Task interface. @Jeffrey Danford , can you confirm for the group?

Abbie Watson (Dec 04 2020 at 18:48):

Okay, so I updated the Consolidated Workflow document. Primarily involving the optional step of whether or not the patient has fetched their records electronically and have the structured data on hand. This is a precondition that we're not aligned on, and a major point of consideration in how this IG will eventually take shape. It's significant enough that it may fork the IG into two... PatientCorrectsWithStructuredData and PatientCorrectionsForPaperWorkflows.

Patient-Corrections-Smoking-Status-Consolidated-Workflows.png

Abbie Watson (Dec 04 2020 at 18:50):

I also created a slimmed down version for Connectathon 26 and the initial version of the IG, which doesn't include authentication, a number of the optional workflows, ancillary systems, etc. It focuses on Task and writing to the Condition endpoint.

Patient-Corrections-Smoking-Status-Connectathon-26-Track.png

Lloyd McKenzie (Dec 04 2020 at 19:48):

For the connectathon, I don't think there's any reason to include either direct write or the use of patch. We already know how those work and they've been well tested (though I don't know that any EHRs support PATCH as yet.) If we do include passing in proposed patches and executing them, I'd stick it in the "bonus points" part of the scenarios. It shouldn't be part of the table stakes to play.

Abbie Watson (Dec 04 2020 at 19:57):

With all due respect, because it's the PatientCorrections track, not the Task track. Implementors like myself want to know how to write to those EHRs. You may already know how those work, but the patient community does not. It needs to be in here.

Lloyd McKenzie (Dec 04 2020 at 19:59):

Ok, but there are already tracks that handle basic RESTful read (and write) to EHRs - e.g. the US Core track. There's no reason to duplicate that in ours, I think?

Lloyd McKenzie (Dec 04 2020 at 19:59):

(Though we should certainly make members of the patient community aware of the other relevant tracks.)

Josh Mandel (Dec 04 2020 at 21:23):

(I'm pretty much with Lloyd on this; if we keep it, might confine it to its own "scenario", and maybe mark it as extra/bonus/extended functionality.)

Dave deBronkart (Dec 07 2020 at 17:20):

Lloyd McKenzie said:

Ok, but there are already tracks that handle basic RESTful read (and write) to EHRs - e.g. the US Core track. There's no reason to duplicate that in ours, I think?

When Josh & Lloyd agree on advice like this it's pretty potent. At the same time, though, we (HL7 through this WG) explicitly want to proactively
engage a new community of patient-oriented collaborators in HL7's work), so when someone as committed as Abbie has such a concern and is less deep-FHIR-savvy, it seems wise to include in the IG (prominently?) a pointer to that other work, yes?

My own initiation into The Ways of HL7 has been painful & stymieing enough that I hope my "suffering" can lead to everyone anticipating how future newbies might stumble, and providing mid-route "caution signs" and/or trail markers.

(Yes, I'm using a "trailblazer" metaphor intentionally, because we want others to follow, and to not be daunted and turn back!)

Lloyd McKenzie (Dec 07 2020 at 18:47):

I think there are two questions here:

what should be in the IG
what should be in the connectathon track

For the former, there should absolutely be a mention of the jurisdictional IGs that define RESTful interface expectations as well as references to a few examples, including US Core

For the latter, I believe that there's an area in each track description to call out other related/relevant tracks. I'd probably list the Patient, Argonaut and Da Vinci Patient Access API tracks as ones that those interested in "patient corrections" might also be interested in or want to leverage. And reaching out to those tracks and asking them to include a link to the Patient Correction track (and maybe even scheduling a joint session at the connectathon track itself) would be appropriate. Cross-pollination is definitely a good thing.

Drew Torres (Dec 07 2020 at 23:07):

For the diagrams, what do the rectangles with opt denote?

Drew Torres (Dec 07 2020 at 23:07):

Is task required and the other optional?

Lloyd McKenzie (Dec 07 2020 at 23:09):

yes

Drew Torres (Dec 07 2020 at 23:13):

I agree with Abigail. The biggest problem to date with participating in this track at all is because of the inclusion of task. I would prefer to see the IG define the set of interactions to make a patient correction work. Define how a system should preform when a patient app does post /Condition.

Task is extremely complicated to implement because of how generic it is. I also don't understand how a patient managing a providers task list helps.

Lloyd McKenzie (Dec 07 2020 at 23:30):

@Drew Torres We need to post a resource that says "please correct this data problem". We also need to understand the response to that request and see where things are at if it's taking a while. Task seems to be the only resource we have that meets that need. Task is the only way to ask for something to be done that also allows tracking progress. CommunicationRequest can't do that - and also doesn't have the semantics of 'please change'.

Note that POSTing a Task to an EHR endpoint doesn't mean that we're managing any particular provider's task list. It's possible that the POSTed Task could end up in a provider's task list if that's how the EHR chooses to handle them.

What is the complexity you're seeing here?

When you say that you'd prefer to "see the IG define the set of interactions to make a patient correction work", can you say what that means other than identifying the specific RESTful operations and resources to use to perform the function (which I think is what we're doing...)?

Drew Torres (Dec 07 2020 at 23:32):

Except the interactions you requiring are all on task... So less about the interactions and more about the resource.

Lloyd McKenzie (Dec 07 2020 at 23:34):

The interactions, from the perspective of the patient app, are "create the Task" and "monitor the Task" (poll/subscribe). The interactions from the EHR's request are "update the Task to reflect status"

Drew Torres (Dec 07 2020 at 23:35):

Right...and from an EHR implementation for Cerner... That is just impossible. I would have to effectively create a new patient "task" area that I then have to integrate to clinical workflows.

Drew Torres (Dec 07 2020 at 23:35):

So the patient app experience is great and app and patients get to do all sorts of things, but providers can't use it.

Lloyd McKenzie (Dec 07 2020 at 23:35):

Ok. What is the current clinical workflow we'd be integrating with for Cerner?

Lloyd McKenzie (Dec 07 2020 at 23:36):

And how would that expose via resources right now?

Drew Torres (Dec 07 2020 at 23:36):

You post/patch/put on a resource to integrate to the existing provider workflow.

Lloyd McKenzie (Dec 07 2020 at 23:39):

Issues:

the patient may not know the resource
the patient may not have the right to change the resource
the target information might not even be exposed as a resource
once accepted, the expectation is that the resource accepted as changed that everyone who could see the original resource sees the change. (Anything else is unsafe). My understanding is that's not the proposed Cerner behavior

Lloyd McKenzie (Dec 07 2020 at 23:41):

That's why we're not using PATCH/PUT. Obviously if those were options (no human review required, patient can just make the change), then that's the choice. However, if there's an asynchronous process where a change is requested but isn't immediately accepted, PATCH/PUT don't work.

Drew Torres (Dec 07 2020 at 23:43):

They are interacting directly with the resource? I figured an app would abstract that away... I didn't know patients were doing direct http calls on endpoints.
And a task changes that?
And a post for adding something is worse than a task to request something be added?
That understanding is wrong.

Drew Torres (Dec 07 2020 at 23:44):

Not sure why asynchronous processing matters in this context. You can do a post/put that I can respond with success/operationoutcome that says the data may be delayed in being reflected in the resource.

Lloyd McKenzie (Dec 07 2020 at 23:46):

A POST/PUT needs to come back with a 200 or a 4xx. If it comes back with a 200, that means the change is made - and everyone can see it. And that has to happen in the timeout period. If you're kicking off a human review process, then you need more than just "Delete this Observation" - you need the story from the patient that says "this observation that says I had 2 abortions is wrong, I've never been pregnant". A PUT/POST gives you no way to say that. A Task does.

Lloyd McKenzie (Dec 07 2020 at 23:48):

Creating the Task says "this is a to-do item" and then allows that item to be managed. The same process is used to say "please fill out this form" or "please suspend this prescription" in cases where the change can't be made directly and requires human review/decision.

Drew Torres (Dec 07 2020 at 23:48):

I thought http 202 solves that problem?

Lloyd McKenzie (Dec 07 2020 at 23:49):

But how are you going to convey the information about the reason why? Or the fact that the change needs to be made before the patient's surgery in two weeks? Or handle the fact that the patient saw the bad data in their web viewer but has zero clue what resource id (if any) corresponds to that problem?

Lloyd McKenzie (Dec 07 2020 at 23:50):

What we're doing here is replacing the "send a formal letter" process that exists now.

Drew Torres (Dec 07 2020 at 23:51):

No worries... Didn't mean to start a design chat. I was just jumping in because I got asked a few times about participating in the track as a server, and needed to catch up on the current line of thinking.

Lloyd McKenzie (Dec 07 2020 at 23:53):

Design chats are fine if they help clarify current line of thinking :) Does the use of Task make more sense now? Or, given the clearer context, is there something else you think we should be exploring?

Drew Torres (Dec 07 2020 at 23:57):

Sorry you might be asking the wrong guy that question. I absolutely think task is unnecessary in this context. I think it adds implementation complexity that just doesn't need to be there. I literally cannot implement task in current architecture and workflows.

I think my comments around post/patch/put should be explore more because those APIs exist. reads/write/updates are live in production for thousands of health systems across the country making it feel like a great path to adoption of the IG. Just need to define the rules of how to use those existing APIs as a patient/proxy workflow.

Michele Mottini (Dec 07 2020 at 23:59):

@Drew Torres this is Nancy Smart data from your sandbox as shown in our app. How do we convey 'no, I never had a rabies vaccine'

image.png

Lloyd McKenzie (Dec 08 2020 at 00:00):

That's interesting because Hans has signed off on using Task for Da Vinci CDex to allow a payer to ask for information from a provider.

Drew Torres (Dec 08 2020 at 00:01):

Michele Mottini said:

Drew Torres this is Nancy Smart data from your sandbox as shown in our app. How do we convey 'no, I never had a rabies vaccine'

When we support patient workflows.. You would patch the status to entered-in-error logged in as a patient.

Lloyd McKenzie (Dec 08 2020 at 00:01):

The "patient correction" use-case we're trying to solve is "Please have a clinician or administrator look at this request, including its justification and decide what to do, then do it". PUT/POST on the relevant resource won't do that.

Drew Torres (Dec 08 2020 at 00:01):

Why is that?

Drew Torres (Dec 08 2020 at 00:02):

Why can't a patch of status not do that?

Lloyd McKenzie (Dec 08 2020 at 00:02):

Where does the supporting information go?

Drew Torres (Dec 08 2020 at 00:02):

That is an EHR implementation detail. The request is routed to the appropriate clinical workflow.

Michele Mottini (Dec 08 2020 at 00:03):

Got it, thanks Drew

Drew Torres (Dec 08 2020 at 00:03):

NP!

Lloyd McKenzie (Dec 08 2020 at 00:05):

"That is an EHR implementation detail" - don't understand. I want to be able to say the following:

please change the record that asserts that I am diabetic. I do have a high A1C record, but that test was determined to be an anomoly and my GP Dr. Smith has confirmed that I am not diabetic. Please ensure this change is effective in my record no later than Feb. 23, when I am scheduled for surgery". How can that be done in a PUT/POST?

Lloyd McKenzie (Dec 08 2020 at 00:06):

Because that is what the clinician/administrator needs to see when they're evaluating my request to mark the Condition record as 'entered in error'.

Lloyd McKenzie (Dec 08 2020 at 00:06):

(And the Feb. 23 date needs to be discrete data so the EHR can appropriately prioritize requests for review.)

Drew Torres (Dec 08 2020 at 00:08):

Patch /COndition/1234 with a status of entered in error with a comment that states that.

Drew Torres (Dec 08 2020 at 00:08):

Does exactly that without task.

Lloyd McKenzie (Dec 08 2020 at 00:08):

How do you include a 'comment' in a patch? The comment shouldn't be in the record

Drew Torres (Dec 08 2020 at 00:09):

Condition had note/annotation on there...

Lloyd McKenzie (Dec 08 2020 at 00:10):

There aren't going to be annotations on everything that needs correction
The request for correction isn't the same as "please store this comment on the record"
That doesn't give you an ability to capture the date by which the change needs to be made

Drew Torres (Dec 08 2020 at 00:10):

Are you going for perfection or something implementable?

Drew Torres (Dec 08 2020 at 00:10):

Sorry not to be rude, but task feels very heavy for this.

Lloyd McKenzie (Dec 08 2020 at 00:11):

It has to work for the full breadth of the use-case. The workflow we're replacing is "letter to clinician".

Drew Torres (Dec 08 2020 at 00:11):

Simple post/patch/put/delete can solve 80% of your use-case.

Lloyd McKenzie (Dec 08 2020 at 00:12):

I'd put it at closer to 20%

Drew Torres (Dec 08 2020 at 00:12):

Hopefully you are wrong because that is what we plan to go to production with working with consumer app companies.

Lloyd McKenzie (Dec 08 2020 at 00:13):

What percentage of the time will the patient know the resource id(s) of the resources involved? (few)
How many EHRs will support asynchronous updates to resources (where the wait time will be days/weeks during review) (few)
How many of the resources where corrections need to be made will have a place to capture notes? (< half)
How often will the notes explaining the rationale for the change be appropriate to retain on the record once the change has been made? (<< half)

Lloyd McKenzie (Dec 08 2020 at 00:14):

PUT/POST works great if you want to say "fix this address" and the EHR can respond with "Cool, done".

Lloyd McKenzie (Dec 08 2020 at 00:14):

It doesn't work great if there's a need to talk to a human who'll be in the middle.

Lloyd McKenzie (Dec 08 2020 at 00:15):

The only bit we're trying to solve is the "human in the middle" piece.

Lloyd McKenzie (Dec 08 2020 at 00:16):

If you're communicating to a human, you need to be able to tell a story. And PUT/PATCH doesn't let you do that.

Drew Torres (Dec 08 2020 at 00:16):

And drafting a task FHIR resource does?

Drew Torres (Dec 08 2020 at 00:16):

Cause the patient is drafting a task resource?

Drew Torres (Dec 08 2020 at 00:17):

I don't follow how that argument works against interactions and for task.

Lloyd McKenzie (Dec 08 2020 at 00:18):

The patient is just saying "here's what I want changed, here's why, here's when it needs to be done". Task is the natural resource for capturing those things in a way a human can consume. (And for the human to communicate back what the current status is of getting the request done.)

Drew Torres (Dec 08 2020 at 00:19):

I think you and I see very different things when we look at task... I think this is enough for one night for me. Have a good night and always fun!

Lloyd McKenzie (Dec 08 2020 at 00:19):

It's about what is the data structure used to describe a desired action with reason and target date and that can communicate back an intermediate status. PUT/PATCH don't have that.

Michele Mottini (Dec 08 2020 at 00:19):

What percentage of the time will the patient know the resource id(s) of the resources involved? (few)

Patient does not have to know, the app will always know that (if did not throw away the original ids, I have to actually check that for ours...)

Lloyd McKenzie (Dec 08 2020 at 00:20):

App will know only if you're talking about data the app is accessing RESTfully. My understanding of the use-case is that it should also allow the patient to request changes to data they've seen/received in other ways.

Lloyd McKenzie (Dec 08 2020 at 00:20):

(e.g. on paper, web portal, via a payer, etc.)

Michele Mottini (Dec 08 2020 at 00:24):

If the data has been received in other ways you would not even know _where_ to send the request for correction

Lloyd McKenzie (Dec 08 2020 at 00:31):

You quite probably know the hospital organization. You might not know where in the hospital. However, the legal obligation is at the organizational level. They have to figure out how to route it and what system(s) actually need correction.

Lloyd McKenzie (Dec 08 2020 at 00:32):

The legal mandate isn't "allow the patient to correct the things that are easy to expose an API to correct" :)

Michele Mottini (Dec 08 2020 at 00:35):

'Where' = to which FHIR end point the app should write the task

Lloyd McKenzie (Dec 08 2020 at 01:02):

End point would be the endpoint associated with the health care organization. If the organization has multiple endpoints, then it could presumably be any of them.

Josh Mandel (Dec 08 2020 at 01:14):

I'm pretty much with Lloyd on this. Drew, have you reviewed the HIPAA requirements? They define a very specific workflow that patients have the right to invoke. Today that happens through faxes. It'd be lovely to make it happen through APIs. It still requires clinical review; you can't wish or assume your way out of that amendment workflow requirement, which every HIPAA covered entity is obligated to support.

Michele Mottini (Dec 08 2020 at 01:17):

associated with the health care organization

Which healthcare organization? You have a piece of data coming from somewhere - maybe your payer as you said... how do you go from that to an actual end point?

Michele Mottini (Dec 08 2020 at 01:19):

In general: I agree that using task seems a better way, but if Cerner say no, that's pretty much it

Drew Torres (Dec 08 2020 at 01:51):

HIPAA obligation that every health system "supports today"... So are you really making today any better by supporting it through task? Taking the paper workflow and making an electronic version isn't really making anything better. You are contributing to physician burnout because I am going to have to support this concept of patient contributed tasks.

Who is wishing it away? I fully plan on supporting the amendment workflow through the API. I just see no path forward with task.

Drew Torres (Dec 08 2020 at 01:58):

And even then... Let's say you take the paper form and make it electronic... Couldn't you just do that with a a document reference post with a human readable text? I could easily store a document to an area of a chart and have a workflow where the document is easily accessible and can be categorized in a way that it is "patient corrections"... Task doesn't align with how our EHR operates as it relates to patient contributed data, or the clinical workflow. It will make adoption and implementation that much more complex because of how I would have to make a patient task list operate.

So task will result in this great patient experience at the cost of the provider workflow.

Dave deBronkart (Dec 08 2020 at 01:58):

Drew Torres said:

Task is extremely complicated to implement because of how generic it is.

I speak up on this with trepidation, being non-technical (compared to y'alls) and this being my first HL7 project. Having said that:

If I understand correctly, isn't the purpose of an implementation guide to spell out which of the million possible "FHIR Lego blocks" should actually be used, for the work being defined? If so, would the infinite possible complexity of Task be a legit issue for this IG?

If this is a time-wasting distraction just say so. :smile:

Drew Torres (Dec 08 2020 at 02:01):

No that is a great question. From a FHIR community standpoint, absolutely. From an EHR implementor perspective, it isn't that easy. I have to see the future of every permutation of how task can be used, and then design an architecture that can route and handle these different workflows from this super generic thing.

Drew Torres (Dec 08 2020 at 02:02):

For example, if you send a post with a task. I will have to inspect this thing and then have to know how to handle that request to know which "task list" to send it to.

Drew Torres (Dec 08 2020 at 02:06):

Our EHR has native patient contributed data workflows where that data is already seen side by side with the charted data. Corrections and contributions should go to that flow. The best path forward is having those API calls go to the correct FHIR APIs.

Dave deBronkart (Dec 08 2020 at 02:14):

Drew Torres said:

I also don't understand how a patient managing a providers task list helps.

Just to be clear, that is absolutely NOT what's happening here. For one thing, AFAIK this has nothing to do with managing anyone's task list; it's a matter of fixing often-egregious errors in the chart ... and it's HIPAA and GDPR that require correections in such cases, not the uppity patient.

If you assert that reporting an error that the provider made is socially inappropriate, well, please arrange for us to have super-human perfect clinicians everywhere :smile:

(Continued)

Dave deBronkart (Dec 08 2020 at 02:15):

Continuing: from Nov 21 waaaaay back up in this thread - the problem we are here to address, which led HL7 to approve this project as net-new in all of HL7:

Dave deBronkart said:

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.

Drew Torres (Dec 08 2020 at 02:16):

I read it with a smile because I feel the work that we already have underway will allow you to do that. :-D

Drew Torres (Dec 08 2020 at 02:19):

I am trying to stress that we need to do it in a way that takes into account existing provider workflows where this manifests itself today.

Drew Torres (Dec 08 2020 at 02:21):

Also, my understanding, HIPAA has had this requirement for a while.. This isn't a new requirement. It has just always been handled in a "paper way"... Send a message from portal, fax something in, etc. Consumer portals added this feature for a while now too.

Dave deBronkart (Dec 08 2020 at 02:24):

Drew Torres said:

I have to see the future of every permutation of how task can be used, and then design an architecture that can route and handle these different workflows from this super generic thing.

From my standards work in the graphic arts long ago, that sounds very familiar. The arguments in that industry were different but similar in kind, I think: "BLUE??? Waddaya MEAN 'blue'? What am I supposed to do with THAT? Somebody else might mean something completely different and bitch at me five years from now. I can't risk that - I'm responsible for everything my system might be asked to."

Again I wonder if it isn't the job of an IG to limit what might be required of a supporting receiver. Sort of, "We're doing X, and we're using Task as the vessel for it," vs "We've pushed the magic Task button - hold onto your hats ha ha!"

Dave deBronkart (Dec 08 2020 at 02:26):

In a comparable case in graphic arts, we addressed it by saying (analogously) "We're using Task as the vessel, with the following constraints, because we don't NEED the magic all-versatile Task button, we only need options 3 and 7."

(I hope that mangling of reality is clear enough to get my point across)

Drew Torres (Dec 08 2020 at 02:26):

Maybe... I just see task as overkill for this problem with substantial costs in making it work.

Dave deBronkart (Dec 08 2020 at 02:27):

Drew Torres said:

Also, my understanding, HIPAA has had this requirement for a while.. This isn't a new requirement. It has just always been handled in a "paper way"... Send a message from portal, fax something in, etc. Consumer portals added this feature for a while now too.

Yes, somewhere between 15-20 years :smile:

Dave deBronkart (Dec 08 2020 at 02:28):

Drew Torres said:

Maybe... I just see task as overkill for this problem with substantial costs in making it work.

Our messages arrived in the same minute, so I want to note for readers that your "substantial costs" was not a response to my suggestion, it was a response to some earlier message. I wonder if a constrained subset of Task would make it viable.

Drew Torres (Dec 08 2020 at 02:29):

I think most of us have heard you loud and clear. ;) I have been working on it for some time already... Just takes some time to make it available in a meaningful way. The clinical workflow for reconciliation complicates things. We want to create an ecosystem where the provider wants to have an engaged patient where provider and patient are collaborating on the chart together. Not a back and fourth where they are frustrating each other.

Drew Torres (Dec 08 2020 at 02:30):

Not really. I still have the issues to consider because there are other IGs trying to leverage task. I have had the same feedback for them too.

Dave deBronkart (Dec 08 2020 at 02:31):

Drew Torres said:

I think most of us have heard you loud and clear. :wink: I have been working on it for some time already... Just takes some time to make it available in a meaningful way. The clinical workflow for reconciliation complicates things. We want to create an ecosystem where the provider wants to have an engaged patient where provider and patient are collaborating on the chart together. Not a back and fourth where they are frustrating each other.

And for that I'll point out that way back in the beginning @Lloyd McKenzie reminded us that our task in an IG was NOT to "legislate" how any dispute gets handled - our task was solely to define the infrastructure to DELIVER a request for a correction, and sequelae.

Dave deBronkart (Dec 08 2020 at 02:31):

Drew Torres said:

Not really. I still have the issues to consider because there are other IGs trying to leverage task. I have had the same feedback for them too.

Ha ha well you can't blame us for THEM not being more careful with their weapons :-) :-)

Abbie Watson (Dec 08 2020 at 02:32):

Lloyd McKenzie said:

What percentage of the time will the patient know the resource id(s) of the resources involved? (few)

I think there's a generational divide going on here, because I would have answered with "most/all". Speaking for millennials and users of the Apple HealthRecords ecosystem, there's a quickly growing generation of patients for whom if it doesn't exist on their smartphone, it's effectively not in their medical record.

Dave deBronkart (Dec 08 2020 at 02:34):

Abigail Watson said:

Lloyd McKenzie said:

What percentage of the time will the patient know the resource id(s) of the resources involved? (few)

I think there's a generational divide going on here, because I would have answered with "most/all". Speaking for millennials and users of the Apple HealthRecords ecosystem, there's a quickly growing generation of patients for whom if it doesn't exist on their smartphone, it's effectively not in their medical record.

YIKES, Abbie! That'd be tres stupid, n'est-ce pas?? It would disable them from knowing about errors that ARE in the EHR and have not been back-ported from Cerner into their Apple Health record.

Not to mention the vast majority of the world that doesn't have an Apple Health app.

Dave deBronkart (Dec 08 2020 at 02:35):

Uh-oh I just realized what time it is - I'm 2 hours late on the rest of my evening - TTYL - I hope I don't wake up to 800 more messages in this thread, but we'll see. Now is the time to have this out!

Drew Torres (Dec 08 2020 at 02:36):

Dave deBronkart said:

And for that I'll point out that way back in the beginning Lloyd McKenzie reminded us that our task in an IG was NOT to "legislate" how any dispute gets handled - our task was solely to define the infrastructure to DELIVER a request for a correction, and sequelae.

I still think task is a bit much for that. Why not use existing infrastructure like pushing a document in, or using a message? Seems like there are mechanisms for that today that are electronic in nature.

Dave deBronkart (Dec 08 2020 at 02:36):

The first brilliant inventor / entrepreneur I ever worked for said "The principal role of trade shows is to force products to get finished." Perhaps the same could be said for connectathons and specs?

Drew Torres (Dec 08 2020 at 02:39):

I would largely agree, but IMO for that to succeed here is to have a bit of a sense of open receptiveness to hearing out some alternatives. I feel like I got invited to a race where the winner was announced...

Drew Torres (Dec 08 2020 at 02:42):

Like in US-Core there was some recent contention about must support elements. Vendors were polled on what they actually/planned to support and decisions were made with that feedback in mind. The spec was updated accordingly. I see allscripts is participating, but have there been any other EHRs who have contributed/participated to land on task?

Abbie Watson (Dec 08 2020 at 02:45):

Drew Torres said:

Are you going for perfection or something implementable?

100% agree with this sentiment. I feel that there we're prioritizing the maturation of the spec and semantic formalism and replicating paper based workflows over creating something implementable and usable in the real world. I look at the Task resource, and it's completely useless to us in the next 6 to 12 months in real-world terms of making actual corrections to actual records in production systems.

As a patient implementor and track lead, I have to confess that I find Task to mostly be an academic exercise, and the real action and value from this connectathon is entirely with working with folks like Drew on testing the PUT Condition API.

@Drew Torres - I'm gathering that you're with either Cerner or Apple?

Drew Torres (Dec 08 2020 at 02:46):

Cerner again :-D

Lloyd McKenzie (Dec 08 2020 at 02:47):

It's not about a generational divide. it's about multiple pathways. The reality is that there's still a lot of data that is not accessible by API, but which a patient will encounter in various ways - and the patient must be able to request corrections to all data, not just the data they've accessed through an app via an API. (Even if the data happens to be accessible via an API, it's not a given that the patient will have encountered that way - or will want to navigate through their app to try to figure out where it is. That's not their job...

There are numerous workflows where an external agency is going to want to insert workflow into an EHR. I'm aware of the following:

Da Vinci CRD - asking for the completion of a form (for prior auth, claims submission and/or local storage for audit)
Da Vinci CDex - payer asking for data from an EHR where simple query won't cut it
Patient asking for data corrections
Patient asking for official logging of disagreement

Any time any system wants to ask for something to be done and there's a need for human review (please action this referral; please suspend this prescription; please discharge this patient; etc.), the way that's communicated is with Task. Yes, it's a resource used for a whole lot of purposes. So is Observation. It's a generic structure used for asking for something to be done. EHRs wouldn't be implementing Task just for patient corrections. They'd be implementing it because they have a need to support external requests for a human to do something. Patient corrections would just be one of those things.

Drew Torres (Dec 08 2020 at 02:48):

Thats just not how EHR works.

Lloyd McKenzie (Dec 08 2020 at 02:48):

Abigail - how is the PUT workflow going to work to communicate "why this change should be made" in a generic case?

Lloyd McKenzie (Dec 08 2020 at 02:48):

How does the paper workflow work?

Lloyd McKenzie (Dec 08 2020 at 02:49):

Because all we're tying to do is automate the paper workflow - so it's easier for patients to initiate and monitor, so it's easier to route, so there's at least a chance of having discrete data allowing more automated location of the data and applying the change, and so that the whole workflow can be performed more quickly (because the back-and-forth isn't happening via the postal system).

Lloyd McKenzie (Dec 08 2020 at 02:49):

If all we wanted to do was PUT an update to the relevant resource, there'd be no need for an IG.

Lloyd McKenzie (Dec 08 2020 at 02:50):

(US Core already covers that...)

Drew Torres (Dec 08 2020 at 02:50):

That for me or Abigail? If its for me... There is no paper workflow in the EHR for this... A patient calls to correct their record... The user of the EHR make the change directly on the chart or adds a note documentation why they didnt make the change.

Lloyd McKenzie (Dec 08 2020 at 02:51):

Right. So the inbound letter never manifests in the EHR, nor does the response. It all lives in the paper world. The IG is intended to address that.

Drew Torres (Dec 08 2020 at 02:52):

I feel like you read my sentence and ignored it... There is no inbound letter.... I must be missing something.

Drew Torres (Dec 08 2020 at 02:53):

I call in.... Say take obesity off my chart cause I lost 100p pounds... A EHR user deletes the problem with a comment why they did it... Or they had a note saying they refused to remove it...

Abbie Watson (Dec 08 2020 at 02:53):

@Drew Torres - well, filreroom operations may be tracking an inbound call log or communications log. (Used to be a Cerner admin for 5 years at the NYMH beta site for Cerner Millennium, btw).

Drew Torres (Dec 08 2020 at 02:54):

Right that is done as a PowerForm. that HIM would use to track that a call happened.

Lloyd McKenzie (Dec 08 2020 at 02:54):

A whole lot of provider organizations expect the request to be in writing. If it comes in as a logged phone call (or lord help us a fax), the principle is the same.

Abbie Watson (Dec 08 2020 at 02:55):

Lloyd McKenzie said:

Right. So the inbound letter never manifests in the EHR, nor does the response. It all lives in the paper world. The IG is intended to address that.

So let's call it the HIPAA Paper to Digital Conversion Workflow IG then, instead of the PatientCorrection IG.
(Not intending to be snarky, but pointing out the misalignment.)

Drew Torres (Dec 08 2020 at 02:55):

I haven't seen that in practice... "require" is strong there... Anyone who implements portal will just let you send a secure message to update.

Lloyd McKenzie (Dec 08 2020 at 02:58):

Ok. Then the API we'd be looking at would be into that secure message repository. This is essentially a 'typed' secure message with some additional discrete data.

Drew Torres (Dec 08 2020 at 03:01):

Then why not use communication?

Drew Torres (Dec 08 2020 at 03:04):

Since that is another API we are actually working on and plan on support patient to provider communication through that API.

Lloyd McKenzie (Dec 08 2020 at 03:04):

Because it's not a generic communication of "hey, here's some information". It's a request for action. It will have a status in the end of "completed" or "rejected" (and may have intermediate statuses). It'll have discrete data that defines what's to be done.

Lloyd McKenzie (Dec 08 2020 at 03:05):

It's not just a simple dumb email - but it's definitely human-to-human communication.

Drew Torres (Dec 08 2020 at 03:06):

So your proposal... If I understand.... Is for us to support a resource to get stored along side messages, where we couldn't support these statuses anyways?

Lloyd McKenzie (Dec 08 2020 at 03:08):

Where will you support capturing a request from a payer to complete a form or to gather information to support a claim? One that's targeted at humans, not APIs?

Abbie Watson (Dec 08 2020 at 03:09):

Lloyd McKenzie said:

Abigail - how is the PUT workflow going to work to communicate "why this change should be made" in a generic case?

Well, first of all, we've always known the PUT workflow isn't entirely sufficient for all data types. I don't think I or Drew or others have ever claimed that the current PUT workflows currently available entirely covers 100% of the HIPAA corrections workflow. Which is why, I think, everybody was willing to hear out the Task based approach - it makes for an excellent yardstick for the PUT workflows to match or exceed. And part of the interest in testing these APIs during the connectathon is to determine a gap analysis of how much we get versus what else needs to be implemented.

Second, we're not necessarily saying that ALL updates are going to be possible through PUT workflows. Updating diagnostic imaging files or genomic files were never going to be in scope to begin with. So it was never proposed as a universal approach for all resources, and we recognize the that Task might be the only option for a lot of data types.

But implementors want to be using these published APIs if they're available. Today. Not next year. And those of us advocating for PUT workflows were always willing to accept an additional PUT Composition or PUT Bundle or PUT DocumentReference operation in addition to the PUT Condition. We're not objecting to a narrative text and nicely phrased request being recorded along with the update; we'd just post it to DocumentReference and blob it into document storage.

Drew Torres (Dec 08 2020 at 03:09):

I would prefer to leave the DaVinci pieces out of this because my only comment to that is that the core API team has not participated in that IG creation either. I believe my initial strong feedback there was to support communication as well.

Lloyd McKenzie (Dec 08 2020 at 03:10):

If there's no chance of EHRs will support capturing requests for action and tracking and communicating back statuses, then maybe all that will be possible is secure email. That'd suck, but if that's all that's possible, then that's all that's possible.

Lloyd McKenzie (Dec 08 2020 at 03:12):

@Abigail Watson I'm not opposed to simple PUT. That's the ideal. It should be used wherever possible. However, we already know how to do that. There's nothing new to define there. There's nothing "special" about a PUT from a patient app vs. a provider app. The "net new" thing was how to make the requests that can't be submitted as a simple PUT.

Lloyd McKenzie (Dec 08 2020 at 03:12):

That's what justified creating an IG and discussing with the EHR community how best to make it happen

Drew Torres (Dec 08 2020 at 03:13):

IG are much more than just data structures... I don't think US-Core defines writes/puts... Nor does it define how a patient app would actually contribute data... It also doesn't touch on the nuances of how to behave with proxy access.

Abbie Watson (Dec 08 2020 at 03:15):

Mmmm... 'net new' might be PUT with launch/patient scope, or perhaps an IG with PUT and a patient correction use case (instead of a provider workflow usecase). Again, PUT might not be new for experienced implementors on the provider side, but it's new for the patient implementor community.

Abbie Watson (Dec 08 2020 at 03:19):

Also, I'm rather concerned about this notion that it has to be 'special' or novel for it to be worthwhile. Clarity and timeliness and consensus and applicability are also worthwhile, and may justify reviewing ground that others have worked on already.

Lloyd McKenzie (Dec 08 2020 at 03:24):

US Core does support create/update, though it doesn't mandate them.

The big question for me is: what percentage of requests for correction can be done without a human needing to see a reason or any other information than "change this". Personally, I expect that if it's something a human needs to decide on, they're always going to need a reason.

Abbie Watson (Dec 08 2020 at 03:25):

It's a good question.

Drew Torres (Dec 08 2020 at 03:27):

Lloyd McKenzie said:

US Core does support create/update, though it doesn't mandate them.

Sure, but also has the very important text:
Writing and Updating - Very little guidance is provided on writing and updating data in the context of US Core profiles. There are multiple issues that will need to be considered when defining expected behavior by the various actors to support updates and writes to the data including:

Defining the overall approach
direct updates to a particular resource via FHIR RESTful transactions
new Profiles to represent the context and issue and request
Write failure scenarios (e.g., insufficient data to create)
Writing and updating data in the context of the Must Support fields
Indicating the source of update

Drew Torres (Dec 08 2020 at 03:29):

Lloyd McKenzie said:

The big question for me is: what percentage of requests for correction can be done without a human needing to see a reason or any other information than "change this". Personally, I expect that if it's something a human needs to decide on, they're always going to need a reason.

Shouldn't we answer or do some homework on that before landing on an approach?

Abbie Watson (Dec 08 2020 at 03:36):

My initial thought was that the need for a reason is a liability issue, and therefore could benefit from a legal review. My intuition is that a properly crafted policy from a Chief Medical Informatics Officer could allow a Provenance record in the header of the PUT to act as a liability waiver or authorization, and allow bypassing the review and need for a reason.

Lloyd McKenzie (Dec 08 2020 at 03:36):

I understand that there are lots of issues with allowing direct write to an API - which is one other reason we were pursuing allowing the update to be driven by a human within the EHR rather than a direct call to the API. Not very many EHRs support update to very many resources.

Josh Mandel (Dec 08 2020 at 03:39):

@Drew Torres I'm not following the thrust of your argument about Task vs Communication -- you're saying that one is "complex"' or you'd have to handle "all possible uses" in order to support even one use; but that doesn't seem true to me. You can always support a narrow set of use cases for Task (or Communication!) driven by types/codes in the resource.

Lloyd McKenzie (Dec 08 2020 at 03:39):

PUT + Provenance + Async could do a semi-decent job of meeting the use-case. My gut is that it's significantly more complex than just posting a Task, but if it's a preferred option by the EHR vendors, it's workable. The only challenges with it would be:

only works for data where the specific data location is exposed RESTfully (and the RESTful location is known by the patient)
doesn't give the patient any insight into what's going on with their data. (E.g. the HIPAA-mandated notice that the review is going to take longer than 30 days)

Josh Mandel (Dec 08 2020 at 03:42):

Re: direct PUTs, this seems like a great option in the context where it's allowed, but you need to 1) address the fact that many details will be unreachable through structured resource content or widespread across far-flung corners of the EHR and 2) establish the criteria for rejection -- does this happen immediately, or sometime later, and how does the patient ensure that she sees the same "current state" as everyone else?

Drew Torres (Dec 08 2020 at 03:44):

Communication is 1..1 in our system.. it is easy to support...

Task can manifest as many different things in my system. I can't just route to different data stores on a read by id call without having to understand what that thing was. So on a simple read, I now have to make at least 2 API calls to make that work. That assumes that the workflow exists in our system. In this case, I would be making a completely new workflow that is disruptive to the existing clinical workflow. If you said route the task to the communication system... Well That system doesn't support any of the status you are talking about. Task is significantly more complex here.

Drew Torres (Dec 08 2020 at 03:45):

Josh Mandel said:

Re: direct PUTs, this seems like a great option in the context where it's allowed, but you need to 1) address the fact that many details will be unreachable through structured resource content or widespread across far-flung corners of the EHR

Examples of this? I can tell you a majority of the data is available in the structure... More so than most health systems like.

Drew Torres (Dec 08 2020 at 03:48):

Josh Mandel said:

2) establish the criteria for rejection -- does this happen immediately, or sometime later, and how does the patient ensure that she sees the same "current state" as everyone else?

Current task resource isn't going to solve that either, right? So you can say, when allowed this is expected behavior. When it is not allowed, there is this other workflow.

Lloyd McKenzie (Dec 08 2020 at 03:52):

Task does solve it because Task is intrinsically asynchronous and can be queried/subscribed to and monitored for status. If you choose to update the Task a few milliseconds after it's posted to say it's done, or you updated it after 3 weeks to say it's going to be another 4 weeks, the workflow's the same.

Drew Torres (Dec 08 2020 at 03:54):

How does task solve for the inconsistency point Josh was making vs a direct update?

Lloyd McKenzie (Dec 08 2020 at 03:54):

That doesn't mean "you might get a 200, you might get a 202 and have to poll" can't work. However, polling on a timeframe of weeks sort of sucks. We've never talked about async working over time-frames that long. (And yes, decisions about whether to apply a correction to a patient record can sometimes take that long - or longer.

Lloyd McKenzie (Dec 08 2020 at 03:54):

I was talking about #2. With Task, the immediate rejection vs. deferred rejection doesn't change the workflow.

Drew Torres (Dec 08 2020 at 03:55):

And why wouldn't pub/sub solve for that?

Lloyd McKenzie (Dec 08 2020 at 03:55):

Once the change is made, it's made for everyone. That has to happen regardless of mechanism. If a patient is told "the change is made", then that must be the view everyone sees.

Josh Mandel (Dec 08 2020 at 03:55):

Everyone has a shared view on outstanding tasks; you never have a situation where one party (Patient) sees a correction as already applied, while other parties (Providers, external apps) still see an old version

Drew Torres (Dec 08 2020 at 03:56):

Who said that is how it does work?

Josh Mandel (Dec 08 2020 at 03:56):

Examples of this? I can tell you a majority of the data is available in the structure... More so than most health systems like.

Narrative notes are the easy example.

Lloyd McKenzie (Dec 08 2020 at 03:57):

It must work that way. If a Patient says "please remove the assertion I'm diabetic from my record before my surgery" and the EHR says "Yup, done" and the patient queries and sees "Great, it's done", it's a HUGE problem if the surgeon queries and sees that the patient is diabetic.

Josh Mandel (Dec 08 2020 at 03:57):

Who said that is how it does work?

Drew, you described a system like this on the API design call a couple of months back; unless I misunderstood or your thinking has evolved

Drew Torres (Dec 08 2020 at 03:57):

I knew that is what you were going to say....

Drew Torres (Dec 08 2020 at 03:58):

I think there is a misunderstanding of how that will work.

Josh Mandel (Dec 08 2020 at 03:59):

Design docs would help clear up any misunderstanding.

Drew Torres (Dec 08 2020 at 04:03):

And there was an action item for me to do that, but am mostly in us-core review in preparation for January ballot. I will share what our current implementation plan is at somepoint.

Josh Mandel (Dec 08 2020 at 04:05):

To the extent you're doing anything "interesting" with this design, best to share early, both 1) to ensure others can plan their own API design accordingly, and 2) to surface any feedback that may influence your plans

Lloyd McKenzie (Dec 08 2020 at 04:10):

Ok. TL/DR summary as I understand it:

PUT (by itself) works for fully automated updates where the patient can decide what they want to fix and the only filter is automated synchronous rules. (But that's probably not a huge amount of the record)
PUT + provenance (to capture reason) + async is a potentially viable solution, but it's limited to those resources where:
- the EHR exposes that data over the API
- the patient knows how to find that data via an app that uses the API
- the EHR allows updates to the data
for all data that isn't covered by this mechanism, the patient has to use a completely different route (which will vary from organization to organization)
as well, this approach doesn't allow communication of status information back to the patient except final success/fail which won't meet HIPAA requirements in cases where the duration goes beyond 30 days
it requires really long polling of data in situations where an organization takes days or weeks to make a decision

On the other hand, a Task based solution would require building a net new capability into the EHR, as well as some smart logic to route Tasks appropriately. So a 'dumb' Communication approach is much lower hanging fruit and more likely to be workable near-term.

Have I missed anything important?

Drew Torres (Dec 08 2020 at 04:11):

Nothing really special TBH... Just simple posts/puts/patches on the resources on APIs... Everything else is just implementation details of the transactions... Describing clinical workflows... How a provider can accept... etc.

Josh Mandel (Dec 08 2020 at 04:13):

The part I think we're anxious about is who sees what content in the "updated" resources at what point in time. If the answer isn't "at any given time, everyone sees the same content for Resource X" this is worth explaining.

Lloyd McKenzie (Dec 08 2020 at 04:13):

It's not 'simple' if it needs provenance + async. (And I expect that's going to be needed > 90% of the time. Providers will be really antsy about patients making unsupervised changes to data.)

Drew Torres (Dec 08 2020 at 04:16):

That is exactly how it works. There is a flow where we optionally give the patient the ability to see what has been proposed changes.... SO they aren't requesting the same changes over and over again.

Drew Torres (Dec 08 2020 at 04:17):

Lloyd McKenzie said:

It's not 'simple' if it needs provenance + async. (And I expect that's going to be needed > 90% of the time. Providers will be really antsy about patients making unsupervised changes to data.)

Who said anything about provenance in the implementation we are working on? In our implementation when a patient contributes data... The provenance record is generated because we don't trust apps to write that correctly.

Drew Torres (Dec 08 2020 at 04:18):

Patient/App writes the data... the rest we do behind the scenes to make it easier.

Lloyd McKenzie (Dec 08 2020 at 04:20):

Abigail had proposed Provenance. I can't see async changes working on their own because there's no consistent place to put the message from the patient about why the data needs to change. And providers are going to need to see that when they evaluate whether to make the change or not. (And patients are going to insist on being able to communicate that.) "Stick it in the notes, if they happen to exist" is not going to fly - both because they exist on too few of the resources and because the explanation of reason for change has no business being applied as part of the change itself.

Drew Torres (Dec 08 2020 at 04:21):

Is that where the IG could create a standard extension?

Drew Torres (Dec 08 2020 at 04:22):

If you wanted to entertain the idea of a post/put approach.

Lloyd McKenzie (Dec 08 2020 at 04:24):

Extension doesn't work unless we stick in metadata and define it as something that isn't actually stored. But it's an abuse of the 'update' process. Provenance is cleaner.

Drew Torres (Dec 08 2020 at 04:25):

I think your and I definition of cleaner is very very different... I think the meta approach is a lot cleaner in this case... And I believe that's how you can communicate things like sensitivity on a post...

Virginia Lorenzi (Dec 08 2020 at 04:25):

Drew Torres said:

I think most of us have heard you loud and clear. ;) I have been working on it for some time already... Just takes some time to make it available in a meaningful way. The clinical workflow for reconciliation complicates things. We want to create an ecosystem where the provider wants to have an engaged patient where provider and patient are collaborating on the chart together. Not a back and fourth where they are frustrating each other.

@Drew Torres I hear you - however, I wonder is amending an inpatient record requires a level of formality because you can't easily go right to that doctor for them to correct it. I will ask our HIM people more. Also, today, you need to have a record of amendment. Also what about if a patient wants to send a free text correction request? Another option would have been Communication resource for that, but then we wouldn't have the statuses Task provides. Also, in our proposed IG we are only specifying two specific profiles on Task. I understand you have to think bigger than that but not all at once maybe?

Virginia Lorenzi (Dec 08 2020 at 04:27):

@Isaac Vetter @Vassil Peytchev @Drew Torres Seems to be some intellectual dispute on using Task for correction versus PUT or PATCH of a specific resource. Vassil - I know you support Task and Isaac I think you support the other approach - can you help us on pros and cons?

Lloyd McKenzie (Dec 08 2020 at 04:28):

Sensitivity of a POST is expected to be stored with the data. As is _lastUpdated, source, profile, tags and everything else there. Submitting an update that says "change this in the metadata" with the expectation it then gets thrown away is definitely not "clean". Also, the long-term place where you'd expect to see the "reason for change" - the patient's justification would be in Provenance.

Drew Torres (Dec 08 2020 at 04:28):

@Virginia Lorenzi correct. I have to check with health systems to see how they handle it today. I can talk to a few in our legal records team to find out what they know.

Drew Torres (Dec 08 2020 at 04:29):

Lloyd McKenzie said:

Also, the long-term place where you'd expect to see the "reason for change" - the patient's justification would be in Provenance.

Sure... Do you need to solve that on day one?

Virginia Lorenzi (Dec 08 2020 at 04:32):

Drew Torres said:

Thats just not how EHR works.

If you got a paper request to amend the EHR, wouldn't HIM enter it in as a task (not a task resource but an actual task in the workflow module for HIM) and communicate with the clinician on it via an electronic workflow?

Lloyd McKenzie (Dec 08 2020 at 04:32):

Data coming in in the place it's expected to be long-term just seems a lot less kludgy than submitting it in a place where it's going to get yanked away from and moved to the other place. I hear you that it may be harder for you to process at the interface, but from a pure "how are resources supposed to be used" perspective, it's the cleaner approach. (I'm not militantly saying it MUST be that way, just that we should seriously think through the consequences of introducing a kludge.)

Drew Torres (Dec 08 2020 at 04:33):

Maybe HIM has that workflow... My comment was more specific to the clinical workflow.

Drew Torres (Dec 08 2020 at 04:34):

I can be sold on the provenance approach, just not a huge fan... It is correct, just a bit heavy... I wouldn't make it required on day1.

Lloyd McKenzie (Dec 08 2020 at 04:41):

Reason is going to have to be required on day 1. And we're not really going to want to support multiple ways of conveying reason. I'm happy to let the EHRs duke out whether they're going to bite the Provenance bullet now or use a kludge in the initial release.

Drew Torres (Dec 08 2020 at 04:42):

I think health systems define what is required. To date, the reason hasn't really been all that important.

Drew Torres (Dec 08 2020 at 04:44):

And maybe that changes once this is more adopted widely I suppose. I believe correction flows, currently, in patient portal doesn't capture reasons.

Drew Torres (Dec 08 2020 at 04:45):

Probably because of the provider review before finalizing... I would have to check.

Lloyd McKenzie (Dec 08 2020 at 04:48):

Right. These would be coming in without any patient/provider prior discussion. Just "change this", "add this", "delete this". And you don't want to have to inject "provider phones the patient to better understand the reason for the requested change" into the workflow :)

Drew Torres (Dec 08 2020 at 04:50):

Thats how it works today though... With positive feedback as I understand it.

Drew Torres (Dec 08 2020 at 04:51):

Granted a subset of data... Like my meds list, social history, etc.

Lloyd McKenzie (Dec 08 2020 at 05:02):

If someone says "delete this med from my list" - does that mean "I never took it", "I'm not taking it anymore" or "My mom's getting access to my record and I don't want her to see it" - could be any of those.

Lloyd McKenzie (Dec 08 2020 at 05:02):

What a provider would actually do in response to each of those reasons could well be different.

Lloyd McKenzie (Dec 08 2020 at 05:02):

(while still meeting the patient intent)

Drew Torres (Dec 08 2020 at 05:04):

I think that may be over complicating the flow today... Patient says remove and it gets removed... I need to confirm that though.

Drew Torres (Dec 08 2020 at 05:05):

And that is only one example... No need to get into each example now... A bit late for me.. I am off to bed... Good chat as always.

Lloyd McKenzie (Dec 08 2020 at 05:14):

That would be unfortunate - because lots of patients won't know what they're doing :(

Brendan Keeler (Dec 08 2020 at 06:35):

200.gif

Brendan Keeler (Dec 08 2020 at 06:36):

Live shot of me firing up the old zulip and seeing this thread

Brendan Keeler (Dec 08 2020 at 06:47):

For what it's worth, I feel empathy towards Drew's scenario. It highlights the occasional tension between standards development and standards implementation.

I don't know that most EHRs are today a series of Task worklists under the hood. But current EHR data structure and consensus built with specific consumer device vendors is only one factor of many to optimize for. They're pretty good to optimize for in that they're inherently geared towards widespread adoption, though.

It would help to understand what factors people are optimizing for when defining which paradigm is "right" here. I see some: RESTfulness, simplicity, patient workflow focus, provider workflow focus, preexisting EHR data structure, ease of adoption. I don't think the different sides are aligned on what are the right values.

Abbie Watson (Dec 08 2020 at 14:50):

I'd encourage everybody to remember that this is the first time we've held a track like this, and it's a topic that a lot of people are passionate about. So, yeah... we got some different values and goals from different groups.

That being said, we're narrowing things down to two approaches that we're exploring; which will probably get broken out into separate test scripts, and eventually into separate IGs most likely. I'll be publishing two more sequence diagrams later this week, one which isolates just the Task workflow, and one which isolates the PUT Condition workflow.

We're going to try to keep the use case the same for both... updating a smoking status record. Regardless of the use case, we're probably going to need test Patients loaded into EHRs and server systems - specifically test patients that have a Condition with a smoking status in their medical history.

But honestly, I think we've had a hell of a conversation, and are hashing out a lot of important details here. I'm pretty thrilled with the conversation that's occurred here, and I think it bodes well for the January connectathon.

Abbie Watson (Dec 09 2020 at 20:43):

As mentioned above, I've created two new sequence diagrams that isolate out the Task and PATCH/PUT workflows.

Patient-Corrections-Smoking-Status-PATCH_PUT-Workflow-for-PatientPortal_PHR-Systems.png

Patient-Corrections-Smoking-Status-HIPAA-Workflow-No-Structured-Data-paper-only.png

Abbie Watson (Dec 09 2020 at 20:45):

@Vassil Peytchev - Hey, Vassil... if you have a few moments, could we get you to weigh in on the original sequence diagram in this thread, and these more recent diagrams?

Vassil Peytchev (Dec 09 2020 at 21:03):

I expect to be at the call tomorrow, but I won't be able to get to that before then...

Abbie Watson (Dec 10 2020 at 00:09):

@Drew Torres - If it wasn't already on your calendar, you're certainly invited to tomorrow's Patient Empowerment call at noon!

Virginia Lorenzi (Dec 10 2020 at 07:11):

Drew Torres said:

Granted a subset of data... Like my meds list, social history, etc.

The purpose of the patient correction IG was never to replace clinical reconciliation - such as when a patient provides their updated information - what meds they are actually taking, etc. Its a way to automate the communication from the App to the clinical record amendment process. I think for what you are describing here - US Core Spec would cover that. But if you want to correct data on a closed encounter, and especially an inpatient record, that is a different story - that is what amendment is about.

Virginia Lorenzi (Dec 10 2020 at 08:36):

Drew Torres said:

And maybe that changes once this is more adopted widely I suppose. I believe correction flows, currently, in patient portal doesn't capture reasons.

Where do those flows go? And how does it work for inpatient charts in particular? And is the HIPAA process honored (request for Medical Amendment)

Virginia Lorenzi (Dec 10 2020 at 08:42):

Drew Torres said:

Nothing really special TBH... Just simple posts/puts/patches on the resources on APIs... Everything else is just implementation details of the transactions... Describing clinical workflows... How a provider can accept... etc.

How would you manage a patient wanting to correct a note? How do you know what provider to send it to? Especially in a correct requested after inpatient discharge? Our doctors rotate in and out of service, we have students, and nurses are off shift. They have moved on. If you send correction request to doctor are they guaranteed to see it? HIM's job is to work these amendment requests to completion/closed loop. I think outpatient may a bit less intense but for inpatient I think you need to get it to HIM. Clinicians already dislike clinrec.

Virginia Lorenzi (Dec 10 2020 at 08:45):

We like the idea of pub/sub but figured we wouldn't start with that

Virginia Lorenzi (Dec 10 2020 at 08:47):

Drew Torres said:

Communication is 1..1 in our system.. it is easy to support...

Task can manifest as many different things in my system. I can't just route to different data stores on a read by id call without having to understand what that thing was. So on a simple read, I now have to make at least 2 API calls to make that work. That assumes that the workflow exists in our system. In this case, I would be making a completely new workflow that is disruptive to the existing clinical workflow. If you said route the task to the communication system... Well That system doesn't support any of the status you are talking about. Task is significantly more complex here.

I think having a way for a patient to send a Communciation resource would be nice for lots of reasons (not meaning to segway). I envision the Task going to HIM workflow, not clinician workflow.

Virginia Lorenzi (Dec 10 2020 at 08:52):

Drew Torres said:

I feel like you read my sentence and ignored it... There is no inbound letter.... I must be missing something.

There are inbound letters - requests for medical amendment:

https://www.memorialhermann.org/uploadedFiles/_Library/Memorial_Hermann/patient-amendment-request-form.pdf
https://www.premierhealth.com/docs/default-source/default-document-library/amendment-request-form.pdf?sfvrsn=728d9b8b_2
https://www.partners.org/Assets/Documents/For-Patients/Medical-Records/Medical-Record-Amendement-Instructions.pdf
https://www.hipaa.cumc.columbia.edu/file/1378/download?token=gKud-5h1

Virginia Lorenzi (Dec 10 2020 at 08:58):

How to Task with the requested correction narrative all inside Description and no inputs or outputs that much different from Communication? And an EHR could even not support the Task read. Wouldn't it function pretty much like Communication then?

Cooper Thompson (Dec 10 2020 at 14:41):

One other consideration about using PUT/POST, is that some patient corrections require moving the content from the patient that reported the issue to another patient that may be missing the data. The patient submitting the correction request may not see the full picture (and shouldn't, for privacy reasons). If we use PUT/PATCH/POST to remove incorrect data like a positive HIV test, then EHRs would still need some mechanism to track adding that data to the correct patient, reviewing notes that may have pulled in that data, looking at any transitions of care documents that may have sent that data to other organizations, etc. We could trigger all that (and more, see below) based on an extension or something on a PUT/POST in the REST API, but that's a lot of business logic to execute that would be unrelated to the content of the provide FHIR resource.

Here is a short list of the tasks that we might perform when we get a Chart Correction Case:

Add advisories to all impacted patient charts so that providers reviewing the chart(s) know there are outstanding issues.
For some issues, patient portal access, transition of care document exchange, and API access MAY be disabled for the impacted patient(s). This is done if there is a lot of data on the wrong patient and a chart correction specialist determines that temporarily disabling access will limit privacy breaches. This is human decision based on the specific circumstances, not a system action.
Flag the incorrect data on the wrong patient as erroneous. We do keep the data on the chart in case there are legal challenges and a provider needs to demonstrate that the data was on the chart if they made a clinical decision based on that information.
Add the correct data to the correct patient's chart.
For some data, we may do a true "move" of the data (e.g. for an entire encounter), as we have an audit of the move that we can use for legal reference.
Review any notes or other areas in the system that may have pulled in the wrong information. Notes may be corrected, or moved to the other patient's chart as appropriate.
Review any communications sent to any affected patients, including letters, portal messages, phone calls, etc.
For patient identification issues, we may need to re-print wristbands, labels, forms, etc.
If the data issue means a patient needs to have their care plan updated, new appointments may need to be scheduled. E.g. if a positive HIV test result was filed to the wrong patient, you need to follow up with the patient that was actually HIV positive.
Review the overall chart correction case to determine which parties may need to be notified of a data breach.
Once the data is cleaned up, if any API/portal access or other data exchanges were disabled, they are re-enabled.

One thing I think it might be useful for the group to consider is the portal account de-activation task. That would (for us) mean you'd (temporarily) be unable to access any of the FHIR APIs (including read APIs) until the chart correction case was completed. I do want to emphasize that portal/API account deactivation is 1) intended to prevent further privacy breaches, 2) is a decision made by a human analyst 3) is done on a case-by-case basis and 4) is temporary. The implication here is that submitting a chart correction request may trigger the temporary revocation of API access. Because the reason is privacy related, in many cases this would likely be allowed under the Cures rules as part of the Privacy Exception (since a human analyst was making the determination on case-by-case basis). However it will have implications on the "notification of complete" process.

Jose Costa Teixeira (Dec 10 2020 at 20:23):

I'm admittedly lost in the discussion but is one of the options that the patient would say "this is the correct version of my Patient resource Patient/xyz ; also, this is the new version of Observation/abc " ? Is that the proposed option?

Dave deBronkart (Dec 10 2020 at 21:33):

Hi @Jose Costa Teixeira - you will probably benefit from listening to the recording of today's VERY robust discussion of things like that.
https://transcripts.gotomeeting.com/#/s/f6548b3db0fff9d3d4be9b68996d16104857033cf61f25312f52f3b5da54c291

As I'm sure you know, you can speed it up until you get to the good stuff.

I'm suggesting this because with as explosively interesting as this is, ergo these wild threads, I think there's more for you to harvest in 45 minutes with that recording than 45 minutes on Zulip trying to sort it out.

Jose Costa Teixeira (Dec 10 2020 at 21:53):

thank you @Dave deBronkart

Debi Willis (Dec 11 2020 at 19:41):

@Jose Costa Teixeira This should also clarify our purpose. It was discussed on the call yesterday.

Debi Willis said:

For those who have not been able to attend our meetings on this topic (which began mid summer), here is a document outlining what we are trying to accomplish with our IG. To reiterate what Virginia noted in an earlier chat: "This is not a simple update - it's a legal amendment." Another important comment from her: "This is net new work for HL7." Because of the newness of this work and the important impact it will have on patients and entities, and the potential to save lives by providing a better flow for the patient's request for correction, I want to clarify again what we are doing.

Once you take a look at what we are trying to accomplish in this document, I think it will become clear and you will see the great value it brings.
image.png

If you want to download the document, you can click on the link below.
What-we-are-trying-to-accomplish.docx

Jose Costa Teixeira (Dec 11 2020 at 20:32):

Thank you @Debi Willis I wish I didn't have a conflict with the OO call. But from what I can follow, allow me to state my starting perspective (sorry if I am repeating something that may have already been stated):

I do not see this as a technical challenge (so I got lost when we discusss with HTTP Codes). This is a workflow. Some of the aspects you have there seem a more concrete example in a concrete jurisdiction (e.g. what happens in case of denial)

Jose Costa Teixeira (Dec 11 2020 at 20:37):

How I see it: Just a "normal" request

someone creates/submits a request - not to change resource 2134, but to "change my medication allergy info". I don't know if there has been a decision on that - I'll shoot this can be a Task or a ServiceRequest. That request is created. (ok, here is a POST with an HTTP 201)
then maybe the request gets picked up. It should be, but we must monitor if that is the case, and how long it takes.
Someone must see what resources are impacted. "medication allergy" may appear as one or many resources - several AllergyIntolerances, several AdverseEvents, others.
Someone then decides to update some of those resources, or to ask further information from the patient, or maybe not to do anything)
Resources are updated, added, deleted - who knows , Provenances created, AuditEvents too.
Lucky Patient gets a notification - can be a simple "your request was processed, we did what we had to" or "your request was processed, here are the changes" - it depends on a lot of rules. Also denial can be explicit with a way to appeal, or a very administrative "we've done what we had to do, that's all we can tell you"

Jose Costa Teixeira (Dec 11 2020 at 20:37):

(again, sorry if this is repeating some discussions or is out of context)

Debi Willis (Dec 11 2020 at 22:34):

@Jose Costa Teixeira The document is an explanation of the information we need to communicate between the parties. Part of the purpose of the document is to underscore that a simple PUT is not the answer. There are so many other pieces to this. We are going to test the Task resource to see if it can be used to communicate all the required information in that document, including the denial, the disagreement, and rebuttal. We think it can.

Here is a picture of a possible use case:
1) A patient uses their consumer app to pull records into their PHR. They see an error and want the clinic to fix it. They can use that same FHIR app to pull up a UI that allows them to enter information concerning what the error is, what they want done, why they are requesting the change, and perhaps who they want to be notified. [The app can direct them on those pieces of information.]

2) The app then sends the Task to the entity to let them know there is something the patient wants to be done (a task). All the pieces of information needed are placed in the Task resource, with Task.description being the place to hold the information from the patient (other areas like Task.input can contain things also, but will not be required).

3) When the entity gets that task, they will need to do some things internally. When they understand what the org wants to do, they will update the Task to let the patient know if their request was accepted, denied, or requires more time. There are other bits of important information that will be placed in the task resource (by the entity) to give the patient more information. [See the image below which lists the required information for each status].

4) The patient can now log back into their consumer app and check the status of the task and the comments associated with that status.

5) If the request was denied, the patient can use their app to voice their disagreement. The app builds another Task (referencing the previous change request that was denied) and the entity gets another task.

6) The entity reviews the information, talks to their internal team about next steps, and responds to the patient.

There may be other conversations going back and forth if the entity needs more information, etc. But, we think this can be done all the way through the denial and rebuttal.

Debi Willis (Dec 11 2020 at 22:36):

Data needed for patient request for amendment

Jose Costa Teixeira (Dec 11 2020 at 22:53):

I agree the task is to be used for following the process.

Jose Costa Teixeira (Dec 11 2020 at 22:54):

the Task resource is not the content, nor the envelope that contains the content. The Task resource is just a string that allows different people to what is to be done by whom

Jose Costa Teixeira (Dec 11 2020 at 22:55):

so yes for Task as a workflow driver/token. I am not sure which resource to contain the information concerning what the error is, what they want done, why they are requesting the change, and perhaps who they want to be notified.

Jose Costa Teixeira (Dec 11 2020 at 22:57):

do we have a Request resource in this story? I know Task can act as one, but I'd think that a Request should be captured

Debi Willis (Dec 11 2020 at 22:57):

It was recommended we use Task.description to describe what the error is, what they want done, why they are requesting the change, and perhaps who they want notified.

Lloyd McKenzie (Dec 11 2020 at 23:05):

Task describes what is to be done. There's no need for a separate resource to do that, though we may (at some point) consider supporting a contained PATCH that formally describes the change if we decide there's value in doing that and implementers are willing to support it.

Virginia Lorenzi (Dec 12 2020 at 04:06):

In our Task profile, we have allowed for a fully structured identification of resources that are wrong, and how they should be corrected within Task.input. I do not see that used all that much as we initially roll out this guide and am more concerned that a patient's narrative request with perhaps a little structured context be received and worked on using the amendment workflows on the provider system and that patient's are able to follow it through till closure. Our goal for phase 1 of this spec was to ensure we could support the actual request for correction as a narrative but get that request for correction into EHR medical records workflow and then provide the ability for the patient app to poll to determine the state of the correction request all the way through completion or rejection. There is another workflow during an encounter where a patient is asked about their meds, allergies, problems, etc and then the clinician compares what they have provided to what they have on their system and reconciles the data.
Since the patient has the clinician's attention this is an easier one to resolve than the after/between encounters errors on charts that are dormant/closed - that is what the purpose of the patient corrections IG is focusing on. It is a major complaint of patients - they get home, they get their data, its wrong - what do they do? They are not with the doctor or nurse any more. All they can do is call, email, mail, or message from a portal and no way to track the request and make sure it actually gets corrected or not. And no way to communicate - to voice this complaint from their app.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Sequence Diagram - Patient Corrections · patient empowerment

Stream: patient empowerment

Topic: Sequence Diagram - Patient Corrections

Abbie Watson (Dec 03 2020 at 20:35):

Michele Mottini (Dec 03 2020 at 20:46):

Abbie Watson (Dec 03 2020 at 20:49):

Abbie Watson (Dec 03 2020 at 20:52):

Josh Mandel (Dec 03 2020 at 20:52):

Abbie Watson (Dec 03 2020 at 20:56):

Michele Mottini (Dec 03 2020 at 20:58):

Abbie Watson (Dec 03 2020 at 21:04):

John Moehrke (Dec 03 2020 at 21:08):

John Moehrke (Dec 03 2020 at 21:09):

Josh Mandel (Dec 03 2020 at 21:09):

John Moehrke (Dec 03 2020 at 21:09):

Abbie Watson (Dec 03 2020 at 21:09):

John Moehrke (Dec 03 2020 at 21:10):

Josh Mandel (Dec 03 2020 at 21:10):

Josh Mandel (Dec 03 2020 at 21:13):

Josh Mandel (Dec 03 2020 at 21:13):

John Moehrke (Dec 03 2020 at 21:15):

Michele Mottini (Dec 03 2020 at 21:16):

Abbie Watson (Dec 03 2020 at 21:16):

Josh Mandel (Dec 03 2020 at 21:21):

Abbie Watson (Dec 03 2020 at 21:23):

Josh Mandel (Dec 03 2020 at 21:23):

Abbie Watson (Dec 03 2020 at 21:24):

Josh Mandel (Dec 03 2020 at 21:24):

Josh Mandel (Dec 03 2020 at 21:25):

Abbie Watson (Dec 03 2020 at 21:26):

Abbie Watson (Dec 03 2020 at 21:27):

John Moehrke (Dec 03 2020 at 21:27):

Josh Mandel (Dec 03 2020 at 21:28):

John Moehrke (Dec 03 2020 at 21:28):

Josh Mandel (Dec 03 2020 at 21:29):

Josh Mandel (Dec 03 2020 at 21:30):

Abbie Watson (Dec 03 2020 at 21:30):

John Moehrke (Dec 03 2020 at 21:30):

Michele Mottini (Dec 03 2020 at 21:30):

John Moehrke (Dec 03 2020 at 21:30):

Josh Mandel (Dec 03 2020 at 21:30):

John Moehrke (Dec 03 2020 at 21:30):

Abbie Watson (Dec 03 2020 at 21:31):

Josh Mandel (Dec 03 2020 at 21:31):

Abbie Watson (Dec 03 2020 at 21:32):

Josh Mandel (Dec 03 2020 at 21:32):

Abbie Watson (Dec 03 2020 at 21:32):

Josh Mandel (Dec 03 2020 at 21:32):

Abbie Watson (Dec 03 2020 at 21:32):

Abbie Watson (Dec 03 2020 at 21:33):

John Moehrke (Dec 03 2020 at 21:33):

Abbie Watson (Dec 03 2020 at 21:34):

John Moehrke (Dec 03 2020 at 21:34):

John Moehrke (Dec 03 2020 at 21:35):

Abbie Watson (Dec 03 2020 at 21:35):

John Moehrke (Dec 03 2020 at 21:35):

Michele Mottini (Dec 03 2020 at 21:38):

Abbie Watson (Dec 03 2020 at 21:39):

Abbie Watson (Dec 03 2020 at 21:39):

John Moehrke (Dec 03 2020 at 21:41):

Abbie Watson (Dec 03 2020 at 21:41):

Abbie Watson (Dec 03 2020 at 21:43):

Michele Mottini (Dec 03 2020 at 21:43):

Michele Mottini (Dec 03 2020 at 21:44):

Michele Mottini (Dec 03 2020 at 21:45):

Abbie Watson (Dec 03 2020 at 21:45):

Vassil Peytchev (Dec 03 2020 at 21:52):

Josh Mandel (Dec 03 2020 at 22:00):

Lloyd McKenzie (Dec 03 2020 at 23:58):

Brendan Keeler (Dec 04 2020 at 05:45):

Brendan Keeler (Dec 04 2020 at 05:47):

Brendan Keeler (Dec 04 2020 at 05:55):

Debi Willis (Dec 04 2020 at 18:26):

Abbie Watson (Dec 04 2020 at 18:48):

Abbie Watson (Dec 04 2020 at 18:50):

Lloyd McKenzie (Dec 04 2020 at 19:48):

Abbie Watson (Dec 04 2020 at 19:57):

Lloyd McKenzie (Dec 04 2020 at 19:59):

Lloyd McKenzie (Dec 04 2020 at 19:59):