PONTIFICIA UNIVERSIDAD CATLICA DEL PER

FACULTAD DE CIENCIAS E INGENIERA

ANLISIS, DISEO E IMPLEMENTACIN DE UN BANCO

ESTANDARIZADO DE HISTORIAS CLNICAS Y APLICACIN
MVIL PARA LAS CLNICAS ODONTOLGICAS

Tesis para optar por el Ttulo de Ingeniero Informtico, que presenta el bachiller:

Luis Martn Allende Flores

ASESOR: Dr. Andrs Melgar Sasieta

Lima, Julio del 2013

RESUMEN

Se ha podido determinar [ENSF] que en los establecimientos de salud pblicos,

sobre todo en lo que brindan servicios de atencin odontolgica, se presentan
mltiples inconvenientes que repercuten directamente en la imposibilidad del
cumplimiento de la Norma Tcnica de Salud para la Gestin de la Historia Clnica,
con especial nfasis en lo relacionado a:

Custodia: No existe seguridad adecuada durante el almacenamiento de la

Historia Clnica.

Conservacin: Existen problemas con humedad y moho.

Confidencialidad: Falta de definicin de polticas de confidencialidad.

Acceso: Permisos no definidos para la recoleccin de la Historia Clnica.

El presente proyecto de fin de carrera tiene como uno de sus productos finales un
banco estandarizado de historias clnicas odontolgicas, el cual intentar resolver
los problemas descritos anteriormente. Actualmente, el Ministerio de Salud no
dictamina un mtodo estndar para la manipulacin automatizada de historias
clnicas, es por ello que los establecimientos de salud pblicos recurren a la
utilizacin de los procesos manuales para el manejo de las mismas sin sopesar
que, en su mayora, infringen las normas [NTHC]. A pesar de esto, los
establecimientos de salud pblicos tienen una gran cantidad de fondos disponibles
no utilizados [ENSF], los cuales nos serviran para el financiamiento del proyecto y
adquisicin de hardware necesario.

En dicho contexto, la implementacin de un banco estandarizado de historias

clnicas permitira monopolizar la informacin relacionada y cumplir con los
estndares dictaminados [NTHC]. Asimismo, es necesario implementar una
aplicacin mvil que aproveche dichas ventajas y que, mediante sus
funcionalidades, permita al profesional de salud manipular dicha informacin.

En base a estos argumentos, se considera que el desarrollo del presente proyecto

adquiere importancia y es altamente viable dentro del escenario planteado.
Dejando, adems, una ventana abierta a posibles ampliaciones y mejoras en el
futuro.
 Dedicatorias
A todas las personas que formar parte de mi vida
y anhelan verme crecer.

Especialmente a ti, madre.

Muchas gracias por todo lo que me has dado
 Agradecimientos
A mi asesor, por haberme acompaado durante
este proyecto y guiarme hasta el final exitoso del mismo.

A mi madre y todo el equipo mdico del C.S. Villa San Luis,

por toda la enseanza brindada a lo largo de estos aos
y la informacin necesaria para culminar este proyecto.

A Karina Reyna, por haberme brindado su apoyo incondicional,

sin ti no hubiera tenido las energas necesarias para continuar.

A todas las personas de las cuales he obtenido conocimientos,

ustedes me trajeron a este punto de mi vida.
 Tabla de Contenido
Introduccin ...............................................................................................................................1
CAPTULO 1 .............................................................................................................................3
1.1. Definicin del problema .................................................................................................3
1.2. Objetivo general ............................................................................................................5
1.3. Objetivos especficos ....................................................................................................5
1.4. Resultados esperados ..................................................................................................6
1.5. Alcance ..........................................................................................................................7
1.6. Limitaciones ..................................................................................................................8
1.7. Mtodos y procedimientos ............................................................................................8
1.7.1 Metodologa para la elaboracin del sistema ...........................................................8
1.7.2 Metodologa para la gestin del proyecto ...............................................................11
1.8. Justificacin del proyecto ............................................................................................13
1.9. Viabilidad del proyecto ................................................................................................15
1.9.1 Viabilidad del sistema .............................................................................................15
1.9.2 Anlisis tcnico y econmico ..................................................................................16
1.10. Plan del proyecto ........................................................................................................18
1.10.1 EDT .................................................................................................................18
1.10.2 Planificacin de las tareas ..............................................................................19
CAPTULO 2 ...........................................................................................................................25
2.1 Marco Conceptual .......................................................................................................25
2.1.1. Historia clnica .................................................................................................25
2.1.2. Odontograma: .................................................................................................31
2.1.3. Norma tcnica de salud para la gestin de la historia clnica .........................33
2.1.4. Directiva administrativa sobre especificaciones tcnicas mnimas para
sistemas informticos en el Ministerio de Salud [ETSI] ...................................................33
2.2 Estado del arte ............................................................................................................34
2.2.1 Sistema de manejo manual de historias clnicas ....................................................34
2.2.2 EdgeDMS ................................................................................................................35
2.2.3 My Dentist ...............................................................................................................36
2.2.4 My Dental Hub Mobile Patient Education ...............................................................37
CAPTULO 3 ...........................................................................................................................38
3.1. Identificacin de requerimientos .................................................................................38
3.1.1. Requerimientos Funcionales...........................................................................39
3.1.2. Requerimientos No Funcionales .....................................................................40
3.2. Arquitectura de la solucin ..........................................................................................40
3.2.1. Arquitectura Web.............................................................................................40
3.2.2. Arquitectura mvil............................................................................................45
3.3. Diseo de Interfaz Grfica ..........................................................................................47
3.4. Arquitectura de Informacin ........................................................................................47
3.4.1. BPMN ..............................................................................................................47
3.4.2. Obtencin de Historias Clnicas Odontolgicas: .............................................48
3.4.3. Utilizacin de Historias Clnicas Odontolgicas: .............................................50
3.5. Diagrama de Base de Datos .......................................................................................53
CAPTULO 4 ...........................................................................................................................54
4.1. Construccin ...............................................................................................................54
4.2. Pruebas .......................................................................................................................58
4.2.1. Tipos de Pruebas ............................................................................................58
4.2.2. Tcnica utilizada..............................................................................................62
4.2.3. Resultados de las pruebas ..............................................................................62
CAPTULO 5 ...........................................................................................................................66
5.3. Observaciones ............................................................................................................66
5.4. Conclusiones ...............................................................................................................67
5.5. Recomendaciones y trabajos futuros ..........................................................................68
BIBLIOGRAFA .......................................................................................................................70
Introduccin

El presente documento consiste en el desarrollo de un proyecto cuya principal

finalidad y objetivo es la resolucin de un problema latente en el actual sistema de
manejo de historias clnicas odontolgicas en los establecimientos de salud
pblicos. Se ilustrar el problema y se detallarn las razones para optar por la
generacin de un protocolo de estandarizacin de historias clnicas y una aplicacin
mvil para el aprovechamiento del mismo. A lo largo de los prximos captulos se
irn mostrando, por etapas, los pasos necesarios para la elaboracin de la solucin
propuesta.

En el captulo 1 se muestran las generalidades del proyecto, incluyendo la

definicin del problema, los objetivos y resultados esperados, el alcance y
limitaciones, las metodologas de desarrollo y manejo de proyectos que se planean
utilizar, la justificacin de la solucin propuesta y el marco de trabajo bajo el cual se
ejecutar el proyecto.

1
En el captulo 2 se muestran los conceptos bsicos y definiciones ms importantes
que permitirn un entendimiento terico del tema. Asimismo, se da una revisin del
estado de arte, el cual es la explicacin de cmo se resuelve actualmente el
problema planteado.

En el captulo 3 se presentan las etapas de anlisis y diseo juntas, en las cuales

se realizan el listado de los requerimientos funcionales y no funcionales, la
arquitectura que se usar en el desarrollo de la solucin y se hace una descripcin
sobre el diseo de la interfaz grfica, para finalmente denotar la arquitectura de
informacin mediante diagramas BPM.

En el captulo 4 se presenta la construccin y pruebas aplicadas al sistema, donde

lo ms resaltante es la descripcin y justificacin de las herramientas tecnolgicas y
frameworks que sern utilizados para desarrollar el sistema, as como las pruebas
que sern aplicadas para garantizar el correcto funcionamiento del mismo.

En el captulo 5 se exploran las observaciones, conclusiones y mejoras para un

trabajo futuro, estas se basan en lo aprendido durante la realizacin del proyecto.

Finalmente, en la bibliografa se listan todas las referencias utilizadas, permitiendo

reforzar los conceptos y profundizar en los temas especficos que se tratan a lo
largo del documento.

2
CAPTULO 1

1.1. Definicin del problema

La historia clnica es el documento mdico-legal en el cual los mdicos u otros
profesionales de salud dan testimonio del estado fsico en el que se encuentra el
paciente, las aflicciones identificadas durante el proceso de atencin y las medidas
correctivas a seguir [NTHC]. De ser el mdico tratante un odontlogo, se adherir a
la historia clnica una pgina con la finalidad de registrar de manera grfica los
datos sobre las anomalas y patologas encontradas en los dientes del paciente tras
cada atencin; esta tendr el nombre de odontograma y de adherirse informacin
sobre el estado bucal completo del paciente, pasar a conocerse como Ficha
Odontoestomatolgica [NTUO].

Las disposiciones brindadas en la Norma Tcnica de Salud para la Gestin de la

Historia Clnica sirven para definir la correcta composicin de la historia clnica y el
manejo adecuado de la misma, con especial nfasis en lo relacionado a custodia,
conservacin, confidencialidad y acceso a la misma [NTHC]. Con el fin de cumplir la
norma, los establecimientos de salud pblicos y privados optan por diversas
opciones que se ajusten a su presupuesto y polticas internas; entre las cuales est

3
la contratacin de un mayor volumen de trabajadores, adquisicin de equipos y
personal mejor capacitado, modificacin a la infraestructura del establecimiento,
entre otras [ENSF].

Adicionalmente, los establecimientos de salud pblicos presentan reglamentos

particulares sobre los formatos de atencin a seguir; teniendo como ms relevantes
los siguientes [ENSF]:

Guas para el correcto llenado de fichas de atencin general [RAFA], las cuales
incluyen toda la documentacin relacionada a la atencin de los pacientes; son
dependientes de la localizacin del establecimiento de salud y la direccin de
red superiora a la que pertenezcan. Estas tambin pueden contener secciones
de codificacin de lesiones odontolgicas [RCCS].

