Interoperabilidad organizativa en IHE: Gestión de flujos de trabajo entre proveedores

1. Interoperabilidadorganizativa en IHE: Gestión de flujos de trabajo entre proveedores

2. Interoperabilidad organizativa • Escenario • Propuesta IHE • Perfil cross enterprise workflow: flujo de trabajo entre organizaciones • Marco IHE: El modelo registro-repositorio • Algunos detalles de diseño • Definición de flujos de trabajo específicos • Conclusiones

3. Escenario • En un hospital tenemos un flujo definido, un CIO que decide y sistemas estables. • El flujo está claro, es predefinido, cambia poco. • La información sobre el workflow se mueve en los mensajes entre sistemas • IHE: Perfiles flujo de trabajo de laboratorio LTW, flujo de trabajo de radiología SWF

4. Escenario • Un flujo similar entre varias organizaciones no es tan sencillo • La definición del flujo no es tan clara, además es más inestable • Sistemas de información muy diferentes • Desde una consulta privada a un hospital universitario • Actualmente hay muchas implementaciones basadas en dar acceso web • Una interfaz para cada tarea • No es escalable: quiero usar MI interfaz de usuario

5. Escenario • Necesidad • Mejorar la coordinación de la atención entre organizaciones diferentes • Gestionar flujos de trabajo más allá de los límites de una organización • Ejemplos: Derivación (eReferral) • Solución flexible para un flujo de trabajo dinámico y configurable

6. Flujos de trabajo entre diferentes organizaciones • La visión de IHE • Elementos críticos (factores de éxito) • Flujo de trabajo centrado en el paciente • Los proveedores (organizaciones, médicos, enfermeras) no deben estar ‘encorsetados’ por las aplicaciones, no podrían hacer su trabajo: libertad total al proveedor para decidir • Ninguno de los sistemas de información debe “conocer” el workflow: la información del workflow está fuera de los sistemas

7. La propuesta de IHE • perfil Cross-Enterprise Document Workflow (XDW) • permite a los participantes en un entorno con múltiples organizaciones gestionar y seguir el progreso de tareas relacionadas con flujos de trabajo centrados en el paciente, coordinando sus actividades • No hay un controlador central • No hay gestión de horarios (scheduler) centralizado • Las decisiones se toman en los extremos del sistema (proveedores: médicos, enfermeros,..)

8. La propuesta de IHE • XDW • Permite diseñar aplicaciones interoperables de gestión de flujos de trabajo, que necesitarán muy poca configuración para adaptarse a flujos específicos. • Facilita la integración de workflows que afectan a muchas organizaciones que ya usan sus propios sistemas de gestión del workflow para sus sistemas internos

9. Marco en IHE: Modelo registro repositorio XDS

10. XDS - Intro XDW en el modelo Registro – Repositorio de IHE (XDS) Centro de diagnóstico por imagen Centro de atención primaria Repositorio Registro Repositorio Imagen Hospital A Repositorio Repositorio Administración Hospital B Laboratorio Urgencias Hospital C

11. XDS – Actores y transacciones Submission Metadata Document Document XDS: Intercambio de documentos El flujo de trabajo es un documento Document Consumer Document Registry proporcionar y registrar un conjunto de documentos en el repositorio Registrar documento en el registro Document source Document Repository Adaptado de Charles Parisot. GE

12. Marco en IHE: Modelo registro repositorio XDS

13. XDW Principales aspectos de diseño • Diseñado para adaptarse a la complejidad de la provisión de servicios sanitarios, con flexibilidad • Da los medios para asociar documentos a diferentes workflows • Fácil de desplegar: no es necesario crear ninguna infraestructura central adicional (basado en XDS) • Escalable en regiones y países • Se basa en el intercambio seguro de documentos de salud proporcionado por otros perfiles IHE (e.g. XDS, ATNA, BPPC, etc.) • Proporciona un enfoque común independiente del flujo de trabajo específico. • Pero a la vez, soporta un amplio rango de “contenidos” de workflow específicos

14. Workflow document: Documento del workflow • Documento que contiene el estado específico del workflow para un paciente • Permite registrar los pasos tanto actuales como pasados del workflow y las organizaciones involucradas

15. Workflow definition: definición del workflow • workflowdefinition • Definición genérica del flujo de trabajo • tareas • Permite definir reglas • describir documentos requeridos en cada paso • definir clinicalpathways complejos para un determinado tratamiento

16. Estructura del XDW Workflow Document • Identificación del paciente • contexto general workflow • Estado, enlace al “workflow description document” • Información al nivel de tarea • Una tarea describe una actividad planeada o realizada • Atributos de la tarea • tipo • Owner (responsable de realizarla) • Estado actual (creada, en progreso, completada, etc.) • Referenciass adocumentos usados for como entrada o producidos como resultado • El Task Event History registra los eventos pasados

