Wednesday Jan 13, 2010

GlassFish ESB v2.2 - Processing Explicit HL7 v2 Accept Acknowledgements

The HL7 v2 standard mandates the use of acknowledgments to ensure message delivery, critical in Healthcare. There are the “Original Mode” acknowledgements and “Enhanced Mode” acknowledgements. Within the enhanced mode acknowledgements there are “Accept Acknowledgements” and “Application Acknowledgements”.

This Note walks through development of two BPEL Module-based solutions that cooperate in generating and processing Enhanced Accept Acknowledgements using HL7 v2.3.1 messages. This discussion should apply to any v2.x, greater then v2.2, where the Enhanced Mode acknowledgements were introduced. In addition, the solutions are used to illustrate receiving HL7 BC ACK generation, when receiving an invalid HL7 message.

The blog article and the related material are available at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-processing-explicit-hl7-v2-accept-acknowledgements

Sunday Jan 10, 2010

GlassFish ESB v2.2 Notes - HL7 v2 Handling - Notable improvements in BPEL Mapper

GlassFish ESB v2.2 was released in late December/early January 2010. This release brings a number of design-time improvements in handling HL7 v2 messages. Some of these have been on my and other people’s wish lists for years.

HL7 v2 structure nodes use full names, rather then acronyms like MSH.1.
In BPEL, mapping can be performed at message, segment, component, subcomponent and field level.

These improvements are noteworthy enough to warrant a note, to be found at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-notes-hl7-v2-handling-notable-improvements-in-bpel-mapper

Saturday Jan 09, 2010

GlassFish ESB v2.2 Field Notes - Ephemeral, JVM-global, POJO-based Sequence Number Generator for BPEL

When working on the HA solutions discussed in my HA blog ebntry I realized that it will be difficult to work out whether messages are delivered in order, as was required, and whether any are missing. I got over the issue by ensuring that my test data was prepared in such a way that messages in each test file had increasing, contiguous sequence numbers embedded in the message. For HL7 v2, which is the messaging standard with which I dealt, I used MSH-10, Message Control ID field. I wrote processed messages and acknowledgments to files whose names embedded MSH-10 Message Control Id, with the sequence number, so breaks in sequence and out of order messages could be readily detected.

With multiple message files containing between 1 and 50,000 messages, adding a sequence number to each message by hand was clearly out of the question.

I put the GlassFish ESB to use. I constructed a file-to-file BPEL module project to read each test file and to prepend a sequence number to each message’s MSH-10 field. The only snag was how to get a sequence number that would start at 0 and increase by 1 for each message, such that each BPEL process instance would get the next sequence, and that messages would be written to the output file in order.

This note discusses how I went about accomplishing the task.

The original article is available as GlassFish ESB v2.2 Field Notes – Ephemeral, JVM-global, POJO-based Sequence Number Generator for BPEL at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-field-notes-ephemeral-jvm-global-pojo-based-sequence-number-generator-for-bpel

Tuesday Jan 05, 2010

GlassFish ESB v2.2 Field Notes - Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions

It seems frequently assumed that architecting and deploying Highly Available (HA) solutions requires Application Server and/or Operating System clustering. When it comes to SOA and Integration solutions this is not necessarily a correct assumption. Load Balanced (LB) and Highly Available HA) SOA and Integration solutions may not require that degree of complexity and sophistication. Frequently, protocol, binding component, JBI and architectural application design properties can be exploited to design highly available solutions. Testing LB and HA solutions requires infrastructure consisting of multiple hosts and the ability to “crash” hosts at will. With virtualization technologies available now it is far easier to use multiple virtual machines then to use physical machines. It is also easier and potentially less destructive to “crash” virtual machines then it is to do so with physical machines.

In this Note a heterogeneous, non-clustered collection of hosts will be used to implement and exercise three load balanced, highly available GlassFish ESB-based solutions. The environment consists of a number of independent “machines”, which are not a part of an Operating System Cluster. Each “machine” hosts a GlassFish Application Server. Application Servers are independent of one another and are not clustered. This is to demonstrate that load balanced, highly available, horizontally scalable solutions, based on the GlassFish ESB software alone, can be designed and implemented.

