However, I realized that I can’t simply accept the usage of tabs in Chrome. It forces you to go through all tabs from left to right, and that is simply horrible for someone like me, who works with 30+ tabs regularly. There are no proper tab plugins to provide the kind of functionality that is provided by tabmix plus. Also there are minor but annoying problems in various web sites, some of which actually stopped me from buying stuff online.

So Chrome is gone for the moment, and I’m back to my old browser: Firefox. I’ll miss the performance, but it simply does not suit my usage, and it does not provide the necessary customization options.

One use for XML you can’t avoid in openEHR implementation is web services.I am talking about SOAP web services (for clinicians, this is Simple Object Access Protocol, this is technical domain, where our acronyms rule, not yours) If you keep hearing things like JSON and REST, well, they have their uses, but for openEHR implementation, I would not really consider using them, because in my view, they are simplification attempts for SOAP web services, which has become a little bit too complex. (actually, a major reason XML web services were created was that CORBA was too complex. Irony that costs billions…)

Now what is the problem with these web services? Well, they are very well supported by free and commercial tools, and they are quite mature. But they are fully XML based. When I say XML based, I mean they require use of XSDs for describing the content, the simple and complex data types that travel over the wire. In other words, two sides of the communication use XSD as a contract for data types and structure of data. Then they use whatever binding they want to use on their side to process this.

I still did not mention the problem did I? Well, XSD is good enough to represent many things, but there are certain aspects of software languages and formal models which can not be represented with XSD in a standard way. In the context of openEHR, the specification makes use of generics, a feature familiar to those who use any non-trivial object oriented programming language. XSD has no concept of generics. openEHR also uses constraints, and XSD has no standard way of representing constraints.There is an XSD on openEHR web site, but that XSD is not a complete representation of the openEHR RM.

This is a big, big problem. The problem gets bigger, since that XSD is being used to develop tools, and it is being used to develop web services. The idea of web services (the kind we are talking about) is representing concepts from programming languages in XML and then transforming them to implementation of those concepts in whatever language you use, when XML arrives to an end point. You have xsd:String as a type in XML world, and you map it to a Java string or  a C# string. You expect to construct something like a composition when XML arrives at your system, and at that point, you have a problem: the arriving composition is based on the XSD that is actually “not” the exact representation of your openEHR reference model. In your reference model, generics are used for example, but in XSD, you have a representation which can reflect the state of the RM once choices related to generics are made. In other words, there is loss of information.Many would say that it is good enough, but what is happening here is we have an on the wire representation of openEHR models that is linked to more conformant  representations (like C# or JAVA classses) in an ad-hoc way.

So the specification is 100% pure representation of what we may model, and C#, Java and Eiffel can come quite close to specification, with Eiffel being almost 100% complete, without much effort. XSD is way behind, since it has no built in way of representing some important aspects of specification, and as far as I know, we are all mapping from this incomplete representation to more complete representations with various methods. Any implementer ends up with a mess trying to do this, and we lose a lot of valuable cpu cycles.

Here is the scenario: XML arrives at the web service end point. It is parsed and values are put into a set of classes instances generated by tools. These classes are based on XML, so they have no notion of things like generics or constraints (sometimes the language can’t event support constraints) . This is reflected into signatures of getter/setter functions and class structures. You need to take these automatically generated class instances and now perform another transformation to put data into your implementation of RM. But your implementation would be using generics, so you have to look at the incoming data, and figure out what choices have been made in using generics. In Java, the implementation of generics is only for compile time, so you can’t even dynamically create instances of generic types in memory, unless you go through an incredible amount of trouble. Even then, certain things are not guaranteed or possible. Anyway, this is actually another issue, not the one I’m ranting about.In short, the expressive power of openEHR specification is weakened pretty much in any case we are using XSDs. There are solutions to these problems, but they do not have the overall elegance of the rest of the implementation of this specification.

I’ll write more on this in part 2.  Till then, take care.

Now I’ve written about Amalga more than 2 years ago,  and I was excited about what it may become. I was hoping that with support and competition from Microsoft, the hospital information system business would go forward. Competition in this kind of very high cost markets is important, and only actors with lots of resources can push this kind of competition.

It appears Microsoft was not big enough! I’ve always felt that it was almost impossible to sustain a business model with a HIS product, and solutions in HIS market would survive only if they reach a really large scale. Reaching that scale is very hard on the other hand, since HIS software is no small piece of software, and its entry into a new hospital always takes a lot of effort in every way you can imagine.

It appears the amount of difficulty I kept observing in HIS business was not overestimated. Microsoft has sold lots of products with no profits at all. They have been selling xbox consoles for years now, and I’m not sure they started making profit in that market, but they still push it for the future value.

They won’t be doing this for HIS market. This is a very important sign for many stakeholders. If MS can’t dare to scale up its operation in such a well known domain, what does it tell you?

What it tells me is: do not attempt to build healthcare IT products with large scope. The cost of creating such products is incredibly high, and it can easily take you down. Everybody has a lot to gain from building smaller, well connected, specialized solutions. Clinicians, software developers, and even patients. Microsoft’s exit from HIS market is not the only sign. CSC having lots of trouble in delivering Lorenzo in UK, NHS slowly walking away from the idea of big contracts for the whole country..

These are the signs that show that gigantic, magical all in one solutions are simply not affordable, not for UK government, not for MS. So what makes you think you can afford it?

Instead we need to focus on systems using the agreed, open standards, specializing in various clinical domains, but sharing information to help with the whole operation of healthcare services. HIS market is way too expensive for newcomers, and even the well established players are having trouble in addressing the needs of customers. It looks more and more like airline industry: economies of scale with thin profit margins, with survival depending on addressing as many customers as possible.

I can’t claim, with full confidence that the future of health services lies in small web based applications, but there is certainly enough signs to claim that the market is going to give this approach a try.

Ibelieve that EHR implementation is not taking off because of some fundamental problems, and I’ve written about them before. Check out my previous posts for anti-patterns in  EHR implementation.One of the things I have not mentioned (or maybe I did) is the lack of commercial motivation for investment in EHR implementation. Pretty much any project has a commercial aspect, and it offers some profit to one or more stakeholders. Sometimes though the offer is not significant enough to attract big players into the project, and at the end, unexpected costs lead to financial constraints and less then desired level of implementation.The big players are governments, private insurance companies, trusts (for UK) and private practices, and large IT domain players like Accenture, IBM, Oracle and Microsoft. However, if you have these names on the table, you have to be very careful to not to create a monster instead of a project. Unfortunately, what happens most of the time is that grand visions (with grand bills) emerge, and billions are spend while actual results turn into fairy tails.If you go for smaller projects like PHRs, the commercial driver, the motivation that comes from profits is hard to build and harder to keep alive.

People can’t really provide convincing business models for PHRs, unless the PHR is some sort of side benefit in a larger system. It is almost always about patients having access to their own records, which are kept in a bigger system.Don’t get me wrong, there is nothing wrong with PHRs, it is just that they are not very easy to commercially justify, especially if they are disconnected from other systems.What we need is smaller (read my anti-patterns posts), but commercially attractive targets for implementation. Smaller pieces of software, connected to major flow of money. GP software is a good example of this, especially for USA.

I’ve been thinking about  medical tourism for some time. It is normal for me to think about this: a visit to a dentist costs you hundreds of pounds for a very simple procedure in London, and if you have a fairly complex operation or a series of operations to have, good luck with that. Meanwhile, flying to Turkey, having the operations in Istanbul, staying at a nice hotel and coming back can easily cost you much less, and you’d probably feel much better at the end. Especially if you do not have huge amounts of money.The level of clinical care in many countries including Turkey, is surprisingly good, and the difference in cost is even more surprising. I can see a huge potential in establishing a proper “medical outsourcing” network among various countries. It would work for everyone, including payers, care providers and finally (and obviously) patients.The amount of cost savings would be huge, and many practices would love to offer prices which would be cheap for patients living in other countries, but still leave them a nice profit, quite likely to be higher than their domestic operations.

The thing is, pulling this kind of setup off would take serious investment. Ensuring that the practices performing the outsourced medical procedures provide proper care, dealing with legal issues around privacy and location of data (still matters a lot), and integrating financial operations is a much larger task than an EHR platform for shifting medical data. The benefit is huge though.Governments (think EU here) can cut off so much spending, they can avoid long waiting times for many procedures, and therefore improve care.Unlike many other use cases for EHRs, medical tourism can very easily justify the investment in money turns, and I think this is what makes it different. If you are a clinician or a developer you may argue that money is not everything, and EHRs should not be implemented on the basis of commercial aspects. Well, you may be right (you probably are), but in this world, money turns most, if not all the wheels, and if your approach is not adopting to the way the financial workings of the healthcare market is organized,  you are going to have a very, very hard time.I know I am not the only one who has thought about this, Professor Kalra mentioned months ago a project they have been involved in. I am not sure if anyone has focused on the huge commercial aspects of medical tourism (I’d rather call it medical outsourcing actually).From a clinical point of view, it is very hard to discuss priorities, and I’m not equipped to do this anyway. However, actual financial figures may get very powerful actors interested in projects which are quite small in clinical scope, which is hard to do. When a medical outsourcing network offers a couple of billions in savings, suddenly the funding for the core EHR system becomes incredibly small, especially compared to administrative work that must be done.

So maybe we are supposed to include these kind of use cases in our presentations and discussions more, to attract the financial support we need to build the better systems we want to build.Having seen many EHR projects fail even to get started, no matter what the clinical benefits are, I am more and more inclined to focus on services which would earn us the resources we need. Otherwise, I can’t see how we can break the cycle of half implemented, budget constrained, isolated projects.Medical outsourcing may allow us demonstrate all the benefits we have been promising, and it can help all stakeholders justify their investment much better than other setups.

This is not news to me, but I had hopes of being wrong about my expectations. I’ve watched Oracle acquire some very capable technology firms, focusing on Java, and one by one, they disappeared from the Java world. Sure, they existed, but companies like BEA, which used to be the topic of daily discussion in the Java world, for one reason or another, slowly faded away. In an amazing way, when a company is acquired by Oracle, the pattern seems to be the opposite of what happens when other giants buy companies. When MS, or IBM or Adobe buys a smaller company, you see their products getting well known, having a larger user base. When it is Oracle, they seem to go to that magical place where all good technologies go…

JavaFX, JRuby, NetBeans etc are not core Java technologies, but these are the links of Java to staying relevant. When you start ditching these technologies, or not supporting them strong enough, you change your course to being a legacy technology company. Oracle has been the giant of db world, and they have very very very good products in that domain. However, they are expensive, very expensive. They seem to offer no interest in any layer below large scale enterprise, and no, versions of their databases with 2gb file limits is not interesting for me, when I have postgresql.

So Oracle seems to pull every technology they acquire into their own ecosystem, in a way that would only help sell more back end products, and that is it. If Gosling is leaving, this is a bad sign. His explanation gives hints about what may have been happening, which is what people like me expected from the beginning. More people will leave Oracle, you’ll see. This is not going to kill Java or make it obsolete in the near future, but the trend is certainly not towards innovation for this technology, not with Oracle. I really hope that I end up being wrong about this one..

This is all the spoiler I’m going to give about Spin. As human beings we are capable of adopting to so many things. The hole in the ozone layer, hunger in Africa, wars, you name it. Spin is a good book since it depicts a realistic picture of humanity’s potential response to something as impossible and as shocking as described by Robert Wilson. Though I have to admit that it goes a little bit too much into details of a relationship between two people. In the grand setting of the events taking place,Wilson seems to spend too much time with the emotions of two key characters. At least that is what I felt.

There is quite nice science fiction in it, but it is weaved so deep into social observations and emotional challenges of characters, it takes some thinking to realize this. I think Wilson choose not to use certain aspects of his own setting, which would have produced a more interesting book, but the results are quite impressive anyway. Verdict: certainly worth reading.

The existence of a legacy system makes the process of EHR implementation much more complex compared to lack of it, and this complexity is usually not managed very well, leading a couple of repeating, hard to avoid problems. The definition of a legacy system is important in this context, since I am claiming that it is a part of an anti pattern. I’d like to describe the legacy system a little bit more, so that the upcoming problem definitions do not refer to a vaguely defined context.

A legacy system, in the context of this anti pattern, is a system which has an established user or more frequently a set of users in a healthcare institution. It is usually build with an older technology compared to new offering, or at least with a more traditional architecture. Database oriented, mostly monolithic solutions constitute the large end of the scale, and file and document oriented desktop applications (like many GP offerings) constitute the small end.   Given this hopefully better description of a legacy system, let’s see what kind of repeating problems occur.

Legacy technology issues
An EHR implementation, replacing an existing legacy system is likely to offer a more recent technology, and this is one of the main selling points of vendors. Cutting edge technology is a good label for sales meetings, even if people do not question the actual benefits of cutting edge technology given their roles. Established legacy systems, unless operated by an unusually incompetent set of people, are well setup. The operating systems, the network setup, security settings in the IT infrastructure, even the hardware is compatible with the software. New technology means new deployment and maintenance processes. A good example is a multi tier, modern piece of software replacing an Oracle forms based (or Paradox) software. A db server working with a couple of (sometimes many) clients, where they are relatively old computers, with older OSs. When a new EHR implementation with a technology that is at least two generations younger than the legacy software arrives, unforeseen consequences begin to emerge. You need to setup .NET framework, but that requires some other updates, or it does not, but when you start updating the computers, suddenly the legacy system stops working in some computers, or you need the latest version of Java runtime, and the update breaks something else. Unless you are performing an overnight migration (quite unlikely), you are in trouble, since you broke the existing system, and you are not able to offer an alternative yet. Assume that the setup went flawlessly, but you’ve just realized that the previous software was running happily with 14 inch monitors with a 1024×768 resolution, but your solution does not exactly fit into screen, or the screen estate is not giving a satisfying user experience. What? Everybody is supposed to have 17 inch monitors these days? I’m afraid that is not the case in many healthcare institutions. Or the screen estate is ok, but your software is running slow. A single patient admission operation which used to take under a second is now taking 10 seconds, and with each typo, this is leading to an unhappy queue. You are inclined to defend your solution of course, everybody knows that a multi tier modern software architecture distributes processing tasks to multiple layers, the back end db, the application server and to clients. It appears the decade old database technology did not require much client power at all! It is quite likely that technical people either knew this would happen, or guessed that it might happen, but they were not allowed to say anything that would put the contract in danger, and the sales people did not mention this to avoid either losses in the profits, or a more expensive offer. As obvious as it may seem, this situation usually causes a lot of pain in the first couple of months of many gradual EHR implementations. Someone has to buy faster switches, larger monitors, faster computers, install better networking and the financial and operational costs of these steps are not easy to neglect. Now to people.

Legacy people issues
Yes, legacy people is a valid term. No I’m not referring to people older than 85 or people who have slayed dragons in the past. I’m talking about the users who are very used to existing system. They know all the keyboard shortcuts,all the tricks and problems of the software they use, and they are absolutely not happy about learning the new system. Here are the things they’ll usually do, which lead to more issues. First of all, they are rarely consulted about a new system during the purchase, so they can’t easily justify the switch to new system. When they are exposed to the new EHR system, this will be during their working hours, and if it is not, they will certainly hate the system more. They will go into a room to either get training for the new system, or to provide opinions about the new system as it is being installed. Unless they have to use it in their daily routine, they will usually say that it is ok, it is working etc. So the training will be considered as complete, the project managers will put a check next to another item, and both institution management and the vendor will move towards deployment. When the deployment actually goes live, the same people who said that it was OK, will start complaining about missing features.  At least you’ll hear things like “we used to open up a patient’s data with this keyboard shortcut, now it takes forever since we have to use the mouse etc etc.” This is not always necessarily true, but it is usually a mismanaged situation. If the management can’t convince them to adopt to new way of doing things, they’ll turn to vendor and ask for changes so that the new system can look like and work like the old system. If you let this happen as a vendor, or if you let it get out of control, you are doomed. “But this is a web based application, that was a desktop application!” is not a valid excuse, they want their shortcuts, and the system is useless if the mouse pointer does not blink in purple when there is an error… This will get even worse when users begin to ask for more, this time related to legacy processes.

Legacy process issues.
One of the reasons for using a new EHR system is its ability to improve certain processes. Better patient safety, better decision support, or better connectivity to other systems. In order to do this, systems are designed to impose certain restrictions. A common use case is not allowing a particular operation without the consent of a key actor, like the doctor in charge. The problem is, when the new EHR goes live, this rule is reflected on real life processes. The process change is not announced or explained however, it is implicit in software. Users go furious, since they think that it is impossible to work with this new system, and this was how they used to work always. They ask for a change, they say that we should be able to enter administration of a drug without getting the doctor’s approval every time in some cases. Mostly they will  object to security restrictions, role based access and data integrity related warnings. They will complain, and at least for certain things management will again turn to vendor and ask for updates, so that certain things can either work as they used to with the legacy system, or various restrictions are relaxed. The implicit change in the way things work is rarely mentioned in the sales meetings, and this time even technical people can’t warn you, since they are simply implementing some technical requirements. They know nothing about how things work in the practice of medicine. If certain concepts are buried too deep into design, you are in deep, deep trouble. Probably a good example of this situation is turning a workflow supporting system  into a workflow based system. Sure, it sounds great to have a fully workflow based system. Every process has to be planned and documented before execution, and benefits are huge. When this approach leads to chaos in a hospital where no one has ever heard of process improvement, the vendor is forced to turn a workflow based system into a more flexible solution, but the whole system is designed to work on workflows! Even with all the analysis of processes done before deployment, users will simply say “this is not how we work”.  You now have to hide a fundamental aspect of your EHR solution, since no one notified users about what is actually going to happen once they start using the new system.

Solution?
Well, I can go into great detail about what the solutions are, but I’d have to charge you for it, so let me try to list the basics. Try not to hide the actual cost of your solution. In the short run you may think that you are a good sales person or CEO since you managed to get that contract, but in the medium and long run, you’ll end up paying the cost of technology upgrades, and your technical team will suffer trying to run their systems on top of hardware which was never meant to be the target for the solution. Make sure that you have a good estimate of certain cost items, like transferring data from the old system to new system, and include them in your price if you don’t want to lose a significant margin from your profit. This kind of tasks will induce further costs, and you’ll have a bad start from the beginning, which will certainly harm your reputation.
Make sure that you do not skip training about your system in a superficial way. If you can, hold people responsible. If users approve that software is OK before deployment, they should know that it is their responsibility to point out to missing features before the system goes live. At least they should be responsible for checking if the features they asked for in the beginning are there before the kick off. Make sure that the users understand their responsibilities. If you have managers which target reaching certain milestones only, who do not care about under what circumstances those targets are reached, you’ll certainly end up broke in the not so long run, due to hidden costs.
Try to explain all aspects of your system, with its implications on processes. Emphasize the problems that come up often. Most sales people avoid this, they fear that it will make the solution look hard to use and costly. First of all, you would look like a professional vendor, who has a deep understanding of what they are doing. Second, even if you hide this fact from your customer, the results will end up as cost items in your budget, you can’t escape it. On the vendor side, this situation is bound to happen if sales teams are simply done once the contract is in place. They get their bonus and walk away, but they are rarely held responsible for the following costs. Remember, maximizing benefits of people in your company does not necessarily lead to maximization of the benefits of the company itself.  These are not the methods all implementers follow, but this is a much more realistic mode of operation, where you have few surprises, which would lead to more satisfying implementations.

