Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm currently working on my thesis, I'm trying to design a radically different take on EMR/EHR systems - http://barnett.surge.sh/

I've come to realize healthcare software is a significantly trickier problem than most realize. Not in terms of technical possiblity, but other factors.

Building healthcare software is really hard - which seems like such a paradox, because surely ensuring highly trained individuals have half decent tools would be a huge goal for society - but almost all healthcare software is still frankly, terrible.

After heaps of reading I've narrowed it down to 3 reasons why healthcare software is so hard to build.

1 - Modern healthcare is complex, and varied. Building any healthcare softawre is no easy task, even simple systems have many other systems to integrate with. But what makes this worse, is that no two places do healthcare quite the same. Between regions, and institutions, healthcare can vary a shit ton.

2 - Healthcare is risky. Sounds obvious, but if your software fails, people die - but this risk creates an attitude of "dont touch it". Changing systems has such a risk, that institutions will use the same software until it's so out of date its not funny. This impeeds improvement and innovation.

3 - Healthcare software is hard to sell. Not in the sense that its unprofitable, but that it takes ages to get users. Say if I made video editing software - I could get professionals trying it out tommorrow. However, if I make a PMS, I have to sell it to the entire practice - not just a few keen doctors. From making contact to actually getting a small practice using your software could literally be years - making it super hard to enter the market.

I've been working on this topic fulltime for a year now - and I must admit, I don't have the golden answer. However, I'm designing a system as a response to these factors, an alternative to interoperability, and would love to talk anybody in the industry about it.

http://barnett.surge.sh/

eliot.slevin@gmail.com



As far as I can tell, there's no economic incentive for health care systems to undergo these transformations willingly. Remember, the digital transformation didn't occur until the HITECH act in 2009, which mandated the use of electronic health records. Why digitize your operations and worry about maintaining tech infrastructure when you can do everything on paper with a handful of secretaries? You could argue providing better data-driven healthcare to patients, but guess what--most health systems don't care because they make money every time you get sick.[0]

With HITECH, the government forced them to transition to EHRs, and here's what hospital systems optimized for...

1. Reliability

2. Optimizing billing

3. Guaranteeing compliance with different protocols, particularly those related to billing

Openess? Interoperability? They don't care. You're piling on more technical and administrative costs without the promise of future returns.

> ensuring highly trained individuals have half decent tools would be a huge goal for society - but almost all healthcare software is still frankly, terrible.

You know who hates EHRs the most? Doctors. Do you know who loves them? Hospital administrators. Guess who pays for the EHR? ;)

[0]: An exception to this is Kaiser Permanente. They insure the patients for which they care, so they're incetivized to improve health to reduce costs over time.


> As far as I can tell, there's no economic incentive for health care systems to undergo these transformations willingly

Yes. Thing is, say you have shitty software and see 20 patients in one day. Say you have fantastic software - you'll probably still only see 20 patients a day. The cost of upgrading is usually not justified if it doesn't hit the bottom line.

I'm trying to tackle this by making a system where improving it isn't a huge risk, or cost. For example, it has an extensible user interface - imagine something like atom text editor, or even browser extensions. Say you look at the immunization screen all day, and hate it. Find / build a small extension to arange it how you want, without changing any of the back-end system, and then share it to a registry for other people in your situation. Easy win.

I'm actually designing this system within the context of primary care in New Zealand. We have a socialized healthcare system, which is honestly very effective. Everybody pays for it via tax, and resources are evenly distributed. We even bulk purchase generic drugs for the entire country.

There isn't so much of an evil incentive to ensure all their 'customers' stay sick, but instead funding is a bit hard to come by. Funding happens regionally, and building national healthcare software systems is a huge task nobody but the government is willing to try. The market is so small (population of 4mill) that vendors can usually make more money elsewhere - so getting NZ tailored solutions is rare.

This is why I think the opportunity is in making a crowdsourced system, as opposed to a 'product' to sell.


I have no idea what the market is like in New Zealand, so my insights there are limited, but a lot of EMR systems in the US have a similar notion of customizability built into the interface. Epic, the largest EHR vendor in the US, for example, doesn't sell a one size fits all solution. Hospitals develop their own GUIs and workflows within Epic, but again, hospital administrators make all the UX/UI decisions while optimizing for documentation that bolsters billing. Again, the doctors lose.

For small practices, this might be a viable solution, but then again, they'd probably rather purchase a complete IT solution than something that handles medical records alone.

Also, have you looked at OpenMRS?[0] They have a module system that allows you to develop extensions to the EHR.[1] If you're looking for your thesis to have a big impact, I'd really recommend getting in touch with an organization like OpenMRS or Partners Healthcare to see how you can extend their platforms. If you want an introduction, drop me a note: faraz dot yashar at the gmail.

[0]: https://openmrs.org

[1]: https://modules.openmrs.org/


The reason why so many EHRs are poorly designed is in part because they are so flexible. Don't under estimate the ego of a physician to think their way is superior to the way the doctor down the road does something.

The EHR model will eventually lose because its one sided. Consumers and patients are completely left out of the picture and EHRs have no incentives right now to change. Beyond that companies like Epic are operating on outdated business models. The days of the black box of data that lives inside the four walls of the health system are numbered.

Consumers won't deal with a dumpster fire of technology once they have the choice. Digital health will win once the barriers of compliance and interoperability are broken down.


