SnomedCT. A Blizzard is coming.
Read Codes.
Read Codes are no more and for those who are unaware we are in a state of flux quietly having to change over to SnomedCT for all coding in primary care. As with most things in the NHS Read Codes are a shining example how to take a promising concept and totally shred it to pieces. We seem to be good at taking good ideas, involving as many people as possible to add their 2 cents to the fray and let it slowly suffocate to become an unwieldy mess which it ended up as. The vision of Read Codes were sound yet flawed: to have a hierarchical view of all things in primary care so an anterior MI is a form of a MI which is a form of Heart Disease the more down the tree you go the more granular the description. Where it fell on its face was on crossover concepts and as we know medicine is never that simple for example is TB a lung condition or an Infection? I know let's put it in both the Respiratory and Infection Disease Main Branch! Read Codes soon turned into a guessing game to work out which codes were used for what and you had to have a myriad of codes for the same item just to cover your bases. However, they are simple to understand and have served us well over the last 33 years.
I even did a one-page crib sheet on Read Codes as shown below
SnomedCT.
Enter SnomedCT. The vision is to encompass medicine and all its complexities into reproducible code which is more accurate and descriptive of the item you want to code. One thing I really like about SnomedCT is that unlike Read Codes, SnomedCT separates out the logic for the user. Whereas some Read Code knowledge was essential, we don't and are encouraged not to know any SnomedCT codes for any associated text and that's how it should be. We worry about the text and let the computer convert it into a standard format.
Unfortunately with this comes a lot of complexity and unpicking SnomedCT from the start isn't easy. I don't really understand the detail but this is my simple take on it which I hope you may find useful as a starting point.
For each item, you have up to 3 associated features
The Concept- This represents the item and is important as it forms in the links in the chain connecting this item to other items, for example, the ConceptID for a MI is Myocardial Infarction (disorder) = 22298006
The Description - This represents synonyms associated with the linked Concept one of which has to be the same name as the Concept which is called the Fully Specified Name or FSN . For example, Myocardial Infarction (disorder) is also a DescriptionID (751689013). So for this Concept, we also have a preferred term or PT and our synonyms or S.
For Example for the above mentioned MI we'd have
FSN - Myocardial Infarction (disorder) whose Description ID is 751689013
PT - Myocardial Infarction whose Description ID is 37436014
S - Heart Attack whose Description ID is 37443015
All the above synonyms or DescriptionID would link to the same ConceptID which is 22298006
The Relationship - This is the complex bit and defines where the item lives in the hierarchy. It's not as easy as Read Codes and addresses problems where an item can be all over the place. Relationships only use Concepts. They also have a Destination Concept which tells you where this item is heading to in the hierarchy. But most importantly they have a characteristic which tells you about the relationship between the source and destination concept. It kind of acts like the glue between concepts.
We can only do searches on Concepts (or Descriptions which map to the Concept) and let the SnomedCT engine define the interactions between this Concept and other ones linked to it.
For Example Appendicitis (source) can be
- An Inflammation of the large Intestine (parent)
- A Disorder of the Appendix
- A location (also called Finding Site Concept) which links to Appendix Structure
- A type of morphology (also called Associated Morphology) which links to Inflammation
The type of link is called an attribute and is defined as the typeid in the relationship file specification. So, for example, you can differentiate if a concept is a body|anatomical structure or a clinical finding in relation to another concept. From what I've been informed, these attributes however at the moment aren't being used fully at the moment.
An example of this is shown in this diagram from the SnomedCT Browser
For the techies, the RelationshipID linked to the concept must have metadata which provide a mapping linking Concepts like a linked list. We just know that this Concept links to another concept which links to another concept with the associated relationship of a certain type.
For every given Concept it has references to the parent and child node so you can only go up and down one hierarchy level.
This is a crude diagram of the above points.
Useful Resources.
The UK Version of SnomedCT
https://termbrowser.nhs.uk/?
A useful mapping lookup Table to convert Read Codes to Snomed CT
https://hscic.kahootz.com/connect.ti/t_c_home/view?objectId=407588&exp=e1
A good introduction into SnomedCT for GPs
http://www.nwyhelearning.nhs.uk/elearning/nhsdigital/SCT_Intro_GPs/index.html
For the more techie, I found these to links useful
Describing Concepts, Descriptions and Relationships
https://confluence.ihtsdotools.org/display/DOCTIG/3.1.+Components
Describing File Formats for the above
https://confluence.ihtsdotools.org/display/DOCRELFMT/3.2.+File+Format+Specifications
Mapping of Read Codes V2 to SnomedCT Codes in XML
Mapping of Read Codes V2 to SnomedCT Codes in Excel
Nice Visualisation Tool for SnomedCT
In the UK we have mapped Read Codes to SnomedCT as a first stage. After this, we can then move into the world of SnomedCT. Just make sure you keep warm!
I'd like to thank Dai Evans for looking over this post for me.
Photo by StormPetrel1 on Foter.com / CC BY-NC