What I Learned at Open@Epic 2025: Interoperability, Trust, and Scale From the Heart of Verona

Introduction: Inside Epic’s Verona Campus, Where Interoperability Gets Real

Walking into Epic’s headquarters in Verona, Wisconsin, feels like stepping into healthcare’s innovation lab. Open@Epic is one of those events that never disappoints. This year, the conversations were sharper, the questions deeper, and the energy unmatched. You could sense that everyone—from Epic engineers to hospital CIOs—was asking the same question: how can we make data move faster and more safely across systems?

For me, this trip was more than just attending sessions. It was about connecting dots between technology, policy, and real-world care delivery. I had the chance to meet with partners and customers, including my friend Paul Edge, who always brings a practical, no-nonsense perspective on what hospitals truly need from health tech vendors.

Every talk I joined, every demo I saw, reinforced one truth: interoperability cannot be an afterthought. It is not just about moving data. It is about removing uncertainty and earning trust—one secure connection at a time.

This blog captures what I saw, what I learned, and how these insights are already shaping how we design and build at Mindbowser.

I. What I Saw On The Ground At Open@Epic 2025

A. The Atmosphere And Why It Matters

Epic’s Verona campus has a unique pulse. It is one of those places where technology, policy, and care delivery intersect in a very tangible way. As I walked through the halls filled with developers, clinicians, and innovation teams, I realized how far the interoperability conversation has evolved. It is no longer about whether systems can talk to each other. It is about how quickly they can trust each other.

Open@Epic brings together people who live and breathe this mission every day. Startups, payers, and hospital IT leaders all speaking the same language: APIs, FHIR, and patient safety. The energy this year was different. There was a shared understanding that interoperability is not a nice-to-have. It is a business enabler. It is what separates apps that stay in pilots from those that scale across health systems.

B. Conversations That Shaped My Takeaways

One of the best parts of this event is the hallway learning. Between sessions, I caught up with CIOs, Epic product leads, and engineers who build these interfaces day in and day out. We spoke about everything from TEFCA alignment to OAuth scope design. What stood out most was a shift in tone. Hospitals are not just asking “Can your app connect?” anymore. They are asking “How do you handle patient safety, security, and upgrades when Epic changes its APIs?”

That shift is important. It means integration is now seen as a trust-building process. When your documentation is clear and your data flow transparent, approvals move faster. When they are not, projects stall for weeks or months. The message was clear: clarity is currency.

C. The Big Picture For Interoperability

The sessions on the FHIR roadmap and population health APIs were packed, and for good reason. Bulk Data and TEFCA are reshaping what national connectivity will look like. Epic’s updates—like improved sandbox environments and the new “Try It” feature—are quietly changing the developer experience. These are not flashy upgrades, but they remove friction where it matters most. At scale, that means fewer errors, shorter approval cycles, and faster time to value.

Standing there, I realized interoperability is not just about technology alignment. It is about operational alignment. When standards guide your architecture, everything from testing to compliance gets easier. That is the kind of simplicity that scales.

II. The Cost of Complexity vs. The Dividend of Clarity

A. Approvals and the Real Bottleneck

One insight that stuck with me at Open@Epic 2025 was just how much time integrations can lose in the approval process. Getting approval from a hospital IT team is not a one-step exercise. It can take days, weeks, or sometimes months depending on how complex the app is and how clearly you describe what it does.

Most teams assume the deciding factor is the technology. It is not. The biggest influence is how well you communicate the basics: your data flow, your security posture, and your API scopes. When these details are crisp, trust builds quickly. When they are not, approvals drag on because reviewers must fill in the gaps themselves.

I heard the same message repeated in several sessions. The approvals that move fastest are the ones where vendors make it easy to say yes. Clarity shortens risk review. Simplicity reduces back-and-forth. At Mindbowser, this confirmed what we already practice: interoperability is 50 percent technology and 50 percent communication.

B. OAuth2 and Scope Hygiene

Epic’s deep dive on OAuth2 was one of the most valuable sessions for me. It reinforced how important it is to treat scopes as more than checkboxes. Each scope signals intent, access boundaries, and accountability. Hospitals notice that.

When you request only what is necessary, you make it easier for reviewers to approve. Overly broad scopes, on the other hand, trigger concern and slow everything down. That is why “scope hygiene” is essential. It protects users and accelerates approvals at the same time.

