Systems and methods for smart radiotherapy

Abstract

Radiation therapy systems and methods including an interoperability engine (112), a radiation therapy service, and an artificial intelligence algorithm are presented. The system and method implement patient (24) medical support. A patient may be diagnosed with a medical imaging device and through an intelligent patient reception (412, 500). The interoperability engine (112) may communicate with various data storage devices, information technology systems, and applications provided by a first party or a third party. The system and method may then be used to provide treatment planning and treatment delivery throughout the care procedure.

Description

Technical Field

[0001] The topics disclosed in this article generally relate to systems and approaches for healthcare that utilize hardware and software computer technologies, including oncology solutions and radiation therapy. Background Technology

[0002] Cancer and cancer treatment are significant sectors of the healthcare market. Creating systems and approaches to improve physician care for cancer patients is crucial. One area of ​​patient support is achieved through patient reception, diagnostics, and radiation therapy (RT) treatment programs.

[0003] Radiation therapy treatment plan development typically utilizes medical imaging techniques such as X-rays, computed tomography (CT), and magnetic resonance imaging (MRI). The development of a radiation therapy treatment plan may involve multiple steps, including multidisciplinary team (MDT) discussions, diagnostic imaging, radiation oncology, patient registration, CT simulation, patient scheduling, data management and / or storage, image registration, segmentation, profiling review, planning, plan review and approval, plan quality checks, treatment initiation, and follow-up care.

[0004] Current radiotherapy approaches present a number of challenges, including complex care coordination, excessive manual processes, and incoherent technical systems. The highly complex care decisions, planning, and treatments delivered by various providers can complicate care coordination. Enhanced collaboration can reduce the complexity of care coordination by enabling users to work together on materials in real time, thereby reducing the time spent waiting for other users to complete tasks. Radiotherapy approaches may involve time-consuming profiling, treatment planning, and plan approval, all of which can involve frequent interruptions due to manual execution methods.

[0005] This paper proposes technical systems and methods for improving cross-vendor capabilities, interoperability, AI support, and efficient data exchange. Summary of the Invention

[0006] According to an embodiment, a healthcare system, method, and engine are provided, which may include one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for: patient reception using a user interface, wherein the patient reception additionally receives information from different information sources, including at least electronic medical records (EMR) and picture archiving and communication systems (PACS), and is capable of pre-populating portions of a patient reception form based on artificial intelligence analysis of the information from the different information sources; workflow management based on the patient reception through a medical diagnosis and treatment process, including providing a user interface that displays workflow orchestration across the diagnosis and treatment process; trend monitoring for each step in the workflow management, wherein the trend monitoring can provide recommendations in the workflow based on automated quality reviews related to the trend; and treatment plans based on user input during the workflow of the medical diagnosis and treatment process.

[0007] Furthermore, the AI ​​analysis of this information from the different information sources may include examining the information based on the possible boundaries of relevant fields in the patient reception form. Additionally, the AI ​​analysis of this information from the different information sources may include searching for the patient information and matching it with relevant clinical trials, as well as verifying whether the patient information complies with clinical trial guidelines.

[0008] The healthcare system, method, and engine may further include: automated quality review related to the trend based on healthcare industry quality standards. It may further include an interoperability engine based on industry standards and proprietary programming interfaces to provide interoperability between various software applications and data storage systems. Treatment plans may be further provided based on predictive analytics of the patient reception and workflow management stored in a non-relational database and using Bayesian statistical methods of predictive analytics on the data in the system. The healthcare system, method, and engine may further include pattern recognition between patients based on artificial intelligence analysis of the workflow management for multiple patients, and providing user interface suggestions on a display based on the recognized patterns.

[0009] It should be understood that the above brief description is provided to introduce some concepts further described in the detailed embodiments in a simplified form. This is not intended to identify key or essential features of the claimed subject matter, the scope of which is uniquely defined by the claims following the detailed embodiments. Attached Figure Description

[0010] Many aspects, specific embodiments, objects, and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which the same reference numerals denote the same parts, and wherein:

[0011] Figure 1 A medical environment with intelligent radiotherapy systems and methods, according to an implementation plan, is shown.

[0012] Figure 2A A hardware device for a healthcare environment according to one embodiment is shown.

[0013] Figure 2B A block diagram of a computed tomography hardware and software system according to one embodiment is shown.

[0014] Figure 3 A block diagram of a hardware and software system for radiotherapy, according to an implementation scheme, is shown.

[0015] Figure 4 The healthcare process and block diagram according to the implementation plan are shown.

[0016] Figure 5 A tree-like process for assisting healthcare decision-making, based on an implementation plan, is shown.

[0017] Figure 6 The radiotherapy procedure according to the implementation plan is shown.

[0018] Figure 7 The process for clinical trial matching according to the implementation plan is shown.

[0019] Figure 8 The process for quality inspection in a healthcare environment, according to the implementation plan, is shown.

[0020] Figure 9 The process for relationship and pattern recognition in a healthcare environment, according to the implementation scheme, is illustrated.

[0021] Figure 10 The process for automatic updates of healthcare software according to the implementation scheme is shown.

[0022] Figure 11 A schematic block diagram of a sample computing environment according to an implementation scheme is shown.

[0023] Figure 12 A schematic block diagram of another sample computing environment according to the implementation scheme is shown.

[0024] Figure 13 A schematic block diagram of another sample computing environment according to the implementation scheme is shown.

[0025] Figure 14 A schematic block diagram of another sample computing environment according to the implementation scheme is shown.

[0026] Figure 15 A schematic block diagram of another sample computing environment according to the implementation scheme is shown.

[0027] Figure 16 A schematic block diagram illustrating a suitable operating environment according to the implementation scheme is shown. Detailed Implementation

[0028] In the following detailed description, reference is made to the accompanying drawings, which form a part thereof, and specific examples that can be practiced are shown by way of illustration. These examples are described in sufficient detail to enable those skilled in the art to practice the subject matter, and it should be understood that other examples may be utilized and logical, mechanical, electrical, and other changes may be made without departing from the scope of the subject matter of this disclosure. Therefore, the purpose of providing the following detailed description is to describe exemplary embodiments and not to be construed as limiting the scope of the subject matter described herein. Certain features from different aspects of the following description may be combined to form new aspects of the subject matter discussed below.

[0029] When describing elements of various embodiments of this disclosure, the terms “a,” “an,” “the,” and “the” are intended to refer to one or more of these elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that additional elements may be present in addition to the listed elements.

[0030] The systems and methods described herein provide centralized management of various computer-generated medical data and further provide on-site analysis of the data to determine whether a particular treatment should continue or be adjusted. A further provision provides a medical computing system that automatically records each step of the data analysis process during treatment.

[0031] Figure 1 A medical environment with intelligent radiotherapy systems and methods, according to an implementation plan, is shown. Figure 1 It includes an oncology healthcare system 100, a medical imaging system 102, an information technology (IT) healthcare 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.

[0032] An oncology healthcare system 100 assists patients in diagnosing and treating medical problems. For example, an oncology healthcare system 100 could be a radiotherapy department. Diagnosis of the medical problem can be accomplished using 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 acquired from the medical imaging system 102 and stored in existing IT systems / data storage devices (including the IT healthcare system 102). Computing hardware and software, such as an RT system 108 and available oncology applications 106, can access information from these systems to aid in decision-making, visualization of medical problems, treatment decisions, etc. Interactions across workflows can be accomplished via a UI 116, and treatment can be directed from the RT system 108 to a treatment delivery system 110 (such as a radiotherapy system). The patient can then return for follow-up and further treatment, as indicated by data flow 118.

[0033] IT healthcare system 104 may include at least one of the following: electronic medical record (EMR), image archiving and communication system (PACS), oncology information system (OIS), radiology information system (RIS), and treatment planning system (TPS). Therefore, TPS applications can be such as... Figure 1 The oncology application shown could also be an existing IT system / data storage device, 104. The IT healthcare system 104 can communicate with the RT system 108. The RT system 108 may include core features and / or services, as well as connectors for applications accessing the host system.

[0034] The RT system 108 can interact with first-party and / or third-party oncology applications 106. These applications may be marketed applications that assist in tumor profiling, quality assurance, oncology diagnostics, radiotherapy delivery, etc. An interoperability engine 112 connects to 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 another. The RT system 108 can interface with a large number of technical standards and application programming interfaces in the industry through the interoperability engine 112. The RT system 108 can access the oncology applications 106 via wired and / or wireless connections. Applications 106 may be deep learning and / or AI applications hosted internally and / or by third parties, such as OAR profiling-MR, brain tumor profiling MR, synthetic CT (MR only), and / or case exchange and MDT.

[0035] The RT system 108 may include numerous hardware and software functionalities, as discussed throughout this article, and not just those related to... Figure 1 Associated with, for example, these functionalities interact with and control scanning of the medical imaging system 102 and the treatment delivery system 110. Technologies utilizing the RT system 108 may include an interoperability engine 112, RT services 114, and a UI 116. As described herein, the functionality of the RT system 108 includes managing patient activity and data in patient radiotherapy treatment course records, and operating as a complete workflow management and integration layer for the radiotherapy department in which the RT system 108 is integrated. In some examples, the RT system 108 may use a web-based single-page application to provide users with access to patient information from multiple sources (e.g., diagnostic imaging systems, patient reception forms, etc.) in a single location. Workflow tasks may be managed by the RT system 108, including stopping and starting workflow applications, displaying the execution status of applications, displaying the task owner assigned to the application, and the remaining timeout portion of the task. For example, the RT system 108 may include containerized microservices that can run on any hardware system, including data centers, public edge appliances, and cloud implementations.

