1 / 30

Assessing the use of archetypes in ED Information System

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 Reference Model & Archetypes Model

cleave
Download Presentation

Assessing the use of archetypes in ED Information System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • 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: • 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”

  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 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. 1. Select all appropriate attributes 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_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 • 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 ?

More Related