Dugas BMC Medical Informatics and Decision Making (2015) 15:40 DOI 10.1186/s12911-015-0163-5

SOFTWARE Open Access

ODM2CDA and CDA2ODM: Tools to convertdocumentation forms between EDC and EHRsystemsMartin Dugas

Abstract

Background: Clinical trials apply standards approved by regulatory agencies for Electronic Data Capture (EDC).Operational Data Model (ODM) from Clinical Data Interchange Standards Consortium (CDISC) is commonly used.Electronic Health Record (EHR) systems for patient care predominantly apply HL7 standards, specifically ClinicalDocument Architecture (CDA). In recent years more and more patient data is processed in electronic form.

Results: An open source reference implementation was designed and implemented to convert forms betweenODM and CDA format. There are limitations of this conversion method due to different scope and design of ODMand CDA. Specifically, CDA has a multi-level hierarchical structure and CDA nodes can contain both XML values andXML attributes.

Conclusions: Automated transformation of ODM files to CDA and vice versa is technically feasible in principle.

Keywords: EHR, EDC, CDA, ODM, Documentation form, Data model

BackgroundInefficient and redundant documentation processes are akey problem in medical research. The documentationburden in clinical studies is huge and increasing: Ac-cording to Getz [1]–based on an analysis of approxi-mately 10.000 study protocols–the average amount ofcase report forms (CRFs) per patient in a clinical trialincreased from 55 (1999-2002) to 180 pages (2003-2006). This surge is primarily caused by regulatory re-quirements, in particular regarding adverse drug events.High documentation workload is certainly a major costfactor for clinical research. It restricts recruitment ofpatients into clinical trials, simply because the numberof available physicians is limited.From an informatics point of view, routine documen-

tation is performed in Electronic Health Record (EHR)systems. These are currently separated from ElectronicData Capture (EDC) systems for research purposes.From a process perspective, this leads to redundant dataentry: Data from the same patient, regarding identical

Correspondence: dugas@uni-muenster.deInstitute of Medical Informatics, University of Münster,Albert-Schweitzer-Campus 1, A11, D-48149 Münster, Germany

© 2015 Dugas; licensee BioMed Central. This iAttribution License (http://creativecommons.oreproduction in any medium, provided the orDedication waiver (http://creativecommons.orunless otherwise stated.

medical problems, are managed in separate systems. It iswell known that uncontrolled redundancy is inefficientand causes data inconsistency. Integrating the Health-care Enterprise (IHE) methods like IHE Retrieve Formfor Data Capture (RFD) try to improve data integration,but are limited due to isolated systems. From a regulatorypoint of view, EHR systems are currently not validatedfor clinical trials–in contrast to EDC systems.From a medical point of view, the overall purpose of

high-volume documentation in EDC systems is verysimilar to EHR systems: The physician provides detailedreports about diagnostic and therapeutic actions. In theclinical context, this is needed to communicate withinthe clinical team and to provide evidence for treatmentaccording to state-of-the-art. In a study context, detaileddocumentation is demanded to identify adverse eventsas early as possible.It is necessary to analyze, compare and potentially

harmonize data structures in EHR and EDC systems toaddress this problem of redundant documentation inEHR and EDC systems.Quite different standards evolved because EHR and

EDC systems are separated. At present, clinical docu-ment architecture (CDA) from HL7 [2] is the most

s an Open Access article distributed under the terms of the Creative Commonsrg/licenses/by/4.0), which permits unrestricted use, distribution, andiginal work is properly credited. The Creative Commons Public Domaing/publicdomain/zero/1.0/) applies to the data made available in this article,

Dugas BMC Medical Informatics and Decision Making (2015) 15:40 Page 2 of 6

established industry standard in EHR systems. It is ap-proved by the American National Standards Institute(ANSI) and supported by major EHR vendors worldwide.Regarding EDC systems, standards reflect requirementsfrom regulatory agencies, in particular Food and DrugAdministration (FDA [3]) and European MedicinesAgency (EMA [4]). Currently standards from the ClinicalData Interchange Consortium (CDISC [5]) are most ac-cepted industry standards for EDC systems. More specific-ally, CDISC’s Operational Data Model (ODM) is availableto represent CRFs. ODM was introduced in 1999, thecurrent version is 1.3.2. It is a platform independentformat for exchange of clinical trial metadata and data.ODM is adopted by many EDC vendors (for exampleMedidata Rave®).From a user’s point of view, data collection with elec-

