LRI+Strategy+and+Consensus+Statement

include component="page" wikiName="siframework" page="LRI Header" toc =Consensus Statement= This wiki page serves as an overview of the consensus positions discussed by the S&I Framework Laboratory Reporting Interface Initiative. These consensus statements are the basis of review for the S&I Framework Face to Face Meeting on June 14-15, 2011 in Washington, D.C.

Specific areas of analysis were looked at as part of standards harmonization, and a consensus statement has been drafted to guide the discussion on next steps for the Laboratory Results Interface Initiative. The consensus statements represent the views of the Laboratory Reporting Interface Initiative Workgroups:
 * Laboratory Reporting Interface Analysis
 * Laboratory Reporting Interface Vocabularies
 * Laboratory Reporting Interface Architecture/Implementation Requirements (IR)
 * Laboratory Reporting Interface Public Health Results Reporting

In addition, work of cross-S&I Framework workgroups is incorporated into this consensus:
 * Cross Use Case Simplification
 * Data Element Set

//The summary table below highlights key areas of decision reached by the S&I Framework Laboratory Reporting Interface workgroups on major issues encountered in standards harmonization. The table of contents shown on the right also allows the reader the opportunity to jump to specific sections of interest:// the performed test to obtain results || Consensus has been reached on requiring the use of the LOINC vocabulary but not constraining labs to using specific LOINC terms. Requires that the LOINC terms transmitted are valid. || =Introduction= //The standards harmonization effort for Laboratory Results Interface focused on the following key steps in completing its work://
 * **Implementation Area of Analysis** || **Description of this Area** || **General Consensus Statement** ||
 * General IG Policies || The usage of specific policy language to constrain the implementation guide || Consensus has been reached on outstanding policy variances ||
 * OIDs || The usage of OIDs by clinical laboratories, and a discussion of the policy and technology issues surrounding the usage of OID's || The LRI workgroups will develop a 12-24 month roadmap that focuses on OID piloting and future implementation ||
 * UCUM || Suitability of UCUM as the standard for units of measure to be used as part of a laboratory reporting implementation guide || The LRI workgroups will develop a 12-24 month roadmap that focuses on UCUM piloting and future implementation ||
 * SNOMED || The use of SNOMED as a controlled vocabulary || SNOMED is considered to be a viable vocabulary option for CWE data types but needs to be confirmed by pilot testing. ||
 * LOINC (Laboratory In-Scope Tests) || The use of LOINC as the standard vocabulary for communicating
 * Optionality || The level of optionality supported for each HL7 2.5.1 message segment based on specific rules of message cardinality that have been defined by HL7 to date. || Optionality is still being analyzed and reviewed as a factor in making a determination on an implementation guide path ||
 * Message Structure || The specific structure of the ambulatory laboratory results message || Consensus has been reached on the specific optionality for each message segment within the laboratory results message ||
 * Implementation Guide Selection || The specific HL7 implementation guide(s) to be selected for inclusion into Meaningful Use Stage 2 || The implementation guide path is still being reviewed and analyzed. At this time, consensus is formulating around the belief that neither HL7 implementation guide meets the S&I Framework Laboratory Results Use Case requirements in full ||
 * Reviewing the two HL7 implementation guides currently in use by clinical laboratories to identify variances (through review of the S&I Framework Laboratory Results Reporting Use Case)
 * Reviewing laboratory implementation guides policy and message variances
 * Identifying vocabulary recommendations for high-priority laboratory results that are in-scope for the S&I Framework Laboratory Results Reporting Use Case
 * Made preliminary recommendations on short and long term milestones surrounding consensus and possible implementation of UCUM and OID's
 * Determining the next steps towards finalizing the implementation guide path to be chosen by the LRI workgroups

The Laboratory Results Interface Working Groups have also created a formal graphic to show how each of the LRI working groups coordinated their work in support of the mission of the S&I Framework. This graphic highlights the dependencies and touchpoints for each working group, as it moves from use case development to the beginning of working code development.

The structure of this Consensus Statement is as follows:
 * Description of the context
 * Summaries of workgroup analysis and decisions to date
 * Use of supporting visuals and guidance (where appropriate)

The consensus statements for review by the workgroups are outlined in **BOLD. These statements will appear in the document and represent preliminary consensus, drawn from the activities of the workgroups to date.**

The S&I Framework Consensus Process can be reviewed here.

The Laboratory Reporting Interface Roadmap at the end of this page outlines specific milestones and activities to be completed once consensus has been achieved.

Assumptions
A number of assumptions were developed in support of harmonization activities.
 * The focus of harmonization is on an analysis of the requirements associated with ambulatory laboratory reporting, derived from the S&I Framework Reportable Lab Results Use Case.
 * Public health implications are part of the LRI consensus but are considered primarily in the context of ensuring alignment of the harmonized implementation guide with the requirements and issues raised by the public health community.
 * Public health recommendations are considered complimentary, NOT prescriptive.
 * Additional policy issues may apply, but the LRI harmonization workgroups focused solely on those related to ambulatory lab reporting implementation as laid out in the S&I Framework Laboratory Reporting Use Case.
 * All assumptions from the S&I Framework Reportable Laboratory Results Use Case.
 * HL7 2.5.1 is the foundational messaging standard for laboratory result reporting and will serve as the basis for the implementation guidance.
 * Two HL7 implementation guides will be used, in combination with the Use Case analysis, as input to arrive at an LRI Implementation Guide:
 * The V 2.5.1 Implementation Guide: Orders & Observations; Ambulatory Care Lab Result (ELINCS), Release 1. Initially developed by the California Healthcare Foundation (CHCF) and then adopted with some modifications by HL7.
 * The HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Result Reporting to EHR (US Realm), Release 1. Developed by the Healthcare Information Technology Standards Panel (HITSP) in response to the American Health Information Community (AHIC) Laboratory Results Use Case.

