Paper Trails: Living and Dying with Fragmented Medical Records
undark.org
undark.org
Health information exchanges and payers (insurers) have been doing great work lately to facilitate authorized providers sharing data with each other using standard formats such as the formats published by HL7. So that does at least prevent the need for duplicate lab tests and reduce the risk of medication errors.
The problem I see is that a lot of the current players in the health system benefit from hidden data and duplicate procedures so it would take a lot of political courage to force them to open up.
The problem is that there is no organization which can provide a stable repository for every patient's data and build secure interfaces to thousands of different provider organizations. That's extremely expensive and there's no real business model. Where will the money come from?
It would be a cool idea if a non-profit organization could handle it. Healthcare organizations would pay a "duty fee" for requesting or sending records. We just need a standard for transporting it. FHIR makes it de facto HTTPS.
The closest analogy I can think of is the Data Communications Company that intermediates smart meter data in the UK between the energy suppliers and end users. As a monopoly, their prices are regulated (well or not is a political problem…) and all the providers have to use them.
If the data exchange was the source of truth, the providers would presumably save some money not having to store their own copies (or at least, could store more summarised versions) with all the requirements that HIPAA/GDPR entail.
However, there’s money to be had for a huge aggregated database of everyone’s health records, stored in consistent format for easy consumption…maybe we should be careful what we wish for.
In an ideal market, another player who didn’t want to hoard data could undercut them (not having that cost).
Tuning either the cost/benefit of outsourcing or the nature of the incentives, I suppose, are the key.
Putting the responsibility on the patients to transfer data strikes me as backwards. The vast majority of patients whose lives depend on the easy transfer of records from one organization to another are incapacitated. They have been hit by a car, suffered a stroke, or are moving from one facility to another.
Yes any initiative that relies on the patient to move data around is doomed to failure. Patients need to be able to get access to their data, but to deliver effective care the data has to flow between provider (and payer) organizations.
In terms of exporting data from one HIS system and into another, it's not clear to me that this will every work without more infrastructure. The exported HL7 data from one organization is going to be of little use to another, they would need some very specialized software to mediate between the data in the exported HL7 file and their own systems. Importing it directly into their hospital information systems is simply not going to be possible; their systems won't understand the myriad of idiosyncratic decisions that the other organization has made, often in response to the specific systems they have purchased (scheduling, laboratory, scheduling, etc.)
Other types of data are still problematic.
It’s all edges. It’s really grim. And once you have it sorted out, another variation pops up and fails in some new and awful way. Trying to maintain charts with columns and rows for example, basic stuff, in is near impossible. Just when you crack it you find some down stream system you have no control over is transposing rows and messing up records. It’s critical stuff and it’s a mess.
Even Epic doesn't have the ability to consolidate multiple CDA documents, or even write information directly to the chart. Each one requires manual review. Standards for exchange are not really the problem.
How does law enforcement organizations store and exchange case data? That's another area that is likely to be expensive with no real business model - granted, there is no health equivalent of the FBI - maybe there should be.
Also, after the first failure the FBI tried again with a bigger budget and better process and succeeded[1]
This is a though and fiddly problem, there's a reason why Google/MS/etc. have all bailed out. You can't just build something once and let it scale for the whole healthcare system.
As a technical matter, no one has yet demonstrated a blockchain that can scale to the amount of data and transaction volume required to maintain a patient chart for everyone in the country. Especially if we include images and genome sequences the data volume is in the exabyte order of magnitude.
This is fundamentally a political and economic problem. Throwing immature new technology at it won't solve anything.
Second, a blockchain creates a decentralized public ledger. Patients can be owners of their records, and sign to share access. There is already a working implementation of this technique in Filecoin.
Third, PoW is the 'new technology', a blockchain is just a data structure. e.g., Binary trees are no good for the U.S. healthcare system.
I know there are politics involved, but we are not politicians, why not try to solve the problem with the tools at hand?
Every company charges 10s of thousands of dollars for every "interface", which is one program sending something to another.
If something gets questioned, there is another copy somewhere.
Health Information Exchanges (HIEs) solve the problem to some extent by importing data from multiple provider organizations and synthesizing a single longitudinal record for every patient. But not every provider is part of an HIE, and no HIE really covers the whole country.
We've chimed in a few other parts of comments, but at PicnicHealth this is exactly what we're working on. If you're interested in fixing this problem we'd love to talk.
But the way it is pushed onto citizens is clearly wrong. Basically the doctor proposes you to switch to that system, citing the advantages, but not the disadvantages...
Also, with EHR, "ananymous data" doesn't mean much : your name is always on the papers produced by the doctors :-/ So anonymisation means : either remove identification data, or make sure it doesn't appear first hand. In both cases, in requires an action, and given the scale of the stuff, it won't be practical...
There are arguments against. Any text written is copyright of the writer, not the person it is written about. Why should the patient own the copyright of that text?
Data access is not the same thing as ownership. Additionally, this is not the case for other data held about someone. If you use a lawyer, they own (and don’t provide access to) the notes they make. Same for any other service provider.
And to avoid repeated tests, it means that this information must be shared between different healthcare organisations.
There is an argument against. Ownership implies the ability to do with the data as you wish, including removing certain parts or withholding others. This could lead to issues where a patients wants a test which is not indicated, and by providing edited records, clinicians may be misled. Similarly, would it be acceptable to delete information referring to a current HUV/Hep C or TB infection? And what about psychiatric patients? Sometimes patients lack insight into their condition, particular in psychosis and delusions. This can persist after acute episodes, where they deny they were unwell during the episode. These patients could then remove anything referring to this section, making future care much more difficult. Finally, medical records also refer to cases where there are legal issues. They may refer to suspicions of child abuse, or the expressed intent of a patient to go kill another. This information should not be blocked by difficulties with patients owning the data.
Some patient notes are a scan of a fax of a scan of a fax.
As an engineer working on this, it's frustrating that the computer vision research community treats document OCR as a solved problem. New papers and competitions are exclusively in fancy settings, like slanted text outdoors on a busy street, or handwritten Urdu with only a small set of training labels.
Meanwhile our medical data is locked up in a scan of a fax of a scan of a fax, with a mixture of printed text and handwritten notes, with table lines crossing the text. Paid services like Google's Cloud Vision API struggle at best, and the best available open source software (tesseract) isn't even close.
http://www.hl7.org/implement/standards/product_brief.cfm?pro...
So a CCD produced by Nextgen won't always come into Epic the way it's intended (not picking on those 2, just an example).
I've come to realize that even though the CCD tries to be all things to all people, it suffes from the same issue as many of the vocabularies themselves: data precision is an afterthough. Clinical informatics lives in a utopia where everything is precisely represented and perfectly documented. Actual clinicals deal with partially-known information, imprecise or unrefined representation of diagnosises, procedures, meds, etc; and just have to make the best with what they have.
But certainly testing is needed to ensure proper end-to-end interoperability. And of course if the users don't enter the data correctly in the first place then no interchange format can fix that.
http://www.hl7.org/fhir/us/ccda/
Healthcare data is fundamentally complex. It is impossible to come up with a single canonical way of representing everything we might want to record about a patient. The standards reflect that essential complexity.
So I've come to think that it would actually be preferable to put most of the health data into PDF-like documents, and focus on optimizing the accessibility of the data through good full-text document search that can assemble an overview by showing document snippets (i.e., allowing to get a broad cross-document overview through document previews, rather than requiring opening each document individually).
I guess some kind of especially important data, such as information on current medication or drug intolerance should really be kept in a fully structured format to enable clinical decision support, but for a lot of other information, a light-weight system based on unstructured data combined with good information retrieval tools would already improve on the status quo quite significantly.
I've thought about this before and came to nearly the same conclusion. It would also help in extremes, allowing doctors to switch back to pure paper should the situation call for it while allowing for that information to be smoothly integrated back into the system once it becomes available again.
What good is an EHR if the power is out?
> I guess some kind of especially important data, such as information on current medication or drug intolerance should really be kept in a fully structured format to enable clinical decision support
Which may help, but as detailed by this article the process of ordering healthcare and the eventual delivery of that care to the patient is often a patchwork of multiple departments and staff with ample opportunities for error anyways.
I used to volunteer in the pharmacy. We'd get an order for a medication. We'd fill and then label that medication. It would then go into a bin on a cart, one bin for each department in the hospital. The cart would go out, and the bins would get delivered. The medication would then be stocked in the department using a slightly different setup for each department. Then the nurses would have their own individual processes for getting that medication, taking it to the patient and then delivering it to them.
An EHR is _one_ very small part of successfully performing this complicated ballet.
HL7 is complicated but I see a lot of work being done to conform with the FHIR standards. FHIR has only been around since 2014 and release 3 was only completed last year. I do have hope for standards to take precedence in the EHR realm but it will take time. Most EHR software was created in the late 80's and there's a lot of legacy code, client customization, and regulations to go through in order to release this code. Healthcare doesn't leverage itself to an agile "move fast and break things" ideology.
In addition the Commonwell alliance was supposed to help alleviate these problems, but the fact that Epic didn't join really ruined things there.
FHIR by itself is no panacea; it has some nice improvements, and makes implementations significantly cheaper and more efficient but it doesn't enable any fundamental new use cases. HL7 V3 standards such as CDA R2 are actively used today to deliver patient care all over the world.
I actually think HL7 (as an organization) is beginning to get us to a point where it's not as convoluted.
>So I've come to think that it would actually be preferable to put most of the health data into PDF-like documents, and focus on optimizing the accessibility of the data through good full-text document search that can assemble an overview by showing document snippets (i.e., allowing to get a broad cross-document overview through document previews, rather than requiring opening each document individually).
I think that's what is intended with FHIR (fast healthcare interoperability resources)[0]:
>A domain resource is [a] resource that [...] has a human-readable XHTML representation of the content of the resource
IIRC all the other FHIR extend the DomainResource class. So you have the narrative and then the resources (supporting data) that makes up that narrative.
I have worked on several integration projects, we always had to customize the interface on both sides of the system (the hospital information system on one side, perhaps a radiology system on the other). Moving one step up and exchanging data between hospital information systems and all of the smaller vendor systems is just that much more complex.
> In my opinion, it is in their interest to leave enough room in the standards to require ever more and more software in order to bridge the gap between systems.
I get your point. When I read about FHIR extensions, my immediate assumption was that a vendor would use it to throw a wrench. But FHIR does have an idea of conformance that I think better addresses the issues with earlier standards.
If you have a specific suggestion for simplifying or otherwise improving any HL7 standard then please submit a formal change request. The process is very open and accessible. I've done it many times myself.
Software vendors see interoperability as a wedge into their lock-in on their customers, making it easier to migrate data from one system to another. I believe the incumbents fear an innovator rather than the other established players. But they would prefer to make it harder to migrate away from their systems, regardless of the target.
Healthcare companies want to keep customers inside the walled garden of their system and actively discourage them from moving to competing vendors. In their view, patients should receive all of their treatment from them or their close partner organizations. I don't believe that clinicians at these organizations are looking to hurt or bamboozle anyone; they are of the opinion that their healthcare organization provides a higher quality of healthcare. And, in all honesty it is safer: those partner organization who have access to the same central system will have access to all of the customer's data.
I once worked for a small healthcare system and my team designed and implemented software to transfer information from one organization to another through disparate systems. The organizations involved were partners, when interoperability with competitors was discussed this was quickly pushed aside: the project needed to be kept "cost effective" and these were "version 2.0" improvements. While these are reasonable arguments, communication with competing organizations was never implemented. The managers of the project were correct: it would cost money to implement this interoperability, money that would be out of pocket for the organization. And to what end? To help customers purchase a competing vendors products.
The HITECH act was meant to provide the money to fund interoperability. But now that I've worked for both healthcare and software vendors, it is less clear to me... What was the goal of the HITECH act? For the healthcare side, the goal was clearly to computerize the medical records and this was the cudgel used to force clinicians to carry laptops around as they spoke to patients; the organization I worked for managed to almost entirely eradicate clipboard usage. From the software vendor side the goals were similar, to provide the functionality required by the act in order to qualify as a "meaningfully useful" system. Interoperability between organization seemed to have been sketched in at the end and the guidelines didn't seem nearly as clear.
To my mind the question boils down to: how does the government (state or federal) incentivize interoperability? Clearly a single payer system would be the easiest answer: the government would be paying for all care and could simply demand this interoperability be present. While single payer isn't the only solution, I beliebe we will need a change of similar size to push these vendors into cooperating, despite the fact that it might hurt their bottom line.
https://www.healthcare-informatics.com/news-item/interoperab...
Given the current state of EHR systems (and their lack of interoperability) this often means dropping into the world of faxes and paper. To deal with this we have built up systems for requesting, re-digitizing, structuring, and validating medical records (in whatever format we receive them).
If you are interested in working with us to address these challenges, we are hiring in a variety of roles: https://team.picnichealth.com/jobs
Unfortunately, the kind of experiences described are extremely common in transfer-of-care settings. When we were starting PicnicHealth, my grandfather was in-and-out of several different ICUs. Preventable mistakes when moving between facilities and providers — inadvertently changed medication dosages, missed therapy regimens, un-transferred test results — created health emergencies that kept pushing him back further and further from recovery. He ultimately passed away. We had these problems around information management and transfer even though my dad (my grandfather's son) is a doctor, and was continuously in touch with the different care teams. Without a central, complete source of information, things will always get missed.
Patients and doctors deserve solutions to this problem today. Like the author said, you can only piece together a patient's medical history if you're willing to deal with records in any form, including faxing and scanning paper and mailing CDs. It's hard, dirty work, but it's the only way to get everything together. PicnicHealth does this so patients don't have to. And gathering the records is actually just the first part —you need to structure and normalize information in the different records so it's possible to do things like view trends and use control-find.
Full electronic interoperability is slowly coming, but it's been slowly coming for more than 20 years. I would be shocked if in 10 years faxes aren't still being sent. We need to push to make interoperability happen as quickly as possible, but in the meantime patients and their care can't wait.
This is the government certification data for inpatient software: https://dashboard.healthit.gov/quickstats/pages/2015-edition...
The long tail of software products makes connecting everything exponentially harder.
Something more direct, with results related to actual event/non-event cardiovascular outcomes, would be ideal. It's also crazy complicated and expensive, so it's reasonable to extrapolate.
Unless you didn't really want data, and had already made up your mind.