SNOMED CT in Primary Care
Professional Clinical Safety Requirements
This is a stub / work in process
The clinical safety recommendations listed below have been obtained from a paper produced by a team of three General Practice Clinical Safety Leads and one Clinical Terminologist, working for Health and Social Care Information Centre (HSCIC) in 2012. They were subsequently endorsed by the Joint GP IT Committee and by the UK Terminology Centre in 2014. They were intended to provide guidance for the migration of GP systems to SNOMED CT and for he use of SNOMED CT thereafter. Since migration from Read v2 and CTV3 to SNOMED CT is not yet complete across the whole of the UK, they remain relevant today (2026)
1. Data migration
When a GP system is migrated to SNOMED CT it is expected that all coded information contained within patient records, excluding that related to medications, will be translated into SNOMED CT. It is further expected that all appropriate measures will be taken to avoid loss of clinical information or change of meaning. Measures to be taken MUST include the following:
- The Clinically Assured terminology mapping tables must be used in any translation or data migration process. These mapping tables must be used in line with the guidance provided and within the purposes for which they were assured
- An audit of the releases of the maps used with effective dates and times should be maintained
- The term text of the target SNOMED CT code must be displayed
- The original source code and term code (i.e. as entered by the original author) must be retained within the patient record; the original term text must be displayed (i.e. in association with the new SNOMED CT term) unless it is a lexical exact match to the new SNOMED CT term text
2. SNOMED CT Concepts and Synonyms
- Systems adopting SNOMED CT must support both preferred terms and synonyms and it follows that these must be preserved during any migration or data translation process
- A system must be able to support synonyms for any data that is received and must not change a synonym that is received into the system to the preferred term
- Synonyms must be available for a user to search. The term then selected by the user for recording into the patient record must be maintained
- As a minimum the system should store the descriptionId and the description text; it is recommended that the conceptId is also stored
- In order to support future expectations in relation to SNOMED CT expressions the description text should not be restricted to an arbitrary length
- Any SNOMED CT system using its own namespace should register for an HL7 oid for their namespace and must accompany any codes sent from that namespace with that oid when sending data to external systems
- Any system receiving a SNOMED CT term (whether from international, UK, or any namespace), must store the specific code system (oid), code and term text and be able to transfer this set of data items to another system, and must display the term text received (see section 5 on oids)
- A system should be able to process the SNOMED CT code and term received from another GP system within the subset of terms as defined by the Read v2 and Read v3 scope
- The receiving system should undertake a level of validation when receiving data from other systems, where it is able to, in the following circumstances:
- when processing a translation set data to ensure accuracy against current maps
- to ensure that appropriate action is taken where inactive codes are received to ensure that these are appropriately visible within their system
- that the correct type of SNOMED CT term is received if this is critical for processing (eg. a procedure in a procedure field)
3. Interoperability
One of the prime reasons for migrating systems to SNOMED CT is to enhance interoperability. It is vital that this opportunity should not be lost. It is therefore expected that all appropriate measures will be taken to promote interoperability and to avoid developments that could be detrimental to current or future interoperability. In particular the following should be taken into account in the system:
- All SNOMED CT based systems, whether or not they employ subsets, must be able to import and process any SNOMED CT code that exists either in International SNOMED CT or in the UK Edition such that:
- The Description is human readable in the record
- The Code is capable of being retrieved by local system searches
- It is possible locally for users to set up searches that can include these codes
- Note that there is no expectation that imported codes should necessarily be added to data input picking lists
- Local codes that are purely local to one organisation must not be propagated outside of that organisation
- Local codes that are system wide (e.g. centrally curated by a Vendor) may be propagated where ‘same’ systems can import them and correctly interpret them provided that they are always exported with the appropriate HL7 message identifier (OID) that distinguishes them clearly from National SNOMED CT. This approach should also be adopted where the local codes are SNOMED CT codes but within a local namespace. The OID used must reflect the local namespace and not be the SNOMED CT OID
- Wherever SNOMED CT post coordination is contemplated it must never be carried out in a way that puts future interoperability at risk
- Data migration to SNOMED CT will use only pre-coordinated concepts to support data interoperability. This is the approach used within the terminology mapping tables
- Post-coordination in messages will only be used where the sender, receiver and message structure can all support its use; these patterns will be detailed and agreed across the active supplier domain in advance and will not impose any particular internal approach
- No general requirements for post-coordination will be required of systems when in the mixed terminology phase
- Any introduction of post-coordination will only be undertaken when interoperability issues have been specifically addressed
4. SNOMED CT updates
-
As with any other coding scheme there is a Professional expectation that as SNOMED CT is updated systems will be kept up to date. GP users have a particular requirement to be able to search their historical data going back many years. Both SNOMED CT itself and systems must be designed in a way that facilitates updates without detriment to the historical record or to searches performed on historical record
- Systems need to be able to take new releases of SNOMED CT in a timely manner and be able to manage the dynamic nature of SNOMED CT
- For both medico-legal and clinical safety reasons any updating process must leave the original term description plus its original coding intact and undisturbed in the historical record as recorded by the original author
- Where SNOMED CT terms or concepts are rendered ‘inactive’ it must continue to be possible for users
- To run searches in a timely fashion on historical data containing those ‘inactive’ terms / concepts
- To design new searches or edit existing searches that include those ‘inactive’ terms / concepts
- Where SNOMED CT terms or concepts are rendered ‘inactive’ they should be removed from data input picking lists in an appropriate timescale
The UKTC provides guidance and products to support the management of inactive terms and concepts; due attention should be taken to the up to date information and products provided by the UKTC. In particular, the Query Table provided by UKTC should be used to manage inactive content in queries and in running queries across records that contain inactive content.