appd4 Patient Topic
HL7 DSTU
HL7 PA, R2-2010
HL7 Version 3 Standard: Patient Administration, DSTU Release 2 Update
February 2010 Update to DSTU Release 2

Content Last Edited: 2011-06-17T13:44:56


Return to Domain Table of Contents

4.1  Introduction
4.2  Storyboards
4.3  Application Roles
4.4  Trigger Events
4.5  Refined Message Information Models
4.6  Hierarchical Message Descriptions
4.7  Interactions
 4.1Introduction
 4.1.1 Introduction & Scope

The Patient topic defines messages exchanged with Patient Registries. The Patient information model is not limited to persons; any type of living subject can be registered as a patient. The model includes full information about the living subject playing the role of patient. The model also includes relationships between the patient and healthcare providers who have primary care and/or preferred care responsibility for the patient.

This document includes message specifications for:

  • Notifications for state transitions of activated, revised, nullified, and obsolete (duplicates resolved)
  • Queries for Find Candidate, Get Demographics, and Get Identifiers
  • Requests for adding and revising records

Possible future work includes:

  • Notification messages for other state transitions such as suspended or terminated
  • Request an identifier
  • Representing patient information in structured document and service profile specifications

The Patient Administration Technical Committee invites implementers with additional requirements to submit content proposals for future releases of the standard.

 4.1.2 Changes From Previous Release

This DSTU update includes only technical corrections to the R2-2007 DSTU content. The Control Act wrappers for two interactions were changed. The Master File / Reg Notif. Control Act, Role Subject wrapper was replaced with the Master File / Reg Request Control Act, Role Subject wrapper. These interactions represent a registry rejecting a request so to conform to the Registration Request, Fulfillment, Notifications storyboard in the Master File - Registries topic, the reject response "contains the identification of the registration request being rejected."

  • PRPA_IN201313UV (Patient Registry Add Request Rejected)
  • PRPA_IN201316UV (Patient Registry Revise Request Rejected)
 4.1.3 Known Issues

The March 2007 Harmonization meeting approved a proposal to deprecate Person.livingArrangementCode attribute and instead convey such information as an Observation. That change is not included in this release.

4.2 Storyboards

Go To Top

► Storyboards (Sorted by Title)
▼ Storyboards (Sorted by Display Order)
 
pointer Patient Registry Record Added (PRPA_ST201301UV02) 
pointer Patient Registry Record Revised (PRPA_ST201302UV02) 
pointer Patient Registry Record Nullified (PRPA_ST201303UV02) 
pointer Patient Registry Duplicates Resolved (PRPA_ST201304UV02) 
pointer Patient Registry Find Candidates Query (PRPA_ST201305UV02) 
pointer Patient Registry Find Id Get Demographics Queries (PRPA_ST201317UV02) 
pointer Patient Registry Get Demographics Query (PRPA_ST201307UV02) 
pointer Patient Registry Get Identifiers Query (PRPA_ST201309UV02) 
pointer Patient Registry Add Request (PRPA_ST201311UV02) 
pointer Patient Registry Revise Request (PRPA_ST201314UV02) 
Reference

For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.

appd4.2.1 Patient Registry Record Added (PRPA_ST201301UV02)
Purpose
This storyboard demonstrates notifying tracking systems after a record is added to a patient registry.
Diagram
Activity Diagram
Interaction List
Patient Registry Record Added Schema View PRPA_IN201301UV02
4.2.1.1 Patient Registry Record Added (PRPA_SN201301UV02)
Narrative Example

Mr. Adam Everyman's physician, Dr. Patricia Primary, called the Good Health Hospital to schedule an inpatient visit for Mr. Everyman for lung surgery. The clerk verified that Mr. Everyman was not already registered as a patient in the GHH Patient Registry and created a new patient record for him [Patient Registry Record Added interaction] then scheduled the admission for two weeks from that day.

appd4.2.2 Patient Registry Record Revised (PRPA_ST201302UV02)
Purpose
This storyboard demonstrates notifying tracking systems after a record is revised in a patient registry.
Diagram
Activity Diagram
Interaction List
Patient Registry Record Revised Schema View PRPA_IN201302UV02
4.2.2.1 Patient Registry Record Revised (PRPA_SN210302UV02)
Narrative Example

Dr. Patricia Primary scheduled an inpatient admission to the Good Health Hospital for her patient Mr. Adam Everyman and the registration clerk added Mr. Everyman to the GHH Patient Registry. The next day the Good Health Hospital's registration clerk, Christopher, called Mr. Everyman to gather additional demographic information and Mr. Everyman's emergency contact and guarantor information [ Patient Registry Record Revised interaction].

appd4.2.3 Patient Registry Record Nullified (PRPA_ST201303UV02)
Purpose
This storyboard demonstrates notifying tracking systems after an erroneous record in a patient registry has been nullified. Note, addressing a duplicate record is described in Patient Registry Duplicates Resolved storyboard.
Diagram
Activity Diagram
Interaction List
Patient Registry Record Nullified Schema View PRPA_IN201303UV02
4.2.3.1 Patient Registry Record Nullified (PRPA_SN201303UV02)
Narrative Example

Good Health Hospital recently implemented an enterprise Patient Registry. The Registry was populated with patients extracted from GHH's existing systems. Shortly after the Registry began operation the record clerk, Christopher Clerk, found that an entry for the test patient "Patient Zztest" was mistakenly transferred to the enterprise Patient Registry. Christopher marked the record as "entered in error" and GHH patient tracker applications were sent a notification [Patient Registry Record Nullified interaction].

appd4.2.4 Patient Registry Duplicates Resolved (PRPA_ST201304UV02)
Purpose
This storyboard demonstrates notifying tracking systems after duplicate records are resolved in a patient registry. The incorrect registration is marked "obsolete" and linked to the surviving registration.
Diagram
Activity Diagram
Interaction List
Patient Registry Duplicates Resolved Schema View PRPA_IN201304UV02
4.2.4.1 Patient Registry Duplicates Resolved (PRPA_SN201304UV02)
Narrative Example

During the patient admission process, the registrar did not find a record for Eve Everywoman in the ADT system and created a new record with identifier ID2. Eve Everywoman had actually been to the healthcare facility several times in the past under her maiden name, Eve Everymaiden, with identifier ID1. The problem persists for a while. During that time, several more encounters are assigned to Eve under her newly created identifier ID2. Finally, the problem is discovered and Medical Records sets the registration for Eve Everymaiden to "obsolete" and links it to the newer registration for Eve Everywoman [Patient Registry Duplicates Resolved interaction].

appd4.2.5 Patient Registry Find Candidates Query (PRPA_ST201305UV02)
Purpose
This storyboard demonstrates querying a patient registry for a list of patients matching a set of demographic information.
Diagram
Activity Diagram
Interaction List
Patient Registry Find Candidates Query Schema View PRPA_IN201305UV02
Patient Registry Find Candidates Query Response Schema View PRPA_IN201306UV02
4.2.5.1 Patient Registry Find Multiple Candidates Query (PRPA_SN201305UV02)
Narrative Example

Dr. Patricia Primary is driving to work and witnesses a road traffic accident. One casualty is unconscious but Dr. Primary recognizes him as Mr. Everyman who came to see her last month. Dr. Primary assists the paramedics and provides as many demographic details for Mr. Everyman as she can remember.

At A&E Connor Comrade the receptionist initiates a Patient Registry Find Candidates Query for Mr. Everyman using sex, date of birth range and family name and initial and GP code provided by Dr. Primary.

Connor Comrade receives back a Patient Registry Find Candidates Query Response containing two matches to his Patient Registry Find Candidates Query for Mr. Everyman. Both records contain Registry ID number, name, sex, date of birth and current GP but one record also contains a date of death. Connor is looking at the record for the live patient when one of the paramedics comes past with the news that Mr. Everyman has come around and given his date of birth. Connor checks that the record he is viewing matches Mr. Everyman's date of birth and selects it.

