Informe Servicio de Salud AE Jaime Cabezas - Maite Portilla

Informática
Arquitectura Tecnológica Empresarial

De la
Servicio de Salud
2018
Asignatura: : Arquitectura de Tecnología Empresarial
Sección: 221
Nombre del académico: Jocelyn Gonzalez Cortes
Nombre de los integrantes del grupo: Maite Portilla – Jaime Cabezas
Fecha de entrega: 9 de Octubre 2018

Contenido
1. Resumen .......................................................................................................................................... 4
2. Introducción .................................................................................................................................... 5
2. Objetivos ......................................................................................................................................... 6
2.1 Objetivo General ....................................................................................................................... 6
2.2 Objetivos Específicos ................................................................................................................. 6
2.3 Consideraciones ........................................................................................................................ 6
3. Estrategia y Planeación de la Arquitectura Empresarial ................................................................. 7
3.1 Modelo de Gobierno ................................................................................................................. 7
3.2 Visión ......................................................................................................................................... 7
3.3 Principios ................................................................................................................................... 8
3.3 Planificación Estratégica.......................................................................................................... 12
3.4 Alcance de la arquitectura empresarial .................................................................................. 14
3.6 Interesados Claves y Preocupaciones ..................................................................................... 15
3.7 Objetivos Estratégicos y Metas ............................................................................................... 15
4. Arquitectura Empresarial de Línea Base (AS IS) ............................................................................ 17
4.1 Arquitectura de Negocio AS IS ................................................................................................ 20
4.1.1 Mapa de Procesos de Servicio de Salud ........................................................................... 20
4.1.2 Descripción de los procesos ............................................................................................. 21
4.1.3 Procesos Seleccionado ..................................................................................................... 24
4.1.4 Modelo de datos del negocio ........................................................................................... 24
4.1.5 Diagrama de Proceso – Donación de Sangre ................................................................... 25
4.1.6 Diagrama de Proceso – Transfusión de Sangre ................................................................ 26
4.2 Arquitectura de Datos AS IS .................................................................................................... 27
4.2.1 Modelo lógico del proceso donación de sangre .............................................................. 27
2
4.2.1 Modelo lógico del proceso trasfusión de sangre ............................................................. 27
4.3 Arquitectura de Aplicaciones AS IS ......................................................................................... 29
4.4 Arquitectura de Tecnología AS IS ............................................................................................ 31
5. Arquitectura Empresarial objetivo (TO BE) ................................................................................... 34
5.1 Arquitectura de Negocio TO BE ............................................................................................... 34
5.2 Arquitectura de Datos TO BE................................................................................................... 39
5.3 Arquitectura de Aplicaciones TO BE ........................................................................................ 44
5.4 Arquitectura de Tecnología TO BE .......................................................................................... 48
6. Análisis de Brechas (GAPS) ............................................................................................................ 54
6.1 Arquitectura de Negocio ......................................................................................................... 55
6.2 Arquitectura de Datos ............................................................................................................. 59
6.3 Arquitectura de Aplicaciones .................................................................................................. 61
6.4 Arquitectura Tecnológica ........................................................................................................ 62
6.5 GAPS Arquitectura Empresarial Proceso de Donación de Sangre........................................... 65
6.6 GAPS Arquitectura Empresarial Proceso de Transfusión de Sangre ....................................... 66
6 .7 Listado de Brechas (GAPS) Adicionales a Procesos seleccionados......................................... 67
7. Mapa de Ruta ................................................................................................................................ 71
8. Conclusiones.................................................................................................................................. 73
9. Recomendaciones ......................................................................................................................... 73
10. Glosario ....................................................................................................................................... 74
11. Siglas ............................................................................................................................................ 74
12. Bibliografía .................................................................................................................................. 75
3
1. Resumen
El presente trabajo tiene como fin el desarrollo – y a su vez plasmar –de la implementación de una
Arquitectura Empresarial realizada en la institución de salud principal en Chile, el sector de salud
dependiente de MINSAL (Ministerio de Salud de Chile). Se obtendrán distintos ámbitos de
información de las fuentes oficiales, principalmente mediante sus sitios webs, para así desarrollar
una cierta cantidad de hitos. Todo esto estará enfocado al Core Banco de sangre dentro de la
instituciones y organismos que abarquen este aspecto dentro de la atención ofrecida a la población.
Aclarado eso, este informe se conformando tomando como base en los hitos de estrategias y
planeación de la arquitectura empresarial, Arquitectura empresarial del Ministerio de Salud que
actualmente posee (AS IS), Arquitectura empresarial Objetivo a la cual se quiere llegar (TO-BE), un
análisis de brechas y por último un mapa de ruta. La arquitectura empresarial tanto en su línea base
(AS IS) como la arquitectura objetivo conllevara la utilización del método de desarrollo de
arquitectura TOGAF abarcando el marco de referencia de las arquitecturas de negocios, datos,
aplicaciones y tecnológicas.
El desarrollo de los modelos de arquitectura empresarial tiene como propósito caso incrementar la
competitividad enfocándose en el servicio y el paciente del servicio de salud que permita el otorgar
una atención más rápido y que abarque un mayor rango de la población priorizando sus necesidades
médicas , mediante la utilización de las tecnologías de la información y de esta forma optimizar los
procesos y la toma de decisiones dentro de una empresa y en el presente caso de las instituciones
y centros orientados y bajo el amparo del Ministerio de Salud.
Las propuestas desarrolladas en este trabajo profesional permitirán optimizar los subprocesos de
donación y transfusión de sangre a través de proyectos que contribuyan al logro de los objetivos
estratégicos y brinde una ventaja competitiva al objeto de estudio.
4
2. Introducción
En la actualidad los avances tecnológicos han creado una brecha entre lo que el mercado y los
consumidores demandan, y aquello que las organizaciones pueden ofrecer. El principal problema
que enfrentan las organizaciones es el hecho de emprender una transformación de sus sistemas de
trabajo a nivel tecnológico, de proceso o de gestión integral. Para lograrlo, las organizaciones
definen sus objetivos estratégicos de negocio y estos en su mayoría son soportados por las
tecnologías de información, sin embargo, la tecnología no siempre está alineada con los objetivos
estratégicos, esto ocasiona que las empresas sientan que sus inversiones se vean desperdiciadas y
no se perciba al área de tecnologías de información como un socio estratégico que permita
contribuir al logro de los objetivos.
El objeto de estudio son los Servicios de Salud que pertenecen a la Área de Salud del Estado Chileno,
una red de centros de salud y organismos de este en constante crecimiento a nivel asistencial y
técnico. Estos, tiene muy bien definido su población y como no es ajena a los avances tecnológicos,
se debe estar prepara para los cambios que los avances obliguen y poder posicionarse de tal manera
a fin de brindar una experiencia de calidad a sus pacientes.
Con el fin de entregar un atención y experiencia medica de calidad y que satisfaga las necesidades
de la población chilena que acude a la atención pública de salud, este documento presenta
propuesta de una arquitectura empresarial para el proceso de banco de sangre del objeto de estas
instituciones. para ello se aborda el tema en 4 capítulos en donde se describe un marco teórico que
nos da una visión general de los conceptos utilizados en el desarrollo de este trabajo. Asimismo, se
aplica el marco de trabajo TOGAF para realizar el procesos de arquitectura empresarial, a través de
todas las fases definidas en este marco de trabajo, se analiza el estado actual de los procesos de
Donación de Sangre y Transfusión de sangre que son parte del alcance a través de los 4 dominios:
Negocio, Datos, Aplicaciones y Tecnología TI y luego se plantea un escenario deseado teniendo en
cuenta de alinear las propuestas de mejora con los objetivos estratégicos de la organización.
5
2. Objetivos
Estos conllevaran el indicar el propósito de la arquitectura empresarial del Servicio de Salud

