Está en la página 1de 98

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
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

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
Fuente: Elaboración propia
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
Fuente: Ludwig Maximiliams University Munich, 2012

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
Fuente: Ludwig Maximiliams University Munich, 2012

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 finalmente 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


Fuente: Elaboración propia

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


Fuente: Elaboración Propia

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


Fuente: Elaboración Propia

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


Fuente: Elaboración propia

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
Fuente: Elaboración Propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración propia

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
Fuente: Elaboración propia

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


Fuente: Elaboración Propia

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.
Post condición: La información del paciente se registra en una historia clínica
guardada en la base de datos.
Tabla 3.7: Ver Reporte de Seguimiento
Fuente: Elaboración propia

Nombre: Registrar control de sesión


Estado (fase): Análisis
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


Fuente: Elaboración Propia

52
Nombre: Registrar evolución
Estado (fase): Análisis
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.
Post condición: La información del paciente se registra en una historia clínica
guardada en la base de datos.

Tabla 3.9: Registrar evolución


Fuente: Elaboración propia

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
Fuente: Elaboración propia

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
Fuente: Elaboración propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración Propia

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
Fuente: Elaboración Propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración propia

Una vez logeado el usuario se muestra una pantalla de bienvenida.

60
Figura 3.16: Pantalla de bienvenida
Fuente: Elaboración propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración propia

Por debajo aparecen los signos vitales del paciente

Figura 3.19 Historia Clínica, signos vitales y diagnóstico


Fuente: Elaboración propia

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


Fuente: Elaboración propia

Figura 3.21: Guardar Evolución, imprimir Historia


Fuente: Elaboración propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración propia

Figura 3.25: Formulario registro paciente


Fuente: Elaboración propia

65
La otra opción que tenemos son los reportes:

Figura 3.26: Lista de reportes


Fuente: Elaboración propia

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


Fuente: Elaboración propia

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


Fuente: Elaboración propia

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
Fuente: Elaboración propia

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

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 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

También podría gustarte