LRI+-+FINAL+Use+Case

include component="page" wikiName="siframework" page="LRI Header"

Thank you all for your participation!
=== As of May 5th, 2011 the content of the Laboratory Results Reporting to Primary Care Providers (in an Ambulatory Setting) Use Case, as part of the Laboratory Results Interface Initiative has been finalized. Below are links to the Final versions of the Use Case Narrative as well as the Functional Requirements Spreadsheet i.e. the Use Case Package. The documents below as well as the text embedded within the Wiki reflect updates that were proposed and agreed upon during the formal Consensus Process. Please contact the Use Case and Requirements Support Leads if you have any remaining questions or concerns. ===

To access the Final and Approved Microsoft Word version of the LRI Use Case click here:
[|LRI Use Case]

To access the Microsoft Excel version of the LRI Functional Requirements Spreadsheet click here:
[|LRI Functional Requirements Spreadsheet]

**To view the LRI Consensus page, please click here.**

1.0 Preface and Introduction
To fully realize the benefits of health IT, the Office of the National Coordinator for Health Information Technology (ONC), as part of the Standards and Interoperability (S&I) Framework is developing Use Cases that define the interoperability requirements for high priority health care data exchange to maximize efficiency, encourage rapid learning and protect patients’ privacy in an interoperable environment. These Use Cases address the requirements of a broad range of Communities of Interests including, patients, providers, vendors, laboratories, standards organizations, public health organizations and Federal agencies.

These Use Cases describe:
 * The operational context for the data exchange
 * The stakeholders with an interest in the Use Case
 * The information flows that must be supported by the data exchange
 * The types of data required in the data exchange

The Use Case is the foundation for identifying and specifying the standards to support the data interoperability and developing reference implementations and tools to ensure consistent and reliable adoption of standards.

2.0 Overview and Scope
The Laboratory Results Interface Initiative focuses on identifying the requirements, specifications and standards, and on providing the implementation guidance for electronic reporting of ambulatory care laboratory test results in the US Realm. The scope of this Use Case includes requirements to enable the incorporation of clinical laboratory test results into an EHR as standardized structured data using the defined inter-organizational laboratory transaction. The Use Case requirements are directed at laboratory test results reporting between a laboratory information system and an ambulatory EHR system in different organizational entities, e.g., different corporate structure, ownership or governance. However, the resulting implementation guide may also be useful within organizations and in non-ambulatory care settings.

There are at least two standard implementation guides for ambulatory laboratory test reporting, neither of which are adopted universally across the industry. The lack of a single, comprehensive implementation guide for the result reporting interfaces drives the cost and time to implement such interfaces up and consequently hampers broad adoption of such interfaces. Furthermore, the field by field details of HL7 v2 implementation guides used by clinical laboratories and EHRs vary; creating a need for mapping or configuration per interface, and the prevalence of core subsets of LOINC codes, where in use for common tests and analytes also varies, causing downstream issues in decision support and quality reporting.

Successful outcomes for this Initiative include:
 * 1) Increase the n umber of providers using Laboratory Results Interface Initiative Outputs
 * 2) Increase the n umber of laboratories using Laboratory Results Interface Initiative Outputs
 * 3) Increase the n umber of Laboratory Results Reporting transactions using Laboratory Results Interface Initiative Outputs
 * 4) Increase the n umber of vendors (EHRs, PHRs, LIS Vendors, HIEs) using Laboratory Results Interface Initiative Outputs
 * 5) Time Reduction to Create a New Laboratory Interface for the laboratory/EHR system
 * 6) Cost Reduction to Create a New Laboratory Interface for the laboratory/EHR system
 * 7) Meaningful Use Alignment

NOTE: Additonal quantifiable metrics will be added in the next iteration of the Use Case.

The Use Case scenario that is outlined in the subsequent sections focuses on the sending of clinical laboratory results to a certified EHR system. The scope has been limited to the core set of test results typically utilized for primary care functions provided by Internal Medicine, Family Practice and Pediatrics, but may also be leveraged by other providers and settings.

** 2.1 In Scope **

 * Defining the core data elements required for ambulatory care core clinical laboratory test results.
 * Reporting of ambulatory care clinical laboratory test results in the US Realm.
 * Sending clinical laboratory test results as standardized structured data so they can be incorporated that way into a certified EHR.
 * Supporting Stage 2 certification criteria and MU requirements by developing requirements for an interface that enables the incorporation of clinical laboratory test results into certified EHR when data is sent as standardized structured data.
 * Reporting test results of an order placed manually or electronically.
 * To the extent an order has been placed returning the minimally required set of information related to that order through that transaction.
 * Covering all CLIA reporting requirements, including but not limited to: result reports statuses; preliminary, final, appended, corrected and/or amended.
 * Receiving of laboratory results as a non-order placer.