The specific class of solutions to which this discussion applies is the class of solutions which:
1.    are exposed as request/reply services
a.    HL7 messaging with explicit Application Acknowledgment
or
b.    Request/Reply Web Services
or
c.    JMS in Request/Reply mode
2.    implement business logic as short lived processes
3.    are
a.    atomic
or
b.    are idempotent
or
c.    tolerant of duplicate messages
Classes of solutions with characteristics different from these named above require different approaches to high availability and horizontal scalability, and are not discussed here.

In this Note only high availability and scalability of receiver solutions is addressed. This aspect is the focus because a failure to process a message by a receiver may result in message loss –generally a bad thing.

Paradoxical as it may sound; senders are special cases of receivers. Just as a receiver is triggered by arrival of a message so too is a sender. Making sure that the sender trigger message does not get lost is much the same as making sure the message a receiver receives does not get lost. This means that the same considerations apply to senders and to receivers.

This note discusses an exercise involving an example load balanced, highly available, horizontally scalable healthcare environment, processing HL7 v2 messages. Discussion includes customization of generic GlassFish ESB v2.2 VMware Virtual Appliances for a specific Load Balancing and High Availability exercise and deploying ready-made GlassFish ESB solutions. The exercise for HL7 BC-based, Web Service-based and JMS-based highly available, load balanced, and horizontally scalable receivers, processing HL7 v2.3.1 messages, will be conducted and discussed.

At the end of the Note we will have three GlassFish ESB VMware Appliances with GlassFish ESB v2.2 Runtime infrastructure, ready to use for further GlassFish ESB Load Balancing and High Availability exercises.

The reader will be convinced, one hopes, that for the applicable class of GlassFish ESB-based solutions, load balancing and dynamic failover without message loss work. For that class of solutions this provides for high availability and horizontal scalability without resorting to Application Server or Operating System clustering.

The article is available at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-2-field-notes-exercising-load-balanced-highly-available-horizontally-scalable-hl7-v2-processing-solutions

Thursday Sep 17, 2009

GlassFish ESB v2.1 - Excessive length of Stay Healthcare IEP Demonstration

As a healthcare enterprise looks after patients, information is gathered about various events that take place. Information about notable events, Admissions and Discharges, for example, is recorded in Hospital Information Systems or Patient Administration Systems. These systems typically broadcast event information in a form of HL7 messages for use by other enterprise systems, for example laboratory or diagnostic imaging. A stream of HL7 messages can be intercepted and processed to derive all sorts of interesting information.

The solution developed in this walkthrough deals with Excessive Length of Stay. Length of stay is defined as the period between patient’s admission to and discharge from the hospital. Statistical average expected length of stay is typically available for different kinds of patients presenting with different kinds of conditions. A significant variation from the average length of stay for specific patients may indicate complications, treatment errors, infections and other kinds of issues that the hospital needs to investigate. Notification of such incidents may help the hospital in addressing these issues and prevent future occurrences.

In this solution the Intelligent Event Processor is used to calculate the continuously updated average length of stay over a period of time and use it to compare against each event’s length of stay. It passes, to the downstream component, all events where the length of stay exceeds the average by 1 ½ times and ignores all others.

In the initial iteration, the solution reads a stream of discharge messages, containing admission date, discharge date, length of stay, and a bunch of other fields from a file and passes them to the IEP process. The IEP process keeps the window on the last 10 seconds worth of records and continuously calculates the average length of stay over all records in that window. As records are added to and removed from the window the average is recalculated. As each record is seen its length of stay is compared to the average length of stay of all records in the window at the time. If the length of stay in the current record is less then or equal to 1 ½ times the average at the same time the record is discarded. If the average is greater the record is ejected to the output and ultimately written to a file of exception records.

In a subsequent iteration the solution is modified to accept messages from a JMS Queue. This modification allows the solution to use the stream of discharge messages produced by the HL7 Processor solution, discussed in “HL7 Processor Demonstration - GlassFish ESB v2.1”.

In a further modification the solution is configured to send notification messages to another JMS Queue. Notification messages are processed by a different solution and sent to an email recipient.

The article and referenced materials are available at http://blogs.czapski.id.au/2009/09/glassfish-esb-v2-1-excessive-length-of-stay-healthcare-iep-demonstration

Friday Sep 04, 2009

