Takeaway: New rules mean new markets for AAPL, AMZN and a host of small HIT developers; disruption for UNH, CI, HUM and ANTM and moat filling for CERN

The long-anticipated rule on data blocking and interoperability is out and it did not disappoint. There are new market opportunities for AAPL, AMZN and HIT solutions small and large; threats to UNH, CI, HUM and ANTM; and a lot of moat filling for CERN, Epic and major health systems, especially the NFPs. The VC/PE opportunities seem endless. As is often the case when a major new policy is implemented, the thing to watch will be how strongly incumbents resist the change and what consequences result.

Last week, the Office of the National Coordinator for Health Information Technology released its long-awaited rule on interoperability and data sharing as required by the 2016 21st Century Cures Act. The release was timed to coincide with the opening of the HIMSS Conference in Orlando, FL. What happened next is unusual in federal health policy; almost everyone seems pleased with the outcome, except perhaps Epic founder, Judy Faulkner.

Proposed Rule.

The ONC is using its HIT certification process to create standards for interoperability, patient access and information blocking that will be uniform across the HIT sector. One of the most important changes is a redefinition of the data set that will be exchanged and thus establish interoperability. Currently, the 2015 Edition for Certification of Health IT calls for use of the Common Clinical Data Set. The CCDS is much maligned because it does not include clinical notes. Under the new standard, known as the US Core Data for Interoperability, clinical notes including consultation, progress, discharge, laboratory and imaging narratives, are required elements.

Other Certification Criteria. The proposed rule amends the 2015 Edition Certification Criteria for Health Care IT vendors. Vendors will be required to meet and maintain seven new Conditions of Certification. These condition categories are:

  • Information Blocking
  • Assurances
  • Communications
  • APIs
  • Real World Testing
  • Attestations
  • EHR Reporting Criteria Submission (TBD)

Information Blocking, Assurances, Communications. The first three of these categories are meant to address certain business practices adopted by EHR vendors and health systems. EHR vendors and the health systems that use them have put in place information blocking strategies and contractual gag clauses the limit competition and encourage consolidation.

Under the new certification system, EHR vendors will be prohibited from taking any action that constitutes information blocking, including gag clauses and vague or sweeping NDAs. Vendors would have to provide assurance to the Secretary of HHS that they were not engaged in any prohibited practices. To put teeth in that requirement, Congress authorized the Office of the Inspector General to enforce these provision and apply Civil Money Penalties as appropriate.

According to a 2017 study published in the Milbank Quarterly, the most common forms of information blocking used by EHR vendors are:

  • Deployment of products with limited or no interoperability
  • High Fees for health information exchange unrelated to cost
  • Difficult access by third parties to standardized data
  • Lack of support for health information exchange with specific vendors or exchanges
  • Difficult data export
  • Revisions to contract terms after implementation
  • Unfavorable contract terms for health information exchange
  • Gag clauses imposed on providers

CERN, AAPL, AMZN, UNH, CI, HUM, ANTM | INTEROPERABILITY AND DATA BLOCKING RULE: MANNA FOR VCs - Slide1

The information blocking prohibition will also apply to health systems and providers. Providers will be barred from limiting access to data by patients and other providers . The same Milbank study found that health systems have their own strategies for limiting information flow.

CERN, AAPL, AMZN, UNH, CI, HUM, ANTM | INTEROPERABILITY AND DATA BLOCKING RULE: MANNA FOR VCs - Slide2

Application Programming Interface. Aside from the information blocking provisions and the new USCDI, the next most important feature of the new certification standards are the requirements for APIs. The rule will require developers to support API related services for data on a single patient and multiple patients.

The API certification criteria would grant a provider the sole authority and autonomy to permit API users to interact with the technology deployed by the provider. In other words, the HIT vendor would be unable to deny access necessary for the development and use of an API service. That decision would be made by the health system or other provider.

The ONC proposes to set boundaries on fees HIT vendors can charge for the development of API services. Under the new criteria, vendors will only be able to charge fees that are reasonably associated with the costs of providing the necessary services. HIT vendors may also charge for “value-added” services that would interact with the API technology.

Real World Testing. HIT vendors will be required as part of the certification to have successfully tested the “real world” use of the technology for interoperability in the type of setting in which the technology will be marketed.

Attestation. HIT vendors must provide an attestation to compliance with the Conditions and Maintenance of Certification to the Secretary of HHS.

Effective Date. The new certification criteria are generally effective about 24 months after the rule is finalized. Within six months of the issuance of the final rule, HIT vendors will be prohibited from enforcing communication or contract provision that contravene the rule.

Impacts

HIT The implications to CERN, MDRX and Epic are not immediate. There is a 24-month phase in for many provisions, save the prohibition on gag clauses and similar communication limitations. In the near term, the vendors may benefit from some API-related fee income.

In the long term, however, the ONC rule fills in a few industry moats like limiting interoperability and maintaining a closed loop of compatible functionality. The rule declares the data acquired by health systems to be theirs to control (except for patient data – more on that in the next note.)

The future state of incumbent HIT vendors may be that of a low margin commodity-type service with differentiation determined by app developers and their provider-partners.

The rule also encourages uses of data that heretofore had been difficult to scale. For example, AMZN, which provides storage services to many HIT vendors, has pushed into automated analysis of medical records as part of a pilot in the Pacific Northwest. The availability of clinical notes as a data element will create the uniformity necessary to scale AMZNs efforts for the purposes of medical research and predictive analytics.

