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

Patient.Search oughtn't be used as EMPI lookup; that's what $match is for.

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: Medium Medium
    • US PACIO Advance Directive Interoperability (FHIR)
    • 0.1.0
    • Patient Empowerment
    • STU
    • Use Cases
    • Hide

      We fully agree and will harmonize the ADI IG with the $match operator guidance and update the IG to make that clear.

      Show
      We fully agree and will harmonize the ADI IG with the $match operator guidance and update the IG to make that clear.
    • Dave Hill / Virginia Lorenzi : 7-0-0
    • Correction
    • Compatible, substantive

      In a few places, the IG states or implies that Patient.search is an appropriate and expected method for an EMPI-lookup function. In use-case 3 (HL7.FHIR.US.PACIO-ADI\Use Cases - FHIR v4.0.1), the IG states:

      > First the Content Requester will use a GET Patient request using patient matching information. The Content Custodian server returns all Patient resources to the Content Requester.

      A well behaved EMPI lookup API should:

      1. Return no matches if multiple matches are found.
      2. require a base minimum number of data elements to perform a search.

      Worse, you encode this idea in required search parameters in an unsafe way, by requiring a server to support empi lookup on only: birthdate, deathdate, family, gender, given, name. HL7.FHIR.US.PACIO-ADI\PADI CapabilityStatement - FHIR v4.0.1

      At minimum, you should only require safe and EMPI appropriate combinations of search parameters, but the right thing to do would be to not use Patient.search for EMPI lookup and instead use $match.

       

            may_terry May Terry
            Isaac.Vetter Isaac Vetter
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: