Slashdot Mirror
UK's National Health Service Moves To NoSQL Running On an Open-Source Stack
An anonymous reader sends this news from El Reg:
The U.K.'s National Health Service has ripped the Oracle backbone from a national patient database system and inserted NoSQL running on an open-source stack. Spine2 has gone live following successful redevelopment including redeployment on new, x86 hardware. The project to replace Spine1 had been running for three years with Spine2 now undergoing a 45-day monitoring period. Spine is the NHS’s main secure patient database and messaging platform, spanning a vast estate of blades and SANs. It logs the non-clinical information on 80 million people in Britain – holding data on everything from prescriptions and payments to allergies. Spine is also a messaging hub, serving electronic communications between 20,000 applications that include the Electronic Prescription Service and Summary Care Record. It processes more than 500 complex messages a second.
Obviously you have never worked with HL7. One message will have hundreds, if not thousands of pieces of data.
The "NoSQL means Not Only SQL" crap you're shitting out is nothing more than the NoSQL community frantically backtracking after their "NoSQL means No SQL" ideas were shown to be disastrous bunk.
Instead of owning up to the fact that they were horribly, horribly wrong, and made some really fucking stupid suggestions, the NoSQLers have just decided to change history. They pretend that they weren't saying what they very clearly said in the past. And they obviously need to admit that SQL and relational databases are the only viable option, but can't do this without looking like the fools that they are, so they admit that it's okay to use "sometimes". And this "sometimes" ends up being "all the time", but again, they can't openly say that without looking like the incompetents that they are.
Face it, "NoSQL" does mean "No SQL". It always has, and it always will. No amount of backtracking will change the fact that the NoSQL crowd was full of shit, and still is.
Summary says: "It logs the non-clinical information on 80 million people in Britain"
Well, yes it does hold clinical information. That is a big deal.
From the UK's HSCIC web site there's more (and authoritative) information on SPINE
http://systems.hscic.gov.uk/sp...
"The Summary Care Record:
SCRs provide emergency and out-of-hours healthcare professionals with faster access to key clinical information, including details of allergies, current prescriptions and bad reactions to medicines. The Summary Care Record helps to ensure continuity of care across a variety of care settings, and is provided by the Spine."
Having or losing corrupt information in a clinical record is a good way to kill some random person. However, it is a summary, so if a physician suspects a problem in the summary, they can go to the patient's main record. Getting prescriptions crossed can also be problematic for the patient.
Ignoring the NOSQL issue, I wish we had something like SPINE here in the USA.
"It logs the non-clinical information on 80 million people in Britain " when the population of Britain is about 64 million.
I just interviewed with one of the largest healthcare focused tech companies in the US, Epic Systems. On of the more interesting things I learned while I was there was that they use InterSystems Caché, a non-relational system that's built on b-trees instead of tables. The main draw of this system is the speed at which they are able to operate, which is one of the big things they've built their reputation on. They claimed while I was there that roughly 47-49% of Americans are covered by Epic's software at some point. Now, obviously that's not just records stored in databases they designed, implemented, and support, but, especially considering that Epic targets medium to large healthcare companies, with very little involvement with smaller outfits, and the fact that they do their best not to parcel out their software, but to sell integrated top to bottom systems... well, they seem to not only be doing fine without a relational system, but thriving. I don't work for them, so I can't say any more than that since I don't have experience, but I just thought it might be of interest in relation to the relational/non-relational debate in this thread.
Sure you can. You can do that and get useful gains. Your imagination may be too limited to understand it, but it's perfectly possible out here in the real world.
It's a distributed database. They don't need the data to be consistent across every node on every write; "eventually consistent" is fine provided that they know the write has reached at least n+1 nodes, and modern NoSQL databases can do just that.
Maybe for you, but they were probably able to hire real developers who knew how to write queries and map/reduce algorithms to perform effective queries.
I also love the implicit suggestion that performing an effective query on any large normalised relational dataset is easy, by the way.
Look, we get it: you've invested a lot of time and effort into becoming an Oracle developer, and yes your skills are now under attack by something that's totally foreign to you, but perhaps you could try learning about those new things and extending your knowledge base instead of dismissing them an hoping they'll go away. It'll make you more employable and you'll look like less of a petulant child, all at the same time.
There are certain ways ACID compliance is important and certain ways it is not, in fact sometimes it's a hinderance. In particular the following:
One patient's records must be consistent only with itself, you don't need the whole patient table to be consistent. It's a problem because you do need to have cross-table consistency (patients, episodes, diagnosises, treatments, medications and so on) which can lead to locking issues while they're really millions of records living in parallel. Really I'd like to treat them as millions of microtables that happen to share the same structure but never cross lock.
Perhaps in a hospital you can do synchronization at a database level but for an exchange or common journal you have to assume records come in asynchroneously, your general physician might finish some paperwork while you're in emergency care at the same time as a lab result you've waited a week for comes in. The actual ordering they're applied in doesn't matter, there must be rules so (A,B,C), (C,A,B) and (B,C,A) all end up the same result. This means you can relax the hard synchronization of for example a bank account where it is essential that the transactions are applied in order and rejected if you're overdrawing your account, but that's hard in SQL.
That doesn't just apply to the ordering of writes but also querying. If two people at different hospitals tries to pull up your medical records it is important they're not corrupt but it's not essential that an update being distributed is presented to both or none. In fact, for essential robustness they should be able to continue working independently if the connection is broken and when the connection is restored the records are reconciled. That kind of shard and merge is generally a problem relational databases don't handle while the distributed synchronization is rather essential and implicit in NoSQL solutions.
Live today, because you never know what tomorrow brings