Master File - Registry Infrastructure

ANSI/HL7 V3 MFRI, R1-2006 (R2011)
HL7 Version 3 Standard: Master File - Registry Infrastructure, Release 1 (reaffirmation of ANSI/HL7 V3 MFRI, R1-2006)
10/12/2011

Responsible Group	Infrastructure and Messaging Work Group HL7
Infrastructure and Messaging Co-Chair	Graham Grieve Kestral Computing Pty Ltd.
Infrastructure and Messaging Co-Chair	Anthony Julian Mayo Clinic
Infrastructure and Messaging Co-Chair	Joann Larson Kaiser Permanente
Infrastructure and Messaging Co-Chair	Douglas Pratt Siemens
Infrastructure and Messaging Co-Chair	Rene Spronk Ringholm GmbH

HTML Generated: 2012-08-31T12:05:59

Content Last Edited: 2006-03-09T12:57:31

HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
Use of these materials is governed by HL7 International's IP Compliance Policy.

Preface
    i Notes to Readers
    ii Known Issues & Planned Changes
    iii Message Design Element Navigation
1 Overview
    1.1 Introduction & Scope
    1.2 Domain Information Models
2 Master File - Registry Topic
    2.1 Introduction
    2.2 Storyboards
    2.3 Application Roles
    2.4 Trigger Events
    2.5 Refined Message Information Models
    2.6 Hierarchical Message Descriptions
3 Quality Analysis Report Topic
4 CMETs Used by this Domain
5  Glossary

This is the first Normative Release of the Master File / Registry (MFMI) domain.

The following known open issues will be dealt with in a future release of this material:

A way is needed to convey acknowledgements to individual registration requests contained within master file messages - as of yet there is no equivalent of the HL7 version 2 MFA segment. Associating the RegistrationProcess class with the A_DetectedIssue CMET may prove to be a solution. This Order-related issue is not limited to the registry domain. The cardinality of the association between the controlAct and the registrationProcess act has been constrained to 1..1 in the registration request R-MIM until such time the issue has been dealt with. The cardinality will be set to 1..* again once a solution has been found.
The classCode of RegisteredRole is currently constrained to ROL. CQ intends to create an x_RegistrySubjectRoleClass value set containing the leaf-concepts of the RoleClassPassive and RoleClassRelationshipFormal hierarchies.
Note that upon replacing of a registration the status of the erronous prior registration will change to obsolete, but this does not automatically imply that the status of the registered Role or Act changes to obsolete. The use-case where both are obsoleted at the same time will be dealt with in the next release of this material.

▼ Master File - Registry Topic ()

	Master File / Reg Registration Request Control Act (MFMI_RM700720UV01)
	Master File / Reg Event Notification Control Act (MFMI_RM700700UV01)
	Master File / Registry Query Response Control Act (MFMI_RM700710UV01)

The Master File / Registry domain comprises the classes and attributes needed to support Master Files and Registries. It does so by providing a Trigger Event Control Act that can be associated through a subject participation either with an entity (a Role) or with an act.

This domain focuses on the Master File / Registry specific extensions to the generic Trigger Event Control Act. Refer to the Message Control Act Infrastructure Introduction for general details on Trigger Event Control Acts.

Note that the Master File Infrastructure does not define message transmission rules or transmission wrappers. Instead, it uses the transmission rules and transmission wrappers defined under the Transmission Infrastructure domain. In addition, it does not define message structures, trigger events, or interactions. It simply provides a specialized Control Act Wrapper for use in master file type interactions.

Master File / Registry Acts

Definition:

Represents the act of maintaining information about the registration of its associated registered subject. The subject can be either an Act or a Role, and includes Role Based subjects such as persons, patients, practitioners, and equipment, as well as Act-based subjects such as lab exam definitions, prescriptions and drug protocol definitions.

Note on Act-based subjects (FAQ): they may be in any mood, including, but not limited to, DEF.

Background Discussion:

Maintaining a Master File / Registry over time requires that one tracks changes to a registered subject above and beyond state changes to that subject. Typically, the registered subject is reasonably static and serves as reference information within environments that employ trusted sources of such information such as masterfiles and registries. The registration event may have a unique identifier - separate from the unique identification of the subject - as well as a core set of related participations and act relationships that characterize the registration event and aid in the disposition of the subject information by a receiving system.

Registry acts compared with Master Files:

Master File applications support notifications about changes to the Master File. The application role that supports just this set of notifications is the equivalent of an 'ordinary' Master Files application that sends only event-mood notifications. In such cases the Registry act part of the transaction is minimal, and most of the information is carried in the subject participation that carries the 'Master File' data. Besides the 'Master Files notification' application role, a Registry application also supports events in order mood, as well as queries. For these interactions, the Registry application needs to track the participations on a registry interaction with a greater degree of precision than is possible with a basic control act. The Registry may have roles (such as patient and staff) as its main content, or entities (in role of "registered entity"). It may also consist of acts (such as acts in definition mood for specializations of atomic acts, as well as protocols, and complex act structures).

Use cases include:

Applications such as the patient Registry and the master patient index (MPI) make use of the Registry act specialization. Typically these applications receive data from multiple sources, and will also need to document the sources of any changes to the records in the Registries that they manage.

Registry examples include:

MPI (master patient index)
staff/employee Registries
accreditation/certificate maintenance Registries
acts (or groups of acts) defining protocols/treatment plans, order sets, etc.
Canadian Provider Registry

Master File examples include:

charge description Master File
location Master File
device Master File.

Note: These use cases are meant to be general examples only. They are NOT meant to specify the details of a given Registry or Master File application. Such details will be created when specific Master File / Registry applications are added to the applicable HL7 Version 3 domain.

Go To Top

Diagram

Design Walk-Through

The Master File / Registry (MFMI) Control Act is a specialization of the Trigger Event Control Act and is centered around the ControlActProcess act. Refer to the Message Control Act Infrastructure D-MIM walk-through for general details on the ControlActProcess element. The remainder of this walk-through discusses that specialization.

Focal Classes Exposed

The ControlActProcess act, as constrained within the Master File / Registry Infrastructure domain, constitutes the Trigger Event Control Act. Its associations facilitate the production of Master File and Registry related messages.

The structure of the Master File / Registry D-MIM supports both Master File and Registry messages. In both cases, the ControlActProcess is associated with one or more instances of the RegistrationProcess. RegistrationProcess is associated either with an Act payload or a Role payload. Only one, not both, of Act or AssignedEntity may be present in a message type instance of the Master File / Registry act.

Stubs

The Master File / Registry DMIM contains 3 stubs. Any interaction which uses this ControlAct Wrapper will replace these with a domain Message Type.

The RegisteredAct stub will be replaced by an Act-based Message Type in Act-registry based interactions.
The RegisteredRole stub will be replaced by a Role-based Message Type in Role-registry based interactions.
The QueryByParameter stub will be replaced by a QueryByParameter based Message Type in interactions used as a response to registry queries.

Master File / Registry Domain Information Model Classes

ControlActProcess

Refer to the Message Control Act Infrastructure for a description of ControlActProcess as well as its associated classes (e.g. the A_DetectedIssue CMET).

This class is described more fully in the Control Infrastructure class of the Message Control domain.

RegistrationProcess

This class contains information relevant to the registration of the payload item(s) into the Master File or Registry. It also allows for this Registration Act to be associated with the domain-defined Master File entry stub (as Role) or (xor) Registry domain-defined entry point stub (as Act).

Note: The RegistrationProcess act is the focal act of the message. It has been included in the Master File / Registry (MFMI) Trigger Event control Act message type for reasons of convenience only. It is effectively a piece of predefined payload that has been included in a specialized version of the Trigger Event Control Act wrapper. Trigger Events are typically based on state changes of the RegistrationProcess class.

As noted below, Role and Act Master File / Registry payloads shall not be combined into the same message type. The following attributes are supported for this class:

classCode: A code specifying the major type of Act that this Act-instance represents. This attribute is required and constrained to the value REG. (mandatory)
moodCode: A code distinguishing whether an Act is conceived of as a factual statement or in some other manner as a command, possibility, goal, etc. This attribute is required and constrained by the x_ActMoodIntentEvent domain. Commonly used moodCodes include EVN (this subject payload is/has been registered) and RQO (please register this subject payload). (mandatory)
id: A unique identifier for the Act. (Required) Version 2 mapping: MFE-2.
statusCode: A code specifying the state of the registration of the payload. This attribute is required and constrained by the ActStatus domain. The default value is "active". If the Registration has been replaced, its value will be "obsolete". (optional) Version 2 mapping: MFE-1
effectiveTime An interval of time specifying the operative time of the Registration. (optional) Version 2 mapping: MFE-3

