Why Your Operations Team Needs To Spend Time On Innovation

Innovation Spend

One of the biggest challenges in healthcare, actually with almost any business, is working with and relating to others; which we happily call leadership.

Some leadership challenges are created because of external factors, interpersonal relating and company dynamics. However some leadership challenges are self-created.

Case in point is operations and innovations. Often a team that is focused on day-to-day operations is the last team you would tap in order to spend on innovations. Instead companies bring in other teams, which creates a massive divide between operations and innovations even though they can help fuel innovation faster than it would on its own if properly aligned and led.


They know the existing challenges

You should always involve your operations team in innovation, and give them time to actually work on those innovations. In the software development a popular method is 20% time whereby a developer will spend 20% of their time on innovative and new projects to help keep their skills sharp but also help propel their team and company forward.

This is key as the same team operating the day-to-day to keep your trains running on time really understands the challenges they face and often have thoughts about how they can be addressed. But even if they don’t, being able to articulate the challenge to a team that can innovate is extremely important, it is half the battle of coming up for a solution.

They have ideas to fix it

More often than not your operations team has solutions, even more astonishing they probably have already developed work arounds for those challenges they have and are either just unaware they can be resolved, don’t have time to resolve them or feel that they will not be heard if they voice those challenges.

Make no mistake though a work around is NOT a fix or a solution; it may be a great stop-gap temporarily but long term you leave the organization exposed.

These work arounds though are helpful to any team innovating and more often than none can lead to a solution that not only solves that challenge but sheds light on the real challenge at hand.

They have access to the tools

One of the largest areas where innovation teams clash with operations is getting access to tools, data and applications they need. Often the operating team will push back stating they require a project plan, and what if something goes wrong, or if they accidentally mess things up.

At first these concerns can be seen as a way to sabotage a project however a different perspective is that they are truly concerned about the challenges they have. If a system already has stability issues, or if they have had challenges with it in the past and they know all the work arounds and fixes for it however this new incoming team has no knowledge of that.

This comes back to leadership and how the groups came together, this can be avoided if both teams know what each is working on, and both involved, then they will move as a united team.

They know what success looks like

This is perhaps the most important part of the entire article. Your operations team knows exactly what success looks like and can help articulate that to both your senior management, internal teams and even the innovation team.

In order to actually achieve this you must lead your team properly through the transition, and involve them in innovation from day one.

Your Analytics Software Is Creating Another Silo

Data Silo

In healthcare the current hottest trend we see is analytics software that seems to have the promise to do it all. Often times Integration Engines, HIEs and Population Health Management is also thrown into the mix to confuse things even more. Regardless of which you are looking at, we are going to call these “Analytics” software.

Don’t get us wrong we are not against any analytics software, however we are against the case for yet another silo to be created, but this can be managed!

The Value of Analytics

Analytics comes in many flavors, and this post is in no means meant as a comprehensive cover of such. You have everything from Machine Learning, AI to specific needs such as SEPSIS or HEIDS measures.

The value for analytics is broad and will largely depend on your needs as well as outcomes you are looking to resolve, which is exactly what it is intended for.

The Shortcoming

However that being said there are a few challenges with analytics as they stand today and ideally you want to avoid making these mistakes as they cost time and money down the road. The major shortcomings are:

  • Since there are so many options and each one takes a major integration effort to address, its hard to pick the right analytics software
  • All of them create another silo for your data, but they have to in order to provide value to your organization

Mind The Silo

In order for analytics to function most data needs to be transformed into whatever the solution requires in order to produce the results you need. This creates a silo for your data because the data goes in as one format and only to be stuck in another, the output is merely the process of that system.

This may sound okay, where it is not okay is that then we try to use that data for other things. Such as connecting an HL7 interface, or passing along data; which many of these systems will tell you they can do.

On the surface this all works well, however as you dig down to creating near-real-time data exchanges or try to do high volume transactions you will begin to run into a lot of issues, and in the process you have created yet another dead end silo for your data.

How A Platform Helps

This is where a platform that helps direct your data in near-real-time really can show its true benefit. First and foremost it solves for the issue of which to choose. You can easily pilot 2 or 3 software systems at the same time without adding resource needs as the platform can easily manage and direct data to each system using proper security controls.

While you are still creating another data silo, you are not dependent on that one. Meaning the software can do what it does best then you can take that output and put it back into the platform to provide a full view of your data.

Why Care Gaps Are Really Data Gaps


