This is archived content; for historical reference only.
The California HealthCare Foundation has two initiatives to promote the electronic transfer of laboratory results data to clinical settings: CALINX and ELINCS. This page provides answers for common questions about how the two initiatives relate.
Why are there two different messaging standards for communicating lab results?
Two standards are needed to handle two different “use cases” for reporting lab results. ELINCS handles the immediate test-by-test reporting of lab results to physicians’ electronic medical record systems; it is intended to support direct patient care and to replace the paper-based reporting of lab results. CALINX handles the periodic retrospective batch reporting of lab results to populate data warehouses and disease registries; it is intended to support population-based quality-improvement programs and to supplement the paper-based reporting of lab results. The different features of CALINX and ELINCS are required to handle these different use cases effectively.
What are the differences between CALINX and ELINCS?
There are numerous differences at both the general and detail levels between CALINX and ELINCS. Some of the most notable differences are:
CALINX defines a single message type to communicate retrospectively the final results of tests. ELINCS defines two message types to communicate in real time various types of lab information: the status of tests still in the lab (including cancellations), the results of completed tests, and corrections to previously reported results.
CALINX is based on the HL7 v2.4 ORU message type. While ELINCS v1.0 and v1.1 were also based on HL7 v2.4, the most recent version of ELINCS (HL7-R1) is based on the HL7 v2.5.1 standard.
CALINX was designed for use primarily in California and certain features are specific to California. ELINCS was designed for use anywhere in the United States.
CALINX does not require receivers to acknowledge the receipt of messages; labs assume that messages were received unless notified otherwise. ELINCS requires receivers to acknowledge the receipt of each message; labs assume that messages were not received unless notified otherwise.
CALINX allows laboratories to optionally populate HL7 segments and fields that are not designated as “required.” ELINCS prohibits the population of most HL7 segments and fields that are not designated as “required.”
CALINX requires that LOINC codes are used in reporting lab tests related to HEDIS quality measures (such as LDL-cholesterol, urine protein, and Chlamydia). ELINCS requires that LOINC codes are used in reporting the most frequently reported lab results (such as CBCs, urinalyses, and metabolic panels).
CALINX includes explicit support for transmitting batches of many result messages across many patients in a single file. ELINCS allows batching, but does not explicitly support it, because most ELINCS messages are transmitted in near-real time, as individual result messages.
What do CALINX and ELINCS have in common?
Both are intended to communicate the results of lab test results in a tightly defined message format that allows significant automated processing. For example, both specifications require that the identities of certain tests be reported using the standard LOINC coding system.
CALINX and ELINCS use ORU message type definition as a foundation and add additional constraints regarding required segments, fields, and data encoding.
Both were developed under the auspices of the California HealthCare Foundation with input and support from many industry stakeholders.
Both are freely available for use.
Both have free software applications to assist senders and recipients in using and implementing the specifications.
Should I use CALINX or ELINCS or both?
Certain organizations may benefit from using both ELINCS and CALINX.
You may wish to use ELINCS if many providers in your organization use an electronic medical record system; if this system includes an interface for receiving HL7-based messages; and if the clinical laboratory that you use can transmit lab results electronically in real-time or near-real-time.
You may wish to use CALINX if your organization aggregates clinical data in a disease registry or data warehouse on behalf of your providers; if these data are used primarily to support retrospective analyses for quality measurement or quality improvement; and if your labs and contracted health plans are located in California.
If I am using CALINX now for batch processing, will it be possible to switch to ELINCS later for real-time results reporting?
Some applications (such as some disease registries products) are capable of receiving and loading both batch lab results and real-time lab results. If you are using CALINX for receiving batches, you may decide later to upgrade your interface to ELINCS to receive lab results in a more timely (real or near-time) basis. Alternative strategies include using both CALINX and ELINCS concurrently, each for its designated purpose.
It will be possible for labs and provider organizations to switch from CALINX to ELINCS in the future because the specifications require many of the same segments, fields, and data encodings. Nevertheless, because the interaction model of ELINCS is more complex, requiring support for two message types and explicit message acknowledgments, such a switch will not be trivial and should be planned and executed carefully. Additionally, because the features of CALINX and ELINCS support different use cases, one should ensure that switching from CALINX to ELINCS will continue to support all of one’s business requirements.