top of page
  • Writer's pictureChi Nguyen-Rettig

Navigating the Integration Rapids: Part 1: Decoding the Complexity of Integrating CCDA into HealthShare

Have you ever wondered why implementing CCDA interfaces can be such a time-consuming and costly endeavor for organizations? In this article, we'll delve into the intricacies behind this issue. Stay tuned for Part 2, where we'll explore LEAD North's best practices for simplifying and overcoming many of these challenges.

CCDA Documents are complex XML data objects that inherently pose challenges for analysis and ingestion. In addition, there are challenges specific to HealthShare that, once identified, shed light on the pain points and provide a plan of attack.

First, the inherent challenges that exist in any solution: 

  • CCDA documents can be comprehensive/longitudinal or episodic

  • CCDA documents are many times more complex than HL7 v2 documents in terms of data elements

  • CCDA documents contain an enormous amount of metadata, codes, tags, and template ids that do not constitute data elements, resulting in a lot of extra noise for an analyst or developer to sort through

  • Working with the CCDA document is often entangled with working with the IHE header - presenting an extra layer of transformation

  • XSLT, used for XML to XML mapping, is not a common skill

  • XSLT behavior is dependent on version and parser (i.e. xalan vs saxon)

  • Encoding can become a factor in free-text fields: UTF-8, UTF-16, UTF-32, ASCII, Latin-1

Given the challenges that are inherent in the CCDA document structure and versions themselves, the solution in HealthShare focuses on these supportive features: 

  • An extensive pre-built library of XSLT code

  • XSLT libraries to address different versions of CCDA documents

  • Conditional logic to handle many variations within the standard

  • Extensive documentation of the coding logic in the SDA annotations

  • Utility function library

  • Abstraction of encoding handling

  • Pre-built code to handle the IHE transaction header

  • Many “hooks” for additional customization: callbacks, pre-functions, post-functions

The HealthShare CCDA solution does a lot of heavy lifting and encapsulates many of the requirements from the implementor. Running most CCDAs through the standard transforms will get you 85% of the way there. That last 15%, however, usually requires an amount of effort and knowledge of the IRIS IHE implementation that is not insignificant.

Here are the specific challenges for transforming CCDAs in HealthShare, which can be understood when taking into account the above two sections: 

  • By design, custom CCDA transformations are supposed to leverage the pre-built framework provided by HealthShare. There is a steep learning curve for understanding the framework as it is a separate framework on top of the ObjectScript framework.

  • There are two main points where transformation can non-invasively take place while leveraging the codebase. Knowing this tells an implementer how to customize. 

    • Pre-transform (Mapping from CCDA to CCDA)

    • Post-transform (Mapping from resulting SDA to SDA) 

  • There are situations when it may be desirable to customize pre-existing library transformations– for example, if a site wants to create a custom Problems section mapping or needs to incorporate SDA extensions for CCDA elements that do not standardly map to SDA. Knowledge and sample code of where and how to do that has limited to no documentation, increasing development time.  

  • XSLT within HealthShare is so encapsulated that it is difficult to debug and troubleshoot. 

    • There is low visibility into the XSLT transformation process. i.e. There is no traditional  XSLT debugger and the ability to do console log debugging is limited to non-existent. 

    • Navigating the existing codebase to identify where a problem is occurring is difficult. 

  • Some of the built-in logic for handling CCDAs is controlled by the IHE header and the HSREGISTRY IHE registry entries. There is little visibility into this process in the product documentation, and not knowing this can lead to a lot of extra development time chasing down issues.

  • Problem-solving using a combination of Cache ObjectScript and XSLT:

    • Based on the limitations of XSLT, the existing solution combines functions built in ObjectScript which are referenced in XSLT. An implementer faces the same challenge of deciding whether it makes sense or is even possible to solve a problem in XSLT vs. combining a callout to ObjectScript. This requires a higher level of technical proficiency across both languages.   

  • CCDA documents are mapped to the SDA data structure internally in HealthShare. To navigate complicated data scenarios, an implementer needs to have in-depth knowledge of the SDA model including: 

    • How adds and updates work

    • How the Encounter model works in SDA

    • How streamlet matching works for each section, i.e. Medications have different matching criteria than Problems 

    • How Action Codes and IDs work in the SDA against the HealthShare patient record model

  • IHE Ecosystem challenges: 

    • CCDA Documents are often combined with HL7 Data or other documents (i.e., XDLabs) to provide the complete patient record. This means the mapping of the CCDA must be sensitive to the idea of data aggregation. For example, a policy of always clearing away the previous existing patient record and loading the new comprehensive record from the CCDA will not work in these cases. 

    • Data aggregation between HL7 and CCDA is further complicated through the duplication of data or incomplete data records. For instance, if encounters are received through both ADT and CCDA feeds from the same data source but the encounter IDs across these feeds are not matching up when appropriate, HealthShare will end up with two or more encounter records for the same visit.

    • In addition to data transformation, the requirements of handling CCDAs may also include how to register the CCDA document in the document repository.

    • CCDAs will vary depending on their data source and the internal systems (EMR/EHR, HIE platform, etc.) each data source uses to generate CCDA. Managing these variations across sources can make code reuse sometimes difficult.


103 views0 comments


bottom of page