4.2.5.2 Patient Registry Find Single Candidate Query (PRPA_SN201306UV02)
Narrative Example

Adam Everyman has a consultation with Dr. Fay Family today to discuss the likelihood that he has inherited Parkinson's disease. Adam's father died last year so Adam gives his permission for Dr. Family to look at his father John's records. Dr. Family enters John's name, sex, date of birth, date of death and postal code onto the system and performs a Patient Registry Find Candidates Query.

Dr. Family's search for Adam's father, John, is successful and only one match is found. A Patient Registry Find Candidates Query Response returns the Registry ID number, usual address, telephone numbers, current usual name, sex, date of birth, date of death, status of death notification and GP. She then uses this information to access John's records to see if any there is any clinical information relating to Parkinson's disease

.
appd4.2.6 Patient Registry Find Id Get Demographics Queries (PRPA_ST201317UV02)
Purpose
This storyboard demonstrates querying a patient registry for patient demographics after first doing a find candidates query to get the identifier for the patient.
Diagram
Activity Diagram
Interaction List
Patient Registry Find Candidates Query Schema View PRPA_IN201305UV02
Patient Registry Find Candidates Query Response Schema View PRPA_IN201306UV02
Patient Registry Get Demographics Query Schema View PRPA_IN201307UV02
Patient Registry Get Demographics Query Response Schema View PRPA_IN201308UV02
4.2.6.1 Patient Registry Find Id Get Demographics Queries (PRPA_SN201317UV02)
Narrative Example

Connor Comrade receives notification from Dr Patrick Pump that a patient, Ann Terminal, has died in the hospital. Connor performs a Patient Registry Find Candidates Query for Ann Terminal and selects her patient identifier from the Patient Registry Find Candidates Query Response. He uses Ann's patient identifier in a Patient Registry Get Demographics Query. Connor receives the Patient Registry Get Demographics Query Response and from this he can see that the Date of Death has already been updated on the patient registry.

appd4.2.7 Patient Registry Get Demographics Query (PRPA_ST201307UV02)
Purpose
This storyboard demonstrates querying a patient registry to get demographic information for a registered patient.
Diagram
Activity Diagram
Interaction List
Patient Registry Get Demographics Query Schema View PRPA_IN201307UV02
Patient Registry Get Demographics Query Response Schema View PRPA_IN201308UV02
4.2.7.1 Patient Registry Get Demographics Query (PRPA_SN201307UV02)
Narrative Example
Connor Comrade has a list of patients who need to be invited for follow up to Dr Patricia Primary's clinic. He sets up a list of Registry ID numbers and requests a Patient Registry Get Demographics Query for each number. Connor checks the details returned in the Patient Registry Get Demographics Query Response to make sure the patients are still alive. Where a date of death and a death status has been returned, Connor makes a note to follow these up later. For all the other patients, Connor uses the details returned in the Patient Registry Get Demographics Response messages to set up a mail merge file. Connor then uses this mail merge file to issue an invitation letter to each patient for the clinic
appd4.2.8 Patient Registry Get Identifiers Query (PRPA_ST201309UV02)
Purpose
This storyboard demonstrates querying a patient registry to get all identifiers for a registered patient.
Diagram
Activity Diagram
Interaction List
Patient Registry Get Identifiers Query Schema View PRPA_IN201309UV02
Patient Registry Get Identifiers Query Response Schema View PRPA_IN201310UV02
4.2.8.1 Patient Registry Get Identifiers Query (PRPA_SN201309UV02)
Narrative Example

An enterprise registry will often store multiple system identifiers to allow consistent identification of a patient across the enterprise.

Christopher Clerk works at Good Health Hospital's Record Management Office. The patient registry that is in place in the Records Management office associates all the identifiers for the patient in order to allow access to all the medical records within the enterprise for the patient.

Christopher Clerk enters an identifier for Adam Everyman and initiates a Patient Registry Get Identifiers Query to the Good Health Hospital Patient Registry. The Patient Registry Get Identifiers Query Response returns all identifiers associated with Adam Everyman within the patient registry system.

appd4.2.9 Patient Registry Add Request (PRPA_ST201311UV02)
Purpose
This storyboard demonstrates a local patient registry sending a request to an enterprise (or national or regional) patient registry to add a new record to the enterprise patient registry. The enterprise patient registry system will respond with a confirmation and the enterprise identifier for the new patient record, or it will respond with a rejection and the reason for the rejection.
Diagram
Activity Diagram
Interaction List
Patient Registry Add Request Schema View PRPA_IN201311UV02
Patient Registry Add Request Accepted Schema View PRPA_IN201312UV02
Patient Registry Add Request Rejected Schema View PRPA_IN201313UV02
4.2.9.1 Patient Registry Add Request Accepted (PRPA_SN201312UV02)
Narrative Example
Eve Everywoman has moved out from her parent's house in Scotland to a new apartment in London and soon after visits her local GP clinic to register for services. She has enjoyed good health and has not visited her previous GP for many years. Connor Comrade who is working on reception attempts several Patient Registry Find Candidates Querys but as he can find no previous record he decides to request a new Patient Registry ID number. He carefully completes the on screen record detailing Eve's full name, address, date of birth, sex and telephone number as well as the GP practice number. This is transmitted to the Patient Registry as a Patient Registry Add Request and a Registry ID number is allocated and returned via a Patient Registry Add Request Accepted.
4.2.9.2 Patient Registry Add Request Rejected (PRPA_SN201313UV02)
Narrative Example
Eve Everywoman has moved out from her parent's house in Scotland to a new apartment in London and soon after visits a local GP clinic to register for services. She has enjoyed good health and has not visited her previous GP for many years. Connor Comrade who is working on reception attempts a Patient Registry Find Candidates Query several times but as he can find no previous record he decides to request a new Patient Registry ID number. He completes the on screen record detailing Eve's full name, date of birth, sex and telephone number as well as the GP practice number. This is transmitted to the Patient Registry as a Patient Registry Add Request. Unfortunately Connor omits to enter either a permanent or temporary address in the request and as this is a mandatory item the Patient Registry responds with an Patient Registry Add Request Rejected with the reason for the rejection returned as a Detected Issue in the Master File / Registry Query Response, Role Subject wrapper.
appd4.2.10 Patient Registry Revise Request (PRPA_ST201314UV02)
Purpose
This storyboard demonstrates a local patient registry sending a request to an enterprise (or national or regional) patient registry to revise information for a record in the enterprise patient registry. The enterprise patient registry system will respond with a confirmation of the information update, or it will respond with a rejection and the reason for the rejection.
Diagram
Activity Diagram
Interaction List
Patient Registry Revise Request Schema View PRPA_IN201314UV02
Patient Registry Revise Request Accepted Schema View PRPA_IN201315UV02
Patient Registry Revise Request Rejected Schema View PRPA_IN201316UV02
4.2.10.1 Patient Registry Revise Request Accepted (PRPA_SN201315UV02)
Narrative Example
A GP at the Good Health Medical Center, Dr Patricia Primary, is called out to see one of her patients, Mr. Neville Nuclear, by his wife Nancy. Neville has been suffering from carcinoma of the lung and despite chemotherapy his health has continued to decline. After examining Neville carefully, Patricia pronounces him as dead. She completes a death certificate for the family and after helping the family make arrangements Patricia returns to the clinic. She updates Neville's Patient Registry record using the Patient Registry Revise Request including the date and time of death. The Patient Registry responds with a Patient Registry Revise Request Accepted indicating that the update was performed successfully within the Patient Registry.
4.2.10.2 Patient Registry Revise Request Rejected (PRPA_SN201316UV02)
Narrative Example
Eve Everywoman registered for national health services some time ago. She works as an actress, has recently been in a very successful film and as a result she is now a well known celebrity. On the advice of her legal advisors she writes to her local clinic requesting that her records are updated. She asks that her stage name of Sarah Showtime and her move to Marilyn Mansions are noted. The Records Supervisor at the clinic, Connor Comrade, performs a Patient Registry Revise Request supplying Eve's alias name and new address with a date effective taken from the letter. Unfortunately the date on the letter is the 30th of February so the Patient Registry responds with a Patient Registry Revise Request Rejected with the reason for the rejection returned as a Detected Issue in the Master File / Registry Query Response, Role Subject wrapper.
4.3 Application Roles

