FHIR Chat · Correcting Errors in Argonaut data · argonaut

Stream: argonaut

Topic: Correcting Errors in Argonaut data

Grahame Grieve (Jun 14 2019 at 22:12):

there's a thread on patient empowerment about correcting data. Is this something that argonaut has ever taken up? (e.g. creating an API to request corrections)

Grahame Grieve (Jun 14 2019 at 22:12):

https://chat.fhir.org/#narrow/stream/179262-patient-empowerment/topic/FHIR.20adoption

Debi Willis (Jun 14 2019 at 22:42):

I’m not able to open up that message. Hopefully we can ignite the conversation again. I think the topic is important.

Grahame Grieve (Jun 14 2019 at 22:53):

I think that the API should be a task or something - not just 'fix' the resource and post it. So something like :

{
  "resourceType" : "Task",
  "status" : "requested",
  "focus" : {
    "reference" : "Condition/234234234234"
  },
  "intent": "proposal",
  "authoredOn" : "2019-06-15T08:46:00+10:00",
  "requester" : {
    "Patient" : "Patient/123456"
  },
  "code" : {
    "coding" : [{
      "system" : "http://terminology.hl7.org/CodeSystem/v3-ActReason",
      "code" : "FIXDATA"
    }]
  }
  "note" : [{
    "text" : "The condition says \"Pregnant\" but I am a male"
  }]
}

Josh Mandel (Jun 14 2019 at 22:58):

Would you also want to convey some structured representation of what needs to change (e.g., include in the task a patch or something)?

Josh Mandel (Jun 14 2019 at 22:59):

