User interface design in health related software is a big problem. On one hand, you have a set of technical people who have a set of skills and produce results based on those skills, and on the other hand you have medical people who demand various functionality. The problem is, the skills and approach of technical people produce outcomes which does not always satisfy the users. In fact medical people rarely seem to be satisfied with user interfaces provided to them.
I can’t remember how many times I have heard the following sentence from a doctor, when asked what he/she would like to see on the screen: “I want to see everything”. From a developer perspective fitting everything on screen has two basic issues: first, providing a lot of information on the screen does not mean that it can be easily used. Second: a lot information related to various factors in care process (current medication, prior treatments etc..) means collecting data from a lot of sources. Even if they are found in the same system, it is not easy for developer to put them on the same screen. The fundamental problem with developers is: we are continuously conditioned to think in terms of sub systems, clearly isolated from each other. Call it modules if you want, or frameworks, or libraries. “Divide and Conquer” is our motto. We do it for better performance of subsystems, and for better maintaining code later. Unfortunately, doctors are not interested in our technical success in managing a large chunk of code, they want “Unite and Conquer” for information when it comes to managing care process.

Now add different opinions from different doctors about how a user interface should be to this situation, add different UI requirements from different medical domains, (you do not think that you can serve radiology and laboratory with the same screen do you?) and you have… a nightmare. To be successful in user interface design for a medical software, you need input from doctors, whether they work for your company or not. Check out successful healthcare solutions in software domain, and most of the time, you’ll see a few doctors somewhere in a company.

Simply put, Microsoft CUI (Common User Interface) is an attempt to build common user interfaces for healthcare and is backed up by the work in NHS in UK. I call it an attempt, since I am so used to seeing medical people who are almost always unhappy with other’s decisions, but I am actually excited about it. IMHO it is really nice to have medical input channeled into a piece of software. It allows you to reuse hours of analysis and discussion with medical people, and it is priceless. The method taken by Microsoft for reference implementation is to start a project at codeplex, which can be reached at http://www.codeplex.com/mscui You can download a reference implementation in .NET . The guidelines are at http://www.mscui.net Nice things about this initiative are: it is being developed in collaboration with NHS. You can reach the programme from here . Thinking about the size of NHS, the outcome of MS CUI has a very serious advantage, it is evaluated by medical people in very large scale healthcare system.

Now to the things I wonder: What kind of licensing is used? Will I be able to come up with a Java Server Faces implementation of design guidelines? Will I be able to port components in codeplex to Java or Ruby or PHP? I’ll write down about these again after I work a little bit on the documents, but I assume NHS has been clever in this one, to allow a broader adaptation of developed guidelines. I think the discussion in OpenEHR mail list is a good sign for adoption (read here). I’d like to know what other initiatives think about this, like OHF, Mirth etc..

Another issue is if this can be reused in other counties. I do not mean the general internalization/localization (funny these two serve the same meaning in software) issue. I mean I’d like to see how the doctors in Turkey for example respond to these components, which is generated by input of doctors in NHS.