CDA → FHIR without a Big Bang (Part 1): Migration patterns that work in practice

By Friedhelm Matten · iscad-it
Abstract:
Many organizations face the same task: keep operating CDA-based document landscapes while at the same time establishing FHIR for modern interfaces, workflows, and data platforms. Part 1 presents field-proven migration patterns that reduce risk and complexity: coexistence, gradual extraction of structured content, parallel operation with quality metrics, and a clear target architecture. The focus is on decision logic and procedural models – not on deep technical details.
Keywords: HL7 CDA, HL7 FHIR, migration, interoperability, target architecture, coexistence, data quality, governance

Why “switching off CDA” is rarely the right way to start

CDA is deeply embedded in many landscapes: document processes, legal requirements, established viewers, archiving, and existing partner connections. FHIR, by contrast, addresses API-driven integration, modular data use, and modern interoperability. The mistake often happens right at the start: CDA is labeled “old” and FHIR “new” – and that turns into a big-bang project.

In practice, what succeeds is coexistence (keep using CDA while FHIR is built up in a targeted way) – combined with a clear roadmap for when which content, processes, and partners are migrated to FHIR.

A target picture that positions both worlds cleanly

A pragmatic target picture first answers what you keep using CDA for and where FHIR delivers the greatest value:

  • CDA as a document-centric exchange format (narrative, signature/archiving, established workflows).
  • FHIR for structured data use, APIs, process integration, terminology and quality rules.
  • Bridges for selected content (extraction, transformation, dual-write, or gateway).

What is decisive is that this target picture is operational: ownership, versioning, tests, monitoring, and partner communication are part of the architecture – not “later”.

Five migration patterns that avoid a big bang

1) Coexistence (“CDA stays – FHIR complements”)

You start with FHIR where it delivers value immediately (e.g. new systems, new integrations, new use cases) and let CDA keep running stably for existing document flows.

2) Extraction pattern (“structure-out”)

You gradually extract structured core content from CDA (e.g. diagnoses, medication, lab results) and make it available in FHIR – without immediately rebuilding the document flow.

3) Gateway/facade (“FHIR outside, CDA inside”)

A gateway exposes FHIR APIs to the outside, while internally CDA-based processes initially remain in place. The advantage: modernize partner integration without rebuilding the backend right away.

4) Parallel operation with metrics (“dual run”)

For prioritized use cases, CDA and FHIR are served in parallel. Using quality metrics, the FHIR variant is stabilized step by step until a cutover can be carried out responsibly.

5) Greenfield-first (“new processes on FHIR only”)

New applications and new exchange processes are built consistently on FHIR. Legacy processes keep running in CDA until they reach a natural point for rebuilding.

What you should decide before you start (short checklist)

  1. Which use cases deliver the fastest value with FHIR?
  2. Which CDA content is “critical” (legal, clinical, partner-related)?
  3. Which terminologies become binding (ValueSets, mapping, governance)?
  4. Which quality metrics decide on the cutover?
  5. Who is the owner for profiles/IG, releases, and partner communication?

Outlook on Part 2

Part 2 focuses on typical pitfalls: terminology and mapping debt, identifier strategies, narrative vs. structured data, test automation, and a practical cutover logic – including a compact implementation checklist.