In a prior post, I discussed what the Federal Health IT Strategic Plan meant for health IT developers. In short: a focus on interoperability and the enforcement of 21st Century Cures’ prohibition of information blocking. In this post I will look at what this proposed plan means to healthcare providers.
First, the good news. The plan calls out the need to reduce the regulatory and administrative burden on providers. In separate rulemaking, CMS has signaled that it’s entertaining scaling back on the number of quality measure submission mechanisms it allows, creating a simpler reporting framework under MIPS, and relying on more administrative claims data so that it can handle some of the administrative burden on its back-end. Taken together, I hope this means that we’ll see an approach to quality reporting that is less intrusive into provider workflows. Harmonizing measures across programs is specifically referenced in the plan and would be a wonderful start. Different quality measures have different qualifying criteria and workflows depending on how they are submitted (claims, registry, EHR, etc). Other measures, like the ones in Promoting Interoperability/Meaningful Use, may vary based on whether the program falls under Medicare or Medicaid.
For example, under Medicare (MIPS specifically), the measure that assesses whether providers are giving their patients “patient-specific education” requires the provider to deliver that education, say a link to a list of dos and don’ts before a surgery, sometime during the “performance period.” That’s usually any 90-day period the doctor picks. The Medicaid Promoting Interoperability program uses the same measure, but requires that the doctor provide that information any time during the calendar year. For a patient getting a colonoscopy done – I don’t think the distinction in payer has much clinical value. Getting rid of this kind of white noise in the various quality programs that CMS has established would be a leap forward. It just confuses people.
Next, the plan reinforces that the government will continue to invest in value-based programs. It especially calls out the role of incentives. It also calls out the need to build interoperable technologies. These two call-outs are related. Prior history teaches us that when ONC and CMS push for new technologies to be developed and deployed, they integrate them into preexisting and new payment models. Generally, you’ll see ONC phase in new certified capabilities that developers must deliver to their customers. However, certification is fundamentally modular, so where’s the incentive for the developers to make this stuff and certify to it? CMS will incent the healthcare providers to use those capabilities through various means, including:
- Making those capabilities mandatory conditions of participation in different payment programs;
- Assessing how providers use these capabilities in payment programs as a measure of reimbursement; or
- Requiring the use of these capabilities as a condition of Medicare, Medicaid, or any other federal healthcare program.
For example, the Comprehensive Primary Care Plus program incented the development of certain technology in excess of what the 2015 Edition of Certified EHR Technology calls for (the most current edition on the market). The EHR Incentive Program required the implementation of certified EHR technology. Under MIPS, you might face a 25% reduction in your score (and potentially face a penalty in later years) for not using an EHR. Other programs require different types of reporting, including at the “population level.” Some programs leveraged in Medicaid, like Patient-Centered Medical Homes (“PCMH”), may give you some credit for using certain technologies during the application or recognition process.
Expect more the same, except now instead of just “certified EHR,” you’ll likely see measures that emphasize patient access to health records, the implementation of APIs that allow third party applications to ping your EHR for patient data pursuant the patient’s “consent,” and programs that encourage the population level aggregation of data. Will any of this make a difference in terms of denting the cost and quality curve in the United States? Frankly, I am a little doubtful. I don’t see the patients driving up healthcare costs suddenly getting healthier because they send their health data to an app on their phone. I think the healthcare crisis in this country is much deeper than that. However, you can sure bet that you will be measured on it and reimbursed on it: so, it is something you should pay attention to.
What should you do now? First, comment! Officials from CMS and ONC say, and I take them at their word on this, that they read every comment. Let them know what you think. Some particularly good areas to consider are privacy and security concerns (which exist), where you’ve struggled the past few years with respect to workflow driven by technology, and the financial and clinical ROI of prior programs. These can at least give the agencies a sense for what may have gone right and wrong in the past five years as it contemplates the next five. Remember, the people at these agencies are people. They don’t know 100% of what they don’t hear. Don’t take it for granted they’ve heard your perspective. You can submit a comment directly through this link:
https://www.healthit.gov/topic/2020-2025-federal-health-it-strategic-plan
Comments are due March 18, 2020.
What are some other considerations? Well, you need to be careful in how you select your health IT vendors. I have seen contracts that run the gamut (one of Epic’s was recently in the news). There is TREMENDOUS room for improvement on the healthcare provider side. The most important thing to realize that the technology you are buying today may not be up to snuff for what you need tomorrow, especially as a lot of rules are in draft status. Even then, this is a five-year outlook. Even once the CMS and ONC interoperability and information blocking rules are finalized this spring, more are coming. Nobody should expect that brace of regulations to be the government’s last hurrah into interoperability and information blocking. How do you write that into your contracts? One critical area is defining your needs and revenue strategy. From there you can form an opinion on what these programs mean to you. Dollars wise, the past is probably a good indicator of the future. How game are you for shared savings, percentage increases on your FFS reimbursement, capitation or partial capitation, etc, in exchange for deploying new technology to your patients? What are the basic requirements going to be for participating in Medicare and Medicaid? From there you should be refining your specification sheets to at least anticipate what’s coming down the pipeline: capabilities related to APIs, patient access, and different levels of reporting (as well as different standardized vocabularies and data sets). These really should be considered in your RFPs today; it’s not far off the horizon.
Read the plan. In the health IT space, the government tends to signal its intentions. That’s what this document is doing. We’d all be well off by taking the government at its word. APIs, information blocking, interoperability, and integrating all of that into value-based programs is important to the government. It’s coming, get ready.
eHealth Law Blog 