Ringholm-Logo Ringholm  Whitepaper Ringholm page header
Training    Services   |   Whitepapers    Blog    Events    Links   |   About us    Partners    Clients    Contact

Registries and Master Files

See http://www.ringholm.com/docs/00820_en.htm for the latest version of this document.
Author: René Spronk - Sr.Consultant, Ringholm bv
Document status: Final, version 2.0 (2009-02-25)
Please send questions and comments to Rene.Spronk@Ringholm.com
This work is licensed under a Creative Commons License.


Abstract

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. Introduction

An 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. Registries

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. 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]

UML interaction diagram for a Registry
Figure 1. Interactions supported by a Registry

Registries support the following interactions:

  • An application not "owning" a particular master file, transmits update requests (add, delete, update, merge, unmerge, unlink, and link) to the "owning" system, for review and possible inclusion. Registries receive data from multiple sources, and need to document the sources of any changes to the records in the registries that they manage.
  • A registry may notify other systems of changes or updates. These may be "real time" notifications, or batch releases.
  • A registry has to respond to queries.
If the changes to the master file are only periodically communicated, then the copies of the master file may not be an exact match of the master file in the registry. Querying the registry (i.e. the owner of a master file) for the latest information is the best guarantee that one has access to the latest information.

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.

UML interaction diagram for a Master File Registry
Figure 2. Interactions supported by a Master File Registry

In case the registry conforms to the criteria below it is known as a Master File Registry, and the reference table as a Master File:
  • The registry is the sole location where changes to the master file (reference table) are made, the registry doesn't receive update request messages from other systems.
  • The contents of the registry are relatively permanent and are only infrequently updated.
  • The registry sends notification messages of the changes (e.g., add, delete, update). The changes to the master file (reference table) are made available in a batch-like fashion to other applications on a routine basis. (e.g. monthly)
Note that a Master File Registry may offer support for queries. This is however rarely supported by master file registry implementations.

2.2 Terminology Servers

The functionality of a Terminology Server is a superset of the functionality of registries. It is a registry which manages the complex inter-object relationships between registry entries across multiple domains. Capabilities that are beyond the requirements of a registry include the management of complex relationships (mapping and hierarchies) among the entities in the registry, as well as synonymy.

  Example

Examples of objects managed by Registries include:

  • Person (Patient, Client)
  • Provider
  • Protocols/treatment plans
  • Order set definitions
  • Security/consent (authorization) rules

Examples of objects managed by Master File Registries include:

  • Charge descriptions
  • Test/exam definitions
  • Locations
  • Organizations
  • Pharmaceutical products

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. Summary

Registries 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. Acknowledgements

We'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 Messages

This part of the whitepaper contains the technical details of HL7 version 2 Master File messages.

A.1 Master File Messages

HL7 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".

Message interaction diagram for a Master Files
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:

  • MFN Notification message (Registry Notification)
  • MFK Acknowledgement message (Notification accept/reject)
  • MFQ Master file query (Registry Query)
  • MFR Master file response (Registry Query Response)

MFN Master File Notification
MSH Message Header
MFI Master File Identification
{ MFE Master File Entry
   [ One or more HL7 and/or Z-segments carrying the data for the entry identified in the MFE segment
    ]
}

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.

MFK Master File Acknowledgement
MSH Message Header
MSA Message Acknowledgement
[ERR] Error Detail
MFI Master File Identification
{ [MFA] Master File Acknowledgement
}

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 Segments

This 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

Seq Table Item# r/o/c Rep# Description Data type
1017500658R  Master File IdentifierCE
3017800660R  File Level Event CodeID
6017900663R  Response Level CodeID
Figure A.4 - MFI segment definition (partial)

MFI-1 Master File Identifier (CE) 00658
Definition: Identifies the master file type. A list of default values is defined in table 0175, for example LOC Location, STA staff, PRA Practitioner.

MFI-3 File Level Event Code (ID) 00660
Definition: This field defines the file-level event code. Contains either REP (Replace current version of this master file with the version contained in this message), or UPD (Change file records as defined in the record-level event codes for each record that follows).

MFI-6 Response Level Code (ID) 00663
Definition: These codes specify the application response level defined for a given Master File Message at the MFE segment level. All known implementations use NE (Never, No application-level response needed)

A.2.2 MFE Segment

