| |
| HDR Version 7 HL7 Version 3 Messaging Conformance Specification |
This section contains the following topics:
1.1 IntroductionOracle Healthcare Data Repository (HDR) is a comprehensive data repository and service infrastructure that supports the development of robust and scalable healthcare applications. It consists of software components that centralize and consolidate patient, provider, payor and clinical objects and business rules across the healthcare enterprise, providing unified access to a comprehensive healthcare IT infrastructure. HDR leverages Oracle’s database expertise to create a high performance repository based upon the Health Level Seven (HL7) Version 3 (V3) Reference Information Model (RIM).
HL7 is an ANSI-accredited Standards Developing Organization operating in the healthcare arena. HL7 V3 is a standard for exchanging messages among information systems that implement healthcare applications.
Support for HL7 V3 messaging between HDR and a wide variety of administrative, clinical and financial systems is a critical component of the Oracle Healthcare strategy.
Since the V3 standard is currently in the consensus development process, Oracle is working with HL7 committees to develop ballot content. As an early adopter, Oracle has also worked to develop RMIMs and other artifacts in areas not yet explored by HL7. This set of artifacts, along with this document, is referred to as the HDR HL7 V3 Conformance Specification. It describes all the structures, content and rules required for an HL7 V3 interface to communicate with HDR. Currently HDR only supports the exchange of HL7 V3 messages in XML format.
HL7 documentation and tutorial information are referenced throughout this document, although it was not possible to include specific references in every case, due to changes with each new ballot of the V3 standard. In general, you can find such referenced materials at the HL7 Web site, and the HL7 v3 current ballot Web site is a particularly useful reference. HL7 Web site and HL7 V3 ballots are the properties of Health Level Seven Inc and access to these information may require HL7 membership.
This document presumes familiarity with the HL7 V3 RIM and with the XML Implementation Technology Specification (ITS). For further information about HL7, HL7 V3, the RIM, HL7 V3 Methodology, HL7 V3 Tooling, or the XML ITS, refer to the HL7 Web site.
The artifacts produced during message development such as RMIMs, HMDs, XSDs and MIFs provide most of the information necessary to create conformant messages. However, these artifacts by themselves often cannot provide important guidance such as the semantics of certain message elements when used in a particular message domain. The purpose of this document is to provide a comprehensive human readable description of messaging artifacts in the context of the healthcare domain they serve. HDR conformance documentation can be used by healthcare organizations to achieve two principal objectives:
HDR conformance is currently based upon an enhanced version 2.14.1 of the HL7 V3 RIM. This means that both the HDR repository and the HDR V3 messaging interface are designed to understand only those classes, attributes, datatypes, associations, vocabulary, and state machines that are specified in this version of the RIM. This version of the RIM has been designated 2.14.1.01 by Oracle.
Subsequent to RIM 2.14.1, newer versions were released by HL7 and changes will continue to occur until the V3 standard is released. These details should be taken into consideration when communicating with any HL7 Committee member who is not also part of the Oracle Healthcare group.
The following is the list of HL7 V3 Message Development Artifacts that complement the content of this conformance documentation:
1.3.1 Refined Message Information Models (RMIMs)
1.3.2 Hierarchical Message Descriptions (HMDs)
1.3.3 XML Schema Definitions (XSDs)
1.3.4 Model Interchange Format (MIFs)
1.3.5 Composite Message Schemas
1.3.6 Interactions
1.3.7 Trigger Events
1.3.8 Focal Class State Machines
1.3.9 Vocabulary Specification
These artifacts should be used in conjunction with this documentation to complete the implementation of an HDR conformant HL7 V3 messaging interface.
As the first step, in message definition, RIM classes are assembled into a graph representing the content and relationships within the message domain. This graph of RIM classes is called a Refined Message Information Model or RMIM. The RIM classes that are used in an RMIM may be given alias names specific to the perspective of the message domain. Various constraints to the RIM can be expressed in an RMIM to represent the domain requirements.
These include constraints to:
RMIM diagramming conventions do not allow for the formal representation of certain constraints such as validations involving multiple message elements. Therefore, it is important for implementers to consider the informative content included in this document for additional rules governing each message.
RMIMs serve both as graphical representations of message structure and as input to further tooling steps that produce HMDs, XSDs and MIFs. The RMIMs accompanying this specification were all created in Microsoft Visio 2002 (Microsoft Visio 2002 is the property of Microsoft Corporation) using templates and tooling published by HL7. There are RMIM and Visio tutorials available through the HL7 Web site. Visio diagrams for the various message components are located in the RMIM sub-directory within each message domain area of the companion HDR HL7 V3 Artifacts. These diagrams have also been exported as GIF images to enable viewing in a browser. There are three basic kinds of RMIMs:
RMIMs from each of these categories are described in considerable detail in section 3, 4 and 5. For detailed descriptions of Wrapper RMIMs refer to Section 3. For detailed descriptions of all the message RMIMs of different domains, Interactions, state Transition Diagrams and Trigger Events, that are supported by HDR, refer to Section 4. For detailed descriptions of CMET RMIMs, refer to Section 5.
The Hierarchical Message Description (HMD) is a serialized version of the RMIM. It is derived from the RMIM by walking through its classes and their associations in a predetermined fashion. The HMDs included with this conformance specification are in the form of Microsoft Excel (Microsoft Excel is the property of Microsoft Corporation) spreadsheets.
In the HL7 methodology, it is possible to create specific message types by imposing further constraints on the individual elements of an HMD. The unconstrained default message type is called the Common Message Type. In HDR message artifacts, no constraints are applied at the level of the HMD. Therefore, only the Common Message Type is present per HMD.
The spreadsheet version of an HMD includes a list of all message elements, their sequence, data types, cardinality, optionality, vocabulary, etc. Knowledge of the V3 RIM and V3 message structure is necessary to fully understand the content of an HMD. The technical implementer of XML messages typically uses the XSD instead of the HMD spreadsheet. The HMD allows for those unfamiliar with XML to identify element and attribute tags, and view the expected order of the tags in a message instance. HMD spreadsheets can be found in the HMD sub-directory within each message domain area of the companion HDR HL7 V3 Artifacts.
RMIMs, HMDs and Message Types are all abstract descriptions of message structure that are implementation neutral. In order to facilitate implementation of messages using XML, message types are expressed as XML Schema Definitions (XSD).
The XSD of a message type defines the machine readable XML syntax that must be followed by a conformant message. Implementers can validate message instances against corresponding XSDs to determine if they are valid. The outbound message processor uses XSDs to construct messages in the correct format using data from the repository.
XSDs cannot enforce all the constraints expressed in a RMIM, for instance vocabulary constraints involving coded datatypes such as CD, or CE, or constraints that are only expressed as comments. The sending application or interface engine must enforce such constraints as described in the RMIMs and this document.
For more information about the XSDs published in this release, refer to Appendix A of this document.
MIF stands for Model Interchange Format. It is a set of inter-related schemas that define the set of primary artifacts that may be developed or exchanged as part of the HL7 version 3 development status.
The MIF defines a series of elements, attributes, complex types, simple types, element groups and attribute groups. These combine to describe all HL7 v3 artifacts. The elements which are defined at the ‘root’ level are legal elements to transmit within a MIF file. (Elements lower than this cannot be independently validated and should not be placed in MIF files on their own.)
The MIF makes use of schema constructs including simple type patterns, the use of choice and sequence structures as well as cardinality and attribute use to reflect HL7 requirements as tightly as possible.
All messages published as part of HDR Version 7 have their meta data present in MIF files. HDR's Inbound Message Processor and the Outbound Message Processor uses this meta-data to process and generate messages respectively.
Following HL7, HDR Version 7 introduces and supports Composite Message Schema (CMS) also known as Interaction Schemas.
A CMS has three parts: Message Wrapper, Control Act Wrapper, and Payload Reference
A CMS references and loads only one payload schema for a particular message type allowing messages to be processed quickly. The number of CMSs to be generated for a Message Type is directly proportional to the number of Interactions available for it. Each CMS is identified by an InteractionId and the name of the CMS will match the InteractionId.
The HL7 V3 Guide defines an Interaction as:
Interactions are at the heart of messaging. The formal definition of an interaction as per the HL7 V3 Guide is:
A unique association between a specific message type (information transfer), a particular trigger event that initiates or "triggers" the transfer, and the application roles that send and receive the message type. It is a unique, one-way transfer of information.
HDR Version 7 messaging functionality is entirely dependent upon interactions. InteractionId is a mandatory attribute in the Message Wrapper and is used to identify the CMS. The following information needs to be configured for every new Message Type.
In HDR conformance, each message domain is associated with a set of interactions. Each interaction is described by an identifier that corresponds to the list mentioned above. The list of interactions supported by HDR is extensible.
Interactions are central to the HDR messaging strategy. Side effect configuration and the composition of messages (the right combination of Message Wrapper, Control Wrapper, and Domain Message Type) are all based on Interactions.
Refer to the respective message domains under Section 4 Message Domains of this document for a list of Interactions and their associated trigger events, Message Wrappers, Control Wrappers, and Domain Message Types.
A trigger event is an explicit set of conditions that initiate the transfer of information between system components. It is typically a real-world event such as the placement of a laboratory order or admission of a Patient. The trigger event must be systematically recognizable by an automated system.
All HDR conformant messages, except the Clinical Trial Laboratory Observation Periodic Report message, are designed to communicate trigger events that involve some state transition in the RMIM’s focal class. For example, the Encounter Event domain includes trigger events for a Patient admission (Encounter.statusCode goes from null or new to active) and a Patient leave of absence (Encounter.statusCode goes from active to suspended). Revisions of objects that may not involve a change in the value of the statusCode are also considered state transitions. For example, a completed encounter may be revised with information after the Patient is discharged.
In HDR conformance, each message domain is associated with a fixed set of trigger events. Each trigger event is described by an identifier, a human readable name, and one or more state transition. The list of trigger events supported by HDR in this release is extensible. The trigger events are currently defined in the HDR Supplemental coding scheme.
The set of trigger events that have been identified for a particular domain reflect the real world business activities that the design of the message supports. Each trigger event is associated with explicit state transition(s) of the focal class. The set of state transitions that are legal for a message domain are therefore fixed by the set of supported trigger events. This set is called the state machine of the focal class. A single trigger event may correspond to more than one such transition, with the caveat that the target status is the same in all these transitions.
State machines are represented graphically using directed graphs called state diagrams or in tabular format using state transition tables.
The focal class of a message domain RMIM is an Act in most cases, but may be a Role (Staff Registration, Person Merge, Person Unmerge) or an Entity (Person Registration - This would still require a role to identify this entity, though it may be called as an Entity Focal Class). The HL7 V3 RIM specifies the universe of states and transitions that are valid for an Act, a Role and an Entity. All focal class state machines defined in this specification are purely restrictions of the RIM allowed set of state transitions. Refer to the respective message domains under Section 4 – Message Domains of this document for a list of trigger events and associated state transitions.
The vocabulary specification for a coded attribute may be in the form of a single fixed value (value constraint) or default value documented at the end of each RMIM description, or in the form of a vocabulary domain documented in the RMIM diagram.
Vocabulary domains are HL7 defined sets of concepts that can be assigned to a coded attribute. The RIM defines certain top level vocabulary domains for each coded attribute. During RMIM design, sub domains of the RIM specified domain can be chosen thus adding definition to the purpose of an attribute. In HDR, only membership in the RIM specified top level domain is verified for inbound codes. Sub domains are not enforced.
As an early adopter, Oracle has developed messaging artifacts using the V3 development methodology, sometimes in domains not yet explored by HL7. For this reason, the artifacts discussed in this conformance document use an HDR-specific suffix naming convention. This facilitates control and future migration to the final fully balloted HL7 V3 artifacts. This naming convention is defined by appending a realm code of HT and a version number. For example, the XSD for the initial message wrapper from HL7 is MCCI_MT000100.xsd. Because Oracle is implementing its fourth version of this wrapper before the standard is ratified, the name included for HDR conformance is mcci_mt000100ht04.xsd. As HL7 V3 artifacts are ratified, the new message types can be added to HDR-supported content. Once the mapping has been migrated, the old HDR message types can be retired. This migration process is controlled by the customer and not by HL7.
The following are descriptions of messaging service features and behavior that apply to all message types.
1.5.1 Reference Modifiers
1.5.2 Identified Object Processing (IOP)
1.5.3 Context Conduction
In HL7 version 2.x there were two modes of update. These were the action code/unique identifier and the snapshot. The action code method allowed for a code to state whether an object, identified by its unique identifier should be added, updated or deleted. This allowed for selective updates to object structures. There were many problems with this method when unique identifiers did not exist for an object. Frequently, snapshot mode was then used to control the update.
Snapshot mode relies upon the ability to send all information, each time a message is sent. The assumption is that the source system has the ability to send the complete set of objects and relationships a snapshot is intended to replace the previous set of objects for the same message subject.
There are many objects within V3 messages that do not have unique identifiers. The identification of such objects relies upon the ability to follow the relationships from the focal class. Examples of this include the valuables collected from a patient, or an interim diagnosis. When an update to the Encounter is sent with a new valuable collected from the patient, is it intended to replace the one that was previously sent or should it be added to the set of valuables collected? If a version 2 diagnosis does not contain a unique identifier, how does one distinguish a duplicate from a secondary diagnosis without making assumptions based upon an analysis of each attribute within the diagnosis? To answer these questions, HDR Version 7 offers wide range of reference modifiers.
HDR Version 7 supports the following reference modifiers:
Create : This checks for the existence of an object with the specified identifier and create it if it does not already exist.
Overlay: This creates an entirely new version of an object that already exists completely replaces information from the current version. However, that version and its associations are not lost. This allows for the exact relationships for a set of objects to be viewed at specific intervals over time.
Must Exist: assumes that the object exists and the current object in the message is ignored. An error is thrown in the object does not exist.
Update: This provides the ability to selectively update portions of an object group.that will help to build a new version of the object by using the attributes from the new object and also the missing attributes from the existing object. This would allow customers to build and pass objects with only the attributes that needs update.
Create Or Overlay: Creates an object if it does not exist; overlay if already present.
Create Or Update: Creates an object if it does not exist; updates if required.
The object at the root of the message is referred to as the focal class. The trigger event of the message describes this class. The focal class must contain a unique instance identifier.
If none of these reference modifiers are used to configure the type of object, the message processor treats a message object of that type as a Must Exist reference and attempts to resolve it by locating it in the repository. If the object is not found, the message is rejected. Note that if the reference is successfully resolved, the message processor does not attempt to validate or process message objects distal to the referenced object.
If the same object, or set of objects, occurs more than once in a message, it is important to ensure that they do not differ in content. For example, in some types of messages, it may be necessary to provide information about the same Patient in different parts of a single message instance. In such cases, identical information about the Patient should be provided each time. If the objects differ, the message is rejected.
Control Acts that are part of the message payload (example: Clinical Trial Laboratory Observation Periodic Report message) should not be configured for the overlay mode. Once created, a Control Act may be referenced by other messages but never overlaid with a new version of the Act.
For additional information about IOP, refer to the Identified Objects Processing section of the Oracle Healthcare Data Repository Programmer's Guide.
In HL7 V3, the set of all Participations and ActRelationships that apply to an Act form its context. Context may be conducted via ActRelationships so that the target Act inherits some of the source Act’s context using well defined rules.
The HL7 V3 RIM defines ActRelationship attributes (contextControlCode and contextConductionInd) and a Participation attribute (contextControlCode) that can be used in a message to regulate this inheritance. The details of this behavior are documented in the HL7 V3 ballot.
While these codes and indicators are represented faithfully in HDR (as received in a message), there is no further processing, which would implement this behavior. Therefore, if the combination of context control codes and indicator suggest that context can be inherited, HDR does not automatically reproduce the inherited Participations and ActRelationships on the target Act.
|
Copyright © 2018, Oracle. All rights reserved. |
About Oracle Contact us Legal Notices and Terms for Use Privacy Statement |