[0036] Workflow task management can be event-based, allowing the interoperability engine 112 to send notifications to, for example, a user interface 116 when data is received, triggering a custom workflow generated by an interoperability system that can operate based on different data received. Therefore, the startup of the 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 provides data storage management, including records of location, status, and operation date. Data stored by the RT system 108 can be used to trigger the startup of the workflow application.

[0037] Using workflow building blocks and information input into the RT system 108, the system can define patient-related workflows and enable these workflows to be adapted at any time during treatment based on versioned workflow definitions / templates. Workflow adaptation allows for adaptive radiotherapy, for example, by the user and / or an interoperability engine or relevant artificial intelligence based on updated patient, treatment, and / or diagnostic information. As part of deploying the workflow, the RT system 108 can use DICOM (e.g., MPPS / UPS) or any other protocol for automating workflow operations (e.g., without user input) to trigger the launch of at least one external application. MPPS stands for Modal Execution Process Steps. DICOM Modal Execution Process Steps (MPPS) close the loop between the information system, PACS, and modality. The modality provides information about the studies actually performed, the number of images scanned, and the status of the examination. As further noted herein, the RT system may include one or more artificial intelligence (AI) modules. These can be hardware, firmware, or software. AI modules may include dedicated AI, machine learning, generative AI, large language models (LLM), neural networks, or other forms of artificial intelligence that receive data and provide relevant and useful outputs.

[0038] The interoperability engine 112 of the RT system 108 (which may include data modeling and workflow orchestration modules) can interact with existing IT systems and / or data storage devices, such as OIS (Oncology Information Service), PACS (Picture Archiving and Communication System), and / or EMS / RIS (Emergency Medical Services, Radiology Information Service), as well as existing services including TPS (Treatment Planning System), profiling, QA (Quality Assurance), and / or delivery, to exchange patient information. The interoperability engine 112 is a key engine in the RT system 108, providing seamless interoperability with existing IT healthcare systems 104, such as OIS, TPS, EMR, Radiology Information System (RIS), and PACS. This interoperability engine is built on standards such as DICOM-RT and Integrated Healthcare Enterprise-Radiation Oncology (IHE-RO) to enable 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 first-party oncology applications 106.

[0039] Interoperability Engine 112 utilizes mechanisms and standards such as DICOM (Digital Imaging and Communications in Medicine), DICOM RT, HL7 (Health Level 7), and FHIR (Fast Healthcare Interoperability Resource). These mechanisms and standards support various data protocols such as analog scanning, RIS / PACS, EMR (Electronic Medical Records), and OIS (Oncology Information System), and further support routing between different data sources based on a set of rules for implementing the functionality of an information exchange center. These mechanisms and standards can be used to connect various data protocols (such as any EMR and PACS system) to Interoperability Engine 112 in a vendor-agnostic manner (e.g., using Integrated Healthcare Enterprise-Radiation Oncology (IHE-RO), DICOM RT Generation 2, and other standard data protocols). For example, PACS can host application entity (AE) headers and port numbers, and APIs (Application Programming Interfaces) can be developed to connect to various PACS systems in accordance with DICOM standards. Interoperability Engine 112 can leverage a backend abstraction layer to connect to external systems in a standard manner. The set of rules used to implement the functionality of the information exchange center is a clinical task for routing between systems (e.g., between interoperable systems and systems hosting multiple data protocols). The interoperability engine 112 provides modular workflow tasks to create different rules based on user requests. Information can be exchanged via DICOM and other protocols such as SOAP (Simple Object Access Protocol) and / or REST (Representative State Transfer), which, for example, enables holistic review using integrated data from OIS, TPS (Treatment Planning System), and RIS / PACS. Information can be exchanged following standard protocols such as DICOM-MPPS, DICOM-UPS, ODBC (Open Database Connectivity, e.g., for connecting to OIS), and second-generation DICOM-RT for connecting to TPS.

[0040] The workflow orchestration module is intelligently optimized to eliminate the frustration of repetitive, multi-screen data searches. It orchestrates easy access to all applications. Its dynamic data aggregation may be invisible to the user. All clinically relevant data is automatically collected, analyzed, sorted, and displayed, replacing manual steps that could consume significant user time and effort.

[0041] The services of RT system 108 may include first-party and / or third-party services, including RT services 114 for case exchange, planning guidance, tumor profiling, staff scheduling, patient reception, organ profiling-MR, and / or MR-only workflows (e.g., synthetic CT). Services 114 of RT system 108 may be hosted and / or provided internally and / or by third parties. These services enable the clinical and operational outcomes of RT system 108. These services provide case exchange, patient reception, planning guidance, staff scheduling, organ profiling-MR, tumor profiling, and MR-only workflows.

[0042] The Patient Reception Module and the Planning Instruction Module are shown in RT Service 114. These modules allow physicians to capture patient information to initiate patient care pathways. Patient demographics, medical history, and alerts from the Oncology Information System (OIS) can be easily retrieved from a single screen via UI 116. The physician's intent regarding the patient's treatment plan is clearly displayed for the team's reference. The Planning Instruction is designed to describe the physician's intent regarding the goals of the patient's treatment plan. The Planning Instruction can also be referred to as the Planning Intent. The Patient Reception Module records and provides the corresponding patient's care team with key information about the patient and their care plan, enabling the care team to efficiently receive and manage the patient. Typically, patient reception and management information is manually recorded during MDT (Multidisciplinary Oncology Panel) sessions (e.g., on paper) and manually entered into the Oncology Information System (OIS). The DICOM worklist adapter provides functionality to enable patient demographics and imaging scanners to retrieve details of patients scheduled for scanning from the HIS / EMR / OIS system within the radiation oncology environment. Furthermore, the Patient Reception Module allows physicians to capture patient information to initiate patient care pathways. It can be designed to retrieve patient demographics, medical history, and alerts from oncology information systems.

[0043] The Planning and Instruction module manages the on-call schedules for staff within the department. The algorithms and processes in this module help calculate role-based on-call schedules in medium to large-sized medical departments.

[0044] The staff scheduling module in RT service 114 can be used to manage and schedule all staff in medical departments (such as radiation oncology) based on factors such as staff availability. The planning instruction module further enables radiation oncologists to digitally add detailed prescriptions to planning teams, which may include medical dosimeters and / or medical physicists. RT system 108 can be communicatively coupled to components of oncology healthcare system 100 via one or more connectors.

[0045] The RT system 108 further includes a user interface (UI) 116, which may be a single UI across workflows. The RT system's user interface 116 provides a single UI across RT care pathways, thereby minimizing touchpoints with existing RT IT systems. This UI provides a workflow view with user-enabled configurability and action management. As described herein, the RT system 108 can receive, process, and output information related to patients, workflows, and at least one resource to automatically guide and execute steps of diagnosis, simulation, treatment delivery, and follow-up.

[0046] Treatment delivery system 110 provides medical treatment to patients. Medical and healthcare decision-makers (such as clinicians, physicians, physician assistants, nurses, etc.) use RT system 108 to make decisions and assign treatment plans. Healthcare professionals work in conjunction with treatment delivery hardware and software system 110 to provide medical treatment tailored to each patient. In implementations, this may include medical linear accelerators for external beam radiotherapy for cancer patients. These accelerators deliver high-energy X-rays or electrons to the patient's malignant tumor. Additional machines may include a combination of a CT scanner and an external beam radiotherapy machine. Image-guided radiotherapy also helps track cancer and preserve normal tissue. Other forms of oncology radiotherapy may be intensity-modulated radiotherapy and volume-modulated radiotherapy. Medical devices in these spaces may be examples of treatment delivery system 110.

[0047] According to the implementation scheme, data flow 118 illustrates how data can flow. In some examples, the diagnosis-to-treatment workflow is a cyclical operation. After treatment, the results of the medical treatment can be fed back to RT system 108, medical imaging equipment 102, healthcare IT system 104, and available applications 106. Furthermore, the resulting data is fed into an artificial intelligence module within the system for continuous learning.

[0048] RT System 108 uses a modular approach to facilitate the exchange of functional modules to support the diverse needs of the radiotherapy department in which the system is integrated. In some examples, RT System 108 can support the needs of larger environments, such as hospitals or other healthcare facilities where the radiotherapy department is located, to enhance collaboration between the radiotherapy department and other departments. When patient data (e.g., via the patient reception module) becomes available to RT System 108, CT / MR simulation scans can be scheduled by importing patient demographic data, and simulation scan protocols can be generated by importing scan command text data provided by the patient reception module. The modular workflow can be further defined based on user input.

[0049] The RT system 108 can use a radiation oncology domain-specific language (DSL) that provides flexible workflow building blocks to create versioned workflow definitions (e.g., templates). Workflow building blocks can contain business logic and interoperability definitions. For example, diagnostic imaging can be performed on a patient, and a multidisciplinary team (MDT) discussion about the patient can be conducted. Information from diagnostic imaging and the MDT, along with patient demographics and medical alert history, can be transferred from the patient reception module and used to schedule patient scans. The transferred information can be further used to perform image contouring after a simulated scan. The contoured image is transferred to a treatment planning system that allows users to view the contoured image. An interoperability engine 112, working with the RT service 114, uses planning instructions to create treatment plans. After quality review and approval, the treatment plan is transferred to the treatment delivery system 110.

