T4

One of two use cases we tested in the Markle Connecting for Health Common Framework prototype was the exchange of laboratory results. In order to do so, we adopted a format for representation in the network that had the best fit with broad adoption and potential standardization. The Laboratory Results schema we used was derived from the ELINCS v2.0 (draft) specification, created by the California Healthcare Foundation.¹

The specification can be found at: http://elincs.chcf.org/specifications.aspx.

There is considerable work on laboratory results standards, and we anticipate that there will be future changes to this standard in the near term. Because the Common Framework maintains a separation between data description and transport, updates to the lab results standard will not require re-engineering the network to accommodate the new standard.

The ELINCS 2.0 version we used is still in draft form. The messages as we formatted them had several deviations from the ELINCS implementation guide in its draft form:

1. ELINCS prohibits populating many of the PID fields. NHIN permits any or all to be populated in query messages and returns most of those values when responding to a query. Our own implementation will return most of the contents of the PID segment in the query response (with the exception of SSN, which we will blank out).
2. The ELINCS draft requires a time zone accompanying all date-time values, while we do not. (We believe that that requirement will be relaxed in the balloted standard.)
3. Only the first component of the OBR.15 (SPECIMEN SOURCE) is allowed to be valued in the ELINCS draft. We routinely get very useful specimen source information in all five components of this HL7 field, and have allowed them to be populated.
4. The draft ELINCS spec requires all units be expressed as UCUM codes. We do not expect to see all units expressed in that coding system.
5. HL7 permits OBX.14 (DATE/TIME OF OBSERVATION) when test results for some members of a test battery were preformed at a time different from the other members of the test battery. ELINCS forbids this value. We support it.
6. The ELINCS draft limits the value type in OBX results segments to be of type CE (code), SN (structured numeric), ST (string), TX (text), or FT (formatted text). HL7 defines a much longer list of allowed value types. Our messages also support the longer list for those value types, such as DT (date), etc.
7. The ELINCS draft ignores OBX.4 (SUB-ID) for all but microbiology tests. Our messages include that value. It is useful for formatted reports and for other, less common types of data.
8. OBR fields for Principal Results Interpreter, Assistant Results Interpreter, Reason For Study, Technician, Diagnostic Service Sect ID, Danger Code, Relevant Clinical Info, and Priority are prohibited from being valued in the ELINCS draft. Our messages support those values.

__________

1. http://www.chcf.org/.

Markle Connecting for Health thanks the Indiana prototype team, J. Marc Overhage, MD, PhD, Clement McDonald, MD, and Lonnie Blevins for their implementation efforts on this standard.