Quick review, HL7 (Health Level Seven) is an organization that provides a framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information. These standards define how information is packaged and communicated from one party to another, setting the language, structure, and data types required for seamless integration between systems. 
HL7 version 2 is one of the older standards that is still widely used today. It is a pipe-delimited data structure. Compared to other data structures like JSON or XML, this is not easily understood.
Below is an example of a results message.
OBR|1||PLA20200812^FIL20200812|FREEPSA^FREE PSA-PSA II W TOTAL^L|R||20200807185800|||||||20200807185800|LABX^LAB X DIAGNOSTICS^|111111111^Luna^Juan||||||20200807185800|||F||^^^^^R
OBX|2|NM|FREEPSAR2^PSA Free^L||0.09|ng/mL|||||F|||20200807185800|LABX^LAB X DIAGNOSTICS^
OBX|3|NM|FREEPSAR3^PSA Total^L||0.3|ng/mL|<=4.0||||F|||20200807185800|LABX^LAB X DIAGNOSTICS^
You can see from the example above that it’s the friendly to the eyes. Identifying where the patient details and lab result information is a challenge.
These are the parts of the HL7 v2 message with their delimiters:
- Segments – These are the parent sections of the message separated by a carriage return or line break. In the example above, these are the MSH, PID, PV1, ORC, OBR, and OBX. The first 3 alphanumeric characters are the segment code. Each has its own meaning. examples are MSH is the message header and PID would be the patient information.
- Fields – These are the child nodes of the parent section, and are separated by a pipe delimiter or “|”. Each field pertains to specific information, with the exception of the MSH where the 1st field is the delimiter character “|”.
- The 2nd MSH field states the encoding characters. Recommended value on that field ^~\& (ASCII 94, 126, 92, and 38).
- ^ – Use for component separator
- ~ – Use for repeating separator
- \ – Use as an escape character
- & – Use as the subcomponent separator
When reading positions or fields, best to approach it in a key-value pair object. Example, the position of the 2nd field in the MSH segment would be MSH.2. Having children the index would be added in the name like MSH.2.1, MSH.2.2, MSH.2.3, and so on.
When working with HL7 v2 messages, you need to primarily identify the Message Type, Trigger Event, Data Types, and Tables.
- Message Type – The code to be set in MSH.9.1. This defines what the message is for. For our example above, ORU is the message type that defines an unsolicited transmission of an observation message. Lab results can be considered as an observation message in this case, although unsolicited would mean they are not expected by the receiving application. If you took the HL7 v2 fundamentals in HL7.org, you can find the message types in Appendix A.
- Tables – These are table references that you can look up for the suggested values for data types, event codes, and other standardized values.
- Trigger Events – These are codes that state on what case scenario the message applies. In our case, it’s RO1 which means ORU/ACK – Unsolicited transmission of an observation message based on Table 0003 which is found in Chapter 2 “Control” of the HL7 v2 resource standard. This table is a reference list for the event type codes.
- Data Types – This defines the type of data expected from the segment and its fields. This allows you and the recipient to add validation on the data value. Examples of this are ST for string, NM for numeric, ED for encapsulated data. You can find the datatype codes in Table 0440 in Chapter 2.
Hopefully, that helped you to get a quick overview of how HL7 v2 messages are structured. One great website I lookup for definitions is Caristix.com.