JP2018163670A - Device, system and method for data processing in invasive context, and multi-modality medical system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it possible to selectively archive patient data in a multi-modality medical processing system.SOLUTION: Medical data are selectively archived at the patient case level, the modality data set level and/or the individual image level, thereby allowing a medical doctor to have fine levels of a right of managing archived specific data. Further, a data set of other medical modalities can be simultaneously archived, and patient cases corresponding to different patients can be simultaneously archived to enhance the efficiency of the archive.SELECTED DRAWING: None

Description

  Embodiments of the present disclosure relate generally to the field of medical devices, and more specifically to a multi-modality selective archiving system and method.

  Innovation in diagnosing and validating the success level of disease treatment is moving from an external imaging process to an internal diagnostic process. Specifically, diagnostic devices and methods are used for vascular occlusion and other vessels with microsensors placed on the distal end of a flexible elongate member such as a catheter or a guidewire used for catheterization. It has been developed to diagnose structural diseases. For example, known medical sensing techniques include angiography, intravascular ultrasound (IVUS), anterior vision IVUS (FL-IVUS), blood flow reserve ratio (FFR) measurement, coronary blood flow reserve ratio (CFR) measurement, Includes optical coherence tomography (OCT), transesophageal echocardiography, and image guided therapy. Each of these techniques may be more suitable for different diagnostic situations. In order to increase the likelihood of successful treatment, medical facilities have a large number of imaging, treatment, diagnosis, and sensing hand modalities in the catheter lab during the procedure. Traditionally, when a patient goes through 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 effort can lead to clerical errors and wasted resources. Furthermore, patient diagnostic discrepancies may be caused by each modality that maintains separate patient charts for the same patient.

  In addition, the data associated with each medical modality is traditionally acquired and managed with different hardware or software systems. As a result, the physician can review a data set associated with the first medical modality on a different system than the data set associated with the second different medical modality. Transitioning between systems for reviewing data obtained from the same patient is inefficient and can lead to inaccurate diagnosis. Further, the archiving mechanism and archive storage location may be different between different modality acquisition systems. For example, patient IVUS data may be archived in a different location and in a different format than the same patient OCT data, which makes data acquisition inefficient and cumbersome.

  Further, when archived medical data is used for educational and other non-diagnostic purposes, it is typically to delete any information that can identify the patient from which the data was obtained. Traditionally, deletion of identification information prior to archiving is performed by a technician who deletes patient data from manually selected fields. As described above, in many cases, the anonymized data is an error that is likely to occur, and in many cases, all identification information is not deleted.

  Thus, while existing case management systems and methods are generally appropriate for their intended purpose, they have not been completely satisfactory in all respects.

  In general, the present disclosure is directed to selectively archiving patient data in a multi-modality medical processing system. The methods and systems described herein selectively archive medical data at the patient case level, at the modality data set level, and / or at the individual image level, thereby enabling the physician to archive specific data. Have a fine level of management rights. In addition, another medical modality data set may be archived simultaneously, and patient cases corresponding to different patients may be archived simultaneously to increase the efficiency of the archive.

  In certain exemplary aspects, the present disclosure is directed to a method of selectively archiving medical data associated with a patient using a multi-modality medical processing system. The method receives first medical data obtained from a patient from a first medical device, the first medical data is associated with a first medical modality; and a patient from a second medical device Receiving second medical data obtained from the second medical data, wherein the second medical data is associated with a second medical modality different from the first medical modality. The method also displays on the user interface a selectable representation of the first medical data and the second medical data, receiving a user selection of the one or more selectable representations; And receiving an archive request via a user interface. Further, the method includes archiving medical data corresponding to the selected one or more selectable representations at the archive location in response to receiving the archive request.

  In another exemplary aspect, the present disclosure is directed to a multi-modality 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 receive first medical data obtained from a patient from a first medical device, the first medical data is associated with a first medical modality; and a patient from a second medical device Receiving second medical data obtained from the second medical data, wherein the second medical data is associated with a second medical modality different from the first medical modality. The instructions also display on the user interface a selectable representation of the first medical data and the second medical data, receiving a user selection of one or more of the selectable representations; And receiving an archive request via the user interface. Further, the instructions relate to archiving medical data corresponding to the selected one or more selectable representations to an archive location in response to receiving the 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 multi-modality medical processing system. The method retains a first patient case corresponding to a first patient, the first patient case includes multi-modality medical data obtained from the first patient; and corresponds to a second patient Maintaining a second patient case, the second patient case including multi-modality medical data obtained from the second patient. The method also displays on the user interface a selectable representation of the first medical data and the second medical data, receiving a user selection of the one or more selectable representations; And receiving an archive request via a user interface. Further, the method includes archiving multi-modality medical data in 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 present disclosure relates to anonymizing patient data in a multi-modality medical processing system. The methods and systems described herein automatically delete information from the medical data that can identify the patient from whom it was obtained in order to protect patient privacy. Specifically, anonymization is performed without human intervention to limit the deletion of errors and incomplete information. In addition, another medical modality data set may be anonymized simultaneously, and multiple patient cases corresponding to different patients may be anonymized simultaneously to increase efficiency.

  In certain exemplary aspects, the present disclosure is directed to a method of anonymizing medical data acquired from a patient in a multi-modality medical processing system. The method receives first medical data obtained from the patient from a first medical device, the first medical data being associated with a first medical modality; the patient from a second medical device. Receiving second medical data obtained from the second medical data, wherein the second medical data is associated with a second medical modality different from the first medical modality; and the first and second medical data are Adding to the patient case corresponding to the patient, the patient case including identification information about the patient. The method further includes 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. Receiving. In addition, the method deletes the identification information from the patient case in response to receiving the anonymization request, the deletion is not affected by the user, and the deletion Meanwhile, at least some of the identification information is hidden from the user.

  In another exemplary aspect, the present disclosure is directed to a multi-modality 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 receive first medical data obtained from the patient from a first medical device, the first medical data is associated with a first medical modality; and from a second medical device Receiving second medical data obtained from the patient, the second medical data being associated with a second medical modality different from the first medical modality; The instruction also adds the first and second medical data to a patient case corresponding to the patient, the patient case includes identifying information about the patient; Displaying a selectable representation; and receiving a user selection of the selectable representation. Further, the command includes receiving an anonymization request from a user via the user interface; and deleting the identification information from the patient case in response to receiving the anonymization request, the deletion Are unaffected by the user, and during this deletion, at least some of the identification information is hidden from the user.

  In yet another exemplary aspect, the present disclosure is directed to another method for anonymizing medical data in a multi-modality 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. The first patient case includes identification information about the first patient; receiving medical data obtained from a second patient from a second medical device; Different from the first patient; and adding the second medical data to the second patient case corresponding to the second patient, the second patient case providing identifying information about the second patient Including; including. The method also displays on the user interface a selectable representation of the first and second patient cases, receives a user selection of both selectable representations, and via the user interface. Receiving anonymization requests. The method also includes deleting the first and second identification information from each of the first and second patient cases in response to receiving the anonymization request, wherein the deletion is from the user. It is unaffected and the first or second identification information is hidden from the user during this deletion.

  In another context, the present disclosure is directed to displaying patient medical data in a multi-modality medical processing system. The method and system described herein presents medical data in multiple modalities on a single user interface screen, and a physician who views the user interface is associated with the patient without worrying about the modality. Allows management of all acquired data sets. In this way, the amount of time that the physician must spend reviewing the patient's medical data is reduced, leading to a more efficient diagnosis and treatment. Furthermore, multiple patient cases corresponding to different patients may be presented on a single user interface screen to simplify the management of multiple patient cases.

  In certain exemplary aspects, the present disclosure is directed to a method of displaying multi-modality medical data using a multi-modality medical processing system. The method receives first medical data obtained from a patient from a first medical device, wherein the first medical data is associated with a first medical modality; Storing second medical data acquired from the patient from a second medical device, the second medical data being in a second medical modality different from the first medical modality And storing the second medical data in the data repository. The method also displays on the user interface a selectable representation of each of the first medical data and the second medical data; user selection of the selectable representation 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 multi-modality 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 receive first medical data obtained from a patient from a first medical device, the first medical data being associated with a first medical modality; Storing in a data repository; receiving second medical data obtained from the patient from a second medical device, the second medical data being different from the first medical modality Associated with a modality; and storing the second medical data in the data repository. The instructions also display on the user interface a respective selectable representation of the first medical data and the second medical data; a user selection of the selectable representation 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 multi-modality medical data using a multi-modality medical processing system. The method includes maintaining a first patient case corresponding to a first patient, the first patient case being associated with a first data modality associated with a first medical modality and the first medical modality. Includes a second data set associated with a different second medical modality; and retaining a second patient case corresponding to the second patient, wherein the second patient case is from the second patient Including acquired medical data. The method also displays on the user interface a selectable representation of each of the first patient case and the second patient case; a first user of the selectable representation of the first patient case. Receiving a selection; and in response to receiving the first user selection, displaying a selectable representation 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 responsive to receiving the second user selection on the user interface. Displaying one data set.

  In another context, the present disclosure is directed to managing and managing and storing patient data in a multi-modality 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 information, (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 review and retrieval of patient cases. An aspect of this is that only identifying patient information such as patient name and date of birth needs to be entered into the disclosed system at a single time, which can be clerical Will reduce sex.

  In certain exemplary aspects, the present disclosure is directed to a method of multi-modality medical case management in a multi-modality medical processing system. The method includes receiving identification information about a patient, generating a unique identifier corresponding to the patient, and associating the unique identifier with the identification information. The method also includes receiving, in the multi-modality medical processing system, first medical data acquired from the patient from a first medical device, the first medical data being transmitted to the first medical modality. And storing the first medical data in a data repository, the first medical data being associated with the unique identifier in the data repository. Further, the method includes receiving the second medical data acquired from the patient from a second medical device in the multi-modality medical processing system, and the second medical data is the first medical modality. And storing the second medical data in the data repository, the second medical data being associated with the unique identifier in the data repository; Including.

  In another exemplary aspect, the present disclosure is directed to a multi-modality 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 identification information about a patient, generating a unique identifier corresponding to the patient, and associating the unique identifier with the identification information. The instructions also receive first medical data obtained from the patient from a first medical device that is communicatively connected to the multi-modality medical processing system, the first medical data being Associated with a medical modality; and storing the first medical data in the data repository, wherein the first medical data is associated with the unique identifier in the data repository. The instructions further include receiving second medical data obtained from the patient from a second medical device communicatively connected to the multi-modality medical processing system, wherein the second medical data is the first medical data. Being associated with a second medical modality different from the one medical modality; and storing the second medical data in the data repository, wherein the second medical data is stored in the data repository with the unique identifier Related to;

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

FIG. 1 is a schematic diagram illustrating a medical system including a multi-modality processing system according to an embodiment of the present disclosure. FIG. 2 is a functional block diagram of portions of a medical system that includes a processing framework implemented in one embodiment of the multi-modality processing system. FIG. 3A is a functional block diagram of a portion of the processing framework of FIG. 2, which is associated with multi-modality case management. FIG. 3B is a diagram showing a specific patient case having a unique identifier at the data level of each hierarchy. FIG. 4 is a simplified flow diagram of patient case management within the multi-modality processing system of FIG. 1 in accordance with aspects of the present disclosure. FIG. 5 is an example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 6 is an example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 7 is an example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 8 is an example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 9 is an example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 10 is an example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 11 is an example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. 12 is an example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 13 is an example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 14 is a simplified flow diagram illustrating archiving and anonymizing patient medical data within the multi-modality processing system of FIG. FIG. 15 is a specific archive screen of the case management user interface rendered by the multi-modality processing system of FIG.

For the purpose of promoting an understanding of the principles of the disclosure, reference is made to the embodiments illustrated in the drawings and specific language is 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 apparatus, system, and method, and further applications of the principles of the present disclosure, are fully within the present disclosure as would occur to those of ordinary skill in the art to which this disclosure pertains. Intended and included.
In particular, it is fully intended 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 present disclosure. . However, for the sake of brevity, numerous repetitions of these combinations are not described individually.

  FIG. 1 is a schematic diagram illustrating a medical system 100 including a multi-modality processing system 101 according to an embodiment of the present disclosure. In general, the medical system 100 appears to be sensitive to various methods used to obtain and interpret human biological physiological and morphological information and summarize the treatment of various symptoms. Provides consistent integration and enhancement of multiple forms of acquisition and processing elements designed to. More specifically, in the system 100, the multi-modality processing system 101 is an integrated device for acquiring, managing, interpreting, and displaying multi-modality medical detection data. In some embodiments, the processing system 101 is a computer system having hardware and software for acquiring, processing, and displaying multi-modality medical data, while in other embodiments, the processing system 101 is Any other type of computing system operable to process medical data may be used. In embodiments where processing system 101 is a computer workstation, the system includes a microcontroller or dedicated central processing unit (CPU) and a fixed computer readable storage medium such as a hard disk drive, random access memory (RAM) and And / or a compact disk read only memory (CD-ROM) and 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 specific examples, the processing system 101 is programmed to execute procedures associated with data acquisition and analysis as described in this disclosure. Thus, procedures related to data acquisition, data processing, instrument control, and / or other processing or management aspects of the present disclosure may be on or in a fixed computer readable storage medium accessible by the processing system. It is understood that it may be implemented by a processing system that uses corresponding instructions stored in In some examples, the processing system 101 is portable (eg, handheld, on a transport cart, etc.). Further, it will be appreciated that in some examples, the processing system 101 comprises multiple computing devices. In that regard, it is specifically understood that the different processing and / or management aspects of the present disclosure may be implemented separately or in predefined groups using multiple computing devices. Any division and / or combination of the processing and / or management aspects described below across multiple computing devices is within the scope of this disclosure.

  In the illustrated embodiment, the medical system 100 is deployed in a catheter lab 102 having a management room 104 with a processing system 101 located in the management 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 area that covers the procedural area, but the associated management room 104 may or may not be sterile depending on the requirements of the procedure and / or medical facility. Good. Catheter labs and management rooms provide patients with various medical detection procedures such as angiography, intravascular ultrasound (IVUS), virtual tissue structure (VH), forward vision IVUS (FL-IVUS), intravascular photoacoustic (IVPA). ) Imaging, blood flow reserve ratio (FFR) measurement, instantaneous blood flow reserve ratio (iFR) measurement, X-ray angiography (XA) imaging, coronary blood flow reserve ratio (CFR) measurement, optical coherence tomography (OCT) ), Computed tomography, intracardiac ultrasonography (ICE), forward vision ICE (FLICE), intravascular palography, transesophageal ultrasound, or any other medical detection modality known in the art Can be used for In addition, the catheter lab and management room perform one or more procedures or therapeutic procedures on the patient, such as radiofrequency ablation (RFA), cryotherapy, atherectomy, or any other medical procedure known in the art. Can be used for. For example, in the catheter lab 102, the patient 106 can undergo a multi-modality procedure in combination with a single procedure or one or more detection procedures. In any case, the catheter lab 102 includes a plurality of medical instruments that include medical detection devices that can collect medical detection data from a patient 106 at a variety of different medical detection modalities.

  In the embodiment shown in FIG. 1, the instruments 108 and 110 are medical sensing devices that can be utilized by a clinician to obtain medical detection data regarding the patient 106. In a particular example, the device 108 collects medical detection data at one modality, and the device 110 collects medical detection data at different modalities. For example, the devices may each include pressure, flow rate (flow rate), images (including images obtained using ultrasound (eg, IVUS), OCT, heat, and / or other imaging techniques), temperature, and One of the combinations can be collected. The devices 108 and 110 are sized and shaped to be placed within an apparatus, instrument, or blood vessel, or attached to the exterior of the patient, or scanned across the patient at intervals. Any form of the probe may be used.

  In the embodiment shown in FIG. 1, instrument 108 is an IVUS catheter 108 that includes one or more sensors, eg, a phased array transducer for collecting IVUS detection data. In some embodiments, the IVUS catheter 108 may have the possibility of multi-modality detection, such as IVUS and IVPA detection. Further, in the illustrated embodiment, instrument 110 is an OCT catheter 110 that includes one or more optical sensors configured to collect OCT detection data. In some examples, IVUS patient interface module (PIM) 112 and 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 detection data collected from patient 106 by IVUS catheter 108 and OCT catheter 110, respectively, and manage the received data. It can be operated to transmit to the processing system 101 of the chamber 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 send analog data. To the processing system. In some embodiments, IVUS-PIM 112 and OCT-PIM 114 transmit medical detection data via a peripheral component interconnect high speed (PCIe) data bus connection, while in other embodiments they are USB connected, Thunderbolt Data may be transmitted via a (Thunderbolt) connection, a FireWire connection, or some other high speed data bus connection. In other examples, the PIM is via a wireless connection using the IEEE 802.11 Wi-Fi standard, Ultra Wideband (UWB) standard, Wireless FireWire (FireWire), Wireless USB, or another high-speed wireless network standard. It may be connected to the processing system 101.

  Further, in the medical system 100, the electrocardiogram (ECG) device 116 is operable to send an electrocardiogram signal or other hemodynamic data from the patient 106 to the processing system 101. In some embodiments, the processing system 101 is operable to synchronize data collected with the catheters 108 and 110 using ECG signals from the ECG 116. Further, the angiography system 117 is operable to collect x-rays, computed tomography (CT), or magnetic resonance images (MRI) of the patient 106 and transmit them to the processing system 101. In certain embodiments, angiography system 117 may be communicatively connected to processing system 101 via an adapter device. Such an adapter device can convert data from its own third-party format to a format that can be used by the processing system 101. In some embodiments, the processing system 101 uses image data (eg, X-ray data, MRI data, CT data, etc.) from the angiography system 117 along with detection data from IVUS and OCT catheters 108 and 110. , It may be operable to register simultaneously. As one aspect thereof, the simultaneous registration may be performed to generate a three-dimensional image using the detection data.

  Bedside controller 118 is communicatively coupled to processing system 101 and provides user management rights for specific medical modalities (or modalities) used to diagnose patient 106. In the current embodiment, the bedside controller 118 is a touch screen controller that provides user management rights and diagnostic images for a single surface. However, in alternative embodiments, the bedside controller 118 may include both a non-interactive display and a separate operating device, such as a physical button and / or joystick. 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, bedside controller 118 includes user interface (UI) framework services through which workflows associated with multiple modalities may be executed. In this way, the bedside controller 118 allows workflow and diagnostic images for multiple modalities to allow a clinician to manage the acquisition of multi-modality medical detection data using a single interface device. Can be displayed.

  The main controller 120 in the control room 104 is communicatively connected to the processing system 101 and is 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 that includes a touch screen, and a GUI-based workflow corresponding to another medical detection modality via a UI framework service executing on it. It is operable to display many. In some embodiments, the main controller 120 can be used to simultaneously execute a workflow of a different manner of procedure than the bedside controller 118. In an alternative embodiment, the main controller 120 may include a non-interactive display and a stand-alone operating device such as a mouse or keyboard.

  The medical system 100 further includes a boom display 122 communicatively connected to the processing system 101. The 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 on the boom display 122 may display a tomographic view, and some monitors may display a sagittal view.

  Further, the multi-modality processing system 101 is communicatively connected to the data network 125. In the illustrated embodiment, the data network 125 is a TCP / IP based local area network (LAN), but in other embodiments it may be a different protocol such as a synchronous optical network (SONET), or It may be a wide area network (WAN). The processing system 101 can be connected to various resources via the network 125. For example, the processing system 101 includes a digital imaging and communication in medical (DICOM) system 126, an image archiving and communication system (PACS) 127, a hospital information system (HIS) 128, and the like via a network 125. Can communicate. Further, in some embodiments, the network console 130 communicates with the multi-modality processing system 101 via the network 125 to allow a physician or other medical professional to remotely access aspects of the medical system 100. It may be possible. For example, a user of the network console 130 can access patient medical data, eg, diagnostic images collected by the multi-modality processing system 101, or in some embodiments, the user of the network console 130 is performed at the catheter lab 102. One or more procedures can be monitored or managed in real time. The network console 130 may be any type of computing device with a network connection, such as a PC, laptop, smartphone, tablet computer, or other such device located inside or outside a medical facility.

  Further, in the illustrated embodiment, the medical detection tool of the system 100 described above is shown as being communicatively connected to the processing system 101 via a wired connection, eg, a standard copper link, a fiber optic link, In an embodiment, the tool is connected to the processing system 101 via a wireless connection, such as an IEEE 802.11 Wi-Fi standard, an ultra-wideband (UWB) standard, a wireless firewire (FireWire), a wireless USB, or another high-speed wireless network standard. You may connect.

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

  Next, FIG. 2 illustrates a functional block diagram of a portion of the medical system 100 that includes a processing framework 200 that executes on one embodiment of the multi-modality processing system 101. The process framework 200 includes various independent and dependent executable components that control the operation of the processing system 101, including acquisition, processing, and display of multi-modality medical detection data. In general, the processing framework 200 of the processing system 101 is modular and extensible. That is, the framework 200 is comprised of independent software and / or hardware components (or extensions) that are 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. Allows for expansion. Furthermore, an internal messaging system facilitates independent data communication between modules within the framework. In one example, the processing framework 200 may be implemented as computer-executable instructions stored on a fixed computer-readable storage medium within the processing system 10. In other examples, the processing framework 200 may be a combination of hardware and software modules executing within the processing system 101.

  In general, in the embodiment shown in FIG. 2, the processing framework 200 is configured to detect medical detection data from a plurality of medical detection devices; process data; or diagnostic images via the main controller 120, bedside controller 118 or other graphic display device. A plurality of components configured to receive the output data. The framework 200 includes several system level components that manage the core system functions of the processing system 101 and group multiple modality specific components. For example, the framework 200 includes a system controller 202 that coordinates activation and shutdown of a plurality of executable components of the processing framework 200 including hardware and software modules related to the acquisition and processing of patient diagnostic data. The system controller 202 is also configured to monitor the status of components executing within the framework 202, for example, to determine whether any component has stopped executing unexpectedly. In addition, the system controller 202 provides an interface through which other framework components can obtain system configuration and status information. Since the software framework 200 is modular, the system controller 202 is independent of the components in the framework it manages, so that errors and changes that occur in the components are not executed or structured by the system controller. Will not affect.

  As described above, the framework 200 is configured such that various extensions can be added and deleted without changing the system architecture. In certain embodiments, an extension executing within framework 200 may include multiple executable components that together implement the full functionality of the extension. In such embodiments, the extension may include an extension controller similar to the system controller 202 that is operable to activate, terminate, and monitor various executable components associated with the extension. For example, at system startup, the system controller 202 may initiate an expansion controller that corresponds to the medical modality, and then the expansion controller may in turn start executable components associated with the modality. In some embodiments, the extended controller may not be assigned until the system controller 202 associates them with certain modalities or other system tasks via configuration mechanisms, 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 multi-modality medical detection workflow. The workflow controller component 204 can govern the workflow executed by the processing framework 200 in a variety of different ways.

  The processing framework 200 includes an event log component 206 that is configured to log messages received from various components of the processing framework. For example, during system startup, the system controller 202 can send a message regarding the status of the started component to the event log component 206, which sequentially writes messages to a log file in a standardized format. In addition, the processing framework 200 is configured to manage limited system resource sharing between various executable components of the framework 202 during a multi-modality medical detection and / or treatment workflow. A resource arbiter component 208 is included. For example, during a multi-modality workflow, two or more components associated with different modalities within the processing framework 202 may contend for the same system resources, such as a graphical display on the main controller 120. The resource arbiter component 208 can put together limited system resource sharing in various ways, for example through a lock system, a queue system, or a hierarchical collision management system.

  In some embodiments, the 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 are 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 in which executable components are implemented in the FPGA, the system controller 202 is configured to dynamically change the programmable logic in the FPGA to implement the various functions required at that time. May be. As in this aspect, the processing system 101 may include one or more unassigned FPGAs that can be assigned by the system controller during system startup. For example, if the system controller detects an OCT-PIM and associated catheter at startup of the processing system 101, the expansion controller associated with this system controller or OCT function is programmable in one of the unassigned FPGAs. The logic can be dynamically translated so that it includes functionality for receiving and / or processing OCT medical data.

  In order to facilitate inter-system communication between different hardware and software components in the multi-modality processing system 101, the processing framework 200 further includes a message delivery component 210. In some embodiments, the message delivery component 210 is configured to receive messages from components in the framework 202, determine the intended goal of the message, and deliver the message in a timely manner ( That is, the message delivery component is a participant who is active in delivering the message). In such embodiments, message metadata may be generated by this sending component, which includes destination information, payload data (eg, modality type, patient data, etc.), priority information, timing information, or Including other such information. In another embodiment, the message delivery component 210 receives a message from a component in the framework 202, temporarily stores the message, and utilizes the message for retrieval by other components in the framework. (I.e., the message delivery component is a passive queue). In any case, message delivery component 210 facilitates communication between components that are executable on framework 200. For example, the system controller 202 uses the message delivery component 210 to investigate the status of the component to be activated during the system startup sequence, and regarding the reception status information, the system controller 202 uses the message delivery component to determine the status information. Can be sent to the event log component 206 so that it can be written to a log file. Similarly, the resource arbiter component 208 can utilize the message delivery component 210 to pass resource tokens between components that request access to limited resources.

  In one embodiment, where the message delivery component 210 is a passive queue, a component of the framework 200 may packetize medical detection data that comes into the message and other components, such as images The message can be sent to a queue of message delivery components that can be obtained by the data processing component. Further, in some embodiments, the message delivery component 210 receives a message that arrives first in the queue in a first-in first-out (FIFO) manner, first deleting the first queue. It is operable to make the message available. In an alternative embodiment, the message delivery component 210 can create a message that can be used, for example, in different ways, depending on the priority value stored in the message header. In some embodiments, the message delivery component 210 is implemented in random access memory (RAM) at the processing system 101, while in other embodiments it is non-volatile RAM (NVRAM), secondary storage (eg, magnetic Dynamic hard drive, flash memory, etc.), or network-based storage. Further, in certain embodiments, messages stored in message delivery component 210 can be accessed by software and hardware modules at processing system 101 using direct memory access (DMA).

  The process framework 202 further includes a number of additional system components that provide core system functionality, which includes a security component 212, a multi-modality case management (MMCM) component 214, and a database management component 216. . In certain embodiments, the security component 212 is configured to provide various security services to the entire processing framework and to individual components. For example, a component that implements an IVUS data acquisition workflow may utilize an encrypted application programming interface (API) exposed by the security component 212 to send this IVUS data before it is transmitted over a network connection. It may be encrypted. Further, the security component 212 can provide other security services, such as system level authentication and authorization services, to restrict and extend access to the processing framework for qualified users. The execution of untrusted components within the framework can be prevented. The multi-modality case management (MMCM) component 214 is configured to organize and enhance diagnostic data associated with multiple medical modalities into a unified patient chart that can be more easily managed. Such a unified patient chart can be stored more efficiently in the database and is more suitable for data archiving and retrieval. In that regard, the database management component 216 is configured to provide a transparent database service to other components of the framework 200, and database connection and management details are hidden from the other components. For example, in certain embodiments, the database management component 216 may expose an API that includes database storage and search functionality to components of the framework 200. In other words, the medical detection workflow component may be able to send diagnostic data through the database component to a local and / or remote database, such as a DICOM or PACS server, without being aware of the details of the database connection. . In other embodiments, the database management component 216 may be operable to perform additional and / or other database services, such as a data formatting service that prepares diagnostic data for database archiving.

  As described above, the processing framework 200 of the multi-modality processing system 101 is operable to receive and process medical data associated with multiple modalities. In this regard, the processing framework 200 includes a module acquisition component and a workflow component, each associated with a different medical detection and diagnostic modality. For example, as shown in the embodiment illustrated in FIG. 2, the processing framework 200 is configured to receive and process IVUS medical detection data from the IVUS-PIM 112, respectively. And an IVUS workflow component 222. Depending on the modules and extensibility of the processing framework 200, any number of additional acquisition and workflow components may acquire and process data from the modality “N” PIM 228, modality “N” acquisition component 224 and modality. As indicated by the “N” workflow component 226, it may be added to the framework independently. For example, in certain embodiments, the processing system 101 may be communicatively coupled to an OCT-PIM 114, an ECG system 116, a reserve blood flow ratio (FFR) -PIM, a FLIVUS-PIM, and an ICE-PIM. . In other embodiments, additional and / or different medical detection, treatment, or diagnostic devices may be connected to the processing system 101 via additional and / or different data communication connections known in the art. Good. In such a scenario, in addition to the IVUS-acquisition module 220, the process framework 200 includes an FFR acquisition component for receiving FFR data from the FFR-PIM and a FLIVUS acquisition component for receiving FLIVUS data from the FLIVUS-PIM. An ICE acquisition component for receiving ICE data from the ICE-PIM, and the OCT acquisition component is operable to receive OCT data from the OCT-PIM. In this context, medical data communicated between the executable components of the processing framework 200 and a communicatively connected medical device (eg, PIM, catheter, etc.) may include data collected by sensors, control signals, It may also include power levels, device feedback, and other medical data regarding detection, treatment or diagnostic procedures. Further, in certain embodiments, the patient treatment device may be communicatively connected to the processing system 101, such as radio frequency ablation (RFA), cryotherapy, or atherectomy and any PIM or such It may be a device associated with another controller associated with the treatment procedure. In such an embodiment, the modality “N” acquisition component 224 and the modality “N” workflow component 226 are located on the treatment device, for example, by relaying control signals, by relaying power levels, by receiving device feedback. Receiving data collected by the sensors can be configured to communicate with and manage the treatment device.

  In one embodiment, once acquisition components 220 and 224 receive data from a connected medical detection device, the component packetizes the data into messages to facilitate communication between the systems. Specifically, the component may be operable to create a plurality of messages from an input digital data stream, each message including digitized medical detection data and a portion of the header. The message header includes metadata associated with medical detection data included in the message. Further, in some embodiments, the acquisition components 220 and 224 may, in some way, digitize medical detection data before the digitized medical detection data is communicated to other parts of the framework 200. May be operable to operate. 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 assist in post-processing of the data. May be. In some embodiments, this operation may be modality specific. For example, the IVUS-acquisition component 220 may identify and discard the redundant IVUS-data before it is passed to save processing time in subsequent steps. The acquisition components 220 and 224 may additionally perform a number of tasks related to data acquisition, including responding to interrupts generated by the data bus (eg, PCIe, USB), which Detecting whether a medical detection device is connected to the processing system 101, obtaining information about the connected medical detection device, storing data specific to the detection device, and allocating resources to the database. It is done. As described 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 data bus software layer (eg, through the use of an API) and by a third party to facilitate acquisition of data from a third party medical detection device. It may be created.

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

The process framework 200 is further acquired and processed by any one of the other acquisition components in the framework to acquire and process data from any number of data collection tools 234. Including a simultaneous registration interface component 230 and a simultaneous registration workflow component 232 configured to register simultaneously with the registered data. More particularly, the co-registration interface component 230 can be operable to interface communicatively with any number of modalities, eg, the ECG device 116 or the angiographic system 117 of FIG. Can do. In certain embodiments, the interface component 230 can be operable to standardize and / or convert incoming modality data so that the data is acquired by the processing system 101. Can be registered simultaneously with the detected data. Since the medical data is obtained by the co-registration interface component 230, the co-registration workflow component 232, for example, by synchronizing data collection between medical detection devices spatially or temporally and spatially. Humans by aligning two or more acquired data sets based on static and temporal registration markers and allowing co-registered diagnostic images or clinicians to assess patient status It is configured to facilitate simultaneous registration of data from different modalities by generating other readable data. Further, in other embodiments, the co-registration workflow component 232 uses a previously collected 2-D image or 3D model to collect catheters in a two-dimensional (2-D) or three-dimensional (3-D) space. Data may be operable to spatially register simultaneously. For example, a catheter-based detection tool may include criteria that are tracked to generate location data during a detection procedure, and the co-registration workflow component 232 may use this location for previously acquired MRI data. Data can be registered. Further, the simultaneous registration workflow component 232 can facilitate simultaneous registration of multi-modality data acquired by native acquisition components within the framework 200, such as the IVUS acquisition component 220 and the modality “N” acquisition component 224. . In addition, in some embodiments, a real time clock may be incorporated into the co-registration workflow component 232.
US Provisional Patent Application No. 61 / 473,91, entitled “Distributed Medical Detection System and Method”, discloses in more detail about temporal synchronization of medical detection data collection, and is fully incorporated herein by reference. Incorporated as a reference.

  As described above with respect to FIG. 1, a clinician utilizing the processing system 101 can manage the workflow and review diagnostic images through the main controller 120 and the bedside controller 118. 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 respectively correspond to medical detection modalities and to manage associated acquisition workflows and to display processed detection data. The user interface is operable to render. Similar to the processing framework 200, the UI frameworks 240 and 242 are extensible in that they support mutually independent UI extensions. That is, its modular design fits additional medical detection modality user interfaces without requiring UI frameworks 240 and 242 to affect existing user interfaces or to change the underlying UI architecture. Allows to be extended to. In the illustrated embodiment, the main controller 120 includes a system UI extension 244 that renders a user interface including core system management and configuration options. For example, the clinician can use the user interface rendered by the system UI extension 244 to start, stop, or otherwise manage the processing system 101. In certain embodiments, the components of the main controller 120 can be considered part of the 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 be displayed. Similarly, the modality “N” UI extensions 250 and 252 render management and images associated with the modality “N” workflow.

  In some embodiments, UI framework services 240 and 242 may expose APIs that UI extensions use when calling to access system resources, such as look and feel toolbox and error handling resources. . The look and feel toolbox API allows the UI extensions to present a standardized user interface with common buttons, parallel workflow formats, and data presentation schemes for different such modality workflows. In this way, the clinician can more easily transition between acquisition modalities without additional user interface training. Further, the co-registration UI extension can present and / or combine processed image or signaling data from multiple modalities. For example, a UI extension may cause an electrocardiogram (ECG) to display waves adjacent to the IVUS image data and display an IVUS image with the borders previously drawn on the OCT image overlaid. Further, in some embodiments, UI framework services 240 and 242 may include a multitasking framework for coordinating to perform UI extensions simultaneously. For example, if the processing system 101 obtains data associated with more than one modality at the same time, the UI framework services 240 and 242 may present a modality selection screen to the user to select the desired user interface. Also good.

  The UI framework service 240 communicates with the components of the processing framework 200 via the message delivery component 210. As shown in the embodiment shown in FIG. 2, the bedside controller 118 may be communicatively connected to the processing framework 200 via a network connection 254. The 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 be connected to the processing framework 200 with a local bus connection, eg, (PCIe) data bus connection, USB connection, Thunderbolt connection, FireWire connection, or any number Communication may be via other high speed data bus connections. Further, in the embodiment shown in FIG. 2, the bedside controller is configured to facilitate message-based communication between UI extensions in the bedside controller 118 and components in the processing framework 200. A message delivery component 256. In certain embodiments, message delivery component 256 may extract diagnostic image data from network communication packets as they arrive via this network connection 254.

  The process framework 200 includes additional components that allow a clinician to access and / or manage the workflows executed on the multi-modality processing system 101. For example, the framework 200 includes a remote access component 260 that communicatively connects the network console 130 (FIG. 1) to the processing framework 200. In some embodiments, the remote access component 260 is operable to export the management functions of the processing system 101 to the network console 130, whereby the network console presents workflow management functions within its user interface. be able to. In certain embodiments, remote access component 260 receives workflow commands from network console 130 and forwards them to remote access workflow component 262. The remote access workflow component 262 can direct the command set and diagnostic data to where the remote user can access via the network console 130. In addition, legacy management component 264 and legacy management workflow component 266 provide users of legacy console 268 (eg, button console, mouse, keyboard, standalone monitor) with several levels of modality workflow management and access to data. .

  In certain embodiments, additional components, such as the core system components of processing framework 200 and components associated with such modalities, are implemented as processor executable software stored on a fixed computer-readable storage medium. However, in alternative embodiments, these components may be hardware components such as special purpose microprocessors, field programmable gate arrays (FPGAs), microcontrollers, graphics processing units (GPUs), digital signals. 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 recognize that the processing framework 200 of FIG. 2 is merely an exemplary embodiment, and in alternative embodiments, the framework may include different and / or include additional components, It will be recognized that the detection workflow is configured to execute. For example, the processing framework 200 may be an executable component configured to assess human vascular stenosis, or an executable component configured to facilitate the management of computer-assisted surgery or remotely managed surgery. May be included.

  Next, FIG. 3A shows a functional block diagram of a portion of the processing framework 200 associated with a multi-modality case management (MMCM) workflow component 214. As described above, the multi-modality case management (MMCM) component 214 is configured to combine and enhance patient medical data associated with multiple medical modalities into a unified patient chart that can be more easily managed. Is done. Specifically, in the illustrated embodiment, the MMCM workflow component 214 associates a unique identifier (UID) with all aspects of a patient case, including the medical data and patient acquired from the medical device, Includes both acquired data and metadata (unacquired data) describing the procedure. The UID may be a number, alphanumeric key, hexadecimal value, or any other item that can be used to uniquely identify the patient. The metadata associated with the UID includes identification information about the patient (eg, patient name, gender, date of birth, social security number, blood type, etc.) and derived data associated with the acquired medical data (measurement, blood vessel Information such as boundaries generated on internal images), annotations on images generated from acquired medical data (blood vessel names, physician notes, internal structure identification, etc.), and information about procedures performed on the patient (eg, , Procedure time, procedure location, physician name, medical equipment used, etc.). Assigning a common unique identifier to both patient metadata and acquired data creates the strong relevance required for efficient data retrieval and analysis (i.e., measurements are within a single vessel) It needs to be associated with the image; the vessel name annotation must be associated with every frame of the multi-frame image). Further, in the illustrated embodiment, a common unique identifier is assigned to all data obtained from the patient regardless of the modality of the data. For example, a patient will typically experience a number of different diagnostic procedures, allowing the physician to more fully assess the patient's condition. In that regard, the data acquired during the IVUS procedure for the patient can be assigned the same UID as the data acquired during the OCT procedure for the patient. In some examples, the procedure may be performed between a single catheter lab session, and in other examples, the procedure may be multiple sessions separated by hours, days, months, or years. May be performed during In any case, all diagnostic and / or treatment data obtained from the same patient is assigned the same unique identifier for improved patient diagnosis and ultimately treatment.

  The MMCM workflow component 214 shown in FIG. 3A organizes common UID assignments for all metadata and acquired data related to patient cases. Specifically, the modality-specific workflow components, such as IVUS workflow component 222 and modality N workflow component 226, were obtained from a patient using a medical instrument, such as a catheter-based transducer, utilizing MMCM workflow component 214. Store medical data. In one embodiment, the MMCM workflow component 214 exposes a library of storage-related functions to the modality workflow component so that they can be stored and patient data can be retrieved from specified storage media. In this way, the storage of acquired data is handled in a unified way, rather than implementing a unique storage mechanism, such as a file management mechanism and a data format mechanism, in each modality component. In one aspect, when the MMCM workflow component 214 receives a storage / retrieval request from a modality-specific component, it receives a single patient metadata set from medical data obtained from patients across multiple modalities. Can be put together.

The MMCM workflow component 214 includes an MMCM logic component 302 that implements library storage and retrieval functions called by the modality-specific component. In some embodiments, the MMCM logic component 302 can be implemented as a hierarchical state machine, but in other embodiments it can 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, a single patient case can be “open” in time within the processing framework 200, and the MMCM logic component 302 can ensure that all data acquired or entered by a physician is included in the case. Ensures that it is associated with the same study (case) UID while it is open. During a diagnostic procedure for acquiring data from a patient, the MMCM logic component 302 assigns a temporary UID to the acquired data and stores it in the data repository 304.
Data repository 304 may implement any type of logic data container, eg, a database, and is stored on any type of storage medium, eg, as a hard drive on multi-modality processing system 101 or at a storage location on a network. May be. 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 stored in the repository 304 in association with the same UID. 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. Those skilled in the art will appreciate that the organization of data in repository 304 is just one example, and all data associated with a patient case is in many different ways, such as database tables, data structures, hash tables, stacks, queues, It will be recognized that a link list or the like and a UID can be put together. In one example, all data associated with a medical modality is stored together in a logical data partition, but each data set in a group of modality data is associated with a UID corresponding to the patient case to which it belongs. Also good. Further, the acquired patient data may be stored in the repository 304 in many different formats. For example, it may be stored in a “raw” form that does not change from the format generated by the acquiring medical device, or it may be stored as a processed form, for example, an IVUS image in a blood vessel. As described above, data associated with one UID may be collected across multiple clinical sessions or may be collected during a single session.

  Further, in some embodiments, each hierarchical level of data in the patient chart has its own identifier, so that there is a unique identifier chain that links all patient data together. A specific example of a patient case having 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 may have a globally unique identifier as a patient case UID as shown in FIG. 3B. A patient case may include one or more patient studies, each patient study including all data collected during a catheter lab session. Each patient study may include a unique unique identifier that is linked to a global patient case unique identifier. Further, each patient study can then include one or more data sets (or series) composed of data for a particular medical modality. For example, patient studies may include IVUS series, OCT series, and FFR series, all acquired during a single catheter lab session, each series having its own unique link linked to a patient study unique identifier Have identifiers. In addition, each data set or series may include one or more diagnostic images, each image having its own unique identifier that is linked to a data set specific identifier. Thus, the unique identifier at each data level forms a chain of ownership that links together patient metadata, patient studies, datasets (series), and individual images within a patient case.

  In addition, the use of unique identifiers for all data contained in patient cases simplifies data management within the multi-modality processing system 101. This scheme allows all patient cases, or portions of individual data within patient cases, to be identified and addressed. For example, when reviewing patient data by a physician, the MMCM logic component 302 uses a UID associated with the patient case to access all acquired diagnostics without worrying about modality with a single access to the repository. Data can be retrieved. Alternatively, the 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 the patient can be deleted simultaneously using the UID associated with the patient without concern for the modality.

  In addition, the MMCM logic component 302 can interact with the data archive component 314 when a request to archive patient data is made by a physician. Specifically, as will be described in more detail in connection with FIGS. 14-15, the physician may choose to archive all or a portion of the patient cases in the storage medium 316. The storage medium 316 may be a removable medium 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 disk. It can be a drive, a DICOM server, or another networked archive repository. In some embodiments, in response to an archive request, the MMCM logic component 302 may retrieve all data associated with the patient case from the repository 304 via the corresponding UID, which is then associated with the UID. It may be sent to the archived data archive component 314. In such a scenario, restoration of archived data can be accomplished with reference to the UID. Further, the data archive component 314 is configured to anonymize data on demand before it is archived. In an embodiment, all identification information about a patient may be deleted 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 managing patient cases. Specifically, the MMCM GUI component 320 renders UI screens associated with creating new patient cases, collecting patient identification information, managing previously acquired modality data, and archiving patient diagnostic data.
As one aspect of this, the MMCM GUI component 320 is configured to interpret user commands entered in association with a user interface. Screens related to patient case management may be collectively referred to as a 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 have simplified aspects of the processing framework 200 associated with the MMCM workflow component 214 shown in FIG. 3A and that additional and / or different components execute within the framework for managing patient case data. You will recognize what you can do. For example, the MMCM logic component 302 may utilize one or more database communication components to organize the transmission of data to and from the repository 304. Further, in some embodiments, each modality-specific workflow component can independently handle storage of acquired diagnostic data. In such a scenario, each modality-specific workflow component queries the MMCM workflow component 214 for a UID corresponding to the currently open patient case, and uses the UID to store the acquired diagnostic data in a dedicated storage container. To remember. Furthermore, the MMCM workflow component 214 can store patient metadata in another MMCM storage container along with the corresponding UID.

  Next, FIG. 4 is a simplified flow diagram of patient case management in the multi-modality processing system 101. As described above, the MMCM workflow component 214 enhances the management of patient data that is acquired and not acquired within the multi-modality processing system 101. The MMCM workflow controller 214 controls and manages both front-end user interface and back-end data storage. The front-end user interface includes a number of screens for efficiently guiding the practitioner through the patient case workflow. First, the identification information input screen 402 allows a doctor to input identification information about a new patient to the multi-modality processing system 101 first. 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. Further, the identification information input screen 402 can be used to edit previously stored patient information. By using a common unique identifier for all acquired patient data, the physician only needs to enter the patient identification information once when the patient case is initialized without concern for modalities. In this way, data entry errors are reduced and patient identification information is guaranteed to be linked to correctly acquired diagnostic data. In an alternative embodiment, patient identification information can be retrieved from an external patient data repository, such as a hospital information system (HIS). In such a case, the identification information input screen 402 may instruct the doctor about the network connection information for the external data repository, thereby enabling acquisition of patient metadata.

Returning to FIG. 4, after the physician enters the patient's metadata 404 into the screen 402, the patient case is initialized and the metadata 404 is sent to the MMCM workflow component 214 where this metadata is associated with the UID 406. . The UID 406 may be a UID entered on the screen 402 or it may be a UID generated by an MMCM workflow component. After the patient metadata 404 is associated with the UID 406, the MMCM workflow component 214 stores the metadata in the data repository 304. When 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. The modality data acquisition screen 408 facilitates acquisition of diagnostic data received from a medical device inside or outside the patient. A specific example of the modality data acquisition screen 408 is shown in detail in FIG. A screen example 408 shows an IVUS acquisition workflow.
An image of the patient's blood vessel, 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 a user interface extension that renders the screen necessary to perform a diagnostic procedure associated with the particular modality. Screens associated with data management rendered by the MMCM workflow component 214 and 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). The Returning to FIG. 4, the patient medical data 410 associated with the first modality captured via the modality data acquisition screen 408 is transferred 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 the data repository 304. As such, patient metadata 404 and patient medical data 406 are both associated with UID 406 and stored in data repository 304. In some embodiments, the medical data 410 may be stored in the data repository 304 in a format received from a medical device, while in other embodiments, the medical data is processed data, such as IVUS or OCT images. It may be stored.

In the 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 from 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 without worrying about when the acquisition occurred. A second modality data acquisition screen 412 is presented to guide the doctor through the second acquisition workflow. A specific example of the modality data acquisition screen 412 is shown in detail in FIG. Screen example 412 shows the FFR diagnostic procedure. Screen 412 presents the physician with data representing blood flow through the patient's blood vessel, acquired by a sensor placed in the blood vessel.
Returning to FIG. 4, patient medical data 414 captured in association with the second data acquisition screen 412 has an MMCM where the same UID 406 is associated with the data and this data is stored in the data repository 304. Sent to the workflow component 214.

  After diagnostic data associated with one or more modalities is acquired from a patient, an acquisition data management screen 416 allows a physician to review and manage the acquired data set. A specific example of the acquired data management screen 416 is shown in detail in FIG. Screen 416 includes a case log that displays a selectable representation of all acquisition procedures performed on the patient without regard to 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, the example screen 416 includes both IVUS and FFR data sets obtained from the same patient. The selectable representations displayed on screen 416 may correspond to data sets acquired over a time, day, week, or year period, or they are separate data sets acquired within the same procedure. It may correspond to.

  In one embodiment, to render the screen 416, the MMCM GUI component 320 queries the data repository 304 for a list of all collected data sets associated with the UID corresponding to the open patient case. In example screen 416, all data sets are associated with a unique identifier 123456, and the selectable representations are organized by modality type. Further, in the illustrated embodiment, each selectable representation of the data set includes the title of the data set and whether the data set includes any bookmarks that highlight important patient characteristics, and the data set is obtained. Display the date and time In other embodiments, additional information may be displayed in association with each selectable representation of the data set. In addition, 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 data and / or images included in the selected data set. However, in some embodiments, selecting a representation that can be selected on screen 416 causes the UI to display additional information about the selected dataset in screen 416, for example in a drop-down preview pane. Let For example, FIG. 9 shows a scenario where a doctor has selected a data set titled “UNITITLED01”. Additional information about the data, such as acquisition time, pullback rate, and bookmarks in the data set, is displayed under a selectable representation of the data set. Further, as shown in the illustrated embodiment, a preview of the image data included in the data set may be additionally displayed. Within the drop-down preview pane, a button for deleting the data set, a button for loading the data set, and a button for displaying additional information about the data set can be selected by the physician. In addition, in some embodiments, the screen 416 allows a physician to select multiple selectable representations of the data set for comparison purposes. Therefore, a doctor reviewing the acquired data management screen 416 can review and manage all acquired data sets associated with the patient without worrying about modalities. In this way, the amount of time that the doctor must spend reviewing the patient's medical data is reduced, leading to more efficient diagnosis and treatment.

  Next, FIG. 10 shows a large number of patient acquisition data management screens 418. The data management screen 418 is similar to the data management screen 416, but it is configured to display a selectable representation of a data set associated with multiple patient cases. Each selectable representation of a patient case includes information about the patient case, such as patient name, unique identifier (UID), procedure date, physician, modality / mode, whether the data set is archived, Includes data set 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 display order of the patient cases listed on the data management screen 418 may be arranged according to one or more information categories associated with each patient case. Further, in some embodiments, as shown in FIG. 10, when a physician selects a toggle element associated with a selectable representation of a patient case, an individual data set comprising the selected patient case is displayed. The All acquired data sets associated with patient cases are displayed below the selectable representation without concern for medical modalities. In one implementation of screen 418, a first patient case is selected and a data set associated with IVUS and FFR procedures is displayed. In addition, multiple patient acquisition data management screens 418 are configured to allow a physician to acquire and open patient cases by selecting one or more displayed selectable expressions. Is done. If a selectable representation of the patient case is selected on screen 418, MMCM GUI component 320 queries data repository 304 using the associated UID to obtain a data set associated with the patient. . In some embodiments, the selected patient case may be obtained from a local or network-based hard drive, while in other embodiments the selected patient case is removable media such as a DVD, Blu-ray disc, or It may be obtained from a flash-based drive. Therefore, a doctor reviewing a large number of patient acquisition data management screens 418 can easily review and manage all patient cases including all acquisition data sets included in the patient cases without concern for modalities. it can. In this way, the physician can efficiently identify and compare relevant patient cases, thereby facilitating efficient diagnosis and treatment.

  Referencing and returning immediately to FIG. 4, the physician reviewing the acquired data management screen 416 may select a particular data set for more detailed review, as described above. 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 selected medical data UID. As shown in the embodiment shown in FIG. 4, once the selected patient medical data 422 is acquired from the data repository 304, it is displayed to the requesting physician via the acquired medical data display screen 424. In this regard, one specific example of the acquired medical data display screen 424 is shown in FIG. The example display screen 424 shows the image data set captured during the IVUS procedure. In reviewing IVUS images, the physician may take measurements and add labels and other annotations to the IVUS images in the data set. In that regard, methods and systems for enhanced measurement, manipulation, navigation, display, and annotation of multi-modality medical images are described in US Provisional Patent Application No. XX / XXX, XXX (Application No. 44755.104). "DATA Labeling and Indexing in Modality Diagnostic System", US Provisional Patent Application Nos. XX / XXX, XXX (Application No. 44755.142), "Measurement and Enhancement in Multimodality Diagnostic System", US Provisional Patent Application No. XX / XXX, XXX (application number 44755.104), the name “gesture-based interface for multi-modality imaging system”, and US provisional patent application XX / XXX, XXX (application number 44755.1044), name “multi-modality imaging. system Definitive measurement Navigation "is also disclosed, and all their entirety in this disclosure are incorporated by reference.

  As described above, in some embodiments, the acquired data management screen 416 may allow the physician to select multiple selectable representations of the data set for comparison purposes. In such a scenario, 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 a diagram showing another example of the acquired medical data display screen 424 that shows two IVUS images side by side. The two IVUS images may be from a data set acquired during two different IVUS procedures performed on the patient. By side-by-side comparison of patient images acquired at different times, a doctor can efficiently determine the change in patient symptoms over time. In addition, 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 shown simultaneously with FFR data collected from the same patient. IVUS data and FFR data may be collected during the same catheter lab procedure or during different catheter lab procedures. The MMCM workflow component 214 may include a synchronization component that synchronizes the multi-modality data displayed on the screen 424 spatially or temporally. Those skilled in the art will recognize that the screen 424 of FIG. 13 is only an example and that data of 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, eg, X-ray angiography (XA) data, external to the multi-modality processing system 101 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 the 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 way, any annotations, measurements, etc. are closely associated with the corresponding acquired data, facilitating efficient searching and subsequent review.

  Those skilled in the art will appreciate that the patient case management system and method described in connection with FIGS. 4-13 is merely an exemplary embodiment, and in alternative embodiments, additional and / or different steps may be performed, It will be appreciated 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 the writing and retrieving of 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. Further, screens 402, 408, 412, 416, and 424 are merely examples, and such screens may further differ and / or to facilitate patient case management within multi-modality processing system 101. Additional features and user options may be included.

  Next, FIG. 14 is a flowchart showing another aspect of patient case management in the multi-modality processing system 101. Specifically, FIG. 14 illustrates a system and method for archiving and anonymizing patient medical data. For clarity, parts of FIG. 14 that are similar to parts of FIG. 4 are similarly labeled.

  After medical data associated with one or more modalities is obtained from the patient and stored in the data repository 304, as described above with respect to FIG. Given options. In general, archiving acquired medical data includes moving the medical data to a storage location external to the medical processing system where the medical data is acquired. In one example, the acquired medical data may be transferred to a removable storage medium, such as a writable optical disc or a portable flash-based container. In another example, acquired medical data may be transferred over a network connection to a remote data repository, such as DICOM.

  To facilitate archiving of multi-modality patient charts, the MMCM GUI component renders the acquired medical data archive screen 1400. A specific example of the acquired medical data archive screen 1400 is shown in detail in FIG. This example of the archive screen 1400 displays a list of selectable representations of patient cases available for archiving. Each selectable representation of a patient case includes information about the patient case, such as patient name, unique identifier (UID), procedure date, physician, modality / mode, whether the data set 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 clinical hospital treating the patient, and may not be 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 the archive screen 1400 may arrange one or more categories of information associated with each patient case. Each representation of a patient case can be selected, for example via a checkbox. By operating a drop-down toggle associated with one of the patient cases, the modality data set constituting the patient case is displayed. For example, the first patient case displayed on screen 1400 includes a data set generated during the IVUS procedure and a data set generated during the FFR procedure. These datasets are displayed as individually selectable representations, for example by selecting the check box to the left of the dataset representation. In other embodiments, different methods of selecting a data set can be implemented. In a further embodiment, not shown in example screen 1400, each image-based dataset (ie, IVUS dataset) is expanded within the patient case to display the individual images that make up the dataset. May be. In such an embodiment, each image can be selected individually, for example via a checkbox.

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

As described above in connection with FIG. 3A, patient cases can be archived in association with their corresponding UIDs for efficient storage management and retrieval. In some embodiments, utilization of this UID allows archiving patient cases to be updated with “new” patient data obtained after the initial archiving action. More specifically, after the patient case has been archived, screen 1400 shows only that in the “archived” information column. If a new data set was acquired in association with a previously archived patient case, screen 1400 indicates that the new data set has not been archived. The doctor can individually select the 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) finds the archived patient case via the associated UID and retrieves it. Open and insert the new data set. In other embodiments, updating an archived patient case may be performed in different ways, for example, retrieving the archived patient case data, adding the new data set, and adding new data in the updated patient case. This can be done, for example, by creating an archive.
Furthermore, in other embodiments, the MMCM workflow component prevents data from being tampered by prohibiting data from being added to previously archived cases.

  Further, in some embodiments, the archiving system of FIGS. 14 and 15 is configured to archive medical data to a location selected by the physician rather than a fixed location. For example, in the example screen 1400, the physician selects either removable media, eg, an archive to a writable optical disk, or portable flash storage, or an archive to a networked remote storage media, eg, a DICOM server. Can do. In alternative embodiments, additional and / or different archive locations can be selected by a physician, such as a local hard drive, storage area network (SAN), or cloud-based storage.

  In certain embodiments, the archiving system of FIGS. 14 and 15 is configured to archive medical data in one of a plurality of different formats according to selections by the physician on example screen 1400. In that regard, the patient medical data may be archived “as is” without changing the format, or the format may be changed (ie, changed to the format selected on the example screen 1400), Or it may be archived in a compressed format to reduce the amount of storage space required. In some embodiments, the medical data can be inserted into a dedicated or industry standard archive data container. Further, medical data archived by the illustrated archiving system may be encrypted or otherwise obfuscated to prevent unauthorized access. In some embodiments, an option for encrypting and / or restricting access to archived items may be presented on the archive screen 1400 via a password.

  The archiving element of the multi-modality processing system 101 shown in the embodiment of FIGS. 14 and 15 is further configured to selectively anonymize medical data before it is archived. For example, a physician can choose whether to delete patient identification information from medical data before it is archived. More specifically, when archiving patient cases without anonymization, all acquired modality data sets and all metadata-including patient identification information-are included in the archive container. Similarly, individual archived modality data sets and images will contain patient identification information when archived without anonymization. However, if the physician chooses to anonymize before archiving, the archiving system automatically deletes any information from the archive chart that can identify patients from the person who acquired the data . In the illustrated embodiment, the archiving system anonymizes the medical data when the “Anonymize” button on the archive screen 1400 is operated. Notably, the archiving system is configured to delete all patient identification information without being affected by the archiving physician. That is, the system first determines which data fields in the patient case contain information that can identify the patient, and then deletes any data in the identified fields. In certain embodiments, this determination is based on a configuration file that includes a predetermined set of data fields known to include identification information. In an alternative embodiment, the archive system determines the sensitive data field using a natural language processing algorithm on a case-by-case basis. Further, in some embodiments, patient identification information is obfuscated rather than deleted during the anonymization procedure. In such embodiments, obfuscated patient information can be collected by an authorized system or physician. In addition, if multiple patient cases corresponding to multiple patients are selected for archiving—and the anonymization option is selected—identification information for each different patient is deleted from the patient case, Or obfuscated.

  Thus, because multi-modality processing system 101 automatically anonymizes archived data without intervention by the physician, at least some of the removed removed patient information remains hidden from the physician or other third party data processor. Yes, this will increase the confidentiality of sensitive medical information. Furthermore, automated anonymization reduces clerical errors and ensures that all identification information is deleted without worrying about whether it is accessible via the user interface. . Further, in the archiving scenario described herein, the anonymization action is performed on the multi-modality acquisition / processing system itself before the data is sent to the remote archive storage location. For example, in embodiments where the multi-modality processing system is a portable processing system deployed 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 with a treatment system in the catheter lab.

  Returning to FIG. 14, an archive request 1402 is sent to the MMCM workflow component 214 after the physician has selected to archive one or more of the patient cases, datasets, and / or images. The archiving request is an instruction to archive selected specific medical data and whether the selected medical data needs to be anonymized. The MMCM workflow component 214 processes this request and retrieves the selected medical data 1404 from the data repository 304. If the physician indicates 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 in the archive storage medium 316. The MMCM workflow component 214 can further modify the data to be archived, for example, by compressing, encrypting, changing its format, and / or storing it in an archive data container.

  The systems and methods described above for archiving or anonymizing multi-modality medical data in a multi-modality processing system are merely exemplary embodiments, and in alternative embodiments, additional and / or different steps It is understood that the method may be included in the method and that the system may include additional and / or different user interface screens. Further, the archive screen 1400 is just one example, and it may include different and / or additional features and user options to further facilitate patient case management within the multi-modality 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 examples, some features of the present disclosure are addressed. Can be adopted without the use of other features. Also, as described above, the components and extensions described above in connection with the multi-modality processing system can be implemented in hardware, software, or a combination of both. And the processing system may be designed to operate on any particular architecture. For example, the system can run on a single computer, local area network, client server network, wide area network, the Internet, handheld and other portable wireless devices and networks. It will be 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 interpreted in a manner consistent with the scope of the present disclosure.

Claims (87)

A method of selectively archiving medical data associated with a patient using a multi-modality medical processing system:
Receiving first medical data obtained from a patient from a first medical device, wherein the first medical data is associated with a first medical modality:
Receiving second medical data obtained from a patient from a second medical device, wherein the second medical data is associated with a second medical modality different from the first medical modality; and Displaying on the user interface a selectable representation of the first medical data and the second medical data;
Receiving a user selection of one or more selectable expressions;
Receiving an archive request via the user interface; and in response to receiving the archive request, the medical data corresponding to the one or more selectable representations selected above to an archive location Archiving;
Including methods. The first medical data includes data acquired from the patient during a first acquisition procedure associated with a first medical modality, and the second medical data is associated with the second medical modality The method of claim 1, comprising data acquired from the patient during a second acquisition procedure.   The method of claim 2, wherein the first and second acquisition procedures were both performed during a single catheter lab session.   The method of claim 2, wherein the first and second acquisition procedures were performed during different catheter lab sessions.   The first medical data includes a plurality of images representing the portion of the patient, and further includes displaying a selectable representation of each image in the plurality of images on the user interface. The method of claim 1.   6. The method of claim 5, wherein archiving includes archiving only a single image if only one selectable representation of the image is selected. The method of claim 1, wherein
A patient case associated with the patient includes both the first medical data and the second medical data; and further: displaying a selectable representation of the patient case on a user interface; and the patient case Receiving a further user selection of a selectable representation of
The archiving includes archiving the first medical data and the second medical data together as part of the patient case.   The method of claim 1, wherein the archiving is performed in the same manner regardless of whether the first medical data or the second medical data is archived. The method of claim 1, further comprising:
Receiving a user selection of an archive location via the user interface;
The archiving includes archiving the medical data to the selected archive location.   The method of claim 9, wherein the archive location is one of a removable storage medium and a remote network storage repository.   The first and second medical modalities are intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, optical coherence tomography (OCT), forward vision IVUS (FL-IVUS), blood, respectively. The method according to claim 1, wherein the method is one of a flow reserve volume ratio (FFR) method and a coronary flow reserve volume ratio (CFR) method. A multi-modality medical treatment system:
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 first medical data obtained from a patient from a first medical device, the first medical data being associated with a first medical modality;
Receiving second medical data obtained from a patient from a second medical device, the second medical data being associated with a second medical modality different from the first medical modality;
Displaying a selectable representation of the first medical data and the second medical data on a user interface;
Receiving a user selection of one or more of the selectable representations;
Receiving an archive request via the user interface; and archiving medical data corresponding to the selected one or more selectable representations to an archive location in response to receiving the archive request. . The multi-modality medical processing system according to claim 12,
The first medical data includes data acquired from the patient during a first acquisition procedure associated with the first medical modality; and the second medical data is stored in the second medical modality. A system comprising data acquired from the patient during an associated second acquisition procedure. The multi-modality medical processing system according to claim 12,
The first medical data includes a plurality of images representing a portion of the patient, and the instructions are instructions for displaying a selectable representation for each image of the plurality of images on the user interface. The system further comprising: The multi-modality medical processing system according to claim 12,
A patient case associated with the patient includes both the first medical data and the second medical data; and the instructions further include instructions regarding:
Displaying a selectable representation of the patient case on a user interface; and receiving a further user selection of the selectable representation of the patient case;
Wherein the archiving includes archiving the first medical data and the second medical data together as part of the patient case.   13. The multi-modality medical processing system of claim 12, wherein the archiving is performed in the same manner regardless of whether the first medical data or the second medical data is archived. System. The multi-modality medical processing system according to claim 12,
The instructions further include instructions for receiving a user selection of the archive location via the user interface; and the archive includes archiving the medical data to the selected archive location. Feature system.   18. The multi-modality medical processing system according to claim 17, wherein the archive location is one of a removable storage medium and a remote network storage repository. The multi-modality medical processing system according to claim 12,
The instructions include further instructions for receiving:
An encryption request via the user interface; and a compression request via the user interface; and wherein the archive includes encrypting and compressing the medical data.   The multi-modality medical processing system of claim 12, wherein the first and second medical modalities are intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, and optical coherence tomography (OCT), respectively. ), Forward vision IVUS (FL-IVUS), blood flow reserve ratio (FFR) method, and coronary blood flow reserve ratio (CFR) method. In a multi-modality medical processing system, a method for anonymizing medical data acquired from a patient,
This method
Receiving first medical data obtained from the patient from a first medical device, the first medical data being associated with a first medical modality;
Receiving second medical data obtained from the patient from a second medical device, the second medical data being associated with a second medical modality different from the first medical modality;
Adding 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 of the patient case on a user interface; receiving a user selection of the selectable representation;
Receiving an anonymization request from a user via the user interface;
In response to receiving the anonymization request, deleting identification information from the patient case, the deletion being unaffected by the user, and during the deletion, at least some The identification information is hidden from the user.   The method of claim 21, wherein the identification information includes one or more of a patient's name, patient's gender, patient's birthday, patient's blood group, and patient's social security number.   23. The method of claim 21, wherein the patient case includes a unique identifier, and the deletion does not delete the unique identifier from the patient case. The method of claim 21, wherein the deletion is:
Identifying at least one data field containing the identification information; and deleting the identification information from the at least one data field.   25. The method of claim 24, wherein the identifying includes reading a configuration file that lists the at least one data field.   25. The method of claim 24, wherein the identifying comprises analyzing each data field included in the patient case to determine whether it includes the identification information. .   The method of claim 21, wherein the deleting comprises obfuscating the identification information without deleting the identification information.   24. The method of claim 21, further comprising archiving the patient case to an archive location after the deletion.   30. The method of claim 28, wherein the archive location includes at least one of a removable storage medium and a remote network-based storage repository.   24. The method of claim 21, wherein the first and second medical modalities are intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, optical coherence tomography (OCT), and forward vision, respectively. A method characterized by being one of IVUS (FL-IVUS), blood flow reserve ratio (FFR) method, and coronary blood flow reserve ratio (CFR) method. A multi-modality medical treatment system,
A fixed computer-readable storage medium that stores a plurality of instructions for execution by at least one computer processor, the instructions are:
Receiving first medical data obtained from the patient from a first medical device, the first medical data being associated with a first medical modality;
Receiving second medical data obtained from the patient from a second medical device, the second medical data being associated with a second medical modality different from the first medical modality;
Adding the first and second medical data to a patient case corresponding to the patient, the patient case including identification information about the patient;
Displaying a selectable representation of the patient case on a user interface;
Receiving a user selection of the selectable representation;
Receiving an anonymization request from a user via the user interface; and deleting the identification information from the patient case in response to receiving the anonymization request, the deletion affecting the user And at least some of the identification information is hidden from the user during this deletion,
A system characterized by that.   32. The multi-modality medical processing system of claim 31, wherein the identification information includes one or more of a patient's name, patient's gender, patient's birthday, patient's blood group, and patient's social security number. System. The multi-modality medical processing system according to claim 31,
The patient case includes a unique identifier, and the deletion does not delete the unique identifier from the patient case. 32. The multi-modality medical processing system of claim 31, wherein the deletion is:
Identifying at least one data field including the identification information; and deleting the identification information from the at least one data field.   35. The multi-modality medical processing system of claim 34, wherein the identifying includes reading a configuration file that lists the at least one data field.   35. The multi-modality medical processing system of claim 34, wherein the identifying includes analyzing each data field included in the patient case to determine whether it includes the identifying information. Feature system.   32. The multi-modality medical processing system according to claim 31, wherein the deletion includes obfuscating the identification information without deleting the identification information in the at least one data field. system.   32. The multi-modality medical processing system of claim 31, wherein the instructions further include instructions for archiving the patient case to an archive location after the deletion.   40. The multi-modality medical processing system of claim 38, wherein the archive location includes at least one of a removable storage medium and a remote network-based storage repository.   36. The multi-modality medical processing system of claim 35, wherein the first and second medical modalities are intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, and optical coherence tomography (OCT), respectively. ), Forward vision IVUS (FL-IVUS), blood flow reserve ratio (FFR) method, and coronary blood flow reserve ratio (CFR) method. A method of displaying multi-modality medical data using a multi-modality medical processing system, the method comprising:
Receiving first medical data obtained from a patient from a first medical device, the first medical data being associated with a first medical modality;
Storing the first medical data in a data repository;
Receiving second medical data for the patient from a second medical device, the second medical data being associated with a second medical modality different from the first medical modality;
Storing the second medical data in the data repository;
Displaying a selectable representation of each of the first medical data and the second medical data on a user interface;
Receiving a user selection of the selectable representation of the first medical data; and displaying the first medical data at the user interface in response to receiving the user selection. Including. 42. The method of claim 41, wherein:
Receiving a further user selection of the selectable representation of the second medical data; and simultaneously displaying the first medical data and the second medical data at the user interface. Method.   42. The method of claim 41, wherein displaying the selectable representation includes displaying the selectable representation in an order determined by metadata values associated with the first medical data and the second medical data. Displaying .. A method comprising: displaying.   44. The method of claim 43, wherein the metadata value is one of medical modality, medical data acquisition time, and physician name.   42. The method of claim 41, wherein displaying a selectable representation comprises displaying the selectable representation in a group based on the modality of the represented medical data. how to.   42. The method of claim 41, further comprising displaying additional information about the first medical data in response to a user operation of a toggle element associated with the selectable representation of the first medical data. Method.   49. The method of claim 46, wherein the additional information includes a preview image of a portion of the patient obtained from the first medical data.   48. The method of claim 46, wherein the additional information is displayed adjacent to the selectable representation of the first medical data.   49. The method of claim 46, wherein the additional information includes a pullback rate of an acquisition procedure that generated the first medical data. 42. The method of claim 41, wherein
Displaying a delete button in response to a user operation of a toggle element associated with the selectable representation of the first medical data;
Receiving a user operation of the delete button; and deleting the first medical data from the data repository in response to receiving the user operation.   42. The method of claim 41, wherein the first medical data and the second medical data are obtained from the patient during a single catheter lab session.   42. The method of claim 41, wherein the first and second medical modalities are intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, optical coherence tomography (OCT), and forward vision, respectively. A method characterized by being one of IVUS (FL-IVUS), blood flow reserve ratio (FFR) method, and coronary blood flow reserve ratio (CFR) method. A multi-modality medical treatment system,
A data repository; and a fixed computer-readable storage medium storing a plurality of instructions for execution by at least one computer processor, wherein the instructions are:
Receiving first medical data obtained from a patient from a first medical device, the first medical data being associated with a first medical modality;
Storing the first medical data in the data repository;
Receiving second medical data obtained from the patient from a second medical device, the second medical data being associated with a second medical modality different from the first medical modality;
Storing the second medical data in the data repository;
Displaying a selectable representation of each of the first medical data and the second medical data on a user interface;
Receiving a user selection of the selectable representation of the first medical data; and displaying the first medical data at the user interface in response to receiving the user selection. ,system. 54. The multi-modality medical processing system of claim 53, wherein the instructions include the following instructions:
Receiving a further user selection of the selectable representation of the second medical data; and simultaneously displaying the first medical data and the second medical data at the user interface.   54. The multi-modality medical processing system of claim 53, wherein displaying a selectable representation is the selection in an order determined by metadata values associated with the first medical data and the second medical data. A system characterized by comprising displaying possible representations.   56. The multi-modality medical processing system according to claim 55, wherein the metadata value is one of a medical modality, a medical data acquisition time, and a physician name.   54. The multi-modality medical processing system of claim 53, wherein displaying a selectable representation includes displaying the selectable representation in a group based on the modality of the represented medical data. A system characterized by that.   54. The multi-modality medical processing system of claim 53, wherein the instructions are additional information about the first medical data in response to a user operation of a toggle element associated with the selectable representation of the first medical data. A system further comprising instructions for displaying.   59. The multi-modality medical processing system of claim 58, wherein the additional information includes a preview image of a portion of the patient obtained from the first medical data.   59. The multi-modality medical processing system of claim 58, wherein the additional information is displayed adjacent to the selectable representation of the first medical data.   59. The multi-modality medical processing system of claim 58, wherein the additional information includes a pullback rate of an acquisition procedure that generated the first medical data. 54. The multi-modality medical processing system of claim 53, wherein the instructions include further instructions regarding:
Displaying a delete button in response to a user operation of a toggle element associated with the selectable representation of the first medical data;
Receiving a user operation of the delete button; and deleting the first medical data from the data repository in response to receiving the user operation.   54. The multi-modality medical processing system of claim 53, wherein the first medical data and the second medical data are acquired from the patient during a single catheter lab session.   54. The multi-modality medical processing system of claim 53, wherein the first and second medical modalities are intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, and optical coherence tomography (OCT), respectively. ), Forward vision IVUS (FL-IVUS), blood flow reserve ratio (FFR) method, and coronary blood flow reserve ratio (CFR) method. A method of multi-modality medical case management in a multi-modality medical processing system, the method comprising:
Receiving identification information about the patient at the multi-modality medical processing system;
Generating a unique identifier corresponding to the patient;
Associating the unique identifier with the identification information;
Receiving first medical data obtained from the patient from a first medical device at the multi-modality medical processing system, the first medical data being associated with a first medical modality;
Storing the first medical data in a data repository, the first medical data being associated with the unique identifier in the data repository;
Receiving the second medical data acquired from the patient from the second medical device in the multi-modality medical processing system; the second medical data is different from the first medical modality; Storing the second medical data in the data repository, wherein the second medical data is associated with the unique identifier in the data repository.   68. The method of claim 65, further comprising obtaining the first medical data and the second medical data from the data repository using the unique identifier.   66. The method of claim 65, further comprising deleting the first medical data and the second medical data from the data repository using the unique identifier.   68. The method of claim 65, further comprising storing data obtained from the first medical data in the data repository, wherein the data obtained from the first medical data is in the data repository, A method associated with the unique identifier. 68. The method of claim 65, wherein:
Generating measurement data corresponding to one of the first medical data and the second medical data; and storing the measurement data in the data repository, wherein the measurement data is stored in the data repository Associated with the unique identifier.   70. The method of claim 69, wherein the measurement data corresponds to a blood vessel diameter in the patient.   66. The method of claim 65, wherein the first medical data includes an image representing a portion of the patient. 72. The method of claim 71, wherein
Generating an annotation in the image; and storing the annotation in the data repository, the annotation being associated with the unique identifier in a data repository.   75. The method of claim 72, wherein the annotation includes one or more of a blood vessel name and a physician note.   66. The method of claim 65, wherein the identification information includes one or more of a patient's name, patient's gender, patient's birthday, and patient's blood type. 68. The method of claim 65, wherein:
Receiving information about the acquisition procedure that generated the first medical data; and storing information about the acquisition procedure in the data repository, wherein the information about the acquisition procedure is at the data repository, Further associated with the unique identifier.   76. The method of claim 75, wherein the information about the obtaining procedure includes one or more of a physician name, a procedure time, and information about the first medical device.   66. The method of claim 65, wherein the first and second medical modalities are intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, optical coherence tomography (OCT), forward vision, respectively. A method characterized by being one of IVUS (FL-IVUS), blood flow reserve ratio (FFR) method, and coronary blood flow reserve ratio (CFR) method.   66. The method of claim 65, wherein storing the first medical data in the data repository and storing the second medical data in the data repository are within the multi-modality medical processing system. A method characterized in that both are performed by the same workflow component to execute.   68. The method of claim 65, wherein the data repository includes an XML database.   66. The method of claim 65, wherein the first medical data and the second medical data were obtained from the patient during a single catheter lab session. A multi-modality medical treatment system:
A data repository; and a fixed computer-readable storage medium storing a plurality of instructions for execution by at least one computer processor, the instructions being:
Receiving identification information about the patient;
Generating a unique identifier corresponding to the patient;
Associating the unique identifier with the identification information;
Receiving first medical data acquired from the patient from a first medical device communicatively connected to the multi-modality medical processing system, the first medical data being transmitted to the first medical modality; Associated with;
Storing the first medical data in the data repository, the first medical data being associated with the unique identifier in the data repository;
Receiving second medical data acquired from the patient from a second medical device communicatively connected to the multi-modality medical processing system, the second medical data being the first medical modality Associated with a different second 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; ,system. A multi-modality medical treatment system,
A user interface component that includes a computing system communicatively coupled to the first medical device and the second medical device, the computing system configured to receive identification information about the patient;
A first modality workflow component configured to receive first medical data obtained from the patient from the first medical device, wherein the first medical data is in a first medical modality;
A second modality workflow component configured to receive second medical data obtained from the patient from the second medical device, wherein the second medical data is different from the first medical modality. In two medical modalities;
A multi-modality case management (MMCM) workflow component configured to associate the identification information, the first medical data and the second medical data with a unique identifier; and the identification information, the first medical data and A data repository configured to store the second medical data in association with the unique identifier.   83. The multi-modality medical processing system of claim 82, wherein the MMCM workflow component uses the unique identifier to retrieve and / or delete the first medical data and second medical data from the data repository. A system further configured to:   83. The multi-modality medical processing system of claim 82, wherein the MMCM workflow component is further configured to store data obtained from the first medical data in the data repository, from the first medical data The obtained data is associated with the unique identifier in the data repository. 83. The multi-modality medical processing system of claim 82,
The user interface component is further configured to generate measurement data corresponding to one of the first medical data and the second medical data; and the MMCM workflow component is the measurement A system further configured to store data in the data repository, wherein the measurement data is associated with the unique identifier in the data repository.   83. The multi-modality medical processing system of claim 82, wherein the MMCM workflow component receives information about an acquisition procedure that generated the first medical data, and stores the information about the acquisition procedure in the data repository. A system further configured to store, wherein the information about the retrieval procedure is associated with the unique identifier in the data repository. 83. The multi-modality medical processing system of claim 82, wherein the first and second medical modalities are respectively intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, and optical coherence tomography (OCT). ), Forward vision IVUS (FL-IVUS), blood flow reserve ratio (FFR) method, and coronary blood flow reserve ratio (CFR) method.

Images