Issues and Challenges
Additional issues were identified that were specific to policy and technology, and were reviewed in the context of the S&I Framework Reportable Laboratory Results Use Case.
 * Usage of Object Identifiers (OIDs)
 * Usage of UCUM as a standard for units of measure
 * Usage of SNOMED as a controlled vocabulary for results of appropriate Laboratory Tests
 * Usage of LOINC as a controlled vocabulary for results of Laboratory In-Scope Tests
 * Optional and Required Message Segments and Data Elements within the Laboratory Results Message

=Position and Strategy for Implementation Guide Policies= In this section, specific policy discussions of the S&I LRI Implementation Guide Analysis Workgroup are summarized, with formal recommendations outlined in **BOLD**. These recommendations will be reviewed and edited at the S&I Framework Face to Face meeting so that final consensus voting can occur and consensus can be adopted surrounding work to date. Several policy issues were considered in looking at implementation guide suitability:
 * Result Identifiers
 * Escape Sequences
 * Data Types
 * Truncation
 * Conformance

Result Identifiers
There are two options to identify a result in V2.5.1:
 * 1) Non-Unique Order Number and Universal Service Identifier are necessary to uniquely identify a individual test ordered and resulted
 * 2) Unique Order Number only is sufficient to uniquely identify an individual test ordered and resulted, while the Universal Service Identifier is sent to indicate the requested test

Though the long term goal is to use unique order numbers, and re-affirmed through an agreement to deprecate the use of option 1 in V2.7, we recognize that the industry has not yet sufficiently adopted option 2 to be viable as the only mechanism for Meaningful Use Stage 2. Consequently we will allow for Meaningful Use Stage 2 both options 1 and 2, encourage software developers to migrate towards option 2 unique order numbers and non-unique order numbers while a later stage transitions to only unique order code numbers. There is an interoperability concern that most LIS systems currently do not support a unique order number in the ambulatory space. The implementation time frame for this should be pinned to the meaningful use stage. The group identified a need to identify profiles that tie an organization to a type of order number.


 * The preliminary consensus statement is that the implementer should identify the profile to be used and which profile they are compliant to.**

Escape Sequences
HL7 V2.5.1 and the implementation guide provide different guidance on how to use escape sequences. HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Result Reporting to EHR (US Realm), Release 1 indicates on page 5:


 * Senders and receivers using this profile shall handle escape sequence processing as described in HL7 Version 2.5.1, Chapter 2,Section 2.7.4 (Special Characters) and Section 2.7.5 (Hexadecimal).
 * Implementers may support escape sequences described in Sections 2.7.2 (Escape sequences supporting multiple character sets), 2.7.3 (Highlighting), 2.7.6 (Formatted Text) and 2.7.7 (Local).

Each implementer can suggest potential strengthening statements as needed.


 * The preliminary consensus is that the language from the HITSP implementation guide can be used as a starting point to define escape sequences.**

Data Type Considerations
Both implementation guides use varying data types and pre-adoption of more current versions.


 * The preliminary recommendation is that there should be no blanket pre-adoption of all post-HL7 V2.5.1 data types (for example, data types specified in HL7 Version 2.6, 2.7, or as anticipated in 2.8)**

Consequently, for each field we will determine whether a more current version of the data type should be adopted before we pre-adopt a more current version of a data type for all its uses.

The recommendation is that the best data type be adopted to properly message the requirements of the field and that it be clearly defined which HL7 version the data type specification is from for each field in the segment. Unless otherwise specifed vv2.5.1 defintions are to be assumed. For those fields where the data type has multiple components, each subcomponent will be defined as required, conditional, optional or not needed including if the field can be empty even if it is required or conditional.

Truncation

 * The recommendation is that truncation is not allowed within the implementation guide.**

Conformance
Based on experience to date with both implementation guides and Meaningful Use Stage 1 testing, we determined that V2.5.1 definitions for conformance useage indicators is not sufficiently dis-ambiguated. It is the expressed intent that all conformance constraints are well defined in the implementation guide and are populated into an appendix. After review of the various documents we concluded that the following definitions from both a sender and receiver perspective should be applied. (NOTE TO SUPPORT TEAM - Suggest to lift the updated language from the word document and insert directly rather than by reference. NOTE TO READERS - until these two notes are removed, the links below are not accurate.)

Conformance Verbs
The following keywords in this document are to be interpreted as follows: An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) Note that the force of these words is modified by the requirement level of the document in which they are used. ||
 * **Keywords to Indicate Requirement Levels**
 * MUST** or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
 * MUST NOT** or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
 * SHOULD** or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
 * SHOULD NOT** or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
 * MAY** or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.

**Conformance Usage**
//The conformance Usage is revised for the S&I Framework, but is based on HL7 Version 2.8// //[|Click Here] to edit// media type="custom" key="9845185"

