2013 Joint Summits on Translational Science

2013 Joint Summits on Translational Science
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 Your Panel presentation for the 2013 Joint Summits on Translational Science has been scheduled: Session Title: CRI-15: Panel - Standard-based Integration Profiles for Clinical Research and Patient Safety Presentation Title: AMIA-094-C2013. Standard-based integration profiles for clinical research and patient safety Presentation Type: Panel Author(s): Christel Daniel(1); Landen Bain(2); Brendan Delaney(3); Gokce Laleci Erturkmen(4); Curcin Vasa(5) Session Date and Time: March 21, 2013 from 3:30 PM to 5:00 PM 2013 Joint Summits on Translational Science

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 EHR-enabled research. EHRs can now be adapted to integrate seamlessly with existing research platforms thus creating a unique opportunity for many stakeholders, including hospitals, clinical research promoters, pharmaceutical industry and policy makers. However, key challenges, including security and semantic interoperability issues, need to be overcome in order to provide a platform that functions across many EHR systems. The IHE Quality, Research and Public Health (QRPH) domain addresses the information exchange standards necessary to share information relevant to quality improvement in patient care and clinical research. In collaboration with CDISC’s Healthcare Link initiative, IHE QRPH has developed a set of integration profiles that specifically address EHR-enabled research. 2013 Joint Summits on Translational Science

Panelists Wayne Kubick – CDISC (US) CDISC’s Healthcare Link initiative & IHE QRPH Christel Daniel, MD, PhD – INSERM AP-HP (France) EHR4CR (Innovative Medicine Initiative Brendan Delaney, BM, BCh, MD – KCL (UK) TRANSFoRm (7th framework programme) Ali Anil Sinaci, MSc – SRDC (Turkey) SALUS (7th framework The EHR4CR project is providing adaptable, reusable and scalable tools and services for reusing data from hospital EHRs for Clinical Research. TRANSFoRm is developing an informatics infrastructure to support the learning healthcare system in European Primary Care. SALUS project is providing scalable, standard based interoperability framework for sustainable proactive post market safety studies. Overall, the panel will discuss the key steps towards realizing a joint EHR4CR/TRANSFoRm/SALUS European projectathon demonstrating EHR-enabled clinical research across Europe using standard-based integration and content profiles. 2013 Joint Summits on Translational Science

EHR-enabled research Use cases
EHR4CR TRANSFoRm SALUS Use case #1: Identification of populations of patients based on pre-defined characteristics (eligibility criteria) Protocol feasibility study Patient recruitment Signal detection Use case #2: Extraction for a given patient of a set of individual clinical data predefined by a research protocol/reporting standard Case Report Form (CRF) pre-population Individual case safety report (ICSR) form Use case #3: Extraction for a given population identified based on pre-defined characteristics (use case #1) of sets of individual clinical data predefined by a research protocol (use case #2) Retrospective observational study Exploratory analysis study 2013 Joint Summits on Translational Science

Question How can we use standard-based IHE profiles to implement EHR-enabled use cases for clinical research and patient safety? EHR4CR/TRANSFoRm/SALUS European projectathon ? Demonstrating EHR-enabled clinical research across Europe using standard-based integration and content profiles. A set of 9 IHE QRPH profiles and standards pulled together -> super profile standardizing and automating: the research process flow from the patient recruitment to the submission of the clinical trial data to the sponsors The patient safety process flow The panel participants from IHE QRPH-CDISC and three European projects will present how subsets of existing IHE QRPH profiles can be pulled together (and extended when necessary) to form a super profile which will standardize and automate the clinical trial process flow. . Overall, the panel will discuss the key steps towards realizing a joint EHR4CR/TRANSFoRm/SALUS European projectathon demonstrating EHR-enabled clinical research across Europe using standard-based integration and content profiles. 2013 Joint Summits on Translational Science

Standard-based integration profiles for clinical research and patient safety
Wayne Kubick, Landen Bain CDISC’s Healthcare Link initiative & IHE QRPH These profiles address the aspects of i) representing and sharing a clinical research protocol for its execution (CRPC(Clinical Research Process Content), RPE(Retrieve Process for Execution)), ii) representing and sharing clinical research documentation (eCRF, adverse event reporting form) to be pre-populated by existing clinical data in EHRs (RFD(Retrieve Form for Data Capture), CRD(Clinical Research Document), DSC(Drug Safety Content), RSP(Redaction Service Profile)), iii) addressing confidentiality and security aspects (CT(Consistent Time), XUA(Cross-Enterprise User Assertion), ATNA(Audit Trail Node Authentification)) iv) additional profiles, currently in the proposal stage, will further refine and extend these capabilities. 2013 Joint Summits on Translational Science