A developer from a major health system summed it up perfectly during the Q&A: “The fastest way to get a green light is to show that you understand what you should not touch.” I could not agree more.

C. Lessons for Product Teams

If I had to translate these insights into practical advice, it would come down to three things:

1. Treat approval criteria like product requirements. Build your integration packet early. Include architecture diagrams, data usage explanations, and security controls upfront.
2. Decide early what data you truly need. Scope creep in integrations creates both technical and compliance debt.
3. Build repeatable documentation. Every new hospital connection should feel like déjà vu because your team already knows the process and the materials required.

The takeaway is simple but powerful. Complexity has a cost. Clarity creates trust. And trust, in turn, unlocks speed. That is the dividend of doing the hard work up front.

III. Standards First: Building With Them, Not Around Them

A. FHIR Roadmap Highlights

One of the strongest themes at Open@Epic 2025 was the continued evolution of the FHIR roadmap. Epic’s team walked through how standards are expanding beyond basic data exchange into real, scalable use cases for population health, payer collaboration, and analytics.

Bulk Data exports stood out to me. They are becoming the backbone of population-level reporting, allowing health systems to share data securely and efficiently with partners. Another highlight was Epic’s focus on aligning FHIR implementation with TEFCA. This is a big deal because it connects standards-based APIs with the national exchange framework that regulators are pushing forward.

The message from Epic’s sessions was clear. Standards will not just make integration easier; they will make interoperability sustainable. When we build to FHIR and TEFCA instead of building around them, we reduce rework, simplify security, and improve compatibility across systems.

B. HL7v2 Still Works Hard

While FHIR gets the spotlight, HL7v2 is still doing the heavy lifting for many hospitals, especially in high-volume environments like remote patient monitoring. I was glad to see that Epic continues to invest in supporting both worlds. Their new HL7v2 testing tools inside Vendor Services allow developers to simulate real trigger events before going live. That means fewer surprises in production.

I also asked Epic’s team about when HL7v2 is still the preferred option. Their answer was practical. For large data streams, HL7v2 often performs better because it can handle volume without overloading the system. For transactional and event-based data, FHIR is ideal. The key is not to treat one as a replacement for the other. They serve different needs.

C. Practical Tradeoffs Teams Should Model

Every healthtech product team faces a similar challenge. Do we design purely for FHIR or do we maintain hybrid interfaces with HL7v2? The best answer I heard during Open@Epic was to model both.

FHIR Subscriptions are powerful but not yet universally supported across hospitals. Meanwhile, HL7v2 remains stable and reliable for transmitting updates after a bulk export. That balance ensures continuity and compliance no matter what environment you deploy into.

At Mindbowser, we apply the same principle. When we build for interoperability, we start with standards as the foundation. But we also account for real-world variability in how hospitals implement them. That balance is what allows integrations to scale smoothly instead of breaking with every system upgrade.

IV. Epic’s Developer Experience: Small Features, Big Time Savings

A. Tools That Reduce Friction

Epic’s developer team deserves credit for how much they have simplified the integration journey. What impressed me most this year was how small updates are removing real-world pain points for developers.

The new “Try It” feature on the Epic Developer Portal is a perfect example. It lets developers test APIs directly in the browser, similar to Swagger or Postman. This may seem like a small step, but it saves hours of setup time for every team trying to validate calls or troubleshoot response formats. For anyone who has built healthcare integrations before, this is a real productivity boost.

Another practical addition is the HL7v2 testing environment inside Vendor Services. It allows developers to simulate message triggers like admissions, discharges, and transfers before a single live connection is made. This level of testing reduces risk during go-live and helps teams catch issues early, when fixes are still easy.

Epic has also made progress with CDS Hooks testing. Patient-view hooks are now easier to test in isolation, and other hooks can be verified through collaboration with Epic’s Vendor Services. These small steps make a big difference in the developer experience and directly impact how quickly an app can move from sandbox to production.

B. Onboarding and Guidance

One of the recurring challenges in healthtech development is onboarding. Teams often underestimate how complex it can be to align technical, security, and compliance documentation before getting started. Epic’s new five-step onboarding guide simplifies this. It gives developers a structured path from registration to production, with checkpoints for testing and validation.

In addition, the expanded sandbox environments now support more real-world scenarios. Developers can test workflows that mimic hospital use cases, which makes troubleshooting more realistic and valuable. Epic has also published more than 40 developer playbooks covering everything from authentication to version management.

