Care Evolution Logo Care Evolution

Post

Interoperability

Man at computer screen looking at medical data

Beyond translation: How smart standardization unlocks the true power of your healthcare data for FHIR and quality measurement

In today’s data-driven healthcare, the promise of interoperability through FHIR (Fast Healthcare Interoperability Resources) is immense. It’s the key to unlocking streamlined workflows, advanced analytics, and crucially, accurate Digital Quality Measures (DQMs). However, much of the foundational patient data still resides in Clinical Document Architecture (CDA) files – a format known for its richness but also its complexities and its inconsistencies.

Simply “converting” CDA to FHIR isn’t enough. If the underlying data is messy, incomplete, or ambiguously coded, the resulting FHIR can inherit these problems, hindering its utility for DQMs and other critical applications. At CareEvolution®, we believe in a more intelligent approach. Our Orchestrate CDA-to-FHIR service isn’t just a translation layer; it’s a sophisticated standardization engine designed to navigate the real-world chaos of healthcare data and transform it into clean, reliable, and truly useful FHIR.

We understand that adopting new data strategies can feel daunting. You’ve likely invested significantly in your current systems and workflows. Our goal is to build upon what you have, making the transition to high-quality FHIR as smooth and beneficial as possible

Leaving no data behind: Our commitment to comprehensive conversion

We’ve learned that critical information in CDAs can be elusive, often hidden in places many other vendors or tools might miss. Our approach is designed to be exhaustive:

  • Digging deeper than discrete codes: It’s common for EMRs to omit displayName for a coded concept (like a medication) and instead embed the full description within the originalText HTML table. While some tools might only grab the code, we meticulously parse these narrative sections. So, if a medication is coded but its description, “ipratropium-albuterol (COMBIVENT) 20-100 mcg/actuation inhaler,” only appears in a referenced HTML table, we ensure this rich description is carried into the FHIR resource. This avoids the “empty” or context-poor data points that can undermine clinical understanding and DQM accuracy.
  • Handling missing codes with intelligence: When source EMRs haven’t assigned a proper code to a problem or procedure, they often still provide a text description. Instead of discarding this valuable clinical intent, we generate a FHIR CodeableConcept from the available text, ensuring that insights aren’t lost simply due to an initial coding gap.

Mastering the maze: Thriving on non-standard and vendor-specific data

If there’s one constant in healthcare data, it’s variability. We’ve built Orchestrate to be resilient and adaptable:

  • Decoding “creative” date-times: We routinely encounter dates and times in non-standard or partial formats (e.g., “2020-01”, “202001”, or even vendor-specific variations like “2022050208-0400” seen in some other enrichment vendor CDAs). Our engine is adept at parsing these variations and converting them into compliant FHIR dateTime values, complete with timezones, which is crucial for accurate DQM logic.
  • Illuminating uncharted sections: Beyond standard CDA section templates (from HITSP C32, CDA R1.1/R2.1, and IHE flavors), many CDAs contain proprietary or non-standard template IDs. Rather than ignoring these, we employ a generic mapping to extract the valuable HTML narrative content, ensuring clinical notes aren’t lost in translation.
  • Expertly navigating vendor dialects: We’ve encountered and built specific logic to handle the unique ways different EMR and HIE systems structure their CDAs. This isn’t just a minor detail; it’s often the difference between a successful conversion and a failed one, or between complete data and missing data.
    Vendor Examples of what we do
    Athena: We correctly identify lab values that might be listed as “translations” instead of actual values and reconcile problem lists where narrative text might contradict the discrete coded entries (e.g., ensuring only genuinely affirmed problems are carried forward).
    Meditech: We automatically correct invalid negationInd attributes (e.g., “N” instead of “true” or “false”), which can cause other parsers to fail entirely or miss critical negative findings.
    Redox: We gracefully handle blank moodCodes in substanceAdministration or observation entries, which would break standard CDA deserializers.
    Various HIEs & Cerner: We’ve engineered resilience against invalid data types used for physical quantity values in Labs and Vitals sections (e.g., text or HTML snippets where numbers are expected).
    Intersystems: When the xsi:type attribute is missing from an immunization’s effectiveTime (making it ambiguous), our API intelligently infers the correct type based on context (e.g., presence of <low> and <high> for an interval).
    eClinicalWorks: We adeptly handle malformed XHTML in narrative sections (e.g., <td align="Center"> vs. align="center", missing quotes, undeclared namespace prefixes like <o:p>), which would render the XML invalid for many standard parsers.
    ElationEMR/
    ZusHealth:
    We correctly process CDAs even with invalid moodCode values (e.g., “ENV” instead of “EVN“) in problem sections.
    CareContinuity CCDAs: Structured body and one or more Unstructured Components (nonXMLBody components) present in a single CDA document which goes against what is prescribed in the CDA specification. Orchestrate API is successfully able to process this, while not leaving behind any of the data in the unstructured parts of the CDA.
  • Capturing the full clinical narrative:
    • No detail too small: We ensure data isn’t overlooked, even if it’s “buried” in an entryRelationship within another entry. For example, a physician’s note for an encounter can appear as a separate linked element; we extract this into the FHIR bundle.
    • Valuable comments: Additional notes and comments, often in entry relationships and frequently missed by other tools, are extracted and mapped to appropriate FHIR resource annotations.
    • Provider context: We meticulously derive and link provider relationships (author, performer) to clinical concepts and encounters, going beyond basic specifications to reflect the nuanced ways this information appears in real-world CDAs.

