Hi TimC & Ian & David,
On 18/06/2007, at 8:07 AM, Tim Churches wrote:
Ian Cheong wrote:
At 2:23 pm +1000 17/6/07, David More wrote:
<http://www.computerworlduk.com/management/government-law/public-
sector/news/index.cfm?newsid=3529>http://www.computerworlduk.com/
management/government-law/public-sector/news/index.cfm?newsid=3529
NHS IT chief Granger quits
Head of £12.4bn programme will go before roll-out of crucial care
record system
=================================================
The lessons to be learnt from this are legion and need to be
carefully
learned.
Cheers
David
----
...but the lessons were known prior to the project/programme
starting.
Probability of failure being proportional to project size.
Not entirely true. It is all about good design. The aids memorial
quilt http://www.aidsquilt.org/makeapanel.htm is one of the largest
community project and its design has a lesson or two for us trying to
build an interoperable health architecture. The "pluggable
component" is a panel 3 ft x 6 ft. A "block" (or section) of The
AIDS Memorial Quilt which measures approximately twelve feet square
(144 sq ft), and a typical block consists of eight individual panels
each three foot by six foot panels(8x6x3=144 sq ft) sewn together.
Add a few simple rules about applique, paint, collage and photos. I
wonder if the architect of the quilt is a biologist with a good
grounding in multi-cellular organisms? Back to e-health, I am not
sure(.... or too reticent to say) what that "pluggable component" is
in this domain, but human readable context complete clinical codes
sure solve a lot of problems.
I suspect that Grainger is going because Blair is stepping down this
month, and without Blair's backing of the massive expenditure
needed to
support Grainger's maximal cost strategy, it is all going to go even
more pear-shaped than it is now.
A prime lesson is that core health care information systems need to be
sustainable, and this includes financially sustainable, through
periods
of recession and through political changes - both being very likely to
happen in the lifecycle of most national-level health IT deployments.
Personally I think that a lot of health IT software which is bought
from
overseas could have been developed here in Oz, had there been
sufficient
belief in local ability and some national leadership. But if
systems do
need to be purchased from overseas, the key thing is to ensure is that
there has been sufficient technology transfer and sufficient rights
obtained so that, if a recession comes or the terms of trade turn
against imports (that is, our dollar weakens), then we are not left to
pay a ransom in US dollars or Euros for software upgrades and services
in order to keep out health system running. I suppose it is a similar
question to whether our telecommunications companies or national
airline
or other core infrastructure providers should be foreign-owned or not.
Apart from some GP systems, Grainger has linked the fate of health
IT in
the UK to CERNER, iSoft, Microsoft, CSC, IBM, Accenture, PWC and
Fujitsu. Of those, only iSoft is a British company, and Grainger's
programme has driven it to the wall and it is reputed to be in
danger of
tanking or being bought out. However, Grainger has always espoused the
line that the UK NHS was a partner with these firms, with IP and
copyrights jointly held with the companies concerned, and with
complete
or very good access to their underlying technologies. In Australia, we
are more just clients of those companies, I think, which puts us in a
riskier position, at least with respect to the public hospital sector.
The GP software sector is much more indigenous. But talking of risk
management, how many GP software vendors provide source code escrow
agreements, or even better, access to source code (short of a
license to
re-distribute or modify that source code, which is of course the
open-source approach and is even better again)?
Tim C
As usual, you three are helping us evolve into deeper insight. Thanks.
Cheers
Kuang
The fog of general practice.
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
