This post relates to a previous post of Why EHR implementations fail and is offered to "bridge the difficult gap that exists between business units and IT". See What people say about what I do in the left column.
This suggested approach provides the business (those who perform the work) with a means to manage and control process execution while slowly moving towards implementation of an EHR/EMR. This approach seeks to drive technology selection from a basis of a well-informed staff using a well-developed, proven process improvement methodology.
- Interview staff (preferred anonymously) and determine current problems related to patient care and safety. Rank the problems
- During interviews ask participants how they would address the problems. Use suggestions as input to a process/performance improvement effort.
- Develop a running list and note if EHR or functions of an EHR are among the needs defined in the interviews.
- As part of the interview, ask how they rank EHR as part of a solution suite. Ask staff to list the 5 most important elements of what an EHR/EMR application must provide in order to be “useful”.
- Subsequently, determine if current issues can be addressed with process/methods changes or introduction of “easy to use”/simple tools
- Create a collaborative framework or system architecture within which people, processes and technology can be “mixed and matched” and applied to problem solving.
- Solve a few problems to demonstrate how process changes can provide benefits to staff. Continually determine if solutions are providing the intended benefits.
- If EHR does not show up well in rankings (item 3), but is envisioned to be necessary in the long run, develop a multi-year roadmap that addresses immediate needs, but points the organization toward this goal.
- Gain the support of staff by demonstrating consistent ability to deliver solutions (people, process or technology) and by integrating staff into decision-making. Educate staff about process, process change, utility of technology to support change, etc.
- Demonstrate how individual functions of EHR fit into the framework, how these functions extend the benefits of previous process changes, how the tools supports the needs in Item 4, and how these functions decrease workload.
- Conduct a series of informational efforts, demonstrations of EHR/EMR, team conversations, etc, to vet potential applications.
- After staff becomes familiar with all aspects of EHR, how it will work in their environment, how they will benefit by its use, a team creates a requirements document that forms the basis for selecting a tool.
- Begin implementation following a well-developed plan managed and controlled by user organizations.
The alternative:
Management, feeling pressure from external sources, tells IT to find an EHR application that is not too expensive. IT asks a few staff members what might be good, and buys an EHR application from a salesman who assures them that it is easy to use, has already been implemented in many different locations, and is the most cost effective application among many competitors. IT selects application A since XYZ hospital bought it and “they must know what they are doing”.
I think you've created a really great list of things to check off when deciding if EMR is the right option. I couldn't agree more with your overall point that it is important to involve staff at every level (those who are most likely to use it) in order to create a custom system that will work best.
Posted by: Nina | February 02, 2011 at 03:59 PM
Thanks for your comment.
I am considering expanding on this and possibly creating a guide of some kind.
My experience suggests that not only do you include staff at every level but you will need a person who can manage the interface between the staff and the IT department. In general, staff (or the business unit) typically don't understand IT and IT doesn't understand the staff. The interface can be difficult, and the staff often don't have the time to deal with it.
In the big picture, the focus should be on managing and controlling interfaces at every level (within a process, process to process, people to process, technology to process, department to department, etc,)
My sense is that there are more pressing issues at this time than EMR. Often, problems revolve around "can't find stuff" or using the wrong stuff. These normal process issues should be addressed first, before launching into something big.
Posted by: kevin | February 02, 2011 at 05:26 PM
Merci à l'auteur de ce post, si heureux Im que j'ai trouvé un des sujets très utile ...
Posted by: casino | May 09, 2011 at 11:34 AM