The document discusses the development of a content model for view datasets utilizing archetypes, aiming to enhance risk prediction models and create a variation atlas of cardiovascular diseases in New Zealand. It outlines objectives such as defining a canonical information model and establishing a research data repository that integrates existing datasets while ensuring backward compatibility. The content model, based on archetypes, facilitates interoperability, real-time data access, and efficient research data sharing, addressing challenges related to data silos and loss of clinical context.

1. Content Modelling for VIEW
Datasets Using Archetypes
Koray Atalag1, Jim Warren1,2, Rod Jackson2
1.NIHI – University of Auckland
2.Department of Computer Science – University of Auckland
3.School of Population Health – University of Auckland

2. What’s VIEW
• Smart (!) name  Vascular Informatics using Epidemiology &
the Web (VIEW)
• Building on PREDICT CVD-DM (primary care)
– Extending to secondary (acute Predict)
– Improving risk prediction models
– Creating a variation map/atlas of NZ
• Data linkages to:
– National Mortality Register,
– National Minimum Dataset (public and private hospital discharges)
– National Pharmaceutical Collection (drugs dispensed from community
pharmacies with government subsidy)
– National PHO Enrolment Collection
– Auckland regional CVD-relevant laboratory data from DML
– TestSafe (in progress)

4. Objectives of this study
• Extend existing data management capabilities;
– Define a canonical information model (openEHR)
– Normalise and link external datasets
– Ability to extend without compromising backward
data compatibility – future-proofing
• Create a state-of-the-art research data
repository
– Transform existing datasets into full-EHR records
– Data integration using model as map
– Powerful semantic querying & stata on the fly

5. Archetypes
• Smallest indivisible units of clinical information
– Preserving clinical context
– maximal datasets for given concept
• Brings together building blocks from Reference Model
• Puts constraints on them:
– Structural constraints (List, table, tree, clusters)
– What labels can be used
– What data types can be used
– What values are allowed for these data types
– How many times a data item can exist?
– Whether a particular data item is mandatory
– Whether a selection is involved from a number of items/values

6. Logical building blocks of EHR
EHR
Folders
Compositions
Sections
Entries
Clusters
Elements
Data values

7. Example Model:
Blood Pressure Measurement

8. BP Measurement Archetype

9. PREDICT Dataset Definitions

10. Current Model

11. NZ Extension

13. Results
• Archetype based content model can faithfully
represent PREDICT dataset
• Modelling:
– two new archetypes‘Lifestyle Management’ and
‘Diabetic Glycaemic Control’ checklists
– NZ extensions for demographics (DHB catchment,
meshblock/domicile, geocode NZDep)
• Difficulty: overlap between openEHR and NEHTA
repositories – different archetypes for tobacco use,
laboratory results and diagnosis which we reused
– Considering both repositories are evolving separately it is
challenging to make definitive modelling decisions.

14. Potential Benefits
• High level of interoperability and increased
data linkage ability
• Important for research data sharing
• Can sync more frequently (even real-time!)
• Can leverage biomedical ontologies (through
Archetype terminology bindings and service)
• Can perform complex and fast queries on
clinical data (real-time decision support)

15. Bigger Picture
• Interoperability for clinical information
systems – great
– But what about population health & research?
• Research data also sits in silos – mostly C
Drives or even worse in memory sticks!
• Difficult to reuse beyond specific research
purpose – clinical context usually lost
• No rigour in handling and sharing of data

17. Shared Health Information Platform (SHIP)

20. VIEW extensions  ECM

21. Working Principle
Exchange Content Model
Conforms to
Message
Payload
(CDA)
Source System Recipient System
Map Map
Source to Web Service ECM to
ECM Recipient
Exchange
Data
Object
Source data Recipient data

22. Questions / Further Info
Koray Atalag, MD, PhD, FACHI
k.atalag@nihi.auckland.ac.nz