D7.1 Federated Infrastructure for eCRFs...TRANSFoRm FP7-247787 D7.1 Federated infrastructure for eCRFs 8 1. Introduction The core objective of TRANSFoRm is to produce a digital infrastructure

TRANSFoRm FP7-247787 D7.1 Federated infrastructure for eCRFs

1

Translational Research and Patient Safety in Europe

D7.1 Federated Infrastructure for eCRFs

Work Package Number: WP7

Work Package Title: Core Tools and Services for Interoperability

Nature of Deliverable: Report

Dissemination Level: Public

Version: 1.0

Delivery Date From Annex 1: M51

Principal Authors: Mark McGilchrist, Piotr Bródka, Andrzej Misiaszek,

Włodzimierz Tuligłowicz, Lei Zhao, Sarah N. Lim

Choi Keung

Contributing Authors: Radosław Michalski, Vasa Curcin, Theodoros N.

Arvanitis

Partner Institutions: University of Dundee, University of Warwick,

Politechnika Wroclawska, Karolinska Institutet,

Imperial College London, King’s College London

Internal reviewers: Ita Richardson, Wolfgang Kuchinke

This project has received funding from the European Union’s

Seventh Framework Programme for research, technological

development and demonstration under grant agreement no

247787 [TRANSFoRm].


2

Version History

Version Date Author (partner) Changes/reason0.1(draft) 12.05.2014 Sarah N. Lim Choi

Keung (UW)

Lei Zhao (UW)

First draft combining input aboutthe DNC from Mark McGilchrist andrelevant parts from D7.3 draft.

Writing of Sections 1 Intro and 2TRANSFoRm Models.

0.2 (draft) 22.05.2014 UW, WRUT Description of the TRANSFoRmStudy System in Section 3.1.Revision of document.

0.3 (draft) 22.05.2014 UW Revision based on feedback fromco-authors.

0.4 (draft) 23.05.2014 UW, IC Revision following feedback1.0 (final) 30.05.2014 UNIVDUN, UW, IC Revision based on feedback from

co-authors.Final document release.


3

Table of Contents

Version History ......................................................................................................... 2

List of Figures........................................................................................................... 4

List of Tables ............................................................................................................ 5

Abbreviations............................................................................................................ 6

Executive Summary ................................................................................................. 7

1. Introduction ........................................................................................................ 8

2. TRANSFoRm Models for Semantic Interoperability........................................ 9

3. Architecture...................................................................................................... 12

3.1. TRANSFoRm Study System ....................................................................... 13

3.1.1 Forms extraction ............................................................................................................ 14

3.1.2 Randomisation............................................................................................................... 17

3.1.3 Alarm symptoms and signs monitoring.......................................................................... 20

3.2. Communication between DNC and SS........................................................ 21

3.2. Communication between DNC and EHR..................................................... 23

4. End-to-end Integration Workflow ...................................................................... 27

4.1 Enrolment check.......................................................................................... 27

4.2 Study eligibility check for computable criteria .............................................. 28

4.3 Form preparation, process and storage....................................................... 29

4.3.1 Form preparation and filling by the DNC (Scenario A) .................................................. 31

4.3.2 Form preparation and filling using both the EHR application and the DNC (Scenario B)

32

4.3.3 Form preparation and filling using the EHR application only (Scenario C) ................... 33

4.4 TRANSFoRm Study System Generated Forms........................................... 34

4.5 Storage of forms.......................................................................................... 34

4.5.1 Scenario A ..................................................................................................................... 35

4.5.2 Scenario B ..................................................................................................................... 36

4.5.3 Scenario C ..................................................................................................................... 36

4.6 Viewing forms stored in the EHR................................................................. 37


4

4.7 Initialisation of EHRs ................................................................................... 37

5. Conclusions ........................................................................................................ 39

References .............................................................................................................. 40

Appendices ............................................................................................................. 41

Appendix A – TRANSFoRm Study System: server deployment guide.................. 41

Appendix B – Message structures......................................................................... 43

Appendix C – Patient enrolment calls.................................................................... 44

Appendix D – EC checking calls............................................................................ 44

Appendix E– Form storage calls............................................................................ 45

Appendix F – Form handling calls (patient specific) .............................................. 46

Appendix G – System-system calls ....................................................................... 47

List of Figures

Figure 1: Platform conceptual components: TSS, DNC and data source. Other

connectors cover the movement of requests and responses between the various

components....................................................................................................... 12

Figure 2: General workflow for an RCT within the patient consultation. ................... 24

Figure 3: Message flows between RCT system components and their associated

naming conventions........................................................................................... 25

Figure 4: EHR interface module ............................................................................... 26

Figure 5: Location of DNC in relation to the client-server architecture of the EHR

system. The chosen configuration is vendor dependent and the communication

environment (dotted boundary) is considered safe............................................ 26

Figure 6: Workflow for enrolment check. .................................................................. 28

Figure 7: Workflow for checking computable eligibility criteria.................................. 29

Figure 8: EHR and DNC components and their use of forms, ODM transport files and

queries. Colour is used for highlighting only. Forms, ODM files and query files


5

are authored centrally and held on the study system. These forms can be used

at runtime by the DNC, or are held by the EHR system in native formats for its

direct use........................................................................................................... 30

Figure 9: Workflow for preparing and filling a study form where the EHR application

offers no facilities for this purpose. The DNC coordinates all activities using a

local web browser as the user interface to fill the form. ..................................... 32

Figure 10: Partial workflow for completing a form using the EHR application as the

user interface..................................................................................................... 33

Figure 11: Workflows for storage of ODMs............................................................... 35

Figure 12: Viewing a form stored in the EHR with the help of the DNC.................... 37

Figure 13: DNC:Reset message. For those vendors that require it, all forms and

computable EC are provided in a RESET message to the EHR. ...................... 38

List of Tables

Table 1: Operations for an RCT modelled as form collections.................................. 22

List of Equations

Equation 1: Formula for the probability of assigning a new patient to the first arm of

study in one of the randomization blocks........................................................... 19


6

Abbreviations

CROM Clinician Reported Outcome Measures

DNC Data Node Connector

EC Eligibility Criteria

eCRF electronic Case Report Form

EHR Electronic Health Record

ESP EHR Signalling Protocol

GP General Practitioner

ODM Operational Data Model

PROM Patient Reported Outcome Measures

RDBMS Relational database management system

SDB Study Database

SDM Study Design Model

SS TRANSFoRm Study System

W/S Web Service


7

Executive Summary

This deliverable (D7.1) describes the outcomes of Worktask 7.4: Infrastructure that

manages the deployment of functional eCRFs in EHR systems. It reports on the

management of functional eCRF deployment within EHR systems for data collection

into study databases, and the management of the interactions between the EHR

systems and the TRANSFoRm Study System for study-specific and event-triggered

data collection.

As a comprehensive digital infrastructure to support learning healthcare system

(LHS), TRANSFoRm aims to advance the integration between clinical research,

especially RCTs, and routine healthcare. The ability of embedding clinical trial tasks

within daily healthcare workflow and interoperating with local IT infrastructure is

essential to implement this linkage. Following a model-based semantic mediation

approach for data integration, the system is designed as a service oriented

architecture, with a number of loosely coupled, self-contained software units

implemented as Web services, delivering the required technology support for

randomised clinical trials.

The TRANSFoRm Study System (SS) handles the collection of data using eCRFs

from within an EHR system, from the identification of eligible patients to the end of

data collection, following the study protocol. The study is defined using a custom

extension to CDISC SDM format. The TRANSFoRm infrastructure allows the transfer

of data requests from the SS to the EHR system (where eCRF forms are displayed

and completed) via the Data Node Connector (DNC). The DNC includes a set of