Go To Top

► Application Roles (Sorted by Artifact Code)
▼ Application Roles (Sorted by Display Order)
 
pointer Patient Registry Revision Tracker (PRPA_AR201307UV02) 
pointer Patient Registry Request Placer (PRPA_AR201305UV02) 
pointer Patient Registry Request Fulfiller (PRPA_AR201306UV02) 
pointer Patient Registry Informer (PRPA_AR201301UV02) 
pointer Patient Registry Tracker (PRPA_AR201302UV02) 
pointer Patient Registry Query Placer (PRPA_AR201303UV02) 
pointer Patient Registry Query Fulfiller (PRPA_AR201304UV02) 
Reference

For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.

appd4.3.1 Patient Registry Revision Tracker (PRPA_AR201307UV02)
Description View Interactions

This application role is responsible for receiving a single interaction -- notification that a record in a patient registry has been revised. The application role was singled out to support systems such as lab systems that only need to track changes in patient information.

appd4.3.2 Patient Registry Request Placer (PRPA_AR201305UV02)
Description View Interactions

This application role represents applications that initiate state transition requests to patient registries.

appd4.3.3 Patient Registry Request Fulfiller (PRPA_AR201306UV02)
Description View Interactions

This application role represents the responsibility of patient registries to respond to state transition requests.

appd4.3.4 Patient Registry Informer (PRPA_AR201301UV02)
Description View Interactions

This application role represents the responsibility of patient registries to notify systems of state transitions (such as add, revise, nullify) on records it holds.

appd4.3.5 Patient Registry Tracker (PRPA_AR201302UV02)
Description View Interactions

This application role represents the responsibility to receive state transition notification messages from patient registries.

appd4.3.6 Patient Registry Query Placer (PRPA_AR201303UV02)
Description View Interactions

This application role represents applications that initiate queries to patient registries.

appd4.3.7 Patient Registry Query Fulfiller (PRPA_AR201304UV02)
Description View Interactions

This application role represents the responsibility of patient registries to respond to queries.

4.4 Trigger Events

Go To Top

► Trigger Events (Sorted by Title)
▼ Trigger Events (Sorted by Display Order)
 
pointer Patient Registry Record Added (PRPA_TE201301UV02) 
pointer Patient Registry Add Request (PRPA_TE201311UV02) 
pointer Patient Registry Add Request Accepted (PRPA_TE201312UV02) 
pointer Patient Registry Add Request Rejected (PRPA_TE201313UV02) 
pointer Patient Registry Record Revised (PRPA_TE201302UV02) 
pointer Patient Registry Revise Request (PRPA_TE201314UV02) 
pointer Patient Registry Revise Request Accepted (PRPA_TE201315UV02) 
pointer Patient Registry Revise Request Rejected (PRPA_TE201316UV02) 
pointer Patient Registry Record Nullified (PRPA_TE201303UV02) 
pointer Patient Registry Duplicates Resolved (PRPA_TE201304UV02) 
pointer Patient Registry Find Candidates Query (PRPA_TE201305UV02) 
pointer Patient Registry Find Candidates Query Response (PRPA_TE201306UV02) 
pointer Patient Registry Get Demographics Query (PRPA_TE201307UV02) 
pointer Patient Registry Get Demographics Query Response (PRPA_TE201308UV02) 
pointer Patient Registry Get Identifiers Query (PRPA_TE201309UV02) 
pointer Patient Registry Get Identifiers Query Response (PRPA_TE201310UV02) 
Reference

For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.

appd4.4.1 Patient Registry Record Added (PRPA_TE201301UV02)
Description View Interactions
Type:  State-transition based
State Transition:  RegistrationEvent (MFMI_RM700700UV01)

This trigger event signals that a record was added to a patient registry.

appd4.4.2 Patient Registry Add Request (PRPA_TE201311UV02)
Description View Interactions
Type:  User request

A source system sends a patient record to a patient registry with a request to add the record to the registry.

appd4.4.3 Patient Registry Add Request Accepted (PRPA_TE201312UV02)
Description View Interactions
Type:  Interaction based

This trigger event signals that a patient registry has accepted a request to add a new record.

appd4.4.4 Patient Registry Add Request Rejected (PRPA_TE201313UV02)
Description View Interactions
Type:  Interaction based

This trigger event signals that a patient registry has rejected a request to add a new record.

appd4.4.5 Patient Registry Record Revised (PRPA_TE201302UV02)
Description View Interactions
Type:  State-transition based
State Transition:  RegistrationEvent (MFMI_RM700700UV01)

This trigger event signals that a record was revised in a patient registry.

appd4.4.6 Patient Registry Revise Request (PRPA_TE201314UV02)
Description View Interactions
Type:  User request

A source system sends a request to a patient registry to make specific changes to the information it holds for a specified patient.

appd4.4.7 Patient Registry Revise Request Accepted (PRPA_TE201315UV02)
Description View Interactions
Type:  Interaction based

This trigger event signals that a patient registry has accepted a request to revise information it holds for a specified patient.

appd4.4.8 Patient Registry Revise Request Rejected (PRPA_TE201316UV02)
Description View Interactions
Type:  Interaction based

This trigger event signals that a patient registry has rejected a request to revise information it holds about a patient.

appd4.4.9 Patient Registry Record Nullified (PRPA_TE201303UV02)
Description View Interactions
Type:  State-transition based
State Transition:  RegistrationEvent (MFMI_RM700700UV01)

This trigger event signals that a record was nullified in a patient registry.

appd4.4.10 Patient Registry Duplicates Resolved (PRPA_TE201304UV02)
Description View Interactions
Type:  State-transition based
State Transition:  PriorRegistration (MFMI_RM700700UV01)

This trigger event signals that duplicate records were resolved in a patient registry.

appd4.4.11 Patient Registry Find Candidates Query (PRPA_TE201305UV02)
Description View Interactions
Type:  User request

A user initiates a query to a patient registry requesting patient records that match a set of demographic information.

appd4.4.12 Patient Registry Find Candidates Query Response (PRPA_TE201306UV02)
Description View Interactions
Type:  Interaction based

A patient registry responds to a Find Candidates Query request by returning patient records that match a set of demographic information sent in the query. Each returned record includes an observation reporting how well it matched the query parameters.

appd4.4.13 Patient Registry Get Demographics Query (PRPA_TE201307UV02)
Description View Interactions
Type:  User request

A user initiates a query to a patient registry requesting the demographic information it has stored for a given patient.

appd4.4.14 Patient Registry Get Demographics Query Response (PRPA_TE201308UV02)
Description View Interactions
Type:  Interaction based

A patient registry responds to a Get Patient Demographics Query request by returning the demographic information it has stored for the patient specified in the query.

appd4.4.15 Patient Registry Get Identifiers Query (PRPA_TE201309UV02)
Description View Interactions
Type:  User request

A user initiates a query to a patient registry requesting the identifiers it has stored for a given patient.

appd4.4.16 Patient Registry Get Identifiers Query Response (PRPA_TE201310UV02)
Description View Interactions
Type:  Interaction based

A patient registry responds to a Get Associated Identifiers Query request by returning the identifiers it has stored for the patient specified in the query.

4.5 Refined Message Information Models

Go To Top

► Refined Message Information Models (Sorted by Title)
▼ Refined Message Information Models (Sorted by Display Order)
 
pointer Patient Activate (PRPA_RM201301UV02) 
pointer Patient Revise (PRPA_RM201302UV02) 
pointer Patient Nullify (PRPA_RM201305UV02) 
pointer Patient Demographics (PRPA_RM201303UV02) 
pointer Patient Registry Find Candidates Response (PRPA_RM201310UV02) 
pointer Patient Identifiers (PRPA_RM201304UV02) 
pointer Patient Registry Query By Demographics (PRPA_RM201306UV02) 
pointer Patient Registry Query By Identifier (PRPA_RM201307UV02) 
Reference

