A demo of an initial prototype of project idea

1. A demo of an initial prototype of project idea Mustafa Yuksel & Gokce B. Laleci, SRDC

2. Motivation • Currently, the clinical research and the clinical care domains are quite disconnected because each use different standards and terminology systems. • In contrast to CDISC standards used in the clinical research domain, in the clinical care domain, the most widely used content and messaging standards are by HL7 • The terminology systems are quite different as well: While MedDRA, WHODD and CDISC Terminology are commonly used in the clinical research domain; the prominent terminology systems in clinical care domain include SNOMED CT, LOINC, ICD-9 and ICD-10 • The available integration efforts are mostly proprietary, custom developed for a specific use-case and depend on hard-coded n x n mappings among standards • For example, the Electronic Data Capture (EDC) systems are usually not connected to the EHR systems that are used by the health care providers. • The clinicians have to manually copy the results of therapeutic procedures and examinations from an EHR system into the Case Report Form (CRF), which causes errors and work disruption as well as delays in reporting data. SALUS Technical Kickoff Meeting

3. Visionary Scenario • A new Calcium Channel Blocker is marketed after a successful clinical trial period • The regulatory body receives Adverse Event reports indicating that this new drug causes swelling of legs • The regulatory body decides to conduct a more extended post market safety study (or asks the Pharmaceutical Company to do so) • Prepares the Study Protocol in CDISC SDM • Eligibility criteria: Patients who have recently been treated with this new Calcium Channel Blocker • Collect all of the other symptoms, diagnoses, allergies, medications of this patient in the first visit • This protocol definition is sent to the health care providers that are in SALUS cslinical research community • Patient history documents conforming to the protocol definition, and in different schemas such as HL7 CDA and CEN EN 13606 are sent by the hospitals to the regulatory body • This patient histories in CDA and 13606are translated to BRIDG Model • Form Manager processes the Study Design, identifies the items requested in CRF Forms from their annotation in CDASH • The patient history in BRIDG is queried through the predefined queries defined for each CDASH variable (they can be used for semi-autmatically filling in CRF forms) SALUS Technical Kickoff Meeting

4. Visionary Scenario (continued) • After collecting significant data from some patients, the regulatory body prepares the statistical analysis data by semantically querying the collected data represented in BRIDG Model • Number of patients who have experienced edema in legs (represented through MedDRA term 10014239) have also • Condition of heart failure (represented through MedDRA term 10019279) • Condition of primary pulmonary hypertension (represented through MedDRA term 10036727) • Has already been treated through a vasodilating agent (represented through SNOMEDCT term 58944007) • Participating health care providers code observations through ICD-9, SNOMED CT terms, record adverse events through Who-Art, and record the medications provided through RxNorm • After the analysis, it has been clarified that the adverse event incidents are mostly related with the underlying condition or current treatment of the patients… SALUS Technical Kickoff Meeting

5. Exploiting the Initial SALUS Semantic Framework • We have envisioned two use cases to • automatically fill in eCRFs • facilitate safety studies on EHR systems SALUS Technical Kickoff Meeting

6. The Components of the initial Demo • the BRIDG DAM ontology expressed in RDF as the core ontology hosted in a knowledge base • We have developed the RDF representation of the BRIDG DAM v3.0.3 to be used as the core ontology to make the common shared semantics available in a formal, machine processable form. • tools for semantic lifting of the content standards harmonized by the BRIDG initiative including HL7 RIM based models, CDISC ODM based models and for aligning these semantic models with the core ontology in the knowledge base • tools for importing semantic representations of the terminology systems and biomedical ontologies as well as aligning these models with the core ontology • tools to import clinical documents/messages to the SALUS knowledge base by automatically translating them to the instances of the core ontology • a library of SPARQL queries to retrieve clinical data corresponding to the CDASH data sets from the knowledge base • tools for semantically mediating the documents/messages represented in different clinical research and care standards to one another SALUS Technical Kickoff Meeting

7. SALUS Technical Kickoff Meeting

