SALUS Presentation in AMIA CRI 2013 - San Francisco
•Transferir como PPT, PDF•
1 gostou•640 visualizações
Standards-based integration profiles for clinical research and patient safety from SALUS perspective
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Destaque
Semelhante a SALUS Presentation in AMIA CRI 2013 - San Francisco
Semelhante a SALUS Presentation in AMIA CRI 2013 - San Francisco (20)
SALUS Presentation in AMIA CRI 2013 - San Francisco
- 1. 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 1
- 2. 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) ERS, Netherlands EUROREC, France LISPA, Italy WHO- UMC, Sweden INSERM, France OFFIS, Germany TUD, Germany AGFA Healthcare, Belgium ROCHE, Switzerland 2013 Joint Summits on 2 Translational Science
- 3. 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 3 Translational Science
- 4. 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 4 Translational Science
- 5. 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 5 Translational Science
- 6. SALUS Semantic & Technical Interoperability 2013 Joint Summits on 6 Translational Science
- 7. 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 – HL7 CRFQ – From ITI: IHE RFD, From QRPH: IHE 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 • HL7 Study Design Message (SDM) 2013 Joint Summits on 7 Translational Science
- 8. 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 2013 Joint Summits on 8 Translational Science
- 9. 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 9 Translational Science
- 10. 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 10 Translational Science
- 11. 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… MDR ISO/IEC Any other 11179 Metadata 2013 Joint Summits on 11 Translational Science
- 12. 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 12 Translational Science
- 13. 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 13 Translational Science
- 14. An example Execution in SALUS BRIDG Semantic MDR maintains a skos:exactMatch mapping from Preparing LBORRES to “Result.Value” Study design through Local links to SDTM CDEs for an “PerformedObservationResult.value observational Semantic MDR CDISC .Any” study Search and use Semantic MDR BRIDG CDEs from the 1 Semantic MDR local MDR 4 Queries federated Receives the URI of HITSP Metadata MDR Cloud for CDE:“Result.Value” Consumer SDTM 5 “LBORRES” CDISC ODM Study Design Metadata Source Document implementing Search for DEX 7 HITSP 2 CCD 3 Semantic MDR Extraction XPATH of corresponding ODM is annotated CCD element is returned 6 s of the with SDTM Ask for Extraction Specification of HITSP CDE:”Result SDTM CDEs Value” //cda:observation[cda:templateId/@root = '2.16.840.1.113883.10.20.1.31'] /cda:value 2013 Joint Summits on 14 Translational Science
- 15. 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 EHR4CR (Metadata Source) (Metadata Consumer) Retrieve Metadata • CDISC SHARE can be extended… 2013 Joint Summits on 15 Translational Science
Notas do Editor
- 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
- 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
- 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 13606 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.
- 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.
- 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 )
- 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…