Efficient caching for radiotherapy subject visualization and processing

Abstract

A system and technique may be used for radiotherapy data visualization. An example method may include determining a data set corresponding to visualization data to be displayed in an application user interface (e.g., on a client device). The data set may include one or more medical digital imaging and communication (DICOM) objects. A request for a data set may be received at an application interface (API) configured to access a plurality of sources of a DICOM object. The method may include processing the requested dataset, verifying the request for the dataset, and upon verification, providing access to the processed dataset to a client device to enable visualization of the processed dataset. The processed data set may be cached, and access to the cached processed data may be provided to a verification request to the same data set for visualization at the same or different client devices.

Description

Background Art

[0001] Radiation therapy (RT) or "radiotherapy" can be used to treat cancer or other diseases in mammalian (e.g., human and animal) tissue. The processing of RT or medical imaging data objects is typically performed by software applications. Users of different RT software applications may be interested in visualizing the same underlying data. An RT visualizer can manage or process patient health information (PHI), for example, when a visualizer renders data from a Digital Imaging Communication in Medicine (DICOM) file, PHI can be provided from the DICOM file as a DICOM object. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] In the drawings, which are not necessarily drawn to scale, like numbers throughout the several views describe substantially similar parts. Like numbers with different letter suffixes represent different instances of substantially similar components. The drawings generally illustrate various embodiments discussed in this document by way of example and not by way of limitation.

[0003] Figure 1 An example of an end-to-end data flow for authorizing a radiation therapy data visualization request is shown.

[0004] Figure 2A and Figure 2B A visualization sequence for radiation therapy visualization is shown.

[0005] Figure 3 An exemplary data flow for retrieving cached data is shown.

[0006] Figure 4 An exemplary method of radiation therapy visualization is shown.

[0007] Figure 5 is a block diagram of an example of an apparatus, device, or machine on which any one or more of the techniques (eg, methodologies) discussed herein may be performed. DETAILED DESCRIPTION

[0008] In the following detailed description, reference is made to the accompanying drawings which form a part of the present invention, which are shown by way of exemplary embodiments of the technology disclosed in the present invention. These embodiments, also referred to herein as "examples", are described in sufficient detail to enable those skilled in the art to practice the present invention, and it should be understood that these embodiments may be combined, or other embodiments may also be utilized, and structural, logical or other changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not restrictive, and the scope of the present disclosure is defined by the appended claims and their equivalents.

[0009] The systems and techniques described herein can be used for radiation therapy visualization. For example, a data set corresponding to visualization data to be displayed in an application user interface on a programming device can be determined. The data set can include one or more medical imaging objects, such as one or more Digital Imaging and Communications in Medicine (DICOM) data objects (referred to herein as "DICOM objects"). DICOM objects can include special attributes that contain image pixel data. Modality attributes typically describe the type of image data captured from a patient (e.g., computed tomography (CT) scans, etc.). DICOM objects can be real-world information entities that include information such as patient data, imaging studies, medical equipment, doctor visits, documents, diagnostic interpretations, and the like. DICOM objects can include multiple attributes, including items such as the patient's name or other identifying information.

[0010] A request for a data set may be received at an application programming interface (API) configured to access multiple sources of DICOM objects and / or operating in an environment including multiple sources of DICOM objects (e.g., multiple databases containing DICOM objects). The environment may include multiple sources of DICOM objects and include a multi-application and / or multi-tenant environment (e.g., on the client side and / or server side). The requested data set may be processed, which may include optimizing the requested data set. Optimizing the requested data set may include optimizing the requested data set for visualization (at the client device) without visualizing or visually rendering the data set at the device or server that processes the requested data. For example, pixel data may be extracted from one or more DICOM objects in the requested data set to remove personal health information or other identifying information before providing access to the processed data to the client device. Thus, data may be extracted from the DICOM tags and placed in a JSON object that may be parsed in a web-based client application. Optimizing the requested data set for visualization without visualizing or rendering the requested data set has the effect of making the data set more suitable for downstream streaming (e.g., use on different client devices) and for caching the requested data at the server level and the client level. The anonymized and optimized (processed) data can be rendered by the client device without using additional server-level resources.

[0011] A security key corresponding to one or more DICOM objects can be created. A request for a data set at an API can include a security key that can be unique to the API request and only allows access to a specific combination of one or more DICOM objects in the data set. When the API request is received (e.g., at a server), the security key can be verified to confirm that the security key corresponds to the requested data set. In one example, a security key for a JSON Web Token (JWT) can be provided. In order to verify that the security key corresponds to the requested data set, the API can use a public key to verify the JWT. The public key can be configured to verify that the client device is a valid source of the requested data set and to verify that the requested data set has not been modified or corrupted when transmitted from the client device.

[0012] The RT visualizer can rely on a caching mechanism to ensure optimal performance and minimize duplication of processed data, as well as to reduce or minimize processing time. Thus, the optimized dataset can be cached (e.g., on the server side or at the server level), and the API can retrieve the requested dataset from the cached data source. A second request for the dataset can be sent to the API, for example, from a second client device. The second request can include a second security key. In response to verification that the second security key corresponds to the requested dataset, access to the cached optimized dataset for visualization or rendering can be provided to the second client device (without having to process the dataset a second time).

