Plan Estratégico de Tecnologías y Sistemas de Información

Transcripción

1

2 Plan Estratégico de Tecnologías y Sistemas de Información Qué tenemos? TSI & EMPI ERP EcoFin A.P. 100% con BD Centralizada HCE e Imagen: HSLL, HMAN, Ibiza 2006 Historia de Salud Puesta en marcha de 2 nuevos hospitales Piloto de Receta Electrónica Sistema de Información 061 2

3 Proyectos 2006 Nuevos Hospitales Concurso 1 Puesta en marcha 2 nuevos hospitales: INCA y Menorca Inca: nuevo Hospital Menorca: gestión del cambio Proyectos de servicios a 3 años Incluye HIS, HCE, RIS & PACS, Departamentales Entorno centralizado Enviado al DOCE Concurso 2 Dotación local de infraestructura (red y microinformática) Soporte local Incluye Formentera 3

4 PESI P1 HISTORIA DE SALUD Uno de los proyectos prioritarios resultado del plan de sistemas desarrollado en IBSalut es la creación de la Historia de Salud electrónica que sea accesible desde todos los niveles asistenciales y que se apoye tanto en la base de datos poblacional como en la aplicación existente actualmente en Atención Primaria. 4

5 Active PESI DE LA DIGITALIZACIÓN A LA TRANSFORMACIÓN La Historia de Salud es el proyecto que va a permitir alinear mejor las Tecnologías de la Información con los procesos de negocio User relations passive Focused on medicine Augmented health concepts Cambio de los procesos de negocio Reingeniería de procesos Framework de Interoperabilidad Nuevos servicios y fórmulas Romper con barreras tradicionales (hospitales primaria ) Preparando el terreno Digitalización de Sistemas de Información Asistenciales (Hospitales, A. Primaria y SocioSanitaria) Nuevos Hospitales Definir un framework de interoperabilidad Toda la información necesaria accesible al clínico Paciente participa del proceso Innovation and services 5

6 Marco de la Historia de Salud Índice de aspectos Estrategia Directrices y principios estratégicos Condicionantes clave Beneficios esperados Estrategia y fases de implantación: mejoras a corto plazo vs. visión objetivo Modelo de integración Modelo operativo Definición de responsabilidades Marco de relación entre los organismos y entidades involucradas Mecanismos de gobierno y gestión del Programa Organización y recursos Enfoque de contratación externa Arquitectura de referencia, normativas y estándares aplicables Definición funcional a alto nivel de mensajes asociados a la Historia de Salud Requerimientos de mensajería: Protocolos Comportamiento Formatos Modos de operación e integración Calidad de servicio Otros: control de versiones, gestión de errores, direccionamiento, etc. Requerimientos para la integración con sistemas legacy Condicionantes de la situación actual Criterios de comparación de tecnologías Arquitectura de datos Modelo de seguridad Arquitectura de aplicación Modos de acceso a la Historia de Salud Definición a alto nivel de interacciones entre aplicaciones 6 Definición conceptual de modelos de datos clave Estructura y arquitectura de datos de la Historia de Salud Relaciones con modelos de datos existentes Estándares claves de datos y nomenclaturas Arquitectura de referencia, normativas y estándares aplicables Organización y políticas de seguridad Requerimientos de seguridad: Gestión de la seguridad Controles de seguridad a nivel de aplicación Servicios comunes de seguridad Requerimientos de gestión de identidad y acceso Modelo operativo en la definición de roles Condicionantes de la situación actual Criterios de comparación de tecnologías

7 Presentación introductoria El proyecto de Historia de Salud, por su importancia y por el impacto que tiene en el resto de proyectos definidos por el Plan de Sistemas es un proyecto estratégico que servirá de arrastre de todas las iniciativas a desarrollar por IBSalut. 7

8 Situación Inicial Aproximación a la Historia de Salud Portal Procesos clínicos (Workflow) S. Informacional (DTWH) Historia de Salud Servicios de Mensajería Seguridad y auditoría Definición EHR CDR ATENCIÓN ATENCIÓN ATENCIÓN PRIMARIA PRIMARIA PRIMARIA ATENCIÓN ATENCIÓN ATENCIÓN ESPECIALIZADA ESPECIALIZADA ESPECIALIZADA Ambulancias Terminologías y catálogos ASISTENCIA ASISTENCIA SOCIOSANITARIA SOCIOSANITARIA Laboratorio Sistema RIS + PACS Atención Primaria H1 H2 H3 H5 H4 Sistemas Propietarios H6 Gestor de Identidades para Sanidad (SSO) Base de Datos Poblacional + EMPI Sistema de Información 1 Sistema de Información 2 Personal Sistema de Información 3 8 Recursos Sistema de Información 4 CMBD Morbilidad Farmacia Sistemas de Información Futuros