Streamlined, agile, and API-first: A modern approach to FHIR conversion

When organizations look to integrate and standardize clinical data from diverse CDA sources, the chosen technical approach can significantly impact speed, flexibility, and long-term maintenance. Traditional integration platforms, while powerful, can sometimes involve intricate, stateful integrations or require extensive, pre-defined template management for each new data source or vendor variation. This can lead to longer onboarding times for new data feeds and a heavier lift for ongoing maintenance as standards and source systems evolve.

CareEvolution’s Orchestrate CDA-to-FHIR service is built on a different philosophy: a modern, stateless, API-first architecture.

  • Why stateless? Predictability and scalability.
    Each call to our API is independent. This stateless nature means easier scalability (no complex session states to manage across servers) and greater resilience. If one conversion request encounters an issue, it doesn’t impact others. You get predictable, reliable performance, transaction by transaction.
  • Why API-based? Flexibility and ease of integration.
    An API-driven approach provides a clean, standard interface for your applications to send CDA data and receive high-quality FHIR. This simplifies integration into your existing workflows and allows for more agile development cycles, whether you’re building a DQM pipeline, a research database, or a new patient engagement tool.
  • Beyond rigid templates: Adaptive intelligence.
    Instead of relying solely on a vast library of specific templates that must be meticulously matched and maintained for every CDA variation – which can be brittle and slow to update when facing the sheer diversity of real-world CDAs – our API employs dynamic parsing and adaptive intelligence. This is the engine that powers our ability to handle the vendor quirks and messy data detailed earlier. While we understand and leverage standard CDA templates, our system is architected to intelligently interpret the structure and semantics even when faced with unexpected or non-standard elements, focusing on extracting the clinical truth.

What this means for you

  • Faster onboarding of new data sources: Less time spent on custom template development or configuration for each new EMR feed or HIE connection.

  • Reduced maintenance overhead: Our core intelligence evolves to handle new variations, minimizing the need for you to constantly update a local library of templates.

  • Greater resilience to data variability: Increased confidence that you’re getting the most complete data possible, even from less common or imperfectly structured CDAs.


This API-centric, stateless, and dynamically adaptive model is engineered to reduce the friction often associated with CDA processing. It allows us to focus on the core mission: transforming diverse, complex CDA documents into a consistent, high-fidelity FHIR output that is truly primed for demanding use cases like Digital Quality Measures, without requiring you to become CDA parsing experts for every possible source.

The goal: FHIR that’s not just valid, but valuable

Producing technically valid FHIR is the baseline. However, our focus is on generating FHIR that is truly useful and reliable for downstream applications, especially DQMs. This means:

  • Robustness against real-world data: We parse messy files, handle common XML errors like unescaped ampersands, and emit warnings for data issues rather than failing the entire document.
  • IG-centric output: The resulting FHIR is structured and coded to align with key Implementation Guides like US Core, making it ready for quality measurement and other interoperability use cases. For example, in a recent internal test, we ensured a Patient resource, initially from Synthea, was fully aligned with US Core by validating and populating all necessary fields, including the crucial Patient.meta.profile.

From complex CDA to DQM-ready FHIR: A standardized approach

When we process your CDA data and transform it into FHIR, the improvements are tangible:

  • Patient data: Critical demographic elements, including US Core extensions for race, ethnicity, and birth sex, are correctly populated using standard terminologies. Data provenance is clearly marked.
  • Condition & encounter resources:
    • Standardized codes: This is paramount for DQMs. Elements like clinicalStatus, verificationStatus, category, class, and type are populated with official codes from required terminologies (SNOMED CT, HL7 v3 ActCode, etc.). We often enrich this by adding mappings to other relevant code sets like ICD-10 or CMS Place of Service codes.
    • Resolved references: One of the most significant enhancements for DQMs is our handling of references. Original CDAs often contain ambiguous, query-like references (e.g., Practitioner?identifier=...). Our process resolves these by creating or identifying the full Practitioner, Location, and Organization resources and updating the Encounter to use direct, literal FHIR ID references (e.g., Practitioner/{id}). These referenced resources are then included in the output bundle, making it self-contained and easily processable. Our OperationOutcome resource provides transparency into this resolution.
  • Explicit profile conformance: All relevant resources in the standardized bundle explicitly declare their conformance to the appropriate US Core profiles (e.g., Condition.meta.profile includes http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition|3.1.1), which is vital for any system consuming the data based on IG specifications.

Why this level of detail is a game-changer for your organization

This meticulous, battle-tested approach to data standardization isn’t just about technical elegance; it’s fundamental for:

  • Reliable Digital Quality Measures (DQMs): Accurate DQMs depend on precise, correctly coded, and conformant data. Our process ensures the FHIR data feeding your DQM engine is as clean and complete as possible, leading to trustworthy quality scores and actionable insights for care improvement.
  • True interoperability & future readiness: Beyond quality measures, high-fidelity FHIR data empowers smoother data exchange, fuels clinical decision support, supports research initiatives, and helps build a more connected and efficient healthcare ecosystem for everyone.

We understand the complexities your team navigates daily. If you’re exploring ways to unlock the full potential of your clinical data and ensure it’s ready for the next generation of healthcare analytics and quality improvement, we’re here to help.

Wondering how this could apply to your specific data challenges? Let’s explore together. We often find that a brief discovery session, understanding your current systems and what success looks like for your team, can quickly illuminate the path forward.