Lineamientos relacionados a la responsabilidad del establecimiento de salud

para con la comunidad [PVCS], promoviendo la sostenibilidad de los
mecanismos de vigilancia ciudadana en salud, el establecimiento de medios de
comunicacin y difusin de la informacin, etc.

Especificaciones en el manejo y atencin de las siete patologas bucales ms

comunes, comprendiendo diversos tratamientos desarrollados segn las
evidencias cientficas vigentes [GPCE].

Manuales para el trato con pacientes que requieren atencin especial; estas
incluyen a personas con enfermedades altamente contagiosas, menores de
edad, adulto mayor, gestantes, lactantes, entre otros [ENSF]. El caso de las
gestantes y lactantes presenta aspectos particulares, ya que el rea de atencin
mdica trabaja en conjunto con el rea de obstetricia del establecimiento de
salud, con el fin de asegurar as la salud de la madre y el nio [PPLM].

Se ha podido determinar [ENSF] que en los establecimientos de salud pblicos,

sobre todo en lo que brindan servicios de atencin odontolgica, se presentan
mltiples inconvenientes, como la insuficiencia de personal en el rea de manejo de
historias clnicas, falta de capacitacin para el capital humano relacionado,
inviabilidad en la ejecucin de modificaciones a la infraestructura de los
establecimientos asignados y, sobre todo, el limitado presupuesto destinado a la
administracin del establecimiento de salud. Todos estos inconvenientes repercuten
directamente en la imposibilidad del cumplimiento de la norma tcnica vigente
[NTHC], siendo este el problema a solucionar.

4
1.2. Objetivo general
Desarrollar un sistema de informacin que permita a los establecimientos de salud
pblicos que cuenten con el programa de salud bucal activo cumplir con las
clusulas referentes a custodia, conservacin, confidencialidad y acceso a la
historia clnica, dictaminados en la Norma Tcnica de Salud para la Gestin de la
Historia Clnica [NTHC] en el rea odontoestomatolgica para los pacientes con
denticin permanente.

1.3. Objetivos especficos

Los objetivos especficos segregados del objetivo general presentado son los
siguientes:

A. Definir el modelo de datos a utilizar en base a la recopilacin de informacin

sobre el contenido de las historias clnicas utilizadas en los establecimientos de
salud pblicos y las partes trascendentales de la ficha estomatolgica.

B. Modelar los procesos utilizados en el actual manejo de las historias clnicas

odontolgicas en los establecimientos de salud pblicos.

C. Identificar las necesidades de informacin y necesidades transaccionales de

los odontlogos teniendo como base el cumplimiento de la norma [NTHC] y la
directiva [ETSI].

D. Implementar el sistema de informacin y corroborar su funcionamiento

mediante el plan de pruebas unitarias.

5
1.4. Resultados esperados
Los resultados esperados correspondientes a los objetivos especficos planteados
son los siguientes:

A. Se obtendr el modelo de datos que represente la informacin a manejar y, con

esto, se generar el diagrama de base de datos.

B. Se obtendr el modelo de procesos de los establecimientos de salud pblicos

utilizando la herramienta BizAgi Process Modeler [BIZAGI].

C. Se contar con el catlogo de requerimientos funcionales y no funcionales con

los que debe cumplir el proyecto.

D. Se tendr la solucin implementada y cumplir con los puntos del plan de

pruebas unitarias.

6
1.5. Alcance
El proyecto se enfoca en la generacin de una herramienta que viabilice el
cumplimiento de la norma que rige la utilizacin de las historias clnicas en los
establecimientos de salud [NTHC], especficamente en el trabajo realizado por los
establecimientos de salud pblicos que cuenten con el programa de salud bucal
activo. Se ha escogido acotar el proyecto nicamente a estos establecimientos no
slo por la importancia que tienen en el desarrollo social, sino tambin por el
conocimiento del tema, la vasta cantidad de reglamentos a considerar al trabajar
con una institucin del estado y, sobre todo, la facilidad para la recoleccin de la
informacin.

Adicionalmente, tomando en cuenta el universo de casusticas posibles en lo que

respecta a la atencin en el rea de salud bucal, y con particular nfasis en lo
relacionado a menores de edad y lactantes [PPLM], se decide delimitar el alcance
del presente trabajo a la atencin de pacientes mayores de edad que no
pertenezcan a un grupo de riesgo y cuenten con denticin permanente, es decir,
que hayan finalizado el proceso de denticin decidua y mixta. Esto con la finalidad
de evitar toda la reglamentacin y condiciones particulares a tener en cuenta en el
trabajo con menores de edad y personas de riesgo (pacientes que sufran de
enfermedades altamente contagiosas, mujeres lactantes o embarazadas, etc.).

Todo lo planteado en el proyecto es de aplicabilidad inmediata, es decir, est

propenso a ser implementado en el mbito temporal en que se redacta el presente
documento.

El sistema de informacin a desarrollar propone corroborar el cumplimiento de la

norma [NTHC] en el mbito acotado, y puede llegar a ser el punto de partida para
otros proyectos con un alcance ms profundo, que podra incluir todo tipo de
denticin, una aplicabilidad a nivel privado e, incluso, extenderse a otras
especialidades mdicas.

7
1.6. Limitaciones

Considerando que se tiene la finalidad de realizar un anlisis, diseo e

implementacin de un aplicativo que ayude a mitigar el problema presentado, se
puede determinar que el proyecto pertenece al rea de Sistema de Informacin.

Debido a que se trabajar con instituciones del estado, se cuentan con numerosas
reglamentaciones a considerar para que el proyecto pueda ser implantado
exitosamente en el mbito definido, teniendo como principal normativa en el rea
de desarrollo las especificaciones tcnicas mnimas a cumplir [ETSI].

1.7. Mtodos y procedimientos

En esta seccin se expondr la informacin sobre las metodologas a utilizar, as

como el alcance que se tomar en cuenta para su aplicacin al proyecto.

1.7.1 Metodologa para la elaboracin del sistema

La metodologa a usar ser Crystal Clear, esta es categorizada como una

metodologa gil, la cual cuenta con las siguientes propiedades [COCKB]:

Entregas frecuentes de cdigo til a los usuarios, con lo cual se monitoriza el

avance del sistema y se pueden plantear mejoras en el camino: Esto ser
utilizado en el actual proyecto con las presentaciones continuas al asesor para
monitorear el avance del mismo y analizar el estado y posibles cambios a
realizar en el proyecto.

Mejora reflexiva, con la cual el equipo se retroalimenta del trabajo realizado

entre cada iteracin: Se mantendrn abierta siempre la posibilidad a cambio y
replanteamiento de la forma de resolucin del problema.

Comunicacin osmtica, es decir que se prefiere la comunicacin presencial en

un mismo ambiente entre los miembros del equipo a fin de agilizar el desarrollo
y resolver inconvenientes rpidamente.

Tambin incluye otras propiedades adicionales como, la seguridad personal, el

enfoque en la persona, el fcil acceso de los usuarios al sistema, las pruebas

8
automatizadas, la gestin de configuraciones y la integracin frecuente en todas las
iteraciones.

En esta metodologa se tienen los siguientes roles:

Patrocinador ejecutivo

Jefe del proyecto

Experto en el dominio

Experto de uso

Programador diseador

Diseador de la interfaz de usuario

Realizador de Pruebas

Programador Tcnico

Teniendo en cuenta el objetivo del presente proyecto, los roles planteados sern
cubiertos por mi persona, con el eventual apoyo del asesor en los roles especficos
en los que se necesite.

Las herramientas que se utilizan en el desarrollo son

Catalogo simple de casos

Casos de uso

Requerimientos no funcionales

Arquitectura

Casos de prueba

Diseo de interfaz de usuario

Todos estos sern debidamente mostrados a lo largo del documento.

9
A continuacin, se muestra un grfico que resume las actividades que se realizan
con esta metodologa.

[1.7.1] Proceso Crystal Clear

Dada la breve explicacin de la metodologa, a continuacin se exponen las

razones por la que se propone como metodologa para el desarrollo.

La metodologa seleccionada es para equipos pequeos, cuyos integrantes

estn en constante comunicacin, lo cual se adapta claramente al equipo,
compuesto por dos personas.

Con esta metodologa se presentan entregas con cortos intervalos de tiempo,

esto corresponde con las entregas planificadas del presente proyecto.

Otra propiedad de esta metodologa es la de mejoras reflexivas, es decir, cada

iteracin representa una oportunidad de mejora para la siguiente, pudiendo
determinar puntos a mejorar en el camino. Lo cual es muy til para el proyecto
porque se requiere de constante aprendizaje en las tecnologas para mviles.

Esta metodologa se enfoca en las personas, por lo cual se requiere de

comunicacin constante y personal entre los miembros del equipo, adems se
promueve el trabajo en equipo y la ayuda mutua para superar obstculos en el
desarrollo.

10
Sin embargo, la metodologa se tiene que adaptar al proyecto, por lo cual se
realizarn los siguientes cambios:

Los roles sern adaptados por mi persona de acuerdo a la necesidad y la fase

del proyecto en la que se encuentre.

Cada iteracin ser semanal a fin de promover la mejora reflexiva y cumplir los
plazos del proyecto.

Cada iteracin contar con la revisin del asesor del proyecto, con el fin de
ajustar detalles no previstos en el documento.

Se generar la documentacin necesaria e indispensable para un proyecto de

fin de carrera.

1.7.2 Metodologa para la gestin del proyecto

Para la gestin del proyecto se utilizar la metodologa llamada Scrum, otra

metodologa gil que ser til por su facilidad de aplicacin en equipos pequeos,
flexibilidad a los cambios, colaboracin con el cliente y orientacin a los resultados.

Scrum utiliza el concepto de sprint, un periodo entre dos y cuatro semanas, dentro
del cual se mejora el sistema y los requerimientos no pueden cambiar. Entre
distintos sprints se puede cambiar la idea y el alcance del proyecto, previo anlisis.

Dentro de Scrum se tienen los siguientes roles:

Product owner, que representa al cliente, aunque tambin puede ser un

miembro del equipo con suficiente conocimiento del negocio. En el caso
particular de este proyecto, se considera que la persona apropiada para
afrontar este cargo sera mi madre, la cual es una odontloga y es la principal
fuente de conocimientos para el presente proyecto.

Scrum Master, quien es el encargado de verificar que el equipo funcione

correctamente, as como de organizar reuniones luego de los sprints.
Claramente, la persona a la que le corresponde este cargo es al asesor, el cual
velar por el buen desenvolvimiento y trabajo del equipo (mi persona).

Development team, el cual se encarga tanto del anlisis y diseo como del
desarrollo, pruebas y documentacin. Este cargo ser asumido enteramente

11
 por mi persona, tomando los roles particulares que sean necesarios en cada
caso.

Los documentos que se utilizan en Scrum son:

Product Backlog, que contiene los requerimientos y funcionalidades deseables.

Este documento es propenso a modificaciones en el transcurso del proyecto.

Sprint Backlog, en el cual se detalla la actividad del siguiente sprint, sin asignar
tareas a personas especficas.

Burn Down, en el cual se puede ver el avance del proyecto en base a los
requisitos pendientes.

En la seccin de anexos se presentarn algunos de estos documentos.

El proceso del Scrum tiene las siguientes actividades:

Creacin del Product Backlog.

Sprints, dentro de lo cual se incluye la creacin del Sprint Backlog.

Scrum diario, que es una aplicacin de la metodologa, pero a menor escala, el

cual se realiza diariamente dentro de un sprint.

Incremento potencial del producto entregable.

Adicionalmente a estos procesos ya definidos, se presentarn documentos de

avance y tareas realizadas, para tener una clara idea de la fase en la que se
encuentra el proyecto.

12
El siguiente grfico muestra un resumen de este proceso, cabe decir que este
proceso es cclico.

[1.7.2] Proceso Scrum

Se seleccion esta metodologa por la naturaleza del proyecto, con pocos

miembros en el equipo, plazos cortos de avances del proyecto, posibilidad de
mejora o variacin del producto en el camino y la necesidad de reuniones con el
asesor en el transcurso del proyecto.

1.8. Justificacin del proyecto

En los acpites anteriores se ha descrito la problemtica encontrada en los
establecimientos de salud pblicos y, en particular, en el manejo de sus historias
clnicas y fichas odontoestomatolgicas.

Como soluciones a los problemas encontrados se propone lo siguiente:

Generacin de un protocolo de homogenizacin de historias clnicas

odontolgicas.

Con dicha implementacin se propone crear reglas de estandarizacin que

beneficiarn tanto al manejo del establecimiento de salud como a los pacientes.
Mediante la generacin de WebServices se permitir una fcil interaccin entre
el protocolo y los sistemas que deseen acceder a este.

Ms all de resolver los problemas expuestos, una solucin de esta ndole

presenta un potencial inimaginable a ser utilizado; no solo por el lado
transaccional sino tambin por otras reas como las siguientes:

13
 El rea de Inteligencia de negocios, ya que esta monopolizacin de
informacin resultara infinitamente relevante para la generacin de
reportes de toda ndole.

El rea de Inteligencia artificial, mediante el uso de diversos algoritmos

y/o sistemas expertos, se pueden realizar predicciones sobre posibles
brotes de enfermedades, por ejemplo.

Con la implementacin de dicho protocolo se espera lograr crear un precedente

de los beneficios que esta clase de monopolizacin de informacin traera al
sistema de salud.

Generacin de una aplicacin mvil de manejo de historias clnicas y

funcionalidades odontolgicas.

Tomando en cuenta la descripcin del problema en puntos anteriores se ha

identificado que la implementacin de una aplicacin mvil puede solucionar
los mismos, as como brindar nuevas oportunidades al odontlogo.

En base a la toma de requerimientos a realizar se desarrollar una aplicacin

mvil que servir para realizar los mantenimientos de historias clnicas
odontolgicas y tambin para mltiples funcionalidades que sern definidas en
el camino.

El objetivo de esta solucin planteada es presentar al profesional odontlogo

una aplicacin que verdaderamente le sea til en sus quehaceres diarios y
presente todas las funcionalidades que se necesite.

Recapitulando lo explicado, se plantea como propuesta de valor de las

presentes soluciones, lo siguiente:

Generacin de un protocolo de homogenizacin de datos.

Publicacin de servicios que permitan la integracin del protocolo con otros

sistemas externos.

Definicin de una aplicacin que consuma los servicios del nuevo protocolo
generado.

Generacin de una aplicacin mvil para satisfacer las necesidades del usuario.

Tras el desarrollo del presente proyecto, se plantea generar una herramienta que
permitir la automatizacin en el proceso de mantenimiento de historias clnicas y
fichas estomatolgicas; esto beneficiara a tres grupos de personas:

14
 El rea administrativa de los establecimientos de salud pblicos, ya que podrn
asegurar el cumplimiento de la normativa necesaria [NTHC].

Los odontlogos y otros profesionales de la salud, ya que tendrn el acceso en

tiempo real de la informacin contenida en la historia clnica del paciente.

Los pacientes, estos sern los mayores de manera indirecta ya que, contando
con los procesos automatizados, mejorarn los tiempos de atencin y su
relacin con el establecimiento de salud.

Con respecto al valor terico del proyecto, se generarn modelos de procesos

sobre el actual manejo de las historias clnicas; esta informacin podra ser utilizada
por la institucin para identificar los problemas en la atencin y, ltimamente,
generar consciencia sobre los beneficios de esquematizar la institucin.

1.9. Viabilidad del proyecto

A continuacin se evala la viabilidad del proyecto, as como el anlisis tcnico y
econmico para establecer costos. Del mismo modo, se presenta el diagrama de
clases del sistema que servir de base para el trabajo posterior.

1.9.1 Viabilidad del sistema

El presente proyecto de fin de carrera tiene como uno de sus productos finales un
banco estandarizado de historias clnicas odontolgicas, el cual intentar resolver
los problemas descritos anteriormente referentes a custodia, conservacin,
confidencialidad y acceso a la historia clnica, dictaminados en la Norma Tcnica
de Salud para la Gestin de la Historia Clnica [NTHC].

Actualmente, el Ministerio de Salud no dictamina un mtodo estndar para la

manipulacin automatizada de historias clnicas, es por ello que los
establecimientos de salud pblicos recurren a la utilizacin de los procesos
manuales para el manejo de las mismas sin sopesar que, en su mayora, infringen
las normas [NTHC]. A pesar de esto, los establecimientos de salud pblicos tienen
una gran cantidad de fondos disponibles no utilizados [ENSF], los cuales nos
serviran para el financiamiento del proyecto y adquisicin de hardware necesario.

Es necesario considerar que en el mercado existen varias herramientas y

tecnologas disponibles para el desarrollo de aplicaciones mviles por lo que no

15
sera un obstculo para su viabilidad, por el contrario, permiten disminuir los
tiempos del desarrollo y mejorar las funcionalidades.

En dicho contexto, la implementacin de un banco estandarizado de historias

clnicas permitira monopolizar la informacin relacionada y cumplir con los
estndares dictaminados [NTHC]. Asimismo, es necesario implementar una
aplicacin que aproveche dichas ventajas y que, mediante sus funcionalidades,
permita al profesional de salud manipular dicha informacin.

En base a estas consideraciones, se considera que el desarrollo del presente

proyecto adquiere importancia y es altamente viable dentro del escenario
planteado. Dejando, adems, una ventana abierta a posibles ampliaciones y
mejoras en el futuro.

1.9.2 Anlisis tcnico y econmico

Para las caractersticas tcnicas se tom en cuenta el aprovechamiento de software

libre, as como la flexibilidad para la arquitectura propuesta y las tendencias en el
uso de dispositivos mviles. Por lo tanto, se tendrn en cuenta las siguientes
consideraciones para la API y la aplicacin mvil a desarrollar:

Para la API se utilizar el lenguaje de programacin Ruby.

El acceso a datos se realizar mediante REST.

El sistema operativo sobre el cual se desarrollar es Ubuntu 12.04.

La aplicacin mvil ser para tabletas.

El lenguaje de la aplicacin mvil ser Java para Android.

Se utilizar una base de datos Postgresql.

Adems, se valorizar econmicamente el proyecto, tomando en cuenta todos los

gastos en los que se deba incurrir para finalizarlo. El software y herramientas a
utilizar son de libre distribucin, por lo que no generarn costos adicionales. En este
caso, el nico gasto en el que se incurrir ser el de hora/hombre trabajada. En el
siguiente grfico se muestra un costo tentativo estimado para la realizacin del
presente proyecto, es necesario resaltar que estos resultados son netamente
tericos y podran diferir de la realidad.

16
 COSTO ECONMICO

Das trabajados 151

Horas por da 8

Horas trabajadas 1,208

Costo por hora (S/) 20

Costo total (S/) 24,160

[Fig. 1.9.2] Costos tentativos del proyecto

17
1.10. Plan del proyecto
1.10.1 EDT

A continuacin, se muestra el EDT a tomar en cuenta para la realizacin del proyecto.

ANLISIS, DISEO E IMPLEMENTACIN DE UN BANCO

ESTANDARIZADO DE HISTORIAS CLNICAS PARA
ESTABLECIMIENTOS DE SALUD PBLICOS Y APLICACIN
MVIL ODONTOLGICA

1. Evaluacin 2. Anlisis de La 3. Diseo de la 4. Construccin 5. Desarrollo de la

del negocio. solucin. solucin de la solucin solucin

1.1
Funcionamient 2.1 3.1
4.1 Construccin
o Actual de la Metodologa Arquitectura de
de la solucin 5.1 Sprint 1
empresa. de la Solucin la solucin

3.2 Diseo de 4.2

1.2 Reglas de la interfaz Planificacin
2.2 Identificacin
negocio grfica de pruebas 5.2 Sprint 2
de
Requerimientos

1.3 Estado del 3.3

arte. Arquitectura
2.3 Anlisis de 5.3 Sprint 3
de
la solucin Informacin
1.4
Planificacin
del Proyecto. 5.4 Sprint 4

1.5
Generacin de
conclusiones.
5.5 Sprint 5

1.6
Sustentacin
de la solucin
5.6 Sprint 6

[1.10.1] EDT (Estructura de Desglose de Trabajo)

 1.10.2 Planificacin de las tareas

El siguiente cuadro es el plan del tiempo estimado a emplear en el proyecto,

considerar que las tareas sern realizadas en orden descendente.

Task Name Duration Predecessors Start Finish

Sprint 0 21 days Thu 01/11/12 Thu 29/11/12
Elaboracin de Product
7 days Thu 01/11/12 Fri 09/11/12
Backlog
Elaboracin de Sprint Mon
7 days 3 Tue 20/11/12
Backlog 12/11/12
Elaboracin de Sprint Wed
7 days 4 Thu 29/11/12
Backlog 21/11/12
Wed
Sprint 1 14 days Fri 30/11/12
19/12/12
Wed
Constitucin del proyecto 4 days 5 Fri 30/11/12
05/12/12
Wed
Captulo 1 10 days Thu 06/12/12
19/12/12
Definicin del problema 1 day 7 Thu 06/12/12 Thu 06/12/12
Objetivo general 1 day 9 Fri 07/12/12 Fri 07/12/12
Mon Mon
Objetivos especficos 1 day 10
10/12/12 10/12/12
Resultados esperados 1 day 11 Tue 11/12/12 Tue 11/12/12
Wed Wed
Alcance 1 day 12
12/12/12 12/12/12
Limitaciones 1 day 13 Thu 13/12/12 Thu 13/12/12
Mtodos y
1 day 14 Fri 14/12/12 Fri 14/12/12
procedimientos
Justificacin del Mon Mon
1 day 15
proyecto 17/12/12 17/12/12
Viabilidad del proyecto 1 day 16 Tue 18/12/12 Tue 18/12/12
Wed Wed
Plan de proyecto 1 day 17
19/12/12 19/12/12
Sprint 2 14 days Thu 20/12/12 Tue 08/01/13
Captulo 2 14 days Thu 20/12/12 Tue 08/01/13
Marco conceptual 7 days 18 Thu 20/12/12 Fri 28/12/12
Mon
Estado del arte 7 days 21 Tue 08/01/13
31/12/12
Wed Mon
Sprint 3 14 days
09/01/13 28/01/13
Wed Mon
Captulo 3 14 days
09/01/13 28/01/13
Identificacin de Wed
3 days 22 Fri 11/01/13
requerimientos 09/01/13
Arquitectura de la 3 days 25 Mon Wed

19
solucin 14/01/13 16/01/13
Diseo de interfaz
2 days 26 Thu 17/01/13 Fri 18/01/13
grfica
Arquitectura de Mon Wed
3 days 27
informacin 21/01/13 23/01/13
Diagrama de base de Mon
3 days 28 Thu 24/01/13
datos 28/01/13
Sprint 4 14 days Tue 29/01/13 Fri 15/02/13
Captulo 4 14 days Tue 29/01/13 Fri 15/02/13
Wed
Construccin 7 days 29 Tue 29/01/13
06/02/13
Pruebas 7 days 32 Thu 07/02/13 Fri 15/02/13
Mon
Sprint 5 14 days Thu 07/03/13
18/02/13
Mon
Captulo 5 14 days Thu 07/03/13
18/02/13
Mon
Observaciones 5 days 33 Fri 22/02/13
18/02/13
Mon
Conclusiones 5 days 36 Fri 01/03/13
25/02/13
Recomendaciones y Mon
4 days 37 Thu 07/03/13
trabajos futuros 04/03/13
Sprint 6 14 days 23 Tue 29/01/13 Fri 15/02/13
Wed
Desarrollo de la API (50%) 7 days Tue 29/01/13
06/02/13
Set de pruebas 1 7 days 40 Thu 07/02/13 Fri 15/02/13
Mon
Sprint 7 14 days Thu 07/03/13
18/02/13
Desarrollo de la API Mon
7 days 41 Tue 26/02/13
(100%) 18/02/13
Wed
Set de pruebas 2 7 days 43 Thu 07/03/13
27/02/13
Wed
Sprint 8 14 days Fri 08/03/13
27/03/13
Desarrollo de la aplicacin Mon
7 days 44 Fri 08/03/13
mvil (25%) 18/03/13
Wed
Set de pruebas 3 7 days 46 Tue 19/03/13
27/03/13
Sprint 9 14 days Thu 28/03/13 Tue 16/04/13
Desarrollo de la aplicacin
7 days 47 Thu 28/03/13 Fri 05/04/13
mvil (50%)
Mon
Set de pruebas 4 7 days 49 Tue 16/04/13
08/04/13
Wed Mon
Sprint 10 14 days
17/04/13 06/05/13
Desarrollo de la aplicacin Wed
7 days 50 Thu 25/04/13
mvil (75%) 17/04/13

20
 Mon
Set de pruebas 5 7 days 52 Fri 26/04/13
06/05/13
Sprint 11 14 days Tue 07/05/13 Fri 24/05/13
Desarrollo de la aplicacin Wed
7 days 53 Tue 07/05/13
mvil (100%) 15/05/13
Set de pruebas 6 7 days 55 Thu 16/05/13 Fri 24/05/13
Mon
Sprint 12 14 days Thu 13/06/13
27/05/13
Mon
Finalizacin del proyecto 7 days 56 Tue 04/06/13
27/05/13
Wed
Presentacin final 7 days 58 Thu 13/06/13
05/06/13

21
22
23
24
CAPTULO 2

2.1 Marco Conceptual

2.1.1. Historia clnica

La historia clnica es un documento fundamental en que se recoge la descripcin

ordenada, completa y precisa de la experiencia que el profesional de salud obtiene
en su relacin directa y tcnica con los pacientes [NTHC]. En su definicin ms
bsica es un instrumento mdico legal de gran utilidad para el personal del rea
de la salud. Su importancia radica en el simple hecho de que es una herramienta
til en los establecimientos de salud (pblicos o privados) y en los establecimientos
de orden judicial, sirviendo para el reconocimiento forense o arbitrajes penales. La
historia clnica, de acuerdo con las normas generales de la ciencia de la salud, es el
resultado del trabajo medico en el paciente; la realizacin de la fase cognoscitiva de
la relacin mdico paciente tendr un anlisis o sntesis que ser conocido como
diagnstico y tratamiento.

Resulta necesario destacar las caractersticas de la historia clnica:

25
 Integridad: La historia clnica debe recoger todo dato relevante para la atencin
del paciente.

Precisin: La historia clnica es un documento dnde debe usarse la

terminologa cientfico tcnica apropiada. Bajo ningn aspecto la terminologa
debe ser ambigua.

Claridad: Los datos que aparecen en la historia clnica deben expresarse de

manera inequvoca, que no pueda dar lugar a dudas o diversidad de
interpretaciones.

Legibilidad: La caligrafa del profesional y sus colaboradores debe ser

interpretada por terceros.

Descriptiva: Describir la patologa dental del paciente con la mayor precisin

posible.

Cronologa: Se confecciona desde el momento en que el paciente realiza su

primera consulta y contina su evaluacin a lo largo del tratamiento dental.

En las siguientes figuras [Fig. 2.1.1.1 2.1.1.4] podemos apreciar un modelo de

historia clnica utilizado en la actualidad en los establecimientos de salud pblicos
relacionados al Ministerio de Salud (MinSa), cuyo contenido se encuentra normado
[NTUO]. En ella se puede apreciar que se busca registrar la mayor cantidad de
informacin relevante sobre el paciente, desde datos de contacto hasta posibles
enfermedades o estados de salud particulares en los que se encuentre, los cuales
determinarn la clase de tratamiento a la cual se podr someter.

26
[Fig. 2.1.1.1] Historia clnica Hoja 1

27
[Fig. 2.1.1.2] Historia clnica Hoja 2

28
[Fig. 2.1.1.3] Historia clnica Hoja 3

29
[Fig. 2.1.1.4] Historia clnica Hoja 4

30
2.1.2. Odontograma:

Se trata del diagrama ms utilizado para hacer el registro del estado de los dientes
contenidos en la boca de un paciente; dicho registro se realiza mediante el uso de
signos que representan el estado en los que estos se encuentran con toda precisin
y, a la vez, ahorra espacio y tiempo. Tambin son conocidos como diagramas
dentarios o fichas odontoestomatolgicas [NTUO].

En la figura [Fig. 2.1.2.1] podemos observar un ejemplo de un odontograma que es

utilizado en un establecimiento de salud pblico. Se trata de un papel en tamao de
hoja A3, el cual es adhiri a la historia clnica del paciente. Por su carcter
rudimentario, es comnmente usado en grandes campaas mdicas, en la cual se
tiene un tiempo reducido de atencin por paciente y es necesario recabar la mayor
cantidad de informacin posible [ENSF].

[Fig. 2.1.2.1] Modelo de odontograma

31
En la imagen [Fig. 2.1.2.2] podemos observar la versin extendida de la ficha
estomatolgica que se present anteriormente, esta es comnmente adherida al
archivo que contiene la historia clnica del paciente. Como se puede visualizar,
permite mantener el registro de los tratamientos que han sido efectuados para que
el profesional de salud de turno los tome en cuenta.

[Fig. 2.1.2.2] Modelo de odontograma extendido

32
2.1.3. Norma tcnica de salud para la gestin de la historia clnica

Esta norma tiene como finalidad contribuir a mejorar la calidad de atencin a los
usuarios de los servicios de salud a travs de una adecuada gestin de las
Historias Clnicas, as como a proteger los intereses legales de los usuarios, del
personal de salud y de los establecimientos de salud.

Sus principales objetivos son:

Establecer las disposiciones para el manejejo, conservacin y depuracin de

la Historia Clnica en todos lso establecimientos de salud pbclis y privados
del Sector Salud.

Establecer y estandarizar el contenido bsico a ser registrado en la Historia

Clnica, teniendo en cuenta los diferentes tipos de atencin, respetando los
aspectos legales y administrativos.

Como se ha mencionado con anterioridad, el objetivo principal del presente

proyecto es desarrollar un sistema de informacin que permita a los
establecimientos de salud pblicos que cuenten con el programa de salud bucal
activo cumplir con las clusulas referentes a custodia, conservacin,
confidencialidad y acceso a la historia clnica, dictaminados en la esta norma, por lo
que es imperativo considerarla dentro del marco normativo legal a cumplir.

2.1.4. Directiva administrativa sobre especificaciones tcnicas mnimas para

sistemas informticos en el Ministerio de Salud [ETSI]

Esta directiva tiene como finalidad contribuir a la integracin de contribuir a la

integracin de los Sistemas Informticos del Ministerio de Salud y sus
dependencias. Sus principales objetivos es definiri las especificaciones tcnicas
mnimas para sistemas informticos a implantarse en el Ministerio de Salud y sus
dependencias.

Como especificaciones tcnicas mnimas se encuentran:

Uso de Interfaces Web para el acceso de usuarios.

Uso de lenguajes de programacin estndares.

Uso de sistema de gestin de base de datos para el almacenamiento de

datos.

Intercambio de informacin entre sistemas informticos.

33
2.2 Estado del arte
Como se mencion anteriormente, el problema planteado ha sido acotado a
establecimientos de salud pblicos que cuenten con el programa de salud bucal
activo, en donde se han presentado tambin falencias tecnolgicas [ENSF]. A
continuacin, se muestra el sistema actual de manejo de historias clnicas
manuales utilizado en los establecimientos pblicos, junto con algunos ejemplos de
aplicaciones mviles de uso odontolgico existentes que son mayormente utilizadas
en el mercado privado.

2.2.1 Sistema de manejo manual de historias clnicas

Este sistema referencia el actual manejo de las historias clnicas odontolgicas en

los establecimientos de salud pblicos. El proceso se inicia con el acercamiento del
paciente al establecimiento de salud pblico de su eleccin, donde se indagar si
es su primera atencin en dicho establecimiento. De ser negativa la respuesta, se
proceder a buscar su historia clnica en el cuarto de almacenamiento y continuarn
con el proceso propio de atencin; de lo contrario, se har el triaje respectivo
(incluye medicin de talla, peso, temperatura y presin arterial del paciente),
iniciando as la elaboracin de la nueva historia clnica.

Posteriormente, una vez iniciado el procedimiento odontolgico, el profesional de

salud proceder a reportar las condiciones bucales del paciente, los tratamientos
realizados y las indicaciones que crea conveniente en un nuevo odontograma [Fig.
3]; para finalmente adherir dicha hoja a la historia clnica del paciente.

Los procesos relacionados al sistema de manejo manual de historias clnicas sern

profundizados en el acpite 3.3 Arquitectura de Informacin, en donde se propondr
definir el flujo de negocio con el fin de poder establecer un modelo de datos
adecuado para la solucin.

34
2.2.2 EdgeDMS

Esta aplicacin fue realizada por la compaa Edge EHR Corp. Dicha aplicacin
funciona para iPad y permite al usuario un rpido mantenimiento de pacientes con
un nivel de descripcin del estado bucal del paciente bastante detallado. Adems,
la aplicacin es considerada nativa a diferencia de sus competidores utilizando
tecnologa VNC. Finalmente, ofrece conexin directa a la aplicacin del mismo
nombre para MAC mediante VPN, lo cual garantiza que los datos guardados no se
encuentren solamente almacenados en el iPad. Un video representando las
principales funcionalidades de este software en su versin para iPad puede ser
encontrado en la siguiente direccin [EDMS].

En la figura [Fig. 1.3.2] podemos apreciar una de las funcionalidades de este

programa, donde podemos visualizar la forma intuitiva en el que se nos presenta
cada diente del espectro bucal para poder detallar su estado.

[Fig. 1.3.2] Aplicacin EdgeDMS para iPad

35
2.2.3 My Dentist

Esta aplicacin fue realizada por Dental Anywhere [MDDA] y presenta

compatibilidad con iOS y Android. Su principal funcionalidad reside en la posibilidad
que tienen los pacientes de conectarse directamente con su odontlogo, con el fin
de recibir consejos e instrucciones en caso de emergencias o cuando se crea
necesario. Adems, presenta interaccin directa con el calendario interno del
dispositivo, el cual le permite sincronizar citas con el odontlogo. Adicionalmente,
permite la reserva de citas en tiempo real, sin la necesidad de mayor comunicacin
o confirmacin.

En la imagen [Fig. 1.3.3] podemos apreciar el men principal de la aplicacin, la

cual nos ofrece diversas funcionalidades para contactar al odontlogo asignado,
registrar citas, entre otras.

[Fig. 1.3.3] Aplicacin My Dentist

36
2.2.4 My Dental Hub Mobile Patient Education

A diferencia de las otras presentadas, esta aplicacin es de carcter informativo

[MDHU]. A travs de ella se puede aprender nuevos temas relacionados a la
odontologa.

En el men de opciones mostrado en la figura [Fig. 1.3.4] se nos muestra la

informacin agrupada por categoras: endodoncia, esttica, implantes, etc.; y en
cada una de ellas informacin detallada de los temas en los que se desee
profundizar.

[Fig. 1.3.4] My Dental Hub Mobile Patient Education

37
CAPTULO 3

El captulo a tratar muestra informacin detallada sobre el anlisis y diseo de la

solucin; esto incluye la identificacin de los requerimientos del sistema, el
diagrama de base de datos, la arquitectura de la solucin, el diseo de la interfaz
grfica y la arquitectura de informacin; tanto para la elaboracin del protocolo de
estandarizacin como para la aplicacin mvil.

3.1. Identificacin de requerimientos

En esta seccin se muestra la lista de requerimientos identificados para resolver el

problema planteado, tanto funcionales como no funcionales. Al finalizar la
identificacin de los mismos, se puede considerar como cumplido el resultado
esperado C del acpite 1.4

38
3.1.1. Requerimientos Funcionales

Los requerimientos funcionales de la Api y la aplicacin mvil son los siguientes:

R1. La API debe brindar un estndar de informacin en una historia clnica

odontolgica.

R2. La API debe permitir la trazabilidad de los diagnsticos de los pacientes.

R3. La API debe permitir la utilizacin de informacin de distintas instituciones

en forma nica.

R4. La API solo debe permitir el acceso a aplicaciones registradas.

R5. La API debe permitir el mantenimiento de usuarios.

R6. El sistema debe permitir el mantenimiento de pacientes

R7. El sistema debe permitir el filtro de informacin por paciente y/o institucin
mdica.

R8. El sistema debe permitir la consulta de la historia clnica de un paciente.

R9. El sistema debe permitir ingresar nuevas pginas de historia clnica.

R10. El sistema debe permitir ingresar informacin adicional no contemplada

en la historia clnica de un paciente.

R11. El sistema debe permitir cargar imgenes para complementar la

informacin odontolgica del paciente

R12. El sistema debe mostrar grficamente la informacin odontolgica del

paciente.

R13. El sistema debe permitir generar reportes sobre los resultados de los
anlisis.

R14. El sistema debe permitir enviar por correo la informacin de los reportes.

R15. El sistema debe permitir administrar la informacin que se desee

compartir con el paciente.

R16. La API debe almacenar la informacin de auditora pertinente al acceso a

la misma.

R17. La API debe generar reportes de auditora.

39
3.1.2. Requerimientos No Funcionales

Los requerimientos no funcionales son los siguientes:

R18. El sistema debe ser desarrollado para aplicaciones mviles destinadas

para el uso de tablets con sistema operativo Android.

R19. La API debe ser desarrollada utilizando Ruby on Rails.

R20. La API debe hacer uso de tecnologas REST para permitir la

comunicacin con las aplicaciones.

R21. El sistema debe soportar el trabajo sin conexin a la API.

R22. El sistema debe realizar almacenamiento continuo en el dispositivo, hasta

que se desee interactuar con la API.

3.2. Arquitectura de la solucin

Considerando la solucin planteada, presentaremos dos enfoques con respecto a la

arquitectura a utilizar.

3.2.1. Arquitectura Web

La solucin planteada requiere que se mantenga la integridad y disponibilidad de la

informacin en todo momento a fin de evitar inconvenientes; como por ejemplo, la
solicitud de modificacin de una historia clnica que se encuentra actualmente en
procesamiento, el borrado de informacin sobre un paciente actualmente activo,
entre otros. Debido a esto, se propone la implementacin de un modelo de dos
capas.

Capa de acceso a datos

40
La capa de acceso a datos es la encargada de proveer de la informacin
almacenada en la base de lgica de negocio, segn esta la requiera. Esta capa
asegurar que la informacin proporcionada sea la ms reciente (en tiempo real), y
evitar que surjan problemas de inconsistencia en la informacin debido a
transacciones simultneas.

Dado que se est tratando con el almacenamiento de todas las historias clnicas a
nivel nacional se puede asumir un alto ndice de transacciones concurrentes que el
sistema debe de soportar. Tomando esto en consideracin, se plantea la
arquitectura multicapa, considerando la Presentacin como la aplicacin mvil.

Esta es representada en la imagen [Fig. 3.1.1.1] en el nivel superior dentro de los

servidores, ya que es independiente de los dispositivos mviles o plataformas que
se utilicen.

Capa de lgica de negocio

Esta capa es la encargada de almacenar los servicios REST desarrollados para la

comunicacin de los aplicativos mviles con la Base de Datos. En esta capa se
procesan todos los requerimientos que realicen los usuarios de interaccin con el
sistema. Aqu se encontrarn los procedimientos y funciones que permitirn el
manejo de historias clnicas y todas las funcionalidades propuestas.

Esta es representada en la imagen [Fig. 3.2.1.1] siguiendo la capa de acceso a

datos, esto se debe a que sirve de intermediaria entre esta capa base y los
dispositivos mviles que se utilicen para acceder a la aplicacin.

41
 [Fig. 3.2.1.1] Modelo de 3 capas

Como puede observarse en la figura [Fig. 3.2.1.1], la capa de acceso a datos y la

capa de Lgica de Negocio se encontrarn en los servidores puesto que la base de
datos ser centralizada a nivel nacional, y el procesamiento de los requerimientos
del usuario se realizar centralizadamente (a fin de aligerar a los clientes).

42
La capa de presentacin estar presente en los dispositivos mviles, y se
encargarn de enviar peticiones, mostrar informacin y almacenar los cambios
realizados de forma preliminar antes de contactarse con los servidores. A
continuacin. se muestra la arquitectura detallada [Fig. 3.2.1.2].

[Fig. 3.2.1.2] Arquitectura de la solucin

En lo que respecta al patrn de diseo, para este sistema se ha elegido el diseo