tronic forms is a laborious task, both in EHR and EDCsystems. These contain 1.800+ data elements on average(180 pages per trial, 10+ items per page). In the past,automated conversion between different technical repre-sentations of these data elements was not available. Thescope of conversion is on the metadata level, i.e., conver-sion of “empty” forms (list of data elements, no patient-level data).The objectives of this work are:

1) To provide a transformation tool for data structuresof CRFs, represented in CDISC ODM, into HL7CDA format, thereby enabling to integrate CRF datastructures into EHRs,

2) to provide a converter for EHR forms into EDCformat, specifically HL7 CDA into CDISC ODMformat and

3) to describe the limitations of this conversion process.

ImplementationFirstly, the meaning of “documentation form” will beexplained, then a short explanation of the standardsCDISC ODM and HL7 CDA will be provided. Secondly,the mapping process between ODM and CDA will beintroduced with more details. Thirdly, an evaluationapproach to test the transformation will be presentedas well as some technical aspects of the referenceimplementation.

Documentation formA documentation form is considered a list of data items.Each data item is characterized by a name, for example“patient weight”, and a data type, such as “float number”.This simple representation of forms is commonly usedin statistical programs like IBM SPSS [6]. Additionalproperties of forms are not taken into account, such aslayout information, business logic, font type or locationcoordinates of data items.

CDISC ODMCDISC ODM [7] is an XML-based transport format forboth metadata and data in clinical trials. It is applied inmany EDC systems, which are accepted for clinical trialsby FDA and EMA. Specifically, ODM enables to repre-sent CRFs. A form is structured into item groups. Eachitem group consists of items. For each item, a data typeand an optional code list can be specified. Fig. 1 presentsan example of a form in ODM format.

HL7 CDAHL7 CDA [2] is an XML-based industry standard forexchange of clinical documents, for example dischargesummaries or assessment forms. Basically, CDA can beused for any type of clinical content. Each CDA documentconsists of a header (descriptive metadata and data, forexample title of document, creation time) as well as abody (structural metadata and data, for instance diagnosiscodes). CDA includes a specification of document seman-tics and is based on the HL7 reference information model(RIM) [8]. CDA Release two has been adopted as ISOstandard ISO/HL7 27932:2009 [9]. Dedicated CDA tem-plates are defined by the HL7 organisation, i.e., not allCDA structures can be considered CDA templates.Figure 2 presents an example of a CDA document

from the Austrian electronic health record project [10].

Mapping process ODM to CDA formatXML elements in the CDA standard were reviewed toidentify suitable data structures for CRF items. A CDAdocument consists of several sections, including a genericassessment section. Because a CRF can be considered apatient assessment, it was decided to map each CRF inODM format into an assessment section of a CDA docu-ment. Each data item from a CRF was mapped to an entryelement within this CDA assessment section (see Fig. 3).CDA entry elements can contain semantic annotations likeUnified Medical Language System (UMLS) codes [11].

Mapping process CDA to ODM formatODM is designed to store patient data in item nodes,which are organised by itemgroups. In contrast, CDAuses different types of nodes and attributes to store patientdata. The CDA standard was reviewed to identify XMLnodes and XML attributes representing patient data.The mapping process CDA to ODM is more compli-

cated, because CDA nodes are nested: For example, thenode < patient > within the CDA header contains a sub-node < name>, which contains subnodes < given > and< family>. The name of the leaf node < given > is not ne-cessarily unique. For this reason it was decided to gener-ate unique ODM item names by concatenating nodenames from leaf nodes and parent nodes. ODM item

Fig 2. Example CDA file. A small extract from a discharge summary file is presented. The header contains a document code (“11490-0”), timestamp (“20130324082015 + 0100”) and patient name (“Herbert Mustermann”). The structured body consists of several components, starting with asection of discharge letter text (“Brieftext”)

Fig. 1 Example of ODM file. A CRF with 4 itemgroups (IG.1 - IG.4) is presented. Details for item I.1001 are provided such as data type and elaborated text

Dugas BMC Medical Informatics and Decision Making (2015) 15:40 Page 3 of 6

Fig. 3 Example for an entry element of a CDA file. It corresponds to an ODM item named “Date of Birth”. C0421451 is the UMLS code for Date of Birth