Additional conformance guidance includes:
 * The preliminary recommendation is to use "shall" and "must" interchangeably. A clear statement should be defined that highlights all key "shalls" to be noted by the implementer.**
 * Optional elements should not be conformance tested, by the receiver
 * If the sender usage is in scope:
 * For sending entities, conformance testing should be applied specifically to the base standard (for the two HL7 implementation guides considered within this initiative, this would be HL7 2.5.1) (NOTE TO SUPPORT TEAM - I don't think this was mentioned anywhere)

=Position and Strategy for Message Structure= A thorough review of the message structure for both HL7 implementation guides led to the formalization of structure recommendations outlined in the table below. The IG's and the Use Case requirements still need to be completed before all requirements are completed.
 * Click here for the most recent IG Messaging Structure Variance Analysis **


 * The general recommendation of the workgroup is that the message structure of the Laboratory Results message should follow the message structure recommended in the above table. This message structure was derived from both HL7 implementation guides.**

=Position and Strategy for Use of LOINC Vocabulary= The general recommendation of the workgroup is for the use of the Logical Observation Identifier Name and Code (LOINC) vocabulary to be required. The LOINC terms transmitted by the sender in OBX.3 must be valid but it is not the intent of the workgroup to constrain senders to using any specific LOINC terms for the tests defined on the Laboratory In-Scope Tests list.

=Laboratory In-Scope Tests= It is not possible for the workgroup to specify every possible LOINC code for every possible laboratory test. As such, the workgroup developed an approach that led to a specific list of laboratory in-scope tests with associated LOINC term descriptions. The approach used to evaluate the list of in-scope tests developed for the S&I Framework Laboratory Results Reporting Use Case is listed below:
 * 1) Reviewed the tests on the In-Scope Tests listfrom the S&I Framework Laboratory Results Reporting Use Case. This list represents the most commonly ordered tests/panels in the ambulatory care setting.
 * 2) Analyzed the example LOINC codes for each in-scope test.
 * 3) Selected tests that represent each type of target format (listed below) to ensure that all will be included in an LRI Initiative pilot.
 * 4) Focused on the list of tests needed for the pilot. The workgroup clarified what level of detail should be included in the In-Scope tests list.
 * 5) Ensured that the In-Scope test list covers several test categories (including formats, components, etc.) of varying levels of complexity and various ranges of tests (analyze for patterns).
 * 6) The definition of "targeted format" is based on the following reference information from the Use Case document (In-Scope Tests scope statement):
 * The S&I framework for laboratory test interfaces should accommodate all laboratory results sent electronically. To avoid a situation where complex data requirements of certain types of results (e.g. specific anatomic pathology, cytology, genetics tests) would cause exclusion, the scope will support these tests without current constraint on format or clinical terminology (e.g. as PDFs, narrative test or data blobs). The balance of the laboratory tests that have standard reporting formats as defined below will be broken into two categories:
 * A) Those with simple data types (positive/negative, numeric values and units of measure) or use standard terminology (e.g. LOINC or SNOMED CT where available and appropriate).
 * B) Those that may have laboratory specific local terminology used in electronic reporting of results.

The standard targeted report formats are further defined as follows:
 * A1 -- Tests and/or components with numeric results, units and reference ranges
 * A2 -- Tests and/or components with a limited set of textual results with or without reference ranges
 * Example 1: Positive/negative/indeterminant, resistant/intermediate/susceptible
 * Example 2: Cytology / Anatomic pathology
 * Example 3: Mutation type and location
 * Example 4: Organism name
 * A3 -- Tests with defined structure in Observation Result Segment OBX-3 through OBX-8 for the reporting of culture results and antimicrobial sensitivities
 * A4 -- Semi-structured or Unstructured
 * Tests and/or components reported in a PDF or data blob format

The primary focus is on sending lab test results as standardized structured data. From the above list, 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 have limited sets of text results and defined structure. All 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, the In-Scope Tests list 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.

