TELOS - Fundación Teléfonica

Artículos

Artículos de la Sociedad de la Información

Tribuna
23/08/2006
Nivel dificultad: Alto

Receta electrónica. Estándares de seguridad en salud electrónica

O. Ferrer-Roca, A. Diaz-Cardama y F. Marcano

La seguridad y privacidad de datos son elementos fundamentales en la sanidad. Este artículo nos muestra un sistema de receta sanitaria con firma electrónica de acuerdo a las leyes vigentes y con un alto nivel de  seguridad.

Descargar archivo de audio (12:03 min / 2,76 Mb)

El demostrador de receta electrónica que se describe en este artículo es un modelo de infraestructura y gestión de accesos en sanidad electrónica. Para su diseño se han utilizado los estándares de informática médica y seguido la legislación vigente sobre seguridad y privacidad.

Uno de los elementos fundamentales en sanidad es la seguridad y privacidad de los datos. En la Convención Europea de Derechos Humanos (1963), la protección de los datos personales y la privacidad se reconoce como un derecho fundamental.

Las directivas de la UE tratan aspectos genéricos de privacidad y seguridad de los datos, y son los países miembros los que tienen que ponerlos en practica (1,2). Estos dictan leyes fundamentalmente técnicas para la adecuación de los tres niveles de seguridad (bajo, medio y alto); perteneciendo el ámbito sanitario al nivel alto y siendo obligatorio a partir del presente año 2006. Cuando los países miembros cumplan todos las directivas comunitarias, el intercambio de datos entre cualquier entidad europea no necesitará ya acuerdos bilaterales de seguridad.

Debido al elevado nivel técnico de las normativas en Europa, las autoridades sanitarias y los usuarios desconocen los requerimientos legales de su hardware y su software. Muy pocos son los documentos (3,4,5,6) y las normas parcialmente estandarizadas (2,7,8,9) que han sido publicadas. Brevemente, la ISO 17799 es un marco mundial sobre criterios de seguridad informática.

No existen soluciones comerciales adecuadas para acceder a los complejos datos y roles sanitarios. Requerirían tener Notarios electrónicos especializados (Trusted Third Party Services TTPS), ser altamente seguras y estar disponibles 24 horas al día para la autenticación-autorización-administración-auditoria de cualquier acceso o modificación de los datos sanitarios.

En estos temas el comité internacional ISO/TC251-WG4-DTS ha hecho un esfuerzo de estandarización con su norma 17090 (3). Según el estándar es necesario que se designen autoridades sanitarias para la identificación y emisión electrónica de los títulos, permisos o licencias de actuación sanitaria incluyendo roles y reglas.

En este documento se expone el desarrollo de un sistema de receta sanitaria con firma electrónica de acuerdo a las leyes vigentes, con un alto nivel de seguridad, tomando en consideración los estándares de informática médica y usando un sistema de almacenamiento de la identidad electrónica de alta seguridad. Se discuten las ventajas y los inconvenientes de las soluciones comerciales existentes y si estas son adecuadas para sanidad.

I. MATERIAL Y METODOS.

DISEÑO DEL ENSAYO

El ensayo intenta mejorar la eficiencia de la atención primaria, acelerando la receta y validación de medicamentos que requieren la firma del supervisor.

El simulador tenía la finalidad de generar una aplicación real buscando las soluciones legales necesarias para que tuviera total validez. La aplicación trabaja en un entorno altamente seguro de red privada virtual (VPN) del departamento de Sanidad del Gobierno Canario. Ya que las transacciones con el servidor son seguras e incluyen encriptación, los datos pueden archivarse sin encriptar en el servidor central, que gestiona y actualiza permanentemente los datos sanitarios.

La arquitectura del sistema puede estudiarse en la figura 1 , que representa la solución ideal.

Figura 1.- Arquitectura de una TTP especializada en Sanidad. A la izquierda puede comprobarse el diseño del token USBsec -dentro del proyecto Smart-USB.

(CA=Certification Authority; RA=Registration Authority; AA=Attribute Authority; AC=Attribute certificate)