2.2 Out of Scope

 * Specifications and implementation guidance on laboratory ordering transactions. However, the establishment of requirements in the laboratory result message that will allow the matching of the reported result to an existing order initiated from the ordering clinician’s EHR is within the scope of this effort.
 * Querying for laboratory results.
 * Querying for historical laboratory results.
 * Receiving historical laboratory results.
 * Secondary use of laboratory data (i.e., public health or bio surveillance uses of the reported laboratory results).
 * Receiving test results for specialty laboratory orders.
 * In hospital ordering and reporting of laboratory results.
 * Advanced error messages related to application transport.
 * Results not transmitted using a standardized structured format.

2.3 Background
The Laboratory Results Interface Initiative and the subsequent Laboratory Results Reporting to Primary Care Providers (in an Ambulatory Setting) Use Case have been selected because of its alignment with Meaningful Use Stage 1 and foreseen Stage 2 indications as well as addressing various Prioritization Criteria as described below.

The Laboratory Results Interface Initiative holds importance and relevance because it enables stage 1 and potential stage 2 Meaningful Use criteria:
 * Stage 1: Incorporation of laboratory results as structured data
 * Stage 2: Incorporation of laboratory results through well defined interfaces as standardized structured data

The terms structured data and standardized structured data represent current Stage 1 certification criteria and possible extensions for Stage 2.

**Definitions of Structured Data Applicable to Laboratory Results Reporting **
 * || **Structured Data** || **Standardized Structured Data** ||
 * Definition || "Structured data is not fully dependent on an established standard. Established standards facilitate the exchange of the information across providers by ensuring data is structured in the same way. However, structured data within certified EHR technology merely requires the system to be able to identify the data as providing specific information. This is commonly accomplished by creating fixed fields within a record or file, but not solely accomplished in this manner" (please reference background section & Final Rule). || Established standards facilitate the exchange of the information across providers by ensuring data is structured in the same way. ||
 * Source || 45 CFR Part 170 §170.302(h) 42 CFR Part 495. || Extension of definitions in cited final rules by Structured Data Sub-Workgroup. ||
 * Applicability || Current requirement for EHR technology certification (testing) and demonstration of Meaningful Use for Stage 1. || Potential future requirement for EHR technology certification (testing) and demonstration of Meaningful Use for Stage 2/3. ||
 * Context || Receive, display (in human readable format) and incorporate structured (laboratory) data. || (Proposed) Receive, display and incorporate +standardized+ structured (laboratory) data. ||
 * Description || "Structured data is commonly accomplished by creating fixed fields within a record or file, but not solely accomplished in this manner. For example, in this case for it to be structured, if the patient is on aspirin, then that information should be in the system so that it can be automatically identified as a medication and not as an order, note, or anything else. An example of unstructured data would be the word aspirin, but no ability of the system to identify it as a medication. We said that when the information was available in a structured format we expected that it be transferred in a structured format. However, if it was unavailable in a structured format, that the transmission of unstructured data was permissible." Final Rule. || Standardized structured data is a related set of data encoded within an agreed-upon **syntactic and semantic** structure, using coding systems and metadata to formalize the meaning of each individual datum (which cannot be decomposed further) in the set where appropriate and feasible. Standardized structured data is driven by the goal of improving the **interoperability** of data between disparate systems, and simplifying the process of harmonizing data from disparate sources. ||

The Laboratory Results Interface Initiative requires and supports information interchange. Messaging and vocabulary standards exist but due to the high degree of allowable variation implementation of laboratory interfaces is time consuming and costly. This Initiative will leverage existing interoperability standards and specifications when defining the Use Case and functional requirements.

There are at least two implementation guides and specifications for laboratory results.


 * The HITSP/IS01 specification, the HL7 Implementation Guide: Order and Observations; Interoperable Laboratory Results Reporting to Electronic Health Record (EHR), Release 1 (Laboratory to EHR guide), that HITSP points to, and HITSP/C36 Laboratory Message Component in combination define and constrain the use of the HL7 Version 2.5.1.
 * EHR-Laboratory Interoperability and Connectivity Specification (ELINCS) also constrained the HL7 Version 2.5.1 Implementation Guide which resulted in the HL7 2.5.1 Implementation Guide: Orders and Observations; Ambulatory Laboratory Results (ELINCS), Release 1.

2.4 Policy Issues
The Use Cases strive to address relevant and timely policy issues that will have downstream effects on the US healthcare reform agenda; specifically relevant to healthcare information technology. Without a widely accepted standard for laboratory results exchange several issues will arise in relation to clinical decision support and quality reporting.


 * Certification Criteria: Receive results in structured format and display in human readable format. However the certification criteria for Stage 1 do not specify that the structured laboratory results that are received be in a standard format or use code set standards in meeting the measure for this objective. However, the Office of the National Coordinator for Health Information Technology (ONC) has adopted Logical Observation Identifiers Names and Codes (LOINC®) version 2.27, when such codes were received within an electronic transaction from a laboratory, for the entry of structured data for this measure and made this a requirement for EHR technology to be certified.

//NOTE: While ONC has selected to adopt LOINC version 2.27 new versions of the LOINC database are published twice a year with the most current version being 2.34. This can potentially cause issues for the laboratories because earlier versions of LOINC may contain LOINC terms that have been modified or deprecated. For this reason Laboratories should be encouraged to use the most current version of LOINC.//
 * Meaningful Use Requirement for Stage 1: Incorporate Laboratory results as structured data into Electronic Health Record.

