Tecnologías en la informática sanitaria

© SIEMENS Medical Solutions Health Services, 2004 – All rights reserved

MED Health Services

HS

Tecnologías en la informática sanitaria

Antonio TorresResponsable de Producto

23 de noviembre de 2005


HS

2 de 74

Índice

Tecnología de la información en Sanidad

El negocio de los Sistemas de Información Sanitarios

Modelo de conceptos clínicos

Necesidades tecnológicas en el entorno sanitario

Arquitectura básica

Fundamentos metodológicos

Seguridad en entornos clínicos


HS

3 de 74

Tecnología de la información en la Sanidad


HS

4 de 74

Tecnología en Sanidad

El esfuerzo del cambio Incorporación de la tecnología en la Sanidad

Es un entorno reacio al cambio Asume rápidamente nuevas tecnologías en

equipamiento electromédico y de diagnóstico

Primeros pasos y primeros errores … Los primeros sistemas se orientan hacia la gestión, no

hacia la actividad asistencial El compromiso no fue todo lo completo y organizado que

debía haber sido

… y primeros resultados Se asume y extiende el concepto de HIS (Health

Information System) Definición de conceptos y estrategias

INDICE

►Tecnología en Sanidad

►Negocio de los SI sanitarios

►Necesidades tecnológicas

►Arquitectura básica

►Fundamentos metodológicos

►Seguridad en entornos clínicos

►Modelo de conceptos


HS

5 de 74


La entrada de la Informática Clínica Como dispositivo …

Los sistemas electromédicos cambian de paradigma Los fabricantes siguen pensando en el equipamiento

como autosuficiente en el uso del conocimiento

Como producto … El software de gestión aplicado a Servicios Centrales

Hospitalarios llevan a un acercamiento al paciente Hay un avance, pero sigue condicionado a los intereses

empresariales

Como cultura … El uso intensivo de Internet para investigación clínica,

familiariza al usuario con la tecnología

INDICE









HS

6 de 74


El mercado Obsolescencia funcional

Los conceptos funcionales han variado poco en los últimos quince años

No se aprovecha el empuje de la novedad que genera la investigación en los entornos sanitarios

Obsolescencia tecnológica Las tecnologías en desuso tienen plena vigencia en

producción (MUMPS, Multibase, etc.)

Cultura del desarrollo Los grandes proveedores piensan en “propietario” Los pequeños proveedores no invierten Los desarrollos propios no evolucionan

INDICE









HS

7 de 74


El problema de la integración

HIS

Gestión

UCI Anatomía

Laboratorio

Farmacia

Radiología

Islas de información Compromiso de la unicidad del dato Incoherencias Trabajo en tiempo real

INDICE









HS

8 de 74


Las TI en las organizaciones sanitarias Las instituciones sanitarias

No se implican en el desarrollo de proyectos de informatización, que son costosos en tiempo y dinero

Es difícil realizar la reingeniería de procesos que implica el uso extensivo de TI en el negocio

El personal de TI en sanidad No ha adquirido el rol de organización que los directores

de Sistemas de Información tienen en otros ámbitos

El usuario clínico Busca soluciones a sus necesidades de forma autónoma

INDICE









HS

9 de 74


Un ginecólogo utiliza el programa que aparece en un CD que regala una revista para hacer un seguimiento del Cáncer de Mama en su servicio.

Un médico de urgencias trae un MAC de su casa y lo conecta a la red del Hospital para trabajar … y trabaja.

El novio informático de una secretaria de departamento hace en una semana (primera release en un día) una aplicación de registro quirúrgico que se extiende al 100% de uso en un solo día.

Un reumatólogo hace un “datawarehouse” en Access conectado vía ODBC a las aplicaciones del Hospital y pone un acceso al mismo desde la Intranet.

Un médico hace un interface en Java para una aplicación existente y hace una aplicación de medicación conectada a Farmacia que se extiende al 100% de utilización en un solo día.

Algunos ejemplosINDICE









HS

10 de 74


Objetivos de la Tecnología Simplificar la actividad asistencial del clínico

Maximizar la automatización de tareas No se trata de sustituir la figura del clínico

Evitar el uso de papel El papel no debe ser el soporte del conocimiento No confundir con la inversión en papel (suele crecer!)

Evitar los desplazamientos del paciente Formalizar y automatizar los circuitos El paciente es el “correo interno” en la mayoría de las

interacciones administrativas

Facilitar la interacción entre roles Eliminar la separación entre médico-enfermera-gestión

INDICE









HS

11 de 74


Transformación de la Historia Clínica

Carpeta con documentos independientes por cada actuación asistencial no indexados incluyendo informes impresos, manuscritos, firmados, fotocopiados, placas

Conjunto de información electrónica única, organizada por criterios conceptuales de uso práctico, a la que se accede según necesidades del perfil del usuario

Explotable Estructurado Organizado Útil Coherente Compartible? Seguro

INDICE









HS

12 de 74

