Sistema de información de salud rural en Perú

Mster en Redes de Telecomunicacin
para Pases en Desarrollo
ESCUELA TCNICA SUPERIOR DE

INGENIERA DE TELECOMUNICACIN
PROYECTO FIN DE MSTER
ESTUDIO DE VIABILIDAD PARA LA MEJORA DEL

SISTEMA DE INFORMACIN DE SALUD DE LOS
ESTABLECIMIENTOS RURALES DE PER (CASO
DE ESTUDIO REGIN DE LORETO) UTILIZANDO
LA HERRAMIENTA DHIS2
Autora: Marta Mara Vila Pozo

Tutor: Andrs Martnez Fernndez
Curso acadmico 2011/2012

.
ACTA DEL TRABAJO FIN DE MSTER
DATOS DE ESTUDIO DEL MSTER

ESTUDIOS CURSADOS: MSTER EN REDES DE TELECOMUNICACIN PARA
PASES EN DESARROLLO
CURSO ACADMICO: 2011 / 2012
CONVOCATORIA: Ordinaria Extraordinaria Especial de Finalizacin
DATOS DEL ALUMNO

APELLIDOS: Vila Pozo NOMBRE: Marta Mara
DNI / Pasaporte: 48442156Q E-mail:martavila@gmail.com Telfono: 647775696
TTULO DEL TRABAJO FIN DE MSTER
Estudio de viabilidad para la mejora del sistema de informacin de salud de los establecimientos
rurales de Per (caso de estudio Regin de Loreto) utilizando la herramienta DHIS2.
DIRECTOR/ES (Obligatorio)
DNI NOMBRE Y APELLIDOS UNIVERSIDAD/INSTITUCIN
10.196.457M Andrs Martnez Fernndez Universidad Rey Juan Carlos
MIEMBROS DEL TRIBUNAL ACTA EN CALIDAD DE

Presidente/a
Vocal/es
Secretario/a
Suplente
Suplente
Suplente
Reunido el Tribunal de Evaluacin con fecha .............................., ACUERDA otorgar al alumno

la calificacin global de .................................
Indicar, en su caso, si se propone la concesin de la mencin Matrcula de Honor.
EL PRESIDENTE EL SECRETARIO VOCALES
Fdo: Fdo: Fdo:

.
Gracias...
Gracias Andrs y Javier, por crear y luchar por mantener este entorno en que yo, y tantos
otros, hemos encontrado un espacio donde crecer en el mundo de las TIC para el desarrollo.
Sois un ejemplo a seguir.
Gracias Ins y Jose, por entender que la ausencia de vuestro nombre en este documento es
tan injusta como que apareciese solo uno de vosotros. Y porque sin vosotros, este proyecto,
simplemente no seria.
Gracias compaeros de clase, Richi, Orlando, Ivn, Jaime, Alex, Juan, Rodolfo, Huascar,
Ren, Wilmar, Nacho y Edu, porque ha sido un ao muy bonito gracias a vosotros. Me habis
hecho sentir como si fuese la nica :)
Gracias Richi, por creer en mi como nadie.
Gracias compaeros de aos anteriores, por tantos buenos ratos dentro y fuera del laborato-
rio del stano.
Gracias Nacho Foche, por tu alta tasa de disponibilidad ;) y tantas charlas sinceras.
Gracias a todos los profesores que me habis dado clase, porque me llevo un poquito de
vuestro conocimiento.
Gracias Isa y Blanca, por los nimos infinitos y las revisiones extraoficiales, del proyecto, y
de la vida.
Thanks Sundeep, Knut, John, Johan, Jorn, Bob, Zeferino ,Ranga, and all members of HISP
for your interest in this project and the warm welcome in Oslo.
Gracias Fundacin EHAS, por el apoyo para la realizacin de este proyecto.
Gracias Fundacin La Caixa, por apoyarme en el estudio de este mster.
Gracias Pap, Mam, Sara, Andrs, ngela y Javi, porque sin vosotros ni este proyecto
sera lo que es, ni yo sera lo que soy.
.
Resumen
El objetivo de este proyecto fin de mster es la realizacin de un estudio de viabilidad tcnica
e institucional de la implantacin de un sistema de informacin de salud basado en la herramien-
ta DHIS2. En l se cubre el registro, el envo, el procesado y la visualizacin en tiempo real de
la informacin de salud generada en los establecimientos rurales del Departamento de Loreto en
Per.
Este estudio se basa en la informacin obtenida de la experiencia del Proyecto EHAS-Napo

en Per. Se trata de un proyecto de TIC aplicadas a la Salud en marcha desde el ao 2009 que
interconecta 16 establecimientos pblicos de atencin de salud en la cuenca del ro Napo. Esta
infraestructura de comunicaciones, que en total cubre ms de 500 km, ofrece servicios de banda
ancha y acceso a Internet, comunicacin telefnica y electrificacin bsica en todos los estableci-
mientos. Actualmente se est ampliando su explotacin mediante la puesta en marcha proyectos
de tele-medicina con el fin de proporcionar servicios de tele-estetoscopia, tele-microscopa, y
tele-ecografa.
El actual Sistema de Informacin de Salud de la Regin de Loreto, donde se enmarca el pro-

yecto EHAS Napo, comprende un gran nmero de formularios. El personal de atencin de los
puestos de salud rurales dedica una parte importante de su tiempo a rellenar manualmente la in-
formacin solicitada desde niveles jerrquicos superiores, sabiendo que van a tener que rellenar
los mismos datos en diferentes formularios, y que nunca les va a llegar realimentacin de la in-
formacin enviada. Mediante la implantacin de un Sistema de Informacin apropiado se podra
gestionar de un modo mas eficiente la recogida de informacin cubriendo todo el flujo que esta
debe seguir y permitiendo al usuario, de cualquier nivel de la jerarqua, realizar un anlisis y
distribucin de la informacin en un tiempo razonable. Esto mejorara notablemente la situacin
de los trabajadores de salud y proporcionara informacin de calidad.
En este PFM se analiza la informacin requerida por el Ministerio de Salud en los programas
de Vigilancia Epidemiolgica y Registro Diario de Atenciones y Otras Actividades. Se estudia
el flujo de la misma, desde que se genera en el establecimiento de salud, hasta que es recibida
a nivel nacional. A continuacin se realiza un estudio en profundidad de la herramienta DHIS2
con el fin de conocer sus capacidades funcionales y analticas. Por ltimo, se realiza una adap-
tacin de DHIS2 para la regin de Loreto.
Siguiendo este proceso se ha conseguido realizar una implementacin fiel de los subsistemas
de informacin estudiados, integrndolos en una sola arquitectura, e incluso se ha realizado una
propuesta de integracin de los subsistemas que reduce de forma considerable la informacin a
recoger por el personal de salud en los formularios. Para ello se han eliminado redundancias e
introducido el clculo de datos agregados a partir de datos individuales de paciente. En base a
estos resultados se ha valorado la herramienta de forma positiva dejando una puerta abierta a un
anlisis mas profundo tanto de la realidad del Sistema de Informacin de Salud de Per como
de la propia herramienta.
ndice
I. Introduccin 1
1. Presentacin 1
1.1. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Organizacin del Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Marco de Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. TIC en Zonas Rurales en Pases en Desarrollo . . . . . . . . . . . . . . 4
1.3.2. El Sistema de Salud en Zonas Rurales . . . . . . . . . . . . . . . . . . 5
1.3.3. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Contexto 10
2.1. Sistemas de Informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1. La sociedad de la Informacin . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2. Sistemas de Informacin y Conceptos Relacionados. . . . . . . . . . . 10
2.1.3. Sociedad de la Informacin y Desarrollo . . . . . . . . . . . . . . . . . 13
2.2. El Sistema de Informacin de Salud (SIS) . . . . . . . . . . . . . . . . . . . . 14
2.2.1. Los diferentes enfoques de un SIS . . . . . . . . . . . . . . . . . . . . 14
2.2.2. Estndares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3. Software de Informacin de Salud . . . . . . . . . . . . . . . . . . . . 17
2.3. El Sistema Sanitario de Per . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1. Contexto y realidad socio cultural de Per . . . . . . . . . . . . . . . . 21
2.3.2. El Sistema Sanitario de Per . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.3. El Sistema de Informacin de Salud en Loreto . . . . . . . . . . . . . 31
3. Objetivo 34
II. Metodologa 36
4. Materiales y Mtodos 36
4.1. Obtencin de informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2. Estudio del Sistema de Informacin de Salud . . . . . . . . . . . . . . . . . . 37
4.2.1. Anlisis del flujo de Informacin . . . . . . . . . . . . . . . . . . . . . 37
4.2.2. Estudio en Profundidad de la Herramienta DHIS2 . . . . . . . . . . . . 37
4.2.3. Adaptacin del SIS estudiado al Contexto . . . . . . . . . . . . . . . . 38
III. Resultados 39
5. Identificacin del flujo de Informacin generada en el Sistema de Salud de

Loreto 39
5.1. El Sistema de Informacin de Salud de Per - Enfoque Global . . . . . . . . . 39
5.1.1. Los subsistemas que integran el SIS de Per . . . . . . . . . . . . . . . 39
5.2. Sistema de Informacin Clnica . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.1. El Registro Diario de Atencin y Otras Actividades . . . . . . . . . . 43
5.2.2. Recopilacin de Informacin y Flujo de datos . . . . . . . . . . . . . . 46
5.2.3. El Software del HIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3. Sistema de Vigilancia Epidemiolgica . . . . . . . . . . . . . . . . . . . . . . 49
5.3.1. Etapas de la vigilancia epidemiolgica . . . . . . . . . . . . . . . . . . 49
5.3.2. La informacin y flujos de comunicacin en la etapa de Notificacin . . 50
5.3.3. El software de Vigilancia Epidemiolgica NOTI SP . . . . . . . . . . 56
6. Estudio del Sistema de Informacin de Salud DHIS2 57

6.1. Dimensiones de Datos en DHIS2 . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.1.1. La dimensin dnde (Unidades Organizativas) . . . . . . . . . . . . . 57
6.1.2. La dimensin qu (Elementos de Datos) . . . . . . . . . . . . . . . . . 60
6.1.3. La dimensin cundo (Periodos de tiempo) . . . . . . . . . . . . . . . 62
6.2. Anlisis Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.1. Datasets Y Formularios . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.2. Entrada de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.3. Administracin de datos . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2.4. Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.5. Calidad de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.6. Anlisis de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.7. Cuadro de Mandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.8. Administracin de Usuarios . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.9. Mensajes y Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2.10. Configuracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2.11. Mdulo de Informacin de Seguimiento de Pacientes . . . . . . . . . . 81
6.3. Analisis Tcnico de DHIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.3.1. Caractersticas Tcnicas . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.3.2. Requisitos Tcnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7. Implementacin de DHIS2 para el caso de estudio en la Regin de Loreto 86

7.1. Diseo del Sistema de Informacin . . . . . . . . . . . . . . . . . . . . . . . . 87
7.1.1. La Jerarqua de Unidades Organizativas . . . . . . . . . . . . . . . . . 87
7.1.2. Gestin de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.1.3. Mdulo SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.2. Diseo del Registro Diario de Atenciones . . . . . . . . . . . . . . . . . . . . 95
7.2.1. Elementos de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.2.2. Definicin del Programa . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.2.3. Formulario de Entrada . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.3. Diseo del Sistema de Vigilancia Epidemiolgica - Datos de Paciente . . . . . 102
7.3.2. Definicin del Programa . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.3.3. Formulario de Entrada . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.4. Diseo del Sistema de Vigilancia Epidemiolgica - Datos Agregados . . . . . . 106
7.4.2. Conjunto de Datos, Formulario de Entrada y Reglas de Validacin . . . 108
7.5. Clculo de Datos Agregados desde Datos de Paciente . . . . . . . . . . . . . . 113
7.6. Creacin de Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.6.1. Tipos de Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.6.2. Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.7. Grficos, Mapas y Cuadro de Mandos . . . . . . . . . . . . . . . . . . . . . . 117
7.7.1. Creacin de Grficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.7.2. Creacin de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.7.3. El Cuadro de Mandos . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.8. Verificacin de Requisitos del Sistema . . . . . . . . . . . . . . . . . . . . . . 123
7.8.1. Requisitos No Funcionales . . . . . . . . . . . . . . . . . . . . . . . . 123
7.8.2. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.9. Propuesta de Integracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
IV. Conclusiones y trabajo futuro 134
8. Conclusiones 134
9. Trabajo Futuro 136

ndice de figuras
1. El ciclo Datos - Informacin - Conocimiento . . . . . . . . . . . . . . . . . . . 12
2. Mapa poltico del Per . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3. Mapa del Departamento de Loreto . . . . . . . . . . . . . . . . . . . . . . . . 24
4. ndice de Pobreza de Loreto por Provincias . . . . . . . . . . . . . . . . . . . 25
5. Categoras de los Establecimientos de Salud de Per . . . . . . . . . . . . . . 26
6. Estructura del Sistema Regional de Salud . . . . . . . . . . . . . . . . . . . . 28
7. Establecimientos de Salud en la cuenca del Ro Napo . . . . . . . . . . . . . . 29
8. Esquema Tcnico de la Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Datos Generales del Registro Diario . . . . . . . . . . . . . . . . . . . . . . . 44
10. Datos Especficos del Registro Diario . . . . . . . . . . . . . . . . . . . . . . 45
11. Formulario del Registro Diario de Atencin y Otras Actividades . . . . . . . . 47
12. Flujo de Informacin del Registro Diario de Atencin . . . . . . . . . . . . . . 48
13. Flujo de la Informacin del Sistema de Vigilancia Epidemiolgica . . . . . . . 51
14. Organizacin de los documentos del Sistema de Vigilancia Epidemiolgica . . 51
15. Ficha de Notificacin Individual . . . . . . . . . . . . . . . . . . . . . . . . . 52
16. Ficha de Notificacin Consolidada . . . . . . . . . . . . . . . . . . . . . . . . 55
17. Ejemplo de rbol de jerarqua . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
18. Jerarqua de Grupos y Conjuntos de Grupos . . . . . . . . . . . . . . . . . . . 60
19. ejemplo de formulario de entrada de datos . . . . . . . . . . . . . . . . . . . . 64
20. Interfaz para la Creacin de Unidades Organizativas . . . . . . . . . . . . . . . 89
21. Jerarqua Geogrfica de los Establecimientos de Salud de Loreto . . . . . . . . 89
22. Definicin de los Niveles de Unidad Organizativa. . . . . . . . . . . . . . . . . 90
23. Jerarqua de Redes y Microredes . . . . . . . . . . . . . . . . . . . . . . . . . 91
24. Navegabilidad del mdulo SIG . . . . . . . . . . . . . . . . . . . . . . . . . . 94
25. Pantalla de Creacin de Programas . . . . . . . . . . . . . . . . . . . . . . . . 97
26. Pantalla de Administracin de Programas . . . . . . . . . . . . . . . . . . . . 98
27. Pantalla de Creacin de Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . 99
28. Pantalla de Administracin de Etapas . . . . . . . . . . . . . . . . . . . . . . 99
29. Pantalla de Edicin del Formulario de Entrada de Datos . . . . . . . . . . . . . 100
30. Resultado Final del Formulario de Entrada de Datos . . . . . . . . . . . . . . . 101
31. Tipo de Informacin del Sistema de Vigilancia Epidemiolgica . . . . . . . . . 101
32. Pantalla de Creacin de Programas - Evento Simple . . . . . . . . . . . . . . . 104
33. Pantalla de Asignacin de Unidades Organizativas a Programas . . . . . . . . . 105
34. Ejemplo de formulario por defecto para la entrada de datos . . . . . . . . . . . 106
35. Creacin de un Conjunto de Datos . . . . . . . . . . . . . . . . . . . . . . . . 108
36. Diseo de Formulario - Paso 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 109
39. Creacin de una Regla de Validacin . . . . . . . . . . . . . . . . . . . . . . . 111
40. Edicin del lado Izquierdo de una Expresin de Validacin . . . . . . . . . . . 112
41. Reglas de Validacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
42. Ventana de Resultados del Proceso de Validacin . . . . . . . . . . . . . . . . 113
43. Detalle de la informacin de paciente . . . . . . . . . . . . . . . . . . . . . . 114
44. Crear Tipo de Indicador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
45. Distintos Tipos de Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . 115
46. Crear Indicador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
47. Pantalla de Creacin de Grficas . . . . . . . . . . . . . . . . . . . . . . . . . 119
48. Pantalla de Creacin de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . 121
49. Incidencia de Malaria en Per - Loreto - Maynas . . . . . . . . . . . . . . . . 121
50. Cuadro de Mandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
51. Ejemplo de Informe del Modulo de Reportes asociado al Modulo de Pacientes . 126
52. Cuadro Resumen de los campos de los Formularios . . . . . . . . . . . . . . . 131
53. Conjunto mnimo de informacin . . . . . . . . . . . . . . . . . . . . . . . . . 132
54. Formulario de Entrada con la informacin mnima . . . . . . . . . . . . . . . . 133
ndice de cuadros
2. Poblacin de Loreto por Provincias . . . . . . . . . . . . . . . . . . . . . . . . 23
3. Enfermedades Sujetas a Vigilancia Epidemiolgica . . . . . . . . . . . . . . . 52
4. Enfermedades y Eventos Sujetos a Notificacin Consolidada . . . . . . . . . . 54
5. Dimensiones DHIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6. Ejemplo Categoria DHIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7. Ejemplo Combinacin de Categoras DHIS . . . . . . . . . . . . . . . . . . . 62
8. Funciones de Usuario DHIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9. Roles y Permisos de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
10. Representacin de la Informacin en la base de datos . . . . . . . . . . . . . . 95
13. Definicin de Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
14. Creacin de Grficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
*
CIE Codificacin Internacional de Enfermedades
CS Centro de Salud
DGE Direccin General de Epidemiologa
DHIS District Health Information System
DICOM Digital Imaging and Communication in Medicine
DIREMID Direccin Regional de Medicamentos e Insumos
DIRESA Direccin Regional de Salud
ECG Electrocardiograma
ED Elemento de Datos
EDA Enfermedad Diarreica Aguda
EHAS Enlace Hispano Americano de Salud
FESE Ficha para Evaluacin Socio Econmica
FOSS Free and Open Source Software
GML Geography Markup Language (Lenguaje de Marcado Geogrfico)
GTR Grupo de Telecomunicaciones Rurales
HCE Historia Clnica Electrnica
HIS Health Information System
HISP Health Information System Programe
HL7 Health Level Seven
IHTSDO International Health Terminology Standards Development Organisation
INEI Insituto Nacional de Estadstica e Informtica
IRA Infeccin Respiratoria Aguda
MINSA Ministerio de Salud
NORAD Norwegian Agency for Development (Agencia Noruega para el Desarrollo)
ODM Objetivos de Desarrollo del Milenio
OEI Oficina General de Estadstica e Informtica
OMS Organizacin Mundial de la Salud

OPS Organizacin Panamerica de la Salud
PNUD Programa de Naciones Unidas para el Desarrollo
PS Puesto de Salud
SESE Sistema para Evaluacin Socio Econmica
SI Sistema de Informacin
SIG Sistema de Informacin Geogrfica
SIS Sistema de Informacin de Salud
SISMED Sistema Integrado de Suministro de Medicamentos e Insumos mdico Quirrgico
SNOMED-CT Systematized Nomenclature of Medicine - Clinical Terms
TIC Tecnologas de la Informacin y la Comunicacin

Parte I.
Introduccin
1. Presentacin
1.1. Motivacin
En Septiembre de 2000, basada en un decenio de grandes conferencias y cumbres de las
Naciones Unidas, se celebr en Nueva York la Cumbre del Milenio. En ella los dirigentes del
mundo se reunieron para aprobar la Declaracin del Milenio [dec12], comprometindose con
una nueva alianza mundial en la que se establecieron una serie de objetivos conocidos desde ese
momento como los Objetivos de Desarrollo del Mileno (ODM), cuyo plazo de consecucin se
fij en el ao 2015.
En conjunto, los ODM, contemplan las necesidades humanas y derechos bsicos de todos los
individuos del planeta. Se enfocan en la erradicacin de la pobreza extrema y el hambre, el acce-
so universal a la educacin, la igualdad entre gneros, la reduccin de la mortalidad infantil, la
mejora de la salud materna, la lucha contra el VIH/SIDA, Malaria y otras enfermedades, la sos-
tenibilidad del medio ambiente y la potenciacin de una asociacin mundial para el desarrollo.
Se trata de ocho objetivos generales, veintiuna metas especficas y sesenta indicadores oficiales
1 mediante los cuales se monitorizan los avances hacia la consecucin de los objetivos.
Desde su establecimiento en el ao 2000, existe a nivel mundial una alineacin con los ODM
de todos los proyectos e investigaciones enmarcados en el campo de la cooperacin internacio-
nal al desarrollo. A cuatro aos de la fecha lmite para su cumplimiento, no parece que se vayan
a alcanzar, pero se puede decir que se han logrado muchos avances. Lo ms importante es que
se ha demostrado que los Objetivos son alcanzables cuando las estrategias, polticas y progra-
mas de desarrollo son de inters nacional y tienen el apoyo internacional de agencias para el
desarrollo. Al mismo tiempo resulta claro que las mejoras en las vidas de los ms pobres han
sido inaceptablemente lentas, y que algunas de las ganancias que tanto ha costado obtener, estn
siendo erosionadas por las crisis medioambiental, econmica y alimentaria. [odm 9]
Las Tecnologas de la Informacin y la comunicacin (TIC) tienen potencial para contribuir a

la consecucin de los ODM, como parte de ellos, en el octavo objetivo (Meta 8.F: En coopera-
cin con el sector privado, dar acceso a los beneficios de las nuevas tecnologas especialmente las
de la informacin y las comunicaciones. ), as como impactando en la consecucin de los otros
siete. Para ello, las TIC pueden ser empleadas para afrontar los ODM de un modo ms efectivo
mediante la mejora de los sistemas de monitorizacin y vigilancia del progreso obtenido en los
mismos, mejorando el crecimiento econmico, reduciendo la pobreza y proporcionando servi-
cios sociales bsicos ms eficientes y efectivos. [PNUD 2008]
1
La lista completa de objetivos, metas e indicadores se encuentra en http://mdgs.un.org
1
Es evidente que el sector salud juega un papel primordial en el desarrollo de un pas. El estado
de salud de una poblacin afecta directamente a su productividad, el potencial de sus nios, la
mortalidad infantil y materna, y la longevidad. De hecho tres de los ocho ODM se refieren a la
salud: reducir la mortalidad infantil, mejorar la salud materna, y combatir el VIH/SIDA, malaria
y otras enfermedades.
En un estudio comparativo de cuatro estrategias de integracin de Sistemas de Informacin

de Salud (SIS) (Saebo et al [Sae02]), la existencia de SIS ineficientes ha sido identificada como
uno de los mayores obstculos a los que se enfrenta el sector salud para abordar los ODM. No
es de extraar pues, que en la estrategia y plan de accin de la Organizacin Panamericana de
la Salud (OPS) se resuelva apoyar la consideracin de la eSalud en las polticas, planes y pro-
gramas de desarrollo, as como en las propuestas y la discusin de los presupuestos nacionales,
permitiendo crear las condiciones propicias para dar respuesta al reto de mejorar la salud pblica
en la Regin a travs del uso de herramientas y metodologas innovadoras de las tecnologas de
la informacin y las comunicaciones, en sus respectivos pases. [dlSOMdlS11]
La Fundacin Enlace Hispano Americano de Salud (EHAS) ha desarrollado diversas solu-

ciones TIC para proporcionar conectividad y servicios de comunicaciones en diversos pases de
Amrica Latina, con un enfoque principal en el rea de la telemedicina rural. En el ao 2007,
la Fundacin EHAS despleg una red inalmbrica de banda ancha para el Sistema de Atencin
Primaria en Salud en la regin de Loreto, en el distrito rural amaznico del Napo, en Per. La
conectividad proporciona servicios, como telefona IP, videoconferencia, chat y acceso a Inter-
net, entre otros. La red interconecta 16 establecimientos de salud rurales a lo largo del ro Napo,
cubriendo una distancia de ms de 500 Km, con el Hospital Regional de Iquitos.
El acceso a las TIC en la red del Napo y los servicios que se ofrecen, cuentan con un alto
grado de valoracin y motivacin por parte del personal de salud rural. No obstante, hasta la ac-
tualidad, no hay implantada ninguna herramienta capaz de gestionar la informacin derivada de
los protocolos y procesos mdicos, los cuales constituyen una de las claves del funcionamiento
y eficiencia del sistema sanitario del Napo.
El Health Information Systems Programe (HISP) es una red colaborativa norte-sur, que tra-
baja para la mejora de los servicios de salud en pases en desarrollo por medio de la investigacin
e implementacin de Sistemas de Informacin de Salud. La red ha trabajado en diversos pases
de frica y el sudeste asitico desde 1994. El ncleo del programa HISP es el desarrollo (de
cdigo abierto) del software District Health Information System (DHIS) y el uso de la aplica-
cin para fortalecer los SIS a nivel nacional.
Es objetivo de este Proyecto Fin de Mster unificar los esfuerzos de ambas organizaciones.
Gracias a la experiencia de EHAS en Per, en concreto en los establecimientos ubicados en la
cuenca del Ro Napo, en la regin de Loreto, se espera poder identificar los flujos de informacin
generados en los centros y puestos de salud rurales. Posteriormente, con el apoyo de la Funda-
cin EHAS y del programa HISP, se pretende estudiar en profundidad la herramienta DHIS2,
mediante el anlisis de su capacidad para gestionar y controlar la informacin generada, as co-
2
mo la viabilidad de su implantacin en un entorno como el presentado en el caso de estudio, con
el fin de estudiar la idoneidad de su implantacin.
1.2. Organizacin del Documento

El documento se estructura de la siguiente forma:
Captulo 1: Presentacin, en la cual se introduce el Proyecto Fin de Mster y su motiva-
cin en el marco del trabajo por el desarrollo humano. Se presenta tambin el papel de las
TIC en el sector salud y la estructura bsica del sistema de salud en zonas rurales de pases
en vas de desarrollo. Por ltimo se realiza una presentacin de la Fundacin EHAS y el
grupo HISP, organizaciones que han hecho posible la realizacin de este PFM.
Captulo 2: Contexto, en el que se definen los sistemas de informacin y conceptos teri-
cos relacionados con ellos. Se enmarca su nacimiento en la sociedad de la informacin, de
la que tambin se hace una introduccin y un anlisis de su posible papel en el desarrollo
humano. Se define tambin qu son los Sistemas de Informacin de Salud y sus diferentes
enfoques y se hace un pequeo recorrido por las aplicaciones y estndares existentes en la
actualidad. Por ltimo, se detalla cul es el contexto sociocultural del Per y la Regin de
Loreto, para posteriormente centrarse en la problemtica de la gestin de la informacin
de salud en los establecimientos de salud rurales de la cuenca del ro Napo.
Captulo 3: Objetivo, que define el objetivo principal de este PFM en el marco del estudio
de un Sistema de Informacin de Salud, para su uso en proyectos TIC en zonas rurales de
pases en desarrollo.
Captulo 4: Materiales y Mtodos, donde se hace una descripcin de las fuentes de
informacin del trabajo, las herramientas de las que se ha hecho uso y la participacin de
entidades en la elaboracin de este PFM. Se describe por ltimo, el proceso a seguir para
alcanzar el objetivo planteado.
Captulo 5: Identificacin del Flujo de informacin generada en el Sistema de Salud
de Loreto, se trata del primer resultado de este PFM. En l se realiza una foto general
del Sistema de Informacin de Salud completo que hay hoy en da en Per a nivel na-
cional, para posteriormente analizar ms en detalle dos subsistemas de informacin, que
son el Registro Diario de Atenciones y Otras Actividades y el Sistema de Vigilancia
Epidemiolgica.
Captulo 6: Estudio del Sistema de Informacin de Salud DHIS2, donde se intenta
transmitir una imagen completa de la herramienta y ayudar a entenderla a nivel concep-
tual, funcional y de requisitos tcnicos. En primer lugar se describen las dimensiones
utilizadas para identificar los datos en el sistema, ya que estas constituyen y ayudan a
entender la filosofa de diseo de DHIS2. En segundo lugar se hace un recorrido por las
funcionalidades ms destacadas y se intenta contestar a la pregunta Qu se puede hacer
con DHIS2?. Por ltimo se intenta hacer una descripcin de alto nivel de sus caracters-
ticas tcnicas y los requisitos necesarios para poner en marcha la herramienta.
3
Captulo 7: Implementacin de DHIS2 para el caso de estudio en la Regin de Lo-
reto, donde se detalla en primer lugar el diseo del Sistema de Informacin de forma
genrica, la configuracin de los mdulos que compartirn todos los sistemas o subsiste-
mas de informacin y que son los que definen la estructura del sistema. A continuacin se
explica cmo se han diseado los subsistemas de informacin analizados en el Captulo
5, cmo se les ha dado forma dentro del sistema DHIS2. Una vez diseado el sistema, se
hace un repaso a los requisitos del sistema de informacin acompaado de un anlisis del
comportamiento de DHIS2 respecto a ellos, y por ltimo se expone un pequeo ejemplo
de cmo se podra sacar partido a algunas de las funcionalidades encontradas durante el
anlisis de la herramienta.
Captulo 8: Conclusiones, en las que se discuten y resumen los resultados obtenidos y se

contrastan con el objetivo inicial.
Captulo 9: Trabajo Futuro, donde se apunta qu estudios se debern llevar a cabo si

se desea profundizar ms en el conocimiento de DHIS2 y establecer una colaboracin y
puesta en marcha de un proyecto en el marco de la implementacin real de la herramienta.
1.3. Marco de Referencia

1.3.1. TIC en Zonas Rurales en Pases en Desarrollo
Las zonas rurales en pases en desarrollo son probablemente las que, dentro de un contexto
global de recursos escasos, sufren con mayor intensidad la desigualdad econmica y el acceso
limitado a bienes o servicios de primera necesidad. Una orografa complicada y en muchos casos
una falta de infraestructura terrestre de calidad juegan un papel muy importante en el aislamien-
to de estos ncleos de poblacin. Este aislamiento geogrfico define un contexto muy parecido
en sus distintas realidades, se trata de zonas en las que es difcil encontrar personal cualificado
para trabajar con nuevas tecnologas, la infraestructura no es deficiente slo en cuanto a trans-
porte, sino que, en muchos casos la infraestructura de electrificacin tambin es de mala calidad,
y la de comunicaciones es prcticamente inexistente. La baja densidad de poblacin y su bajo
poder adquisitivo hacen que la instalacin y mantenimiento de este tipo de infraestructuras sea
inviable econmicamente para el gobierno, y de bajo inters para las grandes empresas de co-
municaciones. Adems las soluciones o servicios disponibles en el mercado no suelen adaptarse
a las necesidades especficas de un contexto como el descrito aqu.
Una situacin como sta deriva inevitablemente en un acceso muy limitado a las nuevas tec-
nologas. Las TIC, bien utilizadas, son una herramienta muy potente de apoyo al desarrollo
humano de una poblacin, pueden mejorar mbitos como el de la educacin, salud y desarrollo
productivo en general, pero las zonas rurales de pases en desarrollo estn lejos de beneficiarse
de este potencial. Es por ello que las agencias internacionales de ayuda al desarrollo han puesto
parte de sus esfuerzos en dotar de acceso a redes de telecomunicaciones a estas poblaciones,
principalmente de conexin telefnica y acceso a Internet, ya que generalmente no es prioridad
entre los objetivos de centros de investigacin y mucho menos de empresas de comunicaciones,
4
ms centradas en zonas urbanas densamente pobladas.
En el mbito de los servicios de salud, las TIC tienen un gran potencial de impacto, nos re-
ferimos a partir de ahora a la prctica de atencin sanitaria apoyada en las TIC como e-salud.
La e-salud puede generar importantes mejoras en la eficiencia del servicio sanitario, ya que hay
muchos mbitos en los que puede intervenir: los sistemas de informacin sanitaria, que alma-
cenan y gestionan los datos mdicos; el acceso remoto a bases de datos de archivos mdicos;
el diagnstico compartido o apoyo al diagnstico; la tele-enseanza, que permite la formacin
continua; tele-monitorizacin, para el seguimiento remoto de un paciente; tele-presencia, como
sera la tele-ciruga u operaciones realizadas a distancia; y tele-diagnstico, que permite a un
mdico diagnosticar remotamente a un paciente, por ejemplo, con videoconferencia.
El campo de la informtica para la salud en pases en desarrollo ha crecido mucho en la ltima

dcada, habindose convertido en un apoyo a la atencin sanitaria en frica, Amrica Latina, y
Asia. Los factores claves de este crecimiento pasan por la disponibilidad de hardware ms robus-
to, barato, y con menos requerimiento de energa, un lento pero paulatino aumento del acceso a
Internet, y la aparicin de proyectos de software de alto nivel que ha sido implantado en un alto
nmero de pases. [Fra]
Por otro lado, el dotar a estas poblaciones de tecnologa no es suficiente si no se hace bien
y con mucho conocimiento de los procesos de implantacin y del impacto de la misma. Ya en
1995, Sosa-Iudicissa, apuntaba que solo una muy cuidada metodologa de desarrollo y adapta-
cin de herramientas y un esmerado trabajo de implantacin de tecnologa y servicios apropiados
a sus necesidades concretas, puede conseguir solucionar los problemas de aislamiento e incomu-
nicacin en que se encuentra la mayora del personal de atencin primaria de salud en las zonas
rurales de los pases en desarrollo. [SIB 7]
1.3.2. El Sistema de Salud en Zonas Rurales

En las zonas rurales de pases en vas de desarrollo la jerarqua de establecimientos sanitarios
de atencin primaria se divide generalmente, aunque no tiene porqu coincidir la nomenclatura,
en Puestos de Salud y Centros de Salud. [Mar 4]
Puestos de Salud (PS)

Son el escalafn ms bajo en el sistema de atencin primaria. Estn localizados en las po-
blaciones ms aisladas, generalmente en poblaciones con pocos habitantes, sin lnea telefnica
y con sistemas de transporte muy deficientes (sin carreteras, o con pocas y de mala calidad).
Dependen jerrquicamente de los Centros de Salud (CS) de referencia, constituyendo una red
en la que varios PS dependen de un mismo CS. En la mayor parte de los casos son dirigidos
por un tcnico de enfermera con escasa formacin, que requiere, debido a que se enfrentan a
los casos ms graves, de continua realimentacin por parte de los mdicos de referencia que se
encuentran en los CS. El nmero de tcnicos de enfermera que atienden un PS es muy reducido
(en ocasiones una o dos personas), para hacer frente a gran parte de las necesidades sanitarias
5
de primer nivel.
Debido a que los PS se enclavan en las regiones ms aisladas de la geografa de los pases en
desarrollo, el aislamiento al que son sometidos estos profesionales es muy elevado, y en muchas
ocasiones, este personal no procede de la poblacin en la que ejerce. Este aislamiento no es el
entorno apropiado para el desempeo de su profesin, por lo que frecuentemente la rotacin de
este tipo de personal es muy elevada (en ocasiones con rotaciones anuales), provocando en cada
rotacin de personal la prdida de la experiencia adquirida y, por tanto, deteriorando la calidad
de la atencin, la relacin con el paciente y derrochando los recursos formativos de la regin.
Centros de Salud (CS)

Se sitan jerrquicamente sobre los PS. Generalmente se ubican en capitales de distrito, donde
existe mayor disponibilidad de sistemas de telecomunicacin como la telefona. Son dirigidos
por mdicos y presentan cierta infraestructura y equipamiento para la realizacin de algunas
pruebas diagnsticas. En algunos casos permiten la hospitalizacin. Normalmente, en zonas ais-
ladas, es en los CS donde se gestionan los informes que se envan desde los PS, tambin se
organizan campaas de salud regulares para alcanzar aquella poblacin que, por su ubicacin y
falta de movilidad, no puede desplazarse para ser atendida en un PS o CS. Con frecuencia en los
CS se dispone de algn tipo de equipo de cmputo para digitalizar los informes que se envan
desde los PS y suelen contar con algn personal responsable de esta tarea.
En el caso de Per, estos dos tipos de establecimiento se enmarcan en el primer nivel de aten-
cin definido por el Ministerio de Salud (MINSA), siendo un Nivel de Atencin el conjunto
de establecimientos de salud con niveles de complejidad necesaria para resolver con eficacia y
eficiencia necesidades de salud de diferente magnitud y severidad. [dSdP09]
El primer nivel de atencin es aquel en que se atiende el 70-80 % de la demanda del sistema.
La severidad de los problemas de salud es de baja complejidad. Hay una gran oferta con menor
especializacin y tecnificacin de sus recursos. En este nivel se desarrollan principalmente ac-
tividades de prevencin y proteccin especfica, diagnstico precoz y tratamiento oportuno de
las necesidades de salud ms frecuentes. Es raro encontrar en zonas rurales atencin ms espe-
cializada que la cubierta por este tipo de establecimientos. Para situaciones ms complejas es
habitual remitir a los pacientes a los hospitales.
1.3.3. Actores
La Fundacin EHAS
Los orgenes de la Fundacin EHAS se remontan al ao 1997 cuando el Grupo de Bio-

ingeniera y Telemedicina (GBT) de la Universidad Politcnica de Madrid y la ONGD
6
Ingeniera Sin Fronteras ApD1 , comenzaron a investigar en el diseo de sistemas y ser-
vicios de comunicacin apropiados a las necesidades del personal sanitario rural de los
pases de Amrica Latina. A raz de estos trabajos se dise y ejecut el programa En-
lace Hispano Americano de Salud (EHAS), con el objetivo de contribuir a la mejora del
sistema pblico de asistencia sanitaria en las zonas rurales de los pases de Amrica Latina.
La trayectoria del Subprograma EHAS en Per arranca en el ao 1999, de la mano de la

Seccin de Electrnica de la Pontificia Universidad Catlica del Per, que ms tarde se
consolid como el Grupo de Telecomunicaciones Rurales (GTR), siendo esta la contra-
parte tecnolgica de EHAS. Entre los aos 2000 y 2002 se puso en marcha un proyecto
piloto en la provincia de Alto Amazonas del departamento de Loreto en Per, con obje-
to de implementar una solucin de comunicaciones de bajo costo y evaluar su impacto.
Dicho proyecto involucra al Hospital Provincial de la capital, Yurimaguas, y a 40 estable-
cimientos de salud de dos categoras: centros de salud y puestos de salud. La seleccin
de la provincia de Alto Amazonas se llev a cabo debido a que es una provincia de sel-
va baja idnea para probar las herramientas de comunicacin en VHF (primer producto
del Programa EHAS); es muy extensa y sin carreteras (el 95 % de los establecimientos
de salud son slo accesibles por ro); y tiene importantes carencias en infraestructura de
telecomunicaciones (slo dos establecimientos de salud contaban con lnea telefnica).
El programa sigue creciendo y en octubre de 2004 se constituye como fundacin sin nimo
de lucro la Fundacin EHAS, teniendo como patronos dos instituciones, la Universidad
Politcnica de Madrid y la ONGD Ingeniera Sin Fronteras ApD. En 2008 se ampli el
patronato con la Universidad del Cauca de Colombia, la Pontificia Universidad Catlica
del Per y la Universidad Rey Juan Carlos de Madrid.
La Fundacin EHAS mantiene el espritu del programa, persiguiendo el mismo objetivo

de contribuir a la mejora del sistema pblico de asistencia sanitaria en las zonas rurales de
los pases de Amrica Latina. En esta lnea persigue dos fines principales:
1. La cooperacin internacional para el desarrollo en el sector de las tecnologas de la
informacin y la comunicacin aplicadas a la salud de los pases hispanoamericanos
u otros que se encuentren en vas de desarrollo.
2. La investigacin, la formacin y el desarrollo de la sociedad de la informacin para
mejorar el sector salud de los pases hispanoamericanos u otros que se encuentren
en vas de desarrollo.
Para perseguir sus objetivos, EHAS basa sus acciones en una estrategia que presenta cuatro
lneas principales de trabajo:
1. La investigacin y el desarrollo de nuevas tecnologas de comunicacin y sistemas
de acceso e intercambio de informacin adaptadas a las zonas rurales de pases en
desarrollo.
1
Actualmente ONGAWA, Ingeniera para el Desarrollo Humano
7
2. El asesoramiento, desarrollo y evaluacin de protocolos de actuacin para la mejora
de los procesos de atencin de salud en las zonas rurales, con especial atencin en
los relacionados con la salud materno-infantil.
3. El diseo y la ejecucin de proyectos de cooperacin para el desarrollo que permitan
validar tanto la tecnologa como los protocolos de actuacin anteriores.
4. El desarrollo de actividades de formacin, difusin, transferencia e incidencia pol-
tica para promover el uso adecuado de las TIC en el sector salud rural de pases en
desarrollo.
En la actualidad, la Fundacin EHAS contina trabajando en la mejora de los siste-

mas de comunicacin, y en las posibilidades de implantar sistemas inalmbricos de tele-
diagnstico y otros servicios de tele-medicina. Los trabajos de investigacin y desarrollo
de nuevas aplicaciones se realizan en colaboracin con diversos socios expertos como la
Fundacin FUNDATEL, el Instituto Nacional Materno Perinatal del Per, el Departamen-
to de Teora de la Seal de la ETSI de Telecomunicacin de la Universidad Rey Juan
Carlos, el grupo de investigacin clnica de Neumologa del Hospital San Pedro de Alcn-
tara de Cceres, o el Hospital Universitario de Fuenlabrada, entre otros.
El Programa HISP
El Health Information Systems Programe (HISP) es una red colaborativa norte-sur que
trabaja para la mejora de los servicios de salud en pases en desarrollo. Nace en el Depar-
tamento de Informtica de la Universidad de Oslo en 1994, en colaboracin con la Uni-
versidad de Ciudad del Cabo, Sudfrica. Desde entonces ha trabajado en diversos pases
de frica como Sierra Leona, Sudfrica, Malawi, o Tanzania, entre otros, y en el sudeste
asitico en pases como India, Sri Lanka o Vietnam. El ncleo del trabajo llevado a cabo
por HISP es el desarrollo del software de cdigo abierto District Health Information Sys-
tem (DHIS) y el uso del mismo para fortalecer los SIS a nivel nacional.
El objetivo principal de HISP es el de desarrollar un Sistema de Informacin de Salud

basado en el distrito, entendido este como el ltimo escaln de la jerarqua de un sistema
de salud nacional, es decir, basado en la informacin obtenida en los niveles ms bsi-
cos de la atencin sanitaria. Esto incluye el desarrollo del software, metodologas para la
implantacin de sistemas de informacin de salud y programas de formacin. La visin
de HISP es la de apoyar el desarrollo de un sistema de informacin de salud excelente y
sostenible, que permita a todos los trabajadores sanitarios, independientemente de su nivel
en la estructura sanitaria, el uso de su propia informacin para mejorar la cobertura y la
atencin sanitaria.
HISP nace en Sudfrica, despus de la llegada de la democracia en 1994, como un pro-

grama de investigacin y desarrollo. En gran parte inspirada por la tradicin Escandinava
basada en investigacin-accin y la aplicacin de metodologas participativas para los sis-
temas de informacin. El objetivo general en Sudfrica era explorar y desarrollar enfoques
8
africanos para un diseo bottom-up participativo y posterior desarrollo de un sistema de
informacin sanitaria. Uno de los objetivos clave de la investigacin era encontrar la ma-
nera de potenciar y dar voz a la comunidad de usuarios finales, a las estructuras de gestin
local y a las comunidades desfavorecidas, en el proceso de desarrollo de un nuevo sistema
de informacin de salud enmarcado en las estructuras de salud descentralizadas propues-
tas en Sudfrica. Con los aos, DHIS se ha convertido en parte del Sistema de Informacin
de Salud Nacional de Sudfrica, y se ha expandido a otros pases en desarrollo como Mo-
zambique, India, Etiopa, Tanzania y Malawi entre otros.
El proceso desde su nacimiento hasta su consolidacin como solucin a nivel nacional

no fue fcil. HISP como proyecto piloto funcion con xito hasta que la NORAD 2 de-
j de financiar el proyecto en 1998. En aquel momento pareca que el proyecto HISP
desaparecera, como tantos otros proyectos piloto, pero una serie de acontecimientos lo
mantuvieron en marcha. En primer lugar, todos los competidores de DHIS fueron consi-
derados pequeos fiascos, y fue el nico proyecto piloto de atencin primaria de salud que
se mantuvo. En segundo lugar, trabajar con el usuario final, desde el nivel ms bajo tuvo
su recompensa, los trabajadores de salud comenzaron a tomar accin y explicaron a los
niveles superiores cmo HISP les haba apoyado en el anlisis y uso de los datos. En tercer
lugar, una investigacin nacional de SIS en Sudfrica, recomend el uso de DHIS para la
generacin del primer Conjunto Mnimo de Datos nacional. De este modo, con el fra-
caso del resto de alternativas, la gente sigui utilizando DHIS en las provincias Oriental y
Occidental del Cabo, lo que llevo a una implantacin de DHIS ms amplia. En Febrero de
1999 prcticamente todas las provincias, con la excepcin de 3 de ellas, queran seguir el
camino de implantacin de DHIS. Finalmente, en 1999, DHIS fue aceptado como estn-
dar nacional para el Sistema de Informacin de Salud de Sudfrica.
Desde entonces HISP ha continuado trabajando en la misma lnea que emple en su naci-
miento. La herramienta ha evolucionando adaptndose a la evolucin de las nuevas tecno-
logas hasta llegar a ser DHIS2, herramienta que se implanta hoy en da en los pases en
que HISP tiene presencia y que se estudiar con detenimiento en el apartado correspon-
diente de este proyecto.
2
Agencia Noruega para el Desarrollo
9
2. Contexto
2.1. Sistemas de Informacin
2.1.1. La sociedad de la Informacin
La sociedad de la informacin, trmino acuado en los aos 70, y profundizado en los 90,
hace referencia a la sociedad resultante de la ltima revolucin tecnolgica. La sociedad en que,
por el avance de la ciencia y la tecnologa, los ordenadores y las telecomunicaciones se vuelven
cotidianos y asequibles. Una sociedad que casi de la noche a la maana dispone de cantidades
enormes de informacin y de la capacidad para el intercambio y transmisin de la misma. La
informacin y el conocimiento tienen un lugar privilegiado en la sociedad y en la cultura y la
creacin, distribucin y manipulacin de la misma se convierten en parte estructural de las acti-
vidades culturales y econmicas.
Aunque los trminos sociedad de la informacin y sociedad del conocimiento son a menu-
do utilizados como sinnimos, personalmente me gusta ms la corriente que define la sociedad
de la informacin como un paso previo a la sociedad del conocimiento, haciendo referencia la
primera a la capacidad tecnolgica para almacenar cada vez ms datos, procesarlos, obtener in-
formacin y distribuirla, dejando el ltimo paso a la sociedad del conocimiento. Una sociedad
en que se da la apropiacin crtica y selectiva de la informacin por parte del ciudadano, una
sociedad formada e informada, capaz de acceder a la informacin y de aprovecharla por el bien
comn, bien sea en el mbito empresarial, educativo, de salud o personal.
2.1.2. Sistemas de Informacin y Conceptos Relacionados.

Este apartado no tiene otro objetivo que el de establecer una base terica sobre determinados
conceptos que se repiten a lo largo del documento.
Qu entendemos por Sistema de Informacin?

Los Sistemas de Informacin nacen en el seno de las organizaciones que tras la era indus-
trial buscan el crecimiento a travs del manejo apropiado de la informacin y el conoci-
miento, dentro del marco de la Sociedad de la Informacin.
Los Sistemas de Informacin han evolucionado mucho desde su nacimiento en los aos
60, han ido abarcando ms funciones y lo han hecho con mayor capacidad y velocidad.
Inicialmente se trataba de un sistema de tratamiento de datos, capaz de almacenar y tratar
grandes volmenes de registros de forma automatizada, para posteriormente introducir la
explotacin de datos en forma de informacin y generacin de informes. En una mejora de
la eficiencia interna aparece la automatizacin de procesos, que cambia la entrada manual
de la informacin en el sistema por la automatizacin de procesos que generan informa-
cin de salida, aparece la interaccin en tiempo real. Tambin como parte del crecimiento
del Sistema de Informacin interno aparece la comparticin de informacin entre depar-
10
tamentos.
A partir de este momento los Sistemas de Informacin crecen mirando hacia fuera de la
organizacin, buscando la interaccin con otros sistemas.Se busca el intercambio autom-
tico de informacin entre el sistema de informacin interno y el mundo exterior.
Como resultado de esta evolucin podemos definir, desde un punto de vista empresarial,
el Sistema de Informacin como un conjunto formal de procesos que, operando sobre
una coleccin de datos estructurada de acuerdo con las necesidades de una organizacin,
recopila, elabora y distribuye la informacin necesaria para la operacin de dicha organi-
zacin y para las actividades de direccin y control correspondientes, apoyando, al menos
en parte, los procesos de toma de decisiones necesarios para desempear las funciones de
negocio de la organizacin de acuerdo a su estrategia. [And 7]
De un modo genrico y ms conciso podemos decir que el patrn comn de los sistemas
de informacin es un conjunto de procesos formales3 que acta sobre una base de datos
para transformar los datos en informacin.
El ciclo Datos-Informacin-Conocimiento
Hay una estrecha relacin entre estos tres conceptos, pero no son lo mismo y es importan-
te diferenciarlos bien. Son los elementos bsicos en las etapas del ciclo de la generacin
de conocimiento y cada una de ellas necesita de la etapa anterior. Vemos a continuacin
cmo se relacionan:
Datos: Los datos son elementos discretos que carecen de valor por si mismos. Son
la materia prima de la informacin y como tal son la mnima unidad semntica. Se corres-
ponden con elementos primarios de informacin que por s solos son irrelevantes como
apoyo a la toma de decisiones. Tambin se pueden ver como un conjunto discreto de va-
lores, que no dicen nada sobre el porqu de las cosas y no son orientativos para la accin.
Informacin: La informacin se obtiene como resultado del tratamiento de los datos,
de cogerlos, unirlos y estructurarlos, ponerlos en contexto. El valor de la informacin lo
impone la utilidad de la misma para su receptor. Se puede definir como un conjunto de
datos procesados y que tienen un significado (relevancia, propsito y contexto), y que por
lo tanto son de utilidad para quin debe tomar decisiones, al disminuir su incertidumbre.
Conocimiento: El conocimiento aparece cuando la informacin y su receptor entran
en contacto. Para que haya conocimiento, la informacin debe ser reconocida como til y
vlida por el receptor. Este deber hacer un esfuerzo mental, de comprensin, reflexin e
introspeccin de la informacin recibida, deber hacer propio aquello que recibe filtrn-
dolo segn su capacidad y experiencia, y relacionndolo con el acervo cientfico actual.
3
Procesos Formales: La secuencia ordenada de entrada de datos, el tratamiento de los mismos a travs de instruc-
ciones y la obtencin de informacin como salida.
11
De una forma muy resumida podramos definir la informacin como datos en contexto
y conocimiento como informacin en contexto.
Figura 1: El ciclo Datos - Informacin - Conocimiento
El conocimiento se deriva de la informacin, as como la informacin se obtiene de los

datos. Como vemos en el grfico, para obtener conocimiento final a partir de los datos es
necesario realizar una serie de acciones sobre los mismos.
De los datos a la informacin:
Contextualizacin: conocer en qu contexto y para qu propsito se generaron
los datos.
Categorizacin: conocer las unidades de medida que ayudan a interpretarlos.
Clculos: procesado de los datos matemtica o estadsticamente.
Correccin: eliminacin de errores e inconsistencias de los datos.
Agregacin: agrupacin de los datos por mbitos.
De la informacin al conocimiento:
Comparacin: realizar comparaciones de la informacin obtenida con otros ele-
mentos de inters.
Prediccin: definir posibles consecuencias.
Bsqueda de conexiones: identificar similitudes, o relaciones entre la informa-
cin obtenida y el contexto, o informaciones relacionadas.
Debate: Conversacin e intercambio de ideas con otros portadores de conoci-
miento.
Flujo de Informacin: Definimos como flujo de informacin a la caracterizacin de

todas las posibles transformaciones o envos que puede sufrir la misma, en forma de in-
formacin o en forma de datos, dentro del sistema, tanto fsica como lgicamente.
12
2.1.3. Sociedad de la Informacin y Desarrollo
Volviendo al concepto de sociedad de la informacin, es fcil adoptar una postura optimista
con respecto a la misma y el desarrollo humano de los pases ms empobrecidos, pero no hay
que perder de vista que la brecha digital es uno de los principales obstculos en este modelo de
desarrollo. A grandes rasgos, el fenmeno de la brecha digital afecta a todos aquellos sectores
que permanecen, por diversas razones, al margen de los beneficios y ventajas asociados a las
TIC.
Como si de una cadena de subdesarrollo se tratase, las desigualdades en el mundo, de un

modo ms agudo en lo referente a nuevas tecnologas, siguen creciendo y las distancias se van
sumando hasta convertirse en casi insalvables. Es tarea de todos evitar que la revolucin desen-
cadenada por la sociedad de la informacin siga aumentando las desigualdades generadas por la
brecha digital.
En el libro La Sociedad de la Informacin en el siglo XXI: un requisito para el desarrollo,

que nace en el contexto de la Cumbre Mundial de la Sociedad de la Informacin, auspiciada por
Naciones Unidas, se resume de forma clara la relacin entre la evolucin de las nuevas tecnolo-
gas, el acceso a la informacin y las posibilidades de desarrollo que ofrecen:
Las Tecnologas de la Informacin y las Comunicaciones se han convertido en un instrumento

indispensable para la lucha contra la pobreza, y deberan ser vistas como un requisito para el
desarrollo. A travs de ellas, los pases en desarrollo tienen una oportunidad sin precedentes
de conquistar mucho ms eficazmente objetivos de desarrollo de primera necesidad, como son
la reduccin de la pobreza y la provisin de servicios bsicos de salud y educacin. Los pases
que estn en disposicin de aprovechar este potencial de las TIC reflejarn, previsiblemente,un
considerable aumento del crecimiento econmico y del bienestar humano, y aspirarn a moda-
lidades ms robustas de gobierno democrtico y participacin ciudadana. [...]
[...] La notable evolucin de las tecnologas de la informacin y las comunicaciones en los

ltimos aos ha hecho vislumbrar un nuevo abanico de oportunidades para ese grupo de pases
desfavorecidos. Particularmente, porque permiten la reduccin de los problemas de asimetra
de informacin y una mayor facilidad de difusin internacional de los bienes y servicios relacio-
nados con las TIC, con un coste marginal relativamente bajo. En este contexto, las posibilidades
de acceso a la informacin que brinda Internet, ha llevado a concebirla como una fuente poten-
cial de desarrollo futuro.[dCyT 4]
Es cierto que el esfuerzo de las polticas de desarrollo no debe aplicarse nicamente en el

desarrollo de la sociedad de la informacin, sino tambin en el entorno econmico y social. Es
difcil imaginarse que la sociedad de la informacin pueda evolucionar en pases donde no se
cubren las necesidades ms bsicas de gran parte de la poblacin, pero es mejor no perder de
vista, en la medida de lo posible, el apoyo a la Sociedad de la Informacin desde la base y que
las tecnologas sean vistas como un instrumento al servicio del desarrollo.
13
2.2. El Sistema de Informacin de Salud (SIS)
Un Sistema de Informacin de Salud, no es ms que la aplicacin de un Sistema de Informa-
cin a un entorno sanitario. De modo genrico sera un sistema global e integrado, diseado para
gestionar la informacin que se genera en el funcionamiento clnico y administrativo de una red
de establecimientos que conforman un sistema de salud o un hospital.
Para dar una definicin ms especfica debemos en primera instancia hacer una diferenciacin
entre el ambiente hospitalario y el de atencin primaria, puesto que sus necesidades son muy
diferentes, y aunque ms adelante veremos que no generan conjuntos de informacin disjuntos,
ni totalmente independientes uno de otro, requieren diferentes soluciones.
2.2.1. Los diferentes enfoques de un SIS

El Sistema de Informacin Hospitalaria
Se encarga de la gestin de informacin de ingreso y alta de pacientes, facturacin, finanzas,
almacn, gestin de personal, y control de actividades entre otros. Se trata de un conjunto de
ordenadores y equipamiento hospitalario, con su software correspondientes, encargados de ge-
nerar, almacenar e intercambiar informacin entre ellos. En el caso ms avanzado toda la infor-
macin clnica girara alrededor de la Historia Clnica de Paciente, que enva y recoge datos de
las aplicaciones clnicas de los distintos departamentos especializados del hospital, a los siste-
mas de gestin de pacientes, recursos humanos, logstica y control de insumos, e incluso a los
de seguimiento financiero y contable.
En la realidad, en muchos hospitales, la informatizacin arranca en determinadas dependen-

cias hospitalarias y no se posee un sistema global como el descrito en el prrafo anterior, sino
que se cubren de forma modular ciertos departamentos para posteriormente ir creciendo de for-
ma gradual hasta conseguir un sistema global en el mejor de los casos.
El Sistema de Atencin Primaria

Cuando hablamos de atencin primaria frente a atencin especializada, la primera diferencia
que encontramos es que la arquitectura del sistema es muy diferente. Se trata de una estructura
de salud compuesta de centros y puestos ordenados jerrquicamente que trabajan en red. Por lo
cual, mientras que en el Sistema de Informacin Hospitalaria las comunicaciones internas son
las ms importantes, en un sistema de atencin primaria lo son las comunicaciones externas.
Las aplicaciones en estos casos suelen ser muy sencillas; gestin de medicamentos, referencia y
contra-referencia de pacientes, control epidemiolgico, gestin de pacientes, etc.
Como decamos anteriormente estos dos ambientes no son independientes. En los pases en
vas de desarrollo, donde la atencin primaria de las zonas rurales se encuentra en general ais-
lada e incomunicada, cuando hablamos de Tele-medicina nos solemos referir a la aplicacin de
las Tecnologas de la Informacin y la Comunicacin para actuar como puente entre el siste-
ma hospitalario y el de atencin primaria. Permiten comunicar al trabajador de salud aislado
14
con el mdico general o el especialista (apoyo al diagnstico), o permiten el envo de seales
o imgenes mdicas realizadas en un centro hasta otro para su estudio por parte del especia-
lista (tele-radiologa, tele-cardiologa, tele-auscultacin, tele-microscopa). Tambin, en un caso
ideal, ambos ambientes compartiran las historia clnica del paciente, garantizando la continui-
dad de la atencin en todo el sistema de salud. Pero esta es una realidad que se empieza a
alcanzar ahora en los pases ms tecnolgicamente avanzados.
Los Subsistemas de Informacin Verticales

Tambin es importante hablar de los sistemas de control epidemiolgico o de seguimiento de
programas especficos. Suele tratarse en estos casos de aplicaciones especficas que responden a
las necesidades de control de unas determinadas patologas con el fin de controlar brotes y epide-
mias, o al seguimiento de un determinado programa o estrategia vertical de salud. Especialmente
en los pases en vas de desarrollo en los que distintos programas pueden ser financiados por dis-
tintos donantes (con gran inters en el control de la informacin de su programa), o tambin
desde el gobierno, que puede lanzar programas especficos de seguimiento, como por ejemplo
de control de la malaria, de crecimiento del nio, de salud materna, de VIH/SIDA, etc. Estos sis-
temas afectan tanto al entorno hospitalario como al de atencin primaria, puesto que en ambos
se genera informacin de este tipo.
En este aspecto los sistemas estn evolucionando en dos direcciones. Por un lado, hacia un
modelo de integracin de toda la informacin en un almacn de datos comn, con el fin de evitar
la fragmentacin, la redundancia de datos y la inconsistencia inherente al hecho de manejar in-
formacin duplicada de diversas fuentes que introducen los programas verticales. Por otro lado,
el enfoque en que la informacin estadstica se entiende como datos introducidos en el sistema
directamente en forma de valores agregados, est perdiendo fuerza debido a que resulta imposi-
ble navegar hacia una informacin de granularidad ms fina, como pueda ser la informacin de
paciente, bien sea para estudios estadsticos o para comprobar su autenticidad. Cada vez ms los
datos agregados en un sistema de salud deben ser datos calculados a partir de combinaciones de
registros de datos personales de paciente.
2.2.2. Estndares
La existencia de los Sistemas de Informacin de Salud para gestin integrada de sistemas sa-
nitarios requiere del uso de estndares para el registro, codificacin, almacenamiento, seguridad
y envo de informacin. Estos estndares afectan tanto a la comunicacin interna del sistema
global, como para intercomunicacin de sistemas aislados, pero no totalmente independientes.
Existe una demanda de sistemas abiertos, distribuidos e interoperables, que garanticen fiabi-
lidad y unos requisitos de calidad y seguridad muy exigentes, intrnsecos al sector salud. Los
expertos trazan el itinerario futuro hacia la adopcin de estndares tcnicos como clave para la
planificacin, diseo, implementacin, escalabilidad, y mantenimiento de este tipo de sistemas.
15
En el sector TIC para la salud podemos destacar estndares de contenidos y estructura, de re-
presentacin de datos clnicos, de comunicacin, de seguridad de datos y confidencialidad y de
autenticacin. Hay muchos proyectos de estandarizacin a nivel nacional, regional o internacio-
nal, por lo que resulta complejo dar una visin completa de la situacin actual, pero intentaremos
hacer un recorrido por aquellos estndares ms importantes y con cierto grado de aceptacin en
el mercado.
En cuanto a arquitectura de Historia Clnica debemos mencionar el estndar ISO 19308

(Requirements for an Electronic Health Record Reference Architecture) [ISO02], que define un
conjunto de requisitos clnicos y tcnicos, para una arquitectura de historia clnica que soporta el
uso, comparticin e intercambio de registros electrnicos, entre y a travs de diferentes sectores
de salud, diferentes pases y diferentes modelos de asistencia sanitaria.
Existen tambin normas para la codificacin estandarizada de enfermedades o resultados

de pruebas clnicas ampliamente utilizado en formularios tanto en papel como electrnicos. El
estndar SNOMED-CT (Systematized Nomenclature of Medicine-Clinical Terms) es una ter-
minologa clnica integral que se define como de las ms importantes desarrolladas en el mundo
y permite representar informacin clnica de forma precisa y unvoca. La mantiene y distribuye
la International Health Terminology Standards Development Organisation (IHTSDO). En la co-
dificacin de enfermedades es el estndar CIE (Clasificacin Internacional de Enfermedades),
el que ms fuerza tiene, siendo utilizado a nivel internacional. Fue desarrollado por la OMS y se
encuentra en su dcima versin, aunque se encuentra ms implementada a da de hoy la versin
anterior (CIE9). Es una codificacin arbrea que recoge enfermedades y una amplia variedad
de signos, sntomas, hallazgos anormales, denuncias, circunstancias sociales y causas externas
de daos y/o enfermedad.
Para la comunicacin entre Sistemas de Informacin de Salud, o entre distintos mdulos

de un sistema, debemos destacar el conjunto de estndares HL7 (Health Level Seven) para el in-
tercambio electrnico de informacin clnica. Son desarrollados por la HL7 International, que es
una organizacin con base en Estados Unidos, y delegaciones en casi todos los pases del mundo,
dedicada al desarrollo de estndares en el campo de la informacin sanitaria, que est acredita-
da por la autoridad oficial de estandarizacin americana (ANSI). Est enfocada al desarrollo de
especificaciones de mensajera en el nivel de aplicacin (nivel 7 del modelo OSI) entre siste-
mas de informacin sanitaria, pero tambin en otras reas como documentos clnicos y soporte
a la decisin. HL7 Versin 2 es la versin mas implantada del estndar, incluso tras la aparicin
de la tercera versin, que mejora claramente tanto la sintaxis como la semntica de los mensajes.
A un nivel de comunicacin interna de equipamiento mdico, en concreto para equipa-

miento de almacenamiento, visualizacin y envo de imgenes mdicas se define el estndar
DICOM (Digital Imaging and Communication in Medicine) que estructura las comunicaciones
y formatos de mensajes para imgenes diagnsticas y teraputicas.
No solo existe la posibilidad de intercambiar datos, sino que tambin se da el intercambio

de informacin. SDMX-HD (Statistical Data and Metadata Exchange - Health Domain), es la
16
implementacin de la OMS para favorecer la gestin, publicacin e intercambio de indicadores
estadsticos, sus valores y definiciones. Nace del estndar ISO/TS 17369:2005 para el inter-
cambio de datos y meta-datos estadsticos (Statistical Data and Metadata Exchange standard,
SDMX) desarrollado por las Naciones Unidas.
Para permitir la comunicacin de informacin del Registro Mdico Electrnico o Historia Cl-
nica Electrnica (HCE) del paciente entre sistemas y componentes que necesitan aadir, modifi-
car, transferir o acceder a datos de la HCE, el estndar mas moderno y completo es el ISO/CEN
13606. Este estndar sigue una innovadora arquitectura de Modelo Dual que define una clara
separacin entre informacin y conocimiento. La interaccin de un Modelo de Referencia, para
el almacenamiento de los datos (informacin), y un Modelo de Arquetipos, para describir se-
mnticamente esas estructuras de datos (conocimiento), proporciona una novedosa capacidad de
evolucin de los Sistemas de Informacin. El conocimiento (los arquetipos) pueden cambiar en
el futuro, pero los datos permanecern intactos.
2.2.3. Software de Informacin de Salud

El software Libre en Pases en Desarrollo
Histricamente el desarrollo de software siempre ha ido ligado a un modelo de propiedad de
conocimientos, protegidos por una serie de derechos intelectuales junto con una fuerte jerarqua
corporativa que dirige el proceso de desarrollo. El software juega un papel cada da ms impor-
tante en el mercado econmico global y las organizaciones internacionales.
La capacidad de un pas y sus empresas de interactuar con ese mercado est muy restringido
por su capacidad tecnolgica. De hecho, no se entiende hoy en da la inclusin en el mercado y
la economa global de un pas u organizacin sin unas muy potentes capacidades tecnolgicas.
Es por lo tanto crucial para el desarrollo de un pas, tomar medidas y decisiones en la lnea de la
inversin y formacin en la introduccin de nuevas tecnologas.
De nuevo nos encontramos frente a los efectos de la brecha digital. Los pases en desarrollo
tienen presupuestos limitados destinados a tecnologas de la informacin y la mayora de los
gobiernos de pases en desarrollo estn abogando por el uso de Software Libre, FOSS de su
nombre en ingls, Free and Open Source Software, en los casos en que este sea una alternativa
factible al software propietario.
En un anlisis en profundidad de la idoneidad del software libre para el crecimiento tecnolgi-

co de pases en vas de desarrollo, Weber [Web03] hace una interesante lista de tres motivaciones
que pueden explicar el porqu estos pases han adoptado en muchos casos soluciones libres:
Independencia: Muchos pases en desarrollo han reconocido que son cada vez ms de-
pendientes de los proveedores de software ubicados en sus pases. El coste asociado de
la implementacin, licencias, y mantenimiento de este software propietario es elevado, y
adems son servicios que no nutren la economa nacional. Con la adopcin de software
17
libre, contratistas locales pueden competir en precio y calidad en la provisin de sopor-
te y mantenimiento, generando as empleo e impulsando la economa. El problema de la
compra de licencias excesivamente caras desaparece, y adems el mantenimiento se puede
llevar a cabo sin que suponga un gran coste, ya que la modificacin de cdigo es gratuita.
Seguridad y Autonoma: La seguridad es una de las grandes ventajas del software libre
frente al propietario. El argumento de ms peso es que hay menos bugs o defectos de
software y cuando son identificados se solucionan mucho ms rpido. Adems FOSS ga-
rantiza que el software es seguro, ya que el cdigo puede ser inspeccionado. Los gobiernos
necesitan confiar en sistemas sin elementos controlados por terceras partes, posiblemente
ubicadas fuera del pas, representando una posible amenaza de seguridad nacional. Otro
beneficio del uso de software libre en sistemas crticos de un gobierno es que se obtiene
diversidad en la base tcnica, disminuyendo en cierto modo los potenciales riesgos deriva-
dos del uso de cdigo monoltico. Una de las obligaciones de la mayora de los gobiernos
es la de ofrecer acceso gratuito a la informacin pblica. El uso de estndares y forma-
tos abiertos en lugar de datos vinculados a proveedores individuales garantiza este acceso
libre. Incluso, para asegurar la permanencia de esos datos es importante no estar condi-
cionado a la voluntad de un proveedor nico o una situacin de monopolio. Los pases
en desarrollo tambin sienten que su influencia en cmo se desarrolla el software propie-
tario es muy limitada. El software libre promete ms flexibilidad y permite aportaciones
propias en el proceso de desarrollo.
Derechos de propiedad intelectual y productividad: La intensa lucha contra la piratera de

software ha llevado a muchos pases a decantarse por el uso de cdigo libre como alter-
nativa al software propietario de elevado coste. Los bajos costes es una cosa, la propiedad
del software es otra. Eligiendo herramientas FOSS, la posibilidad de uso y expansin del
software no est limitada por derechos de propiedad, el potencial de una herramienta solo
est limitado por el conocimiento, y capacidad de aprendizaje e innovacin del usuario.
La extensa utilizacin de software libre generar una infraestructura dependiente de otros
productos y servicios, siendo un potencial impulso a la economa local. La combinacin
de mano de obra tcnica de coste razonable, junto el uso de software gratuito, por parte de
empresas locales de mercados emergentes, pude ofrecer ventajas competitivas tanto en el
mercado global como local.
Parece quedar justificada de un modo muy razonable, la apuesta por el uso del software libre,
no solo en pases en vas de desarrollo, sino de un modo global. Aunque bien es cierto que
mientras en los pases tecnolgicamente desarrollados se trata de una opcin, que en ocasiones
puede causar desconfianza y un esfuerzo aadido por el modelo que se acostumbra a usar, en
pases con dificultades en el desarrollo de su tejido tecnolgico es la nica opcin viable si se
quiere progresar hacia un desarrollo de calidad y sostenible.
Soluciones existentes
La oferta de sistemas de informacin de salud de cdigo abierto es muy amplia y abarca muchos
mbitos del entorno sanitario. Se muestra a continuacin una seleccin de entre las numerosas
18
herramientas existentes para gestin de informacin de salud libres, con el objetivo de transmitir
el nivel de presencia que los desarrollos de gestin sanitaria tienen en esta comunidad.
CHITS [GPL, QPL | Linux | Basado en web] - Community Health Information Tracking
System es un sistema de informacin extensible, modular, basado en cdigo abierto para
las unidades de salud rurales (inicialmente de Filipinas). Recoge datos de salud de rutina
de los programas verticales en el mbito del servicio de salud del Sistema de Informacin
(FHSIS) y las integra en un nico y completo sistema de informacin computerizado.
ClearHealth [GPL | - | Basado en web] - ClearHealth es un software para gestin de his-
toria clnica electrnica. Incluye soporte demogrfico, programacin, facturacin mdica
completa, tratamiento de enfermedades, de apoyo a las decisiones, y e-Prescribing entre
otros servicios.
CottageMedTM [GPL | Windows, Mac, Linux | Filemaker] - CottageMed TM FileMaker
Pro es una aplicacin que es flexible, fiable y estable basado en un sistema seguro de
Registros Mdicos Electrnicos, con seguridad de red inalmbrica. Se basa en el gestor de
base de datos Filemaker Pro4 , que es software propietario.
DHIS2 [BSD | multiplataforma | Basado en web] - District Health Information System
proporciona los medios para la entrada de datos, generacin de informes y anlisis. Es
parte de un iniciativa ms amplia de recoleccin y tratamiento de datos para la atencin de
la salud en los pases en desarrollo, denominado Health Information System Programme
(HISP).
HOSxP [GPL | Windows | Cliente-Servidor] - HOSxP es un sistema de informacin ba-
sado en la tecnologa cliente/servidor utilizado en 150 hospitales de Tailandia. HOSxP
tiene muchos mdulos que conservan los datos de la imagen mdica del paciente, los sn-
tomas que presenta, su condicin fsica, datos de investigacin, diagnstico, tratamiento
propuesto, etc
MedClipse [GPL | multiplataforma | Nativo] - MedClipse es una aplicacin para gestin
de Historia Clnica Electrnica basada en cdigo abierto. Incorpora gestin del orden
del da, la facturacin, mdicos y administracin de la gestin de datos, recetas y otras
herramientas.
Medical [GPL | Linux | Basado en Web] - Medical es un sistema de informacin sani-
tario y hospitalario en software libre que ofrece las funcionalidades de Registro Mdico
Electrnico, Sistema de informacin Hospitalario, y Sistema de informacin de salud.
Se desarrolla como complemento vertical de OpenERP5 desarrollado para la gestin de
4
FileMaker Pro es una aplicacin multiplataforma (Windows y Mac) de base de datos relacional de FileMaker Inc.
(una subsidiaria de Apple Inc.). FileMaker integra el motor de la base de datos con la interfaz, lo que permite
a los usuarios modificar la base de datos al arrastrar elementos (campos, pestaas, botones...) a las pantallas o
formas que provee la interfaz.
5
Open ERP es un sistema de ERP y CRM. Tiene componentes separados en esquema Cliente-servidor. Dispone de
interfaces XML-RPC, y SOAP. Cuenta con mdulos de contabilidad analtica, contabilidad financiera, gestin
de almacenes/inventario, gestin de ventas y compras, automatizacin de tareas, y campaas de marketing entre
otros.
19
centros hospitalarios y sanitarios.
MirrorMed [GPL | Linux | Basado en web] - MirrorMed es un software de Historia Clnica

Electrnica y Gestin de la Prctica de la Medicina. Se basa en el cdigo obtenido de los
proyectos ClearHealth, Freemed y OpenEMR.
OpenEMR [GPL | Windows, Mac, Linux | Basado en web] - Es una aplicacin para admi-
nistracin de prctica mdica, registro mdico electrnico (historia clnica), prescripciones
mdicas y facturacin.
OpenMRS [OpenMRS Public License | Windows, Mac, Linux | Basado en web] -OpenMRS
es una comunidad de desarrolladores, basada en el cdigo libre. Su aplicacin se sita den-
tro del marco del sistema de Historia Clnica Electrnica, destinado a mejorar la asistencia
sanitaria en entornos de recursos limitados.
OpenVista [AGPL | multiplataforma | Basado en web] - OpenVista es la versin de cdigo

abierto de Vista, un Sistema de Informacin de Salud desarrollado originariamente por
por el U.S. Veterans Affairs, implantado en mas de 1.500 establecimientos de salud a
nivel global. Es una herramienta que busca aumentar la eficiencia clnica y operacional
del sistema sanitario. Su mayor potencial es la capacidad de almacenar informacin de la
Historia Clnica Electrnica de los pacientes.
OSCARMcMaster [GPL | multiplataforma | Basado en web] - OSCAR (Open Source Cli-

nical Application and Resource), de la Universidad de McMaster, se basa en la Historia
Clnica Electrnica. Es un sistema desarrollado para uso profesional en atencin primaria
y cuidados clnicos.
Ultimate EMR [GPL | Windows, Linux | Basado en web] - Indicada para pequeos pro-
veedores de servicios mdicos. Incluye funcionalidades bsicas de Historia Clnica Elec-
trnica: la historia del paciente, visitas anteriores, Rx, Alergias, Labs, vitales, Notas y
Procedimientos.
Se explican a continuacin, con algo ms de detalle, las soluciones ms utilizadas; OpenMRS,

OpenEMR, DHIS,y HRHIS.
OpenMRS
Es una plataforma de cdigo abierto para sistemas de registros mdicos, aplicada sobre to-
do en pases en vas de desarrollo. Se trata de una aplicacin cliente/servidor y orientada a la
web, por lo que se requiere el uso de un navegador en el terminal cliente. Actualmente existe
una comunidad de desarrollo que implementa nuevas funcionalidades, que se aaden en forma
de mdulos al ncleo del sistema. Algunos ejemplos pueden ser los mdulos de informes, la-
boratorio, radiologa, etc. Todos ellos intercambian informacin con el ncleo del OpenMRS
siguiendo los estndares HL7. En estos momentos OpenMRS ha sido implantado con xito en
pases tales como Sudfrica, Kenia, Ruanda, Zimbabue, Mozambique, Uganda, Tanzania, Haiti,
India, China.
20
OpenEMR
Es una aplicacin para administracin de prctica mdica, registro mdico electrnico (his-
toria clnica), prescripciones mdicas y facturacin. Es una de las aplicaciones de Gestin de
Registros Mdicos Electrnicos de Software Libre ms populares en uso hoy en da a nivel
mundial, tanto en pases desarrollados como en aquellos en vas de desarrollo. Es un proyecto
que ha sido calificado de exitoso en un estudio de calidad de software puntuando la cantidad
de cdigo subido al repositorio, mensajes publicados en los foros de discusin, y nmero de
personas implicadas en estas actividades [Nol 9].Se trata de un sistema multi-plataforma (MS
Windows, MAC OS X, Linux, FreeBSD). Se utiliza generalmente en entornos donde se practica
la medicina individual como clnicas de pequeo tamao.
DHIS
Es una herramienta para recoleccin, validacin, anlisis y presentacin de datos estadsticos
agregados, diseada para actividades integradas de administracin de informacin de salud. Es
una herramienta genrica, lejos de ser una aplicacin de base de datos preconfigurada, con un
modelo de meta-datos abierto y una interfaz de usuario flexible que permite al usuario disear
los contenidos de la informacin especfica del sistema, sin necesidad de programar nada. Es una
herramienta modular, basada en web, desarrollada con frameworks Java gratuitos y de cdigo
abierto. DHIS nace como herramienta para el manejo de datos estadsticos agregados, pero su
evolucin y los requisitos del usuario la llevan a mirar hacia el registro individual de paciente
como fuente de informacin. Este es uno de los aspectos en los que DHIS2 est creciendo e
introduciendo muchas de las mejoras y actualizaciones.
HRHIS
Se trata de un sistema para la recoleccin, procesado, administracin y distribucin de datos
en recursos humanos en salud. En funcin del nivel de desarrollo del sistema de salud, su or-
ganizacin y su capacidad de trabajo, un HRHIS puede utilizar el ordenador o estar basado en
papel. Incluye informacin de las cantidades y distribucin de los trabajadores de salud y hace
un seguimiento a su evolucin profesional.
2.3. El Sistema Sanitario de Per

2.3.1. Contexto y realidad socio cultural de Per
La Repblica del Per es un pas situado en la parte occidental e intertropical de Amrica del
Sur. Limita al norte con Colombia (con 1506 km de frontera), al noroeste con Ecuador (1.420
km), al este con Brasil (2.995 km), al sudeste con Bolivia (1.075 km), al sur con Chile (171 km),
y al oeste colinda con el Ocano pacfico, con 2.414 km de costa. La superficie de Per es de
1.285.216 km2 (Espaa tiene 504.6451 km2). Es el vigsimo pas ms grande del planeta y el
cuarto de Amrica Latina.
21
Figura 2: Mapa poltico del Per
Geogrficamente se puede dividir en tres grandes zonas, costa, sierra, y selva. La costa, franja
litoral de 80 a 150 km de anchura, es una zona de clima desrtico. Es la regin ms poblada
y de mayor desarrollo industrial y occidentalizada del pas, puesto que en ella se encuentran
las grandes ciudades como Lima, Arequipa o Trujillo. La sierra posee un clima de alta montaa
fro y seco. Constituye la zona de altiplanicie andina, en la que se diferencian dos cordilleras,
la Occidental y la Oriental, y se encuentra su pico ms alto, el Huascarn con 6768 m en su
cumbre sur. Por ltimo, la selva, que es un vasto sector amaznico drenado por los ros Maran
y Ucayali. Tiene un clima tropical caluroso y hmedo. Es la zona ms deshabitada del pas con
una densidad de 3 hab./Km2, convirtindose en la frontera interior de Per.
A nivel administrativo, el territorio de Per est organizado en circunscripciones territoriales

que son, de mayor a menor jerarqua; departamentos, provincias, distritos y centros poblados.
Estos organizan al Estado y al gobierno en niveles nacional, regional y local. Cada nivel de
gobierno tiene autonoma, y el derecho a regular y administrar los asuntos pblicos de su com-
petencia.
El pas se compone de 24 departamentos y una provincia constitucional, la Provincia del Ca-

llao. Cada departamento se halla a su vez dividido en provincias y estas en distritos. En total el
pas cuenta con 195 provincias y 1.841 distritos.
22
Per cuenta con una poblacin total de 29.248.9436 habitantes. La distribucin por edades es
de un 28,5 % menores de 14 aos (de los cuales el 50,9 % son hombres y el 49,1 % mujeres), un
65,1 % de entre 15 y 64 aos (de los cuales el 48,9 % son hombres y el 51,1 % mujeres) y un
6,4 % tienen 65 aos o ms (de los cuales el 47,5 % son hombres y el 52,5 % mujeres). La edad
media se fija en 26,2 aos (25,5 para los hombres y 26,8 para las mujeres). La tasa de crecimien-
to demogrfico es de un 1,029 % en 2011, con una tasa de natalidad de 19,41 nacimientos por
cada 1.000 habitantes, y una tasa de mortalidad de 5,93 muertes por cada 1.000 habitantes.
La distribucin tnica de la poblacin es de un 45 % de amerindios, un 37 % mestizos (mez-

cla de amerindios con raza blanca), una representacin del 15 % de raza blanca, y un 3 % de
procedencia china o japonesa, raza negra y otras minoras. En cuanto al idioma, se habla mayo-
ritariamente el espaol, con un 84,1 %, el 13 % hablan Quechua, que tambin es lengua oficial, el
1,7 % Aymara, el 0,3 % Ashaninka, un 0,7 % habla lenguas amaznicas minoritarias, y el 0,2 %
restante habla otras lenguas.
En un repaso a los principales indicadores de desarrollo del Per, podemos ver que ocupa el
puesto 80 de 187 en la ltima clasificacin de pases del PNUD por IDH, siendo este de un 0,725,
(0,002 por debajo de su IDH de 2010), considerado como un IDH Alto. An as el porcentaje de
poblacin que vive por debajo del umbral de pobreza es del 34,8 %.
La Regin de Loreto
El departamento o regin de Loreto se sita en la parte nor-oriental de Per. Ocupa una su-
perficie de 368.852 km2 que representa el 28,7 % del territorio nacional siendo el departamento
ms extenso del pas. El territorio en que se encuentra Loreto pertenece al Llano Amaznico,
cuyas altitudes mxima y mnima son 220 y 61 metros sobre el nivel del mar respectivamente.
Administrativamente, el departamento de Loreto est dividido en 7 provincias y 51 distritos,

en los cuales se ubican 705 de las 1.786 comunidades indgenas existentes a nivel nacional.
Su capital es la ciudad de Iquitos, perteneciente a la provincia de Maynas, de la cual tambin
es capital. Segn las proyecciones del INEI (Instituto Nacional de Estadstica e Informtica),
en el ao 2010, Loreto contaba con una poblacin de 983.371 habitantes, la cual representa el
3,34 % de la poblacin nacional y tiene una densidad poblacional de 2,4 habitantes por Km2.
Por sexo, los hombres representan el 52,2 % y las mujeres el 47,8 % de la poblacin total del
departamento.
Cuadro 2: Poblacin de Loreto por Provincias

Provincia Poblacin
Maynas 539.901
Alto Amazonas 114.853
Requena 71.633
6
Segn datos del CIA World Factbook https://www.cia.gov/library/publications/the-world-factbook/geos/pe.html
23
Cuadro 2 - Continuacin
Provincia Poblacin
Ucayali 68.736
Loreto 68.195
Mariscal Ramn Castilla 63.374
Datm del Maraon 56.679
Como vemos en la tabla las provincias ms pobladas son Maynas y Alto Amazonas, con
539.901 y 114.853 habitantes, respectivamente, siempre segn la proyeccin poblacional del
INEI para 2010, y ms del 80 % de la poblacin total se concentra en cuatro provincias; May-
nas, Alto Amazonas, Requena y Loreto.
Figura 3: Mapa del Departamento de Loreto
El IDH promedio de la regin de Loreto 7 es de 0,5248, que es considerado un IDH medio,

frente al 0,725 nacional. A nivel provincial, Maynas tiene el ms alto con un 0,5476, y Loreto
(provincia) el ms bajo, con un IDH del 0,4679, al nivel de Papua Nueva Guinea o la Republica
Unida de Tanzania, ambos con un IDH de 0,466, que es considerado un IDH bajo.
7
Segn informe de Ordenamiento Territorial www.regionloreto.gob.pe
24
Figura 4: ndice de Pobreza de Loreto por Provincias
La esperanza de vida al nacer es de 71,7 aos, frente a los 74,1 aos a nivel nacional. Y, como
podemos observar en la figura 4 los datos de incidencia de la pobreza tambin se disparan si los
comparamos con los ndices medios nacionales, fijados en un 38,4 %.
2.3.2. El Sistema Sanitario de Per

Estructura del Sistema Nacional de Salud
A nivel Nacional es el Ministerio de Salud de Per (MINSA) la entidad que trabaja con el fin
de promover y mejorar la salud, previniendo las enfermedades y garantizando la atencin inte-
gral de todos los habitantes del pas; proponiendo y conduciendo los lineamientos de polticas
sanitarias en concertacin con todos los sectores pblicos y los actores sociales.
En el ao 2004, el MINSA inicia un proceso de descentralizacin de la funcin salud y a

trmino de 2009 se haba logrado culminar la transferencia de las 16 funciones sectoriales, las
125 facultades y los recursos asociados, a los 25 gobiernos regionales, incluyendo a la Regin
Lima-Provincia y el Callao. De este modo, cada Gobierno Regional o de Departamento tiene
asociada una Direccin Regional de Salud (DIRESA), cuyas funciones principales son de go-
bierno, regulacin, monitoreo y evaluacin del sistema sanitario.
Sobre cmo se estructura la atencin sanitaria, a nivel nacional, el ministerio clasifica los
establecimientos segn las funciones que desempean y sus caractersticas, las cuales definen
el nivel de complejidad de las demandas que pueden asumir. En esta clasificacin existen tres
niveles de atencin:
Primer Nivel: Donde se atiende el 70-80 % de la demanda del sistema. La severidad de

los problemas de salud en este nivel, plantean una atencin de baja complejidad con una
oferta de gran tamao y con menor especializacin y tecnificacin de sus recursos. Se
desarrollan principalmente actividades de prevencin y proteccin especfica, diagnstico
precoz y tratamiento oportuno de las necesidades de salud ms frecuentes.
25
Segundo Nivel: Donde se atiende entre el 12 y el 22 % de la demanda. Se enfoca en
la promocin, prevencin y diagnstico de la salud, brindando acciones y servicios de
atencin ambulatoria y hospitalizacin a pacientes derivados del primer nivel, o de los
que se presentan de modo espontneo en urgencias. Las necesidades de salud requieren
atencin de complejidad intermedia.
Tercer Nivel: Donde se atiende del 5 al 10 % de la demanda. Este nivel se ubica en grandes
ciudades y constituye el centro de referencia de mayor complejidad nacional y regional.
Lo conforman especialistas para la atencin de problemas patolgicos complejos, que
necesitan equipo e instalaciones especiales.
En funcin de estos niveles de atencin se definen ocho categoras de servicio, y sus estable-
cimientos asociados.
Figura 5: Categoras de los Establecimientos de Salud de Per
La categorizacin de los Establecimientos del Sector Salud se encuentra especificada en una

norma tcnica [dSdP04], elaborada por el MINSA, que establece las categoras necesarias para
el adecuado funcionamiento de los servicios. A continuacin se detallan las funcionalidades,
infraestructura y equipo humano que conforman cada categora de los establecimientos de salud:
Categora I-1: Pertenece al primer nivel de atencin. Es responsable de satisfacer las

necesidades de salud de la poblacin de su mbito jurisdiccional, a travs de una atencin
integral ambulatoria basada en la promocin de la salud y en la prevencin de los riesgos
y daos. Los establecimientos de esta categora dependen de los Centros de Salud y estn
situados en poblaciones, en la mayora de los casos, aisladas, en reas de baja densidad de
poblacin y generalmente con menos de 1.000 habitantes. En su mayora, no cuentan con
lnea telefnica y estn mal dotados de infraestructura de carreteras y suministro elctrico.
Contar como mnimo, con un Tcnico de Enfermera (debidamente capacitado) y puede
adicionalmente contar con una Enfermera y/o Obstetriz.
Categora I-2: En este caso, y al contrario que la categora I-1, realiza una atencin m-
dica integral ambulatoria. Al igual que los establecimientos de la categora anterior, se
26
encuentran en zonas aisladas y disponen de muy poca infraestructura elctrica y de comu-
nicaciones para su funcionamiento.
Categora I-3: Brinda atencin mdica integral ambulatoria, con acciones de promocin
de salud, prevencin de riesgos y daos, y la recuperacin de los problemas de salud ms
frecuentes, a travs de servicios bsicos de salud de complejidad inmediata superior a las
categoras I-2. Generalmente se encuentran situados en capitales de provincia o distritos.
Categora I-4: Brinda atencin mdica integral ambulatoria y con internamiento de corta
estancia, principalmente enfocada al rea materno-perinatal e infantil. Los servicios de
salud ofertados tienen una complejidad superior a la categora I-3.
Categoria II-1: Lo conforman establecimientos de salud del segundo nivel de atencin,

y son los responsables de satisfacer las necesidades de salud de la poblacin de su mbito
jurisdiccional, proporcionando una atencin ambulatoria y hospitalaria en varias especia-
lidades bsicas: medicina interna, ginecologa, ciruga general, pediatra, anestesiologa,
prevencin de riesgos y daos, recuperacin y rehabilitacin de problemas de salud. Para
el MINSA corresponden al Hospital I. Se encuentra dentro del mbito de la Direccin de
la Red de Salud y es el establecimiento de referencia de las microrredes de salud.
Categora II-2: Brinda atencin integral ambulatoria y hospitalitaria especializada, con

nfasis en la recuperacin y rehabilitacin de problemas de salud. Esta categora corres-
ponde al Hospital II del MINSA. Se encuentra dentro del mbito de la Direccin de Salud
y constituye el establecimiento de referencia de las Redes de Salud y Hospital I.
Categora III-1: Brinda atencin ambulatoria y hospitalaria altamente especializada, con

nfasis en la recuperacin y rehabilitacin de problemas de salud a travs de unidades
productoras de servicios de salud mdico-quirrgicos de alta especialidad. Para el MINSA
corresponde al Hospital III. Se ubica a nivel del mbito nacional y constituye el centro de
referencia de mayor complejidad nacional y regional.
Este proyecto se enmarca en la atencin sanitaria en zonas rurales, las cuales, como hemos
comentado con anterioridad quedan en su mayora cubiertas por establecimientos del primer ni-
vel de atencin, es decir las categoras I-1, I-2, I-3 e I-4. En estas categoras se encuentran los
puestos y centros de salud, descritos con detalle en el captulo I, el captulo de presentacin .
Los establecimientos de salud de cada regin se estructuran en una jerarqua de rbol. Los
Centros de Salud son los establecimientos de primer nivel de mayor jerarqua, son centro de re-
ferencia de varios Puestos de Salud, y conforman Microrredes de Salud, que a su vez se agrupan
en Redes de Salud.
Las Direcciones de Red de Salud tienen a su cargo, como rganos desconcentrados, a los
hospitales II y I que brindan atencin de salud de mediana y baja complejidad y como unidades
orgnicas de lnea a las diferentes Microrredes de Salud. Por ltimo, en un nivel superior, las
Direcciones Regionales de Salud (DIRESA) tienen a su cargo a las Direcciones de Red de Salud
27
y a los Hospitales III que brindan atencin de salud de alta complejidad.
Figura 6: Estructura del Sistema Regional de Salud
El sistema de Salud de Loreto

Segn datos del Gobierno Regional de Loreto, la regin cuenta con 352 establecimientos de
salud; tres hospitales, 52 Centros de salud y 297 puestos, de estos ltimos, 263 son de categora
I-1, atendidos solo por un sanitario o enfermera, muchas veces en locales precarios construidos
por las municipalidades o la misma comunidad. Es decir, si sumamos los centros de salud con
los puestos de salud de categora I-2, solo en un 24,23 % de los establecimientos hay presencia
mdica, quedando que el 75,77 % de los establecimientos de atencin primaria son puestos de
salud de categora I-1, que tienen menos capacidad resolutiva y un menor equipamiento.
Los establecimientos de salud de Loreto se dividen en 36 microredes de salud, que son coor-
dinadas por 8 Direcciones de Red de Salud: Maynas Ciudad, Maynas Periferia, Mariscal Ramn
Castilla, Loreto, Ucayali, Requena, Alto Amazonas y Datm del Maraon. Es en las microredes
de Napo y Mazn, bajo la Direccin de Red de Salud de Maynas Periferia, en las que se en-
cuentran los establecimientos de salud de la cuenca del Ro Napo, donde se centra el trabajo de
EHAS.
Los establecimientos son, en la microred de Mazn; Huamn Urco; y en la de Santa Clotilde;

San Rafael, Rumi Tuni, Campo Serio, Angoteros, Tuta Pishco, Negro Urco, Tacsha Curaray,
Tempestad, Torres Causana y Cabo Pantoja. Ambas Microrredes se encuentran en la misma Red
28
de Salud que el Hospital Regional de Loreto (HRL), su hospital de referencia, que a su vez ges-
tiona los Centros de Salud de Mazn y Santa Clotilde.
Cada establecimiento de salud de la Red se encuentra bastante aislado del resto, siendo la va
fluvial la nica forma de comunicacin terrestre entre los diferentes puntos. Vemos su ubicacin
a lo largo del ro en la siguiente figura.
Figura 7: Establecimientos de Salud en la cuenca del Ro Napo
Como resultado del desarrollo de un proyecto de implantacin de una red de telecomunica-

ciones llevado a cabo por Fundacin EHAS durante los aos 2007 y 2008, todos los estableci-
mientos de la cuenca del Ro Napo se encuentran conectados por una red de telecomunicaciones
entre s y con el Hospital Regional de Loreto, su hospital de referencia.
La red cubre un total de ms de 400 km de distancia, proporcionando servicios de acceso a

telefona e Internet, logrando el contacto de 16 centros y puestos de salud entre s y con Iqui-
tos, donde se encuentran la Direccin Regional de Salud (DIRESA) y el Hospital Regional,
aumentando de esta forma, la sostenibilidad y el impacto de la red. Los enlaces troncales que se
muestran en la figura siguiente, conectan repetidores distanciados hasta 50 km entre s. Para esto
se utiliza la tecnologa de comunicaciones WiFi (estndar IEEE 802.11) modificada para largas
29
distancias, lo que se conoce con el nombre de WiLD-EDCA. Dado que esta tecnologa necesita
lnea de visin entre los extremos de cada enlace de comunicacin, los repetidores instalados en
la red Napo constan de estructuras de torres ventadas de gran altura (hasta 90 metros).
Figura 8: Esquema Tcnico de la Red
Este sistema de comunicaciones proporciona conectividad de banda ancha, es decir, supe-

rior a 1Mbps. Existen varios puntos de acceso a Internet para la red Napo: una conexin DSL
en Iquitos y una conexin satelital en Santa Clotilde. Los servicios de datos que funcionan en
esta red son todos los que puede proporcionar una red de banda ancha con acceso a Internet:
correo electrnico, mensajera instantnea, gestin de la red, sistemas de informacin remota
(basados en Web y bases de datos), videoconferencias, transmisin de audio e imgenes mdi-
cas para consulta remota, navegacin Web y acceso a Internet. Los nicos emplazamientos que
slo disponen de servicio de telefona IP son Copal Urco y Tpac Amaru, ya que no disponen
de personal sanitario.
No es habitual encontrar una red de salud rural tan bien comunicada ubicada en una orografa
tan compleja. La red lleva cerca de tres aos funcionando y ha recibido una aceptacin muy
positiva. La comunicacin entre centros ha resultado altamente til, y en la actualidad se estn
poniendo en marcha proyectos de tele-medicina con el fin de proporcionar servicios de tele-
estetoscopia, tele-microscopa, y tele-ecografa.
La red tambin se utiliza para el envo de datos entre centros, pero, segn un estudio de identi-
ficacin llevado a cabo en la zona, el uso de la misma para la gestin de la informacin sanitaria
30
no es del todo satisfactorio, y no se saca todo el rendimiento que puede ofrecer a este aspecto.
Lo vemos con detalle en el siguiente apartado.
2.3.3. El Sistema de Informacin de Salud en Loreto

En una identificacin del uso de Sistemas de Informacin en los establecimientos mdicos
aislados de la Regin de Loreto, realizada por los ingenieros Nacho Foche y Jose Garca (de la
Fundacin EHAS), Edwin Leopoldo Bentez y River Quispe (del GTR), y Germn Hirigoyen
(de la Fundacin FUNDATEL) en los establecimientos mdicos aislados de Loreto se detect
parte de la problemtica a la que se enfrenta el sistema, o sistemas, de informacin actual.
Explicaremos con detalle, ms adelante, cmo se estructuran los sistemas de informacin, pe-
ro para ayudar a la compresin de los resultados de la identificacin explicamos brevemente en
este apartado el flujo que sigue la informacin.
Los informes se envan desde los puestos de salud a sus centros de salud de referencia. De
cada centro de salud cabecera de microrred (donde ya se han consolidado los datos de todos sus
puestos de salud asociados), se envan a la DIRESA correspondiente (nivel departamental) y de
ah, a la DGE (nivel nacional). Estos informes se elaboran de manera semanal y el martes de
cada semana se han de enviar los informes de la semana anterior. La DIRESA de Loreto elabora
un seguimiento sobre cules son los puestos y centros que no han notificado sus informes en una
semana.
Con respecto a esta forma de trabajar, estas son las impresiones recogidas en el informe
[Gar10] resultante de la identificacin:
Puestos de Salud: Debido a la escasez de personal con el que cuentan para la atencin de
los pacientes, no se ve con muy buenos ojos tener que realizar un desplazamiento semanal
para el envo de los informes de epidemiologa y mensual para el informe de produccin
del puesto. Adems, la escasa formacin clnica, y posiblemente dejadez, conlleva a que
muchos informes no contengan informacin real.
Centros de Salud: Su opinin es que los informes epidemiolgicos y de produccin prove-

nientes de los puestos de salud, vienen en varias ocasiones falseados con intencin, con la
finalidad de obtener ms recursos por parte de la DIRESA, ya que la informacin que con-
tienen no es clnicamente sostenible. Adems creen que desde la DIRESA y DIREMID se
hace caso omiso de los informes que se les envan y que no actan en consecuencia.
Hospital Regional de Loreto: Da la sensacin de que, an siendo cabeza de la red de salud

de Loreto, vive desvinculada de la situacin real que atraviesan las diferentes microredes
que tiene asociadas (aunque tambin es cierto que para el proyecto de tele-estetoscopia
se recibi mucho compromiso y apoyo por parte del hospital). Se reciben quejas de que
la informacin que les llega por parte de los centros de salud, de los pacientes que le son
referidos, es insuficiente.
31
DIRESA: Segn su opinin, solo un 70 % de los datos que provienen de los diferentes
establecimientos de salud son congruentes (en muchos casos hay campos sin rellenar y en
otros sus valores son imposibles), por lo que no se puede extraer informacin fiable de los
mismos.
En un enfoque ms tcnico los resultados de la identificacin destacan que:
Ningn puesto de salud utiliza un software para gestionar la informacin clnica y admi-
nistrativa que maneja. Esto conlleva, aparte de los desplazamientos vistos en el apartado
anterior, que toda la informacin que haya que tratar en el punto de digitacin de los cen-
tros de salud sea verdaderamente inmensa. A modo de ejemplo comentar que en Mazn
hemos visto a un tcnico teniendo que digitalizar lo que seran ms de 600 folios de in-
formes recibidos por parte de los puestos de salud. Una persona dedicndose una buena
parte de su jornada laboral a esta labor, puede tardar de 15 a 20 das al mes en llevar a
cabo dicho trabajo.
El software del MINSA no tiene en cuenta las diferentes capacidades de los usuarios
que hacen uso del mismo. Evidentemente la diferencia en los conocimientos es suficiente
como para justificar el uso de una herramienta personalizable al tipo de usuario (tcnico,
enfermero/a, mdico, etc.) que acceda a la aplicacin, y que de esta forma se puedan
minimizar errores introduciendo datos incorrectos.
La informacin no est centralizada. Todo el software que se maneja est pensado para
facilitar el manejo de los datos estadsticos por parte de la DIRESA. As hay un software
para produccin, epidemiologa, medicamentos, etc. El problema de ello radica en que
se puede duplicar la informacin de manera innecesaria, producirse incongruencias y au-
mentar el tiempo que se le dedica a un trabajo puramente de gestin. Adems se obliga
al usuario a tener que rellenar los datos fuera del horario de atencin de los pacientes al
desvincularse completamente stos de la historia clnica de los pacientes.
Se concluye el informe trazando las lneas generales que se deberan seguir en la bsqueda de
una solucin adecuada para la gestin de informacin:
1. Deber ser una aplicacin Web o distribuida.
2. Debe implementar un sistema de referencia/contrarreferencia de pacientes y que introduz-

ca la historia clnica del paciente (anamnesis, examen fsico, exmenes auxiliares, diag-
nstico, tratamiento) de manera automtica en l.
3. Los datos de la historia clnica debe minimizar, en la medida de lo posible, la introduccin

de texto libre en los formularios. En todo caso el tiempo de insercin de la informacin
clnica no debera ser mayor al minuto.
4. La informacin que se muestre por pantalla deber estar personalizada dependiendo del
tipo de usuario que acceda a la misma (ej: CIE10)
32
5. La interfaz de las pantallas debern definirse con la ayuda del personal clnico, mediante
la declaracin de arquetipos y plantillas.
6. Debe desarrollarse una plataforma que permita introducir a futuro nuevas caractersticas
o plantillas en las historias clnicas.
7. Debe extraer de manera automtica el informe de produccin en dbf de todos los pacientes
atendidos en el ltimo mes.
Partiendo de estas premisas, y siguindolas como lneas generales, nace este proyecto fin de
mster.
33
3. Objetivo
El actual sistema de informacin de salud de la Regin Loreto, que por otro lado es el mismo
que se utiliza en todo Per, comprende un gran nmero de formularios relacionados con la vigi-
lancia epidemiolgica, otros relacionados con el control de actividades del personal de atencin
y unos cuantos ms relacionados con la cobertura del seguro integral para zonas de extrema po-
breza. El personal de atencin de los puestos de salud rurales dedica una parte importante de su
tiempo a rellenar manualmente la informacin que solicitan desde niveles jerrquicos superio-
res, sabiendo que van a tener que rellenar la misma informacin en diferentes formularios, y que
nunca les va a llegar realimentacin de la informacin enviada. Adems van a tener que viajar,
dejando desatendido el establecimiento para entregar a tiempo dichos formularios.
A su vez, los niveles jerrquicos superiores van a tener que digitalizar toda la informacin que
llega desde los puestos de salud sabiendo que en muchos casos la informacin no llega, otras
veces llega tarde y en la mayora de los casos llega escrita con errores.
Todo esto hace que, an con el gran esfuerzo realizado en horas de trabajo dedicadas y coste
de los viajes, el sistema de informacin de salud en Loreto (donde las distancias entre los esta-
blecimientos son especialmente grandes) no resulte til para prevenir y mejorar la atencin de
salud ya que en muchos casos contiene informacin incompleta o errnea y adems est dispo-
nible con mucho retraso.
Todo esto justifica trabajar para mejorar el sistema de informacin de salud en Loreto, identi-
ficando un sistema adecuado para la recopilacin, procesado, envo y visualizacin de informa-
cin.
Tras una primera revisin de las plataformas de informacin de salud ms utilizadas en pa-
ses en desarrollo, la Fundacin EHAS contact con el grupo HISP, con la intencin de conocer
en profundidad la herramienta DHIS2. A priori pareca una herramienta potente y estable que
se presenta como una potencial solucin al tratamiento de informacin en Loreto, pero en ese
momento DHIS2 trabaja slo con datos agregados sin considerar informacin de paciente, lo
cual representa un fuerte debilidad, ya que en Loreto, incluso en la informacin epidemiolgica
como se estudiar ms adelante, se recopila informacin personal. En un posterior seminario,
organizado por HISP, y celebrado esta vez en Oslo, se tiene conocimiento de que el grupo de
desarrollo de HISP ha estado trabajando en un mdulo basado en informacin de paciente, y que
se encuentra ya en marcha en implementaciones de DHIS2 en India. Nace entonces la idea de
estudiar la capacidad de este software para manejar la informacin que fluye entre los puestos y
centros de salud de Loreto.
34
Por esta razn, definimos el objetivo de este proyecto fin de mster como el estudio de la via-
bilidad tcnica e institucional de la implantacin de un sistema de informacin de salud basado
en DHIS2 para el registro, el envo, el procesado y la visualizacin en tiempo real de la informa-
cin epidemiolgica, del registro diario de atenciones y del sistema de cobertura de atenciones
a travs del seguro integral de salud en los establecimientos rurales del Departamento de Loreto
en Per.
35
Parte II.
Metodologa
4. Materiales y Mtodos
4.1. Obtencin de informacin
La obtencin de la informacin necesaria para la elaboracin de este proyecto fin de mster
provendr de:
Documentacin institucional oficial peruana: De donde se espera obtener gran parte

de la informacin necesaria para caracterizar el sistema sanitario nacional y regional (Lo-
reto), poder conocer la realidad socio-cultural del pas, y analizar las necesidades de los
sistemas de informacin del pas. Para ello se procesar documentacin del Ministerio de
Salud, de la Direccin Regional de Salud de Loreto, del Instituto Nacional de Estadstica
e Informtica y de la Direccin General de Epidemiologa.
Informes de estudios de la Fundacin EHAS: Los numerosos documentos de la Fun-

dacin EHAS, resultado de su extenso trabajo en el contexto de las microrredes de salud
situadas en la cuenca del ro Napo, servirn para conocer en profundidad las tecnologas
utilizadas para la implementacin de la red de comunicaciones y su situacin en lo refe-
rente al tratamiento y procesado de informacin.
Documentacin institucional internacional: Para la definicin de la situacin actual en

trminos de salud y desarrollo de Per, y el estado de los Objetivos de Desarrollo del Mile-
nio se emplearn informes del Programa de Naciones Unidas para el Desarrollo (PNUD).
Publicaciones del Grupo HISP: A travs del estudio de publicaciones que reflejan su
historia, diversos casos de estudio, anlisis de xitos y fracasos, as como documentacin
de uso de DHIS2 y recomendaciones de implantacin, se espera obtener un conocimiento
de la trayectoria del grupo, de la historia de evolucin de la herramienta, y de la capacidad
funcional de su versin ms actual.
Entrevistas con personal de la Universidad de Oslo: Se cuenta con el apoyo del perso-
nal tcnico del grupo HISP para el diseo de un modelo piloto que integre la herramienta
DHIS2 con el caso de estudio, esperando as sacar el mximo partido a sus caractersticas
funcionales para modelar una implementacin piloto del sistema de informacin de salud
para Per.
Workshop sobre el mdulo de informacin de paciente: Asistencia a un workshop

interno en que se introduce a la totalidad del grupo HISP las posibilidades y modo de uso
del nuevo mdulo de informacin de pacientes de la herramienta.
36
4.2. Estudio del Sistema de Informacin de Salud
4.2.1. Anlisis del flujo de Informacin
Para el estudio de necesidades se pretende extraer de los documentos oficiales y los docu-
mentos escritos de la Fundacin EHAS, la informacin referida al ciclo de vida de los datos en
el sistema, los actores que interactan con el mismo, as como sus limitaciones, bien sean de
carcter tcnico, administrativo o humano.
La gran cantidad de informacin generada en los puestos y centros de salud puede ser dividida
en tres grandes grupos, informacin epidemiolgica, informacin de produccin e informacin
clnica. Se pretende obtener una identificacin y anlisis de la entrada de datos sistemtica ge-
nerada por estos tres grupos, el flujo y transformacin de los datos durante su evolucin en el
sistema, as como sus modos de almacenamiento y finalmente la generacin y difusin de infor-
macin.
El anlisis constar de:
Identificacin de flujos de Informacin: Qu informacin debe ser enviada o recibida en

cada tipo de establecimiento, periodicidad y formato de envo.
Anlisis y procesado de informacin: Tratamiento que recibe la informacin en los dife-

rentes niveles de jerarqua para ser enviada o presentada a un nivel diferente, o para su
almacenamiento en el sistema.
Se espera poder identificar en este estudio todos los procesos en los que se introducen datos,
las etapas o estados por los que stos pasan y los anlisis o transformaciones que sufren desde
que entran al sistema hasta que son presentados como informacin y/o son almacenados como
histricos. En general, el objetivo de esta primera fase es poder definir los flujos de informacin,
desde las fuentes hasta el destino final, sus fases o etapas.
Una vez definido el flujo de la informacin, se analizar el Informe sobre la Identificacin
de un Sistema de Informacin de Salud (SIS) en los Establecimientos Mdicos Aislados de la
Regin de Loreto (Per) [Gar10] con el fin de poder obtener los requisitos del SW necesario.
4.2.2. Estudio en Profundidad de la Herramienta DHIS2

Es necesario entender la filosofa sobre la que se crea la herramienta DHIS2, conocer los con-
ceptos bsicos para el trabajo con ella y profundizar en sus capacidades funcionales y analticas.
El anlisis de la herramienta se realizar siguiendo la siguiente estructura:
Estudio de las dimensiones existentes en DHIS2 alrededor de las cuales se estructura el

almacenamiento de informacin. Las dimensiones qu, dnde, y cundo.
Estudio Funcional en el cual se recorrern conceptos como los conjuntos de datos, for-
mularios, mtodos de entrada de datos, administracin, trabajo con indicadores, anlisis y
control de calidad, el cuadro de mandos, el mdulo de mensajes, opciones de configura-
cin, y por ltimo se estudiar el mdulo de informacin personal de paciente.
37
Por ltimo se har una revisin de sus caractersticas tcnicas y una especificacin de los
requisitos mnimos para una instalacin completa de la herramienta.
Se espera al final de este apartado tener los conocimientos necesarios para poder plantear una
implementacin de DHIS2 que cumpla con los requisitos detectados en el anlisis del sistema
de informacin peruano.
4.2.3. Adaptacin del SIS estudiado al Contexto

Como etapa final del proyecto, se espera poder realizar una implementacin de DHIS2 para
la regin de Loreto. Este diseo se centrar principalmente en la creacin de la base de datos, la
cual se espera modelar para satisfacer las necesidades del caso de estudio.
Las etapas en que se divide la implementacin de DHIS2 son:
Diseo del Sistema de Informacin, en el que se define la jerarqua de establecimientos, la

