1. Terminology and HL7 Dr 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.
UKCPRS
All new systems shall support the UKCPRS standard.
All existing systems should support UKCPRS.

6. SNOMED CT development April 1999 April 2000 April 2001 April 2002
Draft
Standard
April 1999
April 2000
April 2001
April 2002
April 2003
April 2004
Alpha
test
Formative Evaluation.
Start-up
Read/SNOMED merger
SNOMED CT design
Core Refinement.
Release 1 January 2002
Agreement signed
Implementation
Foundation.
Evaluation & Testing

7. Milestones to date August 2003 January 2002 From 2002 April 2003
Read Codes and SNOMED merger completed
From 2002
Early adopter US implementations of SNOMED CT
April 2003
NHS Formative Evaluation Programme completed
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 HL7 Dr 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 3 Overview
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
+ 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 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
Terminology and HL7 - Price and Markwell
11 December 2003
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