LRI+Public+Health+Reportable+Lab+Results+-+Abbreviated+Use+Case

include component="page" wikiName="siframework" page="LRI Header" **The Public Health Reportable Lab Results Abbreviated Use Case was approved through consensus by the LRI Public Health Lab Results Workgroup on June 8th, 2011. This document will be presented to the LRI Harmonization Workgroup as a formal recommendation for inclusion within the Implementation Guide.**

**Please reference the document below, or to access the Microsoft Word version.** toc

**1.0 Introduction**
This document outlines the requirements for Public Health Laboratory Reporting for the consideration in the selection of the Laboratory Results Interface Initiative Implementation Guide. In order to adhere to the requirements for Public Health Laboratory Reporting as outlined in the Meaningful Use criteria, the HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health was utilized to develop and validate the contents of this document.

In order to achieve broad interoperability for the reporting of laboratory results to Public Health agencies, the following key points need to be taken into consideration:
 * **Use of strong identifiers for key information objects.** These information objects include patients, orders, providers and organizations. A strong identifier is one that uniquely identifies the object in question in a global fashion. This means the identifier includes enough information to remain unique when taken out of the context within which the identifier was created. This is accomplished through the use of assigning authorities for the identifier. In this guide, an assigning authority is normally handled either as an ISO Object Identifier (OID). The combination of the identifier and the assigning authority should always be unique. This uniqueness ensures that each identifier can be broadly shared among independent healthcare organizations and still point to its originally associated object.


 * **Use of Vocabulary Standards. ** The HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health guide calls for specific vocabulary standards for the exchange of laboratory information. Use of standard vocabularies is important for a number of reasons. It allows broad distribution of healthcare information without the need for individual institutions to exchange master files for data such as test codes, result codes, etc. Each institution maps its own local vocabularies to the standard code, allowing information to be shared broadly, rather than remaining isolated as a single island of information. Standard vocabularies, particularly coded laboratory results, enable more automated decision support for patient healthcare, as well as more automated public health surveillance of populations. At minimum laboratory tests (LOINC), results (SNOMED) and the related units (UCUM) should be coded with the appropriate standards.

2.0 Scope
The Use Case is directed at addressing the requirements for Meaningful Use for certified EHR technology for the sending of laboratory results from the EHR to the Public Health Agency. The underlying guide does not intend to replace or exclude other requirements for reporting to Public Health.

3.0 User Story
The User Story exhibits the operational context of what is occurring within the Use Case.

A Provider Organization //(results sender)// detects a preliminary, amended, appended or final lab result (of a patient) to report to a Public Health Agency. Due to State laws, specific lab results for particular conditions are mandated to be reported to Public Health Agencies. Characteristically, either a statute or regulation determines both the timing and process of reporting lab results as well as the appropriate Public Health jurisdiction to receive the lab results. The Provider has made the determination that the lab result is clinically and legally relevant to report to the Public Health Agency. The Provider //(results sender)// sends the reportable laboratory test results to the Public Health agency //(results receiver)//.

4.0 Actors and Roles
This section describes the Business Actors that impact information exchange requirements for the 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 is not a Stakeholder. Furthermore, the systems perform specific roles in this Use Case as listed below:

Note: This includes tribal, local, state and federal (jurisdictional boundaries) public health agencies.
 * **Actor** || **System** || **Role** ||
 * Public Health Agency* || Electronic Public Health System || Results Receiver ||
 * Provider Organization || Electronic Health Record System (or LIS that performs certified EHR technology functions) || Results Sender ||

5.0 Use Case Diagram
The following diagram depicts the actual Use Case for Public Health Reportable Labs:
 * 1) The ability to transmit reportable lab results to a Public Health System
 * 2) The ability of the Public Health System to receive reportable lab results



6.0 Scenario
This Use Case contains one scenario: The Reportable Lab Result is Transmitted Directly from the EHR System to the Public Health System.

6.1 Triggers

 * **Triggering Event** || **Specific Pre-Conditions** || **Description** ||
 * The system identifies and/or receives a reportable laboratory result. || An EHR system is responsible for sending reportable lab results to the Electronic Public Health System. ||  ||