Chileno.
2.1 Objetivo General
Realizar el diseño de una arquitectura empresarial para los Servicios de Salud enfocado en los
subprocesos de Donación de sangre y Transfusión de sangre que son parte del proceso Core Banco
de sangre, planteando la implementación de proyectos a través de metodologías agiles que ayuden
a alcanzar la situación deseada con mayor eficacia, cumpliendo con los requerimientos del negocio
y que permita obtener una ventaja competitiva a la organización
2.2 Objetivos Específicos
Con el fin de poder puntualizar y aclarar el objetivo general establecido en el presente informe, se
procederá a detallar los objetivos específicos con que contará el desarrollo de este trabajo
observándose así la realización de:
• La definición la arquitectura Empresarial AS IS.

• Diseñar una arquitectura empresarial objetivo (TO-BE).
• Determinar y documentar las brechas entre la arquitectura actual (AS-IS) y la arquitectura
empresarial objetivo (TO-BE).
• Definir el mapa de ruta.
2.3 Consideraciones
Cuando se especifica a las personas, que son el punto en que se enfoca el desarrollo y operación
del Servicio de Salud , en ciertos apartados del presente proyecto como Clientes se aclara que nos
referimos a todos los pacientes de dichas instituciones y organismos de Salud.
6
3. Estrategia y Planeación de la Arquitectura Empresarial
3.1 Modelo de Gobierno

El Sector Salud es liderado por el Ministerio de Salud, quien le corresponde formular, fijar y controlar
las políticas de salud para el país. Bajo su dirección, se encuentran las dos Subsecretarías y las
Secretarías Regionales Ministeriales que se encargan de materializar estas políticas, junto a otros
organismos técnicos dependientes. El sistema de salud del país está conformado esencialmente por
las redes públicas de salud que incluyen desde los centros de atención primaria, hasta los centros
de especialidad de diferente nivel de complejidad. Asimismo, en una menor escala, se encuentra el
sistema privado de salud, cuya composición depende de la dirección de cada administrador,
fundamentalmente son un conjunto de centros de atención de salud de diferente complejidad que
pueden estar integrados en red o no. En cuanto a seguro de salud, este está integrado por el Fondo
Nacional de Salud (FONASA) y las Instituciones de Salud Previsional (ISAPRE), quienes tienen la
responsabilidad de garantizar la atención de salud a sus cotizantes. Todas las políticas de salud son
aplicables tanto al sector público de salud, como al sector privado, así como también a todos
aquellos agentes que ejercen acciones que puedan afectar a la salud de la población.
3.2 Visión
Actualmente el proceso de Donación de Sangre se tienen muchos problemas de falta de donantes y
por lo tanto muy poco stock de unidades para transfusión, esto representa un problema que afecta
directamente sobre la calidad de servicio que se brinda a los pacientes. Asimismo, el proceso de
transfusión de sangre que es un procedimiento muy solicitado tiene problemas de demora debido
a que el proceso de solicitud es manual, además el sistema que gestiona el almacén de sangre es un
sistema que solo funciona para el área de banco de sangre y no puede ser accedida por la enfermera
para que pueda agilizar el proceso de transfusión. Para que la empresa pueda generar valor
agregado a sus pacientes en los procesos mencionados anteriormente, el plantear una arquitectura
empresarial de manera progresiva ayudara a tener una alineación del área de TI con los objetivos
estratégicos del negocio, ayudando a plantear soluciones para lograr que estos procesos sean más
ágiles y eficaces. Esto debido a que la arquitectura empresarial abarca los dominios de negocio,
datos, aplicaciones e infraestructura de TI.
7
3.3 Principios
Principios de Negocio
Nombre Atraer la mayor cantidad de donantes de sangre
Enunciado Se debe procurar que los donantes pasen por un flujo de proceso sencillo y
en el menor tiempo posible. Esto puede garantizar su regreso en el futuro
y la recomendación a más personas.
Fundamento Asegurar el mínimo de stock de unidades de sangre disponible en el banco
Repercusiones • Mayores unidades de sangre donadas
• Minimizar los tiempos de donación para atraer mayor cantidad de

donantes.
Nombre Minimizar el uso de documentación física
Enunciado Se debe evitar el uso de documentación física en las solicitudes de

requerimientos de transfusión.
Fundamento Asegurar la integridad de la información requerida
Repercusiones • Minimizar error humano en la solicitud de transfusión.

• Minimizar los tiempos de solicitud de transfusiones de sangre.
8
Principios de Aplicaciones
Nombre Brindar servicios más que aplicaciones
Enunciado Permitir que las aplicaciones a implementar sean compatibles con la

actual para permitir integrar, combinar y reutilizar funcionalidades
Fundamento Eliminar dependencias de componentes. Evitar redundancia funcional.

Escalabilidad e interoperabilidad.
Repercusiones • Estandarización de las soluciones tecnológicas.

• Aseguramiento de la calidad de datos evitando sobre costos para
la reutilización.
Nombre Simplicidad de uso
Enunciado El usuario debe tener un mínimo de horas de capacitación para asegurar

el uso correcto de las aplicaciones Fundamento.
Fundamento Asegurar el correcto uso de las aplicaciones buscando la optimización en

los servicios.
Repercusiones • Minimizar errores operativos por parte de los usuarios.

• Cumplir con los requisitos y lineamientos establecidos al inicio.
9
Principios de Datos
Nombre Integración de la información
Enunciado La información debe estar centralizada en un repositorio central, desde el

cual podrá ser accedida por otras aplicaciones pertenecientes a otras
áreas en modo de solo lectura, en caso se requiera acceder otro nivel
deberá contar con autorización
Fundamento Contar con información histórica que permite el análisis que apoyen las
decisiones.
Repercusiones • Corregir información para el caso de emergencias.

• Control de la disponibilidad de la información
Nombre Disponibilidad de datos
Enunciado La información debe estar 100% disponible para asegurar el

cumplimiento del soporte por parte de los colaboradores.
Fundamento Información disponible. Información integra. Información centralizada.
Repercusiones • Información integra y disponible para la organización

• Seguridad de aplicaciones
Principios de Tecnología
Nombre Transición a la nube
Enunciado Enunciado Evaluar costo/beneficio de alojar las aplicaciones en la nube
Fundamento Reducción de costo de infraestructura. Integración de aplicaciones.
Repercusiones • Escalabilidad de la infraestructura en caso se requiera.

• Alta disponibilidad
10
Nombre Tecnología actual
Enunciado Todo requerimiento nuevo debe ser soportado por tecnología actual
Fundamento Contar con tecnología actualizada y adecuada que permita integrar toda
la red.
Repercusiones • Alta disponibilidad de las aplicaciones a causa de la integración.

• Asegurar que los procesos estén soportados por la tecnología.
11
3.3 Planificación Estratégica
Estos planes estratégicos afectaran los subprocesos tomando en cuenta para el desarrollo de las
arquitecturas empresariales. Así se podrá observar lo siguiente.
En concordancia con la Estrategia Nacional de Salud 2011-2020, el Ministerio de Salud, a través del
Departamento de Gestión TIC Sectorial, define el Plan Estratégico de TI e-salud que plantea los
siguientes ejes rectores para la informatización del Sector Salud:
1. Información como activo estratégico: en el Sector Salud la información es un activo

