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

2

Project Description openEHR Basic Principles

Reference Model & Archetypes Model Archetypes

Data Model Archetype Data Dictionary (ADD) Demographics Model (DM) Generic Data Structure (GDS) Composition Package

Findings and Issues

Outline

3

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

4

Introducing openEHR

openEHR – open Electronic Health Record International organisation.

Goals: Interoperable health systems Life Long health records

5

openEHR idea 2 level frame work:

Reference Model (RM): Information model Semantics of storing and processing in system

Archetype Model (AM): Knowledge model Domain level structure and constraints placed on the RM

Why?

Separate knowledge (domain experts) and information (IT experts) models.

Interoperability

6

Archetype Archetypes are fundamental to openEHR.

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”

1..1

Concept: “Blood Pressure”

Name: “systolic”Value: mm[Hg]

Name: “Core Data”

Name: “diastolic”Value: mm[Hg]

1..1

1..1

7

Methodology1. Archetype Data Dictionary

2. Demographics Model

3. Generic Data Model

Reference Model

Persistent Layer

8

Data Model

9

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.

10

Archetype Data Dictionary

ARCHETYPE ELEMENT

TERM BINDING

UNIThas

Is_binded_to

has

Id IdELEMENT.Id

Name

Id

11

Archetype Data Dictionary1. Archetype Name and Type

2. Archetype elements3. Constraints on attributes

12

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

13

Demographics Model (DM)

PARTY

Id

ACTOR

PARTY.Id

ROLE

PARTY.Id

PerformsSpeaks

Identified_by

Contacted_by ADDRESS

Id

includes

Is_related_by

has

Is_described_by

ELEMENT

EntityId (FK)**

eType

LANGUAGE

Id

PARTYIDENTITY

Id

CAPABILITYId

CONTACT

Id

PARTYRELATIONSHIP

Id

CONTACT.Id

**Note: FK ‘EntityID’ is used to link the ACTOR, ROLE, PARTY_IDENTITY, ADDRESS and PARTY_RELATIONSHIP together. The PK ‘{EntityId,eType}’ distinguishes its uniqueness.

14

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

15

Generic Data Model (GDM)

Made_up_of

EVENT.Id

HISTORY ITEM

STRUCTURE

Id

*** Note: FK ‘StructureID’ is from either ACTIVITY, EVENT CONTEXT or ENTRY tables.Candidate Key: {Structure Id, Type}

DATA STRUCTURE

Id

ITEM STRUCTURE

DATA STRUCTURE.Id

HISTORY

DATA STRUCTURE.Id

EVENT

Id

POINT EVENT

INTERVAL EVENT

EVENT.Id

Recorded_by Dedscribed_by HISTORY ITEM

Id

has

ELEMENT VALUE

ITEM.Id

HISTORY ELEMENT

VALUE

HISTORY ITEM.Id

ITEM

Id

Described_by has

16

Generic Data Structure

Logical Form

Physical Form

17

Generic Data Structure1. Data identifier

3. Data Attributes

4. Attribute’s associated values

2. Generic Structure type

18

Findings and Issues

Performance – Retrieving, Storing, Querying Complexity Interoperability

Advantages and Disadvantages of the architecture.

19

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.

20

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

21

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?

22

SELECT 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_UNITFROM

EHR AS ehr, COMPOSITION AS c, EVENT_CONTEXT AS ec, DATA_STRUCTURE AS ds, ITEM_STRUCTURE AS its, ITEM AS i, ELEMENT_VALUE AS evWHERE

ehr.EHR_ID = c.EHR_ID And c.COMPOSITION_ID = ec.EVENT_CONTEXT_ID And ec.EVENT_CONTEXT_ID = ds.STRUCTURE_ID And ds.DATA_STRUCTURE_TYPE= 'EVENT_CONTEXT' And ds.DATA_STRUCTURE_ID = its.ITEM_STRUCTURE_ID And its.ITEM_STRUCTURE_ID = i.ITEM_STRUCTURE_ID And i.ITEM_ID = ev.ELEMENT_VALUE_ID And ehr.EHR_ID = 1;

3. Filter joined tables for correct rows

1. Select all appropriate attributes

2. Join generic tables

23

Advantages of openEHR

Interoperability Use of shared repository of archetypes allows

information exchange between systems.

Generic data structures Adaptable to other health systems. Information model does not have to be altered if

domain knowledge changes.

Life long electronic health records

24

Disadvantages of openEHR Performance issues

Significant overhead in processing Recall E.A.V modelling 3 to 5 times less efficient than

conventional modelling.

Models are very generic 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

25

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

26

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

27

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”

28

Future Work

Complete implementation of generic OpenEHR in python

Develop a version for ED

29

Questions ?

30