Put the visit into your EHR as drafts

# Decosa "Put the visit into your EHR as drafts": use the hosted API (made-up patients only)

You are wiring Decosa's EHR-drafts check into this project. It takes a visit's output (diagnosis codes, lab and imaging
orders, medicine changes, the note, the transcript) and returns the review for a given EHR: which items an agent may
enter there as drafts, which go to a copy list in the EHR's field order (each value with its transcript line), and which
are held (a medicine whose dose, frequency, route or drug differs from the transcript, or a controlled substance). The
hosted API never touches an EHR: the agent itself runs in the clinician's own browser. Use only what is listed below. If
you need something else, stop and ask me.

- Base URL: `https://api.decosa.ai`
- Health check: `GET https://api.decosa.ai/healthz`.
- **Made-up patients only.** Chart data is protected health information; no business associate agreement is signed yet.
  Never send real patient information here.
- Nothing here signs, sends, transmits or e-prescribes, and nothing should be built that does.

## Auth: API key (or a demo session)
1. Preferred: an API key (`dk_…`) from "Get an API key" on the tool page, in `DECOSA_API_KEY`, sent as
   `Authorization: Bearer $DECOSA_API_KEY`.
2. Without a key: `POST https://api.decosa.ai/demo/session` with `{"vertical": "ehr-drafts"}` returns `{"token", "expires_at", "budget"}`.

## Endpoints
- `GET /ehr-drafts/info`: what it does and never does.
- `GET /ehr-drafts/gate`: per EHR, whether a tool may type in the clinician's session, whether a write API exists, and
  the route (`draft`, `api_or_copy`, `copy`).
- `GET /ehr-drafts/samples`: made-up visits in the input format `decosa.visit-drafts.v1`.
- `POST /ehr-drafts/check` (token). Body: `{"sample_id": "wrong-dose-planted", "ehr": "openemr"}` or
  `{"visit": {...}, "ehr": "therapynotes"}`. A visit: `patient {name, dob YYYY-MM-DD, mrn?}`, `encounter {date}`,
  `transcript [{n, role, text}]`, `items [{id, kind: problem|order|med_new|med_change|med_stop|note|follow_up, lines: [n],
  ...}]`. Answer: `{review: {headline, counts, items: [{id, kind, label, status, group: ready|check|yours, where, why, lines,
  source, flags}], copy: {title, note, items: [{label, value, cite, quote}]}, still_active, never, agent_may_type}, ehr,
  medcheck, receipt}`.
- `POST /ehr-drafts/ack` (token) `{panel: <review>, person: {name, role}}`: the clinician's signed acknowledgement of the
  review (not an EHR signature).

## Build
Show the review grouped: "check first" (held medicines, with the transcript line), "ready as drafts", "for you to enter"
(the copy list with a copy button per value). Show the headline verbatim. Keep the transcript line next to every value.

On request. The container images and the compose file aren’t public yet. Ask for self-host access and Decosa sends the registry (DECOSA_REGISTRY) and the compose file’s URL (DECOSA_COMPOSE_URL) these steps use. They are the steps we tested end to end on a fresh machine.

# Decosa "Put the visit into your EHR as drafts": self-host

You are setting up Decosa's EHR-drafts tool on this practice's own machine. Use only what is listed below. If something
is missing, stop and ask me.

What it is: decosa-api's `ehr-drafts` module (`decosa_api/verticals/ehrdrafts`) on the shared computer-use engine
(`decosa_api/cu`), the note-detail checker (a CPU model, `services/detail_checker`), and Qwen3.8-27B served by vLLM. The
agent drives a tab of the clinician's own browser (Chrome DevTools Protocol), types the visit's items into the open chart
as drafts, and stops before sign. It types only into EHRs whose terms allow a tool in the session (today: a self-hosted
OpenEMR); for other EHRs, use `POST /ehr-drafts/check` for the copy list.

1. Check the GPU (`nvidia-smi`; about 20 GB for Qwen3.8-27B NVFP4) and Docker with the NVIDIA container toolkit.
2. Serve the model with vLLM (image `vllm/vllm-openai@sha256:c2914767605584b6d8f45686b82de173ecc99e781897aa3d0a66dacd72c51ae1`)
   on `127.0.0.1:8114`, OpenAI-compatible.
3. Clone decosa-api (ask me for access), create a venv, `pip install -e '.[flight]'` and `playwright install chromium`.
4. Start the note-detail checker: `python services/detail_checker/server.py` on `127.0.0.1:8495` (CPU).
5. Start the API: `DECOSA_HOST=127.0.0.1 DECOSA_PORT=8445 DECOSA_LLM_ROUTE=direct DECOSA_DETAIL_URL=http://127.0.0.1:8495 python -m decosa_api`.
6. Smoke test: `GET /ehr-drafts/samples`, then `POST /ehr-drafts/check {"sample_id": "wrong-dose-planted", "ehr": "openemr"}`:
   the metformin item must be in the "check" group with the transcript line that says 1000 mg.
7. The agent: `decosa_api.verticals.ehrdrafts.runner.run_visit(visit, OpenEMR(<your OpenEMR URL>), chat, run, emit,
   surface=CDPSurface(<Chrome's DevTools endpoint>, <your OpenEMR URL>))` with the chart open in that tab. Read
   `runner.py` first: it checks the chart, the medicines, and releases each draft save once; sign, transmit, send and
   e-prescribe are held.
Never point it at an EHR whose terms forbid tools in the session, and never at real patients before your own review of
the rails on a test copy.

## 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,
   (no mock bundle is published for this tool yet, so use the synthetic sample from the smoke test below),
   show me what is in it, and run the rehearsal against the local API:
   the smoke test from the steps below, on that synthetic sample only.
   It sends the mock inputs to the local API and prints PASS or FAIL for each expected property. 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.