SNOMED Clinical Terms®
Post-coordinated Expressions
User Interface Issues and Options
IHTSDO Implementation SIG Webinar
by David Markwell
The Clinical Information Consultancy Ltd
[email protected]
www.cliniclue.com and www.clininfo.co.uk
© 2002-2010 The Clinical Information Consultancy Ltd (includes some material © 2002-2010 IHTSDO)
1
Overview
 Refresher about expressions
– What is an expression
– Pros and cons of post-coordination
 Issues with post-coordination
 Practical approaches to data entry issues
 Practical approaches to display issues
– Rendering post-coordinated expressions
SNOMED CT Expressions
A „SNOMED CT expression‟ is
 A collection of references to one or more
SNOMED CT concepts, used to express an
instance of a clinical idea
 Expressions can be used to represent:
– Instances of clinical information in electronic health
records
– Knowledge links in resources such as decision
support protocols and online reference materials
Expressions can be pre-coordinated or
post-coordinated
 Pre-coordinated expression
– A single ConceptId represents the required meaning
• Example
• 31978002
– (fracture of tibia)
 Post-coordinated expression
– A combination of ConceptIds represents a concept
• Example
• 31978002 : 272741003 = 7771000
– (fracture of tibia : laterality = left)
– In human readable form … “fracture of left tibia”
Expressions can exist in different forms
 Close-to-user form
– The concept or concepts selected by the user
• (or by a user-interface designer)
 Normal form
– The result of applying a set of logical rules that
transform different expressions with the same
meaning into a common comparable form
 Both these forms may include or exclude a
situation context wrapper
– If included this explicitly states the context of a
finding or procedure
Advantages of post-coordination
 Scope coverage and terminology size
– Coverage of scope to an adequate level of specificity does not
require every possible concept to exist
– Reduces the need for “combinatorial explosion” in concept
numbers to cover every eventuality
 Terminology maintenance
– The maintenance burden is related to terminology size
• Discussed further on next slide
 Structured data entry
– Ability to represent refined content is not dependent on specific
concept existing
– Expressions can be constructed in a consistent manner rather than
searching hundreds of similar terms for precisely the correct one
 Consistent retrieval
– Less dependency on modelling of individual concepts
• Discussed further on subsequent slide
Advantages of post-coordination
Terminology maintenance
 Maintenance burden is roughly proportional to
terminology size. This is due to:
– Requirements to add new content
• Accurate modelling and addition of synonymous terms
• Synonymous terms
• Translation adding terms in other languages
– Errors such as
• Ambiguity
• Non-synonymous terms (within or between languages)
• Inconsistent modelling
– Enhancements of the SNOMED CT Concept Model
• Which require some concepts to be remodelled
Note:
This rule applies to Extensions as well as the International Release
Advantages of post-coordination
Consistent retrieval
 Use of post-coordination make retrieval less
dependent on modelling of individual concepts
 For example:
– Accurate retrieval of the following pre-coordinated
expression is dependent on the accuracy and
specificity of the defined causative agent
• 91936005 | allergy to penicillin |
– In contrast, the following post-coordinated
expression explicitly identifies the substance
• 416098002 | drug allergy | : 246075003 | causative agent | =
372725003 | penicillin V |
Disadvantages of post-coordination
(Note: issues addressed in more detail on subsequent slides)
 Human readability, entry and display
– „Extreme post-coordination‟ leads to loss of natural terms
 Data entry
– Requiring users to select several items to build a postcoordinated expression may be a burden for entry of
common composite data items
 Storage
– Post-coordinated expressions have variable length so it
may be difficult to efficiently represent them in a database
table
 Retrieval
– Performance may be impaired by
• Storage issues that may prevent optimal indexing
• Complexity of testing query predicates against post-coordinated
expressions
Pre & post-coordination with SNOMED CT
 SNOMED CT supports both pre and post-coordination
– No absolute boundaries between them
 SNOMED CT enables computation of equivalence and
subsumption between pre and post-coordinated
expressions that have the same meaning
Addressing post-coordination issues
Human-readability
„Extreme post-coordination‟ leads to loss of natural terms
Example
If “appendectomy” is only represented as:
71388002 | procedure | : { 260686004 | method | = 129304002 | excision action | , 405813007 | procedure site - Direct | = 66754008 | appendix
structure | }
the word „appendectomy‟ is not present
Thus this does not support search by or display of the term clinical
users expect to see
 Clinical ideas that are associated with common names
(other than composites that could be derived from a
post-coordinated expression) need to be represented by
adding concepts to SNOMED CT
Addressing post-coordination issues
Concept model limits
 Clinical ideas that cannot be fully represented by a postcoordinated expression due to limitation of the
