Stream: patient empowerment
Topic: amendments
Virginia Lorenzi (Dec 22 2020 at 20:02):
I have been focused on the request process but I am curious about the actual amendment and communication of that across the API. In ONC certification, vendors need to support the ability to amend the record. However, providers do not have to use it. I wonder if this feature is being used in a widespread fashion?
Also if a record is amended, then I wonder what an amended EHR looks like and if the amended information is sent across the USCDI API and if so how? Are they additional documents? Notations on elements? Or are the amendments not going to API at all? Or is it indistinguishable from an update to a data element? @Jenni Syed @Drew Torres @Cooper Thompson @Vassil Peytchev
I wonder if today, when a patient requests an amendment and the amendment is done, if the amendment information ever makes it to the portal or API....
Cooper Thompson (Dec 24 2020 at 19:58):
Once a chart is corrected, that data is just part of the normal chart, and is available in the USCDI APIs. There aren't any special annotations we include to indicate that it's corrected. Lab results and notes may have a status of addended, but addendums can happen for a variety of reasons, not just due to chart correction.
Josh Mandel (Jan 04 2021 at 15:32):
What about the case where a provider decides not to update the record and instead files a patient's disagreement? Does this disagreement appear in the API somewhere? (I assume today the answer is no...)
Dave deBronkart (Jan 04 2021 at 15:34):
@Debi Willis I think this one's for you ...
John Moehrke (Jan 04 2021 at 15:50):
It certainly could/should show up as an AuditEvent. That AuditEvent would point at the evidence and request. But I suspect this is not visible, except to those that explicitly look at AuditEvent.
It could be recorded as a Provenance, but I am not sure how that would look. The problem is that a Provenance is the record (who, what, where, when, why) of a "change"; where this would be a non-change. Thus I am unsure how it would be recorded, or what it would be recorded against. Likely it would be a Provenance.target that is NOT a version specific target, where most Provenance.target are expected to be version specific. Thus it would be generally discoverable. The non-change aspect has not yet been modeled.
If we have an agreed object for patient corrections (e.g. specific kind of task), then those tasks could/should always be discoverable, regardless of if they were accepted or rejected.
What else might this show up as?
Jose Costa Teixeira (Jan 04 2021 at 16:25):
How do we capture the decision itself (of changing vs not changing)?
Josh's case could also be unfolded into "decides to update but only partially" or "decides to update but while doing that reqlizes other things need to change"
Josh Mandel (Jan 04 2021 at 17:42):
What else might this show up as?
A DocumentReference pointing to the letter from the patient (for instance)
Debi Willis (Jan 04 2021 at 22:35):
Josh Mandel said:
What about the case where a provider decides not to update the record and instead files a patient's disagreement? Does this disagreement appear in the API somewhere? (I assume today the answer is no...)
@Josh Mandel , I am not sure what you mean here. Are you asking how the Task resource would indicate the provider denied the correction request? If so, the Task would be updated on the provider side to indicate the status of "Denied" and would indicate the reason for the denial. When the patient app queries for the status update, and the patient sees the request has been denied, the patient can then send a disagreement with the denial. Is that what you were asking?
Josh Mandel (Jan 04 2021 at 22:56):
I guess I'm thinking about what happens after a denial, when different applications may be accessing this patient's record; is the idea that these subsequent apps would search the set of tasks and look for ones that represented denied amendment requests, and that's how they would discover the patient's disagreement letter? Or would they disagreement letter get stored as some sort of first class resource?
Debi Willis (Jan 05 2021 at 00:38):
@Josh Mandel I don't know how the EHRs or clinics are storing the data. But, that is a good point. Since the law requires the request for correction, the denial, and the patient disagreement to be shared on any subsequent disclosers of the data in dispute (if asked to do so by the patient), then it would seem important to have a way for that information to be shared via the API when requests for patient data are made via FHIR. I don't know how clinics are storing that information, but if it is in a note of some kind, then would it be included with the new USCDI list? (Just wondering...) I know this information would be important to research also.
If there are any health orgs or EHR vendors who could give us insight on this, that would be great!
Virginia Lorenzi (Jan 05 2021 at 03:21):
I am imagining its stored as a document in the record. Like an advanced directive or other patient correspondence. Its a good question to ask. I have several people I am reaching out to to understand workflows at different places. And could always use more...
Virginia Lorenzi (Jan 05 2021 at 03:23):
I think that perhaps the API would have it if it sends documents, but depends if the API supports that.
Lloyd McKenzie (Jan 05 2021 at 05:14):
There isn't a great way to link a DocumentReference to another resource (or set of resources) it's describing directly. So it would be good to know not only "how is it being exposed?", but also "how is it linked?" - because in principle when you query for data, you'd want to be able to use _include or _revinclude to bring back associated records of disagreement.
John Moehrke (Jan 05 2021 at 14:11):
@Lloyd McKenzie I don't understand your assertion. DocumentReference has many elements that can point at resources for various purposes, including .context.related which can be used for anything. A DocumentReference can also be the target of reference pointers elsewhere, such task.focus, task.for, task.basedOn, task.reasonReference, and I think task.input and task.output.
John Moehrke (Jan 05 2021 at 14:18):
Im not arguing that it is a rich structure, just trying to figure out if there is a need it is missing. I would like to see us use something more capable of showing relationships between inputs, outputs, rational, etc... so, I am agreeing that DocumentReference is not my first choice here. Would see Composition would be better. I am also not sure why the task itself isn't enough. Don't we just need a narrative to explain the outcome?
Debi Willis (Jan 05 2021 at 15:15):
I am not quite certain what use case we are talking about...but i am going to give this a guess. I think Josh was asking about the ability for FHIR to pull information about the denial of a correction request. I think that answer would be based on where that denial is stored in the EHR. Is it a document that can be pulled in via the Document reference?
First question: @Josh Mandel , did i reframe your question correctly? (If not, can you ask the question again in a different way so we can discuss the possible answers?)
Josh Mandel (Jan 05 2021 at 15:25):
I think you got the idea! the only slight tweak I'd make is I'm not specifically interested in the denial so much as making sure the patient disagreement statement shows up somewhere. If that comes along inside of a denial package that's fine.
Dave deBronkart (Jan 05 2021 at 15:27):
Josh Mandel said:
...making sure the patient disagreement statement shows up somewhere. If that comes along inside of a denial package that's fine.
I can't imagine that any other approach would make sense or even be feasible - right?
Dave deBronkart (Jan 05 2021 at 15:27):
("Feasible" as in "reliable.")
John Moehrke (Jan 05 2021 at 15:31):
I could imagine a type of Provenance that is specific to patient directed amendment requests. Both positive and negative. Thus they would be easy to find, and possible on all Resource types. This amendment Provenance can point (.target) at all the resources that were subject to the amendment request, and point at the amendment workflow (.entity). In the case of success or partial success, this Provenance would be truly provenance of the change. In the case of a rejected amendment request, this Provenance would serve as evidence that there was a dispute and the resolution.
Lloyd McKenzie (Jan 05 2021 at 15:41):
@John Moehrke The question is how does an Observation or MedicationRequest or Condition or other resource link to the DocumentReference that contains the "notice of disagreement". You're correct that DocumentReference.context.related, though the semantics of that are incredibly loose - and querying to bring back all DocumentReferences that point to a 'focal' resource using context.related is likely to be pretty overwhelming when you only want to retrieve the associated "notice of disagreement" (if any).
Lloyd McKenzie (Jan 05 2021 at 15:42):
I think we'd be better off with an explicit extension in the Observation/MedicationRequest/Condition/etc. At least then, there's a cue that says "hey, this exists, you should go get it".
John Moehrke (Jan 05 2021 at 15:42):
thanks.
John Moehrke (Jan 05 2021 at 15:42):
How about my proposal for Provenance as the linkage?
Lloyd McKenzie (Jan 05 2021 at 15:44):
Event that is somewhat problematic. You don't want to do a _revinclude on Provenance - that'd be super overwhelming
John Moehrke (Jan 05 2021 at 15:53):
The indication could be easily done with a .meta.security tag, that simply indicates a dispute resolution. That would be the trigger to a user of the resource. I am actually surprised that there isn't already a security tag code for that situation. The IG could create one.
Lloyd McKenzie (Jan 05 2021 at 15:54):
Tag isn't very useful. I'd much prefer a reference that tells me exactly what to retrieve.
Lloyd McKenzie (Jan 05 2021 at 15:54):
(which would mean an extension)
John Moehrke (Jan 05 2021 at 15:56):
My worry about an extension is that it is going to end up taking over the role that Provenance has for when the change was accepted. Thus I am looking for one way that covers. Rather than two different ways based on acceptance vs not.
Lloyd McKenzie (Jan 05 2021 at 16:07):
They're really two different things. Provenance is always a record of what changes were made, by whom, when and why. So if you care about that, that's where you look. Notice of disagreement is a quite different thing.
Abbie Watson (Jan 06 2021 at 02:56):
I built out our DocumentReference infrastructure over the holidays, and was pleasantly surprised to see DocumentReference.docStatus supports amendments. The CompositionStatus value set has prior-art on the document amendment process .
https://www.hl7.org/fhir/valueset-composition-status.html#4.4.1.432
It's a super simple valueset/workflow, but it's been in the spec since DSTU2 and is in production and currently available in the major EHRs public sandboxes. It's just enough API surface area to provide a RESTful interface to a PDF or document blob server, and links/amendments between files.
Virginia Lorenzi (Jan 06 2021 at 07:51):
See @Cooper Thompson response to amendment. I think disagreement needs to be discussed on a separate thread.
John Moehrke (Jan 06 2021 at 13:58):
@Abigail Watson not only that, but the whole predecessor standards that DocumentReference is based upon (XDS, XCA, XDR, etc) have since the beginning had amendment as a formal association type. Standards are often not the problem, policy and will to do the work tend to be the problem.
John Moehrke (Jan 06 2021 at 14:20):
the actual amendment in DocumentReference (and XDS/XCA/XDR/etc) is a linkage to the amendment. Thus Document (B) - the amendment- would have a DocumentReference.relatesTo that points at the Document (A) - the original - with a relatesTo.code of appends. As with FHIR (REST) the later object points at the older object. Thus to know if any DocumentReference (A) has been amended, one must look for other DocumentReferences with a relatesTo.target equal to (A) the DocumentReference you are interested in. -- This is used where the amendment is not considered invalidating of the original, but is seen as additional information.
This is distinct from where the amendment caused a revision of the original is decided upon. These tend to be where it is determined that the amendment is pointing out corrections that do change the substance. These revisions are done by replacing the original (A) with a new (A'). In this case (A') would (possibly) have a relatesTo.target equal to (A) with a relatesTo.code of 'replaces'. In the case of replacing the original (A) would be marked (.status) as superseded. Thus anyone with a persistent reference to (A) will see that it has been replaced, and can find (A') by querying for it as being a replaces of (A).
Note, this is very similar to what I have been proposing for use of Provenance resource.
Abbie Watson (Jan 06 2021 at 16:05):
Indeed. When we we installing our PDF/blob server while NYMH ‘went digital’ in the mid-aughts, we had a years-long debate over whether the document server was able to handle the full range of legal corrections that paper could handle. The IT team had an understanding that amendments and the entire legal document review cycle was covered by PDF, HTTP, XDS, and similar standards, and the whole system acted as a glorified microfiche machine of sorts. And we had to explain all that to physicians and clerks across the hospital, for whom it was new.
So this is debate is very familiar, and while I’m a bit rusty on some of the specifics, when the EHR vendors have claimed that HIPAA corrections are already supported in the existing APIs, it’s always rang true from my years of experience managing patient corrections on the provider side and deploying document servers.
I think of it similar to how millennials will take screenshots of things they’re reading and make memes out of it to share on social media, instead of copy-pasting the actual text. Having the structured data is ideal, but the entire HIPAA correction workflow can be handled with flattened files and photographs/scans of documents if one has to. Not every hospital has that infrastructure installed, but it’s a pretty standard module in any major EHR.
(Also, as an aside - Jean Baudrillard’s taxonomy of images has some excellent insights into document/image provenance, as it relates to diagnostic images vs referential images. It was an often used model that our department of Radiology used in determining whether a clinical legal decision could be made from a copy or scan of a photo. There’s a much needed valueset for provenance embedded in his work. Just need to convert his taxonomy of images into a value set and register it with LOINC and other value set authorities.)
John Moehrke (Jan 06 2021 at 18:29):
@Abigail Watson can you give me a pointer to that work? The FHIR Provenance is derived off of W3C PROV model, so it is based on a standard that is intended to be used well beyond healthcare, or even information. We manage the codes, as W3C PROV doesn't. So if there are Provenance concepts needed, we do not need to take them to LOINC.
Abbie Watson (Jan 06 2021 at 19:36):
Simulacra et Simulation, by Jean Baudrillard. It’s a short read, and the taxonomy of images he presents is covered in maybe the first 20 pages?
If I were to make a first pass at encoding the taxonomy, it would be something like [“image”, “photocopy”, “scan facsimile”, “simulation”]. I had to educate clinical staff throughout the hospital on the differences on nearly a daily basis... no, you can’t use that scan of the radiograph to rule out a diagnose of cancer, but you can use it to plan a surgical procedure; but if I pull the original radiograph, then you can make your cancer diagnosis with THAT copy; etc.
Importantly, it’s a model that can coherently discuss clinical impact and diagnostics when organizations do things like put PDFs in the PACS servers, or radiographs in their PDF blob server.
John Moehrke (Jan 06 2021 at 19:51):
Thanks. we do have some of that in terms of general concepts, not specific to image processing data fidelity loss. We do have derivations in Provenance. and we do have various levels of quality (as .meta.security tags)
Last updated: Apr 12 2022 at 19:14 UTC
