Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Status of Claims
The present Office Action is pursuant to Applicant’s communication on 11-10-2025; current application filed on 11-10-2025; this application is a 371 of PCT/US2024/028969 05-10-2024 PCT/US2024/02869 has PRO 63/501,581 05-11-2023.
Examiner’s Note
The rejections below group claims that may not be identical, but whose language and scope are so substantively similar as to lend themselves to grouping, in the interests of clarity and conciseness.
Information Disclosure Statement
The information disclosure statements (IDS) filed on 11-10-2025, have been acknowledged. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more.
Claim 1 recites:
A computing device comprising a display screen, the computing device being configured to display on the display screen a course directive graphical user interface (GUI), wherein the course directive GUI displays, for a selected patient, a limited list of patient information, the limited list of patient information obtained from one or more of an electronic medical record (EMR) database and an oncology information system (OIS), the course directive GUI further displaying a limited list of radiation therapy forms, each radiation therapy form in the limited list of radiation therapy forms being selectable to launch a display panel and enable at least the selected radiation therapy form to be seen within the display panel.
Claim 9 recites:
A method for a radiation therapy management system, comprising: displaying a course directive graphical user interface (GUI) that displays, for a selected patient, a human figure, patient information in an intake information panel, and a limited list of radiation therapy forms, wherein at least some of the patient information displayed in the course directive GUI is obtained from an electronic medical record (EMR) database and/or an oncology information system (OIS); in response to a selection of a simulation order form of the limited list of radiation therapy forms, displaying the simulation order form in a first display panel; receiving user input filling one or more fields of a plurality of fields of the simulation order form, wherein at least some of the plurality of fields of the simulation order form are auto populated with patient information from the intake information panel; displaying a multi-patient GUI that displays a workflow for each patient of a plurality of patients including the selected patient; updating a workflow progress bar for the selected patient of the multi-patient GUI upon receiving the user input filling the one or more fields of the simulation order form; in response to a selection of a plan intent form of the limited list of radiation therapy forms, displaying the plan intent form in a second display panel; and receiving user input filling one or more fields of a plurality of fields of the plan intent form, wherein at least some of the plurality of fields of the plan intent form are auto-populated with patient information from the intake information panel and/or with information from the simulation order form.
I. Independent Claims Analysis (Claims 1 & 9)
Step 1: Statutory Category Claims 1-8 are directed to a computing device, which falls within the statutory category of a "machine." Claims 9-14 are directed to a method for a radiation therapy management system, which falls within the statutory category of a "process." Thus, all claims pass Step 1
Step 2A Prong One: Judicial Exception (Abstract Idea) The claims recite an abstract idea falling under the "certain methods of organizing human activity" and "mental processes" groupings. Specifically, the claims are directed to collecting, organizing, auto-populating, and displaying patient data and radiation therapy planning information via a graphical user interface. This is essentially managing clinical workflows and organizing information, which can be performed in the human mind or with pen and paper.
Specification discloses a computing device configured to display a course directive GUI that displays patient information and radiation therapy forms. [0004]: "a computing device comprises a display screen, the computing device being configured to display on the display screen a course directive graphical user interface (GUI) for radiation therapy (RT) management, wherein the course directive GUI displays, for a selected patient, a limited list of patient information... the course directive GUI further displaying a limited list of radiation therapy forms".
Specification discloses a method for displaying a GUI, receiving user input to fill forms, and auto-populating fields. [0138]: "displaying a course directive graphical user interface (GUI) that displays, for a selected patient, a human figure, patient information in an intake information panel, and a limited list of radiation therapy forms... receiving user input filling one or more fields of a plurality of fields of the simulation order form, wherein at least some of the plurality of fields of the simulation order form are auto-populated with patient information from the intake information panel".
Step 2A Prong Two: Integration into a Practical Application The additional elements (computing device, display screen, EMR/OIS databases, auto-populating fields, displaying progress bars) do not integrate the abstract idea into a practical application. They merely use generic computer components to perform the data organization and display functions described in the abstract idea. The claims recite conventional data retrieval from medical databases and standard GUI interactions without improving the functioning of the computer itself or effecting an improvement in another technology.
Specification discloses retrieving data from siloed sources and converting it for display. [0047]: "The radiation therapy management system may be configured to retrieve the pertinent data from the different data sources (e.g., the OIS and EMR database) in one or more first formats and convert the data to the common, human-readable format."
Specification discloses that the system aggregates data to reduce manual entry. [0132]: "By establishing a system that automatically retrieves data from all EMRs and/or OIS records in real time or near real time, aggregates that information regardless of data format, and continually updates the course directive GUI and multi-patient GUI as data is received, the approach of the disclosure allows care providers to make informed decisions about radiation therapy..."
Step 2B: Significantly More The additional elements do not amount to "significantly more" than the judicial exception. Using a computing device to retrieve data from databases, auto-populate forms based on prior inputs, and display information on a screen is well-understood, routine, and conventional activity in the field of software and GUI design. The claims merely automate a manual workflow management process using generic computer hardware and standard programming techniques, which does not provide an inventive concept sufficient to overcome the abstract idea rejection.
II. Dependent Claims Analysis (Claims 2-8 & 10-14)
The dependent claims add further limitations that merely specify the type of data being organized, conventional GUI layout features, or standard data transmission steps. Under the Alice/Mayo framework, these additional elements do not integrate the abstract idea into a practical application (Step 2A Prong Two) nor do they amount to significantly more (Step 2B).
Claims 2 & 3: Specific Forms and Summaries These claims recite specific radiation therapy forms (simulation order form, plan intent form) and summaries of entered information. This merely narrows the abstract idea to a specific type of medical data organization without adding an inventive concept.
Specification discloses these forms. [0054]: "To facilitate RT planning, the GUI 300 may include a first button 306 that, when selected, launches a first display panel wherein a simulation order form is displayed... The GUI 300 may also include a second button 308 that, when selected, launches a second display panel, wherein a radiation therapy plan intent form is displayed."
Specification discloses the summary feature. [0056]: "In the second view 401, the simulation order form has been filled out by the user and a summary 402 of the simulation order is displayed in the GUI 300..."
Claims 4 & 5: Human Figure with Highlighting These claims recite displaying a human figure with highlighting based on patient information or forms. This is a conventional GUI visualization technique for presenting data and does not improve computer functionality.
Specification discloses this feature. [0055]: "The GUI 300 further includes a graphical representation of a human, referred to as a human figure 310... When the patient being treated has a cardiac device, the human figure 310 may be modified to include a graphical indication of the device positioned to correspond to where the cardiac device is located in the patient."
Specification discloses the highlighting. [0056]: "Further, highlighting 404 has been placed over the human figure 310 to indicate the region of the patient that is to be scanned during the simulation scan and treated with the radiation therapy..."
Claims 6 & 7: Multi-Patient GUI, Workflows, Progress Bars, & Image Viewer These claims recite a multi-patient workflow display, progress bars, and automatic launching of an image viewer. These are conventional project/workflow management UI elements and standard software automation for data retrieval.
Specification discloses the workflow display. [0071]: "The columns further include a plurality of workflow columns that indicate each step that is to be taken by one or more clinicians before each patient can receive a scheduled treatment."
Specification discloses the progress bar. [0074]: "Further, when two or more consecutive activities have been completed, the ovals may be joined into a progress bar that is visually indicated by color."
Specification discloses the automatic image viewer launch. [0130]: "...at least one activity of the workflow includes user selection of medical images stored in an image archive, the medical images displayed via an image viewer launched automatically in response to user input to the detail view display panel."
Claim 8: Launching GUI from Multi-Patient View This claim recites launching the course directive GUI in response to user input on the multi-patient GUI. This is a conventional UI navigation step (clicking a link/button to open another window).
Specification discloses this navigation feature. [0079]: "Additionally, a link may be provided on the multi-patient GUI 800 to launch a respective course directive GUI for each patient."
Claims 10 & 11: Sending Forms to CT System & Imaging Interface These claims recite transmitting filled forms to a CT imaging system and viewing them on an imaging interface. This is conventional data transmission between medical devices/systems using standard network protocols.
Specification discloses this transmission. [0105]: "Additionally, the simulation order form/information entered via the simulation order form may be sent to a CT scanner (e.g., the CT control console of the CT scanner)..."
Specification discloses the imaging interface viewability. [0138]: "In a second example of the method... the computed tomography imaging system displays an imaging interface and the filled simulation order form is viewable on the imaging interface."
Claim 12: Activity Detail View Panel & Automatic Image Viewer This claim recites displaying an activity detail panel with a list of medical images and automatically launching an image viewer upon user input. This is conventional data retrieval and standard GUI interaction for file selection.
Specification discloses this feature. [0138]: "...displaying, on the multi-patient GUI, an activity detail view display panel in response to user input to an activity of the selected workflow, the activity detail view display panel displaying a list of medical images obtained via the computed tomography imaging system and stored in an image archive, the medical images configured to be displayed via an image viewer launched automatically in response to user input to the activity detail view display panel."
Claim 13: Sending Plan Intent Form to Radiation Therapy Device This claim recites transmitting the filled plan intent form to a radiation therapy device. This is conventional data transmission for device control/configuration.
Specification discloses this transmission. [0108]: "Further, the plan intent form/information entered via the plan intent form may be sent to a radiation therapy device, such as a LINAC system..."
Claim 14: Human Figure Intermediate Panels & ROI Highlighting This claim recites specific GUI layout (human figure between panels) and highlighting a treatment region of interest. These are conventional UI design choices for data visualization that do not improve computer functionality or amount to significantly more.
Specification discloses the intermediate placement. [0058]: "In the third view 501, the summary 502 is displayed along with the summary 402... wherein the human figure is displayed intermediate the respective display panels."
Specification discloses the ROI highlighting. [0138]: "...further comprising highlighting a treatment region of interest on the human figure in response to identification of the treatment region of interest via the patient information in the intake information panel, the simulation order form, and/or the plan intent form."
Conclusion
Claims 1-14 are rejected under 35 U.S.C. § 101 because they are directed to the abstract idea of organizing, auto-populating, and displaying medical/radiation therapy data via a GUI. The additional elements recite generic computing devices, conventional database queries, standard UI navigation, and routine data transmission steps. These elements do not integrate the abstract idea into a practical application (Step 2A Prong Two) and do not amount to significantly more than the judicial exception itself (Step 2B), as they merely use well-understood, routine, and conventional computer functions to automate a manual clinical workflow management process.
Thus, taken alone, the additional elements do not amount to significantly more than the abstract idea identified above. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, and there is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation.
Therefore, whether taken individually or as an ordered combination, claim(s) 1-14 is/are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-14 are rejected under 35 U.S.C. § 103 as being unpatentable over Morgas (2021/0402215) in view of Smith (US 2021/0128946 A1) and further in view of Mathur (US 2021/0174941 A1).
I. REJECTION OF CLAIMS 1-5
Claim 1 - Complete Limitation Listing:
(a) A computing device comprising a display screen; (b) the computing device being configured to display on the display screen a course directive graphical user interface (GUI); (c) wherein the course directive GUI displays, for a selected patient, a limited list of patient information; (d) the limited list of patient information obtained from one or more of an electronic medical record (EMR) database and an oncology information system (OIS); (e) the course directive GUI further displaying a limited list of radiation therapy forms; (f) each radiation therapy form in the limited list of radiation therapy forms being selectable to launch a display panel and enable at least the selected radiation therapy form to be seen within the display panel.
Limitation-by-Limitation Mapping:
(a) "A computing device comprising a display screen"
Morgas discloses a computing device with a display screen used in a radiation therapy management system. [0069]: "The controller 200 can include software programs that operate to communicate with the radiation therapy device 101… The computer can also include any suitable input/output (I/O) devices 210, which can be adapted to allow communication between controller 200 and a user of the radiation therapy system 100, e.g., medical personnel. For example, the controller 200 can be provided with I/O interfaces, consoles, storage devices, memory, keyboard, mouse, monitor, printers, scanner, as well as a departmental information system (DIS) such as a communication and management interface (DICOM) for storing and transmitting medical imaging information and related data."
(b) "the computing device being configured to display on the display screen a course directive graphical user interface (GUI)"
Morgas discloses a GUI for displaying treatment plan information and patient data in a radiation therapy context. [0133]: "The scheduled plan together with the calculated scheduled dose matrix as well as the adapted plan together with the calculated adapted dose matrix are displayed for the RTT/MTA for selection, as shown in FIGS. 5 and 9. The RTT/MTA is also provided with one or more tools (hardware, software, etc.) to evaluate the scheduled plan and the adapted plan."
Morgas further discloses a GUI that presents a consolidated view of patient and treatment information. [0106]: "the RTT/MTA is presented with the session treatment image 500 containing the generated influencer structures as well as the propagated structures (i.e., the contours of the session structures overlaid on the treatment session image) alongside the reference image 400 containing the reference structures (i.e., the contours of the reference structures overlaid on the reference image) on the console display, as shown in FIG. 15B."
(c) "wherein the course directive GUI displays, for a selected patient, a limited list of patient information"
Morgas discloses displaying patient-specific information for a selected patient in a radiation therapy workflow. [0076]: "The physician also develops a set of adaptive directives which is a list of parameters/directives/information that describes the intent of the adaptive treatment, namely, the 4D description of the planned treatment for the patient. The set of adaptive directives can include information regarding the planned (reference) dose specification (i.e., Rx prescription), whether adaptive or standard IGRT therapy is to be used, the prescribed clinical goals, such as but not limited to, the target dose coverage and (OAR) risk dose limits, planned (reference) clinical goal values, the planning (reference) image, such as but not limited to a CT image, supporting images with their corresponding registration information (PET, MRI, etc.), the planned (reference) patient model (i.e., the contours of the reference structures, such as the target volumes, OARs and other structures on the reference image), the planned (reference) treatment plan (RT Plan), the planned (reference) treatment plan 3D dose (i.e., RT 3D dose), a list of the reference structures (target volumes, OARs, influencer structures, body outlines), a list of influencer structures of different treatment sites, information regarding the shapes and location of the planned (reference) structures on the planned (reference) image, as well as any information as to how the planned (reference) treatment plan was optimized."
(d) "the limited list of patient information obtained from one or more of an electronic medical record (EMR) database and an oncology information system (OIS)"
Morgas discloses obtaining patient information from a departmental information system (DIS), which functions as an OIS. [0069]: "The controller 200 can be provided with I/O interfaces, consoles, storage devices, memory, keyboard, mouse, monitor, printers, scanner, as well as a departmental information system (DIS) such as a communication and management interface (DICOM) for storing and transmitting medical imaging information and related data and enabling the integration of medical imaging devices such as scanners, servers, workstations, printers, network hardware, etc."
Morgas does not explicitly disclose as disclosed by Smith, Smith explicitly discloses an oncology information system (OIS) as a source of patient and treatment information. [0077]: "A FLASH prescription capability in a TPS and OIS (e.g., oncology information system) so that a physician can for example prescribe a certain dose rate based of a selected dose-rate definition (e.g., for example voxel-specific, contour-specific, global beam dose rate, etc.) dose rate threshold or irradiation time for a specific tissue structure."
Morgas does not explicitly disclose as disclosed by Smith, Smith disclosing the OIS as a record and verify system. [0088]: "In step 766, the final step is the OIS acts as the record and verify system during the time of delivery. Recording and verifying both dose and dose-rate delivered for each fraction of the patients treatment."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine the radiation therapy workflow GUI of Morgas with the OIS-based information retrieval of Smith, because both references are directed to radiation therapy treatment planning and management, and combining an OIS as a data source for patient information in a radiation therapy GUI would provide a more comprehensive and integrated system for managing radiation therapy workflows. See KSR Int'l Co. v. Teleflex, Inc., 550 U.S. 398 (2007).
(e) "the course directive GUI further displaying a limited list of radiation therapy forms"
Morgas discloses a GUI that displays a limited set of treatment-related forms and parameters for a selected patient. [0076]: "The set of adaptive directives can include information regarding the planned (reference) dose specification (i.e., Rx prescription), whether adaptive or standard IGRT therapy is to be used, the prescribed clinical goals… the planned (reference) treatment plan (RT Plan), the planned (reference) treatment plan 3D dose (i.e., RT 3D dose), a list of the reference structures (target volumes, OARs, influencer structures, body outlines)…"
Morgas doe not explicitly disclose as disclosed by Smith, Smith disclosing a GUI with selectable forms for radiation therapy planning. [0080]: "The method 750 begins with step 752, where the physician selects relevant parameters. The physician will have access to a drop down menu that will allow him or her to select the desired dose rate definition. Parameters include, for example, average field dose rate, local dose rate, spot dose rate, instantaneous dose rate, computed with active time or total time, or any other specific definition of biologically relevant dose rate, or time-depended flux pattern, as that information becomes available through pre-clinical research."
(f) "each radiation therapy form in the limited list of radiation therapy forms being selectable to launch a display panel and enable at least the selected radiation therapy form to be seen within the display panel"
Morgas discloses selectable forms that launch display panels for viewing and editing. [0133]: "The RTT/MTA is also provided with one or more tools (hardware, software, etc.) to evaluate the scheduled plan and the adapted plan. The tools may include tools that provide Isodose distribution of the reference plan on the reference image, Isodose distribution of the scheduled plan on the treatment session image, Isodose distribution of the adapted plan on the session treatment image, Dose Volume Histograms (DVHs) of the reference plan, the scheduled plan and the adapted plan."
Mathur discloses a GUI where selectable items launch display panels. [0116]: "System 300 demonstrates an example embodiment integrating a medical image viewer application 304 and a medical image storage system 306 that can be or correspond to a PACS, a VNA or the like. In accordance with system 300, a clinician can employ a clinician device 302 to access/execute an image viewer application 304 to view medical images stored in the medical image storage system 306."
Mathur further discloses selectable workflow items that launch detail views. [0158]: "FIGS. 10A-10B present an example workflow management UI 1001… the workflow management UI can provide a searchable and filterable list of available workflows and sub-workflows… workflows and sub-workflows can be selected from the list to view additional details about the workflow/sub-workflow, to edit the workflow, delete the workflow and/or perform other actions related to the workflow."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to integrate the OIS-based patient information retrieval of Smith and the selectable display panel architecture of Mathur into the radiation therapy workflow GUI of Morgas, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more efficient, integrated interface for radiation therapy planning and execution.
Claim 2 - Complete Limitation Listing:
(a) The computing device of claim 1; (b) wherein the limited list of radiation therapy forms includes a simulation order form and a plan intent form; (c) wherein the simulation order form includes a first plurality of fillable fields for planning a simulation scan of the selected patient; (d) and the plan intent form includes a second plurality of fillable fields for planning one or more radiation therapy sessions of the selected patient.
Limitation-by-Limitation Mapping:
(b) "the limited list of radiation therapy forms includes a simulation order form and a plan intent form"
Morgas discloses a simulation-related form (treatment session image acquisition) and a plan-related form (treatment plan generation). [0088]: "After the patient setup, the next step is to acquire, prior to the treatment, at the treatment site, one or more treatment session images (Imaging, S103) of the portion of the patient 110 that is of interest, using the radiation imaging device 101. In an exemplary embodiment, the treatment session image is a 3D or 4D CBCT scan for example obtained during a treatment session by irradiating the region of interest of the patient 110 with radiation 120."
Morgas discloses a plan intent form equivalent through the adaptive directives and plan generation. [0076]: "The physician also develops a set of adaptive directives which is a list of parameters/directives/information that describes the intent of the adaptive treatment, namely, the 4D description of the planned treatment for the patient."
Smith discloses a plan intent form equivalent through the FLASH prescription workflow. [0080]: "The method 750 begins with step 752, where the physician selects relevant parameters. The physician will have access to a drop down menu that will allow him or her to select the desired dose rate definition."
(c) "the simulation order form includes a first plurality of fillable fields for planning a simulation scan of the selected patient"
Morgas discloses fillable fields for planning a simulation/CT scan. [0088]: "the treatment session image is a 3D or 4D CBCT scan for example obtained during a treatment session by irradiating the region of interest of the patient 110 with radiation 120. This treatment session image may show boney structures of the patient but does not include any delineations of target volumes or other structures."
Morgas further discloses the planning of the scan through the adaptive directives. [0076]: "The set of adaptive directives can include information regarding… the planning (reference) image, such as but not limited to a CT image, supporting images with their corresponding registration information (PET, MRI, etc.)…"
(d) "the plan intent form includes a second plurality of fillable fields for planning one or more radiation therapy sessions of the selected patient"
Morgas discloses fillable fields for planning radiation therapy sessions. [0076]: "The set of adaptive directives can include information regarding the planned (reference) dose specification (i.e., Rx prescription), whether adaptive or standard IGRT therapy is to be used, the prescribed clinical goals, such as but not limited to, the target dose coverage and (OAR) risk dose limits, planned (reference) clinical goal values… the planned (reference) treatment plan (RT Plan), the planned (reference) treatment plan 3D dose (i.e., RT 3D dose)…"
Smith discloses fillable fields for planning radiation therapy sessions. [0081]: "In step 754, the physician selects a desired dose rate definition. Once the dose rate definition is selected, the physician can select the dose rate value (40 gy/sec to 120 gy/sec) and above."
Smith further discloses: [0083]: "In step 756, the physician selects a desired dose rate value. The physician can also select treatment modality (e.g., Bragg-Peak, Transmission, or a hybrid approach)."
Smith further discloses: [0085]: "In step 760, the physician specifies plan statistical parameters. The physician can specify plan statistical parameters such as, for example, 90% of the voxels in healthy lung shall receive dose rate of x and above and no less than 70% of dose delivered at or above 40 Gy/s."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to integrate the OIS-based patient information retrieval of Smith and the selectable display panel architecture of Mathur into the radiation therapy workflow GUI of Morgas, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more efficient, integrated interface for radiation therapy planning and execution.
Claim 3 - Complete Limitation Listing:
(a) The computing device of claim 2; (b) wherein the course directive GUI is configured to display a first summary of information entered into the simulation order form; (c) and a second summary of information entered into the plan intent form.
Limitation-by-Limitation Mapping:
(b) "the course directive GUI is configured to display a first summary of information entered into the simulation order form"
Morgas discloses displaying a summary of scan-related information. [0133]: "The scheduled plan together with the calculated scheduled dose matrix as well as the adapted plan together with the calculated adapted dose matrix are displayed for the RTT/MTA for selection, as shown in FIGS. 5 and 9."
Morgas further discloses: [0122]: "The scheduled dose matrix so generated (S304) is then sent together with the generated scheduled plan and scheduled isodose values to a display device to be displayed for the RTT/MTA in S109."
(c) "a second summary of information entered into the plan intent form"
Morgas discloses displaying a summary of plan-related information. [0130]: "The adapted dose matrix so generated S404) is then sent together with the generated adapted plan and adapted isodose values to the display device to be displayed for the RTT/MTA in S109."
Smith discloses displaying a summary of plan parameters. [0079]: "For example, a clinician can decide to prescribe FLASH therapy to a lung cancer patient and determine depending on how dose rate is defined, that they need 90% of the normal lung to be irradiated at FLASH dose rate above 40 Gy/s… They will also be able to visualize on the dose rate map if the prescription is achieved and make decisions on the course of treatment."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the radiation therapy adaptive workflow of Morgas with the OIS-based information retrieval of Smith and the multi-patient workflow management and progress tracking of Mathur, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more comprehensive, efficient, and integrated system for managing radiation therapy workflows across multiple patients with auto-populated forms and progress tracking.
Claim 4 - Complete Limitation Listing:
(a) The computing device of claim 1; (b) wherein the course directive GUI further includes a human figure; (c) wherein the human figure includes highlighting positioned based on the limited list of patient information and/or based on information obtained with the limited list of radiation therapy forms.
Limitation-by-Limitation Mapping:
(b) "the course directive GUI further includes a human figure"
Morgas discloses a GUI that displays anatomical structures of a patient, which constitutes a representation of a human figure. [0084]: "FIG. 16 shows an exemplary reference image 400 for a cervix uteri treatment. The reference image 400 includes a contour 401 delineating the primary and nodal targets as the target volume, and a set of contours 402, such as a contour 402A delineating the bladder, a contour 402B delineating the uterus, and contours 402C delineating the rectum, as the influencer structures. Reference image 400 may also include other structures of interest, such as body outlines or femoral heads, etc., as shown in FIG. 16."
Morgas further discloses: [0074]: "In a typical planning process, qualified medical personnel (physician) manually draw contours on one or more of the initial reference planning images. These contours delineate the malignant tumor that is to be irradiated, as well as one or more other structures, such as organs, tissue, etc. that are susceptible to substantial damage from radiation exposure."
(c) "the human figure includes highlighting positioned based on the limited list of patient information and/or based on information obtained with the limited list of radiation therapy forms"
Morgas discloses highlighting/contouring of target volumes and organs at risk based on patient information and treatment plan data. [0084]: "The reference image 400 includes a contour 401 delineating the primary and nodal targets as the target volume, and a set of contours 402, such as a contour 402A delineating the bladder, a contour 402B delineating the uterus, and contours 402C delineating the rectum, as the influencer structures."
Morgas further discloses: [0106]: "the RTT/MTA is presented with the session treatment image 500 containing the generated influencer structures as well as the propagated structures (i.e., the contours of the session structures overlaid on the treatment session image) alongside the reference image 400 containing the reference structures (i.e., the contours of the reference structures overlaid on the reference image) on the console display, as shown in FIG. 15B. Optionally, overlaid on the two images are body outlines, as well as a radiation dose representation (Isodose lines, color washes, etc.)."
Smith discloses highlighting of treatment regions based on patient information. [0079]: "For example, a clinician can decide to prescribe FLASH therapy to a lung cancer patient and determine depending on how dose rate is defined, that they need 90% of the normal lung to be irradiated at FLASH dose rate above 40 Gy/s. As more is learned from pre-clinical studies, perhaps it may be determined brain structures require higher dose rates in order to achieve the FLASH effect, so perhaps for a brain case, the clinician will want to prescribe that normal brain should receive a minimum dose rate of 100 Gy/s. They will also be able to visualize on the dose rate map if the prescription is achieved and make decisions on the course of treatment."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to integrate the OIS-based patient information retrieval of Smith and the selectable display panel architecture of Mathur into the radiation therapy workflow GUI of Morgas, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more efficient, integrated interface for radiation therapy planning and execution.
Claim 5 - Complete Limitation Listing:
(a) The computing device of claim 4; (b) wherein the limited list of radiation therapy forms includes a simulation order form and a plan intent form that are each displayed via a respective display panel viewable simultaneously on the course directive GUI; (c) wherein the human figure is displayed intermediate the respective display panels.
Limitation-by-Limitation Mapping:
(b) "the limited list of radiation therapy forms includes a simulation order form and a plan intent form that are each displayed via a respective display panel viewable simultaneously on the course directive GUI"
Morgas discloses displaying two plans (scheduled and adapted) simultaneously for comparison. [0133]: "The scheduled plan together with the calculated scheduled dose matrix as well as the adapted plan together with the calculated adapted dose matrix are displayed for the RTT/MTA for selection, as shown in FIGS. 5 and 9. The RTT/MTA is also provided with one or more tools (hardware, software, etc.) to evaluate the scheduled plan and the adapted plan."
Morgas further discloses: [0134]: "Equipped with these tools and choices, the RTT/MTA determines in SS00 whether the scheduled plan is the acceptable plan for the current treatment session. If the scheduled plan is acceptable, the RTT/MTA selects in S501 to deliver the scheduled plan in S502 for treatment delivery in S111. If the RTT/MTA determines in SS00 that the scheduled plan is not acceptable, the RTT/MTA selects the adapted plan in S503 for evaluation."
Mathur discloses a GUI with multiple panels viewable simultaneously. [0116]: "System 300 demonstrates an example embodiment integrating a medical image viewer application 304 and a medical image storage system 306 that can be or correspond to a PACS, a VNA or the like. In accordance with system 300, a clinician can employ a clinician device 302 to access/execute an image viewer application 304 to view medical images stored in the medical image storage system 306."
(c) "the human figure is displayed intermediate the respective display panels"
Morgas discloses a central anatomical display with surrounding plan information. [0106]: "the RTT/MTA is presented with the session treatment image 500 containing the generated influencer structures as well as the propagated structures (i.e., the contours of the session structures overlaid on the treatment session image) alongside the reference image 400 containing the reference structures (i.e., the contours of the reference structures overlaid on the reference image) on the console display, as shown in FIG. 15B. Optionally, overlaid on the two images are body outlines, as well as a radiation dose representation (Isodose lines, color washes, etc.)."
Morgas further discloses: [0084]: "FIG. 16 shows an exemplary reference image 400 for a cervix uteri treatment. The reference image 400 includes a contour 401 delineating the primary and nodal targets as the target volume, and a set of contours 402, such as a contour 402A delineating the bladder, a contour 402B delineating the uterus, and contours 402C delineating the rectum, as the influencer structures. Reference image 400 may also include other structures of interest, such as body outlines or femoral heads, etc., as shown in FIG. 16."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the radiation therapy adaptive workflow of Morgas with the OIS-based information retrieval of Smith and the multi-patient workflow management and progress tracking of Mathur, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more comprehensive, efficient, and integrated system for managing radiation therapy workflows across multiple patients with auto-populated forms and progress tracking.
II. REJECTION OF CLAIMS 6-8
Claim 6 - Complete Limitation Listing:
(a) The computing device of claim 2; (b) wherein the computing device is further configured to display on the display screen a multi-patient GUI; (c) wherein the multi-patient GUI displays, for each patient of a plurality of patients including the selected patient, a workflow visually representing a list of activities to be performed in order to delivery radiation therapy to each patient; (d) each activity of the workflow being selectable to launch an activity detail view display panel and enable the activity to be performed via the display panel; (e) and wherein at least one activity of a selected workflow includes user selection of medical images stored in an image archive; (f) the medical images displayed via an image viewer launched automatically in response to user input to the activity detail view display panel.
Limitation-by-Limitation Mapping:
(b) "the computing device is further configured to display on the display screen a multi-patient GUI"
Mathur discloses a multi-patient GUI for managing medical image processing across multiple patients. [0202]: "FIG. 16A illustrates an example activity dashboard UI 1601 that provides algorithm statistics and comparison feedback with respect to radiologist's predictions and studies in accordance with one or more examples of the disclosed subject matter. The activity dashboard UI 1601 includes an overview section 1602 that includes information regarding number and percentage of application of some of the different models provided by the system… The overview section 1602 also identifies the total number of studies received for processing (e.g., wherein each study corresponds to an image processing request), the total number of patients represented, the total number of sites from which the studies were received (e.g., imaging providers), and the total number of devices."
Mathur further discloses: [0203]: "FIG. 16B presents another example activity dashboard UI 1611 that can generated and presented via the user interface component 1510 and/or the dashboard reporting component 570. In this example, the activity dashboard UI 1611 presents graphical information 1610 regarding the number of studies received for processing per modality per a selected timeframe (e.g., the last 30 days in this example). The activity dashboard UI 6111 also includes a model summary section 1612 that includes information regarding the models run within the past 30 days."
(c) "the multi-patient GUI displays, for each patient of a plurality of patients including the selected patient, a workflow visually representing a list of activities to be performed in order to delivery radiation therapy to each patient"
Morgas discloses a workflow for radiation therapy delivery. [0089]: "As shown in FIGS. 3-4, and 14, the on-couch adaptive workflow is guided by the set of directives made available in Sl0l, so as to perform a series of automated steps by the RTT/MTA that allow for the generation of an accurate session patient model that need not be reviewed separately by a physician, and which can generate accurate treatment plans that the RTT/MTA can select from without additional physician input."
Morgas further discloses: [0087]: "In order to adapt a new treatment plan to the current anatomy, once the set of adaptive directives are made available at the treatment site, a radiation technologist (RTT/MTA) who is skilled and trained at reviewing anatomy and plan selection, and who is tasked to deliver the adaptive treatment on the patient (i.e., the user/adapter), executes the first level of treatment modification, which is setting the patient on the treatment couch and moving the patient to the imaging position (Patient Setup, S102)."
Mathur discloses workflows for multiple patients. [0094]: "In this context, a workflow refers to a set of computer executable workflow instructions that define what computer-executed processing steps to apply to the medical image (or images). A workflow consists of an orchestrated and repeatable pattern of service calls to process medical images, execute algorithms and produce outcomes to be consumed by other systems."
(d) "each activity of the workflow being selectable to launch an activity detail view display panel and enable the activity to be performed via the display panel"
Mathur discloses selectable workflow activities that launch detail views. [0158]: "FIGS. 10A-10B present an example workflow management UI 1001 in accordance with one or more embodiments of the disclosed subject matter. In various embodiments, the workflow management UI 1001 can be generated and presented in response to selection of the 'Workflows' tab from the upper toolbar. As shown in FIG. 10A, the workflow management UI can provide a searchable and filterable list of available workflows and sub-workflows (e.g., wherein sub-workflows are only run when their parent workflows are run). The list view can identify the workflow/sub-workflow by name, the time when the workflow/sub-workflow was last updated, the type (e.g., workflow or sub-workflow), the creator, and the status (e.g., activated/active or deactivated/suspended)."
Mathur further discloses: [0159]: "In various embodiments, workflows and sub-workflows can be selected from the list to view additional details about the workflow/sub-workflow, to edit the workflow, delete the workflow and/or perform other actions related to the workflow. For example, as shown in FIG. 10B, in some implementations, right clicking on a workflow or sub-workflow from the list can result in generation of a pop-up window 1002 with various actions/functions that can be selected and performed relevant to the workflow, including adding or removing tags, changing parameters, exporting the workflow or running the workflow simulator (as described below)."
(e) "at least one activity of a selected workflow includes user selection of medical images stored in an image archive"
Mathur discloses selection of medical images stored in an image archive (PACS). [0085]: "In various embodiments, the image provider systems/devices 102 can be or include one or more PACS. A PACS provides economical storage and convenient access to images from multiple modalities (source machine types). Electronic images and reports can be transmitted digitally via a PACS, which eliminates the need to manually file, retrieve, or transport film jackets, the folders used to store and protect X-ray film. The universal format for PACS image storage and transfer is DICOM."
Mathur further discloses: [0116]: "System 300 demonstrates an example embodiment integrating a medical image viewer application 304 and a medical image storage system 306 that can be or correspond to a PACS, a VNA or the like. In accordance with system 300, a clinician can employ a clinician device 302 to access/execute an image viewer application 304 to view medical images stored in the medical image storage system 306."
(f) "the medical images displayed via an image viewer launched automatically in response to user input to the activity detail view display panel"
Mathur discloses an image viewer launched in response to user input. [0117]: "In various embodiment, the image viewer application 304 can provide the image tools needed for viewing and interacting with medical image data stored at the medical image storage system 306. For example, in various embodiments, the image viewer application 304 can be or correspond to medical image view applications/programs that can be accessed using a web-based platform (e.g., a web application, a client application, or the like). The image viewer application 304 can include software and/or hardware components that facilitate viewing the medical images stored at the medical image storage system 306 and can optionally provide various interactive features for interacting with the images (e.g., changing perspectives, editing the images, applying annotations, etc.)."
Mathur further discloses: [0118]: "In accordance with system 300, the algorithm orchestration component 110 can interface with the medical image storage system 306 to receive image processing requests 106, retrieve medical image data for the requests, and provide requests results and status notifications 108. Image processing requests 106 can be initiated from the image viewer application 304 and/or the medical image storage system 306."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the radiation therapy workflow of Morgas with the multi-patient workflow management and image archive/viewer architecture of Mathur, because both references are directed to radiation therapy and medical imaging management, and combining a multi-patient workflow view with image archive access and an image viewer would provide a more comprehensive and efficient system for managing radiation therapy across multiple patients.
Claim 7 - Complete Limitation Listing:
(a) The computing device of claim 6; (b) wherein the selected workflow is for the selected patient; (c) wherein the medical images are obtained during the simulation scan for the selected patient.
Limitation-by-Limitation Mapping:
(b) "the selected workflow is for the selected patient"
Morgas discloses a workflow specific to a selected patient. [0087]: "In order to adapt a new treatment plan to the current anatomy, once the set of adaptive directives are made available at the treatment site, a radiation technologist (RTT/MTA) who is skilled and trained at reviewing anatomy and plan selection, and who is tasked to deliver the adaptive treatment on the patient (i.e., the user/adapter), executes the first level of treatment modification, which is setting the patient on the treatment couch and moving the patient to the imaging position (Patient Setup, S102)."
(c) "the medical images are obtained during the simulation scan for the selected patient"
Morgas discloses images obtained during a simulation/CT scan. [0088]: "After the patient setup, the next step is to acquire, prior to the treatment, at the treatment site, one or more treatment session images (Imaging, S103) of the portion of the patient 110 that is of interest, using the radiation imaging device 101. In an exemplary embodiment, the treatment session image is a 3D or 4D CBCT scan for example obtained during a treatment session by irradiating the region of interest of the patient 110 with radiation 120."
Morgas further discloses: [0065]: "In-treatment images can include one or more two or three-dimensional images (typically X-ray) acquired at one or more different points during treatment… a 3D IGRT could include localization of a cone-beam computed tomography (CBCT) dataset with a planning computed tomography (CT) dataset, and a 2D IGRT could include matching planar kilovoltage (kV) radiographs or megavoltage (MV) images with digital reconstructed radiographs (DRRs) obtained from the planning CT."
Claim 8 – Complete Limitation Listing:
(a) The computing device of claim 6; (b) wherein the course directive GUI is launched in response to user input to the multi-patient GUI.
Limitation-by-Limitation Mapping:
(b) "the course directive GUI is launched in response to user input to the multi-patient GUI"
Mathur discloses launching a detailed view in response to user input to a management GUI. [0159]: "In various embodiments, workflows and sub-workflows can be selected from the list to view additional details about the workflow/sub-workflow, to edit the workflow, delete the workflow and/or perform other actions related to the workflow. For example, as shown in FIG. 10B, in some implementations, right clicking on a workflow or sub-workflow from the list can result in generation of a pop-up window 1002 with various actions/functions that can be selected and performed relevant to the workflow."
Mathur further discloses: [0116]: "In accordance with system 300, a clinician can employ a clinician device 302 to access/execute an image viewer application 304 to view medical images stored in the medical image storage system 306. In this regard, the clinician device 302 can include any suitable computing device capable of accessing the viewer application 304 and viewing medical images stored in the medical image storage system 306."
Morgas discloses launching a detailed treatment view from a workflow. [0089]: "As shown in FIGS. 3-4, and 14, the on-couch adaptive workflow is guided by the set of directives made available in Sl0l, so as to perform a series of automated steps by the RTT/MTA that allow for the generation of an accurate session patient model that need not be reviewed separately by a physician, and which can generate accurate treatment plans that the RTT/MTA can select from without additional physician input."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the radiation therapy adaptive workflow of Morgas with the OIS-based information retrieval of Smith and the multi-patient workflow management and progress tracking of Mathur, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more comprehensive, efficient, and integrated system for managing radiation therapy workflows across multiple patients with auto-populated forms and progress tracking.
III. REJECTION OF CLAIMS 9–14
Claim 9 – Complete Limitation Listing:
(a) A method for a radiation therapy management system, comprising: (b) displaying a course directive graphical user interface (GUI) that displays, for a selected patient, a human figure, patient information in an intake information panel, and a limited list of radiation therapy forms; (c) wherein at least some of the patient information displayed in the course directive GUI is obtained from an electronic medical record (EMR) database and/or an oncology information system (OIS); (d) in response to a selection of a simulation order form of the limited list of radiation therapy forms, displaying the simulation order form in a first display panel; (e) receiving user input filling one or more fields of a plurality of fields of the simulation order form, wherein at least some of the plurality of fields of the simulation order form are auto-populated with patient information from the intake information panel; (f) displaying a multi-patient GUI that displays a workflow for each patient of a plurality of patients including the selected patient; (g) updating a workflow progress bar for the selected patient of the multi-patient GUI upon receiving the user input filling the one or more fields of the simulation order form; (h) in response to a selection of a plan intent form of the limited list of radiation therapy forms, displaying the plan intent form in a second display panel; and (i) receiving user input filling one or more fields of a plurality of fields of the plan intent form, wherein at least some of the plurality of fields of the plan intent form are auto-populated with patient information from the intake information panel and/or with information from the simulation order form.
Limitation-by-Limitation Mapping:
(a) "A method for a radiation therapy management system"
Morgas discloses a radiation therapy management system. [0058]: "Referring to FIG. 1, an exemplary radiation therapy system 100 is shown that can be used in adaptive radiation therapy as shown in FIG. 2. The radiation therapy system 100 can provide radiation to a patient 110 positioned on a treatment couch 112 and can allow for the implementation of various radiation dose verification protocols."
(b) "displaying a course directive graphical user interface (GUI) that displays, for a selected patient, a human figure, patient information in an intake information panel, and a limited list of radiation therapy forms"
Morgas discloses a GUI displaying patient information and treatment forms for a selected patient. [0076]: "The physician also develops a set of adaptive directives which is a list of parameters/directives/information that describes the intent of the adaptive treatment, namely, the 4D description of the planned treatment for the patient. The set of adaptive directives can include information regarding the planned (reference) dose specification (i.e., Rx prescription), whether adaptive or standard IGRT therapy is to be used, the prescribed clinical goals, such as but not limited to, the target dose coverage and (OAR) risk dose limits, planned (reference) clinical goal values, the planning (reference) image, such as but not limited to a CT image, supporting images with their corresponding registration information (PET, MRI, etc.), the planned (reference) patient model (i.e., the contours of the reference structures, such as the target volumes, OARs and other structures on the reference image), the planned (reference) treatment plan (RT Plan), the planned (reference) treatment plan 3D dose (i.e., RT 3D dose), a list of the reference structures (target volumes, OARs, influencer structures, body outlines), a list of influencer structures of different treatment sites, information regarding the shapes and location of the planned (reference) structures on the planned (reference) image, as well as any information as to how the planned (reference) treatment plan was optimized."
Morgas discloses a human figure representation through anatomical contours. [0084]: "FIG. 16 shows an exemplary reference image 400 for a cervix uteri treatment. The reference image 400 includes a contour 401 delineating the primary and nodal targets as the target volume, and a set of contours 402, such as a contour 402A delineating the bladder, a contour 402B delineating the uterus, and contours 402C delineating the rectum, as the influencer structures. Reference image 400 may also include other structures of interest, such as body outlines or femoral heads, etc., as shown in FIG. 16."
(c) "at least some of the patient information displayed in the course directive GUI is obtained from an electronic medical record (EMR) database and/or an oncology information system (OIS)"
Morgas discloses obtaining patient information from a departmental information system (DIS/OIS). [0069]: "The controller 200 can be provided with I/O interfaces, consoles, storage devices, memory, keyboard, mouse, monitor, printers, scanner, as well as a departmental information system (DIS) such as a communication and management interface (DICOM) for storing and transmitting medical imaging information and related data and enabling the integration of medical imaging devices such as scanners, servers, workstations, printers, network hardware, etc."
Morgas does not explicitly disclose as disclosed by Smith, Smith disclosing an OIS as a source of patient and treatment information. [0077]: "A FLASH prescription capability in a TPS and OIS (e.g., oncology information system) so that a physician can for example prescribe a certain dose rate based of a selected dose-rate definition (e.g., for example voxel-specific, contour-specific, global beam dose rate, etc.) dose rate threshold or irradiation time for a specific tissue structure."
Morgas does not explicitly disclose as disclosed by Smith, Smith further disclosing: [0088]: "In step 766, the final step is the OIS acts as the record and verify system during the time of delivery. Recording and verifying both dose and dose-rate delivered for each fraction of the patients treatment."
(d) "in response to a selection of a simulation order form of the limited list of radiation therapy forms, displaying the simulation order form in a first display panel"
Morgas discloses displaying a simulation/scan form in a display panel. [0088]: "After the patient setup, the next step is to acquire, prior to the treatment, at the treatment site, one or more treatment session images (Imaging, S103) of the portion of the patient 110 that is of interest, using the radiation imaging device 101. In an exemplary embodiment, the treatment session image is a 3D or 4D CBCT scan for example obtained during a treatment session by irradiating the region of interest of the patient 110 with radiation 120. This treatment session image may show boney structures of the patient but does not include any delineations of target volumes or other structures."
Morgas further discloses: [0094]: "As a first, optional step S200, the treatment session image obtained in step S103, which is an image that shows an anatomy of interest and may show one or more boney structures, is compared with the reference image which also includes a corresponding set of boney structures. For this, the RTT/MTA is provided on a console display with the reference image and the treatment session image as shown in FIG. 15A for comparison and analysis."
(e) "receiving user input filling one or more fields of a plurality of fields of the simulation order form, wherein at least some of the plurality of fields of the simulation order form are auto-populated with patient information from the intake information panel"
Morgas discloses auto-population of form fields from patient information. [0076]: "The set of adaptive directives can include information regarding the planned (reference) dose specification (i.e., Rx prescription), whether adaptive or standard IGRT therapy is to be used, the prescribed clinical goals, such as but not limited to, the target dose coverage and (OAR) risk dose limits, planned (reference) clinical goal values, the planning (reference) image, such as but not limited to a CT image, supporting images with their corresponding registration information (PET, MRI, etc.), the planned (reference) patient model (i.e., the contours of the reference structures, such as the target volumes, OARs and other structures on the reference image), the planned (reference) treatment plan (RT Plan)…"
Morgas further discloses: [0125]: "To generate the adapted plan, the propagated session structures together with a synthetic image of the patient (i.e., synthetic CT, for example) obtained in S103' are used as inputs to an automated plan generation algorithm in S400. The plan generation algorithm combines several components from existing components (Photon Optimization algorithm (PO-GPU) for VMAT and IMRT, SmartLMC algorithm for leaf sequencing, RapidPlan for DVB-estimation, FTDC-GPU for optimization dose calculation, AcurosXP-GPU for final dose calculation), and additionally, to support the automated adaptive workflow, further includes an additional component that allows for the automatic generation, automatic selection, and automatic continuous modification of optimization parameters by which the algorithm S401 and ultimately the generated plan S402 are optimized. This relieves the RTT/MTA from having to himself/herself provide optimization specific parameters (objectives, optimization structures, options, normal tissue handling, etc.) on a case by case basis."
(f) "displaying a multi-patient GUI that displays a workflow for each patient of a plurality of patients including the selected patient"
Morgas does not explicitly disclose as disclosed by Mathur, Mathur disclosing a multi-patient GUI with workflows. [0202]: "FIG. 16A illustrates an example activity dashboard UI 1601 that provides algorithm statistics and comparison feedback with respect to radiologist's predictions and studies in accordance with one or more examples of the disclosed subject matter. The activity dashboard UI 1601 includes an overview section 1602 that includes information regarding number and percentage of application of some of the different models provided by the system, which in this example include a CT hemorrhage model, a CTALVO model and a CT schematic stroke model. The overview section 1602 also identifies the total number of studies received for processing (e.g., wherein each study corresponds to an image processing request), the total number of patients represented, the total number of sites from which the studies were received (e.g., imaging providers), and the total number of devices."
Mathur further discloses: [0094]: "In this context, a workflow refers to a set of computer executable workflow instructions that define what computer-executed processing steps to apply to the medical image (or images). A workflow consists of an orchestrated and repeatable pattern of service calls to process medical images, execute algorithms and produce outcomes to be consumed by other systems."
(g) "updating a workflow progress bar for the selected patient of the multi-patient GUI upon receiving the user input filling the one or more fields of the simulation order form"
Morgas does not explicitly disclose as disclosed by Mathur, Mathur disclosing tracking and updating workflow progress. [0193]: "The activity logging component 564 can track and log the activity of the algorithm orchestration system (e.g., algorithm orchestration system 100, system 300 and the like). In particular, the activity logging component 564 can track activity information regarding all imaging processing requests 106 received and processed, including the system/device from which a request is received, the time/date when the request was received, the image data associated with the request (e.g., attributes of the image or images to be processed), the workflows executed, the algorithms executed (e.g., the algorithms included in the respective workflows that were successfully executed), the workflow results provided (e.g., the outputs of the one or more algorithms), and the timing of provision of the results."
Mathur further discloses: [0197]: "FIG. 15A provides an example activity log UI 1501 that can be generated in response to selection of the activity log tab from the upper toolbar. The activity log UI 1501 provides a searchable/filterable list view of activity logs for image processing requests 106 fulfilled by the algorithm orchestration component 110… The activity logs respectively identify the exaction ID for the request (e.g., the request ID), the date/time of the request was received, the modality of the imaging study (or image) processed, the accession number, the study instance uniform ID number (UID), the workflows that were executed, and the status of the request fulfilment, which can be either completed, in-progress, or failed."
Morgas discloses updating workflow status upon user input. [0089]: "As shown in FIGS. 3-4, and 14, the on-couch adaptive workflow is guided by the set of directives made available in Sl0l, so as to perform a series of automated steps by the RTT/MTA that allow for the generation of an accurate session patient model that need not be reviewed separately by a physician, and which can generate accurate treatment plans that the RTT/MTA can select from without additional physician input."
(h) "in response to a selection of a plan intent form of the limited list of radiation therapy forms, displaying the plan intent form in a second display panel"
Morgas discloses displaying a plan intent form in a display panel. [0133]: "The scheduled plan together with the calculated scheduled dose matrix as well as the adapted plan together with the calculated adapted dose matrix are displayed for the RTT/MTA for selection, as shown in FIGS. 5 and 9. The RTT/MTA is also provided with one or more tools (hardware, software, etc.) to evaluate the scheduled plan and the adapted plan."
Morgas does not explicitly disclose as disclosed by Smith, Smith disclosing a plan intent form. [0080]: "The method 750 begins with step 752, where the physician selects relevant parameters. The physician will have access to a drop down menu that will allow him or her to select the desired dose rate definition. Parameters include, for example, average field dose rate, local dose rate, spot dose rate, instantaneous dose rate, computed with active time or total time, or any other specific definition of biologically relevant dose rate, or time-depended flux pattern, as that information becomes available through pre-clinical research."
(i) "receiving user input filling one or more fields of a plurality of fields of the plan intent form, wherein at least some of the plurality of fields of the plan intent form are auto-populated with patient information from the intake information panel and/or with information from the simulation order form"
Morgas discloses auto-population of plan fields from prior patient and scan information. [0125]: "To generate the adapted plan, the propagated session structures together with a synthetic image of the patient (i.e., synthetic CT, for example) obtained in S103' are used as inputs to an automated plan generation algorithm in S400… The original treatment instruction, namely, the physician defined set of clinical goals contained in the set of adaptive directives in Sl0l, are used in S401 to automatically generate a set of optimization parameters/criteria for the adaptive plan generation."
Morgas further discloses: [0127]: "The automated plan generation algorithm of S400 takes the created synthetic CT and the propagated session structures as inputs to modify the reference plan based on the new anatomy. The original treatment instruction, namely, the physician defined set of clinical goals contained in the set of adaptive directives in Sl0l, are used in S401 to automatically generate a set of optimization parameters/criteria for the adaptive plan generation. The plan generation algorithm uses the automatically generated and selected optimization parameters to generate a plan in S402. The so generated plan in S402 is further automatically optimized using additional information, including reference plan optimization parameters, associated with the reference plan, which are included in the set of directives obtained in SlOl."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the radiation therapy adaptive workflow of Morgas with the OIS-based information retrieval of Smith and the multi-patient workflow management and progress tracking of Mathur, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more comprehensive, efficient, and integrated system for managing radiation therapy workflows across multiple patients with auto-populated forms and progress tracking.
Claim 10 – Complete Limitation Listing:
(a) The method of claim 9; (b) further comprising, upon receiving the user input filling the one or more fields of a plurality of fields of the simulation order form, sending the filled simulation order form to a computed tomography imaging system.
Limitation-by-Limitation Mapping:
(b) "upon receiving the user input filling the one or more fields of a plurality of fields of the simulation order form, sending the filled simulation order form to a computed tomography imaging system"
Morgas discloses sending scan parameters to a CT imaging system. [0088]: "After the patient setup, the next step is to acquire, prior to the treatment, at the treatment site, one or more treatment session images (Imaging, S103) of the portion of the patient 110 that is of interest, using the radiation imaging device 101. In an exemplary embodiment, the treatment session image is a 3D or 4D CBCT scan for example obtained during a treatment session by irradiating the region of interest of the patient 110 with radiation 120."
Morgas further discloses: [0065]: "In-treatment images can include one or more two or three-dimensional images (typically X-ray) acquired at one or more different points during treatment… a 3D IGRT could include localization of a cone-beam computed tomography (CBCT) dataset with a planning computed tomography (CT) dataset, and a 2D IGRT could include matching planar kilovoltage (kV) radiographs or megavoltage (MV) images with digital reconstructed radiographs (DRRs) obtained from the planning CT."
Morgas further discloses: [0067]: "Alternatively, the system 100 can include a kilovoltage or a megavoltage detector operable to receive the radiation beam 120. The radiation therapy device 101 and the detector can operate as a computed tomography (CT) system to generate CT images of the patient. The images can illustrate the patient's body tissues, organs, bone, soft tissues, blood vessels, etc."
Claim 11 – Complete Limitation Listing:
(a) The method of claim 10; (b) wherein the computed tomography imaging system displays an imaging interface and the filled simulation order form is viewable on the imaging interface.
Limitation-by-Limitation Mapping:
(b) "the computed tomography imaging system displays an imaging interface and the filled simulation order form is viewable on the imaging interface"
Morgas discloses a CT imaging system with an imaging interface. [0067]: "Alternatively, the system 100 can include a kilovoltage or a megavoltage detector operable to receive the radiation beam 120. The radiation therapy device 101 and the detector can operate as a computed tomography (CT) system to generate CT images of the patient. The images can illustrate the patient's body tissues, organs, bone, soft tissues, blood vessels, etc."
Morgas further discloses: [0064]: "For example, embodiments of the disclosed subject matter can be applied to image-guided radiation therapy (IGRT) devices, which uses cross-sectional images of a patient's internal anatomy taken during the radiation therapy treatment session (i.e., in-treatment images) to provide information about the patient's position. Frequent two or three-dimensional imaging during the radiation treatment is used to direct the therapeutic radiation utilizing the imaging coordinates of the actual radiation treatment plan. This ensures that the patient is localized in the radiation treatment system in the same position as planned, and that the patient is properly aligned during the treatment."
Morgas further discloses: [0094]: "As a first, optional step S200, the treatment session image obtained in step S103, which is an image that shows an anatomy of interest and may show one or more boney structures, is compared with the reference image which also includes a corresponding set of boney structures. For this, the RTT/MTA is provided on a console display with the reference image and the treatment session image as shown in FIG. 15A for comparison and analysis."
Claim 12 – Complete Limitation Listing:
(a) The method of claim 10; (b) wherein the workflow progress bar is displayed as part of a selected workflow for the selected patient on the multi-patient GUI; (c) and further comprising displaying, on the multi-patient GUI, an activity detail view display panel in response to user input to an activity of the selected workflow; (d) the activity detail view display panel displaying a list of medical images obtained via the computed tomography imaging system and stored in an image archive; (e) the medical images configured to be displayed via an image viewer launched automatically in response to user input to the activity detail view display panel.
Limitation-by-Limitation Mapping:
(b) "the workflow progress bar is displayed as part of a selected workflow for the selected patient on the multi-patient GUI"
Mathur discloses a workflow progress display. [0197]: "FIG. 15A provides an example activity log UI 1501 that can be generated in response to selection of the activity log tab from the upper toolbar. The activity log UI 1501 provides a searchable/filterable list view of activity logs for image processing requests 106 fulfilled by the algorithm orchestration component 110… The activity logs respectively identify the exaction ID for the request (e.g., the request ID), the date/time of the request was received, the modality of the imaging study (or image) processed, the accession number, the study instance uniform ID number (UID), the workflows that were executed, and the status of the request fulfilment, which can be either completed, in-progress, or failed."
Mathur further discloses: [0198]: "FIG. 15B provides an example workflow auditing UI 1511 that can be generated in response to selection of workflow 1506 for the first image processing request in the activity log UI 1501. The workflow auditing UI 1511 provides detailed information for the workflow, including the workflow name, the workflow type (e.g., which can be either a workflow or a sub-workflow), the workflow status, the workflow start time, the workflow duration, and the workflow version."
(c) "displaying, on the multi-patient GUI, an activity detail view display panel in response to user input to an activity of the selected workflow"
Mathur discloses displaying an activity detail view in response to user input. [0159]: "In various embodiments, workflows and sub-workflows can be selected from the list to view additional details about the workflow/sub-workflow, to edit the workflow, delete the workflow and/or perform other actions related to the workflow. For example, as shown in FIG. 10B, in some implementations, right clicking on a workflow or sub-workflow from the list can result in generation of a pop-up window 1002 with various actions/functions that can be selected and performed relevant to the workflow, including adding or removing tags, changing parameters, exporting the workflow or running the workflow simulator (as described below)."
(d) "the activity detail view display panel displaying a list of medical images obtained via the computed tomography imaging system and stored in an image archive"
Mathur discloses displaying medical images stored in an image archive (PACS). [0085]: "In various embodiments, the image provider systems/devices 102 can be or include one or more PACS. A PACS provides economical storage and convenient access to images from multiple modalities (source machine types). Electronic images and reports can be transmitted digitally via a PACS, which eliminates the need to manually file, retrieve, or transport film jackets, the folders used to store and protect X-ray film. The universal format for PACS image storage and transfer is DICOM."
Mathur further discloses: [0116]: "System 300 demonstrates an example embodiment integrating a medical image viewer application 304 and a medical image storage system 306 that can be or correspond to a PACS, a VNA or the like. In accordance with system 300, a clinician can employ a clinician device 302 to access/execute an image viewer application 304 to view medical images stored in the medical image storage system 306."
(e) "the medical images configured to be displayed via an image viewer launched automatically in response to user input to the activity detail view display panel"
Mathur discloses an image viewer launched in response to user input. [0117]: "In various embodiment, the image viewer application 304 can provide the image tools needed for viewing and interacting with medical image data stored at the medical image storage system 306. For example, in various embodiments, the image viewer application 304 can be or correspond to medical image view applications/programs that can be accessed using a web-based platform (e.g., a web application, a client application, or the like). The image viewer application 304 can include software and/or hardware components that facilitate viewing the medical images stored at the medical image storage system 306 and can optionally provide various interactive features for interacting with the images (e.g., changing perspectives, editing the images, applying annotations, etc.)."
Mathur further discloses: [0118]: "In accordance with system 300, the algorithm orchestration component 110 can interface with the medical image storage system 306 to receive image processing requests 106, retrieve medical image data for the requests, and provide requests results and status notifications 108. Image processing requests 106 can be initiated from the image viewer application 304 and/or the medical image storage system 306."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the radiation therapy adaptive workflow of Morgas with the OIS-based information retrieval of Smith and the multi-patient workflow management and progress tracking of Mathur, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more comprehensive, efficient, and integrated system for managing radiation therapy workflows across multiple patients with auto-populated forms and progress tracking.
Claim 13 – Complete Limitation Listing:
(a) The method of claim 9; (b) further comprising, upon receiving the user input filling the one or more fields of a plurality of fields of the plan intent form, sending the filled plan intent form to a radiation therapy device.
Limitation-by-Limitation Mapping:
(b) "upon receiving the user input filling the one or more fields of a plurality of fields of the plan intent form, sending the filled plan intent form to a radiation therapy device"
Morgas discloses sending a treatment plan to a radiation therapy device. [0136]: "Once the user selects a treatment plan, the radiation treatment will proceed in S111 according to the selected plan. The prescribing physician (MD) which generated the original treatment plan, the adaptive directives, and the adaptive workflow, or any other qualified physician, can review and/or monitor the treatment delivery oflline, as shown in FIG. 5."
Morgas further discloses: [0058]: "Referring to FIG. 1, an exemplary radiation therapy system 100 is shown that can be used in adaptive radiation therapy as shown in FIG. 2. The radiation therapy system 100 can provide radiation to a patient 110 positioned on a treatment couch 112 and can allow for the implementation of various radiation dose verification protocols. The radiation therapy can include photon-based radiation therapy, particle therapy, electron beam therapy, or any other type of treatment therapy."
Morgas further discloses: [0059]: "In an embodiment, the radiation therapy system 100 can include a radiation treatment device 101 such as, but not limited to, a LINAC operable to generate one or more beams of megavolt (MV) X-ray radiation for treatment. The LINAC may also be operable to generate one or more beams of kilovolt (kV) X-ray radiation, for example, for patient imaging."
Smith discloses sending a treatment plan to a radiation therapy device. [0046-0047]: "FIG. 4A is a block diagram showing selected components of a radiation therapy system 400 upon which embodiments according to the present invention can be implemented. In the example of FIG. 4A, the system 400 includes a beam system 404 and a nozzle 406. The beam system 404 generates and transports a beam 401 to the nozzle 406. The beam 401 can be a proton beam, electron beam, photon beam, ion beam, or atom nuclei beam (e.g., carbon, helium, and lithium)."
Smith further discloses: [0050]: "The control system 410 of FIG. 4A receives and implements a prescribed treatment plan. In embodiments, the control system 410 includes a computer system having a processor, memory, an input device (e.g., a keyboard), and perhaps a display in well-known fashion. The control system 410 can receive data regarding operation of the system 400. The control system 410 can control parameters of the beam system 404, nozzle 406, and patient support device 408, including parameters such as the energy, intensity, direction, size, and/or shape of the beam, according to data it receives and according to the prescribed treatment plan."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the radiation therapy adaptive workflow of Morgas with the OIS-based information retrieval of Smith and the multi-patient workflow management and progress tracking of Mathur, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more comprehensive, efficient, and integrated system for managing radiation therapy workflows across multiple patients with auto-populated forms and progress tracking.
Claim 14 – Complete Limitation Listing:
(a) The method of claim 9; (b) wherein the human figure is displayed intermediate the first display panel and the second display panel; (c) and further comprising highlighting a treatment region of interest on the human figure in response to identification of the treatment region of interest via the patient information in the intake information panel, the simulation order form, and/or the plan intent form.
Limitation-by-Limitation Mapping:
(b) "the human figure is displayed intermediate the first display panel and the second display panel"
Morgas discloses a central anatomical display with surrounding plan information panels. [0106]: "the RTT/MTA is presented with the session treatment image 500 containing the generated influencer structures as well as the propagated structures (i.e., the contours of the session structures overlaid on the treatment session image) alongside the reference image 400 containing the reference structures (i.e., the contours of the reference structures overlaid on the reference image) on the console display, as shown in FIG. 15B. Optionally, overlaid on the two images are body outlines, as well as a radiation dose representation (Isodose lines, color washes, etc.)."
Morgas further discloses: [0084]: "FIG. 16 shows an exemplary reference image 400 for a cervix uteri treatment. The reference image 400 includes a contour 401 delineating the primary and nodal targets as the target volume, and a set of contours 402, such as a contour 402A delineating the bladder, a contour 402B delineating the uterus, and contours 402C delineating the rectum, as the influencer structures. Reference image 400 may also include other structures of interest, such as body outlines or femoral heads, etc., as shown in FIG. 16."
(c) "highlighting a treatment region of interest on the human figure in response to identification of the treatment region of interest via the patient information in the intake information panel, the simulation order form, and/or the plan intent form"
Morgas discloses highlighting a treatment region of interest based on patient information and treatment plan data. [0074]: "In a typical planning process, qualified medical personnel (physician) manually draw contours on one or more of the initial reference planning images. These contours delineate the malignant tumor that is to be irradiated, as well as one or more other structures, such as organs, tissue, etc. that are susceptible to substantial damage from radiation exposure. The planning images can also be semi-automatically segmented to delineate the malignant tumor that is to be the target of the irradiation, and any surrounding critical structures (OARs) whose irradiation should be limited. Typical delineations for the malignant tumor include the gross target volume (GTV), the clinical target volume (CTV), and the planning target volume (PTV). The (GTV) determines the anatomic region which harbors the highest tumor cell density and requires the highest prescribed dose. The (GTV) is the position and extent of the gross tumor, i.e. what can be seen, palpated or imaged. The (CTV) contains the (GTV), plus a margin for sub-clinical disease spread which therefore cannot be fully imaged. The (CTV) is very important because this volume must be adequately treated to achieve cure. The (PTV) allows for uncertainties in planning or treatment delivery. It is a geometric concept designed to ensure that the radiotherapy dose is actually delivered to the CTV. The (PTV) is thus used to compensate for treatment setup uncertainties through volumetric expansion of the (CTV) margins."
Morgas further discloses: [0107]: "The RTT/MTA utilizes the presented information to verify that the created target volumes, namely, the target volumes propagated to the treatment session image 500, represent the correct anatomical regions of the patient. In other words, the RTT/MTA compares the treatment session image which now has the generated influencer structures and the propagated structures (i.e., the session structures) overlaid thereon with the reference image which has the reference structures overlaid thereon, and using information such as the shapes and positions of the reference structures on the reference image (i.e., the reference patient model) included in the set of adaptive directives, calculates the positions and shapes of the propagated target volumes on the treatment session image, and determines whether the propagated target volumes (CTV, PTV, GTV, etc.) represent the same anatomical regions of the patient as those represented by the reference structures in the reference image."
Smith discloses highlighting a treatment region based on patient information. [0079]: "For example, a clinician can decide to prescribe FLASH therapy to a lung cancer patient and determine depending on how dose rate is defined, that they need 90% of the normal lung to be irradiated at FLASH dose rate above 40 Gy/s. As more is learned from pre-clinical studies, perhaps it may be determined brain structures require higher dose rates in order to achieve the FLASH effect, so perhaps for a brain case, the clinician will want to prescribe that normal brain should receive a minimum dose rate of 100 Gy/s. They will also be able to visualize on the dose rate map if the prescription is achieved and make decisions on the course of treatment."
Smith further discloses: [0009]: "Embodiments of the present invention implement a computing system comprising a central processing unit (CPU), and memory coupled to the CPU and having stored therein instructions that, when executed by the computing system, cause the computing system to execute operations to generate a radiation treatment plan. The operations include accessing a minimum prescribed dose to be delivered into and across the target, determining a number of beams and directions of the beams, and determining a beam energy for each of the beams, wherein the number of beams, the directions of the beams, and the beam energy for each of the beams are determined such that the entire target receives the minimum prescribed dose. The operations further include prescribing a dose rate and optimizing dose rate constraints for FLASH therapy, and displaying a dose rate map of the FLASH therapy."
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine the radiation therapy adaptive workflow of Morgas with the OIS-based information retrieval of Smith and the multi-patient workflow management and progress tracking of Mathur, because all three references are directed to radiation therapy and medical imaging management, and combining these features would provide a more comprehensive, efficient, and integrated system for managing radiation therapy workflows across multiple patients with auto-populated forms and progress tracking.
Conclusion
The prior art made of record1 and NOT relied upon is considered pertinent to applicant's disclosure:
Yedwab (US 2020/0294671): In one aspect, the invention relates to method and systems for automating medical data processing and counseling. A method may include receiving a selection of a condition associated with a plurality of diagnosis possibilities for a patient. The method may further include displaying candidate treatment options based upon, at least in part, the condition associated with the plurality of diagnosis possibilities for the patient. The method may also include receiving a selection of a candidate treatment option from the candidate treatment options displayed and a regimen associated with the candidate treatment option selected. The method may additionally include determining a diagnosis for the patient based upon, at least in part, the condition associated with the plurality of diagnosis possibilities for the patient, the candidate treatment option, and the regimen. The diagnosis may be one of the plurality of diagnosis possibilities for the patient.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL EZEWOKO whose telephone number is 571 272 7850. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Fonya Long can be reached on 571 270 5096. The fax phone number for the organization where this application or proceeding is assigned is 571-273-7850.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL I EZEWOKO/Primary Examiner, Art Unit 3682
1Please see Form 892 for complete listing
Prosecution Insights