Medical-grade data handling for authentication, generation, review, and institutional reporting.

This policy page is now written as a complete product page. It explains what data the Clinical Rounds workspace captures in the prototype and what the final application will protect once the interfaces move into the Next and Supabase implementation.

1. What we collect

Clinical Rounds may process account details, institution metadata, generator prompts, generated case artifacts, preview states, learner session records, analytics summaries, faculty review notes, and internal debug references. In the prototype layer these items are represented as interface structures; in the production application they will map to authenticated user records, case rows, version tables, and audit surfaces.

2. Why we collect it

The platform is designed to support diagnosis-focused learning. Data is collected to generate cases, preserve session continuity, review learner decisions, identify reasoning patterns, support institutional faculty workflows, and maintain operational visibility for deployment and debugging. We do not present this workspace as a public content feed; it is a controlled clinical learning environment.

3. Categories of protected workflow data

Identity and access data: email, role, institution, and sign-in path.
Generator input data: prompts, configuration choices, and preview states.
Learning and review data: case attempts, reasoning checkpoints, debrief notes, and faculty comments.
Operational data: timestamps, validation warnings, publish state, and internal debug traces when jobs are investigated.

4. Access, retention, and control

Institutional users should have visibility only into the workspaces, cohorts, and review views appropriate to their role. Once we move the prototype into the real application, retention periods, deletion workflows, and export controls should be enforced through authenticated services rather than static pages. Support or institutional administrators may request correction, export, or removal review for stored records in accordance with program requirements.

5. Security expectations

The final application is expected to protect this workflow with real authentication, role-based access, secured environment variables, server-side data access, and managed persistence. The current HTML prototypes are intentionally presentation-first. They define the product surface and information model, not the final security implementation.