View
213
Download
0
Category
Preview:
Citation preview
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Welcome and introductions
2
What are you hoping to get out of this afternoon?
What we expect you already know
© Global eHealth Collaborative 2016
Preface
3
This is the first time this particular material has been presented, and it it is still a work in progress
FHIR is still a DSTU and is changing
The area of terminology binding is rapidly changing
Many of the topics discussed here are still on the “cutting/bleeding edge” — there are open issues and will likely have changed even since these slides were put together early this week.
We solicit audience input
Examples in these slides range in maturity from FHIR ‘0’ through ‘3’ — they are meant strictly as examples…
Most examples are drawn from DSTU2 except when otherwise noted
© Global eHealth Collaborative 2016
Acknowledgements
4
The authors wish to thank the International Health
Terminology Standards Development Organization (IHTSDO)
and Health Level Seven International for access to their
documentation and other materials.
Graham Grieve and Lloyd McKenzie for their contribution.
© Global eHealth Collaborative 2016
What we expect you to already know
5
General knowledge of FHIR
Ability to read XML and JSON
Basics of SNOMED CT
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Intended outcomes for today
6
Identify roles SNOMED CT plays in FHIR
Know how to find and understand SNOMED CT references in the current FHIR
specification
Describe when SNOMED CT should be used with FHIR
Recognize situations when SNOMED CT can be used “out of the box”
Describe mechanisms that define SNOMED CT value sets for FHIR profiles and extensions
Describe process to define a map between existing data and SNOMED CT concept codes
Describe some of the issues that may be encountered in the process of mapping
Describe several approaches to determining whether required concepts exist in SNOMED
CT
Describe the process for requesting new SNOMED CT concepts for use in FHIR
Introduce semantic model binding in FHIR
© Global eHealth Collaborative 2016
Goal of this session 1. To understand the aspects of SNOMED CT that are referenced in the
FHIR spec
2. To understand when and how SNOMED CT concept codes and compositional grammar expressions can be used in FHIR:
Value Set definitions
Data Instances
Profile terminology mapping (meaning)
7
© Global eHealth Collaborative 2016
Presentation Outline
Roles SNOMED CT plays in FHIR
Coded Content in FHIR
Value Set Definitions in FHIR
Issues and things to consider
Mapping
The Semantic Gap
Model bindings and FHIR
Questions and Issues
8
© Global eHealth Collaborative 2016
Roles of SNOMED CT in FHIR Representation of terminology in FHIR
Representation of SNOMED CT in FHIR
Selecting codes from a SNOMED CT value set
Mapping to and from a SNOMED CT value set
SNOMED CT Compositional Grammar and FHIR
SNOMED CT Expression Constraint Language and FHIR
10
© Global eHealth Collaborative 2016
Roles that SNOMED CT plays in FHIR
The representation of concept codes in FHIR data records
The representation of value sets in FHIR resource definitions
Associating FHIR resource definitions with semantics using
terminology
11
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
When SNOMED CT should be used in FHIR?
12
Choice of code system depends on
Use Case
why are you collecting the data?
need for computable meaning over time?
need to aggregate according to national rules? (ICD…)
What are you representing
the terminology or the information model requirement
Type of information
clinical data (SNOMED CT / LOINC)
financial data
authority data in EHR
Is the concept available as a resource in FHIR?
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Questions to ask …. HL7 Standards Developers…
Development International
Use of SNOMED CT content is freely available – you don’t need a
license (covered by MOU)
Publication in documents and repositories
Development National Affiliate
Requires license
No licence required to convert from HL7 published SNOMED CT
content to local codes to publish local implementation guides
13
© Global eHealth Collaborative 2016
Guides available
HTA Policies and Guidance Licensing V1.0
HTA Policies and Guidance currency of value set content V1.0
14
https://www.hl7.org/special/committees/termauth/docs.cfm
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Questions to ask ….. Users Do you have a license?
Yes – use away….
No
Are you using SNOMED CT in a country which is a national member of
IHTSDO?
Yes
Get a license from your National Release Centre and use away
No
Get a license (from IHTSDO which may have a charge) and use away
15
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Which Version of SNOMED CT? HL7 International Specifications
IHTSDO International Release most current version
If content you need is not there?
If it is in a national extension
Request permission to use the national extension as the basis
Inform HL7 international Terminology Authority (HTA) to request
this content in the international release.
If not – Ask HL7 International HTA to request content
16
© Global eHealth Collaborative 2016
HL7 Affiliate in a National Member Country of IHTSDO
Affiliate is required to have a license
License is obtained from your National Release Centre
With a license the affiliate may
Publish standards for use in that nation
All uses of the standard must have a license
Content requests
Go to the National Release Centre
18
© Global eHealth Collaborative 2016
HL7 Affiliate in a Non IHTSDO Member Country
If publishing content which includes SNOMED CT
Must be done under license obtained from IHTSDO
In which case operation is as per an IHTSDO Member Country
If not publishing – replace with local content
Method used to develop local content and the relationship to
international content is up the HL7 Affiliate
19
© Global eHealth Collaborative 2016
Jointly Developed Standards
Standards developed by groups of HL7 Affiliates (IHTSDO
Member and Non Members)
Awaiting advice from IHTSDO
20
© Global eHealth Collaborative 2016
Translations The HL7 Affiliate is responsible for quality control of translated
content
Translation
If the term is in your national release translation – use the translation
If the term required is not yet translated – make a request directly to your national release centre to discuss the process to be used.
If the language you require is not available contact HTA
21
© Global eHealth Collaborative 2016
Maps Published by SNOMED CT
May be used by license holders, but are not available to others
Development for local use
managed through collaboration between IHTSDO National
Release Centres and the HL7 Affiliate
Where there is no national release centre managed by the affiliate
– with great care!
22
© Global eHealth Collaborative 2016
Coded concepts in FHIR data records
FHIR Coded concept Data Types
Code - stand-alone code
Coding - system, version, code, display, etc.
CodeableConcept - collection of codings + plain text
Quantity - (special case - not further discussed)
http://www.hl7.org/FHIR/terminologies.html
24
© Global eHealth Collaborative 2016
FHIR code data type example
www.hl7.org/FHIR/observation-example-bloodpressure.json.html
http://www.hl7.org/FHIR/observation-example-bloodpressure.xml.html
XML
JSON
26
© Global eHealth Collaborative 2016
FHIR code data type example (continued)
27
https://hl7-fhir.github.io/observation-example-bloodpressure.ttl.html
RDF (proposed)
© Global eHealth Collaborative 2016
FHIR Coding data type
http://www.hl7.org/FHIR/snomedct.html
29
© Global eHealth Collaborative 2016
SNOMED CT Version Identifier
30
http://www.hl7.org/FHIR/snomedct.html
© Global eHealth Collaborative 2016
SNOMED CT Version Identifier For Extensions
31 http://www.hl7.org/FHIR/snomedct.html
Distribution / Edition Identifier:
http://snomed.info/sct/900000000000207008 — SNOMED CT International Edition
http://snomed.info/sct/32506021000036107 — SNOMED CT Australian Distribution
http://snomed.info/sct/11000160102 — SNOMED CT CIMI Extension
© Global eHealth Collaborative 2016
SNOMED CT Version Identifier for Versions
32 http://www.hl7.org/FHIR/snomedct.html
Full versioned identifier:
http://snomed.info/sct/900000000000207008/version/20160131 — SNOMED CT International Edition,
January 2016 release
© Global eHealth Collaborative 2016
FHIR Coding data types in a resource definition
33 http://www.hl7.org/FHIR/imagingstudy.html
© Global eHealth Collaborative 2016
FHIR Coding data type example
34
http://www.hl7.org/FHIR/imagingstudy-example.xml.html
XML
JSON
http://www.hl7.org/FHIR/imagingstudy-example.json.html
© Global eHealth Collaborative 2016 35
FHIR Coding data type example (cont)
RDF
https://hl7-fhir.github.io/imagingstudy-example.ttl.html
© Global eHealth Collaborative 2016
FHIR CodeableConcept data type
Internal Codes
Any LOINC Code
Any code (no recommendation) 38
© Global eHealth Collaborative 2016 39
FHIR CodeableConcept data type example
http://www.hl7.org/FHIR/diagnosticreport-example-f202-bloodculture.json.html
JSON
© Global eHealth Collaborative 2016 40
FHIR CodeableConcept data type example
http://www.hl7.org/FHIR/diagnosticreport-example-f202-bloodculture.json.html
JSON
Questions:
1. Is this asserting that the two codes are
synonyms?
2. Can an application safely use whichever
code it is equipped to deal with?
© Global eHealth Collaborative 2016 41
FHIR CodeableConcept data type example
http://www.hl7.org/FHIR/medicationexample2.json.html
© Global eHealth Collaborative 2016 42
FHIR CodeableConcept data type example
http://www.hl7.org/FHIR/medicationexample2.json.html
Questions:
1. Is this asserting that the two codes are
synonyms?
2. Can an application safely use whichever
code it is equipped to deal with?
© Global eHealth Collaborative 2016 43
FHIR CodeableConcept data type examples
http://www.hl7.org/FHIR/medicationexample2.json.html
Questions (continued):
…
3. What is going on here?
© Global eHealth Collaborative 2016
What of version?
http://www.hl7.org/FHIR/datatypes.html#Coding.
45
© Global eHealth Collaborative 2016
US Edition
SNOMED
CT
Internation
al
74400008 | Appendicitis |
46
Versions / Editions
CIMI
SNOMED CT
International
74400008 | Appendicitis |
41000160101 | Good Concept |
1072931000119109 | Non-traumatic partial tear of right
rotator cuff (disorder) |
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
SNOMED CT Compositional Grammar
50
A formal language, specific to SNOMED CT, that is used to represent formal
logic description of the concept referent.
One way of representing the formal (description logic) aspect of a SNOMED
CT concept description
Can be interpreted as representing the set of entities “in the real (clinical)
world” that meet the defining criteria.
Does NOT represent a set of SNOMED CT concept identifiers (!) …
… in fact, there may be no SNOMED CT concept identifier defined whose
referents meet a given CG description
http://ihtsdo.org/fileadmin/user_upload/doc/download/doc_CompositionalGrammarSpecificationAndGuide_Current-en-US_INT_20150708.pdf?ok
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Compositional Grammar and “coordination”
51
Pre-coordinated — a compositional grammar expression that has is associated
with a SNOMED CT Concept Identifier
Post-coordinated — a compositional grammar that is not necessarily
associated with a SNOMED CT Concept identifier
© Global eHealth Collaborative 2016 52
SNOMED CT Compositional Grammar Examples
The set of all right hip joints:
The set of all excision procedures having a direct site of the appendix structure
and a priority of emergency. Any emergency excision on the appendix.
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
SNOMED CT Compositional Expressions
53
Need to consider:
• Semantics — how do you constrain the set of expressions that are allowed
• Logic aspect — in DL, there is a huge difference between “the set of all things
that have the following properties” and “Specimen X has property Y”. It may
be blurred in SNOMED CT, but we still need to consider the ramifications
• Search, query and granularity — how do you search for “laterality left” when
it is contained (or inferred from!) a compositional expression
© Global eHealth Collaborative 2016
Value Set Strengths in the Core FHIR Spec
Value set references
(total / unique / includes SNOMED CT / core includes SNOMED CT)
Required: 798 / 281 / 2 / 1
Extensible: 199 / 89 / 13 / 2
Preferred: 140 / 101 / 43 / 8
Example: 587 / 271 / 96 / 87
62
© Global eHealth Collaborative 2016 68
Defining Value Sets in FHIR - Data Element Sheet
Type Link to entry on Bindings worksheet
This slide shows an example entry in a FHIR resource definition spreadsheet.
See: http://wiki.hl7.org/index.php?title=FHIR_Spreadsheet_Profile_Authoring) for more detail.
© Global eHealth Collaborative 2016 69
Defining Value Sets in FHIR
FHIR Bindings Worksheet
Name - globally unique Type - one of:
• code list - (enumeration) defined in spreadsheet
• value set - name of a FHIR value set resource instance in same
directory
• reference - reference to external standard
• Required
• Preferred
• Extensible
• Example
© Global eHealth Collaborative 2016 72
Defining Value Sets in FHIR
FHIR Bindings Worksheet
External value set reference
© Global eHealth Collaborative 2016 74
Ways to define SNOMED CT Value Sets Lists of specific codes (similar to Coding)
By subsumption (all ‘isA’ descendants + the root concept)
By reference set — the identifier of a SNOMED CT Reference Set
As an Expression Constraint
Set operations on the above
… (there are several other alternatives in the ValueSet Resource which we
choose to ignore)
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
SNOMED CT Expression Constraint Language
75
A formal language that describes a set of SNOMED CT Concept Identifiers
• The interpretation of an Expression Constraint Expression depends on the
release / version / extension (“substrate”) to which it is applied
• One of many possible value set definition languages that can be used in the
FHIR environment.
http://ihtsdo.org/fileadmin/user_upload/doc/download/doc_ExpressionConstraintLanguageSpecificationAndGuide_Current-en-US_INT_20150820.pdf?ok
© Global eHealth Collaborative 2016 76
SNOMED CT Expression Constraint Language
Examples
77400008 | Appendicitis | OR 90176007 | Tonsillitis |
The concept identifiers for appendicitis or tonsillitis:
All concept identifiers that represent descendants of disorder of lung and
have an associated morphology of edema
All concept identifiers that represent descendants of clinical finding,
have a finding site of pulmonary valve structure or one of its descendants and
have an associated morphology of stenosis or one of its descendants
have an associated morphology of edema
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
SNOMED CT Expression Constraint Grammar and FHIR
77
SNOMED Expression Constraint Grammar can be used to define:
“Extensional” SNOMED CT value sets — (lists of concepts)
“Intensional” SNOMED CT value sets using a grammar that is very expressive
in the SNOMED CT context
The contents of a SNOMED CT Simple Reference Sets — when interpreted
against a given substrate
The contents of a SNOMED CT Query Specification Reference Set (or
equivalent), which can be interpreted against any substrate
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Value Set Definition Issues in SNOMED CT
78
1. You can use the FHIR value set definition grammar directly
2. You can use the SNOMED CT Expression Constraint Grammar within the
FHIR value set definition
3. You can use the URI of a SNOMED CT Query Specification Refset, which
resolves to a Value Set
4. You can use the URI of a SNOMED CT Simple Refset, which is (arguably)
the result of a resolution
5. Some mixture of the above
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
SNOMED CT / FHIR Value Set decision points
79
SNOMED CT Expression Constraint Language and the FHIR Value Set Resource have considerable
overlap. The choice of which to use and when is not easy.
• Are your value set definitions specific to a given application or to be generally available?
• Are your value sets exclusively for use in the FHIR environment or will they have other
applications?
• Do you need the full expressivity of the SNOMED Model (e.g. role groups, site, etiology,
laterality, etc.?)
• Are you allowed to use all of SNOMED?
• Are you able to mint your SNOMED Value Set (Concept) Identifiers?
• Do you have a workflow that enables the submission of new concept identifiers and their
descriptions to a national or international body?
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Additional things to consider with FHIR value sets
80
Should your profile really allow more than one “Coding” in a CodedEntry? If
so, what do multiple elements mean?
They should NOT represent compositional semantics
Should they include information that is explicit elsewhere in the document?
Should you leave the coding open-ended (e.g. any Finding or Procedure) or
should you lock it down to an agreed-upon set of codes?
Should you lock in a specific extension / release / version?
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Known Issues
Increasing use of maps
Need for HL7 to publish (reference) maps to
Support conversion to improved value set content and
harmonisation across products (V2, FHIR, CDA)
Support conversion to nationally required representations
Risks of map use – dependent on use case
82
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
What is mapping? process of defining
a relationship between
concepts in one coding system to concepts in another coding system
in accordance with a documented rationale,
for a given purpose.
Reference: ISO TR 12300
83
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Reasons to map
Data re-use
Statistical
Research
Planning and policy
Public health reporting
Interoperability (clinical use and data sharing)
Migration of ‘old’ system/data
Historical analytics
84
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
What mapping is NOT A low risk, low cost approach to interoperability
A one off exercise (except for migration)
A simple task
Mapping skills and skills in source and target are necessary
85
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Map quality measures in development ISO work item
with collaboration of HL7 International and IHTSDO
Technical Specification – to establish and test conformance
Define quality requirements for map sets to Establish quality determinants of a map
Assess quality of a map for a purpose
Guide decision makers in map project requirements and processes
Establish pathways to improvement
Based on ISO TR12300 – Principles of mapping between terminological systems
86
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Determinants include Terminology resource capacity
Equivalence achieved
Development Methodology
Team skills
Implementation functionality
87
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Example – of measures
Type 1 – Level of quality
0 = best - high quality
4 = worst – low quality
Ability to sum measures to obtain overall score with low
being the highest quality.
Type 2 – outlier acceptability
Define acceptable quality limit for purpose
Define % outside acceptable limit which can be tolerated
88
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Measures – Row Equivalence 0 = equivalent meaning
1 = source is totally included in target
2 = source is partly included in target
3 = source is mapped but there were many options and it is a best comparison rather than an actual correspondence
4 = no map possible
Method - Collect equivalence for every concept mapped
Measure 1 - Average equivalence for the Map Set
Measure 2 % X or over
89
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Build Measure – Documentation and Process
0 1 2 3 4
Use Case Clear, specific
,documented
Clear, general,
documented
Clear,
documented
Documented Not Documented
Rationale of
decisions
Consistent,
Documented
Applied
Consistent
Documented
Documented
Applied
Documented Not Documented
Methodology Documented
Equivalence measured at
0-4 minimum
Process for review
Equivalence
measured
Documented
Process for review
Documented
Process for
review
Documented Not Documented
90
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Build Measure – Validation
0 1 2 3 4
% of validation 100% 80% or more 60% or more 40% or more Less than 40%
Method of validation Blind double mapping
Manual review of
results
Validation for purpose
Double mapping
Manual review of
results
Validation for
purpose
Manual review
of results
Validation for
purpose
Manual review
of results
No validation
methodology
91
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Build Measure – Tools
0 1 2 3 4
Level of
comparison
Lexical – offering
alternatives,
Semantic model applied
Lexical – exact
match
Semantic model
applied
Lexical – offering
alternatives
Lexical exact Not applied
Rules applied Data normalization
assessment
Data normalization
undertaken
Source/Target rules
integrated
Data normalization
undertaken
Source / Target
rules integrated
Data
normalization
undertaken
Basic rules
applied (i.e. age)
No rules or data
normalization.
92
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Build Measure – Skills
0 1 2 3 4
Target Skills Examined recent
knowledge of Target and
experienced in application
in use case
Knowledgeable about
use and experienced in
application n use case
Experienced in
application in
use case
Practical but not
extensive
experience in use
case.
Basic or little
knowledge or
experience
Source Skills Examined recent
knowledge of source and
experienced in application
in use case
Knowledgeable about
use and experienced in
application n use case
Experienced in
application in
use case
Practical but not
extensive
experience in use
case.
Basic or little
knowledge or
experience
Mapping process
skills
Examined recent
knowledge of map
processes
Prepare documentation
on rationale for decision
Knowledge of map
processes
Prepare documentation
on rationale for decision
Examined
recent
knowledge of
map processes
Prepare
documentation on
rationale for
decision
No experience
or training
93
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Governance Measure – Composition
0 1 2 3 4
Composition •Data Source
•Result Users
•Health Informatics Data
specialists
•Terminology Resource
•Map process
•Sponsor
5 of these 4 of these 3 of these 2 or less of these
94
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Governance Measure – Process 0 1 2 3 4
Process Documentation of
decisions
Decisions applied across
the map.
Equity of decision making
to support use case
Responsibility for final
decision
Documentation of
decisions
Decisions applied
across the map.
Responsibility for
final decision
Documentation of
decisions
Responsibility for
final decision
Responsibility for
final decision
No documented
process
Maintenance Process established
Identified currency
requirements for update
Maintenance team
established and resourced
Maintenance follows
build process
Procedures
established
Identified currency
Maintenance team
established and
resourced
Procedures
established
Identified currency
Procedures
established
No process
established
95
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Implementation Measure 0 1 2 3 4
Version Map, target and source
versions maintained in
the original data and
any messages
associated with the
data
Map, target and
source versions
maintained in the
original data
Target and source
versions maintained
in the original data
Details not maintained
in original data
Equivalence
maintained in the
map
Equivalence known
and communicated
Equivalence known Equivalence of mapped
data not identified
Communication Notification to user
that data was mapped
from original and the
map etc used.
Notification to the
user that the data
was mapped from
original
No notice of mapped
data
96
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Rules Measure
0 1 2 3 4
Source Rules required for accurate
representation for use case – rules
applied in map
Or
No rules required
Rules required – some
rules applied
Rules required – not
applied
Target Rules required for accurate
representation for use case – rules
applied in map
Or
No rules required
Rules required – some
rules applied
Rules required – not
applied
97
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Use of measures
For a given use case
Identify acceptable minimum required measures
Undertake quality measure review of the map
Compare results and map acceptability for purpose
Intended uses
Establish vendor conformance requirements
Establish ongoing improvement pathways
Provide quality and safety benchmarks to industry
98
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Use Case - changes measure required for
conformance
Include examples such as
Direct Clinical Use E.g.: equivalence 0 with max 1% outliers)
Administration / Financial
Public Health
Research
Service Planning E.g.: Equivalence 1 with max 10% outliers
99
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Mapping and FHIR
100
Mapping a resource to a local code system
Mapping from a local code system to a resource
May be SNOMED CT but could be other code systems
Publication method – being considered – not yet determined
Need to establish the metadata required and how this will be maintained
Possibly one off from old representation to new at the point of change
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Measuring quality
101
Document the purpose of the map
Clearly indicate if clinical use is part of that purpose or not
If rules have been used associated with how the code system is used (not the meaning but the coding rules). Eg X is not coded in case Y cause we can’t claim it.
Consider maintenance requirement and frequency
Consider equivalence required for purpose
For all or for some of the content
Publication details – include all of this metadata as well as the actual map which should include equivalence clearly defined for each individual map in the set.
© Global eHealth Collaborative 2016
Semantic interoperability – the holy grail
Not just sharing data
Sharing and ‘understanding’ meaning
103
© Global eHealth Collaborative 2016
Once data is in the record – it’s there for life Ability use computers to find clinical information for
Analysis
Clinical Decision Support
Automation of reporting
But….
104
© Global eHealth Collaborative 2016
Technology solutions
Complex clinical terminologies
Terminology servers
Terminology governance in the organisation for implementation
Terminology specification for shared data
Information Model use of terminology
Post-coordination
105
© Global eHealth Collaborative 2016 108
Hypertension as a diagnosis
38341003 Hypertensive
disorder, systemic arterial
© Global eHealth Collaborative 2016 109
Hypertension as a risk factor
38341003 Hypertensive
disorder, systemic arterial
© Global eHealth Collaborative 2016 110
Hypertension – excluded – not a diagnosis
38341003 Hypertensive
disorder, systemic arterial
© Global eHealth Collaborative 2016 111
Hypertension in Family History
38341003 Hypertensive
disorder, systemic arterial
© Global eHealth Collaborative 2016 113
Finding the line…
Terminology
Information Model
Semantic Gap
Ref: terminology, clinical models and queries combined,
Karlsson, Heather Leslie, Sundvall
© Global eHealth Collaborative 2016 114
Where do the pieces fit….. 18336000 Open Fracture of
upper limb
© Global eHealth Collaborative 2016 115
Where do the pieces fit….. 439987009 Open Fracture of
Bone
371195002 Bone structure of
upper limb
© Global eHealth Collaborative 2016 116
Hypertension in Family History
303071001
Person in the
family
439401001
Diagnosis
© Global eHealth Collaborative 2016 117
Working Together
373572006 Clinical finding
absent
439401001
Diagnosis
38341003 Hypertensive
disorder, systemic arterial
© Global eHealth Collaborative 2016 118
Problems to resolve Equivalence testing (work in HL7 and IHTSDO)
Pre-post coordination
– where to use or not to use
Management of terminology and knowledge resources
© Global eHealth Collaborative 2016
Boundary Problem
• consistency is hard
• use case changes the practical solution
• Clinical need
• Recording
• Re-use
119
© Global eHealth Collaborative 2016
HL7 TermInfo,
Defined many of the use cases
Suggestion - qualifiers in the model
works sometimes
Solutions emerging in
HL7 CIMI, IHTSDO and OpenEHR
120
© Global eHealth Collaborative 2016
Experience and learning will..
• decrease the semantic gap
• identify patterns for common solutions
• improve problem identification and specification
121
© Global eHealth Collaborative 2016
Model Bindings in FHIR
Semantics for FHIR modeling artifacts
122
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Semantics for FHIR Modeling Artifacts
123
Connecting the “meaning” of various artifacts with the defining components
that describe what they are about.
Semantic binding has always been on the FHIR roadmap, but it is just
beginning to solidify
Bridging the “Semantic Gap”
124
363787002 | Observable entity (observable entity) |
704327008 | Direct site (attribute) |
246501002 | Technique (attribute) |
424226004 | Using device (attribute) |
https://hl7-fhir.github.io/observation.html
© Global eHealth Collaborative 2016 125
246501002 | Technique (attribute) |
https://hl7-fhir.github.io/vitalsigns.html
75367002 | Blood pressure (observable entity) |
70665002 | Blood pressure cuff, device
37931006 | Auscultation (procedure) |
424226004 | Using device (attribute) |
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
Bindings
126
Provides semantic specialization
Allows model validation / alignment / discovery
It isn’t always obvious, for instance when something is a Condition vs. an
Observation in FHIR…
… also allows for alignment with other models
Validates value sets
Value set is a (sub) set of concept identifiers that classify under the target
126
© Global eHealth Collaborative 2016
Semantics for FHIR modeling artifacts Metadata
StructureDefinition.code
StructureDefinition.mapping
ElementDefinition.code
ElementDefinition.mapping
127
© Global eHealth Collaborative 2016
Possible StructureDefinition Bindings
131
“code”: {
“system”: “http://snomed.info/sct”,
“code”: “363787002”,
“display”: “Observable entity”
},
{
“identity”: “about”,
“uri”: “http://snomed.info/id/36378002”,
“name”: “Observable entity”
},
- or -
© Global eHealth Collaborative 2016 © Global eHealth Collaborative 2016
StructureDefinition and ElementDefinition code
132
Lloyd McKenzie (email - April 18): “StructureDefinition.code is
semantically identical to the
StructureDefinition.snapshot.element[1].code.” [or differential]
Map entries are different though. They represent relationships to
external artifacts for multiple elements as opposed to defining the
meaning of the overall model or a particular element within it. For
example, if StructureDefinition.code is set to blood pressure, your’e
saying “this profile *is* a blood pressure”, while, if you do a mapping,
you can say “this structure definition is somewhat similar to this
openEHR model of blood pressure and corresponds as follows.
© Global eHealth Collaborative 2016 135
Observation Elements as ElementDefinition
“code”: {
“system”: “http://snomed.info/sct”,
“code”: “363787002”,
“display”: “Observable entity”
},
{
“identity”: “about”,
“uri”: “http://snomed.info/id/36378002”,
“name”: “Observable entity”
},
- or -
© Global eHealth Collaborative 2016 136
Observation.device Element
“code”: {
“system”: “http://snomed.info/sct”,
“code”: “424226004”,
“display”: “Using device (attribute)”
},
What of: 70665002 | Blood pressure cuff, device | ?
© Global eHealth Collaborative 2016
Who is GeHCo?
Global eHealth Collaborative
Not for profit
Sharing and exposing expertise
Building solutions to share
www.gehco.org - more to come – be part of the solution!
138
Recommended