Systems and methods for intelligent radiotherapy

Abstract

We propose a radiotherapy system and method including an interoperability engine (112), radiotherapy services, and artificial intelligence algorithms. These systems and methods aim to support the medical care of patients (24). Patients can be diagnosed by medical imaging devices and through intelligent patient reception (412, 500). The interoperability engine (112) can communicate with various data storage units, information technology systems, and applications provided in-house or by third parties. These systems and methods can then be used to provide treatment planning and administration across the care continuum.

Description

Technical Field

[0001] The subject matter disclosed in this book generally relates to systems and methods using computer technology with hardware and software for medical purposes, including oncology solutions and radiotherapy.

Background Art

[0002] Cancer and cancer treatment are important areas of the medical market. It is important to create systems and methods to improve the medical treatment of cancer patients by physicians. One area of patient support spans patient intake, diagnosis, and treatment planning for radiotherapy (RT).

[0003] The development of radiotherapy treatment plans generally uses medical imaging such as X-rays, computed tomography (CT), and magnetic resonance imaging (MRI). The development of radiotherapy treatment plans may include a number of steps, including multi-disciplinary team meetings (MDTs), diagnostic imaging, radiation oncology, patient registration, CT simulation, patient scheduling adjustment, data management and / or storage, image registration, segmentation, contour review, plan formulation, plan review and approval, plan quality check, treatment initiation, and ongoing management.

[0004] Current radiotherapy presents a series of problems, including complex medical cooperation relationships, overly manual processes, and fragmentation of technology systems. Extremely complex medical judgments, plan formulation, and treatments performed by diverse providers can complicate medical cooperation relationships. By strengthening collaboration, it is possible to enable users to jointly review materials in real time, thus reducing the complexity of medical cooperation relationships by shortening the time spent waiting for other users to finish their work. Radiotherapy may include time-consuming contouring, treatment plan formulation, and plan approval, all of which may include frequent interruptions resulting from performing the methods manually.

[0005] This paper proposes technical systems and methods for improved cross-vendor capabilities, interoperability, artificial intelligence support, and efficient data exchange. [Overview of the Initiative]

[0006] According to the embodiment, a medical system, method, and engine are provided which may include one or more processors, memory, and one or more programs, wherein one or more programs are stored in memory and configured to be executed by one or more processors, and these one or more programs include: instructions for patient registration using a user interface which additionally receive information from heterogeneous sources including at least an electronic medical record (EMR) and a picture archiving and communication system (PACS), and pre-fill each part of a patient questionnaire based on an artificial intelligence analysis of the information from these heterogeneous sources; instructions for workflow management through a medical diagnosis and treatment process based on patient registration which includes providing a user interface that displays a workflow orchestration that spans the diagnosis and treatment process; instructions for trend monitoring for each step of workflow management which may provide suggestions in the workflow based on an automated quality review related to the trend; and instructions for treatment planning based on user input in the workflow of the medical diagnosis and treatment process.

[0007] Furthermore, AI analysis of information from heterogeneous sources may include checking information based on the relevant fields of patient questionnaires to the extent possible. In addition, AI analysis of information from heterogeneous sources may include searching for relevant clinical trials and cross-referencing them with patient information to verify that the patient information conforms to the clinical trial guidelines.

[0008] These healthcare systems, methods, and engines may further include automated quality review related to trends based on healthcare industry quality standards. They may also include interoperability engines that provide operational capabilities between various software applications and data storage systems based on industry standards and application-specific programming interfaces. Treatment planning may further be provided based on predictive analysis of system data related to patient registration and workflow management, stored in a non-relevant database, and using Bayesian statistics for predictive analytics. These healthcare systems, methods, and engines may further include pattern recognition among patients based on artificial intelligence analysis of workflow management for multiple patients, and providing suggestions to the user interface on a display based on the recognized patterns.

[0009] Please understand that the above brief description is provided to introduce various concepts in a simplified form, which will be described again in the detailed description. Such description is not intended to identify the main or essential features of the claimed subject matter, and the scope of the claimed subject matter is uniquely defined by the claims that follow the detailed description. [Brief explanation of the drawing]

[0010] Many aspects, implementations, applications, and advantages of the present invention will become apparent from the consideration of the following detailed description, which is accompanied by the drawings. In the drawings, similar reference letters consistently refer to similar components.

[0011] [Figure 1] This figure shows a medical environment equipped with an intelligent radiotherapy system and method according to an embodiment. [Figure 2A] This figure shows a hardware device for a medical environment according to an embodiment. [Figure 2B] This is a block diagram of a computer-aided tomography hardware and software system according to an embodiment. [Figure 3] This is a block diagram of a radiotherapy hardware and software system according to an embodiment. [Figure 4] This is a medical process and block diagram according to an embodiment. [Figure 5] This diagram shows a tree-like process that supports medical decision-making according to the embodiment. [Figure 6] This figure shows the radiotherapy process according to an embodiment. [Figure 7] This figure shows the process of clinical trial matching according to the embodiment. [Figure 8] This figure shows the process of quality checks in a medical environment according to an embodiment. [Figure 9] This figure shows the relationship and pattern recognition process in a medical environment according to the embodiment. [Figure 10] This diagram shows the process of automatically updating medical software according to an embodiment. [Figure 11] This is a schematic block diagram of an example calculation environment according to an embodiment. [Figure 12] This is a schematic block diagram of another example calculation environment according to the embodiment. [Figure 13] This is a schematic block diagram of another example calculation environment according to the embodiment. [Figure 14] This is a schematic block diagram of another example calculation environment according to the embodiment. [Figure 15] This is a schematic block diagram of another example calculation environment according to the embodiment. [Figure 16] This is a schematic block diagram showing a suitable operating environment according to the embodiment. [Modes for carrying out the invention]

[0012] In the following detailed description, reference is made to the accompanying drawings which form a part hereof and which illustrate specific embodiments that can be carried out. These examples are described in sufficient detail to enable those skilled in the art to implement the subject matter and it is understood that other examples can be utilized and logical, mechanical, electrical, and other changes can be made without departing from the scope of the subject matter of this disclosure. Thus, the following detailed description is presented for purposes of illustration and should not be construed as limiting the scope of the subject matter described herein. Some features from different aspects of the following description may be combined to form further novel aspects of the subject matter discussed below.

[0013] When presenting elements of various embodiments of this disclosure, terms such as the singular indefinite article, definite article, "the", "said", etc. shall be taken to mean that one or more of the elements exist. Also, terms such as "comprising", "including", and "having" are to be construed as inclusive and mean that additional elements may exist in addition to the recited elements.

[0014] The systems and methods of this disclosure provide centralized management for various medical data generated by computers and further provide "on-the-spot" analysis of the data to determine whether to continue or modify a particular treatment. Additionally, a medical computing system is provided that can automatically record each step of the data analysis process during treatment.

[0015] FIG. 1 shows a medical environment with a system and method for intelligent radiotherapy according to an embodiment. FIG. 1 includes an oncology medical system 100, a medical imaging system 102, an information technology (IT) medical system 104, an oncology application 106, a radiotherapy (RT) system 108, a treatment delivery system 110, an interoperability engine 112, an RT service 114, a user interface (UI) 116, and a data flow 118.

[0016] The oncology medical system 100 supports patients in diagnosing and treating medical problems. For example, the oncology medical system 100 can be an example of a radiology department. The diagnosis of medical problems can be performed by a medical imaging system 102 such as ultrasound, PET / CT, CT, PET / MR, MR, X-ray, and other medical technologies for detecting medical problems. Medical imaging data is collected from the medical imaging system 102 and input into an existing IT system / data storage unit including the IT medical system 102. From these systems, information can be accessed by computing hardware and software such as the RT system 108 and the available oncology applications 106 to assist in decision-making, visualization of medical problems, and treatment determination, etc. Interaction (mutual action) is performed through the UI116 across the workflow, and treatment can be instructed to a treatment execution system 110 such as a radiation therapy system from the RT system 108. Then, as shown in the data flow 118, the patient can return for continuous management and further treatment.

[0017] The IT medical system 104 can include at least one of an electronic medical record (EMR), a medical image storage and transmission system (PACS), an oncology information system (OIS), a radiation information system (RIS), and a treatment planning system (TPS). Thus, the TPS application can be an oncology application as shown in FIG. 1, but can also be an existing IT system / data storage unit with the reference number 104. The IT medical system 104 can communicate with the RT system 108. The RT system 108 can include a core feature and / or service and a connector for hosting applications accessed by the system.

[0018] The RT system 108 can interact with its own (first-party) and / or third-party (third-party) oncology applications 106. These applications may be commercially available products that assist in tumor contouring, quality assurance, oncological diagnosis, and radiotherapy administration. The interoperability engine 112 connects with the available oncology applications 106 to provide interoperability between various IT systems, applications, and systems. Some oncology applications 106 may use one industry standard for communication, while others may use other methods. Through the RT system 108 to the interoperability engine 112, these can be linked with a wide range of industry technical standards and application programming interfaces. The RT system 108 can access the oncology applications 106 via wired and / or wireless connections. The applications 106 may be deep learning and / or AI applications hosted internally and / or by third parties, such as OAR contouring MR, brain tumor contouring MR, synthetic CT (MR alone), and / or case exchange and MDT.

[0019] The RT system 108 may include many hardware and software technical functions discussed throughout this document, not just those related to Figure 1. These functions can interact with, for example, the medical imaging system 102 and the treatment administration system 110 to control the scanning of these systems. Technologies related to the RT system 108 may include the interoperability engine 112, RT services 114, and UI 116. As described in this document, the operation of the RT system 108 includes managing data on patient behavior and the treatment progress of patients' radiotherapy, as well as acting as a complete workflow management and integration layer for the radiology department to which the RT system 108 is integrated. In some examples, the RT system 108 uses a web-based single-page application to provide users with access to patient information from multiple sources in a single location (e.g., diagnostic imaging system and patient questionnaires). Each task in the workflow may be managed by the RT system 108, including stopping and starting the workflow application, displaying the application's execution status, displaying the task owner assigned to the application, and task timeout reminders. For example, RT system 108 may include containerized microservices that can run on any hardware system, including data centers, common edge appliances, and cloud implementations.