9 Historia de Salud Arquitectura ilustrativa Pacientes Clínicos IVO T A TR S ILU Gestores Portal Clínico Laboratorios Consultas, Gestión de Peticiones, Workflow Labs (Lab Results) Gestión de conocimiento Resumen de la Historia de Salud Datos demográficos, Diagnosis, Prescripciones, Alergias, Resultados Resultados Gestión terminología CIVITAS Catálogo de recursos Gestión Clínica Payers (Encounters) Otros sistemas Provider Legacy Systems (Diagnosis/ Clinical History) EMPI Repositorio centralizado Análisis de recetas Lista de Espera FIC Motor de Integración Modelo de Seguridad Servicios asociados al desarrollo, integración y soporte 9 Gestión asistencial

10 De, únicamente, TI. A Innovación de Procesos y TI, incrementando el valor creado por TI al negocio TI Mañana TI Hoy Gestión de Procesos Integración y Aplicaciones TI operación e infraestructura La cuestión fue... Cómo desarrollar un framework o conjunto de herramientas que cambién la discusión hacia un diálogo basado en valor para el servicio de salud y no sobre únicamente TI? 10

11 Claves Ficha de Salud Portal Clínico: framework Identificación del paciente (EMPI) Seguridad e Identificación del profesional (GIS) 11

12 Historia de Salud Ficha de Salud Resumen de Titulares de Salud del ciudadano No suplanta a las aplicaciones existentes (SIAP, HIS) PORTAL CLÍNICO Acceso directo a utilidades y aplicaciones (SIAP, HIS) y documentos de la Historia Clínica manteniendo el contexto de paciente Ficha de Salud Acceso a aplicaciones 12

13 Sesión interactiva sobre requerimientos clave (25 usuarios clave) Pregunta: REQUERIMIENTOS CLAVE DE LA HISTORIA DE SALUD Escriba las ideas más importantes para usted de forma breve Escriba entre 3 y 5 ideas Cada idea en una cartulina Tiempo: 10 minutos 13

14 Requerimientos clave Conclusiones Tras la sesión de trabajo realizada los aspectos clave que debe cubrir el proyecto de la Historia de Salud son los siguientes: 10 Claramente estructurada Búsqueda de información Contenidos pactados definidos Estructura de información Homogeneizar conceptos Acceso directo a campos específicos Diagnósticos Datos sanitarios comunes (antecedentes, alergias, alarmas, ) Información descriptiva Ficha de Salud Filiación: paciente, médico Tratamiento actual Tratamiento actual (hoja de medicación activa) 14

15 Requerimientos clave Conclusiones Sencilla 8 Útil Sencillez de manejo 8 Fácil interpretación por personal general y auxiliar Sencilla Debe mantener información de Salud útil y variada Fácil introducción de datos Fiable Práctica Rápido acceso a la información 5 Útil Fiabilidad Calidad de los datos de entrada 15

16 Requerimientos clave Conclusiones Integral 6 Completa Información integral: lanzador de aplicaciones unificado, integral Universal Útil Completa Integral pero útil Actualizada Seguimiento de los procesos independiente del ámbito (AP, AE, ) 4 Eliminar barreras de la dispersión de la información clínica Actualización Tratamiento actualizado (posibilidad de tener los tratamientos administrados o prestados por los diferentes profesionales) 2 Complemento a mis aplicaciones actuales Actualizada 16

17 Requerimientos clave Conclusiones Accesible 3 Segura Tener los datos necesarios en el momento necesario Accesibilidad Seguridad Accesible Disponibilidad Accesible 2 Confidencial (mantener la confidencialidad pese a que accedan muchos usuarios a distintas secciones, zonas reservadas para diferentes profesionales?) También Flexible, adaptable Visión personalizada de datos Adaptada a perfiles Metodología para patologías activas: problemas, episodios Evitar duplicidades 17

18 Panel de discusión Sesión de Trabajo con Usuarios Clave 1. Definición de los apartados de la Ficha Resumen 2. Identificación para cada apartado de la Ficha Resumen de: Definición de la información que debe constar, estableciendo aquellos elementos que aportan más valor Barreras y riesgos para la implantación Factores clave de éxito De dónde extraer la información? Es una primera reunión sobre el contenido de la Ficha Resumen. El objetivo es intentar cubrir todos los apartados que se definan. Se definirán reuniones más especificas según sean necesarias. 18

