Mar 08

Since Sun Microsystems started the Java Business Integration specification work, and subsequently started releasing the OpenESB platform and components around 2006, until Sun was acquired by Oracle around 2010, I published a number of blog articles dealing with different aspects of the JBI-based technologies embedded in the OpenESB, GlassFish ESB and Java CAPS/JBI. I lost interest in the topic when Sun acquisition was completed and it became clear to me that the JBI specification will not be supported by Oracle other as part of the legacy Java CAPS/JBI and the GlassFish ESB products. Around the same time there was a fair bit of activity around the OpenESB community aimed at working out whether and how OpenESB can be picked up by the community, perhaps development branch forked so it can be controlled by the community, etc.. Since I did not expect that effort to lead anywhere I stopped following these discussions and eventually OpenESB mailing lists to which I was subscribed disappeared to be replaced by others to which I did not subscribe.

I never went back to my original blog articles to see if they are still implementable and whether the software used in them is still available. Needless to say some articles can no longer be implemented as written and the links to the OpenESB / GlassFish ESB distributions which I provided in my articles no longer lead anywhere useful.

Recently I had an occasion to look at some of the articles and it occurred to me that perhaps they can be updated if OpenESB is available somewhere, so people can still try them. I did put a fair bit of effort into the articles and it is such a waste to have the solutions unimplementable. I went looking for OpenESB distributions to see if they are available, what state they are in, and whether anyone cares. It turned out that LogiCoy (http://www.logicoy.com/) maintains and develops OpenESB, at least one distribution of which is publically available, and I know some of the people at LogiCoy who are working on this platform. I understand from them that a new release, v2.3 (of which a Beta version is available at the community site – http://www.open-esb.net/) will be officially released sometime this month. Once the release is available I will come back to this article to provide the link to it and perhaps to the installation documentation.

In the spirit of “Jacques Brel is Alive and Well and Living in Paris” (http://en.wikipedia.org/wiki/Jacques_Brel_is_Alive_and_Well_and_Living_in_Paris) I decided to have a look at my JBI articles and release updated versions using the OpenESB distribution released to the community by LogiCoy’s. This will happen as time and motivation permit.

In this article I am listing articles which I may get around to updating to work with LogiCoy’s version of OpenESB, and their status (Not started, Updated, Never to be worked on again). This blog entry is available at http://blogs.czapski.id.au/wp-content/uploads/2013/03/OpenESBIsALiveAndWellAndLivingIn…_v0.1.0.pdf.

 

Feb 10

This article leverages discoveries from the 2+ year old article “Migrating Java CAPS 5/6 Assets to Oracle SOA Suite 11g – HL7 JCD to Spring Component Migration”, at http://blogs.czapski.id.au/2010/10/migrating-java-caps-56-assets-to-oracle-soa-suite-11g-hl7-jcd-to-spring-component-migration,  and presents a different method of reusing “HL7 Transformer JCD” code in a SOA or OSB solution. This method uses SOA Suite for healthcare integration, slightly modified Java code for a “HL7 Transformer JCD” and WebLogic JMS. The Java CAPS part of the discussion is substantially the same, except the JCD code is wrapped in a SOA Suite for healthcare integration Callout, rather than being converted to a Spring Component embedded in a SOA Campsite. The “HL7 Adapter” part of the article is different in that SOA Suite for healthcare integration is used instead of the SOA Suite B2B HL7 functionality.
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 or the Oracle Service Bus. 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 migration. The adapter part of the HL7 solution is provided by the SOA Suite for healthcare integration. This makes the method domain-specific.
Discussion in this article addresses a subset of technologies available in the Java CAPS and in the SOA Suite for healthcare integration. Specifically, the Java Collaboration Definitions supported in Java CAPS 5.x and in Java CAPS 6/Repository, and the SOA Suite for healthcare integration (part of the SOA Suite 11g R1 PS5).
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 an Oracle SOA Suite solution.
The HL7 eWay and JCD based Java CAPS solution will be ported to the Oracle SOA Suite for healthcare integration and Java-based environment. HL7 Adapters will be replaced with the HL7 endpoints provided by the Oracle SOA Suite for healthcare integration infrastructure. What minimal routing is used will be provided by the Mediator component via JMS Queues. Transformation logic will be ported to the Java POJO (Plain Old Java Object) and will be embedded in the endpoint as a document callout.
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 SOA Suite for healthcare integration callout and finally reproducing Java CAPS HL7 solution functionality in an equivalent SOA Suite for healthcare integration solution.
The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2013/02/09_HL7JCD2DocumentCalloutMigration_v1.0.1.pdf.

Data files used in this article series are available at:

ADT_A01_output_1.hl7 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_1.zip – this file contains a single ADT A01 transaction

Feb 03

This article may be of interest to these who would like to use the “SOA Suite for healthcare integration” HL7 v2 delimited message handling functionality in solutions similarly to how Oracle Java CAPS HL7 eWay-based solutions were built, perhaps as endpoints in a “Service Bus”-based infrastructure, or to these who would like to use the HL7 messaging handing functionality in OSB environments. In essence, for these unfamiliar with the Java CAPS pattern of use, there were the “Inbound HL7 eWay” and the “Outbound HL7 eWay” patterns. An inbound HL7 v2 Adapter (eWay) would receive a HL7 message, perform all (minimal) validation and acknowledgement processing and store the incoming message in a persistent JMS Queue for some downstream component to process the message as necessary. An Outbound HL7 v2 Adapter (eWay) would read a HL7 message from a JMS Queue (where it was deposited by some upstream component) and send it out to the external system, performing any HL7 ACK processing that might have been required.
In the prior articles in this series we used direct integration between the HL7 v2 endpoints and SOA Suite Composites which provided processing logic. While in my articles JMS is used implicitly as an internal mechanism (via B2B_IN_QUEUE and B2B_OUT_QUEUE JMS queues) the SOA Suite composite did not explicitly use JMS adapters.
It is possible to configure SOA Suite for healthcare integration endpoints in such a way that messages the inbound endpoint receives will be deposited in a particular JMS destination (queue or topic other than the B2B_IN_QUEUE) associated with the endpoint, and messages to be sent by an outbound endpoint will originate in a specific JMS destination (queue or topic other than the B2B_OUT_QUEUE). This will allow such endpoints to be used in Oracle Service Bus-based or other ESB-based solutions as services with JMS interfaces.
In this article we will develop and exercise an inbound-to-JMS and JMS-to-outbound HL7 v2 delimited message processing solutions to demonstrate this capability.

The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2013/02/SOASuiteHCI_ch15_Inbound_HL7v2Delimited_The_JavaCAPS_Way_v0.1.0.pdf.

Data files used in this article series are available at:

ADT_A01_broken_1.hl7 – http://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 – http://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 – http://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 – http://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 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/QRY_A19.zip – this file contains a sample A19 query message

Jan 05

While most HL7 v2 messaging is of the store-and-forward kind, where a sender sends a message to a partner, receives a positive acknowledgement and forgets the transaction, there are circumstances where a sender wants to query the receiver and get and process a response. For ADT-related queries A19 transaction serves this function. A client application can send an A19 QRY message, with a patient identifier and assigning authority and request patient demographic information to be returned using the A19 ADR response message.
In this article we will develop and exercise an A19 Query Processor solution.
This article assumes that the reader has the SOA Suite for healthcare integration environment with all necessary components installed and ready to use. The Bill of Materials for such an environment and a discussion on where the components can be obtained is provided in the earlier article, “SOA Suite for healthcare integration Series – Overview of the Development Environment”, to be found at http://blogs.czapski.id.au/2012/08/soa-suite-for-healthcare-integration-series-overview-of-the-development-environment.

The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2013/01/SOASuiteHCI_ch12_A19Query_v0.1.0.pdf.

Data files used in this article series are available at:

ADT_A01_broken_1.hl7 – http://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 – http://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 – http://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 – http://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 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/QRY_A19.zip – this file contains a sample A19 query message

Jan 04

Every now and then a situation may arise where a message sent to a downstream system is rejected or a message arriving from an external system, is rejected. Some of the possible issue could be “fixable” and others not. If message is “fixable”, in the sense that its content or structure can be modified and the re-submitted modified message will be accepted, then the operator must follow the steps necessary to extract, repair and resubmit the message. In other circumstances it may be necessary to resubmit a specific batch of messages to an external system, for a particular time period or of particular kind.

In this article we will walk through the process of externalizing a message, “fixing” it and resubmitting it for processing. We will also briefly touch on other uses of the resubmit utility.

More details on the technical aspects of this topic can be found in the Oracle “Technical Note: 11g_005 Command-Line Utilities”, section “Resubmit Utility”, available at http://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/326860.pdf.

This article assumes that the reader has the SOA Suite for healthcare integration environment with all necessary components installed and ready to use. The Bill of Materials for such an environment and a discussion on where the components can be obtained is provided in the earlier article, “SOA Suite for healthcare integration Series – Overview of the Development Environment”, to be found at http://blogs.czapski.id.au/2012/08/soa-suite-for-healthcare-integration-series-overview-of-the-development-environment.

This article assumes that the reader completed the solution discussed in the earlier article, “SOA Suite for healthcare integration Series – Exception Handling – Processing Endpoint Errors”, to be found at http://blogs.czapski.id.au/2013/01/soa-suite-for-healthcare-integration-series-exception-handling-processing-endpoint-errors.  

The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2013/01/SOASuiteHCI_ch11_ExternaliseRepairAndResubmit_v0.1.0.pdf.

Data files used in this article series are available at:

ADT_A01_broken_1.hl7 – http://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 – http://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 – http://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 – http://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

 

Jan 03

In this article we will add exception handling to the routing and transformation solution developed in the article entitled “SOA Suite for healthcare integration Series – Domain Value Map (DVM) – On-the-fly Code Mapping”, to explore how message processing exceptions can be redirected to a logic component for handling. The exception handling components will handle exceptions form all SOA Suite for healthcare integration applications.
This article assumes that the reader has the SOA Suite for healthcare integration environment with all necessary components installed and ready to use. The Bill of Materials for such an environment and a discussion on where the components can be obtained is provided in the earlier article, “SOA Suite for healthcare integration Series – Overview of the Development Environment”, to be found at http://blogs.czapski.id.au/2012/08/soa-suite-for-healthcare-integration-series-overview-of-the-development-environment.
This article assumes that the reader completed the solution discussed in the earlier article, “SOA Suite for healthcare integration Series – Domain Value Map (DVM) – On-the-fly Code Mapping”, to be found at http://blogs.czapski.id.au/2013/01/soa-suite-for-healthcare-integration-series-domain-value-map-dvm-on-the-fly-code-mapping
 
The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2013/01/SOASuiteHCI_ch10_ProcessingEndpointErrors_v0.1.0.pdf.

Data files used in the article series:

ADT_A01_broken_1.hl7 – http://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 – http://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 – http://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 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/ADT_A01_output_5099.zip – this file contains 5099 ADT A01 transactions, separated by \r\r\n, or Carriage Return, Carriage Return and New Line

 

Jan 01

In this article the routing and transformation solution developed in the article entitled “SOA Suite for healthcare integration Series – Routing and Transformation using XSL Solution, will be extended to add an on-the-fly code mapping. This does not have anything to do with HL7 or HL7 processing, or indeed SOA Suite for healthcare integration infrastructure, but since the task is a pretty common one in the HL7 messaging world, it will be discussed and illustrated.
This article assumes that the reader has the SOA Suite for healthcare integration environment with all necessary components installed and ready to use. The Bill of Materials for such an environment and a discussion on where the components can be obtained is provided in the earlier article, “SOA Suite for healthcare integration Series – Overview of the Development Environment”, to be found at http://blogs.czapski.id.au/2012/08/soa-suite-for-healthcare-integration-series-overview-of-the-development-environment.
This article assumes that the reader completed the solution discussed in the earlier article, “SOA Suite for healthcare integration Series – Routing and Transformation using XSL Solution”, to be found at http://blogs.czapski.id.au/2012/12/soa-suite-for-healthcare-integration-series-routing-and-transformation-using-xsl-solution.

The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2012/12/SOASuiteHCI_ch9_DominValueNap_OnTheFlyCodeMapping_v0.1.0.pdf

Data files used in this article series are available at:

ADT_A01_broken_1.hl7 – http://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 – http://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 – http://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 – http://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 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/QRY_A19.zip – this file contains a sample A19 query message

Dec 26

In this article the router, developed in “SOA Suite for healthcare integration Series – HL7 v2 Inbound CMM to Outbound Pass-through Solution”, to be found at http://blogs.czapski.id.au/2012/12/soa-suite-for-healthcare-integration-series-hl7-v2-inbound-cmm-to-outbound-pass-through-solution, will be extended to add a fan-out for distribution of one inbound message to two outbound receivers and a ADT A01/A03 to ADT A08 transformation using the eXtensible Style Language (XSL). SOA Suite for healthcare integration Dashboard functionality will also be explored.

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.

This article assumes that the reader has the SOA Suite for healthcare integration environment with all necessary components installed and ready to use. The Bill of Materials for such an environment and a discussion on where the components can be obtained is provided in the earlier article, “SOA Suite for healthcare integration Series – Overview of the Development Environment”, to be found at http://blogs.czapski.id.au/2012/08/soa-suite-for-healthcare-integration-series-overview-of-the-development-environment.

This article assumes that the reader completed the solution discussed in the earlier article, “SOA Suite for healthcare integration Series – HL7 v2 Inbound CMM to Outbound Pass-through Solution”, to be found at http://blogs.czapski.id.au/2012/12/soa-suite-for-healthcare-integration-series-hl7-v2-inbound-cmm-to-outbound-pass-through-solution.
 
The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2012/12/SOASuiteHCI_ch8_RountingAndTransformatonUsingXSL_v0.1.0.pdf.

Data files used in this article series are available at:

ADT_A01_broken_1.hl7 – http://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 – http://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 – http://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 – http://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 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/QRY_A19.zip – this file contains a sample A19 query message

Dec 08

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. A more sophisticated solution will receive an inbound message and send it out to an external system, possibly transforming it before sending.
This article works through the mechanics of configuring the “SOA Suite for healthcare integration” to send a HL7 v2.3.1 ADT message as a Canonical Message, extending the solution developed in the previous article, “” to be found at .
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.
This article assumes that the reader has the SOA Suite for healthcare integration environment with all necessary components installed and ready to use. The Bill of Materials for such an environment and a discussion on where the components can be obtained is provided in the earlier article, “SOA Suite for healthcare integration Series – Overview of the Development Environment”, to be found at http://blogs.czapski.id.au/2012/08/soa-suite-for-healthcare-integration-series-overview-of-the-development-environment.
This article assumes that the reader completed the solution discussed in the earlier article, “SOA Suite for healthcare integration Series – HL7 v2 Inbound to File Solution”, to be found at http://blogs.czapski.id.au/2012/11/soa-suite-for-healthcare-integration-series-hl7-v2-inbound-to-file-solution.

The complete article is available at http://blogs.czapski.id.au/wp-content/uploads/2012/12/SOASuiteHCI_ch7_InboundCMM2Outboud_Passthrough_v0.1.0.pdf.

Data files used in this article series are available at:

ADT_A01_broken_1.hl7 – http://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 – http://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 – http://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 – http://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 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/QRY_A19.zip – this file contains a sample A19 query message

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 http://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 – http://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 – http://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 – http://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 – http://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 – http://blogs.czapski.id.au/wp-content/uploads/2013/01/QRY_A19.zip – this file contains a sample A19 query message

preload preload preload