Release 2.26

by | Ago 2, 2024 | Releases

En esta nueva release se trabajaron las siguientes funcionalidades:

Resultados de procedimientos

Consulta ambulatoria – carga de procedimientos sin resultados

A partir de ahora, para los roles de especialista médico, especialista en odontología y enfermero se puede cargar un procedimiento durante una consulta ambulatoria, el cual queda reflejado también dentro de la solapa Estudios.

Luego de que el usuario haga click sobre el botón  “+ Agregar procedimiento” dentro del desplegable “Procedimientos”, se muestra un popup con formato stepper de 2 pasos. En el primer paso, el usuario deberá cargar el procedimiento, la categoría del procedimiento y el problema asociado. Estos datos son necesarios para poder generar la orden asociada al procedimiento.

Luego de completar los campos, el usuario hace click sobre el botón “Siguiente”. A partir de esto, se muestra al usuario el segundo paso del stepper donde debe seleccionar cual es la modalidad de la carga de los resultados. En este paso, debe seleccionar el radiobutton con la opción “No requiere carga de resultados” debajo del título “Resultados de estudio”.

Una vez seleccionado el radiobutton, el usuario hace click sobre el botón “Agregar procedimiento”. Esto muestra la carga del procedimiento como se visualiza en la actualidad.

 

Finalmente, luego de la confirmación de la consulta, se crea la orden y el procedimiento correspondiente dentro de la solapa “Estudios” con el estado del estudio “COMPLETADO”.



Consulta ambulatoria – carga de procedimientos con resultados pendientes

A partir de este release, para los roles de especialista médico, especialista en odontología y enfermero, también se puede cargar un procedimiento durante una consulta ambulatoria y que quede la carga de sus resultados como “PENDIENTE”.

Al igual que el caso anterior, luego de que el usuario haga click sobre el botón  “+ Agregar procedimiento” dentro del desplegable “Procedimientos”, se muestra un popup con formato stepper de 2 pasos. En el primer paso, el usuario deberá cargar el procedimiento, la categoría del procedimiento y el problema asociado. Estos datos son necesarios para poder generar la orden asociada al procedimiento.


Para este caso, a la hora de seleccionar la modalidad de la carga de los resultados, se debe seleccionar el radiobutton con la opción “Los resultados quedarán pendientes de carga” debajo del título “Resultados de estudio”.

Una vez seleccionado el radiobutton, el usuario hace click sobre el botón “Agregar procedimiento”. Esto muestra la carga del procedimiento como se visualiza en la actualidad. 

Para este caso, luego de confirmar la consulta, se crea la orden y el procedimiento correspondiente dentro de la solapa “Estudios” pero con el estado del estudio en “PENDIENTE” y el botón de “Completar” disponible para cargar los resultados correspondientes. De esta manera, se podrá realizar la carga de resultados cuando sea necesario.

Reportes

Reportes nominales

Todo usuario con acceso a los reportes puede, desde ahora, descargar fácilmente un reporte si ya lo generó anteriormente, mejorando así la eficiencia y la experiencia general de uso.

Se incorporó una pantalla para seleccionar que tipo de reporte se desea descargar, estos se dividen en los que se obtienen mediante cubejs y los reportes de tipo mensual.

En particular, para los reportes de Hoja 2, Detalle Nominal de Turnos y Reporte detalle nominal de atenciones de guardia, al seleccionar un reporte con ciertos parámetros, la primera vez aparece esta pantalla:

Este mensaje significa que el reporte se está generando sin bloqueo de aplicación. El usuario puede hacer otras actividades en HSI mientras el reporte se genera y luego volver a ver los resultados.

Cuando termina de generarse:

Cuando se selecciona un reporte con parámetros ya seleccionados en otra oportunidad, independientemente del usuario que lo generó por primera vez:

Para este caso, se puede volver a generar el reporte o descargar el ya generado con las mismas condiciones.

Mejora de performance del reporte nominal de guardia