Table 1 Basic characteristics of ODM files used fortransformation testing

Form number Form name Number ofdata items

4589 Knochenmark AML-AZA 11

4590 Adverse Event AML-AZA 14

4701 Finnish Cancer Registry 49

4810 CDASH Vital Signs 14

5043 Eligibility AML-AZA NCT00915252 24

5165 Follow Up 16

5167 NCI Standard Adverse EventCTCAE v3 Template

28

5215 HIS review of systems 107

5216 EHR4CR data inventory 75

6413 AML-AZA Ersterhebung 94

Dugas BMC Medical Informatics and Decision Making (2015) 15:40 Page 4 of 6

names “patient.name.given” and “patient.name.family”would be generated in this example.CDA uses both XML node values and XML attributes

to represent patient data. For example, the home townof the patient can be stored as < city >Münster</city >and the E-mail address can be stored as < telecomvalue = “mailto:mustermann@mail.de”>. There can beseveral XML attributes per node (e.g., patient telephonenumber as another attribute), therefore the number of re-quired ODM items cannot be directly determined from thenumber of CDA nodes. A suffix was added to the ODMitem name for each attribute to generate unique names. Forexample: “telecom.attributes.value” as ODM item name forthe attribute “value” of the CDA node < telecom >.

Evaluation approachTo test the transformation of ODM to CDA, ten ODMfiles were extracted from the portal of medical datamodels [12]. These ODM files were converted into CDAformat and the result was reviewed regarding syntacticalcorrectness and limitations of the transformation.To assess the conversion of CDA to ODM, ten public

CDA files from the Austrian electronic health recordproject [10] were converted into ODM format. Thetransformation result was checked for schema conform-ance. This is necessary, but not sufficient for ODM val-idity (additional constraints need to be considered).Therefore transformed files were manually reviewed.

Reference implementationAn open source reference implementation for conver-sion of documentation forms between ODM and CDAformat was developed. ODM2CDA and CDA2ODM areimplemented in R [13] and available with programdocumentation at http://cran.r-project.org within pack-age ODMconverter.In addition, ODM2CDA was implemented as web ser-

vice and is available to the scientific community as down-load option within the portal of medical data models [14].

ResultsTransformation of ODM to CDATable 1 provides details about ten ODM files which wereconverted into CDA format. Forms from different docu-mentation settings such as routine documentation (e.g.,

HIS review of systems, Follow Up), clinical trials (e.g.,Adverse Event AML-AZA) or clinical registries (e.g.,Finnish cancer registry) were assessed. These formsare available at https://medical-data-models.org/forms/{form number}.Using the reference implementation of ODM2CDA, all

ten forms were converted into CDA format. Conformancewith CDA schema was tested successfully according to apublic CDA XML schema definition [15]. In addition,these generated CDA files were manually reviewed to as-sess validity. Of note, these files are valid CDA structures,but no CDA templates, because these are defined by theHL7 organisation.The transformation tool ODM2CDA was integrated as

a web service into the portal of medical data models[14], therefore all available forms (>9.000) can beexported in CDA format.It can be concluded that automated conversion from

ODM to CDA format is technically feasible in principle.However, all ODM items are represented as CDA assess-ment items and other CDA sections are not taken intoaccount for this transformation. In addition, ODM item-group information is not represented in CDA format.

Transformation of CDA to ODMTen public CDA files (see Table 2) from the Austrianelectronic health record project [10] were converted into

Table 2 Transformation results of ten CDA files from the Austrianelectronic health record project

CDA file Number ofODM data items

Findings imaging diagnostics (full support) 528

nurse discharge letter (basic) 359

nurse discharge letter (enhanced) 597

nurse discharge letter (full support) 755

physician discharge letter (basic) 359

physician discharge letter (enhanced) 668

physician discharge letter (full support) 1087

physician discharge letter (full support minimal) 559

physician discharge letter (structured) 359

lab findings (full support) 3013

Dugas BMC Medical Informatics and Decision Making (2015) 15:40 Page 5 of 6

ODM format. The transformation result was tested forsyntactical correctness according to CDISC ODM (ver-sion 1.3.2) [7]. These converted CDA files were reviewedmanually. Of note, these converted CDA files contain alarge number of items (between 359 and 3013).In addition, the converted CDA file “physician discharge

