Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

Synching of results in Allscripts Enterprise EHR v11 has been both very appealing and difficult for many to understand.

The premise is this – if a patient has a test done over time, you would like to compare the results – in HMPs, flow sheets and result history.  If the lab changes the code used for a particular result (as is common), or you send the same tests to multiple labs (also common), you need a way to link those separate resultable entries for comparison.

Recently, we had the chance (a client of mine and I) to speak to some folks at Allscripts – their clinical architect and the product manager for Order.

We had two basic questions:

1. Should we synch our results?
2. If we don’t synch, then what?

Ultimately, we chose to use “Considered equivalent” mapping that will be fully functional in a later release – perhaps as soon as v11.1.7.

The details of our discussion should provide insight on the decision that we made.

Should we synch our results?
Ideally yes, the Resultable Item Dictionary (RID) should be setup similarly to the Orderable Item Dictionary (OID) – with one master RID entry representing any equivalent RID entry.  The more lab vendors you interface with, the more important synching becomes.  Synching will make your the HMP, flow sheets/grids, graphs, and historical results display on one consolidated line and look great.

The reality is, that over time, lab vendors will change resultable codes (INR from 1/1/08 – 8/30/08 = code 12345, from 9/1/08-12/31/08 the INR code = 56789).  Since you can only have one RID entry per Requested Performing Location you would have to go update the INR synching to use the 56789 code to represent new INR results.  This means that if you are looking historically at a patient that had a PT INR in March and a PT INR in December their INR results would display on two lines even with Results synching. (See grid below)

If we don’t synch, then what?
Allscripts is planning to use the “Considered equivalent only for flowsheet graph:” (which can be set up in the RID entry) to do basically the same thing as the synching, but this would allow you to synch as many resultables as you want together (not just one per result per requested performing location).  The plan is to have the “considered equivalent…” consolidate results in the HMP, flow sheets/grids, graphs, and historical results.  So, even though ideally right now synching will help you consolidate line items it looks like the need for it will be obsolete in the near future.

We’ve made the decision to go ahead and use the “Considered equivalent” setting and hold off on the results synching.  We hope that in the future all of our needs will be met with the equivalent mapping.

This is high level summary of the discussion that we had.  If anyone is contemplating synching and you have any questions or would like to discuss further, please leave a comment.

Tags: Allscripts Consultants, Allscripts Enterprise EHR, Results Interface, Successful EHR Implementation

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

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

I have worked on many projects with the objective of implementing an EHR.  It seems that somewhere along the way, the goal sometimes gets lost.  Yes, from an IT project perspective, sometimes the goal is to get the EHR live, however healthcare organizations should not have EHR projects with the goal of “getting an Electronic Health Record live.”

They have to go back to the reasons why the project started.  What were all of those questions or requirements that were in the RFP or search process, that get out of focus?  There are now government organizations and others with initiatives to help encourage EHR adoption which can be interpreted hundreds of ways.  It sounds dreadfully obvious, EHRs exist to improve healthcare in many ways and those are the reasons for the projects, not the implementation milestones.

As part of an organization with a large focus of helping healthcare organizations embrace technology to improve patient care, I often find myself reminding myself and others why we are doing what we are doing.   Admittedly it is easy to get caught up in the race to the finish line.   If the light at the end of the tunnel doesn’t remain the target it becomes easy to make poor decisions along the implementation path that drastically affect utilization.

Cost reduction, efficiency gain are often a large part of the focus, but properly implemented EHRs can enable more thorough, compliant and consistent care.  The accessibility of the information available in a properly implemented EHR  to individuals within the healthcare organization can be phenomenal.  Once organizations realize the magnitude of the data available, the old reporting mechanisms and their data become minuscule compared to the power of the discrete data in an EHR.

Problem list population can be overwhelming, but on the back side, order entry can be achieved much easier if driven by the problem lists, notes can have problems automatically cited,  health maintenance can be driven by these problems etc.

I could go on with a many more examples and don’t contend that an EHR implementation can take place without the IT folks, but want to do everything to make it clear that we are implementing EHRs for healthcare and the technology is just what gets us there.

Tags: EHR Implementation, 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