TheDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/KevxxAlva/femesalud-zen-flow/llms.txt
Use this file to discover all available pages before exploring further.
patients table is the central entity of the FemeSalud schema. Every appointment, consultation, clinical note, and lab result is ultimately anchored to a patient row. In addition to standard demographic fields, the table stores rich clinical background as structured JSONB columns — covering family history, personal history, gynecological data, and obstetric data — so that the complete medical profile is co-located with the patient record rather than distributed across auxiliary tables.
Patient Status
A patient’s lifecycle in the system is tracked through thestatus field using the following enumerated string type:
| Value | Meaning |
|---|---|
nuevo | Newly registered; no completed consultation yet. |
activo | Active patient currently receiving care. |
en_tratamiento | Patient currently undergoing a treatment programme. |
alta | Patient has been discharged. |
Core Fields
Primary key. Auto-generated UUID assigned on insert.
Patient’s full legal name. Must be non-empty. Uniqueness is enforced at the application layer using a case-insensitive (
ilike) check before insert or update to prevent duplicate registrations.National identity document — cédula or passport number. Must be unique across all patient rows. A uniqueness check is performed at the application layer before every insert or update.
Medical record number auto-generated by the system when a new patient is created. Provides a human-readable identifier for paper-based cross-referencing.
Patient’s email address. Nullable. Used for contact and notification purposes.
Patient’s phone number. Nullable.
ISO 8601 date string (
YYYY-MM-DD). Nullable. Used to calculate the patient’s age throughout the UI.Patient’s residential address. Nullable.
City or region where the patient was born. Nullable.
Patient’s marital status (e.g.
soltera, casada, divorciada, viuda, unión libre). Nullable free-text field.Highest educational level attained. Nullable free-text field.
Patient’s occupation or profession. Nullable.
Patient’s self-reported ethnicity. Nullable.
Patient lifecycle status. Defaults to
nuevo on insert. Accepted values: activo | en_tratamiento | alta | nuevo.Foreign key to
profiles.id. Identifies the responsible physician. Drives Row Level Security — doctors can only read patients where this value matches their own user ID.General free-text notes not tied to a specific consultation. Nullable.
Primary reason the patient first sought care. Nullable.
Narrative description of the patient’s current illness at the time of registration. Nullable.
ISO 8601 date string (
YYYY-MM-DD) recording when the patient first attended the clinic. Nullable.JSONB History Fields
Structured object capturing hereditary conditions reported for immediate relatives. All sub-fields are nullable strings.
Structured object for the patient’s personal background. All sub-fields are nullable strings.
Structured gynecological history. Numeric values such as
menarche may be stored as either a number or a string depending on the form input.Structured obstetric formula and pregnancy-related data. All numeric sub-fields may be stored as number or string.
Audit Fields
ISO 8601 timestamp with time zone. Set automatically by the database on insert.
ISO 8601 timestamp with time zone. Updated automatically on every row modification.
Foreign key to
auth.users.id. Records which authenticated user created the patient record. Nullable — may be null for records seeded outside the application.Uniqueness Constraints
| Field | Enforcement level | Behaviour on conflict |
|---|---|---|
id | Database (PK) | Insert rejected by PostgreSQL. |
document_id | Application layer | useCreatePatient and useUpdatePatient perform an eq query before writing; an error is thrown to the caller if a match is found. |
full_name | Application layer | Checked case-insensitively (ilike) before insert or update; an error is thrown on conflict. |
document_id uniqueness is enforced at the application layer rather than with a database UNIQUE constraint because the field is nullable — some patients may not have a document number recorded at registration.