Connecting multiple large medical products and services to single ecosystem

Abstract

Embodiments of the present disclosure relate to connecting multiple large medical products and services to a single ecosystem. Embodiments disclosed herein implement a computing system in a computing network having hardware and software components of clinical system resources. The computing network may be a closed private network. Clinical system resources may be located locally or otherwise geographically close to a clinical facility. The clinical system resources may be heterogeneous resources. Clinical system resources may access or execute an interface program for performing interoperability operations on input data or instructions from a clinic database or upstream clinical system resources of a clinical web computing system. For example, an interface program may, for example, convert a data format of instructions or application data, or authenticate upstream clinical system resources that send application data or instructions, etc. During joining, the integration program may perform operations for authenticating, permitting verification, and testing and verifying interoperability of clinical system resources.

Description

Technical Field

[0001] This application generally relates to interoperability and compatibility among heterogeneous computing resources in a computing network. In particular, it relates to systems and methods for managing the interoperability of data and services between various healthcare software applications and medical devices. Background Art

[0002] The market for radiation oncology products is flooded with hardware and software products designed to assist and enhance the treatments delivered by providers to patients. Currently, there is no unified platform or program to integrate these products (hardware or software products) while focusing on improving clinical workflows, patient safety, compliance, and cybersecurity. A common technical hurdle for such integration is to solve how to allow third-party applications to become part of the integration platform while still retaining or maintaining the security identification of various different applications and the control over which application uses which resources of the platform (e.g., APIs (Application Programming Interfaces), software services, data sources). Summary of the Invention

[0003] Systems and methods for solving the disadvantages of the prior art are disclosed herein, and any number of additional or alternative advantages may be provided. Embodiments include a clinical computing system for radiotherapy planning and treatment or other clinical or healthcare-related therapies and treatment activities. The clinical computing system is in a closed private computing network with hardware components and software components having clinical system resources located on-premises or otherwise geographically close to a clinical facility (e.g., a hospital, a healthcare clinic). The clinical system resources can access or execute an interface program (e.g., an API) for performing certain interoperability operations on input data or instructions from a clinic database or upstream clinical system resources of the clinical network computing system. For example, the interface program can, for example, convert the data format of instructions or application data, or authenticate the upstream clinical system resources sending the application data or instructions, etc. During the onboarding process, the integration program can perform operations for authenticating, validating permissions, and testing and verifying the interoperability of the clinical system resources.

[0004] An embodiment may include a computer method for hosting resources in a computing network. The method includes a computer of the computing network obtaining authentication information associated with a clinical system resource of the computing network. The authentication information includes claimed authentication data and an authentication protocol. The clinical system resource generates at least one attribute of a patient treatment. The method includes the computer authenticating the clinical system resource based on comparing the claimed authentication credentials with stored expected authentication credentials. The method includes the computer identifying one or more interface programs for the clinical system resource to exchange at least one attribute of the patient treatment with a software application of a clinical therapy machine. The method includes the computer verifying the clinical system resource as an interoperable resource in response to determining that the clinical system resource meets one or more interoperability test thresholds corresponding to one or more interoperability test operations using the one or more interface programs. The method includes the computer storing a set of resource configurations in a database record representing a verified version of the clinical system resource. The set of resource configurations includes a list of functional outputs for the clinical system resource, the authentication protocol, and a list of one or more interface programs. The resource may be a heterogeneous resource. The computing network may be a closed network with local resources. The resource may be a local resource in a closed computing network. The closed computing network may include one or more computing devices, including a computer.

[0005] The patient treatment may include radiotherapy treatment. At least one attribute of the patient treatment includes an attribute of the patient's radiotherapy treatment. The software application of the clinical therapy machine may include a patient radiotherapy machine.

[0006] The method may include: the computer obtaining claimed license data associated with the clinical system resource; and the computer verifying the clinical system resource based on comparing the claimed license data with stored expected license data.

[0007] The method may include the computer granting access rights to the clinical system resource for executing one or more interface programs based on authenticating, verifying, and validating the clinical system resource.

[0008] The method may include the computer transmitting a security token to the clinical system resource, the security token indicating the access rights granted to the clinical system resource.

[0009] The method may include the computer generating a notification indicating a new version of the clinical system resource for an end-user device in response to identifying a change in at least one of the function list or the authentication protocol compared to the verified version of the clinical system resource.

[0010] The method may include identifying a new version of a clinical system resource by a computer in response to a change based on at least one of a feature list or an authentication protocol as compared to a verified version of the clinical system resource, and revoking access rights granted to the clinical system resource for executing one or more interface programs.

[0011] One or more interface programs include at least one of a data exchange and integration application programming interface (API), a healthcare scripting API, a quality assurance (QA) API, a database access API, a motion management interface (MMI), or a Varian treatment interface ( ).

[0012] Determining that a clinical system resource meets one or more interoperability test thresholds may include: performing, by a computer, interoperability test operations for an interface program to generate one or more test outputs; and determining, by the computer, a test difference for comparison with the interoperability test thresholds based on comparing the one or more test outputs with one or more expected outputs for the interoperability test operations.

[0013] An embodiment may include a system for hosting resources in a computing network. The system may include a database of the computing network, the database being configured to store multiple database records for multiple verified versions of multiple clinical system resources. The system may include a server of the computing network, the server including a processor and being configured to: obtain authentication information associated with a clinical system resource of the computing network, the authentication information including claimed authentication credentials and an authentication protocol, wherein the clinical system resource generates at least one attribute of patient treatment; authenticate the clinical system resource based on comparing the claimed authentication credentials with stored expected authentication credentials; identify one or more interface programs for the clinical system resource to exchange at least one attribute of patient treatment with a software application of a clinical therapy machine; verify the clinical system resource as an interoperable resource in response to determining that the clinical system resource meets one or more interoperability test thresholds corresponding to one or more interoperability test operations using the one or more interface programs; and store a resource configuration set into a database record of the database, the database record representing a verified version of the clinical system resource, the resource configuration set including a list of functional outputs for the clinical system resource, an authentication protocol, and a list of one or more interface programs. The resource may be a heterogeneous resource. The computing network may be a closed network with local resources. The resource may be a local resource in a closed computing network. The closed computing network may include one or more computing devices, including a computer.

[0014] Patient treatment may include radiotherapy treatment. At least one attribute of patient treatment may include an attribute of radiotherapy treatment. A software application of a clinical therapy machine may include a patient radiotherapy machine.

[0015] The server may be further configured to: obtain claimed license data associated with a clinical system resource; and verify the clinical system resource based on comparing the claimed license data with stored expected license data.

[0016] The server may be further configured to grant access to the clinical system resource for executing one or more interface programs based on authenticating, verifying, and validating the clinical system resource.

[0017] The server may be further configured to transmit a security token to the clinical system resource, the security token indicating the access rights granted to the clinical system resource.

[0018] The server may be further configured to: generate a notification indicating a new version of the clinical system resource for an end-user device in response to identifying a change in at least one of a feature list or an authentication protocol compared to a verified version of the clinical system resource.

[0019] The server may be further configured to: revoke the access rights granted to the clinical system resource for executing one or more interface programs in response to identifying a new version of the clinical system resource based on a change in at least one of a feature list or an authentication protocol compared to a verified version of the clinical system resource.

[0020] One or more interface programs include at least one of a data exchange and integration application programming interface (API), a healthcare scripting API, a quality assurance (QA) API, a database access API, a motion management interface (MMI), or a Varian treatment interface among others.

[0021] When it is determined that a clinical system resource meets one or more interoperability test thresholds, the server may be configured to: perform interoperability test operations for the interface program to generate one or more test outputs; and determine a test difference for comparison with the interoperability test thresholds based on comparing the one or more test outputs with one or more expected outputs for the interoperability test operations.

[0022] An embodiment may include a non-transitory computer-readable medium of a computing network, the non-transitory computer-readable medium being coupled to one or more processors of the computing network and containing executable instructions that, when executed by the one or more processors, cause the one or more processors to: obtain authentication information associated with clinical system resources of a closed computing network, the authentication information including claimed authentication credentials and an authentication protocol, wherein the clinical system resources generate at least one attribute of patient treatment; authenticate the clinical system resources based on comparing the claimed authentication credentials with stored expected authentication credentials; identify one or more interface programs for the clinical system resources to exchange at least one attribute of patient treatment with a software application of a clinical therapy machine; in response to determining that the clinical system resources meet one or more interoperability test thresholds corresponding to one or more interoperability test operations using the one or more interface programs, verify the clinical system resources as interoperable resources; and store a set of resource configurations in a database record of a database, the database record representing a verified version of the clinical system resources, the set of resource configurations including a list of functional outputs for the clinical system resources, the authentication protocol, and a list of the one or more interface programs. The computing network includes resources. The resources may be heterogeneous resources. The computing network may be a closed network with local resources. The resources may be local resources in a closed computing network.

[0023] Patient treatment may include radiotherapy treatment. At least one attribute of patient treatment includes an attribute of the patient's radiotherapy treatment. The software application of the clinical therapy machine may include a patient radiotherapy machine.

[0024] The executable instructions, when executed by the one or more processors, may further cause the one or more processors to: obtain claimed license data associated with the clinical system resources; and verify the clinical system resources based on comparing the claimed license data with stored expected license data.

[0025] The executable instructions, when executed by the one or more processors, may further cause the one or more processors to: grant access rights to the clinical system resources for executing the one or more interface programs based on authenticating, verifying, and validating the clinical system resources; and transmit a security token to the clinical system resources, the security token indicating the access rights granted to the clinical system resources.

[0026] The executable instructions, when executed by the one or more processors, may further cause the one or more processors to: revoke the access rights granted to the clinical system resources for executing the one or more interface programs in response to identifying a new version of the clinical system resources based on a change in at least one of the function list or the authentication protocol compared to the verified version of the clinical system resources. Description of the Drawings

[0027] Non-limiting embodiments of the present disclosure are described by way of example with reference to the accompanying drawings, which are schematic and not intended to be drawn to scale. Unless indicated as representing the background art, these figures represent aspects of the present disclosure.

[0028] Figures 1A - 1B Components of a clinical network computing system are illustrated that implement integration operations for interoperability and compatibility between hardware components and software components of the clinical network computing system according to an embodiment.

[0029] Figure 2 Operations of a method for joining and hosting clinical system resources at a clinical computing system architecture of a plurality of local computing resources having a closed computing network are shown according to an embodiment. Detailed Description

[0030] Reference will now be made to the illustrative embodiments depicted in the accompanying drawings, and specific language will be used herein to describe them. However, it will be understood that no limitation of the claims or the scope of the present disclosure is thereby intended. As will occur to those of ordinary skill in the relevant art and those in possession of the present disclosure, changes and further modifications to the features of the invention described herein, as well as additional applications of the principles of the subject matter described herein, will be considered to be within the scope of the subject matter disclosed herein. Other embodiments may be used and / or other changes may be made without departing from the spirit or scope of the present disclosure. The illustrative embodiments described in the detailed description are not meant to limit the subject matter presented.

[0031] Computing network architectures deployed for radiotherapy or other clinical settings (e.g., hospitals, health clinics, doctor's offices, research laboratories) often include hardware products and software products from various vendors. Data generated from these products cycles among the various products of the system for performing downstream operations. This requires clinical computing systems to employ various software programming (such as application programming interfaces (APIs)) to identify or reconcile differences in data formats and software protocols in order to integrate each product into the ecosystem. Computing resources can be heterogeneous, such as hardware and software products or resources from different manufacturers or software developers, which typically requires operations for analyzing and validating interoperability, including data exchange between products of different companies. For heterogeneous resources, the embodiments described herein provide processes for analyzing, validating, and establishing interoperability among various heterogeneous products. Computing resources can be homogeneous, such as hardware and software products or resources from the same or related manufacturers or software developers. For homogeneous resources, the embodiments described herein provide processes for analyzing, validating, and establishing intraoperability among various products. Although the embodiments describe examples of "interoperability" analysis and validation operations, the embodiments can also include processes and functions for analyzing and validating "intraoperability".

[0032] Although the embodiments described herein refer to clinical computing networks implemented for radiotherapy treatment and radiotherapy healthcare devices, the embodiments are not limited thereto. The embodiments can include implementing healthcare-related hardware components (e.g., medical imaging devices, radiotherapy devices) and / or healthcare-related software components (e.g., healthcare hardware control software; treatment delivery software; treatment planning software).

[0033] Common methods for hosting clinical computing ecosystems include using cloud or virtualized computing systems. Various clinical or healthcare applications and application data are hosted in cloud-provisioned computing resources, allowing functions such as storage, analysis, authentication, and data interoperability APIs to be hosted and executed in the provisioned resources of the cloud system. In a cloud system, each computing resource (e.g., hardware component and software component, data storage location) is referenced, invoked, or linked by accessing or calling a Uniform Resource Locator (URL), where the URL serves as a web-based pointer to a software component or hardware component hosted in the cloud system via the Internet. Connectivity is typically required for these computing resources of clinical systems to access the hardware component or software component associated with the URL. The need for Internet connectivity raises several issues, including degraded or lost connectivity to cloud system resources, exposure to Internet-based cyberattacks, and other potential problems.

[0034] Embodiments of the present disclosure implement a clinical computing system in a closed private computing network having hardware components and software components located locally or otherwise geographically close to a clinical facility (e.g., a hospital, a healthcare clinic). The software components and hardware components of the clinical system (e.g., computing devices, sensors, medical devices (e.g., motion management devices, MRI (Magnetic Resonance Imaging) devices), application servers, routers, switches) are housed within or near the clinical facility. Thus, the components do not require Internet connectivity to operate or access patient care-related data. A typical clinical computing system does not implement local computing resources; a typical clinical computing system also does not implement a closed network computing architecture.

[0035] A clinical computing system can include a heterogeneous collection of hardware components and software components having multiple data formats and authentication protocols and other differences. Currently, there is no unified platform or program to integrate such heterogeneous (hardware and software) products while focusing on the requirements of the clinical environment (such as improving clinical workflows, patient safety, compliance, and cybersecurity, etc.). The technical problem is how to allow multiple vendor products and applications to be integrated into a common clinical computing system while also maintaining secure identification of different applications and control over which applications can access which resources of the clinical system (e.g., APIs, application services, databases).

[0036] Vendors of clinical system resources can address the integration capabilities (e.g., interoperability and / or compatibility) between heterogeneous components. In some cases, the interoperability capabilities of medical devices (e.g., motion management devices) are developed by the vendors producing the products, then implemented and verified in the clinical network via a software emulator, and finally verified by the clinical customers using the clinical network system. The problem is that interoperability between hardware devices is time-consuming and expensive, and the costs are spread to the clinical customers or patients who ultimately use them.

[0037] In addition, the integration of multiple software applications, including clinical system resources for radiation oncology solutions, is typically the responsibility of clinical customers. Clinical customers typically use multiple vendor products to find the best available solutions for integration, coordinate parties and tasks, implement the integration, and provide long-term support for the integration. Although traditional healthcare integration standards (e.g., Health Level Seven (HL7) standards, Digital Imaging and Communications in Medicine (DICOM) standards) have reduced and streamlined the amount of integration options, these traditional standards are merely data formatting standards and do not provide the foundation for clinical computing systems in which new vendors and applications can be added to the clinical computing system and can ultimately contribute to the ongoing clinical workflows of hardware and software components.

[0038] The embodiments described herein implement a unified integration method for consistent interoperability and / or compatibility of hardware and software. The clinical computing network system described herein serves as a unified clinical platform, which includes supported processes to assure the end-using physicians that the integration among the developed components has been certified as safe to use, compliant, and free from accidental or unauthorized use.

[0039] Embodiments may include various interface programs (e.g., APIs) and standard implementation programs for healthcare software application interoperability and / or hardware compatibility. Non-limiting examples of interfaces may include data exchange and integration APIs (“data exchange APIs”), healthcare scripting APIs, quality assurance (QA) APIs, database access APIs (“DB access APIs”), and motion management interfaces (MMIs), etc.

[0040] The data exchange API enables seamless data exchange and integration between computing devices or clinical system resources of the clinical network computing system. The data exchange API may support and execute, for example, Fast Healthcare Interoperability Resource (FHIR) standards or other standardized or proprietary protocols. The data exchange API executed by the integration program or clinical system resources promotes interoperability between hardware or software clinical system resources.

[0041] The scripting API of the clinical network computing system includes, for example, accessing healthcare scripting application services (e.g., ) a software library and programming interface for treatment planning information within. In some embodiments, the scripting API of the clinical network computing system provides the same functionality as typical scripting API implementations and may also include an additional executable layer for identification and authorization, which is customized for use by the hardware and software of clinical system resources produced by various enterprise-level third-party vendor products.

[0042] The QA interface can simplify the integration process for different QA objects and applicable data elements in the clinical network computing system. When combining the functions of various clinical system resources from the clinical network computing system, the QA interface can be used, for example, to verify data quality, thereby beneficially enhancing scalability, usability, and efficiency.

[0043] The DB access API enables a clinical system resource or integration program to generate SQL (Structured Query Language) queries (e.g., select statements) and publish them to a database containing patient information or treatment information generated, for example, by the software applications of the clinical network computing system.

[0044] The MMI can transform and verify the motion data and position data exchanged between a radiotherapy device and a treatment sensor (e.g., a camera), where the treatment sensor provides the motion information and pose information of the patient for adjusting the radiotherapy device. The treatment sensor can transmit various types of data related to the position and motion of the patient to a control processor or computing device that controls the operation of the radiotherapy device, and the control processor or computing device can invoke or execute the MMI to ingest the motion information and position information into a format compatible with the radiotherapy device.

[0045] Embodiments may include additional or alternative types of interfaces, such as an authentication API or a radiotherapy controller API. The authentication API allows computing devices of the clinical computing system to authenticate each other, which may include requesting an authentication status and presenting an authentication status. The controller API (such as the Virtual Treatment Interface ( )) allows certain computing resources to control and monitor radiotherapy treatment machines. The control API facilitates the seamless integration of heterogeneous computing resources, enabling multiple computing devices and clinical therapy machines (e.g., radiotherapy machines, clinical imaging or scanning machines) to exchange data. Using the control API, data related to patient positioning, beam control, and imaging can be shared among heterogeneous clinical system resources.

[0046] An interface program (e.g., an API) can correspond to a functional domain of a clinical system resource. A functional domain represents the functional or operational purpose of a clinical system resource. Non-limiting examples of functional domains include practice management, treatment planning, quality assurance, motion management, and treatment delivery. An integration program and a clinical system resource can implement interfaces and / or software applications corresponding to the (multiple) functional domains.

[0047] The practice management domain includes clinical system resources for managing the operations of a clinic. The practice management domain in radiotherapy refers to the regulatory and administrative aspects of running a radiotherapy practice. This includes scheduling patient appointments, billing for services, managing patient records, ensuring compliance with regulatory standards, and coordinating care with other healthcare providers. The goal of practice management functions and features is to ensure that the practice operates smoothly and efficiently, providing high-quality care to patients while also maintaining financial sustainability.

[0048] The treatment planning domain in the context of radiotherapy (or other clinic computing systems) involves creating a detailed plan for delivering a radiation dose to a patient's tumor site. The plan is designed to effectively target cancer cells while minimizing exposure to surrounding healthy tissue. The treatment planning domain in radiotherapy can utilize API-based interoperability standards such as HL7's FHIR standard. This allows for the rapid creation and deployment of different functions and facilitates data exchange between various clinical system resources involved in the treatment process (such as patient management, machine control, and electronic health records).

[0049] The QA domain in a radiotherapy treatment system (or other clinic computing systems) includes hardware and software functions intended to ensure the accuracy and reproducibility of treatment data output and treatment delivery. The QA domain can involve a series of checks and procedures designed to verify that aspects of the treatment domain, from treatment planning to treatment delivery, are being performed correctly and consistently.

[0050] The motion management domain in radiotherapy (or other clinic computing systems) includes hardware and software functions for mitigating the effects of intrafractional respiratory motion and position of a patient during treatment, particularly for lung tumors and upper abdominal tumors. The motion management domain involves, for example, measuring, monitoring, and managing a patient's respiratory motion to ensure accurate treatment delivery. The motion management domain includes MMI.

[0051] The treatment delivery domain in radiotherapy (or other clinical computing systems) includes the hardware and software functions for the actual supervision of radiotherapy for a patient in accordance with a treatment plan (e.g., controlling radiotherapy equipment). The treatment delivery domain involves complex machinery (such as radiotherapy machines, linear accelerators, medical imaging systems, and robotic arms) to deliver a precise dose of radiation to the tumor site while avoiding surrounding healthy tissue or providing other forms of care. The treatment delivery domain often includes real-time imaging and patient positioning systems to ensure accuracy. Interoperability in the treatment delivery domain can involve APIs for machine control, patient safety systems, and integration with other clinical systems. The goal of the treatment delivery domain is to deliver treatment safely, effectively, and comfortably.

[0052] In many cases, the clinical system resources that execute the interface program are the clinical system resources in which the software application that invokes the interface is installed and runs. In the context of radiotherapy and interoperability (or other clinical systems), the computing resources that execute the API can vary based on a particular use case. For example, when the API is used for treatment planning, the API can be executed on a dedicated treatment planning computer system. If the API is used for machine control, the API can be executed on the control system of a radiotherapy machine. If the API is used for integration with an electronic health record, the API can be executed on a client computing device (e.g., a clinic computer, a doctor's computer, a clinic server, a clinic database) that accesses, generates, stores, or hosts the electronic health record. In some cases, a centralized integration server can invoke and implement the API on behalf of another clinical system resource of a clinical system.

[0053] Components of an example system

[0054] Figures 1A - 1B Illustrates the components of a clinical network computing system 100 that implements integration operations for interoperability and compatibility between the hardware components and software components of the clinical network computing system 100 according to an embodiment.

[0055] Reference Figure 1A , the clinical network computing system 100 includes an integration server 102, clinical system resources 120a - 120i (generally referred to herein as clinical system resources 120), and client devices 152. The various hardware components and software components of the clinical network computing system 100 communicate with each other via a closed network 130. The components of the clinical network computing system 100 (including various computing devices or clinical system resources 120) and the components of the closed network 130 can be located locally (e.g., within or near a physical clinical facility). The clinical network computing system 100 is not limited to the components described herein and can include additional or other components not shown for the sake of brevity, which can be considered to be within the scope of the embodiments described herein.

[0056] The closed network 130 includes various hardware components and software components for handling device communication, including switches, routers, firewalls, proxy servers, etc. The closed network 130 may employ wired communication and / or wireless communication according to one or more standards and / or via one or more transmission media. Communication on the closed network 130 may be performed according to various communication protocols, such as the Transmission Control Protocol and Internet Protocol (TCP / IP), the User Datagram Protocol (UDP), and IEEE (Institute of Electrical and Electronic Engineers) communication protocols. In one example, the closed network 130 may include wireless communication according to a Bluetooth or Wi-Fi (wireless fidelity) specification set or another standard or proprietary wireless communication protocol. Examples of the closed network 130 may include a private or public LAN (Local Area Network), WLAN (Wireless Local Area Network), CAN (Controller Area Network), and / or intranet included within the physical and logical network architectures of a clinical facility.

[0057] The clinical system resources 120 include various heterogeneous hardware components and software components for performing various tasks associated with radiotherapy treatment or other forms of clinical patient care or supervision (e.g., hardware components and software components from multiple vendors or product lines; hardware components and software components implementing multiple data modalities or formats). Non-limiting examples of the clinical system resources 120 include the clinic computer 120a, the doctor device 120b, the clinic server 120c, the clinic database 120d, the medical imaging device 120e, the sensors 120f - 120h, and the radiotherapy device 120i, as well as other types of hardware components and software components of the clinical network computing system 100.

[0058] The clinical system resources 120 include various clinic computing devices 120a - 120c, including a clinic computer 120a, a doctor device 120b, and / or a clinic server 120c, where these clinic computing devices 120a - 120c can be computing devices including a processor, a non - transitory storage device, and software programming for performing various processes and tasks described herein. The clinic computing devices 120a - 120c can host or execute various software applications related to certain functional domains (e.g., treatment planning, treatment delivery). These software applications can ingest and analyze various types of data from a clinic database 120d or other data sources, and generate various outputs including application data or executable instructions for one or more clinical system resources 120. The clinic computing devices 120a - 120c can store the output into the clinic database 120d, and / or transmit the output to other clinical system resources 120 for performing downstream operations. The clinic computing devices 120a - 120c can access or execute an interface program (e.g., an API) for performing certain interoperability operations on input data or instructions from the clinic database 120d or upstream clinical system resources 120 of the clinical network computing system 100. For example, the interface program can convert the data format of instructions or application data, or authenticate the upstream clinical system resources 120 that send the application data or instructions, etc.

[0059] The medical imaging device 120e includes hardware and software for generating medical image data for a patient. Non - limiting examples of the medical imaging device 120e include an MRI device, a CAT (computed tomography) device, an X - ray device, and other types of medical imaging devices 120e. The medical imaging device 120e includes an integrated processing device, and / or receives instructions from the clinic computing devices 120a - 120c. The image data can be stored in the clinic database 120d as a data record associated with a patient or patient treatment. The medical imaging device 120e can access or execute an interface program (e.g., an API) for performing certain interoperability operations on input data or instructions from the clinic database 120d or other clinical system resources 120 of the clinical network computing system 100.

[0060] The radiotherapy device 120i includes hardware and software for performing radiotherapy treatment on a patient. The radiotherapy device 120i can receive various inputs from other devices of the clinical network computing system 100, such that the computing devices managing the radiotherapy device 120i (e.g., the administrator computer 152, the integrated processor of the radiotherapy device 120i) can adjust the operation of the radiotherapy device 120i (e.g., beam angle, treatment attributes, radiation parameters) based on instructions from the administrator computer 152 or in response to various data inputs received from the treatment sensors 120f - 120h. For example, the radiotherapy device 120i includes a radiotherapy therapy machine that adjusts the gantry, beam blocking devices (e.g., Multi - Leaf Collimator (MLC)), and treatment couch based on an optimized beam angle, where the optimized beam angle is the angle of the radiotherapy device 120i that emits radiation. The radiotherapy device 120i and / or the treatment sensors 120f - 120h can access or execute an interface program (e.g., API) for performing certain interoperability operations on input data or instructions from other clinical system resources 120 of the clinical network computing system 100.

[0061] The integrated database 103 stores various types of data regarding the clinical system resources 120 that have been verified and authenticated by the integrated server 102 as being integrated (e.g., interoperable, compatible) with the clinical network computing system 100. The integrated database 103 can be hosted by one or more computing devices of the clinical network computing system 100 that include hardware components (e.g., processors, non - transitory machine - readable storage devices) and software components (e.g., database management system) capable of performing the various processes and tasks described herein. The database records stored in the integrated database 103 can represent the verified versions of the clinical system resources 120 that have been verified by the integration program 111 of the integrated server 102 as being integrated (e.g., interoperable, compatible, both) with the clinical network computing system 100. The database records of the verified versions include various types of information about a particular version or the clinical system resources 120. Non - limiting examples of the data stored in the integrated database 103 include function lists, functional domains, input or output data formats, and authentication protocols, as well as other types of information about a particular version or the clinical system resources 120.

[0062] The integration server 102 includes a computing device that includes hardware components (e.g., a CPU (central processing unit)) and software components (e.g., an integration program 111) capable of performing the various features and functions of the integration server 102 described herein. The integration server 102 executes the integration program 111, which performs various functions for managing the integration (e.g., interoperability and compatibility) between the various clinical system resources 120 of the clinical network computing system 100. Non-limiting examples of the integration functions performed by the integration program 111 include joining clinical system resources 120, authenticating clinical system resources 120, verifying clinical system resources 120, interfacing with clinical system resources 120, and managing interfaces for clinical system resources 120, as well as other possible integration functions. The integration program 111 performs integration functions that unify or integrate the clinical system resources 120 within the clinical network computing system 100 (e.g., enterprise-level third-party vendor medical products and services among the clinical system resources 120). The integration program 111 enhances the interoperability between the clinical system resources 120, which can beneficially result in improved integration, workflows, user experiences, and patient outcomes. The integration program 111 can prioritize, for example, consistency, compliance, regulatory compliance, data privacy, and cybersecurity among the clinical system resources 120.

[0063] The integration program 111 can verify the interoperability of new clinical system resources 120 and capture various types of information about the clinical system resources 120. The integration program 111 can store the information about the clinical system resources 120 into database records of the integration database 103, where the database records represent new instances of a verified version of a particular clinical system resource 120.

[0064] In many cases, the clinical system resources 120 implement interface programs (e.g., APIs) for performing integration operations. However, in some cases, the integration program 111 can implement the interface programs on behalf of the clinical system resources 120, where the integration server 102 is an intermediate destination for data exchange between the clinical system resources 120 via a closed network 130.

[0065] An interface program (e.g., an API) can correspond to a functional domain of the clinical system resource 120. The functional domain represents the functional or operational purpose of the clinical system resource 120. Non-limiting examples of functional domains include practice management, treatment planning, quality assurance, campaign management, and treatment delivery. The integration program 111 and the clinical system resource 120 can implement interfaces and / or software applications corresponding to the (multiple) functional domains. In the context of radiotherapy and interoperability, the clinical system resource 120 that executes the interface program may vary. In many cases, the clinical system resource 120 that retrieves and executes the interface program is the specific clinical system resource 120 in which the software application using the interface is installed and running. As an example, when the clinical system resource 120 uses the interface program for treatment planning, the interface program can be retrieved by the clinic computing devices 120a - 120c that execute a dedicated software application for treatment planning. As another example, when the interface program is used for machine control, the interface program can be executed by the control program of the radiotherapy device 120i. As another example, if the interface program is configured for the data exchange of integrated electronic health records, the interface program can be retrieved and executed on the clinic computer 120a, the clinic server 120c, or the clinic database 120d that hosts the electronic health record.

[0066] The interface can include data exchange and integration APIs (“data APIs”). The data APIs are capable of seamless data exchange and integration between the computing devices of the clinical network computing system 100 or the clinical system resources 120. The data APIs can support and execute, for example, FHIR standards or other proprietary protocols. The data APIs executed by the integration program 111 or the clinical system resource 120 facilitate the interoperability between the hardware or software clinical system resources 120. For example, the data APIs can transform or convert data formats to transfer data inputs and data outputs between the clinical system resources 120.

[0067] The interface can include script APIs implemented by the clinical system resource 120 or the integration program 111. The script APIs of the clinical network computing system 100 include, for example, software libraries and programming interfaces for accessing treatment planning information within a healthcare script application service (e.g., ). In some embodiments, the script APIs of the clinical network computing system 100 provide the same functions as typical script API implementations and can also include an additional executable layer for identification and authorization, which is customized for use by the hardware and software of the clinical system resources 120 produced by various enterprise-level third-party vendor products. Some embodiments of the script APIs may be intended for heterogeneous third-party vendor products, while some embodiments of the script APIs are designed for previously proven or vendor-specific products.

[0068] The QA API can be executed by the integration program 111 or the clinical system resources. The QA interface can simplify the integration process for different QA objects in the clinical network computing system 100. When combining the functions of various clinical system resources 120 from the clinical network computing system 100, the QA interface can be used, for example, to verify data quality, thereby beneficially enhancing scalability, availability, and efficiency.

[0069] The MMI can transform and verify the motion data and position data exchanged between the radiotherapy device 120i and the treatment sensors 120f - 120h (e.g., cameras). The treatment sensors 120f - 120h can transmit various types of data related to the patient's position and motion to a control processor or computing device that controls the operation of the radiotherapy device 120i, and the control processor or computing device can invoke or execute the MMI to ingest the motion information and position information into a format compatible with the radiotherapy device 120i.

[0070] Clinical system resources 120 (e.g., medical imaging device 120e, radiotherapy device 120i) and / or the integration program 111 can implement and apply the Digital Imaging and Communications in Medicine (DICOM) standard for transferring image data. In some cases, the DICOM Radiation Therapy (RT) interface specifies data structures or objects designed specifically for radiotherapy. The integration program 111 provides various communication interface operations between the various clinical system resources 120 of the clinical network computing system 100. For example, the Data API can be an interface that implements the DICOM or DICOM RT standard for data exchange. In some embodiments, the integration program 111 or other components of the clinical network computing system 100 implement an event subscription - publishing framework. The integration server 102 can receive and "publish" events as inputs received from the clinical system resources 120. The integration server 102 implements listeners or subscribers for events subscribed to the event framework. In some cases, the events include DICOM events (according to the DICOM data standard) published to the event framework by the clinical system resources 120 or the integration program 111.

[0071] In some cases, the interface includes a DB access API, which enables the clinical system resources 120 or the integration program 111 to generate SQL queries (e.g., select statements) and publish them to a database 120d that contains, for example, patient information or treatment information generated by the software applications of the clinical network computing system 100.

[0072] The integration program 111 performs an onboarding function when an administrator or a vendor introduces new or updated (hardware or software) clinical system resources 120 into the clinical network computing system 100. The onboarding function can include, for example: authenticating the clinical system resources 120 as having the privilege or access rights to access the closed network 130; verifying the license of the clinical system resources 120, which authorizes the clinical system resources 120 to access and retrieve the interface programs and / or computing resources of the clinical network computing system 100; and testing and validating the interoperability of the clinical system resources 120 of the clinical network computing system 100 with other computing resources and other potential functions.

[0073] The integration program 111 can verify the license data associated with the clinical system resources 120. The license data authorizes the clinical system resources 120 to access the clinical network computing system 100, including the integration operations of the integration program 111. The integration program 111 authorizes the clinical system resources 120 based on the license data and authorizes the clinical system resources 120 to access various functions of the integration program 111 or the clinical system resources 120, including interface programs or events (e.g., DICOM events). During the onboarding process (or other integration processes), the integration program 111 can obtain (e.g., retrieve, receive) license inputs containing the license data from the clinical system resources 120. The integration program 111 can verify the claimed license data of the clinical system resources 120 against the pre-stored expected license data, where the expected license data can be stored in the integration database 103 or the integration server 102 and can be accessed by the integration program 111.

[0074] As an example, during the onboarding process or at login, the clinical system resources 120 can call a license verification interface and submit the claimed license data for the specific clinical system resources 120 to the integration program 111. The integration program 111 can use the claimed license data obtained from the clinical system resources 120 to perform (or instruct the integration server 102 to perform) a license verification operation for the clinical system resources 120. The license verification operation of the integration server 102 can, for example, compare the claimed license data with the pre-stored expected license data for the clinical system resources 120. If the integration server 102 successfully verifies the license of the clinical system resources 120, the integration server 102 can grant a set of access privileges or rights to the specific clinical system resources 120 to access other computing resources of the clinical network computing system 100. During the onboarding process, the integration program 111 verifies whether the clinical system resources 120 are a newly verified version of the clinical system resources 120. In this way, in some cases, the onboarding process can usefully ensure that the developed commercial interfaces can be deployed and maintained for the clinical system resources 120 that have previously established interoperability as part of the clinical system 100.

[0075] In some embodiments, the interface program includes instructions for causing the clinical system resource 120 to provide licensing data when the clinical system resource 120 invokes a particular interface program. The interface program can, for example, request purported licensing data and confirm the purported licensing data against stored expected licensing data (e.g., a license key), where the expected licensing data can be stored in the integration server 102 or the integration database 103 (or another non-transitory storage medium of the clinical network computing system 100).

[0076] The integration program 111 can perform an authentication operation or implement an interface program that performs an authentication operation for authenticating the clinical system resource 120. For example, the clinical system resource 120 or the integration program 111 can invoke the authentication operation and request authentication information from the clinical system resource 120. The authentication operation can be performed by another clinical system resource 120 or the integration server 102 (or any other computing device of the clinical network computing system 100) using the purported authentication data received from the clinical system resource 120. The authentication operation can authenticate the access rights of the clinical system resource 120 and specific access privileges for accessing specific resources of the clinical network computing system 100. Authentication

[0077] During the onboarding process for the clinical system resource 120, the integration program 111 can determine the authentication protocol implemented by the clinical system resource 120 and select a corresponding authentication interface based on the authentication protocol. The integration program 111 can store the authentication protocol information for the clinical system resource 120 in the verified version record of the integration database 103. Additionally or alternatively, the integration program 111 can store the selected authentication interface for the clinical system resource 120 in the verified version record of the integration database 103. The clinical system resource 120 can invoke the authentication operation of the integration server 102 or other components of the clinical network computing system 100 by calling the assigned authentication interface of the integration program 111. The integration server 102 or other components of the clinical network computing system 100 can perform the authentication function according to the authentication protocol of the specific clinical system resource 120.

[0078] As an example, during the onboarding process or at login, the clinical system resource 120 can call the authentication interface and submit the claimed authentication credentials for the specific clinical system resource 120 to the integration program 111. The integration program 111 can use the claimed authentication credentials obtained from the clinical system resource 120 to perform (or instruct the integration server 102 to perform) an authentication operation for the clinical system resource 120. The authentication operation of the integration server 102 can, for example, compare the claimed authentication credentials with the pre-stored expected credentials for the clinical system resource 120. If the integration server 102 successfully authenticates the clinical system resource 120, the integration server 102 can grant the specific clinical system resource 120 a set of access privileges to access other computing resources of the clinical network computing system 100. During the onboarding process, the integration program 111 authenticates the clinical system resource 120 as a newly verified version of the clinical system resource 120.

[0079] In some embodiments, the authentication operation issues and references a security token stored at the clinical system resource 120 or other non-transitory storage medium. The authentication operation issues a security token to the clinical system resource 120 to prove that the clinical system resource 120 has been previously authenticated. After successfully authenticating a specific clinical system resource 120, the integration server 102 (or other devices of the clinical network computing system 100) provides the security token to the authenticated clinical system resource 120. Other clinical system resources 120 and / or the integration server 102 can send a challenge request to the clinical system resource 120, where the challenge request instructs the clinical system resource 120 to respond with the security token to prove that the clinical system resource 120 has been previously authenticated and is granted permission to access the computing resources of the clinical network computing system 100.

[0080] In some cases, the authentication operation, the integration server 102, the integration program 111, or other computing resources of the clinical network computing system 100 can deny or revoke the access privileges of the clinical system resource 120. The authentication operation can deny access privileges when the clinical system resource 120 fails to return authentication data or a security token that can successfully authenticate the clinical system resource 120. The authentication operation (or other components of the clinical network computing system 100) can revoke the previously granted access privileges of the clinical system resource 120 in response to an administrator input from the administrator computer 152 or in response to detecting a trigger condition. Non-limiting examples of trigger conditions can include detecting a change in the current version of the clinical system resource 120 compared to the verified version in the integration database 103, receiving incorrect authentication data or a security token in response to an authentication challenge request, or receiving incorrect permission data in response to a permission challenge request, and other trigger conditions.

[0081] Optionally, the integration program 111 performs operations for testing and validating the interoperability of the clinical system resources 120. Before the integration program 111 grants access privileges to a particular clinical system resource 120, the integration program 111 may perform test operations during the onboarding or update process. In some cases, it may be customary to conclude clinical interoperability testing on a particular (new or updated) version of the clinical system resource 120 before deploying and implementing the version control features and functions described herein within the clinical system 100. Thus, when deploying this (new or updated) version of the clinical system resource 120, the integration program 111 (or other components of the system 100) does not need to perform, conclude, and successfully validate interoperability test operations in real time. In some cases, successful interoperability (or inter-operability) tests are recorded / archived, and the deployment or testing can be concluded at a later time using the recorded / archived output stored in the non-transitory storage medium of the computing system 100. The appropriate commercial license is then updated / released. The test operations may implement one or more test methods, such as test script methods, data exchange tests, interface tests, conformance tests, and integration tests, as well as other potential test methods.

[0082] In the test script method, the integration program 111 launches a script program containing a particular test scenario such that the clinical system resource 120 uses data inputs or data outputs defined in the script to simulate real-world scenarios, where these data inputs or data outputs require computing resources (e.g., the integration program 111, the clinical system resource 120, the interface) to implement interoperability features (e.g., data format conversion). The integration program 111 may monitor and evaluate the data communication between the clinical system resource 120 and other clinical system resources 120 to determine whether the clinical system resource 120 interacts effectively. For example, the script includes a set of instructions simulating various user interactions with the clinical system resource 120. The script may define, for example, the exact operations to be performed by the clinical system resource 120 (or other components of the clinical network computing system 100), the expected responses from the clinical system resource 120, and the particular data to be used by the clinical system resource 120 for testing. The integration program 111 may record the output generated by the clinical system resource 120 in the non-transitory memory of the integration server 102 (or other device) and compare the test output with the expected output. The integration program 111 may identify and indicate any differences between the expected results and the actual results as potential defects in the interoperability function of the clinical system resource 120.

[0083] In an optional data exchange test method, the integration program 111 checks whether the clinical system resources 120 can accurately and seamlessly exchange data. The integration program 111 instructs the clinical system resources 120 (e.g., using a data API) to send data to another clinical system resource 120, and determines whether the data is output or received as expected, or whether the data remains intact and unchanged according to the expected format. As an example, the integration program 111 can evaluate whether the output or transmission of clinical data in XML format from the clinical system resources 120 or the data API follows the expected standards or formats.

[0084] In an optional interface test method, the integration program 111 instructs the clinical system resources 120 to invoke one or more interfaces. Interface testing is used to ensure that different clinical system resources 120 can communicate effectively with each other. The integration program 111 can determine, for example, whether the interface produces the correct transmission or response during the communication between the clinical system resources 120. The integration program 111 evaluates, for example, the invocation of the interface by the clinical system resources 120 and the output generated by the interaction between the clinical system resources 120 and the interface. The integration program 111 verifies whether a particular clinical system resource 120 is configured to effectively access and use the interface (e.g., a data API for communication and data exchange) assigned to the clinical system resource 120. For example, the integration program 111 can define test cases in a script and instruct the clinical system resources 120 or the interface to execute the test cases. The integration program 111 can analyze the results. The integration program 111 can use the interface to identify any problems in the interaction between the clinical system resources 120, such as data loss, incorrect data transmission, or problems with request and response routines.

[0085] In an optional conformance test method, the integration program 111 instructs the clinical system resources 120 to generate various outputs, for example. The integration program 111 then evaluates the outputs to determine whether the clinical system resources 120 comply with the expected formats, standards, and protocols required by the clinical network computing system 100. There are other forms of testing the interoperability of the clinical system resources 120 or other resources (e.g., interface programs).

[0086] The integration program 111 can determine whether a test case for a specific computing resource (e.g., an interface, a clinical system resource 120) fails or passes based on comparing the actual output with the expected output defined in a test script or other pre-configured data values. The integration program 111 can verify and validate a specific clinical system resource 120 or interface in response to determining that the clinical system resource 120 has successfully passed the (multiple) test cases applied by the integration program 111. Alternatively, the integration program 111 can compare the actual output with the expected output to identify any differences. The integration program 111 can verify and validate the clinical system resource 120 or interface in response to determining that the amount of difference meets a difference failure threshold (sometimes referred to herein as an "interoperability test threshold"). The integration program 111 can store the current version of the successfully verified clinical system resource 120 in the integration database 103 as the verified version of the clinical system resource 120.

[0087] In some embodiments, the integration program 111 can be executed by the integration server 102 or an end-user device (e.g., an administrator computer 152) to test and verify the interoperability of a new clinical system resource 120 under development. The integration program 111 can implement various test methods, such as the test methods described above. The integration program 111 can verify that the new clinical system resource 120 is interoperable. The developer can release the new clinical system resource 120 in the market as a new product. Alternatively, the developer can instruct the integration program 111 to store the current version of the new clinical system resource 120 in the integration database 103 as the verified version of the new clinical system resource 120. In this way, the developer can test and verify the clinical system resource 120 product before providing the product to the public, or the developer can test and verify an in-house developed clinical system resource 120 product before placing the product into the clinical network computing system 100. In some implementations, the integration program 111 refers to the metadata of the new clinical system resource 120 to confirm whether the new clinical system resource 120 has been previously verified as being interoperable.

[0088] The integration program 111 or other components of the clinical network computing system 100 (e.g., the integration server 102, an interface program) can implement a version control function to manage changes to the clinical system resources 120 of the clinical network computing system 100. The integration database 103 includes database records that contain various types of version or component information about the verified versions of the clinical system resources 120. The version control function can compare the data output generated or the functions performed by the clinical system resource 120 with the corresponding version information of the verified version in the integration database 103.

[0089] Reference Figure 1B, an example embodiment includes a radiotherapy device 120i that receives and analyzes data inputs from treatment sensors 120f - 120h for Surface Guided Radiation Therapy (SGRT). The radiotherapy device 120i includes a control device having a processor, where the processor adjusts a radiation beam based on sensor data received from the treatment sensors 120f - 120h. The treatment sensors 120f - 120h include cameras from multiple vendors that generate sensor data in the form of media image data according to multiple media data formats. The clinical system resource 120 can be, for example, a product from the same or a different vendor as the vendor of the treatment sensors 120f - 120h, or implement the same or different data formats of the treatment sensors 120f - 120h. In this way, the treatment sensors 120f - 120h and the radiotherapy device 120i represent heterogeneous clinical system resources 120.

[0090] The SGRT function of the treatment sensors 120f - 120h (e.g., cameras) is used for motion management in radiotherapy to track and capture the patient's motion during radiotherapy. The radiotherapy device 120i receives measurement outputs from the treatment sensors 120f - 120h and adjusts, for example, beam angle, dose, or other parameters of the treatment. The treatment sensors 120f - 120h and / or the radiotherapy device 120i can be products from multiple vendors with multiple data formats or functions. The radiotherapy device 120i can receive data inputs from the treatment sensors 120f - 120h and invoke a Motion Management Interface (MMI) to ingest, standardize, and / or analyze motion information and position information in the input data. The MMI in radiotherapy includes software programming that helps, for example, continuously track the position and movement of the patient's tumor or the patient in real time, so that the radiotherapy device 120i can deliver accurate and precise radiation to the patient's tumor while minimizing radiation exposure to healthy tissue. In the context of interoperability or other clinical functions, the MMI programming acts as a conversion bridge API to allow different clinical system resources 120 (e.g., multiple treatment sensors 120f - 120h) to access and exchange motion data, for example. For example, the SGRT software application controlling the radiotherapy device 120i can exchange data with the treatment sensors 120f - 120h by invoking the MMI in the integration program 111 or the integration database 103.

[0091] Figure 2 Operations of a method 200 for joining and hosting clinical system resources at a clinical computing system architecture of multiple local computing resources with a closed computing network are shown.

[0092] Embodiments may include additional or alternative operations, or omit certain operations from the operations of method 200, and still fall within the Figure 2 description thereof. Additionally, the operations of method 200 are described as being performed by a server of a clinical network computing system coupled to a closed network, although embodiments are not limited thereto. Any number of additional or alternative computing devices of the clinical network computing system and the closed network may perform the operations of the method.

[0093] In operation 202, the server receives a join or access request from a clinical system resource seeking access to the closed network and computing resources (e.g., interface functionality). The request seeks access to the clinical system resource.

[0094] In operation 204, the server performs an authentication operation for authenticating the clinical system resource. The server obtains authentication information associated with the clinical system resource, and the authentication information may include claimed authentication credentials and an authentication protocol. The server may perform the authentication operation by exchanging challenge requests and response messages through an authentication operation of an interface program (e.g., API) with the clinical system resource. The server authenticates the clinical system resource based on comparing the claimed authentication data with stored expected authentication credentials. Granted,

[0095] In operation 206, the server performs test and verification operations for verifying whether the clinical system resource is an interoperable resource according to the interface program used by the clinical system resource. Before the integration program 111 grants access privileges to a specific clinical system resource 120, the server may perform test operations during the join or update process. The test operations may implement one or more test methods, such as test script methods, data exchange tests, interface tests, conformance tests, and integration tests, as well as other potential test methods. The integration program 111 may identify and indicate any differences between the expected results and the actual results as potential defects in the interoperability functionality of the clinical system resource 120.

[0096] The integration program may determine whether a test case of a specific computing resource (e.g., interface, clinical system resource) fails or passes based on comparing the actual output with the expected output defined in a test script or other preconfigured data values. The integration program may verify and confirm a specific clinical system resource or interface in response to determining that the clinical system resource successfully passes the (multiple) test cases applied by the integration program. Alternatively, the integration program may compare the actual output with the expected output to identify any differences. The integration program may verify and confirm the clinical system resource 120 or interface in response to determining that the amount of difference meets a difference amount failure threshold. The integration program may store the current version of the successfully verified clinical system resource into the integration database as the verified version of the clinical system resource.

[0097] In operation 208, the server performs a verification operation for verifying license data associated with a clinical system resource. The server sends a challenge request message to the clinical system resource to request license data (e.g., software key, API key). Alternatively, the server queries the database for the license data. The server may receive claimed license data associated with the clinical system resource and compare the claimed license data with the stored expected license data. Based on comparing the claimed license data with the stored expected license data, the server may verify the clinical system resource as a licensed instance or a licensed component of the clinical network computing system.

[0098] In operation 210, the server grants access to the clinical system resource based on verifying (as in operation 208), authenticating (as in operation 204), and validating (as in operation 206) the clinical system source. In operation 212, the server stores a set of resource configurations into a database record representing a verified version of the clinical system resource.

[0099] Optionally, in operation 214, the server revokes access to the clinical system resource. The server may revoke access in response to determining that a new version of the clinical system resource seeks access to the computing resources of the clinical network computing system. The server may also revoke access in response to determining that the clinical system resource is invalid, not authenticated, or not validated as interoperable.

[0100] The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure or the claims.

[0101] Embodiments implemented in computer software may be implemented using software, firmware, middleware, microcode, hardware description language, or any combination thereof. Code segments or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0102] The actual software code or dedicated control hardware used to implement these systems and methods does not limit the claimed features or this disclosure. Accordingly, the operation and behavior of the systems and methods have been described without reference to specific software code, it being understood that the software and control hardware can be designed to implement the systems and methods based on the description herein.

[0103] When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of the methods or algorithms disclosed herein may be embodied in a processor-executable software module, where the processor-executable software module may reside on a computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one location to another. The non-transitory processor-readable storage medium may be any available medium accessible by a computer. By way of example and not limitation, such non-transitory processor-readable media may include RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), CD-ROM (Compact Disc Read-Only Memory) or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that can be used to store the desired program code in the form of instructions or data structures and that is accessible by a computer or a processor. Disk and optical disks as used herein include compact disk (CD), laser disk, optical disk, digital versatile disk (DVD), floppy disk, and Blu-ray disk, where disks typically reproduce data magnetically, while optical disks reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or collection of code and / or instructions and / or code and / or instructions on a non-transitory processor-readable medium and / or a computer-readable medium that can be incorporated into a computer program product.

