A comparison of two Detailed Clinical Model representations: FHIR and CDA

(1)

Medical Informatics

Scientific Research Project

A comparison of two Detailed Clinical

Model representations:

FHIR and CDA

Author: Marten Smits, BSc Mentors: Drs. Ewout Kramer Martijn Harthoorn Tutor:

Dr. ir. Ronald Cornet

(2)

Student M.M. Smits Student number: 6076688 Email: M.M.Smits@amc.uva.nl Mentors Drs. E W.G. Kramer M. Harthoorn Furore

Software Engineering Department

Tutor

Dr. ir. R. Cornet Faculty of Medicine

Department of Medical Informatics, AMC-UvA

Location of Scientific Research Project Furore

Software Engineering Department Bos en Lommerplein 280

(3)

Abstract

Introduction:

In recent years several modeling methods (standards) have been proposed that separate data models from their underlying technical data model. These methods presuppose representation of information independently of (or uninfluenced by) technical consider-ations. One of these methods is the Detailed Clinical Model (DCM) paradigm.

One of the pillars of this paradigm is that all representations convey the same meaning and are independent of the technical standard that is used. The DCM standard claims to achieve that. In this thesis we will challenge that claim by modeling the specific DCMs in two different technical standards (CDA and FHIR) and testing if messages based on these models are interconvertible.

Methods:

We identified and classified the problems that may arise when mapping or combining multiple standards through a literature study, after which we created representations of selected DCMs in both FHIR and CDA to determine possible fundamental problems using a technology independent model (DCM) to represent technical models (FHIR and CDA).

To test if the theoretical problems we found in the literature and encountered while creating our example messages also occur during the actual transformation, and to detrmine any additional problems, we attempted to transform the Clinical Document Architecture (CDA) representations to the FHIR representations of the DCMs using Extensible Stylesheet Language Transformations (XSLT).

Results:

Most aspects of the DCMs could be properly represented in both FHIR and CDA, and can be transformed from CDA to FHIR. However, we identified fundamental issues where meaning of information was lost or changed. This results in fundamental difficul-ties during the implementation of the standards and when transforming one standard to another.

Conclusion:

Our research shows that possible loss and change of meaning and lack of interconvert-ibility occurs when implementing two separate technical standards based on the same DCMs. Which indicates that it does matter in which standard DCMs are represented.

(4)

Samenvatting

Introductie:

De afgelopen jaren is een aantal modeleermethodes voorgedragen die datamodelen beschrijven die onafhankelijk zijn van een onderliggend technisch datamodel. Deze mod-ellen veronderstmod-ellen dat ze informatie representeren onafhankelijk van (of be¨ınvloed

door) technische overwegingen. E´en van deze methoden is de Detailed Clinical Model

(DCM) aanpak. Wij willen testen of verschillende representaties van dezelfde DCMs ook daadwerkelijk dezelfde betekenis hebben. Wij testen dit door DCMs in twee ver-schillende standaarden (CDA en FHIR) uit te drukken om daarna te onderzoeken of ze dezelfde betekenis hebben en in elkaar om te zetten zijn.

Methode:

We hebben de mogelijke problemen die boven water kwamen tijdens ons

literatuuron-derzoek en het cre¨eren van voorbeeldberichten in FHIR en CDA gebaseerd op de DCMs

ge¨ıdentificeerd en geclassificeerd om fundamentele problemen te vinden die voor zouden kunnen komen wanneer je een technisch model (FHIR en CDA) probeert te baseren op een abstract model (DCM).

Om te testen of deze theoretische problemen zich ook voordoen in de praktijk en of er andere problemen zijn, hebben we ook geprobeerd om de CDA voorbeeldberichten te transformeren naar FHIR door middel van Extensible Stylesheet Language Transfor-mations (XSLT).

Resultaten:

De meeste aspecten de DCMs konden correct worden gerepresenteerd in zowel FHIR als CDA en konden worden getransformeerd van CDA naar FHIR. Er kwam echter een aantal fundamentele problemen boven water waar betekenis verloren ging of werd gewijzigd. Dit leidt tot problemen bij de implementatie van de standaarden en bij het

transformeren van ´e´en standaard naar een andere.

Conclusie:

Onze resultaten laten zien dat er mogelijk verlies of verandering van betekenis en gebrek aan onderliggende uitwisselbaarheid ontstaat wanneer er twee technische standaarden gebaseerd op dezelfde DCMs worden gemplementeerd. Dit wijst erop dat het wel uit-maakt welke standaard je gebruikt om DCMs te representeren.

(5)

Preface

This document constitutes the report of the scientific research project to accomplish the Master of Science degree in Medical Informatics at the University of

Amster-dam, Faculty of Medicine. The document was written in LA_{TEX using the TeXstudio}

environment. The study was carried out under the supervision of Ewout Kramer, Martijn Harthoorn, and Ronald Cornet.

I would like to acknowledge all the people who made my graduation and study possible. First of all I would like to thank my thesis committee for their support, interest and enthusiasm from the beginning to the very end of my graduation work. I thank Martijn Harthoorn for his frequent supervision and openness to questions and a helping hand. I furthermore would like to thank Ronald Cornet for making time for me as a tutor for this thesis. Special thanks go out to Ewout Kramer, who took me under his wing in the world of health information exchange standards, and provided me with feedback and assistance on both my writing and my practical work.

Secondly, I’d like to thank my fellow students at the university, especially Jos Vliegen-thart, who made each year a very pleasant one. I would also like to thank my col-leagues at Furore for their interest and support. They made the time I spent there as an intern one to never forget.

Last but not least, I would like to thank my family and friends for all their sup-port during my study. I thank my parents for their supsup-port, both financially and morally, and their infinite interest in my study. On the same note I would also like to thank my brother and friends for their encouragement.

Marten Smits,

(6)

Chapter 1 Introduction

1.1 Context

Hospitals and other healthcare providing organizations typically have many different computer applications for everything from billing records to patient tracking. A lot of this software must communicate with other software inside and outside the facil-ity to be able to share clinical information. It is important for hospitals and patient safety in general that information exchanged between software is not lost or altered. There is general agreement that making clinical documentation uniform saves time and resources and the exchange of data between healthcare institutions is much simpler when there are less different data definition standards. For research and healthcare indicators it is also desirable that healthcare data is saved in a uniform way and close to the health processes. [1]

The eight academic hospitals in the Netherlands and the National IT Institute for Healthcare in the Netherlands (Nictiz), a knowledge center for IT and innovation in the healthcare sector, took the initiative to work together on standardization of health data. The project Generic Data for Patient Transfers (GenOGeg) also known as “GoG” or “Generieke Overdrachtsgegevens” in Dutch, was started in January 2012 as the first project of the collaboration. The scope of the project is to create a national cross-specialty exchange dataset for when a patient gets transferred between healthcare facilities. [1]

