On February 11, 2019 CMS and ONC released complimentary proposed rules on Information Blocking and Interoperability. Long anticipated, these rules will influence how we exchange electronic healthcare data and ensure patient access for the foreseeable future. In this blog post, we’ll look at the major provisions of these proposed rules, and offer commentary on how they may impact our healthcare system, hospitals and providers.
As evidenced by the synchronized release of these two rules, both CMS and ONC are communicating that there is a coordinated effort to align these regulatory statues, with the message being that interoperability will be required for all healthcare providers and organizations, and that ONC certification will establish the functionality requirements necessary to ensure interoperability is standardized and achievable for the industry as a whole.
We’ll now take a look at some of the more interesting specifics of each rule, beginning with ONC:
ONC is including a new specification (as part of the 2015 Edition Base EHR definition) that will require software vendors to provide the capability to electronically export all EHI they produce and manage in an electronic format (potentially including images, clinical notes (including shared notes may conflict with state privacy laws) and data warehouse information), facilitating import and export of entire medical records between vendors for both providers and patients. Vendors will have a short 24 months (after the final rule’s effective date) to fully implement this functionality.
While certainly a noble goal (and especially helpful for providers changing HIT vendors, or patients changing providers) standardizing a single data format that will allow import of structured data across multiple vendors may prove to be a significant hurdle for ONC to document, and for vendors (and providers) to implement.
EHR Certification will now have more stringent API certification components, designed to facilitate interchange of data, using the HL7 FHIR standard.
These requirements are designed to allow not only exchange of information between healthcare providers and organizations, but also allow entrepreneurs access to health data to help facilitate innovation and “apps” that may improve care.
Additionally, the Common Clinical Data Set (CCDS) will be replaced with the United States Core Data for Interoperability (USCDI), and all data elements of the USCDI are proposed to be included in this specification. (See the section below for more on USCDI).
API developers will need to ensure security standards are met (SMART Application Launch Framework and OAuth 2.0) and patients will be able to authenticate using their EHR credentials and be able to limit the data they authorized their apps to access.
Software vendors (API Technology Suppliers) will have 24 months to deliver APIs meeting these new specifications (from the effective date of the final rule).
Three new API technology roles are also defined:
API Technology Supplier – Health IT developers (typically EHR vendors) that create API technology presented to ONC for certification. (Note ONC will now require suppliers to provide significantly expanded documentation on their APIs as part of this rule).
API Data Provider – Healthcare organizations that deploy API technology (typically hospitals and health systems).
API User – Persons and entities that use or create software applications that interact with API technology (typically patients, physicians and software “app” developers).
APIs certainly are featured prominently as a key cornerstone in HHS’ plans for solving interoperability, yet as they become more widespread in use, they may prove to be logistically and politically complex to administer. Expect continuing additional rule making helping to establish guidelines and governance standards for API use in the future.
ONC has proposed boundaries for the fees associated with API technology, specifically the amounts that API Technology Suppliers can charge API Data Providers (such as fees to recover costs of development and some incremental costs for the use of API technology).
API Data Providers are also limited with respect to the fees they can charge to API users. In addition if these fees are not based on objective criteria or considered “reasonable” they may be classified as “information blocking”.
Costs not included as part of ONC’s “permitted fees” will be expressly prohibited.
Preventing excessive fees charged by developers may be a directionally correct strategy for HHS, yet may prove difficult to administer, given the challenges with defining standards such as “reasonable” fees. Regardless, it is clear that how vendors structure and charge fees to Data Providers is likely to be under close scrutiny by HHS in coming years.
ONC proposes that interoperability means, with respect to health IT, such health IT that: (1) enables the secure exchange of electronic health information (EHI) with, and use of EHI from, other health IT without special effort on the part of the user; (2) allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable state or federal law; and (3) does not constitute information blocking.
Seven “practices” were deemed allowable (and were not to be considered information blocking) so long as certain conditions were met. These practices include:
1) Preventing Harm – defined as physical harm to a patient or another person. Must be supported by organizational policy or an individual assessment of risk in each case.
2) Promoting the Privacy of EHI – must satisfy at least one of the following:
a. Practices that satisfy preconditions prescribed by privacy laws
b. Certain practices not regulated by HIPAA but which implement documented and transparent privacy policies
c. Practices that are specifically permitted under HIPAA
d. Practices that give effect to an individual’s privacy preferences
3) Promoting the Security of EHI – practice must be directly related to safeguarding the confidentiality, integrity and availability of EHI, and must be tailored to specific security risks and implemented in a consistent and non-discriminatory manner. Also, the practice must be supported by organizational policy or an individual assessment of risk in each case.
4) Recovering Costs Reasonably Incurred – fees must be:
a. Charged on the basis of uniformly applied objective and verifiable criteria
b. Related to the costs of providing access, exchange, or use of EHI
c. Reasonably allocated among all customers that use the product/service
Fees must not be anti-competitive and certain costs are expressly excluded (e.g., costs associated with access by individuals to their EHI).
5) Responding to Requests that are Infeasible – this provision is less well defined, but allows flexibility where practical challenges exist that may limit the ability to provide access, exchange, or use of EHI (perhaps best viewed as similar to CMS’ historical “Hardship Exceptions” type of individual exclusion).
6) Licensing of Interoperability Elements on Reasonable and Non-discriminatory Terms – this exception allows those developing, maintaining and updating EHI software to earn reasonable returns / royalties on the investments they have made. The terms of any license must be reasonable and objective and uniformly applied (i.e. non-discriminatory).
7) Maintaining and Improving Health IT Performance – allows for downtime for upgrades / maintenance or other improvements to the performance of health IT that may temporarily make EHI unavailable.
HHS clearly recognizes and is trying to better define what constitutes Information Blocking, and defining what exceptions are allowed is also a step in that direction. Yet organizations or providers claiming one of these exceptions will be saddled with the burden of proof in order to be allowed to continue the practice–and there will be some risk in doing so, as the final decision for (and definition of) Information Blocking will rest with HHS.
ONC Certification is proposed to require compliance with the following seven components that will help establish interoperability:
1) Information Blocking – HIT developers must not take any action that constitutes Information Blocking
2) Assurances – HIT developers must provide assurances that they:
a. Are not Information Blocking
b. Are in full compliance with ONC’s Certification Criteria
c. Are certified to the 2015 Edition, and support the “Electronic Health Information (EHI) Export Criterion”
d. Maintain Records and Information that can demonstrate ongoing compliance
e. Participate in the Trusted Exchange Framework and adhere to the Common Agreement (i.e. TEFCA) – note that this requirement is specifically called out for “Request for Comment” (making inclusion in the final rule a bit more unpredictable)
3) Communication (Gag Clauses) – Requires HIT developers to not restrict communication (unless it infringes on intellectual property) regarding:
a. Usability
b. Interoperability
c. Security
d. User experiences
e. Business practice
f. The manner in which a user of health IT has used such technology
Note that this requires software developers to notify customers that they will not enforce any current contractual agreements / provisions that may violate this rule within six months of the effective date of the final rule, and must formally modify / amend non-complying contracts within two years.
Rewriting / renegotiating contracts may prove difficult for some vendors, and providers, hospitals and health systems are encouraged to contact their vendors early to understand how this rule may affect them.
4) Application Programming Interfaces (APIs) – requires HIT developers to:
a. Publish APIs and allow access / exchange of EHI for all data elements in the USCDI
b. Make API business and technical documentation public and accessible
c. Not charge fees unless specifically permitted by regulatory rule making
d. Grant access to API technology only when authorized by API Data Providers (i.e. hospitals and providers licensing EHRs are the ones who grant permissions for API Users to interact with APIs-not the API developers)
5) Real World Testing – HIT developers must successfully test the real-world use of their interoperability and data exchange technologies, including publication of test plans and results.
6) Attestations – HIT developers must submit attestations that they comply with the Conditions of Certification every six months.
7) Electronic Health Record (EHR) Reporting Criteria Submission (FUTURE) – this requirement is deferred as ONC has not yet established an EHR reporting program that would receive these reporting criteria. This will be a future requirement and will be enabled via future rulemaking.
Compliance with these seven criteria represent an additional burden for software developers, beyond the additional functionality requirements mandated as changes to the ONC 2105 Certification Criteria.
ONC included specific and recommended requirements for Pediatric EHRs, in support of the 21st Century Cures Act. We are planning to review these requirements in more detail in a future blog post. Until then, interested readers are encouraged to review this section in the proposed rule themselves for additional information and detail.
With this rule, ONC is moving beyond the current “Common Clinical Data Set” (CCDS) standard, and will be requiring exchange of the “U.S. Core Data for Interoperability” (USCDI) data set to support interoperability and data exchange.
The CCDS will be removed from the 2015 certification criteria and will be replaced with the USCDI and includes the following data elements:
Note that ONC plans to update the USCDI on an annual basis in order to expand the USCDI data elements and improve the scale and scope of interoperability in future years.
Again, a development standard that may seem to be reasonable, yet one that may prove technically difficult in some instances for vendors to achieve.
Worth noting is that not only will the expanded data set of the USCDI need to be enabled by developers, but providers will need to ensure they accurately and consistently capture all of this additional information, lest they perhaps risk being classified as “information blocking”.
Furthermore, leaving the door open to annual changes to scope and scale will likely prove to be an ongoing challenge, and will require HHS to accelerate its publication of standards in order to afford sufficient time for vendors to successfully comply with any required changes, upgrades and implementations.
Focusing more on Interoperability and access for patients, the CMS rule offered some additional requirements, many specific to payers:
One of CMS’ stated goals is to make it easier for patients to make informed healthcare decisions, and they are advocating the use of APIs as a way to enable and enhance that access. Indeed this proposed rule requires various entities to leverage third-party application developers using HL7 FHIR and APIs to make patient claims and other health information available to patients. These entities include:
CMS would like to ensure that as patients transition to different payers, and different health care plans that their data and healthcare information is able to be preserved and exchanged. Consequently CMS has proposed requiring that transitions of care data be electronically exchanged as patients move between payers and plan types for the following:
CMS is proposing to require organizations to provide access to health plan provider directories so that patients have the ability to easily find providers, as well as to facilitate transfer of medical records, referrals, etc. between providers. This will be required of:
CMS is requiring organizations to participate in Trusted Exchange Networks in order to share healthcare information on a nationwide basis. While not specifically linking this requirement to TEFCA compliance, it seems clear this represents CMS’ future direction (and likely additional rule making)–yet for now, the following organizations will be required to participate in a “trusted framework”:
CMS is proposing to increase the frequency that states are required to exchange data for dually eligible beneficiaries (those receiving both Medicare and Medicaid) from monthly to daily. The data set exchanged is proposed to include:
CMS will be leveraging its “Physician Compare” and potentially other websites to disclose any clinicians, hospitals or critical access hospitals (CAHs) who responded “no” to any of the three information blocking attestation statements in the Promoting Interoperability program categories.
This proposal has already received comment from physician groups, who feel that a “name and shame” strategy may not be the best way to influence and change clinician behavior. It will be interesting to see if the proposal is retained unaltered once the final rule is published.
CMS is advocating for a “centralized directory” of provider information, including electronic addresses, to facilitate information exchange among clinicians. This requirement is directly tied to the 21st Century Cures Act requirements, and is also tied to updates to the National Plan and Provider Enumeration System (NPPES) that will now include fields for digital contact information.
Similar to the Information Blocking rule, CMS is also proposing to publicly report the names and NPI numbers of providers who have not complied with this requirement by adding their digital contact information to NPPES.
CMS is proposing to require all Medicare-participating hospitals, psychiatric hospitals, and Critical Access Hospitals (CAHs) to send electronic notifications when any patient is admitted, discharged or transferred.
Furthermore, this requirement is proposed to be added as a mandatory component to the conditions of participation for these hospitals, meaning non-compliance would remove the hospital from receiving Medicare compensation.
This proposal has received significant criticism from the healthcare community, who feel that adding such a requirement to the CoP may be too drastic of a penalty, and that CMS should consider alternative ways to help ensure compliance with this initiative.
CMS is requesting public comment on how best to promote interoperability as part of the “Innovation Center” efforts.
As CMS clearly seems to be focused on leveraging these new service delivery models in the future, providers and health systems would be well advised to take an active role in helping to shape their design by commenting and engaging with CMS as it crafts these new models.
In addition to the above, CMS is also specifically requesting comments and RFI input on the following:
Combined, these two proposed rules showcase some significant new initiatives from HHS, and perhaps an indication of a new direction toward more severe penalties for non-compliance. They also represent HHS’ interpretation of the 21st Century Cures Act, and how it will implement and embed the requirements of that legislation in future rule making.
Some of the more controversial highlights likely to receive public comment include:
Certainly lots to read and digest, and providers and hospitals are encouraged to carefully review these two critical proposed rules and offer comments to CMS to help shape the future direction of these pieces of legislation as CMS contemplates and formulates its final rules.
CMS: Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans in the Federally-facilitated Exchanges and Health Care Providers
https://www.cms.gov/Center/Special-Topic/Interoperability/CMS-9115-P.pdf
ONC: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program
https://www.healthit.gov/sites/default/files/nprm/ONCCuresActNPRM.pdf
Headquarters
400 E. Diehl Road
Suite 190
Naperville, IL 60563
Downtown Chicago Office
980 N. Michigan Avenue
Suite 1998
Chicago, IL 60611
Phone
1-800-680-7570