The workgroup reviewed example LOINC codes for each of the tests from the Use Case In-Scope Tests list and finalized a harmonized list of tests and the strategy recommended for pilot testing on the S&I Framework wiki in a table format (Appendix A). It should be noted that the pilot test list was developed for the purpose of testing the appropriateness of requiring the use of the LOINC vocabulary. **The intent is for senders to transmit a valid LOINC term (consistent with the constraints of the expected format) for the tests on the harmonized In-Scope Tests list based on the Property and Scale attributes but not restrict or dictate which specific LOINC terms are considered as acceptable or not acceptable. The LOINC code transmitted does not necessarily need to be included in the In-Scope Tests list from the LRI Initiative Use Case to be considered as valid but should contained in the LOINC database published by Regenstrief.** = = =Position and Strategy for Use of SNOMED Vocabulary= The workgroup identified potential benefits and issues for using the SNOMED CT vocabulary. Since SNOMED CT is a viable vocabulary already widely used in focused settings (e.g. Public Health and NAACCR), the workgroup recommends it as a required vocabulary for communicating coded results when reported as CWE (Coded With Exception) data types in OBX.5 for specific result categories as defined below. We also recommend it for specimen source terms in SPM.4. However, the workgroup agreed that pilot testing is needed to fully resolve the potential issues prior to implementation.


 * Potential Benefits**
 * Adopted by public health, especially for organism names
 * Used in combination with generic LOINC terms (for cultures), it will help automate detection of reportable lab results
 * Used in reporting absence and presence findings (detected, not detected, etc.), it helps to enable automation and aggregation of results
 * Increased use across the lab domain may potentially increase interoperability while preserving the local language


 * Potential Issues**
 * One code can be represented with several descriptions which will most likely require approval from CLIA and its accrediting bodies to allow lab results to be reported at the concept level rather than at the verbatim level. Until approval and/or clarification from regulatory bodies is obtained, compliance could be achieved by utilizing CWE.9 to communicate the exact laboratory result in printed and displayed text when SNOMED CT is used.
 * As an example from an implementation point of view, the SNOMED code would be contained in CWE.1 to CWE.3, but CWE.9 could be used to communicate original text (i.e. the text printed on the report) so the test results would match between the printed and displayed text to be in compliance.
 * It may be difficult to use SNOMED CT terminology for coding all of the available specimen fields other than SPM.4 (e.g. SPM.5 through SPM.9) due to the limitations in the number of source fields available in many laboratory information systems.
 * Most laboratory information systems only have one or possibly two source fields.
 * There is a large degree of inconsistency in the type of information reported in the source field(s). Some systems send type and site, others send only source which can be described as either type or source site.
 * Per the IG Analysis workgroup, this situation necessitates that the required data type for SPM.5 through SPM.9 be "O" instead of "RE" (as RE would force systems to manage the information if it was sent)
 * Although SNOMED CT is the preferred terminology, the HL7 2.5.1 implementation guide also contains coded specimen tables which are currently in use by senders. It is understood that the HL7 tables are likely to be deprecated over the next few years, but their use needs to be allowed during the interim period.

In laboratory test result reporting, the semantic relationship between OBX-3 (Observation Identifier) and OBX-5 (Observation Value) is that the asserted value in OBX-5 "refines" or "qualifies" the meaning of the laboratory test that is specified in OBX-3. This is true regardless of whether SNOMED-CT is used. When SNOMED CT is used for a coded result value in OBX-5, this understanding of the semantic relationship is consistent with the use of qualifiers and refinement as specified in the SNOMED CT Concept Model. It supports the use of SNOMED CT concepts (codes) from the "qualifier value" or another appropriate SNOMED CT hierarchy matching the "semantic type" of the laboratory test specified by the LOINC code in OBX-3. These result value concepts may specify a presence/absence value, an organism name or, in some cases, a finding of a negative assertion (e.g., "394869007^Campylobacter species not isolated^SCT"). We believe this is an appropriate position given the following examples:
 * CWE Data Types in OBX.5**

1. OBX-3 observations with quantitative LOINC test codes have numeric result values (plus units, if appropriate) which fully specify the observation. 2. OBX-3 observations with qualitative LOINC test codes using ordinal result scales may fully specify the analyte/component measured in OBX-3, thus only requiring a “Presence/Absence” type SNOMED CT concept from the "qualifier value" hierarchy to fully specify the observation. 3. OBX-3 observations with "presence or identity" LOINC test codes using nominal result scales (e.g. bacterial cultures) may require a SNOMED CT concept from the "organism" hierarchy to fully specify the observation.

For specific result categories:
 * Organisms
 * Identify using codes from the SNOMED CT “organism” hierarchy
 * This will normally exclude the use of codes from the “clinical finding” hierarchy representing the presence of a specific organism (e.g., "312210001^methicillin resistant staphylococcus aureus positive^SCT”, "431256002^culture positive for vancomycin resistant enterococcus^SCT”, "441070005^Human enterovirus present^SCT”). However, in some cases a specific absence finding may be appropriate (e.g., "404520004^no Chlamydia trachomatis found^SCT”).
 * Organism-related substances (e.g. toxin, DNA, RNA, antigen, antibody, etc.)
 * Identify using codes from the SNOMED CT “substance” hierarchy (e.g., "12671002^Clostridium difficile toxin^SCT”, "121181000^Chlamydia trachomatis DNA^SCT”, "121006005^influenza virus A antigen^SCT”)
 * This will normally exclude the use of codes from the “clinical finding” hierarchy representing the presence of a specific organism-related substance (e.g., "310541005^Clostridium difficile toxin A detected^SCT”). Currently (as of the January 2011 release) we are not aware of any SNOMED CT codes representing the absence of an organism-related substance.
 * Presence and absence findings
 * Identify using codes from the SNOMED CT “qualifier value" hierarchy (e.g., "52101004^present^SCT”, "10828004^positive^SCT”, "2667000^absent^SCT”, "260385009^negative^SCT”)
 * Anatomic Pathology
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13px;">Use of SNOMED CT codes is recommended, but further evaluation is needed to determine which hierarchies are appropriate for use
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13px;">The NAACCR examples list "abnormal morphology" codes
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13px;">Clinical genomics and additional clinical areas
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13px;">Consider whether other vocabularies in addition to, or in place of, SNOMED CT might apply

The workgroup recommends that when the specimen source is transmitted as CWE data types in SPM.4, values should be drawn from SNOMED CT or may be drawn from HL7 table 0487. NOTE : Pending the outcome of successful pilot testing, the workgroup expects that SNOMED CT would be the required vocabulary in the long term.
 * Specimen source in SPM.4**
 * Use specimen hierarchy for SNOMED CT (preferred)
 * HL7 table 0487 is an acceptable alternative for an interim period (until deprecated by HL7)
 * HL7 table 0487 (previously table 70) is a commonly used vocabulary, for example in use with NAACCR.
 * For CWE.9 to be used to report the specimen information, CMS will need to clarify whether the original text (order placer's) submitted to the lab or coded text is considered to be in compliance. At this time, it is understood that the order placer often expects to receive the specimen information as originally submitted but clarification is needed from CMS as to whether this is a compliance requirement.

Successful pilot testing will be defined as:
 * Pilot Testing Strategy**
 * 1) SNOMED CT is included for CWE data types in OBX.5 (test results) and SPM.4 (specimen source)
 * 2) SNOMED CT is successfully received, displayed and incorporated as structured data
 * Receiver will provide printed report, which must match the communicated content from the sender's report of record
 * Receiver will provide screen shots of the displayed results, which must match the communicated content from the sender (at a minimum, using CWE.9)
 * 1) Valid SNOMED CT codes are used from the appropriate hierarchies
 * 2) Identified issues from pilot testing must be resolved. The mechanism of resolution is still to be determined.

