T 2856

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA
TESIS DE GRADO
SOFTWARE COMO SERVICIO PARA LA ADMINISTRACIÓN DE HISTORIAS

CLINICAS
Tesis para obtener el Título de Licenciatura en Informática
Mención Ingeniería de Sistemas Informáticos
POR: YECID ALEJANDRO YAHUITA PONCE

TUTOR METODOLÓGICO: M.SC. ALDO VALDEZ ALVARADO
ASESORA: LIC. MENFY MORALES RIOS
LA PAZ – BOLIVIA
2014
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
DEDICATORIA
Este Proyecto está dedicado a mi familia
por todo el cariño, confianza y apoyo
que me han brindado a lo largo de estos años
y me permitieron llegar hasta estas instancias
Yecid Alejandro Yahuita Ponce

AGRACECIMIENTOS
A mi familia por el apoyo incondicional en cada momento de mi formación académica, en
especial a mi madre Sofía por el cariño, confianza y apoyo que me ha dado a lo largo de
mi vida.
Al Dr. Juan Yahuita y a la Dra. Ruth Alvarado por permitirme implementar mi software en
sus consultorios y manejo de sus historias clínicas y por haber aportado con observaciones
y sugerencias para el desarrollo de este proyecto.
Al M.Sc. Aldo Valdez quien con sus recomendaciones, paciencia, sugerencias y buen
humor colaboraron para el desarrollo y conclusión del Proyecto de Grado
A Patricia García por la paciencia y la cooperación en la elaboración de mi tesis de grado

RESUMEN
Las tecnologías de la información y comunicación van evolucionando a nuevos paradigmas

de programación, aprovisionamiento de datos y operabilidad de los mismos. La
computación en la nube o cloud computing comparte una mejor administración y
despliegue de aplicaciones en la Red, con nuevos paradigmas de almacenamiento y
despliegue que presenta muchas ventajas.
Hoy en día en el mundo se ve la aceptación de esta tecnología, en numerosas empresas con

aplicaciones desplegadas en nubes privadas al igual que empresas prestan servicios de
alojamiento y datos para el desarrollo de las mismas.
Eta Tesis tiene como finalidad el presentar y/o aclarar dudas sobre esta tecnología, que si
bien no es nueva, no es fomentada en nuestro medio. Usando como caso de estudio 2
consultorios médicos de distintas especialidades, del Dr. Juán Yahuita, médico internista y
la Dra. Ruth Alvarado, médico pediatra.
La metodología utilizada para el análisis, diseño y desarrollo del Software Como Servicio
es OpenUP aplicada conjuntamente con la metodología UWE aplicando los modelos de
diseño web. En cuanto al desarrollo del sistema, se utilizó el framework Django, que
permite desarrollo web con el lenguaje de programación Python y Heroku como Plataforma
Como Servicio para el alojamiento del Software.
Finalmente se puede concluir que el Software Como Servicio aplicado a las Historias
clínicas de estos consultorios privados, ha mejorado la atención de sus pacientes como la
portabilidad y fácil manejo, permitiéndoles un ahorro a los médicos en cuanto a servidores.
ÍNDICE
CAPÍTULO I .........................................................................................................................................1
MARCO INTRODUCTORIO ..................................................................................................................1
1.1 INTRODUCCIÓN ......................................................................................................................1
1.2 ANTECEDENTES ......................................................................................................................2
1.3 PLANTEAMIENTO DEL PROBLEMA ..........................................................................................5
1.3.1 PROBLEMA CENTRAL ......................................................................................................5
1.3.2 PROBLEMAS SECUNDARIOS ............................................................................................6
1.4 OBJETIVOS ..............................................................................................................................7
1.4.1 OBJETIVO GENERAL ........................................................................................................7
1.4.2 OBJETIVOS ESPECÍFICOS .................................................................................................7
1.5 HIPÓTESIS ...............................................................................................................................7
1.6 JUSTIFICACIÓN........................................................................................................................7
1.6.1 JUSTIFICACIÓN ECONÓMICA ..........................................................................................7
1.6.2 JUSTIFICACIÓN SOCIAL ...................................................................................................8
1.6.3 JUSTIFICACIÓN CIENTÍFICA .............................................................................................8
1.6.4 JUSTIFICACIÓN TECNOLÓGICA ........................................................................................8
1.7 ALCANCES Y LÍMITES ..............................................................................................................9
1.7.1 ALCANCES .......................................................................................................................9
1.7.2 LÍMITES ...........................................................................................................................9
1.8 APORTES ...............................................................................................................................10
1.8.1 PRÁCTICO .....................................................................................................................10
1.8.2 TEÓRICO .......................................................................................................................10
CAPÍTULO II ......................................................................................................................................11
MARCO TEÓRICO ..............................................................................................................................11
2.1 INGENIERIA DE SOFTWARE [1] .............................................................................................11
2.1.1 METODOLOGIA DE DESARROLLO DE SOFTWARE .........................................................11
2.1.1.1 METODOLOGIAS INCREMENTALES ...........................................................................11
2.1.1.2 METODOLOGIAS EVOLUTIVAS ..................................................................................12
2.1.1.3 METODOLOGIAS AGILES ...........................................................................................12
2.2 METOLOGÍA OPENUP [18] ....................................................................................................13
2.2.1 CARACTERISTICAS .........................................................................................................13
2.2.2 FASES DE LA METODOLOGIA ........................................................................................15
2.2.2.1 FASE DE INICIO .........................................................................................................15
2.2.2.2 FASE DE ELABORACION ............................................................................................15
2.2.2.3 FASE DE CONSTRUCCIÓN ..........................................................................................15
2.2.2.4 FASE DE TRANSICIÓN ................................................................................................16
2.3 INGENIERIA WEB ..................................................................................................................16
2.3.1 DEFINICIÓN...................................................................................................................16
2.4 METODOLOGIA UWE ............................................................................................................17
2.4.1 LENGUAJE UNIFICADO DE MODELADO [3] ...................................................................17
2.4.2 UML-BASED WEB ENGINEERING [11] ...........................................................................18
2.4.3 CARACTERÍSTICAS DE UNA APLICACIÓN WEB...............................................................19
2.4.4 REQUISITOS DE DESARROLLO DE UNA APLICACIÓN WEB .............................................20
2.4.5 FASES DE LA METODOLOGÍA UWE ...............................................................................21
2.4.5.1 ANÁSLISIS DE REQUISITOS ........................................................................................21
2.4.5.2 DISEÑO CONCEPTUAL ...............................................................................................22
2.4.5.3 DISEÑO NAVEGACIONAL...........................................................................................23
2.4.5.4 DISEÑO DE PRESENTACIÓN ......................................................................................24
2.5 COMPUTACIÓN EN LA NUBE ................................................................................................26
2.5.1 CAPAS DE LA COMPUTACIÓN EN LA NUBE ...................................................................27
2.5.1.1 INFRAESTRUCTURA COMO SERVICIO .......................................................................28
2.5.1.2 PLATAFORMA COMO SERVICIO ................................................................................29
2.5.1.3 SOFTWARE COMO SERVICIO ....................................................................................29
2.5.2 ARQUITECTURA DATOS MULTI USUARIO .....................................................................30
2.5.2.1 JUSTIFICACIÓN ..........................................................................................................30
2.5.2.2 GESTIÓN DE DATOS DE MULTI-USUARIO - 3 ENFOQUES ..........................................31
2.5.2.3 CONCEPTOS DE APLICACIONES MULTI-TENANT .......................................................33
2.5.3 TIPOS DE NUBES ...........................................................................................................34
2.5.4 VENTAJAS DE LA NUBE .................................................................................................34
2.5.5 DESVENTAJAS DE LA NUBE ...........................................................................................35
2.6 ADMINISTRACIÓN DE HISTORIAS CLÍNICAS ..........................................................................36
2.6.1 DEFINICIÓN DE HISTORIAS CLÍNICAS ............................................................................36
2.6.2 CARACTERÍSTICAS .........................................................................................................37
2.6.3 FINALIDADES ................................................................................................................37
2.6.4 HISTORIAS CLINICAS ELECTRONICAS ............................................................................38
CAPÍTULO III .....................................................................................................................................40
MARCO APLICATIVO .........................................................................................................................40
3.1 INTRODUCCIÓN ....................................................................................................................40
3.2 FASE DE INICIO .....................................................................................................................41
3.2.1 DESCRIPCIÓN DE LOS INTERESADOS.............................................................................41
3.2.2 ARQUITECTURA DEL SISTEMA ......................................................................................41
3.2.3 DEFINICIÓN DE LA SOLUCIÓN PROPUESTA ...................................................................42
3.2.4 VISIÓN GENERAL DEL SISTEMA .....................................................................................43
3.2.5 REQUERIMIENTOS TECNOLÓGICOS ..............................................................................43
3.3 FASE DE ELABORACIÓN ........................................................................................................44
3.3.1 ESPECIFICACIÓN DE REQUERIMIENTOS ........................................................................44
3.3.2 DESCRIPCIÓN DE ACTORES ...........................................................................................44
3.3.3 MODELOS DE CASOS DE USO .......................................................................................45
3.3.3.1 CASOS DE USO ..........................................................................................................45
3.3.3.2 DIAGRAMA GENERAL DE CASOS DE USO ..................................................................49
3.3.4 DISEÑO CONCEPTUAL ...................................................................................................54
3.3.5 DISEÑO NAVEGACIONAL...............................................................................................56
3.3.6 DISEÑO DE PRESENTACIÓN ..........................................................................................57
3.3.7 DIAGRAMA RELACIONAL ..............................................................................................59
3.4 FASE DE CONSTRUCCIÓN......................................................................................................60
CAPÍTULO IV .....................................................................................................................................68
ANÁLISIS DE DATOS Y RESULTADOS .................................................................................................68
4.1 PRUEBA DE HIPÓTESIS ..........................................................................................................68
4.1.1 CONTRASTE DE RACHAS DE WALD – WOLFOWITZ .......................................................68
4.1.2 DESARROLLO DE LA PRUEBA DE HIPÓTESIS ..................................................................70
CAPÍTULO V ......................................................................................................................................76
CONCLUSIONES Y RECOMENDACIONES ...........................................................................................76
5.1 CONCLUSIONES ....................................................................................................................76
5.2 RECOMENDACIONES ............................................................................................................77
6. BIBLIOGRAFIA ...........................................................................................................................77
6.1 REFERENCIAS BIBLIOGRÁFICAS .........................................................................................77
6.2 REFERENCIAS DE INTERNET ..............................................................................................79
1.1 ANEXOS ................................................................................................................................81
ÁRBOL DE OBJETIVOS .......................................................................................................................82
ÁRBOL DE PROBLEMAS ....................................................................................................................83
MATRIZ DE MARCO LÓGICO .............................................................................................................84
ENCUESTA PROPUESTA ....................................................................................................................85
ENCUESTA PRUEBA DE HIPÓTESIS ....................................................................................................86
TABLA DE CALIFICACIÓN ..................................................................................................................87
ÍNDICE DE FIGURAS
Figura 2.1. Proceso OpenUp .............................................................................................................15

Figura 2.2: Casos de usos .................................................................................................................21
Figura 2.3: Diagrama de actividad ....................................................................................................22
Figura 2.4: Diagrama de secuencia ...................................................................................................22
Figura 2.5: Análisis casos de uso ......................................................................................................23
Figura 2.6: Elementos del diseño Navegacional ...............................................................................23
Figura 2.7: Diseño navegacional UWE ..............................................................................................24
Figura 2.8: Elementos del diseño de presentación ...........................................................................25
Figura 2.9: Diagrama de presentación..............................................................................................26
Figura 2.10: Capas de la computación en la nube ............................................................................28
Figura 2.11: Gestión de datos Multi-tenant, escala entre el aislamiento y el intercambio .............33
Figura 2.12: SaaS, taxonomía del modelo de computación en la nube ............................................33
Figura 3.1: Arquitectura de conexión cloud computing ...................................................................42
Figura 3.2: Caso de uso Paciente ......................................................................................................46
Figura 3.3: Diagrama de secuencia de paciente ...............................................................................47
Figura 3.4: Caso de uso Médico........................................................................................................48
Figura 3.5: Diagrama de secuencia Médico ......................................................................................48
Figura 3.6: Caso de uso Proveedor ...................................................................................................49
Figura 3.7: Diagrama de secuencia de Proveedor de Servicio ..........................................................49
Figura 3.8: Diagrama general de Casos de Uso ................................................................................50
Figura 3.9: Diagrama de actividades ................................................................................................54
Figura 3.10: Diseño conceptual ........................................................................................................55
Figura 3.11: Diagrama de clases .......................................................................................................55
Figura 3.12: Diseño Navegacional ....................................................................................................56
Figura 3.13: Diseño de Presentación ................................................................................................58
Figura 3.14 Modelo Relacional .........................................................................................................59
Figura 3.15: Login de usuario ...........................................................................................................60
Figura 3.16: Pantalla de Bienvenida .................................................................................................61
Figura 3.17: Lista de pacientes .........................................................................................................61
Figura 3.18: Historia Clínica ..............................................................................................................62
Figura 3.19: Historia Clínica, signos vitales y diagnóstico .................................................................62
Figura 3.20: Formulario crear Evolución ..........................................................................................63
Figura 3.21: Guardar Evolución, imprimir Historia ...........................................................................63
Figura 3.22: Evolución añadida a Historia Clínica .............................................................................64
Figura 3.23: Reporte Historia Clínica ................................................................................................64
Figura 3.24: Formulario añadir paciente ..........................................................................................65
Figura 3.25: Formulario registro paciente ........................................................................................65
Figura 3.26: Lista de reportes ...........................................................................................................66
Figura 3.27: Ejemplo, lista reportes fecha en el día 5 .......................................................................66
Figura 3.28: Reporte fechas .............................................................................................................67
ÍNDICE DE TABLAS
Tabla 3.1: Fases OpenUp, aplicando UWE ........................................................................................40

