Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Demo MedicalStIm

Primera demo del sistema integrado MedicalStIm para el cliente.
by

Diana Sormani

on 14 May 2010

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Demo MedicalStIm

Sistema MedicalStIm Flujo sin Work List Aplicación Matching Casos de Prueba Flujo con Work List Introducción:
Componentes del sistema integrado MedicalStIm
Flujo sin worklist
Otros Servicios
Aplicación Matching MedicalStIm
Casos de prueba (sin WL)
Flujo con worklist
Análisis FODA Medical Static Images ¿Cómo funciona el flujo SIN WL a alto nivel? Otros Servicios ¿Cómo saber si un estudio está disponible? ¿Cómo eliminar estudios no matcheados? ¿Cómo visualizar estudios? Sistema integrado ¿Qué es el sistema MedicalStIm? ¿Qué componentes tiene para hacer esto posible? Se abre el cabezal del archivo DICOM.
Se obtienen los datos a analizar. En particular: identificador de paciente, modalidad y fecha.
Se consulta la tabla PENDING_TRAY buscando estudios en estado SCHEDULED.
Se intentan matchear los datos mencionados.
Si existe UN UNICO registro se matchee:
* Se marca como COMPLETED
* Se guarda el Study Instance UID
Si el registro no es único o si no existe ninguno que matchee:
* Se crea un alta en la tabla UNMATCHED_TRAY. ¿Cómo funciona el flujo SIN WL a bajo nivel? Objetivo de la aplicación Matching Inbox Gestión de Estudios Ayuda en línea Pruebas de flujo integrado CON Matcheo Pruebas de Estrés Pruebas de flujo integrado de Series Pruebas de flujo integrado SIN Matcheo ¿Cómo funciona el flujo CON WL a bajo nivel? ¿Cómo funciona el flujo CON WL a alto nivel? Consume un web service a través de MedicalStIm
Canal de Mirth Connect :"New Study Request".
Especifica que se trata de un EA que NO maneja worklist
HIS
Sistema de Agendas Llega el Paciente Este evento se registra como la llegada física del
paciente a realizarse el estudio (no su registro en la
agenda)
HIS
Sistema de Agendas Llega el Paciente Consume un web service a través de MedicalStIm
Canal de Mirth Connect :"New Study Request".
Este evento se registra como la llegada física del
paciente a realizarse el estudio (no su registro en la
agenda)
Parsea los datos del web service.
Genera un alta en la tabla PENDING_TRAY.
Retorna el identificador de PENDING_TRAY (vínculo
entre HIS y MedicalStIm)
Genera un archivo de log con los datos pasados.

Mirth Connect
New Study Request Mirth Connect
New Study Request Parsea los datos del web service.
Genera un alta en la tabla PENDING_TRAY.
Se genera dos mensajes HL7 y los envía al PACS.
Retorna el identificador de PENDING_TRAY (vínculo entre HIS y MedicalStIm)
Genera un archivo de log con los datos pasados.

DCM4CHEE Se crea una entrada en la worklist de DCM4CHEE

