In this talk I will touch on some hard problems in health informatics around working with structured data and why we can’t link and reuse them with ease. The essence of the problem is that, while clinicians can perfectly understand each other, IT systems can’t. Traditional IT requires formally defined common terminology, meta-data, data and process definitions. While Medicine is mostly accepted as positive science, yet the great variation in the body of knowledge and practice is often seen as ‘Art’. Ignoring this bit, IT people tend to develop all-inclusive common information models (almost always too complex to implement) and expect everybody adhere to that. Clinicians love to do things a bit differently and of course don’t buy into that! Maybe they are right! Maybe we don’t have to agree on a uniform model at all. This is the basic assumption of the openEHR methodology which I will describe by giving clinical examples. The main premise of this approach is to effectively separate tasks of healthcare and technical professionals. Clinicians can easily define their information needs as they like using visual tools – called Archetypes which are essentially maximal data sets. These computable artefacts, built using a well defined set of technical building blocks, are then fed into the technical environment to integrate data or develop software. Lastly the free web based openEHR Clinical Knowledge Manager portal provides collaborative Archetype development and ensures semantic consistency among different models.

1. What If We Never Agree On A Common
Health Information Model?
2 Nov 2011, CTRU Research Seminar
Koray Atalag, MD, PhD, FACHI
The National Institute
Informatics for Health Innovation

2. A look at clinical
communication
• Clinicians usually understand each other when
conveying information about patients, studies etc.
• Perhaps because:
– Communication is a natural phenomenon
– Common language (common training, experience, culture,
goals, universality of Medicine)
– Moral responsibility, drive for success, money etc.
• It is a seamless human thing - involves greatest
computer of all times – the Brain!
• We still don’t have a clue how this happens though 

3. What’s the problem with IT
here?
• We capture heaps of healthcare data - sit in silos
• Partly structured and coded – depends on purpose
– eg ICD10, ICD-O, LOINC
• Coding is not easy
– depends on context, purpose, or just coder’s mood!
• Still wealth of valuable information in free text
• Difficult to code from free text after capturing
– Usually context is lost
• Ultimately we cannot link, share and reuse!

4. What are the implications?
• Apart from:
– safety, quality, effectiveness and equity in healthcare
– New knowledge discovery and advances in Science
• Cost of not sharing health information:
– in the US could sum up to a net value of $77.8 billion/yr
(Walker J. The Value Of Health Care Information Exchange And
Interoperability. Health Affairs 2005 Jan)
– In Australia well over AUD 2 billion
(Sprivulis, P., Walker, J., Johnston, D. et al., "The Economic Benefits of
Health Information Exchange Interoperability for Australia,"
Australian Health Review, Nov. 2007 31(4):531–39.)

5. If the banks can do it, why can’t
health?
• Clinical data is wicked:
– Breadth, depth and complexity
• >600,000 concepts, 1.2m relationships in SNOMED
– Variability of practice
– Diversity in concepts and language
– Conflicting evidence
– Long term coverage
– Links to others (e.g. family)
– Peculiarities in privacy and security
– Medico-legal issues
– It IS critical…

6. Wickedness: Medication timing
Dose frequency Examples
every time period …every 4 hours
n times per time period …three times per day
n per time period …2 per day
…6 per week
every time period …every 4-6 hours,
range …2-3 times per day
Maximum interval …not less than every 8
hours
Maximum per time …to a maximum of 4 times
period per day
Acknowledgement: Sam Heard

7. Wickedness: Medication timing
Time specific Examples
Morning and/or lunch …take after breakfast
and/or evening and lunch
Specific times of day 06:00, 12:00, 20:00
Dose duration
Time period …via a syringe driver
over 4 hours
Acknowledgement: Sam Heard

8. Wickedness: Medication timing
Event related Examples
After/Before event …after meals
…before lying down
…after each loose stool
…after each nappy change
n time period …3 days before travel
before/after event
Duration n time period …on days 5-10 after
before/after event menstruation begins
Acknowledgement: Sam Heard

9. Wickedness: Medication timing
Treatment Examples
duration
Date/time to date/time 1-7 January 2005
Now and then repeat …start, repeat in 14 days
after n time period/s
n time period/s …for 5 days
n doses …Take every 2 hours for 5
doses
Acknowledgement: Sam Heard

10. Wickedness: Medication timing
Triggers/Outco Examples
mes
If condition is true …if pulse is greater than 80
…until bleeding stops
Start event …Start 3 days before travel
Finish event …Apply daily until day 21 of
menstrual cycle
Acknowledgement: Sam Heard

11. How do we model now?
complex techy stuff

12. A new approach:
 Open source specifications for representing health
information and person-centric records
– Based on 18+ years of international implementation experience
including Good European Health Record Project
– Superset of ISO/CEN 13606 EHR standard
 Not-for-profit organisation - established in 2001
