CDA → FHIR without a Big Bang (Part 2): Pitfalls, quality rules, and a cutover checklist

By Friedhelm Matten · iscad-it
Abstract:
Part 2 describes why CDA→FHIR projects often fail not at “mapping” but at terminology, identifiers, narratives, testability, and governance. The article shows typical failure patterns, provides guardrails for quality (validation, test cases, monitoring), and offers a compact cutover checklist for the safe transition from parallel operation into regular operation.
Keywords: HL7 CDA, HL7 FHIR, terminology, identifiers, data quality, validation, testing, cutover, Implementation Guide

The most common pitfalls (and why they keep happening)

1) Terminology: the invisible foundation

Without binding ValueSets, mapping rules, and approval processes, “it works” quickly turns into “it works sometimes”. Typical symptom: data is syntactically valid but semantically inconsistent.

2) Identifier strategies: when references aren’t stable

CDA document IDs, internal keys, patient IDs, encounter numbers: in FHIR, referenceability becomes central. A clear identifier strategy determines whether bundles, references, and deduplicated data flows work reliably.

3) Narrative vs. structured data

CDA often carries important information in the narrative. The ambition to fully structure everything at once frequently leads to delay and quality problems. Prioritized structuring is better.

4) Overfitting: profiles become too project-specific

Profiles that are too tight drive special-case logic. Guardrail: as close to the standard as possible, as specific as necessary – with clear extension and deprecation rules.

5) Testability is considered too late

Many problems only surface once several partners implement. That is why a test strategy is needed early: examples, scenario tests, a validator pipeline, and reproducible error management.

Quality assurance as a migration accelerator

  • Conformance: validation against profiles/IG.
  • Semantics: terminology consistency (ValueSet checks, mapping reviews, approvals).
  • Completeness: mandatory fields/Must-Support per use case.
  • Stability: versioning, release notes, deprecation, backward compatibility.

Cutover logic: when is FHIR “ready”?

  1. Use-case coverage achieved (prioritized scenarios end-to-end).
  2. Quality metrics stable (validation rate, terminology errors, missing fields).
  3. Partner readiness demonstrated (at least one independent implementer).
  4. Operations secured (monitoring, support, incident process, versioning).

Implementation checklist (compact)

  1. Clarify the target picture (CDA vs FHIR) incl. ownership.
  2. Prioritize use cases and translate them into testable scenarios.
  3. Set up terminology governance.
  4. Define the identifier strategy.
  5. Version profiles/IG (releases, changelog, deprecation).
  6. Establish a test pipeline (validator, scenario tests, examples).
  7. Run a dual run with metrics and check the cutover criteria.
  8. Plan partner communication including a fallback strategy.

Conclusion

CDA→FHIR succeeds best when you work with clear patterns, governance, and measurable quality. Migration then becomes a controlled transition into a stably operable interoperability practice.