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: 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.