II. SIMULACIÓN DE LA GESTIÓN SANITARIA ELECTRÓNICA.

1) COLEGIO MÉDICOS / SIMULADOR DE COLEGIACIÓN. PERSONALIZACIÓN DEL CHIP.

1.1) Personalización del chip.

La tarjeta sanitaria de ID profesional se ha creado sobre un token-USB (ISTEC E4 High; EAL-5) que incorpora un acelerador HASH por hardware para la firma digital. Almacena las claves privadas y los certificados para las transacciones electrónicas y realiza la encriptación de datos el mismo chip. Tiene un acelerador de HASH en hardware para la firma digital que procesa a una velocidad superior a la que soporta el Puerto USB 1.1. (12 Mbit/segundo).

El token sin inicializar viene de fabrica con dos certificados no personalizados y un PIN de acceso. Se personaliza importando al chip la clave privada, utilizada para firmar, junto con el certificado de clave pública. La Autoridad de Certificación (CA) simulada emite un certificado de clave pública (PKC) y genera un archivo PKCS#12 conteniendo el par de claves (claves pública-privada por software) que se importa en el chip del token.

Los PKCs son utilizados como ID únicos en las funciones de autenticación de acuerdo con las leyes españolas y de la UE [certificado de clave pública X.509]. El certificado contiene la autorización (doctor licensing) y reconocimiento del titulo médico y de la especialidad para ser usada por la receta-e. Este certificado especifica además la política de reconocimiento inter-institucional y trans-fronterizo.

1.2) Autenticación de la identidad ID.

Se requiere una autenticación de la identidad ID del usuario que le permita entrar en la aplicación de receta-e y autorización de acuerdo con sus roles para acceder a los datos disponibles. La aplicación solicita del usuario una autenticación fuerte, enviando un numero aleatorio que es firmado con la clave privada dentro del token-USB; el HASH resultante es enviado y procesado comparándolo con el obtenido por la clave pública del usuario. La aplicación antes y después de asegurar la identificación del usuario ( User-ID ) accede localmente al CRL (Certification Revocation List) para comprobar la validez del certificado.

La aplicación determina posteriormente si el usuario del token está o no autorizado a emitir/supervisar una receta. Lee la extensión atributo de su PKC que almacena su rol. El atributo de rol de doctor o de supervisor tuvo que ser introducido en el PKC. Para la autorización de acceso a los datos, no están comercialmente disponibles los modelos estandarizados de Certificado de atributos y no existen los Certificados de acceso por reglas. Por lo tanto los roles en forma de atributos han tenido que ser incluidos en extensiones del PKC del tipo de Atributos del directorio sujeto (Subject Directory Attributes), y las reglas ni siquiera han podido ser consideradas.

2) RELLENO DE LA RECETA.

Imita el formato de una receta española en papel (figura 2). Selecciona los medicamentos de la Base de Datos Nacional de Medicamentos que está disponible dentro de la EHR (Historia Clínica Electrónica). Importa la identificación única de paciente (PUID) desde la historia clínica y los datos administrativos del médico, incluido su número de colegiado, del certificado de ID guardado en el token-USB.

Figura 2.- Formato de la receta- e siguiendo el modelo en papel existente en España.

3) FIRMA Y ALMACENAMIENTO.

Una función ligada a un icono permite al doctor firmar electrónicamente la receta añadiendo su firma con su/sus certificados públicos y la cadena de confianza en la que están basados, en la base de datos de la EHR. Un segundo icono permite a los supervisores revisar las recetas y realizar una contra-firma después de haber confirmado la integridad del mensaje, la validez de la firma del médico y comprobar hacia atrás la cadena de confianza del mismo contra una lista de revocación local (CRL) que se actualiza cada 2 horas.