In order to secure corresponding data, the Detailed Clinical Model (DCM) paradigm is chosen, and a sizable set of DCMs have been published as a result of this project. DCMs provide a method to specify what information is potentially relevant. DCMs combine terminology, professional knowledge, and data specification into informa-tion models, from which various technical soluinforma-tions can be developed. [2] Nictiz is

(9)

planning to use a Health Level Seven (HL7) version 3 Clinical Document Architec-ture (CDA) Release 2 standard based on the DCMs as a solution for this exchange. Meanwhile, developments of a next version of HL7 are ongoing, coined Fast Health Interoperable Resources (FHIR), which can also be used to represent DCMs.

Over the years, a lot of effort has been put in the specification of clinical data el-ements. Clinicians, regulatory agencies, health statisticians, institutions for quality control and others invest in clinical data standards. [3] With this growth of stan-dards, the demand of standards that can exchange information with other standards also grows.

As the GenOGeg project constitutes a large effort from many people and different organizations, it is relevant to consider how this work will be able to cope with the inevitable change in landscape of data standards in health. For this it is vital to establish whether the current chosen implementation of DCM can be transformed into the next generation of standards.

1.2 Research

As FHIR is based on other models than HL7v3 [4], we aim to investigate to what extent CDA representations of the GenOGeg DCMs are different from the FHIR representations and which problems occur when transforming one into the other. A review about detailed clinical models states:

“DCMs organize health information via combining knowledge, data ele-ment specification, relationships between data eleele-ments, and terminology into information models that allow deployment in different technical for-mats.” [5]

In this thesis we will prove that different representations of DCMs do not convey the same meaning and are not independent of the technical standard that is used. We will prove this by showing that both FHIR and CDAs result in different representa-tions of the DCMs, and that a direct conversion from CDA to FHIR is not possible. We will identify and classify the problems that arise during this attempt.

(10)

Subquestions in this thesis are:

• What problems arise though conceptual analysis (creating and comparing ex-ample messages)?

• What results does practical XSLT transformation add? • Does literature confirm these problems?

(11)

Chapter 2 Background

2.1 Generieke Overdrachtsgegevens (Generic Data

for Patient Transfers)

In the past 10 years patient care has shifted more and more to a multidisciplinary approach when it comes to diagnosis and treatment. The healthcare professionals of each discipline have to be aware of each other’s treatments and findings to treat their shared patients correctly. [1]

There is a clear trend of specialization and concentration of healthcare in Dutch hos-pitals. Therefore, probably not every care provider will offer every form of specialized healthcare in the future. Already patients are treated in academic and top-clinical hospitals for the more specialized problems, where the before- and aftercare of the patient takes place in general hospitals. Because of this shift towards multi-agency healthcare, the exchange of healthcare data becomes more important than ever.[1] Increasing patient empowerment results in a need of hospitals to provide patients with insight into their own medical records. The patient wants access to and control over their own data and the possibility to add information to their own record. [1] The academic hospitals in The Netherlands have taken the initiative to collaborate in the field of standardization of healthcare data. Their goal is to create a higher degree of interoperability in data exchange and standardization of health processes, regardless of the type of Electronic Health Record (EHR). With the improvement of uniformity of clinical documentation they aim to save time and resources and the exchange of data between healthcare institutions is much simpler when there is consensus on the data definitions. For research and healthcare indicators it is also desirable that healthcare data is uniformly accessible and without loss of information

(12)

as a result to aggregation, transformation and abstraction. [1]

The project Generieke Overdrachtsgegevens (GoG or GenOGeg) was founded to achieve this increase in interoperability. The objective of the project is to create a nationally defined, generic, cross-specialty dataset which can be used for electronic exchange, when a patient is transferred in a hospital environment. [1]

The following scenarios involving data exchange fall into the scope of this project: • Data exchange between hospitals, within the same specialism.

• Data exchange between hospitals, from one specialism to another.

• Data exchange within the same hospital, from one specialism to another. The final standard is also planned to be used as a base for other scenario’s like:

• Gathering information for multidisciplinary consultation. • Implementation of internal EHR’s.

• Gathering information for scientific research.

• Gathering information for various forms of reporting (diagnoses, complications, co-morbidities, performance indicators).

2.2 Detailed Clinical Models

The Detailed Clinical Model methodology is a draft ISO standard (ISO/PRF TS 13972). It is used to describe a technology-agnostic data model and narrative around interpretation of the model and the data. The methodology was created to standard-ize the way data is modeled.

The concept of “supine systolic blood pressure” is composed from three concepts: blood pressure, systolic phase, and supine position. There are a lot of possibilities to define a concept. For example, the concept “Supine Systolic Blood Pressure” can be defined using just one term. We used an Extensible Markup Language (XML) example for comparison with later examples:

Listing 2.1: Supine Systolic Blood Pressure represented using pseudo XML

<type>Supine Systolic Blood Pressure</type> <value>120 mmHg</value>

(13)

However the same concept could also be defined using:

Listing 2.2: Supine Systolic Blood Pressure represented using pseudo XML

<value>Systolic</value> </qualifier>

</type>

<position>Supine</position> <value>120 mmHg</value> </observation>

Both of these observations are equally valid in describing an blood pressure obser-vation of a patient in a supine position of 120 mmHg. In the first example, all three concepts are represented as a single pre-coordinated term from a terminology. In the second example, “Systolic” has become post-coordinated in the term “blood pres-sure” and “supine” has become part of the information model. [6]

Both definitions may be valid in a given information model within a single institu-tion, however some models will only accept one of the two definitions or neither. To overcome this, either the models of all institutions must understand all used repre-sentations, or all models must be mapped to one central model.

The first is not an option since it is not possible to foresee all of the ways an institu-tion may choose to represent their clinical informainstitu-tion. While the second opinstitu-tion is possible, it places burden on institutions who have to map their model. However, the burden would be far worse in the first option. If, for instance, three hospitals, who all have a different representation model, share their information, each institution will have to map their model to all others. When a fourth institution joins, they must create mappings to the other three hospitals, and the original three have to map their model to the fourth. (see figure 2.1) [6]

(14)

However, if the institutions agree on a common model, each institution only has to create one mapping, which is a lot easier than to create mappings for each partici-pating institution. (see figure 2.2)[6]

Figure 2.2: many-to-one mappings

Detailed clinical models (DCMs) are a good example of such a central model. DCMs describe the structure of the clinical data that is stored in electronic patient records, sent between clinical systems, and referenced in decision support rules. DCMs also describe the line between the terminology model and the information model (see example above), which is, just like defining value sets, helpful for a compatible ex-change of data. A DCM is a relatively small model and is designed to express a clinical concept in a standardized and reusable way. Data elements and attributes of a clinical concept, the possible values and types, and relationships needed to convey the clinical reality are described by a DCM in a way that is readable to both mod-elers and clinicians. [5]

