Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "A demo of an initial prototype of project idea Mustafa Yuksel & Gokce B. Laleci, SRDC."— Presentation transcript:

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

2 Motivation April 17-18,  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 are sent by the hospitals to the regulatory body  This patient histories in CDA and are 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) 3 April 17-18, 2012 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 ) have also  Condition of heart failure (represented through MedDRA term )  Condition of primary pulmonary hypertension (represented through MedDRA term )  Has already been treated through a vasodilating agent (represented through SNOMEDCT term )  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… 4 April 17-18, 2012 SALUS Technical Kickoff Meeting

5 Exploiting the Initial SALUS Semantic Framework  We have envisioned two use cases to 1. automatically fill in eCRFs 2. facilitate safety studies on EHR systems 5 April 17-18, 2012 SALUS Technical Kickoff Meeting

6 The Components of the initial Demo April 17-18, i. 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. ii. 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 iii. tools for importing semantic representations of the terminology systems and biomedical ontologies as well as aligning these models with the core ontology iv. tools to import clinical documents/messages to the SALUS knowledge base by automatically translating them to the instances of the core ontology v. a library of SPARQL queries to retrieve clinical data corresponding to the CDASH data sets from the knowledge base vi. tools for semantically mediating the documents/messages represented in different clinical research and care standards to one another SALUS Technical Kickoff Meeting

7 April 17-18, SALUS Technical Kickoff Meeting

8 (A) BRIDG DAM as the common “model of meaning” April 17-18,  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 April 17-18, 2012 SALUS Technical Kickoff Meeting 9

10 Sample UML Model from BRIDG Study Conduct Sub Domain April 17-18, 2012 SALUS Technical Kickoff Meeting 10

11 Creating BRIDG Ontology April 17-18, 2012 SALUS Technical Kickoff Meeting 11  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

12 BRIDG Ontology April 17-18, 2012 SALUS Technical Kickoff Meeting 12

13 (B) Mapping Different Content Models to BRIDG DAM Ontology (Common Ontology) April 17-18, 2012 SALUS Technical Kickoff Meeting 13  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  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

14 (B) Mapping CCD “Past Medical History” section to “PerformedMedicalConditionResult” class in BRIDG 14 April 17-18, 2012 SALUS Technical Kickoff Meeting

15 SPINMap Formalism April 17-18, 2012 SALUS Technical Kickoff Meeting 15  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:rule that points to a SPARQL CONSTRUCT query that computes the value of ex:area based on the values of ex:widthand ex: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)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

16 SPINMap vocabulary April 17-18, 2012 SALUS Technical Kickoff Meeting 16  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..

17 April 17-18, 2012 SALUS Technical Kickoff Meeting 17

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

19 (D) Clinical data instance translation procedure April 17-18, SALUS Technical Kickoff Meeting

20 SPIN Map (SPARQL Queries attached to Classes) HL7 Study Design RMISM as an Ontology Source Ontology BRIDG DAM Ontology Target Ontology Ontology Mapping Definition CDISC Study Design Ontology Instance Ontology Mapping Engine (SPIN Engine) Target Ontology Instance (Study Design in the CDISC SDM Ontology) 1. Defining the Mapping2. Instance Translation CEN XSD Instance Study Design (Native XML conformant to CDISC SDM ODM) (D & F) Importing & Exporting Clinical Documents CDISC Study Design ODM as an Ontology Source Ontology BRIDG DAM Ontology Target Ontology Ontology Mapping Definition HL7 Study Design XSD Instance HL7 Study Design Ontology Instance Source Ontology Instance (Study Design in HL7 study Design Ontology) Study Design (Native XML conformant to HL7 study Design RMIM) BRIDG Study Design DAM Ontology Instance BRIDG Study Design DAM Ontology Instance Ontology Mapping Engine (SPIN Engine) April 17-18, 2012 SALUS Technical Kickoff Meeting 20

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 April 17-18, 2012 SALUS Technical Kickoff Meeting 21

22 CDASH Data set example April 17-18, 2012 SALUS Technical Kickoff Meeting 22

23 How CDASH Variables can be used within ODM messages April 17-18, 2012 SALUS Technical Kickoff Meeting 23

24 (E) Aligning the standards harmonized by BRIDG with the SALUS Core Ontology April 17-18,  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 April 17-18, 2012 SALUS Technical Kickoff Meeting 25 PREFIX sp: PREFIX fn: PREFIX bridg: PREFIX bfn: 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). }

26 How and Where these SPARQLs can be exploited April 17-18, 2012 SALUS Technical Kickoff Meeting 26  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)…

