# AI & Digital Twin Readiness Checklist — BIDMC

> **Markdown report of a non-markdown source document.**
>
> | | |
> |---|---|
> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/Beth Israel Deaconess Medical Center/Hospital_AI_DigitalTwin_Readiness_Checklist for BIDMC.docx` |
> | **Format** | Microsoft Word (.docx), 29.6 kB |
> | **MD5** | `f7d1d4b7877b5f96cff9204012d4071f` |
> | **Owner** | Energy Management cluster |
> | **Status** | Current — **partially completed** (sections 1–3 scored, 4–8 blank) |
> | **Report generated** | 2026-07-25 |

## Scope

Covers Energy Microgrid (Shift data) + Clinical Operations + Integration + Governance.

**How to use it:** for each criterion, mark ☑ PASS, △ PARTIAL, or ✗ FAIL in the rightmost
column. **Any FAIL in Sections 1–4 is a blocker** for RL training or digital twin deployment.

**Clinical gap:** Sections 5–8 represent data that must be sourced from the hospital EMR, CMMS,
HR systems, and governance processes before a whole-hospital digital twin can be deployed.

Referenced data source: `https://physionet.org/content/mimic-iv-demo/2.2/icu/inputevents.csv.gz`

### Scoring legend

| Mark | Meaning |
|---|---|
| ☑ **PASS** | Criterion fully met |
| △ **PARTIAL** | Partially met; gap plan required |
| ✗ **FAIL** | Not met; deployment blocker |

> [!IMPORTANT]
> **Completion status.** Sections 1–3 have been scored. Sections 4–8 — including
> *Operational Constraints & Safety*, which the document itself declares a blocker section —
> are **entirely unscored**. This is the single most important open item in this document: the
> safety gate has been written but not walked through.
>
> The scorer also introduced two verdicts outside the legend — **"No need"** and
> **"No need for now"** — used 7 times. These are scope decisions, not readiness assessments,
> and they are recorded below verbatim.

---

## 1. Data infrastructure & temporal fidelity — *"The Substrate"*

Focuses on whether the raw data is granular and consistent enough for model training. Directly
maps to Shift input variables (V, I, P, SoC, irradiance, n_H2, etc.).

| Criterion | What to verify / acceptance standard | Verdict |
|---|---|---|
| **Data Resolution** | Time-series data available at ≤ 15-minute intervals. Applies to all dynamic variables (P, I, V, SoC) | ☑ Pass |
| **Timestamp Synchronization** | All generation (PV/fuel cell), storage (BESS), electrolyzer, and load meters time-aligned to a single master clock. Max drift < 1 second | △ Partial |
| **Historical Depth** | Minimum 12 months of continuous data to capture seasonal variability in load, solar irradiance (W/m²), and hospital occupancy patterns | ☑ Pass |
| **Telemetry Reliability** | Missing/null values < 5% across all channels. Gaps flagged with error codes rather than zero-filled. Consistent sampling rate | ☑ Pass |
| **Data Schema & Ontology** | Unified data dictionary maps every sensor tag (e.g. `V_electrolyzer`, `SoC_battery`, `n_H2_in`) to physical asset, engineering unit, and measurement type | *No need for now* |
| **Multi-System Integration Readiness** | Energy (SCADA/BMS), clinical (EHR/EMR), and facility (CMMS) data agree on one timing format. ETL pipeline or middleware (HL7 FHIR, OPC-UA, Brick Schema) documented; data repeatable and up to date | △ Partial |

## 2. Reinforcement learning readiness — *"The Agent"*

Shift data covers the energy action space and state space well; clinical rewards and
multi-agent aspects are absent.

