Quote:
Originally Posted by Hugh
But that’s been the default in most large organisations (well, the ones I’ve worked in) - standard IT equipment/builds are simpler and easier to maintain (so it would be more inefficient if a large amount of non-standard builds were available by default).
We got round that issue by having a number of standard builds (general office work, IT developers, marketing, etc.) - I know this is how it currently works in NHS Digital, as I have a couple of ex-colleagues who work there.
|
It's easier now that hardware is cheap enough to over spec the basic so most users can use that standard and the exceptions can be dealt with.
Then the standard was way below what I needed and to get what I needed from the standard supplier was hugely more expensive with much longer wait times.
I am aware that IT systems are more complex and integrated than when I was trying to get the right serial library to get a PC to talk with a bit of lab equipment but I look at how projects like the NHS national network is reported and I just wonder.
One of the issue I had with the integration above is that the equipment had no idea of a patient as an entitity. It knew about an inpatient or an outpatient but not just a patient that may have both inpatient and outpatient tests. (The nature of the hospital I worked out meant some patients were admitted for extended periods and the consultants would see them as part of their outpatient clinics so a patient could be in and out at the same time, logically possible). This incompatibility is what gets sited as one of the big issues.
But when I was doing patient systems the NHS had a huge set of manuals about how data was "formatted" and how different data sets were related. It may not be possible to force this on the different NHS units but you should be able to specify that in how they communicate. e.g. you will receive queries in this form and you will reply in this form, how you achieve that is not important. That way you specify the communication but not how any one platform manages it. This is probably too simplified in these days where there is a lot more done with computers.
Other inefficiencies included getting rid of bad staff, not those who commit some form of malpractice but those who know how to work the system to their benefit. Insisting on following procedures/protocols that while important could be short circuited in some cases to get the job done faster. (Not all cases, not all the time, not just to avoid paperwork/documentation.)
I'd hope demarcation is mostly gone. Obviously some jobs must be done by the appropriate persons but sometimes if something needs doing and you can do it, just do it.