The requirements of this Use Case when fulfilled by the Standards and Interoperability Framework should provide policy makers the option of a viable implementation guide for sending laboratory results as standardized structure data to EHR systems within the ambulatory care setting. This would enable policy makers to require such exchanges if they so decided in Stage 2 and/or Stage 3.

2.5 Regulatory Issues
This Use Case acknowledges the variations in requirements for reporting across local, state, tribal, and territorial boundaries as well as voluntary versus mandatory requirements. In the Final Rule 42 ONC required that EHR systems receive and incorporate lab results as structured data. CFR 493.1291(c) requires that the test report must indicate the following:

(1) For positive patient identification, either the patient's name and identification number, or a unique patient identifier and identification number. (2) The name and address of the laboratory location where the test was performed. (3) The test report date. (4) The test performed. (5) Specimen source, when appropriate. (6) The test result and, if applicable, the units of measurement or interpretation, or both. (7) Any information regarding the condition and disposition of specimens that do not meet the laboratory's criteria for acceptability.

The Centers for Medicare & Medicaid Services (CMS) regulates all laboratory testing (except research) performed on humans in the U.S. through the Clinical Laboratory Improvement Amendments (CLIA). In total, CLIA covers approximately 200,000 laboratory entities. The Division of Laboratory Services, within the Survey and Certification Group, under the Center for Medicaid, CHIP, and Survey & Certification (CMCS) has the responsibility for implementing the CLIA Program.

The objective of the CLIA program is to ensure quality laboratory testing. Although all clinical laboratories must be properly certified to receive Medicare or Medicaid payments, CLIA has no direct Medicare or Medicaid program responsibilities. Interpretations of legal requirements across the states and laboratory sources vary widely and there is currently no ability to monitor/enforce standards.

2.6 Communities of Interest
Communities of Interest are public and private stakeholders that are directly involved in the business process or are involved in the development and use of interoperable implementation guides and implementation of the Solution. Some members are business actors. Communities of Interest may directly participate in the exchange, that is they are actors, or indirectly through the results of the improved business process.

The following list of Communities of Interest and their definitions are for discussion purposes for clinical information exchange:
 * **Members of Communities of Interest ** || **Working Definition ** ||
 * Patient || Members of the public who require healthcare services from ambulatory, emergency department, physician’s office, and/or the public health agency/department. ||
 * Consumers || Members of the public that include patients as well as caregivers, patient advocates, surrogates, family members, and other parties who may be acting for, or in support of, a patient receiving or potentially receiving healthcare services. ||
 * Care Coordinators || Individuals who support clinicians in the management of health and disease conditions. These can include case managers and others. ||
 * Clinicians || Healthcare providers with patient care responsibilities, including physicians, clinical laboratory personnel, advanced practice nurses, physician assistants, nurses, pharmacists, and other licensed and credentialed personnel involved in treating patients. ||
 * Provider || An individual clinician or care delivery setting delivers care to the patient and in that role accepts laboratory test results in this Use Case. ||
 * Laboratories || A laboratory (often abbreviated lab) is a setting where specimens are sent for testing and analysis, after which results are communicated back to the requestor. The types of laboratories may include clinical, medical, and/or reference and may be both private and/or public. ||
 * Provider Organizations || <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 3.25pt 0in; text-indent: 0in;">Organizations that are engaged in or support the delivery of healthcare to include Hospital Ambulatory Centers and Provider Practices. ||
 * <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 3.25pt 0in; text-indent: 0in;">Standards Organizations || <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 3.25pt 0in; text-indent: 0in;">Organizations whose purpose is to define, harmonize and integrate standards that will meet clinical and business needs for sharing information among organizations and systems. ||
 * <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 3.25pt 0in; text-indent: 0in;">Electronic Health Record/Personal Health Record Vendors || <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 3.25pt 0in; text-indent: 0in;">Vendors which provide specific EHR/PHR solutions to clinicians such as software applications and software services. These suppliers may include developers, providers, resellers, operators, and others who may provide these or similar capabilities. ||
 * <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 3.25pt 0in; text-indent: 0in;">Federal Agencies || <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 3.25pt 0in; text-indent: 0in;">Organizations within the federal government that deliver, regulate or provide funding for health and health care. ||
 * <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 3.25pt 0in; text-indent: 0in;">Health Information Exchange (HIE) || <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 3.25pt 0in; text-indent: 0in;">HIE is defined as the mobilization of healthcare information electronically across organizations within a region, community or hospital system. ||

3.0 Challenge Statement
There are at least two implementation guides for ambulatory laboratory reporting, neither of which is widely adopted across industry. There are many proprietary specifications for ambulatory laboratory reporting. Every vendor in this space has its own format for reporting results. Each laboratory has its own vocabulary for identifying tests, reporting test results and units of measure. The cost and time to initiate new electronic laboratory results interfaces hampers broad adoption of such interfaces but is only one of the obstacles to adoption. Customization of interfaces is common in the acute care hospital setting where the individual hospitals demand result formats customized to meet local requirements. The field-by-field details of HL7 v2 implementation guides used by clinical laboratories and EHRs vary, creating a need for mapping or configuration per interface, and the composition of core subsets of LOINC codes for common tests and analytes also varies, causing downstream issues in decision support and quality reporting.

