The Development of a Highly Constrained Health Level 7 Implementation Guide to Facilitate Electronic Laboratory Reporting to Ambulatory Electronic Health Record Systems

doi:10.1197/jamia.M2610

J Am Med Inform Assoc. 2009 May-Jun; 16(3): 285–290.

PMCID: PMC2732232

The Development of a Highly Constrained Health Level 7 Implementation Guide to Facilitate Electronic Laboratory Reporting to Ambulatory Electronic Health Record Systems

Walter V. Sujansky, MD, PhD,^a J. Marc Overhage, MD, PhD,^b Sophia Chang, MD, MPH,^c Jonah Frohlich, MPH,^c and Samuel A. Faus, MS^a

^aSujansky and Associates LLC, San Carlos, CA

^bDepartment of Medical Informatics, Regenstrief Institute, Inc, Indianapolis, IN

^cBetter Chronic Disease Care Program, California HealthCare Foundation, Oakland, CA

Correspondence: Walter Sujansky, 751 Laurel St # 112, San Carlos, CA 94070 (Email: wsujansky/at/sujansky.com).

Received August 31, 2007; Accepted February 10, 2009.

Abstract

Electronic laboratory interfaces can significantly increase the value of ambulatory electronic health record (EHR) systems by providing laboratory result data automatically and in a computable form. However, many ambulatory EHRs cannot implement electronic laboratory interfaces despite the existence of messaging standards, such as Health Level 7, version 2 (HL7). Among several barriers to implementing laboratory interfaces is the extensive optionality within the HL7 message standard. This paper describes the rationale for and development of an HL7 implementation guide that seeks to eliminate most of the optionality inherent in HL7, but retain the information content required for reporting outpatient laboratory results. A work group of heterogeneous stakeholders developed the implementation guide based on a set of design principles that emphasized parsimony, practical requirements, and near-term adoption. The resulting implementation guide contains 93% fewer optional data elements than HL7. This guide was successfully implemented by 15 organizations during an initial testing phase and has been approved by the HL7 standards body as an implementation guide for outpatient laboratory reporting. Further testing is required to determine whether widespread adoption of the implementation guide by laboratories and EHR systems can facilitate the implementation of electronic laboratory interfaces.

Introduction and Background

The use of Electronic Health Record systems (EHRs) in small physician practices remains relatively uncommon.^2–4 Although various barriers to EHR adoption exist,^5,6 observers have identified the major technical barrier as the absence of widely adopted and effective data standards for interoperability.^5–8 Interoperability is important to EHR adoption because the ability to conveniently send and receive clinical data is among the key benefits of “digitizing” health information management.⁹ Among the most important applications of interoperability in the outpatient setting is the reporting of laboratory test results. Office physicians spend an average of 74 minutes daily managing laboratory results, and most physicians are dissatisfied with their current paper-based processes for handling laboratory data.¹⁰ Electronic data management can save physicians (and their staffs) time, avoiding paper-based routing, filing, and retrieving of laboratory results. Electronic data also allows easier review of laboratory results via search, flow chart, and graphing functions that are provided by many EHRs. Practicing physicians have cited the ability to import and display laboratory results electronically as one of the most desirable,¹¹ frequently used,¹² and productive¹³ features of ambulatory EHR systems. Beyond convenience, the computer-aided management of laboratory-result data (via “decision support”) is also important for patient safety and quality improvement. The EHRs receiving digitized laboratory results can alert physicians to significant abnormal values,¹⁰ suggest needed laboratory tests when medications are prescribed,¹⁴ and support adherence to preventive screening and disease-management guidelines.^15–17 One study indicated that use of an EHR, per se, does not improve the quality of care in the absence of appropriate decision-support capabilities.¹⁸

Many practices with EHRs, however, cannot realize the benefits enabled by electronic laboratory reporting. A small informal survey conducted by the primary author indicated that many practices that use EHRs lack electronic interfaces (such as those based on HL7¹) with their laboratories (see

). Further, small practices may be especially disadvantaged in this regard because laboratories are less likely to develop custom interfaces to EHRs in small practices,⁵ which provide less testing volume to offset the expense. Also, small practices generally have fewer resources to finance the customization required to interface their EHR to a laboratory (cost range U.S. $3,000–$15,000).^19,20

Table 1

Table 1 Prevalence of Electronic Lab Interfaces Among the Installed Physician Practices of Several EHR Vendors (informal survey of five EHR vendors conducted by primary author, June 2007)