HL7 Processor Demonstration - GlassFish ESB v2.1

This Note walks the reader through development of a GlassFish ESB v2.1based solution that addresses a Healthcare-related business problem. The Note elaborates on the healthcare background necessary to get a notion of what is being done and why, and provides detailed steps required to implement and exercise the solution to the business problem.

We will use the HL7 Binding Component, the File Binding Component, the JMS Binding Component, the SOAP/HTTP Binding Component, the BPEL 2.0 Service Engine, the JavaEE Service Engine, the HL7 Encoder and EJB-based Web Services in a JBI-based solution. 

This note is an update, for GlassFish ESB v2.1, of the original note  "HL7 Processor Demonstration - Java CAPS 6/JBI and OpenESB".

Updated note is available at http://blogs.czapski.id.au/2009/09/hl7-processor-demonstration-glassfish-esb-v2-1

Friday Jul 03, 2009

GlassFish ESB v2.1, MySQL v5.1 - Make HL7 v2.3.1 Delimited Messages from Custom Delimited Records with HL7 Encoder and HL7 BC

“Progress” notwithstanding, Healthcare environments still extensively use the HL7 v2.x Delimited messages for conveyance of patient and patient-related information between applications. The GlassFish ESB provides support for HL7 v2.x messaging in the form of the HL7 Encoder, which allows conversion between HL7 v2 Delimited and HL7 v2 XML message formats, and in the form of the HL7 Binding Component, which allow connectivity between the GlassFish ESB-based healthcare solutions and healthcare applications that support HL7 over TCP connectivity.

In this document I will walk through the process of generating HL7 v2.3.1 delimited messages from pipe-delimited records containing patient information, sending and receiving HL7 v2.3.1 delimited messages using the HL7 Binding Component, parsing HL7 v2.3.1 delimited messages and writing HL7 v2 delimited messages to a file. To create and process HL7 messages I show how create a custom ADT A04 XML Schema and a custom “any HL7 v2 message” XML Schema. This gives me an opportunity to use the File Binding Component (File BC), the HL7 BC, the HL7 Encoder, the Custom Encoder and the BPEL Service Engine (BPEL SE). This also gives me an opportunity to demonstrate a HL7 v2.3.1 delimited message sender solution and to demonstrate a HL7 v2.3.1 delimited message receiver solution. At the end of the process we will have a file containing HL7 v2 delimited ADT A04 messages, which we will use in related writeups. 

The article and referenced materials are available at http://blogs.czapski.id.au/2009/07/glassfish-esb-v2-1-mysql-v5-1-make-hl7-v2-3-1-delimited-messages-from-custom-delimited-records-with-hl7-encoder-and-hl7-bc

Sunday Mar 01, 2009

Java CAPS Quick Note 002 - JCA Transform HL7 Delimited to Custom XML


This Quick Note discusses a solution to the use case provided by Marcus Davies.



I am trying to read HL7 from JMS (preferably stcms) and populate an outbound XML data structure (different to the XML generated by the decoder).
I have been thinking of doing one of the following […]:
1.    Use a Concrete JMS WS using the HL7 encoders to unmarshal the HL7 and use JAXB to populate the outbound XML.  Unfortunately this does not appear to connect to the stcms queue as I can not see any receivers
2.    Use a JCA MDB to read from the stcms JMS queue - this works but I don’t think I can use the HL7 encoder like this
3.    Use and MDB to read from JMS, manually unmarshal the HL7 and use JAXB to populate the data structure
Ideally I would like to use the HL7 encoders.  Do you think the first approach should work?


Number 1 will not work as at end of February 2009 because the JMS BC does not properly decode the HL7 delimited message. This is a know issue. I don't know what the status of this is. The only BCs that know how to deal with HL7 delimited, that I know of, are the File BC and the HL7 BC.

Number 2 should work. I did not personally try it. You can invoke an encoder library from Java. Have a look at http://wiki.open-esb.java.net/Wiki.jsp?page=UseEncodersInJavaSE.

Number 3 should work but it will be very laborious.

I have a Number 4, which uses a HL7 OTD and a custom XSD-based OTD in a JCA EJB. You may or may not like it but it’s the best thing to do if you can not use BPEL 2.0 to do the mapping and you don’t want to build a repository-based solution (which would be the best for your case anyway).