Tabla 3.2 Descripción de interesados ...............................................................................................41
Tabla 3.3 Registro automatizado de historias clínicas ......................................................................43
Tabla 3.4 Requerimientos funcionales – Seguimiento de historia clínica .........................................44
Tabla 3.5 Descripción de actores ......................................................................................................45
Tabla 3.6: Registrar Historia Clínica ..................................................................................................51
Tabla 3.7: Ver Reporte de Seguimiento ............................................................................................52
Tabla 3.8: Registrar control de sesión ..............................................................................................52
Tabla 3.9: Registrar evolución ..........................................................................................................53
Tabla 4.1: Comparación Historia Clínica tradicional con Software como Servicio ............................72
CAPÍTULO I
MARCO INTRODUCTORIO
1.1 INTRODUCCIÓN
Cloud Computing o computación en la nube es un modelo de aprovisionamiento de

recursos TI (Tecnologías de la Información) que potencia la prestación de servicios TI y
servicios de negocio, facilitando la operativa del usuario final y del prestador del servicio.
Muchas tecnologías y empresas apuestan por el desarrollo de Software como

servicio, prestándonos sus Plataformas e Infraestructuras como Servicio, como Microsoft,
Google, Amazon, entre otros. El presente trabajo aplica su ventaja en ahorro y sencilla
administración, creando un Software como servicio, aplicado a un médico internista y un
médico pediatra, en la administración de sus historias clínicas.
Un Software como Servicio para una fácil y portátil administración de historias

clínicas, permite la adición, seguimiento, archivo de historias clínicas, al mismo tiempo
presentarle reportes al médico. La adaptación a esta tecnología en Bolivia, computación en
la nube, no es fomentada, al menos no de manera pública. Está nos ofrece un uso mucho
más eficiente de recursos, como almacenamiento, memoria, procesamiento y ancho de
banda, al proveer solamente los recursos necesarios en cada momento, al mismo tiempo su
ventaja de portabilidad para médicos de atención a domicilio. A pesar que algunos usuarios
creen que los dispositivos perderán “poder”, porque la información en una nube de internet
se cree volátil. De todas formas, los dispositivos como los Smart phones y Smart Tvs están
adquiriendo más “poder” gracias a la computación en la nube.
En la Universidad Mayor de San Andrés son pocas las tesis o proyecto de grado que
traten de la computación en la nube, trabajos sobre Historias clínicas fueron bien acogidas
en la carrera de Informática. La perspectiva del presente trabajo plantea la misma idea de
seguimiento de paciente mediante historias clínicas vista como software como servicio
(S.a.a.S.), una aplicación dentro la computación en la nube.
1.2 ANTECEDENTES
La disponibilidad de recursos computacionales conectados a través de Internet y

redes WAN reviste un especial interés, principalmente en el marco de la infraestructura
Web 2.0, la cual permite que los usuarios puedan acceder a estos recursos por medio de
interfaces más intuitivas. De esta manera, la nueva forma de hacer computación en Internet
resulta más orientada a servicios que a aplicaciones. En este contexto, emerge un nuevo
modelo de gestión de recursos: Cloud Computing; en el que grandes organizaciones ofrecen
sus recursos computacionales a cambio de un crédito económico.
Cloud computing se hace eco recientemente como una excelente infografía sobre la
evolución del almacenamiento informático desde la década de los 50, en el siglo pasado,
hasta llegar a la actualidad, en los principios del siglo XXI, donde el almacenamiento
informático en la nube crece de forma exponencial tanto en servicios como en capacidad de
almacenamiento. [10]
El concepto fundamental de la entrega de los recursos informáticos a través de una

red global tiene sus raíces en los años sesenta. La idea de una "red de computadoras
intergaláctico" fue introducido en los años sesenta por JCR Licklider, quien era responsable
de permitir el desarrollo de ARPANET (Advanced Research Projects Agency Network) en
1969. Su visión era que todo el mundo pudiese estar interconectado y poder acceder a los
programas y datos desde cualquier lugar, (Margaret Lewis, directora de marketing de
producto de AMD). "Es una visión que se parece mucho a lo que llamamos cloud
computing". [11]
Las tecnologías que hicieron posible cloud computing fueron básicamente dos.
Sistema distribuido, que es un grupo de computadores autónomos conectados por una red, y
2
con el software distribuido adecuado para que el sistema sea visto por los usuarios como
una única entidad capaz de proporcionar facilidades de computación. Grid Computing
(malla de ordenadores), se basa en el aprovechamiento de los ciclos de procesamiento no
utilizados por los millones de ordenadores conectados a la Red. De esta forma se consigue
que puedan resolver tareas que son demasiado intensivas para ser resueltas por una única
máquina. [15]
El concepto de la computación en la nube, o cloud computing, empezó con

proveedores de servicios de Internet a gran escala como Google, Amazon AWS y otros que
construyeron su propia infraestructura. De entre todos ellos emergió una arquitectura: un
sistema de recursos distribuidos horizontalmente introducidos como servicios virtuales de
TI escalados masivamente y manejados como recursos configurados y mancomunados de
manera continua. [15]
La computación en la nube está envolviendo la innovación como nunca antes, con

compañías de todas las formas y tamaños adaptando su tecnología y transformando su
infraestructura IT. Gracias a esto expertos en tecnologías IT y desarrolladores de software
apuntan al desarrollo de más software orientado a los servicios, Infraestructuras como
servicio y Plataformas privadas. [16]
En las últimas décadas, se desarrollaron Infraestructuras como servicios de las

empresas más conocidas en el medio informático como Microsoft, Cisco, Google,
VMware, IBM etc. Para poder desarrollar nubes privadas, mas hay otras que ofrecen
privacidad evitando que los datos se conozcan por empresas o gobiernos como
“OwnCLoud” una plataforma para crear tu propia nube, que tiene funciones de datos como
DropBox y tantas que se encuentran en el mercado. Para software como servicio se
apuestan más, como las Plataformas como Servicio, Google con “AppEngine” y Microsoft
con “Windows Azure” como plataformas de desarrollo de aplicaciones en la nube, otros
menos populares como Heroku, Jelastic, entro otros. [12]
3
Uno de los más notables Softwares como servicio es “Office 365” y “SharePoint”
de la compañía Microsoft, creada el año 2013; que trata de la conocida aplicación de
escritorio “Microsoft Office 2013” pero llevada a la nube. La gran diferencia se encuentra
en que puede guardar y editar tus documentos tanto en Word, Power Point, Excel; de
manera potable en donde te encuentres, desde el dispositivo que te encuentres con conexión
a internet. Éste tiene un precio de alquiler del servicio. [12]
Otra muy popular es “Google Docs” de la empresa Google, que funciona de igual
manera que “Office 365” de Microsoft, solo que este no presenta las características de
“Microsoft Office”, pero si permite la manipulación de documentos, y este es de forma
gratuita. “Evernote” que lleva las notas o calendarios a todos los dispositivos mediante la
nube. [12]
En cuanto a un Software como servicio de historias clínicas el mejor ejemplo es del

de “DRiCloud”, creada en el 2012, presenta uno de los softwares más completos en la nube
ya que dispone de 4 servicios en uno. Gestión de relación con el paciente, que facilita una
página web para las citas online y el doctor envía recordatorios de consultas y exámenes al
paciente. Historia clínica electrónica, personalizable para cada especialidad, con la
posibilidad de dar recetas con código de colores en enfermedades. Gestión económica
completa, datos estadísticos de número de pacientes, facturas y más. Seguridad, gestiona
diferentes cuentas de usuario con encriptado y en diferentes idiomas. Todo el software es
compatible con todos los sistemas operativos y navegadores.
En el ámbito nacional, Bolivia no presenta alguna aplicación conocida en la nube.

Las empresas de Bolivia no presentan softwares como servicio de desarrollo nacional, mas
el Gobierno Nacional parece estar consciente del uso de la nube, como se puede ver en un
artículo que titula “La computación en la nube es fundamental para reducir la desigualdad
en la región” por el Ministerio de Gobierno. Sin embargo, empresas tanto privadas como
públicas solamente usan DataStore en la nube. Se cree que no es bien aceptada por la baja
calidad de conexión en el País. [17]
4
En cuanto a programas o sistemas similares en la Carrera de Informática de la
UMSA, solo se presentan proyectos de grados hacia empresas, seguros u hospitales, de
sistemas de historias clínico, fichaje, administración de la entidad.
“Sistema de Seguimiento de historias clínicas y fichaje Promes” proyecto del

estudiante Miguel Angel Leaño Velasquez, del año 2008. Éste propone un sistema
integrado para el seguro universitario PROMES de la UMSA para controlar las historias de
los estudiantes y al mismo tiempo el fichaje para las citas con los médicos de las distintas
especialidades. [7]
Otro proyecto similar que trata la misma solución pero para otras empresa es
“Sistema de administración de historias clínicas Clínica Sanjinés” del estudiante Machicao
Rejas, Americo Guillermo, el año 2009.Él cual realiza un sistema en Java para el envío y
control de las historias clínicas en general en la clínica privada Sanjinés. [4]
El proyecto más similar al presente es “Sistema Web de “Seguimiento a Historias

Clínicas para la empresa SPA Médico Cime basado en CRM”, de la estudiante María
Leonor Gonzalez, el año 2013. Éste realiza un sistema web del spa mencionado haciendo
uso de CRM como modelo de negocios en la empresa, utilizando tecnología web como
PHP y MySQL con el MVC. [5]
1.3 PLANTEAMIENTO DEL PROBLEMA
1.3.1 PROBLEMA CENTRAL
La historia clínica electrónica ya no es un nuevo paradigma que se impone en la

documentación de la información en salud de nacimiento hasta la muerte de una persona.
Su adopción en los medios se debe a múltiples ventajas que presentan, es más en el mundo
el 80% de profesionales e instituciones en salud hace uso algún software o sistema para
citas de pacientes, Historias clínicas electrónicas, recetas, entre otros. Lo cual redujo de
53% al 83% de errores en indicaciones médicas. [14]
5
Sin embargo, hoy en día se presentan diferentes tecnologías para el desarrollo de las
mismas, intentando de alguna forma mejorar las HCE (Historia clínica electrónica).
La historias clínicas necesitan de actualizaciones constantemente, sin importar

donde se atienda al paciente (clínica, hospital, domicilio, entre otros). Cualquier persona o
empresa desearía ahorrar los gastos en conexiones, servidores y equipos para tener un
sistema de información de historias clínicas.
¿Cómo se podrá lograr que los médicos tengan un mejor control y seguimiento de sus
pacientes?
1.3.2 PROBLEMAS SECUNDARIOS
El proyecto presenta lo siguientes problemas secundarios:
Limitación de acceso remoto a los datos y antecedentes de un paciente, dificultando

tener la información necesaria de los pacientes al atenderlos en instituciones ajenas
o domicilios.
Gasto de papel y espacio ocupado por los mismos innecesario, complicando la
manipulación y acceso de historias clínicas.
Procesos de búsqueda lentos, provocando demoras en la atención a pacientes y
reduciendo número de pacientes atendidos en una jornada laboral.
Extravíos y mal manejo de las historias clínicas, pudiendo comprometer valiosa
información de un paciente en medios físicos y atenderlo deficientemente
Permisión de la manipulación de las historias clínicas por personal autorizado, para
permitir control de usuarios para la lectura, escritura de las historias.
6
1.4 OBJETIVOS
1.4.1 OBJETIVO GENERAL
Desarrollar un software como servicio, para la administración de historias clínicas

para que médicos tengan un mejor control y seguimiento de sus pacientes.
1.4.2 OBJETIVOS ESPECÍFICOS
Los objetivos específicos planteados para el proyecto son:
Facilitar el acceso a datos de los pacientes, historias clínicas, de manera remota.

Disminuir espacio y trabajo que causan la redacción de historias clínicas.
Ahorrar tiempo a la hora de buscar historias clínicas impresos.
Otorgar seguridad a los datos de pacientes.
Restringir el uso a personal no autorizado.
1.5 HIPÓTESIS
Un software como servicio para la administración de historias clínicas

implementado en consultorios privados con tecnología de punta, sobre la Plataforma como
servicio pública Heroku, con las ventajas de cloud computing; ahorra el hosting, gasto en
servidores, proporciona fácil manipulación, mantenimiento remoto y asegura la estabilidad
de la aplicación, disminuyendo tiempo de atención.
1.6 JUSTIFICACIÓN
1.6.1 JUSTIFICACIÓN ECONÓMICA
Una de las grandes ventajas de la computación en la nube es el ahorro económico.