Técnico realiza
el Estudio El técnico cuenta con una estación de trabajo HIS.
Selecciona de sus estudios para realizar, el del paciente en cuestión.
Ingresa identificador de paciente. (Requerimiento mínimo) DCM4CHEE Se recibe el estudio enviado por el EA
Se crean registros vinculados al nuevo estudio.
Se marca el estudio como COMPLETED.
Se guarda el estudio en el sistema de archivos.
Se obtiene el cabezal del archivo DICOM.
Se envía SOLO EL CABEZAL a Mirth Connect: canal DICOM_AE_PACS. Mirth Connect
DICOM AE PACS Mirth Connect
DICOM AE PACS Se abre el cabezal del archivo DICOM.
Se obtienen los datos a analizar. En particular el campo SPSID.
Se consulta la tabla PENDING_TRAY buscando estudios en estado SCHEDULED.
Se matchean los datos mencionados con el ÚNICO registro existente para este estudio. Este estudio es el que tiene un SPSID = PenTrayId.
E.A
Nuevo Estudio Con el workitem seleccionado, el técnico realiza el estudio.
Si bien el identificador de paciente es dato mínimo, como el estudio fue dado de alta por proceso, es seguro que existe. Técnico realiza
el Estudio DCM4CHEE Realiza el C-STORE
Envía el estudio a MedicalStIm a través del PACS
DCM4CHEE Se marca el estudio como COMPLETED.
Se guarda el estudio en el sistema de archivos.
Se obtiene el cabezal del archivo DICOM.
Se envía SOLO EL CABEZAL a Mirth Connect: canal DICOM_AE_PACS.
Consulta de WL El EA es configurado para que periódicamente consulte la lista de trabajo al PACS.
El técnico carga su lista de trabajo en el EA donde realizará el estudio.
Selecciona el workitem correspondiente al estudio del paciente en cuestión. Pruebas sobre flujo con Work List FODA Ventajas Desventajas
PACS DCM4CHEE.
Mirth Connect.
Aplicación Matching MedicalStIm.
Oviyam.
El objetivo principal de la aplicación Matching MedicalStIm es permitir establecer una correspondencia entre un registro de solicitud de estudio médico generada por el HIS y el estudio efectivamente enviado por el equipo de adquisición.
Provee al usuario de una interfaz que permite visualizar todos los datos disponibles de los estudios denominada Matching Inbox.
Permite la visualización de los exámenes ya enviados por las modalidades a través de la aplicación Oviyam. Acceso a un help on line desde el sistema.
Ayuda por página del sistema. Consumo de web service de entrada vía SOAP UI (generación de solicitud de estudio)
Generación de C-STORE del estudio vía:
* Vista Box
* Línea de comando (dcmsnd)
Verificación de generación de log.
Verificación de NO matcheo automático (control de PENDING_TRAY y UNMATCHED_TRAY)
Verificación tanto para matcheos múltiples como no existentes.
Matcheo Manual vía Matching Inbox. Verificación de impactos.
Llega el paciente a realizarse el estudio médico.
El HIS consume un web service publicado por MedicalStIm realizando una "Solicitud deEstudio", generando una entrada en la lista de trabajo de DCM4CHEE.
El Equipo de Adquisición (EA) consume la lista de trabajo desde el PACS.
El técnico revisa su lista de trabajo desde el EA, selecciona el estudio y lo realiza.
El EA envía el estudio a MedicalStIm: PACS DCM4CHEE
El PACS reenvía el estudio hacia MedicalStIm a través de Mirth Connect.
El sistema matchea con la única solicitud de estudio.
Se establece esa correspondencia y se disponibiliza el estudio para el HIS. El objetivo princial es gestionar el ciclo de realización de estudios médicos.
El ciclo comienza al llegar un paciente a realizarse un estudio médico.
El HIS se comunica con el sistema MedicalStIm solicitando el estudio.
El técnico realiza el estudio en un Equipo de Adquisición (EA).
El EA envía el estudio a MedicalStIm.
El sistema MedicalStIm define si existe solicitud asociada al estudio.
Se disponibilizan los estudios para el HIS para acceso y visualización.
Llega el paciente a realizarse el estudio médico.
El HIS consume un web service publicado por MedicalStIm realizando una "Solicitud de Estudio".
El técnico realiza el estudio en un Equipo de Adquisición (EA).
El EA envía el estudio a MedicalStIm: PACS DCM4CHEE
El PACS reenvía el estudio hacia MedicalStIm a través de Mirth Connect.
El sistema verifica si el estudio realizado matchea con una única ''Solicitud de Estudio".
Si matchea, se establece esa correspondencia y se disponibiliza el estudio para el HIS: tanto para acceso como visualización.
Para los casos en que el matcheo no se haga automático, el sistema provee una aplicación web "Matching MedicalStIm" a través de la cual se permite hacer el matcheo manual. E.A
Nuevo Estudio Realiza el C-STORE
Envía el estudio a MedicalStIm a través del PACS
DCM4CHEE ¿Cómo se comprimen las imágenes?
MedicalStIm provee un servicio de "Time To Live".
En Mirth Connect existe el canal TTL en el cual se le configuró que todos los días a las 3 AM se eliminen las solicitudes de estudio no matcheados en las anteriores 48 horas.
El valor del time to live es configurable.
El efecto de este servicio es eliminar todos los registros de la tabla PENDING_TRAY existentes que cumplen la condición anteriormente mencionada. MedicalStIm provee dos formas de visualización:
1) Acceso vía WADO: se provee manual indicativo de acceso y parametrización.
2) Acceso vía Oviyam: la aplicación provee integración con la aplicación Oviyam, configurada para el repositorio de estudios desde Matching MedicalStIm.
En todo momento el HIS puede preguntar por la disponibilidad de un estudio.
El HIS puede consumir un web service publicado por MedicalStIm a través de Mirth Connect: canal "Study Availability"
El web service retornará los siguientes valores:
* Si el estudio está COMPLETED, el web service retornará el estado más un hipervínculo para el
acceso vía Oviyam.
* Si el estudio no fue matcheado, retornará un indicador de que el estado del estudio es aún
SCHEDULED . Se configura DCM4CHEE para provee compresión. (PLL|JLSL|J2KR)
La compresión se puede configurar por tipo de estudio.
Se puede configurar que se haga a partir de determinada cantidad de días para permitir hacer primero la visualización por diagnóstico. Despliega los estudios pendientes (SCHEDULED) en una grilla y los estudios no matcheados en otra para asistir al usuario a establecer la correspondencia.
Sistema de selección uno a uno.
Organización de la información en forma conveniente para permitir la elección de los registros.
* Listado de datos más relevantes por registro.
* Visualización vía Oviyam integrada a las grillas.
* Acceso a detalle de cada estudio vía ventana emergente por registro.
* Tooltips de datos extendidos.
Funcionalidad de matcheo:
* Control de datos.
* Ventana emergente para desplegar discrepancias.
Impactos de matcheo:
* Se registra que el matcheo se hizo manualmente.
* Se marca usuario y fecha de matcheo manual.
* Se deja el estudio COMPLETED y con el Study Instance UID.
* Se elimina el registro de UNMATCHED_TRAY Se proveen "Trabajar con" de:
* Estudios Pendientes (tabla PENDING_TRAY)
* Estudios sin correspondencia (tabla UNMATCHED_TRAY)
* Modalidades
* Parámetros del sistema
Cada estudio tiene acceso a ventanas emergentes con detalles de: estudio, modalidad, paciente y si existe, del scheduled procedure step.
Si el estudio fue completado, se provee acceso a Oviyam. Envíos en paralelo desde tres fuentes diferentes
Envío de 300 imágenes en cada uno de los envíos en paralelo, con un total de 200 Mb cada envío.
Envío de 2000 imágenes con un total de 200 Mb.
CONSIDERACIONES:
Pruebas realizadas con 1Gb de memoria de máquina virtual, 512Mb de java (dcm4chee) máximo y 512Mb de Mirth máximo.
Pruebas realizadas con routers domésticos con acceso inalámbrico. Manejo de Estudios y de Series.
Idem caso anterior pero con series.
Verificaciones adicionales:
* A Mirth Connect llega un header por cada elemento de la serie, pero únicamente se procesa el primer elemento de la misma.
* Se genera únicamente UN registro en UNMATCHED_TRAY o se actualiza UN registro en PENDING_TRAY.
* Acceso de toda la serie vía Oviyam a través del Study UID Consumo de web service de entrada vía SOAP UI (generación de solicitud de estudio)
Generación de C-STORE del estudio vía:
* Vista Box
* Línea de comando (dcmsnd)
Verificación de generación de log.
Verificación de matcheo automático (control de PENDING_TRAY y UNMATCHED_TRAY)
Consumo de web service (vía SOAP UI) para alta de solicitud (tanto en PENDING_TRAY como en la WorkList)
Generación de los mensajes HL7 con los datos apropiados.
No se probó exitosamente el matcheo de un estudio generado desde la work list por falta de un EA (o simulador) que consumiera la work list del PACS.
Los estudios generados no contaban con la información necesaria para matchear: SPS ID Mirth no está procesando imágenes (solamente el HEADER DICOM) en esta solución, por lo que se evita la duplicación del flujo de estudios pesados en la red.
El flujo de la solución permite explotar la alta performance de DCM4CHEE en cuanto al manejo de grandes series.
El sistema permite el manejo de múltiples tipos de modalidades (no se restringe a las requeridas: mamógrafo, arco en C y tomógrafo).
Diseño de arquitectura independiente del HIS con el que se interactúe: integración de tablas intermedias y su gestión.
El diseño permite actualización de versiones de los componentes de forma independiente, gracias al uso de estándares y modularización.
Sistema complemetario para gestión de consistencia de datos.
Visualizador integrado a la solución, permite abstraerse de construcción de urls. Oviyam no es un visualizador DICOM robusto.
Complejidad de instalación y configuración del sistema.
Full transcript