Nov 11

The archetypical “Hello World” solution in the HL7 v2 messaging world will consist of a HL7 v2 message receiver which writes the messages it receives to files in the file system.

This article works through the mechanics of configuring the “SOA Suite for healthcare integration” to receive HL7 v2.3.1 ADT messages as a Canonical Messages and configuring the SOA Suite to write each message to a file in the file system.

This article assumes that the reader is sufficiently familiar with HL7 v2 and HL7 v2 messaging to require no elaboration on the message structures, message acknowledgement processing and the “equivalence” of HL7 v2 delimited and HL7 v2 XML message forms.

The complete article is available at https://blogs.czapski.id.au/wp-content/uploads/2012/11/SOASuiteHCI_ch6_Inbound2File_v0.1.0.pdf.

Data files used in this article series are available at:

ADT_A01_broken_1.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_broken_1.zip – this file contains a single ADT A01 transaction, in which the EVN segment’s name is rbroken, making the message invalid. This message is used in the article “SOA Suite for healthcare integration Series – Exception Handling – Processing Endpoint Errors” for testing exception handling
ADT_A01_output_1.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_1.zip – this file contains a single ADT A01 transaction
ADT_A03_output_1.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A03_output_1.zip – this file contains a single ADT A03 transaction
ADT_A01_output_5099.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_5099.zip – this file 5099 ADT A01 transactions, separated by \r\r\n, or Carriage Return, Carriage Return and New Line
QRY_A19.hl7 – https://blogs.czapski.id.au/wp-content/uploads/2013/01/QRY_A19.zip – this file contains a sample A19 query message

Sep 02

Each different domain, covered by HL7 v2 standard, has a set of message definitions which support message exchanges for a particular domain. Most of the message definitions for a domain share certain segments. Many of the segments are optional and perhaps not used in a particular messaging environment.
In any but the simplest of HL7 messaging environments there will be multiple sources and multiple destinations of HL7 messages. It is very unlikely that all, or even a majority of these, will use exactly the same HL7 message structures in terms of versions, optional/mandatory segments, extension Z segments, and so on.
It is common for integrating specialists, if the tooling which they use permits, to develop one or few generalised message structures which can be used to represent more than one distinct message from a domain they work with. These are typically called canonical models. The overriding purpose is to standardise the message payload being passed around between integration components, enabling reuse and reducing complexity. The Canonical Message model (CMM) works hand-in-glove with the enterprise architecture in which transformation to/from the CMM is performed at the edges of the integration domain, standardizing as much as possible, payload structure within the integration domain.
The article, whose full text is available at https://blogs.czapski.id.au/wp-content/uploads/2012/09/SOASuiteHCI_ch5_CanonicalMessage_v0.1.0.pdf, works through the mechanics of deriving a Canonical Message Model for the series of articles on SOA Suite for healthcare integration using the “Oracle SOA Suite for healthcare integration” tooling. It contains an abridged version of the article “Healthcare Enterprise – IT Architecture Building Blocks – Canonical Message Model for a HL7 Enterprise”, available at https://blogs.czapski.id.au/2010/10/healthcare-enterprise-%e2%80%93-it-architecture-building-blocks-canonical-message-model-for-a-hl7-enterprise, but adds new material related to testing the canonical structure against sample data and modifying the structure to accommodate data idiosyncrasies.

Aug 26

To develop HL7 v2 messaging solutions which use the SOA Suite for healthcare integration one needs a working development and deployment environment.

This article provides references to components which must be obtained and installed to get a working environment in preparation for development of solutions presented in possible future articles.

This article and the remaining articles assume a development environment based in Microsoft Windows XP 64-bit. Nothing, except the instructions for downloading Windows-specific components and screenshots of Windows-specific non-SOA Suite tools, prevents you from developing on any of the other supported platforms. Convers my Windows-specific instructions to your platform-specific instructions as needed.

The full text of this article is available as “SOA Suite for healthcare integration Series – Overview of the Development Environment” at https://blogs.czapski.id.au/wp-content/uploads/2012/08/SOASuiteHCI_ch2_Dev_Environ_v0.1.0.pdf.

 

Aug 25

