When you are going paperless in your hospital, do not underestimate the amount of time it takes to digitise reference data, lists, protocols, pathways, images, order sets etc. This is just one pile of books I came across to support the complex and lengthy discussions between our IT analysts and front line users.
It is not all about choosing and implementing an Electronic Patient Record product, it is more about making it work for your clinicians through detailed configuration. Sure, some vendors will have some information hard wired into their product and some will provide "out the box" configs, but you need to realise that to do this well in a hospital, or across multiple specialties, the effort can dwarf the equivalent product costs. Your hospital is not "out the box".
Monday, September 14, 2009
Sunday, September 13, 2009
Thursday, September 10, 2009
What can IT Procurement Learn from the Construction Industry?
A letter by Mike Stranks to the 10th September 2009 edition of Computing Magazine "Overhauling government IT procurement" reminds me of a concept I've long advocated in our organisation, but not posted about yet. Mike looks to the construction industry, which has a much better record of programme success than IT (well, they have had several thousand years to work it out!), and observes that the role of design and construction is split between organisations. Along with a savvy client (often a chartered professional) these three parties create the necessary environment for programme success. In IT, the design and build roles are usually not distinct and are therefore usually awarded to the same company. This is especially true in public IT procurement where, ironically, the public purse want to derisk the delivery by passing that risk on to a prime contractor.
I wholeheartedly agree with Mike. Closing a deal for the design and build before the problem is understood means that the parties are playing with alot of uncertainty. Either the problem will be easier than expected to solve and the client pays more than was necessary, or as is more often the case, the problem is more difficult to solve than expected and the supplier either needs to play a game of "change request charges" to recoup the extra costs or the project fails to deliver.
By seperating the design piece out, the client is able to procure build services with a much better understanding of what they are asking to be done, and the incentives in the 3 way tie up are also more balanced. Classic conflicts between design and build are mediated between organisations which include the client rather than pitch the client against a single supplier who naturally has their own interests at heart.
Mike makes a strong case for chartered engineers in this process. Hooray to that too, but that's a subject for another topic.
I wholeheartedly agree with Mike. Closing a deal for the design and build before the problem is understood means that the parties are playing with alot of uncertainty. Either the problem will be easier than expected to solve and the client pays more than was necessary, or as is more often the case, the problem is more difficult to solve than expected and the supplier either needs to play a game of "change request charges" to recoup the extra costs or the project fails to deliver.
By seperating the design piece out, the client is able to procure build services with a much better understanding of what they are asking to be done, and the incentives in the 3 way tie up are also more balanced. Classic conflicts between design and build are mediated between organisations which include the client rather than pitch the client against a single supplier who naturally has their own interests at heart.
Mike makes a strong case for chartered engineers in this process. Hooray to that too, but that's a subject for another topic.
Subscribe to:
Posts (Atom)