components that support the interactions with the local EHR via structured

messages. The functionality of the different components is described through end-to-

end integration workflows for different activities, such as participant enrolment check,

form preparation and storage. The workflows also cover different scenarios based on

the requirements of EHR vendors.


8

1. Introduction

The core objective of TRANSFoRm is to produce a digital infrastructure that supports

translational research by facilitating the reuse of routinely collected primary care data

in different types of clinical research, including epidemiological studies, randomized

controlled trials (RCT) and diagnostic decision support. An essential aspect of this

infrastructure is to manage the deployment of functional electronic Case Report

Forms (eCRF) into primary care electronic health record (EHR) systems and

coordinate study-specific event-triggered data collection activities within those EHR

systems. The Gastroesophagal Reflux Disease (GORD) use case will use the

infrastructure to conduct a real randomised clinical trial: recruit patients based on the

EHR records for the trial during their normal GP visits, issue the eCRFs from within

the primary care centres to collect Care Reported Outcome Measures (CROM), and

gather complete case data in a central study database available to the researchers.

Specifically, this infrastructure should deliver the following functions in order to

support RCTs:

Deployment of functional eCRFs into EHR systems

Coordination of study execution across distributed study sites in different

countries

Discovery of potential study subjects

Identification of study-specific events and time based on the study research

protocol

Study event triggered data collection with study eCRFs embedded in EHR

systems

Pre-population of eCRFs with available EHR data

Collection of data from eCRFs into study specific databases

Adverse event monitoring and automatic alarm notification to both GP and

study investigators

A key challenge for the implementation of this infrastructure is to ensure both

syntactic and semantic interoperability across heterogeneous EHR systems. The

European EHR systems are generally implemented using different technology stacks

and expose diverse access interfaces. The data itself is also stored in different

structure and format and often coded in varied coding schemas, which are


9

sometimes proprietary. To overcome the syntactic barrier, TRANSFoRm develops a

specific communication protocol to enable communicate and exchange information

between the TRANSFoRm system and EHRs. The protocol is implemented using

standard Web services technologies which are widely supported by cooperative EHR

vendors. This messaging mechanism and its technical implementation are detailed in

this document. For the semantic interoperability, TRANSFoRm uses a model-based

mediation approach to address both the structural and terminological heterogeneity

in a unified interoperability framework (D6.3 [1]). An overview of the semantic models

is presented briefly in the next section.

2. TRANSFoRm Models for Semantic Interoperability

Semantic modelling is an essential part in the development of TRANSFoRm

infrastructure. The models underpin the design of all software tools and ensure their

interoperability for concrete information exchange.

CRIM (Clinical Research Information Model) establishes the framework for

integration of clinical research covering RCT, case-control and retrospective cohort

studies into the TRANSFoRm application development. CRIM extends the Primary

Care Research Object Model (PCROM) to include new information objects, episode

of care related objects and high-ranking concepts (areas), while satisfying all the

requirements from the TRANSFoRm research use cases. It is implemented as a set

of UML models that are instantiated in the features of TRANSFoRm software tools

and underpin the development of the infrastructure to manage eCRFs in EHR

systems. Please refer to D6.2 [2] for more information regarding CRIM.

CDIM (Clinical Data Integration Model) [3], [4] is a global mediation model expressed

as ontology for use in the primary care domain. It uses a realist approach employing

Basic Formal Ontology (BFO v1.1) as an upper ontology. Other ontologies were

imported or specialized to give deeper definition to the concepts in the domain.

These included OGMS, IAO and VSO. The CDIM ontology includes concepts that are


10

especially important to primary care (e.g. episode of care or reason for encounter),

but also others to handle temporality in queries (e.g. the start and beginning of

processes). The ontology is stored as OWL files and managed using Protégé 4.2. It

is deployed using the LexEVS 6 platform.

DSM (Data Source Model) describes the internal structure of data sources such as

RDBMS, XML documents and HL7 messages. It is designed to be a target for

mapping CDIM concepts to structural elements within the sources and is used by the

mediator for query translation. During the design, a range of EHRs were investigated

for their data models and user-defined data types. This was done through a review of

specifications for various data models and also with the assistance of staff familiar

with the data source. The instantiated source models are stored as XML files, which

can be viewed with any XML reader, such as a web browser. These model files are

deployed via the LexEVS 6 platform using a custom loader.

CDIM-DSM mapping model is required to express how concepts from the CDIM are

related to one or more structural elements of the DSM using a variety of operators.

Operators can be assembled in parallel or in series and support numerical and string

operations as well as built in functions. Knowledgeable staff at the data sources must

comprehend the meaning of the CDIM concept and establish the best match to the

structural elements in the data source model and combine these in the appropriate

way. The concepts of the CDIM are expressed independently of the data sources so

such mappings are not guaranteed to exist. The mapping models are stored as XML

files, which can be viewed with any XML reader, such as a web browser. They are

deployed using the LexEVS 6 platform, via a custom loader. D6.3 [1] presented a

more detailed discussion about CDIM, DSM, and CDIM-DSM mapping models.

Archetypes are computable expressions of a domain content model in the form of

structured constraint statements, based on some reference model. Archetypes were

developed by openEHR [5] as a generic modelling technique to specify detailed

clinical models (DCM) that combine clinical knowledge, data type definition, data

point relationships, and reference terminologies into formal representations.


11

Archetypes are expressed in Archetype Definition Language (ADL), a formal

language which allows computer processing in various technical contexts, such as

EHR, messaging, data warehouses and clinical decision support systems. Archetype

is characterised by a two-level modelling paradigm, where all information is described

using a generic reference model that enables a wide variety of health information to

be stored and then the structure of that information is further constrained by an

archetype. An archetype is a constraint model that limits the structure of certain kinds

of information such as clinical tests, care plans, etc. so that only data of a certain

structure and quality can be added to the record. In the context of TRANSFoRm,

archetypes have a binding with CDIM and are embedded into ODM documents.

Query Model is necessary to formulate query requests for eligible patient

identification and patient data extraction. The query model uses archetypes as

clinical data specifications and allows arithmetic calculations and mathematic

functions. It also supports complex Boolean logic and temporal constraints. A number

of different types of query requests can be constructed using the model to support

TRANSFoRm use cases, such as returning counts of eligible patients, flagging

eligible patients, and extracting patient data for those who are flagged. These actual

queries are expressed in xml format and are embedded in eCRFs to enable form pre-

population with EHR data. The complete query model is discussed in D5.4, as well as

the concrete queries to be embedded in the eCRFs for the GORD study.

Study Model: The TRANSFoRm study model is based on CDISC Study Design

Model (SDM) and works within the scope of the CRIM. The study model describes

the lifecycle of the study data collection process, including activities such as informed

consent and randomisation, as defined in the study protocol. It also supports data

collection using various methods (mobile, web interface, EHR embedded eCRF), in

various languages, and is in a format that can be deployed within an EHR system

(e.g. XML format). The model extends the SDM, by attaching semantically

interoperable queries to form questions, to enable EHR data to be extracted and pre-

populate eCRFs where applicable. The deliverable D5.4 demonstrates how a

detailed study model is developed for the GORD use case.


12

3. Architecture

With respect to supporting eCRFs, the TRANSFoRm platform realises the basic

operation of requesting for data embedded within an ODM, issued by a TRANSFoRm

study system and targeted at an EHR system. The platform’s conceptual

components, which mediate these operations, are shown in Figure 1 and are

described below.

Figure 1: Platform conceptual components: TSS, DNC and data source. Otherconnectors cover the movement of requests and responses between the various

components.

The TRANSFoRm Study System (SS) stores study information and processes, and

manages and deploys the applications for the collection of patient reported outcome

