Re: Mega-projects
H/W becomes obsolete. S/W becomes obsolete.
Data should live on. The key to that is open standards.
42421 publicly visible posts • joined 16 Jun 2014
I guess the problem is a single big outsourced operation. It needs in-house to set the standards, say batches of extra interface specs every 6 months. Given that there are, I believe, a number of suppliers for systems to be interfaced there would be competition to keep them relatively honest - "That's the spec, you've got 3 months to go-live. The others will be doing it, so it's on your market reputation if you can't."
Years ago - so long ago I've forgotten most of the details - a client of mine had a contract with the NHS. If you lived in England and Wales back then you've probably benefited from the end product and the recollection was part of the thinking behind my OP.
Somehow - I wasn't involved with the details - we got the server an email address on NHS.net (or maybe there was some predecessor) and received data by encrypted email. I then had to parse these emails to load into the ERP system. The record formats hadn't been put together with enough planning and the ad hocery as more use cases got added got to a familiar point: "If I'd known that's where you were going I'd have started it differently." If the contract hadn't ended about the same time as I retired I'd have refactored it.
It didn't need anything special in respect of email clients. AFAICR the existing Unix mail handling sufficed to drop the files into the processing so no need to write email clients.
So much can be done with local processing and message passing with agreed formats.
I had this incident in mind: https://www.bbc.co.uk/news/uk-northern-ireland-18497161
I remember the hospital because it used to be just along the road from my lab which meant that during the rotating power cuts in the troubles we were spared them because the hospital power had to be kept going.
Over the past few year or so my wife's cardiac and, particularly the last few weeks, blood pressure problems - together with a few of my own have given me chance to observe the local hospital trust and especially the local A&E.
Firstly they do have a trust system. It has links to a national system so they can look up NHS number from name, DoB & post code (as can online booking for flu & covid jabs). The only connected printer in evidence at A&E reception spits out a wrist band with name, NHS number and a QR code. That solves the patient ID as they're moved around. BP testing devices have an RJ45 so presumably could be networked but aren't - it would probably be impractical - so readings have to be typed in but doctors and nurse practitioners can review what's been done. The cardiac ward in the other main hospital in the trust has hand-helds which look like smartphones but I suppose might not be which are used to register the readings. I'm not sure how the doctors review this on ward rounds but in the A&E offices they can review everything without needing a paper record. On the face of it it appears that this trust is largely if not entirely paperless apart from the wrist bands, at least on a functional level although it's possible there might be a paper back-up. I don't know the origins of the system but I doubt it's written in house; it will be bought in.
Our GP also has a practice system so they also are largely if not entirely paperless, at least on a functional level. I know this is system is bought in, in fact I'm pretty sure it runs on the provider's server.
The need for paper, then, seems to be communicating between trust and GP and possibly between trusts (SWMBO was sent elsewhere for a TAVI last year). This set me thinking: bearing in mind that perfection is the enemy of the good, let alone the workable, is it possible to build a bottom-up system instead of some grand plan, especially one to be handed over to a major data-broker? How does email work, or the web, or any effective communications system? It has scarcely any central requirement other than data standards - communication protocols and defined message formats and a hierarchical, distributed registry. There's no need for everyone to use a specific client. There's no need for MSPs to use the same server software. Providing the clients and servers follow the protocols and handle the same message format everything works. It should be possible to build something on those principles.
A quick online search shows that there's a lot of information about medical exchange message formats. Pick one, preferably one that's extensible. Specify a core amount of information and a go-live date. It doesn't matter how different the internal databases of the various providers are, all they have to do is to provide an interface to read or write that subset of data to that format. Now we have to decide how to exchange data about the patient. As the system evolves extensions for extra data can be defined and added in phases.
On the basis that the patient is registered with a GP (not all patients may be but let's start with what's practical) the GP (in practice the GP's service provider) is the obvious place to exchange information; it's the GP who will refer patients a lot of the time and even if a hospital trust encounters the patient as an A&E walk in the GP will need to know eventually. Clearly a network is needed to transmit messages securely and I'm assuming that NHS.net can provide this and that most, if not all, trusts and GPs have NHS.net addresses. Again "most" can be the starting point.
What the network needs to provide is a central registry to provide identify the patient's GP and I'd be somewhat surprised if the system which already provides the lookup for NHS number didn't already include this; and a store and forward message handling system which looks remarkably like email. It may well be that the GP service providers could handle the latter
TL;DR A system could be built bottom up. No massive central contract is needed. Software would be an add-on to existing medical record systems by the providers of those systems. Not every patient nor every possible item of data might be served by this but the system could start earning its keep from go-live and grow out from there. Perfection is the enemy of the workable.
It's an on attitude isn't it? These machines will house your entire business. If they go down so does your business. Collectively they represent your entire business, whatever you value that at. Where do you put them? Somewhere where they'll be treated with the respect that that value deserves or whatever small space that you'll begrudge least, however unsuitable?
Same house, most of the wiring was wooden conduit like that except those wires were gutta-percha with fabric covering. Metal conduit chased in down the walls.Only two wires of course. What to do when 3-pins were installed? Easy. Thread an extra wire down the metal conduit then twist it round the top of the metal to earth it. Or round a 6" nail hammered into the joint between two courses of brick. No brickwork handy? Hammer the nail into a wooden joist. I found all three options in that house.
"Companies will not spend man-hours to upgrade and retrain"
If you want a UI that doesn't require periodic retraining of users - nor requires them to just take UI changes in their stride without retraining - then you're a lot better off moving to Linux.
Do the retraining once and from then on enjoy the stability of UI. Between KDE 3 & KDE 5 there's only been one change that's really annoyed me and that's the fact that I can no longer confine un-hide of the panel (task bar to you) to a corner. I suppose for Windows users that would be classed as a minor annoyance given what Microsoft have wrought on them over that time.
Unfortunately a few applications, particularly browsers have changed their UI for the worse. That's because they've followed what happens on Windows and, believe me, that imported lack of stability bugs me no end.
" It was supposed to be the last version until Redmond got an aneurysm and decided to do another one."
I wonder if someone faced with a large, otherwise unnecessary, replacement requirement might use this to sue Microsoft under the Trades Descriptions Act.
"it's seventy three competing GUIs"
You say that like it's a bad thing. But one size does not fit all. Liam reviewed Elementary here the other day. I'm sure it has users who find it to be just what they want, likewise Cinnamon, XFCE, Gnome, Unity or whatever. If I personally find KDE fits my way of doing things then I don't have to use any of the others (a couple of which would be an extremely bad fit for me).
To take just one aspect of it - the versions of Windows from 95 to 2000 had a fairly configurable and on the whole user-friendly hierarchical start menu organised on more or less functional lines. Over the years since it has changed into what appears to be an inflexible lumpen mess ending up resorting to alphabetical ordering because nobody seems to recognise that functional organisation is what's needed. I understand that many users resort to typing the name of the program they want into search - they've reinvented the command line in desperation. The Linux desktops I've used have retained the functional organisation and improved on it. KDE, the one I'm most familiar with is fully editable to achieve the arrangement that best suits the user and has remained that way as long as I've used it and has also sprouted a couple of extra choices as to how the user wishes to view the menu.
It's a world away from the Windows approach of use this whether it works well for you or not, until the next one which might work in an entirely different way. I can have something I can tailor to my needs and enjoy consistency of UI from one release to the next.
That choice of desktops isn't a reason to avoid Linux - it's actually a very good reason to use it.
The desktops are over a clone of a 50 year old minicomputer operating system? Fine, there were some very clever people about 50 years ago. Even back then I preferred the one that was cloned for Linux over the one that was cloned for Windows.
Primarily it was a wrist-mounted display object whose prime function was to show, by having been purchased, what the owner could afford to by. Having been purchased and flashed about most of its utility value has been used up. Being a wrist-mounted gadget that could also tell you the time was its residual utility value (plus the melt price of the gold, of course).
I don't think many people in Kirklees think it works. It was a cobbling together of areas which previously had their own administrations with the West Riding County Council on top of them. The name was presumably the consequence of there being no name within the combined area which wouldn't identify it with one of the original areas to the detriment of the other. It's not a bit of accidental daftness - it reflects the underlying lack of logic.
I suppose the destabilising factor was breaking up the WRCC to create the Peoples Republic of South Yorkshire. That, of course, is the root of your Whitby/Settle issue - Settle was also part of the West Riding.
Now, for goodness sake, we've also got a West Yorkshire mayor to no obvious purpose.
Given that there are raster and vactor editors to learn from those aren't to trick parts of the puzzle. The bit that requires imagination is how to produce a workable paint program from it. I'd like to think that if you put that problem as a test the human would start by thinking what the interface would have to look like but what would a ML do?