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

Imágen de pdf Capítulo 4 - Servicio de identificación de personas de CORBAmed

Capítulo 4 - Servicio de identificación de personas de CORBAmedgráfica de visualizaciones

Publicado el 28 de Junio del 2018
284 visualizaciones desde el 28 de Junio del 2018
83,5 KB
12 paginas
Creado hace 14a (24/04/2005)
Capítulo 4
Servicio de identificaci ón
de personas de CORBAmed

4.1. EL OMG, Object Management Group

El OMG, es una organizaci ón internacional sin ánimo de lu-

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

Fundado en 1989, el OMG promueve la teoría y pr áctica del pa-
radigma de orientaci ón a objetos en el desarrollo del software, y
tiene como misi ón la creaci ón de est ándares para la integraci ón de
sistemas por medio de la orientaci ón a objetos. Adem ás, los obje-
tivos de la organizaci ón también incluyen el establecimiento de una
línea de industria y especificaciones sobre el manejo de objetos, que
provean de un sistema com ún para el desarrollo de aplicaciones.

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

El ce ñirse a estas especificaciones har á posible desarrollar un en-
torno de aplicaciones heterogéneas que abarque la mayoría de pla-
taformas de hardware y sistemas operativos.

4.2. ¿Qué es CORBA?

CORBA, Common Object Request Broquer Arquitecture (Arqui-
tectura de Agentes de Solicitudes de Objetos Comunes), es un es-
t ándar 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 ón entre aplicaciones con independencia de su localizaci ón

Mar«“a «Angeles Repullo L«opez

42

Servicio de identificaci«on de personas de CORBAmed

o de quién las cre ó.

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

CORBA 1.1 fué introducido en 1991 por el OMG junto con su IDL
e interfaces de programaci ón de aplicaciones (API, Aplication Pro-
gramming Interfaces), que permiten a los objetos cliente y servidor
interactuar con una implementaci ón específica de un ORB(Object
Request Broquer), el cual permite el intercambio de informaci ón
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 úan 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 ósito de adap-
tar este est ándar 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 ón de CORBA al sector sanitario.

La principal misi ón de CORBAmed, es facilitar el acceso a todo tipo
de informaci ón 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édicos entre organizaciones.

N Define interfaces estandarizadas orientadas a objetos entre

servicios y funciones sanitarias.

N Mejora la calidad de la atenci ón 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 ón de

personas

Una persona a lo largo de su vida, puede llegar a recibir cuida-
dos médicos 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 ún este patr ón cada organizaci ón 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 ón dichos IDs carecen de sig-
nificado.

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

Un sistema típico de informaci ón sanitaria permite al usuario re-
alizar b úsquedas de historiales clínicos de un paciente usando algu-
na combinaci ón de par ámetros de identificaci ón del mismo. Cuando
el usuario quiere obtener informaci ón de un paciente a lmacenada
en otra organizaci ón debe de comenzar una nueva b úsqueda en ese
otro sistema.

En los últimos a ños, 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édicas redundantes, a la vez que difícil (porque la creciente espe-
cializaci ón de la medicina, provoca la fragmentaci ón y distribuci ón
de los historiales de pacientes).

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

Para identificar a una persona, hay gran variedad de informaci ón a
usar como:

N Datos demogr áficos (direcci ón, lugar de nacimiento, etc).

N Datos administrativos (n úmero de la seguridad social, n úmero

de la licencia de conducci ón, n úmero del DNI, etc).

Hay que tener en cuenta que la informaci ón v álida 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 ón de personas de CORBAmed (PIDS),
maneja identificadores que cumplen las necesidades exigidas en el
ámbito sanitario. El servicio ha sido dise ñado para:

N Soportar de manera simult ánea la asignaci ón de IDs dentro de
un dominio particular y la correlaci ón de IDs entre m últiples
dominios.

N Soportar la b úsqueda y localizaci ón de personas, tanto en mo-
do interactivo como en no atendido, con independencia del al-
goritmo de la m áquina.

N Permitir que la implementaci ón 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 ón, partiendo de peque ñas b úsquedas 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 únmente, 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én 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 á con m últi-
ples hospitales, laboratorios, clínicas... cada uno con su propio do-
minio de IDs, por lo que una correcta gesti ón de dominios de IDs es
fundamental.

4.7. Modelo de identificaci ón del PIDS

Elementos b ásicos estructurales del modelo de identificaci ón.

Figura 4.2: Modelo de identificaci ón del PIDS

El Dominio ID es el bloque b ásico del modelo PIDS. Un Dominio
ID mantiene un único identificador (ID) para cada persona repre-
sentada dentro del dominio. Idealmente, s ólo hay un ID por per-
sona, pero en la realidad puede suceder que a una misma persona
se le asigne m ás de un ID dentro del mismo dominio. Por motivos
de consistencia, dentro de un mismo dominio nunca se asignar á un
mismo ID a m ás de una persona, ya que sería imposible distinguir-
las. La uni ón del identificador y el dominio, crea un único 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 ásicamente 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és 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 ón 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 últiples 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 ólo
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 ógica 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 úmero opcional de
interfaces que puede impleme
  • Links de descarga
http://lwp-l.com/pdf12186

Comentarios de: Capítulo 4 - Servicio de identificación de personas de CORBAmed (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios
Es necesario revisar y aceptar las políticas de privacidad