Se analizó la consulta sql utilizada para recuperar la información a volcar en el reporte para buscar la forma de optimizarla. Se realizaron mejoras de performance.

Guardia

Editar episodio de guardia desde el dashboard

Se añadió la acción de “Editar episodio” para los roles administrativo, enfermero, especialista médico, especialista en odontología y profesional de la salud directamente desde el dashboard del listado de pacientes en la guardia.

Esta funcionalidad actualmente existe y no se modifica su funcionamiento. Lo único a mencionar es que una vez que el usuario es redirigido a la interfaz de editar el episodio, si este hace click sobre el botón VOLVER o sobre CONFIRMAR es redirigido al dashboard de guardia.

Esta acción no impacta en el estado de atención del paciente, es decir, el estado de atención del paciente se mantendrá en su estado actual sin importar las veces que se edite el episodio.

Colores del nivel de triage

A partir de ahora, se modificaron los labels de niveles de triage a la hora definir uno. Luego de iniciar un episodio, cuando el usuario debe seleccionar el nivel de triage en cuestión, se muestra sobre el desplegable el nivel de triage junto con su color correspondiente.

Del mismo modo, en caso de que un usuario defina un nuevo triage, también se visualiza esta modificación dentro del desplegable. 

Cabe mencionar que este nuevo label se ve reflejado en todas las interfaces que lo contienen. Estas son:

  • Dashboard de guardia
  • Card de resumen de guardia
  • Histórico de evoluciones de guardia


Turnos

Búsqueda de turnos en Oferta por institución

Como usuario del sistema con rol administrativo se desea buscar un turno en la oferta institucional que hay, al hacer uso del filtro de especialidad se mostraba el alias de la agenda. La mejora consiste en modificar el filtro solo mostrando lo que es especialidad y dividir en un nuevo que sea por alias.

Se modificó el filtro de la siguiente manera: 

  • Especialidad: solo trae agendas con una especialidad asociada, debido a que es un campo obligatorio, siempre trae datos.
  • Alias de la agenda: trae las agendas con alias que se encuentran asociada a la especialidad filtrada anteriormente

Dicho cambio de filtro se aplicó tanto para agendas con tipo de atención “Consulta“como de “Práctica/Procedimiento“

Cuando se trata de una búsqueda de turnos de tipo Consulta el filtro especialidad es de carácter obligatorio y dejando el de alias como opcional. Pero cuando estamos buscando en agendas de tipo Práctica/Procedimiento el campo obligatorio es el de prácticas, dejando opcional el de especialidad y alias. Pero la funcionalidad sigue manteniendo la de tipo consulta, es decir, si se ingresa una especialidad se puede elegir un alias, no viceversa.

Diagnóstico por imágenes

Fecha y hora del turno dentro de la sección Estudios en la HC del paciente

Se agregó la fecha y hora del turno, siempre que exista uno, en la sección “Estudios” dentro de la HC del paciente. Cuando un usuario con acceso a la HC del paciente ingrese a esta sección, visualiza en cada fila un label con la leyenda Turno y a continuación la fecha y hora del turno en cuestión. Esto contempla los 3 tipos de órdenes posibles (sin orden, orden transcripta u orden HSI).

Especialista médico/profesional de la salud/odontólogo pueden ver estudio local

  • Cuando desde backoffice un PACS tiene la URL del visualizador local, se debe ver en la app el botón “Ver estudio local”
  • En el caso de no tener seteada la URL mencionada, no debe verse ese botón sino el “Ver estudio” que busca la imagen almacenada en el PACS CENTRAL

Cuando un usuario con rol de especialista médico ingresa a la sección “Estudios” dentro de la historia clínica de un paciente visualiza un nuevo botón de “VER ESTUDIO LOCAL” siempre y cuando el campo “url del visualizador local” ubicado en el backoffice esté completo”. Se agregó el botón como un elemento adicional en la fila del estudio de imágenes correspondiente. Esto contempla los 3 tipos de órdenes posibles (sin orden, orden transcripta u orden HSI).

