Binding SNOMED CT to detailed clinical information models

1
Binding SNOMED CT to detailed clinical
information models

• Laura Sato NHS Connecting for Health
• David Markwell The Clinical Information
  Consultancy Ltd

2
Overview

• Background
• Terminology binding
• Requirements
• Components
• SNOMED Clinical Terms
• Information model standards
• Combining structure and terminology
• Strengths and weaknesses
• Managing overlaps
• A practical approach
• Principles and recommendations
• Practical principles of terminology binding
• Terminology binding recommendations
• Future direction

3
Background

• In terms of
• What is meant by EHR content
• Why NHS CFH is interested
• What led to the investigation of terminology
  binding methods

4
Types of NHS EHR content specifications

• Application to application interface content
• Data sharing - messages and documents (e.g. MIM,
  HL7)
• User interface content
• Data capture (e.g. openEHR, emerging national
  models)
• Data display (e.g. CUI, emerging national models)
• Content to support national abstractions /
  queries / policies
• Data definition (e.g. NHS Data Dictionary)
• Data submission (e.g. Commissioning Data Sets)
• Data queries (e.g. HRGs, QMAS)
• Future
• Content to support queries and clinical decision
  support

5
NHS interest in clinical content modelling

• NHS vendors, informatics groups and clinicians
  want -
• better or more explicit alignment across NHS data
  specifications
• non-proprietary detailed data requirements
  definitions to feed into application designs
• Do once, re-use many
• clinicians (data capture)
• software developers (code, data)
• NHS application purchasers (requirements)
• NHS data specifications developers (avoid
  conflicts, save time, devote scarce resources to
  build shared specs.)
• Preliminary study of feasibility of use
  (Oct.-Dec. 2006)
• Pilot use clinical data capture requirements
  for the North, Midlands, East Programme for
  Information Technology in Emergency and Maternity
  care (Feb.-May 2007)

6
Summary of pilot findings

• Content models could help NHS business analysts
  share detailed data requirements (data
  constraints) across projects
• openEHR content models are very accessible to
  clinicians
• The openEHR modelling technique of designing
  global archetypes alongside use-specific
  templates makes the re-use of structures very
  easy for modellers
• More work is needed to explore the feasibility of
  automatically transforming between openEHR and
  HL7 V3 models
• More work is needed to explore how complex SNOMED
  CT-binding to archetypes and templates would be
  done

7
Terminology binding requirements (overview)

• What terminology binding means
• A short introductory glossary
• Why terminology binding is important
• Requirements for reusable, meaningful health
  records
• When terminology binding matters
• Relevance of the clinical information life-cycle

8
What terminology binding means

• A short introductory glossary

9
What terminology binding means

• Terminology binding (noun) an instance of a link
  between a terminology component and an
  information model artefact.
• Examples
• A set of coded values that may be applied to a
  particular attribute in an information model. The
  set may be expressed either explicitly
  (extensionally) or as a definitional constraint
  (intensionally).
• The association between a named attribute value
  in the information model and a specific coded
  value or expression.
• A rule that determines the way that a coded
  expression is constructed based on multiple
  attribute values in the information model.

10
What terminology binding means (subsidiary
definitions)

• Terminology component a code value from a code
  system or a representation of a set of codes or a
  post-coordinated expression or a set of
  post-coordinated expressions.
• A SNOMED CT concept id, expression, reference set
  or constraint.
• Information model artefact an attribute, class
  or collection of related attributes and/or
  classes in an information model.
• A coded attribute in an HL7 constrained model or
  template.
• A node or collection of nodes in an openEHR
  archetype or template.
• Information model a formal description of how
  information may be structured, interrelated and
  accessed.
• A static HL7 model such as the Reference
  Information Model (RIM) or a constrained model or
  template derived from the RIM.
• An openEHR archetype or template.

11
What terminology binding means

• Terminology binding (verb) the process or action
  of making one or more terminology bindings.
• Examples
• Reviewing user-specified information requirements
  and assigning appropriate code values to express
  the underlying concepts in a way that enables
  consistent reusable representation of the
  required information.
• Assigning a set of code values to a field in an
  information model to express the range of
  possible meanings that can be expressed within
  that field.

12
Avoid the lazy abbreviation Term binding

• Terminology binding is principally concerned with
  clear expression of clinical ideas in ways that
• Allow common understanding
• Support effective reuse of information
• Terminology binding does not focus on the
  particular terms used to describe a clinical idea
• The same term may expression different meanings
  
• cold
• Different terms may express the same meaning
• removal of appendix, appendicectomy,
  appendectomy
• The terminology component involved in a binding
• Is not a term
• Is an expression that represent a clinical idea
  by reference to one or more SNOMED CT concepts

13
Why terminology binding is important

• Requirements for reusable, meaningful health
  records

14
Why terminology binding is important

• For health record information to be reusable it
  must be processable in a meaningful way by a
  variety of different applications