configuracin del sistema de informacin geogrfico y la gestin de usuarios. Es el marco
genrico sobre el que se implementarn los subsistemas de informacin estudiados.
Diseo de los subsistemas de informacin mediante la definicin de los elementos de

informacin necesarios, los programas que definen el flujo de la informacin, y los for-
mularios de entrada para la recogida de datos.
Una vez implementado el sistema se har un recorrido por las herramientas de tratamien-
to, anlisis, y presentacin de datos, pertinentes para la satisfaccin de las necesidades
previamente identificadas, como son el clculo de datos agregados desde datos de pacien-
te, la definicin de indicadores, creacin de grficas y mapas, y el diseo del cuadro de
mandos.
Verificacin de cumplimiento de requisitos del sistema. Una vez completada la imple-

mentacin de DHIS2 para el escenario peruano, se har un recorrido por los requisitos del
Sistema de Informacin, en l se analizar la satisfaccin de necesidades y se identificarn
sus posibles carencias.
38
Parte III.
Resultados
5. Identificacin del flujo de Informacin generada en el
Sistema de Salud de Loreto
5.1. El Sistema de Informacin de Salud de Per - Enfoque Global
Es objetivo de este apartado la identificacin y anlisis de la entrada de datos sistemtica, el
flujo y transformacin de los mismos durante su evolucin en el sistema, as como su almacena-
miento y finalmente la generacin y difusin de informacin.
En el caso del Sistema de Informacin de Salud de Per, se cuenta con diversas aplicacio-
nes informticas diseadas para ayudar a la gestin de cada una de las reas en que se divide
el mismo. Se trata, en general, de sistemas aislados e independientes entre s, enmarcados en
una jerarqua de mbito nacional. Las diferentes aplicaciones informticas recopilan y generan
informacin que posteriormente es enviada por distintos medios al nivel superior en la jerarqua.
Segn se indica en la Evaluacin del Sistema de Informacin Rutinaria en Salud de Per

[dSdP09], el informe final sobre necesidades de comunicacin y acceso a informacin realizado
para el Programa de Fortalecimiento de Servicios de la Salud en 1999, defina el Sistema de
Informacin de Salud Peruano de un modo genrico como un sistema basado en bases de datos
locales, pequeas, desarticuladas y con tecnologa obsoleta, muchas aplicaciones, en ocasiones
duplicadas, y de alcance limitado. La generacin de informacin se define como tarda, de poca
calidad, y obtenida a partir de operaciones principalmente manuales.
Como veremos a continuacin, pese a los esfuerzos realizados posteriormente por el Mi-
nisterio de Salud de Per, su sistema de informacin de salud sigue cumpliendo, desde una
perspectiva global, algunas de estas caractersticas.
5.1.1. Los subsistemas que integran el SIS de Per

Los diferentes Sistemas Informticos de recogida de informacin que se integran de modo
independiente en el SIS, segn la Evaluacin del Sistema de Informacin Rutinaria en Salud de
Per son:
Sistema de registro de las atenciones ambulatorias

Sistema desarrollado por el Ministerio de Salud, aprobado en la Resolucin Ministerial
No 0073-93-SA/DM - Sistema de Informacin HIS. Su misin es la de recopilar da-
tos a nivel nacional de las consultas externas y los programas y actividades preventivo-
promocionales.
39
Se debe encontrar en todos los establecimientos de salud desde los Institutos especializa-
dos hasta los puestos de salud.
Registro de hospitalizaciones y emergencias
Sistema nacional creado por la Oficina de Estadstica del MINSA. Proporciona informa-
cin de ingresos, egresos, morbilidad hospitalaria, y de servicio y estancia. Se encuentra
slo en los establecimientos de salud pblicos que tienen servicios de hospitalizacin co-
mo son los Hospitales Nacionales, Regionales, y de Apoyo y algunos Centros de Salud
con hospitalizacin.
Sistema de planillas del Ministerio de Salud
Sistema generado por la Oficina de Personal del MINSA y elaborado en la Oficina General
de Estadstica e Informtica, es usado en las unidades ejecutoras dependientes del Sector
Pblico (MINSA y Regiones) cuenta con un aplicativo con el que se capturan los datos
del personal activo y cesante, y, desde septiembre del 2008-2009, del personal contratado.
Sistema Integrado de Suministro de Medicamentos e Insumos Mdico-Quirrgico -
SISMED
En 2002 se aprueba la Directiva del Sistema Integrado de Suministros de Medicamentos
e Insumos mdico-quirrgico: SISMED mediante Resolucin Ministerial No 1753-2002-
SA/DM. En la cual se especifica que la Oficina General de Estadstica e Informtica di-
sear, desarrollar e implementar el sistema informtico. El resultado fue una primera
versin en 2003 (SISMED V1.3), para el registro de los consumos y stocks consolidados
bimensuales de los medicamentos e insumos a nivel nacional. Y una segunda en 2005
(SISMED V2.0), que permite adems gestionar la informacin detallada desde el nivel
operativo de la cadena de suministro y monitorizar la distribucin y consumo en los Alma-
cenes Especializados de las DIREMIDs, subalmacenes y farmacias de Establecimientos
de Salud que cuenten con PC.
Sistema de Informacin Perinatal
En Enero del ao 2001, teniendo en consideracin que la atencin de la madre y el recin
nacido constituye una prioridad del Sector Salud, se consider necesario ampliar la capa-
cidad de obtencin de datos y generacin de informacin tiles para optimizar la atencin
de la madre y el nio; para ello la Historia Clnica es la fuente esencial de datos, y el Apli-
cativo Analtico el instrumento de procesamiento de los mismos. Se aprob la Historia
Clnica Materno Perinatal y su Aplicativo Analtico de Indicadores de Produccin y Ca-
lidad de Servicios Materno Perinatales (SIP 2000), siendo de uso obligatorio en todos los
establecimientos de las Direcciones Regionales de Salud, Direcciones Subregionales de
Salud, as como en el Instituto Materno Perinatal.Este Sistema es utilizado actualmente en
el 50 % de Hospitales del pas y cerca del 30 % de los centros de salud, pero no es aprove-
chado en su totalidad por el bajo nmero de ordenadores que hay en los establecimientos
de salud.
Sistema de Informacin del Seguro Integral de Salud
Existen aplicaciones informticas para la gestin de informacin relativa al Seguro Inte-
gral de Salud. Esto viene documentado en la Directiva No 004-2008/SIS-J, que regula el
40
uso de las aplicaciones informticas de registro de formatos del seguro integral de salud y
en la Directiva No 002-2011/SIS-GO, que regula los procesos de validacin prestacional
del seguro integral de salud. Las aplicaciones son:
SIASIS: aplicacin web para usuarios con acceso a Internet que da soporte a los
procesos de afiliacin, atencin, supervisin, transferencia de pagos a unidades eje-
cutoras, informacin para la gestin y soporte para el proceso de quejas y reclamos.
SESE-SIS: aplicacin de escritorio para usuarios sin acceso a Internet, que permite
el registro y categorizacin de los formatos de evaluacin socio-econmica (FESE).
ARFSIS: aplicacin de escritorio que permite el registro de formatos de inscripcin
y afiliacin de los asegurados del componente subsidiado y de los formatos de aten-
cin para todos los asegurados del SIS. Los datos de ARFSIS se ingresan en los
Hospitales y en las DIRESAs para el reembolso de las prestaciones a los pacientes
pobres y extremadamente pobres que son beneficiarios del SIS.
El sistema de referencia y contra-referencia
Se trata de un sistema ligado al Seguro Integral de Salud, ya que vincula la historia clnica
del paciente con el nmero de afiliacin al SIS. Se utiliza para la transmisin de informa-
cin de pacientes con aviso previo con el fin de asegurar su traslado y la correcta recepcin
de la informacin en el servicio de salud destino, as como la vuelta de la informacin per-
tinente al establecimiento de origen mediante el documento de contra-referencia. La trans-
misin de informacin se realiza entre todos los establecimientos de salud del MINSA y
entre algunos de establecimientos de EsSalud en los que est implementado.
Sistema de Vigilancia Epidemiolgica

La Direccin General de Epidemiologa (DGE), con el fin de procesar, analizar, monito-
rizar y difundir los datos, defini un Sistema de Vigilancia Epidemiolgica y dise una
aplicacin que cubre todo el proceso con el fin de contribuir a mejorar la vigilancia de las
patologas y enfermedades contagiosas ms frecuentes y peligrosas.
La herramienta desarrollada se llama NOTI versin 3.1, aunque es ms conocido como
NOTI 99. Se trata de un software construido para la gestin de los datos recolectados
a travs de las fichas de notificacin de las enfermedades o eventos sujetos a vigilancia
epidemiolgica. Desde su primera versin se ha ido adaptando para cubrir las nuevas ne-
cesidades como la ficha de investigacin epidemiolgica de muerte materna.
En caso de disponer de conexin a internet existe tambin una opcin de notificacin va
web que permite la notificacin inmediata de casos mediante una opcin del Noti.
Por otro lado se encuentran las fichas de investigacin, que deben ser rellenadas para de-
terminados posibles diagnsticos y son especficas de cada uno de ellos. Se han ido aa-
diendo en diferentes mdulos o actualizaciones al desarrollo principal de la aplicacin.
Registro de Nacimientos e Informe Estadstico del Nacido Vivo

Cada vez que se produce un nacimiento se debe inscribir en el registro, bien de forma or-
dinaria (dentro del plazo legal) o extraordinaria. Existen fichas de registro de los nacidos
vivos, que constan de tres rubros, uno para la Oficina del Registro Civil, otro con la huella
de identificacin, y otro para ser anotada por el declarante su relacin con el recin nacido.
41
Tambin se debe rellenar un informe estadstico del nacido vivo el cual consta de cinco
grupos de datos: Datos del nacido vivo, datos del parto, datos de la madre, datos de la
persona que atendi el parto, y datos de la inscripcin en el registro civil.
Se desconoce la existencia de una aplicacin informtica para la recogida de la informa-
cin especificada anteriormente.
Registro de Muerte e Informe Estadstico de Defuncin

Igual que en los nacimientos, es necesario reportar los fallecimientos en el registro civil.
Hay tres modalidades de inscripcin de una defuncin:
1. Inscripcin ordinaria: cuando la inscripcin se realiza dentro de las 48 horas de ocu-
rrido el fallecimiento.
2. Inscripcin por parte policial: cuando la inscripcin se realiza en virtud de la certifi-
cacin de la defuncin por la autoridad policial, en caso de muerte por accidente.
3. Inscripcin judicial: cuando la inscripcin se realiza por orden del Juez Penal en
caso de muerte violenta o sospechosa, certificada por el mdico legista. Para ello, no
se determina plazo.
Las inscripciones se realizan rellenando el formulario correspondiente, dependiendo de si
se trata de una defuncin fetal o no, y deben ir acompaadas de un informe estadstico de
defuncin tambin definido diferenciando la defuncin fetal. Se desconoce la existencia
de un software especifico para la recogida de esta informacin.
Enfoque del estudio
Como vemos en el anterior anlisis, el Sistema de Informacin de Salud de Per se divide

en 9 reas o entornos claramente definidos y diferenciados unos de otros. La mayora de ellos
dispone de una aplicacin informtica de ayuda a la recogida e integracin de datos, y en ningn
caso se potencia la posibilidad de compartir informacin entre ellos.
Un sistema de informacin que integrase la mayor parte de la informacin citada anterior-

mente garantizara un flujo completo y coherente de la misma, evitara redundancias sobre todo
en informacin personal de paciente, repetida en la mayora de los sistemas existentes, y hara
mucho ms accesible el seguimiento clnico de una determinada persona en las diferentes reas
que contempla el sistema de salud nacional.
La calidad de la informacin generada, y las posibilidades de hacer estudios estadsticos tam-

bin seran mayores y ms flexibles en el marco de un sistema global. En estos casos, sera
posible cruzar informacin de diferentes reas, y los indicadores y series se calcularan a partir
de la agregacin de registros individuales, pudiendo ser recalculados tantas veces sea necesario
y con diferentes parmetros en funcin de los requisitos del estudio para el cual se generen.
42
No obstante, queda fuera del alcance de este proyecto proponer una solucin que englobe
la totalidad de la informacin que genera el Sistema de Salud Nacional de Per, siendo priori-
tario el subsistema que componen los establecimientos mdicos aislados de la Regin de Loreto.
Se centra a partir de ahora el anlisis de flujos de informacin en los dos sistemas que registran
informacin relativa a pacientes y la envan hacia el nivel superior formando parte del flujo de
informacin de salud a nivel nacional, estos son el Sistema de Registro de Atenciones Obligato-
rias y el Sistema de Vigilancia Epidemiolgica. El objetivo es el de unificar sistemas, eliminar
redundancias y minimizar los recursos requeridos preparando el sistema para una implementa-
cin de todos los subsistemas cuyo ncleo de informacin sea un almacn de datos compartido.
Queda fuera del anlisis el sistema de gestin de medicamentos, por tratarse de un rea de la
que no se tiene apenas informacin. Por otro lado, el solapamiento de informacin de este siste-
ma con los otros dos mencionados es mnimo, lo cual permite un anlisis e integracin posterior
sin comprometer la obtencin de un buen resultado.
5.2. Sistema de Informacin Clnica

El Sistema de Informacin en Salud HIS (en el idioma original, Health Information Sys-
tem) es una herramienta indispensable que garantiza el adecuado registro de las actividades de
salud, contribuyendo a mejorar la calidad del registro de datos, homogeneizando criterios, in-
corporando nuevas formas de registro y consolidndolo como nica fuente de informacin, con
el propsito de instrumentalizar el soporte para la toma de decisiones. [dSdP07b]
Es un sistema de cobertura nacional, dado que lo desarrolla el Ministerio de Salud (Resolu-

cin Ministerial No 0073-93-SA/DM). Se debe encontrar en todos los establecimientos de salud
desde el nivel ms bajo al ms alto de la jerarqua de establecimientos de salud. En l se recoge
informacin de consultas externas y de los programas y actividades preventivo-promocionales a
nivel nacional.
5.2.1. El Registro Diario de Atencin y Otras Actividades

Es un formulario a travs del cual se recoge la informacin de las atenciones diarias en con-
sultas externas o de otras actividades llevadas a cabo desde el establecimiento de salud. Se debe
rellenar en todos los centros diariamente y se deben reportar todas las atenciones y actividades
del da.
Por atenciones se refiere a las consultas realizadas por el mdico o tcnico de salud a los
pacientes, las actividades pueden ser actividades preventivo promocionales, cuyo fin es el de
educar a la poblacin mediante la transmisin de medidas de prevencin de enfermedades a ni-
vel de comunidad, o actividades masivas de salud que se enmarcan en estrategias sanitarias que
se llevan a cabo para toda la poblacin, o un determinado grupo, como puedan ser inmunizacio-
43
nes o actividades de salud bucal.
El diseo del formulario Registro Diario de Atencin y Otras Actividades presenta una dis-
tribucin por casillas; en cada formulario se completan una serie de datos generales comunes a
todo el documento y una serie de registros con datos especficos correspondientes a cada aten-
cin y/o actividad de salud realizada.
Datos Generales
El aspecto de los datos generales almacenados en el Registro Diario es el siguiente:
Figura 9: Datos Generales del Registro Diario
A continuacin se explica el contenido de cada campo, de datos generales del formulario:
Turno - Maana o tarde.
Fecha - Mes y ao.
Ubicacin Geogrfica (Ubigeo) - Identificacin nica del Establecimiento de Salud.
Servicio - Ambiente fsico equipado y con el personal de salud correspondiente, en el que

se realiza la atencin o actividad. Existe un listado de servicios del HIS codificados, este
cdigo lo aadir el estadstico en la zona sombreada. (Nota sobre cules son los servicios
en PS y en CS)
Responsable de la atencin o actividad - Nombre, apellido y cdigo del mismo. El cdigo

se establece segn una nomenclatura compuesta establecida por el MINSA, debe ser nico
para cada profesional de salud.
Datos Especficos
Los datos especficos son los relativos a cada atencin y/o actividad de salud. Se codifican en
funcin de cada paciente, si se trata de una atencin, o del grupo de pacientes, en el caso de las
actividades preventivo-promocionales. El cuadro mostrado a continuacin se repite a lo largo
del formulario, recopilando en cada uno la informacin relativa a una atencin o actividad.
44
Figura 10: Datos Especficos del Registro Diario
La codificacin de los datos especficos depende de si se trata de una atencin sanitaria o de

una actividad preventivo promocional. Se detallan a continuacin las guas a seguir para rellenar
el informe en cada actividad o atencin:
Da de la Atencin - Nmero de da del mes.
Nmero de Historia Clnica o de Ficha Familiar

Atencin - se escribir el nmero de historia clnica que identifique al paciente.
Actividad - se escribir el cdigo correspondiente a la misma segn los cdigos esta-
blecidos.
Procedencia del Paciente

Atencin - se anotar el distrito del domicilio actual del paciente.
Actividad - se escribir el distrito donde est ubicada la institucin o grupo humano
donde se realiza la actividad.
Edad
Atencin - se anotar la edad cumplida del paciente, seguido de un indicador del tipo
de edad (das (D), meses (M) o aos (A)).
Actividad - si la actividad va dirigida a un determinado grupo de edad se anotar en
esta casilla, en caso contrario se dejar en blanco trazando una lnea oblicua sobre ella.
Sexo
Atencin - marcar una X en la casilla correspondiente.
Actividad - dejar en blanco y trazar una lnea oblicua sobre la casilla.
tems de condicin de ingreso al establecimiento

Atencin - marcar con una cruz la casilla correspondiente en funcin de si el paciente
es Nuevo, Continuador o Reingreso en el establecimiento 8 .
8
Nuevo: Paciente nuevo en el establecimiento.
Continuador: Paciente que ya ha acudido al establecimiento durante el ao en curso.
Reingreso: Paciente que ya ha acudido al establecimiento en aos anteriores, pero es la primera vez que acude
durante el ao en curso.
45
tems de condicin de ingreso al servicio
Atencin - marcar con una cruz la casilla correspondiente en funcin de si el paciente
es Nuevo, Continuador o Reingreso en el servicio.
Diagnstico, Motivo de la Consulta y/o Actividad de Salud
Atencin - Se debe anotar el diagnstico de morbilidad o estado de salud de la perso-
na, la condicin de riesgo, posibles daos externos y su causa. Se pueden anotar hasta seis
por atencin.
Actividad - se anotar en primer lugar la actividad realizada y en segundo la estrategia
sanitaria por la cual se realiza.
Tipo de Diagnstico
Atencin - se seleccionar con una cruz la opcin correcta segn si el diagnstico es
presuntivo (P), definitivo (D) o repetidor (R).
Actividad - se marcar siempre D.
Laboratorio (Lab) - Se rellenar siguiendo una codificacin previamente establecida en
funcin del tipo de atencin o actividad. Tiene varios usos de acuerdo a las distintas acti-
vidades de salud, como pueda ser el nmero de dosis de vacunas, controles de tratamiento
en gestantes o nios, nmero de sesiones en actividades profilcticas o nmero de partici-
pantes en actividades de capacitacin.
Cdigo(CIE 10) - Se debe anotar el cdigo CIE 10 correspondiente a la morbilidad o
actividad de salud brindada e indicada en el campo Diagnstico, motivo de consulta y/o
actividad.
5.2.2. Recopilacin de Informacin y Flujo de datos

La recopilacin de informacin se hace a travs del formulario en papel. Los profesionales
de salud registran en l cada atencin realizada en el mismo momento que se realiza la atencin
utilizando un formulario por cada turno en que se preste servicio cada da. Cada establecimiento
recopila sus informes y luego los hace llegar al punto de digitacin, donde los datos se introdu-
cen en el sistema a travs de la aplicacin informtica que tiene el mismo nombre, HIS. Una vez
introducidos se deben realizar los diferentes anlisis estadsticos que generen los reportes, que
deben ser entregados a los niveles inferiores que han entregado los datos (cosa que raramente
ocurre). Posteriormente los datos van al nivel regional, y de ah al nacional, siguiendo el orden
jerrquico de los establecimientos. La informacin puede ser analizada en cualquiera de los ni-
veles en los que hay un ordenador para capturar datos.
El sistema produce una serie de indicadores que ayudan a medir la produccin del estableci-
miento y da un seguimiento al estado de la salud en la zona [dSdP09].
Estos indicadores son:
46
Nmero de Atendidos
Nmero de Atenciones
Morbilidad por categoras
Morbilidad por captulos de CIE X
Atenciones por Servicios
Atenciones por profesional
El aspecto del formulario completo es el siguiente:
Figura 11: Formulario del Registro Diario de Atencin y Otras Actividades
El proceso de recogida de datos
A continuacin se describen de forma genrica las etapas del proceso de recogida de datos,
ms adelante se har un anlisis ms detallado de lo que suponen la primera y segunda etapa en
los centros y puestos.
47
Primera fase: Durante la primera fase, llevada a cabo en los establecimientos, el personal
de salud registra la actividad, rellena el formulario y codifica el diagnstico en CIE-10.
Segunda fase: Durante la segunda fase, llamada fase de procesamiento de datos, y que
se lleva a cabo en la oficina de estadstica o punto de digitacin, se realiza una revisin
crtica de los datos para posteriormente introducirlos en el sistema. Sobre los datos se
realiza un control de calidad, basado en un control en la codificacin de los diagnsticos,
informacin de registro discordante, y la correspondencia entre el HIS y la Historia Clnica
del paciente, para posteriormente enviar los datos al nivel superior y generar los reportes
de informacin.
Tercera fase: La tercera fase se conoce como etapa de Anlisis y Difusin. En ella se ana-
liza toda la informacin recibida a nivel regional o nacional, se generan las publicaciones
estadsticas y se toman las decisiones pertinentes.
El proceso de recogida de datos en el puesto de salud y centro de salud
Segn el Anexo 2 [dSdP07a] del documento Manual General de Registro y codificacin de

Diagnsticos de Consulta Externa y Otras Actividades de Salud 2007 que representa el flujo-
grama del Sistema de Informacin, el proceso de recogida de informacin y envo de formularios
hacia el nivel superior sigue el flujo mostrado en la imagen siguiente.
Figura 12: Flujo de Informacin del Registro Diario de Atencin
48
En l se representa que los puestos rellenan los formularios HIS diariamente y los remiten
semanalmente a la oficina de estadstica de su centro de salud de referencia. Los centros por su
parte hacen lo mismo, pero adems van recopilando los informes de los puestos de su micro red.
En la oficina de estadstica o punto de digitacin se realizan los controles de calidad y mensual-
mente se procede al envo de la informacin al nivel superior y de los reportes bsicos al nivel
inferior.
5.2.3. El Software del HIS

La informacin de que disponemos sobre esta aplicacin informtica es la recogida en el in-
forme de identificacin de un Sistema de Informacin de Salud en los Establecimientos Mdicos
Aislados de la Regin de Loreto (Per) [Gar10], que la describe como una aplicacin desarrolla-
da en Clipper, lenguaje procedural muy utilizado en los 80 y principios de los 90 para la gestin
de bases de datos bajo el sistema operativo MS-DOS. Aunque funciona (exclusivamente) sobre
Windows, toda la interfaz grfica con el usuario se reduce a la lnea de comandos. Genera archi-
vos de base de datos DBF en los que se guarda diferente informacin de los pacientes que son
atendidos por el establecimiento. Al tratarse de una aplicacin que no funciona en red, los ar-
chivos DBF han de ser enviados mediante el uso del correo electrnico o algn dispositivo fsico.
5.3. Sistema de Vigilancia Epidemiolgica

El objetivo del sistema de vigilancia epidemiolgica nacional es el de garantizar la calidad y
continuidad del proceso de recogida, anlisis e interpretacin de datos de una serie de enferme-
dades sujetas a vigilancia. Este proceso permite conocer la tendencia y evolucin en el tiempo
de las mismas, cules son las regiones o grupos poblacionales ms afectados y el estado de salud
del pas de una forma genrica.
Este seguimiento permite evaluar, en un perodo de tiempo razonable, los resultados de las
medidas de prevencin y control aplicadas desde el sector salud, as como identificar a corto
plazo los brotes o epidemias, permitiendo el desarrollo de campaas de intervencin y control a
tiempo.
La correcta recoleccin de informacin en cuanto a calidad y tiempo es crucial para garanti-

zar el buen funcionamiento del sistema de vigilancia. Es tarea de un Sistema de Informacin el
proporcionar las herramientas necesarias para que la recogida de datos sea sencilla, accesible y
robusta, de modo que se garantice el correcto tratamiento de los datos durante todo el proceso.
5.3.1. Etapas de la vigilancia epidemiolgica

El flujo de la informacin de las enfermedades sujetas a vigilancia epidemiolgica, desde que
se recoge hasta que es analizada, se puede dividir en tres etapas principales:
49
1. Notificacin: Es la etapa en que la informacin es introducida en el sistema y agrupada
en los distintos niveles para su correcta difusin hasta el nivel superior de la jerarqua, la
Direccin General de Estadstica (DGE) 9 , donde se recopilan los datos a nivel nacional.
2. Anlisis e interpretacin: Es la etapa en que se procesa toda la informacin recibida de

las unidades notificantes. Cada martes a las 14:00 horas se realiza el procesado de la in-
formacin de la semana epidemiolgica anterior. Este procesado consta de un control de
calidad de los datos en que se hace revisin de registros en blanco, verificacin de semanas
epidemiolgicas notificadas, verificacin de diagnsticos notificados, bsqueda de regis-
tros duplicados, verificacin de fechas y aos, verificacin de inconsistencias en registros,
verificacin de tiempo promedio de notificacin, verificacin de cdigos ubigeo, y control
de duplicados. Posteriormente se extraen los grficos y tablas por grupos temticos. En
los casos en que la enfermedad sea de notificacin mensual o bimensualmente, se realiza
el mismo proceso de anlisis descrito anteriormente.
3. Retroalimentacin: A partir de la informacin obtenida en la etapa de anlisis e interpre-

tacin, la DGE edita publicaciones10 que son difundidas entre las Direcciones de Salud,
Redes, Cabeceras de Red, con el fin de que la informacin llegue a todos los niveles infe-
riores de la jerarqua y se retroalimente el sistema de vigilancia epidemiolgica.
5.3.2. La informacin y flujos de comunicacin en la etapa de Notificacin

Se entiende por Notificacin la comunicacin oficial de la deteccin o captacin por el nivel
local (unidades notificantes) de un caso sospechoso, probable o confirmado de una enferme-
dad o evento sujeto a vigilancia epidemiolgica hasta la Direccin General de Epidemiologa.
[dge12]
El flujo que sigue la informacin en esta fase de notificacin se inicia en cualquiera de los cuatro
niveles y evoluciona en sentido ascendente, agrupndose toda la informacin recopilada en cada
uno de ellos antes de pasar al nivel siguiente en la jerarqua, desde el nivel local hasta el nivel
nacional.
La equivalencia de las etapas reflejadas en el grfico con nuestro caso de estudio es:
Nivel local: corresponde para nosotros con los puestos de salud.
Nivel Intermedio: son las cabeceras de micro red, es decir, los centros de salud.
Nivel Regional o subregional: La Direccin Regional de Salud
Nivel Nacional: La Direccin General de Epidemiologa.
9
La Direccin General de Epidemiologa ( DGE ) es el rgano encargado de asesorar a la Alta Oficina del Minis-
terio de Salud, a las dependencias competentes de los Gobiernos Regionales y dems componentes del Sistema
Nacional Coordinado y Descentralizado de Salud: Sobre la Situacin de Salud del pas y de cada regin, las
condiciones de Salud de las poblaciones, las tendencias de las enfermedades y de la respuesta para su prevencin
y control. Pgina web: http://www.dge.gob.pe/
10
Publicaciones de la DGE: http://www.dge.gob.pe/publicaciones.php
50
Figura 13: Flujo de la Informacin del Sistema de Vigilancia Epidemiolgica
La informacin relativa a enfermedades sujetas a vigilancia epidemiolgica, y que por tanto

debe ser generada en esta primera etapa de notificacin se recoge en dos tipos de informes o
fichas, que a su vez se clasifican segn el tipo de enfermedad o evento. A continuacin se mues-
tra de forma grfica la estructura en que se clasifican los documentos utilizados en la etapa de
notificacin.
Figura 14: Organizacin de los documentos del Sistema de Vigilancia Epidemiolgica
1. Fichas epidemiolgicas de notificacin
Contienen informacin bsica sobre el caso, se utilizan para notificar que se ha encontrado un
caso sospechoso o probable, y tambin para casos, confirmados. Estas fichas se dividen a su vez
en dos tipos, en funcin de si se trata de un evento de notificacin individual o consolidada.
51
Enfermedades o eventos de notificacin individual
La notificacin individual se refiere al registro del paciente que sea un posible caso de una de
las enfermedades bajo vigilancia epidemiolgica, en un listado semanal que almacena todos los
posibles casos. En l se especifica informacin personal del paciente, su posible diagnstico y
tipo, si est vacunado, fechas importantes relacionadas con la enfermedad y si se inicia ficha de
investigacin (se trata de una ficha de informacin clnica para seguimiento de caso que veremos
ms adelante).
En estos casos, las unidades notificantes rellenan la Ficha de Notificacin Epidemiolgica

Individual.
Figura 15: Ficha de Notificacin Individual
A continuacin se detallan las enfermedades o eventos sujetos a vigilancia epidemiolgica

que deben ser notificadas en el registro de notificacin individual.
En la tabla se encuentra, en la primera y segunda columna, el diagnstico y su correspondiente

cdigo CIE 10, a continuacin el perodo dentro del cual se debe informar de su existencia al
nivel superior, y por ltimo si ese determinado diagnstico tiene ficha de investigacin o no (las
fichas de investigacin se vern ms adelante).
Cuadro 3: Enfermedades Sujetas a Vigilancia Epidemiolgica

Diagnstico Cdigo CIE Periodo de Ficha de In-
10 Notificacin vestigacin
Reglamento Sanitario Internacional
Clera A00 Inmediata Si
Peste A20 Inmediata Si
52
Diagnstico Cdigo CIE- Periodo de Ficha de In-
Fiebre Amarilla Selvtica A95.0 Inmediata Si
Enfermedades Inmunoprevenibles
Ttanos neo-natal A33 Inmediata No
Ttanos A35 Inmediata No
Difteria A36 Inmediata No
Tos Ferina A37 Inmediata No
Poliomeritis (Parlisis Flcida Aguda) A80.3 Inmediata No
Sarampin B05 Inmediata Si
Rubola B06 Inmediata Si
Hepatitis B B16 Inmediata No
Enfermedades metaxnicas, arbovirus y otras transmitidas por vectores
Tifus exantemtico A75.0 - No
Bartonelosis Sistmica (aguda) A44.0 Semanal No
Bartonelosis eruptiva A44.1 Semanal No
Dengue Clsico A90 Inmediata Si*
Dengue Hemorrgico A91 Inmediata Si
Leishmaniasis cutnea B55.1 Mensual Si
Leishmaniasis mucocutnea B55.2 Mensual Si
Enfermedad de Chagas B57 Mensual No
Malaria P. falciparum B50 Inmediata Si
Malaria P. Malariae B52 Semanal No
Malaria mixta B501 Semanal No
Enfermedades zoonticas
Antrax (Carbunco) A22 Inmediata Si
Rabia humana urbana A82.1 Inmediata Si
Rabia Humana silvestre A82.0 Inmediata Si
Enfermedades de transmisin sexual
Sndrome de Inmuno Deficiencia Adquirida (SI- B24 Mensual No
DA)
Enfermedades infecciosas congnitas
Sfilis congnita A50 - No
Sndrome de Rubeola Congnita P35.0 Semanal No
Enfermedades infecciosas del sistema nervioso central
Meningitis Tuberculosa A17 - No
Meningitis Meningoccica A39 - Si
Accidentes por animales Ponzoosos
Accidente ofdico X20 Semanal Si
Eventos de importancia en salud pblica
Muerte Materna directa O95 Semanal Si
Muerte Materna indirecta O96 Mensual Si
Muerte Materna incidental 097 Mensual Si
ESAVI T88.1 Inmediata Si
Gestante Vacunada Inadvertidamente GVI Inmediata No
Hijo de Gestante Vacunada Inadvertidamente GVIH Inmediata No
Accidente de Trnsito - - No
53
Diagnstico Cdigo CIE- Periodo de Ficha de In-
Muerte perinatal - - Si
Muerte infantil - - No
Las enfermedades o eventos de Notificacin inmediata deben ser reportadas al nivel nacional
lo antes posible mediante la va ms rpida (telfono, fax, email).
Enfermedades o eventos de notificacin consolidada

Hay una serie de enfermedades de las cuales se recogen datos epidemiolgicos agregados, es
decir, slo se recoge el nmero de casos ocurridos durante la semana, sin almacenar ningn tipo
de informacin personal del paciente.
Las enfermedades sujetas a este tipo de vigilancia se muestran en la siguiente tabla:
Cuadro 4: Enfermedades y Eventos Sujetos a Notificacin Consolidada

Enfermedad / Evento Periodo de Ficha de In-
Notificacin vestigacin
Diarrea Acuosa Aguda
Casos Semanal Si
Hospitalizados Semanal Si
Defunciones Semanal Si
Diarrea disentrica
Casos Semanal Si
Defunciones Semanal Si
Infeccin Respiratoria Aguda
No Neumona
Casos Semanal Si
Neumona No Grave
Casos Semanal Si
Neumona Grave (NG) o Muy Grave (EMG)
Casos Semanal Si
Defunciones por IRAs
Defuncin Intrahospitalaria Semanal Si
Defuncin Extrahospitalaria Semanal Si
Sndrome Obstructivo Bronquial Agudo (SOBA) - ASMA
Casos Semanal Si
Malaria por Plasmodium Vivax
Casos Confirmados Semanal Si
Para estos diagnsticos se rellena la Ficha de Notificacin Epidemiolgica Consolidada con

periodicidad semanal.
54
Figura 16: Ficha de Notificacin Consolidada
2. Fichas epidemiolgicas de investigacin
El objetivo de las fichas clnico-epidemiolgicas de investigacin es el de dar seguimiento

clnico a un caso probable de una enfermedad o evento de notificacin individual para su clasi-
ficacin como confirmado o descartado. En funcin del tipo de diagnstico, adems de realizar
la notificacin inmediata cuando el diagnstico lo requiera va telfono, e-mail o fax, se debe
empezar a rellenar las fichas dentro de las primeras 24 o 48 horas desde que se detecta el caso,
y remitirlas a la Oficina General de Estadstica, a nivel nacional.
Las fichas son especficas para cada diagnstico, generalmente contienen informacin del
establecimiento, informacin especfica del paciente, antecedentes, cuadro clnico, resultados de
laboratorio, evolucin del caso y observaciones, pero esto vara en cada ficha en funcin de la
informacin til para cada caso. A continuacin se listan las Fichas de Investigacin:
Ficha Investigacin Antrax carbunco
Ficha Investigacin Dengue
Ficha Investigacin Fiebre amarilla
Ficha Investigacin Leishmaniasis
55
Ficha Investigacin Malaria
Ficha Investigacin Meningitis meningoccica
Ficha Investigacin Muerte Materna
Ficha Investigacin Ofidismo
Ficha Investigacin Peste
Ficha Investigacin Rabia urbana y silvestre
Ficha Investigacin Sarampin y Rubeola
Ficha Investigacin ESAVI
Ficha Investigacin Mortalidad perinatal
Ficha de Investigacin Clera
5.3.3. El software de Vigilancia Epidemiolgica NOTI SP

Para la gestin de la informacin epidemiolgica existe una aplicacin cuyo uso es de mbito
nacional llamada NotiSP. Se trata de una aplicacin de escritorio que facilita el registro de la in-
formacin, su anlisis, control de calidad y generacin de paquetes para envo, entre otras cosas.
Las funcionalidades de NotiSP se clasifican en cinco grupos que son:
Ingreso de casos: donde se encuentran las interfaces para introduccin de datos en las
diversas modalidades del sistema de vigilancia (individual, consolidada, investigacin).
Anlisis e informes: donde se pueden extraer informes de control de salud, o de ndice de

notificacin.
Mantenimiento/Configuracin: para el mantenimiento de la aplicacin y la configuracin

de algunos de los parmetros que se utilizan al recoger los datos.
Servicios / Procesos: En este grupo se encuentran las funcionalidades relacionadas con la

base datos, controles de calidad, unificacin, generacin, indicadores.
Utilitario: Se encuentran aqu la gestin de usuarios y las tareas de exportacin y compac-

tacin de datos. Los datos se exportan en formato DBF para su envo al nivel superior en
la jerarqua.
Documentos Tcnicos: Referencia a documentos de consulta en los que define el siste-