In my past articles I presented, amongst other things, HL7 v2 messaging solutions using the Oracle SOA Suite 11g R1 B2B HL7 infrastructure. At the beginning of the calendar year 2012 Oracle released a new incarnation if its HL7 messaging capability under the name of the “SOA Suite for healthcare integration”. This capability builds on the SOA Suite B2B HL7, adding design, configurator, monitoring and management user interface capabilities which greatly simplify the task of creating HL7 v2 messaging solutions and enhance management and operational reporting.
The new and changed functionality is significant enough for me to consider writing a series of articles on the topic. The series is intended to walk the reader through the tasks of creating specific HL7 v2 messaging solutions using the SOA Suite for healthcare integration.
At this point in time I expect to produce articles on the following topics, in the order given:

  1. Overview of the Development Environment – this article
  2. A Very Brief Overview of HL7 v2 Messaging
  3. A Very Brief Overview of the SOA Suite for healthcare integration
  4. Creating a Canonical Message Model – https://blogs.czapski.id.au/2012/09/soa-suite-for-healthcare-integration-series-creating-a-canonical-hl7-v2-message-model
  5. HL7 v2 Inbound to File – https://blogs.czapski.id.au/2012/11/soa-suite-for-healthcare-integration-series-hl7-v2-inbound-to-file-solution
  6. Constructing file name from message content and messaging properties – https://blogs.czapski.id.au/2012/11/soa-suite-for-healthcare-integration-series-hl7-v2-inbound-to-file-solution
  7. HL7 v2 Inbound to HL7 v2 Outbound Pass-through – https://blogs.czapski.id.au/2012/12/soa-suite-for-healthcare-integration-series-hl7-v2-inbound-cmm-to-outbound-pass-through-solution
  8. Transformation and Routing using XSL and Mediator – https://blogs.czapski.id.au/2012/12/soa-suite-for-healthcare-integration-series-routing-and-transformation-using-xsl-solution
  9. Adding Data Map for pass-through code translation – https://blogs.czapski.id.au/2013/01/soa-suite-for-healthcare-integration-series-domain-value-map-dvm-on-the-fly-code-mapping
  10. Automating Exception Message Handling – https://blogs.czapski.id.au/2013/01/soa-suite-for-healthcare-integration-series-exception-handling-processing-endpoint-errors
  11. Externalise, “Repair” and Resubmit “broken” messages – https://blogs.czapski.id.au/2013/01/soa-suite-for-healthcare-integration-series-externalise-repair-and-resubmit-broken-messages
  12. Implementing an A19 Query Processor – https://blogs.czapski.id.au/2013/01/soa-suite-for-healthcare-integration-series-implement-an-a19-query-processor
  13. Send, Receive and Translate HL7 messages using B2B Web Services
  14. Other Key Features
  15. HL7 v2 solution using JMS “the Java CAPS way” – https://blogs.czapski.id.au/2013/02/soa-suite-for-healthcare-integration-series-hl7-v2-solution-using-jms-the-java-caps-way (this article was propmpted by correspondence with Steve L)

It will take some time to produce these articles and the list may change.
I am interested in hearing from people about other topics they might like to see covered. I will consider suggestions though I am not promising that I will act upon them.
In the following sections I am briefly elaborating on what I expect each topic to cover, and presenting a solution schematic where a solution will be developed.

The article is availabe as “SOA Suite for healthcare integration Series – Series Overview” at https://blogs.czapski.id.au/wp-content/uploads/2012/08/SOASuiteHCI_ch1_Introduction_v0.1.0.pdf.

Dec 29

New release, v0.7, is available – see link below for downloadable archive. Throughput masurements were added. Manpages were updated.

I spend considerable time working with HL7. In the past I used SeeBeyond ICAN and Sun Java CAPS products, and OpenESB with HL7 Binding Component,  to rapidly create MLLP senders and receivers for the HL7 solutions I was building and testing. I also tried, at various times, 7 Scan, Interface Explorer and more recently HL7 Browser. For the blog articles I am writing on HL7 I need simple tooling that allows me to send HL7 v2 delimited messages from a file to a MLLP listener and receive acknowledgements, receive HL7 messages from a sender and retrun acknowledgements, and recently to combine multiple sender message streams into a single stream, with correct acknowledgement handling. The tooling has to be free for me to distribute with the projects and the articles and to use in my day job as well.

Not finding anything that would fit the bill, and that would work reliably enough, I developed my own tools.

I embellished the basic sender a bit so I could send multiple messages, one after the other, from a file, delay between successive sends, generate MSH-10, replace MSH-3-1, MSH-4-1, MSH-5-1 and MSH-6-1, and increase timeout for acknowledgements.

The tools are all old fashioned command line tools – no graphical user interface.

CMDHL7Listener – man page: https://blogs.czapski.id.au/wp-content/uploads/2010/12/CMDHL7Listener.pdf

CMDHL7Sender – man page: https://blogs.czapski.id.au/wp-content/uploads/2010/12/CMDHL7Sender.pdf

CMDHL7Proxy – man page: https://blogs.czapski.id.au/wp-content/uploads/2010/12/CMDHL7Proxy.pdf

Deprecated Distribution: https://blogs.czapski.id.au/wp-content/uploads/2010/12/CMDHL7_v0.5.zip

Current Distribution: https://blogs.czapski.id.au/wp-content/uploads/2010/12/CMDHL7_v0.7.zip

Release 0.5 and 0.7 are free to use by anyone for any purpose and will stay that way. There may not be future releases 🙂
I used HAPI 1.0.1 libraries for HL7 processing – http://hl7api.sourceforge.net/

Oct 23

In any but the simplest of HL7 messaging environments there will be multiple sources and multiple destinations of HL7 messages. It is very unlikely that all, or even a majority of these, will use exactly the same HL7 message structures in terms of versions, optional/mandatory segments, extension Z segments, and so on. A sensible approach to dealing with these kinds of issues, and a key component of the HL7 Enterprise Architecture, is the so called Canonical (or Common) Message Model (CMM). The CMM works hand-in-glove with the enterprise architecture in which transformation to/from the CMM is performed at the edges of the integration domain. This article discusses major considerations and works through the mechanics of deriving a Canonical Message Model for a fictitious Healthcare Enterprise and implementing it using the Oracle SOA Suite 11g HL7 tooling as an example. The article will also discuss and illustrate a mechanism for injecting arbitrary metadata into the canonical message, generated by the B2B Document Editor, in such a way that it is ignored by the Edge-dwelling B2B infrastructure but is significant to the SOA infrastructure.