[0013] In other RT visualization systems, the processed result data can be reused between user sessions within an application, but cannot be reused between different applications or devices because the processed data is usually in a proprietary format known only to the application performing the processing. Therefore, if the same data needs to be accessed by multiple applications or client devices, the same data needs to be processed for each application or user session. Reprocessing data multiple times may result in increased costs in data storage and processing. The currently claimed system and method introduce a caching mechanism to optimize data and reduce, reduce or minimize the repetition and processing time of processing data. Using the currently disclosed system and method, the data to be visualized will only need to be processed once (unless the cache is unavailable) and can be accessed across multiple sessions and / or multiple devices when the verification device is authorized to visualize the processed data.

[0014] RT Visualizer Transcoder can work in a multi-tenant and multi-application environment. RT Visualizer has unrestricted access to the underlying data sources that contain data from different applications and tenants. It is important that only client-side participants are allowed to view the data they are authorized to view. A normalized digest can be calculated for each request to visualize one or more DICOM objects, and the digest payload can be signed with a private key to produce a JSON Web Token. The digest can encode an identifier of the data source (e.g., a network drive or cloud storage location where the data can be found) and a unique and unchanging data identifier within that source. The RT Visualizer Transcoder Server can use the public key to verify the token, decode the token to extract the digest, and calculate its own digest to compare with the digest encoded into the token. This process verifies what data the token corresponds to and confirms that the request is valid for the data that the client device is looking for (e.g., the client device is authorized to access the data).

[0015] Upon successful authentication, the transcoder server can check whether the requested data has already been processed and stored in the cache. If the requested data is not available in the cache, the requested data can be extracted, processed, and stored in the cache. Once the data is stored in the cache, the stored data can be provided to any device or application based on the authentication process. The data in the cache can be safely evicted at any time. When data in the cache is evicted, a request for the evicted data will require the data to be extracted, processed, and stored in the cache again.

[0016] Thus, the systems and methods of the present invention represent an improvement over prior RT visualization techniques that utilized the cloud to process data for reuse across different user sessions (by the same application), but did not process data to be used across multiple applications. The currently disclosed systems and methods support reuse of processed data, which avoids the need to use computing resources to recalculate data for each application. In addition, storage space is preserved because the processed data may only need to be stored once (as opposed to once per application). This results in lower latency for end users when the system has already cached the requested data. Since the processed data being used by each application is the same, the visualization can also be consistent from application to application. This has the additional advantage of standardizing the visualization pipeline between applications and servers while keeping unrelated application-specific aspects separate.

[0017] Figure 1 An example of an end-to-end data flow (data flow 100) for authorization of a radiation therapy data visualization request is shown. As part of the data flow 100, the application backend 102 may include a data store 104 and one or more application programming interfaces (server-side APIs 106). The application backend 102 may determine the data to be displayed by the client and create a security key or private key 108. The private key 108 is unique to the server-side 106 request and only allows access to a specific combination of one or more DICOM objects in the data store 104. The private key 108 may be provided as a JSON Web Token (JWT). Therefore, authorization may be configured independently for each data source (e.g., each DICOM object) in the data store 104. This configuration may be implemented by specifying a security field in a configuration section associated with a particular source. The configuration may indicate a path to a public key (discussed below) for verifying any JWT provided to the client (and subsequently sent to the RT visualization converter (code converter server 110) discussed below). The JWT may be valid only for a specific data object and may not be used to reference any other data.

[0018] The purpose of the JWT includes allowing the transcoder server 110 to determine whether the carried JWT should be granted access to the requested data. In one example, the JWT can contain a list of all related data objects requested, however, for many DICOM data types (such as image sets), the list of related data items can be quite large (e.g., hundreds of items or more). In turn, the JWT associated with the request can become very large. In order to avoid creating large tokens, the JWT sent to the transcoder server 110 can contain a specific message summary with a hash of all the requested data. The summary can be calculated in the same manner on the application backend 102 server (which can determine whether the current user should access the requested data) and the transcoder server 110, which allows the transcoder server 110 to ensure that any data requested is authorized.

[0019] The process of generating a valid JWT can include the following operations:

[0020] Execute the JSON.strinfy() method on the entire data field from the client-side object. This data field may contain a list of images, structure sets, plans, doses, etc. to be visualized;

[0021] Generate a hash of the serialized data using the same hashing algorithm that will be used to hash the JWT (e.g., the RS256 signature algorithm);

[0022] Once the hash digest is generated, create a hexadecimal encoded string of the hash digest;

[0023] Create a JWT payload with data equal to the summary string; and

[0024] The JWT is generated using the private key 108 corresponding to the public key 112 configured for the target source.

[0025] In one example, all requests targeting any source of the authorization configuration require a valid JWT. The JWT can be provided as a bearer token. When utilizing the client-side RT visualization library 120, the token can be provided via a corresponding "add" method from the model.

[0026] The transcoder server 110 (server-side RT visualizer) may rely heavily on caching mechanisms to provide optimal performance. Data may only need to be processed once (unless evicted from the cache), and then the processed data can be provided to multiple applications or during multiple sessions. Since the transcoder server 110 does not need to retrieve cached data from the underlying data source, access control rules must be enforced when extracting data from the cache. Therefore, all data of an object must be bound to the object through a profile, which is inherent and unique to the object. An exemplary end-to-end data flow may include:

[0027] The application backend 102 may determine data that the client may display, such as on the client-side application user interface 114 , and create a corresponding bearer token including the private key 108 ;

[0028] The data reference and token may be passed or transmitted from the server-side API 106 to the renderer (controller 116) of the client-side application user interface 114. The controller 116 may in turn pass the data reference and token to the client-side RT visualization library 120;