The Lab and Messaging Community of Practice (LMCoP) [], a group currently consisting of Public Health Laboratories, CDC and the national ELR working group but open to all laboratories, is currently working on a cross-map of HL7 terms to SNOMED CT. These are not always one-to-one mappings because terms and settings are not always compatible. There will be a need to separate the following: specimen, site and collection method. The specimen crossmapping table can be accessed here: [].
 * Cross-mapping Efforts for SNOMED CT with other Vocabularies**

The Vocab Workgroup also supports the development of a process or system for correlating SNOMED CT and LOINC codes. It is noted that the CDC/CSTE ELR Task Force Standards Workgroup has completed the development of Reportable Condition Mapping Table (RCMT) content. RCMT provides mapping between a __reportable condition__ and its associated LOINC lab tests and SNOMED lab results. The CDC Vocabulary Server (PHIN VADS) would allow the public health community to browse, search and download the RCMT content. The RCMT can be accessed here: [].

=Position and Strategy for Use of UCUM Vocabulary= UCUM (Unified Code for Units of Measure) implementation issues were discussed within the context of the S&I Framework Reportable Laboratory Results Use Case. While there do not appear to be any clearly identified issues with using UCUM for HL7 C32 reporting, and while UCUM is also being used in support of Public Health reporting requirements and NAACCR, there are still significant issues that prevent clinical laboratories from using UCUM in the context of ambulatory laboratory reporting. The workgroup determined that UCUM appears to be a viable option for reporting units of measure but must be pilot tested in order to understand the impact of key issues identified. Until this is completed, the workgroup will not be able to recommend adoption of UCUM as a standard vocabulary for inclusion in Meaningful Use Phase 2, but will develop a plan of action or roadmap for the next 12-24 months to work toward that goal.

The following analysis outlines the key benefits and issues of UCUM:


 * Potential Benefits**
 * Provides standard codes for Units of Measure (UoM)
 * Adopted for case reporting for Public Health


 * Potential Issues**
 * If no Units of Measure are available, unclear as to whether OBX.6 will be populated with a default UCUM code
 * Issues with how titers are reported, that is, will {titer} be translated into a UCUM unit of "1".
 * Will Units of Measure (UoM) on paper reports vs. electronic messaging show as an exact match if UCUM translations occur outside of the laboratory information system (CLIA compliance requirement)
 * It is unclear as to what the impact will be of using some of the characters defined in the UCUM standard vocabulary (e.g. curly braces, square brackets, asterisks) on sender and receiver systems
 * There may be an issue with UCUM code length for some of the codes contained in the UCUM table. The code length may be longer than the field length available in some electronic systems (e.g. LIS, EHR, LIMS, HIE, PHR). They may also be longer than the coded element component of CWE in OBX.6 in the HL7 message.
 * Providers typically do not look at the units of measure (focusing mainly on the result value and reference range), and altering that process through applying a standard for Units of Measure may cause that process to fail. When UoM symbols are used that are not expected, the provider then must also analyze the units of measure when evaluating patient results.
 * Implementation of UCUM within the laboratory community is very limited at this time. There are specific implementation issues identified with UCUM that have slowed its adoption, and while workarounds have been developed by Regenstrief, these workarounds are not well known.
 * Lack of a clearly defined change control process to address potential issues identified during pilot implementations.
 * Many senders use the Units of Measure (UoM) fields as a String data type rather than using it as a CE (Coded Entry) data type. There is a potential that some labs are sending the UoM in the ID field of the CE data type instead of the description field. If labs were to implement UCUM to exchange Units of Measure, the description and the ID fields may both be exposed to the user rather than just the description.


 * Workgroup Recommendations**
 * 1) ONC should sponsor a pilot testing project including hospitals, physicians, and labs that requires the use of UCUM to determine the impact in a controlled process.
 * Transmission of UCUM codes containing special characters. At a minimum, this would include the use of curly braces, square brackets and asterisks.
 * Transmission of UCUM codes with a field length of more than 20 characters
 * Transmission of laboratory test results that do not contain units of measure
 * Develop a list of tests to be included in pilot testing to cover the above situations
 * 1) Work with states that have implemented or are in the process of implementing UCUM to identify best practices
 * 2) A table of Regenstrief-approved UCUM codes should be assembled that implementers can easily access and understand so they know exactly what codes for units of measure need to be incorporated into messaging
 * 3) For UCUM to be adoptable, CMS needs to develop or modify interpretive guidelines to allow equivalent codes/descriptions of units of measure between electronic and printed reports to be considered in compliance with CLIA regulations.
 * 4) Review of existing UCUM code documentation by Regenstrief for removal of duplicates and resolution of inconsistencies, character usage and code length. In addition, a more transparent process for change requests and updates to UCUM should be implemented. Recommend that Regenstrief include at least one example UCUM unit for each quantitative LOINC term.
 * 5) Regenstrief should provide documentation of the proposed workarounds for UCUM implementation issues and develop an outline of how they should be communicated going forward.
 * 6) At a minimum for Meaningful Use Phase 2, when sending units of measure as text, they must be placed in the correct component of OBX.6 (CWE.2 or CWE.5). This will ease the transition for adoption of UCUM by the user community.

