Site icon IT World Canada

HIS/EMR replacement: Peeling the onion early to avoid tears

Shutterstock

People working on technology projects will understand the analogy of peeling the layers of an onion.

Typically, when used in reference to projects, this refers to additional details being uncovered that weren’t initially considered. The onion analogy is apt because newly uncovered details rarely yield pleasant surprises, they usually bring tears.

Discovering new details after a project has begun is fairly common place. The Project Management Institute, PMI, has a specific term for this phenomenon. It is called progressive elaboration. To put it another way, uncertainty is at its highest at the beginning of a project. As the project progresses more details are uncovered and the project acquires greater certainty.

This is progressive elaboration or peeling the layers of an onion. An HIS/EMR replacement is a significantly complex project. The magnitude of change goes beyond a single onion, it is more like a bunch, or in some cases a field. But there are ways to minimize the tears that come from progressive elaboration. It begins with organizational decomposition.

Many HIS/EMR vendors recommend leaders being part of the project delivery team. Leadership is certainly important and leaders are integral to successful delivery. However, in large complex institutions such as hospitals, relying solely on leaders to provide software projects the detailed information that is necessary for project success creates project risk.

Many hospital leaders have a large organization to run and rarely can be spared in a full-time capacity. Assuming a leader alone can represent their entire organization and all the detailed interactions, processes and forms is in essence handing the project a bag full of onions. Hospital leaders rarely know all that is involved in their day to day operations. How benefits are applied in the payroll system, or how patient notes are communicated during bullet rounds, or how bed boards are updated are all details necessary for project success.

Leaders are often too far removed to know these specifics. This isn’t neglect. In a funding climate that expects hospitals to do more with less it’s necessity. The detailed processes, system interactions and standards of practices are where the layers of the onion live. Where leaders can help to minimize the tears are by helping decompose their organization into smaller units.

 

 

The above cycle highlights how a project can manage organizational decomposition. Defining the in-scope areas. Engaging the areas in decomposition exercises. Acquiring support by decomposing organizational units into sub units and finally into discreet processes. The acquire step also refers to the acquisition of process experts that will help map current state processes and identify system needs. Validation is the review of documentation and agreement. This begins to build ownership as well as a partnership between operational and project teams.

HIS/EMR vendors often apply gross categories to their implementation such as finance, emergency department, patient movement, etc. But consider finance for a moment. In a hospital finance can be comprised of many more sub-units.

Each ‘tower’ organization in a hospital are similar in nature. The above illustrates a ‘simple’ decomposition of a finance department.

This is where leaders are instrumental. They know their organizational structure and can bring the right people to the table. Each organizational unit will have a lead. The project then assembles unit leads in an interactive session where they identify discreet processes and process owners. This will help the project build an organizational decomposition road map.

 

The output of the leadership meeting will drive a schedule of current state process mapping. The following illustrates a breakout of a single organizational unit into discreet processes.

The discreet processes enable the project team to build a schedule for current state mapping with the appropriate process owner.

Through the course of process mapping and requirements gathering system needs are captured for future use. The following illustrates an example of process flow that highlights the people and system interactions in carrying out a discreet process.

The following highlights a requirement capture tool for each process step(s) and key considerations for new systems or improvements.

To put into context for an HIS/EMR replacement project I had recently participated in the above process yielded near 500 discreet process flows along with over 1,000 unique requirements. This output only represented the back-office operations of the hospital! The exercise in its entirety yielded more than double for the entire organization.

Decomposition supports multiple objectives. Project teams are often external resources. Decomposing operational processes both build relationships and an understanding of business operations. It enables the project team to become advocates for the business. This is often integral to project success. HIS/EMR vendors are often experts in their product. They are not experts in a specific organization. The decomposition bridges the gap between current state and future state and helps identify those details that if found out too late could generate issues, or tears, associated with peeling back the layers of an onion.

Decomposition will not eliminate all the tears associated with progressive elaboration. Hospitals can have processes that have been in place so long that even front-line resources are not sure about all the details that keep things running smoothly. But decomposition will eliminate missing the larger items. More importantly it involves operations and creates a sense of ownership. If layers of the onion reveal an obstacle it is a shared by both operations and the project. With collective ownership the teams can work as one to find solutions. Something that will be important for later stages of the project during implementation and adoption.

Exit mobile version