Thoughts on SNOMED CT – a supplier’s perspective

The Information Standards Board have recently approved SNOMED CT (SCT) as a “fundemantal standard”, almost 10 years since its inception. At Bluewire, we would consider ourselves early adopters of the terminology – both Adam and I went on training courses back in 2003 and my Masters thesis in 2004 investigated approaches to derive SCT terms from natural language – considered a “holy grail” within health informatics (I don’t think we are much closer to this now than we were then from a technical perspective, and in the real world, there are significant cultural and user interface issues to be overcome if this is ever to become a reality).

From a commercial perspective, we have had little or no demand for SCT support from hospitals. The only place where we are using the terminology significantly is when recording drug administration using the dictionary of medicines and devices, which uses SCT identifiers internally. In turn, these can be used to drive decision support (we use First Databank) and so there is an incentive to collect the structured data. All of the national datasets that we use in a structured way (such as Specialty Codes) do not yet use SCT, and it is not always the case that hospitals use these codes internally anyway.

As to the future of SCT, I have some thoughts:

  1. There needs to be a strong commercial incentive for suppliers to support SCT. Initially, I think this will come as the national datasets migrate to SCT terms. After the low-hanging fruit, I think adoption will be much slower, and it will be a long time before we start to see SCT used for what is currently unstructured data and have the tools to take advantage of the properties of SCT which differentiate it from it’s predecessors.
  2. We need significant user interface innovation around clinical data entry if we are to start replacing unstructured prose with structured / coded data. Maybe tablets will provide the incentive here, since on-screen keyboard input is clunky, and it is an opportunity to start with a blank slate. This kind of innovation is tough in the risk-averse and commercially difficult NHS environment and, although tablets are in vogue, it is yet to be seen whether there is a market for software that really takes advantage of the platform.
  3. Collecting structured / coded data is very difficult if we don’t know how it is going to be used – if we could work this out retrospectively then it is effectively the same problem as automatically deriving codes from natural language.
  4. Hospitals and suppliers need better tools to manage and work with the SCT releases. At the moment, we are having to maintain our own internal SCT terminology database, applying updates and subsets ourselves. This is costly, and means that the terminology is only updated with new releases of our software. Under Connecting for Health there were noises about NHS-wide terminology services but we’ve never seen this implemented anywhere. At a technical level, there is little / no out of the box support for the standard platforms and development tools that most NHS-supplied software is built on. Where are the libraries and tools for developing against SCT in .NET or Java?
In short, I think there is a future for SNOMED CT, but it is still too early to see if we will ever be able to use it to its full potential and there needs to be pragmatic and practical guidance to drive adoption.