Revisiting the Issue of Health Data Interoperability Amidst ONC Rule Pushback
Epic, the largest electronic health record (EHR) company in the nation, raised some eyebrows (and ire) recently when it launched an aggressive campaign to block finalization of the Office of the National Coordinator for Health Information Technology (ONC) rules mandating interoperability across electronic health records and software applications. They have been joined by sixty (60) health care systems urging ONC to re-evaluate the rule, citing concerns for patient privacy, data security, and transparency as to how such data may be used.
The controversy and public discourse over what had previously been a largely non-political issue has provided an opportune moment to revisit the broader issues surrounding lack of data interoperability.
Understanding the Problem of Health Data Interoperability
Health care is a data-driven industry. The ability of providers to deliver the right care, at the right time, and in the right place to a given patient is dependent upon the completeness, accuracy, and accessibility of the data available. Data is also the recognized, indispensable lever to implementing and sustaining the delivery of value-based health care. CMS Administrator Seema Verma highlighted this point in her address at last year’s Healthcare Information and Management Systems Society (HIMSS) conference, observing that, “Technology and the sharing of data underpin the entire move to innovative payment mechanisms in healthcare. Without effective, open data sharing, providers cannot keep patients’ healthy. Without data to track patient progress or understand quality….[payers] cannot tie payment to outcomes.”
However, as in all things in the U.S. health care system, data interoperability, or the ease with which a patient or their provider can access and utilize their health record, is highly fragmented. While there is now broad adoption of electronic health records (EHRs) among providers, the exchange of patient data across providers (and specifically outside of a given health system or network) is sluggish at best. Research indicates that less than a third of hospitals have implemented the technical and administrative infrastructure necessary to exchange and integrate external data sources into any patient’s record, with only about 18% of hospitals incorporating this functionality on a regular basis.
Patients face similar barriers when seeking access to their own data. Patient access is often limited to patient portals which are restricted to a given health system or provider, preventing them from easily pulling and integrating data from multiple sources or providers.
The lack of data interoperability is not, by and large, an issue of technology capability. To paraphrase the tagline of The Six Million Dollar Man, we have (or can develop) the technology. And that technology can be used to make our health care system better, stronger, and a little less labyrinthine. Data inoperability is, instead, primarily due to a lack of market alignment and inertia in the face of competing market interests and defensive misapplication of regulatory regulations.
Put more plainly, Health data is valuable and can be used to leverage a vendor or health system’s market presence. However, who can access health data, when, and for what purpose is highly regulated. The financial and reputational risk associated with impermissible disclosures or data breaches can be financially and reputationally ruinous. This creates a significant chilling factor on a health systems’ willingness to engage in data exchange and innovation outside of their own, tightly controlled environments.
The end result? Market stakeholders, including vendors such as Epic and health systems, either out of an interest in preserving competitive market advantages or in response to a highly defensive regulatory or corporate culture, are largely unable or unwilling to engage in the development necessary to deploy these tools to exchange electronically in the absence of an external force. ONC’s proposed regulations which mandate an interoperability framework serve as said external force and catalyst. In the following section we look at the two primary ways that ONC’s proposed regulations flip the dynamics that favor “data silos” to a paradigm that presumes inter-organizational data sharing.
A Framework for Interoperability
Addressing Technical Barriers and Mandating Exchange
ONC’s proposed rules draw heavily from HL7 FHIR (Argonaut Project), an academic and private sector initiative dedicated to developing Fast Healthcare Interoperability Resources (FHIR) and standardizing exchange specifications with the aim of enabling exchange of electronic health records. Central to FHIR is the utilization of Application Programming Interfaces (APIs) that provide a communication protocol or portal between multiple systems that may operate on different platforms.
Under these new regulations, to be eligible for EHR-certification (a prerequisite for participation in Medicare and Medicaid value-based programs and, thus, a functional necessity) EHR vendors will need to develop and deploy APIs to electronically export all of a patient’s medical records under management in an electronic, computable format and including documentation to allow for interpretation and use of the electronic health information (EHI). Note the emphasis on “all” here. The regulation provides a timeline of two years for developing, deploying, and demonstrating the efficacy of the exchange interfaces. Prospective Data “receivers” (i.e.: smartphone app developers) have that same timeframe to demonstrate that they meet more stringent API certification components assuring the security of these transfers.
Expanding the Common Data Set
A central tenant of the proposed regulations is empowering patients to access and direct the distribution of their own data. However, the pending regulations also expand the common data set to facilitate direct and routine exchanges between providers. To this end, ONC’s rules expand the definition of the common clinical data set to include, among other more discrete tweaks, all clinical notes. Integration of clinical notes into the common data set means that recipients of data essentially will, for all intents and purposes, have access to the complete health record. Inclusion of clinical notes means that the data recipient has data that represents the patient at that point in time as well as all “touches.” This is important for providers as they make point of care decisions.
The graphic below, which is from ONC’s fact sheet on the proposed regulation, breaks down the expansion of the common data set to include its new requirements.
In addition to mandating the exchange of EHRs as directed by patients and their providers, the regulation limits the fees that EHR vendors can impose on users for the use of these API exchanges. Such fees must be “reasonable” and based on an objective, verifiable criteria which is tied to the actual cost of development of the new software and equally applied across all (or “substantially similar”) users. As such, fees imposed cannot constitute anti-competitive practices and will be under scrutiny as to whether they constitute indirect “information blocking.”
A Prohibition Against Data Blocking
That brings us to what may be the core element of the regulations: Data blocking. Data blocking (or “information blocking” as termed in the regulations) is defined as “a practice by a health care provider, health IT developer, health information exchange, or health information network that, except as required by law….is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.” As demonstrated by the definition above, data blocking may fall into the ambiguous category of “we know it when we see it,” to quote Supreme Court Justice Potter Stewart on the difficulty of defining pornography in Jacobellius v. Ohio. Given the challenges of defining data blocking, recognizing the legitimate and important reasons why information may be withheld, ONC has instead focused on what data blocking is not as evidenced by seven expansive exemptions, including:
Where the action is taken on a reasonable belief that it is necessary to prevent physical harm to a patient or another person. To qualify for this exemption, the actor must reasonably believe withholding of the data will “directly and substantially” reduce the likelihood of harm and this determination must be based on an individualized assessment.
Where the action is necessary in order to protect the privacy of EHI in conformity with federal and state privacy regulations or to give effect to an individual’s expressed privacy preferences.
Where the action is necessary to promote the security of EHI.
Where action is restricted to recovering costs reasonably incurred in the providing access, exchange or use of EHI.
Where the requested action or exchange is infeasible, such that it imposes a substantial and unreasonable burden on the data holder. Where this is the case the data holder must cooperate with the requestor to develop reasonable alternatives.
Where the action is restricted to licensing of interoperability functions insofar as licensing or terms of use are reasonable and applied on a non-discriminatory basis.
Where the action is necessary to maintaining and improving Health IT performance, insofar as availability is temporary and of limited duration.
Actions that do not fall into these exemptions are at risk of being deemed as information blocking. In those instances data custodians could be subject to civil penalties (amounting up to $1,000,000 per violation) and may be subject to further (as yet unspecified and unestablished) “disincentives” by the DHHS.
Putting Data Blocking in Context
Data blocking is not a new phenomenon and it is a problem. For example, in a 2017 study which surveyed 141 Health Information Exchanges on their perception of data blocking, respondents reported that 83% of EHR vendors engaged in data blocking occasionally (33%) to routinely (50%). Respondents indicated greater collaboration from hospitals, reporting that only 59% engaged in data blocking occasionally (34%) to routinely (50%) Hospitals.
The most common forms of data blocking by vendors as reported by respondents include:
Imposition of prohibitively high fees;
Making third party access cumbersome; and
Limited technical interoperability.
It is worth reflecting on here the very real market forces that drive the prevalence and persistence of data blocking in the face of the acknowledged necessity and urgency of interoperability. Data is valuable and, particularly for providers operating outside of a large hospital system and network (insofar as care is captured within the closed environment), comparatively scarce.
EHR vendors, with their control over the data platform and its capacity for interoperability, have developed a formidable “strategic moat” to protect their business interests. Larger EHR vendors, which have already captured a large share of a market, can solidify their market presence, and potentially increase the likelihood that other providers will select their product over competitors on the basis of the need to be able to connect with that existing framework.
Similarly, EHR interoperability, or the lack thereof, has also been tied to efforts to capture patient populations and grow regional markets. By withholding or selectively sharing patient information, health systems “create barriers that make it less likely that patients will see care elsewhere.” In this manner, EHR vendors and the health systems they serve have strategic interests that may reinforce each other in an industry marked by balkanization and consolidation.
Points of Caution and Need for Additional Action
Understanding the importance data plays in health care and how key stakeholders currently control the disposition of this data is central to understanding why ONC’s rules are so fiercely contested. While there is general consensus that ONC’s rules constitute a necessary and long overdue step in establishing greater health interoperability, it is not a final step. Proponents of the regulation recognize that this is, instead, only the first step and that a further buildout of the regulatory framework is needed.
Concerns that Epic and others have raised in regard to data privacy is one such example. In a statement posted to its website, Epic referenced lack of transparency requirements for mobile healthcare apps, arguing that the lack of regulation as to how these (non-HIPAA covered) entities access and use data means that patients are unlikely to “have the information they need to make decisions knowledgeably” as it pertains to their protected health information.
Facilitating the “frictionless” transfer of health data to third-parties, in the absence of a regulatory framework or guidance on the kind of disclosures that software developers will need to include (as well as the ability of patients to meaningfully direct and restrict how that data is used) can be a backdoor to invalidating the protections afforded patients under HIPAA. Software giants such as Google, Apple and Microsoft are leading proponents of this regulation, and are also the entities that may benefit most from the movement to #freethedata, as this move would facilitate their entrance into the healthcare industry. While the proposed regulations are necessary and urgent, it is important that they also be followed by substantive scrutiny and regulation of the playing field to ensure that patients have the access and framework they need to meaningfully exercise their right to control and restrict how their data is used.
Conclusion
At base, this is a question of who has the right to access and utilize a patient’s data. To date, the structural, technical, and regulatory framework has created an environment that has impeded patient’s ability to access and direct the management and use of their health records.
In addition to laying out the technical and structural implementation framework, the ONC rules are revolutionary in that they reverse established industry presumptions: Instead of assuming that health data shouldn’t be accessible or shared across permitted parties unless certain terms are met, these new regulations presume that such data must be shared unless a specific exemption is met. The burden going forward is therefore on the Data Provider to justify how or why any failure to provide requested data doesn’t constitute data blocking. This may just be a first step, but it is an indispensable one.