Los beneficios económicos del software como servicio a comparación del software como
producto, está en los servidores y personal IT ya que el personal puede estar a kilómetros
7
de distancia controlando la aplicación, asegurando la estabilidad del servicio y los servicios
se pueden importar a la nube, cambiando los servidores físicos por virtuales, reduciendo el
espacio ocupado y ahorrando energía. Lo cual significa un gran ahorro para una empresa.
Además de la resistencia sin redundancia, es decir evitar tener que reinstalar software u
necesitar hardware para que las aplicaciones funcionen.
1.6.2 JUSTIFICACIÓN SOCIAL
Reducir el tiempo de registro y búsqueda de pacientes permite un mayor número de

consultas. Cuando se crea un software o un sistema de historias clínicas el principal
objetivo es poder reducir el tiempo de actualización y creación de una historia, para así
facilitar de manera más eficiente la información al médico especialista. Aplicamos la idea a
la computación en la nube y la portabilidad de esas historias de un médico o una institución
facilitará la información de un paciente en cualquier lugar que cuente con conexión a
internet e implica más comodidad para el médico (basado en encuestas), ejemplo: 2
sucursales de una misma clínica.
1.6.3 JUSTIFICACIÓN CIENTÍFICA
El desarrollo de aplicaciones en la nube en Bolivia es bajo. Se estima que la

computación en la nube es el futuro en tecnologías web, mencionada en la tecnología de la
web 3.0 como la preferencia de control y hosting. La web semántica gestionada en la nube
o cloud computing y ejecutada desde cualquier dispositivo con un alto grado de viralidad y
personalización. Sin embargo, las bajas velocidades y altos costos en la región de Bolivia
impide el desarrollo de Softwares como servicio o consultoras para Plataformas e
Infraestructuras como servicio. Bolivia no puede quedar al margen de estas tecnologías.
1.6.4 JUSTIFICACIÓN TECNOLÓGICA
Como solución a los problemas planteados por la tecnología grid computing surge
recientemente el término Cloud Computing o computación en nube. Esta tecnología se
centra fundamentalmente en el desarrollo de un sistema operativo que hace funcionar un
8
hardware heterogéneo que puede estar ubicado físicamente en diferentes lugares del mundo
e interconectado entre sí mediante redes IP. Los procesos que se ejecuten sobre este sistema
operativo lo hacen de forma transparente a la ubicación del núcleo sobre el que se ejecute y
a la ubicación de memoria RAM que le sea asignada. Es decir, el sistema operativo de un
Cloud Computing virtualiza todo el hardware, homogeneizando mediante software un
hardware heterogéneo, corrigiendo de esta forma las deficiencias detectadas en la
tecnología anterior. El Cloud Computing está cambiando la perspectiva de los servicios de
Internet con la promesa de servicios software más baratos y flexibles. Por falta de
estandarización se propuso soluciones más hacia el software libre, como Opennebula.
1.7 ALCANCES Y LÍMITES
1.7.1 ALCANCES
El presente proyecto realiza una investigación aplicada con las siguientes características:
Registro del doctor y enfermera o secretaria.

Registro de historias clínicas
Recepción de pacientes
Generación de reportes
Adaptabilidad a diferentes dispositivos
Portabilidad como aplicación
1.7.2 LÍMITES
Los límites que presenta el proyecto son:

Falta de personalización en la historia (agregado de campos)
Función solo con conexión a internet.
Actividades económicas y estadísticas de un consultorio o un hospital no serán
tomadas en cuenta.
Solo podrán acceder los médicos al software y no así los pacientes.
9
1.8 APORTES
1.8.1 PRÁCTICO
El prototipo de la presente investigación se aplicará como casos de estudio los

consultorios privados de dos doctores, Dr. Juán Yahuita médico internista y Dra. Ruth
Alvarado, pediatra con la esperanza de que en un futuro pueda ser de utilidad en clínicas y
hospitales para que tengan una administración de pacientes, más veloz y sencilla. Y poder
realizar informes de su atención.
Proporcionar una herramienta que brinde información oportuna y confiable de

manera móvil como de escritorio, que sirva de apoyo a la toma de decisiones sin importar
donde se encuentre un paciente.
1.8.2 TEÓRICO
El trabajo pretende dar conocimiento y un empujón para la investigación y

desarrollo de aplicaciones en cloud computing, que se ve limitado en nuestro medio.
El Software como Servicio será desarrollado por la metodología OpenUp propuesta

por la fundación Eclipse, basada en características más sobresalientes de la metodología de
Proceso Racional Unificado (RUP).
Para el modelo del Software, se utilizaran elementos y diagramas de desarrollo

UWE, basado en el modelo UML.
Las tecnologías a usar en el presente trabajo serán Python en su versión 3.4, con el
framework de desarrollo web Django 1.7, base de datos SQLite 3; haciendo uso del SDK
de Heroku SalesForce que permite el desarrollo y alojamiento en la nube pública.
10
CAPÍTULO II
MARCO TEÓRICO
2.1 INGENIERIA DE SOFTWARE [1]
Existen diferentes definiciones sobre el término ingeniería de software. La

definición de ingeniería de software de Sommerville, la define como, “La ingeniería de
software es una disciplina de la ingeniería que comprende todos los aspectos de la
producción de software desde las etapas iniciales de la especificación del sistema, hasta el
mantenimiento de este después de que se utiliza.”
Entonces, la ingeniería de software comprende el conocimiento amplio de teorías,

métodos y herramientas que permite el desarrollo de software que sea eficiente, de calidad
y confiable.
2.1.1 METODOLOGIA DE DESARROLLO DE SOFTWARE
De acuerdo al INTECO (Instituto Nacional de Tecnologías de la comunicación,

2009) el desarrollo de software requiere del uso de metodologías, que ayuden y guíen las
actividades y procesos, para conseguir las metas u objetivos planteados al inicio de
proyecto de desarrollo software y conseguir un producto que sea de calidad y cumpla con el
ciclo de vida del proyecto, para este caso existen tres tipos de metodologías, que actúan o se
diferencian por el tiempo de desarrollo e iteraciones que se presenta para controlar el buen
desarrollo de software.
2.1.1.1 METODOLOGIAS INCREMENTALES
De INTECO (2009), se resume que los métodos incrementales, permiten entregar

con frecuencia avances del desarrollo de software, como su nombre o indica e trabaja en
iteración y bosquejos hasta llegar a conseguir el producto terminado.
11
Una de las características del método incremental, es que para la actualización de
desarrollo de software, solo es posible la modificación de subprocesos y no así de todo el
software.
2.1.1.2 METODOLOGIAS EVOLUTIVAS
El desarrollo de software por metodologías evolutivas, implica el desarrollo de una

versión inicial, que va mejorando durante el ciclo de vida del proyecto, a partir de la
interacción constante con el cliente.
Para obtener mejores resultados, se debe tener cuidado con los documentos y
versiones que se tiene del software porque, a pesar de que esta metodología permite realizar
cualquier número de cambios, se debe tener control de estos cambios a partir de la
documentación y versiones existentes.
Algunos ejemplos de metodologías evolutivas los siguientes:
Modelo Espiral
Modelo Espiral (WINWIN)
Modelo Iterativo - Incremental
2.1.1.3 METODOLOGIAS AGILES
Se caracterizan por entregas pequeñas de software, el tiempo o vida de los ciclos de

vida concluyen más rápido. Otra característica de estos métodos es la interacción constante
y cooperativa entre desarrolladores y clientes.
La ventaja de los métodos ágiles, es la facilidad de realizar cambios que intervienen

en el desarrollo. Entre los métodos conocidos como agiles tenemos:
Extreme Programing (XP)

Scrum
Familia de metodologías Crystal
12
FeatureDrivenDevelopment
RationalUnifiedProcess (RUP)
OpenUp
2.2 METOLOGÍA OPENUP [18]
2.2.1 CARACTERISTICAS
En la documentación de la metodología OpenUp/OAS de la Universidad Distrital

Francisco José de Caldas (2012), describe a la metodología OpenUp como un proceso
unificado que adopta un enfoque ágil, que se centra en la naturaleza colaborativa de
desarrollo de software, planteado por la fundación Eclipse, como característica principal su
flexibilidad de poder adaptarse a las características y necesidades de cada proyecto.
Las posibilidades de éxito del proyecto se basan en el equipo de trabajo, sus

respectivos roles y la planificación de las fases del proyecto. A sí mismo, como base del
uso o implementación de esta metodología corresponde al amplio conocimiento del sistema
o proyecto a desarrollar, esto implica, el manejo de una cierta cantidad iteraciones dentro
del ciclo de vida del proyecto, puesto que pueden existir cambios producidos por nuevas
necesidades. Las iteraciones también permiten la retroalimentación, que conlleva a
solucionar problemas, prever riesgos y realizar mejoras en el desarrollo del ciclo de vida
del proyecto.
En la página que Eclipse Foundation (2012) dedicada a OpenUp, plantea el

seguimiento de actividades diarias a grupos de trabajo, menores a 10 personas, con un
tiempo mínimo de tres meses para completar el ciclo de vida y las fases que comprende esta
metodología.
OpenUp, describe el ciclo de vida de un proyecto a partir de cuatro fases, que son:
Inicio, Elaboración, Construcción y Transición; dentro de estas fases, se desarrollan
13
subprocesos como ser: Procedimientos, Roles, Guías y productos de trabajo que facilitan y
contribuyen con el desarrollo de las cuatro fases (Ver figura 2.1).
Figura 2.1. Proceso OpenUp

Fuente: epf.eclipse.org, 2012
Una de las funciones básicas que se debe cumplir en la metodología OpenUp, son
las tareas y artefactos, por cada disciplina que se muestra a continuación:
Arquitectura
Despliegue
Desarrollo
Entorno
Gestión de Proyectos
Requerimientos
Pruebas
14
2.2.2 FASES DE LA METODOLOGIA
2.2.2.1 FASE DE INICIO
En esta fase los interesados o "stakeholder" e integrantes del equipo de desarrollo,

determinan aspectos como ser: ámbito del proyecto, objetivos y viabilidad del proyecto. Es
decir, que en esta fase se describe o define la visión del proyecto, que contempla el alcance
y sus límites, los interesados en este sistema, funcionalidad clave del sistema,
requerimientos, posible solución, arquitectura, viabilidad.
2.2.2.2 FASE DE ELABORACION
En la fase de elaboración, además de identificar y considerar los riesgos, se persigue

los siguientes puntos:
Entender los requisitos de forma detallada y la mayor cantidad posible, para

establecer un plan detallado, y concretar de forma más eficiente la arquitectura del
proyecto.
Establecer una arquitectura o diseño del producto final, basado en los diagramas
básicos de UML es decir: casos de uso, secuencias, colaboración.
Con un buen conocimiento de los requisitos se logra reducir los riesgos y planificar
el cronograma de desarrollo.
2.2.2.3 FASE DE CONSTRUCCIÓN
En esta fase, el proyecto toma el rumbo de desarrollo bajo la arquitectura descrita en

la fase anterior, se espera que se complete el desarrollo y objetivos de la fase de
elaboración. El número iteraciones dentro de la fase de construcción varía según el tamaño
del proyecto, siendo uno para proyectos simples, dos para proyectos considerables y tres o
mayor para proyectos grandes.
15
2.2.2.4 FASE DE TRANSICIÓN
La fase de transición implica que el producto o sistema desarrollado haya logrado

las expectativas del usuario. Como objetivos de esta fase se puede mencionar el entregar
una versión del sistema sin errores, que cumpla las necesidades o expectativas del usuario y
la realización de pruebas al sistema para verificar o validar su funcionalidad.
De la misma forma que en la fase de construcción, el número de iteraciones dentro

de esta fase dependerá del tamaño del proyecto, en cada iteración se depuraran errores o
pulirán requerimientos.
2.3 INGENIERIA WEB
Con la definición y avance que obtuvo la World Wide Web (www) o internet, se ha
logrado que numerosas actividades se lleven a cabo en su entorno, aprovechando los
servicios que ofrece como la inmensa variedad de contenido y las funciones que responden
a necesidades del usuario.
Gracias a este cambio la administración de empresas dio un giro trascendental. La

atención a los clientes mejoro de forma remota y reduciendo costos en diversos aspectos
dentro de la empresa, como ser la correspondencia electrónica. Hoy en día la mayoría de las
empresas han optado por la implementación de sistemas de información web.
2.3.1 DEFINICIÓN
La ingeniería Web al igual que la ingeniería de software, aplica tanto metodologías,

técnicas y herramientas para el desarrollo de las solución a un problema, pero a diferencia
de la ingeniería de software, cumple características específicas para el desarrollo de sistema
Web de gran complejidad y dimensión.
Si bien la ingeniería de software brinda fases y pasos a seguir el desarrollo de un

sistema de información o software, un sistema web requiere un trato diferente, por las
16
especificaciones y características que conlleva. Powell (1998, Pressman, 2002) resume que
los sistemas web "implican una mezcla de publicación impresa y desarrollo de software, de
marketing e informática, de comunicaciones internas y relaciones externas, de arte y
tecnología".
2.4 METODOLOGIA UWE
2.4.1 LENGUAJE UNIFICADO DE MODELADO [3]
Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad; está respaldado por el OMG (Object Management
Group).
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un

sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocio, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o

para describir métodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar

soporte a una metodología de desarrollo de software (tal como el Proceso Unificado
Racional o RUP), pero no específica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa

Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad
17
de una utilización en un requerimiento. Mientras que, programación estructurada, es
una forma de programar como lo es la orientación a objetos, la programación
orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso
se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos
de las entidades representadas:
2.4.2 UML-BASED WEB ENGINEERING [11]
UWE es un proceso del desarrollo para aplicaciones Web enfocado sobre el diseño
sistemático, la personalización y la generación semiautomática de escenarios que guíen el
proceso de desarrollo de una aplicación Web. UWE describe una metodología de diseño
sistemática, basada en las técnicas de UML, la notación de UML y los mecanismos de
extensión de UML.
Es una herramienta que nos permitirá modelar aplicaciones web, utilizada en la

ingeniería web, prestando especial atención en sistematización y personalización (sistemas
adaptativos). UWE es una propuesta basada en el proceso unificado y UML pero adaptados
a la web. En requisitos separa las fases de captura, definición y validación. Hace además
una clasificación y un tratamiento especial dependiendo del carácter de cada requisito.
En el marco de UWE es necesario la definición de un perfil UML (extensión)

basado en estereotipos con este perfil se logra la asociación de una semántica distinta a los
diagramas del UML puro, con el propósito de acoplar el UML a un dominio específico, en
este caso, las aplicaciones Web. Entre los principales modelos de UWE podemos citar: el
modelo lógico-conceptual, modelo navegacional, modelo de presentación, visualización de
Escenarios Web y la interacción temporal, entre los diagramas: diagramas de estado,
secuencia, colaboración y actividad.
18
UWE define vistas especiales representadas gráficamente por diagramas en UML.
Además UWE no limita el número de vistas posibles de una aplicación, UML proporciona
mecanismos de extensión basados en estereotipos. Estos mecanismos de extensión son los
que UWE utiliza para definir estereotipos que son lo que finalmente se utilizarán en las
vistas especiales para el modelado de aplicaciones Web. De esta manera, se obtiene una
notación UML adecuada a un dominio en específico a la cual se le conoce como Perfil
UML.
UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto
hace especial hincapié en características de personalización, como es la definición de un
modelo de usuario o una etapa de definición de características adaptativas de la navegación
en función de las preferencias, conocimiento o tareas de usuario.
Además de estar considerado como una extensión del estándar UML, también se
basa en otros estándares como por ejemplo: XMI como modelo de intercambio de formato,
MOF para la meta-modelado, los principios de modelado de MDA, el modelo de
transformación del lenguaje QVT y XML.
2.4.3 CARACTERÍSTICAS DE UNA APLICACIÓN WEB
Las Aplicaciones Web tienen una serie de rasgos comunes que diferencia a unos
tipos de aplicaciones software de otros, y que son:
Desde el punto de vista del usuario, se ha universalizado su accesibilidad:
Actualmente un usuario experto y un usuario con habilidad limitada en el uso de
aplicaciones informáticas acceden al mismo tipo de aplicación. Aún más, el número y
tipo de usuario de las Aplicaciones Web no siempre es predecible, lo que obliga a
tener el concepto de facilidad de uso aún más presente que en otros tipos de
aplicaciones.
Desde el punto de vista de la plataforma se realiza un uso intensivo de la red y la
conexión se establece desde distintos tipos de dispositivo de acceso.
19
Desde el punto de vista de la información, asistimos en la actualidad a una
disponibilidad global de fuentes heterogéneas de información, estructurada y no
estructurada, pertenecientes a distintos dominios y que colaboran en el cumplimiento
de los objetivos de la aplicación.
2.4.4 REQUISITOS DE DESARROLLO DE UNA APLICACIÓN WEB
Cada una de estas perspectivas introduce una serie de requisitos que deben ser
tenidos en cuenta durante el proceso de desarrollo de cualquier tipo de Aplicación Web con
el fin de incrementar su probabilidad de éxito de implantación y que pueden ser
estructuradas como sigue:
Portabilidad. Debido a la dinamicidad del entorno tecnológico, a menudo es necesario
implantar una misma aplicación en distintas plataformas, con distintas arquitecturas,
con distintas tecnologías y/o atendiendo a distintos dispositivos de acceso, lo que
obliga a desarrollar técnicas, modelos y herramientas que faciliten la reutilización e
independiza hasta donde sea posible en el desarrollo de la aplicación.
Inmediatez (Rapidez de Implantación). El desarrollo de aplicaciones web requiere un
período de implantación mucho más reducido, que influye en todo su ciclo de
desarrollo.
Creación de contenidos como parte integrante de la fase de ingeniería de la
aplicación. Aunque en este trabajo nos centramos en la especificación de aplicaciones
orientadas a ofrecer funcionalidad compleja, más allá de la mera diseminación de
información, el diseño y producción de textos, gráficos, vídeos etc. que conforman la
estructura informacional de la aplicación es una tarea que debería ser realizada en
paralelo al diseño de la propia aplicación.
Integración (disponibilidad global) de fuentes heterogéneas de información. La
posible necesidad de manejo integrado de contenido estructurado y no estructurado,
almacenado en distintos formatos (bases de datos, sistemas de ficheros, dispositivos
multimedia) y accesibles de forma distribuida mediante múltiples aplicaciones es otro
de los factores que condiciona el proceso de diseño de este tipo de aplicaciones.
20
2.4.5 FASES DE LA METODOLOGÍA UWE
Las fases de la metodología UWE son procesos o actividades que se utilizan y

permiten identificar necesidades de la aplicación o sistema web a desarrollar, estas
actividades se describen y representan en cuatro fases, presentadas a continuación: [11]
2.4.5.1 ANÁSLISIS DE REQUISITOS
Como en otras metodologías, la primera fase o actividad es el análisis de requisitos

funcionales, que permite visualizar los procesos y funciones que debe cumplir el software,
se utilizan diagramas de casos de uso (Figura 2.2). [3]
Figura 2.2: Casos de usos

Fuente: Monografias.com, 2011
Para conocer donde empiezas y terminan su participación de cada actor, debemos

utilizar el diagrama de actividad que nos muestra los procesos de cada actor (Figura 2.3).
Figura 2.3: Diagrama de actividad

Fuente: Elaboración propia
21
Para tener un mejor entendimiento entre los objetos organizadas en una secuencia
temporal, debemos utilizar un diagrama secuencial. En particular muestra los objetos
participantes en la interacción y la secuencia de mensajes intercambiados. [3]
Representa una interacción, un conjunto de comunicaciones entre objetos

organizadas visualmente por orden temporal (Figura 2.4).
Figura 2.4: Diagrama de secuencia

Fuente: Monografias.com, 2011
2.4.5.2 DISEÑO CONCEPTUAL
El modelo conceptual se basa en el análisis y requisitos reflejados en los casos de

uso, comprende el modelo de dominio que al igual que los casos de uso se debe cumplir
con las funcionalidades requeridas por el sistema web a desarrollar, el diseño conceptual no
sufre ningún cambio con el modelo o diagrama de clases correspondientes a UML (Figura
2.5). [11]
22
Figura 2.5: Análisis casos de uso
2.4.5.3 DISEÑO NAVEGACIONAL
Cuando hablamos del desarrollo de un sistema web, es necesario conocer la relación

y enlaces entre las páginas web, es por eso que en la fase de diseño se describen a través de
diagramas la navegación del sistema cumpliendo con lo que se diseñó en los casos de uso.
Los elementos que se utilizan en el diagrama son (Figura 2.6): [11]
Figura 2.6: Elementos del diseño Navegacional

Fuente: Universidad San Carlos de Guatemala, 2008
La aplicación del diagrama se ve de la siguiente manera (Figura 2.7):
23
Figura 2.7: Diseño navegacional UWE
Fuente: Ludwig Maximiliams University Munich, 2012
2.4.5.4 DISEÑO DE PRESENTACIÓN
El modelo de la presentación permite una visión amplia de los procesos de las

páginas o aplicaciones web que se representan en los diagramas de navegación, también
pueden interpretarse también con las interfaces del sistema o aplicación web, para cada
caso se tiene estereotipos o iconos que ayudan al diseño de los diagramas de presentación.
[11]
Los iconos que permiten la realización de los diagramas de presentación poseen una
característica y permite que los diagramas de presentación sean entendibles, como se
muestran a continuación (Figura 2.8):
24
Figura 2.8: Elementos del diseño de presentación
Para el diseño de presentación, se debe tener en cuenta la funcionalidad que se

requiere para el cumplimiento de los requerimientos del usuario.
El diagrama de presentación de la metodología UWE, permite al usuario

comprender y analizar, sobre el área de trabajo al que se someterá con la implementación
del sistema. En la siguiente figura, se muestra la aplicación de los iconos que pertenecen a
los diagramas de presentación (Figura 2.9):
25
Figura 2.9: Diagrama de presentación
2.5 COMPUTACIÓN EN LA NUBE
La computación en nube es un sistema informático basado en Internet y centros de

datos remotos para gestionar servicios de información y aplicaciones. La computación en
nube permite que los consumidores y las empresas gestionen archivos y utilicen
aplicaciones sin necesidad de instalarlas en cualquier computadora con acceso a Internet.
Esta tecnología ofrece un uso mucho más eficiente de recursos, como almacenamiento,
26
memoria, procesamiento y ancho de banda, al proveer solamente los recursos necesarios en
cada momento.
El término “nube” se utiliza como una metáfora de Internet y se origina en la nube

utilizada para representar Internet en los diagramas de red como una abstracción de la
infraestructura que representa.
Un ejemplo sencillo de computación en nube es el sistema de documentos y

aplicaciones electrónicas Google Docs / Google Apps, Office 365, entre otros. Para su uso
no es necesario instalar software o disponer de un servidor, basta con una conexión a
Internet para poder utilizar cualquiera de sus servicios.
El servidor y el software de gestión se encuentran en la nube (Internet) y son

directamente gestionados por el proveedor de servicios. De esta manera, es mucho más
simple para el consumidor disfrutar de los beneficios. En otras palabras: la tecnología de la
información se convierte en una servicio, que se consume de la misma manera que
consumimos la electricidad o el agua. [16]
2.5.1 CAPAS DE LA COMPUTACIÓN EN LA NUBE
La computación en la nube basa su arquitectura haciendo una separación entre

hardware, plataforma y aplicaciones quedando las siguientes capas (Figura 2.10):
27
Figura 2.10: Capas de la computación en la nube
Fuente: José Luis Colom Planas, 2014
2.5.1.1 INFRAESTRUCTURA COMO SERVICIO
La capa de infraestructura es la base de la nube. Se compone de los activos físicos -

servidores, dispositivos de red, discos de almacenamiento, y más. Infraestructura como
Servicio (IaaS, Infrastructure as a Service, Infraestructura como servicio) cuenta con
proveedores como IBM Cloud. Usando IaaS en realidad no controlas la infraestructura
subyacente, pero sí tienes el control de los sistemas operativos, almacenamiento, despliegue
de aplicaciones, y, en un grado limitado, el control sobre determinados componentes de red
seleccionados. Impresión bajo demanda (POD, PrintOnDemand) los servicios son un
ejemplo de organizaciones que pueden beneficiarse de IaaS. El modelo de POD se basa en
la venta de productos personalizables. POD permiten a las personas abrir tiendas y vender
los diseños de los productos. Los comerciantes pueden cargar tantos o tan pocos diseños,
28
como puedan crear. Muchos suben (upload en el original) miles. Con capacidades de
almacenamiento en la nube, un POD puede ofrecer espacio de almacenamiento ilimitado.
[12]
2.5.1.2 PLATAFORMA COMO SERVICIO
La capa intermedia es la plataforma. Proporciona la infraestructura de aplicaciones.

La Plataforma como servicio (PaaS, Platform as a Service, Plataforma como servicio)
proporciona acceso a los sistemas operativos y servicios asociados. Proporciona una forma
de implementar aplicaciones en la nube usando lenguajes de programación y herramientas
de apoyo del proveedor. Usted no tiene que administrar o controlar la infraestructura
subyacente, pero tiene el control sobre las aplicaciones implementadas y, hasta cierto punto
sobre las configuraciones de aplicaciones en el entorno de alojamiento (hosting). PaaS
cuenta con proveedores como Elastic Compute Cloud (EC2) de Amazon. La casa de
software pequeño del empresario es una empresa ideal para PaaS. Con la plataforma
elaborada, productos de clase mundial pueden ser creados sin la sobrecarga de la
producción interna. [12]
2.5.1.3 SOFTWARE COMO SERVICIO
Se encuentra en la capa más alta y consiste en la entrega de aplicaciones completas

como un servicio.
El proveedor de tecnologías de información y comunicación (TIC) ofrece el SaaS

(Software as a Service). Para ello dispone de una aplicación que se encarga de operar y
mantener y que frecuentemente es desarrollada por él mismo. Con ella se encarga de dar
servicio a la multitud de clientes a través de la red, sin que ´estos tengan que instalar ningún
software adicional. La distribución de la aplicación tiene el modelo de uno a muchos, es
decir, se elabora un producto y el mismo lo usan varios clientes.
29
Los proveedores de SaaS son responsables de la disponibilidad y funcionalidad de
sus servicios no dejando de lado las necesidades de los clientes que ﬁnalmente son los que
usaran el software.
Las actividades son gestionadas desde alguna ubicación central, en lugar de hacerlo
desde la sede de cada cliente, permitiendo a los clientes el acceso remo- to a las
aplicaciones mediante la web. Igualmente, las actualizaciones son centralizadas, eliminando
la necesidad de descargar parches por parte de los usuarios finales. [12]
2.5.2 ARQUITECTURA DATOS MULTI USUARIO
Hoy en día la disposición de alta velocidad en el ancho de banda del acceso a