Con respecto al botón, al hacer clic en el botón “Ver estudio local”, se abre en una nueva pestaña, la url definida en el campo “url visualizador local” dentro del backoffice. 

La url declarada en el backoffice puede tener las siguientes sintaxis:

En caso de tener la primera sintaxis, HSI reemplaza {dni} por el DNI del paciente en el que está ubicado el usuario. Ejemplo: https://10.175.37.35/?mrn=12032823

Si estamos en el caso de la segunda sintaxis, HSI no reemplaza nada, solo abre la pestaña con la url definida.

Técnico puede ver estudio local

Al igual que el caso anterior, cuando un usuario con rol técnico de imágenes ingresa al listado de trabajo visualiza un nuevo botón de “VER ESTUDIO LOCAL” siempre y cuando el el campo “url del visualizador local” ubicado en el backoffice esté completo”. Esto contempla los 3 tipos de órdenes posibles (sin orden, orden transcripta u orden HSI).

Con respecto al botón, al hacer clic en el botón “Ver estudio local”, se abre en una nueva pestaña, la url definida en el campo “url visualizador local” dentro del backoffice. La url declarada en el backoffice puede tener las siguientes sintaxis:

En caso de tener la primera sintaxis, HSI reemplaza {dni} por el DNI del paciente en el que está ubicado el usuario. Ejemplo: https://10.175.37.35/?mrn=12032823

Si estamos en el caso de la segunda sintaxis, HSI no reemplaza nada, solo abre la pestaña con la url definida.

Informador puede ver estudio local

Al igual que los casos anteriores, si se dan las condiciones, el informador tambien podría ver el estudio localmente

Búsqueda de estudios en pacs local

A partir de que falla el movimiento de un estudio, se ejecuta de manera automática la búsqueda en el pacs local, de todos los estudios para ese paciente.
El resultado se guarda en la base, en una nueva tabla, donde se asocia a cada estudio encontrado con el id de turno del estudio que falló.
Estos resultados se visualizan desde el BO en la lista de Monitoreo de estudio y la lista estudios, en la vista de edición.
La búsqueda se dispara a través de un evento mqtt, en donde se enviaran datos del paciente y del turno correspondiente. Estos eventos serán ejecutados cuando el orquestador informe a HSI que no se encontraron estudios para mover.
Cada búsqueda tendrá  3 posibles resultados:

  • Datos de todos los estudios encontrados para el paciente.
  • No se encontraron estudios para el paciente.
  • No se pudo establecer la asociación con el servidor PACS.

Impresión historia clínica

Parte anestésico

Se sumó para el rol personal de legales el documento de Parte anestésico dentro de los documentos disponibles para imprimir cuando el usuario ingresa a la HC del paciente.

Se sumó un checkbox con la leyenda de “Partes anestésicos”. En caso de incluir el documento, este se agrega a la impresión de la HC del paciente con el formato de impresión actual. Cabe mencionar que no se realiza la impresión del gráfico del parte anestésico en cuestión pero sí de la tabla con todos sus puntos de medición.

Formularios configurables

FUNCIONALIDAD CON FF de Desarrollo (luego de finalizada la funcionalidad por completo se eliminará)

Feature flag para activar funcionalidad: HABILITAR_FORMULARIOS_CONFIGURABLES_EN_DESARROLLO

Creación a nivel dominio

A partir de ahora se pueden crear formularios configurables a nivel dominio usando los parámetros definidos previamente también por el dominio. La funcionalidad de creación de estos parámetros están dentro del documento del release de la versión 2.23.

Se agregó para el rol administrador nuevo submódulo al módulo de datos maestros llamado “Formularios configurables”. Dentro de este submódulo se muestran todos los formularios creados por el dominio. Cuando el usuario ingresa a este submódulo se muestra una tabla con las columnas de:

  • id
  • Nombre de formulario
  • Estado (puede ser borrador, activo o inactivo)
  • Ambito
  • Botón de editar (solo si esta en estado borrador)
  • Botón de activar/desactivar

Allí mismo se listan los distintos formularios con su respectivo estado. Al mismo tiempo, se muestra un switch con la leyenda de “Excluir inactivos”. En caso de estar activado el switch, los formularios en estado inactivo no estarán visibles en el listado. Si este switch se desactiva se muestran todos los formularios. Por otra parte existe un botón de “CREAR” para generar uno de estos formularios.


Una vez que el usuario hace click sobre el botón “CREAR”, se le muestra un formulario en donde el usuario tiene un campo de texto libre para definir el nombre del mismo y por otro lado tiene, debajo del titulo Ambito, 3 switchs en donde define para qué ámbitos de la webapp va a estar disponible el formulario en cuestión. Cabe mencionar que el alcance de la funcionalidad en un principio estará solo disponible para el ámbito ambulatorio, es decir, por más que se marque el switch de internación esto no servirá para nada.


Una vez guardado el formulario, se redirige al usuario al detalle del mismo. Una vez creado, el formulario por defecto estará en estado borrador. Esto significa que le podrán agregar, editar o eliminar los parámetros que considere necesario. Al mismo tiempo se podrá editar el nombre del formulario y los ámbitos del mismo. En este detalle el usuario tendrá la posibilidad de agregar los parámetros que considere necesario. Para esto deberá hacer click sobre el botón “Asociar parámetro”.


Luego de hacer click aquí, se muestra un formulario con un campo de tipo typeahead donde el usuario selecciona el parámetro a asociar. Dentro de los parámetros a seleccionar se muestran solo los creados por el dominio. 


Una vez agregados, estos se listan en una tabla con las columnas de:

  • Descripción: Nombre del parámetro
  • LOINC: Código loinc si tiene 
  • Tipo: tipo de parametro
  • Unidad: unidades definidas si tiene
  • Orden: orden en el que se va a visualizar dentro de la webapp

A su vez se visualiza un botón de eliminar mientras el formulario se encuentre en estado borrador para eliminar el parámetro.


Como se mencionó anteriormente, una vez creado el formulario este pasará a estado borrador. Mientras esté en este estado el formulario no se visualizará dentro de la webapp y podrá sufrir las modificaciones que sean necesarias.

Una vez que el usuario hace click sobre el botón “ACTIVAR” dentro del listado de formularios, este pasa a estado activo y no podrá sufrir ninguna modificación. Al mismo tiempo, cuando esté en este estado el mismo será visible en la webapp para su uso.

Una vez activo el usuario puede hacer click sobre el botón “DESACTIVAR” para cambiar el estado del formulario a inactivo. Mientras el formulario esté en este estado, no se podrá utilizar dentro de la webapp. Sin embargo, el usuario en cualquier momento puede volver a hacer click sobre el botón de “ACTIVAR” y dejarlo disponible para su uso nuevamente.

Prevalidación de medicamentos

Asociación de fármacos y problemas a grupos de fármacos

A partir de esta versión, se agregó al detalle de los grupos de fármacos dos solapa nuevas. La primera solapa es la de fármacos. Dentro de esta solapa se visualiza un botón de “AGREGAR FÁRMACO” y un listado de fármacos. El listado cuenta con una columna con el nombre del fármaco la cual está ordenada alfabéticamente. Por otro lado existe una columna que tiene el título “Financiado” con un tic o una cruz. Al mismo tiempo se visualiza un botón de “Eliminar” para cada fármaco.


En caso de hacer click sobre el botón agregar fármaco se muestra un formulario donde se visualiza un campo para agregar el fármaco en cuestión. Este campo es un campo de tipo typeahead y trae solo los fármacos que tienen el switch de “Financiado por dominio” activado.

Una vez agregado, el fármaco se sumará al listado de fármacos con la columna “Financiado” con un tic explicado anteriormente. Cabe mencionar que, en caso de apagar el switch “Financiado por dominio” del listado de fármacos dentro del submódulo “Fármacos”, esto afectará la columna “Financiado” con una cruz.

