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!
© Copyright Jeffrey Morgan, 2016
This article first appeared on cio.com at: http://www.cio.com/article/3138958/software/heres-why-your-ehr-doesnt-work.htmlby
I never sign medical release forms anymore. That’s because I read them. These forms tend to be lengthy documents which ultimately state that your medical records can be shared with just about everyone on the planet.
Don’t believe me? Here’s the first paragraph of a 2,000-word explanation of how PHI (protected health information) can be used by a nationally recognized pediatric provider:
Quality Improvement Activities: Information may be shared to improve the quality or cost of care. For example, your PHI may be reviewed by XXX XXX or outside agencies to evaluate and improve the quality of care and services we provide.
Outside agencies? Are you kidding me? Who would you sign that release?
Three can keep a secret if two of them are dead
Maybe I’m just an old-fashioned Luddite, but I prefer to be treated by a doctor rather than a corporation. A private practitioner who has a personal relationship with me is much more likely to take steps to ensure my privacy. Once those records are on a corporate network, my chances of privacy are considerably diminished. If my records are accessible to a RHIO (regional health information organization), the probability that I have medical privacy is near zero.
The problem isn’t necessarily one of policy or procedure; it’s more human behavior. Clerks and bureaucrats at Giga Health Services or the RHIO don’t know me and aren’t likely to care if my records are released to someone who shouldn’t see them. Their pockets are too deep for me to sue, and chances are that I wouldn’t ever even know whether my information was inappropriately or illegally disclosed.
Opt-out programs are a privacy abomination
Providers, CIOs, mental health directors, public health directors, and consumers should all be campaigning against the erosion of privacy that results from extensive sharing of health information. Instead, they are drinking the Kool-Aid and rolling over.
The Affordable Care Act has exacerbated the problem considerably, and I read all too much from healthcare IT industry pundits about the need for increased sharing of information and more “visibility.” This is all rationalized by dubious claims about saving lives and “improving outcomes.”
We’re all team players
In county and municipal government, it is often the case that consumers getting public or mental health treatment may also be involved with other departments, including social services, law enforcement, the court system and probation.
“We’re all on the same team, we’re all county employees. Why not show us what’s in those records?” asks the sheriff. The correct response from health officials should be “Get a subpoena, prepare to show cause, and we’ll see you in court buddy!” Unfortunately, a common response is “Sure, let’s have a look. We’re all team players here.”
I know what you’re thinking. “Those people might be criminals! They wouldn’t do that with my records.” Yes they will. Even worse, you might be saying “I have nothing to hide. I don’t care who sees the information.” Not everyone would feel the same way, and many public figures have refused to release their medical records and even their academic records.
Once we begin to get cavalier about disclosure of PHI and other personal information, we are way past the slippery slope stage. We’re already rolling down the mountain in an avalanche. Redisclosure is governed by federal and state law and the problem isn’t restricted to local government entities. State and federal law enforcement and intelligence officials are likely to be granted access to PHI and all sorts of other personal information as well, without any of the legal protections that should be in place.
What’s the role of IT in protecting privacy?
CIOs should be playing a greater role in protecting privacy, but very few IT professionals have had any training on the subject. How many IT people do you know who are familiar with 42 CFR Part 2?
There are so many questions. What happens when IT directors receive subpoenas to provide protected information? Would they fight, or comply? Would they have any idea of how to respond? And what if your SaaS vendor gets the subpoena, circumventing professionals who will know how to respond? Is that addressed in your contract? Extensive training in privacy should be part of the tool set of every IT professional, but this is not currently the case.
This article was first published on CIO.COM at:
© Copyright Jeffrey Morgan, 2016
As a Mental Health Commissioner or Director of Community Services, purchasing the right EHR & Practice Management System will be one of the most important business decisions of your career. Even for a relatively small practice, you will spend at least several hundred thousand dollars once all the relevant modules, training, data migration, and implementation are accounted for. It’s an overwhelming decision on top of DSRIP, ACA and all the other changes in the industry.
One of the big problems with purchasing such a system is the learning curve. If you are new to the procurement of major systems, you probably don’t have all the tools you need to get through the process. The second problem is all about assumptions. Managers who are new to software procurement often make the assumption that the software company is providing a turnkey solution. Here is the ugly truth: the software company will only do exactly what you asked for in the RFP. Anything you forgot will cost extra. Even if you are purchasing a turnkey solution, there is still a great deal of work for you and your staff to do. Here is a link to my article about software implementation models.
First, let’s talk about some of the tools you will need as well as the general approach to the procurement process you should be taking. Then, we’ll discuss some of the specifics for EHR/Practice Management systems.
The 12 Step Program for Software Procurement
I have written about this before in other contexts, but the basic process is the same whether you are purchasing an ERP, EHR, CRM, or any other type of system. Following is a summary of the basic steps with links to more detailed discussions of the specific steps.
- Draft a Project Charter
- Establish a Procurement Committee & Appoint a Project Manager
- Conduct a Business Process Review
- Identify and Document Goals, Objectives and a Preliminary Budget
- Conduct a Needs Assessment
- Analyze and document your Information Technology Infrastructure
- Document Environmental Factors and Organizational Culture
- Draft and release an RFP (Request for Proposal) or IFB (Invitation for Bid)
- Review Proposals and Prepare a Short List for Demonstrations
- Hold Software Demonstrations & Select a Solution
- Customer and Vendor Site Visits
- Negotiate and execute the Contract
You may have noticed that drafting and issuing an RFP comes late in the project. In many of the failed projects I have studied and reviewed, the buyer treated the RFP as the first step rather than one of the final steps. Moreover, I have presented the steps sequentially, but they don’t need to be so. For instance, steps 3-7 can be conducted concurrently if you have a staff member or consultant with the skills to do so.
It sounds like a simple process, and it is. It’s going to take more than 15 minutes to put it together, however. If you are truly using due diligence, it may take several weeks to gather all the information required to assemble your RFP.
Behavioral Health Specific Questions – Some Considerations
In addition the procedures described above, there many industry specific factors to consider. I provide a summary of some of these issues below in the form of questions. However, this is not intended to be an exhaustive discussion. Please e-mail me if you wish to discuss your project in more detail and we can setup an appointment to talk. The first hour is free!
Are the systems you are reviewing certified for all 3 stages of Meaningful Use?
Forms & Regulatory Compliance
What forms do you currently use? Are your forms fully compliant with both Medicaid and NYSCRI or other state specific forms? Does the vendor have a major presence in your state and are they committed to the immediate implementation of regulatory changes for your state? Will there be an extra charge for unexpected regulatory changes? Will you require custom forms with custom mandatory fields?
HL7 and Interoperability
Do you need RHIO connectivity? Right now or down the road? What sort of impact will DSRIP have on your project?
Third Party Hardware and Software
What third party hardware and software is required for the system? How much does it cost and what will be the 5 year TCO?
Will the system allow you to go paperless? What about the cost of scanners? Will you use a centralized or distributed model for document imaging? What are your state’s regulatory requirements for scanning? Most states have specific legal and procedural requirements for document imaging. For New York, the requirements can be found here. Is your software in compliance with state imaging guidelines?
What is your workflow from initial client contact forward? Every agency has a different workflow and quality EHR systems have flexible workflows that can be adapted for your specific requirements. Do you have flowcharts? Do you want to change your workflow to a more efficient model during implementation? What will your new workflow look like? Who is going to configure rules and alerts for Treatment Plans, etc? What is the workflow between clinician and billing?
Total Cost of Ownership (TCO)
What is the real 5 year TCO of your system including maintenance, support, consulting services, implementation and third part products?
Return on Investment (ROI)
What will the ROI of your system be? Will productivity improvements allow you to reduce staff or will you have to add staff?
SaaS Vs. Customer Hosted
Do you have the infrastructure to host the system internally? Or does a SaaS (aka “Cloud”) system make more sense? Which makes more sense from a business perspective and what are the long term costs and consequences of each type of system? What are the pros and cons of each system?
Do you have a Comprehensive Information Security Policy? Is the software you are purchasing flexible enough to implement your security policy in the system? Do you have an information security officer? Who will monitor and document system security?
What are your reporting requirements? Will you staff need special training to build reports? Have you included required reports in the RFP? Does the software allow you to easily build required CFR’s?
Who is going to handle the data migration? Most vendors insist that you supply the data to them in a specific format. Do you have staff members who can extract the data from your old system and provide it to the vendor in the requested format? Who is going to validate the migrated data and how long will it take?
Do you have a comprehensive list of Payors and Clearing Houses? Each of these will have to be configured individually. How will your system handle write downs? Cash Payments? Credit Cards? Invoicing? Are you still doing any paper billing or is it all electronic? What billing forms do you use and are all these supported by the system?
Installation, Implementation, Configuration
Have you budgeted for sufficient professional services to get the project completed without excessive cost overruns? Are you going to implement EHR and Billing simultaneously? Or in stages? What is your timeline?
Have you budgeted for sufficient training and Go Live support? No matter how much training you have built into the project, I assure you that you will need more than you think.
I get it. You are Mental Health Professionals, but transition to a new EHR/Practice Management System is a painful process and Change Management is something that must be considered.
You may wish to read my article on writing RFP’s before you get too far down that road.
EHR/Practice Management projects are only successful when the executives provide unwavering support and dedication. These sorts of projects don’t succeed or fail by accident. You will have to roll up your sleeves and get your hands dirty to succeed with the minimum amount of pain.
As I have already indicated, this is a partial list of questions you should be considering before you write an RFP. Please e-mail me at firstname.lastname@example.org if you would like to discuss your EHR or Practice Management System Requirements.by