Successful pilot testing will be defined as:
 * Pilot Testing Strategy**
 * 1) Sender and receiver systems will successfully transmit and incorporate UCUM codes containing special characters such as curly braces, square brackets and asterisks into the data transmission and display
 * 2) Electronic data messages containing non-standard units of measure (e.g. titers) or no units of measure will not be converted to a UCUM default value (i.e. "1")
 * 3) Receiver will provide visual verification of communicated vs. stored/displayed content, which must match.
 * 4) Identified issues from pilot testing must be resolved. The mechanism of resolution is still to be determined.

Development of UCUM Roadmap
The LRI Vocabulary Workgoup has reviewed UCUM and its feasibility as a standard for Units of Measure and the general recommendation is to develop an implementation roadmap to further review UCUM and determine its suitability for implementation. The roadmap should target a 12-24 month timeline. It will need to be reviewed with clinical laboratories and other interested healthcare stakeholders and will include a transition period for individuals and organizations to become accustomed to UCUM. The implementation timeline would be spearheaded with the LRI workgroups to focus on near-term milestones to study UCUM feasibility and represent possible UCUM changes.

The implementation roadmap planned for UCUM will focus on the following milestones:
 * Begin an immediate review of UCUM issues and engage Regenstrief to map out next steps.
 * In order to facilitate adoption of UCUM, a change request process needs to be developed and documented by Regenstrief.
 * The S&I Framework Standards Development team will engage Regenstrief to ensure appropriate follow-up for the items identified above.
 * Engage clinical laboratories to schedule a short-term UCUM pilot.

=Position and Strategy for Use of HL7 Tables= The LRI Implementation Guide Analysis Workgroup requested that the LRI Vocabulary Workgroup review the content of existing HL7 tables 0078 (Abnormal Flag), 0001 (Administrative Sex), 0005 (Race) and 0004 (Patient Class), along with table FIPS6_4 (County) as referenced in the Implementation Guide, to determine completeness and relevance. In addition, since HL7 table 0487 is noted to be an interim acceptable vocabulary for SPM.4 as referenced above, this table was included in the review process [|Appendix_B_SNIVocabOwnedTables_v7.xls]. For reference, the document also contains a listing of SNOMED CT specimen types.

Following review, the LRI Vocabulary Workgroup concluded that no changes were necessary to the content of the above HL7 tables. The recommendation for adopting HL7 table content to be used as vocabulary assumes that the HL7 Version 2.5.1 standard is the required version, except as specified below.

HL7 Table Content Version exception: Table / HL7 Version 0078-Abnormal Flags / v2.7

The LRI Implementation Guide Analysis Workgroup also shared a newly proposed table for Universal Service Class and requested review and feedback from the LRI Vocabulary Workgroup [|Appendix_C_UnivServClass_v3.xls]. After further discussion, the IG Analysis WG concluded that they were unable to find a classification that made sense to enable improved conditions. Therefore, the newly proposed table was withdrawn and no further action was taken by the LRI Vocabulary Workgroup. =Position and Strategy for OIDS= Discussion on OID's within the S&I Framework has centered around documentation of the specific policy and technology issues associated with their implementation. Throughout the analysis of OID's, two specific challenges have arisen, specific to there being a need, as defined in the S&I Framework Reportable Laboratory Results Use Case, for a method to determine that a person has registered or used an OID. The challenge for OID's is twofold:
 * Technology: There are issues that pertain to the specific technology of OIDs.
 * Policy : These issues refer to the policy and exist irrespective of the OID technology.

Development of OID Roadmap
The LRI workgroups will continue to review OID issues at the S&I Framework Face to Face meeting. Because the HL7 implementation guides reviewed in standards harmonization do not require the use of OIDS, a roadmap is a feasible option for consideration, with the stipulation that the S&I Framework LRI workgroups will need to begin work on near-term milestones in the roadmap immediately. The 12-24 month implementation timeline planned for OID's will focus on the following milestones:
 * Begin an immediate review of short-term OID requirements.
 * Conduct detailed analysis of OID requirements with EHR and LIS vendors.
 * Review OID alternatives.
 * Review the option of developing a single assigning authority.
 * Open formal comment period on the use of OID's by EHR vendors and LIS vendors, managed through the ONC Health IT site.
 * Identify OID pilots to determine feasibility for clinical laboratories.