internet, arquitectura orientado al servicio (SOA en inglés), y la gestión económica de
aplicaciones dedicadas en premisa están conduciendo una transición hacia la entrega de
aplicaciones en la nube (SaaS).
Éste es un cambio de paradigma en el cual se impone nuevos retos técnicos.

Algunos frameworks no están diseñados y desarrollados para el manejo fluido de SaaS’s.
Esta falta nos lleva a un nuevo cambio de paradigma llamado Plataforma como servicio
(PaaS). [9]
2.5.2.1 JUSTIFICACIÓN
• El enfoque de arquitectura multiempresa puede beneficiar tanto a los proveedores de

aplicaciones y usuarios.
• Funcionamiento instancia de una sola aplicación para múltiples empresas rinde
grandes beneficios de costos para el proveedor, así como los inquilinos.
• Las empresas pueden personalizar una aplicación como si tuvieran su instancia de
aplicación privada.
• La instancia de solicitud se transforma dinámicamente para cualquier necesidad
inquilino particular.
30
• En lugar de silos aislados de aplicaciones, una aplicación multi-tenants una gran
comunidad organizada (hosted) por el proveedor.
• Hay mucho menos costo de desarrollo y mantenimiento debido a una sola
plataforma (Sistema Operativo, la base de datos, entre otros).
• Se necesita menos trabajo administrativo y personal para el hardware compartido y
entorno de software, lo que conduce a un mayor ahorro de costes.
• Los inquilinos pueden operar en virtual aislamiento, mediante la implementación de
la virtualización.
• Debido a un hardware compartido y participación del software, es fácil de
administrar el acceso de los usuarios a diferentes aplicaciones y los datos, lo que
conduce a una mayor colaboración e integración con el tiempo más rápido a
mercado.
• Varios grupos de usuarios pueden proporcionar información sobre las operaciones
de aplicación por ejemplo de consulta respuestas, errores, y más, lo que permite al
proveedor para hacer mejoras en el hardware común y el software con el fin de
beneficiar a toda la comunidad de usuarios a la vez.
• Algunos de los beneficios secundarios de multi-tenant son servicios de calidad, el
deleite de usuario, y la repetición de negocios. [10]
2.5.2.2 GESTIÓN DE DATOS DE MULTI-USUARIO - 3 ENFOQUES
El grado de aislamiento de un software como servicio puede variar

significativamente dependiendo de los requerimientos del negocio. Hay tres enfoques
principales, cada uno de los cuales se encuentra en una ubicación diferente en la escala
entre el aislamiento y el compartir (Figura 2.11).
31
Figura 2.11: Gestión de datos Multi-tenant, escala entre el aislamiento y el
intercambio
Fuente: ShaileshPaliwal, 2013
1. BD Separadas: El menos preferido es demasiado asilado y con costes altos.

2. BD Compartidas –Esquema separado: Moderadamente preferido, reduce el costo de
recursos pero tiene un alto costo de mantenimiento.
3. BD Compartidos – Esquema compartido: El más preferido con un enfoque de Base de
Datos y el esquema compartidos, éste reduce los recursos y el costo de mantenimiento
en gran medida. [10]
La figura 2.12 nos muestra la taxonomía general de cloud computing para el modelo
SaaS. Cubre horizontal capas de hardware, software, base de datos, y la aplicación de la
capa de proveedor de servicios y verticalmente del consumidor del servicio, la
seguridad, la gestión de capa desarrollador de servicios. [9]
32
Figura 2.12: SaaS, taxonomía del modelo de computación en la nube.
Fuente: The Open Group, 2014
2.5.2.3 CONCEPTOS DE APLICACIONES MULTI-TENANT
A fin de lograr eficiencia de costos en la entrega mismas aplicaciones a diversos

conjuntos de usuarios, es vital y obvia elección de que un número cada vez mayor de
aplicaciones son multi-tenant en lugar de un solo usuario.
Una aplicación multi-inquilino debe ser capaz de satisfacer las necesidades de

múltiples sub-organizaciones o secciones dentro de la organización (múltiples inquilinos),
usando el sencillo, la participación compartida de software y hardware.
33
2.5.3 TIPOS DE NUBES
Existen diversos tipos de nube dependiendo de las necesidades de cada empresa, el

modelo de servicio ofrecido y la implementación de la misma, pero básicamente existen
tres grandes grupos:
Nubes Públicas, las nubes públicas se refieren al modelo estándar de computación en nube,
donde los servicios que se ofrecen se encuentran en servidores externos al usuario,
pudiendo tener acceso a las aplicaciones de forma gratuita o de pago.
Nubes Privadas, en las nubes privadas la plataforma se encuentra dentro de las

instalaciones de la empresa y no suele ofrecer servicios a terceros. En general, una nube
privada es una plataforma para la obtención solamente de hardware, es decir, máquinas,
almacenamiento e infraestructura de red (IaaS), pero también se puede tener una nube
privada que permita desplegar aplicaciones (PaaS) e incluso aplicaciones (SaaS).
Las nubes privadas son una buena opción para las compañías que necesitan alta protección
de datos y ediciones a nivel de servicio. En las nubes privadas el cliente controla qué
aplicaciones usa y cómo. La empresa es la propietaria de la infraestructura y puede decidir
qué usuarios están autorizados a utilizarla.
Nubes Híbridas, las nubes híbridas combinan recursos locales de una nube privada con la
nube pública. La infraestructura privada se ve aumentada con los servicios de computación
en nube de la infraestructura pública. Esto permite a una empresa mantener el control de
sus principales aplicaciones y aprovechar la computación en nube publica solamente
cuando resulte necesario. [12]
2.5.4 VENTAJAS DE LA NUBE
Las ventajas de la computación de la nube son:
Rápida: Los servicios más básicos de la nube funcionan por sí solos. Para servicios
de software y base de datos más complejos, la computación en nube permite saltarse
34
la fase de adquisición de hardware y el consiguiente gasto, por lo cual es perfecta
para la creación de empresas.
Actual: La mayoría de los proveedores actualizan constantemente su software,
agregando nuevas funciones tan pronto como están disponibles.
Elástica: Adaptable rápidamente a negocios en crecimiento o de picos estacionales,
ya que el sistema en nube está diseñado para hacer frente a fuertes aumentos en la
carga de trabajo. Esto incrementa la agilidad de respuesta, disminuye los riesgos y
los costos operacionales, porque sólo escala lo que crece y paga sólo lo que usa.
Móvil: El sistema en nube está diseñado para ser utilizado a distancia, así que el
personal de la empresa tendrá acceso a la mayoría de los sistemas en cualquier lugar
donde se encuentre.
Económica: El proveedor ofrece servicios a múltiples empresas, las cuales se
benefician de compartir una moderna y compleja infraestructura, pagando
solamente por lo que realmente utilizan, eliminando así gastos en infraestructura
innecesaria. [16]
2.5.5 DESVENTAJAS DE LA NUBE
Algunas de las desventajas que presenta la computación en la nube son:
La centralización de las aplicaciones y el almacenamiento de los datos origina una

interdependencia de los proveedores de servicios.
La disponibilidad de las aplicaciones está sujeta a la disponibilidad de acceso a
Internet.
Los datos "sensibles" del negocio no residen en las instalaciones de las empresas, lo
que podría generar un contexto de alta vulnerabilidad para la sustracción o robo de
información.
35
La confiabilidad de los servicios depende de la "salud" tecnológica y financiera de
los proveedores de servicios en nube. Empresas emergentes o alianzas entre
empresas podrían crear un ambiente propicio para el monopolio y el crecimiento
exagerado en los servicios.
La disponibilidad de servicios altamente especializados podría tardar meses o
incluso años para que sean factibles de ser desplegados en la red.
La madurez funcional de las aplicaciones hace que continuamente estén
modificando sus interfaces, por lo cual la curva de aprendizaje en empresas de
orientación no tecnológica tenga unas pendientes significativas, así como su
consumo automático por aplicaciones.
Seguridad. La información de la empresa debe recorrer diferentes nodos para llegar
a su destino, cada uno de ellos (y sus canales) son un foco de inseguridad. Si se
utilizan protocolos seguros, HTTPS por ejemplo, la velocidad total disminuye
debido a la sobrecarga que éstos requieren.
Escalabilidad a largo plazo. A medida que más usuarios empiecen a compartir la
infraestructura de la nube, la sobrecarga en los servidores de los proveedores
aumentará, si la empresa no posee un esquema de crecimiento óptimo puede llevar a
degradaciones en el servicio o altos niveles de jitter.
Privacidad. La información queda expuesta a terceros que pueden copiarla o acceder
a ella. [16]
2.6 ADMINISTRACIÓN DE HISTORIAS CLÍNICAS
2.6.1 DEFINICIÓN DE HISTORIAS CLÍNICAS
Guzmán (2012), resume a las historias clínicas como la base en la relación médico –
paciente, cuya finalidad principal se encuentra, el recoger y agrupar la información
importante y de extrema intimidad referida a los pacientes, a través de datos del estado de
salud del mismo, dicha información otorga al médico una visión completa y global del
36
paciente, de esta forma prestar la debida asistencia médica y atención continuada por
médicos, especialistas, tratamientos o equipos distintos. [14]
El origen de la historia clínica nace con el primer contacto que se establece médico-
paciente para la asistencia médica por medio de levantamiento de datos de forma
interrogativa exploratoria. Fombella y Cereijo (2012). La idea y el concepto actual de lo
que es una historia clínica fue concebida por primera vez por Hipócrates (460 a.C. – 370
a.C.). [13]
2.6.2 CARACTERÍSTICAS
Las características principales de una historia clínica, basados en Guzmán (2012) y

Carnicero (2012), son las siguientes:
Confidencialidad, es deber profesional del médico mantener en confidencia la

asistencia médica administrada a un paciente.
Disponibilidad, está se refiere a que las historias clínicas deben estar disponibles y
con libertad de acceso en casos legalmente contemplados, o bajo procesos de
docencia e investigación.
Individualidad, la información que contienen las historias clínicas debe ser única
para cada paciente, con información legible y exacta, para evitar interpretaciones
inadecuadas. [14]
2.6.3 FINALIDADES
Las finalidades de una historia clínica, no se limitan únicamente a seguimiento o

asistencia médica a los pacientes, ya que su contenido contiene información sobre
trastornos o enfermedades aun no clasificadas, Carnicero (2012). Puede ser utilizada en
otros campos como:
Docencia e Investigación, a partir de la información de en las historias clínicas,

puede enseñarse a nuevos profesionales de salud sobre los casos clínicos expuestos.
37
También se aplica a investigaciones y estudios de patologías, publicaciones
científicas, todas con la autorización del paciente.
Evaluación de calidad, las historias clínicas permite obtener resultados de la calidad
en cuanto a la asistencia médica prestada a los pacientes, que se refleja por medio de
la relación médico – paciente.
Gestión administrativa, se pueden obtener resultados o conclusiones en cuanto a la
administración de recursos y obtener mejoras en el planteamiento de planes y
objetivos de las instituciones médicas, estadísticas mediante las historias clínicas.
Médico – legal, el manejo y gestión de historias clínicas es regida bajo normas de
manejo, establecidas por cada país, en nuestro caso por la “NORMA TÉCNICA
PARA EL MANEJO DEL EXPEDIENTE CLÍNICO”, Ministerio de Salud y
Deportes. [2]
2.6.4 HISTORIAS CLINICAS ELECTRONICAS
Dentro del ámbito de la medicina surge la necesidad de una mejor manejo y

administración de historias clínicas, por su importancia, esté documento debe ser
preservado y seguro.
Gracias a la concepción de las nuevas Tecnologías de la Información y

Comunicación (TIC), nace el concepto de Historia clínica electrónica (HCE), que se
implementa de diferentes maneras, de acuerdo al propósito.
Hayrenen, Saranto y Nykanen (2008), describen que tanto las funcionalidades como
los componentes a integrar pueden variar en diferentes casos. [13]
Cuando la HCE es para un consultorio particular o de ámbito ambulatorio.

Cuando la HCE se aplica a una institución que cubre todo o algunos de los niveles
de atención (emergencias, internación domiciliaria o en la institución, tercer nivel
entre otros).
38
Cuando la HCE integra información de múltiples instituciones con diferentes
niveles, donde la complejidad de estandarización y protocolos de comunicación
aumentan. [13]
39
CAPÍTULO III
MARCO APLICATIVO
3.1 INTRODUCCIÓN
El presente capítulo tiene como finalidad describir el análisis y diseño del software
como servicio para administración de historias clínicas, usando como el caso del
consultorio privado del Médico internista Dr. Juán Yahuita y prueba en el consultorio de la
Dra. Ruth Alvarado. Para el desarrollo del mismo haremos uso de la metodología OpenUp,
cuya descripción, fases y detalles fueron mencionadas en el capítulo del marco teórico; así
mismo de la ingeniería de software.
Presentaremos una descripción breve de las fases a utilizar de la metodología

OpenUp:
Fases Tareas Producto