Una vez rellena la receta medica, el doctor o el supervisor ha de firmarla. Para ello se presiona el icono de firma. En este momento el rol y la validez del PKC se comprueban de nuevo, seguido por un paso de "confirmación" de la acción que es obligatorio por ley, con el fin de asegurar que la acción (estampar una firma electrónica) no es accidental sino totalmente consciente. En el momento de la confirmación se lleva a cabo una re-autenticación y una re-autorización que por supuesto es totalmente transparente al usuario. Por imperativo legal, la receta-e firmada se almacena en la base de datos sanitaria junto con el certificado público del médico y si es posible con la cadena de confianza validada.

III. DISCUSIÓN.

El demostrador de receta-e es un ejemplo de aplicación sanitaria electrónica. Muestra los problemas que tiene el entorno sanitario para cumplir con las regulaciones nacionales e internacionales sobre la protección de datos sensitivos y para el intercambio y el reconocimiento Inter-institucional y trans-fronterizo.

Nos muestra algunas soluciones efectivas como la utilización de un dispositivo plug and play capaz de transportar la identidad del trabajador junto con su clave privada, sus atributos su certificado de roles y la cadena de confianza en la que se basan los mismos (ID electrónico profesional).

Nos muestra cómo crear Autoridades de Certificación capaces de emitir certificados digitales legales y los requerimientos de software para gestionar las extensiones estandarizadas de los certificados electrónicos de acuerdo con las normas internacionales. Poniendo de manifiesto las carencias de TTPs especializados en sanidad.

Debido a esta complejidad se hace necesario contar con etiquetas o marcas de calidad que cubran al usuario de posibles negligencias o falta de adecuación legal en aspectos tan importantes como la seguridad y los estándares médicos en el entorno sanitario. Estas etiquetas tendrían por finalidad generar confianza a usuarios y consumidores de que los aspectos de alta seguridad y calidad requeridos por ley, se cumplen. El demostrador se adecua a las leyes de la UE, España y USA, y aborda los aspectos de cualquier entorno legal en el que se requieran intercambios globales.

Las PKI sanitarias demandan soluciones que especifiquen el grado de veracidad necesario, por su necesidad de disponibilidad las 24 horas del día, por su necesidad de ser compatible con Internet, y adecuar las políticas de certificación entre centros que han de ser públicas y reconocidas cuando hay intercambios de información (3). De lo contrario la información electrónica transportada (entre medicina primaria y terciaria, entre hospitales, entre regiones, entre países) no tendría validez.

La puesta en funcionamiento de soluciones de salud electrónica obligatorias desde el 2006, está pues ligada a la formación en seguridad electrónica. Para la Telemedicina, los aspectos de seguridad son esenciales pero las Facultades de Medicina no facilitan esta formación a los médicos generales a pesar de ser esencial en su práctica diaria. Este hecho es independiente de las reivindicaciones de los técnicos por una nueva profesión, la de Informática Medica que definen como "el conocimiento, las habilidades y las herramientas, que permitan recoger, gestionar, usar, y compartir información que provea o promocione la salud".

IV. CONCLUSIONES.

Los requerimientos de seguridad en el ámbito sanitario son muy elevados y precisan, tal como especifican los cuerpos de estandarización, una Infraestructura de Manejo de Privilegios para la gestión de roles además de una Infraestructura de Clave pública que permita una política de reconocimiento trans-fronteriza. Las autoridades de certificación próximas a los Colegios de Médicos y a los hospitales probablemente demanden Centros de Transacción electrónica especializada.

Desde el punto de vista del Hardware, los chips deben tener una adecuada capacidad de almacenamiento que permita la gestión de los múltiples certificados. Aunque la mayoría de los requerimientos están estandarizados, la falta de conocimiento por parte de los trabajadores y gestores sanitarios limita el desarrollo de aplicaciones comerciales que una vez disponibles deberán llevar los sellos de calidad y de adecuación a las normativas legales.

V. AGRADECIMIENTOS.

Este trabajo ha sido realizado bajo los auspicios del proyecto IST- 1999-20323 Smart-USB a los que agradecemos su cooperación y soporte.

VI. ENLACES DE INTERÉS.