For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.

appd4.5.1 Patient Activate (PRPA_RM201301UV02)
Diagram
T-PRPA_RM201301UV.png
Parent:  Patient Administration (PRPA_DM000000UV)
Description

Overview

The Patient Activate R-MIM defines the payload for messages used for state-transition requests and notifications for adding new records to a patient registry.

Walk-through

Patient

The Patient class is the entry point to the R-MIM and contains one or more identifiers (for example, an "internal" id used only by computer systems and an "external" id for display to users) for the focal subject (either person or non-person living subject) playing the role of patient in the Patient Registry. It also contains the address and telephone number for the focal subject in their role as patient. This is the information the providerOrganization uses to communicate with the patient. The effectiveTime specifies the time interval during which this record is in effect; an active record with have no ending time. The statusCode is fixed as "active" in the Patient Activate message.

AdministrativeObservation

The AdministrativeObservation class contains administrative information about the patient that cannot be conveyed by other classes and attributes in the model. Examples of administrative observations are Preferred Contact Method, Preferred Contact Times, Preferred Written Communication Format. The mandatorycode attribute characterizes the type of administrative observation performed and the mandatory value attribute contains the result of the observation.

coveredPartyOf

A patient may be the coveredPartyOf one or more insurance policies, each conveyed in an A_Coverage CMET. If a patient has more than one insurance policy the sequenceNumber attribute can convey a coordination of benefits sequence for insurance claims. Note the constraint that the CoveredPartyPerson or CoveredPartyAnimal within the CMET must be the same Person or NonPersonLivingSubject playing the role of Patient.

EntityChoiceSubject

The EntityChoiceSubject box defines identifying and demographic data elements similar to those in the HL7 v2.x PID segment. An actual HL7 v3 message must implement either Person or NonPersonLivingSubject. Person excludes data elements that only apply to veterinary subjects, such as strainText and handlingCode. NonPersonLivingSubject excludes data elements that only apply to persons such as maritalStatusCode and educationLevelCode. For Person the name attribute is required with a minimum cardinality of 1, meaning the attribute must be valued or contain an appropriate null flavor such as "temporarily unavailable", "not asked", "masked."

OtherIDs

Identifiers used for the focal patient by other registries are sent in the OtherIDs class; this could even be an identifier used by the scoping organization of this Patient Registry but in a different context. The scoping organization for this identifier is sent in a required E_Organization [identified/confirmable] CMET.

Citizen

Citizenship information for a person, including citizen identifier and effective time can be sent in the Citizen class. The nation that scopes the Citizen role, as identified by Nation.code, is mandatory.

BirthPlace

The patient's place of birth can be sent in a BirthPlace class. The BirthPlace.addris a physical address (address use = "PHYS") and could be a full address or only known address components such as city or country. The BirthPlace.addr must be non-null if the E_Place.name is null. The geographic coordinates of the BirthPlace can be conveyed in an A_SpatialCoordinate observation.

Employee

Employee information for a patient, including employee identifier and work address and telephone number, can be sent in an Employee class. The statusCode and effectiveTime attributes can differentiate between current and former employee relationships. Send an Employee with negationInd "true" and an employerOrganization of "not applicable" null flavor to convey that the patient is not employed.

Student

Information for students, including student identifier and a boarding student's address and telephone, can be sent in a Student class. The statusCode and effectiveTime attributes can differentiate between current and former student relationships.

PersonalRelationship

Associations between the patient and another living subject, such as spouse or parent, can be sent in a PersonalRelationship class. The exact nature of an association is described by the code attribute with a value drawn from the PersonalRelationshipRoleType domain. The statusCode and effectiveTime attributes can differentiate between current and former personal relationships, for example, a former spouse. Most associations can be represented in either of two ways depending on who is the player and who is the scoper. For example, the association between a father and his daughter can be represented by a code of "father" where the parent is the player and the child is the scoper, or by a code of "daughter" where the child is the player and the parent is the scoper. Send a PersonalRelationship with negationInd "true" and a relationshipHolder of "not applicable" null flavor to convey that the patient does not have a personal relationship of the type characterized by the code attribute.

CareGiver

A person (playing entity) responsible for the primary care of the patient (scoping entity) at home. The statusCode and effectiveTime attributes can differentiate between current and former caregiver relationships.

Member

Membership of the patient in a group can be sent in the Member class. The statusCode and effectiveTime attributes can characterize the current status of the patient's membership relationship. The group of which the patient is a member can be further characterized by the Group.code attribute, for example "religious organization."

ContactParty

A person or organization that provides or receives information regarding the patient is sent in the ContactParty class. The type of contact is determined by a code from the ContactRoleType domain. The current values are "next of kin" and "emergency contact". The telecom attribute is required and mandatory. The statusCode and effectiveTime attributes can differentiate between current and former contacts. If the relationship (e.g., parent, spouse, unrelated friend) of the contact to the patient is of interest then a PersonalRelationship with the same living subjects as player and scoper should also be sent. Send a ContactParty with negationInd "true" and a contactEntityChoice of "not applicable" null flavor to convey that the patient does not have a contact party of the type characterized by the code attribute.

Guardian

The Guardian class can send the person or organization (player) that is legally responsible for the care and management of the patient (scoper). The statusCode and effectiveTime attributes can differentiate between current and former guardian relationships. A facsimile of the legal document establishing guardianship could be sent in the certificateText attribute. If the relationship (e.g., parent, spouse, unrelated friend) of the guardian to the patient is of interest then a PersonalRelationship with the same living subjects as player and scoper should also be sent. Send a Guardian with negationInd "true" and a guardianEntityChoice of "not applicable" null flavor to convey that the patient does not have a guardian.

Guarantor

A person or organization that serves as financial guarantor for the patient is sent in an R_Guarantor CMET. If the relationship (e.g., parent, spouse, unrelated friend) of the guarantor to the patient is of interest then a PersonalRelationship with the same player and scoper should also be sent.

LanguageCommunication

Information about what language(s) should be used to communicate with the patient can be sent in the LanguageCommunication class.

Primary Care Provider Relationships

A patient may have one or more primary care and/or preferred providers (PCP) that are relevant from an administrative point of view. Each of these is sent in an A_PrinicpalCareProvision CMET linked to the living subject who plays the role of PatientOfOtherProvider that is the subjectOf the care provision act.

Contained Hierarchical Message Descriptions
Patient Activate PRPA_HD201301UV02
appd4.5.2 Patient Revise (PRPA_RM201302UV02)
Diagram
T-PRPA_RM201302UV.png
Parent:  Patient Administration (PRPA_DM000000UV)
Description

Overview

The Patient Revise R-MIM defines the payload messaged used for state-transition requests and notifications for revising records in patient registry.

Walk-through

The Patient Revise R-MIM differs from the Patient Activate R-MIM in the following ways:

  • Patient - the statusCode attribute can take on any of RoleStatusNormal values (excludes nullify) instead the fixed value of "active"
  • The providerOrganization association from Patient has a lower multiplicity of 0 instead of 1 since the receiver may already know the identity of the registry
  • Update Mode - the revise message implements update mode to convey changes and the R-MIM specifies allowed update modes for certain attributes and associations. All other attributes and associations can take on any normally allowed update mode.
Contained Hierarchical Message Descriptions
Patient Revise PRPA_HD201302UV02
appd4.5.3 Patient Nullify (PRPA_RM201305UV02)
Diagram
T-PRPA_RM201305UV.png
Parent:  Patient Administration (PRPA_DM000000UV)
Description

Overview

The Patient Nullified R-MIM defines the payload for a state-transition notification after a record in a patient registry has been nullified.

Walk-through

