back

by rdl·16y ago·view on hn ↗
I agree -- and it's amazing how bad the existing software is. (I work in this field).

It would be a great place to do a startup (there are a bunch of niches which could easily support multiple companies) -- it's mainly implementing open but antiquated specs from the late 1980s, doing interop testing with existing vendors, and being able to go through the long sales cycle. You would want some MDs on the team, which makes it kind of expensive (young MDs need to pay off their schooling, and older ones would be giving up profitable jobs).

The $40-80k per EHR thing is a big market opportunity.

2 comments
Antiquated? but HL7 is XML!!! ;) The barriers to entry are pretty high just to have a baseline solution, and then you have to figure out how to reach the few people that have decision making authority to implement this kind of system. A lot of interesting things were discussed at HIMSS, very exciting things are happening in this space.
In particular, anyone who wants to sell a complete EHR product will generally need CCHIT certification. That isn't easy or cheap even if you have smart developers and good tools. http://www.cchit.org/certify/2011/cchit-certified-2011-ambul...
Hopefully this is not the case. With the interim final rule all but ignoring CCHIT (http://edocket.access.gpo.gov/2010/E9-31216.htm) there is hope that somebody comes up with a real certification rather than a list of functional requirements for EHRs.
The regulation can't specifically delegate certification authority to a single private organization, but it is highly likely that CCHIT will end up being one of the certifying bodies. HHS may include other organizations as certifying bodies but I don't think anyone has really stepped forward yet with a complete proposal.
I heard this was about $500k in additional cost and maybe +6mo, starting from a reasonable technical basis, which doesn't seem that bad.

There's also the "sell it outside the USA, then sell inside the USA" model.

I don't think this is true. The initial certification is ~$28k and the auditors just watch you demonstrate the list of criteria. Sure, there are interoperability requirements (and other requirements such as drug interactions) that may take some time to implement, but all of these requirements are simply features that many of your competitors have anyway.
I work with DICOM more than HL7. DICOM is very frustrating, especially because the task it tries to solve could be so easily done. I think DICOM-related products (an open stack for equipment vendors, various PACS and other tools, etc.) would be easy projects to get to baseline.
The problem the startup will face is finding programmers who would put up with all the irrationality in the medical field. The reason the software is so bad is because the field is dominated by business types who can push papers through until their software is approved or bought, but can't find good programmers to make good software.

There are a lot of legal issues too, so the risk can actually take you negative very easily -- like jail time or fines, so it's a different equation for investors, entrepreneurs and programmers.

That "irrationality" is fundamental to many types of enterprise software, which is a big reason why most of it sucks. You're codifying hundreds of years of established precedent, often heavily legally regulated in slightly different ways by all 50 states (not to mention foreign countries). The more established precedent there is, the more history in the industry, and the more regulation, the harder it is to write decent software.
That is more true for EHR than for a lot of the more specialized systems in radiology, pharmacy, lab, etc. For those, it's much more clearly a CS problem, with a UI component, and then some interaction with existing crappy systems (mainly the EHR).

The EHR itself is the black hole of suck. It almost always ends up being like an ERP package, with either an off the shelf package (e.g. SAP) where the workflow is changed to accomodate the package, or a semi-custom consulting product built around specific workflow.

Luckily, the more specialized stuff is actually vastly simpler.

Sounds about right . . . any time you're solving a particular problem, things get a lot simpler. You need something to do x and y, so you make something do x and y, and it's pretty easy to tell whether what you've made sucks and x and y or not.

Once you have to handle anything workflow-ish or manage any sort of business process, or any time you have to handle integration to arbitrary external systems, it's very difficult to make anything that doesn't suck. The "right" thing becomes very fuzzy, and there's no one purpose or problem you can use as your rightness criterion, so it all becomes very fuzzy. Things then get worse when some standards committee tries to please everyone, or when business users insist that they want everything to work exactly the way it used to just, you know, with a computer know. And since there's no easy criterion against which to judge the solution, it's an easy slope down towards even more suck.

The technical issues are challenging, but the problem space is intrinsically motivating if you "believe in" the space. EHR is one of those rare opportunities where you can "do good" and be rewarded for it. Further, there is a HUGE amount of bizdev that goes into partner integrations, and you basically can't meet "meaningful use" (a requirement for ARRA money) going it alone. HIPAA compliance, security review, and on and on. Learning about the way healthcare really works in this country has been incredibly eye-opening.

Thankfully, I work with really smart people who are all motivated and our company has a few unique strategic advantages. If any great rubyists want to join a company that is iterating our test-driven way to launch, my contact info is in my profile.

Yeah, it is nice to be able to work on something where you can be at a party and someone mentions a motorcycle accident or something, and you can point out how the product you work on was involved in saving his life. More meaningful than yet another social network game.