2. What is CDR ?
Ø Definition of CDR
• A data store that holds and manages clinical data collected
from service encounters at point of service locations (e.g.
hospitals, clinics) (from ISO/TR 20514,2005)
Ø Widely implemented internationally
• 46.7% Asia Pacific, 71.2% Middle East, 67.2% Canada,
94.8% America
Ø Early adoption in China
• 0.57% hospitals in China until 2014
Ø CDR is particularly important to support medical
information interoperation in China
4. Clinicians Engineers
Clinical Data Repository
HIS LIS PACS …RIS EIS OIS
Data
Viewer
Data
Analytics
Decision
Support
。。。
Data
Mining
Gap
I want to
query the
count of
patient with
CIK therapy
plan
Researchers
I want to find
the relationship
between
diseases and
certain factors
Patients
I want to find
the number
of patients
like me
I want to
integrate my
new system to
CDR
Increasing requirements
cannot be filled
Developed software
cannot be fully used
The Gap between requirements and reality
5. Solution
An Open Extensible Information Platform
Let the people with data requirements retrieve & query
data themselves
I can
configure a
simple form
for my
request
I can get the
necessary
data as input
to analytics
software
I can query
whatever I
needed
I can
transfer the
data to my
own
structure
Clinical Data Repository
HIS LIS PACS …RIS EIS OIS
Clinicians EngineersResearchers Patients
6. openEHR Methodology
ØTwo level model & Shared archetypes - CKM
ØFlexibility and scalability of semantics interoperation
ØA promising approach to build the CDR system
9. Data persistence
xml database
Basic serialization
XML databaseNode+path
1. Performance slower than conventional RDB
2. Not suitable to answer complex query
Take into consideration that almost all the hospitals in China adopt relational database,
the relational database persistence with openEHR approach is necessary.
Hybrid serialization
11. Principle of ARM
Keep the same granularity of information at modeling and persistence.
openEHR Model Entity Relationship Model
Archetype Entity
Archetype Attribute Entity Attribute
Embedded CLUSTER Weak Entity
Archetype Specialization Entity Inheritance
SLOT Relationship
LINK Relationship
Multiple Occurrence Attribute Multiple Occurrence Attribute
Identification Attribute Identification Attribute
Computation Attribute Computation Attribute
openEHR Model Concepts vs. Entity Relational Model Concepts
Experts
RDB
12. Straight
• Basic data type attribute
• Action archetype state machine
• Basic archetype structure
Boost
• Identification attribute
• Query attribute
• Flattened attribute
Tune
• Propagated attribute
• Singularized attribute
• General/Specific archetype
ARM data persistence rules
Denormalization
16. •AQL grammar
•ANTLR grammar analyzer
•Abstract grammar tree
Grammar
analysis
•Archetype
•Variable
•Path
Legality
verification •Multiple SQLs
Query
execution
•XML or ODIN
•Gzip compression
Result
capsulation
Archetype Query Language - AQL
SELECT o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value,
o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value
FROM EHR e [openEHR-EHR-EHR.ehr.v1] CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS
OBSERVATION o [openEHR-EHR-OBSERVATION.blood_pressure.v1]
WHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value >= 140 OR
o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value >= 90
INSERT INTO OBSERVATION o [openEHR-EHR-OBSERVATION.blood_pressure.v1]
VALUES o/uid/value = newUID(),
o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value = 140,
o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value = 90
UPDATE OBSERVATION o [openEHR-EHR-OBSERVATION.blood_pressure.v1]
SET o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value = 140
WHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value >= 90
DELETE FROM OBSERVATION o [openEHR-EHR-OBSERVATION.blood_pressure.v1]
WHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value >= 140
OR o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value >= 90
17. REST API
Ø Auto generated REST API
• GET, POST, PUT, DELETE with template uid or identification
attribute as condition
Ø REST API designer
18. Performance comparison
Query
serial
number
Records
count
API(ms) AQL(ms)
1 1 5 6
2 1 9 6
3 1 5 6
4 1 5 7
5 1 5 5
6 1 5 5
7 1 5 5
8 1 6 13
9 1 6 5
10 1 5 4
Average 1 5.6 6.2
Query
serial
number
Records
count
API(ms) AQL(ms)
1 209 10 20
2 1209 21 71
3 2847 41 150
4 56 5 8
5 1221 19 72
6 1971 28 106
7 1337 24 74
8 7 5 5
9 279 15 20
10 532 15 33
Average 966.8 18.3 55.9
Retrieving patient information by patient identifier Retrieving image information by exam identifier
The execution time is similar between AQL query and API query. On account of
package for ODIN, the AQL average performance is little slower than API.
23. Ø Part of Project of “Medical Data Integration & Merging”, funded by
Chinese National “863” Program, initiated in 2012.
Ø Research Purpose: An methodology of implementing open and
extensible CDR and a case study in a pilot hospital
Shangxi Dayi Hospital with 2600 beds
CDR Implementation in Chinese Hospital
24. CDR in Chinese Hospital - Architecture
HIS LIS PACS …RIS EMR CIS
Archetype template
repository
Data access service
Diabetes follow-up Integrated data viewClinical decision support
Research Data Query Quality Data analysis Data mining and analysis
Application based on the CDR
25. CDR outcome
643665
34664534
1355345
14727482
32676 528600 115371 673619 760687
9236476
0
5000000
10000000
15000000
20000000
25000000
30000000
35000000
40000000
Data statistics
Examination request Examination data Lab test request Lab test data
Operation request Diagnosis Health examination Patient
Encounter Order
Ø 89 archetypes, 85 tables and 142 APIs.
Ø Data volume (2012.8—2015.12)
• Medical data 120G
• 673619 patients and 760687 encounters
32. Ø openEHR is a promising methodology to provide a open
and highly extensible solution for building CDR
Ø The study show the feasibility of Archetype/Template
driven approach.
Ø More configurable applications such as decision tools,
clinical quality management tools need to use archetypes
as their data sources to achieve interoperability.
What we learned from implementation?