I'd have to pick none of the above. Honestly, that first one just looks like gibberish. Not that XML is any better, but still... Just total gibberish.

It's actually rather simplistic and all your information is viewable in a tight, concise manner.

Each message that comes across a network interface has an MSH segment, a Message Header. The message header displays information like who sent the message, who's supposed to receive it, what type of information are you going to find in the message, when was it sent, etc.

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4

Each line of the message consists of a 3 letter identifier that tells you what information is going to be housed in the following line. Such as the MSH(Message Header), PID (Patient Identification), OBR(Oberservation Request), OBX (Oberservation Result), etc. These lines are known as Segments.

Each segment contains a host of fields, sub fields, sub-sub fields, etc.

Each field is separated by a | delimiter, which each field containing a particular set of standardized data.

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4

Take for instance the MSH segment - Field number 9. This field states the Message Type (what type of information you can expect to see in the rest of the message). MSH-9 in this example has a field and subfield delimited by the ^ symbol. The caret delimits fields and subfields.

So MSH-9.1 is the Message Type, and MSH 9.2 (Subfield) is the Message Event.

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4

The message structure looks like this:

[Message (Type & Event]

[Segment]

[Field]

[Subfield]

[Field]

[Subfield]

[Segment]

[Field]

[Subfield]

[Field]

[Subfield]

[Segment]

[Field]

[Subfield]

[Field]

[Subfield]

...and so on...

Anyways, figured I'd share. It's not often I get to speak about my profession as it's so niche.

So you have to memorize a bunch of three-letter acronyms as well as memorizing standard field layouts in order to make sense of it? I can see how that would be somewhat easier for the expert, but not so much for anyone who hasn't spent their career memorizing such things.

Not quite. There are a load of tools out there that does this for you. Most of the tools you use to build the interfaces have this automatically added to them. Much like trying to figure out where everything is in the BCL in .NET, Intellisense works wonders, as well as the Library Explorer.

That being said. Most people revert back to the standard specifications that are released by HL7.org, as this positional data tends to change slightly depending on the version of the standard you're using. (Again, much like the different .NET Framework versions)