LRI+-+Structured+Data+Text+to+Include+as+Part+of+Scope

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

Definitions of Structured Data Applicable to Lab Results Reporting
 (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. ||  42 CFR Part 495 || Extension of definitions in cited final rules by Structured Data Sub-Workgroup ||  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. 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. ||
 * || **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"
 * Source || 45 CFR Part 170 §170.302(h)
 * 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 || <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 2.9pt 0in; text-indent: 0in;">Receive, display (in human readable format) and incorporate structured (lab) data || <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 2.9pt 0in; text-indent: 0in;">(Proposed) Receive, display and incorporate standardized structured (lab) data ||
 * <span style="font-family: Helvetica,sans-serif; line-height: 13pt; margin: 2.9pt 0in; text-indent: 0in;">Description || <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 2.9pt 0in; text-indent: 0in;">"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...

BACKGROUND
<span style="font-family: Helvetica,Arial,sans-serif; line-height: 13pt; margin: 6.55pt 0in; text-indent: 0in;"> 42 CFR Parts 412, 413, 422 et al. Final rule(Definition of structured data): //In the proposed rule, we// **//defined structured data//** //as data that has a specified data type and response categories within an electronic record or file. We have revised that definition for the final rule as discussed below.// T//he distinction between structured data and unstructured data applies to all types of information.// **//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.// [1],[3]

<span style="font-family: Helvetica,Arial,sans-serif; line-height: 13pt; margin: 6.55pt 0in; text-indent: 0in;"> As part of the Use Case and Requirements documents for this workgroup, it is important to have a clear definition of "structured and unstructured data" and "structured lab results", for several reasons:

DEFINITIONS
<span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">The FR[1,3] gives a reasonable high level definition of structured data and we should focus on what the definition of standardized structure data should be and address any limitations or suggest improvements in Stage 2 MU. An alternative technical complementary definition suggested from this subWG as: 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 in the set where appropriate. The definition of "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.
 * <span style="font-family: Helvetica,Arial,sans-serif; font-weight: normal; line-height: 13pt;">**Syntax** is explicitly defined by a the syntactic model from which software can be implemented (manually or automatically), that determine whether instances of data are syntactically well-formed.
 * <span style="font-family: Helvetica,Arial,sans-serif; font-weight: normal; line-height: 13pt;">**Semantics** is explicitly defined by a semantic model from which software components can be implemented (manually or automatically), that perform computations according to the meaning of each syntactically well-formed data
 * <span style="font-family: Helvetica,Arial,sans-serif; font-weight: normal; line-height: 13pt;">To support **interoperability** among heterogeneous structured data, the underlying heterogeneous syntactic and semantic models should enable the construction of software components across syntactic models

<span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">**Structured lab test results** are data elements associated with specific observations, encoded within an agreed-upon syntactic structure, where each data element is identified by an agreed-upon identifier and the value of the observation has an identified type and associated metadata to guide interpretation of the value. //OR// An encoded test observation according to an agreed to vocabulary that is described with a fully-decomposed set of attributes within an well defined syntactic structure. The term "structured lab results" does not imply that the data is numeric; it may also be nominal (true/false, present/absent) or even textual. Results may be "more structured" or "less structured" depending on how much meaning can be extracted from the data in an agreed-upon way.

<span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">The term "structured lab results" also doesn't imply that vocabulary standards such as LOINC or SnoMed are used; though clearly use of these standards enhances the interoperability of the data. The FR[1] mentioned that structured data don't depend on an established standard. Together, standard clinical terminologies(SNOMED) and classifications(ICD9, ICD10) represent a common language, allowing clinical and lab data to be effectively shared between EHR systems for enhanced interoperability.

REFERENCED STANDARDS
<span style="color: #000000; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">§170.205 Content exchange standards and implementation specifications for exchanging electronic health information §170.207 Vocabulary standards for exchanging electronic health information Regulatory Referenced Standard (Certification Criteria from NIST for incorporating lab results as structured data into and EHR under MU Stage 1.) <span style="font-family: Helvetica,Arial,sans-serif; line-height: 17px;">Thus the EHR must indicate (and display and use for summaries) the seven data elements above. But the EHR can use any structure, data type, value set it wants. Moreover, there is __no standard__ specified for receiving lab results in a structured form. The 7 components to be part of the lab result may not fully address what structured means ...
 * **<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;">None specified ** || <span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt; line-height: 13pt; margin: 0.65pt 0in; text-indent: 0in;">42 CFR 493.1291(c) 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. ||

<span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">__Other Considerations__

<span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">The only lab result messaging standards specified under the certification criteria in the final rule for MU Stage 1 are for Public Health Surveillance and Reportable Lab Data. The former requires EHR technology electronically record, modify, retrieve, and submit syndrome-based public health surveillance information in accordance with the standard specified in § 170.205(d)(1) or § 170.205(d)(2).

<span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">(1)Standard. HL7 2.3.1(incorporated by reference in §170.299). This has subsequently been deleted because CDC replaced its Implementation Guide for 2.3.1.

<span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">(2) Standard. HL7 2.5.1(incorporated by reference in §170.299).

<span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">Reportable lab results criterion require the EHR technology to electronically record, retrieve, and submit laboratory test results containing LOINC codes in HL7 v2.5.1 format to public health and other agencies. Thus reportable labs criterion requires
 * 1) <span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt;">Electronic submission of lab results to public health agencies. Standard. HL7 2.5.1 (incorporated by reference in §170.299). Implementation specifications. HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) (incorporated by reference in §170.299). AND
 * 2) <span style="color: #000000; font-family: Helvetica,Arial,sans-serif; font-size: 10pt; font-weight: normal; line-height: 13pt;">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).

