Develop Your Own EMR – You’re Still Crazy!

John,

Two posts about EHR workflow in one day? Cool!

Physicians complain about having to hew to what their EHR vendor thinks their workflows should be. It ought to be up to users (or at least someone who knows their workflows) to decide how consistent or flexible they’d like their software to be. Workflow technology opens up the possibility of physicians owning their own workflows. They can make everyone’s workflow the same. They can also allow different physicians to have different preferred workflow.

There’s a stereotype of workflow systems turning users into cogs, with humans doing what machines cannot, instead of machines doing what humans prefer not. That said, defining and executing workflows is one way to influence user behavior, to get folks to do their work the way that medical practice or that hospital intends it be done. Instead of making it impossible for users to depart from intended workflows, the best approach is to make it as easy as possible for users to do their work intended ways, ideally ways that have been vetted and discussed and agreed upon by relevant personnel.

Consistency and flexibility are in natural contradictory tension. At one extreme is a physician, working with lots of physician assistants and nurses and staff, who’d like to make sure everyone does it his or her way. In organizational management-speak, customizable workflows enable greater “span-of-control” than otherwise possible. At the other extreme, multiple physicians can work together and each have their own workflow.

The cool thing (even cooler than two posts about EHR workflow in one day!) is that I’m seeing new health IT products coming into marketplace that rely on true workflow tech. Whether or not they call their systems EMRs or EHRs is besides the point. The point is they are addressing the single biggest problem with many current EHRs: inflexible workflow that cannot be systematically improved.

More workflow please!

–Chuck

John, there is at least one vendor who has negated your contention, “Plus, no EMR vendor has focused their EMR on patient care instead of billing.” Check out: http://www.elationemr.com.

It’s one of the most workflow-oriented EMRs ever. They started with the idea of patient care as their only mission. Very user-focused; in fact, they have IDEO, the “human-centered design” folks as an advisor/investor.

Good pricing and support structure, too.

Chuck, you’ll like it, I’ll wager. And, Carl, there’s the envelope! 🙂

I’m delighted to see the quality of this discussion of EMR and EHR workflow and workflow technology.

Ten years ago I wrote a survey of EHR workflow functionality that appeared in the old Advance for Health Information Executives. Here’s a high-level outline (more details at following links):

System displays selected worklists for active cases.

System permits employees to view and complete work items that have been assigned to other employees.

System creates reminders for work items that have not been completed when due.

Users can selectively modify assigned work items.

System maintains a record of various changes made to work items.

System maintains various records of completed activities.

Users can selectively correct or modify records of completed activities.

System has a workflow engine that automatically creates work items based on a workflow definition using various defined criteria.

Users can customize workflow definitions to match their internal processes using various defined criteria.

Users can define roles and resources that will receive task assignments.

Users can edit workflow definitions using a graphical user interface.

Software vendor provides workflow definitions for individual medical specialties.

http://chuckwebster.com/2009/03/ehr-workflow/survey-electronic-health-record-workflow-management-system-features-functions

Believe it or not, back then, most EMRs didn’t do any of the above. Now some EMRs do some, but most do not, in my opinion quality as full-fledged EMR workflow systems.

That said, I do see workflow technology and/or marketing of workflow ideas, diffusing into healthcare.

I updated the survey in 2009, applied for copyright…

http://chuckwebster.com/2010/03/ehr-workflow/copyright-received-for-ehr-workflow-management-systems-criteria

… and republished under a very liberal Creative Commons license. Basically, anyone can use or adapt for any purpose (including commercial) as long as they attribute me as author and link back to the original.

Why am I posting this information here?

I am seeing a groundswell of interest in EMR/EHR and health IT workflow issues. It is, I believe, the single most important impediment to widespread adoption of health information technology.

I’d love to see a new interest to find and highlight EMRs, EHRs, and related health IT systems that are, to use the academic phrase, “process-aware” (that is, the opposite of “workflow oblivious”).

Conversations such as this are an important part of building awareness and interest in workflow technology in healthcare. In the ten years that have passed since the original survey, technology and terminology have evolved. The workflow management systems industry evolved into the business management systems industry. The BPM industry has segmented into variety of complementary (and sometimes competing) approaches. For example, one of the debates there, about structured versus unstructured workflow (“workflow”, not “data”) is relevant to a wide variety of EHR and health IT efficient, effective, and satisfactory process and workflow management topics.

Anyway, as I said at the outset, I am delighted to see increasing awareness, interest, and, perhaps even, intent to leverage workflow tech in healthcare.

Carl, I see you’re with EHR Selector. I hope you’ll consider using the EHR Workflow Management Systems Survey.

Gregg, Thanks! I’ve tweeted about @ElationEMR and enjoyed our interactions about workflow (and your and my interactions on Twitter too).

John B, “The real issue is alluded to above: that is workflows.” < totally agree.

John L, Thank you for creating a place on the web to discuss EMR workflow (and many other important topics).

–Chuck

“Buy an Off-the-Shelf EMR – You’re Still Crazy!”

Pick your poison. 🙂

The referenced ‘crazy person’ is a primary care doctor that, like me, was very disillusioned with the EHR products out there, especially since Meaningful Use started. The one thing I believe is true is that no one EHR is going to be for everyone and even with the same EHR, there are so many variables that need to be accounted for regarding workflows (even if the doctor knows the ins and outs of their own clinic workflow) that one cannot assume that a number of EHRs can cover the different physicians/hospitals/clinics and each of their own individual workflows. Other clinicians I’ve worked with and have used the big vendor EHRs have admitted to me that the disasterous implementation process all boiled down to the negative effect on workflow and ultimately to patient care. It is extremely frustrating and costly once they stumble upon it. And every clinician has a different idea of what works for them.

One thing that is for sure is that forcing certified products to doctors that will alter and change their workflows (usually in a negative fashion) is not a risk most doctors feel comfortable doing.

Another thing to keep in mind is that the challenges of a primary care doctor are different than specialists. That was one reason I developed my own EHR because I could not find an EHR that could adjust to my workflow (pretty similar to the doctor referenced in this post) without costing an arm and a leg for customization, because certifying an EHR for MU would cost the vendor significantly to cater to the needs of different doctors. That was one of the big reasons I felt that MU really disincentivized innovation – you’re locked into an expensive product that may or may not help you care for your patients. Not a risk I’d be taking when reimbursement rates by insurance companies for primary is so low to begin with. It was a lose-lose situation for me and my patients all the way around.

My ideal is that EHRs need to be left out in the open for customazation regarding user interface (and workflows) and open source is one venue where that can be done in very cost effective way, especially for primary care. But data needs to be standardized and full interoperability needs to be embraced by all EHR vendors to get the full benefits of electronic health data. That’s where MU should have spent its efforts, instead of where it is now.

Any others out there wanting to follow Dr. Chen?
Let’s do it.

Customizable workflow: Workflow engine? Process definitions? (tho you may call them something else)

http://chuckwebster.com/2009/12/ehr-workflow/why-pediatricians-need-pediatric-emrs-that-understand-more-than-pediatrics#specialty

I’ve been that guy. More than 10 years back, I was the doc who thought “this could be better.” I used that combination of frustration & hope to create point-of-care tools for ICD-9 and CPT coding that continue to have a loyal following. At any point, I would have gladly abandoned the project if I found another tool that met my needs. But it didn’t exist so this drove me to keep working on improving my own tools. But a fully functioning EMR is such a much more complicated beast. The need to meet all of the security, legal, HIPAA, and MU requirements while also maintaining (or improving) workflow, being very usable, and keeping up with all of the evolving needs makes for a very complex project.

Sure, some docs have taken on the challenge. eMDs, SOAPware, and Amazing Charts were all started by family docs who took it on and, according to many satisfied users, have succeeded in creating better products. But, here in mid 2013, isn’t it far too late to start a new EMR?

