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 clínica y administrativa:
- Interconsultas: Se centraliza la visualización en la Historia Clínica —incluyendo el motivo de cierre en Evoluciones— y se habilita que el propio solicitante anule una interconsulta Pendiente; además, se refuerza la seguridad revalidando permisos en cada acción y se protege desde BackOffice a las interconsultas en curso frente a la deshabilitación de su Unidad Jerárquica.
- Turnos: Se optimiza la asignación de sobreturnos para referencias.
- Farmacia: Se mejora el flujo de validación farmacéutica.
- Referencias: Nuevo diseño del dashboard con mejores filtros de responsabilidad y trazabilidad de lectura.
- Pases: Se completa el flujo de pase de Guardia a Internación, permitiendo una gestión administrativa más fluida.
Nota importante sobre feature flags
Un feature flag de desarrollo es una herramienta para gestionar riesgos y entregas (habilitar/deshabilitar o acotar el alcance de una nueva funcionalidad mientras se valida). Es temporal y se elimina cuando la función se consolida y pasa a formar parte estable del producto.
⚠️ 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 integral de interconsultas en HC y Backoffice. |
| HABILITAR_LISTA_TRABAJO_FARMACIA | Acceso a validación farmacéutica e impresión de indicaciones. |
| HABILITAR_MODULO_INTERNACION | Permite acceso al módulo de internación. |
| HABILITAR_MODULO_GUARDIA | Permite acceso al módulo de guardia. |
| HABILITAR_PASE_DE_GUARDIA_A_INTERNACION_EN_DESARROLLO | Flujo de pase administrativo entre Guardia e Internación. |
| HABILITAR_ALERTA_DOMICILIO_CONFIRMACION_TURNO | Validación de datos de domicilio al confirmar asistencia. |
| HABILITAR_MONITOREO_CIPRES | Acceso al tablero de monitoreo de integración Cipres. |
Properties del sistema configurables
| Propiedad | Descripción | Valor por defecto |
|---|---|---|
| app.cipres.consultations.institution | ID de institución para filtrar la transmisión de consultas a Cipres. | (Vacío) |
Nota importante sobre esquema SNOMED
Se actualizó el esquema SNOMED a la release de mayo de 2026. Si el feature flag HABILITAR_RELACIONES_SNOMED está en TRUE, es necesario actualizar el esquema siguiendo la Guía de configuración del esquema SNOMEDCT. Además, las vistas materializadas de unidades y vías de un fármaco incorporan el código SNOMED correspondiente. Para eso se actualizaron los scripts que poblan esas vistas: hay que solicitar la versión nueva al equipo de HSI y usarla en reemplazo de la anterior.
Interconsultas
Feature Flag: HABILITAR_INTERCONSULTA (no aplica a la pantalla de BackOffice de Unidades Jerárquicas, que es siempre visible)
Roles involucrados: Especialista médico, Especialista en odontología, Profesional de la salud, Administrador de Institución con acceso a BackOffice
Alcance: Internación y Guardia, sobre episodios activos. La restricción de deshabilitación de Unidades Jerárquicas aplica en BackOffice → Instituciones → Unidades Jerárquicas.
A partir de esta versión, se centraliza la visualización de interconsultas en la Historia Clínica, se incorpora el motivo de cierre en Evoluciones, se habilita la anulación por parte del solicitante, se refuerza la seguridad revalidando permisos en el momento de cada acción, y se protege desde BackOffice a las interconsultas en curso frente a la deshabilitación de su Unidad Jerárquica de destino.
Card de Interconsultas en Historia Clínica
Se incorpora una nueva card llamada Interconsultas, ubicada debajo de Signos Vitales, tanto en Internación como en Guardia. Permite visualizar de un vistazo todas las solicitudes del episodio activo del paciente, sin necesidad de navegar al Buzón.
Contenido de cada fila:
| Campo | Detalle |
|---|---|
| Solicitud | Fecha y hora de creación (formato “Hoy/Ayer HH:mm hs” o DD/MM/AAAA) |
| Estado | Pendiente, Aceptada, Rechazada, Finalizada o Anulada |
| Destino | Unidad Jerárquica (UJ) a la que fue dirigida |
| Últ. actualización | Fecha/hora del evento más reciente sobre la interconsulta (aceptación, nota de evolución, rechazo, finalización o anulación); queda vacío si sigue Pendiente sin acciones |
Se listan todas las interconsultas del episodio activo, sin filtrar por Unidad Jerárquica o familia del profesional que consulta la HC, y se ordenan por fecha de solicitud, de más reciente a más antigua.
Cada fila tiene un menú (⋮) con dos opciones: Ver interconsulta, que desplaza automáticamente la pantalla hasta la sección Evoluciones y resalta el detalle de esa interconsulta puntual; y Anular interconsulta, habilitada únicamente para quien la creó y mientras esté Pendiente (ver más abajo).
Como consecuencia de esta nueva card, se eliminó el acceso directo “Interconsulta” que aparecía junto al Diagnóstico principal y a cada uno de los Otros diagnósticos: el acceso queda centralizado en la nueva card.
Ejemplo: en la Historia Clínica de la paciente Paula Maral, la card muestra “Hoy 08:25 hs | Pendiente | Cardiología | —” y “Ayer 10:00 hs | Aceptada | Traumatología | Hoy 15:30 hs”.
Motivo de Rechazo, Finalización o Anulación en Evoluciones
El detalle de una interconsulta en Evoluciones incorpora una nueva sección llamada Motivo, visible cuando la interconsulta está en estado Rechazada, Finalizada o Anulada. Antes era necesario ir al Buzón para conocer este dato; ahora se muestra también desde la Historia Clínica, con el formato: “DD/MM/AAAA HH:mm hs | [texto del motivo] | Nombre del profesional”.
Contenido según el estado:
| Estado | Contenido de “Motivo” |
|---|---|
| Rechazada | Motivo de rechazo ingresado por el receptor |
| Finalizada, con Observación | Texto de la Observación cargada al finalizar |
| Finalizada, sin Observación | Se muestra igual la sección, indicando “Sin Observación” |
| Anulada | Texto generado automáticamente por el sistema, o motivo ingresado manualmente por quien la anuló; en lugar del profesional figura “Sistema” cuando la anulación fue automática |
Para interconsultas en estado Pendiente o Aceptada la sección no se muestra: todavía no hay un cierre que documentar.
Ejemplo: en el detalle de la interconsulta de Bruno Cáceres (Rechazada), Evoluciones muestra “16/07/2026 15:42 hs | Rechazado por inactividad | Eduardo Alfaro” — el mismo dato que ya se veía en el Buzón.
📝 El dato no se vuelve a capturar: es el mismo que ya se registraba en el Buzón de Interconsultas Recibidas. Esta funcionalidad solo lo hace visible también desde la Historia Clínica.
Anulación de la interconsulta por el profesional solicitante
El profesional que creó una interconsulta puede anularla mientras esté en estado Pendiente, por ejemplo si se equivocó de servicio destino o cargó un dato incorrecto.
Reglas:
- Solo puede anularla el profesional que la creó — no aplica el criterio de familia de UJ, ni alcanza con compartir su Unidad Jerárquica o servicio.
- Solo está disponible mientras la interconsulta está Pendiente; una vez Aceptada, la única vía de cierre es que el receptor la Finalice.
- Requiere un motivo obligatorio de texto libre, mismo patrón que Rechazar.
- La opción vive únicamente en el menú (⋮) de la card de Interconsultas en la Historia Clínica. El Buzón de recibidas nunca la ofrece, ni siquiera si quien creó la interconsulta también pertenece a la Unidad Jerárquica de destino.
Al anularse, la interconsulta desaparece por completo del Buzón del servicio de destino. En la Historia Clínica, en cambio, permanece visible en Evoluciones y en la card de Interconsultas, en estado Anulada, junto con su motivo — por tratarse de un requisito legal de la historia clínica.
Ejemplo: Eduardo Alfaro anula una interconsulta que había dirigido por error a Cardiología, con el motivo “Me equivoqué de servicio destino, correspondía a Nefrología y no a Cardiología”. Roberta Fernández, de Cardiología, deja de ver esa solicitud en su Buzón.
📝 Si entre que se abre la pantalla y se confirma la anulación el servicio de destino acepta la interconsulta, el sistema revalida el estado en el momento de la acción y rechaza la anulación si ya no está Pendiente.
Revalidación de permisos vigentes al solicitar o accionar sobre una interconsulta
Toda acción sobre una interconsulta (Solicitar, Aceptar, Rechazar, Finalizar, Ir a HC y Responder) revalida los permisos vigentes del profesional en el momento exacto de ejecutarla, y no solo al cargar la pantalla.
Esto cubre dos situaciones que antes podían dejar a un profesional accionando sobre una interconsulta a la que ya no debería tener acceso, si el cambio ocurría mientras tenía la pantalla abierta:
- Le quitan su asociación directa con la Unidad Jerárquica.
- Se deshabilita el switch “Habilitado para Interconsultas” de una Unidad Jerárquica intermedia, cortando la cadena de parentesco por la que accedía a esa interconsulta por familia (y no por pertenencia directa).
Comportamiento según la acción, cuando la revalidación falla:
| Acción | Resultado |
|---|---|
| Aceptar / Rechazar / Finalizar / Ir a HC | Se rechaza la acción, se muestra un aviso y el Buzón se refresca automáticamente, sin necesidad de F5 manual |
| Responder (asociar nota de evolución) | La nota se guarda igual, como evolución común y sin asociar — no se pierde el contenido clínico —, y se muestra un modal bloqueante avisando que la interconsulta sigue sin respuesta |
| Solicitar | Se rechaza el envío y se muestra un aviso; la interconsulta no se genera |
La revalidación es puntual: si un profesional pierde el permiso sobre una Unidad Jerárquica, sus permisos sobre las demás no se ven afectados, y otros profesionales que conservan el acceso a esa interconsulta pueden seguir accionándola con normalidad.
Ejemplo: el Dr. Franco Ledesma tiene abierta una interconsulta Pendiente de Bruno Cáceres dirigida a “Alergia”. Mientras la pantalla sigue abierta, un administrador le quita su asociación con esa Unidad Jerárquica. Al presionar “Aceptar” sin haber refrescado, el sistema rechaza la acción y le avisa que ya no tiene permisos.
⚠️ Esto es distinto de la restricción para deshabilitar UJ (ver a continuación): esa previene apagar una UJ con interconsultas dirigidas directamente a ella. No cubre que se apague una UJ intermedia que solo corta el acceso por parentesco hacia una UJ hermana o descendiente — ese caso queda cubierto por esta revalidación.
Restricción para deshabilitar Unidades Jerárquicas con interconsultas en curso
El switch “Habilitado para Interconsultas” de BackOffice (Instalaciones → Instituciones → Unidades Jerárquicas) ya no permite deshabilitar una Unidad Jerárquica (UJ) que tenga interconsultas en estado Pendiente o Aceptada dirigidas exactamente a ella. Al intentar apagarlo en esa condición, el sistema rechaza la acción, el switch permanece Habilitado y se muestra un aviso.
Alcance de la validación:
- Se evalúa únicamente la UJ puntual que se intenta deshabilitar — no hijas, hermanas ni ancestras.
- Habilitar una UJ nunca se bloquea: la restricción aplica solo a la transición Habilitado → Deshabilitado.
- Interconsultas en estado Finalizada, Rechazada o Anulada no bloquean la desactivación.
- Aplica sin importar si el feature flag HABILITAR_INTERCONSULTA está activo o no en la institución, ya que protege interconsultas que ya existen como registro clínico.
Ejemplo: Mariano Fuentes intenta deshabilitar “Cardiología”, que tiene una interconsulta Pendiente para Iván Salazar y otra Aceptada para Milagros Ríos. Al tocar el switch, el sistema rechaza la acción y “Cardiología” permanece Habilitada.
⚠️ El mensaje de aviso indica la cantidad de interconsultas por estado (ej. “1 Pendiente, 1 Aceptada”); si esa discriminación no era viable técnicamente al momento de estimar, puede haber quedado un mensaje genérico equivalente — conviene verificar el texto real contra el ambiente antes de publicar.
Turnos y Agenda
Sobreturnos para solicitudes de referencia
Se habilitó la posibilidad de asignar sobreturnos a pacientes que vienen con una solicitud de referencia previa.
- En la solapa Oferta por institución, si no encontrás turnos comunes, hacé clic en el nuevo botón Buscar sobreturnos.
- El sistema listará los sobreturnos disponibles en las agendas que los permitan.
- Podrás ver cuántos sobreturnos ya fueron asignados en cada franja horaria para no sobrecargar el servicio.
Validación de domicilio en confirmación de turno
Feature flag requerido: HABILITAR_ALERTA_DOMICILIO_CONFIRMACION_TURNO en TRUE
Roles involucrados: Administrativo, Administrativo de UJ, Especialista Médico, Especialista en Odontología, Enfermero, Profesional de la Salud.
En el módulo Turnos, al momento de confirmar un turno de un paciente en una agenda de profesionales, si sus datos de domicilio (País, Provincia, Ciudad, Partido, Calle) están incompletos en el MPI, el sistema mostrará un popup obligatorio para completarlos.
Con este popup podés completar los datos en ese momento y elegir si querés que impacten también en el MPI (Maestro de Pacientes) para futuras atenciones.
Si el paciente realmente no cuenta con domicilio, podés marcar el checkbox de confirmación de falta de datos para poder continuar con la atención.
Gestión de Accesos y Referencias
Roles involucrados: Gestor institucional, Gestor local, Gestor regional, Gestor de dominio.
Filtro de responsable asignado
Se incorporó un nuevo filtro en el Dashboard de Referencias para facilitar el seguimiento de las tareas del equipo de gestión.
| Opción de Filtro | Resultado |
|---|---|
| Sin responsable asignado | Muestra solicitudes que nadie tomó todavía. |
| Asignado a mí | Muestra solo las solicitudes que tenés a tu cargo. |
| Asignado a otro responsable | Permite buscar solicitudes asignadas a otros compañeros del mismo nivel. |
Seguimiento de solicitudes no leídas
Para que no se pierda ningún cambio importante, las solicitudes ahora se marcan como No leídas (con una barra violeta lateral) cuando ocurre alguna modificación (nuevo turno, cambio de prioridad, adjuntos nuevos, etc.).
- La marca desaparece automáticamente cuando entrás a ver el detalle de la solicitud.
- Podés volver a marcarla como “No leída” manualmente si necesitás que otro gestor la revise.
Validación de indicaciones intervenidas
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
- Feature Flag HABILITAR_LISTA_TRABAJO_FARMACIA en TRUE
Roles involucrados: Farmacéutico, Personal de farmacia, Especialista médico, Especialista en odontología, Profesional de la salud, Enfermero.
Alcance: esta funcionalidad aplica tanto a pacientes en ámbito de guardia como de internación. Para los pacientes en ámbito de guardia, se accede mediante la Historia Clínica; para los de internación, se puede acceder tanto por Historia Clínica como mediante la Lista de trabajo.
Botón “Validar” en indicaciones intervenidas
El rol Farmacéutico visualiza el botón “Validar” en la card de la indicación cuando el estado de validación farmacéutica es “Intervenida por Farmacéutico”.
Al hacer clic en “Validar”, se abre el mismo modal “Validar indicación” utilizado para validar indicaciones en estado “Pendiente de validación”, con las mismas opciones “Cancelar” y “Validar”.
Acciones del modal de validación
Si el Farmacéutico hace clic en “Cancelar” o en la X del modal:
- El modal se cierra.
- La indicación no cambia de estado, permanece en “Intervenida por Farmacéutico”.
Si el Farmacéutico hace clic en “Validar”:
- El estado de validación farmacéutica cambia de “Intervenida por Farmacéutico” a “Validada por farmacéutico”.
- Se revierte el estado de intervención.
- Se registra la validación (farmacéutico, fecha y hora) para garantizar la trazabilidad del proceso.
- El botón “Validar” deja de ser visible en la card de la indicación.
Efecto del cambio de estado para el resto de los roles
Una vez validada la indicación previamente intervenida, para todos los roles incluidos en esta funcionalidad (Farmacéutico, Personal de farmacia, Especialista médico, Especialista en odontología, Profesional de la salud, Enfermero):
- El estado de validación farmacéutica se muestra como “Validada por farmacéutico” en lugar de “Intervenida por Farmacéutico” tanto en la card de la indicación como en el modal de ver detalle.
- El botón “Validar” no se muestra en la card.
Actualización de la Lista de trabajo de Farmacia
La Lista de trabajo de Farmacia refleja el nuevo estado “Validada por farmacéutico” de la indicación una vez confirmada la validación.
Internación y Guardia
Feature flag requerido: HABILITAR_PASE_DE_GUARDIA_A_INTERNACION_EN_DESARROLLO en TRUE
Roles involucrados: Administrativo, Administrativo de UJ.
Pase de guardia a internación
Se agregaron acciones al listado de Pacientes con pase del módulo Internación.
- Iniciar internación: Al seleccionar esta opción, el formulario de Nueva Internación se precompleta con los datos del episodio de Guardia (Médico solicitante, Origen, Cobertura), ahorrando tiempo de carga y evitando errores.
- Además si un paciente se encuentra en el listado de Pacientes con pase, se elimina el botón Iniciar Internación en el perfil de paciente, y se muestra una leyenda que dice “El paciente se encuentra en el listado de pacientes con pase (módulo internación)”
- Quitar del listado de pases: Si un paciente finalmente no se interna y debe ser eliminado del listado de Pacientes con pase, podés quitarlo de la lista indicando el motivo.
Historia Clínica y Pacientes
Carga de problemas en receta electrónica
Ahora es posible registrar un nuevo problema de salud directamente mientras estás generando una receta electrónica, sin necesidad de salir del flujo de prescripción. El problema quedará automáticamente asociado a la receta y registrado en la Historia Clínica.
Registro de situaciones de violencia
Campos opcionales al continuar registro de violencias
Se modificó la obligatoriedad de todos los campos dentro del desplegable Nuevo episodio de violencia al continuar un registro. A partir de ahora, todos los campos dentro del desplegable pasaron a ser opcionales.
Es importante aclarar que para la creación de un nuevo registro de violencia si se mantiene la obligatoriedad de los campos como en la actualidad.
En caso de no completar algunos de los campos, dentro del histórico se visualiza la leyenda de “Sin información” debajo de los campos no completados.
Editar datos de persona que ejerce violencia
Se incluyó un botón de Editar dentro del card Persona/s que ejercen violencia registrada/s.
En caso de hacer clic sobre este botón, se abre el formulario con la información precargada y con la posibilidad de editar cualquiera de los campos. En caso de editar alguno de los campos, luego de confirmar los datos, se actualiza el card en cuestión. La edición de los datos contempla los flujos de Nuevo episodio de violencia y Continuar un registro.
En caso de realizar la edición de los datos en registros posteriores a la creación de una nueva situación de violencia, los datos modificados deberán impactar desde el registro en donde se hizo la modificación en adelante.
Ajuste en la actualización de coberturas mediante consulta a PUCO
Al actualizar la cobertura de un paciente, el sistema consulta el servicio de PUCO para obtener las coberturas informadas para el mismo. Anteriormente, cuando se encontraba una coincidencia por RNOS con una cobertura almacenada en el sistema, esta era habilitada automáticamente, incluso si había sido deshabilitada previamente de manera intencional.
Se modificó este comportamiento para evitar la reactivación de coberturas que hayan sido dadas de baja previamente. A partir de este cambio, cuando se recibe una cobertura desde PUCO:
- Si existe al menos una cobertura activa con el RNOS correspondiente, no se realiza ninguna acción.
- Si no existe ninguna cobertura activa para dicho RNOS, se crea una nueva cobertura.
Seguridad
Seguridad en acceso a datos de pacientes
Se reforzaron los controles de acceso a la información completa de los pacientes. Solo los usuarios con roles activos y autorizados dentro de la institución pueden consultar los datos de auditoría y clínicos detallados, protegiendo la privacidad de la información.