| Criterion | What to verify / acceptance standard | Verdict |
|---|---|---|
| **Action Space Definition** | Enumerated list of controllable setpoints: charge/discharge power (kW), electrolyzer ON/OFF & power setpoint, fuel cell ON/OFF, HVAC setpoints, OR scheduling levers | △ Partial — *reward function should be defined* |
| **Control Latency Documentation** | Round-trip delay (command → hardware response) measured and documented for each actuator: electrolyzer ramp, BESS response, fuel cell throttle. Required for accurate environment simulation | △ Partial — *hydrogen ramp needed* |
| **Economic Reward Signals** | Local electricity tariffs (time-of-use, peak demand charges), carbon intensity factors, and cost-per-bed-day metrics available as time-series for RL reward shaping | ☑ Pass |
| **Clinical Reward Signals** | Outcome-linked metrics available: patient wait time, length-of-stay, readmission rate, adverse event rate — to define a multi-objective reward beyond energy cost alone | ☑ Pass |
| **Environmental Stochasticity** | Time-aligned local weather (irradiance W/m², ambient temperature K — from Shift data) plus demand shocks (mass-casualty events, seasonal disease surges) to model real-world uncertainty | ☑ Pass |
| **State Space Completeness** | All observable variables logged: Shift energy states (SoC, V, I, P, n_H2, p_tank) plus clinical census and equipment status. Partially observable regions identified and quantified | ☑ Pass |
| **Multi-Agent Considerations** | Interdependencies between semi-autonomous units (ED, ICU, OR, pharmacy, energy microgrid) mapped. Conflict-resolution protocol defined for competing RL agents | *No need* |
| **Simulation Environment (Gym)** | A simulator or emulator exists where the RL agent trains without affecting the live hospital. Electrolyzer, fuel cell, BESS, and PV physics models (using Shift parameters) implemented offline | *No need* |
| **Minimum Operating Constraints** | Minimum operating current (electrolyzer) and operating voltage range (fuel cell) that cannot be violated by any RL action | ☑ Pass |
| **Hydrogen Production Calibration** | Measured hydrogen production rate calibration factor (Shift data) applied to the `n_H2` output model to correct for real-world deviation from theoretical Faraday efficiency μ_F | ☑ Pass |

> [!WARNING]
> **"Simulation Environment (Gym) — *No need*"** directly contradicts the rest of the project.
> Building exactly this Gym-style environment is what the
> [Simulator I/O Interface](../02-specifications/simulator-io-interface.md) exists to specify,
> and it is [WP3/WP4](../01-project/work-packages.md) of the work plan. The most likely reading
> is *"not needed as a prerequisite from the hospital"* — i.e. SHIFT builds it, so BIDMC does
> not have to supply it. Worth clarifying in the source document, because as written it reads
> as a scope cut.
>
> Similarly, **"Clinical Reward Signals — Pass"** is optimistic: the
> [RL reward specification](../02-specifications/rl-reward-function.md) contains no clinical
> outcome term at all, and Section 5 of this same checklist marks all clinical operations data
> as *"entirely absent from the Shift input data."*

## 3. Digital twin & physics-based modelling — *"The Twin"*

Shift data provides good component constants (N_c, μ, A_PV, E_rated, Q_rated); topology and
clinical process models are missing.

