Módulo 12 · Administración

Última actualización: 14 de noviembre de 2026.

Documento funcional para validación con usuarios. Se presentan comportamientos esperados y reglas en lenguaje claro, sin códigos de trazabilidad técnica.

Contexto funcional vigente

• El MVP se desarrolla en plataforma web. Salud 365 presenta la experiencia del usuario y coordina las operaciones; Elite Global Doctors (EGD) es el core clínico. Las capacidades concretas de sus servicios e interfaces aún requieren validación técnica.

• El titular que contrata y paga puede ser distinto del paciente; los pacientes dependientes deben estar vinculados y autorizados. Los usuarios, pacientes y médicos requieren registro y correspondencia de identidad entre Salud 365 y EGD.

Descripción funcional y procesos

Objetivo y alcance

Definir las funciones esenciales del perfil ADMINISTRADOR en Salud 365 para gestionar usuarios, médicos, catálogos, parámetros operativos, citas, incidencias, conciliaciones, reportes y auditoría. El módulo corresponde al backoffice de Salud 365; no reemplaza la gestión clínica de EGD ni habilita edición indiscriminada de historias clínicas.

• Confirmado: el ADMINISTRADOR se crea internamente por personal autorizado; no existe autorregistro público para este perfil.

• Confirmado: el alta y validación profesional de MEDICOS se realiza internamente mediante el ADMINISTRADOR.

• Confirmado: usuarios, pacientes y médicos deben registrarse en Salud 365 y EGD, con mapeo de identificadores y sincronización.

• Confirmado: EGD es el sistema clínico principal y el médico opera desde su plataforma. Salud 365 conserva los datos y estados acordados, y presenta al titular/paciente su experiencia autorizada.

• Confirmado: Izipay gestiona pagos antes del agendamiento; las devoluciones excepcionales se tramitan fuera de la aplicación.

• Confirmado: el TITULAR consulta los datos de atención y recetas aprobados de pacientes asociados autorizados, incluidos dependientes adultos conforme a las reglas de representación. No dispone de lectura clínica completa por el solo vínculo o pago.

Flujo administrativo de referencia

1. El ADMINISTRADOR inicia sesión y Salud 365 valida su rol y permisos.

2. Accede a un panel de operación con módulos habilitados según su perfil.

3. Consulta usuarios, pacientes, médicos, citas, pagos e incidencias conforme a permisos.

4. Ejecuta altas, actualizaciones, suspensiones o cambios de configuración autorizados.

5. Salud 365 valida los cambios y sincroniza con EGD cuando corresponda.

6. Ante fallos, registra el estado, permite reintentos controlados y deriva incidencias.

7. Consulta reportes y bitácoras para seguimiento, sin exponer información clínica innecesaria.

RF-12-001 · Acceso al backoffice y permisos administrativos

Objetivo: Permitir el ingreso seguro al panel administrativo según rol y permisos.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: El ADMINISTRADOR inicia sesión; Salud 365 valida credenciales y muestra exclusivamente las funciones autorizadas.

Ejemplo práctico: Un operador de soporte puede consultar incidencias, pero no necesariamente modificar médicos o parámetros de seguridad.

Diferencia respecto de otros requerimientos: Este requisito controla el acceso general; controla auditoría de acciones.

Validaciones y reglas: Aplicar mínimo privilegio, cierre de sesión y control de acciones críticas.

Alternativas y excepciones: Acceso denegado o sesión expirada: no revelar datos ni permitir acciones.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: El usuario sin permiso no puede visualizar ni ejecutar funciones restringidas.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-002 · Gestión administrativa de usuarios TITULARES

Objetivo: Consultar, actualizar datos administrativos permitidos y gestionar el estado de cuentas de TITULARES.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: Buscar usuario por criterios autorizados; revisar estado de sincronización y ejecutar actualización o inactivación permitida.

Ejemplo práctico: Un TITULAR reporta datos de contacto incorrectos y soporte corrige un campo autorizado.

Diferencia respecto de otros requerimientos: No sustituye el autorregistro ni la recuperación de contraseña del Módulo 01.

Validaciones y reglas: No modificar datos clínicos desde el perfil de usuario; mantener identidad y vínculo con EGD.

