Registries and Master Files
for the latest version of this document.
The data as contained in healthcare IT applications is synchronized by the exchange of HL7 messages. These messages will refer to the identifiers of commonly used objects such as locations, physicians and laboratory tests. A Registry maintains the identifiers of certain objects, and searchable metadata to permit a user to locate the correct identifier of the object in question. This whitepaper describes Master Files and Registries at a conceptual level. HL7 version 2 and HL7 version 3 master file messages are discussed in an appendix.
1. IntroductionAn ever increasing amount of data is exchanged between applications in healthcare. The data as contained in healthcare IT applications is synchronized by the exchange of messages. This data will refer to the identifiers (codes) of commonly used objects such as locations, physicians and laboratory tests. A list of object identifiers of a specific type is known as a Reference Table.
These reference tables are currently mainly maintained by a manual synchronization processes, or a "master file" created by a (third party) source is processed by applications on a periodic basis. There is an increasing demand to synchronize these files in an automated process.
Reference tables will typically be managed (or: owned) by a single application. This application is known as a Registry. There may be multiple registries in a healthcare environment, e.g. one for locations, and one for laboratory test definitions. The registry is responsible for the synchronization of the reference files between various applications.
2. RegistriesA Registry maintains the identifiers of certain objects, and searchable metadata to permit a user to locate the correct identifier of the object in question. A Registry manages ‘reference’ data appropriate to one conceptual entity. It is generally used to support the coordinated interaction of multiple systems; its information is constantly referenced during operation. The primary purpose of a Registry is to respond to searches using one or more pre-defined parameter in order to find and retrieve a unique occurrence of an entity.
Registries have been receiving more attention recently as countries like the UK (CfH), the Netherlands (AORTA), Germany (gematik) and Canada have been working on initiatives related to a continuity-of-care oriented Electronic Health Record. Certain registries are seen as essential building blocks towards this goal. The general feeling by HL7 and other groups is that the major registries are the Client, Provider, Location, and Security/Consent Registries. A client registry can be defined as a directory of people being treated, accessible across all points of care, within a region, a province or nationwide. A provider registry is an index of caregivers with a description of their roles within any given jurisdiction. A location registry identifies all health care sites where services are delivered to patients. [UVIC]
Figure 1. Interactions supported by a Registry
Registries support the following interactions:
In general, the way in which the receiving system processes the update request messages will depend on both the design of the receiving system and the requirements negotiated at the site. Some systems and/or sites may specify a manual review of all requested changes to a particular registry. Some may specify a totally automated process. Not every system at every site will need all the fields contained in the update request message.
This also means that an application acknowledgment from a receiving system that it accepted the registry update request does not imply that the receiving system has an exact copy of the information and state that is on the sending system: it means only that a relevant subset of that message’s data is kept on the receiving system in such a manner that a new registry update request message with the same primary key can be applied unambiguously to that subset of information.
2.1 Master File Registries The functionality of a Master File Registry is a subset of the functionality of registries. It is a registry of more of a permanent nature; it contains relatively stable information which changes infrequently.
All of the registries described in HL7 version 2 are Master File Registries. HL7 version 3 addresses the use of all registry types.
Figure 2. Interactions supported by a Master File Registry
A Terminology server contains information and metadata related to terminologies and vocabularies that can be queried and retrieved. The queries may be simple or complex depending on the sophistication of the server. A terminology server is intended to support multiple applications' use of common terminologies and vocabularies.
The complexity of the inter-object relationships managed by a terminology server is much higher than the relationships among identifiers managed by other registries. The complexity is such that one needs proper development models for the underlying content. Terminology development is mostly done in a process which is akin to software development - it needs to be developed, run through a QA process, and then released.
Notifications generally use a batch update model given the complicated process of terminology development. If the terminology server allows for local modifications to the terminology content, then the update process must be very robust and deal with the potential for semantic conflict (and subsequent resolution of those conflicts) in the resulting updated model.
3. SummaryRegistries can be used to synchronize identifiers between systems in an automated manner. One can get probably get away with manually updating references tables that change very little. However, the more the registry entries are subject to change, and the more they are referenced by different healthcare IT applications, the higher the need for a registry will be. The move towards a shared EHR in some countries will in all likelihood increase the use of registries.
4. AcknowledgementsWe'd like to thank W. Ted Klein (Klein Consulting, Inc.) and Larry V. Streepy Jr. (Health Language, Inc.) for their comments related to terminology servers. Their comments were made in an e-mail exchange on 2004-04-13. The definition of the terms "Registry" and "Master File Registry" are based in part on the work by Shaina Hood and Shannon Malovec. [UVIC]
4. References[UVIC] "Analysis of a Generic Registry: an HL7 Position", March 2004, Shaina Hood and Shannon Malovec, University of Victoria School of Health Information Science.
Appendix A: HL7 v2 Master File MessagesThis part of the whitepaper contains the technical details of HL7 version 2 Master File messages.
A.1 Master File MessagesHL7 offers support for Master File Registries. In version 2 of the standard these registries are simply referred to as "Master File System" and the contents as a "Master File".
Figure A.1. Message interaction diagram for Master File messages defined by HL7 v2
Chapter 8 of the standard describes a number of master file messages as well as their dynamic behavior. Figure A.1 describes the master file messages using generic descriptions. The following master file messages have been defined:
Figure A.2 - MFN generic message definition
The structure of a MFN message is always the same. The core of MFN messages consists of a single MFI segment, and a repeating group of segments of which the first segment is MFE.
The MFI (master file identification) segment identifies the master file being updated as well as the "file-level" event (such as "replace file"). For each record being changed, the MFE (Master File Entry) segment carries the record-level event code (such as add, update, delete), and the record-level key identifying the entry in the master file.
The MFE segment specifies the identifier of the master file record. The master file record itself is contained in either Z-segments or HL7-defined segments immediately following the MFE segment. This record may be either contained in a single segment, or a complex record needing more than a single segment to carry its data and (usually hierarchical) structure.
A given master files message concerns only a single master file. However, the provision of a record-level event code on the MFE segment allows a single message to contain several types of changes (events) to that file.
Figure A.3 - MFK generic message definition
The core structure of the MFK message (master file acknowledgement) consists of a repeating MFA segment. The MFA segment returns record-specific acknowledgment information. The number of MFA segments in the acknowledgement message is equal to the number of MFE segments in the notification message.
The MFQ transaction allows a system to query for a particular record or group records (defined by the primary key) in a particular master file. The MFR transaction contains the response to the query using a message structure like the MFN message.
A.2 Master File SegmentsThis section discusses the 2 core classes of all master file messages: MFI (master file identification) and MFE (master file entry).
A.2.1 MFI Segment
MFI-1 Master File Identifier (CE) 00658
MFI-3 File Level Event Code (ID) 00660
MFI-6 Response Level Code (ID) 00663
A.2.2 MFE Segment
MFE-1 Record Level Event Code (ID) 00664
If the MFI-3 - File-level event code is "REP" (replace file), then each MFE segment must have an MFE-1 - Record-level event code of "MAD" (add record to master file).
MFE-4 Primary Key Value (Varies) 00667
MFE-5 Primary Key Value Type (CE) 01319
A.3 Patient Location Master FileHL7 v2.5 contains messages to support a number of master files. These messages can be either generic in nature (General Master File, event M13, and Site Defined Master File, event M14) or related to one conceptual entity (e.g. location master file, event M05).
The Patient Location Master File messages allow for the management of location identifiers and location metadata. The abstract message structure is described in figure A.6. The core classes of this message consists of the segment group which contains the MFE, LOC and LDP segments. Each repetition of this segment group contains the details of a single registry entry.
Figure A.6 - MFN^M05 Patient Location Master File message definition
MSH|^~\&|Registry||Applic1||200811221003||MFN^M05^MFN_M05|31|P|2.5||AL|NE MFI|LOC|EH_Locations|UPD|||AL MFE|MDL|M226||Aqua1^^^Eastern Hospital^^^Physio^B^Aqua therapy room 1|PL LOC|Aqua1^^^Eastern Hospital^^^Physio^B^Aqua therapy room 1||L MFE|MUP|M227||Aqua2^^^Eastern Hospital^^^Physio^B^Aqua therapy room 2|PL LOC|Aqua2^^^Eastern Hospital^^^Physio^B^Aqua therapy room 2|Aqua therapy room 2|L| Eastern Hospital| LDP|Aqua2^^^Eastern Hospital^^^Physio^B^Aqua therapy room 2|PHY^Physiotherapy||REH~PRE|D~O|Figure A.7 - MFN^M05 Master File Notification example
This example message updates (MFI-3=UPD) the location master file (MFI-1=LOC) of the receiving application. The update contains data related to 2 master file entries: Aqua1 (first MFE segment, MFE-4) and Aqua2 (second MFE segment, MFE-4). Aqua1 is to be deleted from the master file (MFE-1=MDL), the information for Aqua2 is to be updated (MFE-1=MUP). The LOC and LPD segments contain the location metadata related to the identifier of the location.
MFK ACK, Location Example
MSH|^~\&|Applic1||Registry||200811221004||MFK^M05^MFK_M05|31|P|2.5||AL|NE MFI|LOC|EH_Locations|UPD|||NE MFA|MDL|M226||U^Location not present|Aqua1^^^Eastern Hospital^^^Physio^B^Aqua therapy room 1|PL MFA|MUP|M227||S|Aqua2^^^Eastern Hospital^^^Physio^B^Aqua therapy room 2|PLFigure A.8 - MFK^M05 Master File Acknowledgement example
This acknowledgement example is a response to the example shown in figure A.7. The MFA segments are linked to the MFE segments by the location identifier in MFA-5. The deletion of Aqua1 from the master file has not been accepted (MFA-4=U), the update of the metadata of Aqua2 was succesful (MFA-4=S).
Appendix B: HL7 version 3 Master File MessagesThis part of the whitepaper contains the technical details of HL7 version 3 Master File messages.
B.1 Registry MessagesHL7 version 3 offers support for registries in general, as well as Master File Registries.
Figure B.1. Interactions supported by a Registry
The HL7 v3 messaging standard defines the interactions for a number of registry types. Examples (from the HL7 v3 Normative Edition 2008) include:
B.2 Core Registry ClassesThis section discusses the core class model used in all registry messages. Next to a Transmission Wrapper and a ControlAct Wrapper (used by any and all HL7 v3 interactions) all Master File/Registry interactions use one and the same class model to identify metadata related to the Registered object (a.k.a. the Master File entry).
Figure B.2. Class model for Registration Request interactions
The class model shown above (figure B.2) is used in the Update Request interaction as shown in diagram B.1. Its core characteristics are:
Figure B.3. Class model for Registration Event-based interactions
The class model shown above (figure B.3) is used in the Update Request Fulfillment, Registration Notification and Registry Query Response interactions as shown in diagram B.1. Its core characteristics are:
B.3 Person Registry exampleThe Patient Administration/Person Topic HL7 v3 specification specifies the structure and usage of interactions to support a Person Registry.
In interactions of this kind of registry the RegisterRole class (a Stub) is replaced by a detailed class model for Person demographic data.
<registrationEvent classCode="REG" moodCode="EVN"> <!-- Concept of RegistrationIDs not supported by this MPI --> <id nullFlavor="UNK"/> <statusCode code="active"/> <subject1 typeCode="SBJ"> <identifiedPerson classCode="IDENT"> <id root="2.16.5188.8.131.520.1" extension="24109642356" assigningAuthorityName="F-Number"/> <statusCode code="active"/> <identifiedPerson> <id root="2.16.5184.108.40.2060.1" extension="24109642356"/> <name use="L"> <given>Jan</given> <given>Helge</given> <family>Nielsen</family> </name> <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/> <birthTime value="19961024"/> <addr use="HP"> <streetAddressLine>Rod vei 123</streetAddressLine> <postalCode>2345</postalCode> <city>Rodby</city> </addr> <maritalStatusCode code="1" codeSystem="2.16.5220.127.116.110.6" displayName="Ugift"/> <birthPlace> <addr> <city>Oslo</city> </addr> </birthPlace> </identifiedPerson> </identifiedPerson> </subject1> <custodian typeCode="CST"> <assignedEntity classCode="ASSIGNED"> <id root="2.16.518.104.22.1680.5" extension="983658725"/> </assignedEntity> </custodian> </registrationEvent>Figure B.4 - Person registry Notification example
The example shown above (figure B.4) is based on the HL7 v3 Normative Edition 2008. It shows the registration details of a person entity (Jan Helge Nielsen), the status of the registration (active) and the custodian responsable for the contents of the registry.
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.