[0104] The foregoing description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the embodiments described herein and their variations. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the principles defined herein may be applied to other embodiments without departing from the spirit or scope of the subject matter disclosed herein. Accordingly, the present disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

[0105] Although various aspects and embodiments have been disclosed, other aspects and embodiments are also contemplated. The various aspects and embodiments disclosed are for illustrative purposes and not intended to be limiting, where the true scope and spirit are indicated by the appended claims.

Claims

1. A computer method for hosting resources in a computing network, comprising: Obtaining, by a computer of the computing network, authentication information associated with a clinical system resource of the computing network, the authentication information including claimed authentication data and an authentication protocol, wherein the clinical system resource generates at least one attribute of patient treatment; Authenticating, by the computer, the clinical system resource based on comparing the claimed authentication credentials with stored expected authentication credentials; Identifying, by the computer, one or more interface programs for the clinical system resource to exchange the at least one attribute of the patient treatment with a software application of a clinical therapy machine; Verifying, by the computer, that the clinical system resource is an interoperable resource in response to determining that the clinical system resource meets one or more interoperability test thresholds corresponding to one or more interoperability test operations using the one or more interface programs; and Storing, by the computer, a set of resource configurations in a database record representing the verified version of the clinical system resource, the set of resource configurations including a list of functional outputs for the clinical system resource, the authentication protocol, and a list of the one or more interface programs.

2. The method according to claim 1, further comprising: Obtaining, by a computer, claimed license data associated with the clinical system resource; And Verifying, by the computer, the clinical system resource based on comparing the claimed license data with stored expected license data.

3. The method according to claim 2 further comprises: Granting, by the computer, access rights to the clinical system resource for performing the one or more interface programs based on authenticating, verifying, and validating the clinical system resource.

4. The method according to claim 3, further comprising: Transmitting, by the computer, a security token to the clinical system resource, the security token indicating the access rights granted to the clinical system resource.

5. The method according to claim 1 further comprises: Generating, by the computer, a notification indicating a new version of the clinical system resource for an end-user device in response to identifying a change in at least one of the function list or the authentication protocol compared to the verified version of the clinical system resource.

6. The method according to claim 1, further comprising: Revoking, by the computer, the access rights granted to the clinical system resource for performing the one or more interface programs in response to identifying a new version of the clinical system resource based on a change in at least one of the function list or the authentication protocol compared to the verified version of the clinical system resource.

7. The method according to claim 1, wherein the one or more interface programs include at least one of a data exchange and integration application programming interface (API), a healthcare scripting API, a quality assurance (QA) API, a database access API, a motion management interface (MMI), or a Varian treatment interface. ​ 8. The method according to claim 1, wherein determining that the clinical system resource meets one or more interoperability test thresholds includes: Performing, by the computer, interoperability test operations for an interface program to generate one or more test outputs; And Determining, by the computer, a test difference for comparison with the interoperability test threshold based on comparing the one or more test outputs with one or more expected outputs for the interoperability test operations.

9. A system for hosting resources in a computing network, comprising: A database of the computing network, the database being configured to store a plurality of database records for a plurality of verified versions of a plurality of clinical system resources; And The server of the computing network, the server including a processor and configured to: Obtain authentication information associated with the clinical system resources of the computing network, the authentication information including claimed authentication credentials and an authentication protocol, wherein the clinical system resources generate at least one attribute of patient treatment; Authenticate the clinical system resources based on comparing the claimed authentication credentials with stored expected authentication credentials; Identify one or more interface programs for the clinical system resources to exchange the at least one attribute of the patient treatment with a software application of a clinical therapy machine; Verify that the clinical system resources are interoperable resources in response to determining that the clinical system resources meet one or more interoperability test thresholds corresponding to one or more interoperability test operations using the one or more interface programs; And Store a resource configuration set in a database record of the database, the database record representing a verified version of the clinical system resources, the resource configuration set including a list of functional outputs for the clinical system resources, the authentication protocol, and a list of the one or more interface programs.

10. The system according to claim 9, wherein the server is further configured to: Obtain claimed license data associated with the clinical system resources; and Verify the clinical system resources based on comparing the claimed license data with stored expected license data.

11. The system according to claim 10, wherein the server is further configured to: Grant access rights to the clinical system resources for executing the one or more interface programs based on authenticating, verifying, and validating the clinical system resources.

12. The system according to claim 11, wherein the server is further configured to: Transmit a security token to the clinical system resources, the security token indicating the access rights granted to the clinical system resources.

13. The system according to claim 9, wherein the server is further configured to: Generate a notification indicating a new version of the clinical system resources for an end-user device in response to identifying a change in at least one of the function list or the authentication protocol compared to the verified version of the clinical system resources.

14. The system according to claim 9, wherein the server is further configured to: Revoke the access rights granted to the clinical system resources for executing the one or more interface programs in response to identifying a new version of the clinical system resources based on a change in at least one of the function list or the authentication protocol compared to the verified version of the clinical system resources.

15. The system according to claim 9, wherein the one or more interface programs include at least one of a data exchange and integration application programming interface (API), a healthcare scripting API, a quality assurance (QA) API, a database access API, a motion management interface (MMI), or a Varian treatment interface. ​ 16. The system according to claim 9, wherein when it is determined that the clinical system resources meet one or more interoperability test thresholds, the server is configured to: Perform interoperability test operations on the interface programs to generate one or more test outputs; and Determine a test difference for comparison with the interoperability test thresholds based on comparing the one or more test outputs with one or more expected outputs for the interoperability test operations.

17. A non - transitory computer - readable medium for a computing network, the non - transitory computer - readable medium being coupled to one or more processors of the computing network and containing executable instructions that, when executed by the one or more processors, cause the one or more processors to: Obtain authentication information associated with clinical system resources of the closed computing network, the authentication information including claimed authentication credentials and an authentication protocol, wherein the clinical system resources generate at least one attribute of patient treatment; Authenticate the clinical system resources based on comparing the claimed authentication credentials with stored expected authentication credentials; Identify one or more interface programs for the clinical system resources to exchange the at least one attribute of the patient treatment with a software application of a clinical therapy machine; Verify that the clinical system resources are interoperable resources in response to determining that the clinical system resources meet one or more interoperability test thresholds corresponding to one or more interoperability test operations using the one or more interface programs; And Store a resource configuration set in a database record of a database, the database record representing the verified version of the clinical system resources, the resource configuration set including a list of functional outputs for the clinical system resources, the authentication protocol, and a list of the one or more interface programs.

18. The non - transitory computer - readable medium according to claim 17, wherein the executable instructions, when executed by the one or more processors, further cause the one or more processors to: Obtain claimed license data associated with the clinical system resources; and Verify the clinical system resources based on comparing the claimed license data with stored expected license data.

19. The non - transitory computer - readable medium according to claim 17, wherein the executable instructions, when executed by the one or more processors, further cause the one or more processors to: Grant access rights to the clinical system resources for executing the one or more interface programs based on authenticating, verifying, and validating the clinical system resources; and Transmit a security token to the clinical system resources, the security token indicating the access rights granted to the clinical system resources.

20. The non - transitory computer - readable medium according to claim 17, wherein the executable instructions, when executed by the one or more processors, further cause the one or more processors to: Revoke the access rights granted to the clinical system resources for executing the one or more interface programs in response to identifying a new version of the clinical system resources based on a change in at least one of the function list or the authentication protocol compared to the verified version of the clinical system resources.

Images