To answer the question, I’d like to share my group’s experience with choosing Elation EMR, the product mentioned above by Dr. Glenn. In Oct 2010, our 12 doctor family medicine group started the search for our first EMR. We had demoed 7 EMRs a few years earlier for our affiliated residency program so had some sense of what we were in for. We heard about ElationEMR and set up a demo. They showed us a very easy-to-use system; one where you could do anything at anytime without clicking through layers of windows. We were impressed by the vision of Elation’s founders – they seemed to “get it.” But they were a very new company. ePrescribing: “coming soon.” Lab interfaces: “we’re expecting this in 6 months.” Despite our enthusiasm about Elation’s concept, I didn’t see this early version of the product as meeting the needs of our busy docs, most of whom would shun the beta testing tolerance necessary for adopting a product in its infancy. And there was so much left for them to do. How could a small company with a couple of programmers build out prescribing and lab interfaces and also meet all of the Meaningful Use requirements in any reasonable time frame? “No way,” I thought. And our grouped decided against using Elation EMR. It just wasn’t ready and I figured it would take a few years before they’d be able to build out everything we needed. “If only they’d started a couple years earlier,” I thought.

Other things came up and our EMR search got put on the back burner for a time. About a year later, we were back to our EMR search, had had demos from a couple of strong contenders, and were about to make our final decision when someone suggested we take another look at Elation. At our second Elation demo, just 1 year after the first, I was blown away by how much progress they’d made. Their eprescribing system was not only up and running but it was the easiest-to-use system I’d ever tried. Lab interfaces, check. MU certification, check. Elation had evolved from a great concept to a fully functional, wonderfully usable product. Our group signed up (month-to-month contract, no start-up fees) and started using it within a month.

In contrast to many who have been frustrated with their EMR’s usability, our group has been thrilled with Elation. We implemented the system with no downtime for training, no decrease in patient volume, and no decrease in productivity. On day 1, I suggested that my partners use it to document visits for 1-2 patients just to get started. Most told me that they ended up using it for every patient instead of just one or two. It was that easy. Elation has intentionally chosen to avoid templates and tallying bullet points that make E&M coding easy but have made so many EMRs painfully unusable. Doctors with a little training know how to assign an E&M code to a visit. I’d bet all would gladly sacrifice this billing feature for a more usable EMR. I could go on at length about the strengths and also some of the shortcomings of Elation but, for this post, will try to stay to the point.

Based on my experience with Elation, I would have joined many in saying it’s crazy to start a new EMR company. But, Elation’s development team surpassed my expectations and quickly developed a fully functional system our group loves. Even better, they continue to evolve it, most recently having added a great patient portal that communicates with patients by email or text message.

Most doctors who would consider starting their own EMR company would approach it with the attitude “Nothing else does what I need so I’m going to build it myself.” I would encourage these docs to take a long look at some of the new, innovative, and rapidly evolving products out there, like Elation, and to save themselves the trouble.

Disclosure: I have no financial relationship with Elation EMR. I like supporting good products and helping docs find tools to improve their quality of life and patient care.

I’ve found the MU requirements can make an otherwise decent EMR suffer. For example, I previously used a web-based EMR that implemented an allergy documentation component that met MU requirements but was impossible to use in real-world clinical care. It didn’t allow one to enter a class of drugs (“I’m allergic to sulfas”) only specific agents. It didn’t allow an allergy entry without specifying the type of reaction. As any practicing doc knows, a good chunk of allergies come in as “I don’t know what reaction but my mom told me I’ve been allergic since I was a kid.” It met MU requirements but it was truly unusable. It continued in this unusable state for more than a year. I think it’s fixed now although I no longer use that product.

In contrast, when I started using Elation, it only allowed allergy documentation as free text. This was very usable but did not allow for drug interaction checking and may not have met the MU requirement. They waited to introduce a fully MU compliant version for allergy documentation until they had something that worked great and didn’t mess up my workflow.