El negocio de los Sistemas de Información Sanitarios


HS

13 de 74

El negocio de los SI

Características de un proyecto El sistema es de criticidad máxima

La disponibilidad de conocimiento es la diferencia entre vida y muerte

¿En qué medida se delega la decisión?

Comprensión del sistema Las facetas administrativas son más comprensibles que

la actividad clínica La situación es, todavía, de inmadurez

Gestión de un proyecto No es un entorno de imposición, sino de negociación a

varias bandas y de convencimiento

INDICE









HS

14 de 74


El objetivo del sistema integral

INFRAESTRUCTURA DE HARDWARE, COMUNICACIONES Y SISTEMAS DE BASE

SISTEMAS CLÍNICOS DE

USO GENERAL

SISTEMAS FINANCIEROS Y DE RECURSOS

HUMANOS

SISTEMAS SECTORIALES INTEGRADOS

EN PLATAFORMA

SIST

EMA

S D

EPA

RTA

MEN

TALE

S PR

OPI

ETA

RIO

S

PEQ

UEÑ

OS

SIST

EMA

S

SISTEMAS DE EXPLOTACIÓNInformes, cuadros de mando, EIS, análisis

∞

INDICE








SISTEMAS CLÍNICOS DE

USO GENERAL


HS

15 de 74

ESTRATEGIA PROYECTO PRODUCTOSIM

PLA

NT

AC

IÓN

DIS

EÑ

OC

ON

DU

CC

IÓN


Los roles en el proyecto típico

CONSULTOR

INTEGRADOR

IMPLANTADOR

EXPLOTADOR SOPORTE

INDICE








PROVEEDORPRODUCTO


HS

16 de 74


Rentabilidad del negocio Personal

Un sistema no informatizado requiere personal para el movimiento de historias clínicas en papel

- 1 Téc. especialista por cada 750 historias/día, 1 Téc. auxiliar 325 historias/día,1 Celador 200 historias/día

Un hospital medio gestiona unas 525.000 historias/año, sobre los 300.000 €/año

Soporte papel La historia clínica puede tener una media de 20

documentos en papel Incluir costes de carpetas, sobres, documentos impresos Más de 300.000 €/año

Imagen 180.000 placas/año a unos 5 €/ placa – 900.000 €/año

INDICE









HS

17 de 74



HS

18 de 74


Modelo de información básico

PROCESO CLÍNICO

HospitalizaciónUrgencias ConsultaConsulta

Cirugía

ACTOS CLÍNICOS (CONTACTOS)

PUNTO DE VISTACLÍNICOinformación

PUNTO DE VISTAADMINISTRATIVOactividades

ENTIDADPACIENTE

Objeto Clínico

INDICE









HS

19 de 74

OBJETO PADRE ESPECIALIZACIÓN ESTRUCTURA DEFINICIÓN Y USO PLANTILLAS

Objeto de texto plano

Anotaciones libres y comentarios en cualquier entorno, datos no estructurados

Tipología de anotación

Documento Word

Informes formateados para salida externa a pacientes o instituciones

Plantillas (Word) de documentos compuesta con otros OC

Conjunto de indicadores de paciente

Datos estructurados en cualquier entorno

Plantillas de formulario

Conjunto de líneas de prescripción (medicación)

Tratamiento farmacológico en planta, receta electrónica

Perfiles de tratamiento

Workflow (prescripción, distribución, administración)

Conjunto de pruebas (indicadores de paciente) – posible link con otros OC

Pruebas departamentales (lab, rx, otros), interconsultas

Perfiles de prueba

Workflow (petición, extracción – exploración, resultados)

Conjunto de cuidados (acciones) – posible link con otros OC

Cuidados de enfermería, protocolos

Planes de cuidados

Relacionados con agendas de actividad


Jerarquía de objetos clínicos

Genérico

Texto

Documento

IndicatorIndicatorLínea deprescripción

Form.

Petición

Cuidadoa paciente

IndicatorIndicatorCuidado

Hoja de Tratamiento

IndicatorIndicatorIndicador

IndicatorIndicatorPrueba

INDICE









HS

20 de 74


Indicadores y observaciones

DICCIONARIO DE DATOS

INDICADOR

NOMB PESO COD. PS

TIPO NUMERICO UNID. KGNORM 0 a 90

FORM. ENFERMERÍA

PESOFORM. CARDIOLOGÍA

PESO

MODELADO (MODELO DE DATOS) DEFINICIÓN (PLANTILLAS)

USO (OBSERVACIONES)

FORM. CARDIOLOGÍA

PESO 72 kg

GESTIÓN (SERIES & GRÁFICAS)

PESO 75 76 76 74 72 72

INDICE









HS

21 de 74

Necesidades tecnológicas en el entorno sanitario


HS

22 de 74

Necesidades tecnológicas

Integración e Integridad

DOMINIO DEL USO

DOMINIO DEL WORKFLOW

DOMINIO DE LA ENFERMEDAD

DOMINIO DE LA SALUD

Ultrasonido

Resonancia

Terapia

Mamografía

Endoscopia

Consultas

Quirófanos

Hospitalización

BoxesINTERACCIÓN CLÍNICA(Paciente real, médico, equipamiento)

Enfermo

Sano

Nacimiento

Muerte

Medicina Basada en la Evidencia Representación del Proceso Agudo

Workflow dirigido por el sistema

Registro Electrónico de Paciente

Equipamiento Logísitica Fármacos Sistemas de

ayuda

Redes de salud Sistemas Socio-Sanitarios

INDICE









HS

23 de 74


Seguridad

SISTEMA DEINFORMACIÓN

DISPONIBILIDAD

Toma de decisiones erróneasAtacantes externos

• Virus• Ataque DoS• Spam

INTEGRIDAD

Daño a la entidad o a la personaAtacantes internos y externos

• Secuestro de sesión• Packet spoofing• Troyanos

CONFIDENCIALIDAD

Robo o mal uso de informaciónAtacantes internos en mayoría

• Escaneo• Intrusión en GUI• Sniffing

SEGURIDADFÍSICA SEGURIDAD

LÓGICA

“… ficheros que contengan datos de ideología, religión, creencias, origen racial, salud o vida sexual …” - Real Decreto Ley 994/1999, de 11 de junio Art. 4.3

Tipos de datos clasificados con nivel de protección ALTO

INDICE









HS

24 de 74


Explotación de datos

OPERATIVO

TÁCTICO

Mecanización de procesos de la actividad diaria

Soporte a la toma de decisiones

Gestión de la información frente a almacenamiento

INDICE









HS

25 de 74


Flujos de trabajo

PROCESO ASISTENCIAL

ConsultaHospitalizaciónUrgencia Atención domiciliaria

PeticiónExplor. Acción

Acción

… …

…

Petición

Petición

Extracción

Resolución Análisis

Lectura

INDICE









HS

26 de 74


Otras características

Centralización

Disponibilidad

Accesibilidad

Responsabilidad

Integración

Productividad

Control de autor / acceso Control de las modificaciones

Acceso de todos los roles Desde cualquier punto

Usuarios concurrentes Funcionamiento 24x7

Unicidad Coherencia de la información

Protocolos, estándares y calidad Gestión basada en la información

Diagnósticos efectivos Explotación de datos

INDICE









HS

27 de 74


El problema de la dimensión De un hospital medio (± 300 camas)

500.000 pacientes como población de referencia Más de 1.300 usuarios (250 médicos, 900 enfermería y técnicos, 150

administrativos) Actividad mensual 20.000 consultas, 1.300 ingresos, 800

intervenciones, 10.000 urgencias

Volúmenes de información mensual 75.000 anotaciones 25.000 informes 90.000 peticiones interdepartamentales 450.000 resultados analíticos 400.000 campos de formulario 13.000 estudios de imagen 24.000 prescripciones farmacológicas

INDICE









HS

28 de 74



HS

29 de 74


Metodología - Proceso Unificado

Arquitectura - Tres niveles, POO, DBC

Tecnología - Web, J2EE

Estrategia tecnológica Objetivos tecnológicos de un producto sanitario

Adecuado al estado del arte en desarrollo Orientación a las necesidades del usuario Obtención de un producto sólido y estable Obtención continua de resultados Mantenibilidad y capacidad de evolución

INDICE









HS

30 de 74


Requerimientos tecnológicos (I) Adaptabilidad

La arquitectura y tecnología empleadas deben proporcionar una infraestructura estable y capaz con una funcionalidad extensible

El producto ha de aportar configurabilidad y capacidad de parametrización

El equipo y la metodología de desarrollo aportan la garantía y el compromiso de crecimiento

Seguridad Cumplimiento de la normativa vigente Adaptación a los requerimientos específicos del cliente y

del entorno Balanceo entre seguridad y rendimiento

INDICE









HS

31 de 74


Requerimientos tecnológicos (II) Integración

Adopción de los estándares maduros tanto en lo tecnológico como en lo funcional

Adaptabilidad también dirigida hacia el proyecto y hacia la integración

Plataforma operativa Uso de los estándares tecnológicos para el

funcionamiento multiplataforma

Rendimiento Optimización en el proceso de desarrollo Ventajas provistas por la arquitectura

INDICE









HS

32 de 74


Plataforma básica Fundamentos

Plataforma Java – J2EE Cliente ligero sobre HTML y JavaScript Independencia de base de datos con JDBC y LDAP Independencia de plataforma operativa Diseño basado en componentes

Ventajas de esta plataforma Mantenibilidad en el ciclo de vida Seguridad física y lógica por diseño Navegador web como cliente Soporte multilenguaje

INDICE









HS

33 de 74


¿Porqué una plataforma web? Requerimiento del cliente

Cliente tecnólogo Presión del mercado tecnológico Novedad como eje de la producción