It probably won't happen soon enough or be material enough to overcome the retail reckoning in 2019, as Hedgeye's retail team has discussed (ask sales@hedgeye.com if you need to know more). AMZN's policy - a result of HIPAA - that the clincal data stored on AWS servers belongs to the providers and not AMZN means new entrants are a likely consequence. (Attention VCs!) That same policy, and the broader implications of HIPAA will also make it difficult for AMZN to make much headway leveraging health data into the sale and delivery of retail medical items and services through their platform.

AAPL is going to have an easier time of it. They have a headstart with the Apple Health Apps that are affiliated with about 200 providers in the US, including Adventist, Partner and Geisinger and have recently announced a project with Veterans Affairs. Their position on data privacy has generated a level of trust that is not shared by Android users but critical to encouraging adoption. Like AMZN, APPL's move into health is not going to overcome weak IPhone sales in their near future but there is no denying they will have a role in shaping the future of HIT.

Health Systems. Anecdotally, the information blocking strategies of health systems combined with the high cost of installing and implementing an EHR appear to have contributed to these systems’ acquisition of physician practices and their consolidation with other systems.

>chart3>

CERN, AAPL, AMZN, UNH, CI, HUM, ANTM | INTEROPERABILITY AND DATA BLOCKING RULE: MANNA FOR VCs - Slide4

Not so anecdotally, care integration has been a major reason d’etre for hospital mergers, second only to the laughable cost-reduction-due -to-greater-efficiencies argument. As Tsai and Jha point out in a 2014 JAMA article, cited in the ONC rule:

The second argument advanced by advocates of hospital mergers is that mergers can lead to greater “integration” of care, which can be especially helpful in managing the care of chronically ill patients. However, consolidation is not integration. Clinical integration requires meaningful data sharing, systems for effective handoffs, and streamlined care transitions. These processes can be achieved through other mechanisms, such as participating in health information exchanges…Care integration results from the sharing of clinical information with all who might care for the patient. Larger systems may be less motivated to join health information exchanges, assuming that they already capture a large proportion of patients' clinical information internally. In such instances, hospital mergers may create new islands of data in which information is seen as a tool to retain patients within their system, not as a tool to improve care.

The FTC Act limits the ability of the FTC to interfere with certain practices by nonprofit hospitals which can have the effect of anti-competitive behavior. One of those practices includes building networks of affiliated, but not owned, providers on the same EHR system. Information blocking strategies used by major health systems encourage participation in these networks. Because it would be difficult for affiliated providers to extract themselves from the network due to the dependency on a shared EHR system, these networks can have the effect of a merger.

In its effect, the new rule would remove a major motivation for health system consolidation in name or in fact, especially vertical integration. It would also make it much easier for acquired providers to break away, especially those that have reached the end of any employment agreement.

Other Providers. The API and information blocking requirements are designed to make care coordination between different providers more seamless. An API that connects a post-acute provider with the nearby hospital means providers don’t need to rely on patient or family narratives – which are frequently wrong – or abbreviated discharge instructions. The rule also limits the necessity of repeating certain services like imaging and laboratory testing whose result is locked up in the EHR down the street.

Payers. Beside the development of MedTech, probably the most interesting impacts could emerge in the payer sector. The API service criteria permits the development of an app to access a single patient’s data or group of patients. The rule also expands the definition of Electronic Health Information beyond what is considered PHI to include billing and payment information.

A major employer in a particular region, for example, may work with a major health system to understand the utilization of its self-insured plan members. In turn, they could use that data to guide network decisions and educate their employees on price and quality.

Employer-based insurance is ripe for disruption. WMT announced last week, it had contracted directly with Oschner Health in Louisiana to provide spine, joint and cardiac procedures. The JPM-BRK-AMZN alliance is largely thought to include direct contracting with providers, raising the hackles of UNH which has sued. Bright Health ($950 valuation), a private insurer, affiliates with a single care partner in each of its markets to provide simplified insurance solutions for individual and small employers. Benefit Science Technologies, also privately financed, provides analysis of an employer's medical costs and makes recommendations. For all these models, the free(er) flow of data is a tailwind.

Outcome

The free flow of information immediately raises the specter of HIPAA violations, the EHR industry’s go-to defense. Epic CEO Judy Faulkner, in an interview with Dan Diamond’s Politico, responded, "Is data responsibility gone now? Are we and the health systems both to give patient data to anybody, no matter what they do with it? (It seems clear from the rule that health systems will not give patient data to anyone. API developers will have to operate under a BAA and meet privacy and security standards.)

What remains to be seen is if providers and health systems will simply pay lip service to app developers or embrace the requirements.

At a HIMSS panel discussion last week, developers pointed out that CERN requires patients to request the Apple Health app through their doctor or hospital. Another issue raised is the requirement that patients authenticate their identities through patient portals before downloading the app. Patient portals have experienced weak adoption in part because they do not always give access to the entire medical record. Another concern is that AAPL will throw its weight around, keeping new entrants from the market. This outcomes seems unlikely since 56 percent of Americans use an Android phone.

Certainly, the OIG’s enforcement authority should help focus the mind on the negative consequences. However, the ONC  and the Trump administration are motivated to prevent any more moat construction with health data. The final rule is likely to address these competitive concerns and reiterate the seriousness of data blocking. In every other respect, the rule has been so thoroughly vetted through what has to be unprecedented industry involvement, we see few changes likely.

Call with questions or better yet, thoughts on other impacts.

Emily Evans
Managing Director – Health Policy



Twitter
LinkedIn

Thomas Tobin
Managing Director


Twitter
LinkedIn

Andrew Freedman, CFA
Managing Director


Twitter
LinkedIn