Enabling Clinical Data Reuse with openEHR Data Warehouse Environments

Enabling Clinical Data Reuse with openEHR

Data Warehouse Environments

Luis Marco-Ruiz, Pablo Pazos Gutiérrez, Koray Atalag, Johan Gustav Bellika, Kassaye Yitbarek

Yigzaw

2

Agenda1. Background

1.1. Learning Healthcare System1.2. Semantic Interoperability1.3. Linkage EHR – Inference models

2. METL2.1. Modelling2.2. Extract2.3. Transform2.4. Load

3. Experiences3.1. Laboratory Service at University Hospital North Norway3.2. NZ Cardiac Registry3.3. Path based queries

3

Background – Limitations of EBM• Since its inception EBM has improved healthcare

outcomes by “collating studies, setting methodologies and publication standards, developing reasons and courses for technical appraisal and building new knowledge bases to be implemented in routine care”[1]

• However, some factors like the over-influence of industry in clinical research, the overwhelming amount of evidence in a form of scientific papers, the reduction of knowledge to algorithmic rules and the poor adoption to the individual patient needs have raised as EBM limitations

[1] T. Greenhalgh, J. Howick, N. Maskrey, and for the Evidence Based Medicine Renaissance Group, “Evidence based medicine: a movement in crisis?,” BMJ, vol. 348, no. jun13 4, pp. g3725–g3725, 2014.

4

Background – The Learning Healthcare System

•In response to the limitations, the US Institute of medicine (IOM) summarized the pillars needed to overcome them in the proposal of a new healthcare paradigm named the Learning Healthcare System [1]:

– (a) fast progression of knowledge produced in clinical research to its use in routine clinical practice;

– (b) empowerment of a shared responsibility culture; – (c) present the notion of clinical data as a public asset;– (d) empower interoperability with Patient Health Records

(PHR) systems; – (e) facilitate public engagement of patients and doctors.

5

Background – The Learning Healthcare System

•The LHS needs efficient data reuse mechanisms that allow to test hypothesis and confirm effects of interventions.

• Data need to flow from systems where originally were captured (EHRs, journals, LIS etc.) to systems that implement inference models (CDS, data analysis etc. )

• Need to find better mechanisms to improve accessibility and processing of clinical data for reuse

6

Background – Ingredients for data reuse• Semantic Interoperability (SiOp)

– Latest efforts (Europe, US, Brazil, etc.) have established mechanisms to support the adoption of health interoperability standards

– Several standards available: openEHR, HL7 CDA, ISO 13606, FHIR

• Linkage of EHR with inference models– The ‘impedance mismatch’ between the information and inference model

needs to be resolved– Mechanisms are needed to rise the level of abstraction of the fine grained

data in the EHR to the abstract concepts referenced from inference models (medical logic or data analysis)

– Examples: DW, KDOM, Archetype layers, VMR etc.

• Data reuse pipeline infrastructure– An infrastructure must adequately implement the mechanisms to resolve

the impedance mismatch between EHR and inference models. It must ensure that data is appropriately updated, validated and accessible at the end of the pipeline for reuse.

7

Semantic Interoperability

• Integration and harmonization of formats using health information standards– openEHR, HL7 CDA, CIMI, FHIR etc.

• Definition of shared information models and terminology binding– Several national and international initiatives:

Norwegian openEHR CKM, Spanish ISO13606 SOM, International openEHR CKM, CIMI etc.

8

Linkage of EHR with inference models

• The ‘impedance mismatch’ between the information and inference model needs to be resolved

• Mechanisms to rise the level of abstraction of the fine grained data in the EHR to the abstract concepts referenced from inference models (medical logic or data analysis)

• Examples: DW, KDOM, Archetype layers, VMR etc.

9

Linkage of EHR with inference models

SymptomName=coughTime= 6am-7am

Early morning cough

SymptomName=sputumcolor= salmon

Productive Early morning

cough

EH

RIn

fere

nce

If (Productive_early_morning_cough) then recommend X-ray

10

Data reuse pipeline infrastructure• An infrastructure must adequately implement the

mechanisms to resolve the ‘impedance mismatch’ between EHR and inference models

• It must ensure that data is appropriately updated, validated and accessible at the end of the pipeline for reuse

• Transformation from proprietary to EHR standards is the most complex step

• The data model must be generic to ensure that the maximum reuse scenarios are covered

11

ChallengeTo define a infrastructure that appropriately enables:

–To gather proprietary clinical data and transform it into standard compliant canonical form (ensures SiOp)

–To query data referencing standard defined clinical models independently from the underlying technological implementation

–To define different views of the openEHR data for different scenarios

12

Agenda

1. Background1.1. Learning Healthcare System1.2. Semantic Interoperability1.3. Linkage EHR – Inference models


3. Experiences3.1. Laboratory Service at University Hospital North Norway3.2. NZ Cardiac Registry3.3. Path based queries

14

METL

Modelling ExtractTransformLoad

Marco-Ruiz L, Moner D, Maldonado JA, Kolstrup N, Bellika JG,Archetype-based data warehouse environment to enable the reuse of electronic health record data, International Journal of Medical Informatics (2015), http://dx.doi.org/10.1016/j.ijmedinf.2015.05.016

15

MET

L

Adapted from: Marco-Ruiz L, Moner D, Maldonado JA, Kolstrup N, Bellika JG,Archetype-based data warehouse environment to enable the reuse of electronic health record data, International Journal of Medical Informatics (2015), http://dx.doi.org/10.1016/j.ijmedinf.2015.05.016

16

Modelling

CKMClinical Model

Selection

Extension / Adaption

• Archetype reuse must be attempted checking national and international repositories to maximize the reuse of the data structure and queries

• Often CKM archetypes need to be extended to accommodate data reuse requirements (e.g. addition of demographical data*)

• The set of archetypes chosen must guarantee the highest level of reusability

• Archetypes should not be influenced by a particular reuse scenario

• Keep any new or extended Archetypes unconstrained as much as possible (e.g. do not bind value sets or set property units ranges etc.). Constraint at Template level to increase reuse.

• Keep archetypes containing fine grained properties and aggregate using the query languages to accommodate each reuse scenario

* The demographic model is not supported by current tools and demographic properties are modelled with the EHR information model

Set of archetype

s

17

Extract

High level architectures for Extraction to DWExtraction of data in the Snow system

ExtractTraditional DW approach

EHR/Lab systems

data warehouse

In a traditional data warehouse, case data is stored both locally and centralized.

Has privacy / trust / autonomy issue

Decentralized approach

EHR/Lab systems / Health institutions

In a decentralized system, case data stay locally, summarized data can be stored centrally.

Avoids the privacy / trust / autonomy issuesThe Snow system is based on this decentralized approach

EHR /Lab production data

EHR/LAB database

Snow server

Snow exporter

Snow importer

exp

Snow dw

Filter

Automatic Extraction of data from local EHR/Lab systems

Transformation rulesData

Aggregater

Aggregated data---------------

Sample data from LIS system

Data Extraction from microbiology laboratories

TLS

Lab Snow serverPost Office Snow

server

Health networkHospital network

DMZ

XMPP Server Port: 5269

XMPP Client

Port 5222

”Retrieve4"

SSH: 22

Move CSV file

To $snow/data/in directory

Source: Snow dev team. Security policy: Pilot Deployment. Version 0.8. 2009

Snow coordination server

Stores aggregated data used to

produce a regional epidemiology

model

Automating Extraction – The Snow mission scheduler

23See further details in: J. G. Bellika, T. Henriksen, and K. Y. Yigzaw, “The Snow System – A Decentralized Medical Data Processing System,” in Data Mining in Clinical Medicine, vol. 1246, Spinger, 2014.

24

MET

L


25

Archetype-based DW in UNN - Transform<microlabresult> <id>2350459475284566896</id> <registrationDate>2013-02-24T12:56:00+01:00</registrationDate> <analysisDate>2013-02-25T15:35:20+01:00</analysisDate> <resultSentDate>2013-02-25T15:39:30+01:00</resultSentDate> <testRequesterId>68C17EC6</testRequesterId> <analysisName>Nasopharynx-Chlamydophila pneumoniae DNA</analysisName> <analysisType>VNX-CPP</analysisType> <originalTestResult>NEGATIV</originalTestResult> <material>Nasopharynx</material> <requesterMunicipalityCode>1905</requesterMunicipalityCode> <gender>K</gender> <patientMunicipalityCode>1902</patientMunicipalityCode> <patientId>18E8422AD</patientId> <patientBornYear>1972</patientBornYear> </microlabresult><microlabresult> <id>12769G4560JT284563452</id> <registrationDate>2013-02-24T12:56:00+01:00</registrationDate> <analysisDate>2013-02-25T15:35:20+01:00</analysisDate> <resultSentDate>2013-02-25T15:39:30+01:00</resultSentDate> <testRequesterId>68C17EC6</testRequesterId> <analysisName>H1N1 RNA</analysisName> <analysisType>VNX-H1N1</analysisType> <originalTestResult>NEGATIV</originalTestResult> <material>Nasopharynx</material> <requesterMunicipalityCode>1905</requesterMunicipalityCode> <gender>K</gender> <patientMunicipalityCode>1902</patientMunicipalityCode> <patientId>563G5E8443ER</patientId> <patientBornYear>1942</patientBornYear> </microlabresult>