[0050] The RT system 108 further includes a workflow orchestration module that enables the nursing team to orchestrate treatment planning workflows. This patient-centered, formalized application manages and monitors patient treatment processes. Therefore, enabling the RT system 108 to automate workflows and minimize manual operations within the application improves efficiency and enhances safety. About Figure 4 Further details about the workflow manager are described.

[0051] like Figure 1 As shown, the RT system 108 utilizes connector technology to connect to various components, such as EMR, imaging equipment, imaging and treatment planning software, scheduling and appointment management tools, and quality assurance and monitoring systems, for the electronic exchange of healthcare information, including message sending and receiving, documents, and clinical data. The RT system 108 can also incorporate remote monitoring and telemedicine technologies to enable remote consultation and follow-up care.

[0052] The RT system 108, with its API access to supported third-party applications, can prepare and set the necessary parameters for an application before it is launched. This includes available oncology applications 106. By delivering this information in advance, time and effort are saved, as users do not need to manually configure the application each time it is launched. Instead, the workflow orchestration module of the RT system 108 provides a set of predefined parameters that applications can automatically load and use. This helps streamline healthcare workflows and make them more efficient. Furthermore, the RT system 108 can programmatically launch and access the functionality of each application using APIs, enabling seamless integration with other applications in the workflow. The RT system 108 also supports the use of custom scripts to automate repetitive tasks such as file transfers or data transformations, further simplifying the workflow process.

[0053] The RT system 108 can seamlessly integrate applications with defined and supported standard interfaces to perform at least one given task in a clinical workflow. This also allows for the easy substitution of a given application with another application without affecting the overall workflow. For example, a user might prefer to use a first application rather than a second application integrated throughout the workflow. The first application can then substitute for the second application throughout the workflow without disrupting it.

[0054] Furthermore, RT system 108 can automate workflow execution and can potentially configure triggering conditions for orchestrating the following steps in each case. RT system 108 can provide users with the option to insert review points that can intentionally halt workflow execution, for example, to await user interaction with the workflow. At any point during workflow execution, RT system 108 provides users with intermediate results of the review process, initial data, and accepts user input to continue, stop, or rerun the workflow execution. Users can create flexible workflows with different instances and / or vendors for a given workflow step. For example, users can select the desired application for a given step of the workflow from an application catalog. RT system 108 provides a framework and interface through interoperability engine 112 to output configurations, orchestrations, and / or protocols from one user to another for storage and / or display, which can provide opportunities for collaboration between users (e.g., different teams within or outside the healthcare sector). The RT system 108 can provide tools for data and performance analysis, as well as resources for device optimization of workflows and resources for re-adapting workflows for compatible devices (e.g., when updated devices and / or new devices are introduced into the workflow).

[0055] Figure 2A A hardware device for a healthcare environment according to one embodiment is shown. Figure 2B A block diagram of a computed tomography hardware and software system according to one embodiment is shown. Such a machine can be used as imaging device 102.

[0056] Figure 2A and Figure 2BA computed tomography (CT) imaging system 10 including a gantry 12 is shown. The gantry 12 has a rotating member 13. An X-ray source 14 projects an X-ray beam 16 through a patient anterior collimator 15 toward a detector assembly 18 on the opposite side of the rotating member 13. The X-ray source 14 may also be referred to as an X-ray tube or an X-ray generating assembly. The X-ray source 14 is an emission assembly. The rotating member 13 can be attached to a fixed 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, and may include a patient posterior collimator. The plurality of detectors 20 sense the projected X-rays passing through the subject 24, and the DAS 22 converts this data into a digital signal for subsequent processing. Each detector 20 generates an analog or digital electrical signal representing the intensity of the irradiated X-ray beam and thus the intensity of the attenuated beam as it passes through the subject 24. During a scan to acquire X-ray projection data, the rotating member 13 and the assemblies mounted thereon can rotate about a center of rotation.

[0057] The rotation of the rotating component 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 and timing signals to the x-ray source 14, and a gantry motor controller 32 that controls the rotational speed and positioning of the rotating component 13. The image reconstructor 34 receives sampled and digitized x-ray data from the DAS 22 and performs high-speed image reconstruction. The reconstructed image is output to a computer 36, which stores the image in a computer storage device 38.

[0058] Computer 36 also receives commands and scan parameters from the operator via operator console 40, which has some form of operator interface, such as a keyboard, mouse, touch-sensitive controller, voice-activated controller, or any other suitable input device. Display 42 allows the operator to view reconstructed images and other data from computer 36. Computer 36 uses commands and parameters provided by the operator to provide control signals and information to DAS 22, X-ray controller 28, and rack motor controller 32. Additionally, computer 36 operates table motor controller 44, which controls the electric table 46 to position the patient 24 and rack 12. Specifically, table 46 allows the patient 24 to move wholly or partially through rack opening 48 or entrance. Coordinate system 50 defines the patient 24 along the patient or Z-axis 52 as it moves in and out of opening 48, the detector assembly 18 along the rack circumference or X-axis 54 as it passes, and the Y-axis 56 along the direction from the focal point of X-ray tube 14 to detector assembly 18.

[0059] Figure 3 A block diagram of a hardware and software system for radiotherapy, according to an implementation scheme, is shown. Figure 3 It includes a medical environment 300, a display device 302, medical professionals 304, an RT system 312, a first-party medical application 314, a third-party medical application 316, treatment delivery software 310, an oncology information system 308, and a patient 306.

[0060] RT system 312 provides information such as Figure 1 The features and functionality of the described RT system 108 are described. A user interface can be displayed on a display device 302 to allow medical professionals 304 to interact with the software and hardware of the RT system 312. The RT system 312 includes interoperability and software for providing imaging support, tumor profiling, treatment (Tx) planning, patient records and review of treatment plans, and quality assurance (QA). Through an interoperability engine, the RT system 312 can successfully interact with first-party medical applications 314 and third-party applications 316. As discussed throughout this document, such interaction can be accomplished through industry standards, application programming interfaces, and / or specific technologies. First-party applications 314 can be those from companies providing various diagnoses or treatments for medical problems, such as CT, MR, radiotherapy, X-ray, and other medical software and hardware. Third-party applications 316 are those from third-party companies providing various diagnoses or treatments for medical problems, such as CT, MR, radiotherapy, X-ray, and other medical software and hardware. The ability of the RT system 312 to successfully work with various first-party and third-party applications is valuable to medical professionals 304. Once the medical professional 304 interacts with the RT system 312 to finalize the treatment plan, the treatment delivery software 310 works in conjunction with the oncology information system 308 to deliver medical treatment to the patient 306.

[0061] Figure 4 A healthcare process and block diagram according to an implementation scheme are shown. Flowchart 400 is shown, illustrating the workflow of the RT system 108 of the oncology healthcare system 100. In the implementation scheme, the workflow manager 410 of the RT system includes a graphical user interface (UI), data management, and storage devices.

[0062] Flowchart 400 illustrates the various steps in the medical care process and how the radiotherapy system can support the patient. Prior data related to the patient and their medical history can be entered into the RT workflow manager 410 from OIS 454, EMR 452, RIS / PACS 450, diagnostic imaging 402 (e.g., from medical imaging equipment), data from image registration 420, and multidisciplinary team discussions 404. When patient reception 412 occurs, the patient begins or restarts their medical journey, and they are registered in the patient register 414. Their journey may then proceed through multiple steps as shown in flowchart 400, depending on various factors regarding the patient and their medical condition. These steps include tumor profiling review 492, treatment planning 484, plan review 486, plan quality review 488 (QA - Quality Assurance, QC - Quality Control), treatment initiation 490, and patient follow-up 492. Modules within the system help automate these steps, such as the planning instruction module 464 and intelligent plan evaluation 468. In addition, depending on the patient and medical issues, additional steps can be performed, such as CT / MR / PETCT simulation scan 416, CT / MR / PETCT / 4DCT / 4DMR contouring 418 (which can use CTV / GTV / ROI automatic contouring 460 and / or OAR automatic contouring 462), image registration 420, CT / MR SIM guidance 432, patient scheduling using patient schedules 434, equipment scheduling using equipment schedules 436, staff scheduling using staff schedules 438, intelligent CT / MR protocol selection 440, protocol review 446, contrast agent injection 444, and AI-based registration and fusion 472.

[0063] The steps shown in flowchart 400 and workflow manager 410 can utilize AI model self-learning and training platform 470. As discussed below with reference to the processes and methods in the accompanying figures, the RT system utilizes machine learning and artificial intelligence to provide many innovative assistance to the patient's journey. Furthermore, such AI models can be continuously trained using additional input regarding the patient and medical issues.

[0064] Workflow Manager 410 is Figure 1 An example of the workflow manager and / or interoperability engine of the RT system 108. Figure 4In the example, data protocols include CT / MR / PETCT simulation scan 416 (e.g., using MWL and / or MPPS), CT / MR / PETCT / 4DCT / 4DMR contour plotting 418, RIS / PAC 450, EMR 452, and OIS 454. The workflow manager 410 supports information exchange via DICOM and other protocols, enabling holistic review using integrated data from: OIS 454; Treatment Planning Systems (TPS), including a planning system 484, a planning review system 486, and a planning quality assessment / quality control system 488; EMR 452; and RIS / PACS 450. Text data is transferred between functional modules (e.g., indicated by blue boxes), and DICOM and DICOM-RT data are transferred between workflow steps (e.g., indicated by brown boxes).

