Interoperability: Empowering the healthcare data  to speak one language

Impact at a Glance

Origin Story

After the success of our internal data platform- Hungry Wizard, we confront a new question: How do we solve healthcare data chaos not just for our organization, but across our industry? We dramatically sped up our internal data processing, but it was still a closed-world solution. We could ingest data faster, yet each external partner (payers, providers) still sent data in their own quirky format. It became clear that even a strong internal tool wouldn’t fix the broader interoperability problem – the industry lacks adoption of a common language.

The healthcare community is buzzing about HL7 FHIR (Fast Healthcare Interoperability Resources). FHIR is essentially an open standard for health data – think of it as a universal language that lets systems talk to each other using modern web tech (JSON, REST APIs). Here's an opportunity: if we embrace HL7 FHIR within our products, we bridge our internal innovations to the outside world. In other words, we’d go from taming our own data to helping tame data across organizations.
‍
That insight kicked off our new mission. We are transforming our data pipeline from a Hungry Wizard “speaks-all dialects” approach into a “teach the world one language” approach. It's a bold pivot: we  champion interoperability through HL7 FHIR, aiming to replace  messy CSVs and ad-hoc files with standard, real-time data exchange. The team is excited but cautious – we know adopting a new standard would be challenging. Still, the vision is compelling: if Hungry Wizard was about scaling internally, this new initiative is about scaling connectivity externally, which amplifies our impact on healthcare outcomes well beyond our four walls.

(We recognize that to truly unlock value-based care across our network, we need to build on standards that everyone will adopt, not just create another proprietary solution.)

Context and Problem

Healthcare data exchange has long been stuck in the dark ages of technology. Even in a modern value-based care organization, data often moves via messy CSV files, Excel sheets emailed through secure portals, or one-off API connections that lack consistency. Each payer might deliver a monthly eligibility roster in a unique format; each provider might share quality data in a different template. This patchwork of formats isn’t just annoying – it’s a major bottleneck for value-based care (VBC).

In value-based care, success depends on timely, accurate data sharing between payers and providers. You need to know which patients you’re responsible for (and their insurance details), and you need clinical data on those patients (e.g. did they get their diabetes checkups?). Without smooth data exchange, providers can’t close care gaps in time, and payers can’t measure outcomes fairly. Our team experienced this firsthand: even after speeding up internal processing, if a payer’s file came in late or wrong, our analytics and interventions suffered.

We saw that the root problem was lack of standards. Imagine trying to assemble a puzzle where each piece comes from a different puzzle set – that’s how healthcare data felt. This is where HL7 FHIR comes in. HL7 FHIR (Fast Healthcare Interoperability Resources) is an emerging industry standard for structuring and sharing health data. In plain terms, FHIR provides a common format and protocol so systems can exchange data like patients, enrollments, and clinical records in a predictable way – much like how all websites speak HTTPS. It’s backed by a broad coalition of providers, tech vendors, and regulators, making it a promising lingua franca for healthcare.
‍
Our hypothesis is that adopting HL7 FHIR will break down the silos. Instead of building 100 custom pipelines for 100 partners, we’d build one standardized pipeline that all partners could use. This would not only save engineering effort, but also dramatically improve data timeliness and quality (since everyone’s using the same playbook). We also recognized that the industry momentum was shifting: government regs and initiatives (like CMS interoperability rules and HL7’s own Da Vinci projects) were nudging payers and providers toward FHIR. We had a chance to get ahead of the curve and shape the future rather than play catch-up later.
So the problem we targeted was twofold:

• Disparate Data Feeds: How to eliminate the tangle of CSVs and one-off integrations that slowed down our value-based care operations.
• Interoperability Gap: How to enable a scalable, standards-based data exchange so that our internal gains (fast data processing, analytics) could extend outward to partners, supporting industry-wide improvement.

Without solving these, our ambitious quality programs would always be hamstrung by slow, error-prone data handoffs. We needed to create a solution where data flows as seamlessly as the insights it enables. That meant reimagining our pipeline around HL7 FHIR interoperability.

My Role

As the product leader overseeing our interoperability initiative, I led all product development across these new HL7 FHIR use cases from conception to launch. My role was a blend of product strategy, people mentorship, and technical direction:

• Product Strategy & Vision: I crafted the roadmap for how we’d tackle interoperability in stages – first focusing on patient rosters, then scaling to clinical quality data. I pitched the vision that “if Hungry Wizard solved our internal scale problem, HL7 FHIR will solve our external scale problem.” This meant translating the high-level idea into concrete goals and timelines that our executives and team could get behind.
• Technical & Strategic Bridge: I served as the bridge between diverse stakeholders – engineering teams, clinical informaticists, and external partners like payers and vendors. On the technical side, I worked closely with our architects and engineers to evaluate solutions (e.g. selecting Smile CDR as our FHIR server, designing how Azure Functions would orchestrate data flows). I often found myself translating between worlds: explaining clinical requirements to engineers, or articulating technical constraints to payer IT teams in plain language. I ensured that our solution was not just technically sound but also clinically valid and aligned with payer expectations.
• Mentorship & Team Building: My team included product managers who were formerly business analysts. I coached these PMs to adopt a product mindset – teaching them techniques like user story mapping (to break complex workflows into manageable pieces) and iterative delivery (to release value incrementally rather than big bang). For example, I guided them through mapping the end-to-end journey of a “quality data pipeline,” from data ingestion to gap closure, so we could identify MVP features. I also made sure each PM felt ownership of a sub-area (one took on the ATR roster work, another focused on quality measures) while I provided oversight and support.
• Cross-Functional Orchestration: Much like with Hungry Wizard, I led regular syncs and alignment meetings – daily stand-ups with developers, weekly check-ins with clinical leadership, bi-weekly updates with external payer stakeholders. I became the point person for anything interoperability-related, making sure that engineering decisions stayed tied to business value (and vice versa). For example, when an engineering lead was debating how to model a patient roster in FHIR resources, I’d loop in a clinician to confirm what data mattered most, and a payer partner to ensure our format matched theirs. This tight loop kept everyone on the same page.

In short, my role spanned vision to execution. I was hands-on when needed (sketching data flow diagrams on a whiteboard, reviewing FHIR resource mappings) and hands-off when appropriate (letting my PMs run their scrum ceremonies to grow as leaders). I also championed a culture of learning on the team – since HL7 FHIR was new to many, we organized internal training sessions by an HL7 expert. By wearing both the product manager and technologist hats, I helped the team navigate uncertainty and stay focused on the ultimate goal: an interoperable future where data moves easily and securely to improve patient care.