• Reliable interpretation of the meaning of
  information depends on
• The way information is structured
• A common reference information model
• The way clinical concepts are represented
• A common clinical terminology
• The way the terminology is used within the
  structure
• A consistent approach to the interface between
  structural and terminological representations of
  information

15
Meaningful health records

• A meaningful health record makes it possible to
  answer relevant questions accurately and
  efficiently

16
Terminology binding supports reusable meaningful
health records

• Requirements for meaningful processing of health
  record information come from different sources
  including
• Clinicians involved in direct patient care
• Epidemiologists and researchers
• Service managers at local and national levels
• To meet these varied requirements the health
  record content must be represented in ways that
  encompass multiple perspectives

17
Different perspectives on health information

• Clinical discipline and specialty views
• Different ways of working and priorities affect
• Degree of detail that can be readily captured
• Balance between data capture styles
• Record content that needs to be displayed for
  review
• Opportunities for effective use of decision
  support
• Reporting requirements
• Specific process views
• For example
• Requesting and reporting investigations
• Prescribing, dispensing and administration of
  medication
• Managing immunisation programs
• Referrals and appointment bookings

18
Integrating different perspectives

• Specific perspectives are important
• Specialty specific views support clinical users
• Process specific views enable efficient and
  effective delivery of services
• Integration of multiple perspectives is important
• The same information is often collected by, and
  relevant to, many specialties and processes
• Consistent representation of information is
  essential to enable reuse of relevant information
• Requirements for consistency are often ignored
  when focusing attention on one process or
  specialty

19
Process-centric data and reusable health record
information

• The delivery of health care to a person or a
  population consists of various processes
• Each process has specific requirements for data
  collection and communication
• For example, the process of providing routine
  immunisations
• Health records contain information collected
  during various processes
• The information collected is often relevant to
  and related with multiple care delivery processes
• For example, information about an immunisation
  may be relevant when determining the differential
  diagnosis for a subsequent febrile illness

20
Process based requirements

• Data requirements
• Provide each party with sufficient information to
  fulfil their role
• Track progress to confirm consistent completion
• Identify exceptions
• Data capture and communication requirements
• Simplify capture of data essential to the process
• Specify the requirements for communications that
  are essential to the process
• Typical end result
• Forms, information structures and messages
  directly matching specific requirements with
  minimal requirements for data transformation
• Not ideal if the information needs to be reused
  by other related processes

21
Health record requirements

• Information requirements
• Provide appropriate accurate information when and
  where it is needed
• To enable delivery of evidence-based personal
  care to individuals
• To enable more effective delivery of care to the
  wider population
• Allow incremental growth of meaningful
  information
• Capture and communication requirements
• Facilitate capture of information from which the
  meaning can be determined without detailed
  knowledge of the specific data collection process
• Represent communications in ways that conserve
  meaningful information derived from different
  processes and applications

22
An example of a process Routine immunisation

• Call person to immunisation clinic
• Record call and booked appointment
• Take and review history for contra-indications
• Decide on immunisation required
• Explain recommendation and obtain consent
• Record history, immunisation decision and consent
• Administer the appropriate quantity of the
  vaccine by the appropriate route
• Record details of the substance, quantity, batch
  number and route of administration
• Arrange follow up for next step in course
• Submit required information to support claims
  and/or update central/shared immunisation
  registers

23
An example of a meaningful health record
viewImmunisation information

• Questions a meaningful health record should be
  able to answer
• What immunisations has this person had and
  when?
• Has this person had an adverse reaction to a past
  immunisation?
• What immunisations are due or incomplete?
• Is this person up to date for immunisation
  against disease X?
• What percentage of a population completed their
  immunisations?
• Who received immunisations from a suspected
  faulty batch?
• Which members of the population are at risk from
  a current outbreak of a disease due to out of
  date immunisation?
• Has this GP/PCT hit a target for coverage of the
  population?
• Have particular immunisations, routes or regimes
  been associated with greater risks of side
  effects?
• and many more

24
Reuse requires reliable interpretation of
information collected for different purposes

• Reliable interpretation of the meaning of
  information depends on
• The way information is structured
• A common reference information model
• The way clinical concepts are represented
• A common clinical terminology
• The way terminology is used within the structure
• Consistent terminology binding

25
Requirements for structure terminology

• Effective representation of clinical information
  requires
• A common structure to represent record entries in
  a consistent manner
• To relate each record entry to a subject, author,
  time, place and other specific data items
• A terminology to represent clinical concepts used
  in record entries
• To relate the meanings of different concepts used
  in record entries, protocols, and queries in ways
  that facilitate consistent processing and reuse

26
Requirements for terminology binding

• Candidates for standard EHR structures include
• HL7 Version 3 based models
• Including HL7 CDA and HL7 Clinical Statements
• EN13606 based models
• Including openEHR
• The leading candidate EHR terminology is
• SNOMED Clinical Terms
• SNOMED CT can potentially be used in a variety of
  ways in either HL7 and openEHR structures
