In part 2 I’ve written about MS CUI. Actually I’ve written about the part related to developing a common UI for efficiently using coding systems. The efficiency in user interfaces is important, without usability, you might have trouble at attaching the minimum level of semantics to data that can be easily processed by software. However, front end usability sometimes demands backend precautions. Assuming you have a very nice method of making users choose items from a classification system, you are halfway through. The other half is waiting for you to cover it, by focusing on aspects like efficiency. Even the nicest user interface in the world can not make your users wait for ten seconds for a single key type while performing a search in a terminology.

When you have a beast like Snomed CT with over 350.000 concepts to search for, you have performance issues. You can not simply pull this data into memory and play with it, you’ll need a separate solution for this task, like a terminology server. Brian Levy gave an interesting talk about their solution, which is apparently what is, and will be powering NHS spine, and which is also being used by MS CUI team in their work in UK. Another interesting solution was in the conference room for to days, which was the terminology server of Ocean. Sam Heard and his colleagues were helpful and informative as always, and they gave me a nice tour of their work, which was very impressive when it comes to binding a terminology server to their archetype based GUIs. (By the way, Ocean team in general deserves a non existing award in healthcare informatics, for being the team that seems to be having the most fun while doing whatever they are doing, really cheerful people) Sam had his own presentation, but I guess their stand was naturally more informative in case you wanted an in depth tour of the subject.

The question that I could not ask neither to Brian nor Ocean people was about scalability. Assuming Snomed CT is a moving target with addition of new concepts, synchronizing the changes to a nationwide grid of healthcare information systems. For anyone who has been into healthcare informatics, this is a sign of trouble. How do you manage to diffuse changes to nationwide standards to actual systems? In today’s highly connected world, especially in Europe we can think about running a national service for it. In the most plain scenario, every terminology related search is directed to a national service (a web service is most likely to happen). In more realistic approaches, some form of caching in the healthcare institutions can be used, but still the huge scalability requirement for central service stands. The nature of the task is not very simple either, you have to perform searches in more than 350.000 items which are hierarchically connected. You need to scale up, where you must have a system that performs this search efficiently with a very large number of clients. Ocean’s solution seemed to be performing very well, given the very modest hardware it was running in the conference room, and it was probably using some serious caching. (In fact I can almost recall getting a confirmation for this) But what would happen if I wanted to run this nationally? I’d like to get some insight into this, since scalability is a black art on its own.

These two presentations was precious, they provided insight about a major component of terminology related functionality, the back end. There is a lot to discuss, for example, what kind of problems we’d face if we wanted to integrate these systems to our own systems? Considering the large amount of vendors in healthcare information systems, connectivity in the technical level becomes an important issue.

I guess the two major points that struck me in the conference for terminology related issues was: a terminology server is a must, and scalability is an important aspect of it.