estratégico para llevar a cabo las acciones de preservar y gestionar la salud, por lo que debe
ser resguardada a fin de garantizar su disponibilidad, calidad y oportunidad.
2. El paciente en el centro: el centro de todo el sistema es el paciente en una red asistencial
integrada.
3. Liderazgo funcional: la visión e incorporación de las TI en el sector son procesos que deben
ser liderados por los directivos y dueños de los diferentes procesos (asistenciales y/o
administrativos) de cada institución. Son ellos los responsables de asegurar el impacto del
uso de las TI.
4. Foco en la atención sanitaria: la provisión de servicios informáticos no es el giro principal
del Sector, por lo tanto, se privilegia una estrategia de contratación de servicios provistos
por terceros, aprovechando las capacidades del sector privado. Se fortalecerá a nivel
sectorial la capacidad de administrar proyectos y contratos de provisión de TI. Así mismo
se establecen mecanismos de fortalecimiento de la relación Público-Privada para obtener
los mejores resultados.
5. Integración de la información: la información se registrará una sola vez en lo posible en el
lugar donde ocurre el acto asistencial y fluirá al interior del sistema público de salud. La
información de gestión se derivará de los sistemas operacionales a través del uso de
estándares (en lo posible internacionales) y de la adhesión a un modelo de arquitectura de
la información sectorial.
6. Incorporación de soluciones probadas: se promueve la incorporación de soluciones de clase
mundial, en lo posible ya probadas para los grandes procesos clínicos y administrativos (HIS
y ERP). Estas soluciones deben ser evaluadas en base a la funcionalidad provista a los
procesos del negocio, rapidez de implementación, flexibilidad, capacidad de integración
con otras soluciones, adhesión a estándares, actualización y mejoras permanentes de las
versiones de software. En el proceso de implementación de estas soluciones, se
recomienda adoptar las mejores prácticas a nivel de procesos, que éstas incorporan.
7. Alto nivel de seguridad de la información: se deben generar políticas de seguridad de la
información para los registros nacionales, de tal forma de resguardar la confidencialidad,
accesibilidad e integridad de la información administrada.
12
8. La introducción de TI es una actividad que se planifica: debe existir un plan que guíe el
desarrollo de las TI en cada Servicio, alineado con los objetivos estratégicos del Sector y con
el plan de e-salud. Además, se propiciará la existencia de Comités Informáticos en los
Servicios de Salud, compuestos por Directivos y representantes de TI, para debatir las
orientaciones de la actividad.
9. Evaluación de beneficios: Los proyectos de TI deben ser tratados como proyectos de

inversión con beneficios medibles. Se entregarán orientaciones acerca de la forma en que
se deben evaluar los beneficios de los proyectos TI. Todos los proyectos deben considerar
un estudio de prefactibilidad que señale con claridad dónde están los beneficios que se
buscan y cómo se medirán, además de identificar Los riesgos asociados y la forma de
mitigarlos. Una vez implementados, serán posteriormente evaluados, para comprobar el
cumplimiento de las promesas de impacto.
Figura 1. Visión de contexto del Plan Estratégico de TIC Servicios de Salud
13
3.4 Alcance de la arquitectura empresarial
El alcance de la propuesta de arquitectura empresarial está basado en las siguientes dimensiones:
Amplitud:
El objeto de estudio Servicios de Salud, bajo el Ministerio de Salud. Se brindan atenciones de salud
tales como hospitalizaciones, emergencia, procedimientos médicos, etc. Como parte de los
procedimientos médicos se tiene el macroproceso Procedimientos Terapéuticos que es parte de los
procesos Core de la empresa y el cual está constituido por dos procesos: Para el presente estudio
elegiremos el proceso de Banco de Sangre que abarca 2 subprocesos que serán analizados:
- Donación de sangre
- Transfusión de sangre
Profundidad:
El alcance de este proyecto profesional abarca el diseño de la arquitectura para los subprocesos de
Donación y Transfusión que pertenecen al macroproceso de Procedimientos Terapéuticos.
Periodo de tiempo:
La propuesta de arquitectura empresarial para los procesos de donación y transfusión de sangre,

comprenden el análisis de la situación actual, y las brechas que se requieren para llegar a la
situación deseada. Este proceso será cubierto en un periodo de 7 años, que ha comenzado con
distintas reformas y acciones que partieron desde el 2011 tenido como fin el año 2020
involucrando estas arquitecturas dentro de estos periodos y poniendo énfasis de puntos de
mejoras y objetivos deseables a partir del presente año 2018 (principalmente en el desarrollo de
plataformas que solventen las GAP presentadas en capítulos siguientes en el presente trabajo).
Dominios: Las arquitecturas que se abarcan y los cambios a llevar a cabios se basaran tomando en
cuenta:
Arquitectura
Proceso Negocio Datos Aplicaciones Tecnología
Operativo ✓ ✓ ✓ ✓
Estratégico ✓ ✓ ✓ ✓
14
3.6 Interesados Claves y Preocupaciones
- Ministros y Seremis de Salud: Velan por cumplir los objetivos estratégicos y que los
Servicios de Salud sean capaces de brindar las soluciones medicas necesarios.
- Directores médicos: El director médico de las distintas unidades de salud son quien
gestiona los temas del área de salud de todos los ámbitos y especialidades.
- Jefe de operaciones: Es el análogo del director médico, gestiona los temas no asistenciales
y que son de soporte de la operación de los Servicios de Salud.
- Jefas de enfermería: Encargado de dirigir las gestiones que competen al rubro de
enfermería.
- Pacientes: Foco de la recepción y validar los servicios médicos ofrecidos y otorgados.
3.7 Objetivos Estratégicos y Metas
Como consecuencia de la reforma, el sector de la salud inicio una extensiva transformación que
abarcó desde la definición de políticas y estrategias de salud, hasta la reestructuración funcional de
los centros de salud de acuerdo con el nuevo modelo de atención, así como también, la inversión
de nuevos centros asistenciales para atender la demanda existente.
En este marco, tuvo lugar como el primer eje de trabajo la definición de los objetivos sanitarios de
la década pasada, cuya evaluación se realizó al término del periodo contemplado, en donde se
identificaron los avances y las necesidades para esta década.
Respecto a las necesidades, se demostró como esencial la inserción de los objetivos en un sistema
de planificación sanitaria que integrase todos los niveles de la organización de salud, de manera de
avanzar en la formulación y gestión efectivas de las metas.
Junto a lo anterior, se mostró como imprescindible una visión amplia de la salud en la perspectiva
de la producción social y en el enfoque de determinantes sociales de la salud, lo cual pone en relieve
el planteamiento de una Política de Estado que trasciende más allá del Sector Salud, dando mayor
énfasis a la intersectorialidad y a la participación social.
15
Los objetivos que se espera alcanzar con el plan son:
• Mejorar la salud de la población.
• Mejorar la calidad de la atención.
• Efectividad de costos y aumento de productividad.
• Mejores competencias y motivación del personal.
16
4. Arquitectura Empresarial de Línea Base (AS IS)
La Arquitectura Empresarial es la respuesta de hoy para organizar y definir los componentes