Inicio -Delimitar la arquitectura, bajo - ORM.
requisitos del doctor. - MTV.
-Definir misión y visión del proyecto. - Historia clínica
Elaboración -Definir requerimientos funcionales. - Diagrama casos de uso.
-Definir casos de uso. - Diagrama de clases.
-Definir los modelos de la metodología - Diagrama de presentación.
UWE. - Diagrama de navegación.
-Definir el modelo de datos SQL - Diagrama de contenido.
- Diagrama de actividades
- Diagrama de secuencia.
- Diagrama de actividades
Construcción -Implementar la solución. - Código fuente del software.
-Ejecutar pruebas del desarrollador. - Prototipo del software.
Transición -Probar la solución. - Pruebas funcionales del
-Comprobar la hipótesis. software.
- Conclusiones.
Tabla 3.1: Fases OpenUp, aplicando UWE

Fuente: Elaboración Propia
40
3.2 FASE DE INICIO
Dentro de la fase de inicio realizamos la redacción de la misión y visión del

proyecto, para lo cual debemos evaluar los objetivos, límites y viabilidad, mediante la
participación del caso interesado y equipo de desarrollo. (Revisar Capítulo I)
3.2.1 DESCRIPCIÓN DE LOS INTERESADOS
Es importante describir a los usuarios interesados dentro de la fase de inicio de la

metodología OpenUp, ya que el software como servicio se desarrollara beneficiaria
directamente a los usuarios y de acuerdo a sus demandas.
La descripción de interesados y responsabilidades son tres:
Interesados Descripción Responsabilidades

Médico Es el responsable de otorgar Realizar el respectivo
el servicio de calidad de seguimiento por medio de
atención médica en su área, las historias clínicas al
crear historias clínicas y paciente, controlar la
evoluciones de los información.
pacientes.
Paciente Clientes del consultorio. Su responsabilidad es la de
brindar datos claros, asistir
a re consultas y realizar los
pagos.
Tabla 3.2 Descripción de interesados

3.2.2 ARQUITECTURA DEL SISTEMA
Los usuarios mencionados, médico, paciente; con diferentes privilegios de acceso e

información dentro del software, describirán la arquitectura del proyecto.
41
Recordamos que para el uso de un Software como servicio es indispensable el uso de
internet, para así aprovechar la adaptabilidad del mismo. Cloud computing, incluyendo
SaaS presenta una arquitectura de datos Multi-tenant.
Cabe mencionar cual es la arquitectura de conexión de Cloud computing y SaaS

(figura 3.1):
Figura 3.1: Arquitectura de conexión cloud computing

Fuente: Elaboración propia, 2014
3.2.3 DEFINICIÓN DE LA SOLUCIÓN PROPUESTA
De acuerdo al anterior punto, tomando en cuenta el cuadro de los interesados, a

continuación presentaremos un resumen de los problemas resueltos para cada uno:
Médico: Siendo el encargado de crear historias clínicas, y controlar el seguimiento

de sus pacientes mediante sus respectivas historias clínicas, el software como
servicio le permite una mejora en la fluidez de su trabajo, mediante los mecanismos
automatizados de actualización y búsqueda de información de las historias clínicas
al mismo tiempo disminuir tiempo al tomar y guardar datos del paciente.
42
Paciente: Son los clientes a los que el médico atiende con calidad y confiabilidad, el
software como servicio brinda información actualizada de los tratamientos que
reciben los mismos.
3.2.4 VISIÓN GENERAL DEL SISTEMA
A continuación se presentara la solución propuesta, sus características y las

necesidades del caso de estudio (Ver tabla 3.3).
Necesidad Prioridad Característica Solución sugerida

Registro Alta Al realizar las historias Registro único de
automatizado de clínicas de manera manual, pacientes y su
historias clínicas. existe el riesgo de datos respectiva historia
perdidos o repetidos de los única.
pacientes.
Control de duplicidad Alta En la búsqueda de historias Implementar controles

y archivo. clínicas puede existir en el software para
duplicidad de pacientes, poder archivar los
incluyendo de persona datos de pacientes
difuntas que se deberían difuntos y la base de
archivar y no usarlas. datos para que no
exista duplicidad.
Tabla 3.3 Registro automatizado de historias clínicas

3.2.5 REQUERIMIENTOS TECNOLÓGICOS
Los requerimientos tecnológicos para el desarrollo del software son:
Computador Core I5 de tercera generación o superior.

RAM de 4 GB
Editor lenguaje de programación Python.
Conexión a internet mínimo 1 MB.
Cuenta en la plataforma como servicio Heroku.
43
Motor de base de datos SQLite 3.
3.3 FASE DE ELABORACIÓN
3.3.1 ESPECIFICACIÓN DE REQUERIMIENTOS
Los requerimientos se obtienen a través de entrevistas y encuestas realizadas a

doctores de diferentes especialidades, interesados en el proyecto como solución, con
conocimiento de las necesidades de los médicos y siguiendo las características y
límites de Guzmán. Presentamos los requerimientos (Ver tabla 3.4):
Código del Prioridad Descripción

Requerimiento
RF – HC - 01 Alta Se podrá realizar la redacción y modificación de las
historias clínicas de los pacientes, sin importar su
padecimiento.
RF – HC - 02 Alta Es necesario que el sistema permita la exportación de
las historias clínicas, en un formato que pueda
imprimirse.
RF – HC - 03 Alta Se podrá evitar la duplicidad de historias clínicas, y

archivo de las historias clínicas.
RF – HC – 04 Alta Se podrá autenticar usuarios.
Tabla 3.4 Requerimientos funcionales – Seguimiento de historia clínica

3.3.2 DESCRIPCIÓN DE ACTORES
Los actores representan un tipo de usuario del sistema. Se entiende como usuario
cualquier persona externa que interactúa con el software El actor es un usuario que juega un
rol con respecto al software. Es importante destacar el uso de la palabra rol, pues con esto
44
se especifica que un actor no necesariamente representa a una persona en particular, sino
más bien la labor que realiza frente al sistema (Ver tabla 3.5):
Actores Definición
Médico El usuario con mayor privilegio médico se
encarga del seguimiento de las historias
clínicas, registro de los pacientes y ver
reportes de seguimiento.
Paciente Es el usuario que facilita sus datos para la
redacción de historias clínicas.
Tabla 3.5 Descripción de actores

3.3.3 MODELOS DE CASOS DE USO
A continuación se muestran los casos de uso de negocio, representando las

funciones que desarrollan un papel importante para el software a implementar.
3.3.3.1 CASOS DE USO

El paciente presenta 2 casos de uso, como se aprecia en la figura 3.2:
Registrar historia clínica, el paciente brinda sus datos para poder registrar la
historia clínica, en la primera consulta con el doctor se deben registrar sus
datos personales por única vez, y los datos de auscultación de esa consulta.
Registrar evolución, cada re consulta el paciente participa de la evolución de
la historia clínica, lo cual significa que solo se apuntará el progreso de su
enfermedad o malestar.
45
Figura 3.2: Caso de uso Paciente
Para el mejor entendimiento de los casos de uso del actor paciente creamos el
diagrama de secuencia para conocer la relación y comportamiento entre los casos de uso en
un determinado tiempo (Figura 3.3):
Figura 3.3: Diagrama de secuencia de paciente

46
El médico cumple el rol más importante, ya que él es el más beneficiado del sistema,
presenta 3 casos de uso, que se aprecian en la figura 3.4:
Registrar de control de sesión, hace referencia a la contratación del servicio

contactándose con el proveedor de servicio.
Registrar historia clínica, el doctor registra los datos personales del paciente,
aun si va a una consulta a domicilio al mismo tiempo inicia los datos del
malestar del paciente previa auscultación.
Registrar evolución, cada vez que el paciente tiene una re consulta es deber
del doctor tomar sus signos vitales y agregar la evolución de la enfermedad o
malestar del paciente.
Ver reportes de seguimiento, puede ver de la información de cuantos
pacientes se atendieron por día, para calcular un ingreso promedio.
Figura 3.4: Caso de uso Médico

47
El médico es quien más participación tiene en el software, prácticamente todas las
jornadas laborales actualizará información de los pacientes, y mensualmente con el
proveedor de servicios (Figura 3.6).
Figura 3.5: Diagrama de secuencia Médico

El Proveedor cumple el rol de prestaciones de servicio, en la figura 3.7:
Registro control de sesión, el proveedor de servicio se encarga de facilitar el

Software como servicio al doctor, con su cuenta de usuario.
Figura 3.6: Caso de uso Proveedor

48
La única relación que tiene el proveedor de servicio es el de registrar cuentas,
después de brindar el servicio recibe un pago mensual (Figura 3.7).
Figura 3.7: Diagrama de secuencia de Proveedor de Servicio

3.3.3.2 DIAGRAMA GENERAL DE CASOS DE USO
La figura 3.8 a continuación se enfoca en el valor suministrado de todos los actores:
49
Figura 3.8: Diagrama general de Casos de Uso
En el diagrama general de casos de uso, seguimiento a historias clínicas, se abarca a

los procesos que realiza la empresa para registrar al paciente, su debida historia clínica y
controles que le realiza el medico a lo largo de un tratamiento, para cumplir con estos
requerimientos, se tiene el siguiente caso de uso general.
En las tablas 3.6, 3.7, 3.8, 3.9 se describen las especificaciones de cada caso de uso,
asociado al módulo de seguimiento de historias clínicas:
50
Nombre: Registrar Historia Clínica
Estado (fase): Análisis
Actor(es): Médico
Precondición: El usuario debe ser autenticado, el paciente debe asistir a la
consulta, o el médico atenderlo a domicilio.
Escenario
Básico: El caso de uso comienza cuando el/la Médico requiere
registrar la historia clínica del paciente.
1. El usuario Médico selecciona la opción registrar la historia
clínica de un paciente.
2. El software despliega el formulario de registro de la
historia clínica.
3. El usuario Médico introduce los datos que se solicitan en la
historia clínica electrónica.
4. El usuario Médico selección guardar.
5. El software valido los datos y guarda la historia clínica.
- Si en escenario 5 del flujo básico el sistema encuentra datos

que no concuerdan con los requeridos entonces el sistema
Escenario
despliega alertas de los datos que no fueron introducidos
Alternativo:
correctamente.
Post condición: La información del paciente se registra en una historia clínica

guardada en la base de datos.
Tabla 3.6: Registrar Historia Clínica

51
Nombre: Ver reporte de seguimiento
Estado (fase): Análisis.
Actor(es): Médico.
Precondición: El usuario debe ser autenticado.
Escenario El caso de uso comienza cuando el/la Médico requiere ver los
Básico: pacientes que fueron atendidos en el día, mes o año.
1. El usuario Médico selecciona la opción ver reportes.
2. El software despliega una ventana con las opciones de
fecha a elegir.
3. El usuario Médico introduce los datos de la fecha.
4. El software muestra de forma tabulado a los pacientes
atendidos en la fecha.
- Si en escenario 3 el flujo básico el software no encuentra

Escenario datos de pacientes atendidos en esa fecha (día) solo mostrara
Alternativo: una ventana en blanco.
Tabla 3.7: Ver Reporte de Seguimiento
Nombre: Registrar control de sesión

Actor(es): Médico
Precondición: El usuario debe ser registrado en la base de datos del
Software como Servicio.
Escenario El caso de uso comienza cuando el usuario Médico desea
Básico: adquirir el Software como servicio.
1. El usuario Proveedor, registra los datos del Médico en
cuentas de usuario para su uso.
2. El usuario Proveedor provee el software sin registros de
ninguna historia en una Plataforma como Servicio.
3. El software despliega la página de bienvenida cuando se
registra el usuario Médico.
Post condición: El Médico cuenta con una cuenta para iniciar sesión en el
Software.
Tabla 3.8: Registrar control de sesión

52
Nombre: Registrar evolución
Actor(es): Médico, paciente
Precondición: El usuario debe ser autenticado, paciente asiste a una re
consulta.
Escenario El caso de uso comienza cuando el paciente regresa al
Básico: consultorio por una re consulta y tiene su historia clínica
creada, el Médico debe anotar las evoluciones del paciente.
1. El usuario Médico selecciona la opción buscar.
2. El usuario Médico ingresa el nombre del paciente.
3. El software despliega al encontrar al paciente, despliega la
historia clínica del mismo.
4. El usuario Médico selecciona la opción añadir evolución.
5. El software crea un campo de texto, con la fecha actual.
6. El usuario Médico ingresa los datos de la consulta del día.
- Si en escenario 1 el flujo básico el software no encuentra

Escenario datos del paciente, el usuario Médico debe crear su Historia
Alternativo: Clínica.
Tabla 3.9: Registrar evolución

Creamos un diagrama de secuencia con todos los casos de uso, objetos y actores
para ver su interacción entre ellos en determinado tiempo, y su mejor entendimiento.
Utilizaremos un diagrama de actividades (ver 2.4.5.1) para un entendimiento total

de cómo reacciona el sistema de un consultorio ante sucesos que se presentan en una
consulta, en la Figura 3.9:
53
Figura 3.9: Diagrama de actividades
3.3.4 DISEÑO CONCEPTUAL
Una de las características de la metodología OpenUp es el diseño conceptual para

dar a entender como están relacionados los componentes del sistema, este puede ser
representado por un diagrama de clases (ver punto 2.4.3.2).
El diseño conceptual del software como servicio para historias clínicas, se define en
la figura 3.10, presentada a continuación:
54
Figura 3.10: Diseño conceptual
Con el diseño conceptual que presenta la figura 3.9 se pasa a realizar el diagrama de clases
para tener más clara la idea de cómo están relacionados sus componentes, en la figura 3.10:
Figura 3.11: Diagrama de clases

