ES2970825T3 - Imágenes médicas e intercambio eficiente de información de imágenes médicas - Google Patents

Imágenes médicas e intercambio eficiente de información de imágenes médicas Download PDF

Info

Publication number
ES2970825T3
ES2970825T3 ES16869357T ES16869357T ES2970825T3 ES 2970825 T3 ES2970825 T3 ES 2970825T3 ES 16869357 T ES16869357 T ES 16869357T ES 16869357 T ES16869357 T ES 16869357T ES 2970825 T3 ES2970825 T3 ES 2970825T3
Authority
ES
Spain
Prior art keywords
processor
phi
data
asp
client device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16869357T
Other languages
English (en)
Inventor
Kyle Dormer
Hussein Patni
Darryl Bidulock
John Axerio-Cilies
Torin Taerum
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Arterys Inc
Original Assignee
Arterys Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Arterys Inc filed Critical Arterys Inc
Application granted granted Critical
Publication of ES2970825T3 publication Critical patent/ES2970825T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/02—Detecting, measuring or recording for evaluating the cardiovascular system, e.g. pulse, heart rate, blood pressure or blood flow
    • A61B5/026—Measuring blood flow
    • A61B5/0263—Measuring blood flow using NMR
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A61B5/0004—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by the type of physiological signal transmitted
    • A61B5/0013—Medical image data
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0033—Features or image-related aspects of imaging apparatus, e.g. for MRI, optical tomography or impedance tomography apparatus; Arrangements of imaging apparatus in a room
    • A61B5/004—Features or image-related aspects of imaging apparatus, e.g. for MRI, optical tomography or impedance tomography apparatus; Arrangements of imaging apparatus in a room adapted for image acquisition of a particular organ or body part
    • A61B5/0044—Features or image-related aspects of imaging apparatus, e.g. for MRI, optical tomography or impedance tomography apparatus; Arrangements of imaging apparatus in a room adapted for image acquisition of a particular organ or body part for the heart
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/02—Detecting, measuring or recording for evaluating the cardiovascular system, e.g. pulse, heart rate, blood pressure or blood flow
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/02—Detecting, measuring or recording for evaluating the cardiovascular system, e.g. pulse, heart rate, blood pressure or blood flow
    • A61B5/021—Measuring pressure in heart or blood vessels
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/02—Detecting, measuring or recording for evaluating the cardiovascular system, e.g. pulse, heart rate, blood pressure or blood flow
    • A61B5/026—Measuring blood flow
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/05—Detecting, measuring or recording for diagnosis by means of electric currents or magnetic fields; Measuring using microwaves or radio waves
    • A61B5/055—Detecting, measuring or recording for diagnosis by means of electric currents or magnetic fields; Measuring using microwaves or radio waves involving electronic [EMR] or nuclear [NMR] magnetic resonance, e.g. magnetic resonance imaging
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/72—Signal processing specially adapted for physiological signals or for diagnostic purposes
    • A61B5/7203—Signal processing specially adapted for physiological signals or for diagnostic purposes for noise prevention, reduction or removal
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/72—Signal processing specially adapted for physiological signals or for diagnostic purposes
    • A61B5/7203—Signal processing specially adapted for physiological signals or for diagnostic purposes for noise prevention, reduction or removal
    • A61B5/7207—Signal processing specially adapted for physiological signals or for diagnostic purposes for noise prevention, reduction or removal of noise induced by motion artifacts
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/72—Signal processing specially adapted for physiological signals or for diagnostic purposes
    • A61B5/7235—Details of waveform analysis
    • A61B5/725—Details of waveform analysis using specific filters therefor, e.g. Kalman or adaptive filters
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/72—Signal processing specially adapted for physiological signals or for diagnostic purposes
    • A61B5/7235—Details of waveform analysis
    • A61B5/7253—Details of waveform analysis characterised by using transforms
    • A61B5/7257—Details of waveform analysis characterised by using transforms using Fourier transforms
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R33/00—Arrangements or instruments for measuring magnetic variables
    • G01R33/20—Arrangements or instruments for measuring magnetic variables involving magnetic resonance
    • G01R33/44—Arrangements or instruments for measuring magnetic variables involving magnetic resonance using nuclear magnetic resonance [NMR]
    • G01R33/48—NMR imaging systems
    • G01R33/54—Signal processing systems, e.g. using pulse sequences ; Generation or control of pulse sequences; Operator console
    • G01R33/56—Image enhancement or correction, e.g. subtraction or averaging techniques, e.g. improvement of signal-to-noise ratio and resolution
    • G01R33/5608—Data processing and visualization specially adapted for MR, e.g. for feature analysis and pattern recognition on the basis of measured MR data, segmentation of measured MR data, edge contour detection on the basis of measured MR data, for enhancing measured MR data in terms of signal-to-noise ratio by means of noise filtering or apodization, for enhancing measured MR data in terms of resolution by means for deblurring, windowing, zero filling, or generation of gray-scaled images, colour-coded images or images displaying vectors instead of pixels
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/0002—Inspection of images, e.g. flaw detection
    • G06T7/0012—Biomedical image inspection
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/20—Analysis of motion
    • G06T7/269—Analysis of motion using gradient-based methods
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H30/00—ICT specially adapted for the handling or processing of medical images
    • G16H30/20—ICT specially adapted for the handling or processing of medical images for handling medical images, e.g. DICOM, HL7 or PACS
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H30/00—ICT specially adapted for the handling or processing of medical images
    • G16H30/40—ICT specially adapted for the handling or processing of medical images for processing medical images, e.g. editing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B2576/00—Medical imaging apparatus involving image processing or analysis
    • A61B2576/02—Medical imaging apparatus involving image processing or analysis specially adapted for a particular organ or body part
    • A61B2576/023—Medical imaging apparatus involving image processing or analysis specially adapted for a particular organ or body part for the heart
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A61B5/0015—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by features of the telemetry system
    • A61B5/0022—Monitoring a patient using a global network, e.g. telephone networks, internet
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/02—Detecting, measuring or recording for evaluating the cardiovascular system, e.g. pulse, heart rate, blood pressure or blood flow
    • A61B5/02007—Evaluating blood vessel condition, e.g. elasticity, compliance
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00—Measuring for diagnostic purposes; Identification of persons
    • A61B5/02—Detecting, measuring or recording for evaluating the cardiovascular system, e.g. pulse, heart rate, blood pressure or blood flow
    • A61B5/02007—Evaluating blood vessel condition, e.g. elasticity, compliance
    • A61B5/02014—Determining aneurysm
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R33/00—Arrangements or instruments for measuring magnetic variables
    • G01R33/20—Arrangements or instruments for measuring magnetic variables involving magnetic resonance
    • G01R33/44—Arrangements or instruments for measuring magnetic variables involving magnetic resonance using nuclear magnetic resonance [NMR]
    • G01R33/48—NMR imaging systems
    • G01R33/54—Signal processing systems, e.g. using pulse sequences ; Generation or control of pulse sequences; Operator console
    • G01R33/56—Image enhancement or correction, e.g. subtraction or averaging techniques, e.g. improvement of signal-to-noise ratio and resolution
    • G01R33/563—Image enhancement or correction, e.g. subtraction or averaging techniques, e.g. improvement of signal-to-noise ratio and resolution of moving material, e.g. flow contrast angiography
    • G01R33/56308—Characterization of motion or flow; Dynamic imaging
    • G01R33/56316—Characterization of motion or flow; Dynamic imaging involving phase contrast techniques
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/10—Image acquisition modality
    • G06T2207/10072—Tomographic images
    • G06T2207/10076—4D tomography; Time-sequential 3D tomography
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/10—Image acquisition modality
    • G06T2207/10072—Tomographic images
    • G06T2207/10088—Magnetic resonance imaging [MRI]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/30—Subject of image; Context of image processing
    • G06T2207/30004—Biomedical image processing
    • G06T2207/30101—Blood vessel; Artery; Vein; Vascular
    • G06T2207/30104—Vascular flow; Blood flow; Perfusion

