Healthcare
Care Coordination on FHIR: The Case for API-Based Exchange
Care coordination depends on every provider seeing the whole patient record. Document-based exchange can't get us there. API-based exchange on FHIR can.
Effective care coordination depends on the ability of multiple providers to have access to a comprehensive view of each patient’s medical record. Yet patients today are surrounded by a flurry of health-related activities, and those disparate activities cause fragmentation of the record. Higher levels of community care, increased use of telehealth, and more frequent use of patient-generated data — from mobile apps, for example — each create separate but important pieces of the complete patient record.
Providers and patients both need safe, secure methods of exchanging health information so that correct, complete data is available to the care team. You want your doctors to have access to the whole puzzle of your health information, not just pieces of it.
Where document-based exchange falls short
Document-based health information exchange transmits data using standardized formats such as Consolidated Clinical Document Architecture (C-CDA) documents, sent via protocols like Direct Secure Messaging. It can accomplish exchange — but protocols like Direct are not widely adopted, and the use of standard document types leads to inefficiencies and the transfer of extra, unneeded data. Significant effort is required to adapt document-based exchange to systems that don’t support it natively.
As a result, while standards-based document exchange fits certain healthcare scenarios, it is not ideal for large-scale care coordination.
What API-based exchange changes
This is where API-based health information exchange comes into the picture. It provides a method for secure, efficient exchange where document-based approaches fall down. It does not rely on transport methods that aren’t widely adopted — it uses instead the same web standards that support most internet applications. It avoids the inefficiencies of translating data into documents, and exchanges only the information required by the transaction. APIs are easily adapted to work with systems that do not have native support.
By now, most of you know about Fast Healthcare Interoperability Resources (FHIR). If you don’t: FHIR is an emerging standard that provides a powerful, modular model for representing health information resources — patient, medication, allergy, and so on — while leveraging web standards (XML, JSON, HTTP, OAuth) and support for RESTful architecture. An API based on the HL7 FHIR standard is an ideal foundation for exchange. FHIR’s flexibility makes it easy to implement in systems with native FHIR support, and in legacy systems an adaptor can be created to expose a FHIR API to the older system.
The benefits don’t stop there. FHIR API-based exchange supports both provider-to-provider exchange and patient-mediated exchange. Provider-to-provider exchange lets modern systems communicate with the legacy EHRs used by community providers. Patient-mediated exchange lets patients retrieve health information from providers and other sources — such as labs — and send it to recipients of their choosing, orchestrated through a patient portal.
The through-line
Healthcare data interoperability is often complicated by local extensions to standard formats and protocols, made by most organizations to handle unique requirements. A capable rules engine can manage these local extensions when mapping data as it is sent and received, greatly reducing the custom development required to adapt legacy systems.
It’s easy to see that FHIR API-based exchange provides an effective means for supporting the data-exchange requirements of care coordination. It is efficient, relies on widely accepted web standards, and is easily integrated with legacy systems. Document-based exchange will keep its place in certain scenarios. But for the thing we actually say we want — every provider seeing the whole patient — the API path is the one that gets us there.