55
3.3.5 DISEÑO NAVEGACIONAL
Para entender la navegación en el software utilizamos diagrama del diseño

navegacional (ver punto 2.4.3.3) el cual muestra que el software empieza con una pantalla
de inicio en la cual el Médico debe registrarse para el uso del mismo. El “MenúMédico”
muestra la lista de pacientes con las opciones de poder crear, editar, evolucionar a cualquier
paciente y ver los reportes de la atención por día. Como se muestra en la imagen 3.11:
Figura 3.12: Diseño Navegacional

56
3.3.6 DISEÑO DE PRESENTACIÓN
El modelo de la presentación del software (ver punto 2.4.3.4) es el de una lista de

pacientes, con 3 botones de “ingresar nuevo”, “editar” y “eliminar”. Si se desea agregar
nuevo pacientes se despliega el “formulario de registro”, en el cual llenamos todos los
datos de los pacientes, en el caso de editar todos estos campos podrán volver ser llenados.
El campo de evolución permite que el Médico solo utilice lo necesario para controlar los
malestares del paciente y nos muestra un mensaje de confirmación para aceptar los datos
del paciente, tanto al agregar, editar y evolucionar, como vemos en la figura 3.12:
57
Figura 3.13: Diseño de Presentación
58
3.3.7 DIAGRAMA RELACIONAL
En el presente trabajo utiliza una base de datos SQL en SQLite 3, el cual se

representa con un modelo relacional, normalizando y con ayuda del diagrama de clases
(Figura 3.11) se diseña a continuación en la figura 3.15:
Figura 3.14 Modelo Relacional

59
3.4 FASE DE CONSTRUCCIÓN
En esta fase mostramos el proceder del sistema, sus vistas y funcionamiento:
En cuanto el Médico desea hacer uso del Software debe registrarse con el nombre de
usuario y contraseña que se le asigna.
Figura 3.15: Login de usuario

Una vez logeado el usuario se muestra una pantalla de bienvenida.
60
Figura 3.16: Pantalla de bienvenida
En el parte superior derecha del navegador nos parecen 3 opciones, la opción “Lista
de Pacientes” muestra los pacientes atendidos hasta el momento en el siguiente ordén:
Figura 3.17: Lista de pacientes

61
En esta pantalla de “Lista de pacientes” se puede acceder a la Historia clínica de
cada uno, en el link de su código de Registro. Con su nombre por encima y la fecha de su
primera consulta. Por debajo sus datos personales.
Figura 3.18: Historia Clínica, datos personales

Por debajo aparecen los signos vitales del paciente
Figura 3.19 Historia Clínica, signos vitales y diagnóstico

62
EL software nos permite añadir Evoluciones dentro de la misma pantalla de la
Historia Clínica, así evitamos confusiones a la hora de asignar una Evolución a un Historia.
Figura 3.20: Formulario crear Evolución

Figura 3.21: Guardar Evolución, imprimir Historia

63
La Evolución clínica se muestra por debajo de la Historia clínica en el siguiente
formato:
Figura 3.22: Evolución añadida a Historia Clínica

Al escoger la opción de “imprimir” nos muestra la historia en modo PDF para su

posterior impresión:
Figura 3.23: Reporte de historia Clínica

64
Volviendo a la pantalla de “Lista de Pacientes” tenemos la otra opción de “Añadir
Paciente” que despliega el formulario para crear una nueva Historia Clínica.
Figura 3.24: Formulario añadir paciente

Figura 3.25: Formulario registro paciente

65
La otra opción que tenemos son los reportes:
Figura 3.26: Lista de reportes

Buscamos la fecha deseada o solo el día, mes. Año. Por ejemplo el día 5, sin
immportar el mes ni año. Tenemos:
Figura 3.27: Ejemplo, lista reportes fecha en el día 5

66
El software nos da la opción de imprimir el reporte creado en formato .csv hoja
Excel, por el motivo de modificar la fecha a otro formato:
Figura 3.28: Reporte fechas

Se aplica el mismo método para reporte de edad y sexo.
67
CAPÍTULO IV
ANÁLISIS DE DATOS Y RESULTADOS
4.1 PRUEBA DE HIPÓTESIS
En esta sección realizaremos la evaluación respectiva de la hipótesis planteada al

inicio del presente trabajo que administra Historias Clínicas.
Recordando la hipótesis planteada es:
“Un software como servicio para la administración de historias clínicas implementado
De la cual identificamos la variable dependiente, independiente e interviniente:
Variable Independiente: Tecnología de punta.

Variable Dependiente: Disminuir tiempo de atención, fácil manipulación.
Variable Interviniente: Plataforma como servicio Heroku, Cloud computing.
4.1.1 CONTRASTE DE RACHAS DE WALD – WOLFOWITZ
Supongamos una población cuya función de distribución es desconocida y sea X la

variable aleatoria asociada a esa población, la cual solo puede tomar dos posibles valores
como ejemplo, éxito (A) y fracaso (B):
68
H0: La muestra aleatoria
H1: La muestra no es aleatoria
En general, sea una muestra de tamaño n en la que han aparecido n1 elementos de

tipo A y n2 elementos del tipo B, siendo n1 + n2 = n sea la variable aleatoria:
R: Número total de rachas en la muestra
Para muestra grande y bajo la hipótesis H0 es decir, para muestras aleatorias la

distribución de probabilidad de R tiende hacia la normal a medida que n 1 y n2 se van
haciendo grandes. Esta aproximación es bastante buena si n 1 > 10 y n2 > 10; de tal manera
que:
Esperanza
Varianza
Var[R] =
Por consiguiente para muestras grandes se verifica:
Y para una muestra concreta el calor de estadístico Z será:
69
En donde R es el número total de rachas observadas en la muestra.
La región de aceptación para la hipótesis nula será:
El valor de se obtiene de la tabla de la N (0.1) de manera que:
4.1.2 DESARROLLO DE LA PRUEBA DE HIPÓTESIS
Para el desarrollo de la prueba de hipótesis por medio de contraste de rachas de

wald-wolfowitz se sigue los siguientes pasos:
Paso 1. Planteamiento de la Hipótesis nula.
Hi: Disminuir tiempo de atención, fácil manipulación
Paso 2. Selección el nivel de confianza.
El nivel de confianza o significancia que se elige es α = 0.05 elegida de la Tabla

Normal.
70
Paso 3: Identificación de estadístico de prueba
Para este caso se utiliza la prueba de rachas de Wald-Wolfowitz utiliza os signos de

los residuos y sus variaciones de negativos y positivos o viceversa. Una racha vendrá
constituida por la sucesión de signos iguales.
Paso 4: Formulación de la regla de decisión
Para la prueba, nos planteamos una encuesta de valoración de la Historia Clínica

Electrónica, la cual compara el manejo de Historias Clínicas que tenían los Médicos con el
manejo actual del Software como Servicio (Anexo 4).
De los resultados de la encuesta, que presenta 16 preguntas, tenemos la siguiente

tabla:
71
Aceptación
Nro.
Preguntas Software como por
Pregunta
Servicio Rachas
1 Estructura General de la Historia Clínica Mejora +
2 Introducción de datos Paciente Mejora +
3 Visualización de datos Paciente Indiferente -
4 Introducción de datos Historia Clínica Mejora +
5 Visualización de datos Historia Clínica Mejora +
6 Introducción de Signos Vitales Indiferente -
7 Visualización de Signos Vitales Mejora +
8 Introducción de Evolución clínica Mejora +
9 Visualización de Evolución clínica Mejora +
10 Búsqueda de Historia Clínica Mejora +
11 Impresión Historia Clínica Indiferente -
12 Reporte de Pacientes atendidos por sexo Mejora +
13 Reporte de Pacientes atendidos por edad Mejora +
14 Reporte de Pacientes atendidos por fecha Mejora +
15 Seguridad de Historias Clínicas Mejora +
16 Tiempo de asistencia al paciente Mejora +

Tabla 4.1 Comparación Historia Clínica tradicional con Software como Servicio
Se tienen los siguientes resultados:
(+ +) (-) (+ +) (-) (+ + + +) (-) (+ + + + +)
72
Dónde:
(-) Representa los casos en los que la Historia clínica no presentó mejoría en
comparación al manejo previó de las Historias Clínicas.
(+) Representa los casos en los que el Software como Servicio mostró mejora en
comparación del manejo previó de las Historias Clínicas.
Siendo una racha construida por la sucesión de signos iguales se tiene:
Total de Rachas expuestas
Número total de observaciones
Número de residuos positivos
Número de residuos negativos
Reemplazando daos para calcular la Esperanza y Varianza se tiene:
Esperanza
Varianza
Var[R] =
73
Paso 5: Toma de decisión
Y para una muestra concreta el valor del estadístico Zexp reemplazando datos se
tiene:
Para calcular la región de aceptación de la hipótesis es necesario halar el valor de

que se obtiene de la tabla de la N (0,1), de manera que cumple:
74
Por tanto la región de aceptación para la hipótesis nula es:
-1.96 < 1.12 < 1.96
Se puede ver que el estadístico Zexp = 1.12 se encuentra en el intervalo de la

hipótesis, por lo tanto se puede afirmar que Hi: Disminuir tiempo de atención, fácil
manipulación.
Lo que demuestra que la tesis es un trabajo válido, además muestra que los datos de
la muestra son aleatorios.
75
CAPÍTULO V
CONCLUSIONES Y RECOMENDACIONES
5.1 CONCLUSIONES
Después de diseñar, implementar y probar de forma preliminar el Software

como Servicio para la administración de historias clínicas, en éste capítulo
presentamos los resultados obtenidos durante la investigación:
La implementación del Software como Servicio para administración de Historias

Clínicas en un centro sanitario requiere una correcta metodología de trabajo, se
deben cumplir las normas y reglas de redacción de las mismas.
El acceso instantáneo desde cualquier punto, presenta mayor comodidad a la
hora de editar Historias Clínicas, como la facilidad de atención domiciliaria.
De los resultados obtenidos se desprende que la implementación del Software
como servicio para la administración de Historias Clínicas ha reducido espacios
físicos y ha disminuido la dotación de recursos humanos para la gestión de la
documentación clínica.
El software como servicio para la administración de historias clínicas optimiza
los tiempos de búsqueda y respuesta, evita la pérdida de historias clínicas.
Es requerimiento ineludible el control de acceso, perfiles de usuario para
garantizar la seguridad y confidencialidad de la información clínica, ya que está
penada por ley.
Se logró controlar duplicidad de registros a través de la centralización de
información en una base de datos relacional, que permite la verificación de la
existencia de datos.
Las plataformas como servicios públicas permiten una fácil administración,
hosting y seguridad para el alojamientos de softwares como servicio.
76
La implementación del software como servicio en una plataforma como servicio
pública, permite un ahorro considerable en cuanto a hosting y servidores.
5.2 RECOMENDACIONES
Al haber terminado la tesis, “Software como Servicio para administración de

Historias Clínicas”, se tiene las siguientes recomendaciones, para un buen y mejor
funcionamiento:
Se debe actualizar el proceso de registro y evolución de historias clínicas de acuerdo

a estándares nacionales e internacionales.
Para garantizar la seguridad de la información, se recomienda la generación de

backups, diarios, semanales o mensuales.
Se recomienda utilizar una plataforma como servicio privada para la administración

propia de seguridad y mantenimiento del Software como Servicio y garantizar un
buen funcionamiento del mismo.
Se recomienda el uso de base de datos no relacionales para un futuro desarrollo en

la nube de computación, por la velocidad de acceso.
6. BIBLIOGRAFIA
6.1 REFERENCIAS BIBLIOGRÁFICAS
[1] A. Roger Pressman, Ingeniería de Software, 5ta Edición (2002), Madrid, España. Mc
GRAW-HILL.
[2] Carnicero, Manual de Salud Electrónica para directivos de servicios y sistemas de salud,
publicación de las Naciones Unidas (2002), Madrid, España, ONA.
77
[3] Craig Larman. (2001). aplying UML and patterns. Upper Saddle River, NJ, USA:
Prentice Hall Professional.
[4] Machicao Rejas, Americo Guillermo (2009). Sistema de administración de historias
clínicas Clínica Sanjinés (84). Tesis para obtener el Título de Licenciatura en Informática,
La Paz, Bolivia. Carrera de Informática.
[5] María Leonor Gonzalez. (2013). Seguimiento a Historias Clínicas para la empresa SPA
Médico Cime basado en CRM (121). Tesis para obtener el Título de Licenciatura en
Informática, La Paz: Carrera de Informática UMSA.
[6] María Murazzo, Flavia Millán, Nelson Rodríguez, Daniela Segura, Daniela Villafañe.
(2010). Desarrollo de aplicaciones para cloud computing, En: XVI CONGRESO
ARGENTINO DE CIENCIAS DE LA COMPUTACIÓN. Buenos aires, Argentina.
Universidad Nacional de San Juan, Facultad de Ciencias Exactas, Físicas y Naturales. pp.
s.p.
[7] Miguel Angel Leaño Velasquez (2008). Sistema de Seguimiento de historias clínicas y
fichaje Promes (87). Tesis para obtener el Título de Licenciatura en Informática, La Paz,
Bolivia. Carrera de Informática UMSA.
[8] Santiago Ríos Salgado, Ing. Cecilia Hinojosa Raza, Ing. Ramiro Delgado Rodríguez.
(2012). APLICACIÓN DE LA METODOLOGIA OPENUP EN EL DESARROLLO DEL
SISTEMA DE DIFUSIÓN DE GESTIÓN DEL CONOCIMIENTO DE LA ESPE.
Ecuador: Escuela Politécnica del Ejército.
[9] Susana Chavez, Adriana Martín, Nelson Rodríguez, María Murazzo, Adriana
Valenzuela (2012). Metodología AGIL para el desarrollo SaaS, En: XIV Workshop de
Investigadores en Ciencias de la Computación. Universidad Nacional de Misiones,
Posadas, Misiones, Argentina. Abril 2012.
78
6.2 REFERENCIAS DE INTERNET
[10] Alberto Portillo (2013). Cloud Computing: Justificación y propósito de un proyecto.

