clinical-os DomainOS

Status: Scaffold (routing wired, skills pending)
Engine: clinical-os
Domain: EHR analytics (MIMIC, eICU, OMOP, PyHealth)

EHR-analytics DomainOS: PyHealth patient-trajectory modeling, mortality and readmission prediction, and drug recommendation over MIMIC / eICU / OMOP. Scaffold with a pyhealth wrapper; routing degrades to the pubmed + clinical-trials MCP fallback.

Field	Value
Product	clinical-os
Engine id	clinical-os
Intent key	clinical_os
Repository	Hordago-Labs/clinical-os
Plugin	clinical-os
Maturity (registry)	Scaffold (routing wired, skills pending)

Overview

EHR-analytics DomainOS: PyHealth patient-trajectory modeling, mortality and readmission prediction, and drug recommendation over MIMIC / eICU / OMOP. Scaffold with a pyhealth wrapper; routing degrades to the pubmed + clinical-trials MCP fallback.

Scientific approach

clinical-os structures every run as 4 phases. Gates marked HITL require an explicit human-in-the-loop approval before the run advances.

#	Phase	Gate	HITL
1	Cohort Definition	Define the OMOP/MIMIC cohort.	No
2	Feature Engineering	Build patient trajectory features.	No
3	Model Training	Train mortality/readmission models.	No
4	Evaluation	Evaluate calibration and fairness.	Yes

Capabilities & evidence objects

Domain tools / skills

• pyhealth-wrapper
• trajectory-modeling
• mortality-prediction
• readmission-risk
• drug-recommendation

Evidence objects

Object	Role	Consumer
result.json	planned	co-writer

Canonical artifacts (5-artifact contract)

Planned

The 5-artifact contract below is the target shape. Canonical-artifact emission is tracked as inherited debt (Wave 3C) and is not yet guaranteed.

Artifact	Description
result.json	Structured primary result payload for the domain run.
report.md	Human-readable narrative summary of the analysis.
provenance.json	Tool versions, reference data, and algorithm lineage for reproducibility.
gate_status.json	Per-phase gate pass/fail decisions.
session_summary.json	Session metadata for replay and audit.

Standalone quickstart

Zero platform dependency

This quickstart runs the DomainOS standalone. The Hordago platform is not required; platform composition is opt-in (see Composition below).

1. Install the standalone clinical-os plugin (Hordago-Labs/clinical-os) -- no Hordago platform required.
2. Invoke the domain skill with a clinical-os intent (see the intent keywords below).
3. Review the emitted artifacts under the run's output directory.

Intent keywords (route to this engine):

clinical pyhealth ehr mimic eicu omop electronic health record patient trajectory mortality readmission drug recommendation

Worked example

MIMIC mortality prediction (planned surface)

A user asks to predict in-hospital mortality on MIMIC. The planned surface defines the cohort, engineers trajectory features, trains a model, and reports calibration. Until skills land, requests degrade to the pubmed + clinical-trials MCP fallback.

Validation & benchmarks

Benchmarks

• Planned: PyHealth benchmark AUROC parity

Reproducibility. Planned: provenance.json will pin OMOP vocabulary and cohort definition.

Reference

MCP fallback servers (used when the plugin is unavailable): pubmed, clinical-trials

Source documents

• Scaffold-domains ledger (clinical-os): references/scaffold-domains.md

Composition

Platform opt-in

clinical-os runs standalone. When composed under the Hordago platform it gains cross-domain routing, the Shared Compiler gate, and evidence-audit provenance enforcement. Platform composition is opt-in; the quickstart above has zero platform dependency.

Cross-domain dependencies

Engine	Relationship
rare-os	Consumes diagnostic findings for clinical context.