Julian Todd is an IT manager at the Dudley Group of Hospitals NHS Trust, who has long held the view that the NHS should create a repository of software objects for localisation by each NHS organisation. That the code of such a repository should be open source is a no-brainer for him. His talk perhaps sits less easily without his slides, but the main ideas come through clearly.
Chair: I think we'd better whiz on with the last presentation. In relation to health, what we are seeing is that the technical issues have largely been solved and as such it's the managerial and cultural issues that we're now having trouble with. Over to you.
Julian Todd: Thank you. I'm Julian Todd. I'm an IT manager in an acute trust in the Midlands and I'm a relatively rare beast in terms of attendance at this conference, and I'm feeling strangely ambivalent. It's really exciting to be in an environment in which people understand what the hell it is I'm ranting on about. This thing I'm going to tell you about, I've been sitting on for some considerable time, occasionally bringing it out and waving it, and saying "Hey I've got a better way of doing things." But it hasn't been a success so far, so perhaps you can help me.
It's basically a thought experiment. I'm an ex-physicist, and I think it's perfectly OK to fly kites and say, "Hey look would this work? Or, why wouldn't this work?" It's for debate and that's fine. On the other hand, I'm now a suit, a haircut and a suit, but I used to have a pony tail so I feel some justification for standing here and talking about technical issues. The other problem I've got, and all the way through here today (I'm not here tomorrow, which is a shame) is that I've been thinking I should go away and rewrite this presentation. So if you'll bear with me, a lot of what I am going to say isn't what I planned to say, and it may not match the slides. So there's some I'm going to rush through, and some I'm going to stand and talk, so I'll try and stick to my time, and it's absolutely fantastic to be here. Thankyou very much for the invite.
My concerns as an IT manager are things like scalability, reliability, sustainability over time, because I work in an environment with 24/7/365. In healthcare, especially in the UK, but I've heard also in Europe, America, South America wherever, everybody's moving to IT being part of the active care of the patient process, and to my mind that changes the game. And means that we have to make sure whatever we're doing with IT whether it's open or closed source--or a combination of both, which is probably where it's going to end up, it must be suitably robust.
This proposition started life as a way of technology transfer of object based modelling and deployment. Actually when I wrote it, it inherently assumed that most of that would be open source, but as a number of people have said it's relatively recent, so I am proposing something that is both object-based and open source, which is slightly different from the what other people have been proposing.
Just so we got a label for what I'm talking about, I've called it Hoist that's what it stands for: if all else fails it'll go in a lousy acronym competition. Then I scouted around for clip art. I can't beat Ray's clip art but I found this one. So Hoist is a bootstrap: it's basically about bringing the whole of health IT community, and my company--the NHS--but I think it's applicable to healthcare in general in different commercial and legal environments round the planet--and I scout around for a some clipart that tries to suit our purpose so we're trying to bring ourselves up to a higher plane and I found this one after a long search, and I thought this bod here looked a bit smug, and it is a theoretical model so I thought, the best laid plans, but I wish I'd changed that now to "Have you got the license agreement?"
That seems to be the sticking point.
Overview; I'm going to rattle through this one. I'm going to assume that you're all in favour of component based development and deployment which seems to be the way the industry is going anyway. I'm also going to assume that there's broad support for the notion that it is possible to contemplate some generic process based models of care and I have regular debates with clinical colleagues... this is a topic in itself. I'm not saying one size fits all. This is not my imposition of standard ways of delivering healthcare, it's not removing clinical decision making and expertise and all the rest of it. But it is acknowledging that the way that diabetes is treated in one environment--from one country to another country is broadly similar, from the way diabetes is treated elsewhere, because otherwise what the hell is evidence-based healthcare about? You know, there has to be some notional model of good and bad ways of doing things. So it's possible to embed some of that process-based view and some of that evidence in systems.
It seems self evident to me that the NHS currently has a pathetic level of internal software development capability--even though it is a huge organisation with a turnover of more than 35 billion ukp. Compare and contrast with the fact that the sort of informatics environment that we deal with is actually very complicated. Much more complicated than banking or airline booking or whatever, and they've got whole software departments to cope.
Therefore we need a technology transfer approach. if we are going to take object based and open source into the service. It's not going to thrive, because at the moment it's being planted on stony ground. That technology transfer approach which has got to be tripartite in my model: I've put "centre" in inverted commas because I'm not talking about geographic centre, I'm talking about a co-ordinated approach, which has to be nationally driven about certain things, like licenses, or the authority and the clinical evidence base embedded in a product. NHS organisations many variations, and that could scale across to other countries easily. And software suppliers--they're a bit thin on the ground here at this conference, and all the way along we've thrown up problems about the way that open source at the moment is perceived at them moment as in conflict with the commercial priorities and the business models we need at the moment, and I think that's something we've really got to think about hard.
Hoist was originally aimed at what are called satellites for patients. I wasn't thinking we could rewrite the PAS system or the pasthology system or whatever, but it was mainly aimed at clinical activity data capture: what used to be called clinical audit if anybody goes back that far, to the resource management initiative and that sort of thing. Because when I was struggling with that at the time, there was very little in the market place that was usable, and it certainly was not flexible. So that's where it started from but I don't think there was any intrinsic limit to the scope of what we are talking about.
So, I tried to get this on one sheet. Basically the proposition is that first off, we've got a hugely complex and challenging national strategy for the NHS informatics. Lack of IT flexibility is a constraint, it's a brake on the reform process. The majority of software that we run in the service at the moment is proprietary and there are literally hundreds of often very small software suppliers who provide that using a whole range of development techniques. So the consequence of that is the cost of complexity is much higher than it needs to be technically. The operational costs are high, because you're locked into that supplier's costs without accountability. And a number of speakers in here and in the main auditorium have noted the cost in time of development and maintenance, and that's an area where open source is proven to be superior.
So, the proposition is that we need component based development with access to application templates, and I'll come on to that in a moment, to not only NHS organisations, that's a model we were talking about in the developer community, which is open source based, and client sites, but also to commercial suppliers, because I think this is a shared effort.
The notion of what the beast we are talking about is here. A lot of the things we have heard about so far are actually monolithic applications which might be developed in Access or Delphi or GNU or PERL. I'm no longer a developer, I can't speak about the detail, but there's a huge range out there. And on the ground, through my peer contact, I know that every site, every community is unique. They're also similar, but they're also unique. We have unique histories, we have unique architectures, we made different choices about which systems we purchased, so it's going to be very difficult to drop in the same component in every location. There's got to be an element of localisation. And the best way to facilitate that localisation, is to make those applications, templates, component-based, so that you can mix and match. You can take what you can use and change the rest. And the open source model, I'm taking that for granted. And open standards is the crucial issue here as well, because we've got to at some point--and I'm looking at Adrian here--we've got think about architectures, and make some choices about the range of tools and methods we adopt.
Deliverables. The Hoist proposition says we need some class and component libraries, but those are no use, without active repository and library management to serve and support the developer community. Otherwise you get the tower of babel. You've got to have some choice in software development. Tools-- you've got to narrow the window, and say that is what we are going to use to build our component-based open source model. It can't be completely open ended because you'll end up with too much choice. You've got have--because we're talking about technology transfer--very robust education and training consultancy support to roll this out and bring the end-user sites up to snuff in terms of the code and technical skills. And some of that education has got to be geared at senior management, somebody else has mentioned that point today, and we'll come back to that.
This is not something you can just address in the technical community, it's got to be an organisational decision based on the end-user: clinical professionals, and senior management about a different way of doing things. Talked about application templates. And you've got to have a parallel set of development tools for the commercial community who are part of this model. We've got to have a very exclusive approach to migrating the code from the "proprietary, we make our money out of flogging licenses model" to a different model which is based on service and support and is based on communal use of open source components.
We start with Hoist centrally--though this is not in one ivory tower, it's a collaborative effort with an organisational box around it. This is where the main class library for the model lives, and library management live, this is where the application templates live, including all the issues about configuration, version control, maybe commissioning different components, maybe going out into the commercial market and buying tools and methods. That's where they're managed and co-ordinated. That service--it's a no-brainer--has to be networked. It might be NHSNet, it might be EU, it might be global.
You connect that central service to client sites. But before they can do anything with it they need to access those training/education/consultancy type services to make use of the toolkit. So once they know what they are doing they can call down what they need--they'll have to spend some money--some of these are commercial products and always will be, but it's much less than spending hundreds and thousands of pounds on software licenses.
Draw a line there, as you'll notice that at this point we haven't actually got any useful applications. So this diagram describes something that's up and running. But how we bootstrap to this state of existance is a moot point. So I'm not suggesting that build sequence on this diagram would work, because it would take a month of Sundays for everything. We have to have a bootstrap to get to the point we are talking about.
Sites can use those applications, templates to build localised useful working applications, and I'm assuming that it provides 80% of the functionality that people actually need and they tweak the rest. Those application templates, if you compiled them on the relevant hardware and network infrastructure would work but they wouldn't be local, so you're talking about some sort of prototyping/rapid application development approach.
Now, what if you've got a situation where the site's too small, or they're too busy, or they haven't got the tools or the skillset? What if there's an absolutely obvious requirement for a shared application around the country? The InControl application is an example: you are co-operating with a third party who can access those same tools, those same templates to develop open applications which are much more similar to the current commercial off the shelf (COTS) that we are currently using?
What we are talking about is kind of mixed economy in which there is a pathway for the NSH sites to share, to skill up, to make use of shared applications, application templates, maybe even fully working applications, but there's a partnership between a) the tool vendors e.g. Borland, Inprise, whatever they call themselves these days, and b) the developer community who perhaps through a process or accreditation or cross-licensing or whatever, can use that product to develop applications. So they're operating a slightly different business model which is maybe based on service and support and not license income.
I've got various examples, but in the interest of time, I'll skip them. Benefits: local flexibility, interoperability, central certification of national standards and strategy. I mean, the extreme difficulty of getting suppliers in the so-called free market to stick to even basic open standards is enormous, and that causes intense difficulty from where I sit, because I've actually got to get all the other stuff to talk to each other. If the component base, and the application actually had a standard embedded into it, then that becomes much easier. So the whole issue about clinical datasets DICOM support, HL7 support, all those things that you need to make EPR work are already embedded in the model.
Market-driven takeup. I'm not for an instant supposing that we can impose this centrally. This will be about facilitating things, doing things in a different way, and it will only work if they see costs and time and flexibility. But it's got to earn its keep. Over time, and I am talking about a software life cycle of 10 years or something, the overall cost of ownership should be considerably less than the routine option. And as I said suppliers become more focussed on service and support.
Their costs of development and the risks of selling to the NHS at them moment are horrendous. The risks in healthcare are very high. So I think there is a winning argument which says, "Hey look guys, we can help you de-risk some of what you do. there will still be a proprietary chunks of code. An example is integration engines: very sophisticated, very complicated chunks of code. They have APIs. Why would I go and rewrite one? There's a model that says there's a mixed economy, that brings their integration services into the fold and becomes an accredited supplier within the hoist environment and thrive on service and support.
The last thing I want to share with you is to kind of contradict myself. The whole point of hoist is it's a big framework, it's a theoretical model, you can't achieve those sort of benefits at local level. And your presentation Donald [he means Douglas] was a prime example of loads of people who have gone away and tried to do exactly that, problems you've faced are archetypal, it's really difficult to make this scale. So I went away and contradicted myself by cheating. So we contracted a supplier for a modular system, but those modules were proprietary. So this is an innovative supplier who've got a business model that sells you a toolkit, and a variable range, depending on how much you want to take up from them, of consultancy and training and development expertise to come in and help you locally. And we've taken advantage of that to transfer skills into the organisation. And it was targetted at clinical activity/audit system, in surgery, web-based, another good thing, based on an open source database.
Overall in terms of proof of concept of the modular approach it worked really well, and RAD approach, and in a certain sense it was too good, in that we hit a major problem. It was so easy to tweak it that users always wanted something different done. And we would say
"Can we sign this off now? Can we call that version 1?"
"No, no, no, we want it to do this now.
"But it wasn't in the spec."
"I don't care"
And this is why you've got to get management support, because when you say, "Please Mr Chief Exec, can you kick Mr Consultant over there, because he's about 50 layers above me in the organisation--he's got oomph--and I'm just a teckie. Can you tell him to stop?"Uhh?"
Because it was so cheap and so quick you don't need top level organisational support to do it, and yet you need that to make it work because this is about a culture shift. So, I don't know.
Chair: Our next session is the panel. While there's movement taking place, does anyone have any single burning points? No? OK, I think that will roll nicely into the panel session.
|Copyright Julian Todd 2001. You may reproduce this page in any medium provided this copyright notice is also maintained. Transcription by Douglas Carnall: firstname.lastname@example.org