17. Estándares usados • Cuatro partes • Parte 1: elementos derivados de HL7 CDA • Parte 2: dos elementos, patient and author, definidos en el XDW Schema cuya estructura deriva del HL7 R-MIM • Parte 3: elementos definidos por el perfil IHE XDW • Parte 4: el elemento <TaskList> derivado de OASIS WS-HumanTask standard.

18. Individuals and organizations each have their own task management system. Some of these will use the BPEL/BPMN standards internally. • By using the same task description data element, an organization that uses BPEL internally can extract the task description from the XDW document and put it directly into their task management system when they start work. • Finished work can be extracted from the BPEL based system and put into the XDW document when complete. XD* Document Sharing Internal System XDW v1 Internal Task Management System Task

19. XDW Flow and Interactions in an XDS scenario Content Creator Content Consumer XDS Infrastructure 2. Consumers search about patient’s workflows 1. Sources post workflow document and referenced document to the XDS Infrastructure 3. Consumers retrieve selected documents from the XDS Infrastructure Content Updater 5. Consumers search about patient’s workflows Content Consumer 4. Sources update the workflow document and post possible new referenced documents 6. Consumers retrieve selected documents from the XDS Infrastructure

20. XDW Process Flow: ejemplo – consulta primaria-especialista 2- Admission of the patient 1-Visit and production of eReferral 3- Start of the Consultation The workflow within the organization is encapsulated into a single XDW step 5 – Possible notification to the GP 4 – End of the consultation and creation of the clinical report

21. XDW Process Flow: ejemplo – tareas asociadas Workflow Document task: REQUESTED Status: COMPLETED Author: Mr.Rossi Time: date/time/utc Inputs: -> Lab Report Outputs: -> eReferralDoc1 Task A: Requested Status 1: Completed 1-Visit and production of eReferral taskEventHistory TaskEvent: 1 Status: COMPLETED Inputs: -> Lab Report Outputs: -> eReferralDoc1

22. XDW Process Flow: ejemplo – tareas asociadas Workflow Document REQUESTED task: REFERRED Status: INPROGRESS Author: Mr.Brum Time: date/time/utc Inputs: -> eReferralDoc1 Outputs: -> 2- Admission of the patient Task B: Referred Status 1: In Progress taskEventHistory TaskEvent: 1 Status: INPROGRESS Inputs: -> eReferralDoc1 Outputs: -> The workflow within the organization is encapsulated into a single XDW step

23. XDW Process Flow: ejemplo – tareas asociadas Workflow Document REQUESTED task: REFERRED Status: COMPLETED Author: Mr.Brum Time: date/time/utc Inputs: -> eReferralDoc1 Outputs: -> ClinicalRepDoc2 Task B: Referred Status 2: Completed 3- Start of the Consultation taskEventHistory TaskEvent: 1 TaskEvent: 2 Status: COMPLETED Inputs: -> eReferralDoc1 Outputs: -> ClinicalRepDoc3 The workflow within the organization is encapsulated into a single XDW step 5 – Possible notification to the GP 4 – End of the consultation and creation of the clinical report

24. El perfil XDW profile frente a los perfiles de Workflow Definition • Genérico: XDW Cross Enterprise Document Workflow es: • Un marco para gestionar workflows • Una plataforma sobre la que se pueden definir un amplio conjunto de workflows específicos, con un mínimo esfuerzo de especificación e implementación • Independiente del workflow • aplicable en diferentes infraestructuras de intercambio de documentos (XDS,XDM, XDR) • Específico: Workflow Definition Profile • La definición de un proceso clínico específico • Un conjunto de reglas y definición de tareas que caracterizan el proceso • La definición de los actores implicados en el proceso y sus roles

25. Situación actual • Fase comentario público en 2011 • Se ha cambiado el formato del workflow definition document • Ahora Trial Implementation status • Se prueba en el connectathon de Berna

26. XDW – Trabajo en curso • Creación del “Workflow Definition Whitepaper”, guía para escribir un perfil de definición de workflow • Trabajo en algunos perfiles de definición concretos • Derivación: • XBeR-WD Cross Enterprise Basic eReferral Workflow Definition Profile • Telemonitorización domiciliaria • XTHM-WD Cross Enterprise TeleHomeMonitoring Workflow Definition Profile (PCC) • Comités de tumores • XTB-WD Cross Enterprise Tumor Board Workflow Definition Profile • Receta • Prescription – austria / epSOS • Mamografía • XSM Cross Enterprise Screening Mammography Workflow Definition Profile (White Paper) (Radiología)

27. Comités de tumores

