Tell me about your processes
“I hope you’re not going to show me a bunch of flowcharts. At the last place I worked, they flowcharted everything.” Thus spoke a client in a consultation about his troubled EHR (electronic health records) project. It wasn’t difficult to figure out where the project went off track; it was doomed from the beginning.
My inner Jeff Lebowski wanted to shout, “Dude! You didn’t map your processes. No wonder your EHR doesn’t work.” Process mapping should have taken place long before my client began discussions with vendors. The RFP should have included process maps so the bidding vendors would have had a clear understanding of what they were required to build.
Map your processes!
Let’s take a look at a high-level process diagram for an outpatient behavioral health clinic. This is one possible workflow map, but every organization is different. The level of detail your mapping reaches depends on your business requirements, but it is reasonable to contemplate and document field-level requirements before beginning your procurement process. For instance, do you need a field that identifies whether a client contact was by phone or in-person? If you don’t proactively account for every component, it may be too late for an optimal solution once implementation has begun.
My wife has been looking for a pair of red shoes for three years. Not just any red shoes — they must meet very specific requirements. They must have high heels and pointy toes, they must be comfortable enough to wear all day, and they should be a specific shade of red leather. They must also match clothing already in her wardrobe. Brand doesn’t matter, and the ideal price would be in the low-medium three-figures. She has designed them in her mind, but she hasn’t been able to find them in a store yet. Shoes are a big deal, so it’s a complicated process.
Shopping for enterprise software isn’t so different from getting the perfect pair of red shoes. Envision what the ideal software application will look like before you even begin shopping, and design it together with your team. Evaluate and document all the processes from initial client contact through discharge. What happens at every step? What are the inputs and outputs for each process? Do you need a screen that replicates a face sheet? What does a billable progress note look like, and how will it link to the practice management (PM) system? What will all the reports and other outputs look like? Does it have to interface with existing applications and processes?
At a minimum, your “design” team should consist of clinicians, billing professionals, other subject matter experts and possibly legal counsel. Depending on how your applications are supported, you might want to invite IT. However, allowing IT to manage the design and process mapping is a big mistake since they are unlikely to understand the clinical nature of the project.
Does this all sound expensive and time-consuming? I can assure you that a failed EHR implementation is far more expensive. Eight- and nine-figure failures are not unusual, and years can be wasted until organizations are willing to say uncle and admit they got it wrong.
Plan to maximize revenue
Another critical exercise is the development of a catalog of services aligned with both customers and payers. For instance, if the majority of your clients are covered under Medicaid, the services offered should align with how Medicaid pays for those services. Unless you are in the charity business, you can’t afford to offer services for which you will not be paid.
Many organizations are able to significantly increase revenue and decrease denials by carefully evaluating their business processes at this stage.
How will staffing be affected by your new system? You may need more or less staff, or may need different skills once your new system is in place.
Plan for quality and compliance
Quality assurance (QA) and regulatory compliance must be built into the system at the design/conceptual stage. We learned from W.E. Deming that it is too late to build quality into a product once the plans are partly in place. Therefore, compliance, QA, and privacy and security must be considered at the design/process mapping phase.
Root causes of failure
Success with an EHR or any other type of enterprise project is neither accidental nor mysterious. One root cause of EHR project failure is invariably failure to understand and account for organizational business processes. Hubris is another root cause of project failure, and the vast majority of the time — 94%, according to Deming — these sorts of failures are failures of management. The crisis of management is not a mystery either, and Harvard Business Review provides a good discussion on the subject.
Don’t fear the flowchart!
This article is published as part of the IDG Contributor Network. Want to Join?