Transcript openEHR is very flexible

Tutorial - Design and
Implementation of Clinical
Databases with openEHR
Pablo Pazos Gutiérrez, Koray Atalag, Luis MarcoRuiz, Erik Sundvall, Sérgio Miranda Freire
Foundations
• Modern Clinical Databases need to ...
–
–
–
–
handle many types of information,
lost of different data structures,
be flexible and generic,
consistent, standardized, future-proof (evolution)
• CDBs are difficult to design!
– design is 10% about storing data, 90% about querying, retieve and using data
• To achieve a good design we need to have:
– deep knowledge of clinical record structures
– apply good practices, standards and support generic requirements
– knowledge about different technologies / solutions
2
Agenda
•
•
•
•
Clinical Information Requirements
Clinical Information Organization
Database Technologies & Features
openEHR
– goals, information model, knowledge model, data store &
query, versioning & audit
• openEHR Data Storage Techniques
– Relational + ORM
– Hybrid
• Data Querying
3
Clinical Information Requirements
Storing & Accessing Data
Minimal Information Set (ISO 18308)
• Related to storage: from the user point of view
–
–
–
–
–
–
–
–
–
–
–
–
Patient history
Physical examination
Psychological, social, environmental, family and self care information
Allergies and other therapeutic precautions
Preventative and wellness measures such as vaccinations and lifestyle interventions
Diagnostic tests and therapeutic interventions such as medications and procedures
Clinical observations, interpretations, decisions and clinical reasoning
Requests/Orders for further investigations, treatments or discharge
Problems, diagnoses, issues, conditions, preferences and expectations
Healthcare plans, health and functional status, and health summaries
Disclosures and consents
Suppliers, model and manufacturer of devices (e.g. implants or prostheses)
• Internally we want more generic information elements
– especially on our database designs
5
Several ways of accessing clinical data
• Related to clinical data querying for clinical usage (patient level):
– Chronological (e.g. to sort medical consultations)
– Problem-Oriented (access data by condition or disease)
• Health records are associated to a health problem
• Each problem evolves until it is solved/inactivated if it is not chronic
– By medical specialty (e.g. cardiology)
– By department, sector, unit or service (e.g. emergency, ICU, ...)
– Episode
• One or many contacts / visits on different dates
• May include hospitalizations
• Associated with a health problem (e.g. asthma attack)
– Access to individual documents or data points
• e.g. all the blood pressure measures for a patient
• There is also Public Health and Epidemiology (population level)
– we had a tutorial about that yesterday: “Enabling Clinical Data Reuse with
openEHR Data Warehouse Environments”
6
Infrastructure Requirements
• Related to user experience and quality
– Be aware of the CAP theorem!
• Scalability (grow maintaining service level)
• High availability (% operational time)
• Transactionality (all or nothing)
–
–
–
–
–
–
Performance (run forest, run!)
Concurrency (we all want that resource)
Audit (what, when, who, where, why, ...)
Encryption (data at rest)
Version management (history of changes)
...
• We want all!
– We might need to use different technologies
7
Agenda
•
•
•
•
Clinical Information Requirements
Clinical Information Organization
Database Technologies & Features
openEHR
– goals, information model, knowledge model, data store &
query, versioning & audit
• openEHR Data Storage Techniques
– Relational + ORM
– Hybrid
• Data Querying
8
Clinical Information Organization
Clinical records & information are highly hierarchical
paper based or electronic
9
Clinical Information Organization
Clinical records & information are highly hierarchical
10
Agenda
•
•
•
•
Clinical Information Requirements
Clinical Information Organization
Database Technologies & Features
openEHR
– goals, information model, knowledge model, data store &
query, versioning & audit
• openEHR Data Storage Techniques
– Relational + ORM
– Hybrid
• Data Querying
11
DBs for different kinds of usage
• operative / transactional databases (OLTP)
– read/write oriented
– support business processes, small historical data
• querying databases
– read oriented
– read-only data, might be in memory
• document database
– audit, versioning, electronic signature (authenticity, incorruptibility)
• analysis database
– read oriented
– might need ETL
– data linking + data mining + statistical analysis + prediction techniques (trends)
• datawarehouse database
– ETL from many data sources
– batch calculations of indicators over loads of historical data
12
Databases and Data Structures
DBMS
Relational
XML
JSON
Key/Value
Graph
MySQL
native
partial
in development
can be modeled
can be modeled
Postgres
native
complete
complete
hstore extension
hstore extension
Oracle
native
complete
complete
NoSQL edition
NoSQL edition
SQLServer
native
complete
in development
can be modeled
can be modeled
eXistDB
no
native
output
map
map
MongoDB
no
no
native
JSON
JSON
CouchDB /
Couchbase
no
no
native
JSON
JSON
Neo4j
can be modeled
can be modeled
can be modeled
can be modeled
native
Riak
no
no
store and get
native
no
13
Which to choose?
relational, documental, key/value,
graph, object, ..., and which brand?
Consider
many use cases can be met efficiently
by relational databases, but each project is different,
and there is no one-fits-all solution
We are not worried about performance just yet, we’ll focus on
how to design Clinical Databases with openEHR first!
First approach
• The choice depends on the context
– use cases, estimated # of operations / # of records, organizational knowledge, ...
• For the operative / transactional DB lets go with a relational database:
– MySQL, Postgres, Oracle, SQLServer, …
– NOT a recommendation: just focusing on one option to understand some
common clinical database design concepts applicable on other technologies.
16
First approach
• Loads of reads? Complex queries and JOINs? Low performance?
– try relational for writes + documental for reads
• Needs ETL: relational => doc (JSON,XML)
–
–
–
–
you can denormalize the relational DB, and/or
use documental capabilities of some RDBs (e.g. Postgres supports XML & JSON)
made good use of indexes
analyze query plans (Posrgres / MySQL EXPLAIN query)
• Most systems wont have problems with any of these options
– there is always a way to optimize things!
17
Also, we have transformations between models
• When we need to
– migrate to another technology (e.g. from RDBs to Doc)
– integrate different technologies (hybrid solution)
18
We can: XML (canonical xform) JSON
<data xsi:type="COMPOSITION" archetype_node_id="openEHR-EHRCOMPOSITION.signos.v1">
<name>
<value>Signos vitales</value>
</name>
<archetype_details>
<archetype_id>
<value>openEHR-EHR-COMPOSITION.signos.v1</value>
</archetype_id>
<template_id>
<value>Signos-Vitales</value>
</template_id>
<rm_version>1.0.2</rm_version>
</archetype_details>
<language>
<terminology_id>
<value>ISO_639-1</value>
</terminology_id>
<code_string>es</code_string>
</language>
<territory>
<terminology_id>
<value>ISO_3166-1</value>
</terminology_id>
<code_string>UY</code_string>
</territory>
<category>
...
</category>
...
</data>
{
"data": {
"@xsi:type": "COMPOSITION",
"@archetype_node_id": "openEHR-EHR-COMPOSITION.signos.v1",
"name": {
"value": "Signos vitales"
},
"archetype_details": {
"archetype_id": {
"value": "openEHR-EHR-COMPOSITION.signos.v1"
},
"template_id": {
"value": "Signos-Vitales"
},
"rm_version": "1.0.2"
},
"language": {
"terminology_id": {
"value": "ISO_639-1"
}
},
"territory": {
"terminology_id": {
"value": "ISO_3166-1"
}
},
"category": {
...
}
}
openEHR XML
JSON equivalent
}
19
Non-RDB-based approaches?
• XML: BaseX, Sedna, eXist, ...
• JSON: Couchbase, CouchDB, MongoDB, ...
• Often suitable if your client side GUI primarily wants XML or JSON
documents/chunks (avoids conversion needs)
…or if you go all-in-javascript on server+client?
• Auto-translating AQL to hierarchy-friendly query languages (e.g. Xquery, N1QL,
Sparql, SQL++?) is often straightforward.
– Consider using a parser generator.
• XML databases fast for transactional (clinical?), but often slow for population-wide
(epidemiology?) queries.
• Solutions such as Couchbase can be very fast for both, after specific indexing is done
(example on next slide).
• Very little is published regarding graph/network databases (Neo4J etc) and object
databases for openEHR usage.
Please test and publish!
20
Scaling? Size & Performance tests, 4.2M patients
Size in GB
Type
Databases
sus42k
sus420k
sus4200k
0.09
0.43
3.6
XML files
1.38
13.8
137.9
JSON files
0.83
8.3
82.9
BaseX
1.2
11.9
-
eXist
3.3
-
-
Berkeley
3.8
-
-
MySQL
RDB
reference
XML DB
JSON DB Couchbase 0.21
2.1
21
Please note:
•All DBs work fine/fast for ”clinical” patient-specific queries, the graph shows population-queries
•the RDB, here used as source and reference, is an epidemiology-optimised non-openEHR-based
reference that we try to match in end-user speed (not size). The XML/JSON based DB-examples have the
flexibility of openEHR to add new archetypes etc. without manually reworking the DB schema etc, the
RDMBs reference example does not have that flexibility.
Source: Yet unpublished results, working title: Comparing the Performance of NoSQL Approaches for Storing and Retrieving Archetype-Based
Electronic Health Record Data. Authors: Sergio M Freire, Douglas Teodoro, Fang Wei-Kleiner, Erik Sundvall, Daniel Karlsson, Patrick Lambrix
More about the test data and some of the setup is already published in http://www.ep.liu.se/ecp/070/009/ecp1270009.pdf
21
Agenda
•
•
•
•
Clinical Information Requirements
Clinical Information Organization
Database Technologies & Features
openEHR
– goals, information model, knowledge model, data store &
query, versioning & audit
• openEHR Data Storage Techniques
– Relational + ORM
– Hybrid
• Data Querying
22
• Open Standard to create really flexible, future-proof (maintainable in the long term
at large scale with low cost), interoperable EHRs.
– Defines an Infostructure!
• Created, maintained, tested, validated and implemented by an international
community of professionals.
• The community provides Modeling Tools and Open Source Reference
Implementations in many technologies (Java, Eiffel, .Net, Ruby, Python).
• Key elements:
– technological independence
– multi-level models, clean and complete
• information, clinical concepts, terminology bindings, querying, services, ...
– formal methodology for knowledge management
– open & free access to specifications
• a-la W3C / IETF (enabled the implementation of the Internet and the Web)
• Please join us!
– openEHR Foundation:
• http://openehr.org/community/mailinglists
– openEHR en español:
• http://openehr.org.es
23
Information Model
Our Clincal DB Design will be based on this!
Information Model
Clinical records & information are highly hierarchical
25
Record Entries
Different types of entries a clinical document can have
Clinical records are highly hierarchical!
26
Data Types (simplified)
27
Demographic Model
28
Specifying Clinical Records:
Key Points for Clinical Database Design for openEHR data
30
Archetypes & ADL
• Represent clinical concepts by constraints over a generic Information Model
– defined in Archetype Definition Language
– globally valid, multi-language
• Important elements for DB design and implementation!
– multi-axial identifier
• openEHR-EHR-OBSERVATION.blood_pressure.v1
– node identifier
• atNNNN
– node path (e.g. path to systolic BP)
• /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
• archetype id + path
– unique semantic identifier
– will use them in our databases!
• Need archetypes, no problem: http://ckm.openehr.org/
31
Operational Templates (OPT)
• "Big archetypes"
– Combine archetypes to represent clinical documents
– Allows to add more constraints
– Defined in XML
• Use for specific contexts
– one language
– locally valid (organization, federation, national)
• Used by EHR/EMR software directly
–
–
–
–
–
for validating data
for generating UIs
for indexing data
for querying
…
32
Operational Templates (OPT)
<template_id>
<value>Consulta Médica</value>
</template_id>
<definition>
<rm_type_name>COMPOSITION</rm_type_name>
...
<node_id>at0000</node_id>
<attributes xsi:type="C_SINGLE_ATTRIBUTE">
<rm_attribute_name>category</rm_attribute_name>
...
<children xsi:type="C_COMPLEX_OBJECT">
<rm_type_name>DV_CODED_TEXT</rm_type_name>
...
<attributes xsi:type="C_SINGLE_ATTRIBUTE">
<rm_attribute_name>defining_code</rm_attribute_name>
...
<children xsi:type="C_CODE_PHRASE">
<rm_type_name>CODE_PHRASE</rm_type_name>
...
<terminology_id>
<value>openehr</value>
</terminology_id>
<code_list>433</code_list> -- category = event
</children>
</attributes>
</children>
</attributes>
...
openEHR IM
class
openEHR IM
attribute
33
Information & Metadata
References to
Archetypes and
Templates
(semantic content
definitions)
• Link between Archetypes and the Information Model
– Will use those fields in our persistence model
– Are important for queries!
34
Agenda
•
•
•
•
Clinical Information Requirements
Clinical Information Organization
Database Technologies & Features
openEHR
– goals, information model, knowledge model, data store &
query, versioning & audit
• openEHR Data Storage Techniques
– Relational + ORM
– Hybrid
• Data Querying
35
Clinical Data Storage Design
openEHR Data Storage Design
• openEHR doesn't define how to store data
– The IM is not a Persistence Model
– The Persistence Model will depend on requirements and technologies
• Our work is to adapt the IM to our persistence needs
• We can simplify, adapt or use part of it (openEHR is very flexible)
– openEHR doesn't care about how we store data but does care about:
• structural and semantic consistency (defined by archetypes & OPTs)
• processable / accessable / queryable data
• Tips:
–
–
–
–
archetype id, path, template id, node id are important for querying
references can be simplified (OBJECT_REF) (FKs in Relational)
structured data can be simplified (ej. DV_CODED_TEXT)
…
37
Object-Relational Mapping (ORM)
• OO system (openEHR IM) & Relational DB => ORM
– OO: class, attribute, attr. type, relationship, inheritance
– Relational: table, column, column type, reference
• Key elements:
1.
2.
3.
4.
identity representation
data type mapping
association mapping (different cardinalities 1..1, 1..N, N..N)
inheritance mapping
38
Identity in Object-Oriented Model
• Objects have an identity to:
– differentiate between objects of the same class
– reference those objects
• In the relational model we have Primary Keys
• Solution:
– add an "id" column in each table
– of type "int" or "long" and use it as PK
– FKs reference only PKs "id"
• represents relationships in the OO model
39
Data Type Mapping
MySQL
Postgres
SQLServer
Oracle
date
datetime
date
timestamp
date
datetime2
date
datetime
varchar
text
varchar
text
varchar
nvarchar
varchar2
nvarchar2
clob
Boolean
bit
boolean
bit
char(1) CHEK IN ('1','0')
Integer
integer
numeric
int
number
...
...
...
...
Date
String
...
Each type we use in the OO model, should be mapped
to a type in the DBMS we chose.
40
Mapping Classes  Tables
41
Mapping Relationships
42
Mapping Inheritance
TIP: on table per class, is
better to use the same
value for "id" for the
columns of the same
instances distributed in
different tables.
43
Database Schema Examples
Some databases we have designed
for openEHR data, but with
different purposes
EHRServer
+ generic data storage
+ focused on querying
+ doesn’t map the whole IM
+ training purposes (for now)
45
+ operational DB
+ for an EMR system
+ pretty normalized
46
Hybrid approach
• Considerations
– Use only if it makes sense!
• for example if it improves querying performance / scalability
– Modern Relational DBMS compete with some NoSQL features:
• support documents
• scale through clusters
• some allow in-memory tables or views
47
Agenda
• Clinical Information Requirements
• Clinical Information Organization
• Database Technologies & Features
• openEHR
– goals, information model, knowledge model, data
store & query, versioning & audit
• openEHR Data Storage Techniques
– Relational + ORM
– Hybrid
• Data Querying
48
Data Querying
AQL and path-based queries
Archetype Query Language
• AQL is like SQL for EHRs
• Archetype ID is "like" a table (type of info we want)
– openEHR-EHR-OBSERVATION.blood_pressure.v1
• Data points identified by paths, "like" "columns (defined by each archetype)
– Systolic BP: /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
Get high BP data
SELECT
obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude,
obs/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude
FROM
EHR [ehr_id/value=$ehrUid] CONTAINS
COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS
OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
WHERE
obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude >= 140 OR
obs/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude >= 90
https://openehr.atlassian.net/wiki/display/spec/Archetype+Query+Language+Description
50
AQL - Query samples
SELECT o/data/events/data/items[at0078.13]/value AS WhiteCellCount
FROM EHR e
CONTAINS COMPOSITION c [openEHR-EHRCOMPOSITION.encounter.v1]
CONTAINS OBSERVATION o [openEHR-EHROBSERVATION.lab_test_full_blood_count.v1]
WHERE o/data/events/data/items[at0078.13]/value > 11000000000
AND o/data/events/data/items[at0078.13]/value < 17000000000
TIME WINDOW P1Y/2014-02-12
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
51
AQL - Query samples
SELECT o/data/events/data/items[at0078.13]/value
AS WhiteCellCount
FROM EHR e
CONTAINS COMPOSITION c [openEHR-EHRCOMPOSITION.encounter.v1]
CONTAINS OBSERVATION o [openEHR-EHROBSERVATION.lab_test_full_blood_count.v1]
WHERE
o/data/events/data/items[at0078.13]/value >
11000000000
AND o/data/events/data/items[at0078.13]/value <
17000000000
TIME WINDOW P1Y/2014-02-12
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
52
Infectious diseases tests
monitoring at University
Hospital of North Norway
AQL in action
AQL in action
Infectious diseases monitoring at UNN:
• Laboratory tests are extracted from the
LIS in a canonical XML format
• Canonical extracts are transformed into
openEHR compliant extracts
• Extracts are loaded into an openEHR data
warehouse (Think!EHR)
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
54
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
55
AQL in action
AQL 1:
+ Count positive tests of Pertussis for the day specified in the parameter
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'
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
56
AQL in action
AQL 2:
+ Count patient ID
+ 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)
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'
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
57
EHRServer Queries
Path-based queries in action
https://cabolabs-ehrserver.rhcloud.com/ehr-0.3/query/list
EHRServer Query Builder
59
Path-based queries in action
Path-based:
+ Get clinical documents (compositions)
+ With high BP
{
JSON
expression of
EHRServer
queries
"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]" }
}
}
]
}
60
Path-based queries in action
Results:
+ in XML (or JSON if specified on the query or as a parameter)
+ just the index, no data, get a document using the index or change the query to get the data
<list>
<compositionIndex id="8">
<archetypeId>openEHR-EHR-COMPOSITION.signos.v1</archetypeId>
<category>event</category>
<dataIndexed>true</dataIndexed>
<ehrId>11111111-1111-1111-1111-111111111111</ehrId>
<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>
<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>
61
Path-based queries in action
Path-based:
+ Get clinical data for all vital signs measures
+ Result in JSON format, grouped by path (type of data)
{
"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"
}
]
JSON
expression of
EHRServer
queries
}
62
GastrOS – Endoscopy Database
http://gastros.codeplex.com
• Open Source openEHR implementation of a commercial DB for academic
research (2011)
• Based on Minimal Standard Terminology for Digestive Endoscopy (MST 2)
• Works with openEHR RM directly
– C# openEHR.NET (Open Source)
– Uses 3 Templates (EGD, Colonopscopy, ERCP)
• Used RDMBS (MS Access and SQLite)
• Uses ORM (Nhibernate) to store XML Compositions
63
MST Structure
MST Findings for Duodenum
MST Hierarchy
Endoscopic
Observation / Procedure
Heading
Term
Site
Attribute
Value
64
65
Content Model Coverage
66
67
AOM Representation
Skeleton Instance
(ENTRY types, CLUSTERS)
OPT
SDE Parser
SDE GUI
Generator
Reference
Model
GUI Form: Widgets+Leaf nodes(ELEMENT)68
69
A Standards-based Approach to Development of
Clinical Registries NZ Gestational Diabetes Registry Pilot
Dr. Koray Atalag MD, PhD, FACHI (National Institute for Health Innovation)
Aleksandar Zivaljevic, PhD candidate (Univ. Of Auckland)
Dr. Carl Eagleton MBChB, FRACP (Counties Manukau District Health Board)
Karen Pickering (Diabetes Projects Trust)
70
GDM Registry Database
• Used OceanEHR Framework
–
–
–
–
Academic license from Ocean Informatics
Simplifies persistence and querying plus more!
Supports openEHR Demographic IM
Supports AQL
• Extended MultiPrac App (Source provided on academic license)
– MVC Application (VS 2010 w/ SQL Server)
– Handles user management, basic admin etc.
– Supports reference sets, provider/organisation etc.
71
The Dataset
72
Automatic technical conversion – C# Class
73
74
Make your own or reuse existing openEHR persistence?
• Open reusable openEHR persistence & query APIs have been suggested and
are now being formally specified
– Join the REST discussion, openEHR wiki + mailinglists
https://openehr.atlassian.net/wiki/display/spec/openEHR+REST+APIs
– Implementations of openEHR SOAP interfaces exist.
• A SOAP API could be formally specified if there is enough interest
– Other API options?
• New reusable implementations are welcome!
• Before implementing your own persistence, consider:
– Is your main interest storage or clinical application?
– Would AQL be helpful in some of your use-cases?
– In what way will it need to scale?
75
Conclusion
• openEHR doesn’t specify how to store openEHR clinical data
– not bound to any technology or modeling technique
• Remember to model data with references to metadata
– archetype id, template id, path, node id
• Use operational templates in software, not archetypes directly
– archetypes are too generic, too many options, not so good for software
• Choosing a technology is on you
– there is no one-fits-all solution
– you might need to mix technologies (hybrid solution)
• Modify the openEHR Information Model
– to create your storage model using the chosen technology
• Design generic query mechanisms based on archetype ids and paths
– go for AQL support if you need it, allows to share queries between openEHR Clinical Data
Storages
• Designing and querying Clinical Databases is hard!
– now you have some pointers on where to start 
76
Muito Obrigado!
Perguntas?
[email protected]
@ppazos
github.com/ppazos
koray
@atalagk
[email protected]
erik [email protected]
@ErikSundvall
github.com/ErikSundvall
http://www.imt.liu.se/~erisu/
[email protected]