The challenge of developing custom laboratory interfaces is compounded by fragmentation among the markets for laboratory services and EHR systems in the United States. The United States Department of Health and Human Services has certified 8,680 hospital laboratories, 5,400 independent commercial laboratories, and 6,500 clinic laboratories to perform testing.²¹ At least 35 different laboratory information systems (LISs) are used by laboratories in the United States.²² In addition, many practices receive test results from multiple laboratories, necessitating multiple interfaces.

Conversely, between 200 and 350 vendors offer ambulatory EHR products in the United States.^19,23,24 Hence, potentially thousands of pairwise interfaces may be required between ambulatory EHR products in physician offices and LIS products in clinical laboratories. In the absence of effective interoperability standards that are widely supported by LIS and EHR products, many of these interfaces will require custom implementation at substantial effort and cost.

In general, four steps are required to implement a laboratory-to-EHR interface²⁵:

1 The establishment of a business relationship between the EHR vendor and the clinical laboratory.
2 The implementation of a secure electronic communication platform between the laboratory and EHR, including choice of networking protocols (e.g., TCP/IP sockets, FTP) and security mechanisms (e.g., Virtual Private Network, SSL).
3 The negotiation, documentation and implementation of a common messaging format, i.e., the agreed-upon length of records, sequence of fields, meaning of fields, optional fields, and the allowed data types, identifiers, and codes that may appear within fields.
4 The testing and debugging of the interface to ensure that transmitted laboratory results are received and displayed correctly by the EHR.

A highly constrained messaging standard that is supported by most EHR and LIS vendors could greatly reduce the ad hoc negotiation, documentation, and implementation tasks associated with step 3. Although many lab information systems and ambulatory EHR products support the existing HL7 version 2.x messaging standards for laboratory reporting—specifically, the “Observation Report—Unsolicited” (ORU) message type−²⁶ this standard has not sufficiently reduced the effort inherent in developing laboratory-to-EHR interfaces. One reason for this shortcoming is the extensive optionality within the HL7 standard, a characteristic noted by other developers of HL7-based interfaces.²⁷

