Accelerating HM Health Solutions in their Platform Journey

Starting out on an API program can be daunting. The temptations to focus on technical objectives are many. After all, APIs are technical things, right? They embody:

• Interfaces so that,
• Programmers – we call them developers in the 21st Century – can provide business value by building,
• Applications – the way that IT systems have traditionally provided experiences for the people consuming your services and information.

There, I covered the acronym in the reverse order: IPA. I guess you can tell what’s been on my mind during this pandemic lockdown.

Seriously though, those three things all sound highly technical. Let’s look past the acronym and really consider what APIs truly offer by walking through one organization’s experience – and my experience as a Catalyst in helping them to make good decisions about APIs.

For the Catalysts, building trusted advisor relationships with organizations that need a boost is our business. We want people to see APIs as business products rather than just technology components because a platform represents not just bits of running technology but a whole new business model.

No strategy, no vision

As we Catalysts like to stress, if your organization does not have a well-defined, easy to understand, and effectively communicated vision, then it will never have a strategy to match it and allow business and technology people to execute and make it real.

HM Health Solutions has a fantastic vision: to provide a solution that “combines an integrated platform, proven business processes, and experienced people supporting all aspects of a health plan’s operations.”

The challenge is to make this vision come to life in a truly digital way – that means focusing on digital membership experiences and outcomes, digital innovation, and ensuring that the whole thing is secure and governed.

HM Health Solutions set great strategic goals to match their vision including:

• Building a core group to deliver consumer-centric APIs
• Identifying what changes we need to make?
• Moving from a project-specific way of working with no reuse – and deliveries that are too technical to share
• Delivering and managing business APIs to support key platforms
• Defining practices – changing mindsets – making a cultural shift

Strategic Alignment – API First

Last year, the core group had been assembled at Highmark and they did set about defining practices and delivering consumer-centric APIs. In parallel, another initiative in another part of the organization was started to begin the mindset and cultural shift and move to drive innovation.

Good things were happening but the alignment wasn’t exactly there. The core API team also needed to be able to articulate the value of an API First approach. API First does not mean “do everything with APIs.” It really takes not just a methodological shift but also a mindset shift.

API First is simple – rather than just diving in and building applications, teams can collaborate on the design and development of an interface before any implementations are started. This approach encourages teams to nail down the design of APIs first, so quite often API First and Design First can be a dynamic duo to accelerate planning, testing, and mocking of APIs with a maximum of feedback.

Consumers First – Focusing on Value

One of the traps I could see my friends at Highmark falling into was approaching API delivery from a one-off provisioning focus. One of the foundational APIs all healthcare providers will need is a Membership Search API. Member growth and member retention are the key business metrics that define success in healthcare and providers need to be proactive about this.

Obviously, the API team put some thought about the capabilities required and but the requirements seemed more about what information to expose and the technicalities of data access. It was also clear that the core team was still falling back to thinking of the API as a way to connect people to membership data but not so much about what they needed to do with it. After having limited uptake of the initial APIs, a pivot needed to be made.

At this point, I advised the team to consider API Value Proposition co-collaboration sessions as a standard practice.

We set up some API Value Proposition sessions to systematically understand customer needs and to design APIs as products that customers really want. To do this, you need … customers! This was a shift in the way of working for HM Health Solutions since the core team still functioned like a traditional integration team, connecting systems to other systems. A big breakthrough was made in these sessions when different consumer groups such as Member Management and Clinical Utilization got involved to describe the gains they wanted to see and the pains they wanted to solve.

Design is not Optional

One thing the HM Health Solutions team learned early on is that API design is not an optional part of the life cycle.

Getting the Balance Right,  Planning for Scale, Executing with Gradual Progress

When advising HM Health Solutions, I was able to draw upon my contrasting experience with two of their peers in healthcare who have also embarked on a platform strategy powered by APIs. One took a big bang approach where an API Factory was readied in order to be cranking out APIs at scale.

It was understood at HM Health Solutions that scaling up their platform to build an ecosystem of healthcare partners was at the heart of their strategy. When an API program is starting out though, we need to somehow fight this “addiction to scale,” as Nick Katsivelos, a digital adviser to Microsoft says.

The Journey – Continued

That’s a Catalyst’s account of one customer’s drive to a world-class platform powered by APIs. I know from experience that this journey never really ends and that the real power of a platform powered by APIs is achieved through steady work at achieving scale and focusing on business outcomes.

Our customer now feels the same way and we have a shared vision:

“HM Health Solutions has partnered with the Axway Catalyst team on digital transformation of our API Ecosystem from project-focused services to an API First, APIs-as-Products culture. The tools, techniques, and modern API thought processes introduced by the Catalyst team have provided significant value to Highmark. While our organization is in the early phases of the API First Journey, our internal and external customers have already been delighted with the early progress and API experiences the Catalyst team helped us create. We look forward to continuing the Journey.”

• Marc Patterson, Senior Architect – HMHS Enterprise Architecture, HM Health Solutions