measures (PROMs). An overview of the system is given in Section 3.1 and further

details are given in D5.5 and D7.3.


13

The Electronic Health Record (EHR) system is the data source where data that can

be used for pre-populating eCRFs are extracted from.

In between the TRANSFoRm Study System and the EHR system are various

connectors and a component called the Data Node Connector (DNC). The

connectors simply offer a means of moving information around using web service

calls; while the DNC provides the management of activities necessary to complete

the operations.

The SS is the source of multiple queries (for data), embedded within a CDISC ODM

document, which forms a container for the queries (see D5.4 for further details) and

also permits GP completion where the query cannot be satisfied by the EHR alone in

an RCT scenario. The embedded queries are subject to translation by the semantic

mediator, and the DNC ensures this.

After semantic mediation the queries are held as files and the eligibility criteria of a

study as received by the DNC are continuously tested against structured patient EHR

documents (XML) as patients come and go in consultation with GPs. These criteria

can also be inspected and authorised by the console component before first use.

The SS and DNC will be described showing how they use data sources (including

GPs) to satisfy the demands of study ODM files with embedded queries.

3.1. TRANSFoRm Study System

The TRANSFoRm Study System (SS) is a platform designed and implemented in

order to facilitate the execution of TRANSFoRm GORD (Gastroesophageal Reflux

Disease) use case described in D1.1[6]. A deployment guide of the SS is provided in

Appendix A.

The main task for the TRANSFoRm project was to create an infrastructure which will

be able to:

1) create the whole study based on its CDISC SDM representation

2) find eligible patients in supported EHR systems of different vendors,

3) enrol the patient into the study,

4) enable execution of the study by providing the secure interface for patients

and GPs to fill out the PROM and CROM questionnaires, and to store the


14

answers,

5) monitor study timeline for each patient to make sure that questionnaires are fill

out on time and if necessary to send the reminders to the patient,

6) monitor the patients’ answers for alarm symptoms and signs and if necessary

to notify the GP responsible for the patient,

7) populate all the required data from the SS to EHR systems,

8) and finally present study statistics to GPs, related to patients for which this GP

is responsible, and researchers who conduct the study.

Except for the tasks 2 and 3, the SS is entirely or partially (with the Data Node

Connector (see next sections)) responsible for proper execution of those tasks. The

full description of SS can be found in Deliverable 5.5 and 7.3. This section describes

only how SS utilizes SDM to perform its tasks.

The workflow for creation of a new SDM starts when the SDM is registered in SS,

creating the new study. The tasks involved are:

1. The whole SDM is stored in Study Database

2. All forms (eCRFs in ODM form) are extracted and stored in the Study

Database

3. Study timeline is extracted and assign to each form

4. Randomisation blocks are extracted and randomisation list for each block is

created

5. The reference to the SDM and whole study is returned to DNC

After that the SS is prepared to receive new participants from DNC.

3.1.1 Forms extraction

At the beginning the general frame for form is created:


15

The above XML is constructed by removing all children elements from

MetaDataVersion and all other children elements from Study element. Next for every

FormRef with unique FormOID in StudyEventDef, a separate xml is stored in the

database by filling the frame shown above with appropriate elements.

Next, the description element with its children is cloned and stored separately with

the XML of single form as additional attribute. Similarly, for the FormType element, its

<ODM xmlns="http://www.cdisc.org/ns/odm/v1.3"

xmlns:sdm="http://www.cdisc.org/ns/studydesign/v1.0"

xmlns:transform="http://www.transformproject.eu/v1.0" CreationDateTime="2013-10-

28T14:05:28" Description="GORD Pilot Study Design, CDISC ODM version 1.3 format"

FileOID="GORD_PILOT" FileType="Snapshot" Granularity="Metadata" ODMVersion="1.3"

SourceSystem="TRANSFoRm" SourceSystemVersion="1.0">

<Study OID="GORD-Pilot">

<GlobalVariables>

<StudyName>TRANSFoRm GORD Evaluation</StudyName>

<StudyDescription>some text.</StudyDescription>

<ProtocolName>GORD_evaluation_METCprotocol</ProtocolName>

</GlobalVariables>

<BasicDefinitions/>

<MetaDataVersion Description="evaluation " Name="GORD pilot SDM v1"

OID="GORD_Pilot_SDM_v1">

<!—place for form def and other needed elements -->

</ MetaDataVersion>

</Study>

</ODM>

<StudyEventDef Name="First Visit" OID="SE.FIRST_VISIT" Repeating="No"

Type="Scheduled">

…

<FormRef FormOID="FD.INCLUSION_EXCLUSION" OrderNumber="1"

Mandatory="Yes"/>

<FormRef FormOID="FD.STUDY_STATS" OrderNumber="2" Mandatory="Yes"/>

<FormRef FormOID="FD.INFORMED_CONSENT" OrderNumber="3"

Mandatory="Yes"/>

…

</StudyEventDef>


16

value is copied from XML and stored in the database as additional attribute. The

whole FormDef is appended to the frame.

For each ItemGroupRef its attribute ItemGroupOID is extracted and is used to find

elements named ItemGroupDef with the same value of its OID. Unique

ItemGroupDefs are also appended to the XML.

Afterwards for each ItemRef a similar to the previous procedure is done to gather all

of the ItemDefs. They are also appended to the XML.

At the end for each CodeListRef a similar to the previous procedure is done to gather

all of the CodeList which are also appended to the XML.

<FormDef OID="FD.INCLUSION_EXCLUSION" Name="Inclusion/Exclusion Criteria Form"

Repeating="No">

<Description>

<TranslatedText xml:lang="en">Inclusion/Exclusion Criteria</TranslatedText>

</Description>

<ItemGroupRef ItemGroupOID="IG.INCLUSION" Mandatory="Yes"/>

<ItemGroupRef ItemGroupOID="IG.EXCLUSION" Mandatory="Yes"/>

<transform:FormType>ActivityForm</transform:FormType>

</FormDef>

<ItemGroupDef Name="PROM Demographics ItemGroup" OID="IG.PROM_DEMOGR"

Repeating="No">

<Description>

<TranslatedText xml:lang="en">PROM Demographics</TranslatedText>

</Description>

<ItemRef ItemOID="ID.HOUSEHOLD" Mandatory="Yes" OrderNumber="1"/>

<ItemRef ItemOID="ID.EMPLOYMENT" Mandatory="Yes" OrderNumber="2"/>

<ItemRef ItemOID="ID.EDU" Mandatory="Yes" OrderNumber="3"/>

</ItemGroupDef>


17

This procedure allows to extract the form with all necessary information. This ensures

that the TRANSFoRm Study System can render and process any form very fast

without the need to analyse the whole SDM.

3.1.2 Randomisation

In the SDM file there is an element called ParticipantSegmentVariables in the

TRANSFoRm namespace. This element contains the definitions of both

randomization variables and their ranges. For example we can define a variable for

gender with the ranges for males and females if we are interested in examining

males and females separately (one variable, two ranges).

<ItemDef DataType="text" Length="10" Name="Difficulties Swallowing Yes/No Item"

OID="ID.DFCLT_SWALLOW">

<Question>

<TranslatedText xml:lang="en">Difficulties swallowing</TranslatedText>

</Question>

<CodeListRef CodeListOID="CL.YN"/>

<transform:Alarm>

<transform:Condition value="YES"/>

</transform:Alarm>

</ItemDef>


18

Based on the definition as above n randomization blocks are defined for study, where

n =�ෑ ݎ

||

ୀଵ

ri is the number of ranges defined in i-th variable and |V| is the number of variables

<transform:ParticipantSegmentVariablesxmlns="http://www.transformproject.eu/v1.0">

