@o-lang/icu-admission

O-Lang resolver — ICU patient admission with team-scope enforcement

Part of the O-Lang Protocol ecosystem.
Licensed under Apache 2.0.

What It Does

@o-lang/icu-admission processes ICU patient admission requests inside a governed O-Lang workflow. It enforces two things the kernel cannot:

1. Team-scope enforcement — each clinical team is only permitted to admit patients to their assigned wards. Requests outside that scope are rejected with a structured reason, not silently allowed.
2. Bed availability — checks whether a bed is available in the requested ward before confirming admission.

The resolver never fabricates data. If a patient cannot be admitted, it returns a rejected status with a clear reason — the kernel records this in the audit trail and the downstream LLM step summarises it for the clinical team.

Installation

npm install @o-lang/icu-admission

Usage in a Workflow

Workflow "ICU Patient Admission" with patient_id, ward, team, notes

Allow resolvers:
- @o-lang/icu-admission
- @o-lang/llm-groq

Step 1: Ask @o-lang/icu-admission "{patient_id}" "{ward}" "{team}"
Save as admission_result

Step 2: Ask @o-lang/llm-groq "Summarise this ICU admission for the clinical team.
Patient: {patient_id}. Ward: {ward}. Team: {team}.
Admission status: {admission_result.status}.
Bed assigned: {admission_result.bed_assigned}.
NEVER suggest treatments or actions outside the assigned team scope."
Save as response

Return response

Action String Format

The kernel canonicalises the Ask syntax and calls the resolver with:

Action @o-lang/icu-admission "{patient_id}" "{ward}" "{team}"

All {symbol} placeholders are interpolated by the kernel before the resolver receives the action string.

Inputs

| Argument | Type | Required | Description | |---|---|---|---| | patient_id | string | ✅ | Unique patient identifier (MRN or local ID) | | ward | string | ✅ | Target ward — see valid values below | | team | string | ✅ | Assigned clinical team |

Valid wards: ICU · HDU · CCU · NICU · Surgical ICU

Output

Saved into workflow context via Save as. Always returns one of two shapes:

Admitted:

{
  "patient_id":     "P-00789",
  "ward":           "ICU",
  "team":           "Team A",
  "status":         "admitted",
  "admission_id":   "ICU-MM86MRTU-0789",
  "admitted_at":    "2026-03-01T20:08:11.106Z",
  "bed_assigned":   "ICU-14",
  "rejection_reason": null
}

Rejected:

{
  "patient_id":     "P-00790",
  "ward":           "NICU",
  "team":           "Team A",
  "status":         "rejected",
  "admission_id":   null,
  "admitted_at":    null,
  "bed_assigned":   null,
  "rejection_reason": "Team \"Team A\" is not permitted to admit to NICU. Permitted wards: ICU, HDU"
}

A rejected status is a valid business outcome — the resolver returns { output }, not { error }. The kernel saves it to context and execution continues to the next step.

Failure Codes

Hard failures return { error: JSON.stringify({...}) } and halt the workflow.

| Code | Cause | |---|---| | MISSING_PATIENT_ID | patient_id not provided | | MISSING_WARD | ward not provided | | MISSING_TEAM | team not provided | | INVALID_WARD | ward is not one of the five valid values | | RESOLVER_ERROR | Unexpected runtime error |

Team → Ward Scope

| Team | Permitted Wards | |---|---| | Team A | ICU, HDU | | Team B | CCU, HDU | | Team C | NICU, Surgical ICU | | On-Call | All wards |

File Structure

@o-lang/icu-admission/
├── index.js       ← kernel-facing entry point (action parsing, error wrapping)
├── resolver.js    ← pure business logic (team scope, bed availability)
├── capability.js  ← static declaration (inputs, outputs, failure modes)
└── package.json

Properties

| Property | Value | |---|---| | deterministic | false — bed availability is runtime state | | sideEffects | true — writes to admission records | | resolverName | @o-lang/icu-admission |

Part of the O-Lang Ecosystem

• O-Lang Spec v1.1
• O-Lang Runtime
• Resolver Conformance Test Suite