[0020] Workflow task management may be event-based; when data is received by the interoperability engine 112, the interoperability engine 112 issues a notification to the user interface 116, etc., triggering a customized workflow generated by the interoperability system, which can then operate based on the received data, which may be various types of data. Thus, the activation of a workflow application is an event-based mechanism that can be triggered based on data availability and / or the receipt of user input. The RT system 108 may provide data storage management, including recording the location, status, and date of the surgery. The data stored by the RT system 108 can be used to trigger the activation of a workflow application.

[0021] Using the blocks that constitute the workflow and the information entered into the RT system 108, the system can define patient-related workflows and allow these workflows to be adjusted at any time during treatment while being under the control of version-controlled workflow definitions / templates. Workflow adjustments can enable adaptive radiotherapy that is adjusted by the user and / or the interoperability engine or associated artificial intelligence based on updated information on the patient, treatment, and / or diagnosis. As the operational (deployment) part of the workflow, the RT system 108 triggers the launch of at least one external application using DICOM (e.g., MPPS / UPS) or any other arbitrary protocol for the automated operation of the workflow (e.g., without user input). MPPS stands for Modality Performed Procedure Step. The DICOM Modality Performed Procedure Step (MPPS) closes the loop between the information system, PACS, and modality. The modality provides information about the examinations actually performed, the number of images scanned, and the status of the checks. As further described in this document, the RT system may include one or more artificial intelligence (AI) modules. These modules may be hardware, firmware, or software. AI modules may include special-purpose AI, machine learning, generative AI, large-scale language models (LLMs), neural networks, or other forms of artificial intelligence that take in data and provide relevant and useful outputs.

[0022] The interoperability engine 112 of the RT system 108 may include data models and workflow orchestration modules and can interact with existing IT systems and / or data storage units, such as OIS (Oncology Information Services), PACS (Medical Image Archive and Transmission System), and / or EMS / RIS (Emergency Medical Services, Radiology Information Services), as well as TPS (Treatment Planning System), contouring, QA (Quality Assurance), and / or administration, to exchange patient information. The interoperability engine 112 is a critical engine in the RT system 108 and provides seamless interoperability with existing IT medical systems 104 such as OIS, TPS, EMR, Radiology Information System (RIS), and PACS. The interoperability engine is built in accordance with standards such as DICOM-RT and Integrative Healthcare-Oriented Radiation Oncology (IHE-RO) and enables collaboration with internal and third-party applications and resources. The interoperability engine provides structured data flows, automated task triggering, and connectors to multi-vendor RT IT systems. The interoperability engine 112 further enables the RT system 108 to connect to third-party and in-house oncology applications 106.

[0023] The interoperability engine 112 utilizes mechanisms and standards such as DICOM ("Digital Imaging and Communications in Healthcare"), DICOM RT, HL7 (Health Level 7), and FHIR (Fast Medical Information Interoperability Resource) to support numerous data protocols such as simulation scanning, RIS / PACS, EMR (Electronic Medical Records), and OIS (Oncology Information Systems). Furthermore, it supports routing between different data sources based on a set of rules used to implement the functionality of an information exchange hub. Using these mechanisms and standards, numerous data protocols, such as any EMR and PACS system, can be connected to the interoperability engine 112 in a vendor-agnostic manner, for example, using Integrative Healthcare-Related Radiation Oncology (IHE-RO), DICOM RT second generation, and other standard data protocols. For example, a PACS can host application entity (AE) titles and port numbers, and can develop APIs (Application Programming Interfaces) to connect various PACS systems compliant with the DICOM standard. The interoperability engine 112 can connect to external systems in a standard manner using a back-end abstraction layer. The set of rules used to implement the functionality of the information exchange hub is a clinical task used to achieve routing between systems (e.g., between an interoperability system and a system hosting multiple data protocols). The interoperability engine 112 provides modular workflow tasks to create different rules based on user requirements. Information can be exchanged through DICOM, as well as other protocols such as SOAP (Simple Object Access Protocol) and / or REST (Representational State Transfer), which enable a comprehensive review of integrated data from sources such as OIS, TPS (treatment planning system), and RIS / PACS.Information can be exchanged according to standard protocols such as DICOM-MPPS, DICOM-UPS, ODBC (e.g., Open Database Connectivity for connecting to OIS), and second-generation DICOM-RT for connecting to TPS.

[0024] The Workflow Orchestration Module is designed to eliminate the burden of repetitive data searches across multiple screens, intelligently optimizing workflows. This module orchestrates easy access to all applications. The module's dynamic data aggregation does not need to be visible to the user. All clinically relevant data is automatically collected, analyzed, categorized, and displayed, replacing manual steps that could burden users with time and effort.

[0025] The services of RT System 108 may include in-house and / or third-party services, including RT Services 114 for case exchange, planning directives, tumor contouring, staffing scheduling, patient registration, organ contouring MR, and / or MR-only workflows (e.g., synthetic CT). RT System 108's Services 114 may be hosted and / or provided internally and / or by third parties. These services enable the clinical and procedural outcomes of RT System 108. These services may provide case exchange, patient registration, planning directives, staffing scheduling, contouring MR, tumor contouring, and MR-only workflows.

[0026] The patient registration module and the planning instruction module are illustrated in RT Service 114. These modules enable physicians to grasp patient information and begin the patient's treatment journey. Patient demographic information, medical history, and alerts from the oncology information system can be easily retrieved from a single screen via UI 116. The physician's intentions regarding patient treatment planning are clearly displayed for the team's reference. Planning instructions aim to describe the physician's intentions regarding the goals of patient treatment planning. Planning instructions are also called planning intentions. The patient registration module can record critical patient information and treatment plans and provide them to each patient's medical team, enabling the medical team to efficiently register and handle patients. Traditionally, patient registration and handling information was manually recorded (e.g., on paper) during MDT (Multidisciplinary Team Oncology Review) and manually entered into the Oncology Information System (OIS). Using a DICOM worklist adapter, patient demographic data and imaging scanners are enabled to retrieve details of patients scheduled for scanning from HIS / EMR / OIS systems in a radiation oncology environment. Furthermore, a patient reception module allows physicians to access patient information and initiate the patient treatment route. This module can be designed to retrieve patient demographic information, medical history, and alerts from the oncology information system.

[0027] The planning and instruction module manages the on-call schedules for clinical departments. The module's algorithms and processes help calculate on-call schedules based on staffing levels in medium to large clinical departments.

[0028] The RT service 114's personnel scheduling module can be used to manage and schedule personnel for a clinical department (radiation oncology) based on factors such as available personnel. The planning instruction module further allows radiation oncologists to digitally add detailed prescriptions for a planning team, which may include medical dosimeters and / or medical physicists. The RT system 108 can be connected to various elements of the oncology medical system 100 via one or more connectors.

[0029] The RT system 108 further includes a user interface (UI) 116 that can be a single UI across the workflow. The RT system's user interface 116 can provide a single UI across the RT medical pathway, minimizing contact with existing RT IT systems. The UI provides a workflow display that enables user configuration and operation management. The RT system 108 can receive, process, and output information such as that described herein relating to patients, workflows, and at least one resource, and can automatically guide and execute the steps of diagnosis, simulation, treatment administration, and ongoing management.

[0030] The treatment system 110 provides medical treatment to patients. Medical and healthcare decision-makers (clinicians, physicians, medical assistants, and nurses, etc.) use the RT system 108 to make decisions and assign treatment plans. Medical professionals work with the treatment hardware and software system 110 to provide specific medical treatment to each patient. In embodiments, the system may include a medical linear accelerator for extracorporeal beam radiotherapy for cancer patients. These devices can irradiate the patient's malignant tumor with high-energy X-rays or electrons. Further machines may include a combination of a CT scanner and an extracorporeal beam radiotherapy machine. Image-assisted radiotherapy also helps track cancer and preserve healthy tissue. Other forms of oncological radiotherapy include intensity-modulated radiotherapy and volume-modulated radiotherapy. These medical devices described in this document may be examples of the treatment system 110.

[0031] Data flow 118 illustrates how data can flow according to the embodiment. In some examples, the workflow from diagnosis to treatment operates as a cycle. After treatment, the results of the medical treatment can be fed back to the RT system 108, the medical imaging device 102, the medical IT system 104, and the available applications 106. Furthermore, this result data is supplied to an artificial intelligence module within the system for continuous learning.

[0032] A modular approach is employed by the RT system 108, facilitating the exchange of functional modules to support the diverse needs of the radiology department into which the system is integrated. In some cases, the RT system 108 can support the needs of larger environments, such as the hospital or other medical facility where the radiology department is located, thereby enhancing collaboration between the radiology department and other departments. When patient data becomes available to the RT system 108 (e.g., via the patient reception module), a CT / MR simulation scan can be scheduled by importing the patient's demographic information, and a simulation scan protocol can be generated by importing the scan instruction text data provided by the patient reception module. The modular workflow may further be defined based on user input.

[0033] The RT system 108 can generate version-controlled workflow definitions (e.g., templates) using a radiation oncology domain-specific language (DSL) that provides flexible workflow configuration blocks. These workflow configuration blocks may include definitions of operational logic and interoperability. For example, a diagnostic imaging scan may be performed on a patient, followed by a multidisciplinary team meeting (MDT) regarding this patient. Information from the diagnostic imaging scan and MDT, as well as the patient's demographic data and medical attention history, are transferred from the patient reception module, and this information can be used to schedule a patient scan. The transferred information may further be used to perform image contouring following a simulation scan. The contoured images are transferred to a treatment planning system that allows users to view the contoured images. The interoperability engine 112, working with the RT service 114, creates a treatment plan using the planning instructions. The treatment plan is transferred to the treatment execution system 110 after quality review and approval.

[0034] The RT System 108 further includes a workflow orchestration module that enables medical teams to direct the treatment planning workflow. This patient-centered protocol-based application manages and monitors the patient treatment process. In this way, the RT System 108 can automate workflows and minimize manual application operation, thereby increasing efficiency and enhancing safety. Further details regarding the workflow manager are described in relation to Figure 4.

