In a series of EHR Certification and Meaningful Use programs since 2010, US national policy has driven toward better consumer access to clinical data – first through online portals; then through downloadable documents; and most recently through APIs that enable third-party application access. This technology is enabling consumers to connect apps like Apple Health or MyFHR to their health records, helping individuals understand their health and shop for better care. API access is expanding, but key struggles include:
-
App registration does not scale. Today, connecting an app requires not only permission from a patient, but also (as a pre-requisite), two additional hurdles that limit the ability for apps to scale: registration with an EHR vendor and approval by a healthcare provider organization. These two steps mean that apps must seek approvals from institutions that may not share common values or business incentives. The first hurdle should be addressed by ONC's final rule on EHR Certification; the second hudle might be addressed by ONC's final rule on information blocking.
-
Permissions are coarse-grained. Today, most apps connect to a health record with coarse-grained permissions (e.g., “share all of my data” or “do not share”). This pattern leads patients to over-share, or limits consumers to using apps in which their place a high degree of trust. There's work kicking off within Argonaut 2020 to define more granular permissions ("scopes").
-
Connections are one-by-one. Consumers must remember where they’ve received care, and must obtain patient portal credentials from those providers as a prerequisite to enabling API-based data access.
Note that none of these barriers is insurmountable. Indeed, considerable regulatory effort has gone into ONC’s final rules for EHR Certification and Information Blocking, especially to address app registration issues. And one-by-one connections seem to work reasonably well for financial data aggregators like mint.com.
Still, providers are gaining more frictionless access to cross-organizational data via B2B networks (described below). We should make sure that the consumer experience is just as straightforward. In other words, it’s unfair to give providers scalable data access while forcing patients to connect piecemeal (portal- by portal).
Dating back to the initial round of EHR Certification, ONC has promoted a vision of B2B data access that allows healthcare providers to easily look up data about their patients across the provider ecosystem. Prominent efforts toward this vision include “The Direct Project” (to enable secure e-mail-based data exchange among providers who participate in the same “trust network”) and “The Sequoia Project” to enable a federated cross-organizational query platform.
ONC in 2019 funded The Sequoia Project as the “recognized coordinating entity” of a nation-wide Trusted Exchange Framework and Common Agreement – that is, a network of networks aimed at enabling nation-wide B2B query-based exchange. The fundamental functional capability of the network is to allow one provider to submit (to one or more outside facilities) a query for available documents about a given patient. Notably out of scope are capabilities like stable cross-organizational patient identifiers or centralized record-location services. This means that patient matching is often ad-hoc and demographics-based, and queries are often sent only to nearby facilities (or to facilities where a patient is known to have been seen in the past). It’s an imperfect solution, but it’s beginning to work at scale in networks like CommonWell (a cross-vendor exchange network) and CareEverywhere (a network of Epic sites around the country, with ~100% coverage).
Today, these networks are B2B constructs, and nearly all participants are healthcare provider organizations. One or two participants in CommonWell are consumer-facing app, which establishes a pattern of B2B2C data access. It’s unclear how much traction these apps (offered by companies that are not household names – like Replete Health and OneRecord) will see.
However, the design of the TEFCA network (with no centralized support for patient identity and no centralized management of user accounts) means that the entire network must deeply trust every participating node. Effectively this implies that each node has the technical ability to broadcast any query (otherwise put, each node runs in “god mode”). The protections are largely policy-based, meaning that an app developer is expected to:
-
Perform any identity proofing necessary to ensure that the consumer using the app is the same person whose demographics are passed into the network as a data query
-
Limit queries to those appropriate and requested by authorized end-users
While certain apps will rise to this level of trustworthiness, the network overall becomes more susceptible to privacy breaches as the number of “god-mode” TEFCA-integrated apps grows.