1. You are here:
  2. Home
  3. Resources
  4. Page not found

Brief History of Selected US Legislation Related to Interoperability (2006 – 2019)

Introduction

Ensuring secure, interoperable health information technology (IT) systems and data exchange has been a critical US national priority for more than a decade.  Below, we briefly describe selected US Federal legislative activity in this area, following Executive Order 13410 signed by President George W. Bush mandating secure, interoperable health information exchanges within the federal government and its consortia.  In the time since this gauntlet was laid, many legislative and executive actions have impacted health technology, data exchange, and health care practitioners and patients.

Here, we provide a partial list, which we will keep up-to-date as events unfold.

  • The Health Information Technology for Economic and Clinical Health Act (HITECH). This legislation was part of The American Recovery and Reinvestment Act of 2009[1] (ARRA).   It created the Office of the National Coordinator for Health IT and introduced requirements for meaningful use (MU) of common data, promoted electronic health record (EHR) adoption, expanded data breach notification requirements, and identified electronic protected health information (ePHI)
  • The Medicare Access and CHIP Reauthorization Act(MACRA)[2]of 2015 provides a new framework for reimbursing clinicians who successfully demonstrate value over volume in patient care, which is critically contingent on interoperability of healthcare data.
  • The 2015 Edition Health IT Certification Criteria Final Rule[3]specifies the capabilities, standards, and specifications that certified electronic health record technology need to include to, at a minimum, achieve meaningful use under the Medicare and Medicaid EHR Incentive Programs. 
  • The 21st Century Cures Act[4](2016). Requires health care information systems to allow individuals to securely and easily access structured (i.e., located in a fixed field in a record) electronic health information “without special effort”

 

ARRA/HITECH Act (Public Law 111-5)

The American Recovery and Reinvestment Act of 2009 was enacted following the Recession of 2008 to stimulate the economy by modernizing the US national infrastructure.  Among its provisions is the Health Information Technology for Economic and Clinical Health (HITECH) Act[5], which made the adoption and meaningful use of health IT a national policy priority.  HITECH established a legal framework for advancing health IT adoption and use.  It included an amendment to the Social Security Act (Sec 4101(a)) to create financial incentives in Medicare and Medicaid programs to encourage qualifying health care professionals and hospitals to become meaningful users of certified EHR technology (CEHRT).  It located the effort within the Centers for Medicare & Medicaid Services (CMS) and the Office of the National Coordinator for Health IT (ONC).

The HITECH Act required accurate exchange of limited EHR data for each person in the United States by 2014 (Sec. 3001(c)(3)(A)(2)).  This included requirements to accurately identifypatientsbytheirhealthinformation, deliver privacy and security protections for the electronic exchange of an individual’s individually identifiable health information, and deliver on an individual’s right to receive an accounting of disclosures (Sec. 13405).

In July 2010, Congress authorized ONC under the HITECH Act to complete the adoption of the initial set of standards, implementation specifications, and certification criteria to achieve Stage 1 of meaningful use.  To meet the requirement of meaningful use for compliance, exchanges must support a minimum of the Common Meaningful Use (MU) Data Set[6].  Complying with this requirement meant that developers would be required to use either the HL7® Continuity of Care Document (CCD) or the ASTM Continuity of Care Record (CCR). In April 2013, ONC established rules for meaningful use Stage 2, requiring use of Consolidated-Clinical Document Architecture[7](C-CDA). 

 

Medicare Access and CHIP Reauthorization Act of 2015

HIPAA, HITECH, and executive orders created a common foundation for meaningful use and access to health care data and information, but clinical reality lagged behind rulemaking.  The Medicare Access & CHIP Reauthorization Act of 2015[8](MACRA) was passed to further motivate the adoption of meaningful use-compliant EHR systems that enable patient information accessibility.

MACRA changed Medicare to reward clinicians for value of care over volume of care.  It established a Quality Payment Program to pay physicians that met the meaningful use requirements by streamlining multiple quality programs under the new Merit-based Incentive Payments System[9](MIPS).  Under MIPS, eligible professionals receive bonus payments based on quality, resource use, clinical practice improvement, and meaningful use of certified EHR technology

Yet, while MACRA succeeded in promoting the adoption of EHRs that supported common meaningful use data, these EHR systems were often still hobbled by poor interoperability. This led to the creation of certification programs that encourage health IT vendors to demonstrate their ability to interoperate in return for public certification. 

2015 Edition Health IT Certification Criteria Final Rule 

The 2015 Edition Health IT Certification Criteria Final Rule[10](45 CFR 170) specifies the capabilities, standards, and specifications that certified electronic health record technology needed to include to achieve meaningful use under the Medicare and Medicaid EHR Incentive Programs.

It encouraged health IT product vendors to provide: 

  • the interoperability essential for systems to communicate
  • tools for clinicians and hospital critical processes, care coordination and quality improvement; 
  • patient access to health information electronically;
  • developers’ assurance that their products meet recognized structure and functionality. Appendix B provides a list of the certification criteria for developers, providers, and vendors.

 

21stCentury Cures Act (2016)

The 21st Century Cures Act[11]mandates approaches to improve healthcare IT in relation to nationwide interoperability, information blocking, and adoption of the U.S. Core Data for Interoperability[12](USCDI) requirements and the Health Level 7 Fast Healthcare Interoperability Resources[13](HL7® FHIR®) protocol.  

Interoperability is among the highest priorities for the health and healthcare industry. Defined as the ability of different systems to communicate with each other, share and make use of data, it’s essential to electronic health information exchange (HIE) reaching its full potential.  It is also essential to the creation of a high performance health system in which value rather than volume drives payment.

In passing the Cures Act, Congress acknowledged that information blocking is currently a major barrier on the path to nationwide interoperability.  Information blocking occurs when some individuals and entities engage in practices that unreasonably limit the availability and use of electronic health information (EHI) for authorized and permitted purposes. The ONC 2019 NPRM specifies when a vendor or provider has a justifiable reason for withholding or limiting access to healthcare information. It also requires health care information systems to allow individuals to securely and easily access structured  electronic health information “without special effort.” The Cures Act also mandates HL7 FHIR API standards to provide patients’ easy access to their structured electronic health information.  Payers will be required to support the exchange of structured HL7 APIs.  

ONC 2019 Notice of Proposed Rulemaking (NPRM)   

ONC’s 2019 Notice of Proposed Rulemaking[14](NPRM), 45 CFR 170 and 171, authorized under the Cures Act, proposes to update the 2015 Edition by revising and adding certification criteria that would establish the capabilities and related standards and implementation specifications for the certification of health IT, including pediatric care. These updates would enhance interoperability, improve the accessibility of patient records[MA2] [RB3] to prevent harm, promote privacy and security of health information, and provide exceptions to information blocking. 

One of the central elements of the proposed interoperability rules is the expanded use of application programming interfaces (APIs).  APIs hold new promise in health care as a powerful and positive disrupter to enable clinical data inoperability and convenient patient access to personal data.  (See here)

This NPRM suggests that the USCDI “will need to continually expand data elements and upgrade capabilities associated with Certified APIs as the FHIR standard and its implementation specifications mature, and the National Coordinator expands the USCDI…”[15]. In particular, the proposed rule calls for the use of “USCDI as a minimum data set expected for exchange; the USCDI is included in such criteria as ‘transitions of care’ [16], ‘view, download, and transmit to 3rd party’[17], and the API criteria[18].

FHIM supports the mandated data standards identified in the HHS regulations.  It is the only health information model where ONC required data standards are easily accessible for developers and analysts to quickly develop APIs and applications that will be interoperable.  FHIM enables health plans and payers to participate in the exchange of data via APIs using the same set of standards or, most importantly, different standards that are mapped to it.

Trusted Exchange Framework and Common Agreement (TEFCA)

One way the Cures Act aims to drive greater interoperability is by asking ONC to assist and encourage development of public-private partnerships to create a “trusted exchange framework, including a common agreement among health information networks (HINs) [RB4] nationally.” Overall, the legislation aims to promote interoperability among disparate EHRs.  ONC developed the Trusted Exchange Framework and Common Agreement[19](TEFCA) standards-based technology to exchange EHI with other HINs and to promote interoperability using FHIR APIs and Common Core Profiles.[RB5]  If successful, it will give patients, health care providers, payers, HINs, health IT developers, and other stakeholders electronic access to data when and where it’s needed to better support patient care. 

Conclusion

Healthcare systems have traveled a challenging path from inaccessible paper health care records exchanged by fax to USCDI meaningful use electronic data exchanged by FHIR. Going forward, Presidential EO 13563 requires agencies to “determine whether any [agency] regulations should be modified, streamlined, expanded or repealed so as to make the agency’s regulatory program more effective or less burdensome in achieving the regulatory objectives.” 

The Cures Act’s focus on trusted exchange is an important step forward to advance an interoperable health system that empowers individuals to use their EHI to the fullest extent, enables providers and communities to deliver smarter, safer and more efficient care, and promotes innovation and competition at all levels.

This history of federal laws, regulations and rulemaking have evolved and built a foundation for simpler, more comprehensive, and more accessible health care information exchange for patients, providers and health insurance organizations. 

The FHIM incorporates many of the US laws and regulations that impact health IT.  As the landscape evolves the FHIM can be updated to reflect the latest requirements that impact health care organizations and health IT vendors both in the US and globally. 

Appendix A – Acronyms

  • API= Application Programming Interface
  • APM= Alternative Payment Models
  • ARCH= API Resource Collection in Health
  • ARRA= American Recovery and Reinvestment Act of 2009 
  • ARCH= API Resource Collection in Health
  • CFR= Code of Federal Regulations
  • EO= Executive Order
  • FHIR®= Fast Healthcare Interoperability Resources (an HL7® standard)
  • Health IT= Health Information Technology
  • HINs= Health Information Networks
  • HITECH= Health Information Technology for Economic and Clinical Health Act
  • IG= Implementation Guide
  • MACRA= Medicare Access & CHIP Reauthorization Act of 2015
  • MIPS= The Merit-based Incentive Payments System
  • MRTC= Minimum Required Terms and Conditions
  • MU= Meaningful Use
  • NPRM= Notice of Proposed Rulemaking
  • QDRA= Quality Reporting Document Architecture
  • QHIN= Qualified Health Information Network
  • QTF= QHIN Technical Framework
  • USCDI= United States Core Data for Interoperability

Appendix B – 2019 NPRM Certification and Standards Requirements

Subpart B – Standards and Implementation Specifications for Health IT

45 CFR 170.205 – Content exchange standards and implementation specifications for exchanging electronic health information

45 CFR 170.213 – United States Core Data for Interoperability (USCDI)

  • The United States Core Data for Interoperability (USCDI), Version 1 (v1) 

45 CFR 170.215 – Application Programming Interface (API) Standards

  • 170.215(a) HL7® Fast Healthcare Interoperability Resources (FHIR®) Release 2.0, Draft Standard for Trial Use (DSTU) Version 1.0.2-7202, October 24, 2015
  • 170.215(b) OpenID Connect Core 1.0 incorporating errata set 1, November 8. 2014
  • 170.215(c)(1) HL7® Fast Healthcare Interoperability Resource Specification (FHIR®) Release 3 Standard for Trial Use (STU), Version 3.0.1, February 21, 2017
  • 170.215 Health Level 7 (HL7®) Version 4.0.0 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, December 27, 2018
  • 170.215(c) Health Level 7(HL7®) Implementation Specification – FHIR Profile: Consent2Share FHIR® Consent Profile Design, December 11, 2017 
  • 170.215(a)(5) SMART Application Launch Framework Implementation Guide Release 1.0.0170.215(a)(3) HL7® FHIR® Foundation, Argonaut Data Query Implementation Guide, Version 1.0.0, December 23, 2016
  • 170.215(a)(4) HL7® FHIR® Foundation, Argonaut Data Query Implementation Guide Server, Version 1.0.2, December 15, 2016 
  • 170.215 OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591), July 2015
  • 170.215(a)(2) API Resource Collection in Health (ARCH) Version 1
  • 170.215(b) OpenID Connect Core 1.0 Incorporating Errata Set 1, November 8. 2014 

45 CFR 170.299 – Incorporation by reference 

  • Standard. HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R1 Companion Guide, Release 1
  • Standard. National Council for Prescription Drug Programs (NCPDP), Script Standard Implementation Guide, Version 2017071
  • Standard. CMS Implementation Guide for Quality Reporting Document Architecture Category I Hospital Quality Reporting Implementation Guide for 2019 
  • Standard. United States Core Data for Interoperability Version 1 (USCDI v1)
  • Standard HL7® Fast Healthcare Interoperability Resources (FHIR)® Draft Standard for Trial Use (DSTU) 2 (v1.0.2-7202)
  • Implementation specifications. API Resource Collection in Health (ARCH) Version 1
  • Implementation specifications – FHIR® profiles. Argonaut Data Query Implementation Guide Version 1.0.0
  • Implementation specifications – FHIR® server conformance. Argonaut Data Query Implementation Guide Server
  • Implementation specification – Application authorization. HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0, including mandatory support for “refresh tokens,” “Standalone Launch,” and “EHR Launch” requirements
  • Application authentication.Standard.OpenID ConnectCore1.0incorporatingerrataset 1
  • Standard. HL7® Fast Healthcare Interoperability Resources (FHIR)® Release 3 Standard for Trial Use (STU) 3 (v3.0.1)
  • Implementation specification – FHIR® consent resources. HL7® Consent2Share FHIR® Consent Profile Design
  • CMS Implementation Guide for Quality Reporting Document Architecture Category I Hospital Quality Reporting Implementation Guide for 2019, May 4, 2018
  • CMS Implementation Guide for Quality Reporting Document Architecture Category III Eligible Clinicians and Eligible Professionals Programs Implementation Guide for 2019, October 8, 2018
  • HL7® CDA Release 2 Implementation Guide: C-CDA Templates for Clinical Notes R1 Companion Guide, Release 1, March 2017
  • HL7® Fast Healthcare Interoperability Resources (FHIR®) Release 2.0, Draft Standard for Trial Use (DSTU) Version 1.0.2-7202, October 24, 2015
  • HL7® Fast Healthcare Interoperability Resource Specification (FHIR®) Release 3 Standard for Trial Use (STU), Version 3.0.1, February 21, 2017
  • HL7®FastHealthcareInteroperabilityResourcesSpecification(FHIR®)Release4,Version4.0.0, December27, 2018
  • HL7®ImplementationSpecification– FHIR®Profile:Consent2ShareFHIRConsentProfileDesign,December11, 2017
  • HL7® CDAR2ImplementationGuide: C-CDASupplementalTemplatesforUnique Device Identification(UDI)forImplantableMedicalDevices
  • HL7® SMARTApplicationLaunchFrameworkImplementationGuideRelease1.0.0,November 13, 2018
  • Argonaut Data Query Implementation Guide. Version 1.0.0, December 23, 2016
  • Argonaut Data Query Implementation Guide Server, Version 1.0.2, December 15, 2016
  • OAuth2.0 DynamicClientRegistrationProtocol(RFC 7591),July2015
  • National Council for Prescription Drug Programs (NCPDP), Script Standard ImplementationGuide,Version2017071 (ApprovalDate for ANSI:July28,2017)
  • ONC United States Core Data for Interoperability (USCDI), Version 1 (v1), February 11, 2019
  • API Resource Collection in Health (ARCH) Version 1, February 1, 2019
  • OpenID Connect Core 1.0 Incorporating Errata Set 1, November 8, 2014

Subpart C – Certification Criteria for Health IT 

45 CFR 170.315 – 2015 Edition Health IT Certification Criteria

  • 170.315(a) Family health history (familial conditions relevant for children)
  • 170.315(a)(5) Demographics Pediatric Care – captures of values and value sets relevant for pediatric health care settings and patient matching
  • 170.315(a)(15) Social, psychological and behavioral data – integration of behavioral health data into child’s record across the care continuum based on Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) and Logical Observation Identifiers Names and Codes (LOINC) codes
  • 170.315(b)(1) Transition of care (USCDI v1.0) – Structured transition of care summaries and referral summaries for children
  • 170.315(b)(2) Clinical Information Reconciliation and Incorporation 
  • 170.315(b)(3) Electronic Prescribing – optional Structured and Codified Sig Format with capability to exchange weight-based dosing calculations within NCPDP SCRIPT 10.6 and limits prescribing all oral, liquid medications in only metric standard units for pediatrics
  • 170.315(b)(9) Care Plan
  • 170.315(b)(10) Electronic Health Information (EHI) Export – export of EHI for a single patient or health care provider transition or migration to another health IT system
  • 170.315(b)(12) DS4P Create Summary Record – HIT tagging DS4P data consent for C-CDA information exchange or FHIR®-based exchange standards 
  • 170.315(b)(13) DS4P Receive Summary Record – HIT receiving DS4P data consent for C-CDA information exchange or FHIR®-based exchange standards
  • 170.315(c1)(1)-(c)(3) Clinical Quality Measures (CQMs)
  • 170.315(d)(12) Encrypt authentication – certification criteria for secure electronic transmission and secure electronic messaging by developers of Health IT modules
  • 170.315(d)(13) Multi-factor authentication – certification criteria for secure electronic transmission and secure electronic messaging by developers of health IT modules
  • 170.315(e)(1) View, download and transmit to 3rdparty (VDT) – transferrable access authority for pediatric health care setting and patients
  • 170.315(e)(3) Patient health information capture – provider ability to accept health information from patient or authorized representative for children 
  • 170.315(f)(1) Transmission to immunization registries – child health care through immunization and health care registries
  • 170.315(g)(6) Consolidated CDA Creation Performance
  • 170.315(g)(7) API Condition of Certification
  • 170.315(g)(8) Application access – Data category request
  • 170.315(g)(9) Application Access – All Data request
  • 170.315(g)(10) Certified API for patient and population services from the FHIR® resources in ARCH Version 1
  • 170.315(g)(10)(i) Data Response
  • 170.315(g)(10)(ii) Search Support
  • 170.315(g)(10)(iii) App Registration proposed (RFC 7591 OAuth Dynamic Client Registration Protocol)
  • 170.315(g)(10)(iv) Secure connection, authentication and authorization
  • 170.315(g)(10)(v)(A) User authentication (OpenID Connect Core 1.10 Errata Set 1)
  • 170.315(g)(10)(v)(B) User authorize applications to access data (SMART Application Launch Framework Implementation Guide Release 1.0.0)
  • 170.315(g)(10)(vi) Authentication and app Authentication and app authorization –Subsequent connections (refresh token for FHIR® server)
  • 170.315(g)(10)(vii) Detail information for certification of FHIR® API
  • 170.315(g)(11) Electronic prescribing
  • 170.315(h) Transport methods and other protocols

Application Programming Interface (API) Conditions of Certification 

45 CFR Part 170.4xx – Conditions and Maintenance of Certification for Health IT Developers

  • 170.401 Information blocking
  • 170.402 Assurances
  • 170.403 Communications
  • 170.404 APIs Transparency Conditions (without special effort), permitted and prohibited fees, non-discrimination
  • 170.405 Real world testing
  • 170.406 Attestations Condition and Maintenance of Certification
  • 170.40x EHR Reporting Program

45 CFR 171.2xx – Information Blocking Exceptions

  • 171.201 Preventing harm
  • 171.202 Promoting the privacy of electronic health information
  • 171.203 Promoting the security of electronic health information
  • 171.204 Recovering costs reasonably incurred
  • 171.205 Responding to requests that are infeasible
  • 171.206 Licensing of interoperability elements on reasonable and non-discriminatory terms
  • 171.207 Maintaining and improving health IT performance by adoption of code sets, terminology and nomenclature as Vocabulary standards for representing electronic health information for interoperability.
  • RxNorm Medication List
  • SNOMED CT®

 

Appendix C: USCDI v1 Summary of Data Classes and Data Elements

Assessment and 
Plan of Treatment

Medications

Smoking Status

  

 
  • Medications
  • MedicationAllergies

 

  

Clinical Notes

Patient Demographics

Unique Device Identifier(s) for a Patient’s Implantable Device(s)*

  
  • Consultation Note*
  • Discharge Summary Note*
  • History &Physical*
  • ImagingNarrative*
  • LaboratoryReport Narrative*
  • Pathology*Report Narrative
  • First Name
  • Last Name
  • Previous Name
  • Middle Name (including middle initial)
  • Suffix
  • Birth Sex
  • Date of Birth
  • Race
  • Ethnicity
  • PreferredLanguage
  • Address*
  • PhoneNumber*

 

  

Vital Signs

  
  • Diastolic Blood Pressure
  • Systolic Blood Pressure
  • Body Height
  • Body Weight
  • Heart Rate
  • BodyTemperature
  • Pulse Oximetry
  • InhaledOxygen Concentration
  • BMI Percentile* per Age and Sex for Youth 2-20
  • Weights for Age* per Length andSex
  • Occipital-Frontal* Circumference for Children < 3 Years Old
  

Goals

Problems

  
  • Patient Goals

 

  

Health Concerns

Procedures

  

 

 

  

Immunizations

Provenance

  

 
  • Author*
  • Author TimeStamp
  • AuthorOrganization
  

Laboratory

  
  • Tests
  • Values/Results
  

* Elements updated or added in the 2019 revised version of U.S. Core Data Interoperability (USCDI) specification.

Appendix D: FHIR® Core Resources

  • AdverseReaction
  • Alert
  • AllergyIntolerance
  • CarePlan
  • Composition
  • ConceptMap
  • Condition
  • Conformance
  • Device
  • DeviceObservationReport
  • DiagnosticOrder
  • DiagnosticReport
  • DocumentReference
  • DocumentManifest
  • Encounter
  • FamilyHistoryGroup
  • ImagingStudy
  • Immunization
  • ImmunizationRecommendation
  • List
  • Location
  • Media
  • Medication
  • MedicationAdministration

 
  • MedicationDispense
  • MedicationPrescription
  • MedicationStatement
  • MessageHeader
  • Observation
  • OperationOutcome
  • Order
  • OrderResponse
  • Organization
  • Other
  • Patient
  • Practitioner
  • Procedure
  • Profile
  • Provenance
  • Query
  • Questionnaire
  • RelatedPerson
  • SecurityEvent
  • Specimen
  • Substance
  • Supply
  • ValueSet

 

 

 

[2]Medicare Access & CHIP Reauthorization Act of 2015, https://www.govinfo.gov/content/pkg/PLAW-114publ10/html/PLAW-114publ10.htm

[3]2015 Edition Health IT Certification Criteria Final Rule, https://www.govinfo.gov/content/pkg/FR-2015-10-16/pdf/2015-25597.pdf

[4]21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program, 45 CFR Parts 170 and 171, https://www.govinfo.gov/content/pkg/FR-2019-03-04/pdf/2019-02224.pdf

[8]Medicare Access & CHIP Reauthorization Act of 2015, https://www.govinfo.gov/content/pkg/PLAW-114publ10/html/PLAW-114publ10.htm

[9]Merit-based Incentive Payments System, page 129 STA. 911, https://www.govinfo.gov/content/pkg/PLAW-114publ10/html/PLAW-114publ10.htm

[10]2015 Edition Health IT Certification Criteria Final Rule, https://www.govinfo.gov/content/pkg/FR-2015-10-16/pdf/2015-25597.pdf

[12]Revised and New 2015 Edition Criteria, B.1, page 7440, https://www.govinfo.gov/content/pkg/FR-2019-03-04/pdf/2019-02224.pdf

[13]HL7®Fast Healthcare Interoperability Resources®, page 7477, https://www.govinfo.gov/content/pkg/FR-2019-03-04/pdf/2019-02224.pdf

[14]21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program, 45 CFR Parts 170 and 171, https://www.govinfo.gov/content/pkg/FR-2019-03-04/pdf/2019-02224.pdf

[16]45 CFR § 170.315(b)(1)

[17]45 CFR § 170.315(e)(1)

[18]45 CFR § 170.315(g)(9) and (10)

[19]Trusted Exchange Framework and Common Agreement Draft 2, https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf