A New Model for Collaboration: Building CDA Documents in MDHT
Abstract
Clinical Document Architecture implementation guides (IGs) specify a standard format for electronic submission and are typically developed by a few standards specialists working in national committees that do not have the resources to address the range of use cases needed for community-wide document-based health information exchange. To accommodate the variation inherent in these use cases we must be able to customize a base IG according to state and local rules, and to document ownership of these constrained guides. Model Driven Health Tools (MDHT) is an open source framework that enables community authoring. The Public Health Data Standards Consortium assembled a cross-disciplinary team to develop Public Health Case Report IGs for 15 reportable conditions using MDHT, with the goal of supporting state and local customization. This paper describes our experience learning MDHT and evaluates how well MDHT meets our objectives.
Introduction
Electronic Health Record (EHR) systems that create, transmit, receive, and display Continuity of Care Documents (CCD) as required under Meaningful Use1 have a framework that can serve as the basis for the creation of closely related documents that are needed within a document-based health information exchange. The HL7 Clinical Document Architecture (CDA)2 Public Health Case Report (PHCR) is one example: it leverages CCD sections (e.g., social history, medications, results, encounters, immunization) to transmit reportable condition information to public health entities as required under jurisdictional law. The CDA PHCR implementation guide (IG)3 was balloted by HL7 in 2009 with a base report and condition-specific reports for anthrax, acute hepatitis B, tuberculosis, and tularemia.
This year, the Public Health Data Standards Consortium (PHDSC), in collaboration with the Centers for Disease Control and Prevention (CDC), Council of State and Territorial Epidemiologists (CSTE), and Association of Public Health Laboratories (APHL), renewed development of the HL7 PHCR IG, to support an additional set of reportable conditions. Following the leadership of the Office of the National Coordinator (ONC) and Centers for Medicare and Medicaid Services (CMS) our project utilizes Model Driven Health Tools (MDHT)4 as a framework for creating CDA constraints in a user-friendly interface. We created modular definitions (templates) in MDHT as inputs for automated IG generation and Java developer tooling (artifacts) for creating, validating, and consuming documents. In addition, we will create condition-specific case reports; demonstrating a sample use case and the tool’s Application Programmer Interfaces (APIs). These templates and artifacts are being contributed to the open source MDHT template library. Our goal is to provide clinical and public health organizations with meaningful examples and a ready-to-use template library, in order to begin a conversation around CDA based public health case reporting in state and local document exchanges with Electronic Health Records (EHRs).
Our cross-disciplinary template team collaboration is composed of members with some technical, standards development, or public health experience – but no member has experience in all 3, and none had prior experience using MDHT. Fifteen reportable conditions were divided among project participants and for each condition the template developer was paired with one or more public health subject matter experts from CSTE and CDC, who provided resource materials, guidance, and content review. Training, hands-on tutorials, and support for MDHT were provided by IBM Research, a contributor to the development of MDHT.
This paper describes the learning process and provides our perspective on installing, learning, and using MDHT for this project, as well as our assessment of the value MDHT is able to provide within a broader community for enabling collaborative authoring and publication of IGs for state and local document exchanges.
Background
MDHT is an open source application that supports collaborative development of a shared electronic repository of CDA templates and documents. The creation of thoughtful and robust standards-based specifications requires that experts in a variety of subjects work together. Our project team consisted of epidemiologists, laboratorians, clinicians, standards developers, and information systems specialists. Team collaboration occurred using the phone and desktop sharing software. The PHDSC wiki5 was invaluable for tracking the collaboration, by maintaining for each reportable condition a list of resources and collaborators, and status updates.
For each reportable condition team there were at least two owners, one CDA template developer and one public health subject matter expert. Group training was provided to the template development team, enabling them to learn how to install and use the template modeling framework provided by MDHT. Each template developer provided introductory information on CDA and the goals of the project to their partner subject matter experts. Each reportable condition team met regularly to document and review case report data, organize epidemiological condition-specific data into the HL7 PHCR IG framework, model this data in CDA templates within MDHT, produce one or more sample CDA case reports using MDHT, and create the implementation guide.
The reportable condition teams gathered requirements online from a variety of sources, including CDC and CSTE. Information resources included CSTE position statements (including reporting criteria and case classification criteria), national case notification forms, relevant terminology from the Reportable Condition Mapping Tables (RCMT)6, CSTE technical implementation guides, and other supporting materials. CSTE volunteers provided local and state public health case reporting forms. Where relevant vocabulary sets existed, these were reviewed for completeness. When needed value sets did not yet exist, these gaps were documented for follow-up with the CDC PHIN-VADS team.
The HL7 PHCR IG framework divides the case report into 6 sections: Social History, Clinical Information, Treatment Information, Encounters, Relevant Diagnostic Tests and/or Laboratory Data, and Immunizations (see Table 1). A base case report and four reportable condition-specific reports, anthrax, acute hepatitis B, tuberculosis, and tularemia had already been specified in the current HL7 PHCR IG. These five reports were modeled by the template developers in MDHT as originally designed and provided guidance to the teams working on new reportable conditions. Template developers documented changes they would suggest given current best practices in modeling. One notable suggestion is to avoid observations with ASSERTION as this paradigm lacks support for documenting Unknown.
Table 1.
HL7 Public Health Case Report IG Framework.
| PHCR Section | Section Description |
|---|---|
| PHCR Social History section (optional) | Conforms to the CCD Social History section Contains data defining the patients occupational, personal (e.g., lifestyle), social, and environmental history and health risk factors |
| PHCR Clinical Information section (required) | Contains the case observation which includes the name of the reportable condition, date of the onset of symptoms, date of diagnosis, and clinical details of the case |
| PHCR Treatment Information section (optional) | Contains treatments given and not given other than immunizations |
| PHCR Encounters section (optional) | Conforms to the CCD Encounters section Contains pertinent healthcare encounters |
| PHCR Relevant Diagnostic Tests and/or Laboratory Data section (optional) | Conforms to CCD Results section Contains the results of observations generated by laboratories and imaging procedures |
| PHCR Immunization section (optional) | Conforms to CCD Immunizations section Contains immunizations specific for the case |
Modeling was done in MDHT using specialized tooling in the Eclipse environment. Two models were created for each reportable condition, one for the case report document and another for condition specific value sets. The condition-specific case report document model extends the base PHCR document model. Each reportable condition team developed one or more representative reportable use cases which result in populating most (if not all) of their new CDA templates. The template developer created CDA data type variables holding data such as time stamps and codes; these were then provided to a Java developer, along with the MDHT model, for creating the sample case report document.
MDHT generates an implementation guide framework from the MDHT model using Darwin Information Typing Architecture (DITA). The reportable condition teams created the document, section, and entry descriptions as well as provided sample CDA template snippets (from their use case) to complete the implementation guide.
MDHT Training
The CDA template team met weekly for 2-hour call-in sessions. Training occurred over 5 meetings with breaks to allow the developers to try out their new skills. The training sessions were recorded to allow developers to replay them as needed. Questions were answered during the week on an individual basis as time allowed. We benefited from one member who created and shared step-by-step documentation, with screen shots, of their work in progress. Following training, the fifteen reportable conditions were allocated, individual template developers were paired with CSTE and CDC volunteer subject matter experts, and we continued to meet weekly to report on our progress.
Our first lesson was an orientation to the MDHT template development environment and our objectives in using MDHT for this project. We walked through downloading the MDHT 1.0 all-in-one package, extracting it into a local directory, and creating a shortcut to the executable. We also discussed the organization of the HL7 PHCR IG.
Our second and third lessons were an introduction to creating a new project using the MDHT project wizard, how to create CDA templates, and how to use the MDHT template editor. Referencing the HL7 PHCR IG, we individually began to build the PHCR Social History section. The PHCR Social History section provided an example of how to constrain existing CCD templates within the MDHT template repository as the PHCR Social History section conforms to the CCD Social History section. We learned how to model template constraints such as business conformance (SHALL, SHOULD, MAY) and cardinality.
Our fourth lesson was how to build the project. Building an MDHT project runs scripts that takes the document model and creates the Java artifacts that document builders use to create, validate, and consume case report instances. We learned how to create a value set and import value sets into our project from the CDC PHIN Vocabulary Access and Distribution System (VADS)7.
Our fifth lesson was how to build the IG and a review of the document layout. Building an MDHT IG runs scripts that take the document and vocabulary models and creates a PDF document organized similarly to an HL7 IG while including hyperlinks to easily navigate nested template structures.
The development of Java code for the creation, validation, and consumption of the sample case report was not included in the MDHT training. A sample build Java class for the base case report was provided to CDA template developers interested in seeing how the model artifacts would be used. The training also excluded development of Object Constraint Language (OCL) to write the rare template constraints that at this time cannot be modeled in MDHT. An example is the base PHCR Clinical Information section constraint that either the Patient Condition Alive or the Patient Condition Deceased CDA template may be present in one document, but not both (see Figure 1). Template developers interested in learning more could view the OCL that was included in the base PHCR document model.
Results
The CDA template team completed a questionnaire following their MDHT training to document feedback on the training, the readiness of the tool, and the value they feel MDHT provides for collaborative authoring and publication of IGs for state and local document-based exchanges. This section summarizes the feedback received.
MDHT Training Results
At the time we started our training there was a limited amount of documentation available on the MDHT website for non-technical users so our training was hands-on and unaided by supportive user manuals. We feel that having better documentation would have improved our ability to read off-line and find answers to questions between calls. We feel strongly that community participation using MDHT will require thorough and current documentation. One deliverable from our project will be a consolidated guide based upon our experience.
The MDHT framework is built in the Eclipse Integrated Development Environment. In Eclipse it is not intuitive how one can re-establish a view that has been minimized or closed. Changing a perspective is similar to changing Spaces on a Macintosh computer, but this is a foreign concept for PC users. A quick introduction to common navigation features would be very beneficial for future first-time users. Additionally, there would have been value to having a pre-loaded project that included the PHCR Social History section to use as a reference during our training. It was difficult to verify that what we built was in fact complete because we did not have a way to test our models.
Modelers that were not also technical developers struggled with the realization that completing the modeling part of the process still leaves the project incomplete. A technical collaborator is necessary to finish in OCL any flagged constraints that cannot be modeled in MDHT, and to use the Java artifacts to create the sample case report. We wanted to see our work taken all the way to its conclusion. In a related topic, it was also difficult to understand how MDHT uses the different aspects of our models in all the downstream artifacts as we are not the end users of these artifacts. There is some content that is not used by the Java artifacts that create documents, but is used by the Java artifacts for validation. For example, the vocabulary model provides a list of value sets for the IG and validates the codes used in a CDA instance but is not available to the developer creating the CDA instance. Having a reference table of these downstream effects would be very useful.
MDHT Tooling Results
The first challenge we faced was installing MDHT on our own workstations. For template developers running a version of the Microsoft Windows Operating System (OS), this was straightforward and quick. MDHT has a Windows all-in-one download, and because it is Eclipse-based, users simply download and extract to any directory. An all-in-one download does not exist for the Macintosh OS; use of a Mac required the creation of the environment and installation of additional components, which at the time was not well documented on the MDHT website. As this is an open source project, our feedback is available to the community and will benefit future first-time users.
The MDHT all-in-one comes pre-loaded with a rich CDA template library. The library contains CDA templates from CCD, Integrating the Healthcare Enterprise (IHE), Health Information Technology Standards Panel (HITSP), and Health Story (cdt4cda). The Office of the National Coordinator Standards & Interoperability (ONC S&I) Framework Consolidated CDA templates are also in progress. We leveraged the pre-built CCD templates, and found two noteworthy issues. First, we found an error in one of the CCD template OCL constraints that caused an invalid error during the PHCR document validation. The MDHT development team fixed it promptly. Second, we found that the HL7 PHCR IG did not communicate the requirement for a CCD source. For example, CCD Result Observation and CCD Result Organizer require a CDA Informant. However, PHCR Result Observation (which is conformant with CCD Result Observation) and PHCR Result Organizer (which is conformant with CCD Result Organizer) show no requirement for a CDA Informant, whereas they specify a SHALL conformance for Author. Using MDHT, these types of gaps and discrepancies in requirements are easily detected.
Having the PHCR templates in an open source template library should facilitate state and local adoption. However, institutional network security barriers prevented one of our template developers from accessing the template libraries in the MDHT template repository. This highlights a potential obstacle for states wanting to use the library and extend the work for their purposes.
The library of templates in MDHT is listed by document (e.g., CCD) or author (e.g., IHE, HITSP, ONC). Following the HL7 PHCR IG, we created separate projects to house templates by document. For the initial PHCR work, we created a base PHCR project, and additional projects for anthrax, acute hepatitis B, tuberculosis, and tularemia. (e.g., project org.openhealthtools.mdht.uml.cda.phcr.tb) This separation allowed us to work independently on our assigned conditions, building our templates from the base PHCR project that was made available in the MDHT template repository. This also creates a lot of projects! New development in MDHT is underway to allow a single model to be broken into multiple files to allow multiple concurrent contributions. This feature may tilt future development models towards the author model instead of the document model.
MDHT has an easy-to-use wizard for creating new projects and intuitive menus for creating new CDA templates. The template editor that represents the primary template development area is easy to learn and is preferred for navigation over the traditional Word or PDF IG. For example, our course exercise to create a base PHCR document with the PHCR Social History section that contained five entries required creating bookmarks spanning the entire PHCR IG including the Appendix, navigating the CDC PHIN VADS website for referenced vocabularies, and navigating the CCD IG (see Table 2). In MDHT, you can see all this in one screen and easily drill down to the detail you need (see Figure 2).
Table 2.
Course exercise navigating the PHCR Social History section in existing PHCR IG document.
| PHCR Document Template | HL7 PHCR IG p 29 |
| PHCR Social History Section Template | HL7 PHCR IG p 45 |
| CCD Social History Section Template | HL7 CCD IG p 37 |
| CCD Social History Observation Template | HL7 CCD IG p 38 |
| CCD Social History Observation Source Constraint | HL7 CCD IG p 86 |
| PHCR Geotemporal History Observation Template | HL7 PHCR IG p 107 |
| Value Set – Geographical Location History | CDC PHIN VADS website |
| PHCR Most Recent Time Arrived in USA Observation Template | HL7 PHCR IG p 110 |
| PHCR Race Observation Template | HL7 PHCR IG p 134 |
| Value Set – Race | CDC PHIN VADS website |
| PHCR Occupation Observation Template | HL7 PHCR IG p 111 |
| Value Set – Occupation | CDC PHIN VADS website |
| Value Set – Industry | CDC PHIN VADS website |
| PHCR Pregnancy Observation Template | HL7 PHCR IG p 134 |
| PHCR Estimated Date of Delivery Template | HL7 PHCR IG p 106 |
The MDHT new project wizard has a very limited naming convention that we found insufficient for our needs. We could name a project “org.openhealttools.mdht.uml.cda.tb” but not “org.openhealttools.mdht.uml.cda.phcr.tb”. Changing a project name after it has been created involves a lot of work. The MDHT development team is aware of our request for features enabling more flexible creation of and renaming of projects.
Documentation of vocabulary constraints is an important feature provided by MDHT and is heavily used by PHCR. MDHT makes it very easy to associate the required value sets, and model the template constraints. It also includes an import feature to import value sets directly from CDC PHIN VADS. However, the import feature is limited to value sets under 50 entries and several of the PHCR value sets exceed this limit (e.g., Race). When the value set is too large, MDHT is unable to validate the vocabulary constraint. We would like to see MDHT enhanced to support cached files or web services that could connect with online vocabulary services for real-time validation of CDA document instances.
MDHT Collaborative Value
Today CDA templates are authored across a number of organizations such as HL7, IHE, HITSP, and ONC. The standards development community recognizes that an electronic template repository is needed to support template searches, provide template use information, and encourage template re-use. The repository would also enable support of the template lifecycle including the deprecation of un-used and redundant templates. MDHT provides a neutral home for such an electronic repository and adds additional value by supporting active use of the template library in the process of creating new templates and allowing template developers to benefit from a holistic view of the full template inheritance.
The template views that MDHT provides in the template development environment are critical to managing the increasing complexity of nested templates. Current IGs suffer from their inability to direct users to the number of reference materials needed to fully specify the standard requirements, which increases the experience and time required for a developer to support a CDA implementation. MDHT generated IGs are able to pull in all the nested constraints from the library so that developers have a single resource. The IG publishing process supports inclusion of domain specific content and examples to increase understanding and appropriate use by domain subject matter experts.
As a standards development tool, the ability to share a common development model and work in a collaborative view with real-time CDA instance generation can help recruit more people with diverse skills into the project to produce a better result. It provides significantly improved visualization over current methods.
Future Work
We do not yet have enough information to determine whether the use of CDA for public health case reporting will supersede current and proposed case reporting mechanisms (e.g., phone call, paper form, pdf form, web form, HL7 messages8), nor do we know whether the use of MDHT to author and host an electronic repository of PHCR templates will transform attitudes toward the adoption of CDA documents. We need to recruit a variety of public health staff to review our case report content, validate vocabulary value sets, and provide feedback on our project’s methodology. We need to recruit clinical and public health vendors to implement our CDA case report for demonstrations in interoperability showcases and to provide feedback on implementation viability. We need to hear from our colleagues that are implementing CDA case reports in a parallel pilot project to be completed this year.
Our team is interested in creating a self-study on-line course and corresponding training materials that would guide others through MDHT training using the Public Health Case Report for demonstration. This course could be tailored to people approaching the task as public health, standards, or technical specialists.
We have documented several suggestions for new features from the MDHT development team. Our priorities include the ability to model nested non-templated constraints, include larger vocabulary value sets for CDA instance validation, and allow concurrent collaborative development of a model.
Conclusion
Our cross-disciplinary CDA template team took on the task of creating 15 condition-specific public health case reports with the goal of beginning a conversation around CDA-based public health case reporting in state and local document exchanges, given that EHRs now have a framework for CCD related documents under Meaningful Use. We created small collaboration teams with a diverse set of public health subject matter experts and developed our CDA templates in MDHT to provide an electronic library of templates for state and local customization. We learned how to use MDHT and have documented our experience and our assessment of how well MDHT serves to provide an improved collaborative environment for creating and customizing IGs in a community setting. The MDHT template repository and template development tool provides a level of navigation and transparency that has no parallel in current IG practice. While we have suggested many improvements to the learning process and new features we would like to see, MDHT 1.0 did meet the needs of our project.
The MDHT template repository is a valuable resource for developers wanting to re-use existing templates, a process critical to driving the adoption of CDA. The HL7 PHCR IG provides evidence of the need to recognize the existence of a template lifecycle, and to establish regular review and maintenance of the templates that have been created. For many IGs there is no “custodian”, no authorized entity responsible for the ongoing work needed to ensure that the standard remains relevant to the needs and evolving best practices of the CDA authoring community. Having an electronic repository of templates does not completely solve this resource problem, but it does make it easier to identify which templates are being adopted so that communities can be created to take ownership of these templates.
Sustainability is a key concern in our project, as well as how best to ensure that adoption is viable. Leveraging common vocabularies and existing CDA templates, especially those required for care coordination, should enable EHRs to participate in document-based exchanges with as little overhead as possible to provide their clinician users with an improved public health reporting experience directly from within their current patient-oriented workflows.
Acknowledgments
The authors thank Nikolay Lipskiy, our CSTE Volunteers, the MDHT development team, CSTE, and APHL for all their support.
Footnotes
Funding
This project was supported by the CDC Office of Surveillance, Epidemiology, and Laboratory Services.