The solution involves the use of:
1.    HL7 2.3.1 OTD Library (Java CAPS 6 Repository)
2.    JMS JCA to trigger a MDB with a HL7 Delimited message
3.    JMS JCA to write result message out
4.    JCA MDB to do the processing
5.    OTDImporter to provide HL7 2.3.1 OTD and custom XSD-based OTD to the EJB for “convenient” mapping

The article and referenced materials are available at http://blogs.czapski.id.au/2009/02/java-caps-quick-note-002-jca-transform-hl7-delimited-to-custom-xml

Thursday Jan 01, 2009

HL7 Processor Demonstration - Java CAPS 6/JBI and OpenESB

This Note walks the reader through development of a Java
CAPS 6/JBI-based / OpenESB-based solution that addresses a Healthcare-related
business problem. The Note elaborates on the healthcare background necessary to
get a notion of what is being done and why, and provides detailed steps
required to implement and exercise the solution to the business problem.



Updated note, where GlassFsish ESB v2.1 is used instead of Java CAPS 6, is available at http://blogs.czapski.id.au/2009/09/hl7-processor-demonstration-glassfish-esb-v2-1



We will use the HL7 Binding Component, the File Binding
Component, the JMS Binding Component, the SOAP/HTTP Binding Component, the BPEL
2.0 Service Engine, the JavaEE Service Engine, the HL7 Encoder and EJB-based
Web Services in a JBI-based solution.


In the process we will create XML Schema Documents (XSDs),
Web Services Description Language Documents (WSDLs), a BPEL 2.0 Business
Process, an EJB-based “Implementation First” web service, an EJB- and
WSDL-based “Interface First” web service, a bunch of Composite Applications,
BPLE 2.0 mapping, BPEL 2.0-based Web Service orchestration, on-the-fly
conversion of HL7 version 2.3.1 delimited messages to their XML equivalents. We
will get a pretty good exposure to what OpenESB and Java CAPS 6/JBI components
look like, how they work and how they can be used to create real business
solutions. Above all, we will develop and test a solution that is more
sophisticated then the customary “Hello World” examples but not so complex as
to take too long to build and become too hard to comprehend by a novice user.


The particular business problem and the particular solution
came about because once upon a time there was intent to build a series of
related OpenESB projects – HL7 Processor, MDM Processor and IEP Processor -
that would:



  • receive HL7 v2.x delimited messages

  • convert HL7 v2.x messages to their equivalent XML format

  • split message stream into ADT A01s, ADT A03s and other

  • convert A01s to an abbreviated Custom Patient XML format

  • convert A03s to an abbreviated Custom Discharge format

  • send Custom Patients to a JMS Queue for processing by a MDM solution

  • send Custom Discharges to a JMS Queue for processing by an IEM solution

  • have the MDM process Custom Patients into a Master Patient Index

  • have the IEP process Custom Discharges to flag excessive length of stay


The MDM Processor and the IEP Processor made it to the Sun CEC
2008 as demonstrations, with associated Tutorials by Tom Barrett, and
demonstration recordings by me. The HL7 Processor did not make it. With the
appearance of Java CAPS 6 Update 1 more JBI components made it into the
officially supported Sun product. While the HL7 BC and the HL7 Encoder did not
make it into this Update they will, eventually. Both components are already
available from the OpenESB site and can be installed into the Java CAPS 6
Update 1 installation as unsupported components. This is what we will do for
this Note.


The article with the complete note and referenced links is available at http://blogs.czapski.id.au/2009/01/hl7-processor-demonstration-java-caps-6jbi-and-openesb


For these interested in processing HL7 using GlassFish ESB v2.1 there is a blog entry, "GlassFish ESB v2.1, MySQL v5.1 - Make HL7 v2.3.1 Delimited Messages from Custom Delimited Records with HL7 Encoder and HL7 BC", at , which discusses, amongst other things, how to create a custom HL7 v2 ADT A04 XSD and a "match any" XSD.

About

In this Blog I post abstracts of articles / writeups / notes on various aspects of Java CAPS and SOA Suite including solutions, discussions and screencasts. The links to the referenced material are included in the bodies of the abstracts.

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