Profiles & Operations > Cross-Identifier - PIXm

Patient Identifier Cross-reference - PIXm

This portion of the specification is based on the documentation developed by IHE to address the PIXm query.

The Patient Identifier Cross-reference for Mobile (PIXm) Profile defines a lightweight RESTful interface to a Patient Identifier Cross-reference Manager, leveraging technologies readily available to mobile and lightweight applications.

In this implementation, the PCR fulfills the role of Patient Identifier Cross-reference Manager and will be referenced as such for the rest of this page. The Patient Identifier Cross-reference Consumer will be referred to as FHIR Client Application to be consistent with the other operations.

The scope of IHE PIXm functionality is based on the PIX Profile described in the ITI TF-1 (http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf). The primary differences between PIX and PIXm are in the transport and messaging format of messages and queries. The IHE PIXm profile leverages HTTP transport, and the JavaScript Object Notation (JSON), XML, and Representational State Transfer (REST). The payload format is defined by HL7 FHIR R4.

Scope

This operation involves a FHIR-based request by the FHIR Client Application for a list of patient identifiers that correspond to a patient identifier known by the consumer. The PCR receives and processes the request and returns a response in the form of a list of corresponding patient identifiers, if any are found.

For example, a patient might arrive at hospital A with a Medical Record Number (MRN) card from hospital B. In order to find all identifiers that are used to refer to this patient across all contributing sites, a PIXm query is sent to the PCR (which is the PIX Manager in Ontario). The response message received by the Hospital A's hospital information system contains a list of identifiers including the client's MRN in hospital A and a global identifier recognized by all health care organizations such as Ontario HCN or PCR ECID (Enterprise Client Identifier).

This operation corresponds to Transaction ITI-83 of the IHE IT Infrastructure Technical Framework. Transaction ITI-83 is used by the FHIR Client Application and the PCR for this implementation.

Storyboard

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

This storyboard demonstrates querying the PCR to get all associated identifiers for a Client (i.e. patient).

Narrative Example

Christopher Clerk works at Good Health Hospital's Record Management Office. Christopher Clerk enters an identifier for Adam Everyman and initiates PIXm Query in his HIS system against the PCR in order to access to all of Adam’s medical records within the enterprise (i.e. within the EHR). The PIXm Query Response returns all the identifiers associated with Adam Everyman within the PCR.

Interaction Diagrams

The following diagram illustrates the high level interaction between a Patient Identifier Cross-reference Consumer and the PCR. The Cross-Identifier PIXm operation will use the following query and response interactions:

  • Get Corresponding Identifiers
  • Return Corresponding Identifiers

PIXmSmall

The interaction includes the following actors and roles:

Actor: FHIR Client Application, this is the actor for Patient Identiifer Cross-reference Consumer.

Role: Queries PCR for a list of corresponding patient identifiers, if any.

Actor: PCR, this is the actor of Patient Identifier Cross-reference Manager.

Role: Manages the cross-referencing of patient identifiers across Patient Identification Domains. Upon request it returns a list of corresponding patient identifiers, if any.

Patient Identifier Cross-reference for Mobile (PIXm) Query

Trigger Events

The FHIR Client Application's need for identifiers associated with a patient using the following query:

  • Get Corresponding Identifiers - This query is implemented as an HTTP GET operation from the FHIR Client Application to PCR using the FHIR $ihe-pix operation. Given that the parameters are not complex types, the HTTP GET operation shall be used as URL parameters when invoking the GET. The FHIR operation $ihe-pix is applied to the patient resource type. The FHIR Client Application executes the HTTP GET against the patient resource URL below:

    GET [base]/Patient/$ihe-pix?sourceIdentifier=[searchExpression]{&_format=[mime-type]}

    Alternatively, a POST based query may be used:

    POST [base]/Patient/$ihe-pix[?_format=mime-type] where the request body will be a name value pair like below:

    sourceIdentifier=system_url|id_value

    Note: for POST based search request, the Content-Type header value should be "application/x-www-form-urlencoded"

PCR's response to the Get Patient Identifiers query will trigger the following response:

  • Return Corresponding Identifiers - this response is implemented as a FHIR Parameters resource instance.

Summary of Supported Operations

The table below shows the allowed transactions for this PIXm profile and how it supports FHIR endpoints, resources and their corresponding HTTP operations (https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html):