Modelo Vista Controlador. Este patrn segmenta al sistema en: componentes
de interfaz de usuario (que sern las vistas), el modelo del negocio y la lgica de
control. Este patrn [3.2.1.3] es el ms utilizado para esta clase de aplicaciones.
Para entender mejor en qu consiste cada segmento de este patrn, se detallarn a
continuacin:

Modelo. Engloba a las capas de acceso a datos y lgica de negocio, y se

considera como una representacin especfica de la informacin con la que el
sistema trabaja. Adems, esta informacin es relativa a su vista y controlador.
Representa a la capa de lgica de negocio.

Vista. Engloba la capa de presentacin. Una vista se considera como una

fotografa de un instante del modelo. Representa a la capa de presentacin.

43
 Controlador. No engloba ninguna capa. Se encarga de capturar los eventos
generados por el usuario (mediante la interfaz grfica), y de realizar peticiones
al modelo (ya sea de informacin o de procesamiento). Representa a la capa
de acceso a datos

[Fig. 3.2.1.3] Arquitectura de la solucin

La ventaja de utilizar este patrn de diseo, es que el sistema se vuelve escalable,

dado que sus partes pueden variar, pero eso no afectara al conjunto. Esto es
particularmente importante a las asunciones realizadas anteriormente donde se
espera que la API a desarrollar sea utilizable por aplicaciones independientes a la
realizada y as lograr una mayor amplitud en el mercado objetivo y la utilizacin del
protocolo.

Vista lgica

Como se mencion anteriormente, el lenguaje de programacin elegido es Ruby

utilizando el framework Rails (Ruby on Rails). Este lenguaje utiliza una tcnica
llamada Object-Relational Mapping (ORM) [Fig. 3.2.1.4] que permite manejar
integradamente objetos y su respectiva tabla en la base de datos, de manera que el
programador consulta directamente a la base de datos cuando se utiliza un modelo.

44
 [Fig. 3.2.1.4] ORM con Active Record

Vista despliegue

Fsicamente, la arquitectura del sistema considerar clientes ligeros que tengan

acceso a internet y satisfagan el esquema de los servicios propuestos. Asimismo, el
sistema deber contar con un servidor web donde se encontrarn los servicios y
donde se procesarn las peticiones de cada cliente. Finalmente, se debe contar
tambin con un servidor de base de datos, donde se almacenar la informacin
recabada por el sistema. A continuacin, se muestra [Fig. 3.2.1.5] el diagrama de
despliegue del sistema.

[Fig. 3.2.1.5] Vista despliegue

3.2.2. Arquitectura mvil

45
La arquitectura mvil para la solucin planteada representar la capa de
presentacin [Fig. 3.2.1.1] detallada anteriormente.

Capa de presentacin

En esta capa el usuario podr interactuar con la aplicacin mediante peticiones y

respuestas que sern procesadas por la capa de Lgica de Negocio. En esta capa
estn representados todos los dispositivos para los que se desee mantener una
interfaz, la capa de lgica de negocio los manejar indistintamente de la
procedencia de estos.

46
3.3. Diseo de Interfaz Grfica

Considerando la solucin planteada, la API no presenta una necesidad de interfaz

grfica. En cambio, nos vemos en la necesidad de la generacin de un documento
en el cual se representen los estndares de diseo a seguir para la creacin de la
aplicacin mvil.

En dicho documento se definirn los controles que sern aplicados en la aplicacin

mvil, la razn y ejemplo de cada uno.

El documento planteado se encuentra en el anexo: [7.1 Documento de estndares

e interfaz grfica para aplicacin mvil]

3.4. Arquitectura de Informacin

Para la definicin del modelo de datos es necesario definir el Flujo del Negocio bajo
el que se somete el sistema actual. Es por ello que se ha generado un diagrama
BPMN utilizando la herramienta BizAgi Process Modeler [BIZAGI] para el fcil
entendimiento de este flujo.

Con esto se logra obtener el resultado esperado B del acpite 1.4.

3.4.1. BPMN

Para el entendimiento del uso actual del sistema de manejo de historias clnicas, se
ha dividido el mismo en dos partes, la obtencin de las historias clnicas (bsqueda
o generacin de nuevas) y la utilizacin de las mismas por parte de los
odontlogos.

47
3.4.2. Obtencin de Historias Clnicas Odontolgicas:

A continuacin, se muestra el diagrama en notacin BPMN generado para la Obtencin de Historias Clnicas Odontolgicas

[Fig. 3.4.2] Obtencin de Historias clnicas

48
Ahora se proceder a describir los procesos mostrados en el diagrama [3.3.2]:

Solicitar atencin en Centro Mdico:

Este proceso simboliza al paciente acercndose al rea de recepcin de un centro

mdico solicitando su atencin en el servicio odontolgico.

Buscar Historia Clnica:

Si esta no es la primera vez que el paciente acude a dicha institucin, se procede a

buscar su historia clnica.

Iniciar Registro de Nueva Historia Clnica:

Si esta es la primera vez que el paciente acude a dicha institucin, se procede a

iniciar el proceso de registro de una nueva historia clnica. Esto se realiza
asignando una carpeta con documentos a dicho paciente.

Tomar datos Generales del Paciente:

En este proceso, una persona encargada de admisin obtiene los datos generales
del paciente, como nombre, edad, direccin, telfono, sexo, fecha de nacimiento,
etc.

Realizar Triaje:

Este proceso contempla la toma de talla, peso, temperatura y presin arterial del
paciente. Este proceso no est completamente estandarizado para todas las
instituciones que contemplen tratamiento odontolgico, pero se est empezando a
realizar como buena prctica.

Enviar Historia Clnica al Odontlogo:

Este proceso simboliza que un encargado de admisin ya posee una historia clnica
del paciente (se encontr la historia clnica de un paciente antiguo o se gener una
de un nuevo) y proceder a llevarlo al odontlogo designado para su atencin.

49
3.4.3. Utilizacin de Historias Clnicas Odontolgicas:

A continuacin, se muestra el diagrama BPMN generado para la Utilizacin de Historias Clnicas Odontolgicas

[Fig. 3.4.3] Utilizacin de Historias clnicas

50
Ahora se proceder a describir los procesos mostrados en el diagrama [3.3.3]:

Realizar Anamnesis:

Una vez que es el turno de atencin del paciente y el odontlogo ya tiene su historia
clnica, se procede a realizar la anamnesis. Esto no es ms que la formulacin de
una serie de preguntas por el profesional para determinar la salud actual del
paciente y tomar nota de cualquier mencin necesaria que este tenga que hacer.
Junto con estas preguntas se procede a realizar un examen odontolgico del
paciente (odontograma) para saber su estado actual. Tomar en cuenta que este
proceso es idntico as el paciente sea nuevo o antiguo. Todos los apuntes
necesarios son colocados en la historia clnica.

Proponer Tratamiento:

Una vez que se tiene la historia clnica actualizada del paciente, se procede a
realizar la atencin normal del mismo, atendiendo las dolencias que lo aquejan.
Tras determinar las causas de las dolencias se propone un tratamiento a dicho
paciente.

Derivar Paciente:

Si se determina que el tratamiento propuesto no es realizable en esos momentos

por algn motivo (falta de insumos, falta de tiempo, necesidad de mayor personal,
etc.) se informa de esto al paciente y se le deriva a una institucin que s pueda
atenderlo de tener un carcter urgente, de lo contrario se reprograma una cita.

Realizar Tratamiento:

Si se determina que el tratamiento propuesto es realizable en esos momentos, se

informa al paciente y procede a realizarlo.

Registrar tratamiento en Historia Clnica:

Si se opt por realizar el tratamiento, al finalizar este se dan comentarios finales al

paciente junto con recetas, de ser necesario. Tras la salida del paciente del
consultorio, el odontlogo procede a registrar las acciones realizadas en la historia
clnica para que quede evidencia del tratamiento seguido.

Enviar Historia Clnica a Admisin:

Este proceso simboliza la finalizacin de la utilizacin de la historia clnica por el

odontlogo (Se complet la anamnesis y/o se incluy el tratamiento realizado). Se
procede a enviar fsicamente la historia clnica al rea de Admisin, donde ser
almacenada en un lugar apropiado.

52
3.5. Diagrama de Base de Datos

En base a lo definido anteriormente, se puede obtener el modelo de datos y, a su

vez, representarlo como el diagrama de base de datos de la solucin a
implementar, culminando el resultado esperado A del acpite 1.4.A continuacin, se
muestra el diagrama de base de datos que se ha definido para el desarrollo del
proyecto, en el mismo se representan las principales entidades que han sido
consideradas necesarias para la implementacin de las funcionalidades propuestas.

[Fig. 1.4.3] Diagrama de base de datos

53
CAPTULO 4
En este captulo se presenta toda la tecnologa a utilizar para la creacin de la API y el
desarrollo de la aplicacin mvil, as como el plan de pruebas que validar el su correcto
funcionamiento.

4.1. Construccin
En este captulo se mostrarn y sustentarn las tecnologas, frameworks e ID a
utilizar para el desarrollo del proyecto.

El lenguaje de programacin Ruby [RUBY] fue seleccionado por las siguientes

razones:

Se requera un lenguaje para el paradigma de programacin orientada a

objetos.

El lenguaje tena que ser verstil ya que no es una aplicacin cualquiera, sino
que requiere interactuar con distintos sistemas.

Se buscaba un lenguaje que sea multiplataforma.

54
 Ruby es extensible ya que cuenta con las llamadas gemas, adems se puede
ampliar utilizando otros lenguajes, como C. En el logo del lenguaje, podemos
ver la referencia a las dichas gemas o libreras [Fig. 4.1.1]

El lenguaje es simple y dinmico, utilizando expresiones simples para sus

sentencias.

[Fig. 4.1.1] Logo del lenguaje de programacin Ruby

El framework a utilizar ser Ruby on Rails [Fig. 4.1.2], el cual sigue la arquitectura
de Modelo Vista-Controlador que ha sido definido anteriormente, el mismo est
programado en Ruby y hecho especialmente para este lenguaje de programacin.

[Fig. 4.1.2] Ruby on Rails

Durante el planteamiento de la solucin a brindar para el problema en anlisis, se

analiz la posibilidad de utilizar WebServices o Rest como medios para la creacin
y utilizacin de los servicios. Si bien el empleo del lenguaje Ruby nos lleva a utilizar
REST para las comunicaciones, se tienen las siguientes ventajas dadas por el uso
de dicha tecnologa:

Se hace uso de los mtodos HTTP: GET, POST, PUT y DELETE.

Las respuestas se pueden dar en distintos formatos, en este caso se

utilizar JSON.

55
 La codificacin en REST es menor y ms clara respecto a los web services
comunes.

Usa mtodos de URL para el mapeo de los datos.

Muchas libreras (gemas) de Ruby no funcionan correctamente en Windows o se

tienen dificultades para instalarlas. Es recomendable usar Linux para desarrollar en
Ruby, en este caso se escogi la distribucin Ubuntu 12.04 ya que era suficiente
para el correcto desarrollo del proyecto y su conocida facilidad de uso resultaba
relevante en la curva de aprendizaje.

En lo que respecta a la aplicacin mvil, se opt por desarrollarla para tabletas en

lugar de smartphones por las siguientes razones:

Son ms portables que las notebooks y a su vez tienen una pantalla tctil
ms grande que los celulares o PDAs.

La pantalla tctil permite una mejor interaccin del usuario con la aplicacin,
incluyendo la manipulacin de imgenes.

Se puede mostrar mayor cantidad de informacin al mismo tiempo que en

un Smartphone o un celular convencional.

En la actualidad las tabletas cuentan con conectividad 3G y 4G, gracias a lo

cual se pueden comportar como telfonos y computadoras portables al
mismo tiempo.

La aplicacin se desarrollara para el sistema operativo Android [Fig. 4.1.4], en este

caso las ventajas son mltiples, por ejemplo:

La posibilidad de Android para instalarse en la mayora de dispositivos

mviles estn volvindolo el sistema con mayor crecimiento en el mercado.

Android permite el desarrollo libre de aplicaciones, sin impedimento alguno

para ofrecer o instalar la aplicacin en la tableta.

Android cuenta con una gran comunidad y su gran crecimiento permite que
en la actualidad exista mltiple informacin sobre esta plataforma.

Android es compatible con tecnologas Web

El desarrollo es gil gracias a su SDK.

Para el desarrollo de aplicaciones en Android el lenguaje ms recomendado es

Java. El IDE seleccionado para tal motivo es Eclipse, debido a su estabilidad en el
sistema Linux y su versatilidad para desarrollos mviles.

56
El desarrollo de la aplicacin se enfocar para la versin Android 4.0.x, Ice Cream
Sandwich, ya que es la ms estable y a su vez la ms utilizada por los equipos en
la actualidad.

[Fig. 4.1.4] Android y Java

Para programar en Ruby el motor de base de datos es transparente, debido a que

se utiliza la biblioteca SQLite por defecto. En este caso se decidi utilizar una base
de datos en PostgreSQL, el cual contiene interfaces nativas para Ruby y adems
est disponible en casi cualquier sistema basado en Unix. Otra ventaja es que se
cuenta con mltiples aplicaciones para su administracin en Ubuntu.

57
4.2. Pruebas

Las pruebas son un proceso clave en todo desarrollo y ms an si consideramos

las metodologas giles que se han definido para este proyecto, ya que stas se
basan en una retroalimentacin constante tanto del cliente al recibir sus entregables
predeterminados como del mismo equipo de desarrollo al ver cmo avanza el
prototipo.

Las pruebas que se irn a desarrollar para corroborar el correcto funcionamiento de

las aplicaciones sern ejecutadas a lo largo de todo el proceso de implementacin
de cada uno de los mdulos (en cada Sprint, como se puede ver en el Diagrama
Gant). stas debern de ser llevadas a cabo por el equipo desarrollador dentro de
cada iteracin, y sta no ser considerada con una finalizacin exitosa si todas las
pruebas no lo son.

4.2.1. Tipos de Pruebas

Se ha definido correcto realizar los siguientes tipos de pruebas:

Prueba de Integracin

Estas pruebas buscan validar el correcto funcionamiento del sistema y el

cumplimiento de todos los requerimientos previamente acordados. A continuacin
se listan las pruebas que se han definido de este tipo.

Caso de Prueba Requerimiento Objetivo de la prueba

asociado

PI001 R01 Verificar que la informacin mostrada

es acorde al Modelo de Datos.

PI002 R02 Verificar que es posible realizar la

trazabilidad de los diagnsticos de los
pacientes.

PI003 R03 Verificar la integridad de la informacin

cuando sta sea accedida de mltiples
instituciones y usuarios.

58
Caso de Prueba Requerimiento Objetivo de la prueba
asociado

PI004 R04 Verificar que la API permite el acceso a

aplicaciones registradas en la Base de
Datos y niega el mismo a las que no lo
estn.

PI005 R05 Verificar se puedan modificar agregar y

eliminar usuarios en la API.

PI006 R06 Verificar se puedan modificar agregar y

eliminar pacientes en la aplicacin.

PI007 R07 Verificar que la bsqueda de pacientes

sea exitosa utilizando los filtros dados.

PI008 R08 Verificar la correcta bsqueda de

pacientes y la integridad de la
informacin.

PI009 R09 Verificar la correcta adicin de pginas

a las historias clnicas

PI010 R10 Verificar el correcto almacenamiento y

obtencin de la informacin adicional
almacenada en una historia clnica.

PI011 R11 Verificar el correcto almacenamiento y

obtencin de las imgenes asociadas a
una historia clnica.

PI012 R12 Verificar la correcta representacin

grfica del estado actual del paciente.

59
Caso de Prueba Requerimiento Objetivo de la prueba
asociado

PI013 R13 Verificar la calidad de informacin

expuesta en los reportes.

PI014 R14 Verificar la correcta interaccin entre la

aplicacin y el servidor de correos
predeterminados, incluyendo la exitosa
recepcin del correo enviado.

PI015 R15 Verificar el nivel de privacidad y

privilegios brindados al mdico y que se
mostrarn al paciente.

PI016 R16 Verificar la calidad de informacin

relacionada a auditora que se est
almacenando y analizar si esta es
suficiente.

PI017 R17 Verificar que los reportes generados

son acordes a la informacin
almacenada.

[TBL-001] Pruebas de Integracin

60
 Pruebas de Sistema

Estas pruebas buscan evaluar el desempeo funcional y tecnolgico de las

soluciones a desarrollar. Asimismo se analizarn aspectos relacionados al
desempeo, uso de recursos, seguridad y estado del sistema tras realizarse la
instalacin y desinstalacin del mismo.

Caso de Prueba Aspecto a Evaluar Objetivo de la prueba

PS001 Prueba Funcional Verificar que las llamadas a la API

por parte de la aplicacin sean
exitosas. Se tiene que verificar que
la API reciba correctamente los
datos enviados por la aplicacin y
que esta ltima reciba la respuesta
de la API.

PS002 Prueba de Verificar que la aplicacin mvil

Desempeo presente un bajo consumo de red y
que realice las llamadas a la API
optimizando esta consideracin.

PS003 Prueba de Verificar que la generacin de

Desempeo conectividad entre la aplicacin y la
API no dure ms de 5 segundos.

PS004 Prueba de Verificar la instalacin exitosa de la

Instalacin aplicacin en los dispositivos
mviles designados.

[TBL-002] Pruebas de Sistema

61
4.2.2. Tcnica utilizada

Para la elaboracin de las pruebas expuestas en el punto anterior se utilizarn las

siguientes tcnicas.

Prueba de Caja Negra

Esta prueba es bastante comn por su simpleza y eficiencia. En ella se definen

valores de entrada para una prueba designada, teniendo en cuenta los valores de
salida tericos que se esperan obtener. Al ejecutar la prueba, no se tiene en cuenta
el procesamiento del sistema, solo el resultado obtenido. Si es igual al terico
esperado, se considera exitosa.

Prueba de Valor Extremo

Esta prueba es consiste en determinar valores de ingreso topes (mximos y

mnimos) para corroborar los puntos de quiebre del sistema y su correcto
funcionamiento en estos casos de stress.

4.2.3. Resultados de las pruebas

Debido a que el proyecto se encuentra en las fases finales, es posible mostrar los
resultados a las pruebas estipuladas, los cuales son los siguientes:

Pruebas de Integracin

Los resultados de las pruebas de integracin definidas se presentan a continuacin.

Caso de Objetivo de la prueba Resultado de la prueba

Prueba

PI001 Verificar que la informacin La informacin mostrada es

mostrada es acorde al Modelo de acorde al Modelo de Datos.
Datos.

PI002 Verificar que es posible realizar la Se comprob la trazabilidad de

trazabilidad de los diagnsticos de los diagnsticos de los
los pacientes. pacientes.

PI003 Verificar la integridad de la Se realizaron pruebas de

informacin cuando sta sea concurrencia. Quedan
accedida de mltiples instituciones y pendientes pruebas de stress.
usuarios.

62
Caso de Objetivo de la prueba Resultado de la prueba
Prueba

PI004 Verificar que la API permite el Se mantiene un registro de

acceso a aplicaciones las aplicaciones permitidas y
registradas en la Base de Datos se corrobor el ingreso de
y niega el mismo a las que no lo estas.
estn.

PI005 Verificar se puedan modificar Se realiz el mantenimiento

agregar y eliminar usuarios en la de la informacin solicitada
API. desde la API.

PI006 Verificar se puedan modificar Se realiz el mantenimiento

agregar y eliminar pacientes en de la informacin solicitada
la aplicacin. desde la aplicacin.

PI007 Verificar que la bsqueda de Se definieron dos filtros y el

pacientes sea exitosa utilizando funcionamiento de ambos fue
los filtros dados. exitoso.

PI008 Verificar la correcta bsqueda de Se corroboraron ambos

pacientes y la integridad de la aspectos.
informacin.

PI009 Verificar la correcta adicin de Se realizaron las adiciones

pginas a las historias clnicas de manera exitosa.

PI010 Verificar el correcto Se corroboraron los aspectos

almacenamiento y obtencin de deseados.
la informacin adicional
almacenada en una historia
clnica.

PI011 Verificar el correcto Se corrobor el correcto

almacenamiento y obtencin de manejo de imgenes.
las imgenes asociadas a una
historia clnica.

63
Caso de Objetivo de la prueba Resultado de la prueba
Prueba

PI012 Verificar la correcta El estado actual del paciente

representacin grfica del se representa de manera
estado actual del paciente. correcta.

PI013 Verificar la calidad de Se corrobor la calidad de la