Clinical laboratories use result-reporting formats that conform to CLIA regulation (42 CFR 493.1291(c)) and in many cases once a laboratory finds a result format and content acceptable to CLIA, the laboratories are hesitant to change that format. Moving laboratories off these proprietary specifications will be the challenge. Meaningful Use doesn't directly address the reasons why laboratories use the formats they do today, and does not currently provide incentives to the laboratories to change current practices. Furthermore, a compelling ROI has yet to be discovered.

4.0 Value Statement
Laboratory results interfaces automate the electronic communication of test results between disparate systems, such as laboratories and ambulatory EHRs. Currently, individual laboratory results interfaces deliver data in a consistent formatted manner; however, there is no consistent implementation of such interfaces across the ambulatory setting. A laboratory results interface implementation which standardizes the communication (message, data elements and their use, and vocabulary) of test results from a laboratory to an EHR can potentially:


 * Reduce implementation-related costs;
 * Reduce on-going support and maintenance-related costs; and
 * Improve care delivery and clinical outcomes.

In addition, a specification defined such that it (or parts thereof) is reusable across different laboratory reporting use cases (e.g., ambulatory, acute, public health) can help lower the cost not just of ambulatory results interfaces, but for other types of laboratory interfaces as well.

5.0 User Story
A Provider //(order placer)// may enter a laboratory order into an ambulatory EHR. A laboratory requisition is generated (paper or electronic) and is communicated to the laboratory. The information in the laboratory requisition is entered manually or captured electronically into the Laboratory Information System (LIS). After the specimen(s) have been collected and, if necessary, shipped or delivered to the laboratory, the laboratory processes the specimen(s). The laboratory performs or attempts to perform the test(s). If testing is successful, results are obtained and entered/released in the laboratory information system. An authorized person at the laboratory reviews and approves the laboratory test results to be sent to the ordering provider.

The laboratory's LIS system //(results sender)// transmits the results to the Provider’s Electronic Health Record system //(results receiver)//. The EHR incorporates the results into the patient’s electronic record. The Provider logs into his/her EHR and views the laboratory results in order to inform patient care decisions.

6.0 Use Case Assumptions

 * Providers securely access clinical information through an EHR system.
 * Appropriate security and transport protocols; patient identification methodology; requisition (order) identification methodology; consent; privacy and security procedures; coding, vocabulary and normalization standards have been agreed to by all relevant participants.
 * This Use Case only addresses the exchange of laboratory results that are associated with the In Scope laboratory tests.
 * All relevant parties have agreed on a structured laboratory test results message format.
 * This Use Case covers all CLIA reporting requirements, including but not limited to: result reports statuses; preliminary, final, appended, corrected and/or amended.
 * For the specimen collection process the data included in the dataset considerations table are assumed to be available and reported in the result.
 * Legal and governance issues regarding data access authorizations, data ownership, and data use are in effect.
 * Established network and policy infrastructure to enable consistent, appropriate, and accurate information exchange across provider systems, data repositories and locator services. This includes, but is not limited to:
 * Methods to identify and authenticate users;
 * Methods to identify and determine Providers of care;
 * Methods to enforce data access authorization policies;
 * Methods to ensure the veracity of data;
 * Detailed audit trails are kept as necessary by all participating systems.
 * Security and privacy policies, procedures and practices are commonly implemented to support acceptable levels of patient privacy and security; i.e. HIPAA, HITECH and EHR certification criteria.
 * Laboratory Information Systems will be the sender of laboratory test results while Electronic Health Record Systems will be the receiver.
 * The transport mechanism will provide guaranteed delivery and error handling
 * This Use Case acknowledges the variations in requirements for reporting across local, state, tribal, and territorial boundaries as well as voluntary versus mandatory requirements.
 * All Federal, State & local regulations are being supported.
 * Laboratories meet accreditation criteria according to jurisdiction requirements or agency criteria.

7.0 Pre-Conditions

 * An order has been generated by an Ordering Provider for the original or repeated laboratory tests results to be produced.
 * The Laboratory receives an order (electronic, paper, etc.) or the Laboratory receives a request to re-run (repeat) a test, or determines a need to re-run a test for possible correction, or determines that reflex testing (which is based on criteria set by the medical review board) is required or determines the need to amend a test result based on erroneous information.
 * The Laboratory receives the appropriate clinical information to perform the ordered test
 * Laboratory has entered manually or through the interface pertinent (or corrected) data from an order into the Laboratory Information System.
 * Laboratory has received and processed properly identified specimen(s) related to the ordered test(s).
 * Laboratory entered or received from the ordering EHR environment, pertinent data from/about the specimen into the Laboratory Information System.
 * Laboratory performed the ordered tests on received specimens and/or incorporated calculated and reference data to produce the results referenced.
 * The laboratory result message contains both the appropriate patient information and the originating order information to associate the laboratory results to the correct patient and original order.
 * Laboratory information system is capable of and ready to send laboratory results electronically and in standardized structured format.
 * EHR system is in place and capable of receiving laboratory results electronically and in standardized structured format.
 * The laboratory result is verified and ready for release.