Interoperabilidad Internet como paradigma de la integración Basado en estándares

Simplicidad en el cliente Homogeneidad y sencillez en el lado cliente Regreso a la potencia de proceso central

INDICE









HS

34 de 74


El navegador web como cliente Ventajas

Sin instalación en el lado cliente Posibilidad de acceso a través de Internet Independencia de plataforma Escalabilidad, disponibilidad y seguridad delegada a la

arquitectura

Inconvenientes Funcionalidades reducidas en la capa de presentación Cambio en la forma de trabajo del usuario Imposibilidad de trabajar sin conexión Complejidad para interactuar con el sistema local

INDICE









HS

35 de 74


CAPA DE DATOS

CAPA DE APLICACIÓN

CAPA DE PRESENTACIÓN

BASE DE DATOS

MODELADO DE DATOS

LÓGICA DE APLICACIÓN

LÓGICA DE NAVEGACIÓN

PRESENTACIÓN

HIS A RIS Laboratorio HIS B Repositorioclínico

OBJETOS DE DATOS

COMPONENTES

NAVEGACIÓN

PÁGINAS WEB

Arquitectura MulticapaINDICE









HS

36 de 74


Capa de presentación Comunicación entre cliente y servidor

Se basa en http como interfaz de transmisión ¿Es seguro?

→ El SSL y su implementación https

Comunicación con el usuario Se basa en html como lenguaje de descripción ¿Vale para todo?

→ Lenguaje dinámico JavaScript

El navegador web Intérprete estándar de DHTML ¿Es un intérprete estándar?

INDICE









HS

37 de 74


Capa de lógica Soporte de toda la lógica de negocio

Posible división en múltiples subcapas

Plataformas de desarrollo de la capa lógica Java es la plataforma paradigmática

Definiciones J2EE Concepto de contenedor de servlets distribuibles

- Extensiones funcionales del servidor web, lanzados por petición http o de otro servlet, almacenados y gestionados por un servidor de aplicaciones Java

Concepto de repositorio JSP- Creación dinámica de páginas en el lado servidor

El API Servlet y JSP llevan el concepto ‘write-once, execute anywhere’ a las extensiones de servidor web

INDICE









HS

38 de 74


Capa de datos Tecnologías de bases de datos

Relacionales- Las más extendidas y sencillas

- Interfaz estandarizado SQL

- Orientadas a actualizaciones, grandes consultas y fusiones

Directorios- Orientadas a jerarquías

- Optimización de consultas

- Óptimas para información distribuida

Interfaz entre aplicación y servidor JDBC es el estándar básico de integración Java LDAP (basado en X500) para directorios

INDICE









HS

39 de 74


HL7

INTERFAZ DE CLIENTE

INTERFAZ DEACCESO A DATOS

CLIENTE

NAVEGADORWEB

DHTML

JavaScript

HTTPHTTPS

APLICACIÓN

SE

RV

IDO

R W

EB

Contenidosestáticos

SERVIDOR DE APLICACIONES

PRESENTACIÓN LÓGICA DE APLICACIÓN

Webflow

JSP

Bean deaccesoDCOM

BeanDAO

BeanDAO

COMPOSICIÓNACCESO A

DATOS

SERVIDOR DE INTERFAZ COM

Bridge Java-COM

NEGOCIO

ComponenteActiveX

DCOM

JDBC

LDAP

DATOS

SERVIDOR DE DATOS

RDBMS

SERVIDOR DEDIRECTORIO

OTRAS APLICS.

CLÍNICAS

AppletsJava

BeanDAOBean de

negocio

LÓGICA DENAVEGACIÓN

TecnologíaINDICE









HS

40 de 74


Motor de Servlets / JSPs

ServletWebflow Fuentes

de datos

Clases deControl

JSPs Modelo

Webflow.xml

[1]

[2]

Patrón MVCINDICE









HS

41 de 74


RDBMS

Directorio

Inte

rfaz H

TM

L d

e u

su

ario

Se

rvid

or H

TT

P / H

TT

PS

MODELO

CONTROLADOR

VISTA

Clases SQL

Clases LDAP

Interfaz DAOClases denegocio

Clases controladoras

Clases de formato

Frameworkcontrol

WebflowFramework seguridad

FrameworklocalizaciónJSP

Repositorio

TagLIBS

webflow.xml

Flujo de datosINDICE









HS

42 de 74


Ap

p.

Infr

aest

ruct

ura

Pla

tafo

rma

Dato

s

Opensource

Comercial

SIEMENS InformaciónRDBMS

SeguridadLDAP

JA

AS

Ja

va

Ma

il

JD

BC

JA

XP

JN

DI

J2SE 1.4.1

JT

A

JA

XR

JA

X-R

PC

JA

XM

SA

AJ JSP

Servlet

J2EE 1.3Web container Apache/Jakarta

Co

mm

on

s

FO

P

XA

LA

N

LO

G4

J

CR

