Re: Bah!
I suspect you have misinterpreted the problems as being technical rather than political.
Certainly you could envisage a centralised core service that provides data store for patient information in an efficient and timely manner. You could imagine APIs that provide access, and means to extend the data and access methods as the use cases build up. I would imagine even the greenest developer could draw that on a whiteboard somewhere.
In practise though you discover that department A and department B want two different features delivered first, that department C wants to use a legacy system until they have the budget to replace it and department D will not sign off on anything until you can guarantee the system is a complete replacement for their entire patient record system. Not only that, but you must prove the entire project meets various bits of legislation around confidentiality and accuracy, but no-one knows which bits of legislation or can understand the legalese that they're written in. There are mutterings that new legislation is coming along shortly that will change things anyway. Worse still, that suits all the departments who have been relying on the vagueness of paper based records to 'work around' legal requirements. They will, of course expect your system to both meet the legal requirements and bend them to fit the existing processes at the same time.
Whilst all of this has been going on, some clever soul signs a three million pound contract to replace all the blood pressure monitors in the hospital with something that is completely incompatible with your data collection hardware. Despite the fact that another company provides a similar device that would work, you cannot amend the order as the manager in question doesn't want to loose face. In the mean time, the heart rate monitors you have planned to incorporate will not be available for another six months and the current equipment won't support the minimum requirements laid down by someone you've never heard of and cannot contact.
On top of all this, it turns out the provider of the tablets cannot support your APIs as they are, and due to restrictions on hardware procurement, you cannot simply go for a bog standard Android device and write your own client. You therefore have to write an entire translation layer that turns your realtime data collection into a series of web forms accessed through a third party database via SOAP calls. The project only takes a few weeks, but it's long enough for the company to go bust and the procurement process has to be restarted. When it is, the new requirement will be that the tablets must support the old manufacturer's obscure SOAP calls, preventing you from being able to ditch the unnecessary translation layer, and doubling the cost as the new manufacturer charges you to re-engineer their APIs.
Finally, in every meeting with the end users, you discuss workflows and current practices regarding data collection. In every meeting, they think of three new use cases, and outright contradict two of their previous descriptions. Like a good techie, you decide to make it all data driven so things can change in future, and you are told to embark on an expensive side-project to provide access and control over this meta-data so that the various stakeholders can feel in control. After six months of development it emerges that none of the stakeholders actually understands a thing about this project and that you will be solely responsible for collecting and maintaining the metadata anyway. And the users still can't actually agree what their workflow is.
Hell is other people.
Biting the hand that feeds IT
