Stream: patient empowerment
Topic: Which resources for patient correction
Virginia Lorenzi (Sep 21 2020 at 19:38):
1)So in the simplest form, we have a request from a patient to a provider for their record to be requested
2)We then have a response, from the provider, to that request - a status which could be working on it, rejected, completed (I am glossing over some details here)
3)We then have the actual correction which happens async to the above (this is where provenance would help).
Also the HIPAA workflow is very much request/response but clearly not synchronous days could go by until its completed.
@Jeffrey Danford has suggested we use Comunication or CommunicationRequest to represent the patient's correspondence - we found that many of the fields we needed were there.
But then I wonder if it is ServiceRequest for the request.
And what would the response be?
@Debi Willis @John Keyes @Dave deBronkart @Abigail Watson @Adrienne Pichon FYI
Lloyd McKenzie (Sep 21 2020 at 19:48):
Communication/CommunicationRequest would NOT be the preferred approach. Task would be the right resource. It handles the accept/reject/working on it and also allows linking to the result
Abbie Watson (Sep 21 2020 at 20:11):
We'd be happy to support ServiceRequest, Task, Communication(Request) in an implementation guide or connectathon. I agree that Communication(Request) isn't the first choice preference; but I think it has slightly wider adoption and can be a workable solution. Preference would be for ServiceRequest.
Lloyd McKenzie (Sep 21 2020 at 22:46):
ServiceRequest (and CommunicationRequest and any other type of 'Request') have no ability to say "yes I will" or "no I won't". Task is the only structure that supports that.
Lloyd McKenzie (Sep 21 2020 at 22:46):
(along with 'why not' if the answer is no, or "where I'm at in the process" if started but not yet done)
Lloyd McKenzie (Sep 21 2020 at 22:48):
There isn't broad support for Task yet because there isn't broad support for allowing an external system to ask something of users in another system. (That's a tricky thing to get right.) ServiceRequest represents an 'authorization', but can't be used on its own to request action or to manage fulfillment.
Dave deBronkart (Sep 21 2020 at 23:39):
Lloyd McKenzie said:
There isn't broad support for Task yet because there isn't broad support for allowing an external system to ask something of users in another system. (That's a tricky thing to get right.) ServiceRequest represents an 'authorization', but can't be used on its own to request action or to manage fulfillment.
@Debi Willis @Virginia Lorenzi and others this looks like it's the crux of the cultural work we face in this project, yes?
@Lloyd McKenzie any thoughts on realities of negotiating such an "ask" when there's no question it's wrong, like Morgan's non-existent pregnancies, vs when the line may not be so clear? I'm keenly aware though that our job is not to define process (the "tricky thing to get right"?), it's to define what elements would/should be used to do the thing.
Lloyd McKenzie (Sep 21 2020 at 23:56):
I don't think the process is going to look terribly different. From the patient's perspective it's always going to be "unquestionably wrong" and the provider's perspective will be highly variable. The providers will be concerned from a process perspective of it being easy to approve stuff and have the change 'happen' - whether automatically or from work done by someone other than them. And if they reject, they don't want to have to deal with the same request the next day and the day after. I.e. they don't want to be spammed.
Dave deBronkart (Sep 21 2020 at 23:58):
I generally understand and agree - but in creating the IG, we are not accountable for that, right? It's sensible to be AWARE of it (pragmatic, as I say), but it's not what we define in any sense, right?
(btw I may be abnormal but sometimes I do propose a change to the record. But now that I think of it, that's always in dialog with my doc in portal mail, not via "FHIR bombs" ha ha)
Dave deBronkart (Sep 21 2020 at 23:59):
I keep thinking that the process will inevitably end up being like with credit cards: "Dispute this charge," which triggers a well defined process. Am I right?
Lloyd McKenzie (Sep 22 2020 at 00:19):
The IG is going to have a technical piece that will, most likely, not deal with it at all. The IG may also have some policy guidance to help guide implementers through the thought process of how to implement as painlessly as possible (and thus increase the odds of it being implemented at all). That's where such topics would most likely be advisable. That said, sometimes there can be technical solutions to policy type issues.
Abbie Watson (Sep 22 2020 at 00:19):
Lloyd McKenzie said:
ServiceRequest (and CommunicationRequest and any other type of 'Request') have no ability to say "yes I will" or "no I won't". Task is the only structure that supports that.
But it does have the capacity to say whether the request status is active(yes, I will), revoked (no, I wont), or completed (yes, I did). How does this not suffice?
Lloyd McKenzie (Sep 22 2020 at 00:20):
I don't know that our process will ever be as straight-forward as credit card statement challenges. With those, data propagation is limited, and professional pride has zero role to play.
Lloyd McKenzie (Sep 22 2020 at 00:20):
Request status being active means the authorization exists. It has nothing to do with whether the person you've asked to do it agrees to do it or not.
Lloyd McKenzie (Sep 22 2020 at 00:21):
A ServiceRequest might be activated and have 10 different tasks that get instantiated, some of which get accepted, others rejected because it takes multiple fulfillments to get to the point where all authorized actions are complete.
Lloyd McKenzie (Sep 22 2020 at 00:22):
Also, in general, ServiceRequest should never be edited by anyone other then the authoring organization - the filler systems never touch it (though they might create their own filler version of it).
Abbie Watson (Sep 22 2020 at 00:29):
In practice, I suspect ServiceRequest is going to get used to kludge together all sorts of order lists and task lists. ;)
That being said, I'll concede the point that Task is probably the more appropriate resource (if its supported).
Lloyd McKenzie (Sep 22 2020 at 01:29):
Task is going to be pretty essential to any sort of workflow. If an EHR doesn't have support for externally-influenced workflow, they're not super likely to be taking on patient-requested data changes anyhow...
Virginia Lorenzi (Sep 22 2020 at 01:38):
The Patient Correction Process has a formality to it. Both HIPAA and GDPR offer guidance. Even NY does. So we are using those types of workflows, especially the HIPAA one, as a template. We started mapping our datatypes to CommunicationRequest, but I think Task would work well. The body of the resource needs to contain what a patient wants changed in their record, which will most likely be unstructured, at least for now, with the possible exception of Patient. Then there are several other data pieces that are needed like encounter perhaps, and who to notify of the correction and then the responder has several options. Anyway those are the initial thoughts. Definitely is workflow stuff but I didn't think of Task - thanks!
Debi Willis (Sep 22 2020 at 01:58):
I will be giving a presentation of all this on Thursday in the FHIR-I 4 PM meeting. I will explain: our final goal (an implementation guide for patient corrections), what we have done so far, what we are looking at for next steps, and request for feedback and ideas for moving forward.
Virginia Lorenzi (Sep 22 2020 at 07:37):
We will also be introducing the project at our open house on Wednesday and working on the IG in several WGM sessions if anyone is interesting in coming to help!
Last updated: Apr 12 2022 at 19:14 UTC
