COI: Brainstorming Document

1. COI: Brainstorming Document

2. Feedback from: • Jyotishman Pathak • Dan Russler • Matt Moores • Alan Ruttenberg • Parsa Mirhaji • Lee Feigenbaum • Ronan Fox • Rachel Richesson • Susie Stephens • Eric Prud’hommeaux

3. Goal • To demonstrate the value of semantic web (SW) specifications in bridging the divide between clinical practice and clinical research • Collaborative development of a proof of concept (POC) that demonstrates key value propositions of using SW specifications • To get buy-in from a wide variety of stakeholders as a prelude to acceptance and adoption of semantic web specifications • Get buy-in for the use case • Get wide participation and involvement of the key stakeholders in various stages of analysis, design and development of the POC. • Re-use existing standards, terminologies, data and information models of existing communities to increase the probability of adoption.

4. Methodology The group has been functioning in a consensus driven manner where opinions are sought at each step from all the stakeholders and a decision is taken based on the consensus so created. It was realized that a critical success factor was to incorporate the views of various communities at each step.

5. Decision 1: Use Case • Use Case Development was lead by Rachel Richesson • Wide variety of use cases were investigated and discussed • Patient Recruitment • Adverse Event Detection • Tracking Patient Through a Clinical Trial • Decision: Focus on Patient Recruitment • Data was assumed to be in an EMR.

6. Re-use of existing Information Models • How can we re-use EMR data for Clinical Research? • HL7/RIM/DCM descriptions may be viewed as a “format” for Clinical Research Data. • Typically clinical data in healthcare delivery systems and applications is represented or transformed into this “format” • CDISC/SDTM description may be viewed as a “format” for Clinical Research questions. • Typically clinical data in clinical trials systems and application is represented or transformed into this format? • Can we ask questions in one “format” when the data represented in another “format”? • How can we implement functionality to map across these “formats”? • The mapping module should be flexible to incorporate extensions in the “formats” • The mapping module should be flexible to “plug and play” with multiple “formats”

7. Decision 2: Information Models • Wide variety of Information Models were considered • HL7/RIM • CDISC/SDTM • Detailed Clinical Models from Intermountain Healthcare • Galen • POMR Ontology (Chimezie) • Eligibility Criteria Ontology (Helen) • Healthcare Delivery Encounter-based Meta Model (Parsa Mirhaji) • Conclusions • No one ontology/information model is likely to fit the bill • Align as closely as possible to existing information model and terminology standards as possible • Identify gaps and inadequacies in addressing the use case at hand. • Provide feedback to standards groups: CDISC, HL7/RIM, BRIDG • Decision: Use CDISC/SDTM, Detailed Clinical Models, HL7/RIM as “seed” ontologies to begin with • Iteratively refine them as gaps and inadequacies are discovered

8. Demonstrate Re-use • Re-use of data from the EMR for Clinical Research • Re-use of existing vocabularies, e.g., NCI Thesaurus, Snomed, MedDRA • Re-use of pre-existing information models e.g., HL7/RIM/DCM, SDTM • Identify and Re-use software components that can be used to enable a wide range of use cases • Patient Recruitment • Adverse Drug Event Detection • Tracking a Patient through a Clinical Trial • Develop the POC based on an implementation of these re-usable components • Components that implement mapping • Components that implement data retrieval • Components that implement wrappers/trasnformations • Components that implement checking for elgibility criteria, adverse events and other clinical events of significance.

9. Decision 3 • Decided to implement POC on a real world data set as opposed to a synthetically created data set. This raised the following issues: • What would be an appropriate “seed’ Information Model/Ontology to describe healthcare data based on current state. • What are appropriate terminologies (e.g., Snomed, LOINC, RxNorm) that need to be considered to capture coded information in healthcare data based on current state • Parsa Mirhaji provided the data and his feedback was crucial in identifying the appropriate “seed” model/terminology

10. Decision 4 • Based on discussions with W3C folks such as Ralph Swick, Karen Myers, Steve Bratt, Eric P. • W3C is interested in working with external standards bodies such as HL7 and CDISC and express their content using Semantic Web specification such as RDF and OWL – Steve Bratt at the Bio IT World Luncheon • Implication about W3C being a content neutral • Bron Kisler emphasized that since W3C is providing only the languages, a collaboration would be synergistic and would make sense • Is it possible to develop a collaborative interest group with involvement of HL7, CDISC and others – conversation with Ralph Swick

11. One proposed Solution Architecture Protocol Specification Interface Mapping Module RDF Transformation Engine Eligibility Checking Module CTMS EMR System

12. Decision 5 • Current State Assumptions • Information Models and Vocabularies used in Clinical Trials Context are different from those used in the Healthcare Delivery context • Emphasis on the mapping aspect • Support Plug and Play of different Information Models and Vocabularies • Technology Choices: • SPARQL • N3 rules

13. Mapping Module • Critical component of the key goal of this effort. • i.e., To gain acceptance from a wide variety of stakeholders in the healthcare and clinical trials space. • HL7/RIM/DCM – seek alignment with healthcare standards • CDISC/SDTM – seek alignment with clinical trials standards • Develop Mappings across these two models • Identify limitations and gaps across these models • Scope: • Focus only on those data items that are required for patient recruitment • Focus only on those data items that are related to diabetes and hypertension • To be driven in some part by “mock” diabetes and hypertension records