6.2.1 Base Flow of Scenario

 * **Step #** || **Actor** || **Role** || **Event/Description** || **Inputs** || **Outputs** ||
 * 1 || Provider Organization || Results Sender || EHR System Identifies Reportable Lab Result || Reportable Lab Result || Request to send reportable Lab Result to Electronic Public Health Systems ||
 * 2 || Provider Organization || Results Sender || EHR System Sends Lab Result(s) to Electronic Public Health System || Reportable Lab Result || Sent Reportable Lab Result ||
 * 3 || Public Health Agency || Results Receiver || Electronic Public Health System Receives Reportable Lab Result || Reportable Lab Result || Received Reportable Lab Result ||

6.3.1 Information Interchange Requirements
6.3.2 System Requirements
 * **Initiating System** || **Action** || **Information Interchange Requirement Name** || **Action** || **Receiving System** ||
 * Electronic Health Record System || Send || Send Reportable Laboratory Results || Receive || Electronic Public Health System ||
 * **System** || **System Requirement** ||
 * Electronic Health Record System || Send Reportable Lab Results ||
 * Electronic Public Health System || Receive Reportable Lab Results ||

7.0 Dataset Considerations
This Use Case acknowledges the variations in requirements for reporting across jurisdictional boundaries as well as voluntary versus mandatory requirements. The datasets which address the scenarios in this Use Case have been included as the following:

7.1 Message Content Requirements
The ELR guide was used to define these requirements. Sending application, Sending facility Receiving application, Receiving facility, Date/Time of message, Message type/Trigger Event, Message control ID, Processing ID, Version ID, Accept acknowledgment type, Application acknowledgment type, Message Profile Identifier ||  || (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 Phone Number Home, Patient Phone Number Business, Patient death Data & Time, Patient Death Indicator, Last Update Date/Time, Last Update Facility, Species Code || Sufficient to identify patient in the EHR system as required by 42 CFR 493.1291(c) (1)* at a minimum and to enable laboratory to apply correct reference ranges, abnormal flags and calculations. ||
 * **Section Description** || **Required Data Elements (Required means the field is either R (Required), RE (Required but can be empty), C (Conditional), CE (Conditional but can be empty). Refer to ELR guide for message structure (order, usage and cardinality of message segments).** || **Additional Notes** ||
 * Message Header Segment || Field separator, Encoding characters,
 * Patient Identification Segment
 * Next of Kin || Set ID - NK1, Next of Kin/Emergency contact, Relationship, Address, Phone number, Organization name - NK1, Contact person's name, Contact person's telephone #, Contact person's address ||  ||
 * Patient Visit Information || Set ID - PV1, Patient Class, Assigned Patient Location, Admission Type, Hospital Service, Visit Number, Discharge Disposition, Admit Date/Time, Discharge Date/Time ||  ||
 * 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), Call Back Phone Number, Ordering Facility Name, Ordering Facility Address, Ordering Facility Phone, Ordering Provider Address || May be "virtual" order and sufficient to match test result with order if available in the EHR system.

Order control should be fixed to required but can be empty (RE). ||
 * Observation Request Segment (Required) || Set ID, Placer Order Number (same as Common Order Segment [ORC]), Filler Order Number (same as ORC), Universal Service Identifier, Observation Date/Time, Observation End Date/Time, Relevant Clinical Information, Specimen Received Date/Time, Ordering Provider, Order Callback Phone Number, Results Report/Status Change – Date/Time, Results Status, Parent Result, Parent, Reason for Study, Principle Result Interpreter || 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 a 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).
 * Notes and Comments Segment (Required if Available) || Source of Comment, Comment/Note and Type Comment/Notes || May be associated with either observation request or observation result. ||
 * Observation/Result Segment (Required) || Set ID, Value Type, Observation ID, Observation Sub- ID, Observation Value, Units, Reference Range, Abnormal Flags, Observation Result Status, Date/time of the Observation, Observation Method, Date/Time of Analysis, Performing Organization, Performing Organization Address and Performing Organization Medical Director || Includes result status as defined in Pre-conditions.
 * Specimen (Required) || Specimen ID, Specimen Type, Specimen Type Modifier, Specimen Additives, Specimen Collection Method, Specimen Source Site, Specimen Source Site Modifier, Specimen Role, Specimen Collection Amount, Specimen Collection Amount, Specimen Collection Date/Time, Specimen Received Date/Time, Specimen Reject Reason || Specimen collection process was out of scope – however necessary specimen data are to be entered into laboratory system and included with the result.

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). || Note: The NIST data elements are included as part of ELR guide and therefore part of the message content requirements listed in table 6.

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