HL7 CDA and FHIR

An email from one HL7 member wrt to HL7v3 methodology had been spawn into a long discussion and debate w.r.t to "Message" and "Document" again, the intended use and actual use of HL7 CDA, what has been the critical success factors of HL7v3 CDA, and its relationship with FHIR (Fast Healthcare Interoperability Resource) Grahame has started last year out of HL7 fresh look task force initiatives.

We had the same long debate Nov 2011 when a question raised with regard to the use of CDA in IHE Lab.

This time I felt we have at least reached some consensus on HL7 CDA's success factors, and clarified some of the confusions some of HL7 members (including myself) had in the past towards FHIR.

1) What's the success factor of HL7 CDA

The consensus is that the key difference between V3 CDA and V3 Messaging is not that one is about documents and the other is about messages, that's the business side of the equation. But it is the fact that CDA uses a single fixed schema from technical design/implementation perspective, this is really the primary basis for its attractiveness to implementers.

HL7 CDA is "One model and one Schema" with its well-documented templates for the details esp. with the introduction of Consolidated CDA, now it is even much easier to search for CDA templates.

In fact that's also the key messages I have been articulating within HL7 for the need to ensure wire format stability back in 2010

I am not commenting on whether we should keep wire format compatible between CDA R3 and R2, if there is valid technical reason to break the compatibility, then we have no choice even if HL7v3 has promised wire format compatibility.

However what I am trying to say here is the wire format stability/compatibility is extremely import for standards adopters, without stable/compatible wire format, we won't even achieve the basic syntactic interoperability let alone semantic interoperability in the long run.

So if we have to break the compatibility for CDA R3, we'd better think carefully and for the long term, maybe we also should rethink the goal and design approach of CDA, why not we just take out the rending part from XSD and put into XSLT for rending and use the new RIM ITS to provide single unified wire format, we should try to solve the problem once and for all if we have to break the compatibility.

2) What's the relationship between FHIR and HL7 CDA

I brought up the concern that whether we will run into the debate "CDA" and "FHIR" if we do not harmonize the development of CDA R3 and FHIR since I have been hearing that FHIR will eventually render the discussion of "Message" and "Document" irrelevant.

The below messages from Lloyd perfectly stated the differences between HL7 CDA and FHIR, and the benefits FHIR will be bringing to us.

There are a few differences:

- A single RMIM in today's methodology will often break down into multiple resources under FHIR

- There are an unlimited number of potential RMIMs under the current methodology, while there will be on the order of 100 resources defined total

A more apt comparison might be to look at each of the acts and roles on the right-hand side of CDA and consider each of them to be a resource. Rather than having one schema for the entire clinical statement, we now have a separate schema for each of the major pieces of the clinical statement. (In practice there will be more resources than there are acts and roles in the clinical statement because things like lab order & lab result will be distinct resources.)

Another difference with FHIR is that it will generally be possible for implementers to figure out how to assemble resources to represent a particular construct independently in a consistent way without needing templates. That doesn't mean there won't be a need for templates and profiles in FHIR, merely that they aren't as critical to get started as they are with CDA or other v3 models that rely on Clinical Statement and similar abstract structures.

The number of resources comes from an enumeration we did based on all of the domains and CMETs, RMIMs and domains. There will likely be a few more over time, but I'd be extraordinarily surprised if we ever get to 200, even 20 years from now.

The FHIR resources will *definitely* have stability. Grahame and I are debating right now how stable - specifically whether it's possible for extensions to ever move into the resource proper if they become popular. But everything that's in a resource will remain at that same x-path forever.

When resources reference other resources, they do so by internal id. The resources don't actually nest. So the overall schema is just a list of resources - and it will support any and all resources because anyone might use an extension that includes a reference to some resource that wasn't defined as part of the main package. There will be no multiplication of schemas based on the different combinations because all combinations need to be supported everywhere - and that's just an arbitrary list of resources. (Your conformance profile tells you what ones *must* be present for a given scenario.)

I know there's been discussion about using FHIR for CDA R3, and I'm definitely in favor of that direction. I think there are benefits for both CDA and HL7. However, that's a topic for structured docs to decide. The 2.1 decision gives us the breathing room to do a proper evaluation. In any event, I don't think we can brand FHIR as being just CDA. The branding message needs to be inclusive of those who aren't interested in documents (e.g. medical device vendors). Though it's possible that CDA R3 might become CDA FHIR or FHIR CDA or something. (A change in label to signal the change in backward compatibility might be appropriate.)

FHIR carries forward the essentials of CDA:

- Stable XML structure

- One schema for everything

- Ability to send both textual representations and discrete data for the same content

- Partitioning of discrete data into simple constructs (entry = resource, more or less)

It also carries forward some essentials of v2:

- Data structures built from a countable number of standardized structures (you can think of a resource as a segment)

- Message paradigm still supported and works much as it does in v2

- Guaranteed wire format backward compatibility

- Standardized way to communicate extensions

But it fixes some of the issues with CDA:

- Wire format is intuitive to implementers out of the box (implementers don't have to know the RIM or ISO datatypes exist, no structural codes to ignore or get wrong)

- Don't *have* to have templates in order to use FHIR productively

- No need to create custom "intuitive" wire formats per template or per use-case (as is the case with Green CDA)

- Extensibility doesn't require messing around with namespaces or breaking schema validation

- Extensions tell you whether you can safely ignore them or not

- Templates used for CDA can also be used for message, service and REST paradigms (and vice versa) because wire format is identical

And issues with v2:

- Specification doesn't get cluttered up with esoteric use-cases (e.g. the PD1 segment :>)

- Extensions are clearly defined and registered, so no more black-box Z-segments

- You can do XML with tag names that aren't butt-ugly :>

- You can work with a structure that's actually object-oriented