2.3 HL7

HL7 International is a non-profit, standards developing organization. HL7 is dedi-cated to providing a comprehensive framework and related standards for exchange, integration, sharing, and retrieval of health information. The HL7 family of stan-dards is one of the most widely discussed and implemented application data exchange standards in the health information technology industry. [7]

The HL7 standards are developed with the assumption that an event in the health-care world causes the exchange of messages between different software. [8]

Currently there are many different versions of the standard, namely, several versions of HL7v2, HL7v3, CDA, Continuity of Care Document (CCD) and the brand-new (FHIR, pronounced “Fire”). Except for FHIR, which is still in development, these standards are widely used by healthcare application providers worldwide. [9]

(15)

healthcare information in the world today (see figure 2.3). However, the HL7v2 standard is often called the “non-standard standard”. This reflects the fact that Version 2 messages have no precisely defined underlying information model; the def-initions for many data fields are rather vague, and there are multiple optional data fields. This vagueness and optionality provide great flexibility but make agreements among healthcare systems necessary to achieve interoperability. [8]

Figure 2.3: Real-world usage of HL7 messaging standards (approximately) [7]

2.4 HL7 v3 CDA release 2

2.4.1 General Introduction to CDA

The HL7v3 Clinical Document Architecture (CDA) is a standard for exchanging and saving medical documents. A typical CDA document would be an admission report, discharge summary, imaging report etc. CDA uses XML, although it allows for a non-XML body (pdf, Word, jpg etc.) for simple implementations.

CDA Release 2, based in the HL7v3 Reference Information Model (RIM), basically consists of tags, which harbor the semantics for persons and document properties that can be used to describe the structure and the hierarchy of the document. CDA release 2 was launched in 2005 and has gained much popularity internationally. The popularity comes from the simplicity of the model. The fact that the model is generic and is not bound to any domain means there is a lot of freedom during implementation. Persistence, the ability to sign documents, context, and human

(16)

readability are all characteristics of the model that is defined in CDA.

2.4.2 Technical Introduction to CDA

The CDA model exists of two main parts, the Header and the Body. Subsequently, the body part is formed from Body Structures and Body Entries. (see figure 2.4) [10] The CDA header is highly structured and describes the information about the pa-tient, the author, other relevant persons, the medical episodes, and the document itself. The information in the header supports the exchange of clinical documents between different institutes and helps document management systems by providing suitable mechanisms.

The actual clinical documentation is stored in the CDA body. The body exists mainly of readable and understandable text, which is the binding part of CDA release 2 documents and guarantees the interoperability between two human communication partners. Basically, the body can exist of either:

• a NonXMLBody to which every document type (.doc, .pdf, .txt) can be at-tached.

• or a StructuredBody in which the medical content can be displayed easily. The StructuredBody allows the user to structure their text in the same way as reg-ular word processing. The StructuredBody can be defined through Body Structures. Body Structures exist of sections, which contain human-readable text. Sections can be nested in the same way a chapter in a book can have sub-chapters.

Sections always exist of narrative text which contributes to one of the advantages of CDA: The human readability of the documents. Through this narrative text, Body Entries can be connected, which represents the “computer readable” part of the doc-ument. Body entries are originally not mandatory in CDA, but are made mandatory in many implementations. A body entry, also known as a clinical statement, can be one of the following:

• Observation: a (coded) observation, for example: a diagnosis or laboratory result.

• Region of interest: characterization of accentuated parts of an image/photo. • Observation media: multimedia content as part of the document.

(17)

• Substance administration: Information about the received and planned medi-cation.

• Supply: the provision of medication and materials.

• Procedure: an activity, for example: an operation, treatment, or a therapeutic or diagnostic intervention.

• Encounter: data of an earlier, current or future patient contact. • Organizer: for grouping other CDA-entries.

• Act: a generic display of an activity.

(18)

2.5 FHIR

FHIR is a new draft standard based on emergent industry approaches. FHIR claims to combine the best features of the previous HL7 standards while being fast and easy to implement. [11] The FHIR standard can be used as a stand-alone data exchange standard, but can also be used in partnership with existing widely used standards.[12] The basic building block of a FHIR document is a resource. An example of a patient resource can be found in figure 2.5.

Resources have a wide range of uses, from clinical content such as care plans and diagnostic reports through infrastructure such as Message Header and conformance statements. [12] Resources define all exchangeable content, despite the fact they are used in totally different fashions, they all share the following set of characteristics:

• A common way to define and represent them, building them from data types. that define common reusable patterns of elements.

• A common set of metadata. • A human-readable part.

FHIR’s philosophy is to build documents from a set of resources that, either by themselves or when combined, satisfy the majority of common use cases. Extensions can be used to cover the remaining content as needed. Usually, specific use cases are implemented by combining resources through the use of resource references. [12]

(19)

(20)

Chapter 3 Methods

To challenge the claim of compatibility of two representations of the Detailed Clin-ical Models, we chose CDA for being the most frequent implementation and FHIR for being it’s most likely successor. We performed a literature search to identify the possible problems that could occur when combining or mapping two technical models.

To determine the presence of fundamental and less severe problems which could oc-cur when representing a technology-independent model (DCM) in a technical model (FHIR and CDA), we created example messages based on the GenOGeg’s DCMs in both representations (FHIR and CDA).

To test if the theoretical problems we determined while creating our example mes-sages also occur during the actual transformation, we attempted to transform the CDA representations to the FHIR representations of the DCMs using Extensible Stylesheet Language Transformations (XSLT).

Finally we compared our findings with compare the encountered problems with the results of our literature review. A visual representation of the methods is depicted in figure 3.1.

(21)

Figure 3.1: Method representation

3.1 Literature Search

We performed a literature search to identify the possible problems we could encounter during the creation of our example messages and when mapping between models. As FHIR is a new standard which has not been covered in scientific literature yet, we searched for articles that describe the implementation of other health information exchange standards such as OpenEHR and CEN/ISO 13606. The OpenEHR and CEN/ISO 13606 standards were chosen because of their popularity under scientific public. We searched PubMed using the following keywords: CDA, OpenEHR, 13606, DCM. We used the following three queries:

• (”DCM” or ”Detailed Clinical Models”) and (”CDA” OR ”13606” OR ”OpenEHR”) • ”CDA” and (”13606” OR ”OpenEHR”)

• ”13606” and ”OpenEHR”

From the literature, we extracted classifications of problems in mapping standards, terminologies, and model structures. For each of the problems mentioned in litera-ture we analyzed whether they also occurred in our translation of CDA to FHIR or in the FHIR and CDA representations of the DCMs.

(22)

3.2 Creating example messages

To establish the presence of problems which could occur when trying to fit a technical model (FHIR and CDA) onto a technology independent model (DCM), we created example messages based on the GenOGeg’s DCMs.