SNOMED CT Concept Model should be represented by
either:
– Adding concepts to SNOMED CT; or
– Using information model constructs to link expressions together
or to other related data
 The choice between these approaches depends on the
information to be represented. Only ideas that fit within
the scope and editorial guidelines applied to SNOMED
CT should result in addition of new concepts
Addressing post-coordination issues
Storage
 Post-coordinated expressions have variable
length so it may be difficult to efficiently
represent them in a database table
– Using the SNOMED CT grammar
• The shortest expression is 6 characters in length
• The length of an expression is theoretically unlimited
• Real examples exist with over 300 characters (using id‟s
only) or over 1,000 characters (including the term text)
 One way to address this is by using an
„Expression Repository‟
– This was the subject of my previous Implementation SIG
webinar
Addressing post-coordination issues
Data entry and rendering
 The “too many keystrokes” problem
– Multiple selections to build a post-coordinated
expression may be a burden for entry of common
composite data items
 The “human readability” problem
– Post-coordinated expressions may be hard to display
in a way that is easy to read and accurate
– These issues are the subject of the following slides in this
presentation
To do this …
… do you need to understand this …
… or just this
To record post-coordinated expressions
Do you need to fill in a form like this?
Date
10/10/2010
Disorder
Fracture of bone
Finding site
Neck of femur
Laterality
Left
Morphology
Fracture, open, displaced
Due to
Fall down stairs
To record post-coordinated expressions
You could simply type something like this and
have it coded
10/10/2010
Fell downstairs causing open displaced
fracture of left femur
… or perhaps even
10/10/2010
#lfem open displaced
Cause
fall stair
Data entry
20
Constraining searches
 Constraining searches by status
– Only show active Descriptions of active Concepts
 Constraining searches by subsets
– Language Subsets to avoid uncommon or foreign terms
– Realm Subsets to simplify or encourage selection of concepts
or used in a particular country, organization, or specialty
– Context Subsets to specify or order the valid Concepts for entry
in a particular field
 Rationalise multiple matches
– Multiple matching terms for same concept could be rationalised
by displaying only one match
– Matching concepts that are subtypes of another matching
concept may be hidden or organised in hierarchy tree under the
more general matching concept
One-phrase searches for
post-coordinated expressions
 There are various ways to make allow a single search
phrase to be extended to include candidate postcoordinated expressions
–
–
–
–
Previously constructed expressions renderings
Detecting common refining value terms
Concept model rationalized searches
Constrained model rationalized searches
One-phrase post-coordinated expression searches
Previously constructed expression renderings
 Store an automatic rendering of each post-coordinated
expression that is used
– Could be included in or joined to the Expression Repository
discussed in previous webinar
 Index these rendered terms
 Include these rendered terms in searches where
appropriate
Important Note
Store auto-generated rather than a user-entered terms
– User-entered terms could be a wrong match for the expression
and this would propagate the error
– Same maintenance and quality issues as arise from managed
content addition
One phrase post-coordinated expression searches
Common refining value terms
 Words, phrases and abbreviations that commonly represent
refining values can be identified
– E.g. Left, right, L, R, family history, FH, severe, mild, moderate, acute, chronic
 Where there is not match a search could automatically exclude
these words from the search key
 Matches without the refining value word would be displayed in the
search list with the missing word(s) appended
 Selection of these matches results in construction and storage of
an appropriate post-coordinated expression
One phrase post-coordinated expression searches
Concept model rationalized searches
 Searches phrases are split and searched
 The results of the searches are combined to identify
candidate post-coordinated expressions which
– Match the search criteria
– Are valid according to the Concept Model
 Post-coordinated rendering of these candidate
expressions are displayed for selection
Note
This is very challenging due to the range of combinatorial
possibilities in the search phrase and in the phase space of
possible valid post-coordinated expressions. It is probably not
tractable in its full form as described here but could work in a
constrained content
One phrase post-coordinated expression searches
Constrained model rationalized searches
 Searches phrases are split and searched
– Constraints limit the set of expected focus concept and
situations.
– Matches for these are identified first
 The unmatched residue of the search phrase is used to
search for refinement values that are valid within a
constrained view of the Concept Model
 Post-coordinated rendering of these candidate
expressions are displayed for selection
Note
This is challenging but depending on the constraint used should be
tractable for many common uses cases. It is a flexible evolutionary
extension of the “common refining terms” approach
Favourites and shortcuts
 A good user interface should allow commonly