Transform

26

Transform• Data extracted must be transformed into

instances compliant with the archetypes defined in the MODELLING stage

• Constraints defined by the archetype must be kept

• Complex transformation mechanisms are needed

• Transformation from proprietary formats into openEHR compliant data is complex

Transform

27

Transformations often needed when mapping from proprietary formats to openEHR:• Direct mappings

– If (gender==W) -> gender=1; – If (gender==M) -> gender=0;

• New node values inferred from the extracted data– If(infectiousAgent==ROTA-VIRUS)-> diseaseCategory=Gastrointestinal

• Grouping functions– “group all tests by request code; group all requests by patient id”

• Dependent from external sources*– Mappings that depend on external parties information (e.g. terminology servers, public available data)

28

Archetype-based DW in UNN - Transform

<microlabresult> <id>2350459475284566896</id> <registrationDate>2013-02-24T12:56:00+01:00</registrationDate> <analysisDate>2013-02-25T15:35:20+01:00</analysisDate> <resultSentDate>2013-02-25T15:39:30+01:00</resultSentDate> <testRequesterId>68C17EC6</testRequesterId> <analysisName>Nasopharynx-Chlamydophila pneumoniae DNA</analysisName> <analysisType>VNX-CPP</analysisType> <originalTestResult>Test for VNX-CPP was NEGATIV</originalTestResult> <material>Nasopharynx</material> <requesterMunicipalityCode>1905</requesterMunicipalityCode> <gender>K</gender> <patientMunicipalityCode>1902</patientMunicipalityCode> <patientId>18E8422AD</patientId> <patientBornYear>1972</patientBornYear> </microlabresult>


Group fields by

test request

If (Nasopharynx-Chlamydophila

pneumoniae DNA)

Set 10652-6

If (gender=K)

Set gender=W

Transform

Direct mapping examples

29

Canonical model from extraction

openEHR archetye

If (gender==W) gender=1If (gender==M) gender=0


openEHR archetye

If (testId==SOD_PLASM) testId=2951-2If (testId==PAP_RESULT) testId=19764-0

Transformation

New inferred values

30


openEHR archetye

If (infectious_agent==FEC-ROTA)

Symptom_group=‘Gastrointestinal’

<microlabresult> <id>2350459475284566896</id> <registrationDate>2013-02-24T12:56:00+01:00</registrationDate> <analysisDate>2013-02-25T15:35:20+01:00</analysisDate> <resultSentDate>2013-02-25T15:39:30+01:00</resultSentDate> <testRequesterId>68C17EC6</testRequesterId> <analysisName>Rotavirus DNA</analysisName> <analysisType>ROTA-VIRUS</analysisType>

…</microlabresult>


openEHR archetye


sub_category=‘Virus’

Transform

Grouping functions

31

Group fields by

test request

<microlabresult> <id>2350459475284566896</id> <registrationDate>2013-02-24T12:56:00+01:00</registrationDate> <analysisDate>2013-02-25T15:35:20+01:00</analysisDate> <resultSentDate>2013-02-25T15:39:30+01:00</resultSentDate> <testRequesterId>68C17EC6</testRequesterId> <analysisName>Nasopharynx-Chlamydophila pneumoniae DNA</analysisName> <analysisType>VNX-CPP</analysisType> <originalTestResult>NEGATIV</originalTestResult> <material>Nasopharynx</material> <requesterMunicipalityCode>1905</requesterMunicipalityCode> <gender>K</gender> <patientMunicipalityCode>1902</patientMunicipalityCode> <patientId>18E8422AD</patientId> <patientBornYear>1972</patientBornYear> </microlabresult>

32

Extract and Transform techs• Technologies available to extract and transform:– LinkEHR (archetype-based) Transform - Commercial– Pentaho Data Integration (Kettle) ETL - Open Source– Altova Mapforce (Mapping between models) ETL -

Commercial– Informatica - Commercial– …– Ad-hoc solutions (e.g. java + Drools)• Load needs to be ad-hoc: no commercial

openEHR connectors available

33

Load

After transformation, openEHR extracts are interoperable with other openEHR systems

However, appropriate query mechanisms based on archetypes need to guarantee openEHR extracts availability and appropriate response times

Performing transformations on demand would not ensure efficient responses neither allow the appropriate filtering

An openEHR persistence platform needs to be loaded to enable queries

Such platform will allow the retrieval of the standard extracts any time with AQL

34

MET

L


Load

35

AQ

L openEHR persistence platform

Extract server

OpenEHR compliant extract



Other openEHR sources