8. (A) BRIDG DAM as the common “model of meaning” • The BRIDG DAM is an implementation independent UML model to represent common shared semantics of regulated clinical research studies which may have different implementations • In 2003, CDISC, and HL7 signed a 2-year-old Memorandum of Understanding (MoU) to work collaboratively on the data exchange standards in domains that are of interest to both organizations and to create a Domain Analysis Model (DAM) as an implementation independent model of the shared semantics • Later NCI through their CaBIG Project, and FDA joined the group • A reverse engineering effort to create the DAM is initiated • From the already existing HL7 RCRIM messages • From the CDISC CDASH, SDTM Data sets and ODM Models • BRID DAM is composed of five sub-domains: • Protocol Representation, Study Conduct, Adverse Event, Regulatory and Common • Implementation independent UML Model • CDISC SDM and HL7 Study Design RMIM are both implementations of Protocol Representation Sub Domain • Hence, it is the best alternative to be the starting point for core of our Semantic Framework SALUS Technical Kickoff Meeting

9. Sample UML Model from BRIDG Study Conduct Sub Domain SALUS Technical Kickoff Meeting

10. Sample UML Model from BRIDG Study Conduct Sub Domain SALUS Technical Kickoff Meeting

11. Creating BRIDG Ontology • We have created a complete RDF representation of the latest BRIDG DAM (v3.0.3) • UML -> XMI -> XSD -> RDF conversion • Utilization of several tools (Enterprise Architect, Visual Paradigm, Topbraid Composer) • Manual fine-tuning • It was quite an effort… • In the end, the RDF representation of the BRIDG DAM is the core of the initial SALUS Semantic Framework, which we call SALUS core ontology • Note that SALUS core ontology has a living and expanding nature SALUS Technical Kickoff Meeting

12. BRIDG Ontology SALUS Technical Kickoff Meeting

13. (B) Mapping Different Content Models to BRIDG DAM Ontology (Common Ontology) • Medical summaries available through XML files • Schemas provided through XSD • First we need to create semantic models of these content models • XSD2RDF Normalization Tools can be used • We created RDF model of HL7 CDA and CEN 13606 • Then this semantic model of the Content Models need to be mapped to the Common Ontology • So that mapping definitions can be used to translate medical summary instances as individuals f SALUS Common Ontology SALUS Technical Kickoff Meeting

14. (B) Mapping CCD “Past Medical History” section to “PerformedMedicalConditionResult” class in BRIDG SALUS Technical Kickoff Meeting

