In the Tools menu from the Main Window click Examples to open the sub-menu to show 4 different HL7 data scenarios. Clicking each one will present a different result.

 

 

10 Generic Example Messages

The software ships with a few example HL7 data files embedded in it. #1 takes a file with generic ADT HL7 messages, writes it out to the Windows TEMP folder and then loads it into the HL7 Viewer. This process is exactly the same as if you were importing HL7 messages from a HL7 data file by clicking the Open HL7 Data File button () on the toolbar.

 

Different Encoding Characters

#2 is the same as #1. It is the same 10 generic messages but this time they are using NON-Standard HL7 Encoding Characters, specifically, these messages use a $ character as the field delimiter instead of a | character (which is standard). The purpose is to show that our HL7 message parser will handle unexpected encoding characters.

 

Messages on the Clipboard

This scenario demonstrates how to use the Windows clipboard. If you have HL7 messages opened in a text editor, hopefully a good one like Notepad++, or even (shudder) Windows Notepad or Microsoft Word, you can copy them to the Windows clipboard and we will try and import them into the CORE HL7 Viewer.

 

Malformed Messages

Never assume that your data is perfect. Even the best of us can make mistakes and this is true in the world of HL7 as well. HL7 messages can be structurally 'malformed' in many different ways. The problem gets compounded when you consider that different software packages (ours included) all might use different parsing algorithms, some of which will handle a specific abnormality, while others do not. This prompts the very common support issue of "Your software will load this message, but their software will not!" OR (to be fair) "Their software will load this message, but your software will not!". Scenario #4 presents what we have found to be the most common, and most insidious, malformation which we have seen occur. A stream of text which purports to be a valid HL7 message which has a Segment Delimiter (SOM) character embedded in the middle of the data somewhere. This usually occurs when HL7 creators are tying to embed text notes or reports into a message and neglect to properly ESCAPE the New Line character(s) IE Carriage Return or New Line or both. See Malformed Messages for a further discussion on how the CORE HL7 API parser works and how we identify malformed HL7 data.