14. Use Case Step Through • Clinical Trial Administrator uses the Protocol Specification Interface to specify the eligibility criteria. The data items are specified using elements from the SDTM model. • The mapping module translates the data items to the appropriate HL7/RIM/DCM representation. • Appropriate queries are made to the Mediator/Gateway module. • The Mediator/Gateway module translates the query into the underlying database query language. The query is executed at the database and sent to the mapping module. • The mapping module retranslates the data into terms from the SDTM model. • The Eligibility Checking Module checks which patients satisfy the eligibility criteria. • The selected patients are returned to the Clinical Trial Administrator Note: Some eligibility criteria may not be expressible using SPARQL queries and may required rules, etc.

15. Next Steps: Narrow Scope for Implementation • Choose a protocol for implementation #8 (second one) • Limit Scope to Medications, Lab Tests and Vital Signs • Develop Clinical Trials Ontology and Clinical Practice Ontology • Iterative development • Alignment with standards as closely as possible • Implement RDF data store based on data requirements and mock patients • Implement Mapping module using N3 rules • Implement Eligibility checking module using SPARQL • Try to demonstrate another use case for Adverse Drug Event Detection.

16. Specification of Eligibility Criteria • Assume we will use an ontology or rule-based tool to specify eligibility criteria • Open to NLP/Ontology-based approaches that translate free text clinical protocol specifications that transform these into a structured form • Examples: • Type 1 diabetes and/or history of ketoacidosis • History of long-term therapy with insulin (>30 days) within the last year

17. Eligibility Criteria Specification • The functional requirements for this need to be identified and spec’ed out. For e.g., • Temporal Constraints • Trends on clinical data and values • … • Out of Scope for POC. • May want to see if the CT or HC communities have done some work on standards for specifying eligibility criteria. • Out of Scope for POC

18. Design Choice: Eligibility Criteria as a “layer” around Data Items • Data Items • Problem: Type 2 Diabetes • History of Problem: Ketoacidosis • History of Therapy • Name: Insulin • Length: X days • Time Period: [Date1, Date2] • Eligibility Criteria: • Rule conditions • Patient has Type 2 Diabetes • Patient has History of Ketoacidosis • Patient has History of Therapy: • Name = Insulin • X > 30 days • Time Period < 1 year

19. Mappings: Goal/Methodology • Characterize the various data items required for patient recruitment (modulo scope)  List of requirements on the data content Tab • http://spreadsheets.google.com/ccc?key=pINNryLt_vyDiPyHj11WiDg&hl=en_US&pli=1 • For each data item do the following: • Identify the RIM/DCM construct(s) that models that data item  DCM column under Models • Identify the SDTM construct(s) that models that data item  SDTM column under Models • Identify the terminologies that model some of the values required  Terminology Columns including Snomed, MedDRA and NCI Thesaurus • Identify the data types and values that characterize the values of some of the data items  Data Types and Units columns including those for RIM and SDTM • We will be considering various constructs of HL7/RIM, Detailed Clinical Models and other models in conjunction

20. Consider a Data Item Example: • History of Therapy • Name: Insulin • Length of Therapy: 100 days • StartDate: Date • EndDate: Date

21. Mapping Methodology • Identify Information Model Elements • Therapy => • SubstanceAdministration (HL7/RIM) • effectiveTime • statusCode • Medication (subClass of ManufacturedMaterial, HL7/RIM) • Specific type of Participation called Consumable (HL7/RIM) • Insulin => • Medication.Name (HL7/RIM) • Identify Controlled Vocabularies • Medication.Name => Controlled Vocabulary RxNorm (also known as Terminology Binding) • Identify Data Types • Dates and Times => TS data type in HL7 • Identify Units • Included in the definition of data types … taken from the UCUM standard

22. Mapping Methodology (Continued) • Mappings between Information Model elements; • SystolicBP VSTEST, VSTESTCD = SYSBP • Mappings between controlled vocabularies: • SystolicBP  “Some Snomed Concept” • SYSBP  “Some NCI Thesaurus Concept” • “Some Snomed Concept”  “Some NCI Thesaurus Concept” • Between Data Types and Units • HL7:PQ  VSRESU

23. Design Choice: Leverage Existing Implementations and Systems • SHER System • Re-use the Reasoner to compute eligibility criteria • Semantic DB System • Re-use the NLP parser (if available) to parse the textual representation of the clinical trials criteria into structured queries, rules, whatever

24. Technical: Eligibility Criteria in OWL Patientthat (hasProblem some DiabetesType 1 or hasHistory some Ketacidosis)and hasTherapy (some Therapy that hasLength all int[>30] and hasTimePeriod all int[< 365]) Just for illustration purposes … need thorough and detailed analysis to get it right.

25. Technical Design: Eligibility Criteria using Rules IF (the_patient.hasProblem = DiabetesType 1 OR the_patient.hasHistory = Ketacidosis) AND the_patient.hasHistory.name = Insulin AND the_patient.hasHistory.length > 30 AND the_patient.hasHistory.timePeriod < 365 THEN the_patient is eligible for the clinical trial

26. Mapping Design Issues • Are mappings always 1-1? • Is it always possible to get synonym mappings? • What happens to these mappings when there are changes in the information models? • Are these mappings enough to enable a bi-directional flow through between EMR and Clinical trials data?