CDS

Clinical research

Public health

Surveillance

Adapter ( groups different archetypes into the emplates and submits them to the DW

using it’s API )

Transform



36

LoadReconciliation of formats unveils the need a connectathon to test real SiOp

Load processes are long lasting (hours)

Load should be implemented as batch scheduled tasks that do not interfere the query load of the DW

37

LoadIdeally the openEHR EXTRACT IM should be used to encapsulate compositions. This guarantees appropriate version control for data updates

However, the EXTRACT model has not catch on in industrial implementations and direct COMPOSITION serializations are used

Since data sources are not openEHR systems, even with the EXTRACT IM, versioning control would present challenges

Data updates of the DW must be carefully performed

38

Load

The load process can be treated as a global transaction

Global transactions not properly managed may incur in wrong inferences when querying the DW

The control of data validity across the whole pipeline is still an open issue

39

MET

L


40

Query - AQL Section Data to be specified in the sectionSELECT Data elements to be returned and aggregation functions to use

over it

FROM EHR Id of the EHR to be queriedContainment Criteria

Archetype sections that need to be contained in the specified EHR

WHERE Criteria that needs to be applied to the result values in order to be returned

ORDER BY Order criteria to apply to the result setTIME WINDOW Date from which the specified data will be queried ignoring those

older


41

AQL - Query samples


SELECT o/data/events/data/items[at0078.13]/value AS WhiteCellCount FROM EHR[ehr_id=1ADC27]

CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1]

CONTAINS OBSERVATION o [openEHR-EHR- OBSERVATION.lab_test_full_blood_count.v1] WHERE o/data/events/data/items[at0078.13]/value > 11000000000AND o/data/events/data/items[at0078.13]/value < 17000000000 TIME WINDOW P1Y/2014-02-12

42

Advantages

• Modeling capabilities provided by openEHR standards

• Archetype vs. snowflake schema/OLAP cube

• Snowflake schemas or OLAP cubes would replicate modeling already validated by domain experts

• Queries are independent of the underlying infrastructure

43

Limitations

• Limited control over ETL stages. Global transactions need to be implemented.

• Synchronization and version control issues can arise when integrating several sources and deciding which entities need to be updated

• Load not rolled back will lead to wrong inferences

• Rules involving time cannot be easily implemented

44

Limitations• When very complex aggregations

(subquerying, constructs…) are needed AQL may not suffice

• Ontological representations and SPARQL could be an alternative but transformations openEHR - ontologies are very expensive [3,4]

[3] L. Lezcano, M.-A. Sicilia, C. Rodríguez-Solano, Integrating reasoning andclinical archetypes using OWL ontologies and SWRL rules, J. Biomed. Inform.44(April (2)) (2011) 343–353.

[4] J.T. Fernández-Breis, J.A. Maldonado, M. Marcos, M.D.C. Legaz-García, D.Moner, J. Torres-Sospedra, et al., Leveraging electronic healthcare recordstandards and semantic web technologies for the identification of patientcohorts, J. Am. Med. Inf. Assoc. JAMA (August 9) (2013)

45

Agenda



3. Use cases3.1. Laboratory Service at University Hospital North Norway3.2. NZ Cardiac Registry3.3. Path based queries

Use cases

Infectious diseases tests monitoring at University Hospital

of North Norway

• Population information for general practitioners (GPs) is usually limited by the patients they are assigned and their personal communications with colleagues

• They seldom have access to real time population test results or colleagues requests

• Access to anonymized and aggregated population data about laboratory interventions of other colleagues and laboratory personnel can empower their environmental awareness of communicable infectious diseases and help them to determine which set of tests should be ordered

48

Archetype-based DW at UNN - Introduction

• Laboratory test results of a population of 230,000 patients belonging to Troms and Finnmark counties in Norway requested between January 2013 and November 2014 were normalized to openEHR

• Test records normalization has been performed by defining transformation and aggregation functions to automatically generate openEHR compliant data.

• These data were loaded into an archetype-based data warehouse

49


• Indicators linked to the data in the warehouse to monitor test activity of Salmonella and Pertussis were defined with AQL

50

Archetype-based DW in UNN - Introduction

Laboratory test request = patient demographical data + requesters demographical data + tests batteryTest battery= 1..n individual tests to detect an infectious agent

51


Individual testidregistrationDateanalysisDateresultSentDatetestRequesterIdanalysisNameanalysisTypeoriginalTestResultmaterialrequesterMunicipalityCodegenderpatientMunicipalityCodepatientIdpatientBornYear

52


• Reuse was attempted checking the international openEHR CKM

