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

Add guidance on matching patients

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci CDex (FHIR)
    • current
    • Patient Care
    • (NA)
    • Hide

      Add a section to the workflow that makes it clear that doing patient lookup to determine the patient FHIR_id on the server is a prerequisite to performing both RESTful search and Task-based query.  (patient business identifiers not widely supported as FHIR references in EHR today)

      Document Options:

      both task based and direct query require a patient FHIR_id 

      Solutions to get it

      Option A:  Identifier search on Patient with identifier = member_id

      e.g. Get patient ?identifier = <member_id>  {& name} & {gender or dob} 

      Background:  Easiest solutions from the CDEX perspective would be for but member_id as identifiers may or may not work that way now IRL

      Option B: Coverage search to obtain the Patients FHIR_id through the beneficiary element.

      e.g. GET Coverage ?payor & member_id and/or subscriber_id

      Note that whether this will work with EHRs - not confirmed

      Background: see comment below re where the data resides in the EHR

       Option C: Use Patient Match operation: http://build.fhir.org/patient-operation-match.html

      Show
      Add a section to the workflow that makes it clear that doing patient lookup to determine the patient FHIR_id on the server is a prerequisite to performing both RESTful search and Task-based query.  (patient business identifiers not widely supported as FHIR references in EHR today) Document Options: both task based and direct query require a patient FHIR_id  Solutions to get it Option A :  Identifier search on Patient with identifier = member_id e.g. Get patient ?identifier = <member_id>  {& name} & {gender or dob}  Background:  Easiest solutions from the CDEX perspective would be for but member_id as identifiers may or may not work that way now IRL Option B : Coverage search to obtain the Patients FHIR_id through the beneficiary element. e.g. GET Coverage ?payor & member_id and/or subscriber_id Note that whether this will work with EHRs - not confirmed Background: see comment below re where the data resides in the EHR   Option C : Use Patient Match operation:  http://build.fhir.org/patient-operation-match.html
    • Eric Haas/Jay Lyle: 8-0-1
    • Enhancement
    • Non-substantive

    Description

      Add a section to the workflow that makes it clear that doing patient lookup to determine the Patient URL on the server is a prerequisite to performing both RESTful search and Task-based query.  Also, we may need to provide some additional conformance constraints on top of US-Core patient search, for example mandating the ability to pass member identifier and/or beneficiary identifier as search parameters. 

      Attachments

        Activity

          People

            Unassigned Unassigned
            lloyd Lloyd McKenzie
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: