Stream: argonaut
Topic: Handling deletion of records
Grahame Grieve (Apr 19 2018 at 20:42):
hi all - raising an issue on behalf of some consumers of the argonaut interface: how do we expect argonaut interfaces to handle deletion of records.
Grahame Grieve (Apr 19 2018 at 20:42):
the scenario goes like this:
Grahame Grieve (Apr 19 2018 at 20:45):
- a patient had his medication discontinued in the EHR
- the patient's PHR still showed the medication
- that's because the Argonaut interface from by which the data was accessed simply stopped including the medication order in their responses
- the PHR was expecting the status of the medication order to be updated, not for the resource to simply stop being reported
Grahame Grieve (Apr 19 2018 at 20:45):
when I was asked about this, I consulted the argonaut guide, which says nothing about it.
Grahame Grieve (Apr 19 2018 at 20:46):
generally, a consumer system can do either:
- know that it always gets snapshots, and delete anything not repeated (and never ask for updates)
- expect status changes to show what is not current
Grahame Grieve (Apr 19 2018 at 20:46):
FHIR expects the second.
Grahame Grieve (Apr 19 2018 at 20:47):
I think that argonaut needs some agreement about this. It's clearly a safety issue
Eric Haas (Apr 19 2018 at 20:51):
The status element are required. but that is different than deletion of records. Wouldn't you get a 410 status code back?
Grahame Grieve (Apr 19 2018 at 20:52):
if you read the resource again. but when would you do that?
John Moehrke (Apr 20 2018 at 12:02):
Possible mechanism: Provenance record is created to record the Delete act. This is a use-case for why Provenance supports Delete. See http://build.fhir.org/provenance.html#6.3.4.4
Eric Haas (Apr 20 2018 at 16:05):
still have to read the resource.
Jenni Syed (Apr 20 2018 at 16:39):
The way our FHIR server handles this is first and foremost: there is no such thing as "delete" for most clinically significant resources such as medications :)
Jenni Syed (Apr 20 2018 at 16:40):
With that assumption, for patient views, we send back the resource with an entered-in-error status if it's removed due to that reason. All else is essentially blank on the resource, but that way systems know to remove it
Jenni Syed (Apr 20 2018 at 16:40):
If it's a clinician or system viewing the data, they'll get the entered-in-error back along with more details that the patient wouldn't be able to see
Grahame Grieve (Apr 20 2018 at 21:10):
@Isaac Vetter / @Danielle Friend can you comment?
Isaac Vetter (Apr 20 2018 at 21:56):
Hey Grahame - we also use the status field. Including support for the entered-in-error status.
Grahame Grieve (Apr 20 2018 at 22:24):
ok thanks. I think we should document this explicitly
Eric Haas (Apr 21 2018 at 00:55):
I'll create tracker on github and gforge for Argo/USCore
Grahame Grieve (Apr 21 2018 at 01:21):
great thanks
Isaac Vetter (Apr 23 2018 at 02:33):
Hey Everybody - I wanted to clarify/correct my above answer. The Epic FHIR server's intent for a MedicationOrder?patient search is to return the patient's active med list. To get medications with other statuses, a client must specify the statuses that they wish to receive, but the active status must also be specified.
The MedicationOrder.status values that can be searched only include active,stopped and completed. I was wrong to suggest that entered-in-error is a searchable status. This behavior is how our MedOrder resource has worked since it's initial release and is documented in our various portals, including open.epic and App Orchard.
Last updated: Apr 12 2022 at 19:14 UTC
