Hacker News Reader

Comment by nradov | Hacker News Reader

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.

View on HN

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.

https://sitenv.org/scorecard/

Other types of data are still problematic.

> few edge cases

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.

https://en.wikipedia.org/wiki/Virtual_Case_File

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]

1. https://en.wikipedia.org/wiki/Sentinel_(FBI)

Lotus notes (at least in Baltimore). There was a good thread on it here where this was viewed quite positively. https://news.ycombinator.com/item?id=17726094

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.

I work for a software company in the HIE space. We like to say, "When you've seen one HL7 message, you've seen one HL7 message."

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.

HL7 is an absolute shitshow.

Every company charges 10s of thousands of dollars for every "interface", which is one program sending something to another.

Sounds exactly like a proper use case for a blockchain.

In what way would blockchain solve the problems?

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?

There may be some use of blockchain but it doesn't solve the problem of incompatible data formats. That's the real problem.

Combined with the need for change. Reports are regularly altered and amended. How would this be handled?

Reply on news.ycombinator.com