Geeking Out: Systems Engineering in Healthcare - Part 2
By: Mischa Dick
A few weeks ago, I mentioned the intersection of three concepts we have found to accelerate healthcare system integration projects: Scope, Systems Engineering and High Engagement Change Management. In the last blog I shared some thoughts and rationale of why scope is a key ingredient to successful integration, now let’s move on to systems engineering.
Systems engineering is the discipline of making complex systems work, and healthcare delivery certainly qualifies for being complex. But what exactly is this discipline that provides the technical foundation for this type of work?
In principle, systems engineering concerns itself with optimizing the efficiency and effectiveness of a system. It strives to create a system that delivers the best output while using minimal resources to do it. It does so by optimizing across all the trade-offs that can be made when designing systems. In geek terms, it solves for maximizing (or minimizing) the objective function.
The objective what?
Let’s geek out. An objective function is a model that describes how a system works. For example, we could describe how a Patient Contact Center works. We would gather some information about the tasks, like how long they take, how much inbound work volume we receive and how many FTEs we may allocate to the call center. We can then determine what types of service levels the patients could expect, and we can optimize the Patient Contact Center such that call hold times and overall patient service levels are optimized. To do that, we can change not only staffing levels, but see how bringing automation to play will impact the staffing levels; or, we can determine what work allocation and organizational structure serves us best. That would be the geeky theory.
In practice, things are a bit messier and more complicated though. It is much less about precise models, and more about understanding the principles of systems engineering. Building any system requires making a long list of trade-off decisions, and the systems engineering principles help us make the best possible trade-offs when building the system. In order to make these decisions, step one is to identify what the trade-offs are, and then, we have to be clear on exactly how the decisions to build the system impact us in the long term. To make it even messier, we have to incorporate not just today’s world, but where the world is going and build the future into today’s process so we do not have to start all over again in one to two years. Let’s think about two of many more specific thoughts we have to optimize across in the case of Patient Contact Centers:
- To centralize versus to decentralize? Centralization has many advantages, like easier standardization leading to higher quality, easier quality control, management and training. From a pure mathematical standpoint, centralizing creates economies of scale and via queuing theory, higher service levels for equivalent staff levels. That said, centralization also has downsides, like potential patient inconvenience, negative impact on relationships with patients (who wants to be number in a system), and general disassociation with the mission. Physician perception can also play a role in favoring a decentralized model. With all that in mind, the question becomes less one of centralize or decentralize, but what to centralize versus decentralize.
- To organize for best service level across service line or by service line? The math of queuing would suggest we want to pool resources heavily, meaning, it is advantageous to not separate incoming volume by specialty. This would lead to a lower number of FTEs needed to achieve the same service levels. But, there are downsides. With value based payment becoming a reality, a logical future role and extension of Patient Contact Centers is the integration of care management and network management functions. Specialization better supports the future of healthcare delivery, and can outweigh the benefits of pooling.
In summary, rather than follow the common and technically geeky definition of systems engineering, I would suggest the real value of bringing systems engineering into the healthcare space is this: Outlining the possibilities of different design options, determining clearly what the practical trade-offs are associated with those choices, and supporting the design of the best feasible system design. This brings a calm and rational dimension to sometimes emotional discussions, and leads to far superior, much lower risk implementations. It always lowers costs and increases service levels for patients and physicians.