CDISC Standards for Research
Mention Posters

Integrating Workflow: EHRs and External Agencies
Clinical Research Public Health Quality Case Report Form Outbreak Report Quality Measure Secondary Uses Primary Use EHR 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
months 14-18 Publish in IHE’s Product Registry Test at IHE Connectathons IHE Profiles Drafted & Revised months 6-13 Trial Implementation Posted Published For Public Comment IHE Technical Framework Developed Demonstrate at a IHE Call for Proposals Opens Profile Selection by Committees months 1-5 Install Interoperable products in Clinical Settings worldwide Achieving cross-border, scalable computable interoperability across multiple domains requires the integration of multiple standards, it becomes apparent that an “integration organization” involving multiple stakeholders (including both vendor and organizations) can serve a valuable role by defining – based on stakeholder dialogue – “real-world usage scenarios” – that can be instantiated using existing standards. The organization Integrating the Healthcare Enterprise (IHE – ) has, in fact, emerged as that organization. The IHE initiative is both a process and a forum for encouraging integration efforts. The “real-world usage scenarios” that are published by IHE are referred to as Integration Profiles. Each profile defining a series of “transactions” which specify how existing standards should be applied to meet the overarching business goal described by the profile. (Technical framework) It includes a rigorous testing process for the implementation of this framework, organizes educational sessions, exhibits at major meetings of medical professionals to demonstrate the benefits of this framework and encourage its adoption by industry and users. The approach employed in the IHE initiative is not to define new integration standards, but rather to support the use of existing standards in an integrated manner, defining configuration choices when necessary. When clarifications or extensions to existing standards are necessary, IHE refers recommendations to the relevant standards bodies. Start on 1998 in US in the Radiology domain Neutral forum for working on interoperability Users RSNA (Radiological Society of North America) HIMSS (Healthcare Information and Management Systems Society) Suppliers (Agfa, GE, Siemens, etc) First connectathon and demonstration (RSNA) : 1999 One integration profile : Radiology Scheduled WorkFlow (SWF) 24 vendors demonstrating 47 systems Within domain-specific technical frameworks, Integrating the Healthcare Enterprise, which has developed in North America, Europe, and Asia, 2013 Joint Summits on Translational Science

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

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: Retrieve Process for Execution (RPE) Clinical Research Process Content (CRPC) Proposed Research Matching CDISC SDM-XML 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 Consistent Time (CT) Cross-Enterprise User Assertion (XUA) Audit Trail Node Authentication (ATNA) Texas’s HIT-enabled Cancer Clinical Trial Europe’s EHR4CR Clinical Study Execution Pilot

EHR EDC eSource RFD Roles – EHR and EDC Form Filler A Form Archiver D
4/10/2017 RFD Roles – EHR and EDC Archive Form Form Filler A EHR Form Archiver D Submit Form Retrieve Form Form Manager B Form Receiver C EDC eSource Source: Dave Iberson-Hurst 13 © CDISC 2011

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.”

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. SHARE metadata is envisioned to help find, understand and use clinical data efficiently. 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 c. Impact Analysis & Inheritance b. Gov’c work-flows a. Change control SHARE BRIDG, ISO21090 Protocol, CDASH SDTM, ADaM Terminologies c b a Access to data standards Source to target mapping & traceability Transformation logic Facilitates Data Exchange bridg Adapted from Source by Sue Dubman, Sanofi-Aventis 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 Your Panel presentation for the 2013 Joint Summits on Translational Science has been scheduled: Session Title: CRI-15: Panel - Standard-based Integration Profiles for Clinical Research and Patient Safety Presentation Title: AMIA-094-C2013. Standard-based integration profiles for clinical research and patient safety Presentation Type: Panel Author(s): Christel Daniel(1); Landen Bain(2); Brendan Delaney(3); Gokce Laleci Erturkmen(4); Curcin Vasa(5) Session Date and Time: March 21, 2013 from 3:30 PM to 5:00 PM 2013 Joint Summits on Translational Science

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 ( ) Largest public-private partnership to date with the goal to tie interoperability aspects The IMI EHR4CR project will run over 4 years ( ) and involve 33 European academic and industrial partners 2013 Joint Summits on Translational Science

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