ma de vigilancia epidemiolgica, o generados por la Direccin General de Salud para el
seguimiento de estado de la salud.
Ayuda: Seccin con informacin til para ayudar al manejo de la herramienta.
56
6. Estudio del Sistema de Informacin de Salud DHIS2
Para una correcta adaptacin de DHIS2 a la red de salud de Loreto y un completo aprove-
chamiento de sus caractersticas es necesario un conocimiento profundo de la herramienta, un
entendimiento de sus fundamentos de diseo y la compresin de todas las posibilidades que
ofrece. Tras un estudio en profundidad de la documentacin disponible en la pgina web de la
herramienta [dhi12], en este captulo se trata de transmitir una imagen completa de la aplicacin
y ayudar a entenderla a nivel conceptual, funcional y de requisitos tcnicos.
En primer lugar se describen las dimensiones utilizadas para identificar los datos de forma
unvoca en la base de datos del sistema. Las dimensiones constituyen y ayudan a entender la
filosofa de diseo de DHIS2.
El segundo apartado hace un recorrido por las funcionalidades ms destacadas de la herra-

mienta e intenta contestar a la pregunta Qu se puede hacer con DHIS2?. Por ltimo se inten-
ta hacer una descripcin de alto nivel de sus caractersticas tcnicas y los requisitos necesarios
para poner en marcha la herramienta.
6.1. Dimensiones de Datos en DHIS2

Todo valor almacenado en DHIS2 est definido en tres dimensiones; como elemento de datos,
perteneciente a una unidad organizativa, y en un periodo temporal.
Cuadro 5: Dimensiones DHIS2

Unidad Org. Elemento de Datos Periodo Valor
Centro de Salud 1 Casos de Malaria Enero 2010 15
Vamos a explicar con detalle en qu consisten cada una de estas dimensiones y cul es su
papel en la lgica del sistema.
6.1.1. La dimensin dnde (Unidades Organizativas)

Unidades Organizativas
Las unidades organizativas pueden ser un establecimiento de salud, desde un puesto a un hos-
pital, o una unidad administrativa que agrupa establecimientos como un distrito determinado o
el mismo ministerio de salud. Las unidades organizativas se estructuran en una jerarqua que
representa el sistema de salud y tienen asignado un nivel organizativo dentro de la jerarqua.
Ejemplos de unidades organizativas podran ser la regin de Loreto, el distrito de Yurimaguas, o
el centro de salud de Santa Clotilde. Las tres, pese a no ser lo mismo en la realidad, en el sistema
seran unidades organizativas.
57
Figura 17: Ejemplo de rbol de jerarqua
La jerarqua de organizaciones
La jerarqua es la estructura interna de unidades organizativas que sigue la implementacin de
DHIS2. Representa la informacin de cmo los establecimientos de salud, las reas administra-
tivas y otras reas geogrficas se organizan, unas respecto a las otras.
DHIS2 est construido considerando que la jerarqua de unidades organizativas es una jerar-
qua geogrfica, y el mdulo de Sistema de Informacin Geogrfica (SIG) depender de ella. No
se recomienda, por tanto, el uso de jerarquas no geogrficas. Veremos ms adelante que estas
pueden ser representadas mediante los grupos de unidades organizativas.
Esta dimensin de datos se define como una jerarqua con un nico nodo raz y cualquier
nmero de niveles y nodos debajo. Cada uno de estos nodos sern llamados Unidad Organiza-
tiva en DHIS2. Una unidad organizativa puede ser un establecimiento de salud, un distrito, una
provincia..., en definitiva, cualquier entidad, fsica o administrativa, que represente un nodo en
el rbol de la estructura jerrquica.
El diseo de esta jerarqua determinar las unidades geogrficas de anlisis disponibles para
los usuarios, ya que los datos se recogen y almacenan en esta estructura. El sistema solo permite
la existencia de una jerarqua organizativa por lo que se debe prestar especial atencin al proceso
de diseo.
La jerarqua se construye con relaciones padre-hijo. Normalmente los establecimientos de

salud, que es donde se recogen los datos, se sitan en el nivel ms bajo, pero pueden estar en
niveles superiores, es decir, todas las ramas del rbol no tienen porqu tener la misma profun-
didad y todos los establecimientos no tienen porqu ser nodos hoja. Se pueden recoger datos en
58
cualquier nivel del rbol.
En nuestra implementacin, los centros y puestos estn definidos en el mismo nivel de pro-
fundidad, ambos cuelgan del nodo distrito (como se puede ver en la figura 17) porque en la
fase de diseo se consider que las agrupaciones durante el anlisis se haran a nivel distrital.
Igualmente se poda haber decidido colocar los puestos de salud por debajo de los centros. En
ese caso, siguiendo el ejemplo de la figura, la jerarqua habra quedado como:
Distrito Parinari
Centro de Salud Santa Rita de Castilla
Puesto de Salud Leoncio Prado
Puesto de Salud Santa Isabel de Yumbaturo
Puesto de Salud Santa Rosa de Lagarto
En este ejemplo los nodos hoja son los puestos de salud, pero tambin se recoge informacin
en el nivel anterior, en el centro de salud. Posteriormente, si se desea analizar los datos, ser
posible agruparlos a nivel de centro de salud, que agrupar como propios los datos de todos los
puestos que se encuentren por debajo de l en la jerarqua.
Esta estructura hace que parezca sencillo realizar modificaciones en la jerarqua cuando el sis-
tema ya esta funcionando, ya que los clculos de agregados se hacen basndose en la jerarqua
existente en el sistema en cualquier momento, es decir, siempre se reflejarn los cambios ms
recientes realizados en la estructura organizativa. Pero hay que tener cuidado con esto, ya que,
si por ejemplo cambiamos de padre a una unidad organizativa, los datos histricos que fueron
introducidos antes del cambio seguirn perteneciendo al padre original, por lo que cualquier re-
presentacin de series temporales por jerarqua se perder. Esta es una razn de peso para que
la definicin de la jerarqua deba ser definitiva antes de que el sistema empiece a funcionar.
Grupos y Conjuntos de Grupos de Unidades Organizativas

Los grupos y conjuntos de grupos son una herramienta ms flexible para la clasificacin de uni-
dades organizativas. Se puede aadir cualquier nmero de conjuntos, que a su vez debern estar
compuestos por grupos, y los grupos contienen cualquier nmero de establecimientos.
Por defecto el sistema tiene dos conjuntos de grupos, el conjunto tipo y el conjunto propiedad.
El uso de conjuntos de grupos facilita el anlisis ya que permite agrupar informacin siguien-
do estructuras diferentes a la geogrfica.
En este caso el conjunto de grupo sera la raz del rbol, los distintos grupos sern el segun-
do nivel de jerarqua y los establecimientos el tercero. De este modo la categorizacin de una
unidad organizativa se har ahora en funcin de su pertenencia o no a un determinado grupo.
Este mtodo puede ser entendido como una jerarqua de las unidades organizativas paralela a la
geogrfica, que puede tener un especial inters para el procesado de la informacin.
59
Figura 18: Jerarqua de Grupos y Conjuntos de Grupos
El conjunto de grupos proporciona entonces informacin y una dimensin adicional para el

anlisis de datos. Con ellos los datos se pueden filtrar de un modo sencillo, y se pueden organi-
zar o agregar por grupos dentro de un conjunto determinado. El hecho de que se puedan agregar
datos por grupos hace que los conjuntos de grupo sean exclusivos, es decir, que una unidad or-
ganizativa no puede pertenecer a ms de un grupo de un mismo conjunto de grupo.
La asignacin de nivel a las Unidades Organizativas

Permiten poner nombre a cada nivel de la jerarqua. Los nombres como pueda ser pas, provin-
cia, regin, distrito, y establecimiento, no tienen otro objetivo que el de ayudar a identificar
intuitivamente en qu nivel nos encontramos. Los nombres asignados sern utilizados en toda la
aplicacin, lo cual facilita el uso de la misma en la bsqueda de unidades organizativas.
6.1.2. La dimensin qu (Elementos de Datos)

Un elemento de datos define un valor que se almacena en la base de datos. Es decir, cualquier
unidad de informacin que se vaya a introducir en la base de datos, deber ser definido previa-
mente como un elemento de datos.
El elemento de datos es la pieza ms importante de la base de datos de DHIS2. Representa

la dimensin Qu y explica qu va a ser almacenado o analizado. En muchos casos, es un
concepto muy parecido a lo que en otros contextos se conoce como indicador, pero por el hecho
de que se introduce directamente el valor y no es calculado a partir de datos individuales, sino
que se trata de un elemento de recogida y anlisis, se le ha llamado elemento de datos.
Cuando se realizan anlisis, informes, validaciones, presentaciones, son los elementos de da-
tos, o expresiones compuestas de ellos las que describen sobre qu se est trabajando. Es por
60
esto que son, como decamos anteriormente, la pieza ms importante, ya que no solo definen
cmo se recogen los datos, tambin especifican cmo se representan los valores en la base de
datos, y cmo pueden ser analizados y representados.
Es importante, al definir los elementos de datos, pensar en ellos como unidades de anlisis de
datos y no solo como un campo en un formulario de recogida de datos. Cada elemento se al-
macena en la base de datos de manera independiente, sin vnculo alguno con el formulario. Los
informes y otras salidas se basan en elementos de datos y expresiones o frmulas compuestas
de ellos, por lo que el cmo quedar el formulario no debe ser una prioridad en esta etapa del
diseo.
Grupos y Conjuntos de Grupos de Elementos de Datos

Los grupos y conjuntos de grupos permiten clasificar los elementos de datos en dos niveles de
agrupacin. De forma anloga al caso de las unidades organizativas, el grupo est formado por
una seleccin de elementos con alguna caracterstica comn, sera el segundo nivel jerrquico,
y el conjunto de grupos est formado por grupos, como su nombre indica, siendo este el primer
nivel de la jerarqua (la raz del rbol).
Esta clasificacin es utilizada posteriormente por el sistema para analizar y generar informes,
as como para ayudar en ciertos formularios a la seleccin de elementos de datos, filtrando por
grupo o conjunto. Es habitual que en el sistema acabe habiendo un nmero elevado de elementos
de datos, por lo que termina siendo de mucha utilidad.
Categoras de Elementos de Datos

Las categoras permiten desagregar los elementos de datos en subgrupos ms especficos. Nor-
malmente son desagregaciones como Gnero, Edad o Estado de la Enfermedad.
Las categoras no son exclusivas de un elemento de datos, sino que se pueden reutilizar si ms
de un elemento se subdivide en las mismas categoras. Si se hace una definicin y uso lo ms
genrico posible, se puede llegar a simplificar mucho la implementacin del sistema a nivel de
nmero de elementos de datos, y permitir a la vez un buen nivel de anlisis.
Por ejemplo, una categora puede ser Mayora de Edad y estar compuesta por las opciones
Menos de 18 aos y 18 aos o ms. Si asignamos esta categora al elemento de datos Casos
de Malaria, este ahora estar compuesto por dos valores: Casos de Malaria con Menos de 18
aos y Casos de Malaria con 18 aos o ms.
Cuadro 6: Ejemplo Categoria DHIS

Casos de Malaria
Menos de 18 aos 18 aos o ms
61
Combinacin de Categoras de Elementos de Datos
En ocasiones es necesario desagregar los datos en ms de una categora. Podra entenderse como
una desagregacin por categoras anidada en una desagregacin previa. De esta forma termina-
ran combinndose todas las distintas opciones de ambas categoras.
Esta operacin se puede realizar mediante la Combinacin de Categoras. Vemoslo en un

ejemplo:
Cuadro 7: Ejemplo Combinacin de Categoras DHIS

Casos de Malaria
Menos de 18 aos 18 aos o ms
Masculino Femenino Masculino Femenino
En el cuadro vemos el resultado de combinar la categora Mayora de Edad con la categora

Gnero, y asignar la combinacin resultante Mayora de Edad - Gnero con el elemento de datos
Casos de Malaria.
6.1.3. La dimensin cundo (Periodos de tiempo)

La dimensin periodo cobra importancia cuando se hacen anlisis de datos en el tiempo, como
puede ser la generacin de informes anuales o mensuales.
En DHIS2 se definen ocho periodos; diario, semanal, mensual, trimestral, cada seis meses,
anual, bienal, y los periodos relativos. Los periodos relativos son tiles para la creacin de in-
formes, tablas, grficas que se quieren reutilizar y obtener datos siempre actuales.
Cada formulario de entrada de elementos de datos definido en el sistema, que deba ser relle-
nado peridicamente, deber tener asignado uno de los anteriores periodos. El sistema esperar
que se introduzcan datos siguiendo la periodicidad especificada.
Periodos Agregados
El hecho de tener que determinar la frecuencia con que los datos son introducidos en el sistema,
no limita el anlisis temporal de los datos y la generacin de informes para diferentes periodos.
Igual que los datos se agregan siguiendo la jerarqua de unidades organizativas, los periodos
temporales tambin se agregan siguiendo la jerarqua temporal lgica. De este modo, el periodo
62
asignado al conjunto de datos se convierte en el nivel ms bajo de detalle que se puede mostrar
en un informe o anlisis.
6.2. Anlisis Funcional

En este apartado se describen las principales funcionalidades de DHIS2 con el objetivo de
entender el alcance y las posibilidades de la herramienta.
Se explican en primer lugar los datasets11 y los formularios, conceptos que se deben manejar
para explicar posteriormente los mecanismos de entrada de datos al sistema.
A continuacin se detallan las posibilidades de anlisis de datos y de control de calidad de los

mismos.
Las siguientes son las funcionalidades de presentacin de datos, que se explican parte en las
opciones de anlisis, y parte en el apartado cuadro de mandos, pues son dos reas difciles de
separar.
Por ltimo se explicarn las posibilidades de gestin de usuarios y las herramientas de comu-
nicacin entre usuarios que ofrece la herramienta.
6.2.1. Datasets Y Formularios

Datasets
La entrada de datos en DHIS2 se basa en datasets. Un dataset es una coleccin de elementos de
datos agrupados para la captura de datos. En caso de instalaciones distribuidas tambin definen
paquetes de datos para importacin y exportacin de los mismos entre instancias de DHIS2.
Los datasets no estn vinculados directamente con los valores, sino con los elementos de da-
tos, sus frecuencias de entrada, y las unidades organizativas, por lo que cualquier modificacin
en un dataset no tendr ningn efecto en los datos existentes en el sistema, solo en el modo en
que se introducen en el mismo. Definen la estructura que seguir el sistema para la recogida de
datos: qu datos son recopilados por cada unidad organizativa, cada cunto se recogen, o que
datos se recogen a la vez, en la misma ventana.
Todo dataset debe tener definido un periodo que controla la frecuencia de entrada de datos.
Esta puede ser diaria, semanal, mensual, cuatrimestral, cada seis meses o anual. Por ltimo, los
datasets estn asociados a determinadas unidades organizativas, segn se defina en el sistema,
proporcionando as flexibilidad para el diseo de formularios en funcin del establecimiento que
lo vaya a utilizar, o restringiendo el acceso por cuestin de autoridad o privilegios.
11
La traduccin correcta de dataset sera Conjunto de Datos, pero resulta tediosa si recordamos que tambin existen
los Conjuntos de Grupos en el sistema, por lo que se mantendr el trmino en ingls en este caso.
63
Formularios de entrada de datos
El formulario es la forma de acceder al dataset previamente definido, es la representacin grfica
del mismo para la introduccin de datos.
Cuando se termina de definir un dataset, sus periodos de entrada de datos y sus unidades aso-
ciadas, este estar disponible por defecto como formulario de entrada de datos, que no es ms
que un listado de los elementos de datos del dataset, con una columna con casillas en blanco al
lado para la entrada de datos, y si alguno de los elementos de datos tiene definidas categoras
como pueda ser edad, o gnero, aparecern columnas adicionales en funcin de las opciones de
categora.
El formulario descrito en el prrafo anterior es el formulario que ofrece el sistema por defecto,
pero hay dos opciones ms:
El formulario basado en secciones.
El formulario personalizado.
Los formularios por secciones son un poquito ms flexibles y son rpidos y simples de
disear. Permiten estructurar la entrada de datos en tablas con sus correspondientes ttulos, o
deshabilitar ciertos campos de una tabla que pueden no ser pertinentes para un determinado ele-
mento de datos o una determinada categora.
Si se requiere ms complejidad para el diseo del formulario, entonces hay que utilizar los
formularios personalizados. Son los que lleva ms tiempo disear pero a cambio, el diseo de
la apariencia final es totalmente configurable. DHIS2 incorpora un editor HTML para este diseo
que puede ser editado desde ah, pegado directamente en el editor cdigo HTML externo, o lo
que lo hace realmente potente, pegar un formulario copiado de una hoja de clculo o de un
documento de texto en el editor.
Figura 19: ejemplo de formulario de entrada de datos
Gracias a los formularios personalizados se pueden hacer diseos idnticos a los formularios
que los trabajadores estn habituados a ver en papel. Esto facilita mucho la tarea de entrada de
datos y evita muchos errores de introduccin de datos en campos equivocados, sobre todo cuan-
do se hace la transicin del papel a la pantalla.
Una vez se define un formulario personalizado, el sistema lo utiliza por defecto aunque se ha-
ya definido un formulario basado en secciones, sin dar opcin al usuario a cambiar de formato.
64
El formulario de ejemplo de la figura 19 es un formulario de datos personalizado, y los ele-
mentos de datos estn vinculados a cada una de las casillas a rellenar. Es decir, el valor escrito
en cada casilla ser almacenado en el elemento de datos correspondiente.
Podemos decir que un formulario de entrada de datos es el equivalente a un formulario de

recogida de datos en papel, y el dataset sera su paralelo en la base de datos que se define para
almacenar los valores escritos.
6.2.2. Entrada de Datos

Es a travs del mdulo de Entrada de Datos como se introducen manualmente los datos agre-
gados en el sistema. Cada vez que se introducen datos se hace para una organizacin determina-
da, un periodo de tiempo, y un conjunto de elementos de datos.
La pgina de entrada de datos permite:
Validacin de los datos: El formato de los datos introducidos se valida en el momento, de

forma automtica, en funcin del tipo de dato esperado, que se define al crear el elemento
de datos. Si adems se ha creado un rango de valores posibles, tambin se valida en la
pantalla de entrada de datos.
Campos deshabilitados: Los campos en los que no deban ser introducidos datos, porque
no corresponde o por hallarse bloqueados, aparecern sombreados en gris.
Histrico de datos: Si se hace doble click sobre uno de los campos o casillas de entrada de
datos se abre una ventana que muestra los ltimos doce valores recogidos en este campo.
Tambin se muestran los valores mximos y mnimos
Etiqueta de seguimiento: En la ventana de datos histricos tambin hay una etiqueta para
marcar un valor que por alguna razn necesita ser examinado con posterioridad. Como
veremos en las herramientas de anlisis, se pueden buscar aquellos elementos de datos
marcados para seguimiento y corregirlos cuando proceda.
Etiqueta de Completitud: Existe la posibilidad de marcar el formulario como Completo.

Esto se utiliza posteriormente cuando se generan informes de completitud por distrito,
provincia, pas, etc.
65
Entrada de Datos offline
El mdulo de entrada de datos permite la introduccin de datos cuando la conexin a internet
no es estable. Para poder hacer uso de esta funcionalidad es necesario que se est conectado al
servidor en el momento de iniciar sesin. De este modo, si mientras se rellena el formulario se
pierde la conexin, se pueden seguir introduciendo datos, que se guardarn en el ordenador local
y sern enviados al servidor cuando la conexin sea restablecida.
Cuando la aplicacin detecta la prdida de conexin, muestra un aviso que informa que se
est trabajando offline, cuando se recupera la conexin se muestra igualmente por pantalla un
mensaje de aviso. En ese momento los datos se empiezan a sincronizar con el servidor y una vez
han sido recibidos y almacenados con xito se muestra un ltimo mensaje informando de que el
sistema est sincronizado con el servidor.
Este sistema es vlido cuando se producen cadas puntuales de la red y de relativamente corta
duracin. No permite empezar a trabajar en modo offline, ya que sin conexin no es posible
acceder al sistema e iniciar sesin. Si se sospecha que los cortes pueden ser muy habituales, o de
larga duracin, es ms recomendable tener instancias locales en las que trabajar, desde las que
luego se podrn exportar datos al sistema central12 .
Validacin de Datos en el Formulario
Una vez se han rellenado todos los campos del formulario se puede lanzar, desde la pantalla de
entrada de datos, la ejecucin de las reglas de validacin. Esto ejecutar todas aquellas reglas13
que estn vinculadas con elementos de datos del formulario que se est rellenando.
Una vez terminado el proceso de validacin, la aplicacin mostrar un mensaje informando

del resultado del test, detallando los errores devueltos cuando sea necesario.
6.2.3. Administracin de datos

El mdulo de Administracin de Datos incorpora las funcionalidades necesarias para que
el usuario se pueda asegurar de que los datos almacenados en la base de datos de DHIS2 son
ntegros. Normalmente estas funcionalidades son utilizadas por el administrador para asegurarse
de que la calidad de los datos almacenados es ptima.
Navegador de Datos
Se utiliza para la generacin de resmenes del contenido de la base de datos. Devuelve un con-
tador de elementos de datos introducidos en el sistema para la unidad organizativa seleccionada,
el periodo de tiempo especificado y sus unidades descendientes.
12
En este caso habr que definir una poltica de sincronizacin de las instancias locales con el servidor central.
13
El mdulo de Calidad permite la definicin de reglas de integridad (se explica ms adelante).
66
Integridad de Datos
Al acceder a esta seccin se lanzan una serie de controles de calidad predefinidos en la aplica-
cin. Se comprueba que los datos se han almacenado siguiendo la filosofa de diseo de la base
de datos, para garantizar que el sistema realiza un uso ptimo de los datos.
Los controles realizados son:
Elementos de Datos sin Conjunto de Datos
Elementos de Datos sin Grupo
Elementos de Datos violando la pertenencia exclusiva a un Conjunto de Grupos
Elementos de Datos asignados a Conjuntos de Grupos con diferentes tipos de periodo
Datasets no asignados a ninguna Unidad Organizativa
Indicadores con frmulas iguales
Indicadores sin Grupo
Numeradores de Indicador no vlidos
Denominadores de Indicador no vlidos
Indicadores violando la pertenencia exclusiva a un Conjunto de Grupos
Unidades Organizativas con referencias cclicas
Unidades Organizativas hurfanas
Unidades Organizativas sin Grupo
Unidades Organizativas violando la vinculacin obligada a un Conjunto de Grupos
Unidades Organizativas violando la pertenencia exclusiva a un Conjunto de Grupos
Unidades Organizativas sin Conjunto de Grupos
Reglas de Validacin sin Grupo
Expresiones de la parte izquierda de Reglas de Validacin invalidas
Expresiones de la parte derecha de Reglas de Validacin invalidas
Archivado de Datos
El archivo permite almacenar datos que no se estn utilizando para anlisis, ni se prev que se
vayan a utilizar, en un almacenamiento secundario. Se debe seleccionar un periodo temporal
a archivar y todos lo datos que hayan entrado al sistema en ese intervalo de tiempo pasaran a
almacenamiento secundario.
67
De este modo se reduce el tamao de las tablas y mejora el rendimiento de la aplicacin. Se
suelen almacenar datos de dos aos de antigedad o ms y pueden ser recuperados en cualquier
momento.
Archivado de Datos de Beneficiario

Tiene el mismo fin y el mismo funcionamiento que el archivado de datos, pero en este caso
se aplica a datos de beneficiario o paciente, mientras que en el archivado genrico se trata de
datos agregados. Es fcil introducir datos de paciente duplicados, especialmente cuando se usa
el archivado en segundo plano. En este caso el sistema sobreescribir los datos duplicados ms
recientes sobre los ms antiguos, tanto en la operacin de archivado como en la de recuperacin.
Mantenimiento
En mantenimiento se pueden realizar cinco acciones. Todas ellas buscan reducir el tamao de la
base de datos mejorando la eficiencia del sistema:
Limpiar el Data Mart14 de valores agregados: vaciar la tabla generada durante el proceso
de exportacin de data mart, que almacena los datos agregados.
Limpiar el Data Mart de valores de indicadores: vaciar la tabla generada durante el pro-
ceso de exportacin de data mart, que almacena valores de indicadores.
Limpiar valores cero: eliminar los valores cero, pero slo en los caso en que el operador
de agregacin asociado no sea media, sino suma.
Limpiar completitud de Datasets: eliminar los valores de completitud de datasets gene-

rados al crear las tablas de informe de completitud.
Purgar periodos: Eliminar todos aquellos periodos temporales para los que no se hayan
introducido datos en el sistema.
Tablas de Recursos
Las tablas de recursos son tablas que proporcionan informacin sobre la estructuracin interna
de la base de datos y las relaciones entre sus distintas entidades. Facilitan los trabajos de anlisis
cuando se trabaja con herramientas externas o directamente sobre las tablas de la base de datos
con aplicaciones de gestin. Estas tablas slo se deberan generar cuando todos los controles de
calidad de datos, enumerados anteriormente, son satisfactorios.
Las tablas generadas son:
Estructura de Unidades Organizativas (_orgunitstructure)
Estructura de Conjuntos de Grupos de Elementos de Datos (_dataelementgroupsetstruc-

ture)
14
El data mart se explicar ms adelante en esta misma seccin.
68
Estructura de Conjuntos de Grupos de Indicadores (_indicatorgroupsetstructure)
Estructura de Unidades Organizativas en Conjuntos de Grupos de Unidades Organizativas

(_organisationunitgroupsetstructure)
Estructura de Categoras (_categorystructure)
Nombres de Opcin de Combinacin de Categorias de Elemento de Datos (_categoryop-

tioncomboname)
Vista SQL
Para la definicin de vistas15 en SQL, el sistema almacena la definicin de la vista, y la materia-
lizar en el momento que sea solicitada.
Fusin de Unidades Organizativas

Para la fusin de datos de dos unidades organizativas.
Eliminacin de Duplicados
Para eliminar elementos de datos que han sido introducidos dos veces en el sistema por equivo-
cacin. Los valores existentes sern almacenados en el elemento de datos que permanezca en el
sistema.
Estadsticas de Datos
Muestra una tabla resumen con un recuento de los objetos almacenados en la base de datos
(elementos de datos, grupos de elementos de datos, tipos de indicador, indicadores, grupos de
indicador, datasets, diccionarios de datos,unidades organizativas, reglas de validacin, periodos,
usuarios, valores de datos, valores agregados), as como un contador de los usuarios que han
accedido al sistema y los valores introducidos recientemente.
Bloqueo de Datos
Permite a los usuarios bloquear ciertos datasets para unas determinadas unidades organizativas.
Permite bloquear por periodos temporales y as limitar en el tiempo la entrada de datos.
Almacenamiento de Valores Cero

Esta funcin permite definir para qu elementos de datos se deben almacenar los valores cero en
la base de datos. Por defecto el sistema no almacenar los ceros, excepto para aquellos elemen-
tos en que se indique explcitamente.
15
Una vista es el resultado de una consulta SQL que devuelve una o varias tablas. Las vistas tienen la misma es-
tructura que una tabla: filas y columnas, con la diferencia de que solo se almacena de ellas la definicin, no los
datos.
69
Poda de Unidades Organizativas
Si se necesita eliminar alguna rama de la jerarqua de unidades organizativas se puede hacer
desde esta seccin, se debe tener en cuenta que los datos de las unidades eliminadas sern eli-
minados del sistema, por lo que, si se desea conservarlos se debe realizar primero una fusin de
establecimientos.
Generacin de Valores Mximos y Mnimos

Permite la generacin de valores lmite para unos grupos de datos determinados. Estos mximos
y mnimos sern utilizados en los procesos de validacin y de calidad de datos.
Constantes
Las constantes son los valores estticos que al ser declaradas estn al alcance del usuario para el
clculo de indicadores y generacin de expresiones.
Estadsticas de Cach
Esta opcin es para uso exclusivo de los administradores del sistema. Muestra el estado de la
cach de la aplicacin. Cuando se hacen cambios directamente en la base de datos y hay que
actualizar al cach del sistema, tambin se hace desde aqu.
Atributos Dinmicos
Para aadir informacin que queremos que sea recogida por defecto en la generacin de elemen-
tos de datos, indicadores, unidades organizativas, o usuarios.
6.2.4. Indicadores
Los indicadores son una caracterstica muy potente de DHIS2. La diferencia con los elemen-
tos de datos es que estos son los datos en bruto, sin tratar, tal y como entran en el sistema,
mientras que los indicadores son representados mediante frmulas que proporcionan ratios de
cobertura, de incidencia, o cualquier otra unidad de anlisis obtenida mediante una frmula.
El valor de un indicador nunca es introducido directamente en el sistema, sino que se obtiene

a partir de combinaciones de elementos de datos y factores. Se calcula con un factor (1, 10,
100, 1000...), un numerador y un denominador. El numerador y denominador sern uno o ms
elementos de datos, una constante o una expresin matemtica.
Indicador = (numerador / denominador) x factor
La mayora de mdulos de informes de DHIS 2 permiten trabajar tanto con indicadores como
con valores de elementos de datos, por separado o en el mismo informe. La utilidad a destacar
de los indicadores es que permiten comparar datos entre diferente reas geogrficas de distintas
70
caractersticas de un modo fiable, mediante el uso de una variable comn en el denominador.
Por ejemplo, el porcentaje de incidencia de una enfermedad, calculado utilizando el nmero de
casos como numerador y la poblacin total como denominador, permite comparar la incidencia
de la enfermedad en dos zonas con una muy diferente densidad de poblacin.
Tipos de Indicadores
Los tipos de indicadores simplemente definen el factor numrico que ser aplicado durante el
clculo de los indicadores. A todo indicador se le debe asignar un tipo durante su creacin.
Grupos y Conjuntos de Grupos de Indicadores

Los grupos y conjuntos de grupos de indicadores funcionan exactamente igual que los de ele-
mentos de datos o unidades organizativas. Agrupan en dos niveles indicadores con temtica
similar y son muy tiles para filtrar en los desplegables de seleccin de indicadores y durante el
anlisis de datos.
6.2.5. Calidad de Datos

El mdulo de calidad de datos permite mejorar la precisin y fiabilidad de los datos. Lo hace
a travs de reglas de validacin y de controles estadsticos.
Las dimensiones de calidad de datos tenidas en cuenta en el sistema DHIS2 son:
Correccin: Los datos deben encontrarse en un rango de normalidad respecto a los datos
ya recogidos para un mismo establecimiento. No debe haber grandes discrepancias.
Completitud: Todas los establecimientos deben completar todos los formularios.
Consistencia: Los datos deben ser consistentes con los datos introducidos en meses y aos
previos, y consistentes tambin con establecimientos de caractersticas similares.
Puntualidad: Los datos de todas las unidades deben ser reportados en el periodo temporal
definido.
El control de calidad de datos se puede hacer por diversos mtodos:
Al introducir los datos, en el mismo formulario de entrada, haciendo doble click sobre
cada casilla, el software comprobar si se encuentra entre los valores mximo y mnimo
esperados.
Definiendo reglas de validacin, que pueden ser ejecutadas al terminar de rellenar el for-
mulario, o lanzarlas en lote para un periodo determinado y una o ms unidades organiza-
tivas.
De modo manual, examinando posibles vacos en los conjuntos de datos.
71
De forma manual tambin, mediante triangulacin de datos, que es la comparacin de un
determinado dato o indicador de diferentes fuentes.
Anlisis por Reglas de Validacin

Antes de hablar de la ejecucin del anlisis por reglas de validacin se deben definir las reglas
de validacin.
Una vez se han definido los datos a introducir en el sistema y los formularios de recoleccin,
se debe proceder a definir las reglas de validacin que sern ejecutadas en los procesos de con-
trol de calidad de datos. El sistema permite definir tantas reglas como sea necesario.
Las reglas no son ms que una expresin que define una relacin entre un nmero de elemen-
tos de datos. La expresin tiene un lado izquierdo y un lado derecho, y un operador que define si
el primero tiene que ser menor que, igual a, o mayor que el segundo. Normalmente estas reglas
se utilizan para comparar totales y subtotales y evitar situaciones errneas por definicin, como
por ejemplo, que la suma de casos de una determinada patologa para cada rango de edad debe
ser igual o menor al nmero total de casos de la patologa en cuestin.
Una vez definidas las reglas se pueden clasificar creando grupos de reglas. Las reglas de va-
lidacin deben ser reglas absolutas, es decir, deben ser condiciones matemticamente correctas
que se cumplen siempre.
Las reglas de control de calidad se ejecutan desde el rea de anlisis por reglas de validacin,
que permite seleccionar las reglas a lanzar, y sobre qu periodo de tiempo y qu unidades organi-
zativas se quiere realizar la validacin. La ejecucin de las mismas devuelve un listado de todas
las violaciones detectadas con detalle del dato errneo en cuestin, o un mensaje informado de
que el proceso se ha completado con xito cuando no se detecte error alguno.
Anlisis por Desviacin Estndar

Se trata de un mecanismo que detecta valores atpicos, numricamente distantes del resto de
datos. Este tipo de valores se puede dar por casualidad, pero generalmente indican un error
de medida o que los valores no siguen una distribucin normal. Hay que tener cuidado con la
identificacin de errores en estos casos, ya que el anlisis asume que los valores siguen una dis-
tribucin normal.
Anlisis por Mximos y Mnimos

En este anlisis se detectan valores que estn fuera del rango predefinido. Los valores mximo
y mnimo que establecen el rango pueden ser fijados a mano o generados automticamente por
el sistema.
Anlisis por Brecha

Es un mecanismo de bsqueda de brechas o intermitencias en los datos. Una brecha se da para
72
un elemento de datos concreto y una unidad organizativa. Entendemos como brecha un periodo
en el que no se registran datos, que est seguido y precedido de periodos en los que s se han
registrado datos. La aparicin de una brecha o hueco en los datos puede indicar que no se estn
rellenando los datos, o que se est produciendo algn error en el proceso de captura.
Anlisis por Seguimiento

Como indicbamos en la seccin de Entrada de Datos, al introducir los datos en el sistema estos
puedes ser marcados para seguimiento, porque por algn motivo deben ser observados o analiza-
dos con posterioridad. Tambin se pueden marcar en los otros mdulos de anlisis explicados en
este apartado. Es en este anlisis en el que se detectan todos estos datos previamente marcados.
Al ejecutarlo, devuelve un listado con los valores de datos que estn bajo seguimiento para
que el usuario pueda proceder a examinarlos.
6.2.6. Anlisis de Datos

El anlisis de datos en DHIS2 es una parte importante de la aplicacin, de hecho hay diversas
funcionalidades implementadas con este fin, desde informes estndar hasta la representacin de
los mismos en un sistema de informacin geogrfica, pasando por representaciones grficas, ta-
blas dinmicas y data marts.
Informes estndar
Se trata de informes de diseos predefinidos. Son fciles de generar y pueden ser utilizados por
usuarios de cualquier nivel de experiencia. En el informe se pueden representar estadsticas en
forma de tablas o grficos. Se adapta a casi cualquier requerimiento del usuario. Pese a que el
diseo es esttico, se puede personalizar la unidad organizativa y el periodo de tiempo para el
que se quieren representar datos.
Informes de Conjuntos de Datos

Este informe tiene el mismo diseo del formulario de entrada de datos, pero con los datos agre-
gados para el periodo y la unidad organizativa seleccionados. Es tambin accesible a usuarios de
cualquier nivel y es una forma rpida de consultar los datos agregados.
Informes de Completitud de Datos

El informe de completitud genera estadsticas del grado de completitud de los formularios de
entrada de datos y de la puntualidad de la entrada de los datos al sistema. Se puede generar de
modo individual o para un listado de unidades organizativas, siempre que tengan un padre co-
mn en la jerarqua.
El criterio de completitud a seguir en la generacin del informe lo debe elegir el usuario entre:
Basado en los conjuntos de datos marcados como Completo.
73
Basado en si los elementos de datos marcados como obligatorios han sido o no rellenados.
Basado en el porcentaje de campos rellenos frente a los campos disponibles.
Informes Estticos
Los informes estticos proporcionan dos mtodos para conectar los recursos existentes con la
interfaz de usuario. En primer lugar se puede enlazar a un documento que est publicado en
internet a travs de una URL. En segundo lugar, se pueden subir documentos al sistema y que
de este modo estn accesibles como informe. Se pueden subir documentos de texto, imgenes o
vdeos.
Informes de Distribucin de Unidades Organizativas

Este informe genera estadsticas de cmo se distribuyen las unidades organizativas en la jerar-
qua en funcin de su clasificacin en grupos y conjuntos de grupo.
Tablas de Informe
Son informes basados en datos agregados representados mediante tablas. Las tablas se pueden
utilizar como informes en s, o como fuente de datos para el diseo de informes estndar, y pue-
den contener tanto indicadores como elementos de datos agregados. Se pueden construir en base
a periodos relativos, lo que permite que el informe sea reutilizado en el tiempo.
Se trata de tablas que pueden ser dinmicas, pues tambin se pueden definir de forma que
permitan al usuario la seleccin de la unidad organizativa o el periodo de tiempo a mostrar.
Grficas
La herramienta de generacin de grficos es bastante completa. Incluye distintos tipos de grfi-
cas como grfico de barras, de linea, y circulares. En ellos se pueden representar elementos de
datos, indicadores, periodos y unidades organizativas en cualquiera de los ejes.
Tablas Dinmicas
Estas tablas permiten acceder rpidamente a representaciones tabulares de datos estadsticos que
permiten pivotar cualquiera de sus dimensiones como indicadores, elementos de datos, unidades
organizativas y periodos, para que aparezcan en filas o columnas, creando as diseos personali-
zados. Cada celda de la tabla puede visualizarse como un grfico de barras, si as se desea.
Sistema de Informacin Geogrfica

