Profiles & Operations > Cross-Identifier - 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.
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.
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:
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.
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:
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 |
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 |
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
Or
sourceIdentifier = system_url|id_value
PIXm Response
PIXm Response Parameters Profile (pcr-parameters-pixm-out)
PCR Operation Outcome Profile (pcr-operationoutcome)
The PCR FHIR profiles are developed to constrain value sets and cardinality of data elements in the resources listed above.
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
Powered by SIMPLIFIER.NET