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

Query for data on a Patient when that Patient has been linked

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • STU3
    • Patient Administration
    • Patient
    • Hide

      PA Virtual WGM Q1 Jan 2021

      The merge behavior has been defined in https://confluence.hl7.org/display/PA/Merge+Operation.  This content will be applied to the spec in the Patient page, and likely the http and/or search pages.

       

      For patient linking, we are expecting that to be used only for cross-system linking.  For intra-system links, those may be an internal implementation detail, but the FHIR API would behave according to the merge behaviors defined in the content above.  The only potential operational impact of a linked resource may be the inclusion of an OperationalOutcome when searching for content for that linked resource.

       

      Regarding the "fixup" question (when merging, not through seealso links).  The server is expected to do the "fix up" by moving all data from the old patient to the new patient.  To communicate to the client, there are two cases:

      1. When looking at the patient resource, our guidance is to include a status of inactive with a link to the new patient.
      2. In the searching other resources case (e.g. Observation?patient=<oldid>), we are creating OperationOutcome codes to indicate that the client should perform merge resolution by going back to the Patient resource, follow the link, then re-query Observation with the new patient FHIR ID.

      For the OperationOutcome, there are two relevant error codes:

      • "transient" will be used for case where a merge is in process
      • a new code will be requested in https://build.fhir.org/valueset-issue-type.html (under processing) indicating that the data is located elsewhere (kinda like an HTTP redirect).

       

      Show
      PA Virtual WGM Q1 Jan 2021 The merge behavior has been defined in https://confluence.hl7.org/display/PA/Merge+Operation.   This content will be applied to the spec in the Patient page, and likely the http and/or search pages.   For patient linking, we are expecting that to be used only for cross-system linking.  For intra-system links, those may be an internal implementation detail, but the FHIR API would behave according to the merge behaviors defined in the content above.  The only potential operational impact of a linked resource may be the inclusion of an OperationalOutcome when searching for content for that linked resource.   Regarding the "fixup" question (when merging, not through seealso links).  The server is expected to do the "fix up" by moving all data from the old patient to the new patient.  To communicate to the client, there are two cases: When looking at the patient resource, our guidance is to include a status of inactive with a link to the new patient. In the searching other resources case (e.g. Observation?patient=<oldid>), we are creating OperationOutcome codes to indicate that the client should perform merge resolution by going back to the Patient resource, follow the link, then re-query Observation with the new patient FHIR ID. For the OperationOutcome, there are two relevant error codes: "transient" will be used for case where a merge is in process a new code will be requested in  https://build.fhir.org/valueset-issue-type.html  (under processing) indicating that the data is located elsewhere (kinda like an HTTP redirect).  
    • Brian Postlethwaite / Cooper Thompson : 10-0-0
    • Enhancement
    • Compatible, substantive
    • R5

    Description

      How should the case of a Patient that has been linked (link/merge/unlink) be handled? Is the server expected to understand a query against a Patient resource as equivilant to a query against all instances of that Patient? Or is this burden put upon the client to know that when the Patient they are interested has links, they are responsible for including the alias Patient resources too? I understood the expectation is to put complexity on the server side.

      Is the same behaviour expected of the patient compartment? Thus all compartments on each of the Patient resources that are linked act the same?

      Or, is a resource server expected to 'fixup' all resources so that they point at the prime Patient, thus acting more like a merge. My understanding of the discussion of Link vs Merge in FHIR to indicate Merge is not a supported architecture, that Link/Unlink is to be used.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: