Healthcare software is expensive. Always much more expensive than people want it to be. But there’s some aspects of this that a lot of people don’t understand.
It’s intuitively obvious that there’s a trade-off between the upfront price of software and flexibility. The less optionality a software package offers, the less work involved in specifying, developing, testing, and implementing it. However once you account for the full cost of the software over full the life cycle, the costs of flexibility are offset by the advantages of the flexibility offered – if the flexibility matches that needed by the user requirements.
The simplest pieces of software are not at all flexible: they solve exactly one problem in only one way. This kind of software isn’t generally very reusable – all software needs to be configurable at least in regards to deployment. Beyond this there is a smooth continuum with growing amounts of configuration, ranging from simple ini-file type settings, through scripting/archetyped solutions, ending with products that are effectively Development Environments in their own right based on some healthcare specific domain language. The more flexible a software product is, the more likely that you’ll be able to make it do what you want. On the other hand, being flexible has a price – as software becomes more flexible, more skills are required to work with it, including learning the product, and thinking with the appropriate level of abstraction. On the other hand, these skills are deployed closer to the problem, which saves the cost of educating developers about the problems.
Interoperability refers to the potential of the software to exchange information with other healthcare software. This includes both functional and semantic interoperability: the ability to transfer information between systems, and have both systems use the information. Obviously there is an automatic cost for interoperability: adding the exchange feature cannot come for free. Even if a whole interoperability framework already exists somehow, connecting features into it is work that must be accounted for (and usually paid for too, one way or another). However the general trade-off between interoperability and cost is only very loose, due to the strong effect of existing infrastructure and frameworks on the cost of development.
The real tradeoff is between flexibility and interoperability. In order to use any information that is exchanged, someone has to understand it. It depends on the design of the system who that is, and what kind of skills they need to have – it could be a programmer, the system maintainer, an external consultant, but someone has to understand it. The more the system understands the data, the easier it is for the person. But the more flexible the system, the harder it is to understand the data, both for the system itself, and for any people trying to work with it, since it has a lot more variability.
This doesn’t make it impossible – just more expensive, much more work to be done. So you have to sacrifice something: either cost, flexibility or interoperability.
The following table provides some example systems that illustrate each of the points.
|Cheap Interoperable System||An HL7 v2 Messaging Transfer Agent. Can receive and send HL7 v2 messages between almost any system that supports HL7 Lower Layer Protocol, but nothing else.|
|Cheap Flexible System||A clinical reporting tool where reports are specified in an XForm document. Reports can look like anything, but the system doesn’t know how to turn them into a standard message|
|Flexible Interoperable System||Archetype based system where each clinical archetype (of hundreds) is accompanied by full specifications for how to read and write the archetypes to HL7 v2 messages and CDA documents, along with a workflow engine that knows when this is required.
Note: Fans of openEHR archetypes will claim that archetypes are the cheapest way to build such a system; that might indeed be true (or not), but a system that meets this general description would not be a cheap system.
Of the three rules, this is the one people most want to disagree about. The most common disagreement is that you can’t even have two of these, or sometimes not even one.
The other objection many people have to this rule is that it isn’t binary: you can sacrifice a little on all three, and kind of get some of each of them. This is certainly true, and should be kept in mind. The rule is only true as a general principle. But it’s important and useful because few people are properly aware of the trade-off between flexibility and interoperability.
Update: Mike Bainbridge points out that an improved formulation of this law could be “Healthcare Software: Cheap, Flexible, Interoperable, Safe – you can have any two”. That’s getting a little pessimistic even for me.