Lecture for health informatics students and faculty at the Western Norway University for Applied Sciences, April 25th 2017.

1. Standards in health informatics
– Problem, clinical models and terminologies
Silje Ljosland Bakke / Information architect, Nasjonal IKT HF / Co-lead, openEHR Foundation Clinical Models Program
E-mail: silje.ljosland.bakke@nasjonalikt.no / Twitter: @siljelb

2. 2

3. An ongoing problem…
“In attempting to arrive at the truth, I have applied
everywhere for information but in scarcely an instance have I
been able to obtain hospital records fit for any purpose of
comparison.”
“If they could be obtained, they would enable us to decide
many other questions besides the one alluded to. They would
show subscribers how their money was being spent, what
amount of good was really being done with it or whether the
money was not doing mischief rather than good.”
- Florence Nightingale, 1863
Credit: Heather Leslie

4. Why is health IT so hard?
•Banks are acing it; why isn’t health?
–Complex and dynamic domain
–Lifelong records
–Clinical diversity
–Confidentiality
–Mobile population
Credit: Heather Leslie

5. Complexity
•Both the number of concepts and the rate of
change is high
•Health is big, and continually growing…
–In breadth
–In depth
–In complexity
•Clinical knowledge is
continually changing
Credit: Heather Leslie

6. How have we been dealing with this?
•Free text(Specialist and administrative systems have more
structured data, but generic electronic health records
are still mainly free text)

7. So what do we need structure for?
•Avoid repetition and shadow records
•Retrieval and overview
•Reuse of record info
•Clinical decision support
•Quality indicators
•Management data

8. Longitudinal information access
•How long are you planning to live?
•Do you expect your health record to survive
that long?
•Even if it does survive, will
it be readable for future
systems and users?
Credit: Ricardo Correia

9. Celsius
Ear measurement
IR aural thermometer
Environment: 5° C
Wet clothing Space blanket
temperatureBody
Structuring health is hard
Credit: Bjørn Næss

10. Structuring identically is even harder
Example: Smoking status in
national registries:
• 9 different variations on
“Smoking status” in 26
different forms
• Additionally: number of cigs
per day, month quit smoking,
number of months since
quitting date, etc.
Brandt, Linn (2016). Report from REGmap February 2016 – Complete mapped register set - Preliminary analysis.

11. Structure is not the Messiah
•Structured data is not a goal in itself
•Structure where clear value can be identified
•It must be possible to add nuances using free text
•Sometimes free text
is adequate/best
suited for purpose
1

12. Semantic interoperability
•[…] the ability of computer systems
to exchange data with unambiguous,
shared meaning
•A Holy Grail of health informatics
•Requires (amongst other things)
shared information models
and terminologies
1
NCOIC, "SCOPE", Network Centric Operations Industry Consortium, 2008

13. «Information model»?
•A definition of the structure and content of the
information that should be collected or shared
– A "minimal dataset"
– A message or interface definition
•Internally all applications have some sort of
information model
•Sharing information requires developing shared
information models
Credit: Ian McNicoll

14. How have we been doing infomodelling?
•Locked into each product
•In ways that clinicians don’t understand
•Few clinicians participating
•Technicians are left to interpret
•New requirements?

15. Clinicians must participate!
•They’re the ones who know the domain
•Garbage in ⇒ garbage out
•Minimise wrong
interpretations

16. Semantic interoperability* requires
identical data models
Clinical information modelling is difficult and
expensive, and should be done once
⇒ Information models should be
shared and governed strictly
* Level 4 semantic interoperability; Walker et al. (2005); http://www.ncbi.nlm.nih.gov/pubmed/15659453

18. National governance
•Managed by Nasjonal IKT
•Goal: Sharing quality information models
•Online collaboration tools:
–http://arketyper.no
–https://kilden.sykehusene.no/display/KLIM/
•More than 400 clinicians and health informaticians
participating
1

