A well-defined scope is the boundary between a focused, deliverable product and an open-ended initiative that never ships. This document records the agreed scope of the SSA Health Platform as determined during the product discovery phase — what the system will do, what it will manage, where it will deploy, and what it will deliberately not do in its first version. Every feature listed here was validated against the platform’s core objective: publish reliable information. Features that do not serve that objective were deferred or excluded. Teams working on architecture, domain modelling, or implementation must treat this document as a hard constraint — expanding scope requires a formal architectural decision, not an informal agreement.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/LMendoza70/SSA/llms.txt
Use this file to discover all available pages before exploring further.
In Scope — Core Features
Content Management System (CMS)
Full lifecycle management of all institutional content types: News, Diseases, Campaigns, Programs, Events, Announcements (Comunicados), Notices (Avisos), Infographics, Documents, FAQs, and Institutional Information. Includes rich-text editing via Tiptap, content versioning, publication scheduling, and workflow controls.
Multimedia Management
A centralized media library for all digital assets used across the platform. Manages images, videos, PDFs, and audio files. Supports upload, organization, tagging, and reuse of assets across multiple content items.
Historical Timeline
A structured chronological record of institutional events, campaigns, and health milestones. Allows the population to explore the jurisdiction’s public health history and provides institutional memory for researchers and authorities.
AI Chatbot (RAG)
A conversational assistant powered by Retrieval-Augmented Generation (RAG). The chatbot answers health questions by retrieving relevant content from the platform’s own knowledge base and passing it to an external LLM. The platform never trains its own AI model.
Social Media Publishing
Integrated publishing of platform content to external social media channels. Supports scheduled publication, republication of existing content, and multi-channel distribution — all originating from the CMS as the single source of truth.
Authentication & Authorization
Secure role-based access control for all internal users. Authentication via JWT with refresh tokens and Argon2 password hashing. Roles include Content Administrator, Multimedia Manager, System Administrator, and Social Media Publisher.
Site Administration
Platform-level configuration managed by the System Administrator: global settings, navigation menus, banners, user management, role assignment, and a full audit log for all content and configuration changes.
Search & SEO
Full-text search across all published content types. Structured metadata and SEO-optimized output for all public-facing pages, ensuring institutional content is discoverable through external search engines.
Content Types
The CMS manages the following content types. All derive from a commonContent domain abstraction, ensuring consistency in lifecycle management, metadata, versioning, and publication rules.
| Content Type | Description |
|---|---|
| News (Noticias) | Current health news and updates from the jurisdiction |
| Diseases (Enfermedades) | Structured disease guides: symptoms, prevention, treatment |
| Campaigns (Campañas) | Health promotion and prevention campaigns |
| Programs (Programas) | Institutional health programs and their documentation |
| Events (Eventos) | Public health events, workshops, and vaccination days |
| Announcements (Comunicados) | Official institutional press releases and formal notices |
| Notices (Avisos) | Short operational notices to the public |
| Infographics (Infografías) | Visual health education materials |
| Documents (Documentos) | Official documents, protocols, and downloadable resources |
| FAQs (Preguntas Frecuentes) | Frequently asked questions with official answers |
| Institutional Information | About the jurisdiction, its mission, services, and contact details |
Deployment Targets
The platform is designed to be Cloud Ready from day one. Deployment targets are organized by project phase. During active development:- Render — backend API and background services
- Railway — database and auxiliary services
- Vercel — frontend deployment
- Institutional server — on-premises deployment within the jurisdiction’s own infrastructure
- AWS — Amazon Web Services cloud deployment
- Azure — Microsoft Azure cloud deployment
- Google Cloud — Google Cloud Platform deployment
What Is Out of Scope (v1)
The following capabilities were considered during product discovery and explicitly deferred from the first version. They are not rejected permanently — they are candidates for future phases once the core platform is stable and the domain is well understood.Excluding a feature from v1 does not mean the architecture should ignore it. The platform’s design must not create barriers to adding these capabilities in the future.
| Excluded Feature | Reason for Deferral |
|---|---|
| Microservices architecture | The first version will be a Modular Monolith. Microservices introduce operational complexity that is premature before the domain is fully understood. The modular design allows extraction of services in future phases without rewriting the core. |
| Native mobile applications | The public-facing web experience is the priority. Mobile access is served through a responsive web interface. Native iOS and Android apps are a future consideration, not a v1 requirement. |
| Custom AI model training | The chatbot uses an external LLM via RAG. Training a custom model requires a volume of institutional data and ML infrastructure that is beyond the current project scope. The RAG approach delivers most of the value without that complexity. |
| E-commerce or billing features | The platform is a public health information service. No commercial transactions, subscriptions, or payment processing are required or planned. |