• Different approaches can undermine the value of a
  standard terminology and structure
• Consistent principles and methods need to be
  applied to terminology binding if potential
  benefits are to be realised

27
When terminology binding matters

• Terminology binding and the clinical information
  life-cycle

28
When terminology binding matters

• Clinical information goes through several
  life-cycle stages
• Entry, storage, retrieval, display and
  communication
• These stages affect ways people specify data
  content requirements
• A consistent view of terminology binding must
  support all these stages

29
Clinical information life-cycle
User Interface
Capture
Display
Decision support
Reporting analysis
Stored EHR content
Other systems or applications
30
Data capture as a determiner of data content and
representation

• Effective data capture is vitally important
• It needs to be easy in terms both of
• the time and effort require and
• the way it fits in with working practices
• Data capture is only worthwhile if the data
  captured can be usefully reused
• Therefore
• Data capture does not define the requirements for
  data content and representation
• Data capture needs to be designed to meet
  requirements for subsequent retrieval

31
Alternative modes of data entry are good servants
but poor masters

• Approaches to data entry need to be tailored to
  the way different groups of clinicians work and
  think
• A common approach to the user interface
• But not one size fits all
• As the following examples illustrate the same
  information may be captured in different ways
• How does this affect content and representation?

32
Different ways to capture the same meaning
(1)Simple check-boxes
Suggests a Model of Use consisting of codes
assigned values of true, false or unknown.
33
Different ways to capture the same meaning
(2)Selection of terms
Suggests a Model of Use consisting of individual
coded statements with associated text
34
Different ways to capture the same meaning
(3)Free text with natural language processing
Suggests a Model of Use consisting of text tagged
with relevant codes.
35
Answering questions based on data capture
representations

• If information is represented according to the
  way it is captured it may be difficult to answer
  simple questions
• Does the patient have a family history of
  diabetes mellitus? expands to
• Do they have a family history form in which
  diabetes mellitus is checked as present?
• Do they have a family history record in which the
  code for FH diabetes mellitus is present?
• Do they have text that is tagged with the code
  for diabetes mellitus in the context of a
  section of text tagged as family history?
• ... there are also other data capture
  representations to consider

36
Communication as a determiner of data content
and representation

• Communication requires the sending system to
  selectively retrieve the information to be sent
• There is no point in communicating information
  that is not retrievable on the recipient system
• Reuse of communicated information requires
  selective retrieval
• Therefore, communication requirements are
  secondary to requirements for reuse and retrieval
• Possible exception A communication specification
  may be the only source of requirements for data
  that is captured specifically to populate a
  message, has a specific role in the receiving
  system and is not reused for any other purposes.

37
Display as a determiner of data content and
representation

• Display requirements can be phrased as questions
• For example
• General What information is held about this
  person?
• Specific What allergies does this patient have?
• Population Which patients require follow up?
• Display is one of the requirements for selective
  retrieval effective display requires
• High performance retrieval - rapid responses
• Clear rendering and layout of responses
• Integration with data capture in the user
  interface

38
Selective retrieval is vital for reuse of health
record information
Display
Reporting and analysis
Decision Support
Capture
Stored EHR Content
Retrieval
Stored Content
Other EHR systems
39
Retrieval as a determiner of data content and
representation

• To support effective reuse a health record must
  make it possible to answer relevant questions
  accurately and efficiently
• To answer relevant questions information must be
  selectively retrieved so it can be displayed or
  analysed
• Therefore, retrieval requirements are clearly an
  important determiner of requirements for data
  content and representation

40
Requirements arise from the questions that need
to be answered
Display Requirements
Reporting and analysis Requirements
Decision Support Requirements
Capture Requirements
Posing questions
EHR Content Requirements
Content Requirements
Other EHR systems
41
Reusable electronic health records

• A reusable health record must make it possible to
  answer relevant questions accurately and
  efficiently
• The primary drivers for the data content and
  representation of health records are
• The questions that are deemed to be relevant
• The accuracy and efficiency necessary to
  adequately address those questions

42
Relevant questions that a health record may need
to answer

• It is impossible to enumerate every potentially
  relevant question (the number is huge and
  growing)
• It is possible to identify general types of
  questions
• For example
• What information is known about this person?
• Does this person have a particular item or
  collection of items of information in their
  record?
• How many incidents of a specified type have
  occurred to members of a population (or selected
  subpopulation)?
• Which members of a population have a particular
  item of collection of items of information in
  their record?
• Each type of question can be refined
• different selection criteria
• different ways in which to represent the answers

43
Retrieval requirements

• Accuracy includes
• Precision
• Reducing the risk of false positives
• Completeness
• Reducing the risk of false negatives
• Efficiency includes
• Ease
• Time and expertise needed to pose questions
• Frequency
• How often does a question need to be answered
• Rapidity
• How quickly is an answer needed