(I think text notes are a great place to start; it'd be good to have a follow-on story about conveying details.)

Grahame Grieve (Jun 14 2019 at 23:01):

I did not think that would be realistic... firstly, generating a patch either implies a sophisticated user or a sophisticated algorithm (e.g. https://github.com/grahamegrieve/fhirserver/blob/master/library/tools/FHIR.Tools.DiffEngine.pas). And even if you did, what clinical user would be in a position to just agree with the change and apply it? I think that most raised issues would be less precise that the record needed

Grahame Grieve (Jun 14 2019 at 23:01):

though I would be in favor if the receiving systems agreed it would be worth it

Josh Mandel (Jun 14 2019 at 23:01):

In specific domains like med rec, it's very useful to be able to adjust (e.g., a dose)

Josh Mandel (Jun 14 2019 at 23:02):

I mean, I think it's a win to start with something simple, so I wouldn't push for structured data here. Just that it's good to think ahead a bit.

Josh Mandel (Jun 14 2019 at 23:03):

A structured med rec process resulting in "Please adjust my metoprolol dose from 50 mg twice daily to 25 mg twice daily" could be just fine.

Josh Mandel (Jun 14 2019 at 23:04):

In your example though I think the Task.requester should be Patient, rather than Task.owner.

Grahame Grieve (Jun 14 2019 at 23:28):

oh yes - fixed it

Grahame Grieve (Jun 14 2019 at 23:30):

I'm not sure how one would introduce a patch into this...

Josh Mandel (Jun 15 2019 at 01:14):

(there could be a pointer to... Ugh, a contained Bundle with a Patch entry?)

Grahame Grieve (Jun 15 2019 at 01:17):

yes would have to be an extension

Josh Mandel (Jun 15 2019 at 04:58):

Or an input.valueReference

Jenni Syed (Jun 17 2019 at 13:59):

Out of curiosity, why create a completely separate resource vs. an operation on the actual resource (the patch would be the "normal" patch body)?

Jenni Syed (Jun 17 2019 at 14:00):

I know for patient contributed "creates" we had considered using a normal POST for resources, knowing that it would likely have a security tag of "unreliable" (or something similar) in our system until it was reviewed by a doc

Jenni Syed (Jun 17 2019 at 14:01):

I think updates are more interesting/complicated

John Moehrke (Jun 17 2019 at 14:43):

That update would have a different Provenance too.... but I would agree a security tag is much quicker to see when looking at the Resource. I would expect once it is reviewed by a doc that the tag would be removed, and a new Provenance indicating the Verification activity.

Jenni Syed (Jun 17 2019 at 15:48):

Yes, provenance would track the source and modifications/changes

Grahame Grieve (Jun 17 2019 at 17:54):

@Jenni Syed mainly because I think that is the typical patient workflow here with regard to patient initiated corrections. It's a message about the issue, anchored to the context.

There is other workflows associated with data management by the patient where that would be entirely inappropriate.

Note that I am assuming here that the patient is asking for corrections to their provider maintained (HIPAA covered) clinical record, one that they do not have write access too, and won't be granted access to

Josh Mandel (Jun 17 2019 at 22:46):

To be fair, the idea of "Correcting" my med list to add or remove an entry is a pretty natural kind of correction.

Grahame Grieve (Jun 17 2019 at 22:49):

it seems natural to the consumer, yes, but in fact it's not so easy.

Josh Mandel (Jun 17 2019 at 23:06):

Certainly if we just want to convey a note for a human on the other side, it generalizes well

Josh Mandel (Jun 17 2019 at 23:07):

As far as I'm concerned it is essential that patients have a way to correct data, and these corrections will not always fall directly along FHIR resource boundaries. The API for sending a "please correct" message to the human doesn't care

Grahame Grieve (Jun 17 2019 at 23:15):

right. which is why I proposed something that may have a context but doesn't need it, rather than making it based around put/post of existing resource types

Josh Mandel (Jun 17 2019 at 23:17):

Which I think is great! I'm just saying that we should define a way to communicate more structured hints (e.g., an included set of Bundle interactions, whether patch, delete, or create) in the protocol.

Brian Postlethwaite (Jun 18 2019 at 02:58):

I was thinking also including a known tag to indicate that the resource has been marked for corrections.

Brian Postlethwaite (Jun 18 2019 at 02:59):

Maybe include an extension in the meta tag to the potential correction.

John Moehrke (Jun 18 2019 at 14:21):

You already have these tag values http://build.fhir.org/v3/SecurityIntegrityObservationValue/vs.html (..., RELIABLE, UNCERTREL, UNRELIABLE, CLINAST, ...) Which can help tag data... I agree with Grahame that the request by a patient to correct data is a Task. A task that might correct the data eventually, or not... but a task that is the record of the request to correct the data.

Ricky Bloomfield (Jul 03 2019 at 00:53):

I'm catching up on this a little late, but I like the proposed approach here to implement this as a task, per @Grahame Grieve. Far more than the technical implementation, it will be critical to understand how health systems would want to receive these requests. E.g., some may want them to go to the Medical Records/HIM department for triage, at which point they would send a formal request to the correct party to make the change. It's hard to know how patients might use this - some submissions might be true errors while others might be disagreements or simply misunderstandings. We should start as simply as possible until the variety of use cases becomes clear. More structured input might be useful for some cases (like medications, per @Josh Mandel), but until the provider workflow for this particular request is well understood, the value of more structure vs prose isn't clear to me.

Jenni Syed (Jul 03 2019 at 12:44):

I'm curious why we think the structured data isn't helpful or is challenging. We have patients submit forms and data already today via portals (for eg) where the data comes in structured and is reviewed/accepted by the care team - most often during or right before an appointment, for eg

Jenni Syed (Jul 03 2019 at 12:46):

What would we expect the task to look like?

John Moehrke (Jul 03 2019 at 13:25):

Where it is supported today, for a patient to submit data and submit change requests, there is a functioning system that is specialized for that organization. Submitting data is well profiled in SMART and US-Core. What is not well defined is the way a patient can submit a change request upon noticing bad data in their record. I think a 'standardized' workflow leveraging Task might be interesting, but it is not likely to inspire those organizations that are not today providing the ability for a patient to submit a change request. The best this could do is provide a reference-model. This reference-model would be helpful in leading the way. In a very distant future one could imagine apps and patient workflows that could automate the (bad) data selection with rational on why it is bad and specific instructions on desired change being requested. However in the near future this is far more likely to be local organization specific patient portal forms such as Jenni refers to. --- so I think this is interesting, but not realistic. Useful as a reference-model, but not as an expected Task workflow.

Jenni Syed (Jul 03 2019 at 13:28):

I guess, specifically, I'm trying to understand if Task is getting us further than a communication at this point. I know task is a more formalized request (from the FHIR perspective) to ask for something to change, though it does assume that the underlying system would be able to translate that to something similarly actionable.

Jenni Syed (Jul 03 2019 at 13:30):

There also seems to be an assumption that there's resistance to allowing this workflow, and so we're starting off with something very basic :) Would love to see some feedback on that from others.

Lloyd McKenzie (Jul 03 2019 at 13:44):

Communication is never about "Please do". It's just about passing around data. Task lets you ask for something to be done - and lets you say yes or no and indicate progress

Brian Postlethwaite (Jul 03 2019 at 21:09):

The Task could contain a "patch" indicating the data that is to be corrected (I'd prefer this over a full patient resource instance for example, which may be incomplete for various reasons)

Brian Postlethwaite (Jul 03 2019 at 21:09):

Has anyone drafted up an example of any of these suggestions?

Grahame Grieve (Jul 05 2019 at 22:32):

well I put an example further up. I'm not against structured data here. I just think that the more likely thing is a comment 'this is not correct, because X'. I agree that there are other things such as adding a medication to the list.

Grahame Grieve (Jul 05 2019 at 22:32):

I don't feel strongly about Communication vs Task... it depends how you conceptualise the workflow, I think

Brian Postlethwaite (Jul 05 2019 at 23:58):

@David Hay this stream on the patch style update might be appropriate to your use case.

Last updated: Apr 12 2022 at 19:14 UTC