15. SPINMap Formalism • SPINMap •  SPARQL-based language to represent mappings between RDF/OWL ontologies • mappings can be used to transform instances of source classes into instances of target classes • Mainly uses the SPARQL CONSTRUCT • particularly useful to define rules that map from one graph pattern (in the WHERE clause) to another graph pattern • Based on SPIN (SPARQL Inferencing Notation) • W3C Submission • makes it easy to associate mapping rules with classes, and SPIN templates and functions can be exploited to define reusable building blocks for typical modeling patterns • Provides a vocabulary: collection of properties and classes that can be used to link RDFS and OWL classes with SPARQL queries • the class ex:Rectangle can define a property spin:rulethat points to a SPARQL CONSTRUCT query that computes the value of ex:area based on the values of ex:widthandex:height. • the property spin:constraint may link the class ex:Square with a SPARQL ASK query that verifies that the width and height values are equal • SPINMap vocabulary (http://spinrdf.org/spinmap) • A collection of reusable design patterns that reflects typical best practices in ontology mapping • Can be executed in conjunction with other SPARQL rules with any SPIN engine SALUS Technical Kickoff Meeting

16. SPINMap vocabulary • Context: • Groups together multiple mappings so that they have a shared target resolution algorithm • The source class of the mapping • The target class of the mapping • The expression that delivers the target of the mapping. This expression can reference the variable ?source for the source resource, and the variable ?targetClass for the type of the target • Usually expressed through a TargetFunction • TargetFunction • Class of SPIN functions used to get the target resource of a mapping • Conditional Construct Statements… • SPIN Rules • Bound to classes and contexts • To map the datatype/object properties of the source-target classes • Can make use of SPIN: Functions • Can make use of the results of the mappings defined through other contexts.. SALUS Technical Kickoff Meeting

17. SALUS Technical Kickoff Meeting

18. Sample Mapping RecordTarget-StudySubject StudySubject -performingBiologcal Entity RecordTarget -hasPatientRole performingBiologicalEntity = targetRecource (RecordTarget, RecordTarget-Person) Person -raceCode -birhDate -administrativeGenderCode PatientRole -hasPatient RecordTarget-Person • raceCode= targetRecource • (RecordTarget, RecordTarget-CD-1) • administrativeGenderCodeCode= targetRecource • (RecordTarget, RecordTarget-CD-2) • birthDate=targetRecource • (RecordTarget, RecordTarget-TS) Patient -hasRaceCode [CE] -hasBirthTime [TS] -hasAdministrativeGenderCode[CE] CS -dtype:Value CD -codeSystem -code -codeSystemName RecordTarget-CD-1 CE -hasCodeSystem [UID] -hasCode [CS] -hasCodeSystemName [string] • code= targetRecource • (RecordTarget, RecordTarget-Code) • codeSystem= targetRecource • (RecordTarget, RecordTarget-Uid) • codeSystemName= copy( • (RecordTarget.hasPatientRole.hasPatient.hasRaceCode.hasCodeSystemName) UID -dtype:Value CE -hasCodeSystem [UID] -hasCode [CS] -hasCodeSystemName [string] CS -dtype:Value Code -dtype:Value RecordTarget-Code UID -dtype:Value TS -dtype:Value [string] • dtype:Value= copy( • (RecordTarget.hasPatientRole.hasPatient.hasRaceCode.hasCode.dtype:value) RecordTarget-Uid Uid -dtype:Value • dtype:Value= copy( • (RecordTarget.hasPatientRole.hasPatient.hasRaceCode.hasCodeSystem.dtype:value) RecordTarget-TS TS -value • value=targetRecource • (RecordTarget, RecordTarget-Class1) RecordTarget-Class1 Class1 -dtype:value SALUS Technical Kickoff Meeting • dtype:Value= copy( • (RecordTarget.hasPatientRole.hasPatient.hasBirthTime.dtype:value)

19. (D) Clinical data instance translation procedure SALUS Technical Kickoff Meeting

20. Ontology Mapping Definition HL7 Study Design RMISM as an Ontology BRIDG DAM Ontology Source Ontology Target Ontology • (D & F) Importing & Exporting Clinical Documents BRIDG Study Design DAM Ontology Instance HL7 Study Design XSD Instance HL7 Study Design Ontology Instance Ontology Mapping Engine (SPIN Engine) Source Ontology Instance (Study Design in HL7 study DesignOntology) Study Design (Native XMLconformant to HL7 study Design RMIM) SPIN Map (SPARQL Queries attached to Classes) Ontology Mapping Definition CEN 13606 XSD Instance Ontology Mapping Engine (SPIN Engine) BRIDG Study Design DAM Ontology Instance CDISC Study Design ODMasan Ontology BRIDG DAM Ontology CDISC Study Design Ontology Instance Study Design (Native XMLconformant to CDISC SDM ODM) Source Ontology Target Ontology Target Ontology Instance (Study Design in the CDISC SDMOntology) SALUS Technical Kickoff Meeting 1. Defining the Mapping 2. Instance Translation

21. (E) Aligning the standards harmonized by BRIDG (Data Sets) with the SALUS Core Ontology • Clinical Data Acquisition Standards Harmonization • a link between the study data collected through eCRF Forms and the study data submitted to the regulatory bodies as SDTM datasets • a limited set of structured data used for any Clinical Trial, regardless of research sponsors or therapy areas • 16 domains • Adverse Events (problems) • Medications (prior and concomitant) • Demographics and subject characteristics • Medical History • Vitals/ Physical Exam • ECG test results • Lab results • Sites have always been asked to complete non-standard CRFs while patients are performing daily assessments, and CRFs are expected to be completed on time and accurately by the site • variety of CRF questions and layouts is almost unlimited • The current 16 CDASH CRFs are associated with standard SDTM mappings and standard CDISC controlled terminology • The eCRF design time is shortened as CDASH eCRF forms can be pulled out of the EDC library as and when they are needed • Standard CDASH CRFs can be transformed to standard SDTM datasets using standard extract transform load (ETL) code SALUS Technical Kickoff Meeting

22. CDASH Data set example SALUS Technical Kickoff Meeting

23. How CDASH Variables can be used within ODM messages SALUS Technical Kickoff Meeting

24. (E) Aligning the standards harmonized by BRIDG with the SALUS Core Ontology • In the first case, the mappings between vocabularies termed as “data sets” (as in the case of CDASH variables) and the BRIDG based core ontology is addressed • This is quite straightforward, since it is possible to write SPARQL queries on top of BRIDG DAM to retrieve the requested CDASH variable • We have developed a library of sample SPARQL queries to extract several CDASH variables SALUS Technical Kickoff Meeting

25. An example SPARQL to collect fields in Medical History Data set in CDASH PREFIX sp: <http://spinrdf.org/sp#> PREFIX fn: <http://www.w3.org/2005/xpath-functions#> PREFIX bridg: <http://bridgmodel.org/dam/3.0.3#> PREFIX bfn: <http://www.salus.eu/bridg-functions#> SELECT ?MHONGO ?MHSTDAT ?MHENDAT ?MHTERM ?MHTERM_CD ?MHTERM_CS ?MHTERM_CS_NAME WHERE { ?p a bridg:PerformedMedicalConditionResult . OPTIONAL { ?p bridg:medicalHistoryIndicator ?mhi . ?mhi bridg:value ?MHONGO . } OPTIONAL { ?p bridg:occurrenceDateRange ?odr . ?odr bridg:low ?odrlow . BIND (bfn:getTSValue(?odrlow) as ?MHSTDAT) . ?odr bridg:high ?odrhigh . BIND (bfn:getTSValue(?odrhigh) as ?MHENDAT) . ?odr bridg:value ?odrval . BIND (bfn:getTSValue(?odrval) as ?midval) . BIND (if( (!bound(?MHSTDAT) && !bound(?MHENDAT)), ?midval, ?MHSTDAT) as ?MHSTDAT) . } OPTIONAL { ?p bridg:value ?val . BIND (bfn:getCDCode(?val) as ?MHTERM_CD) . BIND (bfn:getCDDisplayName(?val) as ?MHTERM) . BIND (bfn:getCDCodeSystem(?val) as ?MHTERM_CS) . BIND (bfn:getCDCodeSystemName(?val) as ?MHTERM_CS_NAME) . } } SALUS Technical Kickoff Meeting

26. How and Where these SPARQLs can be exploited • Study Design Model is represented in CDISC ODM where it is also annotated with CDASH variables to specify the data to be collected through CRFs • The Medical Summaries are collected through SALUS • They are mapped to SALUS Common Ontology instances • The EDC system can automatically parse the Study Design Model annotated with CDASH variables • query the knowledge base already containing the medical history of the patient in the common ontology • This is achieved using the pre-defined SPARQL queries for CDASH variables • This eliminates static XSLT based mappings between Medical Histories and CDASH annotated ODM messages representing CRFs (as proposed by IHE CRD)… SALUS Technical Kickoff Meeting

27. (D) Exploiting terminology systems within the SALUS Semantic Framework • Imported the following terminology systems from BioPortal into the SALUS Knowledge Base • ICD-9: 21,669 terms • ICD-10: 12,318 terms • WHO-ART: 1,724 terms • MedDRA: 69,389 terms • National Drug File (NDFRT): 40,104 terms • SNOMEDCT Clinical findings (97,139 terms) + Pharmaceuticals / biologic products (17,100 terms) • RxNorm: 194,176 terms • Human Disease Ontology (DOID): 8,574 terms • It has references to other Ontologies such as ICD and SNOMED CT through DbXref property to indicate equivalances • Those are processed to create additional Mapping Definitions • And, 133,825 unique code mappings • Not very straight forward • Usually it is not possible to download the full ontology through a singe Rest Service due to timeouts • The class names in an ontology are collected • These classes are retrieved from Bioportalseperately (100 class each time) • Then these subontologies are merged • Some of the Class UIDs were incorrect (for ICD), they are corrected manually SALUS Technical Kickoff Meeting

28. (D) Aligning the Common Ontology with Terminology Ontologies • To be able to automatically map the clinical data using different terminology systems to one another, it is necessary to link the coded terms in SALUS core ontology instances representing clinical data collected from participating sites with the SALUS terminology ontology resources, and to utilize terminology reasoning while querying the collected clinical data. • Two heuristics that we have adapted on top of BioPortalontologies: • We automatically create the instances of BioPortal ontology classes and copy all non-rdfs and non-owls properties from the class definitions to the instances, to prevent OWL-Full ontologies • Within a term present in a terminology ontology retrieved from BioPortal, the original terminology system name is implicitly given in the full URL of the term • However, we need to immediately get the encapsulating terminology system of any term • Therefore, we automatically run a SPARQL rule to add a “skos:inScheme” property to each instance in the terminology ontologies that we retrieve from BioPortal. • We maintain an upper ontology (SALUS Terminology Upper Ontology), in which the major terminology systems used in our system are represented as the individuals of “skos:ConceptScheme” class. • This way, we are able to execute a SPARQL rule to automatically bind a “CD” instance (a coded value) in BRIDG model to the corresponding BioPortal ontology instance via “salus:terminologyRef” property SALUS Technical Kickoff Meeting

29. skos:ConceptScheme CONSTRUCT { ?this salus:terminologyRef ?codeRef . } WHERE { ?this p3.0:code ?code . ?code dtype:value ?codeValue . ?this p3.0:codeSystem ?codeSystem . ?codeSystem dtype:value ?codeSystemRef . BIND (str(?codeSystemRef) AS ?csr) . ?codeOIDRef salus:oid ?csr . ?codeRef skos:inScheme ?codeOIDRef. BIND (str(?codeValue) AS ?cv) . ?codeRef skos:notation ?cv . } rdf:type rdf:type salus:ICD9 rdf:type salus:MedDRA salus:LOINC Attached to CD class rdf:type SNOMEDCT salus:SNOMEDCT PerformedMedicalConditionResult salus:oid: 2.16.840.1.113883.6.96 <http://purl.bioontology.org/ontology/SNOMEDCT/102572006 > value ???? dtype:value: 2.16.840.1.113883.6.96 CD rdfs:subClassOf codeSystem <http://purl.bioontology.org/ontology/SNOMEDCT/102574007> Uid skos:inScheme code Code rdf:type dtype:value: 102574007 <http://purl.bioontology.org/ontology/SNOMEDCT#Ins_102574007> salus:terminologyRef skos:notation: 102574007 √ Part A: A part of the SALUS core ontology based on BRIDG DAM Part B: A part of SNOMED CT ontology from Bioportal SALUS Technical Kickoff Meeting

30. Exploiting the Initial SALUS Semantic Framework • We have envisioned two use cases to • automatically fill in eCRFs • facilitate safety studies on EHR systems SALUS Technical Kickoff Meeting

31. The Knowledge Base • All the semantic artifacts are hosted in a knowledge base • The main consideration for the choice of the SALUS knowledge base is its performance, which is related directly to the complexity of the reasoning process • Our reasoning requirements: • Subsumption reasoning: Crucial to deduce matching coded terms that are aligned with different terminology ontology class instances, which in fact have the same ancestor in the terminology ontology • “Acute heart failure” is a child of “heart failure” in SNOMED CT • Reasoning on equivalence of classes: In SALUS, the mappings of the terms in different terminology ontology classes to each other are represented through “owl:equivalentClass” property. We should be able to classify individuals of a class also as the individuals of its equivalent classes. • Both MedDRA:10019279 and SNOMEDCT:84114007 mean “heart failure” • Reasoning on transitivity of properties: “owl:equivalentClass” property is inherently a transitive property. It should be possible for us to process transitive equivalences, in order to classify individuals of a class also as the individuals of its equivalent classes that are deduced to be equivalent through transitivity. • When we calculate the transitive closure of the 133,825 unique code mappings that we retrieved from the BioPortal, the number of mappings increase to 186,712 SALUS Technical Kickoff Meeting

32. The Knowledge Base • Clearly all the RDF and OWL-DL reasoners support all our reasoning requirements and much more. • However, due to the very large number of triples (around 4.7 million) to be reasoned on in the SALUS knowledge base, we have chosen Virtuoso. • Virtuoso supports a limited reasoning capability when compared to other RDF and OWL-DL reasoners; however the limited set of constructs supported includes rdfs:subClassOf, rdfs:subPropertyOf, owl:sameAs, owl:transitiveProperty and owl:equivalentClass, which fully address the SALUS Framework reasoning requirements. • In addition, we benefit from Protege with Fact++reasoner support, for calculating the transitive closure only via the “owl:equivalentClass” property • It was not possible to run DL reasoning with other reasoners (Jena, OWLim, Fact++, Pellet, Hermit) when we load the BioPortalontologies SALUS Technical Kickoff Meeting

33. Q1: All patients with history of “Edema of Legs” define input:inference "salus5" prefix bridg: <http://bridgmodel.org/dam/3.0.3#> prefix salus: <http://www.salus.eu/ontology/clinical#> prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> prefix dtype: <http://www.linkedmodel.org/schema/dtype#> prefix skos: <http://www.w3.org/2004/02/skos/core#> SELECT ?subject ?subjectBirthDate ?ProblemCodeValue ?ProblemcodeSystemName ?ProblemDisplayName ?StartingDate ?EndDate ?ProblemDate WHERE { OPTIONAL{ ?dateRange bridg:value ?datevalue. } OPTIONAL{ ?datevalue bridg:value ?ProblemDate.} OPTIONAL{ ?dateRange bridg:high ?high. } OPTIONAL{ ?high bridg:value ?EndDate.} OPTIONAL{ ?dateRange bridg:low ?low.} OPTIONAL{ ?low bridg:value ?StartingDate.} ?performedObservationResult bridg:occurrenceDateRange ?dateRange. ?CodedValue bridg:codeSystemName ?ProblemcodeSystemName. ?ProblemCode dtype:value ?ProblemCodeValue. ?CodedValue bridg:code ?ProblemCode. ?birthdatevalue dtype:value ?subjectBirthDate. ?birthdate bridg:value ?birthdatevalue. ?performingBiologicalEntity bridg:birthDate ?birthdate. ?subject bridg:performingBiologicEntity ?performingBiologicalEntity. ?performedObservation bridg:involvedSubject ?subject. ?performedObservation bridg:resulted ?performedObservationResult. ?terminologyCode <http://www.w3.org/2000/01/rdf-schema#label> ?ProblemDisplayName. ?performedObservationResult bridg:value ?CodedValue. ?CodedValue salus:terminologyRef ?terminologyCode. ?terminologyCode rdfs:type <http://purl.bioontology.org/ontology/MDR/10014239> } Rest are for binding values to variables in the results set Only condition SALUS Technical Kickoff Meeting

34. Available Sample Patient Documents in the Knowledge Base None of the medical histories are coded with MedDRA Term:10014239 SALUS Technical Kickoff Meeting

35. 5. SELECT?ProblemDisplayName WHERE { ?terminologyCode <http://www.w3.org/2000/01/rdf-schema#label> ?ProblemDisplayName ?performedObservationResult bridg:value ?CodedValue. ?CodedValue salus:terminologyRef ?terminologyCode. ?terminologyCode rdfs:type <http://purl.bioontology.org/ontology/MDR/10014239> SNOMEDCT: 102576009 Instance SNOMEDCT:102574007 Instance SNOMEDCT:102574007 Edema of leg SNOMEDCT: 102576009 Edema of foot MedDRA: 10014239 Edema of legs MedDRA:10030105 Oedema legs WHOART:0401 Instance SNOMEDCT:26237000 Edema of ankle SNOMEDCT:26237000 Instance WHOART:0401 Edema 1. Through terminology system ontologies and mappings downloaded from BioPortal 2. Instances are created to avoid OWL Full reasoning type salus:terminologyRef equivalantClass equivalantClass subclass subclass type Medical History 3 type type equivalantClass type salus:terminologyRef type type salus:terminologyRef Medical History 1,5,6,7,8,9 Medical History 2 salus:terminologyRef 3. After Medical Histories are uploaded in SALUS Common Ontology, through the Rule attached to CD Class, these references are added… 4. Through equivalence, subsumption and transitivity reasoning supported by Virtuoso Medical History 4 SALUS Technical Kickoff Meeting

36. Facilitating safety studies on EHR systems • Q1: All patients with history of “Edema of Legs” • Q2: All patients with history of “Edema of Legs” AND “Heart Failure” • Q3: All patients with history of “Edema of Legs” AND history of “primary pulmonary hypertension ” • Q4: All patients with history of “Edema of Legs” AND actively using a “vasodilating agent” • Vasodilating agent: SNOMEDCT 58944007 • Instance 8: Patient is using DIPYRIDAMOLE 50MG TAB (RxNorm: 197622) • SNOMEDCT:58944007 <-- subClassOf – SNOMEDCT: 66859009 <-equivalentClass-> NDF: C24056--ingredientof NDF:C39726 <-equivalentClass-> RxNorm: 197622 similar SALUS Technical Kickoff Meeting

37. define input:inference "salus5" prefix bridg: <http://bridgmodel.org/dam/3.0.3#> prefix salus: <http://www.salus.eu/ontology/clinical#> prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> prefix dtype: <http://www.linkedmodel.org/schema/dtype#> prefix owl: <http://www.w3.org/2002/07/owl#> SELECT ?subject ?subjectBirthDate ?MedicationCodeValue ?MedicationDisplayName WHERE { ?termCode rdfs:type <http://purl.bioontology.org/ontology/SNOMEDCT/58944007>. {?termCode salus:ingredientOf ?drugClassA. ?drugClassA owl:equivalentClass ?drugClassB.} UNION {?termCode salus:ingredientOf ?drugClassB} ?drugClassA owl:equivalentClass ?drugClassB. ?medTerminologyCode rdfs:type ?drugClassB ?medTerminologyCode <http://www.w3.org/2000/01/rdf-schema#label> ?MedicationDisplayName. ?CodedValue salus:terminologyRef ?medTerminologyCode. ?classCode bridg:item ?CodedValue. ?product bridg:classCode ?classCode. ?agenta bridg:performing ?product. ?performedSubstanceAdministration bridg:usedConcomitantAgent ?agenta. ?performedSubstanceAdministration bridg:involvedSubject ?subject. ?subject bridg:performingBiologicEntity ?performingBiologicalEntity. ?performingBiologicalEntity bridg:birthDate ?birthdate. ?birthdate bridg:value ?birthdatevalue. ?birthdatevalue dtype:value ?subjectBirthDate. ?CodedValue bridg:code ?MedicationCode. ?MedicationCode dtype:value ?MedicationCodeValue. ?performedObservation2 bridg:involvedSubject ?subject. ?performedObservation2 bridg:resulted ?performedObservationResult2. ?performedObservationResult2 bridg:value ?CodedValue2. ?CodedValue2 salus:terminologyRef ?terminologyCode2. ?terminologyCode2 rdfs:type <http://purl.bioontology.org/ontology/MDR/10014239> } Not only medication’s prodcut code, but also active ingredients are checked Through domain specific rules Query parameters are mapped to related fields, like date of birth Medication’s coded representation is retrieved as medTerminologyCode Patients with History of “Edema of Legs” SALUS Technical Kickoff Meeting

38. Performance Evaluation • On an average desktop computer (Intel Core 2 Duo 3Ghz CPU and 4 GB RAM), the semantic mediation of a medical history in CCD format to SALUS core ontology takes approximately 110 seconds. • An example SPARQL query to check the underlying conditions of patients can be executed on the knowledge base hosting more than 4.7 million triples under 7 seconds. • These results are quite encouraging for a real-life deployment of the initial Semantic Framework. SALUS Technical Kickoff Meeting

39. Thank you...