For those who read this and have an irresistible kneejerk reaction tempting them to cite examples such as ATM networks, telephone networks, Google or email, please understand that this is an apples to unicorns comparison. Assuming that our ultimate goal is to have all health records for all people available at all geographic locations at all times, is weaving a web of rickety interfaces between thousands of products, really the best option? It is, if you sell existing, or enabling, technology for this arrangement, and it is not, if you intend to use, or pay for, the end solution.
The usual arguments against a Universal Health Record, and its scary database in the sky, are that we must build on existing infrastructure; that rip-and-replace is cost prohibitive; that a free market should provide as many choices as possible; and that privacy is best served by keeping data close to home, and certainly out of the hands of Big Government. Sounds pretty reasonable. What if we dig a bit below the surface though?
Medical Records
- Assumption: At any given moment in time there can be only one correct version of a complete medical record for any one person
- Fact: Currently, various parts of the medical record are stored at various locations, by various organizations, in various formats
- Fact: Most organizations possess unique content, but also content overlapping with what others store, containing multiple discrepancies and various errors
- Observation: Using partial medical records for provision of care could be desirable, inconsequential, dangerous or lethal, depending on which parts are missing
- Observation: There is conceptually no reliable way to know whether parts of the medical record are missing at the point of care, let alone ascertain the criticality of missing parts
Reconciliation
Unlike banking, where managing a checking account at your local bank does not require immediate information on your Cayman Islands holdings, medical care operates on a single record set of data elements. Since this record set is being altered at various care facilities, health information exchange must continuously reconcile the data elements. So for example, let’s say that you visit your primary care doctor complaining of chest pain and he diagnoses gastrointestinal disease and prescribes antacids, but you are still concerned and decide to see a cardiologist in the city, who diagnoses angina. Shortly after visiting the cardiologist office you get hit by a bus and end up in the local ER. Was your cardiologist aware that you have been complaining of chest pain for the last 20 years, angina was repeatedly ruled out in spite of your concerns that Aunt Mary also has angina, and antacids always worked for you? Is the ER aware that you just got diagnosed with angina and have a shiny NitroMist sample in the backseat of your car? Is your primary care doc going to be appraised of your adventures? In a world of perfect information exchange the answer is yes to all questions.
However, perfect information exchange in this case requires that your primary care physician pushed your medical records out to the cardiologist, including your fixation with angina and Big Macs, or that the cardiologist was able to locate your primary care records and pull the information in. It also requires that the ER was able to obtain your primary care records from back home, any other medical records from other providers and also the very recent cardiologist records and combine all those data points in one authoritative record set. This reconciliation process would occur every time you seek care and every time you, or other diagnostic facilities and eventually devices, update your records in any fashion. And these transactions will have to execute without a unique patient identifier just for you, and while processing and propagating privacy rules which may differ between various care providers and exchange intermediaries.
Now imagine millions of people with similar needs, and you have many millions of transactions flying around back and forth between thousands of software programs executing in hundreds of thousands of locations, from industrial strength data centers to the lonely Dell server under the printer in a doctor’s office. Yes, the contents will be standardized by those edge transformers, but every relay, every handshake, every acknowledgement and every translation back and forth to the native software program constitutes a point of possible failure, and every reconciliation of multiple messages from disparate sources is an error waiting to happen. In computer land errors don’t usually wait for too long before they happen, and this has nothing to do with lack of standards. Sending applications lose connectivity intermittently and go into a peculiar state of limbo. Receiving applications often get stuck on one bad message, creating huge processing queues on the other end. Messages mysteriously disappear only to be found in a log file or another patient’s chart. Every new release is always an adventure. This is how things are today, with only a fraction of the envisioned number of transactions in the brave new world of a seamlessly connected health care system.
The Power of One
The alternative to having a flimsy system with a multitude of moving parts is to have one unified database system, with one architecture and one schema definition. This does not necessarily mean one EHR. We could of course have a single EHR built on top of this database system, but for those concerned with innovation, free markets and with the problematic one size fits all approach, by all means, let’s build thousands of EHRs with user interfaces and functionality to fit every individual preference, all accessing the same exact database, containing the same exact records. This Universal Health Record will be, by definition, complete and correct at all times, since all health care applications will be built on top of this database, much like browsers are built on top of the World Wide Web. Switching EHRs should be as simple and straightforward as changing from Firefox to Chrome, not to mention how happy the folks advocating substitutable applications instead of walled gardens would be. Oh, and the sum total of investment in a homogeneous data infrastructure is dwarfed by the various other public and private initiatives, all ultimately funded by tax payers.
The 800 pounds gorilla in the room is of course privacy and to a much lesser extent security. A medical database system of this magnitude would have to be built and administered by the Federal Government. Patients would have to be uniquely identified in the system. Granted such Universal Health Record would accessorize well with a universal health care system, but let’s face it, if you are on Medicare or Medicaid, the government already has your medical records. Private payers have mega databases chockfull of medical records and so do EHR companies and pharmacies. Your data is being constantly de-identified, sold, re-identified and exploited for financial profit. Once the planned information exchange network kicks in, a host of State and private agencies will also begin building their own repositories of medical records. The privacy horse has left the barn, and the best we can do now is regulate the use of what was once private. At a minimum, the Universal Health Records database will ensure that you can see everything everybody else is seeing and have some say in its accuracy and utilization, which is orders of magnitudes better that the alternative.
An easy to grasp, clear and compelling case for universal simplicity. Outstanding. There was a time when I would think it hasn't a chance, but that was before the Arab Spring, the dissolution of the Soviet Union, the fall of the Berlin Wall and the election of a Black president.
ReplyDeleteKeep writing. (And for my part, toss in a biometric national ID card to go with it.)
Thanks, John.
DeleteI would love to see one of those cards in use here.
In terms of platforms, you're right, it has to start with the data. And the first step in realizing some ideal platform will be ensuring effective exchange and structuring of the data. But I can't buy into the idea that a single, unified database would be the best solution to this problem. The definition of the data will be constantly changing constantly, we'll need folksonomies vs taxonomies. The data needs to assemble around the patient, in my mind, not some database that happens to have patients in it up in the sky.
ReplyDeleteIn this age of bottom-up solutions via social media that has led to the Arab Spring, we can organize ourselves and perhaps our data much better than a more static, top-down solution ever could.
You must see this video. Have you ever talked with Gary Johnson @CLOUDHealth http://www.youtube.com/watch?v=afMjZgvtsp8 ? He has some very different, more bottom-up approaches that you may find interesting, although perhaps, today, as politically impossible. But I'm with John, let's not ever let that stop us!
I think I need to write a followup post to this. Perhaps a bit more technical.
DeleteI am not thinking about a single platform, only a single data repository. Large EHR vendors would provide platforms and smaller guys would plug into those platforms, all accessing and modifying the same raw data in real time.
(see the rest of my combative/frustrated/not very well thought out comments on G+, and I do apologize)
If I may there is an existing standard already in use for reporting by the us governement and also by the library of congress the finish healthcare and some others. You would just have to add an export capacity in this format from your EHR. And you can add on top of it protocls like HL7 etc.
DeleteIt is so pleasing to start to see this kind of conversation starting to occur.
ReplyDeleteThere will never be one single database, but we can start to work on a universal platform, where applications can plug & play and access standardised data from other systems.
I blogged about this back in 2010 - http://omowizard.wordpress.com/2010/08/23/gimme-an-uhr-yes-please/ - and there is certainly momentum gathering in this direction. See also the CIMI initiative - http://omowizard.wordpress.com/2011/12/15/why-the-buzz-about-cimi/
The work that we are doing in the openEHR Clinical Knowledge Manager - www.openEHR.org/knowledge/ around creating standardised EHR content definitions is also garnering interest, especially in Europe, Australia and Brazil. This work is certainly one candidate as a means to progress the CIMI work forward as well.
I'll be bringing it to HIMSS next month if anyone is interested in finding out more about this Health2.0 approach to EHR content.
I love your uhr blog post, but why not a single database? Why "have the right health information available at the right place at the right time", instead of have all the information at every place at all times?
DeleteWhy does it need to flow instead of just accumulate? Flowing implies possibility of errors, mishaps, lost in transit, etc.
Why move it in this Internet age instead of accessing one authoritative copy from everywhere?
I understand the privacy concerns, and I do understand the established industry concerns, but we are deluding ourselves thinking that having multiple copies of our information floating around is somehow safer than having everything in one place. Is this a uniquely American concern?
I understand that a mega database might seem desirable, although I'm not sure that will actually solve our wish to achieve the 'right triplet' - right data, right time, right place. Do we *really* want everything available all the time? That's a hell of a lot of data to trawl through everytime we access a health record.
DeleteOn the other hand, shared access to standardised and up-to-date, curated lists (eg Problem/Diagnosis lists, Adverse Reaction lists, Medication lists, Alerts), plus pithy and timely communications (such as discharge summaries, specialist letters and referrals) would revolutionise patient care. Note that I specified that these need to be standardised, so we really know what the data means, and can safely compare apples with apples.
Jurisdictions, such as the Australian national program (NEHTA), are avoiding a single database - preferring clinicians and organisations to keep their own local clinical records in great detail. However NEHTA are leading work to provide a central Personally Controlled Electronic Health Record (PCEHR) that will hold key document summaries and, in addition, provide an index that will allow clinicians to find the details in local repositories when they need it.
Maybe as we learn more how to share health information the environment will change, but for a myriad of political and technical reasons, it is unlikely that a single database will happen soon. Expect it to occur in incrementally, if it occurs at all - perhaps organisational, then maybe regional scope expansions might happen. National repositories I predict are not likely, and international, won't happen.
Data can be liquid if is based on standardised definitions and we share it sensibly/appropriately - hence our work on archetypes in CKM, to ensure that the data can be both stored in detail in a local EHR and can be safely exchanged.
The current adhoc way of defining data in each proprietary system should be ringing alarm bells if we start to share any atomised data. That is why we are currently locked into sharing (largely non-computable) CDA documents at present.
So, while that does enable some sharing of health information in the short-term, relying on non-computable document-based records precludes leveraging the data for other purposes such as clinical decision support, aggregating data, comparative analysis etc which will become increasingly valuable as we accumulate health information over time.
Can't wait to hear more about this at HIMSS, Heather. I'll be interested to hear about the Brazil connection as I have some contacts and an interest in driving these kinds of solutions there.
ReplyDeleteA relevant, however shameless, plug. We'll be talking about exactly these types of plug-and-play platforms at the eCollaboration Forum at HIMSS12. Agenda's been published. Hope to see you all there! http://collaborativehc.org/ecollab12/ecollaboration-forum-agenda/
In regards to the conference, I spoke with Josh Newman, MD in charge of health strategy at SalesForce today, and they get it, and with payment reform here in the US, see it as an inevitability toward these types of open platforms.
I am starting to regret my kneejerk decision to not go to HIMSS this year :-(
DeleteY'all have a round of pink Martinis on me.... :-)