SQL has 'interoperability' re: an ANSI standard. Theoretically you should be able to get off all those old Oracle contracts right? Eventually there are little nuanced things that users end up building their workflow completely around. Even if you change no functionality and just slightly alter the GUI, you're going to have complaints that something is broken. Inertia is your #1 vendor lock in feature. EPIC is as golden as Oracle just due to resident incumbency.

#2 is the whole risk aversion thing. Any platform migration is going to have political risk attached to it. Nike won't move away from Oracle even if Postgres can do everything it can line for line because paying the $200k maintenance fee each quarter is a cheap recurring cost compared to the political risk of a failed project.

That's not even factoring in #3, the little features here and there which are value-adds to the platform and not part of the standard. I've inherited projects where my firm offers to support O&M for some poorly written ASP 1.1 Classic software. We'll go in, patch some business-logic bug, and get a phone-call later that afternoon asking to rollback our fix. Turns out their users had integrated bugs into their workflow such that when the software operates "properly" (i.e. 'to spec') it actually breaks things (i.e. stops operating in an expected fashion).


While I strongly agree with points 2 and 3, SQL standards are useless when hospitals invent their own schemas and data governance. Looking for serum creatinine? Good luck without local knowledge. There are probably 30 tables (not exaggerating) for that lab, and the closest you can get without chasing 7 people for info is grepping all the table names for "/CREA/".*

*Based on a true story.


Key point


Do we do relevant XKCD here at HN? Cos https://xkcd.com/1172/


You don't seem to understand the market dynamics. Consumer preferences have little or no impact on provider EHR selection. In general the only consumers who really care about controlling their own data are those with complex, long-term chronic medical conditions who see providers from multiple different organizations. Otherwise most patients are satisfied using the captive PHRs tied into individual provider organization EHRs. Real world patients aren't going to switch providers over issues like this.


Actually quite the contrary. I work in this space everyday.

My point was that the model you describe is dated and broken. When consumers have the choice to make decisions around technology, price and value, they'll do exactly that. Right now they have no say in the matter, as you've pointed out.


Oh man, this is so insanely true, allow me to just contextualize this for you with a POV from the States.

I'm not in medicine (oh thank Christ) but I come from a family where I couldn't ignore the the industry if I wanted to. (Literally every male for 3 generations on both sides have worked directly in either medicine in a university capacity after their PhD, actively practice(d) medicine, or more commonly done both.) My mother's an RN, and my sister's a BS/LPN who's one of those "do gooders" who jumps around (on her third graduate degree now) working usually neuro AC or OR full-time concurrently. So I've heard it from the board-level to the overworked resident side to the 'thank god that fellowship is over' and the 'just got off a double and had three GSRs and a handfull of standard MeOHs', from the the early EHR adopters (interestingly enough, B&W/Partners in Boston) side, the pen-and-paper side, to the 'in between'. The 'in between' is the worst for every one, at every level, bar none, unless you're the one on the steaks-and-strippers sales side.

The limbo period is where absolutely everyone is frazzled because things don't work the way they used to. That's fine for us since we design the damn things, if the scheduling API changes we can just use ...anything really... to make that new JSON invocation or XML-RPC call and Bob's your uncle. But everyone can't be expected to "just pop the hood change the carburetor's flow by 3cfm"; they just want their damned car's engine to turn over so they can use the vehicle. So everyone else is fighting new apps and new workflows while still having to make sure that you're still maintaining an SLA of literally 24/7 operational functionality in certain departments with maybe 3 hours a quarter of scheduled yellow-time for upgrades on 3AMs of the first Sunday each month.

Let's start with getting paid, since everyone needs a paycheck, right? The new system dictates that all employees have to badge-in with new RFID's at certain points (entrances, exits, secure regions, etc). In theory, great idea. Part-time employees salary now gets automated plus now we can ensure better operational security (why is Dr Jane, 9AM-6PM, internal medicine, badging into the OR, 4 floors from her office 5 hours after her shift, where all the Demerol happens to be kept...?). Any non-salaried employees pay-check gets tied into the badge-in/out and literally 70% of the staffers forget to do this, since they never had to before and after lunch they're just walking back in as they normally would. Jon the Janitor pulls up his Bank of America statement and is wondering why last weeks check (bi-monthly, with one pay-cycle close period for adjustment/payout -- so some of these hours, remember, are from potentially 5 weeks ago) was for $90 instead of $2400. So he calls HR to get the money he worked for, and Oprah who's been a great HR employee tries to figure out where the 'alter' feature is and after 5 minutes of "bear with me, sorry, this is a new system...(awkward pause)..." they finally figure out how to make adjustments to the hours (turns out the a manager 2 levels up has to authorize the labor change, since it's past the adjustment business rule of +/- 10% of the hours). AP is slammed with a 40% increase of workload since all those checks have been sent out and we're already in to the second week of the new cost-accounting period. So everyone is frantically calling in 5 weeks after the quarter closed as to why last weeks check was for $90 instead of $3400. Having fun yet?

So Tim works the support-desk phones making sure Derm's scheduling is taken care of. He's spent 20 years making sure all those follow-ups are properly scheduled, all the new patients coming in have the proper primary referrals, etc. Not a glamorous job but he's good at it. Jane's in her 50s and been seeing Dr Eczema for 8 years. She's calling to schedule her yearly just to make sure that mole on her neck which was 2 of 5 on the ABCDE ("looks alright now, let's keep an eye on it though") hasn't developed into a malignant growth. He tries to pull up her file (there's about a 75 second delay there as he fumbles around with the new system's UI and "no no, that's not your subscriber ID, that's your patient ID, your member ID is 8 digits and begins with 40", he finally gets to the right modal menu, and has no idea to even see if her doctor has any availability on the Tuesdays mornings she's got some free-time to take off from work. (Before this, he's would have always just told Jane to "please hold.." and punched in the extension number for Dr Eczema's PA, Mr Clockwork to see if there's availability.) So now he's literally iterates through every possible drop-down, for every 15-minute interval Jane can take off work (9AM to 11:30AM, 10 slots), for the next 6 weeks (takes say 4min30sec per patient). It ends up taking him five minutes, but he gets really good over the course of 8 months at clicking buttons (clocks that down to just under 2 minutes, boom!) before a co-worker tells him there's an "Availability" modal hidden 3 sub-screens in that lets you access Dr Eczema's full calendar. (He was sick on that training session day.) Tim's ecstatic.

Don't get me started on the the custom iPads that the CIO thought "we gotta have, it's the new thing!" which no one uses since the GUI is obtuse and every room has a desktop which is far easier to take notes while talking to your patients. 6 months later, 2k iPads are gathering dust and everyone just uses an RDP session into the Win2k12 server since it's way way easier to take notes/make referrals/write scripts. Don't get me started on actual selection process, as board-level CIOs' wife happens to hold 200k shares of pre-IPO stock she scored 12 years ago that's worth a small fortune now. He conveniently omitted that fact, and rather than recusing from the selection committee was actively pushing for it. (True story.)

Now the CIO is evaluating 'hmm should we go to Cerner?' because we have 2k iPads sitting around doing nothing, some 60 year old absolutely-brilliant neurologist who's responsible for a ton of patient draw (as such, a lot of political clout) can't figure out how to use the damned thing. (An apt comparison would be "ever tried to help your grandparents use email during the hotmail-era?" for those of you who remember that sort of thing.) [Basically the equivalent of moving from SAP to Sage500/Dynamics/other-ERP which also happens; the Mayo Clinic transitioned from EPIC to another EHR while my uncle was there, all sorts of fun I heard!]

There are all sorts of issues on the logistics "who gets what money for what and when". E.g. you have changing insurance issues (i.e. OK, so this patient with this internal medical record saw Dr Foo in dept Bar, which we can internal cost accounted at $x, let's get this invoice for $y out to... (oh damnit, ok who is their health insurance company, let's ping the state's open exchange since this patient gave us their MassHealth ID number[or whatever appropriate exchange your state has if they opted to take the ACA federal funding] and see who their insurance provider is so we can bill this out). Single-payer would be a blessing in reducing complexity!

If you've ever wondered why some cities drop 12 million dollars on a new HR platform only to have it fail 18 months in, it's because information management is hard, regulatory reporting burdens are high, and transition costs (both the political stake the primary project manager who initiates the change-over, as well as the actual quantifiable monetary costs) are astronomical. ATC still uses software designed in the 70s where their web interface is literally screen-scraping IBM CISC software. It's horribly inefficent, but it's been battle-field tested.


I work in healthcare integration. I have interfaced with EPIC and Cerner and pretty much all the other main EHR platforms and seen my clients struggle with their IT.

You sir are absolutely spot on.

As for single-payer, well yes it does make a huge difference on the billing side which is often the biggest IT/tech user of an hospital. My canadian clients still have to worry about billing but they only have 1 insurance carrier to deal with and they know precisely how much everything will earn them upfront. Everyone else (tourists, out of region people, folks who let their healthcare ID lapse) pays cash at basically the same rates, thank you.

Fun fact, the oldest healthcare products like Meditech started from Billing and grew from there, it shows throughout the software still (and not just because they're written in MUMPS / InterSystems Caché). In Meditech results don't actually need a patient ID to be accepted (via electronic messaging/HL7), they need an account number so they can be billed on the right invoice. Nope the software will not figure out from the Order ID which account it goes to... Downstream systems are expected to keep those account numbers around and up to date, a patient might have 2-4 of them at the same time.


I don't see why any physician implements an EMR. My family doctor, who was part of a midsize practice was punished hard by adopting a system. They did it in 2007 thinking they would save money... which didn't happen as they were only able to eliminate 1/4 clerk positions and had to pick up an IT guy and a consultant. Then they really got the shaft when the solution they chose wasn't meeting Medicare guidelines. They ended up getting another system that is worse.

Now they got swallowed up by a regional medical system and have yet another EMR, plus they have 6 clerical staff versus 3 and whatever outsourcer handles IT for the hospital system.

My other doctor friend is a ophamologist. It's a small practice with 3 full time and 1 part time doctor. They pay the fine every year for not having an EMR and use paper and have a standalone system for sending prescriptions. He is enormously happy with paper and feels that's it better in every way, including cost. I agree -- I see zero value in the EMR systems.


I saw one system that seemed like a must have: apps that ensure you got the prescription right. Paper-loving doctors screwing up prescriptions harms a lot of patients. Especially when they insist on writing in cursive.

Much of your post seems to be about bad tech, though. It could mostly be mitigated with a supplier that gave a shit.


Prescriptions ordered electronically seems to be the only thing that is an improvement.

Everything else is not only bad IT, but ruins your interactions because the medicinal person is bent over a laptop.


Also sounds like a shitty pharmacist and pharmacy tech.


I'm not going that far. What I read implied it was either a mental slip or illegible writing. Some of the drug names look similar when they're written in chicken scratch.


I'm just a patient, but I see the advantage to paper.

1. Once it's on your digital record--it's vunerable to hackers, or staff sending a patient's information off without their consent--with a tired swipe, or send key.

2. Once a doctor knows you have been on a potentially addictive drug, or had a problem in the past with addiction, or theses days; self medication, good luck trying to get relief from future pain.(pain=physical, and emotional.) About a year ago I went to a hospital with a case of shingles that looked twice as bad as those commercials on t.v. The staff looked at my record, and I could tell they were concerned about something. Yes--I'm on a low dose of a benzodiazepine. They didn't even bring up pain medication. I didn't even ask, but the pain was bad. Here's a script for 3 10mgs of predisone. I walked out of the emergency room with a prognosis of Anxiety on that stapled care instructions. I was so misserable, I didn't care. They mixed up my record with the guy next to my bed.

3. A compassionate/caring doctor will sometimes write things on paper they wouldn't on a electronic document. In the ninties, my long retired family doctor asked me if I tested positive for the AID's virus, he would put the results in sub-script writing only he would know. He was protecting me from being denied insurance.

4. I thought electronic medical records would be available for patients online. I don't know if patients can access them, nor care anymore. I'm so tired of the system, I just don't care much anymore.


> ...exception to this is Kaiser Permanente

They are notorious in the medical community for valuing efficiency above all else. Kaiser also doesn't serve extremely difficult cases, uninsured patients or patients on Medicaid. Academic hospitals do.

Kaiser can do a lot of things differently by virtue of being subsidized by the generosity of the state and the state's highly talented doctors. I don't know how much there is to learn from them.

> they make money every time you get sick

Nobody at an academic hospital makes money every time you get sick. Discharging patients is a high priority. Doctors are constantly trying to figure out how to do preventative care with the sorts of "frequent flyer" patients that tie up emergency rooms and hospital beds.

To be more blunt, you're not really describing reality. You're describing a particularly cynical point of view, common among people who are unlucky enough to be (or to know someone) rich, sick and not getting better. It's doctor as antagonist, and it tends to emerge in some kind of economic rationalization.

Here's reality: Mark Zuckerberg put his name on an academic hospital in San Francisco that has utterly dysfunctional EHR. Everyone in the system—especially the doctors, contrary to what you say—hates it and wishes the money would have been spent to improve it.

Even the tech fantasy of magic money wand can't solve this problem. It isn't the fault of doctors ("you know who hates EHRs the most? Doctors"). No clever turn of the phrase or insight is going to provide the answer. Blah-blah-blahing about incentives isn't going to provide any solutions. It's a complex system.

The original poster was saying as much. But then all the other commenters go on and start talking about economics, incentives, anecdotes, and assorted conspiracy theories. The guy is studying this! I think he's coming to the right answers.


I work at an academic hospital, and I've seen how the incentives drive policy. Frankly, it's terrifying.

> Nobody at an academic hospital makes money every time you get sick.

Of course they do! Every time you go in for treatment, they make money, and there only incentives for preventative care come from government/Medicare mandates (e.g. hospital readmissions, ACOs.)

Let me color the picture a bit more vividly. At a public pitch competition within the university, a department head--and judge of the competition--laughed at an ML start up: "you do realize we make money from the procedures you're trying to prevent."

> Discharging patients is a high priority.

Hospitals are often penalized for long stays by insurance.

> Doctors are constantly trying to figure out how to do preventative care with the sorts of "frequent flyer" patients that tie up emergency rooms and hospital beds.

Aside from tying up resources, high-utilizers can't afford to pay for services and the hospitals treat them at a massive loss. Naturally, a hospital would like to free up these resources for patients who can pay.

> It's doctor as antagonist.

I never said this, and nor do I believe this. Doctors are victims of this system. I even made the point that doctors hate the EHR because it's been warped by hospital administrators into a billing-centric machine with umpteen documentation requirements at every turn.

For this reason, many who went into medicine for altruistic reasons end up disenchanted with the health system that's been wrecked by those running the business.


It's no longer necessarily true that providers make money every time you get sick. Insurers have shifted risk to providers in some areas in the form of accountable care organizations (ACOs) which receive a flat fee per patient. So in theory the ACOs have a financial incentive to prevent you from getting sick.

Kaiser Permanente uses the same Epic EMR software as many other large provider organizations.


And I have seen shifts that ACOs have caused first hand! Unfortunately, the only insurer running ACOs is Medicare which is an example of a political solution to the problem. While we have yet to see what the financial implications of ACOs are, I can say that I've seen admins work hard to develop data-oriented preventative care. However, these advances are still only limited to the ACO population, which gets back to my point. Hospitals aren't going to fund patient risk analysis until the economic incentives are in place, and for that reason, I fear that the issue of bad interoperability will exist for as long as we live in a "fee-for-service" world.

As for Kaiser adopting Epic, remember I noted that hospitals can customize the EHR to their needs in detail--it does however require troves of cash. Since Kaiser heavily relies on data-driven preventative care as part of their business model, they pay to have a lot of data systems in place to facilitate their operations. Hell, Kaiser even had an Open API since 2013!![0] Good luck finding that anywhere else!

[0]: http://interchange.kp.org/


In fact they were essentially the first and the reason it has become a near monolopoly


Kaiser was, however, one the first systems to start (2000) and finish (2010) their electronic transition. Their decision had nothing to do with the government mandate in 2009, precisely because their business depended on it.

Also, don't forget that EHRs don't come with a data governance model, so the entire onus of maintaining clean, available, interoperable data falls on the institution. Again, since Kaiser depends on clean, available, interoperable data, they made that a priority both internally and in their contracts with Epic.


There is absolutely an incentive for healthcare systems to do these transformations. But it requires leadership that is willing and able to see the long-term benefits. Of course, that can be challenging, and is probably only feasible in larger nonprofits (for-profits need to please shareholders, and smaller organizations simply can't afford it), but the future payoff is there.

I think we're in the turd-age (opposite of golden age) of EMRs right now. Everyone has adopted them—many unwillingly—but user interfaces are still terrible, and interoperability is spotty at best. There are signs of this changing (lots of vendors are touting/promising UX improvements, and FHIR is hot right now), but it will still take time.


I agree with everything you say besides the claim there is no economic incentive.

Just a few

1) Getting patients to pay their bills.

2) Spending less time on each patient.

3) Reducing errors.

All these have economic incentives. But yes it's still a hard sell.


When patients are treated as consumers we'll see the wave of economic incentives. Value based care as part of the ACA is headed in the right direction.


I can assure you, that no patient is a willing "customer" or "consumer" of healthcare. True 'consumers' or 'customers' have a choice to buy something or not. If you are a sick patient, there is no choice.

As a physician and subspecialist I have invested 24+ years of education to achieve this title. Its degrading to our profession and patients to refer to us doctors as 'providers' and to patients as 'consumers'.

This takeover of healthcare by MBA-speak is one of the most irksome trends, and rebranding patients as "consumers" is a patently false equivalence.


Um, what? I've spent 20 years implementing EHRs. You seem to be implying that hospitals were using paper until 2009. I've implemented lab systems with electronic charts in VMS. The systems weren't, and aren't, interoperable, but they were definitely recognizable as EMRs.


He's probably limiting the definition to the kind of overarching EMR that fully replaces paper charts for all departments and provide a single view of the patients.

I've also done migrations (I'm in radiology systems, PACS and RIS) where clients had reports going back to the early 1980s. Not very common mind you, especially in private practices (which we get a lot of) and rural hospitals (the kind of places with CPSI/Evident or, god forbid, Healthland.)