19. • Specification for structured health records
• openEHR Foundation (openehr.org)
• Free (as in beer AND speech)
• International community
• Two level modelling
• Not an open source application
• Not a downloadable app
Illustration: https://wolandscat.net/2011/05/05/no-single-information-model/

20. openEHR reference model
• EHR structure
• Security
• Versioning
• Participants, dates/times,
data types
NO CONTENT
Credit: Heather Leslie

21. openEHR reference model
Domain
Core
RM

22. Archetypes
• Implementable specification for one clinical concept
• Comprehensible for non-techies
• Maximum datasets (aspirational)
• Reusable
THE STANDARDISED CONTENT
Credit: Heather Leslie

23. Archetypes
2

24. Templates
• Combinations of constrained archetypes
• Data sets for forms, messages, interfaces, etc
• For specific use cases
• NOT user interfaces
THE USECASE SPECIFIC CONTENT
Credit: Heather Leslie

25. Templates
2

26. Are information models enough?
•Sure, if we’re okay with making 100k models,
one for each diagnosis, lab result, symptom, …
•Sure, if we never want a list of all the patients
who had viral lung diseases
•We need something more: Terminologies
3

27. Terms/knowledge about
health and healthcare:
Terminologies
Vocabularies,
classifications,
ontologies; ICD-10,
SNOMED CT, ICF
Framework for information
about single individuals:
Information
models
Information structure;
openEHR archetypes, FHIR
resources
Rules to be applied to
recorded information:
Inference models
Rules and knowledge bases
used in decision support
and alert systems.
Some overlap
The things that actually
happen in healthcare:
Process models

28. Terminologies?
•Controlled vocabularies
•Classifications
•Ontological thesauri
3

29. Controlled vocabularies
•Flat lists of coded concepts
•Examples: code sets from hl7.org or volven.no
3

30. Classifications
•Hierarchies
•Examples: ICD-10, ATC
3

31. Ontological thesauri
•Polyhierarchies with associated attributes
•Synonyms
•Some are combinatorial
•Examples: SNOMED CT,
ICNP
3

32. 3

33. Terminologies vs information models
Information models can be said to
describe the "questions"
Terminologies can give (some of) the
"answers"
Complementary concepts
ICD_10::L40.0::Psoriasis vulgaris
and
SCT_2015::74757004::Skin structure of elbow
SCT_2015::6736007::Moderate
???

34. Where terminologies shine
•Hundreds of thousands of concepts
–Diagnoses, symptoms, lab results,
body structures, organisms, procedures, …
•Inference based on relations between concepts
3

35. Relation based inference
3

36. Relation based inference
4

37. Where terminologies don’t shine
•Context
•Quantitative data types
•Complex concepts
4

38. Context
• "Let’s just chuck the codes
in here so we can bill for this
cancer treatment!"
• 15 years later, from the brand new Dr. Google:
– "Ma’am, I’m sorry to tell you you have ovarian cancer."
– "What!? They were taken out 15 years ago!”
• Diagnosis code had no date to show when it was valid…
4

39. Quantitative data types
•«Wouldn’t it be really nice to just have a code
for the number of the pregnancy the woman is
in…?"
•"Yeah. 10 ought to be
enough for anybody."
Famous last words…
4

40. Complex concepts
•Combinatorial explosion
–"Every kind of rash for every skin area"
–Every combination of oral glucose challenge
⇒ 601 LOINC "glucose" codes:
•Postcoordination may
mitigate, but beware…
4

41. Grey areas
•Small value sets
•Some contextual information
–Actual diagnosis vs. tentative vs. risk vs. exclusion
vs. family history
•Consistent use is hard, and not always appropriate
–Different use cases will have different requirements
4

42. Summary
• Structure is important, but not always appropriate
• Clinicians must drive clinical modelling
• Information models must be shared
• Terminologies are necessary additions to information models
• Grey areas -> pragmatic choice based on requirements
More info:
• Videos of one day seminar in Sweden 2015: http://goo.gl/6Ibbkf