Designing queries and searches in SNOMED CT Principles plus hints and tips presented by Denise Downs

Housekeeping Please keep yourself on Mute during the presentation Please use chat if you have any questions –change to Everyone so that we all see the question There are various pauses within the presentation to ask questions BUT If you have a ‘burning question’ please feel free to take yourself off mute and ask Quick Feedback form Email with links after the webinar We have put people on mute as they entered the presentation. If you move your cursor up to the top of the screen, you should get a bar pop down, you can use the actions on the bar to un-mute yourself as well as open a chat box. Please keep yourself on Mute during the presentation unless you wish to ask a question Can I suggest you click on chat now and keep this open during the presentation – you can drag it to a different place on screen. This means you can see any questions anyone asks, as well as enter any yourself. if you have any questions please change the send section to Everyone so that we all see the question There are various pauses within the presentation to ask questions BUT If you have a ‘burning question’ please feel free to take yourself off mute and ask

Queries/searches - definition What do we mean by queries/searches Identifying patients or content in records This could be used for: Reporting Sending letters Risk Analysis Business protocols QOF etc. We will refer to these as searches from this point forward Queries meaning Could be one code or many codes Could be a new search designed from scratch or an existing one you need to convert to SNOMED CT More specifically Queries/searches refers to a computer readable script that selects one or multiple codes for the purpose of extracting information from codes records for human interpretation (note, a tool could be used to create the script).

What this is and isn’t Assumes using the supplier reporting functionality We will be producing documentation and a recorded presentation for those with their own databases who write SQL type queries – a taste at the end

Objectives Understand how to undertake searches in SNOMED CT, what will a QOF rule look like Understand the principles of converting existing searches in Read v2/CTV3 to SNOMED CT Understand why converted searches may not produce quite the same results as the original A brief summary of the technical considerations Presentation will not Provide sample script for you to use to gain familiarity Provide prototype software/tools for you to use to develop your expertise Go into much technical detail, see supporting technical documentation www.blahblah

Read v2 / CTV3 Examples are in Read v2, this is where the changes are probably greatest There are some differences between SNOMED CT and CTV3, but mainly to do with inactivation and modelling

Safety net - Dual Coding and the Subset Suppliers have been provided with a GP Subset, these are SNOMED CT codes for which a Read equivalent exists All historical data will have a Read code AND SNOMED CT New SNOMED data within the subset will also have a Read code entered by the system This Dual coding approach will provide time for searches to be updated CTV3 Read v2 SNOMED CT To allow suppliers to move at different times, we have created a subset of SNOMED CT that reflects the content of Read codes in use in systems. This means we can still exchange data between the different systems as well as run reports; when a supplier moves to using SNOMED CT they will still add the Read codes in the background. This provides a period of time where data will still be recognised in Read and when users can become familiar with SNOMED CT. Suppliers – assurance of their product will be available at first, to reflect the current content of Read codes – so as per previous slide, this allows both SNOMED CT and Read codes to be held in the clinical system during transition. All current codes in Read v2 are within the CTV3 subset; this has some additional content from care settings outside General Practice All current content in CTV3 is within SNOMED CT. SNOMED CT is more extensive than CTV3.

Recap on the fundamentals of SNOMED CT

Irritable bowel syndrome (disorder) 10743008 A Concept in SNOMED CT Preferred Term: Irritable bowel syndrome Synonym: Irritable bowel Synonym: Irritable colon Synonym: Irritable colon syndrome Synonym: Membranous colitis Synonym: Spastic colitis Synonym: Mucous colitis Synonym: IBS - Irritable bowel syndrome Synonym: IC - Irritable colon FSN: Fully specified name Irritable bowel syndrome (disorder) 10743008 Relationships Is a Disorder of intestine Finding site Intestinal structure In SNOMED CT we refer to clinical concepts – a clinical concept can have a number of descriptions that describe that concept. I tend to think of a concept as what I think of when the concept is described, so here Irritable bowel syndrome represents the concept 10743008 –individuals may describe this differently, but we all think of the same thing when they are describing the same concept. All the different descriptions have the same concept id – in this case 10743008 In this illustration here, the concept is Irritable Bowel Syndrome; on the left is a list of the descriptions that may be used to describe that. They all mean the same thing so we refer to them as synonyms. There is also a description known as the FSN or Fully specified name. This is unique and unambiguous – the ‘tag’ of disorder in brackets helps this and is the hierarchy the concept is in. As well as descriptions, a concept also has a number of relationships. The is-a relationship is what positions the concept in the right place in the hierarchy – similar to the chapter structure in Read. It has some additional relationships as well that enable analysis not previously possible. In this example there is a relationship of ’finding site’ is intestinal structure. In SNOMED CT there are a number of these additional relationships – we will see some more later.