IMS

ON

XE

RC

ES

JIN

TE

GR

A

CO

NC

UR

R.

HA

PI

LD

AP

JD

K

SQ

L2

JA

VA

IR

RT

F2

FO

AC

ME

ex

tHA

PI

SA

GCO

S

ex

tJT

A

NE

T

Webflow

Internac. fw. Control fw. Publishing fw. XF

CacheConvers

fw.

Conversor

Adapter

Transformer

Render

XFReport

SELENE

Mapa de componentes de infraestructuraINDICE









HS

43 de 74


Arquitectura de sistemas típica

INTRANETLAN

VLAN

DIRECTORYSERVER

RELATIONAL DATABASE CLUSTER

DOCUMENTALSERVER

APPLICATION SERVERSMATRIX

LOAD BALANCER

PRINT SERVERS

INDICE









HS

44 de 74

CAPA DE DATOS

CAPA DE APLICACIÓN


BASE DE DATOS

MODELADO DE DATOS



PRESENTACIÓN


OBJ ETOS DE DATOS

COMPONENTES

NAVEGACIÓN

PÁGINAS WEB

CAPA DE DATOS

CAPA DE APLICACIÓN


BASE DE DATOS

MODELADO DE DATOS



PRESENTACIÓN


OBJ ETOS DE DATOS

COMPONENTES

NAVEGACIÓN

PÁGINAS WEB


WORKFLOW

SEGURIDAD

PROCESO DE TEXTOS

IMPRESIÓN

PERMISOSPROCESOS

ACTOSCLÍNICOS

AGENDAS

RECURSOS

PACIENTES

INFORMES

CITACIÓNBOXES

TRIAGE

_ADMISIÓN

FORMULARIOS

OBJETIVOS:

Integridad Coherencia - Modularidad Unicidad

ESTACIÓN DE URGENCIAS

Despliegue modularINDICE









HS

45 de 74


Servidor WordMotor de Servlets / JSPs

ServletWebflow

Fuentes de datos

Clase deControlJIntegra

JSPPlantilla

[1]

[2]

Explorador Web

AppletJIntegra

Word

Documento

ODBC

Integración DCOMINDICE









HS

46 de 74


Publicación

Creación

Docum.RTF RTF2FO

XSL-FO(tags) SAX XSL-FO

ProcesadoXSLT

XSL-FO Render

PScrt

XMLPDF

RTF

Arquitectura de impresiónINDICE









HS

47 de 74


El problema de la integración Comunicación a nivel tecnológico

¿Cómo pueden interconectarse dos sistemas?- Sockets, intercambio de fichero, accesos a BD, http, XML

Comunicación a nivel funcional Interconectarse no es lo mismo que comunicarse ¿Cómo pueden comunicarse varios sistemas?

- Estándares funcionales HL7, DICOM, ASTM

Comunicación a nivel conceptual Comunicarse no es lo mismo que entenderse ¿Cómo puede un sistema entender sobre las acciones y

conceptos de otro?- Estándares semánticos SNOMED, LOINC

- Estándares integrales IHE, CEN TC251

INDICE









HS

48 de 74


Arquitectura de integración

OTRAAPLICACIÓN

CONECTORSELENE

Socketscontroller

Filecontroller

httpcontroller

OTRAAPLICACIÓN

OTRAAPLICACIÓN

CONECTOR

OPENLINK

INTER

FA

Z U

NIF

ICA

DO

XMLparser

NSPparser

Non standardmanagers

LÓG

ICA

DE N

EG

OC

IO

DICOMmanager

HL7manager

HL7parser

DICOMparser

Web servicescontroller

INDICE









HS

49 de 74



HS

50 de 74


Servicios

Colaboración

Propuestas

Conocimiento

COMERCIALCOMERCIAL

INTEGRACIÓNINTEGRACIÓN

SISTEMASSISTEMAS CONSULTORÍACONSULTORÍA

PROYECTOSPROYECTOS

INVESTIGACIÓNINVESTIGACIÓN

CALIDADCALIDAD

SOPORTESOPORTE

MANTENIMIENTOMANTENIMIENTO

ORGANIZACIÓNORGANIZACIÓN

FORMACIÓNFORMACIÓN

DESARROLLODESARROLLO

Estructura de unidades de negocioINDICE









HS

51 de 74

Clientes


Central SIEMENS

Plan de Calidad Plan de ProyectoSeguimiento

deProyecto

Sistema de gestión local

Proceso de desarrollo

Beta Site Testing

Proceso de ventasAnálisis

de riesgos

Requisitos

Plan de Producto

Plan denegocio

MejorasErrores

Actualiza

Req. calidad.

RealimentaciónMonitorización

Condicionantesde calidad

Control Actualiza

Actividades Resultadosdel riesgo

Proyecto de desarrollo de productosINDICE









HS

52 de 74


XOK

XOK

XOK

MODELO DE CASOS DE USO

MODELO DE CASOS DE PRUEBA

