“MFMI Discussion paper”
HL7#912
CQ v3
- Version 0.8 –
Status
Date
Editor
:
:
:
Draft
20041104
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/CQ has brought forward some use-cases which
affect the new model for the MFMI domain as presented by this proposal.
2. MFMI Wrapper
Figure 1: MFMI Wrapper
Note to balloters:
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 have been
addressed in this version of the material. Substantive changes include:
 a redefinition include of the REG classcode,
 the use of an associated ActDefinition class instead of the RegistrationProcess.code
attribute to identify the “kind of registry”
 the RegistrationProcess.code attribute has been dropped
2/15/2016
2

the addition of author/custodian partcipactions for the registration
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 is the focal act of the message. It has been included in the
MFMI Trigger Event control Act message type for reasons of convenience only- In modeling
terms, the RegistrationProcess class is part of the message payload, and not part of the
Trigger Event Control Act wrapper. It is effectively a piece of predefined payload that has
been included in a specialized version of the generic 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
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
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 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 Act of this
message. The Act that is fulfilled will be the (original) order to register roles or acts.
2/15/2016
3


subject1: Relates the registration process to the Master File payload information
(represented here by Role) for which it is a Trigger Event Control Act.
subject: Relates the registration process to the Registry payload information
(represented here by Act) 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 the notification.
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 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 an author association to allow the author
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.
DISCUSSION: the base classCode of ROL may lead to misuse. There is a known case where
SubsumesBy is used as a Role classCode. It was probably not the original intent of the
registry wrapper to support this type of Role payload. Do we want to exclude the
RoleClassOntological value set from the set of legal classCode values ?
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 classCode
MFI-2 = Custodian.
MFI-3, MFI-4, MFI-5 = ControlActProcess attributes
MFI-6 = Receiver responsibility related to the interaction
2/15/2016
4
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.0.1. CST participation
This proposal replaces the definition of the CST (Custodian) participationType with the
following: (Accepted on CQ Call 2004-11-01, Greg Sepalla/Louise Brown, 4-0-0) – Acceptance
at harmonization meeting is pending.
“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.). ”
Rationale for the change: the only change is the fact that devices can be custodians. These were not
explicitly listed in the previous definition.
2.1. REG Classcode
In ballots up to ballot 8 there was continuous confusion as to the proper meaning of the REG
classCode. This proposal replaces the definition of the REG classcode with the following:
(Accepted on CQ Call 2004-11-01, Sandra Stuart/Robert Grant, 4-0-0) – Acceptance at
harmonization meeting is pending.
“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
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/15/2016
5