1 / 42

A Lightweight and Generic Data Mediating Architecture for Decision Support Systems

A Lightweight and Generic Data Mediating Architecture for Decision Support Systems. Alfonso Pérez alpegon3@upv.es Biomedical Informatics Group (IBIME) ITACA Institute, Technical University of Valencia. Arctic Conference on Dual-Model based Clinical Decision Support and Knowledge Management

skule
Download Presentation

A Lightweight and Generic Data Mediating Architecture for Decision Support Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Lightweight and Generic Data Mediating Architecture for Decision Support Systems Alfonso Pérez alpegon3@upv.es Biomedical Informatics Group (IBIME) ITACA Institute, Technical University of Valencia Arctic Conference on Dual-Model based Clinical Decision Support and Knowledge Management Tromsø, May 27th and 28th, 2014

  2. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  3. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  4. CDSS Interoperability • Curiam CDSS[1] • Generic CDSS for clinical and biomedical environments • Connects to databases through a generic data framework [1] - [C Sáez, JM García-Gómez, J Vicente, S Tortajada, M Esparza, AT Navarro, E Fuster, M Robles. A genericdecisionsupportsystemfeaturinganassembledview of predictivemodelsformagneticresonance and clinical data. EuropeanSocietyforMagneticResonance in Medicine and Biology 2008 Congress, Valencia, Info-RESO, 2008]

  5. CDSS semantic interoperability:HL7-CDA Wrapper <entry><observationclassCode="OBS"moodCode="EVN"><code code="248333004"codeSystem="2.16.840.1.113883.6.96"codeSystemName="SNOMED CT"displayName=“Standing height"/><valuexsi:type="PQ" value="186" unit="cm"/></observation></entry> • Use of standardized clinical documents (i.e. HL7-CDA) as input/output of CDSS[2] CDSS Semantic Interpreter Inference engine (e.g., Jess, Drools) CDA_input.xml CDA_output.xml <valuexsi:type="CV" code="OBJ-X-IMC0"codeSystem="0.0.0.0.0.1.2.1.5.5“ displayName=“BMI above objective."/> rules_file.clp binding_file.xml human/machine interpretable <datadef name="height" code="248333004"codeSystem="2.16.840.1.113883.6.96"><valuexsi:type="PQ" unit="cm"/></datadef> ?BMI setValue (/ ?weight (* (/ ?height 100) (/ ?height 100)))) HL7-CDA template input/output human-maintainable [2] - [C Sáez, A Bresó, J Vicente, M Robles, and JM Garcia-Gomez. An HL7-CDA wrapper for facilitating semantic interoperability to rule-based Clinical Decision Support Systems. Computer Methods and Programs in Biomedicine. Volume 109 (3) 239–249, 2013]

  6. Proforma data collection • Transparent extension of the PROforma engine to permit automatic data collection from different sources[3] PROforma Engine wrapper PROforma Engine guideline.pf dataconfig.xml a b b c DB CDSS XML (HL7-CDA, EN-13606,…) [3] - [A. Pérez González. Generación de interfaces gráficos automáticos a partir de ontologías, aplicación a guías clínicas. 2011]

  7. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  8. Data integration in CDSSs • Problem • Most of the CDSSs working nowadays focus their data needs in one or few different types of data sources • Solution • Develop the new CDSSs independent of the data sources that we want to access • What happens to the already existent CDSS? • Solution • A mediator architecture able to wrap the data modules/petitions of the CDSSs, and adapt them to different data sources

  9. Data integration in CDSSs • Clinical Decision Support Data Mediator (CDS-DATOR) • Lightweight and modular data mediator that facilitates the access to different data sources • Allows the CDSSs to decouple their implementations of the necessities imposed by the data • Designed as a non-invasive data wrapper to ease the integration with already working CDSSs

  10. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  11. CDS-DATOR • CDS-DATOR connectivity schema • Offers different functionalities depending on the situation in the data flow

  12. CDS-DATOR • Data mediator workflow • Can preload data and store it in an intermediate memory • E.g., standardized patient EHR • Data are loaded via Data Loaders which are specified in the mapping file • The data retrieval process is transparent to the CDSS

  13. CDS-DATOR • Data types

  14. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  15. CDS-DATOR • Generic Data Loader • Composed by a set of elements that can be used to define a new DataLoader • The LoaderURI specifies the class that will be used • Any number of parameters (ParameterOption) can be specified • Each parameter can have one (SimpleParameter) or several (MultiParameter) values. • These parameters look up the data using the ValueOption interface UML Schema of the Generic Loader

  16. CDS-DATOR • Generic Data Loader • Example code (Xpath Loader) <dataLoaderxsi:type="GenericDataLoader"> <loaderURI>es.upv.ibime.bmg.cdsdc.xpathloader.XPathDataLoader</loaderURI> <parameterxsi:type="SimpleParameter" id="url"> <parameterValuexsi:type="URL">C:/patientData.xml</> </parameter> <parameterxsi:type="SimpleParameter" id="xpath"> <parameterValuexsi:type="SimpleValue">//x:observation/x:code [@code=‘<queryxsi:type="ContextValue">patientID</query>'] /../x:value/@value</> </parameter> <parameterxsi:type="SimpleParameter" id="namespaces"> <parameterValuexsi:type="SimpleValue">x=urn:hl7-org:v3</> </parameter> </dataLoader>

  17. CDS-DATOR • Generic Data Loader • Methodology working for developing new data loaders • Problem • Too complex to be used regularly • Solution • Reduce the complexity of the mappings for the most common sources (XML, Web Services, and relational databases.

  18. CDS-DATOR • Xpath Loader • Needs three parameters • Url: define the route of the file • Xpath: the query applied to the XML file • Namespace: used to avoid ambiguities in the query Workflow of the Xpath Loader

  19. CDS-DATOR • Xpath Loader • Example code • <dataLoaderxsi:type="xpath:XPathLoader"> • <xpath:urlxsi:type="URL">file:/C:/patientData.xml</> • <xpath:xpathxsi:type="SimpleValue">//x:observation/x:code[@code='<query xsi:type="ContextValue">patientID</query>']/../x:value/@value</> • <xpath:namespacesxsi:type="SimpleValue">x=urn:hl7-org:v3"</> • </dataLoader>

  20. CDS-DATOR • Web Service Loader • It can be connected to a SOAP or a REST service • The mapping parameters depends on the type of service used • It can be used to retrieve the information at the beginning of the execution Workflow of the Web Service Loader

  21. CDS-DATOR • Web Service Loader • Example code • <dataLoaderxsi:type="web:WebServiceLoader"> • <web:soapService> • <web:wsdlURLxsi:type="URL">http://localhost:9901/PatientHistory?wsdl</> <web:operationNamexsi:type="SimpleValue">getRecord</> • <web:parametersxsi:type="ContextValue">patientID</> • </web:soapService> • </dataLoader>

  22. CDS-DATOR • SQL Loader • Allows to define SQL queries to relational databases • Requires two parameters: • URL: the connection data to the database • SQL: the query that we want to execute (can contain extra mappings) Workflow of the SQL Loader

  23. CDS-DATOR • SQL Loader • Example code • Dynamic query generation • <dataLoaderxsi:type="sql:SQLLoader"> • <sql:connectionxsi:type="URL">jdbc:mysql://localhost/testDB“ </sql:connection> • <sql:sqlxsi:type="SimpleValue">SELECT v.value FROM Patients p, Variables v WHERE p.ID="'<queryxsi:type="ContextValue">patientID</query>'" AND p.Variable="SET" AND v.ID IN (SELECT( p.ID || '_' || p.Variable) FROM Patients);</sql:sql> • </dataLoader>

  24. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  25. CDS-DATOR • How to create mappings • Identify the data needed from the CDSS • Identify the corresponding data sources • Create the corresponding mapping entry • Connecting CDS-DATOR to CDSSs engines • Find the data module from the CDSS • Create a data wrapper (that implements the data loader interface) for the module • Create a wrapper for the engine to override the data queries

  26. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  27. PROforma integration • The PROforma language • Models the clinical knowledge contained in a guideline as a set of tasks and data items • The PROforma engine • Enacts the computer interpretable guideline written in the PROformalanguage • The execution of the guideline can be automatic or step by step • When the guideline needs external data, the engine has to make a request through an enquiry

  28. PROforma integration • PROformaguideline for COPD diagnosis plan

  29. PROforma integration • Problems • The language is limited to the data sources defined internally • The engine requires data to be introduced manually • Solution • Extend the language to add more data sources • Tied to updates and changes in the language (not recommended) • Define an external wrapper independent of the language able to automatize the data collection

  30. PROformaintegration • Definition of the engine wrapper • Task manager extension • Data petitions pass through the CDS-DATOR 1 n PFEngine Taskadapter PFEngine Wrapper CDS-DATOR listener 1 n

  31. PROforma case study

  32. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  33. Curiam – Curiam BT • Curiam is a generic CDSS framework • Generic data and GUI components • Curiameases the inclusion of new predictive models using a generic classification framework[4] • CuriamBT[5,6] is a CDSS for brain tumor diagnosis based on the generic CuriamCDSS • The purpose for this case study is to provide Curiam BT access to the data stored in a generic relational database [4] - [C Sáez, JM García-Gómez, J Vicente, S Tortajada, J Luts, D Dupplaw, SV Huffel, M Robles. A generic and extensible automaticclassificationframeworkapplied to braintumour diagnosis in HealthAgents. TheKnowledgeEngineeringReview 26 (3), 283-301. 2011 ] [5] - [C Sáez, JM García-Gómez, J Vicente, S Tortajada, M Esparza, A Navarro, E Fuster, M Robles. Curiam BT, DecisionSupportSystemforBrainTumour Diagnosis. EuropeanSocietyforMagneticResonance in Medicine and Biology 2009 Congress, Antalya, Turkey, Info-RESO, 2009] [6] - [C Sáez, L Martí-Bonmatí, Á Alberich-Bayarri, M Robles, JM García-Gómez. Randomized pilot study and qualitative evaluation of a clinical decision support system for brain tumour diagnosis based on SV 1H MRS: Evaluation as an additional information procedure for novice radiologists. Computers in Biology and Medicine 45, 26-33. 2014]

  34. Curiam case study • Data flow

  35. Curiam integration Data wrapper that communicates with CDS-DATOR

  36. Curiam case study • The data expected by Curiam BT is a raw signal • Data signals are stored as 512 points arrays in the generic database Patient Variables + CuriamBT Database tables

  37. CDS-DATOR • SQL Loader • <dataLoaderxsi:type="sql:SQLLoader"> • <sql:connectionxsi:type="URL">jdbc:mysql://localhost/testDB“ </sql:connection> • <sql:sqlxsi:type="SimpleValue">SELECT v.value FROM Patients p, Variables v WHERE p.ID="'<queryxsi:type="ContextValue">patientID</query>'" AND p.Variable="SET" AND v.ID IN (SELECT( p.ID || '_' || p.Variable) FROM Patients);</sql:sql> • </dataLoader>

  38. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  39. Data interoperability • Combining PROforma with linkEHR • The mediator doesn’t manage the data at a semantic level • A complete integration between data sources and CDSSs can be achieved combining CDS-DATOR with semantic systems • This mixed functionality was tested in a prototype for the determination of patient eligibility based on clinical data stored in a real-life EHR system[7] • The patient eligibility is determined by a CDSS developed in the PROformalanguage • The mediator provides a data layer that allowed the PROforma engine to access the XML documents generated by the semantic tool LinkEHR. [7][Mar Marcos, José A. Maldonado, Begoña Martínez-Salvador, Diego Boscá, Montserrat Robles. Interoperability of clinical decision-support systems and electronic health records using archetypes: A case study in clinical trial eligibility. Journal of Biomedical Informatics, 46(4):676-689, 2013]

  40. Summary • Previous work • Data integration in CDSSs • CDS-DATOR • Methodology • Data loaders (Generic, Xpath, WebService, SQL) • Mapping definition • Case Studies • PROforma • CURIAM • Data Interoperability • Conclusions

  41. Conclusions • CDS-Dator provides: • Separation between raw and semantic treatment of data • Separation between the CDSS encoding process and the mapping definition • Mappings for common data sources and easy extension to new ones • Data mediation or wrapping with any CDSS with minimal integration effort • Evaluated in three use cases • PROforma engine • Curiam CDSS • PROforma + linkEHR interoperability

  42. Thank you for your attention! Questions?

More Related