T2

Appendix A: HL7 Implementation Guidelines

1. Populating the PID Values for a Patient Search

The system sending an Observation Reporting Query request should populate as many of the PID segment values as it knows. Each SNO that receives the search query uses its own search algorithm and decides which of the incoming PID values it will use. The only values that are guaranteed to be used are the patient name, birth date, and gender.

2. CX Identifier Values

When HL7 messages are being sent between systems, CX values may present difficult implementation issues. CX values as used for institutional medical record numbers, ancillary system order numbers, physician order entry order numbers, insurance policy numbers, driver license numbers, credit card numbers, billing account numbers, patient visit numbers, etc. Our HL7 implementation pays attention to the CX.1 (Identifier), CX.2 (Check digit), CX.4 (Assigning authority), and CX.5 (Identifier type code) sub-component values. We generate CX.6 (Assigning facility) component values in our outgoing messages, when appropriate.

We concatenate the incoming CX.1 (Identifier) and CX.2 (Check digit) components, strip off leading zeroes, and consider the result as the CX identifier/number value. On HL7 output, we value the Identifier component with the identifier value defined above. The Check digit component is always empty in our outgoing message.

The CX.4 (Assigning authority) value defines the identifier “pool” or “namespace” in which the Identifier was generated. We require it to be valued because we represent every patient, order, account, and visit identifier (etc.) as a pair: the actual identifier/number plus the “namespace” within which that identifier is unique. In the HL7 message, the Assigning authority is an HL7 HD data type.  HL7 defines two different ways in which it can be valued. A value in the first HD sub-component (Namespace ID) is a universally agreed upon label for the identifier “pool” or “namespace.”  It is conceptually similar to an HL7 OID.  Alternatively, the second (Universal ID) and third (Universal ID type) HD sub-components may combine to specify the identifier namespace. When we receive an HL7 CX value to be stored in our database, we look into our table of valid Assigning authority values. If we find a match for the Namespace ID sub-component value, all is well and we look no further.  If Namespace ID is not valued or we do find a match for it, we try to match on the combined Universal ID and Universal ID type component values. Our database contains all three HD sub-component values for every Assigning authority.  When we generate a CX value in an outgoing HL7 message, we value all three CX.4 (HD) sub-components.

The CX.5 (Identifier type code) value defines the type or category of the identifier. Across HL7 messages and fields, we place importance on “AN” to indicate a billing account number, “DN” to indicate a doctor number, “MR” to indicate a medical record number, “SS” to indicate a social security number, and “VN" to indicate a patient visit number. 

3. OBR (Order) and OBX (Observation result) Service Codes

We strongly suggest that LOINC codes be used for OBR.4 (Universal Service ID) and OBX.3 (Observation identifier) CE values.

4. PID.8 (Sex) Codes

We support values of "M," "F," and "U." The CE.2 (Text) and CE.3 (Name of coding system) component values can be supplied but we ignore them when performing a patient lookup.

5. Code Values

Each HL7 CE data value contains up to six components. The first three are Identifier, Text, and Name of coding system. When supplying a coded value, these three components should always be valued. In particular, the Text component should be valued even for well-known codes. By doing so, a system that receives a CE value will always be able to display that value, even if it does not understand the code. The fourth through sixth CE components should likewise either all be valued or all be left empty. They represent an alternative code with the same meaning as the code represented in the first three components.