The Record and the Procedure Video in One Clinical Answer

What you can do together

• Ask AI Intelligence Hub a question that needs the record and the library at once, such as what a patient's recent encounters say next to the procedure video filed against them, with the answer citing both.
• Scope the connection's Epic credential to the use case, so its grants would bound what AI Intelligence Hub could read, while library material would stay within what the asking clinician may open.
• Put a step in a workflow where AI Intelligence Hub reads from Epic, drafts a summary or a letter, and pauses at an approval node for a person to accept or edit before anything goes further.
• File procedure video, imaging and scanned documents into the library carrying the encounter identifiers, so a clip is retrievable by the encounter rather than by whoever remembers the filename.

How it connects

Epic would be reached from the agentic layer rather than copied into a second database. Inside a workflow, an HTTP Request node would call Epic's API with credentials you supply, and what returns becomes a step in the graph. Where an MCP server for Epic is available to the deployment, the same reach would be available two ways, as an MCP node with its arguments fixed when the workflow is designed, or as an MCP tool the model calls on its own judgement at run time.

The MCP servers recorded for Epic are community-published rather than published by the vendor, and an engagement would weigh that before depending on one. A server is configured with a name, a URL, a transport and optional headers, which is where its token is carried, over Streamable HTTP, Server-Sent Events or WebSocket.

Two other paths would carry content rather than queries. An ingestion connector would bring procedure video, imaging and exported documents in on a schedule, with the identifiers you choose carried as custom attributes so material lands against the right encounter and is searchable by it afterwards. In the other direction, integration code on the Epic side would use the platform's REST API, which resolves every call through the same permission model as the interface and so cannot exceed what its caller could do by hand.