AI MedAgent Developer Sandbox

The AI MedAgent Sandbox is a scripted demonstration environment that illustrates how the platform's clinical reasoning method is designed to work. It lets hospital IT teams, biomedical engineers, and medication management device manufacturers see the intended request/response shape and workflow described in a pending patent filing.

No credentials, no hospital infrastructure, and no installation required. You submit a structured JSON event in the UPES schema, and the demo returns a fixed, pre-written example decision response illustrating the intended action, recommended dose, confidence score, clinical rationale, and the IHE transaction the Gateway is designed to fire next. This is a scripted example, not a live AI call or a connection to real clinical data.

How It Works

The sandbox simulates the full AI MedAgent signal chain. When you click Run Request, the following sequence fires in real time:

1. UPES schema validation. The sandbox Gateway validates the envelope fields, checks required parameters, and confirms clinical value ranges are physiologically plausible.
2. PHI boundary enforcement. patient_id and encounter_id are confirmed local. Only de-identified clinical features cross to the AI engine.
3. Agent routing. The request_type field directs the event to the correct AI component: a Reactive Agent, the DL Optimizer, the Pharmacy Router, the CPOE Intercept Agent, or the Alarm Manager.
4. Claude AI engine evaluation. The clinical context is evaluated against evidence-based protocols (SCCAM, AHA, SSC guidelines). Formulary constraints, co-safety rules, and confidence thresholds are applied.
5. Structured decision returned. The response includes action, dose recommendation, confidence score, clinical rationale, and the Gateway Routing section showing which IHE transaction fires next.
6. Gateway log. The log panel traces every step the on-premise Gateway would execute: TLS handshake, JWT token validation, agent dispatch, pharmacy notification queuing, and audit log write.

In production, this entire sequence runs in under 100 milliseconds on the on-premise Gateway for Reactive Agent decisions, and under 500 milliseconds end-to-end including the cloud round trip.

Getting Started

The fastest path to a working result is four steps:

1. Open the sandbox console. No login. No API key entry. sandbox.html connects to a live Claude engine with credentials already configured.
2. Select CABG ICU — Vasopressor. This is the primary reference scenario. It covers the most common Reactive Agent use case: MAP declining below threshold on a post-cardiac surgery patient with an active vasopressor infusion.
3. Click Run Request. Watch the Gateway Log trace the signal chain. The response renders as a structured decision card with action, recommended dose, confidence bar, and clinical rationale.
4. Switch to the Schema tab. Every field in the request is documented with type, required/optional status, clinical validation rules, and an example value. Modify the JSON and re-run to test your own scenarios.

Reading the Request JSON

Every request to the AI MedAgent engine is a UPES event (Unified Patient Event Schema). The schema normalizes data from any source protocol — IHE PCD-01 monitor observations, IHE PCD-10 pump events, HL7 LRI lab results, FHIR R4 medication orders — into a single consistent structure that the AI engine reasons over, as described in the patent filing.

Reading the Response

The response is a structured clinical decision object. The sandbox renders it as a decision card. The raw JSON underneath contains every field the production Gateway would act on. The Gateway Routing section below the card describes exactly which IHE transaction fires next and whether pharmacy approval is required before pump programming begins.

Test Scenarios

Eight pre-built scenarios cover the full AI MedAgent adoption stage spectrum. Each loads a complete, clinically valid UPES payload. The Custom scenario lets you build your own.

Request Schema

Every request to the AI MedAgent engine uses the Unified Patient Event Schema (UPES) defined in SDK v2.0 Section 7. These top-level envelope fields are required on every request regardless of event type.

patient_context

Clinical context for the patient. All fields are required. patient_id and encounter_id remain inside the hospital network. The AI engine never receives direct patient identifiers.

device_observations (IHE PCD-01)

Array of vital sign and device parameter observations from patient monitors and ventilators. Maps to IHE PCD-01 (DEC profile) ORU^R01 messages normalized by the Gateway. Multiple observations representing a trend are passed as an array; the AI agent evaluates direction and rate of change, not just the most recent value.

active_infusions (IHE PCD-10)

Array of active infusion pump events. Maps to IHE PCD-10 (IPEC profile) ORU^R42 messages. Provides the AI engine with current drug, concentration, and infusion rate for dose delta calculations. Required for Stage 5+ deployments with closed-loop pump integration. Pass an empty array [] for Stage 1–4 deployments.

lab_results (HL7 LRI / FHIR R4)

Array of laboratory results. Maps to HL7 v2.5.1 LRI ORU^R01 messages via MLLP or FHIR R4 Observation resources via SMART on FHIR subscription. The Gateway filters for medication-relevant analytes using the LOINC codes in SDK v2.0 Section 5.3. Pass an empty array [] for Stage 1 (monitors-only) deployments.

request_type Values

The request_type field routes the event to the correct AI engine component.

Response Structure

Every AI MedAgent decision response returns a structured JSON object followed by a plain-text Gateway Routing section. The sandbox renders the JSON as a decision card.

Action Values

Gateway Routing

Below the decision JSON, the sandbox returns a plain-text Gateway Routing section. This describes exactly what the on-premise Gateway would do next with this decision in a production deployment: which IHE transaction fires, whether pharmacy approval is required before pump programming, and how the nurse is notified.

Clinical Safety Rules

The AI engine enforces these rules on every request. They cannot be overridden by request parameters. Understanding them prevents confusion when the engine returns a different action than expected.

Error Codes

Full error reference is in SDK Supplement v2.1 Section B. Key codes relevant to sandbox testing:

What This Represents

This sandbox illustrates a proof-of-concept architecture, not a production-ready integration path. It demonstrates a new and unique possible approach to closed-loop medication management that may improve outcomes and reduce costs, described in a pending patent filing. It is not a commercial product, and there is no support offering, SDK download, or integration engagement associated with it at this time.