Some of the MU requirements are great, others less so, but it is definitely possible to meet them all in a way that doesn’t sabotage workflow. I think the problem has been that many companies have approached this as “What’s the fastest, easiest way to program in these mandatory MU requirements” rather than “How can I meet MU requirements while maintaining priority for the doctor’s experience, workflow and ease-of-use?”

Re: AXEO’s comment about the establishment cementing in place big EMRs. I think may be true but innovative upstarts still have marketshare to capture from all of the big companies that are failing their user base. When I see a survey that says “XX percent of docs hate their EMR” I think it much more likely that these docs will jump ship for a better product in lieu of somehow getting their current product to improve. Agree with you though that lack of market share and being “established” is a barrier for big institutions looking to change. They may be destined to repeat their mistakes all over again if they don’t look at some of the newer systems with sky high user satisfaction rates.

John,

I don’t agree with that sentiment either. I think it’s valuable to have some basic mandated functionality along the lines of what MU has established. All would agree a good system should have problem lists, documentation of allergies, & the ability to eRx, for example. I think the MU incentives have pushed a lot of docs to make the leap, docs who wouldn;t have otherwise. Yes, it’s imperfect but it’s moving the mass of physicians as a whole in the right direction.

Drs Gregg and Andrew make some good points. MU incentives have primed the pump for some real reform. I don’t put all the blame entirely on the EMR vendors. There are great solutions out there, but many physicians have been misled by aggressive sales and even the RECs telling people to buy only from the big five. Unfortunately the big five are also the purveyors of the least flexible solutions. The key is to stop listening to the old experts and look for solutions from the smaller, more innovative vendors. The more physicians look at more innovative solutions, the faster we will put meaning into meaningful use. ElationEMR and BuildYourEMR are raising the bar, but this is a tougher sell when the pundits are still pushing the dinosaurs.

This is a variation on the “nobody ever got fired buying IBM”, and David v. Goliath. In this case though, the stimulus was artificial and the game was rigged so to speak.

I can’t blame the RECs for taking the safe way out. Also, they can’t be expected to learn and be able to train others on more than a handful of systems — good or bad.

As I posted above, the general goal of a nationwide system to treat and manage the small % of the patient population that paradoxically uses a large % of the resources, AND likely can’t fend for themselves, is a good one.

The implementation though seemed/seems quite convoluted.

Once the stimulus money runs out and market forces return, the upstarts will have a chance again. Of course, another wildcard is the “fremium” approach. EMR would be the absolutely LAST market I would even think of for this model. 🙂

Re: Freemium EMR. Practice Fusion meets this definition. Free to play, monthly fee to remove advertising, company uses and sells aggregated, anonymized data to industry, others as revenue stream.

I used PF for a while and was impressed by some things about it (no barrier to start up, easy to use, great online YouTube tutorials) but frustrated by others (unusable allergy module with no timely response, many months without lab interface setup). When compared to my current EMR, it reinforced the saying: “Sometimes free is too expensive.”

I think ambulatory practices, particularly smaller practices, will be faster to embrace next generation EMRs than hospitals because the complexity of a hospital’s need to deal with the legacy/integration/device issues would scare away any lean, start company. In contrast, small practices with fewer complex integration challenges have the freedom to jump on board with an innovative system that just does it right.

But the hospital system I’ve seen is much farther away from a great product than even the lowliest of the ambulatory EMRs I’ve used. So the desire to find something better for the hospital may have more enegetic support since they’re coming from such a lowly starting point. Still, changing a hospital EMR system is such a HUGE undertaking I bet most would stick with a lousy product for decades settling for incremental and trivial improvements rather than suffer the pain of transitioning. Too hard to turn the battleship.

I think you have it right, John. A start-up could master a niche in the hospital IT system, get a foothold, and then bring that same winning formula to more and more hospital subsystems until it had an excellent, user-friendly, state-of-the-art, unified hospital health IT system in place.

But in reality, wouldn’t one of the big fish companies buy out the upstart long before it could build itself into a comprehensive system. In our dream world, once acquired, the big company would support innovations and momentum of the startup to help it build out and improve one system after the next. In reality, we’d be lucky if they even kept the innovative module instead of just burying it and keeping competitors from getting it. In either case, the dream of an upstart developing a comprehensive hospital IT system would not be achieved. Maybe there’s another way to disrupt hospital IT successfully.

John,

By the way, run a spell checker on your site looking for “Subcribe”.
It’s bugging me. 🙂

Wow! 44 (and now 45) comments on John’s initial post…congratulations John!

I’m not sure that big guys versus little guys, or proprietary versus open source, are the most useful axes of comparison. Most of the problems that plague EHRs seem to involve workflow issues. To put these issues in perspective, consider that EHRs are subject to the same series of developmental stages as applications in other industries.

1. Data, user interface, business rules, and workflow were all mixed together, in an unmanageable and difficult to improve tangle.

2. Data moved out of applications into databases. This happened to EHRs.

3. User interface code (dialogs, buttons, etc.) moved into the operating systems. This happened to EHRs too.

4. Business rules began to move into rule management systems, such as is happening with clinical decision support.

5. Workflow (by which I mean executable representations of workflow) moved out of applications. By storing workflow separately, it can be understood by non-programmers and more easily improved. This hasn’t happened to EHRs yet.

In my, admittedly biased view — John’s applied the hammer and nail analogy to my interest in workflow — the most useful axis of comparison is one along which EHRs, and other HIT systems, can be compared with respect to the degree users can control and systematically improve workflow. I suspect many of these will come from startups. However, there are some workflow management system/business process management system vendors interested in healthcare that are much larger than an EHR startup. Similarly, while most of these workflow vendors are based on proprietary software, there are also open source workflow systems as well.

So, yes, I agree with John that anyone would be crazy to design, develop, market, and implement an EHR from scratch these days, just as anyone would be nuts to go into the word processor business. But developing an EHR from scratch is not the only choice. I’d love to see more EHRs and health IT systems be developed on true workflow management systems/business process management systems chassis. Workflow management system and business process management technology bring the possibility to clinicians who use clinical software to make it do what they need and want without reliance on well-meaning C#/Java programmers who can never completely understand clinical requirements.

Interestingly, at least to me, was how much discussion of workflow there was at the Long-Term & Post-Acute Care health IT conference several weeks ago in Baltimore. LTPAC hasn’t been subjected to Meaningful Use, much to the dismay of some. However, in contrast to some health IT conferences I’ve been to, their discussion of workflow as it relates to care coordination, clinical decision support, telehealth and population health management was actually *more*, not less sophisticated. Most interesting to me was their assertion that EHRs need to be “workflow platforms,” which is exactly what I’ve been saying for years.

Workflow Platform Themes at the 2013 Long-Term and Post-Acute Care Health IT Summit

http://chuckwebster.com/2013/06/healthcare-bpm/workflow-platform-themes-at-the-2013-long-term-and-post-acute-care-health-it-summit-lets-get-started

While it may be crazy to write an EHR from scratch using Java or C#, if may not be so crazy to implement an EHR on one of the many sophisticated workflow platforms out there (from large and small vendors, proprietary or open source). What is it that EHR vendors are struggling to add? Customizable care coordination functionality. Well, customizable coordination is exactly what workflow systems do. Then throw in the fact that workflow vendors are further along than health IT in incorporation of social, mobile, analytics, cloud, and language technologies. Plus social, mobile, analytics, cloud, and language vendors are further along in incorporating workflow tech. In fact, I’d argue that this amalgam of technologies are really a sort of meta-platform, rather than a collection of individual platforms.

In other words, tools and platforms now exist that mean that a physician who decides to design his or her EHR may be crazy like a fox.

For some, the workflow issue is subtle and nuanced.

For some, a system that allows customization of forms, the order in which forms and fields are displayed, etc., IS workflow.

For some, they want a system actually based on a workflow engine.

For some, the workflow issue is a differentiator even if perceived by others as “faux”.