These DCMs are particularly suitable for this research because they are widely ac-cepted, describe a representative set of data, and are the first DCMs on a national cross-specialty level.

We made a selection of the DCMs, where we expected most problems would arise. We selected the DCMs due to their amount of complexity as opposed to the ones we did not select. The DCMs and the reason for their selection can be found in table 3.2

Table 3.1: Selected DCMs, with rationale for their use

DCM Reason for selection

Alert Ambiguous definitions, expected mismatch between technical

models

Barthel Index To compare support for scores and composite observations

Family History Possible relationship problems

Lab Report Hierarchy of report/section/observation, coding systems,

work-flow data elements

Medication Definition and scope of major components of the medication

workflow

Patient Because it’s needed for the CDA header

Plan of Care Complex, scope, tension between free text/structured

represen-tations

Because DCMs are technology-independent models that are not bound to any tech-nical standard and have already defined the clitech-nical concepts in a standardized and reusable way, therefore we used DCMs as a base and try to fit them into two technical models (FHIR and CDA). To overcome the fact that FHIR is still in Draft Standard for Trial Use (DSTU), we adjusted our representations to the latest version of FHIR when revisions were made to the FHIR standard during our study.

We will describe here how we used the implementation guide of GenOGeg’s Amer-ican equivalent, the Consolidated Clinical Document Architecture (C-CDA), as the implementation guide of the GenOGeg project was not yet finished.

The implementation guide describes how to model body entries and provides exam-ple messages, which we remodeled to represent a DCM. Each part of each DCM

(23)

was mapped to corresponding body entries described in the C-CDA implementation guide. We used XML schema validation to check the validity of our messages. The purpose of an XML Schema is to define the legal building blocks of a specific XML document (for example FHIR) and validate if an XML message is in accordance with these building blocks.

As CDA is a rather flexible standard, it is more than likely that different modelers create different CDA representations based on the same DCMs. To prevent outcome bias due to keeping FHIR in mind when creating our CDA representations, we used the rules and CDA subset of the C-CDA.

To create the FHIR example messages for the DCMs, we started by studying the FHIR specification [13]. In the specification, examples were provided, which we used as a template to create our messages. From the list of resources we selected the resource that corresponded with the DCM model, which could be retrieved from the FHIR specification.

We remodeled the examples so they conformed to the rules of a DCM representation. To check the validity of the XML document of our newly created example messages we used the FHIR-atom XML schema validation.

3.3 Comparing example messages to identify

dis-crepancies

From the start of example message creation, we kept an inventory of problems. We documented the problems we had when trying to represent a DCM using FHIR and CDA. With each step we took in the process we asked ourselves if the example mes-sage was still in accordance with the DCM or that meaning was changed or lost with the last adjustment.

Having both FHIR and CDA example messages of the GenOGeg’s DCMs, the second step we took was the classification of the problems we encountered. We compared the meaning of the FHIR and CDA example messages on each element and identified and classified the differences between both representations.

(24)

3.4 Transforming the CDA example messages to

FHIR

To test if the theoretical problems while creating our example messages also occur during actual implementation, and to identify if any additional problems arise, we attempted to transform the CDA representations to the FHIR representations of the DCMs using XSLT. XSLT is a language for transforming XML documents into other XML documents.[14] The input and the output for XSLT are the same type of objects (both XML). This has immediate benefits: for example it is possible to do a complex transformation as a series of simple transformations, and it is possible to do transformations in either direction using the same technology. [15]

During the transformation of each CDA example message we asked ourselves if we had to remove, add or change meaning to come to a valid FHIR message, which we validated using the FHIR-atom XML schema.

All problems and proposed solutions we encountered along the way are documented in this thesis.

(25)

Chapter 4 Results

In this chapter we will first introduce the list of articles we found including a short description. The problems we encountered are then described each in a separate sec-tion. In these sections we describe whether we encountered the problems during the creation of our representations of the DCM, the transformation of the CDA represen-tation to FHIR, or both and if the literature confirms the problems we encountered. All FHIR and CDA representations and XSLT files used for the transformation from CDA to FHIR can be found in the appendix.

Table 4.1 shows the category of the problems we encountered, where we encountered them, whether they are described in the literature, and in which section they are described.

Table 4.1: List of encountered problems

Problem Representations Transformation Literature Described

in section Referencing X X X 4.2 Coded values X X X 4.3 Difference in Rela-tional Structures / Hierarchies X X X 4.4

Requirements and re-strictions

X X X 4.5

Narrative X X 4.6

Null flavors and nega-tion indicators

X 4.7

(26)

4.1 Articles found in literature

Our search queries in Pubmed resulted in 26 unique articles. During the selection of the articles their usefulness was based on the fact that they reported problems when mapping or combining multiple standards. After the pre-selection on title and abstract, 7 articles were selected for further research. Content analysis filtered the results down to 4 relevant articles:

• Genetic testing information standardization in HL7 CDA and ISO-13606 [16]

The paper by Bosca et al. describes a way to semantically model the informa-tion written in genetic testing by using archetypes and the HL7 CDA standard. Bosca et al. also describe the definition of the same information as both ISO 13606 archetypes and HL7 CDA templates. First the HL7 CDA templates were defined after which they translated the same concept to 13606 archetypes, be-cause ISO 13606 had more generic entities, which made the translation process easier.

• OpenEHR Archetypes for HL7 CDA documents [17]

The goal of this article by Browne is to outline a set of problems in the con-ventional CDA approach and possible solutions to these problems based on openEHR Archetypes. Browne states in the article the primary shortcomings that arise from the requirement to use RIM-based modeling for representing detailed clinical content in each CDA entry.

• Bridging the HL7 template - 13606 Archetype gap with Detailed Clinical Models [3]

The question that Goossen et al. addresses in this paper is whether DCMs can bridge the gap between existing approaches. Goossen et al. identified that HL7 templates and 13606 archetypes object models can be compared on the following levels:

1. Data types; the use of different types of data such as free text, codes, and quantities.

2. Encoding; in which way the standard refers to terminology systems. 3. Concepts; the level of clinical concept, the unit of thought.

4. Meaning; this is created by combining concepts, including component data elements and linking this with the context and knowledge for use in health care.

(27)

5. Electronic communication; the level of the clinical data between systems. 6. Cooperation; this discusses expectations based on exchange of

informa-tion.

7. Workflow around the data elements and concepts 8. Agreements between stakeholders

9. Maintenance and management of the instances of models

The paper only focused on levels 1,2,3,4, and 7 as levels 5, 6, 8, and 9 would require a technical, organizational, and managerial discussion, which was out of scope for this study. Although the levels Goossen et al. compared are useful for our project, they didn’t compare the two standards on electronic communication (level 5) and cooperation (level 6). Especially these levels are interesting for data exchange between two systems that use different standards based on the same DCMs, because that’s where we expect most of the actual problems manifest themselves.