19 Requerimientos clave Ficha resumen de la Historia de Salud Contenidos preliminares (desglose) PORTAL CLÍNICO Ficha de Salud Nombre y apellidos Fecha de nacimiento Sexo Dirección NIF o pasaporte Número de Tarjeta Sanitaria Situación laboral Profesión Médico de atención primaria y centro de Salud / Sector Acceso a aplicaciones Problemas de Salud (relevantes) Alertas (críticas) Datos de filiación Alergias Medicación de riesgo: Anticoagulantes Inmunodepresores Riesgo biológico o epidemiológico relevante Problemas relevantes (etiquetados como P en Atención Primaria) Diagnósticos principales de ingreso Hospitalario (CMBD) Tratamiento farmacológico (activo) Contactos (pendientes y activos) Pruebas pendientes: Laboratorio Imagen Fecha de inicio / duración Modificaciones Nombre comercial y principio(s) activo(s) Dosis / pauta CIAS Números de historia clínica (de AP y de todos los hospitales donde haya sido atendido) Citas Otras técnicas terapéuticas Dirección, teléfono(s) de contacto, dirección de Fecha de la última visita al Centro de salud Procedimientos (activos) Lugar de nacimiento Fecha Hospitalización Oxigenoterapia Nacionalidad Acceso a pruebas pasadas Psicoterapia Otros 19

20 Requerimientos clave Aspectos relevantes a tener en cuenta A modo de resumen, los aspectos más relevantes a tener en cuenta para el proyecto de la Historia de Salud son: Funcionalidad: Capacidades de búsqueda Estructura Agilidad y rapidez de manejo Abierta vs. Estructurada Seguridad alineamiento con requerimientos legales Equilibrio de necesidades AP AE Flexibilidad en la presentación de información Adaptada a perfiles, con fondo común Visión cronológica Aspectos trascendentes / activos Capacidad de filtrado y establecimiento de criterios de relevancia Personalización en función del perfil del paciente (ej. edad, sexo) Necesidad en AP de identificar claramente problemas; por ejemplo estableciendo el criterio de etiquetar claramente los problemas (ej. P ) Estrategia de mejora continua, incluyendo mecanismos para la entrada de cuestiones al sistema, controles de auditoria Interconexión con entidades externas concertadas 20

21 Historia de Salud Portal Clínico Como punto central del desarrollo del proyecto de la Historia de Salud, está el Portal Clínico que servirá como punto de acceso único para el profesional y que le permitirá acceder a la información básica de los pacientes, así como, a las diferentes aplicaciones a las que tiene permiso. Portal de asistencia sociosanitaria Portal del Profesional de Salud Portal Clínico Médicos Ficha de Salud Pacientes Portal de Salud del Ciudadano 21 Portal del Proveedor

22 22

23 Características de un Portal Clínico Personalization: permite construir vistas de información diferentes sobre el mismo repositorio de datos (uno o múltiples) Workflow Management: datos que vienen de diferentes sistemas y son agrupados en una vista para el profesional clínico. Permite organizar tareas e interactuar con otros sistemas de información. Quick Integration: típicos datos a incluir en el portal son datos demográficos, resultados de laboratorio, radiología (informes e imágenes), ECG. Single signon : el professional clínico no quiere identificarse en cada sistema de información diferente. (CCOW) Context Management: identificación del paciente solamente una vez en cualquier subsistema de información (CCOW) Transcription : posibilidad de generar informes en el sistema (anatomía patológica, radiología, terapia) 23

24 Why a Clinical Portal? Costs and risks associated with implementing a large system from a single vendor Retain options for implementing bestofbreed applications Retain investment (dollars and IP) in existing systems Allows for an incremental approach Reduced risk Quick wins for clinical staff Avoid lockin to one vendor Provide wider and more unified view of clinical data Add immediate value (quick wins) to ensure clinician byin Integrate data from existing systems Incremental solution 24

25 Ejemplo de coste y complejidad de modelos (CalRHIO & Accenture) 25

26 Herramientas para la Historia de Salud: framework 26

27 Historia de Salud El Portal Clínico acceso y contenidos Acceso al portal clínico IVO T A TR S ILU Portal de aplicaciones clínicas Por favor, introduzca su identificador de usuario y contraseña Usuario Contraseña 27

28 Historia de Salud El Portal Clínico acceso y contenidos Búsqueda del paciente IVO T A TR S ILU 28

