HIT Perspectives: Meaningful Use Stage3

The federal government recently released the long-awaited draft rule for meaningful use  stage 3 (MU3). Everyone is still digesting the 301-page regulation and trying to figure out what it means. We at Point-of-Care Partners  have plowed through it and done the analysis.

In short, MU3 expands some previous measures, such as electronic prescribing and clinical quality measure reporting. Moreover, MU3 significantly expands patient engagement and reporting requirements for public health entities and disease registries.  Not surprisingly, there is new emphasis on the required use of application program interfaces (APIs), which is one way for the government to address the perceived need for interoperability for electronic health records (EHRs). The comment period closes on May 29, and we most likely will see the final rule in late summer.

Here is our initial take on how MU3 impacts EHR vendors.

Where are things going? We expect the large and top medium-size EHR vendors will continue to build to the new MU3 requirements. Their business models have dealt almost exclusively with meeting MU requirements over the past few years, so they know the drill and how to do it profitably. Plus, they have 2 to 3 years to adapt. Under the proposed rule, eligible professionals (EPs) would have the option of moving to MU3 in 2017, and all EPs would begin reporting on MU3 in 2018, regardless of their previous participation.

There is the opportunity for the remaining EHRs to go where the Big Boys ain’t:  non?MU-certified products. Right now, a substantial portion of the market (between 30% and 50%, depending on which survey you rely) isn’t motivated by MU and is not necessarily looking to buy an MU-certified EHR. To be sure, a good number of those are hard-core resisters who have not bought EHRs because they don’t perceive a return on the investment and thumb their noses at government mandates. Yes, they will be hard to convince. However, the world of electronically enabled health care is not going away and even the laggards know in their heart of hearts that they must eventually adapt or quit practicing. They can be won over if presented with the right mix – heavy on easy-to-use functionality that complements the work flow, instead of controlling it, and at the right price.

Many opportunities for smaller EHR vendors are created by the non-MU crowd that are focused less on government incentives and MU and more on how EHRs can be integrated into their work and work flow. The needs of small and specialty practices aren’t well met by one-size-fits-all solutions, so there is opportunity from practices that are disenfranchised with their existing EHRs and those that have not yet adopted.

What about those APIs? We’ve had a strong hint that APIs were on the horizon for MU3 when their use was recommended heavily in last year’s JASON Report, by federal advisory committees, and the Argonaut Project, which seeks to make health data sharing easier by using Internet-based open messaging and documents standards.

According to the Webopedia, an API is a set of routines, protocols and tools for building software applications. It specifies how software components should interact and makes it easier to develop a program by providing all the building blocks. Many operating environments provide an API so programmers can write applications that are consistent. APIs are also specified by websites. For example, Amazon and eBay APIs allow developers to use the existing retail infrastructure to create specialized web stores. Third-party software developers also use Web APIs to create software solutions for end users.

So, what about APIs in health care? The Centers for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator for Health Information Technology (ONC) hope developers will create low- or no-cost APIs to facilitate interoperability across EHRs. MU3 requirements for expanded patient engagement are aimed at fostering entrepreneurial API developers that are looking to break into healthcare through this market. Venture capitalists seem ready with open wallets. According to one estimate, for example, digital health funding skyrocketed to $5.3 billion in the first three quarters of 2014.

We believe the bigger question is not one of APIs but the business rules around them. That could play out in several ways. Analogously, there are two basic models in the smartphone development marketplace. Apple tightly controls developer access to its infrastructure and only allows approved applications (apps) to be available in its environment. It is a pay-to-play proposition for developers, with Apple keeping a percentage of revenue. The Android market is much more free-floating; there is no entity acting as a traffic cop and revenue sharing is not mandatory. The latter model is less costly to administer, which may appeal to the government, but provides less quality assurance for each app. Who will decide how it goes: the market or the government? And what about liability? If your $0.99 game app doesn’t work you can delete it with little risk. What happens if your health care app misfires and a patient is harmed as a result?

Many other questions will also need to be addressed. For example, is ONC certification of APIs enough to ensure that it doesn’t become the “Wild West” out there? (See details in ONC’s 2015 draft certification rule.) By the government’s implied admission, previous EHR certification efforts were not fully successful in creating interoperability. Will it be any different with APIs? Then, there are standards. APIs may use open source as well as standards that are not mature and/or proprietary. How does their required use in MU3 relate to the standards development process and interoperability down the line? Another question concerns how EHR vendors and consumers will be protected so they are not left holding the bag if API developers decide to substantially increase prices or suddenly go out of business. Will this create an expanded role for ONC or a void for another entity to fill, such as a stakeholder coalition? What about privacy and security? Will there be an appetite for an explosion of APIs or will the dearth of business rules make an already confusing and complex environment even more confusing and complex?

Patient engagement. Payers, including Medicare, have come to realize that when providers interact directly with patients, better outcomes and lower costs ensue. MU3 supports that premise and is seen to dovetail with many value-based purchasing programs being created in the public and private sectors. Coupled with the requirements for APIs, MU3’s emphasis on patient engagement opens the door for those entrepreneurs and investors who are rapidly discovering the potential in patient-facing health information technology. We’re already seeing an explosion of wearables, in-home monitoring, health applications for smartphones and other technology-enabled ways for patients (and their authorized representatives, which is a new MU3 requirement) to weigh in on their health care. EHR vendors must decide how they want to become involved in the patient engagement environment — in terms of technology and content. API developers will require access to EHR data to help providers target interventions and educational opportunities. Some would like to capture the “digital exhaust” (valuable consumer information) for other purposes, such as providing aftermarket solutions to pharmaceutical companies or their own data analytics endeavors. EHR vendors will need to decide policies, costs and technology so as to ascertain how such and under what circumstances access can be realized. Privacy and security issues will need to be addressed.

Public health and disease registry reporting. MU3 expands requirements for reporting to public health entities and disease registries. These requirements specifically address how EPs must actively engage in immunization registry reporting, syndromic surveillance reporting, case reporting, public health registry reporting, clinical data registry reporting and electronic reportable laboratory results reporting. This represents a major shift for EHRs, the variety of entities involved in reporting and the types of data that must be exchanged. APIs may be applicable to help streamline such reporting. There is also an opportunity for smaller EHRs to fill reporting voids that exist for certain specialties. Other opportunities include helping states and others in charge of these registries and public health functions to respond to the influx of data coming across their thresholds from providers’ EHRs.

The bottom line. MU3 introduces only a few new requirements for providers while ratcheting up achievement levels of measures from previous versions. From a certification perspective, EHR vendors are faced with a slew of new certification, standards and technology requirements, such as APIs. Certification, especially in the face of waning interest in MU among physicians, remains a significant cost of doing business for EHR vendors — the opportunity cost of which is innovation to make EHRs easier to use.