• Using Archetypes for defining clinical models [18]

In this article Moner et al. describe their effort in combining HL7 CDA tem-plates and CEN/ISO 13606 and openEHR archetypes. The proposed approach uses archetypes as template definitions of HL7 CDA documents.

4.2 Referencing

When creating the example messages, we experienced different ways to trace an ob-servation to a subject (e.g. the patient an obob-servation is about). In FHIR, references to other resources within a resource are made explicit. All resources refer directly or indirectly to a subject of the message. For example: A resource of type “Diagnostic Report” always refers to the subject of that report. The “Diagnostic Report” refers to a specimen, a new resource, as to each observation of a diagnostic report. Because of this mechanism, each resource can be traced back to a subject.

To relate message body entries (similar to resources in FHIR) back to a subject (or RecordTarget) in CDA, context conduction is used. This means that the message body entries (e.g. a lab report) has a link to the information about the RecordTarget (e.g. the patient). If context conduction is implemented properly, this could work well. However, there has been a lot of criticism about context conduction. A quote from a recommendation from a HL7 working group meeting to change how context conduction works describes it well:

(28)

“Context conduction has been known to be either “broken”, “impossible to understand” or “unable to meet known use-cases” almost since it was introduced.” [19]

How to use context conduction is usually mentioned in the implementation guide of a standard. The C-CDA implementation guide [20] does not mention context con-duction. As C-CDA is based on CDA R2, this would imply that C-CDA uses context conduction in the same manner it is used in CDA Release 2. The CDA Release 2 specification [21] does define context conduction, but one could argue if modelers implementing CDA messages based on a DCM would look in the CDA specification to find out how to use context conduction, if they even understand it. Modelers would probably follow the DCM to find out how to trace an observation back to a patient.

The DCMs from Nictiz [22] do not describe a preferred way to trace an observation back to a subject. Referring from a DCM to a patient is mentioned in the require-ments and methodology for detailed clinical models. This document states that the way observations are traced back to a subject determines on the reference model of the used standard:

“Not each DCM will specify again the patient name, date of birth, the location where the measure took place and the date/time of measurement. Such additional characteristics would normally apply to many thousands of DCM, creating an overload of redundancy. The “who”, “where”, and “when” can be better specified at a higher level in the RIM/RM. Never-theless, such referring to a higher level must be done such that each single DCM can still make use of it. ” [23]

The DCM leaves it to the reference information model. This would mean that obser-vations in two different standards, based on the same DCM, could refer to a subject in different ways, or not refer to a subject at all.

We encountered the same problem during the transformation of the CDA represen-tation of the DCM to FHIR. In CDA, the subject is not mentioned anywhere except for the header. In FHIR a reference to the subject is mentioned explicitly in any resource, directly or indirectly. As a result, we could not extract the subject from a CDA message body entry and transform it to FHIR. Which left us with manually adding a reference to the subject to the FHIR resources.

Bosca et al. [16] encountered the same problem during their translation of CDA templates to ISO 13606 archetypes:

“The main problem with this translation was that HL7 has a mechanism to conceptually relate entries that ISO 13606 does not (ISO 13606 allow

(29)

the linking of entries at instance level, not at archetype definition level).” [16]

The article by Browne [17] even states that CDA has a lack of specialization seman-tics, which arises from the fact that the RIM has no consistent mechanism to support specialization semantics:

“HL7 does not have a systematic methodology for expressing specialisation in general, nor of CDA Entry types in particular. In some cases, special-isation is hardwired into the RIM classes [..]; in some cases specialspecial-isation is expressed through ’levels’ of HL7 structural codes [..], where these Act-Code levels can be Abstract, Specializable or Leaf; in some cases speciali-sation remains implicit, but might be inferred through external terminol-ogy hierarchies such as SNOMED, when used to populate Observation.code; in some cases one complete RMIM might be a specialisation of a DMIM or another RMIM; in some cases one LIM might be derived in some fash-ion from another LIM. In some cases one DAM might be derived in some fashion from another DAM. And so on it goes.” [17]

Specialization semantics can be used to define if a body entry is a child of a more general body entry. If there is a lack of specialization semantics, this would that er is no proper way to refer from a specialized entry to a more general one.

4.3 Coded values

During the creation of the example messages in FHIR and CDA, we encountered differences in coded values used in the DCMs, FHIR, and CDA. In DCMs, FHIR, and CDA coded values are used. Coded values can be used to define observations (e.g. SNOMED CT codes), but coded values can also have other purposes. For example, the DCMs use CCD codes to give a care plan a status. The following statuses can be chosen:

• Ordered • Requested • Pending • In process

(30)

• On hold • Canceled • No show

The DCMs do not provide further description of the codes, and leave the interpre-tation of the codes and the difference in meaning between the different codes to the user.

As apposed to the DCM, in FHIR it is mandatory to choose from only three codes: • Planned: The plan is in development or awaiting use but is not yet intended

to be acted upon.

• Active: The plan is intended to be followed and used as part of patient care. • Completed: The plan is no longer in use and is not expected to be followed or

used in patient care.

The difference is that FHIR uses a separate resource for some codes in the DCM: “One man’s code is another man’s class” E. Kramer

This is the case with some statuses in the care plan DCM. For the status “ordered” the DCM and CDA both use a CCD code. FHIR uses a whole different resource to define a care plan order. Instead of using a care plan resource with the status “ordered”, an order resource is used with a care plan as a subject which refers to the actual care plan. Due to this, differences in interpretation may arise. Take for example the starting date of a care plan. Does the date change when the status is changed from “ordered” to “in process”?

The DCM does not specify what to do in such a case, which could result in that one modeler changing the date, where another would leave the initial date. Another problem when changing the date in CDA is that the original date would be deleted, while in FHIR the two dates would still exist: one in the order resource and one in the care plan resource. This could result in inconsistencies in different representa-tions.

When creating the example messages for lab results, we determined another prob-lem related to coded values. This probprob-lem occurred when we modeled the reference ranges of the different lab results. In C-CDA the reference range of Hemoglobin is modeled like this:

(31)

Listing 4.1: A reference range of hemoglobin represented according to C-CDA <referenceRange> <observationRange> <text>M 13.8-18.0 g/dL ; F 12.1-15.1 g/dL</text> </observationRange> </referenceRange>

It specifies the reference ranges in text. One for males and one for females. Normal hemoglobin values for the two genders lie between the two numbers. In FHIR the same is modeled the following way:

Listing 4.2: A reference range of hemoglobin represented according to the FHIR specification

</low> <high>

</high> <meaning>

</low> <high>

(32)

</high> <meaning>

</meaning> </referenceRange>

In the FHIR representation of the reference range every part is coded: Two reference ranges are defined, one for males and one for females. The gender is defined in “meaning”. In both reference ranges a low and a high value are defined and even the units are coded.