<Variable itemRefOID="ID.BRTHYR" varOID="PSV.Var1"><Name>Year of Birth</Name><Description><TranslatedText xml:lang="en">Year of birth of patients</TranslatedText>

</Description><Type>integer</Type><Unit/><Ranges><Range rangeOID="Var1.R1">

<Relation>GE</Relation><Value>1964</Value>

</Range><Range rangeOID="Var1.R2">

<Relation>LT</Relation><Value>1964</Value>

</Range></Ranges>

</Variable><Variable itemRefOID="ID.GENDER" varOID="PSV.Var2"><Name>Gender</Name><Description><TranslatedText xml:lang="en">Gender of patients</TranslatedText>

</Description><Type>text</Type><Unit/><Ranges><Range rangeOID="Var2.R1">

<Relation>EQ</Relation><Value>MALE</Value>

</Range><Range rangeOID="Var2.R2">

<Relation>EQ</Relation><Value>FEMALE</Value>

</Range></Ranges>

</Variable>

</transform:ParticipantSegmentVariables>


19

defined.

If there are three variables and they have two, three and four ranges respectively,

exactly 2*3*4 = 24 randomisation blocks will be generated. Each block is defined by

one range from each variable. To name each block combinations of their OID’s are

used as in the following example: PSV.Var1:R.R1;PSV.Var2:R.R1. Each block in the

database has its own XML that defines it. The XML is made by deleting all ranges

that are not relevant to the block. Afterwards, for every block two arms of study are

defined A and B. In case of GORD use case it is continuous PPI and on demand PPI.

For each block the randomization procedure is performed i.e. the randomisation list is

created. The randomisation list is created based on Constrained Randomization1

procedure. For each block SS creates 100 segments with 10 people in each

segment. In each segment the probability that the new participant will be assigned to

the A arm is defined as in Equation below, where NA (NB) is the maximum number of

participants from A (B) arm in this segment, and nA (nB) is the number of participants

that have been already assigned to the arm A (B). In the GORD use case we

assigned NA = NB = 5.This procedure ensures that regardless of how many patients

will be enrolled both arms will be almost balanced. .

BB

AA

BABA

AA

AA

Nnif

NnifnnNN

nN

Nnif

A

1

0

