Monday Nov 17, 2008

Making HL7 BC work with Java EE SE

You can use Java for transformation or routing logic instead of BPEL by using one of the two options. One is using Java EE SE and another is POJO SE. A Java EE SE can work as an EJB and can utilise App.Server's services such as transactions, pooling etc. whereas a POJO SE cannot. A Java EE SE acts as a bridge between Java EE and JBI environment. In this blog entry I will you guide you step by step on how to make HL7 BC to interact with Java EE SE.


Inbound Scenario: In this scenario HL7 BC receives a HL7 message (ADT A43) and invokes Java EE SE. Here, we will create an EJB webservice. We will use a WSDL which uses HL7 Binding instead of SOAP binding to create the webservice.



  1. Create a WSDL with HL7 Binding and have it in some location. In this step we will create a Java application project just to create the WSDL. If the WSDL is already created , you can proceed to to Step 2.

    •  Download the HL7 V2 XSDs from http://wiki.open-esb.java.net/attach/HL7BC/HL7v2XSDs.zip and extract it somewhere.

    • Create a New Java Application Project

    • Create a WSDL by clicking on File -> New File _> WSDL document -> choose Concrete WSDL Document -> Choose Binding as HL7 Binding and Click Next.

    • Choose the Request Message by Clicking on Browse -> Selecting the xsd ADT_A43.xsd and choosing the element ADT_A43.CONTENT.



  2. Create an EJB Module :

    • Go To File -> New Project -> Enterprise -> EJB Module. Click Next.

    • Give a project name . Click Next

    • Choose Server as Glassfish V2 and Java EE Version as Java EE 5.



  3. Create an EJB Webservice from the WSDL created from Step 1.

    • Right Click on the EJB Module and choose - > New -> Other -> Webservices -> WebService from WSDL and click Next.

    • Provide a class name and package name for the ejb class and choose the WSDL created in Step 1. Wait for sometime until Web Service Port appears and Click on Finish



  4. Now, you have an EJB java file with one method hl7WsdlOperation(org.hl7.v2xml.ADTA43CONTENT part1). The class org.hl7.v2xml.ADTA43CONTENT is a JAXB generated class. You can use the methods of this class to access the values from received message. If you want invoke another JBI component from this EJB by passing the received message, See the outbound scenario. Now, for testing purpose you can just print the received "part1" object inside the method.

  5. Create a Composite Application and deploy it.

    • Go To File -> New Project -> Service Oriented Architecture -> Composite Application. 

    • Provide a project name and finish the wizard.

    • Double Click on the Service Assembly to open the CASA editor.

    • Drag and drop the EJB Module into the CASA editor.

    • Build and deploy the Composite Application.




Outbound Scenario: In this scenario, we will read the HL7 message from File using File BC, invoke Java EE SE passing the HL7 message into JAXB object and invoke HL7 BC from JavaEE SE passing the JAXB object.



  1. Create a WSDL with File Binding (which uses hl7encoder-1.0) and have it in some location.

    • Download the HL7 V2 XSDs from http://wiki.open-esb.java.net/attach/HL7BC/HL7v2XSDs.zip and extract it somewhere.

    • Create a Java Application Project

    • Create a WSDL by clicking on File -> New File _> WSDL document -> choose Concrete WSDL Document -> Choose Binding as File Binding, Choose Type as Poll and click next.

    • Provide the file name as input.txt and Click on Finish.

    • Open the WSDL Editor. Go to Messages -> PollInputMessage -> part1 .

    • Change the datatype by right clicking and choosing the element ADT_A43.CONTENT from ADT_A43.xsd

    • Traverse the tree to input -> file:message. In the properties sheet, choose use = encoded and provide encodingStyle as hl7-encoder1.0



  2. Create an EJB Module :

    • Go To File -> New Project -> Enterprise -> EJB Module. Click Next.

    • Give a project name . Click Next

    • Choose Server as Glassfish V2 and Java EE Version as Java EE 5.



  3. Create an EJB Webservice from the WSDL created from Step 1.

    • Right Click on the EJB Module and choose - > New -> Other -> Webservices -> WebService from WSDL and click Next.

    • Provide a class name and package name for the ejb class and choose the WSDL created in Step 1. Wait for sometime until Web Service Port appears and Click on Finish



  4. Now you have an EJB class with one method poll(org.hl7.v2xml.ADTA43CONTENT part1) . We need to invoke a webservice from this ejb module. So, create a webservice reference by following these steps:

    • Right Click on the ejb module. Choose Other -> Web Services -> Web Service Client.

    • Select the HL7 WSDL. (To create a HL7 WSDL see the STEP 1 in Inbound scenario). Click Finish



  5. Now, you can see a new folder created called Web Service References. Expand it until you see the operation. Drag and drop the operation into the ejb poll method. You will have code created for invoking the webservice. You need to marshall the JAXB object into XML string and pass the string for the method invocation. The code snippet should look like this: Code Snippet

  6. Create a Composite Application and deploy it.

    • Go To File -> New Project -> Service Oriented Architecture -> Composite Application. 

    • Provide a project name and finish the wizard.

    • Double Click on the Service Assembly to open the CASA editor.

    • Drag and drop the EJB Module into the CASA editor.

    • Build and deploy the Composite Application.