informacin expuesta en los informacin, pero los reportes
reportes. quedan postergados para
una prxima versin de la
aplicacin.

PI014 Verificar la correcta interaccin Se corrobor la interaccin

entre la aplicacin y el servidor con la API, pero el manejo de
de correos predeterminados, correos queda postergado
incluyendo la exitosa recepcin para una prxima versin de
del correo enviado. la aplicacin.

PI015 Verificar el nivel de privacidad y Se manejan correctamente

privilegios brindados al mdico y los privilegios de los mdicos.
que se mostrarn al paciente.

PI016 Verificar la calidad de La informacin almacenada

informacin relacionada a en la base de datos contiene
auditora que se est datos de auditora y estos se
almacenando y analizar si esta mantienen de manera
es suficiente. infalible.

PI017 Verificar que los reportes Se corrobor la calidad de la

generados son acordes a la informacin, pero los reportes
informacin almacenada. quedan postergados para
una prxima versin de la
aplicacin.

[TBL-001] Pruebas de Integracin

64
 Pruebas de Sistema

Los resultados de las pruebas de sistema definidas se presentan a continuacin.

Caso de Objetivo de la prueba Resultado de la prueba

Prueba

PS001 Verificar que las llamadas a la Se obtuvieron resultados

API por parte de la aplicacin exitosos en la comunicacin
sean exitosas. Se tiene que API-aplicacin.
verificar que la API reciba
correctamente los datos
enviados por la aplicacin y que
esta ltima reciba la respuesta
de la API.

PS002 Verificar que la aplicacin mvil Se corrobor que la conexin

presente un bajo consumo de se hace de manera ptima.
red y que realice las llamas a la
API optimizando esta
consideracin.

PS003 Verificar que la generacin de Las pruebas realizaras

conectividad entre la aplicacin mostraron una media en el
y la API no dure ms de 5 tiempo de espera menor al
segundos. valor propuesto.

PS004 Verificar la instalacin exitosa de Se instal de manera exitosa

la aplicacin en los dispositivos en una Tablet Toshiba Thrive
mviles designados. 10.1

[TBL-002] Pruebas de Sistema

65
CAPTULO 5
En el presente captulo se proceder a detallar todo lo observado durante el tiempo
de realizacin del proyecto, as como las conclusiones a las cuales se ha podido
llegar y algunas recomendaciones derivadas de las mismas.

5.3. Observaciones
Las principales observaciones que se han podido realizar durante el desarrollo del
presente proyecto son las siguientes:

Tras mltiples conversaciones con los odontlogos y jefes de reas, se pudo

recabar que la idea de centralizacin de bases de datos de historias clnicas
odontolgicas era algo que ellos ya haban pensado; pero lo consideraron
no viable debido a una falla en el canal de comunicacin directo con el
Ministerio de Salud (MINSA) y a su desconocimiento en el mbito
tecnolgico.

Existe poco conocimiento y utilizacin de la tecnologa REST para

generacin y consumo de servicios web en nuestro entorno. Esto se dio a
denotar por las constantes recomendaciones para el uso de WebServices

66
 tradicionales por parte del entorno que me brindaba apoyo en conocimientos
tecnolgicos.

Pese a la inexperiencia en el desarrollo para mviles Android, se encontr

que la obtencin de la tecnologa (IDE, libreras, herramientas, etc.) Eran de
fcil acceso, incluso venan empaquetadas en un archivo para su descarga
directa. Esto reduca considerablemente el nivel de complejidad para iniciar
el proyecto, lo cual puede resultar bastante tedioso de no tener las
herramientas adecuadas. Este tambin fue un punto importante en la
decisin del lenguaje a desarrollar, ya que el ser software libre resulta un
punto muy a favor en comparacin con IOS y otros.

Si bien no se utilizaron todas las bondades de la herramienta Ruby, se pudo

apreciar la simpleza y eficiencia al levantar el proyecto, crear la base de
datos e implementar los servicios utilizados.

5.4. Conclusiones
Las principales conclusiones a las que se ha podido llegar tras finalizado el
proyecto son las siguientes:

El tiempo real de desarrollo del proyecto excedi ligeramente el propuesto, y

esto se debe a una falla en el clculo de la curva de aprendizaje y las
labores extra curriculares realizadas por m, considerando ser el nico
recurso del proyecto.

La metodologa SCRUM utilizada para el manejo del proyecto resulto

positiva de sobremanera, ya que permiti una mejor adaptacin a los
constantes cambios que se presentaban durante todo el tiempo de vida del
mismo.

Las decisiones de plataformas tecnolgicas tomadas para este proyecto

fueron acertadas, tanto en el manejo de servicios como en la aplicacin
mvil.

La API desarrollada para ser manejada por el Ministerio de Salud (MINSA)

requerir una mejor administracin de los recursos informticos que tienen a
su disposicin, ya que se esperara un crecimiento exponencial de la
utilizacin de la misma una vez se adapte a la utilizacin general.

67
 La aplicacin mvil desarrollada representa la informacin bsica a ser
utilizada por un odontlogo en su labor diaria, pero esta labor no debe ser
limitada por la informacin dispuesta.

La calidad de informacin que se pretende representar con la Base de Datos

utilizada fue obtenida tras encuestas e investigacin en mltiples centros de
salud, clnicas y hospitales de la ciudad de Lima, con el fin de poder hacer
que esta represente la realidad. Sin embargo, se considera que una mayor
cantidad de informacin puede ser representada en ella, con la ayuda de un
correcto manejo y estandarizacin de datos.

El mayor problema que puede enfrentar la aplicacin del proyecto, es por

temas burocrticos en el Ministerio de Salud (MINSA), es por ello que se
tuvo una charla previa a la finalizacin del proyecto con los dirigentes del
Colegio Odontolgico de Lima, los cuales apoyaron la idea y propusieron
una implementacin controlada.

5.5. Recomendaciones y trabajos futuros

Con todo lo aprendido durante la realizacin del proyecto se puede indicar lo
siguiente:

Como fue expresado anteriormente, se consideran muy oportunas las

tecnologas utilizadas para el desarrollo del presente proyecto, por lo que se
recomendara su mayor utilizacin y difusin en proyectos afines.

A medida que se incrementen la cantidad de aplicaciones que se conecten a

la API y, a su vez, aumenten la cantidad de clnicas y hospitales que deseen
utilizarla de manera institucional, se recomienda ampliar el esquema de
base de datos que maneja la API. Esto requerir de un gran trabajo de
estandarizacin a travs de los usuarios, pero resultar sumamente til al
poder representar de mejor manera al paciente.

Considerando que se tratarn con volmenes inmensos de informacin, se

propone la generacin de reportes y estudios de BI (Inteligencia de
Negocios) con el fin de lograr una explotacin mayor del proyecto.

Si bien se acot el alcance del proyecto a Historias Clnicas Odontolgicas,

el mismo podra utilizarse para el rea de Medicina General. Esto requerira

68
 un mayor trabajo por la inmensa cantidad de informacin a almacenar, pero
brindara los mismos beneficios explicados al inicio del presente documento.

Como ltimo acpite, se propone realizar la implementacin del proyecto de

manera controlada como fue propuesto por el Colegio Odontolgico de
Lima, con el fin de lograr un alcance a nivel nacional de manera paulatina.

69
BIBLIOGRAFA
[ENSF] ALLENDE FLORES, Luis Martn

2013 Entrevistas del 7 de mayo a Silvia Leonor Flores

Chichipe, COP-4942.

[NTHC] DIRECCIN GENERAL DE SALUD DE LAS PERSONAS

2008 Norma tcnica de salud para la gestin de la historia

clnica.

NTS N 022-MINSA/DGSP-V.03

[ETSI] OFICINA GENERAL DE ESTADSTICA E INFORMTICA DEL

MINSA

2002 Directiva administrativa sobre especificaciones tcnicas

mnimas para sistemas informticos en el Ministerio de
Salud.

MINSA/OGEI-V.01

70
 [MSSB] DIRECCIN GENERAL DE SALUD DE LAS PERSONAS

2002 MINSA - Salud Bucal

Recuperado el 08 de Mayo de 2013

http://www.minsa.gob.pe/portada/est_san/saludbucal.htm

[PVCS] MINISTERIO DE SALUD.

DIRECCIN GENERAL DE PROMOCIN DE LA SALUD

2011 Lineamientos de poltica para la vigilancia ciudadana en

salud.

[RAFA] DIRECCIN RED DE SALUD

2012 Registro adecuado de los formatos de atencin.

[RCCS] ESTRATEGIA SANITARIA NACIONAL DE SALUD BUCAL

2012 Registro y codificacin de la atencin en la consulta

externa.

[NTUO] DIRECCIN GENERAL DE SALUD DE LAS PERSONAS

2006 Norma tcnica de salud para el uso del odontograma.

[GPCE] DIRECCIN GENERAL DE SALUD DE LAS PERSONAS

DIRECCIN EJECUTIVA DE ATENCIN INTEGRAL DE LA SALUD

2005 Gua de prcticas clnicas estomatolgicas.

[PPLM] DIRECCIN EJECUTIVA DE PROMOCIN DE LA SALUD

2013 Promocin y proteccin de la lactancia materna en

establecimientos de salud amigos de la madre y el nio.

71
 [BIZAGI] BizAgi

2013 BizAgi Process Modeler

Recuperado el 30 de Mayo del 2013

http://www.bizagi.com/index.php?option=com_content&view=ar
ticle&id=95&Itemid=107

[RUBY] Ruby

2013 Getting Started with Rails

Recuperado el 06 de Junio del 2013

http://guides.rubyonrails.org/getting_started.html#what-is-rails

[EDMS] Edge Health Solutions, Inc.

2010 edgeDMS for iPad [Videograbacin]. Richmond: Edge

Health Solutions, Inc.

Recuperado el 06 de Junio del 2013.

http://www.youtube.com/watch?v=xsL1n5sGCEw&feature=play
er_embedded

[MDDA] Dental Anywhere.

2012 Pgina principal de la compaa Dental Anywhere.

Recuperado el 16 de Julio del 2013.

http://www.dentalanywhere.com/

[MDHU] MyDentalHub.

2013 Pgina principal de la compaa MyDentalHub.

Recuperado el 16 de Julio del 2013.

http://www.dentalanywhere.com/

72