Carequality is not what the world needs, but it’s what the world has.
The effort to build TEFCA’s Common Agreement is on course to deliver more of what the world already has rather than what it needs. Independent and third-party developers have been clamoring for better access to data for many years. By “better,” they usually mean more consistent and computable discrete data. They also prefer connecting to the largest possible number of data holders so they can reach the largest possible number of users. The Common Agreement may not offer much help on either count.
A TEFCA-compliant network could soon enable a connection to more patient data from around the country than any other single network. Providing a single place to get credentialed and to access data from any provider or payer in the U.S. would seem to be a developer’s dream – but for a few issues.
Healthcare stakeholders should push the Common Agreement process more forcefully toward API-based access to connected data sources.
Not all developers — or industry participants, for that matter — completely understand what the Common Agreement could do. Independent developers increasingly expect API-based access to data sources. So far, the general arc of the effort has been to mimic Carequality, a document-centric set of exchange rules favored by EHR vendors and widely available to their customers. While this architecture builds on an accepted approach, it does not advance the technology basis for healthcare data exchange.
Developers would be more enthusiastic about a TEFCA-compliant network if it were a bit less document-centric. Not all developers are willing — or able — to process, interpret, and otherwise extract computable data from both CDA- and non-CDA-compliant documents, especially if the source is an organization they never interacted with in the past. The variability of document implementations makes it hard to scale as the developer connects its application to more new organizations. It may seem inevitable that the Common Agreement process will eventually produce an API specification, given the enthusiasm about API-based development and integration generally, but there is no rush.
Health IT vendors should advocate for a single on-ramp for all forms of healthcare data exchange.
According to its original ambitions, TEFCA would replace or provide an alternative to the many existing exchange networks with a single “on-ramp.” Too often, the developer must enroll its customers and users in multiple different networks — EHR vendor networks, public and private HIE networks, eHealth Exchange, public and private health ISPs, Carequality, CommonWell, dedicated and specialized HIT vendor networks — depending on the user group, required data, and functionality needed.
Developers, perhaps unrealistically, like the idea of writing an application once and scaling it across as many users and organizations as they can attract. The current trajectory of the Common Agreement — essentially, coexistence with other networks — could improve the status quo on the margins by expanding the number and variety of network participants. But it is not on track to provide a single place for developers to get themselves and their users credentialed.
Brian,
Fully agree. The “data quality problem” — which is first and foremost the lack of patient-centered longitudinality and only secondarily (but still critically) a matter of non-harmonized, heterogeneous data — is the main barrier to the emergent SaMD industry. As long as software developers have to be responsible for collecting and curating (or not!) the data ingested by their apps, the SaMD market and the huge unmet needs it will address will remain a dream.