Terminology and HL7 Dr Colin Price HL7 UK 11 th December 2003

Since 1992, the NHS has had a strategic commitment to using a single comprehensive terminology to support patient care.

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 21 st Century IT

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.

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. ICRS OBS3 Final 1.0

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

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.

Key Objectives 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.

Key Objectives 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.

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

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.

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.

Terminology and HL7 Dr Colin Price HL7 UK 11 th December 2003

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

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

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.

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

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

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

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

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

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