Use cases A loosely coupled SOA, which interconnects independent services implementing EHR4CR usage scenarios Leverage clinical data to design viable trial protocols and estimate recruitment 1 Protocol feasibility Detect patients elegible for trials to better utilize recruitment potential 2 Patient recruitment Re-use routine clinical data to pre-populate trial CRFs 3 Clinical trial execution Detect adverse events and collect/transmit relevant information 4 Pharmacovigilance 2013 Joint Summits on Translational Science

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

CENTRAL EHR4CR PLATFORM HOSPITAL SITES 3 1 2 4
Central Workbench (end user services) 1 2 User Role Management 4 PFS Services PRS Services Publish Research Protocol Recruitment Monitoring Viz CTE/PV Services CENTRAL EHR4CR PLATFORM Study Manager Query builder Result Viz Publish Interest to Sites service Recruitment Status (“Start”) Publish Research Protocol (Forms ID) Data Capture Monitoring Viz Data Relational Manager Query builder Query builder Middleware services Orchestrator Registry Semantic services Local Endpoint EHR CDW HOSPITAL SITES

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. A research worker in charge of designing a new clinical trial seeks to assess the feasibility of the trial and especially the recruitment capability of several healthcare facilities (number of eligible subjects) 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. Since the query builder implements the Data Element Exchange (DEX) profile … 2013 Joint Summits on Translational Science

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 3 For this use case, typically population-centric, data source is preferably a CDW optimized to support queries that cut across multiple patients. EHR (typically built to look at data on single patients) is not an ideal source system. 2013 Joint Summits on Translational Science

Feasibility studies The electronic query returns only aggregated data (counts) only if counts are sufficiently large to protect privacy. might be cross-tabulated by a number of key eligibility criteria For this use case, typically population-centric, data source is preferably a CDW optimized to support queries that cut across multiple patients. EHR (typically built to look at data on single patients) is not an ideal source system. 2013 Joint Summits on Translational Science

