PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ 
 
FACULTAD DE CIENCIAS E INGENIERÍA 
 
 
 
 
Recuperación de Historias Clínicas Electrónicas a partir de 
un Repositorio Digital usando una Arquitectura Orientada a 
Servicios 
 
Tesis para optar el Título de Ingeniero Informático, que presenta el bachiller: 
Katty Sue Hellen Sánchez Reyna 
 
 
 
ASESOR: Dr. Héctor Andrés Melgar Sasieta 
 
Lima, Agosto del 2015 
                                   
2 
 
Resumen 
El presente proyecto de tesis tiene por objetivo implementar un servicio Web que 
permita el registro y la recuperación de las historias clínicas electrónicas (HCEs) a 
partir de un repositorio centralizado. Cabe resaltar que el presente proyecto 
considera los siguientes formatos médicos: Formato de Atención Integral (del niño, 
del adolescente, del adulto y del adulto mayor), Formato de Emergencia, Formato de 
Consulta Externa, Formato de Hospitalización y Ficha Familiar,  Los resultados 
alcanzados para el logro del objetivo del proyecto son: el diseño de la arquitectura de 
software que tendrá el componente web, la elección de los mecanismos de seguridad 
que garanticen la privacidad y autenticación de los datos de las HCEs, y el servicio 
web implementado. Para definir el diseño de la arquitectura, se tomó en cuenta el 
estándar internacional de calidad de software ISO/IEC 9126 para determinar los 
atributos de calidad requeridos en la arquitectura, tales como: adecuación, tolerancia 
a fallos, capacidad para ser operado, entre otros. Asimismo, se determinaron los 
estilos y patrones de arquitectura a utilizar: orientado a objetos, orientado a servicios, 
arquitectura en N-capas, y patrón repositorio. La arquitectura de software definida se 
basa en el modelo “4+1” que considera 5 vistas: la vista lógica, la vista de 
implementación, la vista de procesos, la vista física y la vista de casos de uso. Luego 
de tener el diseño de la arquitectura, se eligieron los siguientes mecanismos de 
seguridad: pseudonimización que permite garantizar la privacidad de los datos de 
identificación del paciente, y firma digital con cifrado simétrico y asimétrico que 
aseguran la integridad y veracidad de la información almacenada en el repositorio. 
Además, se plantearon alternativas de métodos de seguridad para el control de 
acceso: seguridad del servicio web mediante certificados, restricción de acceso por 
IPs, y Tokens. Finalmente, una vez determinados la arquitectura y mecanismos de 
seguridad que tendrá el web service, se describe la forma en que se implementó 
dicho servicio web que permite registrar y recuperar las HCEs, y  los procesos 
involucrados (registro de un médico, generación de llaves de seguridad, registro de 
un paciente, y registro y recuperación de un formato médico). La implementación del 
servicio web permite dar una alternativa de solución a los problemas generados por 
el registro en físico de las historias clínicas, tales como: ilegibilidad, deterioro, pérdida 
de los registros, y, principalmente, la imposibilidad de acceso a las historias clínicas 
completas de los pacientes. El acceso al servicio web implementado y al repositorio 
centralizado permite integrar y mantener actualizadas todas las HCEs de los 
pacientes. 
                                   
3 
 
Cabe resaltar que para la realización del proyecto se ha tomado en cuenta el marco 
legal peruano. De esta forma los formatos médicos considerados en el alcance son 
los más relevantes y tomando como base la Resolución Ministerial N°776-2004. Del 
mismo modo, para elegir los mecanismos de seguridad, se ha considerado la Ley de 
Protección de Datos Personales. 
Los principales beneficios del proyecto de tesis son: ahorro de espacio físico al 
almacenar las historias de manera digital, se evita la duplicidad, deterioro y pérdida 
de los registros médicos, y, principalmente, se logra el acceso en simultáneo a las 
historias clínicas completas de los pacientes desde cualquier institución médica que 
tenga acceso al servicio web y, por ende, al repositorio centralizado. 
Finalmente, se puede decir que el presente proyecto puede servir de base para 
trabajos futuros, entre los cuales se puede destacar: la consideración de formatos 
médicos adicionales, la integración con el DNI electrónico cuando sea habilitado por 
RENIEC, y la implementación de un proyecto de inteligencia de negocios que permita 
la explotación de  los datos e información registrada en el repositorio.  
 
 
 
 
 
 
 
 
 
 
 
 
 
                                   
4 
 
ÍNDICE 
1.1 Problemática .......................................................................................................... 6 
1.2 Objetivo General y Resultados Esperados ....................................................... 9 
1.2.1 Objetivo general ................................................................................................ 9 
1.2.2 Objetivos específicos ........................................................................................ 9 
1.2.3 Resultados esperados ...................................................................................... 9 
1.3 Herramientas, métodos, metodologías y procedimientos ............................. 10 
1.3.1 Herramientas .................................................................................................... 11 
1.3.2 Métodos y procedimientos ............................................................................. 12 
1.3.3 Metodologías .................................................................................................... 15 
1.4 Alcance ................................................................................................................. 16 
1.5 Riesgos ................................................................................................................. 17 
CAPÍTULO 2 ........................................................................................................................ 18 
2.1 Marco conceptual ................................................................................................ 18 
2.1.1 Registros médicos electrónicos .................................................................... 18 
2.1.2 Conceptos relacionados a la seguridad, privacidad e interoperabilidad 19 
2.1.3 Estándares internacionales relacionados a la medicina ........................... 20 
2.2 Marco regulatorio / legal ..................................................................................... 21 
2.2.1 Normas legales de Historias Clínicas Tradicionales .................................. 21 
2.2.2 Normas legales de Historias Clínicas Electrónicas .................................... 22 
CAPÍTULO 3 ........................................................................................................................ 24 
3.1 Estado del arte ..................................................................................................... 24 
3.2 Objetivos de revisión .......................................................................................... 24 
3.3 Método usado en la revisión .............................................................................. 24 
3.4 Preguntas de investigación ................................................................................ 24 
3.5 Estrategia de búsqueda ..................................................................................... 25 
3.6 Criterios de Inclusión y Exclusión ..................................................................... 25 
3.7 Población .............................................................................................................. 26 
3.8 Respuesta a las preguntas de investigación .................................................. 26 
3.9 Conclusiones sobre el estado del arte ............................................................. 32 
CAPÍTULO 4 ........................................................................................................................ 35 
4.1 Diseño de la Arquitectura de Software de la Herramienta Informática ....... 35 
4.1.1 Resultado esperado 1: Identificación y definición de los atributos de 
calidad requeridos en la arquitectura ........................................................................... 35 
                                   
5 
 
4.1.2 Resultado esperado 2: Estudio de los estilos y patrones arquitectónicos, 
elección del patrón arquitectónico ................................................................................ 37 
4.1.2.1 Estilos arquitectónicos ................................................................................ 37 
4.1.2.2 Patrones de arquitectura ............................................................................ 38 
4.1.3 Resultado esperado 3: Diseño de arquitectura propuesto para la 
herramienta ...................................................................................................................... 39 
CAPÍTULO 5 ........................................................................................................................ 44 
5.1 Elección de los mecanismos para asegurar la privacidad y autenticación de 
los datos de las historias clínicas electrónicas ........................................................... 44 
5.1.1 Resultado Esperado 1: Descripción y elección de los mecanismos para 
asegurar la privacidad y autenticación de los datos de las historias clínicas 
electrónicas ...................................................................................................................... 44 
CAPÍTULO 6 ........................................................................................................................ 47 
6.1 Desarrollo del componente para el registro y recuperación de las historias 
clínicas electrónicas ........................................................................................................ 47 
6.1.1 Resultado esperado 1: Componente para el registro de HCE 
implementado .................................................................................................................. 47 
6.1.2 Resultado esperado 2: Componente para la recuperación de HCE 
implementado .................................................................................................................. 55 
 ............................................................................................................................................... 61 
CAPÍTULO 7 ........................................................................................................................ 65 
7.1 Conclusiones ........................................................................................................ 65 
7.2 Recomendaciones .............................................................................................. 66 
7.3 Trabajos Futuros ................................................................................................. 67 
Referencias bibliográficas .................................................................................................. 68 
 
                                   
6 
 
CAPÍTULO 1 
1.1 Problemática1 
La Historia Clínica (HC) es un documento médico legal que contiene, en forma 
ordenada y secuencial, los datos de identificación y procesos de salud practicados al 
paciente. Estos datos son brindados por los médicos que han atendido al paciente y 
su gestión está a cargo de los establecimientos de salud [1]. A pesar de ser un 
documento de gran importancia, el registro en físico (papel) en el 72% de los 
establecimientos de salud en el Perú genera serios problemas, como: ilegibilidad de 
la información, deterioro o pérdida de registros, demora en la ubicación de la HC de 
un paciente por la enorme cantidad de registros en físico, falta de integridad de las 
historias clínicas de un mismo paciente entre las instituciones médicas [2, 3].  
Motivados por los problemas generados por el registro en papel, surge la idea de 
almacenar las historias clínicas de manera electrónica. Sin embargo, un gran 
problema al que se enfrenta con esta posible solución es el temor y la desconfianza 
a la pérdida de la seguridad e integridad de la información al almacenarlos de manera 
digital. Otro problema es la existencia de muchas tecnologías y estándares que se 
pueden utilizar para el desarrollo de la arquitectura y modelado de datos de manera 
estandarizada en todas las instituciones médicas, entre las principales tecnologías 
relacionadas se puede mencionar: Health Level Seven (HL7), estándar CEN 
ENV13606 [9], arquitectura orientada a servicios (SOA), arquitectura de documentos 
clínicos (CDA) [10], estándares de Clasificación Internacional de Enfermedades 
(CIE), entre otros.   
Con relación a la cantidad de estándares y modelos de referencia para la 
implementación de un repositorio centralizado, estos deben ser estudiados y 
analizados a detalle para determinar el estándar y/o modelo adecuado a ser utilizado, 
de tal forma que se cubran las necesidades de interoperabilidad, accesibilidad, 
confidencialidad, integridad y disponibilidad [4]. Una mala elección en el diseño de la 
arquitectura y posterior implementación del repositorio centralizado puede generar 
problemas de desorganización, inconsistencia de la información  y/o duplicidad de la 
información contenida en las historias clínicas. 
                                                          
1 Para detallar los problemas relacionados se tomó en cuenta el Anexo 1 – Árbol de Problemas para la descripción 
de la problemática. 
                                   
7 
 
Luego de establecer correctamente el estándar o modelo de arquitectura a seguir, se 
debe enfrentar otro problema básico que es la desconfianza en la información 
virtualizada o el temor a la pérdida de privacidad de las HCE. En un estudio realizado 
en un hospital nacional mediante encuestas a 423 médicos, 13 enfermeras y 22 
pacientes, se muestra que un 32% de los médicos considera que la relación y 
comunicación entre médico-paciente se ve afectada por el uso del sistema de HCE, 
un 22% de los médicos no se siente satisfecho con el uso del sistema de HCE, 
asimismo, se indica que un 32% de los pacientes cree que la seguridad y privacidad 
podría perderse por la adopción del sistema [5]. Para resolver este problema, es 
necesario la explicación de las ventajas que ofrece la adopción del sistema de HCE 
centralizado y los mecanismos de seguridad y privacidad de datos que este ofrece, 
entre los cuales se destaca: uso de firmas y certificados digitales, niveles de acceso, 
conexiones seguras. 
Entre las principales ventajas que se lograría con la implementación del sistema se 
resaltan: la legibilidad de los registros, la eliminación de información duplicada, la 
integridad de los datos, la interoperabilidad entre las diferentes instituciones médicas, 
el acceso a la información desde diferentes lugares, y la actualización de los registros 
[4]. No solo ofrece ventajas en cuanto al fácil acceso y gestión de las historias 
clínicas, sino que también permite la reducción de costos de salud al contribuir a 
realizar tratamientos más efectivos para los pacientes [6], por la experiencia adquirida 
por los médicos en el tratamiento de cada vez más tipos de patologías. De esta 
manera, es razonable pensar que cuando más disponible esté la información médica 
de los pacientes, el índice de mortalidad podría reducirse [2].  
Un problema adicional y diferente a la gestión de las  HCE es la asignación de 
presupuestos en instituciones médicas públicas de manera independiente, los 
centros médicos privados también utilizan su propio presupuesto; estos presupuestos 
son utilizados para ser invertidos según lo que defina cada institución, de los cuales 
solo pocas instituciones han invertido en registrar las HCE [2], esto genera que no se 
tenga un mecanismo para el monitoreo y supervisión. Otra consecuencia es que se 
tenga acceso limitado a los registros clínicos de los pacientes, pues al no tener un 
sistema integrado de registro y recuperación, más un marco legal adecuado, 
imposibilita la visualización de la HC con toda la información que ha recibido un 
paciente en todas las instituciones médicas que ha sido atendido. 
Es importante mencionar que actualmente solo el 11% de los centros de atención 
médica cuentan con historias clínicas virtuales [2], sin estar integradas entre sí. En 
                                   
8 
 
otras palabras, la mayoría de las instituciones médicas registran las historias clínicas 
en papel. Por otro lado, las pocas instituciones que lo almacenan de manera digital, 
tienen sus propias bases de datos. La situación actual en los centros médicos se 
podría resumir en la imagen 1. 
 
Imagen 1 – Situación de la problemática actual (Elaboración propia) 
Ante este contexto descrito previamente, surge la pregunta que motiva el siguiente 
estudio: ¿Es posible implementar una herramienta informática que permita 
registrar y recuperar la información de las historias clínicas electrónicas 
haciendo uso de un repositorio centralizado? Por lo descrito anteriormente, se 
puede afirmar que el llevar a cabo este proyecto que permite el registro y la 
recuperación de las HCE usando un repositorio centralizado tendría un alto impacto 
social, pues no solo se verían beneficiados las instituciones médicas, sino también 
los pacientes (recibirían un servicio más eficiente) y los médicos u otro personal de 
las instituciones médicas (adquirirán mayor experiencia y conocimiento respecto a la 
información registrada en diferentes instituciones de salud respecto a alguna 
patología u enfermedad en algún paciente).  
 
                                   
9 
 
1.2 Objetivo General y Resultados Esperados 
1.2.1 Objetivo general 
Implementar un componente informático que permita el registro y recuperación de las 
historias clínicas electrónicas usando un repositorio centralizado a través de una 
arquitectura orientada a servicios. 
1.2.2 Objetivos específicos 
OE1. Definir el diseño de la arquitectura de software del componente informático. 
OE2. Elegir los mecanismos de control para asegurar la privacidad y autenticación 
de los datos de las historias clínicas electrónicas. 
OE3. Implementar el servicio web que permita el registro y recuperación de las 
historias clínicas en el repositorio centralizado. 
1.2.3 Resultados esperados 
Tabla 1 – Relación entre los Objetivos Específicos y los Resultados 
Esperados  (Elaboración Propia) 
OE1.    Definir el diseño de la arquitectura de software de la herramienta  
informática. 
R1.1   Identificación y definición de los atributos de calidad requeridos en la 
arquitectura 
R1.2   Estudio de los estilos y patrones arquitectónicos, elección del patrón 
arquitectónico 
R1.3   Diseño de arquitectura propuesto para la herramienta 
OE2. Elegir los mecanismos de control  para asegurar la privacidad y 
autenticación de los datos de las historias clínicas electrónicas. 
R2.1 Descripción y elección de los mecanismos para asegurar la privacidad y 
autenticación de los datos de las historias clínicas electrónicas. 
OE3.   Implementar el componente de la herramienta informática que permita 
el registro y recuperación de las historias clínicas en el repositorio 
centralizado. 
R3.1Componente para el registro de historias clínicas implementado 
R3.2 Componente para la recuperación de historias clínicas implementado 
                                   
10 
 
1.3 Herramientas, métodos, metodologías y procedimientos 
En esta sección se describirán las herramientas, métodos, metodologías y 
procedimientos que se utilizarán para lograr los resultados esperados mencionados 
anteriormente. Se presenta la siguiente tabla que muestra los resultados esperados 
asociados a las herramientas a utilizarse: 
Tabla 2 – Relación entre Resultados Esperados y las Herramientas 
(Elaboración Propia) 
Resultado Esperado Herramientas, métodos, procedimientos 
y metodologías 
R1.1 Identificación y definición de los 
atributos de calidad requeridos en la 
arquitectura 
 
ISO/IEC 9126: estándar internacional que 
establece un modelo de calidad de 
software en base a ciertas características 
o atributos de calidad. 
R1.2 Estudio de los estilos y patrones 
arquitectónicos, elección del patrón 
arquitectónico 
 
Libro Patrones de Diseño – Elementos 
de software orientado a objetos 
reusables: guía de que define y muestra 
las características de los patrones de 
diseño utilizados para el desarrollo de 
software. 
R1.3    Diseño de arquitectura 
propuesto para la herramienta  
Metodología ICONIX: es una metodología 
pesada-ligera para desarrollo de software 
Modelo 4+1: metodología para el diseño de 
la arquitectura de software. 
Lenguaje Unificado de Modelado (UML): 
lenguaje de modelado para los sistemas 
software. 
R2.1 Lista de posibles mecanismos a 
ser considerados para asegurar la 
privacidad y autenticación de los 
datos de las historias clínicas 
electrónicas. 
Encryption, anonymization and 
pseudonymization: mecanismos de 
protección de los datos para asegurar la 
privacidad. 
R2.2 Selección de los mejores 
mecanismos para la privacidad y 
autenticación de los datos 
Encryption, anonymization and 
pseudonymization: mecanismos de 
protección de los datos para asegurar la 
privacidad. 
                                   
11 
 
R3.1 Análisis y diseño del 
componente a implementar (registro 
HCE) 
 
Metodología ICONIX: es una metodología 
pesada-ligera para desarrollo de software 
Lenguaje Unificado de Modelado (UML): 
lenguaje de modelado para los sistemas 
software. 
R3.2 Componente para el registro de 
historias clínicas implementado 
R3.3 Componente para la 
recuperación de historias clínicas 
implementado 
 
Microsoft Visual Studio 2013: 
herramienta que permite la creación de 
aplicaciones. 
WCF (Windows Communication 
Foundation): Es un marco de trabajo para 
la creación de aplicaciones orientadas a 
servicios. 
NUnit: Es un framework de marco de 
pruebas unitarias para todos los lenguajes 
.NET. 
SQL Server: sistema de gestión de base de 
datos. 
 
1.3.1 Herramientas 
 Microsoft Visual Studio 2013 - Netframework 4.5 
Es una herramienta que se utiliza para crear aplicaciones potentes y de alto 
rendimiento  [22]. Esta herramienta será utilizada durante todo el proyecto para 
realizar el desarrollo del componente de gestión de HCE, pues brinda las 
herramientas y entorno necesario para desarrollar en el lenguaje de programación 
elegido: C#. Este IDE de desarrollo y lenguaje de programación fueron elegidos por 
las nuevas funcionalidades que trae esta versión (NF 4.5), las cuales permiten 
optimizar los recursos, pues ayuda a minimizar líneas de código. Además, ofrece 
opciones de ayuda, por ejemplo: Nuget, esta herramienta permite descargar librerías 
y frameworks de fuentes confiables. 
 NUnit  
Es un framework de marco de pruebas unitarias para todos los lenguajes del paquete 
.NET. Inicialmente portado de JUnit. Está escrito en C# y ha sido rediseñado 
completamente para tomar ventajas en muchas características de los lenguajes del 
                                   
12 
 
paquete .NET  [23]. Este será usado para realizar las pruebas unitarias de las 
funcionalidades de los componentes de recuperación y registro de las HCE. 
 SQL Server 2008 R2 
Es una herramienta que permite la administración de datos de una manera confiable 
y eficaz, ofreciendo características, tales como: almacenamiento de datos locales, 
protección de datos. Está diseñado para la creación de prototipos y para una fácil 
implementación  [24]. Esta herramienta será utilizada en el presente proyecto de tesis 
para almacenar la información de las historias clínicas de los pacientes. Este motor 
de base de datos es compatible con el lenguaje de programación elegido: C#. Cabe 
resaltar que es un producto de Microsoft, la cual es una empresa líder en productos 
software. Es un motor de Base de Datos que a diferencia de las versiones anteriores 
de SQL Server, ofrece varias novedades y mejoras. Ofrece funciones de análisis de 
datos a través de las herramientas PowerPivot, Report Builder y Master Data 
Services, las cuales permiten normalizar y procesar grandes volúmenes de datos, 
gestión centralizada de los datos y generación de informes a partir de flujos de datos 
en tiempo real. Estas herramientas podrían usarse en un futuro para la extracción y 
procesamiento de los datos e información almacenada en el repositorio de HCEs. 
Asimismo, brinda mejoras en escalabilidad y procesamiento para responder a 
necesidades de aplicaciones de base de datos más exigentes [50].  
1.3.2 Métodos y procedimientos 
 ISO/IEC 9126 
Es un estándar internacional que establece un modelo de calidad de software en 
base a ciertas características y subcaracterísticas [26], las cuales se muestran en la 
imagen 2:  
                                   
13 
 
 
Imagen 2 - Características y subcaracterísticas de los atributos de calidad  
[27] 
 Patrones de diseño – Elementos de software orientado a objetos reusables 
Libro escrito por Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (o 
también conocidos como The Gang of Four), este libro describe los patrones de 
diseño existentes para ser utilizado en el posterior desarrollo de un proyecto de 
software [35]. Los patrones de diseño son divididos en 3 categorías, y según el 
alcance (clase u objeto), ver imagen 3: 
 
Imagen 3 - Categorías de los Patrones de diseño (Traducido de [36]) 
Esta guía de patrones será utilizada para el presente proyecto de tesis para poder 
conocer acerca de los patrones de diseño y luego poder determinar cuál o cuáles de 
De Creación Estructural De Comportamiento
Clase Método de Fabricación Adaptador (clases)
Intérprete
Plantilla
Objeto
Fábrica
Constructor
Prototipo
Singleton
Adaptador (objetos)
Puente
Composición
Decorador
Fachada
Flyweight
Apoderado
Cadena de Responsabilidad
Comando
Iterador
Intermediario
Observador
Estado
Estrategia
Visitante
Propósito
Ámbito
                                   
14 
 
los patrones de diseño propuestos se adecúa mejor según el problema que se 
pretende resolver (dar una alternativa de solución): la gestión de las historias clínicas 
electrónicas usando un repositorio centralizado. 
 Lenguaje Unificado de Modelado (UML)  
Es el lenguaje de modelado más utilizado, permite modelar estructura, 
comportamiento y arquitectura de una aplicación, procesos de negocios y estructura 
de datos  [30]. Entre los diagramas que se puede modelar con UML y que serán 
requeridas para modelar la arquitectura del componente software para la gestión de 
HCE, se encuentran los siguientes  [31]: 
 Diagramas de estructura: diagrama de clases, diagrama de 
componentes, diagrama de paquetes y diagrama de despliegue. 
 Diagramas de comportamiento: diagrama de caso de uso, diagrama de 
estados y diagrama de actividad.  
 Diagramas de interacción: diagrama de secuencia. 
 Encryption, anonymization and pseudonymization 
Encryption, anonymization y pseudonymization son mecanismos alternativos que 
permiten asegurar la privacidad de los datos de los pacientes. Estos mecanismos 
serán descritos en la sección de resultados esperados para poder elegir el método 
más conveniente para la gestión de las historias clínicas [37].  
Encryption se refiere a la conversión de los datos electrónicos en otra forma, llamado 
texto cifrado, que solo puede ser entendido por partes autorizadas [43]. La 
anonimización es una técnica aplicada a los datos personales con el objetivo de 
lograr de-identificación irreversible. Por otro lado, la seudonimización consiste en 
reemplazar un atributo (usualmente, se trata de un atributo único) en un registro por 
otro, dicho atributo es conocido como seudónimo [44]. 
  Windows Communication Foundation (WCF) 
Es un marco de trabajo para la creación de aplicaciones orientadas a servicios. WCF 
incluye un conjunto de características [32], las cuales se listan a continuación: 
Orientación a servicios, Interoperabilidad, Varios modelos de mensajes, Metadatos 
de servicios, Contratos de datos, Seguridad, Varios transportes y codificaciones, 
Mensajes confiables y en cola, Mensajes duraderos, Transacciones, Compatibilidad 
con AJAX y REST, y Extensibilidad. 
                                   
15 
 
WCF permitirá que los sistemas software de las instituciones médicas se puedan 
comunicar con nuestros componentes para registrar y/o recuperar las historias 
clínicas desde el repositorio centralizado. 
1.3.3 Metodologías 
 ICONIX 
Es un proceso de desarrollo de software práctico pues se encuentra en un punto 
medio entre la complejidad de la metodología RUP (Rational Unified Process) y la 
simplicidad de XP (Extreme Programming), pero sin eliminar las tareas de análisis y 
de diseño que XP no toma en cuenta. Esta metodología unifica un conjunto de 
métodos orientados a objetos para abarcar todo el ciclo de vida de un proyecto. Se 
divide en 2 partes (modelos): estática y dinámica, las cuales se muestran en la 
imagen 3. Considerando el tiempo con el que se cuenta para el proyecto, se utilizará 
esta metodología para considerar los documentos más relevantes que permitan dar 
soporte a la arquitectura y diseño del componente web a implementar. 
La metodología presenta 4 fases [33], las cuales se describen a continuación: la 
primera fase es el análisis de requisitos, en esta fase se elabora el modelo del 
dominio (diagrama de clases de alto nivel), los prototipos del sistema, los modelos 
de casos de uso organizados en paquetes y la trazabilidad o asociación de los 
requisitos funcionales con los casos de uso y objetos del dominio. Luego, la siguiente 
fase es el análisis y diseño preliminar donde se realiza la descripción de los casos de 
uso, los diagramas de robustez y diagramas de secuencia. La tercera fase es la de 
diseño en la que se completan los diagramas de secuencia y se termina el modelo 
estático (se agregan los detalles del diseño en el diagrama de clases), se verifica si 
el diseño satisface los requisitos identificados. La última fase es la implementación 
en donde se realiza el diagrama de componentes en caso se requiera para apoyar 
durante el desarrollo, se escribe y genera el código para finalmente realizar las 
pruebas. En la imagen 3, se muestra las fases de la metodología ICONIX. 
                                   
16 
 
 
Imagen N°3 – Modelos y Fases de ICONIX (Adaptado de [33]) 
1.4 Alcance 
El presente proyecto de tesis pertenece al área de Sistemas de Información, y tiene 
por objetivo implementar un componente de software para el registro y recuperación 
de las historias clínicas en un repositorio centralizado. Para garantizar que se cumple 
con el objetivo del presente proyecto se deberá realizar lo siguiente: 
 Diseñar la arquitectura de software que se necesita para soportar la estructura de 
las historias clínicas. Se abarcará los siguientes formatos médicos: Formato de 
Atención Integral (del Niño, de Adolescente, del Adulto y del Adulto Mayor), 
Formato de Emergencia, Formato de Consulta Externa y Formato de 
Hospitalización y Ficha Familiar. Asimismo, se incluirán datos adicionales 
relacionados al control y vigilancia de seguridad de medicamentos. 
 Establecer mecanismos de seguridad al tratarse de una solución informática que 
requiere conexión a Internet, los cuales garanticen que la información es 
transportada de manera segura. 
 Implementar los componentes de registro y de recuperación de las historias 
clínicas electrónicas utilizando un repositorio centralizado. 
                                   
17 
 
 Realizar las pruebas necesarias para garantizar el correcto funcionamiento del 
componente implementado. 
Además, se especifican las delimitaciones del proyecto de tesis que brinda una 
alternativa de solución a la gestión de HCE de manera centralizada: 
 Para realizar dichas actividades, se seguirá la metodología ICONIX; sin embargo, 
en la fase de Análisis de requisitos no será posible realizar los prototipos o 
interfaces por tratarse del desarrollo de software de un servicio web, el cual será 
utilizado por las diferentes instituciones de salud. 
 Además, cabe resaltar que no se desarrollará un sistema de información para el 
registro y recuperación de las HCE, sino que se implementará los componentes 
en forma de servicios web, los cuales podrán ser consumidos por las distintas 
instituciones médicas para acceder al repositorio centralizado, ya sea para 
registrar o recuperar los datos de una HC. 
1.5 Riesgos 
En esta sección se presentan los riesgos que pueden ocurrir durante el desarrollo del 
proyecto de fin de carrera que pretende dar una alternativa de solución al problema 
de la gestión de historias clínicas electrónicas de manera centralizada. 
El principal riesgo al que se está expuesto es al cambio en la estructura de la HC. El 
impacto de dicho riesgo sería el retraso en el cumplimiento, pues se requerirá 
replantear lo que se tiene avanzado para adecuarlo a la nueva estructura establecida. 
Una posible medida para mitigar este riesgo sería la priorización a la adaptación a la 
nueva estructura sobre algunas tareas de documentación.  
Un riesgo adicional es la adaptabilidad de los sistemas de los centros médicos al 
servicio Web implementado. El impacto de este riesgo es medio, pues si los sistemas 
informáticos no pueden adaptarse a la estructura definida en el servicio web, los 
métodos no podrán ser consumidos, y no se podrá realizar el registro, ni la 
recuperación de las HCE. Una medida para contrarrestar este riesgo es definir una 
estructura de los datos que serán recibidos lo suficientemente clara para que pueda 
ser entendida en las instituciones médicas.  
  
                                   
18 
 