La segunda solapa es la de problemas/diagnósticos. Lo que se muestre en esta solapa depende de si el switch “Incluir todos” en el detalle del grupo de fármacos debajo del título “Diagnósticos y problemas” está activado o desactivado. 


Si el grupo tiene activada la opción “incluir todos” solo se visualiza una leyenda que indica esta selección.

En caso contrario, dentro de la solapa se muestra un botón de “AGREGAR PROBLEMA/DIAGNÓSTICO” y se visualiza un listado de problemas/diagnósticos asociados. El listado cuenta con una columna con el nombre del problema/diagnóstico la cual está ordenada alfabéticamente. Al mismo tiempo, se visualiza un botón de “Eliminar” para cada problema/diagnóstico. 


En caso de hacer click sobre el botón agregar problema/diagnóstico se muestra un formulario donde se visualiza un campo para agregar el problema/diagnóstico en cuestión. Este campo es un campo de tipo typeahead y trae los conceptos de SNOMED de la caché.


Áreas de responsabilidad sanitaria

Edición de domicilio, geolocalización y área

Esta funcionalidad cuenta con un FF de desarrollo hasta su finalización

Feature flag para activar funcionalidad:HABILITAR_AREA_RESPONSABILIDAD_SANITARIA=true

Cuando un usuario ingresa con el rol  Administrador institucional  tiene la posibilidad de acceder desde el menú lateral izquierdo llamado “Área sanitaria” a una funcionalidad que ya se encuentra disponible desde releases anteriores, en donde el objetivo es mostrar en un mapa la ubicación de la institución y poder dibujar un área que representa su alcance de cobertura. La finalidad es visualizar en el mapa los datos de pacientes que se encuentren relacionados con la institución, como por ejemplo pacientes que se empadronaron en la misma.

El desarrollo creado hasta el momento aplicaba al ingreso del usuario a la funcionalidad, ver la dirección asociada a la institución que se encuentra asociado, verlo ubicado en el mapa y poder definir un área de cobertura en el mapa.

En la nueva release se sigue el desarrollo dándole la posibilidad de editar los datos ingresados, ya sea del domicilio de la institución como el área dibujada. 

Ingresa el usuario con rol Administrador Institucional:

Presiona sobre la opción “EDITAR GEOPOSICIÓN Y ÁREA”, se vuelve a posicionar en el paso 1 del stepper en donde se muestra el domicilio anteriormente ingresado

Una vez que se modifica se pasa al siguiente paso en donde se posiciona el punto en el mapa dependiendo de lo ingresado en el paso 1.

Y por último se puede volver a dibujar el área de responsabilidad sanitaria.

Una vez confirmada la edición una vez que vuelve a ingresar el usuario visualizará los datos actualizados.

Nuevas vistas en la Base de Datos

A pedido de Mendoza se crearon 4 nuevas vistas:

  • v_appointments_and_outpatient_consultations_report
  • v_consultations_health_conditions_report
  • v_consultations_reasons_report
  • v_consultations_procedures_report

v_appointments_and_outpatient_consultations_report