8.0 Post Conditions

 * The result is available for patient care.

9.0 Actors and Roles
This section describes the Business Actors that are participants in the information exchange requirements for each scenario. A Business Actor is an abstraction that is instantiated as an IT system application that a Stakeholder uses in the exchange of data needed to complete Use Case action(s); a Business Actor may be a Stakeholder. Furthermore, the systems perform specific roles in this Use Case as listed below.


 * **Actor** || **System** || **Role(s)** ||
 * Provider || Electronic Health Record System || Order Placer, Results Receiver ||
 * Laboratory || Laboratory Information System || Results Sender ||

10.0 Use Case Diagram
The following diagram depicts the Exchange of Electronic Clinical Laboratory Results use case.



**11.0 Scenario** This Use Case contains one scenario; the laboratory sends clinical laboratory test results for primary care to the Provider as standardized structured data.

11.1 Triggers

 * **Triggering Event** || **Specific Pre-Conditions** || **Description** ||
 * A preliminary test result is verified and released. || Laboratory has performed the ordered tests on received specimens to produce the results referenced. ||  ||
 * A final test result is verified and released. || Laboratory has performed the ordered tests on received specimens to produce the results referenced.

Laboratory has incorporated calculated and reference data to produce the results referenced. ||  ||
 * A corrected test result is verified and released. || Laboratory has performed the ordered tests on received specimens to produce the results referenced.

Laboratory has incorporated calculated and reference data to produce the results referenced. || The Laboratory has produced a corrected result that replaces a final result. ||
 * An amended test result is verified and released. || Laboratory has entered manually or through interface corrected data from an order into the Laboratory Information System.

Laboratory has incorporated calculated and reference data to produce the results referenced. || When incorrect information, such as age or gender, is provided to the Laboratory which was used to calculate normal ranges, abnormal flags or calculations and the test result itself is a correct value, an amended result based on the correct information is issued. ||
 * An appended test result is verified and released. || Laboratory has entered manually or through interface additional data from an order into the Laboratory Information System.

Laboratory has incorporated calculated and reference data to produce the results referenced. || The Laboratory reviews the final results and provides additional information without changing the original result values, for clarity. ||

11.2 Activity Diagrams
The visuals below depict a combination of all events described in the scenario flows which are described in further detail in the tables that follow.



** 11.2.1 Base Flow of Scenario **

 * **Step #** || **Actor** || **Role** || **Event/Description** || **Inputs** || **Outputs** ||
 * 1 || Laboratory || Results Sender || Laboratory Information System Sends Laboratory Test Results || Test Results Report || Sent Test Results Report ||
 * 2 || Provider || Results Receiver, Order Placer || Ambulatory Electronic Health Record System Receives Test Results, Incorporates in Standardized, Structured Format and, if available, Associates with a Patient and Laboratory Order || Sent Test Results Report || Received Test Results Report, Incorporated Test Results and Associated Test Results with Patient Record & if available the Order ||
 * 3 || Provider || Results Receiver, Order Placer || Accesses & Views Test Results in Ambulatory Electronic Health Record System || Received Test Results Report, Incorporated Test Results and Associated Test Results with Patient Record & if available the Order || Displayed Test Results ||

** 11.3.1 Information Interchange Requirements **

 * **Initiating System** ||  || **Information Interchange Requirement Name** ||   || **Receiving System** ||
 * Laboratory Information System || Send || Laboratory Test Result || Receives || Electronic Health Record System ||

** 11.3.2 System Requirements **

 * **System** || **System Requirement Name** ||
 * Laboratory Information System || Form a laboratory message with standardized structured data*meeting CLIA and other federal and state regulatory requirements. ||
 * Electronic Health Record System || Incorporate test data from the laboratory message as standardized structured data. ||
 * The definition of standardized, structured data can be found in section 2.3.

**12.0 Issues and Obstacles**
There is a lack of harmonization among data interoperability standards including vocabulary, laboratory and other messaging standards.

The Information Exchange workgroup identified many systematic issues related to standardization of electronic laboratory transactions. These issues were presented at the December 19, 2009 Health Information Technology Policy Committee meeting and have been expanded on within this section.

//Weak market incentives prevent rapid growth in standards-based laboratory interfacing; interfaces still not replicable and are thus time-consuming and costly.//


 * The majority of laboratory tests in the US are outside the scope of this use case because they occur within the intraorganizational environment.
 * Most laboratory results delivered through paper-based means (letter, fax) or non-structured electronic means.
 * Laboratory interfaces cost $5-$25K each to set up
 * Interface development and testing to meet accreditation requirements can take months, which lengthens interface time and cost

