As with the previous twoarticles in this series (which I recommend you read first), this analysis of Epic’s developer programs and marketplace is for informational purposes only. The author has no official relationship with or endorsement from Epic Systems Corporation. All trademarks, service marks, and trade names referenced in this presentation are the property of their respective owners. The information provided here is based on publicly available resources and does not represent official guidance from Epic Systems Corporation.Please refer to their website and contact their representatives for the most up-to-date guidance.
There are a lucky few who live in a bubble, safe and sheltered by the virtue of selling to some niche that Epic has not penetrated. It’s a modern-day Magellan experience to stumble upon them, happily plying their trade in uncharted market waters, their business sails full of winds untouched by the storms of competition. It’s with a slight tinge of sadness, though. One can't help but wonder how long these commercial Edens will remain undiscovered, their shores untouched by the tides of corporate expansion that sweep relentlessly across the greater world.
Epic’s meteoric rise (over three and a half decades) makes it an inescapable, indelible factor for all organizations, vendors, and services in healthcare. Whether or not my earlier article convinced you of the root cause of their dominance, the fact of the matter is that applications building in healthcare are operating in their orbit. Understanding how to do so in a geosynchronous fashion to avoid catastrophic collision and Epic’s gravity well is surprisingly tricky, however: they have a large variety of app programs, processes, and marketplaces that tend to confuse new entrants and long-time operators alike.
Thanks for reading Health API Guy! Subscribe for free to receive new posts and support my work.
So, as we sit in this period of Epic’s zenith (“Pax Epic-ana”, perhaps?), this article will explain the landscape so that we all can thrive. We’ll talk about:
The programs for developing and integrating with Epic
The pathways by which applications can engage Epic health systems
Epic’s marketplace, sub-categories, and partnership frameworks
The expansion to non-traditional provider customers
While these maritime metaphors are fun, the reality on the ground is far more technical and nuanced. Let's examine the concrete pathways and programs that define how organizations actually operate within Epic's ecosystem.
An oft-repeated, apocryphal myth circulates the industry that Epic is the most painful EHR to integrate with. Like many oft-repeated, apocryphal myths, it is neither strictly true nor false in a binary sense but a mix of both, rooted instead in half-truths and confounding factors.
Enterprise Sales
A lot of the perceived pain of integrating with Epic comes from the enterprise sale. Even as they extend to smaller practices with Community Connect and Garden Plot, Epic customers are still all sprawling mega-enterprises, the biggest of the big in the world of providers, because of their single, connected system strategy. Even the smallest Epic customer is still an enterprise organization with the associated baggage of that status.
Agnostic to industry, the smaller the organization you are selling to, the more closely that sale will resemble a consumer sale. You can make quick decisions, appeal to emotion, and drive deals based on individual value perception and immediate needs. The buyer often has direct experience with the problem you're solving, can feel the pain firsthand, and has the autonomy to make purchase decisions. There's only a minimal procurement process, and implementation can start immediately. ROI conversations focus on concrete, near-term impacts rather than abstract organizational value.
However, when selling to enterprises, your sales and engagement motion is an entirely different beast than when selling to individuals or small businesses. You are suddenly suspect to the principal-agent problem, where priorities conflict between the buyer/owner of an asset and the one to whom the owner delegated control.
Suppose you have created a product that is cool and useful to someone in an enterprise organization. Unless that tool is specifically geared to the needs of an organizational leader, it is very likely your champion/user is not the buyer/decision-maker by any measure: economic, legal, or technical.
It sucks to build a solution that solves a problem for someone but then realize that person has no leverage to get your solution prioritized across their organization and that your value proposition (so critical to them) is not resonant at an organizational level. Their enthusiasm for your product gets lost in layers of bureaucracy, compliance requirements, and competing priorities. When you aggregate all the products that different health system users want, there are dozens of other vendors with a similar value prop, care improvement, ROI, or other benefits that are nipping at the heels of every major health system. What puts your app in the front of the line?
Even with a strong internal champion, you'll face a gauntlet of stakeholders: IT security needs to approve your infrastructure, legal needs to review your contracts, procurement needs to validate your pricing against market rates, and finance needs to fit you into next year's budget cycle. What makes this especially challenging is that each of these stakeholders has different, sometimes conflicting priorities. IT security might love your on-premise deployment option, but procurement prefers cloud vendors for cost reasons. Your champion in the radiology department might desperately need your solution, but the CIO has standardization initiatives that favor enterprise-wide platforms over point solutions. The CFO might see the ROI, but the risk management team has concerns about your startup's viability.
As explored in "An Epic Saga: The Origin Story," Epic becomes the natural choice for enterprise decision-makers precisely because of its integrated system architecture. Rather than managing multiple vendors and systems, buyers get a comprehensive platform with a single database, unified workflows, and built-in interoperability through Care Everywhere. While individual users might prefer specialized point solutions, the organizational benefits of standardization and integration make Epic the safer choice for decision-makers who must consider enterprise-wide implications. This creates a classic principal-agent tension: even when a tool perfectly solves an end user's problem, the broader operational advantages of Epic's integrated system often override individual preferences, even when the point solution is superior. For what it’s worth, this is not a problem that is particularly unique to healthcare - all point solutions run into it with the largest enterprises.
This problem is exacerbated by the Community Connect structure of Epic, where a larger hospital or health system extends its instance to a smaller practice or set of providers. In this case, even if you manage to sell to and satisfy all stakeholders at the smaller practice, you still need buy-in from the parent organization that hosts the Epic instance. This adds another layer of complexity, as the parent organization may have different priorities, technical requirements, and approval processes.
The parent organization bears much of the technical and operational risk of any integrated solutions since they're ultimately responsible for the Epic instance and its performance. Even if the smaller practice is willing to pay for the solution themselves, the structure of Community Connect means that the main hospital almost always acts as a gatekeeper, slowing or blocking new integrations and solutions that could benefit the smaller practice.
For example, even when a Community Connect partner is enthusiastic about adopting a new solution, technical connectivity requirements can become insurmountable barriers. For instance, a potential integration that requires Kit connectivity may be blocked by the parent organization despite the smaller practice's strong interest. Even with filter configurations in place, the breadth of access may entail a risk too high. This illustrates how technical architecture decisions that might be acceptable for independent practices become problematic in the Community Connect model, where parent organizations must protect their broader system integrity.
This creates a double-barrier where you need to:
Navigate the enterprise sales process at the smaller practice level, dealing with their internal stakeholders and approval processes
Repeat the process with the parent organization, which may have even more stringent requirements and less incentive to move quickly since they don't directly benefit from your solution.
Good news - it gets worse. Many Community Connect programs are governed by dedicated teams within the enterprise that operate with their own distinct charter and incentives. Unlike the enterprise IT team, which is motivated to meet various stakeholder needs, these Community Connect teams operate on separate balance sheets and are often chartered to keep costs low while maintaining a vanilla Epic implementation, pushing them to focus on standardization and simplicity. This means that even if a solution might benefit Community Connect physicians, the CC team may block it unless it clearly helps them sell more Community Connect licenses or reduces their operational complexity. The rare exceptions are typically high-value, loosely affiliated groups, like surgical practices that use hospital operating rooms but maintain independence - in these cases, the CC team may be more flexible to keep these strategic partners satisfied.
The Product-Led Growth Fallacy
The enterprise sale problem exists in all industries but is exacerbated by regulation (specifically HIPAA) in healthcare. In other sectors, it is increasingly common to circumvent the enterprise sale problem through the use of product-led growth: individual users or small teams can adopt a tool for free or at low cost, prove its value within their sphere, and gradually expand usage until it becomes a de-facto standard that the enterprise must eventually support. Think of how Slack, Zoom, or Figma gained enterprise penetration - they started with bottom-up adoption by individual teams who loved the product, creating organizational pressure to formalize the relationship.
However, in healthcare, HIPAA creates a forcefield around this strategy. Under HIPAA regulations, a Business Associate Agreement (BAA) typically needs to be signed by someone with proper authority to legally bind the organization, not individual providers or employees. A BAA creates specific obligations and liabilities for the organization regarding Protected Health Information (PHI). Thus, any BAA must be between the application and the covered entity/business, not the covered entity’s users.
Despite this, there are some very early-stage startups that implement "provider-level BAAs," often as click-through agreements. Generally, these end up running into legal, operational, and security walls quickly with large enterprises.
The unfortunate result: You can't just let individual doctors or nurses start using your tool with patient data, even if it would dramatically improve their lives. When PHI is involved, you will encounter enterprise-wide security reviews, BAA agreements, and formal procurement processes. There's no real way to bypass the organizational gatekeepers because they are legally mandated to control the flow of sensitive data.
This regulatory barrier means healthcare technology vendors are largely stuck with traditional enterprise sales motions - lengthy cycles, multiple stakeholders, complex compliance requirements, and high customer acquisition costs. The end users who would benefit most from innovation often have the least say in technology decisions, while those furthest from day-to-day patient care hold the most sway over purchasing.
Application Workflows
Beyond the enterprise sale factor, your perception of Epic's integration difficulty often comes down to what your specific application is doing. Different workflows need different levels of system access, and some integration patterns are significantly more straightforward than others.
As you examine a wide range of applications, a general rule of thumb emerges: the closer you get to Epic's intellectual property and core functionality, the more challenging the integration becomes, which pattern matches their history around intellectual property and the scars they have there.
A hierarchy of difficulty manifests across several common integration patterns:
Standardized Data Access: Patient-facing applications that only need access to standard clinical data can leverage USCDI APIs, making deployment across Epic sites relatively straightforward. These standardized interfaces, designed for patient health record access and mandated by federal regulation, provide a consistent integration pattern regardless of the underlying Epic customizations. A personal health record only pulling basic health information will find integration relatively painless.
For example, an application that helps patients track their medications or view their lab results can rely on standardized FHIR resources like MedicationRequest or Observation. Since these endpoints are required by federal regulations, they work consistently across Epic installations with minimal site-specific configuration.
Operational Integration: Applications like scheduling systems or order entry that need to interact with Epic's operational workflows face moderate complexity through a combination of standards-based integration points and Vendor Services web services. While these interfaces are often well-defined, they require more understanding of each organization's specific workflows and reference data.
Take a scheduling application as an example: beyond just finding open slots, it needs to understand each organization's appointment types, provider schedules, location hierarchies, and scheduling rules. An order entry system must map to the organization's specific order catalog, know which orders require authorization, and understand complex routing rules. These integrations work but require significant effort to accommodate each organization's unique configurations.
Deep Analytics or Financial Workflows: Applications requiring deep analytical capabilities often face more challenges. These integrations typically require a more extensive understanding of each organization's unique data structures and workflows. Population health analytics tools or research platforms often fall into this category. Additionally, most of Epic's billing/payments APIs are fully private and aren't well supported by HL7.
Consider a population health platform that needs to identify high-risk patients and track quality measures. It must understand each organization's custom documentation fields, diagnosis coding practices, and quality measure definitions. Similarly, revenue cycle applications need deep knowledge of each organization's charge routing rules, payer contracts, and custom billing workflows. These applications often require direct database access through Clarity or Caboodle, adding another layer of complexity.
The integration challenges don't just stem from technical complexity - they often reflect Epic's strategic priorities and market position. For standardized data access, Epic faces regulatory pressure and market demand for interoperability, leading to well-supported APIs. Operational integrations touch core workflows but generally complement rather than compete with Epic's functionality, resulting in moderate support. Deep analytics and financial workflows get closest to Epic's intellectual property and competitive advantages, explaining the higher barriers to integration.
The wide variety of workflows explains why developers have such differing opinions - it all ultimately comes down to whether your specific needs are accommodated or resisted. An application that stays within well-defined boundaries will have a smoother experience than one pushing into more sensitive territory. Understanding this hierarchy helps developers set realistic expectations and choose appropriate integration strategies for their use cases.
Implementation Variance
Another significant source of integration complexity with Epic stems from implementation variance across different healthcare organizations. In general, all enterprise software exhibits customization across customers - even modern SaaS platforms rarely run truly identical instances. For instance, every Salesforce instance has customization on two fronts:
Pre-built tables (Standard Objects) like leads, accounts, and contacts that are uniquely populated for each business
Entirely bespoke tables (Custom Objects) set up by customers or their System Integrators to meet the specific requirements of the business.
Unsurprisingly, EHR instances, especially Epic, parallel other enterprise B2B software with their customization happening at similar levels. As part of their initial implementation and ongoing maintenance, Epic customizations generally fall into four main categories:
User Interface and Workflow Customization: Organizations extensively modify the way Epic presents information and guides user actions. This includes custom templates for notes and orders, specialized activity views for different departments, user roles, custom navigator layouts, and unique workflow rules that determine how tasks route through the system. While these customizations primarily affect the user experience, they add some cognitive load for application developers trying to understand how their tools might work alongside Epic.
Business Logic and Rules Engines: Epic's architecture includes powerful rules engines that govern automated workflows, event triggers, order transmission, and charge routing. These configurable rule sets differ dramatically across health systems and determine what downstream actions occur without user intervention. Changes to these rules, even seemingly minor ones, can have system-wide consequences. The complexity of these engines means that specialists who understand them are in high demand, and successful integration often requires careful coordination with these rules systems.
Foundational Reference Data: Each organization maintains its own foundational data that defines the basic building blocks of its health system, akin to Salesforce’s Standard Objects. This includes provider directories, orderable items (medications, labs, imaging studies, etc.), note types, department lists, and location hierarchies. These differences in reference data mean that even seemingly simple integrations like "send orders into Epic" require careful mapping and maintenance of these foundational elements.
Custom Data Elements: Beyond the standard Epic data model, organizations can create entirely new data structures through tools like SmartData Elements. These custom fields and forms allow organizations to capture unique information required by their specialty departments, research programs, or regulatory requirements. Similar to how Salesforce customers create Custom Objects, Epic customers can build entirely new data structures that may be unique to their instance
This variance is further compounded by Epic's release cycle model. Unlike SaaS products that can push updates continuously to all users, Epic operates on a more traditional enterprise software model where organizations choose when to upgrade and which features to enable. At any given time, different organizations may be running different versions of Epic, each with its own unique customizations layered on top.
The practical impact for vendors trying to integrate with Epic is that success at one organization doesn't necessarily translate to success at another. For example, you might build a rock-solid integration with Hospital A's Epic instance, only to find that Hospital B's implementation has different workflows, reference data, and custom data elements. What worked perfectly in one environment almost always needs significant reworking in another.
Platform Expectations vs Reality
If customization is common to all systems of record, then why are application developers so shocked by it as they attempt to integrate with Epic? A few possible reasons:
On-premise vs. SaaS: Each Epic installation is not a partition of a single SaaS platform but a unique instance deployed on-premise or in a separate cloud hosting, extensively customized to meet specific needs and workflows. This lack of centralized control leads to further variance as each organization independently manages its own infrastructure configurations, security policies, and system optimization decisions.
Consumer Platforms: Some developers may lack experience with B2B software and be used to designing and building against relatively homogeneous platforms. Consumer-facing platforms, for instance, have much less variance in configuration, as consumers are rarely empowered to create their own data structures. As a result, you can develop more reliably against iOS or Android than any B2B software.
Supporting Ecosystem: Most business apps are the way Epic is, with version skew and customizations, but few (or maybe none) are the same walled garden of documentation and design. Other industries’ B2B platforms ultimately provide significantly more documentation and tools to enable application developers to understand and deal with each customer’s variance. This means that dealing with the variance, while present, is just a question of the developer’s own investment and effort, making it somewhat invisible/built-in. Without this, the pain is delegated to EHRs’ provider customers to help applications understand enough to integrate.
The Big Picture
You are not Charlie Day in the mail room, connecting the red string. This is the simplest form of all the external-facing programs and initiatives Epic offers. While we’re going to define and explain them all as an enduring artifact for the sake of thoroughness, most of the focus will be on “Developer Programs” (offerings aimed at providing application developers with tools and value-add services) and “Marketplaces,” (aimed at showcasing approved products and services to health system customers) as that’s where organizations often have the most confusion.
Today, Epic has three overlapping developer programs:
Open Epic: Epic's self-service documentation for developers focused primarily on standards-based interfaces like HL7v2, X12, and NCPDP, along with some open web services
Epic on FHIR: A subset of Open Epic focused on their implementation of the FHIR standard and associated frameworks like SMART on FHIR and CDS Hooks, offering more robust developer resources than Open Epic but with significant API constraints
Vendor Services: Epic's comprehensive program for application developers seeking deep integration with Epic's software ecosystem through proprietary Web Services and Kit APIs
They have Epic Showroom as their marketplace for products (applications) and services (internal and external consulting services), with three sub-categories for products:
Connection Hub: Applications live with one or more Epic sites by any means, which can be self-attested by applications
Toolbox: Applications that are in specific categories where Epic offers a “Blueprint” (Epic’s recommended practices for integration)
Workshop: Specific categories where Epic is co-developing APIs together with two (or more) vendors at a time. After development, Epic releases these APIs for general availability within the other programs.
Developer Programs
As hinted in the “Implementation Variance” section, developers only want one thing, and it’s disgusting: platforms that are geared to help them connect and coexist with mutual customers. Platform businesses commonly offer services to support that need through developer programs:
Superlative documentation: The ability to understand the core data concepts and integration points of an existing technology ecosystem offloads this task from customer and platform support staff
Testing tools: Tools to validate message formats, data structures, transport methods, and integration security/authorization protocols against platform specifications all enable developers to catch and fix integration issues early and not bog down implementations
Sandboxes: Access to a customer-like environment to validate end-to-end functionality before ever reaching out to potential customers or partners allows for a deeper knowledge of workflows and accelerated application deployment
Developer Support: Dedicated technical support through forums, chat, office hours, or ticketing systems where developers can get expert help with integration challenges is necessary when things go wrong
Yet this seemingly basic need - the ability to front-run technical validation before engaging a customer - remains surprisingly rare in healthcare. Until the advent of APIs roughly a decade ago, the idea of self-service testing, openly available documentation, and all the other trappings of platforms we take for granted was non-existent. In a pre-API economy world with no partnership opportunity, the path for applications to connect was mediated through a mutual customer.
Epic, like most electronic health records, pursued integration by creating interfaces and imports/exports. These capabilities created well-defined formats for data output or input. The bulk they created were in the dominant standards of the time: HL7v2, X12, NCPDP, DICOM, and more. These capabilities for input and output were made available to Epic’s health systems, either as part of the “foundation system” (the base build installed during initial implementation) or as additional licenses for more obscure inputs/outputs.
As we evaluate Epic's various developer programs, we'll evaluate and score each of them along those lines - do they fully document the integration points and core concepts? Are developers able to test those integration points before engaging a customer? Do developers have access to a sandbox environment to validate their integrations? And do they provide adequate technical support through modern channels that developers expect? This framework will help us objectively understand how well Epic's developer programs meet the needs of modern application developers seeking to integrate with their platform and where they can do better.
Integration Steps
As detailed in The Integration Illusion, all applications looking to integrate with an EHR can be scoped into three core categories of exchange:
Enrollment: How does an application get the list of patients relevant to them? Common enrollment mechanisms include orders for a specific procedure, all visits scheduled in specific departments, or just all patients that the organization creates
Supplementation: What data does the application need for enrolled patients? Generally, applications need additional data beyond the enrollment information, such as a patient’s medications, allergies, problems, lab results, or notes
Writeback: What needs to be pushed back into the EHR to close the loop or reduce double documentation? Oftentimes, this is as simple as a note or PDF document, but more involved integrations may include vitals or discrete results
As we look at Epic’s developer programs, these concepts are particularly relevant in understanding where different offerings are mature and where they still need work.
Open Epic serves as Epic's self-service resource for developers and others seeking to understand Epic's interoperability capabilities. The platform primarily focuses on standards-based interfaces like HL7v2, X12, and NCPDP, along with some open web services. While it represents a step toward transparency, its effectiveness as a developer program is mixed.
Technical Capabilities: Superlative (5/5)
Epic has the largest library of legacy standards integration points. For instance, there are 99 HL7v2 interfaces and 46 X12 interfaces on Open Epic. We should give credit where credit is due - there are many EHRs that don’t even have basic interfaces, and Epic has invested a lot of time and effort into creating these inputs and outputs.
Documentation: Mixed (2/5)
Epic gets a few points for publicly documenting their legacy interface specifications - a level of transparency notably absent from competitors like Oracle and Meditech (with athenahealth being the only other major EHR vendor providing similar documentation).
Necessary but in no way sufficient
However, the technical specifications have significant limitations. The documentation lacks a clear distinction between standard and customer-specific configurations, provides minimal context around implementation patterns and best practices, and offers a limited explanation of core data concepts or triggers that send outbound event messages. Without deeper technical detail or workflow documentation, developers often struggle to understand how to properly implement these interfaces. Often, there's a hard wall preventing 3rd parties from reading some documentation if there's a perception that Epic Build is involved. Documentation often points to relevant Userweb links, but vendors are unable to directly view the content themselves due to Epic's strict access controls.
Testing Tools and Sandbox: Limited (1/5)
The platform's testing capabilities are non-existent. Notably absent are validation tools for HL7v2, X12, or other legacy interfaces, as well as any capabilities for message format, transport, or security validation.
Open Epic provides no sandbox environment for developers to validate their integrations. Without access to a customer-like environment, developers cannot test end-to-end functionality before engaging with potential customers or partners. This gap significantly impacts developers' ability to understand workflows and accelerate application deployment.
Developer Support: N/A
Technical support through Open Epic is nonexistent, with all support channels gated behind the Vendor Services program. There are no developer forums, community resources, office hours, or direct channels for getting expert help with integration challenges. This leaves developers dependent on either customer relationships or Vendor Services membership to resolve technical issues.
Cost Structure
The platform is free for application developers, though health systems may incur costs depending on their interface licensing agreements.
While Open Epic offers an industry-leading volume of integration points and deserves recognition for listing them all publicly, it falls short of modern platform expectations for developer enablement. Its primary value lies in providing basic interface documentation, which will tell you at a very high level if an integration of a particular type exists. However, the ability to test and understand these interfaces is a standard expectation in this era. Given the gap, developers invariably need to supplement this with customer relationships or Vendor Services membership before they can build successful integrations.
Epic on FHIR represents Epic's implementation of the FHIR standard and associated frameworks like SMART on FHIR (a technology for single sign-on) and CDS Hooks (a pattern for invoking decision support from within a clinician's workflow). As the FHIR toolbox section of Open Epic, it offers more robust developer resources than its parent platform (Open Epic), though it has its own set of barriers and problems.
Technical Capabilities: Strong (4/5)
Epic's FHIR implementation showcases both trailblazing strengths and confounding limitations. The platform offers an industry-leading number of FHIR endpoints, including 11 Create interactions. However, several constraints impact its utility as a complete integration solution. While Epic leads the industry in advanced context synchronization features like CDS Hooks and FHIRcast (a standard for context synchronization between applications) support, their vanilla FHIR API has significant feature gaps.
Enrollment workflows cannot be accommodated via the FHIR API suite, as they often require patient ID as a parameter when querying, and there is no “push” capability. This forces many applications to seek additional integration patterns like HL7v2, adding significant development lift and cognitive burden.
Because most read and search operations require a patient ID, data supplementation is nearly broken. For each enrolled patient, applications must issue hundreds or thousands of API calls to update relevant resources patient-by-patient.
Getting relevant updates of data for a patient requires applications to manually compare and sort API responses, as Epic does not support the lastUpdated search parameter or metadata element
The Epic Bulk FHIR implementation is not particularly bulk and is frustratingly hamstrung by a limitation on the total number of patients applications should include.
While Epic offers more FHIR-based write capabilities than many EHR vendors, these remain more limited than their HL7v2 counterparts. For instance, while Observation is supported, lab results are not, necessitating the use of HL7v2. Similarly, the DocumentReference.Create has this warning:
The upcoming HTI-2 subscription capabilities promise to address some current limitations, particularly around enrollment and ongoing supplementation, that will allow many applications to be built solely in the FHIR ecosystem. However, for now, very few applications can integrate using only Epic on FHIR capabilities - most require additional integration patterns through Vendor Services or legacy interfaces, subjecting them to the deficiencies of those programs.
Documentation: Moderate (3/5)
The documentation available through Epic on FHIR is notably more comprehensive than Open Epic's general interface documentation. Beyond basic specifications, it provides detailed guidance on application registration, organizational management, and credential handling through client IDs and secrets. The documentation effectively covers both technical implementation details and administrative processes, although it could be improved with trivial formatting changes:
The pictured FHIR response is in XML format (whereas developers typically prefer JSON) and lacks standard indenting for readability.
Testing Tools and Sandbox: Limited (2/5)
Epic on FHIR’s tools only enable basic validation of FHIR-based integrations.
The FHIR test environment, while present, is relatively basic compared to modern API platform expectations. It is not a user interface - it simply provides an environment and test data for FHIR capabilities but lacks the depth needed for comprehensive integration testing, especially for more complex workflows.
Epic does offer a Test Harness, including a newer Mac version, which is a user interface tool to test SMART on FHIR launches and CDS Hooks integrations. While it’s valuable in being able to do some initial testing, it lacks advanced features like CDS Hooks’ suggestions. Ultimately, it is not a full sandbox by any means and only vaguely resembles Epic’s actual UI.
Developer Support: Limited (1/5)
Support remains minimal, though slightly better than Open Epic, due to the more structured nature of the FHIR standard and associated frameworks. Although there is no change log page to understand new or updated APIs, Epic on FHIR does send notification emails about any potentially breaking API changes to developers.
Cost Structure
Like Open Epic, Epic on FHIR is free for application developers, though health systems may incur costs based on their specific licensing agreements and implementation choices.
Vendor Services represents Epic's most comprehensive attempt at providing a program for application developers seeking deep integration with Epic's software ecosystem. As the successor to the now-defunct App Orchard and App Market programs, it provides access to Epic's proprietary integration capabilities, more detailed test capabilities, and direct Epic support.
The Slow Death of Epic’s App Programs
Vendor Services is not Epic’s first attempt at an application program and is the heir to a lineage started withApp Orchard in 2016. This program notably charged developers based on revenue, taking up to 30%, and was plagued by complaints of slow processing of applications, including outright pauses on new applications for months at a time.
"There was this misconception and market confusion around what did it mean to be in the app market. Some folks thought it was co-development with Epic, or a seal of approval from Epic or a recommendation from Epic. It never really was meant to be to that level," Nate Bubb, technical services lead at Epic, said in an interview.”
Epic had realized that they had commingled their application developer program (aimed at providing application developers value-added services and tools) with their marketplace (aimed at showcasing approved products and services to health system customers). By pausing App Orchard, they removed the “public display” of applications, allowing them to recreate the marketplace concept to be crystal clear about co-development, recommended applications, and seals of approval.
In this transition, they also somewhat silently continued the application developer program pieces. As noted in the article:
According to Epic executives, no connections will be impacted, and vendors receiving services, APIs and testing tools in the app market will continue to do so via vendor services
Thus, Vendor Services was born from the vestigial remnants of the App Orchard.
However, the unfortunate reality is that Epic slowly gutted the Vendor Services program, hollowing it out in terms of functionality and service. We’ll address the many reasons (some logical, some confusing) for these changes in the next article in this series, but regardless of the rationale, the ground conditions for developers are objectively worse than it was under App Orchard:
Discoverability of APIs: Now, an opaque API request form process is needed instead of an open library page of available web services and Kit APIs
Technical support: Now, an asynchronous listserv is backed by a shared TS process instead of direct technical support staffed for applications
Build guidance: Epic will no longer create setup and support guides, the written documentation about configuration, build, and setup related to specific applications
Build deployment: Epic will no longer create “turbochargers,” which were packages of all the configurations and build in Epic related to an application
Billing: Shift from revenue-based billing to usage-based pricing for web services and Kit APIs
Conferences: Epic used to hold an annual conference for developers during the App Orchard period, which was beneficial for knowledge sharing and networking
The other unfortunate reality is that the cognitive burden and emotional baggage from these prior iterations confuse not only a lot of developers but also a lot of Epic health system customers. Even today, it is far too frequent to have an Information Technology lead at a hospital tell an app, “We’ll only consider you once you get approved by Epic and listed in the App Orchard”, despite the facts that the Vendor Services program has no direct connection to being shown in Showroom and that the AO program has been discontinued for almost 3 years.
These changes have had another subtle but significant impact on the marketplace: they've effectively reinforced the position of incumbent third-party vendors. Developers who established their Epic integrations 3-5 years ago under the previous programs not only benefited from better support, API discoverability, and fewer barriers to entry at the time but have also had these advantages grandfathered in. New entrants now face a much steeper climb, particularly given the requirement to secure multiple enterprise customers as advocates before gaining access to crucial APIs. This creates an artificial moat around established vendors, making it increasingly difficult for innovative newcomers to compete on technical merit alone.
Technical Capabilities: Limited (1/5)
Vendor Services offers four main integration mechanisms beyond standard interfaces:
Web Services are Epic-specific APIs that extend beyond what's available through standard interfaces like FHIR or HL7v2. These proprietary APIs often enable deeper integration with Epic's workflows and data models, such as understanding open slots for scheduling, manipulating the Inbasket, posting external payments, or updating the problem list directly.
Kit offers SQL-oriented APIs for connecting to health systems' normalized reporting databases (Caboodle), enabling analytics and reporting use cases. However, Caboodle is a simplified and normalized data schema, so it is often missing the full data that would be available in the raw reporting tables (Clarity). Additionally, the usage-based pricing model can make these APIs prohibitively expensive for applications requiring frequent data refreshes. Kit also only provides access to standardly released columns & tables.
Imports are flat file formats that allow for the upload of large numbers of records into health systems’ Epic environments via utilities. Typically, this is used for foundational data or large amounts of content and may need to be run manually.
Clarity connections enable Developers to access certain reporting information directly from Epic’s raw reporting database (Clarity) rather than the normalized data warehouse (Caboodle). These connections are historically fairly rare, given the intellectual property considerations inherent to seeing Epic’s data schema (and Epic’s reservations with 3rd parties and their IP).
It’s difficult to score the technical capabilities given they aren’t readily accessible, but applications with common use cases like digital front doors and ambient scribes often run into walls here. From a technical perspective, they are relatively easy to use once you are granted access.
Documentation: Limited (1/5)
Vendor Services provides documentation and tutorials covering Epic's proprietary Web Services and Kit APIs. The documentation explains core concepts, integration patterns, and technical specifications in greater detail than Epic's public platforms. However, Vendor Services documentation often links to Userweb content. Often there's a hard wall preventing 3rd parties from reading some documentation if there's a perception if Epic build is involved. This adds friction and pain to the overall process.
Additionally, as mentioned, the transition to Vendor Services from App Orchard entailed the removal of API discovery, meaning that applications must submit an Interoperability Request to Epic’s technical support before being granted access to specific API transactions for your use case.
This has a strong chilling effect on applications’ ability to self-service. Ostensibly, this decision and process intends to steer 3rd parties in the right direction to use the appropriate integration pattern for a specific use case. However, in practice, the slow, opaque bureaucracy tends to obfuscate and significantly delay developers’ ability to integrate with APIs an application needs or that a customer specifically asks for.
This practice has drawn increasing scrutiny in the context of information blocking regulations - while Epic maintains this is a necessary technical governance process, many developers and healthcare organizations view it as a potential form of information blocking, particularly when Epic denies or delays access to APIs that would enable the sharing of electronic health information that their provider customers have specifically requested.
Testing Tools and Sandbox: Moderate (3/5)
The platform includes a "sandbox" environment for testing tools, though it's more limited than what was previously available through App Orchard. The testing capabilities primarily focus on Web Services and Kit API validation, providing developers with basic tools to verify their implementations. While Vendor Services provides some sandbox capabilities, they're notably less robust than what modern API platforms typically offer. The environment allows for basic testing but may not fully replicate the complexity of production implementations.
Perhaps most problematically, the sandbox environment provides just enough functionality to give developers a false sense of confidence, only for them to encounter significant unexpected challenges during their first actual customer installation. This disconnect between testing and production environments can lead to costly delays and complications that weren't apparent during the development phase.
Epic is somewhat unique in this regard. Oracle Health, athenahealth, and other major EMRs will actually let you see their product/EMR itself. The biggest issue for Open Epic and all developer programs is the lack of ability to make their own test patients. Developers are dependent on Epic's test sandbox patients, which are shared across all Vendor Service members. They also have to ask an Epic representative (at a high hourly rate on par with some attorneys) for many standard testing actions, such as supplementing this environment with additional or better test data or triggering outbound interface messages. Oftentimes, validation of messages by Technical Support is a manual process over email, not actually over a real interface. All this amounts to more cost to applications for tedious, rote work by Epic Technical Services. Both developers and Epic would benefit from investment in more self-service tooling here.
Developer Support: Declining (2/5)
On the plus side, support tickets through Epic’s Sherlock as a feature of Vendor Services are a good way to access Epic personnel, which many said is significantly better than the equivalent Oracle Health experience. However, some worry that even this functionality may be deprecated, shifting support solely to the shared developer forum, which many described pejoratively as a “ghost town.”
I feel a bit like a broken record, but I do want to drive home this point: developer support through Vendor Services has seen significant reductions compared to its App Orchard predecessor. The previously staffed Technical Services team has been replaced with a listserv, and the API discovery process has become completely opaque, as the "Interoperability Request" system now functions as a black box that returns a handful of APIs, often with limited explanation or context. Epic recommends securing support from 2-3 customers before submitting API requests, shifting the burden of validation to developers and their clients.
Cost Structure
Vendor Services implements a multi-layered pricing model:
Annual membership fee ($1,700)
Support fees
Transactional API fees, which can become substantial for high-frequency usage
This represents a shift from App Orchard's revenue-sharing model to a more predictable but potentially costly structure. While the base fees are lower than App Orchard's revenue share, the transactional costs can make certain use cases economically challenging, particularly for applications requiring frequent data refreshes like analytics.
Health systems may incur additional costs depending on their Epic licensing and implementation choices.
Epic’s “Marketplace”
Through Showroom, Epic's newest marketplace interface, healthcare organizations can discover various services, products, and partners that work with Epic. To that extent, it serves primarily as a discovery platform for Epic's healthcare provider customers, not application developers.
Within this ecosystem, third-party application developers’ products can be listed on the “Products” page under the “Products & Services” section. Several partnership tiers define different levels of integration capability and validation for the third-party products Epic lists here:
Connection Hub
At its most basic level, Connection Hub provides verification that a product has successfully integrated with at least one Epic customer. The program offers a straightforward way for vendors to demonstrate their Epic connectivity to prospective customers.
The value proposition is simple: vendors can definitively show prospects they have connected to an Epic site successfully. With a modest annual fee of $500, vendors can maintain their listing without necessarily participating in other Epic programs like Vendor Services. I’m continually shocked at how some vendors have a listing but don’t fill it out fully. This is an almost free resource for vendors, so the trivial work of describing what an application does, adding screenshots, and filling out the app questionnaires seems worth the investment.
However, products must maintain at least one live customer connection to be listed. Epic is explicit that a Connection Hub listing represents verification of connectivity but is not a sign of their approval or even inclusion in the VS program. As one wise sage predicted when they deprecated App Orchard and launched Connection Hub:
🚨 How to get listed in Epic’s Showroom 🚨
If you didn’t gather from the previous paragraph, this callout is to make it clear and simple: go live with one Epic customer.
You can join Vendor Services, but you don’t need to. You can connect through FHIR, HL7v2, web services, and flat files - it does not matter which format. The only thing between you and that sweet, sweet customer-facing listing is just getting live with your first customer.
If you connect through FHIR APIs or Vendor Services APIs, your listing is somewhat automated, but if you use legacy connectivity like HL7v2, you’ll need your customer to manually mark your connection as live for the listing to become active.
Toolbox
Toolbox represents Epic's mid-tier partnership program for applications that complement rather than compete with Epic's core offerings. This program is designed for vendors building solutions in specific categories where Epic wants to ensure consistent integration patterns through their "Blueprint" specifications.
If you’re curious if this tier is for you, you simply need to see if what you do is listed in their Toolbox categories here. These are very specific classifications like “Bedside TV Hardware,” “Hospital Utilization Review Creation,” and “Fully Autonomous Coding.” Epic’s intent is that it should be very obvious to read the category and pattern match what you are creating to the list:
The primary value comes from access to proprietary APIs that enable deeper integration capabilities and a higher-tier partnership designation. However, this access comes with significant commitments. Vendors must maintain Vendor Services membership and are subject to Epic's non-compete provisions. The cost structure includes substantial fees for API usage, and some categories may incur additional per-customer charges or revenue-sharing arrangements. When an application uses a Toolbox Blueprint, it must be “standalone,” with no bundling of other products and services. This last requirement is particularly irksome in that it is incongruous with Epic’s own behaviors, as the vast majority of their own software comes bundled together.
Reading tea leaves a bit, but it feels like Epic intends to create more and more categories here as Interoperability Requests come in, creating more streamlined and defined pathways to follow and rails to use. In some ways, this is a win-win. For Epic, this eases their support burden, as they have well-trodden paths to point to for applications doing specific workflows. For developers, that can be relieving - if your use case is served, then you have crystal clear steps to follow to integrate. However, it doesn’t change the fact that without the open discoverability of APIs, there’s little room for applications to differentiate from one another.
A Toolbox Filled with Complements
In tech, every product has substitutes and complements. A substitute is a product that can replace another product because it serves a similar purpose or satisfies the same need. When the price of one product rises, consumers tend to buy more of its substitute. For example:
Netflix and Hulu are substitutes for streaming entertainment
AWS vs. Azure vs Google Cloud are substitutes for cloud platforms
iPhone and Google Pixel are substitutes for smartphones (unless you’ve been fully brainwashed by Tim Cook)
Complements are products typically used together - when demand for one increases, demand for the other increases, too. When the price of one falls, people buy more of both. For example:
Smartphones and mobile apps
Databases + ORMs (PostgreSQL + Prisma)
Cloud platforms and container orchestration tools like Kubernetes and Docker (if you are a sicko who uses containers)
It is a well-known technology strategy to commoditize complements, as a company benefits by making the complement as cheap and widely available as possible. Microsoft famously kept their operating system non-exclusive to help drive down PC hardware costs - they wanted computers to be cheap so more people would buy Windows. Google took this even further by making Android free for smartphone manufacturers, ensuring people would have devices to use Google Search and see their ads.
As we look at the categories in Toolbox, there’s a case to be made that all of them are specifically complements - they are functionalities that pair with EHRs well, but that Epic specifically does not do and probably will not do:
Physical Infrastructure: Bedside TV Hardware, Infusion Pumps, Payment Devices, Real Time Location Systems (RTLS), and Point-of-care devices all represent physical hardware that enhances the EHR's utility but requires specialized manufacturing expertise.
Specialized Knowledge Services: Clinical Knowledge Sets, Oncology Clinical Pathways, and Imaging Appropriate Use Criteria provide specialized medical knowledge that complements Epic's workflow capabilities but requires constant maintenance by subject matter experts.
External Service Connections: Community Resource Network, Emergency Medical Services Transportation, Interpretation Services, and Outpatient Pharmacy systems connect the EHR to external service providers that Epic doesn't want to become.
Operational Support Systems: Computer Telephony Integration, Payment Processing, and Printing Output Management handle operational functions that are essential but peripheral to the core EHR functionality.
So whether they are cognizant of it or not, Epic is commoditizing these complementary products through standardization and competition. By establishing recommended connection practices and making Toolbox an “inclusive program where many vendors who make a product in an eligible category can participate," Epic deliberately fosters competition among vendors in each category. Notably, these applications have limited options to differentiate if using a Blueprint, given the prohibition against bundling with other products or services. This drives down prices and margins for complementary products while increasing the value of Epic's core EHR system.
Workshop
Workshop represents Epic's highest tier of product partnership, reserved for select vendors co-developing deeply integrated solutions with Epic. The goal of this tier is for Epic to get adequate feedback when developing new integrations. Thus far, the limit has been two vendors per category, although this could be more for future categories.
The program currently focuses on specific domains:
Ambient Voice Recognition: Partners for the newest health tech gold rush, AI scribes, with Abridge and Nuance DAX as the current co-developers. These solutions go beyond simple scribing and integrate deeply with Epic to support clinical workflows through features like pre-charting, problem-based formatting, automated clinical task documentation, and multilingual encounter support.
Patient Feedback & Insights: Partners that integrate advanced patient experience surveying and analytics directly into Epic workflows, withPress Ganey andQualtrics as the current Workshop members. These solutions enable healthcare organizations to collect patient feedback through MyChart, surface real-time insights to care teams within their workflows, trigger automated service recovery through Cheers, and publish provider reviews in MyChart Provider Finder.
Contact Center: Partners that extend Epic's Cheers platform with enterprise-grade patient engagement capabilities, withGenesys Cloud andTalkdesk as Workshop members. These solutions provide comprehensive contact center functionality, including AI-powered virtual assistants, omnichannel routing, automated patient verification, self-service options (appointments, payments, prescriptions), and deep Epic integrations that surface patient context to agents.
Smart Rooms: Currently unlisted on the Showroom page but announced at UGM, this is somewhat like the inpatient version of AI scribes, where multimodal inputs (sounds, video, images) all feed into documentation about the patient’s condition, reducing nurse burden.
While Workshop offers the deepest level of integration and collaboration with Epic, it's effectively out of reach for most applications. Epic typically selects market leaders that are already well-established with their health systems for Workshop partnerships, taking on a handful of vendors per category (generally two but up to as many as they need to co-develop properly). Beyond the standard vendor services requirements, workshop partners face substantial costs due to potential warranty requirements, equity arrangements, and revenue-sharing agreements. Additionally, any APIs developed through Workshop must be made available to other applications to comply with information-blocking regulations.
Simply put, most organizations would be better served focusing on building successful integrations through standard channels rather than chasing the unattainable Workshop status.
The progression through these tiers represents increasing levels of both opportunity and obligation. Most vendors will find Connection Hub or Toolbox sufficient for their needs, with Workshop reserved for strategic partnerships in specific domains where Epic seeks to develop deep, differentiated capabilities.
Friends Close, Enemies Closer?
Workshop was a very surprising development for many people, including myself. As I’ve written about, Epic has long been wary of partnerships for a variety of historical and cultural reasons. So, the very public announcement of a program of co-development (originally titled “Partners and Pals”) was shocking.
Many complained (and still complain) about Epic playing kingmaker and anointing specific victors in emergent, high-value categories where they have equity or revenue share to benefit. Perhaps the cynicism is warranted, but the messaging from Epic has very clearly been that everything developed within the Workshop program will be released within the appropriate categories for use by any other vendor.
It is possible they may act differently than they say, but if Epic codevelops APIs for use with one partner and does not make them available to equivalent applications that their health system customers want to use, they will be restricting the flow of EHI with none of the information blocking exceptions applying and have numerous complaints, fines, and possibly lawsuits at their door. To avoid that, Epic could better communicate available APIs, including the planned release of API work they are developing and piloting with Workshop customers. The current opaqueness of Vendor Services lends itself to more nefarious optics of gatekeeping, favoritism, and information blocking.
Taking a step back, the pure-play theory of kingmaking also doesn’t really make a ton of sense from a strategic perspective and certainly does not fit with the hypothesis we posited in regard to Toolbox. Ambient voice, patient feedback, and contact center are all seemingly complements and not substitutes. Why keep these particular complements close but commoditize others?
Epic has a lot to build but does not want to lose ground by being slow to deploy best-in-class software. Beyond that, we’re again staring deeply at the tea leaves, but my guess is that it comes down to two factors:
Uncharted paths - Some of these categories, like Ambient and Smart Room, are truly unprecedented emergent categories where the workflows are changing and evolving rapidly. Compared to more mature workflows that we see in Toolbox, where Epic has already created APIs or knows what inputs and outputs to expose, Epic needs partnerships to figure out the right things to build.
Resource constraints - While patient feedback and contact center capabilities could potentially be built as part of Epic Cheers, Epic likely recognized they couldn't develop everything needed simultaneously, given their finite development resources. By bringing in preferred partners with strict "stay-in-your-lane" complementary functionality agreements, they can meet immediate market needs while hedging against more aggressive entrants (like Salesforce) who might have substitutive aspirations over time.
Overall, I wonder if Epic will eventually push these Workshop categories toward commoditization, similar to what we see with Toolbox. Workshop is for emerging technologies and areas where Epic has frequent requests from their health system customers that they need help with. As workflows mature, APIs stabilize, and something makes it to Toolbox with an "agreed-upon-path," Epic may end the Workshop work and gradually open up these integrations to a broader set of vendors. Even more radically, they could create competitive offerings themselves, as all of these offerings correspond more closely with software than the hardware theme we see in Toolbox. After all, the only thing better than commoditizing your competition is expanding your bundle to offer it for free.
Yes, I’ve used this meme before, but it’s too accurate to not reuse
Conclusion: A Path Forward
As we wrap up this article, we can enumerate a few takeaways by persona:
Developers: You should join Vendor Services, but temper your expectations. If you fit a Toolbox category, assess whether it’s beneficial, knowing it may limit you strategically. Don’t go chasing Workbench.
Health Systems: You deserve a robust catalog of plug-and-play applications. You deserve to have a vendor that proactively shoulders as much of the pain of integration as possible up front instead of delegating it to you. You deserve the option of choice. For those reasons and more, you selfishly should be demanding more from Epic in regard to the app ecosystem.
Epic: You deserve credit for the many interfaces and APIs you’ve created. You’ll only get that credit if you surround them with a superlative developer experience of test tools, documentation, and support. You’ll only get it if applications know they have transparent, non-discriminatory access to all those inputs and outputs you’ve made. You could gain significant leverage in exposing foundational data as APIs to help applications better deal with customer-by-customer variability in build.
As Epic's ecosystem continues to evolve, several critical areas for improvement emerge that would benefit both Epic and the broader healthcare technology community. These aren't just wishlist items from frustrated developers – they represent strategic opportunities for Epic to strengthen its market position while reducing operational overhead and regulatory risk.
The degradation of developer support from App Orchard to Vendor Services has had unintended consequences. While the changes may have reduced Epic's direct costs, they've increased the support burden on Epic's health system customers, who must now help vendors understand Epic's systems. Restoring direct technical support and comprehensive documentation would actually reduce Epic's total cost of supporting integrations while improving customer satisfaction.
Epic should consider reopening API discovery, even if access remains controlled. The current opaque process of requesting APIs through Vendor Services creates unnecessary friction and raises concerns about information blocking. While Epic may want to guide developers toward appropriate integration patterns, the complete lack of visibility into available APIs makes it difficult for applications to plan their integration strategy effectively. APIs for workflows like Inbasket management, workqueue control, and financial data don’t have standards-based equivalents - as demand for solutions continues to increase, applications will be forced to use RPA and screenscraping to integrate if this does not change. Epic’s health system customers will commensurately be frustrated. By making APIs more discoverable, Epic could reduce the strain on its technical services team while still maintaining control over actual access.
Epic (rightfully) has a focus on standards-based exchange. This is noble and just, but only if the standards path is equivalent or better in terms of functionality, testability, and cost. Today’s FHIR APIs are leading, for sure, but not yet viable for most applications. Suppose Epic truly wants to shift the industry toward standards. In that case, they should invest in building a more comprehensive FHIR-only ecosystem with push capabilities, robust bulk data access, and feature parity with legacy interfaces. This would position Epic as the definitive leader in healthcare interoperability while reducing their long-term maintenance burden of supporting legacy interfaces.
However, if Epic plans to maintain legacy interfaces as a primary integration pathway, it must invest in fuller sandboxes and testing tools. Self-service HL7v2 connectivity and testing are possible. The current environment where developers must engage Epic TS at high hourly rates for basic testing actions is inefficient for both parties and diverts Epic's valuable technical resources from more strategic work.
Most crucially, Epic must clarify how and when Workshop APIs will become available to broader Toolbox or Vendor Services users. This transparency isn't just about satisfying regulations – it's about encouraging more developers to build on Epic's platform by giving them confidence in the ecosystem's future. Clear API roadmaps would help Epic avoid regulatory scrutiny while fostering innovation that their customers increasingly demand.
These improvements would strengthen Epic's market position by creating a more vibrant complementary application ecosystem while reducing operational costs and regulatory risks. In an era where health systems demand more from their technology partners, Epic has an opportunity to transform its relationship with third-party developers from a necessary burden into a strategic advantage.
However, Epic's ambitions extend far beyond just improving its developer ecosystem. As we'll explore in the following article in this series, Epic is systematically expanding beyond traditional provider organizations through its Health Grid initiative. From payers to laboratories to clinical trials, Epic is methodically creating new software categories that leverage their provider network dominance into adjacent markets. Understanding how Epic manages its traditional developer ecosystem becomes even more crucial as we examine its expansion into new territory and what it means for the future of healthcare technology.
A big thanks to Dave Grosser, Eric Valentine, Brian Bray, Jonathan Perlin, Thomas Kasl, Joe Galea, Melissa Schneider, Shivi Singh, Vkas Chowdhry, Kahaan Shah, Madeline Sall, Vince Hartman and Colin Keeler for all thoughts, insights, and edits.
Thanks for reading Health API Guy! Subscribe for free to receive new posts and support my work.