For anyone serious about building healthcare integrations, these playbooks are a goldmine. They combine technical clarity with operational best practices. I have already shared them with our engineering team at Mindbowser as references to refine our own internal onboarding and review checklists.

C. Why This Matters At Scale

Every developer wants faster testing and fewer surprises in production. What Epic is doing here matters because it directly reduces friction. Each small improvement saves a few hours or a few meetings, but at scale across hundreds of vendors, that becomes a huge productivity lift.

When developer experiences improve, healthcare innovation accelerates. Teams spend less time debugging and more time improving outcomes. For organizations like ours that focus on interoperability, this translates to lower risk, quicker validation, and stronger trust with provider IT teams.

At the end of the day, interoperability success is built on speed, safety, and simplicity. Epic’s latest updates help developers achieve all three without compromise. That is progress worth celebrating.

V. Security, Compliance, and Trustworthy AI

A. Security Reviews That Move Fast

If there is one topic that never loses attention in healthcare, it is security. At Open@Epic 2025, several sessions and side conversations reinforced how vital it is to approach security reviews with transparency and preparation. Hospitals are not just validating your encryption or your OAuth flows. They are assessing how well your team understands what data you collect, where it travels, and how it is stored.

Epic’s infrastructure security team shared that the most common reason for delays is incomplete documentation. When vendors submit a clear architecture diagram, data flow explanation, and storage policy upfront, the review process can move quickly. When those details are vague, it adds weeks of back-and-forth.

For me, that was a reminder that every integration is a trust exchange. Hospitals want assurance that you are not just compliant on paper but secure in practice. A clear story around security posture can make or break the speed of your deployment.

B. Patient Safety and Clinical Trust in AI

The “AI in Healthcare” track this year hit close to home. It was not about flashy AI models or predictive analytics; it was about responsibility. Every speaker echoed the same formula: Patient Safety + Clinical Trust = Adoption.

AI systems in healthcare succeed only when clinicians believe the model’s output is safe, traceable, and relevant. One of the Epic leaders put it perfectly, “We cannot separate innovation from accountability.” That mindset is critical as more healthtech companies deploy AI-enabled tools within EHR environments.

At Mindbowser, we have learned the same lesson from our AI projects. Validation is not a checkbox. It is an ongoing process that combines quality data, ethical design, and constant monitoring. The goal is not to prove the model works once, but to prove it continues to work safely in every setting where it is used.

C. HIPAA Today, TEFCA Tomorrow

Another recurring topic was how compliance expectations are shifting as regulations evolve. The speakers discussed how the intersection of HIPAA, TEFCA, and upcoming data-sharing mandates is redefining what “compliant” really means. It is no longer enough to encrypt data and have a BAA in place.

Compliance now requires demonstrable control over how data flows across systems, how updates are tracked, and how access is revoked when not needed. TEFCA is pushing the industry toward a connected framework where every actor is accountable.

For product teams, this means thinking ahead. If your architecture can adapt easily to new interoperability and privacy standards, you will not just stay compliant, you will stay relevant. That is exactly how we design at Mindbowser. Compliance is not a last-minute checklist. It is a feature built into the foundation.

VI. Go-Live Readiness: What Hospitals Expect You To Have

A. Your Implementation Packet

One of the most practical sessions at Open@Epic 2025 focused on what hospitals expect from vendors when it is time to go live. The message was straightforward. Preparation is everything.

Hospitals want vendors to show up ready with a complete implementation packet. That includes your implementation guide, integration plan, details on APIs and interfaces, VPN requirements, and your change management process. You should also define clear service levels and escalation paths in case something goes wrong.

Epic’s John Pappas from Mass General Brigham shared a great insight during his session. He said, “A go-live is not a finish line. It is the beginning of your accountability.” That mindset shift is important. Once your app is live inside a hospital, you are part of their ecosystem. Your reliability and responsiveness reflect directly on their ability to deliver care.

B. Staff and Cadence

Several presenters also spoke about how vendor teams need to be staffed during implementation. Hospitals expect technical people on the initial calls, not just project managers. Someone who understands the architecture should be able to answer questions or, at minimum, take them back and return with clarity.

Having the right cadence also matters. You cannot disappear after the integration is complete. Staying engaged post-launch helps you understand how clinicians are using your product and where small tweaks could improve their workflows. Hospitals notice when vendors stay close. They also notice when vendors vanish after deployment.

