10 Thoughts About the New Proposed Rules from ONC and CMS
By Point-of-Care Partners Team
The federal government surprised most of us with the launch of two major proposed rules the day before the recent annual meeting of the Healthcare and Information Management Systems Society (HIMSS) in Orlando.
The Office of the National Coordinator for Health Information Technology (ONC) issued a proposed regulation on interoperability and information blocking. Many provisions were in response to requirements from the 21st Century Cures Act. The Centers for Medicare and Medicaid Services (CMS) issued a related proposal concerning various aspects of interoperability. Both carry out the administration’s goals of promoting patient-centric care and helping patients become more informed consumers of health care through access to their data. The proposals are far-reaching and will have significant impacts on all sectors of health care when they are implemented.
There are several reviews of the regulations out there. Here are 10 thoughts we have:
The real question on information blocking is “How will it be enforced?” Publicly, we have made the point that if there’s a will to share information, we can find a way. In a free market society, that means having a business case. That is apart from us/patients, of course, who should have access to our own data as we either own it or are paying for it in our co-payments and premiums.
We’re starting to hear ONC talk about business case; however, in the 21st Century Cures Act, Congress charged ONC with addressing “information blocking” and it is meeting that challenge. The ability to exchange information will be part of the certification process for electronic health records (EHRs). ONC will publish the names of violators and a $1 million fine will be imposed by the Office of the Inspector General. That said, ONC recognizes there are legitimate reasons to block information and lists seven exceptions. Some stakeholders are concerned about the definitions, however, arguing that they could cause more harm than good.
It will be interesting to see how this is enforced. Like most violations, it’ll probably come down to someone turning in an offending company.
Payers must make data available through FHIR APIs. Both proposed rules call for use of open application programming interfaces (APIs) based on the Health Level 7 (HL7) FHIR (Fast Healthcare Interoperability Resources) standard. Many EHRs already have developed APIs using FHIR, but it’s now part of the certification process. Interestingly, by 2020, payers (doing business with Medicare and Medicaid and through the federally sponsored health exchanges) must make data available to patients, providers and other payers (with approval from the patient), building on the myhealthedata initiative and BlueButton 2.0.
It’s worth noting that EHRs that have developed APIs have entire programs and app stores, meaning they certify those to whom they grant access and in many cases charge them a fee. While patients should surely have access to their data – and be able to direct it to a provider – one has to wonder how payers will grant this access.
If you’re not involved in HL7, you’re missing out. We’ve noticed more and more ONCers at HL7, including the National Coordinator for Health Information Technology, Dr. Rucker, himself. CMS also got on the HL7 bandwagon by specifically mentioning the Da Vinci Project in its proposed rule, so it’s no surprise to us that ONC’s proposed rule requires an expanded list of standards that must be used and which vendors (technology suppliers) will have to accommodate to achieve ONC certification. These mostly HL7 standards include:
This is the standard for APIs. The proposed rule mandates use of Release 2 (aka FHIR DSTU2), which is five years old. That’s the “floor.” The proposed rule acknowledges the recent rollout of FHIR Release 4 and says that it may be used by agreement. There’s also a Standards Version Advancement Process that allows developers to choose from among the versions of standards and implementation specifications listed in the regulation or ONC-approved newer versions.
This new government acronym (as if there aren’t enough) is the set of 15 FHIR resources that health information technology (health IT) modules must support for ONC certification. These are known as the API Resource Collection in Health or ARCH.
The Argonaut Data Query Implementation Guide. The Argonaut Data Query Implementation Guide is based on FHIR DSTU2. It documents security and authorization, data element query of the ONC Common Clinical Data Set, and document query of static documents.
SMART is one of the suites of FHIR standards. The SMART App Launch Framework connects third-party applications to EHR data, allowing apps to launch from inside or outside the user interface of an EHR system.
United States Core Data for Interoperability (USCDI). As the country moves toward value-based care, data beyond those included in the Common Clinical Data Set (CCDS) are needed. ONC proposes replacing CCDS with the USCDI standard for certification purposes. The USCDI has a wider number of data classes and elements than the CCDS. Examples include a number of clinical notes, pediatric vital signs and patient phone numbers and addresses.
Focus on standards but not versions. The notice of proposed rulemaking (NPRM) specifies a myriad of required standards, some of which are listed above. But ONC stops short of specifying standards to be used for certain requirements, such as the mandated Export Format. ONC also does not specify a version of FHIR to be supported by APIs. The proposal is to allow technology suppliers flexibility to evolve versions as the technology advances. Not mandating a particular version makes sense because that would require ongoing rules making as versions change. The unintended consequence, however, could be a free-for-all with different vendors supporting different versions. It will be challenging enough for technology suppliers to support the mandated API’s and standards. That challenge will be multiplied if multiple versions of standards need to be supported as well.
We believe the required support of all these standards and versions perpetuates the need for clearinghouses. Not everyone will be able to transition to new standards at once due to the breadth of such an undertaking and the large number of distributed systems. There will be a need for translation by clearinghouses for some time into the future.
Scope of electronic health information (EHI). The NPRM defines the data required to be available via interface and for export as “the health IT’s entire database, including but not limited to clinical, administrative and claims/billing data.” This dramatically increases the scope of data to be exposed to APIs. Within many health IT systems, administrative and billing data are managed by a separate practice management system, sometimes from a different health IT vendor. The intent of the NPRM is clear, but is the requirement to include administrative and billing data out of scope for rules focused on clinical data?
We have a window into HIPAA 2.0. For years, we’ve been awaiting anticipated changes to Health Insurance Portability and Accountability Act (HIPAA) privacy and security provisions and we know they’re working on them. The proposed rules focus on EHI, which is a wider umbrella than the “protected health information” we’ve used for years in implementing provisions under HIPAA. Encounters data, adjudicated claims, directory information and clinical data can now be added.
Another part of the proposal focuses on encryption of authentication credentials and multifactorial authentication, while another updates certification criteria for data segmentation and consent management. Data security and privacy remain top of mind for ONC; as the scope of data widens to EHI, granularity of consent management increases proportionally.
The rules for certification could change in some key ways. ONC’s proposed rule would update the existing 2015 edition certification criteria to ensure certified health IT systems can: (1) send and receive EHI in a structured format, (2) make that EHI available without “special effort” through the use of APIs, and (3) export a single patient’s or multiple patients’ EHI from the health IT system to a location designated by the patient(s). This will be accomplished largely through use of new standards (see above). EHR certification will be an ongoing process, but technology suppliers can update their software more freely (instead of waiting for new regulations). ONC also proposes updating the 2015 edition by not only identifying a number of criteria for removal but by revising and adding new certification criteria that would establish the capabilities and related standards and implementation specifications for the certification of health IT. This may seem like a positive move, but any necessary changes to be made will require technology suppliers to modify software, seek recertification and then upgrade customers. Even seemingly small things like replacing the CCDS with the USCDI is not an insignificant task.
Who pays for the data? Many entities are naturally interested in the fees that might be charged by API technology suppliers and data providers. The proposed rule places a strong focus on patients’ ability to access all their EHI (structured and/or unstructured) at no cost. While it sounds straightforward, there are some gray areas.
THE NPRM proposes that “API technology suppliers can recover the full range of reasonable costs associated with developing, deploying and upgrading API technology” and that “API technology suppliers be able to recover these costs and earn a reasonable return… so that they have adequate incentives to make continued investments in these technologies.” The NRPM is not entirely clear as to what technology suppliers may charge. Most will need to readjust their business model to comply with the proposed rules, similarly as for payers and other data sources. We look forward to the final rule to provide greater clarity – and hope that API activity doesn’t stall while we await the final rule.
Admissions, Discharge and Transfer notification gets codified. CMS is proposing that Medicare-participating psychiatric and critical access hospitals be required to send electronic notifications to providers and other facilities whenever a patient is admitted, discharged or transferred. This requirement will be important to EHRs serving hospitals. The requirement also would be included in Medicare’s conditions of participation, which have met strong opposition from the hospital industry and some who feel it doesn’t go far enough and should also include emergency visits.
Food and Drug Administration(FDA) Digital Software Precertification Program. The NPRM proposes that software certification from this FDA program could be used to satisfy requirements for 2015 Edition certification. We agree there are efficiencies to be gained by not having two certifications with similar requirements.
This clause does give us pause, however. The complexity of FDA certification for IT products is strict and arduous. FDA certification of EHRs has been long talked about and dreaded by EHR vendors. We wonder if this move to harmonize the FDA program with the ONC program could be a precursor of things to come?
Our initial take-away. We applaud ONC and CMS for their thoughtful and diligent work in developing these proposed regulations. The amount of detail is mind-numbing and the industry has much to absorb. ONC, in particular, has been challenged in trying to implement the many provisions of the 21st Century Cures Act in a real-world manner. We hope that ONC and CMS will take into account the intended and unintended real-world consequences of the proposed rule to technology suppliers.
The short-term impact will be industry pushback — and a lot of it. There’s a mountain of work to be done in a short while, which won’t make a lot of folks very happy. At a minimum, we expect the proposed 2020 implementation date for many requirements to be a bone of contention, although some of the compliance dates have been extended to 24 months. We almost wonder if the NPRM isn’t a starting point for negotiation, meaning the feds are asking for way more than they expect to get.
On the other hand, ONC recognizes the scope of lift required by the proposed changes for technology suppliers. The agency noted in a recent blog that about a third of certified health IT developers have published via the Certified Health Products List that they are using FHIR Release 2, as of mid-September 2018. Additionally, 51% of health IT developers appear to be using a version of FHIR and OAuth 2.0 together. It’s been too soon since the two proposed rules were rolled out to fully gauge industry reaction and provide a guesstimate as to what may be eliminated or changed in the final rule based on comments.
In the longer term, we think the depth and breadth of implementing these proposals may be too much for many of the smaller EHRs in the market. In fact, Table 7 in ONC’s Impact Analysis noted a 23% drop in EHRs being certified between 2011 and 2014. This proposed rule could increase market consolidation.
We’d be happy to help you understand the impact of the proposed regulations to your business and assist in developing comments. Comments are due by close of business on May 3rd. Reach out to me at tonys@pocp.com.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