Semantic services for Feasibility studies
1 Semantic services for Feasibility studies Data Element selection at the Workbench Template-based approach: 9 query templates (based on ISO 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 The developer of the Query Builder use semantic services to access the meta data of the Common Data Elements (Data Element, Value Set, data types, unit) in order to provide a computable format of the eligibility criteria that can be executed on the different pilot sites. 2013 Joint Summits on Translational Science

Ontology Modularization Query Result Transformation
1 Eligibility Criteria Matched Patients MedDRA PathLex Ontology Modularization EHR4CR Terminology EHR4CR Reference Terminologies User Workbench UMLS (LOINC, SNOMED CT, ICD-10) Endpoint Algorithm EC Model ECLECTIC Query Templates Orchestrator Terminology Mappings Query Transformation & Expansion Query Result Transformation EHR4CR Endpoint1 EHR4CR Endpoint1 Q1 Q2 SPARQL Endpoint Local Terminology CDW1 CDW2

Feasibility studies 10 clinical trials – 11 pilot sites
Internal Study ID EFPIA Partner Disease Area AP-HP FAU HUG KCL* MUW U936 UCL Univdun UoG uom WWU Total 11899 Bayer Cardiovascular X 3 Amgen Oncology 2 27919 Merck Nervous system disorders BIO111482 GSK CENA713B2315 Novartis Neurology 1 COU-AA-301 Janssen D3191C00009 AstraZeneca CV/Arrhythmias D4320C00015 4 EFC11785 Sanofi NC25113 Roche Cardiovascular and Metabolic 23

Case Report Form (CRF) pre-population
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. A patient has given his full informed consent for participating to the clinical trial and for the extraction of data from his/her EHR and for addition of new information into the patient record. Only pseudonomized individual patient level data are returned to the organization conducting the clinical research. 2013 Joint Summits on Translational Science

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. The data manager is in charge of designing computable specification of the eCRF (CDISC Operational Design Model (ODM)). CDISC Operational Design Model (ODM) defined in 2001,specifies the organization structure and syntax of data captured for analysis and reporting over the course of a clinical trial 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) and, using a unique identifier for that data element, ‘downloads’ the metadata defined by the metadata registry into an annotated case report form. The metadata includes the exact specification, using XPath, to find the corresponding data element in the HL7 specification Continuity of Care Document (CCD) as extended in the Clinical Research Document (CRD) profile. Using the XPath statements, the research system creates an entire extraction specification for all elements to be extracted from the CCD. This extraction specification provides a map that enables re-use of the proper data within a CCD with precision and without inappropriate access to extraneous information. Both CDISC ODM format of the eCRF and extraction specification are avialable on the EHR-enabled platform. 2013 Joint Summits on Translational Science

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. Only pseudonomized individual patient level data are returned to the organization conducting the clinical research. 2013 Joint Summits on Translational Science

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 requires the definition of computable representation of both eligibility criteria and routinely collected clinical data in order to support require the definition of a query language representing executable eligibility rules (query model), a common clinical information model (EHR4CR clinical information model) and a common clinical terminology (EHR4CR clinical terminology). In the EHR4CR project, eligibility rules shall be represented using a formal query language. The formal query language provides a formal “query model” that operates on a EHR4CR-nominated clinical information model. 2013 Joint Summits on Translational Science

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) The common EHR4CR clinical information model shall provide a unique global as view schema of the heterogeneous EHRs/CDWs distributed over different pilot sites across Europe. The EHR4CR clinical information model should consider both standards-based information models and common data elements and de facto existing CDW information models. The common EHR4CR terminology shall integrate a range of clinical terminologies that are needed to collectively code the variety of clinical entities (including obesrvatios (diagnosis, findings, familial and medical history, lab tests, etc), procedures, substance administration (including medication), etc) represented in the EHR4CR information model. The EHR4CR clinical terminology shall enable query expansion and some degree of terminological reasoning. We need a way of mapping eligibility constraints on coded clinical entities that are expressed in the common EHR4CR clinical terminology to the diverse other terminologies used across Europe, and to map any retrived data back to the standard terms. In the EHR4CR project, as part of the EHR4CR clinical information model, we should have basic clinical information models that avoid semantic properties in order to limit the issues in Binding information modelsand terminologies The challenge of semantic integration in the EHR4CR platform relies on the capability of the EHR4CR information model (“model of meaning”, global-as-view schema) Acting as a pivot represention supporting the mapping of respective data structures and semantics between the two data usage contexts: patient care on one side and clinical research on the other side. 2013 Joint Summits on Translational Science

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 MDR Model to model transformation (HL7 MIF -> OWL) 2013 Joint Summits on Translational Science

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 ], resources of which are composed of financial contribution from the European Union's Seventh Framework Programme (FP7/ ) and EFPIA companies’ in kind contribution. 2013 Joint Summits on Translational Science

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 Your Panel presentation for the 2013 Joint Summits on Translational Science has been scheduled: Session Title: CRI-15: Panel - Standard-based Integration Profiles for Clinical Research and Patient Safety Presentation Title: AMIA-094-C2013. Standard-based integration profiles for clinical research and patient safety Presentation Type: Panel Author(s): Christel Daniel(1); Landen Bain(2); Brendan Delaney(3); Gokce Laleci Erturkmen(4); Curcin Vasa(5) Session Date and Time: March 21, 2013 from 3:30 PM to 5:00 PM This project is partially funded by the European Commission under the 7th Framework Programme. Grant Agreement No Translational Research and Patient Safety in Europe (TRANSFoRm) 2013 Joint Summits on Translational Science

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

TRANSFoRm Consortium 21 partners

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 Use case to evaluate/potential of transform tools to perform epidemiological studies linking phenoype genetype data accross europe DATA FEDERATION

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 UC to evaluate performing and RCT using eCRF with build in eHR

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

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 A set of 9 IHE QRPH profiles address the aspects of i) representing and sharing a clinical research protocol for its execution (CRPC(Clinical Research Process Content), RPE(Retrieve Process for Execution)), ii) representing and sharing clinical research documentation (eCRF, adverse event reporting form) to be pre-populated by existing clinical data in EHRs (RFD(Retrieve Form for Data Capture), CRD(Clinical Research Document), DSC(Drug Safety Content), RSP(Redaction Service Profile)), iii) addressing confidentiality and security aspects (CT(Consistent Time), XUA(Cross-Enterprise User Assertion), ATNA(Audit Trail Node Authentification)) iv) additional profiles, currently in the proposal stage, will further refine and extend these capabilities: DEX (Data Element Exchange) Assess the applicability of IHE QRPH profiles to your project and identify its role 2013 Joint Summits on Translational Science

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.

CDISC SDTM

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.

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) Biodynamic Ontology: Applying BFO in the Biomedical Domain, D. M. Pisanelli (ed.), Ontologies in Medicine, Amsterdam: IOS Press, 2004, 20–38 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, p Albert Goldfain et al, Vital Sign Ontology, Proceedings of the Workshop on Bio-Ontologies, ISMB, Vienna, June 2011, 71-74

Clinical Data Integration Model (ontology)
Thing length -> human height Mass -> dose phenotype -> gender pressure -> diastolic pressure Entity Clinical finding -> Phys Exam Clinical finding -> Lab finding Diagnosis Prognosis … Quality Continuant Dependent Independent Data item Information Content 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