The optionality of a message standard can be characterized as the number of data elements within the standard that are designated as “optional”, i.e., that may either be populated or left NULL in a conformant message instance. The ORU message type in HL7 version 2.5.1 includes 4,132 data elements, counting all the segments, fields, components, and subcomponents (primary author's analysis). Of this total, 3,468 data elements (85%) are designated as optional. A practical significance of a message standard's optionality is that it increases the number of data elements that interoperating partners must consider, agree upon, and implement identically to build a functioning interface based on the message standard. Greater optionality, therefore, can increase the time and effort required to complete steps 3 and 4 of the interface-development process. If many of the optional data elements are never needed or always required for a very specific type of communication (such as the reporting of laboratory results to ambulatory EHRs), then the effort of steps 3 and 4 could be theoretically reduced by defining a subset of the standard for use in that type of communication.

Past recognition of this opportunity has led to the definition of previous HL7 “implementation guides” for laboratory messaging.^28–31 However, none of these implementation guides has been specifically designed for the reporting of laboratory results to ambulatory EHRs in the United States. The project described in this paper sought to develop an HL7 implementation guide that greatly minimized optionality while effectively supporting ambulatory laboratory reporting in the United States.

Method Description

Design Goals

In 2005, the California HealthCare Foundation³² convened a technical work group to facilitate outpatient laboratory reporting to EHRs. The group consisted of fifteen representatives from ambulatory EHR vendors, clinical laboratories, physician organizations, government agencies, and HL7.³³ The group embarked on this work guided by the following goals and design principles:

1 specification of a minimally necessary laboratory-result message
2 preference for parsimony over backward compatibility
3 preference for near-term adoption over technical perfection
4 sufficient structure and coding to support algorithmic processing of laboratory result data
5 support for the critical requirements of relevant stakeholder groups
6 support for correct and consistent implementation

The work group proceeded by reviewing the HL7 version 2.4 and 2.5 ORU message types to define the minimum set of data elements that were generally required for ambulatory laboratory reporting, i.e., the smallest subset of data elements from the HL7 ORU message type that could convey all the technical, clinical, and regulatory information needed for electronically reporting outpatient laboratory results to an EHR. The group also determined the maximum degree of standardized structure and coding that could be widely supported by the participating stakeholders. Often, the group had to weigh the expressed needs of EHR systems for structured and coded data against the near-term capabilities of clinical laboratories to provide such data, often compromising to arrive at a specification that was both useful and broadly implementable. For example, the group agreed to require Logical Observation Identifiers Names and Codes (LOINC)³⁷ as the identifiers for most tests, but chose not to require the reporting of cultured organisms using SNOMED-CT codes because the participating laboratories indicated that a transition to SNOMED-CT required much greater changes to their systems and processes.

After meeting via teleconferences and in person for a period of 4 months, the group published the EHR-Laboratory Interoperability and Connectivity Specification (“ELINCS”) version 1.0.³⁴ Over the following two years, the group completed two additional versions. The most recent version was approved and published by HL7 in Jul 2008 as an informative implementation guide for laboratory result reporting in ambulatory care.³⁵

Reduction in Optionality

The HL7 has an optionality of 227 data elements, 93% fewer than that of the standard HL7 ORU message type. The ELINCS work group achieved this significant reduction by designating as “not supported” (prohibited) all optional elements of the ORU message type that it deemed unnecessary or not widely supported by laboratories and/or ambulatory EHRs. These elements included segments containing information already known to or not clinically relevant to the ordering clinician (such as “Next of Kin”, “Patient Visit”, and “Financial Transaction”), fields containing order-related information not useful in laboratory results (such as “Order Callback Phone Number,” “Charge To Practice”, and “Transport Logistics of Collected Sample”), and field components not widely supported by ambulatory EHRs or laboratories (such as “Name Assembly Order”, “Address Validity Range”, and “Code Identifying the Check Digit Employed”).

The work group further reduced optionality by changing the designations of many remaining data elements to “Required” (i.e., they must always be populated), “Required but May Be Empty” (i.e., they must be populated if the laboratory has the data), or “Conditional” (i.e., they must be populated if certain other data elements are populated). For example, the work group designated the field “Performing Organization Name” (OBX-16) as required, because the federal Clinical Laboratory Improvement Amendments (CLIA) regulations require all laboratory reports to specify the laboratory at which the test was performed.³⁶

The complete ELINCS implementation guide appears in the online appendix and is available from Health Level Seven Inc.

Enhanced Structure and Coding

The project team also imposed additional structure and coding constraints on certain of the remaining data elements:

1 LOINC coding. The ELINCS implementation guide requires that conforming laboratories use the LOINC coding standard³⁷ to identify every test analyte in the top 95^th percentile of tests reported in the outpatient setting (ranked by frequency). The project identified this set of 155 analytes by analyzing test-frequency data from three large provider organizations in California.³⁸ Confining the LOINC-coding requirement to only these frequently reported tests achieved much of the value of standard test coding without requiring laboratories to LOINC-encode their entire test catalogs.
2 Structured reporting of result values and units of measure. The ELINCS specification requires that numeric test results be reported separately from their units of measure (rather than as a single text string) to facilitate graphing and other quantitative processing.

Testing via Pilot Implementations

Given the dramatic reduction of optionality in the ELINCS implementation guide through the prohibition of many data elements in the HL7 ORU message type, it was important to determine whether the remaining data elements were sufficient to report laboratory results to ambulatory EHRs in practice. In 2005, six health care organizations, five EHR vendors, and seven clinical laboratories participated in pilot implementation projects based on ELINCS version 1.1 (an earlier but very similar version of the implementation guide described above).

lists the participating organizations and implementation projects on which they collaborated. The goals of these projects were to determine 1) whether the defined specification allowed the communication of all necessary information for laboratory reporting in the ambulatory setting, and 2) whether multiple laboratory and EHR systems could technically implement the specification. These goals represented the lower threshold of practical utility for the ELINCS implementation guide.

Table 2

Table 2 Participants in the Pilot Projects to Implement Lab-reporting Interfaces Using ELINCS v1.1 in 2006–2007

Following a twelve month testing period, the pilot implementations yielded the following findings:

• Five of the six health care organizations successfully implemented laboratory interfaces based on ELINCS version 1.1, which remain in clinical use. The sixth organization withdrew from the pilot project because it switched laboratory vendors (for business reasons) and did not wish to restart the project with its new vendor. Hence, one of the EHR vendors and one of the laboratories also dropped out of the pilot.
• The task of implementing the ELINCS interfaces required various software changes on the part of both EHR vendors and clinical laboratories, including 1) the mapping of proprietary codes used by vendors and laboratories to the standard codes required by ELINCS, such as LOINC codes for test names and HL7 codes for specimen types; 2) the placement of certain information in different HL7 fields than previously used, such as sending the ordering provider's name in the OBR segment rather than the ORC segment (HL7 allows either, an example of unneeded optionality); 3) the transmission of certain information as discrete data within designated fields rather than as free-text strings within comment fields, such as indicating which component of a test had been canceled via the appropriate code in the observation result status field (OBX-11) rather than a free-text string in the observation value field (OBX-5).
• None of the laboratory or EHR systems reported that the ELINCS implementation guide lacked any data elements that they required from a technical, clinical, or regulatory perspective.
• Following the pilot implementations, two of the EHR vendors estimated informally that widespread adoption of the ELINCS standard would reduce the overall effort to implement new laboratory-reporting interfaces by 30–60%.^25,39

Discussion

Lessons Learned

Some noteworthy lessons emerged from the development and early testing of the ELINCS implementation guide.

• A surprisingly small subset of the data elements in the HL7 ORU message type may be adequate to support the reporting of laboratory test results to ambulatory EHRs in the United States. Upon analysis, this result is explained by the fact that the ORU message type includes all the data elements needed for various types of observation reporting (e.g., laboratory, imaging, physiological monitoring) in various contexts (e.g., inpatient, outpatient, various national jurisdictions). Additionally, the segments that comprise the ORU message type also appear in various other message types, such as those for test orders, admission/discharge processing, and billing transactions. Hence, a great many of the data elements in the ORU message type are relevant to tasks other than outpatient laboratory reporting.
• With respect to available data elements, there is significant difference between inpatient and outpatient laboratory reporting. In the inpatient setting, laboratory systems are frequently interfaced with patient-registration systems and have access to the patient demographic and admissions data that were recorded upon registration. In the outpatient setting, reference laboratories have access to only those patient and encounter data that were recorded on each laboratory order (which are typically minimal). Hence, reference laboratories have a “transaction-oriented” view of laboratory results rather than a “patient-oriented” and “encounter-oriented” view, so they cannot populate many of the fields pertaining to patient demographics or patient visits that are part of the HL7 ORU message type.
• The greatest technical challenge for the smaller laboratories that implemented ELINCS was the mapping of their proprietary test codes to the LOINC coding system. Tools and/or assistance for LOINC coding may be required to achieve widespread adoption of the ELINCS implementation guide or any implementation guide that requires LOINC codes.
• The HL7 ORU message type is not entirely consistent with prevailing practices for ordering and reporting laboratory tests. For example, the HL7 standard requires that every test that is ordered be assigned a globally unique identifier, which is later transmitted in the “Filler Order Number” field (OBR-3) of the result. However, we learned that many EHR systems do not generate laboratory orders with unique test identifiers, and many laboratories cannot record such identifiers when they appear on test orders. Also, the “Filler Order Number” field has a maximum length of 22 characters, which is insufficient to store certain globally unique identifiers generated by modern software systems (such as 128 bit GUIDs). The ELINCS implementation guide specified several exceptions and extensions to the HL7 standard to accommodate prevailing practices that were difficult for laboratories and EHR systems to modify, and certain of these changes were subsequently incorporated into the HL7 standard. In this manner, the project balanced the desire to achieve a highly constrained and HL7-compliant implementation guide with the capabilities of the stakeholders to implement the resulting artifact in a one to two year time frame.

Limitations

The limited scale and duration of the pilot implementations precluded testing whether the adoption of ELINCS as an industry standard could significantly reduce the effort and cost of building laboratory-reporting interfaces. Indeed, there were likely no such savings during the pilot implementations because all participants were implementing the ELINCS implementation guide for the first time. Efficiencies may be expected only when interfaces are implemented between systems that already support the ELINCS implementation guide.

Also, the limited scale of the pilot implementations could not demonstrate conclusively that the ELINCS specification retains sufficient optionality to support all ambulatory laboratory-test reporting. Additional implementations involving other health care organizations, EHR systems, and clinical laboratories are required to make this case or to identify potential gaps in the current implementation guide.

Beyond the need for additional evaluation, the ELINCS implementation guide requires several additional enhancements before it can comprise a “plug and play” interoperability standard for laboratory-result reporting:

1 Standardization of communication protocols, including transport protocols, encryption/authentication methods, and message-addressing/routing mechanisms.
2 Further standardized coding of data elements, including cultured organisms, units of measure, pathology findings, and the identifiers of less frequently ordered tests.
3 Standardization of electronic laboratory ordering to facilitate structured information exchange throughout the laboratory-testing process.

