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.

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

CDA

<?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"/>
	<legalAuthenticator>
		<time value="20000408"/>
		<signatureCode code="S"/>
		<assignedEntity>
			<id extension="KP00017" root="2.16.840.1.113883.3.933"/>
			<assignedPerson>
				<name>
					<given>Robert</given>
					<family>Dolin</family>
					<suffix>MD</suffix>
				</name>
			</assignedPerson>
			<representedOrganization>
				<id extension="M345" root="2.16.840.1.113883.3.933"/>
			</representedOrganization>
		</assignedEntity>
	</legalAuthenticator>
	<author>
...

And here’s FHIR bundle which contains multiple resource types

FHIR

{
  "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 FHIR API platform can give you a jump start and help you integrate your healthcare app in minutes.