El mdulo SIG permite visualizar datos agregados en mapas. Proporciona un mapeado dinmico
de polgonos, para representar provincias o distritos, y de puntos que representan los estableci-
mientos. Se pueden representar en diferentes capas que se pueden mostrar a la vez o combinadas
con capas personalizadas. Las representaciones en mapas se pueden guardar etiquetadas para
74
posteriores visitas y se pueden mostrar en el cuadro de mandos.
Es un mdulo muy completo que proporciona generacin automtica de leyendas, la posibili-

dad de poner etiquetas de nombre en elementos geogrficos, y medir distancia entre dos puntos
en el mapa. Se pueden visualizar valores de cualquier indicador o elemento de datos, y para
cualquier nivel de la jerarqua de unidades organizativas.
Data Mart
El objetivo del data mart es proporcionar datos preprocesados para su uso en herramientas de
anlisis y representacin de datos. Se basa en la generacin de dos tablas en la base de datos de
DHIS2. En ellas se almacenan valores agregados, calculados a partir de los valores de elementos
de datos existentes en la base de datos, as como del clculo de los indicadores previamente
definidos. La agregacin se puede realizar tanto en intervalos temporales (valores semanales,
mensuales, etc ), como en funcin de su distribucin geogrfica (valores agregados por distrito,
o provincia). El data mart no es ms que una copia procesada de los valores almacenados en
la base de datos, y puede ser vaciado y regenerado tantas veces como sea necesario.
El objetivo es el de dar al usuario acceso completo a los datos agregados, incluso cuando la
conexin a internet no es fiable, a travs de la exportacin de datos usando el data mart, y su
posterior anlisis a travs de herramientas externas como Mydatamart.
Mydamart es una herramienta de escritorio que funciona sobre Windows o Linux. Permite al
usuario mantener una copia local del data mart generado en DHIS2. La herramienta se encarga
de la sincronizacin con la base de datos de DHIS2, para ello se conecta al servidor online que
est ejecutando una instancia de DHIS2, descarga los datos agregados que el usuario seleccione
y los almacena en su base de datos local. Esta base de datos se puede conectar a una tercera
herramienta de anlisis y visualizacin, como por ejemplo las Tablas Dinmicas de Excel. Esta
solucin permite tener la base de datos local sincronizada con el servidor central en un corto
periodo de tiempo de conexin.
6.2.7. Cuadro de Mandos

El objetivo de los cuadros de mandos es proporcionar a los usuarios el acceso rpido a una
representacin fcilmente comprensible de la informacin de ms relevancia, almacenada en el
sistema.
El cuadro de mando en DHIS2 est pre-estructurado y se divide en dos secciones principales.

En el rea del lado izquierdo de la pantalla, arriba, se ubican enlaces a informes, documentos,
tablas, o vistas de mapas, y en la parte inferior hay un mdulo RSS de salud16 . El rea del lado
derecho se pueden mostrar hasta seis grficas que deben haber sido creadas anteriormente en el
16
http://health.yahoo.net/
75
mdulo correspondiente.
La configuracin del cuadro de mandos la personaliza cada usuario y es una configuracin

habitual el mostrar el cuadro de mandos en la pgina de inicio. Si se definen bien los elementos
a mostrar, permite hacerse una idea rpida del estado de salud en la zona.
6.2.8. Administracin de Usuarios

DHIS2 permite el acceso de mltiples usuarios al sistema simultneamente, cada uno con sus
permisos correspondientes, que pueden ir desde slo entrada de datos hasta la generacin de
informes.
Esta flexibilidad es posible porque trabaja sobre la definicin de roles y la asignacin de per-
misos a los mismos. Destacar que la herramienta no permite la herencia de privilegios entre
roles, lo cual hara ms rpida la definicin de los distintos roles y ms manejable la estructura
en s de roles-permisos a la hora de hacer modificaciones.
Al definir un rol, adems de seleccionar los privilegios asociados, se debe especificar tambin
a qu conjuntos de datos est vinculado, y esos sern los nicos a los que los usuarios con ese rol
podrn acceder. Al definir un usuario se debe asignar un rol y la o las unidades organizativas a
los que pertenece el usuario. Los usuarios se deben asignar a, al menos, una unidad organizativa
y tendrn acceso a la unidad o unidades que les son asignadas y a todas las organizaciones hijo
de las mismas.
Grupos de Usuarios
Los grupos de usuarios son otra de las opciones de la herramienta. No existen grupos predefini-
dos, se deben crear y asignar los usuarios correspondientes. El uso de grupos es til cuando se
desea enviar notificaciones a mltiples usuarios.
Funciones de Usuarios
Un listado de todas las funciones de usuario se encuentran en la siguiente tabla. Es la asignacin
de estas funciones, junto con el control de acceso a los diferentes mdulos, lo que permite la
creacin de diferentes roles de usuario.
Cuadro 8: Funciones de Usuario DHIS2

Administracin de datos
Aadir Concepto
Eliminar concepto
Administracin de Conceptos
Actualizar Concepto
Aadir Constante
76
... Continuacin
Eliminar Constante
Administracin de Constantes
Actualizar Constante
Bloqueo de datos
Desbloqueo de datos
Aadir Diccionario de Datos

Eliminar Diccionario de Datos
Actualizar Diccionario de Datos
Aadir Elementos de Datos

Eliminar Elementos de Datos
Actualizar Elementos de Datos
Aadir Grupo de Elementos de Datos

Eliminar Grupo de Elementos de Datos
Actualizar Grupo de Elementos de Datos
Aadir Conjunto de Grupo de Elementos de Datos

Eliminar Conjunto de Grupo de Elementos de Datos
Actualizar Conjunto de Grupo de Elementos de Datos
Aadir regla Max/Min

Eliminar regla Max/Min
Aadir Conjunto de Datos

Eliminar Conjunto de Datos
Actualizar Conjunto de Datos
Aadir Valor de datos

Eliminar Valor de datos
Actualizar Valor de datos
Anlisis y Presentacin de Datos

Aadir Documento
Eliminar Documento
Administrar SIG
Aadir Indicadores
Eliminar Indicadores
Actualizar Indicadores
Aadir Grupos de Indicadores

Eliminar Grupos de Indicadores
Actualizar Grupos de Indicadores
77
... Continuacin
Aadir Conjunto de Grupos de Indicadores
Eliminar Conjunto de Grupos de Indicadores
Actualizar Conjunto de Grupos de Indicadores
Aadir Tabla de Informe

Borrar Tabla de Informe
Aadir Informe
Borrar Informe
Aadir Seccin
Borrar Seccin
Actualizar Seccin
Aadir Vista SQL

Borrar Vista SQL
Ejecutar Vista SQL
Actualizar Vista SQL
Administracin Vista SQL
Administracin de Unidades Organizativas

Aadir Unidad Organizativa
Borrar Unidad Organizativa
Mover Unidad Organizativa
Actualizar Unidad Organizativa
Aadir Nivel de Unidad Organizativa

Eliminar Nivel de Unidad Organizativa
Actualizar Nivel de Unidad Organizativa
Aadir Grupo de Unidad Organizativa

Borrar Grupo de Unidad Organizativa
Actualizar Grupo de Unidad Organizativa
Aadir Conjunto de Grupo de Unidad Organizativa

Borrar Conjunto de Grupo de Unidad Organizativa
actualizar Conjunto de Grupo de Unidad Organizativa
Administracin de Pacientes
Aadir Paciente
Borrar Paciente
Actualizar Paciente
Actualizar valor Atributo de Paciente

Aadir Atributo de Paciente
Borrar Atributo de Paciente
Actualizar Atributo de Paciente
78
... Continuacin
Aadir tipo de Identificador de Paciente
Borrar tipo de Identificador de Paciente
Actualizar tipo de Identificador de Paciente
Aadir Relacin
Borrar Relacin
Actualizar Relacin
Aadir Tipo de Relacin

Borrar Tipo de Relacin
Actualizar Tipo de Relacin
Administracin de Programas
Aadir Programa
Borrar Programa
Actualizar Programa
Aadir Etapa de Programa

Borrar Etapa de Programa
Actualizar Etapa de Programa
Aadir Atributo de Programa

Borrar Atributo de Programa
Actualizar Atributo de Programa
Administrar Validacin de Programas
Administracin de Usuarios
Aadir usuario
Borrar usuario
Actualizar usuario
Aadir Rol de usuario
Eliminar Rol de usuario
Actualizar Rol de usuario
Aadir Grupo de usuario
Borrar Grupo de usuario
Actualizar Grupo de usuario
Administracin de Calidad de Datos

Aadir Criterio de validacin
Borrar criterio de validacin
Actualizar criterio de validacin
Aadir Grupo de Reglas de Validacin
Eliminar Grupo de Reglas de Validacin
Actualizar Grupo de Reglas de Validacin
Aadir Reglas de Validacin
Eliminar Reglas de Validacin
Actualizar Reglas de Validacin
79
... Continuacin
Otras Funciones
Enviar Mensaje
Cambiar configuracin de Sistema
6.2.9. Mensajes y Feedback

Para facilitar la comunicacin entre usuarios, DHIS2 incluye la funcionalidad mensajes. Es
importante que se puedan comunicar para tratar temas como la calidad de los datos, el cumpli-
miento o no de los plazos, o incluso para ayudarse en el uso de la herramienta.
Los mensajes feedback son enviados a un grupo de usuarios determinado y pueden ser en-
viado por todos los usuarios que tienen acceso al mdulo del cuadro de mandos. El grupo de
usuarios receptor debe ser previamente definido y estos recibirn el mensaje en la aplicacin, no
en su correo electrnico.
Los mensajes son diferentes, ya que se pueden enviar a grupos de usuarios especficos que
hayan sido asignados a una unidad organizativa, y cuando as lo haya definido el usuario, los
recibir en su correo electrnico.
6.2.10. Configuracin
La herramienta permite cierta configuracin personalizada de la aplicacin a nivel de usuario,
y a nivel de sistema.
Configuracin de Usuario
Permite una configuracin del sistema, que ser especfica del usuario, que incluye:
Seleccin del idioma de la interfaz grfica (actualmente disponible en ingls, francs,

portugus, espaol17 , y vietnamita)
Seleccin del idioma de la base de datos
Definicin del campo que ordenar las listas y qu propiedad se mostrar como identifi-
cacin en todas las listas mostradas en la aplicacin
Eleccin de los colores de la interfaz
Eleccin del nmero de grficas a mostrar en el cuadro de mandos
Activacin del guardado automtico en los formularios de entrada de datos
17
La traduccin al espaol nunca ha sido puesta en produccin, por lo que no se considera definitiva
80
Configuracin del email que ser utilizado para enviar mensajes al correo electrnico del
usuario, cuando as lo haya solicitado el mismo
Configuracin del Sistema

La configuracin del sistema se presenta en tres secciones, configuracin general, de apariencia
y de email. En la configuracin general se puede especificar:
Estrategia de agregacin del sistema
Elementos de Datos de Infraestructura
Periodos de Infraestructura
Receptores de Aportaciones
Receptores de Notificaciones de Completitud
Omitir Indicadores de Numerador cero en Data Mart
Deshabilitar la entrada de datos cuando el Conjunto de Datos est completo
Factor a utilizar en el anlisis de datos por desviacin estndar
Periodo de tiempo mximo de entrada de datos
En la configuracin de apariencia se puede personalizar el ttulo, la gama de colores de la

aplicacin, si se quiere mostrar bandera y qu bandera, y qu se quiere mostrar en la pgina de
inicio. En cuanto a la configuracin de email, se deben introducir los datos de la cuenta de correo
que desee utilizar el usuario.
6.2.11. Mdulo de Informacin de Seguimiento de Pacientes

Se trata de una de las ltimas grandes incorporaciones de DHIS2, que hasta ahora no trabajaba
con datos de pacientes. Este mdulo recibe otros nombres en ingls como DHIS Community
Module, Name Based Module, o NBITS Module, sinnimos de su nombre original, Name
Based Information Tracking System.
Se crea con el objetivo de apoyar a los sistemas de salud comunitarios y facilitar la integra-
cin entre los datos de salud personales y los datos agregados de gestin. Soporta la gestin
de programas de salud como pueden ser la inmunizacin infantil o salud materna. Permite el
seguimiento individual de pacientes registrados en uno o ms programas y la planificacin de
actividades de los trabajadores de salud.
Las caractersticas principales del mdulo son:
1. Administracin de pacientes - registro, relaciones, inclusin en programas.
81
2. Administracin de meta datos - atributos de beneficiario, tipo de indentificadores, progra-
mas, atributos de programa, etapas de programa, validaciones.
3. Enlace entre datos de paciente y datos agregados.
4. Entrada de datos de la evolucin de los pacientes en los programas.
5. Planificacin de Actividades.
Aunque en atencin primaria los datos que se registran son principalmente individuales, cuan-
do se envan a niveles superiores se hace en informes con datos agregados. Con la implementa-
cin de este modulo y la disponibilidad de los datos online, el objetivo final ha sido asegurar la
calidad y completitud de los datos.
Es en lnea con esta importante iniciativa que se ha creado el modulo de generacin de infor-
mes name-based, implementado y en funcionamiento en las instalaciones de DHIS2 en la India,
pero que no ha sido incluido todava en el paquete genrico de la herramienta.
Registro e Identificacin de Beneficiarios

Todos los pacientes introducidos en el sistema tendrn un establecimiento asociado, que es desde
el que son introducidos en el sistema. Al registrar a un paciente en el sistema este ser asocia-
do a diversos identificadores personales, como pueda ser el numero de pasaporte, licencia de
conduccin, numero de identificacin de salud o cualquier otro definido por el administrador. A
nivel interno tendr un identificador nico en el sistema.
Aunque los pacientes estn asociados a un establecimiento, el acceso a sus datos es indepen-
diente de la localizacin. Se puede acceder y editar sus datos desde cualquier otro establecimien-
to, siempre que los privilegios lo permitan y se encuentre en la misma base de datos.
Programas
Los programas son la herramienta para definir programas de salud. Toda la informacin de pa-
ciente es introducida en el sistema y ordenada a travs de programas. Los programas se com-
ponen de una serie de etapas que no son ms que encuentros predefinidos segn la estructura o
planificacin del programa en cuestin.
En DHIS2 se definen tres tipos de programas con diferentes filosofas:
Programa basado en etapas: Es un programa de salud tpico en el que se realiza un proceso

estructurado y continuado en el tiempo de seguimiento del paciente. Se compone de etapas
que estn previamente definidas, tanto en contenido como en temporalidad. Un ejemplo
de programa de seguimiento es el del Seguimiento del Embarazo.
Evento aislado: Se trata de un programa de una sola etapa en el que un paciente solo se
puede registrar una vez. Por ejemplo para registrar un nacimiento o defuncin.
82
Programa basado en encuentros: Es muy parecido al programa basado en etapas, pero en
este caso la temporalidad de las visitas no est predefinida, el paciente acude al servicio
de salud cuando tiene necesidad, no cuando le cita el personal sanitario. Por ejemplo, las
visitas de un paciente a un centro de atencin primaria. Esta modalidad est definida en la
filosofa del mdulo basado en pacientes, pero no se encuentra implementada todava.
Registro en un Programa y Plan de Tratamiento

Cuando un paciente se registra en un programa de salud, se crea un registro de tratamiento para
el mismo. En el registro se introducen todos los servicios y/o cuidados que recibe el paciente, y
esto es lo que se conoce como plan de tratamiento.
Encuentros
Se llama encuentro a cada interaccin paciente-profesional de salud que se produce. Estas in-
teracciones o visitas pueden ser programadas o no. Cada actualizacin en los datos de paciente
quedar identificada con el trabajador de salud que la realiza y el beneficiario que recibe el ser-
vicio.
Generacin de Informes
El modulo incorpora dos informes principales, un informe de actividad y un informe resumen.
Informe de Actividad: Este informe devuelve un listado con las visitas que han sido planifica-
das en los diversos programas.
Informe Resumen: Devuelve un informe genrico de los servicios proporcionados por el esta-
blecimiento en el marco de un determinado programa.
De Datos de Paciente a Datos Agregados

Una de las grandes aportaciones del mdulo de pacientes es el poder calcular datos agregados
a partir de datos individuales y personales. Esto es posible gracias al constructor de consultas
de agregados de beneficiario. Es una herramienta que permite, por interfaz grfica, definir una
consulta que ser traducida a SQL por el sistema y lanzada contra la base de datos, devolviendo
el valor agregado que se haya definido al crearla.
Los valores calculados son almacenados en un elemento de datos que debe ser creado previa-
mente para ello. Un dato agregado que podra calcularse desde datos de paciente es, por ejemplo,
el nmero de casos de Malaria registrados, que sera calculado sumando aquellos casos en que
el diagnstico sea igual a Malaria18 .
18
La codificacin de enfermedades se realiza siguiendo el estndar CIE-10, pero veremos en el anlisis de requisitos
que DHIS2 no est preparado para almacenar la estructura arbrea del estndar. Se realiza una implementacin
poco eficiente del mismo en la que se almacenan todos los diagnsticos necesarios de modo lineal.
83
6.3. Analisis Tcnico de DHIS2
DHIS2 es un sistema de informacin flexible y muy fiable que, como hemos visto en los ca-
ptulos anteriores, permite la recogida, validacin, anlisis y presentacin de datos estadsticos
agregados e individuales.
Est diseado para ayudar a la gestin e integracin de actividades de salud, aunque no est
limitado a este uso. Se trata de una herramienta genrica y adaptable, muy lejos de ser una apli-
cacin de base de datos preconfigurada. Esto es posible gracias a un modelo de datos abierto y
una interfaz de usuario que permita definir los contenidos especficos de su sistema de informa-
cin sin necesidad de programacin.
Es un software modular basado en web, y programado con frameworks java abiertos y libres.
6.3.1. Caractersticas Tcnicas

En este apartado se destacan las cualidades tcnicas que hacen de DHIS2 una herramienta
potente y accesible.
Basado en Web: DHIS 2 est basado en tecnologa estndar Java, por lo que la aplicacin
puede ser ejecutada en cualquier servidor que soporte servlets Java y ser accedido por web
a travs de una conexin de internet o intranet.
Multiplataforma: Al estar desarrollado en Java el sistema puede ser ejecutado en cualquier

plataforma con entorno de ejecucin java, que hoy en da son prcticamente todas las
plataformas ms utilizadas, Windows, Linux, Mac OS X y Solaris.
Compatible con la mayora de navegadores web: El cdigo de DHIS 2 se ha escrito si-

guiendo el estandar del World Wide Web Consortium19 para HTML y CSS y funciona
en cualquier navegador estndar como son Firefox, Chrome, Opera, Safari 4 e Internet
Explorer 8+.
Compatible con la mayora de bases de datos relacionales: Actualmente DHIS2 funciona

con PostgreSQL, MySQL, HSQLDB, H2 y Derby. Esa construido sobre Hibernate por lo
que no se necesitan grandes modificaciones para hacerlo trabajar con otros sistemas de
base de datos.
Software Libre: DHIS2 se lanza como software libre y abierto bajo licencia BSD. Esta
licencia permite, por supuesto, descargarlo y utilizarlo de un modo gratuito, pero tam-
bin permite el acceso al cdigo con libertad de hacer las modificaciones que se desee y
redistribuirlo bajo la licencia que el creador considere conveniente.
19
El World Wide Web Consortium (W3C) es una comunidad internacional que desarrolla estndares que aseguran el
crecimiento de la Web a largo plazo.
84
Arquitectura Modular: Desde el punto de vista de desarrollo de la aplicacin, esto quiere
decir que es posible crear nuevas funcionalidades y aadirlas a la aplicacin sin necesidad
de tocar el cdigo fuente. Desde el punto de vista de la implementacin, implica que se
pueden incluir las funcionalidades requeridas en cada contexto y excluir las que no son
tan necesarias.
Interoperable: El sistema de informacin sigue el estandar oficial para intercambio de

informacin de salud SDMX-HD, desarrollado por la OMS. Esto lo hace interoperable
con otras aplicaciones software de salud y con el Registro de Indicadores y Medidas de la
OMS20 .
Flexible: El modelo de datos de DHIS es completamente flexible, por lo que no hacen

falta nuevos desarrollos por muy especiales que sean los requisitos de entrada de datos.
Todo puede ser definido como elemento de datos u otros elementos del sistema.
Internacional: La aplicacin es internacional en cuanto a la interfaz de usuario y al con-

tenido de la base de datos de meta-datos. Actualmente se encuentra disponible en Ingls,
Francs, Espaol, Hind, Vietnamita y Noruego.
6.3.2. Requisitos Tcnicos

Las recomendaciones software de HISP para la instalacin de un servidor a nivel nacional son
las siguientes:
Sistema Operativo de 64 bits (Ubuntu 10.04 LTS)
Sistema de Base de Datos (PostgreSQL)
Contenedor de Servlets (Tomcat)
Java Runtime Environment version 6 o superiores
En cuanto a las recomendaciones hardware para el servidor, sugieren que tenga al menos
un procesador Quad-Core a 2Ghz con 12 Gb de RAM. Se trata de recomendaciones mnimas
y salvo casos excepcionales de incompatibilidad, se puede considerar vlida cualquier versin
superior de la recomendada.
20
El Registro de Indicadores y Medidas de la OMS es una fuente central de meta-datos que definen los indicadores
de salud utilizados por la OMS y otras organizaciones. Incluye definicin de indicadores, de fuentes de datos, de
mtodos de estimacin, y cualquier otra informacin que mejore el entendimiento de los indicadores.
85
7. Implementacin de DHIS2 para el caso de estudio en la
Regin de Loreto
Los dos captulos anteriores de este proyecto se han centrado primero en el estudio y descrip-
cin del sistema de salud en el que se quiere actuar, para pasar luego al anlisis en profundidad
de una herramienta de cdigo libre (DHIS2) en principio adecuada para llevar a cabo una mejora
en el sistema de informacin de salud descrito. En este captulo vamos a proceder a verificar la
idoneidad del uso de DHIS2 modelando varios de los procesos de captura, envo, procesado y
presentacin de informacin dentro del Sistema de Salud Peruano, y en concreto dentro de la
Direccin Regional de Salud de Loreto.
Hasta ahora hemos estudiando dnde y cmo se genera la informacin, quin debe interactuar
y tener acceso a ella o qu flujos debe seguir desde que es recogida en un puesto de salud hasta
que pasa a formar parte de un almacn de datos. Hemos estudiado la filosofa que gui la etapa
de diseo de DHIS2, las funcionalidades ms destacadas para el almacenamiento, procesado y
anlisis de informacin, y por ltimo las caractersticas tcnicas y requisitos necesarios para un
aprovechamiento ptimo de la herramienta.
Parece natural entonces, que el siguiente paso sea intentar combinar los conocimientos ad-
quiridos en ambos anlisis para ya proceder a verificar la viabilidad tcnica e institucional de
la herramienta. En este captulo se procede a configurar en la herramienta los flujos y procesos
de informacin identificados, tratando de reproducir, de la forma ms fiel posible, el Sistema
de Informacin de Salud estudiado. El objetivo no es otro que el de analizar hasta qu punto se
trata de dos realidades compatibles, hasta qu punto las caractersticas funcionales y tcnicas de
DHIS2 satisfacen las necesidades del Sistema de Informacin de Salud rural de la Regin de
Loreto.
Para ello, en primer lugar se explica el diseo del Sistema de Informacin de forma genrica,
la configuracin de los mdulos que forman la estructura del sistema, aquellos que compartirn
todos los sistemas o subsistemas de informacin que se implementen posteriormente, como son
la jerarqua de establecimientos, la gestin de usuarios y el mdulo de informacin geogrfica. A
continuacin se explica cmo se ha realizado el diseo de los subsistemas de informacin anali-
zados en el Captulo 521 , y cmo se les ha dado forma dentro del sistema DHIS2. Se har en tres
subapartados separados, uno para el diseo e implementacin del registro diario de actividades,
otro para la informacin individual de paciente del subsistema de vigilancia epidemiolgica, y
por ltimo, tambin dentro del subsistema de vigilancia epidemiolgica, otro que permite tratar
la informacin consolidada.
En los tres subapartados siguientes, quinto, sexto y sptimo de este captulo, revisaremos las
caractersticas ms potentes en el anlisis y representacin de datos de la herramienta. El diseo
en esta ltima seccin se ha llevado a cabo sin replicar los modelos de anlisis que se siguen
en el caso de estudio. Esto es debido a que no result posible realizar una identificacin en pro-
21
Identificacin del flujo de Informacin generada en el Sistema de Salud de Loreto.
86
fundidad de las necesidades en este aspecto, por lo que los ejemplos y acciones tomadas se han
basado en mostrar las caractersticas ms potentes de DHIS2.
El octavo subapartado contiene una verificacin de requisitos del sistema implementado, y en

el noveno y ltimo, se propone un nuevo modelo de formulario que unifica los tres subsistemas
de informacin que hemos diseado, minimizando al mximo el conjunto de datos a introducir
en el sistema, sin reducir la cantidad de informacin recogida.
7.1. Diseo del Sistema de Informacin

El proceso de implementacin de DHIS2 para la regin de Loreto se centr sobre todo en
torno a la creacin de la base de datos. Toda la informacin de diseo del sistema se encuentra
almacenada en la base de datos, que fue modelada para satisfacer las necesidades del caso de
estudio.
Las etapas de diseo estructural del sistema, como son el diseo de la jerarqua de estableci-
mientos, la configuracin del sistema de informacin geogrfico y la gestin de usuarios, sern
explicadas con detalle en este apartado.
7.1.1. La Jerarqua de Unidades Organizativas

El primer paso para la implementacin del sistema de informacin es la definicin de la je-
rarqua de unidades organizativas. Como vimos en el estudio del sistema de salud de Peru la
DIRESA de Loreto cuenta con 352 establecimientos de Salud de Primer Nivel, organizados en
Puestos y Centros de Salud, y distribuidos a lo largo de los 51 distritos.
Geogrficamente, el Departamento de Loreto se dividen en 7 provincias que a su vez se divi-

den en un total 51 distritos. A nivel del sistema de administracin de salud se dividen en 8 redes
y 36 microredes de salud.
Siguiendo las recomendaciones de diseo de HISP, la jerarqua de organizaciones establecida

ser la geogrfica, y para la divisin en redes y subredes se utilizarn los grupos y conjuntos de
grupos.
Pese a que el alcance de este proyecto es la Regin de Loreto, en la jerarqua geogrfica se

introdujo en el sistema informacin a nivel nacional para dar ms navegabilidad al mdulo SIG,
quedando registradas todas las regiones de Per, con sus correspondientes provincias y distritos.
Para el ltimo nivel, el de los establecimientos, solo se introdujo informacin de Loreto.
Unidades Organizativas
La introduccin de las unidades organizativas en el sistema se puede hacer de una en una a travs
87
de la interfaz22 (ver figura 20), o mediante una carga masiva directamente en la base de datos23 .
En nuestro caso se introdujeron a mano las unidades organizativas pertenecientes a la rama

que va desde el nivel nacional, Per, hasta los establecimientos de la Regin de Loreto. Para el
resto de regiones se introdujo directamente en la base de datos, siendo el resultado la estructura
de rbol que se puede observar en la figura 21.
Al introducir las unidades organizativas se ha seguido una nomenclatura para mantener ho-
mogeneidad en la base de datos.
El Nombre del establecimiento va precedido por el tipo de unidad organizativa (Regin,

Provincia, Distrito, Hospital, CS cuando se trata de un Centro de Salud, y PS cuando se
trata de un Puesto de Salud)
El Nombre Corto es igual al nombre, excepto en los centros y puestos que se suprime el
prefijo CS y PS.
El Cdigo es nico e identifica la regin, provincia, distrito y tipo de establecimiento.
La codificacin utilizada se llama UBIGEO y viene especificada por la Norma Tcnica So-
bre el Uso del Cdigo de Ubicacin Geogrfica [dSdP08]. El cdigo proporciona informacin
geogrfica y del tipo de establecimiento y se compone de 6 dgitos seguidos de una letra y tres
dgitos ms.
Las dos primeras cifras identifican la Regin, la tercera y cuarta la Provincia, la quinta y sexta
el Distrito, la letra A identifica que se trata de un establecimiento pblico, el dgito siguiente, el
octavo, indica qu tipo de establecimiento es (1-Hospital, 2-Centro de Salud, 3-Puesto de Salud),
y las dos ltimas son un contador incremental que diferencia dos establecimientos del mismo
tipo que pertenecen al mismo distrito.
Por ejemplo, segn la codificacin oficial, el cdigo 160201A321 nos dice que se trata de
un establecimiento de la Regin de Loreto (16), provincia del Alto Amazonas (02), distrito de
Yurimaguas (01) y que se trata de un establecimiento pblico(A), en concreto un puesto de salud
(3), y es el nmero 21 del distrito en cuestin.
22
En el men principal acceder a Mantenimiento ->Administracin de Unidades Organizativas ->Unidad Organi-
zativa y pulsar Aadir Nuevo
23
La tabla que almacena las unidades organizativas es la tabla organisationunit
88
Figura 20: Interfaz para la Creacin de Figura 21: Jerarqua Geogrfica de los
Unidades Organizativas Establecimientos de Salud de
Loreto
Niveles de Unidades Organizativas

La aplicacin permite la definicin de cinco niveles de unidades organizativas24 , que son los
mismos que nosotros necesitamos, por lo que se definieron los niveles nacional, regional, pro-
vincial, distrital y de establecimientos, como se puede ver en la figura 22.
24
En el men principal acceder a Mantenimiento ->Administracin de Unidades Organizativas ->Niveles de Unida-
des Organizativa
89
Figura 22: Definicin de los Niveles de Unidad Organizativa.
Conjuntos y Grupos de conjuntos de Unidades Organizativas

Con los conjuntos y grupos de conjuntos creamos otras dos clasificaciones de establecimientos,
una por tipo de establecimiento en la que se definen los tipos Centro de Salud y Puesto de Salud,
y otra en que se definen las redes y microredes de salud en que se organiza el sistema de salud
de la Regin de Loreto. Se puede ver una representacin grfica de las mismas en la figura 23.
90
Figura 23: Jerarqua de Redes y Microredes
91
7.1.2. Gestin de Usuarios
Para satisfacer las necesidades de un sistema como el planteado en este caso son necesarios, al
menos, tres tipos de usuario diferentes. Los tipos de usuario los definimos a travs de los roles de
usuario, a los que asignaremos los privilegios correspondientes a su tarea diaria. Posteriormente
al crear los usuarios les asignaremos el rol correspondiente.
En este diseo se han creado los roles Administrador, Personal Asistencial, y Tcnico Estads-
tico. El administrador dispone de todos los permisos, como es habitual. El Personal Asisten-
cial tiene los permisos relativos a la introduccin o actualizacin de valores de datos, todos los
relacionados con la gestin de pacientes, los de consulta del mdulo SIG, de acceso a la importa-
cin/exportacin de datos y el uso del mdulo de mensajes. En el caso del Tcnico Estadstico,
dispone de los mismos permisos que el anterior y adems puede manipular indicadores, grficos,
informes y todas las acciones relacionadas con el anlisis de datos, administrar los conjuntos de
datos, el mdulo SIG, bloquear y desbloquear datos, y consultar el mdulo de reglas de valida-
cin.
En el cuadro 9, se muestran en detalle los roles y permisos creados25 . Con esta configuracin
se consigue que el personal asistencial introduzca los datos directamente en la base de datos,
pueda gestionar pacientes y consultar informacin relativa a los mismos, as como tener acceso
a los anlisis de datos realizados y publicados por los estadsticos.
El tcnico estadstico podr hacer los mismo que el personal asistencial, pero adems tiene
permisos para realizar anlisis de datos y publicar tablas, informes o grficos. Tambin puede,
con la funcin de bloqueo y desbloqueo, evitar que se introduzcan datos fuera de plazo, o que se
modifiquen datos que se dan por consolidados.
Cuadro 9: Roles y Permisos de Usuario

Tcnico Estadstico Personal Asistencial Administrador
Aadir valor de dato Aadir valor de dato
Actualizar valor de dato Actualizar valor de dato Todos los privilegios
Eliminar valor de dato Eliminar valor de dato
Aadir paciente Aadir paciente
Actualizar paciente Actualizar paciente
Eliminar paciente Eliminar paciente
Aadir relacin de paciente Aadir relacin de paciente
Eliminar relacin de paciente Eliminar relacin de paciente
Acceso mdulo SIG Acceso mdulo SIG
Acceso mdulo Pacientes Acceso mdulo Pacientes
Enviar mensajes Enviar mensajes
Acceso mdulo importar/exportar Acceso mdulo importar/exportar
Acceso mdulo de entrada de datos Acceso mdulo de entrada de datos
Acceso mdulo de Reglas de Vali-
dacin
25
La totalidad de los privilegios disponibles se ha detallado con anterioridad en el cuadro 8
92
Tcnico Estadstico Personal Asistencial Administrador
Acceso mdulo de Integracin de
Cuadro de Mandos
Aadir indicador
Eliminar indicador
Actualizar indicador
Aadir tipo de indicador
Eliminar tipo de indicador
Actualizar tipo de indicador
Aadir grupos de indicadores
Eliminar grupos de indicadores
Actualizar Grupos de indicadores
Administrar constantes
Administrar mdulo SIG
Administrar bloqueo datos
Administrar desbloqueo datos
Aadir grficos
Eliminar grfico
Aadir informe
Eliminar informe
Aadir tabla de informe
Eliminar tabla de informe
7.1.3. Mdulo SIG

La configuracin del mdulo del Sistema de Informacin Geogrfica (SIG) es muy til para
la representacin de los datos, y a travs de l es sencillo hacerse una idea del estado de un cierto
indicador en una regin o comparar diferentes zonas del pas. Para su configuracin es necesario
disponer de los shapefiles de la zona a representar.
Shapefile es el formato estndar para el intercambio de informacin geogrfica entre dife-

rentes SIG. Se trata de un formato de almacenamiento digital donde se guarda la localizacin de
los elementos geogrficos y los atributos asociados a ellos. El formato no guarda informacin
topolgica, pero para nosotros no es necesaria.
El primer paso es conseguir los archivos de Per. Deberemos tener un archivo para cada nivel
a representar. Es decir, como lo queremos hacer a nivel nacional, necesitaremos tres archivos,
uno para cada nivel a representar, en este caso las regiones, provincias y distritos. Estos archivos
se encuentran disponibles para descarga en el servidor de informacin geogrfica del Gobierno
de Per26 .
Una vez descargados los archivos shapefile, lo recomendable es quitarles resolucin, pues
se trata de archivos en que las fronteras se representan de forma muy precisa y dado que los
26
http://geoservidor.minam.gob.pe/geoservidor/download.aspx
93
vamos a utilizar en una aplicacin web, es importante evitar sobrecargar el sistema. En nuestro
caso hemos realizado esta operacin utilizando una herramienta web27 , la cual nos permite re-
ducir en un 70 - 80 % el tamao del archivo.
Cuando los shapefile tienen el tamao y los nombres adecuados, debemos pasarla a formato
GML28 . Para ello se ha utilizado la herramienta ogr2ogr, disponible en casi todas las distribu-
ciones Linux. Se debe tener en cuenta tambin que hay que pasar el sistema de referencia a
EPSG:4326, que es el utilizado por google maps y por ende, nuestro sistema de representacin
geogrfica.
El ltimo paso es importar el archivo GML al sistema29 . Si los archivos se cargan con xito
ya se puede acceder al mdulo SIG30 y navegar por la geografa de Per representando valores
de indicadores o elementos de datos agregados para cada zona geogrfica. A modo de ejemplo
se muestra en la figura 24 el mapa completo de Per tal y como qued tras cargarlo en DHIS.
Es importante saber que cuando importemos los archivos en DHIS, la aplicacin buscar la
correspondencia entre los nombres de cada regin, provincia o distrito, definidos en los archivos
gml, con los nombres de unidades organizativas, por lo que debemos asegurarnos que los nom-
bres asignados son exactamente iguales a los nombres de las unidades organizativas que sean
regin, provincia o distrito. Para la edicin de los archivos se utiliz la herramienta Quantum-
GIS31 .
Figura 24: Navegabilidad del mdulo SIG
27
http://mapshaper.com/test/demo.html
28
Geography Markup Language: Es un sublenguaje de XML descrito para el modelaje, transporte y almacenamiento
de informacin geogrfica.
29
Men Principal: Servicios ->Importar/Exportar
30
Men Principal: Servicios ->SIG
31
http://www.qgis.org/
94
7.2. Diseo del Registro Diario de Atenciones
Para implementar el Registro Diario de Atenciones, en primer lugar tenemos que definir qu
informacin necesita recopilar el formulario mostrado en la figura 11 que se encuentra en el apar-
tado III, para posteriormente crear los elementos de datos necesarios para su almacenamiento en
la base datos.
7.2.1. Elementos de Datos