Alternativas y excepciones: Conflicto o fallo de sincronización: conservar incidencia y no declarar éxito sin confirmación.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: Los cambios autorizados quedan registrados y se reflejan según reglas de sincronización.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-003 · Alta y validación administrativa de MEDICOS

Objetivo: Registrar, verificar y habilitar médicos para la operación de Salud 365.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: El ADMINISTRADOR captura datos profesionales, revisa evidencias y registra o sincroniza el médico con EGD; habilita acceso tras validación.

Ejemplo práctico: Un médico nuevo es registrado internamente y permanece inactivo hasta completar su verificación.

Diferencia respecto de otros requerimientos: Desarrolla la gestión administrativa del y; no implica autorregistro médico.

Validaciones y reglas: No habilitar al médico antes de las verificaciones exigidas y del mapeo de identidad EGD.

Alternativas y excepciones: EGD rechaza el alta: mantener pendiente, registrar error y evitar habilitación inconsistente.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: El médico habilitado cuenta con identificador y estado coherentes entre plataformas.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-004 · Actualización, suspensión e inactivación de médicos

Objetivo: Permitir cambios controlados del perfil profesional y de su habilitación operativa.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: El ADMINISTRADOR consulta al médico, modifica campos permitidos o solicita suspensión; Salud 365 evalúa citas futuras y sincroniza.

Ejemplo práctico: Se suspende temporalmente a un médico y se identifican citas futuras que requieren gestión.

Diferencia respecto de otros requerimientos: Complementa el alta y la gestión del Módulo 03.

Validaciones y reglas: No eliminar historiales ni desasociar citas clínicas por inactivación administrativa.

Alternativas y excepciones: Citas afectadas: generar incidencia o flujo de reasignación según política aprobada.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: El médico suspendido no recibe nuevas asignaciones según reglas definidas.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-005 · Gestión de catálogos de servicios y especialidades

Objetivo: Mantener parámetros comerciales y funcionales utilizados para ofrecer servicios.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: El ADMINISTRADOR consulta los servicios y especialidades, gestiona visibilidad y parámetros comerciales autorizados en Salud 365, y conserva su correspondencia con EGD. La gestión del dato maestro profesional se realiza según la responsabilidad acordada con EGD.

Ejemplo práctico: Se habilita una especialidad en Salud 365 solo cuando existe correspondencia válida con EGD.

Diferencia respecto de otros requerimientos: Gestiona la oferta visible; define parámetros operativos y tarifas.

Validaciones y reglas: Evitar ofrecer servicios sin integración o disponibilidad confirmada; conservar historial de cambios.

Alternativas y excepciones: Catálogo EGD no disponible: impedir publicación inconsistente y notificar incidencia.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: El catálogo publicado tiene identificadores y estado de vigencia controlados.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-006 · Configuración operativa y parámetros comerciales

Objetivo: Administrar parámetros no clínicos del MVP sin modificar código.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: El ADMINISTRADOR autorizado consulta y actualiza los parámetros aprobados, como contactos de servicio, textos operativos y tarifas si están habilitadas. Los valores del código no constituyen por sí solos límites o condiciones definitivos.

Ejemplo práctico: Se actualiza el número de contacto UME que Salud 365 mostrará al TITULAR.

Diferencia respecto de otros requerimientos: Es configuración; gestiona catálogos y monitorea citas.

Validaciones y reglas: Aplicar validación, control de cambios, vigencia y aprobación para parámetros sensibles.

Alternativas y excepciones: Valor inválido o no aprobado: mantener versión vigente y rechazar publicación.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: Los parámetros autorizados se aplican y los cambios quedan auditados.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-007 · Supervisión de citas y agendamiento

Objetivo: Consultar estado de solicitudes y citas para resolver incidencias operativas.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: Filtrar por paciente, fecha, modalidad, médico y estado; ver correlación Salud 365–EGD y acciones autorizadas.

Ejemplo práctico: Se detecta una cita pagada que todavía no fue confirmada en EGD.

Diferencia respecto de otros requerimientos: La creación y reagendamiento pertenecen al Módulo 04; aquí se supervisa su ejecución.

Validaciones y reglas: No cambiar manualmente el estado clínico ni marcar confirmación sin respuesta confiable de EGD. El administrador no registra diagnósticos, recetas, conclusiones ni cierres clínicos.

Alternativas y excepciones: Estado incierto o cita duplicada: derivar a conciliación con trazabilidad.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: El administrador identifica citas pendientes y su motivo sin alterar registros clínicos.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-008 · Supervisión de pagos e incidencias económicas

Objetivo: Consultar transacciones Izipay y su relación con solicitudes y citas.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: Buscar transacciones, contrastar confirmaciones y registrar seguimiento de pagos sin cita o resultados inciertos.

Ejemplo práctico: Un pago aprobado sin disponibilidad médica se muestra como incidencia asociada a la solicitud.

Diferencia respecto de otros requerimientos: No procesa cobros nuevos ni devoluciones automáticas; esos flujos se definen en Módulo 11.

Validaciones y reglas: No almacenar datos completos de tarjetas; no cambiar estados de pago sin evidencia confiable.

Alternativas y excepciones: Diferencia Izipay–Salud 365: enviar a conciliación y preservar comprobantes técnicos.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: Se identifica cada pago y su estado de asociación con una cita.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-009 · Bandeja de incidencias, reintentos y conciliación

Objetivo: Gestionar errores de integración entre Salud 365, EGD e Izipay.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: Registrar incidente con correlación, tipo, prioridad y estado; consultar resultado remoto antes de reintentar operaciones idempotentes.

Ejemplo práctico: EGD crea una cita, pero Salud 365 recibe timeout; el operador verifica antes de reintentar.

Diferencia respecto de otros requerimientos: Es gestión de excepciones transversal; y 008 muestran datos específicos.

Validaciones y reglas: No repetir operaciones inciertas sin verificación; evitar duplicados y exponer datos sensibles.

Alternativas y excepciones: Error persistente: escalar con responsable, evidencia mínima y estado pendiente.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: La incidencia puede seguirse desde detección hasta resolución auditada.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-010 · Reportes operativos e indicadores

Objetivo: Consultar indicadores básicos de operación y exportaciones autorizadas.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: Seleccionar rango de fechas y generar resumen de usuarios, médicos, citas, modalidades, estados, pagos e incidencias.

Ejemplo práctico: Administración revisa citas confirmadas frente a pagos aprobados del día.

Diferencia respecto de otros requerimientos: Presenta información agregada; gestiona consultas operativas detalladas.

Validaciones y reglas: Evitar exponer historias clínicas en reportes administrativos; controlar permisos de exportación.

Alternativas y excepciones: Datos incompletos o retrasados: mostrar fecha de actualización y advertencia.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: Los totales pueden contrastarse con registros de origen y filtros aplicados.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-011 · Consulta administrativa de registros y asociaciones

Objetivo: Localizar registros de usuarios, pacientes, médicos y vínculos sin habilitar edición clínica.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: Buscar entidad, consultar identificadores locales y EGD, relaciones de paciente asociado y estados de sincronización.

Ejemplo práctico: Un paciente aparece duplicado y soporte compara sus identificadores sin consultar notas médicas.

Diferencia respecto de otros requerimientos: Es una consulta transversal de identidad; permiten cambios autorizados.

Validaciones y reglas: Restringir acceso por rol; no modificar el vínculo de pacientes sin validaciones y auditoría.

Alternativas y excepciones: Identificadores inconsistentes: crear incidencia de datos y bloquear acciones riesgosas.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: La consulta muestra correspondencias de identificadores y vínculos autorizados.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-012 · Auditoría, seguridad y trazabilidad administrativa

Objetivo: Registrar acciones críticas, accesos y cambios de configuración para control y revisión.

Actores: ADMINISTRADOR, Salud 365; EGD o Izipay cuando corresponda.

Precondiciones: Administrador autenticado y autorizado; integración o configuración disponible para la operación.

Flujo principal: Por cada acción registrar usuario, fecha, operación, entidad, resultado e identificador de correlación; permitir consulta restringida de bitácoras.

Ejemplo práctico: Se identifica quién suspendió a un médico y cuándo ocurrió el cambio.

Diferencia respecto de otros requerimientos: Es control transversal de todas las funciones administrativas.

Validaciones y reglas: No guardar contraseñas, tokens ni contenido clínico sensible en logs; proteger integridad y retención.

Alternativas y excepciones: Falla de auditoría crítica: bloquear o escalar la operación según política de seguridad aprobada.

