Triage a device complaint for MDR

# Assemble the Decosa device complaint MDR triage on this machine

You are setting up a self-hosted MDR reportability triage on this Linux machine for a medical device maker's regulatory
affairs and quality team. It reads a complaint (narrative, dates, device) and the product's labeling, and returns:
- the 21 CFR 803.50(a) questions answered one by one (death or serious injury? could the device have caused or
  contributed? a malfunction? likely to cause or contribute to a death or serious injury if it recurred?), each with the
  words from the complaint that decide it, found word for word by code;
- a suggestion: reportable, not reportable, or needs investigation, with the reasoning chain;
- the clock (30 calendar days, 5 work days, or 10 work days for user facilities) from the awareness date, with the rule
  and the arithmetic;
- the complaint-record check against 21 CFR 820.35(a) and the Form 3500A items still unknown;
- a draft 3500A event description with every sentence checked against the complaint;
- a signed triage record, a signed decision record for the named person who decides, and a failure-mode trend view.

Work step by step, show me each command before running anything that needs sudo, and stop if a check fails.

**Before anything else, remind me:**
- Complaints can hold patient health information. Keep everything on this machine: the model route stays local
  (`direct`), and nothing goes to a hosted service.
- This is a triage aid, not a reportability determination and not legal or regulatory advice. A qualified person decides
  and signs; it never says a firm or a file is compliant, and it files nothing with FDA.

Repeat both points in your final summary.

## Step 0: set up with a coding agent, rehearse on mock data, then go private

This prompt is for a coding agent running on the machine that will host the service. We recommend Claude Code with
Claude Opus 5.5; any capable coding agent works. Work in this order:

1. Set up on mock data only. During the whole setup you (the agent) work with the synthetic sample bundle below and
   nothing else. Do not ask me for real data, and do not open, read, list or copy files that hold real data, even to
   "test with something realistic".
2. Rehearse. When the steps below are done and the service is healthy, fetch the mock-data bundle for this tool,
   https://decosa.ai/samples/device-mdr-triage.zip (5 KB, 16 checks, synthetic or openly licensed: see `licence` in expected.json),
   show me what is in it, and run the rehearsal against the local API:
   `docker compose exec api python scripts/rehearse.py device-mdr-triage` (the api image carries the same bundle under /app/rehearsal/device-mdr-triage/;
   with no key set, the script asks the local API for a short demo token). From a decosa-api checkout instead:
   `python scripts/rehearse.py device-mdr-triage --bundle device-mdr-triage.zip --base-url http://127.0.0.1:<PORT>`.
   It sends the mock inputs to the local API and prints PASS or FAIL for each expected property (for example: "a 5-day report requested by FDA is due 5 work days after 2 Sep 2026, skipping Labor Day (no model)", "the catheter complaint looks reportable", "the outcome is a serious injury, with a quote from the complaint"). Show me
   the full output. Every check must pass. If one fails, fix the install and run it again; never edit `expected.json`
   to make a check pass.
3. Stop there. Once the rehearsal passes, tell me, and I will run my own data against the local API myself, on this
   machine.

For the person running this: a coding agent that runs in the cloud sees everything in its context, including files it
reads, command output and anything pasted into the chat. Keep real data out of the chat and out of anything the agent
can read. Switch to your own data only after the rehearsal has passed and the agent's work is done.

## What you are building

| service | image | model | port |
|---|---|---|---|
| `llm` | `${DECOSA_REGISTRY}/decosa-llm:0.1.0` (vLLM 0.29.0, `vllm/vllm-openai@sha256:c2914767605584b6d8f45686b82de173ecc99e781897aa3d0a66dacd72c51ae1`) | `nvidia/Qwen3.8-27B-NVFP4` @ `482ca0f3832238542f8f5295dde86b5f22711d80`, Apache-2.0 | internal 8000 |
| `api` | `${DECOSA_REGISTRY}/decosa-api:0.1.0` (no GPU) | none | `127.0.0.1:8445` |

## 1. Check the GPU, driver and Docker

1. Run `nvidia-smi`. I need one NVIDIA GPU with at least 48 GB and driver 580 or newer.
   - Blackwell (RTX PRO 6000, B200): use the defaults below (NVFP4). This is the measured setup.
   - Hopper (H100/H200) or 48 GB Ada/L40S: set `LLM_MODEL=Qwen/Qwen3.8-27B-FP8` and `LLM_REVISION=main`. On a 48 GB card, also
     set `LLM_MAX_LEN=32768`. Not measured.
   - Under 48 GB: stop and tell me it will not fit.
