 ANSI/HL7 V3 COMT, R2-2005 HL7 Version 3 Standard: Shared Messages, Release 2 8/11/2005 |
Content Last Edited: 2009-09-09T22:31:58
3.2 Storyboards
3.3 Application Roles
3.4 Trigger Events
3.5 Refined Message Information Models
3.6 Hierarchical Message Descriptions
3.7 Interactions
The registry messages in this domain can be used for registries which contain definitions of acts (i.e. acts in DEF mood). At this point in time no-one has come forward with a use-case for this type of registry.
This introduction section as well as the storyboards are based on another use-case involving Acts in moods other than DEF. This use-case applies to regional, national as well as institutional settings where data is shared between healthcare providers.
All healthcare providers maintain a record of healthcare related data generated under their responsibility within their own systems. The offering of shared healthcare requires the ability to gain access to all healthcare related data, irrespective of the system where the data is stored.
The Act Reference registry contains a minimal set of metadata which supports the retrieval process of healthcare related data by other healthcare providers. The Act Reference registry contains key identifying features (i.e. metadata keys) of healthcare related data as registered by individual healthcare providers. The registry entries can be used by a healthcare provider to gain access to data as present in other providers' systems.
The main benefit of Act Reference registries can be found in environments where multiple providers are involved in the healthcare process of a patient. For example: if one could create a situation where all healthcare providers could share all available data related to the prescription, administration and supply of medication, then this would have major benefits.
In modeling terms the healthcare related data is represented in the registry by its central or focal act, e.g. a SubstanceAdministration act or the CDA header act. The registered acts may be of any class and in any mood. The identifying features of the act include patient, episode of healthcare, author, effective time of the act, act type, act mood and act status.
Healthcare providers will be able to query the registry, or to use a publish-subscribe mechanism to subscribe to new/updated registry entries that conform to certain criteria. For example, a healthcare provider could query the registry for prescription-related entries for patient Patrick Portillo. The Act Reference responds with a series of registry entries. The registry entries identify the authors of the prescriptions. The applications associated with these authors are subsequently queried for the details of the prescriptions.
If an Electronic Health Record (EHR) fulfills the role of Act Reference registry the messages defined in this domain effectively act as an 'index' or 'search engine' front-end. In this case query responses may be generated both on the data as contained in the EHR, as well as on Act References registered by other applications..
|
||||||||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
This storyboard demonstrates adding a new Act Reference to a registry.
The pharmacy department of the Good Health Hospital creates a new substance administration act within its own system. A new Act Reference act is subsequently sent to an Act Reference registry in order to make other providers aware of the existence of the act in the pharmacy system.
This storyboard demonstrates deleting an Act Reference from a registry.
The laboratory department of the Good Health Hospital creates a new observation act within its own system. A new Act Reference act is subsequently sent to an Act Reference registry in order to make other providers aware of the existence of the act in the laboratory system. Later that day the system administrator learns that the data-entry was erroneous, so a message is sent to other systems nullifying the erroneous entry.
This storyboard describes the process of querying an Act Reference registry
| Find Act Reference Registry Entries, Query |  QUMT_IN020010UV01 |
| Find Act Reference Registry Entries, Response | QUMT_IN020020UV01 |
Patrick Portillo is admitted to the Accident & Emergency department of the Good Health Hospital. Eric Emergency, the physician on duty, notices that the patient is unable to communicate. Eric determines that access to care related data created by other providers is required prior to the provision of care to this patient. He therefore starts a query module in his HIS system and selects the patient. The query module allows for the query to be refined using selection criteria. In this case Gerald specifies that he wants to see all entries in the Act Reference registry related to Patrick Portillo that were created during the last 6 months. Eric's HIS sends the query to the Act Reference registry (Find Act Reference Registry Entries).
The Act Reference registry looks at the details of the query and locates those registry entries that match the search parameters as specified in the query. The registry entries are sent to the HIS system in response to the query (Find Act Reference Registry Entries, Response).
The HIS displays the metadata associated with the various entries to Eric in the form of an index. Eric selects a discharge summary and a prescription from the index. The author of these Act Reference registry entries is known within the HIS system. The HIS sends queries (as defined in the Pharmacy and other HL7 domains) to the systems associated with the known authors of the discharge summary and the prescription. The responses to these queries are shown on the screen of Eric Emergency.
This storyboard demonstrates revising an Act Reference in a registry.
Gerald Gopherman, a GP, changes the state of an appointment act within its own system. A revised Act Reference act is subsequently sent to an Act Reference registry in order to make other providers aware of the updated act as available in the GP system.
|
||||||||||||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
An Act Reference Revision Informer sends a single message -- that either the Act Reference itself has changed, or its registration status.
An Act Reference Activation Informer sends a single message -- that a new Act Reference should be registered.
An Act Reference Nullification Informer sends a single message -- that the registration of an Act Reference was erroneous and should be deleted.
An Act Reference Comprehensive Informer sends all notification messages related to Act Reference registrations.
An Act Reference Comprehensive Tracker receives all notification messages related to Act Reference registrations.
An Act Reference Registry Query Placer initiates queries with Act Reference registries
An Act Reference Registry Query Filler responds to queries sent to Act Reference registries
|
||||||||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Type: | State-transition based |
| State Transition: | ActReference (MFMT_RM002000UV01) |
The Add Act Reference trigger event signals that a new Act Reference was added to an act registry.
| Type: | State-transition based |
| State Transition: | ActReference (MFMT_RM002000UV01) |
The Delete Act Reference trigger event signals that information about an Act Reference was deleted from an act registry.
| Type: | State-transition based |
| State Transition: | ActReference (MFMT_RM002000UV01) |
The Revise Act Reference trigger event signals that information about an Act Reference was revised in an act registry.
| Type: |
The Act Reference Registry Get Entries requests all registry entries that match the criteria as specified by the query parameters
| Type: |
The Act Reference Registry Get Entries Response returns the list of registry entries that match the parameters as defined in the Query
|
||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | Shared Interactions (COMT_DM000001UV) |
This model captures the data and associations that are needed to capture summary versions of Acts. The application that authored the Act stores the summary version in a centralized Act registry. This allows other applications to retrieve information about the existence of acts, their status, their author, and the application where a fully detailed version of the Act can be found. A detailed description of the use-case can be found in the Storyboard section.
It is expected that only certain acts will be registered in the registry. Typical examples include the Focal Classes of payload message types as well as the CDA header act. The registered acts may be of any class and in any mood.
In interactions that add/nullify/revise acts in the Act registry, the ActReference class serves as payload within the Master File / Registry Control Act. In the interaction which is used to respond to queries to the Act registry, the ActReference class serves as payload within the Master File/Registry Query Response Control Act.
The RegistrationProcess.code attribute in the Master File/Registry Control Acts plays a key part in identifying both the registry-type as well as the act-type. The related ActRegistryCode vocabulary domain is based on document types (as used by CDA documents) and other categorizations of acts.
The base class is ActReference based on the Act class. This is a clone name of the D-MIM base class, ActGenericReference.
The following attributes are contained in the ActReference act:
-
id: A unique identifier for the Act. The ActReference act is often regarded by humans as a reference to (or a summary version of) another act. In modeling terms this is not true: the act and its ActReference version share the exact same identifier; they are one and the same object. The id of the ActReference class is always the same as the id of the act it references. This is a mandatory attribute.
-
classCode: The classCode as contained in the act identified by the id attribute.
-
moodCode: The moodCode as contained in the act identified by the id attribute.
-
Other attributes: These attributes are equal to the corresponding attributes in the act identified by the id attribute
The following associations are defined for a ActReference act:
-
recordTarget: The medical record that this document belongs to, i.e. the patient. Patient information is specified with the R_Patient CMET. Note: This association is mandatory in initial notification messages.
-
author: There are one to many parties recorded as author for an Act. The author of any act is the person who, or organizational entity that, takes responsibility for its creation. It is generally assumed that only a single author is allowed. The actual party involved is specified in the R_AssignedEntity CMET. Note: This association is mandatory in initial notification messages.
Implementation note/XML ITS: Message Types used in interactions that add/nullify/revise acts in the Act Reference registry are typically produced by applying an XSLT to either the CDA document or a Message Type which contains the fully detailed original Act.
Examples:
-
a prescription message (as defined by the Pharmacy HL7 domain) is sent to a pharmacy application; and the Act Reference version of its focal act to an Act Reference registry.
-
a CDA document is created and sent to a general practitioner (GP) application; and the Act Reference version of its document header act to an Act Reference registry.
| Act Reference | MFMT_HD002000UV01 |
| Parent: | Shared Interactions (COMT_DM000001UV) |
The QueryByParameter class and related classes capture information related to queries sent to an Act Reference Registry. You are referred to the Query Infrastructure domain for a description of the QueryByParameter and SortControl classes.
QueryByParameter has a number of associated ParameterItem classes:
-
PatientId: Identifies the recordTarget for which Acts are requested. All identifiers listed in this class are related to one specific patient.
-
RegistrationprocessActCode: The Act category (a code taken from the ActRegistryCode domain) of the registrations of requested Acts should be one of the codes specified by this parameter value. This parameter identifies what acts should be included in the response.
-
EffectiveTime: The effective time of the requested Acts should fall within the time interval specified by this parameter value.
-
AuthorId: The Author of the requested Acts should equal one of the authors identified by this parameter value.
-
StatusCode: The statusCode of the requested Acts should be one of the statuscodes specified in this parameter value.
-
AuthorRoleCode: The roleCode of the Author. This allows for registry queries to be based on generic role codes (e.g. 'Pharmacists') instead of specific authors.
-
ActId: The ID of the requested Act. If the ID of the requested Act is known none of the other parameters need to have a value.
| Act Reference Query | QUMT_HD020020UV01 |
|
||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
The ActReference act class captures summary versions of acts that 'exist' within other applications. There are 2 message types; one with optonal participations and one with required participations.
| R_Patient | COCT_MT050000UV01 |
| R_AssignedEntity | COCT_MT090000UV01 |
| Act Reference Optional Participations | MFMT_MT002001UV01 | |
| Act Reference Required Participations | MFMT_MT002002UV01 | |
| Act Reference Registry Find Acts | QUMT_MT020020UV01 | |
|
||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
This interaction supports the initial registration of acts in the registry.
| Trigger Event | Add Act Reference | MFMT_TE002101UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg. Notif Control Act, Act Subject | MFMI_MT700702UV01 |
| Message Type | Act Reference Required Participations | MFMT_MT002002UV01 |
| Sender | Act Reference Activation Request Placer | MFMT_AR002001UV01 |
| Receiver | Act Reference Comprehensive Request Fulfiller | MFMT_AR002005UV01 |
This interaction when an erroneously entered Act Reference is deleted from the act registry.
| Trigger Event | Delete Act Reference | MFMT_TE002103UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg. Notif Control Act, Act Subject | MFMI_MT700702UV01 |
| Message Type | Act Reference Optional Participations | MFMT_MT002001UV01 |
| Sender | Act Reference Nullification Request Placer | MFMT_AR002003UV01 |
| Receiver | Act Reference Comprehensive Request Fulfiller | MFMT_AR002005UV01 |
This interaction supports the registration of modifications of Act References. The act itself, any of its associated classes, or its registration status may have changed.
| Trigger Event | Revise Act Reference | MFMT_TE002102UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg. Notif Control Act, Act Subject | MFMI_MT700702UV01 |
| Message Type | Act Reference Optional Participations | MFMT_MT002001UV01 |
| Sender | Act Reference Revision Request Placer | MFMT_AR002002UV01 |
| Receiver | Act Reference Comprehensive Request Fulfiller | MFMT_AR002005UV01 |
This interaction supports the process of querying an Act Reference for any registry entries that match the parameters as specified in the query.
| Trigger Event | Act Reference Registry Get Entries | QUMT_TE020010UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Reason | Trigger Event | Interaction |
| Find Act Reference Registry Entries, Response | QUMT_IN020020UV01 |
| Sender | Act Reference Registry Query Placer | QUMT_AR020001UV01 |
| Receiver | Act Reference Registry Query Fulfiller | QUMT_AR020002UV01 |
This interaction supports the process of responding to Act Reference registry queries.
| Trigger Event | Act Reference Registry Get Entries, Response | QUMT_TE020020UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Sender | Act Reference Registry Query Fulfiller | QUMT_AR020002UV01 |
| Receiver | Act Reference Registry Query Placer | QUMT_AR020001UV01 |
| Return to top of page |