Clinical Data Integration Model (ontology) Lab ordering
Lab result confirm Process boundary Clinical Data Integration Model (ontology) Thing Lab specimen obtention Entity Process Processual Occurrent Interval Connected temporal Scattered temporal Instant Drug utilisation frequency Birth Death Diagnosis confirmation Disease course onset Lab specimen obtention Vital sign -> BP time taken Vital sign -> height time taken

General model of diagnosis

Extended PCROM Care related concepts Area for data collection

Eligibility Criteria Model (ECM)*
*Input to implementation of the information model in WP5.3 (query and data extraction work bench)

TRANSFoRm Architecture
End User Tools and Services 2. Privacy Model 4. Data Quality Tool 12. Decision Support Prototype 9. Electronic Case Report Forms (eCRFs) Infrastructure and Services Support Services 5. SQA and Integration 7. Clinical Prediction Rules WS 3. Provenance 1. Semantic Mediator 10. Data Federation 8. Research Data Integration Model Distributed Nodes 1. Semantic Mediator

CDIM db Study/Trial CRIM Workbench Provenance and security models
used by CDIM used by Reference Terminologies and mappings used by Provenance and security models Middleware used by Data node connector used by CDIM-DSM mappings DS model (DSM) db

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 ).

Archetype and Forms Archetypes are defined by constraining the reference model. Archetypes are composed into templates, from which screen forms can be generated.

Archetypes constrain data elements
The archetype approach might be the way to go. The idea is around the concept of observation. Collected study dataset is a collection of observations. Each observation may correspond to a clinical database row or an EHR entry. The content of each observation is controlled by archetype. An archetype groups related CDIM concepts to form a meaningful unit, which will be made interoperable with clinical data sources or EHR through CDIM DSM mappings. In the cases where being compatible to CDISC is desired, the archetype can be assigned to a cdisc domain and mapped to CDISC standard variables where possible. In terms of form implementation, an archetype can possibly be mapped to ODM elements such as ItemGroup.

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 *« Semantic Interoperability for Better Health and Safer Healthcare. Research and Deployment RoadMap for Europe - Semantic Health Report », January 2009 Current attempts to standardize the capture, representation and communication of clinical data rely upon Agreed clinical data structure definitions e.g. archetypes (ISO EN13606 Part 2) or HL7 templates

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

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

SALUS: Scalable, Standard based Interoperability Framework for Sustainable Proactive Post Market Safety Studies ( A STREP funded under Objective ICT b – 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 ERS, Netherlands LISPA, Italy INSERM, France TUD, Germany ROCHE, Switzerland 2013 Joint Summits on Translational Science

How SALUS extends current spontaneous reporting system to seamlessly exploit the already existing clinical data at EHRs Enable effective integration and utilization of electronic health record (EHR) data to improve post-market safety activities on a proactive basis EHR covers extended parts of the underlying medical histories, include more complete information on potential risk factors, and not restricted to patients who have experienced a suspected ADE Denominator is missing in SRS data Aim to create the necessary infrastructure to enable secondary use of EHRs in an efficient and effective way for reinforcing the post market safety studies An ideal system for ADR surveillance would combine the strengths of case reports with those of EHRs 2013 Joint Summits on Translational Science

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

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

SALUS Semantic & Technical Interoperability
2013 Joint Summits on Translational Science

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) Achieving syntactic and semantic interoperability between EHR Systems and clinical research systems (1) to seamlessly query heterogeneous EHR systems for analysing and detecting possible ADEs, pre-filling case safety reports and for enabling signal follow-up studies to trace the safety reports back to the related EHRs (2) to seamlessly specify the target eligible patient group for enabling set up of continuous safety studies that screen EHRs (3) to specify the requested clinical data by intelligent data analysis tools for the selected group of patients (4) to transfer the specified de-identified clinical data to the clinical data registries for the selected patients for safety analysis Cross-Enterprise Document Sharing (XDS) is focused on providing a standards-based specification for managing the sharing of documents between any healthcare enterprise 2013 Joint Summits on Translational Science

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 It should be noted that HQMF is designed for collecting statistics as quality measures from the selected population. As a response set, Quality Reporting Document Architecture (QRDA) documents are collected. In SALUS on the other hand we would like to collect de-identified medical summaries of the selected population to be analyzed further by post market safety analysis tools, rather than already calculated eMeasures. Hence, for the time being, we will stick with HL7 CCD based templates and EHRExtract templates as the query results. In the later phases of the project, IHE CM extension may be further constrained to carry QRDA documents, after the possibility of using QRDA format for carrying result set is assessed. 2013 Joint Summits on Translational Science

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 An existing set of IHE profiles – RFD, CRD, and Redaction – provide a way to export a standard EHR documents on demand and to map the elements to a research specification, CDISC’s CDASH. The problem is that the mapping is done using a ‘one size fits all’ approach, an XSLT that maps a generic CCD to generic CDASH annotated CRF forms in ODM format. This generic approach provides one map to use for any and all case report forms, despite the wide variance among these forms. This profile leverages the power of a metadata registry to reach deeper into the semantics, and to apply mappings earlier in the process, at the point of form design. DEX will create an extraction specification, customized map of the elements in a particular case report form to the corresponding elements in the EHR export. The metadata registry will maintain the exact correspondences between the research and healthcare data elements, and will provide an exact map by which the CRD Form Manager can extract data from the pre-population data set. The Data Element Exchange will support study feasibility, patient eligibility and recruiting, adverse event reporting, retrospective observational studies as well as case report form pre-population. DEX is especially useful in making use of existing standard export documents such as CCD and CCDA. 2013 Joint Summits on Translational Science