I strongly suspect that for the US healthcare system setting you are talking about, the incentives are misaligned for building a better EMR/EHR system. What we endure today satisfies those who profit mightily from it just fine, and improvements in health outcomes represent profit erosion, hence no true incentives to truly improve.

Could there be more room for improvements building from the ground up in alternative healthcare environments, like co-ops, hospitals where billing is in cash only and fees for standard procedures posted up-front, concierge, etc.? I don't think the mainstream US healthcare industry will change for the better unless it is presented with an immediate (<6 months), concrete, existential threat to its existence as we know it today. Considering how unfathomably unlikely that is, then substantive improvements in health outcomes could lay only "off the grid" of the current system.

Going down that path is absolutely more risky and less remunerative. Your post gives me the impression that while compensation ranks for you, I'm-On-A-Boat FU money at the expense of poor health outcomes for those you serve might not rank, so I thought I might throw out some outlier ideas and see what discussion falls out of that, if any.

To give an idea of how misaligned the US system is, this blog post [1] from my reading list today came up --- but to pick one at random out of a 3-second Google would be pretty easy --- describes how in the US a $5K MRI tab is not unusual. You can fly to NRT, pay in cash in Japan for an MRI and consult, fly back, about four times for that much. Cray cray.

[1] https://market-ticker.org/akcs-www?post=231917


Just to be clear, I'm actually designing this system with New Zealand in mind, which has a very socialised healthcare system. I've got no idea how to help the american healthcare system


So my startup hosts and supports a decent number of EHR/EMR solutions and I even seriously entered talks at one point for us to partner up with a large medical conglomerate to write a new platform. That idea died for the same two reasons most similar initiatives in healthcare die: Government and Insurance (called "Payers" in the healthcare industry).

You can write the absolute best EMR & PM (Practice Management) platform on the planet but if you can't get the payers to integrate with it you're dead in the water. The only practices who would even consider you without those integrations are ones not currently using an EMR, which means that your first hurdle with them has to be convincing them to go electronic - which means you own all the logistical hurdles associated with a large-scale chart-scanning operation, user training, mindset shifting, and much more.

And don't even get me started on the barriers to entry the Department of Health and Human Services have put in place....


Interesting. I think there's a real argument that an integration platform for healthcare should be a government run entity - ensuring that all parties have a chance.

I'm curious about these barriers you speak of - I'm based in New Zealand, and I must admit I haven't run into many government based barriers to entry - just barriers created by privatized companies.


I work in healthcare. A lot of the complexity is FROM government attempts to help.

Look at HIPAA. Originally about medical record portability, now it largely deals with security, privacy, and availability. These sound good, but it is frustratingly vague, subject to massive reactive fines, and assumes a lot of practices that always feel out of date. It's way more of a pain than private compliance frameworks like PCI.

The problems in US healthcare are complex, entrenched, and Brook no simple fix. The government is incredibly buearacratic, designed by lawyers who value an openness to interpretation by courts that creates ambiguity, and creates solutions in their own mold.


All of the major payers have standard interfaces for submitting electronic claims now. The payers aren't a barrier to launching a new EHR.


There's also some structural reasons. Why is it that larger practices don't write their own software? Well, maybe a few do, but:

a) nearly all states require that ownership in medical practice be restricted to those licensed to practice. This reduces access to capital, and more or less ensures that practices remain small businesses. b) nearly all care in the US is fragmented across specialists in different practices. c) healthcare in the US is largely paid for by parties fairly disinterested in actually transacting. While most folks on HN might A/B test UI improvements looking at click through rates, the implicit idea in insurance billing software is that submitting claims is someone else's expense to deal with.

When you look at places where there is a scale to medical practice, opportunity for software opens up. VA and DoD both operate and staff their own health care facilities, and have software systems they've implemented. But even DoD has problems receiving and retaining records from outside care providers (if Wikipedia is to be believed).

If there were fewer, larger medical practices in the US, it would both be easier to agree on standardized data sharing protocols, and more likely for patients to see multiple doctors working for the same employer, thus never necessitating a data transfer. Admittedly, it'd be harder entrepreneurs like yourself to break in. Perhaps you'd be an employee or Engineering manager working on the problem instead. Or perhaps you'd be selling a plugin to a larger EMR.


In my observation, I've found that there are quite a few larger healthcare providers, and that even the "smaller" hospitals are pretty big in terms of IT needs.

In my hometown alone, there's Kaiser Permanente, Sutter Health, and UC Davis. Sure, none of them are quite nationwide, but they're by no means "small", either.


Part of the challenge is that hospitals represent only one portion of the care chain. My mom's GP, for instance, has never used a hospital as their office. There are dozens of hospitals within 30 minutes driving distance, of which few are owned by the same company / non-profit.

KP is in the vein of what I'm suggesting though, just wish it was more widely available.


The combination of OpenEMR being open source, open community, volunteer driven, physician driven and getting significant use in the real world makes it a perfect vehicle to glean really useful insights into EMR use and I highly recommend looking into it in your research endeavors. For example, in subjects such as EMR system development and the effects of regulation.

A really nice and innovative example on EMR system development is the development of the Eye module released in OpenEMR's most recent version 5.0. A practicing ophthalmologist, Dr. Ray Magauran, decided to develop a ophthalmology module in OpenEMR with the goal of actually improving efficiency over paper (as a physician, I would confidently say I have never used an EMR that is faster than paper). What this physician/developer did was simply amazing and the details of this eye module(including the makings of it) can be found here: http://www.open-emr.org/wiki/index.php/Eye_Exam

What I think is innovative here is that this was designed, built, tested, and used by a practicing physician on the front lines.

Then on the flip side can also learn about the dichotomy of fulfilling regulations versus developing an innovative and efficient EMR system, which OpenEMR provides a ring side seat too since the road to complete meaningful use certification was done the open source way(ie. in full public view).


Your homepage there has a heavy focus on health records. Have you considered building upon the FHIR standard?


Yes, thats the main focus of the project. One of my critiques of healthcare systems is they do wayyy to much. Eg a practice management system (pms), handles appointments, records, invoicing, staff management, inventory, decision support - so much stuff.

I'm instead focusing on just health records - and the interfaces medical professionals use to work with them.

I've had a good look at FHIR and many other standards, but FHIR is built for an interoperability model - eg, your record is sent back and forth between your gp, hospital, specialist, labs, etc. I'm instead focusing on a central access model - so all of the parties interested in your record are all accessing one central point, so I'm doing something a bit different, it almost looks like NPM.

That being said, I'm all for any standard becoming the industry standard - I don't care what it is, anything is better than nothing. So I wish FHIR the best of luck :) http://standardhealthrecord.org/ is also a standard I really like


Most if not all health care systems are implementing FHIR as a layer over HL7. Most of those systems don't have people really conversant with web technologies. Interoperability is, I think, a mirage built on top of already overworked integration staffs.


Have you considered, in your model, how your system would work if a customer wanted to integrate with, as an example, a machine learning platform that attempts to predict the likelihood of a patient's readmission given their current status?


Yeah, I have.

A health record is a collaboration - unlike a medical record, which just shows a slice of your health from the perspective of a single institution, a health record aims to show as many facets as possible. An EHR system should be agnostic about who access the record, and what they use it for - obviously gps, specialists, hosptitals, labs, the patient should all have access - but what about, as your said, software?

The ideal system would be,patient visits your system, goes through an OAuth flow, and your system has api access.

The tricky part is format. Its really hard to define a format which fits the entire world's use case. If you consider, what is healthcare information - you realize it's any data relevant to the patients health. So how can you even start to define that?

My compromise is a system where formats are promoted to become popular, regionally, and condition specific. So if you're building a machine learning readmission software, you can target a specific market - say British Primary care, or a specific condition, say diabetes. You can expand out to other markets by writing transformers to translate from one regional format to another.


So, if I want to run an daily analysis of every record in your system, does that processing happen on your system, or do you somehow replicate the data to me?

I guess my point is... it's likely that you may want a "single source of truth" for the data, but farm out copies for other applications. And once you do that, you probably want some kind of "replication protocol" that sends updates, rather than making a full copy of the data every day.

And once you've done that, aren't you right back where we are today?


It's a self hosted system - so you as an institution have a copy of all of your patients records on your own servers, which you control. So analyse away.

What it provides is a way to replicate some or all of the record to other health institutions. Say, you share the patient's medication list with the hospital - they also keep a copy. When you prescribe a new medicine, the hospital's copy also gets updated.

And yes, arguably this is just another version of interoperability. However, if you want to share healthcare information, in a way which allows institutions to have freedom, it's unavoidable. The concept of interoperability isn't bad, just the implementation is.

The alternative is all patients records are kept, and accessed from the same place. However, this is very tricky. Many governments have tried to make national health record storage systems, which had immense budgets, and didn't really work out. Often with systems controlled by one party, it's hard to work on ideas which don't fit their goals. Say if you have this great idea for a new format to manage diabetes - that wont fit into their standard format, and you'll have to work outside of their system. Not to mention the control over the population this organisation would have.

Patient owned and controled systems are often suggested, and have been built, but I've never seen one work. Patients expect their doctor to manage their record - and they pay for them. It would be a huge challenge to get every patient to pay their yearly 'health record server fees'.

On top of that, heath records also belong to the doctors - legally in NZ they have to keep a copy of your record for 10 years since your last visit. For their own liability they need access.

In my mind only two models can really work - Goverment run systems which are run better than current systems - A better take on the interoperability model


It would be best to have a model where the patient "owns" their own records.


Double bonus for this, we've been working with FHIR at Lumiata and it's quite good for certain things. Difficulty is that most EMRs as is work with tabular databases, and FHIR isn't quite organized that way. It does require some work to translate the tables people usually have into that format.

Still a native FHIR EMR would be really cool!

[EDIT]: https://www.hl7.org/fhir/ for the interested


Lumiata looks super interesting. Ps your https is expired?

As a company trying to use machine learning to predict healthcare risk, what do you look for in a format to work with? How do you deal with incomplete data / incorrectly formatted data?


Above all we want a data format that's consistent.

The nice thing about FHIR is that it quickly allows us to join up all the data for a single patient, and all the pieces of data we need are always in the same, standards-compliant place. It also does a good job of defining what datatype to expect when you access a part of the patient record (low bar, but yeah, medical data :( ).

The bad part about FHIR is that it's so heavily nested and flexible that it can get annoying to extract some of the data. For example, the date that something happened is accessible by a different key or keys based on the type of event that happened. Same with trying to access what doctor was responsible for that event. That's meaningful medically, and one-size-fits-all in these things is hard, but I have to jump through all sorts of hoops to get to it and write lots of "if this then that" code to get the same information. There are also some odd omissions. For example ethnicity isn't super consistently represented.

For incomplete data, we deal with very large numbers of patients so some of that washes out in the aggregate as we build models. If the data for a given patient is truly incomplete, we then simply don't use that patient. We do a few other things, but can't go into much detail here ;).

Incorrectly formatted data drives me nuts. It's super manual. We pass things through a series of filters and reshaping that helps cut down on the problem, but it sucks. A lot. Not much to do but try to figure out rules for common data entry or format screwups.

re. HTTPS, yeah it's screwed up in a couple ways but we're getting it fixed. The public website has nothing to do with how we secure/transfer/handle client data though.

If you've got more questions, I'd be happy to email, feel free to reach out at ntilmans@lumiata.com


At MedicaSoft, we are building a native FHIR EMR and PHR. See medicasoft.us.


EHR is not difficult. There's a lot to the required data model, but building a working system doesn't require mental gymnastics, just time and effort.

Selling isn't particularly challenging either. There is a tried and true model for selling to medical practices and hospitals that works. Customer acquisition is expensive and resource intensive, but it's doable with the right team and right investment for any product.

There is risk, but HIPAA is a lot more of a risk than a logical failure. With every HIPAA violation, there are fingers pointing in every direction, and that means that resources are required to respond to everything - even when it's painfully obvious the software isn't at fault.

I would say that the biggest challenge to creating a market for a new EHR product is that there are generations of people resistant to any real user interface changes. I'm not even talking about adding tabs or checkboxes. If an EHR product logically maps to one of the legacy powerhouses like EPIC, it makes sense to people. If it logically maps to health care instead - No dice. People are entrenched in a system that was designed by engineers for health care because that's all that was available for a generation. They've gone to classes to learn how to work in that environment, they've worked in it for years, and it works for them. A major shift of any sort means retraining doctors, nurses, call center operators... anyone and everyone up and down the food chain. Even in a small practice that's a lot of time and energy to invest. There is resistance every step of the way.


The primary reason why healthcare is hard is legal and politics more than anything else.

I think a lot could be solved if someone decided to build the healthcare version of Zapier.


The EMR market is consolidating on two big vendors: Epic and Cerner. Depending on how you measure it (Hospitals on a system or Medical Records under management), either Cerner or Epic is #1 and the other is #2.

At this point, in the U.S., it is almost impossible for a newcomer to break into the market. There are many companies out there slowly losing market share to Epic or Cerner. Allscripts, Nextgen, McKesson/HBOC, GE, and others. Some are big, well-funded companies, others are more like startups with OK funding. Most of them are falling by the wayside, casualties to the bitter Epic/Cerner market war.