//High degree of allowable variation in current messaging and vocabulary standards makes interfacing time-consuming and costly.//


 * Messaging and vocabulary standards exist but because of the variety of available standards interoperability is difficult to achieve. HL7 2.5.1 released in 2007 but still not widely used.
 * Allowable variations in HL7 standards keeps costs high; high number of optional fields.
 * There are different expectations for laboratories which pose a barrier to the interoperability of laboratory results from ambulatory care environments.
 * Hospital laboratories usually use local codes; national laboratories closer to conforming with LOINC, but still have internal legacy-based variations.
 * LOINC and SNOMED still too complex for routine ambulatory implementation.
 * LOINC encoding should occur at the point of origin for test results, which would be in a clinical laboratory, including physician office, reference, or hospital laboratory environments. Laboratory professional are the subject matter experts to best choose the appropriate LOINC codes dependent on the methodologies they utilize in generating test results. Without the subject matter experts tasked with making these decisions interoperability issues will continue.
 * For correct assignment of a LOINC term, some information systems need to assign specific codes to a test, based on known details such as methodology, specimen type, etc. This is the expectation of the CDC for electronic laboratory reporting, for results required to be reported by law to public health agencies. It is recommended this practice be adopted for all of laboratory testing as it would be counterintuitive and defeat the purpose of this project to add another way of LOINC encoding and most information systems may not be able to handle a more complicated model.
 * With respect to quality reporting, consider the uses/purposes for LOINC terms. It is always easier for a specific LOINC term to be mapped to a test result by the clinical laboratory and then mapped to a more general LOINC test code for other downstream purposes such as quality assurance and quality monitoring. However, it is nearly impossible for a downstream end user to take a test with a less specific LOINC term and figure out if a more specific LOINC term would apply if needed without much more information from the clinical laboratory performing the specimen analysis.
 * Conversion to HL7 2.5.1 and LOINC would require investment by most hospitals, providers, laboratories and IT System developers for interface development and upgrading of systems.
 * No standard automated way to update compendiums and uploading order sets from different laboratories into the EHR; usually happens manually after fax notification.
 * Limited process/workflow/technology that allows echoing of the original requisition (order) identifier and/or patient identifier back to placer makes implementation of results reporting interfaces lengthy, costly, and suboptimal.
 * When an interface is initiated between a laboratory environment and any external (to the laboratory) entity, the laboratory is required by CLIA to test those interfaces before the order is even live in the EHR environment to ensure the results are transmitted correctly (right units, decimal places, etc).
 * Laboratories are required to yearly test these interfaces, including capture of screen shots of the end user receipt of each orderable laboratory test in their laboratory test catalog on a yearly basis for inspection and accreditation purposes.
 * An EHR may feature orderable tests from several laboratories in its menu and each laboratory is responsible for these interface tests.
 * Each laboratory may have different LOINC terms associated with each laboratory result as they each may use different methods in performing the test (i.e., a commercial laboratory versus a clinic laboratory or a hospital laboratory).

//Interpretation of legal requirements across states and laboratory sources varies widely; no requirements exist for messaging or vocabulary standards, and no ability to monitor/enforce standards.//
 * CLIA regulation that holds laboratory responsible for how results appear in the EHR is being implemented differently by various laboratory companies, hospitals, LIS vendors and EHR vendors, to be in compliance with the regulation.
 * CLIA Requirement 42 CFR 493.1291: “The laboratory must have an adequate manual or electronic system(s) in place to ensure test results and other patient-specific data are accurately and reliably sent from the point of data entry to final report destination.”
 * No regulatory requirements or market imperatives currently exist for messaging or vocabulary standards either on the receiving or on the transmitting end.

//Issues have been identified with Stage 1 Meaningful Use requirements.//
 * Meaningful Use states “170.207 (c) Laboratory test results. Standard. Logical Observation Identifiers Names and Codes (LOINC®) version 2.27, when such codes were received within an electronic transaction from a laboratory (incorporated by reference in §170.299).” The issue with this statement is that LOINC is used to identify the laboratory test, in this case the test performed to get the result, which, if it is coded, should be done using SNOMED.
 * Meaningful Use does not directly address the reasons why laboratories use the formats they do today. The majority of data reported by clinical laboratories is required by accreditation bodies which are not covered in Meaningful Use. Another driver having a huge impact on formatting is what the information systems capabilities are from each vendor product (EHR, LIS, etc.).
 * While ONC has selected to adopt LOINC version 2.27 for Meaningful Use new versions of the LOINC database are published twice a year with the most current version being 2.34. This can potentially cause issues for the laboratories because earlier versions of LOINC may contain LOINC terms that have been modified or deprecated. For this reason laboratories should be encouraged to use the most current version of LOINC.

13.0 Dataset Considerations
This Use Case acknowledges the variations in requirements for reporting across local, state, tribal, and territorial boundaries as well as voluntary versus mandatory requirements.