Plain text (C-CDA) is hard to translate for computers to coded values (FHIR), because first the meaning character or combination of characters has to be defined, after which the combination of codes to be used has to be established.

The literature review showed that there are not only differences between the DCMs, FHIR, and CDA. There are even inconsistencies in the representation of clinical concepts within CDA itself. According to Browne [17] inconsistent representation of clinical concepts results from the fact that the HL7 RIM uses a combination of structural components and coded terms to represent clinical concepts. Browne explains this using the Barthel Index as an example:

“Consider a fragment of a CDA template for Barthel Index, which might look something like figure 4.1, and where what is being recorded is an arti-ficial recording concept, unlike a person’s height. Barthel’s index is a com-pound assessment with a total score. The integer value ( the total score of the 10 constituent functional assessments ) is meaningless on its own. The RIM requires that the result be inconsistently spread across a range of different attributes, classes, potential vocabularies etc. One piece in Observation.value, another in Observation.InterpretationCode, yet another in Observation.derivationExpr, some more in compo-nent Observation.value, but with the meaning and relative weighting of those values lost to all and sundry. ” [17]

(33)

Figure 4.1: CDA representation of the Barthel Index [17]

Browne states that the HL7 RIM has this code/value dilemma for many observations. The RIM has no mechanism to ensure that the Observation.value accords with the specification for what is being observed implied by Observation.code. [17]

(34)

4.4 Different Relational Structures/Hierarchies

Some DCMs have a different structure and hierarchy than their representation. One of the best examples for this is Alert. The DCM of alert is shown in figure 4.2

Figure 4.2: The Detailed Clinical Model of an Alert (remodeled in English for read-ability) [22]

Every alert has a code for AlertType. This can be an allergy, adverse reaction, Methicillin-resistant Staphylococcus aureus (MRSA) carrier, etc. Alerts also have a BeginDateTime, a description of the alert, one or multiple reactions including a descriptions, a criticality (severe, moderate or mild) and an agent. This model complies with the model used in C-CDA as they are both based on the same RIM, because the alert DCM has been inspired by the Continuity of Care Record (CCR)

(35)

and Continuity of Care Document (CCD), which are both constraints of CDA. In FHIR, alert is slightly different. The structure of the representation of the Alert DCM when modeled in FHIR can be viewed in figure 4.3. This is what the DCM would look like if it was based on FHIR instead of CCR. So clearly, the model the DCM author had in mind has influenced the design of the DCM, failing the basic premise that a DCM is technology-agnostic.

(36)

In FHIR the alert itself is a stand-alone resource. It contains a category and a note. It can however also have one or multiple extensions (like all FHIR resources). So, if an alert should refer to a condition (MRSA) or an allergy/intolerance, one can extend the resource with a reference to a condition, allergy, contraindication or any other resource.

To create a representation of an allergy alert in FHIR, one can create an alert with a reference through an extension to an AllergyIntolerance resource. These resource enables the specification of the date the allergy was first recorded, the criticality of the allergy (fatal, high, medium or low) and the date the allergy was recorded. The AllergyIntolerance resource refers to one or more adverse reactions and the substance to which the patient is allergic. The adverse reaction has a code, a date, can have one or more symptoms (which have a severity as well), and can have an exposure, which contains a date and a type.

So there are clearly some differences between the two structures:

• In the DCM, the alert concept directly refers to the reaction and its criticality. This criticality can be mapped to FHIR on the severity of the Allergy or on the severity of the symptom of the adverse reaction. The latter is the one to choose, however, some confusion may easily arise here.

• The same goes for the BeginDateTime attribute of an alert in the DCM. The DCM specifies this as:

“The date and time the allergy, the adverse reaction or the warning has been set as an Alert ” [22]

The problem is where to define this date in the FHIR representation. The alert does not have a date attribute, the allergy has an attribute for the date the allergy is recorded, and the adverse reaction has an attribute which defines the date the reaction began and exposure has an attribute for the initial date of the exposure that is suspected to be related to the reaction. None of those will actually do. You could however make another extension to alert which specifies the date the alert has been recorded.

These problems are a result of the fact that the technology-independent model and the technical model both have different structures and hierarchies, and therefore some attributes might have a slightly different meaning in both models.

In their article, Goossens et al. [3] also encounter differences between hierarchical structures. They state that both CDA and 13606 define all relevant data elements,

(37)

relationships, bindings to coding, and derivation of results, but hierarchical differ-ences remain. Goossens et al. [3] confirm our result whem they compare the CDA and 13606 from the viewpoint of the reference information models:

“HL7 v3 RIM is a generic structure with building blocks requiring a do-main specific modeling exercise before it becomes meaningful. One format in HL7 is the CSP that is used in several HL7 domain message informa-tion models or D-MIMs and message models derived from that. In the 13606, the RIM does represent the whole model used for the EHR com-munication. [...] the commonalties become apparent, although it is not a 100% fit. Differences still remain in the hierarchical representation of concepts and in the workflow options that are both present in HL7 v3 and currently not in the 13606 archetypes.” [3]

4.5 Requirements and restrictions

Different standards have different restrictions and different requirements. For ex-ample: A FHIR resource could define an attribute as mandatory, while the DCM or CDA does not, or the other way around. This could form a problem with the transformation: When one transforms a CDA message to FHIR, and one did not model an attribute that is mandatory in FHIR, the message would be invalid. Or one of the standards does not allow an attribute or only one, while the other allows multiple.

It can even be argues whether the representation of the DCM is still valid if the DCM does not define an attribute as mandatory, while FHIR or CDA does.

When creating the CDA and FHIR representations of the Barthel index, we discov-ered different code systems. The Barthel Index is a scale used to measure activities of daily living. It uses ten performance items describing daily living and mobility. Each item is rated on this scale with a number of points assigned to each level. In the end the patient has a total score which indicated the level mobility and daily living.

In FHIR we used a questionnaire resource to model this, because a questionnaire typically uses multiple observations (questions) to draw one conclusion: Each item in the Barthel Index became a question and each rating an answer. CDA has an Assessment Scale Observation, where different observations result in a total score, which seems perfect for this particular DCM.

The DCM specifies the different items of the Barthel Index with two different code systems: CVA-KIS and NL-CM. [22] A FHIR questionnaire allows for defining a

(38)

concept with two different coded values from two different systems, however the As-sessment Scale Observation in CDA does not allow two separate coded values, but a second coded value can be defined as a conversion of the first, which solves this problem.

We encountered another problem with the total score of the Barthel Index. In FHIR, we used another question in the questionnaire to define this, the questionnaire de-fines the total score as an answer and the interpretation of the total score in a text attribute. In CDA the total score can be defined in the top of the Assessment Scale Observation, however, there is no attribute to define the interpretation of the score. The best solution, however not ideal, is to add a reference range to define the inter-pretation.

