Hacker News Reader

Comment by leak | Hacker News Reader

Healthcare is less about these cool technologies and more about how do they devices and software interfaces get access to the patient data. I worked at a startup that launched a tablet application back in 2005 for healthcare professionals to interface with patient records while walking around the hospital. Building the software was and still is the "easy" part.

Getting IT to give you access to patient data is the extremely difficult part. It takes literally years. Lots of proprietary stuff that is very hard to get into. Maybe Drchrono is tackling small doctors offices and it might be easier but trying to get into major hospitals is another story.

I wish them luck either way.

View on HN

We are going to change healthcare from the ground-up. Small 1-10 doctor practices can easily make the decision to completely move to a new solution like drchrono. Once you get every private practice doctor using better tools, you can start banging on the gates of the hospitals to let you in and adopt new technology.

It's similar to how Salesforce.com started with small businesses and eventually broke into enterprise sales from the bottom up.

I hope this works.

As a lot of other posters have noted - hospital level deployments, where good data practices and IT are arguably the most needed due to the mission critical nature and the larger volumes of data generated, is hobbled by entrenched interests, IT policy dominated by insurance revenue concerns rather than driven by patient or practitioner needs, and being swallowed up by a oligopoly (soon to be monopoly) consisting of Cerner, McKesson and Epic.

All of these companies use antiquated databases (MUMPS forms the basis of the products of these companies for the most part, a data language invented in the basement of Massachusetts General that predates FORTRAN and COBOL). The UI/UX design is nonexistent (all of them would crush any of the Daring Fireball interfaces of shame posts).

More ominously - these companies protect their business AND their data formats ferociously. Epic is famous for lock ins - once you pay the $50-100 million contract for them to take over your IT, your data will not interface with any other system again, ever. They are good at generating numbers for Medicare and insurance billing revenue that make hospital CEO's giggle with glee (ignoring user experience and good data practices for the doctors, nurses, and patients on the line - which translates into lousy care administered to patients). Judy Faulkner, the CEO of Epic, is known for having much of the Wisconsin Congressional delegation in that company's back pocket, such that she sits on some congressionally mandated committee for EHR's promoting closed, proprietary systems as a means for "patient privacy" (lolwut).

The system I work in actually has a reasonable setup. Not nearly as sexy as some of the advanced hadoop/linkedin/facebook/netflix setups - it was build on an Oracle back end running MS IIS and ASP. But at least it's on the web and the database isn't creaking along on a system that looks like this: http://thedailywtf.com/comments/A_Case_of_the_MUMPS.aspx?pg=...

Yet swayed by whatever koolaid Epic fed them, they forked over the millions in contract to go 40 years back in time.

I think this industry is so so so ripe for disruption. Focus on the doctor/nurse/patient user experience, make EHR software that does what every facebook/google+/linkedin, heck even blogger user takes for granted, get the adoption rates up, and kill these greedy as sons of bitches at their own game.

> Focus on the doctor/nurse/patient user experience, make EHR software that does what every facebook/google+/linkedin, heck even blogger user takes for granted, get the adoption rates up, and kill these greedy as sons of bitches at their own game.

I agree 100% in principle, but I think that in reality this won't work. Why? Because the people that would benefit from that approach (focusing on the user experience, etc.) are not the people that make the decisions about which system to buy. Those people could care less about what it looks like, or how usable it is.

That's the reason why so many EHRs have UIs that look like they belong up on blocks in somebody's front yard, and even worse-looking APIs- a misalignment of interests between the users of the system and the people who make the purchasing decisions.

It's like a little microcosm of everything that's wrong with the entire medical system... :-)

Not always true; for any project we do which would impact patient care there is always at least a physician involved, sometimes a nurse as well. The reason our Epic UI looks they way it does is because clinicians want it that way.

We have tried to streamline the interface, but they don't want IT telling them what is important to put on the screen. During our last upgrade we had issues because some physicians put so much on the screen that caused a problem with the program; Epic implemented a fix for us, but the physician took something we showed them and ran with it. Then they started telling others who did the same.

The end result was like the image people like to link to whenever this topic comes up; a screen full of check boxes and sliders. They like this because all of the information they want is on one screen and they can quickly go down the screen making selections. When we tried to streamline this they didn't like that there would be multiple screens to load and then they wouldn't have one way to see everything selected without a summary page which was yet another screen.