• 2 possible candidates were identified– openEHR-EHR-OBSERVATION.lab _test.v1 – openEHR-EHR-OBSERVATION.lab test-microbiology.v1

• The need of demographical information and fields like infectious agent or symptom group forced the definition of new archetypes

53

Archetype-based DW at UNN - Modelling

Specialize

54

Archetype-based DW at UNN - Modelling


55

Archetype-based DW at UNN - Transformation

<microlabresult> <id>2350459475284566896</id> <registrationDate>2013-02-24T12:56:00+01:00</registrationDate> <analysisDate>2013-02-25T15:35:20+01:00</analysisDate> <resultSentDate>2013-02-25T15:39:30+01:00</resultSentDate> <testRequesterId>68C17EC6</testRequesterId> <analysisName>Nasopharynx-Chlamydophila pneumoniae DNA</analysisName> <analysisType>VNX-CPP</analysisType> <originalTestResult>The test was NEGATIV for VNX-CPP</originalTestResult> <material>Nasopharynx</material> <requesterMunicipalityCode>1905</requesterMunicipalityCode> <gender>K</gender> <patientMunicipalityCode>1902</patientMunicipalityCode> <patientId>18E8422AD</patientId> <patientBornYear>1972</patientBornYear> </microlabresult>


Transform

56

Transformations needed:• Direct mappings

• New node values inferred from the extracted data

• Grouping functions

Archetype-based DW at UNN - Transform

New inferred values

57


openEHR archetye


Symptom_group=‘Gastrointestinal’

<microlabresult> <id>2350459475284566896</id> <registrationDate>2013-02-24T12:56:00+01:00</registrationDate> <analysisDate>2013-02-25T15:35:20+01:00</analysisDate> <resultSentDate>2013-02-25T15:39:30+01:00</resultSentDate> <testRequesterId>68C17EC6</testRequesterId> <analysisName>Rotavirus DNA</analysisName> <analysisType>FEC-ROTA</analysisType>

…</microlabresult>


openEHR archetye


sub_category=‘Virus’


Grouping functions

58

Group fields by

test request

<microlabresult> <id>2350459475284566896</id> <registrationDate>2013-02-24T12:56:00+01:00</registrationDate> <analysisDate>2013-02-25T15:35:20+01:00</analysisDate> <resultSentDate>2013-02-25T15:39:30+01:00</resultSentDate> <testRequesterId>68C17EC6</testRequesterId> <analysisName>Nasopharynx-Chlamydophila pneumoniae DNA</analysisName> <analysisType>VNX-CPP</analysisType> <originalTestResult>The test was NEGATIV for VNX-CPP</originalTestResult> <material>Nasopharynx</material> <requesterMunicipalityCode>1905</requesterMunicipalityCode> <gender>K</gender> <patientMunicipalityCode>1902</patientMunicipalityCode> <patientId>18E8422AD</patientId> <patientBornYear>1972</patientBornYear> </microlabresult>


59

Extraction and caching

Legacy data extracts

Canonical extracts

XQuery transformatio

n script

EHREXE

Archetype

Transformation, Transformation, aggregation and aggregation and mapping rulesmapping rules

Canonical Data schema

References LinkEHR

Feeds Feeds

GeneratesFeeds

Gene

rate

s


Feeds

Compliant with



Transformation

60

## Virus:# Sets the infectious agent based on the letters after the '-' in analysisType. This is implemented in a Java class.#rule "Gastrointestinal symptoms related to virus"

no-loop true salience 1when

dataModel : SampleData (analysisType == "FEC-ROTA" || analysisType == "FEC-ADNO" || analysisType == "FEC-NORO"|| analysisType == "OPP-NORO" || analysisType == "FEC-SAPO" || analysisType == "OPP-SAPO")

thendataModel.setSymptomGroup(SymptomGroup.GASTROINTESTINAL.getName());dataModel.setSubCategory("Virus");dataModel.setInfectiousAgentFromAnalysisTypeAddVirus();update(dataModel);

end

(/microlabresultscollection/microlabresult/analysisType = "FEC-ROTA") OR (/microlabresultscollection/microlabresult/analysisType = "FEC-ADNO") OR (/microlabresultscollection/microlabresult/analysisType = "FEC-NORO") OR (/microlabresultscollection/microlabresult/analysisType = "OPP-NORO") OR (/microlabresultscollection/microlabresult/analysisType = "FEC-SAPO") OR (/microlabresultscollection/microlabresult/analysisType = "OPP-SAPO")

Condition Mapping function

"Gastrointestinalt"

Drools rule

LinkEHR mapping

Target archetype attribute

Simple test Symptom group Value


Simple test Subcategory Value

"Virus"


Simple test Infectious agent Value