13.1 Message Content Requirements
The following table lists the expected content of a lab test result as defined by this Use Case. Order control should be fixed to required but can be empty (RE). ||
 * **Section Description** || **Data Elements (Required if available and applicable to support use case but not inclusive of any underlying standards)** || **Additional Notes** ||
 * Patient Identification Segment (Required) || PID, Patient Identifier List, Patient Name, Patient Mother’s Maiden Name, Patient Date/Time of Birth, Patient Address, Patient Administrative Sex, Patient Race, Patient Ethnic Group, Patient Telecommunication /Patient Contact Information, Patient Identity Unknown Indicator || Sufficient to identify patient in the EHR system as required by 42 CFR 493.1291(c)(1)* at a minimum and to enable lab to apply correct reference ranges, abnormal flags and calculations. ||
 * Patient Visit Information (Optional) || If needed. || As applicable in some circumstance to ambulatory setting for primary care (Give consideration to inpatient test being reported to PCP). The current Use Case doesn't require this information but it should be left as optional. ||
 * Patient Visit Additional Segment (Optional) || If needed. || As applicable in some circumstance to ambulatory setting for primary care (Give consideration to inpatient test being reported to PCP). The current Use Case doesn't require this information but it should be left as optional. ||
 * Common Order Segment (Required if Available) || Placer Group Order Number, Order Control, Placer Order Number (Same as Observation Request Segment [OBR]), Filler Order Number (same as OBR), Ordering Provider (Same as OBR), Ordering Location and Ordering Facility || May be "virtual" order and sufficient to match test result with order if available in the EHR system.
 * Observation Request Segment (Required) || Placer Order Number (same as Common Order Segment [ORC]), Ordering Provider (same as ORC), Filler Order Number (same as ORC), Universal Service Identifier, Results Report Time, Results Report Status, Copy to Providers, Linking Parent Child via Orders and Linking Parent Child via Results || Includes results report status (final, preliminary, corrected, amended and appended).

This is where parent and child are linked, e.g., reflex test result is linked backed to original result. Another example is an microbiology culture that identifies two organisms and susceptibility panels are linked to the culture but they also need to be linked to the individual organisms that were identified in the culture.

Universal service identifier is bound in this Use Case to the list of In Scope Tests.

The test report date is required by 42 CFR 493.1291(c)(3). || The observation ID is bound to In Scope test lists for this Use Case.* The test performed and test results and, if applicable, units of measurement or interpretation or both are required by 42 CFR 493.1291(c)(4) and (6). The name and address of the laboratory where test was performed is required by 42 CFR 493.1291(c)(2). || Specimen source is required by 42 CFR 493.1291(c)(5). Other information regarding condition and disposition of the specimen that did not meet laboratory’s criteria for acceptability is required by 42 CFR 493.1291(c)(7). ||
 * Notes and Comments Segment (Required if Available) || Comment/Note and Type Comment/Notes || May be associated with either observation request or observation result. ||
 * Timing/Quantity Segment (Optional) || Order Start and end date/time, Order Priority (of test performance) ||
 * Observation/Result Segment (Required) || Sequencing of result in relation to order, Value Type, Observation ID, Observation Value, Units, Reference Range, Abnormal Flags, Result Status Date/Time of Observation and of Analysis, Responsible Observer, Performing Organization, Address and Medical Director || Includes result status as defined in Pre-conditions.
 * Specimen (Required) || Specimen Type, Specimen Source Site, Specimen Accession Number and Date Time of Specimen Collection, Specimen Reject Reason and Specimen Condition || Specimen collection process was out of scope -- however necessary specimen data are to be entered into lab system and included with the result.
 * 45 CFR Part 170 is Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology Final Rule.
 * In scope test results are of four standard reporting formats as discussed next in Table 9 and the list of expected lab test results necessary to support the ambulatory care setting are in Appendix A//.//

13.2 Standard Reporting Format Requirements
To avoid multiple interfaces at both the laboratory and ambulatory EHR systems, the interface must accommodate all test results that will be transmitted electronically. The failure to achieve the above goals will have a significant negative impact on the electronic communications of laboratory results, harmonization of laboratory data, and the ability of physicians to meet the goals of meaningful use in all phases.

The primary focus of this Use Case is on sending lab test results as standardized structured data. As shown in Table 9 there are three categories of tests that can be represented as standardized structured data. These include results expressed with simple data types (positive/negative, numeric values and units of measure) or use standard terminology (e.g. LOINC and SNOMED CT where available or appropriate) or have limited sets of text results and defined structure. All such tests in the list of In Scope tests with such characteristics shall be sent and received as standardized structured data.

However, there are some test results that have complex data requirements (e.g. specific anatomic pathology, cytology, genetics tests) and are much more difficult to be sent as standardized structured data. Rather than excluding such test results from electronic transmission, this Use Case does not preclude supporting these tests without current constraint on format or clinical terminology (e.g. as PDFs, narrative text or data blobs). As standards and/or implementation guides are developed, and made available for currently unstructured data, they should also be sent as standardized structured data.

Therefore, the S&I Framework for laboratory test interfaces should accommodate all laboratory results sent electronically. Laboratory tests that have standard reporting formats are defined in table 9 below in numbers 1 -3. The 4th reporting format may be utilized in the cases where structured data does not apply (e.g. images).

