I think the ownership of medical records should be reversed. Right now the doctors behave as if they owned the records and the patient has to ask for them. Instead the patient should be the owner of the records to which the doctor gets granted access as needed. All test results, X-rays and everything else should go into the patient's record and owned by the patient.
That sounds great in theory. But how could we actually put it into practice? Who will build and maintain that personal health record system and where will the funding come from? Patients are generally unwilling to pay. Google, Microsoft, and Apple have tried to build PHRs to some extent but functionality and adoption have been limited. No one really trusts the government to maintain a big centralized repository of patient data. But decentralized systems are highly complex and prone to breakage. No one has really found a solution yet.
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.
I agree that it's a very difficult problem but I think it could be solvable if people actually sat down to solve it and could impose standards. At a minimum require all systems to have an export function to a standard.
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.
Every current EMR / EHR application can export data in standard formats. That's not a significant problem any more. The federal government has effectively already imposed standards compliance as a requirement.
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?
>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.
You haven't answered the question of where the money will come from. Healthcare provider organizations are generally unwilling to pay such duty fees. HL7 FHIR is great but it does nothing to address the cost structure. This is a political and economic problem, not a technical problem.
I suppose the obvious answer is to require them to pay — as you say, it becomes a political problem for politicians to write law mandating it and the providers to lobby for it not to be forced.
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.
Large provider organizations are never going to totally surrender control of their patient data to some hypothetical government-sponsored monopoly. They may outsource some aspects to cloud platforms or SaaS vendors, and they may be persuaded to share data with other organizations for the right incentives, but we'll never see a major hospital or clinic totally give up control of data that's essential to their business. So your proposal wouldn't produce any cost savings; costs would actually go up.
If the mandate (whether by regulatory or insurer/market force - we’ve established that the providers don’t want any kind of standardisation or data transfer, the hypothetical I’m proposing is that they’re dragged into doing it) is that they have to put their data into some data broker, if they want to keep their own copies too then the cost of doing that is their problem (or a calculation that the value outweighs the cost).
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.
I would be interested to know more about which large hospital information systems can import and export data from their competitors. I understand that FHIR is planning to meet this need, but I don't see much information on which system implement it and which large healthcare systems are making use of it.
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.
Pretty much all large hospitals are now using systems which are technically capable of importing and exporting data in standard HL7 formats such as V2 messages, CDA, and/or FHIR. The trouble is in establishing the working interfaces between hospitals. They don't necessarily want to spend money building interfaces to share data with their competitors. FHIR implementations tend to be a little cheaper than older standards but the obstacles are still primarily political and economic rather than technical. Health information exchanges (HIEs) have helped in some areas by acting as centralized routing hubs so that every hospital doesn't have to build individual point-to-point connections with every other hospital.
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.
I think that is the critical point: there is no interface between hospitals. What little infrastructure the HITECH act sketched out on this point was vague and inadequate. Clinicians and patients are most concerned with communication between hospitals or healthcare companies; miscommunication on this level is the cause of real pain for real people and in many cases actual death.
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.)
If we limit the scope to summary patient chart data, an HL7 C-CDA 2.1 CCD which gets a perfect scorecard can be imported into any modern inpatient or outpatient EMR/EHR application with pretty good fidelity. There will be a few edge cases and data mapping needed depending on the specific application, but generally not much.
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.
I'm not sure what you mean there. If you put a table with rows and columns in the narrative text portion of a CDA that will be preserved across systems. At least I've never seen a real world application that actually modifies the pseudo-HTML narrative text beyond applying some basic style sheet formatting.
The author of the article describes the problem as such:
> When a patient with a complex medical history like Michael arrives under my care, it’s like opening a book to page 200 and being asked to write page 201.
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.
> 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?
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.
If anything law enforcement is even further behind than healthcare. The FBI tried to develop a comprehensive system for storing and sharing case data but it was a complete failure.
I wasn't comparing effectiveness - I was asking where the money comes from. As far as I know, pulling up stolen vehicle information doesn't stop at the county/city/state line.
Also, after the first failure the FBI tried again with a bigger budget and better process and succeeded[1]
This is what we're doing at Patients Know Best (https://www.patientsknowbest.com) -- we are giving patients an aggregated view of their medical data and we're interfacing with many providers. As many of you mentioned, the major issue is to solve is the subtle, but important differences in vocabulary. Even if providers can export data in "standard formats", those standards are often not specific enough so you need to build something that can translate between them.
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.
HL7 is considered a standard format. If you spend a few minutes in that land you can end up very troubled, very fast, and it sounds like you know this.
There people making big money off the format, just by converting flavour A to flavour B for big organisations. It’s grim.
The big tech/medical records companies will have to lead the charge here. Imagine that big tech sets the standard, and the hospitals who are abiding by the standard receive an "Apple Health Certified" stamp of approval.
These certified hospitals have increased visibility within the curated marketplace and gain greater access to patients. This then naturally creates an incentive for hospitals to catch the standard, lest they be left behind. The tech companies are willing to put in the effort, it gives them access to a new marketplace.
I think, the idea is the distributed ledger, which allows you to store the information not with a centralised authority, but yourself. Blockchain would not necessarily be a good technological approach, but a distributed ledger, would be.
In general the healthcare system can't rely on patients to store their own data. Patients lose devices, forget their passwords, get hacked, etc. Certainly we should make it easier for patients to obtain copies of their medical records but it just isn't feasible to put the patient at the center of the data flow.
This is not a proper use case for blockchain. Blockchain technology is primarily for allowing transactions between parties that don't trust each other. That's not a problem we have in the US healthcare system. Providers are all known and generally licensed by the government. They adhere to strict rules of conduct, and if one of them breaks that trust they are subject to civil and criminal penalties.
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.
First, lack of trust doesn't imply bad actors in the system.
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?
we are working on it at https://1up.health which helps patients or developers aggregate and build on a consolidated medical record. We have a lot of developers making some really cool applications from those for patients with cancer to others helping individuals seeking life insurance with individuals connecting records from multiple health systems (we support 200+). Id love to hear from anyone else building applications in this space.
Most large healthcare provider organizations already provide patients with online access to their records. Patients can download or print those records, but the problem is that it's still tough to integrate records from multiple different provider organizations in a clinically useful way.
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.
Patients do have rights to the records, but as described, it's really hard to actually get them and keep them in a useful, accessible format.
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.
I certainly do care. Gov't in my country is pushing for an integrated EHR hat looks like yours (except the level of security is much higher 'cose the data are not anonymous), but the way those records are used is a bit shady.
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...
Why do you think they should be owned by patients? I’m not disagreeing with you, it might work but I would appreciate a more pursuasive argument.
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.
Treating medicine as a generic, traditional business has done nothing positive for society.
There has been a lack of innovation for fear of breaking things, but things are seeming more broken all the time. Maybe we'll start to see some traction.
I'm not advocating for patient ownership of medical records. I'm not in the field, so I don't know whether that makes sense. I do know that profit motives tend to backfire in this industry as everyone tries to get theirs before the house of cards comes falling down.
Fair response. I am in the UK, so it’s not profit orientated in any case. It is moving that way to a certain degree, but clinical decisions are based more on what’s good for the patient and in a defensive manner. The opposite effect is in place: reduce costs wherever possible (don’t do tests unless it will change management, don’t treat unless it will improve the patient’s life).
I'd much rather have some base safety net. As it stands in the US, no amount of capital is sufficient to protect yourself against a lifetime of medical expenses. This is a perverse incentive that injects greed, selfishness, and sometimes desperation into our everyday lives.
The patient should own the records because he/she pays for it. And to avoid repeated unnecessary tests and procedures information has to stay with the patient, not with the doctor.
patients pay for care, not for records. If you employ a photographer for a wedding, they often insist on keeping the copyright of the photos. You have the right to use them personally, but the photographer retains the copyright.
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.
This is a revealing insider's look at what happens when medical records vanish or are mishandled as patients move between physicians. It's also a heart-wrenching story of one patient's journey -- one that should interest anyone who has crossed paths with the American health care system. After all, if they were a disease, medical errors would rank as the third leading cause of death in the U.S., right behind heart disease and cancer.
This is a great point. Medical researchers would do well to stop harassing people about their lifestyle (it's not obvious much headway can be made there anyway) and focus instead on the crazy number of deaths caused by interactions with doctors and hospitals.
Medical researchers generally aren't harassing people about lifestyle issues. The concerns over lifestyle come more from practicing physicians, politicians, bureaucrats, employers, and economists. As a population we are increasingly killing ourselves with overeating, substance abuse, and lack of physical activity. Unless we can get a better handle on lifestyle issues then the healthcare system is going to collapse and there won't be much that medical researchers can do about it.
Cool story bro. Show me the randomized lifestyle intervention trials that actually improved mortality outcomes for heart disease, and I'll believe you.
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.
That is a good one, and very relevant. But the control group's unusually good outcomes need explaining. They are better than expected for "treatment as usual," and genuinely a potential confounder for outcomes.
Agreed, that is a question mark on this study - I think more basic research needs to be done in this area. As you can see from other comments in this tree, many folks think that the science on these matters is settled. As Mark Twain said: “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”
You missed the point of my comment and seem to be trying to pick an argument based on some preconceived notions. I made no claim as the effectiveness of lifestyle interventions. I merely pointed out that poor lifestyle choices are overwhelming our current healthcare financing system. This should be clear to anyone who as looked at the data. If the current trend continues there simply won't be enough money to pay for essential care any more regardless of who does the paying. Therefore, if we can't improve the lifestyle issues there will be serious consequences for the whole country including decreasing lifespans, reduced economic competitiveness, and even impacts to national security.
You missed my point: claims like "I merely pointed out that poor lifestyle choices are overwhelming our current healthcare financing system." are empirical in nature and need empirical studies to demonstrate the truth of them.
It's been studied ad nauseum. And please don't waste our time asking for citations; there are a zillion peer reviewed articles which clearly demonstrate that lifestyle factors have expensive health consequences and that the situation is deteriorating. They're easy enough to find if you want to do more than argue.
I'm not sure why you persist in arguing against a point that I never made. It is well known that the majority of cases of some of the most expensive diseases such as type 2 diabetes or COPD are primarily caused by poor lifestyle choices. Whether effective lifestyle interventions can be found is an entirely separate issue.
This is heartbreaking. As someone at the core of the technology trying to correct some of these problems, the biggest problem is the fragmentation of the market.
My MD sold his practice and when I showed up at the vendee he told me not only didn't he have the 4 inch thick plus paper-only but also that a) it wasn't yet scanned and b) he wasn't even sure where the file, much less when the poor assistant in the office was going to scan it.
From a purely technical standpoint the HL7 Continuity of Care Document (CCD) is intended to address this issue by allowing a provider to put a summary of a patient's entire chart (including a plan for future care) in a single XML file and then give that to another provider when transferring care. It works well when properly implemented, but unfortunately many healthcare providers haven't done so completely yet. There are also practical problems in just moving the file from one provider to another.
The CCD, though a standard, is far from a univeral bridge. You can represent the same things in different ways, use different vocabularies. Even if you standardize on the "blessed vocabularies" you still have many ways to code the same thing.
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.
That's true to an extent, but in practice the problems aren't too serious if everyone follows the C-CDA 2.1 CCD specification. It standardizes the vocabularies in each section so, for example at least you can be sure that prescriptions were coded with RxNorm.
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.
The problems with the CCD (having so many different ways to represent the same thing, having a different flavor for each system) are unfortunately passed down to new iterations of healthcare standards. New standards (like FHIR) are designed to fix problems with older standards, but then when it comes to implementation they are built to be backward compatible with the older standards, and so inherit some of the same problems (in this case, the ambiguity of representation).
HL7 FHIR makes implementation slightly easier, but it doesn't do anything to solve the data modeling and coding problem. There are multiple ways to represent the same patient chart entries in FHIR just as with HL7 CDA R2. Take a look at the C-CDA on FHIR implementation guide.
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.
It's a standards of many standards. Each system (radiology, laboratory, scheduling, etc.) has their own system with it's own flavor of HL7. It then communicates with the larger hospital-wide system (Epic, Meditech, etc.) through interfaces that translate form the system specific to the flavor required by the hospital-wide system. Each interface implementation tends to make their own decisions about what certain pieces of information should look like, decisions that are specific to the healthcare organization and systems that they use.
The irony here is that most clinicians would be happy with something that is simply searchable: even a large PDF would go a long way towards meeting their needs. Instead they are provided nothing at all, or stacks and stacks of physical paperwork.
I needed medical records from a hospital across town for a patient on my shift last night. Unit clerk called the hospital to request records. They then printed about 60 pages from their electronic record. Those pages were faxed to our department. Our unit clerk scanned the printed pages from our fax machine into our electronic record.
Some patient notes are a scan of a fax of a scan of a fax.
This is a perfect explanation of why OCR of medical records is so difficult.
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.
I wonder if current attempts at EHR interoperability are a case of "the perfect is the enemy of the good". Obviously the ideal solution would be one where well-structured interoperable datasets are produced and shared. This would enable very targeted analysis of patient data, and sophisticated clinical decision support functionality. However, it seems like this is still not happening, and the convoluted nature of many HL7 standards is certainly not helping.
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.
> So I've come to think that it would actually be preferable to put most of the health data into PDF-like documents
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.
A standard for exporting summary patient charts in plain text or PDF already exists as the VA Blue Button format. It works to an extent, but the lack of coded data limits effectiveness. And there are still practical problems in that most providers don't have easy ways to import files given to them by patients. There are serious security concerns with accepting files from untrusted sources.
Health care is by nature very complicated and any attempt at standardization is going to be sophisticated. Just look at how many ICD-10 codes there are.
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.
Yes, but FHIR was the result of many years that had previously been wasted with HL7 v3, which was so convoluted that at some point some people in the community gave up on it and came up with FHIR to get things done. The clock did not start ticking in 2014. HL7 already wasted a lot of time and effort, to the very real detriment of many patients around the world.
It's easy to criticize in hindsight but FHIR wouldn't have been possible without the lessons learned from HL7 V3 so there was really no wasted time. Sometimes the only way to learn is to make mistakes.
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.
ICD-10 contains thousands of codes, but unfortunately even with all those sometimes it still isn't complicated enough! There are important diagnostic concepts that can't be expressed with sufficient detail in ICD-10, so we end up having to supplement it with additional code systems such as SNOMED-CT.
>However, it seems like this is still not happening, and the convoluted nature of many HL7 standards is certainly not helping.
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 would disagree that the HL7 organization is looking to make these standards less convoluted. On the contrary, the large and established vendors help write these standards. 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 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.
Did you use something like Mirth Connect? I was going to ask what HL7 you were using, but it looks like you were using v2.
> 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.
HL7 standards are developed on a consensus basis by providers, payers, vendors, governments, and academics. The established vendors certainly help, but I deal with their HL7 representatives on a daily basis and I can clearly see that they're working in good faith. The main reason there is flexibility (and convolutions) in the standards is that healthcare is highly complex. Integration projects are thus labor intensive; software is usually a relatively minor slice of the total cost.
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.
In my opinion, the state of EHR interoperability should be attributed to the vendors of hospital information systems (i.e. Epic, Meditech, etc.) and their larger clients, big healthcare systems. Again, in my opinion, neither of these stakeholders has much, if any, incentive to develop and encourage a smooth or even mostly functional interoperability story. Every vendor wants to lock their customers into their product.
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.
CMS is trying to address that by penalizing organizations that engage in data blocking. We'll have to wait and see whether the new regulation is actually effective.
This article clearly describes the challenges we are trying to solve at https://picnichealth.com/ (YC S14). Our goal is to take the burden of compiling and maintaining a complete medical history off of the patient while at the same time providing them with the utility of having access to and the ability to seamlessly share their records with future doctors.
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.
92 comments
[ 3.2 ms ] story [ 176 ms ] threadHealth 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.)
https://sitenv.org/scorecard/
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.
https://en.wikipedia.org/wiki/Virtual_Case_File
Also, after the first failure the FBI tried again with a bigger budget and better process and succeeded[1]
1. https://en.wikipedia.org/wiki/Sentinel_(FBI)
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.
These certified hospitals have increased visibility within the curated marketplace and gain greater access to patients. This then naturally creates an incentive for hospitals to catch the standard, lest they be left behind. The tech companies are willing to put in the effort, it gives them access to a new marketplace.
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.
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.
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.
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.
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.
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.
https://www.va.gov/bluebutton/
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.
[0]: https://www.hl7.org/fhir/domainresource.html
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.