CDA+Approach

CDA Consolidation Process and Applications
The Clinical Documentation Architecture (CDA) is an interchange standard developed by Health Level Seven (HL7) and was designed consolidate various implementation guides upon which C32, CCD and other clinical content specifications and source CDA implementation guides were based. The following is an overview that will start with the consolidation process and the components for the CDA, progress to the applications of the two expressions from the CDA- CDA Ballot Document and namely, Model-Driven Health Tools (MDHT) - and incorporate the benefits of the two.

The CDA Ballot Document refers to a readable document which is submitted through the HL7 ballot process for the purpose of engaging the Healthcare community stakeholders in terms of providing feedback and subsequently, adoption.

Alternatively, MDHT is an all-encompassing modeling tool that provides standards organizations and implementers with the means to design, publish, and implement standards. The value of MDHT lies in its ability for automated publication of implementation guides in multiple formats (PDF, XHTML, UML). Moreover for developers, the MDHT-generated implementation guides contain reference material that is cross-referenced and hyper-linked, which streamlines analysis and EHR mapping. Implementers can access the information in a consistent and interactive format which can reduce development costs by providing domain-specific API generated directly from the standards. As such, the value proposition of MDHT lies not only in the various outputs being generated but also the ease at the developer-oriented resources that aid in generating the outputs themselves.



1: Source CDA
Currently, there are numerous CDA implementation guides using the CDA standard, such as CCD, the eight Health Story IGs, HITSP C48, HITSP C32, and various other documents as listed in column 1. Implementation guides contain references to other guides, creating a trial of references and a 'document trail' that poses challenges for implementers to adopting standards. As a result, there are overlapping sources of information to find common sections and entries which caused the implementation guides to contain several references to other documents. The CDA consolidation process aims to integrate key source guides to create a centralized, "one stop shop" for implementing standards without the need to reference peripheral sources of information.

2: Consolidation
The consolidated CDA Implementation Guide (IG) contains a library of CDA templates, incorporating and harmonizing previous documents published from Health Level Seven (HL7), Integrating the Healthcare Enterprise (IHE), and the Health Information Technology Standards Panel (HITSP). The guide provides a single source for implementing the following CDA documents: > The Consolidated CDA IG is expressed in two ways: The document submitted through HL7 ballot and through MDHT.
 * Continuity of Care Document (CCD)
 * Consultation Notes
 * Discharge Summary
 * Imaging Integration, and DICOM Diagnostic Imaging Reports (DIR)
 * History and Physical (H&P)
 * Operative Note
 * Progress Note
 * Procedure Note
 * Unstructured Documents

The ballot follows the HL7 ballot process and timeline, engaging the healthcare community with respect to their feedback, buy-in, and input. During ballot, comments received from the community are analyzed, categorized into negatives and affirmatives, and resolved accordingly. The second expression is generated through MDHT, which contains a UML model and serves as an implementer-centric resource that provides technical specifications and guidance on how to implement the CDA standard. MDHT section level models from both the Consolidated CDA IG as well as HITSP C32 and C48.

3: Published Outputs

 * Publishing Process**: The IG publishing process begins with the UML model in Eclipse where section models can be selected to be incorporated in new IGs. The MDHT output is then transformed to XML and the document style sheet can be configured in DITA for human readability.

The following table gauges the current progress of integrating key CDA IG sections to MDHT.


 * **Section/Entry** || **Consolidated** || **C83 Modeled** || **To Do Legacy C83 Model** || **Consol Modeled** || **To Do Consolidated Model** ||
 * Allergies || Yes || Yes || Verification of Model || No || Flattening, Layer Consolidation Decisions, Verification of Model ||
 * Problem List || Yes || Yes || Verification Of Model || Yes || Verification of Model ||
 * Hospital Discharge Diagnosis || Yes || No || IHE Discharge Diagnosis || No || Model: Hospital Discharge Diagnosis Section, Hospital Discharge Diagnosis, Problem Observation, Age Observation etc ||
 * Hospital Discharge Medications || Yes || No || IHE Discharge Medications || No || Model: Hospital Discharge Medications, Discharge Medication Entry, Medication Activity ||
 * Plan Of Care || Yes || No || IHE Care Plan, H&P Note, Consultation Note || No || Model: Plan Of Care Activity Act, Encounter, Observations, Procedure etc ||
 * Hospital Course || Yes || No || IHE Hospital Course || No || Model: Hospital Course ||

MDHT and the UML Model are valuable resources for implementers and can be used to generate the following:
 * 1) **Implementation Guides:** By having section models, MDHT is able to create key clinical documents and implementation guides by reusing and compiling sections to generate a human readable and implementer-centric document.
 * 2) **Java API:** The API contains a set of rules and vocabularies for implementers to use MDHT.
 * 3) **Validation Tools:** Validation tools can be leveraged to identify gaps between current implementation progress and the required elements required for successful implementation.
 * 4) **Sample code:** Implementers can refer to the sample code for examples of successful implementation code as reference.