Epic FHIR Patient Portal Development: Building Beyond MyChart

Epic's current developer ecosystem uses Epic Showroom for application discovery, while Vendor Services provides the developer programme used for commercial integration work. Connection Hub supports connectivity between Epic customers and external applications.

That distinction matters when you are preparing an Epic FHIR patient portal project. A vendor still presenting App Orchard as Epic's current marketplace may be relying on outdated programme information.

During healthcare implementations, correcting that assumption early can prevent teams from planning their technical and commercial process around terminology that Epic no longer uses.

The first step is therefore not writing code. It is confirming how your intended application fits Epic's current developer and customer activation process.

For health systems planning a broader patient experience, patient portal development should also account for the application's relationship with the existing EHR, authentication model, clinical workflows, and patient-facing responsibilities.

Epic's developer marketplace was previously known as App Orchard. According to Nirmitee.io's 2026 developer guide, Epic renamed App Orchard to App Market in 2021 before shutting it down in December 2022.

Epic Showroom replaced that discovery function, while Vendor Services became the relevant programme for developers working towards supported production integrations.

This distinction is practical rather than cosmetic. Project briefs, vendor proposals, technical documentation, and stakeholder expectations should use the current programme names.

If your procurement documents still describe the project as an "App Orchard submission", clarify the intended Epic process before the project moves into commercial planning.

Epic Showroom is the place where applications can be presented and discovered within Epic's ecosystem. It should not be treated as a substitute for the technical and commercial review required for a production integration.

Vendor Services handles the developer programme and associated review process. Connection Hub addresses connectivity between Epic customers and external applications.

For a health system, these functions create different responsibilities. Your development team can build and test the application, while Epic and the customer health system control parts of the path to production.

That division should appear in the project plan from the beginning.

Terminology alone does not prove technical capability. However, outdated programme references can indicate that a proposed implementation plan has not been aligned with Epic's current developer process.

Ask prospective vendors which Epic programme they intend to use, which FHIR resources they expect to request, how SMART on FHIR will be implemented, and which steps depend on the customer health system.

Those questions expose whether the proposed delivery plan separates development work from Epic and hospital-side dependencies.

SMART on FHIR provides the authorisation framework that allows an application to request approved access to FHIR data. With Epic, the implementation commonly involves OAuth 2.0 authorisation combined with defined FHIR scopes.

The important point is that authentication and data access are separate concerns. Successfully identifying a user does not automatically grant an application unrestricted access to their clinical information.

Across recent compliance projects, tightly scoping requested FHIR resources helped keep integration requirements focused during planning for external review.

A simplified SMART on FHIR flow looks like this:

Your architecture must protect tokens throughout this process. Token storage, session handling, logging, access control, and application security should be considered part of the portal architecture rather than treated as separate development tasks.

For organisations building the surrounding patient-facing infrastructure, HIPAA compliant website development can provide the appropriate architectural context for protecting patient information and supporting security requirements.

SMART on FHIR supports different launch patterns.

An EHR launch starts the application from within an existing Epic session. The application receives launch context that helps it understand the user and clinical environment associated with the request.

A standalone launch starts outside Epic. The application initiates authentication independently and then requests the appropriate access through the SMART authorisation process.

The choice depends on the experience you are building.

A patient portal that starts from your own application may require standalone behaviour. A workflow launched directly from an Epic context may require EHR launch behaviour.

The distinction should be resolved during architecture planning because it affects authentication flow, user experience, testing, and integration requirements.

FHIR scopes determine what an application can request. Asking for resources that the portal does not actually use creates unnecessary review complexity and expands the application's access requirements.

For example, a portal focused on appointments and selected clinical documents should not request every available clinical resource simply because those resources exist.

Resource selection should begin with actual product requirements. Map each patient-facing feature to the FHIR resources it requires, then define the smallest practical scope for the integration.

That approach also makes discussions with Epic and the customer health system more precise.

FHIR R4 provides the structured data model that connects the patient experience with Epic's clinical information. The relevant resources depend on the portal's intended features rather than the size of the health system.

A practical implementation starts with the patient journey. Identify what the user must view, create, or act upon, then map those actions to the required FHIR resources.

Our healthcare IT experience with patient-facing integrations has shown that resource scoping becomes easier when teams start from user journeys rather than beginning with a catalogue of APIs.

For deeper interoperability planning, see our web focused guide to FHIR API integration.

The Patient resource establishes the identity context for many patient-facing interactions.

Your portal architecture must associate the authenticated application session with the appropriate patient context. That relationship affects every downstream experience, including appointments, care plans, documents, and other clinical information.

Identity matching therefore deserves early technical attention. A visually polished portal still creates operational risk if the underlying patient context is incorrect.

Appointment can support scheduling-related experiences where the required Epic configuration and access permissions permit the relevant data exchange.

CarePlan can support patient-facing care coordination experiences where the health system's use case and available data make that appropriate.

These resources should not automatically become part of every portal. First define the actual workflow, then establish whether Epic exposes the required data through the relevant FHIR implementation.

That prevents a common planning mistake: designing a feature around an assumed API capability before validating the customer's Epic environment.

DocumentReference can provide a structured way to reference clinical documents associated with a patient.

