> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nekt.com/llms.txt
> Use this file to discover all available pages before exploring further.
# TI Saúde as a data source
> Bring data from TI Saúde to Nekt.
TI Saúde is a Brazilian clinic management and electronic health record (EHR) platform. The connector extracts users, calendars, schedules, patients, procedures, and EHR data via the TI Saúde API.
## Configuring TI Saúde as a Source
In the [Sources](https://app.nekt.ai/sources) tab, click on the "Add source" button located on the top right of your screen. Then, select the TI Saúde option from the list of connectors.
Click **Next** and you'll be prompted to add your access.
### 1. Add account access
You'll need to provide your Ti.Saúde API credentials to access your TI Saúde data.
The following configurations are available:
* **User**: Username for logging into the Ti.Saúde API.
* **Password**: Password for the Ti.Saúde API.
* **Start Date**: Start date for the **schedules** stream (per calendar). Records are synced from this date up to today. If omitted, today is used. Other streams are not affected by this setting.
Once you're done, click **Next**.
### 2. Select streams
Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.
> Tip: The stream can be found more easily by typing its name.
Select the streams and click **Next**.
### 3. Configure data streams
Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
* **Layer**: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
* **Folder**: a folder can be created inside the selected layer to group all tables being created from this new data source.
* **Table name**: we suggest a name, but feel free to customize it. You have the option to add a **prefix** to all tables at once and make this process faster!
* **Sync Type**: you can choose between INCREMENTAL and FULL\_TABLE.
Once you are done configuring, click **Next**.
### 4. Configure data source
Describe your data source for easy identification within your organization, not exceeding 140 characters.
To define your [Trigger](https://docs.nekt.com/get-started/core-concepts/triggers), consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times).
Optionally, you can define some additional settings:
* Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource [here](https://docs.nekt.com/get-started/core-concepts/resource-control).
* Determine when to execute an **Additional [Full Sync](https://docs.nekt.com/get-started/core-concepts/types-of-sync#additional-full-sync)**. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
Once you are ready, click **Next** to finalize the setup.
### 5. Check your new source
You can view your new source on the [Sources](https://app.nekt.ai/sources) page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.
For you to be able to see it on your [Catalog](https://app.nekt.ai/catalog), you need at least one successful source run.
# Streams and Fields
Below you'll find all available data streams from TI Saúde and their corresponding fields. Streams such as **schedules** and **doctors** depend on parent streams (calendars, locals) and are synced per parent context.
Stream of system users (professionals and staff) from the Ti.Saúde API.
**Key Fields:**
* `id` - Unique identifier for the user
* `client` - Client ID
* `login` - Login username
* `name` - Full name
* `email` - Email address
* `cellphone` - Mobile number
* `cpf` - CPF
* `councilCode`, `councilNumber`, `councilStateUF` - Professional council (e.g. CRM, CRP)
* `specialties` - Array of specialty IDs and titles
* `profiles` - Array of profile IDs
* `idCalendar` - Associated calendar ID
* `address`, `city`, `state`, `zip` - Address fields
Stream of schedule calendars. Each calendar is used to generate (calendar, date) contexts for the **schedules** stream.
**Key Fields:**
* `id` - Unique identifier for the calendar
* `client` - Client ID
* `name` - Calendar name
* `idUser` - Owner user ID
* `flagSMS`, `flagWhatsapp` - Notification flags
* `defaultLocation` - Default location
* `deleted` - Whether the calendar is deleted
* `timestamp` - Last update timestamp
Stream of schedule slots and appointments, per calendar and date. Synced for each (calendar, date) from **Data inicial** to today.
**Key Fields:**
* `idCalendar`, `date` - Context (calendar ID and date)
* `id` - Slot or appointment ID
* `hour` - Time (e.g. 08:10, 09:30)
* `type` - empty slot or appointment
* `local` - Object with `id` and `name` (location)
* `patient` - Object with patient id, name, cellphone, email, dateOfBirth, etc.
* `procedure` - Procedure info and value
* `doctor` - Doctor/professional info
* `typeQuery` - Consultation type (e.g. TELECONSULTA)
Stream of locations/units (locais). Used as parent context for the **doctors** stream.
**Key Fields:**
* `id` - Unique identifier for the local
* `name` - Location name
* `address`, `number`, `neighborhood`, `city`, `state`, `zip` - Address
* `phone`, `phone2` - Phones
* `cnpj`, `cnes`, `cnae` - Registry codes
* `deleted` - Whether the local is deleted
* `timestamp` - Last update
Stream of doctors/professionals per local (parent: **locals**).
**Key Fields:**
* `local` - Local ID (context)
* `id` - Doctor/professional ID
* `idUser` - User ID
* `client` - Client ID
* Additional professional and schedule-related fields from the API
Catalog of procedures (procedimentos).
**Key Fields:**
* `id` - Unique identifier for the procedure
* `client` - Client ID
* Fields for procedure name, codes (e.g. TUSS), values, and related metadata as returned by the API
Stream of patients. Used as parent context for **ehr\_tabs** and **ehr\_fichas**.
**Key Fields:**
* `id` - Unique identifier for the patient
* `client` - Client ID
* Patient name, contact, birth date, document, health insurance, and other demographic/clinical fields as returned by the API
Stream of EHR (prontuário) tabs per patient (parent: **patients**).
**Key Fields:**
* `idPaciente` - Patient ID (context)
* `id` - Tab ID
* `name`, `tab`, `icon` - Tab identifier and display
* `type` - e.g. ehr
* `countDocuments` - Document count in the tab
Stream of EHR fichas (forms/records) per patient (parent: **patients**).
**Key Fields:**
* `idPaciente` - Patient ID (context)
* `id` - Record ID
* `name` - Model/record name
* `tab` - Tab (e.g. fichas)
* `date` - Service date
* `by`, `professionCard`, `council` - Responsible professional and council
* `healthInsurance`, `idHealthInsurancePlan` - Insurance
* `active`, `filledStatus`, `timestamp`, `signed` - Status and audit fields
* `editedFrom` - ID of record this was edited from
Stream of attachment/folder categories (pastas de anexo).
**Key Fields:**
* `id` - Category ID
* `cliente` - Client ID
* `name` - Folder/category name
* `idFather` - Parent folder ID (null = root)
* `level` - Hierarchy level
* `created_at`, `updated_at` - Timestamps
* `deleted`, `prontuario` - Flags
Lookup stream of medical specialties (especialidades).
**Key Fields:**
* `id` - Specialty ID
* `cbo` - CBO code
* `sigps` - SIGPS code
* `description` - Specialty description
* `descriptionApp` - Description shown in the app
Lookup stream of professional councils (conselhos, e.g. CRM, CRP, CRF).
**Key Fields:**
* `id` - Council ID
* `code` - Council code (e.g. CRM, CRP, CRF)
* `description` - Council description
Stream of access profiles (perfis de acesso) with module and permission flags.
**Key Fields:**
* `id` - Profile ID
* `cliente`, `area` - Client and area IDs
* `nome`, `descricao` - Name and description
* `adm`, `profissionaldesaude`, etc. - Role flags
* `modulo_agenda`, `modulo_prontuario`, `modulo_financeiro`, etc. - Module access (0 or 1)
* `agenda_*`, `prontuario_*`, `financeiro_*` - Granular permissions
* `timestamp`, `deletado` - Audit fields
# Data Model
The following diagram illustrates the main relationships between streams. Arrows indicate parent-child or logical links used during sync.
```mermaid theme={null}
erDiagram
calendars ||--o{ schedules : "idCalendar, date"
locals ||--o{ doctors : "local"
patients ||--o{ ehr_tabs : "idPaciente"
patients ||--o{ ehr_fichas : "idPaciente"
users }o--|| calendars : "idCalendar"
schedules }o--|| patients : "patient.id"
schedules }o--|| procedures : "procedure"
schedules }o--|| locals : "local.id"
doctors }o--|| users : "idUser"
calendars {
int id PK
string name
int idUser
}
schedules {
int idCalendar
string date
int id PK
string hour
object patient
object local
}
locals {
int id PK
string name
}
doctors {
int local
int id PK
int idUser
}
patients {
int id PK
}
ehr_tabs {
int idPaciente
int id PK
}
ehr_fichas {
int idPaciente
int id PK
}
```
# Implementation Notes
* **Schedules volume**: The **schedules** stream issues one request per calendar per day from **Data inicial** to today. Use **Data inicial** to limit the period and avoid large extractions.
* **Parent streams**: **schedules** depends on **calendars**; **doctors** depends on **locals**; **ehr\_tabs** and **ehr\_fichas** depend on **patients**. Ensure parent streams are selected when syncing these child streams.
* **Sync types**: Streams use FULL\_TABLE by default. Configure sync type per stream in the data stream configuration step.
## Skills for agents
TI Saúde connector documentation as plain markdown, for use in AI agent contexts.