Well, it’s time to start designing new clinical care systems. MU is winding down, so the yearly certification requirements churn will be ending soon, or at least slowing greatly, which is a good thing for someone jumping into the market. Current vendors have to support users who do continue in MU because, no matter how few users continue, no vendor wants to have a product decertified. In for a penny, in for a pound… Let’s not forget ICD-10. That transition should cause headaches for at least a few months. Every current vendor is bound to MU and ICD-10, and those with mature products have systems that originated when LAN-based client/server was king. As a group, EHR vendors are protected among themselves by a common set of circumstances. However, they are vulnerable to products that play by different rules—those currently in the design stage.
Here a is list of what we have learned in the six years since HITECH took effect:
- Interoperability still doesn’t work quite right.
- Care coordination is a real thing, and EHR systems don’t do it well.
- Disease registries and chronic disease management are important for care quality.
- Small practices need good products that are inexpensive, easy to implement, learn, and update.
- HIT with safety issues can lead to poor care and malpractice suits.
- Clinician productivity should go up, not down, when HIT is introduced.
- Workflow is important for EVERYTHING.
- 64-bit mobile systems are powerful enough to run real software.
- The cloud is a reliable infrastructure component.
How many items in this list would have been considered important when designing an EHR in 10 years ago? Market leaders, both inpatient and outpatient, had products on the market when HITECH went into effect in 2009. If we assume it takes a minimum of three to four years from concept to product to create a viable EHR, then many current EHR systems date back to at least 2005. A lot has happened since then, so these systems have to play technological “catch-up.” But MU and ICD-10 are putting the serious kibosh on that…
The fastest way for vendors to meet rapid market changes, aside from in-house development, is buying up new, specialized products and stapling them together, Frankenstein-like, to make them appear to be a well-thought out product family. The problem is the stitches always show. There is always that unsightly electrode…
New vendors entering the market today do not have to deal with an old code bases. They are not tied to LAN-based systems with UIs optimized for mouse clicks and implicit workflows. New entrants are free to imagine systems based on today’s technology.
Market share is the boogeyman usually invoked to scare off new companies in any domain. Incentives resulted in significant uptake of EHR systems, so the conventional wisdom dictates that there is no room for a new kid. Somehow, everyone forgets that few products have had the luxury of launching on a blue ocean. Almost all products are released into existing markets. Capitalization and utility are more important for new products than what already exists in the marketplace. New clinical care software companies MUST offer products that are substantially better than current systems. Once a great product exists, the next big problem is having the money required market it properly while riding out lean times.
Ask any group of clinicians about how they like their EHRs and one will find seemingly conflicting replies. On one hand, most will complain about mouse clicks, screens, data sharing, and implementation headaches. If asked whether they would go back to paper, the answer is usually, “No.” Clinicians see the value in electronic systems; they simply want systems that make their lives better. There is a market for clinical care systems that make clinical work more productive, that are easier to extend, and that address emerging needs such as population health and care coordination. Practices are willing to switch to demonstrably better products.
Practices of five or fewer clinicians have not adopted EHRs in the same proportion as larger ones. According to Black Book Rankings, 79% of these smaller practices have not implemented systems. Smaller practices, and larger ones looking for better systems, provide the needed entry point for new, innovative products.
Software design is a trial-and-error process. There is usually more than one way to implement a feature or meet a requirement. As a result, the best development strategy is to build products that are easy to change (loosely-coupled, highly-cohesive) while allowing users access to products from the very earliest stages (user-centered design). A new vendor with proper capitalization AND a great product (this includes great service) could break into the ambulatory market.
Imagine how word-of-mouth would sell a product if primary care clinicians were saying that implementing it took only a couple of weeks, it adjusts easily to new workflow needs, and on top of it all, they are more productive.
The fuel for innovation in ambulatory systems also arises from changes in health care. Chronic diseases account for a large portion of care expenditures. Care delivery for chronic diseases could benefit greatly from HIT that supports care coordination, disease registries, medical homes, etc. Experience has proven that electronic charts alone are not up to the task of meeting these needs. That is, the metaphor of a patient data repository is not the best design guidance when communication, collaboration, data exchange, decision support, and adaptable workflows are fundamental requirements.
The goals for chronic disease management: prevention, early diagnosis, and slowing/stopping progression all assume hospitalization to be a sign of failure. Payments for quality are increasing, and systems must help providers deliver better care more efficiently in outpatient settings.
For the last few months, I have been using Swift, Apple’s new programming language, to build a clinical app aimed at primary care docs who do NOT have EHR systems. It is an update of something I built back in the 1990s for my personal use. So far, the experience has been amazing. The number of widgets and doodads in Apple’s development toolbox is mind-boggling! Even better, two weeks ago I began experimenting with an open source business process management suite. Ultimately, my goal is to allow the BPM system to be the backend interface between the app and the database. (I am testing architectural ideas mentioned in the post series Building Clinical Care Software Systems and What if EHRs Were More Like Content Management Systems?) Thus far, I like what I see – a lot.
In 2009, when HITECH went into effect, no one had any idea how care delivery would play out six years later. In 2009, the iPad did not exist, the App Store was only six months old, cloud services were suspect, and NoSQL was a curiosity. Both information technology and health care have changed, and software originally optimized for local area networks and desktop computers can no longer cut it.
Ambulatory care is in need of innovative products optimized for today’s technology and designed to meet current care delivery challenges. Mobile + cloud + workflow engine + modular = systems that offer the required functionality with lower maintenance costs for a reasonable price. Modular systems that allow buy-it-as-you-need-it purchases of additional functionality would address cost constraints of small practices while shortening implementation times.
As the saying goes, “Necessity is the mother of invention.” Care delivery in outpatient settings is changing rapidly, and better HIT support is absolutely necessary if clinicians are to be adequately equipped to meet the challenges ahead. The stage is set – MU is winding down; the number of EPs uninterested in incentives is growing, enabling technology is available, care delivery is becoming more complex, capital for HIT ventures is growing, and current market leaders cannot quit MU. The ambulatory market evinces all the factors required to drive experimentation and innovation, and there lies the future of HIT.