1. 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. Outline Project Description openEHR Basic Principles Data Model
Reference Model & Archetypes Model
Archetypes
Data Model
Archetype Data Dictionary (ADD)
Demographics Model (DM)
Generic Data Structure (GDS)
Composition Package
Findings and Issues

3. Project Description Problem: Objective
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 Goals:
International organisation.
Goals:
Interoperable health systems
Life Long health records

5. openEHR idea 2 level frame work: Why? 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”

7. Methodology Archetype Data Dictionary Demographics Model
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

11. Archetype Data Dictionary
1. Archetype Name and Type
3. Constraints on attributes
2. Archetype elements

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)

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)

16. Generic Data Structure
Logical Form
Physical Form

17. Generic Data Structure
2. Generic Structure type
1. Data identifier
4. Attribute’s associated values
3. Data Attributes

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

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. 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
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
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;
2. Join generic tables
3. Filter joined tables for correct rows

23. Advantages of openEHR Interoperability Generic data structures
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 ?