Patient Identifier Cross Reference Management
Overview
Using the Founda Health Platform, healthcare providers and applications can exchange and cross-reference Patient Identifiers based on the IHE ITI PIXm Profile.
Actors
There are three actors in the PIXm profile:
- The Patient Identity Source is the publisher of the Patient Identifiers.
- Each may serve one or more Identifier Domains and using the Identifier Domains, the Patient Identity Source can populate the Patient Identifier Cross-reference Manager with Patient Identifiers.
- The Patient Identifier Cross-reference Consumer queries a Patient Identifier and receives a Patient Identifier along with its cross-references in return (if there are any).
- ο»ΏThe Patient Identifier Cross-reference Manager stores all of the Patient identifiers and cross-references of a patient within different Identifier Domains.ο»Ώ
Founda offers a secure and fast Patient Identifier Cross-reference Manager to help healthcare providers with their cross-referencing challenges. Depending on the use case, a Client may act as a Patient Identifier Cross-reference Consumer, Patient Identity Source, or both.
Supported Transactions
There are two transactions defined in the PIXm profile
- ITI-104: Patient Identity Source feeds the Patient Identifier Cross-reference Manager with Patient Identifiers and their cross-references.
- ITI-83: Patient Identifier Cross-reference Consumer queries previously-stored Patient Identifiers along with their cross-references.
Founda offers full support for these transactions through the Founda Health Platform.
Patient Identity Feed FHIR (ITI-104)
Within an ITI-104 transaction, there are four different types of operations. A Client can act as a Patient Identity Source to:
- Add a Patient Identifier
- Revise an existing Patient Identifier
- Resolve a duplicate Patient Identifier
- Remove a Patient Identifier
The base URL for all ITI-104 operations is: https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient
Note that a Client acting as a Patient Identity Source is required to provide the IHE ITI PIXm profile URL inside the body of the request.
An example of the profile URL in the request body:
Add/revise a Patient Identifier
The Patient Identifier Cross-reference Manager provided by Founda can differentiate between the add and revise operations. There is no need to specify any extra parameters.
Request
A Client initiates a PUT request to the endpoint https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient and provides a Patient FHIR resource as the body of the request. The Client is also required to supply a valid identifier inside the query parameters.
Note that, as defined by the PIXm profile, the identifier provided in the query parameter is the combination of an Identifier Domain and a Patient Identifier, represented as a single string and pipe-delimited |.
An example Patient payload:
The following Payload can be submitted to this example endpoint: https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient?identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED
ο»ΏNote that the Identifier Domains used in the request must be either managed by the Client or the Provider Organization (you can read more about this in the Security/Authorization section).
Response
Upon a successful request, Founda's Patient Identifier Cross-reference Manager will respond with a FHIR Patient resource and a 200 OK status code.
Resolve Duplicate Patient
A Client can notify Founda's Patient Identifier Cross-reference Manager that a duplicate Patient within the Patient Identity Source has been merged.
The Patient Identity Source is required to provide a link with a type of replaced-by inside the body of the request.
An example payload:
Founda's Patient Identifier Cross-reference Manager replaces the Patient Identifier and all of its internal references with the Patient Identifier provided in the replaced-by link.
Request
A Client initiates a PUT request to the endpoint https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient and sends a Patient FHIR resource as the body of the request, The Client is also required to supply a valid identifier inside the query parameters.
An example of the endpoint:
https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient?identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED
An example Patient payload:
Response
Upon a successful request, Founda Patient Identifier Cross-reference Manager will respond with a FHIR Patient resource and a 200 OK status code.
Remove a Patient Identifier
Founda's Patient Identifier Cross-reference Manager also supports the Remove Patient Option. A Client can request for a Patient Identifier and their references to be deleted.
Request
A Client initiates a DELETE request to the endpoint https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient and sends a valid identifier inside the query parameters.
An example of the endpoint will be: https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient?identifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED
Response
Upon a successful delete, Founda's Patient Identifier Cross-reference Manager will respond with an OperationOutcome and a 200 OK status code.
An example response:
Mobile Patient Identifier Cross-reference Query (ITI-83)
A Client acting as a Patient Identifier Cross-reference Consumer can query all of the cross-references a Patient Identifier has, optionally, The Client can also specify a target system to filter the result within that specific Identifier Domain.
The base URL for an ITI-83 operation is:
https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient/$ihe-pix
Request
A Client initiates a GET request to the endpoint https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient/$ihe-pix and passes the sourceIdentifier inside the query parameters.
As defined inside the PIXm profile, the sourceIdentifier is the combination of an Identifier Domain and a Patient Identifier, represented as a single string and separated by a pipe |.
An example of the endpoint: https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient/$ihe-pix?sourceIdentifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED
A Client can optionally pass an additional query parameter targetSystem to specify the target Identifier Domain.
An example of this: https://api.eu.founda.com/1/health/organizations/{organizationId}/fhir/4/Patient/$ihe-pix?sourceIdentifier=urn:oid:1.3.6.1.4.1.21367.13.20.1000|IHERED&targetSystem=urn:oid:1.3.6.1.4.1.21367.13.20.2000
Response
Founda's Patient Identifier Cross-reference Manager responds with a FHIR Patient resource and 200 OK status code or, in case of failure, an OperationOutcome with a description of the error will be returned.
An example Found - 200 response:
An example Found, replaced by another Patient Identifier - 200 response:
An example Not found - 404 response:
Security/Authorization
To fully understand how the authorization inside the Founda PIXm Manager works, there are a number of concepts to take into account.
- A Provider Organization (usually a healthcare provider, such as a Hospital) owns a Patient (Identifier) Registry in which all the Patient Identifiers and their references are stored. The Provider Organization is referred to as the Owning Organization.
- An Owning Organization is responsible for managing access within its Patient (Identity) Registry.
Patient Identifier Domains
Each Patient Identifier is stored along with its Identifier Domain, this combination is (and must be) universally unique.
A Client application acting as a PIXm Identity Source can only add, revise or replace Patient Identifiers in a Patient Registry for Identifier Domains the Owning Organization has authorized.
PIXm Consumers follow the same rule, and can only query Patient Identifiers in the identifier domains that the Owning Organization has authorized. This rule also applies to any of the references.
When these rules are not obeyed an operation can result in either an unauthorized response or the unauthorized data being omitted from the response.
Audit Events
Both transactions (ITI-104 and ITI-83) will result in an audit record that is submitted to the Audit Record Repository of the Founda Health Platform.
ITI-83 AuditEvent example:
ITI-104 AuditEvent example:
ο»Ώ
