Last Monday, just as many of us were traveling to HIMSS, HHS released two long-awaited pieces of policy that could dramatically reshape the healthcare IT industry. The CMS proposed rules are much more future-looking and aim to change the way we share health data by moving some of the work to Payers. The ONC rule details the nearly 5-year-old term “data blocking”, and makes some minor tweaks to the way EHR products get certified.
Brief Background on Health IT policy
Health IT policy, like most policy written in the United States, starts with Congress. The relevant legislation timeline is as follows:
- 2010 – the HITECH Act was passed – leads to the creation of MU
- April 2015 – Congress passed the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA)
- December 2016 – The 21st Century Cures Act was enacted
Each of these pieces of legislation eventually ends up in the US Code, specifically Title 42. THE PUBLIC HEALTH AND WELFARE, Chapter 6A. PUBLIC HEALTH SERVICE, Subchapter XXVIII. HEALTH INFORMATION TECHNOLOGY AND QUALITY. In this case, the executive branch is tasked with carrying out the things that Congress has asked for.
Working together, CMS and ONC are able to move non-trivial levers in HIT adoption. The last decade of health IT spending, investment, and software development has been driven by these giant policy documents that come out every few years. With that, let’s dive in.
FHIR® Makes a Splash
Want to publish your own articles on DistilINFO Publications?
Send us an email, we will get in touch with you.
HL7 FHIR® is now written into law. DSTU2 (now almost 5 years old) was chosen, but that may change. In addition ARCH, the Argonaut Data Query Implementation Guide, and SMART are all given roles in the new policy. This is a departure from the previous iteration where API rules were intentionally broad. The ONC has chosen a similar tack for things like Dynamic App Registration – not preventing it, but also not specifying a standard yet.
The CMS Proposed Rules
The CMS proposed Rule is the highlight of the announcement for me, especially extending API requirements to payers. Here is a quick bullet list of the proposed changes:
- Some 345 payers will need to hire API developers to stand up FHIR APIs
- Those same Payers also need to be able to participate in networks (Carequality, Commonwell, Surescripts, etc.)
- Medicare/Medicaid participating hospitals must be able to send ADT (*cough* Redox PatientAdmin *cough*)
- Provisions for reporting information blocking
Shifting the burden away from EHR vendors and onto payers for data sharing kind of makes sense to me. On one hand, they have a direct relationship with the patient/consumer, whereas most EHR vendors only have a relationship with provider organizations. Payers want more clinical data and requiring them to share it once they have it is a good alignment of incentives.
EHR Vendors notoriously operate with a “long tail”. The market leaders command a huge share, but a large number of smaller firms make up the rest. The same can be said for payers, and the size of the tail may be 3-4 times larger than the EHR market. The problem is bigger but the incentives are better aligned. Time will tell.
The ONC Proposed Rules
The ONC proposed rule is quite a bit longer (724 pages), with the bulk of it being taken up by the data blocking rule (p.324-p.502). Here are some of the highlights.
- Data blocking is detailed, along with exceptions
- EHR Certification is now an ongoing process, but vendors can update their software more freely (instead of waiting for new regulations)
- Some elements of past CEHRT have been struck in the name of “deregulation”
- Much clearer language around standards to be used (shoutout FHIR)
- Protections for sharing screenshots and other anti-gag clauses
The EHR certification process is getting more scrutiny and potentially more burdensome, probably due to recent and notable EHR vendors getting fined. This table stood out to me though:
I predict that the new certification requirements and additional stringency will accelerate this trend. The ONC claims that market forces would have done this anyways, which I’m tempted to agree with.
Thoughts on “Data Blocking”
Data blocking is big and complex and deserves its own Socratic dialogue.
What is data blocking?
Data blocking is when one of four classes of individuals or entities engages in practices that “must be likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI”1.
What are those classes of individuals?
Health Care Providers (aka health systems), Health IT Developers (aka EHR vendors), Exchanges (aka HIEs), and Networks (aka Commonwell, Carequality)2.
EHI? What happened to PHI?
The rule defines EHI to widen the umbrella of data blocking. While PHI can only be created by covered entities, EHI can come from anywhere, like your smartphone or wearables.
What does likely-to-interfere-with mean? Seems like a big likely…
It does seem like a big likely. The intent of the “likeliness” clause is to keep the parties involved on their toes.
Ok so what if x does y, does that constitute data blocking?
See the examples starting on p.364
Woof it seems like they are really going after app stores
Yeah, but there is still room for some control over approved apps.
How so?
As long as pricing is transparent, and EHRs don’t try to force out products that compete with their own, they may be safe. They can invoke one of the exceptions like the potential for patient harm to get by as well. It’s still dangerous waters though.
There are exceptions? What are they?
- Patient harm/corrupt data
- Privacy (HIPAA still applies)
- Security (An API might offline if a breach happens)
- Recovering reasonable costs incurred (with some exceptions to the exception)
- Infeasibility
- Ability to protect IP (Reasonable and Non-discriminatory terms)
- Maintenance and performance (the system can go down under certain rules)
Wow those seem pretty broad
Each one could probably have 100 pages of exposition. The current policy as written is calling for comments on the exceptions as well as additional exceptions that may need to be considered.
So does data blocking apply to consumer-facing data exchange, provider to provider, or within the healthcare org or what?
Broadly speaking it applies to all of them. There are specific provisions for consumers – for example, exemption #4 can not be applied if a patient is trying to get their own data. It could also be applied in the reverse order, if say Apple Health doesn’t reasonably allow users to export their data, they could be investigated by the OIG.
There is also specific language around population health and other “big data” type projects. Blocking around those types of initiatives sounds like it will get lower priority.
What’s the OIG?
The Office of the Inspector General is part of HHS and is given authority by the ONC rule to investigate data blocking claims.
Who can report data blocking? Are they protected from retaliation?
There is language in the proposal to protect the confidentiality3 of those reporting. This almost seems impossible to protect though.
_____________________
1 p. 354
2 p. 331
3 p. 327
Conclusion
CMS is doing cool stuff to push the industry forward, and the ONC is grabbing a ton of influence asserting its ownership over the data blocking legislation.
The CMS policy moves levers related to their reimbursements to facilitate data sharing. Specifically, hundreds of payers will need to expose FHIR APIs. This has the potential to dramatically reshape the way consumers interact with health data.
The ONC policy spends most of its time detailing information blocking and outlines a broad set of criteria, and exceptions for meeting a “likeliness” criteria.
I eagerly await the comment period and the final rule, and I’m sure many EHR developer strategy teams have been up late this week understanding what these thousands of pages mean for them.
Date: March 6, 2019
Source: Redox
