Patient Master Identity Registry (PMIR)
1.5.1-current - ci-build International flag

Patient Master Identity Registry (PMIR), published by IHE IT Infrastructure Technical Committee. This is not an authorized publication; it is the continuous build for version 1.5.1-current). This version is based on the current content of https://github.com/IHE/ITI.PMIR/ and changes regularly. See the Directory of published versions

1:49 Patient Master Identity Registry (PMIR) Profile

Official URL: https://profiles.ihe.net/ITI/PMIR/ImplementationGuide/ihe.iti.pmir Version: 1.5.1-current
Active as of 2023-02-10 Computable Name: IHE_ITI_PMIR

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.

This profile is intended for FHIR-only configurations without other underlying standards for patient master identity management. The FHIR message pattern was chosen because it fits well into the subscription notification model.

Organization of This Guide

This guide is organized into four main sections:

  1. Volume 1: Profiles
    1. PMIR Introduction
    2. PMIR Actors, Transactions, and Content Modules
    3. PMIR Actor Options
    4. PMIR Required Actor Groupings
    5. PMIR Overview
    6. PMIR Security Considerations
    7. PMIR Cross Profile Considerations
  2. Volume 2: Transaction Detail
    1. Mobile Patient Identity Feed [ITI-93]
    2. Subscribe to Patient Updates [ITI-94]
  3. Test Plan

  4. Changes to other Profiles

Click on any of the links above, navigate the contents using the table of contents, or if you are looking for a specific artifact, check out the artifacts.

Conformance Expectations

IHE uses the normative words: Shall, Should, and May according to standards conventions.

Must Support

The use of mustSupport in StructureDefinition profiles equivalent to the IHE use of R2 as defined in Appendix Z.

mustSupport of true - only has a meaning on items that are minimal cardinality of zero (0), and applies only to the source actor populating the data. The source actor shall populate the elements marked with MustSupport if the concept is supported by the actor, a value exists, and security and consent rules permit. The consuming actors should handle these elements being populated or being absent/empty. Note that sometimes mustSupport will appear on elements with a minimal cardinality greater than zero (0), this is due to inheritance from a less constrained profile.

Download

You can also download:

The source code for this Implementation Guide can be found on IHE GitHub.

Cross Version Analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (ihe.iti.pmir.r4) and R4B (ihe.iti.pmir.r4b) are available.

Dependency Table

IGPackageFHIRComment
.. Patient Master Identity Registry (PMIR)ihe.iti.pmir#1.5.1-currentR4
... HL7 Terminology (THO)hl7.terminology.r4#5.0.0R4Automatically added as a dependency - all IGs depend on HL7 Terminology
... Basic Audit Log Patterns (BALP)ihe.iti.balp#currentR4
.... HL7 Terminology (THO)hl7.terminology.r4#5.0.0R4

Package ihe.iti.balp#current

The Basic Audit Log Patterns (BALP) Implementation Guide is a Content Profile that defines some basic and reusable AuditEvent patterns. This includes basic audit log profiles for FHIR RESTful operations to be used when there is not a more specific audit event defined. A focus is enabling Privacy centric AuditEvent logs that hold well formed indication of the Patient when they are the subject of the activity being recorded in the log. Where a more specific audit event can be defined it should be derived off of these basic patterns. (built Wed, Feb 8, 2023 19:26+0000+00:00)

Globals Table

There are no Global profiles defined

IP Statements

This publication includes IP covered under the following statements.