GET /api/alerts fires up to 100 parallel patient reads and writes ~100 audit rows per request

[manjula25]

Summary

One GET /api/alerts request fires up to 100 parallel per-patient HAPI round trips and writes up to 100 success rows into the audit log — polluting the very governance trail it paginates.

Evidence

apps/api/src/alerts/service.ts:130-140:

await Promise.all(
  profiles.slice(0, 100).map(async (p) => {
    const patient = await fhirService.getPatient(actor, p.patientId); ...

Each getPatient is a full HAPI round trip and writes an audit row (client.ts:411). getPatientDemographics in the same file already demonstrates the batch Patient?_id=... pattern that avoids this.

Impact

• Up to 100 concurrent HTTP calls to HAPI per dashboard poll.
• ~100 audit rows per request injected into the governance trail (default page size 50 — a single alerts view generates two pages of noise).
• Patients beyond the silent slice(0, 100) cap lose their names with no indication to the caller.