EHR pedigree integration: Epic, Cerner, SMART-on-FHIR, and the embed pattern

Short version. There are four realistic integration patterns for getting pedigree software into a modern EHR: a native EHR app (Epic App Orchard / Showroom or Oracle Health's equivalent), a SMART-on-FHIR launched app, an embedded iframe inside a hyperspace or portal web-content frame, and a back-office REST API plus webhook synchronisation. Evagene's position today is that the embeddable pedigree viewer plus REST API plus webhooks is the primary integration surface; a SMART-on-FHIR launch adapter can be built on top in a small amount of code. A pre-packaged Epic or Oracle Health connector in their marketplaces is not available as of April 2026. This page walks through each pattern, what it costs to build, and what trade-offs it involves.

The question "does your pedigree software integrate with our EHR?" is almost never a yes/no — it is a question about which integration pattern fits the organisation's appetite, timeline, and governance constraints. We try to be straightforward about each one.

The four integration patterns

Regardless of vendor, EHR integration for a clinical data product sits on a spectrum:

1. Native EHR app. The product is published in the EHR's app marketplace (Epic App Orchard / Showroom, Oracle Health's equivalent) and installed by the hospital's IT department using the EHR's approved integration framework. Highest procurement legitimacy, longest lead time, strongest dependency on the EHR vendor's release cycle.
2. SMART-on-FHIR app. The product accepts a SMART launch context from the EHR, exchanges it for a FHIR access token, and runs in a web frame inside the clinician's session. Good pattern for products that need clinical context (the patient, the encounter, the practitioner) without full EHR app status.
3. Embedded iframe with signed session. The product runs outside the EHR but is displayed inside an EHR-hosted frame (hyperspace web-content, Oracle Health webframe, portal iframe) with the patient's context passed in via query parameter or signed URL. Simplest to implement; most common for phase-one integrations.
4. Back-office REST API + webhook sync. No user-facing integration; the EHR and the pedigree platform exchange data through APIs and event notifications, typically wired together by an integration engine (Rhapsody, Mirth, Azure Integration Services, Cloverleaf). Important for data flow even when the UI integration is a simple iframe.

In practice, production integrations combine patterns three and four: an iframe gives the clinician the pedigree view, the REST API plus webhooks keeps structured data in sync behind the scenes. Patterns one and two layer on top later.

Epic: App Orchard, Showroom, and hyperspace embedding

Epic organises third-party products through its App Orchard / Showroom programme. Vendors listed there have completed Epic's technical and compliance review, and their apps can be installed into a hospital's Epic environment through documented processes. This is the gold-standard path for a pedigree platform that intends to sell to US academic medical centres at scale.

Evagene is not currently listed in Epic App Orchard or Showroom. Integration with Epic customers today is built using the generic patterns: embed the Evagene pedigree viewer in an Epic hyperspace web-content frame (a common and well-understood mechanism), and wire structured data flow through the REST API. The hyperspace frame passes in a token or identifier that the viewer uses to fetch the correct pedigree; the organisation's Epic interface team controls what context is passed.

For patient-facing use (MyChart), an iframe pointing at the Evagene viewer, authenticated via a short-lived scoped API key or a public read-only link, is the realistic approach day one. For clinician-facing use inside hyperspace, the same pattern with a write-scope token held server-side is common.

Being honest: a hospital IT department whose procurement policy requires a native App Orchard listing will not accept an iframe-plus-API integration until that listing exists. For those organisations, the integration is a future state — the roadmap and commercial conversation. For organisations whose procurement policy accepts "app plus documented integration pattern," the iframe-plus-API pattern is production-ready.

Oracle Health (Cerner): same shape, different marketplace

Oracle Health (formerly Cerner) runs its own third-party programme with the same basic model: vetted apps in a marketplace, plus open integration via FHIR APIs and web frames. The iframe-plus-API pattern applies unchanged; the webframe and CCL / MPages context differ from Epic's hyperspace but the architectural shape is identical.

As with Epic, Evagene does not currently ship a pre-packaged Oracle Health connector. Integration with Oracle Health customers uses the REST API, webhooks, and embeddable viewer.

SMART-on-FHIR: the open-standards middle path

SMART-on-FHIR is the open standard for launching web apps from within an EHR with clinical context. A SMART-capable EHR presents the launching app with an iss (the FHIR server URL) and a launch parameter; the app exchanges these at the FHIR authorisation endpoint for an access token, and then queries FHIR resources on the clinician's behalf.

A SMART-on-FHIR front door for Evagene is a small adapter service. Its job is to accept the SMART launch, exchange the context for a FHIR token, resolve the patient's MRN or FHIR Patient ID to an Evagene pedigree (creating one if none exists via the REST API), and return the embeddable viewer URL in the launch response. In shape:

