Epic Vendor Services and open.epic are the two main routes developers use to build for Epic today. open.epic provides free public documentation and sandbox access for standards-based FHIR APIs, while Vendor Services is Epic’s paid developer program for deeper API access, testing resources and eligibility for higher Showroom tiers.
Taction Software builds Epic integrations for health technology companies and provider organizations, drawing on 200+ healthcare projects delivered since 2013. Epic retired the App Orchard brand, so this page expands on our Epic EHR integration guide by explaining what replaced it, how open.epic and Vendor Services differ, and which route fits your product.
Our experts are ready to understand your business goals.
Many hospital IT teams and older guides still tell vendors to get listed in App Orchard, but that program no longer exists. Epic launched App Orchard in 2016, later renamed it App Market, and shut the App Market down at the end of 2022. It then split the old single program into separate pieces: a paid developer program, a free standards-based developer resource and a public marketplace with several tiers. Knowing which piece does what prevents wasted effort and budget. The six elements below make up the current Epic developer and vendor landscape.
App Orchard was Epic’s original program for third-party developers, combining API access, testing and a marketplace listing in one membership. It was later renamed App Market. References to either name today are out of date, even though the terms remain heavily searched by developers and buyers.
Epic closed the App Market at the end of 2022 so it could restructure how it works with a fast-growing number of third-party vendors. Existing members moved into new programs, and the single combined path became several separate paths with different requirements and purposes.
Vendor Services is Epic’s paid developer program for companies that need deeper integration than public standards allow. Membership gives access to a broader API catalog, testing resources and Epic technical support. Annual fees are set by Epic and should be confirmed directly with Epic before budgeting.
open.epic is Epic’s free public resource for standards-based development, including FHIR API documentation and sandbox testing. It suits teams building apps on published standards such as SMART on FHIR, and it lets developers prototype against Epic without joining a paid program first.
Showroom, launched in January 2024, is Epic’s public marketplace where health systems discover products and services that work with Epic. It is organized into tiers with different entry requirements, and a Showroom presence makes a product visible to customers without replacing each customer’s own security review.
Connection Hub is the entry tier of Showroom, where vendors list products that already connect to Epic. Listing generally requires at least one live connection with an Epic customer, and it is a self-attested listing that should not be presented as an Epic endorsement of the product.
open.epic is where most teams should begin, because it costs nothing to start and covers the standards-based APIs that many Epic integrations need. It gives developers public documentation, sandbox environments and a clear view of which FHIR resources Epic supports, so product teams can test ideas before committing budget. It also has limits, particularly for proprietary workflows and data that published standards do not cover. The six points below explain what open.epic provides, where it works well for product teams, and where teams usually need something more to reach real production use.
open.epic publishes documentation for the FHIR resources and operations Epic supports, including patient, encounter, observation and medication data. Developers can review scopes and data elements before writing code, and our FHIR R4 implementation guide explains how to apply that documentation in practice.
The sandbox lets teams test FHIR calls and SMART launches against sample data without connecting to a live hospital. It is ideal for proof-of-concept work, and our walkthrough on building your first SMART on FHIR app shows how teams use it early.
Because open.epic focuses on published standards, apps built this way are easier to adapt for other EHR vendors that support the same standards. That portability matters for startups planning multi-EHR distribution, and our FHIR API development service designs for it from the first sprint.
Developers register applications to obtain the identifiers needed for OAuth-based authorization against Epic FHIR endpoints. Registration clarifies which scopes the app requests and whether it serves patients or clinicians, which later shapes each customer’s review and activation of the app in production.
open.epic carries no membership fee to begin development, which makes it the lowest-risk way to validate an integration idea. The main costs at this stage are engineering time and design effort, not program fees, so teams can prove value before paying for deeper Epic access later.
open.epic covers standards-based APIs, not every proprietary Epic capability. If your product needs workflows, data or write-back paths that public standards do not support, you will likely need Vendor Services or a customer-sponsored approach. Production go-live still depends on an Epic customer activating your app.
Vendor Services exists for companies whose products need more than public standards can provide. It is a paid program, and membership decisions should follow real product requirements and customer demand rather than an assumption that every Epic integration needs it. For some products it is essential from the first sprint, while for others it adds cost without changing what can be built. Understanding what membership includes helps teams time the decision well. The six features below summarize what Vendor Services provides and the one requirement that membership alone never removes for any vendor.
Vendor Services is an annual paid membership, and Epic sets and publishes its own terms. Because program fees can change, confirm current pricing and conditions directly with Epic. Taction’s estimates never include Epic program fees, which are always listed as a separate third-party cost.
Members can access a wider range of Epic APIs than the public standards available through open.epic, including capabilities that support deeper workflow integration. This matters for products that need to write data back, trigger actions or connect with Epic features that standards do not cover.
Membership includes testing environments and resources suited to validating more complex integrations before they reach a customer. Stronger pre-production testing reduces surprises during customer security reviews and go-live, particularly for bidirectional integrations that write clinical or financial data back into Epic.
Vendor Services members can raise technical questions with Epic about APIs and integration behavior. This support can shorten troubleshooting on complex builds, though your engineering team still owns design, mapping, testing and maintenance of the integration itself throughout its life.
Some Showroom tiers above Connection Hub are tied to Vendor Services membership and to Epic’s recommended integration patterns for certain product categories. If broad Showroom visibility is a commercial goal, plan membership timing alongside your go-to-market strategy and our advice on selling an AI feature into Epic hospitals.
Membership does not put a product live at any hospital. Each Epic customer must still approve, configure and activate the integration in its own environment after its security review. A sponsoring customer remains the most important factor in reaching production, regardless of program membership.
The right route depends on what your product does, who your first customers are and how quickly you need broad visibility. Many teams start on open.epic, prove value with a sponsoring customer and join Vendor Services only when a real requirement appears. Others need proprietary access from day one because their workflow cannot work on standards alone. Choosing deliberately avoids paying for access you do not use or discovering a missing capability late in the build. The six considerations below guide that decision for most health technology companies building for Epic.
Write down exactly which Epic data your product reads, what it writes back and where it appears in clinical or patient workflows. That list decides whether standards are enough. Our Epic integration services team can map a use case to the right route quickly.
If your app reads common clinical data and launches through SMART on FHIR, open.epic usually covers what you need. Teams embedding tools inside Epic can follow our guide to embedding AI inside Epic with SMART on FHIR using standards-based access.
If your product must trigger Epic-specific actions, access data outside published standards or write back in ways standards do not support, Vendor Services is usually required. Confirm the exact APIs you need before joining, so membership cost is tied to a specific product requirement.
A committed health system customer changes the calculation, because it can sponsor activation and clarify which APIs its environment allows. Without one, membership adds cost before revenue. Many vendors secure a pilot customer first, then decide on Vendor Services with real requirements in hand.
Many products combine standards-based FHIR access with HL7 v2 feeds for real-time events, and add Vendor Services APIs only for the features that need them. Our HL7 integration services team often pairs event feeds with FHIR queries in one architecture.
Taction is an independent development company, not an Epic partner or reseller. We design and build integrations on whichever route you choose, and you keep your direct relationship with Epic. Our existing Epic App Orchard development page covers our build services in more depth.
Whichever route you choose, Epic customers review third-party apps carefully before activation. Health systems examine how your product authenticates users, protects PHI, logs activity and handles incidents, and many require security questionnaires, penetration test results or independent attestations. Preparing these materials early in the build shortens sales cycles and avoids delays once a customer is ready to proceed. The six requirements below appear in most Epic customer security reviews, and Taction builds each one into integration projects from the start rather than treating security as a late addition just before launch or customer review.
Each health system runs its own security review, often with detailed questionnaires about hosting, encryption, access control and incident response. Recent healthcare penetration testing results and clear architecture documentation help your product pass these reviews faster and with fewer follow-up questions from reviewers.
If your product creates, receives or stores PHI for a covered entity, you will usually need to sign a business associate agreement. Taction signs BAAs before handling PHI during development, so your build and testing environments meet the same expectations as production.
Epic FHIR access uses OAuth 2.0 authorization with SMART scopes that limit what an app can read or write. Requesting only the scopes you need simplifies customer review and reduces risk, while broad scope requests often trigger extra scrutiny from security teams.
Customers expect a clear record of who accessed which patient data and when, both inside your product and at integration points. Logs should capture access events without storing unnecessary PHI, and alerts should flag unusual activity quickly so incidents can be investigated and contained.
Many health systems ask vendors for SOC 2 reports or similar evidence of security controls. Our SOC 2 compliance for healthcare service prepares evidence for the independent auditor. No official HIPAA certification exists, so attestations and documentation carry that weight instead.
Federal information blocking rules shape how providers and health IT developers share electronic health information. Our information blocking rule compliance service explains the obligations. Taction is not a law firm and does not give legal advice, so confirm specific duties with counsel.
Taction bills a blended $50 per hour across developers, integration engineers, QA and project management, and every estimate shows hours alongside dollars. The ranges below are planning figures, not quotes, and they cover only Taction’s engineering work on your Epic integration or app. Epic program fees, Showroom listing fees, your customers’ Epic analyst time, hosting, integration engine licenses and auditors are separate costs paid to those parties directly. For a quick estimate across interface types, you can also try our EHR integration calculator before speaking with our team about scope and timing.
A discovery sprint typically takes 80 to 240 hours. It confirms which Epic route fits, the APIs required, security design and the test plan, and it produces a fixed scope. The format is described on our healthcare software discovery workshop page.
A standards-based FHIR read integration typically takes 120 to 480 hours, covering authorization, resource queries, mapping, error handling and testing against the open.epic sandbox and customer test environments. Complex mapping or bulk data work sits toward the upper end of the range.
An embedded SMART on FHIR app typically takes 400 to 1,600 hours, including user interface design, launch context, authorization, data access and clinical testing. Our SMART on FHIR app development team scopes these apps against your chosen Epic route and customer requirements.
Each HL7 v2 interface typically takes 80 to 400 hours, depending on message volume, custom segments, mapping depth and testing cycles. Many Epic products combine one or more v2 feeds for real-time events with FHIR queries for on-demand data access.
Ongoing support typically covers 20 to 80 hours per month for monitoring, error reprocessing, Epic upgrade testing and small enhancements. Products live at several health systems often combine a retainer with quarterly reviews to keep integrations stable as customer environments change.
Costs rise with write-back, proprietary APIs, multiple customer environments and strict security reviews. Combined programs can reach 800 to 2,080 hours, or $40,000 to $104,000, at MVP scale. For ongoing capacity, you can hire Epic integration developers at $8,000 per engineer per month.
These are the questions digital health founders, product leaders and hospital IT teams ask most often when they first try to understand how Epic’s developer programs work after App Orchard. The answers are deliberately short and reflect Epic’s publicly described program structure, which Epic can change at any time, so confirm current terms directly with Epic before making commitments. If your question depends on your product, your customers or the APIs you need, a short call with our Epic integration engineers will usually give you a clearer and more specific answer.
No. Epic retired App Orchard, which was later renamed App Market, and closed the App Market at the end of 2022. Today developers use open.epic for standards-based work and Vendor Services for deeper access, while Showroom serves as Epic’s public marketplace.
open.epic carries no membership fee to begin development, and it provides public FHIR documentation and sandbox testing. Your main costs at that stage are engineering time and design. Production use still requires an Epic customer to review and activate your application.
Not always. Many products that read clinical data through SMART on FHIR work well on open.epic alone. Vendor Services is usually needed when your product requires proprietary APIs, deeper write-back or eligibility for certain Showroom tiers tied to membership. Decide once requirements are clear.
The Connection Hub tier is generally open to vendors with at least one live Epic customer connection, without requiring Vendor Services. Some higher Showroom tiers are tied to membership. Confirm current listing requirements and fees directly with Epic before you plan your launch.
No. Taction is an independent healthcare software development company and is not an Epic partner or reseller. We build integrations using the routes Epic makes available to you, and your company keeps its direct relationship with Epic and its customers.
Our Epic App Orchard development page describes our Epic build services. This page compares Epic’s current developer routes, open.epic and Vendor Services, explains what replaced App Orchard, and helps you decide which route fits your product before any build work begins.
Share what your product does, which Epic data it needs, whether it writes data back and whether you have a sponsoring customer. In a 30-minute call we will recommend the right Epic route and outline the build. Book a free consultation.
Your email address will not be published. Required fields are marked *
Our expert reaches out shortly after receiving your request and analyzing your requirements.
If needed, we sign an NDA to protect your privacy.
We request additional information to better understand and analyze your project.
We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.
If you're satisfied, we finalize the agreement and start your project.