Apr 24

From time to time prospective clients ask for a proof that Java CAPS will not loose HL7 messages in the event of machine or network failure.

This note walks through the process of installing a Java CAPS 6.2 runtime on the Base OpenSolaris-based VMware Virtual Appliance, discussed in the Blog Entry “GlassFish ESB v2.x Field Notes – Preparing Basic JeOS Appliance for GlassFish ESB LB and HA Testing” at http://blogs.czapski.id.au/2010/01/glassfish-esb-v2-x-field-notes-preparing-basic-jeos-appliance-for-glassfish-esb-lb-and-ha-testing.

At the end of the Note we will have a Java CAPS 6.2 VMware Appliance with Java CAPS 6.2 Runtime infrastructure, ready to use for reliability testing, or any other purpose for which a Java CAPS 6.2 runtime appliance might be appropriate.

The Note is available at “http://blogs.czapski.id.au/wp-content/uploads/2010/04/02_Installing_JavaCAPS_6.2_on_JeOS_appliance_v1.0.0.0.pdf“.

Jan 26

In the blog entry “GlassFish ESB v2.2 Field Notes – Exercising Load Balanced, Highly Available, Horizontally Scalable HL7 v2 Processing Solutions”, at http://blogs.czapski.id.au/?p=13, I present the GlassFish ESB v2.2-based load balanced, highly available, horizontally scalable solution for HL7 v2.x delimited messaging, using both the HL7 Binding Components, Web Services and JMS in request/reply mode. The one and a half hour recording of me discussing and demonstrating this solution is available as a Flash Movie (SWF), “GFESB_LB_HA_Demo_Session SWF ” at http://blogs.czapski.id.au/wp-content/uploads/2010/03/GFESB_LB_HA_Demo_Session_SWF.swf (62.7Mb download)

Jan 12

The HL7 v2 standard mandates the use of acknowledgments to ensure message delivery, critical in Healthcare. There are the “Original Mode” acknowledgments and “Enhanced Mode” acknowledgements. Within the enhanced mode acknowledgments 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 Acknowledgments using HL7 v2.3.1 messages. This discussion should apply to any v2.x, greater then v2.2, where the Enhanced Mode acknowledgments were introduced. In addition, the solutions are used to illustrate receiving HL7 BC ACK generation, when receiving an invalid HL7 message.

The Note, Processing_Explicit_HL7_AcceptAcks_v1.0.0.0.pdf, can be found at http://blogs.czapski.id.au/wp-content/uploads/2010/03/Processing_Explicit_HL7_AcceptAcks_v1.0.0.0.pdf.
The associated GlassFish ESB v2.2 Projects, HL7EA_Projects.zip, can be found at http://blogs.czapski.id.au/wp-content/uploads/2010/03/HL7EA_Projects.zip.

Jan 09

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, GFESBv22_HL7_Handling_Improvements.pdf, at http://blogs.czapski.id.au/wp-content/uploads/2010/03/GFESBv22_HL7_Handling_Improvements.pdf.

Tagged with:
Jan 08

When working on the HA solutions discussed in my HA blog entry 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 complete note, GFESBv22_EphemeralSequenceGenerator_v1.0.0.0.pdf, is to be found at: http://blogs.czapski.id.au/wp-content/uploads/2010/03/GFESBv22_EphemeralSequenceGenerator_v1.0.0.0.pdf

Tagged with:
Jan 05

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
b.    Request/Reply Web Services
c.    JMS in Request/Reply mode

2.    implement business logic as short lived processes
3.    are

a.    atomic
b.    are idempotent
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 complete Note is available as 03_Conducting_HL7_LB_and_HA_Exercise_v1.0.0.1.pdf at http://blogs.czapski.id.au/wp-content/uploads/2010/03/03_Conducting_HL7_LB_and_HA_Exercise_v1.0.0.1.pdf

Sep 16

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”, http://blogs.czapski.id.au/?p=23.

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 document, “Excessive length of Stay Healthcare IEP Demonstration”, can be found at http://blogs.czapski.id.au/wp-content/uploads/2010/03/Combinned_Intelligent_Event_Processor_Demonstration_v1.0.pdf

The pre-built projects in the “Excessive length of Stay Healthcare IEP Demo Companion Archive” can be found at http://blogs.czapski.id.au/wp-content/uploads/2010/03/Healthcare_Demo_Combined_v1.0.zip

Aug 01

In this walkthrough I will add a Google Map showing a Route between patient’s home address location and the location of patient’s facility of record, as well as directions to follow along this route, to the Visual Web JSF Portlet developed in “Patient Lookup Visual Web JSF Portlet with a nicer looking Google Map”.

The walkthrough document is here: 02_PatienLookup_VWJSFPortletGooRoute.pdf

The comnpanion archive with NetBeans project artifacts is here: PatientLookupGooRouteVWJSFP.zip

Jul 31

The previous blog, walked through development and deployment of the Patient Lookup Portlet with a basic Google Map centered at the location identified by patient address, if any. It was a fairly basic Google Map, as Google maps go. In this document I will add a better looking Google Map to the Patient Lookup Portlet, explicitly using Google Maps APIs to construct the map.

The walkthrough is here: 02_PatienLookup_VWJSFPortletGooMapFancy.pdf

The companion archive, containing the NetBeans project, is here: PatientLookupGooMapBetterVWJSFP.zip

Jul 21

The business idea behind the functionality developed in this walkthrough is that patients are looked after in various healthcare facilities. Healthcare workers need to lookup patient details such as their identifier, gender, birth date or address. A relational database holds patient details as well as other information of relevance such as descriptions of various coded values. Patient details are available through a web service. Facility list and details, used to narrow down the search for patients to a specific facility, are available through a web service. These web services will be used to construct the Portlet that will allow patient search and a display of patient details with display a Google Map, centered at patient’s address, if one is available and is valid for the purpose of mapping. This Portlet will be deployed to the Sun FOSS Web Space Server 10 Portal.

The previous blog entry walked through development and deployment of the basic Patient Lookup Portlet. In this document I add a basic Google Map to the Patient Lookup Portlet.

Other blog entries in this series walked the reader through the process of implementing GlassFish ESB v2.1-based web services which return facility list and facility details as well as patient details.

Note that this walkthrough builds on the Patient Lookup Portlet, built previously, but deals exclusively with Visual Web JSF portlet-related technologies, Java Script and Google Maps API.

The walkthrough document is here: 02_PatienLookup_VWJSFPortletGooMapBasic.pdf

The project archive is here: PatientLookupGooMapBasicVWJSFP_companion_archive.zip

preload preload preload