0

]Pr[

Equation 1: Formula for the probability of assigning a new patient to the first arm ofstudy in one of the randomization blocks

1https://onlinecourses.science.psu.edu/stat509/node/66


20

3.1.3 Alarm symptoms and signs monitoring

One of the key extension of the CDISC standard is the transform:alarm namespace.

It is a part of the ItemDef element of a ODM. Based on that element the SS knows

which specific answer should be monitored for alarm symptoms.

Before patient answers are saved in the SDB (Study Database) they are checked for

adverse alarm symptoms. The first step is to parse a blank ODM file for answers

which may contain Transform:alarm tags and cross-references them with patients

answers. If an answer with match alarm symptom answer is discovered the form filled

by the patient is saved in the SDB with flag isAlert=1. Form without alarm symptoms

is saved with flag isAlert=0 (For the details of SDB see Deliverable 5.5 Mobile

eHealth application for the delivery of Patient Related Outcome Measures).

Below the fragment of an SDM file with Transform:alarm can be seen.

In the transform:Condition segment is the exact value which will trigger an alarm. The

second example presents the patient answers.

<ItemDef OID="ID.DFCLT_SWALLOW" Name="Difficulties Swallowing Yes/No Item"

DataType="text" Length="10">

<Question>

<TranslatedText xml:lang="en">Difficulties swallowing</TranslatedText>

</Question>

<CodeListRef CodeListOID="CL.YN"/>

<transform:Alarm>

<transform:Condition value="YES"/>

</transform:Alarm>

</ItemDef>


21

The patient has chosen "YES" which matches the transform:Condition value in the

ItemDef segment and that will flag the "isAlert" field with value "1".

In order to trigger the GPs reaction for alarm symptom, every few minutes the DNC

asks the SS if there are any new forms where "isAlert" flagged as "1". If there is such

a form the information about it is passed to DNC and DNC contacts proper EHR

system in order to pass the information about alarm symptom to the GP.

3.2. Communication between DNC and SS

This DNC component mediates the relationship between a vendor’s EHR system and

the TRANSFoRm Study System. It communicates with the SS through a connector

that consists of standard REST web services. In this instance, DNC polls the SS with

POST and GET methods over HTTPs to exchange XML messages. For any given

study, DNC can ascertain the status of a study volunteer and their position within the

study schedule and download study forms for completion when the timing is

appropriate. It will also upload completed forms and the SS will acknowledge these

explicitly.

In the present discussion a form consists of three components: (1) an HTML

document for viewing and data collection, (2) an ODM file for submitting data to the

SS, and (3) an XML file of queries referenced by the HTML and ODM files. These are

<ClinicalData StudyOID="ST.001" MetadataVersionOID="MD.001">

<SubjectData SubjectKey="adamek">

<StudyEventData StudyEventOID="PROM_Event">

<FormData FormOID="FD.DFCLT_SWALLOW">

<ItemGroupData ItemGroupOID="IG.DFCLT_SWALLOW">

<ItemDataString ItemOID="ID.DFCLT_SWALLOW">

YES

</ItemDataString>

</ItemGroupData>

</FormData>

</StudyEventData>

</SubjectData>

</ClinicalData>


22

typically transmitted together in a single message when a form is requested from the

SS by DNC, and the ODM is transmitted in a separate message for storage within the

study or EHR system. Both the HTML and ODM files contain embedded query

references where it is desired to pre-load data using the EHR. These embedded

queries are replaced by actual data values before the forms are used by the GP.

In the TRANSFoRm project, nearly all operations performed in an RCT are modelled

as form collection, as illustrated in Table 1.

Table 1: Operations for an RCT modelled as form collections.

RCT operation Implementation as a form

Eligibility Criteria Expressed as multiple queries and embedded in a form (HTML and

ODM). The EC will always include non-computable criteria which must

also be collected; hence the use of a form is appropriate. The GP

completes the form for all criteria awaiting completion, including those

which automation could not deliver. This form and its completed values

can be stored within the EHR. At this stage, consent has not yet been

obtained.

Consent This form allows for the collection of additional information beyond a

simple agreement to take part. It can record email address for future

communication with the patient and any additional options that the

study affords the patient, such as study access to patient follow-up

data. This form would be stored in both EHR and study databases.

Randomisation Patients and physicians are not blinded in the GORD study. A form

delivers the randomisation to the EHR and is accepted or rejected by

the GP/Patient and stored in the EHR.

CROMx Clinician reported outcome measures. Preload values are expressed as

individual queries in the form. The DNC uses the semantic mediator to

translate these queries to XQuery statements for execution against a

patient’s XML record.


23

PROMx Patient reported outcome measures. These forms consist only of ODM

files containing data values as these were collected by the TSS directly

from mobile devices belonging to the patients. These forms

subsequently get stored in the EHR when DNC determines that they

are available.

Withdrawal These forms are generated by the study system and record data

associated with withdrawal. These forms subsequently get stored in the

EHR when DNC determines that they are available.

Alarm These forms are generated by the study system and record data

associated with alarm conditions. These forms subsequently get stored

in the EHR when DNC determines that they are available.

RESTful web services that use XML messages for communication are described in

D7.3, Section 2.6.

3.2. Communication between DNC and EHR

The DNC component handles the eligibility criteria (EC) query that must be parsed to

extract the individual queries for execution against an XML document provided by the

EHR system. The results are presented to the GP in a form window to enable entry of

those data values still required, and to confirm those data values that were extracted

automatically. This DNC component has presented the greatest challenge in terms of

interoperating with EHRs from multiple vendors.

The interoperation of DNC and the EHR system has been modelled as a set of

workflows, which have a similar role to IHE profiles (such as Retrieve Form for Data

Capture Profile [7]). These workflows are implemented as a set of XML messages

(called EHR Signalling Protocol) driving specific logic within the component. We will

first describe the general workflow supporting an RCT scenario within a patient

consultation (Figure 2), and then more detailed scenarios for specific operations and

how the ESP messages support these operations.


24

The study schedule and data collection are specified as a set of forms described in

Table 1. When the patient enters a consultation with a GP, the EHR system notifies

DNC of the contents of the patient record (XML). The DNC determines whether this

patient is already enrolled and the next option that is available (if any). If the patient is

not already enrolled, the record is queried with XQuery statements to determine

whether it satisfies the computable eligibility criteria. If it does the DNC offers the EC

form as the next option. Whatever the next option, a form is retrieved from the SS,

and prepared and processed for use by the EHR system. Following the form

collection, the completed (or abandoned) form is stored in both the study and EHR

systems.

Figure 2: General workflow for an RCT within the patient consultation.

The more detailed scenarios cover the individual components of the general workflow

shown Figure 2. We will look at each of these scenarios in turn and relate them to

relevant IHE profiles.

Figure 3 shows the system components, message flows and their message naming

convention. Messages are XML documents exchanged using standard web services

– HTTP GET and POST methods – and are given name spaces associated with their


25

target components.

Figure 3: Message flows between RCT system components and their associatednaming conventions.

EHR vendors agreed to develop a module interfacing the web service calls to the

underlying API or database calls for their EHR system (See Figure 4). This module

isolates EHR system technology and API knowledge from TRANSFoRm.

At the vendor’s discretion this new module can be wholly or partially contained within

the existing EHR system. Study systems, however, are expected to natively provide

web service calls for their message functions.

In nearly all message examples, the content relates to forms and includes their HTML

representation, their ODM transport equivalents and sets of queries referenced by

the HTML or ODM. One or all of these can be carried within the overall ESP

message structure (Appendix B).


26

Figure 4: EHR interface module

All vendor systems have a client-server configuration and the DNC interfaces to

either the server or client side as shown in Figure 5. Communication between the

DNC and the EHR is always local, i.e. communication is bi-directional and no

firewalls intervene. This network environment is considered safe and no particular

security precautions are taken by TRANSFoRm to protect the messages.

Figure 5: Location of DNC in relation to the client-server architecture of the EHRsystem. The chosen configuration is vendor dependent and the communication

environment (dotted boundary) is considered safe.


27

4. End-to-end Integration Workflow

In this section, the detailed descriptions of general workflow components are given.

4.1 Enrolment check

All EHRs must test for enrolment when a new patient consultation is opened. The

EHR interface module (EIM) detects the opening of a patient record for a consultation

and makes a web service call to the DNC asking whether the patient is enrolled in

any study. The DNC relays the contents of this message as a study-system web

service call and the response is relayed back to the EHR module. Two ESP message

are involved in this workflow: DNC:IsEnrolled and SS:GetPatientOptions. The SS

maintains patient state for each study the patients are enrolled in and can store and

retrieve documents for EC, consent, CROMs, PROMs, alarms, and withdrawal. The

message response from the SS indicates the next available form(s) and activities

they support, according to the study schedules. Therefore, the response to the

DNC:IsEnrolled message provides all the information that is needed by the GP to

interact with the patients about the joined studies at this point. It is important that all

vendor systems make this call to ascertain patient status since withdrawal requests

and clinical alarms must be acted on in real time. The message definitions described

here are provided in Appendix C and the workflow in Figure 6. In this workflow for

enrolment check, all newly opened patient records must be checked against the SS

for existing enrolment. The SS maintains patient state for each study and can

store/retrieve documents for EC, consent, CROMs, PROMs, alarms, and withdrawal.

This ensures withdrawals and alarms can be acted on at the earliest opportunity. The

SS processes the content of CROMs and PROMs for alarm generation.


28

Figure 6: Workflow for enrolment check.

4.2 Study eligibility check for computable criteria

If a patient is not already enrolled in an existing study, all newly opened or updated

patient records must be checked for eligibility against available study criteria. This

can be done by the EHR itself, by the DNC, or both. Since the patient record data for

this eligibility check is not consented, some vendors have taken the view that they

should perform this check and filter any resultant data before delivery to the DNC.

This is problematic where multiple studies are active. However, whatever happens,

the DNC receives the patient record (part or whole) as an XML document in a

DNC:Open or DNC:Update message (Figure 7) and performs eligibility checks

against its store of study criteria. The stores of EC that are held by the DNC and EHR

are obtained earlier using a DNC:Reset startup message. These messages are

defined in Appendix D.

The DNC uses the semantic mediator (WT 7.1) to translate the platform EC queries

to XQuery statements which are applied to the patient record XML document (Figure

7). The EC are thus evaluated for each active study available to the DNC. Where

active study criteria are satisfied the DNC issues an SS: GetPatientOptions message

to the SS. For all eligible studies, this should return the next option as the full


29

eligibility criteria form to be completed by the GP.

Figure 7: Workflow for checking computable eligibility criteria.

4.3 Form preparation, process and storage

Figure 8 shows the system components in relation to the retrieval, filling and storage

of forms. Three separate scenarios are supported based on the requirements of the

EHR vendors:

A. Vendor does not have the ability to serve forms for completion by a GP and

the DNC provides components for this purpose

B. Vendor has, or will have, the ability to dynamically serve forms as delivered by

the SS

C. Vendor has the ability to serve forms using native formats only, and runtime

conversion of SS formats is not possible

For the purposes of this discussion, a form is an HTML document with embedded

references to data queries conforming to the TRANSFoRm query model, which are


30

used by the DNC to pre-load data values. All vendors agreed to process associated

ODM transport files for storage operations.

We will consider the workflows and associated messages for each of these three

scenarios.

Figure 8: EHR and DNC components and their use of forms, ODM transport files andqueries. Colour is used for highlighting only. Forms, ODM files and query files are

authored centrally and held on the study system. These forms can be used at runtimeby the DNC, or are held by the EHR system in native formats for its direct use.


31

4.3.1 Form preparation and filling by the DNC (Scenario A)

In this scenario, the EHR passes on a request from the GP to view and fill a particular

form (Figure 9). It does so using the DNC:PrepareForm message. The DNC retrieves

the form from the SS and uses the semantic mediator to translate any embedded

queries within the form HTML. It should be noted that the HTML only contains

references to the queries, which are held in a separate queries file. The same

references are used within the associated ODM. The translated XQuery queries are

applied to the patient record XML document to extract the necessary data value if

available. These data values are then inserted into the HTML at the correct positions.

The completed HTML file is then placed in the local file store to which the embedded

DNC web server has access and the appropriate URL is returned as the response to

the DNC:PrepareForm message. The EHR application continues to run as normal

after the completion of the web service call. At this stage, the DNC activates the

browser application (IE, Chrome, Firefox, etc.) with the URL giving it the focus; the

DNC then continues its activities waiting for further messages from the EHR or

events from the SS. Once the form is prepared and visible in the browser, all three

applications continue to function asynchronously. This leaves the possibility of the

GP continuing with the consultation at any time while the form is also available.

With the activated browser, the GP now fills the HTML form and confirms the

contents with ‘submit’, or ‘cancels’. The embedded web server processes all form

submissions in a uniform manner. The submission carries all the data in the form and

additional data regarding the associated ODM file, the identity of the patient,

submitting GP and practice, form ID, etc. The web server uses this response to

complete the ODM file, which is then ready to be stored.

The result of the GP choosing to complete a form and doing so with the browser is to

complete an ODM file which the DNC holds at this point.


32

Figure 9: Workflow for preparing and filling a study form where the EHR applicationoffers no facilities for this purpose. The DNC coordinates all activities using a local

web browser as the user interface to fill the form.

4.3.2 Form preparation and filling using both the EHR application and the DNC

(Scenario B)

This scenario is very similar to the previous scenario up to the response to the

DNC:PrepareForm message. In this scenario, however, the response also includes

the pre-loaded HTML file and ODM file for the EHR application to use directly, rather

than the GP using the browser. The EHR is free to process the HTML to a native

format if so desired. The EHR application displays the form directly within the

application itself and the GP fills the form using the EHR application. This makes for

a more seamless interaction of EHR and DNC. On completion, in the same manner


33

as the DNC in the previous scenario, sufficient data is available for the EHR

application to process the GP submission to an ODM file (Figure 10).

The result of the GP choosing to complete a form and doing so with the EHR

application is to complete an ODM file which the EHR holds at this point.

Figure 10: Partial workflow for completing a form using the EHR application as theuser interface.

4.3.3 Form preparation and filling using the EHR application only (Scenario C)

In this scenario, the vendor has the ability to serve forms using native formats only,

and runtime conversion of SS formats (HTML) is not possible. In advance of study

start, the vendor sources the forms (HTML, ODM and pre-load queries) and

generates its own native forms ‘by hand’. When the GP selects a form, instead of

calling the DNC, the EHR application pre-loads data values (if possible) and displays

the form natively; allows the GP to fill the form; and processes to an ODM file. As in

Scenario B, the EHR holds the ODM at this point.


34

4.4 TRANSFoRm Study System Generated Forms

The SS maintains a library of forms for use by the EHR applications and the DNC.

However, the SS itself can directly create forms according to the study schedule. For

example, SS is responsible for requesting study volunteers complete PROMs through

mobile applications and stores the results as ODM files. This involves no interaction

with the EHRs. The SS will also receive withdrawal notifications from volunteers

which are subsequently processed to ODM files. Finally, alarms generated by the SS

using stored form data are also stored as ODM files.

4.5 Storage of forms

All form processing results in a completed ODM file that sits with a DNC, EHR

application or SS. It is desired that all ODM files, wherever they are generated, are

stored in both the EHR and SS. There is no requirement for the DNC to store

generated ODM files. The naming convention for the forms serves to identify forms

uniquely. Keep in mind that forms consist of three components HTML, ODM and data

queries.

A number of workflows and associated messages are provided to enable this storage

of forms for each scenario (Figure 11). Workflows for storage of ODMs depend on

where the ODM was generated. There are three scenarios: (A) ODM generated by

the DNC in the processing of a form; (B) ODM generated directly by the EHR

application; (C) ODM generated by the SS. The latter arises from collection of

PROMs, withdrawal notifications and generated alarms. Actions associated with form

storage at the EHR can include: alarms, withdrawal, and reminders.


35

Figure 11: Workflows for storage of ODMs.

4.5.1 Scenario A

After completion of the ODM by the DNC it must be stored in both the SS and EHR.

Two messages are provided for this purpose: SS:StoreForm and

EHR:StoreFormLocal. The formats for these messages can be found in Appendix E.

The DNC performs SS:StoreForm first so that the study schedule is updated on the

SS at the earliest opportunity and the response to the SS:StoreForm message

contains the next available option for the GP. The DNC then performs

EHR:StoreFormLocal. The EHR will store the form as a blob data type in the

underlying RDBMS, which can be referenced by its name. The EHR can then take

further actions based on any options provided in the EHR:StoreFormLocal message,

and should display these to the GP at the earliest opportunity.

No editing of forms is permitted after completion. The form stored in the EHR system

can be viewed at a future time with the help of the DNC (See Section 4.6 on viewing

stored forms).


36

4.5.2 Scenario B

In this scenario the EHR application stores the ODM as a blob in the underlying

relational database, which can be referenced in future by its name. The EHR then

makes a DNC:StoreForm call containing the ODM. The DNC transparently passes

this to the SS using the SS:StoreForm call which returns the next available option

which the GP should consider. This option is passed back to the EHR as an action to

display to the GP.

4.5.3 Scenario C

In this scenario the ODM is generated on the SS and covers the cases of PROMs for

storage in the EHR, alarms, withdrawals and CROM reminders. Since the SS cannot

call the DNC, which lies behind firewalls, the DNC must poll the SS for recent

updates (a one-minute poll interval is reasonable).

The DNC uses SS:GetNewlyCompletedForms message to detect forms requiring

storage in the local EHR. As with the SS:StoreForm message, the response to the

SS:GetNewlyCompletedForms also carries actions which the EHR should perform at

the earliest opportunity. These actions include responding to an alarm form’s

contents, a withdrawal form’s contents and a CROM form reminder. It is for the EHR

system and the GPs to decide the detail of the response to these requested actions;

the TRANSFoRm platform takes no further action. The EHR application stores the

ODM as a blob in the underlying RDBMS, which can be referenced in future by its

name.

Note well, that a reminder CROM is stored and is replaced when the CROM is

actually completed, or a further reminder arrives. In this way, a record that the

reminders having been delivered to the practice is maintained and is only removed

when the completed form is available.


37

4.6 Viewing forms stored in the EHR

All forms stored in EHRs are, as a minimum, stored as blobs in the underlying

RDBMS. Where the EHR prepared and filled these forms, it should be perfectly

possible to view the stored forms at any time. Where the EHR did not collect the

forms, but left this to the DNC, subsequent viewing of the form must also be through

the DNC (Figure 12). This is particularly useful for alarm forms, withdrawal forms and

PROMs that are entered by the patients via mobile devices.

Figure 12: Viewing a form stored in the EHR with the help of the DNC.

4.7 Initialisation of EHRs

A number of EHR vendors have expressed a need to operate autonomously with

respect to both checking of computable eligibility criteria and form processing.

For some vendors the DNC is not viewed as trusted, although TRANSFoRm would

wish the DNC to be viewed as an extension of the EHR along with the EHR interface

module. In this instance the EHR vendors wish to check the EC for themselves and, if

satisfied, make a DNC:Open call with a patient record containing only that data

necessary for EC determination. There is therefore a requirement for some EHRs to

be provided with all the computable EC when they start up.


38

Secondly, some vendors have the ability to create, maintain, display, process and

store forms natively, but do not have the ability to transform platform HTML forms

and associated queries at runtime to these native formats. The form creation process

is manual. There is therefore a requirement for some EHRs to be provided with all

study forms prior to the start of studies.

Finally, from a user perspective (GP) it is desirable that the web service calls from the

EHR to the DNC give good response times. Most workflows are initiated by a DNC

message call with the exception of EHR:StoreFormLocal, which is handled in the

background by the EHR and so is not a nuisance to the user if it fails or takes time to

complete. To minimise this risk and to establish a proper startup sequence for the

EHR, EIM and DNC, a DNC:Reset message is provided. The DNC should be started

prior to the EHR system and the DNC will not function (including polling the SS for

newly completed forms) until this DNC:Reset message has been received from the

EHR.

If requested by the EHR, the response to this DNC:Reset message will include the

EC criteria and forms for all active studies. Note that this is only relevant to EHRs that

can process these criteria or forms in real time. See Figure 13.

Figure 13: DNC:Reset message. For those vendors that require it, all forms andcomputable EC are provided in a RESET message to the EHR.


39

5. Conclusions

This document presented the TRANSFoRm federated infrastructure for managing the

deployment of functional eCRFs into primary care EHR systems, coordinating study

workflow execution within the EHR systems, and collecting data from EHRs approved

by GP as eSource following CDISC standards.

As a comprehensive digital infrastructure to support the learning healthcare system

(LHS), TRANSFoRm aims to advance the integration between clinical research,

especially RCTs, and routine healthcare. The ability of embedding clinical trial tasks

within daily healthcare workflow and interoperating with local IT infrastructure is

essential to implement the linkage.

Following a model-based semantic mediation approach for data integration, the

system is designed as a service oriented architecture following the established

technology trend in building interoperable systems. A number of loosely coupled,

self-contained TRANSFoRm software units are implemented as RESTful Web

services which work together to deliver the requested functions. The TRANSFoRm

study system, as an external component, hosts study criteria, form templates and

stores collected patient study data. The SS communicates with distributed DNCs

located at each study site and coordinates their activities. DNC is the TRANSFoRm

component which is deployed to each study site and manages all the interactions

with local EHR. DNC comprises two sub-components which connect the SS and EHR

respectively.

While the specific messages between the services will evolve as the system

implementation develops, the logic structure of the messaging has been well

established to support the study operations, such as patient enrolment, checking

eligibility criteria, storing eCRFs, presenting patient specific forms, EHR system

coordination, etc. (Appendices B-G).

This federated infrastructure for eCRFs will be validated by the TRANSFoRm GORD

evaluation study to demonstrate its capability of supporting RCTs.


40

References

[1] J.-F. Ethier, M. M. McGilchrist, A. Burgun, and F. Sullivan, “D6.3 Data Integration

Models,” TRANSFoRm Deliverable, May 2013.

[2] W. Kuchinke, T. Karakoyun, and C. Ohmann, “D6.2 Clinical Research Information

Model,” Project Deliverable TRANSFoRm Deliverable D6.2, V1.0, May 2012.

[3] J.-F. Ethier, O. Dameron, V. Curcin, M. M. McGilchrist, R. A. Verheij, T. N.

Arvanitis, A. Taweel, B. C. Delaney, and A. Burgun, “A unified

structural/terminological interoperability framework based on LexEVS: application

to TRANSFoRm,” J. Am. Med. Inform. Assoc., Apr. 2013.

[4] J.-F. Ethier, V. Curcin, A. Barton, M. McGilchrist, H. Bastiens, A. Andreasson, J.

Rossiter, L. Zhao, T. Arvanitis, A. Taweel, B. Delaney, and A. Burgun, “Clinical

Data Integration Model: Core Interoperability Ontology for Research Using

Primary Care Data,” Methods Inf. Med. Accept., 2014.

[5] openEHR Foundation, “openEHR.” [Online]. Available: http://www.openehr.org.

[Accessed: 25-Apr-2014].

[6] P. Leysen, H. Bastiaens, P. van Royen, L. Agreus, and A. N. Andreasson, “D1.1

Detailed Use Cases,” TRANSFoRm Project Deliverable, Feb. 2011.

[7] “Retrieve Form for Data Capture,” IHE Wiki. [Online]. Available:

http://wiki.ihe.net/index.php?title=Retrieve_Form_for_Data_Capture. [Accessed:

23-May-2014].