Place the test message in C:\\temp\\input.txt to test.

Thursday Oct 30, 2008

MLLP V2 support in HL7 Binding Component

We recently added MLLP Version 2 support in HL7 BC. I would like to share you the details of this support.

What is MLLP?


MLLP stands for Minimal Lower Layer protocol. It is a simple protocol
over TCP-ip. It is represented as : StartBlockChar -> Payload ->
EndBlockChar -> EndDataChar.

What is MLLP V2?


MLLP V2 provides reliability over MLLP transport. It provides
reliability by insisting on persistence of messages and by additional
ack/nak generation over MLLP. For every message received, the systems
should send a commit acknowledgement or negative acknowledgement. The
commit acknowledgement should be sent when the message is successfully
persisted otherwise a negative acknowledgement should be sent. This ack
/ nak is nothing but a single character enveloped within MLLP wrapper.
The MLLP V2 ack/nak will be of the form :


StartBlockChar -> AckChar/NakChar -> EndBlockChar ->EndDataChar.


The StartBlockCharacter is : 11. EndBlockCharacter is 28 End DataChar is 13.

 The characters used for Commit Acknowledgement in hex is 0x06 and negative acknowledgement is 0x15.


MLLP V2 in HL7 BC.



To Configure MLLP V2 in HL7 BC, just select the LLP Type as MLLPV2 in
ProtocolProperties extensibility element. The HL7 messages can be
persisted in a JDBC Datasource or in the HL7 BC's embedded Axion DB.
For storing the messages in JDBC Datasource, the user has to provide
the JNDI name of the JDBC datasource when the HL7 BC is installed. HL7
BC will create the required Tables for persisting the messages. All the
messages are stored in a table called HL7MessageLog. 

If the JNDI name is not found the embedded DB will be used by default.
The embedded Axion db is created in HL7 BC install location in
glassfish. That will be under
domains\\domain1\\jbi\\components\\sun-hl7-binding\\install_root\\axiondb.


Note: The HL7 messages are persisted only in the server side i.e Inbound mode. In outbound case the messages are not persisted.

Structure of HL7MessageLog table.


HL7MESSAGELOG


MESSAGEID VARCHAR(250) - A hash of the entire request message encoded in Byte 64 format.

APPLICATIONID VARCHAR(250) - The application name which stores the message. This will be service assembly name.

REQUESTMESSAGE CLOB - Entire HL7 request message

RESPONSEMESSAGE CLOB - HL7 Ack or HL7 NAK message

STATUS SMALLINT - Status of the message. 1 - Request message received, 2. HL7 ACK sent. 3 HL7 NACK sent

CREATEDTIME TIMESTAMP - Created time of the request message

LASTUPDATEDTIME TIMESTAMP - The time when the table was last updated.

Tuesday Aug 07, 2007

Understanding HL7 Version 3 from Developer perspective

Introduction


Understanding HL7 V3 specification is a difficult task for the developers who worked on HL7 v2 messages. The HL7 V3 specification is different in many ways from V2. I have gathered all the information required for transmitting HL7 V3 messages from the V3 specification documents and here I will give a general overview of different elements of V3 and constructing the V3 message that can be exchanged with other compatible systems.


HL7 V2 versus V3


HL7 V2 is primarily intended for developers or clinical interface specialists, whose job is to move clinical data or create tools to exchange such data from one application to another. Thus, V2 is designed to ease the exchange of clinical data between different systems. Whereas V3 is influenced by Medical informatists who work in the field of healthcare and study how healthcare information is created. Thus the V3 specification primarily focuses on Healthcare data rather than how to transmit the data.


HL7 V3 message development process


The V3 message development process is based on information models produced by the development groups. An information model represents data in object oriented way. It has classes with relationships, properties, states and constraints. The information models are refined and localized to come up with messages that can be exchanged with different systems.


Reference Information Model (RIM): The RIM is an information model collectively developed by the HL7 working group. It is the information model that encompasses the HL7 domain of interest as a whole. The RIM is a coherent, shared information model that is the source for the data content of all HL7 messages. The RIM is intentionally abstract to represent the HL7 data in a standard way across all the domains of Healthcare. It is the root of all information models and structures developed as part of the V3 development process.


Domain-Message Information Model (D-MIM): The classes, attributes, state-machines, and relationships in the RIM are used to derive domain-specific information models called D-MIMs. A D-MIM is a refined subset of the RIM that includes a set of class clones, attributes and relationships that can be used to create messages for a particular domain (a particular area of interest in healthcare). Domains under Administrative Management : - Accounting and Billing - Claims & Reimbursements - Patient Administration - Personnel Management - Scheduling Domains under Health and Clinical Management: - Clinical Document Architecture - Medical Records - Public Health Reporting - Clinical Genomics - Specimen Domain - Regulated Studies