Integraciones y datos: Salud 365, EGD, Izipay y bitácora según la operación; identificadores, estados, marcas de tiempo y correlación.

Criterios de aceptación: Las acciones críticas tienen trazabilidad consultable por usuarios autorizados.

Esta versión es una propuesta de alcance esencial de Administración para el MVP. Deben validarse el catálogo de operaciones, la matriz de permisos, la responsabilidad sobre cada dato maestro, las APIs EGD/Izipay, los controles de seguridad y los criterios de operación. No se consideran confirmadas las capacidades técnicas aún no demostradas por los proveedores.

Referencias de trazabilidad: FL por vincular | INT por vincular | API/Checklist EGD por verificar.

RF-12-013 · Configuración del origen de datos del sistema

Objetivo:

Permitir que el ADMINISTRADOR configure el origen de consulta conforme al alcance que se apruebe, manteniendo como base la selección descrita entre EGD y Salud 365, sin afectar usuarios, autenticación, roles y permisos. La configuración de lectura no concede edición médica propia ni amplía el alcance visible del titular/paciente.

Actores:

ADMINISTRADOR, Salud 365 y EGD.

Precondiciones:

El ADMINISTRADOR tiene una sesión activa en Salud 365.

El usuario cuenta con permisos para modificar la configuración general del sistema.

Salud 365 dispone de mecanismos de consulta para el origen de datos seleccionado.

Existe una configuración vigente del origen de datos.

Flujo principal:

1. El ADMINISTRADOR ingresa al módulo de Administración.

2. Selecciona la opción «Configuración del sistema».

3. Accede a la sección «Origen de datos».

4. Salud 365 muestra el origen de datos actualmente configurado.

5. El ADMINISTRADOR selecciona una de las siguientes opciones:

   • EGD: La información funcional y clínica se consultará mediante los servicios de EGD.
   • Salud 365: La información funcional y clínica se consultará desde los servicios y repositorios propios de Salud 365.

6. Salud 365 muestra una descripción del comportamiento correspondiente a la opción seleccionada.

7. El ADMINISTRADOR confirma el cambio.

8. El sistema valida que el origen seleccionado se encuentre habilitado y que sus parámetros técnicos estén configurados.

9. Salud 365 registra la configuración y conserva el historial de modificaciones.

10. Las nuevas consultas funcionales utilizan el origen de datos seleccionado, según las reglas definidas para cada módulo.

11. Salud 365 muestra un mensaje de confirmación de la actualización.

Comportamiento según el origen configurado:

A. Origen de datos EGD

Cuando EGD se encuentra activo:

Los usuarios continúan registrándose y autenticándose exclusivamente en Salud 365.

Los roles y permisos siguen administrándose en Salud 365.

Los pacientes se registran inicialmente en Salud 365.

Se habilita el proceso de sincronización asíncrona de pacientes con EGD, conforme a la integración definida.

La información de pacientes, médicos, especialidades y disponibilidad se consulta desde EGD.

Los estados del acto médico y de la videoconsulta se consultan desde EGD.

Las consultas históricas, diagnósticos, observaciones clínicas y recetas se obtienen desde EGD.

Salud 365 presenta la información recibida respetando los permisos por paciente y el alcance aprobado de datos de atención y recetas para el usuario.

B. Origen de datos Salud 365

Cuando Salud 365 se encuentra activo:

Los usuarios se registran y autentican en Salud 365.

Los roles y permisos se administran en Salud 365.

Los pacientes se registran y gestionan en Salud 365.

No se requiere ejecutar la sincronización de pacientes hacia EGD.

La información de pacientes, médicos, especialidades y disponibilidad se consulta desde Salud 365.

Los estados del acto médico y de la videoconsulta se consultan desde los servicios propios de Salud 365.

Las consultas históricas, diagnósticos, observaciones clínicas y recetas se obtienen desde Salud 365.

No se realizarán consultas a EGD para las funcionalidades cubiertas por esta configuración.

Validaciones y reglas de negocio:

Solo el ADMINISTRADOR autorizado podrá consultar y modificar la configuración del origen de datos.

El sistema deberá mantener un único origen de datos activo para las funcionalidades contempladas en este requerimiento, salvo que posteriormente se apruebe una configuración independiente por módulo.