I work in IT security and user experience is one of the key things we focus on; a system that is confusing or difficult to use will be used in ways we do not expect. Making the most obvious choice the right choice reduces risk, confusion and helps ensure people do the right thing.

Epic is famous for lock ins - once you pay the $50-100 million contract for them to take over your IT, your data will not interface with any other system again, ever.

I'm not too familiar with MUMPS but is there anyway the hospital's IT Dept. could allow a 3rd Party App to integrate to the actual MUMPS database/data source to get to the data, and thus bypass trying to get access to the EPIC/Cerner API or HL7?

> We are going to change healthcare from the ground-up

This is so impossible!

You have a great product for 1-10 general doctor practices. You should focus on that and just that. If you feel like you have a lot of free time on your hands try knocking on 1-5 pain management doctors clinic. See how you do there. If you manage to customize their workflows and menus for pain management, move to 1-5 MDs obesity clinics, and so on. I suspect that after single pain management clinic you get burned out.

Have you ever looked at UMLS http://www.nlm.nih.gov/research/umls/ ? It has 2,612,024 mln medical concepts and counting. Many diseases are still poorly covered. Any time you talk with a specialist in a hospital he/she will need those terms in their documentation. Every disease has different workflow and different vocabulary. If a hospital thinks about adopting a new EMR, they will send ~100 their own IT people to EPIC/GE HQ to have them trained how to configure their system. Then, those ~100 IT people will work with ~1000 MD to have progress notes, flowsheets, and what have you configured to everyones liking. This is SO MUCH work and huge investment that has to have 0.0001% risk for the hospital and for the patients. Keep in mind that if patient dies and there are lacks in documentations someone will have to pay ... a lot.

I'm sure that some day you will have ~1k engineers and ~2k support team, each encumbered with basic medical knowledge and patient workflows. But then you will notice that healthcare can be changed only top-down not ground-up.

> This is so impossible!

This is exactly why I feel we need more such start-ups in this space - Naive but Bold that have a "Stay hungry Stay foolish" mentality.

Having said that, I pretty much agree with all what you said. The core problem is that few years working in health IT, most people (myself included) start thinking this way. And thats why I feel we need such bold visions, which may sound stupid or "impossible" at this point but can potentially change the status quo. Its very hard to predict when, how and who will bring the change but I know it ll happen, sooner or later.

PS: I disagree about the UMLS part - I don't think any company in their right mind would use Metathesaurus as their base vocabulary, may be synonyms, mappings etc but not as a coding vocabulary.

> The core problem is that few years working in health IT, most people (myself included) start thinking this way.

You hit the nail on the head, here. There's a fine line between "bold, fearless, and usefully foolish" and "too ignorant of an extremely complicated domain to accomplish anything useful", and in medical informatics that line is even finer than in many other fields.

> I don't think any company in their right mind would use Metathesaurus as their base vocabulary, may be synonyms, mappings etc but not as a coding vocabulary.

Just to chime in (in case anybody reading this comment thread is thinking about getting into this stuff), you're 100% correct: the UMLS is in no way supposed to be used as a coding vocabulary. If you try and use it as such, you're Doing It Wrong(tm). That's what clinical terminologies e.g. SNOMED-CT are for.

Of course, that doesn't mean that plenty of people haven't tried- it's just such a tempting-looking resource...

That said, I certainly wouldn't want to dissuade anybody from learning how to use the UMLS, or from using it for its intended purposes. It's a really valuable (and easily accessible) vocabulary resource.

Yes, UMLS is indeed a great resource! I do think one could use UMLS as a core vocabulary but with specific application context. At my company, we use it for information retrieval of clinical trials. NIH itself uses it in several of their services (MedlinePlus, ClinicalTrials.gov, etc)

In the context of EHR data-entry/documentation, using UMLS would not make sense just because of the inherent noisiness/granularity differences that come about due to the integrated view of the world. With terminologies like SNOMED-CT, you run into coverage issues and end up pre/post coordinating lot of knowledge.

Good point; I've used it as language resource for IR applications many times. What sort of clinical trial IR are you guys doing- storing and retrieving trial protocols themselves? Or is it about managing ongoing trials? Or something else entirely?

> With terminologies like SNOMED-CT, you run into coverage issues and end up pre/post coordinating lot of knowledge.

Well, yes, SNOMED is a post-coordinated vocabulary, so that's sort of the point- it's a feature, not a bug. Of course, there are so many ways to do post-coordination that you can easily end up in trouble when you try to exchange data with somebody else...

The problem is Epic has effectively locked-in the top end of the market. Their strategy, which is brilliant, is to only go after the biggest, most well-known clients (I know nothing groundbreaking, but it works). They say they only focus on whales, academics, and children (hospitals). Due to this, they have been able to capture 265 of the most prestigious hospitals in the country (and soon in the world). With the lock-in they have, I can't see them giving up this market. It would take a lot to justify replacing that half a billion dollar system for someone else, especially after the hell the administrators have gone through to get the systems up in the first place. Also, in many ways Epic is becoming the de-facto standard, which is leading to network effects that would have to be broken down. I don't think you can fight Epic at their game and win.

Added to that they will likely begin to move downstream (recently heard a rev. projection $8.4B in 2016, up from $1.2B today) as the mid-size players would love to have an Epic install if only to mimic the respected healthcare organizations.

The most secure place from Epic is the small practices. The IT/intemplmentation/costs requirements of Epic are far too high, in its current form, to sell to them. The problem becomes selling. It recently talked with a VP of Sales at a HIT vendor and he said of 10 hours spent selling a doctor, 9 hours are spent trying to get a hold of him. Difficult.

That's the exact way the market looked to Salesforce.com when Seibel system only went after large markets and told their salesforce to "run" not "walk" away from smaller customers. Salesforce.com definitely killed Seibel in the enterprise space after building a better product with feedback from smaller sales forces.

My understanding of Epic's approach, to some extent, is that they know approximately how much it will cost to support an organization. When we were going live they had reservations due to our size at the time; if we were not big enough they did not want us as a client since the cost of support would be greater than what we honestly afford.

I really like how they have structured the support concerning Forums, UGM and Good Maintenance; for an enterprise software company it is the best approach I've seen.

>"It's similar to how Salesforce.com started with small businesses and eventually broke into enterprise sales from the bottom up."

No it's not.

Missteps with something like Salesforce might cost people jobs.

When a hospital makes a misstep, people might die as a result.

A hospital's operations are no more a scaled up version of a small group practice, than its physical plant is a scaled up version of a bungalow.

I don't agree.

A little background:

I am a hospital systems designer and consultant. I actually built one of the first EHR clients for iPhone, before the iPad came out (Rejected from YC in 2009), I was the technology implementation manager for the new El Camino Hospital build, I was the primary technology designer for San Francisco General's new 850MM facility. I am consulting on the UCSF Mission Bay project for technology and transition, and the same for UTSW in Dallas. I am also the transition planner for a small 100MM facility in Nome Alaska.

In all of these projects I design and or consult on all aspects of technology implementation, use, training etc..

I even sent an RFP for EHR implementation to Dr. Chrono to see if you guys could step up to a larger facility ($5MM budget for that piece), I heard nothing back for weeks until after the deadline when I was then told that you couldn't respond - and then had a sales guy call me trying to get me to sign up as a physician.

Anyway -- getting a private practice of ~10 physicians to use your product is in no way a gateway to hospitals. They are completely different markets.

The EMR implementations in large hospitals are multi-million dollar implementations and they take ~18 months to accomplish.

The sheer number of workflows needed and the integrations with various systems are daunting and non-trivial.

You are going after a massively entrenched market with many many millions of dollars committed by all the customers

I fully hope that there can be a serious shakeup in health IT, but having some success with 1-10 physicians and then expecting to parlay that to hospitals with thousands of employees, or even hundreds (like in Nome) is a tall tale.

I think there are TONS of opportunity to disrupt healthcare, and DrChrono is a great app - it is just not mature enough or on scale enough to compete against the larger EHR market YET.

EDIT:

I'd like to add - that if you want to continue to build a free product, and you want to get into the larger scale EHR space - I suggest you partner with/learn from/attempt to implement on-top-of MedSphere's OpenVista EHR.

DrChrono has some great features - and if you make the capabilities more robust then you can get into this market more easily.

OpenVista is used widely outside the US as well, and this would be an opportunity to capture the Asian/Indian market.

Also, if you take some of the features you have (Voice Notes, etc) and offer them as a stand-alone-ish product - then you can attempt to get physicians already in large hospitals to use that product - not selling it as an EHR, but a needed tool, and expand from there.

If you stay away from the EHR/EMR moniker when infiltrating physicians in larger hospitals you'll more easily get under ITs radar.

Every hospital has iPad users already, and most are rolling out official IT support for them - so you need to get an app that physicians can use in parallel to their epic/siemens/cerner/eclypsis solution without pissing IT off.

>"The EMR implementations in large hospitals are multi-million dollar implementations and they take ~18 months to accomplish"

This is approximately one and a half revisions to Apple's product line and developer agreements, and this creates serious uncertainty for a large organization on the scale of a US hospital which needs needs to plan changes to its operations well in advance.

Unfortunately, Apple does not provide a technology roadmap around which organizations can make the sort of serious decisions that affect health, safety, and welfare.

Exactly. The iPad can only be an access device for an EHR - it cant be the core of the product.

Respectfully, I disagree with your assessment of their business. Anybody who has ever worked for an enterprise startup knows that requests for custom installations and implementations of your product are a dime a dozen. No startup will ever win a RFP from a big company and it's just a time waster. I would say not only is drchrono taking the right path, it's the only possible path to getting into the larger hospitals. Once they've refined their product and built up a name for themselves, they only need to win that one bigger contract and they are off to the races. But what you are suggesting is simply impossible for a startup. And you should have known better than to contact drchrono for your large hospital, that's just irresponsible. If you didn't believe in their product then you were knowingly wasting their time.

I in no way thought Dr Chrono could respond to the RFP - that wasn't why I sent it to them - and I was very clear about why I was sending it to them and told them so. I said that I wanted to give them the RFP to see what they COULD cover within the requirements, that I was interested in seeing where they were in their capability and what market they were going with. I spoke to them on the phone as well and explained this.

I was sharing the RFP with them so they could see what an organization of that size specifically needed.

After this - they just took a few weeks and said "Nope we cant do that" but offered no analysis of their capabilities, which is fine. However it showed me that they were young and immature as a company when I then received several calls from their sales team trying to get me to sign up for the service as a physician.

I DO believe in their product, however in each of my exposures to them I see them faltering and operating a little blindly.

I want them to succeed - but it is plain foolish to say that getting a 1 - 10 physician private practice is the gateway to knocking on the door of a large hospital.

Those are totally different markets.

I followed up and said that they should seek out offering a tool to hospital physicians not under the premise of being an EMR - get the tool into the facility and let the physicians champion your product that way.

Epic, Cerner and Eclypsis are very very territorial and are not very open to working with scrappy startups like DrChrono... so they need to take a strategic approach.

Further, hospitals spend million upon millions on these systems. Saying that a free app with 44K in meaningful use funds support is going to really compete on the same level is just false.

I would do anything I can to help further their efforts - but lets deal with reality as well.

> I see them faltering and operating a little blindly.

What are they doing "blindly"? Can you offer specfics?

> I want them to succeed - but it is plain foolish to say that getting a 1 - 10 physician private practice is the gateway to knocking on the door of a large hospital.

I don't think they ever wanted to knock on the door of a large hospital. Why do you insist that they must find a way to do this? More importantly, why so immediately? Of course they know they can't compete with Epic, Cerner, etc. So they're not even trying.

It's quite possible that enough small practices adopt a system for it to be hard for big hospitals NOT to notice. Then hospitals will be knocking on their door. Many many markets have been disrupted this way, where the big players don't take small ones seriously until it's too late.

Read the comments from Skeletor in this thread, who works for DrCrono and made these claims.

I'm just speculating here, but another option is that one of the entrenched players with millions committed notices the success of Dr Chrono with smaller clinics and decides to acquires them to get a leg up on the competition.

Yeah, that's pretty much the way I see their future as well.

"Me too" reply concurring with your business analysis.

Politely, respectfully disagree with recommendation for OpenVista. Of all the tech stacks I've worked with, only InterSystem's Cache (also popular for healthcare IT) is worse.

I will not say their tech is great - but they are an open and hungry company that does like to make partnerships, work with startups and they do have larger deployments outside the US.

EPIC, Cerner etc are all going to stonewall against DrChrono.

At a minimum - they should look at the robustness of the system. While the implementation may suck, the fact is that openvista has a hell of a lot of thought hours into it given it is based on vista.

Hopefully someone at DrChrono REALLY knows what is needed in an EHR.

Hell - they should be actively trying to poach employees from the big guys, as well as going after med CIOs (except for some who are all ego, but I can't call them out here).

Good luck with that.

Reply on news.ycombinator.com