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 de la información clínica y administrativa, destacándose:
Interconsultas: Se amplió la capacidad de respuesta a toda la “familia” de unidades jerárquicas y se incorporó un control granular para habilitar Unidades Jerárquicas desde el Backoffice.
Gestión de Turnos y Reservas: Se sumó un historial de reservas canceladas, nuevos filtros por especialidad y estado de orden, y la solicitud de datos de domicilio durante la confirmación de turno.
Farmacia y Enfermería: Se implementaron ventanas temporales configurables para el registro de tomas del rol Enfermero. El rol Personal de Farmacia tiene acceso a la lista de trabajo de Farmacia. Además, se mejoró el modal de detalles de indicaciones y la visualización de mezclas de fármacos.
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.
Feature Flag | Funcionalidad Asociada |
|---|---|
HABILITAR_INTERCONSULTA | Gestión completa de interconsultas entre servicios. |
HABILITAR_OBLIGATORIEDAD_TELEFONO_MAIL | Exigencia de datos de contacto en el empadronamiento. |
HABILITAR_ALERTA_DOMICILIO_CONFIRMACION_TURNO | Solicitud de domicilio incompleto al confirmar turnos. |
HABILITAR_OBLIGATORIEDAD_EVOLUCION | Obligatoriedad de nota de evolución al cerrar consulta. |
HABILITAR_PASE_DE_GUARDIA_A_INTERNACION_EN_DESARROLLO | Listado de pacientes esperando pase a internación. |
HABILITAR_MEJORAS_INDICACIONES_EN_DESARROLLO | Mejoras visuales en mezclas y detalles de indicaciones. |
HABILITAR_LISTA_TRABAJO_FARMACIA | Permite visualizar estados de validación farmacéutica a los roles que pueden acceder a módulos de guardia e internación. |
HABILITAR_MODULO_INTERNACION | Permite acceso al módulo de internación. |
HABILITAR_MODULO_GUARDIA | Permite acceso al módulo de guardia. |
HABILITAR_LIMITAR_AGENDAS_A_ROLES_DE_SALUD_POR_UJ | Restricción de acceso a agendas según la UJ del profesional. |
HABILITAR_GUARDADO_INFO_EN_MPI | Permite realizar modificaciones en el MPI desde otros módulos. |
HABILITAR_DESARROLLO_RED_IMAGENES | Muestra el módulo de Red de Imágenes. |
HABILITAR_TRIAGE_PARA_ADMINISTRATIVO | Permite el triage por parte de personal administrativo, utilizado en el control de casos duplicados en SNVS (SISA). |
HABILITAR_REPORTE_EPIDEMIOLOGICO | Habilita el reporte epidemiológico y la integración con el control de casos duplicados en SNVS (SISA). |
Historia Clínica e Internación
Registro obligatorio de evoluciones ambulatorias
Feature Flag: HABILITAR_OBLIGATORIEDAD_EVOLUCION en TRUE
Roles involucrados: Especialista médico, Profesional de la salud, Especialista en odontología.
Alcance: Consulta Ambulatoria.
A partir de esta versión, los dominios pueden configurar la obligatoriedad de registrar una nota de evolución antes de finalizar una atención ambulatoria. Esto garantiza que toda prestación médica cuente con su debido respaldo clínico.
El profesional realiza la consulta ambulatoria de forma habitual.
Al intentar hacer clic en Finalizar consulta, si el campo de evolución está vacío, el sistema mostrará un mensaje de validación.
El sistema no permitirá guardar ni cerrar la consulta hasta que se complete el registro de la evolución.
Previsualización de archivos adjuntos en el histórico
Roles involucrados: Todos los roles con acceso a Historia Clínica.
Alcance: Ambulatorio y Red de Imágenes.
Se habilitó la visualización de documentos adjuntos directamente desde el histórico de evoluciones, facilitando el acceso a estudios o informes previos sin necesidad de editar la consulta.
Ingresá a la pestaña Problemas del paciente y buscá la sección Histórico de evoluciones.
En las consultas que posean archivos, verás la sección Documentos adjuntos.
Al hacer clic en el nombre del archivo, el sistema permitirá su previsualización o descarga inmediata.
Gestión de pacientes con pase de guardia a internación
Feature Flag: HABILITAR_PASE_DE_GUARDIA_A_INTERNACION_EN_DESARROLLO en TRUE
Roles involucrados: Administrativo, Administrativo de UJ.
Alcance: Módulo de Internación.
Se incorporó una nueva solapa denominada PACIENTES CON PASE dentro del módulo de Internación. Este listado permite a los administrativos monitorear a los pacientes que tienen el alta médica de guardia con motivo Alta a internación pero que aún están esperando la asignación de una cama en internación.
El listado muestra la siguiente información clave:
Campo | Detalle |
|---|---|
Paciente | Nombre, apellido, DNI, ID, sexo, edad |
Nivel de urgencia | Prioridad asignada en el formulario de pase a internación. El listado se ordena según el nivel de urgencia. |
Diagnóstico | Problema seleccionado en el formulario de pase a internación. |
Servicio responsable | Servicio responsable seleccionado en el formulario de pase a internación. |
Tipo de cuidado | Tipo de cuidado seleccionado en el formulario de pase a internación. |
Tiempo de espera | Cálculo de horas transcurridas desde la solicitud del pase. |
Además, la nueva pestaña cuenta con filtros por fecha de pase y por paciente, utilizando el ID, el número de documento, el nombre y el apellido.
En futuras versiones se agregarán nuevas acciones al listado (internar paciente, eliminar del listado).
Red de imágenes – Gestión de estudios derivados para Técnicos
Feature flag requerido: HABILITAR_DESARROLLO_RED_IMAGENES en TRUE
Roles involucrados: Técnico (de Red de Imágenes).
Alcance: Módulo de Imágenes.
A partir de esta versión, se habilitó una gestión integral de los estudios que son derivados a otras instituciones para su informe. Esto permite al técnico mantener un control claro sobre el estado de los estudios fuera de su lista de trabajo habitual.
Nueva pestaña de Derivaciones
Se incorporó la pestaña “Derivaciones” dentro del módulo Imágenes.
Al derivar un estudio, este desaparece de la lista de trabajo principal del técnico y se traslada automáticamente a esta pestaña.
La tabla muestra por defecto los estudios de los últimos 7 días, ordenados del más antiguo al más nuevo según su última actualización.
Al expandir una fila, podés ver el historial completo de eventos (fecha, hora y descripción) y las observaciones asociadas.
Columnas de la tabla de derivaciones:
Campo | Detalle |
|---|---|
Paciente | Nombre y apellido (incluye nombre autopercibido si existe) |
DNI – ID | Documento e identificador del paciente |
Estudio | Nombre del estudio realizado |
Problema asociado | Diagnóstico o problema vinculado |
Institución destino | Institución a la que se derivó el estudio |
Estado del informe | Derivado, Completado, Rechazado |
Última actualización | Fecha y hora del último cambio de estado |
Historial de eventos | Al desplegar la fila, se muestra un historial con fecha y hora de las acciones realizadas |
Gestión de estudios rechazados y re-derivación
Si un informador de la red rechaza un estudio, el técnico ahora puede visualizarlo y actuar en consecuencia:
El estudio aparecerá con el estado “Rechazado” en la pestaña de Derivaciones.
En el historial expandido, podrás ver la fecha, hora, motivo del rechazo y las observaciones del informador.
Se habilitó la acción “Derivar” para estos casos. Al seleccionarla, se abre un modal con la información del rechazo previo.
Podés completar el campo Observaciones y hacer clic en [Derivar] para enviar el estudio nuevamente.
Reglas para el campo Observaciones en re-derivación:
Motivo del rechazo | Obligatoriedad de Observaciones |
|---|---|
Faltan imágenes en el PACS central | Opcional |
No contamos con profesionales para ese informe | Opcional |
Se solicita más información | Obligatorio |
Otros | Obligatorio |
Filtros avanzados y persistencia de sesión
Se rediseñó la interfaz para incluir un panel de filtros a la izquierda de la pantalla, similar al que utiliza el rol Informador.
Filtros disponibles: Modalidad, Equipo, Institución destino, Estado del informe (multicheck: Rechazado, Derivado, Completo), Tipo de estudio (Rutina, Urgente), Rango de fechas y búsqueda por datos del paciente (ID, DNI, Nombre, Apellido).
Persistencia: Los filtros que selecciones se mantendrán activos mientras navegues entre pestañas o si salís y volvés a entrar al módulo, siempre que mantengas la misma sesión activa.
Limpiar filtros: Podés restablecer todos los valores rápidamente usando el botón ubicado en el ángulo superior derecho del panel.
Importante: Por defecto, el filtro de estado viene preseleccionado con el valor “Rechazado” para priorizar la atención de estos estudios.
Interconsultas
Feature Flag: HABILITAR_INTERCONSULTA (no aplica a la pantalla de BackOffice de habilitación de UJ para interconsultas, que está siempre visible independientemente del flag)
Roles involucrados: Profesionales médicos (buzón, visualización y respuesta de interconsultas), usuario de BackOffice con permisos de edición de Unidades Jerárquicas
Alcance: Internación y Guardia (episodios activos); la habilitación de Unidades Jerárquicas para interconsultas se configura a nivel Institución desde BackOffice
Habilitación de Unidades Jerárquicas para Interconsultas (BackOffice)
A partir de esta versión, cada Unidad Jerárquica (UJ) de una institución puede marcarse como habilitada o no para ser seleccionada como Destino de una interconsulta, permitiendo controlar qué servicios y sub-unidades del hospital están operativamente disponibles para recibir solicitudes.
Switch “Habilitado para Interconsultas”
En BackOffice → Instalaciones → Instituciones → [Institución] → Unidades Jerárquicas → [UJ], se agrega un switch nuevo entre los campos “Productividad asociada a” y la sección “Unidades jerárquicas hijas”. El cambio se guarda automáticamente al tocar el switch, sin necesidad de entrar en modo edición ni confirmar la acción, igual que el resto de las acciones de esa pantalla (Asociar usuario, Asociar sector, etc.). Aplica a cualquier tipo de UJ, sin restricción por tipo, y la acción es siempre individual (no existe una opción masiva).
Al crear una UJ nueva, el switch no forma parte del formulario de alta: el sistema redirige a la pantalla de detalle de la UJ recién creada, donde el switch está disponible en estado Deshabilitado por defecto.
📝 Todas las UJ existentes al momento de liberar esta funcionalidad quedan en Deshabilitado. Cada institución debe habilitar manualmente, UJ por UJ, las que quiera dejar disponibles como Destino de interconsulta. Lo mismo aplica a las UJ que se creen de ahora en más.
⚠️ Una UJ no puede deshabilitarse si tiene al menos una interconsulta en estado Pendiente o Aceptada dirigida a ella. El sistema bloquea la acción en ese caso.
Columna “Interconsultas” en el listado de UJ
La grilla de listado de UJ de una institución incorpora una columna nueva, “Interconsultas”, que muestra el estado (Habilitado/Deshabilitado) de cada UJ de forma solo informativa; el cambio de estado se realiza exclusivamente desde el detalle de la UJ.
Impacto en el campo Destino al crear una Interconsulta
El campo Destino, que filtraba únicamente por UJ de tipo Servicio (y sus hijas), deja de aplicar ese filtro por tipo: a partir de esta versión filtra únicamente por habilitación. Se muestran todas las UJ marcadas “Habilitado para Interconsultas”; sus UJ hijas se muestran solo si también están individualmente habilitadas. El campo Origen no se modifica: sigue mostrando todas las UJ del profesional logueado, habilitadas o no.
⚠️ El feature flag HABILITAR_INTERCONSULTA no controla esta pantalla de BackOffice: el switch y la columna están siempre visibles, incluso si la institución no tiene el módulo de Interconsultas activo. Esto permite pre-configurar las UJ antes de activar el módulo.
Ejemplo: Mariano Fuentes, administrador de BackOffice del Hospital Demo Mendoza, habilita el switch de “Cardiología” y de su UJ hija “Cardiología – Consultorio 1”, dejando deshabilitada “Cardiología – Consultorio 2”. Al crear una interconsulta, el Dr. Ledesma ve “Cardiología” y “Cardiología – Consultorio 1” como opciones de Destino, pero no “Cardiología – Consultorio 2”. Cuando esa UJ ya tiene una interconsulta Aceptada asociada, Mariano ya no puede deshabilitarla hasta que se resuelva.
Visualización de interconsultas ampliada a la familia de Unidades Jerárquicas del profesional
A partir de esta versión, el Buzón de Interconsultas Recibidas deja de limitarse a la UJ exacta del profesional: se amplía a su “familia” de Unidades Jerárquicas, definida como la propia UJ, sus UJ hermanas (que comparten el mismo Servicio inmediato superior), sus UJ ancestras (padre, abuelo, etc., sin límite de niveles) y sus UJ descendientes (hijas, nietas, etc., sin límite de niveles). No se incluyen los “tíos” (hermanos de un ancestro) ni los descendientes de estos.
Si el profesional pertenece a más de una UJ sin relación entre sí, ve la unión de las familias calculadas para cada una.
El switch de habilitación corta la cadena de parentesco
El switch “Habilitado para Interconsultas” participa en este cálculo: al recorrer ancestros, descendientes o hermanos, si se encuentra una UJ deshabilitada en el camino, la búsqueda se detiene ahí, aunque haya UJ habilitadas más allá de ese punto. Para llegar a un hermano es necesario “pasar” por el padre inmediato compartido: si ese padre está deshabilitado, ningún hermano resulta visible por esa vía, sin importar el estado propio de cada uno; si el padre está habilitado pero el hermano en sí está deshabilitado, solo ese hermano puntual queda excluido.
📝 Cuando una UJ tiene más de un padre inmediato, el cálculo se realiza de forma independiente por cada rama: la visibilidad de ancestros y hermanos a través de un padre depende únicamente del estado de habilitación de esa rama en particular, sin que el estado de otro padre la afecte.
Acciones disponibles sobre interconsultas de UJ familiares
Dentro de la familia visible, cualquier profesional puede Aceptar, Rechazar, Finalizar e “Ir a HC” sobre una interconsulta, sin importar si pertenece exactamente a la UJ Destino o a una UJ relacionada, respetando siempre el corte de cadena por deshabilitación.
Ejemplo (hermanas): el Dr. Franco Ledesma pertenece a “Alergia”, hermana de “Reumatología” (ambas hijas de “Servicio de Inmunología”, que está Habilitado). Al recibirse una interconsulta con Destino “Reumatología” para el paciente Ramón Aguirre, el Dr. Ledesma la ve en su buzón y puede Aceptarla, Rechazarla, Finalizarla o Ir a HC, aunque no pertenezca a “Reumatología”.
Ejemplo (corte de cadena): si “Servicio de Inmunología” (el padre compartido de “Alergia” y “Reumatología”) se deshabilita, el Dr. Ledesma deja de ver las interconsultas dirigidas a “Reumatología”, porque el camino hacia cualquier hermano se corta en ese padre, sin importar que “Reumatología” en sí siga habilitada.
Ejemplo (múltiples padres): si “Alergia” tiene dos UJ padre — “Servicio de Inmunología” (Habilitado) y “Servicio de Alergología Central” (Deshabilitado) —, el Dr. Ledesma sigue viendo la familia que desciende de “Servicio de Inmunología” con normalidad; solo se corta la rama hacia “Servicio de Alergología Central”.
Respuesta de interconsultas ampliada a la familia de Unidades Jerárquicas del profesional
A partir de esta versión, la acción de Responder una interconsulta (asociar una nota de evolución) deja de estar restringida a profesionales de la UJ Destino exacta: se habilita para toda la familia de UJ del profesional, con el mismo cálculo de parentesco (self, hermanas, ancestras y descendientes, respetando el corte de cadena por deshabilitación) ya utilizado para visualizar y gestionar interconsultas en el Buzón.
Al crear una Nota de Evolución, el sistema detecta automáticamente si el paciente tiene alguna interconsulta Pendiente o Aceptada cuyo Destino pertenezca a la familia de UJ del profesional logueado. Si hay coincidencia, se muestra el modal de asociación; si no, la nota se abre normalmente.
Estado de la interconsulta | Comportamiento al asociar |
Pendiente | El profesional puede presionar “Aceptar y asociar a interconsulta”: la interconsulta pasa a Aceptada, se asocia la nota y se abre la nota de evolución |
Aceptada | Cualquier profesional de la familia puede asociar una nueva nota de seguimiento mediante el modal “Asociar a interconsulta” (sin acción de “Aceptar”) |
Si el profesional elige no asociar, la nota se abre sin vincularse a ninguna interconsulta y el estado de esta no se modifica. Cuando existen varias interconsultas candidatas, se mantienen los modales secuenciales ya existentes (uno por interconsulta, sin agrupar). El registro en el historial de acciones no cambia: continúa mostrando únicamente nombre y fecha del profesional, sin agregar su UJ como dato adicional.
Ejemplo: la interconsulta de “Reumatología” del paciente Ramón Aguirre está Pendiente. El Dr. Ledesma, de “Alergia” (hermana de “Reumatología”), crea una nota de evolución y el sistema le muestra el modal de asociación. Al presionar “Aceptar y asociar”, la interconsulta pasa a Aceptada y su nota queda vinculada, sin necesidad de pertenecer a “Reumatología”.
Ejemplo (seguimiento): esa misma interconsulta, ya Aceptada, recibe una segunda nota de evolución del Dr. Ruiz, de “Servicio de Inmunología” (ancestro de “Reumatología”). El sistema le ofrece asociarla igualmente a la interconsulta existente.
Filtro por Unidades Jerárquicas en el Buzón de Interconsultas
Se incorpora un nuevo filtro al panel de filtros del Buzón de Interconsultas Recibidas: filtrar por una o más Unidades Jerárquicas. Las opciones disponibles se calculan según las UJ a las que el profesional está inscripto y su árbol de parentesco habilitado, con el mismo criterio de familia descripto en “Visualización de interconsultas ampliada a la familia de Unidades Jerárquicas del profesional”.
Cada UJ seleccionada se agrega como una etiqueta visible dentro del filtro, acumulándose con las anteriores; cada una puede quitarse de forma individual sin afectar al resto de la selección.
Ejemplo: el Dr. Ledesma agrega al filtro “Alergia” y luego “Reumatología”; el buzón muestra las interconsultas dirigidas a ambas UJ combinadas. Si quita “Reumatología” del filtro, el listado se actualiza mostrando únicamente las de “Alergia”.
Persistencia de los filtros del Buzón al cambiar de módulo
Se corrigió un comportamiento por el cual, al modificar los filtros del Buzón de Interconsultas (estados, ámbito, fechas, etc.) y navegar a otro módulo del sistema, la configuración aplicada se perdía: al regresar al Buzón, los filtros volvían a su estado inicial (Pendiente y Aceptada seleccionados, resto vacío) y era necesario rehacer la búsqueda.
A partir de esta versión, la selección de filtros persiste al cambiar de módulo: al regresar al Buzón, se mantiene la última configuración utilizada por el profesional.
Ejemplo: el Dr. Fernández filtra el Buzón por Estado = Aceptada y Ámbito = Guardia, y luego navega a la Historia Clínica de un paciente. Al volver al Buzón, encuentra los mismos filtros aplicados, sin necesidad de reconfigurarlos.
Corrección de los datos de ubicación en la interconsulta asociada a una Nota de Evolución
Se corrigieron los datos de ubicación del paciente (Sector, Sala y Cama) que se muestran en la card de la interconsulta asociada dentro del formulario de Nota de Evolución, que no coincidían con los reales según el escenario del paciente:
Escenario | Comportamiento anterior (incorrecto) |
Internación (Sector, Sala y Cama) | El dato de Cama se mostraba en el campo Sala; el campo Cama quedaba vacío |
Guardia con Cama asignada | Mismo problema: el dato de Cama se mostraba en el campo Sala |
Guardia en Shockroom | El Sector se mostraba correctamente, pero el Shockroom no se mostraba (aparecía el campo Sala vacío en su lugar) |
Guardia en Consultorio | El Sector se mostraba correctamente, pero el Consultorio no se mostraba (aparecía el campo Sala vacío en su lugar) |
A partir de esta versión, los datos que muestra la card de la interconsulta asociada coinciden con los que se visualizan en la Historia Clínica del paciente, para los cuatro escenarios.
Turnos y MPI
Obligatoriedad de teléfono y mail en la ficha del paciente
Feature Flag: HABILITAR_OBLIGATORIEDAD_TELEFONO_MAIL en TRUE
Roles involucrados: Administrativo (Empadronamiento).
Alcance: Alta y edición de paciente.
Para mejorar la comunicación con el paciente y la gestión de turnos, se estableció la obligatoriedad de los campos de contacto. El sistema validará que el teléfono tenga un formato correcto y que el mail sea válido antes de permitir guardar la ficha.
Datos del domicilio en la confirmación del turno
Feature flag requerido: HABILITAR_ALERTA_DOMICILIO_CONFIRMACION_TURNO en TRUE
Roles involucrados: Administrativo, Administrativo de UJ, Profesional de la Salud, Especialista Médico, Especialista en Odontología, Enfermero.
Alcance: Módulo de Turnos.
A partir de esta versión, se facilita la actualización de los datos de residencia del paciente durante la gestión de sus turnos. El objetivo es asegurar que la información de domicilio esté completa para procesos de georreferenciación y facturación, sin interrumpir el flujo de atención.
Visualización del domicilio en el turno
Al acceder a los datos de un paciente asociado a un turno, vas a visualizar una nueva sección de Domicilio.
Ingresá al módulo de Turnos y seleccioná una agenda.
Hacé clic sobre un turno asignado para ver el detalle del paciente.
En la vista de datos del paciente, buscá el campo Domicilio. El sistema mostrará la dirección completa registrada (Calle, Número, Localidad, etc.).
Indicador de datos incompletos
Para ayudar al operador a identificar rápidamente qué registros requieren actualización, el sistema aplica las siguientes leyendas:
Situación | Leyenda en el campo Domicilio |
|---|---|
Faltan datos básicos (País, Provincia, Partido o Ciudad) | “Datos incompletos” |
El paciente no tiene ningún dato de domicilio cargado | “Sin información” y “Datos incompletos” |
Edición de datos de domicilio y persistencia en MPI
Podés completar o corregir la información del paciente directamente desde el flujo del turno.
En la vista del turno, seleccioná la opción para editar los datos del paciente.
Se desplegarán los campos de domicilio: País, Provincia, Ciudad, Partido, Calle, Número, Piso, Departamento, Barrio y Código Postal.
Los campos de ubicación geográfica (País, Provincia, Ciudad, Partido) funcionan como selectores para evitar errores de carga.
Una vez completados, hacé clic en Guardar.
Nota: en futuras versiones se agregará esta funcionalidad en los turnos pertenecientes a agendas de prácticas.
Reglas de persistencia (MPI):
El comportamiento del guardado depende de la configuración de otros feature flags del sistema:
Configuración de Feature Flags | Resultado del guardado |
|---|---|
HABILITAR_ALERTA_DOMICILIO… = TRUE y HABILITAR_GUARDADO_INFO_EN_MPI = TRUE | Los datos de teléfono y domicilio se actualizan permanentemente en el Maestro de Pacientes (MPI). |
HABILITAR_ALERTA_DOMICILIO… = FALSE y HABILITAR_GUARDADO_INFO_EN_MPI = TRUE | Solo se actualiza el teléfono en el MPI. |
HABILITAR_GUARDADO_INFO_EN_MPI = FALSE | Los cambios realizados no se guardan en el MPI (solo aplican al contexto del turno). |
Es importante aclarar que en este flujo de edición, ninguno de los campos de domicilio es obligatorio. Esto permite al operador guardar cambios parciales según la información que el paciente pueda brindar en el momento, sin bloquear la continuidad del turno.
Limitación de acceso agendas ambulatorias para roles de salud
Feature Flag: HABILITAR_LIMITAR_AGENDAS_A_ROLES_DE_SALUD_POR_UJ
Roles involucrados: Especialista médico, Especialista en odontología, Enfermero y Profesional de la salud.
Alcance: Solapa Oferta por servicio.
Se limitó la gestión de turnos para usuarios con roles de salud dentro de las agendas ambulatorias. El desarrollo afecta a las agendas visualizadas en las solapa de OFERTA POR SERVICIO en el modulo Turnos.
El FF se muestra por defecto en estado false. En caso de cambiar el estado a true se limita la oferta de turnos para los roles involucrados.
Los usuarios solo tendrán acceso a agendas ambulatorias que cuenten con la misma unidad jerárquica a la que está asociado. Se considera a un usuario asociado a una unidad jerárquica cuando este se encuentre dentro de la tabla de la sección “Usuarios” en el detalle de la unidad jerárquica.
Luego, dentro de la solapa oferta por servicio, en el campo “Servicio / Unidad jerárquica” solo se listan las unidades jerárquicas que están asociadas a agendas en donde la unidad jerárquica coincide con las unidades jerárquicas a las que está asociado el usuario logueado.
De la misma manera, dentro del campo “Alias” solo se listan los alias que están asociados a agendas en donde la unidad jerárquica coincide con las unidades jerárquicas a las que está asociado el usuario logueado.
A su vez, dentro del campo “Modalidad” solo se listan las modalidades que están asociadas a agendas en donde la unidad jerárquica coincide con las unidades jerárquicas a las que está asociado el usuario logueado.
Finalmente, dentro del campo “Equipo” solo se listan los equipos que están asociados a agendas en donde la unidad jerárquica coincide con las unidades jerárquicas a las que está asociado el usuario logueado.
Al mismo tiempo esta reestricción sucede dentro del desplegable Seleccione una agenda.
Reservas
Cambios en estados de validación de ordenes y nuevo orden en dashboard de reservas
Roles involucrados: Administrativo y Administrativo de UJ
Alcance: Solapa Reservas
Se cambiaron los nombres de los estados de validación de las órdenes relacionadas a las reservas de turnos así como el orden en que se listan.
En primer lugar se reemplazó el label “Orden pendiente” por el label “Orden pendiente de validación”. Por otro lado, se reemplazó el label “No requiere” por el label “No requiere orden”.
Finalmente se definió un nuevo criterio de ordenamiento dentro del dashboard. A partir de ahora, las reservas se listan en orden cronológico de la más próxima a la más lejana teniendo en cuenta el día de la fecha.
Nuevos filtros en dashboard de reservas
Roles involucrados: Administrativo y Administrativo de UJ
Alcance: Solapa Reservas
Se agregaron filtros relacionados a:
La validación de la orden
La especialidad
Por un lado, se agregaron 3 filtros multicheck debajo del título “Estado de orden” con los nombre de:
Orden pendiente de validación
No requiere orden
Orden validada
Cuando todos los filtros de estado de orden están desmarcados no se tendrá en cuenta el filtrado. Al marcar alguna de las opciones se filtrarán las reservas que cuenten con el o los estados de estado de orden seleccionados.
Por otro lado, se agregó un filtro de tipo typeahead bajo el título “Especialidad”. Dentro del filtro se listan todas las especialidades activas que corresponden a agendas activas que tienen habilitada la posibilidad de asignar reservas dentro de las mismas.
Historial de reservas canceladas
Roles involucrados: Administrativo, Administrativo de UJ, Profesional de la salud, Especialista médico, Especialista en odontología.
Alcance: Perfil del paciente.
Se agregó un acceso para consultar todas las reservas que fueron canceladas para un paciente, permitiendo conocer el motivo y quién realizó la acción.
En el perfil del paciente, dentro de la tarjeta Reservas online, se visualiza un botón de Ver canceladas.
En caso de hacer clic se abre un modal con el historial detallado, incluyendo:
-
Fecha y hora original de la reserva.
Profesional, institución destino y partido destino.
Especialidad, práctica y unidad jerarquía.
Estado “CANCELADA”.
Motivo de cancelación.
Usuario que canceló y fecha y hora de la acción.
Gestión de Accesos y Referencias
Cambios en el cierre administrativo de referencias
Roles involucrados: Gestores de acceso (Local, Regional, Institucional y de Dominio).
Alcance: Gestión de Accesos / Turnos – Solicitudes.
Se modificó el flujo de cierre administrativo para que sea más preciso y tenga impacto directo en la Historia Clínica.
Al hacer clic en el botón cierre administrativo de referencia se reemplazó el campo de texto libre donde se define el motivo del cierre por un selector de campos estructurados con formato desplegable obligatorio. Las opciones de motivos de cierre son:
Solicitud anulada por error en la carga
Cierre por duplicación de solicitud
Error de auditoría.
Solicitud de referencia resuelta por circuito externo
El paciente consiguió un turno en otra institución por fuera de la red.
Cierre por falta de re contacto con el paciente
Cierre de referencia por paciente fallecido
Otro
Al mismo tiempo, al cerrar una referencia administrativamente, el motivo seleccionado se visualiza debajo del label de “Cierre administrativo” y el estado de atención pasa a tener el valor ANULADO.
A continuación se listan los cierre con su resultado esperado:
Motivo de cierre | Comportamiento esperado |
Solicitud anulada por error en la carga |
|
Cierre por duplicación de solicitud |
|
Error de auditoría. |
|
Solicitud de referencia resuelta por circuito externo |
|
El paciente consiguió un turno en otra institución por fuera de la red. |
|
Cierre por falta de re contacto con el paciente |
|
Cierre de referencia por paciente fallecido |
|
Otro |
|
Otra cosa que se agregó fue la opción de Anulado al filtro actual de Estado de turno / atención. En caso de seleccionar este filtro se filtran todas las solicitudes de referencia que fueron cerradas administrativamente y cuentan con su estado de turno / atención con el valor Anulado.
Filtro de última modificación
Roles involucrados: Gestores de acceso (Local, Regional, Institucional y de Dominio), Especialista médico, Especialista en odontología, Profesional de la salud, Enfermero, Administrativo, Administrativo de UJ
Alcance: Gestión de Accesos / Turnos – Solicitudes.
Se agregó un nuevo criterio de fecha a los filtros de criterios de fechas actuales dentro de los dashboard de solicitudes de referencia relacionado a cualquier modificación que haya tenido la solicitud de referencia en el rango de fechas definido.
En caso de filtrar por este criterio se tiene en cuenta la fecha cuando se realizó cualquier modificación a la solicitud. Dentro de estos cambios se consideran:
Cambio de auditoria de origen
Cambios en aprobación de destino
Cambios en estado de turno / atención
Cambios en estado de referencia
Cambios en nivel de derivación
Cambios en red a la que se deriva
Nueva observación
Cambios en institución destino
Cambios en criterio de priorización
Cambios en documentos adjuntos
Creación de US
El orden de resultados es desde la solicitud de referencia con alguno de estos cambios mas recientes hasta los mas antiguos.
Asignación de otro responsable a solicitud de referencia
Roles involucrados: Gestores de acceso (Local, Regional, Institucional y de Dominio).
Alcance: Gestión de Accesos / Turnos – Solicitudes.
A partir de esta release, se permite asociar otros usuarios a las distintas solicitudes de referencia generadas dentro de HSI. Es importante mencionar que dentro del listado Solicitadas en el modulo Turnos no se incluye la funcionalidad de ver o asignar responsable para evitar sobre información innecesaria.
Dentro de la sección de Responsable cuando aun no se asignó un usuario como responsable se agrega un botón de acciones secundarias que desplegará la opción Asignar otro responsable.
Haciendo clic sobre el botón de asignar otro responsable se muestra un pop up con el título Asignar responsable para realizar la acción. Dentro del pop up se visualiza un campo de tipo type ahead con el placeholder Sin responsable.
Dependiendo del rol y la institución o la red a la que pertenece el usuario logueado se listan distintos usuarios.
Rol Gestor institucional
Para este rol solo se listan otros usuarios con el rol Gestor de acceso institucional que pertenezcan a la misma institución.
Rol Gestor local
Para este rol solo se listan otros usuarios con el rol Gestor de acceso local que pertenezcan a la misma red local.
Rol Gestor regional
Para este rol solo se listan otros usuarios con el rol Gestor de acceso regional que pertenezcan a la misma red o redes regionales.
Rol Gestor de dominio
Para este rol solo se listan otros usuarios con el rol Gestor de acceso de dominio.
Una vez asignado un responsable se reemplaza el botón de Asignar a mi por un botón de Cambiar que vuelve a mostrar el pop up de asignación en caso de hacer clic sobre el mismo. Solo puede estar asignado en simultaneo un usuario responsable para una misma solicitud de referencia.
En caso de hacer clic sobre el botón Cambiar se vuelve a mostrar el pop up de asignación de responsable. Al hacer clic el campo de selección de responsable viene pre-cargado con el nombre del responsable actual.
Cabe mencionar que se puede cambiar el responsable todas las veces que se considere necesaria mientras el usuario tenga habilitada la acción.
Acceso a la Lista de Trabajo de Farmacia para el rol Personal de Farmacia
Toda la funcionalidad descrita en esta sección requiere los siguientes Feature Flags activos:
Feature Flag HABILITAR_MODULO_INTERNACION en TRUE
Feature Flag HABILITAR_LISTA_TRABAJO_FARMACIA en TRUE
Roles involucrados: Personal de Farmacia.
Alcance: esta funcionalidad aplica a pacientes en ámbito de internación, a los que se accede mediante el módulo Lista de trabajo – Farmacia. El acceso a la Historia Clínica de pacientes de internación, guardia y ambulatorio no se ve afectado por este desarrollo.
Acceso al módulo Lista de trabajo – Farmacia
La opción “Farmacia” del menú principal se visualiza también cuando el usuario tiene asignado el rol Personal de Farmacia, permitiéndole acceder al módulo Lista de trabajo – Farmacia.
Con HABILITAR_MODULO_INTERNACION en TRUE y HABILITAR_LISTA_TRABAJO_FARMACIA en TRUE, el usuario con rol Personal de Farmacia visualiza la opción “Farmacia” y accede al módulo.
Si alguno de los Feature Flags está en FALSE, la opción “Farmacia” no se visualiza para el rol Personal de Farmacia.
Los usuarios sin los roles Farmacéutico o Personal de Farmacia no visualizan ni acceden al módulo.
Comportamiento de la lista de trabajo
El rol Personal de Farmacia visualiza y opera la lista de trabajo con el mismo comportamiento definido para el rol Farmacéutico: mismos criterios de inclusión/exclusión de pacientes y mismos contadores de estados de las indicaciones.
Alcance del rol Personal de Farmacia (sin cambios respecto del comportamiento actual)
Esta historia solo incorpora el acceso al módulo Lista de trabajo – Farmacia. El resto del comportamiento del rol se mantiene sin cambios:
El rol Personal de Farmacia no puede validar ni intervenir indicaciones: no visualiza el botón “Validar” ni el botón “Intervenir” en la card de indicaciones, acciones exclusivas del rol Farmacéutico.
Sí visualiza el estado de validación farmacéutica de las indicaciones, tanto en pacientes de Internación como de Guardia.
Conserva su acceso actual a la Historia Clínica de pacientes de internación, guardia y ambulatorio con sus acciones pertinentes; esta historia no modifica ni restringe dicho acceso.
Ventana Temporal para la Administración de Tomas de Enfermería
Roles involucrados: Enfermero.
Alcance: esta funcionalidad aplica a pacientes en ámbito de internación o de guardia con al menos una indicación asociada. El rol Enfermero es quien administra las tomas desde la pestaña Enfermería; el resto de los roles puede acceder y visualizar las tomas registradas sin cambios.
Administración de tomas futuras dentro de la ventana configurada
Cuando la fecha y hora programada de una toma es posterior a la fecha y hora actual, el sistema permite su administración únicamente cuando la diferencia se encuentra dentro de la cantidad de horas configurada en la propiedad MAX_FUTURE_HOURS_FOR_DOSE_ADMINISTRATION (unidad: horas; valor: número entero mayor a 0; valor por defecto: 6).
El sistema calcula el límite permitido como la hora actual más el valor configurado en la propiedad. Si la toma programada se encuentra dentro de ese límite, se permite la administración; caso contrario, no se permite. La validación considera la fecha y hora completas de la toma, independientemente de que la administración ocurra el mismo día o en días distintos.
Ejemplo con la propiedad configurada en 3 horas:
Toma Programada | Hora Actual | Diferencia | ¿Permite Administrar? |
|---|---|---|---|
02/06 17:00 hs | 02/06 13:00 hs | Faltan 4 hs | No |
02/06 17:00 hs | 02/06 15:00 hs | Faltan 2 hs | Sí |
03/06 01:00 hs | 02/06 23:30 hs | Faltan 1:30 hs | Sí |
Administración de tomas pasadas dentro de la ventana configurada
Cuando la fecha y hora programada de una toma es anterior a la fecha y hora actual, el sistema permite su administración únicamente cuando la diferencia se encuentra dentro de la cantidad de horas configurada en la propiedad MAX_PREVIOUS_HOURS_FOR_DOSE_ADMINISTRATION (unidad: horas; valor: número entero mayor a 0; valor por defecto: 6).
El sistema calcula el límite permitido como la hora actual menos el valor configurado en la propiedad. Si la toma programada se encuentra dentro de ese límite, se permite la administración; caso contrario, no se permite. La validación considera la fecha y hora completas de la toma, independientemente de que la administración ocurra el mismo día o en días distintos.
Ejemplo con la propiedad configurada en 3 horas:
Toma Programada | Hora Actual | Diferencia | ¿Permite Administrar? |
|---|---|---|---|
01/06 23:30 hs | 02/06 01:00 hs | Pasaron 1:30 hs | Sí |
02/06 05:00 hs | 02/06 17:00 hs | Pasaron 12 hs | No |
02/06 05:00 hs | 02/06 06:00 hs | Pasó 1 hs | Sí |
Comportamiento cuando no se permite registrar la toma
Cuando la toma se encuentra fuera de la ventana temporal permitida, el sistema indica que no es posible registrar la administración griseando el botón correspondiente. Al pasar el mouse por el botón grisado, se muestra el tooltip “El tiempo para registrar caducó”.
Hora de Creación y Matrícula del Prescriptor en el Modal Ver Detalles de la Indicación
Toda la funcionalidad descrita en esta sección requiere los siguientes Feature Flags activos:
Feature Flag HABILITAR_MEJORAS_INDICACIONES_EN_DESARROLLO en TRUE (por defecto, el valor de este Feature Flag es siempre FALSE)
Roles involucrados: Especialista médico, Especialista en odontología, Enfermero, Farmacéutico, Personal de Farmacia.
Alcance: esta funcionalidad aplica a pacientes en ámbito de internación o de guardia con al menos una indicación registrada. Se accede mediante el modal “Ver detalles” de la indicación.
Visualización de hora de creación y matrícula del prescriptor
Al hacer clic en “Ver detalles” de una indicación, en la información de creación el sistema muestra:
Nombre y apellido del prescriptor, como actualmente (considerando nombre autopercibido si está registrado), acompañado de la/s matrícula/s del prescriptor (valor nuevo). Si el profesional posee más de una matrícula, se muestran separadas por comas, con el mismo formato definido para el campo Médico de los modales Validar e Intervenir indicación.
Fecha de creación, como actualmente, acompañada de la hora de creación de la indicación (valor nuevo), en formato HH:mm hs.
Nota: si el prescriptor no posee matrícula registrada, esta no se agrega a la información mostrada.
Secciones del modal sin cambios
El resto de las secciones y datos del modal “Ver detalles” continúan funcionando y visualizándose como actualmente; el cambio se limita a la información de creación de la indicación.
Compatibilidad con indicaciones previas
Para indicaciones registradas antes de esta funcionalidad, el modal muestra la hora de creación ya persistida junto a la fecha de prescripción.
La/s matrícula/s mostrada corresponde al dato registrado del profesional prescriptor.
Visualización de Indicaciones de Tipo Mezcla en las Cards de Indicaciones y de Tomas de Enfermería
Toda la funcionalidad descrita en esta sección requiere los siguientes Feature Flags activos:
Feature Flag HABILITAR_MEJORAS_INDICACIONES_EN_DESARROLLO en TRUE (por defecto, el valor de este Feature Flag es siempre FALSE)
Roles involucrados: todos los roles con acceso a la pestaña Indicaciones de un paciente en guardia o internación.
Alcance: esta funcionalidad aplica a pacientes en guardia o internación con al menos una indicación de fármaco confirmada. Se visualiza en la pestaña Indicaciones y en la pestaña Enfermería.
Visualización del dato de mezcla en las cards de indicaciones de fármacos
En la pestaña Indicaciones (guardia e internación), en cada card de indicación de fármaco se visualiza, debajo de donde se informa el nombre del fármaco, un ícono indicando que la indicación es una mezcla, cuando la indicación fue prescripta con el checkbox “Es una mezcla” habilitado.
Casos en los que NO se muestra el ícono:
Cuando la indicación fue prescripta con el checkbox “Es una mezcla” deshabilitado, no se muestra ningún ícono.
El detalle de la mezcla (fármacos asociados y dosis) continúa visualizándose en el modal “Ver detalles” sin cambios.
Visualización del dato de mezcla en las cards de tomas de Enfermería
En la pestaña Enfermería, en cada card de toma correspondiente a una indicación de fármaco se visualiza el mismo ícono definido para las cards de indicaciones (según corresponda si “Es una mezcla” está habilitado o no), debajo de donde se informa el nombre del fármaco, con el mismo criterio de determinación del valor.
Compatibilidad con indicaciones previas
La visualización del ícono aplica también a las indicaciones existentes creadas antes de este desarrollo:
Indicaciones creadas con el checkbox “Es una mezcla” habilitado: muestran el valor que se seleccionó para “Es una Mezcla”.
Indicaciones históricas creadas con la funcionalidad “Diluyente”: muestran el valor que se seleccionó para “Diluyente”, dado que el sistema ya las identifica como mezclas.
El resto de las indicaciones de fármacos muestran “Es una mezcla: No”.
Nota: no se modifica ni se pierde información de indicaciones históricas; el cambio es exclusivamente de visualización.
Detalle de la Mezcla en los Modales de Validación e Intervención Farmacéutica
Toda la funcionalidad descrita en esta sección requiere los siguientes Feature Flags activos:
Feature Flag HABILITAR_LISTA_TRABAJO_FARMACIA en TRUE
Feature Flag HABILITAR_MEJORAS_INDICACIONES_EN_DESARROLLO en TRUE
Roles involucrados: Farmacéutico.
Alcance: esta funcionalidad aplica a pacientes en guardia o internación con al menos una indicación de tipo Mezcla (con fármacos asociados) en estado de validación farmacéutica “Pendiente de validación”.
Visualización del detalle de la mezcla en el modal de validación
Cuando el Farmacéutico abre el modal “Validar indicación” sobre una indicación de tipo Mezcla, el modal incluye el bloque “Detalle de la Mezcla”, a continuación de los datos de la indicación y antes del campo Observaciones.
Si la indicación no es una mezcla, el modal se visualiza como actualmente, sin el bloque.
El resto de los campos y las acciones del modal se mantienen sin cambios.
Visualización del detalle de la mezcla en el modal de intervención
Cuando el Farmacéutico abre el modal “Intervenir indicación” sobre una indicación de tipo Mezcla, el modal incluye el mismo bloque “Detalle de la Mezcla”, a continuación de los datos de la indicación y antes del campo Motivo.
Si la indicación no es una mezcla, el modal se visualiza como actualmente, sin el bloque.
El resto de los campos y las acciones del modal se mantienen sin cambios.
Compatibilidad con indicaciones previas
Para indicaciones registradas con la funcionalidad anterior “Diluyente” que tengan fármacos asociados, el bloque “Detalle de la Mezcla” se muestra en ambos modales con los fármacos y dosis registrados. No se modifica ni se pierde información de indicaciones históricas.
Integraciones y Seguridad
Control de casos duplicados en SNVS (SISA)
Roles involucrados: Especialista médico, Enfermero.
Alcance: Reporte epidemiológico.
Se mejoró la integración con SISA para evitar la duplicación de notificaciones. Por un lado, si un profesional intenta reportar un diagnóstico que ya fue notificado recientemente para ese paciente, el sistema muestra un aviso indicando que el evento ya existe y proporciona el ID de evento original para su seguimiento en el portal de SISA. Por otro lado se mejoraron los mensajes reflejados al usuario para que entienda mejor las acciones dentro del sistema.
Tener en cuenta ws.sisa.snvs.enabled=true y los FF:
HABILITAR_TRIAGE_PARA_ADMINISTRATIVO=true
HABILITAR_REPORTE_EPIDEMIOLOGICO=true
Al cargar un diagnóstico asociado a un grupo epidemiológico se visualiza el siguiente mensaje:
“El diagnóstico (diagnóstico seleccionado) requiere notificación epidemiológica. Al reportar caso, se generará la apertura de la ficha inicial en el Sistema Nacional de Vigilancia de la Salud (SNVS). La información clínica y de laboratorio complementaria no se migra automáticamente y deberá completarse en dicho sistema”.
Al mismo tiempo, al reportar el caso con éxito se modificó el mensaje y se visualiza el siguiente:
“El diagnóstico (diagnóstico seleccionado) fue reportado al SNVS con éxito.
Seguido se visualiza la leyenda “ID de evento: XXXXXX”
“Esta acción realiza la apertura inicial de la ficha del caso. Para incluir la información clínica, epidemiológica o de laboratorio se debe ingresar al SNVS.”
Finalmente, en caso de que se intente reportar un caso de un mismo diagnóstico para un mismo paciente, si el sistema SISA devuelve la información que todavía no pasó el tiempo suficiente para que se considere como un caso nuevo, se muestra al usuario un pop up con el título:
El diagnóstico (diagnóstico seleccionado) ya fue registrado
Seguido a esto se muestra el mensaje:
“El evento ya cuenta con un registro previo reciente en el SNVS. Podés acceder a la notificación original utilizando el ID de evento.
ID de evento: XXXXXX.” → Se incluye el botón actual para copiar el ID.
Extensión del servicio de pedidos de laboratorio: soporte para órdenes transcriptas
El servicio de consulta de pedidos de laboratorio (por ejemplo GET /fhir/ServiceRequest?identifier={idDominio-idOrden}&subject={patientIdentificationNumber}) utilizado por las integraciones con los laboratorios (LIS) ahora también reconoce correctamente las órdenes transcriptas —es decir, aquellas emitidas fuera de HSI y cargadas manualmente en el sistema—.
Dado que en este tipo de órdenes solo se cuenta con el nombre del profesional solicitante y de la institución de origen (y no con sus registros completos), la consulta del pedido informará únicamente esos nombres, sin hacer referencia a los recursos de profesional (Practitioner) ni de institución (Organization) como sí ocurre para las órdenes generadas nativamente en HSI.
Esto permite que el circuito completo de carga de resultados (subida del informe en PDF y carga de resultados) funcione de la misma manera que para las órdenes generadas nativamente en HSI, sin necesidad de tratamientos especiales por parte del laboratorio.