Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

WellSpan Health has just made the move from Allscripts Enterprise EHR’s version 10 to V11. It’s Go-Live Monday and it’s quiet in the command center. How did we get here? 400 Doctors, 1900 total end users, 4 external MSO sites and 60 internal sites up on the EHR, and close to 40 of them completely paperless. 1pm on Go-Live Monday and we have had 125 calls. That is less than 1% of end users calling in with anything. The calls that we are receiving are typical of any go live. Some PCs were had issues with the Allscripts (ActiveX) controls and end users still learning their way around in a new system. We have entered one support ticket into the vendor. What are the elements that led to this success?

The Client Team

The client team at WellSpan Health is deep, and knowledgeable. They take pride in partnering with their physicians, and the physician partners drive the design of the EHR. The physician champions have been intimately involved in the project from classroom training to Go-Live. Their schedules have been adjusted throughout the course of the project to be able to provide clinical oversight to the build process and to act as liaisons with the leadership team internally with the organization. The build and configure team is made up of multiple analysts, three lead analysts and two physician champions. Some of these team members typically work with other products or in specific areas (with Dragon Dictate, with the practice management system, Allscripts Scan, etc.) but have been brought in to meet the staffing needs of the project. All of the people that worked on the build and configuration, as well as the technical staff and the desktop team have been working in conjunction with each other through the entire process.

Testing

The testing of the system was diligent and thorough. There was one person on the team who was a designated testing coordinator. Testers worked through every workflow used in the organization multiple times. The physician champions worked through their workflows and ensured that they had a through understanding of the system and were prepared to discuss the system and provide support to their colleagues. Their testing plan included 16 people working full days in a lab, hammering on the system. They paced their testing with internal issue resolution – they would complete one week of testing and follow it with one week of internal issue resolution, and then test again. They continued this pattern for 6 weeks. This testing plan allowed for their team to become intimately familiar with the new features of the application and clearly validate their build decisions.

End User Training

End user training lasted for a month prior to go-live and provided many options for learning for individuals with different learning styles. There was introductory information available online and a very clear and valuable webcast for end users designed by the client team. Classroom sessions in a lab were offered in 2 hour session and 4 hour sessions by the education team. The client also created a Citrix training environment where end users could log in and practice prior to the V11 deployment. The week before Go-Live, the education team offered V11 Workshops.

Deployment

The Command Center is fully staffed with help desk staff, analysts, the project manager, desktop team along with the Upgrade Consultant and Upgrade PM. Over the course of the weekend there was a dial-in number that administrators could call into to check the process of the upgrade. There is a three tiered issue resolution process in place and as of 2pm on Go-live Monday, only one issue has not been able to be resolved on-site and been logged into the vendor. In addition to the issue resolution process in place, the physician champions are available today to go directly to practices where physicians would be better served by talking to another physician about the workflow and the presentation of the system.

The client knew that even with the thorough education provided, there would be a learning curve for their end users on the initial days logging into the new system. Provider schedules have been reduced for the week of go-live in order to support the end users and to give them time to adjust to their new navigation and adjustments to workflow.

WellSpan Health is live on V11, end users are in and practicing medicine…and it’s quiet here in the command center. While I am normally a person who thrives on a sense of urgency and loves solving problems – I am glad that today is quiet; it means my client has done a really excellent job.

For additional information regarding Galen Healthcare Solutions’ upgrade / professional services please contact max.henson-stroud@galenhealthcare.com or visit www.galenhealthcare.com/touchworks

Tags: Allscripts Enterprise EHR, EHR, MSO, v11

Research– do your research.  When I first started out as a project manager my sole responsibility was to implement an EMR. I searched the internet and every article I could find where I could glean some advice what was required to successfully implement an EMR.  The time I took to perform this research felt like I was “playing around” until I realized how important the data I was obtaining was going to be to the project.

Compile Your Data – I then took all that data and compiled it into a list of “Steps to Make the EMR a Success”.  I presented this list to the executive steering committee of the project.  I needed to ensure I had captured all the aspects necessary to achieve a successful implementation.  I even came up with a slogan that I taped on the door to my office and stood behind 100%.  “The success of the EMR project is not just up to the Physicians, the Management Team, the EMR Team, Medical Records, the Receptionists, the Nursing Staff or Medical Assistants…It is up to the Entire Practice!” (http://wiki.galenhealthcare.com/Successful_Implementation)

Review Your List Often – whether it is posting the list on your wall, your door or in your notebook it does not matter.  As long as you post somewhere you will see it often and refer to the items you have listed.  Use it as a checklist if necessary.  The idea is not to forget or lose track of all the little things that will contribute to making your job easier.  I posted mine on my wall, next to my project calendar.  I knew that what I had included on that list was vital to truly being successful.

Set Desired Goals – this is not as easy as it sounds, and if you are already started in this process you know that better than anyone how tough it is.  There will be goals as to how your group will require the data to be entered, will text boxes and/or dictation be allowed.  Also set goals as to what your desired outcomes will be.  Do you want to capture 80% of your results directly into the EMR?  These are the kinds of things you will need to consider in the beginning.  I will emphasize here that this is not an easy or quick task that can be completed overnight.  Ask the question what were the driving forces that lead the group to implementing an EMR?  You will use these goals to determine the priority of your focus.

Tags: EHR, Successful EHR Implementation

EHR utilization

Talking about EHRs and their respective utilization is much like making a blanket statement about cars or computers.  It just can’t be done at that level.  There are many organizations that would consider themselves live on an “EHR.”  Truthfully most are somewhat using some EHR functionality.  As humans we only use a small portion of the capability of the human brain and we live normal lives without using the rest.  Most EHRs are used to some similar level but we have a capability to tap into more of that functionality that we have invested in.

Much of this functionality requires that front end effort be made to make the back end benefits evident.  The effort is often not made based on lack of understanding or education of the necessary effort.  Unfortunately, the sales pitch that sold the back end benefit did not explain the detail.  This is not to place blame on the sales person, but to illustrate the necessity to read the manual.

Reluctance to change is amazing.  It is beyond my understanding why as educated adults we think that results with EHR will happen so instantaneously without necessary effort.  Nobody expects it to all change tomorrow, but give it some time it is truly a transformation.  With EHR you can see some results and benefits very fast but making it all takes some time.

EHR projects require such an involvement from both the clinical and the IT side in a world where most things used to be handled on one side of the fence or the other.  Now we are truly working on the fence.  Unfortunately we tend to staff these projects by giving 20-30% of 20 individuals time to the project.  I am not sure how the mathematical equation works but the manpower of those part time individuals, not dedicated to the project often ends up less than the 4 it should be.  Personally I would take 3 teachable full-timers over 20 part-timers almost all of the time.

The way that we implement or utilize an EHR greatly determines its success.  It is a large project deserving of an amount of forethought and effort correlated to the magnitude of the desired success of the project.

Tags: EHR, EHR Implementation, Successful EHR Implementation

More structure and planning help to head off excuses and voluntary non-compliance.  One of the more common excuses is finding reasons the system is less than perfect, ignoring the fact that the system is replacing a flawed system in many cases.  I couldn’t count the times I have spent  explaining “flaws” in a system that were really the same flaws that existed in the paper world.

There has to be accountability for non-compliance with expectations.  Metrics have to be in place to track compliance and remediation has to be in place to assist with compliance.  This needs the appropriate chain of command authority and support.

Here are some thought to promote compliance.

Competition – Use individuals competitive spirit to drive compliance.  Publish compliance success stories that prove utilization is possible which naturally spark some competitive spirit in some, which also is aided by the “un-biased” peer being the one that made it work and can use their clinical credibility to persuade.  Physician Champions are often well suited for this because they have a better understanding of the big picture.

Buttons – Take the time to take notice of what the pain points and satisfaction buttons are for the varied audiences.   If you know what these are the message can be tailored to accommodate the differences.

Piloting – Use piloting to work out the kinks.  If you aren’t sure how something is going to play out in a specific situation, play it out with a willing participant or champion to refine the process before rolling it out in mass.

Tags: Adoption, EHR, Successful EHR Implementation, TouchWorks

Interoperability of EHRs with all of the peripheral devices that make an EHR a one-stop shop that the clinicians cannot live without seems to still be a challenge.  Despite “standards” such as HL7 which define how the systems communicate there still is significant challenge in getting through the projects.  It is by no means “plug and play” and the difficulty is in getting the parties to even have their own version of the standard specification.  The flexibilities of the standards leave some room for interpretation and this is where difficulty sometimes arises.

The desire to freely communicate is not there yet.  When folks start to understand that the end game is quality healthcare and if a system is easy to integrate with the customers will be more happy and everyone wins.  Unfortunately now, it seems that everyone sees integration as a constant revenue generator.  The costs associated are not bogus but without proactive thought to how to make a system be repetitively interoperable there is a significant waste of resources crafting the same wheels over and over.   I have been involved with projects where copious amounts of hours are spent discussing the most basic details of an HL7 interface because the parties involved don’t know anything about the fields or the data.  I have also been involved in the antipodean scenario where both parties show their standard specifications, discuss the minor differences and they agree upon who is going to accommodate the differences and moments later they can send test transactions.

The tendency for integration points to become projects by themselves inherently lengthens the process.  With the lack of knowledge often exhibited on such projects they tend to collect teams of individuals who collectively should have the knowledge to make the integration work, but the points of ignorance of those individuals in other areas exponentially increase the topics of discussion that are in play to educate everyone involved.   This becomes very annoying to the individual that has their stuff together on the the other end of the integration.

The challenge to healthcare organizations is that the complexity of the EHR is not only a complex IT project but one that also demands a clinical understanding to help with all of the integration.  Clinical organizations are required to have resources that are more technical and the technical resources have to have clinical knowledge about what they are doing.  It is extremely difficult to complete a lab interface if you don’t have the knowledge of how to flip the flags and when to flip the flags.

The resources involved in integration need to step up and take the time to learn what they are doing rather than spending one hour a week trying to make something work.   Know your part and then some and don’t waste others time.  If you know what you are talking about and what you want the efficiency of the process is greatly increased.

I argue that a clinical organization that takes the time to acquire or train an individual that knows their business on integration will recover his/her salary multiple times in EHR efficiency, buy-in and ability.  I have seen organizations where they pay both vendors $30,000 to complete 20 integration points, why not pay one individual $60,000 for 10 years or $100,000 for 6 years.  I have seen this work.   Once you have the individual on staff the integrations become easier and easier and even a small interface that only aids a few clinicians is now justifiable.

There are other staffing changes that seem and are significantly different, but when you compare them to what you might spend paying to have the work done elsewhere, they make sense.

Tags: EHR, EHR Implementation, Interoperability

Mandated functionality use with a Live date without a plan to get there are begging for user adoption failure.   There are few organizations that have the ability to staff “Big Bang implementations.”  Whether big bang or some portions of the functionality, I think having just a live date can be very frustrating for users.  There are several factors coming into play on effective EHR adoption of functionality that are not accounted for in a situation where there is only a Live date and not a plan around what “Live” means.  For instance if we “go-live” on e-prescribing, what does this mean?  Some groups never define what this means and get several flavors of compliance or non-compliance.  What does it mean?  Does it mean that every patient from go-live forward will have a complete EHR medications list or all new prescriptions will be ordered from within the EHR or does it mean that the module is now available for use.   Come up with a fair solution that enables compliance without setting an expectation that is not realistic.

There are variables which vary by practice type or specialty affecting what makes sense for the implementation or adoption of functionality.   For instance, if I see 15 patients a day the expectations could be different than someone who sees 40 patients a day.  Some more variables include the first which I will call “Patient Repeat Value” or PRV a ratio that has to do with how often patients will return for a visit defined by number of visits divided by number of unique patients over a given period of time, and second which I will call “Patient Population Cycle Time” or PCT is the amount of time it takes to cycle through your active patients.

Volume is more obvious so let’s look at PRV.   If a clinician sees 40 patients a day but his PRV is high any pain associated with new functionality that is driven by items that are maintained list such as the various items on the paper face sheet like medications, problems and allergies will be more short term than someone who has a lower PRV that sees the same patient load, because they have a larger population and ergo more lists to maintain.  PRV may not be as relevant in items like electronic noting where it comes down more to practicing and repetitions to become efficient.

Let’s look at PCT as it applies to the first go-live of the EHR.  The best way to explain how PCT comes into play is that it makes every patient’s first visit in the EHR almost like a new patient visit.   We know that visits for New Patients typically take longer and their appointment times typically plan for this.  A logical conclusion from this comparison would be that schedules need to be changed to accommodate these “New to the EHR” patients.  If the PCT is 60 days, like it might be in an Obstetrics office or perhaps even lower in a Nursing Home, it could be practical.  However in Family Medicine it isn’t practical if some of my patients might not come in within 18 months but they are still considered active patients.

Since all practices aren’t created equally with regard to these variables it isn’t realistic to expect the same results from different groups.  Required utilization should be mapped out to accommodate the differences.  Come up with a strategy that allows the practice to step through to full utilization.   Sometimes it is simply something like applying the new functionality to every third “New to the EHR” patient for 60 days and then you’ll have a majority of your visits utilization compliant.  In other situations the logic is broken down by seeing different appointment or patient types initially and then working into the other types as you progress.  The main logic is to come up with steps that are easier to swallow than doing everything different than what was done yesterday.

Worth equal consideration, is a realistic timeframe for supporting an in progress EHR.  We have to coach the users through the implementation, to do more than what they think is possible.  Having an approach just as defined above will serve as the roadmap for the end user to get to some where they have never been.  Having never been there they don’t know what to expect.  Users can’t be allowed to always take the easy way out.  This sometimes involves repetitive reference to the gains and benefits that will be available.  If you don’t get the medication lists and problem lists in for the patients, notes can’t automatically cite from these lists etc.

Tags: Adoption, EHR, Successful EHR Implementation

We recently did a presentation at the Allscripts conference titled “Your EHR is Live.  What’s next?”  To me it seems like a fairly simple concept, but I am amazed at the applicability to most groups using an EHR.

The simple concept is around optimization.  The initial push of the implementation is to meet all of the vendor milestones and accomplish all of the things that were decided way back when.  This often seems to leave some low-hanging fruit.  There are varying reasons these exist.

Often, the reason is what we know now, doesn’t quite line up with what we thought we knew or understood then.  It may have been a lack of understanding or possibly that some additional people weren’t in the decision process.

Another reason is the learning curve is limited by the “go-live” timeframe.  Some of the users aren’t as quick as others and they learned what was required but nothing beyond.  The EHR might be just one of the changes the users are currently absorbing.

The number of reasons could go on and on.  The reasons aren’t as important if you are already using a system.  If you aren’t you might want to ask others what they might have done differently.  The next step is what’s important.

I was introduced to the term “process re-engineering” some time ago and have been continually process re-engineering my life since that time.  When going through the implementation process to bring up an EHR, we often duplicate bad processes in the EHR because we don’t see the opportunity to improve other than the technology.  When I say we don’t see the opportunity, it could mean a couple of things.  One might be that the build team asked “How do you do it now?” and never examined if that was the best process.  The other side is that those answering the question don’t understand the technology available to know how to improve the process.

I recently came across a group where everyone is “e-prescribing.”  Interestingly there are several flavors of how “everyone” is accomplishing this.  There are some who are writing everything on paper as they always have done but now also entering the information into the computer.  There are some who are writing all of the prescriptions in the computer and printing them all out.  Both of these have missed some of the efficiencies of e-prescribing.  Among the efficiencies, are the medication list and allergy/DUR reconciliation that these two examples are gaining.  However, they are missing out on the delivery efficiencies available, as well as not using paper and incurring those costs.

I would suggest that groups schedule periodic process improvement evaluations that look at utilization, efficiencies and priorities from a technical and clinical perspective.  The main focus should be to get the most out of the systems in the most efficient manner.  Here is a list of some of the questions that should be asked?

How are you using the EHR?
What are your challenges with the EHR?
What are possible solutions to the challenges?
What would make the EHR most valuable to you?
Has the EHR made you more efficient?

Work with those that are having challenges, often the learning curve is what is holding them back.  They want things that are already there, they just need education on how to use the features.

Additionally study some individuals to see how they are accomplishing what they are doing in the system.  Use this to compare it to “best-practice” not as a tool to reprimand but as a way to show them the easier way.

Tags: EHR, EHR Implementation, Successful EHR Implementation

When implementing new software, organizations understandably focus on the short term goal of go-live, but taking a more long term approach can actually lead to less work, a smoother transition and better results. Here are 3 techniques to accomplish this shift.

Know the software – cold
Don’t try to imagine or decide how to best configure the software for your workflow and then build it. Instead build test components (worklists, views, menus, etc.) and then bring that knowledge to the decision process. Divide the build tasks up and assign to teams. Each team should include a leader with build access and a few advisors with clinical workflow experience. Build the examples in our Wiki or provided by Allscripts or make up your own. The other team members should watch the build process and ask questions. This will give them firsthand knowledge of what can and cannot be done to better inform their decisions and allow them to translate to the larger user community. It does not matter what you build. The goal is to get familiar with the options and limitations. This will allow the team to use a more creative approach to the build. It is easy for a team to get bogged down in deciding what will work best for their providers and  delay the actual building only to discover a better approach after they get started and are short on time.

Don’t assume the end user always knows what will make them happy
Build decisions often involve a compromise between the experience the end user is requesting and other concerns such as patient safety, workload for IT support staff, etc. Teams often focus on finding solutions to these conflicting needs without first considering the underlying assumptions. A user may be insisting on a particular workflow or other requirement because they are unaware of all the options that are available. Allowing end user representatives to observe the actual build work is one way ensure that they know all the options and enables them to help find creative solutions to the software’s limitations. Observation is another useful method. In an article about the innovative design firm IDEO, author James M. Pethokoukis gives an example of how direct observation can yield new insights:

….IDEO general manager Tom Kelley gives the example of working on a project with the SSM DePaul Health Center in St. Louis to revamp its emergency room. One approach the firm could have taken would have been to quiz a bunch of former patients on their experiences.

While there is much to be gained from carefully constructed interview questions, IDEO understands that self-observation does not reveal the whole story.

The article goes on to explain:

For instance, one IDEO anthropologist pretended to be a patient and managed to videotape his entire emergency room experience. One realization: While the admitting and treatment process might seem logical and orderly to staff, it appears chaotic and confusing to patients. So IDEO created a simple “map” that the hospital staff could give each incoming patient outlining the seven steps of the emergency room experience, starting with the triage nurse. It also recommended cards that each member of the staff could hand out so the patients could keep track of who’s who. “They understand that creativity had to be provoked and fed,” says Robert Porter, who has twice worked with IDEO, now as head of strategic and business development for SSM Health Care-St. Louis, part of one of the largest Roman Catholic systems in the country. “They understand that you need a messy process to gain consumer insights.”

A similar approach can be applied to EHR implementations. Including users in configuration decisions is a good first step but direct observation can lead to a more thorough and accurate understanding of the workflow. Have end users demonstrate their workflow in the office and trade roles to understand the handoffs and risks. How are transitions handled? Who logs in and out and when? Can the patient see their chart?

Use an iterative approach
The goal of your team should be to get as many team-members familiar with the application options and limitations as possible and to have at least one build expert for each area. The nature of software is that most people find the conceptual structures and relationships difficult to learn but once they know them it is very easy for them to build, edit and rebuild as needed. The organization benefits most if the team members understand the software itself rather than just the one or two configurations the organization has chosen. An iterative approach provides this type of knowledge allows for more creative solutions and encourages reevaluation. After each team has built practice configurations, have them regroup and decide on the baseline enterprise level configuration. Keep this initial configuration as simple as possible to allow for thorough testing and minimize complexity during and after go-live. Once the system is live and users have had time to become familiar with the baseline configuration, they will be better able to contribute to the next round of improvement.

The transition from paper to an electronic workflow is more than just translation; it is a creative process that leads to new efficiencies and improved experiences for both physicians and patients.

Tags: Allscripts Enterprise EHR, EHR, Successful EHR Implementation, TouchWorks

I worked with a large group who had been using TouchWorks for a year or so, after converting data from their previous EHR (a predecessor of TouchWorks). The conversion brought their Problems into TouchWorks; however, the problems were viewed differently and were now also viewed and managed by physicians, rather than only the nursing staff. While these changes were generally fine, the personal and family history that they had captured on paper, then showed in their old EHR, now cluttered patients’ problem lists – they had 10 copies of “Coffee Consumption” or “Denies Drug Use”. They also commonly had patients with duplicates of other problems as these didn’t appear as duplicates in the previous EHR.

We spent a few weeks designing a neat de-duplication process. I’ll spare you the details, but it went along the lines of finding problems of the same type, status, category and view. We’d take the oldest entry and keep it. We’d mark the rest as Entered in Error; however, we didn’t toss them away completely – we’d store each problem entry as an assessment on the first problem entry so you could always view the problem details to see the Audit/History.

We also took out some other attributes of the converted problems, such as the category of History Of for every problem and comments that the physician group thought might be useful.

Before I continue, I have to say – both the physician group and those assisting with the conversion (at Allscripts) did a great job of converting the 12 years of electronic charts (about 2MM patients). I think the biggest issue was the group not having a year’s experience using TouchWorks to make some of the decisions – hindsight is 20/20.

Luckily, we had the ability to make corrections as we went. We were able to convert millions of problems, removing duplicates (while maintaining their history!) and saving the clinicians a great amount of time and frustration. An internal medicine doc remarked that it saved him somewhere in the area of 100 hours of effort (not to mention the gray hairs).

I wouldn’t say we did anything extraordinary, but just had the luck to work on a fun project that helped out a couple hundred nurses and physicians. And hopefully make their transition to a (full) EHR a little more pleasant.

Tags: EHR, Technical, TouchWorks, TouchWorks Problem

Labs require that you provide them with the type of billing, and the insurance info if they are to bill the insurance company.  Sending this information with Allscripts Enterprise (formerly TouchWorks EHR) requires consideration of work flows and design.

Insurance information is easy with Enterprise – you store the insurance with the patient’s record from the Practice Management System (PMS), and then send it along to the lab with each Order placed in Enterprise.

Bill Type is pretty easy too – for the majority Orders that are placed.  Most clinics have certain rules that govern the insurance to be used.  It can be as simple as the clinic always bills the patient or their insurance, or they always have the lab bill.  There are times when the insurance or the order being placed may contribute – sometimes this logic is built in to your interface, other times it’s not deemed worth the build effort.  And, there may be other factors – such as the patient indicates that the reason for their visit is due to an on-the-job injury (Workers Comp).
I have not found a great solution for handling the exceptions, but I did see an interesting solution a few months back that works pretty well.

A group I was working with stumbled upon the Special Billing (aka Injury Type) dictionary and asked if we could use it.  We thought about it for a bit and it seemed to meet a lot of the needs that we had:

1. No impact on other modules – for them, and perhaps not for you, they did not send Special Billing information back to their PMS.  This is the only standard use for Special Billing information.
2. It affected all orders on a particular encounter – in their case they knew that all labs should be billed by the lab, except when they shouldn’t.  They could not determine the rules for exceptions from talking to the clinic – the employees there said they just knew when the clinic should bill and all orders for the encounter should follow that exception.
3. It was sent to the ConnectR interface.
4. They could create their own entries – such as “Client Bill”, “Third-party Bill” and “Patient Bill” (the three values the lab would accept).

Then we were on our way – a small change to the interface to override the logic we had built based on Special Billing / Injury Type, if it was set.  They added the appropriate entries and trained the users to pop in to the Encounter Form and set the Sp Billing value to “Client Bill” if the clinic should charge for the blood work.  It’s a great solution for groups that are otherwise not using Special Billing in Charge.

Tags: EHR, Enterprise Order, TouchWorks