“MFMI Discussion paper”
HL7#912
CQ v3
- Version 0.5 –
Status
Date
Author
:
:
:
Draft
20041023
René Spronk, HL7 Netherlands, rene.spronk@ringholm.nl
The contents of this document have been placed in the public domain. Note that the images
in this document are based on HL7 Artifacts, these are © HL7 Inc.
1. Introduction
The MFMI domain was pulled from the IM domain (after ballot cycle 8) because of persistent
discussion of some open issues of a fundamental nature. These include the nature of the REG
classcode, the use of RegistrationProcess.code to identify the “kind of registry”, as well as the
lack of author/custodian for the registration.
The creation of a registry project by PA/PM has brought forward some use-cases which effect the
new model for the MFMI domain as presented by this proposal.
2. MFMI Wrapper
Figure 1: MFMI Wrapper
The text below contains an updated walkthrough of the MFMI D-MIM. This part has been
edited using the change-tracking features of Word to highlight the changes with respect to
the text of the walkthrough as present in ballot 8.
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 Actto be associated with the
domain-defined Master File entry stub (as AssignedEntity) or (xor) Registry domain-defined
entry point stub (as Act).
2/16/2016
2
Note: The RegistrationProcess is the focal act of the message. It has been included in the
Trigger Event control Act message type for reasons of convenience only, Strictly taken, it is
not part of the Trigger Event Control Act wrapper. Trigger Events are caused by 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. This attribute is optional. Version 2 mapping:
MFE-2
code: A code specifying the kind of Registration Act.(optional)
OPEN ISSUE: Do we need an ActClass vocabulary to distinguish between different kinds
of registration acts ? This is an optional attribute. Any ActClass codes are NOT related to
the kind of subject payload !


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. (required) Version 2 mapping: MFE-1
effectiveTime An interval of time specifying the operative time of the Registration.
(required) Version 2 mapping: MFE-3
Version 2 mapping: In version 2, a given master files message concerns only a single
master file. However, the provision of a record-level event code (and requested activation
date) on the MFE and the MFA segments allows a single message to contain several types of
changes (events) to that file. The Version 3 model allows for changes to multiple master
files, with multiple payloads. The closest equivalent for the RegistrationProcess class is the
MFE segment (with the identifier of the master file added to it, in RegistrationProcess.code).
MFI-1 = ActDefinition, subject Act/Role classCodeMFI-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
2/16/2016
3
Act
This class represents the stub of a domain-defined Master File / Registry payload message
type that is instantiated for the notification.
ActDefinition
This class identifies the kind of payload that is undergoing registration; this is directly related
to the kind of Registry. The code attribute of this class is required and constrained by the
ActRegistryCode domain. 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
RegistrationRequest
This class represents the original registration request. If the RegistrationProcess fulfills a
registration request then the original identification request is represented by the
RegistrationRequest class. RegistrationRequest has a custodian association to allow the
custodian of the registration request to be identified.
Role
This class represents the stub of a domain-defined Master File / Registry payload message
type that is instantiated for the notification.
Participations and Act Relationships
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 author will mostly (but not always) be the same as the custodian.
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 performing an act. Note that
the custodian of a Registration Act in request (RQO) mood is the entity responsible
for the registration requests and subsequent updates (the custodian ‘owns’ the
registered data), whereas 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.
DISCUSSION: This proposal regards the custodian of a “request to register” as the owner
of the subject payload. This proposal regards the custodian in any message sent by a
registry to be the party responsible for the registry contents (i.e. not the original owner).
This is a rather fundamental modeling decision. If one sends a query to a registry, then
the response will have the party responsible for the registry application in
RegistrationProcess.custodian, and the owner of the data in
RegistrationProcess.infullFillmentOf.custodian.
Lloyd argued in Atlanta that one only needs an author when registering a payload.
2/16/2016
4
Custodian should only be used for thos managing the registry. What if one has multiple
(conflicting) sourced of data related to 1 object ?




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 Act of this
message. The Act that is fulfilled will be the (original) order to register roles or acts.
subject: Relates the registration process to the Master File payload information
(represented here by AssignedEntity) for which it is a Trigger Event Control Act.
subject1: Relates the registration process to the Registry payload information
(represented here by Act) for which it is a Trigger Event Control Act.
2.0.1. CST participation
This proposal aims to replace the definition of the CST (Custodian) participationType with the
following:
“An entity (person, organization or device) that is in charge of maintaining the information of
this service object (e.g., who maintains the report or the master service catalog item, etc.).
”
Note: the only change is the fact that devices can be custodians. These were not explicitly listed in the
previous definition. (For the record: Lloyd McKenzie agrees with this approach)
2.1. REG Classcode
In ballots up to ballot 8 there was continuous confusion as to the proper meaning of the REG and
CACT classCodes.
In ballot 8, the description of the REG act class is as follows (from the ActClass vocabulary):
“Represents the act of maintaining information about an entity or role in a registry. The class is
most general, designed to support a variety of registries for persons, patients, practitioners,
equipment, etc. If required, specific registry types will be treated as specializations of this class.“
The control act is defined as follows: “An act representing a system action such as the change of
state of another act or the initiation of a query. All control acts represent trigger events in the
HL7 context. ControlActs may occur in different moods.”
In order to avoid confusion, the description of REG should be changed so it will be clear that
REG is not a specialization of CACT, but an entirely different concept.
2.1.1. REG class definition
This proposal aims to replace the definition of the REG classcode with the following:
“REG: 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 subjects such as lab
2/16/2016
5
exam definitions, drug protocol definitions, prescriptions, persons, patients, practitioners, and
equipment.
Usage notes:
This class is intended for use where there is an interest in tracking 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. See the MFMI Masterfile/Registry
Control Act wrapper for an example.”
2/16/2016
6