Resource Transaction URL Request Body Resource Response Body Resource Notes
Patient Search GET|[base]/Patient/$ihe-pix?[searchExpression]e.g. GET [base]/Patient/$ihe-pix?sourceIdentifier=http://ehealthontario.ca/fhir/NamingSystem/id-sick-children-hospital-def-source|MRN12345 N/A Parameters Search expression is mandatory

Alternatively, a POST based query can be used

Resource Transaction URL Request Body Resource Response Body Notes
Patient Search POST|[base]/Patient/$ihe-pix[?_format=mime-type] No resource. The body is a string of name value pair in the form of sourceIdentifier=system_url|id_value Parameters The Content-type header field value should be "application/x-www-form-urlencoded"

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
search R R: Parameters N/A N/A 200,400,404,422,500

Expected Behavior

PCR returns Patient Identifiers associated with the identifier provided by the FHIR client application only when PCR recognizes the specified Patient Identification Domain, the Patient ID submitted and an identifier exists for the specified patient in at least one other patient identification domain. PCR shall return all known Patient Identifiers and Patient Resource References including the one identified by the sourceIdentifier parameter.

The information provided by PCR to FHIR Client Application is a list of cross-referenced identifiers. The list of cross-references is not made available until the set of policies and processes for managing the cross-reference function have been completed. The policies for administering identities adopted by the cooperating domains are completely internal to PCR as the Patient Identifier Cross-reference Manager. Possible matches are not communicated until the PCR reaches a positive matching decision.

The Patient Identifier Cross-reference Manager shall respond to the query request as described by the cases listed below:

Case Scenario Description Response Example
1 PCR recognizes the specified sourceIdentifier sent by the FHIR Client Application and corresponding identifiers exist in at least one other domain. HTTP 200 (OK) is returned as the HTTP status code. A Parameters Resource is returned representing the result set. Link
2 PCR recognizes the specified sourceIdentifier sent by the FHIR Client Application, but no identifier exists for that patient in any of the other domains. HTTP 200 (OK) is returned as the HTTP status code. A Parameters Resource is returned representing the result set with the empty search set. 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. Link
3 PCR cannot validate the request as it does not conform to the specification. HTTP 400(Bad Request) is returned as the HTTP status code. An OperationOutcome Resource is returned indicating an issue. The client must fix the request and try again. N/A
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. N/A
5 PIXm POST operation contains incorrect header value for "Content-Type" HTTP 400(Bad Request) is returned as HTTP status code. An OperationOutcome Resource is returned indicating the "Content-Type" header must be set to "application/x-www-form-urlencoded". The client must fix the request and try again. N/A
6 PCR has validated the request, but cannot return valid response (e.g. minimum of Patient ID + Name + Gender cannot be satisfied). HTTP 422 (Unprocessable Entity) is returned as the HTTP status code. An OperationOutcome Resource is returned indicating an issue. Client should contact eHealth Ontario for troubleshooting. N/A
7 PCR validates the request but cannot return valid response due to internal issue. HTTP 500 (Internal Server Error) is returned as the HTTP status code. An OperationOutcome Resource is returned indicating an issue. Client should contact eHealth Ontario for trouble shooting. N/A

Resource Profiles

This FHIR spec is based on IHE PIXm (ITI-83 - Patient Identifier Cross-reference for Mobile). It makes use of the following resource profiles:

PIXm Request

  • No Resource Profile. HTTP GET is used.

Or

  • If using POST based query, body should be a string that contains the sourceIdentifier value as below. Content-type header needs to be set to "application/x-www-form-urlencoded".

sourceIdentifier = system_url|id_value

PIXm Response

The PCR FHIR profiles are developed to constrain value sets and cardinality of data elements in the resources listed above.

Examples

Request example

Search for all matching patient identifiers for global identifier (e.g. Ontario Health Card Number (HCN)):

GET [base]/Patient/$ihe-pix?sourceIdentifier=http://ehealthontario.ca/fhir/NamingSystem/id-registration-and-claims-branch-def-source|1234567890

Or

POST [base]/Patient/$ihe-pix

Request Body: sourceIdentifier=http://ehealthontario.ca/fhir/NamingSystem/id-registration-and-claims-branch-def-source|1234567890

Response example

If no matching patient identifier is found. An operationOutcome will be returned in the Parameters resource. Example below