[0035] As shown in Figure 1, the RT system 108 electronically exchanges medical information, including messages, documents, and clinical data, using connector technology to various components such as EMR, imaging devices, imaging and treatment planning software, scheduling and appointment management tools, and quality assurance and monitoring systems. The RT system 108 can also incorporate remote monitoring and telemedicine technologies to enable remote consultations and continuous medical care.

[0036] The RT system 108, with its API access to supported third-party applications, can prepare and configure the necessary parameters for applications before they are launched. This includes the available oncology application 106. By sending this information early, users can save time and effort by eliminating the need to manually configure applications each time they are launched. Alternatively, the RT system 108's workflow orchestration module can provide a set of default parameters that applications can automatically load and use. This helps streamline and improve the efficiency of medical workflows. Furthermore, the RT system 108 allows programmatically launching each application using its API to access its functions, enabling seamless integration with other applications in the workflow. The RT system 108 also supports the use of custom scripting to automate repetitive tasks such as file transfers or data conversions, further streamlining workflow processes.

[0037] The RT system 108 can seamlessly integrate applications into predefined and supported standard interfaces to perform at least one given task in a clinical workflow. This can also provide easy replacement of a given application with another without affecting the overall workflow. For example, a user might prefer to use the first application instead of a second application integrated into the overall workflow. The second application can be replaced with the first application within the overall workflow without disrupting the overall workflow.

[0038] Furthermore, the RT system 108 can provide the possibility of configuring trigger conditions for the orchestration of each subsequent step in each case for automation of workflow execution. The RT system 108 can provide the option for the user to insert considerations into which the user can intentionally pause workflow execution, for example, to await user interaction with the workflow. At any point during workflow execution, the RT system 108 gives the user the option to review intermediate results and initial data of the process and accept user input to continue, abort, or rewind workflow execution. The user can create flexible workflows for a given workflow step by different cases and / or vendors. For example, the user can select a desired application for a given step of the workflow from an application catalog. The RT system 108 can provide opportunities for collaboration among users (e.g., users from different teams within or outside a clinical department) by providing frameworks and interfaces for outputting configurations, orchestrations, and / or protocols for each user for storage and / or display through the interoperability engine 112. The RT system 108 can provide tools for data and execution analysis, resources for optimizing the device for the workflow, and resources for re-adapting the workflow for compatible devices (for example, when updated and / or new devices are introduced into the workflow).

[0039] Figure 2A shows a hardware device for a medical environment according to an embodiment. Figure 2B shows a block diagram of a computer-aided tomography hardware and software system according to an embodiment. Such a machine can be used as an imaging device 102.

[0040] Figures 2A and 2B show a computer-aided tomography (CT) imaging system 10 including a gantry 12. The gantry 12 has a rotating member 13. An X-ray source 14 projects a beam of X-rays 16 through a pre-patient collimator 15 toward a detector assembly 18 on the opposite side of the rotating member 13. The X-ray source 14 is also called an X-ray tube or X-ray generating component. The X-ray source 14 is one type of emission component. The rotating member 13 can be mounted to the stationary structure of the gantry 12 using a main bearing. The detector assembly 18 is formed by a plurality of detectors 20 and a data acquisition system (DAS) 22, which may include a post-patient collimator. The plurality of detectors 20 sense the X-rays that have been projected and passed through the subject 24, and the DAS 22 converts the data into digital signals for later processing. Each detector 20 generates an analog or digital electrical signal representing the intensity of the incident X-ray beam, and consequently the intensity of the beam as it passes through the subject 24. During scanning to acquire X-ray projection data, the rotating member 13 and the components mounted on the member 13 can rotate around the center of rotation.

[0041] The rotation of the rotating member 13 and the operation of the X-ray source 14 are controlled by the control mechanism 26 of the CT system 10. The control mechanism 26 may include an X-ray controller 28 and a generator 30 that provide power signals and timing signals to the X-ray source 14 and to the gantry motor controller 32 that controls the rotational speed and position of the rotating member 13. The image reconstructor 34 receives the sampled and digitized X-ray data from the DAS 22 and performs high-speed image reconstruction. The reconstructed image is output to the computer 36, which stores the image in the computer storage device 38.

[0042] The computer 36 also receives commands and scanning parameters from the operator via an operation console 40 having some form of operator interface, such as a keyboard, mouse, touch-sensing controller, voice-activated controller, or any other suitable input device. The display 42 allows the operator to observe the reconstructed image and other data from the computer 36. The commands and parameters given by the operator are used by the computer 36 to provide control signals and information to the DAS 22, the X-ray controller 28, and the gantry motor controller 32. In addition, the computer 36 operates the table motor controller 44 to control the motorized table 46, positioning the subject 24 and the gantry 12. Specifically, the table 46 moves the subject 24 through the gantry opening 48 or bore (internal hole), either entirely or partially. The coordinate system 50 defines the patient axis or Z-axis 52 as the subject 24 moves in and out of the aperture 48, the gantry circumference axis or X-axis 54 through which the detector assembly 18 passes, and the Y-axis 56 that passes along the direction from the focal spot of the X-ray tube 14 to the detector assembly 18.

[0043] Figure 3 shows a block diagram of a radiotherapy hardware and software system according to an embodiment. Figure 3 includes a medical environment 300, a display device 302, a medical professional 304, an RT system 312, a proprietary medical application 314, a third-party medical application 316, treatment administration software 310, an oncology information system 308, and a patient 306.

[0044] RT system 312 provides the features and functions of RT system 108 as described with respect to Figure 1. A user interface may be displayed on the display device 302, enabling medical professionals 304 to interact with the software and hardware of RT system 312. RT system 312 includes interoperability and software to provide imaging assistance, tumor contouring, treatment (Tx) planning, patient record keeping and treatment plan review, and quality assurance (QA). Through the interoperability engine, RT system 312 can interact effectively with proprietary medical applications 314 and third-party applications 316. Such interaction may be achieved through industry standards, application programming interfaces, and / or specific technologies discussed throughout this document. Proprietary applications 314 may belong to a company providing various diagnostic or treatment solutions for medical problems, such as CT, MRI, radiotherapy, X-ray, and other medical software and hardware. Third-party applications 316 belong to third-party companies that provide various diagnostic or treatment options for medical problems, such as CT, MRI, radiotherapy, X-ray, and other medical software and hardware. The RT system 312's ability to work well with a variety of in-house and third-party applications is invaluable to medical professionals 304. Once medical professionals 304 have interacted with the RT system 312 to finalize a treatment plan, the treatment administration software 310 works with the oncology information system 308 to administer medical treatment to patient 306.

[0045] Figure 4 shows a medical process and block diagram according to an embodiment. A flowchart 400 illustrating the workflow of the RT system 108 of the oncology medical system 100 is shown. The workflow manager 410 of the RT system, in this embodiment, includes a graphic user interface (UI), data management, and storage.

[0046] Flowchart 400 illustrates the various steps in the medical process and how the radiotherapy system can provide support for the patient. Past patient data and medical history can come to the RT Workflow Manager 410 from OIS 454, EMR 452, RIS / PACS 450, diagnostic imaging 402 (e.g., from medical imaging equipment), image registration 420, and multidisciplinary team review 404. When patient registration 412 occurs, the patient begins or resumes their medical journey and is registered in the patient registry 414. The patient's journey can then proceed through many steps shown in Flowchart 400, depending on several factors about the patient and their medical condition. These steps include tumor contouring review 492, treatment planning 484, planning review 486, planning quality review 488 (QA - Quality Assurance, QC - Quality Control), treatment initiation 490, and follow-up outpatient visits 492. Each module of the system, such as the planning instruction module 464 and the intelligent planning evaluation module 468, can help automatically assist in these steps. Furthermore, depending on the patient and medical issues, additional steps may occur, such as CT / MR / PETCT simulation scanning 416, CT / MR / PETCT / 4DCT / 4DMR contouring 418 (which may utilize CTV / GTV / ROI automatic contouring 460 and / or OAR automatic contouring 462), image registration 420, CT / MR SIM guidance 432, patient scheduling via patient scheduling 434, equipment scheduling via equipment scheduling 436, personnel scheduling via personnel scheduling 438, smart CT / MR protocol selection 440, protocol review 446, contrast agent injection 444, and AI-based registration and synthesis 472.

[0047] Each step and workflow manager 410 shown in flowchart 400 can utilize the AI ​​model self-learning and training platform 470. As will be discussed later in this document in relation to the processes and methods in subsequent diagrams, the RT system leverages machine learning and artificial intelligence for many innovative assistance for the patient's journey. Furthermore, such AI models can be continuously trained with further input on patients and medical issues.

[0048] Workflow Manager 410 is an example of a workflow manager and / or interoperability engine for the RT system 108 in Figure 1. In the example in Figure 4, the data protocol includes CT / MR / PETCT simulation scanning 416 (e.g., using MWL and / or MPPS), CT / MR / PETCT / 4DCT / 4DMR contour definition 418, RIS / PACS 450, EMR 452, and OIS 454. Workflow Manager 410 supports information exchange via DICOM and other protocols, enabling a comprehensive review of integrated data from OIS 454, the Therapy Planning System (TPS) including the Planning System 484, the Planning Review System 486, and the Planning Quality Assessment / Quality Management System 488, EMR 452, and RIS / PACS 450. Text data is transferred between functional modules and DICOM (e.g., shown in blue boxes), and DICOM-RT data is transferred between workflow steps (e.g., shown in brown boxes).

[0049] During multidisciplinary team meetings 404, patient images and documents are exchanged among team members. Traditionally, patient information could be physically recorded (e.g., on paper) during multidisciplinary team meetings (MDTs) (e.g., multidisciplinary team meetings 404) and manually entered into the Oncology Information System (OIS) 454. As described in this document, the workflow manager 410 securely manages the distribution of patient images via image interfaces (e.g., DICOM) and documents via document interfaces such as HL7 (e.g., text-based communication). For example, results and / or conclusions may be distributed among healthcare providers across geographical distances, network boundaries, and / or through professional social networks.

[0050] Patients confirmed to receive radiotherapy treatment are registered with the radiology department, which may include providing clinical personnel with patient information such as medical history, demographic information, and aggregate information about the patient's condition. The workflow manager 410 guides clinical personnel by filling out the patient reception 412 according to a predetermined workflow. For example, some patient information may be used for the first workflow but not for the second workflow for the patient reception 412. Through the DICOM worklist adapter 430 provided by the workflow manager 410, information exchange and automated workflow entry between radiotherapy imaging equipment from different manufacturers can be realized by the patient reception 412, including, for example, patient demographics, scanning schedule, and specific scanning precautions and requirements. The patient reception 412 can provide the patient's medical team with information about the patient and their treatment plan, enabling the medical team and the patient to efficiently receive and handle the patient.

[0051] The DICOM worklist adapter 430 can be configured with a number of publicly published and / or recognized data dictionaries from different manufacturers. For example, the DICOM worklist adapter 430 can be configured as a converter that reads a manufacturer's data dictionary with common rules, adapting the data dictionary to match the data language, and converting patient reception information into the language used by the scanning device. In this way, the DICOM worklist adapter 430 can convert unstandardized updated information into a standardized format. Traditionally, the DICOM worklist adapter and demographic data may be primarily used for radiology. In radiology oncology, the Oncology Information System (OIS) manages and stores specific oncology demographic information. Interoperability systems also include Modality Worklist (MWL) services. The transfer of patient demographic data between MWL services provided by the OIS can present problems because different vendors may use different DICOM tags in the OIS, and the OIS data may not be fully recognized by the CT or MR system. The DICOM worklist adapter 430 of the interoperability system disclosed herein may enable CT and / or MR simulation scanners to syntactically analyze specific oncological information supported by their respective simulation scanners and transmitted via the DICOM modality worklist adapter 430.

[0052] The workflow manager 410 can seamlessly connect DICOM tag data via the DICOM worklist adapter 430 by reading numerous data dictionaries and providing interoperability for data communication between different platforms and different manufacturers using its internally included data matching algorithms. For example, in conventional systems, patient data registered in the OIS system 454 may not be fully transferred to a simulated CT scanner, as described later in this document. This process, in which one user (e.g., a healthcare provider) manually enters the patient's demographic information and another user cross-checks the entered information to ensure the accuracy of the patient data (e.g., information about the patient's condition) entered during patient registration 414, can be time-consuming and labor-intensive. Therefore, a method for automatically filling in patient information on a patient questionnaire is desirable to enable rapid and accurate information transmission. By using the DICOM worklist adapter 430 together with the patient reception 412, the current overly manual process can be significantly reduced, lowering the possibility of manual errors.

[0053] Using the patient reception 412, a patient simulation scan instruction can be generated using the CT / MR simulation guidance module 416. The simulation scan may follow the standard operation of conventional modality scans such as CT scans, MR scans, and PET-CT scans. In some examples, the simulation scan may be a computer simulation scan that outputs a predictive image that could be generated by a scan based on input parameters. The operation of each module of the simulation scan is the same as the operation of conventional modules, and the interoperability system described herein enables coordination between modules. Compared to conventional simulation scans, the simulation scan instructed by the patient simulation scan instruction can include a series of decentralized factors, including patient registration, patient booking, scan protocol creation, equipment preparation, and operator preparation, enabling independent management of the process. By enabling individual modules of the interoperability system to run dynamically through a cooperative mechanism, it is possible to generate a new patient booking list when a patient booking is changed, as described with respect to the patient scheduler 434.

[0054] Data preparation for the simulation scan 416 is managed through a workflow module to be automatically exported to the simulation scan modality. Generating a patient simulation scan instruction may involve collecting relevant patient demographic and medical information using the patient reception 412 module. The interoperability and workflow manager system can then initiate the workflow within the radiology oncology department (an example of a clinical department to which the interoperability system is integrated). Demographic data, disease-specific information, and simulation scan instruction information, such as scanning area and contrast agent, can be collected using one or more whole-entity information systems, such as the EMR system 452, for radiology oncology patients. The interoperability and workflow manager system can output data forms via the DICOM worklist adapter 430 in an electronic format (e.g., a standardized format) compatible with the simulation scan system (e.g., CT, MR, PET / CT, PET / MR). The patient simulation scan instruction may indicate that the patient simulation scan was requested and / or recommended by the healthcare provider based on patient information in the patient reception 412.

[0055] The workflow manager 410 can automatically generate recommended scanning protocols for simulated imaging devices (e.g., CT, MR, and PET-CT) through the intelligent scanning protocol module 440. The intelligent scanning protocol module 440 can obtain patient demographic information (e.g., weight, height, age, and sex) from the patient reception 412 and generate protocols in combination with scanning protocol imaging device guidelines that comply with industry standards and / or user-defined guidelines.

[0056] The workflow manager 410 further includes a protocol review and approval mechanism 1205 used to review the scanning protocols generated by the intelligent scanning protocol module 440 and determine whether an appropriate scanning protocol / sequence has been selected. The intelligent scanning protocol module 440 consists of an algorithm that can generate matching parameters for the respiratory gating device 442 and contrast agent injector 444 from the scanning instructions. For example, a machine learning model is used as the algorithm that drives the automatic generation of scanning protocols. The selected protocol data stored in the interoperability system can be obtained from pre-scans. The selected protocol data is used as the basis for future procedure recommendations and scanning protocol planning. Each selected protocol includes the RIS procedure name (e.g., as defined in MWL), scanner protocol identifier, patient age, patient height, and patient weight, as well as parameters for the respiratory gating device and contrast agent injector. The recommended scanning protocol can be executed using at least one of two methods: a linear weighted moving average (LWMA) statistical method, or a machine learning method such as a Naive Bayes classifier. Operating parameters for the respiratory gating device 442 and the contrast agent injector 444 are sent to each device by the workflow manager 410.

[0057] Following protocol generation, the generated protocol can be viewed using a management process and a user interface. In Protocol Review 446, the user can provide user input that can be used by the interoperation system to modify each step of the generated protocol. For example, the generated protocol and pre-protocols, and / or alternative generated protocols, may be output for display so that they can be displayed for comparison of more than one protocol at a time. The display of the protocol may include the display of embedded electronic scanning guidelines. In Protocol Review 446, an operational interface may be provided to allow the user to approve or modify the generated protocol. Following the receipt of user input indicating protocol approval, the interoperation system executes the generated protocol by initiating the next step in the workflow.

[0058] The patient scheduler module 434 uses an AI algorithm to foresee and predict the probability that a patient will not show up and / or will be late over a certain period of time. For example, this period may be 7 days. Based on the predicted probability, the patient scheduler module 434 can automatically generate an updated patient schedule based on the patient's priority and likelihood of arrival if the patient does not show up or is late. In this way, as part of the workflow manager 410, the patient scheduler module 434 can automatically provide guidance to the patient for scanning and treatment preparation based on the simulated scanning instructions and the subsequent radiotherapy treatment plan. For example, the workflow manager 410 can generate and send a calendar notification to the patient that includes the time, date, location, and necessary preparations for the scanning. Patient response feedback, such as the likelihood of the patient to be scanned showing up, can be provided to the workflow manager 410 via the patient scheduler module 434.

[0059] The workflow manager 410 is further configured with an equipment scheduler module 436 that can automatically adjust the equipment schedule of a clinical department (for example, a radiology department including at least one scanning device). The equipment scheduler module 436 can adjust the equipment schedule of a clinical department, including at least one simulation device, a TPS, and treatment devices such as a linear accelerator proton therapy (high-energy radiation that can be used for cancer treatment). The equipment scheduler module 436 can also automatically update the equipment schedule based on equipment status and priority to match the latest patient schedule as patient appointments change.

[0060] The personnel scheduler module 438 of the workflow manager 410 can automatically manage and schedule departmental personnel based on factors such as available personnel, upcoming procedures, and geographical details. Thus, the workflow manager 410 can automatically identify, plan, and schedule patient scans using the patient scheduler module 434, the equipment scheduler module 436, and the personnel scheduler module 438. Patient, personnel, and equipment coordination can be automatically adapted and configured by the workflow manager 410. Relevant personnel can be notified of the time, date, and location of the scan via text message and / or email. In this way, the workflow manager 410 provides a method to effectively ensure and improve operational efficiency across departments.

[0061] After each of the above steps—patient registration, identification of scanning parameters, and scheduling of the scan—is completed, the workflow manager 410 automatically coordinates the CT / MR / PET-CT simulation scan 416. The simulation scan includes the corresponding patient information, scanning protocol, patient schedule, equipment schedule, and personnel schedule as described above. Following the completion of the simulation scan 416, the workflow manager 410, in embodiment, obtains information about the completion of the simulated scan via DICOM MPPS.

[0062] Patient image data generated by the simulated scan is automatically transferred to the contouring application 418. The workflow manager 410 may manually control the start and stop of the contouring procedure performed by the contouring application 418, or it may automatically trigger the start of the contouring procedure by transferring patient image data to the contouring application 418. For example, the workflow engine of the workflow manager 410 uses the availability of patient image data to automatically trigger the OAR automatic contouring 462 and / or the AI ​​model self-learning and training platform 470. The hardware platform and AI model training software of the self-learning and training platform 470 may enable the user to train the contouring AI model to update existing models in order to continuously improve results. The data exported from the contouring application 418 is temporarily stored in the database of the workflow manager 410 and passed to the image alignment process 420 to automatically start the image synthesis calculation 472. For example, if a patient undergoes a multi-modality simulation scan such as CT, MR, and PET-CT scans, image synthesis is performed between differently contoured outputs. The availability of image data can trigger the generation and display of notifications on the user interface. Based on the notification, the user can interact with the user interface and provide user input. The receipt of user input may indicate the start or stop of automatic contouring provided by the AI ​​algorithm.