CAPÍTULO 2 
2.1 Marco conceptual 
Luego de plantear la problemática respecto a la posibilidad de gestionar las historias 
clínicas de manera electrónica, será necesario conocer los conceptos relacionados 
al tema para poder entender el estudio realizado y la alternativa de solución planteada 
para el problema identificado: no contar con un repositorio centralizado para la 
gestión de las historias clínicas electrónicas. Esta sección tiene como objetivo dar a 
conocer al lector los significados de los conceptos antes mencionados. 
2.1.1 Registros médicos electrónicos 
Registro Médico Electrónico (EMR) 
Registro electrónico que contiene información relacionada a la salud de una persona. 
En un centro de salud, médicos y personal autorizados, pueden crear, administrar y 
consultar los EMRs [7]. El EMR contiene toda la información producto de la 
interacción con diferentes profesionales de la salud. 
Registro Electrónico del Paciente (EPR) 
Registro centrado en el paciente con información proveniente de varias instituciones 
médicas [7]. 
Registro Electrónico de Salud (EHR) 
Registro que adiciona al EPR información general relacionada a la salud, esta 
información no necesariamente se refiere a alguna enfermedad [7]. Su propósito es 
proveer un registro documentado del cuidado de salud de un paciente en el presente 
y futuro realizado por uno o varios médicos en diferentes instituciones de salud. Esta 
información contribuye al cuidado del paciente [8]. 
EHR Virtual 
Se refiere a la integración lógica de los sistemas distribuidos que contienen los 
registros médicos electrónicos, independientemente de cómo se logre físicamente 
[8]. 
 
 
                                   
19 
 
Historia Clínica Electrónica (HCE) 
Base de datos integral que contiene información personal relacionada a la salud. Esta 
base de datos puede ser accedida y actualizada por medio de una red de cuidado de 
la salud. 
Por ejemplo, para la solución planteada. Se tendrá registros médicos electrónicos 
para identificar a los formatos médicos: Formato de atención integral, Formato de 
Emergencia, Formato de Consulta Externa y Ficha Familiar. Estos formatos podrán 
ser registrados y recuperados con el componente web a implementar.  
Sistema de Información de Salud (HIS) 
Concepto que surge a partir de la Información de Salud y Tecnologías de 
Comunicación. Mecanismo que permite almacenar, procesar, analizar y transmitir 
información requerida para la planificación, organización, ejecución y evaluación de 
los servicios de salud. Su meta principal es contribuir con el logro de un cuidado de 
la salud más eficiente y de alta calidad [6].  
Algunos ejemplos de HIS para la alternativa de solución son los sistemas médicos 
externos de las diferentes instituciones médicas que harán uso del servicio web para 
registrar las HCEs en el repositorio centralizado. 
2.1.2 Conceptos relacionados a la seguridad, privacidad e interoperabilidad 
Interoperabilidad 
En el área de salud, habilidad que poseen sistemas de información de salud 
heterogéneos y las aplicaciones de computación para comunicarse e intercambiar 
información de manera correcta, efectiva y consistente para el posterior uso de la 
información intercambiada [11]. 
Por ejemplo, para lograr la interoperabilidad entre los sistemas de las instituciones 
médicas se puede utilizar el estándar internacional Health Level 7. 
Firma Digital 
Firma electrónica que usa una técnica de criptografía que usa un par de claves: una 
clave privada y una clave pública, las cuales se encuentran relacionadas entre sí para 
asegurar que las personas que conocen la clave pública no pueda derivar la clave 
privada [12]. 
                                   
20 
 
Certificado digital 
Número único que establece la identidad de un usuario cuando realiza cualquier 
transacción segura mediante una red de trabajo. Según la Ley de Firmas y 
Certificados Digitales, “El certificado digital es el documento electrónico generado y 
firmado digitalmente por una entidad de certificación, la cual vincula un par de claves 
con una persona determinada confirmando su identidad”. 
Algunos métodos de cifrado que permiten el manejo de firmas y certificados digitales 
son: criptografía simétrica y asimétrica. Algunos algoritmos para el cifrado simétrico 
son: Data Encryption Standard (DES), Triple Data Encryption Standard (3DES), 
International Data Encryption Algorithm (IDEA), Advanced Encryption Standard 
(AES) [48]. Por otro lado, los algoritmos y tecnologías para el cifrado asimétrico son: 
Diffie-Hellman, RSA (Rivest, Shamir y Adleman), Digital Signature Algorithm (DSA), 
Criptografía de curva elíptica [49]. 
Protección de datos 
Se refiere a proteger los derechos fundamentales y libertades de personas naturales 
y, particularmente, a su derecho a la privacidad respecto al procesamiento de datos 
personales [4]. 
Seguridad de datos 
Se refiere a proteger los datos personales de destrucción accidental, o contra la ley, 
o pérdida por accidente, alteración o acceso no autorizado, principalmente, cuando 
el proceso incluye la transmisión de datos mediante una red y otras formas de 
procesamiento [4]. 
2.1.3 Estándares internacionales relacionados a la medicina 
Health Level Seven (HL7) 
Estándar acreditado establecido por American National Standards Institute (ANSI) 
para datos administrativos y clínicos. Los sistemas basados en HL7 mejoran su 
habilidad de interoperabilidad e intercambio de datos electrónicos [7]. 
Health Insurance Portability and Accountability Act of 1996 (HIPAA) 
Ley cuyo propósito es mejorar la portabilidad de los seguros de salud y simplificar la 
administración del cuidado de la salud. HIPSS establece estándares para la 
                                   
21 
 
transmisión electrónica de información relacionada a reclamaciones y para garantizar 
la seguridad y privacidad de toda la información médica personal [7]. 
De los conceptos presentados en la sección anterior, se puede observar que existen 
varias formas de denominar a los registros de historias clínicas, entre los cuales están 
los siguientes: EHR, EMR, EPR. Estas abreviaciones serán utilizadas indistintamente 
en la descripción del estado del arte. 
2.2 Marco regulatorio / legal 
En esta sección se describen brevemente las leyes y/o normas legales que pudieran 
afectar y deben ser tomadas en cuenta para el desarrollo del proyecto de fin de 
carrera. Cabe mencionar que las normas y leyes están descritas en orden cronológico 
ascendente. 
2.2.1 Normas legales de Historias Clínicas Tradicionales  
RM 776-2004/MINSA: Norma técnica número 022-MINSA/DGSP-V.01: Norma 
Técnica de la Historia Clínica de los Establecimientos de Salud del Sector 
Público y Privado 
Esta norma técnica define las normas y procedimientos para administrar y gestionar 
las historias clínicas (tradicionales). Asimismo, establece la clasificación de las 
historias clínicas y la estructura que deberá tener para lograr una mejor calidad en la 
atención de los pacientes. 
Las secciones principales que posee una HC son: Identificación de HC, Datos 
Generales, Registro de la Atención de Salud e Información Complementaria. Estas 
secciones a su vez definen datos específicos. 
RM 597-2006/MINSA: Norma técnica número 022-MINSA/DGSP-V.02: Norma 
Técnica de Salud para la Gestión de la Historia Clínica 
Esta resolución aprueba la Norma Técnica de Salud para la Gestión de la HC, refiere 
a los responsables de hacer cumplir dicha norma técnica. Cabe resaltar que esta 
resolución deja sin efecto la RM 776-2004 (antes mencionada) y define otra 
estructura para el archivo de historias clínicas. A diferencia de la resolución anterior, 
la estructura básica posee las siguientes secciones: Identificación del paciente, 
Registro de la Atención de Salud e Información Complementaria. Asimismo, se 
                                   
22 
 
agrega un formato básico: Ficha familiar (en la resolución anterior solo considera 3 
formatos básicos: Formato en consulta externa, emergencia y hospitalización). 
RM 686-2008/MINSA: Norma técnica número 022-MINSA/DGSP-V.02: Norma 
Técnica de Salud para la Gestión de la Historia Clínica, Epicrisis, Informe de 
Alta y Consentimiento Informado 
Esta resolución plantea modificaciones a la Norma Técnica de Salud para la Gestión 
de la HC, básicamente para incorporar la gestión de Epicrisis, Informe de Alta y 
Consentimiento Informado, esto para beneficio de los pacientes y personal de los 
centros de salud. 
RM 732-2008/MINSA: Norma Técnica número 022-MINSA/DGSP-V.03: Norma 
Técnica de Salud para la Gestión de la Historia Clínica. 
Esta resolución deja sin efecto la RM 686-2008, pues realiza actualizaciones y 
modificaciones a la Norma técnica de salud para la gestión de la historia clínica, 
estableciendo así la tercera y última versión de dicha norma. 
2.2.2 Normas legales de Historias Clínicas Electrónicas 
RM 466-2011/MINSA: Prepublicación del proyecto de Directiva Administrativa 
que aprueban las especificaciones para la estandarización del registro en la 
Historia Clínica Electrónica 
Esta es la primera resolución en la que se plantea la alternativa del registro 
electrónico de las HC. Se dispone que la Oficina General de Comunicaciones lleve a 
cabo la prepublicación del proyecto de Directiva Administrativa para aprobar las 
especificaciones para la estandarización del registro de la HCE, y recibir sugerencias 
y comentarios de los ciudadanos. 
RM 576-2011/MINSA: Directiva Administrativa número 183-MINSA/OGEI V.01 
“Directiva Administrativa que establece las especificaciones para la 
estandarización del registro en la HCE" 
Se aprueba la Directiva Administrativa que establece las especificaciones para la 
estandarización del registro en la HCE, asignando a la Oficina General de 
Comunicaciones como la encargada de difundir, monitorear y evaluar que se cumpla 
dicha directiva. 
 
                                   
23 
 
RM 328-2013/MINSA: Ley N° 30024 - Ley que crea el Registro Nacional de 
Historias Clínicas Electrónicas 
El objetivo de esta ley es crear el registro de HCEs y definir sus objetivos, 
administración, organización, implementación, confidencialidad y accesibilidad. 
Esta ley plantea que los registros de las historias clínicas electrónicas deben tener 
datos e información estandarizados, la forma de organizarlos y mantenerlos. Esta 
información debe estar disponible en todo momento a los especialistas o paciente, 
para lo cual se requiere tener la capacidad de  interoperabilidad, logrando así la 
comunicación y compartimiento de información entre los diferentes centros médicos. 
RM 726-2013/MINSA: Prepublicación del proyecto de la Ley número 30024, Ley 
que crea el Registro Nacional de Historias Clínicas Electrónicas 
La Oficina General de Comunicaciones lleva a cabo la prepublicación del Proyecto 
de Ley N°30024 (Ley que crea el registro nacional de HCEs) para recibir comentarios 
y sugerencias de las entidades públicas, privadas y la ciudadanía. Los aportes serán 
procesados  a fin de elaborar dicho proyecto. 
Ley N° 29733: Ley de Protección de Datos Personales 
Esta ley tiene como objetivo garantizar el derecho que tiene todo ciudadano a la 
protección de sus datos personales. Se relaciona al problema identificado, pues la 
HC contiene datos personales de un paciente, y su gestión electrónica debe asegurar 
la integridad y protección de los EMRs. 
Ley N° 27269: Ley de Firmas y Certificados Digitales 
Esta ley tiene como principal objetivo otorgar la misma validez que una firma 
manuscrita a la firma electrónica para autenticar un documento administrado 
electrónicamente. Esta ley es requerida en las HCE para las actualizaciones que 
requieran realizar los diferentes médicos que atienden a un paciente y las 
autorizaciones del paciente para las diferentes prácticas médicas que se le realicen.   
  
                                   
24 
 
CAPÍTULO 3 
3.1 Estado del arte  
En la siguiente sección se realizará una revisión sobre los estudios, investigaciones, 
herramientas relacionados a la gestión de las HCE. Esta revisión permitirá tener un 
mejor entendimiento del contexto global de los avances relacionados al problema 
planteado en el presente proyecto de fin de carrera, de tal manera que puedan ayudar 
a encontrar una alternativa de solución. 
3.2 Objetivos de revisión 
Los objetivos que se pretenden cubrir según el problema identificado son los 
siguientes: 
 
3.3 Método usado en la revisión 
El método a utilizar es la revisión sistemática, la cual es un medio para identificar, 
evaluar e interpretar todas las investigaciones relevantes disponibles respecto a una 
(o varias) pregunta(s) de investigación particular, área temática o fenómeno de 
interés [41].  
3.4 Preguntas de investigación 
Las preguntas de investigación que se pretende resolver son las siguientes: 
 
• Identificar los problemas o desventajas que se presentan al tener un registro de historias 
clínicas administradas de forma independiente por cada institución médica
• Encontrar modelos, estándares y/o tecnologías existentes para el desarrollo de un 
repositorio centralizado de las HCE
• Identificar los requisitos a ser tomados en cuenta para implementar la plataforma para la 
gestión de registros clínicos electrónicos.
• Identificar los beneficios que traería el desarrollo de una plataforma informática para el 
registro y recuperación de las HCE usando un repositorio centralizado.
• ¿Qué problemas se presentan al tener un registro de historias clínicas administradas de 
forma independiente por cada institución médica?
• ¿Qué modelos, estándares y/o tecnologías existen para el desarrollo de un repositorio 
centralizado de las HCE?
• ¿Qué consideraciones o requisitos deben ser tomados en cuenta para la implementación 
del repositorio centralizado para la gestión de historias clínicas electrónicas?
• ¿Qué beneficios traería el desarrollo de una plataforma informática para el registro y 
recuperación de las HCE usando un repositorio centralizado?
                                   
25 
 
Estas preguntas se resolverán utilizando las palabras claves para buscar los estudios 
y aplicando ciertos criterios de inclusión y exclusión sobre los estudios encontrados 
en los indexadores de búsqueda. 
3.5 Estrategia de búsqueda 
Para la búsqueda e identificación de los estudios primarios, se establecieron las 
siguientes cadenas de búsqueda:
 
Dichas cadenas de búsqueda fueron ejecutadas en los siguientes indexadores: 
ScienceDirect y Scopus. 
3.6 Criterios de Inclusión y Exclusión 
Luego de revisar los estudios mostrados como resultados de ingresar la cadena de 
búsqueda, los criterios de inclusión y exclusión a considerar se muestran en la tabla 
3: 
Tabla 3 – Criterios de inclusión y exclusión de la revisión sistemática 
 