letter (basic)” was uploaded to the portal of medical datamodels [14] and is available at https://medical-data-models.org/forms/5217.This transformation has several limitations: The

hierarchical structure of CDA (see methods section“Mapping process CDA to ODM format”) was approxi-mated by concatenated ODM item names, for example“patient.name.family”. CDA nodes can contain both XMLvalues and XML attributes, which need to be representedby separate ODM items. In addition, re-transformation ofthis ODM file into CDA does not generate the originalCDA file: ODM2CDA stores ODM items only within theCDA assessment section.

DiscussionCurrently, the documentation processes for routine pa-tient care and clinical research are disconnected. Highregulatory requirements result in costly documentationprocesses [16]. Different technical standards are used inmedical IT systems: Predominantly CDISC standards forclinical research and HL7 standards for EHR systems, inparticular CDA. CDISC ODM is highly adopted by EDCvendors. ODM is used for data and metadata export, butrecently more and more for metadata import. Regulatoryauthorities like FDA support CDISC standards, which isan important driver for this trend.From a medical point of view, an EHR system and an

EDC system collect information for the same patient.From a data analysis perspective, many data points inboth systems–such as body weight–should be very simi-lar or the same, only stored in different representations.

CDISC and HL7 standards serve different purposes, sothere will be differences between ODM and CDA.Regarding data exchange between EHR and EDC sys-

tems, it would be very useful to extract data points fromone representation and transform it into another one. Aprerequisite for such data exchange is a transformationof ODM data structures into CDA and vice versa. Thisenables clinicians and researchers to identify similaritiesand differences between EHR and EDC documents.Comparison between EHR and EDC data structures canbe used at the trial design stage to optimize EHR andEDC documentation. In the trial execution phase it canbe used to identify data elements for re-use.Transformation of ODM to CDA was already de-

scribed in the literature [17], however so far no imple-mentation was available to the scientific community. Inthis work we present an open source transformationprogram between ODM and CDA data structures. It wastested for two sets of files: ten ODM files from differentdocumentation settings and ten public CDA files.It was demonstrated that an automated transformation

between ODM and CDA is technically feasible inprinciple. However, this transformation is “lossy”, i.e.,has several limitations due to specific properties ofODM and CDA: ODM is much more generic, because itassigns data items to item groups, and these item groupsto forms. In contrast, CDA consists mainly of predefinedsections of XML nodes related to diagnosis, allergies,medication, findings etc. Many CDA documents containa lengthy header with very detailed descriptive metadataregarding administrative patient data (name, address),physician and hospital-related data. From a data analysisperspective, most of these CDA header elements are notuseful for clinical research questions. In contrast, thebody section of many CDA files–which contains theinteresting clinical data–is very short. From a technicalperspective, processing CDA files is more complicatedthan ODM files: CDA combines XML node values withXML attributes and has a variable hierarchical structure.There are several limitations of the proposed trans-

formation between ODM and CDA.In general, CDA is generated from data instances and

it is not clear what data elements are optional orrepeatable (by default, the conversion tool assigns attri-butes Mandatory = “Yes” and Repeating = “No”). CDAalso provides narrative parts, i.e., non-structured data. Incontrast, ODM defines a full schema with optional,mandatory and repeatable data elements. ODM items arerepresented as CDA assessment sections in the currentimplementation of the conversion tool. The hierarchicalstructure of CDA is approximated by concatenated itemnames in ODM format. ODM does not provide informa-tion about item classes, therefore act classes are generatedin CDA. Narrative text from CDA is ignored when it

Dugas BMC Medical Informatics and Decision Making (2015) 15:40 Page 6 of 6

cannot be assigned to structured data elements. Thetransformation is designed for metadata: CDA filescontain data for one patient while ODM files can containdata for large patient cohorts.Many differences between EHR and EDC standards

have been reported [18], and there is a long scientificdebate about standardised medical data models.Transformation and mapping between EHR and EDC

standards is a first, but important step to enable com-parison and discussion of data items. From a dataanalysis perspective, a list of data items is a prerequisitefor statistical analysis.This requirement is addressed very well by the ODM

standard. CDA was designed to represent the currentheterogeneity of clinical data structures. From a meth-odological point of view, the large diversity of clinicaldocumentation indicates that there is room for improve-ment by standardisation: It is highly unlikely that all thediverse documentation approaches are optimal. Trans-parency of data models and transformation betweendifferent standards like ODM and CDA are first steps totrigger a discussion about best practice in clinical andresearch documentation.The proposed transformation approach can take into