30. Conclusiones • XDW es trabajo en curso • permite a los participantes en un entorno con múltiples organizaciones gestionar y seguir el progreso de tareas relacionadas con flujos de trabajo centrados en el paciente, coordinando sus actividades • No hay un controlador central • Las decisiones se toman en los extremos del sistema (proveedores: médicos, enfermeros,..) • Basado en la infraestructura XDS • Independiente del workflow concreto • Pero se trabaja también en workflows específicos

31. Interoperabilidad organizativa en IHE: Gestión de flujos de trabajo entre proveedores Paula de Toledo. IHE España Universidad Carlos III de Madrid Transparenciasadaptadas del IT Planning Committee de IHE. Luca Zalunardo, Arianna Cocchiglia - Arsenal.IT. Marzo 2012

32. XDW-TB: Tumor board

33. Escenario • Tumor board review • Análisis del diagnóstico, tratamiento y seguimiento del paciente oncológico • Equipos multidisciplinares • Tratamiento oncológico es multi disciplinar y típicamente “cross-enterprise” • Se revisan los pasos dados y los planeados • Se revisan imágenes, informes y otros documentos creados en diferentes pasos del proceso • El resultado principal del TBR es un informe consensuado con los hallazgos, conclusiones y recomendaciones para el tratamiento del paciente.

34. Objetivo del perfil XDW-tb • Definir el workflow para gestionar las tareas asociadas a un comite de tumores: • scheduling, tasks, and documents. • Seguimiento del estado de todos los pasos del workflow • Monitorizar los documentos usados en el proceso • Crear un informe integrado con las conclusiones y recomendaciones del TB • Debe resolver las necesidades actuales y ser extensible para adptarse a requisitos futuros

35. Contenido del perfil • XTB-WD • Describe los diferentes pasos de un proceso de Tumor board review • Y la información que los sustenta como documentos de entrada y salida y que está ligada a cada paso del proceso • The different Workflow definitions can be used as ‘building blocks’ to describe the actual care pathway of an individual patient.

36. Relación de este trabajo con un pathway oncológico

37. XTB-WD steps and documents

38. Actores / transacciones XDS Documentsourcewithfodermanagemt & documentreplacementoptions XDS Documentconsumer XDS Documentsourcewithfodermanagemtoptions

41. <ns3:taskData>   <ns2:taskDetails> <ns2:id>urn:oid:1.1.1.1.1</ns2:id> <ns2:taskType>RequestTBR</ns2:taskType> <ns2:name> Request Tumor Board Review</ns2:name> <ns2:status>COMPLETED</ns2:status> <ns2:createdTime>2006-05-04T18:13:51.0Z</ns2:createdTime> <ns2:lastModifiedTime>2006-05-04T18:13:51.0Z</ns2:lastModifiedTime> <ns2:renderingMethodExists>false</ns2:renderingMethodExists> </ns2:taskDetails> </ns2:description> <!-- input documents --> <ns2:input> <ns2:part name="document"> <!-- Document useful to understand the reason of the Request --> <!-- uid: the document uniqueId, home: the homeCommunityId --> <reference uid="urn:oid:1.2.3.4.4.3.2.2.3" home="urn:oid:1.2.3"/> </ns2:part> </ns2:input> <!-- output documents --> <ns2:output> <ns2:part name="Request Document"> <!—Request document --> <!-- uid: the document uniqueId, home: the homeCommunityId --> <reference uid="urn:oid:1.2.3.4.4.4" home="urn:oid:1.2.3"/> </ns2:part> </ns2:output>  </ns3:taskData>

42. Completion of the De-Identification Cookbook • Instructions to other IHE domains on how to create profiles that use Anonymization and pseudonymization tools. • Critical and Important Results – White paper • Notify someone when something critical or important is uncovered. Discover who should be told about this information and how should they be told.

43. Workflow manager has to give full power to provider • If we put technical barriers we are lost • There shall be no system in the infrastructure that knows about the workflos • Organize information around episode of care • An episode of care is a workflow center • Einforce some very simple things

44. format of this task description based upon OASIS Human Task standard. The Human Task standard is defined to provide an interface between the highly prescribed and automated world of BPEL/BPMN task automation, and the unpredictable changing world of human tasks, such as medical activities.

45. Tecnica • Gestión distribuida del workflow • Parten de prescripción electrónica • Estandares • Bpl • Humantask (derivado del anterior) • Para describir acciones humanas • Primera parte derivada de hl7 • Después info que describe los steps del workflo • Viene del estandrahumanask • Trazas del workfow y estado (abierto, cerrado) • El docu de workflow se comparte en el registro

46. Dos niveles de definición del workflow • Los dos en el workflowdocument • Es un documento – se usa un estándar • Sistemas que ya tengan un gestor de worflow con BPL pueden reutilziar • Guía de implementacion en PCC • Case use especificos • eReferal • Telemonotirización • Centritumori – grupo holandés • Screeningmamografico