41

Appendices

Appendix A – TRANSFoRm Study System: server deployment guide

Deployment Guide Page i

Translational Research and Patient Safety in Europe

Deployment guide

TRANSFoRm Study System – serverdeployment guide

Work Package Number: WP5Work Package Title: Interfaces: User and Software Services

Nature of Deliverable: NADissemination Level: NAVersion: 0.1Delivery Date From Annex 1: M51

Principal Authors: Piotr Bródka, Andrzej Misiaszek, Stanisław Saganowski

Contributing Authors: Przemysław Kazienko, Kazimierz Frączkowski Partner Institutions: WRUT, UW, UNIVDUN, IC, KI, KCLInternal reviewers: NA

This project has received funding from the European Union’sSeventh Framework Programme for research, technologicaldevelopment and demonstration under grant agreement no 247787[TRANSFoRm].

Deployment Guide Page ii

Revision Sheet

Version Date Revision Description

0.1 16.05.2014 first version of the guide

Deployment Guide Page iii

USER'S MANUAL

TABLE OF CONTENTS

Page #

1.0 Introduction..................................................................................................... 1

1.1 Server functions............................................................................................. 1

1.2 Acronyms and Abbreviations......................................................................... 2

2.0 Hardware requirements.................................................................................. 3

3.0 Prerequisites ................................................................................................... 4