In healthcare you will often hear, or see in the news, talks about care gaps. Care gaps is used to describe when a link in the chain along the journey is not connected. Think of care gaps as a way to address a particular path/journey/experience in the same manner every time.

Addressing journey experiences is very important for systems and providers as it provides patients with a better experience overall, reduces risks and increases the success of each visit.


White spaces

Care gaps live in white spaces, spaces that need to be addressed to resolve a particular initiative that is usually unique to addressing the unique population that provider/system serves. This is an important part, because you can’t have the same care gaps for every hospital be the same, although there are guides and standards people follow as a starting point most often you will see systems really take a unique approach to it which is important for them to stay innovative.

Strategic initiatives look at resolving these challenges at a high level; for example lets say a patient visits a doctor and then he is referred to a specialist and instead of making appointment on the spot the patient has to call a different number make an appointment. Then once the patient gets there the doctor does not have their information, this is a big care gap.

In this area is where care gaps work to solve the white spaces and they do this using workflows that can be followed consistently over and over again.


Workflows go hand in hand with care gaps. Care gaps identify the challenge we need to address and workflows is how we address those challenges. So if we were to take a look at it the flow goes from strategic initiatives to care gap identification to workflows.

Once workflows are identified then operations can begin executing those workflows and then we can measure the output of those and repeat the process or adjust until we find the right formula that provides consistent results


Data Gaps not Care Gaps

When thinking of addressing care gaps what is always absent is the data gap. We have a larger data gap problem than a care gap problem. If we take our example of a basic referral for instance and ask the question is why is it missing? There are a few reasons that could be:

  • Provider is not inside the 4 walls of the system OR
  • Provider is using their own EMR system OR
  • Provider is completely independent and even in another location/state

When you dig into all care gaps you will find it is often, if not always, a data gap issue that needs to be addressed – and any care gap or workflow built to work around this often ends in less than desired outcome.

It’s time to look at data gaps to inform care gaps

When working through the customer journey or doing an experience map, it is vital that we use data gaps that we have to inform those care gaps rather than the other way around. Unfortunately we often come at it only from a care gap perspective leaving our IT team scrambling to identify where data gaps exist and how to fill them.

Often this results in workarounds that cause more work for providers than is needed. Instead we really should start looking at data gaps to help inform these care gaps, in fact if we look at our data gaps we can identify large gaps that we have and by solving those we would be informing care gaps about which gaps can be addressed and which are the biggest whitespace to fill.

This is where a platform comes in, platforms help you resolve data gaps quickly or at least offer a path to a solution quickly that does not require you to have to build out a team or projects with every single new identified data gap.

Do We Really Need APIs In Healthcare?

When I talk to CEOs and CIOs often the first question I get is what are APIs and followed almost immediately by why do I need them? Perhaps, as I have come to learn, the root of the question is do I really need it? I mean after all we do have HL7 so why APIs and how are they different.


For clarity sake lets all get on the same page about APIs. For starters API stands for Application Programming Interface(s). Better way of thinking of APIs is to think of power sockets. Around the world as you travel you find different sockets depending on which country you are in. To use those sockets you buy an “adapter” that converts your plug, for whatever gadget you have, to that countries specified plug. This is exactly what an API does. It allows an application that has one type of socket to use an adapter (API) that then connects to the other type of socket you need to connect to.


In many ways HL7 is a great, sort of, API that we have in healthcare that is taken largely for granted. However it is really important to note that a lot of the challenges of HL7 are really due in part to how the software provider configured HL7 and due to the complexity of HL7 there are many deployments of it.

Before I go any further though I would like to point out that APIs have the same challenge as HL7. There is no ultimate governing body and we have to rely on developers. Yes, there is, a widely accepted specification format for displaying such as JSON however how it comes out and how it is deployed is NOT standard.

Retrospectively HL7 has more of a standard than APIs as it forces a set of guidelines for how data should be displayed and more specific how data should be displayed in healthcare.


Absolutely. Maybe. Perhaps.

The answer to this question is just as tough as figuring out how to solve it. The challenge with any standard is restriction of how something flows; thus why we get specifications. However then the challenge is in how its implemented across the industry.

What I would like you to consider is that instead of focusing on standards we focus on specifications that lay a general guideline and then use the least complex method to get that data in and out.



The first step is to shift away from talking about “interoperability” and start talking about data liquidity. After we refocus and redefine our approach and accomplish that we can then put APIs on top to help people access the data faster and help build great experiences.

However the greatest challenge lies beyond data liquidity, the merger of the experience, consumer and the clinical workflow.