SoylentNews is people
SoylentNews
Ulitzer's Business Wire reports:
The Spine -- a collection of national applications, services, and directories -- connects clinicians, patients and local service providers throughout England to essential national services, such as electronic prescriptions and patient health records.
Spine is used by more than 20,000 organizations that provide health care across England, including primary and secondary care sites, pharmacies, opticians and dentists. Riak, the open source distributed database, is key to providing the reliability and scalability for the platform to drive efficiency and improve patient care.
The NHS' move to revamp the Spine, in a major project led by England's Health and Social Care Information Centre (HSCIC), was driven by the need for a scalable, resilient and flexible system that would also result in cost-savings for the organization.
With these requirements in mind, the NHS selected Riak Enterprise, the commercial version of Basho's distributed open source, highly available NoSQL database, to support the transition and implementation of the new Spine. Basho and the HSCIC collaborated throughout to ensure the technical knowledge of both organizations was reflected in enhancements to Riak and the wider project itself.
El Reg's coverage notes that the old system used a (closed-source, proprietary) Oracle product and the new software is NoSQL running on an open-source stack. It also notes the decision was made in October 2013.
Robert Pogson's commentary is also interesting.
(Score: 1) by Anonymous Coward on Thursday September 11 2014, @07:24AM
I mean, it's cool that they are switching to Open Source. But there are enough Open Source SQL databases they could have chosen. I mean, for health data, correctness is critical. SQL gives certain guarantees, and NoSQL explicitly scraps those guarantees in exchange for better performance on large data sets. But for critical data, data integrity is more important than performance. After all, you'll not die if your data is stored in the database a second later. But you'll die if an error in the database causes you to get the wrong medication.
(Score: 1) by Anonymous Coward on Thursday September 11 2014, @07:38AM
MariaDB++
(Score: 3) by skullz on Thursday September 11 2014, @08:10AM
I think the biggest selling factor for them would be the ability to plop nodes onto their datastore easily. So as long as they could flag changed data as "potentially not consistent" that would act as a gatekeeper for records which were recently updated with new allergy info.
(Score: 4, Informative) by c0lo on Thursday September 11 2014, @08:11AM
Not necessarily: there are NoSQL-es [wikipedia.org] (immediately consistent) and then, again, there are NoSQL-es [wikipedia.org] (eventually consistent).
In particular, TFA states:
Wikipedia says Riak is "eventually consistent" and that is used by 25% of the Fortune 50 [wikipedia.org] (which means: if it's good for multibillion transnationals, should be good enough for low-end matters such as brits health-care - after all, a life is valued at max $7.9M in US [wikipedia.org]).
Ah, BTW, the system that is using Riak, TFA says:
(with my emphasis). Now, there's a difference between mission critical [wikipedia.org] and life critical [wikipedia.org] (I infer that, while a failure within NHS may become unpleasant, it is unlikely that will cause loss of life).
https://www.youtube.com/@ProfSteveKeen https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by Wootery on Thursday September 11 2014, @10:40AM
This is probably incorrect. I don't know exactly what they're storing on there, but things like medical triage really are matters of life and death, and software failures in this area really have caused loss of life in the past.
(Score: 2) by Wootery on Thursday September 11 2014, @10:50AM
Having gone back and actually read the summary....
The patient health records sounds like the important bit here. I imagine there could be some consequences to this stuff failing, but I suspect you're right that it wouldn't generally result in death, but instead in an Error 404.
The consequences of the system getting hacked could be very severe, if they really are hooking up patient health records to a widely-accessible database...
(Score: 2) by M. Baranczak on Thursday September 11 2014, @01:29PM
"NoSQL" doesn't really tell you anything about the system. It just tells you that it isn't a traditional relational DB.
And you're understating the performance issues. A one-second delay isn't too bad - what about a five-hour delay because someone else is updating the table schema and some resource gets locked? When you have millions of records in a relational DB, those are the kind of problems you run into all the time.
(Score: 2) by strattitarius on Thursday September 11 2014, @04:28PM
Slashdot Beta Sucks. Soylent Alpha Rules. News at 11.
(Score: 3, Insightful) by choose another one on Thursday September 11 2014, @05:03PM
Trouble is, the better performance on large data sets (ability to scale hardware out instead of up) is the key to the cost saving on this replacement - despite Pogson believing that it is the licence change that delivers scalability savings and not the architecture change. I doubt that any of the open source RDBMS's have any track record at the scale of NHS Spine, or that they are likely to scale better than Oracle, whereas various NoSQL solutions definitely will. On the other hand, 10+yrs ago when the first solution started, there were probably zero credible NoSQL options.
...unless the data being stored too-late is the correction to your medication.
More seriously, availability of your record is also critical, and lack of availability can easily be fatal (e.g. drug allergy info). This is a big dataset, with access from large numbers of distant systems, it _is_ going to end up partitioned. Spine v1 was specced at four nines availability, which probably didn't include scheduled downtime or downtime for connection from the thousands of hospitals _to_ the spine, so end user availability would be less. Doctors aren't simply going to stop treating people for an hour or a day or so a year, historical / local cached record copies will be needed and offline updates to be reconciled later.
Once you accept the data is partitioned, CAP theorem comes into play and you need to trade off consistency against availability, and availability is critical... Consistency ? - less so. Do different patient records need to be consistent ? - unlikely, even when, say, you transfer a kidney from one patient to another, in reality it isn't an atomic transaction and may end up half complete. Do different patient records need to be consistent with some other data e.g. appointment booking ? - possibly but not immediately, and not life threatening if it isn't, whereas not being able to get your record in an emergency because the system is updating a routine checkup appointment in two months time actually could be life threatening.
In fact, the system needs to be able to guarantee no lost data (no update to a record lost, ever), and that every change (or addition - in fact, records are rarely if ever changed, just added to) must be audited, but those aren't the ACID guarantees. NoSQL and/or BASE guarantees should be able to do the job perfectly well. Only time, and data on running costs and maintainability, will tell us if this particular implementation actually does the job well.