MODELO DE ANÁLISIS MODELO DE DISEÑOMODELO DE DESPLIEGUE

MODELO DE IMPLEMENTACIÓN

El Caso de Uso en la metodología Un caso de uso es un fragmento de funcionalidad

del sistema que proporciona al usuario un resultado importante Plantean qué debe hacer el sistema Pensar en términos de importancia para el usuario

Casos de uso como hilo conductor del desarrollo

INDICE









HS

53 de 74


La arquitectura software incluye los aspectos dinámicos y estáticos más signiticativos del sistema Definida por Casos de Uso, requisitos no funcionales,

plataforma, componentes reutilizables, etc.

Arquitectura como sustento del sistema Parte de la selección de casos de uso significativos Debe garantizar el soporte de los casos de uso actuales

y futuros La funcionalidad debe poder cambiar, la arquitectura

debe ser estable

Metodología centrada en la arquitecturaINDICE









HS

54 de 74


Proceso iterativo e incremental

Cada etapa se considera un subproyectoEl resultado es un incremento del producto final

Etapa 1.1 Etapa 2.1 Etapa 3.1 Etapa 3.2 Etapa 3.3 Etapa 3.4

Requisitos

Casos de uso

Arquitectura

Análisis y diseño

Desarrollo

Pruebas

Implantación

INDICE









HS

55 de 74


Roles Definición Prototipo Fase 1 Fase 2 Fase 3 Fin Proyecto

Resp. de Proyectos

Jefe deEquipo

Arquitecto

ConsultorFuncional

Analista

Program.

Gestor decalidad

Tester

Plan de Proyecto

Calendario

Actualizar Plan Actualizar Plan Actualizar Plan Revisar Plan

Seguimiento de Proyecto Cierre Proyecto

Dimensionar

Inicio Proyecto Ejecución de Proyecto

Definir Arq.

Construir prot.

Revisar Arq.

Definir Alcance Especificación de Requisitos y Validación de Casos de Uso

Validación de Casos de Prueba y Pruebas Funcionales

Definición de Casos de Uso

Diseño de Componentes Software

Construcción de Componentes Software

Prueba de Componentes Software

Plan Calidad

Configuración

Control de Calidad

Control de Cambios

Definición de Casos de Prueba

Ejecución de Casos de Prueba

Descripción del procesoINDICE









HS

56 de 74


Periodo 1 Periodo 2 Periodo 3

Análisis de Iteración N Análisis de Iteración N+1 Análisis de Iteración N+2

Desarrollo de Iteración N-1 Desarrollo de Iteración N Desarrollo de Iteración N+1

Testing de Iteración N-2 Testing de Iteración N-1 Testing de Iteración N

Desarrollo iterativo

Características fundamentales Se agiliza el proceso de desarrollo El tiempo de reacción es más corto ante equivocaciones

de planificación La planificación se adecua a los periodos, se establece

una respuesta funcional aunque no sea global El contacto con los consultores de negocio es constante

en cada fase

INDICE









HS

57 de 74


Iteración Análisis Iteración Desarrollo Iteración Pruebas

Responsablede versión

Obtener requisitosCierre de la iteración Entrega iteración

Planificar recursos

Responsable de iteración

Preparar reunión de planificación de la

iteración Preparar entrega de iteración

Trabajar con los analistas para llevar a cabo las funcionalidades

AnalistaTrabajar con los desarrolladores

Preparar entrega de iteraciónLlevar a cabo el análisis de las

funcionalidades de la iteración N Cerrar la iteración N

Desarrollador de dominio

Desarrollar funcionalidades

Desarrollador post-iteración

Preparar ensamblajeDesarrollo no

funcionalDesarrollo no funcional

Ingeniero de pruebas

Cerrar iteración

Probar entrega de iteración Entregar iteración

Añadir test de iteración al conjunto de los test de regresión. Realizar test.

Preparar documento de versión

Ciclo detallado de una versiónINDICE









HS

58 de 74


Iteración N-1 Iteración N Iteración N+1 Semana 1 Semana 2 Semana 3 Semana 4 Semana 1 Semana 2 Semana 3 Semana 4 Semana 1 Semana 2 Semana 3 Semana 4

Planificación Interciclo

Obtener de requisitos Iteración N

Planificar recursos

para iteración N

Entrega de iteración N-

2

Cierre de iteración

N-1

Obtener de requisitos Iteración

N+1

Planificar recursos

para iteración

N+1

Entrega de iteración N-

1

Cierre de iteración N

Obtener de requisitos Iteración

N+2

Planificar recursos

para iteración

N+2

Entrega de iteración N

Cierre de iteración

N+1

Planificación Intraciclo

Preparar de entrega de

iteración N-2

Trabajar con los analistas para llevar a cabo la funcionalidad de la

iteración N

Preparar la reunión de planificació

n de iteración N

Preparar de entrega de

iteración N-1


iteración N+1


n de iteración

N+1