[0029] The data reference and token may be passed or transmitted from the client-side RT visualization library 120 to the server-side RT visualization API 118 on or coupled to the transcoder server 110 ;

[0030] The transcoder server 110 may use the public key 112 to verify the authenticity of the JWT by ensuring that the request is from the correct tenant or client source (e.g., ensuring that the public-private key pair is unique), that the data claims have not been corrupted or modified in transit from the client-side RT visualizer library 120 to the server-side RT visualization API 118, and that the JWT is valid for or corresponds to the requested data;

[0031] Once the request is authenticated and the JWT is verified, the transcoder server 110 can use the verified credentials to connect to the data storage 104 and access the requested data. From there, the requested data can be cached (as described below) for visualization for subsequent requests.

[0032] Figure 2A and Figure 2B A visualization sequence for radiotherapy visualization is shown. Figure 2A As shown, the first client application 200 may send a data request including data identification information to an RT visualizer 204, a renderer, etc. The RT visualizer 204 may be implemented on a server, such as Figure 1RT visualizer 204 may send a request for metadata to transcoder 206. The metadata may include one or more DICOM objects or other medical imaging data or patient data. When visualizing patient data for the first time, transcoder 206 may send a request to shared data source 208.

[0033] After the transcoder 206 obtains the data from the shared data source 208, the transcoder 206 can process the data and return the processed metadata to the RT visualizer 204 for visualization by the first client application 200. The processed data blocks can be stored in the cache 210 so that when a request comes from the second client application 202, the same data requested by the first client application 200 can be obtained from the cache 210. The data block can include several data to be extracted in order to render the requested content. That is, a request to visualize the same patient data can be sent from the second client application 202 to the RT visualizer 204. The RT visualizer 204 can try to extract the metadata from the transcoder 206 again, but because the data has already been processed and cached, the processed metadata (data block) can be immediately returned to the RT visualizer 204 from the cache 210 for visualization by the second client application 202. Therefore, the request from the second client application 202 for the same data requested by the first client application 200 will not need to be extracted from the shared data source 208 and processed a second time by the transcoder 206. Thus, any subsequent requests for processed data may be sent from cache 210 for download and visualization by the client device, thus saving computing resources of the server as long as cache 210 is not cleared.

[0034] like Figure 2B As shown in the example of , the first client application 200 can retrieve data identification information from the first application server 212 and then send a request to the RT visualizer 204. Similarly, the second client application 202 can retrieve data identification information from the second application server 214 and then send a request for data to the RT visualizer 204. Once the application receives the data identification information from the corresponding server, the process can continue, as shown in FIG. Figure 2A Depicted.