[0063] Following the image alignment process 420, patient images can undergo a contour demarcation review 482 performed by the user and / or an automated system. Based on the contour demarcation review 482, a TPS is performed, including planning 484, planning review 486, and planning QA / QC 488. The workflow manager 410 includes a digital planning instruction application 464 as part of planning 484, which intelligently assists users (e.g., radiation oncologists, medical dosimetrists, and / or medical physicists) in developing radiotherapy plans and generating detailed digital prescriptions, thereby replacing current paper-based radiotherapy treatment plans. For example, the planning instruction may include information on the radiotherapy planning goals of a physician or other healthcare provider, which can be used to improve the efficiency and communication of the treatment planning process by enabling standardized communication. The input to the planning instruction application 464 may be a default template of planning goals for a patient according to a plan selected and manually filled in by the healthcare provider. The planning information can be output for display to the user and may also be stored in the interoperability system database. The plan may be reviewed by planning review 486, which includes an intelligent planning evaluation application 468 that uses AI methods to pre-evaluate the treatment plan and suggest modifications. At the same time, the AI-based evaluation module may allow the user to train the planning evaluation AI model to improve performance and update the existing model using a self-training platform provided by the workflow manager 410. The treatment plan is checked for quality assurance and quality control in planning QA / QC 488.

[0064] Once a treatment plan has been approved through the treatment planning step, the workflow manager 410 can provide the radiology department with information to be used to initiate treatment 490. For example, this information includes the generated and approved treatment plan, the aligned / composite / contoured patient images, and the patient's demographic data. Following treatment, follow-up outpatient visits 492 can be scheduled to discuss treatment outcomes and / or determine future treatment plans. Changes to the treatment plan and treatment outcome data can be entered into the workflow manager 410 to help track the patient's progress through the treatment plan.

[0065] In this way, the RT system's workflow manager provides automation, enabling users to configure workflows and automatically direct data integration, task execution, and result deployment while connecting with multi-vendor external systems. Third-party applications can be controlled and invoked by calling application-side interfaces for standard AI / DL applications. The system can provide a broad catalog of powerful radiation oncology applications and offer seamless integration of any application within the scope of its own implementation process. The system can provide a single user interface used with existing RT IT multi-vendor systems. This system only needs to store reference data, reducing data overhead. Furthermore, this system can reduce the cognitive burden on users that arises from navigating through numerous software systems.

[0066] Figure 5 shows a tree-like process that supports medical decision-making according to an embodiment. This process is also called a multi-level model. Figure 5 includes an RT system patient reception 500, a general block 502, a simulation instruction block 504, and a planning instruction block 506.

[0067] In one embodiment, the most likely personalized treatment plan can be determined by a non-relational database and Bayesian statistics, as shown in the example of patient reception 500. Compared to relational databases, non-relational databases decouple data from applications and store data in a tree structure. This allows for a flexible schema in which Bayesian statistics can be used to compute the correct data path. Bayesian statistics use observed and unobserved parameters in a statistical model for finding probability distributions. Such a Bayesian network is a probabilistic graphical model that represents a set of variables and their conditional dependencies via a directed acyclic graph (DAG), as shown in the example in Figure 5. Bayes' theorem describes the conditional probability of an event based on data about the event and conditions related to the event, such as prior information or beliefs, or medical treatment for the patient. The dashed circles and lines in Figure 5 show the initial probability flow through the tree structure based on factors such as patient details, diagnosis, and environmental settings. In the imaging layer, predictive Bayesian statistics are divided into dashed paths (most likely paths) and dotted paths. Furthermore, at the contour demarcation level, as we learn more about the tumor through contour demarcation, the predicted pathways branch again, adding the dashed-dotted-line pathway. As shown in the example in Figure 5, the predictive ability of the RT system predicted a treatment plan with 83% probability along the dashed-dotted-line pathway, a treatment plan with 10% probability along the dashed-dotted-line pathway, and a treatment plan with 7% probability along the dotted-line pathway. Thus, both unrelated data structures and Bayesian models can help predict a patient's medical path. Once a physician has filled out a form containing variable paths about a patient, this data can be used to predict paths for future patients. Such unrelated data structures enable this probability in models other than Bayesian network models, and the Bayesian network model is just one example of an embodiment.

[0068] Patient registration is a critical area of ​​healthcare that has long required technological improvements. AI can help automatically fill out patient questionnaires, including medical history, current medications, and allergies. This saves time and reduces human error. Using AI-assisted smart patient questionnaires, the medical workflow leading up to radiation therapy can be initiated. The questionnaire collects the patient's medical history, current medications, allergies, and other critical information necessary to determine the best course of treatment. The questionnaire can be automatically completed by the RT system and reviewed by the radiation oncologist and medical team. When automatically completed, artificial intelligence analysis of information from heterogeneous sources (EMR, PACS, and oncology applications, etc.) includes checking the information based on the extent possible for the relevant fields of the patient questionnaire.

[0069] As part of the patient registration process, the system and methods described in this document can store templates, allowing users to store and search a list of their preferred templates. When using patient registration, AI can be provided in assist mode. In this mode, as the user answers questions, the questionnaire can suggest answers based on the most likely responses. The user can verify or change values ​​as needed. Furthermore, in an additional mode, as the user answers questions, the questionnaire suggests key questions that may lead to the automatic completion of the questionnaire. In some cases, the results of the OIS may be sufficient to complete the diagnosis. This function provides users with accuracy and efficiency by enabling the workflow and questionnaire to be completed or structured automatically. For example, AI / ML can help identify patients who may be at risk of certain side effects or complications and recommend appropriate treatment templates. Such a system brings workflow efficiency and reduces human error by introducing validity features, including predictive workflows.

[0070] Figure 6 shows a radiotherapy process according to an embodiment. Figure 6 includes an AI-enabled RT system 600, a workflow manager 602, a trend monitor 604, an AI algorithm 606, a proposed correction 608, a decision step 610, an AI QA check 612, and a quality decision step 614.

[0071] The AI-enabled RT system 600 facilitates the health and quality assurance of workflow data. The workflow manager 602 of the RT system 600 includes many of the steps already discussed in this document. These include patient registration, acquisition of imaging scans, image segmentation, contouring and medical image analysis to understand medical issues in areas of interest, development of treatment plans, scheduling of treatments, and administration of treatments. Throughout this process, the RT system 600 includes trend monitoring 604. Trend monitoring 604 monitors trends along each step of the process for AI learning. This monitoring includes software trends such as which parts of the software were clicked most by users, which options were most selected, and which parts of the workflow were most omitted, and similar trends. The software incorporates these trends to update the RT system 600 and workflow manager 602 to improve them. Another set of trends for trend monitoring 604 are medical trends. These trends include trends related to patient registration, imaging protocol selection, diagnosis, radiology report construction, and treatment planning and administration.

[0072] Next, trend monitoring 604 supplies these trends and learnings to AI algorithm 606. AI algorithm 606 makes proposed improvements and corrections 606 to the software, medical diagnoses, treatment plans, and other trends mentioned throughout this document. Acceptance in step 610 may be performed by the system in some cases, for example, by comparing the change with medical guidelines for the disease in question and accepting it if it is within the scope of the medical guidelines. In other cases, acceptance in step 610 may be performed by the user, for example, by a physician when changing the dose of radiotherapy in a treatment plan, and they may make a proper review. The change is then quality-checked based on software standards, usability standards, and medical standards, etc. If the change meets the quality standards, the change may be introduced from AI QA check 612 to workflow manager 602. Throughout this process, the AI ​​model and algorithm may be constantly updated based on data related to trends, feedback, user judgments, and quality checks.

[0073] The system utilizes AI-driven machine learning algorithms to establish an internal QA system that checks data integrity between work steps, ensuring quality at every stage of the workflow. This internal QA system identifies and corrects any errors or inconsistencies in the data, guaranteeing that the data is accurate, reliable, and consistent throughout the entire workflow. Furthermore, the use of AI and machine learning allows the software to learn and improve over time, becoming more efficient and effective in detecting and resolving problems in the workflow. This ultimately leads to improved patient outcomes and better overall healthcare delivery. AI algorithm 606 learns from past quality checks to identify patterns that indicate potential problems, enabling more accurate and efficient quality control. AI-enabled RT system 600 provides real-time monitoring capabilities using AI-driven algorithms. Trend monitoring 604 monitors the system, constantly monitoring the workflow process, identifying quality issues when they occur, and enabling immediate improvement.

[0074] Figure 7 shows the clinical trial matching process 700 according to an embodiment. This process aims to match a patient with an appropriate clinical trial or treatment option based on the patient's medical history and other relevant factors. In step 702, patient information is collected from heterogeneous sources such as EMR, PACS, and patient registration. This information is fed into the AI ​​model 704. In step 706, the patient information is processed through an integrated multi-modality data model. In step 708, the process searches for clinical trials related to the patient information, which may include the patient's diagnosis and treatment plan, and matches the patient. In step 710, the AI ​​model 704 verifies whether the suggestions from step 708 for matching the patient with clinical trials are accurate against relevant guidelines. Then, depending on the AI ​​model process, different stratified output options are selected. These options may be option 1 radiotherapy 712, option 2 radiotherapy and immunotherapy 714, and / or option 3 radiotherapy and theranostics. A treatment approach such as theranostics is a bifurcated approach to cancer diagnosis and treatment using radiation tracers. Radiation tracers are compounds made of radiation and chemicals that selectively bind to specific targets within the body.

[0075] Figure 8 shows the process of quality check in a medical environment according to an embodiment. Process 800 allows the RT system to analyze patient data to identify potential problems or isolated values ​​in the treatment plan or other aspects of medical care. For example, it identifies potential errors such as applying a prostate cancer treatment process to a female patient or applying an adult treatment template to a pediatric patient. Step 802 extracts input data such as patient information, treatment plan, imaging scan information, and additional information as discussed herein. Step 804 checks the input data for quality and accuracy issues through artificial intelligence. For example, if a name is entered incorrectly or if some input data is outside the possible range of that data, the system can identify a problem (for example, if blood pressure is outside the human possible range, there may have been an input error). If no problems are found, the process moves from step 806, and the software continues in the workflow management process. If problems are found, the user is notified in step 808. Alternatively, depending on the problem, the system may check with other AI applications that automatically find solutions to the problems. The AI ​​algorithm supporting the RT system can automatically generate specific solution suggestions in step 810 to resolve the identified problems. Once selected, the problems are corrected, and the process returns to step 802.

