Download Document

What if We Really Had a Silver Bullet to
Deal with Health Information?
1 Dec 2011, COMPASS Seminar
Koray Atalag, MD, PhD, FACHI
What’s the Problem with Health
Information?
• We capture heaps of data - sit in silos 
• Partly structured and coded
– eg ICD10, ICD-O, READ, LOINC etc.
• Coding is not easy / expensive
– Depends on context, purpose, or just coder’s mood!
– Automated coding is not reliable
• Difficult to code from free text after capturing
– Usually context is lost
– Best at the time and place of data capture
• Still wealth of valuable information in free text
• We cannot link, aggregate and reuse!
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 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.)
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…
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
range
…every 4-6 hours,
…2-3 times per day
Maximum interval
…not less than every 8
hours
Maximum per time
period
…to a maximum of 4 times
per day
Acknowledgement: Sam Heard
Wickedness: Medication timing
Time specific
Examples
Morning and/or lunch
and/or evening
…take after breakfast
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
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
before/after event
…3 days before travel
Duration n time period
before/after event
…on days 5-10 after
menstruation begins
Acknowledgement: Sam Heard
Wickedness: Medication timing
Treatment
duration
Examples
Date/time to date/time
1-7 January 2005
Now and then repeat
after n time period/s
…start, repeat in 14 days
n time period/s
…for 5 days
n doses
…Take every 2 hours for 5
doses
Acknowledgement: Sam Heard
Wickedness: Medication timing
Triggers/Outco
mes
Examples
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
How Do We Model Now?
Complex techy stuff
A New Approach:
 Open source specifications for representing health
information and person-centric records
– Based on 20+ years of international experience including Good
European Health Record Project
– Superset of ISO/CEN 13606 EHR standard
 Not-for-profit organisation - established in 2001
www.openEHR.org
 Separation of clinical
and technical worlds*
• Big international community
and research
Clinicians in the Driver’s Seat!
Key Innovation
“Multi-level Modelling”
separation of health information representation into layers
1) Reference Model: Technical building blocks (generic)
2) Content Model: Archetypes (domain-specific)
3) Terminology: ICD, CDISC/CDASH, SNOMED etc.
Data exchange and software development based on first layer
Archetypes provide ‘semantics’ + behaviour and GUI
Terminology provides linkage to knowledge sources
(e.g. Publications, knowledge bases, ontologies)
Multi-Level Modelling in openEHR
Date and Time Handling in openEHR
Archetypes:
Models 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
Content Example:
Blood Pressure Measurement
Blood Pressure Measurement
Meta-Data
Blood Pressure Measurement
Data
Blood Pressure Measurement
Patient State
Blood Pressure Measurement
Protocol
Open Source Archetype Editor
Content Modelling in Action
Back in 2009 – GP view of BP
WHAT HAVE WE MISSED?
Acknowledgement: Heather Leslie & Ian McNicoll
Blood pressure: CKM review
Acknowledgement: Heather Leslie & Ian McNicoll
Blood pressure: CKM review
Acknowledgement: Heather Leslie & Ian McNicoll
Blood Pressure v2
…additional input from other clinical settings
Acknowledgement: Heather Leslie & Ian McNicoll
Blood Pressure v3
…and researchers
Acknowledgement: Heather Leslie & Ian McNicoll
CKM: Versioning
Acknowledgement: Heather Leslie & Ian McNicoll
CKM: Discussions
Blood Pressure: Translation
Acknowledgement: Heather Leslie & Ian McNicoll
How Do They All Fit Together?
• 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 a ‘canonical’ representation
– All similar bits of information go into right buckets
– Easy & accurate querying + aggregation for secondary use
• Addresses provenance and medico-legal issues
A Simple Health Information
Organisation
EHR
Folders
Compositions
Sections
Entries
Clusters
Elements
Data values
Patterns in Health Information
Clinician
Published
evidence base
Observations
measurable or
observable
Subject
Actions
Personal
knowledge
Recording data
for each activity
Evaluation
clinically interpreted
findings
Administrative
Entry
Instructions
order or initiation of a
workflow process
Investigator’s
agents
(e.g. Nurses,
technicians, other
physicians or
automated devices)
Specialisation of Archetypes



Data conforms %100 to parent archetype
International -> national -> regional -> local
Generalist -> specialist -> subspecialist
Problem
Text or Term
•Clinical description
•Date of onset
•Date of resolution
•Side
•No of occurrences
Diagnosis
Term
+
•Grading
•Diagnostic criteria
•Stage
Diabetes
diagnosis
Term
+
•Diagnostic criteria
• Fasting > 6.1
• GTT 2hr > 11.1
• Random > 11.1
Specific blood test
Urine culture
Genomic assay
Retinography
N/A
Routine
N/A
N/A
Rx
N/A
Fluid Tx
Insuline inj
Infection Tx
Psychologic
Detailed DNA
Pedigree Chronic Foot and Seq.
eyes
Assays
Each finding usually depends on other – clinical context matters!
Person-Centric Record Organisation
Low
sugar
Exercise
etc. etc. etc.
Diabetes Dx
-Type
-Severity
-Course etc.
Life Style
Rx B
Dispense
Administer
Genetics
BP 120/70
(24 hour avg)
HR 70
T: 37 C
Physical Exam
Hospital adm.
Diabetes
Priv insurance
Past History
Subject B
USAddress
State
Next of kin
Routine Blood
Urine
X-Ray
Family History
Dx 1
Dx 2
etc.
Interventions
Rx A
Dispense
Administer
Diagnostic Tests
BP 130/90
HR 90
T: 38.5 C
Diagnoses
GP visit
Flu-like
PHO enrolm.
Medications
Clinical Encounter
Subject A
NZ Address
Ethicity1,2.
Whanau
Shared Archetypes
Vital Signs
Demographics
Providing a Canonical Representation
Can Clinicians Agree on Single
Definitions of Concepts?
• “What is a heart attack?”
– 5 clinicians: ~2-3 answers – 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
name
 Status
 Date of initial onset
 Age at initial onset
 Severity
 Clinical description
 Date clinically
recognised
 Anatomical location
 Aetiology
 Occurrences





Exacerbations
Related problems
Date of Resolution
Age at resolution
Diagnostic criteria
Acknowledgement: Sam Heard
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]
Achievable? – cont.
• 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
NZ Interoperability Architecture
is underpinned by openEHR
Thanks...
Questions?
Not a silver bullet, but definitely a good shot!
Visit:
www.openehr.org
[email protected]