Installing Upgrading Designing Configuring Deploying Monitoring Administering Troubleshooting Reference JBI Components
Close Print View
Designing: Introducing the Methodology
 

Classic Java CAPS

Developing Java CAPS Projects

Using SOAP Message Handlers

Creating a Runtime Environment

Designing Business Processes in the Sun Business Process Manager

Working with TCP/IP HL7 Collaborations

TCP/IP HL7 Adapter Collaborations Overview

TCP/IP HL7 Adapter Task Overview

TCP/IP HL7 V2 Adapter Collaborations

Inbound HL7 V2 Collaboration Overview

Outbound HL7 V2 Collaboration Overview

Limitations of Version 2.x

Creating a Copy of an HL7 V2 Project

To Export a Project

Customizing Predefined Collaborations for HL7 V2

Creating Copies of an HL7 V2 Collaborations

To Create Copies of an HL7 V2 Collaborations

Adding HL7 V2 OTD to an Existing Collaboration

To Add HL7 V2 OTD to an Existing Collaboration

TCP/IP HL7 V3 Adapter Collaborations

Introducing the Methodology

What's New with HL7 V3

Artifact Identification System

HL7 V3 Message Development Process

Artifact Codes

Transmission Wrapper and Control Act Wrapper

Comparison between HL7 V2.x and HL7 V3

Benefits of V3 to HL7

Inbound HL7 V3 Collaboration

Inbound HL7 V3 Immediate Collaboration Overview

Inbound HL7 V3 Deferred Collaboration Overview

Outbound HL7 V3 Collaboration

Outbound HL7 V3 Collaboration Overview

Creating a Copy of an HL7 V3 Project

Customizing Predefined Collaborations for HL7 V3

Creating Copies of an HL7 V3 Collaborations

Adding HL7 V3 OTD to an Existing Collaboration

To Add HL7 V3 OTD to an Existing Collaboration

MLLP V2

MLLP V2 Content Exchange Model

Standard Inbound HL7 V2 Collaboration Overview over MLLPV2

Developing Sun Master Indexes (Repository)

Developing Sun Master Patient Indexes

Developing OTDs for Application Adapters

Developing OTDs for Communication Adapters

Developing OTDs for Database Adapters

Developing OTDs for Web Server Adapters

Designing with Application Adapters

Designing with Communication Adapters

Designing with Web Server Adapters

SWIFT Integration Projects

Java EE Based Components

Designing with Sun JCA Adapters

About the TCP/IP JCA Adapter

Defining Constants and Variables

Using Database Operations

Developing Sun Master Indexes

Using the JMS JCA Wizard

Using the JAXB Wizard and Code-Seeder Pallete

Introducing the Methodology

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.

Outlined below is a summary assessment of the two HL7 versions.

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