Well, it appears Google and Microsoft are going to clash once more. As you can read here Google is going for PHR too. Not many details for now, but I’d like to see how these two 800 pound gorillas are going to tackle the usual problems. Healthcare IT is tough, it is so tough that even these two giants can get burned. Let’s wait and see.

Ok I was planning to write a few word about this, actually more than few, but I realized that I won’t have the time for a long post for a few weeks, so here it is: a few points about PHR.

Personal Health Record is a concept which is not generally pronounced as much as EHR, at least not in my usual environment. However, PHR has some very interesting opportunities, which deserve another post on its own. What I want to point out is that, Microsoft seems to be investing in the idea with HealthVault . It is not only Microsoft however, according to this article American Heart Association, Johnson & Johnson LifeScan, NewYork-Presbyterian Hospital, the Mayo Clinic and others are joining the initiative with Microsoft. Now when you have such big boys in a game, that’s a good one to have a look at.

IMHO, key advantage of PHR is that it might relieve the legal burden related to privacy of health data, since it is controlled by the patient. When the legal constraints are weakened, technical issues become more easy to deal with. There are still many things to consider in terms of privacy, security etc, but PHR can really take off. Maybe this might be the key to accessible health data, maybe PHR might be a better approach to the ultimate challenge in medical informatics: sharing data.

I’d like to say that I see another opportunity here: PHR might be a very good application of EHR related initiatives. EHR related work is large, it is huge actually, and covering such large ground makes it hard for everyone from standards people to implementors. I’d really like to see a group of people, say from OpenEHR working on a backend, for a subset of PHR, for example in cardiology domain.

Please ask yourself what is the holy grail of healthcare information systems? Your answer might not be same as everybody else’s but you can be sure that quite many people will name “interoperability”.

Interoperability has been one if the most demanding, challenging demands of healthcare, and to be honest despite all the work, the problem still remains. However, at least we have standards like HL7 which has been alive for the last 20 years, we have initiatives like OpenEHR, EN 13606 etc. You can spend a lifetime on these subjects, and I actually know people who have done so, but for the moment let’s try to dream of that sweet future where we have no interoperability problems.

In this feature, since you can easily plug in to any data source “technically”, you can now move healthcare data around, save lives and be happy and rich (this part of the dream is for heatlhcare IT people) Right?

Wrong! By that time (I’m afraid to give a year) you’ll still have the issue of privacy, and legal constraints related to it. So even if you were able to seamlessly connect data sources, you’d still have a hard time moving people’s data around, since you need to deal with legal issues.

People have the right to demand that their sensitive information is handled and used in a proper manner. The proper manner is a vogue definition, but it is for sure that anonymity for health related data is a strong demand. Considering the very large amount of data that we are collecting in healthcare, there appears to be a very promising opportunity: all this healthcare data can be reused. Research, analysis, quality assurance, performance benchmarks, you name it.

It is very hard to find actual health data, since you can’t just go to care provider and request their data for the last 10 years, whatever your intension is. Even if you do not care about the format of the data, you can’t, unless you get data that  can not be used to identify people in the care process. If however, you can get data in a form that is still consistent (same patient’s data for say 2 years) but de-identified, you have a very interesting opportunity. Actually both parties have an interesting opportunity, you can reuse existing data for a completely different purpose, and the care provider, patient or community can benefit from the outcomes.

To accomplish this, we need de-identification. This is a well recognized requirement. Jamia has this document that provides a good starting point. NHS is also aware of this requirement, and Sapior provides a product that is also being used in the NSH. Sapior provides this link which says that according to EC, pseudonymised data is not subject to data protection act! This is very interesting news actually, since it might basically open the doors for a second hand healthcare data market in EU.

For USA, things seem to be a little bit shaky in legal domain. HIPAA de-identification rules provide guidance for de-identification but HIPAA does not seem to cover all institutions, so secondary health data related operations might be problematic in terms of legal constrains. The issue is well recognized, and seems to be goings somewhere both in UK and USA. I’d love to hear what’s going on in Australia by the way.

Finally, it seems to me that de-identification is a very good candidate for a service layer that sits on top of a EHR repository. Anyone hearing this from OpenEHR?

Check out web for open source de-identification, pseudonymization frameworks, and you’ll see that not much exists. IBM has a product for this purpose, but for healthcare, this still seems like an important requirement without serious effort for the solution. I’d love to be corrected about any of this, if there is something wrong with it.

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.