Landscapes

  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • Veterinary Medicine (AREA)
  • Pathology (AREA)
  • Biomedical Technology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Biophysics (AREA)
  • Molecular Biology (AREA)
  • Surgery (AREA)
  • Animal Behavior & Ethology (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • Physiology (AREA)
  • Signal Processing (AREA)
  • Radiology & Medical Imaging (AREA)
  • Cardiology (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Artificial Intelligence (AREA)
  • Psychiatry (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Hematology (AREA)
  • High Energy & Nuclear Physics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Vascular Medicine (AREA)
  • Mathematical Physics (AREA)
  • Condensed Matter Physics & Semiconductors (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Magnetic Resonance Imaging Apparatus (AREA)

Abstract

Un sistema de procesamiento y análisis de imágenes de MRI puede identificar instancias de estructura en los datos de flujo de MRI, por ejemplo, coherencia, derivar contornos y/o marcadores clínicos basados en las estructuras identificadas. El sistema puede estar ubicado de forma remota desde uno o más sistemas de adquisición de MRI y realizar: detección y/o corrección de errores en conjuntos de datos de MRI (por ejemplo, corrección de errores de fase, alias de fase, desenvolvimiento de señales y/o en otros artefactos); segmentación; visualización del flujo (p. ej., velocidad, flujo arterial versus venoso, derivaciones) superpuesto a la estructura anatómica, cuantificación; verificación; y/o generación de protocolos de flujo 4-D específicos del paciente. Se proporciona un servicio de información de salud protegida (PHI) que anonimiza los datos de estudios médicos y permite a los proveedores médicos controlar los datos de PHI y carga los datos anónimos en un sistema de proveedor de servicios de análisis (ASP). Se proporciona una aplicación web que combina los datos de PHI con los datos no identificados mientras mantiene el control de los datos de PHI con el proveedor médico. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Imágenes médicas e intercambio eficiente de información de imágenes médicas
Antecedentes
Campo técnico
La presente divulgación se refiere generalmente a imágenes por resonancia magnética (IRM), por ejemplo, IRM de flujo de cuatro dimensiones (4-D), y al intercambio de imágenes médicas y otra información a través de redes o canales de comunicaciones.
Descripción de la técnica relacionada
IRM se emplea con mayor frecuencia en imágenes médicas, aunque puede usarse en otros campos. Las máquinas de IRM incluyen un imán principal que normalmente es una serie anular de bobinas que tienen un orificio central o longitudinal. El imán principal es capaz de producir un campo magnético fuerte y estable (por ejemplo, de 0,5 Tesla a 3,0 Tesla). El orificio está dimensionado para recibir al menos una parte de un objeto del que se va a obtener una imagen, por ejemplo, un cuerpo humano. Cuando se utiliza en aplicaciones de imágenes médicas, la máquina de IRM puede incluir una mesa para el paciente que permite deslizar o hacer rodar fácilmente a un paciente en tendido prono dentro y fuera del orificio.
Las máquinas IRM también incluyen imanes de gradiente. Los imanes de gradiente producen un campo magnético variable que es relativamente más pequeño que el producido por el imán principal (por ejemplo, de 180 Gauss a 270 Gauss), lo que permite obtener imágenes de porciones seleccionadas de un objeto (por ejemplo, un paciente). Las máquinas IRM también incluyen bobinas de radiofrecuencia (RF) que se operan para aplicar energía de radiofrecuencia a partes seleccionadas del objeto (por ejemplo, el paciente) del que se van a tomar imágenes. Se pueden usar diferentes bobinas de RF para obtener imágenes de diferentes estructuras (por ejemplo, estructuras anatómicas). Por ejemplo, un conjunto de bobinas de RF puede ser apropiado para obtener imágenes del cuello de un paciente, mientras que otro conjunto de bobinas de RF puede ser apropiado para obtener imágenes del tórax o del corazón del paciente. Las máquinas de IRM suelen incluir imanes adicionales, por ejemplo, imanes resistivos y/o imanes permanentes.
La máquina de IRM normalmente incluye, o está acoplada comunicativamente a, un sistema informático utilizado para controlar los imanes y/o bobinas y/o para realizar procesamiento de imágenes para producir imágenes de las partes del objeto que se están analizando.
Convencionalmente, las máquinas de IRM producen conjuntos de datos de magnitud que representan estructuras físicas, por ejemplo, estructuras anatómicas. Los conjuntos de datos a menudo se ajustan al estándar de Comunicaciones e Imágenes Digitales en Medicina (Digital Imaging and Communication in Medicine, DICOM). Los archivos DICOM suelen incluir datos de píxeles y metadatos en un formato prescrito.
El documento US 9118641 describe un procedimiento implementado por ordenador. El procedimiento incluye producir información que caracterice a un grupo de individuos a partir de un conjunto de datos privados que representan características de los individuos. La identidad de los individuos no se puede obtener a partir de la información producida. El procedimiento también incluye proporcionar la información producida para reportar las características del grupo.
Breve resumen
Según aspectos de la invención, se proporciona un procedimiento para operar una plataforma de análisis médicos y una plataforma de análisis médicos de acuerdo con las reivindicaciones independientes. En las reivindicaciones dependientes se proporcionan características ventajosas. Otros aspectos se describen a continuación.
Un procedimiento para operar una plataforma de análisis médicos, incluyendo la plataforma de análisis médicos un sistema proveedor de servicios de análisis (analytics service provider, ASP) y un sistema de información de salud protegida (protected health information, PHI), el procedimiento puede resumirse como que incluye: almacenar, mediante al menos un procesador del sistema ASP, datos de estudio médico de-identificados (no identificados) en al menos un medio de almacenamiento no transitorio legible por procesador del sistema ASP; almacenar, mediante al menos un procesador del sistema PHI, datos PHI asociados con los datos de estudio médico de-identificados en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; enviar, mediante el al menos un procesador del sistema PHI, datos PHI para un estudio médico solicitado a un dispositivo cliente basado en procesador a través de al menos una red de comunicaciones; y enviar, mediante el al menos un procesador del sistema ASP, datos de estudio médico de-identificados para el estudio médico solicitado al dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones.
El sistema PHI puede estar acoplado comunicativamente a una red privada, el procedimiento puede incluir, además: verificar, mediante el al menos un procesador del sistema ASP o el al menos un procesador del sistema PHI, que el dispositivo cliente basado en procesador tiene acceso a la red privada. El procedimiento puede incluir además: recibir, por parte de el al menos un procesador del sistema ASP, una solicitud de un token de acceso PHI desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones; enviar, mediante el al menos un procesador del sistema ASP, un token de acceso PHI encriptado al dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones; recibir, mediante el al menos un procesador del sistema PHI, una solicitud de datos PHI para el estudio médico desde el dispositivo cliente basado en procesador, incluyendo la solicitud el token de acceso p Hi encriptado; enviar, mediante el al menos un procesador del sistema PHI, el token de acceso PHI encriptado al sistema ASP a través de la al menos una red de comunicaciones; validar, mediante el al menos un procesador del sistema ASP, el token de acceso PHI encriptado recibido; y notificar, mediante el al menos un procesador del sistema ASP, al sistema PHI que el token de acceso PHI es válido, donde el enviar los datos PHI solicitados al dispositivo cliente basado en procesador puede responder a que el al menos un procesador del sistema PHI reciba la notificación de validación del sistema ASP. El procedimiento puede incluir además: recibir, mediante al menos un procesador del sistema PHI, datos de estudio médico que incluyen datos PHI; eliminar, mediante el al menos un procesador del sistema PHI, los datos PHI de los datos de estudio médico para generar datos de estudio médico de-identificados; almacenar, mediante el al menos un procesador del sistema PHI, los datos PHI en el al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y enviar, mediante el al menos un procesador del sistema PHI, los datos de estudio médico de-identificados al sistema ASP a través de la al menos una red de comunicaciones. Recibir datos de estudio médico que incluyen datos PHI puede incluir recibir datos de imágenes médicas de un escáner. Enviar los datos de estudio médico de-identificados al sistema ASP puede incluir enviar los datos de estudio médico de-identificados al sistema ASP utilizando una interfaz de programación de aplicaciones de transferencia de estado representacional (representional state transfer, REST). Eliminar los datos PHI de los datos de estudio médico puede incluir: eliminar, mediante el al menos un procesador del sistema PHI, campos que está permitido que puedan eliminarse; y reemplazar, mediante el al menos un procesador del sistema PHI, datos en campos que no está permitido que puedan eliminarse con datos de reemplazo ofuscados. El procedimiento puede incluir además: asociar, mediante el al menos un procesador del sistema p H i, un identificador único con los datos de estudio médico para un estudio médico; almacenar, mediante el al menos un procesador del sistema PHI, el identificador único en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y enviar, mediante el al menos un procesador del sistema PHI, el identificador único con los datos médicos de identificados para el estudio médico al sistema ASP a través de la al menos una red de comunicaciones. El procedimiento puede incluir además: recibir, mediante al menos un procesador del dispositivo cliente basado en procesador, los datos PHI del sistema PHI a través de la al menos una red de comunicaciones; recibir, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos de estudio médico de-identificados del sistema a Sp a través de la al menos una red de comunicaciones; fusionar, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos PHI y los datos de estudio médico de-identificados para generar datos de estudio médico re-identificados; y presentar, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos de estudio médico re-identificados a un usuario del dispositivo cliente basado en procesador. El procedimiento puede incluir, además: generar, mediante el al menos un procesador del sistema ASP, datos de análisis relacionados con los datos de estudio médico de-identificados; y enviar, mediante al el menos un procesador del sistema ASP, los datos de análisis generados al sistema PHI a través de la al menos una red de comunicaciones. El procedimiento puede incluir, además: recibir, mediante el al menos un procesador del sistema ASP, una solicitud para generar datos de análisis desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones, en donde generar los datos de análisis puede responder a la recepción de la solicitud para generar datos de análisis desde el dispositivo cliente basado en procesador. Generar datos de análisis puede incluir generar al menos uno de un informe o un objeto de captura secundario, y enviar los datos de análisis generados al sistema de PHI puede incluir enviar el al menos uno del informe o el objeto de captura secundario al sistema de PHI a través la al menos una red de comunicaciones para almacenamiento en el al menos un medio de almacenamiento no transitorio legible por procesador acoplado comunicativamente con el sistema PHI. El procedimiento puede incluir, además: proporcionar, mediante el al menos un procesador del sistema PHI, una lista de estudios disponibles al dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones; y recibir, mediante el al menos un procesador del sistema PHI, una selección de al menos uno de los estudios disponibles en la lista desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones. El procedimiento puede incluir además: enviar periódicamente, mediante el al menos un procesador del sistema PHI, una chequeo de actualizaciones al sistema ASP a través de la al menos una red de comunicaciones; determinar, mediante al menos un procesador del sistema ASP, si se necesita alguna actualización del sistema PHI; y en respuesta a determinar que se necesita al menos una actualización del sistema PHI, enviar, mediante el al menos un procesador del ASP, datos de actualización al sistema PHI a través de la al menos una red de comunicaciones.
Un procedimiento para operar un sistema de proveedor de servicios de análisis (ASP) de una plataforma de análisis médicos, la plataforma de análisis médicos que incluye el sistema ASP y un sistema de información de salud protegida (PHI), el sistema de PHI que almacena datos PHI asociados con datos de estudio médico no identificados. en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI, el procedimiento puede resumirse de la siguiente manera: almacenar, mediante al menos un procesador del sistema ASP, los datos de estudio médico no identificados en al menos un medio de almacenamiento no transitorio legible por procesador medio de almacenamiento del sistema ASP; y enviar, por al menos un procesador del sistema ASP, datos de estudio médico no identificados para un estudio médico solicitado a un dispositivo cliente basado en procesador a través de al menos una red de comunicaciones para ser fusionados por el dispositivo cliente basado en procesador con PHI datos recibidos por el dispositivo cliente basado en procesador desde el sistema PHI a través de al menos una red de comunicaciones.
El procedimiento puede incluir además: recibir, mediante el al menos un procesador del sistema ASP, una solicitud de un token de acceso PHI desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones; enviar, mediante el al menos un procesador del sistema ASP, un token de acceso PHI encriptado al dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones; recibir, mediante el al menos un procesador del sistema ASP, el token de acceso PHI encriptado desde el sistema PHI a través de la al menos una red de comunicaciones; validar, mediante el al menos un procesador del sistema ASP, el token de acceso PHI encriptado recibido; y notificar, mediante el al menos un procesador del sistema ASP, al sistema PHI que el token de acceso PHI es válido. El procedimiento puede incluir, además: recibir, mediante el al menos un procesador del sistema ASP, los datos de estudio médico de-identificados del sistema PHI a través de la al menos una red de comunicaciones. El procedimiento puede incluir, además: generar, mediante el al menos un procesador del sistema ASP, datos de análisis relacionados con los datos de estudio médico de-identificados; y enviar, mediante el al menos un procesador del sistema ASP, los datos de análisis generados al sistema PHI a través de la al menos una red de comunicaciones. El procedimiento puede incluir, además: recibir, mediante el al menos un procesador del sistema ASP, una solicitud para generar datos de análisis desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones, en donde generar los datos de análisis puede responder a la recepción de la solicitud para generar datos de análisis desde el dispositivo cliente basado en procesador. Generar datos de análisis puede incluir generar al menos uno de un informe o un objeto de captura secundario, y enviar los datos de análisis generados al sistema de PHI puede incluir enviar al menos el uno del informe o el objeto de captura secundario al sistema de PHI a través de la al menos una red de comunicaciones para almacenamiento en el al menos un medio de almacenamiento no transitorio legible por procesador acoplado comunicativamente con el sistema PHI. El procedimiento puede incluir además: recibir periódicamente, mediante el al menos un procesador del sistema ASP, una chequeo de actualizaciones del sistema PHI a través de la al menos una red de comunicaciones; determinar, mediante el al menos un procesador del sistema ASP, si se necesita alguna actualización del sistema PHI; y en respuesta a determinar que se necesita al menos una actualización del sistema PHI, enviar, mediante el al menos un procesador del ASP, datos de actualización al sistema PHI a través de la al menos una red de comunicaciones. El procedimiento puede incluir además: recibir, mediante al menos un procesador del dispositivo cliente basado en procesador, los datos PHI del sistema PHI a través de la al menos una red de comunicaciones; recibir, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos de estudio médico de-identificados del sistema a Sp a través de la al menos una red de comunicaciones; fusionar, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos PHI y los datos de estudio médico de-identificados para generar datos de estudio médico re-identificados; y presentar, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos de estudio médico re-identificados a un usuario del dispositivo cliente basado en procesador.
Un sistema de proveedor de servicios de análisis (ASP) de una plataforma de análisis médicos, incluyendo la plataforma de análisis médicos el sistema ASP y un sistema de información de salud protegida (PHI), el sistema de PHI almacena datos PHI asociados con datos de estudio médico de-identificados (no identificados) en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI, el sistema ASP puede resumirse como que incluye: al menos un medio de almacenamiento no transitorio legible por procesador que almacena al menos uno de instrucciones o datos ejecutables por el procesador; y al menos un procesador acoplado de manera comunicable al al menos un medio de almacenamiento no transitorio legible por procesador, en funcionamiento el al menos un procesador: almacena los datos de estudio médico de-identificados en al menos un medio de almacenamiento no transitorio legible por procesador; y envía datos de estudio médico de-identificados para un estudio médico solicitado a un dispositivo cliente basado en procesador a través de al menos una red de comunicaciones para que el dispositivo cliente basado en procesador los fusione con los datos PHI recibidos por el dispositivo cliente basado en procesador desde el sistema PHI a través de la al menos una red de comunicaciones.
Al menos un procesador puede: recibir una solicitud de un token de acceso PHI desde el dispositivo cliente basado en procesador a través de al menos una red de comunicaciones; enviar un token de acceso PHI encriptado al dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones; recibir el token de acceso PHI encriptado desde el sistema de PHI a través de la al menos una red de comunicaciones; validar el token de acceso PHI encriptado recibido; y notificar al sistema PHI que el token de acceso PHI es válido a través de la al menos una red de comunicaciones. El al menos un procesador puede: recibir los datos de estudio médico de-identificados del sistema PHI a través de la al menos una red de comunicaciones. El al menos un procesador puede: generar datos de análisis relacionados con los datos de estudio médico de-identificados; y enviar los datos de análisis generados al sistema PHI a través de la al menos una red de comunicaciones. El al menos un procesador puede: recibir una solicitud para generar datos de análisis desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones, donde el al menos un procesador puede generar los datos de análisis en respuesta a la recepción de la solicitud para generar datos de análisis desde el dispositivo cliente basado en procesador. Los datos de análisis pueden incluir al menos uno de un informe o un objeto de captura secundario, y el al menos un procesador puede: enviar al menos uno del el informe o el objeto de captura secundario al sistema PHI a través de la al menos una red de comunicaciones para almacenamiento en al menos un medio de almacenamiento no transitorio legible por procesador acoplado comunicativamente con el sistema PHI. El al menos un procesador puede: recibir periódicamente un chequeo de actualizaciones del sistema PHI a través de la al menos una red de comunicaciones; determinar si se necesita alguna actualización del sistema de PHI; y en respuesta a una determinación de que se necesita al menos una actualización del sistema PHI, enviar datos de actualización al sistema PHI a través de la al menos una red de comunicaciones.
Un procedimiento para operar un sistema de información de salud protegida (PHI) de una plataforma de análisis médicos, incluyendo la plataforma de análisis médicos el sistema PHI y un sistema de proveedor de servicios de análisis (ASP), almacenando el sistema ASP datos de estudio médico de-identificados en al menos un medio de almacenamiento no transitorio legible por procesador del sistema ASP, el procedimiento puede resumirse de la siguiente manera: almacenar, mediante al menos un procesador del sistema PHI, datos PHI asociados con los datos de estudio médico de-identificados en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y enviar, por el al menos un procesador del sistema PHI, datos PHI para un estudio médico solicitado a un dispositivo cliente basado en procesador a través de al menos una red de comunicaciones para ser fusionados por el dispositivo cliente basado en procesador con datos de estudio médico de-identificados recibidos por el dispositivo cliente basado en procesador desde el sistema ASP a través de la al menos una red de comunicaciones.
El procedimiento puede incluir además: recibir, mediante el al menos un procesador del sistema PHI, una solicitud de datos PHI para el estudio médico desde un dispositivo cliente basado en procesador, incluyendo la solicitud un token de acceso PHI encriptado; enviar, mediante el al menos un procesador del sistema PHI, el token de acceso PHI encriptado al sistema ASP a través de la al menos una red de comunicaciones para su validación; y recibir, mediante el al menos un procesador del sistema PHI, una notificación del sistema ASP de que el token de acceso PHI es válido. El procedimiento puede incluir además: recibir, mediante el al menos un procesador del sistema PHI, datos de estudio médico que incluyen datos PHI; eliminar, mediante el al menos un procesador del sistema PHI, los datos PHI de los datos de estudio médico para generar datos de estudio médico de-identificados; almacenar, mediante el al menos un procesador del sistema PHI, los datos PHI en el al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y enviar, mediante el al menos un procesador del sistema PHI, los datos de estudio médico de-identificados al sistema ASP a través de la al menos una red de comunicaciones. Recibir datos de estudio médico que incluyen datos PHI puede incluir recibir datos de imágenes médicas de un escáner. Enviar los datos de estudio médico de-identificados al sistema ASP puede incluir enviar los datos de estudio médico de-identificados al sistema ASP utilizando una interfaz de programación de aplicaciones de transferencia de estado representacional (REST). Eliminar los datos PHI de los datos de estudio médico puede incluir: eliminar, mediante el al menos un procesador del sistema PHI, campos que está permitido que puedan eliminarse; y reemplazar, mediante el al menos un procesador del sistema PHI, datos en campos que no está permitido que se puedan eliminar con datos de reemplazo ofuscados. El procedimiento puede incluir además: asociar, mediante el al menos un procesador del sistema PHI, un identificador único con los datos de estudio médico para un estudio médico; almacenar, mediante el al menos un procesador del sistema PHI, el identificador único en el al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y enviar, mediante el al menos un procesador del sistema PHI, el identificador único con los datos médicos de-identificados para el estudio médico al sistema ASP a través de la al menos una red de comunicaciones. El procedimiento puede incluir, además: recibir, mediante el al menos un procesador del sistema PHI, datos de análisis relacionados con los datos de estudio médico de-identificados del sistema ASP a través de la al menos una red de comunicaciones; y almacenar, mediante el al menos un procesador del sistema PHI, los datos de análisis recibidos en al menos un medio de almacenamiento no transitorio legible por el procesador acoplado comunicativamente con el sistema PHI. El procedimiento puede incluir, además: proporcionar, mediante el al menos un procesador del sistema PHI, una lista de estudios disponibles al dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones; y recibir, mediante al menos un procesador del sistema PHI, una selección de al menos uno de los estudios disponibles en la lista desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones. El procedimiento puede incluir, además: enviar periódicamente, mediante el al menos un procesador del sistema PHI, un chequeo de actualizaciones al sistema ASP a través de la al menos una red de comunicaciones; y recibir, mediante el al menos un procesador del sistema PHI, datos actualizados del sistema ASP a través de la al menos una red de comunicaciones. El procedimiento puede incluir además: recibir, mediante al menos un procesador del dispositivo cliente basado en procesador, los datos PHI del sistema de PHI a través de la al menos una red de comunicaciones; recibir, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos de estudio médico de-identificados del sistema<a>S<p>a través de la al menos una red de comunicaciones; fusionar, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos PHI y los datos de estudio médico de-identificados para generar datos de estudio médico re identificados; y presentar, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos de estudio médico re-identificados a un usuario del dispositivo cliente basado en procesador.
Un sistema de información de salud protegida (PHI) de una plataforma de análisis médicos, incluyendo la plataforma de análisis médicos el sistema de PHI y un sistema de proveedor de servicios de análisis (ASP), almacenando el sistema ASP datos de estudio médico de-identificados en al menos medio de almacenamiento no transitorio legible por procesador del sistema ASP, el sistema PHI puede resumirse como que incluye: al menos un medio de almacenamiento no transitorio legible por procesador que almacena al menos uno de datos o instrucciones ejecutables por procesador; y al menos un procesador acoplado de manera comunicable al al menos un medio de almacenamiento no transitorio legible por procesador, en funcionamiento el al menos un procesador: almacena datos PHI asociados con los datos de estudio médico de-identificados en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y envía datos PHI para un estudio médico solicitado a un dispositivo cliente basado en procesador a través de al menos una red de comunicaciones para que el dispositivo cliente basado en procesador los fusione con datos de estudio médicos de-identificados recibidos por el dispositivo cliente basado en procesador desde el sistema ASP a través de la al menos una red de comunicaciones.
El al menos un procesador puede: recibir una solicitud de datos PHI para el estudio médico desde un dispositivo cliente basado en procesador, incluyendo la solicitud un token de acceso PHI encriptado; enviar el token de acceso PHI encriptado al sistema ASP a través de la al menos una red de comunicaciones para su validación; y recibir una notificación del sistema ASP de que el token de acceso PHI es válido. El al menos un procesador puede: recibir datos de estudio médico que incluyan datos PHI; eliminar los datos PHI de los datos de estudio médico para generar datos de estudio médico de-identificados; almacenar los datos PHI en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y enviar los datos de estudio médico de-identificados al sistema ASP a través de la al menos una red de comunicaciones. Los datos de estudio médico pueden incluir datos de imágenes médicas de un escáner. El al menos un procesador puede enviar datos de estudio médico de-identificados al sistema ASP utilizando una interfaz de programación de aplicaciones de transferencia de estado representacional (REST). El al menos un procesador puede: eliminar campos de los datos de estudio médico está permitido que sean eliminados; y reemplazar datos en campos de datos de estudio médico que no está permitido que sean eliminados con datos de reemplazo ofuscados. El al menos un procesador puede: asociar un identificador único con los datos de estudio médico para un estudio médico; almacenar el identificador único en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y enviar el identificador único con los datos médicos de-identificados para el estudio médico al sistema ASP a través de la al menos una red de comunicaciones. El al menos un procesador puede: recibir datos de análisis relacionados con los datos de estudio médico de-identificados del sistema ASP a través de la al menos una red de comunicaciones; y almacenar los datos de análisis recibidos en al menos un medio de almacenamiento no transitorio legible por procesador acoplado comunicativamente con el sistema PHI. El al menos un procesador puede: proporcionar una lista de estudios disponibles al dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones; y recibir una selección de al menos uno de los estudios disponibles en la lista desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones. El al menos un procesador puede: enviar periódicamente un chequeo de actualizaciones al sistema ASP a través de la al menos una red de comunicaciones; y recibir datos de actualización del sistema ASP a través de la al menos una red de comunicaciones.
Brece descripción de las múltiples vistas de los dibujos
En los dibujos, números de referencia idénticos identifican elementos o actos similares. Los tamaños y posiciones relativas de los elementos en los dibujos no están necesariamente dibujados a escala. Por ejemplo, las formas de diversos elementos y ángulos no están necesariamente dibujadas a escala, y algunos de estos elementos pueden ampliarse y colocarse arbitrariamente para mejorar la legibilidad del dibujo. Además, las formas particulares de los elementos dibujados no necesariamente pretenden transmitir ninguna información con respecto a la forma real de los elementos particulares, y pueden haber sido seleccionadas únicamente para facilitar el reconocimiento en los dibujos.
La Figura 1 es una vista esquemática de un entorno en red que incluye al menos un sistema de adquisición de IRM y al menos un sistema de procesamiento de imágenes, el sistema de adquisición de IRM ubicado en un entorno clínico y el sistema de procesamiento de imágenes ubicado remotamente desde el sistema de adquisición de IRM y acoplado comunicativamente con el mismo mediante una o más redes, según una realización ilustrada.
La Figura 2 es un diagrama de bloques funcional de un sistema de adquisición de IRM y un sistema de análisis y procesamiento de imágenes de IRM que proporciona servicios de análisis y procesamiento de imágenes por IRM, según una realización ilustrada.
Las Figuras 3A-3B son un diagrama de flujo de un proceso de empuje de ejemplo ejecutable por al menos un procesador, según una realización ilustrada.
Las Figuras 4A-4B son un diagrama de flujo de un proceso de ejemplo de monitorización de artefactos y arcos ejecutable por al menos un procesador, según una realización ilustrada.
La Figura 5 es una ilustración esquemática de una tubería (pipeline) de servicio PHI, según una realización ilustrada. La Figura 6 es una ilustración esquemática de un servicio PHI de la Figura 5, que muestra datos PHI mantenidos dentro de la red de un proveedor médico fusionados con datos de píxel de un sistema de proveedor de servicios de análisis (ASP) a través de la aplicación web del ASP, según una realización ilustrada.
La Figura 7 es una ilustración esquemática del servicio PHI de la Figura 5, que muestra archivos DICOM despojados de datos PHI, según una realización ilustrada.
La Figura 8 es una ilustración esquemática del servicio PHI, que muestra a un usuario operando una aplicación web para solicitar al sistema ASP que almacene un informe en un servidor PACS registrado de la organización del usuario, según una realización ilustrada.
La Figura 9 es una ilustración esquemática del servicio PHI, que muestra cómo el servidor PHI del servicio PHI maneja los archivos DICOM, según una implementación ilustrada.
La Figura 10 es una ilustración esquemática del servicio de PHI, que muestra cómo se organizan las dependencias del servicio de PHI, según una realización ilustrada.
Las Figuras 11A-11B son un diagrama de secuencia del sistema que ilustra un proceso para una secuencia de lanzamiento del servicio PHI, según una realización ilustrada.
La Figura 12 es un diagrama de flujo que ilustra un proceso para implementar un servicio de de-identificación del servicio PHI, según una realización ilustrada.
Las Figuras 13A-13B son un diagrama de flujo que ilustra un proceso para un servicio de empuje o subida del servicio PHI, según una realización ilustrada.
Las Figuras 14A-14B son un diagrama de secuencia de sistema que ilustra un proceso para la re-identificación de navegador web, según una realización ilustrada.
Las Figuras 15A-15B son un diagrama de secuencia del sistema que ilustra un proceso para implementar un servicio de re-identificación de artefactos, según una realización ilustrada.
Descripción detallada
En la siguiente descripción, se establecen ciertos detalles específicos para proporcionar una comprensión profunda de varias realizaciones divulgadas. Sin embargo, un experto en la técnica relevante reconocerá que se pueden practicar realizaciones sin uno o más de estos detalles específicos, o con otros procedimientos, componentes, materiales, etc.
En otros casos, las estructuras bien conocidas asociadas con máquinas de resonancia magnética, sistemas informáticos, servidores y/o redes de comunicaciones no se han mostrado ni descrito en detalle para evitar oscurecer innecesariamente las descripciones de las realizaciones.
A menos que el contexto requiera lo contrario, a lo largo de la especificación y las reivindicaciones que siguen, la palabra "comprende" y sus variaciones, tales como "comprendiendo" y "que comprende" son sinónimos de "incluido" y son inclusivos o abiertos (es decir, no excluye elementos adicionales no recitados o actos de procedimiento). La referencia a lo largo de esta especificación a "una realización" significa que una característica, estructura o característica particular descrita en relación con la realización está incluida en al menos una realización. Por lo tanto, las apariciones de las frases "en una realización" en varios lugares a lo largo de esta especificación no necesariamente se refieren todas a la misma realización.
Tal como se utiliza en esta especificación y en las reivindicaciones adjuntas, las formas singulares "un", "una" y "el", "la" incluyen referentes en plural a menos que el contenido indique claramente lo contrario. También cabe señalar que el término "o" se emplea generalmente en el sentido que incluye "y/o" a menos que el contenido indique claramente lo contrario.
Los títulos y el resumen de la divulgación proporcionados en este documento son solo por conveniencia y no interpretan el alcance o significado de las realizaciones.
Muchas de las implementaciones descritas en el presente documento aprovechan un conjunto de datos de resonancia magnética de flujo 4-D, que esencialmente captura información de fase y magnitud de la resonancia magnética para un volumen tridimensional (3-D) durante un período de tiempo. Este enfoque puede permitir la captura o adquisición de conjuntos de datos de resonancia magnética sin necesidad de contener la respiración o sincronizar con los ciclos cardíacos o pulmonares de un paciente. En cambio, se capturan o adquieren conjuntos de datos de resonancia magnética y se emplean procesamiento y análisis de imágenes para derivar la información deseada, por ejemplo, volviendo a agrupar la información adquirida en función de los ciclos cardíacos y pulmonares. Básicamente, esto lleva las operaciones de adquisición que normalmente requieren mucho tiempo a la etapa de procesamiento y análisis de imágenes. A modo de analogía simplificada, en algunos aspectos esto puede considerarse como capturar una película de la estructura anatómica (por ejemplo, tórax, corazón) sin preocuparse por los ciclos pulmonares o cardíacos del paciente, y luego procesar la película capturada para tener en cuenta el movimiento relativo introducido por los ciclos pulmonar y cardíaco. La información capturada incluye tanto información de magnitud, que es indicativa de la estructura anatómica, como información de fase, que es indicativa de la velocidad. La información de fase permite distinguir entre tejido estático y no estático, permitiendo por ejemplo distinguir el tejido no estático (por ejemplo, sangre, aire) del tejido estático (por ejemplo, grasa, hueso). La información de fase también permite distinguir cierto tejido no estático (por ejemplo, aire) de otro tejido no estático (por ejemplo, sangre). Esto puede permitir ventajosamente la segmentación automatizada o incluso autónoma entre tejidos y/o distinguir el flujo sanguíneo auricular del flujo sanguíneo venoso. Esto puede permitir ventajosamente la generación automatizada o incluso autónoma de información de visualización de flujo, que puede superponerse a información anatómica. Esto también puede permitir ventajosamente la cuantificación del flujo automatizada o incluso autónoma, identificando anomalías y/o verificando los resultados.
El flujo de trabajo generalmente se puede dividir en tres partes, de forma secuencial: 1) adquisición de imágenes, 2) reconstrucción de imágenes y 3) procesamiento o post-procesamiento y análisis de imágenes. Alternativamente, el flujo de trabajo se puede dividir en 1) operativo, 2) pre-procesamiento y 3) visualización y cuantificación.
La adquisición de imágenes puede incluir determinar, definir, generar o configurar de otro modo una o más secuencias de impulsos, que se utilizan para hacer funcionar la máquina de IRM (por ejemplo, controlar imanes) y adquirir IRM sin procesar. El uso de una secuencia de pulsos de flujo 4-D permite capturar no solo la estructura anatómica, que está representada por la magnitud, sino también la velocidad, que está representada por la fase. Al menos uno de los procedimientos o técnicas descritos en el presente documento, generación de secuencias de pulsos 4-D específicas del paciente, se produce durante o como parte de la parte de adquisición de imágenes. La reconstrucción de imágenes puede, por ejemplo, emplear transformaciones rápidas de Fourier y dar como resultado conjuntos de datos de resonancia magnética, a menudo en una forma compatible con el estándar DICOM. La reconstrucción de imágenes tradicionalmente ha sido computacionalmente intensiva y a menudo depende de supercomputadoras. El requisito de esto es una carga significativa para muchas instalaciones clínicas. Muchos de los procedimientos y técnicas descritos en el presente documento se producen durante o como parte del procesador de imágenes o del post-procesamiento y análisis. Estos pueden incluir detección de errores y/o corrección de errores, segmentación, visualización, incluida la fusión de información relacionada con el flujo e imágenes de estructuras anatómicas, cuantificación, identificación de anomalías, incluidas derivaciones, verificación, incluida la identificación de datos espurios. Alternativamente, la detección de errores y/o la corrección de errores pueden ocurrir durante la parte de pre-procesamiento.
La Figura 1 muestra un entorno en red 100 según una realización ilustrada, en el que uno o más sistemas de adquisición de IRM (se muestra uno) 102 están acoplados comunicativamente a al menos un sistema de análisis y procesamiento de imágenes 104 a través de una o más redes 106a, 106b (se muestran dos, colectivamente 106).
El sistema de adquisición de IRM 102 normalmente está ubicado en una instalación clínica, por ejemplo, un hospital o un centro de imágenes médicas dedicado. Diversas técnicas y estructuras, como se explica en el presente documento, pueden permitir ventajosamente que el sistema de procesamiento y análisis de imágenes104 esté ubicado de forma remota respecto al sistema de adquisición de IRM 102.
El sistema de procesamiento y análisis de imágenes 104 puede, por ejemplo, estar ubicado en otro edificio, ciudad, estado, provincia o incluso país.
El sistema de adquisición de IRM 102 puede incluir, por ejemplo, una máquina de IRM 108, un sistema informático 110 y un sistema de operador de IRM 112. La máquina de IRM 108 puede incluir un imán principal 114, que normalmente es una serie anular de bobinas que tienen un orificio central o longitudinal 116. El imán principal 108 es capaz de producir un campo magnético fuerte y estable (por ejemplo, de 0,5 Tesla a 2,0 Tesla). El orificio 116 está dimensionado para recibir al menos una parte de un objeto que se va a fotografiar, por ejemplo, un cuerpo humano 118. Cuando se utiliza en aplicaciones de imágenes médicas, la máquina de IRM 108 normalmente incluye una mesa para el paciente 120 que permite deslizar o hacer rodar fácilmente a un paciente en tendido prono 118 dentro y fuera del orificio 116.
La máquina de IRM también incluye un conjunto de imanes de gradiente 122 (sólo se indica uno). Los imanes de gradiente 122 producen un campo magnético variable que es relativamente más pequeño que el producido por el imán principal 114 (por ejemplo, de 180 Gauss a 270 Gauss), permitiendo que se obtengan imágenes de porciones seleccionadas de un objeto (por ejemplo, un paciente).
La máquina de IRM 108 también incluye bobinas de radiofrecuencia (RF) 124 (sólo se menciona una) que se operan para aplicar energía de radiofrecuencia a porciones seleccionadas del objeto (por ejemplo, paciente 118) del que se van a tomar imágenes. Se pueden usar diferentes bobinas de RF 124 para obtener imágenes de diferentes estructuras (por ejemplo, estructuras anatómicas). Por ejemplo, un conjunto de bobinas de RF 124 puede ser apropiado para obtener imágenes del cuello de un paciente, mientras que otro conjunto de bobinas de RF 124 puede ser apropiado para obtener imágenes del tórax o del corazón del paciente. Las máquinas de IRM 108 comúnmente incluyen imanes adicionales, por ejemplo, imanes resistivos y/o imanes permanentes.
La máquina de IRM 108 normalmente incluye, o está acoplada comunicativamente a, un sistema de control de IRM basado en procesador 126 usado para controlar los imanes y/o bobinas 114, 122, 124. El sistema de control basado en procesador 126 puede incluir uno o más procesadores, memoria no transitoria legible por computadora o procesador, circuitos de accionamiento y/o componentes de interfaz para interactuar con la máquina de IRM 108. El sistema de control basado en procesador 126 puede, en algunas implementaciones, también realizar algún pre procesamiento de los datos resultantes de la operación de IRM.
Un sistema de operador de IRM 128 puede incluir un sistema informático 130, monitor o pantalla 132, teclado y/o teclado 134 y/o un dispositivo de control del cursor tal como un ratón 136, joystick, trackpad, trackball o similares. El sistema de operador de IRM 128 puede incluir o leer instrucciones ejecutables por computadora o procesador desde uno o más medios no transitorios legibles por computadora o procesador, por ejemplo, medios giratorios 138 tales como un disco magnético u óptico. El sistema de operador 128 puede permitir que un técnico opere la máquina de IRM 108 para capturar datos de IRM de un paciente 118. Varias técnicas, estructuras y características descritas en el presente documento pueden permitir el funcionamiento de la máquina de IRM 108 por parte de un técnico sin requerir la presencia de un médico. Ventajosamente, esto puede reducir significativamente los costos de los procedimientos de resonancia magnética. También como se describe en el presente documento, diversas técnicas, estructuras y características pueden permitir que los procedimientos de IRM se realicen mucho más rápidamente que el uso de técnicas convencionales. Esto puede permitir ventajosamente un mayor rendimiento para cada instalación de IRM, amortizando el costo del equipo intensivo en capital durante un número mucho mayor de procedimientos. Por ejemplo, las computadoras de alta potencia computacional pueden ubicarse remotamente desde el entorno clínico y pueden usarse para dar servicio a múltiples instalaciones clínicas. Las diversas técnicas, estructuras y características descritas en el presente documento también pueden reducir adicional o alternativamente de manera ventajosa el tiempo que cada paciente está expuesto al procedimiento de resonancia magnética, reduciendo o aliviando la ansiedad que a menudo acompaña a la realización de un procedimiento de resonancia magnética. Por ejemplo, eliminar la necesidad de contener la respiración y/o sincronizar con los ciclos pulmonares y/o cardíacos de un paciente mediante técnicas de análisis y procesamiento de imágenes descritas en el presente documento puede reducir significativamente el tiempo de adquisición, por ejemplo, a de ocho a diez minutos.
El sistema de procesamiento y análisis de imágenes 104 puede incluir uno o más servidores 139 para manejar solicitudes y respuestas entrantes, y una o más computadoras de procesamiento y análisis de imágenes o representación 140. Los servidores 139 pueden, por ejemplo, tomar la forma de uno o más ordenadores servidores, ordenadores estaciones de trabajo, superordenadores u ordenadores personales, que ejecutan software o instrucciones de servidor. La una o más computadoras de procesamiento y análisis de imágenes o representación 140 pueden tomar la forma de uno o más ordenadores, ordenadores de estaciones de trabajo, superordenadores u ordenadores personales, que ejecutan software o instrucciones de procesamiento y/o análisis de imágenes. Una o más computadoras de procesamiento y análisis de imágenes o representación 140 normalmente emplearán una, y preferiblemente múltiples, unidades de procesamiento gráfico (graphical processing unit, GPU) o núcleos de GPU.
El sistema de procesamiento y análisis de imágenes 104 puede incluir uno o más medios no transitorios legibles por computadora 142 (por ejemplo, discos duros magnéticos u ópticos, RAID, RAM, Flash) que almacenan instrucciones y/o datos ejecutables por el procesador u otra información. El sistema de procesamiento y análisis de imágenes 104 puede incluir uno o más sistemas de operador de procesamiento y análisis de imágenes 144. El sistema del operador de procesamiento y análisis de imágenes 144 puede incluir un sistema informático 146, monitor o pantalla 148, teclado y/o teclado 150 y/o un dispositivo de control del cursor tal como un ratón 152, joystick, trackpad, trackball o similares. El sistema de operador de procesamiento y análisis de imágenes 144 puede estar acoplado comunicativamente a la(s) computadora(s) de procesamiento y análisis de imágenes o representación 140 a través de una o más redes, por ejemplo, una LAN 154. Si bien muchas técnicas y análisis de procesamiento de imágenes pueden estar completamente automatizados, el sistema de operador de procesamiento y análisis de imágenes puede permitir a un técnico realizar ciertas operaciones de procesamiento y/o análisis de imágenes en datos de IRM capturados de un paciente.
Si bien se ilustra como un único medio de almacenamiento no transitorio legible por computadora o procesador 142, en muchas implementaciones el medio de almacenamiento no transitorio legible por computadora o procesador 142 puede constituir una pluralidad de medios de almacenamiento no transitorios. La pluralidad de medios de almacenamiento no transitorios puede estar ubicada comúnmente en una ubicación común o distribuida en una variedad de ubicaciones remotas. Por lo tanto, una base de datos de datos de IRM sin procesar, datos de IRM pre procesados y/o datos de IRM procesados se puede implementar en uno o en más de un medio de almacenamiento no transitorio legible por computadora o procesador. Dichas bases de datos pueden almacenarse por separado entre sí en un medio de almacenamiento 142 legible por computadora o procesador separado o pueden almacenarse en el mismo medio de almacenamiento 142 legible por computadora o procesador que las demás. El medio de almacenamiento legible por computadora o procesador 142 puede estar ubicado junto con el sistema de análisis y procesamiento de imágenes 104, por ejemplo, en la misma habitación, edificio o instalación. Alternativamente, el medio de almacenamiento legible por computadora o procesador 142 puede estar ubicado remotamente desde el sistema de procesamiento y análisis de imágenes 104, por ejemplo, en una instalación, ciudad, estado o país diferente. La información, archivos o registros electrónicos o digitales u otras colecciones de información pueden almacenarse en ubicaciones específicas en medios no transitorios legibles por computadora o procesador 142, por lo que son partes lógicamente direccionables de dichos medios, que pueden o no ser contiguas.
Como se señaló anteriormente, el sistema de procesamiento y análisis de imágenes 104 puede estar ubicado de forma remota desde el sistema de adquisición de IRM 102. El sistema de adquisición de IRM 102 y el sistema de procesamiento y análisis de imágenes 104 son capaces de comunicarse, por ejemplo, a través de uno o más canales de comunicaciones, por ejemplo, redes de área local (LAN) 106a y redes de área amplia (WAN) 106b. Las redes 106 pueden incluir, por ejemplo, redes de comunicaciones conmutadas por paquetes, tales como Internet, la porción de Internet de la Web mundial, extranets y/o intranets. Las redes 106 pueden tomar la forma de varios otros tipos de redes de telecomunicaciones, tales como redes de datos y de telefonía celular, y redes de sistemas telefónicos antiguos (plain old telephone system, POTS). El tipo de infraestructura de comunicaciones no debe considerarse limitante.
Como se ilustra en la Figura 1, el sistema de adquisición de IRM 102 está acoplado comunicativamente a la primera LAN 106a. La primera LAN 106a puede ser una red operada por o para la instalación clínica, que proporciona comunicaciones de área local para la instalación clínica. La primera LAN 106a está acoplada comunicativamente a la WAN (por ejemplo, Internet) 106b. Un primer cortafuegos o firewall 156a puede proporcionar seguridad para la primera LAN.
También como se ilustra en la Figura 1, el sistema de análisis y procesamiento de imágenes 104 está acoplado comunicativamente a la segunda LAN 154. La segunda LAN 154 puede ser una red operada por o para una instalación o entidad de procesamiento de imágenes, que proporciona comunicaciones de área local para la instalación o entidad de procesamiento de imágenes. La segunda LAN 154 está acoplada comunicativamente a la WAN 106b (por ejemplo, Internet). Un segundo cortafuegos o firewall 156b puede proporcionar seguridad para la segunda LAN 154.
La instalación o entidad de procesamiento de imágenes puede ser independiente de la instalación clínica, por ejemplo, una empresa independiente que proporciona servicios a una, dos o muchas instalaciones clínicas.
Si bien no se ilustra, la red de comunicaciones puede incluir uno o más dispositivos de red adicionales. Los dispositivos de red pueden adoptar cualquiera de una gran variedad de formas, incluidos servidores, enrutadores, conmutadores de red, puentes y/o módems (por ejemplo, módem DSL, módem por cable), etc.
Si bien la Figura 1 ilustra un entorno de red representativo 100, los entornos de red típicos pueden incluir muchos sistemas de adquisición de IRM, sistemas de análisis y procesamiento de imágenes 104, sistemas informáticos y/o entidades adicionales. Los conceptos que se enseñan aquí se pueden emplear de manera similar con entornos de red más poblados que el ilustrado. Por ejemplo, una única entidad puede proporcionar servicios de análisis y procesamiento de imágenes a múltiples entidades de diagnóstico. Una o más de las entidades de diagnóstico pueden operar dos o más sistemas de adquisición de IRM 102. Por ejemplo, un gran hospital o un centro de imágenes médicas dedicado puede operar dos, tres o incluso más sistemas de adquisición de IRM en una sola instalación. Normalmente, la entidad que proporciona los servicios de procesamiento y análisis de imágenes operará múltiples entidades que pueden proporcionar sistemas de procesamiento y análisis de imágenes 104 que pueden incluir dos, tres o incluso cientos de computadoras de procesamiento y análisis de imágenes o de representación 140.
La Figura 2 muestra un entorno en red 200 que comprende uno o más sistemas de análisis y procesamiento de imágenes 104 (solo uno ilustrado) y uno o más medios de almacenamiento no transitorios asociados legibles por computadora o procesador 204 (solo uno ilustrado). El medio de almacenamiento no transitorio asociado legible por computadora o procesador 204 está acoplado comunicativamente al sistema(s) de procesamiento y análisis de imágenes 104 a través de uno o más canales de comunicaciones, por ejemplo, uno o más cables paralelos, cables en serie o canales inalámbricos capaces de comunicaciones de alta velocidad, por ejemplo, a través de FireWire®, Universal Serial Bus® (USB) 2 o 3, y/o Thunderbolt®, Gigabyte Ethernet®.
El entorno en red 200 también comprende uno o más sistemas finales de adquisición de IRM 102 (solo se ilustra uno). El(los) sistema(s) de adquisición de IRM 102 están acoplados comunicativamente al(los) sistema(s) de procesamiento y análisis de imágenes 104 mediante uno o más canales de comunicaciones, por ejemplo, una o más redes de área amplia (WAN) 210, por ejemplo, Internet o la porción Web mundial del mismo.
En funcionamiento, los sistemas de adquisición de IRM 102 normalmente funcionan como un cliente para el sistema de procesamiento y análisis de imágenes 104. En funcionamiento, los sistemas de procesamiento y análisis de imágenes 104 normalmente funcionan como un servidor para recibir solicitudes o información (por ejemplo, conjuntos de datos de IRM) desde los sistemas de adquisición de IRM 102. En el presente documento se describe un proceso general que emplea un comando asincrónico y una canalización de imágenes que permite que el procesamiento y análisis de imágenes se realice de forma remota (por ejemplo, a través de una w An ) desde el sistema de adquisición de IRM 102. Este enfoque proporciona una serie de ventajas distintivas, por ejemplo, permitir que un técnico opere el sistema o sistemas de adquisición de IRM 102 sin requerir la presencia de un experto clínico (por ejemplo, un médico). También se describen diversas técnicas o enfoques para mejorar la seguridad, permitiendo al mismo tiempo el acceso a datos de imágenes médicas, así como a información de salud privada específica del paciente.
Si bien se ilustra como ubicado remotamente del sistema de adquisición de IRM 102, en algunas implementaciones los sistemas de procesamiento y análisis de imágenes 104 pueden ubicarse junto con el sistema de adquisición de IRM 102. En otras implementaciones, una o más de las operaciones o funciones descritas en el presente documento pueden realizarse mediante el sistema de adquisición de IRM 102 o mediante un dispositivo basado en procesador ubicado conjuntamente con el sistema de adquisición de IRM 102.
Los sistemas de procesamiento y análisis de imágenes 104 reciben conjuntos de datos de IRM, realizan procesamiento de imágenes en los conjuntos de datos de IRM y proporcionan los conjuntos de datos de IRM procesados, por ejemplo, a un médico para su revisión. Los sistemas de procesamiento y análisis de imágenes 104 pueden, por ejemplo, realizar detección y/o corrección de errores en conjuntos de datos de IRM, por ejemplo, corrección de errores de fase, detección de alias de fase, desenvolvimiento de señales y/o detección y/o corrección de diversos artefactos. El error de fase está relacionado con la fase, al igual que el alias de fase. El desenvolvimiento de la señal está relacionado con la magnitud. Varios otros artefactos pueden estar relacionados con la fase y/o la magnitud.
Los sistemas de procesamiento y análisis de imágenes 104 pueden, por ejemplo, realizar segmentación, distinguiendo entre varios tipos de tejido. Los sistemas de procesamiento y análisis de imágenes 104 pueden, por ejemplo, realizar cuantificación, por ejemplo, comparando el flujo sanguíneo dentro y fuera de una estructura anatómica cerrada o a través de dos o más estructuras anatómicas. Los sistemas de procesamiento y análisis de imágenes 104 pueden usar ventajosamente la cuantificación para verificar los resultados, por ejemplo, confirmando la identificación de un determinado tejido y/o proporcionando una indicación de un grado de certeza en los resultados. Además, los sistemas de procesamiento y análisis de imágenes 104 pueden usar ventajosamente la cuantificación para identificar la existencia de una derivación.
En algunas implementaciones, los sistemas de procesamiento y análisis de imágenes 104 pueden generar imágenes que reflejan el flujo sanguíneo, incluyendo por ejemplo distinguir entre flujo sanguíneo arterial y venoso. Por ejemplo, los sistemas de procesamiento y análisis de imágenes 104 pueden emplear un primer mapa de colores (por ejemplo, azul) para indicar el flujo sanguíneo arterial y un segundo mapa de colores (por ejemplo, rojo) para indicar el flujo sanguíneo venoso. Los sistemas de procesamiento y análisis de imágenes 104 pueden indicar aberraciones (por ejemplo, derivación) utilizando algún otro color distintivo o énfasis visual. Se describen numerosas técnicas diferentes para distinguir entre diferentes tejidos, así como entre el flujo sanguíneo arterial y venoso. La visualización del flujo puede superponerse, por ejemplo, como una o más capas, encima o sobre representaciones visuales de estructura anatómica o datos de magnitud.
En algunas implementaciones, los sistemas de procesamiento y análisis de imágenes 104 pueden generar un protocolo de flujo 4-D específico del paciente para su uso en el funcionamiento de un sistema de adquisición de IRM 102 con un paciente específico. Esto puede incluir establecer una codificación de velocidad (velocity enconding, VENC) adecuada para el funcionamiento de la máquina de resonancia magnética.
Los sistemas de procesamiento y análisis de imágenes 104 pueden realizar una o más de estas operaciones o funciones de forma autónoma, sin intervención humana. Alternativamente, los sistemas de procesamiento y análisis de imágenes 104 pueden realizar una o más de estas operaciones o funciones basándose en información humana, por ejemplo, información humana que identifica un punto, ubicación o plano, o que de otro modo identifica una característica del tejido anatómico. Algunos planos y/o vistas pueden estar predefinidos, lo que permite al operador, usuario o médico seleccionar simplemente un plano (por ejemplo, un plano de válvula) o una vista denominada (por ejemplo, vista de 2 cámaras, vista de 3 cámaras, vista de 4 cámaras) para rápidamente y obtener fácilmente la vista deseada.
El entorno de red 200 puede emplear otros sistemas informáticos y equipos de red, por ejemplo, servidores adicionales, servidores proxy, cortafuegos, enrutadores y/o puentes. En ocasiones, se hará referencia a los sistemas de procesamiento y análisis de imágenes 104 en singular en el presente documento, pero esto no pretende limitar las realizaciones a un solo dispositivo, ya que en realizaciones típicas puede haber más de un sistema de procesamiento y análisis de imágenes 104 involucrado. A menos que se describa lo contrario, la construcción y operación de los diversos bloques mostrados en la Figura 2 son de diseño convencional. Como resultado, no es necesario describir dichos bloques con mayor detalle en el presente documento, tal como los entenderán los expertos en la técnica relevante.
Los sistemas de procesamiento y análisis de imágenes 104 pueden incluir una o más unidades de procesamiento 212a, 212b (colectivamente 212), una memoria de sistema 214 y un bus del sistema 216 que acopla varios componentes del sistema, incluida la memoria de sistema 214 a las unidades de procesamiento 212. Las unidades de procesamiento 212 pueden ser cualquier unidad de procesamiento lógico, tal como una o más unidades centrales de procesamiento (central processing unit, CPU) 212a, procesadores de señales digitales (digital signal processor, DSP) 212b, circuitos integrados de aplicación específica (application-specific integrated circuit, ASIC), matrices de puertas lógicas programables en campo (field-programmable gate array, FPGA), etc. El bus del sistema 216 puede emplear cualquier estructura o arquitectura de bus conocida, incluido un bus de memoria con controlador de memoria, un bus periférico y/o un bus local. La memoria de sistema 214 incluye memoria de sólo lectura ("ROM") 218 y memoria de acceso aleatorio ("RAM") 220. Un sistema básico de entrada/salida ("BIOS") 222, que puede formar parte de la ROM 218, contiene rutinas básicas que ayudan a transferir información entre elementos dentro del sistema(s) de procesamiento y análisis de imágenes 104, tal como durante el inicio.
El(los) sistema(s) de procesamiento y análisis de imágenes 104 pueden incluir una unidad de disco duro 224 para leer y escribir en un disco duro 226, una unidad de disco óptico 228 para leer y escribir en discos ópticos extraíbles 232 y/o una unidad de disco magnético 230 para lectura y escritura en discos magnéticos 234. El disco óptico 232 puede ser un CD-ROM, mientras que el disco magnético 234 puede ser un disquete o disquete magnético. La unidad de disco duro 224, la unidad de disco óptico 228 y la unidad de disco magnético 230 pueden comunicarse con la unidad de procesamiento 212 a través del bus del sistema 216. La unidad de disco duro 224, la unidad de disco óptico 228 y la unidad de disco magnético 230 pueden incluir interfaces o controladores (no mostrados) acoplados entre dichas unidades y el bus del sistema 216, como saben los expertos en la técnica relevante. Las unidades 224, 228 y 230, y sus medios legibles por computadora asociados 226, 232, 234, proporcionan almacenamiento no volátil de instrucciones, estructuras de datos, módulos de programa y otros datos legibles por computadora para el o los sistemas de procesamiento y análisis de imágenes 104. Aunque los sistemas de procesamiento y análisis de imágenes 104 representados se ilustran empleando un disco duro 224, un disco óptico 228 y un disco magnético 230, los expertos en la técnica relevante apreciarán que otros tipos de medios legibles por computadora que pueden almacenar datos accesibles por una computadora pueden emplearse, como unidades WORM, unidades RAID, casetes magnéticos, tarjetas de memoria flash, discos de vídeo digitales ("DVD"), cartuchos Bernoulli, RAM, ROM, tarjetas inteligentes, etc.
Los módulos de programa se pueden almacenar en la memoria de sistema 214, tal como un sistema operativo 236, uno o más programas de aplicación 238, otros programas o módulos 240 y datos de programa 242. Los programas de aplicación 238 pueden incluir instrucciones que hacen que el procesador o procesadores 212 realicen procesamiento y análisis de imágenes en conjuntos de datos de imágenes de IRM. Por ejemplo, los programas de aplicación 238 pueden incluir instrucciones que hacen que el procesador o procesadores 212 realicen una corrección de errores de fase en datos relacionados con la fase o la velocidad. Por ejemplo, los programas de aplicación 238 pueden incluir instrucciones que hacen que el (los) procesador(es) 212 corrijan el alias de fase. También, por ejemplo, los programas de aplicación 238 pueden incluir instrucciones que hacen que el (los) procesador(es) 212 realicen el desenvolvimiento de la señal. Adicional o alternativamente, los programas de aplicación 238 pueden incluir instrucciones que hacen que el(los) procesador(es) 212 identifiquen y/o corrijan artefactos.
Los programas de aplicación 238 pueden incluir instrucciones que hacen que el (los) procesador(es) 212 realicen, por ejemplo, segmentación, distinguiendo entre varios tipos de tejido. Los programas de aplicación 238 pueden incluir instrucciones que hacen que el procesador o procesadores 212 realicen una cuantificación, por ejemplo, comparando el flujo sanguíneo dentro y fuera de una estructura anatómica cerrada o a través de dos o más estructuras anatómicas.
Los programas de aplicación 238 pueden incluir instrucciones que hacen que el procesador o procesadores 212 utilicen la cuantificación para verificar los resultados, por ejemplo, confirmando la identificación de un determinado tejido y/o proporcionando una indicación de un grado de certeza en los resultados. Los programas de aplicación 238 pueden incluir instrucciones que hacen que el procesador o procesadores 212 utilicen la cuantificación para identificar la existencia de una derivación.
Los programas de aplicación 238 pueden incluir instrucciones que hacen que el procesador o procesadores 212 generen imágenes que reflejen el flujo sanguíneo, por ejemplo, distinguiendo entre flujo sanguíneo arterial y venoso. Por ejemplo, se puede usar un primer mapa de colores (por ejemplo, azul) para indicar el flujo sanguíneo arterial y un segundo mapa de colores (por ejemplo, rojo) para indicar el flujo sanguíneo venoso. Las aberraciones (por ejemplo, derivación) pueden indicarse utilizando algún otro color distintivo o énfasis visual. Se pueden aplicar funciones de transferencia de color para generar los mapas de color. Los programas de aplicación 238 pueden incluir instrucciones que hacen que el(los) procesador(es) 212 superpongan la visualización del flujo (por ejemplo, datos de fase de IRM indicativos de la velocidad y/o volumen del flujo sanguíneo) sobre la visualización o imágenes renderizadas de anatomía (por ejemplo, datos de magnitud de IRM). Las instrucciones pueden hacer que la visualización del flujo se represente como una o más capas en las imágenes de la anatomía para proporcionar una fusión de información de anatomía (es decir, magnitud) y flujo (es decir, fase), por ejemplo, como un mapa de calor en color y/o o como vectores (por ejemplo, iconos de flecha) con dirección y magnitud (por ejemplo, representados por longitud, grosor de línea). Las instrucciones pueden causar adicional o alternativamente la generación de mapeos espaciales o visualización de dispersión de señal, turbulencia y/o presión, que pueden superponerse o superponerse a un mapeo espacial o visualización de estructura anatómica. Fusionar la visualización de información relacionada con la fase o la velocidad con la visualización de información anatómica o representaciones visuales de estructuras anatómicas puede facilitar la identificación de puntos de referencia anatómicos. Las instrucciones pueden utilizar conjuntos o matrices de unidades de procesamiento de gráficos o GPU para representar rápidamente las visualizaciones.
También se pueden aplicar funciones de transferencia para determinar qué efectos visuales (por ejemplo, color) aplicar a qué tejido. Por ejemplo, el flujo sanguíneo arterial puede colorearse en tonos de azul y el flujo sanguíneo venoso en tonos de rojo, mientras que el tejido adiposo puede colorearse de amarillo. La estructura anatómica, representada como magnitud en el conjunto de datos de imágenes de resonancia magnética, puede visualizarse, por ejemplo, utilizando una escala de grises. La profundidad de visión puede ser ajustable por el operador o el usuario, por ejemplo, mediante un control deslizante en una interfaz gráfica de usuario. Por lo tanto, la visualización puede tener la forma de una vista de fusión que fusiona ventajosamente una representación visual de información de velocidad con una representación visual de información o representación anatómica.
Los programas de aplicación 238 pueden incluir instrucciones que hacen que el(los) procesador(es) 212 generen un protocolo de flujo 4-D específico del paciente para su uso en la operación de un sistema de adquisición de IRM 102 con un paciente específico. Esto puede basarse en información específica del paciente, por ejemplo, proporcionada por un técnico, y puede basarse en la máquina de resonancia magnética particular que se utiliza para capturar el conjunto de datos de resonancia magnética.
Los programas de aplicación 238 pueden incluir instrucciones que hacen que el procesador o procesadores 212 reciban conjuntos de datos de imágenes del sistema de adquisición de IRM, procesen y/o analicen los conjuntos de datos de imágenes y proporcionen imágenes procesadas y/o analizadas y otra información a los usuarios de forma remota. ubicado desde el procesamiento de imágenes, de manera segura y sensible al tiempo. Esto se describe en detalle en el presente documento con referencia a las diversas figuras.
La memoria de sistema 214 también puede incluir programas de comunicaciones, por ejemplo, un servidor 244 que hace que los sistemas 104 de procesamiento y análisis de imágenes sirvan información o archivos electrónicos a través de Internet, intranets, extranets, redes de telecomunicaciones u otras redes como se describe a continuación. El servidor 244 en la realización representada está basado en un lenguaje de marcado, tal como un lenguaje de marcado de hipertexto (HTML), un lenguaje de marcado extensible (XML) o un lenguaje de marcado inalámbrico (WML), y opera con lenguajes de marcado que usan caracteres delimitados sintácticamente agregados a los datos de un documento para representar la estructura del documento. Es posible que se encuentren disponibles comercialmente varios servidores adecuados, como los de Mozilla, Google, Microsoft y Apple Computer.
Aunque se muestran en la Figura 2 almacenados en la memoria de sistema 214, el sistema operativo 236, los programas de aplicación 238, otros programas/módulos 240, los datos del programa 242 y el servidor 244 pueden almacenarse en el disco duro 226 de la unidad de disco duro 224, en el disco óptico 232 de la unidad de disco óptico 228 y/o en el disco magnético 234 de la unidad de disco magnético 230.
Un operador puede ingresar comandos e información en el o los sistemas de procesamiento y análisis de imágenes 104 a través de dispositivos de entrada tales como una pantalla táctil o teclado 246 y/o un dispositivo señalador tal como un mouse 248, y/o mediante una interfaz gráfica de usuario. Otros dispositivos de entrada pueden incluir un micrófono, un joystick, un mando para juegos, una tableta, un escáner, etc. Estos y otros dispositivos de entrada están conectados a una o más de las unidades de procesamiento 212 a través de una interfaz 250 tal como una interfaz de puerto serie que se acopla al bus del sistema 216, aunque se pueden utilizar otras interfaces tales como un puerto paralelo, un puerto de juego o una interfaz inalámbrica o un bus serie universal ("USB"). Un monitor 252 u otro dispositivo de visualización está acoplado al bus del sistema 216 a través de una interfaz de vídeo 254, tal como un adaptador de vídeo. El(los) sistema(s) de procesamiento y análisis de imágenes 104 pueden incluir otros dispositivos de salida, tales como altavoces, impresoras, etc.
Los sistemas de procesamiento y análisis de imágenes 104 pueden operar en un entorno de red 200 usando conexiones lógicas a una o más computadoras y/o dispositivos remotos. Por ejemplo, el procesamiento y análisis de imágenes 104 puede operar en un entorno de red 200 usando conexiones lógicas a uno o más sistemas de adquisición de IRM 102. Las comunicaciones pueden realizarse a través de una arquitectura de red cableada y/o inalámbrica, por ejemplo, redes informáticas empresariales cableadas e inalámbricas, intranets, extranets y/o Internet. Otras realizaciones pueden incluir otros tipos de redes de comunicaciones, incluidas redes de telecomunicaciones, redes celulares, redes de localización y otras redes móviles. Puede haber cualquier variedad de computadoras, dispositivos de conmutación, enrutadores, puentes, cortafuegos y otros dispositivos en las rutas de comunicación entre los sistemas de procesamiento y análisis de imágenes 104 y los sistemas de adquisición de IRM 102.
Los sistemas de adquisición de IRM 102 normalmente tomarán la forma de una máquina de IRM 108 y uno o más dispositivos asociados basados en procesadores, por ejemplo, un sistema de control de IRM 126 y/o un sistema de operador de IRM 128. Los sistemas de adquisición de iRm 102 capturan información de IRM o conjuntos de datos de pacientes. Por lo tanto, en algunos casos los sistemas de adquisición de IRM 102 pueden denominarse sistemas de adquisición de IRM frontales o sistemas de captura de IRM, para distinguirlos del sistema o sistemas de procesamiento y análisis de imágenes de IRM 104, que en algunos casos pueden denominarse como sistemas finales de IRM. En ocasiones, en el presente documento se hará referencia a cada uno de los sistemas de adquisición de IRM 102 en singular, pero esto no pretende limitar las realizaciones a un único sistema de adquisición de IRM 102. En realizaciones típicas, puede haber más de un sistema de adquisición de IRM 102 y probablemente habrá una gran cantidad de sistemas de adquisición de IRM 102 en el entorno de red 200.
Los sistemas de adquisición de IRM 102 pueden estar acoplados comunicativamente a uno o más ordenadores servidores (no mostrados). Por ejemplo, los sistemas de adquisición de IRM 102 pueden estar acoplados comunicativamente a través de una o más computadoras servidoras de instalaciones de diagnóstico (no mostradas), enrutadores (no mostrados), puentes (no mostrados), LAN 106a (Figura 1), etc., que pueden incluir o implementar un cortafuegos o firewall 156a (Figura 1). Las computadoras servidor (no mostradas) pueden ejecutar un conjunto de instrucciones de servidor para funcionar como un servidor para varios sistemas de adquisición de IRM 102 (es decir, clientes) acoplados comunicativamente a través de una LAN 106a en una instalación o sitio clínico, y así actuar como intermediarios entre los sistemas de adquisición de IRM 102 y el sistema(s) de procesamiento y análisis de imágenes de IRM 104. Los sistemas de adquisición de IRM 102 pueden ejecutar un conjunto de instrucciones de cliente para funcionar como cliente de la(s) computadora(s) servidor(es), que están acoplados comunicativamente a través de una WAN.
El sistema de control de IRM 126 normalmente incluye uno o más procesadores (por ejemplo, microprocesadores, unidades centrales de procesamiento, procesadores de señales digitales, unidades de procesamiento gráfico) y memoria no transitoria legible por procesador (por ejemplo, ROM, RAM, Flash, discos magnéticos y/u ópticos). El sistema de operador de IRM 128 puede tomar la forma de una computadora, por ejemplo, computadoras personales (por ejemplo, computadoras de escritorio o portátiles), computadoras netbook, tabletas, teléfonos inteligentes, asistentes digitales personales, computadoras de estación de trabajo y/o computadoras centrales, y similares, que ejecutan instrucciones apropiadas.
El sistema de operador de IRM 128 puede incluir una o más unidades de procesamiento 268, memorias de sistema 269 y un bus del sistema (no mostrado) que acopla varios componentes del sistema, incluida la memoria de sistema 269, a la unidad de procesamiento 268.
La unidad de procesamiento 268 puede ser cualquier unidad de procesamiento lógico, tal como una o más unidades centrales de procesamiento (CPU), procesadores de señales digitales (DSP), circuitos integrados de aplicación específica (ASIC), conjuntos de puertas programables en campo (FPGA), unidades de procesamiento gráfico (GPU), etc. Los ejemplos no limitantes de sistemas informáticos disponibles comercialmente incluyen, entre otros, un microprocesador de la serie 80x86 o Pentium de Intel Corporation, EE.UU., un microprocesador PowerPC de IBM, un microprocesador Sparc de Sun Microsystems, Inc., una serie PA-RISC. microprocesador de Hewlett-Packard Company, un microprocesador de la serie 68xxx de Motorola Corporation, un procesador ATOM o un procesador A4 o A5. A menos que se describa lo contrario, la construcción y operación de los diversos bloques de los sistemas de adquisición de iRm 102 mostrados en la Figura 2 son de diseño convencional. Como resultado, no es necesario describir dichos bloques con mayor detalle en el presente documento, tal como los entenderán los expertos en la técnica relevante.
El bus del sistema puede emplear cualquier estructura o arquitectura de bus conocida, incluido un bus de memoria con controlador de memoria, un bus periférico y un bus local. La memoria de sistema 269 incluye memoria de sólo lectura ("ROM") 270 y memoria de acceso aleatorio ("RAM") 272. Un sistema básico de entrada/salida ("BIOS") 271, que puede formar parte de la ROM 270, contiene rutinas básicas que ayudan a transferir información entre elementos dentro de los sistemas de adquisición de IRM 102, como durante el inicio.
El sistema de operador de IRM 128también puede incluir una o más unidades de medios 273, por ejemplo, una unidad de disco duro, una unidad de disco magnético, una unidad WORM y/o una unidad de disco óptico, para leer y escribir en medios de almacenamiento legibles por computadora 274, por ejemplo, discos duro, discos ópticos y/o discos magnéticos. Los medios de almacenamiento no transitorios legibles por computadora 274 pueden, por ejemplo, tomar la forma de medios extraíbles. Por ejemplo, los discos duros pueden adoptar la forma de una unidad Winchester y los discos ópticos pueden adoptar la forma de CD-ROM, mientras que los discos magnéticos pueden adoptar la forma de disquetes o disquetes magnéticos. La(s) unidad(es) de medios 273 se comunican con la unidad de procesamiento 268 a través de uno o más buses del sistema. Las unidades de medios 273 pueden incluir interfaces o controladores (no mostrados) acoplados entre dichas unidades y el bus del sistema, como saben los expertos en la técnica relevante. Las unidades de medios 273, y sus medios de almacenamiento no transitorios legibles por computadora 274 asociados, proporcionan almacenamiento no volátil de instrucciones, estructuras de datos, módulos de programa y otros datos legibles por computadora para los sistemas de adquisición de IRM 102. Aunque se describe que emplea medios de almacenamiento legibles por computadora 274 tales como discos duros, discos ópticos y discos magnéticos, los expertos en la técnica relevante apreciarán que el o los sistemas de operador de<i>R<m>128 pueden emplear otros tipos de medios de almacenamiento no transitorios legibles por computadora que pueden almacenar datos accesibles mediante una computadora, como casetes magnéticos, tarjetas de memoria flash, discos de video digitales ("DVD"), cartuchos Bernoulli, RAM, ROM, tarjetas inteligentes, etc. Los datos o información, por ejemplo, archivos electrónicos o digitales o datos o metadatos relacionados con los mismos pueden almacenarse en los medios de almacenamiento no transitorios legibles por computadora 274.
Los módulos de programa, tales como un sistema operativo, uno o más programas de aplicación, otros programas o módulos y datos de programa, se pueden almacenar en la memoria de sistema 269. Los módulos del programa pueden incluir instrucciones para acceder a un sitio web, un sitio extranet u otro sitio o servicios (por ejemplo, servicios web) y páginas web asociadas, otras páginas, pantallas o servicios alojados o proporcionados por los sistemas de procesamiento y análisis de IRM 104.
En particular, la memoria de sistema 269 puede incluir programas de comunicaciones que permiten que el sistema o sistemas de adquisición de IRM 102 intercambien información o archivos electrónicos o digitales o datos o metadatos con los servicios de procesamiento y/o análisis de imágenes de IRM proporcionados por el sistema de procesamiento y análisis de IRM. sistema(s) 104. Los programas de comunicaciones pueden ser, por ejemplo, un cliente web o navegador que permite que el sistema o sistemas de adquisición de IRM 102 accedan e intercambien información, archivos, datos y/o metadatos con fuentes tales como sitios web de Internet, intranets corporativas, extranets u otras redes. Esto puede requerir que un cliente usuario final tenga suficiente derecho, permiso, privilegio o autoridad para acceder a un sitio web determinado, por ejemplo, uno alojado en el sistema(s) de procesamiento y análisis de IRM 104. Como se analiza en el presente documento, los datos de identificación del paciente pueden residir en sistemas operados por o para la instalación clínica, y pueden no ser accesibles por o a través de los sistemas operados por o para la instalación de procesamiento de imágenes o el personal de la instalación de procesamiento de imágenes. El navegador puede, por ejemplo, estar basado en un lenguaje de marcado, tal como un lenguaje de marcado de hipertexto (HTML), un lenguaje de marcado extensible (XML) o un lenguaje de marcado inalámbrico (WML), y puede funcionar con lenguajes de marcado que utilizan caracteres delimitados sintácticamente añadidos a los datos de un documento para representar la estructura del documento.
Si bien se describe como almacenado en la memoria de sistema 269, el sistema operativo, los programas de aplicación, otros programas/módulos, datos de programas y/o el navegador se pueden almacenar en los medios de almacenamiento legibles por computadora 274 de las unidades de medios 273. Un operador puede ingresar comandos e información en el sistema de operador de IRM 128 a través de una interfaz de usuario 275 a través de dispositivos de entrada tales como una pantalla táctil o un teclado 276 y/o un dispositivo señalador 277 como un mouse. Otros dispositivos de entrada pueden incluir un micrófono, un joystick, un mando para juegos, una tableta, un escáner, etc. Estos y otros dispositivos de entrada están conectados a la unidad de procesamiento 269 a través de una interfaz tal como una interfaz de puerto serie que se acopla al bus del sistema, aunque se pueden utilizar otras interfaces como un puerto paralelo, un puerto de juegos o una interfaz inalámbrica o un bus serie universal ("USB"). Se puede acoplar una pantalla o monitor 278 al bus del sistema a través de una interfaz de vídeo, tal como un adaptador de vídeo. El(los) sistema(s) de operador de IRM 128 pueden incluir otros dispositivos de salida, tales como altavoces, impresoras, etc.
El sistema de análisis y procesamiento de imágenes de IRM puede construir una interfaz estática, que permite restar o agregar varios tipos de tejido a un conjunto de datos de flujo 4-D de IRM. Por ejemplo, los tejidos estáticos, como la grasa o los huesos, pueden distinguirse de los tejidos no estáticos, como el aire o la sangre que fluye. El sistema de procesamiento y análisis de imágenes de resonancia magnética puede distinguir además de forma autónoma entre diversos tejidos no estáticos, por ejemplo, distinguiendo entre aire (por ejemplo, pulmones) y sangre que fluye. Además, el sistema de análisis y procesamiento de imágenes de<i>R<m>puede distinguir entre flujos sanguíneos arteriales y venosos.
Por ejemplo, el sistema de análisis y procesamiento de IRM puede emplear una transformación rápida de Fourier para identificar el tejido sanguíneo, que se espera que tenga un patrón o forma de onda pulsátil. El aire o los pulmones tenderán a tener un patrón de apariencia aleatoria en un volumen definido, a medida que se comparan las velocidades de los vóxeles vecinos. Por ejemplo, los vóxeles con velocidades fuertes o rápidas suelen ser indicativos de aire. Los conjuntos de datos de IRM pueden ser bastante grandes, por ejemplo 256 x 256 x 256 x 20 puntos de tiempo. El sistema de procesamiento y análisis de imágenes de IRM puede depender de gradientes (por ejemplo, procedimiento de descenso de gradiente) para detectar diferentes tipos de tejido, y puede emplear ventajosamente un enfoque numérico en lugar de un enfoque de solución analítica para manejar rápidamente los conjuntos de datos de iRm relativamente grandes. Al controlar el número de dígitos significativos (por ejemplo, 2) del enfoque numérico, el sistema de análisis y procesamiento de imágenes de IRM puede lograr resultados muy rápidos (por ejemplo, 1 segundo en lugar de 30 minutos), y al mismo tiempo obtener resultados que son suficientemente precisos para la aplicación concreta.
En algunas implementaciones, se pueden restar diferentes tipos de tejido del conjunto de datos de resonancia magnética del paciente, uno a la vez. Por ejemplo, restando aire o pulmón, restando sangre, separando el flujo auricular del venoso, restando hueso, dejando grasa. En particular, la grasa es estática, por lo que cada vóxel que representa la grasa debe tener una velocidad cero asociada a él. El sistema de procesamiento y análisis de imágenes de IRM puede emplear ventajosamente dicha verdad sobre el terreno para corregir el conjunto de datos de IRM para todos los tipos de tejido.
Si se encuentra una velocidad distinta de cero para el tejido de tipo graso, esto se puede utilizar para ajustar todo el conjunto de datos (por ejemplo, para todo el tejido). Por ejemplo, el sistema de análisis y procesamiento de imágenes de IRM puede generar o crear un modelo polinómico basado en un área o volumen identificado (por ejemplo, grasa o tejido blando). Puede ser un polinomio simple (por ejemplo, ax2+bx+c) o un polinomio mucho más complejo (por ejemplo, b-spline uniforme no racional). El sistema de procesamiento y análisis de imágenes de IRM puede encontrar los coeficientes del polinomio que se ajusta a la imagen, por ejemplo, usando técnicas de regresión lineal o técnicas de álgebra lineal. Esto da como resultado un modelo que el sistema de análisis y procesamiento de imágenes de IRM puede aplicar (por ejemplo, restar de) todo el campo, no solo la grasa o el tejido blando.
En una implementación, se obtienen imágenes de una réplica del cuerpo para crear un conjunto de datos de referencia o un modelo "fantasma" que se puede restar de los datos reales del paciente. La réplica del cuerpo puede estar hecha de materiales que imitan la respuesta de resonancia magnética de un cuerpo real, aunque no tendrá flujo sanguíneo. Un gradiente de fase en un conjunto de datos de referencia o modelo "fantasma" puede representar ruido (por ejemplo, ruido aleatorio) y puede usarse para corregir un cambio de fase. Este enfoque evita ventajosamente la necesidad de generar un ajuste polinómico a los datos tridimensionales. El conjunto de referencia generado o el modelo fantasma puede ser válido durante varios meses de funcionamiento de la máquina de resonancia magnética, aunque se debe generar un nuevo conjunto de datos de referencia o modelo fantasma si la máquina de resonancia magnética recibe mantenimiento o se mueve.
El sistema de análisis y procesamiento de imágenes de IRM puede definir varios filtros o máscaras para eliminar diferentes tipos de tejido o para eliminar el flujo sanguíneo venoso o auricular. Los filtros o máscaras pueden eliminar el flujo sanguíneo anómalo, como el flujo sanguíneo fuera de un rango razonable (por ejemplo, demasiado alto o rápido, demasiado lento o bajo) o cuando la sangre parece estar fluyendo en una estructura anatómica (por ejemplo, hueso) donde no debería haber flujo sanguíneo. También se puede definir un filtro o máscara para mostrar solo vóxeles que tengan magnitudes con un valor absoluto mayor que algún valor umbral. También se puede definir un filtro o máscara para mostrar solo vóxeles con un valor absoluto del producto cruzado de magnitud y un vector de velocidad cuyo valor absoluto es mayor que algún umbral definido. Además, se puede definir un filtro o máscara que muestre solo vóxeles que tengan vectores en la misma dirección que los vectores de vóxeles vecinos, para, por ejemplo, identificar o ver chorros de alta velocidad. En particular, los vectores de velocidad de los vóxeles vecinos están en diferentes direcciones y pueden ser una indicación de ruido.
PRE PROCESAMIENTO
Reducción de errores de corrección de conservación de masa
El objetivo de este algoritmo de pre procesamiento es corregir los datos de flujo (segmentación, cuantificación de flujo y corrección de errores de fase de fondo). Hay tres conjuntos de datos de flujo que deben corregirse: i) velocidad x, ii) velocidad y y iii) velocidad z. Debido a artefactos de imagen (por ejemplo, turbulencia) y ruido, los datos de flujo estarán sesgados. Para corregir esto, se utiliza la conservación de masa (es decir, principios físicos) para corregir los datos de flujo. La conservación de masa nos dice que la masa de un sistema cerrado debe permanecer constante a lo largo del tiempo, ya que la masa del sistema no puede cambiar la cantidad si no se agrega o se elimina. Por lo tanto, si se define un límite dentro del corazón (es decir, el borde luminal de las cámaras y vasos del corazón), el flujo que ingresa a un volumen estacionario debe coincidir con el flujo que sale del volumen si el líquido es incompresible. Esta teoría se puede aplicar a cualquier volumen. En el caso del flujo sanguíneo, asumimos que la densidad sanguínea es constante y, por lo tanto, la ecuación de continuidad se simplifica para significar que la divergencia del campo de velocidades es cero en todas partes. Físicamente, esto equivale a decir que la tasa de dilatación del volumen local es cero (es decir, du/dx+dv/dy+dw/dz=0). Es imposible forzar esta condición en todas partes, pero la dilatación del volumen local se puede minimizar en todos los momentos. Hay varios tipos diferentes de algoritmos que minimizarán du/dx+dv/dy+dw/dz, pero el más común es un algoritmo que generará una aproximación libre de divergencia de mínimos cuadrados del campo de flujo. Hay varias formas de construir una aproximación de mínimos cuadrados al campo de flujo con la restricción de minimizar la divergencia, y varios algoritmos diferentes para lograrlo.
Por lo general, existe un enfoque iterativo que intenta minimizar la divergencia residual en cada pasada. Además, conocer el límite exacto del vaso/cámara es importante para garantizar un flujo cero a través del límite. Sin dicho límite, se podría permitir que el flujo escape hacia el músculo cardíaco y la grasa. Además, podría haber artefactos en la imagen (es decir, causados por turbulencia). Si un usuario identifica una región donde hay artefactos ("datos incorrectos"), esta región no se utiliza para influir en la corrección del valor de velocidad en la región de "datos buenos".
Otro enfoque para resolver esto es utilizar la optimización: intentar minimizar la divergencia y al mismo tiempo garantizar que el campo vectorial original cambie lo menos posible (para seguir capturando los efectos locales y evitar el suavizado).
La conservación del momento se puede aplicar en un acto posterior para estimar los gradientes de presión a través de un recipiente además del esfuerzo cortante de la pared. Este paso de conservación de masa es fundamental para garantizar estimaciones precisas de la presión.
Corrección automática de alias de fase usando el dominio del tiempo
El alias de fase ocurre cuando el VENC que se configuró para el escaneo de flujo 4-D era demasiado bajo, lo que provoca que los valores de velocidad se "envuelvan"; desde grandes valores positivos hasta grandes valores negativos o viceversa. En principio, este envoltorio puede realizarse más de una vez.
Al analizar la variación temporal general de los datos de velocidad, es posible determinar los puntos principales del ciclo cardíaco (descritos en otra parte). Bajo el supuesto de que no hay alias de velocidad en la imagen en el pico de diástole y también bajo el supuesto de que la velocidad en un solo punto en el espacio, en realidad, no varía más de /- VENC de un punto de tiempo al siguiente, se puede corregir el alias de fase examinando la variación temporal de cada punto en el espacio de la siguiente manera:
i) Identificar el punto de tiempo máximo de diástole y suponga que no hay alias de fase en ese punto.
ii) Examinar el comportamiento temporal de cada componente de velocidad adquirida individualmente.
iii) Para cada punto en el espacio (vóxel) en cada imagen de velocidad, realizar un seguimiento del cambio en la velocidad de un punto temporal al siguiente. Si se observa que la velocidad varía más de /- VENC, se supone que se ha producido un alias.
iv) Cuando se detecta aliasing o solapamiento, el recuento de envolturas para ese punto se incrementa si la velocidad observada se reduce en más de VENc o se reduce si la velocidad observada aumenta en más de VENC.
v) En cada punto en el tiempo, la velocidad se modifica de acuerdo con el recuento de envolturas acumulado actual para ese punto sumando el producto del recuento de envolturas con dos veces VENC.
vi) Verificar que el recuento de envolturas haya regresado a un valor de cero una vez que el punto de tiempo actual haya regresado al punto de inicio de la diástole máxima inicial. Si el recuento de envolturas no ha regresado a cero, entonces el procesamiento de ese punto en el espacio (vóxel) debe considerarse un error.
El procedimiento se puede mejorar y hacer más eficaz utilizando otros procedimientos para determinar los píxeles de interés. Por ejemplo, se pueden utilizar otros procedimientos para determinar los píxeles que tienen más probabilidades de representar el flujo sanguíneo y procesar únicamente estos píxeles.
Este procedimiento también tiene la característica y ventaja de ser de autodiagnóstico. El recuento de envoltura para todos los vóxeles de sangre válidos (a diferencia del aire, por ejemplo) debe volver a cero cuando finalice el procesamiento de ese vóxel a lo largo del tiempo. Se puede realizar un seguimiento de los errores vóxel por vóxel, aunque esto tiene la debilidad de que no se garantiza que este procedimiento de detección de errores detecte todos los vóxeles de error. Sin embargo, además, al buscar una tasa de error general baja como fracción del número de píxeles donde se aplicaron las correcciones, se puede determinar si las suposiciones iniciales necesarias, requeridas por el procedimiento, son en gran medida correctas.
Corrección automática de alias de fase
El alias de fase se produce cuando el VENC que se configuró para el escaneo de flujo 4-D era demasiado bajo. Es muy fácil encontrar vóxeles con alias debido a lo siguiente:
i) Se conoce el VENC de cada escaneo ya que esta información está en el archivo de encabezado de todas las imágenes DICOM.
ii) Identificar cambios bruscos en la velocidad del flujo alrededor de la velocidad /- VENC (es decir, si VENC se establece en 100 cm/s, busque cambios bruscos en la velocidad alrededor de /- 99 cm/s). Los cambios bruscos en la velocidad significan que un vóxel puede tener un valor de velocidad de 100 cm/s y el vóxel adyacente tiene un valor de -99 cm/s.
iii) Encontrar luego el borde de la región con alias conectando todos los vóxeles que tienen un gradiente pronunciado alrededor de /- VENC.
iv) Esto da como resultado un límite cerrado. Determinar si todos los vóxeles en la región del límite cerrado tienen alias. Al comenzar en el límite y avanzar hacia el centroide de la región tridimensional, el sistema puede interrogar cada vóxel para garantizar que no haya ningún salto significativo (a través de un VENC).
v) Si no se encuentra ningún salto pronunciado, la velocidad VENC se puede agregar a todos los vóxeles dentro de la región con alias.
vi) Si se encuentra un salto pronunciado, entonces el problema se vuelve un poco más desafiante (pero aún tiene solución). En este caso, un vóxel podría envolverse varias veces (es decir, si el VENC se establece en 100 cm/s, pero la velocidad en el vóxel en realidad es 499 cm/s, esto se envolverá 2 veces y la velocidad se mostrará como 99 cm/s). La forma de corregir los datos es observar la velocidad de los vóxeles vecinos. Si hay un salto de más de 1,5 veces el VENC, entonces es necesario sumar o restar 2*VENC en esa región cerrada. La selección de sumar o restar se elige para minimizar la discontinuidad entre los vóxeles vecinos.
vii) Para mejorar aún más el algoritmo, la información sobre dónde está el tejido estático puede ser fundamental para definir dónde debe estar el cero absoluto. Dado que el tejido estático tiene velocidad 0, los vóxeles identificados como tejido estático no deben envolverse. Entonces debe haber un aumento continuo en la velocidad alejándose de la pared debido a las propiedades físicas (es decir, la capa límite del fluido). La única suposición en todo esto es que los vóxeles vecinos no tienen más de 1,5 * VENC de salto entre sí.
Corrección de corrientes Eddy en tiempo real spline
Cuando se realiza una adquisición de IRM, los datos pueden contener artefactos debido a corrientes parásitas o corrientes Eddy en el campo magnético. En una adquisición de flujo 4-D en la que se adquiere la velocidad de las partículas, los artefactos provocarán que los valores de velocidad sean incorrectos. Es fundamental con el flujo 4-D tener datos de velocidad precisos para poder cuantificar el flujo sanguíneo a través de los vasos.
Al menos una técnica para corregir los artefactos de las corrientes parásitas implica:
- segmentación volumétrica de tejidos estáticos (velocidad cero); y
- usar los datos de velocidad en estas ubicaciones estáticas para ajustar una curva al volumen que se puede restar de los datos sin procesar.
Dada una máscara de volumen que representa el tejido estático, se evalúan bloques tridimensionales de tamaño arbitrario.
Si un bloque dentro del volumen contiene suficientes vóxeles enmascarados, se considera tejido estático. La velocidad promedio para cada uno de los bloques de tejido estáticos se usa luego como valores de control para una colección de funciones spline en cada una de las tres direcciones del eje principal. Después de evaluar todas las funciones spline en las tres direcciones, el resultado es una cuadrícula regular de valores que se pueden muestrear hasta la resolución original y luego restarse de los datos originales. Después de la resta, los tejidos estáticos deben tener una velocidad efectiva de cero, y a los tejidos no estáticos se les eliminarán los artefactos de corrientes parásitas. Esto permitirá una cuantificación precisa del flujo.
Dado un volumen segmentado, se generó un nuevo volumen de resolución significativamente menor. Los valores en este nuevo volumen son el resultado de promediar valores del volumen más grande; sin embargo, dado que algunos de los elementos quedarían enmascarados por la segmentación, un elemento en el volumen de baja resolución podría tener significativamente menos datos de alta resolución y potencialmente ningún dato de alta resolución. Los elementos sin datos o con datos insuficientes se descartan. El resultado en este punto es una cuadrícula regular con agujeros. Para evaluar el producto tensorial para el volumen spline, la pasada inicial evalúa las funciones base spline para cada fila de elementos en donde el orden del spline puede variar debido al número de valores de control disponibles. Después de la primera pasada, no habrá agujeros por lo que se podrá evaluar el resto del producto tensorial. Según el análisis de nuestros datos de prueba, los resultados de este enfoque nuevo e innovador son una función tridimensional suave y variable en el tiempo que representa el error en el volumen y es muy rápida de calcular.
Para el tercer paso, nuestro enfoque para aplicar el algoritmo de corrección fue utilizar un muestreo trilineal del volumen de corrección, lo que resultó exitoso. Para cada elemento en el volumen de origen, realizamos una combinación trilineal de ocho elementos en el volumen de corrección y restamos ese valor de los datos de origen. Después de aplicar nuestra nueva función de corrección, se encontró que las mediciones de flujo tenían un error del 3%. Además, como parte del proceso requiere la interacción del usuario, también se cumplió el requisito de rendimiento en tiempo real, ya que evaluar y aplicar nuestra nueva corrección toma del orden de milisegundos en lugar de horas.
Sólidos para corrección de errores de fase de fondo
La información de la velocidad de la sangre en la resonancia magnética de flujo 4-D tiene un error que debe corregirse para obtener cálculos precisos del flujo sanguíneo. La señal de error en el tejido estático se puede utilizar para proporcionar una función de corrección para el tejido no estático (descrita en otra parte). Se puede crear un volumen tridimensional de tejido llamado sólido para identificar una sección de tejido estático o no estático. Se puede crear un sólido utilizando dos procedimientos:
Contornos ortogonales: el usuario puede dibujar manualmente tres contornos cerrados que se intersectan. La intersección de estos contornos representa un volumen sólido tridimensional de tejido estático o no estático. No es necesario que los contornos sean perfectamente ortogonales y el usuario puede crearlos en cualquier ubicación.
Inundaciones tridimensionales: el usuario también puede optar por crear automáticamente un sólido especificando el punto inicial de una inundación tridimensional. La inundación se puede utilizar en cualquier imagen, incluidas las imágenes de fase. La imagen se inunda según un umbral por debajo y por encima del valor en el punto donde el usuario hizo clic. El usuario puede controlar tanto el umbral como el radio de la inundación que se genera.
Se pueden crear múltiples sólidos usando cualquiera de los procedimientos para enmascarar áreas de tejido estático y no estático y se pueden usar superpuestos entre sí para desenmascarar áreas dentro de un sólido existente.
En algunas situaciones habrá artefactos en las imágenes. Es necesario eliminar o resaltar el artefacto para evitar que un usuario dé un diagnóstico incorrecto. Nuestro software tiene pasos de pre procesamiento (es decir, corrección de corrientes parásitas o Eddy) que calculan una métrica basada en todos los vóxeles del conjunto de datos. Para evitar estos pasos de pre procesamiento, se utiliza una herramienta para identificar los vóxeles que tienen artefactos y estos vóxeles se eliminan de cualquier paso de pre procesamiento (pero no se eliminan con fines de visualización). La herramienta puede ser una herramienta de segmentación manual (es decir, áreas de círculos de usuario que tienen artefactos) o una herramienta de segmentación semiautomática/automática que identifica artefactos. Independientemente de las características específicas de la herramienta, nuestro software necesita una función para eliminar la cuantificación de "vóxeles defectuosos".
Corrección automática de errores de fase de fondo
La medición precisa de la velocidad en escaneados de IMR de flujo 4-D requiere la aplicación de correcciones para la señal falsa introducida por las corrientes parásitas o corrientes Eddy. La determinación de la corrección de corrientes Eddy (Eddy current correction, ECC) se realiza examinando la señal de velocidad en tejido estático (inmóvil). Esto requiere enmascarar todos los tejidos en movimiento, sangre y aire. Esta afirmación describe un procedimiento para hacer esto automáticamente, sin la intervención del usuario. La corrección automática es útil ya que no sólo hace que el software sea más simple y rápido de usar, sino que también permite que la corrección se calcule previamente y se aplique cuando el usuario abre el estudio por primera vez. También es muy importante ya que permite que otros algoritmos de pre procesamiento, que hacen cosas como segmentación y medición automáticas, se beneficien de la ECC.
La ECC automática se realiza calculando los valores iniciales de inicio para tres filtros que luego el usuario puede ajustar libremente una vez abierto el estudio. El aire se enmascara enmascarando regiones con valores de imagen anatómica por debajo de un umbral establecido. Este umbral se determina automáticamente mediante un análisis del histograma de los valores de la imagen anatómica en todo el volumen escaneado. El histograma de estos valores sobre la cavidad torácica muestra un patrón que permite la detección automática de los valores de la imagen correspondientes al aire.
Además, se han desarrollado dos filtros que detectan de forma fiable regiones de flujo sanguíneo y regiones de movimiento de la pared cardíaca. La región del corazón se puede enmascarar satisfactoriamente ajustando adecuadamente estos dos filtros. Debido a la normalización utilizada en la producción de estos filtros junto con su naturaleza naturalmente consistente, se pueden obtener resultados satisfactorios simplemente configurando estos filtros en valores predeterminados (por ejemplo, 50%). La configuración automática de estos filtros podría mejorarse (o retocarse) aún más mediante el análisis de los valores producidos por estos filtros, similar a lo descrito en el párrafo anterior para la detección de regiones de aire. La configuración también podría modificarse examinando la ECC resultante y buscando regiones que muestren una gran variación a lo largo del ciclo cardíaco.
Los valores correctos para estos filtros, determinados cuando se pre procesa el estudio, simplemente se almacenan en la base de datos junto con el resto de la información de estudio, lo que permite que el software del cliente los establezca como valores predeterminados cuando se abre el estudio por primera vez.
VISUALIZACIÓN
Cuantificación y visualización de hito temporal
Es útil poder identificar puntos de referencia (es decir, puntos, líneas, planos, áreas, volúmenes) en el cuerpo y específicamente en el corazón. Varios puntos de referencia o hitos son de naturaleza dinámica (por ejemplo, el plano de la válvula mitral) y, por tanto, es importante seguir su movimiento en el tiempo:
Puntos: rastrear la ruta 3-D (que es una línea) a lo largo del tiempo.
Líneas: rastrear la ruta 3-D de 2 puntos finales a lo largo del tiempo.
Planos: rastrear un punto en un plano y el vector normal del plano a lo largo del tiempo.
Áreas: rastrear el contorno de dilatación, el centroide del contorno y el vector normal del contorno a lo largo del tiempo.
Volúmenes: discretizar la superficie del volumen y rastrear cada punto discretizado a lo largo del tiempo.
Hay dos actos para la cuantificación y visualización de hitos temporales:
1) Detección: El primer paso es identificar los puntos de referencia o hitos a lo largo del tiempo. Esto se puede hacer de forma manual o automática.
Detección manual: El usuario puede indicar la posición y orientación de cada punto de referencia. Un procedimiento para hacer esto podría ser navegar por la imagen usando panorámica y rotación para que el centro de la imagen esté en la ubicación deseada del punto de referencia. La ubicación del punto de referencia puede ser diferente en diferentes momentos y se interpolará para momentos en los que el usuario no lo haya configurado explícitamente. Se indica al usuario si se interpola un punto de referencia.
2) Visualización: Dependiendo del tipo de punto de referencia se utiliza un tipo diferente de procedimiento para visualizar los datos. Por ejemplo, si un contorno no se mueve ni cambia su vector normal con el tiempo (es decir, simplemente se dilata), tiene sentido que el plano de visión del usuario no cambie y siempre esté alineado con el contorno. Si este contorno se mueve, podemos imaginarnos siguiendo el plano de manera que la vista siempre esté alineada con el plano para cada punto de tiempo. El plano de visión puede ser desde una perspectiva lagrangiana o desde una perspectiva euleriana. Para volúmenes, una perspectiva euleriana es más apropiada donde la superficie de un volumen se dilata y esto se puede visualizar con una cámara fija en el espacio (el usuario puede cambiar la ubicación de la cámara según sea necesario).
Vistas cardíacas: el vértice del ventrículo izquierdo, el vértice del ventrículo derecho, la válvula mitral, la válvula tricúspide, la válvula aórtica y la válvula pulmonar se pueden utilizar para crear vistas de dos, tres, cuatro cámaras y vistas de eje corto de los ventrículos izquierdo y derecho una vez que se han detectado los puntos de referencia. Las orientaciones de estas vistas se especifican en la Guía de RM cardíaca de la Clínica Mayo. Se puede calcular una orientación y un nivel de zoom para cada vista a partir de las posiciones de los puntos de referencia. Si la posición del punto de referencia cambia en el tiempo, la vista cambiará en consecuencia.
Puntos de referencia o hitos de ejemplo para cada vista:
Dos cámaras izquierdas: válvula aórtica, válvula mitral, válvula tricúspide, vértice del ventrículo izquierdo
Tres cámaras izquierdas: válvula aórtica, válvula mitral, vértice del ventrículo izquierdo
Cuatro cámaras izquierdas: válvula tricúspide, válvula mitral, vértice del ventrículo izquierdo
Eje corto izquierdo: válvula mitral, ápex del ventrículo izquierdo
Dos cámaras derechas: válvula pulmonar, válvula tricúspide, válvula mitral, vértice del ventrículo derecho
Tres cámaras derechas: válvula pulmonar, válvula tricúspide, vértice del ventrículo derecho
Cuatro cámaras derechas: válvula tricúspide, válvula mitral, vértice del ventrículo derecho
Eje corto derecho: válvula tricúspide, ápex del ventrículo derecho
Vistas interactivas basadas en hito
Una vez que se han colocado ciertos puntos de referencia (por ejemplo, válvula aórtica, válvula mitral, ápice del ventrículo izquierdo, músculo papilar anterior, músculo papilar posterior, válvula pulmonar, válvula tricúspide, ápice del ventrículo derecho, LPA, RPA, SVC, IVC, aorta descendente), se pueden crear vistas automáticas para mostrar la anatomía de interés. Los expertos clínicos están acostumbrados a ver un determinado punto de referencia con 3 vistas perpendiculares o, en el caso del corazón, utilizando una vista de 4 cámaras o una vista de 2 o 3 cámaras del ventrículo izquierdo o derecho. Al actualizar la ubicación de solo 1 punto de referencia o hito para uno de los puntos de tiempo, todas las vistas se actualizan en consecuencia, de modo que las vistas sean siempre perpendiculares o las vistas de 2, 3 y 4 cámaras permanezcan intactas. Una vez que se han colocado los puntos de referencia y las vistas se generan automáticamente, estas vistas se pueden guardar en la sección de informes del software y exportarse en cualquier formato (es decir, una imagen), incluida una película cinematográfica (es decir, varias imágenes a lo largo del tiempo). Creación de malla 4-D a partir de contornos cerrados
Una vez que se han colocado los contornos a lo largo del eje corto (posiblemente curvado) para cada punto de tiempo, la malla se genera de forma independiente para cada punto de tiempo. Esto se hace rotando cada contorno en la pila de eje corto para minimizar la torsión y luego generando una ranura cúbica abierta que conecta el primer punto en cada contorno, una segunda ranura que conecta el segundo punto, y así sucesivamente para cada punto en el contorno (el contorno de cada corte tiene el mismo número de puntos). El resultado de este proceso es una cuadrícula cilíndrica de puntos que utilizamos como vértices de la malla.
El proceso de minimizar la torsión se realiza calculando una spline cúbica abierta de Hermite desde el centroide de un contorno hasta el centroide del contorno superior, y luego ejecutando esta spline desde cada punto del contorno inferior hasta que interseca el plano en el que se encuentra el contorno superior. en. El sistema calcula este punto de intersección y luego determina cuál de estos puntos de intersección se encuentra más cerca de un punto de contorno real en el contorno superior. Luego se gira el contorno de manera que estos dos puntos se encuentren en la misma ranura del eje longitudinal.
La implementación actual funciona razonablemente bien con ejes rectos y curvos cuando los contornos son razonablemente circulares y la diferencia espacial entre los contornos vecinos es mínima. Sin embargo, en el caso del ventrículo derecho, donde los contornos no son circulares, la implementación actual introduce a veces una torsión excesiva. Para minimizar esto, debemos deshacernos del enfoque spline de eje largo y cambiar a uno donde el número de triángulos entre dos cortes cualesquiera pueda diferir. Hacer esto minimiza la torsión más local, lo que dará como resultado una malla más suave en general.
Herramienta de ajuste al flujo
Observar o medir con precisión el flujo sanguíneo en un escaneado de flujo 4-D requiere que el usuario alinee una reconstrucción multiplanar (multiplanar reconstruction, MPR)de modo que quede perpendicular a la dirección del flujo. Esto describe un procedimiento para crear una herramienta que permite al usuario establecer la orientación correcta de la MPR automáticamente.
Para alinear una MPR, el usuario primero activa la herramienta y luego hace clic en una región central del flujo sanguíneo en cuestión. Luego, los puntos de clic sirven como centro de rotación cuando la MPR está alineada, moviendo el punto de clic al centro de la MPR resultante. La alineación se realiza promediando el flujo sanguíneo en una pequeña región alrededor del punto de clic. Para hacer esto con precisión, la medición se realiza utilizando el punto de tiempo correspondiente al flujo sanguíneo máximo, independientemente del punto de tiempo que el usuario esté viendo actualmente mientras usa la herramienta. Esto generalmente implica realizar la medición en el pico de sístole.
Si bien el usuario puede ajustar el punto de tiempo para la sístole máxima, el software de ejecución primero determina automáticamente este punto durante el pre procesamiento del conjunto de datos, y este valor automático se utiliza como valor predeterminado cuando el usuario abre el estudio por primera vez. Se ha desarrollado un filtro (descrito en otra parte) para determinar automáticamente regiones de flujo sanguíneo dentro del volumen escaneado. Luego se determina el pico de sístole examinando la dependencia del tiempo del flujo general dentro de la región filtrada o de máscara que se determina que corresponde a la sangre.
Una vez que se ha determinado con precisión la dirección del flujo, es sencillo ajustar la orientación de la MPR para que esté en un plano perpendicular al flujo.
CUANTIFICACIÓN
Cuantificación automática del flujo sanguíneo
El flujo sanguíneo en una cámara y/o vaso se puede cuantificar automáticamente aislando primero la acumulación de sangre -blood pool- (consulte los procedimientos de segmentación descritos en este documento) y colocando un plano en un punto de referencia (que se puede definir usando los procedimientos anteriores) que sea aproximadamente perpendicular al flujo en la cámara/vaso (es decir, la normal del plano está alineada con el flujo). Una vez logrados estos 2 actos, la intersección entre el plano y la acumulación de sangre crea un contorno. Todos los vóxeles dentro del contorno están marcados. Lo siguiente es sumar el producto escalar del vector normal del plano con el vector de velocidad de ese vóxel (además de normalizar por el área del vóxel) para cada vóxel para obtener el flujo total. El flujo en ese contorno se puede mostrar automáticamente en la pantalla o en un informe que eventualmente podría exportarse.
Permitir que un usuario seleccione una posición en una imagen tiene muchas aplicaciones importantes. Al realizar mediciones, es posible que un usuario desee medir la distancia de un punto a otro. En una aplicación que utiliza MPRs de un volumen de datos, los puntos de una imagen representan ubicaciones en el espacio 3D. Estos puntos 3D son fáciles de calcular a partir de los metadatos asociados con la imagen. En una aplicación que utiliza renderizado de volumen, permitir al usuario seleccionar un punto en el espacio 3D es más difícil ya que cada píxel podría estar a una profundidad diferente.
En la típica proyección de rayo (raycasting) de volumen de adelante hacia atrás con una función de composición alfa creciente que termina una vez que alfa alcanza 1,0, se puede determinar la profundidad del píxel haciendo un seguimiento de dónde termina el rayo. Cuando se proyecta el rayo de atrás hacia adelante, no se produce una terminación temprana del rayo. El color resultante simplemente se actualiza según la función de composición. Normalmente, la función de composición hará que el aire sea transparente y, como tal, el color dejará de cambiar cuando el rayo salga del material más cercano al ojo. Al realizar un seguimiento de cuándo dejó de cambiar el color, esta profundidad de cada píxel se puede utilizar para transformar la coordenada 2D seleccionada por el usuario nuevamente en una ubicación 3D en el espacio. Esta selección de ubicación tridimensional se puede utilizar para seleccionar un vaso sanguíneo y luego cuantificar automáticamente el flujo.
Detección de derivación automática
En lugar de intentar encontrar una ubicación exacta para una derivación, la primera operación sería identificar si existe una derivación. Un procedimiento sencillo para identificar si hay una derivación es medir el flujo de corazón izquierdo (Qs) y el flujo de corazón derecho (Qp). Qp y Qs se pueden medir manualmente (por ejemplo, colocando un contorno) o automáticamente si se han completado los puntos de referencia y la segmentación de la acumulación de sangre. Si estos números no coinciden dentro de un cierto umbral, se puede marcar que la exploración tiene potencialmente una derivación.
Estas mediciones podrían realizarse automáticamente utilizando la siguiente técnica:
i) La medición automática del gasto cardíaco (Qs) se describe en otra parte, al igual que la producción de máscaras para el flujo aórtico y pulmonar junto con estimaciones automáticas de la ubicación de las válvulas aórtica y pulmonar.
ii) Una vez que se han identificado las regiones valvulares, es una tarea sencilla tomarlas y las regiones de flujo pulmonar ya determinadas, moverse ligeramente aguas abajo de la válvula y producir contornos de medición de flujo de una manera similar a lo que se ha descrito para el gasto cardíaco. Una vez que se han identificado los contornos adecuados para medir el flujo pulmonar, se pueden utilizar los algoritmos de medición de flujo existentes para determinar la salida del ventrículo derecho.
iii) Usar la medición de flujo automática para indicar la probabilidad de que exista una derivación.
Detección automática de pico y final de sístole y diástole
Gran parte del procesamiento automático depende de la capacidad de identificar primero los puntos de tiempo correspondientes a los principales hitos temporales del ciclo cardíaco: pico y final de sístole y diástole.
Como se describe en otra parte, podemos utilizar una técnica de análisis de Fourier en las imágenes de velocidad para identificar regiones de flujo sanguíneo dentro del corazón junto con las principales arterias y venas alrededor del corazón. Una vez que se han identificado estas regiones principales de flujo sanguíneo, encontramos el flujo sanguíneo total sobre los vóxeles identificados en cada momento (normalmente 20 puntos de tiempo). Luego, el sistema puede analizar la función del tiempo resultante para determinar los puntos de referencia en el ciclo cardíaco. Al momento con mayor flujo se le asigna primero el punto de referencia de sístole máxima. A partir de ahí se analiza la función en ambos sentidos en el tiempo para determinar los puntos donde el flujo tiende a estabilizarse. El punto antes del pico de la sístole donde el flujo total se estabiliza (el punto justo antes de que comience a aumentar rápidamente) corresponde al final de la diástole. Después del pico de sístole, el flujo total cae rápidamente hasta que se nivela, lo que corresponde al final de la sístole. El pico de diástole no suele ser un punto bien definido, por lo que colocamos este punto de referencia temporal en el punto medio entre el final de la sístole y el final de la diástole.
Gasto cardíaco automática y medidas volumétricas
La medición automática del gasto cardíaco se realiza mediante el siguiente procedimiento:
i) La relación entre los principales componentes de la transformada discreta de Fourier (discrete Fourier transform, DFT) de las imágenes de velocidad, junto con el punto de referencia de la sístole máxima ya determinado (descrito en otra parte) se utilizan para identificar las principales regiones del flujo arterial de los ventrículos izquierdo y derecho.
ii) Se utiliza una variedad de filtros de continuidad de flujo, uno tras otro, para separar la región de flujo arterial en dos partes, flujo aórtico y pulmonar. El punto de la máscara de flujo arterial inicial con mayor velocidad proporciona un punto confiable que se sabe que está en la aorta o en la arteria pulmonar. La separación de las dos regiones de flujo se puede determinar, por ejemplo, examinando el tamaño de la región dentro del filtro resultante que puede inundarse comenzando en el punto de flujo máximo. Una vez identificada la primera pieza, la segunda pieza puede identificarse, por ejemplo, inundando desde el punto de flujo máximo en las regiones restantes.
iii) Una vez que se han identificado dos regiones, una correspondiente al flujo aórtico y otra al flujo pulmonar, se puede permitir que las dos regiones vuelvan a crecer en una cantidad limitada (asignando píxeles individuales solo a una máscara u otra) y con la máscara de flujo arterial original que proporciona límites absolutos a la cantidad de crecimiento. Permitir al menos una pequeña dilatación de las máscaras también puede ser muy importante ya que las operaciones del proceso anteriores pueden haber dejado pequeños agujeros en las regiones resultantes que tenderían a dificultar los siguientes pasos del procedimiento.
iv) Las dos regiones de flujo pueden identificarse como flujo aórtico y pulmonar en función de su relación espacial entre sí y de su forma y orientación esperadas en el espacio, muy diferentes. Una vez hecho esto, la máscara de flujo arterial original se divide esencialmente en dos regiones, una denominada flujo aórtico y la otra denominada flujo pulmonar.
v) Como la aorta es esencialmente un tubo continuo, el recorrido de la aorta se puede trazar desde un punto inicial dentro de la arteria hasta llegar a los dos extremos. En cada punto, la dirección principal del flujo sístole máximo se puede determinar promediando una pequeña región alrededor del punto. Luego se pueden proyectar ortogonales a la dirección del flujo desde el punto inicial a intervalos angulares regulares para determinar el límite con la región aórtica enmascarada, determinando así un contorno aproximadamente circular alrededor del punto inicial.
vi) Una vez determinado un contorno como polígono en el plano ortogonal a la dirección principal del flujo para algún punto de partida. El punto inicial se vuelve a centrar en el polígono. En este punto se puede dar un pequeño paso (por ejemplo, un milímetro) desde el punto central en la dirección del flujo positivo o negativo, dependiendo de en qué dirección desde el punto inicial estemos trazando, y luego repetir el proceso. Esto continúa hasta que salimos de la máscara en cada extremo.
vii) Una vez que se han producido los contornos a intervalos regulares a lo largo de la aorta, produciendo esencialmente una malla, se refinan en cada momento individual usando las imágenes de anatomía (posible si se trata de un conjunto de datos mejorado de flujo sanguíneo) o usando la velocidad directa para los puntos de tiempo de sístole e interpolación. Un posible enfoque es utilizar un algoritmo de serpiente para identificar con precisión el límite deseado para cada contorno en cada momento.
viii) Una vez determinados los contornos refinados, se miden los diámetros mayor y menor de cada contorno, siendo el diámetro mayor el diámetro mayor y el diámetro menor el diámetro mayor ortogonal al diámetro mayor.
viii) La siguiente tarea es identificar buenos contornos en la región principal de la aorta ascendente entre la válvula aórtica y las bifurcaciones que ocurren en la parte superior de la aorta, ya que esta es la región que debe usarse al medir el gasto cardíaco. Esto se puede hacer en varios actos. En primer lugar, las regiones de la aorta ascendente se separan fácilmente de las regiones descendentes mediante la dirección del flujo. Luego, los contornos restantes se pueden calificar usando una combinación de la continuidad y variabilidad del área del contorno y los diámetros (mayor y menor) tanto espacialmente (a lo largo de la aorta) como temporalmente en un punto de la aorta. Las puntuaciones se pueden promediar a lo largo de la aorta para buscar regiones con buena puntuación en lugar de simplemente identificar contornos individuales con puntuaciones altas. Usando este procedimiento, se pueden eliminar regiones cercanas a las bifurcaciones en la parte superior de la aorta y también regiones que podrían existir cerca de la válvula aórtica y hacia el ventrículo izquierdo, ya que estas regiones, por su naturaleza, obtendrán una mala puntuación.
ix) Una vez que se han identificado buenas regiones de la aorta ascendente, se pueden seleccionar los contornos individuales con la puntuación más alta para la medición del gasto cardíaco real. Si es posible, la medición se realiza en múltiples puntos a lo largo de la aorta ascendente, lo que mejora el resultado mediante el promedio y proporciona una determinación automática de la calidad de la medición mediante el examen de la variabilidad (proporcionando así también estimaciones de la incertidumbre de la medición). Además, examinar el resultado de múltiples mediciones del flujo a lo largo de la aorta ascendente permite juzgar la calidad de la corrección de la velocidad por corrientes parásitas que se está aplicando actualmente.
x) Una vez seleccionados los contornos ideales a lo largo de la aorta ascendente, el gasto cardíaco se determina mediante las técnicas habituales de medición del flujo.
Medición volumétrica 4-D
Para calcular el volumen de una región en particular, hemos desarrollado tres opciones dentro de la interfaz en la nube de Arterys.
Opción 1: Eje Fijo
Dos puntos en el espacio tridimensional definen el eje principal de un volumen de interés. Una línea recta conecta estos 2 puntos (es decir, eje fijo). Luego, el eje se divide en puntos discretos (por ejemplo, 2 ~ 40) que definen las ubicaciones donde se colocará un corte. Los cortes se alinean ortogonalmente al eje de manera que no se crucen. No es necesario que los cortes estén espaciados uniformemente. Se representa una MPR en todas las ubicaciones del corte para permitir al usuario ver cómo se ve la imagen médica en esa ubicación del corte. Luego, de forma manual o automática, se crea un contorno cerrado en cada sector para definir el límite del volumen en esa ubicación del sector. Puede haber múltiples contornos cerrados en cada ubicación de corte. También podría no haber ningún contorno en uno o varios cortes. En el caso de estudios dimensionales 4-D o superiores (es decir, estudios que muestran cambios de volumen, o dicho diferente, múltiples fotogramas por corte), puede haber contornos separados por fotograma. Una vez que se han colocado todos los contornos para todos los fotogramas y cortes, se crea una superficie tridimensional que conecta los contornos de todos los cortes para un fotograma en particular. La forma en que se crea la superficie 3D a partir de un conjunto de contornos cerrados se explica anteriormente en "Creación de malla 4-D a partir de contornos cerrados". Si hay un volumen dimensional 4-D o superior, se puede calcular un cambio en el volumen calculando el volumen de cada cuadro y restándolo con otro cuadro. Esto es especialmente importante cuando se intenta cuantificar la función ventricular, que luego proporciona volúmenes sistólicos y fracciones de eyección.
Opción 2: Eje recto móvil
Este procedimiento es similar a la Opción 1, excepto que en el caso de un volumen 4-D, los puntos de referencia o puntos que definen los dos puntos finales del eje pueden moverse sobre cada cuadro (por ejemplo, punto de tiempo). Esto hace que el volumen se mueva potencialmente a ubicaciones en el espacio 3D sin cambiar el volumen.
Opción 3: Eje Curvo Fijo.
Este procedimiento es similar a la Opción 1, excepto que la línea que conecta los 2 puntos finales no tiene que ser recta. Esta línea puede ser curva o tener múltiples tramos rectos y curvos. Esto se maneja en el sistema con una spline que conecta puntos/ubicaciones entre 2 puntos finales. Estos puntos/ubicaciones pueden estar en cualquier lugar y no necesariamente siempre entre los 2 puntos finales.
Opción 4: Eje curvo móvil
Este procedimiento es similar a la Opción 2, excepto que en el caso de un volumen 4-D, los puntos de referencia o puntos que definen los dos puntos finales del eje curvo pueden moverse sobre cada cuadro (por ejemplo, punto de tiempo). Esto hace que el volumen se mueva potencialmente a ubicaciones en el espacio 3D sin cambiar el volumen.
En todas las opciones anteriores, podría haber múltiples ejes. Por ejemplo, podría haber un eje en forma de "Y" que se divida en 2 a partir de 1. También existe la opción de tener ejes rectos y curvos que se dividen y se unen para crear el volumen. El objetivo de esto sería tener en cuenta formas más complejas que todavía tienen un eje principal (es decir, una línea central).
En todas las opciones anteriores, también existe la opción de mostrar cómo el volumen 3-D se cruza con una MPR. La intersección debe ser una colección de uno o más contornos cerrados. Estos contornos cerrados se pueden representar en la MPR. Además, estos contornos cerrados se pueden editar moviendo el contorno en la nueva vista (no ortogonal). Los contornos de intersección se pueden calcular tanto en el cliente como en el servidor, o pueden adaptarse según los recursos locales. Para imágenes cardíacas, las vistas no ortogonales comunes son las de 2, 3 y 4 cámaras. Los contornos se pueden editar en estas vistas permitiendo que la edición solo se realice en una dirección determinada (es decir, a lo largo del plano de corte).
Mediciones fuera de plano y modo de seguimiento
Las mediciones en un sistema cardíaco a partir de datos volumétricos de resonancia magnética tienen varias complejidades. Por ejemplo, la forma, posición, orientación y velocidad del plano valvular pueden cambiar significativamente durante un ciclo cardíaco. Resolvemos esto usando contornos 2D que se mueven a través del espacio 3D. Ya sea manual o automáticamente, los contornos se colocan en el borde de la abertura de la válvula en el plano más perpendicular a la dirección del flujo. Se realiza un seguimiento de la posición y orientación del plano valvular para cada fase del ciclo cardíaco. La evaluación del flujo se realiza mediante la integración de procedimientos finitos estándar; sin embargo, en el caso de que el plano de la válvula se esté moviendo, la velocidad lineal y angular del plano de la válvula se puede incluir en el cálculo del flujo para esa fase. Durante la visualización, al pasar por fases, la posición y orientación de la MPR pueden seguir el plano de la válvula. Si se visualiza una medición cuando la MPR actual está fuera del plano, el contorno se vuelve semitransparente.
SEGMENTACIÓN
Segmentación de la acumulación de sangre (blood pool) impulsada por la ecuación de continuidad
Una vez más, se puede utilizar la conservación de la masa (es decir, la continuidad) con el supuesto de incompresibilidad para demostrar que la divergencia debe ser cero en todas partes de la acumulación de sangre. Al calcular la divergencia en todas partes, el sistema puede definir la extensión de la acumulación de sangre mediante un valor umbral de divergencia. La divergencia fuera de la acumulación de sangre será mayor (es decir, aire en los pulmones) o la velocidad será baja (es decir, señal de velocidad en tejido estático), lo que ayuda a identificar el límite del volumen. No es necesario que el mapa de divergencia sea la única entrada en un algoritmo de segmentación; en cambio, podría agregarse a otras entradas y ponderarse adecuadamente.
Detección automática de punto de referencia
La forma típica de crear un algoritmo de detección automática de puntos de referencia o hitos es buscar ciertas formas en imágenes y medir distancias y ángulos entre estas formas. Si las medidas se encuentran dentro de una determinada banda, se clasifican. Se pueden agregar varias otras entradas fisiológicas al algoritmo. Por ejemplo, localizar un volumen de líquido que aumenta y disminuye sustancialmente con cada latido del corazón (probablemente sea un ventrículo). Una vez que se encuentra un ventrículo, la entrada y salida de la válvula se pueden encontrar siguiendo las líneas de corriente. Una vez que se encuentra una válvula, es más fácil encontrar las válvulas restantes porque generalmente siempre están a cierta distancia y ángulo entre sí.
El algoritmo que se selecciona para encontrar los puntos de referencia puede ser del tipo aprendizaje automático. Dado que Arterys recopilará constantemente datos que han sido validados con la colocación correcta de puntos de referencia por parte de un médico, estos datos deben usarse como un conjunto de entrenamiento (por ejemplo, agregación estadística de datos). Cada conjunto de datos que deba analizarse se puede registrar conjuntamente con un "atlas" creado con los datos del conjunto de entrenamiento. Una vez que se recopila una cantidad suficiente de conjuntos de datos, se pueden usar parámetros de entrada adicionales, como el tipo de enfermedad (es decir, saludable, tetralogía de Fallot, etc.) para agrupar los conjuntos de datos antes de analizarlos. Cada contenedor podría tener puntos de referencia y medidas ligeramente diferentes según el tipo de enfermedad y la patología esperada. Si se sabe que un conjunto de datos es un paciente que tiene un solo ventrículo, el algoritmo de detección automática de puntos de referencia debe ajustarse a esto, ya que nunca encontrará 4 válvulas.
En particular, los puntos de referencia de las válvulas aórtica y pulmonar se pueden determinar mediante el siguiente proceso:
i) Identificar las regiones correspondientes al flujo arterial del ventrículo izquierdo y derecho. Se han desarrollado filtros (descritos en otra parte) que pueden hacer esto con alta confiabilidad.
ii) Separar la región de flujo arterial en dos regiones, una correspondiente a la aorta y otra a la arteria pulmonar. Este proceso se describe en detalle en Gasto cardíaco.
iii) Una vez determinada una región correspondiente a cualquiera de los flujos del ventrículo izquierdo o derecho, la otra región se determina restando de la región inicial correspondiente a ambos flujos. Luego, las regiones se pueden identificar fácilmente como flujo del ventrículo izquierdo o flujo del ventrículo derecho según sus dimensiones físicas y orientaciones en el espacio (también descritas en el gasto cardíaco).
iv) Una vez identificadas las dos regiones de flujo, se pueden determinar aproximaciones iniciales para la ubicación de las válvulas aórtica y pulmonar rastreando cuidadosamente el flujo masivo hasta su origen aparente.
v) Una vez que se producen estimaciones iniciales confiables para la ubicación de las dos válvulas, se pueden usar otras técnicas para refinar la ubicación de la válvula. Por ejemplo, se podría examinar la aceleración y la intensidad del flujo sanguíneo en la región que rodea la estimación inicial para refinar la ubicación de las válvulas.
Segmentación interactiva de volumen 4-D
La segmentación de los ventrículos a partir de una exploración cardíaca es fundamental para determinar la función ventricular. La técnica de función ventricular automática puede implicar:
- una entrada de dos o más puntos que representan puntos de control de una spline;
- los puntos finales de la spline denotan el vértice del ventrículo y la válvula de salida (pulmonar o aórtica);
- el uso de estos puntos genera MPRs con normales al plano establecidas en la tangente de la curva a intervalos regulares a lo largo de la curva spline;
- en cada MPR se aplica un modelo de contorno activo para encontrar el límite (epicardio o endocardio) del ventrículo; y
- generar una malla 3-D utilizando los puntos de cada uno de estos contornos.
Los modelos de contorno activos están sujetos a la inestabilidad debido a las fuerzas que actúan sobre ellos. Para reducir esta inestabilidad, en lugar de simplemente generar los contornos de manera que estén espaciados en el espacio de salida deseado (distancia entre contornos), el sistema genera muchos contornos espaciados muy estrechamente. Además, si los datos de entrada tienen datos temporales, se generan contornos en la misma ubicación utilizando datos de puntos de tiempo adyacentes. Luego se mide la forma y la calidad del contorno comparándolas con los contornos típicos de un ventrículo. Si se considera que un contorno tiene la calidad suficiente, se incluye para generar un resultado final. Los resultados finales se generan promediando los contornos incluidos que están cerca de la posición y el tiempo a lo largo de la curva de entrada. Con una malla construida tanto al final de la sístole como al final de la diástole, la diferencia de volumen representa el gasto cardíaco y la función ventricular.
En una implementación de ejemplo, el sistema y el software Arterys proporcionarían una segmentación de volumen 4-D con un solo clic. Esto permitiría al usuario hacer clic en áreas de interés (por ejemplo, acumulación de sangre, miocardio, hueso, etc.) mientras navega libremente (es decir, rotando, haciendo panorámica, haciendo zoom, desplazándose por cortes, desplazándose en el tiempo) por el volumen 3D. Dado que es difícil construir y ser preciso un algoritmo de segmentación de volumen 3-D completo, una segunda opción es mostrar 3 vistas ortogonales al usuario mientras éste dibuja el límite del área que desea segmentar. Para el corazón, la vista que se muestra puede ser una vista de 2, 3 y 4 cámaras del corazón, además de una vista de eje corto. El usuario sólo necesita crear 2 contornos ortogonales en el eje largo, y luego el software puede crear de forma automática o autónoma una superficie 3-D basada en la interpolación de los dos contornos. La superficie tridimensional se puede mostrar al usuario en un eje corto para una modificación rápida. Además de mostrar las imágenes anatómicas, las imágenes de la velocidad de la sangre (con o sin vectores) se pueden superponer a las imágenes anatómicas para aclarar aún más dónde está el límite de la acumulación de sangre durante el proceso interactivo de segmentación del volumen tridimensional.
Llenado adaptable de inundación
El sistema utiliza múltiples tipos de inundaciones que pueden distinguirse como 2-D vs. 3-D, por la conectividad utilizada durante la inundación (conectividad de 6, 18 o 26 vías) y el radio restringido frente a una inundación limitada por un número máximo de pasos. En todos los casos, la inundación funciona moviéndose hacia afuera desde un punto inicial específico e incluyendo un píxel en el resultado de la inundación si 1) está conectado al resto de la inundación (usando cualquier conectividad especificada), 2) tiene una intensidad dentro de un umbral especificado del píxel en el punto inicial, y 3) el píxel está dentro del radio especificado del número máximo de pasos del punto inicial. El resultado de la inundación es una máscara conectada bidimensional o tridimensional. El algoritmo de inundación se utiliza en sólidos en forma de inundación 3D para marcar tejido estático/no estático, en volúmenes donde se puede utilizar una inundación 2D para generar un contorno en la pila de eje corto y en la cuantificación del flujo, donde se puede utilizar una inundación 2-D para inundar un vaso y determinar el flujo contenido dentro de la inundación.
Para generar un contorno a partir de una inundación 2-D de radio limitado, utilizamos el hecho de que la inundación necesariamente estará conectada y que es una imagen binaria. Debido a estos hechos, podemos aplicar un algoritmo estándar de trazado de límites para generar un contorno que ignore cualquier agujero que pueda estar presente en el interior de la inundación.
A partir del contorno generado, la siguiente operación es reducir el contorno generado de potencialmente cientos de puntos a un pequeño conjunto de puntos de control que utilizará una spline cúbica cerrada para aproximarse con precisión al contorno real. Un muestreo ingenuo en el que el sistema simplemente espacia un número fijo de puntos de control igualmente espaciados alrededor del contorno no funciona tan bien como otros enfoques, ya que este enfoque frecuentemente resulta en la pérdida de características importantes en el contorno, como la porción cóncava de la inundación que rodeaba un músculo papilar. Para evitar esto, se emplea un enfoque de muestreo "inteligente" que se desarrolla en una serie de actos. Para empezar, a cada punto del contorno se le asigna una puntuación de resistencia de las esquinas que va de -1 a 1, además de asignar a cada punto un área de "influencia". Una vez hecho esto, el contorno se reduce sólo a aquellos puntos donde la resistencia de sus esquinas es máxima dentro de su área de influencia. En esta etapa también se aplican criterios adicionales, como garantizar que tengamos un espacio mínimo entre puntos y garantizar que las esquinas detectadas sean lo suficientemente fuertes. El resultado de la operación anterior es una lista de "esquinas" detectadas en la inundación. Al usarlos como puntos de control en una spline, este enfoque garantiza que la spline no pierda ninguna característica interesante en el contorno. Sin embargo, cualquier tramo largo de curvatura relativamente baja en el contorno original no se detectará como esquinas, lo que puede dar como resultado que porciones significativas del contorno resultante no tengan ningún punto de control, lo que lleva a una mala aproximación por parte de una spline en dichos segmentos. Para solucionar esto, se calcula una métrica de error para cada par de puntos de control calculando el área de un contorno cerrado formado por el segmento del contorno original que pasa por los puntos y el segmento de una spline que pasa por esos puntos. Si el error está por encima de cierta tolerancia fija, se agrega otro punto de control en el punto medio del segmento del contorno original. Esta operación se repite hasta que cada segmento tenga un error calculado por debajo de la tolerancia requerida.
Esta herramienta de inundación a contorno se puede utilizar en al menos dos lugares de la aplicación: para inundar cortes de un ventrículo mientras se realiza una segmentación volumétrica y en la cuantificación del flujo. En el caso de la inundación de volúmenes, el contorno devuelto se dilata un 8 % para capturar más del ventrículo, ya que un relleno de inundación sin procesar a menudo se subestima simplemente debido a la diferencia en las intensidades de los píxeles cerca de la pared del corazón. Para una inundación de flujo, el resultado se dilata en un 12 % porque la herramienta de inundación funciona en la anatomía, lo que significa que la inundación no dilatada a menudo perderá el flujo cerca de la pared del vaso.
PROCESO GENERAL
Informes automatizados
De manera similar a cómo se generan los informes ecocardiográficos, se puede crear un informe automatizado basado en datos de resonancia magnética de flujo 4-D permitiendo al usuario hacer clic en el tipo de paciente que tiene. Arterys tendrá plantillas de informes únicas que son específicas para una determinada patología o tipo de usuario (es decir, paciente o médico). Todos los valores, curvas, imágenes y películas de cine de este informe se pueden completar automáticamente en la plantilla de informe. Dado que los puntos de referencia se colocan como parte del paso de pre procesamiento, toda la información importante se puede guardar automáticamente en la base de datos y exportarse a este informe.
Pruebas de integración automatizadas
Una herramienta llamada node-webkit que está diseñada para crear aplicaciones web del lado del cliente utilizando node.js para realizar pruebas de integración automatizadas. Aunque no está diseñado para este propósito, nos permite ejecutar la pila de software del cliente y del servidor dentro del mismo entorno, lo que permite un control total sobre las aplicaciones del cliente y del servidor al mismo tiempo. Utilizando una infraestructura combinada con una herramienta de prueba llamada mocha, escribimos pruebas que emulan la interacción del usuario con el cliente y al mismo tiempo confirman el procesamiento de esa interacción por parte del cliente y del servidor junto con el estado resultante de la aplicación. Este procedimiento de prueba de integración es novedoso y superior a otras herramientas que se basan principalmente en visión para este tipo de prueba de interfaz de usuario.
Renderización híbrida de cliente servidor
Descripción: algunos flujos de trabajo requieren que se representen una o varias imágenes al mismo tiempo que tienen propiedades vinculadas. En algunos casos, el paso del flujo de trabajo actual puede requerir la visualización simultánea de 20 imágenes. Si cada una de estas imágenes se recuperara con una solicitud<h>T<t>PS distinta, el rendimiento se vería muy afectado ya que existe una sobrecarga significativa al crear y enviar una solicitud. En su lugar, renderizamos todas las imágenes en una imagen grande y solo realizamos una única solicitud HTTPS para esa 'hoja de sprites'. Luego, el cliente muestra las imágenes utilizando desplazamientos de píxeles. Por ejemplo, si una vista tenía cuatro imágenes cada una de 256x256, la hoja de sprites podría ser de 256*1024 con cada una de las imágenes apiladas una encima de otra. Luego, el cliente mostraría 4 imágenes a 256 * 256 utilizando compensaciones de 0, 256, 512 y 768.
Además, todas las líneas, marcadores o planos de las imágenes se dibujan en el cliente como una superposición, y la información que le informa al cliente cómo representar la superposición proviene del servidor a través de un mensaje JSON. Esto proporciona una representación de mayor calidad de los datos superpuestos que si la superposición se renderizara en el servidor y luego se codificara como JPEG y se transmitiera.
Pruebas de estrés y resistencia global automatizadas
Para realizar pruebas de carga y pruebas de resistencia, lanzamos multitud de procesos cliente en multitud de ordenadores (que pueden estar distribuidos geográficamente) para iniciar navegadores web especializados en los que tenemos control total sobre su entorno de ejecución. Se dirigen a la aplicación y cargan el cliente como lo haría un navegador normal, luego interactuamos directamente con el estado del cliente controlando el software y haciendo que se comporte como una determinada carga de trabajo. Las métricas del cliente y del servidor se registran durante las pruebas de carga y se ejecutan durante períodos de tiempo más prolongados para realizar pruebas de resistencia.
Empujador (pusher) empuja datos desde un dispositivo médico a servidores remotos
Hemos desarrollado software para monitorear estudios activos y enviar los resultados a nuestro servicio remoto en la nube. Se monitorea una carpeta en busca de archivos generados por un escáner y, al finalizar, todos los datos relevantes se agrupan y se envían a través de una conexión segura utilizando un secreto y clave únicos por escáner para la autorización a nuestros servidores remotos en la nube. El uso de espacio en disco (por ejemplo, medios de almacenamiento no transitorios) se minimiza eliminando inmediatamente cualquier archivo intermedio.
Tras una transferencia exitosa, la integridad de los datos del contenido transferido se verifica con el contenido local reproduciendo el proceso del paquete y comparando el resultado de una función hash criptográfica. Repetir el proceso de esta manera garantiza que cualquier dato nuevo que pueda haber sido generado por un escaneo no se pierda en caso de retrasos durante el proceso de escaneo que puedan desencadenar una transferencia prematura de los datos a los servidores de Arterys.
En el caso de una transferencia fallida, debido a errores del servidor o de la red, se realizará un número configurable de intentos con un intervalo creciente de descanso entre cada intento, antes de que el empujador asuma que la transferencia fue un error. Sin embargo, después de una transferencia fallida (incluidos todos los intentos posteriores), el empujador continuará monitoreando los archivos entrantes y volverá a intentar otra transferencia más adelante.
Una vez que se ha verificado que los datos se transfirieron exitosamente, nuestro software los elimina para conservar espacio en disco en los escáneres.
Se envía un mensaje de latido desde cada software empujador que se ejecuta en cada escáner, proporcionando los datos de registro local e información detallada del estado del escáner, lo que brinda monitoreo continuo y mayor tiempo de respuesta para garantizar la funcionalidad del escáner durante los momentos críticos de escaneo.
Durante la instalación inicial, un escáner se registrará automáticamente en Arterys solicitando un secreto y una clave únicos para firmar todas las solicitudes futuras con fines de autorización. El escáner se registrará en la base de datos de nuestros sistemas, pero no se adjuntará a ninguna organización. Luego, un técnico puede conectar todos los escáneres registrados recientemente a la organización correcta a través de un portal web.
Un empujador puede actualizarse automáticamente (si está configurado) solicitando periódicamente nuevas versiones de Arterys. Si se proporciona una nueva versión, instalará una nueva copia de sí mismo y se reiniciará. Esto permite implementar actualizaciones de seguridad y funcionalidad en los escáneres sin intervención de los técnicos. Los mensajes de latido proporcionan la información necesaria para garantizar el éxito de esta operación en los servidores de Arterys. Los latidos nos permiten determinar cualquier empujador que no se haya actualizado recientemente y comunicarnos directamente con los hospitales para garantizar de manera proactiva que todo el software esté actualizado y sea seguro.
Las Figuras 3A-3B muestran un proceso de ejemplo 300.
Extractor - archivo de artefactos
El software extractor (puller) se utiliza para archivar artefactos generados en un hospital (por ejemplo, PACS). Se instala dentro de la red de un hospital y se registra automáticamente en Arterys mediante un procedimiento similar al de los empujadores. Se realiza una solicitud con cierta información de identificación y se devuelve un par de clave y secreto para firmar solicitudes futuras con fines de autenticación y autorización. Luego, un técnico conecta el extractor a una organización a través de un portal web.
También es posible descargar una versión para una organización directamente, con una clave y secreto únicos incluidos automáticamente en el proceso de instalación, por lo que no es necesario registrarse automáticamente y adjuntar el extractor una vez instalado.
La configuración de los puntos finales de artefactos se realiza en los servidores de Arterys. Se pueden configurar varias ubicaciones con nombres de host, puertos, títulos de AE y cualquier otra información requerida que el extractor necesitaría para transferirle datos. Estos puntos finales pueden nombrarse y el médico puede seleccionarlos desde la interfaz de usuario web de Arterys al elegir dónde desea que se archiven sus artefactos (informes/capturas de pantalla/videos).
El extractor monitorea los artefactos solicitando una lista de la API de Arterys a intervalos regulares y frecuentes. La lista de artefactos incluye una identificación única y toda la información de configuración para el punto final en el que se almacenará el artefacto. La identificación única se utiliza como entrada en otra solicitud de API para recuperar el artefacto de los servidores de Arterys. El artefacto se descomprime si es necesario y se transfiere utilizando la configuración y el procedimiento definidos por la configuración incluida en la solicitud de lista (por ejemplo, storescp). Una vez que se transfieren todos los datos, se realiza otra solicitud API utilizando la ID proporcionada a Arterys para marcar el artefacto como archivado y ya no aparecerá en la lista generada por la primera solicitud en el ciclo del proceso. Una vez que el artefacto se haya marcado como archivado, los servidores de Arterys notificarán al usuario que el archivo se ha completado.
El extractor envía solicitudes de latidos a Arterys y proporciona registros detallados para ayudar a validar y garantizar que todo funcione como se esperaba. El extractor también ocasionalmente, en un momento configurable (por ejemplo, una vez por hora o por día), realizará una solicitud de API a Arterys para obtener nuevas versiones del software del extractor. Si hay una nueva versión disponible, se descargará, se instalará y el extractor se reiniciará.
Solicitud de ejemplo para recuperar una lista de artefactos:
GET https://app.arterys.com/api/1/artifact?status=pending&timeout=20
[
{ "id" : "55006362619baaad4323f799", "name": "report_one.zip",
"digest": "f90sdaf9d0safd0safd09safd", "size": 3523234, "dicom_host":
"192.168.1.3"", "dicom_port": 1999, "dicom_aetitle", "aetitle for
dicom endpoint"},
{ "id": "454bf977be1cfbe146f36549", "name": "report two.zip",
"digest": "9320028003002930sass9safd", "size": 1221134, "dicom_host":
"192.168.1.3"", "dicom_port": 1999, "dicom_aetitle", "aetitle for
dicom endpoint" }
]
Las Figuras 4A-4B muestran un proceso de ejemplo 400 de monitoreo de artefactos y archivado.
Hemos desarrollado un procedimiento para entregar de forma segura información confidencial del paciente a una aplicación de cliente desde un servicio sin revelar la información confidencial al proveedor del servicio.
Los datos antes de ser enviados al proveedor de servicios se eliminan de toda la información de salud identificable del paciente, que se registra en el servicio y los datos confidenciales originales se reemplazan con un identificador de token único proporcionado por el servicio.
El cliente, al interactuar con el proveedor de servicios, identificará estos tokens y utilizará una capa de transporte independiente para reemplazar los tokens con la información confidencial de salud del paciente.
A continuación, se muestra un ejemplo de una posible implementación de dicho sistema:
Actores:
El usuario que interactúa con el software cliente (usuario)
La aplicación cliente (cliente)
El servicio que contiene la información confidencial del paciente (servicio)
El proveedor de servicios de aplicaciones.
1. El usuario indica al software un conjunto de archivos que le gustaría enviar a un proveedor de servicios de aplicaciones.
2. Para cada archivo, toda la información confidencial se recopila en formato JSON y se registra en el servicio a través de una solicitud http.
Ejemplo:
POST https://sensitive.arterys.com/register-data HTTP/1.0
{
"PatientName": "Franklin\Benjamin"
"Birthdate" : "1706-01-17"
}
returns
Location: "/4217ad2b78fff7eb9129a58b474efb3e"
3. Los datos confidenciales se reemplazan con marcadores de posición como #{PatientName} y luego los datos se cargan junto con la URL de ubicación devuelta por el servicio.
4. Cuando el cliente carga los datos del proveedor de servicios de la aplicación, las cadenas que contienen estos tokens confidenciales hacen que la aplicación del cliente solicite los datos del proveedor de servicios (ya sea individualmente o de forma masiva).
Ejemplo:
GET https://SENSITIVE.arterys.com/4217ad2b78fff7eb9129a58b474efb3e#PatientName
returns
"Franklin\Benjamin"
5. El cliente sustituye los tokens por la información confidencial.
Nota: Para la autorización, podríamos usar un sso como saml2.
Espacios de trabajo
Los espacios de trabajo son una solución a los problemas de almacenar y compartir un subconjunto del estado de la aplicación en todo el software médico.
Los espacios de trabajo contienen el estado de la aplicación de un estudio, incluido cualquier análisis, y cuando se cargan, restauran la aplicación al estado anterior. El estado de la aplicación incluye el subconjunto del estado del componente relacionado con una preocupación particular, como la revisión del estudio, incluidas las mediciones y los valores de corrección de ECC, etc.
Los espacios de trabajo se pueden cargar y actualizar constantemente mientras el usuario interactúa con el software. Los usuarios comienzan con un espacio de trabajo privado predeterminado cuando cargan un estudio por primera vez y, cuando recargan, se carga el espacio de trabajo aplicable utilizado más recientemente.
Los usuarios pueden publicar un estudio para un grupo o más usuarios, lo que también puede servir como activador para la generación de informes y notificaciones del sistema externo.
Al abrir un espacio de trabajo publicado por primera vez, se crea una copia privada del espacio de trabajo y también se carga en recargas posteriores. Los estudios publicados son inmutables y nunca pueden modificarse.
Aprendizaje automático con imagen médica
Con una interfaz en la nube, ahora es posible agregar estadísticas de múltiples fuentes para generar predicciones mediante el aprendizaje automático. Estas múltiples fuentes pueden ser los resultados generados por varias personas dentro de una organización, o incluso por varias organizaciones repartidas por todo el mundo. Las estadísticas que se pueden agregar pueden ser datos de píxeles de imágenes médicas, metadatos de imágenes médicas (por ejemplo, encabezados DICOM) y, por ejemplo, registros médicos electrónicos (electronic medical record, EMR) de pacientes. El aprendizaje se puede aplicar a nivel de usuario, a nivel de organización o incluso a nivel macro (por ejemplo, globalmente).
En el caso de intentar cuantificar automáticamente (por ejemplo, anotar, medir, segmentar) imágenes médicas, puede haber dos categorías diferentes de aprendizaje profundo, aprendizaje automático o inteligencia artificial: Para la aplicación de imágenes médicas, el aprendizaje supervisado es más apropiado porque hay datos suficientes para el aprendizaje. Para aprender de la forma más eficaz posible, la interfaz de usuario de la nube se ha adaptado para permitir a los usuarios agregar etiquetas a los datos de forma estructurada. Por ejemplo, en el caso de imágenes cardiovasculares, un usuario puede realizar varias mediciones y etiquetarlas como desee. En lugar de permitir un campo completamente definido por el usuario, existe la opción para que un usuario seleccione una etiqueta de una lista predefinida que proporciona Arterys. Al hacer esto, podemos agregar etiquetas a los datos de forma estructurada y automatizada. Los datos etiquetados actúan como conjunto de datos de entrenamiento para alimentar un algoritmo de aprendizaje automático (es decir, como un bosque aleatorio o CNN o RNN de aprendizaje profundo) de modo que el algoritmo pueda predecir un resultado basado en nuevos datos sin etiquetar. Por ejemplo, un paso opcional en el proceso de revisión del usuario es que "publique" su espacio de trabajo o estado de una manera que confirme que está satisfecho con las etiquetas que ha agregado a los datos. El mecanismo de "publicación" puede ser un icono en la interfaz de usuario en el que hacen clic para "guardar", o pueden ser los resultados que se envían al archivo (por ejemplo, a un servidor PACS de un hospital). Simplemente tiene que haber una manera de diferenciar a un usuario que crea mediciones y anotaciones ficticias con mediciones y anotaciones clínicas reales.
El beneficio de una interfaz en la nube es que cada vez que un usuario realiza alguna modificación dentro de la interfaz del sistema a la sugerencia proporcionada, esta modificación se guarda y se devuelve a los datos etiquetados del aprendizaje automático. Esto crea un ciclo de aprendizaje por refuerzo que agrega datos de entrenamiento muy valiosos. Las sugerencias proporcionadas por el algoritmo de aprendizaje automático se pueden proporcionar una vez cuando un usuario inicia sesión o en tiempo real cada vez que un usuario realiza una modificación durante su sesión. Por ejemplo, cuando un usuario identifica un vóxel en una imagen médica de anatomía, todos los vóxeles similares se pueden identificar en tiempo real en su sesión.
En el caso de intentar predecir el resultado de un tratamiento particular (y dar una medida de probabilidad resultante) o predecir qué opción de tratamiento es mejor para un paciente en particular, los datos del EMR son críticos. Tener acceso a datos de dispositivos médicos etiquetados (por ejemplo, imágenes médicas, datos genómicos, dispositivos portátiles) no es suficiente para determinar las mejores decisiones de tratamiento. Estos datos deben agregarse en todos los casos retrospectivos para ofrecer una predicción a un nuevo paciente que tenga datos de dispositivos médicos similares.
El aprendizaje automático también se puede utilizar para buscar imágenes médicas. Un usuario puede escribir en un campo de búsqueda y encontrar todas las imágenes que, por ejemplo, tengan un tipo particular de trastorno. Luego, un usuario puede verificar que todos los estudios que se le presentan tienen este trastorno y estos datos pueden luego reintroducirse en el conjunto de datos de entrenamiento.
Servicio de imágenes y vídeos
Queremos que el usuario pueda capturar imágenes y videos del estado actual de su flujo de trabajo. Estas imágenes y videos deben incluir tanto datos de imágenes generados en nuestro servidor como superposiciones representadas en el navegador del cliente. Para lograr esto, contamos con un servicio de video basado en node-webkit que nos permite ejecutar nuestra pila de software de cliente y servidor dentro del mismo entorno. Luego restauramos el estado actual del espacio de trabajo del usuario en el entorno del node-webkit y aprovechamos los mismos nodos informáticos que se asignaron para la sesión de ese usuario. Si el usuario solicita una sola imagen, el servicio simplemente toma una captura de pantalla del espacio de trabajo restaurado y se devuelve el archivo de imagen resultante. En el caso de una solicitud de video, el servicio toma una captura de pantalla para cada cuadro del flujo de trabajo actual y compila las imágenes de la captura de pantalla en un archivo de video usando un codificador de video que luego se devuelve. Las imágenes o videos devueltos pueden almacenarse en el servidor o enviarse de regreso al cliente para que los vea.
A continuación, se muestra un ejemplo de un diseño de software detallado para el servicio de imágenes y videos:
Capturas de pantalla y captura de vídeo
Requisitos
AAAAAAAAAA
* la captura de pantalla debe ser una representación de lo que el usuario ve actualmente en el área de visualización * el vídeo puede generarse a partir de una colección de fotogramas clave con parámetros intermedios interpolables * el vídeo puede ser una grabación de la interacción del usuario
* la salida debe contener todo lo que está en la ventana gráfica (imagen, superposiciones webgl, superposiciones css, ..)
* las capturas de pantalla y los fotogramas de vídeo deben ser de calidad completa.
Diseño
AAAAAAA
Dado que renderizamos todo en el cliente necesitamos un cliente para generar la imagen.
Desafortunadamente, subir un vídeo sería prohibitivo en la mayoría situaciones de red.
Por lo tanto, un servicio de captura de pantalla / vídeo se ejecutará en el clúster que utiliza tecnología de renderizado de cliente.
Expondrá una interfaz a través de http para proporcionar la funcionalidad definida en los requisitos.
El servicio pone en marcha procesos webkit nodo bajo demanda para renderizar vídeos y capturas de pantalla a medida que llegan las solicitudes.
Al recibir una solicitud para renderizar una imagen o colección de imágenes, el servicio lanzará un proceso node webkit y lo redirigirá a la URL firmada para la lista de trabajo del usuario.
A continuación, el proceso node-webkit cargará el estudio e inyectará el espacio de trabajo del usuario.
A continuación, cada fotograma se renderizará a máxima calidad.
A medida que se renderiza un fotograma, node-webkit realizará una captura de pantalla X11 y la recortará a la ventana del lienzo.
La imagen se guardará en el disco.
Una vez capturados todos los fotogramas, el servicio devolverá la captura de pantalla o, en el caso de un vídeo, se codificará y devolverá un vídeo.
Flujo de datos
AAAAAAAAAAAAAA
* el usuario inicia una solicitud de captura de pantalla o un vídeo.
* el servidor web recibe la solicitud
* se inicia el proceso node-webkit
* el proceso node-webkit abre una sesión, autenticada para cargar el estudio solicitado
* se carga el estudio solicitado
* el espacio de trabajo de la solicitud se inyecta en el estudio
* una vez finalizada la carga del espacio de trabajo (incluidas tareas de larga duración como streamlines), comienza a renderizar los fotogramas clave
* todos los fotogramas se renderizan con la máxima calidad y sin comandos de rebote de imagen
* cuando se renderiza una imagen, se ejecuta la captura de pantalla X11 (xwd) en la ventana * la imagen se recorta en la ventana gráfica y se guarda en disco.
* si se ha solicitado un vídeo, la codificación se ejecutará una vez generadas las imágenes.
* una vez generadas todas las imágenes, se envía una respuesta http con el archivo .png o .mp4
* cuando el servidor web reciba el resultado, se guardará en S3 y se enviará una referencia a la base de datos
Herramientas adicionales y optimizaciones
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
* node-webkit requiere webgl por lo que el servicio tendrá que ejecutarse en G2 instancias
* el programa 'xwd' en 'xll-apps' puede capturar ventanas
* ImageMagick 'convert' puede convertir xwd a png
* ffmpeg se puede utilizar para generar .mp4 a partir de una colección de .png
Detalles
AAAAAAAA
Capturas de pantalla
Mensaje de cliente:
ws.emit('generate-screenshot', params)
params:
{
workspace id : 'workspace-id',
id : 'app-id',
study_id : 'study-id',
upload_id : 'upload-id',
window width : 'browser window width',
window height : 'browser window height'
hostname : window.location.hostname,
port : window.location.port,
pathname : '/app/xxx'
}
Vídeo
++++
Mensaje de cliente
ws.emit('generate-screenshot', params)
params:
{
// las mismas que captura de pantalla más
render_frames : [
{
orientation : [1,0,0,0,1,0,0,0,1],
position : [0,0,0],
timepoint : 1
},
{
orientation : [0,1,0,1,0,0,0,0,1],
position : [0,0,0],
timepoint : 2
}
],
betweens : optional_number_of_frames_to_interpolate_between_frames
Controlador de servidor web
El controlador de mensajes para 'generar captura de pantalla' (generate-screenshot) adjunta el espacio de trabajo actual a los argumentos que se envían a los servicios del webkit.
Luego, el módulo webkit-client se utiliza para enviar una solicitud a uno de los servicios de webkit.
Una vez recibida la respuesta se inserta un registro en la base de datos y se almacena la imagen o video.
Cliente Webkit
El módulo cliente webkit (webkit-client) es responsable de enrutar una solicitud de captura de pantalla a un nodo que pueda manejarla.
El cliente webkit se suscribe a los mensajes de Redis que publican los nodos webkit actualmente en ejecución. Estos mensajes incluyen las instancias existentes de node-webkit que se ejecutan con el ID de aplicación con el que se ejecutan.
Cuando se recibe una solicitud, el cliente webkit intenta encontrar un nodo que ya tenga nodo-webkit ejecutándose con el ID de aplicación solicitado.
Alternativamente, si aún no se ha creado una sesión, elige el nodo con el menor número de sesiones en ejecución. Una vez que se ha identificado el nodo, envía el mensaje a través de HTTPS a ese host.
Los argumentos se envían en el cuerpo como JSON en un POST a la ruta '/webkit/execute'.
Cuando se devuelve el resultado, se invoca una devolución de llamada con el binario y un blob JSON que contiene el tipo (imagen/png o vídeo/mp4), junto con otra información útil recopilada (por ejemplo, información de tiempo, tamaño).
function execute (args, cb) {
https.request('POST', '/webkit/execute',JSON.stringify(args),
function(res) {
cb(null, {
binary: res,
json: { type: headers ['content type'], info: {
generation_start_time: <fecha>, generation_end_time: <datos>}}
});
});
}
Servicio Webkit
El servicio webkit es un microservicio que expone una interfaz HTTPS para generar capturas de pantalla y videos. El servicio webkit escucha solo solicitudes POST en '/webkit/execute'.
Al recibir una POST en '/webkit/execute', crea un contexto de webkit y pone en cola una solicitud de captura de pantalla o vídeo.
Este módulo también se encarga de autorizar la solicitud que se enviará desde node-webkit al servidor web agregando un token de autenticación asociado con el usuario especial 'webkit-screenshot'.
Contexto de Webkit
El módulo webkit-context es responsable de administrar el proceso node-webkit que se ejecutará para generar una captura de pantalla o un video.
Tras la creación, un contexto webkit crea un directorio de trabajo para almacenar resultados intermedios.
A continuación, configura node-webkit copiando un archivo simple 'index.html' y 'package.json' en el directorio de trabajo, y el 'args.json' que contiene los argumentos pasados al contexto para representar la captura de pantalla/video. Luego se inicia node-webkit y se ejecuta el proceso de generación de una captura de pantalla.
Cuando node-webkit sale, webkit-context buscará la captura de pantalla o el archivo de video apropiado para responder.
Solo se puede ejecutar una captura de pantalla por ID de aplicación a la vez.
Un contexto de webkit se registra a sí mismo en redis para que un servidor web pueda enrutar solicitudes de captura de pantalla y video.
Nodo-principal
El módulo de nodo-principal es el módulo puente que se ejecuta en node-webkit.
Cuando se inicia node-webkit, espera hasta que se define la variable 'global.window' y luego lee el archivo args.json y comienza a ejecutar los pasos para generar una captura de pantalla.
Estos argumentos denotan el ancho x alto para crear la ventana y hacia dónde redirigir window.location.href.
Se supone que la redirección apunta a un sitio web que configurará global.window.io, que es una variable definida por Arterys que indica la conexión websocket.
Una vez que se ha establecido la conexión websocket, invoca un comando de 'carga de estudio' (load-study) y espera a que se complete la carga de espacio de trabajo (load-workspace-complete).
Una vez que finalizan todos los comandos que pueden haber sido invocados al restaurar un espacio de trabajo, el nodo-principal comienza a capturar imágenes.
Si 'args.json' contenía el campo 'render_frames', itera a través de cada uno generando una imagen.
Las imágenes se generan invocando xwd para volcar el Xwindow.
Luego, ImageMagick convert se usa para convertir a png y recortar a '.ar-content-body-canvases'.
Si se generó más de una imagen, se invoca ffmpeg para codificar la colección de imágenes en un video codificado en h.264.
Cuando se haya creado la captura de pantalla o el vídeo, node-webkit saldrá limpiamente.
Cualquier error hará que node-webkit salga con un código distinto de cero, lo que indicará al contexto webkit que la captura de pantalla falló.
SERVICIO PHI
La Figura 5 muestra un entorno en red para un sistema o plataforma de análisis médicos 500, según una realización ilustrada. La plataforma comprende una red de proveedor de servicios de análisis (analytics service provider ASP) 502 que comprende un sistema ASP 504 (por ejemplo, uno o más dispositivos basados en procesador) que se comunica a través de un firewall 506 con varios sistemas asociados con redes de proveedores médicos (por ejemplo, hospitales) 508 (se muestra uno). El sistema ASP 504 proporciona algunas o todas las diversas funciones analizadas anteriormente. Por ejemplo, el sistema ASP 504 puede ser similar o idéntico al sistema de análisis y procesamiento de imágenes 104 de la Figura 1, por ejemplo. El sistema ASP 504 puede implementarse usando una arquitectura de nube y, como tal, puede comprender varios dispositivos basados en procesadores distribuidos. El sistema ASP 504 puede acceder a sistemas externos a través de una o más redes de comunicaciones accesibles a través del firewall 506, por ejemplo.
La red de proveedor médico u hospitalario 508 puede incluir uno o más sistemas de información de salud protegida (protected health information, PHI) 510 (se muestra uno) acoplados operativamente a una o más redes externas (por ejemplo, Internet) a través de un firewall 518. La red de proveedores médicos 508 también puede incluir un servicio de lenguaje de marcado de afirmación de seguridad (security assertion markup language, SAML) 512 acoplado operativamente al servicio PHI 510. En al menos algunas de las implementaciones analizadas en el presente documento, el servicio SAML 512 puede considerarse parte o integrado con el sistema o servicio PHI 510.
El sistema PHI 510 puede estar acoplado operativamente a un sistema de adquisición de IRM 514 que incluye una máquina de IRM 515 (Figura 7) y un sistema informático anfitrión 517 (Figura 7). El sistema PHI 510 también puede estar acoplado comunicativamente a una base de datos 524 u otro medio de almacenamiento no transitorio legible por procesador que almacena datos de estudio médico recibidos del sistema de adquisición de IRM, entre otros datos. Los datos de estudio médico pueden incluir datos de resonancia magnética, datos de flujo 4-D o cualquier otro tipo de datos que puedan tener PHI u otra información personal o protegida. Como se muestra en la Figura 8, el sistema PHI 510 puede estar acoplado comunicativamente a un sistema de comunicación y archivo de imágenes (PACS) 525 u otro almacenamiento de destino asociado con el proveedor médico.
El sistema de adquisición de IRM 514 normalmente está ubicado en una instalación clínica, por ejemplo, un hospital o un centro de imágenes médicas dedicado. El sistema de adquisición de IRM 514 puede ser similar o idéntico al sistema de adquisición de IRM 102 de la Figura 1. Diversas técnicas y estructuras, como se explica en el presente documento, pueden permitir ventajosamente que el sistema ASP 504 esté ubicado de forma remota desde el sistema de adquisición de IRM 514. El sistema ASP 504 puede, por ejemplo, estar ubicado en otro edificio, ciudad, estado, provincia o incluso país.
El sistema ASP 504 puede incluir uno o más servidores para manejar solicitudes y respuestas entrantes, y una o más computadoras de análisis y procesamiento de imágenes o renderización. Los servidores pueden, por ejemplo, tomar la forma de uno o más ordenadores servidores, ordenadores estaciones de trabajo, superordenadores u ordenadores personales, que ejecutan software o instrucciones de servidor. La una o más computadoras de análisis y procesamiento de imágenes o de renderización pueden tomar la forma de una o más computadoras, computadoras de estaciones de trabajo, supercomputadoras o computadoras personales, que ejecutan software o instrucciones de procesamiento y/o análisis de imágenes. Una o más computadoras de procesamiento y análisis de imágenes o renderizado emplearán típicamente una, y preferiblemente múltiples, unidades de procesamiento gráfico (GPU) o núcleos de GPU.
Si bien la Figura 5 ilustra un entorno en red representativo, los entornos en red típicos pueden incluir muchos sistemas de adquisición de IRM, sistemas ASP, sistemas PHI, sistemas informáticos y/o entidades adicionales. Los conceptos que se enseñan aquí se pueden emplear de manera similar con entornos de red más poblados que el ilustrado. Por ejemplo, una única entidad ASP puede proporcionar servicios de análisis y procesamiento de imágenes a múltiples entidades de diagnóstico. Una o más de las entidades de diagnóstico pueden operar dos o más sistemas de adquisición de IRM. Por ejemplo, un gran hospital o un centro de imágenes médicas dedicado puede operar dos, tres o incluso más sistemas de adquisición de resonancia magnética en una sola instalación.
Generalmente, el sistema PHI 510 puede crear un punto final seguro para datos de estudio médico (por ejemplo, archivos DICOM). El sistema PHI 510 puede eliminar PHI de ficheros de forma automática o autónoma y cargar los datos de estudio médico de-identificados al sistema ASP 504 para su procesamiento y/o análisis. Además, como se analiza a continuación, se puede proporcionar una aplicación web para un usuario que opera un dispositivo cliente basado en procesador 520 que tiene acceso seguro a la red de proveedores médicos 508 (por ejemplo, a través de VPN). La aplicación web funciona para fusionar datos PHI locales del sistema PHI 510 con los datos de-identificados del sistema de ASP 504, sin proporcionar ningún dato PHI al sistema de ASP.
Una organización (por ejemplo, un hospital, otro proveedor médico) puede implementar el sistema PHI 510 en el sitio o en la nube. El sistema PHI 510 que implementa el servicio PHI permite que los datos PHI permanezcan dentro de la red y el control del proveedor médico, al tiempo que permite que el sistema ASP 504 funcione en la nube mientras cumple con las leyes regulatorias y garantiza la privacidad del paciente.
Como se muestra en el proceso 600 de la Figura 6, cuando un usuario carga un estudio médico (por ejemplo, IRM) usando un navegador web que se ejecuta en el dispositivo cliente basado en procesador 520 que tiene acceso seguro a la red del proveedor médico 508, los datos de estudio médico se re-identifican bajo pedido dentro del navegador web. La aplicación web solicita datos tanto desde el sistema ASP 504 (por ejemplo, a través de una aplicación web del sistema ASP) como desde una API web del sistema PHI 510 simultáneamente. Los datos PHI y los datos de identificados luego se fusionan sin problemas dentro del navegador web del usuario que se ejecuta en el dispositivo cliente basado en procesador 520 durante una sesión activa.
El sistema PHI 510 puede proporcionar una API para un dispositivo médico (por ejemplo, el sistema de adquisición de IRM 514) para transferir datos de estudio médico a través de una conexión cifrada. Los datos pueden luego cargarse de forma segura con un procedimiento eficiente en el sistema ASP 504. Esto proporciona facilidad de integración con dispositivos médicos actuales y proporciona seguridad para los datos transferidos fuera de la red 508 de un proveedor médico. El sistema PHI 510 puede reducir la configuración de red complicada por dispositivo al garantizar que toda la comunicación dentro y fuera de la red 508 del proveedor médico se realice de forma segura (por ejemplo, a través de un protocolo HTTP a través de puertos HTTP).
Como se analiza más adelante, es posible que sea necesario empujar los artefactos, tales como objetos de captura secundaria e informes generados dentro de la aplicación web del sistema ASP 504, de vuelta al sistema de informes del proveedor médico y/o PACS. El sistema PHI 510 actúa como un proxy seguro, extrayendo los artefactos del sistema ASP 504 y empujando los datos re-identificados a la ubicación configurada dentro de la red del proveedor médico 508. Esto permite que el proveedor médico utilice los servicios proporcionados por el sistema ASP 504 sin permitir ninguna solicitud de red entrante, lo que mantiene segura la red del proveedor médico.
El sistema PHI 510 también puede actualizarse automáticamente y puede permitir actualizaciones de seguridad, así como actualizaciones de funcionalidad sin requerir la intervención del personal del proveedor médico.
La Figura 7 muestra un proceso de ejemplo 700 de funcionamiento del sistema PHI 510 para extraer datos PHI de ficheros DICOM. El sistema PHI 510 recibe los ficheros DICOM, que incluyen datos PHI y datos de píxeles, desde el sistema informático anfitrión 517 del sistema de adquisición de IRM 514. El sistema PHI 510 extrae los datos PHI de los archivos DICOM y almacena los datos PHI en la base de datos 524. El sistema PHI 510 carga los datos de píxeles de-identificados al sistema ASP 504 a través del firewall 518 para que los utilice el sistema ASP 504 para realizar las diversas funciones analizadas anteriormente.
La Figura 8 muestra un proceso de ejemplo 800 de almacenamiento de un informe generado por el usuario en el servidor PACS registrado 525 asociado con el proveedor médico. Como se muestra, el usuario que opera el dispositivo cliente basado en procesador 520 puede solicitar, a través de la aplicación web, que el sistema ASP 504 cree un informe. En respuesta a la solicitud, el sistema ASP 504 genera el informe. El servicio PHI 510 puede, de vez en cuando, sondear el sistema ASP 504 en busca de informes de-identificados. Cuando el sistema ASP 504 tiene uno o más informes de-identificados disponibles, el sistema ASP 504 envía uno o más informes de-identificados al sistema PHI 510 a través de una transferencia cifrada. El sistema PHI 510 luego almacena el informe recibido en el servidor PACS 525 para su uso posterior.
La Figura 9 es un diagrama esquemático 900 del sistema PHI 510, que muestra cómo los archivos DICOM recibidos por el sistema informático anfitrión 517 del sistema de adquisición de IRM 514 son manejados por el sistema PHI 510. Entre otros servicios, el servicio PHI 510 puede incluir un servicio 902 de subida de escáner, un servicio 904 de de identificación, un servicio 906 de carga o subida, un servicio 908 de almacenamiento PHI y un servicio 910 de agregador de estado. Cada uno de estos servicios se analiza más adelante.
Generalmente, el servicio de carga o subida de escáner 902 es responsable de subir archivos DICOM desde el sistema informático anfitrión 517 del sistema de adquisición de IRM 514. El servicio de subida de escáner 902 también publica el estado del procesamiento de archivos DICOM en el servicio agregador de estado 910. El servicio de subida de escáner 902 también envía archivos DICOM extraídos al servicio de desidentificación 904.
Como se analiza más adelante con referencia a la Figura 12, el servicio de-identificador 904 funciona para quitar o eliminar cualquier dato PHI de los archivos DICOM. Luego, el servicio de de-identificador 904 envía los archivos DICOM de-identificados al servicio cargador 906 y envía los datos PHI eliminados al servicio de almacenamiento PHI 908, que almacena los datos PHI en la base de datos 524. El servicio de-identificador 904 también publica información del estado de desidentificación en el servicio agregador de estado 910. El servicio cargador 906 envía los archivos DICOM de-identificados al sistema ASP 504 a través de un protocolo de transferencia cifrado para su procesamiento por parte del sistema ASP.
La Figura 10 es un diagrama esquemático 1000 del sistema PHI 510, que muestra cómo se organizan las dependencias del servicio PHI. El sistema PHI 510 incluye un sistema operativo base (por ejemplo, Ubuntu/SL7) que comprende scripts bash 1004, Docker 1006 y ejecutables nativos 1008. El Docker 1006 incluye varios contenedores Docker que se utilizan para implementar los diversos microservicios 1002 del sistema PHI 510. Como se muestra en las Figuras 9 y 11, dichos microservicios 1002 pueden incluir el servicio de subida de escáner 902, el servicio deidentificador 904, el servicio cargador 906, el servicio de almacenamiento 908, el servicio agregador de estado 910, un servicio de proxy SSL 1106, un servicio de artefacto 1108, y un servicio de lanzamiento 1110, por ejemplo.
Las Figuras 11A-11B (colectivamente, Figura 11) son un diagrama de secuencia del sistema 1100 que ilustra una secuencia de lanzamiento del servicio PHI 510. Los componentes asociados con la implementación de la secuencia de lanzamiento incluyen un nodo de control de servicio 1102, un servicio de gestión de claves 1104 del servicio PHI 510, el sistema ASP 504, el servicio de subida de escáner 902, el servicio de-identificador 904, el servicio de almacenamiento 908, el servicio de proxy SSL 1106, el servicio de artefacto 1108 y el servicio de lanzamiento 1110.
En 1112 y 1114, el control de servicio 1102 crea una solicitud firmada al sistema ASP 504 a través del servicio de almacenamiento 908. En 1116, el sistema ASP 504 solicita una clave de datos en texto sin formato (plain text) desde el servicio de gestión de claves 1104. En 1118, el servicio de gestión de claves 1104 devuelve la clave al sistema ASP 504 que, en 1120, devuelve la clave de datos en texto sin formato y una clave de datos cifrada al servicio de almacenamiento 908 del sistema PHI 510. En 1122, el servicio de almacenamiento 908 proporciona una indicación al control de servicio 1102 de que el servicio de almacenamiento 908 ha comenzado.
En 1124, el control de servicio 1102 envía una orden de inicio al servicio de lanzamiento 1110. En 1126-1130, el servicio de lanzamiento 1110 solicita una clave de texto sin formato del servicio de gestión de claves 1104 a través del sistema ASP 504. En 1134, el servicio de lanzamiento 1110 genera una clave de volumen si no existe ninguna. Luego, la clave de volumen se cifra con la clave de datos de texto sin formato y ahora se la denomina clave de volumen cifrada. La clave de volumen cifrada se almacena junto con la clave de datos cifrados. La clave de datos cifrada identifica de forma única la clave de datos de texto sin formato, lo que permite que el sistema PHI 510 utilice claves en lanzamientos posteriores. En 1136, el servicio de lanzamiento 1110 notifica al control de servicio 1102 que el servicio de lanzamiento ha comenzado.
Al menos en algunas implementaciones, la clave de volumen se usa para inicializar un volumen montado (por ejemplo, un volumen Docker) como un sistema de archivos EncFS en modo paranoia usando aes-256-gcm. Todos los demás servicios que necesitan escribir datos en el disco deben solicitar primero la clave de volumen del servicio de lanzamiento 1110. Como la clave de volumen puede no mantenerse en la memoria, previa solicitud, el servicio de lanzamiento 1110 descifra la clave de volumen cifrada con la clave de datos de texto sin formato en memoria y devuelve la clave de volumen al servicio solicitante. Luego, el servicio solicitante utiliza esa clave de volumen para montar el volumen EncFS compartido de forma descifrada.
En 1138, el control de servicio 1102 inicia el servicio de de-identificación 904. En 1140, el servicio de de-identificación 904 obtiene la clave de volumen del servicio de lanzamiento 1110 que, en 1142, devuelve la clave de volumen al servicio de de-identificación. En 1144, el servicio de de-identificación 904 usa la clave de volumen para montar un volumen EncFS compartido. En 1146, el servicio de de-identificación 904 notifica al control de servicio 1102 que el servicio de desidentificación ha comenzado.
En 1148, el control de servicio 1102 inicia el servicio de subida de escáner 902. En 1150, el servicio de subida de escáner 902 obtiene la clave de volumen del servicio de lanzamiento 1110 que, en 1152, devuelve la clave de volumen al servicio de subida de escáner. En 1154, el servicio de subida de escáner 902 usa la clave de volumen para montar el volumen EncFS. En 1156, el servicio de subida de escáner 902 notifica al control de servicio 1102 que el servicio de subida de escáner se ha iniciado.
En 1158, el control de servicio 1102 inicia el servicio de artefacto 1108. En 1160, el servicio de artefacto 1108 obtiene la clave de volumen del servicio de lanzamiento 1110 que, en 1162, devuelve la clave de volumen al servicio de artefacto. En 1164, el servicio de artefacto 1108 usa la clave de volumen para montar el volumen EncFS. En 1166, el servicio de artefacto 1108 notifica al control de servicios 1102 que el servicio de artefacto se ha iniciado.
En 1168, el control de servicio 1102 inicia el servicio de proxy SSL 1106. El servicio de proxy SSL 1106 es el último en iniciarse. El servicio de proxy SSL 1106 controla el acceso externo a todos los servicios internos. En 1170, el servicio de proxy SSL 1106 notifica al control de servicio 1102 que el servicio de proxy SSL se ha iniciado.
La Figura 12 es un diagrama de flujo que ilustra un proceso 1200 para el servicio de de-identificación 904 del servicio PHI. El servicio de de-identificación 904 es responsable de procesar un estudio cargado por el servicio de subida de escáner 902, recopilar toda la información y garantizar que sea seguro subirlo a, o cargarlo en, el sistema ASP 504. Un componente principal del servicio de de-identificación 904 es el acto de de-identificación real realizado en los datos DICOM. Al menos en algunas implementaciones, se puede utilizar una utilidad gdcmanon modificada del proyecto GDCM.
El proceso 1200 comienza en 1202, por ejemplo, cuando el servicio de subida de escáner 902 envía archivos DICOM extraídos para un estudio al servicio de de-identificación 904. En 1204, se inicia un módulo de procesamiento PHI. En 1206, se realizan una serie de actos de procesamiento 1208-1222. En particular, en 1208 se cambia el nombre de una carpeta que contiene el estudio a procesar. En 1210, se eliminan todos los archivos que no son de estudio (por ejemplo, sha1sum). En 1212, el servicio de de-identificación 904 extrae PHI de los archivos DICOM. En 1214, el servicio de de identificación de-identifica los archivos DICOM. Todos los datos PHI extraídos pueden recopilarse y almacenarse para cada archivo DICOM y pueden enviarse al servicio de almacenamiento 908 al final del proceso, por ejemplo.
En 1216, el servicio de desidentificación 904 extrae UID ofuscadas. El acto de de-identificación 1214 reemplaza una UID de instancia de estudio (StudyInstanceUID) con un valor ofuscado. Los datos originales se vinculan con el estudio enviado al sistema ASP 504 mediante este valor.
En 1218, el servicio de de-identificación 904 realiza un chequeo o verificación de conflicto para la UID ofuscada para garantizar que exista una asignación única entre la UID de instancia de estudio (StudyInstanceUID) y la UID ofuscada. Si hay un conflicto, se puede generar una UID ofuscada diferente para garantizar una asignación única entre la UID de instancia de estudio y la UID ofuscada.
En 1220, el servicio de de-identificación 904 envía los datos PHI al servicio de almacenamiento 909, que almacena los datos PHI 1220 en la base de datos 524, por ejemplo. En 1222, el servicio de de-identificación 904 mueve la carpeta al estado de-identificado. En 1224, una vez que se completa el acto de procesamiento 1206, el servicio de subida 906 pone en cola los datos de-identificados para subirlos al sistema ASP 504. En 1226, el proceso 1200 finaliza hasta que, por ejemplo, se encuentra otro estudio que necesite ser procesado. En 1228, se puede ejecutar un módulo de procesamiento de errores PHI si se detecta un error en cualquiera de los actos de procesamiento 1208-1222.
Los datos PHI recopilados se pueden organizar en un documento con dos niveles de información, un nivel de estudio y un nivel de serie. Los datos pueden indexarse mediante una UID de instancia de estudio ofuscada que proporciona el enlace con los datos almacenados por el sistema ASP 504. Los datos PHI pueden enviarse al servicio de almacenamiento 908, que cifra y almacena los datos en la base de datos 524.
Para manejar datos ISO2022, se puede utilizar la utilidad dcmconv (del proyecto dcmtk). Antes de leer datos PHI del conjunto reducido de archivos DICOM, los archivos DICOM se pueden convertir a UTF-8. Esto acelera el proceso al limitar la cantidad de archivos que deben convertirse y al mismo tiempo garantizar que todos los datos PHI recopilados estén en un formato consistente.
La utilidad gdcmanon maneja la de-identificación en una carpeta de datos DICOM. Sin embargo, el proyecto solo se de-identifica según el estándar NEMA 2008. Como tal, al menos en algunas implementaciones se utiliza una versión modificada de la utilidad gdcmanon que agrega las etiquetas DICOM necesarias para cumplir con el último estándar DICOM.
La utilidad también cifra la PHI y la almacena dentro de cada archivo DICOM como una nueva etiqueta. El sistema PHI 510 no envía ningún dato anónimo, incluso cuando está cifrado, por lo que la utilidad se modifica aún más para omitir el paso de insertar una nueva etiqueta de datos cifrados. Esto acelera aún más el proceso al eliminar la necesidad de agregar un paso adicional para eliminar esa etiqueta más adelante.
Para que funcione el sistema PHI 510, sólo se necesita un pequeño subconjunto de PHI a nivel de estudio y serie según sea necesario. Sin embargo, el estándar DICOM elimina muchos más campos. Para mantener la base de datos 524 del sistema PHI 510 más pequeña, lo que mejora el rendimiento para el usuario, el sistema PHI puede almacenar solamente los datos requeridos en la base de datos 524. En los casos en que se necesiten campos adicionales, o si es necesario reprocesar los datos PHI, los datos no identificados eliminados de cada archivo DICOM pueden almacenarse (por ejemplo, como un archivo JSON que se comprime y archiva).
Las Figuras 13A-13B (colectivamente, Figura 13) son un diagrama de flujo que ilustra un proceso 1300 para el servicio de subida o empuje 906 del sistema PHI 510. El servicio de empuje 906 tiene dos tareas principales. La primera tarea es transferir los estudios identificados al sistema ASP 504. La segunda tarea es monitorear el estado de un estudio subido y actualizar el estado interno del sistema PHI 510 hasta que se alcance un estado final. Esto permite que el sistema informático anfitrión 517 solicite el estado de un estudio desde el sistema PHI 510 y reciba información desde el sistema ASP 504.
En 1302, el servicio de empuje 906 monitorea una carpeta para estudios de-identificados proporcionados por el servicio de de-identificación 904. El servicio de empuje 906 comienza entonces un proceso de carga o carga de archivos 1304. En 1306, el servicio de empuje 906 agrupa o une los datos de-identificados (por ejemplo, tar y gzip el estudio). En 1308, el servicio de empuje 906 calcula la sha1sum del nuevo fichero agrupado (por ejemplo, fichero tar), cuya sha1sum se utiliza para verificar la integridad de la subida y también proporciona una clave con la que solicitar actualizaciones de estado. En 1310, el servicio de empuje 906 puede cambiar el nombre del archivo (por ejemplo, "<sha1sum>.tgz") para garantizar que el nombre del archivo no contenga PHI.
En 1312, el archivo renombrado puede luego subirse al sistema ASP 504 usando un bucle de reintento de envío 1314. El bucle de reintento del remitente continúa intentando cargar el archivo con un retraso cada vez mayor entre intentos. Si el archivo no se carga después de varios intentos, se puede ejecutar un módulo de error de carga 1316. Si la carga se realiza correctamente, se verifica shalsum para garantizar la integridad de los datos. En 1318, el archivo cargado se pone entonces en cola para su procesamiento por el sistema ASP 504.
En 1320, el servicio de empuje 906 puede monitorear remotamente el estado del archivo cargado. Como ejemplo, la carga o servicio 906 puede usar sha1sum como clave de búsqueda. Los posibles estados del archivo cargado pueden incluir "error de procesamiento", que significa que ocurrió un error, "procesamiento", que significa que el archivo se está procesando, o "procesado", que significa que el archivo ha sido procesado.
El servicio de almacenamiento 908 es responsable de almacenar los datos PHI extraídos para que luego puedan recuperarse para su re-identificación. Cuando se ejecuta el servicio de almacenamiento, el servicio de almacenamiento se comunica con el sistema ASP 504 y recupera la clave de datos en texto sin formato y la clave de datos cifrada, como se analizó anteriormente. Estas claves luego se almacenan en la memoria. Cualquier dato que el servicio de almacenamiento 908 escriba en el disco se cifra con la clave de datos de texto sin formato y se almacena junto con la clave de datos cifrada que identifica la clave de datos de texto sin formato que se utilizó para cifrar los datos.
Las Figuras 14A-14B (colectivamente, Figura 14) son un diagrama de secuencia del sistema 1400 que ilustra un proceso 1400 para la re-identificación de los datos en un navegador web que ejecuta una aplicación web en el dispositivo cliente basado en procesador 520 (Figura 5). En 1402, el navegador web envía una solicitud al sistema ASP 504 para cargar una aplicación. En 1404, el sistema ASP 504 carga la aplicación en el navegador web. A un usuario que se ha autenticado exitosamente en la aplicación web del sistema a Sp 504 se le puede dar un token web (por ejemplo, token web JSON). Como se analizó anteriormente, este token web se envía al sistema PHI 510, mediante el navegador web, cuando se solicitan datos. El servicio de proxy SSL 1106 (Figura 11) reenvía todas las solicitudes de datos a un servicio de autorización del sistema PHI 510 para garantizar que el usuario aún tenga acceso válido y autenticado a la aplicación web. Este es un proceso transparente en lo que respecta al usuario.
En 1406, el navegador web solicita información sobre el sistema PHI 510 desde el sistema ASP 504. En 1408, el sistema ASP 504 envía la información del sistema PHI al navegador web. En 1410, el navegador web solicita un token de acceso PHI desde el sistema ASP 504. Los tokens de acceso PHI están cifrados y solo pueden ser leídos por el sistema ASP 504. En 1412, el sistema ASP 504 envía el token de acceso PHI encriptado al navegador web.
En 1414, el navegador web consulta el sistema PHI 510 para obtener una lista de trabajo de estudios disponibles. Todas las solicitudes al sistema PHI 510 contienen el token de acceso PHI encriptado. En 1416, el sistema PHI 510 envía un token de acceso cifrado al sistema ASP 504 para su validación. El sistema ASP 504 confirma que el token de acceso es válido (es decir, el token de acceso pertenece a una sesión activa). En 1418, el sistema ASP 504 envía una notificación al sistema PHI 510 indicando que el token de acceso es válido.
Después de la autenticación/autorización adecuada, el sistema PHI 510 recupera la lista de trabajo y estudia los datos PHI a través de una API del servicio de almacenamiento 908. En 1420, el sistema PHI 510 envía los datos PHI de la lista de trabajo al navegador web.
En 1422, tras la selección de un estudio de la lista de trabajo, el navegador web envía una solicitud al sistema ASP 504 para cargar un estudio. En respuesta a dicha solicitud, el sistema ASP comienza a cargar el estudio en un sistema informático (por ejemplo, un grupo de computación). En 1424, el navegador web envía una solicitud al sistema PHI 510 para obtener datos PHI asociados con el estudio seleccionado. El acceso concedido puede almacenarse en caché durante un breve periodo de tiempo y, como tal, es posible que esta solicitud no requiera validación. En 1426, el sistema PHI 510 envía los datos p H i para el estudio seleccionado al navegador web. En 1428, una vez que el estudio se carga en el grupo de computación, el sistema ASP 504 envía los datos del estudio al navegador web 520.
En 1430, el navegador web junta o fusiona los datos del estudio recibidos del sistema ASP 504 con los datos PHI recibidos del sistema PHI 510 y los presenta al usuario para el uso de los servicios proporcionados por el ASP. Por lo tanto, utilizando el proceso 1400, el usuario tiene acceso a los datos y análisis completos del estudio proporcionados por el sistema ASP 504 sin proporcionar al sistema ASP ningún acceso a los datos PHI.
Las Figuras 15A-15B (colectivamente, Figura 15) son un diagrama de secuencia del sistema que ilustra un proceso 1500 para implementar el servicio de re-identificación de artefactos 1108. El servicio de re-identificación de artefactos 1108 es responsable de contactar con el sistema ASP 504, descargar cualquier artefacto pendiente, re-identificar los artefactos descargados y almacenarlos en un sistema de destino de proveedor médico, tal como el PACS 525, un sistema de información de radiología basado en web (web-based radiology information system, WRIS), etc.
En 1502, el servicio de re-identificación de artefactos 1108 envía una solicitud al sistema ASP 504 solicitando una lista de artefactos pendientes. En 1504, el sistema ASP 504 proporciona al servicio de re-identificación de artefactos 1108 una lista de artefactos pendientes.
En 1506, el servicio de re-identificación de artefactos 1108 envía una solicitud al sistema ASP 504 para obtener uno de los artefactos pendientes en la lista recibida de artefactos pendientes. Los artefactos pueden ser objetos de captura secundaria, informes o cualquier otra cosa que el sistema ASP 508 pueda querer empujar al almacenamiento de destino del proveedor médico 525. En 1508, el sistema ASP 504 envía el artefacto solicitado al servicio de re identificación de artefactos 1108.
En 1512, el servicio de artefactos 1108 solicita datos PHI para el artefacto desde el servicio de almacenamiento 908. Esta solicitud puede utilizar la etiqueta StudyInstanceUID ofuscada, tal como se proporciona en la respuesta, para consultar el servicio de almacenamiento 908 para obtener la información de etiqueta original asociada para esa StudyInstanceUID. En 1514, el servicio de almacenamiento 908 del sistema PHI 510 envía los datos PHI al servicio de artefactos 1108.
En 1516, el servicio de artefactos 1108 vuelve a identificar el artefacto. Por ejemplo, para datos DICOM, se puede utilizar la utilidad dcmodify para reescribir las etiquetas DICOM del artefacto para que coincidan con las que se almacenaron originalmente.
Tras una re-identificación exitosa, el artefacto se empuja al almacenamiento de destino 525 del proveedor médico. El destino puede ser un PACS, WRIS o cualquier otro punto final compatible. Los detalles de conexión pueden proporcionarse desde el sistema ASP 504 con los detalles del artefacto.
En 1522, el servicio de artefactos 1108 envía una notificación al sistema ASP 504 indicando que el proceso de re identificación de artefactos para ese artefacto se ha completado. En 1524, el sistema ASP 504 notifica al servicio de artefactos 1104 que el estado de ese artefacto se ha actualizado, indicando que dicho artefacto ya no se devolverá en la lista de artefactos pendientes durante la siguiente iteración.
Los enfoques automatizados descritos anteriormente eliminan la subjetividad en la identificación de la estructura anatómica y el flujo, que es endémica en los enfoques convencionales, proporcionando un alto nivel de repetibilidad. Esta repetibilidad permite nuevos usos para los datos de IRM. Por ejemplo, los datos de IRM de un solo paciente se pueden revisar de manera confiable en diferentes sesiones para detectar tendencias. Aún más sorprendente es que los datos de IRM de una pluralidad de pacientes pueden revisarse de manera confiable para detectar tendencias en una población o grupo demográfico.
Las diversas realizaciones descritas anteriormente se pueden combinar para proporcionar realizaciones adicionales. En la medida en que no sean incompatibles con las enseñanzas y definiciones específicas del presente documento, se citan todas las patentes estadounidenses, publicaciones de solicitudes de patentes estadounidenses, solicitudes de patentes estadounidenses, patentes extranjeras, solicitudes de patentes extranjeras y publicaciones que no sean de patentes a las que se hace referencia en esta especificación y/o enumerados en la hoja de datos de la solicitud, que incluye, entre otros, la solicitud de patente provisional de EE. UU. N.° 61/571,908, presentada el 7 de julio de 2011; Solicitud de Patente Internacional No. p Ct /US2012/045575, presentada el 5 de julio de 2012; Solicitud de patente provisional de EE. UU. n.° 61/928.702, presentada el 17 de enero de 2014; Solicitud de Patente Internacional No. PCT/US2015/011851, presentada el 16 de enero de 2015; Solicitud de patente estadounidense n.° 15/112130 presentada el 15 de julio de 2016; Solicitud de patente provisional de EE. UU. n.° 62/260.565, presentada el 29 de noviembre de 2015; Solicitud de patente provisional de EE. UU. N.° 62/415,203 presentada el 31 de octubre de 2016; y la Solicitud de Patente Provisional de EE. UU. N.° 62/415,666 presentada el 1 de noviembre de 2016.

Claims (14)

REIVINDICACIONES
1. Un procedimiento para operar una plataforma de análisis médicos, comprendiendo la plataforma de análisis médicos un sistema proveedor de servicios de análisis, ASP, (504) y un sistema de información de salud protegida, PHI, (510), comprendiendo el procedimiento:
almacenar, mediante al menos un procesador del sistema ASP, datos de estudio médico de-identificados en al menos un medio de almacenamiento no transitorio legible por procesador del sistema ASP (504);
almacenar, mediante al menos un procesador del sistema PHI, datos PHI asociados con los datos de estudio médico de-identificados en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI (510);
enviar, mediante el al menos un procesador del sistema ASP, datos de estudio médico de-identificados para un estudio médico solicitado al dispositivo cliente basado en procesador a través de al menos una red de comunicaciones;
validar, mediante el al menos un procesador del sistema ASP, el estado del dispositivo cliente basado en procesador para acceder al sistema PHI basándose en un token de acceso PHI encriptado enviado desde el sistema PHI, donde el token de acceso PHI encriptado es enviado previamente por el sistema ASP al dispositivo cliente basado en procesador en respuesta a una solicitud de un token de acceso PHI desde el dispositivo cliente basado en procesador y es recibido por el sistema PHI en una solicitud de datos PHI para el estudio médico desde el dispositivo cliente basado en procesador;
en respuesta a la validación (1418) del sistema ASP del estado del dispositivo cliente basado en procesador para acceder al sistema PHI, enviar (1420), por el al menos un procesador del sistema PHI, datos PHI para el estudio médico solicitado al dispositivo cliente basado en procesador a través de al menos una red de comunicaciones, donde el estudio médico solicitado se re-identifica basándose al menos en parte en los datos de estudio médico de identificados y los datos PHI sin proporcionar al sistema ASP acceso a los datos PHI;
generar, por el al menos un procesador del sistema ASP, datos de análisis relacionados con los datos de estudio médico de-identificados; y
enviar, por el al menos un procesador del sistema ASP, los datos de análisis generados al sistema PHI a través de la al menos una red de comunicaciones.
2. El procedimiento de la reivindicación 1, donde el sistema PHI está acoplado comunicativamente a una red privada, comprendiendo además el procedimiento:
verificar, mediante el al menos un procesador del sistema ASP (504) o el al menos un procesador del sistema PHI (510), que el dispositivo cliente basado en procesador tiene acceso a la red privada.
3. El procedimiento de la reivindicación 1, que comprende, además:
recibir, mediante el al menos un procesador del sistema ASP (504), la solicitud del token de acceso PHI desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones;
enviar, mediante el al menos un procesador del sistema ASP, el token de acceso PHI encriptado al dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones;
recibir, mediante el al menos un procesador del sistema PHI (510), la solicitud de datos PHI para el estudio médico desde el dispositivo cliente basado en procesador, donde la solicitud incluye el token de acceso PHI encriptado;
enviar, mediante el al menos un procesador del sistema PHI, el token de acceso PHI encriptado al sistema ASP a través de la al menos una red de comunicaciones;
validar, mediante el al menos un procesador del sistema ASP, el token de acceso PHI encriptado recibido; y notificar, mediante el al menos un procesador del sistema ASP, al sistema PHI que el token de acceso PHI es válido,
donde el envío de los datos PHI solicitados al dispositivo cliente basado en procesador es en respuesta a que al menos un procesador del sistema PHI reciba la notificación de validación del sistema ASP.
4. El procedimiento de la reivindicación 1, que comprende, además:
recibir, mediante el al menos un procesador del sistema PHI (510), datos de estudio médico que incluyen datos PHI;
eliminar, mediante el al menos un procesador del sistema PHI, los datos PHI de los datos de estudio médico para generar datos de estudio médico de-identificados;
almacenar, mediante el al menos un procesador del sistema PHI, los datos PHI en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y
enviar, mediante el al menos un procesador del sistema PHI, los datos de estudio médico de-identificados al sistema ASP a través de la al menos una red de comunicaciones.
5. El procedimiento de la reivindicación 4, donde recibir datos de estudio médico que incluyen datos PHI comprende recibir datos de imagen médica desde un escáner.
6. El procedimiento de la reivindicación 4, donde enviar los datos de estudio médico de-identificados al sistema ASP comprende enviar los datos de estudio médico de-identificados al sistema ASP utilizando una interfaz de programación de aplicaciones de transferencia de estado representacional REST.
7. El procedimiento de la reivindicación 4, donde eliminar los datos PHI de los datos de estudio médico comprende:
eliminar, mediante el al menos un procesador del sistema PHI, campos que está permitido que sean eliminados; y
reemplazar, mediante el al menos un procesador del sistema PHI, datos en campos que no está permitido que sean eliminados con datos de reemplazo ofuscados.
8. El procedimiento de la reivindicación 4, que comprende, además:
asociar, mediante el al menos un procesador del sistema PHI, un identificador único con los datos de estudio médico para un estudio médico;
almacenar, mediante el al menos un procesador del sistema PHI, el identificador único en al menos un medio de almacenamiento no transitorio legible por procesador del sistema PHI; y
enviar, mediante el al menos un procesador del sistema PHI, el identificador único con los datos médicos de identificados para el estudio médico al sistema ASP a través de la al menos una red de comunicaciones.
9. El procedimiento de la reivindicación 1, que comprende, además:
recibir, mediante al menos un procesador del dispositivo cliente basado en procesador, los datos PHI del sistema PHI a través de la al menos una red de comunicaciones;
recibir, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos de estudio médico de-identificados desde el sistema ASP a través de la al menos una red de comunicaciones;
fusionar, mediante el al menos un procesador del dispositivo cliente basado en procesador, los datos PHI y los datos de estudio médico de-identificados para generar datos de estudio médico re-identificados; y presentar, mediante al menos un procesador del dispositivo cliente basado en procesador, los datos de estudio médico re-identificados a un usuario del dispositivo cliente basado en procesador.
10. El procedimiento de la reivindicación 1, que comprende, además:
recibir, mediante el al menos un procesador del sistema ASP, una solicitud para generar datos de análisis desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones,
donde le generación de los datos de análisis responde a la recepción de la solicitud para generar datos de análisis desde el dispositivo cliente basado en procesador.
11. El procedimiento de la reivindicación 1, donde generar datos de análisis comprende generar al menos uno de un informe o un objeto de captura secundario, y enviar los datos de análisis generados al sistema PHI comprende enviar al menos uno del informe o el objeto de captura secundario al sistema PHI a través de la al menos una red de comunicaciones para almacenamiento en el al menos un medio de almacenamiento no transitorio legible por procesador acoplado comunicativamente con el sistema PHI.
12. El procedimiento de la reivindicación 1, que comprende, además:
proporcionar, mediante el al menos un procesador del sistema PHI, una lista de estudios disponibles al dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones; y
recibir, mediante el al menos un procesador del sistema PHI, una selección de al menos uno de los estudios disponibles en la lista desde el dispositivo cliente basado en procesador a través de la al menos una red de comunicaciones.
13. El procedimiento de la reivindicación 1, que comprende, además:
enviar periódicamente, mediante el al menos un procesador del sistema PHI, un chequeo de actualizaciones al sistema ASP a través de la al menos una red de comunicaciones;
determinar, mediante el al menos un procesador del sistema ASP, si se necesita alguna actualización del sistema PHI; y
en respuesta a determinar que se necesita al menos una actualización del sistema PHI, enviar, mediante el al menos un procesador del ASP, datos de actualización al sistema PHI a través de la al menos una red de comunicaciones.
14. Una plataforma de análisis médicos, que comprende:
al menos un procesador (212); y
al menos un medio no transitorio legible por procesador (214) acoplado comunicativamente al al menos un procesador, incluyendo el al menos un medio no transitorio legible por procesador uno o más conjuntos de instrucciones ejecutables por procesador que, cuando son ejecutados por el al menos un procesador, causan al al menos un procesador que realice cualquiera de los procedimientos de las reivindicaciones 1 a 13.
ES16869357T 2015-11-29 2016-11-29 Imágenes médicas e intercambio eficiente de información de imágenes médicas Active ES2970825T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562260565P 2015-11-29 2015-11-29
US201662415203P 2016-10-31 2016-10-31
PCT/US2016/064029 WO2017091834A1 (en) 2015-11-29 2016-11-29 Medical imaging and efficient sharing of medical imaging information

Publications (1)

Publication Number Publication Date
ES2970825T3 true ES2970825T3 (es) 2024-05-30

Family

ID=58763677

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16869357T Active ES2970825T3 (es) 2015-11-29 2016-11-29 Imágenes médicas e intercambio eficiente de información de imágenes médicas

Country Status (6)

Country Link
US (6) US20180256042A1 (es)
EP (3) EP3380971B1 (es)
JP (3) JP6871250B2 (es)
CN (2) CN108431817B (es)
ES (1) ES2970825T3 (es)
WO (2) WO2017091834A1 (es)

Families Citing this family (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10331852B2 (en) 2014-01-17 2019-06-25 Arterys Inc. Medical imaging and efficient sharing of medical imaging information
CN108431817B (zh) 2015-11-29 2022-09-16 阿特瑞斯公司 医学成像和医学成像信息的高效共享
EP3300021B1 (en) * 2016-09-22 2018-12-05 RaySearch Laboratories AB Image processing system and method for interactive contouring of three-dimensional medical data
JP6817775B2 (ja) * 2016-10-11 2021-01-20 株式会社東芝 補正装置、補正方法及び磁気共鳴画像装置
US11688495B2 (en) 2017-05-04 2023-06-27 Arterys Inc. Medical imaging, efficient sharing and secure handling of medical imaging information
US10129269B1 (en) 2017-05-15 2018-11-13 Forcepoint, LLC Managing blockchain access to user profile information
CN107290700B (zh) * 2017-08-08 2020-12-04 上海联影医疗科技股份有限公司 一种相位校正方法、装置及磁共振系统
US10949966B2 (en) * 2017-08-18 2021-03-16 Siemens Healthcare Gmbh Detecting and classifying medical images based on continuously-learning whole body landmarks detections
US10677873B2 (en) * 2017-08-29 2020-06-09 General Electric Company System and method for correcting an artifact within magnetic resonance data
WO2019103912A2 (en) 2017-11-22 2019-05-31 Arterys Inc. Content based image retrieval for lesion analysis
FR3080761B1 (fr) 2018-05-03 2025-08-01 Alara Expertise Dispositif et methode animant un debit pulse connu a l'interieur d'une irm, pour effectuer son evaluation de performances dans le domaine des mesures hemodynamiques
US10918344B2 (en) * 2018-05-29 2021-02-16 Wisconsin Alumni Research Foundation Methods and systems for determining vascular velocity using CT imaging
WO2019241155A1 (en) 2018-06-11 2019-12-19 Arterys Inc. Simulating abnormalities in medical images with generative adversarial networks
CN109450985B (zh) * 2018-10-17 2021-09-21 中电万维信息技术有限责任公司 一种基于Html5高性能的Web影像加载展现系统
US10861178B2 (en) 2018-11-02 2020-12-08 International Business Machines Corporation Developing a training set for a deep learning system configured to determine a centerline in a three dimensional image
JP7475344B2 (ja) * 2018-11-21 2024-04-26 アーテリーズ インコーポレイテッド 保護された健康情報を追跡し、それにアクセスし、それをマージするためのシステムおよび方法
KR102001790B1 (ko) * 2018-12-24 2019-07-23 (주)제이엘케이인스펙션 인공지능 기반 혈류 구간 분류 방법 및 시스템
US10909681B2 (en) 2019-01-03 2021-02-02 The Regents Of The University Of California Automated selection of an optimal image from a series of images
WO2020167736A2 (en) * 2019-02-15 2020-08-20 Arterys Inc. Deep learning-based eddy current correction
CN111613301B (zh) * 2019-02-22 2023-09-15 曹生 基于VRDS 4D医学影像的动脉与静脉Ai处理方法及产品
JP7539921B2 (ja) 2019-04-24 2024-08-26 プロジェニクス ファーマシューティカルズ， インコーポレイテッド 核医学画像における強度ウィンドウ処理の双方向調節のためのシステムおよび方法
US10997295B2 (en) * 2019-04-26 2021-05-04 Forcepoint, LLC Adaptive trust profile reference architecture
EP3664036B1 (de) 2019-04-30 2022-08-17 Siemens Healthcare GmbH Verfahren und system zur berechnung einer ausgabe von einem durch einen tomographen bereitgestellten scrollbaren bildstapel
US11854281B2 (en) 2019-08-16 2023-12-26 The Research Foundation For The State University Of New York System, method, and computer-accessible medium for processing brain images and extracting neuronal structures
US11676701B2 (en) 2019-09-05 2023-06-13 Pearl Inc. Systems and methods for automated medical image analysis
EP3792925A1 (de) * 2019-09-11 2021-03-17 Siemens Healthcare GmbH Verfahren und vorrichtung zur datentechnischen kommunikation in einem netzwerk
EP3799056A1 (en) * 2019-09-24 2021-03-31 Siemens Healthcare GmbH Cloud-based patient data exchange
US11544407B1 (en) 2019-09-27 2023-01-03 Progenics Pharmaceuticals, Inc. Systems and methods for secure cloud-based medical image upload and processing
US11521345B2 (en) * 2019-09-30 2022-12-06 GE Precision Healthcare LLC Method and system for providing rotation previews for three-dimensional and four-dimensional ultrasound images
TWI728553B (zh) * 2019-11-14 2021-05-21 財團法人資訊工業策進會 資料去識別處理裝置及方法
CN111083200B (zh) * 2019-11-25 2022-07-05 武汉联影医疗科技有限公司 智能服务网络系统
US12588817B2 (en) * 2019-12-11 2026-03-31 GE Precision Healthcare LLC Systems and methods for generating diagnostic scan parameters from calibration images
CN111046873B (zh) * 2019-12-12 2020-07-28 电子科技大学中山学院 基于机器视觉的产品功能耐久性测试自学习方法
CN111158649B (zh) * 2019-12-23 2024-12-27 中国建设银行股份有限公司 多层级参数配置的方法和装置
CN111179252B (zh) * 2019-12-30 2021-02-05 山东大学齐鲁医院 基于云平台的消化道病灶辅助识别与正反馈系统
CN111214255B (zh) * 2020-01-12 2023-07-25 刘涛 一种医学超声图像计算机辅助方法
US11055789B1 (en) 2020-01-17 2021-07-06 Pearl Inc. Systems and methods for insurance fraud detection
US12216791B2 (en) 2020-02-24 2025-02-04 Forcepoint Llc Re-identifying pseudonymized or de-identified data utilizing distributed ledger technology
US12089988B2 (en) * 2020-04-28 2024-09-17 EchoNous, Inc. Systems and methods for automated physiological parameter estimation from ultrasound image sequences
WO2022020394A1 (en) * 2020-07-20 2022-01-27 The Regents Of The University Of California Deep learning cardiac segmentation and motion visualization
US11720704B1 (en) 2020-09-01 2023-08-08 Cigna Intellectual Property, Inc. System and method for authenticating access to private health information
US12493676B2 (en) 2020-09-01 2025-12-09 Cigna Intellectual Property, Inc. System and method for authenticating access to private health information
US12354232B2 (en) 2020-10-09 2025-07-08 The Regents Of The University Of California Spatiotemporal resolution enhancement of biomedical images
WO2022075994A1 (en) * 2020-10-09 2022-04-14 Hewlett-Packard Development Company, L.P. Correcting scanned documents based on determined corrective functions
DE102020213497A1 (de) * 2020-10-27 2022-04-28 Siemens Healthcare Gmbh Verbessertes Dosisdatenmanagementsystem und -verfahren
CN112883308B (zh) * 2020-12-04 2024-09-13 中船鹏力(南京)大气海洋信息系统有限公司 基于WebGL的大批量目标加载与显示的方法
WO2022150821A1 (en) 2021-01-06 2022-07-14 Pearl Inc. Computer vision-based analysis of provider data
GB202101908D0 (en) * 2021-02-11 2021-03-31 Axial Medical Printing Ltd Axial3D pathology
US12444506B2 (en) 2021-02-11 2025-10-14 Axial Medical Printing Limited Systems and methods for automated segmentation of patient specific anatomies for pathology specific measurements
US12260549B2 (en) * 2021-02-15 2025-03-25 The Regents Of The University Of California Automated deep correction of MRI phase-error
CN115906144B (zh) * 2021-08-26 2024-04-19 抖音视界有限公司 数据处理方法、数据处理装置、电子设备和可读存储介质
KR102657226B1 (ko) * 2021-10-18 2024-04-15 주식회사 온택트헬스 심장 초음파 이미지 데이터를 증강하기 위한 방법 및 장치
US12586182B2 (en) 2021-11-09 2026-03-24 The Regents Of The University Of California Multi-prong multitask convolutional neural network for biomedical image inference
US11886955B2 (en) 2022-02-16 2024-01-30 Protopia AI, Inc. Self-supervised data obfuscation in foundation models
CN115862817A (zh) * 2022-10-18 2023-03-28 南京鼓楼医院 一种基于人工智能的医学图像处理系统及方法
US12241954B2 (en) * 2023-04-14 2025-03-04 United Imaging Healthcare North America, Inc. Systems and methods for quantitative measurement in magnetic resonance imaging
US20250023730A1 (en) * 2023-07-10 2025-01-16 Bank Of America Corporation Systems and methods for image authenticated data transfers between electronic devices in a distributed network
US20260064887A1 (en) * 2024-09-04 2026-03-05 Koninklijke Philips N.V. Methods and systems for storing and controlling access to protected health data, making de-identified health data available for use and resolving identities of de-identified health data to authorized users

Family Cites Families (86)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6032120A (en) 1997-12-16 2000-02-29 Acuson Corporation Accessing stored ultrasound images and other digital medical images
US6377832B1 (en) * 1998-03-20 2002-04-23 Georgia Tech Research Corporation System and method for analyzing a medical image
US8073712B2 (en) 1999-04-02 2011-12-06 Cybernet Systems Corporation Method for consolidating medical records through the world wide web
WO2000067185A1 (en) * 1999-05-05 2000-11-09 Healthgram, Inc. Portable health record
US6317620B1 (en) * 2000-05-04 2001-11-13 General Electric Company Method and apparatus for rapid assessment of stenosis severity
WO2002005061A2 (en) 2000-07-06 2002-01-17 David Paul Felsher Information record infrastructure, system and method
US20020073138A1 (en) * 2000-12-08 2002-06-13 Gilbert Eric S. De-identification and linkage of data records
DE10117685C2 (de) 2001-04-09 2003-02-27 Siemens Ag Verfahren zur Bearbeitung von Objekten eines standardisierten Kommunikationsprotokolls
US7523505B2 (en) 2002-08-16 2009-04-21 Hx Technologies, Inc. Methods and systems for managing distributed digital medical data
GB0219408D0 (en) 2002-08-20 2002-09-25 Mirada Solutions Ltd Computation o contour
JP2004133727A (ja) 2002-10-11 2004-04-30 Hitachi Ltd 医療支援システム
US7519591B2 (en) 2003-03-12 2009-04-14 Siemens Medical Solutions Usa, Inc. Systems and methods for encryption-based de-identification of protected health information
JP2007531124A (ja) 2004-03-26 2007-11-01 コンヴァージェンス シーティー 患者医療データ記録のアクセス及び利用を制御するためのシステム及び方法
US9820658B2 (en) * 2006-06-30 2017-11-21 Bao Q. Tran Systems and methods for providing interoperability among healthcare devices
US8989349B2 (en) * 2004-09-30 2015-03-24 Accuray, Inc. Dynamic tracking of moving targets
US7049816B2 (en) * 2004-09-30 2006-05-23 Wisconsin Alumni Research Foundation Magnetic resonance imaging with dual velocity encoded projection reconstruction acquisition
US7127095B2 (en) 2004-10-15 2006-10-24 The Brigham And Women's Hospital, Inc. Factor analysis in medical imaging
EP1659511A1 (en) 2004-11-18 2006-05-24 Cedara Software Corp. Image archiving system and method for handling new and legacy archives
US20060229911A1 (en) 2005-02-11 2006-10-12 Medcommons, Inc. Personal control of healthcare information and related systems, methods, and devices
US20060242159A1 (en) * 2005-03-10 2006-10-26 Bishop Robert J Methods and apparatus for distributing digital medical images via a redirected system
US20070061460A1 (en) 2005-03-24 2007-03-15 Jumpnode Systems,Llc Remote access
US20070255704A1 (en) 2006-04-26 2007-11-01 Baek Ock K Method and system of de-identification of a record
CA2652470C (en) 2006-06-08 2014-12-16 Softmedical, Inc. Methods and systems for consolidating medical information
US7974924B2 (en) 2006-07-19 2011-07-05 Mvisum, Inc. Medical data encryption for communication over a vulnerable system
US8719047B2 (en) 2008-06-17 2014-05-06 American Well Corporation Patient directed integration of remotely stored medical information with a brokerage system
US7961187B2 (en) * 2007-03-20 2011-06-14 The University Of North Carolina Methods, systems, and computer readable media for flexible occlusion rendering
US20090012817A1 (en) * 2007-07-06 2009-01-08 Squires Charles S System and method for facilitating cross enterprise data sharing in a healthcare setting
US20090099862A1 (en) * 2007-10-16 2009-04-16 Heuristic Analytics, Llc. System, method and computer program product for providing health care services performance analytics
US8065166B2 (en) 2007-10-30 2011-11-22 Onemednet Corporation Methods, systems, and devices for managing medical images and records
US8108912B2 (en) 2008-05-29 2012-01-31 Red Hat, Inc. Systems and methods for management of secure data in cloud-based network
US20100082369A1 (en) * 2008-09-29 2010-04-01 General Electric Company Systems and Methods for Interconnected Personalized Digital Health Services
US8527251B2 (en) * 2009-05-01 2013-09-03 Siemens Aktiengesellschaft Method and system for multi-component heart and aorta modeling for decision support in cardiac disease
US9118641B1 (en) * 2009-07-01 2015-08-25 Vigilytics LLC De-identifying medical history information for medical underwriting
US20120070045A1 (en) * 2009-12-17 2012-03-22 Gregory Vesper Global medical imaging repository
US8799221B2 (en) 2010-04-23 2014-08-05 John Canessa Shared archives in interconnected content-addressable storage systems
US8696579B2 (en) 2010-06-04 2014-04-15 Siemens Medical Solutions Usa, Inc. Cardiac flow quantification with volumetric imaging data
US8898798B2 (en) * 2010-09-01 2014-11-25 Apixio, Inc. Systems and methods for medical information analysis with deidentification and reidentification
US8948478B2 (en) 2010-10-08 2015-02-03 Codonics, Inc. Multi-media medical record system
US8971608B2 (en) 2010-12-09 2015-03-03 Koninklijke Philips N.V. Volumetric rendering of image data
US8600476B2 (en) * 2011-04-21 2013-12-03 Siemens Aktiengesellschaft Patient support table control system for use in MR imaging
CN103781416B (zh) * 2011-07-07 2016-09-14 小利兰·斯坦福大学托管委员会 使用体相位对比mri的全面的心血管分析
EP2732423A4 (en) 2011-07-13 2014-11-26 Multiple Myeloma Res Foundation Inc METHOD FOR DETECTING AND DISTRIBUTING DATA
US20130041686A1 (en) 2011-08-10 2013-02-14 Noah S. Prywes Health care brokerage system and method of use
US8959347B2 (en) * 2011-08-29 2015-02-17 Salesforce.Com, Inc. Methods and systems of data security in browser storage
US9585568B2 (en) 2011-09-11 2017-03-07 Steven D. Wolff Noninvasive methods for determining the pressure gradient across a heart valve without using velocity data at the valve orifice
US8682049B2 (en) 2012-02-14 2014-03-25 Terarecon, Inc. Cloud-based medical image processing system with access control
KR101285281B1 (ko) 2012-03-29 2013-08-23 주식회사 씨디에스 자가조직 저장매체의 보안 시스템 및 그 방법
US20140109239A1 (en) 2012-03-30 2014-04-17 Alexander Calhoun Flint Collaborative cloud-based sharing of medical imaging studies with or without automated removal of protected health information
US20130259651A1 (en) 2012-04-02 2013-10-03 Daniel Bernard Kupratis Differential geared architecture for gas turbine engine
CN102790761B (zh) * 2012-06-13 2015-05-06 浙江浙大中控信息技术有限公司 一种区域医疗信息系统及访问权限控制方法
US20140114672A1 (en) 2012-10-19 2014-04-24 Datcard Systems, Inc. Cloud based viewing, transfer and storage of medical data
EP2909803A1 (en) 2012-10-19 2015-08-26 Apixio, Inc. Systems and methods for medical information analysis with deidentification and reidentification
US10255455B2 (en) 2012-11-26 2019-04-09 Fisher & Paykel Healthcare Limited Method and system for accessing centralised patient data
GB2509064A (en) * 2012-12-18 2014-06-25 Completegp Ltd Method and system for distributing health data
US8908951B2 (en) * 2012-12-27 2014-12-09 General Electric Company Complex reconstruction of Q-space for simultaneous detection of coherent and incoherent motion
US9203814B2 (en) 2014-02-24 2015-12-01 HCA Holdings, Inc. Providing notifications to authorized users
US20140309521A1 (en) 2013-04-11 2014-10-16 Vassol Inc. Aliasing correction in pcmr imaging
CN104156935B (zh) 2013-05-14 2018-01-02 东芝医疗系统株式会社 图像分割装置、图像分割方法和医学图像设备
US10152688B2 (en) 2014-05-15 2018-12-11 Deroyal Industries, Inc. System for sensing and recording information regarding medical items in a medical facility
US10607726B2 (en) * 2013-11-27 2020-03-31 Accenture Global Services Limited System for anonymizing and aggregating protected health information
US9396355B2 (en) 2013-12-17 2016-07-19 International Business Machines Corporation Multi-part encrypted messages for support of sensitive systems
CN106170246A (zh) 2014-01-17 2016-11-30 阿特瑞斯公司 用于四维(4d)流磁共振成像的设备、方法和产品
US10331852B2 (en) 2014-01-17 2019-06-25 Arterys Inc. Medical imaging and efficient sharing of medical imaging information
US10803466B2 (en) 2014-01-28 2020-10-13 3M Innovative Properties Company Analytic modeling of protected health information
US10049185B2 (en) * 2014-01-28 2018-08-14 3M Innovative Properties Company Perfoming analytics on protected health information
CA2938437A1 (en) 2014-01-31 2015-08-06 Quick Response Lifescan, Llc System and method for communicating protected health information
WO2015123540A1 (en) 2014-02-14 2015-08-20 Optum, Inc. Clinical population analytics and healthcare user interface and incentives
US9503432B2 (en) 2014-04-04 2016-11-22 Privacy Analytics Inc. Secure linkage of databases
US9613190B2 (en) 2014-04-23 2017-04-04 Intralinks, Inc. Systems and methods of secure data exchange
US9824193B2 (en) * 2014-07-29 2017-11-21 Aruba Networks, Inc. Method for using mobile devices with validated user network identity as physical identity proof
US10216902B2 (en) * 2014-08-31 2019-02-26 General Electric Company Methods and systems for improving connections within a healthcare ecosystem
US20160085915A1 (en) 2014-09-23 2016-03-24 Ims Health Incorporated System and method for the de-identification of healthcare data
US20150149362A1 (en) * 2015-02-04 2015-05-28 vitaTrackr, Inc. Encryption and Distribution of Health-related Data
US20150161413A1 (en) * 2015-02-16 2015-06-11 vitaTrackr, Inc. Encryption and distribution of health-related data
CA3007791A1 (en) 2015-02-19 2016-08-25 Doc Buddy, Inc. Coordinated mobile access to electronic medical records
US20160300223A1 (en) 2015-04-08 2016-10-13 Portable Data Corporation Protected data transfer across disparate networks
US10600506B2 (en) 2015-05-13 2020-03-24 Iqvia Inc. System and method for creation of persistent patient identification
US20160350482A1 (en) 2015-05-27 2016-12-01 University Of Utah Research Foundation Agent for healthcare data application delivery
US11599672B2 (en) 2015-07-31 2023-03-07 PME IP Pty Ltd Method and apparatus for anonymized display and data export
CN108603922A (zh) 2015-11-29 2018-09-28 阿特瑞斯公司 自动心脏体积分割
CN108431817B (zh) 2015-11-29 2022-09-16 阿特瑞斯公司 医学成像和医学成像信息的高效共享
US10600184B2 (en) 2017-01-27 2020-03-24 Arterys Inc. Automated segmentation utilizing fully convolutional networks
KR101981583B1 (ko) 2017-02-27 2019-05-23 재단법인 아산사회복지재단 의료영상 내 정보처리방법
US11688495B2 (en) 2017-05-04 2023-06-27 Arterys Inc. Medical imaging, efficient sharing and secure handling of medical imaging information
WO2019103913A1 (en) 2017-11-22 2019-05-31 Arterys Inc. Systems and methods for longitudinally tracking fully de-identified medical studies
JP7475344B2 (ja) 2018-11-21 2024-04-26 アーテリーズ インコーポレイテッド 保護された健康情報を追跡し、それにアクセスし、それをマージするためのシステムおよび方法

Also Published As

Publication number Publication date
US10869608B2 (en) 2020-12-22
EP4332603A2 (en) 2024-03-06
US12171537B2 (en) 2024-12-24
JP2018536488A (ja) 2018-12-13
US20250064334A1 (en) 2025-02-27
US20180256041A1 (en) 2018-09-13
WO2017091835A3 (en) 2017-07-27
CN108601552A (zh) 2018-09-28
JP6828034B2 (ja) 2021-02-10
US20210085195A1 (en) 2021-03-25
JP2021077389A (ja) 2021-05-20
EP3380971A1 (en) 2018-10-03
EP3380008A4 (en) 2019-08-14
EP3380008A2 (en) 2018-10-03
US20230270346A1 (en) 2023-08-31
US11633119B2 (en) 2023-04-25
CN108431817A (zh) 2018-08-21
US12161451B2 (en) 2024-12-10
US20230284924A1 (en) 2023-09-14
JP2018538050A (ja) 2018-12-27
EP4332603A3 (en) 2024-05-22
EP3380008B1 (en) 2020-09-09
EP3380971A4 (en) 2019-08-07
US20180256042A1 (en) 2018-09-13
WO2017091835A2 (en) 2017-06-01
CN108431817B (zh) 2022-09-16
CN108601552B (zh) 2021-04-09
EP3380971B1 (en) 2024-01-03
JP6871250B2 (ja) 2021-05-12
WO2017091834A1 (en) 2017-06-01
JP7046240B2 (ja) 2022-04-01

Similar Documents

Publication Publication Date Title
ES2970825T3 (es) Imágenes médicas e intercambio eficiente de información de imágenes médicas
US20250232852A1 (en) Systems and methods for tracking, accessing and merging protected health information
US12272435B2 (en) Medical imaging, efficient sharing and secure handling of medical imaging information
US11515032B2 (en) Medical imaging and efficient sharing of medical imaging information
US20250022575A1 (en) Systems and methods for longitudinally tracking fully de-identified medical studies
US10089752B1 (en) Dynamic image and image marker tracking