The text of the article is available at https://blogs.czapski.id.au/wp-content/uploads/2010/10/HB01_OSS11g_HL7CannonicalMessageModel_v1.0.1.pdf

Oct 06

This article is of potential interest to these Sun/SeeBeyond customers who have an investment in moderate and large Java Collaboration Definition-based transformation and mapping rules, and who are looking for ways to reuse as much as possible of the Java code involved, when migrating to the Oracle SOA Suite. The example developed in this article comes from the healthcare domain and uses the HL7 OTDs (Object Type Definitions). This is a deliberate choice because all but the most trivial HL7 transformations will involve hundreds of lines of Java code, therefore are a good candidates for migrating to the SOA Suite Spring Component as means of preserving the code and the effort invested in developing it. This does not make the method domain-specific. On the contrary, the method is applicable to all other domains where JCDs with significant transformation and mapping rules content are used.

Discussion in this article addresses a subset of technologies available in the Java CAPS and in the SOA Suite. Specifically, the Java Collaboration Definitions supported in Java CAPS 5.x and in Java CAPS 6/Repository, and the Spring Component supported in the SOA Suite 11g R1 PS2. Both use the Java programming language and related runtime environment to implement processing logic.  There is no discussion pertaining to JBI-based technologies or Java CAPS BPEL-based technologies. There is no discussion about other ways in which Java logic can be deployed as part of a Oracle SOA Suite solution.

The HL7 eWay and JCD based Java CAPS solution will be ported to the Oracle SOA Suite 11g B2B and Mediator-based environment. HL7 Adapters will be replaced with the Oracle “Healthcare Adapters”, provided by the SOA Suite B2B HL7 support infrastructure. Routing will be provided by the Mediator component and transformation logic will be ported to the Spring Component.

This article walks through the process of “extracting” JCD source and related archives from Java CAPS, developing a stand-alone Java application which uses the JCD source, encapsulating JCD source in a Spring component and finally reproducing Java CAPS HL7 solution functionality in an equivalent SOA Suite solution.

The complete article is available at https://blogs.czapski.id.au/wp-content/uploads/2010/10/08_HL7JCD2SpringComponentMigration_v1.3.pdf

Aug 30

In this article I discuss and illustrate a “SOA-less” solution which uses the Oracle SOA Suite 11g R2 B2B functionality to convert HL7 v2 delimited messages into their equivalent HL7 v2 XML messages. I say “SOA-less” because all the work is done entirely within the B2B part of the SOA Suite – no OSB or SOA Composites are involved.

The article text is available at https://blogs.czapski.id.au/wp-content/uploads/2010/08/06_Oracle_SOA_Suite_B2B_Quick_HL7v2_Delimited_to_HL7v2_XML_Conversion_v1.0.0.pdf

Jun 27

This article is a follow on to the “Oracle SOA Suite 11g HL7 Inbound Example – Functional ACK Addendum” article and the “Oracle SOA Suite 11g HL7 Inbound – Customized HL7 Message Structure and Data Validation” article.  In these articles the B2B infrastructure was configured to return the “Functional ACK” when it validated each message. The ACK was a positive or a negative ACK depending on whether the message passed validation. The ACK was generated by the B2B Layer before the message was passed on to the SOA Layer.

In this article I expand on the previous posts by configuring the B2B Layer to pass the message to the SOA Layer and pass the Functional ACK, generated by the SOA Layer on to the requester. To process a message and produce the ACK we will build and deploy a new SOA Composite.

The text of the article is to be found at https://blogs.czapski.id.au/wp-content/uploads/2010/06/05_Oracle_SOA_Suite_HL7_inbound_example_BackEnd_ACK_Addendum_v0.1.0.pdf.

Jun 26

Messages we used in previous articles dealing with HL7 Inbound (Oracle SOA Suite 11g HL7 Inbound Example – Functional ACK Addendum, Oracle SOA Suite 11g HL7 Inbound Example) were not strictly speaking valid according to the default HL7 V2 ADT A01 message specification produced by the Oracle B2b Document Editor. Both the message structure was not quite right and the data was not quite right. To allow such messages in, we disabled Validation property in the B2B Trading Partnership Agreement.

In this article we will alalyze the data and  create a customized HL7 v2 ADT A01 structure which will allow us to successfully validate incoming messages. We will then modify the document definition and Partnership Agreements to use this custom structure and validate messages as they come in.

The customization discussed in this article only scratches the surface of what is possible with the Oracle B2B Document Editor.

The complete text of the article is available at https://blogs.czapski.id.au/wp-content/uploads/2010/06/04_Oracle_SOA_Suite_HL7_inbound_Customising_Message_Structure_v0.1.1.pdf

Tagged with:
preload preload preload