En esta nueva entrega se trabajaron los siguientes puntos:

Registro de auditoría en admisión de paciente y edición de sus datos

Es necesario que para un correcto seguimiento de las implementaciones del HSI en los dominios y también para permitir realizar diferentes reportes, se registre auditoría al momento de admitir un nuevo paciente en el MPI, cuando se editan sus datos y también cuando se logra federar correctamente desde el cron. Se debe considerar no perder la auditoría de ningún evento sobre el paciente. Esto significa que se debe contar con información histórica de auditoria.

Esto significa que al momento de admitir un nuevo paciente se debe registrar: institución desde la cual se produce la admisión, el usuario que genera la admisión y la fecha de admisión. 
Al momento de la edición de los datos del paciente se debe registrar el  usuario que realiza la modificación, la fecha de actualización y la  institución desde la cual se produjo la modificación.
Al momento de la federación del paciente se debe registrar la fecha de cuando se logra federar, usuario y fecha.

Se debe considerar que para los pacientes ya admitidos no se contará con información de “auditoría”.

Para resolver esta necesidad se diseñaron dos nuevas tablas:

Nuevas tablas en base de datos

Ambas tablas son manejadas por la aplicación ante cada evento de admisión de nuevo paciente y edición de cualquiera de sus datos. Para realizar seguimiento de implementación de dominios o reportes se deben realizar consultas sobre las mismas desde la base de datos respectiva

Visualización de historia clínica externa

Un dominio que implemente el HSI y además tenga otra aplicación anterior en la cual contenga información  de historia clínica del paciente, debe contar con la posibilidad de acceder a dicha información a través de algún mecanismo dentro del HSI. El acceso a la información histórica externa será solo a modo de visualización y no debe permitir ninguna acción directa sobre el HSI.

La información externa contendrá:

  • datos de identificación del paciente: tipo, nro, de documento y sexo
  • institución desde la cuál proviene la información
  • especialidad en formato texto sin relación con las especialidades del HSI. Este dato podría estar vacío.
  • nombre del profesional en formato texto sin relación con los profesionales del HSI. Este dato podría estar vacío
  • evolución en formato texto
  • fecha de consulta

La información externa debe poder visualizarse de manera ordenada por fecha descendente. Eventualmente se podría filtrar información por palabra clave, institución, fecha, especialidad o nombre del profesional.

Si el dominio desea ver información de historia clínica externa debe contar con la posibilidad de ver dicha información desde la historia clínica del paciente

Por defecto no debe verse ninguna opción para visualización de historia clínica externa

Para habilitar la funcionalidad de historia clínica externa se debe activar el feature flag HABILITAR_HISTORIA_CLINICA_EXTERNA. Además el dominio será el encargado de generar un script a correr sobre la base de datos para cargar la información de historia clínica externa. El script debe ejecutarse una única vez y sus datos podrán consultarse desde el HSI todas las veces que sean necesarias.

La tabla que se creó para guardar información de historia clínica externa se llama: external_clinical_history. Esta tabla contiene los siguientes campos:

 

Para insertar tuplas en la tabla external_clinical_history, se debet ener en cuanta lo siguiente:

  •     patient_gender: tiene 2 posibles valores: 1 para sexo femenino y  2 para sexo masculino
  •     patient_document_type: tiene 12 posibles valores: 1(DNI), 2(CI), 3(LC), 4(LE), 5(Cédula Mercosur), 6(CUIT), 7(CUIL), 8(Pasaporte extranjero), 9(Cédula de identidad extranjera), 10(Otro documento extranjero), 11(No posee), 12(En trámite)
  •     patient_document_number: Campo de texto de 11 caracteres max para el numero de documento
  •     notes: Campo de texto libre de hasta 1024 caracteres para resumir toda la información necesaria de la consulta
  •     consultation_date: Fecha de la consulta (YYYY-MM-DD)
  •     institution: Campo de texto libre con 255 caracteres para especificar la institución donde fue atendido el paciente
  •     professional_name: Campo de texto de hasta 120 caracteres para almacenar el nombre completo del profesional que atendió la consulta
  •     professional_specialty: Campo de texto de 100 caracteres para insertar la especialidad del profesional

Ejemplo para insertar un paciente Masculino con tipo de documento Dni, numero 33444555 que fue ingresado por “fiebre y tos” el día 03 de Agosto del 2021 en la Clínica Chacabuco, atendido por el profesional Jorge Robles con especialidad ‘Visitador médico’:

INSERT INTO external_clinical_history(patient_gender, patient_document_type, patient_document_number, notes, consultation_date, institution, professional_name, professional_specialty) VALUES (2, 1,’33444555′, ‘fiebre, tos’, ‘2021-08-03’, ‘Clinica Chacabuco’, ‘Jorge Robles’, ‘Visitador médico’);

Nota: No se debe insertar ‘NULL’ en ningún campo; en caso de no tener la información se debe ignorar la carga del campo. A continuación un ejemplo a partir del anterior en donde no se posee el nombre de la Institución:

INSERT INTO external_clinical_history(patient_gender, patient_document_type, patient_document_number, notes, consultation_date, professional_name, professional_specialty) VALUES (2, 1,’33444555′, ‘fiebre, tos’, ‘2021-08-03’, ‘Jorge Robles’, ‘Visitador médico’);

Es importante remarcar que en el ejemplo se retiró el campo “institution” tanto en la parte de descripción de parámetros como en la asignación del valor.

Ajuste de información en reportes de admisión: Anexo II y Formulario V

Ambos reportes muestran desde esta nueva release información de código CIE10 de diagnóstico y su correspondiente descripción en los casos en los se hayan definido los mismos en las consultas representadas.

Anexo II
Formulario V

Se agregó también el código SISA del establecimiento según información cargada para el mismo desde el backoffice.

Formulario V
Anexo II

Avance módulo de odontología

En esta release se culminó la implementación de la acción completar consulta odontológica. Esta acción permite guardar información en la base de datos para luego poder mostrarla cada vez que sea necesario tanto en el odontograma como en el sector de información histórica de piezas.. Se modificaron componentes visuales que permiten agregar y quitar hallazgos y procedimientos en piezas y/o caras de una manera mas sencilla, facilitando también la búsqueda. Se inició desarrollo para calcular índices CPO y ceo.

Identidad de género

En esta release se comenzó a trabajar en los cambios sugeridos por la Dirección de Géneros y Diversidad del Ministerio de Salud de la Nación respecto a lo que venimos denominando género autopercibido dentro del HSI. Hasta el momento se puede definir dos opciones: femenino y masculino, desde la próxima release quedarán disponibles un conjunto de opciones y el titulo del componente pasará a denominarse: Identidad de género. En la próxima entrega se darán detalles mas puntuales y se podrán observar los cambios en la aplicación.