En primer lugar vemos que se trata de informacin individual, de paciente o actividad. Habr
una entrada en el formulario para cada visita o actividad llevada a cabo. Esto quiere decir que
alguna informacin se almacenar como atributos del paciente (la informacin personal) y otra
como elemento de datos de dominio Paciente32 (la informacin que se recoja del paciente en
cada visita). Mostramos en el cuadro 10 los datos a recoger y cmo sern representados en el
sistema.
En la columna Dato se especifican los campos a almacenar, detallados en el apartado de an-

lisis del subsistema de informacin. En la segunda columna, Tipo, se especifica de qu forma se
almacenan en la base de datos. Por ltimo en la columna Comentario se incluir la informacin
necesaria para terminar de explicar el modo de almacenamiento.
Los valores encontrados en la segunda columna pueden ser:
Elemento de Datos: Cuando hay que crear un elemento de datos para almacenar el valor.
Identificador de Beneficiarios: La aplicacin permite definir diferentes tipos de identifica-

dores nicos para los pacientes.
Atributo de Beneficiario Predefinido: Valores por defecto que hay que rellenar al crear un
paciente nuevo.
Atributo de Beneficiario: Si los valores por defecto son insuficientes, existe la posibilidad
de crear tantos atributos como sea necesario.
Cuando se deja en blanco se est indicando que los datos son almacenados automtica-
mente por la lgica interna del sistema, por el hecho de haber iniciado sesin, o por estar
trabajando con un beneficiario en concreto.
Cuadro 10: Representacin de la Informacin en la base de datos

Dato Tipo Comentario
Turno Elemento de Datos Hay que asociarlo a la categora Tipo de Turno con los
valores Maana y Tarde
32
Recordamos que los elementos de datos pueden ser de dominio Paciente para datos individuales asociados a una
persona o actividad, o de dominio Agregado, para almacenamiento de valores agregados.
95
Fecha - DHIS2 almacena la fecha automticamente.
Ubicacin Geogrfica - Se guardar automticamente el cdigo asignado al esta-
blecimiento de salud al crearlo.
Servicio Elemento de Datos Hay que asociarlo a la categora Tipo de Servicio que de-
fine todos los tipos de servicio disponibles.
Responsable de la Aten- - Ser el usuario que haya iniciado sesin.
cin
Nmero de Historia Cl- Identificador de Benefi- Se almacenar automticamente al identificar al usuario
nica o Familiar ciario del servicio.
Procedencia del Pacien- Atributo de Beneficiario Se almacenar automticamente al identificar al usuario
te del servicio.
Edad Atributo de Beneficiario Se almacenar automticamente al identificar al usuario
predefinido del servicio.
Sexo Atributo de Beneficiario Se almacenar automticamente al identificar al usuario
Condicin de Ingreso al Elemento de Datos Hay que asociarlo a la categora Condicin de Ingreso
Establecimiento que define los tipos Nuevo, Continuador, y Reingreso
Condicin de Ingreso al Elemento de Datos Hay que asociarlo a la categora Condicin de Ingreso
Servicio que define los tipos Nuevo, Continuador, y Reingreso
Diagnstico, Motivo Elemento de Datos -
Consulta
Diagnstico CIE 10 Elemento de Datos Hay que asociarlo a la categora Diagnstico CIE10, que
recoge tantos cdigos de enfermedad como precisemos
definir.
Tipo de Diagnstico Elemento de Datos Hay que asociarlo a la categora Tipo de Diagnstico que
define los tipos Presuntivo, Definitivo, y Repetidor.
Laboratorio Elemento de Datos Hay que asociarlo a la categora Tipo de Laboratorio que
define todos los tipos de servicio disponibles.
Al crear los elementos de datos33 se debe prestar especial atencin en dos campos, el Domi-
nio, que como hemos dicho antes, en este caso es de paciente, y el Tipo de valor a almacenar.
El dominio, porque si no especificamos que es de paciente, no nos ser posible usarlo despus
para el clculo de agregados. El Tipo, porque en aquellos casos en que se trate de un Elemento
de Datos que tome valores predefinidos especificados en una categora (por ejemplo el Campo
Turno, que toma los valores maana y tarde), hay que seleccionar el tipo texto, de otro modo no
mostrar las opciones como desplegable en los formularios de entrada.
Por ltimo hay que especificar el operador de agregados, que para nosotros ser en todos los
casos el operador suma.
En el caso del identificador nico de beneficiario34 , al definirlo debemos especificar el nom-

33
Men Principal: Mantenimiento ->Elementos e Indicadores de Datos ->Elementos de Datos, pulsar Aadir Nuevo
34
Men Principal: Mantenimiento ->Beneficiarios y Programas ->Tipo de Identificador de Beneficiario, pulsar Aa-
dir Nuevo
96
bre y descripcin, si es obligatorio al introducir un paciente en el sistema, de cuntos caracteres
se compone y de qu tipo es.
En cuanto a los atributos de beneficiario35 que necesitemos aadir en el sistema sern so-
licitados al crear un nuevo paciente, en la pantalla de registro. Su creacin es muy similar a la
del identificador. Debemos especificar el nombre y descripcin, si es obligatorio al introducir un
paciente en el sistema, de cuntos caracteres se compone y de qu tipo son, y adems deberemos
especificar si se hereda cuando los pacientes tienen la relacin padre-hijo.
7.2.2. Definicin del Programa

Siempre que hablamos de recoger informacin personal de paciente debemos pensar autom-
ticamente en definir un programa, pues es la nica va de introducir datos de paciente.
Recordemos que en el registro diario de atenciones, el paciente acude espontneamente al

establecimiento de salud, por lo que la visita no forma parte de una planificacin o seguimiento.
Adems el paciente puede acudir tantas veces como lo necesite.
El programa que se adeca perfectamente a este modelo es el Programa Basado en Encuen-

tros, pero ya que no est implementado todava debemos implementarlo con un Programa Ba-
sado en Etapas, en el cual definiremos una nica etapa, la visita al centro.
Procedemos a definir el programa a travs de la pantalla de administracin de programas36 como
se aprecia en la figura 25.
Figura 25: Pantalla de Creacin de Programas
Ntese que no se marca la casilla de single event, ya que esto lo convertira en un Programa
de Evento Aislado.
El campo Numero mximo de das en que se permite introducir datos se define para aquellos
programas en que las visitas estn programadas con un periodo de tiempo fijo entre ellas. Por
35
Men Principal: Mantenimiento ->Beneficiarios y Programas ->Atributos de Beneficiario, pulsar Aadir Nuevo
36
Men Principal: Mantenimiento ->Beneficiarios y Programas ->Programas pulsar Aadir nuevo
97
ejemplo: la segunda visita ser siempre dos semanas despus de la primera. Su funcin en estos
casos es la de establecer un mximo de das en que se permite introducir datos para una visita.
Una vez ha pasado la fecha programada, no se podr introducir ese dato.
Una vez creado el programa debemos asignarle las unidades organizativas que podrn utilizar-
lo y definir sus etapas. Para acceder a estas secciones debemos utilizar los iconos que aparecen
al lado del programa en la pantalla de administracin de programas.
Figura 26: Pantalla de Administracin de Programas
Con la asignacin de unidades organizativas restringimos qu establecimientos podrn dar de

alta pacientes en el programa. En nuestro caso son todos los establecimientos.
En las etapas definimos la nica etapa de que consta el programa, que es la visita del pa-
ciente o actividad de salud. Al crear la etapa debemos asignarle obligatoriamente un nombre y
descripcin y a continuacin seleccionar aquellos elementos de datos que sern utilizados pa-
ra almacenar algn valor. Deberemos seleccionar aquellos elementos de datos que previamente
creamos, los especificados en la tabla 10.
98
Figura 27: Pantalla de Creacin de Etapas
7.2.3. Formulario de Entrada

El siguiente paso es el diseo del formulario de entrada de datos, que es la ventana que ver
el personal asistencial cuando tenga que introducir los datos. Para acceder al mismo debemos
utilizar el ltimo icono que aparece al lado de la etapa.
Figura 28: Pantalla de Administracin de Etapas
En nuestro caso utilizaremos un formulario de entrada personalizado. Una forma muy sencilla
de hacerlo es disearlo en una hoja de clculo y a continuacin copiarlo y pegarlo.
En la pantalla de diseo de formulario disponemos de un editor HTML en el que deberemos

pegar el formulario copiado de la hoja de clculo. Una vez hecho eso, debemos asignar a cada
celda en blanco un elemento de datos en el que se almacenar en la base de datos el valor escrito
en ella.
Para ello se debe pulsar el botn Elementos de Datos que abre una ventana con los elementos
de datos disponibles, que son aquellos que hemos seleccionado previamente al crear la etapa.
99
Figura 29: Pantalla de Edicin del Formulario de Entrada de Datos
Vemos a continuacin, en la figura 30, cmo queda el formulario para un paciente determina-
do. Una vez seleccionado el paciente, deberemos seleccionar el programa, en el cual el paciente
deber ser registrado previamente. Por tratarse de un programa con una sola etapa, esta ser se-
leccionada por defecto.
Una vez completado este proceso, el programa se encuentra listo para ser utilizado y empezar
a almacenar informacin de la actividad diaria de los establecimientos.
100
Figura 30: Resultado Final del Formulario de Entrada de Datos
El caso del Sistema de Vigilancia Epidemiolgica, que vamos a disear en el siguiente

apartado, es un poco ms complejo. En l se recoge tanto informacin de paciente como datos
agregados. Recordamos la clasificacin de los documentos de recogida de datos del Sistema de
Vigilancia Epidemiolgica indicando el tipo de informacin recopilada en casa caso.
Figura 31: Tipo de Informacin del Sistema de Vigilancia Epidemiolgica
101
Para explicarlo de un modo ordenado y sencillo se ha decidido separar la explicacin de su
diseo en dos partes, una para los informes de enfermedades o eventos de notificacin individual,
y otra para el informe enfermedades o eventos de notificacin consolidada en el que se recogen
datos agregados.
7.3. Diseo del Sistema de Vigilancia Epidemiolgica - Datos de

Paciente
Recordemos que tanto el Registro Semanal de Notificacin Individual como las Fichas de In-
vestigacin Clnico-Epidemiolgicas recogen informacin de forma puntual y no programada,
es decir, cuando se detecte un posible caso de alguna de las patologas sujetas a esta vigilancia
(ver cuadro 3) se inscribir al paciente en el Registro de Notificacin Individual, y cuando sea
necesario se proceder tambin a rellenar su Ficha de Investigacin.
Este modelo es exactamente igual que el del Registro Diario de Informacin Clnica, por lo
que se puede emplear la misma lgica en su diseo.
En el caso de la Ficha de Investigacin, no se dispone de ningn formato genrico, sino que

las fichas son especficas para cada patologa. Dado que funcionalmente tienen exactamente los
mismos requisitos que el subsistema de vigilancia y el de vigilancia epidemiolgica individual,
no ser detallado su diseo en este documento. S se encuentra implementada en el sistema de
prueba la ficha de investigacin Influenza y Otros virus respiratorios (OVR), Infeccin Respira-
toria Aguda Grave (IRAG), IRAG Inusitada y muerte por IRAG.
Para la implementacin de este programa procedemos en primer lugar a la identificacin de

la informacin a recoger. Posteriormente se define un programa de tipo Programa de Evento
Aislado, y por ltimo se disea el formulario de entrada.
Pese a que el Programa de Evento Aislado no satisface los requisitos de este caso, nos parece
interesante darlo a conocer, pues el mtodo de entrada de datos no requiere dar de alta al usuario
previamente en el sistema. Esta es su aportacin ms importante frente al programa de una sola
etapa. Se recomienda el uso del Programa Basado en Encuentros cuando ste sea implementado.

Para la representacin de la informacin y su definicin como elementos del sistema se pre-
senta una cuadro anlogo al cuadro 10.
102
DIRESA - Se almacenar automticamente al iniciar sesin.
Red - Se almacenar automticamente al iniciar sesin.
Establecimiento - Se almacenar automticamente al iniciar sesin.
Semana de Notificacin - Se almacenar automticamente al iniciar sesin.
Apellidos y Nombre Atributo de Beneficiario Se almacenar automticamente al identificar al usuario
Edad Atributo de Beneficiario Se almacenar automticamente al identificar al usuario
Sexo Atributo de Beneficiario Se almacenar automticamente al identificar al usuario
Lugar de Infeccin Elemento de Datos -
Diagnstico CIE 10 Elemento de Datos Hay que asociarlo a la categora Diagnstico CIE10, que
recoge tantos cdigos de enfermedad como precisemos
definir.
Tipo de Diagnstico Elemento de Datos Hay que asociarlo a la categora Tipo de Diagnstico que
define los tipos Confirmado, Probable, y Descartadp.
Protegido Vacuna Elemento de Datos El tipo de elemento deber ser Si/No.
Fecha Inicio Sntomas Elemento de Datos El tipo de elemento deber ser Fecha.
Fecha Notificacin - Se toma como fecha de Notificacin la fecha de entrada
de los datos en el sistema.
Fecha Defuncin Elemento de Datos El tipo de elemento deber ser Fecha.
Ficha de Investigacin Elemento de Datos El tipo de elemento deber ser Si/No.
7.3.2. Definicin del Programa

La solucin que cumple los requisitos de este programa es, como hemos dicho antes, la crea-
cin de un programa con una sola etapa en el que se inscribir al paciente como posible caso de
infeccin, se rellenar a continuacin informacin correspondiente a la nica etapa y el progra-
ma se dar por terminado. Aun as, para navegar un poco ms en las posibilidades de DHIS2 se
ha utilizado en este caso un programa del tipo single-event, que tiene las mismas caractersticas,
pero el proceso de entrada de informacin es ms corto.
El motivo por el que este programa no cumple los requisitos es que, por su filosofa de dise-
o, solo permite inscribir una vez a cada paciente. Est diseado considerando que se trata de
eventos que slo pueden suceder una vez en la vida.
103
Figura 32: Pantalla de Creacin de Programas - Evento Simple
La creacin del programa es exactamente igual que en el caso anterior, solo que ahora s debe-
remos marcar la casilla single event. Al hacerlo desaparece la casilla de Descripcin de la Fecha
de Alta en el Programa, ya que ese concepto desaparece en este tipo de programas.
El Programa de Evento Aislado o single-event, no requiere de la creacin de etapas, sino que

el sistema crea automticamente la nica etapa que tiene. El siguiente paso es la asociacin con
las unidades organizativas que podrn hacer uso de l y la asignacin de los elementos de datos
que queremos que estn disponibles para el formulario de entrada.
Vemos en la siguiente figura la pantalla de asociacin de programas con unidades organizati-

vas.
104
Figura 33: Pantalla de Asignacin de Unidades Organizativas a Programas
Es en este tipo de selecciones, al navegar la jerarqua de unidades organizativas, cuando ve-

mos lo til de la definicin de niveles de jerarqua y de grupos de unidades organizativas. En
este caso, que queremos seleccionar todos los establecimientos de salud, seleccionamos el nivel
Establecimientos y pulsamos Seleccionar Nivel. Quedarn seleccionados todos los estableci-
mientos de salud, tanto centros como puestos. Podramos hacer lo mismo utilizando los grupos
que hemos definido, que son las micro redes de salud, y los tipos de establecimiento. Una vez
hecho esto, todos los centros y puestos de salud tendrn acceso a este programa.
7.3.3. Formulario de Entrada

En este caso, tambin para explorar con ms profundidad las funciones de DHIS2, empleare-
mos el formulario por defecto.
La creacin de este formulario no requiere nada ms que la seleccin de los elementos de da-
tos disponibles para la etapa nica. Una vez seleccionados, el sistema crear un formulario por
defecto, que no es ms que un listado de ese grupo de elementos, acompaados por una casilla
en blanco en la que introducir el valor correspondiente.
Se muestra en la siguiente figura cmo quedara el formulario por defecto37 en este caso.
37
La ltima columna se introdujo en la herramienta porque se detect la necesidad de marcar si la informacin era
proporcionada por la unidad que haba iniciado sesin, o si por el contrario se estaba introduciendo informacin
de otro centro. En nuestro caso no es necesario su uso.
105
Figura 34: Ejemplo de formulario por defecto para la entrada de datos
7.4. Diseo del Sistema de Vigilancia Epidemiolgica - Datos

Agregados
Hay una serie de enfermedades o eventos para los cuales se recogen datos epidemiolgicos
agregados con periodicidad semanal. Es decir, todos los establecimientos de salud deben, cada
semana, rellenar un informe con los totales de aquellos casos o eventos que se hayan producido
durante la semana. Los casos y eventos estn detallados en el cuadro 4.
En este caso los datos no tienen vnculo alguno con la informacin de paciente, por lo que
no es necesaria la creacin de un programa. Cuando se habla de recoger informacin agregada,
nmero de casos, totales, subtotales, en DHIS2 debemos pensar en trabajar con Conjuntos de
Datos38 .

Como en los otros casos, en primer lugar identificamos la informacin que deberemos alma-
cenar en la base de datos, para posteriormente crear los elementos necesarios.

DIRESA - Se almacenar automticamente al iniciar sesin.
Red - Se almacenar automticamente al iniciar sesin.
Establecimiento - Se almacenar automticamente al iniciar sesin.
38
Es importante recordar de nuevo que no se debe confundir Conjuntos de Datos con Conjuntos de Grupos de
Elementos de Datos.
106
Semana de Notificacin - Se almacenar automticamente al iniciar sesin.
Enfermedad Diarreica Aguda
Casos Diarrea Elemento de Datos Hay que asociarlo a la categora Edad - EDA en la que se
definen los grupos de edad que requiere el formulario.
Defunciones Diarrea Elemento de Datos Hay que asociarlo a la categora Edad - EDA en la que se
Hospitalizados Diarrea Elemento de Datos Hay que asociarlo a la categora Edad - EDA en la que se
Casos Disentera Elemento de Datos Hay que asociarlo a la categora Edad - EDA en la que se
Defunciones Disentera Elemento de Datos Hay que asociarlo a la categora Edad - EDA en la que se
Hospitalizados Disentera Elemento de Datos Hay que asociarlo a la categora Edad - EDA en la que se
IRAS, ASMA y SOB
Casos Iras Elemento de Datos Hay que asociarlo a la categora Edad-IRAS/NEUM en la
que se definen los grupos de edad que requiere el formu-
lario.
Neumona Casos-Severidad Elemento de Datos Hay que asociarlo a la combinacin de categoras Edad-
Severidad NEUM en la que se combinan las categoras
Edad-IRAS/NEUM, que define los grupos de edades, y
Severidad-NEUM, que define los niveles de severidad.
Neumona Defunciones Elemento de Datos Hay que asociarlo a la combinacin de categoras Edad-
LugarDef NEUM en la que se combinan las categoras
Edad-IRAS/NEUM, que define los grupos de edades y
LugarDef-NEUM, que define la defuncin intra y extra
hospitalaria.
Neumona Hospitalizacin Elemento de Datos Hay que asociarlo a la categora Edad-IRAS/NEUM en la
lario.
SOB/ASMA Casos Elemento de Datos Hay que asociarlo a la categora Edad-SOB/ASMA en la
lario.
Malaria
Casos Malaria Confirmados Elemento de Datos
P.Vivax
Como se observa en el cuadro, no se ha creado un elemento de datos por cada casilla del
formulario (ver figura 36), sino que se ha creado un elemento de datos para cada valor que se
pueda mostrar como un total, y se han utilizado las categoras para los subtotales del mismo.
Por ejemplo, en el caso de la Neumona se ha creado un elemento de datos para los casos, uno
para las hospitalizaciones y uno para las defunciones. Luego son las categoras las que permiten
diferenciar entre casos de diferentes edades y diferentes severidades, entre hospitalizaciones por
edades y entre defunciones por edades y por lugar dnde se da la defuncin.
107
7.4.2. Conjunto de Datos, Formulario de Entrada y Reglas de Validacin
Como decamos al empezar a definir este caso, para datos agregados trabajaremos con con-
juntos de datos. Para ello basta con crear el conjunto de datos39 , darle un nombre y descripcin,
y asignarle una periodicidad de rellenado. A continuacin se disea el formulario de entrada, y
se le asignan los elementos de datos correspondientes e indicadores si se desea.
Creamos en este caso el conjunto de datos Notificacin Epidemiolgica Semanal - Agregados,

a travs del cual entrarn al sistema los datos agregados de EDA, IRAS, ASMA y Malaria.
El siguiente paso es asignarlo a todos los establecimientos de salud. Este paso es idntico al
caso de los programas, por lo que ser idntico a como hemos visto antes en la figura Pantalla
de Asignacin de Unidades Organizativas a Programas, que es la nmero 33.
Figura 35: Creacin de un Conjunto de Datos
Formulario de Entrada
Es un buen ejemplo para replicar en el sistema uno de los formularios utilizados en papel, por
lo que primero lo diseamos en una hoja de clculo, para posteriormente copiarlo y pegarlo en
el editor de formularios como ya vimos en la figura 29.
Mostramos a continuacin el proceso en imgenes. En primer lugar vemos el formulario ori-

ginal en papel escaneado, a continuacin vemos la rplica de este en una hoja de clculo, y por
ltimo el resultado obtenido al pegarlo en el editor HTML.
39
Men Principal: Mantenimiento ->Conjuntos de Datos
108
Ntese que en la segunda figura se han eliminado las dos primeras columnas de los tres cua-
dros en que se divide el formulario. Esto es debido a que almacenaban informacin de la ubica-
cin geogrfica, que asumimos se registra de forma automtica por haber iniciado sesin en el
sistema.
En la ltima figura, debemos indicar que en cada una de las celdas en blanco habremos asig-
nado, tambin desde la pantalla de edicin del formulario de entrada, los elementos de datos con
la opcin de categora correspondiente a cada una.
Figura 36: Diseo de Formulario - Paso 1
109
Los datos recogidos por este formulario son exclusivamente datos agregados, por lo que po-
dran ser calculados a partir de datos de paciente. Ms adelante se explican los pasos a seguir
para llevar a cabo el clculo de agregados. En este apartado se ha respetado el formato original
de recogida de datos porque se est realizando una implementacin del sistema que emule su
funcionamiento actual.
Reglas de Validacin
Centrndonos en la primera tabla del formulario, la de enfermedades diarreicas, vemos que se
definen casos, hospitalizaciones y defunciones. Una regla que se podra aplicar es la de que el
nmero de casos debe ser igual o menor al numero de hospitalizaciones. Procedemos entonces
a la definicin de la regla 40 , la cual utilizaremos como ejemplo en todo el proceso de creacin.
40
Men Principal: Servicios ->Calidad de Datos ->Regla de Validacin pulsar Agregar Nuevo
110
Recordemos que las reglas de validacin van asociadas a elementos de datos. Cuando las lan-
cemos desde el formulario de entrada de un conjunto de datos, se lanzarn nicamente aquellas
que afecten a los elementos de datos asociados al conjunto en cuestin.
Vemos en la figura 39 la ventana de creacin, donde definimos el nombre y descripcin, edi-

taremos ambas partes de la expresin, y seleccionamos el operador relacional a emplear, que en
este caso ser mayor o igual.
Figura 39: Creacin de una Regla de Validacin
Para la edicin de la parte izquierda y derecha de la expresin, al pulsar el botn correspon-

diente se nos muestra la ventana de la figura 40, en la que seleccionamos el elemento de datos a
utilizar, o construimos la expresin compuesta de elementos de datos cuando proceda.
En nuestro caso, considerando que estamos en la parte izquierda de la expresin y que que-
remos definirla para edades de 1 a 4 aos, seleccionamos el elemento de datos Diarreica-Casos
(1-4 a). Cuando definamos el lado derecho el elemento de datos ser Diarreica-Hospital (1-4 a).
Si, por ejemplo, quisiramos una regla para el total de casos en todos los rangos de edad, en
el lado izquierdo construiramos la expresion Diarreica-Casos (1-4 a) + Diarreica-Casos (5 a
+) + Diarreica-Casos (<1 a), y en el lado derecho crearamos la misma expresin pero con las
hospitalizaciones.
A continuacin se muestra cmo quedara la pantalla de administracin de reglas tras crear las
tres reglas que hay, que completan esta comprobacin en sus diferentes grupo etarios (figura 41).
111
Por ltimo, en la figura siguiente (figura 42), vemos el resultado de lanzar las reglas contra
unos datos errneos introducidos en el formulario de datos de Notificacin Epidemiolgica Se-
manal - Agregados. Para lanzar las reglas basta con pulsar el botn Correr Validacin que se
encuentra en la pantalla de entrada de datos.
Figura 40: Edicin del lado Izquierdo de una Expresin de Validacin
Figura 41: Reglas de Validacin
112
Figura 42: Ventana de Resultados del Proceso de Validacin
7.5. Clculo de Datos Agregados desde Datos de Paciente

El clculo de datos agregados, desde los datos de paciente introducidos en el sistema, es
una de las caractersticas ms potentes del modulo de paciente. Para obtener valores agregados
debemos seguir varios pasos:
1. Crear un elemento de datos, de dominio Agregados, en el cual se almacenar el valor nu-

mrico calculado. Por ejemplo, Casos de Malaria registrados en el Sistema de Vigilancia
Epidemiolgica Individual.
2. El elemento de datos debe pertenecer a un grupo de elementos de datos. En nuestro sistema

tenemos el grupo Agregados para este tipo de elementos de datos.
3. El elemento de datos debe pertenecer tambin a un grupo de Conjunto de Datos. En nues-

tro sistema tenemos el Conjunto de Datos Agregados para este tipo de elementos de datos.
4. Crear en el Constructor de Consultas de Agregacin41 una consulta que cuente todos

los casos que cumplan la condicin que buscamos y asociarla con el elemento de datos
previamente creado. En nuestro caso, haremos una consulta que seleccione todos los pa-
cientes que han sido registrados en el programa de Vigilancia Epidemiolgica Individual
con diagnstico de Malaria.
5. Ejecutar la agregacin42 para que los datos sean calculados y almacenados en la base de
datos.
Una vez realizados todos los pasos, el valor estar disponible para su uso en grficos, informes,
o representacin en el SIG. Es muy importante destacar que, al calcular los datos, se puede
41
Men Principal Mantenimiento ->Beneficiarios y Programas ->Constructor de Consultas de Agregacin
42
Men Principal Servicios ->Registro de datos individuales de Paciente ->Agregacin de Beneficiarios
113
consultar cules son los pacientes individuales de los que se ha obtenido el valor numrico
agregado.
Vemos, por ejemplo, los casos de malaria registrados43 en la provincia de Requena durante
un da determinado de 2009. Esta ventana se abre al hacer click sobre un determinado valor
numrico de entre los calculados por la aplicacin.
Figura 43: Detalle de la informacin de paciente
7.6. Creacin de Indicadores

7.6.1. Tipos de Indicadores
El primer paso para la definicin de indicadores es que se encuentren previamente definidos
los distintos tipos de indicadores que vamos a utilizar.
Como vemos en la figura, lo importante de esta definicin es el factor que se emplear en el

clculo de los mismos.
43
Se trata de datos de ejemplo introducidos manualmente en la base de datos
114
Figura 44: Crear Tipo de Indicador
Para nuestro caso vamos a definir cuatro tipos de indicadores44 ; Nmero, Por Cien, Por Mil,
Por Cien Mil, que son los factores que se utilizan tpicamente para datos estadsticos.
Figura 45: Distintos Tipos de Indicadores
Tambin es importante el uso de las constantes. En este caso hemos creado la constante Pobla-
cin de Loreto, la cual tiene el valor 983.37145 y podr ser utilizada para el clculo de porcentajes
sobre la poblacin total. As mismo se podra introducir la poblacin de cada uno de los distritos.
44
Men Principal Mantenimiento ->Elementos de Datos e Indicadores ->Tipo de Indicador
45
Habitantes de Loreto en 2010
115
7.6.2. Indicadores
Podemos ahora proceder a crear los indicadores46 . Crearemos como ejemplo seis indicadores,
tres para los datos agregados introducidos por la pantalla de entrada de datos, y otros tres para
datos calculados a partir de datos individuales del Programa de Vigilancia Epidemiolgica Con-
solidada - Individual.
Los indicadores utilizados en este ejemplo son:

Porcentaje, del total registrado, de Casos de EDA en nios menores de 1 ao.
Porcentaje, del total registrado, de Casos de EDA en nios de entre 1 y 4 aos.
Porcentaje, del total registrado, de Casos de EDA en nios de 5 aos o ms.
Porcentaje, de la Poblacin total de Loreto, de casos de Malaria registrados.
Porcentaje, del total de casos registrados, de casos de Hepatitis B en mujeres.
Porcentaje, del total de casos registrados, de casos de Hepatitis B en hombres.
Para crear un indicador debemos, asignarle un nombre intuitivo, seleccionar qu tipo de indi-
cador ser de entre los previamente definidos, y por ltimo definir el numerador y denominador
correspondiente.
Figura 46: Crear Indicador
En la siguiente tabla vemos cmo se han creado los indicadores en nuestro caso, los valores
que se han asignado al numerador y denominador y qu tipo de valor son:
46
Men Principal Mantenimiento ->Elementos de Datos e Indicadores ->Indicador
116
Cuadro 13: Definicin de Indicadores
Indicador Descripcin Nume- Tipo Numera- Descripcin Deno- Tipo Denomina-
rador dor minador dor
% Casos EDA - <1 a Casos EDA <1 ao Elemento de Da- Total Casos EDA Elemento de Da-
tos tos
% Casos EDA - 1-4 a Casos EDA 1-4 aos Elemento de Da- Total Casos EDA Elemento de Da-
tos tos
% Casos EDA - 5 a + Casos EDA 5 aos o Elemento de Da- Total Casos EDA Elemento de Da-
ms tos tos
% Casos Malaria Casos de Malaria Elemento de Da- Poblacin total de Constante
tos Loreto
% Hepatitis A - Mujeres Casos de Hepatitis A Elemento de Da- Total Casos Hepatitis Suma de Elemen-
en mujeres tos A tos de Datos
% Hepatitis A - Hom- Casos de Hepatitis A Elemento de Da- Total Casos Hepatitis Suma de Elemen-
bres en hombres tos A tos de Datos
Con los indicadores aqu definidos se crearn los grficos de ejemplo que se explican en el
siguiente apartado.
7.7. Grficos, Mapas y Cuadro de Mandos

7.7.1. Creacin de Grficos
En la interfaz de creacin de grficos47 se permite la creacin de nueve tipos de grficos
distintos. Con el tipo no nos referimos al modo en que la informacin ser representada, sino a
qu informacin se representa, veamos los distintos tipos para entenderlo mejor:
Indicador por Perodo: Se deben seleccionar los perodos e indicadores a representar y se

filtrar la informacin por unidad organizativa.
Indicador por Unidad Organizativa: Se deben seleccionar los indicadores y unidades or-
ganizativas a representar. Se filtrar la informacin por perodo.
Elemento de Datos por Perodo: Se deben seleccionar los perodos y elementos de datos a
representar. Se filtrar la informacin por unidad organizativa.
Elemento de Datos por Unidad Organizativa: Se deben seleccionar los elementos de datos
y unidades organizativas a representar. Se filtrar la informacin por perodo.
Completitud por Perodo: Se debe seleccionar los conjuntos de datos y perodos a repre-
sentar. Se filtrar la informacin por unidad organizativa.
Completitud por Unidad Organizativa: Se deben seleccionar los conjuntos de datos y uni-
dades organizativas a representar. La informacin se filtrara por perodo.
47
Men Principal: Servicios ->Informes ->Grficos
117
Perodo por Indicador: Se deben seleccionar los indicadores y perodos a representar. La
informacin se filtrar por unidad organizativa.
Perodo por Elemento de Datos: Se deben seleccionar los elementos de datos y perodos a
representar. La informacin se filtrar por unidad organizativa.
Perodo por Completitud: Se deben seleccionar los conjuntos de datos y perodos a repre-
sentar. La informacin se filtrar por unidad organizativa.
En cuanto al modo en que se representa la informacin, podemos elegir entre grfico de barras,
grfico de lneas, grfico de barras apiladas, o grfico circular. Todos ellos en modo normal o 3D.
En este caso hemos creado cuatro grficos que detallamos en el siguiente cuadro. Estos grfi-
cos se muestran en el cuadro de mandos, como se ver ms adelante.
Cuadro 14: Creacin de Grficas

Nombre Tipo de Grfica Informacin Representada
Casos de malaria por pro- Elemento de Datos por Unidad Or- Elemento de datos que almacena el valor
vincias ganizativa / Grfico de Barras agregado de casos de malaria para las siete
provincias de Loreto durante el ao 2008.
Casos EDA por edades y se- Indicador por Perodos / Grfico Los tres indicadores que almacenan los
manas Circular porcentajes de casos de EDA por grupos
etreos, para las tres primeras semanas de
2012 y para el Distrito de Balsapuerto.
Completitud por Estableci- Completitud por Unidad Organiza- El Conjunto de Datos de Notificacin Epi-
mientos - Alto Amazonas tiva / Grfico de Barras 3D demiolgica Semanal Consolidada, para
los seis distritos de la Provincia del Alto
Amazonas, la tercera semana de 2012.
Distribucin Hepatitis A Indicador por Unidad Organizativa Los dos indicadores que contienen los por-
por Sexo y Provincia / Grfico Circular 3D centajes de incidencia de Hepatitis A en
hombres y mujeres, para las siete provin-
cias de la Regin de Loreto, para el ao
2008.
La pantalla de creacin de grficos es bastante compleja. Se muestra en la figura 47 la pantalla

de creacin del grfico Casos EDA por Edades y Semanas.
118
119
Figura 47: Pantalla de Creacin de Grficas

7.7.2. Creacin de Mapas
En el mdulo SIG, previamente configurado, podemos representar con escalas de colores so-
bre el mapa, los valores almacenados tanto en los indicadores, como en los elementos de datos,
para las diferentes regiones que hemos definido, que en nuestro caso son las regiones, provincias
y distritos de Per.
Como indicamos anteriormente, se han cargado en el sistema datos de todas las regiones, pro-
vincias y distritos de Per, pero solamente se cargaron los establecimientos de salud de la Regin
de Loreto. Ser esta regin la nica que tendr valores a representar, ya que la informacin, los
datos, estn siempre asociados a un establecimiento de salud.
Para crear un mapa hay que especificar qu valor se va a mostrar, si es un indicador o un

elemento de datos, y cul de ellos en concreto se representar. Se definir tambin el tipo de
perodo para el cual se quieren agregar los valores, y se seleccionar el perodo en cuestin.
El siguiente paso es la configuracin de la leyenda, los colores a utilizar, nmero de subdivi-

siones entre los valores extremos y modo en que se realiza la divisin.
En cuanto a las reas de representacin, debemos especificar el nivel de jerarqua para el que
queremos representar los valores, y por ltimo seleccionar la unidad organizativa padre de la
representacin, es decir, para qu rea queremos visualizar los datos.
Vemos en la figura 48 la pantalla de creacin de un mapa.
En este caso hemos seleccionado mostrar el indicador de %Porcentaje de Casos de Malaria,

para el perodo anual de 2009. La configuracin de leyenda la hemos dejado como vena por
defecto y por ltimo hemos seleccionado representar los datos a nivel regional y desde el nodo
padre Per, es decir, que devolver un mapa en que se muestren los datos de este indicador para
todas las regiones de Per, durante el ao 2009. Como ya sabemos solo nos devolver datos en
la Regin de Loreto.
En la figura 49, vemos el mapa resultante, as como los mapas que obtenemos al navegar en
la Regin de Loreto, y posteriormente en la Provincia de Maynas.
120
Figura 48: Pantalla de Creacin de Mapas
Figura 49: Incidencia de Malaria en Per - Loreto - Maynas
Para mostrar los mapas en el Cuadro de Mandos es necesario guardarlos como favoritos y
marcarlos como aadidos en la ventana de administracin de favoritos del mdulo SIG.
121
7.7.3. El Cuadro de Mandos
El cuadro de mandos es uno de los recursos ms llamativos de DHIS2. En nuestro caso lo
hemos configurado para que aparezca como pgina principal48 .
Como ya vimos, el cuadro de mandos est pre-estructurado y se divide en dos secciones prin-
cipales: En la columna izquierda de la pantalla se ubican enlaces a informes, documentos,
tablas, o vistas de mapas en la parta superior, y un mdulo RSS de salud en la parte inferior. En
nuestra configuracin hemos publicado en pa parte superior los mapas, en el medio el RSS de
salud, y en la inferior enlaces a documentos publicados por la DIRESA. Estos documentos han
sido subidos al sistema previamente como informes estticos49 .
La columna derecha, que ocupa aproximadamente dos tercios de la pantalla, es donde se

muestran las grficas. En nuestro caso mostramos las cuatro grficas creadas en el apartado co-
rrespondiente.
El resultado final, que aparecer en la pantalla de inicio de la herramienta es el siguiente:
Figura 50: Cuadro de Mandos
48
Disponible en las opciones de configuracin del sistema.
49
Men Principal Servicios ->Informes ->Informe Esttico
122
7.8. Verificacin de Requisitos del Sistema
En este apartado haremos un repaso por los requisitos del Sistema de Informacin, y a conti-
nuacin, para cada uno de ellos, se har un pequeo anlisis de cmo DHIS2 satisface o no las
necesidades descritas.
7.8.1. Requisitos No Funcionales