tecnológicos (servicios) de un sistema con algún grado de complejidad. Según la definición
presentada por Lankhorst,1 “la arquitectura empresarial es un conjunto coherente de principios,
métodos y modelos que se utilizan en el diseño y la realización a nivel empresarial de la estructura
organizacional, los procesos de negocio, los sistemas de información y la infraestructura”.
Consecuente con este principio, el Ministerio de Salud adhirió a esta metodología para desarrollar
la Arquitectura Empresarial del Sector Salud. En una primera etapa, se realizó el modelamiento para
el nivel central. La metodología seguida para describir las diferentes capas de la arquitectura se
representa en el siguiente esquema:
17
La metodología sugiere principalmente lo siguiente:
1) Dados los lineamientos estratégicos del sector y de las tecnologías de información, se definen dos
grupos de arquitecturas: Arquitectura de Negocios y Arquitectura de Tecnologías de Información.
2) La Arquitectura de Negocios está compuesta por un conjunto de modelos que definen el quehacer
de una organización; estos son:
a. Estructura organizacional: identifica la estructura de la organización de acuerdo con las
funciones que desempeña cada dependencia.
b. Mapa de procesos: identifica y agrupa los procesos de la organización de acuerdo con los
niveles de la toma de decisiones; estos son, principalmente, estratégico, operativo y de
apoyo.
c. Modelo de información: identifica y agrupa la información según el ámbito de negocio
que la produce y sus características.
d. Mapeo de los procesos, con la información que estos consumen y producen.
e. Caracterización de los actores que participan en los procesos y su ubicación.
18
3) La Arquitectura de Tecnologías de Información describe la organización de los recursos TI para
soportar la arquitectura del negocio e incluye:
a. Arquitectura de Información: define el modelo detallado de información, que contiene
las entidades y sus relaciones, los atributos y sus características.
b. Arquitectura de Aplicaciones: establece el mapa de las aplicaciones existentes (“As Is”), y
el nuevo mapa deseado (“To Be”), de acuerdo con los procesos de negocio, la información
y los principios de la Arquitectura Orientada a Servicios. Además, contiene las fichas de las
aplicaciones, en donde se describen detalladamente los aspectos relacionados a: ¿qué es?,
¿para qué sirve?, ¿qué hace?, ¿quién es el cliente?, ¿qué valor aporta a la organización?,
entre otros.
c. Arquitectura de Integración: define los servicios que se requieren para generar la
integración de las aplicaciones, considerando tanto los servicios que sirven de plataforma
base, como los servicios aplicativos orientados a determinados negocios.
d. Arquitectura Tecnológica: define la infraestructura de hardware y software que se
requiere para soportar la Arquitectura de Integración.
e. Arquitectura de Redes: define la infraestructura de redes que se requiere para generar la
comunicación necesaria y adecuada entre las partes.
f. Arquitectura de Seguridad: define las políticas de seguridad que se requieren para la
operación de esta plataforma, considerando desde el acceso a los diferentes ambientes,
hasta el uso de estos mismos.
4) Acorde a las arquitecturas definidas, se realiza el análisis estratégico de las brechas de TI de
acuerdo con el estado actual y el estado deseado.
5) Finalmente, se define el plan de implementación de acuerdo con los criterios de priorización
definidos. En este proceso, es importante considerar que la introducción de este paradigma implica
una enorme transformación en la organización. Por lo tanto, es necesario tener presente el
mecanismo de transición para los aplicativos existentes, con el objeto de migrarlos paulatinamente
hacia aplicativos orientados a servicios, para lo cual se define un plan de transición.
6) Este trabajo es un proceso continuo que requiere de una administración permanente, esto es lo
que se denomina “Gobernabilidad de TI”. Para ello, se debe conformar un equipo de trabajo que
valide permanentemente los cambios producidos en la organización, tanto desde el punto de vista
de sus procesos, como de la información que consumen y producen estos mismos; de igual forma,
se deben validar los nuevos requerimientos de TI que surge de los cambios generados o nuevas
necesidades identificadas.
Los resultados más importantes de la definición de la Arquitectura Sectorial son los que ahora se
indican.
La arquitectura SOA permite una eficiente reutilización de los componentes, generando ahorros
en la inversión y en la administración de estos componentes
19
4.1 Arquitectura de Negocio AS IS
4.1.1 Mapa de Procesos de Servicio de Salud
20
4.1.2 Descripción de los procesos
Id Proceso Función Descripción de la función
Gestionar, administrar el plan

1 Planeamiento Gestionar el plan estratégico
Estratégico estratégico de la empresa
Planificar las metas de la empresa y

2 Planificación y Planificar el desarrollo de la empresa
Desarrollo desarrollar los objetivos para
alcanzarlos
Se encarga de gestionar el
3 Marketing Gestionar el marketing estratégico
marketing de los servicios /
Estratégico de
Productos de la empresa, de
los Servicios -
manera estratégica
Productos
Gestiona las relaciones

4 Relaciones Gestionar las relaciones
institucionales con la finalidad
Institucionales institucionales
de que estén acorde con lo
deseado
5 Gestión Legal Gestionar los temas legales Gestiona los temas legales de la
empresa
6 Gestión de Calidad Gestionar la calidad en los procesos y Gestiona y asegura la calidad en los
servicios procesos
Realiza las investigaciones en el ámbito
7 Investigación y Realizar investigación en el ámbito
Docencia médico sobre temas aún no estudiados,
médico y su posterior docencia
y promueve la docencia
21
ID Proceso Función Descripcion de la Función
Recluta, capacita, apoya, gestiona el

talento clínico humano y tecnológico
8 Gestión del Talento Gestiona el talento
Clinico (Médico) clínico(Médico)
Realiza la atención de todos los pacientes

que llegan a la clínica bajo condiciones
9 Emergencia Atención de pacientes clínicas de emergencia
por emergencia
Gestionar y atender a los pacientes en el

ámbito de consulta externa
10 Consulta Externa Atención vía consulta
externa
Hospitalización
Convencional
11 Gestionar la Gestionar y atender los pacientes
hospitalización hospitalizados
Gestionar y atender los pacientes

hospitalizados en UCI
12 Hosp. críticos UCI Gestionar la
hospitalización UCI
13 Cirugía Ambulatoria Gestionar las cirugías Realizar las atenciones por cirugía
ambulatorias ambulatoria
Realizar las atenciones por cirugía y

derivarlas a hospitalización
14 Cirugía de Gestionar cirugías con
Hospitalización hospitalización
Gestionar las Realiza y gestiona las atenciones con

atenciones de solicitud de imágenes
15 Dx por imágenes imágenes
22
23
4.1.3 Procesos Seleccionado
El macroproceso seleccionado es Procedimientos Terapéuticos, este macroproceso es Core de
Banco de Sangre dentro de los Servicios de Salud. Este macroproceso soporta los objetivos
estratégicos indicados en la empresa y fortalecen el negocio para lo cual tiene siete procesos
Farmacia, Quimioterapia, Nutrición y Dietética, Radioterapia, Medicina Física y Rehabilitación,
Hemodiálisis y Banco de Sangre siendo este último el objeto de estudio, donde veremos la gestión
integral de las unidades de sangre disponibles y requeridas, cuentan con los siguientes
subprocesos:
- Donación de sangre
- Transfusión de sangre
4.1.4 Modelo de datos del negocio
Proceso de Donación
No Aplica
Procesos de Transfusión
Figura – Arquitectura Línea Base - Modelo de datos de Negocio – Transfusión de Sangre
24
4.1.5 Diagrama de Proceso – Donación de Sangre
Figura - Arquitectura Línea Base – Diagrama de flujo de proceso de Registro Donación de

Sangre
Figura - Arquitectura Línea Base – Diagrama de flujo de proceso de Donación de Sangre
25
4.1.6 Diagrama de Proceso – Transfusión de Sangre
Figura Arquitectura Línea Base – Diagrama de flujo Proceso Transfusión de Sangre
26
4.2 Arquitectura de Datos AS IS
La arquitectura de datos, estructura de datos, declarada en el Servicio de Salud para los procesos
elegidos en el análisis del presente trabajo se muestra a continuación:
4.2.1 Modelo lógico del proceso donación de sangre

En la actualidad no se cuenta con un sistema para el proceso de Donación de sangre y todo el flujo
es de manera manual, por ello no se cuenta con el modelo conceptual.
4.2.1 Modelo lógico del proceso trasfusión de sangre
Figura - Arquitectura Línea Base – Modelo Lógico del Proceso Transfusión de Sangre
27
Tabla - Arquitectura Línea Base – Descripción Modelo Lógico
ID Obejtivo de Negocio Descripcion

Es la tabla que almacena toda información del
1 USUARIO
usuario solicitante.
Contiene datos del paciente con la cantidad de

2 SOLICITUD_TRANSFERENCIA
sangre que solicita.
3 MUESTRA_SANGRE Contiene la solicitud para sacar la muestra de

sangre.
4 PRUEBA_CRUZADA Contiene el estado de la prueba cruzada.
Es la tabla donde se almacena la información de la

5 ALMACEN
sangre que se tiene con la característica de cada tipo.
28
4.3 Arquitectura de Aplicaciones AS IS
La arquitectura de aplicaciones de los subprocesos en análisis es declarada en el siguiente

diagrama
Figura - Arquitectura Línea Base – Arquitectura de aplicaciones / Diagrama de

aplicaciones
29
Tabla - Arquitectura Línea Base – Arquitectura de aplicaciones / Componentes
ID Componente Descripción
ERP Asistencial, contiene los módulos de

Estación médica, Central de enfermeras,
1 xHIS bloque quirúrgico, Liquidación, facturación,
Admisión, Urgencias, Confirmación de citas.
Módulo correspondiente a Farmacia,

2 xFarma
movimientos de stock, dispensación de
carros de unidosis, órdenes médicas
3 eHC Módulo de Historia Clínica electrónica
4 HPresc Módulo de Prescripciones médicas
5 xGPC Módulo de Peticiones de procedimientos
6 Rispacs Módulo de imágenes, Rx, Tomografías
7 Endoc Módulo de endoscopia
8 Omega Módulo de laboratorio
9 SAP ERP operativo, logística y finanzas
10 BMatic Gestor de colas
11 E-Delphyn Software de banco de sangre
30
4.4 Arquitectura de Tecnología AS IS
La arquitectura tecnológica declara para los subprocesos, muestra el servidor único e

independiente “GSPEDELPHYN” y luego dos grupos de servidores los cuales conectan la
información mediante el sistema integrador llamado Mirth, el detalle se encuentra en el
siguiente cuadro.
Figura - Arquitectura Línea Base – Arquitectura tecnológica / Diagrama de infraestructura
31
Tabla Arquitectura Línea Base – Arquitectura Tecnológica/ Componentes de
Infraestructura
ID Infraestructura Descripción
Servidor Citrix ERP HIS

1 GSPLMOISOFT01

2 GSPLMOISOFT06

3 GSPLMOISOFT07
4 GSPEDELPHYN Servidor de banco de sangre E-Delphyn

5 GSPLMOHISEB
Servidor Citrix ERP HIS,

6 GSPLMOFS01
7 AUNSNBCX02 Servidor Citrix ERP HIS, sede Call Center
8 GSPLMOISOFT05 Servidor Citrix ERP HIS, sede Call Center
9 GSPHISPRD Servidor de Base de Datos ERP HIS
Servidor del integrador Mirth, tiene como

10 GSPLMOISOFT04
función integrar los sistemas brindando
información de pase de un sistema a otro
11 GSPERPPRD Servidor del ERP SAP
Servidor del sistema RISPACS (Módulo

12 AUNMOLCAS1
Imágenes)
13 GSPLMOAP03 Servidor del sistema Omega (Laboratorio)
14 GSPDELAD01 Servidor del gestor de cola BMatic
32
Estaciones de trabajo ubicadas
15 Pacientes(Clientes Minsal)
Estaciones de trabajo ubicadas en la estación de

16 Pacientes Call Center
Centro De Atención Telefónica
33
5. Arquitectura Empresarial objetivo (TO BE)
5.1 Arquitectura de Negocio TO BE

Para el caso de la Arquitectura de negocio, después de haber realizado el análisis de las brechas,
para el caso del proceso de Donación de Sangre lo que se propone es automatizar y aumentar el
número de donantes a través de una aplicación web y móvil. Para el caso del proceso de Transfusión
se propone la integración con el Sistema Core del Servicio de Salud que es el ERP xHIS con la finalidad
de agilizar el proceso de transfusión de sangre, así como también tener la data centralizada sobre
transfusiones a pacientes de piso y emergencia, para mostrar el esquema propuesto se detallan los
flujos del proceso en base a la solución propuesta:
Diagramas de proceso – Donación de sangre – TO BE
Figura - Arquitectura destino TO BE– diagrama de flujo de proceso generar cita donación
34
Figura – Arquitectura Objeto TO BE - Diagrama de Flujo de proceso de Donación de Sangre
35
Diagramas de proceso – transfusión de sangre – TO BE
En este proceso se contempla que la propuesta para el esquema de transfusión debe tener una
orden de transfusión automática que permita hacer el pedido directamente en el sistema, con
ello, se optimizarían los tiempos de solicitud y permita registrar esta información.
El módulo Transfusión se debe ubicar como opción en el ERP xHIS.
Figura – Arquitectura Objetivo TO BE – Arquitectura de Negocio/Flujo de Transfusión de Sangre
36
Modelo de datos del negocio (modelo conceptual TO BE)
Proceso de Donación de Sangre
Figura – Arquitectura destino – Modelo de datos de negocio – Donación de Sangre
37
Proceso de transfusión de sangre
Figura – Arquitectura destino – Modelo de datos de negocio – Transfusión
38
5.2 Arquitectura de Datos TO BE
En la arquitectura de datos TO BE, encontramos que se añadirán tablas ya existentes a este esquema
de datos propuesto para este subproceso, estas tablas corresponden a los nuevos requerimientos,
Avance de cuenta y App Móvil. El modelo de datos que acogerá el App Móvil es el modelo de datos
ya existente por lo que solo se deberá añadir tablas base de anotaciones adicionales que permitirá
informar sobre los cambios.
Modelo de datos lógico – Proceso de donación de Sangre TO BE
Figura - Arquitectura Destino – Modelo lógico del proceso de Donación de Sangre
39
El modelo de datos que acogerá el Portal Web y App Móvil de donante es nuevo y
que se implementara en su totalidad.
Tabla -Arquitectura Objetivo TO BE – Descripción Modelo Lógico
ID Objeto de Negocio Descripción

1 PERSONA Contiene información general de una persona.
2 DONANTE Almacena información personal del donante
3 EXAMEN_CLINICO Almacena información de todos los exámenes de los análisis médicos o
clínicos.
4 ALMACEN Almacena identificación del almacén de sangre
5 SANGRE_DONADA Almacena las unidades donadas
6 RESERVA_SANGRE Almacena información de la cantidad de unidades de sangre existente.
Almacena resultados de análisis médicos de la sangre donada.

7 REPORTE_DE_ANÁLISI
S _ CL Í N I C O
8 Contiene la información de resultado de la sangre donada

DONACION
9 P R E G U N T A S _ E N C U E S T Contiene la información del pre-formulario de evaluación del donante

A
10 ENCUESTA Contiene la información de todas las encuestas realizadas a donantes
11 MEDICO Registra la información del médico y las recomendaciones para el donante

12 FORMULARIO Registra información respondida a las preguntas realizadas al paciente
40
Modelo de datos lógico – Proceso de Transfusión de Sangre TO BE
Figura - Arquitectura Destino – Modelo lógico del proceso de Transfusión
41
Para la arquitectura de datos de este proceso se integrará con las siguientes tablas que permitirá
automatizar el envío y recepción de información asignado a un paciente para su posterior
tratamiento.
Tabla – Arquitectura destino – Descripción Modelo de Transfusiones de Sangre
ID Objeto de Negocio Descripción

En esta entidad se registran la ID de la muestra de sangre del paciente
1 MUESTRA_SANGRE
2 PRUEBA_CRUZADA Tabla de información que guarda resultados de prueba cruzada
3 TRANSFUSION Almacena incidencias de la transfusión
4 ALMACEN Almacena información del tipo de sangre
5 RESERVA_SANGRE Almacena información de disponibilidad de unidades de sangre
6 TRANSFUSIÓN Almacena información de la transfusión
7 HISTORIA_CLÍNICA Almacena toda la información de su historia clínica
8 MEDICOS Almacena ID de médico
9
ENFERMERA Almacena ID de la enfermera
10 SOLICITUD_TRANSFEREN Almacena las hojas de solicitud de transfusiones.

CIA
11 PACIENTE Almacena información del paciente
12 CENTROS Lista de centros registrados
13 CLIENTES Registra los pacientes-clientes de la institución
14 HABITACION Se almacenan los tipos de habitación posibles
42
Almacena información de los datos personales de médicos, enfermera y
15 PERSONA
paciente
43
5.3 Arquitectura de Aplicaciones TO BE
Arquitectura Orientada al proceso de Donación de Sangre
Se incluirá dentro del diagrama de aplicaciones, las nuevas generadas a partir de los requerimientos:
• Aplicación Web y Móvil del Donante

Figura - Arquitectura Destino – Arquitectura de Aplicaciones / Donación de Sangre
Tabla - Arquitectura Línea Base – Arquitectura de Aplicaciones / Donación de Sangre
44
ID Componente Descripción
ERP Asistencial, contiene los módulos de Estación
1 xHIS médica, Central de enfermeras, bloque quirúrgico,

Liquidación, facturación, Admisión, Urgencias,
Confirmación de citas.
Módulo correspondiente a Farmacia, movimientos de

2 xFarma
stock, dispensación de carros de unidosis, órdenes
médicas
3 eHC Módulo de Historia Medica electrónica
4 Hpresc Módulo de Prescripciones médicas
10 Bmatic Gestor de colas
11 Banco Sangre Portal Web y App móvil del donante
45
Arquitectura Orientada al proceso de Transfusión de Sangre
Esta arquitectura sufre modificaciones, ya que en este proceso se manejará ERP xHIS de manera
independiente, pero se ahora se requiere integrar con la aplicación de Banco de Sangre E-Delphyn.
Figura - Arquitectura Destino – Arquitectura de aplicaciones / Transfusión de sangre
46
Tabla 39 - Arquitectura Línea Base – Arquitectura de Aplicaciones / Transfusión de Sangre
ID COMPONENTE DESCRIPCIÓN
ERP Asistencial, contiene los módulos de Estación
1 xHIS médica, Central de enfermeras, bloque quirúrgico,

Liquidación, facturación, Admisión, Urgencias,
Confirmación de citas.
Módulo correspondiente a Farmacia, movimientos de

2 xFarma
stock, dispensación de carros de unidosis, órdenes
médicas
3 eHC Módulo de Historia Medica electrónica
4 Hpresc Módulo de Prescripciones médicas
10 Bmatic Gestor de colas
11 E-DELPHYN Aplicación de gestión de banco de sangre
47
5.4 Arquitectura de Tecnología TO BE
Arquitectura Orientada al proceso de Donación de Sangre
La arquitectura tecnológica del modelo propuesto incluye un servidor adicional y terminales de

conexión para la nueva aplicación.
Figura - Arquitectura Destino –Arquitectura Tecnológica / Donación de Sangre
48
Tabla - Arquitectura Destino – Arquitectura Tecnológica / Donación de Sangre
ID Infraestructura Descripción

1 GSPLMOISOFT01

2 GSPLMOISOFT06

3 GSPLMOISOFT07
Servidor Citrix ERP HIS,

4 GSPLMOHISEB

5 GSPLMOFS01
Servidor del integrador Mirth, tiene como

9 GSPLMOISOFT04
función integrar los sistemas brindando
información de pase de un sistema a otro
Servidor del sistema RISPACS (Módulo

11 AUNMOLCAS1
Imágenes)
13 GSPDELAD01 Servidor del gestor de cola BMatic
49
Estaciones de trabajo
14 Paciente (Cliente Minsal)

15 Paciente Call Center (Cliente)
Call Center
17 Banco Sangre Servidor que alojará la aplicación del Portal web

del donante
18 Portal Web Donante Terminal que usará el donante para
conectarse al portal
19 App Móvil Donante Terminal móvil que usará el donante para
conectarse a la aplicación Móvil
50
Arquitectura Orientada al proceso de Transfusión de Sangre
De la mano con la problemática de Lentitud de la aplicación, encontramos que la arquitectura

tecnológica en este proceso se modificará incluyendo un servidor adicional que permitan
balancear la carga de la operación y la integración del servidor E-DELPHYN con xHIS.
Figura - Arquitectura Destino –Arquitectura Tecnológica / Transfusión de Sangre
51
Tabla 41 - Arquitectura Destino – Arquitectura Tecnológica / Transfusión de Sangre
ID INFRAESTRUCTURA DESCRIPCIÓN
1 GSPLMOISOFT01 Servidor Citrix ERP HIS
2 GSPLMOISOFT06 Servidor Citrix ERP HIS
3 GSPLMOISOFT07 Servidor Citrix ERP HIS,
4 GSPLMOHISEB Servidor Citrix ERP HIS
5 GSPLMOFS01 Servidor Citrix ERP HIS
ID INFRAESTRUCTURA DESCRIPCIÓN

Servidor del integrador Mirth, tiene como función
9 GSPLMOISOFT04 integrar los sistemas brindando información de
pase de un sistema a otro
11 AUNMOLCAS1 Servidor del sistema RISPACS (Módulo Imágenes)
13 GSPDELAD01 Servidor del gestor de cola Bmatic
14 Paciente (Cliente Minsal) Estaciones de trabajo

15 Paciente Call Center
Call Center
Servidor de Banco de Sangre se integrara a los

16 EDELPHYN
servidores Citrix ERP HIS
52
Servidor adicional Citrix ERP HIS,
20 GSPLMOISOFT21
53
6. Análisis de Brechas (GAPS)
Del análisis de la arquitectura empresarial mostrado en los puntos anteriores podemos
encontrar que el modelo ASIS presentado nos muestra la situación actual de los procesos en la
empresa, desde el punto de vista de la arquitectura de negocios, de datos, de aplicaciones y
tecnológica.
De esta revisión hemos definido el modelo TO BE propuesto a nivel de mejoras y solución de
problemas, y a continuación mostraremos el análisis de brechas que nos permitirá definir qué
estrategia utilizaremos para completar y llegar al modelo propuesto.
54
6.1 Arquitectura de Negocio
Tabla -Análisis de Brechas /Arquitectura de Negocios /Donación de Sangre
55
56
Proceso de Trasfusión de Sangre
Tabla -Análisis de Brechas/Arquitectura de Negocios /Transfusión de Sangre
57
58
6.2 Arquitectura de Datos
Tabla –Análisis de Brechas/Arquitectura de Datos /Donación de Sangre
Proceso de Transfusión de Sangre
Tabla –Análisis de Brechas/Arquitectura de Datos /Transfusión de Sangre–Parte1
59
Tabla –Análisis de Brechas/Arquitectura de Datos /Transfusión de Sangre–Parte2
60
6.3 Arquitectura de Aplicaciones
Tabla -Análisis de Brechas/Arquitectura de Aplicaciones /Donación de Sangre
61
6.4 Arquitectura Tecnológica
Tabla- Análisis de Brechas/Arquitectura de Tecnológica /Donación de Sangre–Parte1
62
Tabla- Análisis de Brechas/Arquitectura de Tecnológica /Donación de Sangre–Parte2
63
Proceso de Transfusión de Sangre
Tabla -Análisis de Brechas/Arquitectura de Tecnológica /Transfusión de Sangre–Parte1
Tabla -Análisis de Brechas/Arquitectura de Tecnológica /Transfusión de Sangre–Parte 2
64
6.5 GAPS Arquitectura Empresarial Proceso de Donación de Sangre
GAPS Arquitectura de Negocio
• Implementar
El plan de acción para este caso es implementar los nuevos procesos descritos, para ello
se ejecutarán como proyecto de implementación de software que tendrá como objetivo,
cada uno de ellos, tener la aplicación móvil y de portal web de donante.
GAPS Arquitectura de Datos:
• Implementar
El modelo de datos se implementará de cero, ya que, para este caso, las mejoras
propuestas trabajaran en automatizar un proceso manual con ausencia de información.
GAPS Arquitectura de Aplicación
• Implementar
El plan por seguir está en la implementación de dos nuevas aplicaciones para soportar la
propuesta definida del análisis realizado. En este caso incluiremos las aplicaciones App
Móvil Donante y Portal Web Donante.
GAPS Arquitectura Tecnológica
• Implementar
Para dar soporte a lo establecido en los puntos anteriores, la estrategia será
complementar el modelo de infraestructura con un servidor que alojen estas aplicaciones
y respondan a los requerimientos establecidos en el proyecto.
65
6.6 GAPS Arquitectura Empresarial Proceso de Transfusión de Sangre
• Implementar
El plan de acción a seguir para este caso es implementar las actividades dentro del proceso
de Transfusión de sangre, se implementará el módulo de Transfusión de sangre, este es un
módulo adicional al ERP xHIS, posteriormente se integrará con el software EDelphyn.
GAPS Arquitectura de Datos:
• Implementar
En este caso el modelo de datos se integrará con un conjunto de tablas que son parte del
proceso de transfusión, son 5 tablas para poder enviar y recibir la información que viene de
la mano con la actividad incluida en el punto anterior, estas tablas incluyen información de
los esquemas de Hospitalización e Historia Clínica.
GAPS Arquitectura Tecnológica
• Implementar
Si bien para la modificación del proceso no se requiere cambiar el esquema de tecnología,
es una problemática general la lentitud que presenta el sistema en distintos rangos horarios,
por lo que la estrategia en este caso es implementar la puesta en marcha de un servidor
Citrix adicional que permita balancear la carga de usuarios conectados al esquema actual.
66
6 .7 Listado de Brechas (GAPS) Adicionales a Procesos seleccionados
Proceso Dispensación de Fármacos
GAPS_ID D-01
Tipo de Gaps Modificación
Dimensión de Arquitectura Aplicaciones, datos
Descripción Gaps El dispensar los fármacos necesarios para solventar alguna enfermedad es un
punto clave en la entrega de un servicio de salud completo.
Situación Actual (AS IS) Se cuenta con dispensación de fármacos de forma manual
Situación Futura (TO BE) Automatizar y tener mayor control de los fármacos
Factores responsables Perdida de fármacos y mala gestión de estos mismos.
Propuesta de Solución Mejorar el sistema de gestión de farmacia para suministrar en forma oportuna
a los usuarios los medicamentos recetados por el profesional de la salud.
Motivador (Driver) misional Entregar fármacos correctos y adecuados, contando con las cantidades
que soporta necesarias controlando y gestionado para no incurrir en gastos innecesarios al
no contar con estos elementos críticos de salud.
67
Proceso Servicio de gestión de citas
GAPS_ID D-02
Tipo de GAPs Modificación
Dimensión de Arquitectura Aplicaciones, datos
Descripción GAPs La gestión de citas es un proceso de servicio integrado a las actuales agendas
de gestión de los centros de salud, donde el proveedor de agenda integra su
servicio con el proveedor de contractibilidad, levantando funcionalidades que
ayudaran a los centros para enviar comunicaciones de forma automatizada.
Situación Actual (AS IS) No existe un sistema de automatización de citas
Situación Futura (TO BE) Un sistema de automatización de gestión de citas para contar con servicios de
validación de datos de contacto, recibir
notificaciones de confirmación o cancelación de citas de parte de los usuarios
directo en sus actuales
agendas, y otros canales, así como poder contar con nuevos servicios con más
información para
le gestión del SOME y los encargados del programa cardiovascular
Factores responsables La adherencia en tratamiento a largo plazo de pacientes crónicos
Propuesta de Solución Mejorar el sistema de gestión de farmacia para suministrar en forma oportuna
a los usuarios los medicamentos recetados por el profesional de la salud.
Motivador (Driver) misional Brindar mejor servicio a los pacientes
que soporta
68
Proceso Habilitar controles contra malware
GAPS_ID D-03
Tipo de GAPs Nuevo
Dimensión de Arquitectura Software, seguridad.
Descripción GAPs La sala de data center al contener información tan sensible necesita
mantenerse en óptimas condiciones físicas.
Situación Actual (AS IS) No se encuentran habilitados los controles contra Programa maligno
Situación Futura (TO BE) Se pretende habilitar los controles contra malware en el 2019, para mantener
la seguridad. Y no permitir vulnerabilidades en el sistema.
Factores responsables Eventual demanda de ataques
Propuesta de Solución Plan de prevención de programa maligno
Motivador (Driver) misional Seguridad para el data center y aplicaciones que dependen de este
que soporta
Proceso Sistema de climatización de precisión con pasillo frio/caliente y extractor de

aire de pasillo caliente en sala data center
GAPS_ID D-04
Tipo de GAPs Nuevo
Dimensión de Arquitectura Aplicaciones, hardware
Descripción GAPs La sala de data center al contener información tan sensible necesita
mantenerse en óptimas condiciones físicas.
Situación Actual (AS IS) No se cuenta control de ambiente en la sala de data center.
Situación Futura (TO BE) Climatización y control total del data center para prevenir eventuales
problemas futuros.
Factores responsables No se contempló cuando se incorporó el data center
Propuesta de Solución Implementar un sistema de climatización con sensores de precisión de la

temperatura ambiente y que este sea controlado mediante una aplicación.
69
Motivador (Driver) misional Brindar mayor protección en el data center
que soporta
70
7. Mapa de Ruta
Este mapa de ruta presenta la Estrategia Digital 2011-2020 para el Sistema Público de Salud, con la
intención final de contribuir a mejorar la salud de la población mediante una información oportuna,
eficiente y confiable, como apoyo sustantivo a los procesos de cuidado y prevención sanitarios. Uno
de los objetivos centrales de este plan es convertirse en un soporte del más alto nivel para lograr un
ejercicio eficiente del Sistema de Salud en aspectos como la coordinación y administración de la red
asistencial, la gestión, productividad y desempeño de los establecimientos, con estándares de
calidad y eficiencia universalmente aceptados, resguardando y focalizando el uso de los recursos del
sector. Asimismo, debe ser una poderosa herramienta para mejorar la prevención y promoción de
la salud pública. Este propósito se afianzará a través de soluciones que permitan articular procesos
estandarizados y coordinados, juntamente con sistemas de información interconectados, todo ello
sobre la base de una Arquitectura de Información para el área de la salud.
Descripción Proyecto Prioridad Año Inicio Año termino Situación Actual Situación Final
Esperada
Tentativo Tentativo
Implementar un sistema web y Alta 2018 2020 Realizar citas y Desarrollar un

móvil de donante donación de sangre aplicativo web y
de manera manual móvil para la gestión
de la donación de
sangre
Desarrollo de módulo de Alta 2018/ 2020 Las enfermeras Desarrollar un

transfusión de sangre en ERP realizan de manera módulo de
2019
Xhis e integración con Edelphyn manual las transfusión de
solicitudes de sangre dentro del
transfusión de ERPS xHIS y luego
sangre integrarlo con el
software de banco
de sangre Edelphyn
71
Campaña de publicidad e Media 2017 2020 Se ha concretado Se espera generar
integración a la población al pequeñas campañas una amplia
llamado público de ser donante con el fin de cobertura a nivel
concientizar a la publicitario para
población respecto a elevar los índices de
la donación de donantes de sangre
sangre a nivel a nivel nacional.
nacional. Logrando concretar
que el nivel de
donantes de
triplique al finalizar
el año 2020.
Creación de manuales de Media 2017 2020 Al no contar con Por ello se cree
usuarios para el uso correcto dicha tecnología y generar la suficiente
de las nuevas mejoras y sumando a ello la información para
plataformas que contaran los falta información en entregar a la
servicios de salud. cuanto a donación población dando uso
de sangre y a estas nuevas
transfusiones la herramientas y
cantidad de donares dando conocer la
es insuficientes, relevancia de donar
debido al miedo y sangre en nuestro
aversiones creadas país.
en torno ello
72
8. Conclusiones
Asimismo, del análisis se ha obtenido una propuesta del modelo TO-BE a implementar y ha
permitido realizar el análisis de brechas y encontrar los GAPs necesarios a cubrir mediante las
estrategias definidas para cada nivel de arquitectura.
Los proyectos de TI que están alineados con el cumplimiento de los objetivos estratégicos tienen
mayor prioridad por las gerencias ya que se tiene una percepción de que habrá un retorno de la
inversión y se deja de ver como un gasto, de esta forma se posiciona al área de TI como socio del
negocio.
Posicionar al área de TI como socio del negocio permitirá que se planteen mejoras que ayuden a
obtener una ventaja competitiva para la organización en relación con su competencia.
Mejorar el proceso de donación de sangre permitirá aumentar la cantidad de donantes y de esta

forma poder tener la cantidad necesaria de unidades de sangre para poder cubrir
con las transfusiones que demandan los pacientes.
9. Recomendaciones
Como grupo de trabajo pretendemos el poder concientizar a la principales organismos y entidades

con mayor injerencia e importancia en el Servicio de Salud – sus distintas instituciones y organismos
– acerca de la gran importancia de contar con una Arquitectura Empresarial que permita el
alineamiento de los procesos de negocio con los objetivos de la institución.
Asimismo, Revisar y rediseñar, de ser necesario, el portafolio de servicios de TI ya que conforman la

carta de presentación hacia los clientes. Y si adicionalmente a ello no se cuenta con un plan de
capacidades bien definido o no se sabe llevar de manera adecuada una gestión del cambio no se
alcanzará el nivel esperado de satisfacción del cliente.
Evaluar las ventajas y desventajas de los diversos estándares o marcos de trabajo para los diferentes
propósitos de la organización: Recurso Profesional, Servicios en TI o Arquitectura Empresarial ya que
se debe tener en consideración que no necesariamente se deben implementar en su totalidad. En
su defecto, se deben tomar las mejores prácticas y alineamientos que se ajusten a la realidad de la
organización
73
10.Glosario
-xHIS: ERP HIS asistencial, el cual permite la automatización de procesos asistenciales desde la
admisión hasta la facturación y liquidación con aseguradoras.
-E-Delphyn: Programa de administración del Banco de sangre. Permite la completa automatización

de la actividad que desarrolla un Banco de Sangre. Facilita el acceso inmediato a la historia
completa de cada una de las unidades y a la historia completa de cada donante.
Basado en la impresión de etiquetas mediante códigos de barras para agilizar los procesos y
garantizar la veracidad de la información. Captura en tiempo real de los resultados obtenidos en
todos los analizadores o dispositivos disponibles en cada Banco de Sangre. Centraliza el manejo de
la información y permite imprimir reportes que ayudan a auditar los procesos.
11.Siglas
1. HIS: Hospital Information System
2. UCI: Unidad de cuidados intensivos
3. UCIN: Unidad de cuidados intensivos Neonatal
4. CEX: Consulta Externa
5. URG: Urgencias
6. HOS: Hospitalización
7. CQX: Cirugía
8. EDT: Estructura de descomposición del trabajo
9. ERP: Enterprise Resource Planning
10. PRD: Producción
11. TI: Tecnologías de Información
12. MOF: Manual de roles y funciones.
74
12.Bibliografía
García Suárez, J. L. (2004). Los sistemas de información y la estrategia empresarial [Monografía]. Recuperado
de
https://ebookcentral.proquest.com/lib/inacapsp/detail.action?docID=3158912&query=978113408
2711
Josey, A. (2013). TOGAF® versión 9.1: Guía de bolsillo. Recuperado de
https://www.vanharen.net/Samplefiles/9789087537104SMPL.pdf
Lobo Dugarte, W. (2009). Modelo de planificación [Apuntes]. Recuperado de
https://ebookcentral.proquest.com/lib/inacapsp/detail.action?docID=3181419&query=modelo+d
e+planificaci%C3%B3n
Ministerio de Tecnologías de la Información y las Comunicaciones de Colombia. (s.f.). 3. Ejecución del
ejercicio de AE. Recuperado de http://www.mintic.gov.co/arquitecturati/630/w3-article-9437.html
The Open Group. (2009). TOGAF version 9: The Open Group Architecture Framework (TOGAF). Recuperado
de
http://www.up.ac.za/media/shared/Legacy/sitefiles/file/44/1066/2018/8136/tempfolder/togaf9.
pdf
75
Thompson, A., Gamble, J. y Peteraf, M. (2012). Administración estratégica: Teoría y casos [Monografía].
Recuperado de
https://ebookcentral.proquest.com/lib/inacapsp/reader.action?docID=3214460&ppg=5
Salud-e. (2018). Arquitectura Sectorial y Estándares. [En Línea] Recuperado de: http://www.salud-
e.cl/plan/arquitectura-sectorial-y-estandares/ [Accedido 5 octubre 2018].
Arquitectura Empresarial Sector Salud. (2013). [En Línea] Recuperado de http://www.salud-e.cl/wp-
content/uploads/2013/07/I+-+Arquitectura+Empresarial+Sector+Salud+v+1.0.pdf
FASES DE DESARROLLO DE TOGAF. (2014). [En Línea] Recuperado de:
https://chae201411700810326.wordpress.com/2014/07/10/fases-de-desarrollo-de-togaf/
Arquitectura, integración e interoperabilidad en Salud. (2004). [En Línea] Recuperado de:
http://www.scian.cl/archivos/uploads/1314011034.9904
Documento: AE MINSAL –Arquitectura de Negocios –Modelo de Información Fecha:16/05/2013Versión 1.2
Página: 1 de 20 Arquitectura Empresarial Ministerio de Salud. (2015). [Ebook]. Recuperado de
https://docplayer.es/5654149-Arquitectura-empresarial-ministerio-de-salud.html
76

Informe Servicio de Salud AE Jaime Cabezas - Maite Portilla

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe Servicio de Salud AE Jaime Cabezas - Maite Portilla

Cargado por

Copyright:

Formatos disponibles

Informática

Arquitectura Tecnológica Empresarial

Asignatura: : Arquitectura de Tecnología Empresarial

Nombre del académico: Jocelyn Gonzalez Cortes

Nombre de los integrantes del grupo: Maite Portilla – Jaime Cabezas

Fecha de entrega: 9 de Octubre 2018

Estos conllevaran el indicar el propósito de la arquitectura empresarial del Servicio de Salud

2.1 Objetivo General

2.2 Objetivos Específicos

• La definición la arquitectura Empresarial AS IS.

3.1 Modelo de Gobierno

Nombre Atraer la mayor cantidad de donantes de sangre

Fundamento Asegurar el mínimo de stock de unidades de sangre disponible en el banco

Repercusiones • Mayores unidades de sangre donadas

• Minimizar los tiempos de donación para atraer mayor cantidad de

Nombre Minimizar el uso de documentación física

Enunciado Se debe evitar el uso de documentación física en las solicitudes de

Fundamento Asegurar la integridad de la información requerida

Repercusiones • Minimizar error humano en la solicitud de transfusión.

Nombre Brindar servicios más que aplicaciones

Enunciado Permitir que las aplicaciones a implementar sean compatibles con la

Fundamento Eliminar dependencias de componentes. Evitar redundancia funcional.

Repercusiones • Estandarización de las soluciones tecnológicas.

Nombre Simplicidad de uso

Enunciado El usuario debe tener un mínimo de horas de capacitación para asegurar

Fundamento Asegurar el correcto uso de las aplicaciones buscando la optimización en

Repercusiones • Minimizar errores operativos por parte de los usuarios.

Nombre Integración de la información

Enunciado La información debe estar centralizada en un repositorio central, desde el

Repercusiones • Corregir información para el caso de emergencias.

Nombre Disponibilidad de datos

Enunciado La información debe estar 100% disponible para asegurar el

Fundamento Información disponible. Información integra. Información centralizada.

Repercusiones • Información integra y disponible para la organización

Nombre Transición a la nube

Enunciado Enunciado Evaluar costo/beneficio de alojar las aplicaciones en la nube

Fundamento Reducción de costo de infraestructura. Integración de aplicaciones.

Repercusiones • Escalabilidad de la infraestructura en caso se requiera.

Repercusiones • Alta disponibilidad de las aplicaciones a causa de la integración.

1. Información como activo estratégico: en el Sector Salud la información es un activo

9. Evaluación de beneficios: Los proyectos de TI deben ser tratados como proyectos de

La propuesta de arquitectura empresarial para los procesos de donación y transfusión de sangre,

Proceso Negocio Datos Aplicaciones Tecnología

3.7 Objetivos Estratégicos y Metas

La Arquitectura Empresarial es la respuesta de hoy para organizar y definir los componentes

Id Proceso Función Descripción de la función

Gestionar, administrar el plan

Planificar las metas de la empresa y

Gestiona las relaciones

Recluta, capacita, apoya, gestiona el

Realiza la atención de todos los pacientes

Gestionar y atender a los pacientes en el

Gestionar y atender los pacientes

Realizar las atenciones por cirugía y

Gestionar las Realiza y gestiona las atenciones con

4.1.4 Modelo de datos del negocio

Figura – Arquitectura Línea Base - Modelo de datos de Negocio – Transfusión de Sangre

Figura - Arquitectura Línea Base – Diagrama de flujo de proceso de Registro Donación de

Figura - Arquitectura Línea Base – Diagrama de flujo de proceso de Donación de Sangre

Figura Arquitectura Línea Base – Diagrama de flujo Proceso Transfusión de Sangre

4.2.1 Modelo lógico del proceso donación de sangre

4.2.1 Modelo lógico del proceso trasfusión de sangre

ID Obejtivo de Negocio Descripcion