@concat(@substring-after(/microlabresultscollection/microlabresult/analysisType,"-"),"virus")

Mar

co-R

uiz

L, M

oner

D, M

aldo

nado

JA

, Kol

stru

p N

, Bel

lika

JG,

Arc

hety

pe-b

ased

dat

a w

areh

ouse

env

ironm

ent t

o en

able

the

reus

e of

el

ectro

nic

heal

th re

cord

dat

a, In

tern

atio

nal J

ourn

al o

f Med

ical

Info

rmat

ics

(201

5), h

ttp://

dx.d

oi.o

rg/1

0.10

16/j.

ijmed

inf.2

015.

05.0

16

61


TransformArchetyp

e

Archetype-based DW at UNN - Load

62

Archetype-based DW at UNN - Load• Load was performed sequentially for each patient calling the extracts service from the Transform

stage

• The extracts where simple COMPOSITION serializations. The EXTRACT IM has not been used

• Some differences between the seriations from the Transformation stage and the serializations accepted by the DW were found (namespaces, message wrapping…)

• Format reconciliation was needed

• The openEHR project Connectathon should guarantee openEHR tooling to interoperate seamlessly

• We defined several indicators to monitor infectious diseases (salmonella and pertussis)

63

Archetype-based DW at UNN - Query

• After loading the DW we were able to query data creating different data sets for different scenarios

• As use case we defined several indicators to monitor infectious diseases (salmonella and pertussis)

64

Archetype-based DW at UNN


65

SELECT count(o1/data[at0001]/events[at0002]/data[at0003]/items[at0022]) - - count (patientId)

FROM EHR e

CONTAINS COMPOSITION c

CONTAINS (OBSERVATION o1[openEHR-EHR-OBSERVATION.micro_lab_test.v1])

WHERE (o1/data[at0001]/events[at0002]/data[at0003]/items[at0010]/items[at0043]/items[at0036]/value='Kikhoste‘ and

o1/data[at0001]/events[at0002]/data[at0003]/items[at0010]/items[at0043]/items[at0037]/value='Positiv')

and o1/data[at0001]/events[at0002]/data[at0003]/items[at0024]/value >= '2013-01-04'

and o1/data[at0001]/events[at0002]/data[at0003]/items[at0024]/value < '2013-01-05'


AQL 1: Count positive tests of Pertussis for the day specified in the parameter

AQL 2: Salmonella cases in the specified municipality (same as patient just confirmed) in the first 2 weeks of January

SELECT count(o1/data[at0001]/events[at0002]/data[at0003]/items[at0022]/value) - - count (patientId)

FROM EHR e

CONTAINS COMPOSITION c

CONTAINS (OBSERVATION o1[openEHR-EHR-OBSERVATION.micro_lab_test.v1] and OBSERVATION o2[openEHR-EHR-OBSERVATION.micro_lab_test.v1])

WHERE (o1/data[at0001]/events[at0002]/data[at0003]/items[at0010]/items[at0043]/items[at0036]/value='Salmonella‘ and

o1/data[at0001]/events[at0002]/data[at0003]/items[at0010]/items[at0043]/items[at0037]/value='Positiv')

and o1/data[at0001]/events[at0002]/data[at0003]/items[at0020]/value='1917'

and o1/data[at0001]/events[at0002]/data[at0003]/items[at0024]/value >= '2013-01-01'

and o1/data[at0001]/events[at0002]/data[at0003]/items[at0024]/value < '2013-01-15'

Archetype-based DW at UNN

66

Archetype-based DW at UNNWork available at:


Special thanks to:This work was supported by Helse Nord [grant HST1121-13 and 9057/HST1120-13]; the NILS Science and Sustainability Programme [grant number 005-ABEL-IM-2013] from Iceland, Liechtenstein and Norway through the EEA Financial Mechanism, operated by Universidad Complutense de Madrid; and by the Spanish Ministry of Economy and Competitiveness [grant PTQ-12-05620]. We would like to thank to Marand d.o.o. and Torje S. Henriksen for the products provided and their assistance and support during this work. We would like to acknowledge Gunnar Skov Simonsen and Marit Wiklund at the microbiology laboratory service of the University Hospital of North Norway for their supportfor this work.

Recent developments and future plans

• Additional microbiology labs have joined Snow• Complete coverage of Northern Norway• Soon partly coverage of whole Norway • Tasks involved in setting up a new laboratory:

– Establishing network connection– Setting up a physical / virtual Snow Server– Defining laboratory analysis code mapping rules– Initiating data extracts– Defining data import transformations– Setting up Snow data consumption missions for epidemiology

model generation– Preparing visualisation of epidemiology model data

67

Future plans – distributed analysis of OpenEHR data using secure multiparty

computations

27.05.15

More details available in: •M. A. Hailemichael, L. Marco-Ruiz, and J. G. Bellika, “Privacy-preserving Statistical Query and Processing on Distributed OpenEHR Data,” Stud Health Technol Inform, vol. 210, pp. 766–770, 2015. •Meskerem Asfaw Hailemichael, Kassaye Yitbarek Yigzaw, Johan Gustav Bellika (2015). Emnet: a System for Privacy-Preserving Statistical Computing on Distributed Health Data, SHI 2015, Proceedings from The 13th Scandinavien Conference on Health Informatics, June 15–17, 2015, Tromsø, Norway http://www.ep.liu.se/ecp_article/index.en.aspx?issue=115;article=006

69

• A two-phase solution1. Dataset creation2. Statistical computation

http://www.ep.liu.se/ecp_article/index.en.aspx?issue=115;article=006

27.05.15 70

OpenEHR in Norway• The current strategic plan of Norwegian

Health authorities is encouraging EHR vendors to adopt openEHR1

– DIPS ASA, which is the provider of more than 70% of hospital EHRs in Norway, is using OpenEHR2

• Norwegian CKM

1 Ellingsen G, Christensen B, Silsand L. Developing Large-scale Electronic Patient Records Conforming to the openEHR Architecture. Procedia Technology. 2014;16:1281–6.“

2 http://www.dips.no/eng/about-us/customers?lang=eng

Dataset creation

27.05.15 71

openEHR Data1

openEHR Data2

Researcher

Hospital 1

Hospital 2

Hospital 3Coordinator

AQL AQLAQL

AQL

The EHRs are OpenEHR based

openEHR Data3

Web-klient

72

Statistical computation

27.05.15 73

Hospital1

Hospital2

Hospital3

Researcher Coordinator

Query QueryQuery

Query

ResultResult Secure multi-party

computation (SMC)

Architecture

75

coordinator

Relevant publications• L. Marco-Ruiz, D. Moner, J. A. Maldonado, N. Kolstrup, and J. G. Bellika, “Archetype-based

data warehouse environment to enable the reuse of electronic health record data,” International Journal of Medical Informatics, vol. 84, no. 9, pp. 702–714, Sep. 2015.

• J. G. Bellika, T. Henriksen, and K. Y. Yigzaw, “The Snow System – A Decentralized Medical Data Processing System,” in Data Mining in Clinical Medicine, vol. 1246, Spinger, 2014.

• M. A. Hailemichael, L. Marco-Ruiz, and J. G. Bellika, “Privacy-preserving Statistical Query and Processing on Distributed OpenEHR Data,” Stud Health Technol Inform, vol. 210, pp. 766–770, 2015.

• Meskerem Asfaw Hailemichael, Kassaye Yitbarek Yigzaw, Johan Gustav Bellika (2015). Emnet: a System for Privacy-Preserving Statistical Computing on Distributed Health Data, SHI 2015, Proceedings from The 13th Scandinavien Conference on Health Informatics, June 15–17, 2015, Tromsø, Norway http://www.ep.liu.se/ecp_article/index.en.aspx?issue=115;article=006 (accessed 8/18/2015)

• J. G. Bellika, T. Hasvold, and G. Hartvigsen, “Propagation of program control: a tool for distributed disease surveillance,” Int J Med Inform, vol. 76, no. 4, pp. 313–29, 2007.

• J. G. Bellika, H. Sue, L. Bird, A. Goodchild, T. Hasvold, and G. Hartvigsen, “Properties of a federated epidemiology query system,” Int J Med Inform, vol. 76, no. 9, pp. 664–76, 2007.

76

http://www.ep.liu.se/ecp_article/index.en.aspx?issue=115;article=006

77

Agenda




ANZACS-QI* openEHR Modelling for

DatawarehousingKoray AtalagJane Farris

*All NZ Acute Coronary Syndrome Quality Improvement programme

National clinical registry for acute coronary syndrome (ACS) events and cardiac procedures

ANZACS-QI Wiki: Created by Johan Strydom – Aug 2014

Current Architecture

Current Situation• Flat files transferred from Enigma• Heavily dependent on Data Dictionary

for meaning (Word & Excel files)• No view ‘across’ datasets• Requirement for extensive clinical input

for report development and on-going support

Future State

What is a Content Model?• IT IS A REFERENCE LIBRARY - for enabling

consistency in HIE Payload• Superset of all clinical dataset definitions

– normalised using a standard EHR record organisation (openEHR)

– Expressed as reusable and computable models – Archetypes

• Top level organisation follows CCR• Further detail provided by:

– Existing relevant sources (CCDA, Nehta, epSoS, HL7 FHIR etc.)

– Extensions (of above) and new Archetypes (NZ specific)• Each HIE payload (CDA) will correspond to a subset

(and conform)

Usage of the Content Model

Exploiting Content Model for Secondary Use

Single Content Model

CDA

FHIR

HL7 v2/3

EHR Extract

UML

XSD/XMI

PDF

Mindmap

PAYLOAD

System A

Data Source A

MapTo

Content Model

System B

Data Source B

Native openEHR Repository

Secondary Use

MapTo

Content Model

Automated Transforms

No Mapping

Atalag K. Using a single content model for eHealth interoperability and secondary use. Stud Health Technol Inform. 2013;193:282–96

A Canonical Model using National Standards

ACS Cathlab

Device (PCI)

Content Model Subject Areas – Health Information Exchange Content Model Architecture Building Block – HISO 10040.2

View of the EHRFrom an ACS viewpoint

Overview of ANZACS-QI Models

Benefits• Single point of reference

– Faithful representation of the ‘forms’– Standards based

• Extensible• Flexible• Reusable

– Clear and unambiguous data definition– Enables single source metadata management

• Data Dictionary• Rules within and between forms• Rules to other data sources (e.g. Linking datasets)

– Export for reuse– Holds the clinical viewpoint – ACS part of the

EHR

Future: Shared Health Information Platform (SHIP)

90

Agenda




Path-based queries in action

Test available in EHRServerhttps://cabolabs-ehrserver.rhcloud.com/ehr-0.3/query/list

EHRServer Query Builder

Path-based queries in action

{ "uid": "9c5da334-4b81-4d60-92e2-aa96a722b4ac", "name": "Documents with high BP", "format": "xml", "type": "composition", "criteriaLogic": "OR", "criteria": [ { "archetypeId": "openEHR-EHR-OBSERVATION.blood_pressure.v1", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value", "conditions": { "magnitude": { "gt": [ 140 ] }, "units": { "eq": "mm[Hg]" } } }, { "archetypeId": "openEHR-EHR-OBSERVATION.blood_pressure.v1", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value", "conditions": { "magnitude": { "gt": [ 90 ] }, "units": { "eq": "mm[Hg]" } } } ]}

Path-based: + Get clinical documents (compositions) + With high BP

JSON expression of EHRServer

queries

Path-based queries in actionResults: + in XML (or JSON if specified on the query or as a parameter) + just the index, no data, can get a specific document using the index

<?xml version="1.0" encoding="UTF-8"?><list> <compositionIndex id="8"> <archetypeId>openEHR-EHR-COMPOSITION.signos.v1</archetypeId> <category>event</category> <dataIndexed>true</dataIndexed> <ehrId>11111111-1111-1111-1111-111111111111</ehrId> <lastVersion>true</lastVersion> <startTime>2015-08-14 03:06:44.0 EDT</startTime> <subjectId>11111111-1111-1111-1111-111111111111</subjectId> <templateId>Signos</templateId> <uid>e152b2c2-7dbe-44b6-9ec6-2cd698561140</uid> </compositionIndex> <compositionIndex id="9"> <archetypeId>openEHR-EHR-COMPOSITION.signos.v1</archetypeId> <category>event</category> <dataIndexed>true</dataIndexed> <ehrId>11111111-1111-1111-1111-111111111111</ehrId> <lastVersion>true</lastVersion> <startTime>2015-08-14 03:07:06.0 EDT</startTime> <subjectId>11111111-1111-1111-1111-111111111111</subjectId> <templateId>Signos</templateId> <uid>f0a8d192-0f68-4501-8373-f954a47a7385</uid> </compositionIndex> ... </list>

Path-based queries in action{ "uid": "70764d85-4e4b-4548-8f71-3a294f35e704", "name": "Vital Signs", "format": "json", "type": "datavalue", "group": "path", "projections": [ { "archetypeId": "openEHR-EHR-OBSERVATION.blood_pressure.v1", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.blood_pressure.v1", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.body_temperature.v1", "path": "/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.body_weight.v1", "path": "/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.pulse.v1", "path": "/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.respiration.v1", "path": "/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value" } ] }

Path-based: + Get clinical data for all vital signs measures + Result in JSON format, grouped by path (type of data)

JSON expression of EHRServer

queries

Q & A

Contact:Luis Marco [email protected] Pazos [email protected],

Koray Atalag [email protected], Johan G. Bellika [email protected],

Kassaye Y. Yigzaw [email protected]

Enabling Clinical Data Reuse with openEHR Data Warehouse Environments

Healthcare

Transcript of Enabling Clinical Data Reuse with openEHR Data Warehouse Environments