Preparar de entrega de iteración N


iteración N+2


n de iteración

N+2

Análisis Trabajar con los desarrolladores en la iteración N-1 Trabajar con los desarrolladores en la iteración N Trabajar con los desarrolladores en la iteración N+1

Preparar entrega de

iteración N-2

Llevar a cabo el análisis de las funcionalidades de

la iteración N

Cerrar Iteración

N-1

Preparar entrega de iteración N-

1


la iteración N+1

Cerrar Iteración N

Preparar entrega de iteración N


la iteración N+2

Cerrar Iteración

N+1

Desarrollo de dominio Desarrollar funcionalidades de iteración N-1 Desarrollar funcionalidades de iteración N Desarrollar funcionalidades de iteración N+1

Desarrollo de iteración Preparar ensamblaje de

iteración N-2 Desarrollo no funcional de

iteración N-2 Preparar ensamblaje de

iteración N-1 Desarrollo no funcional de

iteración N-1 Preparar ensamblaje de

iteración N Desarrollo no funcional

de iteración N

Pruebas de regresión Añadir tests de iteración N-2 al conjunto de tests de

regresión. Realizar los tests. Añadir tests de iteración N-1 al conjunto de tests de

regresión. Realizar los tests. Añadir tests de iteración N al conjunto de tests de

regresión. Realizar los tests.

Probar entrega de

iteración N-2

Preparar documento de versión

de iteración N-2

Entregar Iteración N-

2

Cerrar iteración

N-1

Probar entrega de iteración

N-1

Preparar documento de versión de iteración

N-1

Entregar Iteración N-

1

Cerrar iteración N

Probar entrega de iteración N

Preparar documento de versión de iteración

N

Entregar Iteración N

Cerrar iteración

N+1

Concurrencia de versionesINDICE









HS

59 de 74



HS

60 de 74


Requerimientos básicos de seguridad Exigencias del entorno

Cumplimiento de la Ley de Protección de Datos (L.O. 15/1999) y otras normas relacionadas

- Comunicaciones cifradas

- Traza de accesos a la aplicación y datos de paciente

- Políticas de contraseña y cifrado de palabras clave

Cobertura de las necesidades de control de las entidades sanitarias (validaciones, pacientes restringidos, etc.)

Otros requerimientos deseables Equilibrio entre seguridad y funcionalidad Evitar acceso a la base de datos desde puestos cliente Misma información de acceso para todos los módulos Permisos a nivel de función y a nivel de tipo de datos Dispositivos de identificación y autentificación

INDICE









HS

61 de 74


1 CSI / FBI Survey 20032 ASIMELEC Encuesta 20033 AUSCERT 20034 CERT / CC

Panorama de la seguridad El 78% de las entidades identifican Internet como la

vía principal de ataques a sus sistemas (1)

El 55% de los accesos no autorizados a datos son realizados por personal propio (1)

Las PYMES españolas sufren entre dos y tres ataques anuales a sus sistemas (2)

Ataques de virus y spam siguen siendo las amenazas principales (80% de los daños) (3)

Tras 24 horas, el virus Blaster había infectado a 336.000 ordenadores (4)

INDICE









HS

62 de 74


Carnegie Mellon University 2003

1990 2000

Ataques deingenieríasocial en Internet

Packetspoofing

Sniffers

Herramientasde intrusiónen GUI

Ataques extensivosautomáticos

Ataques encódigoejecutable(browsers)

Secuestrode sesiones

Escaneoautomático

Técnicas deanálisis de códigosin código fuente

Ataques DoS extensivos

Ataques extensivoscon NNTP endistribución Ataques a la

infraestructuraDNS

Alta escala endistribución de Troyanos

Técnicas deescaneo avanzado /silencioso

Troyanos de Windowscontrolablesremotamente

Herramientas de DoSdistribuidas

Propagación de virus enemail

Herramientasde ataquesdistribuidos

Sofisticación de los ataques Conocimientos del intruso

Técnicas deescaneo avanzado /silencioso

Troyanos de Windowscontrolablesremotamente

Propagación de virus enemail

Herramientasde ataquesdistribuidos

Evolución de los ataques informáticosINDICE









HS

63 de 74


Debilidades características Concienciación del problema de la seguridad

Inexistencia de planes de continuidad

Nivel de complejidad de los sistemas en aumento Administración compleja Detección tardía de las lagunas de seguridad

Poco nivel de seguridad en infraestructuras Mantenimiento y actualización de los sistemas

Debilidad en los accesos a los sistemas Múltiples usuarios, mecanismos y contraseñas Inexistencia de sistemas integrales de gestión de usuarios

INDICE









HS

64 de 74


Efectos de las incidencias de seguridad

SISTEMA DEINFORMACIÓN

DISPONIBILIDAD

Imposibilidad de acceso a información en situaciones críticas

No disponibilidad de información en tiempo real

Posible riesgo para la vida del paciente

INTEGRIDAD

