Observational clinical studies play a pivotal role in advancing medical knowledge and patient healthcare. However, to lessen the prohibitive costs of conducting these studies and support evidence-based medicine, results emanating from these studies need to be shared and compared with one another. This paper explores how semantic interoperability of clinical data can be achieved by integrating two prominent standards for clinical data: ODM and FHIR. ODM lacks a rich-enough information model to adequately capture the contextual information of clinical study data. This is overcome by using FHIR's information model to achieve semantic interoperability of clinical data. This work outlines our ongoing e ort to integrate the ODM standard to the FHIR standard. In particular, it demonstrates how the hierarchical ODM model lends itself to be mapped to the ubiquitous FHIR resources. We describe the approach and provide insights into the assumptions made to t the clinical data extracted from the ODM standard into the FHIR resources. Our focus is not only on mapping the data from ODM to the FHIR models but on capturing the contextual information, present in other sources, such as the study protocol, and which should have been made available with the extracted data. Finally, we discuss the exceptions under which the extracted ODM data does not adequately t the targeted FHIR resources and o er some insight into a suitable solution.
It is increasingly important to share results from clinical studies. The challenge
when comparing results from clinical studies is to ensure that we compare
corresponding data sets. The CDISC ODM1 de nes an XML-based standard that has
been mandated by the Food and Drug Administration (FDA) for the electronic
capture and reporting of clinical study data. While ODM provides a vehicle
to communicate the results back to the regulatory body, it lacks a rich-enough
information model to capture the innate contextual information of the clinical
study data [
A recent report [
In this work, we present an approach to integrate the CDISC ODM standard with the FHIR resources to enrich longitudinal clinical study data extracted from ODM. The aim is to exploit the rich information model from FHIR to reintroduce the contextual information that is often contained within the study protocol documents but not contained within ODM and rarely made available alongside the clinical data. We explore the hierarchical concepts within the ODM and describe how these t the pervasive FHIR resources. In so doing, we elaborate on the assumptions that have been made to adapt the extracted clinical data to the FHIR resources. The expected bene t of this approach is in facilitating a richer exploration and querying of clinical data coupled with relevant contextual information. 2 2.1
The CDISC ODM data model [
FHIR2, published as a Draft Standard for Trial Use by the Health Level Seven (HL7) organisation is a speci cation designed to facilitate the exchange of
ODM
METADATA Study
MetaDataVersion DATA
Clinical Data
Subject Data
Study Event Data
Study Event Def Form Def ItemGroup Def
Item Def Form Data
ItemGroup Data
Item Data healthcare-related information. FHIR revolves around resources, which are snippets of highly-focussed data. The speci cation de nes a set of minimalistic and generic elements and extensions are used to bridge the gap for the remaining content. Figure 2 depicts the hierarchy for the proposed FHIR resources to model the ODM data. The entities in red (CarePlan and Questionnaire) denote metadata concepts. The remaining entities model the clinical data at various levels. Solid lines are used to denote the links between the entities. The original model is depicted in Figure 4 in the Appendix. It was discarded in favour of Figure 2 so that there could be a clear demarcation between the metadata and the data and to allow the questionnaire to be linked to the care plan. The original model did not allow for a resource to contain the entire clinical data pertaining to a patient. This role is ful lled by the ClinicalImpression resource in the new model and has necessitated the introduction of the EpisodeOfCare resource.
CarePlan
Clinical plan Impression activity Questionnaire questionnaire investigations
Episode of
Care patient
patient Patient patient
Encounter subject Questionnaire
Response patient encounter episode of care
encounter
Observation value
Fig. 2. Depicts the metadata (red) and data (blue) FHIR resources and their links
This section describes the approach to integrate ODM with FHIR. We describe the components from the ODM hierarchy that we seek to map to FHIR. We assume here that the person doing the mapping has access to all the contextual information relating to the study. In this vein, it is not our aim to perform a one-to-one mapping of the CDISC ODM with FHIR. Rather we seek a holistic approach to mapping the hierarchical concepts between the two models as depicted in Figure 3.
DATA
Clinical Impression Episode of Care
Encounter
ODM
Study Clinical Data Subject Data
Study Event Data
Form Data
ItemGroup Data
Item Data
MetaDataVersion
Study Event Def Form Def ItemGroup Def
Item Def Observa@on
CarePlan
METADATA Ques@onnaire A study de nes static information about the structure of an individual study. We wish to not only capture this static information but also much of the contextual information pertaining to the study that is contained in the study protocol. This has resulted in the choice of the CarePlan resource to map the Study component from ODM. It provides a link to the study coordinator through the participant attribute and study protocol through the support attribute. While the Subject represents a critical element of the study, its role is quite subdued in ODM. In particular, the speci cation provides no functionality to record the subject's attributes such as gender, date of birth, recommending that these be modelled as clinical data within the forms. The logical mapping for the Subject in FHIR is the Patient resource. This allows us to include relevant contextual information, such as the patient's gender, date of birth and care provider and allows the study subject to be linked to other FHIR resources containing pertinent study-related information. The clinical data for each subject is encapsulated within a ClinicalImpression resource that is linked to the Patient resource. 3.3
A study event comprises a StudyEventDef and a StudyEventData component that are referenced using a common OID. The StudyEventDef manages the set of forms to be completed at this phase of the study and represents an activity within the CarePlan resource. StudyEventDef entities de ne scheduled and unscheduled events and these may be de ned within the detail.scheduled attribute of the activity. The StudyEventData entity contains clinical data collected during a subject's visit. We believe that the EpisodeOfCare resource is appropriate for this entity because it provides details about the group of activities and their purpose pertaining directly to a patient. The care plan is linked to this resource using the plan attribute. A study event may result in many visits from a patient. Each individual visit is modelled as an Encounter and is linked to the episode of care through the episodeOfCare attribute. The patient attribute links the resource to the study subject while the assessor attribute provides a link to the clinician conducting the clinical assessment. 3.4
A form de nes a collection of data items collected during the study and termed a
case report form. A form comprises a FormDef and a FormData component that
are referenced using a common OID. The form is linked to CarePlan through the
activity.actionResulting attribute. The FormDef de nes the form structure
and its questions. The logical mapping of forms in FHIR is the Questionnaire
(Q) resource. This resource contains the typical attributes for questionnaires,
such as an identi er, version, publisher and status, but can also be customised
using the extension mechanism in FHIR. The FormData entity contains the
clinical data associated with the form. The logical mapping for the FormData in
FHIR is the QuestionnaireResponse (QR) resource. The bene ts of using the
QR resource are that the order of the responses is maintained and these can
be linked and validated against the questions asked. Conversely, however, while
CDISC de nes the CDASH3 model to standardise the generation of CRFs for
clinical studies, its use is not enforced. Consequently, in our experience, few
study coordinators choose to use them [
The ItemGroupDef and ItemGroupData entities constitute an item group referenced using a common OID. The ItemGroupDef entity de nes the optional grouping of questions on a form. Groups are de ned using the Q.group attribute. The FHIR speci cation stipulates that a group attribute de ne either a question or a group but not both. The ItemGroupData contains the clinical data detailing the responses for the item group. FHIR organises these grouped responses within the QR.group attribute. The FHIR speci cations requires the order of the responses within the group to be maintained. This is a very important constraint. Consider the situation where the heart rate measurement of a patient indicates that the patient might have had a slight malaise during data collection and that subsequently a blood pressure measurement was taken. In this case, it would be prudent to analyse the blood pressure observation in this context and make inferences accordingly. On the ip side, questions are often grouped together on a form to match the collection habit of the data entry person and not necessarily because of their semantic similarity. Grouping responses in this manner does not advance the semantic interoperability principles. 3.6 Item At the item level, the ItemDef and ItemData entities de ne each question and its subsequent response. The ItemDef entity de nes the question asked during the study along with de ning attributes such as the datatype, data size, measurement unit, permissible range and code list. The Q.group.question attribute is the most appropriate to de ne the ItemDef entity. The logical mapping for the ItemData entity is the QR.group.question attribute. The response to the question is then contained within the question.answer sub-attribute. This model works best in a lifestyle study scenario using questionnaires in the traditional question-answer mode. In the case of longitudinal clinical studies where the responses are analogous to a patient's observations during an episode of care, we believe the ItemData entity to be more appropriately represented using the Observation resource. Furthermore, as outlined in the FHIR speci cations, data captured in questionnaires can be di cult to query after the fact. Individual items within a QR or an Observation are subsequently linked back to the Encounter in which they occur. 4
The FHIR resources provide a good t to semantically enrich the extracted data from the CDISC ODM. In spite of its shortcomings in providing context to the clinical data, the CDISC ODM provides a sound hierarchical framework for capturing the clinical data that needs to be replicated in the new model. Several assumptions have been made when mapping the ODM data to the FHIR resources because their objectives di er and this work represents one view of how the mapping can be achieved. We chose to model the study as a CarePlan because we want to model the activities planned for the patient during the study in the context of the study protocol. The CarePlan resource o ers a number of attributes, such as context, category and description that can provide additional context to the care plan. The clinical data pertinent to a patient is modelled using the ClinicalImpression resource. The ClinicalImpression permits very pertinent information to be associated to the patient's data through the use of the trigger, investigations and summary attributes. Furthermore, it makes it possible to explicitly link the protocol followed and to associate the findings to the clinical data.
The StudyEventDef is modelled as an activity within the care plan. At a macro level, the study event data is categorised as an EpisodeOfCare. The EpisodeOfCare resource provides broad context to the study event. At a micro level, each visit within the study event is represented as an Encounter. This provides a richer summary of the activity performed, allowing each visit to be described atomically and linked back to the event using the episodeOfCare attribute. However, this requires the ODM data to be rich and accurate enough. This is particularly important for study event activities that occur at di ering times in a particular day.
The Questionnaire resource is a suitable match for mapping ODM forms.
However, as outlined in section 3.4, forms are often ill-conceived in ODM and
as discussed in sections 3.5 and 3.6, the tendency is not to organise questions in
a contextual manner but in one that be ts the data capture process. The
implication is that tremendous e ort, which grows exponentially with the size of the
study, must be expended to semantically enrich the clinical data by regrouping
it contextually and integrating it with the relevant domain ontologies [
As outlined in section 3.6, we advocate the use of the Observation resource to model the responses from item data. FHIR considers the Questionnaire resource to be a specialisation of the Observation resource. The appeal in adopting the Observation resource to store the ItemData responses is the ability to store important contextual information alongside the clinical data. Speci cally, the dataAbsentReason attribute, which enables some justi cation to be provided as to the absence of a measurement, is very important in a clinical study setting, as is the ability to interpret the observation in the context of a controlled vocabulary or ontology. Furthermore, an Observation allows pertinent information such the method, specimen and performer but also the device, bodySite and related attributes to be coupled with the data, which is very useful when observing clinical data such as vital signs.
Ultimately, the aim of this work is to stimulate a debate on the most e
ective way to model clinical study data. While mapping ODM to FHIR is, in our
view, a suitable solution, we do not regard it as a permanent one.
Fundamentally, FHIR has the potential to manage clinical data in its own right. This has
numerous advantages because as discussed in [
Several researchers have initiated approaches to address the semantic enrichment
of clinical data with a view to achieving interoperability. One such approach, the
Linked Clinical Data Cube (LCDC) [
Dugas [
Abler et al. [
The Pharmaceutical Users Software Exchange5 community, in concert with the FDA, has started work on RDF representations of various CDISC models6,
5 http://www.phusewiki.org/wiki/index.php?title=Semantic Technology
6 https://github.com/phuse-org/rdf.cdisc.org
including the terminologies published by the National Cancer Institute (NCI)
Enterprise Vocabulary Services7. This community has started to evaluate the
RDF Data Cube [
The HL7 Working group on Semantic Interoperability8 has initiated some work on translating the XML or JSON version of FHIR into FHIR RDF. This work is still in draft mode and we will look at translating our solution into FHIR RDF once it has reached a more mature level. 5
As secondary use of clinical data gathers momentum, it will become increasingly important to share and compare clinical studies. We have presented an approach that integrates clinical data extracted from CDISC ODM to the FHIR resources. This work takes advantage of the rich information model comprising the FHIR resources to semantically enrich the clinical data and reintroduce the domain information that was omitted during the data capture phase. The objective is to achieve semantic interoperability of clinical study data by standardising and normalising the data along the same metrics. The main contribution is a framework to organise clinical data in a manner that preserves its organisation but captures its context. A sample of this mapping is available at: http://healthinet.it.csiro.au/net/odmFhirMapping/. activity
CarePlan value
encounter Observation encounter