P23 by Carlos Manrique

P23. Informe de requerimientos y posibilidades de mejoramiento del software del Sistema de Informaci贸n Comunitaria de APS (SICAPS). Daniel Camilo Ram铆rez, M.D. B&M Salud Diciembre de 2011

Tabla de Contenido Introducción

Aplicabilidad del Documento

Visión de Arquitectura

Objetivo del Diagnóstico de Arquitectura

Diagnóstico de Arquitectura de Negocio

Objetivo del dominio de arquitectura de negocio

Contexto del Negocio

Identificación de Involucrados (stakeholders)

Justificación de un Diagnóstico de Arquitectura de Aplicaciones

Procesos soportados Modelo operacional

2 2

Matriz RACI

Modelo de datos de negocio (Modelo del mundo del problema)

Diagnóstico de Arquitectura de Aplicaciones y Tecnología Actual

Objetivos del diagnóstico

Inventario de aplicaciones

Modelo de estructura funcional

Modelo de dependencia tecnológica

Modelo de despliegue

Integración entre aplicaciones

Inventario de Infraestructura

Atributos de Calidad de Aplicaciones

Seguridad

Desempeño

Concurrencia

Arquitectura de Datos Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 2

Objetivo del dominio

Inventario de fuentes de datos

Modelo de Datos Actual

Vista de seguridad de datos

Atributos de Calidad de la Información

Precisión (P)

Accesibilidad (A)

Completitud (C)

Consistencia (F)

Definición (D)

Granularidad (G)

Exactitud (E)

Relevancia (R)

Oportunidad (O)

Resultado de la Calificación de Calidad de la Información

Gobierno de datos definido

Análisis de Problemática Identificada en TI

Objetivo del análisis

Visión de arquitectura y arquitectura de negocio

Lista de problemáticas identificadas

Soluciones sugeridas

Arquitectura de aplicaciones e infraestructura

Lista de problemáticas identificadas

Soluciones sugeridas

Arquitectura de Datos

Lista de problemáticas identificadas

Soluciones sugeridas

Referencias Bibliográficas

3 3

Introducción En el contexto del Plan de Atención Primaria en Salud (APS) para el departamento de Boyacá, se hace indispensable evaluar las soluciones informáticas actualmente usadas por los servicios de salud del departamento, en específico el Sistema de Información Comunitaria de Atención Primaria en Salud (SICAPS). Esto permitirá conocer cómo este sistema se alinea con los objetivos trazados para la atención en salud en el departamento, la utilidad de la información contenida, la integración de los sistemas informáticos y los posibles puntos de mejora. Este diagnóstico provee los elementos de juicio necesarios para tomar decisiones que permitan el aseguramiento de la calidad en los servicios de salud.

Aplicabilidad del Documento El presente documento divide el diagnóstico en dimensiones para facilitar la aproximación a los sistemas informáticos y cómo estos se alinean con los objetivos de la prestación de servicios de salud. Estas dimensiones (Arquitectura de Negocio; Arquitectura de Aplicaciones; Arquitectura de Datos y Tecnología y Análisis de Problemática Identificada en TI) pretenden demostrar los puntos de utilidad y fallas susceptibles de mejora en cada sección del sistema, ofreciendo estos puntos orientados a los procesos y objetivos determinados. Se entiende como arquitectura de un sistema, la combinación de datos, aplicaciones e infraestructura que proveen apoyo a los procesos de una organización1. Este documento permitirá obtener una imagen suficiente de los elementos a considerar en cualquier arquitectura de tecnología de la información y el posible mapa de ruta para su mejora.

Visión de Arquitectura Objetivo del Diagnóstico de Arquitectura Con la visión de arquitectura se pretende: - Evaluar las capacidades actuales del sistema. - Definir el alcance del sistema SICAPS y su articulación con la arquitectura, así como los posibles indicadores que permitan la consecución de los objetivos.

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 4

Diagnóstico de Arquitectura de Negocio Objetivo del dominio de arquitectura de negocio La arquitectura de negocio pretende describir a grandes rasgos los elementos de la organización que son susceptibles de ser soportados por el sistema SICAPS, sus procesos e información contenida.

Contexto del Negocio En esta sección se hace una relación de los objetivos, procesos y servicios ofrecidos a nivel institucional por los servicios de atención primaria en salud de Boyacá. Esto permite conocer los objetivos con los cuales los sistemas de información deben ser conformes. La Secretaría de Salud de Boyacá, en su programa “APS SALUD FAMILIAR” busca proveer planes de atención adecuados para su población, por lo cual dentro de su programa de Atención Primaria en Salud, ha decidido realizar un diagnóstico de todas las familias objeto de la atención en salud dentro del departamento. Para esto, ha diseñado un instrumento de medición, denominado “Tarjeta Familiar”, que permite identificar los miembros de una familia, sus condiciones de salud y las condiciones de entorno presentes que puedan afectar la salud. Esto ha permitido a la Secretaría de Salud de Boyacá generar estadísticas en salud pública acordes a su realidad, que en la actualidad están guiando los proyectos de salud del departamento.

Entre los objetivos de este programa podemos encontrar: - Hacer un diagnóstico de las familias centro de atención primaria del departamento de Boyacá, sus características, condiciones y factores de entorno. - Obtener información de valor en los factores: salud sexual y reproductiva, cumplimiento de vacunación, necesidades básicas insatisfechas, estado de los servicios sanitarios, indicadores de maltrato infantil y familiar, factores nutricionales, enfermedades crónicas, datos de morbi-mortalidad y factores protectores de la familia entre otros. - Diseñar planes de salud acordes con la realidad de las familias del departamento. Para esto, la Secretaría de Salud de Boyacá, adquirió el software SICAPS (Sistema de Información de Base Comunitaria para Atención Primaria en Salud), desarrollado por el CIMDER (Centro de Investigaciones Multidisciplinarias para el Desarrollo 2) de la Universidad del Valle, Colombia. Este sistema provee un instrumento diagnóstico (la “Tarjeta Familiar”) y una pieza de software que permite la digitación de los datos levantados. También incluye una serie de reportes y mecanismos de extracción de datos.

Identificación de Involucrados (stakeholders) Por involucrado (stakeholder) entendemos, una persona o conjunto de personas con un interés en una determinada situación, acción o proceso, enmarcada en el ambiente de las reglas y procesos de una organización. Referente a la arquitectura, cada involucrado (stakeholder) representa una entidad con un interés específico en distintos puntos de la arquitectura, basándose en un conjunto de objetivos, aspiraciones o intenciones para un sistema 3. En la Tabla 1 se detallan los involucrados que fueron identificados. 5

Tabla 1. Involucrados (stakeholders) identificados. Involucrado

Intereses

CIMDER (Centro de Investigaciones Multidisciplinarias para el Desarrollo

- Costo total de desarrollo. - Tiempo de ejecución del proyecto de desarrollo y mantenimiento. - Satisfacción de las expectativas del proyecto.

Gobernación de Boyacá

Costo total del proyecto. Costo proyectado y real del mantenimiento. Satisfacción de las expectativas del proyecto. Consecución de objetivos y planes de desarrollo.

Secretaría de Salud de Boyacá

Costo total del proyecto. Costo proyectado y real del mantenimiento. Costos de entrenamiento y capacitación. Satisfacción de las expectativas del proyecto. Consecución de objetivos y planes de desarrollo.

Ingeniero de Soporte

Mantenibilidad del sistema. Tamaño promedio de los datos. Administración de los datos. Seguridad esperada del sistema. Alcance de los módulos y componentes.

Enfermera/o jefe encargado del APS

Facilidad de uso del sistema. Tamaño promedio de los datos. Completitud y validación de los datos. Soporte ofrecido.

Personal de salud en cada localidad

- Facilidad de uso del sistema. - Tamaño promedio de los datos. - Soporte ofrecido.

Digitador

- Facilidad de uso del sistema. - Soporte ofrecido.

Como puede verse, se detallan los intereses que un involucrado particular puede tener en el sistema, su funcionalidad y elementos. Es importante evaluar cada aspecto del sistema frente a estos intereses. De esta manera puede determinarse si el sistema es adecuado para las necesidades. Justificación de un Diagnóstico de Arquitectura de Aplicaciones Dadas las problemáticas enunciadas anteriormente, puede verse la necesidad de buscar soluciones y mecanismos que le permitan ajustarse a las siempre cambiantes condiciones de la atención en salud, permitiendo ofrecer servicios de gran valor. Sin embargo, la estructuración de estas soluciones requiere ante todo el conocimiento de la problemática del sistema de información SICAPS y los mecanismos que son usados para hacerles frente. Es por esto que se propone la necesidad de un diagnóstico de la arquitectura de aplicaciones, definida como la Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 6

descripción rigurosa de la estructura del sistema, sus entidades, componentes, las relaciones entre estos elementos y sus propiedades internas y externas. Esto dirigido a evaluar la situación actual del sistema y la estructura deseable para conseguir los objetivos establecidos.

Procesos soportados Se describen a continuación, el conjunto de procesos de la organización que son soportados en la actualidad por la plataforma SICAPS. Dentro de los procesos operativos que vela la Secretaría de Salud de Boyacá, se definió un flujo matricial que demuestra a nivel general (macroprocesos) las actividades ofrecidas (Figura 1). Pueden verse resaltados, los macroprocesos que podrían verse apoyados por la plataforma SICAPS. Esta información permite identificar fácilmente como un cambio en el SICAPS impactaría cuales procesos.

Figura 1. Flujo matricial de procesos velados por la Secretaría de Salud de Boyacá.

Puede verse que la información obtenida por medio de la plataforma SICAPS, provee datos de análisis que permiten tanto a la Secretaría de Salud de Boyacá como a las instituciones y empresas prestadoras de servicios de salud definir políticas de promoción y prevención así como la administración de recursos y visitas a la población general.

Modelo operacional El modelo operacional de una organización se centra en dos dimensiones las cuales deben ser tenidas en cuenta a la hora de definir la arquitectura. La primera se refiere al grado de estandarización de los procesos, lo que hace que estos sean estables, predecibles y medibles. La segunda es la integración, que se refiere a la capacidad e interés de la organización de compartir datos e información entre los diferentes procesos del sistema. De esta manera, se puede proponer un panorama de modelos que pueden dar una idea de como la organización opera.

Figura 2. Panorama de modelos operacionales.

Dado este panorama, se puede concluir que la organización se encuentra en la categoría de Diversificación, puesto que posee múltiples unidades (instituciones prestadoras de servicios de salud, centros de atención primaria, etc.) y cada una utiliza procesos que aunque similares, no son únicos. Esto puede contribuir a la dificultad de mantener un modelo de información centralizado y que provea datos consistentes y confiables.

Matriz RACI La matriz RACI relaciona el modelo del flujo de datos que hay al interior de la organización y a quienes son Responsables (Responsible), Dueños de los datos (Accountable), Consultados en caso de modificación (Consulted) y cuales son Informados de estas modificaciones (Informed). En este caso, se decidió utilizar esta matriz para dar pistas sobre las áreas de la organización que tienen presencia y poder de decisión sobre la plataforma. Tabla 2. Matriz RACI. Responsable SICAPS

Ninguno

Dueño Dirección de Salud Pública

Consultado Secretaría de Salud de Boyacá

Informado Municipios

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 8

Responsable

Dueño

Consultado

Informado

APS

Dirección de Prestación de Servicios

Secretaría de Salud de Boyacá

Municipios

Promoción y Prevención

Salud Pública Coordinación Grupo de Vigilancia

Dirección de Salud Pública

Secretaría de Salud de Boyacá

Municipios

De esta manera, la matriz permite entender si son necesarios cambios o mejoras en la plataforma, a quién le pertenecen y si estas áreas tienen poder de decisión dentro de la Secretaría. Puede verse, que cualquier cambio en la plataforma, nueva necesidad o manipulación de la información, afecta a los municipios y debe ser consultado con la Secretaría de Salud en instancias superiores. Sin embargo, las dos áreas que como se apreció en el flujo de procesos son afectadas o soportadas por el SICAPS, no tienen directa responsabilidad en él. Esto significa que al interior de la organización, no existe un directo doliente de la plataforma. Esto puede dificultar la administración, el mantenimiento estable de la información y la evolución futura de la plataforma.

Modelo de datos de negocio (Modelo del mundo del problema) Se desea presentar las entidades que constituyen la organización junto con sus atributos y relaciones. Se entiende por entidad, un elemento constituyente del mundo del negocio que representa un concepto vital para los objetivos. Este modelo muestra la información importante que debe ser manejada por los sistemas y las relaciones entre los conceptos. Se utilizó la notación UML (Unified Modeling Language4) para modelar estos elementos. Figura 3. Modelo de datos de negocio.

Se pueden ver las entidades de importancia para la Atención Primaria. Como punto de apoyo, podemos encontrar a un Persona. Esta Persona, hace parte de una Familia y puede residir en una Vivienda. La Familia debe estar localizada en alguna zona identificada dentro del departamento. Gracias a una Visita, el grupo de salud puede identificar los Factores Protectores y los Factores de Riesgo de una Vivienda, Familia y Persona, de esta manera, generando un Diagnóstico. Con la ayuda de este modelo, es posible identificar los elementos que primordialmente deben generarse en la base de datos del sistema. Comparando este modelo con el diseño de la base de datos, se obtiene un diagnóstico de la utilidad de la base de datos para responder a preguntar de análisis.

Diagnóstico de Arquitectura de Aplicaciones y Tecnología Actual Objetivos del diagnóstico El objetivo de este diagnóstico es definir cómo el SICAPS procesa los datos de la organización y dan apoyo a los procesos descritos, su infraestructura y funciones de aplicación.

Inventario de aplicaciones Se describe a continuación la aplicación SICAPS, la unidad dueña de la aplicación, sus objetivos, las funcionalidades de la organización soportadas, la plataforma de hardware y software y el modelo de integración. Tabla 3. Inventario de aplicaciones.

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 10

Aplicación

Descripción

SICAPS

Sistema de Información de Base Comunitaria para Atención Primaria en Salud. El sistema mantiene los datos recopilados de la aplicación de la Tarjeta Familiar, genera reportes básicos y consolidad la base de datos.

CIPES

Aplicación generadora de reportes del sistema SICAPS. Permite generar reportes en formato de texto plano y en formato Microsoft ® Excel para usarlo en tablas dinámicas.

Modelo de estructura funcional Este modelo muestra los componentes de software y como se relacionan. Esto se hace, haciendo una descomposición por los diferentes módulos que componen las aplicaciones, identificando los actores del sistema y sus casos de uso (funciones dentro del sistema). La notación utilizada fue UML (Unified Modeling Language 4). La Figura 4 muestra esta descomposición.

Figura 4. Modelo de estructura funcional.

Puede verse en el diagrama, que la aplicación SICAPS está conformada por un módulo de aplicación (donde se integran todas las funciones) y un módulo que constituye la base de datos, que se maneja en forma de archivos planos. A su vez, la aplicación CIDES (que produce reportes) se encuentra integrada como un solo componente, que recibe como entrada los archivos de la base de datos. Estas aplicaciones se consideran por tanto monolíticas, al no tener módulos que repartan la funcionalidad y permiten su uso por otras aplicaciones. Las aplicaciones fueron programas en Microsoft ® Visual Fox Pro, utilizando archivos planos para el almacenamiento de la información. De esta manera, la base de datos se encuentra en archivos con la extensión “.dbf”, que sólo pueden ser accedidos por medio de la aplicación. Es posible importar estos archivos manualmente a un servidor de base de datos (tal como Microsoft® SQL Server) mediante scripts o herramientas comerciales para tal fin5. Esto implica importantes dificultades para la manipulación de los datos y la obtención de análisis. Aunque es posible utilizar esta información mediante el método descrito, es imposible alterar los archivos originales fuera de la aplicación. Esto impide realizar análisis confiables o mantener automáticamente la consistencia de la información. Se considera entonces que el formato de la base de datos es otro punto de falla. Los actores identificados dentro del sistema fueron: 11

• •

Administrador: Este usuario tiene las funciones máximas dentro del sistema. Puede crear usuarios y tiene la responsabilidad sobre las funciones de la base de datos. Digitador: Este usuario tiene la capacidad de introducir datos al sistema y hacer consultas básicas.

Estas funciones pueden verse en la Figura 5 y 6.

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 12

Figura 5. Casos de uso - Usuario administrador.

Figura 6. Casos de uso - Usuario digitador.

Pueden observarse las diferentes funciones ofrecidas por el sistema para los usuarios. Modelo de dependencia tecnol贸gica Este modelo demuestra los sistemas y los requerimientos de software y tecnolog铆a para cada plataforma.

Tabla 4. Modelo de dependencia tecnol贸gica.

Aplicación

Infraestructura Requerida

SICAPS

Microsoft® Windows XP/Vista/7 .NET Runtime Environment VB6 Runtime Environment 1 GB de RAM 1,5 GHz de procesador de doble núcleo. 500 MB de Disco Duro (instalación básica - sujeto al crecimiento de la base de datos).

CIPES

Microsoft® Windows XP/Vista/7 .NET Runtime Environment VB6 Runtime Environment 1 GB de RAM 1,5 GHz de procesador de doble núcleo. 500 MB de Disco Duro

Modelo de despliegue Este modelo muestra como se distribuyen los diferentes componentes sobre los elementos físicos de la arquitectura.

Figura 7. Modelo de despliegue.

El modelo de despliegue muestra que las aplicaciones se instalan en cada máquina de usuario, para quien requiere su utilización. De esta manera, cuando se requiere la funcionalidad, se hace una instalación nueva, creando nueva base de datos y módulos.

Integración entre aplicaciones A continuación puede verse una relación del SICAPS y la forma en como se integra o comunica con otros sistemas existentes.

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 14

Tabla 5. Matriz de integración entre aplicaciones. SICAPS

CIPES

SICAPS

Integración a nivel de datos por archivos de lotes

Integración por lectura de base de datos

CIPES

No existe integración

Entre distintas instalaciones del SICAPS (que actualmente es necesario para poder utilizar el sistema, realizar instalaciones independientes) es posible integrar los datos por medio de archivos comprimidos que contienen la base de datos de un sistema local. De esta manera, el sistema ofrece la capacidad de exportar la base de datos local en un archivo comprimido que a su vez puede ser importado en otra instalación del SICAPS. Esto evidencia una importante problemática: dado que cada instalación del SICAPS es independiente, al importar los datos puede presentarse inconsistencias en la información. Esto se soluciona de manera manual por el ingeniero de soporte ingresando por la aplicación a cada registro importado y validando la información. El CIPES a su vez, puede leer la base de datos del SICAPS, con el fin de generar reportes. SICAPS no ofrece ningún otro mecanismo de integración, lo que evidentemente limita el crecimiento de la plataforma.

Inventario de Infraestructura Como se describió, las aplicaciones evaluadas sólo permiten un modelo de instalación por máquina, implicando que cada aplicación con su base de datos debe residir en una máquina independiente. De esta manera, se identificaron las máquinas que actualmente poseen una instalación del SICAPS. Tabla 6. Aproximado de máquinas que poseen las aplicaciones en Boyacá. Lugar

SICAPS

CIPES

Secretaría de Salud de Boyacá

Municipios con 2 máquinas (aproximado)

Municipios con 1 máquina (aproximado)

Total de instalaciones

173

Esto representa un número alto de máquinas que generan información para el SICAPS y por tanto, una problemática de integración de datos importante. Dado que cada instalación es independiente y la importación de datos presenta grandes posibilidades de inconsistencias, es evidente que los puntos de falla para el manejo de la información es elevado (en las 173 máquinas).

Atributos de Calidad de Aplicaciones 15

Se considera un atributo de calidad como las características no funcionales que son deseables para un sistema. Se entiende un software de calidad como aquel que exhibe una cierta combinación de estas características6. Estos atributos pueden ser evaluados dependiendo de cada dimensión de arquitectura, como atributos a nivel de la aplicación, de la infraestructura o de los datos. Para realizar un diagnóstico adecuado del SICAPS es necesario evaluar estos atributos de calidad a la luz de las necesidades. Seguridad Se considera la seguridad como la protección que ejerce el sistema contra el acceso, modificación, o destrucción de sus datos, o de sus elementos de software o hardware 6. Los mecanismos que aseguran la seguridad pueden ser técnicos y administrativos. La aplicación utiliza un medio de autenticación por usuario, al ingresar a la plataforma. Este ingreso puede ser configurado en la instalación básica del sistema y mediante el usuario Administrador para el resto de los usuarios. Dada la naturaleza cerrada del sistema, no es posible identificar los mecanismos de autenticación utilizados ni si los algoritmos de codificación de las contraseñas tienen las características suficientes para mantener una seguridad adecuada. Se debe resaltar que los mecanismos de autenticación solamente se encuentran garantizados a nivel de la aplicación, no a nivel de la base de datos. Desempeño Se refiere a la capacidad de un sistema a responder ante eventos en un periodo establecido de tiempo6. Esto significa que se espera que el sistema responda a las solicitudes en un periodo razonable, sin retardos ni alteraciones. El desempeño percibido de la plataforma es aceptable dentro de los parámetros de uso normales. El ingreso de información y la consulta de datos no presenta retrasos superiores a 1 segundo. Sin embargo, cabe anotar que la generación de reportes y análisis de los datos se ha visto incrementado desde hace aproximadamente 1 año, teniendo tiempos de generación de en promedio 4 horas por reporte. Esto impacta las actividades dentro de la plataforma e inhabilita las máquinas donde se encuentra instalado el sistema. Concurrencia Se entiende como la propiedad de un sistema de ejecutar acciones o funciones simultáneamente7. Esto usualmente implica el acceso simultáneo de dos o más usuarios a la funcionalidad de la plataforma o a sus datos. Dada la naturaleza monolítica de la plataforma, no se tienen mecanismos de acceso concurrente a la plataforma. Significa que no es posible que más de un usuario tenga acceso a la información al mismo tiempo. No es posible por tanto, compartir el mismo conjunto de información en un determinando momento, disminuyendo la oportunidad de acceso a la información y generando un punto de falla sobre la consistencia de los datos.

Arquitectura de Datos Objetivo del dominio El objetivo de este dominio es el de definir los principales tipos de datos y sus principales fuentes, para aquellos datos que son necesarios para soportar los objetivos de la organización.

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 16

Es importante notar que este esfuerzo no intenta realizar un diseño detallado de los objetos de bases de datos. El objetivo es definir entidades de negocio que sean relevantes para la organización, pero no el de detallar los sistemas locales o físicos de almacenamiento.

Inventario de fuentes de datos A continuación se describen las diferentes fuentes de datos identificadas en el análisis de la organización. La única fuente de información es la base de datos del SICAPS, donde se ingresa la información de cada localidad. Por decisión de la Secretaría de Salud de Boyacá, se estableció una máquina donde se mantiene la información integrada de todo el departamento. Actualmente, un ingeniero de soporte se encarga de realizar esta integración importando manualmente cada respaldo de información enviado por todos los municipios y localidades. Esta actividad es realizada 2 veces al año. Posteriormente el ingeniero debe revisar cada registro inconsistente de forma individual, resolviendo los problemas de integración. Dado que la base de datos sólo puede ser ingresada por medio de la aplicación, no es posible identificar todos los registros inconsistentes. Se considera que existe un porcentaje desconocido de inconsistencias en la base de datos centralizada. Dado que las importaciones se realizan 2 veces por año, en cualquier instante del tiempo los registros tienen una antigüedad de 6 meses a 1 año.

Figura 8. Diagrama de red con las fuentes de datos.

Como puede verse, existen múltiples fuentes de datos, cada una con una instalación independiente de la base de datos. Se decidió mantener esta información integrada de en una máquina designada como central, sin embargo, esta integración se hace de forma manual y sin mecanismos que validen la información, siendo un punto de falla que genera inconsistencias. Adicionalmente, se mantiene una copia de la información de la máquina central en un servidor de respaldo y en discos ópticos (CD’s). Ninguna de estas copias tienen mecanismos de validación. 17

Adicionalmente, se describió una alta rotación del personal principalmente a nivel de los municipios, lo que dificulta mantener una política estable del manejo de la información generada a ese nivel.

Modelo de Datos Actual Como se comentó en secciones anteriores, la base de datos se encuentra en archivos planos. Los archivos se encuentran en formato “.dbf” que representan tablas en Microsoft® Visual Fox Pro. Dado que no es posible observar los datos directamente, se debe inferir el modelo de datos siguiendo los archivos guardados. Los archivos (y por tanto las tablas) en la base de datos son: • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Actividad Adulmay (representa los datos del adulto mayor) Claves Encuest (aparentemente representa el objeto de la visita) Foxuser (posiblemente guarde los usuarios) Gespaypp (representa los datos de una gestante, su parto y puerperio) Hom40a59 (representa un hombre de 40 a 59 años) Hym10a52 (representa una persona de 10 a 52 años) Institucion (representa las instituciones) Menoruno (representa una persona menor a un año) Morbilid (representa la morbilidad identificada en la familia) Mortalid (representa la mortalidad identificada en la familia) Muj10a59 (representa una mujer de 10 a 59 años) Nino1a4 (representa un niño de 1 a 4 años) Niv1dpto (representa el código geográfico del departamento) Niv2mcpo (representa el código geográfico del municipio) Niv3area (representa el código geográfico del área) Niv4cyc (representa el código geográfico de la comunidad o corregimiento) Niv5byv (representa el código geográfico del barrio o vereda) Niv6man (representa el código geográfico de la manzana) Personas (representa a las personas de la familia) Tabla_perimetro (representa los datos de perímetro cefálico para consulta) Tabla_peso (representa los datos de peso para consulta) Tabla_peso_talla_0a2 (representa los datos de relación peso y talla en niños de 0 a 2 años para consulta) Tabla_peso_talla_2a5 (representa los datos de relación de peso y talla en niños de 2 a5 años para consulta) Tabla_talla (representa los datos de talla para consulta) Tarjetaf (representa la tarjeta familiar, siendo posiblemente la tabla principal) Tce2 Tce

Como puede verse, el modelo de la base de datos refleja casi exactamente la estructura que fue diseñada para las tarjetas familiares físicas. Esto posee las siguientes ventajas: 1. Facilita el desarrollo de la aplicación al proveer los datos por sección y pantalla que se quiere visualizar en determinado momento. Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 18

2. Facilita la generación de reportes que soliciten los datos específicos de secciones de la tarjeta. 3. Provee un mecanismo seguro de alteración de los atributos de cada sección de la tarjeta familiar. Esto significa que si se desea añadir una nueva sección o nuevos atributos, no representa mayor dificultad. Sin embargo, el modelo de datos actual, posee importantes desventajas, entre las cuales podemos nombrar: 1. Al no encontrarse en una base de datos aparte, es imposible manipular los datos de una manera distinta a como lo hace la aplicación. Esto impide realizar análisis más profundos, generar proyecciones o administrar el crecimiento de la base de datos eficientemente. 2. Los datos no se encuentran normalizados, implicando que obtener información de valor desde la base de datos es una labor dispendiosa y en ocasiones imposible. Responder preguntas específicas podría requerir un trabajo y un alto costo que debería hacerse manualmente. 3. La entidad principal de la base de datos claramente es la Tarjeta Familiar, siendo la llave principal el código de 6 niveles de localización geográfica. Esto representa importantes problemas al momento de ingresar información nueva. Por ejemplo, si una persona se muda de hogar y crea una nueva familia, no existe un mecanismo adecuado de representar esta información en el modelo de datos actual, sin incurrir en duplicidad de información y por tanto inconsistencias. El modelo tampoco considera el evento Visita (y el tiempo en que fue realizada) de forma correcta, implicando que es posible dañar información anteriormente cargada al generar una nueva Tarjeta Familiar para una familia ya existente. Por último no considera el evento en que una persona o familia se traslade de ubicación geográfica, lo cual genera inconsistencias en la información. 4. Dado que la representación de la información muestra adecuadamente la Tarjeta Familiar pero no los elementos del problema (ver sección “Modelo de Datos de Negocio”), y la plataforma tecnológica utilizada impide el manejo libre de esta información, el mantenimiento de la información, la evolución de la plataforma y la escalabilidad de los datos son imposibles. No es posible controlar el crecimiento de la información y esto por consiguiente implica altos costos si se desea crecer la plataforma en atributos o funcionalidad. 5. Como los datos se encuentran representados en una forma útil para la visualización humana (esto es, la Tarjeta Familiar) pero no para la manipulación de los mismos, diversos atributos de calidad se ven afectados. El desempeño de manejo de los datos se ve reducido de forma evidente, al dar tiempos elevados de generación de reportes (de más de 4 horas). Esto se va a hacer cada vez más evidente en la medida en la que crezca la información cargada al sistema. Como puede verse, las desventajas del modelo actual de datos supera sus ventajas. Las características deseables del sistema (desempeño, confiabilidad de los datos, capacidad de generar análisis) se verán afectadas cada vez más por el modelo actual de la información. En la medida que la base de datos crezca, estos factores se verán alterados y posiblemente impidan finalmente la utilización práctica de la plataforma.

Vista de seguridad de datos

El propósito de este punto de vista es describir que actor (entre personas, unidades o sistemas) pueden acceder a cual conjunto de datos de la organización. Los datos se mantienen en archivos planos en cada máquina independiente. Tabla 7. Vista de seguridad de datos. Actor

Localización

Tipo de Acceso

Administrador

- Local

Control de Acceso por Aplicación

Digitador

- Local

Control de Acceso por Aplicación

Ingeniero de Soporte

- Local

Control de Acceso por Aplicación

Los actores pueden interactuar con los datos a través de la aplicación utilizando el mecanismo de autenticación provisto. Sin embargo, el acceso a los datos se hace por archivos planos, lo que significa que la tablas pueden ser importadas mediante scripts a una base de datos comercial, implicando que no existen mecanismos de seguridad a nivel de los datos. Esto significa que los datos a ese nivel no son seguros, por lo que pueden ser accedidos o destruidos, dañando la instalación de la aplicación.

Atributos de Calidad de la Información En términos de información, los atributos de calidad, representan características que debe poseer la información para considerarse útil. Dados los requerimientos especiales del ámbito de la salud, deben considerarse atributos de calidad definidos de forma estándar para este dominio. La American Health Information Management Association (AHIMA), ha definido una serie de principios de manejo de información en salud, asociados a los procesos clave de atención clínica. Asegurar estos principios implica una necesidad para todos los sistemas de información en salud y establece una línea base para la calidad de estos sistemas a nivel global. Conseguir estos principios depende en gran medida de los atributos de calidad de la información manejada; en la tabla X pueden verse los atributos de calidad y como cada uno permite alinear la organización con los principios de manejo de información en salud. Para hacer un diagnóstico adecuado de los atributos de calidad de la información manejada por el SICAPS, se decidió calificar por cada atributo de manera cuantitativa de 1 a 5, siendo 5 la máxima calidad posible. Finalmente, se obtuvo un promedio de las calificaciones cualitativas para dar una idea de la calidad de la información y su manipulación.

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 20

Tabla 8. Atributos de calidad de la información y principios de manejo de información en salud (Adaptado de 8). Principios

1. Soportar la calidad y seguridad en la atención clínica

2. Soportar requerimientos regulatorios/acreditación

3. Liderazgo y estandarización de los datos como principio estratégico

X X

4. Educación y transferencia de conocimiento

5. Soportar iniciativas cooperativas y estandarización de datos

7. Desarrollar y mantener estándares de contenido

8. Mantener diccionario de datos 9. Coordinar integración de datos entre sistemas

10. Ayudar al personal médico a adoptar estándares de contenido

X X

11. Proveer soporte para los esfuerzos de interoperabilidad

13. Asegurar la seguridad de los datos

14. Asegurar la privacidad de los datos

15. Proveer datos de calidad para soportar decisiones clínicas y de salud pública

6. Desarrollar diccionario de datos y mapeo de datos

12. Vincular los dominios clínicos y tecnológicos

X X

Dado esto, cada atributo de calidad contribuye a los aspectos de manejo de la información en salud. A continuación una relación de los atributos de calidad y su diagnóstico en el SICAPS. Precisión (P)

Este atributo asegura que los datos poseen valores correctos, válidos y vinculados con el paciente o familia correctos. En el caso del SICAPS, se pudo apreciar que dado el modelo de datos actual, la información contenida es precisa para la tarjeta familiar. Lamentablemente el Precisión

Atributos de Calidad de Información

Accesibilidad Completitud Consistencia Definición Granularidad Exactitud Relevancia Oportunidad

modelo de datos puede presentar valores incorrectos a un determinado momento del tiempo dada la problemática de integración de datos. Calificación: 4. Accesibilidad (A) Se refiere a que los datos son fácilmente obtenibles y cuando es necesario, es posible acceder a ellos, siguiendo protecciones y controles construidos dentro del proceso. SICAPS provee un esquema de seguridad básico a nivel de la aplicación, sin embargo, no posee otros mecanismos de fácil acceso por parte de otros sistemas o programas. Esto limita el intercambio de información y su análisis. Calificación: 2. Completitud (C) Implica que todos los datos requeridos están incluidos, asegura que los datos tengan el alcance deseado y documenta las limitaciones intencionales. Para el SICAPS, se pudo observar que la definición de los datos en la Tarjeta Familiar contiene la mayoría de los datos requeridos por los procesos. Dada la estructura de la Tarjeta, es posible limitar los datos a lo estrictamente necesario. Sin embargo, se identificó como necesario añadir información de APGAR a los niños menores de un año e información de plan de cuidado. Calificación: 4. Consistencia (F) Se define la consistencia como la capacidad de un sistema de mantener datos confiables e iguales entre copias y/o aplicaciones. Para el SICAPS, se pudo ver que existen numerosas copias en las diferentes máquinas dada la arquitectura monolítica del sistema. Aunque existen mecanismos de exportación e importación de los datos, la base de datos no mantiene reglas de consistencia de la información, obligando a la revisión manual y por cada registro. Esto produce grandes probabilidades de daño de consistencia de la información. Calificación: 2.

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 22

Definición (D) Los datos poseen definiciones clara y éstas mantienen el significado de cada atributo. Esto significa, que los datos poseen valores escalares y son medibles. En el caso del SICAPS, la Tarjeta Familiar y el modelo de datos proveen información adecuadamente definida. Calificación: 4. Granularidad (G) Los atributos y sus valores están definidos a un nivel de detalle correcto. Para el SICAPS, pudo verse que la granularidad de los datos es adecuada para los procesos de análisis. Calificación: 4. Exactitud (E) Los valores de los datos son lo suficientemente grandes para soportar los procesos de análisis y los mecanismos de control de datos están diseñados para manejar esta cantidad de datos. En el SICAPS, se espera tener un conjunto de datos grande, que representa la totalidad de las familias del departamento. La Tabla 9 muestra la cantidad de tarjetas familiares iniciales que se deben tener en el sistema.

Tabla 9. Cantidad de registros iniciales en la base de datos. Municipio ALMEIDA AQUITANIA ARCABUCO BELEN BERBEO BETEITIVA BOAVITA BOYACA BRICEÑO BUENAVISTA BUSBANZA CALDAS CAMPOHERMOSO CERINZA CHINAVITA CHIQUINQUIRA CHIQUIZA CHISCAS CHITA CHITARAQUE CHIVATA CHIVOR CIENEGA COMBITA COPER CORRALES COVARACHIA CUBARA CUCAITA CUITIVA DUITAMA EL COCUY EL ESPINO FIRAVITOBA FLORESTA GACHANTIVA GAMEZA GARAGOA GUACAMAYAS GUATEQUE GUAYATA GUICAN IZA JENESANO JERICO LA CAPILLA LA UVITA LA VICTORIA LABRANZAGRANDE MACANAL MARIPI MIRAFLORES MONGUA MONGUI MONIQUIRA MOTAVITA MUZO NOBSA NUEVO COLON

Número de Registros 495 2823 880 1538 383 382 1157 831 282 1042 113 663 666 768 768 9025 877 900 1650 1000 767 334 880 1595 700 440 549 882 662 331 18400 900 600 1102 664 550 775 2917 386 1979 1537 879 334 1428 770 660 661 275 992 880 1145 1817 881 774 3850 768 1750 2419 1046

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 24

Municipio OICATA OTANCHE PACHAVITA PAEZ PAIPA PAJARITO PANQUEBA PAUNA PAYA PAZ DEL RIO PESCA PISBA PUERTO BOYACA QUIPAMA RAMIRIQUI RAQUIRA RONDON SABOYA SACHICA SAMACA SAN EDUARDO SAN JOSE DE PARE SAN LUIS DE GACENO SAN MATEO SAN MIGUEL DE SEMA SAN PABLO DE BORBUR SANTA MARIA SANTA ROSA DE VITERBO SANTA SOFIA SANTANA SATIVANORTE SATIVASUR SIACHOQUE SOATA SOCHA SOCOTA SOGAMOSO SOMONDOCO SORA SORACA SOTAQUIRA SUSACON SUTAMARCHAN SUTATENZA TASCO TENZA TIBANA TIBASOSA TINJACA TIPACOQUE TOCA TOGUI TOPAGA TOTA TUNJA TUNUNGUA TURMEQUE TUTA TUTAZA UMBITA VENTAQUEMADA

Número de Registros 387 1758 606 606 4728 400 328 1646 386 989 1541 221 8900 1485 1649 1648 551 2091 551 2537 385 988 1100 881 663 1485 800 1870 554 1209 550 221 1104 1597 1266 1650 20792 662 388 878 1400 600 1046 881 1155 936 1762 2092 550 659 1450 826 657 933 27600 384 1375 1433 383 1485 2095

Municipio

Número de Registros

VILLA DE LEYVA VIRACACHA ZETAQUIRA Total

1706 656 950 209587

Este conjunto de datos muestra una suficiente cantidad de registros que pueden soportar las necesidades de análisis. Sin embargo, la base de datos no tiene mecanismos de control de la información y como es manipulada, por lo cual el tamaño de los datos representa un problema disminuyendo el desempeño percibido del sistema. Por otro lado, también incrementan los puntos de falla en cuanto a los otros atributos de calidad, como la consistencia. Claramente un conjunto de datos mínimo tan grande requiere de una base de datos más robusta que la que actualmente está implementada. Calificación: 3. Relevancia (R) Los datos son significativos para el desempeño de los procesos o aplicaciones para lo cual son recolectados. SICAPS en la mayor parte de su información provee información relevante para los procesos. Sin embargo, el manejo de estos datos se ve dificultado por el propio modelo de datos, lo cual le resta calidad a la relevancia. Calificación: 4. Oportunidad (O) Determina que los datos se encuentran actualizados y están disponibles cuando son requeridos por el proceso. SICAPS provee la información necesaria, pero dado el modelo de datos, la arquitectura monolítica de la aplicación y el manejo de la integración de datos, es posible que la información no se encuentra totalmente actualizada y mantenga datos incorrectos. Calificación: 1. Resultado de la Calificación de Calidad de la Información En la Tabla 10, se resume la calificación de los atributos de calidad de la información. Se puede ver la calificación promedio.

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 26

Tabla 10. Calificación de Calidad de la Información. Atributos

Precisión Accesibilidad Completitud Consistencia Definición Granularidad Exactitud Relevancia Oportunidad

Promedio

31/50

La calificación final muestra que en términos de calidad de la información, los datos contenidos permiten hasta cierto punto la producción de valor. Sin embargo, la calidad de entrada de los datos no es suficiente para los requerimientos de información de la Secretaría de Salud de Boyacá. En la Figura 9 se muestra el impacto que presentan las calificaciones sobre los principios establecidos de manejo de la información.

Figura 9. Impacto de la calificación de calidad sobre los principios de manejo de información.

Se relacionó la calificación de cada principio con su impacto relativo sobre cada principio., de tal manera que se pudo obtener un valor de impacto. En la gráfica, entre más cerca esté un valor de 1, más beneficio tiene sobre el principio. Esto implica que para 10 de los principios de 27

manejo de la información, la calidad de los datos evita la consecución del principio. Para 4 principios, hay un cierto beneficio y 1 no presenta efecto alguno. Los principios más afectados son: - Soportar requerimientos regulatorios/acreditación. - Coordinar integración de datos entre sistemas. - Mantener seguridad de los datos. Esto implica que para obtener resultados costo/efectivos en los planes de mejoramiento, es necesario comenzar por proyectos y actividades que mejoren estos tres principios.

Gobierno de datos definido El gobierno de datos describe el conjunto de procesos que aseguran que los activos de información vitales para la organización son formalmente administrados. Actualmente se han definido los siguientes procesos: 1. Integración de los datos: cada municipio exporta su base de datos dos veces al año. En el computador designado como central, se importan todos los datos. En caso de inconsistencia, se revisa manualmente cada registro para repararlas. 2. Manejo de consistencia: la consistencia se revisa únicamente cuando se integran los datos. La aplicación ofrece un mecanismo de reparación automática de consistencia, sin embargo este mecanismo no repara la totalidad de los elementos. 3. Respaldo de información: el ingeniero de soporte genera un respaldo de los datos cuando lo considera necesario, creando una copia de la información central en un servidor de respaldo y en ocasiones en CD’s. No existen mecanismos de control de versiones ni de recuperación parcial de información.

Análisis de Problemática Identificada en TI Objetivo del análisis Dado el diagnóstico realizado anteriormente, es posible tomar elementos de cada dominio de diagnóstico e identificar las problemáticas descritas. Esto junto a la situación objetivo deseada permite describir los puntos de sensibilidad y las posibles mejoras al sistema SICAPS.

Visión de arquitectura y arquitectura de negocio Lista de problemáticas identificadas 1. La aplicación SICAPS como plataforma soporta y contribuye a los procesos de realización de visitas extramurales y la generación de políticas de promoción y prevención en salud. Esto implica que su impacto es importante dado que estos procesos se consideran la base de la cadena de valor de la Secretaría de Salud de Boyacá, sus procesos y generación de políticas. 2. En cuanto al modelo operacional de la Secretaría de Salud, se encontró que los procesos soportados por la plataforma son diversificados: esto implica que se cuenta con numerosas unidades de atención cada una con procesos independientes para la obtención de los datos. Esto es útil dada la gran cantidad de información a recolectar (esto es, la gran cantidad de familias a visitar y la dispersión geográfica de las mismas). Sin embargo, el modelo podría generar situaciones en las cuales se obtengas resultados muy variados de cada ejercicio de recolección de información. Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 28

3. La problemática identificada más importante en este dominio, es la ausencia de un responsable directo de la plataforma. En una plataforma de tal importancia (puesto que soporta procesos vitales para la Secretaría), es necesario que exista un responsable directo de la aplicación y sus datos, y este responsable usualmente debe tener un poder de decisión sobre el manejo de las políticas que impactan esta información. Es decir, el responsable debe tener un cargo elevado dentro de la Secretaría de Salud de Boyacá.

Soluciones sugeridas 1. Se le debe dar la importancia requerida a la plataforma dada su importancia en los procesos de la Secretaría de Salud. Se sugiere que se incluya dentro de los planes anuales de desarrollo de sus políticas. 2. Se sugiere que se lleve a cabo una estandarización de los procesos de toma y manejo de la información de las familias. Lo ideal es que estos procesos se repliquen adecuadamente en cada unidad de atención. 3. Se sugiere que se asigne un responsable de alto nivel en cuanto al manejo y desarrollo de la plataforma, de tal manera que su evolución esté atada a las políticas de la propia Secretaría de Salud.

Arquitectura de aplicaciones e infraestructura Lista de problemáticas identificadas 1. La arquitectura de la aplicación es de naturaleza monolítica. Esto significa que la aplicación se encuentra completamente cerrada y el acceso a los datos es imposible en su estado original. Añadir funcionalidades nuevas es costoso y no existen posibilidades de integración de la plataforma con nuevos sistemas (tal como administradores de historias clínicas, sistemas de control de inventarios, etc.). En cualquier caso, las mejoras deben ser realizadas siempre con el proveedor original y probablemente esto sea costoso dada la propia arquitectura. Finalmente, las posibilidades de crecimiento horizontal de la plataforma son nulas. 2. La base de datos de la aplicación está en archivos planos (formato “.dbf”) y no se puede manipular en su estado original. Esto implica que el análisis de la información presenta gran dificultad y es imposible anclar programas de reporte o minería de datos que puedan sacar nuevos datos de valor. El análisis es probable, pero costoso. 3. No existen mecanismos confiables a nivel de la aplicación que aseguren una integración adecuada de los datos frente a las numerosas fuentes de información. El proceso de integración de la información debe realizarse de manera manual y resulta en retrabajo, situación que potencialmente eleva los costos de mantenimiento de la plataforma. 4. Dada la arquitectura monolítica de la aplicación, que obliga a tener una instalación completa del sistema en cada unidad de atención, se presenta un problema en cuanto a la gobernabilidad de la información. Los puntos de falla de los procesos de integración de datos son altos y esto podría disminuir la calidad de la información, a la vez que eleva costos en la administración. 5. En cuanto a la seguridad, la aplicación ofrece un modelo de autenticación básico a nivel de la aplicación. Las regulaciones Colombianas con respecto al manejo de la información clínica (Resolución No. 1995 de 1999, ISO/IEC 27001:2005 y la NTC ISO/IEC 27005) colocan directrices severas con respecto a los procesos y condiciones de la seguridad. La plataforma no posee en la actualidad los atributos necesarios para cumplir estas normas. 6. La arquitectura actual y su modelo de información llevan a un desempeño percibido bajo. Esta problemática se incrementará con el paso del tiempo en la medida que el tamaño de la base de datos crezca. 29

7. No existe un modelo actualmente de acceso concurrente a los datos. Esto lleva a que la oportunidad de la información disminuya dado que la información no siempre esta disponible para los procesos. Soluciones sugeridas 1. La arquitectura de la aplicación podría mejorarse para incluir una serie de “adaptadores” (mecanismos que permitan su integración con otros sistemas) y tener un diseño más flexible que permita añadir fácilmente nueva funcionalidad. Sin embargo, esta alteración en la arquitectura representará un costo. 2. Se sugiere que la base de datos sea migrada a un Sistema Manejador de Base de Datos comercial establecido. Este sistema puede ser relacional (Oracle ® MySQL, Microsoft® SQL Server, InnoDB® PostgreSQL, etc.) o no (Google® BigTable, VMWare GemStone, 10gen ® MongoDB, etc.). Lo importante es ofrecer mecanismos de normalización de la información, condiciones de integración de datos y la capacidad de obtener información de valor y reportes. 3. Al migrar los datos, es posible generar mecanismos de integración y validación de la información desde la propia base de datos. 4. Es adecuado generar procesos estándares de gobernabilidad que asuman los procesos de integración de la información y manejo de las instalaciones en cada unidad de atención. 5. Al migrar los datos a un Sistema Manejador de Base de Datos, se pueden crear políticas de seguridad a nivel de la base de datos, alineándose con las regulaciones actuales. 6. El modelo de datos debe ser actualizado, para ser normalizado y reflejar de mejor manera los elementos del problema de negocio expuestos. Esto facilitará la manipulación de la información y permitirá que el acceso a los datos sea eficiente, mejorando sustancialmente el desempeño de la plataforma. 7. Al migrar la base de datos, es posible ofrecer una arquitectura Cliente/Servidor, que permita el acceso concurrente y oportuno de los datos.

Arquitectura de Datos Lista de problemáticas identificadas 1. La arquitectura actual obliga a tener múltiples instalaciones de la base de datos, por cada dispositivo de ingreso de información. Esto lleva a que exista un alto número de fuentes de datos, que podría ser un punto de falla para la integración y consolidación de la información. 2. Se describió una alta rotación del personal que maneja las bases de datos individuales de cada unidad de atención. Esto sumado a una baja estandarización de los procesos de gobernabilidad de la información lleva a que la calidad de los datos se vea disminuida. 3. El modelo de datos no refleja adecuadamente los elementos del mundo del problema. La clave de codificación es la ubicación geográfica de una familia, modelo que desconoce los elementos individuales que la componen (esto es, cada persona) lo que lleva a un crecimiento de la información que dificulta la manipulación de los datos. 4. El modelo de datos no se encuentra normalizado, dificultando la manipulación de la información y generando posibles inconsistencias. 5. Dado el modelo de datos actual, las posibilidades de escalamiento de los datos son limitadas. Es probable que la problemática de escalamiento (datos inconsistentes, dificultad de análisis y disminución del desempeño) empeore a medida que el tamaño de la base de datos crezca. 6. La plataforma actual cumple parcialmente con los atributos de calidad de la información clínica. Sin embargo, estos atributos impactan negativamente los principios de manejo de la información en salud y pueden llevar a una disminución evidente de la calidad de la información. Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 30

Soluciones sugeridas 1. Se sugiere que con la migración de los datos a un Sistema Manejador de Bases de Datos, se implementen políticas de integración de la información a nivel tecnológico y administrativo. El modelo final de datos debe tener en cuenta la fragmentación y localización de la información, de tal manera que se pueda acceder a los datos de forma eficiente y se pueda integrar centralmente la información sin pérdida de la calidad. 2. Los procesos de gobernabilidad de los datos en cada unidad de atención deben estandarizarse. Esto permitirá que a pesar de la alta rotación del personal se cuenten con medidas de aseguramiento de la calidad en los datos. 3. El modelo de datos debe ser reestructurado para reflejar de forma más adecuada el mundo del problema de negocio. 4. La reestructuración del modelo de datos debe contemplar la normalización de la información, de tal manera que se facilite la manipulación de la información. 5. El modelo de datos final debe tener en cuenta los aspectos de fragmentación y localización de la información en las diferentes unidades de atención. Esto permitirá que el modelo pueda ser escalado y crecer adecuadamente. El acceso podrá ser eficiente al manejar conjuntos de datos pequeños. 6. Según el análisis de calidad de la información, actualmente se obtiene un valor determinado de la información, que es adecuado para las necesidades actuales de la Secretaría de Salud de Boyacá. Sin embargo, existen numerosas posibilidades de mejora para cada principio de manejo de la información en salud. Por costo/efectividad, se sugiere que se generen iniciativas y proyectos alineados con la mejora de los principios de regulaciones gubernamentales en el manejo de la información, la adecuada integración de los datos dentro y fuera de la plataforma y el aseguramiento de la seguridad de la información contenida. Esto significa que las iniciativas podrían orientarse hacia el establecimiento de un sistema con un modelo de datos escalable, la creación de políticas de gobernabilidad de la información y la migración de la información a un sistema que permita la manipulación de los datos. Para implementar estas sugerencias, debe realizarse un análisis de brecha y una definición formal de las iniciativas, formalizando la priorización de las mismas para encontrar el camino más costo/efectivo.

Referencias Bibliográficas 1. International Organization for Standardization. Systems and software engineering Architecture description. Ginebra: ISO, 2011 (ISO/IEC/IEEE 42010). 2. Universidad del Valle. CIMDER - Centro de Investigaciones Multidisciplinarias para el Desarrollo. [En línea]. Disponible en http://www.cimder.org.co/ 3. Ross, J., Weill, P., Robertson, D. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Estados Unidos: Hardvard Business School Press, 2006. 4. G. Booch, J. Rumbaugh, I. Jacobson, El lenguaje unificado de modelado. España: Pearson Educación S.A., 2006, pp. 11-40, 243-270, 487-490. 5. Stack Overflow. How to import a DBF file in SQL Server. [En línea]. Disponible en http://stackoverflow.com/questions/52822/how-to-import-a-dbf-file-in-sql-server 6. Barbacci, M., Klein, M., Longstaff, T., Weinstock, C. Quality Attributes. Technical Report. Sofware Engineering Institute. Estados Unidos: Carnegie Mellon University. 1995. 7. Tanenbaum, A.; Van Steen, M. Distributed Systems: Principles and Paradigms. Estados Unidos: Prentice Hall. 2002. 8. American Health Information Management Association. Data Quality Attributes Grid. [En línea]. Disponible en http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_035071.pdf

Documento técnico, elaborado por la Secretaria de Salud de Boyacá en cooperación con el Hospital del Sur E.S.E Bogotá, con apoyo de ByM Salud Pagina 32