44
Reusable health records and models of meaning

• For health record information to be reusable it
  must be processable in a meaningful way
• This requires a model that enables questions to
  be posed and answered consistently irrespective
  of the method of data capture
• This can be considered as model of meaning
• If processable information to be shared between
  different systems and applications with out loss
  of processable meaning
• This requires a common model of the meaning

45
Data capture and meaningful records

• Reuse of data requires a common model of
  meaning that can reliably answer questions
  independent of the method of data capture
• Data entry may be driven by different models of
  use
• For example, check-lists, picking lists, typing,
  dictation
• Entered information must be transformed to the
  common model of meaning so it is available for
  reuse
• The model of meaning must consistently
• Encapsulate essential contextual information
• Represent appropriate and available detail
• Allow general questions to be answered by records
  that contain more detailed representations

46
Communication of meaningful records

• Information with the same meaning may be
  represented differently in different systems and
  in different messages
• To meet different use cases in term of levels of
  detail
• To benefit from proprietary optimisations
• To utilise different communication standards
  appropriate to specific requirements
• Communications of health record information
  should be based on (or transformable to) a common
  model of meaning
• A common model of meaning offers a shared view
  allowing consistent retrieval of data
  irrespective of its point of origin

47
Summary of the ClinicalInformation Life-Cycle
Selection Criteria
Other systems or applications
48
Requirements for a commonmodel of meaning

• A model of meaning into which data captured in
  different ways can be transformed is required to
  support
• Consistent processing within an application that
  collects similar data in different ways
• Semantic operability
• A common model of meaning in which data from
  different applications can be shared is required
  to support
• Communications between applications which employ
  different internal models of meaning
• Semantic interoperability

49
What should a common model of meaning look like

• A virtual view of information that can be used as
  a point of reference for questions
• Ensure that similar information can be retrieved
  in similar ways
• Avoid special cases in which particular
  information is only accessible using particular
  queries
• This does not preclude specialised views but it
  does require that the information is also
  accessible using the general view
• Avoid multiple representations of similar
  information based on process or level of detail
• The model of meaning should tolerate different
  levels of details within the common structure

50
Templates and other constraints

• Templates and archetypes act as useful
  constraints to information models that can assist
  many aspects of health record system
  specification
• Including
• Design of data capture screens and protocols,
• Design and implementation of health record
  repositories,
• Message design and message instance validation.
• Like other information models these structures
  should be bound to terminologies to make them
  meaningful
• Structural constraints should not be assumed to
  encapsulate meaning
• Instances of information that conform to
  structural constraints should be reliably
  transformed to a common model of meaning to
  enable comparability with other representations
  of similar information

51
Starting point for a common model of meaning

• The HL7 DSTU Guide to the use of SNOMED CT with
  HL7v3 (TermInfo) is a starting point from which
  to develop a common model or meaning
• It discusses many general issues encountered at
  the boundary between information models and
  terminology models
• It identifies specific issues at the boundary
  between HL7 Clinical Statements and SNOMED CT
  Terms and specifies rules and guidance for
  dealing with many of these issues.
• It provides a point of reference rather than a
  finished work since it remains subject to
  evolutionary improvement

52
High-level statements on Terminology Binding
agreed by EHR Content TAG

• The requirements for terminology-binding to
  information models should be driven by data
  retrieval requirements.
• Data retrieval requirements should guide data
  capture specifications.
• The SNOMED CT concept model should be exploited
  to the full in NHS data retrieval specifications
• Where the SNOMED CT concept model does not meet
  requirements, efforts should be made to enhance
  the concept model to meet requirements in future.
• This does not preclude applying constraints on
  the use of the SNOMED CT concept model.
• Some overlaps between information models and
  terminology models may be deemed useful or
  necessary in a grey zone where the merits of
  alternative representations are finely balanced
  or use case specific. Coded information items
  within these overlaps should be defined in such a
  way that fully automated and loss-less
  transformation is possible between permitted
  alternative representations.
• This means that the principles for terminology
  binding (including using the SNOMED CT concept
  model as a conceptual framework) should influence
  the design of grey zone data specifications
  within the information models.
• Detailed terminology-binding rules should be
  fully illustrated with implementation examples.

53
Terminology binding and information model
standards
54
SNOMED CT HL7 Version 3

• HL7 Version 3
• Reference Information Model and method for
  development of communication specifications
• TermInfo Project
• Looking at integration of terminologies with HL7
  Version 3
• Started late 2004 by NASA ? adopted by HL7
  Vocabulary TC
• Guide to Use of SNOMED in HL7 Version 3
• Produced by TermInfo and refined by 3 ballot
  cycles
• Adopted as HL7 Draft Standard for Trial Use
  (DSTU) in September 2007
• NHS Connecting for Health specified
• SNOMED CT for coding clinical information
• HL7 Clinical Statements CDA based messages
• Applied the early recommendations of TermInfo work