Concepts and descriptions Synonyms are truly synonymous Searches are done on the concept id FSN is often the term provided in searches Fully specified name Preferred term Acceptable synonyms Preferred term is usually the description seen in the system Concepts can have many descriptions as clinicians have many different ways of expressing the same things Searches will be written at concept level

NHS Digital browser Select options and then click to display Description Ids Browser available at https://termbrowser.nhs.uk

Structure of SNOMED CT 19 hierarchies to organise the content of SNOMED CT Semantic tags change within some hierarchies: Top level hierarchy Sub hierarchy tag Sub hierarchy 2 tag body structure (body structure) (cell) (morphologic abnormality)   clinical finding (disorder) (finding) Concepts are organised into 19 hierarchies to help organise the concepts. A concept will only ever be in one hierarchy (with the exception of a handful of concepts)

Relationships - recap Navigation within a hierarchy is done via the |is a| relationship Infective pneumonia |is a| child of infection Infective pneumonia |is a| child of respiratory disease Viral pneumonia |is a| descendant of infection Searching on attribute relationships will not initially be available in systems There is no limit to the number of children a concept can have There is no limit to the number of parents a concept can have Attribute relationships further refine the definition of a concept, however their use in searches is out of the scope of this presentation

Bacterial infectious disease |Is a | relationships Infectious disease Disorder by body site Infection by site Disorder of trunk Bacterial infectious disease Respiratory tract infection Disorder of thorax Bacterial infection by site Disorder of lung Lower respiratory tract infection Lung consolidation Bacterial respiratory infection Pneumonia Infectious disease of lung Infective pneumonia Bacterial lower respiratory infection In SNOMED CT concepts can be linked to more than one concept, however, they will always be in the same hierarchy, e.g. procedures. Concepts form networks via the |is a| relationships, not linear singular relationships All concepts can always be traced back to the top level hierarchy and to the root concept SNOMED CT The view you can see here is actually a simplified view to show you how concepts relate to each other. Bacterial pneumonia

Consequences of multiple parents These are the same concept – found in more than one place

Writing a new Search SNOMED CT in primary care

Differences? SNOMED CT A1 A1234 SNOMED is poly-hierarchical – ie. Terms can have more than one parent. So you need to be careful if producing reports that provide counts, that you haven’t counted something more than once. It does mean that you have to worry less about finding the same term that has been put in more than once in different places in Read. However, you cannot use the code to find a term and its children – eg. All terms beginning H33 for Asthma.

All patients who have had … How might I write a search to find those patients who have had an appendectomy… We are going to start by searching for individual terms. Remember that each browser may function differently so the commands I use with this one may not be the same in other browsers, but generally the types of things we can do to search will be available.

Search for clinical codes: Use techniques similar to how you currently search the internet and medical publications COPD - Chronic obstructive pulmonary disease Try common abbreviations e.g. Things are normally in the singular, e.g. eye not eyes Make sure you have the correct type of concept – eg. procedure not an organism Type what you want to say … The main thing to remember is to search for what you want to record in the record – I wouldn’t advise starting at the top of the hierarchy and trying to work your way down. When searching: Descriptions are generally in the singular – don’t type a plural Don’t use full words – you usually need at least 4-5 characters to start to hone in on the description you are looking for Don’t worry about knowing the exact phrase as its written in the terminology (unless you have it in guidance). In the main don’t type words like: with, to, the When you find a concept description, make sure it’s the right type – either by viewing its FSN or whatever method your EPR uses.

Appendectomy and all its descendants…

That’s it …. The rest of this presentation is about dealing with anomalies with Read

Comparison with Read v2 and CTV3 SNOMED CT in primary care