La configuración del origen de datos no modificará el mecanismo de autenticación de usuarios.

La creación de usuarios, administración de roles y control de acceso siempre serán responsabilidad de Salud 365.

El registro inicial de pacientes siempre se realizará en Salud 365.

Cuando EGD esté activo, la sincronización de pacientes deberá ejecutarse de forma asíncrona, sin bloquear el registro inicial.

La sincronización deberá contar con estados de seguimiento, registro de errores y mecanismos de reintento controlados.

La falta de sincronización previa de un paciente no impedirá su registro ni la utilización de sus datos disponibles en Salud 365.

Las consultas de información funcional y clínica deberán utilizar el origen configurado.

No se deberá cambiar automáticamente de EGD a Salud 365 ante errores de consulta, salvo que exista una regla de contingencia expresamente aprobada.

Las consultas de información clínica respetan permisos, representación y alcance visible aprobado. Conservar un dato clínico no autoriza presentarlo al titular/paciente.

El sistema deberá registrar los cambios de configuración, incluyendo usuario responsable, fecha, hora, origen anterior y nuevo origen.

No se permitirá activar un origen cuyos servicios requeridos no se encuentren configurados y habilitados.

Los cambios de origen no deberán modificar ni eliminar información histórica existente.

Los identificadores propios de Salud 365 y EGD deberán mantenerse diferenciados y relacionados cuando corresponda.

Las operaciones de creación, actualización y consulta deberán aplicar las reglas del origen activo, evitando duplicaciones e inconsistencias.

Alternativas y excepciones:

EGD no disponible: Salud 365 informará que la información solicitada no puede recuperarse temporalmente y registrará la incidencia correspondiente.

Paciente pendiente de sincronización: El paciente permanecerá registrado en Salud 365 y continuará su proceso asíncrono de sincronización con EGD.

Error durante la sincronización: El sistema registrará el error y permitirá ejecutar los reintentos definidos.

Datos no encontrados en EGD: Salud 365 identificará la ausencia de información y aplicará el tratamiento funcional aprobado, sin asumir que el paciente no existe en Salud 365.

Origen no configurado: El sistema impedirá activar una configuración incompleta.

Error al guardar la configuración: Se conservará el origen previamente activo.

Administrador sin permisos: Se denegará el acceso a la configuración.

Cambio de origen con operaciones en curso: El sistema deberá preservar la trazabilidad de las operaciones iniciadas y evitar que se procesen parcialmente con distintos orígenes.

Integraciones y datos:

Módulo 01 – Acceso: Gestión local de usuarios, autenticación, roles y permisos.

Módulo 02 – Pacientes: Registro local y sincronización asíncrona con EGD cuando corresponda.

Módulo 03 – Médicos: Consulta de información de médicos y especialidades.

Módulo 04 – Citas: Consulta de disponibilidad, citas y estados según el origen configurado.

Módulo 05 – Videoconsulta: Consulta de estados de videoconsulta.

Módulos clínicos: Consulta de historia clínica, diagnósticos, observaciones y recetas.

Módulo de Administración: Gestión y auditoría de la configuración.

EGD: Servicios de consulta y sincronización cuando se encuentre activo.

Salud 365: Servicios propios de consulta, almacenamiento y gestión de datos.

Criterios de aceptación:

El ADMINISTRADOR puede visualizar el origen de datos actualmente activo.

El sistema permite seleccionar EGD o Salud 365.

El cambio de configuración requiere confirmación.

La autenticación y administración de roles permanece exclusivamente en Salud 365.

Los pacientes siempre se registran inicialmente en Salud 365.

Cuando EGD está activo, se inicia el proceso de sincronización asíncrona correspondiente.

Cuando Salud 365 está activo, las consultas utilizan sus propios servicios.

Las consultas de médicos, pacientes, especialidades, disponibilidad y datos clínicos utilizan el origen seleccionado.

Los cambios de configuración quedan registrados para auditoría.

Los errores de sincronización o consulta se registran sin modificar automáticamente el origen activo.

El sistema conserva la trazabilidad de las operaciones iniciadas antes de un cambio de configuración.

La información clínica se presenta respetando permisos y autorizaciones y manteniendo los datos de atención y recetas aprobados para el usuario, sin diagnósticos, conclusiones ni otros campos excluidos.

---

Descargar Markdown original