4.0 Applications .................................................................................................... 5

4.1 Apache Tomcat ............................................................................................. 6

4.2 MySQL .......................................................................................................... 6

5.0 Additional instructions................................................................................... 8

5.1 PROM reminders........................................................................................... 8

5.2 Web services................................................................................................. 8

Deployment Guide Page 1

1.0 Introduction

TSS is a complex system that consists of many parts. From the patientsapplications (mobile and web solution) to the Study Database (SDB) everything isconnected through the TSS server. This document will is a simple deployment guidefor the server part of TSS. Everything will be explained from hardware requirementsto the applications that need to be installed beside the operating system

1.1 Server functions

Study System server is the central point of the whole infrastructure. It’s job ismainly to:

provide secure connection between its components

enable the use of the web application

run special web services designed for the TSS

create and store logs for every TSS application

scan the SDB for not filled questionnaires and according emails topatients

For detailed explanation of the Study System and its server please seeDeliverable 5.5 Mobile eHealth application for the delivery of Patient RelatedOutcome Measures. Simple overview of the server is presented in figure 1.1.1.


TRANSFoRm Study System server

Windows Server

Apache TomcatMySQL

databasePROM

reminders

Fig. 1.1.1 Basic overview of the TSS server

1.2 Acronyms and Abbreviations

SDB Study DatabaseTSS TRANSFoRm Study SystemDNC Data Node ConnectorHDD hard disk drive


2.0 Hardware requirements

Technical requirements for installing all of the Study System server componentsare as follows:

2xIntel Xeon E5-2430 or better

4 HDDs (hard disk drives) 1TB each running on RAID 5

16 GB of RAM

symmetrical internet connection with download and upload speed of atleast 100 Mbit/s


3.0 Prerequisites

Before installing all of the necessary applications it is vital to do the followingsteps:

1. installation of the required hardware (most importantly the 4 HDDs running onRAID 5)

2. creating a virtual machine to run the server on. This step might be optionaldepending on the preferred installation choice. The TSS will run in the sameway on a server with a virtual machine as its base or dedicated hardware

3. installation of a Windows Server system. Anything above Windows Server2008 R2 will be sufficient. However Windows Server 2012 R2 is the preferredchoice

4. configuring the Windows Server to allow connection through a remote desktop(for administrative work). Additionally it is vital to create an admin account onthe Windows Server for the administrator of the TSS

5. internet connection from the server to the outside world and other TSScomponents must use ports 443, 465, 587, 1433, 2382, 3308, 3389, 8443


4.0 Applications

It is not possible to run the TSS just on a barebones Windows Server. There isof course a chance to run the web application and web services through the IIS(Internet Information Service). For the purpose of TSS server two applications areessential to be installed. Apache Tomcat and MySQL are critical softwarecomponents. Both of these application can be installed from a standard windowsinstallation package. Proffered versions are as follows:

Apache Tomcat 7.0.53 64-bit or later

o download link http://tomcat.apache.org/download-70.cgi

MySQL Community Server 5.7 64-bit or later

o download link http://dev.mysql.com/downloads/mysql/


4.1 Apache Tomcat

Prerequisite to the installation is the Java SDK. It is required when promptedlater in the installation process to set the JAVA_HOME variable to point to the JDK'smain directory. Download and install the Java 7 SE JDK. Remember to install the 64-bit version if you are running on a 64-bit OS. The Tomcat installer will look for a 64-bitJava VM on a 64-bit OS