[0035] Figure 3 An exemplary data flow for retrieving cached data is shown. Figure 3 In the example shown, the RT visualizer 300 (eg, Figures 1 to 2B306. Figure 1 The token discussed is the same and includes the private key 108. Decoding the JWT can include ensuring that the request is from the correct client or tenant source (e.g., the private / public key pair is unique) and ensuring that the data claims (GET request) have not been modified, altered, or otherwise corrupted while in transit from the client. Once the JWT is decoded and the information is verified, the RT visualizer transcoder 304 can access the requested processing data from the cache 308.

[0036] Figure 4 An exemplary method of radiotherapy visualization is shown. Method 400 may include or comprise a plurality of operations (402-412). These operations are merely examples, and the method performed may omit one or more of the listed operations, may repeat operations, may include other operations, or may perform operations simultaneously, substantially simultaneously, or in another order, as circumstances or desires require. The operations may be automatically performed by a processor or controller of a machine or computer, such as the following for Figure 5 as described.

[0037] At operation 402, method 400 may include determining a data set corresponding to visualization data to be displayed in an application user interface on a client device. The data set may include one or more medical imaging objects, such as one or more DICOM objects, patient data, or other patient information. At operation 404, method 400 may include receiving a request for the data set at an application programming interface (API). The API may be configured to access multiple sources of DICOM objects, such as multiple databases or data storage devices. The environment may include multi-tenant applications and multi-tenant environments. A security key corresponding to the DICOM object may be generated. The security key may be unique to the API request and may only allow access to a specific combination of one or more DICOM objects in the data set.

[0038] A security key for a JSON web token (JWT) may be provided. The security key may include a message summary. The message summary may include a hash generated from a list of DICOM objects. For example, a hash may be generated from a list of images to be visualized (e.g., radiotherapy images, computed tomography (CT) images, magnetic resonance (MR) images, etc.), one or more spatially registered objects, a set of structures, a radiotherapy plan, and / or a radiotherapy dose.

[0039] At operation 406, method 400 may include processing the requested data set. Processing the requested data set may include removing identification information of the patient. Removing the identification information may include removing or extracting pixel data from one or more DICOM objects. For example, when personal and / or identification information is burned on an image such as a CT scan, pixels with identification information may be extracted during processing. In addition, processing the requested data set may include optimizing the requested data set for visualization, rather than visualizing or visually rendering the requested data set at the API. Such processing of the requested data set may allow for efficient use of the data set on different client devices, and for caching the requested data set at the client level and the server level.

[0040] At operation 408, method 400 may include verifying the requested data set, and operation 410 may include providing the client device with access to the processed data set. For example, the requested data set may be verified by verifying that the security key corresponds to the requested data set. As part of this verification, the API may verify the JWT using the public key. The public key may verify that the client device is a valid source of the requested data set, and verify that the requested data set has not been modified or corrupted when transmitted from the client device. Thus, the API may verify the private key-public key pair and verify that the security key corresponds to the requested data. Once the requested data and security key are verified, the client device may be allowed to render the processed data set in an application user interface of the client device or on the client device.

[0041] At operation 412, method 400 may include caching the processed data set. The cached data set may be stored in a memory of the server, or in a database coupled to the server. Once the data set is cached, when submitted and verified through the process discussed above, a client device or a second client device that has access to the cached data set may be provided with a request to visualize the same processed data (e.g., a second request). It should be understood that operations 410 and 412 may be performed in any order. For example, access to the processed data may be provided to the client device before the processed data is cached. Alternatively, the processed data may be cached and then access to the processed data from the cache may be provided to the client device.

[0042] Figure 5It is a block diagram of an example of an apparatus, device or machine 500, wherein any one or more techniques (e.g., methods) discussed herein can be performed on the apparatus, device or machine 500. In alternative embodiments, the machine 500 can operate as a standalone device, or can be connected (e.g., networked) to other machines. In a networked deployment, the machine 500 can operate in the capacity of a server machine, a client machine, or both in a server-client network environment. In one example, the machine 500 can act as or operate as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. The machine 500 can be a personal computer, a tablet computer, a set-top box, a personal digital assistant, a mobile phone, a network device, a network router, a switch or a bridge, or any machine capable of executing instructions (sequential or other) specifying the actions to be taken by the machine. In addition, although only a single machine is shown, the term "machine" should also be deemed to include any machine collection that executes a set (or multiple sets) of instructions to perform any one or more methods discussed herein, such as cloud computing, software as a service (SaaS), and other computer cluster configurations, either individually or jointly.

[0043] As described herein, examples may include logic or multiple components or mechanisms, or may be operated by logic or multiple components or mechanisms. A circuit group is a collection of circuits implemented in a tangible entity including hardware (e.g., simple circuits, gates, logic, etc.). Circuit group members may be flexible over time and underlying hardware variability. A circuit group includes components that can perform specified operations individually or in combination when in operation. In one example, the hardware of the circuit group may be immutably designed to perform or execute a specific operation (e.g., hard wiring). In one example, the hardware of the circuit group may include a variably connected physical component (e.g., an execution unit, a transistor, a simple circuit, etc.), which includes a computer-readable medium that is physically modified (e.g., magnetic, electrical, agglomerated particles are not moved, etc.) to encode instructions for a specific operation. When the physical component is connected, the basic electrical properties of the hardware component are changed, for example, from an insulator to a conductor, or vice versa. The instruction enables embedded hardware (e.g., an execution unit or a loading mechanism) to create a member of a circuit set in the hardware via a variable connection to perform or execute a part of a specific operation when in operation. Therefore, when the device is operating, the computer-readable medium is communicatively coupled to other components of the circuit group component. In one example, any physical component may be used in more than one member of more than one circuit group. For example, in operation, an execution unit may be used in a first circuit of a first circuit, which is set at one point in time and reused by a second circuit in the first circuit group, or set by the second circuit at a different time.

[0044] The machine (e.g., computer system) 500 may include a hardware processor 502 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, a field programmable gate array (FPGA), or any combination thereof), a main memory 504, and a static memory 506, some or all of which may communicate with each other via an interconnect (e.g., a bus) 530. The machine 500 may also include a display unit 510, an input device 512 (e.g., a keyboard or other alphanumeric input device), and a user interface (UI) navigation device 514 (e.g., a mouse). In one example, the display unit 510, the input device 512, and the user interface navigation device 514 may be a touch screen display. The machine 500 may additionally include a storage device 508 (e.g., a drive unit or other similar mass storage device or unit), a signal generating device 518 (e.g., a speaker), a network interface device 520 connected to a network 526, and one or more sensors 516, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The machine 500 may include an output controller 528, such as a serial (e.g., Universal Serial Bus (USB), parallel or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0045] The storage device 508 may include a machine-readable medium 522 on which is stored one or more sets of data structures or instructions 524 (e.g., software) that implement or are used by any one or more of the techniques or functionality described herein. The instructions 524 may also reside, completely or at least partially, within the main memory 504, within the static memory 506, or within the hardware processor 502 during execution of the instructions 524 by the machine 500. In one example, one or any combination of the hardware processor 502, the main memory 504, the static memory 506, or the storage device 508 may constitute a machine-readable medium.

[0046] Although the machine-readable medium 522 is illustrated as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 524. The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions executed by the machine 500 and causing the machine 500 to perform any one or more of the techniques of the present disclosure, or any medium capable of storing, encoding, or carrying data structures used by or associated with these instructions. Non-limiting machine-readable medium examples may include solid-state memory and optical and magnetic media. In one example, the aggregated machine-readable medium includes a machine-readable medium having multiple particles of constant (e.g., stationary) mass. Therefore, the aggregated machine-readable medium is not a transient propagating signal. Specific examples of aggregated machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM optical disks.

[0047] Additional notes and examples:

