CDA Generator Module Documentation

Documentation

Overview

The aim of this project is to produce CDA documents from OpenMRS data objects based upon user requests.

Clinical Document Architecture(CDA) is an XML-based standard for exchange of health information records, it is meant to ensure interoperability.

The CDA generator module uses the MDHT API to produce and validate CDA Documents.

This document will cover following information :-

What types of CDA Documents or Messages are currently supported by the CDA Generator module
Design of the Module
How users can extend on CDA Generator module
How we are populating sections of APHP CDA Message
Installation of the Module
Potential Improvements
Screenshots
Quick Demonstration

What types of CDA Documents or Messages are currently generated by the CDA Generator module ?

This release of module only supports the generation of an APHP CDA Document type. However, developers are free to write up new CDA documents which can be added to the module. There are many types of CDA documents (APHP, APS, APL ,APE, e.t.c) that may be found on the IHE profile page.

Design of the Module

During this summer our focus was to generate APHP CDA message, but there are many types of IHE profile or CDA documents types.

However, our module was designed to be configured in a manner that allows users to write their own CDA message handlers.

We have designed our module to ensure that our work is flexible, and can be extended further. If someone wants to add new CDA type documents other than APHP, our module accommodates this change. Our design consists of an hierarchy of classes (or as we call them, an hierarchy of handlers. BaseCdaTypeHandler serves as the base class which contains all attributes necessary for CDA document. All other handlers extend this BaseCdaTypeHandler (example APHP handler, APS handler or some other handler).

Our module uses the BaseCDATypeHandler to make our work as generic as possible.

If we want to add a new CDA Document Type, all we need to do is create a class, extend from this BasCdaTypeHandler class and use setter methods to add values. Its as simple as that!

The same design approach is followed for Section as well. There we have BaseCdaSectionhandler and child handlers extending upon it.

Class Diagrams

The class digram above depicts how different Document handler classes extend on the BaseCdaTypeHandler.

How can users extend on the CDA Generator module?

Users can extend the module by adding new CDA document Types or Editing existing ones (not recommended). Each CDA document consist of few sections and users can also add new sections to the module or Edit existing ones. The Editing/Adding/Deleting of Sections and CDA document types can be done programmatically through code not the User Interface.

1) Steps to Add a new CDA Document Type

fork our module from gitub here .
open "CDAGenerator-api"folder.
In src/main/java package try to locate "org.openmrs.module.CDAGenerator.CDAHandlers" package.
Now in this "org.openmrs.module.CDAGenerator.CDAHandlers" package, Create class for new CDA Document Type you need and Note that this class must extend BaseCdaTypeHandler class.
Add details about documents either using setter methods or adding in a constructor. Thats it and new CDA document type is ready! .

Image showing location to add new CDA Document Type

Sample Code

Code showing how New CDA Document type Class Must look like

package org.openmrs.module.CDAGenerator.CDAHandlers;


public class MyCDADocument extends BaseCdaTypeHandler
{
    
    public MyCDADocument()
    {
    this.documentFullName="MyCDADocument";    
    this.documentShortName="MCD";
    this.documentDescription="to add new cda document type";
    this.templateid="some free text";//required attribute,not null
    this.formatCode=null; //optional attribute
    }
}

2) Steps to Add a new Section

fork our module from gitub here .
open "CDAGenerator-api"folder.
In src/main/java package try to locate "org.openmrs.module.CDAGenerator.SectionHandlers" package.
Now in this "org.openmrs.module.CDAGenerator.SectionHandlers" package, Create class for new section you need and Note that this class must extend BaseCdaSectionHandler class.
Add details about section either using setter methods or adding in a constructor. Thats it and new Section is ready! .

Image showing location to add new sections

Sample Code

Code showing how New Section Class Must look like

package org.openmrs.module.CDAGenerator.SectionHandlers;
public class MySection extends BaseCdaSectionHandler
{

public ChiefComplaintSection()
{
    this.sectionName="My Section";
    this.templateid="";//ihe specific id
    this.sectionDescription="This is my new section";
    this.code="";//Ihe specific code for section
}
}

Similarly one can edit or delete any Sections or CDA document type.

Populating sections of the APHP CDA Message

We have used OpenMRS Concept Dictionary to populate APHP CDA message section with answers. We used IHE APHP Document value sets which list out specific concepts that must be used for specific sections. We are updating the MVP-CIEL Concept dictionary with LOINC codes, SNOMED codes and new concept that our module needs.

Installation of the Module

Potential Improvements

We can Add/Edit/Delete CDA Documents and Sections Programmatically but not though the UI.
Create clients to consume CDAs by hitting a REST Web Service with a patient identifier and cda document type to download their CDA instead of users downloading through administrative tab.
We are using gazelle as an external validator in addition to mdht cda validation code in our module. I’m manually using GUI gazelle validator to check our cda documents. So, we can call gazelle validator via a web service from our module.