Standard-based integration profiles for
clinical research and patient safety
Christel Daniel, MD, PhD1,2, Gokce Banu Laleci Erturkmen, PhD3, Ali Anil Sinaci, MSc3, Brendan C
Delaney, BM, BCh, MD4, Vasa Curcin, PhD5, Landen Bain6
1INSERM
UMRS 872eq20, Paris, France; 2AP-HP, Paris France; 3Software Research, Development and
Consultancy, Ankara, Turkey; 4Kings College of London, UK; 5Imperial College London, UK; 6CDISC, USA
2013 Joint Summits on Translational Science
1
Integraton profiles
for EHR-enabled research
• EHRs can now be adapted to integrate seamlessly with
existing research platforms
– Unique opportunity for many stakeholders, including
hospitals, clinical research promoters, pharmaceutical
industry and policy makers.
– Key challenges, including security and semantic
interoperability issues, need to be overcome in order to
provide platforms that functions across many EHR systems.
• IHE Quality, Research and Public Health (QRPH)
– Collaboration with CDISC’s Healthcare Link initiative
– Set of integration profiles that specifically address EHRenabled research.
2013 Joint Summits on Translational Science
2
Panelists
• Wayne Kubick – CDISC (US)
CDISC’s Healthcare Link initiative & IHE QRPH (wkubick@cdisc.org)
• Christel Daniel, MD, PhD – INSERM AP-HP (France)
EHR4CR (Innovative Medicine Initiative (IMI))(christel.daniel@crc.jussieu.fr)
• Brendan Delaney, BM, BCh, MD – KCL (UK)
TRANSFoRm (7th framework programme)
(brendan.delaney@kcl.ac.uk)
• Ali Anil Sinaci, MSc – SRDC (Turkey)
SALUS (7th framework programme)(anil@srdc.com.tr)
2013 Joint Summits on Translational Science
3
EHR-enabled research
Use cases
Use case #1: Identification of
populations of patients based on
pre-defined characteristics
(eligibility criteria)
Use case #2: Extraction for a given
patient of a set of individual clinical
data predefined by a research
protocol/reporting standard
Use case #3: Extraction for a given
population identified based on predefined characteristics (use case #1)
of sets of individual clinical data
predefined by a research protocol
(use case #2)
EHR4CR
TRANSFoRm
Protocol feasibility study
Patient recruitment
SALUS
Signal
detection
Case Report Form (CRF)
pre-population
Individual case
safety report
(ICSR) form
pre-population
Retrospective Exploratory
observational analysis study
study
2013 Joint Summits on Translational Science
4
Question
How can we use standard-based IHE profiles
to implement EHR-enabled use cases for clinical research
and patient safety?
2013 Joint Summits on Translational Science
5
Standard-based integration profiles for
clinical research and patient safety
Wayne Kubick, Landen Bain
CDISC’s Healthcare Link initiative & IHE QRPH
2013 Joint Summits on Translational Science
6
CDISC Standards for Research
7
Integrating Workflow: EHRs and External Agencies
Clinical Research
Public Health
Quality
Case Report Form
Outbreak Report
Quality Measure
EHR
8
2013 Joint Summits on Translational Science
Linking Research and Healthcare
• Secondary Use of Big Data – OMOP, mini-Sentinel,
I2B2
–
–
–
–
Access and pool de-identified, past observational data
Across many subjects
Data mined for feasibility and hypothesis generation
Limited value for new research other than recruitment
• Primary Research – ASTER, RFD Study Execution
–
–
–
–
Pseudonymized live data – during patient encounters
One single subject at a time
Protocol driven recruitment and data capture
Limited value for feasibility or recruiting
IHE Profiles Drafted &
Revised
Trial
Implementation
Published Posted
For Public
Comment
IHE Technical
Framework
Developed
Profile Selection by
Committees
IHE Call for Proposals
Opens
months 1-5
Test at IHE Connectathons
Publish in IHE’s
Product Registry
months 14-18
Demonstrate at a
months 6-13
Install
Interoperable
products in
Clinical
Settings
worldwide
2013 Joint Summits on Translational Science
10
QRPH Overview
• Overview
IHE Quality, Research and Public Health Domain (QRPH) addresses the
infrastructure and content necessary to:
–Share information relevant to quality improvement in electronic patient
care and health care records
–Facilitate interoperability between the healthcare system and clinical
research
–Facilitate interoperability between the healthcare system and public
health
• Sponsors
–Healthcare Information and Management Systems Society (HIMSS)
–Radiological Society of North America (RSNA)
• History
–Domain launched in 2007
2013 Joint Summits on Translational Science
11
IHE Healthcare Link Profiles
A set of profiles and standards to automate the clinical trial process flow of EHR-enabled
platforms from patient recruitment thru clinical trial data capture:
Clinical research protocol:
–
–
–
–
•
Clinical research documents (eCRF or adverse event reports) to be pre-populated by
existing clinical data in EHRs:
–
–
–
–
–
–
•
Retrieve Form for Data Capture (RFD)
Clinical Research Document (CRD)
Drug Safety Content (DSC)
Redaction Service Profile (RSP)
Proposed Data Element Exchange (DEX) and Patient Authored Note
HL7 CCD, CDISC CDASH and ODM for data exchange and archive
Confidentiality and security aspects
–
–
–
12
Retrieve Process for Execution (RPE)
Clinical Research Process Content (CRPC)
Proposed Research Matching
CDISC SDM-XML
Consistent Time (CT)
Cross-Enterprise User Assertion (XUA)
Audit Trail Node Authentication (ATNA)
RFD Roles – EHR and EDC
Archive Form
A
EHR
D
Form Filler
Submit Form
Retrieve Form
B
C
EDC
Form Manager
© CDISC 2011
Form Receiver
Form Archiver
eSource
Source: Dave Iberson-Hurst
13
2013 Joint Summits on Translational Science
14
2013 Joint Summits on Translational Science
15
A Learning Health System (LHS)
“ … one in which progress in science, informatics, and care
culture align to generate new knowledge as an ongoing,
natural by-product of the care experience, and seamlessly
refine and deliver best practices for continuous improvement
in health and health care.” (Institute of Medicine)
• The LHS relies on “sharing and disseminating what is learned
in timely and actionable forms”.
• (In a manner that is) “sufficiently specific, unambiguous, and
standardized to allow encoded logical statements and
operations that can be executed by digital computing devices-and retrieved again for future use.”
16
CDISC SHARE VISION
A global, accessible electronic metadata library,
which through advanced technology, enables
precise and standardized data element
definitions and richer metadata that can be
used in applications and studies to improve
biomedical research and its link with healthcare.
http://www.cdisc.org/cdisc-share
17
• Single, trusted, authoritative source for
CDISC data standards
• Concepts, metadata, collections,
relationships, value sets across the full
spectrum of CDISC content
• Links research to healthcare concepts to
support interoperability
• Aligned with NCI Semantic Systems
a. Change
control
b. Gov’c
workflows
c. Impact
Analysis &
Inheritance
BRIDG, ISO21090
a
Protocol, CDASH
b
c
SDTM, ADaM
SHARE
Facilitates • Access to data standards
• Source to target
Data
mapping & traceability
Exchange • Transformation logic
Terminologies
Adapted from Source by Sue Dubman, Sanofi-Aventis
1
8
18
Standard-based integration profiles for
EHR4CR
Christel Daniel, MD, PhD; Landen Bain
INSERM UMRS 872eq20, Paris, France
AP-HP, Paris France
CDISC’s Healthcare Link initiative & IHE QRPH
2013 Joint Summits on Translational Science
19
IMI EHR4CR project
Objectives, scope Executive Summary
• Innovative Medicine Initiative
– Public-Private Partnership between EU and EFPIA
focused in research on needs common to the
Pharmaceutical Industry and Patients at European
level
• EHR4CR platform to reusing EHR data for
supporting medical research
• A comprehensive business model for
governance, acceptance, adoption and
sustainability
• 4 years (2012-2015)
2013 Joint Summits on Translational Science
20
EHR4CR partners
33 European academic and industrial partners
11 Pharmaceutical Companies (members of EFPIA) & 22 Public Partners (Academia,
Hospitals and SMEs)
2013 Joint Summits on Translational Science
21
Use cases
A loosely coupled SOA, which interconnects independent
services implementing EHR4CR usage scenarios
Protocol feasibility
Patient recruitment
Clinical trial execution
Pharmacovigilance
1
Leverage clinical data to design viable
trial protocols and estimate
recruitment
2
Detect patients elegible for trials to
better utilize recruitment potential
3
Re-use routine clinical data to prepopulate trial CRFs
4
Detect adverse events and
collect/transmit relevant information
2013 Joint Summits on Translational Science
22
Standard-based IHE profiles for EHR4CR
Work Breakdown: RAPID
• Review existing IHE QRPH
integration profiles
• Assess their applicability
• Participate in ongoing IHE
QRPH work
• Integrate a selected group
of profiles into a coherent
test plan (projectathon)
• Develop a new IHE QRPH
profile in order to better
address semantic
interoperability issues
2013 Joint Summits on Translational Science
23
3
Central Workbench (end user services)
PFS Services
Query
builder
1
Result
Viz
2
PRS Services
Publish Interest
Researchto
Publish
Protocol
Sites service
Query builder
Recruitment
Recruitment
Status (“Start”)
Monitoring
Viz
CTE/PV Services
Publish Research
Protocol (Forms ID)
Query builder
4
Study Manager
Data Capture
Monitoring
Viz
Data Relational
Manager
Middleware services
Orchestrator
Registry
Semantic services
Local Endpoint
EHR
User Role
Management
CDW
1
Feasibility study
• A research worker in charge of designing a
new clinical trial seeks to assess the
recruitment capability of several healthcare
facilities by searching distributed CDWs.
– For this use case, typically population-centric,
CDW is the preferable data source
• He/she uses the query builder of the Protocol
Feasibility Study module of the EHR4CR
platform.
2013 Joint Summits on Translational Science
25
1
Feasibility studies
• Since the query builder
implements services similar
to Data Element Exchange
(DEX) service the research
worker can drag and drop
Data Elements stored in the
EHR4CR metadata registry
(1) as well as boolean and
temporal operators (2) in
order to represent formally
the inclusion/exculsion
criteria of the clinical trial
(3).
2
1
2013 Joint Summits on Translational Science
3
26
1
Feasibility studies
• The electronic query
returns only
aggregated data
(counts)
– only if counts are
sufficiently large to
protect privacy.
– might be crosstabulated by a number
of key eligibility criteria
2013 Joint Summits on Translational Science
27
1
Semantic services
for Feasibility studies
• Data Element selection at the Workbench
– Template-based approach: 9 query templates (based on
ISO 21090 data types)
– Services are used by the query builder to access the meta
data repository (Data Element concept, Value Set, data
types, unit, etc) in order to select the appropriate template
and parameters for the query specification
• EHR4CR object-oriented query language – ECLECTIC
• Query transformation at the Endpoints
– Service gets as input a template and the appropriate
parameters and delivers as output:
• SQL queries for relational data bases
• SPARQL for RDF triple stores/SPARQL Endpoints
2013 Joint Summits on Translational Science
28
Terminology
Mappings
Query Result
Transformation
Ontology
Modularization
EHR4CR Reference Terminologies
interface, we adopted the Eligibility
«A_SupportingClinicalStatementUniv
Matched
Patients
1 of MedDRA
nent
the StudyDesign, Criteria
proposed
by the HL7 Regulated Cli
EHR4CR
mation PathLex
Model (RCRIM)
Work
Group [12]. Structures and Va
User Workbench
Terminology
UMLS (LOINC,
Data Elements
(CDEs) are defined
inEndpoint
order to specify additio
SNOMED CT,
EC Model
ICD-10)
Algorithm
high-level EHR4CR information model
and to represent the fin
Query
ECLECTIC
Templates
formation included in eligibility
criteria
constructs. Based on t
Orchestrator
nology mappings in the terminology server, we expand and
Query
SPARQL queries based on the
local CDW schemas, and execute
Transformation
& Expansion
CDWs. We transform the query results based on the standardiz
EHR4CR
EHR4CR
EndpointWorkbench.
Endpoint
then display them at the User
The key elements are
1
Q1
1
Q2
SPARQL
Endpoint
Local
Terminology
CDW1
CDW2
29
1
Feasibility studies
Cardiovascular
Oncology
Nervous system
disorders
X
GSK
Novartis
Janssen
AstraZe
neca
AstraZe
neca
Sanofi
Roche
Oncology
Neurology
Oncology
CV/Arrhythmias
20050182
27919
BIO111482
CENA713B2315
COU-AA-301
D3191C00009
D4320C00015
EFC11785
NC25113
Total
30
Oncology
Oncology
Cardiovascular
and Metabolic
X
X
WW
U
Tota
l
Bayer
Amgen
Merck
uom
11899
Univ
dun
UoG
Disease Area
KCL
*
MU
W
U93
6
UCL
EFPIA
Partner
HUG
Internal
Study ID
APHP
FAU
10 clinical trials – 11 pilot sites
X
3
2
3
X
2
1
X
X
X
X
X
X
X
X
2
1
X
X
X
X
X
X
X
X
3 2
3
2
1
1
2
2
X
3
2
X
3
1
4
3
23
3
Case Report Form (CRF)
pre-population
• A patient has given his full informed consent
for participating to the clinical trial and for the
extraction of data from his/her EHR
• Only pseudonomized individual patient level data are
returned to the organization conducting the clinical
research.
2013 Joint Summits on Translational Science
31
3
Case Report Form (CRF)
pre-population
• The study manager/data manager is in charge of designing
computable specification of the eCRF
– CDISC Operational Design Model (ODM) defined in
2001,specifies the organization structure of data captured for
analysis and reporting over the course of a clinical trial
• He/she uses an eCRF editor
– uses Data Element Exchange (DEX) profile to access to the
metadata registry and select the desired Data Elements (such as
CDSASH, CSHARE) to annotate the eCRF.
– the metadata include a mapping to the corresponding data
element in the HL7 specification Continuity of Care Document
(CCD) as extended in the Clinical Research Document (CRD)
profile.
• He/she uploads the CDISC ODM format of the eCRF on the
EHR-enabled platform.
2013 Joint Summits on Translational Science
32
3
Case Report Form (CRF)
pre-population
• During a visit, the clinical investigator, using the
Retrieve Form for Data Capture (RFD), opens the eCRF
• An electronic query based on the extraction
specification of the Clinical Research Document (CRD)
profile automatically pre-populates the forms
– For this use case, typically patient-centric, the data source
is preferably the EHR.
• The clinical investigator validates pre-populated data,
completes and submits the form to the organization
conducting the clinical research.
2013 Joint Summits on Translational Science
33
Semantic interoperability approach
• Matching computable query specifications to
routinely collected clinical data
– Common clinical information model (EHR4CR
clinical information model): a unique global as
view schema of the heterogeneous EHRs/CDWs
distributed over different pilot sites across Europe
– Query language representing executable eligibility
rules (scenario 1 & 2) and data extraction
specification (scenario 3 & 4)
– Mapping tools and query transformation services
2013 Joint Summits on Translational Science
34
Semantic interoperability approach
Semantic resources
• EHR4CR clinical information model
– HL7 RIM based generic model
• Templates/Archetypes
• Data Elements
– Clinical entities (including observations (diagnosis, findings,
familial and medical history, lab tests, etc), procedures,
substance administration (including medication), etc)
represented in the EHR4CR information model.
– Reference clinical terminologies (e.g ICD-10, ATC,
LOINC, SNOMED CT, RadLex, PathLex, etc)
2013 Joint Summits on Translational Science
35
Collaborative Data Element Editor
http://termapp.davidouagne.com
Edition of a new resource
(Data Element)
EHR4CR semantic resources:
Data Elements, Value Sets
Reference terminologies
(BioPortal)
Collaborative model editor
•Data Element artifacts -> serialization to ISO 11179 MDR
•Model to model transformation (HL7 MIF -> OWL)
2013 Joint Summits on Translational Science
36
Acknowledgments
INSERM team : Sajjad Hussain, Michel Kapoko,
David Ouagne, Eric Sadou
WP4 members : Richard Bache, Kerstin
Forsberg, Thomas Ganslandt, Julie James,
Sebastian Mate, Marc Mc Gilchrist, Dirk
Schwarz-hertzner, Eric Zapletal, …
WPG2 members
The research leading to these results has received support from the Innovative Medicines Initiative
Joint Undertaking under grant agreement n° [No 115189], resources of which are composed of
financial contribution from the European Union's Seventh Framework Programme (FP7/2007-2013) and
EFPIA companies’ in kind contribution.
2013 Joint Summits on Translational Science
37
TRANSFoRm
Standards-based integration profiles for
TRANSFoRm
Brendan C Delaney, BM, BCh, MD1, Vasa Curcin, PhD2 On behalf of the
TRANSFoRm consortium
1Kings
College of London, UK; 2Imperial College London, UK
This project is partially funded by the European Commission
under the 7th Framework Programme. Grant Agreement No.
247787 Translational Research and Patient Safety in Europe
(TRANSFoRm)
2013 Joint Summits on Translational Science
38
Aims of TRANSFoRm
• To develop methods, models, services,
validated architectures and demonstrations to
support:
– Epidemiological research using GP records,
including genotype-phenotype studies and other
record linkages
– Research workflow embedded in the EHR
– Decision support for diagnosis
3
9
TRANSFoRm Consortium
Use case 1: Type 2 Diabetes
• Research Question: In type 2 diabetic patients, are
selected single nucleotide polymorphisms (SNPs)
associated with variations in drug response to oral
antidiabetic drugs (Sulfonylurea)?
• Design: Case-control study
• Data: primary care databases (phenotype data)
and genomic databases (genetic risk factors) – data
federation
• Requirements: Data quality filter, cohort selection,
data linkage
41
Use case 2: Gastro-oesophageal reflux
disease (GORD)
• Research Question: What gives the best symptom
relief and improvement in QoL: continuous or on
demand PPI use?
• Design: Randomised Controlled Trial (RCT)
• Data: Collection through eHR & eCRF
• Requirements: Cohort selection, randomisation,
eSource, PROM via web and mobile platform, event
based triggering from EHR
42
Use case 3: Diagnostic decision
support
• Research Question: Experimental study of a
DSS with standardized patients
• Design: within subjects experiment
• Data: Ontology of Clinical Prediction Rules,
diagnostic performance
• Requirements: Triggering via captured ‘Reason
for Encounter’
2013 Joint Summits on Translational Science
43
Standard-based IHE profiles for
Transform
• Background: BRIDG 3.0, ISO11179, CDISC (STDM, CDASH, ODM),
LexEVS
• DM Use case requires functionality of the Retrieve Form for Data
Cature profile
• GORD use case additionally requires the functionality of the Clinical
Research Process Content and Retrieve Process for Execution
profiles.
• DSS requires incorporation of diagnostic ontology
• However:
– TRANSFoRm is model-based
– We do not load all source data via an ETL process but manage queriy
expressions at run-time.
– Workflow representation
– Provenance
2013 Joint Summits on
Translational Science
44
caDSR/ISO11179
• A complex model difficult to extend or adapt, e.g.
not easy to incorporate CDISC domain model and
variable role model.
• Heavyweight implementation – any change of the
model will require a complete rebuild of the whole
stack from database schema up to client API.
• Focuses solely on data element, lack of formal
definition of data element relationships.
45
CDISC SDTM
• CDISC SDTM is more focused on defining a standard
representation structure of collected datasets.
• Use of CDISC standard variables in CRFs are outside
CDISC scope – subject to vendor implementation
specifics.
• CDISC (CDASH) standard variables are often generic,
so TRANSFoRm needs a mechanism to extend CDISC
model and be able to define more study specific data
elements which are based on or can be mapped to
CDISC standard variables where possible.
47
CDISC Operational Data Model
• Standard for the description of metadata
associated with a clinical trial.
• Allows exchange of datasets.
• Allows vendor extensions.
• Does not allow groups within groups on a
form in its unextended format.
• ODM instance would be an xml document
with bound terminology and descriptors for
text, value, value range, code etc.
Ontology Framework
The TRANSFoRm mediation framework is based on a general
information model (GIM) derived from a recognised sets of
initiatives in the biomedical domain. This GIM is instantiated as
the Clinical Data Integration Model for the purposes of
TRANSFoRm.
The major role of CDIM is to support data interoperability.
CDIM is the only model with which TRANSFoRm modules
interact with the data. This allows the framework to abstract a
significant part of the of the complexity created by
heterogeneity between each data source
Ontology Framework
Upper ontology:
• Basic Formal Ontology (BFO)
Middle (domain) ontologies:
• OGMS (Ontology of General Medical Science)
• IAO (Information Artefact Ontology)
• VSO (Vital Signs Ontology)
www.ifomis.org/bfo
Biodynamic Ontology: Applying BFO in the Biomedical Domain, D. M. Pisanelli (ed.), Ontologies in Medicine, Amsterdam: IOS
Press, 2004, 20–38
http://code.google.com/p/ogms
R. H. Scheuermann et al, Toward an Ontological Treatment of Disease and Diagnosis, Proceedings of the 2009 AMIA Summit on
Translational Bioinformatics, San Francisco, CA, 2009. p 116-120
http://code.google.com/p/vital-sign-ontology/
Albert Goldfain et al, Vital Sign Ontology, Proceedings of the Workshop on Bio-Ontologies, ISMB, Vienna, June 2011, 71-74
http://code.google.com/p/information-artifact-ontology/
Thing
length -> human height
Mass -> dose
phenotype -> gender
pressure -> diastolic pressure
Clinical finding -> Phys Exam
Clinical finding -> Lab finding
Diagnosis
Prognosis
…
Data item
Clinical Data
Integration Model
(ontology)
Entity
Continuant
Quality
Dependent
Information
Content
Independent
Material
Measurement
datum
Systolic measurement
Lab measurement
Pulse rate measurement
…
Document -> Rx
Directive -> Act -> Rx item
Directive -> Condition -> Rule
Label -> Measurement unit -> Unit label
Chemical -> Form -> Product
Molecular -> DNA -> SNP
Object -> Human -> Patient
Lab ordering
Lab result confirm
Process
boundary
Thing
Lab specimen obtention
Clinical Data
Integration Model
(ontology)
Entity
Process
Processual
Occurrent
Connected
temporal
Interval
Instant
Birth
Death
Diagnosis confirmation
Disease course onset
Lab specimen obtention
Vital sign -> BP time taken
Vital sign -> height time taken
Scattered
temporal
Drug utilisation frequency
General
model of diagnosis
Extended PCROM
Care related concepts
54
Area for
data collection
TRANSFoRm Architecture
End User Tools and Services
2. Privacy Model
5. SQA and
Integration
4. Data Quality
Tool
Infrastructure
and Services
10. Data Federation
8. Research Data
Integration
Model
12. Decision
Support
Prototype
9. Electronic Case
Report Forms
(eCRFs)
Support Services
7. Clinical
Prediction
Rules WS
3. Provenance
1. Semantic
Mediator
Distributed Nodes
1. Semantic Mediator
5
Study/Trial
CRIM
used by
Workbench
used by
Reference
Terminologies
and mappings
CDIM
used by
Provenance
and security
models
Middleware
used by
Data node
connector
used by
CDIM-DSM
mappings
DS model
(DSM)
db
57
OpenEHR Archetype
• In the OpenEHR “archetypical” approach, clinical contents
are defined through archetypes.
• OpenEHR archetype is a constraint model, which constrains
a reference information model to formulate domain
contents.
• The archetype model follows object-oriented semantics,
which allows specialization and composition – much more
powerful and flexible than caDSR model.
• Some other features, e.g. a human readable archetype
definition language (ADL), a XPATH/SQL style archetype
query language (AQL), etc.
• OpenEHR archetype is now an ISO standard (ISO 13606-2).
58
Archetype and Forms
59
Archetypes constrain data
elements
60
Conclusion
• European Learning Healthcare System
• Complex and challenging use case
requirements
• Only a small fraction of the project presented
here
• Embedding constrained models within
standards to allow flexibility and standards
compliance
• Need to work with IHE and other EU and US
projects
61
Acknowledgments
•
•
•
•
•
•
•
•
•
•
•
King’s College London: Adel Taweel
Imperial College: Vasa Curcin
University of Rennes: Jean Francois Ethier, Anita Burgin-Parenthoine
University of Dundee: Mark McGilchrist
University of Birmingham: Theodoros Arvanitis, James Rossiter, Lei Zhao
RCSI, Dublin: Derek Corrigan
Karolinska Institute: Anna Nixon Andreasson, Lars Agreus
University of Antwerp: Paul van Royen, Hilde Bastiens, Johan Wens
NIVEL: Robert Verheij
CPRD: John Parkinson, Tjeerd van Staa
Trinity College Dublin: Siobhan Clarke
2013 Joint Summits on Translational Science
62
Standard-based integration profiles for
SALUS
Gokce B. Laleci Erturkmen, PhD
A. Anil Sinaci, MSc
SRDC Software Research, Development and Consultancy
Ankara, Turkey
2013 Joint Summits on Translational Science
63
SALUS: Scalable, Standard based Interoperability
Framework for Sustainable Proactive Post Market Safety Studies
(http://www.salusproject.eu/)
• A STREP funded under Objective ICT-2011.5.3b – Tools and
environments enabling the re-use of electronic health records
which aims to
– Enable effective integration and utilization of electronic health record
(EHR) data to improve post-market safety activities on a proactive
basis
– Pilots in Lombardia Region (Italy) and Eastern Saxony (Germany)
• WHO-UMC and ROCHE are actively involved in pilot studies
Partners
SRDC Ltd, Turkey (coordinator)
EUROREC, France
WHO- UMC, Sweden
OFFIS, Germany
AGFA Healthcare, Belgium
2013 Joint Summits on
Translational Science
64
ERS, Netherlands
LISPA, Italy
INSERM, France
TUD, Germany
ROCHE, Switzerland
How SALUS extends current spontaneous reporting system to
seamlessly exploit the already existing clinical data at EHRs
An ideal system for ADR surveillance would combine the
strengths of case reports with those of EHRs
2013 Joint Summits on
Translational Science
65
Use Cases
• Enabling Semi-automatic Notification of Suspected ADEs and Reporting
ADEs within a Hospital
– Enabling Notification of Suspected ADEs
– Enabling Semi-automatic ADE Reporting
• Supporting Clinical Evaluation of a Potential Signal through Accessing the
EHRs
– Characterizing the cases and contrasting them to a background population
• What differs between the patients having a myocardial infarction within two weeks
of Nifedipine intake to all the other patients taking Nifedipine?
– Temporal pattern characterisation
• Is there a temporal association between a drug of interest and a medical event of
interest
– By comparing the actual and expected counts of events in different time periods relative
to the first prescription of a drug
– Can be used for evaluating ADEs
– Can be used to assess positive impacts of drugs
2013 Joint Summits on
Translational Science
66
Use Cases
• Running Exploratory Analysis Studies over EHRs for Signal
Detection
– Temporal association screening on EHRs
– What does the Medical Event profile look like for Nifedipine?
– Are there any drugs that might be associated with causing Myocardial
Infarction?
– Open ended analysis, no prior hypothesis
– Generates associations that might become signals
– Manual clinical review of relevant medical history
• Using EHRs as secondary use data sources for Post Marketing
safety studies
– Estimate incidence rates of congestive heart failure (CHF)
in diabetic patients with a recent acute coronary syndrome
(ACS) event on different diabetic medications
2013 Joint Summits on
Translational Science
67
SALUS Semantic & Technical Interoperability
2013 Joint Summits on
Translational Science
68
Standard-based IHE profiles for SALUS
•
SALUS Technical Interoperability – Subscription/Query Based Interoperability
Profiles
–
–
–
–
•
heterogeneous EHR systems
population based
eligible patient group (inclusion/exclusion)
continuous screening
Related available interoperability approaches have been examined
– From ITI: IHE RFD, From QRPH: IHE DSC, CRD
• Form based interaction, not query/subscription based, focusing on case safety reports
– From ITI: IHE XDS (MS), From PCC: IHE QED, IHE CM
• Subscription/query based, yet not specialized for population based queries
• Not only HL7 CCD, SALUS would support patient summaries expressed in EN13606 artefacts
– Representing eligibility queries:
• HL7 HQMF queries
• CDISC Study Design Model (SDM)
2013 Joint Summits on
Translational Science
69
Standard-based IHE profiles for SALUS
• For the subscription/query based profiles of SALUS
• Extended IHE CM (subscription) and IHE QED (query)
• population based eligibility criteria
• use HL7 HQMF
• Carry EN13606 EHR EXTRACTs in addition to ASTM/HL7 CCD.
• For ADE Reporting (ICSR)
• QED, DSC or IHE DEX are possible solutions
• DEX: Modular, dynamic, interoperable
• Study Design for Observational Studies
• DEX
2013 Joint Summits on
Translational Science
70
IHE DEX
• For the reuse of EHRs for clinical research
– E.g. CCD CDASH annotated ODM
• Can be achieved through existing IHE profiles
– RFD, CRD, Redaction
– The problem: one size fits all – XSLT mappings
• Power of an MDR
– apply mappings earlier in the process
• During the form design, data elements of the form have already been mapped to the
corresponding elements in the EHR export
– The MDR to maintain the exact correspondences between the research and
healthcare data elements
• DEX is to support study feasibility, patient eligibility and recruiting,
adverse event reporting, retrospective observational studies as well as
case report form pre-population
– existing standards for patient summaries – ASTM/HL7 CCD
2013 Joint Summits on
Translational Science
71
IHE DEX – Actors and Transactions
DEX
•Volume 1 is complete
•Volume 2 is underway
•Release for
•Public comment in May
•Trial Implementation in July
Retrieve Metadata [QRPH-Y1]
This transaction is used by the Metadata Consumer to retrieve the metadata of a selected Data
Element from the Metadata Repository. The Metadata Consumer has previously obtained the
UUID of the Data Element she is looking by means outside of the scope of this transaction
2013 Joint Summits on
Translational Science
72
Semantic Metadata Registry (MDR)
• Data within each system is stand-alone and not interoperable
– “have a common understanding of the meaning and descriptive characteristics
(e.g. representation) of data”
• Metadata for Semantic Interoperability
– annotate the information models of different systems
• with the same set of data elements residing in the metadata registries
– early approach: bottom-up
• takes root from several other disciplines like linguistics, compilers etc…
Patient
Name
Surname
MDR
Birth Date
Sex
Patient
First name
Last name
Patient
Firstname
Date of Birth
Surname
Sex
Date of Birth
Gender
2013 Joint Summits on
Translational Science
73
ISO/IEC
11179
Any other
Metadata
Disparate Data Elements, Content Models
•
•
There are many different efforts to define Data Elements, and binding them to
actual data sources (like CCD documents)
Examples:
– Health Information Technology Standards Panel (HITSP) has defined the C154: Data
Dictionary Component
• HITSP C83 marks the elements in CCD document with the corresponding HITSP C154 data
elements
– The Federal Health Information Model (FHIM) develops a common Computationally
Independent Model (CIM) for EHRs
– GE/Intermountain Healthcare Clinical Element Models (CEM)
– The Transitions of Care Initiative (ToC) maintains the S&I Clinical Element Data Dictionary
(CEDD)
• Mappings to I2B2, PopMedNet, HQuery implementations, FHIM Model, HITSP C154 when
possible
– available in separate excel sheets, PDFs…
–
–
–
–
CDISC SDTM, CDASH
Mini Sentinel Common Data Model (CDM)
I2B2 data model
Observational Medical Outcomes Project (OMOP) Common Data Model (CDM)
2013 Joint Summits on
Translational Science
74
Linked Metadata
Federated Semantic MDRs
• Maintain & Manage
–
–
–
–
Data Elements
the relations between Data Elements
the components of Data Elements
the relations between the components of Data Elements
• Different Data Elements from different Content Models
– their relations and mappings are managed semantically
• A set of Data Elements with lots of relations – Semantic Resource Set
– The relations can be through the LOD cloud – Linked Metadata!
• The relations may point to native representations of the Content Models
– Extraction Specification
2013 Joint Summits on
Translational Science
75
An example Execution in SALUS
Preparing
Study design
links to SDTM CDEs
Local
for an
observational Semantic MDR
study
Search and use
CDEs from the 1
local MDR
CDISC
Semantic MDR
BRIDG Semantic MDR maintains a
skos:exactMatch mapping from
LBORRES to “Result.Value”
through
“PerformedObservationResult.valu
e.Any”
BRIDG
Semantic MDR
4
Queries federated
MDR Cloud for
SDTM
“LBORRES”
Metadata
Consumer
CDISC ODM
Study Design
Document
2
ODM is annotated
with SDTM
Search for
CCD
Extraction
s of the
SDTM
CDEs
2013 Joint Summits on
Translational Science
3
Receives the URI of HITSP
CDE:“Result.Value”
5
Metadata Source
implementing
DEX
HITSP
Semantic MDR
7
XPATH of corresponding
CCD element is returned
6
Ask for Extraction Specification of HITSP CDE:”Result
Value”
//cda:observation[cda:templateId/@root =
'2.16.840.1.113883.10.20.1.31'] /cda:value
76
Participation to a projectathon?
Using DEX?
•
•
SALUS is implementing a semantic MDR for the semantic interoperability
Semantic MDR can implement IHE DEX in order to provide
– extraction specifications during ICSR Reporting
– population of data collection sets for eligible patients during observational studies
•
SALUS – EHR4CR collaboration through DEX
SALUS MDR
(Metadata Source)
EHR4CR
(Metadata Consumer)
•
DEX
Interface
Retrieve
Metadata
CDISC SHARE can be extended…
2013 Joint Summits on
Translational Science
77
Conclusion
Standard-based IHE profiles for
TRANSFoRm, EHR4CR, SALUS use cases
• Collaborating to test IHE profiles during a joint
projectathon will be a first step towards global
interoperability between EHR4CR,
TRANSFoRM and SALUS platforms and
towards a pan-EU capability for clinical
research and patient safety.
2013 Joint Summits on Translational Science
78
Use
case
#1:
Identification
of
populations of patients
Use case #2: Extraction
of a set of individual
clinical data
EHR4CR / TrRANSFoRM use cases
SALUS use cases
Clinical Research
Patient Safety
Protocol feasibility study
Signal detection
Patient recruitment
IHE QRPH:Retrieve Process for Execution [RPE], Clinical Research
Process Content [CRPC], Data Element Exchange [DEX] (under
development) – IHE PCC Query for Existing Data [QED], Care
Management [CM]
Case Report Form (CRF) preIndividual case safety report
population
(ICSR) form pre-population
IHE ITI: Retrieve Form for Data Capture [RFD],
IHE QRPH: Retrieve Process for Execution [RPE], Clinical Clinical
Research Process Content [CRPC], Data Element Exchange [DEX]
(under development)
Research Document [CRD]
Drug Safety Content [DSC]
Retrospective observational study
Use case #1+ Use case #2
Data Element Exchange [DEX] (under development)
IHE ITI: XUS, CT, ATNA
Use case #3: Extraction
of sets of individual
clinical
Security
&
confidentiality
Standards : CDISC (CDASH, Operational Design Model (ODM), Study Design Model (SDM),
CSHARE, BRIDG) - HL7 (RIM, DCM,
Clinical Statement model, CDA (templates e.g. CCD),
2013 Joint Summits on Translational Science
79
Vocabulary) – ISO (ISO 21090, ISO 11179)
Perspectives
• Semantic resources
– “Model of use” : Agreed clinical data structure definitions
(Templates,archetypes, Data elements (e.g SHARE (CDISC))
• Based on generic reference models for representing clinical data (e.g. ISO EN
13606 Part 1, the ISO/HL7 RIM, openEHR Reference Model) and standard data
types (ISO 21090)
– Explicitly bound to “Models of Meaning” : reference clinical
terminologies (e.g. LOINC, SNOMED-CT, ICD-10) through value sets
• Services for accessing semantic resources
– Implemented into standard-based “Transactions” between “Actors”
• Most healthcare IT standards are now available in RDF/OWL
– Could semantic interoperability be now only an issue of shared
ontologies?
– Are they therefore magically transformed into meaningful and
computable standards?
Questions ?
2013 Joint Summits on Translational Science
81
2
Patient recruitment
• The study manager/data manager is in charge of
designing the computable specification of the
research protocol
– CDISC Study Design Model (SDM) released in
2012,provides machine-readable, interchangeable
descriptions of the design of clinical studies
• Extension to the existing CDISC Operational Data Model
(ODM) specification
• He/she uploads the CDISC SDM format of the
research protocol on the EHR-enabled platform.
2013 Joint Summits on Translational Science
82
CDISC Study Design Model (SDM)
Clinical study concepts
XML-SDM
<clinicalStudyDefinition …>
<eligibilityCriterion…/>
<epoch…/>
<arm …/>
<timePointEventDefinition …/>
<studyCharacteristic…/>
<clinicalStudyDefinition/>
83
CDISC Study Design Model (SDM)
Eligibility criteria
2013 Joint Summits on Translational Science
84
2
Patient recruitment
• The study manager uses the EHR4CR query
builder (using Data Element Exchange (DEX)
profile) for representing formally the
inclusion/exclusion criteria of the clinical trial
2013 Joint Summits on Translational Science
85
2
Patient recruitment
• At the hospital, once the clinical trial is set up
(approvals obtained, clinical investigators
recruited and contract completed)
• The principal investigator runs the queries on
a local workbench
– For this use case, typically population-centric,
CDW is the preferable data source
2013 Joint Summits on Translational Science
86
2
Patient recruitment
• No individual patient level data would be returned to
the organization conducting the clinical research prior
to patient consent.
• Only treating physicians have access to a re-identified
list of patients and may, when appropriate, invite
patients to participate to the trial.
2013 Joint Summits on Translational Science
87
3
Case Report Form (CRF)
pre-population
• The data manager is in charge of designing computable
specification of the eCRF (CDISC Operational Design Model (ODM)).
• He uses the Data Element Exchange (DEX) profile to access to the
on-line metadata registry and select the desired from a core
Common Data Elements (such as CDSASH, CSHARE) to annotated
eCRF.
• The metadata includes the exact specification, using XPath, to find
the corresponding data element in any standard EHR export
document such as a CCD or CDA (including the HL7 specification
Continuity of Care Document (CCD) as extended in the Clinical
Research Document (CRD) profile.
• Both CDISC ODM format of the eCRF and extraction specification
are avialable on the EHR-enabled platform.
2013 Joint Summits on Translational Science
88
3
Case Report Form (CRF)
pre-population
• The LOCAL data manager creates an
extraction specification to extract specific data
elements included in the eCRF either from the
EHR or from a standard EHR export document
such as a CCD or CDA.
2013 Joint Summits on Translational Science
89
Redactor
Form
Filler/
Document
Source
Send Export
document
[QRPH-31]
Extraction
Specification
Manager
Form
Manager
Form
Receiver/
Document
Consumer
Retrieve
Extraction
Specification
[QRPH-33]
Return
redacted
document
[QRPH-32]
Retrieve Form
[ITI-34]
Submit
Form [ITI-35]
Archive Form
[ITI-36]
90
Figure 2-1: CRD+RSP Swimlane Diagram
Form
Archiver
Providing RFD formID to the EHR
<clinicalStudyDefinition xmlns= “urn: hl7-org:v3” ….>
<!-- …. -->
<!-- Visit1 event -->
<component4 typeCode="COMP">
<timePointEventDefinition classCode="CTTEVENT" moodCode="DEF">
<!-- Time Event Content Module -->
<id root="3.2.4.4.5" extension=" ACT.VISIT1"/>
<code code=" ACT.VISIT1 " codeSystem="1.2.3.4.8.2">
<displayName value=" Clinical trial visit 1"/>
</code>
<subjectOf typeCode="SUBJ">
<timePointEventCharacteristic classCode="VERIF" moodCode="EVN">
<!-- Form ID -->
<id>
<item root="1.2.3.4.5" extension="form2ID"/>
</id>
<code code="FO.VISIT1" codeSystem="1.2.3.4.8.2" />
<value xsi:type="TEL" value="https://some.formmanager.addr/forms/"/>
</timePointEventCharacteristic>
</subjectOf>
</timePointEventDefinition>
</component4>
<!-- …. -->
<!-- Study characteristics -->
</clinicalStudyDefinition>
91
Providing Adverse Event formID
to the EHR
<clinicalStudyDefinition xmlns= “urn: hl7-org:v3” ….>
<!-- …. -->
<!—Adverse events -->
<component4 typeCode="COMP">
<timePointEventDefinition classCode="CTTEVENT" moodCode="DEF">
<!-- Time Event Content Module -->
<id root="3.2.4.4.5" extension="ACT.AdverseEvent"/>
<code code="ACT.AdverseEvent" codeSystem="1.2.3.4.8.2">
<displayName value=" Adverse Event"/>
</code>
<subjectOf typeCode="SUBJ">
<timePointEventCharacteristic classCode="VERIF" moodCode="EVN">
<!—Adverse Event Form ID -->
<id>
<item root="1.2.3.4.5" extension="form3ID"/>
</id>
<code code="FORM.AE" codeSystem="1.2.3.4.8.2" />
<value xsi:type="TEL" value="https://some.formmanager.addr/forms/"/>
</timePointEventCharacteristic>
</subjectOf>
</timePointEventDefinition>
</component4>
<!-- Study characteristics -->
</clinicalStudyDefinition>
92
Providing RSP ExtractionID to the
EHR
<clinicalStudyDefinition xmlns= “urn: hl7-org:v3” ….>
<!-- …. -->
<component4 typeCode="COMP">
<timePointEventDefinition classCode="CTTEVENT" moodCode="DEF">
<!-- Time Event Content Module -->
<id root="3.2.4.4.5" extension=" ACT.VISIT1"/>
<code code=" ACT.VISIT1 " codeSystem="1.2.3.4.8.2">
<displayName value=" Clinical trial visit 1"/>
</code>
<subjectOf typeCode="SUBJ">
<timePointEventCharacteristic classCode="VERIF" moodCode="EVN">
<!—RSP Extraction Specification -->
<id>
<item root="1.2.3.4.5" extension="extractionSpecificationID"/>
</id>
<code code="extractionID.VISIT1" codeSystem="1.2.3.4.8.2" />
<value xsi:type="TEL" value="https://some.formmanager.addr/extractionSpecifications/"/>
</timePointEventCharacteristic>
</subjectOf>
</timePointEventDefinition>
</component4>
<!-- Study characteristics -->
<!-- …. -->
<clinicalStudyDefinition />
93
Providing the RFD orgID to the
EHR
<clinicalStudyDefinition xmlns= “urn: hl7-org:v3” ….>
<!-- Study Description Content Module -->
<!-- Definition of the different epochs of the study -->
<!-- Definition of the different arms of the study -->
<!-- Study characteristics -->
<subjectOf typeCode="SUBJ">
<studyCharacteristic classCode="CLNTRL" moodCode="EVN">
<!-- type of characteristic = organization identifier -->
<code code="orgID" valueSet="7.6.5.4"/>
<statusCode code="active"/>
<value xsi:type="TEL" value="X12"/>
</studyCharacteristic>
</subjectOf>
</clinicalStudyDefinition>
94
The need of standard-based
integration profiles
• EHR Clinical Research Functional Profile (ANSI/HL7 standard) can be used
by EuroRec in certifying EHRs for the purpose of research considered
• Joint Initiative Council (JIC) for Global Harmonization of Standards (which
includes ISO, CEN, CDISC, HL7, IHTSDO, GS1)
• Certification based on open model & standard compliance encourage wide
adoption
– Both accredited EDCs/EHRs vendors (certified products) & hospitals (certified
source data) will have a competitive advantage
• Platform services shall
implement established,
vendor neutral integration
profiles tested during
projectathons
2013 Joint Summits on Translational Science
95