The difference in requirements and restrictions between CDA, the DCMs, and FHIR also posed a problem when transforming the CDA representation of the DCMs to FHIR. More restrictions in FHIR can result in loss of meaning, while more require-ments enforce manual addition of information to the FHIR representation. We en-countered such a problem during the transformation of a care plan:

A care plan exists of one or multiple components. According to the DCM, these components are allowed:

• Encounter • Medical devices • Medicine • Vaccination • Activity • Other

An encounter in FHIR has more requirements in FHIR than in CDA. The DCM only requires a reference to the encounter [22], as does the C-CDA implementation guide [20]. However, FHIR requires also an encounter state and an encounter class, which cannot always be extracted from the CDA representation, because it is not mandatory. Consequently, these attributes must be added manually to the FHIR representation.

The problem is confirmed by Moner et al. [18] They use OpenEHR archetypes as a template definition of HL7 CDA documents, because according to the authors:

(39)

“Current template model used by HL7 v3 has some limitations that could be solved by using archetypes. [..] They also provide a less elaborated definition of the semantics of the clinical model (only by constraining an attribute code to a particular coded value) and do not support multi-lingualism either. Finally, the constraining expressivity of templates is limited in comparison with archetypes (only lists of possible values can be defined for primitive types).” [18]

Moner et al. conclude their article with that, as previously identified, the archetype approach adds semantic definition capabilities that can be applied to the CDA ref-erence model.

4.6 Narrative

When transforming CDA to FHIR we encountered a problem in the mapping of nar-ratives. Both CDA and FHIR enable addition of narratives to messages. In both standards reference is possible to coded entries in a document. This is a similarity that immediately forms a problem when transforming one representation into the other. The problem arises when one entry in CDA becomes two entries in FHIR. This would require a choice to which entry the narrative refers. When choosing to refer to both, it is hard to define what the reference means. It could mean that the narrative describes a combination of both entries or that it describes two totally separate entries.

A difference between the two narratives is the syntax in which the narrative is defined: CDA defines its own XML syntax for narrative content, loosely based on HyperText Markup Language (HTML). FHIR makes use of a constrained set of Extensible Hy-perText Markup Language (XHTML) which is somewhat more expressive than the CDA markup. [24] This means we would have to transform not only the content and references to the entries, but also the syntax, which is a whole new problem.

Browne [17] confirms this problem and even states in his article that the lack of cohesion between text and coded Entries in CDA messages arises from the fact that the RIM has no mechanism to tie narrative to entries, nor can one be transformed to the other. Also, the coded entries are optional and often contradict the information stated in the narrative, which causes confusion.

(40)

4.7 Null flavors and negation indicators

A problem with null flavors and negation indicators arose during the transformation of CDA to FHIR. In healthcare, it’s quite common for data to be unknown, unavail-able, have an exceptional value or otherwise fall outside the bounds of a “normal” value. To deal with this, CDA uses the concept of “null flavors”, i.e., the different meanings of null values. Examples are: “Unknown”, “Not asked”, “Positive infinity”, “Trace amount”, “Masked”, “Other”. Null flavors are used on almost every attribute and data type property in its models. These coded null flavors could be sent in place of or in addition to the data where normally a value of the attribute property is presented. Unless an element is explicitly marked as “mandatory”, which means no null flavors are permitted, these null flavors can appear anywhere. [4] One example is:

The means that the quantity of a maximum dosage of a certain medication is un-known.

FHIR handles null flavors exactly opposite to CDA. In FHIR addition of a null flavor on resources must be explicitly allowed. In these resources null flavors are defined in the core specification and are constraint (using a specific value set) to those relevant to that element.

The same goes for negation indicators. In CDA one can add a negation indicator on almost any act. For example: a negation indicator could specify that a patient was not given a certain medication. In FHIR negation indicators can be added only on places where they are explicitly allowed. In the FHIR specification of the medication administration for example, specific attributes are added to indicate if and why a medication was not given. An example can be found in figure 4.4.

(41)

Figure 4.4: FHIR specification of the medication administration resource [13] Because CDA allows null flavors and negation indicators almost everywhere and FHIR allows them only on specific elements, it is difficult to transform a CDA doc-ument into a FHIR docdoc-ument without loss of meaning. A solution might be to use extensions for this, however most FHIR developers would not expect these exten-sions.

4.8 Meaning of attributes

Some attributes in FHIR and CDA look similar, but can have a slightly different meaning or a meaning which can be discussed. Because of this difference or vague-ness, these attributes are difficult to transform from one message to another.

When transforming the AllergyIntolerance representation of CDA to FHIR we experienced unclear definitions of the EffectiveTime attribute. CDA uses one gen-eral attribute to define dates and times. This attribute is called EffectiveTime. To create an AllergyIntolerance section in a CDA document a couple of these date attributes are mandatory:

• The effective time in the section which contains all of the patient’s allergies and intolerances.

• The effective time of each separate allergy or intolerance.

However, the C-CDA implementation guide [20] does not specify the exact meaning of these effective time attributes. Does the first mean the time that the first allergy or intolerance was identified? Although this is probable this is not explicitly stated. Because of this vagueness, we cannot be sure were to place this date in a FHIR message. The effective time of each separate allergy and intolerance is probably the time the allergy has been recorded, and therefore can be transformed to the recordedDate attribute in a FHIR message.

(42)

Chapter 5 Discussion

5.1 Principle findings

Different representations of a DCM do not necessarily convey the same meaning. In our study we showed that both CDA and FHIR are not fully compliant with each other and with GenOGeg’s detailed clinical models when it comes to restrictions and requirements, coded values, relational structures, narrative, null flavors and negation indicators, meaning of attributes, and referencing methods. This results in possible loss of meaning and lack of interconvertibility when implementing two separate standards based on the same DCMs. This indicates that it does matter in which standard DCMs are represented. Most aspects of GenOGeg’s DCMs can be properly represented in both FHIR and CDA, and can be transformed from CDA to FHIR. However, some fundamental problems arose in our study, which could trouble a proper implementation of two standards based on the same DCM. Creating the CDA and FHIR representations of the DCMs shows us that combining or mapping two different standards could result in several conflicts. The transformation of the CDA representation to FHIR confirms these conflicts and adds several others to the list. Most problems were also confirmed by literature. Problems we encountered refer to the following aspects:

• Referencing • Coded values

• Relational structures / Hierarchies • Requirements and restrictions

(43)

• Narrative

• Null flavors and negation indicators • Meaning of attributes

All problems in these aspects result in either loss or slight change of meaning, and fundamental difficulties during the implementation of the standards and when trans-forming one standard to the other.

This study shows that DCMs are not technology-independent. This means not every representation of a DCM, are necessarily interconvertible with others. Therefore, to allow the implementation of multiple technical models in a DCM, modelers should anticipate on the technological models to be used when defining the DCMs.

5.2 Strengths and weaknesses

