| I used to work at Epic as a software developer. My take on it is that the key explanation for why medical software is so bad is that it is so hard to even attempt to compete with established EMR's. I could go on at length about this but I'll try to keep it short. Basically, imagine that you're a startup and you want to compete with Epic in providing a comprehensive IT solution to health systems. You will _at least_ need to: 1. Write software for every major medical specialty that is comprehensive enough to satisfy the specialists' expectations of domain-specific tailoring 2. Also ensure that these modules are flexible to accommodate intra-specialty variation (for example, oncologists vary a lot in how they divide stages of cancer) 3. Ensure that your software will comply with and help your customers perform well financially with federal, state, local, and program-specific (Medicaid, Medicare...) regulations 4. Go into a room full of health executives who are deeply weary and suspicious of health IT people (for better and worse reasons) and convince them they're better off risking a multi-year, extremely expensive transition project on your startup, which might not be around in a few years, instead of going to an EMR vendor that's almost-not-even-mediocre but stable like Cerner or Epic. (The "nobody gets fired for buying IBM" effect here is real.) Clearly all of this requires a lot of work, and would require millions of dollars in funding and the poaching of some top talent in healthcare IT who know the lay of the regulatory land. As a result, most HIT startups (that I know of, at least) target something less ambitious than an enterprise EMR. Some target only a specific specialty (like home health or care management), others target small family practices (which are becoming increasingly rare as they are bought out by major health systems). This is in a way bad for everyone except the software vendors, though, because without a competitive threat, there is little incentive for companies like Epic to undertake the risky, major rewrites which are vital for the company's long-term technical health. Epic still uses a typeless, (almost) data structure-less language called MUMPS for its server and DB code, and on the client side, all of it is still either in VB6 (yes, 6, not .NET) or a quite spartan home-grown JavaScript framework. The result is that bad code never gets totally thrown out, and Epic's developers are not able to benefit from the productivity-multiply amenities of modern languages, which include type systems and abstractions more powerful than subroutines and goto statements. Development then takes an order of magnitude longer than it might have, and the feedback cycle continues. |