Payers Need API Plumbing That's Nimble and at Scale | digitalML

Payers Need Enterprise API Plumbing That’s Digitally Nimble and At Scale

API Strategy, Enterprise Architecture

Payers Need Enterprise API Plumbing That’s Digitally Nimble and At Scale

·  4 Min Read

IDC’s guest blogger Jeff Rivkin discusses best practices for healthcare API strategy.


In this post, guest blogger Jeff Rivkin, Research Director, Payer IT Strategies, IDC, discusses drivers and challenges for Healthcare Payers’ need to evolve past silos; to become a “partner in care” for consumers. Jeff also provides advice on implementing an effective API strategy to enable this evolution, and become digitally nimble at scale.


Payers Need Enterprise API Plumbing That’s Digitally Nimble and At Scale

By Jeff Rivkin, Research Director, Payer IT Strategies, IDC

Gone are the days where a payer was in a staid market and considered a member as a year-to-year entity that enrolled, paid premiums, and submitted claims in a silo, managed by a tangential clerical functions that only ensured that transactions were processed cleanly. Payers know the landscape is changing externally, internally, operationally, and in the minds of consumers, who desire the payer to be their “partner in care” navigating the fragmented healthcare ecosystem.

Externally, payers are facing multiple business challenges, straining the flexibility of systems:

  • Disintermediation—from major companies, short-term policy providers, and “public-option” products
  • Regulation—both federal and each of the 50 states about transparent pricing, network adequacy, standards of care, exchange of data, exchange rules, etc.
  • Partnerships—with “payviders,” health systems and complementary industries
  • Diversification of portfolio—with health systems, product innovation centers, and mergers
  • Consumerism—to meet the consumer expectations of the individual healthcare experience, which include:
    • Consumer experience – shopping, selecting, and paying for care
    • Patient experience – arranging and receiving care
    • Patient engagement – active participation of patients in their care

Internally, core processing systems need to evolve past their silos to seamlessly interact with the entire customer; sales, marketing, customer service, consent, medical, claims, enrollment, premium, SDOH, wellness, and bundled payment software. Today, the virtual or physical customer-360-degree view is the center of a customer relationship management ecosystem. Melded from home-grown and vendor-purchased assets, this ecosystem is where all enterprise functions operate, are modeled, examined continuously for accurate or more profitable relationships. From member onboarding to self-service to delivering personalized care recommendations, payers can provide an elevated and personalized experience to engage their members across all healthcare journeys. As an example, it is not unusual to see products packaged “member in a box” that enables:

  • Member Portal
  • Member Mobile App
  • Service Bot
  • CX Engagement communications hub
  • Member Service Center
  • Member 360
  • “Next best action” recommendation assistance

Operationally, payers need their enhancements “activated” with the virtual data platform, such as:

  • Activated applications. The connections and maps to allow the workflows, user interfaces, and reporting of (versions of) applications to effectively use the data platform
  • Activated analytics. The aggregations, slices, extracts, and rules around such to enable the analysts, data scientists, modelers, statisticians, and inquirers to do effective analysis
  • Activated access. The ability for all enterprise personnel to securely, auditably, predictably, and reliably get to the needed data using standard protocols and published interfaces
  • Activated managed services. The ability to package reusable functions for use by applications, analytics, or partners

API Strategy Advice for Payers:

To answer these challenges, payers should:

  • APIs expose business capabilities and IT functions. Establish early an API Catalog management approach and a disciplined center of excellence. A coherent context for building API and using vendor API in an enterprise way prevents or controls haphazard point-solution-driven software asset accumulation.
  • Enable the ability for payers to surface tailored content to be a complete view of a Member across multiple siloed systems of record through an enterprise API tool. Leverage the data from existing systems of record. Data may not need to be moved, replicated, etc. to meet cross-organizational need. APIs enable the member 360 to display the most up-to-date information on a member from various lenses around the enterprise (marketing, clinical, workflow, claims, events, care management, gaps in care, authorizations, anything). Since APIs can provide health plans with comprehensive consumer profiles, this enables efficient and personalized service experiences. It improves resource utilization and increases operational efficiency by consolidating consumer-related data gathered from disparate sources into one virtual central location, ensures data synchronization across the entire organization, and updates profiles dynamically.
  • Evolve 360 themes past the member to support views of other types of consumers (provider, broker, group, employee, vendor, etc.). Standardize assets, workflows, shared APIs, and other services across the entire platform. This will make it easy to add additional vendor products and functions, while leveraging the payer’s initial investment in integration, configuration, and delivery.
  • This year, when establishing interoperability or consent initiatives, establish an environment where these API assets are reliable, can scale, and be controlled collectively. Some interoperability products were born, and maybe brought up quickly, for the interoperability mandates or evolved as a vendor acquired various software pieces and stitched together a derivative data model and platform. Similarly, some consent modules are application-specific, stuck in member portal or other applications and need to be freed up for enterprise use.
  • Look internally to support interoperative, cross-organization capabilities with APIs, web services, events. Day-to-day integration requirements can be met with these enablers.
  • Look at disintermediators, see how their comparative functions are locked in internal payer silos and enable them by unleashing API technology.
  • Look at Provider data with the eye of exposing transparency through API, with a different set of use cases, but equally powerful.
  • Ensure that infrastructure (standards, process, workflow, education, integration, agility) is respected by the vendors and control their API Catalogs with an Enterprise API Catalog of your own.
  • Remember that this openness is not just for a single application or “clinical” integration or consuming developer. This enterprise API backbone catalog will be the baseline for the infusion of future data requirements such as social determinant data, remote monitoring data, telehealth data, contact tracing data, and be the basis for “lifetime person” data for the enterprise. It must scale, and it must be inclusive of business and product owners as well as IT and other developers.



About the Author

Learn the Best API Practices and Get the Latest ignite Updates

What can we help you find?

Use of cookies

We use cookies to make the website optimal and to continuously improve it. By continuing to use the site, you consent to the use of cookies. Please refer to the privacy policy for more information.