www.openEHR.org
 Extensively used in research
 Separation of clinical
and technical worlds
• Big international community

13. Key Innovations
• “Multi-level Modelling”
– separation of health information representation into layers
1) Reference Model: Technical building blocks (generic)
2) Content Model: Archetypes & Templates (domain-specific)
3) Terminology: ICD, CDISC/CDASH, SNOMED etc.
Data exchange and software based on only the first layer
Archetypes provide ‘semantics’ for mapping and GUI forms
Terminology provides linkage to knowledge sources (e.g.
Publications, knowledge bases, ontologies)

14. Multi-Level Modelling in openEHR

15. Date and Time Handling in openEHR

16. Archetypes:
Blueprints of Health Information
• Puts together RM building blocks to define clinically
meaningful information (e.g. Blood pressure)
• Configures RM blocks
• Structural constraints (List, table, tree)
• 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
• They are maximal datasets–contain every possible item
• Modelled by domain experts using visual tools

17. Clinicians in the Driver’s Seat!

18. Content Example:
Blood Pressure Measurement

19. Blood Pressure Measurement
Meta-Data

20. Blood Pressure Measurement
Data

21. Blood Pressure Measurement
Patient State

22. Blood Pressure Measurement
Protocol

23. Open Source Archetype Editor

25. Content Modelling in Action
Back in 2009 – GP view of BP
WHAT HAVE WE MISSED?
Acknowledgement: Heather Leslie & Ian McNicoll

26. Blood pressure: CKM review
Acknowledgement: Heather Leslie & Ian McNicoll

27. Blood pressure: CKM review
Acknowledgement: Heather Leslie & Ian McNicoll

28. Blood Pressure v2
…additional input from other clinical settings
Acknowledgement: Heather Leslie & Ian McNicoll

29. Blood Pressure v3
…and researchers
Acknowledgement: Heather Leslie & Ian McNicoll

30. CKM: Versioning
Acknowledgement: Heather Leslie & Ian McNicoll

31. CKM: Discussions

32. Blood pressure: Translation
Acknowledgement: Heather Leslie & Ian McNicoll

33. How do they all fit together?
(to share and reuse data)
• Common RM blocks ensure data compatibility
– No need for type conversions, enumerations, coding etc.
• Common Archetypes ensure semantic consistency
– when a data exchange contains blood pressure
measurement data or lab result etc. it is guaranteed to
mean the same thing.
– Additional consistency through terminology linkage
• Common health information patterns and
organisation provide ‘canonical’ representation
– All similar bits of information go into right buckets
• Addresses provenance and medico-legal issues

34. Patterns in Health Information
Observations
Clinician measurable or
Published observable
evidence base Subject
Personal Actions
knowledge Recording data
for each activity
Evaluation
clinically interpreted
findings
Administrative Investigator’s agents
Entry
Instructions
order or initiation of a (e.g. Nurses, technicians,
other physicians or
workflow process automated devices)

35. A Simple Health Information
Organisation
EHR
Folders
Compositions
Sections
Entries
Clusters
Elements
Data values

36. Achievable?
• ̴ 10-20 archetypes  core
clinical information to ‘save a
life’
• ̴ 100 archetypes  primary
care
• ̴ 2000 archetypes  secondary
care
– [compared to >600,000 concepts
in SNOMED]

37. Achievable? 2
• Initial core clinical content is common to all
disciplines and will be re-used by other specialist
colleges and groups
– Online archetype consensus in CKM
– Achieved in weeks/archetype
– Minimises need for F2F meetings
– Multiple archetype reviews run in parallel
• Leverage existing and ongoing international work
Acknowledgement: Sam Heard

38. Can clinicians agree on single
definitions of concepts?
• “What is a heart attack?”
– “5 clinicians, potentially >1 answer” – probably more!
• “What is an issue vs. problem vs. diagnosis?”
– No consensus for conceptual definition for years!
BUT
• There is generally agreement on the structure and
attributes of information to be captured
 Problem/Diagnosis  Clinical description  Exacerbations
name  Date clinically  Related problems
 Status recognised  Date of Resolution
 Date of initial onset  Anatomical location  Age at resolution
 Age at initial onset  Aetiology  Diagnostic criteria
 Severity  Occurrences
Acknowledgement: Sam Heard

39. Problem Archetype

40. Who’s using it for research?
• The Victorian Cancer Council
– Transformed all their research data over the last 20
years to an openEHR repository
• SINTERO Project
– Wellcome Trust funded – at Cardiff Univ.
– Gather data for diabetes from patients, devices and
hospital records
– openEHR based repository to aggregate and query data

41. NZ Interoperability Architecture
is underpinned by openEHR

42. Thanks...
Questions?
k.atalag@auckland.ac.nz
If you are really interested in Health Informatics,
consider attending HINZ. This year's annual conference is in
Auckland 23-25 November
http://www.hinz.org.nz/page/conference