21st Century Cures Part 2: Electronic Health Information

As noted in the first part of this series, 21^st Century Cures prohibits any practice that could materially interfere with a patient’s (or their authorized representative’s) ability to access, exchange, or use their electronic health information without special effort – unless an exception applies. So just what is “electronic health information,” or “EHI”? This blog post will look at how the final rule defines it, and what that means going forward.

The proposed rule took a fairly broad approach. It defined EHI as electronic protected health information and “any other information that identifies the individual, or with respect to which there is a reasonable basis to believe the information can be used to identify the individual and is transmitted by or maintained in electronic media . . . that related to the past, present, or future health condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual.” Practically speaking, that’s almost all of the data contained within an electronic health record system. The proposed definition could reach not just clinical data formatted to the ONC Health IT Certification Program’s standards, but also claims data and practice management data like scheduling. For much of that data, no consensus-based standard exists for its exchange.

In contrast, the final rule defines EHI as electronic protected health information as defined under HIPAA, to the extent that it would be included in a designated record set. For 24 months from the publication of the final rule in the Federal Register, EHI for the purpose of information blocking findings will be limited to EHI identified by data elements that are in the United States Core Data for Interoperability (“USCDI”). This is a much more constrained definition than proposed. You can find version 1 of the USCDI here, and read more about its use generally here. Version one includes the following data classes and data elements:

1. Allergies and Intolerance
   1. Substance (Medication)
   2. Substance (Drug Class)
   3. Reaction
2. Assessment and Plan of Treatment
3. Care Team Members
4. Clinical Notes
   1. Consultation Note
   2. Laboratory Report Narrative
   3. Discharge Summary Note
   4. Pathology Report Narrative
   5. History & Physical
   6. Procedure Note
   7. Imaging Narrative
   8. Progress Note
5. Goals
   1. Patient Goals
6. Health Concerns
7. Immunizations
8. Laboratory
   1. Tests
   2. Values/Results
9. Medications
   1. Medication Allergies
10. Patient Demographics
    1. First Name
    2. Last Name
    3. Previous Name
    4. Middle Name
    5. Suffix
    6. Birth Sex
    7. Date of Birth
    8. Race
    9. Ethnicity
    10. Phone Number
    11. Phone Number type
    12. Email address
    13. Current Address
    14. Previous Address
11. Problems
12. Procedures
13. Provenance (meta data)
    1. Author Time Stamp
    2. Author Organization
14. Smoking Status
15. Unique Device Identifiers for a Patient’s Implantable Device(s)
16. Vital Signs
    1. Dialostic Blood Pressure
    2. Heart Rate
    3. Inhaled Oxygen Concentration
    4. Systolic Blood Pressure
    5. Respiratory Rate
    6. BMI Percentile
    7. Body Height
    8. Body Temperature
    9. Weight-for-length Percentile
    10. Body Weight
    11. Pulse Oximetry
    12. Head Occipital Frontal Circumference Percentile (birth-36 months)

This is a much, much smaller data set than what was proposed. From a practical perspective, this enhances the importance of the Application Programming Interfaces (“APIs”) based on Fast Healthcare Interoperability Resource (“FHIR”) – the main means by which ONC envisions moving the USCDI between systems. It also enhances the importance of the Standards Version Advancement Process (“SVAP”) because the USCDI is not meant to be a static set of data.

The Standards Version Advancement Process (“SVAP”) allows for health IT developers to incorporate new standards and implementation specifications that are not incorporated explicitly into the 2015 Edition of Health IT Certification. It is also the mechanism by which ONC intends to add and test new data classes and data elements to the USCDI. That means it will be important for organizations to track emerging elements through the SVAP so they can adjust their roadmaps to account for those new data classes and elements: eventually those data elements will graduate from the SVAP to the certification program. So even if your organization does not test emerging standards, the SVAP is an important tool because it acts as a looking glass for what you can expect in the USCDI as it expands in scope.

The consequences of not staying hooked into that process is the potential that you are caught off guard by a new data class or element that becomes part of certification and requires substantial development and testing resources and/or time. The failure to implement a new USCDI data element to which a health IT product must certify to will have a series of downstream impacts. It will impact the ability for providers to use those products in programs like the Merit-based Incentive Payment System. Of course, it could also lead to a finding that an organization engaged in information blocking, which may result in a significant civil monetary penalty. And as discussed yesterday, it might even implicate the product’s underlying certification. The USCDI and SVAP are a big deal and given their central role to the regulatory scheme ONC has developed, I encourage every health IT developer to monitor them.