PHS / Department of General Practice Royal College of Surgeons in Ireland Coláiste Ríoga na Máinleá in Éirinn Knowledge representation in TRANSFoRm AMIA CDSS workshop, 24 th October 2011 Derek Corrigan, Borislav Dimitrov, Tom Fahey

PHS / Department of General Practice Overview Aim to provide overview of TRANSFORM approach to knowledge representation – provide discussion points Distinguish between clinical knowledge vs. patient data Description of development of ontology to support clinical evidence Examples of how the ontology can be used to support querying data Discuss the benefits of this approach Discuss the challenges and issues encountered using this approach

PHS / Department of General Practice Clinical knowledge – what do we mean? Patient Data – traditional model focus –Documentation to support record of patient encounter –Tends to be historic and static to a point in time in nature –Data or document presentation focussed –Existing clinical models traditionally have been EHR focussed Clinical Knowledge –Clinical facts derived from research data that stands alone and separate from a patient context –Dynamically changing as research evolves and develops –Rule based to implement forms of reasoning

PHS / Department of General Practice The TRANSFoRm Project

PHS / Department of General Practice 1 CPR Repository Clinical Prediction Rules Service TRANSFoRm Services 5 CPR Data Mining and Analysis 3 Research Study Designer 2 Distributed GP EHRs With CDSS CPR Analysis & Extraction Tool CP Classifier CP Rules Manager Study Criteria Design Find Eligible Patient 4 Research Study Management Recruit Eligible Patient Study Data Management

PHS / Department of General Practice TRANSFoRm approach Clinical Prediction Rule – core model structure –Well defined and has underlying statistical model in the form of logistic regression models to support electronic derivation from research data –TRANSFoRm has potential to address limitations of traditional CPR development – large populations for derivation, validation infrastructure, dissemination of CPRs as guidelines Ontology of clinical evidence –Using Protégé to define an ontology of clinical evidence that implements CPRs as an evidence interpretation mechanism

PHS / Department of General Practice Ontology Development Tools Protégé – Ontology Development Sesame Triple Store – provides persistent representation Sesame API – provides for programmatic update/manipulation Ontology will provide a service oriented semantic contract for the representation of clinical evidence knowledge for other TRANSFoRm services and software artifacts e.g. provenance, data mining, CDSS interface

PHS / Department of General Practice Ontology Data Representation Generic model representation constructs and rule formulation –RDFS (Schema language) and Web ontology language (OWL) –E.g. “EvidenceSymptom” – “isSymptomOf” – “EvidenceDiagnosis” –SWRL (Semantic Web Rule Language) allows definition of complex chained rules –Person (?x1) ^ hasSibling(?x1,?x2) ^ Man(?x2) → hasBrother(?x1,?x2) Data instance representation –Resource Description Format triples (RDF) – “Subject – Predicate – Object” –E.g. “Dysuria” – “isSymptomOf” – “UrinaryTractInfection” –Predicates/relationships are directional in nature –E.g. “UrinaryTractInfection” – “hasSymptom” – “Dysuria” Distribution format – supports concept composition –Tagged text file in XML like syntax for easy distribution –Import and reuse other ontologies as building blocks

PHS / Department of General Practice Example Question: Provide all differential diagnoses relating to a reason for encounter ICPC2 code “D01” (abdominal pain /cramps general) SELECT ?anyDifferentialDiagnosis WHERE {?anyRFE hasICPC2Code "D01"^^xsd:string. ?anyDifferentialDiagnosis isDifferentialDiagnosisOf ?anyRFE.} EctopicPregnancy Pyelonephritis UrinaryTractInfection ChronsDisease Appendicitis BowelCancer IrritableBowelSyndrome BacterialEnteritis

PHS / Department of General Practice Example Question: Give me all rule criteria and cues for all elements of the Little Symptom Rule for UTI SELECT ?anyCriteriaElement ?anyCueElement ?anyProperty ?anyValue WHERE {?anyRuleElement isRuleElementOf LittleSymptomRule. ?anyCriteriaElement isCriteriaOf ? ?anyRuleElement. ?anyCueElement isCueElementOf ?anyRuleElement. ?anyCriteriaElement ?anyProperty ?anyValue. ?anyProperty rdf:type owl:DatatypeProperty. } UTI1Crit1 UTI1Crit2UTI1Crit3UTICrit4 UrineCloudiness UrineSmellDysuria Nocturia isPresent isPresent 1 (True) 1 (True)

PHS / Department of General Practice Observations on the ontological approach RDF provides an alternative model approach by reducing data representation to a very simple form without use of complex reference models – reduced complexity paradoxically increases power! The addition of RDFS and OWL add a semantic interpretation layer on top of the data representation that supports composition and merging of diverse data sources and subsequent inference to generate new facts SPARQL allows for very complex querying using compact data representation that can be easily be done in ‘two directions’ to support ‘top-down’ analysis or ‘bottom-up’ analysis – works well for diagnostic view of data

PHS / Department of General Practice Challenges of ontological approach Ontology validation – who arbitrates on the clinical accuracy and completeness of models? Knowledge governance Vs. Standards governance An ontology is not a working application – development tools are not application focussed and needs ontological to relational mapping to support integration with relational data to provide the ‘working’ application context – duplication of effort? Ontology maintenance is intensive – tools still immature/poorly integrated in development environments Integration /interoperability with EHR using standards and clinical vocabularies – granularity/mapping issues e.g. ICPC2

PHS / Department of General Practice Thank You Discuss!