a lightweight and generic data mediating architecture for decision support systems alfonso pérez...

A Lightweight and Generic Data Mediating Architecture for Decision Support Systems

Alfonso Pé[email protected]

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

Summary

• Previous work• Data integration in CDSSs• CDS-DATOR– Methodology– Data loaders (Generic, Xpath, WebService, SQL)– Mapping definition

• Case Studies– PROforma– CURIAM– Data Interoperability

• Conclusions2

Summary



• Conclusions3

CDSS Interoperability

[1] - [C Sáez, JM García-Gómez, J Vicente, S Tortajada, M Esparza, AT Navarro, E Fuster, M Robles. A generic decision support system featuring an assembled view of predictive models for magnetic resonance and clinical data. European Society for Magnetic Resonance in Medicine and Biology 2008 Congress, Valencia, Info-RESO, 2008]

• Curiam CDSS[1]

– Generic CDSS for clinical and biomedical environments

– Connects to databases through a generic data framework

CDSS semantic interoperability:HL7-CDA Wrapper

5

CDA_input.xml

rules_file.clpbinding_file.xml

CDA_output.xml

CDSS Semantic Interpreter Inference engine (e.g., Jess, Drools)

<datadef name="height" code="248333004" codeSystem="2.16.840.1.113883.6.96"> <value xsi:type="PQ" unit="cm"/></datadef>

?BMI setValue (/ ?weight (* (/ ?height 100) (/ ?height 100))))

<entry> <observation classCode="OBS" moodCode="EVN"> <code code="248333004" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName=“Standing height"/> <value xsi:type="PQ" value="186" unit="cm"/> </observation></entry>

<value xsi:type="CV" code="OBJ-X-IMC0" codeSystem="0.0.0.0.0.1.2.1.5.5“displayName=“BMI above objective."/>

human/machine interpretable

human-maintainable

• Use of standardized clinical documents (i.e. HL7-CDA) as input/output of CDSS[2]

[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]

HL7-CDA template input/output

Proforma data collection

6

PROforma Engine

PROforma Engine wrapper

guideline.pf dataconfig.xml

DB XML (HL7-CDA, EN-13606,…)

ab

bc

• Transparent extension of the PROforma engine to permit automatic data collection from different sources[3]

CDSS

[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]

Summary



• Conclusions7

Data integration in CDSSs

8

• 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

Data integration in CDSSs

9

• 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

Summary



• Conclusions10

CDS-DATOR

• CDS-DATOR connectivity schema– Offers different

functionalities depending on the situation in the data flow

11

CDS-DATOR

12

• 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

CDS-DATOR

13

• Data types

Summary



• Conclusions14

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

15UML Schema of the Generic Loader

CDS-DATOR

• Generic Data Loader– Example code (Xpath Loader)

16

<dataLoader xsi:type="GenericDataLoader"> <loaderURI>es.upv.ibime.bmg.cdsdc.xpathloader.XPathDataLoader</loaderURI>

<parameter xsi:type="SimpleParameter" id="url"> <parameterValue xsi:type="URL">C:/patientData.xml</>

</parameter> <parameter xsi:type="SimpleParameter" id="xpath">

<parameterValue xsi:type="SimpleValue">//x:observation/x:code[@code=‘<query xsi:type="ContextValue">patientID</query>'] /../x:value/@value</>

</parameter> <parameter xsi:type="SimpleParameter" id="namespaces">

<parameterValue xsi:type="SimpleValue">x=urn:hl7-org:v3</> </parameter>

</dataLoader>

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.

17

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

18

Workflow of the Xpath Loader

CDS-DATOR

• Xpath Loader– Example code

19

<dataLoader xsi:type="xpath:XPathLoader"><xpath:url xsi:type="URL">file:/C:/patientData.xml</><xpath:xpath xsi:type="SimpleValue">//x:observation/x:code[@code='<query

xsi:type="ContextValue">patientID</query>']/../x:value/@value</><xpath:namespaces xsi:type="SimpleValue">x=urn:hl7-org:v3"</>

</dataLoader>

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

20

Workflow of the Web Service Loader

CDS-DATOR

• Web Service Loader– Example code

21

<dataLoader xsi:type="web:WebServiceLoader"> <web:soapService>

<web:wsdlURL xsi:type="URL">http://localhost:9901/PatientHistory?wsdl</> <web:operationName xsi:type="SimpleValue">getRecord</>

<web:parameters xsi:type="ContextValue">patientID</> </web:soapService> </dataLoader>

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)

22

Workflow of the SQL Loader

CDS-DATOR

• SQL Loader– Example code• Dynamic query generation

23

<dataLoader xsi:type="sql:SQLLoader"><sql:connection xsi:type="URL">jdbc:mysql://localhost/testDB“ </sql:connection> <sql:sql xsi:type="SimpleValue">SELECT v.value FROM Patients p, Variables v WHERE p.ID="'<query xsi:type="ContextValue">patientID</query>'" AND p.Variable="SET" AND v.ID IN (SELECT( p.ID || '_' || p.Variable) FROM Patients);</sql:sql>

</dataLoader>

Summary



• Conclusions24

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

queries25

Summary



• Conclusions26

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 PROforma language– 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

27

28


• PROforma guideline for COPD diagnosis plan


• 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

29


• Definition of the engine wrapper

• Task manager extension

• Data petitions pass through the CDS-DATOR

30

PFEngine

PFEngineWrapper

Task adapter

CDS-DATORlistener

n

n

1

1

PROforma case study

31

Summary



• Conclusions32

Curiam – Curiam BT

• Curiam is a generic CDSS framework – Generic data and GUI components– Curiam eases the inclusion of new predictive models using

a generic classification framework[4]

• Curiam BT[5,6] is a CDSS for brain tumor diagnosis based on the generic Curiam CDSS

• 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 automatic classification framework applied to brain tumour diagnosis in HealthAgents. The Knowledge Engineering Review 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, Decision Support System for Brain Tumour Diagnosis. European Society for Magnetic Resonance 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]

Curiam case study

• Data flow

34

Curiam integration

35

Data wrapper that communicates

with CDS-DATOR

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

36

ID Variable1 STE1 LTE3 LTE4 STE

ID Value1_STE 6868982712…1_LTE 9834765982…3_LTE 2983746584…4_STE 2384756938…

Patient Variables

+

CuriamBT Database tables

CDS-DATOR

• SQL Loader

37

<dataLoader xsi:type="sql:SQLLoader"><sql:connection xsi:type="URL">jdbc:mysql://localhost/testDB“ </sql:connection> <sql:sql xsi:type="SimpleValue">SELECT v.value FROM Patients p, Variables v WHERE p.ID="'<query xsi:type="ContextValue">patientID</query>'" AND p.Variable="SET" AND v.ID IN (SELECT( p.ID || '_' || p.Variable) FROM Patients);</sql:sql>

</dataLoader>

Summary



• Conclusions38

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 PROforma language

• 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]

Summary



• Conclusions40

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

Thank you for your attention!

Questions?

a lightweight and generic data mediating architecture for decision support systems alfonso pérez...

Documents