A continuación se muestran algunos enlaces que pueden resultar de utilidad para los usuarios interesados en el desarrollo de la receta electrónica:

  • Artículo de la Revista española de patología: Vol. 36, nº 2, 2003


- Título: Firma electrónica y manejo de privilegios en sanidad
- Autores: Olga Ferrer Roca, Karim Franco, Pablo Pulido, Pedro Escobar, Álvaro Cardenes
- Enlace documento (html): http://www.pgmacline.es
- Enlace documento (pdf): http://www.pgmacline.es

  • Vínculo a la página web del Ministerio de Industria, Comercio y Turismo con enlaces a proyectos relativos a la sanidad electrónica.


- Enlace: http://www.mityc.es

  • Vínculo a la página web del Ministerio de Fomento con un pequeño tutorial sobre firma electrónica y certificados digitales con motivo del lanzamiento del DNI electrónico.


- Enlace: http://www.fomento.es

  • El Gobierno español y la Junta de Andalucía, conjuntamente con la Presidencia Austriaca de la Unión Europea y la Comisión Europea organizarán la cuarta edición de la Conferencia de Alto Nivel eSalud bajo el lema: "eSalud y políticas de Salud: Sinergias para una mejor Salud en una Europa de Regiones". La celebración de este evento tendrá lugar en  Málaga del 10 al 12 de mayo 2006.


- Enlace: http://www.ehealthconference2006.org/index.php?lang=ES

 

Autores: O. Ferrer-Roca, A. Diaz-Cardama, F. Marcano.


BIBLIOGRAFÍA

1. Directivas UE: Directiva 95/46/EEC Protección del individuo en el procesado de datos personales y el libre movimiento de datos; Directiva 99/93/CE del Parlamento y la CE sobre firma electrónica. Directiva 200/31/CE de Comercio Electrónico y 98/27/CE Protección consumidor.

2. Grupo de trabajo de intercambio de datos electrónicos http://www.wedi.org (Accedido el 15 de Febrero 2006).

3. Health Insurance Portability and Accountability Act (1996) (HIPAA) http://cms.hhs.gov/hipaa (Accedido el 15 de Febrero 2006).

4. Borten K. Ed. (2003) HIPPA Security Made Simple. Practical Advice for compliance. HCPro Inc. Maryland. ISBN 1-57839-269-1.

5. Legislación española: Firma digital RD14/99; Regulaciones para la protección datos personales RD949/99; LOPD - Ley orgánica de protección datos personales LO15/99; Ley de autonomía del paciente L41/2002; LSSI - Ley para los servicios de la sociedad de la información y comercio electrónico. L34/2002; http://www.aeat.es/normlegi/otros/rdl1499.htm; http://www.i-3.org/docs/datos/lopd.pdf; http://civil.udg.es/normacivil/estatal/persona/PF/L41-02.htm; http://www.setsi.mityc.es/legisla/internet/ley34_02/sumario.htm (Accedido el 15 de Febrero 2006).

6. Van der Haak., Wolf AC., Brandner R., Drings P., Wannenmacher M. & Wetter Th. Data security and protection in cross-institutional electronic patient records. Int. J. Med. Informatics 70: 117-130, 2003.

7. ISO/TC251 WG4 - Security on Health Informatics, Task force of Public Key Certification Infrastructure. TS 17090 parts 1-3 (2005) http://www.centc251.org/TCMeet/doclist/TCdoc05/N05-018-WGIII-minutesBerlinMay2005.pdf http://www.ist35.nhs.uk/pages/secure/DOCS/Documents/2005/ist3505_246.pdf (Accedido el 15 de Febrero 2006).

8. ISO/IEC 15408- (1999) Common criteria for information technology security evaluation. http://www.clusit.it/whitepapers/iso15408-1.pdf (Accedido el 15 de Febrero 2006).

9. Buckovich S., Rippen H., Rozen M. (1999). Driving Toward Guiding Principles: A Goal for Privacy, Confidentiality, and Security of Health Information. Journal of the American Medical Informatics Association, 6: 122 - 133.

Descargar archivo de audio (12:03 min / 2,76 Mb)