Transcript Richard-Presentation.. - The University of Sydney

Assessing the use of archetypes
in ED Information System
Jon Patrick, Richard Ly
Centre for Health informatics Research &
Development
Donna Truran, National Centre for
Classification in Health
Outline


Project Description
openEHR Basic Principles



Data Model





Reference Model & Archetypes Model
Archetypes
Archetype Data Dictionary (ADD)
Demographics Model (DM)
Generic Data Structure (GDS)
Composition Package
Findings and Issues
2
Project Description

Problem:



Emergency Department (ED) Information System lacks
interoperability, intelligent querying, effective use of
terminology.
Medical environment is highly volatile.
Objective


Investigating openEHR Architecture by developing a data
model
Feasibility of using openEHR as a basis for an ED
Information System
3
Introducing openEHR

openEHR – open Electronic Health Record


International organisation.
Goals:


Interoperable health systems
Life Long health records
4
openEHR idea

2 level frame work:

Reference Model (RM):



Archetype Model (AM):



Information model
Semantics of storing and processing in system
Knowledge model
Domain level structure and constraints placed on the RM
Why?


Separate knowledge (domain experts) and information (IT
experts) models.
Interoperability
5
Archetype

Archetypes are fundamental to openEHR.
Concept: “Blood Pressure”
1..1

Name: “Core Data”
1..1
Name: “systolic”
Value: mm[Hg]
1..1
Name: “diastolic”
Value: mm[Hg]
Definition:

“An archetype is a formal expression of a distinct,
domain level concept, expressed in the form of
constraints on data whose instances conform to
some RM”
6
Methodology
1.
2.
3.
Archetype Data Dictionary
Demographics Model
Generic Data Model
Reference Model
7
Data Model
8
Archetype Data Dictionary (ADD)

ADD is a repository of archetypes

Contains the definition of archetypes.

Enables software layer to correctly instantiate
EHR data by ensuring these instances
adhere to defined archetypes.
9
Archetype Data Dictionary
ARCHETYPE
ELEMENT.Id
Id
Id
has
Name
ELEMENT
has
UNIT
Is_binded_to
TERM
BINDING
Id
10
Archetype Data Dictionary
1. Archetype Name and Type
3. Constraints on attributes
2. Archetype elements
11
Demographics Model (DM)

openEHR assumes distributed model

Demographics model describes any party
who has interaction with health care facility.

In an ED Information System, demographics
model will record patient administrative data.

Similar to Patient Master Index (PMI) in EDIS
12
Demographics Model (DM)
Id
Id
PARTY
IDENTITY
Identified_by
PARTY
CONTACT.Id
Id
PARTY.Id
Id
LANGUAGE
Speaks
ACTOR
PARTY.Id
Performs
Contacted_by
Id
CONTACT
includes
ADDRESS
ROLE
Id
has
Is_related_by
Id
PARTY
RELATIONSHIP
CAPABILITY
Is_described_by
ELEMENT
EntityId
(FK)**
eType
**Note: FK ‘EntityID’ is used to link the ACTOR, ROLE, PARTY_IDENTITY, ADDRESS and
PARTY_RELATIONSHIP together. The PK ‘{EntityId,eType}’ distinguishes its uniqueness.
13
Generic Data Model (GDM)

A generic data structure flexible enough to model
most, if not all logical structures in clinical records.

Why? It is the basis for storing instances of
archetyped information in a relational database.

It must cater for:



Instantaneous and interval measurements
Historical and Time series events
Structures: SINGLE, LIST, TREE, TABLE
14
Generic Data Model (GDM)
DATA STRUCTURE.Id
ITEM
STRUCTURE
ITEM.Id
Id
Described_by
ITEM
ELEMENT
VALUE
has
Id
EVENT.Id
DATA
STRUCTURE
INTERVAL
EVENT
Id
HISTORY
Made_up_of
EVENT
EVENT.Id
DATA STRUCTURE.Id
POINT EVENT
HISTORY
ITEM.Id
Id
*** Note: FK ‘StructureID’ is from either ACTIVITY, EVENT CONTEXT or ENTRY tables.
Candidate Key: {Structure Id, Type}
Recorded_by
HISTORY
ITEM
STRUCTURE
Dedscribed_by
HISTORY
ITEM
has
HISTORY
ELEMENT
VALUE
Id
15
Generic Data Structure
Logical Form
Physical Form
16
Generic Data Structure
1. Data identifier
2. Generic Structure type
4. Attribute’s
associated values
3. Data
Attributes
17
Findings and Issues

Performance – Retrieving, Storing, Querying



Complexity
Interoperability
Advantages and Disadvantages of the
architecture.
18
Performance

Entity-Attribute-Value (E.A.V) modelling
allows representation of generic data
structures in a relational database.

However, it has performance trade offs.

Insertion, retrieval, validation and querying can be
costly due to the amount of processing required to
reconstruct information from generic tables.
19
Performance

According to a performance study on E.A.V
modelling by Yale University;


“E.A.V modelling can be up to 3 to 5 times less
efficient than its conventional counterpart
(traditional modelling methods)”
“… differences in query efficiency became greater
as database size increased”
Source: Ronald S. Chen et. al. (2000). ‘Exploring Performance Issues for a Clinical Database
Organised Using an Entity Attribute Value Representation‘ Journal of the American Medical
Information Association. Pp 475-478
20
E.g. SQL Querying

What is a SQL statement to find:
The NMDS information relating to an ED visit
from patient with health record = 1?
21
SELECT
1. Select all appropriate
attributes
ehr.EHR_ID, ehr.PATIENT_ID, ehr.EHR_DATE_TIME_STAMP,
c.COMPOSITION_COMPOSER, ec.HEALTH_CARE_FACILITY,
ec.EVENT_CONTEXT_START_TIME,
ec.EVENT_CONTEXT_END_TIME,
ds.DATA_STRUCTURE_TYPE, ds.DATA_STRUCTURE_NAME,
its.ITEM_STRUCTURE_NAME, i.ITEM_NAME,
ev.ELEMENT_VALUE, ev.ELEMENT_UNIT
FROM
2. Join generic tables
EHR AS ehr, COMPOSITION AS c, EVENT_CONTEXT AS ec,
DATA_STRUCTURE AS ds, ITEM_STRUCTURE AS its, ITEM AS i,
ELEMENT_VALUE AS ev
WHERE
And
And
And
And
And
And
And
ehr.EHR_ID
=
c.COMPOSITION_ID
=
ec.EVENT_CONTEXT_ID =
ds.DATA_STRUCTURE_TYPE=
ds.DATA_STRUCTURE_ID =
its.ITEM_STRUCTURE_ID =
i.ITEM_ID
=
ehr.EHR_ID
=
3. Filter joined tables for
c.EHR_ID
correct rows
ec.EVENT_CONTEXT_ID
ds.STRUCTURE_ID
'EVENT_CONTEXT'
its.ITEM_STRUCTURE_ID
i.ITEM_STRUCTURE_ID
ev.ELEMENT_VALUE_ID
1;
22
Advantages of openEHR

Interoperability


Generic data structures



Use of shared repository of archetypes allows
information exchange between systems.
Adaptable to other health systems.
Information model does not have to be altered if
domain knowledge changes.
Life long electronic health records
23
Disadvantages of openEHR

Performance issues



Models are very generic



Significant overhead in processing
Recall E.A.V modelling 3 to 5 times less efficient than
conventional modelling.
Not intuitive conceptually.
Complex attribute querying is less efficient and technically
more difficult.
Must get everyone to agree on a set of archetypes

Archetype governance
24
Python Implementation (Brendan Cheng)
Model Complexity
3 models
Reference Model, 5 packages, 90 classes
Archetype Model, 10 packages, 40 classes
Service Model
30% of first 2 models implemented in 3,000 lines
Content is strongly coupled and complex
Prescription archetype requires 30 classes
25
Implementation contd.




The interconnection means all classes must be
implemented before testing can begin.
Sometimes there is no clear or detailed explanation
(600 pages of specs spread across 10 files)
E.g. logical_paths (a_lang:String): Set<String>
Def. Set of language-dependant paths extracted
from archetype. Paths obey the same syntax as
physical_paths, but with node_ids replaced by their
meanings from the ontology
26
Implementation contd.



More variables, arguments & functions in the
Eiffel implementation than in the Specification
Answers from the Open EHR team are not
always informative and indicate the
documentation is not always in sync with
specification:
“It has already been implemented in Java and
C# actually, so we should be able to find out
the approach used by those two groups”
27
Future Work


Complete implementation of generic
OpenEHR in python
Develop a version for ED
28
Questions ?
29
30