 ANSI/HL7 V3 MFRI, R1-2006 (R2011) HL7 Version 3 Standard: Master File - Registry Infrastructure, Release 1 (reaffirmation of ANSI/HL7 V3 MFRI, R1-2006) 10/12/2011 |
Content Last Edited: 2006-03-09T12:57:31
2.2 Storyboards
2.3 Application Roles
2.4 Trigger Events
2.5 Refined Message Information Models
2.6 Hierarchical Message Descriptions
This domain discusses the Master File / Registry infrastructure. Refer to the appropriate domain for their Master File / Registry artifacts.
|
||||||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
The above figure represents the interaction exchange patterns used by registries. The Master File / Registry domain does not define any interactions itself; this is up to other HL7 domains. The subsequent sections describe the most commonly used 3 interaction exchange patterns.
This storyboard describes interaction pattern A as contained in the interaction diagram.
A registry may notify other systems of changes or updates. These may be "real time" notifications, or batch releases. The Registry sends one or more Registration Records to a Tracking application. The trigger event may be based on a status change of a registration (e.g. the creation of a new registration), or on the simple fact that a timer has expired (e.g. send all registry entries at 04:00 every Wednesday). Registry Notifications are based on the MFMI_RM700700 Trigger Event Control Act.
The notification interaction may have receiver responsibilities associated with it in the form of an application response to indicate acceptance of the contents of the notification.
Not every system at every site will need all the fields contained in notification message. This also means that an application response from a receiving system that it accepted the notification 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 notification message with the same primary key can be applied unambiguously to that subset of information. Application Responses to Registry Notifications can be defined as the Act Generic Status - Event (COMT_IN001103) interaction as defined in the Shared Messages domain.
Version 2 mapping: MFN message, followed by an optional MFK.
This storyboard describes interaction pattern B as contained in the interaction diagram.
An application not "owning" a particular master file, transmits update requests (e.g. add, update, merge, unmerge, unlink, and link) or replacement requests to the "owning" system, for review and possible inclusion. Prior to the actual update request a query may (optionally) be used to retrieve the latest information. 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. This information is subsequently used as a basis for the update process. This part of the interaction pattern is typically used in those cases where updates are done interactively by a user.Registries receive data (in the form of update and replace requests) from multiple sources, and need to document the sources of any changes to the records in the registries that they manage. Registration Requests are based on the MFMI_RM700720 Trigger Event Control Act.
The request interaction always has a receiver responsibility attached to it in the form of an application response. In the case of an accept, the interaction contains the registry entry created as the result of the request; in the case of a reject, it contains the identification of the registration request being rejected.
An application response 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. Application Responses to Registration Requests are based on the MFMI_RM700700 Trigger Event Control Act.
Version 2 mapping: none. MFN messages are occasionally "misused" as request messages; there are, however, no registration request trigger events in HL7 version 2.
This storyboard describes interaction pattern C as contained in the interaction diagram.
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. A Query interaction is responded to by one or more response interactions. Response interactions are based on the MFMI_RM700710 Trigger Event Control Act.
Queries may be based on attribute values of the Registration (e.g. registration ID, registration status) or on attribute values of the registration subjects (e.g. role ID, person name). A query based on attribute values of the registered subject will ensure that the information of the latest registration is returned, even if registrations for the subject have been replaced multiple times.
Version 2 mapping: MFQ message, followed by a MFR response.
|
||||||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
This domain discusses the Master Files infrastructure. Refer to the appropriate domain for their Master File / Registry application roles. The roles listed here are for example/publication purposes.
This is an application role example of a requester of Master Files / Registry registrations. This Application Role sends registration requests to registries.
This is an application role example of a Query Placer of Master Files / Registry registrations. This Application Role sends queries related to registrations to registries.
This is an application role example of a tracker of Master Files / Registry acts.
This is an application role example of a manager of Master Files / Registry acts. This Application Role sends notifications, responds to queries and fulfills registration requests.
|
||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Type: |
This domain does not define trigger events, this trigger event has been defined for example purposes only.
This example represents trigger events based on the receipt of a query interaction.
| Type: | State-transition based |
| State Transition: | Registry Act (MFMI_RM700700UV01) |
This domain does not define trigger events, this trigger event has been defined for example purposes only
This example represents trigger events based on state transitions of the Registry Act: Examples include: null to active (create), active to active (revise), obsolete (replace), and nullified (nullification). These state transitions may occur in Registry Acts irrespective of the mood of the Registry Act (which is mostly used in request or event mood).
|
||||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | Master File / Registry Infrastructure (MFMI_DM700700UV) |
This is the entry point for the Master File / Registry Trigger Event Control Act RMIM used to request a (replacement of a) registration.
The base class is RegistrationRequest based on the Act class. RegistrationRequest is a clone of the RegistrationProcess base class of the D-MIM. Refer to the Master File / Registry Infrastructure D-MIM Walkthrough for details of the classes of the D-MIM. The R-MIM is equal to the D-MIM, except for the following attributes/associations:
- subject: The cardinality of the subject act-relationship (between ControlActProcess and RegistrationRequest) has been constrained to 1..1. There is a known open issue related the acknowledgement of individual registration requests contained within master file messages. This Order-related issue is not limited to the registry domain. The cardinality will be set to 1..* again once a solution has been found.
- author: The identification of the Author of the registration request is mandatory (as opposed to being optional in the D-MIM). The participation has a 1..1 cardinality.
- custodian: The custodian is not present in this R-MIM. Registration requests do not have a Custodian, any resulting registrations will have a Custodian.
- replacementOf / PriorRegistration: optional Act Relationship between a new Registration Request and a Prior Registration. If a Prior Registration is identified in a message instance, its status will be set to obsolete by the receiver of the message. PriorRegistration is a clone of the RegistrationProcess base class of the D-MIM. Note for Role-based registries: The use, and identification of, the PriorRegisteredRole is mandatory in those cases where the ID of the Prior Registration is unknown. Note for Act-based registries: The use, and identification of, the PriorRegisteredAct is mandatory in those cases where the ID of the Prior Registration is unknown.
- statusCode: Contains the status of the Registration Request. In request messages its value will typically be 'active', which is also the default value. This attribute is Mandatory (as opposed to Required in the D-MIM).
- subject1/subject2: the cardinality of this association/participation is 0..1 (as opposed to 0..* in the D-MIM). There are no known use-cases for registrations of multiple entries.
Please refer to the Storyboard section for a description of Registry related interaction patterns.
| Master File / Registry Request Control Act | MFMI_HD700720UV01 |
| Parent: | Master File / Registry Infrastructure (MFMI_DM700700UV) |
This is the entry point for the Master File / Registry Trigger Event Control Act RMIM used for reporting about Regsitrations in event mood. This includes Master File Notification interactions and Registry Notifications caused by state changes in registrations, as well as responses to Registration Requests or Registration replacement Requests.
The base class is RegistrationEvent based on the Act class. RegistrationEvent is a clone of the RegistrationProcess base class of the D-MIM. Refer to the Master File / Registry Infrastructure D-MIM Walkthrough for details of the classes of the D-MIM. The R-MIM is equal to the D-MIM, except for the following attributes/associations:
- subject: The cardinality of the subject act-relationship (between ControlActProcess and RegistrationRequest) has been constrained to 1..* (as opposed to 0..* in the D-MIM).
- custodian: identification of the Custodian of the registration is mandatory (as opposed to being optional in the D-MIM). The participation has a 1..1 cardinality.
- infulFillmentOf / RegistrationRequest: optional Act Relationship between a new Registration and a Prior Registration Request. RegistrationRequest is a clone of the RegistrationProcess base class of the D-MIM.
- replacementOf / PriorRegistration: optional Act Relationship between a new Registration Request and a Prior Registration. If a Prior Registration is identified in a message instance, its status will be obsolete. PriorRegistration is a clone of the RegistrationProcess base class of the D-MIM. Note for Role-based registries: The use, and identification of, the PriorRegisteredRole is mandatory in those cases where the ID of the Prior Registration is unknown. Note for Act-based registries: The use, and identification of, the PriorRegisteredAct is mandatory in those cases where the ID of the Prior Registration is unknown.
- statusCode: Contains the status of the Registration Request. In request messages its value will typically be 'active', which is also the default value. This attribute is Mandatory (as opposed to Required in the D-MIM).
- subject1/subject2: the cardinality of this association/participation is 0..1 (as opposed to 0..* in the D-MIM). There are no known use-cases for registrations of multiple entries.
Please refer to the Storyboard section for a description of Registry related interaction patterns.
| Master File / Registry Event Notification | MFMI_HD700700UV01 |
| Parent: | Master File / Registry Infrastructure (MFMI_DM700700UV) |
This is the entry point for the Master File / Registry Trigger Event Control Act RMIM used for responses to a registry query.
Queries are specific to a domain. Examples may include a query for the registration status of a patient, a query for provider details based on a provider id and a query for the act-based definition of a specific Radiology examination.
This R-MIM is only used in interactions created by a Registry in response to a query. Please refer to the Storyboard section for a description of Registry related interaction patterns.
The base class is RegistrationEvent based on the Act class. RegistrationEvent is a clone of the RegistrationProcess base class of the D-MIM. Refer to the Master File / Registry Infrastructure D-MIM Walkthrough for details of the classes of the D-MIM.
This R-MIM is equal to the Master File / Registry Trigger Event Control Act R-MIM (See Master File / Registry Trigger Event Control Act RMIM for details of this R-MIM) except for the following attributes/associations:
- The QueryByParameter and QueryAck query classes have been added. Refer to the Query Infrastructure D-MIM for details on these Query-related classes.
- subject: The cardinality of the subject act-relationship (between ControlActProcess and RegistrationRequest) is set to 0..*. The response to a query may contain zero or more matching registrations.
| Master File / Registry Query Response | MFMI_HD700710UV01 |
|
||||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
| R_AssignedEntity | COCT_MT090003UV01 |
| R_AssignedPerson | COCT_MT090100UV01 |
| R_AssignedDevice | COCT_MT090300UV01 |
| A_DetectedIssue | MCAI_MT900001UV01 |
| Master File / Reg Request Control Act,Role Subject | MFMI_MT700721UV01 |  |
| Master File / Reg Request Control Act,Act Subject | MFMI_MT700722UV01 | |
Master File / Registry Event Notification
| R_AssignedEntity | COCT_MT090003UV01 |
| R_AssignedPerson | COCT_MT090100UV01 |
| R_AssignedDevice | COCT_MT090300UV01 |
| A_DetectedIssue | MCAI_MT900001UV01 |
| Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 | |
| Master File / Reg. Notif Control Act, Act Subject | MFMI_MT700702UV01 | |
The Master File / Registry should be used by Master File / Registry Query Response messages that have a Role as a payload entry point and it can be used by Master File / Registry Query Response messages that have an Act as a payload entry point if,next to the Act itself, information related to the Registration of the Act needs to be contained in the response (e.g. RegistrationProcess.statusCode, RegistrationProcess.code, RegistrationProcess.effectiveTime).
| R_AssignedEntity | COCT_MT090003UV01 |
| R_AssignedPerson | COCT_MT090100UV01 |
| R_AssignedDevice | COCT_MT090300UV01 |
| A_DetectedIssue | MCAI_MT900001UV01 |
| Master File / Registry Query Response,Role Subject | MFMI_MT700711UV01 | |
| Master File / Registry Query Response, Act Subject | MFMI_MT700712UV01 | |
| Return to top of page |