1. EHR redirects clinician to:
   https://your-smart-launcher.example.org/launch?
       iss=https://ehr.example.org/fhir&launch=abc123

2. Launcher exchanges (iss, launch) for an access token via
   the SMART authorisation server.

3. Launcher fetches Patient/{id} from the EHR FHIR endpoint,
   resolves MRN -> Evagene pedigree via Evagene REST API.

4. Launcher returns an HTML page that embeds:
   <iframe src="https://evagene.com/embed/pedigree/{id}
       ?api_key=evg_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx">

The launcher is the trust boundary. The Evagene API key lives on its server; the iframe URL carries a scoped identifier. A production SMART launcher also handles session expiry, audit logging, and CSP.

Evagene does not ship this launcher today as a turnkey app, but the REST API and embeddable viewer are the building blocks. Teams that have already built SMART launchers for other apps typically port one in a week or two.

Embedded iframe with signed session

For organisations that do not have a SMART-on-FHIR launcher (or do not need one yet), the simplest production pattern is:

1. Clinician opens the patient record in the EHR.
2. A hyperspace web-content frame (or equivalent) is configured to load a URL like https://your-integration.example.org/pedigree?mrn={{MRN}}, where {{MRN}} is a hyperspace token substitution.
3. Your integration service receives the request, looks up the Evagene pedigree for that MRN (creating one via the REST API if none exists), and returns an HTML page containing the Evagene embed.
4. The embed authenticates using an API key held by your integration service — never exposed to the browser.

The Evagene embeddable viewer supports three modes: iframe to a self-contained HTML page, a raw SVG endpoint (for lightweight use as an img or object source), and a JavaScript snippet that auto-discovers data-evagene-pedigree attributes on the page. For EHR embed, the iframe mode is the most common; for a read-only audit-log entry or a PDF export pipeline, the SVG mode is useful.

Webhook-driven updates

Clinical data products in the EHR do not work well as static embeds. When the pedigree changes — a new affected relative is added, a risk analysis completes, a colleague imports a GEDCOM — downstream systems need to know. Evagene emits HMAC-SHA256-signed webhooks for eight event types:

• pedigree.created, pedigree.updated, pedigree.deleted
• individual.created, individual.updated, individual.deleted
• analysis.completed (BRCAPRO, MMRpro, PancPRO, Mendelian, AI interpretation)
• import.completed (GEDCOM, 23andMe, XEG, image OCR)

A webhook payload's shape (not a copy-paste contract):

POST /hooks/evagene  HTTP/1.1
X-Evagene-Signature: sha256=3a7b...
Content-Type: application/json

{
  "event": "analysis.completed",
  "occurred_at": "2026-04-17T10:22:44Z",
  "pedigree_id": "ped_9f2b...",
  "analysis": {
    "type": "brcapro",
    "proband_id": "ind_1a3c...",
    "result_summary": { ... }
  }
}

Verify signatures using the per-webhook secret, dedupe by (event, pedigree_id, occurred_at), and treat webhooks as hints: always read the definitive state from the REST API before acting, so a lost or reordered webhook does not corrupt state.

How this works in Evagene

The practical recipe for an EHR integration with Evagene today:

• Embed surface: the Evagene embeddable pedigree viewer (iframe, SVG, or JS snippet) sits inside the EHR's web-content area.
• Auth: a server-side scoped API key (evg_<43 chars>, read/write/analyse scopes, SHA-256 hashed at rest) held by the integration service.
• Data sync: REST API calls on provisioning (create pedigree on new referral, add individuals from EHR family history, attach disease codes).
• Events: webhooks drive downstream actions (file an EHR flowsheet row on analysis.completed, notify the clinician on pedigree.updated).
• AI: use Analysis Templates with variable injection ({{pedigree_description}}, {{proband_name}}) to generate a house-style interpretation that the EHR filing pipeline attaches to the record.
• BYOK: your organisation's own Anthropic or OpenAI key, encrypted with Fernet at rest, so LLM traffic stays within your data-processing agreements.

For MCP-capable clinicians using Evagene's MCP server from within Claude Desktop or Claude Code, EHR-side integration is unnecessary for the AI workflow — the clinician operates on the pedigree directly from their AI workspace while the EHR sees the result via webhook.

Frequently asked questions

Related reading

• Evagene platform overview
• HL7 FHIR and pedigree data
• Pedigree REST API reference and patterns
• Embeddable pedigree viewer: iframe, SVG, and JS
• Pedigree MCP server for AI agents
• Phenotips vs Evagene

Further reading: Evagene platform documentation at evagene.net/help/platform_overview.