Profiles & Operations > Patient EMPI Match

Patient EMPI Match

This section describes the FHIR Patient EMPI Match operation. It has been constrained to meet Ontario's requirements.

The Patient EMPI Match operation provides a RESTful approach to performing an EMPI query based on the search criteria provided from a client. In an EMPI query, a set of criteria are provided and the EMPI match operation performs a probabilistic match, such that results may not match all of the criteria - or even any of the criteria - exactly. Results are based on server-specific rules that allow for alternate spellings, typos, historical patient information and other factors to find the patient records that have a high probability of a match. Each record is accompanied by a score that indicates the server's evaluation of the likelihood that the specified record is the one being sought.

In the PCR Patient Match operation, the query must contain a Parameters resource which contains a Patient resource that is populated with what information is known about the patient in an attempt to find the PCR's corresponding record. The more information provided, the more likely PCR will be able to find the appropriate patient record with greater certainty to establish a match.

Scope

This transaction involves a request by a FHIR Client Application for the information about a patient whose demographic data matches the data provided in the FHIR operation request. PCR receives and processes the request, and returns a FHIR Bundle containing a list of potentially matching Patient records. PCR requires that the Minimum Search Criteria be met in order to return patient records.

Storyboard

PCR stores accurate and up to date patient demographics and associated identifiers for consistent access across the enterprise.

This storyboard demonstrates querying PCR for a list of patients matching a set of demographic information.

Narrative Example

Adam Everyman has a consultation with Dr. Fay Family to discuss the likelihood that he has inherited Parkinson's disease. Adam's father died last year so Adam gives his permission for Dr. Family to look at his father John's records. Dr. Family enters John's name, gender, and date of birth into his EMR system, which in turn, performs a Patient EMPI Match Query against the PCR.

Dr. Family's search for Adam's father, John, is successful and the PCR Patient EMPI Match Query Response returns two records with summary information (e.g. name, date of birth, gender, Ontario Health Card number, address, phone number). She then uses John’s Phone Number to determine the appropriate record to access his clinical information relating to Parkinson's disease.

Interaction Diagrams

The following diagram illustrates the high level interaction between a FHIR Client Application and the PCR. The Patient EMPI Match operation will use the following query and response interactions:

  • Patient EMPI Match

  • Patient EMPI Match Response

PatientEMPIMatchSmall

Actor: FHIR Client Application

Role: Requests a list of patients with a probabilistic match on the supplied set of demographics criteria (example: ID or Name) from the PCR. The Client Application populates its local store with demographic information received from the PCR.

Actor: PCR

Role: Returns demographic information for all patients matching the demographics criteria provided by the FHIR Client Application.

Patient EMPI Match Operation

This operation is the PCR FHIR implmentation of HL7 FHIR R4 Match operation. The operation definition is provided here.

Trigger Event

This operation will be invoked when the client application requests a patient record from the PCR by providing known information about the patient in the search parameters.

Summary of Supported Operations

The table below shows the allowed transactions for each profile and how they support FHIR endpoints, resources and their corresponding HTTP operation:

Resource Transaction HTTP Operation URL Request Body Resource Response Body Resource
Patient EMPI Match POST [base]/Patient/$match{?[_format=mime-type]} Parameters containing a single Patient parameter A searchset Bundle containing Patient entries

The interaction summary table below lists the HTTP status codes that may be returned for the query:

Interaction Content-Type Body Location Versioning HTTP Status Codes Comments
(operation) R R: Bundle N/A N/A 200,400,404,422,500

Expected Behavior

The PCR shall return patient records that have a probabilistic match to the search criteria provided by the FHIR Client Application. The PCR shall respond synchronously (i.e. on the same connection as was used to initiate the request).

The FHIR Patient EMPI Server shall respond to the query request as described by the following cases listed below:

Case Scenario Description Response Response Example
1 PCR finds in its information source, at least one patient record with a sufficiently high probabilistic match on the criteria sent in the input Patient record. HTTP 200 (OK) is returned as the HTTP status code. A Resource Bundle is returned representing the result set. Refer to Bundle definition here. Match Response Example
2 PCR cannot find any patient record matching the criteria in the source patient record. HTTP 200 (OK) is returned as the HTTP status code. A Bundle Resource is returned with zero search results. The resource includes an OperationOutcome Resource with a warning indicating no patient found. The client should confirm the request criteria is valid, and if so, contact eHealth Ontario for troubleshooting. Empty Bundle Response
3 PCR cannot validate the request as it does not conform to the specification. HTTP 422 (Unprocessable Entity) is returned as the HTTP status code. An OperationOutcome Resource is returned indicating an issue, where applicable. The client must fix the request to align with the specification and try again.
4 The requested resource is not supported. HTTP 404 (Not Found) is returned as the HTTP status code. The body contains an OperationOutcome with error details, where applicable.
5 EMPI Match request contains unsupported FHIR format type in the request Content-Type header. HTTP 400 (Bad Request) is returned as HTTP status code. An OperationOutcome Resource is returned indicating only XML and JSON format are supported in the Content-Type header, where applicable. The The client must fix the request and try again.
6 EMPI Match request does not meet the Minimum Search Criteria. HTTP 400 (Bad Request) is returned as HTTP status code. An OperationOutcome Resource is returned indicating insufficient search criteria has been provided. The client must add additional search criteria to the request to meet the minimum, and try again.
7 PCR validates the request but cannot return a valid response due to an internal issue. HTTP 500 (Internal Server Error) is returned as the HTTP status code. An OperationOutcome Resource is returned indicating an issue, where . Client should contact eHealth Ontario for trouble shooting.

