Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

21st Century Cures Act: Interoperabillity, Information Blocking and ONC Health IT Certification Program #1

Closed
JillDeGraff opened this issue Mar 16, 2019 · 34 comments

Comments

@JillDeGraff
Copy link
Owner

@JillDeGraff JillDeGraff commented Mar 16, 2019

This GitHub repository provides high-level and selectively detailed summaries of the ONC's proposed rulemaking, published in the Federal Register on March 4, 2019.

The ONC accepts formal comments from the public on the proposed rules until 5pm on May 3, 2019. If you want to submit comments, go to the Federal eRulemaking Portal and upload your comments in MS Word (preferred), MS Excel or Adobe PDF.

Not all sections of the proposed rule have been summarized. Feel free to contribute! Follow links in the Table of Content structure to pages that have been summarized.

The ONC's presentation to HIMSS about the Proposed Rule and other resources provided by the ONC about the proposed rule is available on HealthIT.gov.

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 16, 2019

Table of Contents

I. Executive Summary

A. Purpose of Regulatory Action

B. Summary of Major Provisions and Clarifications

1. Deregulatory Actions for Previous Rulemakings

2. Updates to the 2015 Edition Certification Criteria

a. Adoption of the U.S. Core Data for Interoperability (USCDI) as a Standard
b. Electronic Prescribing
c. Clinical Quality Measures - Report
d. Electronic Health Information Export
e. Application Programming Interfaces
f. Privacy and Security Transparency Attestations
g. Data Segmentation for Privacy and Consent Management

3. Modifications to the ONC Health IT Certification Program

4. Health IT for the Care Continuum

5. Conditions and Maintenance of Certification

6. Information Blocking

C. Costs and Benefits

II. Background

A. Statutory Basis

1. Standards, Implementation Specifications, and Certification Criteria

2. Health IT Certification Program(s)

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria

2. ONC Health IT Certification Program Rules

III. Deregulatory Actions for Previous Rulemakings

A. Background

1. History of Burden Reduction and Regulatory Flexibility

2. Executive Orders 13771 and 13777

B. Proposed Deregulatory Actions

1. Removal of Randomized Surveillance Requirements

2. Removal of the 2014 Edition from the Code of Federal Regulations

3. Removal of the ONC-Approved Accreditor from the Program

4. Removal of Certain 2015 Edition Certification Criteria and Standards

a. 2015 Edition Base EHR Definition Certification Criteria
b. Drug-Formulary and Preferred Drug Lists
c. Patient-Specific Education Resources
d. Common Clinical Data Set Summary Record - Create; and Common Clinical Data Set Summary Record - Receive
e. Secure Messaging

5. Removal of Certain ONC Health IT Certification Program Requirements

a. Limitations Disclosures
b. Transparency and Mandatory Disclosures Requirements

6. Recognition of Food and Drug Administration Processes

a. FDA Software Pre-Certification Pilot Program
b. Development of Similar Independent Program Processes - Request for Information

IV. Updates to the 2015 Edition Certification Criteria

A. Standards and Implementation Specifications

1. National Technology Transfer and Advancement Act

2. Compliance with Adopterd Standards and Implementation Specifications

3. "Reasonably Available" to Interested Parties

B. Revised and New 2015 Edition Criteria

1. The USCDI

a. USCDI 2015 Edition Certification Criteria
b. USCDI Standard - Data Classes Included
c. USCDI Standard - Relationship to Content Exchange Standards and Implementation Specifications
d. Clinical Notes C-CDA Implementation Specification

2. Electronic Prescribing Criterion

3. Clinical Quality Measures - Report Criterion

4. Electronic Health Information Export Criterion

a. Patient Access
b. Transitions Between Health IT Systems
c. Scope of EHI
d. Export Format
e. Initial Step to Persistent Access to All of a Patient's EHI
f. Timeframes
g. Replaces the 2015 Edition "Data Export" Criterion in the 2015 Edition Base EHR Definition

5. Standardized API for Patient and Population Services Criterion

6. Privacy and Security Transparency Attestations Criteria

a. Background
b. Encrypt Authentication Credentials
c. Multi-Factor Authentication

7. Data Segmentation for Privacy and Consent Management Criteria

a. Implementation with the Consolidated CDA Release 2.1
b. Implementation with FHIR Standard

C. Unchanged 2015 Edition Criteria - Promoting Interoperability Programs Reference Alignment

V. Modification to the ONC Health IT Certification Program

A. Corrections

1. Auditable Events and Tamper Resistance

2. Amendments

3. View, Download and Transmit to 3rd Party

4. Integrating Revised and New Certification Criteria into the 2015 Edition Privacy and Security Certification Framework

B. Principles of Proper Conduct for ONC-ACBs

1. Records Retention

2. Conformance Methods for Certification Criteria

3. ONC-ACBs to Accept Test Results from any ONC-ATL in Good Standing

4. Mandatory Disclosures and Certifications

C. Principles of Proper Conduct for ONC-ATLs-Record Retention

VI. Health IT for the Care Continuum

A. Health IT for Pediatric Setting

1. Background and Stakeholder Convening

2. Recommendations for the Voluntary Certification of Health IT for Use in Pediatric Care

a. 2015 Edition Certification Criteria
b. New or Revised Certification Criteria in This Proposed Rule

B. Health IT and Opioid Use Disorder Prevention and Treatment - Request for Information

1. 2015 Edition Certification Criteria

2. Revised or New 2015 Edition Certification Criteria in This Proposed Rule

3. Emerging Standards and Innovations

4. Additional Comment Areas

VII. Conditions and Maintenance of Certification

A. Implementation

B. Provisions

1. Information Blocking

2. Assurances

a. Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities
b. Certification to the "Electronic Health Information Export" Criterion
c. Records and Information Retention
d. Trusted Exchange Framework and the Common Agreement - RFI

3. Communications

a. Background and Purpose
b. Conditions of Certification Requirements
c. Maintenance of Certification Requirements

4. Application Programming Interfaces

a. Statutory Interpretation and API Policy Principles
b. Key Terms
c. Proposed API Standards, Implementation Specifications and Certification Criterion
i. Proposed Adoption of FHIR Release 2
ii. Proposed Adoption of Associated FHIR Release 2 Implementation Specification
iii. Proposed Adoption of Standards and Implementation Specifications to Support Persistent User Authentication and App Authorization
iv. Proposed Adoption of a New API Certification Criterion in Section 170.315(g)(10)
d. Conditions of Certification Requirements
i. Scope and Compliance
ii. Cures Act Condition and Interpretation of Access to "All Data Elements"
iii. Transparency Conditions
iv. Permitted Fees
v. Openness and Pro-Competition
e. Maintenance of Certification Requirements
f. 2015 Edition Base EHR Definition

5. Real World Testing

6. Attestations

7. EHR Reporting Criteria Submissions

C. Compliance

D. Enforcement

1. ONC Direct Review of the Conditions and Maintenance of Certification

2. Review and Enforcement Only by ONC

3. Review Processes

a. Initiating Review and Health IT Developer Notice
b. Relationship with ONC-ACBs and ONC-ATLs
c. Records Access
d. Corrective Action
e. Certification Ban and Termination
f. Appeal
g. Suspension
h. Proposed Termination

4. Public Listing of Certification Ban and Terminations

5. Effect on Existing Program Requirements and Processes

6. Concurrent Enforcement by the OIG

7. Applicability of Conditions and Maintenance of Certification Requirements for Self-Developers

VIII. Information Blocking

A. Statutory Basis

B. Legislative Background and Policy Considerations

1. Purpose of the Information Blocking Provision

2. Policy Considerations and Approach to the Information Blocking Provisions

C. Relevant Statutory Terms and Provisions

1. "Required by Law"

2. Health Care Providers, Health IT Developers, Exchanges and Networks

a. Health Care Providers
b. Health IT Developers of Certified Health IT
c. Networks and Exchanges

3. Electronic Health Information

4. Interests Promoted by the Information Blocking Provision

a. Access, Exchange and Use of EHI
b. Interoperability Elements

5. Practices that Might Implicate the Information Blocking Provision

a. Prevention, Material Discouragement and Other Interference
b. Likelihood of Interference
c. Examples of Practices Likely To Interfere with Access, Exchange or Use of EHI

6. Applicability of Exceptions

a. Reasonable and Necessary Activities
b. Treatment of Different Types of Actors
c. Establishing That Activities and Practices Meet the Conditions of an Exception

D. Proposed Exceptions to the Information Blocking Provision

1. Preventing Harm

2. Promoting the Privacy of EHI

3. Promoting the Security of EHI

4. Recovering Costs Reasonably Incurred

5. Responding to Requests That Are Infeasible

6. Licensing of Interoperability Elements on Reasonable and Non-Discriminatory Terms

7. Maintaining and Improving Health IT Performance

E. Additional Exceptions - Request for Information

1. Exception for Complying with Common Agreement for Trusted Exchange

2. New Exceptions

F. Complaint Process

G. Disincentives for Health Care Providers - RFI

IX. Registries RFI

**X. Patient Matching RFI

XI. Incorporation by Reference

XII. Response to Comments

XIII. Collection of Information Requirements

A. ONC-ACBs

B. Health IT Developers

XIV. Regulatory Impact Analysis

A. Statement of Need

B. Alternatives Considered

C. Overall Impact

1. Executive Orders 12866 and 13563 - Regulatory Planning and Review Analysis

2. Executive Order 13771 - Reducing Regulation and Controlling Regulatory Costs

a. Costs and Benefits
b. Accounting Statement and Table

3. Regulatory Flexibility Act

4. Executive Order 13132 - Federalism

**5. Unfunded Mandates Reform Act of 1995

6. Executive Order 13771 Reducing Regulation and Controlling Regulatory Costs

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 16, 2019

I. Executive Summary

A. Purpose of Regulatory Action

  1. Advance interoperability
  2. Support access, exchange and use of EHI
  3. Address occurrences of information blocking
  4. Implement provisions of Cures Act related to:
    a. Conditions and Maintenance of Certification for health IT developers
    b. Voluntary certification of HIT for use by pediatric health providers
    c. Reasonable and necessary activities that do not constitute information blocking
  5. Implement other provisions of Cures Act related to:
    a. Supporting patient access to their EHI, like making it more electronically accessible through adoption of standards and certification criteria and the implementation of information blocking policies that support patient electronic access to their health info at no cost
  6. Modify 2015 Edition HIT certification criteria and ONC HIT Certification Program to advance interoperability and reduce burden and costs

B. Summary of Major Provisions and Clarifications

1. Deregulatory Actions for Previous Rulemakings

Proposes 6 deregulatory actions to reduce burden for health IT developers, providers and other stakeholders, outlined in Section III.B

  • Remove threshold requirements for randomized surveillance, to give ONC Authorized Certification Bodies (ONC-ACBs) more flexibility in selecting right approach
  • Remove 2014 Edition from CFR
  • Remove ONC Approved Accreditor (ONC-AA) from Program
  • Remove certain 2015 Edition Certification Criteria
  • Remove certain Program requirements
  • Recognize relevant FDA certification processes

2. Updates to the 2015 Edition Certification Criteria

Proposes emphasis on capabilities with related standards and implementation specs to fulfill purposes of proposed regulation

a. Adoption of United States Core Data for Interoperability (USCDI) as a Standard
  • Replace Common Clinical Data Set (CCDS) with USCDI
  • Names USCDI v1 in 45 C.F.R. Section 170.299 as a standard
  • USCDI names a set of data classes and constituent data elements required to be exchanged
  • Establishes predictable, transparent and collaborative process for expanding the USCDI over time
  • Health IT will be able to voluntarily implement new versions of the USCDI as they are approved by the ONC, following the "Standards Version Advancement Process" under the Maintenance of Certification real world testing requirements
b. Electronic Prescribing
  • Update e-Rx SCRIPT standard in 45 CFR Section 170.205(b) to NCPDP SCRIPT 2017017
  • Add new certification criterion in Section 170.315(b)(11) for e-Rx to reflect new standard and align with CMS' recently finalized Part D standards to NCPDP SCRIPT 2017017, effective 1/1/20
  • Require all NCPDP SCRIPT 2017017 standard transactions, also to align with CMS rule
c. Clinical Quality Measures - Report
  • Require "Health IT Modules" to support the CMS QRDA Implementation Guide, and remove the HL7 QRDA as a reporting standard
d. EHI Export
  • Would replace the "data export" criterion at 170.315(b)(6) with a new "EHI export" criterion at 170.315(b)(10), which would require all EHI produced and electronically managed by a developer's health IT to be readily available for export as a standard capability of certified HIT.
  • The export would not need to follow a specific data format, structure or syntax, to facilitate interpretation of the exported EHI, but developers would need to provide documentation about data format, structure and syntax
  • The EHI Export Criterion is intended to facilitate the export all of a single patient's EHI in one-off transacitons and all patients' EHI, for example, to facilitate EHI migration to another HIT system
e. API
  • Would replace the "application access- data category request" criterion at 170.315(g)(8) with a new "API" criterion at 170.315(g)(10), and make the API criterion part of the 2015 Edition Base EHR definition
  • The new API criterion would require use of HL7 FHIR standards and several implementation specifications
  • The new criterion would focus first on two types of API-enabled services
    • services for which a single patient's data is the focus
    • services for which multiple patients' data are the focus
f. Privacy and Security Transparency Attestations
  • Would require HIT developers to answer in their attestations whether or not their certified HIT supports (1) encryption of authentication credentials and (2) MFA
  • Goal is to motivate HIT developers to incorporate these practices into their technologies
g. Data Segmentation for Privacy and Consent Management (DS4P)
  • Would replace the optional "DS4P-create" and "DS4P-receive" certification criteria, which only focus on document-level segmentation, with 3 new optional DS4P certification criteria to support a more granular approach to privacy tagging data consent management, by either C-CDA or FHIR-based exchange standards. By proposing these consent management certification criteria, the ONC seeks to encourage HIT developers to further mature the industry's capabilities to effectively manage patient consent and privacy law directives while facilitating data interoperability.

3. Modifications to the ONC Health IT Certification Program (Program)

  • Corrected the 2015 Edition privacy and security certification framework in 80 FR 62705 and relevant provisions. See Certification Companion Guides
  • New and revised principles of proper conduct (PoPC) for ONC-ACBs
  • Would require ONC-ACBs to accept test results from any ONC-ATL in good standing
  • Would also update Section 170.523(k) to broaden the requirements beyond just the Medicare and Medicaid EHR Incentive Programs

4. Health IT for the Care Continuum

  • Seeks comment on ONC's identified 2015 Edition criteria that could benefit providers of pediatric care and pediatric settings
  • Seeks comment on how the Program could support use cases related to Opioid Use Disorder prevention and treatment, and if there are additional areas that ONC should consider for effective implementation of HIT to help address OUD prevention and treatment

5. Conditions and Maintenance of Certification

  • Proposes initial Conditions of Participation and ongoing Maintenance of Certification requirements, in Subpart D, starting at Section 170.400, to implement Section 4002 of the Cures Act
  • Would apply to all Health IT developers and their certified Health IT Modules
  • Content Areas
    • Information Blocking. Health IT developers would be required not to take any action that constitutes information blocking, as defined in PHSA Section 3022(a) and proposed in Section 171.103
    • Assurances. Health IT developers would be required to provide more detailed assurances that they will not take actions that constitute information blocking
    • Communications. Health IT developers would be prohibited from restricting communications about the performance of their health IT and related business practices; for example, they would not be able to impose or enforce contractual requirements that contravene the Conditions of Certification. Existing contracts would have to be voided or amended before the 2nd anniversary of the effective date of the final rule.
    • APIs. API Conditions and Maintenance of Certification are described more fully in Section VII.B.4.
    • Real World Testing. Would require all health IT developers with Health IT Modules certified to one or more of the 2015 Edition certification criteria to perform annual testing of the real world use of interoperability technology in the type of setting in which the technology would be marketed. Under the Conditions of Certification and Maintenance of Certification, these developers would need to submit annual test plans and annual test results of their real world testing. They would also have the option to update their health IT to more advanced versions of the standards included in the 2015 Edition certification criteria, if the advanced versions have been approved by the ONC (The Standards Version Advancement Process). Under related updates to the PoPC for ONC-ACBs, ONC-ACBs would be required to review and confirm the test plans and test results, and upload the plans and results to the ONC's Certified Health IT Product List (CHPL). Updates would be collected quarterly.
    • Attestations. Health IT developers would attest 2x a year to compliance with the Conditions and Maintenance of Certification requirements. Attestations would be submitted to ONC-ACBs, who would then be required to review and submit the attestations to the ONC. The attestations would also be made available publicly through the CHPL.
    • EHR Reporting Criteria Submission. Cures Act requires ONC to create a reporting program, but will do so in a later rulemaking.
    • Enforcement. Proposes a new enforcement approach, to encourage compliance with the Conditions and Maintenance of Certification Requirements. The approach would use a corrective action process for ONC to review potential or known instances of noncompliance, similar to existing processes fort ONC direct review of certified health IT (see 170.580 and 170.581). While first priority would be to work with the health IT developer to remedy the matter through corrective action, ONC proposes to back up the process with authority to ban a health IT developer from the Program or terminate certification of a noncompliant Health IT Module.

6. Information Blocking

  • Proposes 7 reasonable and necessary activities that would not constitute information blocking under Section 4004 of the Cures Act (codified at Section 3022 of the PHSA), even if they interfere with the access, exchange or use of EHI.
    1. protect patient safety
    2. promote privacy of EHI
    3. promote security of EHI
    4. allow for recovery of costs reasonably [incurred]
    5. excuse an actor from responding to requests that are infeasible
    6. permit licensing of interoperability technology on reasonable and non-discriminatory terms
    7. reasonable and necessary to promote the performance of health IT
      - The 7 activities are described more fully in [Section VIII.D.] and are characterized as exceptions to the information blocking definition
      - Criteria used to select these exceptions
    8. To promote public confidence in health IT infrastructure, protect patient safety and/or promote competition or innovation in health IT and its use to provide health care services to consumers.
    9. Mitigate a significant risk that the "reasonable and necessary activities" would not be engaged in, out of concern that these activities constitute information blocking.
    10. Can be tailored through appropriate conditions, so that they are limited to the reasonable and necessary activities that they are designed to exempt.

C. Costs and Benefits

  • ONC prepared a regulatory impact analysis because the OMB determined that the proposed rule would have economically significant effects ($100M+ in any one year)
  • Under the RIA, ONC provides cost and benefit estimates
    • Year 1 total annual cost. Estimates range from $365M to $919M with an average annual cost of $642M
    • Year 2 and beyond total annual cost. Estimates range from $228M to $452M, with an average perpetual annual cost of $340M.
    • Total annual benefit. Estimates range from $3.08B to $9.15B, with an average annual benefit of $6.1B.
    • Total net benefit, Year 1. Estimates range from $2.7B to $8.2B, with average net benefit of $5.5B
    • Total net benefit, Year 2 and beyond. Estimates range from $2.9B to 5.8B, with an average net benefit of $5.8B

Return to Table of Contents

Repository owner deleted a comment from github-learning-lab bot Mar 16, 2019
Repository owner deleted a comment from github-learning-lab bot Mar 16, 2019
@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 16, 2019

4. Removal of Certain 2015 Edition Certification Criteria and Standards

ONC proposes removal of certain 2015 Edition Certification Criteria and Standards to reduce burden and costs for HIT developers and health care providers. They would be removed upon the effective date of any final rule. ONC welcomes comment on the items proposed for removal, and recommendations for any other criteria or standards that it should consider for removal.

Justifications given for removing these certification criteria are summarized below:

  1. Usually were part of Meaningful Use 1, and no longer support an objective and measure of the CMS Medicare and Medicaid EHR Incentive Program, which is now the Promoting Interoperability Program
  2. The functionality is sufficiently widespread, and unlikely to be removed from health IT systems
  3. The functionality does not directly support interoperability
  4. In some cases, the functionality underlying the certification criterion proposed for removal is picked up elsewhere in the proposed updates to the 2015 Edition certification criteria
a. 2015 Edition Base EHR Definition Criteria

i. Remove the "problem list" certification criterion from Section 170.315(a)(6)
ii. Remove the "medication list" certification criterion from Section 170.315(a)(7). To be replaced by RxNorm as part of the USCDI.
iii. Remove the "medication allergy list" certification criterion from Section 170.315(a)(8). To be replaced by RxNorm as part of the USCDI.
iv. Remove the "smoking status" certification criterion from Section 170.315(a)(11). To be addressed in the USCDI.
v. Remove the specific USCDI "smoking status" code sets, in favor of a more general representation of smoking status, in Section 170.207(h)

b. Drug Formulary and Preferred Drug Lists

Remove the "drug formulary and preferred drug list checks" because it does not require any standards that facilitate interoperability.

c. Patient-Specific Education Resources

Remove the "patient-specific education resources" certification criterion from Section 170.315(a)(13) because of advancements in the use of automation and algorithms to provide appropriate educational material to patients in a timely manner. Removal will reduce unnecessary burden in the certification process.

d. CCDS Summary Record--Create; and CCDS Summary Record--Receive

Remove these certification criteria from Section 170.315(b)(4) and 170.315(b)(5), respectively because of apparently limited market demand for them to be certified.

e. Secure Messaging

Remove "secure messaging" certfication criterion from Section 170.315((e)(2) because of multiple alternative criteria that support patient engagement and widespread integration of this capability. Also, removal will not negatively impact HIT interoperability.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 16, 2019

6. Recognition of FDA Processes

Background. FDASIA required the FDA, in consultation with the ONC and FCC, to develop a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to HIT, including mobile medical apps. The FDASIA Health IT Report was delivered in April 2014. In it, the FDA recommended a single process for HIT developers/manufacturers to follow to satisfy the requirements of all agencies, and to leverage existing processes, systems and standards for patient safety in health IT. The voluntary Software Precertification (Pre-Cert) Pilot Program is implementing these recommendations.

The FDA Precert Program is notable for its orientation away from premarket reviews of specific products, in favor of a streamlined approval for mobile medical apps developed by organizations that receive organization-level certification based upon demonstrated commitments to a culture of quality, patient safety and organizational excellence.

a. FDA Software Pre-Certification Pilot Program.

ONC proposes that health IT developers holding a precertification under the FDA Pre-Cert Program could qualify for, and benefit from, certain efficiencies under the Program. For example, HIT developers holding a precertification under the FDA Software Pre-Cert Program could be exempt from testing and certification of its HIT to the 2015 Edition:

  • "quality management systems" criterion at Section 170.315(g)(4) and
  • "safety-enhanced design" criterion at Section 170.315(g)(3).
    Also, depending upon the final framework of the FDA Pre-Cert Program, exemptions might be available for the 2015 Edition:
  • "computerized provider order entry" criteria at Section 170.315(a)(1)(, (2) and (3),
  • "drug-drug, drug-allergy interaction checks for CPOE" criteria at Section 170.315(a)(4),
  • "clinical decision support" criteria at Section 170.315(a)(9), and
  • "implantable device list" criteria at Section 170.315(a)(14).

The ONC requests comments, as it believes some stakeholders might not agree that "recognition" of the FDA PreCert Program is the right approach.

b. Development of Similar Independent Prtogram Processes - RFI

Influenced by the FDA PreCert framework, the ONC invites comment on whether it should develop similar processes to those established for the FDA Precertification Program, by providing a pathway for some HIT developers who can meet demonstrated capabilities of excellence to have their products and services precertified, as an alternative to the current Program, which focuses on specific HIT being presented for certification.

Return to Table of Contents

Repository owner deleted a comment from github-learning-lab bot Mar 16, 2019
Repository owner deleted a comment from github-learning-lab bot Mar 16, 2019
Repository owner deleted a comment from github-learning-lab bot Mar 16, 2019
@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 16, 2019

IV. Updates to the 2015 Edition Certification Criteria

The proposed criteria are oriented around enhancing interoperability and improving access to patient records, with an emphasis on using technical standards developed or adopted by voluntary consensus standard bodies, where practical. Preference is to avoid government-unique standard, or other standards, unless required to deliver favorable economic and/or technical outcomes

A. Standards and Implementation Specifications

ONC proposes to use voluntary consensus standards, except in four instances:

  1. The USCDI, a government-unique standard, proposed for adoption at Section 170.213
  2. The API Resource Collection in Health (ARCH) v.1 implementation specification, proposed for adoption in Section 170.215(a)(2). These are a government-unique subset of HL7's FHIR standard, defined for the proposed API certification criterion and API Conditions and Maintenance of Certification
  3. The API standards proposed for adoption at Section 170.215(a)(3) through (5).
  4. Standards proposed in Section 170.205(h)(3) and (k)(3) to replace the current HL7 QRDA standards and designed to support the reporing of eCQM data to CMS

B. Revised and New 2015 Edition Criteria

1. The USCDI

The USCDI replaces the "Common Clinical Data Set (CCDS)" throughout the 2015 Edition. More detail in Section IV.B.1.b of the proposed rule for the USCDI's overall structure and organization.

According to the ONC, the CCDS placed a semantic constraint on the types of data classes that were being considered for interoperable exchange. USCDI re-orients the focus on data classes and data elements that should be included some of which might not be part of a CCDS.

The ONC will follow a predictable, transparent and collaborative process to expand the USCDI. After v1 is adopted, Health IT developers would be allowed to voluntarily implement and use a new version of an adopted USCDI, by following the ONC's proposed "Standards Version Advancement Process", describved in Section VII.B.5 of the proposed rule.

a. USCDI 2015 Edition Certification Criteria

Standard= USCDI v1, found in proposed Section 170.213. Once adopted, health IT developers would be required to update their certified health IT support USCDI v.1. To maintain certification, HIT developers with health IT certified to any of the following certification criteria would need to plan for real world testing, and provide updated certified HIT to their cusotmers within 24 mo after effective date for the final rule:

 1.  "transitions of care" certification criteria (Section 170.315(b)(1)
 2.  "view, download and transmit to 3rd party" certification criteria (Section 170.315(e)(1)) 
 3.  "consolidated CDA creation performance" certification criteria (Section 170.315(g)(6))
 4. "transmissions to public health agencies - electronic case reporting" certification criteria (Section 170.315(f)(5))
 5.  "application access- all data request" certification criteria (Section 170.315(g)(9)).
b. USCDI Standard - Data Classes Included

The overall structure and organization of the USCDI standard is found at here. The ONC adopted only a modest expansion to reduce burdens of a rapidly expanding set of data classes and data elements beyond the CCDS. The delta between the CCDS and USCDI v1 is discussed below.

i. Updated versions of vocabulary standard code sets

Baseline would equal the newest versions of the minimum standard code sets included in the CCDS available at publication of the final rule.

ii. Address and Phone Number

USCDI v1 includes data elements for address and phone number, to improve comprehensiveness of health information for patient care. Would also be consistent with the list of patient matching data elements specified in the 2015 Edition "transitions of care" certification criterion (Section 170.315(b)(1)(iii)(G), which supports exchange of patient data between providers of patient care).

iii. Pediatric Vital Signs

USCDI v1 would make pediatric vital sign data elements mandatory (e.g. occipital frontal circumference for children less than 3 YO, BMI percentile per age and sec for youth 2-20 YO, weight for age per length and sex for children < 3 yO and reference range/scale or growth curve.) Currently, they are optional in the 2015 Edition CCDS definition.

iv. Clinical Notes

USCDI v1 would add a new data class, titled "clinical notes", consisting of structured and unstructured data elements. The free text portion is most highly sought among clinicians because it includes assessment, diagnosis, plan of care and evaluation of plan, patient teaching and other relevant data points. As a standard, ONC proposes 8 note types, identified by Argonaut Project participants, as a minimum bar:

  1. Discharge Summary Note
  2. History & Physical
  3. Progress Note
  4. Consultation Note
  5. Imaging Narrative
  6. Laboratory Report Narrative
  7. Pathology Report Narrative and
  8. Procedure Note
v. Provenance

Provenance (author, author's time stamp and author's organization) was identified by stakeholders as valuable context for understanding when and who created data. Especially important as interoperability achieved through APIs, when a full C-CDA is no longer transmitted, but instead the pertinent data from a record is transmitted. Thus, each item of data needs provenance.

vi. Unique Device Identifier(s) (UDI) for a Patient's Implantable Device(s)

ONC requests comment on a recently published implementation guide within HL7 that provides further guidance on the UDI, specifically around real world testing and costs (for the regulatory impact analysis).

vii. Medication Data Request for Comment

ONC requests comment on removing the Medication Allergies data element, and creating a new data class titled "Substance Reactions," which would be meant to be inclusive of "Medication Allergies".

c. USCDI Standard - Relationship to Content Exchange Standards and Implementation Specifications

USCDI, defined at proposed Section 170.213, establishes data policy, and does not directly associate with any content exchange standards selected by ONC in the proposed rule. ONC believes that all data classes in the USCDI v.1 can be supported by commonly used content exchange standards, like HL7 C-CDA Release 2.1 and FHIR.

d. Clinical Notes C-CDA Implementation Specification

ONC proposes to adopt the HL7 CDA(r) R2 IG: C-CDA Templates for Clinical Notes R1 Companion Guide, Release 1 in Section 170.205(a)(4)(i) to provide further clarity on context exchange standards, like C-CDA Release 2.1, which is part of 2015 Edition certification criteria at 170.205(a)(4). An example of how the Companion Guide provides more detailed specifications is that it specifies clinical notes to be recorded under "note activity" and the location and value set of data elements like race and ethnicity, which are required data elements in the USCDI. The C-CDA Release 2.1 alone provides some optionality or lacks specificity, which the Companion Guide may address. The Companion Guide and C-CDA Release 2.1 concern 6 certification criteria

  • "transitions of care" (Section 170.315(b)(1))
  • "clinical information reconciliation and incorporation" (Section 170.315(b)(2))
  • "care plan" (Section 170.315(b)(9))
  • "view, download and transmit to 3rd party" (Section 170.315(e)(1))
  • "consolidated CDA creation performance" (Section 170.315(g)(6))
  • "application access-all data request" (Section 170.315(g)(9))

Note that real world testing of interoperability on these criteria would have to be completed within 24 months after the final rule is effective.

2. E Prescribing Standard and Certification Criterion

Proposes a new e-prescribing standard, in line with the NCPDP SCRIPT 2017071 standard that CMS has adopted for its CMS Medicare Part D standards. See 84 Fed Reg 7424, starting at page 7444

3. Clinical Quality Measures - Report Criterion

Would remove the HL7 Quality Reporting Document Architecture standard requirement from the 2015 edition CQMs, and in its stead require that health IT certified to the CQM criteria support the latest annual CMS QRDA IGs (for hospitals and eligible professionals), whenever a final rule is published. Over time, ONC expects FHIR APIs may be utilized for CQM reporting, and solicits comment on the future possibility of FHIR-enabled APIs replacing or complementing the CMS QRDA reports.

4. EHI Export

ONC proposes a new 2015 Edition certification criterion for EHI export, in Section 170.315(b)(10), as a means to provide patients and health IT users with a means to efficiently export the entire EHR for a single patient or all patients in a computable, electronic format, and facilitate the receiving health IT system's interpretation and use of the EHI. The new certification criterion would complement other provisions that support patient access to their EHI, all of which the ONC expects will eventually be accessible via APIs.

By providing a baseline capability for exporting EHI in a commercially reasonable format, the new certification criterion would help remediate past practices in which HIT developers could effectively block the export and portability of data for use in competing systems or applications, or charge rents for access to the basic technical information needed to facilitate the conversion or migration of data to competing health IT systems.

ONC does not propose a specific standard for implementing this certification criterion.

a. Patient Access

A user must be able to timely execute the single patient EHI export at any time the user chooses and without subsequent developer assistance to operate. For example, a health IT developer should not:

  • require the user to make a request multiple times for different types of EHI
  • provide unreasonable delays for the export
  • prohibit reasonable user access to the system during the export provess

By "timely", ONC does not mean real-time; however, the export should not be longer than reasonably necessary to avoid interference with other clinical functions of the health IT system. According to the ONC, delays that cause or contribute to users being presented with data files that no longer contain current, accurate or valid data would not conform with the certification criteria.

By "user", ONC refers to a health care professional or his or her office staff, or a software program or service that interacts directly with the certified HIT. The certification criterion does not address access directly by a patient, but ONC requests comment on whether the criterion should be more prescriptive, by only allowing the patient and his/her authorized representative to be the requestor of their EHI, similar to how ONC has previously scoped the "view, download and transmit to 3rd parties" certification criterion at Section 170.315(e)(1).

b. Transitions between Health IT Systems

A HIT developer of HIT certified to the proposed new EHI Export certification criteria would be required, at a customer's request, to provide a complete export of all EHI that is produced or managed by means of that HIT. The certification criterion focuses on the technical outcome, and gives flexibility to HIT developers to decide how to achieve the outcome, as long as it is achieved in a timely and efficient manner and in a format that is commercially reasonable. ONC notes that under Section 170.402, health IT are required to provide assurances that they will provide reasonable cooperation and assistance to other persons (including customers, users, and third party developers) to enable the use of interoperable products and services. See Section VII.B.2. of the Proposed Rule

c. Scope of EHI

EHI export would encompass all EHI that the health IT system produces and electronically manages for a patient or group of patients, including clinical, administrative and claims/billing data. It would also include any data stored in separate data warehouses that the system has access to, can produce and electronically manages. ONC's use of EHI is intentionally broad. "We clarify that 'EHI' also includes the oldest EHI available on that patient to the most recent, no matter the specific electronic format."

ONC also notes that it would encompass imaging information. With regard to imaging, however, ONC understands that "EHRs may not be the standard storage location for images". For this reason, it solicits comment on the feasibility, practicality and necessity of exporting images and/or imaging information. It also requests comment on image elements that should be included (e.g. image quality, type and narrative text.) and on how the ONC should address use cases where it is infeasible or impractical to transfer all possible data elements. As an example, the ONC suggests that HIT developers attest or publish as apart of their export format documentation the types of EHI that they cannot support for export.

Some types of metadata would not be required for export (e.g. internal database table names)

d. Export Format

ONC proposes that health IT developers make their export formats (data dictionary or export support file) publicly available via hyperlink as part of certification to the EHI export criterion, and keeping the hyperlink up-to-date with current export format. This requirement would be consistent with the proposed rules against information blocking.

e. Initial Step to Persistent Access to All of a Patient's EHI

The "export EHI" certification criterion does not require persistent and continuous access to EHI. It is only intended to support discrete data export capability. However, the ONC regards it as a necessary step towards persistent and continuous access. In its discussion, the ONC encourages health IT developers to consider persistent and real-time approaches as part of the step-wise progression we see towards open, standards-based APIs for a growing number of data elements per the USCDI in the proposed "standardized API for patient and population services" criterion.

f. Timeframes

The ONC seeks input on EHI export and timeframes. In particular, beyond exporting all the EHI the health IT system produces and electronically manages, should it include capabilities to permit health carte providers to set timeframes for EHI export, such as only the past two years or past month of EHI?

g. Replaces the 2015 Edition "data export" Criterion in the 2015 Edition Base EHR Definition

The new "export EHI" would be included in the Base EHR definition, which means that all health care providers participating in the CMS Promoting Interoperability Program (formerly the Medicare and Medicaid EHR Incentive Program) would need this capability in their CEHRTs. It would vastly expand data export certification requirements, since the current "data export" criterion is limited to clinical data specified in the C-CDA. The effective data for including the export EHI certification criterion in the Base EHR definition would be 24 months from the effective data of the final rule.

5. Standardized API for Patient and Population Services Criterion

ONC would replace the "application access-data category request" certification criterion with a new "standardized API for patient and population services" criterion in Section 170.315(g)(10), and include this criterion in the 2015 Edition Base EHR definition. Consequently, all CEHRTs would need to support this functionality. See Application Programming Interfaces

6. Privacy and Security Transparency Attestations

The 2015 Edition includes a privacy and security certification framework, at Section 170.550(h), that applies to all Health IT Modules presented for certification. The ONC proposes the addition of two questions that HIT developers would answer regarding these Health IT Modules.

In the first question, HIT vendors would attest whether or not their technologies encrypt all authentication credentials. If HIT vendors affirmatively attest to this criterion, the proposed attestation would tie to FIPS 140-2 cryptography requirements, which the ONC commentary regards as the “seminal, comprehensive and most appropriate standard”.

In the 2nd question, HIT vendors would attest whether or not their technologies use multi-factor authentication. The attestation would also address whether their MFA implementation, where applicable, conforms with industry recognized standards like NIST SP 800-63B Digital Authentication or ISO 27001. In commentary accompanying the proposed rule points to the Healthcare Industry Task Force on Cybersecurity’s recommendation that the industry adopt NIST SP 800-46 guidelines in services where any personal data can be remotely accessed.

7. Data Segmentation for Privacy and Consent Management Criteria

The ONC proposes to remove from the 2015 Edition Certification Criteria two “data segmentation for privacy” (DS4P) certification criteria for summary care records (C-CDAs), and replace them with three new DS4P certification criteria. The criteria concern the implementation of security labels that facilitate the exchange of data in accordance with privacy policies that originate from patients, the law or an organization. The existing DS4P certification criteria only required the use of security labels at the document-level. Based on feedback, the ONC states that document-level security labels don't give providers sufficient flexibility to address more granular segmentation needs, especially in pediatric care and behavioral health care. To address these limitations, he new DS4P certification criteria would support document-, section- and entry-level segmentation and consent management in the exchange of C-CDAs and through FHIR servers

As with the current DS4P certification criteria, the ONC would not include the proposed DS4P certification criteria in the 2015 Edition Base EHR definition. Instead, they are being proposed to put DS4P capabilities on a glide path that would eventually help automate existing manual redaction workflows.

a. Implementation with the C-CDA Release 2.1

The DS4P certification criteria proposed for Section 170.315(b)(12) and (13) would apply to C-CDAs and be based on the HL7 DS4P standard.

b. Implementation with the FHIR Standard

The DS4P certification criteria proposed for Section 170.315(g)(11) would support data segmentation and consent management in APIs by following Consent2Share. Consent2Share is an open source application for data segmentation and consent management that ONC created with the Substance Abuse and Mental Health Services Administration (SAMHSA). The ONC encourages developers to participate in the Consent2Share community to expand support of data segmentation for health care providers engaged in complex use cases, including thosed involved in pediatric care, behavioral health care, HIV/AIDS, alcohol, tobacco, sexuality and reproductive health, and opioid use disorder.

C. Unchanged 2015 Edition Criteria - Program Reference Alignment

Throughout the 2015 Edition Criteria, the ONC has removed references to the Medicare and Medicaid EHR Incentive Programs, and replaced them with references to the Medicare and Medicaid Promoting Interoperability Program, to align with the name change invoked by the CMS, and reflect the shift in policy priorities from meaningful use of EHR to interoperability and improving patient access.

Return to Table of Contents

Repository owner deleted a comment from github-learning-lab bot Mar 16, 2019
@JillDeGraff JillDeGraff transferred this issue from JillDeGraff/markdown-portfolio Mar 17, 2019
@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

Application Programming Interfaces

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

V. Modifications to the ONC Health IT Certification Program

(note: not all sections have been summarized. Contributions are welcomed.)

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

A. Corrections

(note: not all corrections under V. Modifications to the ONC Health IT Certification Program have been summarized. Contributions are welcomed.)

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

4. Integrating Revised and New Certification Criteria into the 2015 Edition Privacy and Security Certification Framework

Consistent with the 2015 Edition privacy and security certification framework, each certification criterion has a set of appropriate P&S "safeguards" that must be in place. In the 2015 Edition, ONC required that an ONC-ACB ensure that a Health IT Module presented for certification to any of the certification criteria that fall into each regulatory text "first level paragraph" cateory of Section 170.315(e.g. 170.315(a)) would be certified to either Approach 1 (technically demonstrate) or Approach 2 (system documentation).

In this proposed rule, ONC would require the new criteria (Section 170.315(d)(12) and (13) to apply to all Section 170.315 certification criteria. ONC notes that the P&S Framework will likely need further updating, if proposals for removing certain certification criteria are finalized.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

VII. Conditions and Maintenance of Certification

Section 4002 of the Cures Act requires the Secretary of HHS, through notice and comment rulemaking, to establish Conditions and Maintenance of Certification requirements for the Program. Specifically, health IT developers or entities must adhere to certain Conditions and Maintenance of Certification requirements concerning information blocking; appropriate exchange, access and use of EHI; communications regarding HIT; APIs; real world testing for interoperability; attestations regarding Conditions and Maintenance of Certification requirements; and submission of reporting criteria under the EHR reporting program.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

A. Implementation

The Conditions of Certification express initial requirements for HIT developers and their certified Health IT Modules. The Maintenance of Certification express continuing requirements that must be met by HIT developers and their certified Health IT Modules under the program. "Health IT Module" is defined in 45 C.F.R. 170.102 as "any service, component, or combination thereof that can meet the requirements of at least one certification criterion adopted by the Secretary."

The Maintenance of Certification requirements are aligned with their related Conditions of Certification, but represent standalone requirements. Procedurally, this approach creates a clear baseline with an expectation that evidence will be collected to demonstrate that the Conditions of Certification are continually being met. Noncompliance triggers the ONC's corrective action process, which could ultimately lead to termination from the program.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

1. Information Blocking

Section 4004 of the Cures Act creates a new Section 3022(a) of the PHSA, which requires that developers of technologies certified under the ONC's voluntary health IT certification program, health care providers, health information exchanges and health information networks not take any action that constitutes "information blocking". Congress also directed the ONC, through notice and comment rulemaking, to define reasonable and necessary practices that would not constitute information blocking, which the ONC does in a new Section 171.103.

ONC implements this Congressional mandate with significant definitions for information blocking, electronic health information and other key terms. It also defines seven exceptions when information blocking would be permitted, if detailed requirements are satisfied.

Prohibitions on information blocking would be enforced through new statutory and regulatory authorities. First, the Cures Act grants the HHS office of the inspector general authority to investigate information blocking claims, backed by additional authority to impose civil money penalties (on developers, networks and exchanges) and the potential for programmatic disincentives. Second, under the ONC proposed rule, the ONC proposes to exercise its authority to terminate certifications under its voluntary HIT certification program if a health IT developer is found to engage in information blocking, even if the activity does not concern certified health IT. Third, under the CMS proposed rule on data interoperability and patient access, CMS would require eligible professionals in the Quality Performance Program to make an annual attestation that they have not knowingly or willfully engaged in information blocking. These attestations would be reported in Physicians Compare.

If implemented as proposed, how would business practices and contracts change for health IT developers, health care providers, developers that seek access to electronic health information for their services, health information networks and health information exchanges?

  • to promote the privacy of EHI

  • to promote the security of EHI

  • to recover costs reasonably incurred to provide access, exchange or use of EHI

  • in response to requests for EHI that are infeasible

  • in connection with licensing interoperability elements on reasonable and non-discriminatory terms

  • to maintain and improve health IT performance.

Elsewhere in the proposed rule, the ONC includes

this requirement at Section 170.401, and defines "information blocking" in a The ONC's approach in defining information blocking has two parts. First, it would establish a broad definition of business practices that constitute impermissible information blocking, with clarification that disclosures required band then

Developers of technologies certified under the ONC's voluntary health IT certification program are not the only entities subject to the information blocking provisions of the Cures Act, and the implementing regulations proposed by ONC. Part 171 would also apply to health care providers, health information exchanges and health information networks, and provides new defined terms for HIEs and HINs. In the related CMS proposal on data interoperability and patient access, CMS would update the Physician Compare website to include information from an updated attestation that health care providers would make, stating that they have not knowingly or willfully engaged in information blocking activities. See 84 Fed Reg 7610, 7645 (March 4, 2019)

Part 171 contains a range of definitions to

To enforce provisions against information blocking, the ONC would exercise its authority with regard to the Certification Program. As well, it notes that the HHS OIG has investigatory and enforcement authority over information blocking, including authority to impose CMPs for information blocking conducted by health IT developers of certified HIT, HINs and HIEs. OIG can also investigate health care providers for information blocking for which health care providers could be subject to disincentives.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

Section 171.103. Information Blocking

Under Part 171 of the ONC's Proposed Interoperability Rule, Information blocking would mean a practice that--

  1. Except as required by law or covered by an exception set forth in subpart B of this part, is likely to interfere with, prevent, or materially discourage access, exchange or use of EHI; and

  2. If conducted by a HIT developer, HIE, or HIN, such developer, exchange or network knows, or should know, that such practice is likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI; or

  3. If conducted by a health care provider, such provider knows that such practice is unreasonable and is likely to interferewith, prevent, or materially discourage access, exchange or use of EHI.

Section 171.200. Exceptions for Reasonable and Necessary Activities That Do Not Constitute Information Blocking

ONC then proposes seven (7) permissible exceptions for activities that that would not constitute information blocking, even if they interfere with the access, exchange or use of EHI. Broadly, these exceptions address activities that —

A. prevent harm
B. promote privacy of EHI
C. promote security of EHI
D. allow for recovery of costs reasonably incurred
E. excuse an actor from responding to requests that are infeasible
F. permit licensing of interoperability technology on reasonable and non-discriminatory terms
G. reasonable and necessary to promote the performance of health IT

Each exception is qualified by specific requirements [summarized in the links provided]. In designing these exceptions, including their specific requirements, the ONC was guided by three policy considerations:

To promote public confidence in health IT infrastructure, protect patient safety and/or promote competition or innovation in health IT and its use to provide health care services to consumers
To mitigate a significant risk that "reasonable and necessary activities” might not be engaged in, out of concern that these activities would constitute information blocking
To tailor permissible exceptions through appropriate conditions, so that they are limited to the reasonable and necessary activities that they are designed to exempt.

A. Exception - Preventing Harm

To qualify for this exception, the actor must have a reasonable belief that the practice will directly and substantially reduce the likelihood of harm to a patient or another person, arising from (1) corrupt or inaccurate data being recorded or incorporated in a patients electronic health record; (2) misidentification of a patient or patient’s EHI; or (3) disclosure of a patient’s EHI in circumstances where a licensed health care professional has determined, in the exercise of professional judgment, that the disclosure is reasonably likely to endanger the life or physical safety of the patient or another person. Circumstances arising under (3) would not disturb applicable federal or state law requirements giving patients the right to review that determination, where applicable. To the extent a practice implements an organizational policy, the exception also imposes policy standards. In all other cases, the actor must make a finding in each case, based on the particularized facts and circumstances, and based on, as applicable, relevant clinical, technical and other appropriate expertise, that the practice necessary and no broader than necessary to mitigate the risk of harm

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

2. Assurances

The Cures Act requires a health IT developer, as a Condition and Maintenance of Certification under the Program, to provide assurances to the Secretary, unless for legitimate purposes specified by the Secretary, that it will not take any action that constitutes information blocking or any other action that may inhibit the appropriate exchange, access and use of EHI. The ONC proposes to implement these assurances in [Section 170.402]. Under Subpart B of proposed Part 171 of the proposed rule, starting at Section 171.200, the ONC proposes seven (7) "reasonable and necessary" activities that would constitute exceptions to the information blocking definition.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

Part 171 -- Information Blocking; Subpart B -- Exceptions for Reasonable and Necessary Activities

Section 171.201 - Exception - Preventing harm
Section 171.202 - Exception - Promoting the privacy of EHI
Section 171.203 - Exception - Promoting the security of EHI
Section 171.204 - Exception - Recovering costs reasonably incurred
Section 171.205 - Exception - Responding to requests that are infeasible
Section 171.206 - Exception - Licensing of interoperability elements on reasonable and non-discriminatory terms
Section 171.207 - Exception - Maintaining and improving HIT performance.

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

a. Full compliance and unrestricted implementation of certification criteria capabilities

For the avoidance of doubt, the Conditions of Certification would include at [Section 170.402] assurances](#1 (comment)) by the health IT developer that the certified Health IT conforms to the full scope of the certification criteria to which its health IT is certified. They would also be required to provide an assurance that they have made certified capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes, and not take any action that could interfere with a user's ability to access or use certified capabilities within the scope of the technology's certification. These assurances are likely to find their way in commercial contracting terms.

By way of example, the ONC states that these actions would violate these assurances:

  • failing to fully deploy or enable certified capabilities
  • imposing limitations (including restrictions) on the use of certified capabilities once deployed
  • requiring subsequent developer assistance to enable the use of certified capabilities, contrary to the the intended uses and outcomes of those capabilities
  • refusing to provide documentation, support or other assistance reasonably necessary to enable the use of certified capabilities for their intended purposes
  • imposing limitations or additional types of costs that have the effect of substantially impairing the ability of one or more users to implement or use certified capabilities for any purpose within the scope of applicable certification criteria, especially when these costs are not disclosed when a customer purchased or licensed the certified HIT.

Organizations will need to review their business practices to eradicate these activities if they exist.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

b. Certification to the EHI Export Criterion

As a Condition of Certification, ONC proposes that all HIT developers that produce and electronically manage EHI would need to certify its HIT to the 2015 Edition "electronic health information export" certification criteria, as proposed in Section 170.315(b)(10).

HIT developers of certified HIT certified to this criteria would need to provide EHI export capabilties within 24 months after the final rule becomes effective. HIT developers that never previously certified HIT would have 12 months from certification, if later.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

c. Records and Information Retention

HIT developers would be subject to a 10 year record and information retention policy, beginning from the date of certification, in order to demonstrate initial and ongoing compliance with the ONC Health IT Certification Program. It applies separately to each unique Health IT Module (or complete EHR, as applicable).

An exception is proposed for certification criteria that are later removed from the CFR before a 10-year period expires. In these cases, records only need to be kept for 3 years from the date of removal, or the expiration of the 10 year period, whichever occurs sooner.

For Health IT developers that have never participated in the ONC Health IT Certification Program, presents their Health IT Modules for certification and produces and electronically manages EHI, the record keeping and compliance responsibilities associated with the Conditions and Maintenance of Certification are going to be a significant new cost that will need to be budgeted into its service offerings, and included in calculations to justify recovery of reasonably incurred expenses, per Subpart B of the Information Blocking Rule.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

d. Trusted Exchange Framework and the Common Agreement - RFI

ONC requests comment on whether the Assurances provided by some HIT developers as part of the proposed Conditions and Maintenance of Certification regulations include a requirement that they participate in the TEFCA. According to the ONC, doing so would give further assurances to customers and ONC that these HIT developers are not taking actions that constitute information blocking or any other action that may inhibit appropriate exchange, access and use of EHI. The requirement would have to come up in a subsequent rulemaking, but ONC requests these comments as an RFI. The ONC only envisions the requirement for HIT developers that have a Health IT Module certified to any of the following 2015 Edition certification criteria, because the capabilities included in these criteria support access and exchange of EHI:

  • the "transitions of care" certification criteria (Section 170.315(b)(1))
  • the "clinical quality measures" certification criteria (Section 170.315(c)(1) and (2))
  • the "view, download and transmit" certification criteria under patient engagement (Section 170.315(e)(1))
  • the "public health" certification criteria (Section 170.315(f))
  • the "application access - all data request certification criteria (Section 170.315(g)(9))
  • the proposed "standardized API for patient and population services" certification criteria (Section 170.315(g)(10))
  • the proposed "consent management"certification criteria (Section 170.315(g)(11))

The ONC doesn't envision TEFCA being a requirement for HIT developers of HIT Modules that do not support access and exchange of EHI; for example, HIT developers of clinical decision support HIT Modules would not be subject to the requirement, if proposed and implemented.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

3. Communications

The ONC proposes a two-part test to implement provisions of the Cures Act that prohibit a HIT developer from prohibiting or restricting communication regarding (a) the usability, interoperability or security of the HIT or (b) relevant information about users' experience when using the HIT, the developers' business practices related to EHI exchange or the manner in which users have used the HIT. Under the two-part test, it would never be legitimate or reasonable to restrict communications required by law, made to a government agency or made to a defined category of safety organizations. HIT developers would be permitted to impose certain narrow kinds of prohibitions and restrictions enumerated in proposed Section 170.403(a)(2)(ii). Health IT vendors would also be prohibited from establishing or enforcing contract provisions that contravene the proposed rule. Under the proposed Maintenance of Certification provisions, health IT vendors would need to notify existing customers within 6 months of the effective date of a final rule that contract provisions in conflict with the requirement will not be enforced by the HIT developer, and to provide follow up notices annually until the contract is amended to remove or void the contravening contract provisions.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 17, 2019

Section 170.403(a)(ii) - Communications - Permitted Prohibitions and Restrictions

Following is a high-level description of the exceptions from the proposed rule In the ONC's proposed Conditions and Maintenance of Certification for Health IT Developers that would restrict health IT developers from prohibiting or restricting communications regarding the the usability, interoperability or security of the HIT or relevant information about users' experience when using the HIT, the developers' business practices related to EHI exchange or the manner in which users have used the HIT.

(A) Developer employees and contractors. A health IT developer may prohibit or restrict the communications of its employees or contractors.
(B) Non-User Facing Aspects of HIT. A health IT developer may prohibit or restrict communications that disclose information about non-user-facing aspects of the developer's HIT
(C) Intellectual Property. A health IT developer may prohibit or restrict communications that would infringe IPRs existing in the developer's HIT, provided:

  1. communications that would be a fair use of copyright work may not be prohibited or restricted
  2. communication of screenshots can only be restricted along specified parameters

(D) Screenshots. Health IT developers may require persons who communicate screenshots to follow specified parameters (e.g. not to alter screenshots or infringe the IPR of third parties, or only use redacted screenshots of 3rd party content and PHI)
(E) Pre-Market Testing and Development. Health IT developers may prohibit or restrict communications that disclose information or knowledve solely acquired in the course of participating in pre-market product development and testing activities.

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

4. Application Programming Interfaces (APIs)

The ONC's discussion of the Conditions and Maintenance of Certification related to APIs begins in the proposed rule on page 7476. It implements the Cures Act requirement that HIT developers publish APIs that allow "health information from such technology to be accessed, exchanged and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law." The Cures Act's API Conditions of Certification also states that a developer must, through an API, "provide access to all data elements of a patient's EHR to the extent permissible under applicable privacy laws."

This preamble outlines the ONC's proposals to implement the Cures Act's API Condition of Certification, which include new standards, new implementation specifications and a new certification criterion, as well as detailed Conditions and Maintenance of Certification requirements. The ONC also proposes to modify the Base EHR definition.

2019 03 13_Posnack_APICoC_Fees_IB.pdf is a slide deck prepared by the ONC about the API provisions of the proposed rule. It was accessed on March 15, 2019 from HealthIT.gov

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

a. Statutory Interpretation and API Policy Principles

The ONC interprets the "effort" exerted (i.e. by whom) to be focused on API users, which could include third party software developers, the health care providers that acquire API technology, and patients, health care providers and payers that use apps/services that connect to API technology. It interprets "without special effort" to require that APIs, and the health care ecosystem in which they are deployed, have three attributes: Standardized, transparent and pro-competitive.

  • Standardized. All health IT developers seeking certification should have to implement the same technical capabilities. Technical consistency and implementation predictability are fundamental to scale API-enabled interoperability. With standardization, health IT developers would gain certainty in regards to pre-certification testing and post-certification real world testing expectations. Moreover, a consistent and predictable set of API functions would provide the health IT ecosystem with known technical requirements against which "app" developers and other innovative services can be built.
  • Transparent. All HIT developers seeking certification of API technology would need to make the specific business and technical documentation necessary to interact with APIs in production freely and publicly accessible, as is commonplace in industries marked by innovation, growth and competition.
  • Pro-Competitive. All HIT developers seeking certification of API technologies would need to abide by business practices that promote the efficient access, exchange and use of EHI to support a competitive marketplace. The ONC also believes that health care providers - not HIT developers - should have the sole augthority and autonomy to unilaterally permit 3rd party software developers to connect to the API technology they have acquired. Moreover, patients, who as consumers of health care services, should be able to access their EHI via any API-enabled app they choose without special effort, since they pay for their care and the information generated from that care.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

b. Key Terms

The proposal would update 45 CFR 170.102 to include the following new terms:

  • API technology generally refers to the capabilities of certified health IT that fulfill the API-focused certification criteria adopted or proposed for adoption at 45 CFR 170.315(g)(7) through (11)
  • API Technology Supplier refers to a health IT developer that creates the API technology that is presented for testing and certification to any of the certification criteria adopted or proposed for adoption at 45 CFR 170.315(g)(7) through (11)
  • API Data Provider refers to the organization that deploys the API technology created by the API Technology Supplier and provides access via the API technology to data it produces and electronically manages
  • API User refers to persons and entities that use or create software applications that interact with the APIs developerd by the API Technology Supplier and deployed by the API Data Provider. An API User includes third party software developers, developers of software applications used by API Data Providers, patients, health care providers and payers that use apps/services that connect to API technology.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

c. Proposed API Standards, Implementation Specifications and Certification Criteria

i. Proposed Adoption of FHIR DSTU2 Standard ("FHIR Release 2")

In the proposed rule, the ONC proposes to adopt FHIR Release 2 as the baseline standard conformance requirement in a new API standards section at 45 CFR 170.215(a)(1). FHIR Release 2 is also referenced for use in the new "standardized API for patient and population services" certification criterion at CFR 170.315(g)(10). The ONC reports that approximately 87% of hospitals and 57% of clinicaians are served by delovered with a FHIR Release 2 API, reflecting rapid progress since publication of the 2015 Edition certification criteria to advance the FHIR Standard.

While the ONC believes FHIR Release 2 best reflects the industry's current maturity and implementation readiness, it observes that FHIR Release 3 is published. Additionally, FHIR Release 4 has not been published, and updated associated implementation specifications are expected to follow. The ONC remarks that FHIR Release 4 has several key improvements which will be compelling for many health IT developers. As a result, the ONC expects many health IT developers will either rapidly process to FHIR Release 4 from Release 3, or skip Release 3 entirely.

For these reasons, ONC wants to know if it should adopt just FHIR Release 2 as the baseline API standard (Option 1), adopt FHIR Release 2 and 3 (Option 2), adopt FHIR Release 2 and 4 (Option 3) or adopt just FHIR Release 4 (Option 4). In the preamble, the ONC observes that Option 3 would appear to be the best near and long term option for the industry, as long as the FHIR Release 4 implementation specifications are published in time for the final rule. Option 3 would allow lagging health IT developers to catch up to the FHIR Release 2 baseline while enabling leading health IT developers to move directly and immediately to FHIR Release 4. The ONC regards Option 4 as the next best option, if the implementation specifications are published in time for the final rule, because it would still give industry 12 months of development experience with FHIR Release 4 without putting a drag on the industry's transition to FHIR Release 4.

The ONC highly encourages stakeholders to express their perspectives and explicitly note their preferred option in comments.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

c. Proposed API Standards, Implementation Specifications and Certification Criteria

...

ii. Proposed Adoption of Associated FHIR Release 2 Implementation Specifications

Proposes to adopt three (3) implementation specifications to constrain implementation choices on the proposed FHIR Release 2 baseline conformance standard and further assure that APIs can be used "without special effort".

  • API Resource Collection in Health (or "the ARCH")(45 C.F.R. Section 170.215(a)(2). The ARCH refers to a subset of FHIR resources that map to and support the equivalent data classes specified in the USCDI:
  1. AllergyIntolerance
  2. CarePlan
  3. Condition
  4. Device
    • The "Device.udi" element to follow the human readable representaiton of the UDI found in HL7 Version 34 Cross Paradigm Implementation Guide: Medical Devices and Unique Device Identification (UDI) Pattern, Release 1.
  5. DiagnosticReport
  6. Goal
  7. Immunization
  8. Medication
  9. MedicationOrder
  10. MedicationStatement
  11. Observation
  12. Patient
    • The ONC would require "Patient.address" and "patient.telecom" to be supported.
  13. Procedure
  14. Provenance
    • The ONC would require "Provenance.recorded" (for the author's time stamp) and "Provenance.agent.actor (for the author and author's organization) to preserve context when specific data is exchanged through FHIR-based APIs
  15. DocumentReference
    • The ONC observes that this resource is best capable of handling the exchange of clinical notes
  • Argonaut Data Query Implementation Guide version 1 (45 C.F.R. 170.215(a)(3). Specifies FHIR profile constraints for 13 of the associated FHIR resources proposed for inclusion in the ARCH

  • Argonaut Data Query Implementation Guide Server conformance requirements (45 C.F.R. Section 170.215(a)(4). Viewed by the ONC as essential for ensuring that all FHIR servers are consistently configured to support the defined data queries and "supported searches" associate with each Argonaut profiled FHIR resource.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

c. Proposed API Standards, Implementation Specifications and Certification Criteria

...

iii. Proposed Adoption of Standards and Implementation Specifications To Support Persistent User Authentication and App Authorization
  • Proposes to adopt the OpenIDConnect Core 1.0 incorporating errata set 1" standard (45 C.F.R. Section 170.215(b). The ONC notes that it is typically paired with OAuth 2.0 and complements the SMART Guide (below)
  • Proposes to adopt the SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART Guide) (45 C.F.R. Section 170.215(a)(5)) because it is referenced by the Argonaut IG and is generally being implemented by the health IT community as a security layer with which FHIR deployment is being combined.
  • While the SMART Guide specifies the use of "refresh tokens" as optional, ONC would make their use mandatory, with a minimum refresh token life of 3 months
    • Consistent with industry developed security best practice guidelines for OAuth 2.0, which require support for a short-lived "access token" and a long-lived "refresh token"
    • ONC believes these further requirements will enhance the seamlessness of a patiebnt's data access and reduce "friction" they would otherwise experience with having to re-authenticate and re-authorize.
  • ONC would also require that the "Standalone Launch" and "EHR Launch" requirements specified in the SMART Guide be supported.
    • The "Standalone Launch" would require API Technology Suppliers to demonstrate ease of use when a third party app first connects with a FHIR server; for example, by showing information about the patient's most recent encounter.
    • The EHR Launch" would require API Technology Suppliers to demonstrate that the app will open directly to the same patient as for the open/active patient record in the EHR when the API-enabled application is launched.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

c. Proposed API Standards, Implementation Specifications and Certification Criteria

...

iii. Proposed Adoption of a New API Certification Criterion in Section 170.315(g)(10)

The ONC would retire the current "application access - data category request" certification criterion at 45 C.F.R. Section 170.315(g)(8), which applies standards-less requirements for API functionality when data is requested from a C-CDA. In its place, the ONC proposes a new "standardized API for patient and population services" at a new Section 170.315(g)(10). During a transition period (through month 24 after the final rule's effective date), HIT developers would be able to choose between the two certification criterion. The proposed "standardized API for patient and population services" would apply to any Health IT Module presented for certification and any technology meeting the 2015 Edition Base EHR definition presented for EHRT certification.

Key highlights

  • Requires "read" access for data defined in the USCDI
  • Requires FHIR servers to support services for which a single patient's data is at focus, like
    • software or mobile apps controlled and used by patients to access their data
    • software apps implemented by a provider to enhance their internal clinical care tools and workflow
  • Requires FHIR servers to support services for which multiple patients' data is at focus, like
    • a specific provider's patient panel
    • all patients covered by a specific health plan
    • all patients cared for through a specific alternative payment model
  • Supported services where multiple patients' data is at focus include:
    • software apps used by a health care provider to manage various internal patient populations
    • external services contracted for by a health care provider
  • Implements proposed definitions for "API Technology Supplier", "API Data Provider", "API User" and "API technology"

ONC notes that FHIR Release 2 does not have as many capabilities to support population level services. By contrast, FHIR Release 4 includes technical specification to enable standardized population-level services in a more efficient manner.

HIT presented for testing and certification against the proposed "standardized API for patient and population services" certification criterion would need to meet these requirements:

  • Data Response. Must be capable of responding to requests for data on a single patient and multiple patients associated with each of the FHIR resources specified in ARCH v.1 and consistent with FHIR Release 2 (as currently proposed) and the Argonaut IG implementation specification.
  • Search Support. Must be capable of responding to all of the "supported searches" specified in the Argonaut Data Query Implementation Guide Server. The ONC observes that HIT developers would be permitted to approach searches for multiple patients in a manner they deem efficient, since there is not yet a consistent, standardized specification for FHIR servers to handle searches for multiple patients. The ONC requests comment on the minimum "search" parameters that would need to be supported for DocumentReference and Provenance resources.
  • App Registration. Must be capable of enable apps to register with with an "authorization server", but does not require that it be done according to a specific standard. The ONC considered but decided against requiring that this capability be done according to the OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] standard because of relatively low adoption rates. While industry reaches consensus, it opted to define the requirement as a technical outcome. The ONC does not intend to test registration capabilities for apps that would be executed within an API Data Provider's clinical environment, on the grounds that API Technology Suppliers and API Data Providers are best poised to innovate and execute app registration within these environments. By inference, the ONC might be suggesting that certification would require demonstration of app registration for patient apps, but clarification may be needed.
  • Secure Connection, Authentication and Authorization.
    • Must be capable of establishing a secure and trusted connection with an application that requests patient data in accordance with the SMART Guide. Functionally, this means that an "authorization server" would be deployed and be required to support "authorize" and "token" endpoints. The ONC states that "initial conformance would focus on the secure connection parameters with a single patient's data in mind" since there is not yet a consistent, standardized specification for FHIR servers to handle secure connection parameters for multiple patients. API Technology Suppliers would be permitted to use approaches that they deem most efficient to meet the proposed certification criterion.
    • When an app connects to request data for the first time, the API technology must be capable of supporting user authentication according to OpenID Connect Core 1.0 incorporating errata set 1 and allowing users to authorize applications to access data in accordance with the SMART Guide.
    • Testing would occur in "Standalone Launch" and "EHR Launch" modes.
    • To get persistent access to health information without having to re-authenticate and re-authorize, the API technology must provide a "refresh token" with an expiration period of at least 3 months from date of issuance and support subsequent connections without re-authentication or re-authorization when a valid refresh token is supplied.
    • an industry consensus standard does not yet exist to support persistent connections for data requests for multiple patients, but the ONC expects that FHIR Release 4 will address this. In the meantime, developers would be permitted to approach requests for multiple patients in the manner they deem most efficient.
  • Transparency Through the Publication of API Documentation. API Technology Suppliers would need to provide complete, detailed information for all aspects of its (g)(1)-certified API, especially for any unique technical requirements and configurations. Documentation must be of the sort and to the level of specificity, precision and detail that the HIT developer customarily procides to its own employees, contractors and/or partners who develop software applications for production environments. It should be accessible via hyperlink without additional access requirements.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

4. APIs

...

d. Conditions of Certification Requirements

The ONC proposes a new API Condition of Certification requirement at 45 C.F.R. Section 170.404.

i. Scope and Compliance

The Condition of Certification would apply to any developer of Health IT Modules certified to any of the certification criteria in 45 C.F.R. Sections 170.315(g)(7) through (11), namely:

  • (adopted) the "application access - patient selection" certification criteria (45 C.F.R. 170.315(g)(7))
  • (proposed for removal) the "application access - data category request" certification criterion (45 C.F.R. 170.315(g)(8))
  • (adopted) the "application access - all data request" certification criterion (45 C.F.R. 170.315(g)(9))
  • (proposed) the "standardized API for patient and population services" certification criterion (45 C.F.R. 170.315(g)(10))
  • (proposed) the "consent management for APIs" certification criterion (45 C.F.R. 170.315(g)(11)

It would not apply to health IT developers that do not have technology certified to any of the foregoing criteria. Note, that the ONC also proposes to update the "Base EHR" definition at 45 C.F.R. 170.102 to include the the "application access - patient selection", "application access - all data request", and "standardized API for patient and population services" certification criteria, but not the "consent management for APIs" certification criterion. The definition would also give developers the option of certifying to the "application access - data category request" certification criterion instead of the "standardized API for patient and population services" during a 24-month transition period after a final rule takes effect.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

4. APIs

...

d. Conditions of Certification Requirements

The ONC proposes a new API Condition of Certification requirement at 45 C.F.R. Section 170.404.
...

ii. Cures Act Condition and Interpretation of "All Data Elements"

The Cures Act's API Condition of Certification requires that a developer, through an API, "provide access to all data elements (emphasis included) of a patients' electronic health record to the extent permissible under applicable privacy laws." Initially, the ONC constrains its interpretation of "all data elements of a patient's electronic health record" to the limited set of data elements defined by the UCSDI and supported by the ARCH. The API Conditions of Certification will accommodate updates in required data elements as the UCSDI and the ARCH are updated.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

  1. APIs
    ...
    d. Conditions of Certification Requirements
    ...
    iii. Transparency Conditions

The ONC proposes that the API Condition of Certification require specific business and technical documentation to be freely and publicly accessible. These would include all terms and conditions, as well as the technical documentation described in the "standardized API for patient and population services" certification criterion.

"terms and conditions" would include any fees, restrictions, limitations, obligations, registration process requirements and other terms or conditions that would be material and needed to:

  • develop software applications to interact with the API technology
  • distribute, deploy and enable the use of software applications in production environments that use the API technology
  • use software applications, including to access, exchange and use EHI by means of the API technology
  • use any EHI obtained by means of the API technology and
  • register software applications.

The ONC proposes that any and all fees charged by an API Technology Supplier for use of its API technology must be published and described in detailed, plain language as part of its publicly available terms and conditions. The description of the fees must include all material information, including:

  • the persons or classes of persons to whom the fee applies
  • the circumstnaces in which the fee applies
  • the amoung of the fee, which for variable fees must include the specific variable(s) and methodology(ies) that would be used to calculate the fee.

After a 6-month transition period from the final rule's effective date, suppliers with products already certified to Section 170.315(g)(7), (8) or (9) would have to revise their API documentation to come into compliance with these transparency conditions.

The ONC would expect API Technology Suppliers to revise and/or construct terms and conditions for its API technology that account for and reflect the provisions of the proposed API Conditions of Certification. Revised terms and conditions would also need to address compliance with the ONC's proposed Information Blocking regulation, so that API Technology Suppliers can qualify for applicable exceptions, like "Recovering Costs Reasonably Incurred" and "Licensing of Interoperability Elements on Reasonable and Non-Discriminatory Terms".

Another transparency condition concerns the processes used by API Technology Suppliers to verify third party app developers. The ONC notes in passing that had it implemented the OAuth 2.0 standard, it would have outright prohibited API Technology Suppliers from identity proofing or verifying authenticity of developers of apps designed to enable patient access. In the alternative, the ONC seeks comment and recommendations on factors that would enable registration with minimal barriers; for example, by:

  • permitting API Technology Suppliers to do one-time verification of the app developres, which would allow the developer's future apps to automatically register without case-by-case checks.
  • mandating the Dynamic Registration option supported by the OAuth 2.0 standard

Meantime, the ONC proposes to permit API Technology Suppliers to institute a process to verify the authenticity of app developers, subject to the following conditions:

  • the process would need to be completed within 5 business days
  • the process would need to focus only on authenticating the app developer's identity, and not involve any verification process on the underlying software application
  • the process would have to be objective and the same for all app developers

Examples of verification techniques suggested by the ONC include:

  • instituting "penny verification" process
  • requiring some form of corporate documentation
  • requesting other forms of authenticating documentation or transactions

The ONC notes that app developers would still need to be registered, and thus be identifiable and able to have their access deactivated if they behave in malicious ways [acceptable use policies]. Also, the patient seeking access through the app needs to authenticate themselves in order to connect to the FHIR server and specify the scope of data the app may access.

For apps used by health care providers, the ONC recognizes that API Technology Suppliers may establish additional mechanisms within to vet app developers to ensure that they operate appropriately within the providers' health IT environment and won't degrade overall system performance. The ONC advises that these mechanisms could fit into the "value-added services" permitted fee and result in the app being acknowledged or listed by the health IT developer in some special manner (e.g. in an "app store" or "verified app" list). The ONC's proposals do not specify any explicit limits to the nature and governance of these approaches, but cautions HIT developers to design these approaches in ways that avoid violations of the proposed Information Blocking regulation.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

  1. APIs
    ...
    d. Conditions of Certification Requirements
    ...
    iv. Permitted Fees Conditions

The permitted fee conditions in the proposed API Conditions of Certification have been designed to align with the requirements of the information blocking exceptions proposed in the Information Blocking regulation. Absent a valid exception, the API Conditions of Certification would prohibit API Technology Suppliers from imposing fees associated with certified API technology (but not for other types of technology or unrelated services). In order for API Technology Suppliers to recover costs and earn a reasonable return on their investment in providing certified API technology, the ONC has identified categories of "permitted fees" that API Technology Suppliers would be permitted to charge and remain in compliance with the API Conditions of Certification.

Other than with regard to "value-added services," proposed in Section 170.404(a)(iv), fees permitted under the API Conditions of Certification must arise between an API Technology Supplier and an API Data Provider. Any fee arising in connection with an API User's use of API technology would need to exist solely between the API Data Provider and the API User. Suppliers would not be permitted in any way to impose fees on any person in connection with an API Technology Supplier's work to support the use of certified API technology to facilitate a patient (or patient app's) ability to access, exchange or use their EHI. However, API Technology Suppliers would be permitted to charge API Data Providers based on the usage activities of API Users.

These fee parameters would not prohibit another party from paying for API Technology Supplier's permitted fee, however. For example, an API User could offer to pay the permitted fee charged to an API Data Provider by an API Technology Supplier. In devising payment strategies, the ONC reminds stakeholders to be mindful of other federal and state laws and regulations that could prohibit or limit certain types of relationships involving remuneration.

General Conditions - Permitted Fees

  • the fee imposed must be based on objective and verifiable criteria that are uniformly applied for all substantially similar or similarly situated classes of persons and requests
  • the fee must not be based on whether the API User is a competitor or potential competitor, or on whether the data accessed via the API technology will be used to facilitate competition with the API Technology Supplier
  • the fee must be reasonably related to the API Technology Supplier's costs of supplying and, if applicable, supporting the API technology. Under this requirement, revenue-sharing arrangements may not be permitted becuase the fee bears little plausible relation to the costs incurred by the API Technology Supplier
  • the fee must be reasonably allocated among all customers to whom the API technology is supplied or for whom it is supported.
  • the API Technology Supplier must ensure that fees are not based in any part on whether the requestor or other person is a competitor, potential competitor or user of the API technology in a way that facilitates competition with the API Technology Supplier (contradicts settled acceptable use terms in standard SaaS agreements)

Specific Proposed Permitted Fees

1. Reasonable Fees for Developing, Deploying or Upgrading API technology

  • reasonable fees for developing API technology.
    • fees for developing API technology must not inclde the costs of updating the non-API related capabilities of the API Technology Supplier's existing health IT, including its databases, as part of its development of the API technology.
    • ONC appears to be taking aim at HIT developers that may have designed or implemented HIT in nonstandard ways in the past. ONC believes recovery of these costs would be inconsistent with the Cures Act requirement that API technology be deployed "without special effort"
  • reasonable fees for deploying API technology
    • deployment fees would be tied to the costs of operationalizing API technology in a production environment (e.g. standing up hosting infrastructure, software installation and configuration, creation/maintenance of API Data Provider administrative functions)
    • deployment fees would not include costs associated with managing the traffic of API calls (see usage support costs instead)
  • reasonable fees for "upgrading" API technology
    • upgrade fees would comprise costs to bring API technology into conformity with new requirements of the Program, updates to implement general software updates or developing updates requested by the API Data Provider
  • The ONC views it as "inappropriate to pass development, deployment or upgrade fees to API Users (although see above, where API Users can enter into an arrangement directly with API Data Providers to pay for these incurred costs)

2. Recovery of Costs To Support API Usage for Purposes Other than Patient Access, Exchange and Use

  • usage fees may not be charged to patients or the applications they use to access, exchange or use their health information
  • usage fees would have to be tied to incremental costs incurred to support API interactions at increasing volumes and scale within established service levels. Wouldn't apply in scenarios where the API Data Provider assumes full responsibility for the technical infrastructure necessary to deploy and host the API technology
  • usage fees charged to API Users would not be appropriate, in the ONC's view. "The API Technology Supplier would have no standing to go around or through the API Data Provider to issue fees to, for example, a population health analytics company engaged by an API Data Provider who accesses the API Data Provider's data via the API technology."
  • the preamble includes discussion of different pricing models, including tiered, "pay-as-you-go" and and structures that support unlimited API calls. The ONC cautions against designing pricing models that can't be supported by the underlying requirements in the API Condition of Certification. For example, a pricing model with unlimited API call volume would need to be based upon a realistic estimate of anticipated volume to avoid excessive fees.
  • fees would not be permitted to recover costs associated with intangible assets (e.g. the purported "cost" of allowing the API Data Provider to use the API Technology Supplier's patented API technology. In the ONC's view, "it would be inappropriate to permit an actor to charge a fee based on these considerations, which are inherently subjective and could invite the kinds of rent-seeking and opportunistic pricing practices that create barriers to access, use and exchange of EHI and impede interoperability."
  • fees would not be permitted to recover opportunity costs, except for the reasonable forward-looking cost of capital.

3. Permitted Fee for Value-Added Services

  • API Technology Suppliers would be permitted to charge fees to API Users for value-added services. These services would need to be provided in connection with and supplemental to the development, testing and deployment of software applications that interact with API technology.
  • Value added service fees would not be permitted if they interfere with an API User's ability to efficiently and effectively develop and deploy production-ready software. It has to be an elective service. Examples might include:
    • advanced training
    • premium development tools
    • premium distribution channels
    • enhanced compatibility/integration testing assessment
    • "write" access to APIs
    • co-branded integration into the API Technology Supplier's product(s) workflow
    • co-marketing arrangements
    • promoted placement in an API Technology Supplier's app store

** 4. Prohibited Fees**
The ONC provides examples of what it views to be prohibited fees because they inappropriately create barriers to entry or competition and reflect rent-seeking and other opportunistic behaviors:

  • any fee for access to the documentation that an API Technology Supplier is required to publish or make available under the API Condition of Certification
  • any fee for access to other types of documentation or information that a software developer may reasonably require to make effective use of API technology for any legally permissible purpose
  • Any fee in connection with any services that would be essential to a developer or other person's ability to develop and commercially distribute production-ready applications that use API technology.
    • For example, charging fees for access to "test environments" and other resources that an app developer would need to efficiently design and develop apps would not be a permitted "value added service", in the ONC's view.
    • Another example: charging access fees to connect to FHIR services or have the ability to dynamically register with an authorization server would not be a permitted "value added service", in the ONC's view.

** 5. Record-Keeping Requirements**
API Technology Suppliers would be required to maintain for inspection detailed records of all fees charged with respect to certified API technology and all costs they claim to have incurred to provide API technology to API Data Providers. They would also need to document the criteria used to allocate any costs across relevant customers, requestors or other persons, so that the ONC would be able to objectively determine whether cost allocations are reasonable and comply with cost allocation requirements. Consistent with the Assurances Condition of Certification, records would need to be retained for 10 years (or three years post-removal by the ONC of a relevant API certification criterion), whichever occurs first.

Comments sought.

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

  1. APIs
    ...
    d. Conditions of Certification Requirements
    ...
    iv. Openness and Pro-Competitive Conditions

These conditions further align the API Conditions of Certification with the pro-competitive principles guiding the ONC's rulemaking.

General Condition

  • API Technology Suppliers would be required to grant API Data Providers the sole authority and autonomy to permit API Users to interact with the API technology deployed by the API Data Provider.

Specific Conditions

  • Nondiscrimination. API Technology Suppliers would be required to provide API technology to API Data Providers on [pricing and non-pricing] terms that are no less favorable than they would provide to themselves and their customers, suppliers, partners and other persons with whom they have a relationship
    • Any terms and conditions associated with API technology would have to be based on objective and verifiable criteria that are uniformly applied for all substantially similar or similarly situated classes and requests.
    • An API Technology Supplier would be prohibited from offering or varying its terms or conditions on impermissible criteria, like the competitive status of the API User or the revenue or other value that the API User would derive from accessing, exchanging or using the EHI by means of the API technology.
  • Rights to Access and Use API Technology. API Technology Suppliers would be required to grant all rights reasonably necessary to access and use the API technology in production environments, and would be prohibited from imposing any collateral terms or agreements that could interfere with or lead to special effort in the use of API technology. Examples include:
    • Pay a license or royalty fee, or enter into a revenue-sharing arrangement
    • Agree to a non-compete agreement
    • Agree to an exclusivity arrangement
    • Obtain additional licenses, products or services that can be unbundled from the API technology
    • Agree to license, grant, assign or transfer any IP to the API Technology Supplier
    • Additional developer or product certification requirements
    • Grant reciprocal access to application data

API Technology Suppliers - Additional Obligations. To support the use of API technology in production environments, API Technology Suppliers would be required to provide all support and other services that are reasonably necessary to enable the effective development, deployment and use of API technology by API Data Providers and its API Users. In this regard, they would be required --

  • to make reasonable efforts to maintain the compatibility of the API technology they develop, and assist API Data Providers
  • to provide notice and a reasonable opportunity for its API Data Provider customers and registered application developers to update their applications prior to making changes or updates to their API technologies

Return to Table of Contents

@JillDeGraff

This comment has been minimized.

Copy link
Owner Author

@JillDeGraff JillDeGraff commented Mar 18, 2019

  1. APIs
    ...
    e. Maintenance of Certification Requirements
  • API Technology Suppliers would need to "register" applications for production use within one (1) business day of completing its verification of an app developer's authenticity.
  • API Technology Suppliers would be required to support the publication of FHIR Service Base URLs for all of its customers, including those locally managed by API Data Providers
  • API Technology Suppliers (including CEHRT vendors) with API technology that has been certified to the "application access - data category request" certification would be required to deploy API technology that has been certified to the proposed "standardized API for patient and population services" certification standard within 24 months of the final rule's effective date.

Return to Table of Contents

@JillDeGraff JillDeGraff changed the title 21st Century Cures Act: Interoperabillity, Information and ONC Health IT Certification Program 21st Century Cures Act: Interoperabillity, Information Blocking and ONC Health IT Certification Program Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.