Product Brief - Master File - Registry Infrastructure
Master File - Registry Infrastructure
- Master File - Registry Topic
- Health Information Exchange Standards
Normative, ANSI Standard
ANSI/HL7 V3 MFRI, R1-2006; HL7 MFRI, R2
HL7 Version 3 Standard: Master File - Registry Infrastructure, Release 2
Last Ballot: DSTU Ballot 1 - September 2008
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 addresses the communications environment that is considered common to all HL7 Version 3 messaging implementations. It covers the Transmission wrapper as well as the transmission interaction patterns.
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.
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).
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.
Business Case (Intended Use, Customers)
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.
- See more at http://www.hl7.org/implement/training.cfm