SNOMED CT in the clinical data standards landscape: Where does it fit and how should we use it? Robert Hausam, Hausam Consulting LLC SNOMED CT 2019 -seminaari (28.3.2019)

1. SNOMED CT in the Clinical
Data Standards Landscape
Where Does it Fit and How Should We Use It?
Robert Hausam MD
2019-03-28

2. 2
Puhun vain vähän suomea
I only speak very little Finnish
Hyvää päivää
Good afternoon

3. Who am I?
◼ Rob Hausam MD
◼ Consultant in Clinical Informatics
◼ Family Physician, Electrical/Computer Engineer
◼ Active in HL7 and SNOMED International (IHTSDO)
➢ Co-chair of HL7 Vocabulary and Orders and Observations Work
Groups
➢ FHIR Core Team member, Co-lead FHIR Terminology Services
Connectathon track
➢ HL7 Co-lead of SNOMED on FHIR project (joint SNOMED Int. & HL7)
3

4. PRINCIPLES AND POSSIBILITIES
Clinical Data Standards Landscape
4

5. Two Standards Types
◼Terminology Standard
➢ Terminology Model
◼Information Standard
➢ Information Model
But wait a minute …
Isn’t terminology used to code information?
5

6. Terminology and Information
◼ Questions
➢ Are terminology and information standards really different
kinds of things?
➢ Or are they the same kind of or closely related things?
◼ Actually, both are true
◼ So, can we use the standards for terminology and
information together?
6

7. The simple (obvious) answer
◼ Sure, just use the information and terminology standards
together
➢ For example, SNOMED CT (pre-coordinated) codes (or LOINC, ICD-
10, etc.) are used to populate coded elements in HL7 FHIR (or HL7
CDA, HL7 V2, openEHR, etc.)
◼ All is good, right?
7

8. The complex (real) answer
◼ Well, what about:
➢ Overlap in meaning between information model element and
terminology concept(s) (including expressions)
◼ Potential for redundancy or conflict, which may impair clinical safety
➢ Information model elements (attributes) may modify the default
assumptions that determine the meaning of a SNOMED CT concept
➢ The information model elements and terminology concepts may have
been created with different assumptions that don’t align (e.g. different
granularity, etc.)
8

9. The complex (real) answer
◼ This is especially true with a large, expressive terminology
like SNOMED CT
◼ In HL7 and in SNOMED this may frequently be referred to as
the “TermInfo” problem
➢ HL7 Version 3 Implementation Guide: TermInfo - Using SNOMED CT
in CDA R2 Models, Release 1
http://www.hl7.org/implement/standards/product_brief.cfm?product_id
=418
➢ The same or similar issues occur with other information model
standards – HL7 V2 and FHIR, openEHR, etc.
9