For us at Mindbowser, this aligns with how we operate. Our technical leads stay connected throughout the integration and go-live phase. We believe ongoing collaboration builds trust faster than any service-level document ever could.

C. Upgrade Awareness

Another area that often gets overlooked is the impact of Epic’s regular upgrades. Hospitals expect their vendor partners to be proactive in identifying and managing these changes. Every upgrade can affect how an app behaves, especially if it relies on specific APIs or interface configurations.

Teams that plan by maintaining version control, testing scripts, and regression plans avoid downtime and frustration. Epic strongly encouraged vendors to build a habit of upgrade readiness. This is especially critical for apps that operate across multiple hospitals where versions can differ slightly.

At Mindbowser, we treat upgrades as part of our product lifecycle. Our engineering playbooks include pre-upgrade checklists and rollback plans. It is part of how we ensure that integrations remain stable and compliant over time.

VII. Architecture Patterns That Travel Across Sites

A. SMART on FHIR Is Table Stakes

One consistent message throughout Open@Epic 2025 was that SMART on FHIR is no longer a differentiator. It is the baseline. Most Epic deployments now support SMART apps out of the box, which means if your product cannot authenticate and exchange data through SMART on FHIR, you are already behind.

During one breakout discussion, Epic’s developer team confirmed that nearly all Epic instances have SMART on FHIR enabled, though configurations may vary slightly. That was reassuring, especially for vendors designing apps that need to work across multiple hospitals. The key takeaway was to design for flexibility. Your authentication and token handling should adapt seamlessly to the specific Epic instance you are connecting with.

Epic also reminded developers not to over-customize their apps for a single site. When you design integrations that rely on generic scopes and standard endpoints, your product scales faster. That aligns perfectly with how we build at Mindbowser. Our integrations follow the “one build, many sites” rule. It saves time, reduces support costs, and keeps future updates manageable.

B. Data Access Beyond APIs

Another interesting conversation at the event centered around data access options beyond APIs. Epic’s team discussed how Clarity and Caboodle databases remain essential for advanced analytics and historical data exports. These do not require an app layer to access, which makes them ideal for organizations that need to run population health reports or data science workloads.

The flexibility to pull from Clarity or Caboodle gives healthtech teams more control over how they access and process large datasets. It is also a reminder that APIs, while modern and elegant, are not the only path to interoperability. For bulk exports or historical trend analysis, a SQL-based approach can sometimes be more efficient.

Epic also clarified how updates are managed after bulk exports. The _since parameter in FHIR queries can help fetch incremental data, but it introduces additional overhead in complex systems. For now, HL7v2 remains a more reliable mechanism for continuous updates at scale. This balance of FHIR for access and HL7v2 for updates is exactly what we have found effective in our integrations at Mindbowser.

C. Messaging and Eventing

Messaging came up repeatedly in developer sessions, and it is easy to see why. Real-time data synchronization is becoming the backbone of connected care. Epic’s team discussed several evolving options such as FHIRcast, FHIR Messaging, and Subscriptions.

FHIRcast, for example, allows systems to synchronize context between multiple apps within Epic’s Hyperspace environment. It is useful for scenarios like enabling a care coordination dashboard to follow the clinician’s patient view in real time. While not every Epic instance supports it yet, the direction is clear. Context-aware workflows are the future.

FHIR Messaging and Subscriptions are also worth watching. Subscriptions can be powerful for pushing updates to connected systems, but adoption across hospitals is still uneven. The best advice I heard at the event was to design fallbacks. Build your app to gracefully switch between Subscriptions, HL7v2, or even file drops when needed.

At Mindbowser, we already follow this principle. Every integration plan includes redundancy paths to maintain uptime and consistency even when certain features are unavailable in a specific hospital environment. It is the difference between an app that works in one site and an app that thrives in fifty.

VIII. From Interoperability to Go-To-Market

A. Integrations as a Distribution Strategy

One of the most eye-opening insights I took away from Open@Epic 2025 was that interoperability is no longer just a technical milestone. It has become a go-to-market strategy in its own right. The organizations that build connectivity into their product from day one are the ones scaling faster across health systems.

I heard this directly from both Epic leaders and provider CIOs. When a hospital sees that an app integrates cleanly, handles data securely, and stays compatible through upgrades, the approval conversation shifts from hesitation to enthusiasm. A trusted integration does more than enable data flow. It opens doors. It expands your distribution channels, builds brand credibility, and accelerates adoption across new customers.

