How to connect AI agents to hospital systems running SQL Server or Oracle

The direct database problem

Hospital IT teams face a difficult dilemma. Clinical leaders want ambient voice scribes, billing teams want auto-coding assistants, and operations want autonomous scheduling agents. However, almost every legacy Hospital Information System (HIS) or Electronic Health Record (EHR), whether running on Microsoft SQL Server, Oracle, or MySQL, was designed under the assumption that human users enter data through validated graphical forms.

Letting an autonomous AI agent or MCP tool connect over raw database connections to execute INSERT, UPDATE, or DELETE statements is a recipe for silent data corruption. An agent formulating a dynamic SQL query might omit a WHERE clause, scramble a foreign key relation between an encounter and a patient, or write an invalid clinical status code that bypasses application-level business constraints.

For healthcare environments where patient safety is paramount, direct SQL writes by autonomous agents must be avoided.³ The risk is not merely theoretical: an accidental query modifying billing codes or medication frequencies directly against clinical schemas can bypass application validation rules, trigger cascading side-effects, and compromise patient charts without leaving a clinician’s audit signature.

Why Deedglass says Not today for direct SQL

On the Deedglass hospital fit page, the entry for Microsoft SQL Server, Oracle, MySQL, and HL7 v2 is marked “Not today.”⁴

This honesty boundary is intentional. Deedglass includes a native relational connector for PostgreSQL because Postgres exposes logical replication decoding messages (pgoutput) and WAL-level hooks that allow Deedglass to verify exact row-level changes and execute automatic rollbacks.⁴

SQL Server and Oracle do not share this uniform logical decoding architecture across on-premise editions without heavy custom proprietary extensions. In enterprise environments, hospital DBAs strictly forbid third-party agents from attaching raw administrative replication slots to production patient record databases. Rather than presenting a fragile connection that could miss database trigger side-effects, Deedglass recommends three reliable architectural patterns that hospital IT teams use today.

Pattern 1: The integration engine and FHIR facade

The most common and secure architecture in hospitals is routing AI agent writes through an existing integration engine or FHIR API.⁴

Almost all hospitals operate an integration engine such as Mirth Connect (NextGen Connect), Rhapsody, or Infor Cloverleaf, or run a modern FHIR server like HAPI FHIR or Medplum in front of their legacy database.

Code What the screen or file shows, copied as is.

[ AI Agent / Scribe ]
        │
        ▼ (Tool Call)
[ Deedglass ] ──► (Evaluates CEL Policy Rules & Clinical Holds)
        │
        ▼ (Authorized FHIR Write)
[ Integration Engine / FHIR Facade ] (Mirth Connect / Rhapsody / HAPI)
        │
        ▼ (Validated Transaction / HL7 / Stored Procedure)
[ Legacy HIS (SQL Server / Oracle) ]

When an AI agent needs to update an allergy, move an appointment, or queue an order, it calls Deedglass’s FHIR or REST connector instead of talking directly to SQL.⁴

1. Policy Evaluation: Deedglass checks the request against the hospital’s policy rules (for example, holding any allergy update or prescription write for a clinician’s countersignature).
2. Execution: Once approved, Deedglass transmits the write to the FHIR endpoint or integration engine webhook.
3. Readback Verification: Deedglass immediately reads the record back by its resource ID, comparing every returned field against what the agent claimed to change (Checked).
4. Sealed Record: The complete action, including approvals and field diffs, is sealed into a tamper-evident audit record that anyone can verify offline.⁴

By keeping the integration engine in the path, hospital IT ensures that existing HL7 business rules, schema constraints, and data validations remain active.

Pattern 2: The MCP wrapper route

When internal IT tools or administrative automation scripts must execute specific procedures against SQL Server or Oracle, hospital engineers wrap those operations into a Model Context Protocol (MCP) server.⁴

Instead of giving an agent arbitrary SQL execution privileges, the MCP server exposes constrained, parameterized tools:

• patient_directory.lookup_by_mrn(mrn)
• schedule.find_available_slots(provider_id, date)
• billing.draft_claim_submission(encounter_id)

Hospital IT then wraps the MCP server with Deedglass:

Code Commands typed in a terminal. The text around it says what happens.

deedglass mcp wrap --connector his-tools -- npx -y @hospital/his-mcp-server

Deedglass intercepts every tool invocation by name, inspects arguments for injection attempts, requires multi-person approval on administrative operations, and creates signed audit records for every tool execution. The agent never receives raw database credentials or arbitrary SQL query execution capabilities.

Pattern 3: Debezium change data capture

For teams that require cryptographic verification of what a relational database actually committed to disk, Deedglass supports Change Data Capture (CDC) via Debezium.⁴

Debezium streams raw row-level change events from the database transaction logs (including SQL Server CDC, Oracle LogMiner, and MySQL binlogs) into Kafka or a JSON feed.²

With the command:

Code Commands typed in a terminal. The text around it says what happens.

deedglass witness debezium --feed events.jsonl

Deedglass parses the stream of database commits, matches the transaction timestamp and row primary keys against the agent’s intent, and labels the verification level Checked · via Debezium. Even without a direct database connection, hospital security officers get an immutable log showing exactly which rows changed when an agent ran.

This pattern is especially valuable for periodic audit reviews, enabling clinical risk teams to verify that agent activity matched expected parameters over the preceding shift or clinical reporting cycle.

AI built into your HIS versus external agents

Another boundary noted on the hospital page is “AI built into your HIS: Not covered.”⁴

It is essential to distinguish between two categories of healthcare AI:

1. Embedded Vendor AI: If your EHR vendor (such as Epic or Cerner) builds an internal AI feature that executes inside the vendor’s closed binary, those database writes happen internally. Because no external network call or MCP invocation is generated, Deedglass cannot intercept it.
2. External AI Tools & Agents: Ambient scribes running on mobile devices (such as Abridge, Suki, or Nuance DAX), autonomous coding agents in developer IDEs, and custom hospital automation bots communicate over HTTP, REST, and MCP.

Deedglass is designed specifically to govern and record this second category, ensuring that external autonomous tools never execute unauthorized changes against clinical systems.

Practical checklist for hospital IT

Before approving any AI agent pilot in a hospital department, verify these five controls:

1. No direct database credentials: Ensure the AI agent does not possess SQL connection strings or credentials to production tables.
2. Expose mediated APIs: Require the tool to communicate through an integration engine or FHIR REST endpoint.
3. Enforce write tiers: Require human-in-the-loop countersignatures for any write affecting clinical notes, medications, or patient identifiers.
4. Self-host the control plane: Run your verification gateway inside your own private network so patient health information never leaves your perimeter.⁴
5. Verify records offline: Ensure audit records can be inspected and verified with standard cryptographic tools without relying on external vendor servers.⁴

Testing the patterns in your environment

Hospital IT teams can test policy evaluation and verification workflows without installing proprietary infrastructure.

You can try the interactive policy sandbox directly in your browser at /play to explore how rules hold high-risk actions and record tamper-evident records. To evaluate your existing coding tools, MCP wrappers, or agent configurations on your local workstation, run the local scanner:

Code Commands typed in a terminal. The text around it says what happens.

npx deedglass scan

The scan checks local configuration files, permissions, and database roles without transmitting data outside your machine. You can read what the security score means to evaluate your current defense posture before connecting agents to clinical systems.

Written with AI assistance and checked against our claims register.