[0076] Figure 9 shows a process for relationship and pattern recognition in a medical environment according to an embodiment. Process 900 can help make predictions based on pattern recognition and propose decision-making processes and future treatment plans. AI relationship and pattern recognition 910 can help identify patients who may be at risk of some side effects or complications and recommend appropriate treatment templates. AI relationship and pattern recognition 910 receives input from planning instruction selection 902, patient registration 904 including service and modality information, new patient information 906, and / or data 908 from the hospital system. As an example, a relationship or pattern between some planning instruction and a medical problem may be detected by AI relationship and pattern recognition 910. A relationship or pattern between patients of some age and / or sex may be detected by AI relationship and pattern recognition 910. These relationships and patterns may become memory data for modalities based on patient status in step 912. Alternatively, the system can make changes to treatment plans, imaging protocols, software, and / or other decisions based on relationship and pattern recognition 910.

[0077] Figure 10 shows a process for automated medical software updates according to an embodiment. RT can process and analyze data from patients and users using AI-driven machine learning algorithms to reveal patterns, relationships, and trends. These processes can be performed, for example, through an AI model self-learning and training platform 470. Process 1000 shows how AI can update the RT system's software and medical guidelines based on current treatments and patients, as well as industry trends.

[0078] In step 1002, the system receives data on academic research related to radiotherapy. This step is an example and may include other medical studies, guidelines, and government reports. As new information related to the patient's medical problem exists, the RT system aims to automatically improve medical decisions and related software through this process. Hospitals or clinics may have their own relevant guidelines or regulations regarding medical problems or radiotherapy. In step 1004, these guidelines are provided to the process.

[0079] In step 1006, the RT system evaluates whether the trend potentially suggests a change to hospital guidelines or physician recommendations, based on the guidelines from step 1004 and new trend information from step 1002. In step 1008, the RT system also evaluates whether others have already changed their practice based on the trend, such as changing their own hospital or clinical guidelines based on the research. These factors from steps 1006 and 1008 are provided in step 1010.

[0080] In step 1010, the AI ​​provides a cost-benefit analysis of making changes to the software and / or treatment plan, for example. Then, in step 1012, the changes may be approved (by the user or the system, depending on the form of the changes). If approved, and if the changes relate to the software, the software may automatically update itself in step 1014. If the approved changes relate to guidelines or treatment plans for medical issues, the RT system software may also update these guidelines or treatment plans. If the changes are not approved, the system may record the reasons why the AI ​​should consider them for its own self-learning in step 1016, and provide this information back to step 1010 for learning purposes. Through this process, the system can more quickly improve the efficiency and usability of the software. In addition, through this process, medical care for patients is updated and improved more quickly based on new insights.

[0081] The advantages of the method and system presented in this book include improved integration, automation, standardization, and individualization compared to conventional methods of assembling workflow steps. The method and system enable resources for case reviews, decision support, and reporting on patients. Personnel management and scheduling within departments such as radiation oncology can be performed through the platform based on factors such as available personnel. The method and system can enable users to achieve greater accuracy, efficiency, integration, ease of use, and patient-centered care. In addition, the time spent on complex workflow steps can be reduced through the automation of workflow steps and their execution. Furthermore, the method and system provides support for automated workflows and trigger issuance. For example, contouring of organs at risk can be automatically triggered and performed. The method and system can be integrated and interoperable with existing clinical environments such as TPS, OIS, and HIS. Multi-vendor clinical interoperability, along with the advantages listed above, can compress the timeline of the RT workflow, providing a better overall picture, management, and monitoring of the treatment planning workflow. Furthermore, patients and software users benefit from analysis of personnel and equipment utilization (e.g., trend monitoring in Figure 6), individual user behavior and productivity, and the efficiency of the treatment process by the assigned user. In addition, the systems and methods described in this document optimize and accelerate data transfer across multiple platforms, reduce the risk of human error, and track patients throughout the entire radiotherapy pathway.

[0082] The methods and systems described in this book overcome the difficulties of data transfer between multi-vendor infrastructure structures and enable fully digital patient tracking across numerous appointments. These methods and systems add a level of automation to the patient workflow in radiology departments. Through various connectors, the methods and systems enable automated data transfer between various third-party applications, providing a clear overview of the patient workflow and a universal environment for review and approval at each step of the workflow.

[0083] The systems and processes described below may be implemented within hardware such as a single integrated circuit (IC) chip, multiple ICs, or an application-specific integrated circuit (ASIC). Furthermore, the order in which some or all of the process blocks appear in each process should not be considered limiting. Rather, it should be understood that some of the process blocks can be executed in various orders, and not all of them may be expressly shown in this disclosure.

[0084] The illustrated aspects of this disclosure can also be implemented in a distributed computing environment in which several tasks are performed by remote processing units connected through a single communication network. In a distributed computing environment, program modules may be located in both local and remote memory storage.

[0085] Furthermore, it should be acknowledged that the various components described herein may include electrical circuits that may include components and circuit elements of appropriate value for implementing each embodiment of the innovative technology of the subject matter. Moreover, it should be acknowledged that many of the various components may be implemented on one or more integrated circuit (IC) chips. For example, in one embodiment, a set of components may be implemented as a single IC chip. In other embodiments, one or more of each component may be manufactured or implemented on separate IC chips.

[0086] Referring to Figure 11, a schematic block diagram of the computing environment 2100 according to the present disclosure is shown, in which the System, Method and Computer-Readable Medium of the Subject are deployed. The computing environment 2100 includes one or more clients 2102 (e.g., laptops, smartphones, PDAs, media players, computers, portable electronic devices, and tablets). Clients 2102 may be hardware and / or software (e.g., threads, processes, computing devices). The computing environment 2100 also includes one or more servers 2104. Servers 2104 may also be hardware or hardware combined with software (e.g., threads, processes, computing devices). Servers 2104 may store threads that perform translations, for example, by using the aspects of the present disclosure. In various embodiments, one or more of the front-end components of the Subject may be deployed as hardware and / or software on the clients 2102, and one or more of the back-end components of the Subject may be deployed as hardware and / or software on the servers 2104. One possible communication between client 2102 and server 2104 may be in the form of data packets transmitted between two or more computer processes, the data packets may contain video data. The data packets may contain metadata, such as relevant contextual information. The computing environment 2100 includes a communication framework 2106 (e.g., a wide-area network such as the Internet, or a mobile network) that can be used to facilitate communication between client 2102 and server 2104.

[0087] Communication can be facilitated via wired (including optical fiber) technology and / or wireless technology. Client 2102 includes or is operationally connected to one or more client data stores 2108 that can be used to store local information for client 2102 (e.g., relevant context information). Similarly, server 2104 includes or is operationally connected to one or more server data stores 2110 that can be used to store local information for server 2104.

[0088] In one embodiment, client 2102 can transfer an encoded file to server 2104 according to the disclosed subject matter. Server 2104 can store the file, decode the file, or send the file to other clients 2102. It should also be acknowledged that client 2102 may transfer an uncompressed file to server 2104, and server 2104 may compress the file according to the disclosed subject matter. Similarly, server 2104 can encode video information and send this information to one or more clients 2102 via communication framework 2106.

[0089] Figure 12 shows a schematic block diagram of a computing environment 2200, another example of the subject matter, where the system, method, and computer-readable medium may be deployed. The computing environment 2200 includes a cloud-type deployment architecture consisting of one or more clients 2202 that can be connected to a system cloud 2204 via a network (e.g., the Internet). The system cloud 2204 may include a cloud load balancer, one or more application containers, one or more cloud service containers, a cloud data store, and a cloud network that connects one or more cloud components to the cloud data store. According to the cloud-based deployment architecture, client 2202 may include one or more client devices (e.g., mobile devices, laptop computers, and desktop computers) which may include or use appropriate applications (e.g., native mobile applications, web applications, and thin / thick client applications) for accessing and using one or more features and functions of the subject's native / reconfigured medical imaging system deployed in system cloud 2204. In various implementations, one or more components of system 100 may be distributed between client 2202 and system cloud 2204.

[0090] Figure 13 shows a schematic block diagram of a computing environment 2300, another example of the subject matter, where the system, method, and computer-readable medium may be deployed. The computing environment 2300 includes a virtualized intra-enterprise deployment configuration consisting of one or more clients 2202 that can be connected to a remote data center 2302 via a network (e.g., the Internet). The remote data center 2302 may include an application server subnet 2304 that can provide load balancers, one or more application containers, one or more virtualized servers, and one or more rack servers. The data center 2302 may also include one or more data stores that can be connected to the application server subnet 2304 via a data center network. In a virtualized enterprise deployment configuration, client 2202 may include one or more client devices (e.g., mobile devices, laptop computers, and desktop computers), which may include or use appropriate applications (e.g., native mobile applications, web-based applications, and thin / thick client applications) for accessing and using one or more features and functions of the subject's native / reconfigured medical imaging system deployed in data center 2302 and application server subnet 2304. In various implementations, one or more components of system 100 may be distributed between client 2202 and application server subnet 2304, and one or more data stores may be remotely located in data center 2302.

[0091] Figure 14 shows a schematic block diagram of a computing environment 2400, another example according to this disclosure, in which the subject system, method, and computer-readable medium may be deployed. The computing environment 2400 includes a local enterprise deployment configuration consisting of one or more clients 2202 that can be connected to an application server subnet 2404 via a network (e.g., the Internet). According to this embodiment, the application server subnet 2404 may be located on an enterprise premises 2402 (e.g., to a remote data center 2302). The application server subnet 2404 may include a load balancer, one or more application containers, and one or more servers. The application server subnet 2404 may be connected to one or more data stores located on the enterprise premises 2402 via an enterprise network. Similar to cloud-based and virtualized on-premises deployments, client 2202 may include one or more client devices (e.g., mobile devices, laptop computers, and desktop computers) that include or may use appropriate applications (e.g., native mobile applications, web applications, and thin / thick client applications) to access and use one or more features and functions of the subject's native / reconfigured medical imaging system (e.g., system 100) deployed in the enterprise premises 2402 and application server subnet 2404. In various implementations, one or more components of the system may be distributed between client 2202 and application server subnet 2404, and one or more data stores may be located in the enterprise premises 2402.