IHE DEX – Actors and Transactions
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

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 Birth Date Sex Firstname Date of Birth Gender First name Last name MDR ISO/IEC 11179 Any other Metadata As stated by ISO and rephrased by DEX, for date interoperability, systems have to have a common understanding of the meaning and descriptive characteristics of data. Hence, that is the structural and descriptive metadata (like syntactic and semantic)… Metadata is very important. Even in the same company, two different applications use different metadata which creates data interoperability problems later during integration. 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

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

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

An example Execution in SALUS
BRIDG Semantic MDR maintains a skos:exactMatch mapping from LBORRES to “Result.Value” through “PerformedObservationResult.value.Any” Preparing Study design for an observational study Local Semantic MDR links to SDTM CDEs CDISC Semantic MDR Search and use CDEs from the local MDR BRIDG Semantic MDR 1 4 Metadata Consumer Queries federated MDR Cloud for SDTM “LBORRES” Receives the URI of HITSP CDE:“Result.Value” 5 CDISC ODM Study Design Document Metadata Source implementing DEX Search for CCD Extractions of the SDTM CDEs 7 HITSP Semantic MDR 2 3 XPATH of corresponding CCD element is returned 6 ODM is annotated with SDTM A study data manager in a pharmaceutical company aims to design the data collection set for an observational study She searches the local MDR interface provided by his company to retrieve data element descriptions for the selected set of variables in the data collection set The local MDR returns a list of data element descriptions, including the unique URIs of the matching SDTM CDEs When she selects SDTM variables the Data Collection Set specification is annotated with SDTM ODM annotated with SDTM.. document that correspond to these CDEs within Data collection Set specification i.e. she wants to have a machine processable Extraction Specification to collect the data sets requested She aims to put the exact paths within an EHR from the EHR extracts she receives Through a tool (Metadata Consumer ), she queries a DEX Enabled Metadata Source to query the exact paths of each CDE within ASTM/CCR templates Tool receives XPATHs for each CDE, and annotates the Data Collection Set Specification Using these, tool builds an XSLT script to populate data collection set for each eligible patient… Ask for Extraction Specification of HITSP CDE:”Result Value” = ' '] /cda:value 2013 Joint Summits on Translational Science

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 CDISC SHARE can be extended… SALUS MDR (Metadata Source) EHR4CR (Metadata Consumer) Retrieve Metadata DEX Interface 2013 Joint Summits on Translational Science

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. The panel participants will present their technical implementation approaches for integrating EHRs to clinical research and compare it to the specification of the IHE QRPH integration profiles. The panel participants will propose a global use case for a projectathon that leverages the use cases of each of the profiles involved (from the ITI technical framework (CT, XUA, ATNA, RFD) and the QRPH technical framework (CRD, DSC, CRPC, RPE). This global use case reproducing a clinical trial timeline 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. The panel participants will especially focus on semantic interoperability issues. Integrated interoperability for clinics across countries in Europe, requires widespread access to published and maintained collections of coherent and quality-assured semantic resources, including models such as archetypes and templates (providing clinical context) that are based on reference information models (e.g HL7 RIM, openEHR), standardized data elements based on ISO data types and linked to well specified multi-lingual terminology value sets derived from high quality ontologies. The panel will discuss the specific role of the CDISC SHARE initiative and how semantic resources should be defined, validated, and disseminated. The panel will also discuss how users should be educated to improve the quality and consistency of EHR documentation and the re-use of primary health data. 2013 Joint Summits on Translational Science

EHR4CR / TrRANSFoRM use cases
Clinical Research SALUS use cases Patient Safety Use case #1: Identification of populations of patients Protocol feasibility study Patient recruitment Signal detection 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] Use case #2: Extraction of a set of individual clinical data Case Report Form (CRF) pre-population Individual case safety report (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] Use case #3: Extraction of sets of individual clinical Retrospective observational study Use case #1+ Use case #2 Data Element Exchange [DEX] (under development) Security & confidentiality IHE ITI: XUS, CT, ATNA Standards : CDISC (CDASH, Operational Design Model (ODM), Study Design Model (SDM), CSHARE, BRIDG) - HL7 (RIM, DCM, Clinical Statement model, CDA (templates e.g. CCD), Vocabulary) – ISO (ISO 21090, ISO 11179) 2013 Joint Summits on Translational Science

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 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? *« Semantic Interoperability for Better Health and Safer Healthcare. Research and Deployment RoadMap for Europe - Semantic Health Report », January 2009 Current attempts to standardize the capture, representation and communication of clinical data rely upon Agreed clinical data structure definitions e.g. archetypes (ISO EN13606 Part 2) or HL7 templates

Questions ? 2013 Joint Summits on Translational Science

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. 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, SDM-XML affords implementers the ease of leveraging existing ODM concepts and re-using existing ODM definitions. He can use a protocol editor that uses the Data Element Exchange (DEX) profile to access to the on-line metadata registry and select the desired Data Elements from a core Common Data Elements (such as CDSASH, CSHARE) to annotated the SDM. The metadata includes the exact specification, using XPath, to find the corresponding data element in 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

CDISC Study Design Model (SDM) Clinical study concepts
XML-SDM <clinicalStudyDefinition …> <eligibilityCriterion…/> <epoch…/> <arm …/> <timePointEventDefinition …/> <studyCharacteristic…/> <clinicalStudyDefinition/>

CDISC Study Design Model (SDM) Eligibility criteria
2013 Joint Summits on Translational Science

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

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

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

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. 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) and, using a unique identifier for that data element, ‘downloads’ the metadata defined by the metadata registry into an annotated case report form. The metadata includes the exact specification, using XPath, to find the corresponding data element in the HL7 specification Continuity of Care Document (CCD) as extended in the Clinical Research Document (CRD) profile. Using the XPath statements, the research system creates an entire extraction specification for all elements to be extracted from the CCD. This extraction specification provides a map that enables re-use of the proper data within a CCD with precision and without inappropriate access to extraneous information. Both CDISC ODM format of the eCRF and extraction specification are avialable on the EHR-enabled platform. 2013 Joint Summits on Translational Science

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. 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) and, using a unique identifier for that data element, ‘downloads’ the metadata defined by the metadata registry into an annotated case report form. The metadata includes the exact specification, using XPath, to find the corresponding data element in the HL7 specification Continuity of Care Document (CCD) as extended in the Clinical Research Document (CRD) profile. Using the XPath statements, the research system creates an entire extraction specification for all elements to be extracted from the CCD. This extraction specification provides a map that enables re-use of the proper data within a CCD with precision and without inappropriate access to extraneous information. Both CDISC ODM format of the eCRF and extraction specification are avialable on the EHR-enabled platform. 2013 Joint Summits on Translational Science

