Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-28091

deleted resources requirements and guidance are unclear

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Published (View Workflow)
    • Medium
    • Resolution: Persuasive with Modification
    • US Core (FHIR)
    • 3.1.0
    • Cross-Group Projects
    • (NA)
    • Hide

      update text to: 

       

      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-error or inactive.
      • 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.

       

      Note that RESTful DELETE by Clients is out of scope for US Core and not germain here.

      Show
      update text to:    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-error  or  inactive . 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.   Note that RESTful DELETE by Clients is out of scope for US Core and not germain here.
    • Eric Haas/Drew Torres: 6-0-0
    • Clarification
    • Non-substantive

    Description

      The section on Representing Deleted Information is unclear what is a requirement for servers, what is a requirement for clients, what are recommendations (informative), and why there is a difference between patient apps and clinician apps.

      1. This section is unclear on if it applies only to resources that have had the REST "Delete" verb applied, or also applies to resources where the .status element has been updated.

      2. It is unclear in the first sentence "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.", why there is a statement about 'client systems know they can delete them.'. This might be referring to client systems that may have persisted locally a copy, but that is not clear. Is a client allowed to delete the local copy, or does the followup statements forbidding delete apply to clients too? This statement also is unclear if it is forbidding clients from using the delete verb with the server.

      3. Statements that "A FHIR server SHOULD not delete resources." is unclear given that a proper versioned FHIR delete seems appropriate. Does this forbid the use of the Delete verb? Does this forbid the use of versioning? 

      4. Statement that "The resource status SHOULD be updated to the appropriate status such as entered-in-error or inactive, and these resources SHOULD still be searchable by client applications.". Is this a recommendation that a Delete verb be transposed into an update of the .status?

      5. Is this statement "for patient viewing systems the content of resource SHOULD be removed. In other words a blank resource." a requirement, or a statement of common practice? If it is a requirement, then please explain why it is being recommended. What is the policy that drives use-case analysis to define this 'should' requirement. If this is a requirement, is it placed on the server or the client?

      5.1. What exactly is a "blank resource"? Seems a blank resource might be a minimally populated resource, but a minimally populated FHIR core resource is not compliant with US-Core. A minimally populated US-Core has legitimate data. So it seems impossible to have a US-Core blank resource.

      5.2. Is this blank resource requirement one that a server is expected to conform to? Meaning is the expectation that for all entered in error, the server will serve up blank resources? Or is this a User Interface expectation on the client? If it is a User Interface requirement, then can a client hide these, or must it show blank resource?

      6. Unclear who is responsible for this statement "A provider facing system MAY be supplied with additional details that the patient viewing system would typically not have access to."

      Attachments

        Activity

          People

            Unassigned Unassigned
            john_moehrke John Moehrke
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: