JP7171645B2 - Method for displaying multimodality medical data using multimodality medical processing system and multimodality medical system - Google Patents

Description

TECHNICAL FIELD Embodiments of the present disclosure relate generally to the field of medical devices, and more specifically to multi-modality selection archiving systems and methods.

Innovation in diagnosing and validating the level of success of disease treatment is moving from an external imaging process to an internal diagnostic process. Specifically, diagnosing devices and methods detect vascular occlusions and other vessels with microminiature sensors placed on the distal end of a flexible elongated member, such as a catheter or guidewire used in catheterization procedures. It has been developed to diagnose structural diseases. For example, known medical sensing techniques include angiography, intravascular ultrasound (IVUS), forward-looking IVUS (FL-IVUS), fractional flow reserve (FFR) measurements, fractional coronary flow reserve (CFR) measurements, Includes optical coherence tomography (OCT), transesophageal echocardiography, and image-guided therapy. Each of these techniques may be better suited to different diagnostic situations. To increase the likelihood of successful treatment, medical facilities have a number of on-hand modalities in imaging, treatment, diagnostic, and catheter labs during procedures. Traditionally, when a patient undergoes multiple procedures associated with different modalities, it may be necessary to enter identifying information about the patient for each of the different modalities. In other words, the same patient information may have to be entered multiple times. Such duplication of efforts can lead to clerical errors and wasted resources. Additionally, patient diagnostic discrepancies can be caused by each modality maintaining separate patient charts for the same patient.

Additionally, the data associated with each medical modality is traditionally acquired and managed in different hardware or software systems. As a result, the physician can review the data set associated with the first medical modality on a separate system from the data set associated with the second, different medical modality. Transferring between systems to review data obtained from the same patient is inefficient and can lead to inaccurate diagnoses. Additionally, archival mechanisms and archival storage locations may differ between different modality acquisition systems. For example, a patient's IVUS data may be archived in a different location and in a different format than the same patient's OCT data, making data acquisition inefficient and cumbersome.

Additionally, when archived medical data is used for educational and other non-diagnostic purposes, it typically removes any information that could identify the patient from whom the data was obtained. Traditionally, removal of identifying information prior to archiving is performed by a technician who manually removes patient data from selected fields. Such anonymized data is often error prone and often does not result in all identifying information being removed.

Thus, while existing case management systems and methods have generally been adequate for their intended purposes, they have not been entirely satisfactory in all respects.

SUMMARY In general, the present disclosure is directed to selectively archiving patient data in a multimodality medical processing system. The methods and systems described herein selectively archive medical data at the patient case level, at the modality dataset level, and/or at the individual image level, thereby allowing physicians to view archived specific data. have fine-grained control over Additionally, data sets for different medical modalities may be archived concurrently, and patient cases corresponding to different patients may be archived concurrently to increase archiving efficiency.

In one exemplary aspect, the present disclosure is directed to a method of selectively archiving medical data associated with a patient using a multimodality medical processing system. The method includes receiving first medical data obtained from a patient from a first medical device, the first medical data associated with a first medical modality; and patient data from a second medical device. receiving second medical data obtained from the second medical data associated with a second medical modality that is different from the first medical modality; The method also includes displaying on a user interface selectable representations of the first medical data and the second medical data; receiving user selection of the one or more selectable representations; and receiving archive requests via a user interface. Additionally, the method includes archiving medical data corresponding to the selected one or more selectable representations at an archive location in response to receiving the archive request.

In another exemplary aspect, the present disclosure is directed to a multimodality medical processing system. The system includes a non-transitory computer-readable storage medium that stores a plurality of instructions for execution by at least one computer processor. The instructions include receiving first medical data obtained from a patient from a first medical device, the first medical data being associated with a first medical modality; and patient data from a second medical device. receiving second medical data obtained from a second medical modality, said second medical data being associated with a second medical modality different from said first medical modality. The instructions also display on a user interface selectable representations of the first medical data and the second medical data; receive user selection of one or more of the selectable representations; and receiving an archive request via said user interface. Additionally, the instructions relate to archiving medical data corresponding to the selected one or more selectable representations to an archive location in response to receiving an archive request.

In yet another exemplary aspect, the present disclosure is directed to a method of selectively archiving medical data associated with a patient using a multimodality medical processing system. The method includes maintaining a first patient case corresponding to a first patient, the first patient case including multimodality medical data obtained from the first patient; and corresponding to a second patient. maintaining a second patient case, said second patient case comprising multimodality medical data obtained from said second patient. The method also includes displaying on a user interface selectable representations of the first medical data and the second medical data; receiving user selection of the one or more selectable representations; and receiving archive requests via a user interface. Further, the method includes archiving multimodality medical data within the patient case corresponding to the selected one or more selectable representations to an archive location in response to receiving the archive request. .

In another context, the disclosure relates to anonymizing patient data in a multimodality medical processing system. The methods and systems described herein automatically remove from medical data information that can identify the patient from which it was obtained to protect patient privacy. Specifically, anonymization occurs without human intervention to limit the deletion of errors or incomplete information. Additionally, data sets for different medical modalities may be anonymized simultaneously, and multiple patient cases corresponding to different patients may be anonymized simultaneously to increase efficiency.

In one exemplary aspect, the present disclosure is directed to a method of anonymizing medical data obtained from a patient in a multimodality medical processing system. The method includes receiving first medical data obtained from the patient from a first medical device, the first medical data associated with a first medical modality; the patient from a second medical device. receiving second medical data obtained from a second medical data associated with a second medical modality different from said first medical modality; and combining said first and second medical data with said adding to a patient case corresponding to a patient, the patient case including identifying information about the patient; The method further comprises displaying a selectable representation of the patient case on a user interface, receiving a user selection of the selectable representation, and an anonymization request from a user via the user interface. including receiving The method also includes deleting identifying information from the patient case in response to receiving the anonymization request, the deletion being independent of the user, and At least some of the identifying information is hidden from the user during the time.

In another exemplary aspect, the present disclosure is directed to a multimodality medical processing system. The system includes a fixed computer-readable storage medium that stores a plurality of instructions for execution by at least one computer processor. The instructions are to receive first medical data obtained from the patient from a first medical device, the first medical data associated with a first medical modality; and from a second medical device. receiving second medical data obtained from said patient, said second medical data being associated with a second medical modality different from said first medical modality. The instructions also add the first and second medical data to a patient case corresponding to the patient, the patient case including identifying information about the patient; displaying a selectable representation; and receiving user selection of said selectable representation. Further, the instructions are: receiving an anonymization request from a user via the user interface; and, in response to receiving the anonymization request, removing identifying information from the patient case, is impervious to said user, and during this deletion at least some of said identifying information is hidden from said user.

In yet another exemplary aspect, the present disclosure is directed to another method of anonymizing medical data in a multimodality medical processing system. The method includes receiving first medical data obtained from a first patient from a first medical device; adding the first medical data to a first patient case corresponding to the first patient. receiving medical data obtained from a second patient from a second medical device, said second patient comprising said first patient case; different from the first patient; and adding the second medical data to a second patient case corresponding to the second patient, the second patient case having identifying information about the second patient. include; The method also includes displaying on a user interface selectable representations of the first and second patient cases, receiving user selection of both selectable representations, and via the user interface including receiving anonymization requests through The method also includes, in response to receiving the anonymization request, deleting the first and second identifying information from each of the first and second patient cases, the deletion from the user It is unaffected and the first or second identifying information is hidden from the user during this deletion.

In another context, the present disclosure is directed to displaying patient medical data in a multimodality medical processing system. The methods and systems described herein present medical data in multiple different modalities on a single user interface screen so that physicians viewing the user interface can be associated with patients regardless of modality. Allows to manage all acquired datasets. In this way, it reduces the amount of time a physician must spend reviewing a patient's medical data, leading to more efficient diagnosis and treatment. Additionally, multiple patient cases corresponding to different patients may be presented on a single user interface screen to simplify management of multiple patient cases.

In one exemplary aspect, the present disclosure is directed to a method of displaying multimodality medical data using a multimodality medical processing system. The method includes receiving first medical data obtained from a patient from a first medical device, the first medical data associated with a first medical modality; receiving second medical data obtained from the patient from a second medical device, wherein the second medical data is stored in a second medical modality different from the first medical modality; and storing said second medical data in said data repository. The method also includes displaying on a user interface selectable representations of each of the first medical data and the second medical data; user selection of the selectable representations of the first medical data; and displaying the first medical data at the user interface in response to receiving the user selection.

In another exemplary aspect, the present disclosure is directed to a multimodality medical processing system. The system includes a data repository and a fixed computer-readable storage medium that stores a plurality of instructions for execution by at least one computer processor. The instructions are to receive first medical data obtained from a patient from a first medical device, the first medical data associated with a first medical modality; storing in a data repository; receiving second medical data obtained from said patient from a second medical device, said second medical data being a second medical care different from said first medical modality; associated with a modality; and storing said second medical data in said data repository. The instructions also display, on a user interface, selectable representations of each of the first medical data and the second medical data; user selection of the selectable representations of the first medical data; and displaying the first medical data at the user interface in response to receiving the user selection.

In yet another exemplary aspect, the present disclosure is directed to another method of displaying multimodality medical data using a multimodality medical processing system. The method includes retaining a first patient case corresponding to a first patient, the first patient case being associated with a first medical modality and a first data set associated with the first medical modality. includes a second data set associated with a different second medical modality; and retaining a second patient case corresponding to a second patient, said second patient case from said second patient including medical data obtained; The method also includes, on a user interface, displaying selectable representations of each of the first patient case and the second patient case; a first user of selectable representations of the first patient case; receiving a selection; and, in response to receiving the first user selection, displaying selectable representations of each of the first data set and the second data set on the user interface. including; The method also includes receiving a second user selection of a selectable representation of the first data set; and, in response to receiving the second user selection, on the user interface the first displaying a data set;

In another context, the present disclosure is directed to managing and storing patient data in a multimodality medical processing system. The methods and systems described herein store all medical data obtained from a patient in a single patient record that is assigned a unique identifier. For example, (i) patient identification, (ii) data acquired during a first diagnostic procedure, and (iii) data acquired during a second, separate diagnostic procedure are all the same. It can be stored in association with a unique identifier to simplify patient case review and retrieval. An aspect of this is that only identifying patient information, such as the patient's name and date of birth, needs to be entered into the disclosed system at a single time, which is subject to clerical error. reduce sexuality.

In one exemplary aspect, the present disclosure is directed to a method of multimodality medical case management in a multimodality medical processing system. The method includes receiving identifying information about a patient, generating a unique identifier corresponding to the patient, and associating the unique identifier with the identifying information. The method also includes, at the multimodality medical processing system, receiving first medical data obtained from the patient from a first medical device, the first medical data for a first medical modality. and storing said first medical data in a data repository, said first medical data being associated with said unique identifier in said data repository. The method further includes receiving, at the multimodality medical processing system, second medical data obtained from the patient from a second medical device, the second medical data being transmitted from the first medical modality. and storing said second medical data in said data repository, said second medical data being associated with said unique identifier in said data repository; include.

In another exemplary aspect, the present disclosure is directed to a multimodality medical processing system. The system includes a data repository and a fixed computer-readable storage medium that stores a plurality of instructions for execution by at least one computer processor. The instructions relate to receiving identifying information about a patient, generating a unique identifier corresponding to the patient, and associating the unique identifier with the identifying information. The instructions also receive first medical data obtained from the patient from a first medical device communicatively coupled with the multimodality medical processing system, the first medical data associated with a medical modality; and storing said first medical data in said data repository, said first medical data being associated in said data repository with said unique identifier. Further instructions are to receive second medical data obtained from the patient from a second medical device communicatively coupled to the multimodality medical processing system, the second medical data associated with a second medical modality different from the one medical modality; and storing said second medical data in said data repository, wherein said second medical data is stored in said data repository with said unique identifier. associated with; relating to

In yet another exemplary aspect, the present disclosure is directed to a multimodality medical processing system. The system includes a computing system communicatively connected to a first medical device and a second medical device. A computing system comprising: a user interface component configured to receive identifying information about a patient; a first medical data acquired from the patient from the first medical device; a modality workflow component of a modality workflow component, wherein the first medical data is in a first medical modality; and a second medical data obtained from the patient from the second medical device; a modality workflow component, wherein said second medical data is in a second medical modality different from said first medical modality. The computer system also includes a multimodality case management (MMCM) workflow component configured to associate the identifying information, the first medical data and the second medical data with a unique identifier; a data repository configured to store one medical data and said second medical data in association with said unique identifier.

1 is a schematic diagram illustrating a medical system including a multimodality processing system according to one embodiment of the present disclosure; FIG. FIG. 2 is a functional block diagram of portions of a medical system, including a processing framework implemented in one embodiment of the multimodality processing system. FIG. 3A is a functional block diagram of portions of the processing framework of FIG. 2, said portions being associated with multimodality case management. FIG. 3B shows a specific patient case with a unique identifier at each hierarchical data level. 4 is a simplified flow diagram of patient case management within the multimodality processing system of FIG. 1, according to aspects of the present disclosure; FIG. FIG. 5 is an illustration of various screens of a case management user interface rendered by the multimodality processing system of FIG. FIG. 6 is an illustration of various screens of a case management user interface rendered by the multimodality processing system of FIG. FIG. 7 is an illustration of various screens of a case management user interface rendered by the multimodality processing system of FIG. FIG. 8 is an illustration of various screens of a case management user interface rendered by the multimodality processing system of FIG. FIG. 9 is an illustration of various screens of a case management user interface rendered by the multimodality processing system of FIG. FIG. 10 is an illustration of various screens of a case management user interface rendered by the multimodality processing system of FIG. FIG. 11 is an illustration of various screens of a case management user interface rendered by the multimodality processing system of FIG. FIG. 12 is an illustration of various screens of a case management user interface rendered by the multimodality processing system of FIG. 13 is an illustration of various screens of a case management user interface rendered by the multimodality processing system of FIG. 1; FIG. FIG. 14 is a simplified flow diagram illustrating archiving and anonymizing patient medical data within the multimodality processing system of FIG. FIG. 15 is an illustrative archive screen of the case management user interface rendered by the multimodality processing system of FIG.

For the purposes of promoting an understanding of the principles of the disclosure, reference will be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It should nevertheless be understood that no limitation of the scope of the disclosure is intended. Any changes or further modifications to the described devices, systems, and methods, and further applications of the principles of the disclosure, may be incorporated entirely within the disclosure, as would normally occur to those skilled in the art to which this disclosure pertains. intended to and encompassed by
In particular, it is fully contemplated that features, components and/or steps described with respect to one embodiment may be combined with features, components and/or steps described with respect to other embodiments of the disclosure. . However, for the sake of brevity, the multiple iterations of these combinations are not described individually.

FIG. 1 is a schematic diagram illustrating a medical system 100 including a multimodality processing system 101 according to one embodiment of the present disclosure. In general, the medical system 100 may be amenable to various methods used to acquire and interpret human biological, physiological and morphological information and coordinate treatments for various conditions. Provides consistent integration and enhancement of multiple forms of specially designed acquisition and processing elements. More specifically, in system 100, multimodality processing system 101 is an integrated device for acquiring, managing, interpreting, and displaying multimodality medical sensing data. In one embodiment, processing system 101 is a computer system having hardware and software for acquiring, processing, and displaying multimodality medical data, while in other embodiments, processing system 101 includes: It may be any other type of computing system operable to process medical data. In embodiments where processing system 101 is a computer workstation, the system includes a microcontroller or dedicated central processing unit (CPU), and fixed computer-readable storage media such as a hard disk drive, random access memory (RAM) and and/or a compact disk read-only memory (CD-ROM), and at least a processor such as a video controller, such as a graphics processing unit (GPU), and a network communication device, such as an Ethernet controller or a wireless communication controller. In that regard, in some particular examples, processing system 101 is programmed to perform procedures associated with data acquisition and analysis described in this disclosure. Accordingly, procedures associated with data acquisition, data processing, instrument control, and/or other processing or management aspects of the present disclosure may be stored on or within a fixed computer-readable storage medium accessible by said processing system. may be implemented by a processing system using corresponding instructions stored in the . In some examples, the processing system 101 is portable (eg, handheld, on a transport cart, etc.). Further, it is understood that in some examples, processing system 101 comprises multiple computing devices. In that regard, it is specifically understood that different processing and/or management aspects of the present disclosure may be implemented using multiple computing devices, either separately or within predefined groups. Any division and/or combination of the processing and/or management aspects described below across multiple computing devices are within the scope of the present disclosure.

In the illustrated embodiment, the medical system 100 is deployed in a catheter lab 102 having a control room 104 with a processing system 101 located in the control room. In other embodiments, the processing system 101 may be located at other locations, such as a catheter lab 102, a centralized area within a medical facility, or an off-site location (ie, in the cloud). The catheter lab 102 generally includes a sterile field that covers the procedure area, while its associated control room 104 may or may not be sterile, depending on the requirements of the procedure and/or medical facility. good. Catheter laboratories and control rooms provide patients with a variety of medical detection procedures, such as angiography, intravascular ultrasound (IVUS), virtual histology (VH), forward-looking IVUS (FL-IVUS), intravascular photoacoustic (IVPA). ) imaging, fractional flow reserve (FFR) measurement, fractional instantaneous flow reserve (iFR) measurement, X-ray angiography (XA) imaging, fractional coronary flow reserve (CFR) measurement, optical coherence tomography (OCT ), computed tomography, intracardiac ultrasound (ICE), forward-looking ICE (FLICE), intravascular palpography, transesophageal ultrasound, or any other medical sensing modality known in the art. can be used for In addition, catheter laboratories and administrative offices perform one or more treatments or therapeutic procedures on patients, such as radiofrequency ablation (RFA), cryotherapy, atherectomy, or any other medical procedure known in the art. can be used for For example, at the catheter lab 102, the patient 106 can undergo a multimodality procedure, either in a single procedure or in combination with one or more detection procedures. In any case, catheter lab 102 includes a plurality of medical equipment including medical sensing devices capable of collecting medical sensing data from patient 106 at a variety of different medical sensing modalities.

In the embodiment shown in FIG. 1, instruments 108 and 110 are medical sensing devices that can be utilized by clinicians to obtain medical sensing data about patient 106 . In a particular example, device 108 collects medical detection data in one modality and device 110 collects medical detection data in a different modality. For example, the instruments may, respectively, pressure, flow rate (flow rate), images (including images obtained using ultrasound (e.g., IVUS), OCT, thermal, and/or other imaging techniques), temperature, and /or one of their combinations may be collected. Devices 108 and 110 are sized and shaped to be placed within a device, instrument, or vessel, or to be mounted externally to the patient, or to be scanned across the patient at intervals. The probe may be in any form.

In the embodiment shown in FIG. 1, device 108 is an IVUS catheter 108 that includes one or more sensors, such as a phased array transducer for collecting IVUS detection data. In some embodiments, the IVUS catheter 108 may have multi-modality detection capabilities, such as IVUS and IVPA detection. Further, in the illustrated embodiment, device 110 is an OCT catheter 110 that includes one or more optical sensors configured to collect OCT detection data. In some examples, an IVUS patient interface module (PIM) 112 and an OCT-PIM 114 connect IVUS catheter 108 and OCT catheter 110 to medical system 100, respectively. Specifically, IVUS-PIM 112 and OCT-PIM 114 are operable to receive medical sensing data collected from patient 106 by IVUS catheter 108 and OCT catheter 110, respectively, and manage the received data. It is operable to transmit to processing system 101 in room 104 . In some embodiments, PIMs 112 and 114 include analog-to-digital (A/D) converters and transmit digital data to processing system 101, while in other embodiments these PIMs convert analog data. Send to the processing system. In some embodiments, the IVUS-PIM 112 and OCT-PIM 114 transmit medical sensing data over a Peripheral Component Interconnect High Speed (PCIe) databus connection, although in other embodiments they may be USB connections, Thunderbolt The data may be sent over a (Thunderbolt) connection, a FireWire connection, or some other high speed data bus connection. In other examples, the PIM may communicate via a wireless connection using the IEEE 802.11 Wi-Fi standard, the ultra-wideband (UWB) standard, wireless FireWire, wireless USB, or another high-speed wireless network standard. It may be connected to the processing system 101 .

Additionally, in medical system 100 , electrocardiogram (ECG) device 116 is operable to transmit electrocardiogram signals or other hemodynamic data from patient 106 to processing system 101 . In some embodiments, processing system 101 is operable to synchronize data collected by catheters 108 and 110 using ECG signals from ECG 116 . Additionally, angiography system 117 is operable to acquire and transmit X-rays, computed tomography (CT), or magnetic resonance images (MRI) of patient 106 to processing system 101 . In some embodiments, angiography system 117 may be communicatively connected to processing system 101 via an adapter device. Such adapter devices can convert data from proprietary third-party formats to formats usable by processing system 101 . In some embodiments, processing system 101 combines image data (eg, X-ray data, MRI data, CT data, etc.) from angiography system 117 with detection data from IVUS and OCT catheters 108 and 110. , may be operable to register simultaneously. In one aspect, co-registration may be performed to generate a three-dimensional image using the sensed data.

Bedside controller 118 is communicatively coupled to processing system 101 and provides user control of the particular medical modality (or modalities) used to diagnose patient 106 . In the current embodiment, bedside controller 118 is a touch screen controller that provides user control and diagnostic images for a single surface. However, in alternate embodiments, bedside controller 118 may include both a non-interactive display and a separate operating device, such as physical buttons and/or joysticks. In the integrated medical system 100, the bedside controller 118 is operable to present workflow management options and patient image data in a graphical user interface (GUI). As described in more detail in connection with FIG. 2, the bedside controller 118 includes user interface (UI) framework services through which workflows associated with multiple modalities may be executed. In this manner, the bedside controller 118 organizes the workflow and diagnostic imaging for multiple modalities to allow clinicians to manage the acquisition of multimodality medical sensing data using a single interface device. can be displayed.

A main controller 120 in the control room 104 is communicatively connected to the processing system 101 and adjacent to the catheter lab 102 as shown in FIG. In the current embodiment, the main controller 120 is similar to the bedside controller 118, which includes a touch screen and, through UI framework services running on it, supports GUI-based workflows for different medical detection modalities. It is operable to display more. In some embodiments, the main controller 120 can be used to concurrently execute the workflow of different aspects of the procedure than the bedside controller 118 . In alternate embodiments, main controller 120 may include a non-interactive display and stand-alone operating devices such as a mouse and keyboard.

Medical system 100 further includes a boom display 122 communicatively connected to processing system 101 . Boom display 122 may include an array of monitors, each capable of displaying different information associated with a medical detection procedure. For example, during an IVUS procedure, one monitor in boom display 122 may display a tomographic view and another monitor may display a sagittal view.

In addition, multimodality processing system 101 is communicatively connected to data network 125 . In the illustrated embodiment, data network 125 is a TCP/IP-based local area network (LAN), but in other embodiments may be a different protocol such as Synchronous Optical Network (SONET), or It may be a wide area network (WAN). Processing system 101 may be connected to various resources via network 125 . For example, the processing system 101 may communicate with a medical Digital Imaging and Communications in Medicine (DICOM) system 126 , an image archive and communication system (PACS) 127 , a hospital information system (HIS) 128 via a network 125 . can communicate. Further, in some embodiments, network console 130 communicates with multimodality processing system 101 via network 125 to allow physicians or other medical professionals to remotely access aspects of medical system 100 . It may be possible. For example, a user of network console 130 may access patient medical data, e.g., diagnostic images acquired by multimodality processing system 101 , or in some embodiments, a user of network console 130 may access diagnostic images performed at catheter lab 102 . one or more procedures being monitored or managed in real time. Network console 130 may be any type of computing device with a network connection, such as a PC, laptop, smart phone, tablet computer, or other such device located inside or outside a healthcare facility.

Furthermore, although in the illustrated embodiment the medical detection tools of system 100 described above are shown communicatively connected to processing system 101 via wired connections, e.g., standard copper links, fiber optic links, alternative In embodiments, the tool connects to processing system 101 via a wireless connection, such as the IEEE 802.11 Wi-Fi standard, ultra-wideband (UWB) standard, wireless FireWire, wireless USB, or another high-speed wireless network standard. may be connected.

Those skilled in the art will recognize that the medical system 100 described above is merely an exemplary embodiment of a system operable to collect diagnostic data associated with multiple medical modalities. In alternative embodiments, different and/or additional tools may be communicatively coupled to processing system 101 to impart additional and/or different functionality to medical system 100 .

Turning now to FIG. 2, a functional block diagram of portions of medical system 100 including processing framework 200 executing on one embodiment of multimodality processing system 101 is shown. Process framework 200 includes various independent and dependent executable components that control the operation of processing system 101, including the acquisition, processing, and display of multimodality medical sensing data. In general, the processing framework 200 of processing system 101 is modular and extensible. That is, framework 200 is composed of independent software and/or hardware components (or extensions) each associated with a different function and medical detection modality. This modular design allows the aforementioned framework to adapt to additional medical detection modalities and functionality without impacting existing functionality or requiring changes to the underlying architecture. allow to expand. Additionally, an internal messaging system facilitates independent data communication between modules within the framework. In one example, processing framework 200 may be implemented as computer-executable instructions stored on a stationary computer-readable storage medium within processing system 10 . In other examples, processing framework 200 may be a combination of hardware and software modules executing within processing system 101 .

Generally, in the embodiment shown in FIG. 2, processing framework 200 processes medical sensing data from multiple medical sensing devices; process data; or diagnostic images via main controller 120, bedside controller 118, or other graphical display device. a plurality of components configured to receive output data as; Framework 200 includes several system-level components that manage the core system functions of processing system 101 and organize multiple modality-specific components. For example, framework 200 includes a system controller 202 that coordinates startup and shutdown of the executable components of processing framework 200, including hardware and software modules associated with acquiring and processing patient diagnostic data. System controller 202 is also configured to monitor the status of components executing within framework 202, for example, to determine if any components have unexpectedly stopped executing. In addition, system controller 202 provides an interface through which other framework components can obtain system configuration and status information. Because the software framework 200 is modular, the system controller 202 is independent of the components within the framework that it manages, so that errors and changes made to the components can affect the execution or structure of the system controller. will not affect

As noted above, framework 200 is configured so that various extensions can be added and removed without changing the system architecture. In certain embodiments, an extension executing within framework 200 may include multiple executable components that together implement the complete functionality of the extension. In such embodiments, an extension may include an extension controller, similar to system controller 202, operable to launch, terminate, and monitor various executable components associated with the extension. For example, at system start-up, the system controller 202 can initiate an augmentation controller corresponding to a medical modality, which in turn may initiate executable components associated with the modality. In some embodiments, the expansion controller may not assign specific modalities or other system tasks until the system controller 202 associates them with a particular modality or other system tasks via a configuration mechanism, eg, parameters obtained as a configuration file.

Process framework 200 generally includes a workflow controller component 204 configured to govern the execution of executable components of framework 202 during a multimodality medical detection workflow. Workflow controller component 204 can orchestrate the workflows executed by processing framework 200 in a variety of different ways.

Processing framework 200 includes an event log component 206 configured to log messages received from various components of the processing framework. For example, during system startup, system controller 202 can send messages regarding the status of started components to event log component 206, which in turn writes the messages to a log file in a standardized format. Additionally, processing framework 200 is configured to manage the sharing of limited system resources between various executable components of framework 202 during multimodality medical detection and/or treatment workflows. Includes resource arbiter component 208 . For example, during a multimodality workflow, two or more components associated with different modalities within processing framework 202 may compete for the same system resources, such as a graphical display on main controller 120 . The resource arbiter component 208 can orchestrate sharing of limited system resources in various ways, for example, through a locking system, a queuing system, or a hierarchical collision management system.

In some embodiments, system controller 202, workflow controller component 204, event log component 206, and resource arbiter component 208 may be implemented as processor-executable software stored on a fixed computer-readable storage medium. , in alternative embodiments, these components may be implemented as hardware components such as special purpose microprocessors, field programmable gate arrays (FPGAs), microcontrollers, graphics processing units (GPUs), digital signal processors (DSPs). can be implemented. Alternatively, the components of the processing framework may be implemented as a combination of hardware and software. In certain embodiments where executable components are implemented in FPGAs, system controller 202 is configured to dynamically change programmable logic within FPGAs to implement various functions required at that time. may As such, processing system 101 may include one or more unassigned FPGAs that may be assigned by the system controller during system startup. For example, if a system controller detects an OCT-PIM and its associated catheter at startup of the processing system 101, this system controller, or an expansion controller associated with OCT functionality, is programmed in one of the unassigned FPGAs. Logic can be dynamically transformed so that it includes functionality for receiving and/or processing OCT medical data.

To facilitate intersystem communication between different hardware and software components in multimodality processing system 101 , processing framework 200 further includes message delivery component 210 . In some embodiments, message delivery component 210 is configured to receive messages from components within framework 202, determine the intended goal of the message, and deliver the message in a timely manner ( That is, the message delivery component is an active participant in the delivery of messages). In such embodiments, message metadata may be generated by this transmission component, which may include destination information, payload data (e.g., modality type, patient data, etc.), priority information, timing information, or including other such information. In another embodiment, message delivery component 210 receives messages from components within framework 202, temporarily stores the messages, and utilizes the messages for retrieval by other components within the framework. (ie, the message delivery component is a passive queue). In any case, message delivery component 210 facilitates communication between executable components in framework 200 . For example, the system controller 202 utilizes the message delivery component 210 to examine the state of the components that start up during the system startup sequence, and, with respect to this received state information, utilizes the message delivery component to read the state information. to the event log component 206, which allows it to write to a log file. Similarly, resource arbiter component 208 can utilize message delivery component 210 to pass resource tokens between components requesting access to limited resources.

In one embodiment, where message delivery component 210 is a passive queue, components of framework 200 may cause incoming medical sensing data to be packetized into messages and other components, such as image The message can be sent to a queue of message delivery components that can be retrieved by a data processing component. Further, in some embodiments, message delivery component 210 receives messages on a first-in-first-out (FIFO) basis, where the first message arriving in the queue first deletes the first queue. It is operable to make messages available. In alternate embodiments, the message delivery component 210 can make messages usable in different ways, for example, depending on the priority value stored in the message header. In some embodiments, message delivery component 210 is implemented in random access memory (RAM) in processing system 101, although in other embodiments it is non-volatile RAM (NVRAM), secondary storage (e.g., magnetic physical hard drive, flash memory, etc.), or network-based storage. Additionally, in some embodiments, messages stored in message delivery component 210 can be accessed by software and hardware modules in processing system 101 using direct memory access (DMA).

Process framework 202 also includes a number of additional system components that provide core system functionality, including security component 212, multimodality case management (MMCM) component 214, and database management component 216. . In certain embodiments, security component 212 is configured to provide various security services to the overall processing framework as well as individual components. For example, a component implementing an IVUS data acquisition workflow utilizes cryptographic application programming interfaces (APIs) exposed by the security component 212 to capture IVUS data before it is sent over a network connection. May be encrypted. In addition, security component 212 can provide other security services, such as system-level authentication and authorization services to limit access to the processing framework to qualified users, and is extensible. Execution of untrusted components within the framework can be prevented. A multimodality case management (MMCM) component 214 is configured to organize and enrich diagnostic data associated with multiple medical modalities into a unified patient chart that can be more easily managed. Such unified patient charts can be stored in databases more efficiently and are better suited for data archiving and retrieval. In that regard, database management component 216 is configured to provide database services transparent to other components of framework 200, and database connection and management details are hidden from said other components. For example, in one particular embodiment, database management component 216 may expose APIs containing database storage and search functionality to components of framework 200 . In other words, the medical detection workflow component may be able to send diagnostic data to local and/or remote databases, such as DICOM or PACS servers, via the database component without being aware of database connection details. . In other embodiments, the database management component 216 may be operable to perform additional and/or different database services, such as data formatting services that prepare diagnostic data for database archiving.

As noted above, the processing framework 200 of the multimodality processing system 101 is operable to receive and process medical data associated with multiple modalities. In this regard, processing framework 200 includes modular acquisition and workflow components associated with different medical detection and diagnostic modalities, respectively. For example, as shown in the embodiment illustrated in FIG. 2, processing framework 200 includes IVUS acquisition components 220 each configured to receive and process IVUS medical detection data from IVUS-PIM 112. and IVUS workflow component 222 . Modality 'N' acquisition components 224 and modalities 'N' acquisition components 224 and modalities 'N' PIMs 228 acquire and process data from modality 'N' PIMs 228, in accordance with the modularity and extensibility of processing framework 200. It may also be added to the framework independently, as indicated by the 'N' workflow component 226 . For example, in certain embodiments, processing system 101 may be communicatively connected to OCT-PIM 114, ECG system 116, fractional flow reserve (FFR)-PIM, FLIVUS-PIM, and ICE-PIM. . In other embodiments, additional and/or different medical detection, treatment, or diagnostic devices may be connected to processing system 101 via additional and/or different data communication connections known in the art. good. In such a scenario, in addition to IVUS-acquisition module 220, process framework 200 includes an FFR acquisition component for receiving FFR data from FFR-PIMs, a FLIVUS acquisition component for receiving FLIVUS data from FLIVUS-PIMs. , an ICE acquisition component for receiving ICE data from the ICE-PIM, and an OCT acquisition component operable to receive OCT data from the OCT-PIM. In this context, medical data communicated between executable components of processing framework 200 and communicatively connected medical devices (e.g., PIMs, catheters, etc.) may include data collected by sensors, control signals, Power levels, device feedback, and other medical data regarding detection, treatment or diagnostic procedures may also be included. Further, in certain embodiments, patient treatment devices may be communicatively connected to the processing system 101, such as radiofrequency ablation (RFA), cryotherapy, or atherectomy and any PIM or such. It may be a device associated with other controls associated with the treatment procedure. In such embodiments, modality 'N' acquisition component 224 and modality 'N' workflow component 226 are located on the treatment device, e.g., by relaying control signals, by relaying power levels, by receiving device feedback. Receipt of data collected by the sensors can be configured to communicate with and manage the treatment device.

In an embodiment, once acquisition components 220 and 224 receive data from connected medical sensing devices, they packetize the data into messages to facilitate communication between systems. Specifically, the component may be operable to create a plurality of messages from the input digital data stream, each message including digitized medical detection data and a portion of the header. The message header contains metadata associated with the medical detection data contained within the message. Further, in some embodiments, acquisition components 220 and 224 somehow process the digitized medical detection data before it is communicated to other portions of framework 200 . may be operable to manipulate the For example, the acquisition component compresses the detected data to normalize, scale, or otherwise filter the data to make communication between systems more efficient or to aid post-processing of the data. may In some embodiments, this manipulation may be modality specific. For example, the IVUS-acquisition component 220 may identify and discard redundant IVUS-data before it is passed on to subsequent steps to save processing time. The acquisition components 220 and 224 may additionally perform a number of tasks related to data acquisition, including responding to interrupts generated by a data bus (e.g., PCIe, USB); detecting if a medical sensing device is connected to the processing system 101; obtaining information about the connected medical sensing device; storing sensing device specific data; and allocating resources to the database. be done. As noted above, the data acquisition components are independent of each other and can be installed or removed without interrupting data acquisition by other components. In addition, the acquisition component is independent of the underlying databus software layer (e.g., through the use of APIs) and by third parties to facilitate acquisition of data from third party medical sensing devices. It may be created.

The workflow component of the processing framework, eg, IVUS workflow component 222 , receives raw medical detection and/or diagnostic data from each acquisition component via message delivery component 210 . In general, the workflow component starts and stops data collection, e.g., at calculated times, displays acquired and processed patient data, and facilitates analysis of acquired patient data by a clinician. and the like to manage the acquisition of medical detection data. As this aspect, the workflow component is operable to convert raw medical data collected from a patient into a diagnostic image or other data format that allows a clinician to assess the patient's condition. be. For example, the IVUS workflow component 222 can interpret IVUS data received from the IVUS-PIM 112 and convert the data into human-readable IVUS images. In some embodiments, the software stack within the framework, when called by workflow component 222 and other said workflow components of the framework to access system resources, e.g., computer resources, message delivery component 210, and communication resources. A set of APIs may be published for use. After processing the acquired data, the modality-centric workflow component sends one or more messages containing this processed data to other components within framework 200 via message delivery component 210. You may In some embodiments, before sending such a message, the component may insert a flag into the header indicating that the message contains processed data. Further, in some embodiments, after processing medical detection data, such component utilizes database management component 216 to store such processed data in an archive system, such as a locally attached mass storage device. Or it can be sent to a network-based PACS server 127 . According to the modular structure of process framework 200, workflow components 222 and 226 are independent of each other and can be installed or removed without disrupting other components, and may be written by third parties. . Moreover, their independence allows these components to be operable to simultaneously process signaling and imaging data from multiple medical sensing devices.

Process framework 200 is further adapted to acquire and process data from any number of data collection tools 234 and to pass this acquired data through one of the other acquisition components within the framework. includes a co-registration interface component 230 and a co-registration workflow component 232 configured to co-register with the data obtained. More particularly, co-registration interface component 230 is operable to communicatively interface with any number of modalities, such as medical data acquisition tools associated with ECG device 116 or angiography system 117 of FIG. can be done. In certain embodiments, interface component 230 may be operable to standardize and/or transform incoming modality data such that the data is acquired by processing system 101 in other modalities. can be simultaneously registered with the detection data of As the medical data is to be acquired by the co-registration interface component 230, the co-registration workflow component 232 can, for example, spatially or temporally synchronize data collection among medical sensing devices and By aligning two or more acquired data sets based on the historical and temporal registration markers and co-registered diagnostic images or allowing a clinician to assess patient status, a human It is configured to facilitate co-registration of data from different modalities by generating other readable data. Furthermore, in other embodiments, the co-registration workflow component 232 uses previously acquired 2-D images or 3-dimensional models to perform catheter acquisition in two-dimensional (2-D) or three-dimensional (3-D) space. The data may be operable to spatially co-register. For example, a catheter-based detection tool may include fiducials that are tracked to generate position data during a detection procedure, and the co-registration workflow component 232 compares this position data to previously acquired MRI data. Data can be registered. Additionally, co-registration workflow component 232 can facilitate co-registration of multi-modality data acquired by native acquisition components within framework 200, such as IVUS acquisition component 220 and modality 'N' acquisition component 224 of interest. . Additionally, in some embodiments, a real-time clock may be incorporated into the co-registration workflow component 232 .
U.S. Provisional Patent Application No. 61/473,591, entitled "Distributed Medical Detection System and Method," discloses in greater detail temporal synchronization of medical detection data collection, and is incorporated herein in its entirety by Incorporated by reference.

As described above in connection with FIG. 1, a clinician utilizing processing system 101 can manage workflow and review diagnostic images through main controller 120 and bedside controller 118 . The main controller 120 and bedside controller 118 include user interface (UI) framework services 240 and 242, respectively, that support multiple user interface (UI) extensions (or components). In general, the UI extensions supported by UI framework services 240 and 242 correspond to and are associated with medical detection modalities, respectively, for managing acquisition workflows and for displaying processed detection data. is operable to render the user interface of Like processing framework 200, UI frameworks 240 and 242 are extensible in that they support UI extensions that are independent of each other. That is, its modular design allows UI frameworks 240 and 242 to adapt to additional medical detection modality user interfaces without impacting existing user interfaces or requiring changes to the underlying UI architecture. allows you to extend it to In the illustrated embodiment, the main controller 120 includes a system UI extension 244 that renders a user interface containing core system management and configuration options. For example, a clinician can use the user interface rendered by system UI extension 244 to start, stop, or otherwise manage processing system 101 . In some embodiments, the components of main controller 120 can be considered part of processing framework 200 . IVUS-UI extensions 246 and 248 render user interfaces for main controller 120 and bedside controller 118, respectively. For example, IVUS-UI extensions 246 and 248 may render and display touch screen buttons used to manage IVUS workflows, and render IVUS diagnostic images created by IVUS workflow component 222. and can also be displayed. Similarly, UI extensions 250 and 252 for that modality "N" render management and images associated with the workflow for that modality "N".

In some embodiments, UI framework services 240 and 242 may expose APIs that UI extensions call to access system resources, such as look and feel toolboxes and error handling resources. . The look and feel toolbox API enables the UI extension to present a standardized user interface with common buttons, parallel workflow formats, and data presentation schemes for different modality workflows of interest. In this way, clinicians can more easily transition between acquisition modalities without additional user interface training. Additionally, the co-registration UI extension can present and/or combine processed image or signaling data from multiple modalities. For example, the UI extension may display an electrocardiogram (ECG) wave adjacent to the IVUS image data, and may display the IVUS image overlaid with a border previously drawn on the OCT image. Additionally, in some embodiments, UI framework services 240 and 242 may include a multitasking framework for coordinating concurrent execution of UI extensions. For example, if processing system 101 simultaneously retrieves data associated with more than one modality, UI framework services 240 and 242 present modality selection screens to the user to select the desired user interface. good too.

UI framework services 240 communicate with components of processing framework 200 via message delivery component 210 . As shown in the embodiment shown in FIG. 2, bedside controller 118 may be communicatively coupled to processing framework 200 via network connection 254 . This network connection 254 may be any wired or wireless network connection, such as an Ethernet connection or an IEEE 802.11 Wi-Fi connection. Alternatively, one or both of the main and bedside controllers 120 and 118 may connect the processing framework 200 to a local bus connection, such as a (PCIe) data bus connection, a USB connection, a Thunderbolt connection, a FireWire connection, or any number of may communicate via any other high speed data bus connection. Further, in the embodiment shown in FIG. 2, the bedside controller is configured to facilitate message-based communication between UI extensions within the bedside controller 118 and components within the processing framework 200. , including the message delivery component 256 . In certain embodiments, message delivery component 256 may extract diagnostic image data from network communication packets as they arrive over this network connection 254 .

Process framework 200 includes additional components that allow clinicians to access and/or manage workflows executed on multimodality processing system 101 . For example, framework 200 includes remote access component 260 that communicatively connects network console 130 (FIG. 1) to processing framework 200 . In some embodiments, the remote access component 260 is operable to export management functions of the processing system 101 to the network console 130 such that the network console presents workflow management functions within its user interface. be able to. In one particular embodiment, remote access component 260 receives workflow commands from network console 130 and forwards them to remote access workflow component 262 . This remote access workflow component 262 can direct command sets and diagnostic data to a location that remote users can access via the network console 130 . In addition, legacy management component 264 and legacy management workflow component 266 provide users of legacy consoles 268 (e.g., button consoles, mice, keyboards, standalone monitors) with several levels of access to modality workflow management and data. .

In some embodiments, the core system components of processing framework 200 and additional components, such as components associated with the modality of interest, are implemented as processor-executable software stored on a fixed computer-readable storage medium. alternative embodiments, these components may be hardware components such as special purpose microprocessors, field programmable gate arrays (FPGAs), microcontrollers, graphics processing units (GPUs), digital signal It can be implemented as a processor (DSP). Alternatively, the components of the processing framework may be implemented as a combination of hardware and software.

Those skilled in the art will appreciate that the processing framework 200 of FIG. 2 is merely an exemplary embodiment, and that in alternate embodiments, the framework may include different and/or additional components for various medical applications. configured to perform a detection workflow. For example, processing framework 200 may include executable components configured to assess stenosis in human blood vessels, or executable components configured to facilitate administration of computer-assisted surgery or remotely-controlled surgery. may include

FIG. 3A now illustrates a functional block diagram of a portion of processing framework 200 associated with multimodality case management (MMCM) workflow component 214 . As described above, the multimodality case management (MMCM) component 214 is configured to organize and enrich patient medical data associated with multiple medical modalities into a unified patient chart that can be more easily managed. be done. Specifically, in the illustrated embodiment, the MMCM workflow component 214 associates unique identifiers (UIDs) with all aspects of a patient case, including medical data obtained from medical devices and patient, Contains both captured data and metadata describing the procedure (uncaptured data). A UID can be a number, an alphanumeric key, a hexadecimal value, or any other item that can be used to uniquely identify a patient. Metadata associated with the UID includes identifying information about the patient (e.g., patient name, gender, date of birth, social security number, blood type, etc.) and derived data associated with acquired medical data (measurements, vascular borders generated on internal images), annotations on the images generated from acquired medical data (vessel names, physician notes, internal structure identification, etc.), and information about procedures performed on the patient (e.g. , procedure time, procedure location, physician name, medical device used, etc.). Assigning a common unique identifier to both patient metadata and acquired data creates the strong associations needed for efficient data retrieval and analysis (i.e., measurements are performed within a single intravascular must be associated with the image; vessel name annotations must be associated with all frames of a multiframe image). Further, in the illustrated embodiment, a common unique identifier is assigned to all data acquired from a patient regardless of the modality of interest of the data. For example, a patient will typically undergo several different diagnostic procedures, which allow the physician to more fully assess the patient's condition. In that regard, data acquired during an IVUS procedure for a patient can be assigned the same UID as data acquired during an OCT procedure for the patient. In some instances, the procedure may be performed during a single cath lab session, and in other instances the procedure may be performed in multiple sessions, separated by hours, days, months, or years. may be performed between In either case, all diagnostic and/or treatment data obtained from the same patient are assigned the same unique identifier for improved patient diagnosis and, ultimately, treatment.

The MMCM workflow component 214 shown in FIG. 3A organizes the assignment of a common UID to all metadata and acquired data associated with a patient case. Specifically, the modality-specific workflow components, such as the IVUS workflow component 222 and the modality N workflow component 226, utilize the MMCM workflow component 214 to acquire from the patient using a medical device, such as a catheter-based transducer. Store medical data. In an embodiment, the MMCM workflow component 214 exposes a library of storage-related functions to the modality workflow component so that they can store and retrieve patient data from designated storage media. In this way, storage of acquired data is handled in a unified manner, rather than each modality component implementing its own storage mechanism, such as a file management mechanism and a data formatting mechanism. One aspect of this is that when the MMCM workflow component 214 receives a storage/retrieval request from a modality-specific component, it merges a single patient's set of metadata with medical data acquired from the patient across multiple different modalities. can be put together.

The MMCM workflow component 214 includes an MMCM logic component 302 that implements the storage and retrieval functions of the library called by the modality-specific component. In one embodiment, MMCM logic component 302 may be implemented as a hierarchical state machine, although in other embodiments it may be implemented as an executable file or another logical container. The MMCM logic component 302 generates unique identifiers and associates them with newly acquired data and metadata within the patient case. In some embodiments, one patient case can be "open" at a time within the processing framework 200, and the MMCM logic component 302 interprets all data acquired or entered by the physician into that case. is associated with the same study (case) UID while it is open. During diagnostic procedures that acquire data from a patient, the MMCM logic component 302 assigns the acquired data a temporary UID and stores it in the data repository 304 .
Data repository 304 may implement any type of logic data container, such as a database, and may be stored on any type of storage medium, such as a hard drive on multimodality processing system 101 or at a storage location on a network. may In one embodiment, the repository is an XML database accessed via a Shared Patient Information Management System (SPIMS). As shown in FIG. 3A, both patient metadata (eg, identification information, image annotations, etc.) and diagnostic data acquired across modalities are associated with the same UID and stored in repository 304 . For example, as shown in FIG. 3A, UID1 is associated with a patient case that includes metadata 306, IVUS data 308, OCT data 310, and modality N data 312. FIG. Those skilled in the art will appreciate that the organization of data within repository 304 is merely one example, and that all data associated with patient cases can be organized in many different ways, such as database tables, data structures, hash tables, stacks, queues, It will be appreciated that a linked list or the like can be grouped together with a UID. In one example, all data associated with a medical modality are stored together in logical data partitions, with each data set within a group of modality data associated with a UID corresponding to the patient case to which it belongs. good too. Additionally, acquired patient data may be stored in repository 304 in many different formats. For example, it may be stored in "raw" form, unchanged from the format produced by the acquiring medical device, or it may be stored in processed form, eg, as an intravascular IVUS image. As noted above, data associated with one UID may be collected over multiple clinical sessions or collected during a single session.

Further, in some embodiments, each hierarchical level of data within a patient chart has its unique identifier, such that there is a chain of unique identifiers linking all patient data together. A specific example of a patient case with a unique identifier at each data level is shown in FIG. 3B. For example, a patient case that includes all data acquired or associated with a patient can have a globally unique identifier as a patient case UID as shown in FIG. 3B. A patient case may contain one or more patient studies, each patient study containing all data collected during a catheter lab session. Each patient study may include its own unique identifier that is linked to a global patient case-specific identifier. Moreover, each patient study, in turn, can include one or more data sets (or series) composed of data for a particular medical modality. For example, a patient study may include an IVUS series, an OCT series, and an FFR series, all acquired during a single catheter lab session, each series having its own unique identifier linked to a patient study-specific identifier. has an identifier of Additionally, each dataset or series may include one or more diagnostic images, each image having its own unique identifier linked to the dataset's unique identifier. Thus, the unique identifier at each data level forms a chain of ownership linking together patient metadata, patient studies, datasets (series), and individual images within a patient case.

Additionally, the use of unique identifiers for all data contained in patient cases simplifies data management within the multimodality processing system 101 . This scheme allows portions of the entire patient case, or individual data within a patient case, to be identified and addressed. For example, when reviewing patient data by a physician, the MMCM logic component 302 uses the UID associated with that patient case to provide a single access to the repository for all acquired diagnoses, regardless of modality. data can be retrieved. Alternatively, MMCM logic component 302 can retrieve a single image using a unique identifier associated with the image. Similarly, when patient data is no longer needed, all medical data associated with a patient can be deleted at the same time, regardless of modality, using the UID associated with that patient.

Additionally, the MMCM logic component 302 can interact with the data archive component 314 when a request is made by a physician to archive patient data. Specifically, the physician may choose to archive all or part of a patient case on storage medium 316, as described in more detail in connection with FIGS. 14-15. The storage medium 316 may be removable media, such as a writable Digital Versatile Disc (DVD), a writable Blu-ray Disc, a portable flash drive, or the storage medium 316 may be a fixed type of storage, such as a local hard drive. It may be a drive, a DICOM server, or another networked archive repository. In one embodiment, in response to an archive request, MMCM logic component 302 may retrieve all data associated with the patient case from repository 304 via the corresponding UID, and then associate that data with the UID. Archived data may be sent to the data archiving component 314 . In such scenarios, restoration of archived data can be accomplished by referencing the UID. Additionally, the data archiving component 314 is configured to, upon request, anonymize data before it is archived. In embodiments, all identifying information about a patient may be removed from the patient case, but the UID may remain associated with the case to facilitate efficient data management.

The MMCM workflow component 214 includes an MMCM graphical user interface component 320 that drives user interface components associated with patient case management. Specifically, the MMCM GUI component 320 renders UI screens associated with creating new patient cases, collecting identifying information about patients, managing previously acquired modality data, and archiving patient diagnostic data.
In one aspect of this, the MMCM GUI component 320 is configured to interpret user commands entered in association with the user interface. Screens related to patient case management are sometimes collectively referred to as the case explorer. The user interface rendered by the MMCM GUI component 320 is described in detail in connection with FIGS. 4-13.

Those skilled in the art will appreciate that the aspects of the processing framework 200 associated with the MMCM workflow component 214 shown in FIG. 3A are simplified and additional and/or different components are executed within the framework for managing patient case data. you will recognize that you can. For example, MMCM logic component 302 may coordinate transmission of data to and from repository 304 utilizing one or more database communication components. Further, in some embodiments, each modality-specific workflow component can independently handle the storage of acquired diagnostic data. In such a scenario, each modality-specific workflow component queries the MMCM workflow component 214 for the UID corresponding to the currently open patient case, and stores the acquired diagnostic data with that UID in a dedicated storage container. memorize to Additionally, the MMCM workflow component 214 can store the patient's metadata in a separate MMCM storage container along with the corresponding UID.

4 is a simplified flow diagram of patient case management within the multimodality processing system 101. As shown in FIG. As mentioned above, the MMCM workflow component 214 enhances the management of patient data acquired and not acquired within the multimodality processing system 101 . The MMCM Workflow Controller 214 controls and manages both the front-end user interface and back-end data storage. The front end user interface includes a number of screens to efficiently guide the practitioner through the patient case workflow. Initially, identity entry screen 402 allows the physician to initially enter identity information for a new patient into multimodality processing system 101 . A specific example of the identification information input screen 402 is shown in detail in FIG. Display screen 402 allows entry of patient metadata, including last name, middle name, first name, date of birth, gender, and UID. The UID may be entered by the physician or automatically generated by the MMCM workflow component. In addition, identification information entry screen 402 can be used to edit previously saved patient information. By using a common unique identifier for all acquired patient data, the physician only needs to enter patient identification information once, when a patient case is initialized, regardless of modality. In this way, data entry errors are reduced and it is ensured that the patient identification information is correctly linked to the acquired diagnostic data. In alternative embodiments, patient identification information may be retrieved from an external patient data repository, such as a hospital information system (HIS). In such a case, the identity input screen 402 may prompt the physician for network connection information for the external data repository described above so that the patient's metadata can be obtained.

Returning to FIG. 4, after the physician enters patient metadata 404 into screen 402, the patient case is initialized and metadata 404 is sent to MMCM workflow component 214 where this metadata is associated with UID 406. . UID 406 may be the UID entered on screen 402, or it may be the UID generated by the MMCM workflow component. After patient metadata 404 is associated with UID 406 , MMCM workflow component 214 stores the metadata in data repository 304 . Upon opening a patient case by entering identifying information about the patient, the physician can perform one or more diagnostic and/or therapeutic procedures on the patient. A modality data acquisition screen 408 facilitates acquisition of diagnostic data received from a patient's internal or external medical device. One specific example of modality data acquisition screen 408 is shown in detail in FIG. Screenshot 408 shows an IVUS acquisition workflow.
An image of the patient's blood vessels, generated from data captured by the IVUS transducer, is displayed to allow the physician to guide the delivery catheter through the patient. As described above in connection with FIG. 2, each modality may have user interface extensions that render the screens necessary to perform diagnostic procedures associated with the particular modality. The screens associated with data management rendered by the MMCM workflow component 214 and the screens associated with data acquisition rendered by each modality extension are seamlessly integrated into the user interface by the system UI extension 244 (FIG. 2). be. Returning to FIG. 4, the patient medical data 410 associated with the first modality captured via the modality data acquisition screen 408 is passed to the MMCM workflow component 214 where it is associated with the UID 406 corresponding to the open patient case. transmitted and then stored in data repository 304 . Thus, patient metadata 404 and patient medical data 406 are both associated with UID 406 and stored in data repository 304 . In one embodiment, the medical data 410 may be stored in the data repository 304 in the form received from the medical device, while in another embodiment the medical data is processed data, such as IVUS or OCT images. may be stored.

In one example workflow of FIG. 4, a second data acquisition procedure is performed on the patient. The medical modality associated with the second data acquisition is different than the medical modality associated with the first data acquisition. The second data acquisition may be performed during the same catheter lab procedure as the first data acquisition, or may be performed during a post-procedure. The unique identifier methodology disclosed herein ensures that the data collected during each acquisition is registered for the same patient, regardless of when the acquisition occurred. A second modality data acquisition screen 412 is presented to guide the physician through the second acquisition workflow. A specific example of the modality data acquisition screen 412 is shown in detail in FIG. Screenshot 412 illustrates the FFR diagnostic procedure. Screen 412 presents the physician with data representative of the blood flow through the patient's blood vessels obtained by sensors placed within the blood vessels.
Returning to FIG. 4, the captured patient medical data 414 associated with the second data acquisition screen 412 is the MMCM where the same UID 406 is associated with the data and where this data is stored in the data repository 304 . It is sent to workflow component 214 .

After diagnostic data associated with one or more modalities has been acquired from the patient, the acquired data management screen 416 allows the physician to review and manage the acquired data sets. A specific example of the acquired data management screen 416 is shown in detail in FIG. Screen 416 includes a case log displaying selectable representations of all acquisition procedures performed on the patient, regardless of modality. In other words, each data set displayed in the case log is stored in the data repository 304 under the same UID corresponding to the patient case. For example, example screen 416 includes both an IVUS dataset and an FFR dataset acquired from the same patient. The selectable representations displayed on screen 416 may correspond to data sets acquired over a period of hours, days, weeks, or years, or they may be separate data sets acquired within the same procedure. may correspond to

In one embodiment, to render screen 416, MMCM GUI component 320 queries data repository 304 for a list of all collected datasets associated with the UID corresponding to the open patient case. In screen shot 416, all datasets are associated with a unique identifier 123456 and selectable representations are organized by modality type. Additionally, in the illustrated embodiment, each selectable representation of a dataset includes the title of the dataset and whether or not the dataset includes any bookmarks that highlight important patient characteristics and whether the dataset has acquired display the date and time In other embodiments, additional information may be displayed in association with each selectable representation of the dataset. Additionally, in some examples, the display order of selectable representations in the case log may change based on various characteristics of the data set, such as acquisition time. As described below, selecting a selectable representation on screen 416 causes the user interface to display the data and/or images contained in the selected data set. However, in some embodiments, selecting a selectable representation on screen 416 causes the UI to display additional information about that selected dataset in screen 416, such as in a drop-down preview pane. Let For example, Figure 9 shows a scenario in which a physician has selected a data set titled "UNTITLED01". Additional information about the data such as acquisition time, pullback rate and bookmarks within the dataset are displayed below the selectable representation of the dataset. Additionally, as shown in the illustrated embodiment, a preview of the image data contained within the dataset may additionally be displayed. Within the drop-down preview pane, buttons for deleting datasets, loading datasets, and displaying additional information about datasets are selectable by the physician. Additionally, in some embodiments, screen 416 allows the physician to select multiple selectable representations of the data set for comparison purposes. Accordingly, a physician reviewing the Acquisition Data Management screen 416 can review and manage all Acquisition Data Sets associated with a patient regardless of modality. In this way, the amount of time a physician must spend reviewing a patient's medical data is reduced, leading to more efficient diagnosis and treatment.

10 shows a number of patient acquisition data management screens 418. FIG. Data management screen 418 is similar to data management screen 416, but it is configured to display selectable representations of data sets associated with multiple patient cases. Each selectable representation of a patient case contains information about the patient case, such as patient name, unique identifier (UID), date of procedure, physician, modality/mode, whether the dataset is archived, Includes dataset size and case type. In other embodiments, each selectable representation of a patient case may include different and/or additional information, such as patient date of birth, patient gender, procedure location, and the like. The order of display of patient cases listed in data management screen 418 may be arranged according to one or more of the information categories associated with each patient case. Further, in some embodiments, when a physician selects a toggle element associated with a selectable representation of a patient case, as shown in FIG. 10, an individual dataset comprising the selected patient case is displayed. be. All acquired data sets associated with the patient case are displayed below the selectable representation without regard to medical modality. In one embodiment of screen 418, a first patient case is selected and data sets associated with the IVUS and FFR procedures are displayed. In addition, a number of patient acquisition data management screens 418 are configured to allow physicians to acquire and open patient cases by selecting one or more selectable representations displayed. be done. When a selectable representation of a patient case is selected on screen 418, the MMCM GUI component 320 uses the associated UID to query the data repository 304 to obtain the dataset associated with the patient. . In some embodiments, the selected patient cases may be obtained from a local or network-based hard drive, while in other embodiments the selected patient cases are stored on removable media, such as DVDs, Blu-ray discs, or May be obtained from a flash-based drive. Therefore, a physician reviewing multiple patient acquisition data management screens 418 can easily review and manage all patient cases, including all acquired data sets included in the patient case, without worrying about modalities. can. In this manner, physicians can efficiently identify and compare relevant patient cases, thereby facilitating efficient diagnosis and treatment.

Returning now to FIG. 4, the physician reviewing the acquisition data management screen 416 may select a particular data set for review in greater detail, as previously described. An indication of the selected medical data 420 is sent to the MMCM workflow component 214 so that the selected medical data can be retrieved from the data repository 304 . Specifically, the MMCM workflow component 214 queries the data repository 304 using at least the UID of the selected medical data. As shown in the embodiment shown in FIG. 4, once the selected patient medical data 422 is retrieved from the data repository 304, it is displayed to the requesting physician via the retrieved medical data display screen 424. As shown in FIG. In this regard, FIG. 11 shows a specific example of the obtained medical data display screen 424. As shown in FIG. An illustration of display screen 424 shows an image dataset captured during an IVUS procedure. In reviewing IVUS images, the physician may take measurements and add labels and other annotations to IVUS images in the dataset. In that regard, a method and system for enhanced measurement, manipulation, navigation, display, and annotation of multimodality medical images is disclosed in U.S. Provisional Patent Application No. XX/XXX, XXX (Filing No. 44755.1041) entitled "Multi DATA Labeling and Indexing in Modality Imaging Systems", U.S. Provisional Patent Application No. XX/XXX, XXX (Filing No. 44755.1042) entitled "Measurement and Enhancement in Multimodality Imaging Systems", U.S. Provisional Patent Application No. XX/ XXX, XXX (Filing No. 44755.1043) entitled "Gesture-Based Interface for Multimodality Imaging Systems," and U.S. Provisional Patent Application No. XX/XXX, XXX (Filing No. 44755.1044) entitled "Multimodality Imaging." Measurement Navigation in the System” is also disclosed, all of which are incorporated by reference in their entirety into this disclosure.

As noted above, in some embodiments, the Acquisition Data Management Screen 416 may allow the physician to select multiple selectable representations of the dataset for comparison purposes. In such scenarios, the MMCM workflow component 214 can retrieve each of the requested data sets for simultaneous display on the acquired medical data display screen 424 . FIG. 12 is another example of an acquired medical data display screen 424 showing two IVUS images side-by-side. The two IVUS images may be from data sets acquired during two different IVUS procedures performed on the patient. A side-by-side comparison of patient images acquired at different times allows the physician to efficiently determine changes in the patient's condition over time. Additionally, FIG. 13 is another example of a medical data display screen 424 showing data associated with different modalities displayed side-by-side. Specifically, IVUS images acquired from a patient are presented simultaneously with FFR data acquired from the same patient. IVUS data and FFR data may have been collected during the same catheter lab procedure or during different catheter lab procedures. MMCM workflow component 214 may include a synchronization component that spatially or temporally synchronizes the multimodality data displayed on screen 424 . Those skilled in the art will recognize that screen 424 of FIG. 13 is only an example and that data for different modalities may be displayed side-by-side for comparison purposes. For example, an OCT image may be displayed adjacent to an ICE image, or in some examples, (streaming) acquired data external to the multimodality processing system 101, such as X-ray angiography (XA) data, may It may be displayed adjacent to data acquired by the processing system itself, such as IVUS or OCT data.

Returning to FIG. 4, any measurements, annotations, notes, or other data 426 created and derived during review of acquired data via screen 424 are sent to MMCM workflow component 214 . The MMCM workflow component 214 associates the UID 406 corresponding to this open patient case with the derived data 426 and stores the derived data 426 in the data repository 304 . In this manner, any annotations, measurements, etc., are closely associated with their corresponding acquired data, facilitating efficient retrieval and subsequent review.

Those skilled in the art will appreciate that the patient case management systems and methods described in connection with FIGS. 4-13 are merely exemplary embodiments, and that additional and/or different steps may be performed in alternate embodiments; and that additional and/or different screens may be rendered as part of the user interface. For example, in some embodiments, each modality workflow component, rather than the MMCM workflow component, may handle writing and retrieving data associated with that modality. In such an embodiment, the independent modality workflow component can query the MMCM workflow component for the UID corresponding to the currently open patient case before storing the new acquired data. Moreover, screens 402, 408, 412, 416, and 424 are merely illustrative and such screens may also be different and/or Additional features and user options may be included.

14 is a flow diagram illustrating another aspect of patient case management within the multimodality processing system 101. As shown in FIG. Specifically, FIG. 14 illustrates a system and method for archiving and anonymizing patient medical data. For clarity, portions of FIG. 14 that are similar to portions of FIG. 4 are similarly labeled.

After medical data associated with one or more modalities has been obtained from the patient and stored in the data repository 304, the physician may proceed to archive the data on an archival storage medium, as described above in connection with FIG. 3A. given the option. Archiving acquired medical data generally includes moving the medical data to a storage location external to the medical processing system where the medical data was acquired. In one example, the acquired medical data may be transferred to removable storage media, such as writable optical discs or portable flash-based containers. In another example, acquired medical data may be transferred to a remote data repository, such as DICOM, via a network connection.

To facilitate archiving of multi-modality patient charts, the MMCM GUI component renders an acquired medical data archive screen 1400 . A specific example of the acquired medical data archive screen 1400 is shown in detail in FIG. This exemplary archive screen 1400 displays a list of selectable representations of patient cases available for archiving. Each selectable representation of a patient case contains information about that patient case, such as patient name, unique identifier (UID), date of procedure, physician, modality/mode, whether dataset has already been archived, data Includes set size and case type. In some examples, the UID displayed in association with each patient case may be an identifier assigned by the clinic that treats the patient, even if it is not generally unique, such as a social security number. good. In other embodiments, each selectable representation of a patient case may include different and/or additional information, such as patient date of birth, patient gender, procedure location, and the like. The display order of patient cases listed in archive screen 1400 may arrange one or more of the categories of information associated with each patient case. Each representation of a patient case is selectable—eg via a checkbox. Manipulating the drop-down toggle associated with one of the patient cases displays the modality datasets that make up the patient case. For example, a first patient case displayed on screen 1400 includes a dataset generated during an IVUS procedure and a dataset generated during an FFR procedure. These datasets are displayed as individually selectable representations - eg by selecting a checkbox to the left of the dataset representation. In other embodiments, different methods of selecting datasets can be implemented. In a further embodiment, not shown in example screen 1400, each image-based dataset (i.e., IVUS dataset) can be expanded within a patient case to display the individual images that make up the dataset. You may In such embodiments, each image is individually selectable—eg, via a checkbox.

After the physician has reviewed the list of patient cases available for archiving on screen 1400, the physician may select one or more of the patient cases, datasets, or images for archiving. In the illustrated embodiment, the physician places a check mark by each item to archive and then actuates the archive button. Notably, the archiving system of the present disclosure is configured to archive at the patient-case level, dataset level, or image level. That is, the physician can (1) selectively determine which patient case or multiple patient cases to archive; (2) selectively determine which dataset or multiple datasets within the patient case to archive; and (3) selectively determining which image or images in the dataset to archive. In some examples, any permutation of patient cases, datasets, or images can be archived together. Thus, a single archiving action can simultaneously archive multiple patient cases corresponding to multiple patients. Archived patient cases may also include data sets associated with different medical modalities and were acquired during one catheter lab procedure or during different catheter lab procedures performed at different times. It may also include multi-modality datasets.

As described above in connection with FIG. 3A, patient cases can be associated with their corresponding UIDs and archived for efficient storage management and retrieval. In some embodiments, utilization of this UID allows an archived patient case to be updated with "new" patient data acquired after the initial archiving action. More specifically, after a patient case has been archived, screen 1400 only shows it in the "Archived" information column. If the new dataset was acquired in association with a previously archived patient case, screen 1400 indicates that the new dataset has not been archived. The physician can individually select this unarchived data set and operate the archive button. In response, the archiving system (implemented by the data archiving component 314 of FIG. 3A or by the MMCM workflow component 214) locates the archived patient case via its associated UID and renders it Open and insert the new dataset. In other embodiments, updating an archived patient case may be performed in a different manner, e.g., retrieving the archived patient case's data, adding the new data set, and adding the new data in the updated patient case. It can be done, such as by creating an archive.
Additionally, in other embodiments, the MMCM workflow component prohibits data from being added to previously archived cases to prevent data tampering.

Further, in some embodiments, the archiving systems of Figures 14 and 15 are configured to archive medical data to locations selected by the physician rather than to fixed locations. For example, in screen shot 1400, the physician may select either archiving to removable media, such as writable optical discs, or portable flash storage, or archiving to network-connected remote storage media, such as a DICOM server. can be done. In alternate embodiments, additional and/or different archive locations may be selected by the physician, such as local hard drives, storage area network (SAN), or cloud-based storage.

In one particular embodiment, the archiving system of FIGS. 14 and 15 is configured to archive medical data in one of a number of different formats, according to selections made by the physician on example screen 1400. FIG. In that regard, the patient medical data may simply be archived "as is" without changing its format, or its format may be changed (i.e., changed to the format selected on screen shot 1400); Or it may be archived in a compressed format to reduce the amount of storage space required. In some embodiments, medical data can be inserted into proprietary or industry standard archival data containers. Additionally, medical data archived by the illustrated archiving system may be encrypted or otherwise obfuscated to prevent unauthorized access. In some embodiments, an option may be presented on archive screen 1400 to encrypt and/or restrict access to archived items via a password.

The archiving component of the multimodality processing system 101 shown in the embodiment of Figures 14 and 15 is further configured to selectively anonymize medical data before it is archived. For example, a physician can choose whether to remove patient-identifying information from medical data before it is archived. More specifically, when archiving patient cases without anonymization, all acquired modality datasets and all metadata - including patient identification information - are included in the archive container. Similarly, individual archived modality datasets and images will contain patient-identifying information if archived without anonymization. However, if the physician chooses to anonymize it before archiving, the archiving system automatically removes any information from the archived chart that could identify the patient from the person who acquired the data. . In the illustrated embodiment, the archival system anonymizes medical data when the “Anonymize” button on archive screen 1400 is operated. Notably, the archiving system is configured to remove all patient-identifying information without the influence of the archiving physician. That is, the system first determines which data fields within the patient case contain information that can identify the patient, and then deletes any data within the identified fields. In one embodiment, this determination is based on a configuration file containing a predetermined set of data fields known to contain identifying information. In an alternative embodiment, the archive system uses natural language processing algorithms on a case-by-case basis to determine sensitive data fields. Further, in some embodiments, patient-identifying information is obfuscated rather than removed during the anonymization procedure. In such embodiments, the obfuscated patient information can be retrieved by authorized systems or physicians. Additionally, when multiple patient cases corresponding to multiple patients are selected for archiving--and an anonymization option is selected--identifying information for each different patient is removed from the patient case, Or obfuscated.