Figure 2-1: CRD+RSP Swimlane Diagram
Redactor Extraction Specification Manager Form Manager Form Receiver/ Document Consumer Form Archiver Form Filler/ Document Source Send Export document [QRPH-31] Retrieve Extraction Specification [QRPH-33] Return redacted document [QRPH-32] Retrieve Form [ITI-34] Submit Form [ITI-35] Archive Form [ITI-36] Figure 2-1: CRD+RSP Swimlane Diagram

Providing RFD formID to the EHR
<clinicalStudyDefinition xmlns= “urn: hl7-org:v3” ….>   <component4 typeCode="COMP"> <timePointEventDefinition classCode="CTTEVENT" moodCode="DEF">  <id root=" " extension=" ACT.VISIT1"/> <code code=" ACT.VISIT1 " codeSystem=" "> <displayName value=" Clinical trial visit 1"/> </code> <subjectOf typeCode="SUBJ"> <timePointEventCharacteristic classCode="VERIF" moodCode="EVN">  <id> <item root=" " extension="form2ID"/> </id> <code code="FO.VISIT1" codeSystem=" " /> <value xsi:type="TEL" value=" </timePointEventCharacteristic> </subjectOf> </timePointEventDefinition> </component4>  </clinicalStudyDefinition>

Providing Adverse Event formID to the EHR
<clinicalStudyDefinition xmlns= “urn: hl7-org:v3” ….>  <!—Adverse events --> <component4 typeCode="COMP"> <timePointEventDefinition classCode="CTTEVENT" moodCode="DEF">  <id root=" " extension="ACT.AdverseEvent"/> <code code="ACT.AdverseEvent" codeSystem=" "> <displayName value=" Adverse Event"/> </code> <subjectOf typeCode="SUBJ"> <timePointEventCharacteristic classCode="VERIF" moodCode="EVN"> <!—Adverse Event Form ID --> <id> <item root=" " extension="form3ID"/> </id> <code code="FORM.AE" codeSystem=" " /> <value xsi:type="TEL" value=" </timePointEventCharacteristic> </subjectOf> </timePointEventDefinition> </component4>  </clinicalStudyDefinition>

