SNOMED CT Implementation & Adoption as a Technology Transition – Lessons from Java’s Evolution
During my day job and my voluntary roles (at IHTSDO), I’ve often heard people say things like SNOMED CT is complicated; ICD does the job quite well, so why should we move; My systems wont support SNOMED CT; and more on those lines. To me, all these sound like moving from A to B, where
- A: Given state of clinical information systems – using simplistic coding systems
- B: Future state of clinical information systems – using sophisticated coding systems
In this case, it just so happens that the future state is SNOMED CT. But the means and the way this future state can be achieved is no different from many other technological migrations we’ve witnessed and taken for granted over the years. While I could use the iPhone analogy, I choose to compare this with a similar migration that the software world made from C++ to Java. In this case:
- A: Given state of software development – using C++ (pointers, native binaries, performance)
- B: Future state of software development – using Java (garbage collection, platform-independence, web support)
SNOMED CT is like Java – The Novelty
Now, just like SNOMED CT, I am sure a lot of people argued (and still argue) that Java is bloated, slow and does not compare well with faster, native executables that C++ produces. People similarly argue that SNOMED CT is complex, bigger and makes it difficult to use in some cases. To me, this sounds like a C++ developer complaining that Java does not provide features like pointers or does not allow full control over memory. I mean, yes a good C++ developer can create brilliant applications in C++, but unless s/he stops thinking like a C++ developer, s/he is unlikely to gain any of the benefits of Java (garbage collection, memory management, etc). Similarly if system developers do not understand enough about SNOMED CT and keep trying to ‘beat it into shape’ to fit previous paradigms of ‘data dictionaries’ and ‘simple, exhaustive code sets’, then the ‘pain’ in beating SNOMED CT into shape will be more than the ‘gain’ from using SNOMED CT. I am not advocating that system developers should give up all their previous experience of building clinical information systems and think only in the SNOMED CT way. On the contrary, they need to bring their past experience to bear but understand that SNOMED CT is in some ways fundamentally different to other coding systems and understand how to harness these features. Some of the often quoted features of SNOMED CT are:
- Multiple Inheritance: Concepts can have more than one parent
- Post-coordination: New expressions can be created on the fly
- Release Format 2: A more elaborate (log-append) style management of version history
- Size: Number of concepts and descriptions (terms)
While every single one of these features might be perceived to add an additional level of ‘novelty’ to SNOMED CT, it is not a ‘barrier’. For example, here is a list of Java’s features, which can be also ‘portrayed’ as ‘barriers’ or ‘weakness’:
- Platform independence
- Strongly typed syntax
- Automatic Memory Management / Garbage collection
Java’s often claimed weakness of slow performance (due to byte code compilation) is actually a feature. The feature is ‘platform – independence’. Yes, in order to support this wonderful ‘write once, run anywhere’ feature, Java had to sacrifice some performance by going via byte code. But isn’t that the reason why Java runs on pretty much most hardware from PCs to mobile phones to dishwashers to TVs? Similarly SNOMED CT’s multiple inheritance might appear to oddity to the conventional top down tree hierarchy were a node (concept) can only ever have a single parent node. However, it exists because a lot of times we want to be able to get to a concept (node) in more than one way (parent node). It is intuitive in medicine to do so and you can look at the often used ‘Bacterial Pneumonia’ example for more information.
Learning from Java’s Success – Approach
Now if you thought the reason why I started this rant was to show that I know something about both SNOMED CT and Java, then wait till we get to the next section. The reason why I like this analogy is because Java (despite its obvious oddities) went on to become one of the predominant programming langues in the software world. So can we do the same for SNOMED CT and if so, what can we learn from Java’s evolution that we can apply to SNOMED CT?
I see the following factors are being important in the evolution of Java:
- Opportunity: Appearance of the internet (we needed applets that could run via the browser on any platform)
- Documentation: Sun released good documentation (note I did not say excellent) The documentation can be grouped into;
- General documentation — available on Sun/Oracle site
- Technical documentation — Javadocs provided for Java and also with all 3rd party libraries
- How-to guides — Swing tutorials, Getting started guides…
- Books — including both Java for Beginners/Dummies and ‘Java Complete’ Reference material by third party authors
- Libraries: Java has an extensive set of reusable, third party libraries for specific functionality that makes it easy to create professional applications, without having to worry about all the plumbing. To me this is one of Java’s greatest strengths. So much so, there are so many open-source collaborations and libraries available in Java that it gets a little cloying sometimes!
- Collaboration & communication within the community — Sun enabled some of this via Java.net and once this ‘approach’ spread, it became the norm in the community.
- Skills Value Proposition: Clear relationship between Java skills & marketability — done via JCP or other certifications
In my opinion, a similar strategy for SNOMED CT might help it take-off to new heights akin to how Java did it. This is not to say that there isn’t already enough being done in this area and that there aren’t parallel activities being carried out in the SNOMED CT world. The following similar initiatives exist for SNOMED CT:
- Opportunity: Interest in national eHealth programmes — for obvious reasons, SNOMED CT is the de-facto terminology of choice for such initiatives
- Documentation IHTSDO released documentation — There exists plenty of documentation, but some of it is work in progress.
- General documentation – User Guide
- Technical documentation – Technical Implementation Guide
- How-to Guides — in progress
- Books — very few that can be called beginners or comprehensive texts
- Libraries — There seem to be very few ‘free’ libraries that make it easy for developers to create SNOMED CT enabled applications. Snofyre was an attempt to make a SNOMED CT API available to developers both as step-up but also as an education tool. I am aware of some other APIs, but then again I am not sure how far along we are in this space. Since I am the architect of Snofyre, I know that the Snofyre web site gets around 300 hits every month from different parts of the world. However, there isn’t as much activity on the forums. I might be partially responsible for that!
- Collaboration & communication within community — The IHTSDO sponsored CollabNet area exists for SNOMED CT related discussion. However, I am sure we do a lot more. The level of ‘openness’ for such communities has always been a ‘balance’ between complete freedom like on ‘Stackoverflow’ and the need to maintain some control since SNOMED CT is still a licensed product. I do keep ranting within the community too, to make this a little more ‘open’, especially material related to sharing SNOMED CT implementation experiences. We are gradually making progress…
- Skills Value Proposition: Clear relationships between SNOMED CT skills & marketability — The IHTSDO has recently started looking at Accreditation and there are plans to make a role/skills based curriculum available. Again, things are moving in the right direction.
So time and time again, I feel that if we could get enough developers to know ‘just enough’ about SNOMED CT and then provide APIs like Snofyre to take care of the plumbing, we might actually see SNOMED CT enabled clinical information systems appearing soon. While this isn’t the only approach, this is clearly one area where more work needs to be done and can happen outside the IHTSDO. So anyone who agrees and has ‘time’ to spare’ or ‘resources’ please get in touch with me! Together we might get this to the ‘tipping point’, where everything else just falls into place. Now, theres a happy thought for a SNOMED CT implementer!
Remember, all technology migrations are just one part of change management; so do not forget people, processes and technology!