I am planning to write about business models of EHR solutions next, so see you then.

Suarez wrote a quite interesting book with Daemon, which I would call a pop tech thriller. What makes it interesting is its reasoning is build on things which exist today, and he is not pushing the limits too much, so technical people would not lose the aspect of believability  easily. If you are a little bit too involved with code, AI and distributed computing however, you may still feel that familiar “that would not really work ” feeling. Still, worth taking a look at.

My PhD is in a way focusing on the lack of perfection in certain domains, and accepting  it as it is, for better decision support. In the last 13 years or so, I’ve been involved in thousands of conversations with people demanding solutions, and a particular pattern in healthcare is becoming more an more obvious for me.

Almost all the stakeholders in the demand side of this discussion, always have very high expectations, and almost zero tolerance about what a proper EHR solution would look like.  We have a raining set of documents with tens of thousands of pages arriving in our mailboxes everyday. Everyone, and everyone is so diligent when it comes to providing opinions about what should an EHR implementation provide.  That’s good of course, seeing that attention to details. The only problem is, everybody, but everybody takes this huge amount of requests as indispensable. We must have perfect security, perfect performance, perfect simplicity, ease of use, you name it. And if you can’t provide these to the level we want you to, then this is not a successful outcome.

Really? I mean really? Let’s take a look at the level of imperfection in the processes and tools in healthcare. Any text about patient safety will tell you that walking into a hospital carries some incredible risks, even if it is only for a very simple procedure. What is the response to this? Well, it is a problem, and we need to do better. Good, but you are not shutting down the whole healthcare system because there are mistakes. Take a look at the tools. There is a sensitivity and specificity for many medical tests. There are gold standards of course, but you don’t get to use gold standards all the time, as they are sometimes too expensive, or invasive, or slow etc. The practice of medicine accepts this fact. Clinicians and administrators will explain to you the reasons behind false positives, and false negatives, and for those who are having trouble, check out this excellent paper from BMJ. Medical devices have their rate of error. Medical tools are imperfect, tests have their error rates, and yet, the practice of medicine is not grinding to a halt due to this. The very people who demand perfection in IT systems are running their operations everyday, accepting other deficiencies, and saying that they are continuously being improved. Whenever someone says that “but without proper <insert your favorite aspect of EHR implementation here>, the results would be disastrous!”, they should be reminded of the already existing disastrous results which is not stopping what they are doing. Believe me, they are not that hard to find.

So why is it the case that when it comes to EHR systems everyone keeps demanding perfection as a starting point? The world is full of huge projects soaked in vision and pan fried in indispensable principles. When they usually fail, the creativity which does not exist in the project itself is usually there to provide a perfect explanation for the failure. In fact, in many of the large scale projects, perfection only exists in justifying the mess.   This is mostly because the bar is always so high, and the scope is so wide. Demand side of things is always evolving into this outcome, and supply side is mostly happy about it, who would not love a millions of pound/dollars contract?

I am in no way defending lousy outcomes here. I am trying to understand why perfection is an absolute starting point, or a shiny frictionless base on top of which we should build everything, rather than being taken as a goal, arrived to in steps.  Iterative approaches can help a lot here, but people seem to avoid them passionately. Perfectionism is good, but how come you accept lack of it in almost every other aspect of your practice and demand it for EHR systems?

I’ll keep posting more on the anti patterns and I’ve got a lot to say about supply side of things too. Till then, take care.