En esta nueva release se trabajaron los siguientes puntos:
Guardia
Edición de alertas de aislamiento de pacientes colonizados
Se sumó dentro de las acciones del card “Alertas de aislamiento” presente en la solapa Problemas de la historia clínica del paciente, la acción de “Editar alerta”.
En caso de hacer clic sobre esta acción, se le muestra el popup con información de la alerta con la posibilidad de editar los campos de:
- Criticidad
- Fecha de fin
- Observaciones
Todos los demás campos se muestran deshabilitados para su edición.
Luego de editar la alerta de aislamiento, el usuario debe hacer clic sobre el botón “Guardar cambios” para confirmar la acción. Una vez confirmada la edición, se muestra quien fue el usuario que lo realizó en caso de hacer clic sobre “Ver detalle”, desde el card de Alertas.
Cabe mencionar que solo se pueden editar alertas que están en estado “Activas”.
Alerta de aislamiento en header de historia clínica
Luego de crear una alerta de aislamiento y confirmar el documento, esta se suma al header de la HC del paciente en cuestión. Se visualiza el o los tipos de contacto asociados a la alerta y el diagnóstico asociado a continuación, entre paréntesis.
En caso de existir más de un alerta creado, se visualiza un link indicando cuántas alertas activas más tiene el paciente. En caso de hacer clic sobre el link se visualiza el detalle de todas las alertas de aislamiento activas.
Cabe mencionar que las alertas con estado “Finalizada” no se visualizan dentro del header del paciente.
Gestor de accesos
Nuevos estados de origen y destino y correcciones en asignación de turno
Se realizaron diferentes modificaciones dentro del módulo gestor de accesos. A modo de recordatorio se explica a continuación la parte del proceso a modificar junto con los resultados esperados.
Como primer paso, un usuario con su rol correspondiente va a realizar una solicitud de referencia. Si la referencia es de tipo práctica se va a generar una orden, de lo contrario no. Por otro lado, al momento de generar la solicitud, el usuario tiene la posibilidad de no definir una institución destino.
Cambio 1: Nuevos estados de origen de solicitudes según reglas generales y locales
Hasta la actualidad, al momento de crear una solicitud, teniendo en cuenta las reglas generales o locales definidas en el backoffice y la especialidad o práctica de la solicitud, la solicitud debía pasar o no por una aprobación. Si existen reglas se generaba con el estado “ESPERANDO APROBACIÓN” y si no hay reglas que la regulen se generaba con el estado “SOLICITUD APROBADA”.
A partir de ahora, si la solicitud no tiene una regla local o general que la regule, la solicitud se genera con un nuevo estado de origen “NO REQUIERE AUDITORIA”. En caso contrario, se genera con el estado “ESPERANDO AUDITORÍA”.
Una vez que se crea la solicitud, esta se lista en los dashboards de:
- Gestor de acceso local que pertenece a la red que contiene la institución de origen de la solicitud
- Gestor de acceso regional que pertenece a la red que contiene la institución de origen de la solicitud
- Gestor de acceso de dominio
- Solapa de “Solicitadas” de Gestor de acceso institucional y administrativo de la institución origen de la solicitud
- Solapa de usuario que genero la solicitud.
Por otro lado, las acciones que tienen los roles gestor de acceso local, regional, de dominio en esta etapa del proceso sobre solicitudes dentro de los dashboards mencionados se muestran en la siguiente tabla:
Con respecto a las acciones que deberá tener el rol gestor de acceso institucional en esta etapa dentro de los dashboards mencionados, se muestran en la siguiente tabla:
Finalmente, en caso de que el estado de aprobación de la solicitud sea “Esperando auditoría” los posibles cambios de estados son:
- Rechazada: se cancela la referencia y se elimina la orden si es de tipo práctica. No se puede hacer nada sobre la solicitud. Una vez definido el estado Rechazada no se puede modificar el estado de aprobación.
- Auditada: Se le envía el dashboard de la solapa “Recibidas” de los roles administrativos y gestor de acceso institucional de la institución destino definida. Una vez definido el estado Auditada no se puede modificar el estado de aprobación.
- Revisión Sugerida: Se actualiza el dashboard del médico solicitante para que pueda modificarla. Luego de modificarla, la solicitud de referencia cambia su estado de aprobación a “Esperando auditoría” nuevamente. Hasta no tener respuesta del médico no se puede cambiar el estado de aprobación.
Cambio 2: Nuevo estado de aprobación de destino y acciones de roles
Al momento que las solicitudes ingresan en el dashboard dentro de la solapa”Recibidas”, estas figuran en estado de aprobación de destino “ESPERANDO APROBACIÓN”. Mientras la solicitud se encuentre en este estado, las acciones posibles de los usuarios serán:
Cambio 3: Nuevo estado de aprobación de destino “Revisión sugerida” y acciones posibles
El rol de gestor de acceso institucional acá tiene la posibilidad de cambiar el estado de aprobación de la solicitud a “REVISIÓN SUGERIDA”. En caso de cambiar la solicitud a este estado, el usuario debe definir un motivo obligatorio y aceptar el cambio de estado.
Una vez aceptado el cambio de estado, la solicitud cambia su estado de origen a “ESPERANDO AUDITORÍA”. Al mismo tiempo, esto impacta en los dashboards de los gestores solicitantes. Se muestra el usuario que realizó la acción junto con la fecha y hora.
Aquí el botón de “Editar datos de la referencia” está oculto. A su vez, también se oculta el estado “Auditada”. Una vez hecho esto, el gestor solicitante puede:
- Rechazar solicitud
- Mandar a revisión sugerida
- Cerrar administrativamente la referencia
- Editar referencia / institución destino
En caso de editar la solicitud, los datos posibles a modificar son:
- Adjuntar archivos
- Cambiar institución destino
- Agregar observaciones
Una vez confirmada la modificación de la solicitud, esta vuelve al estado de origen “AUDITADA” y al estado de destino “ESPERANDO APROBACIÓN”.
Cambio 4: Nuevo estado de aprobación de destino “Aprobada” y acciones posibles
En caso de cambiar el estado de aprobación a “APROBADA” se deberá confirmar el cambio de estado mediante un botón de “Confirmar”.
Una vez confirmado el cambio de estado, se muestra el usuario junto con la fecha y hora que realizó la acción.
Al mismo tiempo, la solicitud pasa a estar habilitada para la asignación de su turno para los roles administrativo, gestor de acceso institucional, especialista médico, especialista en odontología y profesional de la salud. Para esto se habilita un botón de “ASIGNAR TURNO”.
En caso de hacer clic sobre este botón, se mantiene el comportamiento actual de asignación de turno.
Listado de trabajo
Filtros en listado de trabajo para personal de laboratorio
El listado de trabajo se encuentra desarrollado de versiones anteriores en donde puede acceder el usuario con rol de “Personal de Laboratorio” para poder visualizar las órdenes de estudios de laboratorio que provienen de guardia e internación, en donde se menciona su urgencia y la fecha en que se realizó la orden, además de los datos del paciente.
Para facilitar el uso del listado se agregó un espacio de filtros en donde se puede hacer uso de:
- Ámbito
- Urgencia o rutina
- Requiere o no traslado
- Paciente temporal de guardia
Todos los filtros se pueden complementar.
Listado de trabajo de Laboratorio:
Sector filtros:
Ejemplo de combinación de filtros con su resultado:
Receta digital
Actualizaciones en receta digital
Configuración necesaria
Para poder acceder al formulario actualizado de receta digital, se deben realizar las siguientes configuraciones:
- Crear o recrear el esquema de relaciones SNOMED en la base de datos de HSI (ver guía)
- IMPORTANTE
Tener en cuenta que el esquema utiliza la ECL MEDICINE_WITH_UNIT_OF_PRESENTATION por lo cual antes de crear o recrear el esquema es necesario contar con la terminología asociada a esa ECL.
- IMPORTANTE
- Habilitar feature flag HABILITAR_RELACIONES_SNOMED
- Habilitar feature flag HABILITAR_RECETA_DIGITAL_ACTUALIZADA
Se incorporan actualizaciones en el formulario de receta digital con el fin de:
- Simplificar el proceso de prescripción y aumentar la claridad en la información presentada mejorando la experiencia del usuario.
- Validar recetas emitidas bajo cobertura médica
Principales mejoras incorporadas:
- Nuevos campos para completar la información requerida por los validadores de receta.
- Presentaciones comerciales: Presentaciones comerciales (unidades) disponibles del medicamento.
- Cantidad de envases: Especifica la cantidad de envases/cajas a dispensar.
- Optimización de la prescripción terapéutica
- Renombrado de los campos para una mayor claridad al momento de completar la receta.
- Reemplazo de la sección “Intervalo” por “Frecuencia”, utilizando terminología más intuitiva.
- Inclusión de información detallada sobre la presentación y las unidades del medicamento, facilitando una prescripción más precisa.
- Habilitación de campos a completar según la presentación del medicamento:
- Cantidad de envases (frascos, tubos, etc.)
- Cantidad (comprimidos, cápsulas, óvulos, etc.)
Ejemplo de receta bajo cobertura médica, como datos obligatorios se deben completar presentaciones comerciales y cantidad de envases.
Otros ejemplos con medicaciones de distinta presentación
Cuando se trata una indicación de tipo gotas o aplicaciones de cremas, disparadores, entre otros, no se calcula ni se es posible completar cantidad total sino que se debe ingresar obligatoriamente cantidad de envases.
Actualización de PDF
Se actualizó el diseño del PDF para reflejar las mejoras en el formulario de receta digital. Es importante destacar que los datos que no se completen en el formulario de receta, por ejemplo la marca sugerida, no se incluirán en el PDF.
Además, se introdujo una división en dos páginas para organizar mejor la información:
- Información para la farmacia: Detalles necesarios para la dispensación del medicamento.
- Indicaciones para el paciente: Instrucciones claras sobre el uso del medicamento.
Detalle:
El nuevo diseño del PDF se aplicará incluso si se utiliza el formulario actual de receta digital (no el actualizado), en este caso:
- Lo ingresado en el campo “Dosis/unidad” se reflejará en la sección “Cantidad por vez”.
- Lo ingresado en el campo “Dosis/día” también será visible en el documento.
Nueva versión de endpoint para obtención de recetas en la API pública
Se ha incorporado una nueva versión del endpoint utilizado para la obtención de las recetas para garantizar compatibilidad con las actualizaciones realizadas en el formulario de receta digital. Este endpoint incluye dos nuevos campos que permiten reflejar la información adicional proporcionada durante la prescripción:
- packageQuantity: Representa el valor ingresado en el campo “Cantidad de envases”.
- presentationPackageQuantity: Representa el valor ingresado en el campo “Presentaciones disponibles”.
Detalle: Los endpoints utilizados para la obtención de las recetas al día de la fecha seguirán funcionando correctamente independientemente de si se usa el formulario actualizado o el vigente.
Red de imágenes
Actualización del visualizador OHIF
Se actualizó el visualizador OHIF VIEWER a versión 3.8. De esta manera se permiten visualizar estudios en modalidad MR, se introdujeron mejoras en el manejo de modalidades PRs, facilidad para visualizar PDFs incrustados usando bulkDataURIs y mejoras UX/UI.
Informe de estudio realizado
Se incorporó información del paciente en cada hoja del informe de estudios para evitar riesgos al momento de imprimir varios estudios juntos.
En cada página del informe se verá información de la institución y del paciente en el header y la numeración de cada hoja en el footer.
Header de cada hoja:
Footer de la última hoja:
Bugs y mejoras generales
Guardia – Atención de especialista de odontología
Se nos reportó imposibilidad de atención en la guardia con especialista de odontología. Este inconveniente fue resuelto en esta última release.
Guardia – Asignación de paciente a un espacio físico que está eliminado en Backoffice
Chubut reportó un error al momento de seleccionar espacios disponibles para atención en la guardia. El inconveniente se presentaba con espacios dados de baja desde el backoffice, ya que los mismos continuaban viéndose como disponibles desde la webapp. Este inconveniente fue resuelto en esta última release.
Impresión de historia clínica – Inconsistencia con las fechas de episodios e institución
Chubut reportó inconsistencia en la impresión de historia clínica en algunos pacientes: al filtrar por fecha para imprimir la historia clínica, se presentaba un resultado, pero al descargarlo la fecha e institución no coincidía con lo que se había buscado. Este inconveniente fue resuelto en esta última release.