2. Check `docker --version`, `docker compose version` and `docker run --rm --gpus all ubuntu nvidia-smi`. If Docker or the
   NVIDIA Container Toolkit is missing, install them from the official Docker and NVIDIA repositories. Then run
   `sudo nvidia-ctk runtime configure --runtime=docker` and restart Docker.
3. Confirm about 60 GB of free disk.

## 2. Get the images

The images are **on request** while self-host is in early access: ask at https://decosa.ai/contact?topic=self-host, and Decosa sends the registry (set it as `DECOSA_REGISTRY`), pull access and the compose file. Try `docker pull ${DECOSA_REGISTRY}/decosa-{llm,api}:0.1.0`.

If a pull fails, build from source once the `decosa-api` source is published:
- clone it;
- in the clone, run `docker build -f docker/api/Dockerfile -t ${DECOSA_REGISTRY}/decosa-api:0.1.0 .`;
- run `docker compose build llm` from its compose file.

If neither works, stop and tell me.

## 3. Write the compose file

Create `~/decosa-mdr/.env`:

```bash
DECOSA_TAG=0.1.0
DECOSA_GPU=0
LLM_MODEL=nvidia/Qwen3.8-27B-NVFP4
LLM_REVISION=482ca0f3832238542f8f5295dde86b5f22711d80
LLM_MAX_LEN=65536
LLM_GPU_UTIL=0.85
DECOSA_SIGNER_NAME="<who signs these records, e.g. Example Medical Devices RA/QA>"
```

Create `~/decosa-mdr/docker-compose.yml` with exactly these services:

```yaml
name: decosa-mdr
x-health: &health
  interval: 15s
  timeout: 5s
  retries: 5
services:
  llm:
    image: ${DECOSA_REGISTRY}/decosa-llm:${DECOSA_TAG}
    deploy: { resources: { reservations: { devices: [ { driver: nvidia, device_ids: ["${DECOSA_GPU:-0}"], capabilities: [gpu] } ] } } }
    ipc: host
    restart: unless-stopped
    volumes: [hf-cache:/root/.cache/huggingface]
    command: ["${LLM_MODEL}", "--revision", "${LLM_REVISION}", "--served-model-name", "qwen3.8-27b",
              "--language-model-only", "--max-model-len", "${LLM_MAX_LEN}", "--gpu-memory-utilization", "${LLM_GPU_UTIL}",
              "--max-num-seqs", "16", "--kv-cache-dtype", "fp8_e4m3", "--speculative-config", '{"method":"mtp","num_speculative_tokens":3}',
              "--seed", "0", "--enable-force-include-usage", "--disable-uvicorn-access-log", "--host", "0.0.0.0", "--port", "8000"]
    healthcheck: { <<: *health, test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/health', timeout=4)"], start_period: 900s }
  api:
    image: ${DECOSA_REGISTRY}/decosa-api:${DECOSA_TAG}
    restart: unless-stopped
    depends_on: { llm: { condition: service_healthy } }
    environment:
      DECOSA_LLM_ROUTE: direct                  # local model only; receipts are signed by this box's key ("attested")
      DECOSA_LLM_URL: http://llm:8000/v1
      DECOSA_LLM_MODEL: qwen3.8-27b
      DECOSA_LOCAL_SIGNING: "on"                # Ed25519 key created at /data/attest/ed25519.pem on first start
      DECOSA_SIGNER_NAME: ${DECOSA_SIGNER_NAME}
      DECOSA_SESSIONS_PER_IP_HOUR: "1000"
      DECOSA_BUDGET_LLM_TOKENS: "200000"        # per session; one triage needs up to about 5,000 generated tokens
      DECOSA_SESSION_TTL_S: "28800"
      DECOSA_MDR_MAX_CONCURRENT: "3"
      DECOSA_CORS_ORIGIN_REGEX: '^https?://(localhost|127\.0\.0\.1)(:\d+)?$$'
    ports: ["127.0.0.1:8445:8445"]
    volumes: [decosa-data:/data]
    healthcheck: { <<: *health, test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8445/healthz', timeout=4)"], start_period: 20s }
volumes: { hf-cache: {}, decosa-data: {} }
```

Use the named volume `decosa-data` exactly as written. A host bind mount owned by root makes the API fail on
`/data/keys.sqlite`.

Run `docker compose up -d`, then poll `docker compose ps` until both services are healthy. The LLM takes 5-10 minutes
the first time. `curl -s localhost:8445/healthz` should show `"llm": true` (`asr` is false here, which is fine).

## 4. Smoke test

The clock rules need no model:

```bash
API=localhost:8445
curl -s $API/mdr/clock -H 'content-type: application/json' -d '{"aware_date":"2026-09-02"}' | jq '.primary | {step, deadline, arithmetic}'
curl -s $API/mdr/clock -H 'content-type: application/json' -d '{"aware_date":"2026-09-02","fda_5day_request":true}' | jq -r .primary.deadline
```

Pass if the 30-day deadline is `2026-10-02` and the 5-day one is `2026-09-10` (Labor Day, 7 Sep, is not a work day).

Then the triage (demo complaints: public MAUDE narratives and synthetic ones):

```bash
TOKEN=$(curl -s $API/demo/session -H 'content-type: application/json' -d '{"vertical":"device-mdr-triage"}' | jq -r .token)
for s in rep-told-earlier cpap-lid-cosmetic meter-reads-high; do
  curl -s $API/mdr/triage -H "authorization: Bearer $TOKEN" -H 'content-type: application/json' \
    -d "{\"sample_id\":\"$s\"}" > /tmp/mdr-$s.json
  jq -c '{decision: .decision.decision, start: .clock.primary.start, due: .clock.primary.deadline, narrative: (.narrative != null), receipts: (.receipts|length), statuses: ([.receipts[].status]|unique)}' /tmp/mdr-$s.json
done
jq -r '.judgments[] | "\(.id)\t\(.answer)\t\(.evidence[0].quote // "-")"' /tmp/mdr-rep-told-earlier.json
jq '{record}' /tmp/mdr-rep-told-earlier.json | curl -s $API/record/verify -H 'content-type: application/json' -d @- | jq '{ok, summary}'
```

Pass if:
- `rep-told-earlier` is `reportable`, the outcome is `serious_injury` with a quote, and the clock starts `2026-09-02` (the
  day the sales rep was told, read from the complaint) and is due `2026-10-02`, with a narrative;
- `cpap-lid-cosmetic` is `not_reportable` with no narrative;
- `meter-reads-high` is `needs_investigation`;
- every receipt has `"status": "attested"`, and the record verifies (`ok: true`).

Then record a decision and check it:

```bash
jq '{triage_record: .record, decision: "reportable", report_type: "30_day", decider: {name: "Test Reviewer", role: "RA specialist"}, rationale: "Snare retrieval of a retained fragment is an intervention to prevent permanent damage."}' /tmp/mdr-rep-told-earlier.json \
  | curl -s $API/mdr/decide -H "authorization: Bearer $TOKEN" -H 'content-type: application/json' -d @- > /tmp/mdr-decision.json
jq '{record}' /tmp/mdr-decision.json | curl -s $API/record/verify -H 'content-type: application/json' -d @- | jq '{ok, summary}'
```

Pass if the decision record verifies.

## 5. Point your complaint system at the local API

- Base URL: `http://localhost:8445`. For a web app, set `NEXT_PUBLIC_DECOSA_API=http://localhost:8445`. Add other origins to
  `DECOSA_CORS_ORIGINS`.
- `POST /mdr/triage` takes `{complaint: {narrative, id?, received_date?, aware_date?, event_date?, device?: {name, model,
  lot, serial, udi, product_code}, complainant?, patient?, correction?, reply?, investigation?}, product?: {name,
  common_name, labeling, implant?, life_supporting?, class?}, role?: manufacturer|importer|user_facility,
  fda_5day_request?, remedial_action?: {needed, aware_date?}, presumption?, draft_narrative?}`. It returns JSON, or
  streams Server-Sent Events with `Accept: text/event-stream`.
- Give `aware_date`: the first day any employee (sales, service, call centre) had the information. The received date is
  used only when it is missing. Paste the labeling's intended use and performance claims: the malfunction question is
  judged against them, and URLs are not fetched.
- `POST /mdr/decide` records the named person's decision; `POST /mdr/trend` groups complaints by failure mode (send the
  `failure_mode` each triage returns). `GET /mdr/info` lists every rule quoted with its citation, link and the date read.
- The server stores nothing. Keep the signed triage and decision records in the MDR event file (21 CFR 803.18). Anyone
  can re-check them with `POST /record/verify` against the key at `GET /attest/signing-key`.
- Keep the API on 127.0.0.1. For other users on the LAN, put a TLS reverse proxy with authentication in front and set
  `DECOSA_TRUSTED_PROXIES`.

## 6. Keep the direct route

`DECOSA_LLM_ROUTE=gateway` would send prompts to the hosted Decosa
API, and those prompts contain the complaint text. Never
use it for real complaints. At most, use it for public MAUDE narratives or synthetic training material.

Finish with a summary: what is running, the health output, the smoke-test results, and the reminders above.