In that sense, interoperability is marketing through trust. Every hospital that successfully connects with your solution becomes a live case study. Every fast approval becomes proof of your reliability.

B. Packaging Your Integration Story

Another theme that came up repeatedly was the importance of telling your integration story effectively. Hospitals are busy. They evaluate dozens of vendors, and what catches their attention is clarity.

Vendors who package their integration details into a concise, visual, and trustworthy story stand out. That means having a one-pager that shows your data flow, your security architecture, and the exact APIs you use. It also means backing those visuals with outcomes. Hospitals care about how your app improves workflow efficiency, reduces risk, or supports clinical decisions.

At Mindbowser, we have learned that the best integration packet combines clarity with confidence. We include our architecture diagram, security documentation, and FHIR or HL7v2 endpoints all in one place. This makes it easier for IT and compliance teams to validate our readiness. It also sends a clear message: we take interoperability seriously.

C. Metrics Executives Care About

During the final panel discussion, someone from Epic’s vendor partnerships team said something that really stuck with me. “The vendors that win are the ones who can quantify their reliability.” That single line sums up how the industry is evolving.

Executives now care less about how technically complex your product is and more about how dependable it is in production. They want numbers. How long does it take from contract to first data exchange? What percentage of your integrations go live without issues? How quickly do you respond to incidents?

At Mindbowser, these metrics are part of how we measure ourselves. Time to approval, time to first data, and integration uptime are not just operational KPIs; they are selling points. They communicate that our solutions are not only compliant and secure but also dependable at scale.

The big takeaway from Open@Epic 2025 is that interoperability and go-to-market are now two sides of the same coin. When your product is built for trust and scale, every new integration becomes both a technical success and a marketing win.

IX. Field Notes and Quick Answers from Epic Teams

A. RPM, Subscriptions, and HL7v2

One of the best parts of Open@Epic is the chance to ask Epic’s technical experts very specific questions. I spent time clarifying a few topics that come up often during our client projects at Mindbowser.

When I asked about Remote Patient Monitoring (RPM), Epic’s team explained that for high-volume data, HL7v2 is still preferred. It handles streaming data more efficiently than FHIR in most production environments. That made sense given the size and frequency of device updates in remote monitoring.

I also asked about FHIR Subscriptions. Epic confirmed that while subscriptions are promising, they are not yet widely available across all hospitals. Many sites are waiting for regulatory alignment and internal validation before enabling them in production. Until that happens, HL7v2 remains the more consistent choice for event-driven updates.

Another question I raised was about keeping data current after Bulk Data exports. The answer was clear. While the _since parameter can pull incremental updates, it adds computational overhead. For continuous synchronization, HL7v2 still offers better performance and stability.

These conversations reinforced something I already believed. The most successful integrations are the ones that respect both new and legacy standards. FHIR and HL7v2 are not competitors; they are complementary layers in a real-world architecture.

B. CDS Hooks, FHIRcast, and Testing Realities

Another area that generated a lot of discussion was CDS Hooks and FHIRcast. I learned that patient-view hooks are available for testing today, which is helpful for decision-support apps that launch within a clinician’s workflow. Other hooks require collaboration with Epic’s Vendor Services team. They can help set up the right environment for testing more complex interactions.

FHIRcast, on the other hand, is now testable inside Epic’s Hyperspace environment. This is great news for developers working on apps that need synchronized context between multiple applications. I had a few side discussions about how this could be used for telehealth dashboards or care coordination tools. The potential is huge, even if full adoption will take some time.

One consistent theme across these technical conversations was that Epic’s developer ecosystem is becoming more open and collaborative. The support teams are genuinely interested in helping vendors get it right. That is a positive sign for anyone investing in long-term partnerships around Epic integration.

C. Alerting and Context

My final set of questions focused on alerting workflows and how systems can use patient context effectively. Epic’s engineers explained that integrating alert managers can be done through something called the IHE ACM PCD Profile. It uses outgoing HL7v2 ADT messages to share critical patient information like demographics, location, and care team assignments.

This allows third-party alert systems to route notifications more intelligently based on who is responsible for the patient at that moment. The setup may sound technical, but the outcome is simple and powerful. It reduces alarm fatigue and ensures that alerts reach the right clinician faster.

These details may seem small, but in a clinical setting, they make a real difference. Reliable context sharing between systems directly supports patient safety. For me, that connection between technical design and clinical impact is what interoperability is all about.