55
Binding SNOMED CT to HL7 Clinical Statements

• HL7 TermInfo
• Scope
• Progress
• Use within NHS CFH
• Wider relevance

56
HL7 TermInfo Scope

• TermInfo is an HL7 Project developing standard
  guidance on use of Terminologies within
  Information models
• As an HL7 Project the Information model focus is
  on HL7 Version 3 models including
• HL7 Reference Information Model (RIM) and
• Constrained Information Models (e.g. DIMs, RMIMs
  etc.)
• Particularly the Clinical Statement pattern
• TermInfo Work Package 2 is the most active part
  of the project
• The Terminology focus of WP2 is SNOMED CT

57
HL7 TermInfo Progress

• Became an HL7 Vocabulary TC Project in September
  2004
• Guide to Use of SNOMED CT with HL7 Version 3
• Adopted as a DSTU in September 2007
• Now under review and revision in preparation for
  a full normative edition next year
• Other activities looking at use of different code
  systems and in HL7 Version 3
• Particularly mixed use of LOINC and/or ICD9.CM
  with SNOMED CT in HL7 messages

58
HL7 TermInfo Use within NHS CFH

• NHS CFH staff have been closely involved
  throughout the development of the HL7 TermInfo
  Project
• Including current Project Leader Edward
  Cheetham
• NHS CFH applied the early recommendations from
  TermInfo within -
• The NHS Message Implementation Manual
• NHS Templates based on HL7 Clinical Document
  Architecture
• Due to development timetabling some later
  revisions of TermInfo recommendations have not
  yet been incorporated in NHS CFH specifications
• Relevance to NHS CFH activities on terminology
  binding for detailed clinical models
• Use of SNOMED CT in other information models
  needs to be compatible with use in HL7 Version 3
  to support consistency and interoperability

59
HL7 TermInfo Wider relevance

• HL7 Version 3 is based on an information model
  (the RIM)
• SNOMED CT provides a controlled vocabulary which
  can be used to populate coded attributes in the
  HL7 RIM
• In theory use of a standard reference
  information model and a terminology should enable
  semantic interoperability
• In practice different ways of using the same
  coding system with the same information model
  form an obstacle to semantic interoperability
• TermInfo was the first formal standardisation
  effort to focus directly on the interface
  between a standard clinical information model and
  a widely used controlled terminology
• It identified general issues including overlaps
  and gaps likely to be found between information
  models and terminologies
• It opened the debate on different approaches

60
SNOMED CT, EN13606 openEHR

• EN13606
• Five part European Standard for EHR Communication
  from CEN TC251
• Also being submitted to ISO for wider adoption
• A generalised EHR reference model
• Uses archetypes for specific types of clinical
  information
• openEHR
• A consortium based on open-source development of
  specification and tools around the EN13606
  standard
• Includes template to further refine archetypes
• NHS Connecting for Health
• Used openEHR tools to capture content
  requirements expressed by clinicians
• Found a variety of approaches had been applied to
  represent similar information in the resulting
  archetypes and templates

61
openEHR Design Overview
Reference Model
Data capture
Retrieval and Reporting
Display
62
openEHR design Reference Model
Reference Model
Data capture
Retrieval and Reporting
Display
63
openEHR Reference Model
64
openEHR design - Archetypes
Archetypes
Reference Model
Data capture
Retrieval and Reporting
Display
65
openEHR Archetypes
66
(No Transcript)
67
(No Transcript)
68
(No Transcript)
69
openEHR design - Templates
Reference Model
Data capture
Retrieval and Reporting
Display
Templates
70
openEHR Templates
71
(No Transcript)
72
(No Transcript)
73
(No Transcript)
74
Using structure and terminology (overview)

• Representing clinical content using structure and
  terminology
• Balancing strengths and weaknesses
• Managing overlaps

75
Representing clinical content using structure and
terminology

• Balancing strengths and weaknesses

76
Expressivity of information models

• Information models are good at
• Specifying structures for representing instances
  of information.
• Enabling general purpose information like text,
  dates, times and quantities to be associated
  together in rational, consistent, meaningful
  ways.
• Constraining information structures to limit the
  degrees of freedom with which similar information
  can be expressed.
• Enabling communication in ways that associate
  information with requests and reports associated
  with identifiable people and other entities.
• Information models require vocabularies
• To populate relevant attributes with codes that
  express common meanings in ways that can be
  processed consistently

77
Expressivity of the combination of a given
information model and terminology model

• Limited expressivity
• Leads to failure to meet some requirements
• May be addressed by customized work-rounds
  leading to loss of consistency and
  interoperability
• Requires standard ways to fix these gaps
• Greater expressivity
• Leads to alternative ways to represent similar
  meanings
• May be addressed by local conventions on what
  codes or model structures are used
• Requires support for reconciling, communicating
  and comparing these alternative representations
