FHIR R4, CDS Hooks, and the practical realities of getting AI alerts into clinical workflows.
The most common reason clinical AI tools fail to achieve adoption is not that they produce poor predictions. It is that they require clinicians to leave their primary workflow to consult a separate interface. A physician who spends 8-10 hours per day inside Epic or Cerner will not routinely open a second browser tab, remember a separate login, and check a standalone dashboard for AI alerts. That behavioral change is too large to ask of clinicians who are already cognitively overloaded.
This is the first principle that guided Pegasi's integration architecture: the platform must surface its output inside the clinical workflow that already exists, not alongside it. Every alert Pegasi generates must reach the right clinician in the system they are already using, in a format that requires zero additional navigation to understand and act on. If a Pegasi alert requires the clinician to leave Epic, we have failed.
Achieving this requires genuinely deep EHR integration - not a simple webhook or a custom report in a secondary module, but a certified, standards-based connection that allows bidirectional data flow within the EHR's own alerting and documentation framework. The technology to do this exists: it is called CDS Hooks, and it is built on top of the HL7 FHIR standard. Most health system IT teams are familiar with both, but the implementation details for production clinical AI are more complex than the standards documentation suggests.
HL7 FHIR (Fast Healthcare Interoperability Resources) is the API standard that modern EHRs expose for data exchange. Published in its current major version (R4) in 2019 and mandated for US health system interoperability by the 21st Century Cures Act's information blocking rules, FHIR is the plumbing that allows healthcare software systems to exchange structured clinical data without custom HL7 v2 feeds or proprietary extract formats.
FHIR structures clinical data as Resources - discrete, typed objects like Patient, Observation, Condition, MedicationRequest, DiagnosticReport, and ImagingStudy. Each resource has a defined schema, a set of mandatory and optional fields, and a RESTful API endpoint. A FHIR-enabled EHR can respond to a request like "give me all Observation resources for patient 1234 with a category of laboratory and a date range of the past 12 months" and return structured JSON containing exactly those lab results, in a format that any FHIR-aware application can parse without institution-specific parsing logic.
Pegasi's data ingestion layer is built entirely on FHIR R4. When a Pegasi deployment goes live at a new health system, the integration team establishes an authorized FHIR connection to the institution's Epic or Cerner instance - typically through Epic's App Orchard or Cerner's App Market for certified applications. The connection is authenticated via OAuth 2.0 with scope restrictions that limit Pegasi's read access to the specific resource types needed for diagnostic modeling. We do not request write access to clinical documentation in the base integration; that is a separate authorization that some health systems grant for documentation assistance features.
FHIR handles data ingestion. CDS Hooks handles alert delivery. CDS Hooks is a separate specification, also developed by HL7, that defines a mechanism for the EHR to invoke an external clinical decision support service at specific points in the clinical workflow (called "hooks") and receive structured recommendations to display to the clinician.
In practice, this means that at defined trigger points - typically when a clinician opens a patient's chart, when an order is being placed, or when a results review session begins - the EHR sends a hook invocation to Pegasi's CDS service with the relevant patient context. Pegasi evaluates the patient's data against the current model state, determines whether an actionable alert threshold has been reached, and returns a response in the CDS Hooks card format. The card appears as a pop-up or in-line recommendation within the EHR's native interface, with a summary, supporting evidence links, and one-click action buttons (such as "Order colonoscopy" or "Request tumor board review").
This integration pattern requires the EHR to be on a modern version with CDS Hooks support. Epic versions released after 2018 support CDS Hooks natively; most enterprise Epic installations are on supported versions. Cerner's PowerChart similarly supports CDS Hooks through its Ignite APIs. For health systems running older EHR versions or EHRs without CDS Hooks support (typically smaller community health systems on legacy Allscripts or Meditech installations), Pegasi supports an alternative delivery mechanism through configurable in-basket messages or care team notifications within the EHR's messaging framework.
A typical Pegasi EHR integration requires 8-12 weeks from contract execution to production go-live. The timeline is determined primarily by the health system's IT change management process, not by Pegasi's technical implementation - most of the calendar time is spent waiting for the institution's Epic or Cerner review board to approve the new application, for the security team to complete vendor due diligence, and for the integration environment (non-production) to be set up for testing.
The technical work from Pegasi's side breaks into three phases. In the first two weeks, we configure the FHIR connection to the institution's sandbox environment and validate that the data we need - patient demographics, laboratory observations, diagnostic reports, medication lists, condition records - is flowing correctly and in the expected format. Significant EHR-to-EHR variation exists in how FHIR resources are populated even within the same EHR platform: two Epic installations at different institutions may use different LOINC codes for the same laboratory test, or may represent pathology reports in Observation resources versus DiagnosticReport resources depending on configuration choices made during the original EHR implementation. Our FHIR normalization layer handles this variation, but validating it requires working with a real data sample from the target institution.
In weeks three through six, we test the CDS Hooks integration in the sandbox EHR environment with de-identified synthetic patient records, validating that alerts display correctly in the clinical workflow, that action buttons trigger the correct downstream processes, and that the alert content is clinically meaningful for the patient population at this institution. This phase involves close collaboration with the institution's clinical champion and typically two or three oncology physicians who serve as initial usability testers.
In the final phase, we run a parallel production period - typically four weeks during which Pegasi is processing real patient data and generating alerts, but the alerts are reviewed by a Pegasi clinical team member before being surfaced to clinicians. This allows us to validate alert quality on the real patient population before activating the live alert pipeline. After the parallel period completes and the clinical champion has reviewed a representative sample of alert outputs, the system goes live with direct-to-clinician alert delivery.
Health system IT teams sometimes ask about three different paths for connecting an AI platform to Epic: Epic App Orchard certification, a direct FHIR API connection using Epic's standard APIs, and a native build within Epic's own development environment (Cogito analytics, or an Epic-built BPA). Each has different tradeoffs.
Epic App Orchard certification, which Pegasi holds, is the preferred approach for enterprise deployments because it provides a pre-reviewed, standardized integration path that Epic health systems' IT teams recognize and have process familiarity with. App Orchard-certified apps have undergone Epic's technical review for security and API use patterns, reducing the due diligence burden on the health system side. The limitation is that App Orchard certification covers a defined set of API capabilities; implementations that require unusual data access patterns may need additional approval.
Direct FHIR API connections without App Orchard certification are technically possible and can be appropriate for pilot or research deployments at institutions with IT teams that prefer to manage the integration directly. They require more upfront security review work from the health system but allow more flexibility in API usage patterns. The compliance and security review requirements are the same regardless of whether App Orchard is involved - the certification simply provides a shortcut through part of that review.
Native Epic builds using Epic's internal tools are the approach many health systems prefer when they want the AI tool to be fully "inside" Epic with no external vendor dependency. Pegasi's algorithms and models can be implemented as Epic Best Practice Advisories (BPAs) or as components in Epic's Cosmos analytics environment, though this path requires more ongoing maintenance when Pegasi's models are updated and typically produces a more limited user experience than the full Pegasi interface. We support this path for health systems that have a strong preference for it, though we recommend the App Orchard integration for most enterprise deployments.
Technical integration connects Pegasi to the EHR. It does not, by itself, create a clinical workflow for acting on Pegasi alerts. That design work - deciding who receives which alerts, at what priority level, with what expected response time, and how non-response is escalated - is organizational, not technical. It is also where most clinical AI implementations fail.
Our implementation methodology includes a workflow design workshop as a required pre-go-live step. In this workshop, the clinical champion, oncology department leadership, and Pegasi's clinical success team map out the specific alert pathways: when a high-priority alert fires for a patient whose primary oncologist is listed in the EHR, the alert goes to that physician. When the primary oncologist is the attending on a different service that week, the alert routes to the covering oncologist. When an alert fires outside business hours, it goes to the on-call oncology nurse practitioner as a non-urgent notification for morning review, unless it is flagged as requiring same-day action. These are real workflow decisions with real clinical implications, and they require real institutional knowledge to design correctly. Technology provides the routing mechanism. Clinical leadership provides the routing logic.