Los requisitos no funcionales del sistema50 se presentan de modo genrico, son compartidos
por los dos subsistemas que se intentan emular en este proyecto, pues vienen establecidos por el
entorno fsico comn en que ambos deben ser instalados.
Segn el Informe sobre la Identificacin del uso de un SIS en los establecimientos mdicos
aislados de la regin de Loreto [Gar10] para la implantacin de un sistema de informacin con
xito se deben satisfacer los siguientes requisitos:
1. Aplicacin web o distribuida. Dada la aislada distribucin de los establecimientos de

salud y su estructuracin en redes y microredes de salud (que son a su vez redes y micro-
redes de informacin), es fundamental que se pueda acceder al sistema desde diferentes
ubicaciones fsicas y que compartan informacin, con la finalidad de coordinar e inter-
cambiar datos entre los diferentes establecimientos. Esto hace imprescindible el uso de
una herramienta software que comparta un sistema de gestin de informacin comn.
Por tratarse de una herramienta web no presenta ningn problema en este aspecto.
El hecho de que posea tambin una versin de escritorio con herramientas para la
exportacin e importacin de datos y metadatos, hace que su condicin de aplicacin
web no la haga restrictiva a la existencia de conexin. Aunque tambin es cierto que se
pierden muchas de sus ventajas.
2. Realizacin de copias de seguridad. Al trabajar con un sistema de informacin comn y

que adems almacena informacin muy sensible como es la informacin de salud, es muy
importante la realizacin de copias de seguridad, tanto en el servidor central como en los
establecimientos de salud.
Toda la informacin que utiliza DHIS2 se encuentra almacenada en la base de datos,

por lo que para el servidor bastara con hacer un buen uso de los sistemas de backup del
sistema de base de datos que se utilice. En cuanto a los establecimientos, los archivos
de exportacin de datos son muy buen sistema para realizar una copia de seguridad de
los datos que tienen almacenados.
3. Facilidad de actualizacin del sistema. Por tratarse de una estructura en que los nodos se
encuentran muy aislados y el acceso a los mismos es difcil, es importante poder realizar
50
Los requisitos no funcionales son aquellos que determinan aspectos del software relacionados con el diseo del
sistema y su implementacin. No se satisfacen aadiendo cdigo, sino cumplindolos como si se tratase de
restricciones.
123
actualizaciones automticas, o lo ms automticas posible, en todos los establecimientos
a la vez.
La actualizacin del sistema es tan sencilla como actualizar el servidor, pero es cierto
que si finalmente se decide trabajar en algunos establecimientos con implementaciones
offline, entonces habr que actualizarlos manualmente, uno por uno.
4. Interfaz de usuario flexible y actualizable. Los trabajadores de salud son los que real-
mente conocen las capacidades y necesidades del personal. El diseo y apariencia de las
pantallas debern definirse con la ayuda del personal clnico. Adems, el caso ideal es
que el sistema vaya incorporando los diferentes subsistemas de informacin, por lo que
la plataforma debe permitir introducir a futuro nuevas caractersticas o plantillas en las
historias clnicas, programas y formularios de recogida de datos.
La filosofa de DHIS2 gira en torno al trabajo diario del usuario final del sistema y la
herramienta se ha construido buscando la flexibilidad y adaptabilidad. Como ya hemos
visto, las pantallas de entrada de datos quedan totalmente a diseo del equipo de im-
plementadores. Por supuesto deber contar con el apoyo y seguir las indicaciones del
personal de salud.
7.8.2. Requisitos Funcionales

Los requisitos funcionales 51 los dividimos en requisitos estructurales, que son comunes para
ambos subsistemas de informacin, y requisitos procedimentales que son especficos de cada
uno de ellos.
1. Requisitos estructurales
a) Administracin de usuarios: se debe poder dar de alta y de baja usuarios dinmi-
camente. Tambin se deben poder crear usuarios con diferentes privilegios.
La administracin de usuarios y asignacin de diferentes privilegios mediante el
uso de roles y permisos es una de las caractersticas de DHIS2, como hemos visto
en los apartados anteriores. Con los roles de Personal Asistencial, Tcnico Esta-
dstico y Administrador, quedan cubiertas las necesidades del sistema de salud.
b) Establecimientos de Salud: Se deben poder introducir en el sistema los estableci-

mientos de salud y organizarlos en una jerarqua que sea fiel a la estructura adminis-
trativa del sistema sanitario de Per.
51
Los requisitos funcionales definen el comportamiento interno del software en lo referente a manipulacin de da-
tos y otras funcionalidades especficas que muestran cmo los casos de uso sern llevados a la prctica. Son
caractersticas que se satisfacen aadiendo un modulo o bloque de cdigo en el software.
124
El sistema de unidades organizativas, junto con su estructura en una jerarqua
de rbol, y el uso de los grupos y conjuntos de grupos de unidades organizativas
permite generar las estructuras necesarias, como hemos visto en el apartado de
Unidades Organizativas.
c) Propiedad de informacin: Los usuarios y los establecimientos deben tener un

vnculo entre s, y deben existir restricciones en la gestin de la informacin en base
a su propiedad y a los privilegios del usuario.
Todos los usuarios, al crearlos, se deben asignar a una o varias unidades organi-
zativas, restringiendo as su mbito de actuacin. Se asocian tambin a las unida-
des organizativas todos los sistemas de entrada de datos, como son los programas
y conjuntos de datos, restringiendo as el acceso a determinados programas o for-
mularios en funcin del usuario y su establecimiento.
2. Requisitos procedimentales
Se listan a continuacin los requisitos procedimentales de ambos subsistemas en lo refe-

rente al proceso de recogida, anlisis y difusin de la informacin y respecto a la capacidad
de almacenamiento en el sistema de la informacin recogida.
a) Registro Diario de Atenciones

1) Recogida, anlisis y difusin de la informacin.
Todas las atenciones y/o actividades deben ser anotadas en el registro diario.
Una vez a la semana las hojas de registro se envan al nivel superior.
En los centros cabecera de red se realizar un control de calidad basado en
la correcta codificacin y la validacin de los datos de aquellos puestos que
dependan de el.
Se deben proporcionar herramientas de anlisis que permitan generar esta-
dsticas de salud y de productividad de los establecimientos.
Los informes generados deben ser difundidos a los establecimientos de sa-
lud productores de informacin.
Como hemos visto en etapa de diseo, el sistema cumple positivamente los

requisitos del Registro de Historia Clnica.
En este caso, un Programa Basado en Eventos sera ms fiel al es-

cenario al que nos enfrentamos en Loreto y proporcionara facilidades a
nivel de usabilidad respecto a la solucin aqu planteada, pero a nivel de
lgica interna para la gestin de la informacin ambos programas cubren
las necesidades de tratamiento requeridas.
125
Respecto al mdulo de informes que explota la informacin recogida
por los programas, se trata de un modulo de reporte potente, capaz de
generar estadsticas de productividad por programas. Contamos con la
confirmacin y validacin del equipo que actualmente lo conoce y trabaja
con l en India, pero su prueba e implementacin no ha sido incluido en
este diseo por estar slo disponible en las implementaciones realizadas
all.
A modo de ejemplo, vemos en la figura el listado de todos los pa-

cientes registrados en un programa determinado durante un da, cortesa
de John Lewis, trabajador de HISP India. Un listado como este, con
todas las atenciones registradas en un da en el programa de Registro
Diario de Atenciones, equivaldra al formulario en papel con el que se
trabaja actualmente, o un listado con todos los pacientes registrados en
el programa de vigilancia epidemiolgica individual sera equivalente al
formulario correspondiente.
Figura 51: Ejemplo de Informe del Modulo de Reportes asociado al Modulo de Pacientes
2) Informacin necesaria para completar el formulario.
Turno No de Historia Clnica

Fecha Procedencia del paciente
Ubicacin geogrfica Edad
Servicio Sexo
Responsable de Atencin Condicin de ingreso al servicio
126
Condicin de ingreso al estableci- Diagnstico CIE-10
miento
Tipo de diagnstico
Diagnstico
Motivo de Consulta Laboratorio
Ya hemos especificado con detalle en el cuadro 10 cmo sera almacenada

en DHIS2 esta informacin, por lo que no los vamos a repasar aqu.
Aun as, debemos destacar un caso excepcional de uso en el trata-

miento de la informacin, para aquellos establecimientos donde no sea
posible hacer uso de la herramienta, ni siquiera en modo offline, y sigan
enviando sus datos en papel para ser digitados en sus centros de cabecera.
En estos caso, dado que toda informacin debe ir asociada al personal
sanitario que la genera, se debera poder indicar en el momento de
introducirla en el sistema, de qu usuario/trabajador se trata.
La aplicacin no est preparada para registrar como elemento de

datos a los usuarios de herramienta. Y aunque as fuera, si los introdu-
jsemos utilizando las categoras, como hemos hecho en otros casos en
que queremos predefinir los posibles valores de un campo, se abrira un
desplegable con todos los usuarios del sistema, sin darnos oportunidad
a filtrar por distrito o establecimiento, haciendo muy incmodo su uso.
Considerando que hay 352 establecimientos, tendramos un listado de, al
menos, 352 usuarios.
Este problema lo encontramos tambin a la hora de codificar el

Diccionario CIE-10. Uno de los requisitos de un sistema de salud rural
es el poder adaptar la complejidad de las herramientas a las distintas
capacidades de los usuarios, y una de las primeras cosas a tener en cuenta
en ese aspecto es la capacidad de diagnstico. En DHIS2, a da de hoy,
no se puede introducir el diccionario CIE 10 con diferentes niveles de
complejidad y relacionarlos entre ellos, ni crear desplegables anidados en
los que las opciones disponibles sean dependientes de la seleccin anterior.
En reuniones del grupo HISP ya se detect est necesidad de anidar

desplegables y se incluy entre los requisitos de futuros desarrollos. La
inclusin de esta lgica en la herramienta sera muy til tanto para la
seleccin de usuarios o la codificacin del CIE-10, o para indicar la
procedencia del paciente, que hasta ahora se ha codificado como texto
libre para evitar introducir todos los posibles distritos y generar un
desplegable demasiado largo.
127
b) Vigilancia Epidemiolgica
1) Recogida, anlisis y difusin de la informacin.
Cada vez que aparezca un caso de enfermedad sujeta a vigilancia epide-
miolgica individual, debe ser registrado en el formulario correspondiente
como caso individual con informacin de paciente.
Los casos de enfermedades sujetas a notificacin consolidada se anotaran
como un total semanal.
Una vez a la semana ambos formularios deben ser enviados al nivel supe-
rior.
En los centros cabecera de red se realizar un control de calidad y valida-
cin de los datos de aquellos puestos que dependan de el.
Se deben proporcionar herramientas de anlisis que permitan generar esta-
dsticas de salud y de productividad de los establecimientos.
Los informes generados deben ser difundidos a los establecimientos de sa-
lud productores de informacin
En este caso tambin debemos separar los dos subsistemas para su eva-
luacin. En el caso de la informacin estadstica de paciente, el Sistema
de Vigilancia Epidemiolgica Individual, nos encontramos en el mismo
caso que en Registro Diario de Actividades. Los dos subsistemas requieren
la misma lgica y las mismas funcionalidades, por lo que pasaremos a la
evaluacin del registro de informacin agregada.
Para el Sistema de Vigilancia Epidemiolgica de Datos Agregados

la herramienta DHIS2 cumple perfectamente los requisitos del proceso de
recogida de datos y difusin de informacin. El sistema se cre para el
tratamiento de este tipo de informacin estadstica, por lo que no presenta
ninguna carencia, ni hay que hacer ninguna adaptacin, a la hora de
implementar la recogida de informacin. Encontramos herramientas
para los controles de calidad, el control de si los centros y puestos estn
rellenando peridicamente y a tiempo sus formularios, el bloqueo de los
datos que se den por vlidos y no deban ser modificados, el anlisis de
datos, y el diseo flexible de formularios.
Una cosa a tener muy en cuenta es que, gracias a la posibilidad de

calcular datos agregados a partir de datos de paciente, sera posible
obtener los datos recogidos por este informe calculndolos desde el
registro epidemiolgico individual. Lo vemos con detalle en el ltimo
apartado.
128
2) Informacin necesaria para completar el formulario.
DIRESA Ficha de investigacin

Red Casos diarrea
Establecimiento Defunciones diarrea
Semana de Notificacin Hospitalizados diarrea
Apellidos y Nombre
Casos disentera
Edad
Defunciones disentera
Sexo
Hospitalizados disentera
Lugar de Infeccin
Casos IRAS
Diagnstico CIE-10
Neumona Casos-Severidad
Tipo de Diagnstico
Protegido Vacuna Neumona Defunciones
Fecha inicio sntomas Neumona Hospitalizacin

Fecha notificacin SOB/ASMA Casos
Fecha defuncin Casos Malaria Confirmados
Tampoco a nivel de capacidad de almacenamiento de la informacin en-

contramos ninguna limitacin en DHIS2 para la implementacin del siste-
ma de vigilancia epidemiolgica. A diferencia del registro diario de aten-
ciones, aqu la codificacin del diccionario CIE-10 no es un problema, ya
que en este caso solamente se registran una serie de enfermedades prees-
tablecida, por lo que se trata de un nmero manejable.
7.9. Propuesta de Integracin

A lo largo de los aos, HISP se ha enfrentado a muy diversos escenarios a la hora de implantar
DHIS2 como Sistema de Informacin de Salud a nivel nacional. De las numerosas experiencias
se han identificado tres estrategias que marcan las lineas generales a seguir [Bra 8]. Estas se
establecen en base al estado del Sistema de Informacin encontrado como punto de partida, y a
la flexibilidad de las organizaciones para alterar su modus operandi en el proceso de recogida
de informacin. Las describimos brevemente a continuacin:
Todo en uno 52 : En ocasiones, no solo el ministerio de salud est involucrado en la reco-

gida de informacin de salud, sino que otros ministerios tambin tienen intereses estrat-
gicos y utilizan sus propios subsistemas de informacin. Si a esto aadimos la convivencia
de diversos programas de salud, con sus respectivos Sistemas de Informacin verticales e
52
All data in one bucket en la nomenclatura original utilizada por HISP.
129
independientes, el resultado es un Sistema de Informacin altamente fragmentado y con
solapamientos en la recogida de informacin. En un escenario como ste, con un alto
sentido de propiedad de informacin por parte de los responsables de cada programa o
sistema, resulta difcil modificar los formularios. En estos casos se apuesta por realizar
una implementacin idntica al sistema existente, tanto a nivel de interfaz de usuario para
la recogida de datos como a nivel interno a la hora de almacenar la informacin en la
base de datos. No se trata de una solucin recomendada, pero en ocasiones la posibilidad
de negociar para obtener una solucin integrada no est sobre la mesa. Aun as, puede
ser una estrategia til cuando se necesite comparar datos similares obtenidos de distintas
fuentes. Es un buen punto de partida para analizar la eficiencia de diversos subsistemas de
informacin conviviendo en un mismo escenario.
Mnimo conjunto de datos 53 : Esta estrategia se enmarca en un escenario similar al

descrito en el apartado anterior, pero en este caso se adopta un plan a dos niveles. Para
el usuario se respetarn todos los formularios utilizados en papel, pero internamente, al
almacenar los datos, se intentar eliminar la fragmentacin y eliminar los duplicados,
obteniendo as una solucin integrada. De este modo, un elemento de datos puede aparecer
en ms de un formulario, pero tendr una representacin nica en la base de datos. Una
implantacin como sta debe ir precedida de un anlisis detallado de todos los elementos
de datos existentes en el sistema, a fin de identificar el conjunto de datos mnimo que ser
almacenado en la base de datos.
Mximo conjunto de datos 54 : La tercera estrategia es una combinacin de las dos an-
teriores. En ella el punto de partida es la generacin de un sistema siguiendo el mtodo
Todo en uno para probar que DHIS2 puede replicar el sistema existente. Posteriormente
se realiza un anlisis de la calidad de datos existentes y se calcula un conjunto de indica-
dores con el objetivo de mostrar las redundancias e identificar la informacin no necesaria
que se recoge. Se intenta reflejar con este anlisis la necesidad de cambio. El ltimo paso
sera realizar una implementacin siguiendo la estrategia del Mnimo conjunto de datos
en que se almacena unvocamente la informacin necesaria. Esta estrategia nace, igual
que la primera, de una postura reacia a cambios por parte de la organizacin en cuestin.
En este proyecto se ha seguido la primera estrategia y todos los sistemas han sido implemen-
tados como una copia del sistema existente a todos los niveles.
Como hemos comentado en diversas ocasiones a lo largo de la memoria, la capacidad de cal-

cular datos agregados desde datos de paciente, abre muchas posibilidades en la recoleccin de
informacin, adems de generar informacin ms fiable. En este apartado intentamos sacar el
mximo partido al clculo de agregados, aplicando la estrategia del Mnimo conjunto de datos,
con la diferencia de que lo haremos tanto a nivel externo (modificando el formulario) como a
nivel interno (eliminando inconsistencias en la base de datos).
53
Minimum Dataset en la nomenclatura original utilizada por HISP.
54
Maximum Dataset en la nomenclatura original utilizada por HISP.
130
Para ello vamos a intentar unificar los tres subsistemas de informacin que hemos diseado
en uno solo, que recoja el conjunto mnimo de informacin posible y genere automticamente
el resto de campos.
En el siguiente cuadro se especifica la informacin necesaria para cada programa, la cual se

ha clasificado en reas de informacin.
Figura 52: Cuadro Resumen de los campos de los Formularios
Los campos de la leyenda significan:
Datos Temporales: Datos relativos a la dimensin cundo.
Datos de Pacientes: Datos personales de paciente.
Datos del Establecimiento: Datos relativos a la dimensin dnde.
Datos de Diagnstico: Datos de diagnstico relativos al diccionario CIE-10.
Datos Clnicos: Datos clnicos de paciente.
Campos Calculables: Datos de epidemiologa consolidada que se pueden calcular con los
campos existentes en el formulario de epidemiologa individual.
131
Campos Calculables aadiendo un campo : Datos de epidemiologa consolidada que se
pueden calcular aadiendo un campo extra al formulario de epidemiologa individual.
Al colorear los campos en funcin del rea en que se clasifican, resulta fcil ver que hay un
nmero importante de campos duplicados y de campos que pueden ser calculados automtica-
mente. De hecho, si eliminamos estos dos grupos (los duplicados y los calculables), y aadimos
los pocos campos necesarios para algunos clculos, vemos que podemos recopilar la misma
informacin con muchos menos campos.
Figura 53: Conjunto mnimo de informacin
En concreto, el nmero se reduce de 59 a 33 (un 44 %), y lo que es ms importante, de tener

que registrar todas las atenciones diarias, y rellenar dos informes estadsticos semanales, pasa-
mos a tener nicamente que registrar todas las visitas en un formulario.
En la figura siguiente vemos un ejemplo de cmo sera el formulario resultante, llamado en

este ejemplo Registro Integrado de Atencin Diaria, teniendo en cuenta que los datos personales
del paciente, los del establecimiento, y los temporales, son almacenados automticamente por el
sistema.
132
Figura 54: Formulario de Entrada con la informacin mnima
Si en cada visita de un paciente al establecimiento, el personal que realiza la atencin rellena-

se el formulario propuesto, se podra generar semanalmente los informes a enviar, y quedaran
registradas todas las atenciones, por lo que se podra generar tambin el registro diario de aten-
ciones.
133
Parte IV.
Conclusiones y trabajo futuro
8. Conclusiones
Al terminar este proyecto, una vez se conocen con cierta profundidad las necesidades de los
sistemas de salud de Loreto a nivel de los establecimientos rurales, y se tiene un amplio conoci-
miento de la herramienta objeto de este estudio, as como del grupo de investigacin que le da
mantenimiento y sigue trabajando en su perfeccionamiento, la valoracin es muy positiva.
Recordemos que partamos de la bsqueda de una herramienta web, que permitiese la referen-
cia y contrareferencia de pacientes y que manejase datos clnicos de paciente, que adems mini-
mizase la introduccin de texto libre en los formularios, y permitiese personalizar las interfaces
de usuario. Que admitiese su ampliacin en el tiempo con la inclusin de nuevos subsistemas de
informacin, que permitiese diseo colaborativo y flexible de las pantallas de recogida de datos,
y por ltimo, que extrajese los informes en formato dbf.
Como hemos visto en la evaluacin de requisitos, se trata de una herramienta que se adapta
muy bien a las necesidades de un sistema de informacin rural, quiz por su filosofa de diseo
flexible y enfocada al usuario final. Es verdad que tambin se han encontrado limitaciones, casos
que no cumplan con total fidelidad las funcionalidades esperadas. En este aspecto cabe destacar
que el grupo HISP trabaja continuamente en la mejora de las funcionalidades existentes. Existe
una lista de distribucin de usuarios e implementadores que he podido comprobar durante la
elaboracin de este proyecto, funciona perfectamente. Se solucionan desde las dudas funciona-
les ms bsicas, hasta bugs de programacin, aunque es cierto que en ese caso se procede a
remitirlo a la plataforma correspondiente de mantenimiento del software, la cual tambin es muy
eficiente. Cuando tuvimos el primer contacto con HISP en Junio de 2011 se acaba de lanzar la
versin 2.3 de DHIS2. A da de hoy, en Enero de 2012, se acaba de publicar la primera mejora
de la versin 2.6 lanzada en Diciembre, y se ha fijado para Marzo el lanzamiento de la 2.7 55 .
En las sucesivas versiones se incluyen correcciones y mejoras que siempre nacen de sugerencias
o comentarios de los usuarios finales, que son lo que se encuentran realizando implantaciones
de la herramienta en el terreno. Pretendo con estos datos mostrar la dinamicidad del grupo de
trabajo, y la importancia que se da a la interaccin con el usuario final en la evolucin de la
herramienta.
Pese a la valoracin positiva realizada, debe ser puesto en evidencia que uno de los mayores
atractivos de DHIS2 para nosotros, el mdulo de datos de paciente, es tambin la funcionalidad
ms reciente y por tanto menos probada y menos expuesta al uso real en terreno. Desde HISP
son conscientes de que necesita pasar por ms fases de prueba, que debe ser optimizada para tra-
55
Se puede hacer un seguimiento a la evolucin de DHIS2 en el sitio web disponible para mantenimiento del soft-
ware. https://launchpad.net/dhis2
134
bajar con grandes cantidades de datos, y que, muy probablemente, requiera de diversas mejoras.
Aun as queremos identificar la inmadurez de este mdulo como un punto dbil de DHIS2, no
porque en s lo sea, sino porque lo es para nosotros. Como se ha visto en el ltimo resultado, es
una parte muy influyente en la idoneidad de la herramienta en nuestro diseo.
Una implementacin real de lo que en este proyecto se ha estudiado debera plantearse al me-
nos a nivel regional, pues a menor escala requerira su integracin con los sistemas existentes
y generara complicaciones derivadas de la convivencia de dos sistemas paralelos, siendo muy
probable que, lejos de mejorar la situacin, se convirtiera en una aportacin negativa.
Para poder garantizar el xito de una implantacin regional, se considera necesario un trabajo
ms profundo en que se lleve a cabo un estudio en terreno mucho ms detallado, en que se com-
prueben, no slo los requisitos aqu descritos, sino tambin la capacitad resolutiva del usuario
final, las necesidades que se deprenden de la actividad diaria de los establecimientos, y un an-
lisis del software existente. Aun as, con el conocimiento adquirido en este PFM, se valora de
forma muy positiva la herramienta y el posible impacto en los sistemas sanitarios rurales que se
podra obtener de la unin de los conocimientos y el esfuerzo de EHAS y HISP, cada uno en su
especialidad, con el objetivo de mejorar los Sistemas de Informacin de Salud en zonas rurales.
135
9. Trabajo Futuro
De la implantacin de un Sistema de Informacin online como DHIS2 en Loreto se abren
muchas posibilidades que podran contribuir a la mejora del sistema de salud. Se exponen a con-
tinuacin las funcionalidades mas interesantes a estudiar, con la seguridad de que muchas ms
aparecern si el sistema se implantase finalmente en la regin.
No se ha introducido en este PFM la posibilidad de DHIS2 de recibir y consultar informacin

a travs del telfono mvil. Ha sido as por dos razones, en primer lugar porque esta funcio-
nalidad aparece en la versin 2.6, lanzada durante el transcurso del PFM, y en segundo lugar
porque la zona donde se enmarca este proyecto carece de cobertura para el uso de mviles, lo
cual result determinante para la decisin de no incluirlo. Aun as, es una funcionalidad que da
mucho valor aadido a la herramienta para aquellos casos en que s haya cobertura mvil y no
se disponga de una red de telecomunicaciones como la del ro Napo, por lo que se considera
interesante su estudio para otros escenarios.
Un estudio de DHIS2 ms enfocado en asegurar las capacidades de las herramientas de anli-

sis para satisfacer las necesidades del sistema de informacin de Loreto, identificar la capacitad
resolutiva del usuario final y las necesidades que se deprenden de la actividad diaria de los esta-
blecimientos, as como un anlisis del software existente, sera necesario para llevar a la prctica
la implantacin de DHIS2 en el terreno.
Debemos recordar que este proyecto se ha centrado nicamente en los flujos de informacin
de los establecimientos rurales. Si se barajase la posibilidad de una implantacin a nivel nacio-
nal, se deber tener en cuenta que el xito de la misma pasar por la voluntad de implantacin del
Ministerio de Salud y la flexibilidad de los actores implicados para aceptar los inevitables cam-
bios. En este caso ser necesario realizar un anlisis de todos los subsistemas de salud existentes.
Se proponen a continuacin unas lineas generales para la integracin completa del Sistema de
Informacin de Salud de Per.
Para la gestin de recursos humanos, es decir el Sistema de planillas del Ministerio de

Salud, se recomienda la utilizacin de un software especializado. Una recomendacin es el soft-
ware Integrated Human Resources IS (IHRIS), herramienta que facilita la gestin de nuevas
contrataciones, formacin de personal, y gestin de empleados, entre otros. Incorpora tambin
funcionalidades de anlisis y generacin de informes, pero su caracterstica mas importante para
nosotros es su integracin con DHIS2.
Para el Registro de Hospitalizaciones y Emergencias y el Sistema Integrado de Suminis-

tro de Medicamentos e Insumos Mdico-Quirrgico se recomienda la utilizacin de un soft-
ware de gestin hospitalaria que permita su integracin, a nivel de datos agregados, con DHIS2.
El software de gestin hospitalaria DHIS Hospital, construido sobre el ncleo OpenMRS si-
guiendo su estructura modular, podra ser una opcin interesante.
La gestin del Seguro Integral de Salud, podra realizarse mediante un software indepen-
136
diente del que se alimentasen tanto DHIS2 como el sistema de gestin hospitalaria. Una solucin
ms integrada pasara por su inclusin en el software de gestin hospitalaria propuesto anterior-
mente. Esta opcin requiere del desarrollo de un nuevo mdulo, pues actualmente el sistema,
pese a que s puede recoger informacin que identifique al paciente en el Seguro Integral de
Salud y aplicar diferentes tarifas en base a esa informacin, no contempla la operaciones nece-
sarias para la gestin de un seguro sanitario como puedan ser altas, bajas, o distintos niveles de
cobertura, entre otras.
Un sistema ligado al Seguro Integral de Salud es el Sistema de Referencia y Contrarefe-

rencia. Se trata de un sistema en que un profesional de salud remite un caso ms complejo a
otro profesional ms especializado. A primera vista parece que se podra solucionar si en ambos
centros se tiene acceso a DHIS2. El envo sera una etapa de un programa, la recepcin y trata-
miento podran ser una segunda etapa, y la contrareferencia la etapa final. Se podra garantizar
as el acceso de ambos profesionales a los datos y solucionar mucha de la problemtica de falta
de informacin tanto en el envo como en la devolucin del paciente. Un estudio en pro-
fundidad del proceso identificar mayores complejidades y requerir de un diseo especfico y
detallado. Tambin el estudio del uso de mensajes para la coordinacin de emergencias y loca-
lizacin de recursos seguro podra resultar de gran utilidad, pese a tratarse de una funcionalidad
muy sencilla.
El Sistema de Informacin Perinatal encaja perfectamente con el programa basado en eta-

pas de DHIS2, por lo que se recomienda la definicin de un programa que contemple todas sus
fases e integre la informacin establecida en la Historia Clnica Materno Perinatal. El Registro
de Nacimientos e Informe Estadstico del Nacido Vivo y el Registro de Muerte e Informe
Estadstico de Defuncin, tambin resultan de integracin inmediata en el Sistema de Infor-
macin. El Programa de Evento Aislado o SingleEvent, que define un programa en el que un
evento sucede una nica vez para cada paciente, precisamente fue diseado para recoger este
tipo de eventos como son nacimiento o defuncin. Una vez integrados estos tres subsistemas
en el Sistema de Informacin de Salud, el anlisis de informacin y obtencin de estadsticas
podra llevarse a cabo con las herramientas proporcionadas por DHIS2, tal y como hemos visto
a lo largo del proyecto.
Por ltimo indicar que sera recomendable enmarcar todo trabajo futuro en el fortalecimiento
de las relaciones con el grupo HISP de la Universidad de Oslo, pues han demostrado tener mucho
inters en colaborar con la Fundacin EHAS y una alta disponibilidad para la orientacin, apoyo
y colaboracin en caso de que finalmente sea viable la implantacin de esta herramienta en Per.
137
Referencias
[And 7] Andreu, R; Ricart, J.E; Valor, J. Estrategia y sistemas de informacin. McGraw-
Hill, 1993. ISBN: 84-481-0508-7.
[Bra 8] Braa J. and Sahay S. Integrated Health Information Architecture. Power to the
Users: Design, Development and Use. Matrix Publishers, 2012. ISBN 978-93-
81320-06-8.
[dCyT 4] Ministerio de Ciencia y Tecnologa. La Sociedad de la Informacin en el siglo

XXI: un requisito para el desarrollo. McGraw-Hill, 2003. ISBN 84-7474-819-4.
[dec12] Asamblea general del 13 de septiembre de 2000. Publicacin de Naciones Uni-

das, http://www.un.org/spanish/milenio/ares552.pdf, Enero, 2012.
[dge12] Sitio web de la direccin general de epidemiologa de per.

http://www.dge.gob.pe/, Enero, 2012.
[dlSOMdlS11] Organizacin Panamericana de la Salud | Organizacin Mundial de la Salud.

Estrategia y plan de accin sobre esalud. Acta de Sesin del Comit Ejecutivo,
Junio, 2011.
[dSdP04] Ministerio de Salud de Per. Categoras de establecimientos del sector de salud.

Norma Tcnica, 2004.
[dSdP07a] Ministerio de Salud de Per. Flujograma del sistema de informacin his. Anexo
Manual General de uso del HIS, 2007.
[dSdP07b] Ministerio de Salud de Per. Manual general de registro y codificacin de diag-

nsticos de consulta externa y otras actividades de salud. Manual General de
uso del HIS, 2007.
[dSdP08] Ministerio de Salud de Per. Norma tcnica sobre el uso del cdigo de ubicacin
geogrfica. Norma Tcnica, 2008.
[dSdP09] Ministerio de Salud de Per. Evaluacin del sistema de informacin rutinaria

en salud per, 2008-2009.
[Fra] Fraser, HSF and Blaya, J. Implementing medical information systems in develo-
ping countries, what works and what doesnt. AMIA Annu Symp. 2010: 232-236.
ISSN 1942-597X.
[Gar10] Garca Muoz, J. y Foche Prez, I. Informe sobre la identificacin de un sistema

de informacin de salud (sis) en los establecimientos mdicos aislados de la
regin de Loreto (Per). Fundacin EHAS, 2010.
[ISO02] ISO International Standard - ISO TC 215/SC N. Requirements for an electronic

health record reference architecture. Technical Specification Draft, 2002.
138
[Mar 4] Martnez, A. Villarroel, V. Seoane, J. Sanchez, A. y del Pozo, F. Sistemas de
telemedicina rural para pases en desarrollo. XX Congreso Anual de la Socie-
dad Espaola de Ingeniera Biomdica, Zaragoza. Espaa, 2002. ISBN 84-600-
9818-4.
[Nol 9] Noll, J., Beecham, S. and Seichter, D. A qualitative study of open source soft-
ware development: the openemr project. Empirical Software Engineering and
Measurement, 2011 International Symposium on, Pagination 30 - 39, ISBN 978-
0-7695-4604-9.
[odm 9] Objetivos de desarrollo del milenio. informe 2010. Publicacin del Departa-
mento de Asuntos Econmicos y Sociales de las Naciones Unidas, Junio, 2010.
ISBN 978-92-1-300246-9.
[Sae02] Saebo, J. Kossi, E. Titlestad, O. Tohouri, R. and Braa, J. Comparing strategies

to integrate health information systems following a data warehouse approach
in four countries. Information Technology for Development, 17(1), 2011. ISSN
0268-1102.
[SIB 7] J. Mandil S. Sosa-Iudicissa, M. Levett and P.F. Beales. Health information so-
ciety and Developing countries. IOS Press, 1995. ISBN 978-90-5199-226-7.
[Web03] Steven Weber. Open source software in developing economies. University of

California, Berkeley, 2003.
139

Sistema de información de salud rural en Perú

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Sistema de información de salud rural en Perú

Hochgeladen von

Copyright:

Verfügbare Formate

Mster en Redes de Telecomunicacin

para Pases en Desarrollo

ESCUELA TCNICA SUPERIOR DE

PROYECTO FIN DE MSTER

ESTUDIO DE VIABILIDAD PARA LA MEJORA DEL

Autora: Marta Mara Vila Pozo

Curso acadmico 2011/2012

DATOS DE ESTUDIO DEL MSTER

DATOS DEL ALUMNO

TTULO DEL TRABAJO FIN DE MSTER

MIEMBROS DEL TRIBUNAL ACTA EN CALIDAD DE

Reunido el Tribunal de Evaluacin con fecha .............................., ACUERDA otorgar al alumno

EL PRESIDENTE EL SECRETARIO VOCALES

Fdo: Fdo: Fdo:

Este estudio se basa en la informacin obtenida de la experiencia del Proyecto EHAS-Napo

El actual Sistema de Informacin de Salud de la Regin de Loreto, donde se enmarca el pro-

5. Identificacin del flujo de Informacin generada en el Sistema de Salud de

6. Estudio del Sistema de Informacin de Salud DHIS2 57

7. Implementacin de DHIS2 para el caso de estudio en la Regin de Loreto 86

IV. Conclusiones y trabajo futuro 134

9. Trabajo Futuro 136

DGE Direccin General de Epidemiologa

DHIS District Health Information System

DICOM Digital Imaging and Communication in Medicine

DIREMID Direccin Regional de Medicamentos e Insumos

DIRESA Direccin Regional de Salud

EDA Enfermedad Diarreica Aguda

EHAS Enlace Hispano Americano de Salud

FESE Ficha para Evaluacin Socio Econmica

FOSS Free and Open Source Software

GML Geography Markup Language (Lenguaje de Marcado Geogrfico)

GTR Grupo de Telecomunicaciones Rurales

HCE Historia Clnica Electrnica

HIS Health Information System

HISP Health Information System Programe

HL7 Health Level Seven

IHTSDO International Health Terminology Standards Development Organisation

INEI Insituto Nacional de Estadstica e Informtica

IRA Infeccin Respiratoria Aguda

MINSA Ministerio de Salud

NORAD Norwegian Agency for Development (Agencia Noruega para el Desarrollo)

ODM Objetivos de Desarrollo del Milenio

OEI Oficina General de Estadstica e Informtica

OMS Organizacin Mundial de la Salud

PNUD Programa de Naciones Unidas para el Desarrollo

SESE Sistema para Evaluacin Socio Econmica

SIG Sistema de Informacin Geogrfica

SIS Sistema de Informacin de Salud

SISMED Sistema Integrado de Suministro de Medicamentos e Insumos mdico Quirrgico

SNOMED-CT Systematized Nomenclature of Medicine - Clinical Terms

TIC Tecnologas de la Informacin y la Comunicacin

Las Tecnologas de la Informacin y la comunicacin (TIC) tienen potencial para contribuir a

En un estudio comparativo de cuatro estrategias de integracin de Sistemas de Informacin

La Fundacin Enlace Hispano Americano de Salud (EHAS) ha desarrollado diversas solu-

1.2. Organizacin del Documento

Captulo 8: Conclusiones, en las que se discuten y resumen los resultados obtenidos y se

Captulo 9: Trabajo Futuro, donde se apunta qu estudios se debern llevar a cabo si

1.3. Marco de Referencia

El campo de la informtica para la salud en pases en desarrollo ha crecido mucho en la ltima

1.3.2. El Sistema de Salud en Zonas Rurales

Puestos de Salud (PS)

Centros de Salud (CS)