[0092] Figure 15 shows a schematic block diagram of a computing environment in another example of the present disclosure in which the subject system, method, and computer-readable medium may be deployed. This computing environment includes a local in-device deployment configuration in which all components of the system present herein reside in a single client device 2502. In this implementation configuration, the client device 2502 may contain a web-type application that can be linked to one or more application containers via a loopback. One or more application containers may be linked to one or more databases and / or one or more local file systems via a loopback.

[0093] With respect to Figure 16, a suitable environment 2600 for implementing various aspects of the claimed subject includes a computer 2602. The computer 2602 includes a processing unit 2604, system memory 2606, a codec 2605, and a system bus 2608. The system bus 2608 connects system components, including but not limited to system memory 2606, to the processing unit 2604. The processing unit 2604 can be any of the various available processors. Dual microprocessors and other multiprocessor architectures can also be used as the processing unit 2604.

[0094] System Bus 2608 may be any form of bus structure, including, but not limited to, memory buses or memory controllers, peripheral buses or external buses, and / or local buses, using any variety of available bus architectures, including, but not limited to, Industrial Standard Architecture (ISA), Micro Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), CardBus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Standards Institute Bus (PCMCIA), Firewire (IEEE 22104), and Small Computer System Interface (SCSI).

[0095] System memory 2606 includes volatile memory 2610 and non-volatile memory 2612. Non-volatile memory 2612 stores a basic input / output system (BIOS) which includes basic routines for transferring information between internal elements of the computer 2602 during startup, etc. In addition, according to this innovative technology, codec 2605 may include at least one of an encoder or a decoder, and at least one of the encoder or decoder may consist of hardware, a combination of hardware and software, or software. Although codec 2605 is illustrated as a separate component, it may be stored in non-volatile memory 2612. As an example rather than a limitation, non-volatile memory 2612 may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory 2210 includes random-access memory (RAM) that operates as external cache memory. From this perspective, volatile memory may store write operation retry logic, etc. To give an example rather than a limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data SDRAM (DDR SDRAM), and extended SDRAM (ESDRAM).

[0096] Computer 2602 may also include removable / non-removable volatile / non-volatile computer storage media. Figure 19 shows, for example, a disk storage unit 2614. The disk storage unit 2614 includes, but is not limited to, devices such as magnetic disk drives, solid-state drives (SSDs), floppy disk drives, tape drives, zip drives, flash memory cards, or memory sticks. In addition, the disk storage unit 2614 may include, but is not limited to, other storage media, either separately or in combination with optical disk drives such as compact disk ROM devices (CD-ROMs), CD recordable drives (CD-R drives), CD rewritable drives (CD-RW drives), or digital general-purpose disk ROM drives (DVD-ROMs). To facilitate connection of the disk storage device 2614 to the system bus 2608, removable or non-removable interfaces such as interface 2616 are typically used.

[0097] Figure 16 should be acknowledged as describing software that acts as an intermediary between a user and basic computer resources, described in a suitable operating environment 2600. Such software includes an operating system 2618. The operating system 2618 can be stored in disk storage 2614 and operates to control and allocate resources of the computer system 2602. Application 2620 leverages the management of resources by the operating system 2618 through program modules 2624 stored in either system memory 2606 or disk storage 2614, and program data 2626 such as boot / shutdown transaction tables. It should be acknowledged that the requested subject matter can be implemented with various operating systems or combinations of operating systems.

[0098] The user inputs commands or information to the computer 2602 through the input device 2628. The input device 2628 includes, but is not limited to, pointing devices such as a mouse, trackball, stylus, touchpad, keyboard, microphone, joystick, gamepad, satellite antenna, scanner, TV tuner card, digital camera, digital video camera, webcam, and microphone. These and other input devices connect to the processing unit 2604 via the system bus 2608 through the interface port 2630. The interface port 2630 includes, for example, a serial port, parallel port, game port, and Universal Serial Bus (USB). The output device 2636 uses some of the same type of ports as the input devices. In this way, for example, a USB port can be used to provide input to the computer 2602 and to output information from the computer 2602 to the output device 2636. Output adapter 2634 is shown to illustrate that there are some output devices 2636 that require special adapters, such as monitors, speakers, and printers, among other output devices 2636. Output adapter 2634 includes, but are not limited to, video cards and sound cards that provide means of connection between output devices 2636 and system bus 2608. It should be noted that other devices and / or systems of devices provide both input and output capabilities, such as remote computer 2638.

[0099] Computer 2602 may operate in a networked environment using logical connections to one or more remote computers, such as remote computer 2638. Remote computer 2638 can be a personal computer, server, router, network PC, workstation, microprocessor appliance, peer device, smartphone, tablet, or other network node, and typically includes many of the elements described with respect to computer 2602. For simplicity, only memory storage device 2640 is illustrated together with remote computer 2638. Remote computer 2638 is logically connected to computer 2602 via network interface 2642, and then via communication connection 2644. Network interface 2642 includes wired and / or wireless communication networks such as local area networks (LANs), wide area networks (WANs), and cellular networks. LAN technologies include fiber-optic distributed data interfaces (FDDI), copper-based distributed data interfaces (CDDI), Ethernet, and Token Ring, among others. WAN technologies include, but are not limited to, circuit-switched networks, packet-switched networks, and digital subscriber lines (DSL), such as point-to-point links, integrated service digital networks (ISDN) and their variations.

[0100] Communication connection 2644 refers to the hardware / software used to connect network interface 2642 to bus 2608. Although communication connection 2644 is shown inside computer 2602 for clarity in the diagram, it may also be located outside computer 2602. The hardware / software required to connect to network interface 2642, for illustrative purposes only, typically includes internal and external technologies such as modems including telephone-grade modems, cable modems, and DSL modems, ISDN adapters, and wired and wireless Ethernet cards, hubs, and routers.

[0101] The foregoing description includes examples of embodiments of the present invention. Needless to say, it is impossible to describe every conceivable combination of components or methodologies for the purpose of describing the claimed subject matter, and it should be acknowledged that many more permutations and combinations of the innovative techniques of the subject matter are possible. Accordingly, the claimed subject matter shall encompass all such changes, modifications, and variations that fall within the gist and scope of the claims. Furthermore, the foregoing description of the illustrated embodiments of the disclosure of the subject matter, including those described in the abstract, is neither exhaustive nor does it limit the disclosed embodiments to the exact form disclosed. While specific embodiments and examples have been described in this disclosure for illustrative purposes, various modifications conceivable within the scope of such embodiments and examples are possible, as will be apparent to those skilled in the art.

[0102] Specifically, with respect to the various functions performed by the components, devices, circuits, and systems described above, the terminology used to describe such components shall, unless otherwise specified, correspond to any component (e.g., a functional equivalent) that performs the specified function of the listed component, even if it is not structurally equivalent to the disclosed structure, as long as it performs the function of the disclosed content as described in the exemplary view of the claimed subject matter. In this view, it should also be acknowledged that this innovative technology includes, in addition to the system, a computer-readable storage medium having computer-executable instructions that perform various methods of operation and / or events of the claimed subject matter.

[0103] The systems / circuits / modules described above are described in relation to the interactions between several components / blocks. Such systems / circuits and components / blocks may include these components or specified subcomponents, some of the specified components or subcomponents, and / or additional components, and various permutations and combinations thereof. Subcomponents may also be implemented not as being contained within (hierarchically) a parent component, but as components linked to other components. In addition, one or more components may be combined as a single component providing a collective function, or they may be divided into several separate subcomponents, and one or more arbitrary intermediate layers, such as a management layer, may be provided to link to such subcomponents in order to provide an integrated function. Any component described in this disclosure may also interact with one or more other components that are not specifically described in this disclosure but are known to those skilled in the art.

[0104] In addition, while certain features of the innovative technology of the subject matter may be disclosed in relation to only one of several implementations, such features may be combined with one or more other features of other implementations that may be desirable and advantageous for any given or particular application. Furthermore, to the extent that “includes / including,” “has,” “contains,” and their variants, as well as other similar terms, are used in either the detailed description or the claims, these terms shall be inclusive in the same manner as the term “comprising” as an open transitional term that excludes no additional or other elements.

[0105] As used in this application, “components,” “system,” etc., generally refer to computer-related entities, whether hardware (e.g., circuits), combinations of hardware and software, software, or entities relating to an operating machine having one or more specific functions. For example, a component may be, but is not limited to, a process running on a processor (e.g., a digital signal processor), a processor, an object, an executable file, an execution thread, a program, and / or a computer. For example, an application running on a controller and a controller can both be components. One or more components may reside in a process and / or an execution thread, and a single component may be localized in one computer and / or distributed across two or more computers. Furthermore, “apparatus” may exist in the form of specially designed hardware, general-purpose hardware specialized by the execution of software installed on such hardware to enable it to perform a specific function, software stored on a computer-readable storage medium, software transmitted on a computer-readable transmission medium, or a combination thereof.

[0106] Furthermore, where the terms “example” or “exemplary” are used in this disclosure, they mean an example, a real-world example, or an illustration. Any viewpoint or design described as “exemplary” in this disclosure is not necessarily construed as being preferable or more advantageous than other viewpoints or designs. Rather, the terms “example” or “exemplary” are intended to present a concept in a specific manner. Where used in this application, the term “or” means an intensional “or” rather than an exclusionary “or.” That is, unless otherwise stated or evident from the context, “X uses A or B” means any of the natural intensional permutations. That is, if X uses A, or X uses B, or X uses both A and B, then “X uses A or B” is satisfied under any of these examples. In addition, where used in this application and claims, the indefinite article generally means “one or plural” unless otherwise stated or evident from the context.

[0107] Computer devices typically include a variety of media, which may include computer-readable storage media and / or communication media, and these two terms are used differently in this specification as follows: Computer-readable storage media may be any available storage media that can be accessed by a computer, and may typically be non-transient in nature, and may include both volatile and non-volatile media, removable and non-removable media. To the extent that they are described, but not limited to, computer-readable storage media may be embodied in relation to any method or technique for storing information such as computer-readable instructions, program modules, structured data, or unstructured data. Computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, digital general-purpose disk (DVD), or other optical disk storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices, or other tangible and / or non-transient media that may be used to store desired information. Computer-readable storage media can be accessed by one or more local or remote computing devices for various operations relating to the information stored on the media, for example, via access requests, queries, or other data retrieval protocols.