• Is perfect expressivity possible?
• Yes - for a requirement agreed by everyone for
  all time!
• Not likely across the full breadth of health care!

78
Expressivity of terminology models

• Simple code systems
• Represent meanings in a compact, consistent
• In addition to this classifications
• Represent aggregations of similar meanings
• In addition to this Reference Terminologies
• Express relationships between concepts
• E.g. pneumococcal pneumonia
• Is a type of pneumonia Is caused by
  pneumonococcus
• Is a type of infection Has site lung (etc )
• Enable transformation between alternative
  representation of the same meaning
• Terminologies require information models
• To express instances of information in ways that
  relate them to entities, times, quantities, text
  and other values.

79
Balancing structure and terminology
80
Balancing structure and terminology

• Structural model
• Attributes with specific data types
• Dates, times, durations, quantities, text markup
• Identifiable instances of real-world entities
• People, organisations, places
• Overall record and/or communication architecture
• EHR extract, EHR composition, openEHR reference
  model, CDA documents, HL7 messages
• Representation of constraints on use of
  particular classes or attributes in given use
  cases
• Formalism for templates applied to constrain
  openEHR archetypes or HL7 CDA documents

81
Balancing structure and terminology

• Terminology model
• Specific concepts
• Diseases, symptoms, signs, procedures, drugs,
  etc.
• Semantic relationships between concepts
• Relationship between "viral pneumonia", "lung",
  "virus", "infectious disease"
• Representation of constraints on use of
  terminology
• Concept model and value-set definition formalism

82
Balancing structure and terminology

• Terminology model preferred
• Constraints on combination of concepts in
  instances including abstract model of
  post-coordination and permissible attributes and
  ranges for refinement of concepts in specified
  domains
• Restrictions on "finding site" refinement of
  "appendicitis", conventions on representation of
  laparoscopic variants of procedures

83
Balancing structure and terminology

• Structural model preferred
• Representation of relationships between distinct
  instances of record entries and other classes
• Grouping of record entries related by timing,
  problem or other organising principles.

84
Balancing structure and terminology

• Grey area
• Representation of contextual information related
  to instances of clinical situations
• Family history, presence/absence, certainty,
  goals, past/current, procedure done/not-done,
  etc.
• Representation of additional constraints on
  post-coordination of concepts for specific use
  cases
• Constraints on terminology use specific to
  immunisation and related adverse reaction
  reporting

85
Representing clinical content using structure and
terminology

• Managing overlaps

86
Managing overlaps

• Both TermInfo and the openEHR terminology binding
  work found overlaps
• Situations that could be represented by combining
  different information model structures with
  different terminology components
• E.g. Context such as past history or family
  history can be captured using specific data
  points in the structural model or using SNOMED CT
  context attributes to express a situation with
  explicit context
• Different structural models driven by
  user-interface considerations to collect
  similar information
• E.g. Check-lists as compared to term or concept
  selection

87
Challenges presented by overlaps (1)Same
information represented in different ways

• Retrieval and reuse may miss similar information
  represented in different structure/terminology
  combinations
• For example, representing Family history of
  asthma
• A family history check-list with asthma
  marked yes
• A family history section referring to the
  SNOMED CT concept asthma
• A record entry referring to the SNOMED CT concept
  family history of asthma
• A record entry containing a SNOMED CT expression
  such as family history associated finding
  asthma
• A record entry containing the SNOMED CT concept
  asthma associated to a family member by an
  information model structure
• To avoid false negatives different
  representations must be transformed to a common
  model

88
Challenges presented by overlaps (2)Same
information represented in different ways

• Risk of ambiguity from alternative
  interpretations
• For example, representing an absent finding
• Information model attributes may indicate
  absence or negation
• SNOMED CT finding context can represent known
  absent
• Does the combination of two representations of
  absence mean
• double-negative
• redundant restatement of the negative
• additional emphasis of the negative
• The logical interpretation is double-negative but
  may not be how it was intended
• It many not be clear which concepts are
  negative
• E.g. conscious not conscious
  unconscious no loss of consciousness
• To avoid misinterpretation there need to be clear
  rules about the way information model and
  terminology semantics combine

89
Challenges presented by overlaps (3) Different
levels of semantic specificity

• Structural and terminological representation of
  apparently similar information may have different
  levels of specificity
• For example, representing the site of a procedure
• SNOMED CT distinguishes between
• the direct site and indirect site
• e.g. for excision - what was excised where it
  was excised from
• site and morphology
• e.g. normal structures abnormal structures
• site and approach
• procedures with a defined site and those applied
  to different sites
• e.g. appendectomy ? appendix
• The information models considered
• Do not make these distinctions in a systematic
  manner
• Make distinctions that SNOMED CT does not support
• Guidance on overlaps must take account of these
  differences in expressivity and the ways they
  affect particular use cases

90
General summary of alternative ways to manage
overlaps