1. Download and install the 7.0.53 64-bit or later Windows Service Installer

2. Ensure that you select the Service and Native options under the Tomcatcomponent. The Manager application component provides a web basedmanagement application

3. You will be asked to choose an HTTPS connector port for Tomcat (should be443). It is also important to install the Manager component which will require toconfigure authentication details for the Manager. It is vital to create oneaccount for Apache Tomcat Manager with administrator rights

4. When the install is complete, the Tomcat service will be automatically. If not, itis essential to start the service manually and in the configuration of thissoftware to choose auto start as the default boot up option

5. Confirm the install

6. If the installation process went without any error an Apache Tomcat iconshould appear on the taskbar

7. Open the Windows Services manager and confirm that the Tomcat servicehas been correctly installed

8. Finally confirm that you can communicate with Tomcat on the configuredHTTPS port. Open https://localhost:443 in your browser

Configuration of the HTTPS should look like this (this is just an example becausedifferent SSL certificates might require other types of installation):

<Connector port="8443" protocol="HTTP/1.1"SSLEnabled="true"

maxThreads="150" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS"

keystoreFile="${catalina.home}/conf/.keystore"

keystoreType="JKS" keystorePass="tRanf8876op" />

4.2 MySQL

Installation manual for MySQL Community Edition Server can be found here:


http://dev.mysql.com/doc/refman/5.7/en/. MySQL Installer is an application thatsimplifies the installation and updating process for a wide range of MySQL products,including MySQL Notifier for Microsoft Windows, MySQL Workbench, and MySQL forExcel. From this central application, you can see which MySQL products are alreadyinstalled, configure them, and update or remove them if necessary. The installer canalso install plugins, documentation, tutorials, and example databases. The MySQLInstaller is only available for Microsoft Windows, and includes both a GUI andcommand-line interface.

MySQL Installer handles the initial configuration and setup of the applications2.For example:

1. It will create MySQL Server connections in MySQL Workbench.

2. It creates the configuration file (my.ini) that is used to configure the MySQLServer. The values written to this file are influenced by choices you makeduring the installation process.

3. It imports example databases.

4. It creates MySQL Server user accounts with configurable permissions basedon general roles, such as DB Administrator, DB Designer, and Backup Admin.It optionally creates a Windows user named MysqlSys with limited privileges,which would then run the MySQL Server.

5. This feature is only available during the initial installation of the MySQL Server,and not during future updates. User accounts may also be added with MySQLWorkbench.

6. If the "Advanced Configuration" option is checked, then the Logging Optionsare also configured. This includes defining file paths for the error log, generallog, slow query log (including the configuration of seconds it requires toexecute a query), and the binary log.

MySQL Installer can optionally check for updated components and downloadthem for you automatically.

There also needs to be created an administrator account for the person whowill manage the MySQL database.

2http://dev.mysql.com/doc/refman/5.6/en/mysql-installer.html


5.0 Additional instructions

This chapter will contain information about installing essential software for theTSS excluding Apache Tomcat and MySQL.

5.1 PROM reminders

Role of this part is to monitor the TSS SDB for not filled questionnaires and tonotify correct people about this fact. This program is delivered with the rest of theTSS bundle as a jar file. This file is named program.jar and comes with a folder calledprogram_lib and an additional file EmailTranslations.xml. It is crucial to run this file assoon as the TSS is deployed. Steps to do that are as follows:

1. download and install from herehttp://www.oracle.com/technetwork/java/javase/downloads/java-se-jre-7-download-432155.html the JAVA SE Runtime Environment 7

2. unpack all of the PROM reminder files to a folder of your choice

3. open the search function of the Windows Server and type cmd or just run thecommand line.

4. navigate in the command line to the folder where you have put PROMreminders files

5. type in the command line java –jar program.jar

After these steps everything will run as intended

5.2 Web services

This part manages all of the connections between the mobile/web application,TSS server and the SDB. Everything that needs to be installed can be found in theTSS bundle. Search for the file names TransfomServer.war. Additional steps are asfollows:

1. open the Apache Tomcat Manager by typing in a web browser address fieldthis line https://localhost:443. Please note that in case you are not on themachine with the TSS server you need to write down a different address

2. after successfully logging in please choose the Manager App link on the rightside of the web page

3. scroll all the way down to the section named WAR file to deploy. Click on thebutton Choose file.


4. select the file TransformServer.war and accept it by clicking on the OK button

5. you will be brought back to the Manager App screen. Please click on theDeploy button. This finalizes the process of installation


43

Appendix B – Message structures

Appendix B – Message structures

B1 - Message pseudo-

format

B2 - Headers

Owner: Message name

{

Message request

}

=

{

Message response

}

EHR/DNC_Header

{

messageID: integer

senderMsgSequence: integer

encryptedEHRPatientID: string

EHRSystemID: string

gpID: string

sessionID: string

}

SS_Header

{

messageID: integer


encryptedEHRPatientID: string

EHRSystemID: string

gpID: string

}


44

Appendix C – Patient enrolment calls

Appendix C – Patient enrolment calls

C1 – DNC:IsEnrolled C2 – SS:GetPatientOptions

DNC: IsEnrolled

{

DNC_Header

}

=

{

<SS:GetPatientOptions>

}

SS: GetPatientOptions

{

SS_Header

}

=

0..* of {

studyID: string

formID: string (EC, Consent,

Randomisation, CROMx, PROMx)

sequenceID: integer

actionFlag: string (Alarm,

Withdrawal, Reminder)

}

Appendix D – EC checking calls

Appendix D – EC checking calls

D1 – DNC:Open or DNC:Update

DNC:Open

{

DNC_Header

patientRecord: XML

checkStudy: string (* or name of

study)

}

=

{Null}


45

Appendix E– Form storage calls

Appendix E – Form storage calls

E1 – SS:StoreForm E2 – EHR:StoreFormLocal

SS: StoreForm

{

SS_Header

studyID: string

formID: string

formODM: XML

}

=

{


}

EHR: StoreFormLocal

{

EHR_Header

studyID: string

formID: string

formODM: XML

formHTML: XML

actionFlag: string (Alarm,

Withdrawal, Reminder)


}

=

{Null}

D3 – SS:GetNewlyCompletedForms

SS: GetNewlyCompletedForms

{

SS_Header

studyID: string

}

=

0..* of {

studyID: string

formID: string

formODM: XML

}


46

Appendix F – Form handling calls (patient specific)

Appendix F – Form handling calls (patient specific)

F1 –

DNC:PrepareForm

F2 – SS:GetForm

DNC: PrepareForm

{

DNC_Header

studyID: string

formID: string

}

=

{

URL: string

}

SS: GetForm

{

SS_Header

studyID: string

formID: string (EC, Consent, Randomisation,

CROMx, PROMx, Alarm, Withdraw)

}

=

0..* of {

studyID: string

formID: string

formHTML: XML

formODM: XML

formQueries: XML

}


47

Appendix G – System-system calls

Appendix G – System-system calls

G1 – DNC:Reset G2 – SS:GetStudyOptions

DNC: Reset

{

EHRSystemID: string


0..* of {studyID: string}

}

=

{

<SS:GetStudyOptions>

}

SS: GetStudyOptions

{

EHRSystemID: integer


studyID: string

}

=

0..* of {

studyID: string

studyEC: XML

0..* of {

formID: string

sequenceID: string

formHTML: XML

formODM: XML

formQueries: XML

}

}

Documents

D7.1 Federated Infrastructure for eCRFs...TRANSFoRm FP7-247787 D7.1 Federated infrastructure for eCRFs 8 1. Introduction The core objective of TRANSFoRm is to produce a digital infrastructure