29 Historia de Salud El Portal Clínico acceso y contenidos Contenidos Utilidades Contexto de paciente Lanzamiento de aplicaciones Ficha de Salud / Área de aplicación O TIV A TR S ILU 29

30 Ficha de Salud Ejemplo Ficha de Salud

31 Historia de Salud El Portal Clínico acceso y contenidos 31

32 Historia de Salud El Portal Clínico acceso y contenidos 32

33 Historia de Salud Proyectos de valor a medio plazo con una visión global Desarrollo de modelo global de Historia de Salud FASE I Arquitectura base Integración completa Base de Datos Poblacional EMPI Estándares de nomenclatura Arquitectura de Integración y Seguridad Arquitectura de Portal Clínico Definición Fase II: grupos de Trabajo FASE III Portal Clínico Básico Funciones avanzadas Acceso a Ficha de Salud con conjunto mínimo de datos Contactos y Estado del paciente con el Sistema de Salut (LEQ, CMBD, Pruebas Pendientes, etc.) Catálogo de recursos (FIC) FASE II Medicación ambulatoria Enlaces a otras aplicaciones: grupos de usuarios y perfiles (médicos de urgencias, ) Prototipos Integración con entidades externas / concertadas: peticiones, resultados (informe e imagen), económicofinanciera Pacientes: VIH, Comunidad Diabetes, 33 Gestión de Peticiones Corporativo (CPOE) Programas de Salud y Protocolos clínicos Herramientas avanzadas de soporte a la decisión clínica Portal Clínico del Paciente Socio Sanitario, Residencias

34 Historia de Salud Tareas de validación previas a Proyecto de Accenture 1. Instalar Concerto & Soprano en OTIC 2. Integrar Concerto con EMPI 3. Construir Prototipo Pantalla Historia de Salud Datos de Filiación Alertas (críticas) Contactos (Pendientes y Activos) Problemas de Salud Relevantes Tratamiento farmacológico activo (esiap) Procedimientos Activos 4. Pruebas de funcionalidades de Concerto Herramienta de Proveedores Abrir otras aplicaciones: Imagen PACS, HIS Hospitales, esiap VIH 5. Desplegar Concerto como Portal Clínico en Ibsalut: DGTIC SSO: Gestión de Identidades / Seguridad Qué pasa en A. Primaria??? 34

35 Historia de Salud EMPI : Enterprise Master Patient Index Situación inicial en qué se dispone de un amplio conjunto de sistemas totalmente aislados. Existencia de múltiples sistemas en los que se registran datos de pacientes. La calidad de los datos registrados impedía un enlace automático de los registros de pacientes. Necesidad de una visión global del paciente. 35

36 Antecedentes: Situación inicial TSI MARÍA NIEVES SAENZ VARGAS SNVR MARÍA SAEZ VARGAS SZVR NIEVES Z 18 HSLL NEUS SAENZ BARGAS MANUEL JAUME LOPEZ HMAN HSDU Z

37 Antecedentes: Problemas de la situación inicial Pobre calidad de datos. Dispersión de datos. Falta de canales de sincronización. Dificultades para localizar pacientes. Imposibilidad de integrar sistemas. Imposibilidad de unificar los datos entre sistemas. 37

38 Descripción Proyecto EMPI Es un índice maestro de pacientes. Permite identificar a los pacientes de forma unívoca dentro de todos los sistemas de información del ibsalut. MARÍA NIEVES SAENZ VARGAS HSLL HMAN HSDU SNVR Z Implementar una plataforma EMPI (Enterprise Master Patient Index) Seguimiento estándares: directiva de IHE IT (Infrastructure Tecnical Framework). En particular el EMPI implementa el perfil de integración PIX definido por IHE. 38

39 Descripción EMPI: Objetivos de la plataforma EMPI: Identificación individual de personas para propósitos tanto propios de salud como administrativos. Enlace de diferentes registros de información sanitaria (del mismo o de diferentes sistemas) que corresponden al mismo paciente. Piedra angular de la Historia de Salud 39

40 Descripción EMPI: Arquitectura Beagle: Buscador estructurado de pacientes. Se utiliza para mantener actualizada la información del EMPI. EMPI Platform IHE Transaction Layer Beagle PatFinder Cartridge Hub BigBrother PatFinder: Buscador desestructurado de pacientes. Se utiliza para implementar un buscador estilo Web. BigBrother: Módulo interno de autodepuración de la información. EMPI Repository Indexing System 40