| Criterion | What to verify / acceptance standard | Verdict |
|---|---|---|
| **Electrolyser Physics Model** | N_c (cells), μ_F (Faraday efficiency), operating voltage V, minimum current, power setpoint range, n_H2 output — all documented | ☑ Pass |
| **Fuel Cell Physics Model** | N_c (cells), voltage range, max output power, utilization %, n_H2_in and n_H2_used documented. Efficiency-vs-load curves at 25/50/75/100% utilization required | ☑ Pass |
| **Hydrogen Tank Model** | V_H2 max & initial (L), temperature T (K), pressure p (atm), n_H2_in and n_H2_out flow rates available for tank thermodynamic (ideal gas) model | ☑ Pass |
| **PV & Battery Parameters** | A_PV (m²), panel efficiency μ, E_rated, Q_rated (charge capacity), max charge/discharge power, SoC max & initial — all in Shift data | ☑ Pass |
| **Component Performance Curves** | Non-linear efficiency-vs-load curves for fuel cell/CHP at multiple load points, chiller COP curves, generator fuel consumption. PV I-V curve under varying irradiance | △ Partial — *manufacturer data sheet might be needed* |
| **System Topology — Energy** | Detailed electrical single-line diagram (SLD) and connection topology (PV→BESS→Electrolyser→Fuel Cell→Load→Grid) in machine-readable format (CIM XML or equivalent) | ☑ Pass |
| **System Topology — Facility & Clinical** | Floor plans, room-to-department mappings, HVAC zone layouts. Hospital load P_load disaggregated by unit (ICU, OR, wards, labs) for clinical-energy co-simulation | ☑ Pass |
| **Thermal Inertia & Dynamics** | Thermal mass of building envelope, hot-water storage, and critical rooms (OR, ICU) documented. Required for multi-energy modelling and infection-control simulation | *No need for now* |
| **Asset Health / Degradation** | Historical SoH or cycle-count data for BESS; maintenance logs for electrolyzer membrane and fuel cell stack to model long-term degradation | △ Partial — *historical maintenance logs for electrolyser membranes not included* |
| **Patient Flow Physics Model** | Stochastic arrival models (Poisson / time-varying) calibrated to historical ED arrivals. Service-time distributions per acuity level and DRG/care-pathway | *No need for now* |
| **Infection & Environmental Models** | HVAC air-change rates, filtration levels, and room-pressure differentials per zone documented to support the infection-risk component | *No need for now* |
| **Twin Validation Dataset** | ≥ 3 months of historical data withheld from training for twin accuracy validation. Covers both energy and clinical domains | ☑ Pass |
| **Uncertainty Quantification** | Method defined for reporting confidence intervals. Ensemble, Bayesian, or conformal prediction approach specified. Sim-to-real gap assessment methodology documented | *No need for now* |