Resource Profiles

This operation is based on the HL7 FHIR R4 Patient Match operation. It makes use of the following resource profiles:

Patient EMPI Match Request

To query the PCR to match a patient, clients call the Patient EMPI Match operation, which processes a parameters resource (i.e. Request Parameters - Patient Match ) containing a complete or fragment of a patient resource (i.e. Patient Match Request), along with some other control parameters.

The patient resource provided must be parsable to pass request validation.

Note: Only certain patient attributes are used to find matched patients. Refer to the Scoring section below for context.

The following resource profiles are used in Patient EMPI Match Request:

The relationship between the resources used in EMPI request is below:

pcr-empi-match

Patient EMPI Match Response

The response from a Patient EMPI Match operation is a set of patient (i.e. Patient Response) records (i.e. Response Bundle), ordered from most likely to least likely. If there are no patient matches, it will return an empty search set with no error, but may include an OperationOutcome with further advice.

The following resource profiles are used in Patient EMPI Match Response:

Command 'tree' could not render: Project was not found for ProvincialClientRegi/pcr-patient-response-png.

The PCR FHIR profiles are developed to constrain value sets and cardinality of data elements in the resources listed above. For data elements not covered in FHIR, we have introduced a few extensions which are called out in the patient profile.

Examples

Examples of a match request can be found here:

Examples of a match response can be found here.

Example of a OperationOutcome can be found here.

Appendix: Business Rules

The following sections describe the business rules specific to the Patient EMPI Match operation that may be helpful to implementers.

Minimum Search Criteria

As part of privacy governance in managing queries against the PCR, the Ministry of Health (MoHLTC) and Information and Privacy Commissioner of Ontario (IPC) have mandated a specific set of minimum criteria that must be met when querying the PCR. One of the following minimum criteria must be met:

Query by:

  1. Informational identifier such as HCN, MRN, or AltID. Note that MRN and HCN may be definitional or informational depending on the source implementation model. EMPI match only supports the informational format of these identifiers.

  2. First Name + Last Name + Date-of-Birth

  3. First Name + Last Name + Address (minimum of Postal Code)

Additional optional query criteria ‘on top’ of one of the minimum sets above is supported (e.g. optional gender). If the one of the above minimum criteria is not met, PCR will return a ‘minimum criteria not met’ error.

Patient Records

Patient EMPI Match Response represents a summary view of patient records as per PCR business rule. The following element(s) in the patient resource will not be populated for Patient EMPI Match:

  • Patient.multipleBirth[x]

Given the Patient EMPI Match response provides a summary view, FHIR recommends that additional information should be included in Patient.meta.tag and the summary view should not be used to update patient records in the PCR. The Patient.meta.tag will therefore be populated in the EMPI Match response as follows:

<meta>
    <tag>
        <system value="http://hl7.org/fhir/v3/ObservationValue" />
        <code value="SUBSETTED" />
        <display value="subsetted" />
    </tag>
</meta>

Maximum Results

As part of privacy governance in managing queries against the PCR, the Ministry of Health (MoHLTC) and Information and Privacy Commissioner of Ontario (IPC) have mandated a maximum result set of 5 matched candidates on a given PCR response.

Scoring

PCR is currently configured to return candidates matched on any positive score (i.e. greater than zero) across HCN, Name, Gender, Address, or Phone attributes. Any other attribute(s) included in the search are not considered.

Based on the minimum search criteria enforced, this translates to a positive score matched based on Name + DOB or Name + Address (postal code minimum).

PCR currently returns matched candidates in descending order based on match score (highest scoring first, lowest scoring last). Note that more than one candidate may receive the same match score and will be ordered in the query response message accordingly. The match score returned for an individual candidate depends on the query criteria used to perform the search. The returned value for an individual candidate match score is based on the search algorithm outlined in the Business Context section.

The expectation is that consumers will display PCR matched candidates in the order returned from the PCR without display of the corresponding match score per individual candidate. For further information on interpreting individual match scores, please contact the eHealth Ontario Registries Product Management Team at oh-ds_registries@ontariohealth.ca.

'Batch' Queries

The Patient EMPI Match operation is designed to return candidates with the goal of resolving the results to a single patient. Overloading a Patient EMPI Match to query on multiple identifiers, phones, or addresses with the goal of resolving to different patients via a single ‘batch’ request is technically possible, but per the following caveats:

  1. A query with multiple IDs should be bound to a single identifier type; one of HCN, MRN, or AltID, but not a mix of these identifier types.

  2. A query with multiple IDs should be bound to a maximum of 25 IDs.

Powered by SIMPLIFIER.NET

HL7® and FHIR® are the registered trademarks of Health Level Seven International