[0065] During a multidisciplinary team discussion 404, patient images and documents are exchanged among team members. Typically, patient information may be physically recorded (e.g., on paper) during a multidisciplinary team meeting (MDT) (e.g., multidisciplinary team discussion 404) and manually entered into an oncology information system (OIS) 454. As described herein, a workflow manager 410 securely manages the distribution of patient images via an image interface (e.g., DICOM) and distributes documents via a document interface (e.g., text-based communication) (such as HL7). For example, results and / or conclusions may be distributed among healthcare providers across geographical distances, network boundaries, and / or through professional social networks.

[0066] Patients confirmed to receive radiotherapy treatment register with the radiotherapy department. This may include providing patient information to clinical staff, such as medical history, demographic information, and aggregated information about the patient's condition. Workflow manager 410 guides clinical staff to complete patient reception 412 according to predefined workflows. For example, some patient information may be available for patient reception 412 in the first workflow but not in the second. Information exchange and automatic workflow filling using radiotherapy imaging equipment from different manufacturers are achieved through patient reception 412 via DICOM worklist adapter 430 provided by workflow manager 410, including, for example, patient demographics, scan schedules, and specific scan notes and requirements. Patient reception 412 provides the patient's care team with information about the patient and the patient's care plan, enabling the care team to efficiently receive and manage the patient.

[0067] The DICOM worklist adapter 430 can be configured with multiple data dictionaries publicly released and / or licensed by different manufacturers. For example, the DICOM worklist adapter 430 is configured as a converter that loads a manufacturer's data dictionary with common rules, adapts the data dictionary to match the data language, and translates patient reception information into the language used by the scanning equipment. In this way, the DICOM worklist adapter 430 can convert non-standardized updated information into a standardized format. Typically, DICOM worklist adapters and demographic data are primarily used in radiology. In radiation oncology departments, the Oncology Information System (OIS) manages and stores specific oncology demographic information. Interoperability systems also include Modal Worklist (MWL) services. Transferring patient demographic data between MWL services provided by the OIS can be challenging because different vendors may use different DICOM tags in the OIS, which may result in data in the OIS not being fully recognized by CT or MR systems. The DICOM worklist adapter 430 of the interoperability system disclosed herein allows CT and / or MR analog scanners to resolve specific oncology information supported by the corresponding analog scanner and transmitted via the DICOM modal worklist adapter 430.