Conclusions

The project described in this paper defined an implementation guide for laboratory-result reporting that manifests significantly less optionality than the current HL7 version 2 standard. Based on results from a small number of pilot implementations, several organizations of varying sizes were able to implement ELINCS successfully and the relatively small set of data elements in ELINCS was sufficient to convey the required contents of laboratory results. If the presumed relationship between the degree of optionality in a message standard and the level of effort required to implement data interfaces is valid, widespread adoption of the ELINCS specification among EHR vendors and clinical laboratories could streamline the development of laboratory-reporting interfaces. However, further evaluation is required to demonstrate that the ELINCS implementation guide can in practice deliver such savings and effectively support the result-reporting requirements of most laboratory and ambulatory facilities.

Acknowledgments

Supported by the California HealthCare Foundation. The authors thank the members of the ELINCS Technical Work Group for their efforts, insights, and perseverance. The authors also appreciate the efforts of the pilot implementation teams, especially the technical personnel who worked diligently to implement the ELINCS specification completely and accurately.

Footnotes

For purposes of this analysis, we classified an element as “Optional” if its designation in the HL7 standard is “Optional” or “Backward Compatibility.” We classified an element as “Required” if its designation is “Required,” “Required But May Be Empty,” “Conditional” or “Conditional But May Be Empty.” For information about these HL7 designations, refer to endnote [²⁹].

References

1. http://www.hl7.org/about(Accessed 10/9/2008).

2. DesRoches CM, et al. Electronic Health Records in Ambulatory Care—A National Survey of Physicians N Engl J Med 2008;359(1):50-60. [PubMed]

3. Burt CW, Hing E, Woodwell DA. Electronic Medical Record Use by Office-Based Physicians: United States, 2005http://www.cdc.gov/nchs/products/pubs/pubd/hestats/electronic/electronic.htm 2008(Accessed 10/9/2008).

4. Jha A, et al. How Common Are Electronic Health Records In The United States?. A Summary Of The Evidence. Health Affairs, 25, no. 6 2006:w496-w507. [PubMed]

5. Miller RH, Sim I. Physicians' use of electronic medical records: barriers and solutions Health Aff (Millwood) 2004;23(2):116-126. [PubMed]

6. Middleton B, Hammond WE, Brennan PF, Cooper GF. Accelerating U.S. EHR adoption: how to get there from here. recommendations based on the 2004 ACMI retreat J Am Med Inform Assoc Jan-Feb 2005;12(1):13-19. [PMC free article] [PubMed]

7. McDonald CJ. The barriers to electronic medical record systems and how to overcome them J Am Med Inform Assoc May-Jun 1997;4(3):213-221. [PMC free article] [PubMed]

8. Audet AM, et al. Information technologies: when will they make it into physicians' black bags? MedGenMed 2004;6(4):2. [PubMed]

9. Thomson TG, Brailer DJ. The Decade of Health Information Technology: Delivering Consumer-centric and Information-rich Health Care–Framework for Strategic Action. U.S. Department of Health and Human Services. http://www.hhs.gov/healthit/documents/hitframework.pdf 21July2004(Accessed 10/9/2008).

10. Poon EG, et al. ”I wish I had seen this test result earlier!”: Dissatisfaction with test result management systems in primary care Arch Intern Med 2004;164(20):2223-2228. [PubMed]

11. Electronic survey of 376 office physicians in United States who are users of the ePocrates drug reference guide. California HealthCare Foundation; 2004(unpublished).

12. Simon SR, et al. Physicians and electronic health records: a statewide survey Arch Intern Med 2007;167(5):507-512. [PubMed]

13. Keshavjee K, Troyan S, Holbrook AM, VanderMolen D. Measuring the success of electronic medical record implementation using electronic and survey data Proc AMIA Symp 2001:309-313. [PMC free article] [PubMed]

14. Steele AW, et al. The effect of automated alerts on provider ordering behavior in an outpatient setting PLoS Med 2005;2(9):e255Epub 2005 Sep 6. [PMC free article] [PubMed]

15. Toth-Pal E, Nilsson GH, Furhoff AK. Clinical effect of computer generated physician reminders in health screening in primary health care-a controlled clinical trial of preventive services among the elderly Int J Med Inform 2004;73(9–10):695-703. [PubMed]

16. Frame PS, et al. Computer-based vs manual health maintenance tracking. A controlled trial. Arch Fam Med 1994;3(7):581-588. [PubMed]