17 de junio del 2014. http://todosobresistemasdeinformacion.blogspot.com/2013/11/cloud-
computing-justificacion-y.html
[11] Alexander Knapp, Nora Koch, Martin Wirsing, Gefei Zhang, Christian Kroiss,
Marianne Busch, Sonja Harrer, Segej Kozuruba. (2012). UWE - Ingeniería web basada en
UML. 02 de agosto del 2014, de Ludwig Maximilians University Munich Sitio web:
http://uwe.pst.ifi.lmu.de/teaching/TutorialSpanish.html
[12] Eladio Quelin Maylle Adriano, Javier Navarro Caycho, Raul Rodrigues Alayo (2011).
CLOUD COMPUTING. 2 de Junio del 2014.
http://www.slideshare.net/navarrojavier22/cloud-computing-trabajo-final
[13] Fernando Guzmán, Carlos Alberto Arias (2012), La Historia

Clínica: Elemento Fundamental del acto médico. 26 de junio del 2014,
http://www.scielo.org.co/pdf/rcci/v27nla2.pdf
[14] Germán Santos (2010). La nueva era de los registros clínicos: Historia Clínica
electrónica. T.S.U. Estadística en Salud. 13 de junio del 2014.
http://estadisticassalud.blogspot.com/2010/09/la-nueva-era-de-los-registros-medicos.html
[15] Martín Chuburu, Pablo Davicino, Javier Echaiz, Jorge Ardenghi. (2010).
Convergencia entre Grid Computing y Cloud Computing, Laboratorio de Investigación de
Sistemas Distribuidos (LISiDi). 15 de mayo del 2014, de Universidad Nacional del Sur,
Bahía Blanca. Departamento de Ciencias e Ingeniería de la Computación Sitio web:
http://sedici.unlp.edu.ar/bitstream/handle/10915/19588/Documento_completo.pdf?sequence
=1
79
[16] Priya Viswanathan (2013) Cloud Computing – Is it Really All That Beneficial? 21 de
abril del 2014. http://mobiledevices.about.com/od/additionalresources/a/Cloud-Computing-
Is-It-Really-All-That-Beneficial.htm
[17] Rogelio Rodríguez Porto(2012). Cloud Computing ¿Esta Bolivia en la Nube?. 5 de

Mayo del 2014.http://www.revistasbolivianas.org.bo/scielo.php?pid=S1997-
40442012000200048&script=sci_arttext.
[18] Wiki Eclipse OpenUp. (2012). OpenUp. 16 de mayo del 2014, de Eclipse Sitio web:
http://epf.eclipse.org/wikis/openup
80
ANEXOS
81
ÁRBOL DE OBJETIVOS
82
ÁRBOL DE PROBLEMAS
83
RESUMEN NARRATIVO INDICADORES VERIFICABLES OBJETIVAMENTE MEDIO DE VERIFICACIÓN SUPUESTOS
FIN
Mejorar la administración de manera En el país no existe un software
remota de las historias clínicas de Pruebas del software y mantenimiento. como servicio, almenos no uno
diferentes especialidades médicas comercial .
PROPÓSITO
Proyectos implementados en - Portabilidad limitada del
Desarrollar un Software como Servicio 1 Software como servicio en la nube pública de
plataformas web en hospitales y software.
para administrar historias clínicas de Google., bajo la metodología OpenUp. Hasta el 15 de
clínicas públicas y provadas del - Acceso a historias clínicas fuera
pacientes, sin importar estar o no diciembre del 2014
país. de instituciones.
internados en un hospital.
PRODUCTOS
MATRIZ DE MARCO LÓGICO
1 Software como servicio alojado en una nube pública. 1. Plataforma como servicio con
1. Software como servicio de historiales - Fallas de la plataforma como
6 meses. 1850 $us el software corriendo. (código).
clínicos. servicio.
1 Buscador de histrias clínicas en el SaaS. 500 $us 2. Base de datos, panel de
2. Un buscador de historias clínicas - Mala gestiónde los datos.
1. Control de usuarios para acceder el SaaS. 200 $us administración del SaaS.
digital. - Plugins para navegadores poder
1. Libro tesis de la investigación. 6 meses 50 $us. 3. Cuentas de usuario.
3. Un identificador de usuarios. reconocer el SaaS.
6 meses 2000 $us 4. Libro terminado.
4. Libro Tesis del proyecto.
ACTIVIDADES COSTES
1. a. Programación web 1a. Código.
b. Definir plataforma como servicio. 1d. Encuestas a médicos.
-Análisis de requerimientos 10 días 50 $us
c. Definir lenguaje de prog. 1e. Código, framework a usar.
-Modelado de la arquitectura de software. 20 días. 100 SUPUESTOS
d. Análisis de requisitos. 2a. Tablas base de datos.
$us. - Presupuesto.
e. Arquitectura del software. 2b. Tablas de normalización.
-Programación. 80 días. 1000 $us - Cambio de tecnologías.
2. a.Gestión de base de datos. 3a. Gestor base de datos.
- Normalización de tablas, creación de base de datos, - Documentación retrasada o
b. Normalizar datos de pacientes. 4a. Libros, revistas, proyectos.
creación de cuentas de usuario. 20 días. 500 $us inapropiada.
3. a. Crear cuentas de usuario. 4b. Documento Tesis.
-Documentación. 20 días. 100 $us - Indisponibilidad de personal de
4. a. Revisión de proyectos similares. 4c. Cartas firmadas por
salud para encuestas.
b. Redacción del documento. instancias necesarias,
150 días 1750 $us
c. Presentación de documentos, para documentos presentados.
aprobación de instancias necesarias.
84
ENCUESTA PROPUESTA
Encuesta para implementación de nuevo Software para administración de historias clínicas
Especialidad: _____________________________________
Por favor marque la opción según su criterio:
1.- ¿Cuenta con un consultorio privado?
a) Sí b) No
Si la respuesta fue afirmativa continúe

2.- ¿Hace uso permanente de historias clínicas en su consultorio?
a) Sí b) No
Si la respuesta fue afirmativa continúe
3.- ¿Qué medio utiliza para el registro de historias clínicas?
a) Papel y archivadores b) Hojas de cálculo EXCEL c) Software personalizado

d) Otros (especifique)......
4.- ¿Esta cómodo con la medio que utiliza para el registro de historias clínicas?
a) Sí b) No
5.- ¿La información contenida se encuentra ordenada de manera tal que facilita su búsqueda e
identificación inmediata?
a) Sí b) No
6.- ¿Cree que la portabilidad de sus historias clínicas, mediante celulares o tabletas, es una ventaja
para la administración de las mismas?
a) Muy ventajoso b) Ventajoso c) Indiferente d) No es importante e) Inservible
7.- ¿Estaría dispuesto a invertir en un Software para administración mediante conexión a internet
para la portabilidad de las mismas?
a) Sí b) No
85
ENCUESTA PRUEBA DE HIPÓTESIS
Especialidad: _______________________________________________________________
Empeoró Indiferente Mejora
Estructura General de la Historia Clínica
Introducción de datos Paciente
Visualización de datos Paciente
Introducción de datos Historia Clínica
Visualización de datos Historia Clínica
Introducción de Signos Vitales
Visualización de Signos Vitales
Introducción de Evolución clínica
Visualización de Evolución clínica
Búsqueda de Historia Clínica
Impresión Historia Clínica
Reporte de Pacientes atendidos por sexo
Reporte de Pacientes atendidos por edad
Reporte de Pacientes atendidos por fecha
Seguridad de Historias Clínicas

Tiempo de atención a paciente
86
TABLA DE CALIFICACIÓN

Tesis de grado:
SOFTWARE COMO SERVICIO PARA LA ADMINISTRACIÓN DE HISTORIAS CLÍNICAS
Presentada por: Univ. Yecid Alejandro Yahuita Ponce
Para optar al grado académico de Licenciado en Informática, con mención a Ingeniería de

Sistemas
Nota numeral: _________________________________________
Nota literal: ___________________________________________
Ha sido aprobado con distinción
Director de la carrera de Informática: Msc. Edgar Clavijo Cárdenas
Tutor: Msc. Aldo Valdez Alvarado
Asesora: Lic. Menfy Morales Ríos
Tribunal: _________________________________
Tribunal: _________________________________
Tribunal: _________________________________
87

T 2856

Încărcat de

Informații document

Titlu original

Drepturi de autor

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

T 2856

Încărcat de

Drepturi de autor:

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

SOFTWARE COMO SERVICIO PARA LA ADMINISTRACIÓN DE HISTORIAS

POR: YECID ALEJANDRO YAHUITA PONCE

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

Yecid Alejandro Yahuita Ponce

y sugerencias para el desarrollo de este proyecto.

humor colaboraron para el desarrollo y conclusión del Proyecto de Grado

A Patricia García por la paciencia y la cooperación en la elaboración de mi tesis de grado

Las tecnologías de la información y comunicación van evolucionando a nuevos paradigmas

Hoy en día en el mundo se ve la aceptación de esta tecnología, en numerosas empresas con

Figura 2.1. Proceso OpenUp .............................................................................................................15

Tabla 3.1: Fases OpenUp, aplicando UWE ........................................................................................40

Cloud Computing o computación en la nube es un modelo de aprovisionamiento de

Muchas tecnologías y empresas apuestan por el desarrollo de Software como

Un Software como Servicio para una fácil y portátil administración de historias

La disponibilidad de recursos computacionales conectados a través de Internet y

El concepto fundamental de la entrega de los recursos informáticos a través de una

El concepto de la computación en la nube, o cloud computing, empezó con

La computación en la nube está envolviendo la innovación como nunca antes, con

En las últimas décadas, se desarrollaron Infraestructuras como servicios de las

En cuanto a un Software como servicio de historias clínicas el mejor ejemplo es del

En el ámbito nacional, Bolivia no presenta alguna aplicación conocida en la nube.

“Sistema de Seguimiento de historias clínicas y fichaje Promes” proyecto del

El proyecto más similar al presente es “Sistema Web de “Seguimiento a Historias

1.3 PLANTEAMIENTO DEL PROBLEMA

1.3.1 PROBLEMA CENTRAL

La historia clínica electrónica ya no es un nuevo paradigma que se impone en la

La historias clínicas necesitan de actualizaciones constantemente, sin importar

1.3.2 PROBLEMAS SECUNDARIOS

El proyecto presenta lo siguientes problemas secundarios:

Limitación de acceso remoto a los datos y antecedentes de un paciente, dificultando

1.4.1 OBJETIVO GENERAL

Desarrollar un software como servicio, para la administración de historias clínicas

1.4.2 OBJETIVOS ESPECÍFICOS

Los objetivos específicos planteados para el proyecto son:

Facilitar el acceso a datos de los pacientes, historias clínicas, de manera remota.

Un software como servicio para la administración de historias clínicas

1.6.1 JUSTIFICACIÓN ECONÓMICA

Una de las grandes ventajas de la computación en la nube es el ahorro económico.

1.6.2 JUSTIFICACIÓN SOCIAL

Reducir el tiempo de registro y búsqueda de pacientes permite un mayor número de

1.6.3 JUSTIFICACIÓN CIENTÍFICA

El desarrollo de aplicaciones en la nube en Bolivia es bajo. Se estima que la

1.6.4 JUSTIFICACIÓN TECNOLÓGICA

1.7 ALCANCES Y LÍMITES

Registro del doctor y enfermera o secretaria.

Los límites que presenta el proyecto son:

El prototipo de la presente investigación se aplicará como casos de estudio los

Proporcionar una herramienta que brinde información oportuna y confiable de

El trabajo pretende dar conocimiento y un empujón para la investigación y

El Software como Servicio será desarrollado por la metodología OpenUp propuesta

Para el modelo del Software, se utilizaran elementos y diagramas de desarrollo

2.1 INGENIERIA DE SOFTWARE [1]

Existen diferentes definiciones sobre el término ingeniería de software. La

Entonces, la ingeniería de software comprende el conocimiento amplio de teorías,

2.1.1 METODOLOGIA DE DESARROLLO DE SOFTWARE

De acuerdo al INTECO (Instituto Nacional de Tecnologías de la comunicación,

2.1.1.1 METODOLOGIAS INCREMENTALES

De INTECO (2009), se resume que los métodos incrementales, permiten entregar

2.1.1.2 METODOLOGIAS EVOLUTIVAS

El desarrollo de software por metodologías evolutivas, implica el desarrollo de una