METRICS/MEASURES MEANINGFUL USE
<span style="color: #000000; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">More than 40% of clinical laboratory test results whose results are in positive/negative or numerical format are incorporated into EHRs as structured data [3] <span style="color: #000000; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;"> <span style="color: #000000; font-size: 10pt; font-weight: normal; line-height: 13pt; margin: 10px 0px; padding: 0px;">

EXAMPLES/CASES

 * //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;">'Our goals for the Stage 2 meaningful use criteria, consistent with other provisions of //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;"> **//Medicare and Medicaid law, expand upon the Stage 1//** //criteria to encourage the use of health IT// //for continuous quality improvement at the point of care and the exchange of information in the most structured format possible, such as the electronic transmission of orders entered using// //computerized provider order entry (CPOE) and the electronic transmission of diagnostic test results (such as blood tests, microbiology, urinalysis, anatomical pathology tests, radiology, cardiac imaging, nuclear medicine tests,// //pulmonary function tests, genetic tests, genomic tests and other such data needed to diagnose and treat disease). For the final rule, we elaborate on our plans for Stage 2. We expect that stage two meaningful use requirements will// //include rigorous expectations for health information exchange, including more demanding requirements for eprescribing and incorporating structured laboratory results and the expectation that providers will electronically// //transmit patient care summaries to support transitions in care across unaffiliated providers, settings and EHR systems.' [1]//
 * //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;">'In the proposed rule, we defined the term ‘‘diagnostic test results ’’ as all data needed to diagnose and treat disease, such as blood tests, microbiology, urinalysis, anatomical pathology tests, radiology,cardiac imaging, nuclear medicine tests, and pulmonary function tests. We maintain this description for the final rule. We said that when the information was available in a structured format we //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;"> //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**. We provide additional information on structured data in the// //comment and response section, but maintain for the final rule the concept that the exchange can be of structured or unstructured data.'[1]//
 * **<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;">CDA/HL7 **<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;"> reference as structured report for lab interoperability example case ( [|WWW.hl7.org] ), HL7 2010 Normative Lab domain, [|IHIC 2011 cases,]
 * //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;">We also believe that there is a natural technological approach which will facilitate a move in this direction and which, over time, will also lead to beneficial changes in the way that EHRs are structured. This approach begins with the observation that the best way to manage and store data for advanced data-mining techniques is to break it down into the smallest individual pieces that make sense to exchange or aggregate. We will refer to these kinds of data as “**tagged data elements**,” because each unit of data is accompanied by a mandatory //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;"> **//“metadata tag//**//” that describes the attributes, provenance, and required privacy protections of the data. Modern, networked computers are particularly good at indexing, finding, and retrieving data that are discrete and “close to the surface,” even when the pieces are distributed widely over many computer systems and data-stores. So storing data in this fashion can create an environment in which clinicians can access a patient-centric record tailored for each medical encounter, and in which health organizations, researchers and public health agencies can aggregate data for a broad variety of uses//.[2]
 * //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;">We clarify that we do not expect Certified EHR Technology to natively (or internally) support //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;"> **//LOINC//** //in its entirety, which is why we do not believe that it is necessary to specify a// //subset of common LOINC codes. Given the diverse comments and requests for clarification on this specific aspect of the certification criterion, we agree with commenters that we should not require a LOINC code that has been received, to then be displayed. Accordingly, we have decided to remove this requirement from the certification criterion. We do, however, wish to further clarify our current approach to Certified EHR Technology’s use of LOINC codes. Presently, we expect Certified EHR Technology to be able to reuse a LOINC code once it has been received and is accessible to Certified EHR Technology. We do not expect, as we mention above, that Certified EHR Technology will have to crosswalk or map internal or local codes to LOINC codes. [3]//
 * **//<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;">Comment. //**<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;"> //One commenter requested that we clarify whether the structured data requirement applies to all laboratories (including reference labs, hospital labs, physician office labs, and physicians performing their own lab tests).**Response.**// //This certification criterion requires Complete EHRs and EHR Modules to provide the capability to receive clinical laboratory test results in a structured format as a condition of certification. It does not speak to how laboratories must send the test results.[3]//
 * //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;">Section 170.302(g)---Incorporate laboratory Test Results. While we understand the intent of these commenters’ suggestions, we do not believe that it is within the cope of this rule to dictate the standard by which laboratories transmit test results. The scope of this rule is the adoption of certification criteria that specify required capabilities of Certified EHR Technology (in this case, receiving laboratory information in structured format) //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;"> **//and not, in this instance, specifying the standard by which laboratories must transmit//** //test results.[3]//
 * <span style="font-family: Helvetica,sans-serif;">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.// //(page 44339) [1]//
 * //<span style="color: black; font-family: Helvetica,sans-serif; font-size: 10pt;">Subpart C---Certification Criteria for Health Information Technology § 170.302 General certification criteria for Complete EHRs or EHR Modules § 170.304 Specific certification criteria for Complete EHRs or EHR Modules designed for an ambulatory setting. § 170.306 Specific certification criteria for Complete EHRs or EHR. Laboratory test results. At a minimum, the version of the standard specified in § 170.207(c); [3] //

LITERATURE/REFERENCES

 * 1) <span style="font-family: Helvetica,sans-serif;">Part II Department of Health and Human Services Centers for Medicare & Medicaid Services 42 CFR Parts 412, 413, 422 et al. Medicare and Medicaid Programs; <span style="font-family: Helvetica,sans-serif; line-height: 17px;">Electronic Health Record Incentive Program; Final Rule, JULY 2010
 * 2) <span style="font-family: Helvetica,sans-serif; line-height: 17px;">REPORT TO THE PRESIDENT REALIZING THE FULL POTENTIAL OF HEALTH INFORMATION TECHNOLOGY TO IMPROVE HEALTHCARE FOR AMERICANS:THE PATH FORWARD Executive Office of the President President’s Council of Advisors on Science and Technology December 2010
 * 3) <span style="font-family: Helvetica,sans-serif; line-height: 17px;">Part III Department of Health and Human Services 45 CFR Part 170 Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology; Final Rule JULY 2010
 * 4) <span style="font-family: Helvetica,sans-serif; line-height: 17px;">David Blumenthal, M.D., M.P.P., and Marilyn Tavenner, R.N., M.H.A. The “Meaningful Use” Regulation for Electronic Health Records N engl j med 363;6 nejm.org august 5, 2010

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