41 El motor Beagle Intentará ubicar al paciente, mediante la adaptación a la información estructurada, disponible en cada caso. El efecto de dos grafías validadas (misma palabra): Gimenez / Jimenez Palabras diferentes y validadas pueden confundirse El caso de la equivalencia idiomática: Pere / Pedro Los identificadores débiles intersistema Gemelos: no son la misma persona El cambio de residencia y su efecto Dislexias habituales: fechas El diccionario corrige abreviaciones y errores de trascripción Casos recurrentes: palabras prohibidas y valores por defecto 41

42 El buscador de pacientes PatFinder Capacitado para localizar al paciente entendiendo la información suministrada sin estructura. Buscar: Sebastián López López Barceló, Sebastián UIP: CIP: LPBR NHCSLL: García López, Sebastián UIP: CIP: GRLP NHCHVT: 4563 Sebastián López, Joan UIP: CIP: SBLP NHCMAN: López Vicens, Sebastià UIP: CIP: LPVC NHCSIAP: NHCSLL: NHCSD: NHCSD: NHCCM: 14522

43 El módulo BigBrother De la experiencia práctica provienen nuevas reglas. Las nuevas reglas se aplicarán a la información de pacientes existente para: Obtener correlaciones no detectadas. Localizar correlaciones erróneas. 43

44 EMPI Resultados obtenidos: Duplicados internos TSI H1 H2 H3 H4 H5 AP Registros Personas Duplicados % Duplicados 0,13% 1% 8% 0,27% 6% 1,04% 1,48% 1,04% 44

45 Resultados obtenidos: Distribución según Tarjeta Sanitaria Población Distribución de pacientes según TSI Historiales en hospitales* % de éxito de TSI Fundació Hospital Son Llàtzer ,8% Hospital Can Misses ,4% Hospital Verge del Toro ,1% Hospital Universitari Son Dureta ,9% Fundació Hospital de Manacor ,8% 1, ,9% Global * Se computan los pacientes que deberían estar (según TSI) en el hospital y realmente están 45

46 Seguridad Elementos del modelo de Seguridad arquitectura tecnológica de seguridad Controles técnicos de Seguridad Controles a nivel de aplicación Modelo de autorización Auditoria y registro de actividad Integridad de datos y mensajes Firma Digital Anonimización Confidencialidad del paciente Autenticación, SSO y control de Sesiones Estándares de seguridad en desarrollo Seguridad en la arquitectura de integración Clasificación de datos Servicios comunes de arquitectura de seguridad: PKI, gestión de identidad y acceso, auditoria centralizada, etc. Controles a nivel de infraestructura (LSPSCXI) Infrastructure Controls Para cada entorno Compartidos Seguridad personal Seguridad física Seguridad de red Seguridad de la plataforma Servicios criptográficos Seguridad de integración Gestión de parches y vulnerabilidades Gestión de logs y auditoria Gestión de alertas Administración de seguridad 46 Seguridad de estaciones cliente

47 Historia de Salud Gestor de Identidades Integrador gráfico Aplicación 1 Aplicación 2... Aplicación n Gestor de contexto Directorio de usuarios 47 EMPI

48 Anexo. Seguridad Elementos del modelo de Seguridad componentes clave Gestión de identidad y acceso: Autenticación de usuarios Gestión de sesiones Control de acceso basado en roles Restricción de acceso dependiendo del paciente y la organización o equipo de trabajo del usuario Control por parte del paciente Auditoria y gestión de eventos Definición de roles Organizaciones Rol Seguridad en la integración de sistemas Necesidad de alta disponibilidad Área de trabajo Funciones Un control de Acceso puede tener en cuenta las múltiples dimensiones del perfil de un usuario Normativa legal Un solo usuario puede tener múltiples perfiles 48 = Perfil de Usuario

49 Lecciones aprendidas Portal Clínico incrementar la utilización de los datos clínicos en una organización. Dos claves importantes: resultados de laboratorio y firma electrónica de documentos. Es el paso previo a introducir a la introducción de un Gestor de Peticiones. Al clínico no le interesa la tecnología, simplemente quiere rápido acceso a los datos desde cualquier sitio. Los Portales tienen alta visibilidad en una organización y ayudan al Director de TI a ganarse la confianza del clínico. Tiempos de implementación breves (6 a 9 meses). La mejor forma de poner en marcha un proyecto de Historia de Salud es mediante una estrategia de Portal. 49

50 La demanda del mercado

51 es mayor que la realidad de los Sistemas de Información