Patient

  • Mandatory id
  • Mandatory statusCode with fixed value of "nullified"
  • Non-mandatory providerOrganization association

EntityChoiceSubject

  • Person
    • Optional id
    • Required name
    • Optional administrativeGenderCode
    • Optional birthTime
    • Optional association to BirthPlace
  • NonPersonLivingSubject
    • Optional id
    • Optional code
    • Optional name
    • Optional administrativeGenderCode
    • Optional birthTime
    • Optional association to BirthPlace
Contained Hierarchical Message Descriptions
Patient Nullify PRPA_HD201305UV02
appd4.5.4 Patient Demographics (PRPA_RM201303UV02)
Diagram
T-PRPA_RM201303UV.png
Parent:  Patient Administration (PRPA_DM000000UV)
Description

Overview

The Patient Demographics R-MIM defines the payload message used for query responses that return a complete or partial record from a patient registry.

Walk-through

The Patient Demographics R-MIM differs from the Patient Activate R-MIM in the following ways:

  • Patient - the statusCode attribute can take on any RoleStatus values instead of the fixed value of "active"
  • The providerOrganization association from Patient has a lower multiplicity of 0 instead of 1 since receiver may already know the identity of the registry
Contained Hierarchical Message Descriptions
Patient Demographics PRPA_HD201303UV02
appd4.5.5 Patient Registry Find Candidates Response (PRPA_RM201310UV02)
Diagram
T-PRPA_RM201310UV.png
Parent:  Patient Administration (PRPA_DM000000UV)
Description

Overview

The Patient Registry Find Candidates Response R-MIM defines the payload message used to return records from a patient registry in response to a find candidates query. Each record includes an observation reporting how well the record matched the query parameters.

Walk-through

The Patient Registry Find Candidates Response R-MIM is the same as the Patient Demographics R-MIM with the addition of the QueryMatchObservation class.

Contained Hierarchical Message Descriptions
Patient Registry Find Candidates Response PRPA_HD201310UV02
appd4.5.6 Patient Identifiers (PRPA_RM201304UV02)
Diagram
T-PRPA_RM201304UV.png
Parent:  Patient Administration (PRPA_DM000000UV)
Description

Overview

The Patient Identifiers R-MIM defines the payload message used to return all identifiers associated with a record in a patient registry.

Walk-through

The Patient Identifiers R-MIM is a reduced version of the Patient Demographics R-MIM with the following changes:

Patient

  • Remove addr, telecom, confidentialityCode, and veryImportantPersonCode attributes
  • Remove the administrativeObservation association

EntityChoiceSubject

  • Remove all attributes except id and name
  • The Person.name attribute is required with a minimum cardinality of 1.
  • Remove birthPlace and R_Guarantor associations
  • Remove the asPatientOfOtherProvider association to A_PrincipalCareProvision CMET because this identifies a principal care provision act or heath care provider rather than the patient
  • Remove languageCommunication association from Person

Associated Roles

  • The id attributes are Mandatory. If the registry has no identifier for a role then the role shall not be sent.
  • Remove CareGiver, ContactParty, Guardian, and PersonalRelationship roles because the patient scopes the roles
  • Remove addr and telecom attributes
  • Remove jobTitleName, jobClassName, and occupation code attributes from Employee
  • Remove existenceTime attribute from Group
Contained Hierarchical Message Descriptions
Patient Identifiers PRPA_HD201304UV02
appd4.5.7 Patient Registry Query By Demographics (PRPA_RM201306UV02)
Diagram
T-PRPA_RM201306UV.png
Parent:  Patient Administration (PRPA_DM000000UV)
Description

Overview

The Patient Registry Query By Demographics R-MIM defines the payload for a query-by-parameter message sent to a Patient Registry when the query placer knows a set of patient demographics.

The response to a Query By Demographics may potentially return many records so the SortControl class and the responseModalityCode, initalQuantity and initialQuantityCode attributes of the QueryByParameter class are included in the information model.

Walk-through

QueryByParameter - The entry point to the R-MIM. This class allows the query requester to specify how the query should be processed by the query fulfiller.

  • queryId - Identifier for the query. It is used to associate this query instance with both the initial response message and with later query interactions. Valuing queryId avoids the need for the QueryContinuation and QueryAck classes to carry as much detail information as is carried in the initial query.
  • statusCode - A value specifying the state of this query (based on the RIM Act class state machine), for example, active, aborted, completed.
  • modifyCode - Indicates whether the subscription to a query is new or is being modified
  • responseElementGroupId - Identifies the specific message type to be returned in the query response. The message type is constrained to the set of message types supported by the receiver responsibilities associated with the query interaction.
  • responseModalityCode - Defines the timing and grouping of the response instances
  • responsePriorityCode - Identifies the time frame in which a response is expected
  • initialQuantity - Defines the maximum size of the response that can be accepted by the requesting application.
  • initialQuantityCode - Defines the units associated with the initialQuantity
  • executionAndDeliveryTime - Specifies the time the response is to be returned

SortControl - This class allows the query requester to specify the order in which the server should return multiple results.

  • sequenceNumber - Specifies the order of this elementName in the sort
  • elementName - Identifies the element upon which the response should be sorted
  • directionCode - Specifies sort order (ascending, descending or none)

MatchCriterionList - This collection of parameter items convey instructions to the query fulfiller. The associated parameter items are joined with OR logic.

  • MatchAlgorithm - This parameter conveys instructions to the query fulfiller specifying the preferred matching algorithm to use
  • MinimumDegreeMatch - This parameter conveys instructions to the query fulfiller specifying the minimum degree of match to use in filtering results
  • MatchWeight - This parameter conveys instructions to the query fulfiller specifying the desired weight to be assigned to parameter types in the matching process

ParameterList - This collection of parameter items for the query, similar to the WHERE clause in a SQL query. A query message can include any combination of the parameters. Multiple instances of parameter item are combined with AND logic. Multiple values in the value attribute of a single parameter item instance are combined with OR logic.

  • LivingSubjectBirthPlaceAddress - this is a patient's birthplace represented as BirthPlace.addr. This can be a full address or only known address components such as city or country. Typically a query would include either this parameter or the next one but not both.
  • LivingSubjectBirthPlaceName - this is a patient's birthplace represented as the name of a Place playing the role of BirthPlace.
  • OtherIDsScopingOrganization - an identifier used for the patient in a different registry is an instance of OtherIDs. The organization that manages that other registry is the OtherIDs.ScopingOrganization. This parameter can be used to find patients who have been registered by a particular organization.
  • PatientStatusCode - this is the status of the patient record in the target registry. The parameter is used to find records in a particular state such as "active" or "completed".
  • LivingSubjectDeceasedTime - The death date/time parameter can convey an exact moment (e.g., January 1, 1960 @ 03:00:00 EST), an approximate date (e.g., January 1960), or even a range of dates (e.g., December 1, 1959 through March 31, 1960).
  • MothersMaidenName - Mother's maiden name is a common attribute for confirming the identity of persons in some registries so it is included as one of the query parameters. But, it may not be obvious how that information is represented in the RIM. Mother's maiden name is the person name part of "family" with an EntityNamePartQualifier of "birth" for the person who is the player in a PersonalRelationship of type of "mother" to the focal person,
  • LivingSubjectId - This is an identifier for the living subject playing the role of patient. The identifier has no context (scoping organization) other than the namespace from which the identifier was issued (OID root).
  • PrincipalCareProvisionId - This is an identifier for the explicit acceptance for some aspect of a patient's care by a health care provider -- a Care Provision act.
  • PrincipalCareProviderId - This is the identifier for a health care provider who has explicitly accepted responsibility for some aspect of a patient's care.
  • PatientTelecom - This is a telecommunications address for communicating with a patient in the context of the target patient registry. It could be a telephone number, fax number or even an email address.
  • PatientAddress - This is a postal address for corresponding with a patient in the context of the target patient registry.
  • LivingSubjectBirthTime -The birth date/time parameter can convey an exact moment (e.g., January 1, 1960 @ 03:00:00 EST), an approximate date (e.g., January 1960), or even a range of dates (e.g., December 1, 1959 through March 31, 1960).
  • LivingSubjectAdministrativeGender - This parameter can limit the search to patients of a specific gender.
  • LivingSubjectName - The HL7 EN (entity name) data type is quite rich and the data type specification should be well understood before being used in a query. For example, the name use parameter can covey that a name is spelled phonetically or based on the SOUNDEX algorithm.
