Terminology and HL7 Dr Colin Price

1
Terminology and HL7Dr Colin Price

• HL7 UK
• 11th December 2003

2
Since 1992, the NHS has had a strategic
commitment to using a single comprehensive
terminology to support patient care.
3
High level implementation goals

• Nation-wide roll out
• Multi-purpose use
• Direct and indirect care
• Multi-professional uptake
• Doctors, nurses, allied health
• Multiple environments
• Primary care, hospitals, community
• Extensibility
• Patient access, Social care.

Information for Health Building the Information
Core Delivering 21st Century IT
4
NHS requirements as a customer"

• A single comprehensive scheme
• Nationally licensed
• Able to support key NHS functions
• Flexible and dynamic
• With robust cross maps to classifications
• Allowing NHS input into governance
• Editorial processes
• Business management
• And . available now
• To support roll out within National Programme.

5
ICRS OBS3 Final 1.0

• 790.12 SNOMED CT
• All new systems shall support the SNOMED CT
  standard.
• All existing systems should support SNOMED CT.
• 790.13 UKCPRS
• All new systems shall support the UKCPRS
  standard.
• All existing systems should support UKCPRS.

6
SNOMED CT development
7
Milestones to date

• January 2002
• Read Codes and SNOMED merger completed
• From 2002
• Early adopter US implementations of SNOMED CT
• April 2003
• NHS Formative Evaluation Programme completed
• April 2003
• NHS end user licensing
• August 2003
• Approval as draft fundamental standard for NHS.

8
Key Objectives 2003 - 2004

• Systematic refinement of SNOMED core
• Based on agreed priorities and use cases
• Development and testing of UK specifics
• Extensions, subsets, cross maps etc
• Based on requirements of National Programme for
  IT
• Support for UK implementations
• Planning migration of primary care Read Code
  systems
• Validation of cross maps to ICD10 and OPCS4
• Testing and evaluation in real systems
• Terminology service development.

9
Key Objectives 2003 - 2004

• Systematic refinement of SNOMED core
• Based on agreed priorities and use cases
• Development and testing of UK specifics
• Extensions, subsets, cross maps etc
• Based on requirements of National Programme for
  IT
• Support for UK implementations
• Planning migration of primary care Read Code
  systems
• Validation of cross maps to ICD10 and OPCS4
• Testing and evaluation in real systems
• Terminology service development.

10
The migration challenge

• Clinical databases (Read Codes and other schemes)
• Applications
• Reports
• Protocols
• Decision support algorithms
• Preserving integration with other semantic
  components.

11
Servicing local requirements

• Local subsets
• Local navigation hierarchies
• Cross mappings to local classifications
• Local sub-licensing distribution mechanisms
• Local education and training
• Local integration with other standards
• Local migration of legacy data systems.

12
Summary

• SNOMED CT is the terminology of choice for the
  NHS
• Strategic direction
• ISB approval as draft fundamental standard
• ICRS OBS specification
• Good progress on developing local enhancements
  for the UK
• Active work to support NPfIT requirements
• Integration with other standards e.g .messaging
• Format of NHS Drugs and Devices Dictionary
  (UKCPRS)
• Implementation issues being investigated
• Migration of primary care systems
• Education, training, change management.

13
Terminology and HL7Dr Colin Price

• HL7 UK
• 11th December 2003

14
Terminology and HL7 UK

• David Markwell
• The Clinical Information Consultancy
• Chair of HL7 UK
• Member of the HL7 Vocabulary Technical Committee
• Consultant to the SNOMED International Editorial
  Board

15
Vocabulary in HL7 Version 3Overview

• Structural Vocabulary
• Coded Data Types
• Vocabulary Domains
• Vocabulary Specific Standards
• Vocabulary Localisation Rules
• HL7 Version 3 with SNOMED CT

16
Structural Vocabulary

• The HL7 Reference Information Model provides the
  shared structure that underpins all HL7 Version 3
  Standards
• Structural Vocabulary
• Internal codes that name specialised classes
  without modifying the structure
• Part of the standard not open to localisation
• For example
• OBS designates an act of observation
• As distinct from a procedure, supply, etc.
• PSN designates an entity that is a person
• As distinct from an organisation, device, etc.

17
Coded data types

• HL7 Version 3 specifies a rich set of data types
  and standardises how these are to be expressed
  (e.g. in XML)
• Four coded data types which meet different
  requirements
• Coded Simple
• Just the code
• Coded Value
• Code
• Code system identifier
• Readable descriptions (originalText and
  displayText)
• Coded with Equivalents
• Coded Value
• optional translations expressed in other code
  systems
• Concept Descriptor
• Code Value
• optional qualifiers
• optional translations

18
Vocabulary domains

• Every coded attribute in an HL7 standard has a
  Vocabulary Domain
• This identifies the range or meanings to be
  represented by a code value in that attribute
• Vocabulary Domains can be refined for each
  message type
• In a message coded attributes are populated with
  codes from a Value Set
• This is a set of codes from a specified source
  that represent the Vocabulary Domain in a given
  realm
• The Value Sets are taken from Code Systems
• Internal HL7 Code Systems
• Usually fairly limited and specific to particular
  domain
• External Code Systems
• Usually referenced to populate broader domains
• Examples include SNOMED CT and the Read Codes

19
Vocabulary specific standardisation

• Register of Code Systems
• Maintained by HL7
• Allocates of unique OID to each code system
• Allows code systems to be recognised in messages
• Register is available at www.hl7.org in text and
  XML
• Common Terminology Server
• Proposed standard API for vocabulary functions
  required to enable use of a variety of code
  systems in HL7 standards and messages
• Guide on good practices for code systems
• Non-reuse of codes / concept permanence
• Meaningless identifiers
• Effective and regular maintenance

20
Localisation and Vocabulary in HL7

• There are HL7 International Affiliate
  organisation in nearly 30 countries
• HL7 recognises the need for a common global
  standard that meets local needs
• Countries vary in their use of code systems
• Some have billing arrangements, policies or even
  laws that require particular code systems
• HL7 Vocabulary Technical Committee has taken a
  lead in realising the idea of localisation
• Localisation is now a normative part of the HL7
  Version 3 standard

21
HL7 Version 3 with SNOMED CT

• HL7 Version 3 is a family of standards
• Providing a framework for development of
  consistent, requirements-based communication
  specifications
• Based on a reference information model that
  offers a consistent grammar for clinical
  expressions but does attempt to mandate a single
  code system
• SNOMED CT is a controlled terminology
• Covering the same broad scope as HL7
• Able to populate HL7v3 coded attributes to
  represent and communicate detailed semantics
• Has logical definitions that permit effective
  retrieval
• Has a subset mechanism that facilitates
  definitions of value sets for HL7v3 messages

22
Vocabulary in HL7 Version 3 A summary of the key
points

• HL7 Structural Vocabulary
• Act as semantic ligaments holding the V3 skeleton
  together and providing constrained flexibility
• HL7 Coded Data Types
• Unambiguously carry coded information expressed
  using any registered vocabulary or code system
• HL7 Vocabulary Domains
• Express the semantic space to be filled by coded
  attributes to enable meaningful interoperability
• HL7 Vocabulary Specific Standards
• Support more effective use coding in healthcare
• HL7 Vocabulary Localisation Rules
• Meet national needs within a global standard