The HITECH act really exacerbated this point by accelerating spending on EMR's since 2008. Meaningful Use meant that a lot of homegrown systems had to be replaced, simply because hospitals couldn't keep up with the regulation and complaince. Likewise, smaller companies had to spend more money on compliance than adding features and also faded. Sure, there are plenty of Allscripts and HBOC customers out there, but their number is shrinking, not growing.

In a way it's a shame, because the two biggest vendors each have critical flaws. Cerner has a decent store in Oracle, but is hobbled by reliance on its own homegrown language for integration and middleware. The language is CCL and is like a cross between PL/SQL and TCL with HL7 Domain knowledge thrown in. Epic has an ancient store with Caché, which is really MUMPS with some OO and relational hooks tossed in. Cerner excels at customization, while Epic excels at disciplined project implementation. You can browbeat Cerner into giving you what you want, but you can implement Epic pretty much close to on time and close to budget with an impressive reliability.

Neither system really wants to interoperate with the other. It can be done, but it takes a months-long project with specialists writing HL7 interfaces to pass demographic, lab, and document data between each system. And this interoperability, once established, doesn't really help the patient. Docs can see orders entered in Cerner Powerchart displayed in Epic Hyperspace, but the patient doesn't necessarily get access to either the order or the result unless it goes to either system's portal.

Finally, you have to realize that you are dealing with a very powerful and conservative management culture. Many Silicon Valley startups with whizbang solutions have foundered when they run up against the entrenched incumbents. Well-funded companies with highly competent engineers have failed because they don't have the patience to spend a couple of decades building up a user base. Investors realize that they can get more bang for their buck elsewhere and leave the game. If you even want to make a dent, you have to be willing to spend at least 15 years and untold amounts of money just trying to take on the big guys. If you're going against a market with relatively short turnarounds, like a calendaring app or even a game console, you have a shot. If you're going against a market that is very conservative and waits at least a decade before reevaluating installed systems, you have a very tough row to hoe.

Ultimately, at least in the U.S., I think that implementing a new EMR is a sucker's game. You can spend millions and lose.

In New Zealand, the market is different at this point, but how long can they resist the network effects of the big vendors? Cerner and Epic are currently battling it out in Australia, and will exert pressure in NZ once that market is settled. I know for a fact that Cerner went after NZ in the late 90's but pulled back after it became clear that entrenched corruption in the NZ procurement system would determine the winner. I don't have names and places for you, but I was in Sydney at the time and remember the disappointment of the executive team when they realized that NZ at that point was not a genuinely open market.

You have mentioned in another post that you are concentrating just on records, and avoiding the extra complexity of the other systems in terms of patient management, practice management, supply management, etc… With all due respect, I think you are being naïve. A modern EMR system has to take into account the entire needs of the practice and how to manage it. When a health care practice is spending a buck, they want to get as much out of that dollar as possible. If vendor A is offering "just records", but vendor B is offering records plus practice management, they will go with vendor B. Every time.

In any case, I wish you the best of luck. I have a lot of experience in this sector and would be happy to share my knowledge with you.


> In New Zealand, the market is different at this point, but how long can they resist the network effects of the big vendors?

Good point, here all hospitals use software from Orion Health, which is an NZ company - They have a really good hold on the market and I don't see that changing.

> You have mentioned in another post that you are concentrating just on records, … With all due respect, I think you are being naïve.

That thought has definitely crossed my mind. It's a tricky puzzle - part of the reason I think healthcare software is so hard, is that current systems are so monolithic - they do it all. To compete, you need to do it all as well. This impedes improvement, if you know how to build a fantastic appointment system, why should you have to also build invoicing systems? You have to bite off more than you can chew.

I don't really have an answer to this problem, but my approach is to break up the problem as much as possible into smaller parts.


It's kind of funny cause I'm in the imaging side and there's a buzz now about "deconstructed PACS" where centers will mix and match different vendors to provide radiologist workflow, image storage, DMWL worklist, Diagnostics Viewer, VR, distribution and analytics.

Right now, that's quite niche and arguably the DICOM space is the most open part of Health IT, but perhaps that will eventually percolate up to EMRs. Maybe once FHIR catches on or whatever will replace FHIR. I'm frankly still using HL7 2.x and mostly 2.2/2.3 level features.


> Finally, you have to realize that you are dealing with a very powerful and conservative management culture.

Has anybody tried to address the patient needs before?

Patients should be easier to convince. It could be a good strategy to influence the doctors and mangement to change their habits.

I'm thinking of a tool to allow the patient to enter data that they could give to their doctor.


It wouldn't help. Very few patients actually care about this stuff. When patients go in to see their doctors they aren't going to waste time discussing software.


lots of people are working on the patient-centric record. No one has cracked the cultural problem and the integration problems. You would be requiring docs to re-enter most of the information in their own system.

Remember, the things we call EMR aren't primarily medical records, they are systems for sending the right codes to the billing systems


> You would be requiring docs to re-enter most of the information in their own system.

Why not gave-up at the beginning with data exchange. Make something that could help both the patients and the physicians.

For example, a mobile app could gather some data concerning the patient habits (with the gps, accelerometer...).

The idea is to create a need and make it mandatory (because very useful).

> Remember, the things we call EMR aren't primarily medical records, they are systems for sending the right codes to the billing systems

Yes. I'm looking for a way to change that. For example, with something more health-centric than money-centric.


looks good, how far are you with it? is it open source?


It's essentially a giant design proposal - yes it's all open source, but theres nothing you can download and start using - yet :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: