An internal application for one multi-branch healthcare organisation. Teams need to coordinate registration, appointments, service queues, invoices, payments, and branch operations reporting without building a complete medical-record system.
This sample comes from an internal test run, not from your idea and not from customer work. Content was sanitised and public terminology aligned without adding new outcome claims.
An internal application for one multi-branch healthcare organisation. Teams need to coordinate registration, appointments, service queues, invoices, payments, and branch operations reporting without building a complete medical-record system.
Product context, actors, boundary, storage, and critical decisions are locked before structure generation.
The App Map and Structure Review Package are reviewed before final output is completed.
Separate facts, decisions, defaults, and open questions before the first approval.
The product is scoped as an internal tool for one multi-branch organisation, with server-derived branch scope and no complete medical record.
Branch teams manage registration, appointments, queues, service, invoices, and payment with auditable states. Central leadership reads aggregate reports without changing branch transactions.
Access derives from roles and server assignments. Laptops and phones use the same PWA workflow. Offline behaviour exists only on explicitly permitted surfaces.
OIDC configuration, conflict resolution, billing mapping, performance parameters, retention, and browser compatibility remain release gates—not facts invented by the AI.
Explain work sequence, handoffs, terminal states, guards, and recovery across actors.
Registration → Appointment → Queue → Service → Invoice → Payment, with lifecycle guards and completion authority at each handoff.
Registration staff find or create the patient, schedule an appointment, and place the patient in the clinic queue. Once service is completed and guards pass, an invoice becomes available for payment.
Registration and queue changes can enter a durable outbox. On reconnect, replay revalidates session, assignment, expected version, and current authority before commit.
Downtime uses manual capture followed by auditable re-entry. Restore, replay, and reconciliation must not duplicate transactions or erase audit evidence.
Turn operational requirements into architecture, authority, offline, observability, and recovery boundaries.
React/TypeScript PWA, modular NestJS API, and PostgreSQL authority; workers, caches, and IndexedDB remain non-authoritative.
One responsive private PWA calls a versioned REST API. A modular monolith keeps lifecycle and authorisation in one boundary until measured scale justifies service separation.
Workers perform non-authoritative tasks such as notification delivery and reconciliation. IndexedDB holds bounded snapshots and outbox items; every business outcome commits to PostgreSQL.
Append-only audit, correlation IDs, observability, backups, restore drills, and recovery targets must be proven before release. The sample records RPO ≤5 minutes and RTO ≤60 minutes as targets still requiring validation.
Define data authority, relations, constraints, lifecycle, audit, and idempotency for a product that needs persistence.
The schema models identity, end-to-end operations, ordered billing, conflicts, outbox, notifications, reconciliation, audit, and recovery.
Organisation is the highest boundary and transactions carry branch scope. Assignments connect users to operational authority; every query and command validates scope server-side.
Statuses use constraints that can evolve through controlled migrations. Version and idempotency prevent duplicate replay; foreign keys and uniqueness preserve authority relations.
The schema is a reviewable baseline, while indexes, volume, retention, conflict resolution, billing mapping, and scope-isolation tests still require proof before production.
Map product areas, capabilities, actors, and journey responsibilities without pretending to be a screen or route list.
Branch Operations, Services, Billing, Reporting, Reconciliation, and Audit own distinct capabilities and journey responsibilities.
Branch Operations owns registration, appointments, and queues. Services manages service state. Billing governs invoice and payment. Reporting, Reconciliation, and Audit provide separate supporting surfaces.
Registration hands off to Appointment and Queue; Service changes invoice eligibility; Billing sends outcomes to reporting and reconciliation. Audit receives cross-area events without becoming transaction authority.
The App Map is reviewed with the Application Journey, Technical Foundation, and relevant Database Schema. The second approval locks the structure package rather than approving each document separately.
Keep product requirements, the MVP boundary, exclusions, risks, and acceptance criteria in one canonical document.
The MVP includes registration through payment, bounded offline operation, reports, audit, and recovery while keeping release gates visible.
The MVP helps branch staff run patient operations and helps management read scoped reports without replacing medical records or clinical decisions.
The boundary covers registration, appointments, queues, service, invoice, payment, reports, in-app notifications, audit, and recovery described by the connected artifacts.
Each requirement names authority, actor, guard, failure state, and test evidence. OIDC, conflict resolution, billing mapping, retention, performance, and browser/storage remain open release gates.
If the offline decision changes from ‘registration and queues’ to ‘registration only’, the revision flow marks Application Journey, Technical Foundation, Database Schema, and PRD as affected. Healthy areas do not need an end-to-end rerun.
This is sanitised AI working material reviewed for demonstration. Technical, legal, security, medical, and operational details still require human review and appropriate testing.
Create your Blueprint