npm package: @o-lang/icu-admission
Description: O-Lang resolver — ICU patient admission with database-backed bed availability and team-scope enforcement
Latest version: 1.0.3

# @o-lang/icu-admission

> O-Lang resolver — ICU patient admission with team-scope enforcement

Part of the [O-Lang Protocol](https://o-lang-central.github.io/spec/v1.1.html) 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

```bash
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:**
```json
{
  "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:**
```json
{
  "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](https://o-lang-central.github.io/spec/v1.1.html)
- [O-Lang Runtime](https://github.com/O-Lang-Central/runtime)
- [Resolver Conformance Test Suite](https://github.com/O-Lang-Central/resolver-test)