The Domain Information Model (D-MIM) is presented first in each domain, providing a graphical and narrative detail of the scope of the domain. The D-MIM is the first in the series of information models. The D-MIM is a subset of the RIM but uses specific conventions to represent artifacts. Once the classes, attributes, and associations for a particular domain have been isolated through the D-MIM, the next logical step is to extract the set of classes, attributes, and associations required for an HMD or set of HMDs that originate from the same root class. These extractions are referred to as R-MIMs (Refined Message Information Models), which are a subset of and use the same conventions as the domain D-MIM.
The second element in the domain is one or more domain-level storyboards. Each storyboard includes a diagrammatic representation, called an Interaction Diagram. [Interactions describe the purpose of information flow. Create Patient Billing Account and Delete Patient Billing Account are examples of interactions found in the HL7 V3 messaging standard. Once the overall picture of data exchange is presented, the Storyboard continues with a narrative describing how the interactions might unfold in real life. Following the narrative is a description of each application role. Storyboards may be represented for the entire domain, or may be specific within the domain.]
There are three modes of Acknowledgement Process in HL7 V3.
Immediate Mode
Deferred Mode
Queued Mode
Outlined below is a summary assessment of the two HL7 versions.
Table 1–1 Summary Assessment
Standard |
Benefits |
Challenges |
---|---|---|
HL7 V2 |
Reflects the complex everyone is special world of healthcare |
Provides a one size fits none standard |
Much less expensive to build HL7 interfaces compared to custom interfaces |
Loose and optional ridden HL7 definitions lead to discrepancies in HL7 interfaces |
|
Provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interface-by-interface basis |
Not inclusive of international needs No compatibility with HL7 V3 |
|
Historically built in an ad hoc way, allowing the most critical areas to be defined first Generally provides compatibility between 2.x versions |
Defining a detailed list of items to be discussed and negotiated before interfacing can occur is required |
|
HL7 V3 |
More of a true standard and less of a framework for negotiation |
For clinical interface specialists |
Model-based standard provides consistency across entire standard |
No compatibility with HL7 V2 |
|
Application roles well defined |
Adoption will be expensive and takes time |
|
Much less message optionality |
Long adoption cycle, unless storage business case or regulatory requirement changes |
|
Less expensive to build and maintain mid-to-long term interfaces |
Retraining and retooling necessary |