Diagnósticos erróneos Tratamientos inadecuados Estados de alerta

Elevado riesgo para la vida del paciente

CONFIDENCIALIDAD

Acceso no autorizado a información sensible

Robo de información confidencial

Sin riesgo para la vida del paciente

INDICE









HS

65 de 74


I y A

Controlesde acceso

Seguros

Personal

Planificación Cifrado

Seguridadfísica

Planes decontingencia

Gestión deriesgos

Actividadesde

usuario

Formación

Soporte ymantenimiento

Gestión deaplicaciones

Amenazas

Enfoque general de la seguridad

Auditoría

Políticasde

seguridad

INDICE









HS

66 de 74


Seguridad física Acondicionamiento del entorno

Control de accesos a los recintos Locales ignífugos y sistemas de extinción Sistemas de alimentación ininterrumpida

Sistemas de copia de seguridad Sistemas de copia de respaldo Gestión distribuida de copias securizadas

Sistemas hardware de alta disponibilidad

Centros de respaldo

Sistemas de seguridad para estaciones de trabajo

INDICE









HS

67 de 74


INTERNET

Red interna Red interna

Red DMZ

Backbone

SMTPHTTP

RAS

Seguridad lógica

Actualizar Configurar (puertos,

NAT, ping) Mantener

Seguridad perimetral o de red Objetivo: mantener un dominio de confianza a salvo de

ataques desde dominios en los que no se confía Solución: firewalls, proxys, VPNs, routers con cifrado

INDICE









HS

68 de 74


Seguridad lógica Seguridad de sistemas

Objetivo: mantener la continuidad y estabilidad de los sistemas productivos

Solución: controles de acceso, cuotas de disco, cifrado de ficheros y bases de datos, antivirus

La problemática de los antivirus El 80% de los daños producidos en sistemas

informáticos en el 2003 han sido causados por virus Pueden ser capaces de detectar otros tipos de software

dañino (troyanos, ataques distribuidos) Mantenimiento, actualización y distribución son la clave

INDICE









HS

69 de 74


Seguridad lógica Seguridad de usuarios

Objetivo: identificación, autenticación y autorización del usuario

Solución: mecanismos de identificación, single sign-on

El problema de la identificación – autenticación Con lo que uno sabe: contraseña, reto-respuesta,

contraseña de un solo uso Con lo que uno tiene: llave, tarjeta inteligente, tokens Con lo que uno es: huella digital, retina, reconocimiento

de voz

Buscar equilibrio entre seguridad, funcionalidad y facilidad

INDICE









HS

70 de 74


Seguridad lógica El uso de contraseñas está extendido en el 90%

de los Sistemas de Información productivos

Deben establecerse mecanismos y políticas adecuadas para su uso: Prevenir los posibles ataques externos (escuchas,

troyanos) Tener especial cuidado con contraseñas de

administrador No permitir que se compartan contraseñas No utilizar la misma contraseña para acceso a

información sensible y no sensible Todas las contraseñas deben mantenerse cifradas

INDICE









HS

71 de 74


NIVEL FÍSICO

ENLACE DE DATOS

NIVEL DE RED

TRANSPORTE

APLICACIÓN

NIVEL FÍSICO

ENLACE DE DATOS

NIVEL DE RED

TRANSPORTE

APLICACIÓN

Cifrado en hardware de enlace

IPSec

SSL, SSH, Kerberos

SMIME, PGP, SET

Seguridad de datos Objetivo: controlar el acceso, creación o manipulación no

autorizada de la información Solución: cifrado de datos, mecanismos de auditoría

Seguridad lógicaINDICE









HS

72 de 74


Seguridad lógica Extensión de SSL en plataformas web

Utiliza un mecanismo mixto de criptografía simétrica y asimétrica

Totalmente transparente a las aplicaciones Tuvo problemas de seguridad en sus inicios y las

implementaciones tienen sistemas de cifrado muy limitados

Generalización de la certificación de usuario Es el soporte de la clave pública en un mecanismo

asimétrico Políticas de certificación que permiten un planteamiento

de autentificación único Soportado en dispositivos de identificación tipo

SmartCard

INDICE









HS

73 de 74

Problemas técnicos difíciles de resolver

Problemas técnicos difíciles de gestionar

Problemas técnicos difíciles de detectar


Tipología de problemas técnicosINDICE









HS

74 de 74


Simplificar … Las brechas de seguridad más comunes, son las

más evidentes a priori Instalaciones por defecto de aplicaciones Cuentas sin contraseña o contraseñas débiles Numerosos puertos abiertos Copias de respaldo incompletas o inexistentes Antivirus inexistente o no actualizado Firewall mal configurado

INDICE









HS

75 de 74

usuario: pperez

contraseña: perico

dominio: hosp001


Simplificar … Cualquier medida es inoperante si el

uso es inadecuado

INDICE








Tecnologías en la informática sanitaria

Documents

Transcript of Tecnologías en la informática sanitaria