Introduction

This is part of my HL7 article series. Let me mention something quickly before we get started. The area that I am exploring in this article is an extremely complex one, and the HL7 group and other related organizations such as NIST, IHE, etc. have published hundreds if not thousands of documents, tutorials, whitepapers, etc. some of which are available freely and some may be for members only to help you get started. These documents should be what you and your team should ultimately rely on during for any implementation. However, my goal in this short tutorial is to simply highlight and help bring attention to this important area since interoperability is often the ultimate goal of any message exchange-based workflow. Armed with some fundamentals provided in this article, you should be able to explore these topics more deeply on your own. As you explore these topics further on your own, you may run into documents that were published a long time ago and may not have been updated more recently. This is very common. The HL7 standard (2.x version) has been around for a long time, and so, several critical tools, documents and other links on this subject (some of which I cover in this article) are extremely old and have not been updated in a long time. Like many other large standards organizations, things do take a long time to move forward within the HL7 standard. This is because any activity almost always requires consensus/approval from many members, groups, committees and other partner organizations to move forward. A lot of work in this area is ultimately achieved through volunteer effort. And so, if you are frustrated about anything, perhaps you can contribute to any efforts in that area. When in doubt, always contact your regional affiliate, or its main site here directly for more information. I am not an expert this area and may not be able to answer every question and so, please be ready to research or reach out to other experts in the field on this or any other topic that I have covered in this article series. If you want to ramp up your knowledge on the prerequisites required to following along, have a look at my earlier articles in this tutorial series.

HL7 Message Profiles

A message profile in the HL7 2.x standard is a precise and unambiguous specification of a HL7 message that has been "constrained" to be used towards a specific set of requirements. The word "constraint" refers to the idea of reducing the optionality within the definition of a specific message so there can be no confusion as to the mandatory information and behavior that can expected from one another by each party involved in the message exchange. However, there is more to message profiles than simply reducing optionality. The definition defines things such as the static structure of the messages, the content of the HL7 message carried by these structures, and also any "dynamic interaction characteristics" of the message flow which explain how and when the messages are communicated from the sending application to one or more receiving applications.

The overall information communicated between the various parties involved when specifying conformance or message profile includes information such as:

• Use case information that describes what the goal of the message exchange is and who the actors are in this message exchange
• Interaction information that describes the collaboration between the actors (parties) involved
• Authorship and organizational information of the message profile
• Role or perspective from which this information is written (Sender or Receiver for instance)
• Version of the HL7 message as well as the message trigger type and event
• Structural information of the HL7 message such as optionality, cardinality, length and content that is permitted within it
• A set of user-defined table values to be used within the fields used in the message segments
• Information whether a specific HL7 message requires an accept acknowledgment or an application acknowledgment
• A unique identifier to help to distinguish profile definitions from others (HL7 group may assign one if this is empty when submitting to a global registry)

“Humanity’s true moral test, its fundamental test…consists of its attitude towards those who are at its mercy: animals.” ~ Milan Kundera

All this information is encoded into an XML file with a precisely defined XSD schema declaration (see screenshot below showing the XSD for this file) enabling easy validation through any XML processor to ensure that the encoded information is acceptable for use by other tools, applications and end users. Several tools and approaches are also used in conjunction with this XML file to create, exchange, test and validate any message interface. We will look at how they all work together next.

Messaging Workbench

Although the XML-based message profile file can in theory be generated by hand, it can be a tedious activity. Therefore members, vendors and various implementors have came up with various tools and approaches over the years to automate the generation of this file. One such tool is the Messaging Workbench. This is a free Windows desktop tool that enables the development of the message profile and was developed out of a healthcare initiative undertaken by the Department of Veteran Affairs in the United States. The message profile to me is really a consolidation of three sub-profiles (message, segment and field levels), and its helps reduce any ambiguity as far as structure, content and any message acknowledgement behaviour pertaining to the message. A screen shot of the tool is shown below highlighting some areas that will be worth noting for now. Commercial tools also happen to exist that help automate the production of these message conformance profiles, but I cannot vouch for the accuracy and/or stability of such tools on the market as I have not used them myself.

There are a lot of convenient features in the Messaging Workbench tool including the following:

• Start with and/or easily customize pre-built "starter" message profiles
• Ability to compare the differences between two message profiles on an element by element basis
• Ability to capture and reverse engineer message profiles from sample HL7 messages
• Generate various reports highlighting many message profile characteristics
• Export the message profile definition in PDF format reports
• Register the message profile in the local repository
• Register the message profile with HL7
• Browse and download message profiles from the HL7 registry

You can find a link to the download page as well as usage instructions for the Message Workbench here. Installing the application should be straight forward as there is an installer provided (use the "setup.exe" to launch the installation) and the application should install normally like any other Windows programs. The program comes with some helpful documentation, but you may find this a bit overwhelming if you are just getting started with it. Read the documentation before getting started or contact your HL7 regional affiliate, or the HL7 main site here directly if you have any questions.

