“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