Contained Hierarchical Message Descriptions
Patient Registry Query By Demographics PRPA_HD201306UV02
appd4.5.8 Patient Registry Query By Identifier (PRPA_RM201307UV02)
Diagram
T-PRPA_RM201307UV.png
Parent:  Patient Administration (PRPA_DM000000UV)
Description

Overview

The Patient Registry Query By Identifier R-MIM defines the payload for a query-by-parameter message sent to a patient registry when the query placer knows an identifier for patient's record in the registry. Note that in practice it may be necessary to do a Patient Registry Find Candidates Query to find an identifier for the patient before using this message.

The response will typically return a single record so the SortControl class and the responseModalityCode, initialQuantity and initialQuantityCode attributes of QueryByParameter class are not included in the information model.

Walk-through

QueryByParameter - The entry point to the R-MIM. This class allows the query requester to specify how the query should be processed by the query fulfiller.

  • queryId - Identifier for the query. It is used to associate this query instance with both the initial response message and with later query interactions. Valuing queryId avoids the need for the QueryContinuation and QueryAck classes to carry as much detail information as is carried in the initial query.
  • statusCode - A value specifying the state of this query (based on the RIM Act class state machine), for example, active, aborted, completed.
  • modifyCode - Indicates whether the subscription to a query is new or is being modified
  • responseElementGroupId - Identifies the specific message type to be returned in the query response. The message type is constrained to the set of message types supported by the receiver responsibilities associated with the query interaction.
  • responsePriorityCode - Identifies the time frame in which a response is expected
  • executionAndDeliveryTime - Specifies the time the response is to be returned

ParameterList - This collection of parameter items for the query, similar to the WHERE clause in a SQL query. A query message must include at least one PatientIdentifier parameter item and may include DataSource parameter items. Multiple instances of parameter item are combined with AND logic. Multiple values in the value attribute of a single parameter item instance are combined with OR logic.

  • PatientIdentifier - at least one identifier for a patient's record in a patient registry
  • DataSource - the identifier for a data source (system); this supports data locator/aggregator type registries that respond to queries by farming the request out to other registries that hold the requested information.
Contained Hierarchical Message Descriptions
Patient Registry Query By Identifier PRPA_HD201307UV02
4.6 Hierarchical Message Descriptions

Go To Top

► Hierarchical Message Descriptions (Sorted by Title)
▼ Hierarchical Message Descriptions (Sorted by Display Order)
 
pointer Patient Activate (PRPA_HD201301UV02) 
pointer Patient Revise (PRPA_HD201302UV02) 
pointer Patient Nullify (PRPA_HD201305UV02) 
pointer Patient Demographics (PRPA_HD201303UV02) 
pointer Patient Registry Find Candidates Response (PRPA_HD201310UV02) 
pointer Patient Identifiers (PRPA_HD201304UV02) 
pointer Patient Registry Query By Demographics (PRPA_HD201306UV02) 
pointer Patient Registry Query By Identifier (PRPA_HD201307UV02) 
Reference

For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.

appd4.6.1 Patient Activate (PRPA_HD201301UV02)
Description

The Patient Activate payload message is used in state-transition notifications and state-transition requests for adding new records to a patient registry.

Common Message Element Types Used
E_LivingSubjectInformational COCT_MT030007UV
E_PersonInformational COCT_MT030207UV07
E_PersonInformational COCT_MT030207UV07
E_OrganizationIdentified/confirmable COCT_MT150002UV01
E_OrganizationContact COCT_MT150003UV03
E_OrganizationInformational COCT_MT150007UV
E_OrganizationInformational COCT_MT150007UV
A_CoverageUniversal COCT_MT510000UV06
R_GuarantorUniversal COCT_MT670000UV04
E_PlaceInformational COCT_MT710007UV07
A_PrincipalCareProvisionUniversal COCT_MT820000UV
A_SpatialCoordinateUniversal COCT_MT960000UV05
Base Hierarchical Message Description Goto RMIM Table View Excel View
Message Type List
Patient Activate PRPA_MT201301UV02 Table View Schema View View Interactions
appd4.6.2 Patient Revise (PRPA_HD201302UV02)
Description

The Patient Revise payload message is used in state-transition notifications and state-transition requests for revising existing records in a patient registry.

Common Message Element Types Used
E_LivingSubjectInformational COCT_MT030007UV
E_PersonInformational COCT_MT030207UV07
E_PersonInformational COCT_MT030207UV07
E_OrganizationIdentified/confirmable COCT_MT150002UV01
E_OrganizationContact COCT_MT150003UV03
E_OrganizationInformational COCT_MT150007UV
E_OrganizationInformational COCT_MT150007UV
A_CoverageUniversal COCT_MT510000UV06
R_GuarantorUniversal COCT_MT670000UV04
E_PlaceInformational COCT_MT710007UV07
A_PrincipalCareProvisionUniversal COCT_MT820000UV
A_SpatialCoordinateUniversal COCT_MT960000UV05
Base Hierarchical Message Description Goto RMIM Table View Excel View
Message Type List
Patient Revise PRPA_MT201302UV02 Table View Schema View View Interactions
appd4.6.3 Patient Nullify (PRPA_HD201305UV02)
Description

The Patient Nullify payload message is used in the state-transition notification reporting nullification of an erroneously-entered record in a patient registry.

Common Message Element Types Used
E_OrganizationContact COCT_MT150003UV03
E_PlaceInformational COCT_MT710007UV07
A_SpatialCoordinateUniversal COCT_MT960000UV05
Base Hierarchical Message Description Goto RMIM Table View Excel View
Message Type List
Patient Nullify PRPA_MT201305UV02 Table View Schema View View Interactions
appd4.6.4 Patient Demographics (PRPA_HD201303UV02)
Description

The Patient Demographics payload message is used to return a complete or partial record from a patient registry in response to a query.

Common Message Element Types Used
E_LivingSubjectInformational COCT_MT030007UV
E_PersonInformational COCT_MT030207UV07
E_PersonInformational COCT_MT030207UV07
E_OrganizationIdentified/confirmable COCT_MT150002UV01
E_OrganizationContact COCT_MT150003UV03
E_OrganizationInformational COCT_MT150007UV
E_OrganizationInformational COCT_MT150007UV
A_CoverageUniversal COCT_MT510000UV06
R_GuarantorUniversal COCT_MT670000UV04
E_PlaceInformational COCT_MT710007UV07
A_PrincipalCareProvisionUniversal COCT_MT820000UV
A_SpatialCoordinateUniversal COCT_MT960000UV05
Base Hierarchical Message Description Goto RMIM Table View Excel View
Message Type List
Patient Demographics PRPA_MT201303UV02 Table View Schema View View Interactions
appd4.6.5 Patient Registry Find Candidates Response (PRPA_HD201310UV02)
Description

The Find Candidates Response payload message is used to return records from a patient registry in response to a find candidates query. Each record includes an observation reporting how well the record matched the query parameters.

Common Message Element Types Used
E_LivingSubjectInformational COCT_MT030007UV
E_PersonInformational COCT_MT030207UV07
E_PersonInformational COCT_MT030207UV07
E_OrganizationIdentified/confirmable COCT_MT150002UV01
E_OrganizationContact COCT_MT150003UV03
E_OrganizationInformational COCT_MT150007UV
E_OrganizationInformational COCT_MT150007UV
A_CoverageUniversal COCT_MT510000UV06
R_GuarantorUniversal COCT_MT670000UV04
E_PlaceInformational COCT_MT710007UV07
A_PrincipalCareProvisionUniversal COCT_MT820000UV
A_SpatialCoordinateUniversal COCT_MT960000UV05
Base Hierarchical Message Description Goto RMIM Table View Excel View
Message Type List
Patient Registry Find Candidates Response PRPA_MT201310UV02 Table View Schema View View Interactions
appd4.6.6 Patient Identifiers (PRPA_HD201304UV02)
Description

