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.

Following part 1 , I’d like to talk about a little bit about the importance of user interfaces in medical informatics in general, their relationship to terminologies and Microsoft CUI as an important attempt. Snomed CT 2008 had many interesting speakers, one of them being a team member from Microsoft CUI team, who was accompanied by a colleague of his from the same team.

Their presentation was about the user interfaces they’ve been developing with NHS for Microsoft CUI, which I’ve mentioned before. Inevitability I recalled the past efforts during the development of a hospital information system by a team which I was leading at the time. I remember the solution that was produced in response to the coding requirements. Put a tree on user interface, and add something else, like a text box so that the user (presumably the doctor) can click on the tree with the mouse, or use the text box to type in some sort of keyword to navigate to related code on the tree easily.

This is a classical software developer response to a very, very important requirement in medical informatics. In fact, the flexibility and efficiency of the solution for this basic requirement is actually a shame on our account. Here “our account” is used to point finger to technical people who are in charge of creating systems that will be used by medical staff. This is a very common response by the way. If you get a bunch of developers and tell them to build a user interface that’d allow the user to select a code for a particular condition, they’ll ask you about the coding system. For most of the coding systems, exactly at he second the developers hear the word “hierarchy” they’ll think about a tree. Yes, a nice tree, maybe a little enhanced, like icons, or colored text for tree nodes etc.. But still, a tree. I guess a tree is the most common method we have at the moment for representing a hierarchy in the user interface, but its usability is not very scalable. In fact it is very likely that you will have a higher number of nodes in real life usage in a tree, than the development scenarios, and in real life, users will hate your tree.

Why focus on the issue with trees so much? Because it is a very common tool for technology supplier part of healthcare informatics, and it is mostly a major setback to adoption of information systems in many scenarios. Real life example: I had a urinal track infection, and went to see a doctor in a government hospital. The doctor simply asked for some tests, and she was using a hospital information system that was developed by a company that I also worked for in the past. She just opened the relevant screen for requesting lab tests, and clicked on a node on a tree, selecting a totally irrelevant code for the condition. Needless to say, I warned her, and the response was terrifying. She told me that the software forced her to perform a coding by selecting an item from the tree (we’re talking about ICD by the way). Smart is it not? No coding, no requests. But she simply hated the user interface, and did not have the time to struggle with it, according to her own words. So, she chose a random item each time.

Results? Well, how about messing up the whole effort for DRG even before it begins? Or not being able to do any fraud detection, or decision support, or any analysis on the data, when almost all doctors are doing the same for almost all lab tests. In real life, the government hospital will send this information to social security institution and ask for the costs, and usual analysis by the experts will see that some unrelated tests are requested for my condition. It is quite possible that the payment for the government hospital will be delayed at best, and you’ll have a heap of problems which are reflected on health of real people.

This is why, Microsoft’s CUI is very, very important. When technical people make assumptions about a domain without knowing all there is to know about it, (or all there must be known), the results can be devastating. Snomed CT conference showed one important thing: coding systems, which can be placed at a much lower position in the complexity scale, compared to modern medical modeling efforts are everywhere! They are way more common in implementation than the ongoing HL7 V3 or OpenEHR work, and you can not neglect this fact. Actually, the mentioned standards also recognize this fact. Some other presentations which I’ll mention in future posts also prove this point, everything from decision support to clinical guidelines use coding systems, they give you a simple method for adding semantics to raw data. But you have to allow the staff to use coding systems without causing loss of time to them.

Usability in user interface becomes so critical in some parts of medical informatics, that you can miss many opportunities for making good use of data, just because you’ve assigned the task of building the coding system for user interface to a regular developer, just someone from the team. Hopefull, MS and MDs from NHS will come up with better solutions for this minor looking but important problem, so that we can actually benefit from the data for which we’ve been spending billions to collect.

This is the first part of my comments related to CUI, and the second part is related to backend of the terminology that is used, which will be next post. That’s another issue that deserves its own post.