FHIR® vs CDA

FHIR® (fast healthcare interoperability resources) provides atomic access to medical data via a RESTful API (using XML & JSON). CDA/CCD (Clinical Document Architecture) is a method of structuring a patient’s full medical history in an XML document. Being that they are both standards developed by HL7, FHIR® has many components of CDA, but they are separated into smaller more manageable pieces.

1upHealth also has a CDA to FHIR® converter and API for organizations looking make the transition to the future of healthcare data standards.

Here’s an example of what CDA document looks like and a FHIR® document.

CDA Document Example

<?xml version=”1.0″?>
<ClinicalDocument xmlns=”urn:hl7-org:v3″ xmlns:voc=”urn:hl7-org:v3/voc” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” templateId=”2.16.840.1.113883.3.27.1776″>
<!– ********************************************************
CDA Header
******************************************************** –>
<id extension=”c266″ root=”2.16.840.1.113883.3.933″/>
<code code=”11488-4″ codeSystem=”2.16.840.1.113883.6.1″ displayName=”Consultation note”/>
<title>Good Health Clinic Consultation Note</title>
<effectiveTime value=”20000407″/>
<confidentialityCode code=”N” codeSystem=”2.16.840.1.113883.5.25″/>
<setId extension=”BB35″ root=”2.16.840.1.113883.3.933″/>
<versionNumber value=”2″/>

And here’s FHIR® bundle which contains multiple resource type

FHIR® Document Example

{
“resourceType”: “Bundle”,
“id”: “33d24439-061c-4f79-b272-c03e0963a39b”,
“meta”:
{ “lastUpdated”: “2018-01-03T21:33:59.788-05:00”
},
“type”: “searchset”,
“total”: 124,
“link”: [
{ “relation”: “self”,
“url”: “http://fhirtest.uhn.ca/baseDstu2/Patient/2228/$everything?_format=json”
},
{ “relation”: “next”,
“url”: “http://fhirtest.uhn.ca/baseDstu2?_getpages=33d24439-061c-4f79-b272-c03e0963a39b&_getpagesoffset=10&_count=10&_format=json&_pretty=true&_bundletype=searchset”
}
],
“entry”: [
{ “fullUrl”: “http://fhirtest.uhn.ca/baseDstu2/Patient/2228”,
“resource”: { “resourceType”: “Patient”,
“id”: “2228”, “meta”: { “versionId”: “5”,
“lastUpdated”: “2017-07-07T16:53:11.952-04:00”
},
“text”: { “status”: “generated”,
“div”: “<div xmlns=\”http://www.w3.org/1999/xhtml\”>Generated by <a href=\”https://github.com/synthetichealth/synthea\”>Synthea</a>. Version identifier: e4694a308119e0ec381819537257a2fe7ebccb2c </div>”
},
…

You can’t see much of a difference just by looking at them; it’s more telling when you use them. FHIR, being a RESTful interface allows developers to interact with the resources by creating, reading, updating, and deleting them. CDA is traditionally used in a read only medium. When reading data, the biggest difference here is that atomic data access provided by FHIR. That means that instead of needing to transmit and parse a huge file composed of patient demographics, observations, allergies, immunizations, encounters, etc. for all 60 years of a patient’s life (the world under CDA), you can use FHIR® and make a specific request for a heart rate observation for last week and get that only.

The more modular FHIR® approach lends itself to more flexibility when developing applications for patients and providers. The CDA approach was initially intended to provide a data dump of the full medical history of a patient, but FHIR® can do that as well via the $everything query. Additionally, because FHIR® breaks up these data into smaller pieces, there’s much better uniformity than in CDA which became somewhat of a mess when processing larger documents for patients with more complex care histories. This large format also held it back from changing with the times. FHIR® has already gone from DSTU2 to STU3 in many environments because parts of it can be changed without affecting everything else.

As you can see we are biased towards the newer RESTful technology introduced to healthcare as FHIR® because we believe it’s more useful and flexible for application development. The RESTful interface comes from years of use in APIs from tech companies like Google, Twitter, and Facebook, and now we finally have it in healthcare. This will make it easier to develop apps and will naturally grow the number of creative developers and problem solvers in the healthcare space.

And if anyone is still wondering… will FHIR® replace CDA? The answer is Yes, but organizations using CDA today will be slow to move on. That’s why 1upHealth is building for the future by creating a FHIR® API development platform which supports FHIR® integrations for patients at dozens of health systems, but our patient app also supports uploading CDA documents for those systems that have yet to upgrade. If you’re building healthcare applications that need integrations with any of these health systems, the 1upHealth 1upHealth Exchange solution can give you a jump start and help you integrate your healthcare app in minutes.