A possible weakness in this study is the difference in our level of knowledge of the standards used in the study. We began the study with zero previous knowledge of DCMs, CDA, and FHIR and learned a lot along the way. However, due to our daily conversation with one of the founders of FHIR, we ended up with more knowledge of FHIR than of DCMs and CDA. This could have resulted in opinion bias and biased comparisons. However, our newly gained expertise of FHIR made our study of higher quality as well, because some problems would not have arisen if it was not for that knowledge.

A different issue is that we expected that the GenOGeg’s CDA example messages were made available in time, however this was not the case. Therefore we had to create the CDA example messages ourselves. Due to the consequent time constraint we did not have the opportunity to transform our messages in reverse direction (from FHIR to CDA). However, we are quite certain this would not have resulted in fun-damentally more problems, because the majority of the problems that would have arisen were already encountered by creating the CDA and FHIR representations, and the transformation from CDA to FHIR.

A third issue is that all of the example messages of both FHIR and CDA, and the transformation of CDA to FHIR were made by a single individual, which could have made the transformation of CDA to FHIR easier than it would if the messages, and transformations were made by different individuals. The creator of the transforma-tion understands his own representatransforma-tions of the DCMs in FHIR and CDA better, and therefore has less of a problem transforming one into the other. It could be that more problems would have arisen if more individuals were involved in creating

(44)

the example messages and the transformation. The DCMs on the other end, were created by Nictiz and intended for a real life situation, which made them very useful for this study.

The selection of the DCMs was done by one individual. This individual has a lot of experience in the subject, but possible selection bias could have been prevented if we created example messages of all DCMs instead of a selection. However, we are fairly certain the majority of the problems the have arisen from the selected DCMs, because of the amount of complexity of the selected DCMs and as apposed to the ones we did not select.

A strength of this thesis is that we used an XSLT transformation to back up our conceptual analyses through representing the DCMs in both standards. The trans-formation also identified problems that would not have arisen otherwise. Even more, all problems identified by the literature review and the creation of example messages were also identified by the transformation.

5.3 Relation to other work

Although there is research on mapping or combining two standards, this thesis is to our knowledge the first research to determine if two standards based on the same DCM are interconvertible and retain meaning. Other studies concluded that only small problems arise when mapping or combining two standards, and leave the bigger problems in deliberate vagueness. The conclusions of our study disagree with the findings of earlier studies as we conclude that with the different procedures and tech-niques and a broader scope we find several fundamental and unresolvable problems. Actually implementing conversions forced us to face problems that will arise.

5.4 Meaning of the study

Because the study is based on a real life use case (GenOGeg) it can be very useful for it’s decision makers. The problems we identified are generic and therefore could also be useful for similar projects. The study shows that the GenOGeg’s current DCMs are not fully compliant with multiple standards, which is relevant information for both the decision makers working with Nictiz and the academic hospitals, and the active community using detailed clinical models. We hope this thesis will encourage modelers to take the possibility of the implementation of multiple standards into account when defining future detailed clinical models.

(45)

Because FHIR is still in DSTU major revisions in the FHIR standards can still be made. This thesis could be input into the standard formation process of FHIR, especially in the area where interoperability with other standards is involved.

5.5 Unanswered questions and future research

We did not use all available DCMs for our research, although we are fairly certain our selection was enough, there is a possibility new problems would have arisen when we used all available DCMs in our study. Using other standards (OpenEHR, ISO-13606, RDF etc.) instead of FHIR and CDA could also give new insights in which problems arise when combining multiple standards based on the same DCMs.

Because the demand of standards that can exchange information with other stan-dards grows, research needs to be done to determine if the current DCM approach needs to be revised to allow for implementation of multiple standards.

(46)

List of Abbreviations

C-CDA Consolidated Clinical Document Architecture. 22, 23, 28, 30, 32, 34, 38, 41

CCD Continuity of Care Document. 14, 29, 30, 35 CCR Continuity of Care Record. 34, 35

CDA Clinical Document Architecture. 3, 9, 14–17, 20–30, 32, 35–43, 45 DCM Detailed Clinical Model. 8, 9, 14, 20–30, 32, 34–38, 42–45

DSTU Draft Standard for Trial Use. 22, 45 EHR Electronic Health Record. 11, 12, 37

FHIR Fast Health Interoperable Resources. 9, 14, 18, 20–25, 27–32, 35–43, 45 GenOGeg Generic Data for Patient Transfers. 8, 9, 12, 20, 22, 23, 42–44 HL7 Health Level Seven. 9, 14, 15, 18, 26–29, 32, 33, 37–39

HTML HyperText Markup Language. 39

MRSA Methicillin-resistant Staphylococcus aureus. 34, 36

Nictiz National IT Institute for Healthcare in the Netherlands. 8, 28, 44 RIM Reference Information Model. 15, 26, 28, 29, 32–34, 37, 39

XHTML Extensible HyperText Markup Language. 39 XML Extensible Markup Language. 12, 15, 23, 24, 39

(47)

Bibliography

[1] F. Smeele, “Begeleidend document producten generieke overdrachtsgegevens,” tech. rep., Nictiz, may 2013.

[2] “Detailed clinical models.” http://wiki.hl7.org/index.php?title=

Detailed_Clinical_Models&oldid=66663. Last updated December 31,

2013. Accessed January 14, 2014.

[3] W. T. Goossen and A. Goossen-Baremans, “Bridging the hl7 template 13606 archetype gap with detailed clinical models,” Stud Health Technol Inform., vol. 160(2), pp. 932–6, 2010.

[4] “Comparison of fhir and v3.” http://www.hl7.org/implement/standards/ fhir/comparison-v3.html. Last updated May 9, 2014. Accessed June 8, 2014. [5] W. T. Goossen, A. Goossen-Baremans, and M. van der Zel, “Detailed clinical models: A review,” Healthcare Informatics Research, vol. 16(4), pp. 201–214, sept 2010.

[6] C. G. Parkerm, R. A. Rocha, J. R. Campbell, S. W. Tu, and S. M. Huff., “Detailed clinical models for sharable, executable guidelines,” in MEDINFO 2004 (M. Fieschi, E. Coiera, and Y.-C. J. Li, eds.), vol. 104(1), pp. 145–148, 2004.

[7] “The hl7 evolution: comparing hl7 version 2 to version 3, including a history of version 2,” tech. rep., Corepoint Health, 2010.

[8] M. Eichelberg, T. Aden, J. Riesmeier, A. Doggac, and G. E. Laleci, “A survey and analysis of electronic healcare record standards,” ACM Comuting Surveys, vol. 37(4), pp. 277–315, 2005.

[9] P. Sinha, G. Sunde, P. Bendale, M. Mantri, and A. Dande, Electronic Health Record. John Wiley & Sons, Inc., nov 2012.

A comparison of two Detailed Clinical Model representations: FHIR and CDA

Medical Informatics

Scientific Research Project