account semantic codes for data items. However, mostpublicly available medical forms are not (yet?) semantic-ally annotated. The high number of data elements perdocumentation unit (up to 3000) in this study indicate aneed for automated metadata processing (for instance[19]), because manual mapping of many data elements isresource-intensive and error-prone.

ConclusionAutomatic transformation of ODM files to CDA andvice versa is technically feasible in principle, but haslimitations due to the different scope of ODM and CDAstandards. An open source reference implementation isavailable.

Availability and requirementsProject name: ODMconverterProject home page: http://cran.r-project.org/web/pack-ages/ODMconverter/index.htmlOperating System: Platform independentProgramming language: ROther requirements: R packages XML and xlsxLicense: GPLAny restrictions to use be non-academics: N/A

Competing interestsThe author declares that he has no competing interests.

Author’s contributionsMD designed and implemented ODM2CDA and CDA2ODM. MD wrote themanuscript.

AcknowledgementsSupport by Deutsche Forschungsgemeinschaft and Open Access PublicationFund of University of Muenster is acknowledged.

Received: 2 April 2015 Accepted: 13 May 2015

References1. Getz K. Protocol Design Trends and their Effect on Clinical Trial

Performance. RAJ Pharma. 2008;5:315–6.2. Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, et al.

HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc.2006;13(1):30–9.

3. Food and Drug Administration. http://www.fda.gov/ (accessed February 7, 2014)4. European Medicines Agency. http://www.ema.europa.eu/ (accessed

February 7, 2014)5. CDISC: Clinical Data Interchange Standards Consortium. http://www.cdisc.org/

(accessed February 7, 2014)6. IBM SPSS. http://www-01.ibm.com/software/analytics/spss/ (accessed

February 7, 2014)7. CDISC Operational Data Model (ODM). http://www.cdisc.org/odm (accessed

February 7, 2014)8. HL7 RIM. http://www.hl7.org/implement/standards/rim.cfm (accessed

February 28, 2014)9. International Organization for Standardization. ISO/HL7 27932:2009.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44429 (accessed February 28, 2014)

10. Elektronische Gesundheitsakte (ELGA). http://www.elga.gv.at/index.php?id=28(accessed May 5, 2015)

11. UMLS. http://www.nlm.nih.gov/research/umls/ (accessed May 5, 2015)12. Breil B, Kenneweg J, Fritz F, Bruland P, Doods D, Trinczek B, Dugas M.

Multilingual Medical Data Models in ODM Format. A Novel Form-basedApproach to Semantic Interoperability between Routine Healthcare andClinical Research. Applied Clinical Informatics. 2012;3(3):276–89.

13. R Core Team: R: A language and environment for statistical computing. RFoundation for Statistical Computing, Vienna, Austria. http://www.R-project.org/(accessed May 27, 2014)

14. Portal of Medical Data Models (MDM). http://www.medical-data-models.org/(accessed May 7, 2014)

15. VHitG-Arztbrief according to HL7 CDA Release 2. http://www.bvitg.de/arztbrief.html (accessed May 21, 2014)

16. Hearn J, Sullivan R. The impact of the ‘Clinical Trials’ directive on the costand conduct of non-commercial cancer trials in the UK. Eur J Cancer.2007;43(1):8–13.

17. El Fadly A, Daniel C, Bousquet C, Dart T, Lastic PY, Degoulet P. ElectronicHealthcare Record and clinical research in cardiovascular radiology. HL7CDA and CDISC ODM interoperability. AMIA Annu Symp Proc. 2007;11:216-20

18. Laleci G, Yuksel M, Dogac A. Providing Semantic Interoperability betweenClinical Care and Clinical Research Domains. IEEE J Biomed Health Inform.2013;17(2):356–69.

19. Dugas M, Fritz F, Krumm R, Breil B. Automated UMLS-based Comparison ofMedical Forms. PLoS One. 2013;8(7):e67883.

Submit your next manuscript to BioMed Centraland take full advantage of:

• Convenient online submission

• Thorough peer review

• No space constraints or color figure charges

• Immediate publication on acceptance

• Inclusion in PubMed, CAS, Scopus and Google Scholar

• Research which is freely available for redistribution

Submit your manuscript at www.biomedcentral.com/submit