These instructions apply to the Patient Identity Manager actor in the Patient Master Identity Registry (PMIR) Profile.  In this test, a PMIR Manager will load its database with Patient Resources formatted for [ITI-93] Mobile Patient Identity Feed, to support subscription tests during Connectathon.

Background Information:

Read this section for background information about test patients used for PMIR testing at the Connectathon. Otherwise, for instructions for loading test patients, skip to the Instructions below.


In a normal deployment, a product is operating in an environment with a policy for patient identity creation and sharing that remains stable.

However, at the Connectathon, we test multiple profiles (for patient management:  PIX, PDQ, PMIR...  for document sharing:  XDS, MHD...).   Thus, the Connectathon provides special challenges when requirements for actors differ across IHE Profiles.    Particularly relevant in PMIR and PIXm is the behavior of the server actor (PMIR Patient Identity Manager & PIXm Cross-Reference Manager.

A PIXm Patient Identifier Cross-Reference Manager:

Source of Patients in the PIXm Profile: There is no Patient Identity Feed transaction in PIXm. Somehow, in a method currently undefined by the profile, the PIX Manager has multiple patient records (e.g. via an HL7v2 or v3 Feed), and a single patient (person) might have several records on the PIX Manager server that are cross-referenced. 
At the Connectathon, we ask PIX Managers to load “Connectathon Patient Demographics” that are are provided via the Gazelle Patient Manager tool. (in HL7v2, v3 for FHIR Patient Resource format).  These Connectathon Patient Demographics contain four Patient records for each ‘patient’, each with identical demographics (name, address, DOB), but with a different Patient.identifier (with system values representing the IHERED, IHEGREEN, IHEBLUE, and IHEFACILITY assigning authority values).   We expect that the PIX Manager will cross-reference these multiple records for a single patient since the demographics are the same.

QUERY: When a PIXm Consumer sends a PIXm Query [ITI-83] to the PIXm Manager with a sourceIdentifier representing the assigning authority and patient ID (e.g. urn:oid:|IHEFACILITY-998), the PIXm Manager would respond with [0..*] targetId(s) which contain a Reference to a Patient Resource (one reference for each matching Patient Resource on the server).
At the Connectathon, if a PIXm Consumer queried by a Patient ID in the IHEFACILITY domain (above example), if there is a match, the PIXm Manager would return a response with three matches, one each for RED, GREEN, and BLUE, e.g.:

PIXm Response Example 

A PMIR Patient Identity Manager:

Source of Patients in the PMIR Profile: The PMIR Profile is intended for use in an environment where each patient has a single “Golden Patient record”. In PMIR, a patient has a single “Patient Master Identity” (a.k.a. Golden Patient record) that is comprised of identifying information, such as business identifiers, name, phone, gender, birth date, address, marital status, photo, contacts, preference for language, and links to other patient identities (e.g. a mother’s identity linked to a newborn).

The PMIR Patient Identity Source actor sends the Mobile Patient Identity Feed [ITI-93] transaction to the PMIR Patient Identity Manager to create, update, merge, and delete Patient Resources.  

The PMIR Manager persists one FHIR Patient Resource per patient. The PMIR Manager does not cross-reference multiple/separate records for a patient.   The PMIR Manager relies on the Patient Identity Source actor as the source of truth about new patient records (Patient Resources), and about updates/merges/deletes of existing patient records.
At the Connectathon, because some systems support PIX/PIXv3/PIXm and PMIR, we provide separate Patients (in [ITI-93] format) for PMIR testing with identifiers in a single assigning authority - urn:oid: (aka IHEGOLD). These patients are used only for PMIR tests; these patients have different demographics than the traditional red/green/blue Connectathon patients used for PIX, PDQ, XDS, and XCA.

QUERY: When a PIXm Consumer sends a PIXm Query [ITI-83] to the PMIR Manager with a sourceIdentifier representing the assigning authority and patient ID  (e.g. urn:oid:|IHEGOLD-555), if there is a match the PMIR Manager would return a response with the one (matching) Patient Reference. 

At the Connectathon, if a PIXm Consumer queried by a Patient ID in the GOLD domain, if there is a match, the PMIR Manager would return a response with a reference to one Patient Resource.


In conclusion, using the RED/GREEN/BLUE Patients for PIX* testing, and the GOLD Patients for PMIR testing enables us to separate expected results that differ depending on whether a server is a PIX* Patient Identifier Cross-reference Manager or a PMIR Patient Identity Manager in a given test.


In this test, the PMIR Patient Identity Manager loads a set of Patient Resources used in PMIR peer-to-peer subscription tests.  We use a set of FHIR Patient Resources) for PMIR testing that are different than the Connectathon patients for testing the PIX* & PDQ* Profiles.

The patient test data is a Bundle formatted according to the requirements for a Mobile Patient Identity Feed [ITI-93] transaction.

The PMIR Patient Identity Manager should follow these steps to load the patient test data:

  1. Find the test patients in IHE Google Drive
  2. Go to folder:  IHE Documents > Connectathon > test_data >ITI-profiles >PMIR-test-data
  3. Download this file:  001_PMIR_Bundle_POST-AlfaBravoCharlie-GOLD.xml   (we only provide the data in xml format)
    That .xml file is a Bundle formatted according to the requirements for ITI-93.
  4. POST that file to your PMIR Manager so that you are hosting the three Patient Resources within that file.
  5. Note that there are other files in that directory that you can download now, but do not POST them to your Manager until instructed to do so in the Subscription test during the Connectathon.  It is important to wait because posting them during the Connectathon will be a trigger for a subscription.


There is no log file associated with this 'test', so you do not need to upload pre-Connectathon results into Gazelle Test Management for this test.