From APIs to Enterprise Advantage: The Product Leader’s Role in Healthcare Interoperability

IA FORUM MEMBER INSIGHTS: ARTICLE

By Md Akram Hossain, Consultant, EPM Technology, JOHNSON & JOHNSON

Healthcare interoperability is no longer a technical constraint. It is an organizational one.

Most enterprise platforms today support modern APIs. Systems like Epic Systems and Oracle Health expose integration layers that make data exchange significantly easier than it was even five years ago. Large health systems have invested millions in modernizing their digital stack.

And yet, fragmentation remains.

In nearly every enterprise transformation I’ve been involved in, the same pattern surfaced. Integration was treated as a milestone: connecting systems, validating feeds, and moving on. Technically, the work was often sound. Operationally, very little changed.

Clinical teams still relied on manual workarounds. Finance teams still questioned cost allocations. Executives still debated which dashboard represented the “real” number.

The issue wasn’t connectivity. It was ownership.

Interoperability has traditionally been framed as an IT responsibility. In practice, it is a product strategy mandate.

Where Interoperability Goes Off Track

Integration roadmaps often begin with architecture. Which systems need to talk? Which APIs should be exposed? How do we normalize formats?

Those are necessary questions. They are not sufficient.

I’ve seen organizations successfully integrate EHR and ERP systems only to discover that no one had defined which operational decision the integration was meant to improve. Without that clarity, data flowed - but behavior didn’t change.

Interoperability without product intent becomes a technical achievement with limited enterprise return.

The more useful question is not “Can these systems connect?” It is “Which decisions are currently impaired by fragmentation, and what will improve once that friction is removed?”

That shift - from connection to consequence - is where product leadership begins.

Start With the Decision, Not the Diagram

System-to-system roadmaps are attractive because they signal completeness. An enterprise integration map gives the impression of progress.

But executives don’t manage diagrams. They manage trade-offs.

In one service-line initiative, leadership believed they had sufficient visibility into procedural profitability. When we overlaid clinical case data with supply utilization and actual cost allocation, the story changed. Margin variability across similar procedures was wider than anyone expected. The data had existed in separate systems for years. No one had prioritized stitching it together around a specific decision.

Once surfaced, the conversation shifted quickly - pricing strategy, vendor negotiations, preference card optimization. The integration itself wasn’t groundbreaking. The decision to focus on that workflow was.

Product leaders have to make those calls deliberately. Not every integration deserves equal investment. The priority should always be tied to enterprise leverage.

Interoperability as a Product Capability

One of the most common failure modes I’ve seen is treating interoperability as a project with a finish line. Projects end. Capabilities compound.

When interoperability is treated as a product capability, it requires the same rigor as any strategic platform initiative: defined outcomes, clear user segments, measurable KPIs, iterative delivery, and long-term ownership.

Clinical leaders need timely documentation and clarity at the point of care. Finance leaders need trusted cost and revenue data. Operations teams need throughput visibility. Each of these stakeholders’ experiences fragmentation differently. Product strategy must account for that reality rather than assuming a single integration effort will satisfy all.

Shifting the conversation from “integration completion” to “workflow improvement” changes how roadmaps are sequenced and how success is measured.

Governance: The Uncomfortable but Necessary Discipline

Data governance rarely generates enthusiasm. It does, however, determine credibility.

In one transformation effort, we launched a cross-functional dashboard intended to unify clinical and financial performance. Within weeks, the conversation shifted from strategy to skepticism. Leaders questioned how costs were allocated and how encounters were defined. The technical integration was correct. The definitions were not aligned.

That experience reinforced something simple: governance cannot sit adjacent to product. It must be embedded within it.

Shared definitions, clear ownership, and visible data quality metrics are not administrative overhead. They are prerequisites for executive trust.

Without them, interoperability scales confusion.

The Cross-Functional ROI Challenge

Another persistent barrier is funding. The benefits of interoperability typically span departments. The costs rarely do.

An integration that improves enterprise margin visibility may require investment from IT, informatics, and finance, yet no single function captures the entire return. Without product leadership to frame the business case at the enterprise level, initiatives stall in budget negotiations.

In several cases, alignment only occurred once the value narrative shifted from “system integration” to “denial reduction, throughput gains, and margin protection.” When leaders saw how fragmented data constrained performance under value-based contracts, prioritization became clearer.

Interoperability must be articulated in terms executives recognize, risk mitigation, margin stability, strategic agility.

Laying the Groundwork for AI and Value-Based Care

There is understandable enthusiasm around AI and advanced analytics. But in practice, I’ve seen organizations attempt to deploy predictive models on top of inconsistent data foundations. The result is usually limited adoption or loss of confidence in the insights.

AI does not compensate for fragmented architecture. It amplifies it.

Value-based reimbursement models create similar pressure. Risk-based contracts require longitudinal visibility. Performance reporting demands harmonized data across care settings. Without foundational interoperability, these strategies remain constrained.

Product leaders have to sequence intelligently. Establish reliable, workflow-aligned data foundations first. Then scale intelligence. When that order is respected, interoperability becomes a strategic enabler rather than a compliance exercise.

Why Discipline Matters

Interoperability programs fail for predictable reasons: over-scoped early phases, success metrics tied to integration completion rather than operational impact, change management separated from delivery, unclear ownership post-launch.

These are product failures, not technical ones.

The correction is straightforward but not easy. Start narrow. Tie releases to measurable operational and financial outcomes. Plan adoption alongside build. Assign clear long-term ownership.

Interoperability is not a release cycle. It is an evolving enterprise capability.

From Connectivity to Advantage

Health systems that approach interoperability through a product lens move differently. They respond faster to reimbursement changes. Their performance conversations are grounded in trusted data. Their AI initiatives scale more effectively because the foundation is stable. Capital decisions are made with greater confidence.

The tools to connect systems already exist. What differentiates organizations is whether someone owns the translation from connectivity to consequence.

I have yet to see an API, on its own, change enterprise performance. I have seen disciplined product ownership do exactly that.

For C-suite and digital transformation leaders, the mandate is clear: interoperability belongs in product strategy, not just architecture roadmaps.

When managed deliberately - tied to decisions, governed carefully, sequenced pragmatically - it becomes more than integration.

It becomes an enterprise advantage.

Author Disclaimer: The views and opinions expressed herein are those of the Author alone and are shared in a personal capacity, in accordance with the Chatham House Rule. They do not reflect the official views or positions of the Author’s employer, organization, or any affiliated entity.