Clinicians are struggling to use SNOMED coding to capture information about patients because it is technically too hard to do it, particularly at the bedside, EHI Live 2012 was told.
Charles Gutteridge, who combines a role as national director for clinical informatics at NHS Connecting for Health with clinical practice as a consultant haematologist at the Royal London Hospital, described how he and colleagues are using SNOMED in Cerner Millennium in outpatient clinics and to build research databases.
For example, Dr Gutteridge said he spends 30 minutes before each outpatient clinic coding data from GP letters and uses this as a basis for history taking.
He uses SNOMED coding at multidisciplinary handover meetings, with codes added to patient’s notes as the team discusses each case.
With colleagues in the emergency department and informaticians at CfH he has identified a sub group of sickle cell patients with very high use of emergency services.
Nurses are now coding for VTE assessments while doctors in multiple sclerosis have started to build a research database linking risk factors and place of birth. But the use of coding at the bedside remained a problem, he admitted.
“This is about the ways that different clinicians work,” he said. “I do it in my outpatient clinics but I really think that it is a challenge when you are walking from bed to bed. The portability question is very challenging.”
Where there had been success in persuading clinicians to adopt SNOMED it was either because they are researchers “who totally get” the opportunity coding offers to or because he had made a personal intervention.
“That’s not scalable,” said Dr Gutteridge. He called for developers to continue to explore ways to make coding portable by developing new user interfaces.
© 2012 EHealth Media.
You might conclude therefore..Infoman 86 weeks ago
A (very) small minority of health professionals would gain benefit from using the richness of SNOMED for research but ic can only be small scale because:
The (vast) majority of health professionals don't have time to use it fully and want simple "pick lists" containing a few hundred terms. If you condense SNOMED down to pick lists, aren't you re-creating a pusedo-coding scheme. If so why not use one of the existing ones?
Where it might be used, there seem to be concerns regarding inter-professional and or system driven mis-reprepresentation of concepts. Isn't this a patient safety issue but as yet un-tested / proven.
Any wonder the case for implementation hasn't been made even after ten plus years of promotion by its authors and advocates in DH and CfH.
Indeed the challenges for implmentation haven't changed since the NHS Information Authority directed the classification and terminology teams to identify the conditions under-which it could be implemented. Hence its never been mandated.
Real time use of terming beyond researchCharles Gutteridge 86 weeks ago
One rich use of SNOMED terms which has universal application in the health system is for transfer of termed information between different professionals. Populating a discharge summary with SNOMED terms from a problem list is popular way of automating a discharge summary at our group of hospitals. For example we have a rule in the emergency department that every patient being discharged from the ED must have a minimum of one code added to their EHR. This problem(s) is sent with attendance data immediately at discharge to the patient's GP and dropped into the patient's record. Another area where I see use, is getting to granular level of clinical detail which cannot be picked up in ICD10 coding. For example hepatologists, acute physicians and psychiatrists are seeing an increasing number of patients with Wernicke's encephalopathy in young binge drinkers. All are at risk of developing Korsakow's syndrome if not promptly treated. This is an important public health problem because irreversible dementia in young poeple has massive resource implications. There are no ICD codes for Wernicke's or Korsakow's so the population health question about how we are dealing with this problem cannot be answered from HES data. Point of care terming using SNOMED or the subset in CTV3 does allow this.
Re infoman - automated coding after the factjamesfone 86 weeks ago
Re infoman's and milo's comments, automated or semi-automated coding is something that I'd be keen to hear about experiences with. (I realise that the Linguamatics software isn't quite the same thing).
Alsoseem to be offering something like this, I expect there are others as well. Can't comment on either of the above.
From my very limited non-live experiences with a SNOMED text-parser (5 or so years ago) the results of automatic code identification were surprisingly good, but not quite good enough for patient-safe uses e.g. decision support (for the reasons mentioned earlier in the thread).
Has anyone got first-hand experience with a more up-to-date system?
Spelling issuesjamesfone 86 weeks ago
I note that you (Dr Gutteridge) used the spelling: Wernicke's and Korsakow's, and if you had been searching on an ICD-10 search that was looking for strict matches then you might get no result (i.e. the 'w' instead if 'v' and the ''s'). I.e. this may explain why you'd not previously found them if using an ICD-10 search implemented in a brittle way.
The WHO ICD-10 browser does tolerate the 's but not the w rather than v.
SNOMED also supports the spelling Korsakoff as a synonym (but not Korsakow), the WHO ICD-10 search doesn't tolerate the ff spelling.
This brings us back to the original point about the UI used for coding. I.e. that clinician's may use
a) Accidentally incorrect spelling (mistyping) e.g. Korswkov
b) Spelling which they believe is correct and use habitually, but isn't correct e.g. Korsakow (when testing clinicians using a SNOMED browser this was a more common occurrence than I'd expected)
c) Alternative and valid spelling e.g. Korsakoff
Whatever terminology / classification you use, you may want to have a system that elegantly handles the above situations, rather than requiring perfection every time. Progressive matching can help, as can synonyms, but these won't work for everyone all of the time.
If you were using text-parser approach for coding, then you can combine this with a spell check to flag up potential issues, which once resolved can be coded.
Real time use of terming beyond researchInfoman 86 weeks ago
I think we all understand abnd support the need to improve the capture of relevent clinical information to support direct patient care, public health and research but are clinical terminolgies the answer? Not with standing mrtablets reply, you could use plain English and adopt solutions like those offered by compaines such as Linguamatics (I have no interests in this co) - see http://www.linguamatics.com/welcome/solutions/life_sciences.html
Thesetools create classifications, ontolgies and quantitive research data from textual and coded sources.
When CTv3 and Snomed were good ideas these types of research tools just did not exist. techology and the world of infomration retrival has moved on.
Bad example of ICD-10 'failure'mrtablet 86 weeks ago
ICD-10 E51.2 Wernicke encephalopathy
And I'll leave you to search for the many Korsakov codes.
You have to look very hard to find an ' important public health problem' that isn't well covered in ICD-10.
What is different when mobile?jamesfone 86 weeks ago
In this specific instance, it would be useful to know what is different between Dr Gutteridge's clinic setup and his ward work setup. I.e. why is portability a problem for Dr Gutteridge?
Is this about:
- Touch screen vs mouse & keyboard?
- Screen resolution?
- Not having a mobile computer at all?
- Slow wireless connectivity meaning that searches take longer to run?
- The clunky UI mechanism for coding that seems ok in outpatients now seems slow when under more time pressure on the ward?
- Getting people other than himself to code clinical data?
- The clinical data recorded on the wards is different to that in outpatients?
- Wanting to code different kinds of data when on the wards?
- Different note structures used on a wards vs outpatients?
- Something else?
It's not clear from the article - Dr Gutteridge could you clarify?
Work intensity and speedCharles Gutteridge 86 weeks ago
The complex answer is that all of the suggested problems are ones that need work. The key issue for medical and nursing staff in ward environments is that the work is done standing, in groups and at high speed. For example, the post take ward round will usually involve at least 3 doctors and one nurse. The round is likely to need to include 20-40 patients. Each patient will be assessed and a plan developed. Systematically adding terms to an EHR while around a patient bed or chair and keeping the focus on the patients is a challenge and one where different doctors and nurses will have personal preferences.
As a consequence adapting whole hospital approaches that allow flexibility in use of device as well as flawless connections is an opportunity that many IT departments relish but may not always be able to supply. The bedside data is similar to outpatient data but not exactly the same because the nature of acute medicine and surgery is that a wider range of problems are seen than in specialty clinics - the interfaces have to be smarter and more adaptable. We could delve deeper but I think the key issue is work intensity and speed. The pull for doing this kind of bedside terming is the data that comes out of of the other end and I think we are all working on developing better analytics based on SNOMED but those software tools are still not easily accessible with applications for the training doctor in the form of decision support or the leading doctor who wishes to shape quality and drive improvement.
Why code anything?mrtablet 86 weeks ago
Coding (as opposed to free text entries) in an electronic record has purpose only when
1. the person entering the code has a clear definition of the code (concept) in their head, are sure it applies to their patient and know why and when they should pick it for this patient's record.
2. the person reading the code (or the machine querying/reporting it) share this understanding.
So a priori would you rather try to achieve consistent coding (i.e. data entry standards) for
International Classification of Primary Care 2 - ~3000 codes
ICD 9 ~8000 codes
ICD 10 ~15,000 codes
Read 2 ~80,000 codes
Read 3 ~250,000 codes
SNOMED plus UK extension >400,000 codes
Apologies for apparently conflating classifications and terminologies - but coding directly using classifications is done by clinicians in some countries.
Number of codesjamesfone 86 weeks ago
I agree with the two premises (in mrtablet's post), and certainly recognise the issue about 'what has to be coded?', but I'm not sure I follow the conclusion, which appears to suggest that using the smallest codeset possible is desireable to achive an easy mapping between human and machine understanding of the code. Sorry if I've misinterpreted this conclusion.
There are over a million words in English, and an individual's personal vocabulary may only be around 10-30,000, but we don't say that we should cut down the total to a common set that each human can handle. Different people use different words and require different levels of detail.
Further to this, given the large clinical vocabulary that an author already has, it is likley to be easier to map to a code the larger that code set is, rather than having to abstract up.
Subsets / heirachies are one way of restricting the possible codes that a given author might want. Though I'm not aware of a way of automatically restricting the 'level of detail', a well designed search / text-parse means that you don't have to worry about all the detailed children of a term - you just use the one you want.
As timbenson says, the level of detail required will depend on the circumstance, and therefore if you use a codeset with only 3000 codes, then you are going to run into trouble pretty fast if you want to do more than a minimum.
Working on free text alone has the additional problem of spelling, i.e. unless the text was corrected at time of writing, then any search on the free-text will either have to ignore the misspelt words, or factor in standard spelling checking when searching - with obvious problems for accuracy. However, free text is probably pretty good for a lot of purposes, especially if combined with a good spell check and a policy on authors using it at time of writing.
Abbreviations will always be a challenge unless clarified at time of writing.
SNOMED not only big because it is more granularmrtablet 86 weeks ago
>There are over a million words in English, and an individual's personal vocabulary may only be around 10-30,000, but we don't say that we should cut down the total to a common set<
SNOMED is more analagous to a semi-structured word list drawn from multiple languages each having distinct grammars. 'Grammar' here is the data model of the host electronic record system.
Thus the same thing may be represented in many different ways in SNOMED which are NOT currently equivalent within the SNOMED object-attribute-value or context models.
SNOMED also includes concents from multiple disciplines - and what for example constitutes a 'diagnosis' in nurse speak might be unrecognised or (more importantly) misunderstood by an occupational therapist, dentist or a physician.
It is not simply a matter of SNOMED having greater granularity that accounts for its size.
By attempting to fulfil all uses cases within any host data model, SNOMED is IMO currently poorly tractible and lacks coherence.
Why code anything - continuedtimbenson 86 weeks ago
Quite right. There are three good reasons why computers need codes:
First, in metadata to search for what you want. Here, high level course grained categories do most of what you want.
Second, when you need to count how often something happens. Here it is important that information is complete, so that in a percentage, we trust both the numerator and the denominator.
Third, when you need to do an exact match to check that X really equals Y and here the level of granularity required depends on the individual use case.
Free text is fit for purpose for everything else.
SNOMED text-parser UIjamesfone 87 weeks ago
Aside from; form input, multi-parent 'tree' browsing, and the usual single concept matching searches, the Common User Interface team spent some time investigating the 'text parser' approach to SNOMED coding. In particular a setup where the parser runs in real-time on the narrative, flags up codable terms, then the author confirms these, leaves them uncoded, or edits the term suggested (just like a spell checker). The designs are publically available at
The matching achieved by the prototype (not accessible anymore) was pretty good and a lot of the time the top match would be a good fit. It could even handle non-elaborate negation and laterality. This would suggest that an automated-behind the scenes coding would be fairly useful for some purposes.
However, problems included:
E.g. negation, false positive and false negative. Despite the CUI parser being pretty good, if you were coding in order to facilitate something 'really important' like decision support or an automatically extracted clinical findings list, then you will almost certainly need human validation of the coded term. Ideally, but not necessarily, by the author at the time of writing.
What to code
The crucial question. One I'm sure that has been much discussed in relation to GP coding. As I understand it, for GPs there are more obvious causes for why to code: QOF, their system's degree of decision support, etc. Even with the best UI in the world, requiring a person to encode the 100 possible codable terms from narrative of 500 words, probably won't have a happy ending. As such you need a policy on what should be coded, with clear justification. This might be facilitated by subsetting such that only some codable words are flagged up.
Level of detail
E.g. eye infection > parasitic eye infection > parasitic conjunctivitis. Also relates to the post-coordination point raised in timbenson's comment. The CUI text parser gave post co-ordination a try (I think), but it gets pretty mind boggling. Also, if a note mentions that the patient is 'planned for a wedge osteotomy of the 5th metatarsal on their right foot', should this always be recorded as the fully post-coordinated phase? Or will 'osteotomy' do? Does this vary in different situations?
E.g. who does this code apply to, and when does it apply. In the case of clinical findings: is this a family history of MI, a past broken leg, a planned appendectomy? The SNOMED context model and CfH's 'clinical statement patterns' might handle this, but how do they get applied to the code in the case of a text parser? (especially if not human validated)? There was the idea that if the narrative was part of a form that had coded headings (e.g. family history) you could make a stab at this, but it still wouldn't be 100%.
Pete Johnson & Ben Luff were the leads for the CUI's SNOMED UI work, I just looked over their shoulders. So I hope I've not misrepresented it here.
SNOMED is a brilliant ideaJoe McDonald 87 weeks ago
but so was Esperanto.
People are unwilling to learn a new language no matter how much it would improve things. If we can have the translation from current language to SNOMED automated by machine then it might get some traction, otherwise it will continue to remain a brilliant but unloved idea.
Case for SNOMED hasn't been made yetbeto 87 weeks ago
There are at least a couple of problems facing the adoption of SNOMED.
Firstly, the clinical case for coding medical records is made on the basis of hypothetical, often secondary, benefits rather than empirically proven clinical benefits. For example, does SNOMED really preserve semantics? Analysis so far suggests that variation in coding practice causes a loss of semantics.
Secondly, as Alan Rector has shown, there are some serious problems with the logical structure of SNOMED (Getting the Foot out of the Pelvis:
Modelling Problems affecting Use of SNOMED-CT
Hierarchies in Practical Applications - available from his webiste)
SNOMED is fit for purposetimbenson 87 weeks ago
15 Years ago Jim Cimino wrote a paper called Desiderata for Controlled Medical Vocabularies in the Twenty%u210First Century (Meth Inform
Med 1998; 37:394%u210403) in which he listed 12 fundamental problems with traditional coding schemes like Read V2, ICD10 and OPCS4. The developers of SNOMED CT accepted this challenge and SNOMED CT solves each and every one of these problems. The developers also built in a facility for implementers to create up to 10 million extension namespaces, in which people could create additional concepts and terms not supported by the international core. Rather surprisingly, the administrators have chosen to be extremely parsimonious about issuing namespaces and have argued instead that anyone who wanted to add new items should use post-coordination in preference. Post-coordination is not in the Desiderata and adds substantial complexity for implementers. The advice to use post-coordination for even such simple things as distinguishing between left and right eyes or arms is an own goal. It is perhaps the main reason why the routine use of SNOMED CT remains so low, more than ten years after its publication.
Maybe I'm over-simplifying things but...milo 87 weeks ago
Surely the most elegant solution is for the coding to happen behind the scenes i.e. done by "the system" as data is entered. To use an analogy of a computer keyboard, users do not need to know how the key presses are converted into an electrical signal, but they do need confidence that what they type is rendered on the screen.
Consistent SNOMED coding obviously requires a considerable effort to design applications that do this as data is entered. This can be helped by using pick-lists rather than free text, but this is much easier said than done.
System Challengestarslikedust 87 weeks ago
It's quite hard to implement in systems as well, but the main problem is that READ and ICD are often just good enough. If you are challenged to deliver the minimum viable product, SNOMED is often seen as gold plating. In reality, I think the problem is that the benefits of interoperability are accrued elsewhere and we don't have a way of recognising this.
Headline is misleadingKen Lunn 87 weeks ago
Having read the content of the article, and knowing Charles' views on the matter very well, I do not understand how the headline was derived.
"Too hard" for what? It is hard to capture electronic data at the bedside, full stop. The call was for ways to make coding more portable.
The headline is at best a misrepresentation of the article and highly inappropriate.
TweakedLyn from eHealth Insider 87 weeks ago
Hi Ken. Thanks for the comment. The original headline for this story was posted at EHI Live and just said that SNOMED was 'too hard'.
On reflection, this didn't really capture Charles Gutteridge's views properly, so we've tweaked it - and the intro - back in the office.
The story explains quite clearly how he is using SNOMED, and his own comment expands on the issue of portability; so I hope the piece will now provoke a constructive debate about that.
Yours, Lyn Whitfield, managing editor, eHealth Insider.
SNOMED is a key part of the EHRCharles Gutteridge 87 weeks ago
Adding SNOMED terms to a patient EHR needs to become a routine part of the clinical care of patients in hospital. It is a key to preserving clinical meaning from the user interface to the database and ensuring that the semantics of medicine are not lost. Clinical staff have no difficulty in understanding and using the concepts underlying SNOMED. The challenge lies in adding terms to a record when on the move in busy clinical environments such as medical admission units and emergency situations. So it is not SNOMED that is too hard but the fact that the current form factors that we use for data entry are not well suited for this purpose. I am sure that portability is key here as terming in out patient areas and in the clinic is simple and quickly develops the record for individual patient use.
Does anyone have an easy to use application for this?Jack Barker 87 weeks ago
Thanks Charles - it would be very interesting to come to see what you are doing. As described in the article I think it will be hard to roll out your methods to the rest of the organisation.
As I see it we need an electronic tool embedded in our EPRs, that helps us accurately describe the patient’s diagnoses, that is easy to use, that does not overwhelm the users with information, that supports the coders in relation to income, that helps us get our mortality risk adjustments correct, that links to local guidelines, that is readily auditable, helps us identify patients for research and readily interchanges with our primary care colleagues. It’s a big ask!
This has to be achievable for dedicated (and not so dedicated) clinicians in clinic and for junior doctors clerking patients in, and doing their ward rounds.
Does anyone have any other successful working examples we can look at? Have you managed to get organisation wide adoption? I wonder whether the solution is in the primary care systems?
Could someone comment on the relationship between SNOMEDCT and ICD-10. I thought our coders used ICD10.
SNOMED and ICD10timbenson 87 weeks ago
ICD-10 deals with diagnoses at a high level, useful for public health, commissioning and international comparisons. SNOMED is a clinical terminology designed to code almost anything that can be found in a clinical record. SNOMED has about 20 high-level hierarchies, one of which is Clinical Findings. Diagnoses are a sub-group within Clinical Findings. SNOMED contains more than an order of magnitude more concepts than ICD-10. Furthermore ICD-10 fails to meet almost all of the requirements set out by Cimino which will mean that ICD-11 will only have limited compatibility with it, as did ICD-10 with ICD-9.