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.