Patient Master Identity Registry

Patient Master Identity Registry (Currently under implementation and should be available by the end of Q1 2020)

Note that the information on this page comes from the IHE Patient Master Identity Registry (PMIR) Rev. 1.1 - 2019-12-05 and in most cases the information is copied verbatim from the specification which can be found here.

The Patient Master Identity Registry (PMIR) Profile supports the creating, updating and deprecating of patient master identity information about a subject of care, as well as subscribing to changes to the patient master identity, using the HL7 FHIR standard resources and RESTful transactions. In PMIR, “patient identity” information includes all information found in the FHIR Patient Resource such as identifier, name, phone, gender, birth date, address, marital status, photo, others to contact, preference for language, general practitioner, and links to other instances of identities. The “patient master identity” is the dominant patient identity managed centrally among many participating organizations (a.k.a., “Golden Patient Identity”).

Beyond the basic create, retrieve, update, and delete transaction set, this profile addresses important patient safety issues related to cases where there are two or more patient master identities that have been established for the same person, thus it is not clear which identity is the “true” one. There is also a risk that health data (possibly conflicting) may be associated with each identity – and these disparate data, together, may need to be reconciled before a fully and accurate “health picture” can be developed for this person. These situations represent patient safety risks. This profile addresses how these multiple patient master identities can be merged into a single patient master identity, and how this merge flows down to data custodians so that they take appropriate actions. It is outside the scope of this profile to define how references to the deprecated patient master identity from other data should be handled.

The following table lists the transactions for each actor directly involved in the PMIR Profile. OpenEMPI plans to offer support for all required transactions of this profile.

Use Case #1: Lookup a patient master identity using PIXm or PDQm

When a patient master identity is needed, a client uses a PIXm or PDQm query to retrieve a patient master identity.

Use Case #2: Create Patient Identity

This use case covers the situation where a new record needs to be created in a database.

Use Case #3: Update Patient Identity

This use case covers the situation where an existing client record's identifier is updated in the database.

Use Case #4: Merge Patient Identities

This use case covers the situation where a duplicate patient record is detected for a patient. This duplicate patient record is merges with the pre-existing patient record.

Transactions

Mobile Patient Identity Feed [ITI-93]

In this transaction the supplier sends a bundle of updates using a FHIR message with the new and updated patient resource data. This transaction is triggered when patient records are created, updated, merged or deleted. The supplier initiates a FHIR message request using HTTP POST as defined in https://www.hl7.org/fhir/R4/messaging.html on a Bundle Resource. The supplier shall create a Bundle Resource of type "message" with the first entry being a MessageHeader Resource and the remaining entries being Patient Resources. The supplier shall be able to send a request for both the JSON and XML messaging formats as defined in FHIR. The consumer shall support accepting either the JSON or XML messaging formats as defined in FHIR depending on the subscription or configuration of the consumer. The following table shows the constraints on the Bundle Resource:

The following table shows the constraints on the MessageHeader Resource:

When a merge is needed, the Patient Resource to be deprecated shall be included and shall be constrained as described below and where the element column references the object model defined at http://www.hl7.org/fhir/R4/patient.html#resource.

When a patient needs to be associated to a related person (such as parents), the Patient Resource of the patient master record shall be constrained as described below.

The following is an example FHIR Bundle Excerpt for a Merge where Patient 123 is being replaced by Patient 456 and where no patient identity changes are made to the surviving patient identity.

{
	"resourceType": "Bundle",
	"type": "message",
	"entry": [{
		"resourceType": "MessageHeader",
		"eventUri": "urn:ihe:iti:pmir:2019:patient-feed",
		"focus": [{
			"reference": "Patient/123"
		}],
		"destination": [{
			"endpoint": "http://example.com/patientEndpoint"
		}]
	},
	{
		"resource": {
			"resourceType": "Patient",
			"id": "123",
			"active": false,
			"link": [{
				"other": {
					"reference": "Patient/456"
				},
				"type": "replaced-by"
			}]
		},
		"request": {
			"method": "PUT",
			"url": "Patient/123"
		}
	}]
} 

A Consumer shall accept the message and return a Mobile Patient Identity Feed Response message as shown further below. When the EMPI receives a merge request, it shall:

• Create: create a new patient record in the database
• Update: update the patient record in the database
• Delete:
• Merge: deprecate the patient record when the message includes a replaced-by link.type. The EMPI shall set the deprecated patient "active" to "false" and include a link with type set to "replaced-by" and "other" set to the surviving patient.
• Unmerge: not supported by this transaction so return a correlated entry.response.code = 405 when a link type of "replaced-by" is removed from a patient resource.

After a merge or delete operation a request to either retrieve or search for patient records shall return either the record with a state of inactive or the appropriate error message and this behavior shall be controlled by policy. When performing a GET on the deprecated or deleted record the response should be either:

• 200 OK and returns the deprecated record marked as inactive
• 404 not found

When performing a SEARCH by the deprecated or deleted record return:

• 200 OK Bundle with the inactive patient marked as inactive
• 200 OK Bundle with no patient resource
• If merged, 200 OK bundle with both the target and old patient resources

The response message is a Mobile Patient Identity Feed Request with an HTTP status of 2xx with a bundle resource with type set to "message" and one entry that is a MessageHeader that reports the outcome of processing the request or an error code, 4xx or 5xx. The EMPI shall return an entry for each resource in the request with an entry.response.status set depending on the processing of the Patient Resources based on the batch processing rules for FHIR: http://hkl7.org/fhir/http.html#brules. A status other than 2xx shall also include an OperationOutcome in error.response.outcome explaining the error.

Subscribe to Patient Updates [ITI-94]

The Subscribe to Patient Updates transaction allows a system to subscribe to a Mobile Patient Resource Feed [ITI-93] depending on the requested criteria,

The Patient Identity Subscriber shall create a Subscription Resource. The Subscription Resource shall be further constrained as described below.

The values for criteria enable Consumers to limit results based on what Patients they are concerned with. The subscriber shall support the ability to subscribe to the ITI-93 with at least one criteria. The PMIR shall support processing subscriptions with all criteria. The criteria list includes:

• Patient - to subscribe to all Patient updates
• Patient?_id=X - to subscribe to updates for a single Patient where X is the id of the Patient Resource
• Patient?organization=X - to subscribe to updates for Patients related to a single Organization
• Patient?identifier=X - to subscribe to updates for Patients based on their identifier. Since X is a token parameter type, a subscriber may limit by system, value or both

A Patient Identity Manager (PMI) shall accept the request, and return an HTTP 201 response when the Subscription is created or an error code with an OperationOutcome if an error occurs. A PMI shall store the subscription request and manage the subscription to enable the ITI-93. Once the subscription has been activated, the status shall be changed to "active". If an error occurs at any time with an active subscription, the PMI shall update the Subscription Resource and set the status to "error" and the error element with the error message. The subscriber may use the Get Patient Subscription Request to get the current status of the subscription.

The PMI shall send a response to the subscriber when the subscription request is received. The response shall include an HTTP status of 201 with the location header set to the created subscription resource or an error (see https://www.hl7.org/fhir/http.html#create).

A subscriber can retrieve from the PMI the current details of a subscription by accessing the Location returned by the subscribe to Patient Updates Response (see https://www.hl7.org/fhir/http.html#read). The subscriber can enable and disable a subscription on the PMI by accessing the Location and performing an update operation. The subscription can be disabled by changing the status to "off" or re-enable it by changing the status to "requested". The subscriber can delete a subscription by sending a delete request to the Location returned by the PMI.