[0108] In light of the exemplary systems described above, methodologies that can be embodied according to the subject matter described herein will be more fully recognized with respect to the flowcharts of various drawings. For the sake of simplicity, the methodologies are illustrated and described as a series of operations. However, the operations in this disclosure may occur in various orders and / or simultaneously, and may occur together with other operations not presented and described herein. Furthermore, not all illustrated operations are required to embodied the methodologies according to some aspects of this disclosure. In addition, those skilled in the art will understand and recognize that the methodologies may alternatively be represented as a series of interrelated states via state diagrams or events. Furthermore, it should be recognized that the methodologies disclosed herein can be stored in articles that facilitate the transport and transfer of such methodologies to a computer. The term "article" as used herein encompasses computer programs accessible from any computer-readable device or storage medium.

[0109] It should be understood that the above description is illustrative and not limiting. For example, the embodiments (and / or aspects of each embodiment) described above may be used in combination with each other. In addition, many modifications can be made to adapt specific situations or materials to the teachings of various embodiments of the invention without departing from the scope of the invention. The dimensions and forms of materials described herein are for defining the parameters of various embodiments of the invention, but these embodiments are illustrative and not limiting. Many other embodiments will become apparent to those skilled in the art upon examination of the above description. Accordingly, the scope of the various embodiments of the invention shall be determined in relation to the claims, together with the entire scope of the equivalent for which such claims are granted. It can be modified in various ways.

[0110] In the claims, the term "including" is used as a standard English synonym for "comprising," and the term "in which" is used as a standard English synonym for "wherein." Furthermore, in the claims, terms such as "first," "second," and "third" are used simply as labels and do not impose numerical requirements on the objects of these terms. Moreover, the limitations of the claims are not written in the "means-plus-function" format, and such limitations of the claims should not be interpreted under 35 United States Code § 112, paragraph 6 unless they explicitly use wording that follows "means for..." with a statement of function that does not include further structure.

[0111] This document discloses various embodiments of the invention, including the optimal mode, and uses examples to enable any person skilled in the art to implement various embodiments of the invention, including manufacturing and using any device or system and performing any incorporated method. The scope of various patentable embodiments of the invention is defined by the claims and may include other examples that would be conceivable to a person skilled in the art. Such other examples shall be within the claims if they have structural elements that are identical to the verbatim wording of the claims, or if they include equivalent structural elements that are not substantially different from the verbatim wording of the claims. [Explanation of symbols]

[0112] 10. Computational Tomography (CT) Imaging Systems 12 Gantry 13 Rotating member 14 X-ray source 15. Pre-Patient Collimator 16 X-ray beams 18 Detector Assembly 20 detectors 22. Data Acquisition System (DAS) 24 Subjects 26 Control mechanism 42 Display 46 Electric Table 48 Gantry opening 50 Coordinate Systems 52 Z axis 54 X-axis 56 Y-axis 100 Oncology Healthcare Systems 102 Medical Imaging Systems 108 Radiotherapy Systems 110 Treatment System 118 Data Flow 300 Medical Environment 302 Display device 304 Medical Professionals 306 patients 310 Treatment Administration Software 312 RT System 314 Proprietary medical applications 316 Third-party medical applications Flowchart showing the workflow of the 400 RT system 480 500 RT System Patient Registration 502 General Block 504 Simulation instruction block 506 Planning and Instruction Block 600 AI-enabled RT system 700 Clinical Trial Matching Process 800 Quality control processes in a medical environment 900 Relationship and pattern recognition processes in a medical environment 1000 Automatic Update Process for Medical Software 2100, 2200, 2300, 2400, 2500 computing environment 2600 Suitable operating environment

Claims

1. One or more processors (2604), Memory (2606) and, One or more programs and A medical system comprising, wherein the one or more programs are stored in the memory (2606) and are configured to be executed by the one or more processors (2604), and the one or more programs are An instruction for patient registration (412, 500) using a user interface (116), wherein the instruction additionally receives information from heterogeneous information sources, including at least an electronic medical record (EMR) and a medical image storage and transmission system (PACS), and pre-fills each part of the patient questionnaire based on an artificial intelligence analysis of the information from the heterogeneous information sources, An instruction for workflow management through the medical diagnosis and treatment process based on the patient registration (412, 500), the instruction for workflow management including providing a user interface (116) that displays a workflow orchestration that spans the diagnosis and treatment process, An instruction for trend monitoring (604) for each step of the workflow management, the instruction for trend monitoring (604) which can provide suggestions in the workflow based on automated quality review related to the trend, Instructions for formulating a treatment plan (484) based on user input in the workflow of the aforementioned medical diagnosis and treatment process, and A healthcare system that includes this.

2. The automated quality review related to the aforementioned trend is based on healthcare industry quality standards. The medical system according to claim 1.

3. The one or more programs described above are Instructions for an interoperability engine (112) that provides operational capability between various software applications and data storage systems based on industry standards and programming interfaces for specific applications. The medical system according to claim 1, further comprising:

4. The medical system according to claim 1, wherein treatment planning (484) may further be based on predictive analysis of the data of the system based on patient registration (412, 500) and workflow management, and is stored in a non-relevant database and can use Bayesian statistical methods for predictive analysis.

5. The medical system according to claim 1, wherein the artificial intelligence analysis of the information from the heterogeneous sources includes checking the information based on the relevant fields of the patient questionnaire to the extent possible.

6. The medical system according to claim 1, wherein the artificial intelligence analysis of the information from the heterogeneous sources includes searching for relevant clinical trials and comparing them with the patient (24) information to verify that the patient (24) information conforms to the scope of clinical trial guidelines.

7. The one or more programs described above further: Instructions for pattern recognition (910) between patients based on artificial intelligence analysis of the workflow management of multiple patients, wherein the instructions for pattern recognition (910) provide suggestions to the user interface (116) on a display based on the recognized patterns. The medical system according to claim 1, comprising:

8. A medical method in an apparatus having one or more processors (2604) and memory (2606), A step of patient registration (412, 500) using a user interface (116), wherein information is additionally received from heterogeneous information sources, including at least an electronic medical record (EMR) and a medical image storage and transmission system (PACS), and each part of the patient questionnaire can be pre-filled based on an artificial intelligence analysis of the information from the heterogeneous information sources, A workflow management step through the medical diagnosis and treatment process based on the patient registration (412, 500), the workflow management step including providing a user interface (116) that displays a workflow orchestration that spans the diagnosis and treatment process, A trend monitoring (604) step for each step of the workflow management, the trend monitoring (604) step which can provide suggestions in the workflow based on an automated quality review related to the trend, The steps of the aforementioned medical diagnosis and treatment process, including the step of formulating a treatment plan based on user input in the aforementioned workflow (484) and A method for providing it.

9. The medical method according to claim 8, wherein the automated quality review related to the aforementioned trend is based on medical industry quality standards.

10. The one or more programs described above further: Steps of an interoperability engine (112) that provides operational capability between various software applications and data storage systems based on industry standards and programming interfaces for specific applications. The medical method according to claim 8, comprising:

11. The medical method according to claim 8, wherein the treatment plan formulation (484) may further be based on predictive analysis of the data of the system based on the patient registration (412, 500) and workflow management, is stored in a non-relevant database, and Bayesian statistical methods of predictive analysis may be used.

12. The medical method according to claim 8, wherein the artificial intelligence analysis of the information from the heterogeneous sources includes checking the information based on the relevant fields of the patient questionnaire to the extent possible.

13. The medical method according to claim 8, wherein the artificial intelligence analysis of the information from the heterogeneous sources includes searching for relevant clinical trials and comparing them with the patient information to verify that the patient information conforms to the scope of clinical trial guidelines.

14. The one or more programs described above further: A step of pattern recognition (910) among patients based on artificial intelligence analysis of the workflow management of multiple patients, wherein the pattern recognition (910) step provides a suggestion to the user interface (116) on a display based on the recognized pattern. The medical method according to claim 8, comprising:

15. A medical engine embodied in a non-transient, computer-readable storage medium storing one or more programs, wherein the one or more programs are executed by one or more processors (2604) of an electronic device, A patient reception system (412, 500) using a user interface (116) that additionally receives information from heterogeneous information sources, including at least an electronic medical record (EMR) and a medical image storage and transmission system (PACS), and can pre-fill each part of a patient questionnaire based on an artificial intelligence analysis of the information from the heterogeneous information sources, Workflow management through the medical diagnosis and treatment process based on the patient registration (412, 500), comprising providing a user interface (116) that displays the workflow orchestration that spans the diagnosis and treatment process, Trend monitoring (604) for each step of the workflow management, which can provide suggestions in the workflow based on automated quality review related to the trend, The medical diagnosis and treatment process described above, and the development of a treatment plan based on user input in the workflow described above (484) A medical engine that includes instructions causing the device to perform the function of providing a medical device.

16. The one or more programs described above further: Instructions for an interoperability engine (112) that provides operational capability between various software applications and data storage systems based on industry standards and programming interfaces for specific applications. A medical engine according to claim 15, comprising:

17. The medical engine according to claim 15, wherein the treatment plan formulation (484) may further be based on predictive analysis of the data of the system based on the patient registration (412, 500) and workflow management, is stored in a non-relevant database, and can use Bayesian statistical methods for predictive analysis.

18. The medical engine according to claim 15, wherein the artificial intelligence analysis of the information from the heterogeneous sources includes checking the information based on the relevant fields of the patient questionnaire to the extent possible.

19. The medical engine according to claim 15, wherein the artificial intelligence analysis of the information from the heterogeneous sources includes searching for relevant clinical trials and comparing them with the patient (24) information to verify that the patient (24) information conforms to the scope of clinical trial guidelines.

20. The one or more programs described above further: Instructions for pattern recognition (910) between patients based on artificial intelligence analysis of the workflow management of multiple patients, wherein the instructions for pattern recognition (910) provide suggestions to the user interface (116) on a display based on the recognized patterns. A medical engine according to claim 15, comprising:

Images