• Processing requirements to manage each overlap
  depend on the permitted representation. In each
  case a single specified representation simplifies
  processing requirements.

91
Managing gaps

• Both TermInfo and the openEHR terminology binding
  work found gaps
• Situations that could not be fully represented
  due to lack of completeness in the structural
  model or the terminology
• In some cases, a simply omission of a relevant
  concept in SNOMED CT
• In other cases, an available SNOMED CT
  representation could not be accommodated in the
  model due to different assumptions about the
  concept domains or lack of support for
  post-coordination
• Gaps are usually easier to address than overlaps
• Decide where a change is needed and submit a
  request
• Some gaps highlight broader issues and it may not
  be appropriate to resolve these by piecemeal
  additions

92
A practical approach to terminology binding
(overview)

• Structural and semantic units of health record
  information
• Terminology binding types

93
Structural and semantic units of health record
information

• Structural anchors for terminology components

94
Managing semantic granularity

• Structural information models
• Use separate data points to represent different
  aspects of a record entry
• Support instance information such as dates,
  times, people, places, numeric values and
  quantities
• May support codes and post-coordinated expression
  in some data points but not in others
• SNOMED CT expresses
• Some aspects of a clinical situation in a single
  concept
• Other aspects using post-coordinated expressions
• Clinical concepts and situations but not instance
  specific data
• It is essential to match and combine these levels
  of semantic granularity in a consistent manner
• This may require changes in the information
  model and/or
• Constraints on the use of SNOMED CT

95
Granularity of binding targets (1)
Binding separate concepts to multiple related
nodes
96
Granularity of binding targets (2)
Binding an expression to a single node
97
Health Record units - common features of
different information models

• An electronic health record can be considered to
  be divided into separate units of information
  which have an indivisible meaning that
  approximates to a single sentence or utterance in
  human language.
• These units are sometimes called 'record entries'
  or 'clinical statements
• To avoid confusion with existing names used in
  openEHR and HL7 these units of information are
  referred to here as 'hr-units' (health record
  units)
• The indivisible meaning within an hr-unit that
  approximates to a single sentence or utterance is
  referred to the 'hru-clinical'

98
Health record unit reference information

• Each hr-unit logically contains references to
  particular people, dates, times and to other
  'hr-units'
• These references are not part of the
  'hru-clinical' but are essential to its
  interpretation
• Representation of these references is not
  directly relevant to terminology binding
• Example
• The following quoted phrases expresses the
  'hru-clinical or an hr-unit
• "subject of record has asthma"
• "subject of record has systolic blood pressure
  of 120 mmHg
• To be interpreted each needs to refer to an
  identified subject and may also refer to related
  'hr-units' (for example in the second case it may
  be related through the structural model to the
  associated diastolic blood pressure)

99
Health record units

• Each 'hr-unit' may contain a human-readable
  textual rendering of the 'hru-clinical'
• This may be required for medico-legal reasons or
  to add detail to a coded representation.
  Otherwise, it is not essential for the 'hr-unit'
  to contain an explicit textual rendering, as this
  may be derived from other representations of the
  'hru-clinical'.
• Each 'hr-unit' may contain a coded representation
  of the 'hru-clinical'. This is referred to as
  hruc_coded
• This coded representation may
• Completely encapsulate the 'hru-clinical'
• Provide a label for a value which, when populated
  with other data such as a numeric quantity or
  range, fully expresses the 'hru-clinical'
• Provide a less detailed representation that is
  expanded by text
• The hruc_coded representation is determined by
  the terminology model and is the direct focus of
  terminology binding

100
Additional information in a health record unit

• Each 'hr-unit' may contain additional information
  to supplement the textual and/or coded
  representations. This information may include
  references to particular people, dates, times,
  quantities, images

101
Terminology Binding Types

• Different ways in which the use of terminology
  may be constrained by or bound to an information
  model

102
Different types of terminology binding

• Constraint bindings
• Semantic constraint binding
• Expression-structure constraint binding
• Fixed bindings
• Node-fixed bindings
• Choice-fixed bindings
• Selection support bindings
• Constructor bindings
• Retrieval bindings

103
Semantic constraint binding (1)

• Semantic-constraints restrict what it is possible
  say
• A semantic-constraint binding requires that
• Only terminology expressions that have a meaning
  in a domain specified by the constraint can be
  applied to a particular node
• A semantic-constraint is not concerned with how
  the required meaning is represented
• Example
• A node representing diagnosis might be required
  to contain a value that is a subtype of
  64572001 disease

104
Semantic constraint bindings (2)

• A semantic-constraint may prohibit a particular
  facet of information from being expressed
• Example
• A node representing administration of a drug may
  be required to exclude any mention of the
  substance administered
• This would permit
• 32282008 subcutaneous injection
• but would not permit subtypes such as
• 308755006 subcutaneous injection of insulin
• A constraint like this is useful if a separate
  node in the information model is used to
  represent the substance administered

