CDA Exchange+ Module Introduction

Premium

C-CDA (Consolidated Clinical Document Architecture) is a standard that has been widely adopted in the healthcare industry for exchanging clinical documents. Based on the HL7 Clinical Document Architecture (CDA) standard, it provides a structured approach to capturing and sharing patient information in a consistent manner. However, with the healthcare industry moving towards the more modern FHIR standard, there is now a growing need to convert data between C-CDA and FHIR. Furthermore, the § 170.315(g)(9) ONC criterion mandates that EHR systems must import and export patient data in C-CDA format.

To meet these data exchange requirements, CDA Exchange+ offers a module that performs bidirectional transformations between C-CDA 2.1 and FHIR R4. This module applies a set of rules consistently in both directions, ensuring a robust and reliable conversion process. In addition to data conversion, the module also provides endpoints for persisting FHIR data extracted from C-CDA documents.

Smile CDR includes a CDA document generation tool capable of transforming a Bundle of FHIR resources into a CDA XML document and a CDA document import tool capable of transforming a CDA XML document into a Bundle of FHIR resources.

CDA Exchange+ provides bidirectional mapping for the following profiles and implementation guides:

• C-CDA 2.1 <—> FHIR R4
• C-CDA 2.1 <—> US Core 5.0.1
• C-CDA 2.1 <—> US Core 6.1.0

Please note:

• The CDA Exchange+ module requires a premium license key from Smile Digital Health. If you are interested in adding this module, please contact sales@smiledigitalhealth.com for further assistance, or please reach out to your Account Executive for more information.
• Smile provides mapping logic between CDA sections and resource types per IGs above. Full IG compliance should be validated per customer use case and may require additional configuration or custom transformations.

CDA Export

LMA

In order to create a CDA document, you must first have a FHIR Bundle of type Document. In order to create a FHIR Bundle of type Document, you must first have a FHIR Composition.

Smile CDR's CDA module can generate a CDA document from your FHIR database in a single operation.

Your CDA document needs are likely unique, and so there is no hard-coded template in Smile that dictates what your CDA document includes. Instead, there is a rich API in the JavaScript Execution Environment that can be used to create CDA templates that suit your needs.

Once you have a CDA template, you can create a CDA document from a FHIR database with a single request using the CDA REST API. The creation of the Composition, Bundle of type document, and CDA XML document is all taken care of for you in that single operation.

The typical workflow for getting your Smile instance ready to create CDA documents is as follows:

1. Instantiate a module of type CDA Exchange.
2. Create a CDA JavaScript template using the functionality available through the JavaScript Execution Environment.
3. POST your template to the CDA Exchange module.
4. Apply your template. Depending on your template, you may be required to provide a number of arguments

The rest of this documentation will walk you through the workflow and prepare you to use the full capability of this module.

CDA Import

LMA

Smile CDR's CDA module can transform a CDA document into a FHIR transaction-type Bundle and persist the resources in this Bundle to your FHIR repository. Alternatively, you can convert a CDA document to a FHIR document Bundle without persisting any resources, which is useful for previewing or validating the conversion.

When a CDA document is provided to the CDA REST API using the $sdh.import-cda operation, the system will parse it, convert all the entries it finds into FHIR resources, collect these resources into a Bundle, and persist the bundle to the FHIR database in a single operation. If you want to convert a CDA document without persisting it, you can use the $sdh.cda-to-fhir operation instead.

The module supports three import modes, controlled by the Import Mode configuration parameter:

• DOCUMENT_BUNDLE (default) — the converted FHIR document Bundle is persisted as a single Bundle resource; the resources it contains are not stored individually.
• TRANSACTIONAL — the resources contained in the converted document Bundle are persisted individually in a FHIR transaction.
• TRANSACTIONAL_MDM — the resources are persisted individually, but the Bundle is first processed through the $sdh.mdm-bundle-match operation so that incoming resources are matched and consolidated against existing MDM-managed records before persistence. This mode requires a Master Data Management (MDM) module dependency.

The id field of each entry in the CDA document will be used to establish references among the generated FHIR resources and to ensure that duplicate resources corresponding to the same entity are not created. This strategy is also used to deduplicate against the contents of the FHIR database. For best results, we recommend that each CDA entry have exactly one id assigned.

In order to enable the CDA import feature, the CDA Exchange module must be configured with an R4 persistence module. Other versions of the FHIR model are not supported at this time.

Data De-duplication

It is often the case that a single resource may be represented multiple times within a CDA document (e.g., the same practitioner authors many entries, many observations are taken in the context of a single encounter, etc.) It is also the case that a CDA document may contain references to resources that are already present in the target repository (e.g., practitioners, organizations and service delivery locations are repeated across many documents).

Smile CDR will attempt to minimize duplication of resources in the repository. Data de-duplication is a complicated process, and our default algorithm depends on several assumptions about the source data.

• Every entry in the document has an <id> element. This will be converted to an identifier on the corresponding FHIR resource.
• If a resource has more than one identifier, the first identifier will be considered primary.
• The primary identifier is unique. For resources within the Patient compartment, the identifier must not be associated with any other resource in that compartment. For other resource types, the identifier must not be associated with any other resource in the entire repository.
• All documents that refer to the same resource must agree on the same primary identifier. Other identifiers may be considered optional, and may occur in any order, but the primary identifier must always be present, and must always be first in the list.

If a CDA document does not meet these assumptions, the behavior of the default de-duplication algorithm is undefined. Duplicate resources may appear in the repository, or document ingestion may fail. In such cases, we recommend overwriting the default conditional queries in the bundle using a post-processing script or interceptor.

De-duplication Against MDM Records

When import_mode is set to TRANSACTIONAL_MDM, each entry in the transaction Bundle derived from the CDA document is matched against existing repository resources using the configured MDM rules:

• If survivorship rules are not configured, matched resources are removed from the Bundle and every reference to them is repointed to the existing repository record (deduplication / match-only behavior).
• If survivorship rules are configured, matched resources are merged into the existing record using survivorship and applied as UPDATE operations.

This provides stronger, rules-driven deduplication than the id/identifier-based strategy. See $sdh.mdm-bundle-match for the underlying operation, matching requirements, and limitations.

Supported sections and CDA document types

Smile currently supports these sections for export and these sections for import.

Smile currently supports these CDA document types on export and these CDA document types on import.

Implementation of additional documents and section types is ongoing. If you have CDA document generation or import needs that are not currently supported, please contact sales@smiledigitalhealth.com for further assistance, or please reach out to your Account Executive for more information.