Some term text differences from Read SNOMED CT uses the Body Structure hierarchy to specify body parts Terms beginning [SO] do not exist 7N890 00 [SO]Cervical lymph node maps to 81105003 |Cervical lymph node structure (body structure) | SNOMED CT uses the Morphologic abnormality sub hierarchy to specify morphology Terms beginning [M] do not exist BBEJ. 00 [M]Intradermal naevus maps to 112681002 | Intradermal naevus (morphologic abnormality) | As we said, SNOMED CT has addressed some of the issues with existing descriptions in Read codes, these are described in guidance documentation now on the NHS Networks site– the link is provided in this slide. Here are some examples: Current terms that end in NOS or NEC don’t exist in SNOMED CT. They arose from the classifications and shouldn’t be used in a patient record. When historical data is mapped they will map to current SNOMED CT concepts as illustrated here. Terms beginning [SO] don’t exist in SNOMED – if I was a patient looking at my record I wouldn’t know what this meant and again they come from the classifications. These will map to the appropriate body structure in SNOMED The same for Morphology. These and more are described in the Guidance document.

Some term text differences from Read Clinic A / Clinic B codes are inactive These will map but to inactive codes; they are not interoperable, never went through GP2GP Bill/fee paid don’t exist in SNOMED CT It is ambiguous, do have Bill paid and Fee paid See Data Quality Guidance for more information, update due in July

NEC / NOS SNOMED CT does not allow concepts such as NOS, NEC ‘other’ F52z. 00 Otitis media NOS maps to 65363002 | Otitis media | Q4z.. 15 Stillbirth NEC maps to 237364002 | Stillbirth | Asthma unspecified maps to Asthma – as it maps to its true meaning

SNOMED CT default context Clinical Findings and procedures have a default meaning: For a clinical finding this means that: the finding has actually occurred (vs. being absent or not found) it is occurring to the subject of record (the patient) it is occurring currently or at a stated past time.  For a Procedure this means that: the procedure was completed it was performed on the subject of record (the patient) it was done in the present time or at a stated past time. So procedure declined is not in the procedure hierarchy but in situation with explicit context (tag is situation)

Some model differences SNOMED CT model requires that all descendants of a concept have same characteristics Opposites are not listed under the same concept Constipated and not constipated are listed under the same parent in Read v2 but in SNOMED CT they have different parent concepts Constipated Disorder of colon Functional disorder of intestine Is a Not Constipated Finding of frequency of defaecation Is a

Other differences SNOMED CT does not contain duplicates F004. 00 Meningitis – tuberculous maps to 58437007 | tuberculosis of meninges| A130. 00 Tuberculous meningitis maps to 58437007 | tuberculosis of meninges| SNOMED CT concept IDs don’t mean anything Users are not expected to remember any of the concept IDs but to search on the words 391281002 | Mental health assessment | 703257008 | Assessment of cause of psychotic and behavioural symptoms | Users are not expected to remember SNOMED CT IDs This is a child of 391281002 but the IDs are not related.

Not ambiguous In Read, some terms were ‘overloaded’ i.e. there were used in multiple ways Example: Assessment Name Score Procedure Observable Generalized anxiety disorder 7 item Generalized anxiety disorder 7 item scale (assessment scale) Assessment using generalized anxiety disorder 7 item score (procedure) Generalized anxiety disorder 7 item score (observable entity) Generalised anxiety disorder 2 Generalised anxiety disorder 2 scale (assessment scale) Assessment using generalised anxiety disorder 2 scale (procedure) Generalised anxiety disorder 2 scale score (observable entity) Alcohol use disorders identification test Alcohol use disorders identification test (assessment scale) Assessment using alcohol use disorders identification test (procedure) Alcohol use disorders identification test score (observable entity) Alcohol use disorder identification test consumption questionnaire Alcohol use disorder identification test consumption questionnaire (assessment scale) MISSING

‘Grouper Terms’ O/E – weight was a heading for the different findings of the patient’s weight in Read, but over the years has been used with a value.

Expressing searches – Clare Burgon SNOMED CT in primary care

Language of SNOMED CT specifications Operators in SNOMED CT - Expression Constraint Language (ECL) conceptid just this code <conceptid the descendants of this code <<conceptid this code and all its descendants MINUS conceptid exclude this code MINUS <conceptid exclude the descendants of this code MINUS <<conceptid exclude this code and all its descendants ^refsetId members of refset

Reference set example

QOF refsets

Language of SNOMED CT concepts Concept can be referred to in computer and human language, the syntax used is to express the concept in terms of its id and either preferred term or fully specified name. ID |term| 233838001 | Acute posterior myocardial infarction (disorder) | So lets look at one more example of how to write a search from scratch using SNOMED CT and Expression Constraint Language