105
Semantic constraint bindings (3)

• A semantic-constraint may require a particular
  facet of information to be expressed
• Example
• A node describing a procedure on a kidney might
  be required to specify laterality
• The following expressions meets this requirement
  in different ways
• 108022006 kidney excision 272741003
  laterality 7771000 left
• 65801008 excision 405813007 procedure
  site - Direct ( 64033007 kidney structure
  272741003 laterality 7771000 left )
  
• 65801008 excision 405813007 procedure
  site - Direct 18639004 left kidney
  structure

106
Semantic constraint bindings (4)

• Semantic constraints permit any logically valid
  representation of a specified meaning
• Example
• A semantic constraint that permits
• 71620000 fracture of femur
• also permits equivalent post-coordinated
  expressions such as
• 125605004 fracture of bone 363698007
  finding site 71341001 bone structure of
  femur
• or
• 64572001 disease 116676008 associated
  morphology 72704001 fracture , 363698007
  finding site 71341001 bone structure of
  femur

107
Semantic constraint binding (5)

• The valid domain for semantic constraint binding
  may be specified
• As a complete set of concept identifiers
  (extensional)
• As a set of rules that test relationships between
  concepts in the terminology to determine the
  membership of the set (intensional)
• Simple rules such as 'this concept and all its
  subtypes'
• More complex rules that involve presence or
  absence of particular defining relationships
  and/or refinements.

108
Semantic Constraint Applicability

• Semantic constraints apply principally to
  archetypes
• A semantic constraint is inherited by the
  equivalent node in any derived archetype or
  template
• A derived archetype or template may have an
  additional semantic constraint
• This may further refine the range of possible
  values
• but
• It must not extend the range of permitted
  expressions
• Semantic constraint binding should be aligned
  with the SNOMED CT concept model
• Semantic constraints should not be constraints on
  (rather than extensions of) the SNOMED CT concept
  model
• A present the concept model is only expressed in
  documents
• In future, it will be possible to validate
  alignment using the SNOMED CT Machine Readable
  Concept Model

109
Semantic Constraint Representation

• Semantic-constraints should be represented using
  a standard formalism specified or recommended by
  the terminology
• SNOMED CT, mechanisms for representation of sets
  (Subset and their enhancement as Refsets) can
  meet most of the simple requirements for
  specifying semantic constraints
• More sophisticated constraints such as a
  requirement or prohibition of a particular facet
  of information require a more expressive syntax
• Currently, an extended version of the SNOMED CT
  compositional grammar
• HL7 TermInfo extension and reference to Subsets
• In future, should be replaced or enhanced by the
  IHTSDO 'Machine Readable Concept Model (MRCM)
  Project

110
Expression-structure constraint binding (1)

• Expression-structure constraints restrict how a
  particular meaning can be expressed
• An expression-structure constraint specifies the
  extent of post-coordination that is permitted or
  required in the expression applied to a
  particular node

111
Expression-structure constraint binding (2)

• An expression-structure constraint may prohibit
  some or all uses of post-coordination
• Example
• An expression-structure constraint that prohibits
  all post-coordination in a particular node
• This would permit
• 71620000 fracture of femur
• but would not permit semantically equivalent
  post-coordinated expressions such as
• 125605004 fracture of bone 363698007
  finding site 71341001 bone structure of
  femur
• or
• 64572001 disease 116676008 associated
  morphology 72704001 fracture , 363698007
  finding site 71341001 bone structure of
  femur

112
Expression-structure constraint binding (3)

• An expression-structure constraint may require
  some facets to be post-coordinated
• Example
• An expression-structure constraint that requires
  the substance responsible for an allergy to be
  represented by post-coordination
• This would permit
• 106190000 allergy 246075003 causative
  agent 373270004 penicillin -class of
  antibiotic-
• but it would not permit the semantically
  equivalent pre-coordinated representation
• 91936005 allergy to penicillin

113
Node-fixed bindings (1)

• A node-fixed binding asserts that inclusion of a
  particular template node has the meaning
  specified by the associated SNOMED CT expression
• In the case of a node with a Boolean value this
  expression is applied if the node has the value
  'true'.

160266009 no significant family history
114
Node-fixed bindings (2)

• A node-fixed binding may be regarded as a special
  type of a semantic-constraint in which only one
  value is possible
• It is also an expression-structure constraint as
  it specifies single permitted expression

115
Choice-fixed bindings

• Choice-fixed bindings assert that a given choice
  from a picking list in the template is
  represented using the specified SNOMED CT
  expression
• Unlike other bindings choice-fixed bindings apply
  to individual items in a list of choices rather
  than to the node itself
• The node to which a list of choices applies
  should be bound to semantic-constraint
• All the choice-fixed bindings in the list should
  fall within the semantic constraint applied to
  the node

116
Choice-fixed binding - Example
117
Alternative to choice-fixed