10. So why do we have both?
◼ Terminologies have models
➢ SNOMED CT Machine Readable Concept Model (MRCM)
◼ Information models have terminology
➢ Element (attribute) names (FHIR, V2, openEHR, other)
➢ Model-specific codes or enumerations (e.g. FHIR code
systems
◼ So what if we use only one of them – wouldn’t that be
simpler?
10

11. Terminology standard only
◼ Could we use only a terminology standard like SNOMED CT
and represent all of the needed clinical data that way?
◼ Maybe?
➢ You certainly can construct complex post-coordinated expressions
that can represent clinical statements
◼ But probably not – what about:
➢ Numeric values – can you create codes for all of those needed?
◼ Concrete domains help with this, but we’re not quite there yet
➢ Dates and times?
11

12. Terminology standard only
◼ How would you transmit and store this data?
◼ As a stream of SNOMED CT codes and expressions, without
additional organizing structure(s)?
◼ That possibly might work, and people have thought about it
and have worked on that or similar ideas, but it hasn’t gained
popularity yet …
12

13. Information standard only
◼ This could be done, but:
◼ You have to have something to put in the “buckets” (data
elements/attributes) for data instances
◼ With no external terminologies to rely on, you have to
(hugely) “re-invent the wheel”
➢ Massive maintenance burden
➢ Overall likely poor quality – even with good people involved, many will
be out of their area of expertise with terminology, leading ultimately to
inadequate quality control and review and less than optimal results
13

14. Terminology and Information
◼ Questions
➢ Are terminology and information standards really different
kinds of things?
➢ Or are they the same kind thing?
◼ Actually, both are true
◼ They approach solving a common set of issues from
different perspectives
◼ And these standards can (and should) work together
14

15. So what if we combine them?
◼ Could you do that – combine the terminology and
information standards together in a single
representation, and avoid some of these problems?
◼ Well, yes, in theory you could
◼ But also no, practically you probably won’t be able to
(at least not yet)
15

16. So what if we combine them?
◼ One way could be with RDF (Resource Description
Framework
➢ This could be the “Holy Grail” of clinical data standards
➢ Or maybe “One standard to rule them all”? ☺
➢ Information structure and terminology in a single unified
model, allowing seamless reasoning across both!
➢ But we aren’t there yet, except mostly in relatively simple
mocked-up examples 
16

17. SNOMED CT WITH CURRENT AND
EMERGING INFORMATION
STANDARDS
Clinical Data Standards Landscape
17

18. Which information standards?
◼ HL7 Standards
➢ Version 2
➢ Version 3
➢ CDA R2 (and soon to be published R2.1)
➢ FHIR
◼ openEHR
◼ Others?
18

19. HL7 V2 and V3
◼ HL7 Version 2
➢ Widely used, especially in laboratory messaging
➢ Quite old (since 1989!)
➢ Can use SNOMED CT, but doesn’t offer complex terminology
capability
◼ HL7 Version 3
➢ Based on the Reference Information Model (RIM)
➢ Coded data types designed for complex, modern terminologies
➢ Has only achieved limited use (e.g. Canada and a few other places)
19

20. openEHR
◼ openEHR (CEN EN 13606) (ISO 13606-5:2010)
➢ Based on ‘Archetypes’
➢ Active but somewhat limited user community and implementation
base (considerable activity in Australia and a few other places)
➢ Can handle complex, modern terminologies reasonably well
➢ Possible competitor for HL7 FHIR?
◼ We’ll have to see, but so far seems to be little sign of this
20

21. HL7 CDA R2
◼ In widespread use worldwide
◼ Based on V3 and the RIM
➢ Modeling is generally a good thing, but it can be overly complex!
➢ Design by constraint
◼ Focused on the document paradigm
◼ Coded data types
◼ Soon to be published updated CDA R2.1 version
➢ Backward compatible with existing data
21

22. HL7 CDA R2 Disadvantages
◼ Uses older Data Types R1 specification
➢ Coded data type (CD) allows qualifiers, but not arbitrary
compositional grammar expressions
➢ Therefore only supports simple, single level post-coordination
◼ Has little associated infrastructure
◼ There is no terminology service specification!
22

23. SNOMED CT where in CDA?
◼ Observation and Procedure code and value
➢ Laboratory, pathology, imaging results, allergies, conditions,
problems, concerns, procedures, etc.
➢ In Observation code is the question, value is the answer
◼ Need to decide how to split them up if both are coded!
◼ Observation and Procedure targetSiteCode
➢ Specify where the observation or procedure occurred
◼ Others
23

24. SNOMED CT in CDA Example
Osteoarthritis of the right knee
24

25. HL7 FHIR
◼ The newest and most active (emerging) HL7 standard
◼ Recently (December 2018) published FHIR Release 4 (R4),
with first normative content
➢ “normative” = “stable” (at least no changes without implementer
community consultation and approval)
➢ http://hl7.org/fhir/R4/
◼ Specification is designed for implementers!
◼ Not based on the RIM or another underlying model
➢ But patterns are used to encourage modeling consistency
25

26. The acronym
◼ F – Fast (to design & to implement)
➢ Relative – No technology can make integration as fast as we’d like
◼ H – Healthcare
➢ That’s why we’re here
◼ I – Interoperable
➢ Ditto
◼ R – Resources
➢ Building blocks – smallest unit of data exchange
26

27. Paradigms
◼ FHIR supports 4 interoperability paradigms
27
REST Documents
Messages Other
What should
you use when?

28. REST
◼ Simple, out-of-the-box interoperability
◼ Leverage HTTP: GET, POST, etc.
◼ Pre-defined operations
➢ Create, Read, Update, Delete
➢ Also: Read Version, Search (resource/type/server), History
(resource/type/server), Capabilities, Patch, Batch & Transaction
28
Rest

29. Code System
◼ SNOMED CT / LOINC / ICD-10
◼ RxNorm, NDF-RT, ICPC, ICF, CPT,
CVX, NUCC HCPT, ATC, ANZSCO
(+ 100s more)
◼ HL7 V2 tables, V3 code systems
◼ A drug formulary
◼ Options for a config table in an
application
◼ A list of enums in a java class
◼ Country codes (ISO 3166)
29
Code System
Defines a set of
concepts with a
coherent meaning
Code
Display
Definition
e.g. SNOMED CT

30. Value Set
◼ “European country codes”
◼ “The LOINC codes that I use”
◼ All LOINC order codes
◼ A particular SNOMED CT hierarchy
◼ Substance codes plus “No known
allergy”
30
Code System
Defines a set of
concepts with a
coherent meaning
Code
Display
Definition
e.g. SNOMED CT
Value Set
A selection of a set
of codes for use in
a particular context
e.g. “SNOMED CT
fracture codes”

31. Terminology Binding
31
Code System
Defines a set of
concepts with a
coherent meaning
Code
Display
Definition
e.g. SNOMED CT
Value Set
A selection of a set
of codes for use in
a particular context
e.g. “SNOMED CT
fracture codes”
Binds
Element Definition
Data element, binding
characteristics and value
set reference
e.g. Condition.code

32. FHIR Coded Data Types
32

33. Coded Data (instance)
There is not a reference from an instance of
coded data directly to a value set (except by
the valueset-reference extension)
33
Code System
Defines a set of
concepts with a
coherent meaning
Code
Display
Definition
e.g. SNOMED CT
Value Set
A selection of a set
of codes for use in
a particular context
e.g. “SNOMED CT
fracture codes”
Binds
Element (instance)
Coded Data Type
code/
Coding/
CodeableConcept
e.g. 263204007 |Fracture of
shaft of ulna|
Element Definition
Data element, binding
characteristics and value
set reference
e.g. Condition.code

34. SNOMED CT where in FHIR?
◼ Condition and Allergy code
➢ Conditions, problems, concerns, allergies, etc.
◼ Observation code and value (like CDA)
➢ Code is the question, value is the answer
◼ Need to decide how to split if both are coded!
➢ Laboratory, pathology, imaging results, etc.
◼ Procedure and Observation bodySite
➢ Specify where the procedure or observation occurred
◼ Others
34

35. FHIR SNOMED example
Coded allergy to cashew nuts (JSON)
35

36. FHIR SNOMED example
(post-coordinated)
Condition: “Appendicitis” (JSON)
36

37. FHIR Terminology Service
◼ There’s a lot of complexity with coded data:
➢ Code Systems
➢ Value Sets
➢ Binding data elements to value sets
◼ Many (or most) applications are much simpler
➢ List of codes and displays in some table structure
➢ This is a known problem
37

38. Terminology Service Rationale
◼ Delegate the complexity to specialist software
◼ Provide a set of services that do what applications need
◼ It becomes easy to write applications that do terminology
well
38

39. Application Needs
◼ Give me a list of codes
➢ e.g., to populate my dropdown list
◼ Is this code valid?
➢ e.g., is the code that I received from an outside source a member of
the required value set?
◼ How do I display a code?
➢ e.g., I need to show the preferred display term for my application
context
39

40. Application Needs
◼ Translate this code to a different code system
➢ e.g., I coded the diagnosis in SNOMED CT and now I need to submit
the claim in ICD-10
◼ Integrate terminology search into my application
➢ e.g., my type-ahead search to enter data into the allergy list needs the
value set expansion for the list of codes that should be included
40

41. Terminology Service
Operations
◼ ValueSet
➢ $expand
➢ $validate-code
◼ CodeSystem
➢ $lookup
➢ $subsumes
➢ $find-matches
➢ $validate-code
◼ ConceptMap
➢ $translate
➢ $closure
41

42. SMART on FHIR
42
MU-oriented
FHIR Data Profiles
REST API
OAuth2
Underlying Health IT Systems
Web AppsMobile Apps
Your system here.

43. CDS Hooks
43

44. USING SNOMED CT
Clinical Data Standards Landscape
44

45. Possible Uses of SNOMED CT
◼ Now that you have SNOMED CT in Finland, where and how
can you use it?
◼ First steps
➢ Coded clinical problems (problem list) in EHR
◼ Realize the vision of the problem oriented record (Larry Weed 1960’s)
◼ Track problems over time based on SNOMED codes
◼ Data analysis and reporting using SNOMED hierarchy
➢ Pathology Reporting
◼ Already using legacy SNOMED codes
◼ Now transition to the improved and expanded codes and capabilities
45

46. Possible Uses of SNOMED CT
◼ Possibilities for the future?
➢ Coding services (API) supporting SNOMED CT content
◼ Reference sets for Finland
◼ Finland SNOMED CT extension?
◼ Much more to further explore!
46

47. Questions?
Rob Hausam
rob@hausamconsulting.com
Connect with the FHIR community:
FHIR Zulip chat terminology stream
https://chat.fhir.org/#narrow/stream/terminology
Finnish PHR
https://chat.fhir.org/#narrow/stream/179222-finnish-PHR
47