Expressing what we want to search on We could express a search in two ways: Use the hierarchy structure to state: Concept and all of its descendants <<233838001 | Acute posterior myocardial infarction (disorder) | Cherry pick the codes List each concept seperately 233838001 | Acute posterior myocardial infarction (disorder) | 70998009 | Acute myocardial infarction of posterobasal wall (disorder) | 15713201000119105 | Acute ST segment elevation myocardial infarction of posterobasal wall (disorder) | Although these produce the same result we’ll see that using the hierarchy is a better way to write the searches Simple example, most searches are expected to be much larger First specifies the exact codes we’re interested in Second method uses the |is a| relationship to define the search |is a| relationships are as shown on the right (note |is a| relationships to other concepts are not shown << realtes to the concept and all its children, more on this later

Example – Diabetes mellitus Identify in SNOMED CT everyone with Diabetes mellitus but not during pregnancy Use browser to find the concepts needed Selecting each concept separately would be time consuming and potentially prone to human error So… select the concept and all descendants << 73211009 | Diabetes mellitus (disorder) | This concept has 16 children Many of the child concepts have children too identified by > As we don’t know what internal tools organisations have access to the example will go through the principles using the SNOMED International browser. 16 children and some of these have children them selves, in most cases we’d want to include all of these

Example – Diabetes mellitus continued Say we decided that we did not want to include diabetes mellitus that occurs during pregnancy << 73211009 | Diabetes mellitus (disorder) | MINUS<<199223000 |Diabetes mellitus during pregnancy, childbirth and the puerperium (disorder)| This search expression would exclude any concepts listed under concept 199223000 Exclude this concept and all descendants So using expression constraint language, this search would be written as << 73211009 | Diabetes mellitus (disorder) | MINUS<<199223000 |Diabetes mellitus during pregnancy, childbirth and the puerperium (disorder)| Using local database or search tools to do this such as SQL

Searches originally written in Read Understanding search results once converted to SNOMED CT Implications of the maps from Read to SNOMED CT

Moving to SNOMED CT Two ways to approach migrating a search from Read v2/CTV3 to SNOMED CT Take the previous search definition and write a new SNOMED CT search from scratch This may include SNOMED CT concepts that do not have a Read v2/CTV3 equivalent Take the previous search codes and map these to SNOMED CT This may need extending and reviewing in future as SNOMED CT concepts with out a Read v2/CTV3 equivalent are used Read v2 Read v3 (CTV3) SNOMED CT SNOMED CT evolved from the Read codes – we didn’t throw everything away and start again. Everything that is current and in Read you will find in SNOMED – its just more extensive as it supports more than general practice. It also supports some data that wasn’t addressed by Read for example allergies

Forward mapping tables to convert to SNOMED CT For each Read v2 / CTV3 code, a FORWARD map to SNOMED CT is provided where appropriate There are two mapping tables one for Read v2 and one for CTV3 Maps have been clinically assured, and are designed to work in one direction only You system supplier should be using the maps to map historical Read v2/CTV3 codes to SNOMED CT Your system supplier will also be converting national system reports to SNOMED CT Read V2 From SNOMED CT To CTV3 From SNOMED CT To

Role of the mapping tables Take the previous search codes and map these to SNOMED CT Following example will illustrate why some results may be different once data entry moves to SNOMED CT How can this be transformed into SNOMED CT? The first approach does not attempt to convert on a code by code basis, is the simplest, this uses all of SNOMED CT so not all concepts will have a corresponding Read code. The first part of the presentation used this approach The second approach will convert on a code by code basis. So far we’ve looked at how to find SNOMED CT codes to create a search from scratch but for converted searches lets look at why they may produce different results in SNOMED CT to Read

Not fully automatic Cannot not be converted automatically as contains content not in Read, this needs a human to check Example: C10..% Diabetes mellitus TO << 73211009 | Diabetes mellitus (disorder) | May be ok Example: H33..% Asthma TO << 195967001 | Asthma (disorder) | For example include Exercise induced Asthma , which may not wish to include

Notice two different Read codes go to the same SNOMED CT concept An example Expanded to 73 Read codes Which map to 67 SNOMED CT concepts Notice two different Read codes go to the same SNOMED CT concept

Why searches might vary

Introducing the ‘Round trip’ In simple terms we have performed the following: We have only considered the maps for Read v2 codes that were in our original specification Are there any other Read v2 codes that map to our list of SNOMED CT concepts? We need to consider these as they would be picked up by the converted search but not by the old search

Back to the example of Diabetes mellitus When checking the forward mapping tables for the 67 concepts in the converted search we find there are other Read codes not in the original specification Original Read v2 specification: 73 codes Converted SNOMED CT specification: 67 concepts ‘Round trip’ Read v2 specification: 138 codes The tables show the maps at read code term code level to SNOMED CT concepts and descriptions. However the search would only be executed at concept level This is one example of the result of the ‘round trip’ So running the search in SNOMED CT would in effect be searching over more Read codes than the original search . However we have not yet been able to test on patient level data so a converted search specifying DM for example may or may not result in a different number of patients being returned by the search .

Other mapping features One Read v2/CTV3 code may go to different SNOMED CT concepts as synonyms were not always true synonyms in Read v2/CTV3 H330. Read code links to 3 different SNOMED CT concepts due to the mapping tables taking into consideration that the synonyms were not true synonyms

Why is it important to know about the maps? Historical data stored in Read will have a SNOMED CT code mapped to it (using the forward maps from Read to SNOMED CT) Dual coding means that future data entered in SNOMED CT will have a Read v2/CTV3 code stored alongside it (using the GP subset from SNOMED CT to Read) The maps mean that running a search in the original Read v2/CVT3 compared to the newly converted SNOMED CT they may produce different results

So what does this mean Maybe the original report was missing a code that should have been included A duplicate Read code was not added to the original report when it should have been The SNOMED CT report (restricted by the map to Read) could be a more accurate representation…. …. However, it does not use the full list of SNOMED CT concepts. It is not a full SNOMED CT search

Mapping summary All searches are expected to be executed at concept level This is true for: SNOMED CT Read v2/CTV3 However the maps created for mapping from Read v2 /CTV3 to SNOMED CT have been created at synonym level to allow for the fact that not all Read v2/CTV3 synonyms were true synonyms Resulting in codes not previously selected being brought into the specification once mapped to SNOMED CT More on this to follow, first look at some principles for converting searches

Look-up for Read to SNOMED Browsers Top 2 browsers created from NHS Digital assured maps

Supplier systems Suppliers will convert their national searches to full SNOMED CT searches If you have refined their search, then this will pick up the new search If you have amended their search, this will need to be reviewed

Searches housekeeping SNOMED CT in primary care

Impact of SNOMED CT releases SNOMED CT is updated twice a year, in the UK the files are released 1st April and 1st October Versioning mechanism allows new content to be created and current content to be made inactivate New content If its relevant to your search, most likely the new concept will have been placed in the SNOMED CT hierarchy as a descendant of one of your search items so your search will automatically pick this up On rare occasions, this new concept may not be placed where you expect and would not automatically be added to your search A new disease has been identified which needs to be recorded New medical procedure needs to be recorded New concept(s) replace pre existing concept(s) that were deemed ambiguous Plus many more reasons… There are two tables that can help with this. The history of substitutions table and search table. the principles of both will be discussed here but the technical detail of how to use them is covered in separate documentation (links at the end of this slide)

Searches housekeeping Meaning searches at some point will likely: Need to be periodically checked to see if new content needs to be added manually Need to be periodically checked to see if content automatically added to your searches is correct Inactive concepts are ok to remain in a search if you search on historical data

Summary One concept has many descriptions Build searches on concept IDs not description IDs A concept can have more than one is-a relationship (parent) Designing a search in SNOMED CT from scratch requires a browser or tools to find the content needed When designing a new search, if its over historical data, just reflect on any anomalies from Read that you need to account for SNOMED CT hierarchy structure means searches will generally pick up all the ‘child’ concepts needed if you select a concept and all descendants Converting an existing search from Read v2/CTV3 to SNOMED CT requires the forward mapping tables but only uses SNOMED CT concepts where there is a map from Read v2/CVT3 – needs extending to all SNOMED CT A converted search may produce different results if run in SNOMED CT to Read v2/CVT3 due to the mapping table structure

Supplier approaches ALL suppliers wish to minimise the impact and provide time to adjust searches On SNOMED Day 1, all existing searches will still work They will continue to work while users enter data that has a Read equivalent – suppliers solutions will help New codes have to use, eg, new immunisation, would have done new report anyway Prioritise reports and plan migrating them over the next year, possibly 2 years

Own solutions? Tools based on Read codes will need ‘updating’ If via in-house solutions, need to: Download SNOMED CT files from TRUD Create some additional tables Write new searches based on SNOMED CT hierarchy Understand some of the nuances wrt Read to SNOMED CT maps SNOMED CT concepts can be up to 18 digits long, set excel sheets as text