Refined-Message Information Model (R-MIM): The R-MIM is a subset of a D-MIM that is used to express the information content for a message or set of messages with annotations and refinements that are message specific. The D-MIM is used as a common base upon which all R-MIMs within a domain are built.


Heirarchical Message Descriptions (HMDs): The HMDs are abstract message structures which represent the information from R-MIMs. The HMD represents R-MIM in an organized way which can be exchanged between systems. The HMDs are called abstract because they define the message structure without reference to the implementation technology.


XML Schemas: HL7 V3 defines Implementation technology specifications (ITS). These ITS define how the abstract message types should be transmitted using an underlying technology. V3 currently defines XML ITS and UML ITS. The XML ITS defines data types and structures. The XML datatypes represents HL7 datatypes in XML specific way. And the XML structures represent the structures defined by HMDs. Thus for every message type there is a HMD and XSD correspondingly.


Understanding V3 Artifacts: We saw the process of V3 message development, where V3 information models are refined to come up with XML schemas which can be used to construct V3 XML messages. But I didn’t mention which are the XSDs contain all required information to come up with complete V3 message. In the below section, I will address this. To understand the V3 specification, understanding the artifacts of the specification is very important. The HL7 technical committee during the specification development process identifies various artifacts for a particular domain and submits the same. For every domain, the artifacts are organized in the same structure. Thus for every domain specification, the committee submits the artifacts documented as explained below. To identify every artifact, the HL7 has come up with an unique attribute called Artifact Identifier. For example, an application role submitted by the Patient Administration domain will have the following unique artifact identifier: PRPA_AR00001UV00 Where: PR = Practice(Subsection) PA = Patient Administration (Domain) AR = Application Role (Artifact type) 00001 = 6 digit non-meaningful number assigned by the Technical Comittee to ensure uniqueness UV = Realm (the only current value is UV for universal) 00 = Current version number


Application Role (Code:AR): Application roles represent a set of communication responsibilities that might be implemented by an application. Thus they describe system components or sub-components that send and/or receive interactions.


Trigger Event (Code:TE): A trigger event is a condition on which an action is initiated. 


Storyboard (Code:ST): A storyboard explains the series of actions in a particular scenario. Its primary purpose is to identify the various scenarios. Each storyboard is represented as sequence diagrams. It also lists the interactions between two or more systems playing different Application Roles.


Storyboard Narrative (Code:SN): A Storyboard narrative provides explanation for the storyboard.


D-MIM (Code:DM): Domain specific classes represented in a diagram with relationships.


R-MIM (Code: RM): A subset of D-MIM classes represented in a diagram with relationships. These classes are specifically to represent information content for one or more HMDs.


HMD (Code:HD): The Message Structures or Message types which form the payload of the data transmitted. The base HMD is depicted in a tabular format or in excel view. It also lists the various message types built based on this HMD.


Message Type (Code:MT): A message type represents a unique set of constraints applied against the common message. It is represented in Table view or in XML schema view.


Interaction (Code:IN): Interactions define the interaction between two systems. The documentation of interaction defines: - Trigger Event which initiated the interaction - Message Type which should be used for interaction (The payload) - Transmission Wrapper: A Message Type to wrap the payload with - Control Act Wrapper: A Message Type to hold the administration information about the payload being transmitted. - Sender: The Sender Role for this interaction - Receiver: The Receiver Role for this interaction.


Transmission Wrapper and Control Act Wrapper: This specification defines HL7 V3 Composite message is composed of:


 



  1. An "HL7 Transmission wrapper" (always)

     


  2. A "Trigger Event Control Act" (required for all messages except accept level acknowledgements, for which it is not permitted)

     


  3. The "HL7 Domain Content" specified by an HL7 domain specific technical committee (required for each Trigger Event Control Act)

     



The HL7 Transmission wrapper is specified in domain: Transmission Infrastructure. This domain specification describes the details on composing a V3 composite message and exchanging the composite message between systems. It covers features like acknowledgements, sequence no. protocol support, error handling and security. “Trigger Event Control Act” is detailed in domain: Message Control Act Infrastructure. This details the administrative information about the data being transmitted. Thus the interactions define the complete set of information that is required to exchange HL7 data between the systems.


Conclusion: The HL7 V3 specification contains the XSDs for Interactions which can be used to construct the composite HL7 V3 message. This composite message then can be transmitted between the systems. The V3 Specification says that a system can claim for V3 conformance based on the Application Role it will play in a particular domain. The system playing the Application Role will recognize the Trigger Events, the message types and the data content of these messages. Thus a system whose sole responsibility is to exchange the V3 data between systems reliably should claim conformance for the Application Roles defined under Transmission Infrastructure Domain.

About

vishblog

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today