Aclaración importante:
Desde esta versión existen dos nuevas propiedades necesaria de configurar, relacionada a la autenticación del sistema.
1- Desde ahora se comienzan a utilizar cookies en el mecanismo de autenticación. Para poder usarlas y que funcione correctamente la cookie es necesario determinar el dominio bajo el cuál la información de la cookie va a ser enviada. Para hacer esto se debe usar la siguiente propiedad: app.auth.domain.
Por ejemplo,
app.auth.domain=sgh.pladema.net
Con esto se indica que todo backend que esté trabajando bajo el dominio *.sgh.pladema.net va a recibir dicha cookie. Si el valor por ejemplo es pladema.net los subdominios serian *.pladema.net, es decir sgh.pladema.net la recibiría.
En primera medida dado que en general se tiene un único dominio para el sistema, el valor recomendado es igual al dominio de la aplicación.
2 – La otra nueva propiedad es app.auth.secure, la cual tiene valor por defecto true. Cuando el valor esta en true, la cookie tiene el secure flag en true. El mismo determina que la cookie solo viaja bajo un dominio seguro (https). En el caso que se use en un dominio http, el valor debería ser seteado en false.
Funcionalidades que se trabajaron en esta entrega:
Reporte de referencias – reestructuración de la información
Hasta la versión anterior, el reporte de referencias que veía el administrativo de la institución, mostraba la siguiente información:
En esta nueva entrega se han reestructurado las columnas quedando de la siguiente manera:
Documento : tipo y nro. de documento . Ej: DNI 2345678, LC 4623456
Paciente : nombre, otros nombres, apellido y otros apellidos del paciente asociado a la referencia
Institución solicitante: nombre de la institución desde la que se generó la referencia
Profesional solicitante: nombre, otros nombres, apellido y otros apellidos del profesional que solicitó referencia
Línea de cuidado : nombre de la línea de cuidado asociada a la referencia, si la tuviera, puede estar vacía
Especialidad : nombre de la especialidad asociada a la referencia
Fecha Consulta : fecha de consulta que generó la referencia
Institución destino: nombre de la institución destino asociada a la referencia
Estado referencia: valores posibles: referencia pendiente, contrarreferencia
El reporte muestra referencias y contrarreferencias donde la institución solicitante o destino sea la institución desde la cual se genera el reporte. Se muestran referencias pendientes de respuesta primero y luego el resto. Dentro de eso, ordenado por fecha de consulta descendente(más nueva arriba)
Referencias solicitadas:
Referencias recibidas:
Se puede filtrar por rango de fecha. En el campo correspondiente se debe seleccionar una fecha inicial y la fecha final.
Gestión de turnos
Advertencia de actualizar cobertura al pasar a estado Confirmado
Se agregó una advertencia previo a confirmar el turno, para recordar que debe actualizarse la cobertura ya que no se podrá hacer posteriormente.
Si el usuario selecciona la opción “Si, actualizar cobertura”, la aplicación regresa al estado anterior, caso contrario se confirma el turno.
Referencia
Cambios en contrarreferencia – tipo de cierre
Un profesional que responde a una referencia cuenta con la posibilidad de definir de qué manera quiere cerrarla. Las opciones para darle el cierre son:
- Continúa en observación
- Inicia tratamiento en centro de referencia
- Requiere estudios complementarios
- Contrarreferencia
Para poder cerrar la referencia se debe seleccionar de manera obligatoria un tipo de cierre.
El tipo de cierre y la institución que cierra la referencia quedará ligado a la respuesta de la referencia ya que luego esa información deberá mostrarse en el histórico de consultas.
Cambios en histórico de consultas
Todo profesional que ingrese a la historia clínica de un paciente contará con la posibilidad de visualizar en el histórico de consultas las marcas especiales y la respectiva información de las referencias y sus respuestas.
En la información que se muestra de la referencia se agregó el nombre de la institución que la solicita.
En la información que se muestra de la respuesta de la referencia se:
- cambió el nombre del label para que tome el tipo de cierre definido en la respuesta
- agregó el nombre de la institución que respondió la referencia
Avance cambios en módulo de referencia
A continuación se enumeran los desarrollos que se avanzaron pero aún no se entregan:
- Backoffice – asociar prácticas a instituciones.Es necesario que las instituciones tengan la posibilidad de definir las prácticas que se ejecutan en el establecimiento.El administrador institucional será el encargado de dar de alta, modificar o borrar dicha información
- Backoffice – asociar problemas a línea de cuidado. Es necesario que las líneas de cuidado tengan asociadas una lista de problemas que podrían ser abordados.
- Configuración de líneas de cuidado y turnos protegidos en agenda de turnos: con esta nueva funcionalidad se podrán configurar las líneas de cuidado que trata una agenda específica y el porcentaje de turnos protegidos que acepta
- Visualización de información de líneas de cuidado y turnos protegidos en agenda: con esta nueva funcionalidad se podrá observar desde la vista de la agenda la información básica de la misma:
- Líneas de cuidado. En caso de ser mas de una se verán separadas por coma.
- Consultorio y sector.
- Profesional responsable y profesionales asociados a la agenda.
- Porcentaje de turnos protegidos.
- Búsqueda de turno directo para referencia: es necesario que personal administrativo de la institución tenga la posibilidad de buscar turnos protegidos en instituciones del dominio para así asignar un turno libre a un paciente puntual con necesidad de ser atendido por una referencia pendiente.
- Asignación de turno reservado para referencia: una vez que el personal administrativo ubica un turno protegido libre para asignar al paciente, debe contar con la posibilidad de realizar tal acción.
Se espera entregar la funcionalidad avanzada en la próxima release