Stream: argonaut
Topic: FHIR-28091
Eric Haas (Nov 02 2020 at 21:39):
@John Moehrke? @Jenni Syed ?
Here is my proposed changes to this section to address John's questions, Jenni can you comment on this as well?
Representing Entered in Error and Deleted Information
Clinical information that has been removed from the patient's record needs to be represented by the FHIR Server in a way so that Clients can expose the corrected information to their end users.
Server Recommendations:
- A FHIR Server SHOULD NOT delete resources.
- A FHIR server SHOULD update the appropriate resource status to
entered-in-errororinactive. - A FHIR Server SHOULD allow these resources to be searchable by client applications.
- If the FHIR server has updated the resource status to
entered-in-error:
- For patient facing applications, A FHIR Server SHOULD remove the contents of resource leaving only an id and status. Note this typically will not be conformant with the US Core or FHIR StructureDefinitions.
- For provider facing applications, the content MAY be supplied with content and additional detail (such as the reason for the status change) that the patient viewing system would typically not have access to.
Eric Haas (Nov 02 2020 at 21:43):
here is what we published :
Representing Deleted Information
Clinical information that has been removed from the patient's record needs to be represented in a way so that client systems know they can delete them.
A FHIR server SHOULD not delete resources.
The resource status SHOULD be updated to the appropriate status such as
entered-in-errororinactive, and these resources SHOULD still be searchable by client applications.If the status is
entered-in-error:for patient viewing systems the content of resource SHOULD be removed. In other words a blank resource.
A provider facing system MAY be supplied with additional details that the patient viewing system would typically not have access to.
Jenni Syed (Nov 02 2020 at 22:35):
cc @Drew Torres
Drew Torres (Nov 02 2020 at 22:40):
I like the additional clarifications and text.
Drew Torres (Nov 02 2020 at 22:40):
Do we want o just have id and status?
Drew Torres (Nov 02 2020 at 22:40):
Should we say bare minimum to meet FHIR spec with text of unknown as needed?
John Moehrke (Nov 03 2020 at 01:20):
Thanks. is it already clear that your scope is EHR? These kind of requirements should not be mandated of "all FHIR Servers", just those that are legal EHR. recognizing that FHIR can be used for many things, not just treatment.
Eric Haas (Nov 03 2020 at 02:16):
Drew Torres said:
Should we say bare minimum to meet FHIR spec with text of unknown as needed?
yeah... its more complicated than that. remove content from all the min = 0 , DAR mandatory elements with concept for maskedand for bindings extend valuesets to have concept for masked
if we decide that we need to jump through the hoops for profile purity ( do clients validate on the fly?) then will recommend an inline example for clarity
Eric Haas (Nov 03 2020 at 02:29):
John Moehrke said:
Thanks. is it already clear that your scope is EHR? These kind of requirements should not be mandated of "all FHIR Servers", just those that are legal EHR. recognizing that FHIR can be used for many things, not just treatment.
Yes this is not just EHRs though... any data source should take this action if it discovered that its entered in error
John Moehrke (Nov 03 2020 at 13:42):
That I disagree with. A data set that happens to use the FHIR datamodel because they are dealing with synthetic data, but is a constrained environment where external references are known not to exist, should be able to delete completely without any trail.
John Moehrke (Nov 03 2020 at 13:44):
The reason this special handling in an EHR is needed is because of multiple factors. Legal requirements around medical-records, medical-safety, medical-litigation, public-health, etc... these are legal basis as to why lifecycle-management is critical in an EHR. These do NOT exist in a PHR, or many other uses of FHIR.
John Moehrke (Nov 03 2020 at 13:46):
The other special reason is that we are all encouraging EHR to be open, and thus references to a data object are expected (hoped for) between different organizations EHR. This means there is a need for trail of delete to be detected. This is tied to the legal requirements, but is also needed simply because of relational linkages. This relational linkages is why a PHR 'should' also be doing this,.. but a PHR would not have the legal requirements (at least not yet there is no legal requirements on PHR. that I know of)
Eric Haas (Nov 03 2020 at 16:47):
These are SHOULDs and not SHALLs and I think it supports your assertion above.
Eric Haas (Nov 03 2020 at 16:48):
As I mention about the DELETE interaction is not in scope for US Core.
Brian Postlethwaite (Nov 03 2020 at 21:04):
The other issue you've missed there @John Moehrke is where content is replicated - such as to a phone app, or other system, or subscriptions - if the resource is gone, they can't know that, and are left with invalid content.
John Moehrke (Nov 03 2020 at 22:07):
I agree.. .but there are plenty of non-treatment use-cases where one must simply be robust to the data disappearing. This is common in the great world of http-REST
Eric Haas (Nov 04 2020 at 16:43):
I appreciate @John Moehrke looking at this and making us take a second look and think about it.
Last updated: Apr 12 2022 at 19:14 UTC