The Patient Identifiers payload message is used to return all identifiers associated with a record in a patient registry in response to a query.

Common Message Element Types Used
E_OrganizationIdentified/confirmable COCT_MT150002UV01
E_OrganizationContact COCT_MT150003UV03
E_OrganizationInformational COCT_MT150007UV
A_CoverageUniversal COCT_MT510000UV06
A_PrincipalCareProvisionUniversal COCT_MT820000UV
Base Hierarchical Message Description Goto RMIM Table View Excel View
Message Type List
Patient Identifiers PRPA_MT201304UV02 Table View Schema View View Interactions
appd4.6.7 Patient Registry Query By Demographics (PRPA_HD201306UV02)
Description

The Query By Demographics payload message is used in query-by-parameter messages sent to a patient registry when the query placer knows a set of patient demographics.

Base Hierarchical Message Description Goto RMIM Table View Excel View
Message Type List
Patient Registry Query By Demographics PRPA_MT201306UV02 Table View Schema View View Interactions
appd4.6.8 Patient Registry Query By Identifier (PRPA_HD201307UV02)
Description

The Query By Identifier payload message is used in query-by-parameter messages sent to a patient registry when the query placer knows a patient's registry identifier.

Base Hierarchical Message Description Goto RMIM Table View Excel View
Message Type List
Patient Registry Query By Identifier PRPA_MT201307UV02 Table View Schema View View Interactions
4.7 Interactions

Go To Top

► Interactions (Sorted by Title)
▼ Interactions (Sorted by Display Order)
 
pointer Patient Registry Record Added (PRPA_IN201301UV02) 
pointer Patient Registry Add Request (PRPA_IN201311UV02) 
pointer Patient Registry Add Request Accepted (PRPA_IN201312UV02) 
pointer Patient Registry Add Request Rejected (PRPA_IN201313UV02) 
pointer Patient Registry Record Revised (PRPA_IN201302UV02) 
pointer Patient Registry Revise Request (PRPA_IN201314UV02) 
pointer Patient Registry Revise Request Accepted (PRPA_IN201315UV02) 
pointer Patient Registry Revise Request Rejected (PRPA_IN201316UV02) 
pointer Patient Registry Record Nullified (PRPA_IN201303UV02) 
pointer Patient Registry Duplicates Resolved (PRPA_IN201304UV02) 
pointer Patient Registry Find Candidates Query (PRPA_IN201305UV02) 
pointer Patient Registry Find Candidates Query Response (PRPA_IN201306UV02) 
pointer Patient Registry Get Demographics Query (PRPA_IN201307UV02) 
pointer Patient Registry Get Demographics Query Response (PRPA_IN201308UV02) 
pointer Patient Registry Get Identifiers Query (PRPA_IN201309UV02) 
pointer Patient Registry Get Identifiers Query Response (PRPA_IN201310UV02) 
Reference

For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.

appd4.7.1 Patient Registry Record Added (PRPA_IN201301UV02)
Description Schema View

A patient registry sends this notification after adding a record to the registry.

Trigger Event Patient Registry Record Added PRPA_TE201301UV02
Transmission Wrapper Send Message Payload MCCI_MT000100UV01
Control Act Wrapper Master File / Reg Notif. Control Act, Role Subject MFMI_MT700701UV01
Message Type Patient Activate PRPA_MT201301UV02
Sending and Receiving Roles
Sender Patient Registry Informer PRPA_AR201301UV02
Receiver Patient Registry Tracker PRPA_AR201302UV02
appd4.7.2 Patient Registry Add Request (PRPA_IN201311UV02)
Description Schema View

A user initiates a request to add a record to a patient registry.

Trigger Event Patient Registry Add Request PRPA_TE201311UV02
Transmission Wrapper Send Message Payload MCCI_MT000100UV01
Control Act Wrapper Master File / Reg Request Control Act,Role Subject MFMI_MT700721UV01
Message Type Patient Activate PRPA_MT201301UV02
Receiver Responsibilities
Reason Trigger Event Interaction
A Request Fufiller application role is responsible for informing a requesting application role if its activation request is accepted PRPA_TE201312UV02 PRPA_IN201312UV02
A Request Fufiller application role is responsible for informing a requesting application role if its activation request is rejected and why PRPA_TE201313UV02 PRPA_IN201313UV02
Sending and Receiving Roles
Sender Patient Registry Request Placer PRPA_AR201305UV02
Receiver Patient Registry Request Fulfiller PRPA_AR201306UV02
appd4.7.3 Patient Registry Add Request Accepted (PRPA_IN201312UV02)
Description Schema View

A patient registry accepts a request to add a record and responds back to the requesting application. The payload contains the identifier assigned to the new patient record.

Trigger Event Patient Registry Add Request Accepted PRPA_TE201312UV02
Transmission Wrapper Application Level Acknowledgement MCCI_MT000300UV01
Control Act Wrapper Master File / Reg Notif. Control Act, Role Subject MFMI_MT700701UV01
Message Type Patient Identifiers PRPA_MT201304UV02
Sending and Receiving Roles
Sender Patient Registry Request Fulfiller PRPA_AR201306UV02
Receiver Patient Registry Request Placer PRPA_AR201305UV02
appd4.7.4 Patient Registry Add Request Rejected (PRPA_IN201313UV02)
Description Schema View

A patient registry rejects a request to add a record and responds back to the requesting application. The reason for the rejection is returned as a Detected Issue in the Master File / Reg Request Control Act,Role Subject wrapper. The payload returns the patient record sent in the original request

Trigger Event Patient Registry Add Request Rejected PRPA_TE201313UV02
Transmission Wrapper Application Level Acknowledgement MCCI_MT000300UV01
Control Act Wrapper Master File / Reg Request Control Act,Role Subject MFMI_MT700721UV01
Message Type Patient Activate PRPA_MT201301UV02
Sending and Receiving Roles
Sender Patient Registry Request Fulfiller PRPA_AR201306UV02
Receiver Patient Registry Request Placer PRPA_AR201305UV02
appd4.7.5 Patient Registry Record Revised (PRPA_IN201302UV02)
Description Schema View

A patient registry sends this notification after revising a record in the registry.

Trigger Event Patient Registry Record Revised PRPA_TE201302UV02
Transmission Wrapper Send Message Payload MCCI_MT000100UV01
Control Act Wrapper Master File / Reg Notif. Control Act, Role Subject MFMI_MT700701UV01
Message Type Patient Revise PRPA_MT201302UV02
Sending and Receiving Roles
Sender Patient Registry Informer PRPA_AR201301UV02
Receiver Patient Registry Tracker PRPA_AR201302UV02
Receiver Patient Registry Revision Tracker PRPA_AR201307UV02
appd4.7.6 Patient Registry Revise Request (PRPA_IN201314UV02)
Description Schema View

A user initiates a request to revise an existing record to a patient registry.

Trigger Event Patient Registry Revise Request PRPA_TE201314UV02
Transmission Wrapper Send Message Payload MCCI_MT000100UV01
Control Act Wrapper Master File / Reg Request Control Act,Role Subject MFMI_MT700721UV01
Message Type Patient Revise PRPA_MT201302UV02
Receiver Responsibilities
Reason Trigger Event Interaction
A Request Fufiller application role is responsible for informing a requesting application role if its revision request is accepted PRPA_TE201315UV02 PRPA_IN201315UV02
A Request Fufiller application role is responsible for informing a requesting application role if its revision request is rejected and why PRPA_TE201316UV02 PRPA_IN201316UV02
Sending and Receiving Roles
Sender Patient Registry Request Placer PRPA_AR201305UV02
Receiver Patient Registry Request Fulfiller PRPA_AR201306UV02
appd4.7.7 Patient Registry Revise Request Accepted (PRPA_IN201315UV02)
Description Schema View

