SAVICS impulsa los bienes globales para habilitar los Sistemas de Intercambio de Información de Salud de Ruanda (RHIES)

In September 2019 the SAVICS team, a digital social start-up who works in-country to develop and implement health information systems, started their work in Rwanda to create the Rwandan Health Information Exchange Systems (RHIES). 

The main issue was that these systems communicated to each other in ways that demanded manual efforts. These systems needed automation and interoperability. The HIV case-based surveillance data needed to be digitized in collaboration with the Rwanda Biomedical Centre (RBC), Health Information System (HIS) team, and the RBC HIV program. Additionally, the data collection and exchange processes needed to be aligned with the country’s OpenHIE-based architecture and utilize an interoperability layer, the client registry, and the Facility Registry.

One of the biggest challenges the SAVICS team faced when tackling these areas was that facilities were using paper based processes to record HIV case-based surveillance cases which were then manually entered into DHIS2 by the data manager. This created an exceptionally heavy workload. There was also a high turnaround time to get the viral load and recent results from the laboratory (LabWare) back to the facility. Another big challenge that Rwanda was facing was health information exchange: systems which contained the data (OpenMRS, National Identification Agency (NIDA), DHIS2) had no way to share it across systems to allow for automation, updates, and reporting.

COLABORADORES DEL PROYECTO
  • SAVICS
  • Centro Biomédico de Ruanda
  • OpenMRS
  • DHIS2
  • del Ministerio de Salud (Ministry of Health, MOH) de Rwanda
  • LabWare
  • Autoridad de la Sociedad de la Información de Ruanda (Rwanda Information Society Authority, RISA)
  • OpenHIM
  • Docker

El impacto

  • Registros de clientes e instalaciones

    Los servidores de los registros de clientes y de instalaciones para Ruanda están en funcionamiento.

  • Interoperabilidad

    El núcleo de OpenHIM para la interoperabilidad y todos los mediadores del sistema están en funcionamiento.

  • 6 instancias de OpenMRS

    Se instalaron seis instancias de OpenMRS en el servidor de RHIES

  • Documentación y libro de códigos

    La documentación y el libro de códigos están almacenados en el GitHub público:

    Tres módulos de OpenMRS, formularios de vigilancia basada en casos (case based surveillance, CBS) de OpenMRS, cinco mediadores, registro de clientes y registro de instalaciones

  • Automatización

    Cuando los pacientes se registran en las Historias Clínicas Electrónicas (Electronic Medical Records, EMR) de OpenMRS los trabajadores de atención médica ya no necesitan introducir los datos manualmente, ya que ahora se extrae la información demográfica de la NIDA.

    Los gerentes de datos ya no necesitan introducir manualmente los detalles de la supervisión de casos en DHIS2.

  • Otras mejoras

    En el futuro, el MOH de Ruanda tiene previsto introducir nuevas mejoras en este trabajo:

    Mejorar el registro de clientes mediante la optimización del algoritmo de coincidencia de pacientes, la ampliación de la Interfaz de Programación de Aplicaciones (Application Programming Interface, API) y la introducción de cambios en la interfaz de usuario.

    Desarrollar una Historia Clínica Compartida

    Desplegar instancias 123 OpenMRS en la nube, con el potencial de hacer un bucle en Kubernetes.

El equipo de SAVICS aprendió muchas lecciones en el camino hacia el establecimiento de registros de clientes e instalaciones.
| LECCIONES APRENDIDAS |

El equipo de SAVICS aprendió muchas lecciones en el camino hacia el establecimiento de registros de clientes e instalaciones.

Estos son los puntos más importantes que analizaron a la hora de pensar en los próximos proyectos:

El alcance real de los proyectos debe definirse con antelación para establecer parámetros y expectativas para todas las partes interesadas.

Aclarar los componentes individuales de OpenHIE necesarios para un proyecto junto con el Ministerio de Salud del país.

Aclarar las políticas de intercambio de metadatos antes de iniciar la personalización de OpenMRS o el desarrollo de módulos.

Comprobar la licencia antes de utilizar el código en GitHub mientras se trabaja en un proyecto de código abierto.

Es mejor utilizar Kubernetes o swarm para el despliegue de Docker , incluso cuando el despliegue pueda parecer sencillo.

Establecer un equipo que trabaje en el departamento del HIS del país.

Involucrarse con la comunidad de OpenHIE para aprender de las implementaciones en curso y exitosas.

El enfoque

El primer paso en este proceso fue crear una capa de interoperabilidad utilizando OpenHIM. El equipo utilizó un enfoque de colaboración para establecer el servicio de interoperabilidad. La capa de interoperabilidad permitió a Ruanda afrontar el mayor reto: el intercambio de datos entre los sistemas clave (OpenMRS, LabWare, NIDA y DHIS2).

El segundo paso del proceso fue desarrollar los mediadores: de OpenMRS a DHIS2-e-tracker, de OpenMRS a la NIDA y de LabWare a OpenMRS-LIS NRL. Se creó un módulo para interconectar estos sistemas y también fueron necesarias modificaciones en algunos casos para que los datos pudieran fluir sin problemas.

La creación del registro de instalaciones (JSON-MongoDB) y del registro de clientes (HAPI de Fast Healthcare Interoperability Resources [FHIR]) fue la pieza final de este proceso. Cada nuevo paciente que se ha añadido a los EMR a través de OpenMRS se añade al flujo de trabajo del registro de clientes. De acuerdo con las directrices del Ministerio de Salud, las instalaciones que también estaban presentes en el DHIS2 se guardaron en la base de datos del registro de instalaciones. Tanto los registros de clientes como los de instalaciones se envían automáticamente, en un proceso continuo, a los EMR para mantener la precisión y la documentación actualizada.

La información de los pacientes de atención primaria se ha vinculado a OpenMRS a partir de la base de datos demográficos de los ciudadanos de la NIDA. Los datos de los pacientes individuales pueden introducirse ahora en OpenMRS y los resultados de LabWare se envían automáticamente al EMR del paciente. La información basada en casos del seguimiento nacional del Programa de CBS del VIH se envía automáticamente a DHIS2 y puede vincularse posteriormente a los historiales individuales de los pacientes.

COMPONENTES DE ARQUITECTURA
  • Registro de clientes
    Registro de clientes
  • Registro del centro
    Registro del centro
  • Registros de salud compartidos
    Registros de salud compartidos
  • Capa de interoperabilidad
    Capa de interoperabilidad
  • CAPACIDADES DE OHIE
    • Gestión de la identidad del paciente en todos los sistemas.
    • Vigilancia y notificación de enfermedades.
    • Planificación y gestión de las instalaciones, lo que incluye su identificación única.
  • ASUNTOS DE SALUD ABORDADOS
    • Atención individual al paciente (clínica): gestión de la enfermedad del VIH.
    • Administración de atención médica: instalaciones.
  • FLUJOS DE TRABAJO DE OHIE
    • Validar y guardar datos agregados.
    • Flujo de trabajo para consultar registros de trabajadores de la salud o de instalaciones.
    • Flujo de trabajo para consultar servicios de atención.
    • Flujo de trabajo de búsqueda de servicios de atención.
    • Crear actualización del flujo de trabajo demográfico del paciente.
    • Flujo de trabajo para guardar datos clínicos del paciente.
    • Flujo de trabajo para consultar datos clínicos del paciente.