Sueiidiss Uy Lin 001

SOCIEDAD URUGUAYA DE ESTANDARIZACIÓN, INTERCAMBIO E INTEGRACIÓN DE DATOS E INFORMACIÓN DE SERVICIOS DE SALUD
SEGURIDAD DE DATOS EN EL SECTOR SALUD URUGUAYO

................................................................................................................................................
SUEIIDISS-UY-LIN-001 | Version 1.0
SUEIIDISS-UY-LIN-001 | SEGURIDAD DE DATOS EN EL SECTOR SALUD URUGUAYO 2 de 25
rev. 21 jul 2006.
Tabla de contenidos
1 SEGURIDAD DE DATOS EN EL SECTOR SALUD URUGUAYO...................................4
1.1 SUBCOMITÉ TÉCNICO DE FIRMA ELECTRÓNICA.............................................. 4
1.2 Registro de Cambios....................................................................................... 4
2 INTRODUCCIÓN................................................................................................... 5
3 ANTECEDENTES.................................................................................................... 6
3.1 Legislación nacional........................................................................................ 6
3.2 Estándares Internacionales.............................................................................. 7
3.2.1 ISO............................................................................................................ 7
3.2.1.1 TC215/WG4.........................................................................................7
3.2.1.2 ISO/TS 17090 Infraestructura de Clave Privada (PKI)..............................8
3.2.1.3 17090-1:2002 PKI / Parte 1 : Introducción........................................... 8
3.2.1.3.1 Aplicaciones de comunicación con seguridad PKI entre actores de la
Salud...............................................................................................................
3.2.1.3.2 Funciones de un PKI dentro de un sistema informatizado de salud....
3.2.1.3.3 Criptografía......................................................................................
3.2.1.3.4 PKI...................................................................................................
3.2.1.3.5 Modelos de interoperabilidad...........................................................
3.2.1.4 17090-2:2002 PKI / Parte 2: perfiles PKI............................................. 10
3.2.1.5 17090-3:2002 PKI / Parte 3: Regulación de CA...................................11
3.2.1.6 ISO17090-3 7.3.1.7........................................................................... 11
3.2.1.7 Resumen sobre Certificados Digitales................................................. 11
3.2.2 HL7......................................................................................................... 12
3.2.2.1 MLLP................................................................................................. 12
3.2.2.2 ebXML...............................................................................................13
3.2.2.3 Web Services Profile........................................................................... 14
3.2.3 IHE.......................................................................................................... 15
3.2.3.1 XDP................................................................................................... 16
3.2.3.2 ATNA.................................................................................................17
3.2.4 DICOM....................................................................................................17
3.3 Situación actual de la Tecnología disponible.................................................. 19
3.3.1 Certificados Digitales............................................................................... 19
3.3.1.1 Cámara de Comercio......................................................................... 20
3.3.1.2 ABITAB.............................................................................................. 20
3.3.1.3 El Correo............................................................................................20
3.4 Necesidades Actuales....................................................................................20
3.5 Casos de Uso................................................................................................ 20
rev. 21 jul 2006.
4 PERFILES DE USO CONTEMPLADOS EN LAS RECOMENDACIONES....................... 22

4.1 Escenarios.....................................................................................................22
4.1.1 Interacción entre Sistemas Informáticos................................................... 22
4.1.2 Sistema Interactivo.................................................................................. 22
4.1.3 Envío de Documentos..............................................................................22
5 RECOMENDACIONES..........................................................................................23
5.1 Introducción a los Estándares........................................................................ 23
5.2 Seguridad en la Capa de Transporte.............................................................. 23
5.3 Certificados Digitales para Organizaciones.....................................................23
5.4 Seguridad en el envío de documentos........................................................... 24
6 REFERENCIAS......................................................................................................25
rev. 21 jul 2006.
SEGURIDAD DE DATOS EN EL SECTOR SALUD URUGUAYO

.....................................................................................................................................
Versión 1.0 – 21 de Julio de 2006
SUBCOMITÉ TÉCNICO DE FIRMA ELECTRÓNICA
Autores:
° Julio Carrau
° Doris Correa
° Carlos Díaz del Pino
° Patricia Diaz Arnesto
° Gonzalo Echagüe
° Jacques Fauquex
° Andrés Ghigliazza
° Gustavo A. Güira
° Selene Indarte
° Sergio Koyounian
° Pablo Martínez
° Ciro Mondueri
° Gustavo Perez
° Gustavo Tejera
Registro de Cambios
Version 1.0
° Versión inicial del documento
rev. 21 jul 2006.
INTRODUCCIÓN
.....................................................................................................................................
Las premisas que definen la seguridad en el intercambio de información en el sector

salud son:
° Confidencialidad : garantizar que la información enviada sólo estará disponible para
el emisor y el receptor.
° Identificación : garantizar la identidad de emisor y receptor.
° Autenticación : confirmar la veracidad de la identidad del emisor y receptor.
° Integridad : asegurar que la información enviada es transmitida sin modificarse.
° Compatible a futuro con estándares internacionales (HL7, IHE, DICOM, ISO y otros).
La necesidad de intercambio de información entre los sistemas de salud es una realidad

en el mundo. En nuestro país, forma parte de los procesos administrativos y
asistenciales habituales.
La información involucrada en estos intercambios, pasa por datos personales, datos

médicos (historia clínica, resultados de exámenes, interconsultas, etc.), datos
económicos (órdenes de pago, autorizaciones, etc.). Todos estos datos tienen
implicancias personales y organizacionales que requieren definiciones específicas en los
aspectos que hacen a la seguridad.
La SUEIIDISS, en cumplimiento de sus objetivos fundacionales ha comenzado un

estudio exhaustivo de esta temática, de forma de poder generar recomendaciones de
seguridad que cumplan el doble objetivo de estar alineadas con los estándares
internacionales y que se adapten a las necesidades y realidades de nuestro medio.
rev. 21 jul 2006.
ANTECEDENTES
.....................................................................................................................................
Legislación nacional
En Uruguay desde 1988 hay elementos del derecho positivo que apuntan a dar un
marco jurídico adecuado a los cambios tecnológicos en el área de la informática. A
modo de resumen listamos los elemtos relevantes:
° Ley 16002 1988-11-25 : Reconocimiento del documento electrónico entre
dependencias oficiales
° Ley 16060 1990-01-05 : Documento electrónico en materia de libros y contabilidad
de las sociedades comerciales
° Decreto 500/991 1991-09-27 : "cualquier medio hábil de comunicación" podrá
implementarse para el mejor cumplimiento de los servicios de la Administración
Pública
° Ley 16226 1991-10-20 : permitió al TCA practicar notificaciones procesales por
medios electrónicos o de similares características
° ley 16713 1995-09-03 : Cheques del BPS podrá sustituirse la firma autógrafa por
signos y contraseñas electrónicas
° Ley 16736 1996-01-05 : Equipara los medios informáticos a los convencionales,
reconoce la validez jurídica y les otorga el mismo valor probatorio. Consagra la firma
electrónica
° Decreto 65/998 1998-03-10 : Reglamenta el procedimiento administrativo
electrónico, reconoce la calidad de instrumento público del documento electrónico,
define firma electrónica y digital
° Decreto 312/998 1998-11-03 : Establece el uso de la firma electrónica para el
Documento Unico Aduanero
° Ley 17243 2000-06-29 : Segunda Ley de Urgencia regula la firma electrónica y digital
y consagra la prestación de servicios de certificación.
° Ley 1729 2001-01-25 : Emisión de certificados de firma electrónica desde Zonas
Francas
° Decreto 83/001 2001-03-08 : Determina medios técnicos de almacenamiento,
reproducción y transmisión telemática de documentos electrónicos
° Decreto 282/003 2003-09-17 : Reglamenta el uso de la firma electrónica y digital
° Decreto Ley 2003-09-30 : Disposiciones relativas a la historia clínica electrónica de
cada persona
° Ley 17.838 2004-09-24 : Protección de datos personales de informes comerciales
rev. 21 jul 2006.
Estándares Internacionales
ISO
ISO agrupa 25 países miembros y 15 observadores. En América del Sur, solamente

Argentina es observadora.
El comité técnico ISO 215 (CENT TC 215) trata de la informática de la salud. Está
subdividido en 8 grupos de trabajo (WG):
° TC 215/WG 1 Data structure
° TC 215/WG 2 Data interchange
° TC 215/WG 3 Semantic content
° TC 215/WG 4 Security
° TC 215/WG 5 Health cards
° TC 215/WG 6 Pharmacy and medicines business
° TC 215/WG 7 Devices
° TC 215/WG 8 Business requirements for Electronic Health Records
TC215/WG4
Este grupo de trabajo publicó en particular:

° ISO/TS 17090-1:2002 [1] Public key infrastructure -- Part 1: Framework and overview
° ISO/TS 17090-2:2002 [2] Public key infrastructure -- Part 2: Certificate profile
° ISO/TS 17090-3:2002 [3] Public key infrastructure -- Part 3: Policy management of
certification authority
° ISO/TR 21089:2004 [4] Trusted end-to-end information flows
° ISO 18232:2006 [5] Messages and communication -- Format of length limited
globally unique string identifiers
Los 3 documentos sobre PKI están en curso de revisión. Están disponibles en su etapa
de revisión al 2006-01-27 bajo los nombres ISO/DIS 17090-1, ISO/DIS 17090-2,
ISO/DIS 17090-3, con versión definitiva para el 2007-02-06. Esta revisión está prevista
desde la publicación inicial en 2002, porque varios países (Canada, Australia, etc.) ya
tenían planes de adoptar PKI para su informática de la salud y necesitaban un marco
estándar de forma urgente. El TC215 publicó entonces una primera versión y se dió un
lapso de 3 años, antes de revisarlo para transformarlo en un estándar internacional
rev. 21 jul 2006.
completo.
ISO/TS 17090 Infraestructura de Clave Privada (PKI)
Las 3 partes de este documento empiezan con 4 capítulos iguales: (1) Enfoque, (2)
Normativas de Referencia, (3) Términos y Definiciones, (4) Siglas. Las definiciones
presentes no tienen carácter normativo, no se solapan con las definiciones de HL7 o
CEN, y sólo sirven para entender el propio texto del estándar OSI sobre PKI. Las siglas
estandardizadas son:
° CA Certification Authority
° CP Certificate Policy
° CPS Certification Practice Statement
° CRL Certificate Revocation List
° PKC Public Key Certificate
° PKI Public Key Infrastructure
° RA Registration Authority
° TTP Trusted Third Party
17090-1:2002 PKI / Parte 1 : Introducción

Aplicaciones de comunicación con seguridad PKI entre actores de la Salud
° Mail electrónico seguro.
° Pedidos de acceso a información sobre pacientes dirigidos a los sistemas centrales de
un hospital a través de aplicaciones usadas por profesionales de la salud vinculados a
la comunidad.
° Pedidos de acceso a información sobre pacientes dirigidos a los sistemas centrales de
un hospital a través de aplicaciones usadas dentro del hospital. Los sistemas incluyen
administración de pacientes, administración de la clínica, patología, radiología, dietas
y otros sistemas de información relacionados.
° Otros sistemas, acorde a reglamentos locales.
° Aplicaciones de facturación que requieren autenticación para los pacientes,
proveedores de servicios de salud, seguros, todo sin repudio, y con integridad de los
mensajes y confidencialidad.
° Aplicaciones de tele-imagenología que requieren un vínculo confiable entre una
imagen y la identidad de un paciente, así como la autenticación de un profesional de
la salud.
° Aplicaciones de control con acceso remoto que necesitan verificar la autenticidad,
confidencialidad e integridad.
° Aplicaciones de prescripción electrónica que necesitan de los servicios de seguridad
rev. 21 jul 2006.
de un PKI.
° Documentos de consentimiento de parte de pacientes firmados digitalmente.
° Servicios de transcripción a través de fronteras nacionales.
Funciones de un PKI dentro de un sistema informatizado de salud
Autenticación, firma electrónica, integridad (en el sector de la salud es importante

separar la autenticación de la encriptación), control de acceso, confidencialidad,
autorización.
Criptografía
En la criptografía simétrica se usa una clave secreta para encriptar un texto legible,
transformándolo en criptograma ilegible. El criptograma puede ser descifrado con la
misma clave secreta, usando un algoritmo inverso al inicial.
En la criptografía asimétrica (con clave pública, descrita por Whitfiled Diffie y Martin
Hellman en 1976) se usan dos claves diferentes, la pública y la privada. Cualquier
persona puede encriptar el mensaje con la clave pública, pero no puede descifrarla
después. Solamente la persona con la clave privada lo puede realizar. Tampoco es
posible deducir la clave privada desde la clave pública y viceversa. Entonces, la clave
pública puede ser difundida sin comprometer la privacidad.
El algoritmo asimétrico puede ser usado también en el otro sentido: el texto es

encriptado mediante la clave privada y descifrado mediante la clave pública. Esta
versión del algoritmo no esta dirigida a la protección de la confidencialidad, pero si a
fines de autenticación.
Un certificado digital[6] es una estructura de datos que vincula la clave pública de una
entidad con atributos de identidad de la misma. La entidad puede ser una persona,
una unidad dentro de una organización, una aplicación, un servidor o un equipo
electrónico. La firma electrónica agrega datos o encripta por clave privada asegurando
que el documento fue validado por el propietario de la clave privada. La protección de
la privacidad de la clave privada es fundamental. ISO 17799 [7]define un entorno que
garantiza tal seguridad.
PKI
El penúltimo capítulo de la parte 1 define CPS, CA, RA y después trata de los

certificados calificados [8](RFC 3039-Internet X.509 Public Key Infrastructure Qualified
Certificates profile). ISO recomienda el uso de certificados calificados tanto por los
rev. 21 jul 2006.
profesionales, bajo secreto médico, como para los empleados comunes cuya discreción
es regida por la legislación nacional.
ISO recomienda igualmente que los certificados sirvan esencialmente para confirmar la
identidad. No obstante, el estándar especifica una extensión al tipo de certificado de
identidad llamada HCRole, definida en ISO 17090-2 [2] para indicar la especialización
profesional de los médicos.
Acerca de agregar al certificado atributos de autorización, el comité técnico ISO hace

sus recomendaciones con prudencia, hablando de si es "deseable" o no que tales
atributos profesionales y de responsabilidad estén incluidos en el certificado.
Modelos de interoperabilidad
La norma ISO 17090 examina modelos de interoperabilidad entre CAs:

1. jerarquía PKI única
2. evaluación del vínculo de confianza por la parte que se conecta
3. reconocimiento recíproco
4. certificación recíproca
5. CA puente
17090-2:2002 PKI / Parte 2: perfiles PKI

1. Certificados de clave pública
1. Certificados cruzados/puente
2. Certificado Raíz CA firmado por si mismo y sus certificados subordinados
2. Certificados de usuario final
1. Individuales
1. Certificado calificado para profesional de la salud bajo secreto profesional
2. Certificado calificado para empleado de la salud no sometido a secreto
profesional
3. Cliente
2. Organización
3. Equipos
4. Aplicaciones
3. Certificados de atributos, atributos firmados digitalmente, información de control
de acceso
El estándar especifica todos los atributos obligatorios y opcionales para cada una de
estas categorías. Además, todos los certificados tienen que ser X.509 versión 3 y
rev. 21 jul 2006.
cumplir con RFC 2459.
Se recomienda que todos los certificados individuales cumplan con IETF/RFC 3039
Qualified Certificates Profile.
Las firmas digitales no se usarán con el fin de encriptación. El campo “signature” tiene
que identificar el algoritmo usado:
1. md5WithRSAEncryption (1.2.840.113549.1.1.4)
2. sha1WithRSAEncryption (1.2.840.113549.1.1.5)
3. dsa-with-sha1 (1.2.840.10040.4.3)
4. md2WithRSAEncryption (1.2.840.113549.1.1.2)
17090-3:2002 PKI / Parte 3: Regulación de CA
Un CA tiene que publicar sus protocolos para registrar y autenticar nuevos certificados,
protocolos para mantener la privacidad de las informaciones personales, protocolos
para distribuir los certificados, protocolos para recibir información acerca de posible
pérdida de privacidad de la clave privada, protocolos de distribución de la lista de
revocación, información sobre tamaño, proceso de generación, vida útil, prolongación,
protocolos de certificación cruzada con otras CA, protocolos de seguridad y auditoría.
ISO17090-3 7.3.1.7
Las organizaciones de la salud, organizaciones de soporte, o personas actuando en

nombre de organizaciones o equipos deben presentar al RA evidencia de su existencia
y role en el sistema de salud, presentando documentos apropiados en el País, Estado o
Gobierno Provincial. La CA o la RA debe verificar esta información así como la
autenticidad del solicitante y la autorización de representación para actuar en nombre
de la organización.
En el Uruguay, los documentos a presentar a la RA son expedidos por el Ministerio de

Salud Pública.
Resumen sobre Certificados Digitales
En el marco de las presentes recomendaciones, el STFE[9] se focalizó exclusivamente en

la comunicación punto a punto segura entre instituciones de salud, que precisa
certificados de organizaciones.
rev. 21 jul 2006.
El documente ISO 17090, y en particular la parte 3, da un patrón con el cual evaluar la

oferta de certificadores privados o estatales antes de contratar sus servicios en el
marco de la comunicación punto a punto entre servicios de salud.
El documento ISO 17090 acerca del certificado personal, del certificado calificado para
profesionales de la salud, de la extensión de certificado informando de la especialidad
del profesional de la salud, aborda temas importantes para cuando se trate la firma
electrónica del documento. Se utilizará entonces la versión definitiva del documento
ISO 17090.
HL7
En lo referente a la capa de transporte, HL7 versión 3, edición 2005 [10], en la sección

de Especificación de Infraestructura, menciona tres especificaciones:
° MLLP
° ebXML
° Web Services Profiles
En la fecha de redacción de esta recomendación, sólo la especificación MLLP es

normativa, y las otras dos están catalogadas como DSTU (Draft Standard for Trial Use),
que significa que están siendo puestas a prueba por los miembros para definir su
incorporación definitiva.
La capa de transporte en HL7 v3 se ocupa del envío de la carga de los mensajes desde
el origen al destino, sin entrar en detalles sobre el contenido a transportar.
HL7 menciona estas especificaciones de transporte sólo como una forma de reconocer
su madurez en el mercado y su interés para la comunidad HL7, pero en ningún
momento las declara como requerimientos[10]. Se delega la responsabilidad de
elección del protocolo a los interesados en la transferencia de información.
MLLP
Como su nombre bien lo describe, el MLLP (Minimum Lower Layer Protocol) tiene
como propósito el proveer un protocolo mínimo. No toma en cuenta la seguridad, y se
sugiere el uso de protocolos adicionales.
rev. 21 jul 2006.
ebXML
El objetivo de ebXML es el de proveer un marco en el cual el intercambio electrónico

de datos, orientado a procesos de negocios, pueda ser preservado en una arquitectura
que hace uso extensivo de las características técnicas de XML. Es la continuación de el
esfuerzo de los estándares EDI: UN/EDIFACT y X12.
El servicio de mensajería ebXML realiza todas las funciones de seguridad, incluyendo:

° Identificación
° Autenticación (verificación de la identidad)
° Autorización (controles de acceso)
° Privacidad (encriptación)
° Integridad (firma del mensaje)
° No repudio
° Registro
En lo referido al transporte, ebXML no tiene ningún requerimiento específico, y

menciona, entre otros, HTTP, SMTP, FTP. [11]. La capa de transporte puede tener un
sobre externo, opcional, específico del protocolo de comunicaciones utilizado, que
contenga al sobre normativo del mensaje ebXML.
Las recomendaciones[12] sobre HTTP mencionan, entre otros:

° HTTP 1.1[13] como nivel mínimo de protocolo soportado.
° Uso de solicitudes HTTP POST para el envío de los mensajes ebXML.
° Uso de los códigos de error HTTP únicamente cuando se trata de errores en la capa
de transporte.
° Sugiere control de acceso vía autentificación HTTP BASIC o HTTP DIGEST[14].
° Sugiere el uso de encriptado utilizando TLS [15]. También requiere compatibilidad
hacia atrás con SSL3, según lo especificado en el apéndice E de TLS[15]. Sobre los
cifrados, cualquiera de los especificados en TLS es normativo, pero requiere que
como mínimo se soporten los necesarios para compatibilidad hacia atrás con SSL3.
HL7 en su especificación [10] también incluye un protocolo simple, seguro y

autenticado sobre TCP/IP para el envío de mensajes ebXML, la cual tiene los siguientes
requerimientos:
° Dominio y dirección IP: cualquiera para el que inicia la comunicación, pública válida
para el destinatario.
° Protocolo de encriptado: TLS 1.0 o SSL 3.0
rev. 21 jul 2006.
° Certificado X.509: opcional pero recomendado para el que inicia la comunicación,

requerido para el destinatario.
° Largo mínimo de la llave pública: 1024 bits.
° Largo mínimo de la llave de sesión: 120 bits.
° Firma digital de los mensajes y las confirmaciones: opcional.
Respecto a los certificados, se menciona que los involucrados en la comunicación

deben ponerse de acuerdo de antemano en la Autoridad Certificadora y la estructura
de nombres de los certificados. En caso de que se utilice autenticación mutua (el
destinatario y el remitente utilizan certificados), aparte de las condiciones mencionadas
anteriormente, se exige que los involucrados confirmen la identidad de la otra entidad
antes del intercambio de mensajes y que no acepten la conexión si se descubre alguna
anomalía en la acreditación.
Web Services Profile
Los lineamientos de implementación de WSP (Web Services Profile) tienen como

propósito la interoperabilidad. Permiten exponer servicios de software usando
protocolos estandarizados e interoperables, sin importar la plataforma en la que fueron
implementados.
Los protocolos WS-* se construyen sobre los cimientos constituidos por XML, SOAP y
WSDL, y permite expresar funcionalidades avanzadas. Estas especificaciones se
desarrollaron con el objetivo de ampliar la adopción de los estándares, focalizando en
temas como la seguridad, confiabilidad de las transacciones, descripción y
descubrimiento.
HL7 ha elegido llevar a cabo una aproximación en fases, donde gradualmente van a ir
introduciendo especificaciones sobre Web Services. Para la edición 2005 del estándar
[10] se incluyen definiciones y se respetan las recomendaciones sobre:
° SOAP 1.1 [16]
° WSDL 1.1 [17]
° WS-I Basic Profile [18]
En el futuro se piensa incluir recomendaciones sobre:

° WS-I Security
° WS-I Policy
° SOAP 1.2
° Otras recomendaciones WS-I
rev. 21 jul 2006.
En lo relativo a la seguridad en el transporte, el WS-I Basic Profile [18] sugiere pero no

exige el uso de TLS 1.0 o SSL 3.0. El estándar incorpora por referencia:
° RFC2818: HTTP sobre TLS [19]
° RFC2246: TLS Versión 1.0 [20]
° Puntos de extensión:
° Cifrados: TLS permite el uso de algoritmos de cifrados arbitrarios.
° Extensiones: TLS permite extensiones en la fase de "handshake".
° SSL Versión 3.0
° Cifrados: SSL permite el uso de algoritmos de cifrados.
° RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile [21]
° Autoridad Certificadora: La selección de la AC debe ser un acuerdo privado entre
los interesados.
° Extensiones a los certificados: X509 tiene previsto extensiones arbitrarias para los
certificados.
El WS-I Basic Security Profile [22] en su sección 4 sobre mecanismos de la capa de

transporte, hace algunas recomendaciones más específicas sobre las versiones y
cifrados de SSL y TLS:
° Debido a los problemas de seguridad conocidos de SSL 2, prohibe su uso.
° Los cifrados obligatorios son:
° TLS_RSA_WITH_3DES_EDE_CBC_SHA
° SSL_RSA_WITH_3DES_EDE_CBC_SHA
° TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
° SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
° Recomienda el uso de AES como encriptado.
° Desalienta el uso de cifrados Diffie-Hellman anónimos y de los MD5.
° Por último recomienda que no se usen cifrados con llaves de 40 o 56 bits dada la
vulnerabilidad que tiene a los ataques de fuerza bruta.
IHE
IHE definió en su ciclo 2004-2005 nuevos perfiles de integración formalizando la

creación de repositorios de documentos médicos compartidos entre sistemas de salud.
Se trata en particular de:
° Cross-Enterprise Document Sharing (XDS) Compartir documentos entre sistemas de
una empresa de salud
rev. 21 jul 2006.
° Audit Trail & Node Authentication (ATNA) autenticación de nodo (en una red de
comunicación) y bitácora de operaciones
Estos 2 perfiles son la base arquitectónica de toda la actividad actual de la IHE. Por
ejemplo, la comunicación de documento punto a punto (XDP, Cross-Enterprise
Document Point-to-Point Interchange) esta escrito como un caso particular de XDS, en
el cual varias transacciones pueden simplificarse dado que en este caso interactuan
sólo 2 sistemas sin repositorio de documentos de por medio.
XDP
El perfil XDP hace propuestas concretas para intercambiar documentos y metadata

acerca de un paciente usando el mail seguro o un servicio web seguro. Además, XDP
define actores y transacciones para comunicar documentos de pacientes mediante CD
o memoria USB.
XDP usa los mensajes y la metadata definida en el perfil XDS, para asegurar la mejor
compatibilidad entre ambos perfiles. Adicionalmente, XDP se apoya sobre los
estándares (OASIS-ebXML, HL7 CDA, CEN ENV 13606, EDISANTE, MMF/MXF,
MERIT-9, IETF, entre otros).
IHE decidió que las condiciones de seguridad definidas en el perfil ATNA precisaban
aplicarse a los actores ("Document Source", "Document Recipient", "Portable Media
Creator"), pero no eran necesarias para el actor "Portable Media Importer". Este último
actor esta ilustrado por ejemplo con un CD conteniendo diagnósticos e imágenes
radiológicas entregado al paciente. La computadora del paciente toma el rol de
"Document Media Importer" gracias a un sencillo navegador web, ya que el CD
contiene un índice html facilitando el acceso a todos los documentos. La ausencia de
seguridad del actor "Portable Media Importer" no hace peligrar la seguridad de ningún
sistema mientras la información no se reingrese.
El perfil XDP considera imperativo:

° la comunicación de metadata de una identificación del paciente que sea común al
"Document Source" y al "Document Recipient"
° el uso del email acknowledgement (confirmación de recepción de email)
° que ambas organizaciones que participan en un intercambio acepten el mecanismo
de auditoría de la otra.
rev. 21 jul 2006.
También XDP indica herramientas de seguridad que el actor de importación puede

usar:
° comparar valor del hash y comparar tamaño de archivos
° firma digital
° el CD o la memoria USB tienen que estar bien identificados en cuanto a origen,
fecha, integridad y privacidad.
° todos los portadores del CD o de la memoria USB tendrán derecho a ver el
contenido, salvo estipulado de otra forma.
ATNA
Audit Trail and Node Authentication (auditoría y autenticación de nodos) es un perfil

IHE básico requerido por otros perfiles operativos menos abstractos. Las metas del
perfil ATNA incluyen:
° responsabilizar el usuario,
° controlar el acceso,
° centralizar la información que permite auditar el sistema de seguridad y
° preservar la integridad y privacidad de la información sensible.
Para lograr estas metas, ATNA impone:

° la autenticación del usuario (pero no define la tecnología a usar),
° la creación de una bitácora de operaciones con información sensible (recomienda
para eso, Reliable Delivery for syslog RFC 3195, pero acepta el estándar anterior, BSD
syslog) y
° la autenticación del nodo al inicio de una transacción.
ATNA no impone el uso de encriptación durante las transmisiones.
ATNA impone el mecanismo de negociación de seguridad de TLS para todas las

comunicaciones entre nodos informáticos seguros para garantizar que se comunican
exclusivamente con otros nodos seguros. Además, ATNA permite la negociación de la
opción de encriptación si ambos nodos son configurados para pedir y soportarla.
ATNA requiere el uso de autenticación bidireccional basada en certificados para las

conexiones hacia y desde cada nodo.
DICOM
rev. 21 jul 2006.
Nació del consenso de los fabricantes de equipos de imagenología médica y es

universalmente reconocida en los temas de almacenamiento, distribución y
visualización de imagen médica digital. Acerca de la distribución digital, DICOM define
varias vías:
° Relación entre una entidad proveedora y una entidad usuaria, que incluye una etapa
de asociación-negociación, seguida en caso de éxito por la transferencia requerida.
La etapa asociarse-negociar utiliza un subgrupo de funciones del estándar ACSE
(basado en OSI y TCP/IP) y restringe ACSE con tablas de valores autorizados para los
pedidos y respuestas. Dentro de estos valores está el protocolo de comunicación TLS.
Entonces, cuando TLS es aceptado en la fase de asociación, todo el resto de la
comunicación se hace de esta forma.
° CD. Toda la metadata directamente utilizada por aplicaciones DICOM esta reunida en
un archivo llamado DICOMDIR. La eventual encriptación esta aplicada a cada uno de
los archivos de imagen. Recientemente IHE definió las especificaciones del formato
de los CD DICOM en un perfil llamado PDI, para favorecer su universalidad. Ahora, en
el nuevo perfil IHE XDP, se pueden incluir dentro de un CD las imágenes con
DICOMDIR respetando el formato PDI junto a un CDA release 2.
° WADO es un acceso a imágenes por comando HTTP o HTTPS GET, descrito en la
parte 18 de la norma DICOM. Los argumentos del comando GET descrito se refieren
a cada imagen por su OID. WADO no permite el acceso a índices para pedir
imágenes en función de otros criterios. Sin conocer el OID, el acceso a una imagen
precisa es de hecho casi imposible.
° EMAIL. El suplemento 113 está en curso de aprobación y define como mandar
imágenes por email. Para este caso, se sugiere que el grupo de archivos con su
DICOMDIR estén comprimidos dentro de un archivo único DICOM.ZIP, que se
adjunta al email en MIME multiparte. Eventualmente, el email entero puede estar
encriptado.
Dentro del estándar DICOM, la parte 15 que trata de seguridad fue agregada en el
2000. La seguridad hasta entonces no era una prioridad para DICOM, ya que las redes
de distribución de imagen funcionaban desconectadas de Internet. Esta parte presenta
las herramientas de seguridad previstas para intercambiar objetos DICOM entre
entidades de aplicación y requiere que estas herramientas permitan definir una política
de seguridad, la cual no forma parte del estándar.
DICOM, de manera similar a IHE, usa los conceptos de actor, perfil y transacción para
diferenciar sus herramientas de seguridad. Lista 8 perfiles de seguridad:
° (A) uso de repositorio (documentos originales)
rev. 21 jul 2006.
° (B) transporte (identidad, autenticación, bitácora, encriptación, distribución de claves

de sesión, integridad)
° (C) firma digital (quién representa, propósito, condiciones de inclusión, atributos,
forma de crear y verificar la firma, relación con otras firmas)
° (D) almacenamiento sobre medios removibles (cómo encapsular y encriptar)
° (E) confidencialidad y eliminación de la identificación
° (F) direccionamiento en la red (DNS, DHCP)
° (G) sincronización de referencias de tiempo (NTP)
° (H) gestión de la configuración de las aplicaciones (descubrimiento automático de los
servicios DICOM)
Para el transporte (B), DICOM preconiza como mínimo TLS con autenticación mediante
certificados RSA (TLS_RSA_WITH_AES_128_CBC_SHA o
TLS_RSA_WITH_3DES_EDE_CBC_SHA), control de integridad por SHA y protección de
la privacidad con encriptación Triple DES, EDE o CBC. Tradicionalmente DICOM usa los
puertos 104 y 11112 para comunicación no segura y el puerto 2762 para
comunicación segura DICOM-TLS.
Alternativamente, DICOM sugiere también un perfil llamado ISCL (Integrated Secure

Communication Layer, V1.00) con autenticación mediante "Three-pass four-way"
(ISO/IEC 9798-2), control de integridad por MD-5 encriptado con DES o DES-MAC (ISO
8730) y protección de la privacidad con encriptación DES. Para tal comunicación
segura esta reservado el puerto 2761 DICOM-ISCL.
Situación actual de la Tecnología disponible
Se hizo una evaluación de la tecnología disponible en el medio, vinculada a

securitización de la transmisión de información.
Certificados Digitales
Los mismos pueden ser:

° certificados personales
° certificados de empresa
° certificados de sitio web
° certificados de e-mail seguro
En Uruguay hay distintos emisores de certificados:

rev. 21 jul 2006.
Cámara de Comercio
Emite certificados destinados a transacciones comerciales. Está entre sus objetivos

obtener validez legal internacional. Hay certificados de empresa representada por un
apoderado y certificados de pertenencia a una empresa.
ABITAB
Emite cerificados para el Banco Central: securitiza las transacciones por Internet. Se
generan en dispositivos externos de seguridad. También emite certificados personales.
El Correo
Emite certificados personales, de sitio web y de e-mail seguro. Requiere una

contratación presencial.
Necesidades Actuales
Las comunicaciones a nivel salud en el momento actual, en su mayoría, están

desprovistas de cualquier sistema de securitización de la información. Es necesario
implementar normativas de seguridad en la transmisión de la información sanitaria,
que ateniéndose a la legislación vigente, protejan los datos y aseguren el cumplimiento
de los conceptos básicos de Seguridad, Identificación, Autentificación, Integridad y
Compatibilidad a futuro.
Los beneficiarios de estas implementaciones serán en primer lugar los usuarios cuya
información sanitaria podrá estar disponible en condiciones de seguridad adecuadas.
En segundo lugar, el propio sistema de salud, que podrá intercambiar información
económica y sanitaria en condiciones de seguridad, que no sólo protegen el contenido
intercambiado sino que se aseguran la identidad del receptor y del emisor de la misma.
Casos de Uso
Se analizaron los casos de uso en el ámbito sanitario nacional.
Los prestadores sanitarios envían rutinariamente información económica, datos de

salud epidemiológicos y datos personales:
rev. 21 jul 2006.
1. Al MSP (todo tipo de información)

° tipos de archivos:
1. Planillas excel
2. Archivos txt
3. Archivos dbf
° vía:
1. E-mail convencional
2. A otros prestadores sanitarios (información económica y datos personales)
1. Planillas excel
2. Archivos dbf
3. Archivo txt
° vía:
2. CD
3. Página web segura
4. Servidor FTP seguro
3. A entidades financieras
1. Planillas excel
2. Archivos txt
° vía:
2. CD o disquete
3. Página web segura
rev. 21 jul 2006.
PERFILES DE USO CONTEMPLADOS EN LAS

RECOMENDACIONES
.....................................................................................................................................
Para definir el escenario de estudio, se agruparon los casos de uso organizándolos en

perfiles, para analizar en forma separada y decidir el alcance de estas recomendaciones
y planificar futuras.
Escenarios
Interacción entre Sistemas Informáticos
Este escenario corresponde al caso de sistemas informáticos que interactúan con

motivo de llevar a cabo una transacción.
Se considera el ejemplo de dos sistemas informáticos que necesitan interactuar para

lograr un fin (autorizaciones, solicitudes, etc.).
Sistema Interactivo
Este escenario corresponde al caso de un usuario interactuando con un sistema

informático.
Se considera el ejemplo de una persona que utiliza un sistema informático externo, a

través de una página web.
Envío de Documentos
Este escenario corresponde al envío de documentación utilizando un repositorio

intermedio para almacenar la información.
Se considera el ejemplo de transferencia de documentación en CD, DVD, USB Drives,

e-mail, servidor de FTP, etc.
rev. 21 jul 2006.
RECOMENDACIONES
.....................................................................................................................................
Introducción a los Estándares
Los estándares recomendados para estos lineamientos fueron basados en los

correspondientes de HL7, IHE, DICOM y en las referencias existentes en este
documento.
Se focalizó en abordar aquellos temas que los estándares internacionales suponen

obvios pero que en nuestro medio todavía no se han difundido.
Entonces, los objetivos de este trabajo son:

° fomentar las comunicaciones seguras.
° sugerir las tecnologías a utilizar.
° incentivar el desarrollo de un marco legal apropiado.
° definir la plataforma que permita la aplicación de estándares internacionales.
Se trabajó en las siguientes áreas:

° Seguridad en la Capa de Transporte
° Certificados Digitales para Organizaciones
Seguridad en la Capa de Transporte
Tanto HL7, IHE, DICOM como las demás referencias estudiadas se apoyan, para la capa
de transporte, en estándares existentes. El denominador común es TLS versión 1.0,
dado que: tiene madurez suficiente en el mercado, tiene proyección al futuro y es
compatible con los objetivos planteados en nuestros escenarios.
El estándar SUEIIDISS-UY-ESP-002 - SEGURIDAD EN LA CAPA DE TRANSPORTE DE

DATOS se aplica a aquellos casos en que exista intercambio de información entre
organizaciones vinculadas al sector salud.
Certificados Digitales para Organizaciones
Desde el comienzo fueron disociados los casos de transporte de información y de firma

rev. 21 jul 2006.
de documentos o de partes de los mismos. Fue útil la distinción porque se necesitan

certificados diferentes para una institución, para el personal médico que firma un
documento o para un paciente.
Son fundamentales las recomendaciones de la ISO 17090 partes 1,2,3.
El estándar SUEIIDISS-UY-ESP-003 - CERTIFICADOS DIGITALES PARA ORGANIZACIONES

se aplica a aquellos casos en que exista intercambio de información entre
organizaciones vinculadas al sector salud.
Este documento no fue redactado a la fecha de entrega de esta versión.
Seguridad en el envío de documentos
El estándar SUEIIDISS-UY-ESP-004 - SEGURIDAD EN EL ENVÍO DE DOCUMENTOS se

aplica a aquellos casos de envío de documentos vinculados al sector salud, por medio
de CD, DVD, USB Drives, e-mail, servidor de FTP, etc..
Este documento no fue redactado a la fecha de entrega de esta versión.

rev. 21 jul 2006.
REFERENCIAS
.....................................................................................................................................
1. # ISO/TS 17090-1:2002 Health informatics - Public key infrastructure - Part 1:
Framework and overview
2. # 2,0 2,1 ISO/TS 17090-1:2002 Health informatics - Public key infrastructure - Part
2:Certificate profile Public
3. # ISO/TS 17090-1:2002 Health informatics - Public key infrastructure - Part 3: Policy
management of certification authority
4. # ISO/TR 21089 Trusted end-to-end information flows
5. # ISO 18232:2006 Messages and communication -- Format of length limited
globally unique string identifiers
6. # ITU-T X.509:1997 Recommendation X.509: The Directory - Authentication
Framework. Equivalent to * ISO/IEC 9594-8
7. # ISO/IEC 17799:2000 Information technology -- Code of practice for information
security management
8. # IETF/RFC 3039 Internet X.509 Public Key Infrastructure Qualified Certificates
Profile
9. # Sub-Comité Técnico de Firma Electrónica de la SUEIIDISS
10.# 10,0 10,1 10,2 10,3 HL7 2005 Normative Edition of the Version 3 (V3) messaging
standard.
11.# ebXML Technical Architecture Specification v1.0.4, 16 Feb 2001, UN/CEFACT and
OASIS 2001
12.# ebXML Message Service Specification Version 2.0. 1 Abril 2002.
13.# Hypertext Transfer Protocol Version 1.1 - RFC2616
14.# HTTP Authentication - RFC2619
15.# 15,0 15,1 IETF Transport Layer Security - RFC2246
16.# W3C Simple Object Access Protocol (SOAP) 1.1 http://www.w3.org/TR/SOAP/
17.# W3C Web Services Description Language (WSDL) 1.1 http://www.w3.org/TR/wsdl
18.# 18,0 18,1 WS-I Basic Profile Version 1.0
http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm
19.# RFC2818:HTTP over TLS http://www.ietf.org/rfc/rfc2818.txt
20.# RFC2246:The TLS Protocol Version 1.0 http://www.ietf.org/rfc/rfc2246.txt
21.# RFC2459:Internet X.509 Public Key Infrastructure Certificate and CRL Profile
http://www.ietf.org/rfc/rfc2459.txt
22.# WS-I Basic Security Profile Version 1.0
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html#transportsec

Sueiidiss Uy Lin 001

Cargado por

Información del documento

Descripción original:

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

Sueiidiss Uy Lin 001

Cargado por

Copyright:

Formatos disponibles

SOCIEDAD URUGUAYA DE ESTANDARIZACIÓN, INTERCAMBIO E INTEGRACIÓN DE DATOS E INFORMACIÓN DE SERVICIOS DE SALUD

SEGURIDAD DE DATOS EN EL SECTOR SALUD URUGUAYO

4 PERFILES DE USO CONTEMPLADOS EN LAS RECOMENDACIONES....................... 22

SEGURIDAD DE DATOS EN EL SECTOR SALUD URUGUAYO

Versión 1.0 – 21 de Julio de 2006

SUBCOMITÉ TÉCNICO DE FIRMA ELECTRÓNICA

Las premisas que definen la seguridad en el intercambio de información en el sector

La necesidad de intercambio de información entre los sistemas de salud es una realidad

La información involucrada en estos intercambios, pasa por datos personales, datos

La SUEIIDISS, en cumplimiento de sus objetivos fundacionales ha comenzado un

ISO agrupa 25 países miembros y 15 observadores. En América del Sur, solamente

Este grupo de trabajo publicó en particular:

ISO/TS 17090 Infraestructura de Clave Privada (PKI)

17090-1:2002 PKI / Parte 1 : Introducción

Autenticación, firma electrónica, integridad (en el sector de la salud es importante

El algoritmo asimétrico puede ser usado también en el otro sentido: el texto es

El penúltimo capítulo de la parte 1 define CPS, CA, RA y después trata de los

Acerca de agregar al certificado atributos de autorización, el comité técnico ISO hace

La norma ISO 17090 examina modelos de interoperabilidad entre CAs:

17090-2:2002 PKI / Parte 2: perfiles PKI

cumplir con RFC 2459.

17090-3:2002 PKI / Parte 3: Regulación de CA

Las organizaciones de la salud, organizaciones de soporte, o personas actuando en

En el Uruguay, los documentos a presentar a la RA son expedidos por el Ministerio de

Resumen sobre Certificados Digitales

En el marco de las presentes recomendaciones, el STFE[9] se focalizó exclusivamente en

El documente ISO 17090, y en particular la parte 3, da un patrón con el cual evaluar la

En lo referente a la capa de transporte, HL7 versión 3, edición 2005 [10], en la sección

En la fecha de redacción de esta recomendación, sólo la especificación MLLP es

El objetivo de ebXML es el de proveer un marco en el cual el intercambio electrónico

El servicio de mensajería ebXML realiza todas las funciones de seguridad, incluyendo:

En lo referido al transporte, ebXML no tiene ningún requerimiento específico, y

Las recomendaciones[12] sobre HTTP mencionan, entre otros:

HL7 en su especificación [10] también incluye un protocolo simple, seguro y

° Certificado X.509: opcional pero recomendado para el que inicia la comunicación,

Respecto a los certificados, se menciona que los involucrados en la comunicación

Web Services Profile

Los lineamientos de implementación de WSP (Web Services Profile) tienen como

En el futuro se piensa incluir recomendaciones sobre:

En lo relativo a la seguridad en el transporte, el WS-I Basic Profile [18] sugiere pero no

El WS-I Basic Security Profile [22] en su sección 4 sobre mecanismos de la capa de

IHE definió en su ciclo 2004-2005 nuevos perfiles de integración formalizando la

El perfil XDP hace propuestas concretas para intercambiar documentos y metadata

El perfil XDP considera imperativo:

También XDP indica herramientas de seguridad que el actor de importación puede

Audit Trail and Node Authentication (auditoría y autenticación de nodos) es un perfil

Para lograr estas metas, ATNA impone:

ATNA no impone el uso de encriptación durante las transmisiones.

ATNA impone el mecanismo de negociación de seguridad de TLS para todas las

ATNA requiere el uso de autenticación bidireccional basada en certificados para las

Nació del consenso de los fabricantes de equipos de imagenología médica y es

° (B) transporte (identidad, autenticación, bitácora, encriptación, distribución de claves

Alternativamente, DICOM sugiere también un perfil llamado ISCL (Integrated Secure

Situación actual de la Tecnología disponible

Se hizo una evaluación de la tecnología disponible en el medio, vinculada a

Los mismos pueden ser:

En Uruguay hay distintos emisores de certificados:

Emite certificados destinados a transacciones comerciales. Está entre sus objetivos

Emite certificados personales, de sitio web y de e-mail seguro. Requiere una

Las comunicaciones a nivel salud en el momento actual, en su mayoría, están

Se analizaron los casos de uso en el ámbito sanitario nacional.

Los prestadores sanitarios envían rutinariamente información económica, datos de