[0068] Workflow Manager 410 can seamlessly connect DICOM tag data via DICOM Worklist Adapter 430 by loading multiple data dictionaries and using the data matching algorithms contained therein, providing interoperability for cross-platform and cross-manufacturer data communication. For example, in a conventional system, patient data registered in OIS system 454 may not be fully transferable to an analog CT scanner, as further described herein. Users (e.g., care providers) may manually enter patient demographic information, and append user-cross-checked information to ensure the accuracy of patient data (e.g., information about the patient's condition) entered during patient registration 414. This process can be time-consuming and laborious, thus a method for automatically filling out patient reception forms using patient information is desired for fast and accurate information delivery. Using DICOM Worklist Adapter 430 with patient reception 412 can significantly reduce the current excessive manual processes and lower the likelihood of manual errors.

[0069] Using patient reception 412, CT / MR simulation guidance module 416 can be used to generate patient simulation scan commands. The simulation scan can follow standard operating procedures for conventional scans such as CT, MR, and PET-CT scans. In some examples, the simulation scan can be a computer-simulated scan, the output of which can be a predicted image generated by the scan based on input parameters. The operation of each module of the simulation scan is the same as that of a conventional module, and the interoperability system described herein enables coordination between modules. Compared to conventional simulation scans, simulation scans guided by patient simulation scan commands can include a series of decentralized factors, including patient registration, patient appointment, scan protocol creation, equipment preparation, operator preparation, etc., thereby enabling independent management of the process. The ability for individual modules of the interoperability system to operate dynamically through a coordination mechanism allows for the generation of new patient appointment lists when patient appointments change, as described with respect to patient scheduler 434.

[0070] Data preparation for the simulated scan 416 is managed through a workflow module to automatically export the simulated scan modality. Generation of patient simulated scan commands may include using the patient reception 412 module to collect relevant patient demographic and care information. The interoperability and workflow manager system can then initiate the workflow within the radiation oncology department (an example department where the interoperability system is integrated). Enterprise-wide information systems (such as one or more EMR systems 452) can be used to collect radiation oncology patient demographics, disease-specific information, and simulated scan command information, such as scan area, contrast agent, etc. The interoperability and workflow manager system can output data tables via the DICOM worklist adapter 430 in an electronic format (e.g., a standardized format) compatible with the simulated scan system (e.g., CT, MR, PET / CT, PET / MR). Patient simulated scan commands may instruct patients who have already requested and / or been recommended for simulated scans by a healthcare provider and / or based on patient information from the patient reception 412.

[0071] Workflow Manager 410 can automatically generate recommended scanning protocols for analog imaging devices (e.g., CT, MR, PET CT, etc.) via Smart Scan Protocol Module 440. Smart Scan Protocol Module 440 can obtain patient demographic information (e.g., weight, height, age, gender, etc.) from Patient Reception 412 and combine it with scanning protocol imaging device guidelines that conform to industry standards and / or user-defined guidelines to generate protocols.

[0072] Workflow manager 410 further includes a protocol review and approval body 1205 for reviewing the scan protocols generated by intelligent scan protocol module 440 to determine whether an appropriate scan protocol / sequence has been selected. Intelligent scan protocol module 440 is configured with an algorithm that generates matching parameters for respiratory gating device 442 and contrast agent injector 444 based on scan commands. For example, a machine learning-based model is used as the algorithm driving the automatic generation of scan protocols. Selected protocol data stored in the interoperability system can be obtained from previous scans. The selected protocol data is used as the basis for future process recommendations and scan protocol planning. Each selected protocol includes a RIS process name (e.g., defined as 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. Recommended scan protocols can be executed using at least one of two methods: linear weighted moving average (LWMA) statistical techniques or machine learning techniques such as Naive Bayes classifiers. The operating parameters of each of the respiratory gating device 442 and the contrast agent injector 444 are transmitted to the corresponding device by the workflow manager 410.

[0073] After the protocol is generated, a management process and user interface can be used to display the generated protocol. During protocol review 446, the user can provide user input, which the interoperability system can use to modify the steps of the generated protocol. For example, the generated protocol and previous and / or alternative generated protocols can be output for display, allowing more than one protocol to be displayed at a time for comparison. The display of the protocol may include the display of an embedded electronic scanning guide. During protocol review 446, an interface can be provided to allow the user to approve or modify the generated protocol. After receiving user input indicating protocol approval, the interoperability system executes the generated protocol by initiating the next step in the workflow.

[0074] The patient scheduler module 434 uses AI algorithms to view and predict the probability of patient no-shows and / or delays over a period of time, such as seven days. Based on the predicted probabilities, the patient scheduler module 434 can automatically generate updated patient schedules based on patient priority and availability in the event of no-shows or delays. Therefore, as part of the workflow manager 410, the patient scheduler module 434 can automatically provide patients with guidance on scan and treatment preparation based on simulated scan commands and subsequent radiotherapy treatment plans. For example, the workflow manager 410 can generate calendar notifications to be sent to patients, including the scan time, date, location, and requested preparations. Patient response feedback, such as whether the patient can undergo a scan, can be provided to the workflow manager 410 via the patient scheduler module 434.

[0075] The workflow manager 410 is further configured with an equipment scheduler module 436, which can automatically coordinate the equipment schedules of a department (e.g., a radiotherapy department including at least one scanning device). The equipment scheduler module 436 can coordinate the scheduling of equipment within the department (including at least one simulation device, TPS, and treatment delivery equipment), such as linear accelerator proton therapy (high-energy radiation that can be used to treat cancer). The equipment scheduler module 436 can further automatically update the equipment schedule based on equipment status and priority as patient schedules change to maintain consistency with the latest patient schedules.

[0076] The staff scheduler module 438 of the workflow manager 410 can automatically manage and schedule all staff in the medical department based on factors such as staff availability, upcoming processes, and geographical details. Therefore, the workflow manager 410 can use the patient scheduler module 434, equipment scheduler module 436, and staff scheduler module 438 to automatically identify, plan, and schedule patient scans. Coordination of patients, staff, and equipment can be adaptively implemented by the workflow manager 410. The time, date, and location of scans can be notified to relevant personnel, for example, via text messages and / or email. Therefore, the workflow manager 410 provides an effective method to ensure and improve operational efficiency between departments.

[0077] After completing the steps of receiving the patient, identifying scan parameters, and scheduling the scan, the workflow manager 410 automatically coordinates a CT / MR / PET_CT simulation scan 416. As described above, the simulation scan includes corresponding patient information, scan protocol, patient schedule, equipment schedule, and staff schedule. In the implementation, the simulation scan 416 is performed, and after its completion, the workflow manager 410 obtains information about the completion of the simulation scan via DICOM MPPS.

[0078] Patient image data generated from simulated scans is automatically transferred to the contour drawing application 418. The workflow manager 410 can manually control the start and stop of the contour drawing process performed by the contour drawing application 418, or can automatically trigger the start of the contour drawing process by transferring patient image data to the contour drawing application 418. For example, the workflow engine of the workflow manager 410 uses the availability of patient image data to automatically trigger OAR automatic contour drawing 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 allow users to train contour drawing AI models and update existing models to continuously improve results. Data exported from the contour drawing application 418 is temporarily stored in the database of the workflow manager 410 and routed to the image registration process 420 to automatically initiate image fusion operation 472. For example, if the patient undergoes multimodal simulated scans (such as CT, MR, and PET_CT scans), image fusion is performed between the outputs of different contour drawings. The availability of image data can trigger the generation of a notification and display it on the user interface. Based on this notification, the user can interact with the user interface to provide user input. Receiving user input can indicate whether to start or stop the automatic contour drawing provided by the AI ​​algorithm.

[0079] Following image registration process 420, patient images may undergo contour drawing review 482, performed by a user and / or automated system. Based on contour drawing review 482, a TPS (Transmission Treatment System) is performed, including planning 484, planning review 486, and planning QA / QC 488. Workflow manager 410 includes a digital planning instruction application 464 as part of planning 484, which intelligently assists users (e.g., radiation oncologists, medical dosimeters, and / or medical physicists) in developing radiotherapy plans and generating detailed digital prescriptions to replace current paper-based radiotherapy plans. For example, planning instructions may include information about the radiotherapy plan goals of the physician or other healthcare provider, which can be used to improve the efficiency and communication of the treatment planning process by enabling standardized communication. Input to planning instruction application 464 may be a preset template of patient-specific planning goals based on a plan selected and manually completed by a healthcare provider. Planning information may be output to be displayed to the user and further saved to the database of the interoperability system. The plan can be reviewed via Plan Review 486, which includes an intelligent plan evaluation application 468 that uses AI technology to pre-assess the treatment plan and suggest modifications. Simultaneously, the AI-based evaluation module can utilize a self-training platform provided by Workflow Manager 410, allowing users to train the plan evaluation AI model and update existing models for better results. The quality assurance and quality control of the treatment plan are checked at Plan QA / QC 488.

[0080] Once the treatment plan has been approved through the treatment planning step, the workflow manager 410 provides the radiotherapy department with information for initiating treatment 490. This information includes, for example, the generated and approved treatment plan, registered / fused / contouring patient images, patient demographics, etc. Following treatment, patient follow-up 492 can be scheduled to discuss treatment outcomes and / or determine future treatment plans. Changes to the treatment plan and outcome data can be entered into the workflow manager 410 to aid in tracking patient progress through the treatment plan.

[0081] In this way, the RT system's workflow manager provides automation, allowing users to configure workflows and automatically orchestrate data integration, task execution, and result deployment, while connecting to multi-vendor external systems. Third-party applications can be controlled and launched by calling their interfaces for AI / DL applications within a standard interface. The system offers a robust and extensive catalog of radiation oncology applications and provides seamless integration of any application during a unique loading process. The system provides a single user interface for use with existing multi-vendor RT IT systems. The system can store reference-only data, thereby reducing data overhead. The system further reduces the cognitive burden on users caused by manipulating multiple software systems.

[0082] Figure 5 This illustrates a tree-like process for assisting healthcare decision-making, based on an implementation plan. This can also be referred to as a multi-level model. Figure 5 This includes the RT system patient reception 500, general block 502, SIM command block 504, and plan instruction block 506.

[0083] In one implementation, as illustrated in the Patient Reception 500 example, the most likely treatment plan for an individual can be determined using a non-relational database and Bayesian statistical methods. Compared to relational databases, non-relational databases decouple data from the application and store data in a tree structure. This enables flexible schemes where Bayesian statistics are used to compute the correct data path. Bayesian statistics utilize observed and unobserved parameters in a statistical model to establish probability distributions. Such Bayesian networks are probabilistic graphical models that transmit data via methods such as... Figure 5 Examples of this include directed acyclic graphs (DAGs), which represent sets of variables and their conditional dependencies. Bayes' theorem describes the conditional probability of an event based on data and prior information or beliefs about the event (such as a patient's medical treatment) or conditions associated with the event. Figure 5The dashed circles and lines in the diagram indicate an initial probability flow through a tree structure based on factors such as patient details, diagnosis, and setup. At the imaging layer, Bayesian statistics branch the prediction path for both the dashed contour (most likely line) and dotted contour paths. Furthermore, at the contour drawing level, the predicted path branches again as more information about the tumor is learned through contour drawing, thus adding both dashed and dotted contours. Figure 5 As illustrated in the example, the RT system predicts an 83% probability treatment plan for dashed contours, a 10% probability for both dashed and dotted contours, and a 7% probability for dotted contours. Therefore, non-relational data structures, together with Bayesian models, can help predict patient care pathways. Once physicians have filled out a form including the patient's variable path, the data can be used to predict future patient pathways. Such non-relational data structures allow for the use of models other than Bayesian network models, which are examples of exemplary implementations.

[0084] Patient reception is a critical area of ​​medicine requiring technological improvement. AI can help automate patient reception forms, such as those for medical history, current medications, and allergies. This saves time and reduces human error. AI-assisted intelligent patient reception forms can be used to initiate medical workflows for radiation therapy treatment. The form collects the patient's medical history, current medications, allergies, and other essential information needed to determine the optimal treatment course. The form can be automated by the RT system and reviewed by radiation oncologists and the medical team. When automated, AI analysis of information from various sources (EMR, PACS, oncology applications, etc.) includes examining the information based on the possible boundaries of relevant fields in the patient reception form.

[0085] As part of patient reception, the systems and methods described in this paper can store templates and allow for the storage and searching of a user's preferred template list. AI can provide an assistive mode when using patient reception. This mode specifies that when a user answers a question, the form suggests answers based on the most likely response. Users can validate or change values ​​as needed. Furthermore, in an additional mode, when a user answers a question, the form suggests key questions that may lead to automatic form completion. In some cases, OIS results provide sufficient information to complete a diagnosis. This functionality allows for the automation or automatic construction of workflows and forms, thus providing users with accuracy and efficiency. 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 systems introduce workflow efficiency and reduce human error by incorporating a likelihood function that includes predictive workflows.

[0086] Figure 6 The radiotherapy procedure according to the implementation plan is shown. Figure 6This includes an AI-enabled RT system 600, a workflow manager 602, a trend monitoring system 604, an AI algorithm 606, suggested corrections 608, a decision-making step 610, an AI QA check 612, and a quality decision-making step 614.

[0087] The AI-enabled RT system 600 promotes workflow data integrity and quality assurance. The workflow manager 602 of the RT system 600 includes many steps already discussed herein. It allows for patient reception, acquisition of imaging scans, image segmentation, contour plotting, and medical image analysis to understand medical problems in regions of interest, treatment planning, treatment scheduling, and treatment delivery. Throughout the process, the RT system 600 includes trend monitoring 604. This monitors trends at each step of the process for AI learning. This includes software trends, such as which parts of the software are clicked most frequently, which options are selected most often, which parts of the workflow are skipped most often by users, and similar trends. The software can adopt these trends and updates to improve the RT system 600 and workflow manager 602. Additional trends in trend monitoring 604 are medical trends. These medical trends include those related to patient reception, imaging protocol selection, diagnosis, radiology report construction, and treatment planning and delivery.

[0088] Trend monitoring 604 then feeds these trends and learned information into AI algorithm 606. AI algorithm 606 makes suggested improvements and corrections 606 to software, medical diagnoses, treatment plans, and other trends mentioned throughout this document. In some cases, acceptance in step 610 can be done by the system, for example, comparing the change to medical guidelines for the disease and accepting the change if it falls within those guidelines. In other cases, acceptance in step 610 can be done by the user, for example, when changing the dosage of radiotherapy in a treatment plan, the physician can review and appropriately assess the change. The change is then quality-checked based on software standards, usability standards, medical standards, etc. If the change meets the quality standards, it can be introduced from AIQA check 612 into workflow manager 602. Throughout the process, the AI ​​model and algorithm can be continuously updated based on trends, feedback, user decisions, and data related to quality checks.

[0089] This system leverages AI-driven machine learning algorithms to build an internal QA system that checks data integrity between work steps and performs quality assurance for each step across all stages of the workflow. This internal QA system identifies and corrects any errors or inconsistencies in the data, ensuring accuracy, reliability, and consistency throughout the workflow. Additionally, by utilizing AI and machine learning, the software learns and improves over time, becoming more efficient and effective in detecting and resolving issues in the workflow. This ultimately leads to improved patient outcomes and better overall healthcare delivery. AI algorithm 606 learns from previous quality checks and identifies patterns indicating potential problems, enabling more accurate and efficient quality control. The AI-enabled RT system 600 provides real-time monitoring capabilities using AI-driven algorithms. The trend monitoring system 604 continuously monitors the workflow process, identifying quality issues when they occur and allowing for immediate remediation.

[0090] Figure 7 A process 700 for clinical trial matching according to an implementation scheme is illustrated. This process allows a patient to be matched with appropriate clinical trials or treatment options based on their medical history and other relevant factors. In step 702, patient information is collected from discrete sources such as EMR, PACS, and patient reception. This information is fed into an AI model 704. In step 706, the patient information is processed through an integrated multimodal data model. In step 708, the process searches for patients and matches them with clinical trials associated with their patient information, which may include their diagnostic and treatment plans. In step 710, the AI ​​model 704 verifies the accuracy of the recommendations from step 708 for matching patients with clinical trials for relevant guidelines. Then, according to the AI ​​model process, different tiered output options are selected. These options may be Option 1 for radiotherapy 712, Option 2 for radiotherapy and immunotherapy 714, and / or Option 3 for radiotherapy and treatment diagnostics. Such treatment methods utilizing treatment diagnostics are a two-pronged approach using radiotracers to diagnose and treat cancer. Radioactive tracers are compounds made from radioactive materials and chemicals that selectively bind to specific targets in the body.

[0091] Figure 8A quality control process for a healthcare setting, according to an implementation scheme, is illustrated. Process 800 allows the RT system to analyze patient data and identify potential problems or outliers in treatment plans or other aspects of care. For example, it identifies potential errors such as applying a prostate cancer treatment procedure to a female patient or applying an adult treatment template to a pediatric patient. In step 802, input data, such as patient information, treatment plans, imaging scan information, and additional information as discussed herein, are retrieved. In step 804, the system checks the input data for quality and accuracy issues using artificial intelligence. For example, it may identify a problem if a name is entered incorrectly, or if some input data is outside the possible range of the data (e.g., blood pressure is set outside the possible range for humans, which may indicate an input error). If no problem is found, the process proceeds to step 806, and the software continues in its workflow management process. If the problem is significant, the user is notified in step 808. Alternatively, depending on the problem, the system may examine it in conjunction with other AI applications to automatically find solutions to the problem. AI algorithms supporting the RT system may automatically generate specific solution suggestions to address the identified problems in step 810. Once selected, the problem is corrected, and the process moves back to step 802.

[0092] Figure 9 A process for relationship and pattern recognition in a healthcare setting, according to an implementation scheme, is illustrated. Process 900 allows for pattern recognition-based predictions, which can aid the decision-making process and suggest future treatment plans. AI relationship and pattern recognition 910 helps identify patients who may be at risk of certain side effects or complications and recommends appropriate treatment templates. AI relationship and pattern recognition 910 obtains input from planning instruction selection 902, patient reception 904 with service and modal information, new patient information 906, and / or data 908 from the hospital system. As an example, relationships or patterns between certain planning instructions and medical issues can be detected by AI relationship and pattern recognition 910. Relationships or patterns between patients of certain ages and / or genders can be detected by AI relationship and pattern recognition 910. These relationships and patterns can be stored data for modality based on patient conditions in step 912. Alternatively, the system may modify treatment plans, imaging protocols, software, and / or other decisions based on relationship and pattern recognition 910.

[0093] Figure 10 The process for automated updates of healthcare software, according to the implementation plan, is illustrated. RT can utilize AI-driven machine learning algorithms to process and analyze data from patients and users to discover patterns, relationships, and trends. For example, this can be accomplished through an AI model self-learning and training platform 470. Process 1000 demonstrates how AI updates RT system software and medical guidelines based on current treatments, patient data, and industry trends.

[0094] In step 1002, the system receives information about academic research on radiotherapy. This is one example, but may include other medical research, guidelines, and government reports. New information exists related to the patient's medical problem, and the RT system allows for automated improvement of medical decisions and related software through this process. Hospitals or clinics may have their own relevant guidelines or rules related to medical problems or radiotherapy. In step 1004, these guidelines are provided to the process.

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

[0096] In step 1010, as an example, the AI ​​provides a cost-benefit analysis of changes to the software and / or treatment plan. Then, in step 1012, the change can be approved (by the user or the system, depending on the type of change). If approved, in step 1014, if the change relates to the software, the software can automatically update itself. If the approved change relates to guidelines or treatment plans for a medical problem, the RT system software can also update these guidelines or treatment plans. If the change is not approved, the system can record the reasons in step 1016 for the AI ​​to consider for its own self-learning, and this is provided back to step 1010 for learning purposes. Through this process, the system can improve its efficiency and software usability more quickly. Additionally, through this process, patient care is updated and improved more quickly based on new knowledge.

[0097] Compared to conventional methods used for compiling workflow steps, the benefits of the methods and systems presented in this paper include improved integration, automation, standardization, and personalization. The methods and systems implemented in this paper enable resources for patient case review, decision support, and reporting. Management and scheduling of all staff within a radiation oncology department can be accomplished through the platform based on factors such as staff availability. The methods and systems in this paper enable users to achieve better accuracy, efficiency, integration, ease of use, and patient-centered care. Additionally, the time spent on complex workflow steps can be reduced through the automation and execution of workflow steps. The methods and systems in this paper further provide support for automated workflows and triggering. For example, contour drawing of organs at risk can be automatically triggered and executed. The methods and systems in this paper can be integrated with and interoperate with existing clinical environments such as TPS, OIS, HIS, etc. Multi-vendor clinical interoperability is achieved, and together with the benefits listed above, the timeline for RT workflows can be compressed, providing better overview, management, and monitoring of treatment planning workflows. Furthermore, patients and software users benefit from improved staff and equipment utilization (as an example, Figure 6 This includes trend monitoring, analysis of individual user behavior and productivity, and efficiency of the treatment process for assigned users. Furthermore, the systems and methods presented in this paper optimize and accelerate data transfer between multiple platforms, reduce the risk of human error, and track patients along the entire radiotherapy pathway.

[0098] The methods and systems presented in this paper address the challenges of data transfer between multi-vendor infrastructures and enable fully digital tracking of patients across multiple appointments. These methods and systems increase the level of automation in patient workflows within radiotherapy departments. Through various connectors, the methods and systems allow for automated data transfer between various third-party applications and provide a clear view of the patient workflow, as well as a common environment for review and approval at each step of the workflow.

[0099] The systems and processes described below can be embodied in hardware, such as a single integrated circuit (IC) chip, multiple ICs, application-specific integrated circuits (ASICs), etc. Furthermore, the order in which some or all of the procedure blocks appear in each procedure should not be considered limiting. Rather, it should be understood that some procedure blocks can be executed in various orders, not all of which are explicitly exemplified in this disclosure.

[0100] The aspects illustrated in this disclosure can also be practiced in a distributed computing environment, where certain tasks are performed by a remote processing device linked via a communication network. In a distributed computing environment, program modules can reside on both local and remote memory storage devices.

[0101] Furthermore, it should be understood that the various components described in this specification may include circuits, which may include components and circuit elements with appropriate values ​​to realize embodiments of the subject matter innovations. Furthermore, it should be understood that many different components may be implemented on one or more integrated circuit (IC) chips. For example, in one embodiment, a set of components may be implemented in a single IC chip. In other embodiments, one or more corresponding components are fabricated or implemented on separate IC chips.

[0102] refer to Figure 11 This illustration depicts a schematic block diagram of a computing environment 2100 according to the present disclosure, in which subject systems, methods, and computer-readable media can be deployed. The computing environment 2100 includes one or more clients 2102 (e.g., laptop computers, smartphones, PDAs, media players, computers, portable electronic devices, tablets, etc.). Clients 2102 can be hardware and / or software (e.g., threads, processes, computing devices). The computing environment 2100 also includes one or more servers 2104. Servers 2104 can also be hardware or hardware combined with software (e.g., threads, processes, computing devices). For example, server 2104 may accommodate threads to perform transformations by employing aspects of the present disclosure. In various embodiments, one or more subject front-end components can be deployed as hardware and / or software of client 2102, and one or more subject back-end components can be deployed as hardware and / or software of server 2104. One possible communication between client 2102 and server 2104 can be in the form of data packets sent between two or more computer processes, wherein the data packets may include video data. For example, the data packets may include metadata, such as associated context information. The computing environment 2100 includes a communication framework 2106 (e.g., a global communication network such as the Internet or a mobile network) that can be used to facilitate communication between the client 2102 and the server 2104.

[0103] Communication can be facilitated by wired (including fiber optic) and / or wireless technologies. Client 2102 includes or is operatively connected to one or more client data repositories 2108 that can be used to store information local to client 2102 (e.g., associated context information). Similarly, server 2104 operatively includes or is operatively connected to one or more server data repositories 2110 that can be used to store information local to server 2104.

[0104] In one implementation, client 2102 may transfer encoded files to server 2104 according to the disclosed subject matter. Server 2104 may store files, decode files, or send files to another client 2102. It should be understood that client 2102 may also transfer uncompressed files to server 2104, and server 2104 may compress files according to the disclosed subject matter. Similarly, server 2104 may encode video information and send the information to one or more clients 2102 via communication framework 2106.

[0105] Figure 12 A schematic block diagram illustrating another example computing environment 2200 according to this disclosure is shown, in which subject systems, methods, and computer-readable media can be deployed. Computing environment 2200 includes a cloud deployment architecture comprising one or more clients 2202 communicatively coupled to system cloud 2204 via a network (e.g., the Internet). System cloud 2204 may include a cloud load balancer, one or more application containers, one or more cloud service containers, a cloud data repository, and a cloud network communicatively coupling one or more cloud components to the cloud data repository. Depending on the cloud deployment architecture, client 2202 may include one or more client devices (e.g., mobile devices, laptops, desktop computers, etc.) that may include or use suitable applications (e.g., native mobile applications, web-based applications, thin / fat client applications, etc.) to access and use one or more features and functions of a subject-native / reconstructed medical imaging system deployed in system cloud 2204. In various specific implementations, one or more components of system 100 may be distributed between client 2202 and system cloud 2204.

[0106] Figure 13A schematic block diagram of another example computing environment 2300 according to this disclosure is illustrated, in which subject systems, methods, and computer-readable media can be deployed. Computing environment 2300 includes a virtualized enterprise deployment consisting of one or more clients 2202 communicatively coupled to a remote data center 2302 via a network (e.g., the Internet). Remote data center 2302 may include an application server subnet 2304 providing a load balancer, one or more application containers, one or more virtualization servers, and one or more rack servers. Data center 2302 may also include one or more data repositories communicatively coupled to application server subnet 2304 via a data center network. According to the virtualized enterprise deployment, clients 2202 may include one or more client devices (e.g., mobile devices, laptops, desktop computers, etc.) that may include or use suitable applications (e.g., native mobile applications, web-based applications, thin / fat client applications, etc.) to access and use one or more features and functions of a subject native / reconstructed medical imaging system deployed in data center 2302 and application server subnet 2304. In various specific implementations, one or more components of system 100 may be distributed between client 2202 and application server subnet 2304, and one or more data repositories may be provided remotely in data center 2302.

[0107] Figure 14A schematic block diagram of another example computing environment 2400 according to this disclosure is illustrated, in which subject systems, methods, and computer-readable media can be deployed. Computing environment 2400 includes a local enterprise deployment consisting of one or more clients 2202, which are communicatively coupled to an application server subnet 2404 via a network (e.g., the Internet). According to this embodiment, the application server subnet 2404 can be provided at an enterprise building 2402 (e.g., opposite 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 can be communicatively coupled to one or more data repositories provided at the enterprise building 2402 via an enterprise network. Similar to cloud and virtualization enterprise deployments, client 2202 may include one or more client devices (e.g., mobile devices, laptops, desktop computers, etc.) that may include or use suitable applications (e.g., native mobile applications, web-based applications, thin / fat client applications, etc.) to access and use one or more features and functionalities of a subject-native / reconstructive medical imaging system (e.g., system 100, etc.) deployed at enterprise building 2402 and application server subnet 2404. In various specific implementations, one or more components of the system herein may be distributed between client 2202 and application server subnet 2404, and one or more data repositories may be provided at enterprise building 2402.

[0108] Figure 15 A schematic block diagram illustrating another example computing environment according to this disclosure is shown, in which the subject system, methods, and computer-readable media may be deployed. The computing environment includes a local device deployment, wherein all components of the systems described herein are provided at a single client device 2502. Using this embodiment, client device 2502 may include a web-based application communicatively coupled to one or more application containers via loopback. The one or more application containers may communicatively couple to one or more databases and / or one or more local file systems via loopback.

[0109] refer to Figure 16 A suitable environment 2600 for implementing various aspects of the claimed subject matter 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 couples system components, including but not limited to system memory 2606, to the processing unit 2604. The processing unit 2604 can be any processor from a variety of available processors. Dual microprocessors and other multiprocessor architectures may also be used as the processing unit 2604.

[0110] The system bus 2608 can be any of a variety of bus architectures, including memory bus or memory controller, peripheral bus or external bus, and / or local bus using a variety of available bus architectures, including but not limited to Industry Standard Architecture (ISA), Micro Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronic Devices (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), PCMCIA Bus, FireWire (IEEE 22104), and Small Computer System Interface (SCSI).

[0111] System memory 2606 includes volatile memory 2610 and non-volatile memory 2612. The Basic Input / Output System (BIOS), which contains basic routines such as transferring information between components within computer 2602 during startup, is stored in non-volatile memory 2612. Furthermore, according to an innovation of the invention, codec 2605 may include at least one encoder or decoder, wherein at least one encoder or decoder may be composed of hardware, a combination of hardware and software, or software. Although codec 2605 is shown as a separate component, codec 2605 may be contained within non-volatile memory 2612. By way of illustration and not 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 acts as an external cache memory. According to aspects of the invention, volatile memory may store write operation retry logic, etc. RAM can be provided in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), and enhanced SDRAM (ESDRAM), by way of example rather than limitation.

[0112] Computer 2602 may also include removable / non-removable, volatile / non-volatile computer storage media. Figure 19 illustrates, for example, a disk storage device 2614. Disk storage device 2614 includes, but is not limited to, devices such as disk drives, solid-state drives (SSDs), floppy disk drives, magnetic tape drives, Zip drives, flash memory cards, or memory sticks. Furthermore, disk storage device 2614 may include a storage medium alone or in combination with another storage medium, including, but not limited to, optical disc drives, such as optical disc ROM devices (CD-ROM), CD recordable drives (CD-R drives), CD rewritable drives (CD-RW drives), or digital universal magneto-optical disc ROM drives (DVD-ROM). To facilitate connection of disk storage device 2614 to system bus 2608, a removable or non-removable interface, such as interface 2616, is typically used.

[0113] It should be understood that Figure 16 Software that acts as an intermediary between the user and the basic computer resources in a suitable operating environment 2600 is described. Such software includes an operating system 2618. The operating system 2618, which may be stored on a disk storage device 2614, is used to control and allocate the resources of the computer system 2602. Application programs 2620 utilize the operating system 2618 to manage resources through program modules 2624, and program data 2626 stored in system memory 2606 or on disk storage device 2614, such as power-on / power-off transaction tables. It should be understood that the claimed subject matter can be implemented using various operating systems or combinations of operating systems.

[0114] Users input commands or information into computer 2602 via input device 2628. Input device 2628 includes, but is not limited to, pointing devices such as mouse, trackball, stylus, touchpad, keyboard, microphone, joystick, gamepad, satellite dish, scanner, TV tuner card, digital camera, digital camcorder, webcam, etc. These and other input devices are connected to processing unit 2604 via interface port 2630 through system bus 2608. Interface port 2630 includes, for example, serial port, parallel port, game port, and Universal Serial Bus (USB). Output device 2636 uses some of the same type of ports as the input devices. Thus, for example, a USB port can be used to provide input to computer 2602 and output information from computer 2602 to output device 2636. Output adapter 2634 is provided to exemplify some output devices 2636 such as monitors, speakers, and printers, as well as other output devices 2636 that require special adapters. By way of example and not limitation, output adapter 2634 includes a video card and a sound card that provide means of connection between output device 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.

[0115] Computer 2602 can operate in a networked environment using a logical connection 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-based appliance, peer-to-peer device, smartphone, tablet, or other network node, and typically includes many of the elements described relative to computer 2602. For simplicity, only memory storage device 2640 is illustrated for remote computer 2638. Remote computer 2638 is logically connected to computer 2602 via network interface 2642 and subsequently connected 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 Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring, etc. WAN technologies include, but are not limited to, point-to-point links, such as Integrated Services Digital Network (ISDN) and its variants, circuit-switched networks, packet-switched networks, and Digital Subscriber Line (DSL).

[0116] 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, it may also be located outside computer 2602. For illustrative purposes only, the hardware / software required to connect to network interface 2642 includes internal and external technologies such as modems, including conventional telephone-grade modems, cable modems and DSL modems, ISDN adapters, wired and wireless Ethernet cards, hubs and routers.

[0117] The foregoing description includes examples of embodiments of the invention. It is certainly impossible to describe every conceivable combination of components or methods for the purpose of describing the claimed subject matter, but it should be understood that many further combinations and substitutions of the invention's innovations are possible. Therefore, the claimed subject matter is intended to cover all such changes, modifications, and variations falling within the spirit and scope of the appended claims. Furthermore, the above description of the illustrative embodiments of this disclosure (including those described in the abstract) is not intended to be exhaustive or to limit the disclosed embodiments to the precise form disclosed. While specific embodiments and examples have been described in this disclosure for illustrative purposes, various modifications can be made within the scope of the various embodiments and examples, as will be appreciated by those skilled in the art.

[0118] Specifically, and with respect to the various functions performed by the aforementioned components, devices, circuits, systems, etc., unless otherwise stated, the terminology used to describe these components is intended to correspond to any component that performs the specified function of the said components (e.g., a functional equivalent), even if it is not structurally equivalent to the disclosed structure, but performs the functions of the exemplary aspects of the claimed subject matter exemplified in this disclosure. In this regard, it will also be appreciated that the innovation includes systems and computer-readable storage media having computer-executable instructions for actions and / or events of various methods for performing the claimed subject matter.

[0119] The aforementioned system / circuit / module has been described with respect to the interactions between several components / frames. It should be understood that such systems / circuits and components / frames may include those components or designated sub-components, some designated components or sub-components, and / or additional components, and conform to the various permutations and combinations described above. Sub-components may also be implemented as communicatively connected to other components besides those included within a parent component (hierarchical). Furthermore, it should be noted that one or more components may be combined into a single component providing aggregate functionality, or divided into several separate sub-components, and any one or more intermediate layers (such as a management layer) may be provided to communicatively connect to these sub-components to provide integrated functionality. Any component described in this disclosure may also interact with one or more other components not specifically described in this disclosure but known to those skilled in the art.

[0120] Furthermore, although a specific feature of the subject matter innovation may be disclosed with respect to only one of several specific embodiments, such feature may be combined with one or more other features of other specific embodiments, as may be necessary and advantageous for any given or particular application. Additionally, where the terms “comprising,” “including,” “having,” “including,” variations thereof, and other similar words are used in the detailed description or claims, these terms are intended to be inclusive, similar to the term “comprising,” as open conversion words without excluding any additional or other elements.

[0121] As used herein, the terms “component,” “system,” etc., are generally intended to refer to a computer-related entity, which is hardware (e.g., circuitry), a combination of hardware and software, software, or an entity associated with an operating machine having one or more specific functions. For example, a component can be, but is not limited to, a process, processor, object, executable file, executing thread, program, and / or computer running on a processor (e.g., a digital signal processor). By way of example, an application running on a controller and the controller itself can both be components. One or more components may reside within a process and / or an executing thread, and components may reside on a single computer and / or be distributed across two or more computers. Furthermore, “device” can take the form of: specially designed hardware; generalized hardware specialized by executing software thereon, which enables the hardware to perform a specific function; software stored on a computer-readable storage medium; software transmitted on a computer-readable transmission medium; or combinations thereof.

[0122] Furthermore, the terms “example” or “exemplary” are used in this disclosure to indicate that something is used as an example, instance, or illustration. Any aspect or design described as “exemplary” in this disclosure is not necessarily to be construed as being more preferred or advantageous than other aspects or designs. Rather, the use of the terms “example” or “exemplary” is intended to present concepts in a specific manner. As used in this patent application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise specified or clear from the context, “X adopts A or B” is intended to mean any natural inclusive substitution. That is, “X adopts A or B” is satisfied if X adopts A; X adopts B; or X adopts both A and B. Furthermore, the articles “a” and “an” used in this application and the appended claims should generally be interpreted as meaning “one or more” unless otherwise specified or clear from the context that they refer to the singular form.

[0123] Computing devices typically include a variety of media, which may include computer-readable storage media and / or communication media, wherein the two terms are used differently in this specification, as described below. A computer-readable storage medium can be any available storage medium accessible by a computer, which is generally non-transitory in nature, and may include volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, a computer-readable storage medium can be implemented in conjunction with any method or technique for storing information such as computer-readable instructions, program modules, structured data, or unstructured data. A computer-readable storage medium may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, Digital Universal Disc (DVD) or other optical disc storage, magnetic tape cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible and / or non-transitory media that can be used to store desired information. A computer-readable storage medium can be accessed by one or more local or remote computing devices, for example, via access requests, queries, or other data retrieval protocols, to perform various operations relative to the information stored on the medium.

[0124] Based on the exemplary system described above, the methods that can be implemented according to the subject matter will be better understood with reference to the flowcharts of the accompanying drawings. For simplicity of description, these methods are described and illustrated as a series of actions. However, the actions according to this disclosure can occur in various orders and / or simultaneously, and together with other actions not presented and described in this disclosure. Furthermore, according to certain aspects of this disclosure, not all exemplified actions may be required to implement these methods. Moreover, those skilled in the art will understand and recognize that methods can alternatively be represented by a series of interrelated states through state diagrams or events. Furthermore, it should be understood that the methods disclosed in this disclosure can be stored on an article of art to facilitate the transmission and transfer of this method to a computing device. As used in this disclosure, the term "article of art" is intended to cover a computer program accessible from any computer-readable device or storage medium.

[0125] It should be understood that the above description is intended to be illustrative and not restrictive. For example, the above embodiments (and / or aspects thereof) may be used in combination with each other. Furthermore, many modifications may be made to adapt particular situations or materials to the teachings of various embodiments of the invention without departing from the scope of the invention. While the dimensions and types of materials described herein are intended to define parameters of various embodiments of the invention, these embodiments are by no means restrictive but exemplary. Many other embodiments will be apparent to those skilled in the art upon review of the above description. Therefore, the scope of the various embodiments of the invention should be determined by reference to the appended claims and the full scope of their equivalents.

[0126] In the appended claims, the terms “comprising” and “in” are used as common Chinese equivalents of the corresponding terms “including” and “wherein”. Furthermore, in the following claims, the terms “first,” “second,” and “third,” etc., are used only as illustrative marks and are not intended to impose numerical requirements on their objects. Moreover, the limitations of the following claims are not written in an apparatus-plus-function format and are not intended to be based on 35 USC. 112, paragraph 6, explains that unless and until these claims explicitly use the phrase "parts for..." followed by a functional statement without any other structure.

[0127] This written description uses examples to disclose various embodiments of the invention, including the best mode, and also enables those skilled in the art to practice various embodiments of the invention, including making and using any device or system and performing any included methods. The patent scope of the various embodiments of the invention is defined by the claims, and may include other examples that would occur to those skilled in the art. Such other examples are intended to fall within the scope of the claims if they have structural elements that are not indistinguishable from the literal language of the claims, or if they include equivalent structural elements that differ only slightly from the literal language of the claims.

Claims

1. A healthcare system, the healthcare system comprising: One or more processors (2604); Memory (2606); and One or more programs, wherein the one or more programs are stored in the memory (2606) and configured to be executed by the one or more processors (2604), the one or more programs comprising instructions for: Patient reception (412, 500) using a user interface (116) wherein the patient reception (412, 500) additionally receives information from different information sources, the information including at least electronic medical records (EMR) and image archiving and communication systems (PACS) and is able to pre-populate portions of the patient reception form based on artificial intelligence analysis of the information from the different information sources; Workflow management based on the patient reception (412, 500) through the medical diagnosis and treatment process includes providing a user interface (116) that displays workflow orchestration across the diagnosis and treatment process; Trend monitoring (604) for each step in the workflow management, wherein the trend monitoring (604) can provide recommendations in the workflow based on automatic quality reviews related to trends; as well as Treatment plans (484) based on user input are used during the workflow of the medical diagnosis and treatment process.

2. The healthcare system according to claim 1, wherein: The automated quality review associated with this trend is based on healthcare industry quality standards.

3. The healthcare system of claim 1, wherein the one or more procedures further include instructions for: An interoperability engine (112) provides interoperability between various software applications and data storage systems based on industry standards and proprietary programming interfaces.

4. The healthcare system according to claim 1, wherein: The treatment plan (484) can be further based on the patient reception (412,500) and workflow management stored in the non-relational database and the predictive analysis of the data in the system using Bayesian statistical methods of predictive analysis.

5. The healthcare system according to claim 1, wherein: The artificial intelligence analysis of the information from the different information sources includes examining the information based on the possible boundaries of relevant fields in the patient reception form.

6. The healthcare system according to claim 1, wherein: The artificial intelligence analysis of the information from the different information sources includes searching the patient (24) information and matching the patient information with relevant clinical trials, as well as verifying whether the patient (24) information complies with clinical trial guidelines.

7. The healthcare system of claim 1, wherein the one or more procedures further include instructions for: Pattern recognition (910) between patients based on artificial intelligence analysis of the workflow management of multiple patients, and providing user interface (116) suggestions on the display based on the recognized patterns.

8. A healthcare method, the healthcare method comprising: In a device having one or more processors (2604) and memory (2606), the following steps are included: Patient reception (412, 500) using a user interface (116) wherein the patient reception (412, 500) additionally receives information from different information sources, the information including at least electronic medical records (EMR) and image archiving and communication systems (PACS) and is able to pre-populate portions of the patient reception form based on artificial intelligence analysis of the information from the different information sources; Workflow management based on the patient reception (412, 500) through the medical diagnosis and treatment process includes providing a user interface (116) that displays workflow orchestration across the diagnosis and treatment process; Trend monitoring (604) for each step in the workflow management, wherein the trend monitoring (604) can provide recommendations in the workflow based on automatic quality reviews related to trends; and Treatment plans (484) based on user input are used during the workflow of the medical diagnosis and treatment process.

9. The healthcare method according to claim 8, wherein: The automated quality review associated with this trend is based on healthcare industry quality standards.

10. The healthcare method of claim 8, wherein the one or more procedures further comprise the following steps: An interoperability engine (112) provides interoperability between various software applications and data storage systems based on industry standards and proprietary programming interfaces.

11. The healthcare method according to claim 8, wherein: The treatment plan (484) can be further based on the patient reception (412,500) and workflow management stored in the non-relational database and the predictive analysis of the data in the system using Bayesian statistical methods of predictive analysis.

12. The healthcare method according to claim 8, wherein: The artificial intelligence analysis of the information from the different information sources includes examining the information based on the possible boundaries of relevant fields in the patient reception form.

13. The healthcare method according to claim 8, wherein: The artificial intelligence analysis of the information from the different information sources includes searching the patient information and matching the patient information with relevant clinical trials, as well as verifying whether the patient information complies with clinical trial guidelines.

14. The healthcare method of claim 8, wherein the one or more procedures further comprise the following steps: Pattern recognition (910) between patients based on artificial intelligence analysis of the workflow management of multiple patients, and providing user interface (116) suggestions on the display based on the recognized patterns.

15. A healthcare engine embodied on a non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium storing one or more programs, the one or more programs including instructions that, when executed by one or more processors (2604) of an electronic device, cause the device to provide: Patient reception (412, 500) using a user interface (116) wherein the patient reception (412, 500) additionally receives information from different information sources, the information including at least electronic medical records (EMR) and image archiving and communication systems (PACS) and is able to pre-populate portions of the patient reception form based on artificial intelligence analysis of the information from the different information sources; Workflow management based on the patient reception (412, 500) through the medical diagnosis and treatment process includes providing a user interface (116) that displays workflow orchestration across the diagnosis and treatment process; Trend monitoring (604) for each step in the workflow management, wherein the trend monitoring (604) can provide recommendations in the workflow based on automatic quality reviews related to trends; as well as Treatment plans (484) based on user input are used during the workflow of the medical diagnosis and treatment process.

16. The healthcare engine of claim 15, wherein the one or more programs further include instructions for: An interoperability engine (112) provides interoperability between various software applications and data storage systems based on industry standards and proprietary programming interfaces.

17. The healthcare engine of claim 15, wherein: The treatment plan (484) can be further based on the patient reception (412,500) and workflow management stored in the non-relational database and the predictive analysis of the data in the system using Bayesian statistical methods of predictive analysis.

18. The healthcare engine of claim 15, wherein: The artificial intelligence analysis of the information from the different information sources includes examining the information based on the possible boundaries of relevant fields in the patient reception form.

19. The healthcare engine of claim 15, wherein: The artificial intelligence analysis of the information from the different information sources includes searching the patient (24) information and matching the patient information with relevant clinical trials, as well as verifying whether the patient (24) information complies with clinical trial guidelines.

20. The healthcare engine of claim 15, wherein the one or more programs further include instructions for: Pattern recognition (910) between patients based on artificial intelligence analysis of the workflow management of multiple patients, and providing user interface (116) suggestions on the display based on the recognized patterns.

Images