Specific Technology Issues
The technology surrounding OID's has limited implementation within the laboratory reporting setting. This is due to a variety of technical and policy reasons which have been discussed by the LRI Workgroups.


 * A preliminary recommendation has been made that to resolve some of these technology issues, an OID profile can be established between the Placer and Filler. Based on that profile, OIDs would be assumed and OIDs would be included in the message only when there was an exception to the profile. This will reduce the burden on the network and infrastructure for gathering and resending of OIDs in the messages.**


 * Further review of this recommendation will occur at the S&I Framework Face to Face meeting**

Specific Policy Issues
One of the main policy issues surrounding OID's is the perception that a centralized authority is needed to manage OID's. Currently, multiple assigning authorities can be used for OID's, which can lead to providers having multiple OID's to manage. Without centralized governance in healthcare providers could have multiple OIDs and therefore need to send the OID based on the receiver. This adds to the complexity of the situation and creates overhead that is not necessary adding burden to the entire system.

A recommendation has been proposed that work be done to develop a single assigning authority for healthcare in the US and that this centralized authority gets rolled out to ensure a successful roll-out to all appropriate healthcare entities between now and Stage 3 of Meaningful Use. The analysis of OID's is ongoing, but a path forward will be determined over the next 2-3 months to ensure that a consensus can be reached on this issue, and that the issue is well understood. **The preliminary recommendation is that consensus surrounding OID's will be worked out within a 1-2 year timeframe within the S&I Framework. Work should also be done to identify those specific data elements within a laboratory result message that would require use of an OID to create strong identifiers.** = =

=Position and Strategy on Public Health Requirements= Public health requirements for meaningful use are an important consideration to ambulatory laboratory reporting. As the work on the S&I Framework Laboratory Results Reporting Use Case commenced, it became clear that public health reporting requirements, while out of scope for the current use case, would need to be considered in the selection of the LRI implementation guide in the context of Meaningful Use requirements for Stage 2 and Stage 3. The decision was made within the S&I Framework to create a Public Health Reporting Results Workgroup to analyze public health considerations to make a formal recommendation for harmonization efforts. This workgroup was also tasked with developing a roadmap for harmonization of the LRI S&I Framework initiatives chosen implementation guide path with the existing HL7 Public Health Implementation Guide.

Key objectives were outlined for Public Health Reporting Requirements:
 * The S&I Framework Public Health Results Reporting Workgroup would need to outline gaps in the current set of requirements for public health.
 * The S&I Framework Public Health Results Reporting Workgroup would need to develop a set of requirements for roadmap for harmonizing the IG selection for ambulatory laboratory reporting with the current HL7 Public Health IG.
 * The S&I Framework Public Health Results Reporting Workgroup would need to SPECIFICALLY focus on outlining the requirements and dataset considerations path forward with clear milestones that will harmonize the laboratory data exchange between public health and clinical care with the Lab Reporting Interface specification.


 * The consensus of the group is that an abbreviated use case is applicable to ensure that public health requirements are considered within the scope of the S&I Framework. The official recommendation reads:**
 * **This abbreviated use case outlines the requirements for Public Health Laboratory Reporting for the consideration in the selection of the Laboratory Results Interface Initiative Implementation Guide**


 * The Public Health Laboratory Results Workgroup recommends that this abbreviated use case and associated dataset considerations be reviewed by the Laboratory IG Analysis Workgroup and considered in the context of their work.**

The use case 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 by inpatient electronic health record systems 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.

The abbreviated use case is located here. =Laboratory Reporting Implementation= Open questions still exist on what the next steps for the Laboratory Reporting Interface initiative will be following the completion of standards harmonization. The LRI Architecture/Implementation Requirements Workgroup looked at specific options for reference implementations and pilots based on potential development of a conceptual architecture for a laboratory reporting reference implementation.

Issues with Laboratory Reporting Reference Implementations
The initial path chosen was to develop a reference implementation that would generate a message that complied with the LRI Implementation Guide Analysis group's chosen path for an implementation guide and the CIM/Vocabulary Group’s CIM Model and Vocabulary. Immediate assumptions that were identified were that this reference implementation would:
 * 1) Provide value for an essentially low risk implementation -The S&I Framework implementation guide path will most likely be a harmonized version of two HL7 implementation guides that are already being used in production systems. There are vague specifics on ELINCS implementations available (last scan produced 11 qualified implementations) and specifics on implementations of a fully constrained version of HITSP are also unclear. So there is a low risk that the S&I Guide wouldn’t be implementable.
 * 2) Provide artifacts to meet the objective for “<span style="color: #000000; font-family: 'Arial','sans-serif'; font-size: 13px;">the development of reusable tools and services.” - The CIM/Vocab Workgroup is focused on identifying a subset of tests, already used in production systems. CIM/Vocab is also creating artifacts that might require reconfiguration of LISs or repopulation of existing tables, and not significant new code.

Two significant issues immediately were identified as well though:
 * 1) The large labs and providers already doing electronic lab reporting have the infrastructure and staff to implement additional code. However, they already have LISs and EHRs that have similar functionality for other laboratory implementation guides.
 * 2) Many of the small labs and providers, not doing electronic lab reporting, don’t have the infrastructure and/or staff to implement any additional code. They rely on the LIS and EHR vendors and might not be able to implement an LRI reference implementation.

