TOGAF
En este momento se va revisar uno de los principales marcos de referencia
utilizado en el mercado para la construcción de una Arquitectura Empresarial. Este es
TOGAF, el cual funge como una herramienta para asistir en la aceptación, creación, uso y
mantenimiento de arquitectura.
Está basado en el modelo iterativo de procesos y su modo de operar está apoyado
por mejores prácticas y un conjunto reutilizable de activos arquitectónicos existentes.
TOGAF es desarrollado y mantenido por el Foro de Arquitectura: The Open Group.
Se trata de un framework que implica a la "Arquitectura Empresarial" en todo su
concepto, ya que a pesar de que su objetivo es la implementación de sistemas operativos
de software; para lograrlo requiere de una visión amplia, que abarque los aspectos
estratégicos, empresariales y organizativos.
Este marco de arquitectura empresarial proporciona un lenguaje, un enfoque y un
conjunto de recomendaciones que abarcan todas las facetas de la arquitectura
empresarial, desde la organización y la estrategia, los negocios y la tecnología, la
planificación y la gestión del cambio.
Es por ello que las diferentes partes que lo componen son: Método, Mejores
Prácticas, Componentes, Repositorio y Gobernabilidad.
ARCHITECTURE DEVELOPMENT METHOD (ADM)
El núcleo de TOGAF es su Método de Desarrollo de Arquitectura (ADM), ya
que describe cómo obtener una Arquitectura Empresarial que sea específica para cada
organización. Su papel es proporcionar dirección a los ingenieros en varios niveles:
1. Establecer varias fases de desarrollo de arquitectura
2. Proporcionar descripción de cada fase de la arquitectura, en términos de: Objetos,
Enfoque, Entradas, Pasos a seguir y Salidas.
3. Facilitar resúmenes multi-fase que abordan la gestión de requerimientos.
El ADM comprende 3 tipo de arquitectura que son: las líneas base, la arquitectura actual
de la corporación y la arquitectura objetivo; es decir a donde se requiere llegar con la
transformación.
Fase A
Se da la visión de la Arquitectura y se comienzan a buscar soluciones a los problemas.
Fase B
Es en la que se establece la diferencia entre la línea base y objetivo de la arquitectura del
negocio.
Fase C
Se diferencian la línea base y objetivo de la Arquitectura de datos y aplicación.
Fase D
Se construye la línea base y objetivo de la Arquitectura Tecnológica.
Fase E
Es denominada de Oportunidades y Soluciones, ya que se da una versión completa del
roadmap de la arquitectura basada en las diferencias obtenidas a partir de las fases
anteriores.
Fase F
Se implementa el plan de migración.
Fase G
Se da la implementación y termina cuando la solución está completamente desplegada,
por lo que se le llama de gobierno de la implementación.
Fase H
Es la Fase de monitoreo de cambios realizados en la industria, en el negocio, en las
tecnologías, y controles de cambios solicitados para mantener la arquitectura funcional.
Competencias
Desmenuzar el marco de referencia TOGAF, mediante el estudio de su significado
y orígenes, con el fin de destacar su aplicación como marco de referencia de AE.
Examinar el Método para Desarrollar la Arquitectura (ADM), mediante el análisis
de sus fases, con el fin de deducir su función sobre el marco de referencia
TOGAF.
Conceptos principales
Concepto Significado
Marco de referencia del Open Group. Proporciona un lenguaje, un
enfoque y un conjunto de recomendaciones que abarcan todas las
TOGAF facetas de la arquitectura empresarial, desde la organización y la
estrategia, los negocios y la tecnología, y la planificación y la gestión
del cambio.
Método para el Desarrollo de la Arquitectura. Describe cómo obtener
ADM una Arquitectura Empresarial que sea específica para la organización
con el fin de responder a los requerimientos del Negocio.
Gobernabilidad Se refiere a la estructura jerárquica que el ADM debe tener.
Ayuda a definir cómo la arquitectura delimita los proyectos de
Gobierno de Implementación implementación, la supervisa y al mismo tiempo que construye,
produce un contrato de arquitectura firmado.
Se trata de la estrategia de negocio, gobierno, organización y
Arquitectura de negocio
procesos clave de la organización.
Se trata de la estructura de datos lógicos y físicos que posee una
Arquitectura de datos
organización y sus recursos de gestión de datos.
Se define como un plano (blueprint en inglés) de las aplicaciones
Arquitectura de aplicación individuales a implementar, sus interacciones y sus relaciones con
los procesos de negocio principales de la organización.
Son las capacidades de software y hardware que se requieren para
apoyar la implementación de servicios de negocio, datos y
Arquitectura tecnológica aplicación. Esto incluye infraestructura de IT, capa de mediación
(middleware en inglés), redes, comunicaciones, procesamiento y
estándares.
ANALISIS DEL CASO 3
La Arquitectura empresarial en una organización es una representación integral, lo que
conlleva a que se establezca una visión clara con objetivos y metas congruentes al
negocio de la empresa.
TOGAF es un framework ampliamente utilizado para la Arquitectura Empresarial, ya
según Sarah White ayuda a organizar el proceso de desarrollo a través de un enfoque
sistemático para reducir los errores, mantener los plazos, mantenerse dentro del
presupuesto y alinear la Tecnología de Información con las unidades de negocios; con el
fin de producir resultados de calidad.
TOGAF
Para desarrollar TOGAF existe el Método de Desarrollo de la Arquitectura, el cual permite
llevar un proceso de evaluación para el desarrollo de arquitecturas. Su característica es
que plantea 9 fases, una fase preliminar y 8 fases iterativas.
CASO
El caso que revisarás será acerca de la aplicación de TOGAF para el manejo de las
aplicaciones científicas en una universidad. Es importante que consideres que TOGAF
puede ser aplicado a todo tipo de organizaciones sin importar al ramo al que pertenezca
ya que, su ADM se puede adaptar según las necesidades puntuales de cada compañía.
CONCLUSIÓN
En este momento has revisado el marco de referencia TOGAF y su ADM, “método para el
desarrollo de la arquitectura”.
Este framework está diseñado para ayudar a las organizaciones a implementar la
tecnología de software de una manera estructurada y organizada, con un enfoque en la
gobernanza y el cumplimiento de los objetivos comerciales.
TOGAF
La bondad de este marco de Arquitectura Empresarial, es que puede ser aplicado a todo
tipo de organización. Con base en esto, a menudo para su aplicación será modificado o
ampliado el ADM para satisfacer las necesidades específicas.
Recuerda que las fases que componen el ADM, permite a los ingenieros concentrarse en
cada área de la organización, llevándola en la creación de su Arquitectura, hasta la fase
de implementación y Monitoreo.
LAS FASES QUE SON PARTE DEL ADM SON:
1. La Fase preliminar
2. La Fase A de Visión de la Arquitectura
3. La Fase B de Arquitectura del Negocio
4. La Fase C de Arquitectura de datos.
5. La Fase D de Arquitectura Tecnológica.
6. La Fase E de Oportunidades y Soluciones.
7. La Fase F de Planificación de la migración
8. La Fase G de Gobierno de la implementación
9. La Fase H de Gestión de cambios en la arquitectura
1. Beneficios de TOGAF para la Universidad Peruana Unión:
Estandarización y Mejores Prácticas: TOGAF proporciona un marco estandarizado
y probado para la arquitectura empresarial, asegurando la coherencia y eficiencia
en los procesos.
Alineación Estratégica: Facilita la alineación de la tecnología con los objetivos de
la universidad, mejorando la toma de decisiones y la planificación estratégica.
Flexibilidad y Adaptabilidad: Permite adaptar la arquitectura empresarial a los
cambios y necesidades futuras de la universidad.
Optimización de Recursos: Ayuda en la gestión eficiente de los recursos,
reduciendo costos y aumentando la eficacia operativa.
2. Preocupaciones en la Fase A de TOGAF:
La preocupación más importante en la Fase A es entender y definir claramente las
necesidades y expectativas de los stakeholders. Esto incluye identificar preocupaciones
específicas, estrategias y metas planteadas para asegurar que la arquitectura empresarial
esté alineada con los objetivos de la universidad.
3. Implementación de la Fase G - Gobierno de la Implementación:
Como responsable del proyecto, implementaría la Fase G estableciendo un marco de
gobierno claro, definiendo roles y responsabilidades, y estableciendo procesos de
monitoreo y control para asegurar que la implementación de la arquitectura se realice
según lo planeado y cumpla con los requisitos establecidos.
Conclusión:
La implementación de TOGAF en la Universidad Peruana Unión puede traer beneficios
significativos en términos de alineación estratégica, optimización de recursos y
adaptabilidad a cambios futuros. La Fase G es crítica para asegurar que la
implementación se adhiera a los planes y cumpla con los objetivos establecidos dentro de
la institución.
Referencias:
The Open Group. (2018). TOGAF® Version 9.2. Recuperado desde
https://pubs.opengroup.org/architecture/togaf9-doc/arch/. Lankhorst, M. (2017). Enterprise
Architecture at Work: Modelling, Communication and Analysis. Springer.
Rodolfo Martinez Aguilera. (2024). Arquitectura tecnológica empresarial. RMA, 1.
Marco de referencia del Open Group que proporciona un lenguaje, un
enfoque y un conjunto de recomendaciones que abarcan todas las
facetas de la arquitectura empresarial, desde la organización y
la estrategia, los negocios y la tecnología, y la planificación y la
gestión del cambio:
Seleccione una:
Zachman
TOGAF
DoDAF
ADM
Retroalimentación
Su respuesta es correcta.
La respuesta correcta es: TOGAF
Pregunta 2
Correcta
Puntúa 1.00 sobre 1.00
Señalar con bandera la pregunta
Texto de la pregunta
La estructura de datos lógicos y físicos que posee una organización y sus
recursos de gestión de datos:
Seleccione una:
Arquitectura de aplicación
Arquitectura de negocio
Arquitectura tecnológica
Arquitectura de datos
Retroalimentación
Su respuesta es correcta.
La respuesta correcta es: Arquitectura de datos
Pregunta 3
Correcta
Puntúa 1.00 sobre 1.00
Señalar con bandera la pregunta
Texto de la pregunta
Ayuda a definir cómo la arquitectura delimita los proyectos de
implementación, la supervisa y al mismo tiempo que construye, produce
un contrato de arquitectura firmado:
Seleccione una:
Gobierno de implementación
Gobierno de información
Gobierno de aplicación
Gobierno de datos
Retroalimentación
Su respuesta es correcta.
La respuesta correcta es: Gobierno de implementación
Pregunta 4
Correcta
Puntúa 1.00 sobre 1.00
Señalar con bandera la pregunta
Texto de la pregunta
Las capacidades de software y hardware que se requieren para apoyar
la implementación de servicios de negocio, datos y aplicación, que
incluyen infraestructura de IT, capa de mediación (middleware en
inglés), redes, comunicaciones, procesamiento y estándares:
Seleccione una:
Arquitectura tecnológica
Arquitectura de datos
Arquitectura de negocio
Arquitectura de aplicación
Retroalimentación
Su respuesta es correcta.
La respuesta correcta es: Arquitectura tecnológica
Pregunta 5
Correcta
Puntúa 1.00 sobre 1.00
Señalar con bandera la pregunta
Texto de la pregunta
Es la estrategia de negocio, gobierno, organización y procesos clave de
la organización:
Seleccione una:
Arquitectura tecnológica
Arquitectura de datos
Arquitectura de aplicación
Arquitectura de negocio
Retroalimentación
Su respuesta es correcta.
La respuesta correcta es: Arquitectura de negocio
OBJETIVOS DE APRENDIZAJE
Explicar el contenido teórico de TOGAF.
Presentar el caso de estudio titulado Diseño de un modelo de arquitectura
empresarial para publicaciones científicas basado en ADM - TOGAF 9.0.
Examinar el caso de forma colaborativa a través de una lluvia de ideas.
Brindar herramientas para la resolución del análisis de caso
¿Qué es TOGAF?
The Open Group Architecture Framework Metodología y Framework de
Enterprise Architecture (EA) más utilizado por las organizaciones a nivel
mundial para mejorar la eficiencia empresarial.
Estándar de EA más destacado y confiable, asegurando normas
coherentes, métodos, y la comunicación entre los profesionales de EA (Standard
de Facto).
TOGAF evita a los profesionales estar atrapados por métodos propietarios
(Open Standard), ayuda a utilizar los recursos de manera más eficiente y eficaz, y
lograr un mayor retorno de la inversión.
En el origen de TOGAF está ADM (Architecture Development Method), un método
genérico para desarrollar y administrar el ciclo de vida de una arquitectura empresarial.
ADM comprende tres tipos de arquitecturas:
La arquitectura de línea base, que es la arquitectura actual de la empresa.
La arquitectura objetivo, que es a donde se pretende llegar tras la transformación.
La arquitectura de transición, que son las arquitecturas intermedias entre la línea base y la
objetivo.
LA ARQUITECTURA SE MODELA EN CUATRO DOMINIOS
Negocio: estrategia de negocios, la gobernabilidad, la estructura y los procesos clave de
la organización.
Aplicación: plano para cada uno de los sistemas de aplicación que se requiere implantar.
Datos: estructura de los datos físicos y lógicos de la organización.
Tecnología: estructura de hardware, software y redes.
https://scielo.conicyt.cl/pdf/infotec/v28n4/art11.pdf
ARCHITECTURE DEVELOPMENT METHOD (ADM)
ADM es una aplicación de TOGAF usada para el desarrollo de arquitectura empresarial
de negocios.
Este proceso se centra en encontrar las necesidades de los procesos de negocios y de
las tecnologías de la información de cualquier tipo de organización.
QUE PROPORCIONA ADM?
Un conjunto de puntos de vista arquitecturas (datos, aplicaciones)
Directrices sobre herramientas para desarrollo de la arquitectura Enlaces a estudios de
casos prácticos
Un método para la gestión de requisitos
El proceso es iterativo y cíclico. Cada paso inicia con la verificación de los requerimientos.
¿QUE PROPORCIONA ADM?
El ADM es un proceso iterativo:
1. A lo largo de todo el proceso
2. Entre las fases
3. Dentro de las fases
Para cada iteración, volverá a considerar:
1. Ámbito de aplicación
2. Detalle
Caso de estudio: Diseño de un modelo de arquitectura empresarial para
publicaciones científicas basado en ADM - TOGAF 9.0
Introducción
El propósito de esta investigación es proponer un modelo de arquitectura empresarial
para publicaciones científicas basado en el marco de trabajo TOGAF 9.0 y utilizando el
lenguaje de modelado Archimate 3.1, en la Universidad Peruana Unión (UPeU) enfocado
al eje de investigación, sección de publicación de libros y artículos.
En ese sentido, se consideraron los procesos e indicadores que establece el plan
estratégico.
PROCESOS DE PUBLICACIONES CIENTÍFICAS
Para este estudio se consideró como caso a la UPeU y los participantes fueron docentes
y administradores relacionados con la investigación científica, quienes participaron como
evaluadores y validadores del modelo propuesto.
La información se colectó a través de una guía de entrevista semi estructurada, que
fueron aplicadas a interlocutores válidos respecto del proceso de publicación científica; en
dicho instrumento se formularon ítems para comprender elementos de la gestión
estratégica como misión, visión.
También se utilizaron fichas para el acopio de información mediante la técnica de revisión
documental. Los documentos que se revisaron fueron documentos de gestión como Plan
estratégico, Plan operativo anual (POA), Reglamento general de investigación, estándares
de calidad del SINEACE.
PROCESOS DE PUBLICACIONES CIENTÍFICAS
Fase preliminar.
En esta fase se realizó un análisis general de la Universidad Peruana Unión (UPeU),
institución educativa confesional de una denominación religiosa en el Perú; cuenta con
una sede principal en la ciudad de lima y dos fíales (Juliaca y Tarapoto) y de la visión y
misión de la institución.
Fase A. Visión de la arquitectura
En esta fase se identificaron concerns; se tomó en cuenta el statu quo del contexto de la
UPeU en materia de investigación universitaria en el Perú, así como de entrevistas
efectuadas a stakeholders tales como el director general de investigación, director de
escuelas profesionales, docentes investigadores y estudiantes, los resultados ayudaron a
identificar la preocupación más relevante que fluyen en el cumplimiento de la visión
institucional.
PROCESOS DE PUBLICACIONES CIENTÍFICAS
PROCESOS DE PUBLICACIONES CIENTÍFICAS
Fase B. Arquitectura de negocio
En esta fase se elaboraron los diagramas de procesos AS-IS y TO-BE que dan la
capacidad de lograr la meta establecida en relación a los objetivos organizacionales; para
el estudio se consideró los siguientes procesos: proceso de publicación de artículos en
revistas de la UPeU, proceso de publicación de artículos en revistas externas, proceso de
publicación de libros y financiados por la UPeU, proceso de publicación de libros
autofinanciados, Para efectos de este articulo solo ser presentará el proceso de
publicaciones en revistas externas.
PROCESOS DE PUBLICACIONES CIENTÍFICAS
Fase B. Arquitectura de negocio En esta fase se elaboraron los diagramas de procesos
AS-IS y TO-BE
PROCESOS DE PUBLICACIONES CIENTÍFICAS
Fase B. Arquitectura de negocio
En esta fase se elaboraron los diagramas de procesos AS-IS y TO-BE
Procesos de publicaciones científicas
Fase C y D. Arquitectura de Servicios y Tecnológica
Publicación de artículos en revistas– Actividad efectuar revisión En esta fase se desarrolló
la arquitectura de la capa de aplicaciones, datos y tecnológica; como se puede ver la
actividad efectuar revisión del proceso de publicación de artículos requerirá 2 servicios de
aplicación que son Realizar revisión externa y realizar revisión interna estas 2 se
encontrarán soportadas por una función de aplicación llamada Gestionar revisiones el
cual requiere de los objetos artículo, contenido y revisiones, los cuales permitirán dar
persistencia a los datos procesados en la función de aplicación, el cual interactúa de
manera externa a través de un componente de publicaciones el cual es presentado a
través de un acceso web y un acceso móvil; finalmente la tecnología requerida será un
Enterprise Service Bus (ESB) el cual funcionará como middleware entre los servidores
oracles HP, Redhat y un servidor Backup.
PROCESOS DE PUBLICACIONES CIENTÍFICAS
Fase E y F. ROADMAP
La última fase consistió en definir la planificación de la arquitectura, esta se desarrolla a
través de un Roadmap u hoja de ruta que presenta en el tiempo como se irá
implementando la tecnología dentro de la organización.
ANTECEDENTES
El Hospital Italiano de Buenos Aires es un Hospital Universitario de alta complejidad con
más de 150 años de vida, que cuenta con una infraestructura hospitalaria de 750 camas
de internación, distribuidas en 2 hospitales, y 23 centros de atención ambulatoria
distribuidos por la Ciudad de Buenos Aires y áreas metropolitanas.
Posee un sistema de Medicina Prepaga llamado Plan de Salud que tiene 150.000
afiliados bajo cuidado médico. A la fecha realiza 2.400.000 consultas en el ámbito
ambulatorio y más de 36 000 internaciones anualmente.
Desde 1998 ha implementado de forma gradual un Sistema de Información en Salud
integral, incluyendo registros electrónicos en diferentes niveles de atención (Historia
Clínica, Electrónica Ambulatoria, de Internación, de Emergencias), sistemas
administrativos, sistemas de agendamiento, sistema de farmacia, etc.
Diversos estándares han sido implementados, incluyendo HL7, CDA versión 2 y un
servicio terminológico basado en SNOMED con diversos vocabularios de salida (ICD-
9CM, ICD-10, IPCP).
PROYECTO PORTAL PERSONAL DE SALUD (POPES)
En el año 2006 el Hospital Italiano comenzó el Proyecto Portal Personal de Salud
(PoPeS) destinado a brindar nuevas funcionalidades a las personas que son atendidas
diariamente en el Hospital.
El PoPeS consiste en un RMP (Registro Médico Personal, del inglés Personal Health
Record) Ligado a la Historia Clínica Electrónica (HCE) hospitalaria, llamada Itálica.
El proyecto “Portal Personal de Salud” (PoPeS) consiste en brindar servicios y acceso a
datos unificados en múltiples aplicaciones, permitiendo a los pacientes que son atendidos
en la red de salud del Hospital Italiano de Buenos Aires interactuar o consultar su
información médica o administrativa.
El PoPeS es una aplicación Web que presenta al usuario, en una interfaz única,
contenidos y funcionalidades obtenidas del sistema de información clínico.
Los pacientes pueden acceder a consultar y actualizar la información demográfica
ingresada en el padrón y aquellos que son socios del Plan de Salud (el prepago
hospitalario) pueden descargar la factura tributaria y cambiar las preferencias de envío de
las mismas.
A su vez, el sistema permite consultar los turnos agendados en el sistema unificado de
agendamiento y realizar búsquedas de profesionales médicos en la cartilla Web.
Referente al aspecto clínico, los pacientes pueden acceder a ver los fármacos prescritos
por sus médicos a través de la Historia Clínica Electrónica, el stock disponible de los
mismos en las Farmacias de la Red Interna y realizar pedidos a domicilio (delivery).
ARQUITECTURA
Las funciones y utilidades que el paciente puede consultar en el PoPeS, son procesos
que están definidos en múltiples sistemas clínicos. Para la construcción de las funciones,
se realizó una abstracción de estos procesos y se desarrollaron como servicios Web, que
una vez publicados pueden ser consumidos por distintas aplicaciones.
Los Servicios Web representan la verdadera reutilización de código. El desarrollo
orientado a objetos forma parte de un cambio radical en el proceso de desarrollo de
software.
ARQUITECTURA
El desarrollador ya no tiene que codificar cada función de una pieza de software,
simplemente accede a una interfaz que contiene el código subyacente.
La interfaz es el elemento clave en el desarrollo de software basado en servicios,
brindando acceso a una colección de posibles funciones que pueden ser instanciadas por
la unidad de servicios.
En términos prácticos, esto significa que realmente el tiempo de trabajo de codificación de
una pieza de software se realiza sólo una vez. Después de eso, el código se convierte en
un objeto que puede ser invocado sin necesidad de una nueva codificación.
LA SEGURIDAD ES OTRO GRAN FACTOR DE IMPORTANCIA EN LA ADOPCIÓN DE
UNA TECNOLOGÍA SOA (9).
La implementación de esta tecnología sin la aplicación de normas y protocolos de
seguridad la convierten en una plataforma totalmente insegura, dado que los servicios
Web utilizan protocolos de Internet para el envío y recepción de mensajes a través de un
navegador.
En general los mensajes pasan sin control a través de un firewall, haciendo que los
servicios Web están muy expuestos a las violaciones de seguridad, contenido e identidad.
Dentro de las medidas de seguridad adoptadas se definió la separación de ambientes
tecnológicos. Esta separación consiste en implementar dos servidores de aplicación: un
servidor que esté montado en la red pública (Internet), y otro servidor que esté montado
en la red privada (LAN HI – Local Area Network del Hospital Italiano).
De esta forma las peticiones HTTP generadas desde los navegadores de los usuarios son
resueltas en la red pública, y los servidores de aplicación tanto público como privado se
comunican entre sí cuando la aplicación lo demande, utilizando un protocolo encriptado
SSL (Secure Socket Layer).
Además, se implementó la encriptación de los mensajes XML por intermedio del uso de la
infraestructura de clave pública/privada y firma digital.
La firma digital es un número que tiene la capacidad de capturar la identidad y el
contenido de un mensaje, procesando la información a través de algoritmos especiales.
Cuando el sistema receptor recibe el mensaje y adjunta la firma digital, se puede usar la
clave para verificar que:
El usuario es el verdadero autor del mensaje (autenticación).
El mensaje SOAP (Simple Object Access Protocol) no ha sido alterado en tránsito.
La aplicación se encuentra dividida en dos capas:
1. La primera capa es una aplicación que se encuentra implementada en la parte pública
del modelo tecnológico y tiene como fin servir de interfaz gráfica de la aplicación. En
esta capa encontramos las funciones que los usuarios pueden realizar, en forma de
interfaces java
2. La segunda capa del modelo tecnológico, se encuentra implementada en la parte
privada del modelo. Está ubicada dentro de la LAN del Hospital Italiano de Buenos
Aires, y se comunica con los distintos modelos de información. Esta capa es la
responsable de manejar la lógica y los procesos. Aquí se publican todos los servicios
Web que dan soporte a las funciones de usuarios.
APLICACIÓN Y FUNCIONES
La aplicación PoPeS contiene distintos tipos de funciones que se obtienen de la
abstracción del sistema de información clínico.
El sistema permite desarrollar funcionalidades con diferentes opciones según se utilice el
rol de usuario médico (se obtiene la visión del médico operando desde la Historia Clínica
Electrónica) o utilizando el rol paciente (se accede a la funcionalidad a través del Portal
Personal de Salud).
La pantalla de presentación del PoPeS, es accedida desde el sitio público del Hospital
Italiano (HI). El paciente accede a la aplicación por intermedio de un banner (Figura 2).
La página inicial del PoPeS (Figura 3) contiene básicamente un sistema genérico de
noticias e información para los pacientes además del sistema de acceso a las funciones
del portal.
Para poder utilizar el sistema, los pacientes deben estar en el padrón del Hospital Italiano
y registrarse en la página de inicio.
El proceso de registración consta de varios pasos que validan los datos ingresados con
los datos existentes en el padrón de personas (Master Patient Index), y a su vez requiere
la validación de una cuenta de correo electrónico, y la generación de una contraseña
segura.
Por un lado, tenemos al usuario médico, operando la Historia Clínica Electrónica. Desde
el módulo de prescripción farmacológica de la Historia Clínica Ambulatoria administra la
prescripción de medicación para el paciente (Figura 4).
Por intermedio de este módulo, el médico prescribe, suspende, modifica y receta la
administración de fármacos (creando créditos, en la farmacia interna, de ese fármaco para
el paciente).
La funcionalidad le permite conocer sus prescripciones, como así también solicitar, por
intermedio de la aplicación el envío de medicamentos a su domicilio (opción delivery),
siempre y cuando tenga créditos de fármacos disponibles para consumir.
Además, puede obtener en línea el stock disponible del medicamento en las Farmacias
internas del HI (Figura 5).
CONCLUSIÓN
En los últimos tiempos cada vez son más las empresas que comenzaron a utilizar la
tecnología SOA emergente para implementar servicios Web como una forma estándar de
diseñar piezas de software reutilizable e interoperable entre plataformas. La
interoperabilidad es uno de los avances más significativos en entornos de software
distribuidos.
Su uso permitió componer piezas de software reutilizable y ensamblarlos para construir
una nueva aplicación que utiliza distintas fuentes de información.
En nuestro caso en particular, la tecnología resultó ser propicia para el tipo de proyecto
desarrollado, permitiendo la reutilización de todos los objetos desarrollados en el modelo
de información clínico (HCE).
Se debe tener en cuenta que es necesario el diseño de una plataforma tecnológica
apropiada para soportar las debilidades de seguridad informática que la tecnología SOA
contiene.
El Proyecto PoPeS tiene como objetivo brindar nuevas funcionalidades clínicas a los
pacientes en los próximos años (visualización y carga de problemas; visualización de
resultados de laboratorio y de exámenes complementarios; acceso a bases de
conocimiento orientadas a pacientes; sistemas de comunicación electrónica con
profesionales tratantes, etc.).