I created a quick messaging workbench project and generated a sample message profile using the workbench and have included the files in my GitHub page for your reference. As you can see from the screenshots shown below, the workbench project enables you to define the structure and content that is permitted for a message processing workflow, the role that each actor plays in the messaging workflow as well as the message acknowledgement behavior that is expected for the transmitted messages. For our example, I am specifying an ADT A01 message with four message segments and have arbitrarily defined various rules such as cardinality, optionality, length, code set rules, etc. for the segments as well as the fields within these segments. To enable testing within the messaging workbench itself, I have also used a sample ADT A01 message (also provided in my GitHub page) which intentionality does not conform to many of the rules such as length as well as permitted data within code-set enabled fields.

A nice feature of the Messaging Workbench is that you can easily test how well a HL7 message matches up to your message profile. Screenshot shown below shows me testing a sample ADT A01 message against the message profile under development. A list of validation errors and warnings generated are shown in the screenshot below for your reference.

Once you have completed specifying the message profile characteristics within the messaging workbench, you should be able to generate the message profile XML file using the export options provided under the "File" menu of the application. For our example, I used the "Export HL7 Conformance Profile" menu to generate the XML file. Unlike the HAPI Java HL7 Toolkit, NHAPI does not offer support for programmatic validation of the conformance profile yet. You can review my other article HL7 Programming using Java and HAPI - Conformance Profiles and Testing to learn more about how this is implemented in the HAPI toolkit for Java. Hopefully, this gap is addressed for developers using the NHAPI toolkit sometime soon as well.

“To me, every hour of the day and night is an unspeakably perfect miracle” ~ Walt Whitman

Message Maker

Once you have the message profile (see screenshot of the XML file above), you can either upload it to a global registry or distribute it to a partner directly who can proceed to use the information in several ways. One interesting way to use the message profile is to help generate test HL7 messages using a tool called "Message Maker". This tool uses the message profile definition information contained within the XML file to create a test suite of both valid and invalid HL7 messages to enable the implementors to test for both good as well as bad scenarios when implementing this interface specification. The test messages generated can be output in multiple formats including ER7 and XML which can be used for any development and testing related efforts of the parties working towards the implementation of this message interface. Screenshot of the message maker tool is shown below for reference. You can find a link to the download page as well as usage instructions for the Message Maker here.

Validation and Testing Tools from IHE

In addition to the tools and techniques listed above, there is another set of testing and validation tools available from a group known as "Integrating the Healthcare Enterprise (IHE)". The primary goal of this group is to enable any coordination as well as standardization efforts especially from an implemention standpoint using standards such as HL7, DICOM, etc. This group creates as well as publishes numerous frameworks, handbooks, case studies and other resources to help make the implementation work of healthcare systems easier. For example, this group publishes something known as "IHE Profiles" which helps customers and vendors involved in both the buying and selling of healthcare systems by enabling an unambiguous way of verifying or claiming adherence to specific "use case profiles" that were previously validated/vetted by numerous testing groups representing many diverse areas within healthcare such as cardiology, pathology, laboratory medicine, etc. Through the use of the validation tools also offered by IHE, vendors and customers can test their systems against the many use cases described by these profiles. For example, the Anatomic Pathology Workflow is one such example of an IHE profile which helps test and validate conformance around aspects such as ordering, reporting, imaging that are all necessary to support any healthcare information flows pertaining to surgical pathology, clinical autopsy and cytopathology within a clinical setting. I plan on writing a separate tutorial on IHE and IHE profiles in the near future, so I will simply direct your attention to their main website for now.

Conclusion

This short tutorial covered the concept of conformance (or "message profiles" as they are known in the HL7 2.x standard) and how they are utilized during message validation process. Message profiles help precisely define the structural (static) and behavioral (dynamic) constraints of a message interface. The use of message profiles promotes interoperability by providing message exchange partners a common format for documenting, communicating, developing and testing message interfaces that conform to strict HL7 interface specifications which help enable interoperability. We reviewed several tools in this tutorial that are available from HL7 and organizations such as NIST to assist us in these efforts. These included the Message Workbench Tool, the Message Maker tool, the OID Registry and the HAPI library classes that enable the creation, exchange and validation of HL7 message interfaces. Like I mentioned earlier, there is a lot more to this subject, and I hope you will be able to explore this area a lot more easily armed with the information provided here. In our next (and last) tutorial in the HL7 programming using tutorial series, I will cover how to receive HL7 messages using a message integration engine called HL7Fuse that is built using the NHAPI framework as well as the NHAPI Tools Framework that we had exposure to earlier for the purposes of HL7 message validation. See you then!