PDF de programación - Capítulo 4 - Servicio de identificación de personas de CORBAmed

Cap´ıtulo 4
Servicio de identificaci ´on
de personas de CORBAmed

4.1. EL OMG, Object Management Group

El OMG, es una organizaci ´on internacional sin ´animo de lu-

cro, formada por unos 800 miembros, incluyendo distribuidores de
sistemas inform ´aticos, desarrolladores de software y usuarios.

Fundado en 1989, el OMG promueve la teor´ıa y pr ´actica del pa-
radigma de orientaci ´on a objetos en el desarrollo del software, y
tiene como misi ´on la creaci ´on de est ´andares para la integraci ´on de
sistemas por medio de la orientaci ´on a objetos. Adem ´as, los obje-
tivos de la organizaci ´on tambi´en incluyen el establecimiento de una
l´ınea de industria y especificaciones sobre el manejo de objetos, que
provean de un sistema com ´un para el desarrollo de aplicaciones.

Son metas primarias la reutilizabilidad, portabilidad e interoperabi-
lidad del software orientado a objetos dentro de entornos heterog´e-
neos y distribuidos.

El ce ˜nirse a estas especificaciones har ´a posible desarrollar un en-
torno de aplicaciones heterog´eneas que abarque la mayor´ıa de pla-
taformas de hardware y sistemas operativos.

4.2. ¿Qu´e es CORBA?

CORBA, Common Object Request Broquer Arquitecture (Arqui-
tectura de Agentes de Solicitudes de Objetos Comunes), es un es-
t ´andar desarrollado por el OMG en respuesta a la necesidad de in-
teroperabilidad entre la gran gama de productos hardware y soft-
ware disponibles hoy d´ıa. En pocas palabras, CORBA permite la co-
municaci ´on entre aplicaciones con independencia de su localizaci ´on

Mar«“a «Angeles Repullo L«opez

42

Servicio de identificaci«on de personas de CORBAmed

o de qui´en las cre ´o.

CORBA ha logrado parte de su ´exito gracias a la clara separaci ´on
entre la interfaz y el objeto. La interfaz define qu´e servicios ofrece
el objeto, c ´omo invocarlos y su implementaci ´on.Se define por medio
de un lenguaje propio conocido como IDL (Interface Definition Lan-
guage), el cual posee un alto nivel de abstracci ´on, lo que le hace
independiente del entorno de desarrollo y de la plataforma.

CORBA 1.1 fu´e introducido en 1991 por el OMG junto con su IDL
e interfaces de programaci ´on de aplicaciones (API, Aplication Pro-
gramming Interfaces), que permiten a los objetos cliente y servidor
interactuar con una implementaci ´on espec´ıfica de un ORB(Object
Request Broquer), el cual permite el intercambio de informaci ´on
entre objetos locales y remotos de manera transparente para los
programadores.

CORBA 2.0, vigente desde Diciembre de 1994, define una verdadera
interoperabilidad al especificar como ORBs de diferentes fabricantes
interact ´uan entre si.

4.3. CORBAmed

Como paso posterior al desarrollo de CORBA el OMG ha puesto
en marcha una serie de grupos de trabajo con el prop ´osito de adap-
tar este est ´andar a un conjunto de sectores, entre los cuales se
encuentra el sanitario. CORBAmed es el grupo de trabajo que el
OMG ha creado para la adaptaci ´on de CORBA al sector sanitario.

La principal misi ´on de CORBAmed, es facilitar el acceso a todo tipo
de informaci ´on cl´ınica, para lo cual:

N Promueve la interoperabilidad entre diferentes sistemas sani-

tarios, pertenecientes incluso a distintas organizaciones.

N Garantiza una mayor seguridad y confidencialidad en el inter-

cambio de datos m´edicos entre organizaciones.

N Define interfaces estandarizadas orientadas a objetos entre

servicios y funciones sanitarias.

N Mejora la calidad de la atenci ´on sanitaria y reduce costes por

medio del uso de tecnolog´ıa CORBA.

Escuela superior de ingenieros de Sevilla, Abril 2005

4.4 Necesidad del servicio de identificaci«on de personas

43

4.4. Necesidad del servicio de identificaci ´on de

personas

Una persona a lo largo de su vida, puede llegar a recibir cuida-
dos m´edicos suministrados por docenas o cientos de diferentes pro-
fesionales sanitarios, la mayor´ıa de los cuales asignan de forma
independiente identificadores (IDs) a sus pacientes.

Seg ´un este patr ´on cada organizaci ´on asigna IDs que, de forma un´ıvo-
ca, identifican a pacientes dentro de su dominio local de valores de
ID. Fuera de ese sistema u organizaci ´on dichos IDs carecen de sig-
nificado.

Esta forma de manejar los IDs cubre las necesidades de almacenar
y recuperar informaci ´on dentro de la organizaci ´on local, pero no
soluciona la recopilaci ´on de informaci ´on de un paciente procedente
de alg ´un sistema externo.

Un sistema t´ıpico de informaci ´on sanitaria permite al usuario re-
alizar b ´usquedas de historiales cl´ınicos de un paciente usando algu-
na combinaci ´on de par ´ametros de identificaci ´on del mismo. Cuando
el usuario quiere obtener informaci ´on de un paciente a lmacenada
en otra organizaci ´on debe de comenzar una nueva b ´usqueda en ese
otro sistema.

En los ´ultimos a ˜nos, los cambios en el negocio de la salud, han he-
cho que el acceso al completo historial cl´ınico de un paciente sea
cada vez mas importante ya que evitar´ıa tratamientos y pruebas
m´edicas redundantes, a la vez que dif´ıcil (porque la creciente espe-
cializaci ´on de la medicina, provoca la fragmentaci ´on y distribuci ´on
de los historiales de pacientes).

Finalmente, el problema del manejo de los IDs se agrava por el he-
cho de que cada organizaci ´on trata sus datos de forma distinta. No
obstante, la actual tendencia es la migraci ´on hacia sistemas basa-
dos en la compartici ´on de datos.

Para identificar a una persona, hay gran variedad de informaci ´on a
usar como:

N Datos demogr ´aficos (direcci ´on, lugar de nacimiento, etc).

N Datos administrativos (n ´umero de la seguridad social, n ´umero

de la licencia de conducci ´on, n ´umero del DNI, etc).

Hay que tener en cuenta que la informaci ´on v ´alida para identificar
a una persona, se compone de aquellos atributos cuyo valor per-

Mar«“a «Angeles Repullo L«opez

44

Servicio de identificaci«on de personas de CORBAmed

manece constante o cambia muy lentamente a lo largo del tiempo,
ya que puede almacenarse y usarse posteriormente con fines iden-
tificativos.

4.5. Objetivos del sevicio

El servicio de identificaci ´on de personas de CORBAmed (PIDS),
maneja identificadores que cumplen las necesidades exigidas en el
´ambito sanitario. El servicio ha sido dise ˜nado para:

N Soportar de manera simult ´anea la asignaci ´on de IDs dentro de
un dominio particular y la correlaci ´on de IDs entre m ´ultiples
dominios.

N Soportar la b ´usqueda y localizaci ´on de personas, tanto en mo-
do interactivo como en no atendido, con independencia del al-
goritmo de la m ´aquina.

N Permitir que la implementaci ´on del PIDS proteja la confiden-
cialidad de las personas, bajo la amplia variedad de pol´ıticas
de privacidad y mecanismos de seguridad.

N Definir los niveles apropiados de conformidad para varios gra-
dos de sofisticaci ´on, partiendo de peque ˜nas b ´usquedas en un
solo dominio de ID hasta entre muchos dominios federados.

4.6. Modelo de referencia del PIDS

Figura 4.1: Modelo de referencia del PIDS

Escuela superior de ingenieros de Sevilla, Abril 2005

4.7 Modelo de identificaci«on del PIDS

45

Com ´unmente, un hospital maneja identificadores de persona
pertenecientes a su propio dominio de IDs, y trabaja conjuntamente
con otros centros auxiliares pertenecientes al mismo hospital, como
pueden ser laboratorios, los cuales tienen tambi´en su propio do-
minio de IDs. El hospital es el encargado de establecer correspon-
dencias entre ambos dominios de manera que se conviertan en uno
solo.

De hecho, una buena infraestructura sanitaria contar ´a con m ´ulti-
ples hospitales, laboratorios, cl´ınicas... cada uno con su propio do-
minio de IDs, por lo que una correcta gesti ´on de dominios de IDs es
fundamental.

4.7. Modelo de identificaci ´on del PIDS

Elementos b ´asicos estructurales del modelo de identificaci ´on.

Figura 4.2: Modelo de identificaci ´on del PIDS

El Dominio ID es el bloque b ´asico del modelo PIDS. Un Dominio
ID mantiene un ´unico identificador (ID) para cada persona repre-
sentada dentro del dominio. Idealmente, s ´olo hay un ID por per-
sona, pero en la realidad puede suceder que a una misma persona
se le asigne m ´as de un ID dentro del mismo dominio. Por motivos
de consistencia, dentro de un mismo dominio nunca se asignar ´a un
mismo ID a m ´as de una persona, ya que ser´ıa imposible distinguir-
las. La uni ´on del identificador y el dominio, crea un ´unico identifi-
cador para la persona.

Las especificaciones del PIDS detallan varias interfaces. Dos de las
principales dentro de un dominio ID son la interfaz IdentifyPerson
y ProfileAccess (ver figura 4.3).

La interfaz IdentifyPerson, b ´asicamente es una consulta usada para

Mar«“a «Angeles Repullo L«opez

46

Servicio de identificaci«on de personas de CORBAmed

localizar a una persona, es decir, encontrar su identificador a partir
de algunos de los atributos conocidos acerca de ella. A trav´es de la
interfaz ProfileAccess se pueden realizar consultas o actualizaciones
de los atributos de una persona si se conoce el ID de la misma. Un
“profile” o perfil es un conjunto de atributos (nombre y valor).

La unidad estructural que coordina el modelo PIDS es la Correla-
ci ´on de Dominios, que permite acceder a los perfiles de todos los
IDs de los Dominios ID participantes.

4.8. Diagrama de herencia

El PIDS se estructura como un componente con m ´ultiples in-
terfaces que pueden ser implementadas por cualquier instancia del
servicio. Cada interfaz representa un trozo de funcionalidad y es
opcional, por lo que cada implementacion del PIDS implementa s ´olo
las interfaces que necesita.

Como se aprecia en la siguiente figura, todas las interfaces heredan
de IdentificationComponent. La funcionalidad IdentificationCompo-
nent, encapsula una tabla l ´ogica con caracter´ısticas de personas
(atributos) emparejadas con un ID. De esta manera, partiendo de un
ID se pueden conocer todas las caracter´ısticas disponibles de una
persona. Un IdentificationComponent, tiene un n ´umero opcional de
interfaces que puede impleme