[0048] The above detailed description includes references to the accompanying drawings that form a part of the detailed description. The accompanying drawings show specific embodiments in which the present invention can be implemented, but are not limited thereto. These embodiments are also referred to as "examples" in this article. These examples may also include elements other than those shown or described. However, the inventors also contemplate that only examples of those elements shown or described are provided. In addition, the inventors also contemplate examples of any combination or permutation of those elements (or one or more aspects thereof) used, or with respect to specific examples (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

[0049] All publications, patents, and patent documents mentioned in this document are incorporated herein by reference in their entirety, as if individually incorporated by reference. In the event of an inconsistency between the usages of this document and a document incorporated by reference, the usage in the incorporated reference should be considered supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.

[0050] In this document, the terms "a", "an", "the", and "said" are used when introducing elements of various aspects of the present invention or in embodiments thereof, as is common in patent documents, to include one or more elements, regardless of any other instances or uses of "at least one" or "one or more". In this document, unless otherwise indicated, the term "or" is used to refer to a non-exclusive or "A or B", including "A but not including B", "B but not including A", and "A and B".

[0051] In the appended claims, the terms "including" and "wherein" are used as equivalents of the respective terms "comprising" and "wherein." Moreover, in the appended claims, the terms "including," "comprising," and "having" mean that there may be other elements in addition to the listed elements, such that the term (e.g., including, comprising, having) in a claim is still considered to fall within the scope of the claim. Furthermore, in the following claims, the terms first, second, third, etc. are used merely as labels and are not intended to impose numerical limitations on their modifiers.

[0052] The present invention also relates to a computing system suitable for, configured or operated to perform the operations herein. The system can be specially constructed for the desired purpose, or it can include a general-purpose computer selectively activated or reconfigured by a computer program (e.g., instruction, code, etc.) stored in the computer. Unless otherwise specified, the execution order or execution of the operations in the embodiments of the present invention illustrated and described herein are not necessary. That is, the operations can be performed in any order, unless otherwise specified, and embodiments of the present invention can include more or less operations than the operations disclosed herein. For example, it is envisioned that before, simultaneously or after another operation, a specific operation is performed or performed within the scope of aspects of the present invention.

[0053] In view of the above, it can be seen that several objects of the present invention can be achieved and other advantageous results are obtained. Having described aspects of the present invention in detail, it is clear that modifications and variations can be made without departing from the scope of aspects of the present invention as defined in the appended claims. Since various changes can be made to the above-mentioned constructions, products and methods without departing from the scope of aspects of the present invention, it is intended that all items contained in the above description and shown in the accompanying drawings be interpreted as illustrative, rather than restrictive.

[0054] The above description is intended to be illustrative, rather than restrictive. For example, the above examples (or one or more aspects thereof) may be used in combination with each other. In addition, without departing from the scope of the present invention, many modifications may be made to adapt specific situations or materials to the teachings of the present invention. Although the dimensions, material types and example parameters, functions and implementations described herein are intended to define the parameters of the present invention, they are by no means restrictive and are exemplary embodiments. When reviewing the above description, many other embodiments will be apparent to those skilled in the art. Therefore, the scope of the present invention should be determined with reference to the appended claims and the full range of equivalents that these claims have.

[0055] In addition, in the above detailed description, various features may be grouped together to simplify the disclosure. This should not be interpreted as intending to make the disclosed features that are not claimed essential to any claim. On the contrary, the subject matter of the present invention may be less than all the features of a particular disclosed embodiment. Therefore, the following claims are incorporated into the detailed description, and each claim is independently used as a separate embodiment. The scope of the present invention should be determined with reference to the attached claims and the full range of equivalents that these claims have.

[0056] Example 1 is a method for visualizing radiotherapy data, the method comprising: determining a data set corresponding to visualization data to be displayed in an application user interface, the data set comprising one or more Digital Imaging and Communications in Medicine (DICOM) objects; receiving a request for the data set at an application programming interface (API), wherein the API is configured to access multiple sources of DICOM objects; processing the requested data set, wherein processing the requested data set comprises optimizing the requested data set; verifying the request for the data set, and in response to the verification, providing a client device with access to the processed data set to enable visualization of the processed data set in the application user interface.

[0057] In Example 2, the subject matter of Example 1 includes, wherein optimizing the requested data set includes optimizing the requested data set for visualization without visualizing the requested data set.

[0058] In Example 3, the subject matter of Examples 1-2 includes, wherein the environment including multiple sources of DICOM objects includes a multi-application and multi-tenant environment, and the API retrieves the requested data set from a cached data source.

[0059] In Example 4, the subject matter of Examples 1 to 3 includes, wherein processing the requested data set includes removing identification information of the patient, wherein removing the identification information of the patient includes extracting a portion of pixel data from one or more DICOM objects.

[0060] In Example 5, the subject matter of Examples 1 to 4 includes creating a security key corresponding to one or more DICOM objects; and in response to receiving the API request, verifying that the security key corresponds to the requested data set.

[0061] In Example 6, the subject matter of Example 5 includes caching the processed data set; receiving a second request for the data set at the API, the request including a second security key; in response to receiving the second request, verifying that the second security key corresponds to the requested data set; and in response to the verification, providing access to the cached processed data set to a second client device for visualization.

[0062] In Example 7, the subject matter of Examples 5 to 6 includes, wherein a request for a dataset at the API includes a security key, wherein the security key is unique to the API request and only allows access to a specific combination of one or more DICOM objects in the dataset, and wherein the security key is provided as a JSON web token (JWT).

[0063] In Example 8, the subject matter of Example 7 includes, wherein, to verify that the security key corresponds to the requested data set, the API verifies the JWT using a public key, and the public key is configured to: verify that the client device is a valid source of the requested data set; and verify that the request for the data set was not modified or corrupted while being transmitted from the client device.

[0064] In Example 9, the subject matter of Examples 5 to 8 includes, wherein the security key comprises a message summary, the message summary comprising a hash generated based on a list of each of the one or more DICOM objects, and the hash is generated based on one or more of a list of images to be visualized, one or more spatially registered objects, a set of structures, a radiation therapy plan, or a radiation therapy dose.

[0065] In Example 10, the subject matter of Examples 5 to 9 includes sending the security key to a renderer of the client device.

[0066] In Example 11, the subject matter of Examples 5 to 10 includes, wherein determining a data set and creating a security key is performed by a first server, wherein the first server generates the security key using a private key, and receiving a request for the data set, verifying that the security key corresponds to the requested data set, processing the requested data set, and providing client device access to the processed data set are performed by a second server different from the first server.

[0067] Example 12 is a system for visualizing radiation therapy data, the system comprising: a processing circuit; and a memory including instructions stored thereon, which, when executed by the processing circuit, cause the processing circuit to: determine a data set corresponding to visualization data to be displayed in an application user interface, the data set including one or more Digital Imaging and Communications in Medicine (DICOM) objects; create a security key corresponding to the one or more DICOM objects; receive a request for the data set at an application programming interface (API), the request including the security key, wherein the API is configured to access multiple sources of DICOM objects; in response to receiving the API request, verify that the security key corresponds to the requested data set; process the requested data set to remove identification information, wherein the processing includes: optimizing the requested data set for visualization without visualizing the requested data set; caching the optimized data set; and in response to the verification, provide access to the processed data set to a client device to enable visualization of the data in the application user interface.

[0068] In Example 13, the subject matter of Example 12 includes, wherein the environment including the multiple sources of DICOM objects includes at least one of a multi-application or a multi-tenant environment, and the API retrieves the requested data set from a cached data source.

[0069] In Example 14, the subject matter of Examples 12-13 includes, wherein the security key is provided as a JSON web token (JWT), and to verify that the security key corresponds to the requested data set, the API verifies the JWT using the public key.

[0070] In Example 15, the subject matter of Example 14 includes, wherein the public key is configured to: verify that the client device is a valid source of the requested data set; and verify that the request for the data set has not been modified or corrupted while being transmitted from the client device.

[0071] In Example 16, the subject matter of Examples 12 to 15 includes, wherein the security key only allows access to a specific combination of one or more DICOM objects in a data set, wherein the security key includes a message summary, the message summary includes a hash generated based on a list of each of the one or more DICOM objects, and the hash is generated based on one or more of a list of images to be visualized, one or more spatially registered objects, a set of structures, a radiation therapy plan, or a radiation therapy dose.

[0072] In Example 17, the subject matter of Examples 12 to 16 includes, wherein processing the requested data set comprises extracting a portion of pixel data from one or more DICOM objects.

[0073] Example 18 is a non-transitory computer-readable medium having instructions stored thereon, which, when executed by a processor of a computing device, causes the processor to: determine a data set corresponding to visualization data to be displayed in an application user interface, the data set comprising one or more Digital Imaging and Communications in Medicine (DICOM) objects; create a security key corresponding to the one or more DICOM objects; receive a request for the data set at an application programming interface (API), the request comprising the security key, wherein the API is configured to access multiple sources of DICOM objects; in response to receiving the API request, verify that the security key corresponds to the requested data set; process the requested data set to remove identifying information, wherein processing the requested data set comprises optimizing the requested data set; and in response to the verification, provide access to the processed data set to a client device to enable visualization of the data in the application user interface.

[0074] In Example 19, the subject matter of Example 18 includes, wherein optimizing the requested data set comprises optimizing the requested data set for visualization without visualizing the requested data set, and the instructions further cause the processor to cache the optimized data set.

[0075] In Example 20, the subject matter of Examples 18-19 includes, wherein processing the requested data set comprises extracting a portion of pixel data from one or more DICOM objects.

[0076] In Example 21, the subject matter of Examples 18 to 20 includes, wherein the security key is provided as a JSON web token (JWT), wherein to verify that the security key corresponds to the requested data set, the API verifies the JWT using a public key, and the public key is configured to: verify that the client device is a valid source of the requested data set; and verify that the request for the data set was not modified or corrupted while being transmitted from the client device.

[0077] Example 22 is a method for caching radiation therapy data visualization, the method comprising: receiving a request for a data set corresponding to a patient from a first client, the data set comprising one or more Digital Imaging and Communications in Medicine (DICOM) objects; retrieving the data set from a data source; processing the data set; caching the processed data set; providing access to the processed data to the first client to enable visualization of the processed data; receiving a request for a data set corresponding to the patient from a second client; and retrieving the cached processed data set.

[0078] In Example 23, the subject matter of Example 22 includes, wherein the request from the first client is from a server associated with the first client device.

[0079] In Example 24, the subject matter of Examples 22 to 23 includes, wherein the request for the data set includes providing a unique security key of a first JSON web token (JWT), and verifying the first JWT using a public key, wherein the public key is configured to verify that the first client is a valid source of the requested data set; and verifying that the request for the data set has not been modified or corrupted while being transmitted from the first client.

[0080] In Example 25, the subject matter of Examples 22 to 24 includes providing access to the processed data from the cache to the second client to enable visualization of the processed data.

[0081] In Example 26, the subject matter of Example 25 includes, wherein the request from the second client is from a server associated with the second client device.

[0082] In Example 27, the subject matter of Example 26 includes, wherein the request for the data set from the second client includes providing a unique security key of a JSON web token (JWT), and verifying the JWT using a public key, the public key configured to verify that the second client device is a valid source of the requested data set; and verifying that the request for the data set was not modified or corrupted while being transmitted from the second client device.

[0083] In Example 28, the subject matter of Examples 22 to 27 includes, wherein processing the requested data set comprises: optimizing the data set for visualization without visualizing the data set; and extracting a portion of the pixel data from the one or more DICOM objects.

[0084] Example 29 is a system for caching radiation therapy data visualization, the system comprising: a processing circuit; and a memory comprising instructions, which, when executed by the processing circuit, cause the processing circuit to: receive a request for a data set corresponding to a patient from a first client, the data set comprising one or more Digital Imaging and Communications in Medicine (DICOM) objects; retrieve the data set from a data source; process the data set, wherein processing the data set comprises: removing identification information of the patient from the one or more DICOM objects; and optimizing the data set for visualization without visualizing the data set; caching the processed data set; and providing access to the processed data to the first client to enable visualization of the processed data.

[0085] In Example 30, the subject matter of Example 29 includes, wherein the request from the first client is from a server associated with the first client device.

[0086] In Example 31, the subject matter of Example 30 includes, wherein the request for the data set includes providing a unique security key of a first JSON web token (JWT), and wherein the first JWT is verified using a public key, the public key configured to verify that the first client device is a valid source of the requested data set; and verifying that the request for the data set was not modified or corrupted while being transmitted from the first client device.

[0087] In Example 32, the subject matter of Examples 29 to 31 includes that the processing circuit is further used to: receive a request for a data set corresponding to a patient from a second client; retrieve a cached processed data set; and provide the second client with access to the processed data from the cache to enable visualization of the processed data.

[0088] In Example 33, the subject matter of Example 32 includes, wherein the request from the second client is from a server associated with the second client device.

[0089] In Example 34, the subject matter of Example 33 includes, wherein the request for the data set from the second client includes providing a unique security key of a JSON web token (JWT), and verifying the JWT using a public key, the public key configured to verify that the second client device is a valid source of the requested data set; and verifying that the request for the data set was not modified or corrupted while being transmitted from the second client device.

[0090] In Example 35, the subject matter of Examples 29 to 34 includes, wherein processing the requested data set comprises: extracting a portion of pixel data from one or more DICOM objects.

[0091] Example 36 is a non-transitory computer-readable medium having instructions stored thereon, which, when executed by a processor of a computing device, causes the processor to: receive a request for a data set corresponding to a patient from a first client, the data set comprising one or more Digital Imaging and Communications in Medicine (DICOM) objects; retrieve the data set from a data source; process the data set, wherein processing the data set comprises: removing identification information of the patient from one or more DICOM objects; and optimizing the data set for visualization without visualizing the data set; cache the processed data set; and provide access to the processed data to the first client to enable visualization of the processed data.

[0092] In Example 37, the subject matter of Example 36 includes, wherein the request from the first client is from a server associated with the first client device.

[0093] In Example 38, the subject matter of Example 37 includes, wherein the request for the data set includes providing a unique security key of a first JSON web token (JWT), and verifying the first JWT using a public key, the public key configured to verify that the first client device is a valid source of the requested data set; and verifying that the request for the data set has not been modified or corrupted while being transmitted from the first client device.

[0094] In Example 39, the subject matter of Examples 36 to 38 includes, wherein the instructions further cause the processor to: receive a request for a data set corresponding to the patient from a second client; retrieve a cached processed data set; and provide the second client with access to the processed data from the cache to enable visualization of the processed data.

[0095] In Example 40, the subject matter of Example 39 includes, wherein the request from the second client is from a server associated with the second client device.

[0096] In Example 41, the subject matter of Example 40 includes, wherein the request for the data set from the second client includes providing a unique security key of a JSON web token (JWT), and verifying the JWT using a public key, the public key configured to verify that the second client device is a valid source of the requested data set; and verifying that the request for the data set has not been modified or corrupted while being transmitted from the second client device.

[0097] In Example 42, the subject matter of Examples 36 to 41 includes, wherein processing the requested data set includes: extracting a portion of pixel data from one or more DICOM objects.

[0098] Example 43 is at least one machine-readable medium comprising instructions that, when executed by a processing circuit, cause the processing circuit to perform operations to implement any of Examples 1-42.

[0099] Embodiment 44 is a device comprising implementing any one of embodiments 1 to 42.

[0100] Embodiment 45 is a system for implementing any one of embodiments 1 to 42.

[0101] Embodiment 46 is a method of implementing any one of embodiments 1 to 42.

[0102] The method examples described herein may be at least partially machine or computer implemented. Some examples may include a computer-readable medium or a machine-readable medium encoded with instructions, which may be operable to configure an electronic device to perform the method described in the above examples. The implementation of this method may include code, such as microcode, assembly language code, high-level language code, etc. This code may include computer-readable instructions for performing various methods. The code may form part of a computer program product. In addition, in one example, the code may be tangibly stored on one or more volatile, non-transient or non-volatile tangible computer-readable media, such as during execution or at other times. Examples of these tangible computer-readable media may include, but are not limited to, hard disks, removable disks, removable optical disks (e.g., compact disks and digital video disks), magnetic boxes, memory cards or memory sticks, random access memories (RAM), read-only memories (ROM), etc.

Claims

1. A method for visualizing radiotherapy data, the method comprising: determining a data set corresponding to visualization data to be displayed in an application user interface, the data set comprising one or more Digital Imaging and Communications in Medicine (DICOM) objects; receiving a request for the data set at an application programming interface (API), wherein the API is configured to access a plurality of sources of the DICOM objects; processing the requested data set, wherein processing the requested data set includes optimizing the requested data set; Authenticate requests for said dataset, and In response to the verification, access to the processed data set is provided to the client device to enable visualization of the processed data in the application user interface.

2. The method according to claim 1, characterized in that Optimizing the requested data set includes optimizing the requested data set for visualization without visualizing the requested data set.

3. The method according to claim 1, characterized in that The environment including multiple sources of the DICOM objects includes a multi-application and multi-tenant environment, and the API retrieves the requested data set from a cached data source.

4. The method according to claim 1, characterized in that: Processing the requested data set includes: Removing identification information of the patient, wherein removing the identification information of the patient comprises extracting a portion of pixel data from the one or more DICOM objects.

5. The method according to claim 1, characterized in that Also includes: Creating a security key corresponding to the one or more DICOM objects; as well as In response to receiving the API request, verifying that the security key corresponds to the requested data set.

6. The method according to claim 5, characterized in that Also includes: caching the processed data set; receiving, at the API, a second request for the data set, the second request including a second security key; in response to receiving the second request, verifying that the second security key corresponds to the requested data set; as well as In response to the verification, access to the cached processed data set is provided to a second client device to enable visualization.

7. The method according to claim 5, characterized in that A request for the dataset at the API includes the security key, wherein the security key is unique to the API request and only allows access to a specific combination of the one or more DICOM objects in the dataset, and wherein the security key is provided as a JSON web token (JWT).

8. The method according to claim 7, characterized in that To verify that the security key corresponds to the requested data set, the API uses a public key to verify the JWT, and the public key is configured to: verifying that the client device is a valid source requesting the data set; and Verifying that the request for the data set has not been modified or corrupted while being transmitted from the client device.

9. The method according to claim 5, characterized in that The security key comprises a message summary comprising a hash generated based on a list of each of the one or more DICOM objects, and the hash is generated based on one or more of a list of images to be visualized, one or more spatially registered objects, a set of structures, a radiotherapy plan, or a radiotherapy dose.

10. The method according to claim 5, characterized in that Also includes: The security key is transmitted to a renderer of the client device.

11. The method according to claim 5, characterized in that Determining the data set and creating the security key is performed by a first server, wherein the first server generates the security key using a private key, and receiving a request for the data set, verifying that the security key corresponds to the requested data set, processing the requested data set, and providing the client device with access to the processed data set is performed by a second server different from the first server.

12. A system for visualizing radiation therapy data, the system comprising: Processing circuit; and a memory including instructions stored thereon that, when executed by the processing circuit, cause the processing circuit to: determining a data set corresponding to visualization data to be displayed in an application user interface, the data set comprising one or more Digital Imaging and Communications in Medicine (DICOM) objects; Creating a security key corresponding to the one or more DICOM objects; receiving, at an application programming interface (API), a request for the data set, the request including the security key, wherein the API is configured to access a plurality of sources of the DICOM objects; In response to receiving the API request, verifying that the security key corresponds to the requested data set; Processing the requested data set to remove identifying information, wherein the processing comprises: optimizing the requested data set for visualization without visualizing the requested data set; and Cache-optimized datasets; and In response to the verification, access to the processed data set is provided to a client device to enable visualization of the processed data at the application user interface.

13. The system according to claim 12, characterized in that The environment including the plurality of sources of the DICOM objects includes at least one of a multi-application or a multi-tenant environment, and the API retrieves the requested data set from a cached data source.

14. The system according to claim 12, characterized in that The security key is provided as a JSON web token (JWT), and to verify that the security key corresponds to the requested data set, the API verifies the JWT using a public key.

15. The system according to claim 14, characterized in that The public key is configured as: verifying that the client device is a valid source requesting the data set; and Verify that the request for the data set has not been modified or corrupted while being transmitted from the client device.

16. The system according to claim 12, characterized in that The security key only allows access to a specific combination of the one or more DICOM objects in the data set, wherein the security key includes a message summary, the message summary includes a hash generated based on a list of each of the one or more DICOM objects, and the hash is generated based on one or more of a list of images to be visualized, one or more spatially registered objects, a set of structures, a radiotherapy plan, or a radiotherapy dose.

17. The system according to claim 12, characterized in that Processing the requested data set includes: A portion of the pixel data is extracted from the one or more DICOM objects.

18. A non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor of a computing device, cause the processor to: determining a data set corresponding to visualization data to be displayed in an application user interface, the data set comprising one or more Digital Imaging and Communications in Medicine (DICOM) objects; Creating a security key corresponding to the one or more DICOM objects; receiving, at an application programming interface (API), a request for the data set, the request including the security key, wherein the API is configured to access a plurality of sources of the DICOM objects; In response to receiving the API request, verifying that the security key corresponds to the requested data set; processing the requested data set to remove identifying information, wherein processing the requested data set includes optimizing the requested data set; as well as In response to the verification, access to the processed data set is provided to a client device to enable visualization of the data at the application user interface.

19. The non-transitory computer readable medium of claim 18, wherein: Optimizing the requested data set includes optimizing the requested data set for visualization without visualizing the requested data set, and the instructions further cause the processor to: Cache-optimized datasets.

20. The non-transitory computer readable medium of claim 18, wherein: Processing the requested data set includes: A portion of the pixel data is extracted from the one or more DICOM objects.

21. The non-transitory computer readable medium of claim 18, wherein: The security key is provided as a JSON web token (JWT), wherein to verify that the security key corresponds to the requested data set, the API verifies the JWT using a public key, and the public key is configured to: verifying that the client device is a valid source requesting the data set; and Verifying that the request for the data set has not been modified or corrupted while being transmitted from the client device.

Images