The following associations are defined for a Master File / Registry Trigger Event RegistrationProcess class.

author: Who or what is performing the registration. This participation is not required. This participation associates the registration with an entity responsible for the registration. The identification of the author is mandatory for interactions where the Registration Act is in request (RQO) mood.
custodian: Who or what is responsible for maintenance of the registration. The custodian identifies responsibility for the registration over its entire life cycle, whereas an author is responsible for a one-off event of requesting a (change to a) registration. Note that the custodian of a Registration Act in event (EVN) or promise (PRMS) mood identifies the custodian of the actual registration, i.e. the custodian of the registry, the entity responsible for the maintenance of the registry application.
definition: Defines the registration. This act relationship associates the registration with the ActDefinition class, which is used to identify the kind of registry.
infulfillmentOf: : Identifies zero or more Acts that are fulfilled by the focal Registration Act of this message. The Act that is fulfilled is the original registration request (an order) to register roles or acts. See below for an explanation of the use of this Act relationship.
subject2 [act relationship]: Relates the registration process to the Registry payload information (represented here by Act) for which it is a Trigger Event Control Act.
subject1: Relates the registration process to the Master File payload information (represented here by Role) for which it is a Trigger Event Control Act.

Act

This class represents the stub of a domain-defined Master File / Registry payload message type that is instantiated for interactions.

ActDefinition

This class identifies the kind of payload that is undergoing registration. This is directly related to the kind of Registry. For example, it could identify the kind of Person, Clinical Statement or CDA document being registered. The id attribute of this class (Mandatory) identifies the vocabulary used to specify the kind of registry or the kind of registration subject. The code attribute (Required) of this class contains a code taken from the vocabulary identified by the id attribute. Note: This attribute does not identify a specific master file / registry application. If a message is sent to a master file / registry application, then that application is identified in the Transmission Wrapper. Version 2 mapping: MFI-1

Role

This class represents the stub of a domain-defined Master File / Registry payload message type that is instantiated for interactions. (Note: Instead of allowing the subject role to be of any type, CQ intends to create an x_RegistrySubjectRoleClass value set containing the leaf-concepts of the RoleClassPassive and RoleClassRelationshipFormal hierarchies)

Act relationships and Mood Codes

This section contains some diagrams to illustrate the use of the infulfillmentOf and replacementOf Act relationships between Registration classes in different moods. Note that these diagrams have been greatly simplified: the names of the cloned Registration classes are incorrect, and the standard Trigger Event Control Act classes as well as some of the mandatory/required attributes have been removed.

A registration request in RQO mood (MFMI_RM700720)
A registration event (EVN) notification, used either in the context of a change to the registration because of changes made by the Custodian of the registry, or in response to a (fulfillment) registration request (MFMI_RM700700). In the first case the inFulfillmentOf relationship will not be present. Note that a response to a registry query (MFMI_RM700710) has the same structure; it may however not have the infulFillmentOf relationship.
A registration replacement request (MFMI_RM700720). This is a both a request to register a subject payload as well as a request to replace a prior registration. The registry sets the statusCode of the replaced registration to "obsolete" once it fulfills the new registration request.
A registration replacement notification, used either in the context of a replacement action undertaken by the Custodian of the registry, or in response to a (fulfillment) registration replacement request (MFMI_RM700700). In the first case the inFulfillmentOf relationship will not be present.

Version 2 mapping

In version 2, a given master files message concerns only a single master file (e.g. patients only). The provision of a record-level event code (and requested activation date) on the MFE segment allows a single message to contain several types of changes (events, e.g. update, delete) to that file. The Version 3 model allows for changes to multiple master files within one interaction (e.g. a change to the person master file as well as to a location master file). Record-level changes are supported by means of the RegistrationProcess class which may be related to multiple records. The closest equivalent of the RegistrationProcess class is the MFE segment.

MFI-1 = ActDefinition, subject Act/Role classCode

MFI-2 = Custodian.

MFI-3, MFI-4, MFI-5 = ControlActProcess attributes

MFI-6 = Receiver responsibility related to the interaction

MFE-1 = registrationProcess.statusCode (loosely)

MFE-2 = RegistrationProcess.id

MFE-3 = RegistrationProcess.effectiveTime

MFE-4/MFE-5 = in Payload

MFE-6 = Author.time

MFE-7 = Author

Return to top of page

Master File - Registry Infrastructure

Table of Contents

Preface