En esta nueva versión se trabajaron las siguientes funcionalidades:
Reportes
Configuración
Reporte atenciones de guardia
Se definió el feature flag HABILITAR_REPORTE_DETALLE_NOMINAL_GUARDIA_EN_DESARROLLO para la activación de este reporte. Por defecto este FF estará en false
Customización de logos – Logos de documentos
A partir de ahora, un usuario con el rol administrador podrá configurar desde la webapp los logos que desea se muestren en header y footer de los documentos que se generan en HSI y también los de receta digital.
En las imágenes se observa que tanto el header como el footer para receta digital en este ambiente están en blanco, por lo cual la receta no tendrá logos.
Percentilos
Guardado de valores de percentiles al momento de carga de valores antropométricos
El nuevo desarrollo consiste en guardar en la base de datos los percentiles asociados a las consultas en donde se registraron datos antropométricos en pacientes pediátricos (menores de 19 años).
Los datos antropométricos son:
- Peso
- Talla
- IMC (calculado)
- Perímetro cefálico
Los gráficos que tienen percentiles:
- Peso/Edad
- Talla/Edad
- Peso para talla
- IMC/Edad
- Perímetro cefálico/Edad
Los gráficos que tienen puntaje Z:
- Peso/Edad
- Talla/Edad
Los datos a guardar se encuentran asociados a un id de consulta y gráfico. El valor del percentil es aproximado al piso. Si el dato antropométrico se encuentra impactando en varios gráficos, se guarda una fila por cada gráfico.
Condición del paciente para guardar la información
- Fecha de nacimiento definida
- Sexo M o F, no X
Ejemplos:
- Se carga el dato de la talla en un paciente:
Los datos guardados en la base:
En donde el ID de consulta es el 63, el gráfico que se encuentra impactado es con id 2 y el valor del percentil es 51.2.
- Se carga datos de peso y talla:
Los datos guardados son:
Guardia
Nuevo diseño de formulario de creación de episodio de guardia
Se realizó un nuevo diseño del formulario de nuevo episodio de guardia. Por un lado, se cambió el campo de motivo de ingreso. Este era un campo donde el usuario debía seleccionar entre conceptos estructurados de SNOMED y ahora es un campo de texto libre. Por otro lado se quitó el botón “OMITIR” ya que realizaba la misma acción que el botón “CONTINUAR” y generaba confusión al usuario.
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 |
El objetivo de esta funcionalidad es la creación de formularios que podrán ser agregados a las nuevas consultas realizadas por los usuarios con rol de especialista médico, especialista en odontología y enfermería para cualquier ámbito.
Estos formularios podrán ser definidos a nivel dominio e institución. Sin embargo, la selección de los parámetros disponibles para utilizar dentro de los formularios quedará solo a cargo del dominio. Cabe mencionar que los parámetros podrán estar asociados a un código LOINC, si es necesario, lo cual va a ser beneficioso para futuras funcionalidades.
A futuro, cualquier sector de cualquier ámbito dentro de la institución podrá crear su propio formulario con los parámetros que considere necesarios para una mejor atención y seguridad del paciente.
Creación de parámetros
La primera acción para poder hacer uso de esta nueva funcionalidad es la creación de los parámetros a nivel dominio. Para esto, el usuario administrador debe ingresar a un nuevo módulo ubicado en el backoffice que tiene el nombre de “PARÁMETROS DE FORMULARIOS” dentro del módulo “DATOS MAESTROS”.
Una vez que ingresa a este nuevo módulo el usuario visualiza una lista en donde se irán cargando los parámetros posibles a utilizar a medida que se vayan creando. Para crear un parámetro se deberá clickear sobre el botón “+CREAR”.
Al clickear sobre este botón se abre un formulario de creación donde se cargan los datos del parámetro a crear. Este formulario cuenta con varios campos que van a ser explicados en detalle a continuación:
Primero se visualiza un radiobutton donde el usuario define si el parámetro a crear está asociado a un código LOINC o no.
En caso de seleccionar el raidiobutton “SI” se muestran los siguientes campos:
1- El primer campo “Código LOINC”, es un campo obligatorio de tipo typeahead donde el usuario va a cargar el código LOINC asociado al parámetro. Estos códigos van a venir de la tabla maestra de LOINC.
2- El segundo campo es el campo descripción. Este campo se va a completar de manera automática cuando el campo de código LOINC sea completado. En caso de que el usuario haya definido un nombre para el campo NombreEnSistema en la tabla LOINC se va a visualizar ese dato. En caso de que no haya completado ese campo se visualiza el nombre reflejado en la columna Component de la tabla LOINC.
3- El tercer campo es “Tipo de parámetro“, aquí es donde se define como es el tipo de dato a cargar. Según el tipo de parámetro se habilitan distintos campos a completar. Aquí las opciones son:
- Numerico
- Texto libre
- SNOMED (ECL)
- Lista de opciones
En caso de seleccionar el raidiobutton “NO” se muestran los siguientes campos:
1- El primer campo es el de “Descripción”. Acá el usuario define el título del parámetro a mostrar en la webapp dentro de un campo de texto libre.
2- El segundo campo es “Tipo de parámetro“, aquí es donde se define como es el tipo de dato a cargar. Según el tipo de parámetro se habilitan distintos campos a completar. Aquí las opciones también son:
- Numerico
- Texto libre
- SNOMED (ECL)
- Lista de opciones
A continuación se explican los campos que se agregan en base al tipo de parámetro seleccionado:
NUMERICO
En caso de seleccionar el tipo de parámetro “Numérico” se habilita un campo opcional de Unidad. Este va a ser un campo de tipo typeahead donde se visualizan todas las unidades “HABILITADAS” dentro de la tabla maestra de unidades. Al mismo tiempo, va a existir un botón para agregar más de una unidad. Finalmente hay un campo donde se debe ingresar la cantidad de valores distintos a ingresar por el usuario.
En caso de tener dos unidades y un solo campo a ingresar, el usuario visualizará en la webapp un solo campo a completar donde tendrá que seleccionar de un desplegable cuál de las dos unidades utiliza.
En caso de tener dos unidades y dos campos a ingresar, el usuario visualizará en la webapp dos campos a completar cada uno con un desplegable para seleccionar las unidades.
TEXTO LIBRE
En caso de seleccionar el tipo de parámetro “Texto libre” no se habilita ningún campo adicional. Esto significa que en la webapp el usuario tendrá un campo de texto libre para completar el resultado.
SNOMED
En caso de seleccionar el tipo de parámetro “SNOMED (ECL)” se habilita un campo para seleccionar una ECL. Este va a ser un campo de tipo desplegable donde se visualizan todas las ECL cargadas en el backoffice. Esto significa que el usuario en la webapp deberá seleccionar entre alguna de las opciones de la ECL definida a la hora de cargar el resultado.
LISTADO DE OPCIONES
En caso de seleccionar el tipo de parámetro “Lista de opciones” se habilita un botón para añadir la cantidad de campos de texto libre que el usuario considere, donde, a su vez, debe cargar la opción a mostrar en cada campo. Es obligatorio que al menos existan dos opciones.
Finalmente para todos los casos de tipo de parámetro se visualiza un botón de “GUARDAR” para crear el parámetro en cuestión. A medida que se crean los parámetros, se van listando con sus datos correspondientes en cada columna de la tabla. Las columnas de la tabla son:
- Descripción
- LOINC
- Tipo
- Unidad
Al mismo tiempo se visualiza un botón de “Editar”. Haciendo click sobre este botón se pueden editar los atributos de los parámetros.
Internación
Mejoras en parte quirúrgico
Se realizaron mejoras en el diseño del documento “Parte quirúrgico”. El objetivo de estas mejoras fue generar consistencia con los otros documentos de la aplicación y mejorar la usabilidad del usuario con rol de especialista médico y especialista en odontología. Los cambios realizados son:
Desplegable “Diagnósticos”
Se unificó el diseño y el comportamiento sobre el desplegable “Diagnósticos” usado en los otros documentos de la aplicación. A su vez, se cambió el nombre a “Diagnósticos Pre-Operatorio”.
Cirugia propuesta
Se creó un desplegable específico para definir el dato de la cirugía propuesta. Previamente, este campo estaba incluido en el desplegable Diagnósticos y generaba confusión al usuario.
Disponibilidad de creación de documento
A partir de ahora, el parte quirúrgico está disponible para su creación incluso después del alta médica. Sin embargo, este no puede ser creado luego del alta administrativa.
Técnica anestésica y diagnóstico postoperatorio
Se creó un desplegable específico para definir el dato de la técnica anestésica y otro para definir el diagnóstico postoperatorio del paciente. Previamente, estos campos estaban incluidos dentro del desplegable “Procedimientos” y generaba confusión al usuario.
Equipo de quirófano
Dentro de este desplegable se ingresan todas las personas que intervinieron en la cirugía. Ahora, solo se visualiza el input a completar del Cirujano principal con su DNI y su matrícula ya que este es el médico responsable que interviene en el documento. Al mismo tiempo, luego de este inputs se visualiza un botón de “+ Agregar integrante al equipo”.
Una vez que el usuario hace click sobre este botón se muestra un popup donde se debe cargar los datos de este nuevo integrante. Primero se visualiza un campo de tipo desplegable donde se deberá elegir la profesión del nuevo integrante. Dentro de este desplegable las posibles opciones son:
- Ayudante
- Anestesiólogo
- Cardiologo
- Enfermero
- Especialista médico
- Instrumentador
- Neonatólogo
- Obstetra
- Odontólogo
- Pediatra
- Profesional de la salud
- Otro
En caso de seleccionar “Otro” se habilita un campo de texto libre donde debe escribir la profesión del integrante.
El comportamiento de este popup es similar al del cirujano principal, es decir, cuando el usuario completa el nombre, el DNI y la matrícula se completan de manera automática teniendo en cuenta el MPI de HSI.
Una vez confirmado al nuevo integrante estos se irán listando en un card debajo del cirujano con la posibilidad de “Eliminar” en caso de ser necesario.
Ambulatorio
Carga de resultados de estudios
A partir de esa versión de HSI se pueden cargar valores a estudios indicados por la aplicación. Cabe mencionar que para que esta funcionalidad esté disponible en la webapp se deben generar la plantilla de estudios correspondientes con sus respectivos parámetros y asociarlas a los SNOMED correctos. Esta acción la realiza el rol administrador. A continuación se muestran pantallas para recordar esto y en caso de necesitar más información esta se encuentra en la documentación de los Release 2.14 y 2.16.
Una vez hecho esto, cuando un usuario solicite una práctica desde la solapa estudios que tenga asociada una plantilla de estudios esta quedará disponible para cargarle sus valores correspondientes. Recordemos que para solicitar un estudio ambulatorio debe entrar a la HC del paciente, ingresar a la solapa “ESTUDIOS” y hacer click sobre “Nueva orden de ambulatorio”.
Luego, debe seleccionar la práctica a realizar. Esta práctica debe ser la que está asociada a la plantilla de estudios generada previamente.
Esto genera un estudio en estado “PENDIENTE” dentro de la solapa “ESTUDIOS”. Al igual que antes el usuario visualiza un botón de “Completar” dentro de las acciones secundarias para indicar que el estudio fue realizado.
A partir de este desarrollo, una vez que el usuario hace click sobre completar se le muestra un popup donde primero debe seleccionar cual de las plantillas de estudios va a utilizar para completar los resultados. Esto se debe a que una práctica puede estar asociada a distintas planillas de estudios.
Luego de seleccionar la plantilla a utilizar se muestran todos los parámetros posibles de carga que tiene la plantilla. Al mismo tiempo, se sigue visualizando el campo de Observaciones y el botón de adjuntar archivos que ya existían previamente. Cabe mencionar que ningún campo de los parámetros a completar es obligatorio.
Finalmente, una vez completado los parámetros y haciendo click sobre el botón “COMPLETAR” estos quedarán asociados a la práctica dentro de la HC del paciente. En caso de ingresar nuevamente a la solapa “ESTUDIOS” y al estudio en cuestión se pueden visualizar los resultados del mismo haciendo click sobre el botón “Ver resultados” dentro de las acciones secundarias.
API Publica – Reportes estadísticos-Turnos – Horas Oferta
Se nos solicitó un endpoint en la API pública que devuelva información de la oferta de horas de turnos de agenda.Dado un rango de fechas de a lo sumo 30 días, y opcionalmente el código sisa de la institución y/o un identificador de unidad jerárquica, retorna un listado de ocupación y disponibilidad de agenda por día.
Nombre: FetchDailyHoursByDate
Permisos: Rol API_REPORTES con su api-key relacionada
Parámetros:
- dateFrom: fecha desde la cual se filtra (obligatorio)
- dateUntil: fecha hasta la cual se filtra (obligatorio, no puede estar separada por más de 30 días de dateFrom)
- institutionRefsetCode: código de la institución por la que se desea filtrar (opcional)
- hierarchicalUnitId: identificador de la unidad jerárquica por la que se filtra (opcional, debe ser de tipo Servicio)
Formato de respuesta
Si existe una persona asociada al usuario, la respuesta será:
[
{
“day”: “2024-05-24”,
“dailyHours”: [
{
“diaryId”: 0,
“institutionCode”: “string”,
“institutionName”: “string”,
“serviceHierarchicalUnit”: { //puede ser vacio si no hay UJ de tipo servicio
“id”: 0,
“description”: “string”,
“type”: 0
},
“hierarchicalUnit”: {
“id”: 0,
“description”: “string”,
“type”: 0
},
“professionalCuil”: “string”,
“professionalData”: {
“id”: 0,
“identificationType”: “string”,
“identificationNumber”: “string”,
“cuil”: “string”,
“lastName”: “string”,
“middleNames”: “string”,
“firstName”: “string”,
“selfPerceivedName”: “string”
},
“clinicalSpecialty”: {
“id”: 0,
“description”: “string”,
“snomedId”: “string”
},
“diaryType”: “string”, //Consulta o Práctica
“minutesInAppointments”: 0, //minutos destinados a turnos
“possibleAppointments”: 0, //cantidad de turnos posibles ese día
“interruptions”: 0, //cantidad de bloqueos
“interruptionsDescriptions”: [ //vacío si no hay bloqueos
“string”
]
}
]
}
]
Mensajes de error
400 invalid-date si la fecha no está en formato yyyy-mm-dd
400 Constraint violation si el rango de fechas excede los 30 días
401 unauthorized si el api-key no se corresponde con un usuario con rol API_REPORTES
404 institution-not-exists si el sisa (refset) code no existe