17. Dorr D, et al. Informatics systems to promote improved care for chronic illness: a literature review J Am Med Inform Assoc Mar-Apr 2007;14(2):156-163. [PMC free article] [PubMed]

18. Linder J, et al. Electronic Health Record Use and the Quality of Ambulatory Care in the United States Arch Intern Med 2007;167:1400-1405. [PubMed]

19. Terry K, et al. Why EHRs Falter Medical Economics 2006. April 7,.

20. The ACG 2007 Annual Report: Computer Systems in the Physician's Office. Chapter 12–EMR/EHR Pricing. AC Group, Inc., Montgomery, Texas.

21. Division of Laboratory ServicesCenters for Medicare & Medicaid Services Laboratories by Type of Facility, CLIA Update – December 2006http://www.cms.hhs.gov/CLIA/downloads/factype.pdf 2006(Accesse July 9, 2007).

22. Aller RD, et al. Annual Survey of LIS Systems CAP Today. November2005. pp. 28-56.

23. EHRConsultant.com - list of EHR manufacturers. http://www.emrconsultant.com/theemrlist.php (Accessed 10/9/2008).

24. PhysiciansEHR.org–vendor listinghttp://www.physiciansehr.org November2005(Accessed 10/9/2008).

25. Hall Patrick. Chief Operating Officer, e-MDs, Inc Personal Communication 2006. June 19,.

26. HL7 Messaging Standard Version 2.5.1, Chapter 7http://www.hl7.org/library/standards.cfm 21February2007(Accessed 10/9/2008).

27. For example, see http://www.itl.nist.gov/div897/ctg/messagemaker/slides/IESA07.ppt, http://www.ncvhs.hhs.gov/011010p2.pdf, and http://www.m.niemeck.org/thesis.pdf.

28. HL7 Messaging Standard Version 2.5.1, Chapter 2.12http://www.hl7.org/library/standards.cfm 21February2007(Accessed 10/9/2008). Note: ”Message profiles” are also referred to as ”implementation guides,” ”interoperability profiles,” and ”interoperability specifications” in the literature and trade press.

29. IHE Laboratory Technical Framework 27February2005;Volume 2http://www.ihe.net/Technical_Framework/upload/LabTFVol2_vl_2_feb27_FT.pdf 27February2005(Accessed 10/9/2008).

30. Broome CV, Loonsk J. Public Health Information Network–improving early detection by using a standards-based approach to connecting public health and clinical medicine MMWR Morb Mortal Wkly Rep 2004;53(Suppl):199-202. [PubMed]

31. Health Information Technology Standards Panel Interoperability Specificationshttp://www.hitsp.org 2004(Accessed 10/9/2008).

32. http://www.chcf.org 2004(Accessed 8/15/2007).

33. The original technical work group included representatives from the following organizations: AllScripts, Inc., American College of Physicians, Ameripath, Inc., eHealth Initiative, Emdeon, Inc., e-MDs, Inc., GE Medical Technologies, HL7, Indiana Health Information Exchange, LabCorp, Inc., Misys, Inc., NextGen, Inc., Quest Diagnostics, Inc., U.S. Centers for Disease Control and Prevention, U.S. Centers for Medicare and Medicaid Services, U.S. Veterans Health Administration.

34. ELINCS Specifications, California HealthCare Foundationhttp://www.elincs.org 2004(Accessed 10/9/2008). Note that the HL7-R1 version of ELINCS is available only to members of HL7.

35. HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Ambulatory Care Lab Result (ELINCS), Release 1. Health Level Seven, July 1, 2008. http://www.hl7.org/documentcenter/private/standards/v251/HL7_AmbulatoryCareLabResultSpecification-R1_v2.5.1.zip 2008(Accessed 10/13/2008).

36. Current CLIA Regulations, Centers for Disease Control and Prevention, §493.1291 (c)(2) and §493.1291 (i)(3)http://www.phppo.cdc.gov/clia/regs/toc.aspx 2008(Accessed 2/2/2009).

37. Logical Observation Identifiers Names and Codes (LOINC®)http://www.loinc.org 2008(Accessed 7/9/2007).

38. Brown and Toland Medical Group, San Francisco, CA; Greater Newport Physicians, Orange County, CA; Sharp Health Care, San Diego, CA.

39. Bartlett Joan. Evaluation of Pilot Projects for ELINCS implementation, personal communication June2007.

Articles from Journal of the American Medical Informatics Association : JAMIA are provided here courtesy of
American Medical Informatics Association