Los datos que la misma devuelve son:

  • idTurno (appointment_id)—puede ser null si la consulta no está asociada a un turno
  • idConsulta (outpatient_consultation_id)–puede ser null
  • idPaciente(patient_id)
  • idProfesional (healthcare_professional_id)
  • primerNombreProfesional (healthcare_professional_first_name)
  • segundosNombresProfesional (healthcare_professional_middle_names)
  • apellidoProfesional (healthcare_professional_last_name)
  • otrosApellidosProfesional(healthcare_professional_other_last_names)
  • nombreAutopercibidoProfesional(healthcare_professional_self_perceived_name)
  • Fecha turno (consultation_date)
  • idEfector (sisa_code)
  • Efector (institution_name)(nombre de institución)
  • idServicio (consultation_hierarchical_unit_service_id)
    • Si existe consulta, corresponde al id de la uj asociado a esta, sino al id de la uj asociado a la agenda.
    • Representa id de uj de tipo servicio que puede ser de la UJ del turno o consulta, o el id de la UJ de tipo servicio inmediatamente superior
  • Servicio (consultation_hierarchical_unit_service_name)(alias de la uj)
  • IdServicioSector (IdSubservicio) (diary_hierarchical_unit_id) – puede ser null si la consulta no está asociada a un turno
    • Mismo criterio que punto anterior. Si existe consulta, corresponde al id de la uj asociado a esta, sino seria el id de la uj asociado a la agenda.
    • Este id podria pertenecer a una UJ que no es de tipo servicio
    • Este identificador puede ser el mismo que el de idServicio, en caso de que la UJ no posea “padre” y a su vez sea de tipo servicio.
  • ServicioSector (alias de la uj)(diary_hierarchical_unit_name) – puede ser null si la consulta no está asociada a un turno
  • CodEspecialidad (clinical_specialty_snomed_code)Cod snomed de la especialidad de la consulta, si no existe, de la agenda
  • Especialidad (clinical_specialty_snomed_description)Descripción snomed de la especialidad de la consulta, si no existe, de la agenda. – puede ser null si la consulta no está asociada a un turno
  • TipoDocumentoPaciente (descripción del tipo de documento del paciente) (patient_identification_type)Cuando es una reserva (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • NúmeroDocumentoPaciente (patient_identification_number)
  • Financiador (descripción de la cobertura asociado a la consulta) (medical_coverage_name)Cuando es una reserva (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • RNOSFinanciador (medical_coverage_rnos)Cuando es una reserva (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • SexoOficial (descripción del sexo del documento) (official_sex)
  • FechaNacimiento (fecha de nacimiento del paciente en formato YYYY-MM-DD) (birthdate)
  • Edad (edad de paciente al momento de la consulta)—si no hay consulta, campo en null (patient_age)
  • Departamento (descripción del partido que figura en el dato de empadronamiento del paciente) (patient_deparment)Cuando es una reserva (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • Distrito (descripción de la ciudad que figura en el dato de empadronamiento del paciente) (patient_city)Cuando es una reserva (antes de ser pasado a asignado/confirmado), no tenemos este dato
  • EstadoTurno (descripcion del estado del turno) – puede ser null si la consulta no está asociada a un turno (appointment_state)
  • CanalObtención (Presencial o “Turnos online”) – puede ser null si la consulta no está asociada a un turno (appointment_booking_method)

 Problemas (v_consultations_health_conditions_report)

Los datos que la misma devuelve son:

  • idConsulta (outpatient_consultation_id)
  • idSnomed (health_condition_id)
  • Snomed (descripción) (health_condition_description)
  • idCie10 (código) (health_condition_cie10_code)
  • fecha_inicio (health_condition_start_date)
  • fecha_fin (health_condition_inactivation_date)

 Motivos (v_consultations_reasons_report)

Los datos que la misma devuelve son:

  • idConsulta (outpatient_consultation_id)
  • idSnomed (código) (reason_id)
  • Snomed (descripción) (reason_description)

Procedimientos  (v_consultations_procedures_report)

Los datos que la misma devuelve son:

  • idConsulta (outpatient_consultation_id)
  • idSnomed (código) (procedure_id)
  • Snomed (descripción) (procedure_description)
  • fecha (procedure_date)

Mejoras y bugs generales

Receta digital – Campos obligatorios para continuar

La confeccion de la receta digital está organizada en 3 pasos: Paciente, Receta y Medicación

A partir de ahora para poder avanzar al siguiente paso se deberán completar los datos obligatorios.

Listado de estudios de pacientes – informacion de observaciones de las ordenes

A partir de ahora, desde el listado de estudios de un paciente se podrán observar las observaciones indicadas en la solicitud.

Carga de resultados de estudios – informacion de profesional y observaciones

Para todo tipo de estudios al ingresar a cargar resultados se observa el nombre completo del profesional solicitante y las observaciones indicadas en la solicitud.