Nota de Política de Soporte
Se brinda soporte para la versión actual y hasta dos releases anteriores.
Resumen Ejecutivo
Esta versión presenta avances significativos en la gestión operativa y clínica del sistema:
- Gestión de Referencias: Se incorporó la posibilidad de asignar un gestor responsable a las solicitudes, permitiendo un seguimiento personalizado y mejorando la trazabilidad en los dashboards de Gestión de Accesos y Turnos.
- Interconsultas: Se optimizó el flujo de cierre clínico mediante la finalización o anulación automática de interconsultas al registrar la epicrisis o el alta. Además, se sumaron filtros avanzados en el buzón de interconsultas recibidas.
- Enfermería en Guardia: Se habilitó la solapa de Enfermería para episodios de Guardia, permitiendo a los enfermeros administrar tomas con el mismo nivel de detalle que en Internación.
- Consulta Ambulatoria: Se habilitó la carga de archivos adjuntos durante la consulta y se incorporó una validación configurable para asegurar el registro de motivo o problema de salud.
- Seguridad y MPI: Se reforzó la seguridad en la descarga de documentos y se establecieron nuevos campos obligatorios (domicilio y cobertura) en el empadronamiento para facilitar el recupero de costos.
Nota importante sobre feature flags
⚠️ Todos los feature flags en cuyo nombre figure “EN_DESARROLLO” no deben configurarse en true en ambientes productivos.
| Feature Flag | Funcionalidad Asociada |
|---|---|
| HABILITAR_INTERCONSULTA | Gestión completa de interconsultas, cierre automático y filtros en buzón. |
| HABILITAR_OBLIG_MOTIVO_O_PROBLEMA_CONSULTA_AMBULATORIA | Obligatoriedad de completar motivo o problema para confirmar consulta ambulatoria. |
| HABILITAR_EDICION_CONSULTA_AMBULATORIA | Permite adjuntar y gestionar documentos en la edición de consultas. |
| HABILITAR_ALTA_SIN_EPICRISIS | Permite realizar el alta médica de internación sin requerir epicrisis previa. |
| HABILITAR_LIMITAR_AGENDAS_A_ROLES_DE_SALUD_POR_UJ | Restringe la visibilidad de agendas a los profesionales según su asociación a UJs. |
| HABILITAR_MODULO_INTERNACION | Requerido para la administración y visualización de tomas de Enfermería en episodios de Internación. |
| HABILITAR_MODULO_GUARDIA | Requerido para la administración y visualización de tomas de Enfermería en episodios de Guardia. |
| HABILITAR_NUEVO_FORMATO_PDF_ORDENES_PRESTACION | Permite visualizar observaciones de estudios en el PDF de la Orden de Prestación. |
Gestión de Accesos y Referencias
Asignación de responsable a solicitudes de referencia
Roles involucrados: Gestor institucional, Gestor local, Gestor regional, Gestor de dominio.
Alcance: Módulos de Gestión de Accesos y Turnos (solapa Solicitudes).
A partir de esta versión, los gestores pueden asignarse como responsables de una solicitud de referencia para realizar un seguimiento nominal de los casos.
- Ingresá al detalle de una solicitud de referencia desde el dashboard.
- Vas a ver una nueva sección denominada Responsable (expandida por defecto).
- Si la solicitud no tiene nadie asignado, verás la etiqueta Sin responsable y el botón Asignarme a mí.
- Al hacer clic en el botón, el sistema registrará tus datos y mostrará la fecha y hora de la asignación.
- Si necesitás liberar la solicitud, podés usar la opción Desasignar desde el menú de tres puntos de la sección.
Reglas de visibilidad
- El Gestor institucional ve la sección para solicitudes dirigidas a su institución.
- Si la solicitud se deriva a nivel local, regional o de dominio, la visibilidad del responsable se traslada exclusivamente al nivel correspondiente.
- Al derivar una solicitud a un nivel superior, el responsable se resetea automáticamente a Sin responsable.
Nuevos filtros en el dashboard de solicitudes
Se incorporaron criterios de filtrado por fecha para mejorar la localización de solicitudes:
- Cambio en estado de atención: permite filtrar por la fecha en que el turno asociado cambió de estado (ej: de Pendiente a Turno Asignado).
- Cambio en institución destino: permite filtrar por la fecha en que se asignó o modificó la institución que debe atender la referencia.
Por otro lado se sumaron a los dashboards los siguientes filtros avanzados:
- Especialidad de origen
- Partido de origen
- Modalidad sugerida
- Institución destino
Finalmente se agregó un switch de Ver solo transcritas
Consulta ambulatoria
Obligatoriedad de campos motivo y problema
Roles involucrados: Profesional médico / de la salud que registra la consulta ambulatoria.
Alcance: Consulta Ambulatoria.
A partir de ahora, en caso de activar el FF HABILITAR_OBLIG_MOTIVO_O_PROBLEMA_CONSULTA_AMBULATORIA, los campos Motivo de consulta y Problema dentro de la consulta ambulatoria pasan a ser necesarios para la confirmación de la misma. Es importante mencionar que basta completar uno de los dos. En caso de no hacerlo se le mostrará al usuario un mensaje de error.
Interconsultas
Feature Flag: HABILITAR_INTERCONSULTA
Roles involucrados: Profesionales médicos (solicitante y receptor), Personal de Legales, Personal administrativo
Alcance: Internación y Guardia
Incorporación de Interconsultas al módulo de impresión de Historia Clínica (Rol Legales)
A partir de esta versión, el Personal de Legales puede acceder a la documentación generada por el módulo de Interconsultas desde el módulo de impresión de Historia Clínica, cerrando una brecha que existía en la documentación clínica con valor legal.
Nuevo checkbox “Solicitudes de Interconsultas”
Se incorpora un nuevo tipo de documento al listado de impresión, junto a los ya existentes (Epicrisis, Prescripciones médicas, Notas Clínicas, Resultados de estudios complementarios, Partes anestésicos, Triage y Parte quirúrgico). El checkbox solo es visible cuando el feature flag HABILITAR_INTERCONSULTA está activo.
Al seleccionarlo y definir un rango de fechas, el sistema lista todas las solicitudes de interconsulta del paciente creadas en ese período (para episodios de Internación y Guardia; no aplica a episodios ambulatorios), sin filtrar por estado. El documento generado para cada solicitud incluye:
| Contenido | Detalle |
|---|---|
| Datos de cabecera | Profesional solicitante, servicio destinatario, prioridad, diagnóstico asociado, motivo |
| Cuerpo de la solicitud | Texto completo del motivo de la interconsulta |
| Historial completo | Aceptaciones, rechazos y finalizaciones, con fecha, profesional involucrado y observación cuando corresponda |
| Estado | Estado de la solicitud al momento de imprimir |
⚠️ Documento legal estático: los datos de episodio (sector, cama, institución) representan una foto del momento de creación de la solicitud. Si el paciente cambió de cama o sector con posterioridad, el documento impreso conserva los datos originales.
📝 Este checkbox no incluye las notas de evolución vinculadas a las interconsultas; esas se acceden desde el check “Notas Clínicas” existente.
Identificación de notas de evolución vinculadas a interconsultas
Las notas de evolución registradas en el contexto de una interconsulta siguen formando parte del check “Notas Clínicas” existente, sin cambios en su estructura de impresión. El cambio es de visibilidad: en la columna “Tipo de Documento”, estas notas se identifican con la etiqueta “Notas clínicas – Interconsulta”, y el PDF de cada nota incorpora en su parte superior los datos de la interconsulta relacionada (servicio y subservicio, fecha y hora de la solicitud, profesional solicitante).
📝 Este criterio es consistente con el ya aplicado en el módulo de Histórico del paciente (Evoluciones), donde el mismo label distingue las notas vinculadas a interconsultas.
Ejemplo: la Dra. Rodríguez (Personal de Legales) descarga la documentación del paciente Juan Pérez para el período mayo 2026 seleccionando “Epicrisis”, “Notas Clínicas” y “Solicitudes de Interconsultas”. El PDF resultante integra cronológicamente los 3 tipos de documento, con las notas de evolución de interconsultas identificadas como “Notas clínicas – Interconsulta” y las solicitudes con su historial completo de aceptación/finalización.
Filtros en el Buzón de Interconsultas
A partir de esta versión, el Buzón de Interconsultas Recibidas incorpora un panel de filtros en el lateral izquierdo, que permite al profesional acotar la vista según múltiples criterios combinables entre sí.
| Filtro | Tipo de control | Valor por defecto |
|---|---|---|
| Estado de solicitud | Checkboxes (Pendiente, Aceptada, Rechazada, Finalizada) | Pendiente y Aceptada marcados |
| Ámbito | Checkboxes (Guardia, Internación) | Sin valor por defecto |
| Fecha de creación | Rango Desde / Hasta | Sin valor por defecto |
| Paciente | ID, N° de documento, Nombre, Apellido (texto libre, búsqueda parcial) | Sin valor por defecto |
Los filtros se aplican automáticamente al modificar cualquier valor, sin necesidad de un botón de búsqueda, y se combinan entre sí con lógica AND. Si un grupo de filtros queda sin ningún valor seleccionado, ese criterio no restringe el listado (se muestran todos los valores posibles). El botón “Restablecer filtros” vuelve la vista a los valores por defecto (Pendiente y Aceptada marcados, resto vacío). Cuando ningún resultado cumple los criterios aplicados, se muestra el mensaje “No se encontraron interconsultas con los filtros aplicados.”
Ejemplo: el Dr. Fernández filtra por Estado = Pendiente, Ámbito = Guardia y Apellido = “Ram”. El listado muestra únicamente las interconsultas pendientes, originadas en Guardia, de pacientes cuyo apellido contiene “Ram”.
Finalización automática de interconsultas al registrar el Alta o la Epicrisis
A partir de esta versión, el sistema resuelve automáticamente las interconsultas abiertas de un paciente cuando su episodio activo llega al punto de cierre clínico, evitando que queden solicitudes pendientes sin continuidad asistencial.
Contexto Internación: el punto de cierre es el registro de la Epicrisis. Contexto Guardia: el punto de cierre es el registro del Alta de paciente, independientemente del tipo de egreso seleccionado (incluyendo “Internación (pase)”), ya que el episodio de guardia es independiente del de internación.
En ambos casos, el sistema procesa todas las interconsultas en estado Pendiente o Aceptada del episodio activo, con la siguiente lógica:
| Estado interconsulta | Notas de evolución | Resultado automático |
|---|---|---|
| Aceptada | Al menos una | Finalizada |
| Pendiente | No aplica | Anulada |
| Aceptada | Sin notas | Anulada |
⚠️ Para interconsultas Aceptadas sin notas de evolución se habilita, de forma excepcional, la transición Aceptada → Anulada: al no existir actividad asistencial registrada, se considera que la atención nunca se concretó. Esta transición fue acordada con el negocio.
El proceso es transparente para el profesional (no muestra alertas ni requiere confirmación) y queda registrado en el historial de la interconsulta como una acción ejecutada por el sistema, nunca a nombre del profesional que registró el Alta/Epicrisis ni del servicio receptor.
Ejemplo (Internación): el Dr. González registra la Epicrisis del paciente Ramírez, que tiene 3 interconsultas abiertas: una Aceptada con nota de evolución (Cardiología, pasa a Finalizada), una Aceptada sin notas (Traumatología, pasa a Anulada) y una Pendiente (Neurología, pasa a Anulada). El historial de cada una registra “Finalizada/Anulada automáticamente por epicrisis del paciente | Sistema”.
Ejemplo (Guardia): el Dr. Sosa registra el Alta del Sr. López con tipo de egreso “Internación (pase)”. Aunque el paciente continúa internado, el episodio de guardia se cierra igual, y sus 2 interconsultas abiertas se resuelven automáticamente.
Cierre de interconsultas abiertas al registrar el Alta Administrativa
Esta funcionalidad extiende la lógica de cierre automático de interconsultas al momento del Alta administrativa, para los casos en que el feature flag HABILITAR_ALTA_SIN_EPICRISIS permite saltear el registro de la Epicrisis y el paciente llega al alta administrativa con interconsultas todavía abiertas (Pendientes o Aceptadas).
Al registrarse el Alta administrativa, el sistema aplica la misma lógica de resolución ya vigente para Epicrisis/Alta de paciente (ver sección anterior): las interconsultas Aceptadas con al menos una nota de evolución pasan a Finalizada, y las Pendientes o Aceptadas sin notas pasan a Anulada. La acción queda registrada en el historial como ejecutada por el sistema, con la observación “Interconsulta anulada automáticamente por alta de paciente” o “Interconsulta finalizada automáticamente por alta de paciente” según corresponda.
📝 Al tratarse de un alta administrativa, el profesional que ejecuta la acción puede no ser un profesional médico (por eso el registro del historial no asocia esta transición a ningún profesional puntual).
⚠️ Dado que el alta administrativa deja inactivo el episodio, las interconsultas resueltas por esta vía no vuelven a visualizarse en el Buzón (comportamiento ya vigente desde HSI-28927 para episodios cerrados).
Ejemplo: el paciente Gómez tiene una interconsulta Aceptada sin notas de evolución al momento en que el área administrativa registra su alta (bajo HABILITAR_ALTA_SIN_EPICRISIS activo, sin haberse registrado Epicrisis). Al confirmarse el alta administrativa, la interconsulta pasa automáticamente a Anulada.
Ajuste en los campos Origen y Destino al crear una Interconsulta
Se ajustó el criterio con el que se cargan las opciones de los campos Origen y Destino en la pantalla de creación de una interconsulta, para reflejar la definición acordada con Negocio:
| Campo | Criterio |
|---|---|
| Origen | Todas las Unidades Jerárquicas (UJ) a las que pertenece el profesional logueado, sin filtrar por tipo (Servicio, Departamento, etc.) ni por si tienen agendas creadas |
| Destino | Todas las UJ de tipo Servicio (tengan o no agendas creadas), incluyendo todas sus UJ hijas, sin filtrar estas últimas por tipo |
Ambos selectores muestran Servicio y Subservicio combinados en un único campo, reutilizando el mismo criterio ya aplicado en la pantalla de Turnos para la selección de servicio.
Ejemplo: el Dr. Ibáñez pertenece a las UJ “Guardia” y “Clínica Médica”. Al crear una interconsulta, el campo Origen le muestra ambas UJ sin importar su tipo. Al elegir el Destino, el campo lista todos los Servicios de la institución (por ejemplo “Cardiología”) junto con sus subservicios (por ejemplo “Cardiología > Arritmias”), independientemente de si tienen agenda configurada.
Corrección de Sector, Sala y Cama para pacientes en Guardia
Se corrigió la visualización de los campos Sector, Sala y Cama en las cards del Buzón de Interconsultas y en la sección de asociación de interconsulta al crear una Nota de Evolución, para pacientes en episodios de Guardia.
Anteriormente, los tres campos solo se mostraban cuando los tres tenían información cargada; si faltaba alguno, los tres aparecían vacíos, incluso cuando otro sí tenía dato. Esto no reflejaba correctamente la realidad de Guardia, donde es válido que un paciente no tenga cama o sala asignada.
A partir de esta versión, cada campo se muestra de forma independiente según su disponibilidad de datos, y cuando ninguno de los tres tiene información se indica explícitamente “Sin datos” en lugar de dejar los campos vacíos.
Ejemplo: un paciente en Guardia asignado a un consultorio, sin sala ni cama registradas, ahora muestra el Sector correctamente y “Sin datos” en Sala y Cama, tanto en la card del Buzón como al asociar la interconsulta en una nueva Nota de Evolución.
Ocultamiento del campo de Interconsulta en la edición de Notas de Evolución Médica
Se corrigió el formulario de edición de una Nota de Evolución Médica, que mostraba un selector para asociar o cambiar la interconsulta vinculada a la nota, aun cuando esa funcionalidad no está definida ni operativa en el contexto de edición.
A partir de esta versión, el campo selector de interconsulta ya no se muestra al editar una nota de evolución médica existente, evitando que el usuario acceda a una funcionalidad no soportada. El campo se mantiene sin cambios en el formulario de creación de la nota, donde la asociación a una interconsulta sigue funcionando normalmente.
Ejemplo: un profesional edita una Nota de Evolución Médica de un paciente en Guardia desde el histórico. El formulario de edición ya no incluye el selector de interconsulta, a diferencia de lo que ocurría antes de esta corrección.
Corrección del feature flag HABILITAR_ALTA_SIN_EPICRISIS
El feature flag HABILITAR_ALTA_SIN_EPICRISIS indica si se puede dar de alta una internación sin tener una epicrisis asociada. En el flujo normal, la epicrisis es un prerrequisito obligatorio para poder registrar el alta médica:
Iniciar internación (admin) → Evaluación de ingreso (médico) → Notas de evolución → Epicrisis (médico) → Alta médica (médico) → Alta física (admin) → Alta administrativa (admin)
Con el flag en true, la epicrisis debería dejar de ser un requisito, permitiendo registrar el alta médica sin haberla completado previamente. Se corrigió un error por el cual, con el flag activo, la opción “Alta médica” no se mostraba en el menú de Acciones para un paciente en internación sin epicrisis cargada, impidiendo en la práctica saltear ese paso aun con la funcionalidad habilitada.
⚠️ Con el flag en false (valor por defecto), el comportamiento no cambia: la epicrisis sigue siendo obligatoria antes de poder registrar el alta médica.
📝 Esta corrección es la que habilita, en la práctica, el escenario descripto en “Cierre de interconsultas abiertas al registrar el Alta Administrativa”: con el flag correctamente operativo, un paciente puede llegar al alta administrativa sin epicrisis y con interconsultas todavía abiertas, caso que dicha funcionalidad resuelve.
Ejemplo: con HABILITAR_ALTA_SIN_EPICRISIS en true, el Dr. Aguirre ingresa a un paciente internado que no tiene epicrisis registrada. Antes de esta corrección, la opción “Alta médica” no aparecía en el menú de Acciones. A partir de esta versión, la opción está disponible y permite registrar el alta médica sin exigir la epicrisis previa.
Mejoras en la administración y visualización de tomas de Enfermería
Toda la funcionalidad descrita en esta sección requiere los siguientes Feature Flags activos:
- Feature Flag HABILITAR_MODULO_INTERNACION en TRUE
- Feature Flag HABILITAR_MODULO_GUARDIA en TRUE (para la funcionalidad en episodios de Guardia)
Roles involucrados: Enfermero, Farmacéutico, Personal de farmacia, Especialista médico, Especialista en odontología, Profesional de la salud.
Alcance: esta funcionalidad aplica tanto a pacientes en ámbito de internación como de guardia. En ambos casos se accede mediante la Historia Clínica del paciente, solapa Enfermería. El rol que administra las tomas es el Enfermero; los demás roles solo visualizan la información registrada. El paciente debe tener al menos una indicación asociada.
Registro y visualización de información en tomas de enfermería
Selector de hora en el modal de registro de toma
En el modal de registro de una toma, se reemplazó el componente de carga de hora por un selector explícito de horas y minutos:
- Permite seleccionar de forma independiente la hora (rango 00–23) y los minutos (rango 00–59).
- El comportamiento del registro de la toma no se modifica: se mantienen la persistencia, las validaciones y el flujo de confirmación actuales.
- La selección de fecha no presenta cambios.
Información visible en la card de una toma administrada
Una vez registrada la administración de una toma, la card de la toma en la solapa Enfermería muestra la siguiente información:
- Hora de administración programada: horario planificado para la toma según la indicación.
- Fecha y hora real de administración: momento informado por enfermería en el que efectivamente se administró la toma al paciente.
- Nombre y apellido del enfermero que registró la toma (utiliza nombre autopercibido si está registrado), junto con la fecha y hora de registro en el sistema.
- Observaciones: texto libre registrado por el enfermero durante la administración. Si el enfermero no ingresó observaciones al registrar, este dato no se muestra en la card.
Información visible en la card de una toma rechazada
Una vez rechazada una toma, la card de la toma en la solapa Enfermería muestra la siguiente información:
- Hora de administración programada: horario planificado para la toma según la indicación.
- Observaciones: texto libre registrado por el enfermero durante el rechazo.
- Nombre y apellido del enfermero que rechazó la toma (utiliza nombre autopercibido si está registrado), junto con la fecha y hora de rechazo en el sistema.
Nota: las tomas registradas con anterioridad a esta versión continúan visualizándose sin alteraciones en la información existente. En los casos en que no exista información para los nuevos datos incorporados (fecha y hora real de administración, fecha y hora de registro, observaciones), los campos correspondientes se muestran en blanco.
Administración de tomas de enfermería en episodios de Guardia
Solapa Enfermería en episodios de Guardia
Al acceder a la Historia Clínica de un paciente con un episodio activo de Guardia, se visualiza la solapa Enfermería. La solapa es visible para el rol Enfermero y para los demás roles con acceso al módulo de Guardia.
- La solapa permanece disponible mientras el episodio de Guardia se encuentre activo, hasta que se realice el alta administrativa.
Visualización y administración de tomas
Dentro de la solapa Enfermería, se visualizan las tomas asociadas a las indicaciones del paciente, con información equivalente a la disponible para episodios de Internación.
- Solo el rol Enfermero puede registrar la administración de las tomas; los demás roles involucrados únicamente visualizan las tomas registradas.
- La administración de tomas se comporta de la misma manera que la funcionalidad disponible para episodios de Internación.
- Toda administración registrada por el Enfermero impacta en las indicaciones del paciente.
Pacientes con episodios simultáneos de Guardia e Internación
Cuando un paciente tiene un episodio activo de Guardia y uno de Internación en simultáneo, la solapa Enfermería muestra las tomas separadas:
- Primero las tomas de Internación, bajo el separador “Indicaciones de internación”.
- Luego las tomas de Guardia, bajo el separador “Indicaciones de guardia”.
Este comportamiento aplica tanto en el ámbito de Guardia como en el de Internación.
La incorporación de esta funcionalidad no modifica el comportamiento actual de la administración de tomas en episodios de Internación: las reglas de negocio y validaciones existentes se mantienen sin cambios.
Red de Imágenes
Visualización de observaciones en estudios
Roles involucrados: Personal de Laboratorio e Imágenes, médico solicitante del estudio.
Alcance: Red de Imágenes / Laboratorio.
Las observaciones cargadas por el médico al solicitar un estudio ahora son visibles para el personal de Laboratorio e Imágenes en:
- Listas de trabajo.
- Solicitudes de Guardia e Internación.
- PDF de la Orden de Prestación (requiere FF activo).
- Servicios de integración FHIR.
Backoffice y Administración
Corrección de acceso inseguro en la descarga de documentos adjuntos del paciente
Roles involucrados: Todos los roles con acceso a documentos adjuntos de pacientes.
Alcance: Perfil del paciente → Documentos adjuntos.
Se corrigió una vulnerabilidad de control de acceso en la descarga de archivos adjuntos del paciente. El endpoint de descarga (GET /api/institution/{institutionId}/person/{personId}/file/download/{fileId}) no verificaba que el archivo solicitado (fileId) perteneciera efectivamente al paciente indicado en la URL (personId).
⚠️ En la práctica, esto permitía que, conociendo o probando distintos valores de fileId, un usuario autenticado pudiera descargar documentos adjuntos de un paciente distinto al que estaba consultando —incluyendo documentación de identidad— sin que el sistema validara que el archivo perteneciera a ese paciente.
A partir de esta versión, antes de servir cualquier descarga el sistema valida que el archivo solicitado pertenezca al paciente indicado en la URL. Si el fileId no corresponde a ese personId, la descarga se rechaza.
Ejemplo: un usuario con acceso al perfil del paciente Fernández intenta descargar, modificando manualmente el fileId en la URL, un documento que en realidad pertenece al paciente García. Antes de esta corrección, el archivo se descargaba igual; a partir de esta versión, el sistema rechaza la descarga por no corresponder el archivo al paciente consultado.
Obligatoriedad de domicilio y cobertura en empadronamiento
Roles involucrados: Administrativo, Administrativo de UJ, Administrador Institucional.
Alcance: Módulo Pacientes.
Para facilitar el recupero de costos y la gestión administrativa, se modificó el flujo de carga de datos personales. Ahora en el empadronamiento y edición de pacientes, la cobertura médica y los datos del domicilio País, Provincia, Partido, Ciudad, Calle y Número son campos obligatorios (Código postal, Piso, Departamento y Barrio continúan siendo opcionales). Además se reordenaron los campos del domicilio de forma más intuitiva.
En caso de que no se pueda completar la información completa del domicilio, se puede marcar el checkbox “Confirmo que el paciente no cuenta con información completa de domicilio” para omitir la obligatoriedad de los campos asociados al domicilio sin perder los datos ya cargados.
En el perfil del paciente, si los datos del domicilio no se encuentran cargados (o se encuentran cargados parcialmente) aparecerá la leyenda “Datos incompletos”.
Especialidad en agendas responsables de servicio
Roles involucrados: Administrador de Agenda.
Alcance: Gestión de Agendas.
Ahora se puede asociar una Especialidad a las agendas Responsables de Servicio. Esto permite que, al buscar turnos por especialidad, el sistema incluya estas agendas en los resultados, mejorando la oferta de turnos en la red. Es importante mencionar que el campo mencionado para estas agendas es de carácter opcional.
Dentro de las especialidades ofrecidas se listan todas las especialidades de los especialistas de la salud que están asociados a la unidad jerárquica seleccionada.
Los usuarios con el rol administrador institucional pueden ingresar desde el backoffice al detalle de una unidad jerárquica y visualizar cuáles son los profesionales asociados junto con sus especialidades.
