Healthcare Orchestrator

Healthcare Orchestrator

The single entry skill for healthcare-software work. It locates the task on the lifecycle × concern map and delegates to one of four specialist spokes. The cross-cutting model every clinical app shares — the three-layer data-protection contract (classify → control access → audit), the patient-safety bias (alerts block, never silently pass), and the CRITICAL-vs-HIGH gate thresholds — lives in healthcare-core; read it before designing data access, wiring a CDSS alert, or configuring a deploy gate.

Cluster map

• healthcare-phi-compliance — the data-protection implementation core: PHI/PII classification, Row-Level Security, audit trails, encryption, and the common leak vectors (logs, URLs, browser storage, service keys). Multi-jurisdiction: HIPAA (US), DISHA (India), GDPR (EU).
• healthcare-emr-patterns — EMR/EHR build patterns: the single-page encounter flow, smart clinical templates, the locked-encounter + addendum model, prescription PDFs, and accessibility-first medical UI.
• healthcare-cdss-patterns — the Clinical Decision Support engine as a pure, side-effect-free function library: drug-interaction checking (bidirectional), weight/age/renal dose validation, clinical scoring (NEWS2, qSOFA), and alert-severity → UI behavior.
• healthcare-eval-harness — the patient-safety verification gate: five test categories, three CRITICAL (100%, block deploy) + two HIGH (95%+, warn), wired into CI/CD.

Routing rules by intent

Privacy, access, and data exposure

• "Is this PHI? can we log/send/store it?" → healthcare-phi-compliance
• RLS / multi-facility isolation / audit-trail schema → healthcare-phi-compliance
• Vendor / LLM-provider / analytics data path → healthcare-phi-compliance (model in healthcare-core)

Building the clinical app (EMR/EHR)

• Encounter workflow, templates, locked notes, prescription UI → healthcare-emr-patterns
• Accessible medical data-entry UI → healthcare-emr-patterns

Clinical decision support (patient-safety logic)

• Drug-interaction / dose-validation / clinical-scoring logic → healthcare-cdss-patterns
• Alert severity → block/acknowledge/inform UI behavior → healthcare-cdss-patterns (consumed by healthcare-emr-patterns)

Shipping safely

• Pre-deploy safety gate / CI thresholds / eval report → healthcare-eval-harness

Standard flow

1. Locate the task: which lifecycle stage (protect data → build workflow → wire decision-support → gate the deploy) and which concern.
2. If it touches PHI handling, audit, alert-severity behavior, or deploy thresholds, pull the model from healthcare-core first — these are interlocking, not independent.
3. Delegate to the spoke(s). Multi-step asks fan out in lifecycle order — e.g. "add AI visit summaries to a clinician dashboard" → healthcare-phi-compliance (PHI/prompt/vendor boundary) → healthcare-emr-patterns (where it renders) → healthcare-cdss-patterns (if it influences a decision) → healthcare-eval-harness (gate before ship).
4. Return: chosen spoke(s), the PHI/audit and patient-safety implications, the jurisdiction(s) in play, and the next action.

Guardrails

See healthcare-core. In short: patient safety and minimum-necessary access are non-negotiable — a critical CDSS alert blocks the action (never a dismissable toast), a missing weight blocks a mg/kg dose (never passes), and PHI never lands in logs, URLs, browser storage, prompts, or client-visible errors. Treat any third-party SaaS / LLM / observability vendor as blocked-by-default until its data boundary (and BAA, for US) is clear. A single CRITICAL eval failure blocks the deploy — don't lower the threshold to get green.

Loading spokes on demand

To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:

~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).