27 (D) Exploiting terminology systems within the SALUS Semantic Framework April 17-18,  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 Bioportal seperately (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 April 17-18,  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 BioPortal ontologies:  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 CD Code dtype:value: dtype:value: Uid PerformedMedica lConditionResult value code codeSystem SNOMEDCT rdfs:subClassOf rdf:type skos:notation: ???? salus:SNOMED CT skos:inScheme salus:oid: 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. } salus:terminologyRef Attached to CD class Part A: A part of the SALUS core ontology based on BRIDG DAM Part B: A part of SNOMED CT ontology from Bioportal skos:ConceptSche me rdf:type salus:LOINC salus:ICD9 salus:MedDR A rdf:type √ April 17-18, 2012 SALUS Technical Kickoff Meeting 29

30 Exploiting the Initial SALUS Semantic Framework  We have envisioned two use cases to 1. automatically fill in eCRFs 2. facilitate safety studies on EHR systems 30 April 17-18, 2012 SALUS Technical Kickoff Meeting

31 The Knowledge Base April 17-18,  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: and SNOMEDCT: 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 April 17-18,  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 BioPortal ontologies SALUS Technical Kickoff Meeting

33 April 17-18, 2012 SALUS Technical Kickoff Meeting 33 define input:inference "salus5" prefix bridg: prefix salus: prefix rdfs: prefix dtype: prefix skos: 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 ?ProblemDisplayName. ?performedObservationResult bridg:value ?CodedValue. ?CodedValue salus:terminologyRef ?terminologyCode. ?terminologyCode rdfs:type } Only condition Rest are for binding values to variables in the results set Q1: All patients with history of “Edema of Legs”

34 Available Sample Patient Documents in the Knowledge Base April 17-18, 2012 SALUS Technical Kickoff Meeting 34 Example Patient Summari es edema of ankle (snomed) edema of foot (snomed) edema of leg (snomed) edema (whoart) heart failure (ICD) heart failure unspecifie d (ICD) heart failure (snomed ) acute H. F. (snomed ) chronic H. F. (snomed ) heart failure (whoart ) primary pulmonary hypertensio n (snomed) pph (icd 9) Dipyridam ol 50MG TAB RxNorm Code X X 2X 3 X 4 X 5 X 6 X X 7 X X 8 X X 9 X X 10 (13606)X X None of the medical histories are coded with MedDRA Term:

35 April 17-18, 2012 SALUS Technical Kickoff Meeting 35 MedDRA: Edema of legs SNOMEDCT: Edema of leg SNOMEDCT: Edema of ankle SNOMEDCT: Edema of foot MedDRA: Oedema legs WHOART:0401 Edema equivalantClass subclass equivalantClass Medical History 1,5,6,7,8,9 salus:terminologyRef SNOMEDCT: Instance type SNOMEDCT: Instance type Medical History 2 salus:terminologyRef SNOMEDCT: Instance type Medical History 3 salus:terminologyRef WHOART:0401 Instance Medical History 4 salus:terminologyRef type 1. Through terminology system ontologies and mappings downloaded from BioPortal 2. Instances are created to avoid OWL Full reasoning 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 5. SELECT ?ProblemDisplayName WHERE { ?terminologyCode ?ProblemDisplayName ?performedObservationResult bridg:value ?CodedValue. ?CodedValue salus:terminologyRef ?terminologyCode. ?terminologyCode rdfs:type

36 Facilitating safety studies on EHR systems April 17-18,  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  Instance 8: Patient is using DIPYRIDAMOLE 50MG TAB (RxNorm: )  SNOMEDCT: NDF: C ingredientof  NDF:C39726 RxNorm: SALUS Technical Kickoff Meeting similar

37 April 17-18, 2012 SALUS Technical Kickoff Meeting 37 define input:inference "salus5" prefix bridg: prefix salus: prefix rdfs: prefix dtype: prefix owl: SELECT ?subject ?subjectBirthDate ?MedicationCodeValue ?MedicationDisplayName WHERE { ?termCode rdfs:type. {?termCode salus:ingredientOf ?drugClassA. ?drugClassA owl:equivalentClass ?drugClassB. } UNION {?termCode salus:ingredientOf ?drugClassB} ?drugClassA owl:equivalentClass ?drugClassB. ?medTerminologyCode rdfs:type ?drugClassB ?medTerminologyCode ?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 } Patients with History of “Edema of Legs” Query parameters are mapped to related fields, like date of birth Medication’s coded representation is retrieved as medTerminologyCode Not only medication’s prodcut code, but also active ingredients are checked Through domain specific rules

38 Performance Evaluation April 17-18,  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...


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

Similar presentations


Ads by Google