> **"System Topology — Facility & Clinical — Pass"** sits awkwardly against the
> [Simulator I/O Interface](../02-specifications/simulator-io-interface.md#5-open-questions),
> which lists *"Critical vs non-critical split — data availability"* as an unresolved open
> question, and against §6 below, which marks Hospital Load Disaggregation as unscored.

## 4. Operational constraints & safety — *"The Boundary"*

Guardrails ensuring the AI or twin does not simulate or propose dangerous actions. Shift data
covers energy hard limits partially; clinical safety floors and full islanding sequences are
absent.

> **Not yet scored.** Every verdict below is blank in the source. Per the document's own rule,
> any FAIL here is a deployment blocker — so this section must be completed before RL training
> is considered ready.

| Criterion | What to verify / acceptance standard | Verdict |
|---|---|---|
| **Hard Safety Interlocks — Energy** | Controller limits documented: min/max BESS SoC, electrolyser minimum current, fuel cell voltage range and max output power, maximum grid connection capacity | *(blank)* |
| **Hard Safety Interlocks — Clinical** | Clinical safety floors documented: minimum nurse-to-patient ratios per acuity, minimum OR turnaround time, ICU bed reserve thresholds. Encoded as inviolable RL constraints | *(blank)* |
| **Ramping Constraints** | Maximum ramp rates (MW/min) for gas engines, fuel cells, and HVAC plant. Clinical analogue: maximum safe admission rate per hour per unit during demand surge | *(blank)* |
| **Critical Load Ranking** | Quantified load priority list: Tier 1 (ICU/OR/Life Safety), Tier 2 (Labs/Pharmacy/NICU), Tier 3 (Admin/Amenities). Machine-readable for automated load-shedding decisions | *(blank)* |
| **Islanding Protocols** | Grid-disconnection and reconnection sequence fully documented and machine-readable. Islanded-mode operating limits for all critical loads. Grid ON/OFF flag is necessary but not sufficient | *(blank)* |
| **Regulatory & Compliance Constraints** | HIPAA, CMS Conditions of Participation, Joint Commission, and local fire/life-safety codes encoded as hard constraints in the RL reward/penalty function | *(blank)* |
| **Fail-Safe & Override Modes** | Human override capability exists for every AI-controlled setpoint (electrolyser, BESS, fuel cell, load-shed relay). Override events logged. Manual-control fallback tested and certified | *(blank)* |
| **Adverse Event Taxonomy** | Formal taxonomy of AI-attributable adverse events defined: loss of life-safety power, inadvertent ICU load shed, delayed discharge due to energy curtailment. Used for reward shaping | *(blank)* |

> Note: the Tier 2 membership here (**Labs/Pharmacy/NICU**) differs from the tier definition in
> [Energy Flow and Balances](bidmc-ucsd-energy-flow-and-balances.md) (**Clinical HVAC, Imaging,
> Medical Wards, Critical Lighting**). Two different tier taxonomies are in circulation.

## 5. Clinical & operational data — *"The Patient Flow Engine"*

Core hospital operations data — **entirely absent from the Shift input data**. Essential for a
whole-hospital digital twin beyond the energy microgrid subsystem. *Not scored.*

| Criterion | Acceptance standard |
|---|---|
| **ADT Event Logs** | Admission, Discharge, Transfer events with timestamps, patient acuity (ESI/DRG), and destination unit. Minimum 24 months for seasonal modelling |
| **Bed Occupancy Time-Series** | Per-unit bed census at ≤ 1-hour intervals. Staffed vs licensed bed counts distinguished. Surge capacity thresholds and escalation triggers documented |
| **ED Arrival Patterns** | Hourly ED arrival counts with triage acuity (ESI 1–5) for ≥ 24 months. Required to fit time-varying Poisson arrival distributions |
| **Length-of-Stay Distributions** | LOS distributions per DRG/condition for inpatient and observation stays. Geometric mean LOS and outlier thresholds (± 1 SD) per condition group |
| **OR Scheduling & Utilisation** | Scheduled vs actual case start/end times, case type, room, turnover durations for ≥ 12 months. Block-time rules and add-on case policies documented |
| **Staffing & Shift Patterns** | Nurse, physician, and tech staffing levels per unit per shift, linkable to patient outcomes (falls, medication errors, HCAHPS). Shift handoff protocols documented |
| **Equipment Utilisation Logs** | Utilisation rates for ventilators, imaging (CT/MRI), infusion pumps, dialysis machines. Required to model equipment bottlenecks and energy demand spikes |
| **Lab & Radiology Turnaround** | Order-to-result turnaround for STAT and routine orders. Essential for care-pathway twin fidelity and discharge delay modelling |
| **Medication Dispensing Patterns** | Pharmacy dispense records with timestamps and location. Enables supply-chain and medication-delay modelling |
| **Readmission & Outcome Data** | 30-day readmission rates, in-hospital mortality, HAI rates, and patient satisfaction scores linkable to admission episodes for RL reward calibration |

## 6. Multi-domain integration & interoperability — *"The Connective Tissue"*

Assesses whether energy (Shift data), clinical (EMR), and facility (CMMS) data can be
semantically and temporally linked into one twin environment. *Not scored.*

| Criterion | Acceptance standard |
|---|---|
| **Common Data Model** | Unified ontology adopted or cross-schema mapping documented: FHIR R4 (clinical), CIM XML (energy), Brick Schema (facility/HVAC). Shift variable names mapped to ontology terms |
| **Cross-Domain Time Alignment** | Clinical (EMR), energy (SCADA/BMS/Shift), and facility (CMMS) data share ISO 8601 UTC timestamps and can be inner-joined without resampling artefacts |
| **Semantic Linkage — Energy to Clinical** | Energy demand surge events (BESS discharge, fuel cell activation) causally linked to clinical triggers (census spike, OR activation) via a shared event log |
| **Hospital Load Disaggregation** | The lumped `P_load` variable disaggregated into sub-meter readings per clinical unit (ICU, OR, wards, labs) for unit-level load forecasting and clinical-energy co-optimisation |
| **Data Governance & Access Controls** | Data sharing agreements, de-identification protocols (HIPAA Safe Harbor or Expert Determination), and role-based access controls documented and active for all data streams |
| **Real-Time API / Feed Availability** | Live data feeds (REST/MQTT/OPC-UA/HL7) from BMS, EMR, and SCADA available for real-time twin synchronisation. Latency < 30 s per stream documented |
| **Master Asset Register** | Single register links physical assets across EMR billing codes, CMMS maintenance IDs, and SCADA tag names (e.g. electrolyser unit ↔ maintenance record ↔ SCADA tag) |

## 7. Reward function & objective completeness — *"The Goal"*

Ensures the RL reward captures all hospital objectives. Shift data provides only energy-side
inputs; clinical outcome metrics and multi-objective weighting are absent. *Not scored.*

| Criterion | Acceptance standard |
|---|---|
| **Multi-Objective Reward Definition** | Formal reward function with explicit weights or Pareto constraints across energy cost, patient outcomes, throughput, safety violations, and staff workload |
| **Reward Shaping for Safety** | Safety violations (loss of life-safety power, ICU boarding > threshold, electrolyser overcurrent) incur large negative rewards. Magnitudes validated by clinical and engineering experts |
| **Reward Time Horizon** | Discount factor (γ) and episode length balance short-term energy cost savings vs long-term asset health (BESS degradation, electrolyser membrane life) and patient outcome improvement |
| **Reward Signal Observability** | All reward components measurable in real time or near real time (< 5-min lag). Proxy metrics defined for unobservable outcomes |
| **Reward Alignment Validation** | Clinical, engineering, and operations SMEs reviewed and signed off the reward function. Ethics policy confirmed. **Reward not gameable by trivial policy** (e.g. always import grid power) |

> This section is the direct counterpart to the
> [RL Reward Function specification](../02-specifications/rl-reward-function.md), whose central
> open problem — *no weights defined across 26 terms* — is precisely "Multi-Objective Reward
> Definition" here.

## 8. Validation, uncertainty & governance — *"The Trust Framework"*

Criteria for testing the twin against reality, quantifying uncertainty, and governing AI
decisions before and after deployment. *Not scored.*

| Criterion | Acceptance standard |
|---|---|
| **Held-Out Validation Dataset** | ≥ 3 months of historical data withheld from training. Twin predictions compared to actuals: energy forecast MAPE ≤ 5%, bed census MAPE ≤ 10%, LOS prediction within ± 0.5 days |
| **Key Accuracy Thresholds** | Minimum accuracy targets defined per output before deployment sign-off: energy, bed census, LOS, equipment utilisation, and hydrogen production rate |
| **Sim-to-Real Gap Assessment** | Formal protocol to measure and track divergence between twin predictions and real outcomes over time. Drift threshold triggers automatic re-calibration |
| **Uncertainty Quantification** | Confidence/prediction intervals reported for all twin outputs. Ensemble, Bayesian, or conformal prediction approach specified and propagated through multi-step forecasts |
| **Explainability Requirements** | RL policy actions explainable to clinical and operational staff. SHAP or LIME applied to high-stakes decisions (load shedding, electrolyser curtailment during peak clinical demand) |
| **Model Governance & Versioning** | All model versions tracked with training data lineage, hyperparameters, and performance metrics. Rollback to prior version possible. Change-control process documented |
| **Continuous Monitoring Plan** | Post-deployment dashboard covers model drift, data quality degradation (sensor failures), and safety-constraint violations. Alert thresholds and escalation paths defined |
| **Ethics & Bias Review** | Training data audited for demographic bias in clinical submodels. Outputs reviewed for disparate impact across patient subgroups (race, age, insurance). Review board sign-off required |
| **Regulatory / SaMD Assessment** | If the digital twin or RL agent constitutes Software as a Medical Device (SaMD), FDA 510(k)/De Novo or EU MDR classification assessed and submission strategy documented |

> The **energy forecast MAPE ≤ 5%** threshold here matches the CV-RMSE < 5% target in the
> [Forecasting Requirements](../02-specifications/forecasting-requirements.md#23-evaluation-and-metrics),
> though one is MAPE and the other CV-RMSE — worth reconciling so a single number gates
> deployment.

## Related

- [BIDMC Datasets Manual](bidmc-datasets-manual.md) — the data this checklist assesses
- [BIDMC ComStock Load Profile](bidmc-parquet-load-data-manual.md)
- [RL Reward Function](../02-specifications/rl-reward-function.md) — §7 is its readiness gate
- [Simulator I/O Interface](../02-specifications/simulator-io-interface.md) — the Gym environment §2 refers to
- [UCSD Equipment Manual](ucsd-equipment-manual.md) — component specs §3 depends on