Driven by Meaningful Use Incentives, many US hospitals have rapidly deployed enterprise class solutions to support EHRs. The enterprise software vendor, such as Epic in my experience, typically has a proven approach and work plan that covers 75 percent or more of what most organizations require to get up and running. While the EHR moniker seems to have stuck, these products are much more than electronic health records, supporting end-to-end business, financial, and clinical processes for hospitals, physician practices, and a growing number of specialty functions. Implementing these solutions truly takes a village.
One common approach is to enlist project team members from among the clinical, administrative, and financial operating areas of the health system. These individuals for the most part abdicate their operating roles, matriculate to IT, and engage in vendor-specific training that enables them to configure the software solutions. Meeting the minimum staffing requirements can create operating budget challenges as employees shift onto the project and are backfilled in the operating departments. The experience brought to the project by these employees from the operating departments is a huge factor to the success of these projects.
Most of these implementation projects are intense, highly structured, and targeted relative to go-live dates. But what happens after the dust settles and the champagne dries? What happens when the big project is over and the sun is no longer blocked by the mega enterprise implementation project? Recall that it has been 18-24 months since these folks left their jobs in the lab, nursing, registration, HIM, etc. The project budget often shifts from capital to the IT operating budget and the nature of the work changes to optimization and cyclical enhancements, along with periodic upgrades.
The standard organization chart for an enterprise Epic implementation is, by design, rather flat — the focus is on concentration of skills set on specific modules in application analyst roles and does not naturally lend itself to the notion of leverage or project oversight. Individuals who are skilled on a particular module are not often engaged on the bigger picture of the operating model. While this structure works well for Epic initial projects and upgrades, the nature of the work across the health system — and, consequently IT — becomes less singularly focused on Epic after go-live. Ongoing optimization and smaller projects generally require project management skills for senior leaders (manager and above). Unfortunately, project management skills are not commonly found in individuals who matriculate from operating areas to IT.
More mature IT organizations acknowledge that there are clusters of applications that share common attributes by being upstream or downstream in the workflow, or by being similar such as specialty modules for ancillary departments. Coupled with some cross training, clustering can reduce the number of individuals on call each night as well as give individuals a view of related modules. Some IT organizations with the leadership and methodologies have experienced success in developing project management skills in some of these employees.
Within a year of the implementation of Epic at our second hospital, we transformed the IT organization. IT 2.0, as we called it, dealt with matters outside of IT such as governance, intake, and extending the planning horizon with road maps. Equally importantly, as part of IT 2.0, we reconfigured our organization structure to put an emphasis on the solutions we were providing to our customers. As part of that, we demoted use of the term “Epic team” and promoted the use of alternate team names such as “Patient Care Solutions” — a portfolio that included Epic and non-Epic applications.
Prior to the acquisition of our health system by a large academic medical center, we worked with our HR business partners to develop the concept of career ladders as a refinement to our IT 2.0 program. Well-run IT departments target job descriptions and career development opportunities around the mainline path for those aspiring to be a CIO. In light of the infusion of non-IT resources onto these enterprise projects, it is important to consider how to make the most of this talent while evolving to meet the needs of the enterprise after go-live.
The tree diagram to the left depicts a proposed career ladder model that suggests that the manager level is an important check point. Some individuals are incredibly talented in a clinical or technical area, but are just not interested, or not good, at managing people. Specialist tracks parallel to the manager position on the wage and salary grid may be a good option for your organization. These roles put the focus on the unique contributions of these individuals, allowing them to continue to advance their careers while being productive on project and optimization work within IT.
Over time, individuals on the specialist track advance through promotions in parallel to the main line. For example, Technical Specialists to Senior Technical Specialists, and eventually Technical Fellow as seen in some large organizations. Similarly, Clinical Specialists to Senior Clinical Specialists and Clinical Informatics leadership positions such as CNIO. Capacity in these alternative career ladder branches is limited as compared to the bolas that gets recruited for the initial EHR implementation project, so expectations need to be managed.
Career mobility is the concept through which individuals, usually in larger organizations, have the opportunity to move laterally into another part of the organization in the interest of pursuing career advancement and/or developing new skill sets. Individuals who move onto an enterprise project like Epic EHR get tremendous experience. They are certified in one or more modules and have been highly sought after by consulting firms of all shapes and sizes. Embedding these individuals back into the operating departments can also be a good move, subject to role definitions on important topics such as controlled access to the production system. Part of your retention strategy should include a thoughtful career ladder structure.
This framework also lends itself to pay for performance. At each level of the career ladder, you can define roles, responsibilities and related metrics. This level of clarity supports more objective banding of new hires along with managing expectations of current employees about what they need to do in order to be considered for promotion.
Your enterprise implementation project has “blocked the sun” for the past few years. Consider how you can reconfigure your IT organization to ensure retention, productivity and employee engagement with career ladders.