List alerts, or the episodes they were folded into

The dashboard view.

By default this is one row per breach, in v1's alert shape plus every nest alert field, inside v1's paginate envelope (items, totalItems, page, totalPages, …) with nest's nextCursor beside it. Page with v1's page and limit (a page may start at most 10000 rows in), or walk with cursor: pass nextCursor back verbatim. sort is v1's time-desc (the default) or time-asc; ids narrows to those patients. It works whether or not the tenant has episodicAlerts. Without project it is tenant-wide: a per-facility view must send project, which keeps only patients stamped with it.

?episodes=true answers with episodes instead, as {items, nextCursor}: one row per clinical event, which opens on the first breaching reading, absorbs the rest, and closes on recovery, on going stale, or by hand. That grain REQUIRES project. It defaults to the tenant's feedCodes (PATCH /api/tenant), every code when it lists none; alerts have no code default.

codes, since and acknowledged filter either grain. until, page and ids are alerts only: sending one with episodes=true is a 422, not a filter that silently did nothing. status reads ACTIVE/RESOLVED for alerts and OPEN/CLOSED for episodes.

Episodes are newest first by sort: openedAt, the default, or lastFiringAt, the newest firing reading (the opening, for an episode that has none). since and the cursor use the same time. openedAt never changes, so walking every page lists each episode once. On lastFiringAt an episode that fires mid-walk moves above the cursor: it is never listed twice, but that walk misses it. A sort value from the other grain is a 422.

Through ovok

• Who can call it: Manager apps, and users whose access policy grants the capabilities.
• Capabilities, all required: signals_alerts:read. Project admins have every capability; client applications get no admin bypass.
• ovok sets project to your project, so you can leave it out.
• If your access covers only some patients (anyone but project admins, manager or submitter apps, and anyone whose Patient access has no criteria), name them with patientId or ids, each one you can read, at most 100. Signals then pages over just those patients, so pages and totals stay true. A patient is named by its Signals id, or by its Medplum Patient id where Signals takes a refId; ovok asks Signals which patient a Signals id is.