Seq Table Item# r/o/c Rep# Description Data type
1018000664R  Record Level Event CodeID
4 00667RY Primary Key ValueVaries
5035501319RY Primary Key Value TypeCE
Figure A.5 - MFE segment definition (partial)

MFE-1 Record Level Event Code (ID) 00664
Definition: defines the record-level event for the master file record identified by the MFI segment and the primary key field in this segment. Contains one of the following codes:
MAD Add record to master file
MDL Delete record from master file
MUP Update record for master file
MDC Deactivate: discontinue using record in master file, but do not delete from database
MAC Reactivate deactivated record

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
Definition: This field uniquely identifies the record of the master file (identified in the MFI segment) to be changed.

MFE-5 Primary Key Value Type (CE) 01319
Definition: This field contains the HL7 data type of MFE-4 - Primary Key Value - MFE. Examples: CE Coded Entry, or PL Person location.

A.3 Patient Location Master File

HL7 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.

MFN M05Location Master File Notification
MSH Message Header
MFI Master File Identification
{ MFE Master File Entry
   LOC Location Master
   [LDP]Location Department
   [     ]Other location related segments
}

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|PL
Figure 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 Messages

This part of the whitepaper contains the technical details of HL7 version 3 Master File messages.

B.1 Registry Messages

HL7 version 3 offers support for registries in general, as well as Master File Registries.

UML interaction diagram for a Registry
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:

  • Act Reference Registry (Shared Messages domain/Act Reference topic)
  • Document Registry (Medical Records domain/Document Management topic)
  • Organization Registry (Personnel Management/Organization topic)
  • Patient Registry (Patient Administration domain/Patient topic)
  • Person Registry (Patient Administration domain/Person topic)
  • Provider Registry (Personnel Management/Provider topic)
The general mechanism for the exchange of Registry (and: Master File) interactions is documented in the Master File/Registry Domain.

B.2 Core Registry Classes

This 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).

Registry model for registration requests
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:

  • The RegistrationProcess class represents the "Activity of requesting the registration of a subject". The request activity has a unique identifier.
  • The Author/R_AssignedEntity classes represent the author of the request activity, i.e. the requestor or 'Order Placer'.
  • Subject1/RegisteredRole and Subject2/RegisteredAct (either set of classes has to be present, not both) represent the object that is requested to be added to the registry. The subject is either a Role (e.g. patients, persons, organizations) or an Act (e.g. a laboratory test master file).
    • The RegisteredRole and RegisteredAct classes are "Stubs" (placeholders), they are replaced by more elaborate class models when this genereic class model is used for a specific type of registry.
    • For example: in a Patient Registry, the RegisteredRol class is replaced by a class model (an R-MIM) that contains all of the demographic data of the Patient.

Registry model for registrations
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:

  • The RegistrationProcess class represents the "Activity of registring a subject". The activity has a unique identifier.
  • The Author/R_AssignedEntity classes (associated with the RegistrationProcess class) represent the author of the activity, i.e. the performer of the registration or 'Order Filler'.
  • Subject1/RegisteredRole and Subject2/RegisteredAct (either set of classes has to be present, not both) represent the object that is registered in the registry. The subject is either a Role (e.g. patients, persons, organizations) or an Act (e.g. a laboratory test master file).
  • The Custodian/R_AssignedEntity classes (associated with the RegistrationProcess class) represent the cutsodian of the registration, i.e. the entity responsible of the contents of the registry.
  • The RegistrationProcess2 class represents the original "Activity of requesting the registration of a subject". This class will only be instantiated if the registration was the result of an earlier request activity.
  • The Author/R_AssignedEntity classes (associated with the RegistrationProcess2 class) represent the author of the original request activity, i.e. the requestor or 'Order Placer'.

B.3 Person Registry example

The 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.578.1.34.1000.1" extension="24109642356"
                assigningAuthorityName="F-Number"/>
            <statusCode code="active"/>
            <identifiedPerson>
                <id root="2.16.578.1.34.1000.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.578.1.34.1000.6"
                    displayName="Ugift"/>
                <birthPlace>
                    <addr>
                        <city>Oslo</city>
                    </addr>
                </birthPlace>
            </identifiedPerson>
        </identifiedPerson>
    </subject1>
    <custodian typeCode="CST">
        <assignedEntity classCode="ASSIGNED">
            <id root="2.16.578.1.34.1000.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 bv

Ringholm 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.