Build First – Ask Questions Later


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.

Facebook Twitter Email

1 comment

Add yours
  1. 1
    Keva Ambre

    I just wanted to comment and say thank you for the great article.

    I am gearing up to implement a software release that will transition our process from a paper to an electronic workflow. I came across your blog during my research (keywords: ideo software implementation plan). I most appreciated the team approach to the build. Good stuff to think through.

    Thanks for the solid ideas!

+ Leave a Comment