For patient portals, document access requires careful consideration of what the patient should see, how documents are presented, and which clinical workflows determine availability.

FHIR connectivity does not remove the need for application-level access controls and appropriate patient experience design.

Bulk Data Access serves a different purpose from the individual patient queries typically used for portal interactions.

A patient portal usually requests information for a specific patient during an active user interaction. Population health dashboards may instead need data across larger patient populations for analytics and operational reporting.

The distinction affects architecture, processing patterns, security considerations, and product expectations.

Bulk Data Access is designed for population-level data exchange rather than individual patient requests.

That makes it relevant when a health system wants to analyse broader groups of patients, create population dashboards, or support data-driven operational workflows.

It should not be treated as a faster replacement for every individual FHIR request.

For a patient portal, individual FHIR queries remain the more relevant model when the application needs information about the currently authenticated patient.

Bulk data can sit alongside an organisation's wider analytics architecture rather than inside the patient portal itself.

A health system might use separate data pipelines and analytics systems for population reporting while maintaining transactional FHIR interactions for patient-facing functions.

Keeping those workloads conceptually separate helps prevent a portal project from becoming an unnecessarily broad analytics integration.

The architecture should reflect the business purpose of each data flow.

Epic integration timelines depend on more than development velocity. A project can have a completed application while still waiting for Epic review or the customer health system's internal provisioning process.

Saga IT's 2026 Epic integration guidance states that Vendor Services review typically takes 8 to 16 weeks, depending on the complexity and scope of requested FHIR resources.

Once approval occurs, the customer health system still has its own provisioning responsibilities.

Sandbox development allows the technical team to begin working with Epic's development environment without waiting for the final production activation.

That helps developers establish FHIR requests, test SMART authorisation, validate application behaviour, and identify technical issues earlier.

Sandbox access should not be confused with production approval. The application still needs to complete the applicable Epic process and receive activation from the customer health system.

Planning should therefore separate "development ready" from "production ready" as different project milestones.

The Vendor Services review can include technical security review and FHIR API compliance assessment.

According to Saga IT's 2026 Epic integration guidance, the review typically takes 8 to 16 weeks depending on the complexity and scope of the requested FHIR resources.

This range should inform stakeholder planning, but it is not a guaranteed service-level timeline.

A tightly scoped integration can give reviewers a clearer picture of the application. Excessive resource requests, unclear workflows, or incomplete technical information can create additional review work.

Approval does not automatically put the application into production.

Opexia Healthcare Software Engineering's 2026 guide reports that hospital-side provisioning typically takes 4 to 8 weeks and can extend to several months, depending on the organisation's change management process.

The customer health system's Epic team may need to activate the application and configure the client ID within its environment.

Based on our healthcare IT experience, treating this as a customer-side dependency rather than a development task produces more realistic go-live planning.

For the broader technical dependency model, see our guide to EHR integration architecture.

MyChart already provides a significant patient-facing capability for health systems using Epic. A custom SMART on FHIR application therefore needs a clear reason to exist.

The decision should start with the patient journey and business requirement rather than the availability of FHIR APIs.

Herexa Health provides a relevant example of Qrolic Health's work with healthcare platform architecture, where patient-facing workflows required more than a generic website experience. See our Herexa Health case study for the broader implementation context.

MyChart customisation may remain appropriate when the required patient experience fits within Epic's existing configuration and supported capabilities.

Consider this route when:

A custom application adds another product surface, integration dependency, security boundary, and release process. Those costs should have a clear business justification.

A custom application becomes more relevant when the health system needs an experience that MyChart cannot provide through its supported configuration.

Common indicators include:

The technical decision should still depend on the exact Epic resources and launch model available to the health system.

Herexa Health demonstrates how healthcare platform requirements can extend beyond a basic patient website.

The platform brought together patient onboarding, medical intake, clinical review, treatment management, provider operations, consultation management, and e-prescribing workflows.

That type of architecture illustrates why the correct question is not simply whether FHIR is available. The stronger question is whether the required patient and operational experience can be delivered effectively through the existing Epic experience or needs a dedicated application layer.

Qrolic Health perspective

Qrolic Health works on healthcare platforms where patient-facing experiences, clinical workflows, integrations, and security requirements must be considered together.

For Epic projects, that means scoping the intended patient journey first, mapping the required FHIR resources second, and then planning the SMART authorisation and Epic-side dependencies around that scope.

RxHere also provides relevant experience with prescription workflow and patient-facing healthcare integrations, where limiting the requested data and workflow scope helps keep implementation focused.

Epic FHIR patient portal development is not simply an API integration exercise. A successful project needs an accurate understanding of Epic's current developer programme, SMART on FHIR authorisation, FHIR resource requirements, review stages, and customer-side provisioning.

The terminology matters because App Orchard is no longer Epic's active developer marketplace. The timeline matters because Vendor Services review and hospital-side provisioning can extend beyond the development schedule.

Your architecture should therefore separate what your team controls from what Epic and the customer health system control. That distinction creates more realistic planning, clearer vendor requirements, and fewer surprises before production.

For health systems moving beyond MyChart, the decision should ultimately come back to the patient experience and business requirement. A custom SMART application should exist because the required experience warrants it.