Snomed CT Conference and Smart Healthcare Expo 2008, part 3

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.

Snomed CT Conference and Smart Healthcare Expo 2008, part 2

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.

One minute rant about Facebook!

Ok, will write this and go back to coding a Facebook app. Facebook, why on earth do you claim that you are giving an API to developers? There are so many quirks that one has to deal when building Facebook app, that you feel like there is a camera hidden somewhere in th office, and Facebook staff is laughing at you while watching you suffer.

The ajax infrastructure does something with the calls, so that your servers receive an ajax request three or four seconds later. If your server needs to get a piece of information (like friends of someone), than you can add another 3-4 seconds (at best). How can I claim that ajax improves user experience when a call takes 15 seconds? There is no surprise so many people are using iframe apps.

Now if you excuse me, I have to re-write some code that took almost 8 hours to write in the first place. All that time is gone to make sure that Facebook ajax functionality can not cover my requirements, which is a very, very basic case of ajax. I hate dealing with other people’s code, and software development has become almost all about it lately. Ok, ranting is over, time to code…

Snomed CT Conference and Smart Healthcare Expo 2008, part 1


Back from London, to watch an amazing game in Euro 2008 just in time, to see Turkish national team creating sort of a miracle . I just have to mention this. I can remember screaming and jumping around, probably breaking some of Zeynep’s stuff, and the rest is still fuzzy…

The main reason I was in London was to join the Snomed conference organized by Tim Benson from Abies .The event was quite dense, with some very interesting  presentations. It was held at the same place with Smart Healthcare 2008 Expo which was a different beast on its own. Tim deserves a big “Well done”, for the content and the environment he provided.  Too bad no one else from Turkey was there.

There are some many things to write, so a few parts will probably follow this. First things first: Snomed CT is a very critical piece of work, for it overlaps with many interesting domains. The conference showed this very clearly, from decision support to user interfaces, you need to make use of it. However, the strongest impression that I got from the speeches I’ve followed is: “we are in trouble”. We are not in trouble because we do not have necessary standards or methods, but we are in trouble because we simply have too many alternatives to do a particular thing given these standards.

Snomed CT is powerful, and that power can lead to (and I’m afraid it is already leading to) situations where we are pushing a particular technology  beyond its core purpose. Golden hammer is nice term for the problem, where a lot of problems which should be handled by other tools are simply regarded as nails.  The right level of Snomed use is a very critical question, and how to modify relevant technologies to catch that level makes this a multidimensional problem, which requires coordination among different standards bodies.

One of the presentations outlined the general view of HL7 V3 for integrating Snomed CT. HL7 V3 have always recognized the need for using existing terminologies, and there are some cases where you have the option of assigning the “modelling” responsibility for a particular medical concept to either Snomed or to the standard that is linking to Snomed.  I’m not sure if this is a clear description  of the problem at hand, let me try to explain it a little bit more: You can go towards an approach where you do most of the domain modelling with a standard like HL7 V3 or OpenEHR, and use a terminology only as an identifier, and a classifier for a particular “thing” contained in a wrapper artifact, like an OpenEHR archetype. When the terminology related standard has more expressive power then a simple list of things, there are now two ways to perform modelling for a particular concept; one in the terminology oriented standard, another in the container.

This kind of confusion is dangerous, and can lead to major problems in interoperability which is the primary reason why we have all these standards! There are also other aspects, like the reflection of these choices to tooling. Tooling is an often neglected (or cared less about then it should be) aspect of this domain, and we need tooling to diffuse our work in standards to actual implementations. We can not expect existing managers, doctors and even patients to emrace the learning curve of a tremendous amount of standards. Tooling is necessary to make a very large user base to adopt the work in more abstract layers, and I am not happy about the state of tooling in this particular field.

A limited set of tools are being developed for critical functionality, but when decisions like using “right amount of Snomed” are to be made, these decisions can dramatically alter tooling implementations. I for one, would be very happy to see a well designed solution in tooling to give the ability to adjust use of terminology related solutions in medical domain modelling, and that’s why Ocean Informatics is worth mentioning here.

They were one of the sponsors of the Snomed Conference, and they were as enthusiastic and helpful as usual. Now their solution for use of terminologies in Archetypes, deserves a whole post on its own, which is probably what I’ll do. The thing to say for now is: Ocean has been working hard! The terminology server was very impressive, especially considering the response time to web service calls. Snomed CT is not  a small piece of data, we are talking about over 350.000 concepts here.Well, I’ll write about other aspects in following posts, but as I’ve said in the beginning: Well done Tim!. I should not miss it next year either.