LRI Transformation Services
One idea explored has been the development of laboratory message transformation services. It might be several years before any regulation driven solution would solve the problem of electronic laboratory reporting implementation guide adoption. In the interim, there is the problem of multiple implementation guides already in use. Some states are discussing and implementing a state message transformation service, for example, as part of a State HIE. These transformation services would allow parties using different implementation guides to exchange messages. The S&I Framework LRI reference implementation could provide value by developing transformation services that support both the S&I Framework implementation guide path and existing laboratory reporting implementations that would need a path for transitioning to the new Meaningful Use Stage 2 requirement. The S&I Framework LRI Reference implementation would provide value by developing transformation services that focused on transformations such as:
 * HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Result Reporting to EHR (US Realm), Release 1 to potential LRI Implementation Guide and vice versa.
 * ELINCS to S&I Framework Guide and vice versa.
 * HL7 V2.3.1 to S&I Framework Guide and vice versa. It is estimated that many parties doing electronic laboratory reporting are using some constrained version of HL7 V2.3.1.

Sender and Receiver Implementation Considerations
The required elements for the receiver must be clearly defined. The S&I Framework LRI Initiative also wants to define those elements sufficiently clear from the sender's perspective, to the extent that it enables unambiguous exchange and thus true interoperability.

If the receiver is expected to accept and parse a well-formed message based on the implementation guide path chosen by the S&I Framework LRI Initiative, then at the least the sender (or their intermediary if used and allowed) must send the same well-formed message. The sender can send more as long as the receiving system does not break. We would expect that the receiving EHR (provider in ambulatory care environment) will likely to be required to receive such messages under Stage 2. Whether a sender is required to do so is beyond the policy and reach of MU, except (potentially) in the special case of hospitals that submit labs through certified EHR modules for that purpose.

= = =Laboratory Reporting Harmonization Roadmap= All work involved in the development of a consensus statement for the S&I Framework will be ongoing and may change based on circumstances and new policy or regulatory developments. This roadmap attempts to document a path forward as work moves from implementation guide and vocabulary analysis to the formulation of clear consensus statements that will lead to the development of implementation guidance.
 * The preliminary recommendation for sender and receiver considerations is that an implementation guide path will be available for any sender to send a well-formed message to enable a receiver to qualify for Meaningful Use**

Develop S&I Framework Laboratory Reporting Implementation Guidance
The implementation guidance WOULD NOT be intended as a ballotable implementation guide and is not intended to be the specific implementation guide(s) to be chosen. The implementation guidance would serve as complimentary material to the implementation guide path chosen by the LRI workgroups. This implementation guidance would also serve as referenceable material on how to implement ambulatory laboratory reporting reference implementations in the short-term.
 * Development of S&I Framework Implementation guidance specific to the consensus adopted by the LRI workgroups should begin immediately**. This implementation guidance will include the following key elements:
 * Implementation Guide References
 * Implementation Models
 * Implementation Examples

Identify Laboratory Reporting Pilots

 * The consensus of the workgroups is that implementation pilots should be identified immediately. These pilots would focus on further testing the issues identified by the LRI IG Analysis and CIM/Vocab workgroups.** The pilots would specifically focus on two key objectives:
 * Piloting of those area where consensus has already been achieved by the LRI workgroups, specifically surrounding policy considerations and message structure. This will help to further inform the consideration of message segment optionality.
 * Piloting of those areas where consensus will be achieved over the longer term; specifically surrounding UCUM and OID's and where public health and inpatient reporting requirements have not been met by the HL7 implementation guides.

Develop HL7 Implementation Guide Transition Recommendation
Based on progress to date, it is clear that neither of the two HL7 implementation guides considered is sufficiently mature to serve the needs for lab resulting with an initial focus on ambulatory laboratory reporting and the ability to consistently and rapidly move into the inpatient and public health domain. <span style="color: #000000; font-family: 'Arial','sans-serif'; font-size: 13px;">With the assumption that both HL7's "Interoperable Laboratory Result Reporting To EHR (US Realm) R1" and "Ambulatory Care Lab Result (ELINCS) R1" satisfy a reasonable set of use cases already, emphasis has been placed on the variances between these two HL7 implementation guides and the development of a consensus on how to reconcile the variances such that the resulting implementation guide to be considered for Meaningful Use (which could be a modified version of an existing HL7 implementation guide, a new blend of both HL7 implementation guides, or the attempt to select an HL7 implementation guide as-is) can be deployed into the Ambulatory space, while providing a reasonable stepping stone to the next version of that HL7 implementation guide that can be deployed across the full continuum (Ambulatory, Public Health, Acute, etc.).

Analysis to date <span style="color: #000000; font-family: 'Arial','sans-serif'; font-size: 13px;">clearly highlights the variances (small and large) and the LRI IG Analysis has reviewed and come to consensus on many of those variances to date. where the two HL7 implementation guides are in agreement on specific message structures, data elements, etc., there has been general consensus to accept this agreement But where there is a major discrepancy, it has been determined that both implementation guides could meet ambulatory laboratory reporting requirements with the variable of determining which would require more work to change.


 * The S&I Framework Face to Face Meeting will focus on generating consensus for the implementation guide path to be taken.**

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