• ("medical history" OR "clinical history" OR ehr OR emr) AND 
(advantages OR benefits OR disadvantages OR issues) AND independent 
AND ("health information system" OR his) AND ((record OR retrieval) 
AND information) AND (HL7 OR 9126)
• ("medical history" OR "clinical history" OR ehr OR emr) AND (model 
OR implementation) AND independent AND ("health information system" 
OR his) AND ((record OR retrieval) AND information) AND (HL7 OR 9126)
CRITERIOS DE INCLUSIÓN
• Estudios que muestran las soluciones informáticas que se han aplicado para el 
registro y recuperación de las HCE.
• Estudios que muestran los problemas o consideraciones a tener en cuenta al plantear 
una plataforma informática para gestionar las HCE.
• Estudios que contengan las palabras clave en el ámbito deseado.
• Estudios publicados en los últimos 20 años
• Estudios y publicaciones en inglés o español
CRITERIOS DE EXCLUSIÓN
• Estudios que muestran soluciones informáticas que no se orienten a la gestión de 
historias clínicas.
• Estudios relacionados al sector de salud con soluciones tecnológicas, pero enfocado a 
enfermedades específicas.
• Estudios que muestran las palabras clave aplicado a otro ámbito de estudio.
                                   
26 
 
3.7 Población 
Estudios seleccionados luego de aplicar los criterios de inclusión y exclusión. Los 
títulos, autores y año de publicación de los estudios seleccionados se muestran en 
la tabla 4. 
Tabla 4 – Tabla que muestra los estudios seleccionados en la revisión 
sistemática 
Estudio Año Publicación 
The electronic health record and its contribution to healthcare 
information systems interoperability 
2013 
Inter-organizational future proof EHR systems. A review of the security 
and privacy related issues 
2009 
A model-driven approach for representing clinical archetypes for 
Semantic Web environments 
2009 
Glossary of health information technology terminology 2008 
“Advanced and secure architectural EHR approaches 2006 
A Survey and Analysis of Electronic Healthcare Record Standards 2005 
Data security and protection in cross-institutional electronic patient 
records 
2003 
La revisión sistemática fue revisada a la fecha 3 de Abril del 2015. 
3.8 Respuesta a las preguntas de investigación 
 Problemas presentados en registro de historias clínicas administradas de 
forma independiente 
La mayoría de instituciones médicas en Perú continúan almacenando las HCs en 
papel [2]. Sin embargo, existen problemas relacionados a esta forma de almacenar 
los registros clínicos, entre los cuales se puede destacar: dificultad de lectura, 
duplicidad de información en los diferentes centros médicos. De las pocas 
instituciones médicas que usan historias clínicas electrónicas [2], estas las gestionan 
de manera independiente, lo cual hace que sea difícil de integrar los datos de un 
mismo paciente, la organización de los mismos y la forma cómo se visualizan. Esto 
se debe, principalmente, a que las diferentes instituciones médicas tienen diferentes 
tipos, forma y naturaleza de los datos, los cuales son almacenados en diferentes 
bases de datos y con diferentes arquitecturas [6]. 
 
                                   
27 
 
 Modelos, estándares y tecnologías existentes para el desarrollo de un 
repositorio centralizado 
Enfoque de modelo dual 
Los estándares OpenEHR y CEN ENV13606 se basan en el enfoque de modelo dual. 
HL7 es otro estándar para representar y comunicar los EMRs; los estándares definen 
y administran su propia información de manera particular. Esto implica que las 
organizaciones médicas podrían tener diferentes formas de administrar sus EMRs. 
El enfoque de modelo dual define 2 niveles conceptuales: modelo de referencia y 
modelo de arquetipo. El modelo de referencia representa las características globales 
de las anotaciones de los registros de salud, este modelo define el conjunto de clases 
que forman los bloques de construcción genéricos de los registros electrónicos de 
salud, contiene las características no volátiles de dichos registros.  
Por otro lado, el modelo de arquetipo modela las características comunes de los tipos 
de entidades y define las estructuras de información válidas.  Para expresar estos 
arquetipos, se puede utilizar Lenguaje de Definición de Arquetipos (ADL). Ontologías 
son otra opción para representar la semántica de información clínica. Lenguaje Web 
de Ontología (OWL) permiten modelar las ontologías [9]. 
Arquitectura Orientada a Servicios (SOA) 
Arquitectura que describe las prácticas y frameworks que habilitan la funcionalidad e 
información de las aplicaciones que van a ser dadas y consumidas como interfaces 
de servicios. SOA es un conjunto de servicios de software que se comunican entre 
sí sobre una red para transmitir datos o coordinar una actividad. Estos servicios 
pueden implementarse usando diferentes tecnologías, pudiendo encapsular la 
funcionalidad e información de las aplicaciones. Aplicado al área de salud, SOA debe 
soportar las necesidades de interoperabilidad, diferentes grados de integración, 
varios patrones de mensajes y diferentes fases del ciclo de vida del sistema. 
Arquitectura de Documentos Clínicos (CDA) 
Asegura la consistencia de la estructura para permitir la interpretación tanto del 
sistema de computación y los usuarios finales [6]. Esta arquitectura desarrolla 
mensajes adecuados para soportar comunicaciones de EHR. Se basa en el Modelo 
de Información de Referencia (RIM) y los refinamientos de éste: Modelo de 
                                   
28 
 
Información de Mensajes Refinados (RMIM) y Tipos de Elementos en Mensajes 
Comunes (CMET) para los ámbitos de EHR [10]. 
Estándar CEN ENV13606 “EHCR communication” 
Estándar que consta de 4 partes: arquitectura extendida, lista de términos de dominio, 
reglas de distribución y mensajes para el intercambio de información. Según este 
estándar, un EHR comprende del componente de arquitectura raíz y de un 
componente de registro establecido por complejos de componentes originales 
(OCC), el cual consta de 4 componentes: carpetas, composiciones, secciones 
dirigidas y clusters [10]. 
Estándar HL7 (Health Level Seven) 
Existen diferentes versiones de este estándar. HL7 versión 2.x es el estándar de la 
industria usado para transmitir información clínica y administrativa entre diferentes 
aplicaciones de salud, se basa en el intercambio de mensajes (documentos en XML) 
entre aplicaciones [6]. Por otro lado, HL7 versión 3 sigue un enfoque orientado a 
objetos usando los principios de lenguaje de modelado unificado (UML) para modelar 
los casos de uso y modelos de interacción a los mensajes específicos [8]. UML se 
basa en un modelo de datos llamado Modelo de Información de Referencia (RIM). 
HL7 especifica el modelo RIM para cubrir  toda la información del área de salud de 
una forma genérica y entendible. El RIM de HL7 define 6 entidades (objetos de 
información física en el dominio de salud) de clases principales y sus asociaciones 
entre ellas, y el rol de dichas entidades [10]. 
Estándar de Clasificación Internacional de Enfermedades (CIE 10 PCS) 
La Clasificación Internacional de Enfermedades (CIE) es definida y actualizada 
periódicamente por la Organización Mundial de la Salud (OMS) para obtener nuevos 
descubrimientos y cambios en el conocimiento médico acerca de las enfermedades.  
La CIE-10 o Clasificación internacional de enfermedades, décima versión 
establece una clasificación de las enfermedades, signos, síntomas, hallazgos 
anormales, y causas externas de daños y/o enfermedad a través de códigos 
conocidos mundialmente. Estos códigos tienen una estructura estandarizada y 
descriptiva.  
Esta versión reemplaza al volumen 3 de la CIE-9. La siguiente tabla muestra las 
principales diferencias entre ambos estándares establecidos por la OMS [51]. 
                                   
29 
 
Tabla 5 – Diferencias entre el CIE-9 y el CIE-10 [51].
 
 
 Consideraciones al implementar una herramienta informática para registrar 
y recuperar las HCE 
La protección y la seguridad de los datos de salud del paciente deben tenerse en 
cuenta, pues es un requerimiento legal. Los datos personales contenidos en las HCE 
son datos personales altamente sensitivos y requieren protegerse para evitar el 
acceso de personas no autorizadas, es decir, debe asegurarse su confidencialidad e 
integridad mediante aspectos de seguridad y protección de datos.  
La seguridad y protección de datos logran su propósito asegurando 5 objetivos 
fundamentales: confidencialidad, integridad, autenticación, “accountability” y 
disponibilidad. 
Confidencialidad: los datos del paciente estén disponibles solo para personas 
autorizadas. Se logra mediante conexiones seguras, lo cual requiere establecer un 
Firewall entre la red interna e Internet. Esta medida ayuda a combatir riesgos de 
“afuera”, para prevenir el riesgo del acceso a personas no autorizadas, se requiere 
conceptos de autorización de los sistemas de información. Los conceptos de 
autorización establecen los usuarios y sus roles autorizados al acceder a la 
información de salud del paciente. Otras formas de implementarlo es etiquetando la 
información con metadatos acerca del estado de confidencialidad o mediante reglas 
de acceso basándose en los logs de auditoría [8]. 
Integridad: los datos del paciente no puede ser actualizada o eliminada por personal 
no autorizado. Una opción para garantizar la integridad es aplicar firmas electrónicas. 
Autenticación: es la verificación de que la persona es quien dice ser. Consiste en 
verificar las credenciales del usuario. No basta solo una contraseña para la 
CIE-9-MC volumen 3 CIE-10-PCS
Sigue la estructura de la CIE (diseñada para 
codificación de diagnósticos)
Diseñada/desarrollada para cubrir las 
necesidades en materia de codificación de 
procedimientos de la atención sanitaria
Los códigos se presentan en forma de conjunto 
fijo/finito en formato de lista
Los códigos se construyen a partir de 
componentes de codificación (valores) 
flexibles, mediante el uso de tablas
Los códigos son numéricos Los códigos son alfanuméricos
Los códigos tienen una longitud de 3 a 4 dígitos Todos los códigos tienen 7 caracteres
                                   
30 
 
autenticación, se requiere una forma más segura de autenticación del usuario: tokens 
de hardware o tarjetas inteligentes combinadas con un servidor de autenticación.  
“Accountability”: permite la trazabilidad de las modificaciones que una persona 
realiza sobre un EPR. Se logra por medio de realizar auditorías de monitoreo o 
archivos logs, estos registran las acciones realizadas sobre la información y los 
usuarios que lo hicieron para poder recuperar el estado pasado de ser necesario [8].  
Disponibilidad: los datos del paciente puedan ser accedidos y usados por personas 
autorizadas cuando lo requieran. Depende de la conexión entre las instituciones de 
salud y dar a conocer los conceptos de emergencia [4]. 
Un segundo enfoque [8], plantea los requerimientos de seguridad de los EHRs son: 
autenticación, autorización, integridad de datos, no-repudio, confidencialidad y 
consentimiento. Se define los conceptos que no son cubiertos por el primer enfoque: 
Autorización: se refiere a los derechos de acceso de un usuario que acaba de ser 
autenticado para acceder a los datos o funcionalidad del sistema.  
No-repudio: permitir que cualquier actor obtenga prueba que valide la integridad y 
origen de los datos. 
Consentimiento: obtener, registrar y dar seguimiento al consentimiento de los 
pacientes para permitir el acceso a la información de su salud para propósitos 
específicos. Este consentimiento debe darse antes de compartir la información de un 
paciente. Puede ser dado de dos formas: consentimiento implícito (se asume que el 
paciente ha consentido el compartir su información, a menos que indique lo contrario) 
o consentimiento explícito (el acceso a la información del paciente está totalmente 
prohibida, a menos que el paciente de su consentimiento).    
Otra característica importante que un Sistema de Información que registra HCEs es 
la interoperabilidad, es decir, que permita la cooperación y comunicación entre los 
sistemas en diferentes niveles, lo cual permite integrar y compartir información de los 
registros electrónicos de salud [6]. Esto permite soportar el procesamiento 
automático de datos en los sistemas que recuperan la información de un paciente 
[8]. 
Finalmente, entre otras consideraciones generales, cabe resaltar las siguientes: 
responsabilidad de autor, administración o control de versiones, acceso de los 
pacientes, y el archivamiento y retención de los datos [8]. 
                                   
31 
 
Responsabilidad de autor: permite asegurar que se conoce quién realiza alguna 
contribución al registro médico. 
Administración o control de versiones: permite gestionar las versiones realizadas 
por actualizaciones o modificaciones realizadas a un registro. Cada vez que se 
produzca una actualización, las partes relevantes deberán ser notificadas. 
Acceso del paciente: permitir al paciente el acceso a toda su información contenida 
en su EHR, pero siempre sujeto a restricciones jurisdiccionales. 
Archivamiento de datos: se refiere a mover la información del EHR a un 
almacenamiento off-line y tener la posibilidad de cargarlo en almacenamiento on-line 
cuando sea necesario sin pérdida de valor. 
Retención de datos: tener la funcionalidad de almacenar la información clínica de 
un paciente por la duración especificada (como mínimo) según políticas legales. Esto 
previene que la información sea eliminada en cualquier instante. 
 Beneficios que ofrece el desarrollo de una herramienta informática para 
registrar y recuperar las HCE usando un repositorio centralizado 
La mayoría de instituciones médicas actuales continúan registrando las historias 
clínicas en papel; sin embargo, debido a las deficiencias mencionadas anteriormente, 
surge la idea del registro electrónico de los pacientes (EPRs). 
Las ventajas que ofrece los EPRs son: ahorra espacio de almacenado, mejor 
legibilidad de la información, acceso rápido a información útil en simultáneo por varios 
especialistas en diferentes ubicaciones para la toma de decisiones, eliminación de 
documentos redundantes. Además, junto con los sistemas de información clínica y 
enfocada en los pacientes, EPRs permiten optimizar la exactitud, integridad, 
completitud, costos y efectos de los procesos clínicos y sus resultados. En otras 
palabras, los EPRs pueden  proveer una base sólida que soporte el cuidado de la 
salud centrada en el paciente [4].  
Otra ventaja de los EMRs es que hay mayor facilidad y efectividad en la 
administración de los registros médicos, esto permite información actualizada y 
centralizada. Esto se puede reflejar en la reducción de costos de salud y la 
contribución a tratamientos más efectivos para los pacientes [6]. 
                                   
32 
 
Finalmente, un beneficio importante es la disponibilidad en cualquier momento de las 
HCE permitiría reducir el índice de mortalidad y una mayor experiencia a los médicos 
para atender una variada cantidad de enfermedades [2]. 
 Caso de aplicación – Google Health 
Google Health era un servicio centralizado de información personal de salud. Este 
servicio permitía a los usuarios de Google almacenar su historia clínica, esto permitía 
que Google tenga de manera centralizada todas las historias clínicas registradas por 
los usuarios. 
Este servicio estuvo habilitado desde el 20 de mayo del 2008 hasta que fue 
suspendido el 1 de enero del 2012, se dio un año adicional (1 de enero del 2013) 
para que los usuarios puedan recuperar su información. Google decidió dar de baja 
este servicio al no tener el impacto que se esperaba [52].  
Algunas posibles causas por las cuales este servicio no tuvo éxito son las siguientes: 
la mayoría de los usuarios no estaban interesados o no sabían lo que era un registro 
e-health, los usuarios consientes de los PHRs tienden a usar portales de planes de 
salud para dar seguimiento a sus registros, la falta de relaciones con proveedores y 
otras fuentes de datos que puedan importar los datos a Google Health, y, por último, 
la preocupación de los pacientes acerca de la privacidad y seguridad de su 
información [53]. 
3.9 Conclusiones sobre el estado del arte 
Se desprende la tabla 6 que muestra el resumen luego de realizar los estudios 
respecto al problema central respecto a la gestión de las historias clínicas: 
Tabla 6 – Resumen de los Subtemas en Estudio 
Subtema Resumen 
Problemas y/o desventajas por el 
registro de historias clínicas 
independientemente por cada 
institución médica 
 Dificultad de lectura 
 Duplicidad de registros 
 Difícil de integrar toda la información de la 
historia clínica de un paciente 
 Diferentes estructuras de las historias clínicas 
en las diferentes instituciones 
Modelos, estándares y tecnologías 
para desarrollar un repositorio 
centralizado de HCE 
 Enfoque de modelo dual 
 Arquitectura orientada a servicios (SOA) 
 Arquitectura de documentos clínicos (CDA) 
                                   
33 
 
 Estándar CEN ENV13606 “EHCR 
communication  
 Estándar Health Level Seven (HL7)” 
Consideraciones y/o requisitos a ser 
tomados en cuenta para la 
implementación de una plataforma de 
gestión de HCE 
Seguridad y protección de los datos contenidos en 
la historia clínica electrónica, a través de: 
 Confidencialidad 
 Integridad 
 Autenticación 
 Accountability 
 Disponibilidad 
 Autorización 
 No-repudio 
 Consentimiento 
 Interoperabilidad, lo cual permite compartir 
información de las HCE entre diferentes 
sistemas. 
 Responsabilidad de autor 
 Control de versiones 
 Acceso del paciente 
 Archivamiento y retención de datos 
Beneficios que ofrecería una 
plataforma informática para registrar y 
recuperar las HCE usando un 
repositorio centralizado 
 Ahorro de espacio de almacenamiento 
 Mejor legibilidad de la información 
 Acceso rápido y simultáneo a las HCE 
 Evita la redundancia de registros 
 Mayor facilidad y efectividad al administrar los 
registros médicos 
 Mayor experiencia a los médicos 
Existen muchos problemas asociados al registro de historias clínicas independientes, 
tales como: pérdida de registros, duplicidad de datos registrados en las instituciones, 
registros incompletos, etc. De estos problemas, se puede concluir que realmente es 
necesario plantear una solución, esta posibilidad de solución puede ser el registro de 
historias clínicas electrónicas.  
También, puede observarse que existen numerosos estándares de tecnología para 
el diseño de la arquitectura y el modelado de datos, esto debe ser realizado tomando 
en cuenta el marco legal y la estandarización adecuada para que todas las 
instituciones pueden compartir la información de las HCE.  
                                   
34 
 
La existencia de consideraciones previas o requisitos deben tomarse en cuenta en la 
implementación del repositorio centralizado para la gestión de historias clínicas. 
Finalmente, los beneficios que se lograrían con un repositorio centralizado para la 
gestión de HCE, se muestra que algunas razones por las cuales aún es bajo el 
porcentaje de implementación de sistemas que gestionen EHRs son: inversión inicial 
alta, costos de mantenimiento, privacidad y el logro de confianza de usuarios 
potenciales, la interoperabilidad, la migración de registros antiguos, y las barreras 
legales y organizacionales [6]. Estas razones deberán ser explicadas en base a la 
forma de implementación y los beneficios que ofrece las HCEs. 
  
                                   
35 
 
CAPÍTULO 4 
4.1 Diseño de la Arquitectura de Software de la Herramienta Informática 
En el presente capítulo, se desarrollará el primer objetivo específico del proyecto. Se 
trata del desarrollo y diseño de la arquitectura de software. Para esto, se debe definir 
los atributos de calidad que se requiere dicha arquitectura. Luego, elegir los patrones 
arquitectónicos que serán usados.  Finalmente, realizar el diseño propiamente de la 
arquitectura que dará soporte a todo la herramienta informática. 
4.1.1 Resultado esperado 1: Identificación y definición de los atributos de 
calidad requeridos en la arquitectura 
En la siguiente sección, se indicarán los atributos de calidad según la ISO/IEC 9126 
que serán requeridos para el desarrollo de la herramienta informática que permitirá 
el registro y recuperación de las HCE. Las definiciones de las sub-características de 
calidad dadas por la ISO/IEC 9126 se encuentran en el Anexo 2: Definición de 
Atributos de Calidad (ISO/IEC 9126). El estándar ISO/IEC 9126, establece las 
siguientes características para asegurar la calidad de un producto software: 
 Funcionalidad 
Para la solución informática que permitirá el registro y recuperación de las historias 
clínicas electrónicas, se debe tener en cuenta todas las sub-características de 
funcionalidad. Se requiere adecuación y exactitud en el tratamiento de datos e 
información de los registros médicos. Será necesario interoperabilidad, pues la 
solución es un componente web que deberá interactuar con los diferentes sistemas 
de las instituciones médicas. Además, se requiere seguridad de acceso para 
garantizar que solo personas autorizadas accedan a las funcionalidades del 
componente web. 
 Fiabilidad 
Para el desarrollo del servicio web que permite registrar y recuperar los registros 
médicos electrónicos, se debe considerar las sub-características de madurez y 
tolerancia a fallos, dado que el componente deberá validar los parámetros y casos 
que puedan resultar en fallos; y de presentarse una situación inesperada,  el 
componente deberá registrar la información del error para evitar que se vuelva a 
                                   
36 
 
producir. No se requerirá capacidad de recuperación, dado que para la solución 
planteada no se controlará los estados durante la entrada y salida de la información. 
 Usabilidad 
Para el proyecto de gestión de HCE, se requerirá solo la capacidad para ser operado. 
No serán necesarias las demás sub características de usabilidad por estar enfocadas 
hacia el usuario final, puesto que la alternativa de solución planteada es la 
implementación de un servicio web, el cual, por definición, no contempla interfaces 
gráficas para los usuarios. 
 Eficiencia 
Para la solución planteada se requerirá la sub-característica de comportamiento 
temporal para garantizar que el tiempo de respuesta del servicio web es el apropiado. 
Además, se requerirá la sub-característica de utilización de recursos para asegurar 
la utilización de los recursos necesarios y no exceder de ellos. 
 Mantenibilidad 
Para la alternativa de solución propuesta, se deben considerar todas las sub-
características de mantenibilidad, para esto el componente de software debe contar 
con documentos y comentarios para identificar rápidamente el comportamiento y 
ubicación de funcionalidades de tal forma que permita rastrear y/o implementar 
cambios necesarios. 
 Portabilidad 
Para la herramienta informática de registro y recuperación de las HCE, solo será 
necesario tener en cuenta la coexistencia, pues el componente no debe alterar el 
comportamiento de otros sistemas de los centros médicos que lo utilicen. No será 
necesario adaptabilidad, instalabilidad ni capacidad de ser reemplazado, pues el 
componente web no es un producto instalable. 
En la tabla 7, se muestra los atributos de calidad requeridos y los que no serán 
necesarios para la alternativa de solución al problema de gestión de las historias 
clínicas: 
 
 
                                   
37 
 
Tabla 7 - Características de calidad requeridas (Elaboración propia) 
 
4.1.2 Resultado esperado 2: Estudio de los estilos y patrones arquitectónicos, 
elección del patrón arquitectónico 
En esta sección, se describen los patrones de arquitectura y diseño que se utilizarán 
para la alternativa de solución planteada para el registro y recuperación de las HCE. 
4.1.2.1 Estilos arquitectónicos 
 Orientado a objetos 
Para el desarrollo del servicio web, se usará el paradigma orientado a objetos, 
logrando así una mejor organización de las clases, propiedades, funciones y métodos 
para facilitar el entendimiento.  
 Orientado a servicios 
Para la interacción del componente informático con los sistemas de las instituciones 
médicas, se usará el paradigma orientado a servicios, logrando así escalabilidad en 
el desarrollo de nuevas funcionalidades para el componente web. 
 Arquitectura en N-capas 
El estilo en n-capas se basa en una distribución jerárquica de los roles y las 
responsabilidades para proporcionar una división efectiva de los problemas a 
resolver. Los roles indican el tipo y la forma de la interacción con otras capas y las 
responsabilidades la funcionalidad que implementan [39]. Entre las principales 
ventajas se encuentran: desarrollos en paralelo, aplicaciones más robustas por el 
encapsulamiento, y mantenimiento y soporte más sencillo.  
CARACTERÍSTICA
SUBCARACTERÍSTICA
A
d
ec
u
ac
ió
n
Ex
ac
ti
tu
d
In
te
ro
p
er
ab
ili
d
ad
Se
gu
ri
d
ad
 d
e 
A
cc
es
o
C
u
m
p
lim
ie
n
to
 F
u
n
ci
o
n
al
M
ad
u
re
z
To
le
ra
n
ci
a 
a 
fa
llo
s
C
ap
ac
id
ad
 d
e 
re
cu
p
er
ac
ió
n
C
u
m
p
lim
ie
n
to
 d
e 
la
 f
ia
b
ili
d
ad
C
ap
ac
id
ad
 p
ar
a 
se
r 
en
te
n
d
id
o
C
ap
ac
id
ad
 p
ar
a 
se
r 
ap
re
n
d
id
o
C
ap
ac
id
ad
 p
ar
a 
se
r 
o
p
er
ad
o
C
ap
ac
id
ad
 d
e 
at
ra
cc
ió
n
C
u
m
p
lim
ie
n
to
 d
e 
la
 u
sa
b
ili
d
ad
C
o
m
p
o
rt
am
ie
n
to
 t
em
p
o
ra
l
U
ti
liz
ac
ió
n
 d
e 
re
cu
rs
o
s
C
u
m
p
lim
ie
n
to
 d
e 
la
 e
fi
ci
en
ci
a
C
ap
ac
id
ad
 p
ar
a 
se
r 
an
al
iz
ad
o
C
ap
ac
id
ad
 p
ar
a 
se
r 
ca
m
b
ia
d
o
Es
ta
b
ili
d
ad
C
ap
ac
id
ad
 p
ar
a 
se
r 
p
ro
b
ad
o
C
u
m
p
lim
ie
n
to
 d
e 
la
 m
an
te
n
ib
ili
d
ad
A
d
ap
ta
b
ili
d
ad
In
st
al
ab
ili
d
ad
C
o
ex
is
te
n
ci
a
C
ap
ac
id
ad
 p
ar
a 
se
r 
re
em
p
la
za
d
o
C
u
m
p
lim
ie
n
to
 d
e 
la
 p
o
rt
ab
ili
d
ad
REQUERIDO SI SI SI SI SI SI SI NO NO NO NO SI NO NO SI SI SI SI SI SI SI SI NO NO SI NO NO
Mantenibilidad PortabilidadFuncionalidad Fiabilidad Usabilidad Eficiencia
                                   
38 
 
4.1.2.2 Patrones de arquitectura 
 Patrón Repository 
Es un patrón relacionado con el acceso a datos que permite reducir líneas de código 
en la implementación de la comunicación entre la base de datos y las aplicaciones. 
En otras palabras, el repositorio actúa como un intermediario entre la base de datos 
y la capa de acceso a datos para que se centralice en un solo punto, y de esta forma 
se logre evitar redundancia de código. Al tratarse de una abstracción del acceso a 
datos permite testear de una forma más sencilla el código, realizando las pruebas 
unitarias con mayor facilidad  [29]. A continuación, se muestra la estructura del patrón 
Repository aplicada a la gestión de las HCE en un repositorio centralizado en la 
imagen 5. 
 
Imagen 5 - Estructura del patrón Repository (Adaptado de [38]) 
En la imagen 5 se puede observar como las instituciones médicas se comunican con 
el servicio web solicitando una operación (registro o recuperación) sobre las HCE. 
Cuando el web service recibe una solicitud, se ejecuta la lógica de negocio, y ésta a 
su vez se comunica con la capa de acceso a datos que trabaja con el patrón 
Repository. Este patrón mapea (obtiene datos y estructura) las entidades 
involucradas en la solicitud del centro médico, ya sea de registro o recuperación. 
Finalmente, la capa de acceso a datos se encarga de solicitar el registro y/o consulta 
de las HCE en el repositorio centralizado. 
Los estilos y patrones arquitectónicos mencionados en conjunto servirán para poder 
definir la arquitectura de la alternativa de solución planteada que permitirá el registro 
y recuperación de las historias clínicas electrónicas de manera centralizada.  
                                   
39 
 
4.1.3 Resultado esperado 3: Diseño de arquitectura propuesto para la 
herramienta 
Para la representación de la arquitectura de software se tomará como base el modelo 
“4+1”, el cual consiste en lo siguiente: Vista Lógica, Vista de Implementación, Vista 
de Proceso, Vista Física y Vista de Casos de Uso2. 
 Vista Lógica 
Esta vista describe las partes arquitectónicamente significativas del modelo de 
Diseño, puede descomponerse en capas, subsistemas o paquetes. Para el servicio 
web de gestión de las historias clínicas, la vista lógica se compone de 6 paquetes, 
los cuales pueden observarse en la imagen 6. 
.  
 
Imagen 6 - Vista Lógica (Elaboración Propia) 
La Vista Lógica muestra la relación que existe entre los 6 paquetes o capas de la 
solución, los cuales, en conjunto, contienen las clases, métodos, funciones, 
subprogramas, propiedades y utilitarios requeridos para implementar la el servicio 
web que permita la gestión de las HCE.  
                                                          
2 En esta sección, se muestra las 5 vistas de la arquitectura propuesta de manera general. Para mayor 
detalle de las mismas, ver el anexo 10: Análisis y Diseño de la Arquitectura y Propuesta. 
<<Host>>
<<Logica Negocio>>
<<Acceso Datos>>
<<Entidades>><<Utilitario>>
<<DTO>>
                                   
40 
 
 
 Vista de Implementación 
Esta vista describe la estructura general del Modelo de Implementación. Además, se 
muestra la relación o mapeo entre los componentes de implementación y las capas 
definidas en la Vista Lógica.   
Las capas de DTO, Utilitario y Entidades contienen 1 proyecto tipo librería de clases. 
La capa de Acceso a Datos y Lógica de Negocios contienen 2 proyectos tipo librería 
de clases, un proyecto que contiene los contratos o interfaces y el otro proyecto que 
contiene las clases donde las interfaces son implementadas. Esta estructura de 
manejar contratos e implementaciones es requerida para trabajar bajo el marco de 
WCF. Finalmente, la capa Host contiene un proyecto tipo Web, el cual será expuesto 
para que los sistemas externos puedan consumir el servicio. 
En la imagen 7, se muestra la vista de implementación para la gestión de las HCE. 
 
Imagen 7 - Vista de Implementación (Elaboración Propia) 
 Vista de Proceso 
La vista de procesos describe los procesos del sistema y cómo estos se comunican. 
También, se consideran requerimientos no funcionales: disponibilidad, desempeño y 
tolerancia a fallos. Para el problema identificado respecto a las historias clínicas, se 
<<Acceso Datos>>
<<Host>>
HCE.Host
<<Logica Negocio>>
HCE.LogicaNegocio.Contrato
HCE.LogicaNegocio.Implementacion
IRegistroHCELogic
IConsultaHCELogic
HCE.AccesoDatos.Implementacion
HCE.AccesoDatos.Contrato
IConsultaHCEData
IRegistroHCEData
<<Entidades>>
HCE.ModeloEntityFramework
<<Utilitario>>
HCE.FuncionesGenerales
<<DTO>>
HCE.DTO
                                   
41 
 
mostrará cómo se comunican los sistemas externos de las clínicas con el 
componente web a implementar.  
El diagrama de actividades mostrado en la imagen 8 representa esta vista para el 
caso de uso Registrar Historia Clínica. Se muestran los pasos a seguir y la interacción 
entre el actor (o usuario de los sistemas externos) y el servicio web para lograr la 
realización del caso de uso. Para los casos de uso Consultar Historia Clínica y 
Actualizar Historia Clínica, sus diagramas de actividades se encuentran en el Anexo 
3: Diagrama de Actividades. 
 
Imagen 8 - Diagrama Actividades: Registrar Historia Clínica (Elaboración 
propia) 
Médico Servicio Web HCE
Solicita consumir servicio web
mediante autenticación
Valida permisos de autenticación
Retorna mensaje de error
de autenticación
NO
es conforme?
Solicita acción a realizar
SI
Solicita registro de HCE
Envía información de formatos
a registrar
Valida datos recibidos
datos correctos?
Retorna mensaje de
error en datos de
registro de HCE
Registra HCE en
repositorio centralizado
NO
SI
Retorna mensaje de
registro satisfactorio
Visualiza respuesta de servicio
Visualiza mensaje de error
                                   
42 
 
 Vista Física 
La vista física muestra los equipos físicos que se requieren para instalar el servicio 
web y poder probar su funcionamiento. Esta vista toma en cuenta requerimientos no-
funcionales como: tolerancia a fallos, escalabilidad, desempeño, entre otros. El 
diagrama de despliegue mostrado en la imagen 9 representa la vista física de la 
alternativa de solución planteada para el registro y recuperación de las historias 
clínicas electrónicas. 
 
Imagen 9 - Vista Física (Elaboración Propia) 
 Vista de Casos de Uso 
La vista de casos de uso consolida las vistas anteriores, donde los escenarios se 
convierten en una abstracción de los requerimientos más importantes. A 
continuación, la imagen 10 muestra el diagrama de casos de uso que refleja esta 
vista: 
<<Servidor Web>>
<<Equilibrador>>
Servidor de Base de Datos
BDHCE
Servidor de Base de Datos Mirror
HCDBD_Mirror
<<PC>>
<<Movil>>
<<Host>>
<<Logica Negocio>>
<<Acceso Datos>>
<<Entidades>>
<<Utilitario>>
<<DTO>>
                                   
43 
 
 
Imagen 10 - Vista Casos de Uso (Elaboración Propia) 
  
Usuario Consulta
Médico
Enfermero
Paciente
Consultar Historia Clínica
Registrar Historia Clínica
Actualizar Historia Clínica
                                   
44 
 
CAPÍTULO 5 
5.1 Elección de los mecanismos para asegurar la privacidad y 
autenticación de los datos de las historias clínicas electrónicas 
En el presente capítulo se describirán las alternativas con las que se cuenta para 
lograr la privacidad de los datos de las historias clínicas por contener información 
muy sensible. Además, se detallarán los mecanismos de firma digital que permitirán 
identificar el médico que registra y/o actualiza información de alguna HCE de un 
paciente, y garantizar el no repudio. 
5.1.1 Resultado Esperado 1: Descripción y elección de los mecanismos para 
asegurar la privacidad y autenticación de los datos de las historias clínicas 
electrónicas 
Mecanismos para asegurar la privacidad de los datos 
Para garantizar la privacidad de los datos de los pacientes en los registros médicos 
electrónicos, existen diferentes métodos o técnicas, entre los cuales destacan: 
encriptación, anonimización y pseudonimización. Sin embargo, los dos primeros 
métodos presentan grandes desventajas [37]. La definición de estos mecanismos se 
encuentran en el anexo 9: Definición de mecanismos de seguridad. 
Se decidió utilizar la técnica de pseudonimización sobre los datos de identificación 
del paciente para hacer frente a posibles ataques sobre la base de datos. De esta 
manera, si una persona no autorizada logra acceder a la base de datos centralizada, 
podrá ver información de parte de las historias clínicas, pero no podrá identificar a 
los pacientes, pues sus datos de identificación personal se encuentran 
pseudonimizados. 
 
Mecanismos para asegurar la veracidad e integridad de los datos 
Los registros médicos electrónicos brindan la posibilidad de ser firmados 
electrónicamente. Algunos conceptos relacionados a la firma electrónica son: 
autenticación y atestación. Autenticación es el proceso de seguridad que verifica la 
identidad de un usuario, este proceso permite autorizar al usuario el acceso al 
sistema. Por otro lado, atestación es el acto de aplicar una firma electrónica al 
contenido, mostrando el autor y responsable legal de una unidad particular de 
                                   
45 
 
información. Cabe resaltar que tanto las firmas analógicas y las firmas electrónicas 
sirven para los siguientes propósitos: intención, identidad e integridad [40]. 
Para asegurar la integridad de la información de las HCE, se tomaron en cuenta los 
mecanismos de firma electrónica definidos en el anexo 9: Definición de Mecanismos 
de Seguridad.  
Para el presente proyecto de registro y recuperación de HCEs, donde una trama que 
contiene información de los formatos médicos de un paciente viaja a través de 
Internet desde un origen (Servicio Web / Institución Médica) a su destino (Institución 
Médica / Servicio Web). Durante este trayecto podría ser interceptado y podría ser 
alterado, frente a esto, se decide utilizar firma digital con cifrado simétrico y 
asimétrico. De esta manera, la trama que viaje estará cifrada bajo las llaves pública 
y privada, estas llaves son únicamente conocidas por los médicos y el componente 
web. Cuando la trama llegue a su destino, será descifrada utilizando estas mismas 
llaves.     
La imagen 11 muestra la forma de enviar un mensaje entre dos usuarios usando 
cifrado asimétrico y cifrado simétrico. 
 
Imagen 11 – Criptografía Simétrica y Asimétrica (Adaptado de [47]) 
Mecanismos para el control de accesos 
Con relación al control de acceso de los dispositivos que harán uso del servicio web, 
se plantean los siguientes mecanismos: 
 
                                   
46 
 
Seguridad de servicio web mediante certificados 
El utilizar certificados de seguridad en el Web Service permite garantizar que solo las 
instituciones médicas que cuenten con un certificado autorizado (provisto por el 
dueño del componente web) puedan registrar y obtener información desde el 
repositorio centralizado. Es importante mencionar que el uso de certificados no está 
considerado en el proyecto, por el costo que implica la utilización de los mismos. 
IIS - Restricción de acceso mediante IP 
Este mecanismo permitirá autorizar el acceso al componente web solo a 
determinados equipos o PCs de las instituciones médicas, estas deberán definir 
cuáles son las PCs o subredes que tendrán acceso. 
Tokens 
El uso de tokens permitirá saber desde qué equipo o terminal de los centros médicos 
se está accediendo al servicio web. Además, se podrá obtener información sobre qué 
operaciones (métodos invocados, cantidad de operaciones al día, frecuencia de uso) 
se realizan desde una terminal.  
Cabe mencionar que los tres mecanismos de control de acceso mencionados aplican 
cuando los terminales son PCs o laptops. Si se trata de terminales que incluyen 
dispositivos móviles, solo se podría aplicar el tercer mecanismo: Tokens. 
  
                                   
47 
 
CAPÍTULO 6 
6.1 Desarrollo del componente para el registro y recuperación de las 
historias clínicas electrónicas 
6.1.1 Resultado esperado 1: Componente para el registro de HCE 
implementado 
En la presente sección, se describirá el proceso de implementación del componente 
web que permitirá el registro de las HCE usando un repositorio centralizado. Además, 
se presentarán las pruebas realizadas entre el componente web y la simulación de 
un sistema externo. 
En primer lugar para el desarrollo del servicio web, se crea la base de datos en SQL 
Server con tablas, índices, llaves primarias y foráneas en base al Modelo Entidad-
Relación elaborado. El nombre de la base de datos creada es BDHistoriaClinica. 
A continuación, se explicará la implementación realizada en cada una de las capas 
definidas previamente en el diseño de arquitectura: 
Entidades 
Esta capa contiene un ORM (Object Relation Mapping) EntityFramework, dentro del 
cual se encuentran mapeadas las tablas y objetos de la base de datos 
BDHistoriaClinica. Esta capa se relaciona con las capas de acceso a datos y lógica 
de negocio. 
 
Imagen 12 – Modelo de Base de Datos – Entity Framework 
                                   
48 
 
La imagen 12 muestra el Modelo de Base de Datos generado por EntityFramework 
tomando como base el script de base datos en SQL Server.  
Acceso a Datos 
Esta capa contiene las clases donde son implementadas las operaciones CRUD 
(Create, Read, Update and Delete) de las tablas de la base de datos creada. Para 
ello, se utiliza las entidades mapeadas en la capa Entidades. Esta capa se encuentra 
dividida en 2 proyectos: un proyecto que maneja las interfaces o contratos y otro 
proyecto donde se implementan dichas interfaces. Cabe mencionar que para agilizar 
el desarrollo de implementación de las operaciones CRUD, se utilizó los patrones de 
arquitectura Repository. 
Las imágenes 13 y 14, muestran el código de la interface o contrato, y su 
implementación para la entidad HCE_Paciente. 
 
Imagen 13 – Interface de la entidad HCE_Paciente 
 
Imagen 14 – Implementación de la interface de la entidad HCE_Paciente 
                                   
49 
 
La tabla 8 muestra la relación entre los formatos considerados en el proyecto y las 
tablas que requiere del diagrama de clases definido. Para cada formato, se muestra 
las secciones que contiene y las clases que soportan dicha estructura. 
DTO 
Esta capa contiene las clases, las cuales han sido divididas según los formatos que 
serán cubiertos en la solución: Formato de Atención Integral (Niño, Adolescente, 
Adulto y Adulto Mayor), Formato de Emergencia, Formato de Hospitalización y 
Formato de Consulta Externa. Estas clases serán utilizadas por los sistemas externos 
para que puedan enviar los datos que serán registrados en el repositorio centralizado; 
asimismo, estas clases sirven de respuesta para las solicitudes de consulta de los 
sistemas externos. 
En la siguiente imagen 15, se muestra una parte del código definido para el Formato 
de Atención Integral. 
 
Imagen 15 – DTO – Formato de Atención Integral 
Tabla 8 – Relación entre los Formatos de Atención Médica y las Clases del Sistema
 
Li
st
a 
d
e 
P
ro
b
le
m
as
P
la
n
 d
e 
A
te
n
ci
ó
n
 In
te
gr
al
D
at
o
s 
G
en
er
al
es
A
n
te
ce
d
en
te
s 
P
er
so
n
al
es
Es
q
u
em
a 
d
e 
V
ac
u
n
ac
ió
n
V
ig
ila
n
ci
a 
d
el
 C
re
ci
m
ie
n
to
 y
 
D
es
ar
ro
llo
C
o
n
su
lt
a 
- 
Tr
ia
je
 (
Si
gn
o
s 
V
it
al
es
)
C
o
n
su
lt
a 
- 
Tr
ia
je
 (
Si
gn
o
s 
d
e 
P
el
ig
ro
)
A
n
am
n
es
is
A
lim
en
ta
ci
ó
n
Ex
am
en
 B
u
ca
l
D
ia
gn
ó
st
ic
o
Tr
at
am
ie
n
to
C
o
n
su
lt
a
Li
st
a 
d
e 
P
ro
b
le
m
as
P
la
n
 d
e 
A
te
n
ci
ó
n
 In
te
gr
al
D
at
o
s 
G
en
er
al
es
A
n
te
ce
d
en
te
s 
P
er
so
n
al
es
A
n
te
ce
d
en
te
s 
Fa
m
ili
ar
es
A
n
te
ce
d
en
te
s 
P
si
co
So
ci
aa
le
s
Sa
lu
d
 S
ex
u
al
 y
 R
ep
ro
d
u
ct
iv
a
C
u
id
ad
o
s 
P
re
ve
n
ti
vo
s 
- 
Se
gu
im
ie
n
to
 
d
e 
R
ie
sg
o
C
o
n
su
lt
a
D
at
o
s 
G
en
er
al
es
A
n
te
ce
d
en
te
s
R
ea
cc
ió
n
 A
lé
rg
ic
a 
a 
M
ed
ic
am
en
to
s
Se
xu
al
id
ad
D
at
o
s 
M
u
je
r 
(m
en
ar
q
u
ía
, g
es
ta
ci
ó
n
, 
et
c)
C
u
id
ad
o
s 
P
re
ve
n
ti
vo
s 
- 
Se
gu
im
ie
n
to
 
d
e 
R
ie
sg
o
C
o
n
su
lt
a
Li
st
a 
d
e 
P
ro
b
le
m
as
P
la
n
 d
e 
A
te
n
ci
ó
n
 In
te
gr
al
D
at
o
s 
G
en
er
al
es
A
n
te
ce
d
en
te
s
R
ea
cc
ió
n
 A
d
ve
rs
a 
a 
M
ed
ic
am
en
to
s
V
al
o
ra
ci
ó
n
 C
lín
ic
a 
A
d
u
lt
o
 M
ay
o
r 
(V
A
C
A
M
)
C
u
id
ad
o
s 
P
re
ve
n
ti
vo
s 
- 
Se
gu
im
ie
n
to
 
d
e 
R
ie
sg
o
C
o
n
su
lt
a
D
ia
gn
ó
st
ic
o
s
C
at
eg
o
rí
as
 d
el
 a
d
u
lt
o
 m
ay
o
r
Paciente X X X X
TipoPaciente X X X X
ProblemaCronico X X X
ProblemaAgudo X X X
PlanAtencionIntegral X X X
DetPlanAtencionIntegral X X X
Antecedentes X X X X X X X
DetAntecedente X X X X X X X
Categoria
NNVigCrecimientoDes X
DetVigCrecimientoDes X
TipoVacuna X X
TipoDosis X X
DetTipDosis X X
ReaccionMedicamento X X
NNSignosVitales X
DetSignoPeligro X
NNSignoPeligro X
CuidadoPreventivo X X X
ClasificacionCuidPrev X X X
DetCuidadoPreventivo X X X
Consulta X X X X X X X X
ExamenBucal X
DetExaBucal X
SeleccionConsulta X X X X
DetSeleccionConsulta X X X X
ExamenAuxiliar
CategoriaAdultoMayor X
AMConsultaAdicional X
DatosMujer X
DetDatosMujer X
Valoracion X X
CategoriaValoracion X X
DetValoracion
ConsultaExterna X
Emergencia X
Hospitalizacion X
FichaFamiliar X
VisitaDomiciliaria X
MiembroFamilia X
Fo
rm
at
o
 F
ic
h
a 
Fa
m
ili
ar
Fo
rm
at
o
 d
e
 A
te
n
ci
ó
n
 e
n
 E
m
e
rg
e
n
ci
a
Fo
rm
at
o
 d
e
 H
o
sp
it
al
iz
ac
ió
n
Formato de atención integral del niño Formato de atención integral del adolescente
Formato de atención integral del 
adulto Formato de atención integral del adulto mayor
Fo
rm
at
o
 d
e
 C
o
n
su
lt
a 
Ex
te
rn
a
Lógica de Negocio 
Esta capa contiene clases donde se implementan las reglas, validaciones, registro, 
actualización y recuperación de los formatos que abarca la solución. Esta capa se 
comunica con las capa Entidades y DTO. Para realizar el registro de los formatos, se 
requiere mapear la información obtenida en los DTO hacia las entidades del ORM. 
De manera similar a la capa de Acceso a Datos, esta capa se divide en 2 proyectos: 
un proyecto que maneja interfaces o contratos y otro proyecto donde son 
implementadas dichas interfaces. 
Las imágenes 16 y 17 muestran la interface o contrato del formato de atención 
integral y parte de la implementación del formato de Atención Integral. 
 
Imagen 16 – Interface o Contrato del Formato de Atención Integral 
 
 
Imagen 17 – Parte de  la implementación de las Interfaces o Contratos 
definidos 
                                   
52 
 
Adicionalmente, para poder realizar las pruebas del servicio web para el registro de 
una HCE. Se creó un proyecto web que simula un sistema externo de una institución 
médica que consumirá el componente web implementado. En la imagen 18 y 19, se 
muestran las interfaces gráficas básicas que contiene los datos solicitados en el 
Formato de Atención Integral del Niño y el Formato de Emergencia. También, se 
puede observar que luego de completar todos los datos del Formato de Atención 
Integral y hacer click en el botón Grabar Formato Integral, el servicio web muestra un 
mensaje de respuesta. En la imagen mostrada, se observa el mensaje de éxito, es 
decir, se registró satisfactoriamente el formato. 
 
 
 
                                   
53 
 
 
 
 
Imagen 18 – Entorno de prueba o Simulador de sistema externo para el 
registro del Formato de Atención Integral 
 
 
                                   
54 
 
 
 
 
Imagen 19 – Entorno de prueba o Simulador de sistema externo para el 
registro del Formato de Emergencia 
Finalmente, con la implementación realizada, el flujo que debe seguirse para el 
registro de una historia clínica electrónica se muestra en la imagen 20. 
 
Imagen 20 – Flujo del Proceso para el Registro de una HCE 
                                   
55 
 
En la imagen se muestra cómo el médico envía de manera cifrada (con las llaves de 
firma digital) el formato que desea registrar. El formato es recibido por el servicio web 
y es descifrado para poder almacenarlo en la base de datos. 
6.1.2 Resultado esperado 2: Componente para la recuperación de HCE 
implementado 
Para la recuperación de una HCE, es similar a lo que se ha descrito para el registro 
de una HCE.  La principal diferencia se muestra en la capa de Lógica de Negocio, 
pues en la implementación, el método para la recuperación devuelve un DTO cifrado 
con una llave simétrica (a diferencia del registro donde solo se retorna un mensaje). 
La imagen 21 muestra la implementación del método que permitirá la recuperación 
del formato de Atención Integral. 
 
Imagen 21 – Implementación del método para la recuperación de Formato de 
Atención Integral 
De igual manera que el registro de Formato de Atención Integral, se utilizó un 
proyecto web con una interfaz similar que permite ingresar el DNI del paciente del 
cual se desea conocer su formato de Atención Integral. El servicio valida el DNI 
ingresado y retorna los datos solicitados, en caso exista. 
La imagen 22 muestra la interfaz de recuperación del Formato de Atención Integral. 
                                   
56 
 
 
Imagen 22 – Entorno de Prueba para la recuperación de HCE 
Además de la interfaz de prueba, se realizaron las pruebas unitarias de los métodos 
que serán publicados en el servicio web implementado para el registro y recuperación 
de las HCE.
 
Imagen 23 – Implementación de prueba unitaria 
RegistrarFormatoIntegralTEST (Método RegistrarFormatoIntegral) 
                                   
57 
 
En la imagen 23, se muestra la prueba unitaria para el método 
RegistrarFormatoIntegralLogic. Esta prueba da un resultado exitoso cuando el 
resultado guardado en la variable result devuelve un mensaje de éxito al invocar al 
método RegistrarFormatoIntegral(mensajeDTO, llave, idMedico, Formato.ninio). 
Implementación de Firma Digital 
Para la implementación de firma digital se utilizó el cifrado simétrico y asimétrico. 
En primer lugar, se debe realizar el registro del médico para que el componente web 
genere las llaves simétrica (texto formado mediante información del médico) y 
asimétrica (llave pública y privada generada utilizando la librería RSAProvider). 
La imagen 24 muestra mediante un diagrama el comportamiento entre los sistemas 
externos y el componente web para la generación de las llaves con cifrado simétrico 
y asimétrico. 
 
Imagen 24 – Diagrama Generación de llaves al registrar un médico  
En la imagen 24, se puede observar que el paso “Valida información del médico” es 
un subproceso, pues consiste en más de una actividad. El diagrama de dicho 
subproceso se muestra en el imagen 25. 
 
Imagen 25 – Diagrama del subproceso “Valida información del médico” 
                                   
58 
 
Para el registro de un formato médico, el sistema externo debe cargar el DTO del 
formato que desea registrar. Luego, el sistema externo invoca a un método del 
componente web que le permite cifrar el DTO mediante la llave simétrica del médico 
que realizará el registro. Una vez que se obtiene el mensaje cifrado (DTO cifrado), 
se invoca al método de registro que solicita los siguientes parámetros: mensaje 
cifrado, llave público del médico y el id del médico. El componente web deserializa la 
llave simétrica mediante las llaves pública y privada. Luego, descifra el mensaje con 
la llave desencriptada (obtiene DTO en formato XML). Finalmente, deserializa el XML 
a formato DTO para realizar el registro.  
En la imagen 26, se muestra la interacción entre el sistema externo y el servicio web 
para realizar el registro de un formato médico. Además, se muestra que el paso 
“Registra formato HCE” es un subproceso, dado que consiste en más de una 
actividad. La imagen 27 muestra los pasos realizados en dicho subproceso. 
Por otro lado, para realizar la recuperación de un formato médico, el sistema externo 
enviará el DNI del paciente e invoca al método de consulta. El componente web 
busca en el repositorio información del formato médico en base al DNI recibido. Si 
existe la información solicitada, el servicio web serializa el DTO (a XML), y luego, lo 
cifra con la llave simétrica (del servicio web). Este mensaje cifrado es el que envía al 
sistema externo. El sistema externo recibe el mensaje cifrado e invocará el método 
para convertir el mensaje cifrado a DTO. 
El diagrama que muestra el comportamiento entre el sistema externo y el 
componente web para recuperar un formato médico se muestra en la imagen 28. 
 
 Imagen 26 – Diagrama registro de formato médico con firma digital 
 
Imagen 27 – Diagrama del subproceso “Registra formato HCE”
 Imagen 28 – Diagrama consulta/recuperación de formato médico con firma digital
Implementación del mecanismo para asegurar la privacidad de los datos 
El mecanismo a utilizar para garantizar la privacidad de los datos contenidos en las 
historias clínicas de los pacientes es la pseudonimización. En otras palabras, los datos 
de identificación personal de una persona serán guardados como pseudónimos o 
encriptados en la base de datos, esto asegura que no sea posible identificar a un 
paciente cuando personas no autorizadas accedan a la base de datos. Se debe realizar 
de esta manera dado que la información contenida en los formatos médicos es 
información sensible y que deben cumplir la regulación vigente. 
Para el servicio web implementado los datos de identificación personal que serán 
guardados de manera encriptada son los siguientes: Nombre, apellidos, DNI, número 
de historia clínica, número de teléfono, dirección y localidad. El tipo de datos de dichos 
campos en la base de datos deberán ser del tipo varcharmax para soportar la cantidad 
de caracteres de los campos encriptados. 
En la imagen 29, se muestra los datos que están siendo encriptados usando la llave 
simétrica del componente web.  
 
Imagen 29 – Registro de datos personales del paciente cifrados 
Asimismo, cuando los sistemas externos deseen obtener los datos de un formato 
médico. Los datos personales del paciente deberán ser desencriptados para que 
puedan ser entendidos por el médico que está realizando la consulta.  
                                   
62 
 
 
Imagen 30 – Obtención de datos personales del paciente descifrados 
En la imagen 30, se muestra los datos del paciente que son desencriptados al invocar 
al método ObtenerFormatoIntegral. 
 
Cabe mencionar que el flujo ideal a seguir para la recuperación de una historia clínica 
se muestra en la siguiente imagen 31. Este flujo refleja que es necesario el 
consentimiento del paciente para que un médico pueda acceder a su información. 
 
Imagen 31 – Flujo ideal para la recuperación de una HCE 
Este flujo es denominado “ideal”, pues en el presente proyecto no se está considerando 
el primer paso (consentimiento del paciente), pues aún no se encuentra implementado 
                                   
63 
 
el DNI electrónico que permitiría validar que el paciente apruebe el acceso a su 
información. Por esta razón el flujo para la recuperación de un formato médico, se está 
siguiendo los pasos mostrados en la imagen 32. 
 
 
Imagen 32 – Flujo para la recuperación de una HCE 
Se puede observar que en el flujo descrito en la imagen 32 no interviene el paciente, 
sino que es solo el médico quien hace la solicitud al servicio web para poder obtener 
información acerca de un paciente. 
Para resumir el presente capítulo, la implementación de los componentes de registro y 
recuperación de HCEs ofrece una alternativa de solución a la situación descrita en la 
problemática donde se muestra a las instituciones y centros médicos registrando las 
historias clínicas de manera física o digital, pero de manera desintegrada, lo cual 
imposibilita el acceso a las historias clínicas completas de los pacientes. El resultado de 
esto es el logro de la integración de las HCEs en un único repositorio centralizado, el 
cual permite el registro y recuperación de las mismas, esto puede resumirse en la 
imagen 33. 
                                   
64 
 
 
Imagen 33 – Interacción entre las instituciones médicas y el servicio 
implementado (Elaboración Propia) 
En la imagen 33 se puede observar como las instituciones médicas solicitan al servicio 
web peticiones de registro y recuperación de historias clínicas. El Web Service  al recibir 
las peticiones, accede al único repositorio centralizado para poder atender las 
operaciones solicitadas, en otras palabras, se encarga de acceder al repositorio para 
registrar los formatos médicos enviados y/o recuperar los registros solicitados por los 
centros médicos. De esta forma, se trabajaría de manera integrada y se tendría todas 
las historias clínicas electrónicas en un mismo repositorio. 
  
                                   
65 
 
CAPÍTULO 7 
En el presente capítulo se detallan las conclusiones que se obtienen después de haber 
completado los resultados esperados en base a los objetivos definidos para la 
implementación de un servicio web que permita el registro y recuperación de las 
historias clínicas electrónicas a partir de un repositorio centralizado. Asimismo, se 
describen las recomendaciones y trabajos futuros asociados al proyecto de fin de 
carrera con el propósito de mejorar la alternativa de solución desarrollada y/o plantear 
otras alternativas que permitan solucionar el problema de falta de un repositorio 
centralizado para el manejo de las HCE. 
7.1 Conclusiones 
Después de haber descrito la forma en que se realizó el diseño de la arquitectura, la 
elección de los mecanismos de seguridad a utilizar y la implementación del servicio web 
para el registro y recuperación de las HCEs, se puede concluir que se han logrado los 
resultados esperados propuestos para el presente proyecto, con lo cual se puede 
afirmar que se han logrado los objetivos específicos, y, por ende, el objetivo general que 
es la implementación de un componente web que permita registrar y recuperar las 
historias clínicas a partir de un repositorio centralizado. 
Durante el análisis del tema en estudio, se observó que existen problemas actuales en 
las diferentes instituciones médicas por el registro en físico de las historias clínicas como 
ilegibilidad, pérdida, deterioro de los registros, dificultad de acceso a los mismos, y falta 
de monitoreo y supervisión a las historias clínicas completas de los pacientes. Se 
determinó que la mejor alternativa de solución sería implementar una arquitectura 
orientada a servicios que permita la comunicación entre las diferentes instituciones 
médicas a través de un único repositorio centralizado.  
En la elección de los mecanismos de seguridad, se optó por utilizar pseudonimización 
para lograr la privacidad de los datos de identificación del paciente. Esto se debe a que 
en el estudio del marco legal se observó la importancia de proteger la información 
personal, lo cual se evidencia en la Ley de Protección de Datos Personales. Asimismo, 
se decidió utilizar firma digital con cifrado simétrico y asimétrico para garantizar la 
integridad y veracidad de la información que se almacena en el repositorio centralizado. 
Adicionalmente, se han propuesto métodos para el control de accesos que podrían 
aplicarse de forma conjunta. El aplicar estos mecanismos permite evitar que los datos 
de la historia clínica de un paciente sean identificados al acceder de manera no 
                                   
66 
 
autorizada al repositorio, y lograr que la trama viaje desde el sistema del centro médico 
al servicio Web y viceversa de manera cifrada.  
Se ha implementado el componente para el registro y recuperación de HCEs, y se han 
descrito los procesos involucrados (el registro de un médico y la generación de las llaves 
de seguridad para permitirle acceder a las funcionalidades ofrecidas por el Web Service, 
el registro de un paciente, el registro de un formato médico y la recuperación del mismo). 
El servicio web implementado contempla los formatos médicos más relevantes 
(Formatos de Atención Integral, Formato de Emergencia, Formato de Consulta Externa, 
Formato de Hospitalización y Ficha Familiar), y garantizando la seguridad de la 
información con respecto a la privacidad e integridad de los datos.  El componente web 
que contempla registro y recuperación podrá ser utilizado por cualquier institución 
médica a la que se le brinde acceso, y de esta manera optimizar el proceso de registro 
y recuperación de las historias clínicas electrónicas. 
Los principales beneficios obtenidos gracias a la alternativa de solución planteada 
permiten reemplazar el registro en físico de las historias, y por ende, evita la duplicidad, 
pérdida y deterioro de los registros. Asimismo, se permite el acceso y supervisión total 
de las HCEs desde cualquier institución médica, lo cual beneficia a los médicos y a los 
pacientes, dado a que no requieren ser registrados en cada institución médica. 
Adicionalmente, se logrará el aseguramiento de la integridad y privacidad de la 
información contenida en el repositorio, y el logro de la estandarización de los formatos 
médicos en base a la Resolución Ministerial N°776-2004. 
7.2 Recomendaciones 
Debido a la gran cantidad de mecanismos que aseguren la privacidad y autenticación 
de datos, se utilizó el cifrado simétrico y asimétrico para la implementación de firma 
digital. Además, se empleó pseudonimización  para  mantener la privacidad de los datos. 
Del mismo modo, para garantizar la interoperabilidad entre los diferentes centros 
médicos, se sugiere utilizar el estándar internacional Health Level Seven (HL7).  
Por otro lado, es importante mencionar que si surgen cambios en los formatos médicos 
a causa de variaciones en las normas legales y/o resoluciones, deberá actualizarse el 
modelo de datos para que pueda soportar las nuevas estructuras que sean definidas. 
Se debe realizar una migración desde las distintas fuentes de datos de los centros 
médicos hacia el repositorio centralizado de las HCEs. Se sugiere realizar una 
                                   
67 
 
depuración de datos durante la migración con el fin de evitar duplicidad e inconsistencia 
de la información.  
Además, se recomienda realizar un piloto con algunos centros médicos con el propósito 
de conocer cuál será el impacto al momento de poner en marcha el componente web 
implementado en el presente proyecto. 
7.3 Trabajos Futuros 
La existencia de diversos formatos médicos definidos por las leyes promulgadas por el 
Ministerio de Salud en el Perú conlleva a la elección de 5 formatos para el desarrollo del 
proyecto de fin de carrera. Los formatos contemplados en el alcance del proyecto son 
los siguientes: Formato de Atención Integral (del Niño, del Adolescente, del Adulto y del 
Adulto Mayor), Formato de Emergencia, Formato de Consulta Externa, Formato de 
Hospitalización y Ficha Familiar. Cabe mencionar que los formatos de atención integral 
aun cuando tengan las mismas secciones, la información y datos contenidos en cada 
una de estas son diferentes según la edad del paciente. 
En un futuro deberían ser considerados los formatos que no han sido cubiertos en el 
presente proyecto de fin de carrera. Algunos posibles formatos a ser tomados en cuenta 
son: Formato de Examen Clínico, Formato de Tratamiento Medicamentoso, Plan de 
Trabajo, Formato de Epicrisis, Formato de Intervención Quirúrgica, Informe de Alta, 
Formato de Anestesia, Notas de Enfermería, Hoja de Enfermería, Formato de 
Interconsulta, entre otros.  
Asimismo, dado que el proceso para la utilización del DNI electrónico está en proceso 
de implementación, cuando se encuentre habilitado, debería ser añadido en el presente 
proyecto para considerar la intervención del paciente en el flujo de recuperación de HCE, 
pues el paciente debe aceptar explícitamente que autoriza el acceso a su información. 
Además, se podrá implementar un proyecto de Inteligencia de negocios con el fin de 
explotar los datos de los pacientes y la información contenida en los formatos médicos 
para determinar indicadores de valor que pueden influir en la mejora de la calidad del 
servicio de cada centro médico, y favorecer a realizar una mejor gestión en la toma de 
decisiones.  
                                   
68 
 
Referencias bibliográficas 
 
[1] Ley 
MINSA 
2013. Ley N° 30024: “Ley que crea el registro nacional de historias clínicas electrónicas”. 
13 de Noviembre del 2013. 
 
[2] M. MENDOZA. “Lolimsa: Solo el 11%% de las historias clínicas son virtuales”. 
http://elcomercio.pe/economia/negocios/lolimsa-solo-11-historias-clinicas-son-virtuales-
noticia-1732352. Noticia Diario El Comercio online [Página Web; acceso 15-setiembre-
2014] 
 
[3] J. VILLENA. “Historias clínicas permitirán atención en cualquier parte del Perú”. 
http://www.rpp.com.pe/2013-06-05-historias-electronicas-permitiran-atencion-en-
cualquier-parte-del-peru-noticia_601633.html. Noticia RPP Noticias online [Página Web; 
acceso 15-setiembre-2014] 
 
[4] M. Van Der Haak; A.C. Wolff, R. Brandner, P. Drings, M. Wannenmacher, TH. Wetter, 
“Data security and protection in cross-institutional electronic patient records”. 
International Journal of Medical Informatics. Vol. 70, Pág. 117-130, 2003. 
 
 [5] W. Curioso, J. Saldías, R. Zambrano. “Historias clínicas electrónicas. Experiencia 
en un hospital nacional. Satisfacción por parte del personal de salud y pacientes”. 
Revista de la Sociedad Peruana de Medicina Interna. Vol. 15, 2002. 
http://sisbib.unmsm.edu.pe/bvrevistas/spmi/v15n1/histo_clini.htm.  
 
[6] S. V. B. Jardim, “The electronic health record and its contribution to healthcare 
information systems interoperability”. Procedia Technology. Vol. 9, pág. 940-948, 2013. 
 
[7] AOA Health Information Technology and Telemedicine Committee. Moving toward 
the paperless practice. “Glossary of health information technology terminology”. 
  
[8] H. Van Der Linden, D. Kalra, A. Hasman, J. Talmon, “Inter-organizational future proof 
EHR systems. A review of the security and privacy related issues”. International Journal 
of Medical Informatics. Vol. 78, Pág. 141-160, 2009. 
                                   
69 
 
 
[9] C. Martínez, M. Menárguez, J. Fernández, “A model-driven approach for representing 
clinical archetypes for Semantic Web environments”. Journal of Biomedical Informatics. 
Vol. 42, pág. 150-164, 2009. 
 
[10] B. Blobel, “Advanced and secure architectural EHR approaches”. International 
Journal of Medical Informatics. Vol. 75, Pág. 185-190, 2006. 
 
 [11] J. Riesmeier, A. Dogac, “A Survey and Analysis of Electronic Healthcare Record 
Standards”. ACM Computing Surveys. Vol. 37, pp. 277-315, 2005. 
 
[12] Ley 
Congreso de la República 
2000. Ley N° 27269: “Ley de Firmas y Certificados Digitales”. 8 de Mayo del 2000. 
 
[13] RM 
MINSA 
2004. RM 776-2004: “Norma Técnica de la Historia Clínica de los Establecimientos de 
Salud del Sector Público y Privado”. 27 de Julio del 2004 
 
[14] RM 
MINSA 
2006. RM 597-2006: “Norma Técnica de Salud para la Gestión de la Historia Clínica”. 
28 de Junio del 2006 
 
[15] RM 
MINSA 
2008. RM 686-2008: “Norma Técnica de Salud para la Gestión de la Historia Clínica, 
Epicrisis, Informe de Alta y Consentimiento Informado”. 2 de Octubre del 2008 
 
[16] RM 
MINSA 
2008. RM 732-2008: “Norma Técnica de Salud para la Gestión de la Historia Clínica”. 
10 de Octubre del 2008 
 
 
                                   
70 
 
[17] RM 
MINSA 
2011. RM 466-2011: “Prepublicación del proyecto de Directiva Administrativa que 
aprueban las especificaciones para la estandarización del registro en la Historia Clínica 
Electrónica”. 14 de Junio del 2011 
 
[18] RM 
MINSA 
2011. RM 576-2011: “Directiva Administrativa que establece las especificaciones para 
la estandarización del registro en la historia clínica electrónica”. 22 de Julio del 2011 
 
[19] RM 
MINSA 
2013. RM 726-2013: “Prepublicación del proyecto de la Ley número 30024, Ley que crea 
el Registro Nacional de Historias Clínicas Electrónicas”. 7 de Junio del 2013 
 
[20] Ley 
Congreso de la República 
2011. Ley N° 29733: “Ley de Protección de Datos Personales”. 2 de Julio del 2011 
 
[21] Ley 
Congreso de la República 
2000. Ley N° 27269: “Ley de Firmas y Certificados Digitales”. 8 de Mayo del 2000 
 
[22]  
http://www.visualstudio.com/ [Página Web; acceso 28-octubre-2014] 
 
[23]  
http://www.nunit.org/  [Página Web; acceso 28-octubre-2014] 
 
[24]  
http://www.microsoft.com/es-es/download/details.aspx?id=1695 [Página Web; acceso 
28-octubre-2014] 
 
 
[25]  
                                   
71 
 
http://msdn.microsoft.com/en-us/library/bb727098.aspx [Página Web; acceso 28-
octubre-2014] 
 
[26]  
http://www.cse.dcu.ie/essiscope/sm2/9126ref.html [Página Web; acceso 29-octubre-
2014] 
 
[27] 
https://estandarsw.wordpress.com/2010/05/20/isoiec-9126-evauacion-del-producto-
software/ [Página Web; acceso 29-octubre-2014] 
 
[28]  
http://msdn.microsoft.com/es-es/library/bb972272.aspx#m21 [Página Web; acceso 29-
octubre-2014] 
 
[29]  
http://www.asp.net/ [Página Web; acceso 29-octubre-2014] 
 
[30]  
http://www.uml.org/ [Página Web; acceso 30-octubre-2014] 
 
[31]  
http://www.omg.org/gettingstarted/what_is_uml.htm  [Página Web; acceso 30-octubre-
2014] 
 
[32] 
http://msdn.microsoft.com/es-es/library/ms731082(v=vs.110).aspx [Página Web; 
acceso 30-octubre-2014] 
 
[33]  
http://www.caseclub.ru/articles/iconix.html [Página Web; acceso 3-noviembre-2014] 
 
[34]  
http://iconixprocess.com/iconix-process/ [Página Web; acceso 3-noviembre-2014] 
 
                                   
72 
 
[35] E. Gamma, R. Helm, R. Johnson, J. Vlissides, 1995. “Design Patterns. Elements of 
reusable object-oriented software”. 
  
[36]  
http://web.cecs.pdx.edu/~black/OOP/slides/Patterns-Singleton,Proxy,State.pdf 
 [Página Web; acceso 4-noviembre-2014] 
 
[37] T. Neubauer, J. Heurix, “A methodology for the pseudonymization of medical data”. 
International Journal of Medical Informatics. Vol. 80, Pág. 190-204, 2011. 
 
[38] Patrón repository 
http://msdn.microsoft.com/en-us/library/ff649690.aspx 
 
[39] César de la Torre Llorente, Unai Zorrilla Castro, Miguel Ángel Barros, Javier 
Calvario Nelson. “Guía de arquitectura en N capas orientadas al dominio con Net 4.0” 
(impreso en España- derechos reservados Microsoft-ibérica S.R.L ISBN -978-84-
936696-3-8), 2010 
 
[40] D. Barron; L. Blumenthal; S. Bourque; N. Brovarny; J. Childress; otros, “Electronic 
Signature, Attestation, and Authorship (Updated)”. HIM Body of Knowledge, 2009.  
 
[41] Kitchenham. “Guidelines for perfoming Systematic Literature Reviews in Software 
Engineering”. Software Engineering Group School of Computer Science and 
Mathematics, 2007 
 
[42] J. Biolchini, P. Gomes, A. Cruz, G. Horta, “Systematic Review in Software 
Engineering”. Software Engineering Group School of Computer Science and 
Mathematics, 2005 
 
[43] Search Security 
http://searchsecurity.techtarget.com/definition/encryption. online [Página Web; acceso 
27-febrero-2015] 
 
[44] “The Working Party on the Protection of Individuals with Regard to Processing of 
ersonal Data”, 2014 
 
                                   
73 
 
[45]  
https://infosegur.wordpress.com/unidad-4/criptografia-simetrica-y-asimetrica/. online 
[Página Web; acceso 5-marzo-2015] 
 
[46]  
http://www.reniec.gob.pe/portal/firmaPKI.htm. online [Página Web; acceso 5-marzo-
2015] 
 
[47]  
http://blogcripto.blogspot.com/ online [Página Web; acceso 22-marzo-2015] 
 
[48]  
http://www.redeszone.net/2010/11/04/criptografia-algoritmos-de-cifrado-de-clave-
simetrica/ online [Página Web; acceso 4-abril-2015] 
 
[49]  
http://es.wikipedia.org/wiki/Criptografia_asimétrica online [Página Web; acceso 4-abril-
2015] 
[50] Migrar a Microsoft SQL Server 2008 R2 desde Microsoft SQL Server 2008, SQL 
Server 2005 y SQL Server 2000. http://www.microsoft.com/es-
es/download/details.aspx?id=16978 [Página Web; acceso 5-junio-2015] 
[51] 
http://www.msssi.gob.es/estadEstudios/estadisticas/docs/CIE_10_PCS_M_Referencia
_2013.pdf [Página Web; acceso 25-mayo-2015] 
[52] 
http://googleblog.blogspot.com/2011/06/update-on-google-health-and-google.html 
[Página Web; acceso 24-mayo-2015] 
 
[53]  
http://www.informationweek.com/healthcare/electronic-health-records/5-reasons-why-
google-health-failed/d/d-id/1098623? [Página Web; acceso 24-mayo-2015]