Medical and nursing education should include basic documentation standards as well as an introduction to EHRs that includes the rationale for needing certain data to assure patient safety while also fulfilling quality, regulatory, and billing requirements.
As for EHR vendors, there should absolutely be a process that assures clinician input throughout the software development life cycle. It's not enough to have clients brainstorm and review designs with business managers, software engineers, and usability specialists - you have to have in-house clinicians who can help the developer teams interpret what they're seeing and hearing as they don't have experience in the complexities of a healthcare setting.
Regarding patient safety, it's unacceptable for any HIT vendor to fail to have a patient safety program that includes experienced, certified patient safety and healthcare risk management clinicians as well as documented protocols for investigating, mitigating, communicating and remediating confirmed issues in the live environment. Simply having a physician or a nurse looking at functionality and prioritize issues is not enough - they do not have experience in safety-centered design principles, assessment of risk based on harm and probability, legal and compliance considerations, or the application of proactive or reactive safety methodologies (e.g. Failure Mode and Effects Analysis, Root Cause Analysis).
While patient safety clinicians can be embedded within R&D teams there must be separate governance for the safety program in order to assure the integrity of the program and eliminate any potential for conflict of interest.

As an educator in a large medical school. for now I see limited role of EHR in medical education. Apart from learning how to document well. I am not sure how much it can add. Documentation is a skill which they need to learn regardless of if they use EHR or paper chart. I have following two suggestions:

1. If there is some standardization on EHR physician interface that may be helpful. Currently if a medical student learns a system - say Epic in med-school, and then they use say patient keeper in residency, there is really not much in common, they have start from scratch. These two EHRs behave vastly differently as far as interface and automation is concerned.

2. EHR need to move on to next level, from basic document editor and macros to more AI related patient decision support. For example if a medical student enters some complains in HPI and adds exam findings, the plan should start giving differentials. This will be a feature which may be helpful in their education.

Hope this helps

Great question, Ben. Contributors to our discussions this week have talked about implementation challenges, and what's worked best (and not worked) from the perspectives of healthcare system administrators, end users, and EHR specialists, as well as vendors. It seems that all of us agree that a successful implementation requires an open, transparent, and ongoing partnership between the facility and the vendor, and that partnership doesn't end on the last day of the go-live. To me, that's when the real work begins - assuring the EHR is used effectively, safely, and essentially as designed. (Interesting insights on the earlier question on shared expectations between healthcare system and vendors.) This collaboration should include discussions about measurement. What milestones make sense and are achievable, and at what intervals? Is achieving MU sufficient? What is the definition of done? Regarding the latter, we have to consider the ever-increasing requirements from regulators, accrediting agencies, and payors - not to mention the burden of ongoing infrastructure work to support data exchange across systems. Defining success has to involve end users, and it can't be the loudest physicians in isolation. It should include nurses (especially in hospitals), the front line staff who register and schedule patients, billing staff, office clinical support staff, and those responsible for managing quality and safety reporting. Healthcare system decision makers aren't necessarily using the EHR product every day, and they don't know all of the workflows. But together with their end users, they can identify some fairly straightforward assessment elements and define metrics, for example: No paper workflows remain for EHR supported workflows, physician documentation time has decreased by x%, patient registration time has decreased by x%, no patient identification errors occur, all data elements required for quality reporting are captured and regulatory and quality metrics are met.

RE: "No paper workflows remain for EHR supported workflows". That's an interesting one. We did a study on health IT safety issues in pediatric settings. One thing that came up is that cancer care is so complicated that sometimes EHRs aren't able to effectively help clinicians with all the nuances and necessary details of that kind of care, so paper charts are used. Then, things documented in one place may not be documented in another, which could result in--for example--patients getting an extra dose of a drug that's highly toxic. Is that something that Joint Commission could look for (e.g. is care still being documented via paper means when that capability--such as a medication schedule--is available via the EHR)?

For those that haven't seen the study done with MedStar and others, it's here in Health Affairs. healthaffairs.org/doi/abs/10.1...

Years ago I was involved with CCHIT and currently there is the ONC certification program. These programs are okay for establishing guidelines and provide a basis for comparison but the criteria needs to come from the leadership at the organization.

Good point, Ben. I think it's important to draw a distinction between what the EHR supports, and what it doesn't. It's reasonable to use paper for oncology or other workflows are highly specialized for the individual patient, as well as ever-changing due to factors such as weight and other anticipated variations throughout the course of treatment. But if the EHR does support the functionality - for example the top 75% of ambulatory office visits for the practice - there shouldn't need to be a need to revert to paper for charting, and especially not for ordering medications.

Surprised not much discussion on users such as doctors nurses and others. An EHR can be meeting all the checkboxes of successful implementation yet can be an ordeal to the users. Too many clicks, inability to auto flow data, rigid unnecessary arbitrary interfaces and rampant in many major EHRs yet they are successful.

Huge disconnect yet frequently overlooked issues. The problem is that once a hospital commits to an EHR system by investing millions they really don’t have much say.

What i have seen is the Chief Medical Officer (CMO) and the clinical steering committee. They set the guidelines on clinician's use of EHRs. Now, enforcement is a different story. While the clinical steering committee can set guidelines, there has to be incentives for physicians and other clinicians to follow them.

Abraham brings up a great point and is traditionally what I have seen in the past. Greater adoption of the guidelines can be done by giving buy-in to the groups that will utilize the EHR. That could be creating an adoption group to continue revamping and improving guidelines which consist of leadership roles, Physicians, and other end users.

The only thing I would add to this is that in our transformation to team based care the IT folks play a key role. I really see it as a partnership between the physicians driving content and the IT folks who help implement it. As with any change process, any time things like new processes or guidelines are put out, they can create challenges.in acceptance by docs. That seems especially pertinent now, since it seems that new guidelines and upgrades are continually being rolled out. Communicating rationale for these new guidelines helps, but what really helps is if there are some positive results that can be communicated, perhaps from a pilot phase. In our experience, that improves doc's acceptance of new processes. For example, showing quality measure improvement of teams on team-based care helped us get new teams to buy into our new processes and workflows.

I would also recommend the EHR vendor being a part of the process. A good training plan and regular meetings that review the implementation and the processes being developed would be helpful. Often times the vendor may know a simple solution for a hurdle in the facility.

Clinical users and vendors should collaborate in the creation of guidelines for safe and effective EHR use. A great example of this, and one that my team relies on, are the SAFER Guides healthit.gov/topic/safety/safe... that provide recommendations not only for safe design, but also safe use and monitoring for safety. They're intended to be used by health care systems as well as vendors, or by both in a collaborative effort, but they can be creatively applied by either. For example, at my company we've used the SAFER Guides not only to education and influence our development teams about the safest solutions, but also to test the products ourselves. Gaining buy-in from stakeholders is essential, and to do that you must first make a business case for safe and effective use. Telling a team with a backlog of issues that they should fix one particular thing doesn't resonate as well as helping them understand the business value of prioritizing a specific solution - reduced corporate risk, improved client satisfaction, more efficient workflows, etc. And most of all, of course, promoting patient safety.

Successful client-vendor relationships are true partnerships marked by honesty and transparency. Clients should expect to understand the software development life cycle, including: Enhancement prioritization, end user input on designs (and iterations), alpha and beta enrollment opportunities, and processes for responding to routine client feedback and the escalation of critical issues. Chief among the latter are the vendor's processes for managing and communicating patient safety issues, which should be performed by clinician patient safety experts.
On the vendor side, expectations are that client leadership will champion and adequately resource implementation by assuring sufficient onboarding and periodic training, that they'll fully support staff through change management, and - most importantly - the client will engage in open and honest dialogue with the vendor when issues are identified.
A degree of customization is necessary, but client configurations can get so out of hand that they stray far from the original design, even impacting underlying functionality due to dependencies that may not be visible to the end user. That's why it's essential for the client and the vendor to partner in periodic workflow analyses after implementation to assure the product is essentially being used as designed.

Trisha brings up a great point about honesty and transparency within the client-vendor relationship. Because this relationship is a long term one, it must be created with specific delivery expectations, ongoing support throughout and post implementation as well as involvement from the health system. Of the organizations that I have seen that did not have a successful relationship with their vendor, it was because there was no cohesive process. They believed that if there is this large of an investment, the vendor should take on most of the roles and responsibilities. This was one of the reasons why 3rd party consulting companies came into the mix to help bridge that gap.
There should be the expectation of time and communication. Taking on a new EHR means full visibility into billing, workflow, training, and organizational discovery all that has very intricate processes involved and requires teams from both the vendor and hospital system to work together. Support staff and leveraging the proper resources at the right times is what makes a project run efficiently.
In terms of the customization piece, Trisha brings up a great point on how design can get out of hand and impact functionality. During these design/customization sessions, there should be open dialogue on how each change impacts foundation and what it will mean to the end user. Again it goes back to being realistic and honest about the level of customization that can help vs harm the organization overall.

Wonderful points about the shared responsibility of providers and developers, Trisha. For those that haven't seen it, AMA, Pew and MedStar released this report last year with examples of provider and developer responsibilities at different steps in the product life cycle. Many of the examples Trisha provides are in the report (in many respects because you advised us on the report!). pewtrusts.org/en/research-and-...

Great comments, Samir, and you highlight customization. So, how can we bridge the divide between customization that the provider wants and needs to improve workflow, while on the other hand the customization may in fact introduce usability, workflow and even patient safety problems? Certain post-customization/implementation testing helps, but we know that often doesn't happen. What about risk mitigation plans? If you, as a provider, implement a high-risk customization--especially one not recommended by the vendor--then you should have a plan in place to monitor the customization for safety problems and the ability to address them if they occur. What other ways can this customization tension be addressed?

The practice/facility should identify a project lead early in the process to be the key interface with the vendor and to coordinate internally. Depending on the implementation this could be a full time activity but it is key to success. Others have highlighted training and testing. I would suggest both activities be identified early in the process. There also needs to be a realistic expectation of time commitment required of the staff. The vendor also needs to manage the process closely, account for changes and delays and anticipate where issues are likely to occur.

Some great questions Ben! If there is true value to the customization that is necessary, and that customization is of high-risk, of course there should be a mitigation plan and fail-safe for necessary actions post implementation. Prior to full go-live of that customization, there should be unit and functional testing, system integration testing and some day in the life scenarios to properly monitor changes and make sure full functionality and usability is there. The most important aspect of any customization is to make sure that it still integrates with the foundation of the system but fits the needs of the organization. This can be achieved by having multiple sessions between the vendor and organization to handle customizations. Creating teams and task forces to build out and provide a level of support to make sure that the synergistic properties are still present.

Great question and responses. I agree with what has been said. Trust and transparency are key. Vendors need to set realistic expectations for the customer and continue to support these expectations with data and other customer experiences. I've seen in the past where an EHR vendor will suggest a plan for physician training for the size of the organization only to give up or water down the plan because of the customer balking due to time or resource commitment. In the end, the physician is frustrated because of the lack of training and go live support. Customers really need to listen to the EHR vendor on their suggestions and also make the committments necessary for a successful implementation. This goes for plan, design, build, test and implementation.

I am going to go in a slightly different direction. I had posted before about our efforts at Bellin to get the clerical burden of EHR work off of the physicians, through our team-based care model. What happens after that is, we started to see the EHR in a new light, namely, what an valuable tool it can be in population health work. When we first started, Epic did not have a lot in this arena, but with their resources, they have made progress. Plus, they have worked with us on things like our sidebar care gap report. Our rooming staff, in pre visit planning, or while rooming, can easily identify interventions the patient is due for, and with the help of standing orders, close these care gaps. The result has been a significant improvement in our quality measures. Plus, there is an overwhelming amount of data that is collected in these EHRs - we are starting to learn how to leverage this data into meaningful improvement in patient care and outcomes. Plus, we are starting to link Epic with our SNF and our community resource organizations to streamline care. So once the burden of the EHR data entry is resolved, then the great potential of the EHR can hopefully be realized.

Dr. Jerzak, well said! Before I worked in healthcare, many many moons ago (90's), I worked in data warehousing and analytics consulting. At that time, most of our customers were retail, manufacturing, marketing, airline companies. These companies had their systems around for over 10+ years and were now at the point of starting to move into the phase of analyzing this 10+ years of data to start making predictive trends etc. I see such a trend now starting in healthcare. EHRs collect a vast amount of data. Now we are at the time of trying to leverage this data to improve patient care through trending and predictive analytics. Its an exciting time to see what happens in healthcare.

Great comments and Insight! Considering the entire lifecycle of an EHR and the changing needs of the health system is a daunting task. It is human nature to only consider the immediate issues associated with the situation at hand, but not considering the middle and late epochs of an EHR can be the beginning of a building tsunami of insurmountable patient information overload.
Quintessentially people believe that an EHR’s function must dictate the immediate needs of the end user ultimately health systems need an EHR that evolves with the volume of data per patient per unit time. Ie: The needs of a provider servicing a New patient with a significant 5 year past medical history can be very different from that of an established patient that has maintained EHR/provider continuity over the last 5 years.
It is the responsibility of the EHR to evolve and grow but is also important for the end-user health system to anticipate the scope and growth of a patient’s health data timeline. Allowing patient data of relevance to be followed while preventing data of lesser immediate relevance from obfuscating the medical record.
While I understand the necessity of some customization of an EHR by a health system, the need for relentless customization maybe a symptom of an underlying health systems lack of flexibility in a relatively new working environment. Careful analysis from the enduser, leaders, developers and engineers needs to be openly discussed AND criticized. There is a very fine balance that must be maintained, it is only through a process of trial & error and open forum discussion like this one that the full breadth of want vs necessity vs evolution can be examined and debated.

Interesting question. All applications have a life cycle and sooner or later an organization's EHR will come to the end. Since EHRs installation or adoption increased with Affordable Care Act and many organization's EHRs are only 10-20 years old, I haven't seen too many switches. However, organizations like Partner's Health in Boston and the Dept of Defense (VA) have found that their home grown systems that they have used for 20-30+ years have become too expensive to support which cause the switch. Hence Partners went with Epic and the DOD/VA with Cerner. I think over time we will see organizations switch their from one vendor EHR to another when the costs of supporting their current EHR becomes too expensive and doesn't provide the functionality and flexibility that it needs. There is some movement on this switch with independent physician practices moving off their own EHR to a larger health system EHR such as Epic's Community Connect program. Better way to share costs and economies of scale.

This is a great question and one that I'm sure has many answers. Abraham mentioned that the switch would happen when the cost of their current EHR is high enough to make a switch. I completely agree with this and think that even large EHR players like Epic and Cerner are understanding the aspect of a (somewhat) affordable EHR and are creating tiered programs for different sized systems.
In the world of mergers and acquisitions, that switch has sometimes become one due to two or three health systems coming together. Here in the midwest, a lot of our health system clients are going through that implementation as we speak.
Outside of this, I think it stems from the advantages that a new EHR poses. Lets trend back to the fee-for-service concept and see that many health systems want to move away from that. If their old/home grown EHR cannot handle complex billing rules or deal with merit-based incentive plans or even meaningful use, that could be enough to get a new EHR. In this scenario an EHR is only as good as how it can report out.
Interoperability has become a hot topic recently but has been in the works for many years now. In this scenario, your EHR is only as good as how it can integrate with other application, 3rd party software or even with other EHRs. The process of continuity of care is very important. The process of integration is very important and if your current system cannot adapt to new technology in an easy way, then that switch will happen.
I think one of the most important is how efficiency is improved with a new system. This comes from both the end user (workflows, templates, documentation, usability, etc) to the patient side (access to records, communication, care collaboration, visibility into billing, etc).

Few industries witness the same degree of outright replacement of a critical application at the rate we see switching of EHR products. It's one thing to replace a product due to obsolescence, cost or longevity but quite another because the product does not meet the business need-essentially buyer's remorse. Given the investment in time, cost and resources a decision to switch is significant for most organizations. If the product can no longer be upgraded to take advantage of new features and functions, is too costly to maintain, has security vulnerabilities, or other significant gaps replacement is in order.
In a recent survey by The Doctor's Company - 54%
of doctors believe EHRs have had a negative impact on the physician – patient relationship; 61%
of doctors believe EHRs have a negative impact on efficiency and productivity; 61% of doctors believe EHRs have a negative impact on workflow; 86%
of doctors reported a neutral or negative experience with EHR vendor service. (see thedoctors.com/contentassets/2...)
This may help explain why we see so much transition.

My own personal experience dictates that health systems have slow seasons. For the east coast that slow seasons starts in June peaks in July/August, the abrupt end is seen in September when it seems like everyone wants to be seen.

Selection of the EHR: January-February: Take into consideration not only the actual cost, but cost of having the services offered fractured amongst multiple independent systems and the associated burden/and associated tangible, Intangible costs. IE: Fax system, document scanning, Billing integrated/separate. Provider and medical professional usability and current user thoughts and opinions

Planning: March-April Including shadowing the patient. Play the role in the current workflow as the patient starting with appointment: scheduling, day of the visit, and Billing. Make sure you account for each of these steps try them with Test patients.
Implementing: June-August (scaling) June starting during the slow parts of the day with select patients and with concrete documentation procedures. Patients will need to be scheduled in both old and new methods. Issues should be worked through continuously, with a follow up QC and QA ensuring that errors are identified corrected and anticipated. By July 95% of the patients should be seen using the NEW EHR; QC/QA should be ongoing with most patients. Finally by August all patients should be seen using new EHR QC/QA of batches of patients should still be occurring. .

This is by no means all encompassing an answer to "When?"/ How more of a rough draft. "When" as in what are the initiating factors, to making the switch done in the (EHR selection/planning phase) . Or as in what I described above the latter ..

While there have been improvements, process issues still exist that make interacting with some EHRs difficult and time consuming for clinicians

Can we expand the question a bit, Ben? The push to implement EHRs has been in place for 10 years, spurred on by HITECH/ARRA funding. Now, some organizations are making decisions on replacing their original EHR systems with new ones. Could we also address special challenges in ripping and replacing EHR systems?

Great point, Fred. So, to some degree the question at hand in that scenario is--what features/functions are needed in EHRs that would drive organizations to rip and replace? In usability, for example, the use of user-centered design principles during both development and implementation can help ensure that the system most directly meets the needs of end users. So, what can organizations do to ensure that their EHRs are implemented to meet their needs (whether a new system, a replacement system, or an upgrade)?

Like what, Jay? What are some of those process issues that you would identify as highest priority?

Many of the current EHR systems were designed as electronic versions of the existing paper/manual processes in an office or hospital. Consequently, there have been limited efficiency gains. In some instances, ordering a test may require more steps than in the past. Some practices even resort to supplementing the electronic process with paper backup. In the rush to implement these systems there has been little done to improve how things are done.

Usability and workflow are interrelated. Often the system is being replaced because it doesn't fit the workflow. Or the practice/hospital is unwilling to adapt to fit the EHR. The replacement must be evaluated not only in terms of cost and functionality but also in terms of how it will be used. That conversation needs to occur before the implementation begins.

I agree with Jay in terms of rushing the implementation process which has restricted the ability to innovate or push product forward. Even a 2 year implementation is not long enough to get a fully functioning EHR at go-live. I believe other challenges include available resources, budgetary restrictions, and time to culture and understand how the data will be utilized in a new EHR. When we saw the transition from fully paper to some sort of EHR, there was an inability to translate all the workflow and processes to an electronic format or even retrofit those processes into a new system. This created gaps post implementation as well the creation of inefficiencies that increased time spent. When you implemented a new EHR from existing electronic formats (rip and replace), data conversion, and the integration of existing solutions became a challenge. Not to mention that the mindset of each end user and the buy-in that much more difficult, specifically if the new system does not function similar to the old one.

Dr. Shah brings up a great point about buy-in from end users. Currently the impression of almost any EHR is that it will "get in the way" of the delivery of care, especially by adding extra steps to get tasks done. Most people seem to say that EHR's are designed for billing, although I'm curious how much thought goes into design for functionality.

I agree with the previous points. Over my 10+ years of implementing EHRs, I find that many organizations focus too much on the technology and not enough on the change management and workflow processes. While also being married to a provider, I see the extra headache and work that EHRs give to providers. Working on charts at night because there is not enough time during the office visit with the patient to complete the enormous amount of progress note documentation and quality metrics reporting. Since the days of paper charts, the amount of data that is required of providers to input into an EHR has probably been 10 fold. While we can automate some tasks in the EHR and try to LEAN down the process, ultimately the main issue begins with the input device given to a provider - keyboard, mouse and at times Dragon. While processor speed and software functionality has increased tremendously these past 40+ years, we are still faced with a keyboard to input and communicate with the software. In the past, I've suggested and piloted a few times the use of a scribe with a provider/physician. Someone who is familiar with the physician practice and understands the specific workflows. We found this very beneficial in Opthalmology where there are 10 minute appointment slots. Until the time that Artificial Intelligence can truly understand the thinking and word actions of physicians, there will always be some form of manual input of data such as a keyboard. Until that time, we should look for ways to quickly automate this manual entry to data. Thoughts?

The use of scribes seems to make sense, until there's sufficient work done to better understand and incorporate better user interfaces for clinicians. What would the ideal user interface be, from the physician perspective? Is there any way around the keyboard, and if you had it to do over, what would be the most efficient user interface?

It's very interesting that Dr. Patel has brought up the aspect that most EHRs are designed for billing. I definitely agree with this one. When we looked at how health systems wanted to become more efficient, utilizing an electronic system gave them the ability to get claims out the door faster, correct charge issues quicker and the list goes on. I can suspect that most EHRs were built with billing as a very high priority. As we now see the transition to integrated health models and value based medicine, I do believe that functionality within the system has become an important factor. Interoperability and care collaboration shift that billing first design to something that has function as a priority. Now there are differences based on size of the system and what the end goal really is. If you are an Athena for example that impact small to midsized practices and systems, billing will always be the main function because thats whats most important. Though, In this new age of Epic and Cerner for larger health systems, patient engagement and end user experience have become more important. Regardless, billing is still tied to every aspect of that as well

With scribes, they definitely help offset a lot of the frustration and challenges with input into an EHR. My work for the past 6 years has been around provider engagement, efficiency and training. Time and time again we see the hesitation to work through an EHR or even leverage it in a positive manner. The success I've seen is with properly training end users, creating workflows that reduce the time in the chart which allow for increased patient engagement. Just with the end user training itself we had seen a few hours of chart time reduction per day. Speech to text dictation such as Dragon has been an extremely great tool to leverage as well. Essentially the ideal interface would be not to enter anything manually at all. If you could voice everything within the patients chart as an option (if accuracy was close to 100%) then it would save the provider hours of documentation time.

To answer the question "What would the ideal user interface be, from the physician perspective? Is there any way around the keyboard, and if you had it to do over, what would be the most efficient user interface?" I agree that voicing everything is really the key. While Dragon has made considerable improvements in this area, there are still functionalities and predictive workflows that Dragon cannot do without some major programming. Technologically, we are making headway, but still some time off from getting to a time such as the Dr. Beverly Crusher voicing medical information/tasks to the computer in Star Trek. :-)

I absolutely agree that the technology component to Dragon is not there just yet but it is a great start. Even with maximizing the current capabilities, I had the ability to go through about 50% of a patients chart without touching a single key on a keyboard, which is not a bad start. Unfortunately that did take hours of creating macros and vocal shortcuts for note templates to make it effective. Also, I was hoping for at least one Star Trek reference so kudos on that one!

Great conversation here, I'm glad to be part of it. From the vendor perspective, one of the biggest barriers to successful implementation occurs whenever there is a failure to align workflows with the technology (and vice-versa). The vendor has to have a deep understanding of end user needs - providers, nurses, billing and admin staff - and the users and their leadership have to anticipate that changes will be necessary. I'm not saying that EHRs are or ever should be an out-of-the-box product, but there are commonalities across clinics and healthcare systems that can be leveraged in the development of best practices. Some of the time savers under discussion here (use of scribes or voice-to-text technology and advanced clinical decision support) have great potential that hasn't yet been fully realized.

Great Comments!
In the outpatient setting some of the things I have noticed is, in the rush to transition to a new EMR, I believe one of keys is the implementation and execution, start very simple. While scribes are great it is important that the provider learns and becomes very comfortable with basic entry before scribes are integrated.
Basic entry of a Diagnosis including their start dates.
Basic entry of a NEW Medication including the start dates and sig. It is also essential for a provider to know how to update or change medication ie. so the updates/change is reflected accurately including the date of the changes. I find that a lot basic entry is done on behalf of the provider and can ultimately be forgotten/never learned. Yearly revisiting of basic practices when utilizing scribes is also an excellent approach.

It's great to hear a comment about the vendor perspective. Current state vs future state is an important process for the vendor considering that every organization has different requirements and needs. The discovery process is extremely important and probably one that either makes or breaks the implementation early on. When I helped implement a lot of behavioral health EHRs, none of them are out of the box solutions and that initial discovery was key to understand complex billing rules and workflows.

Great response! Training is a huge component of a successful implementation. If the end user understands how to input basic information and navigate the chart in an efficient way, then that will help reduce on complications, errors and truly give them a better understanding of the EHR its self. I also agree that best practices must be revisited on a yearly basis. That should also go with training and optimization efforts for the end user as well.

The genesis of a successful implementation can be traced all the way back to the pre-sale - is the client's specialty supported by current state functionality, or are there mutually agreed upon workarounds for perceived gaps. Then comes discovery (again, a two-way street as the vendor learns about the client, and the client learns about the product). Implementation, of course, and then equally important are the post-implementation visits. Call them optimization, or check-ins, or whatever, but it's essential to determine at a prescribed interval whether the client is using the product safely as designed and expected. Following up too early isn't necessarily effective because end users may not have had enough time to start using all the little homegrown shortcuts and workarounds that could be problematic. Allowing too much time to elapse means suboptimal practices may be deeply rooted and more difficult to correct.

Great start to this discussion. My perspective is that of a front line family doc. Have been through this whole transition from paper to EHR. Understanding the burden of the clerical EHR work on clinicians sort of snuck up on us. When fully recognized, it did seem like a crazy thing - sort of like our CEO taking minutes for a meeting. So here at Bellin we did make the transition to advanced team-based care, one part of which was utilizing our CMAs and LPNs to do much of the EHR work including documentation (talk about change management and workflows!) There's a lot we could talk about here, but keep in mind there are two distinct ways to approach this. One is with trained scribes - the other is with up trained staff. The latter is the route we have taken, and we think there are advantages to that in terms of their ability not just to document but to help out in other areas of the EHR, such as pending orders, med review, etc. Agree that docs have to be knowledgeable in all of this, but to be honest, I have lost some EHR skills, such as setting up referrals. Its so nice to go into a room and just focus on the pt, while I hear the keyboard clicking away. Can EHRs evolve to resolve this clerical work burden on docs? Maybe, but I doubt if that is anytime soon. In the meantime, team documentation it is!

In addition to workflow optimization, EHRs should be better able to integrate with behavioral health apps that support the primary care - behavioral health integration (BHI) model. Support for this collaborative approach involves providing adequate and useful biopsychosocial (mind-body-social-environmental) information that enables interdisciplinary/interprofessional teams to deliver value-based (efficient and effective) patient care that demonstrates improvement in patients' physical wellness and psychological well-being for a better quality of life.

You bring up a great point, James, regarding the potential for engaging staff resources to lessen the documentation burden for ambulatory providers. It seems like the requirements for satisfying billing, quality, and regulatory requirements are increasing every year. Ideally, the EHR should satisfy those needs in the back end, without excessive provider keyboard time. But the truth is that can't be done if documentation is incomplete. I've seen clients approach that problem just as you described, by positioning medical assistants and nurses to function at the top of their scope. For example, nurses working inboxes and flagging only what needs provider eyes, and medical assistants queuing up medication lists for provider review. Great time saver for the provider, who can spend more time with patients and less time on routine tasks.

Totally agree, Trisha. We have actually taken our RNs out of their traditional triage role in ambulatory care. They now do most of our Annual Medicare Wellness visits, they do blood pressure followup visits, and basic diabetic ed. They also do most of our CCM and TCM work. They can bill for much of this work, they find that direct patient care is more satisfying work for them, it frees up access to the docs and APCs, and we feel it improves patient engagement and patient care - wins all around.

I'm with Dr. Jerzak. Our experience with 170 rheumatology practices in the RAPP Project was that the physicians lacked the appointment slots and sufficient time within appointments to manage their established patients as necessary. Their tested and implemented practice re-design was for staff to provide separate disease assessment visits to collect and document standardized data sets. This freed the physicians to be problem solvers for more new and established patients who actually needed their attention. So the core problem I see is not with EHRs failing to support practice work flows, but with the traditional work and data flows themselves.
Then the dual purposes of EHRs to document work widgets for billing and to document the caregiver's management process/logic have evolved to be incompatible, and guess which purpose has won. Caregivers can only be effective and communicate our management to one another if we rescue the purpose and content of our practice team's record-keeping from the bean-counters. They made it about widgets because they aren't trained to deliver health care.

Great discussion here. I agree with many of the comments above, but most of all with Paul’s “keep it simple” approach. Unfortunately, with software especially, simplicity tends to be a double-edged sword. The other side of simplicity is a lack of desired functionality. Conversely, the more customizable an EHR/interface, the more complex (read: overwhelming) it is. The fact is that healthcare documentation is incredibly complex, and the needs of various specialties, and even providers within the same specialty, are many and varied. A focus must be maintained on the goal of showing everything the end user needs, and nothing he/she doesn’t. Thus, it’s not enough to be simple – to strike the proper balance, it must be brilliantly simple. It's almost an art form.

Another strong point I agree with is training reinforcement. In early training prior to implementation, the clinicians, having not used the new system in practice, lack context to realize the utility of certain features (especially any customization/personalization options), so going over them again once the provider has been using the new system is immensely helpful in solidifying the basics, becoming more proficient with advanced features, and streamlining workflows.

One thing that hasn’t been mentioned much here is the incredible amount of resources it takes for a successful implementation. It is mind-boggling, and in my opinion, sad, that healthcare systems commonly spend 9 or 10 figures rolling these things out. That’s ludicrous. Costs can quickly balloon out of control, so efficiency is paramount. However, the least expensive option doesn’t always provide the greatest value. The organization needs to be vigilant about hiring (and keeping) people who know what they’re doing. This seems like an obvious general rule, but oftentimes, in the hiring frenzy around implementation, it’s a daunting task to do in short order and is either overlooked or entrusted to an unscrupulous contractor whose only incentive is to bill as many hours as possible for the cheapest (read: ineffective) labor they can find to maximize their margins. It creates a situation where the fox is guarding the henhouse. Avoid exclusivity contracts/clauses with temporary labor suppliers, as the benefits they provide to the healthcare organization are minimal if any, while imposing the great cost of ceding valuable flexibility and independence to efficiently address other needs as they arise.

So every practice has already paid through the nose for an EMR. The challenge is to make it work for the right purposes to pay back the investment, IMHO. In traditional physician-centric practices, documentation for billing is a major contributor to bottlenecking and burnout. Scribes help, but only incrementally.

Care teams that document the right data for high quality care shift about 60% of the established patient work from physician visits, and APPs/nurses perform it when necessary at a lower per patient cost for larger patient populations per physician. They are functioning as physician enablers rather than physician substitutes. The latter approach doesn't work because the division of labor ignores the differing competencies. These advantages work for primes and medical specialists alike.

High access and Treat-to-Target outcomes for more patients at a lower per patient cost = High Value. Leading RAPP Practices implementing population management with care teams have tripled their patient populations and revenues by adding nurses rather than physicians. This approach improves the bottom line whether revenue derives from FFS, pre-paid, or both. Even the bean-counters may understand this advantage.

The important end-user expectations from the EHR products are efficient functionality pertaining to ease of usability within the system and interoperability between systems with other organizations. EHR is the hub that connects the providers and the patients. Hence the design should be "patient centric and provider/ specialty specific" to provide actionable inferences.

A tremendous amount of information/data is generated due to research: a convergence is noted between Genomic data, Bio-Medical Informatics and Population health. A collaborative effort should be made among the providers, vendors, patients, policy maker and health care contractors and other provider organizations to harness this " Big Data" resource and convert
it to an actionable "knowledge base" to derive better outcomes for the patients.

From an end-user point of view the expectations from a designed EHR should be to experience a cohesive interaction between the information flow and the workflow to enhance reliable and accurate decision making process at the point of care within the CDS system of the EHR.

From a vendor's perspective the utmost importance should be to meet the expectations of the end-users and the other stake holders, by designing platforms that harness the data generated from the various data points.

Organizational sustainability is an issue presently due the changes in the compensation model( from volume to value). The ability to integrate an efficient operational cycle with it's revenue cycle management is the key to success. The EHR with applications providing agile architectural designs to provide analytical data in a timely manner will enable correct decision making. The technological advances like AI,ML and NLP will enable process automation and functional augmentation. If successful the process could be amplified. The key to success is the effective collaboration effort of the all the stake holders and the organizational acceptance of the change proce