JP6692855B2 - Multi-modality medical processing system - Google Patents

Description

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

  Innovations in diagnosing and validating successful levels of treatment of diseases are shifting from external imaging processes to internal diagnostic processes. Specifically, diagnostic devices and methods provide for vaso-occlusive and other vascular occlusion by a microminiature sensor placed on the distal end of a catheter or flexible elongate member such as a guide wire used in catheterization procedures. It has been developed to diagnose structural disorders. For example, known medical sensing techniques include angiography, intravascular ultrasound (IVUS), anterior view IVUS (FL-IVUS), blood flow reserve ratio (FFR) measurement, coronary 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 chances of successful treatment, medical facilities have many of the possibilities of imaging, treating, diagnosing, and detecting modalities on hand in the catheter lab during the procedure. Traditionally, when a patient undergoes multiple procedures associated with different modalities, it may be necessary to enter identifying information about the patient for each of the different modalities. In other words, the same patient information may have to be entered multiple times. Such duplication of effort can lead to clerical errors and wasted resources. Further, patient diagnostic discrepancies may be caused by each modality maintaining an individual patient chart for the same patient.

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

  In addition, archived medical data, when used for educational and other non-diagnostic purposes, typically removes any information that may identify the patient from whom the data was obtained. Traditionally, the deletion of identifying information before archiving is done by a technician who deletes patient data from manually selected fields. As described above, the anonymized data is often an error that is likely to occur, and in many cases, not all identification information is deleted.

  Thus, while existing case management systems and methods have generally been adequate for their intended purpose, they have not been entirely 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 dataset level, and / or at the individual image level, thereby allowing physicians to archive specific data. Have a fine level of control over Further, datasets of different medical modalities may be archived at the same time, and patient cases corresponding to different patients may be archived at the same time to increase archiving efficiency.

  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 being associated with a first medical modality; and a patient from the second medical device. Receiving second medical data obtained from the second medical data is associated with a second medical modality different from the first medical modality. The method also includes displaying 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 the archive request via the 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 storing a plurality of instructions for execution by at least one computer processor. The instruction is to receive first medical data obtained from the patient from the first medical device, the first medical data being associated with the first medical modality; and the patient from the second medical device. Receiving second medical data obtained from 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 archiving location in response to receiving an archiving 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 includes retaining a first patient case corresponding to a first patient, the first patient case including multi-modality medical data obtained from the first patient; and corresponding to a second patient. Retaining a second patient case, the second patient case including multi-modality medical data obtained from the second patient. The method also includes displaying 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 the archive request via the user interface. Further, the method includes archiving multi-modality medical data within the patient case corresponding to the selected one or more selectable representations to an archiving location in response to receiving the archiving request. .

  In another context, this disclosure relates to anonymizing patient data in a multi-modality medical processing system. The methods and systems described herein automatically remove from the medical data any information that could identify the patient from whom it was obtained, in order to protect the privacy of the patient. Specifically, anonymization is done without human intervention to limit the deletion of errors and incomplete information. Further, different medical modality datasets may be anonymized simultaneously, and multiple patient cases corresponding to different patients may be anonymized simultaneously to increase efficiency.

  In one exemplary aspect, the present disclosure is directed to a method of anonymizing medical data obtained from a patient in a 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 is associated with a second medical modality different from the first medical modality; and the first and second medical data is related to the second medical modality. Adding to a patient case corresponding to the patient, the patient case including identifying information about the patient. The method further comprises displaying a selectable representation of the patient case on a user interface, receiving a user selection of the selectable representation, and an anonymization request from a user via the user interface. Including receiving. Further, this method deletes identification information from the patient case in response to receiving the anonymization request, the deletion is not affected by the user, and 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 instruction receives first medical data obtained from the patient from a first medical device, the first medical data being associated with a first medical modality; and from the 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 including identifying information about the patient; Displaying a selectable representation; and receiving a user selection of said selectable representation. Further, the instruction receives an anonymization request from a user via the user interface; and, in response to receiving the anonymization request, deleting identification information from the patient case, the deletion. Is 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 of anonymizing medical data in a multi-modality medical processing system. The method receives 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 the second patient from the second medical device, the second patient Different from the first patient; and adding second medical data to the second patient case corresponding to the second patient, the second patient case including identifying information about the second patient. Including; Including. The method also includes displaying on the user interface selectable representations of the first and second patient cases, receiving a user selection of both selectable representations, and via the user interface. Receiving an anonymization request. The method also includes, in response to receiving the anonymization request, deleting the first and second identifying information from each of the first and second patient cases, the deleting 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 methods and systems described herein present medical data in multiple different modalities on a single user interface screen so that the physician viewing the user interface can be associated with the patient without having to care about the modality. Allows management of all acquired datasets. In this way, it reduces the amount of time physicians have to spend reviewing patient medical data, leading to more efficient diagnosis and treatment. Further, multiple patient cases corresponding to different patients may be presented on a single user interface screen to simplify 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 comprises receiving first medical data obtained from a patient from a first medical device, the first medical data being associated with a first medical modality; the first medical data being a data repository. Storing therein; receiving second medical data obtained from the patient from the second medical device, the second medical data being a second medical modality different from the first medical modality. Associated; 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. Receiving; 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 storing a plurality of instructions for execution by at least one computer processor. The instructions include receiving first medical data obtained from a patient from a first medical device, the first medical data being associated with a first medical modality; 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 within the data repository. The instructions also display, on a user interface, a selectable representation of each 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 comprises retaining a first patient case corresponding to a first patient, the first patient case being associated with a first data set associated with the 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, the second patient case 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, the second user selection on the user interface. Displaying one data set;

  In another context, the present disclosure is directed to managing, 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, different diagnostic procedure are all the same. Stored in association with a unique identifier to simplify patient case review and retrieval. An aspect of this is that identifying patient information such as patient name and date of birth only needs to be entered into the disclosed system in a single time, which can lead to clerical error. Sex will be reduced.

  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 obtained from the patient from a first medical device, the first medical data being in a first medical modality. Associated; 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, in the multi-modality medical processing system, second medical data obtained from the patient from a second medical device, the second medical data being the first medical modality. Associated with a second medical modality different from; 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 storing 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 instruction also receives first medical data obtained from the patient from a first medical device communicatively coupled to the multi-modality medical processing system, the first medical data being a first medical data. Associated with a medical modality; and storing the first medical data in the data repository, the first medical data being associated with the unique identifier in the data repository. Further, the instructions receive second medical data obtained from the patient from a second medical device communicatively coupled to the multi-modality medical processing system, the second medical data being 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, the second medical data being at the data repository at the unique identifier. Associated with;

  In yet another exemplary aspect, the present disclosure is directed to a multi-modality medical processing system. The system includes a computing system communicatively coupled to a first medical device and a second medical device. A computing system is a user interface component configured to receive identifying information about a patient; a first configured to receive first medical data obtained from the patient from the first medical device. A modality workflow component, the first medical data being in a first medical modality; and a second medical data configured to receive second medical data obtained from the patient from the second medical device. A modality workflow component, the second medical data being 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 medical data. 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 including 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, said portion being 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 layer. FIG. 4 is a simplified flow diagram of patient case management within the multi-modality processing system of FIG. 1 according to aspects of the disclosure. 5 is a specific example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. 6 is a specific example of various screens of a case management user interface rendered by the multi-modality processing system of FIG. FIG. 7 is a specific example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 8 is a specific example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. FIG. 9 is a specific example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. 10 is a specific example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. 11 is a specific example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. 12 is a specific example of various screens of the case management user interface rendered by the multi-modality processing system of FIG. 13 is a specific 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 will be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. Nevertheless, it should be understood that it is not intended to limit the scope of the present disclosure. Any changes or further modifications to the described devices, systems and methods, and further applications of the principles of this disclosure are fully within the scope of this disclosure as would occur to one of ordinary skill in the art to which this disclosure pertains. Intended and encompassed by.
In particular, it is fully contemplated that features, components and / or steps described with respect to one embodiment may be combined with features, components and / or steps described with respect to other embodiments of the present disclosure. .. However, for the sake of brevity, many iterations 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, medical system 100 may be sensitive to various methods used to obtain and interpret human biological and physiological and morphological information, and coordinate treatment of various conditions. Provides consistent integration and enhancement of multiple forms of acquisition and processing elements designed into. More specifically, in system 100, multi-modality processing system 101 is an integrated device for acquiring, managing, interpreting, and displaying multi-modality medical detection data. In one embodiment, the processing system 101 is a computer system having hardware and software for acquiring, processing, and displaying multi-modality medical data, whereas in other embodiments, the process processing system 101 is: It may be any other type of computing system operable to process medical data. In the embodiment where the processing system 101 is a computer workstation, the system comprises a microcontroller or a 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 disc read only memory (CD-ROM), and a video controller such as a graphics processing unit (GPU), and at least a processor such as a network communication device such as an Ethernet controller or a wireless communication controller. In that regard, in some particular examples, processing system 101 is programmed to perform the procedures associated with data acquisition and analysis described in this disclosure. Accordingly, procedures associated with data acquisition, data processing, equipment control, and / or other processing or management aspects of the present disclosure may be carried on or within 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 the corresponding instructions stored in. In some examples, the processing system 101 is portable (eg, handheld, on a haul cart, etc.). Moreover, it will be appreciated that in some examples the processing system 101 comprises a plurality of computing devices. In that regard, it is specifically appreciated that different processing and / or management aspects of the present disclosure may be implemented using multiple computing devices, separately or in predefined groups. Any division and / or combination of the processing and / or management aspects described below across multiple computing devices is within the scope of the disclosure.

  In the illustrated embodiment, the medical system 100 is installed in a catheter lab 102 having a control room 104 with a processing system 101 located in the control room. In other embodiments, the processing system 101 may be located at another location, such as a catheter lab 102, a centralized area within a healthcare facility, or an off-site location (ie, in the cloud). Catheter lab 102 typically includes a sterile area that covers a procedure area, although an associated control room 104 may or may not be sterile, depending on the procedure and / or medical facility requirements. Good. Catheter laboratories and control rooms provide patients with a variety of medical detection procedures, such as angiography, intravascular ultrasound (IVUS), virtual tissue structure (VH), anterior 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 flow reserve ratio (CFR) measurement, optical coherence tomography (OCT) ), Computed tomography, intracardiac ultrasonography (ICE), anterior vision ICE (FLICE), intravascular palpography, transesophageal ultrasound, or any other medical detection modality known in the art. Can be used for In addition, the catheter lab and administration room perform one or more procedures or treatment 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, at the catheter lab 102, a 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 multiple medical devices including medical sensing devices capable of collecting medical detection data from a patient 106 at a variety of different medical sensing modalities.

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

  In the embodiment shown in FIG. 1, the instrument 108 is one or more sensors, such as an IVUS catheter 108 such as including a phased array transducer for collecting IVUS detection data. In some embodiments, the IVUS catheter 108 may have multi-modality detection potential such as IVUS and IVPA detection. Further, in the illustrated embodiment, the instrument 110 is an OCT catheter 110 such as includes one or more photosensors 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 manage and manage medical detection data collected from patient 106 by IVUS catheter 108 and OCT catheter 110, respectively. It is operable to transmit to the processing system 101 in the room 104. In one embodiment, PIMs 112 and 114 include analog-to-digital (A / D) converters and send digital data to processing system 101, while in other embodiments, these PIMs convert analog data. Send to the processing system. In one embodiment, IVUS-PIM 112 and OCT-PIM 114 send medical detection data via a peripheral component interconnect high speed (PCIe) data bus connection, while in other embodiments they are USB connection, Thunderbolt. Data may be sent via a (Thunderbolt) connection, a FireWire connection, or some other high speed data bus connection. In another example, the PIM is over a wireless connection using the IEEE 802.11 Wi-Fi standard, the Ultra Wide Band (UWB) standard, the Wireless FireWire (FireWire), the Wireless USB, or another high speed wireless network standard. It may be connected to the processing system 101.

  Further, in the medical system 100, an electrocardiogram (ECG) device 116 is operable to send an electrocardiographic signal or other hemodynamic data from the patient 106 to the processing system 101. In some embodiments, the processing system 101 is operable to use ECG signals from the ECG 116 to synchronize the data collected on the catheters 108 and 110. Further, the angiography system 117 is operable to collect and transmit X-ray, computed tomography (CT), or magnetic resonance imaging (MRI) of the patient 106 to the processing system 101. In certain embodiments, angiography system 117 may be communicatively coupled to processing system 101 via an adapter device. Such adapter devices are capable of converting data from proprietary third party formats to a format usable by processing system 101. In some embodiments, the processing system 101 combines the image data (eg, X-ray data, MRI data, CT data, etc.) from the angiography system 117 with the detection data from the IVUS and OCT catheters 108 and 110. Alternatively, it may be operable so as to register at the same time. In one aspect, simultaneous registration may be performed to generate a three-dimensional image using the detection data.

  The bedside controller 118 is communicatively coupled to the processing system 101 and provides user management rights for a particular medical modality (or modality) used to diagnose the 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 physical buttons and / or joysticks. In the integrated medical system 100, the bedside controller 118 is operable to present workflow management options and patient image data in a graphical user interface (GUI). As described in more detail in connection with FIG. 2, the bedside controller 118 includes a user interface (UI) framework service through which workflows associated with multiple modalities may be executed. In this way, the bedside controller 118 provides workflow and diagnostic images for multiple modalities to allow the clinician to manage the acquisition of multi-modality medical detection data using a single interface device. Can be displayed.

  A main controller 120 in the control room 104 is communicatively connected to the processing system 101 and 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 through a UI framework service that runs on it, a GUI-based workflow that supports different medical detection modalities. It is operable to display more. In some embodiments, the main controller 120 can be used to concurrently execute workflow of different aspects of the procedure than the bedside controller 118. In alternative embodiments, the main controller 120 may include a non-interactive display and a stand-alone operating device such as a mouse or keyboard.

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

  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 connect to various resources via the network 125. For example, the processing system 101 includes a Digital Imaging and Communications in Medicine (DICOM) system 126, an image archiving and communication system (PACS) 127, a hospital information system (HIS) 128 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. You may enable it. For example, a user of the network console 130 may have access to patient medical data, eg, diagnostic images collected by the multi-modality processing system 101, or in some embodiments, a user of the network console 130 may be performed at the catheter lab 102. One or more procedures being performed can be monitored or managed in real time. Network console 130 may be any type of computing device with a network connection, such as a PC, laptop, smartphone, tablet computer, or other such device located inside or outside of a healthcare facility.

  Furthermore, in the illustrated embodiment, the medical detection tool of the system 100 described above is shown communicatively connected to the processing system 101 via a wired connection, eg, a standard copper link, a fiber optic link, although alternatives are possible. In an embodiment, the tool connects to the processing system 101 via a wireless connection, eg, IEEE 802.11 Wi-Fi standard, Ultra Wideband (UWB) standard, Wireless Firewire (FireWire), Wireless USB, or another high speed wireless network standard. You may connect.

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

  Next, FIG. 2 shows a functional block diagram of a portion of a medical system 100 including a processing framework 200 executing on one embodiment of a multi-modality processing system 101. The process framework 200 includes various stand-alone and dependent executable components that control the operation of the processing system 101, including the acquisition, processing, and display of multi-modality medical detection data. In general, the processing framework 200 of processing system 101 is modular and extensible. That is, the framework 200 is composed of independent software and / or hardware components (or extensions), each associated with a different function and medical detection modality. This modular design allows the framework described above to accommodate additional medical detection modalities and functionality without affecting existing functionality or requiring changes to the underlying architecture. Allows for expansion. Furthermore, the internal messaging system facilitates independent data communication between modules within the framework. In an example, processing framework 200 may be implemented as computer-executable instructions stored on a fixed computer-readable storage medium within processing system 10. In another example, processing framework 200 may be a combination of hardware and software modules executing within processing system 101.

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

  As mentioned above, the framework 200 is configured such that various extensions can be added and removed without changing the system architecture. In certain embodiments, extensions that execute within framework 200 may include multiple executable components that together implement the full functionality of the extension. In such an embodiment, the extension may include an extension controller similar to system controller 202 that is operable to launch, terminate, and monitor various executable components associated with the extension. For example, at system startup, the system controller 202 may initiate the augmented controller corresponding to the medical modality, which in turn may initiate the executable components associated with the modality. In some embodiments, the enhanced controller may not be assigned until the system controller 202 associates them with a particular modality or other system task via a configuration mechanism, such as parameters obtained as a configuration file.

  The process framework 200 generally includes a workflow controller component 204 that is configured to direct the execution of executable components of the framework 202 during a multi-modality medical detection workflow. The workflow controller component 204 can govern the workflows performed 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 about the state of the started component to the event log component 206 which in turn writes the message to a log file in a standardized format. Additionally, the processing framework 200 is configured to manage limited sharing of system resources 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 processing framework 202 may contend for the same system resource, such as a graphical display on main controller 120. The resource arbiter component 208 can coordinate the sharing of limited system resources in a variety of ways, such as through a locking system, a queuing system, or a hierarchical collision management system.

  In some embodiments, system controller 202, workflow controller component 204, event log component 206, and resource arbiter component 208 may be implemented as processor executable software stored on a fixed computer-readable storage medium. In alternative embodiments, these components 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 one particular implementation of the executable components implemented in the FPGA, the system controller 202 is configured to dynamically change the programmable logic within the FPGA to implement the various functions required at that time. You may. As with this aspect, the processing system 101 may include one or more unassigned FPGAs that may be assigned by the system controller during system startup. For example, if the system controller detects an OCT-PIM and a catheter associated with it upon startup of the processing system 101, the system controller or an expansion controller associated with the function of the OCT is programmable in one of the unassigned FPGAs. The logic can be transformed dynamically, which allows it to include functionality for receiving and / or processing OCT medical data.

  To facilitate intersystem communication between different hardware and software components in multi-modality processing system 101, processing framework 200 further includes message delivery component 210. In one embodiment, the message delivery component 210 is configured to receive a message from a component within 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 the active participant in delivering the message). In such an embodiment, the metadata of the message may be generated by the sending component, which may include destination information, payload data (eg, modality type, patient data, etc.), priority information, timing information, or Includes other such information. In another embodiment, the message delivery component 210 receives a message from a component within the framework 202, temporarily stores the message, and utilizes the message for retrieval by other components within the framework. May be configured (ie, the message delivery component is a passive queue). In any case, message delivery component 210 facilitates communication between components executable by framework 200. For example, the system controller 202 may utilize the message delivery component 210 to investigate the state of a component that is activated during the system startup sequence, and, regarding this reception status information, the message delivery component may be used to determine the state information. To the event log component 206, which allows it to write to the 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, components of the framework 200 may packetize medical detection data coming into the message, and other components, such as images. The message can be sent to a queue of a message delivery component that can be retrieved by the data processing component. Further, in some embodiments, the message delivery component 210 receives in a first-in first-out (FIFO) manner, with the first message arriving at the queue first deleting the first queue. It is operable to make the message available. In an alternative embodiment, the message delivery component 210 may compose a message that can be used in different ways, for example, with the priority value stored in the message header. In one embodiment, the message delivery component 210 is implemented in random access memory (RAM) in the processing system 101, while in other embodiments it is non-volatile RAM (NVRAM), secondary storage (eg, magnetic). Hard drive, flash memory, etc.) or network-based storage. Further, in some embodiments, the messages stored in message delivery component 210 may be accessed by software and hardware modules in processing system 101 using direct memory access (DMA).

  The process framework 202 also includes many additional system components that provide core system functionality, including security components 212, multi-modality case management (MMCM) components 214, and database management components 216. .. In one particular embodiment, security component 212 is configured to provide various security services to the overall processing framework as well as to individual components. For example, a component that implements the IVUS data acquisition workflow utilizes the cryptographic application programming interface (API) exposed by the security component 212 to retrieve the IVUS data before it is sent over the 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 limit access to the processing framework to qualified users, and is extensible. You can prevent the execution of untrusted components in the framework. The multi-modality case management (MMCM) component 214 is configured to aggregate 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 in the database more efficiently and is better suited for data archiving and retrieval. In that regard, the database management component 216 is configured to provide transparent database services to other components of the framework 200, and database connection and management details are hidden from the other components. For example, in certain embodiments, database management component 216 may expose APIs that include database storage and search functionality to components of framework 200. In other words, the medical detection workflow component may be able to send diagnostic data through the database component to local and / or remote databases, such as DICOM or PACS servers, without being aware of database connection details. .. In other embodiments, the database management component 216 may be operable to perform additional and / or other database services, such as a data format service that prepares diagnostic data for archiving the database.

  As mentioned 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, 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 the IVUS acquisition component 220. And an IVUS workflow component 222. According to the modules and extensibility of processing framework 200, any number of additional acquisition and workflow components may acquire and process data from modality “N” PIM 228, modality “N” acquisition component 224 and modality. It may be independently added to the framework, as indicated by the "N" workflow component 226. For example, in certain embodiments, processing system 101 may be communicatively coupled to OCT-PIM 114, ECG system 116, blood flow reserve (FFR) -PIM, FLIVUS-PIM, and ICE-PIM. . In other embodiments, additional and / or different medical detection, treatment, or diagnostic devices may be connected to 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 may include 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. , ICE-PIM may include an ICE acquisition component for receiving ICE data, and the OCT acquisition component is operable to receive OCT data from the OCT-PIM. In this context, medical data communicated between executable components of processing framework 200 and a communicatively coupled medical device (eg, PIM, catheter, etc.) includes 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 coupled to the processing system 101, eg, radiofrequency 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, modality “N” acquisition component 224 and modality “N” workflow component 226 were positioned on the treatment device, eg, via control signal relay, via power level relay, via device feedback. Upon receipt of the data collected by the sensor, it can be configured to communicate and manage the treatment device.

  In one embodiment, once the acquisition components 220 and 224 receive data from the connected medical detection devices, the components packetize the data into messages to facilitate communication between the systems. Specifically, the component may be operable to create multiple messages from an input digital data stream, each message including digitized medical detection data and a portion of a header. The message header contains metadata associated with the medical detection data contained within the message. Further, in some embodiments, the acquisition components 220 and 224 may in some way prior to the digitized medical detection data being communicated to other parts of the framework 200. May be operable to operate. For example, the acquisition component compresses the detected data in order to normalize, scale or otherwise filter the data in order to make communication between systems more efficient or to assist 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 on in subsequent steps to save processing time. The acquisition components 220 and 224 may additionally perform a number of tasks related to data acquisition, such as responding to interrupts generated by the data bus (eg, PCIe, USB). Detecting whether a medical detection device is connected to the processing system 101, obtaining information about the connected medical detection device, storing sensing device specific data, and allocating resources to the database. Be done. As mentioned above, the data acquisition components are independent of each other and can be installed or removed by other components without interrupting the data acquisition. In addition, the acquisition component is independent of the underlying databus software layer (eg, through the use of APIs) and by a third party to facilitate the acquisition of data from a third party medical detection device. It may be created.

  The workflow component of the processing framework, eg, IVUS workflow component 222, receives raw medical detection and / or diagnostic data from each acquisition component via message delivery component 210. In general, the workflow component starts and stops data collection, for example at calculated times, displays acquired and processed patient data, and facilitates analysis of patient data acquired by a clinician. And so on to manage the acquisition of medical detection data. In this aspect, the workflow component is operable to convert raw medical data collected from a patient into a diagnostic image or other data format that allows a clinician to assess the condition of the patient. is there. For example, IVUS workflow component 222 may interpret IVUS data received from IVUS-PIM 112 and convert this data into a human-readable IVUS image. In some embodiments, the software stack within the framework is invoked when the 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. You may expose a set of APIs to use. After processing the retrieved 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. You may. In some embodiments, before sending such a message, the component may insert a flag in the header to indicate that the message contains the processed data. Further, in some embodiments, after processing the medical detection data, the component utilizes a database management component 216 to store the processed data in an archiving system, such as a locally attached mass storage device. Alternatively, it can be sent to the network-based PACS server 127. Due to the modular structure of process framework 200, workflow components 222 and 226 are independent of each other and can be installed or removed without interruption to other components and may be written by a third party. . Furthermore, their independence allows these components to be operable to simultaneously process signaling and imaging data from multiple medical detection devices.

The process framework 200 may further acquire and process data from any number of data collection tools 234, and the acquired data may be acquired by one of the other acquisition components within the framework. A co-registration interface component 230 and a co-registration workflow component 232 configured to co-register with the registered data. More specifically, the co-registration interface component 230 is operable to communicatively interface with any number of modalities, eg, medical data acquisition tools associated with the ECG device 116 or the angiography system 117 of FIG. You can In certain embodiments, the interface component 230 may be operable to standardize and / or transform incoming modality data such that the data may be retrieved by the processing system 101. It can be registered at the same time as the detection data of. Since the medical data is obtained by the co-registration interface component 230, the co-registration workflow component 232 can synchronize the data collection between the medical detection devices spatially or temporally, for example, and spatially. By aligning two or more acquired data sets based on temporal and temporal registration markers, and allowing co-registered diagnostic images or clinicians to assess a patient's condition It is configured to facilitate simultaneous registration of data from different modalities by producing other readable data. Further, in other embodiments, the co-registration workflow component 232 uses a previously acquired 2-D image or a 3-D model to collect catheters in 2-dimensional (2-D) or 3-dimensional (3-D) space. The data may be operable to be spatially co-registered. For example, a catheter-based detection tool may include criteria tracked to generate position data during the detection procedure, and the co-registration workflow component 232 may compare this position to previously acquired MRI data. Data can be registered. Further, the co-registration workflow component 232 can facilitate co-registration of multi-modality data acquired by a native acquisition component within the framework 200, such as the IVUS acquisition component 220 and the modality “N” acquisition component 224. .. Additionally, in some embodiments, a real-time clock may be incorporated into the co-registration workflow component 232.
US Provisional Patent Application No. 61 / 473,591, entitled "Distributed Medical Detection Systems and Methods," discloses in more detail temporal synchronization of medical detection data collection, and is disclosed in its entirety in this disclosure. Incorporated as a reference.

  As described above in connection with FIG. 1, a clinician utilizing processing system 101 can manage workflow and review diagnostic images through main controller 120 and bedside controller 118. The main controller 120 and bedside controller 118 include user interface (UI) framework services 240 and 242, respectively, that support multiple user interface (UI) extensions (or components). In general, the UI extensions supported by UI Framework Services 240 and 242 manage the acquisition workflows associated with and associated with medical detection modalities, respectively, and to display processed detection data. Is operable to render the user interface of. Similar to processing framework 200, UI frameworks 240 and 242 are extensible in that they support UI extensions that are independent of each other. That is, its modular design accommodates additional medical detection modality user interfaces without requiring the UI frameworks 240 and 242 to affect existing user interfaces or to modify the underlying UI architecture. Allows you to extend to. In the illustrated embodiment, the main controller 120 includes a system UI extension 244 that renders a user interface that includes 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 some embodiments, the components of main controller 120 can be considered part of processing framework 200. IVUS-UI extensions 246 and 248 render user interfaces for main controller 120 and bedside controller 118, respectively. For example, IVUS-UI extensions 246 and 248 may render and display touch screen buttons used to manage IVUS workflows and render IVUS diagnostic images created by IVUS workflow component 222. And can also be displayed. Similarly, the modality “N” UI extensions 250 and 252 render the 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 toolboxes and error handling resources. .. The look and feel toolbox API allows the UI extension to present a common button for different modality workflows, a parallel workflow format, and a standardized user interface with a data presentation scheme. 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, the UI extension may display a wave adjacent to the IVUS image data on the electrocardiogram (ECG), and may display the IVUS image with the borderline previously drawn on the OCT image. Further, in some embodiments, UI framework services 240 and 242 may include a multi-tasking framework for coordinating UI extensions to execute concurrently. For example, if the processing system 101 acquires 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. 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 coupled 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 connect to the processing framework 200 and a local bus connection, such as a (PCIe) data bus connection, a USB connection, a Thunderbolt connection, a FireWire connection, or some number. It may also communicate via some other high speed data bus connection. Further, in the embodiment shown in FIG. 2, the bedside controller is configured to facilitate message-based communication between UI extensions within the bedside controller 118 and components within the processing framework 200. , 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 workflows executed on the multi-modality processing system 101. For example, framework 200 includes remote access component 260 that communicatively connects network console 130 (FIG. 1) to processing framework 200. In one embodiment, the remote access component 260 is operable to export the management capabilities of the processing system 101 to the network console 130, which causes the network console to present workflow management capabilities within its user interface. be able to. In one particular embodiment, remote access component 260 receives workflow commands from network console 130 and forwards them to remote access workflow component 262. The remote access workflow component 262 can direct command sets and diagnostic data where remote users can access it via the network console 130. In addition, the legacy management component 264 and the legacy management workflow component 266 provide users of the legacy console 268 (eg, button console, mouse, keyboard, stand-alone monitor) with several levels of modality workflow management and access to data. .

  In an embodiment, additional components such as 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 of ordinary skill in the art will appreciate that the processing framework 200 of FIG. 2 is merely an exemplary embodiment, and in alternative embodiments, the framework may include different and / or additional components to provide various medical services. It will be appreciated that it is configured to perform a detection workflow. For example, the processing framework 200 may be an executable component configured to assess stenosis of human blood vessels, or an executable component configured to facilitate management of computer-assisted surgery or remotely controlled surgery. May be included.

  Next, FIG. 3A shows a functional block diagram of a portion of the processing framework 200 associated with the multi-modality case management (MMCM) workflow component 214. As mentioned above, the multi-modality case management (MMCM) component 214 is configured to aggregate and enhance patient medical data associated with multiple medical modalities into a unified patient chart that can be more easily managed. To be done. Specifically, in the illustrated embodiment, the MMCM workflow component 214 associates a unique identifier (UID) with all aspects of a patient case, which includes medical data and patient acquired from a medical device, Includes both retrieved data and metadata that describes the procedure (unretrieved data). The UID may be a number, alphanumeric key, hexadecimal value, or any other item that can be used to uniquely identify a patient. Metadata associated with a UID includes identifying information about the patient (eg, patient's name, gender, date of birth, social security number, blood type, etc.) and derived data (measurements, blood vessels, etc.) associated with the medical data obtained. Boundaries generated on the internal image), annotations about the image generated from the acquired medical data (vascular name, doctor notes, internal structure identification, etc.), and information about procedures performed on the patient (eg, , Procedure time, procedure location, doctor's name, medical equipment used, etc.). Assigning a common unique identifier to both patient metadata and retrieved data creates the strong relevance needed for efficient data retrieval and analysis (ie, measurements are single intravascular). Needs to be associated with the image; vessel name annotations need to be associated with every frame of the multi-frame image). Further, in the illustrated embodiment, the 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 undergo a number of different diagnostic procedures, which will allow a physician to more fully assess the patient's condition. In that respect, the data acquired for the patient during the IVUS procedure 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 during a single catheter lab session, and in other examples, the procedure may be performed in 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 will be assigned the same unique identifier for improved patient diagnosis and ultimately treatment.

  The MMCM workflow component 214 shown in FIG. 3A organizes a common UID assignment for all metadata and acquired data associated with a patient case. Specifically, the modality-specific workflow components, eg, IVUS workflow component 222 and modality N workflow component 226, were obtained from a patient using a medical device, eg, 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, which allows them to store and retrieve patient data from a designated storage medium. Thus, the storage of acquired data is handled in a unified manner, rather than implementing each storage modality component with its own storage mechanism, such as file management mechanism and data format mechanism. In one aspect of this, when the MMCM workflow component 214 receives a storage / retrieval request from a modality-specific component, it receives a set of metadata for a single patient along with medical data obtained from the patient across multiple different modalities. You can put them together.

The MMCM workflow component 214 includes an MMCM logic component 302 that implements the storage and retrieval functionality of the library called by the modality-specific component. In one embodiment, MMCM logic component 302 may be implemented as a hierarchical state machine, but in other embodiments it may be implemented as an executable 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 one embodiment, one patient case can be "open" at a time within the processing framework 200, and the MMCM logic component 302 ensures that all data acquired or entered by the physician is the case. Ensures that while is open it will be associated with the same study UID. During the diagnostic procedure of retrieving data from the patient, the MMCM logic component 302 assigns a current UID to the retrieved data and stores it in the data repository 304.
The data repository 304 may implement any type of logic data container, such as a database, and is stored on any type of storage medium, such as a hard drive on the 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 obtained across modalities are stored in the repository 304 associated 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 the data in repository 304 is merely one example, and that all the data associated with a patient case may be in many different ways, such as database tables, data structures, hash tables, stacks, queues, It will be appreciated that UIDs can be combined with linked lists and the like. In one example, all data associated with a medical modality is stored together in a logical data partition, but each dataset in the group of modality data is associated with the UID that corresponds to the patient case to which it belongs. 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 produced by the acquiring medical device, or it may be stored as a processed form, such as an IVUS image in a blood vessel. As mentioned above, the data associated with one UID may be collected over multiple clinical sessions or during a single session.

  Further, in some embodiments, each hierarchical level of data in the patient chart has its unique identifier, so that there is a chain of unique identifiers that links all patient data together. A specific example of a patient case with a unique identifier at each data level is shown in Figure 3B. For example, a patient case that includes all data acquired or associated with a patient can have a globally unique identifier as the 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 the catheter lab session. Each patient study may include its own unique identifier linked to a global patient case unique identifier. Furthermore, each patient study can then include one or more data sets (or series) comprised of data for a particular medical modality. For example, a patient study may include IVUS series, OCT series, and FFR series, all taken during a single catheter lab session, each series being uniquely linked to a patient study unique identifier. Has an identifier of. In addition, each dataset or series may include one or more diagnostic images, each image having a unique unique identifier linked to the dataset unique identifier. As such, 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 a patient case simplifies data management within multi-modality processing system 101. This scheme allows the entire patient case, or some of the individual data within the patient case, 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 in a single access to the repository without concern for modality. Data can be retrieved. Alternatively, the MMCM logic component 302 can retrieve a single image using a unique identifier associated with the image. Similarly, if the patient data is no longer needed, all medical data associated with the patient can be deleted at the same time using the UID associated with the patient without concern for 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 described in more detail in connection with FIGS. 14-15, the physician may choose to archive all or some of the patient cases in 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 local hard disk. It may be a drive, a DICOM server, or another networked archive repository. In an embodiment, in response to the archive request, the MMCM logic component 302 may retrieve all data associated with the patient case from the repository 304 via the corresponding UID, and then associate that data with the UID. It may be archived and sent to the data archive component 314. In such a scenario, the restoration of archived data can be accomplished with reference to the UID. Further, the data archive component 314 is configured to anonymize the data on demand before it is archived. In embodiments, all identifying information about the patient may be removed from the patient case, but the UID may remain associated with the case to facilitate efficient data management.

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

  Those skilled in the art will appreciate that aspects of the processing framework 200 associated with the MMCM workflow component 214 shown in FIG. 3A have been simplified, and additional and / or different components implemented within the framework for managing patient case data. You will recognize what you can do. For example, MMCM logic component 302 may utilize one or more database communication components to coordinate the transmission of data to and from 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 the UID corresponding to the patient case in the current open state, and the acquired diagnostic data is used in the dedicated storage container. Remember. Further, the MMCM workflow component 214 can store the patient's metadata in another MMCM storage container along with the corresponding UID.

  Next, FIG. 4 is a simplified flow diagram of patient case management within the multi-modality processing system 101. As mentioned above, the MMCM workflow component 214 enhances the management of patient data acquired and not acquired within the multi-modality processing system 101. The MMCM workflow controller 214 controls and manages both the front end user interface and the back end data storage. The front end user interface includes numerous screens to guide the practitioner efficiently through the patient case workflow. First, the identification information input screen 402 allows the doctor to first enter identification information about a new patient into the multi-modality processing system 101. A specific example of the identification information input screen 402 is shown in detail in FIG. Display screen 402 allows entry of patient metadata, including last name, middle name, first name, date of birth, gender, and UID. The UID may be entered by the physician or may be 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 need only enter the patient identification information once when the patient case is initialized without concern for modality. In this way, data entry errors are reduced and it is ensured that the patient identification information is linked to the correctly acquired diagnostic data. In an alternative embodiment, the 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, which enables the patient's metadata to be acquired.

Returning to FIG. 4, after the physician enters the patient's metadata 404 on 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 the UID entered on the screen 402, or it may be the UID generated by the 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 medical devices internal or external to 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 vessels, generated from the 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 the diagnostic procedure associated with the particular modality. The screens associated with data management rendered by the workflow component 214 of the MMCM and the screens associated with data acquisition rendered by each modality extension are seamlessly integrated into the user interface by the system UI extension 244 (FIG. 2). It Returning to FIG. 4, the medical data 410 of the patient associated with the first modality captured via the modality data acquisition screen 408 is passed to the MMCM workflow component 214 where it is associated with the UID 406 corresponding to the open patient case. Sent and then stored in the data repository 304. As such, the patient metadata 404 and the patient medical data 406 are both stored in the data repository 304 in association with the UID 406. In certain embodiments, the medical data 410 may be stored in the data repository 304 in the form it is received from the medical device, but 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 than the medical modality associated with the first data acquisition. The second data acquisition may be performed during the same catheter lab procedure as the first data acquisition, or may be performed during a post procedure. The unique identifier methodology disclosed herein ensures that the data collected during each acquisition is registered for the same patient, regardless of when the acquisition occurred. The second modality data acquisition screen 412 is presented to guide the physician through the second acquisition workflow. A specific example of the modality data acquisition screen 412 is shown in detail in FIG. An example screen 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 within the blood vessel.
Returning to FIG. 4, the medical data 414 of the patient captured in association with the second data acquisition screen 412 has the same UID 406 associated with it and the MMCM where this data is stored in the data repository 304. It is sent to the workflow component 214.

  After the diagnostic data associated with one or more modalities has been acquired from the patient, the acquired data management screen 416 allows the physician to review and manage the acquired data set. A specific example of the acquired data management screen 416 is shown in detail in FIG. Screen 416 includes a case log displaying selectable representations of all acquisition procedures performed on the patient without concern for modality. In other words, each of the datasets 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 datasets obtained from the same patient. The selectable representations displayed on screen 416 may correspond to datasets acquired over a period of hours, days, weeks, or years, or they may be separate datasets acquired within the same procedure. May be supported.

  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 the example screen 416, all datasets are associated with a unique identifier 123456, and selectable representations are organized by modality type. Further, in the illustrated embodiment, each selectable representation of the data set includes a title for the data set, and whether the data set includes any bookmarks that highlight important patient features, and whether the data set is acquired. Shows the date and time that was done. In other embodiments, additional information may be displayed in association with each selectable representation of the dataset. Additionally, in some examples, the display order of the selectable representations in the case log may change based on various characteristics of the dataset, such as acquisition time. Selecting a selectable representation on screen 416 causes the user interface to display the data and / or images contained in the selected data set, as described below. However, in some embodiments, selecting a selectable representation 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 in which the physician has selected the dataset titled "UNITLED01". Additional information about the data such as acquisition time, pullback rate and bookmarks in the dataset is displayed below the selectable representation of the dataset. 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, the buttons for deleting the dataset, loading the dataset, and displaying additional information about the dataset are selectable by the physician. In addition, in some embodiments, screen 416 allows the physician to select multiple selectable representations of the dataset for comparison purposes. Therefore, a doctor who reviews the acquired data management screen 416 can review and manage all acquired data sets associated with a patient without worrying about modality. In this way, the amount of time physicians have to spend reviewing patient medical data is reduced, leading to more efficient diagnosis and treatment.

  Next, FIG. 10 shows a number of patient acquisition data management screens 418. Data management screen 418 is similar to data management screen 416, but it is configured to display selectable representations 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), date of procedure, physician, modality / mode, whether the dataset is archived, Includes dataset size, and case type. In other embodiments, each selectable representation of a patient case may include different and / or additional information, such as the patient's date of birth, patient's gender, procedure location, etc. The display order of the patient cases listed on the data management screen 418 may be arranged according to one or more of the information categories associated with each patient case. Further, in some embodiments, as shown in FIG. 10, when a physician selects a toggle element that is associated with a selectable representation of a patient case, an individual dataset comprising the selected patient case is displayed. It All acquired datasets associated with a patient case are displayed below the selectable representation without concern for medical modalities. In one implementation of screen 418, the first patient case is selected and the dataset associated with the IVUS and FFR procedures is displayed. Additionally, a number of patient acquisition data management screens 418 are configured to allow a physician to acquire and open patient cases by selecting one or more selectable representations displayed. To be done. When a selectable representation of a patient case is selected on screen 418, the MMCM GUI component 320 uses the associated UID to query the data repository 304 to obtain the 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, eg, DVD, Blu-ray Disc, or It may be obtained from a flash-based drive. Therefore, a doctor who reviews a large number of patient acquisition data management screens 418 can easily review and manage all patient cases including all acquired data sets included in the patient case without worrying about modality. it can. In this way, the physician can effectively identify and compare relevant patient cases, thereby facilitating efficient diagnosis and treatment.

  Referring back 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. The indication of the selected medical data 420 is sent to the MMCM workflow component 214, which allows the selected medical data to be retrieved from the data repository 304. Specifically, the MMCM workflow component 214 queries the data repository 304 using at least the UID of the selected medical data. As shown in the embodiment shown in FIG. 4, when 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 that respect, FIG. 11 shows a specific example of the acquired medical data display screen 424. The example display screen 424 shows an image data set captured during the IVUS procedure. When reviewing IVUS images, the physician may take measurements and may add labels or other annotations to the IVUS images in the dataset. 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 Nos. XX / XXX, XXX (Application No. 44755.11041) entitled "Multi DATA Labeling and Indexing in Modality Imaging Systems ", US Provisional Patent Application Nos. XX / XXX, XXX (Application No. 4475.51042) Name" Measurement and Enhancement in Multi-Modality Imaging Systems ", US Provisional Patent Application No. XX / XXX, XXX (application number 44755.1043) entitled "Gesture-based interface for multi-modality imaging system" and US provisional patent application Nos. XX / XXX, XXX (application number 44755.1044) entitled "Multi-modality imaging" system Definitive measurement Navigation "is also disclosed, and all their entirety in this disclosure are incorporated by reference.

  As mentioned above, in some embodiments, the acquired data management screen 416 may allow a physician to select multiple selectable representations of a dataset for comparison purposes. In such a scenario, the MMCM workflow component 214 may 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 showing two IVUS images side by side. The two IVUS images may be from datasets acquired during two different IVUS procedures performed on the patient. Side-by-side comparison of patient images acquired at different times allows physicians to efficiently determine changes in patient symptoms over time. Additionally, FIG. 13 is another example of a medical data display screen 424 showing data associated with different modalities displayed side by side. Specifically, IVUS images acquired from a patient are shown simultaneously with FFR data collected from the same patient. The IVUS and FFR data may have been collected during the same catheter lab procedure or during different catheter lab procedures. MMCM workflow component 214 may include a synchronization component that spatially or temporally synchronizes the multi-modality data displayed on screen 424. One of ordinary skill in the art will appreciate that the screen 424 of FIG. 13 is only an example, and data of different modalities may be displayed side-by-side for comparison purposes. For example, the OCT image may be displayed adjacent to the ICE image, or in some examples, (streaming) acquisition data external to the multi-modality processing system 101, such as X-ray angiography (XA) data, may be displayed. It may be displayed adjacent to data acquired by the processing system itself, such as IVUS or OCT data.

  Returning to FIG. 4, any measurements, annotations, notes, or other data 426 created and derived during review of the acquired data via screen 424 is 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 their corresponding acquired data, facilitating efficient retrieval and subsequent review.

  Those skilled in the art will appreciate that the patient case management systems and methods described in connection with FIGS. 4-13 are merely exemplary embodiments, and additional and / or different steps may be performed in alternative embodiments. It will be appreciated that and additional and / or different screens may be rendered as part of the user interface. For example, in some embodiments, each modality workflow component, rather than the MMCM workflow component, may handle writing and retrieving data associated with that modality. In such an embodiment, the independent modality workflow component may query the MMCM workflow component for the UID corresponding to the patient case in the open state before storing the new acquired data. Further, screens 402, 408, 412, 416, and 424 are merely exemplary, and such screens may also be different and / or different 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 the medical data associated with one or more modalities has been obtained from the patient and stored in the data repository 304, the physician may archive the data on an archive storage medium, as described above in connection with FIG. 3A. Given options. Archiving the acquired medical data generally includes moving the medical data to a storage location outside the medical processing system where the medical data is acquired. In an example, the obtained 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, the retrieved medical data may be transferred to a remote data repository, eg DICOM, via a network connection.

  To facilitate archiving of multi-modality patient charts, the MMCM GUI component renders the retrieved medical data archive screen 1400. A specific example of the acquired medical data archive screen 1400 is shown in detail in FIG. This example 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 the patient's name, unique identifier (UID), procedure date, physician, modality / mode, whether the dataset has already been archived, data. Includes set size and case type. In some examples, the UID displayed in association with each patient case may be an identifier assigned by the 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 the patient's date of birth, the patient's gender, the location of the procedure, etc. The display order of the patient cases listed on the archive screen 1400 may arrange one or more of the categories of information associated with each patient case. Each representation of a patient case is selectable, for example via a check box. By operating the drop-down toggle associated with one of the patient cases, the modality data set comprising the patient case is displayed. For example, the first patient case displayed on screen 1400 includes a dataset generated during the IVUS procedure and a dataset generated during the FFR procedure. These datasets are displayed as individually selectable representations, for example by selecting the checkboxes to the left of the dataset representations. In other embodiments, different methods of selecting datasets may be implemented. In a further embodiment, not shown in the 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. You may. In such an embodiment, each image can be individually selected, for example via a checkbox.

  After the physician has reviewed the list of patient cases available for archiving on screen 1400, the physician may select one or more of the patient cases, datasets, or images for archiving. In the illustrated embodiment, the physician puts a checkmark 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 doctor (1) selectively determines which patient case or multiple patient cases to archive, and (2) selectively selects which data set or multiple data sets within a patient case to archive. And (3) selectively determining which image or images in the dataset to archive. In some examples, any permutation of patient cases, datasets, or images can also be archived together. In this way, one archiving action can simultaneously archive a plurality of patient cases corresponding to a plurality of patients. Archived patient cases may also include data sets associated with different medical modalities and may be acquired during one catheter lab procedure or acquired during different catheter lab procedures performed at different times. It may also include a multi-modality dataset.

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, the use of this UID allows an archived patient case to be updated with "new" patient data obtained after the first archive action. More specifically, after a patient case has been archived, screen 1400 shows only that in the "Archived" information column. If the new dataset was obtained in association with a previously archived patient case, screen 1400 indicates that the new dataset has not been archived. The doctor can individually select this unarchived data set and operate the archive button. In response, the archiving system (implemented by the data archiving component 314 of FIG. 3A or by the MMCM workflow component 214) finds the archived patient case and retrieves it via the associated UID. Open and insert the new dataset. In other embodiments, updating the archived patient case involves different methods, such as retrieving the archived patient case data, adding the new data set, and updating the updated patient case with a new one. It can be done, for example, by creating an archive.
Further, in another embodiment, the MMCM workflow component prohibits data from being added to previously archived cases to prevent data tampering.

  Further, in some embodiments, the archiving system of Figures 14 and 15 is configured to archive medical data to a location selected by the physician rather than a fixed location. For example, in example screen 1400, the physician selects either removable media, eg, a writable optical disc, or archive to portable flash storage, or a networked remote storage medium, eg, DICOM server. You can In alternative embodiments, additional and / or different archive locations may be selected by the physician, such as 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 into one of a plurality of different formats, as selected by a physician on the example screen 1400. In that regard, the patient medical data may simply be archived "as is" without changing the format, or the format may be changed (ie, 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 certain embodiments, the medical data may be inserted into a proprietary or industry standard archive data container. Further, the medical data archived by the illustrated archival system may be encrypted or otherwise obfuscated to prevent unauthorized access. In some embodiments, the option to encrypt and / or restrict access to archived items via a password may be presented on the archive screen 1400.

  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 remove patient identification information from medical data before it is archived. More specifically, when archiving a patient case without anonymization, all acquired modality datasets and all metadata-including patient identification information-are included in the archive container. Similarly, individual archived modality datasets and images will contain patient identification information if archived without anonymization. However, if the physician chooses to anonymize before archiving, the archiving system will automatically remove any information from the archive chart that can identify the patient from the person who obtained the data. . In the illustrated embodiment, the archive 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 within the patient case contain information that can identify the patient, and then deletes any data within the identified fields. In one embodiment, this determination is based on a configuration file that includes a predetermined set of data fields known to contain identification information. In an alternative embodiment, the archiving system uses natural language processing algorithms on a case-by-case basis to determine sensitive data fields. Further, in some embodiments, patient identification information is obfuscated rather than deleted during the anonymization procedure. In such embodiments, the obfuscated patient information can be retrieved 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-the identifying information for each different patient is deleted from the patient case, Or obfuscated.

  Thus, because the multi-modality processing system 101 automatically anonymizes the 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 identifying information is deleted, without having to worry about whether it is accessible via the user interface. .. Further, in the archiving scenario described here, 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 the embodiment where the multi-modality processing system is a portable processing system located in a catheter lab, the physician obtains medical data from the patient, anonymizes it, and archives it on a removable storage medium, eg a DVD. , Everything can be done with the processing 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 archive request is an instruction to archive the particular medical data selected 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 anonymous, the patient identification information 1406 will be deleted or obfuscated by the MMCM workflow component 214 before it is stored on the archive storage medium 316. The MMCM workflow component 214 may further modify the data to be archived, such as by compressing, encrypting, changing its format, and / or placing it in an archive data container.

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

While exemplary embodiments have been shown and described, a wide range of modifications, changes, and substitutions are intended in the foregoing disclosure, and in some examples, some features of the present disclosure may correspond. Can be adopted without the use of other features that do. Also, as mentioned 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, Internet, handheld and other portable wireless devices and networks. It is understood that such variations can be made in the foregoing without departing from the scope of this disclosure. Accordingly, the appended claims are broad and should be construed in a manner consistent with the scope of this disclosure.

Claims (12)

A multi-modality medical processing system,
A fixed computer readable storage medium storing a plurality of instructions for execution by at least one computer processor,
The order is:
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 the user via the user interface; and deleting identification information from the patient case in response to receiving the anonymization request, the deletion having an impact from the user And at least some of the identifying information is hidden from the user during this deletion,
A system characterized in that   A multi-modality medical processing system,
  A first medical device communicatively coupled to the multi-modality medical processing system, the first medical device configured to be positioned within a blood vessel of a patient, the first medical device. Is a flexible elongate member of a shape and size to be inserted into the blood vessel, and first medical data of a first modality while being placed in the blood vessel and being placed in the blood vessel. A first medical device is an intravascular catheter or guidewire, the first modality associated with intravascular medical data indicative of the blood vessel of the patient. The first medical data includes at least one of pressure data, flow rate data or temperature data, and a first medical device,
  A fixed computer readable storage medium storing a plurality of instructions for execution by at least one computer processor;
  A user interface in communication with the fixed computer readable storage medium,
  The plurality of instructions are
  Receiving the first medical data of the first modality at a first modality component of the multi-modality medical processing system;
  By receiving second medical data of a second modality different from the first modality with the second modality component of the multi-modality medical processing system obtained from the patient using the second medical device. Wherein the second medical device includes an imaging device located outside the patient's body, the second modality includes the imaging device while the imaging device is located outside the patient's body. A multi-modality management component associated with the imaging data indicative of the blood vessel obtained by the imaging device, the multi-modality management component communicating with the data repository, the first modality component and the second modality component, receiving the second medical data; ,
  Adding the first and second medical data to a patient case corresponding to the patient of the multi-modality management component and including identification information about the patient;
  Storing the patient case including the identification information in the data repository;
  The user interface is configured to receive an archive request for the patient case,
  The plurality of instructions further includes
  Anonymizing the patient case by the multi-modality management component in response to receiving the archive request via the user interface;
  Archiving the anonymized patient case to a storage location external to the multi-modality medical processing system,
  The anonymization is
  Retrieving the patient case containing the identification information from the data repository by the multi-modality management component;
  Deleting the identification information from the first medical data and the second medical data by the multi-modality management component,
  The portion of the first medical data and the second medical data that includes the identification information receives a user input to identify the portion so that deleting the identification information is not affected by the user. Automatically, and at least some of the identification information is hidden from the user during the deletion,
A system characterized by that. The multi-modality medical processing system according to claim 1 or 2 , wherein the identification information includes one or more of a patient name, a patient gender, a patient birth date, a patient blood type, and a patient social security number. System characterized by. The multi-modality medical processing system according to claim 1 or 2 ,
The patient case includes a unique identifier, and the deleting does not remove the unique identifier from the patient case. The multi-modality medical processing system according to claim 1 or 2 , 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,
A system characterized by including. 6. The multi-modality medical processing system of claim 5 , wherein the identifying comprises reading a configuration file that lists the at least one data field. The multi-modality medical processing system of claim 5 , wherein the identifying comprises parsing each data field included in the patient case to determine if it contains the identifying information. Characterized system. The multi-modality medical processing system according to claim 1 or 2 , wherein the deleting includes obfuscating the identification information in the at least one data field without deleting the identification information. And the system.   The multi-modality medical processing system of claim 1, wherein the instructions further include instructions for archiving the patient case to an archive location after the deletion. The multi-modality medical processing system of claim 9 , wherein the archive location comprises at least one of a removable storage medium and a remote network-based storage repository. The multi-modality medical processing system according to claim 1 or 2 , wherein the first and second medical modalities are intravascular ultrasound (IVUS) imaging, intravascular photoacoustic (IVPA) imaging, and optical coherence tomography, respectively. (OCT), anterior-view IVUS (FL-IVUS), blood flow reserve ratio (FFR) method, and coronary flow reserve ratio (CFR) method.   The multi-modality medical processing system of claim 2, wherein a graphical user interface component of the multi-modality medical processing system comprises the user interface,
  The graphical user interface component uses the graphical user interface component by the multi-modality management component to interface the first medical data of the first modality and the second medical data of the second modality to the user interface. Communicating with the multi-modality management component, as shown above,
  The user interface displays a selectable representation of the patient case including the first medical data and the second medical data,
  Receiving a user selection of said selectable representation,
  Receiving from a user an anonymization request associated with the anonymization function of the user interface, and
  A system configured to display the selectable representation of the patient case without the identifying information.

Images