used expressions to be entered using shortcuts
– Some of these may be built into the application
– Others should be user or department configurable
 Examples
– TET1 “170330007”
• First tetanus vaccination
– #LTIB  “31978002 : 272741003 = 7771000”
• Fracture of left tibia
Structured data entry forms
 User selection from a small list of possible
descriptions
 A context subset may specify a list of options
for a field
– Very short list – drop-down user selection
– Longer lists require constrained search facility
 Check boxes and other screen devices may be
associated with hidden coding options
 Entries of numeric or other values may be
labelled with appropriate concept identifiers
Structured data entry forms
80248007
86616005
Right Breast
Both Breasts
29
Enhanced interfaces for refinement
71620000
29627003
7771000
397181002
52329006
Auto-encoded indexing of text
Open comminuted fracture of the left tibia
fracture of tibia



associated morphology
fracture, open, comminuted
finding site
bone structure of tibia
laterality
left
Concepts chosen to index text
Computer program matches text to concepts via key word search
Human intervention needed to resolve ambiguities
Rendering
32
Viewing post-coordinated expressions
Do you want to see it looking like this?
373573001:{246090004=(361119006:42752001=414188008,
116676008=426718009,272741003=7771000)}
… or even like this?
For most uses the answer is “no”
… but there may be some exceptions
Viewing post-coordinated expressions
Do you want to see it in a form?
Date
10/10/2010
Disorder
Fracture of bone
Finding site
Neck of femur
Laterality
Left
Morphology
Fracture, open, displaced
Due to
Fall down stairs
Possibly to highlight important facets of information
… or to recreate a structured data entry form
Viewing post-coordinated expressions
Would it be useful to reconstruct text for display?
Open displaced fracture of neck of left femur
due to fall down stairs
In some cases this is feasible based on analysis of terms and
definitions but it would be hard to generalize this to all
combinations and rules would differ by language
Viewing post-coordinated expressions
 It could be useful to find the term for a concept
which is the equivalent of the post-coordinated
expression
– The term could then be displayed
 If there is no equivalent then the proximal
super-type of the expression could be used
– Only the differentiating refinements would needed to
be added to the selected term
Viewing post-coordinated expressions
Should the original text entered by stored linked to the
expression so it can be shown for human-readers?
Fell downstairs causing open displaced fracture of left femur
Human-readable rendering post-coordinated
expressions
Human readable renderings
 Authored text
–
–
–
–
Selected text
Extended text
Modified text
Parsed text
 Description text
–
–
–
–
–
Origin derived text
Verified derived text
Stored derived text
Viewer derived text
Reference derived text
– Manually selected
 Unmatched text
• Chosen text
• Form text
– Specified text
– Legacy text
– Auto selected
•
•
•
•
•
38
 Derived text
PreferredTerm
FullySpecifiedName
Protocol text
Mapped text
Matched text
Human-readable rendering post-coordinated
expressions
Use-cases for human-readable rendering





39
Patient care delivery
Decision support validation
Validating encoding
Validating textual expressions
Analysis and reporting
Human-readable rendering post-coordinated
expressions
Data-entry mechanism summary
 Structured entry with text review
– Text review and verification
• Text extension
• Text modification
 Narrative entry
– Auto encoding
– Assisted encoding
 Encoding with verification
–
–
–
–
40
Translation entry
Term matched translation
Term unmatched translation
Post-coordinated translation
Post-coordination rendering variants
 Origin rendered text
– Only applicable where no other authored original text exists
• Exception may apply for mapping from other terminologies but only
where these generate post-coordinated forms
– Created from a structured post-coordinated expression
– Created at time of origin
– Stored and communicated with the record
 Reference rendered text
– Follow fixed rules for validation of other renderings
 Viewer rendered text
– Allow alternative renderings if users which to clarify coded
meaning in neat readable way
– Beware this is not necessarily what the sender saw.
41
Origin rendered text rule extensions
Ordering of components in rendering (1)

In 2004 NHS discussion paper suggested
–

For example using object : attribute = value
–

appendectomy : priority = emergency
When using value : object becomes
–


emergency : appendectomy
Which is slightly more natural ...
... but complex examples are still rather unnatural
–
42
Improved human renderings of post-coordinated expressions
were possible by “value : object “ rather than “value:
attribute=value” ordering of terms” in a post-coordinated
expression.
emergency {appendix structure; excision – action} {peritoneal cavity:
inspection –action} procedure
Origin rendered text rule extensions
Ordering of components in rendering (2)