Providing RSP ExtractionID to the EHR
<clinicalStudyDefinition xmlns= “urn: hl7-org:v3” ….>  <component4 typeCode="COMP"> <timePointEventDefinition classCode="CTTEVENT" moodCode="DEF">  <id root=" " extension=" ACT.VISIT1"/> <code code=" ACT.VISIT1 " codeSystem=" "> <displayName value=" Clinical trial visit 1"/> </code> <subjectOf typeCode="SUBJ"> <timePointEventCharacteristic classCode="VERIF" moodCode="EVN"> <!—RSP Extraction Specification --> <id> <item root=" " extension="extractionSpecificationID"/> </id> <code code="extractionID.VISIT1" codeSystem=" " /> <value xsi:type="TEL" value=" </timePointEventCharacteristic> </subjectOf> </timePointEventDefinition> </component4>  <clinicalStudyDefinition />

Providing the RFD orgID to the EHR
<clinicalStudyDefinition xmlns= “urn: hl7-org:v3” ….>     <subjectOf typeCode="SUBJ"> <studyCharacteristic classCode="CLNTRL" moodCode="EVN">  <code code="orgID" valueSet=" "/> <statusCode code="active"/> <value xsi:type="TEL" value="X12"/> </studyCharacteristic> </subjectOf> </clinicalStudyDefinition>

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 EHR Clinical Research Functional Profile was developed jointly through the eClinical Research Forum and a PhRMA EDC Task Force. This functional profile took into account the GCPs and global regulations to define the requirements for an EHR to do regulated research. This profile passed HL7 ballots to become an ANSI/HL7 standard and was then reviewed and modified to become a set of criteria that EuroRec has published and uses in certifying EHRs for the purpose of research. Most recently, because there is interest in having one international global functional profile, the Joint Initiative Council (JIC) for Global Harmonization of Standards (which includes ISO, CEN, CDISC, HL7, IHTSDO, GS1) has recommended that this be a JIC project to meet global needs for an EHR Clinical Research Functional Profile upon which certifications can be based. EHR Clinical Research Functional Profile ANSI/HL7 standard used by EuroRec in certifying EHRs for the purpose of research the Joint Initiative Council (JIC) for Global Harmonization of Standards (which includes ISO, CEN, CDISC, HL7, IHTSDO, GS1) has recommended that this be a JIC project to meet global needs for an EHR Clinical Research Functional Profile upon which certifications can be based. Platform services shall implement standard-based integration profiles Already existing (IHE RFD – CRD) New profiles proposed to the IHE Quality, research and Public Health (QRPH) domain e.g : services (CTS2, CRFQ), content (CDISC SHARE) That will be tested during projectathons (based on Integrating the Healthcare Enterprise (IHE) connectathons) ePSOS project for cross-border e-prescription Accreditation and certification will enable research and clinical trials to be delivered more cost effectively. Both accredited vendors (certified products) & hospitals : certified source data) will have a competitive advantage. Testing platform services during projectathons (based on Integrating the Healthcare Enterprise (IHE) connectathons) Standard-based integration profiles 2013 Joint Summits on Translational Science

2013 Joint Summits on Translational Science

Similar presentations

Presentation on theme: "2013 Joint Summits on Translational Science"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

2013 Joint Summits on Translational Science

Similar presentations

Presentation on theme: "2013 Joint Summits on Translational Science"— Presentation transcript:

Similar presentations

About project

Feedback