Therefore, at least some of the deleted ablated patient information remains hidden from physicians or other third-party data processors because the multimodality processing system 101 automatically anonymizes the archived data without intervention by the physician. Yes, this would increase the confidentiality of sensitive medical information. Additionally, automated anonymization reduces clerical errors and ensures that all identifying information is removed regardless of whether it is accessible through the user interface. . Additionally, in the archival scenario described herein, anonymization actions are performed in the multimodality acquisition/processing system itself before the data is sent to the remote archival storage location. For example, in embodiments where the multimodality processing system is a portable processing system located in a catheter lab, the physician obtains medical data from the patient, anonymizes it, and archives it to a removable storage medium, such as a DVD. , all can be done on a processing system in the catheter lab.

Returning to FIG. 14, after the physician selects one or more of the patient cases, datasets, and/or images to archive, an archive request 1402 is sent to the MMCM workflow component 214 . The archive request is an instruction to archive the particular medical data selected and whether the selected medical data should be anonymized. The MMCM workflow component 214 processes this request and retrieves the previously selected medical data 1404 from the data repository 304 . If the physician has indicated that the medical data 1404 should be anonymized, the patient identification information 1406 is deleted or obfuscated by the MMCM workflow component 214 before it is stored on the archival storage medium 316 . The MMCM workflow component 214 may further modify the data to be archived, such as by compressing, encrypting, changing its format, and/or enclosing it within an archive data container.

The above-described systems and methods for archiving or anonymizing multimodality medical data in a multimodality processing system are merely exemplary embodiments, and in alternate embodiments additional and/or different steps may be included in the method, and it is understood that the system may include additional and/or different user interface screens. Additionally, archive screen 1400 is merely one example, and it may include different and/or additional features and user options to further facilitate patient case management within multimodality processing system 101 .

While exemplary embodiments have been illustrated and described, a wide range of modifications, changes, and substitutions are contemplated in the foregoing disclosure, and in some instances some features of the present disclosure have been replaced with corresponding can be employed without the use of other features that Also, as noted above, the components and enhancements described above in connection with the multimodality processing system may be implemented in hardware, software, or a combination of both. And, the processing system may be designed to run on any particular architecture. For example, the system can run on a single computer, local area networks, client-server networks, wide area networks, the Internet, handheld and other portable wireless devices and networks. It is understood that such variations can be made in the foregoing without departing from the scope of the present disclosure. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the present disclosure.

Claims (24)

1. A method of collecting multimodality medical data associated with a patient and displaying said multimodality medical data using a multimodality medical processing system, comprising:
The multimodality medical processing system comprises a first medical modality component, a second medical modality component, and a multimodality management component in communication with the first medical modality component and the second medical modality component;
a first medical device having a shape and size for insertion into a blood vessel of the patient, a first medical device disposed within the patient's blood vessel, an intravascular catheter or guide wire comprising a flexible elongated member; a data acquisition component configured to acquire first medical data associated with a medical modality of the patient intravascularly;
This method:
receiving , at the first medical modality component, the first medical data obtained from the patient from the first medical device ;
associating a unique identifier with the first medical data;
storing the first medical data in a data repository;
receiving, at the second medical modality component, second medical data about the patient from a second medical device, the second medical data different from the first medical modality; Receiving associated with two medical modalities;
associating the unique identifier with the second medical data;
storing said second medical data in said data repository;
simultaneously displaying a first selectable option and a second selectable option in the same portion of a user interface output area on a touch screen of a bedside controller located near the patient; The first selectable option controls display of the first medical data, the second selectable option controls display of the second medical data, and the bedside controller controls display of the A user interface component in communication with the first medical device, the second medical device and the multimodality medical processing system, wherein a user interface component of the multimodality medical processing system renders the touch screen of the bedside controller and renders the user interface. displaying a component utilized by the multimodality management component to display data associated with the first medical modality component and the second medical modality component;
Receiving a user selection of the first selectable option for displaying the first medical data, the user selection comprising user input on the touch screen of the bedside controller. , receiving ; and displaying said first medical data within said user interface output area on said touch screen of said bedside controller in response to receiving said user selection. . The method of claim 1, wherein:
receiving a further user selection of the second selectable option to display the second medical data; and displaying the first medical data and the second medical data at the user interface. The method further comprising displaying simultaneously. 2. The method of claim 1, wherein displaying the first selectable option and the second selectable option comprises metadata values associated with the first medical data and the second medical data. displaying the first selectable option and the second selectable option in an order determined by. 4. The method of claim 3, wherein the metadata value is one of medical modality, medical data acquisition time, or physician name. 2. The method of claim 1, wherein displaying the first selectable option and the second selectable option comprises : organizing by the type of medical modality of the represented medical data, within a group displaying the first selectable option and the second selectable option of . 2. The method of claim 1, further comprising displaying additional information about the first medical data in response to user manipulation of a toggle element associated with the first selectable option . 7. The method of claim 6, wherein said additional information includes a preview image of said portion of said patient obtained from said first medical data. 7. The method of claim 6, wherein said additional information is displayed adjacent said first selectable option . 7. The method of claim 6, wherein said additional information includes a pullback rate of an acquisition procedure that generated said first medical data. The method of claim 1, wherein
displaying a delete button upon user manipulation of a toggle element associated with the first selectable option ;
The method further comprising: receiving a user actuation of the delete button; and deleting the first medical data from the data repository in response to receiving the user actuation. 2. The method of claim 1, wherein said first medical data and said second medical data are obtained from said patient during a single catheter lab session. 2. The method of claim 1, wherein the first and second medical modalities are respectively intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, optical coherence tomography (OCT), forward looking IVUS (FL-IVUS), Fractional Flow Reserve (FFR) method , Fractional Coronary Flow Reserve (CFR) , Pressure, Flow, Temperature, Fractional Flow Reserve (FFR), Fractional Flow Reserve (iFR) ), fractional coronary flow reserve (CFR), intracardiac ultrasonography (ICE), forward-looking ICE (FLICE), intravascular palpography, transesophageal ultrasound, X-ray, magnetic resonance imaging (MRI) or computed tomography (CT) . A multimodality medical processing system comprising:
a data repository ;
a first medical modality component;
a second medical modality component;
a multimodality management component in communication with the first medical modality component and the second medical modality component;
a stationary computer-readable storage medium storing a plurality of instructions for execution by at least one computer processor ;
a first medical device having a shape and size for insertion into a blood vessel of the patient, a first medical device disposed within the patient's blood vessel, an intravascular catheter or guide wire comprising a flexible elongated member; a data acquisition component configured to acquire first medical data associated with a medical modality of the patient intravascularly;
Said instruction is:
receiving , at the first medical modality component, the first medical data obtained from the patient from the first medical device ;
associating a unique identifier with the first medical data;
storing the first medical data in the data repository;
Receiving, at the second medical modality component, second medical data obtained from the patient from a second medical device, the second medical data being different from the first medical modality. Receiving associated with a second medical modality;
associating the unique identifier with the second medical data;
storing said second medical data in said data repository;
simultaneously displaying a first selectable option and a second selectable option in the same portion of a user interface output area on a touch screen of a bedside controller located near the patient; The first selectable option controls display of the first medical data, the second selectable option controls display of the second medical data, and the bedside controller controls display of the A user interface component in communication with the first medical device, the second medical device and the multimodality medical processing system, wherein a user interface component of the multimodality medical processing system renders the touch screen of the bedside controller and renders the user interface. displaying a component utilized by the multimodality management component to display data associated with the first medical modality component and the second medical modality component;
Receiving a user selection of the first selectable option for displaying the first medical data, the user selection comprising user input on the touch screen of the bedside controller. , receiving ; and displaying said first medical data within said user interface output area on said touch screen of said bedside controller in response to receiving said user selection. 14. The multimodality medical processing system of claim 13, wherein said instructions include instructions for:
receiving further user selection of said second selectable option for displaying said second medical data; and displaying said first medical data and said second medical data at said user interface. be displayed at the same time. 14. The multimodality medical processing system of claim 13, wherein displaying the first selectable option and the second selectable option is associated with the first medical data and the second medical data. displaying the first selectable option and the second selectable option in an order determined by metadata values provided by the method. 16. The multimodality medical processing system of claim 15, wherein the metadata value is one of medical modality, medical data acquisition time, or physician name. 14. The multimodality medical processing system of claim 13, wherein displaying the first selectable option and the second selectable option is organized by the medical modality type of the represented medical data. to display the first selectable option and the second selectable option within a group. 14. The multi-modality medical processing system of claim 13, wherein the instructions display additional information about the first medical data upon user manipulation of a toggle element associated with the first selectable option . A system, further comprising instructions for: 19. The multimodality medical processing system of claim 18, wherein said additional information includes a preview image of said portion of said patient obtained from said first medical data. 19. The multimodality medical processing system of claim 18, wherein said additional information is displayed adjacent said first selectable option . 19. The multimodality medical processing system of claim 18, wherein said additional information includes a pullback rate of an acquisition procedure that generated said first medical data. 14. The multimodality medical processing system of claim 13, wherein said instructions include further instructions relating to:
displaying a delete button upon user manipulation of a toggle element associated with the first selectable option ;
receiving a user actuation of the delete button; and deleting the first medical data from the data repository in response to receiving the user actuation. 14. The multimodality medical processing system of claim 13, wherein said first medical data and said second medical data are obtained from said patient during a single catheter lab session. 14. The multimodality medical processing system of claim 13, wherein said first and said second medical modalities are respectively intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, optical coherence tomography (OCT) ), forward IVUS (FL-IVUS), fractional flow reserve (FFR) , fractional coronary flow reserve (CFR) , pressure, flow rate, temperature, fractional flow reserve (FFR), instantaneous flow reserve ratio (iFR), coronary flow reserve ratio (CFR), intracardiac ultrasonography (ICE), forward-looking ICE (FLICE), intravascular palpography, transesophageal ultrasound, X-ray, magnetic resonance imaging (MRI) or A system characterized by being one of computed tomography (CT) .

Images