Instead of applying the value then object
rendering rules across the board it would be
better the following criteria for each attribute
permitted by the concept model:
– Whether it prefixes or postfixes the object term
– Its order relative to other attributes
– Whether the attribute term is required to
disambiguate the value
•
E.g. This may be true for direct/indirect attributes
 These rules would be language specific
43
Origin rendered text rule extensions
Infixing text of some refinements
 The following approach might be considered
– If the object term contains a term associated with
the defining value of an attribute
• Replace this with the term for the refined value applied in the
post-coordinated expression
 This still needs experimentation !
44
Origin rendered text rule extensions
Grouping reduction
 Ignore groups where there is only one group
and where there are no ungrouped attributes
– Exclude “is a” relationships in this consideration
 Ignore groups where there is only one group
unless the refined attribute occurs both inside
and outside the group
 Ignore groups if a single refinement applies to
the same attributes in several groups
45
Origin rendered text rule extensions
Anatomical sites
 Flatten laterality representation so that this does
no need to be nested within the site attribute
value.
– Removes the need to specify the site if the only
refinement is lateralisation
 Simplify anatomic structure text renderings
– Preferred terms of the form “structure of …” and “…
structure” can be simplified by removing “structure
of” or “structure” accordingly. These prefixes/suffixes
exist only to disambiguate the concept from the
“entire …”. A rule that attenuates “structure” but
retains “entire” still leaves the combined rendering
non-ambiguous.
46
Origin rendered text rule extensions
Pattern matching and pre-coordination
 Pattern match to remove duplication where the
site is stated in the term for a qualified object.
 Attempt to locate a fully defined pre-coordinated
concept that reduces or removes the need for
post-coordinated refinement.
– If found the use the preferred term for that concept
and to not re-express any refinements that are
expressed in the pre-coordinated concept.
47
Origin rendered text rule extensions
Context dependent renderings
 In the case of context dependent concepts avoid
treating these as post-coordinated constructs of the
“context-dependent-category” top level concept. In most
cases all that is needed is to identify a high level node
such as “family history of” or “absent finding” and then
apply an “associated finding” (or associated procedure)
value.
– This allows simple rendering rules to reduce the rendered text
for almost any family history to “family history of”: “<preferred
term of disorder>”.
– Due to incomplete definitions this approach is not currently
applicable to all context dependent hierarchies. However, this
should be enhanced over the course of the next two releases.
48
Summary
49
Summary
The value of post-coordination
 Attempts to avoid the use of post-coordination
by adding pre-coordinated concepts to meet
every requirement
– Increases the size of the terminology
– Introduce risks of errors from modeling
• In particular mismatches between descriptions and
associated concept definitions
– Create a growing maintenance burden
– The impact of these factors is probably even greater
if additions are made in Extensions as a result of
duplication of effort on different and potentially
divergent Extensions
Summary
A practical approaches to storage and retrieval of
post-coordinated expressions
 An Expression Repository
– Enables a predictable indexable storage of post-coordinated
expressions
– Allows post-coordinated expressions to be entered, stored,
retrieved and communicated
 Adding an Expression Links Table
– Allows rapid access to Normal Forms
 Adding an Expression Transitive Closure
– Supports high performance subtype testing
 All the required tables required to support this approach
can be maintained by software without manual input
Summary
Practical approaches to entry of
post-coordinated expressions
 Contention between requirements
– Consistent representation is essential for retrieval
– User interfaces need to be tailored by use case
 Therefore
– The relationship between user-interface and
representation cannot be one-to-one
 Using post-coordinated expressions to represent data
need not mean more mouse-clicks or key presses
 A well designed user interface
– Should not slavishly follow the structure of expressions
and their possible refinements
– Should apply a mix-and-match of techniques data entry
techniques that suit users
– Should record information consistently using postcoordinated expressions to support retrieval
Summary
Practical approaches to rendering of
post-coordinated expressions
 There are different use cases for rendering expressions
– Some uses require a human readable familiarity
– Other uses require the technical accuracy and completeness
offered by the post-coordinated grammar
– Some uses are well served by structured forms that highlight key
attributes such as site, laterality, causative agent, etc
– Some uses demand that the text and screen view must be the
same as when the data was entered
– Other uses are better served by reorganizing the data into a
common view
 Therefore
– There is not a single rule for rendering a post-coordinated
expressions in every situation or in every language
– A set of guidelines is needed that identifies the different use cases
and recommends the way to deliver safe and useful renderings
 Post-coordination is only one part of the larger question of
how clinical information should be rendered
Questions?
© 2002-2010 The Clinical Information Consultancy Ltd (includes some material © 2002-2010 IHTSDO)
54