A patient registry accepts a request to revise an existing record and responds back to the requesting application. The revised patient record from the registry is returned in the payload.

Trigger Event Patient Registry Revise Request Accepted PRPA_TE201315UV02
Transmission Wrapper Application Level Acknowledgement MCCI_MT000300UV01
Control Act Wrapper Master File / Reg Notif. Control Act, Role Subject MFMI_MT700701UV01
Message Type Patient Demographics PRPA_MT201303UV02
Sending and Receiving Roles
Sender Patient Registry Request Fulfiller PRPA_AR201306UV02
Receiver Patient Registry Request Placer PRPA_AR201305UV02
appd4.7.8 Patient Registry Revise Request Rejected (PRPA_IN201316UV02)
Description Schema View

A patient registry rejects a request to revise an existing record and responds back to the requesting application. The reason for the rejection is returned as a Detected Issue in the Master File / Reg Request Control Act,Role Subject wrapper. The payload returns the patient record sent in the original request

Trigger Event Patient Registry Revise Request Rejected PRPA_TE201316UV02
Transmission Wrapper Application Level Acknowledgement MCCI_MT000300UV01
Control Act Wrapper Master File / Reg Request Control Act,Role Subject MFMI_MT700721UV01
Message Type Patient Revise PRPA_MT201302UV02
Sending and Receiving Roles
Sender Patient Registry Request Fulfiller PRPA_AR201306UV02
Receiver Patient Registry Request Placer PRPA_AR201305UV02
appd4.7.9 Patient Registry Record Nullified (PRPA_IN201303UV02)
Description Schema View

A patient registry sends this notification after nullifying an erroneously created record in the registry.

Trigger Event Patient Registry Record Nullified PRPA_TE201303UV02
Transmission Wrapper Send Message Payload MCCI_MT000100UV01
Control Act Wrapper Master File / Reg Notif. Control Act, Role Subject MFMI_MT700701UV01
Message Type Patient Nullify PRPA_MT201305UV02
Sending and Receiving Roles
Sender Patient Registry Informer PRPA_AR201301UV02
Receiver Patient Registry Tracker PRPA_AR201302UV02
appd4.7.10 Patient Registry Duplicates Resolved (PRPA_IN201304UV02)
Description Schema View

A patient registry sends this notification after resolving duplicate registrations in the registry. The surviving registration (RegistrationEvent.statusCode = "active") links via the replacementOf act relationship to the deprecated registration (PriorRegistration.statusCode = "obsolete"). A copy of the surviving person record is sent in the payload message.

Trigger Event Patient Registry Duplicates Resolved PRPA_TE201304UV02
Transmission Wrapper Send Message Payload MCCI_MT000100UV01
Control Act Wrapper Master File / Reg Notif. Control Act, Role Subject MFMI_MT700701UV01
Message Type Patient Demographics PRPA_MT201303UV02
Sending and Receiving Roles
Sender Patient Registry Informer PRPA_AR201301UV02
Receiver Patient Registry Tracker PRPA_AR201302UV02
appd4.7.11 Patient Registry Find Candidates Query (PRPA_IN201305UV02)
Description Schema View

A user initiates a query to a patient registry requesting all records that match a particular set of parameters.

Trigger Event Patient Registry Find Candidates Query PRPA_TE201305UV02
Transmission Wrapper Send Message Payload MCCI_MT000100UV01
Control Act Wrapper Query Control Act Request : Query By Parameter QUQI_MT021001UV
Query Definition Patient Registry Query By Demographics PRPA_MT201306UV02
Receiver Responsibilities
Reason Trigger Event Interaction
A Query Fulfiller application role is responsible for responding to queries PRPA_TE201306UV02 PRPA_IN201306UV02
Sending and Receiving Roles
Sender Patient Registry Query Placer PRPA_AR201303UV02
Receiver Patient Registry Query Fulfiller PRPA_AR201304UV02
appd4.7.12 Patient Registry Find Candidates Query Response (PRPA_IN201306UV02)
Description Schema View
Trigger Event Patient Registry Find Candidates Query Response PRPA_TE201306UV02
Transmission Wrapper Application Level Acknowledgement MCCI_MT000300UV01
Control Act Wrapper Master File / Registry Query Response,Role Subject MFMI_MT700711UV01
Query Response Type Patient Registry Find Candidates Response PRPA_MT201310UV02
Query Definition Patient Registry Query By Demographics PRPA_MT201306UV02
Sending and Receiving Roles
Sender Patient Registry Query Fulfiller PRPA_AR201304UV02
Receiver Patient Registry Query Placer PRPA_AR201303UV02
appd4.7.13 Patient Registry Get Demographics Query (PRPA_IN201307UV02)
Description Schema View

A user initiates a query to a patient registry requesting demographic information for a specific patient.

Trigger Event Patient Registry Get Demographics Query PRPA_TE201307UV02
Transmission Wrapper Send Message Payload MCCI_MT000100UV01
Control Act Wrapper Query Control Act Request : Query By Parameter QUQI_MT021001UV
Query Definition Patient Registry Query By Identifier PRPA_MT201307UV02
Receiver Responsibilities
Reason Trigger Event Interaction
A Query Fulfiller application role is responsible for responding to queries PRPA_TE201308UV02 PRPA_IN201308UV02
Sending and Receiving Roles
Sender Patient Registry Query Placer PRPA_AR201303UV02
Receiver Patient Registry Query Fulfiller PRPA_AR201304UV02
appd4.7.14 Patient Registry Get Demographics Query Response (PRPA_IN201308UV02)
Description Schema View

A patient registry responds to a query with demographic information in the registry for the patient specified in the query.

Trigger Event Patient Registry Get Demographics Query Response PRPA_TE201308UV02
Transmission Wrapper Application Level Acknowledgement MCCI_MT000300UV01
Control Act Wrapper Master File / Registry Query Response,Role Subject MFMI_MT700711UV01
Query Response Type Patient Demographics PRPA_MT201303UV02
Query Definition Patient Registry Query By Identifier PRPA_MT201307UV02
Sending and Receiving Roles
Sender Patient Registry Query Fulfiller PRPA_AR201304UV02
Receiver Patient Registry Query Placer PRPA_AR201303UV02
appd4.7.15 Patient Registry Get Identifiers Query (PRPA_IN201309UV02)
Description Schema View

A user initiates a query to a patient registry requesting all identifiers for a specific patient.

Trigger Event Patient Registry Get Identifiers Query PRPA_TE201309UV02
Transmission Wrapper Send Message Payload MCCI_MT000100UV01
Control Act Wrapper Query Control Act Request : Query By Parameter QUQI_MT021001UV
Query Definition Patient Registry Query By Identifier PRPA_MT201307UV02
Receiver Responsibilities
Reason Trigger Event Interaction
A Query Fulfiller application role is responsible for responding to queries PRPA_TE201310UV02 PRPA_IN201310UV02
Sending and Receiving Roles
Sender Patient Registry Query Placer PRPA_AR201303UV02
Receiver Patient Registry Query Fulfiller PRPA_AR201304UV02
appd4.7.16 Patient Registry Get Identifiers Query Response (PRPA_IN201310UV02)
Description Schema View
Trigger Event Patient Registry Get Identifiers Query Response PRPA_TE201310UV02
Transmission Wrapper Application Level Acknowledgement MCCI_MT000300UV01
Control Act Wrapper Master File / Registry Query Response,Role Subject MFMI_MT700711UV01
Query Response Type Patient Identifiers PRPA_MT201304UV02
Query Definition Patient Registry Query By Identifier PRPA_MT201307UV02
Sending and Receiving Roles
Sender Patient Registry Query Fulfiller PRPA_AR201304UV02
Receiver Patient Registry Query Placer PRPA_AR201303UV02

Return to top of page