Patient Safety Issues in Merging Client IDs with FHIR Specifications
Focusing on the potential patient safety risks associated with merging client IDs using FHIR specifications. The discussion highlights challenges, system behaviors, and the impacts on both demographic and health information records. It also presents a scenario illustrating problematic behaviors and the ideal behavior post-merge to ensure patient safety.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Client ID merge on FHIR Patient-safety issues related to merging client IDs using existing FHIR specifications.
Overview A PIXm work item is active, during the 2018-2019 cycle, in IHE s IT Infrastructure (ITI) technical committee; this work item is focused on profiling a FHIR equivalent to the ITI-8 Patient Identity Feed transaction ITI-8 includes a description of system behaviours following a client ID merge operation There are challenges in operationalizing client ID merge using FHIR; these challenges present potential patient safety risks 2
The problem scenario Workflow: 1. 2. Client Registry (CR) record ID-1 created for John Shared Health Record (SHR) transaction TX-A recorded for John under ID-1 CR record ID-2 created for John, in error 4. SHR transaction TX-B recorded for John under ID-2 Result: there are, in error, multiple enterprise IDs for John in the CR and there is health information about John in the SHR under each separate ID 3. 3
Problematic system behaviour A query against the CR using either ID-1 or ID-2 will, in error, appearto correctly resolve to John s single, definitive, golden demographic record A demographic query against the CR will return, in error, multiple records for John with no way to establish which one is the definitive golden record An update to the CR using either ID-1 or ID-2 will, in error, appear to have updated John s golden record A query against the SHR using either ID-1 or ID-2 will, in error and unsafely, return only a partial subset of John s health information 4
Behaviour of the fixedproblem It is detected that CR ID-1 and ID-2 both refer to John and the two IDs are merged Following the merge transaction: There is 1-and-only-1 enterprise ID for John in the CR; a query on this ID will return John s single golden demographic record A query against the CR using ID-1 or ID-2, or any demographic query, will resolve to John s golden record & enterprise ID A query against the SHR using John s enterprise ID will return all of John s health information (TX-A and TX-B) 5
Some questions What should be the mandatory behaviour of a FHIR patient merge operation in OpenHIE? (https://hl7.org/fhir/2018May/patient.html#merge) What architectural role should the CR play in operationalizing a patient ID merge ? (https://hl7.org/fhir/2018May/patient.html#match) What are some of the current approaches to addressing patient ID merging ; can they inform our approach in OpenHIE? (https://mitre.github.io/ptmerge-interface/) What architectural role should the OpenHIE Interoperability Layer (IOL) play in operationalizing a patient ID merge ? Can the IOL be employed to orchestrate the long-running FHIR transaction(s) needed to enforce patient-safe behaviours of an HIE? 6