Example 2: cytology / anatomic pathology Example 3: mutation type and location Example 4: organism name ||
 * **#** || **Reporting Format Requirement** || **Example** ||
 * 1 || Tests and/or components with numeric results, units, and normal ranges ||  ||
 * 2 || Tests and/or components with a limited set of textual results with or without normal ranges || Example 1: positive/negative/indeterminate, resistant/intermediate/susceptibility
 * 3 || Tests with defined structure in Observation Result Segment <span class="wiki_link_ext">OBX-3 through <span class="wiki_link_ext">OBX-8 for the reporting of Culture Results and Antimicrobial Sensitivities ||  ||
 * 4 || Semi Structured or Unstructured components or results || Tests and/or components reported in a PDF or data blob ||

To meet these goals, the initial deployment for the resulting LRI S&I Framework should accommodate the full range of laboratory tests as described above utilizing existing standards constrained with an existing implementation guide. The initial set of tests that should be addressed for harmonization and to determine success metrics should encompass or be selected from the list of LOINC coded tests in Appendix A.

Appendix A: List of In Scope Tests
This list was created using the list of LOINCs terms provided in the ELINCS 2.5.1 Implementation Guide: Orders & Observations; Ambulatory Care Lab Result (ELINCS),- Release 1 as a basis Some codes from the ELINCs list were removed because they were deprecated, erroneous or not applicable to use in the US. Anatomic pathology, cytology, microbiology, virology and serology tests, which were identified as important to ambulatory care, were added.

Representing the National Library of Medicine, Dr. Clem McDonald, filled in the remaining top 300 tests based on laboratory result data obtained from Indiana Healthcare, United Healthcare and a Boston provider group (marked in green). Dr. McDonald also provided guidance on LOINC terms that should be modified or removed from the list.

The list of tests has been organized by order panel or, for micro related tests, by target organism for easier readability. The LOINC terms included here are considered examples only – though they may be the more common LOINC terms, each laboratory needs to be sure to map their own tests to the most appropriate LOINC, even if it is NOT on this list. This is NOT an exclusive list of LOINC terms – ANY valid LOINC should be accepted in data exchange projects based on this specification.

NOTE: For tests not included as part of this list the result should still be sent using one of the four standard reporting formats outlined in section 13.2.

The Targeted Format column does not show report format designations for all test rows – the idea is to show that we cover each suggested format within the test list. However, please be aware that since all of the tests on the list have associated LOINC codes, there are no included examples that represent B reporting formats (use of laboratory specific local terminology only).



** Appendix B: Related Use Cases **
The Use Cases included in this section were used as an reference in the development of the LRI Use Case.

NOTE: This list should not be considered inclusive.
 * ONC/AHIC: Public Health Case Reporting
 * ONC/AHIC: Biosurveillance (Visit, Utilization, and Lab Result Data)
 * ONC/AHIC: Electronic Health Record (Laboratory Result Reporting)
 * ONC/AHIC: General Laboratory Orders
 * ONC/AHIC: Order Sets
 * NHIN: Biosurveillance Use Case
 * NHIN: EHR Lab Scenario Use Case Requirements
 * NHIN Direct: A provider EHR orders a test
 * NHIN Direct: Laboratory reports test results for some specific conditions to public health
 * NHIN Direct: Laboratory sends lab results to ordering provider
 * HIMSS: Biosurveillance - Monitoring and Detection
 * HIMSS: Cancer Reporting - Prostate Cancer, Chronic Lymphocytic Leukemia
 * IHE: Publishing of lab summary at discharge
 * IHE: Publishing of patient report into the regional patient health record
 * IHE: Ambulatory provider shares a laboratory report
 * IHE: Private and/or public laboratory publishes all its reports automatically
 * IHE: Health care institution produces a cumulative laboratory report of test performed on the patient
 * IHE: Public health laboratory shares report in a regional repository
 * ELINCS: Reporting of Laboratory Results to EHR Applications

Appendix C: Previous Work Efforts Related to Laboratory Results
NOTE: This list should not be considered inclusive.
 * The Healthcare and Interoperability Standards Panel (HITSP) Interoperability Specification (HITSP/IS01): The Electronic Health Records Laboratory Results Reporting Interoperability Specification defines specific standards to support the interoperability between electronic health records and laboratory systems and secure access to laboratory results and interpretations in a patient-centric manner.
 * Healthcare and Interoperability Standards Panel (HITSP) Laboratory Message Component (HITSP/C36): The Laboratory Result Message Component describes the use of a constrained Health Level Seven (HL7) Version 2.5.1 ORU – Unsolicited Observation Message for electronic laboratory results reporting.
 * HL7 Version 2.5.1. Implementation Guide: Order and Observations; Interoperable Laboratory Results Reporting to Electronic Health Record (EHR), Release 1 implements HITSP constraints above.
 * EHR-Laboratory Interoperability and Connectivity Specification (ELINCS) HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Ambulatory Laboratory Results (ELINCS), Release 1. Healthcare and Interoperability Standards Panel (HITSP) Laboratory Message Component (HITSP/C80): The Clinical Document and Message Terminology Component defines the vocabularies and terminologies utilized by HITSP specifications for Clinical Documents and Messages used to support the interoperable transmission of information
 * HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm)

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"