Method and system for providing dose data from a cloud-based dose management system

Abstract

This invention relates to a method and system for providing dose data from a cloud-based dose management system (CBDMS) within a local area network (LAN). The method includes: receiving study data from a PACS within the LAN at a Medical Data Gateway (MDGW) within the LAN; based on the received study data, uploading at least first dose data to the dose management system via the MDGW, the first dose data including or indicating at least one corresponding explicit study identification feature; checking for the presence of predefined trigger conditions via a dose data provision module (DDBM) implemented in the MDGW within the LAN, and if so: downloading second dose data from the CBDMS via the DDBM, which includes or indicates the corresponding explicit study identification feature; and providing the second dose data either automatically or when the predefined provision conditions are met to a reporting system or another local device within the LAN.

Description

Technical Field

[0001] This invention relates to a method and system for providing dose data from a cloud-based dose management system in a local area network. Background Technology

[0002] Medical institutions are increasingly using centralized, cloud-based dose management systems. This approach reduces or eliminates the need for on-premises infrastructure, thereby lowering maintenance costs and often making data protection easier and more cost-effective. However, this solution also presents new challenges: for example, in the hospital setting, there is a desire to add applied dose values ​​to locally generated patient study reports.

[0003] Currently, the applied dose value should be understood as a value relating to the radiation dose experienced by a patient within the scope of a so-called "study" (or "examination"). For example, such a study may consist of a series of computed tomography (CT) scans, each of which can represent a dose-related event, i.e., a so-called "dose event." Other dose events may include, for example, the administration of contrast agents or even the ingestion or absorption of radioactive materials by the patient (e.g., in cases of poisoning or for medical examinations).

[0004] Another drawback of the existing system is that doctors or professionals typically create reports after conducting studies. These reports are usually dictated using a so-called reporting system and should include relevant dosage data. What's troublesome for the dictator is that during the dictation process, which is often performed using dictation software, other software applications need to be opened or processed so that the dosage values ​​can be viewed and then added to the report.

[0005] In addition, medical institutions are increasingly under pressure from national agencies to provide dose data (or dose information) based on internationally comparable standards so that applied dose values ​​can be compared with defined reference values.

[0006] Another problem is that reference values ​​and dosage data are not easily comparable in most cases because studies performed in different institutions differ significantly in their content, making direct comparisons impossible. The use of different equipment (e.g., devices or software solutions), different assessment and management software, and different national standards further complicate comparability.

[0007] Furthermore, there is a need for a simple method to transfer dose values ​​to a higher-level dose registry, such as a national dose registry, which is typically required within budgetary constraints. This has been costly and risky to date, as it usually involves different systems and software solutions than those used within individual medical institutions. Conversely, there is also a need for a simple method within medical institutions to obtain reference values ​​from such national dose registry and, where possible, to simultaneously utilize other dose registryes, such as a global dose registry, for analysis. Summary of the Invention

[0008] The stated and other objectives are achieved through embodiments of this patent application.

[0009] According to a first aspect, the present invention provides a method for providing dose data from a cloud-based dose management system (CBDMS) in a local area network (LIN) system, wherein the method includes at least the following steps:

[0010] Research data is received from the local image archive and communication system PACS within the local intranet at the Medical Data Gateway (MDGW) based on at least one predefined selection criterion.

[0011] Based on the received research data, at least the first dose data is uploaded to the cloud-based dose management system CBDMS via the medical data gateway MDGW, wherein the first dose data includes or indicates at least one corresponding explicit research identification feature value ESIK;

[0012] The dose data delivery module (DDBM), implemented in the Medical Data Gateway (MDGW) within the local intranet, checks for the existence of predefined triggering conditions, and if so, then:

[0013] The dose data provision module DDBM downloads second dose data based on the first dose data from the cloud-based dose management system CBDMS, wherein the second dose data includes or indicates the corresponding explicit study identification feature value ESIK; and

[0014] The second dose data is provided either automatically or when predefined provision conditions are met to the reporting system REP or another local device within the local network.

[0015] Medical data gateways (MDGWs) may, for example, involve Siemens Healthineers’ “Teamplay” or “teamplay” (registered trademark) receivers or similar products.

[0016] Cloud-based dose management systems (CBDMS) can have other functions or be provided as part of a broader cloud functionality. For example, studies, benchmarks, box plots, etc., can be stored in the cloud functionality in a deidentified form, especially for data protection considerations.

[0017] Cloud-based dose management systems (CBDMS) can advantageously offer, in particular, the functionality of a global dose registry. In contrast to national dose registries, the global dose registry can provide globally mandatory dose data, such as baselines and reference values, and this is available across different modalities, software applications, medical institutions, etc.

[0018] According to the DICOM standard, research data can be presented in the form of a structured report (SR). "DICOM" is a registered trademark and stands for "Digital Imaging and Communications in Medicine." Whenever the DICOM standard is mentioned here, it is specifically understood to refer to the current version of the DICOM standard, PS3.12020d, in which structured reports based on previous or subsequent versions of the DICOM standard can also be used. Within the scope of first-dose data, complete studies can be uploaded to a cloud-based dose management system (CBDMS).

[0019] As further elaborated below, the dose data provision module (DDBM) may include multiple mechanisms. In particular, push and / or pull functionality may be provided. Furthermore, the method is suitable for feeding data to and / or always receiving current dose reference values ​​from a global or national dose database or dose registry (“dose registry”). These dose reference values ​​can then be provided in association with ongoing studies (“examinations”) to present a comprehensive picture to physicians or other evaluators of the study.

[0020] Reporting systems could include, for example, Nuance's "Powerscribe" (registered trademark) system or similar systems.

[0021] Local devices should be understood in particular as devices available on a local area network, or software applications available there, or local computing devices that execute such software applications. For example, a reporting system or a radiology information system can be understood as a local device. A physician's personal computer (PC) can also refer to a local device as well as management software that runs or is executable on such a PC.

[0022] The invention described herein, along with all its associated concepts and principles, is described in light of the specific problem of dose management. However, it should be understood that similar, i.e., the same type of application, is also possible for similar, closely related problems, such as contrast management or protocol management.

[0023] Therefore, the corresponding statement can be:

[0024] - Use "contrast data" or "protocol data" (or contrast data or recorded data) instead of "dose data";

[0025] - These are either "Comparison Data Provider Module CDBM" or "Protocol Data Provider Module PDBM" instead of "Dose Data Provider Module DDBM";

[0026] - Generally, it is "comparison management" or "protocol management" rather than "dosage data management";

[0027] - wait.

[0028] Therefore, if a cloud-based contrast management system and / or a cloud-based protocol management system are provided in place of a cloud-based dose management system (or to complement a cloud-based dose management system), then a global contrast registry and / or a global protocol registry can also be provided accordingly.

[0029] Other embodiments, features, advantages, variations and possible improvements are derived from the description with reference to the accompanying drawings.

[0030] According to some preferred embodiments, variations or improvements of the embodiments, it is clearly studied that the identification feature value ESIK is at least one of the following feature values ​​and / or based on at least one of the following feature values:

[0031] - Login number AN, which represents the process number in the radiology information system within the local area network LIN;

[0032] - Patient identification feature value PIK; and / or

[0033] - Research Entity UID, which is designed to explicitly identify research associated with the Structured Reporting Document (SDR).

[0034] Therefore, by means of the explicit study identification feature value ESIK, which to some extent serves as a “magic cookie” (i.e., exists for each study), it is possible to create data exchange between devices and services from different manufacturers, different hospitals, different software vendors, etc.

[0035] In the DICOM standard, the registry number is represented by element number (0008, 0050). This registry number is associated with the process created in the Radiology Information System (RIS) and the image produced by that process, which is stored in an image archive. The registry number is assigned by the RIS and clearly stored in the generated or imported DICOM object, allowing the user to understand which process in the RIS the observed image can be associated with when viewing an image in the image archive.

[0036] According to some preferred embodiments, variations or improvements of the embodiments, the dose data providing module DDBM includes a reactive pull module RPM (or is composed of such a reactive pull module RPM), wherein the reactive pull module:

[0037] A URL is provided that can be invoked by a local device within a local area network to request second dose data; wherein the URL includes at least one corresponding explicit research identification feature value (ESIK).

[0038] The predefined triggering conditions include receiving a call from the provided URL; and

[0039] The second dose data is provided to the local device via the reactive pull module RPM.

[0040] Therefore, this URL can be provided to any local device, such as a radiology information system, reporting system, etc., and the required dose data can be easily provided in a pull method based on the query using the URL. In this way, the user of the local device conveniently eliminates the need to operate the dose management system separately in addition to using the device.

[0041] According to some preferred embodiments, variations or improvements of the embodiments, a Service Access Token (SAT) is provided to the local device via a Reactive Pull Module (RPM). The Service Access Token is checked by the Reactive Pull Module (RPM) during a URL call at the local device to verify the call. The predefined triggering conditions include successful verification of the Service Access Token (SAT).

[0042] According to some preferred embodiments, variations or improvements of the embodiments, the local device is a Radiology Information System (RIS).

[0043] According to some preferred embodiments, variations or improvements of the embodiments, the dose data providing module DDBM includes an active push module PPM or is composed of such an active push module PPM.

[0044] The predefined triggering conditions include receiving information from the cloud-based dose management system (CBDMS) that the study has been fully uploaded to the CBDMS. In this manner, for example, dose values ​​can be "pushed" into the reporting system within the range of second dose data, making these dose values ​​automatically available for use by physicians or other professionals when creating (e.g., verbally) reports.

[0045] According to some preferred embodiments, variations or improvements of the embodiments, the Medical Data Gateway (MDGW) de-identifies the first dose data and uploads the first dose data in a de-identified form to the cloud-based dose management system (CBDMS).

[0046] The Medical Data Gateway (MDGW), in particular, re-identifies the downloaded second dose data based on the corresponding explicitly identified study-identified feature value (ESIK) through the Dose Data Provisioning Module (DDBM). Deidentification should be understood in particular as deidentified data or feature values ​​(without additional data) that cannot be associated with a specific patient, while re-identified data can be associated with a specific patient.

[0047] According to some preferred embodiments, variations or improvements of the embodiments, the predefined provisioning conditions VDB include the following positive result of the check: whether there is currently an incomplete task at the reporting system that is associated with the explicit study identification feature value ESIK, which is associated with the second dose data.

[0048] Information about standard protocol allocations and / or standard reference values ​​may be provided as part of, or in addition to, the second dose data, depending on some preferred embodiments, variations or improvements thereof.

[0049] Second dose data may include, for example, desired dose parameters such as CTDIVOL and / or DLP, for use throughout the study (also known as the “examination”) or only for individual dose events. Second dose data may be transmitted in different formats, such as one (or more) of the following formats:

[0050] - Text format (.txt file)

[0051] - PDF format (.pdf file)

[0052] - JSON format

[0053] - DICOM format (as a structured report dose RDSR).

[0054] As part of, or in addition to, the second dose data, information regarding standard protocol mappings and / or standard reference values ​​may advantageously be provided to the local device. For example, the dose parameters mentioned may be supplemented by standard mappings and standardized protocols such as RadLex or LOINC. Alternatively or additionally, the dose event itself and / or associated dose reference values ​​automatically determined according to the standardized protocol mapping may also be provided.

[0055] RadLex is a dictionary of radiological information compiled by the Radiological Society of North America (RSNA). RadLex represents an ontology whose purpose is to develop a useful glossary for radiologists.

[0056] LOINC (Logical Observation Identifiers Names and Codes) is an internationally recognized, primarily English-language system used for explicitly encrypting medical examinations, particularly laboratory tests. LOINC is published by the Regenstrief Institute (USA). Therefore, LOINC can also be referred to as a superset of RadLex, or a RadLex protocol that overlaps with and is compatible with LOINC.

[0057] According to some preferred embodiments, variations or improvements of the embodiments, the dose data providing module DDBM includes a dose registration module DRM or is composed of such a dose registration module DRM.

[0058] Once the study has been fully uploaded to the cloud-based dose management system CBDMS, CBDMS will inform the dose registration module DRM implemented in the medical data gateway MDGW.

[0059] Subsequently, the Dose Registration Module (DRM) provides the second dose data to the Registration Site Service System (REG), which serves as the local device registration site within the local intranet.

[0060] The Registration Site Service (REG) system transmits the third dose data, based on the second dose data, to the National Dose Registration Calculator (NDRR).

[0061] According to some preferred implementations, variations or improvements of the implementations, the Registration Site Service System (REG) (preferably periodically) receives dose reference data from the National Dose Registration Calculator (NDRR). Subsequently, the REG informs the Dose Registration Module (DRM) of the availability of new dose reference data. Then, the DRM uploads the new dose reference data to the cloud-based dose management system (CBDMS).

[0062] According to some preferred embodiments, variations or improvements of the embodiments, the cloud-based dose management system CBDMS additionally functions as a global dose registry, a cloud-based comparison management system CBKMS and / or a cloud-based protocol management system CBPMS.

[0063] A contrast management system should be understood, for example, as a software (and / or hardware) package configured to receive, read, store, share, compare, and / or graphically display data (especially contrast data, or "contrast data") from, for example, PACS, RIS, and / or injection systems.

[0064] The protocol management system should be understood, for example, as a software (and / or hardware) package configured to provide multi-mode access to, monitoring of, and, where necessary, setting / changing of the imaging protocol.

[0065] According to a second aspect, the present invention provides a system for providing dose data from a cloud-based dose management system (CBDMS), comprising:

[0066] The medical data gateway MDGW is located within the local area network of the system, and the medical data gateway MDGW constitutes the dose data provision module DDBM.

[0067] The reporting system REP within the local area network; and

[0068] A cloud-based dose management system (CBDMS) outside of a local area network;

[0069] The system is configured to perform a method according to an embodiment of the first aspect of the invention.

[0070] According to a third aspect, the present invention provides a computer program product comprising executable program code configured to, when executed, perform a method according to an embodiment of the first aspect of the present invention.

[0071] According to a fourth aspect, the present invention provides a computer-readable non-volatile data storage medium comprising executable program code configured to, when executed, perform a method according to an embodiment of the first aspect of the present invention.

[0072] According to a fifth aspect, the present invention provides a data stream comprising executable program code, or the data stream is designed to provide executable program code, wherein the executable program code is configured to, when executed, perform a method according to an embodiment of an embodiment of the first aspect of the present invention. Attached Figure Description

[0073] The invention and its technical field are described in detail below with reference to the accompanying drawings. It should be noted that the invention should not be limited to the embodiments shown. In particular, unless otherwise explicitly stated, certain aspects of the facts illustrated in the figures can be extracted and combined with other components and knowledge from this specification and / or the drawings. It should be particularly noted that the drawings and the dimensional relationships shown are merely schematic. The same reference numerals denote the same objects, so that the illustrations in other drawings can be used supplementarily if necessary.

[0074] The numbering of method steps is primarily for their distinguishability and should not necessarily imply a particular order, unless this is explicitly or clearly described in the content or context.

[0075] The attached diagram shows:

[0076] Figure 1 Schematic diagrams are shown for illustrating a method according to an embodiment of the first aspect of the present invention and a system for illustrating an embodiment according to the second aspect of the present invention;

[0077] Figure 2 Showing the use of according to Figure 1 A schematic flowchart of the method;

[0078] Figure 3 A schematic diagram is shown for a method according to another embodiment of the first aspect of the invention and for illustrating a system according to another embodiment of the second aspect of the invention;

[0079] Figure 4 Showing the use of according to Figure 3 A schematic flowchart of the method;

[0080] Figure 5 Schematic diagrams are shown for illustrating a method according to yet another embodiment of the first aspect of the invention and a system for illustrating yet another embodiment of the second aspect of the invention.

[0081] Figure 6 Showing the use of according to Figure 5 A schematic flowchart of the method;

[0082] Figure 7 A schematic block diagram showing a computer program product according to an embodiment of the third aspect of the present invention; and

[0083] Figure 8 A schematic block diagram of a data storage medium according to an embodiment of the fourth aspect of the present invention is shown. Detailed Implementation

[0084] The present invention will now be described in detail with reference to the accompanying drawings. Embodiments of the method or system according to the present invention are described in detail in figures 1 / 2, 3 / 4, and 5 / 6. It should be understood that different embodiments may be proposed independently of each other, but may also be proposed in any combination thereof.

[0085] The embodiments described in the accompanying drawings relate to dose management; however, as detailed above, comparative management and / or protocol management can also be proposed (alternatively or additionally), wherein the names of the various features, method steps and system components are changed or supplemented accordingly.

[0086] Figure 1 The diagram illustrates a method for providing dose data from a cloud-based dose management system (CBDMS) in a local area network (LIN) according to an embodiment of the first aspect of the invention. Figure 1 The invention also describes a system 100 according to an embodiment of the second aspect of the invention, namely a system for providing dose data from a cloud-based dose management system (CBDMS) in a local area network (LIN).

[0087] Figure 2 The flowchart in the middle belongs to Figure 1 The flowchart further illustrates the various method steps within the context.

[0088] In step S1, which is optionally part of the method, medical data in the form of a structured report (SR) is generated from at least one medical data source, or medical data is provided in other ways, particularly in the form of a structured report (SR) according to the DICOM standard.

[0089] Medical data sources may involve medical imaging equipment, such as computed tomography (CT) scanners, magnetic resonance imaging (MRI) scanners, and ultrasound imaging equipment. Structured reports (SRs) may be, for example, the so-called "Dose-RDSR" with SOP-Class-UID=1.2.840.10008.5.1.4.1.1.88.67, the so-called "MAMMO-CAD-SR" with SOP-Class-UID=1.2.840.10008.5.1.4.1.1.88.50, or the so-called "CT Performed Procedure Protocol Storage" with SOP-Class-UID=1.2.840.10008.5.1.4.1.1.200.3. SOP-Class-UID is defined in the DICOM standard, where SOP stands for "Service-Object Pair", "class" represents the category, and "UID" stands for "unique identifier".

[0090] Alternatively or additionally, medical data sources may also involve an injection system 2 (“Injector”) that provides a structured report SR, particularly in accordance with DICOM standards. For example, an injection system may provide a so-called “implemented imaging agent management SR” with SOP-Class-UID=1.2.840.10008.5.1.4.1.1.88.75.

[0091] Other devices that can provide structured reports (SR) are also conceivable.

[0092] In step S2, which is optionally part of the method, a structured report SR provided by at least one medical data source 1, 2 is provided, in particular transmitted to a picture archiving and communication system PACS 3 within a local area network LIN, and received at PACS 3, where PACS stands for "picture archiving and communication system".

[0093] In step S10, research data is received from PACS 3 within the local intranet LIN at the medical data gateway MDGW 10 within the local intranet LIN, based on at least one predefined selection criterion, in particular as a response to a query from the medical data gateway MDGW 10 to PACS 3.

[0094] To illustrate the predefined selection criteria, the Medical Data Gateway MDGW 10 can query all studies within a specific date range (i.e., a time window) and / or all studies with a specific SOP-Class-UID, and then receive all said studies from PACS 3.

[0095] In optional step S15, the medical data gateway MDGW 10 can perform the following data operations on the received data:

[0096] - Only retain labels (or studies with such labels) associated with the allow list (“whitelist” or “permitted list”) and / or remove such labels or studies associated with the block list (“blacklist” or “isolation list”);

[0097] - Convert the retained tags into another data format, especially more commonly used data formats such as XML or JSON.

[0098] Allow lists and / or block lists may be based, for example, on data protection considerations or obligations, such as under the European Data Protection Regulation (DSGVO) or under U.S. HIPAA law (“Health Insurance Portability and Accountability Act”). Allow lists and / or block lists may additionally or alternatively be based on considerations regarding various features or functions of the system according to the invention.

[0099] In step S20, based on the received study data, at least the first dose data is uploaded to the cloud-based dose management system CBDMS 20 via the medical data gateway MDGW 10. The first dose data may in particular be a tag or study retained after optional step S15, but may also relate to a portion of the retained study.

[0100] The first dose data includes or indicates at least one corresponding clearly defined study-identified characteristic value ESIK, which may also be referred to as a cookie or "magic cookie".

[0101] The explicitly identified feature value ESIK can be, for example, at least one of the following feature values ​​and / or based on at least one of the following feature values:

[0102] - Login number AN, which represents the process number in the Radiology Information System RIS 30 within the local area network LIN;

[0103] - Patient identification feature value PIK; and / or

[0104] - Research Entity UID, which is designed to explicitly identify research associated with the structured report SR.

[0105] Due to data protection considerations, it is advantageous in most countries that sensitive data, such as patient data and medical records, are not stored in cloud-based data storage, making them relatable to specific patients.

[0106] Therefore, in optional step S15, the de-identification of the research data can advantageously be performed before the research data is uploaded in step S20. Thus, the explicit research identification feature value ESIK can be replaced in the uploaded data by a de-identified explicit identification feature value diESIK, which cannot be assigned to a specific patient, wherein the medical data gateway MDGW 10 within the local intranet LIN retains information about which explicit research identification feature value ESIK the diESIK corresponds to. Therefore, diESIK indicates the corresponding ESIK without publicly storing this information in the cloud-based system.

[0107] Uploading S20 data, in particular, allows many different DICOM research data based on SOP-Class-UID to be stored separately in research and institution-related cloud containers, for example, according to a hierarchy of institution / research / SOP-Class-UID. Regarding institutions, the term "tenant" is frequently used, referring to institutions that typically deploy or maintain a local area network (LAN) LIN.

[0108] Web applications, such as Siemens Healthineers' "Teamplay Dose WebApplication," can display uploaded research information in a research and / or event-related view, depending on the intended purpose.

[0109] In addition, such as Figure 1 As shown, a local area network (LIN) can be, for example, a local area network (LAN) of a hospital or research institution, or it can include a radiology information system (RIS) 30, etc. Therefore, the RIS 30 represents a local device within the LAN.

[0110] By using the dose data providing module DDBM configured as the reactive pull module RPM 12 according to this embodiment, the URL (universal ressource locator) is provided to the radiology information system RIS 30 within the scope of the network service API generated by the reactive pull module RPM 12.

[0111] The URL can be retrieved from or at the Radiology Information System RIS 30 to request dose data, which will be referred to below as "second dose data". The second dose data may be the same as the first dose data, but may also be based on the first dose data and optionally include other data, as further elaborated below.

[0112] In addition, when the URL is invoked, it includes at least one corresponding explicit research identification feature (ESIK), which can be transmitted to the URL as a parameter via the Radiology Information System (RIS) 30 in relation to, for example, how the user activates the URL (e.g., regarding a specific patient).

[0113] The reactive pull module RPM 12 can also advantageously transmit a so-called "Service Access Token" (SAT) to the Radiology Information System RIS 30 via, for example, encrypted email. The SAT is also used as an additional parameter in the invoked URL.

[0114] In step S31 of the method, the reactive pull module RPM 12 receives a URL call from the radiology information system RIS30.

[0115] In step S32 of the method, it is then checked whether the correct SAT is added as a parameter to the URL call. If the verification is successful, this is a (sufficient) triggering condition for the subsequent step S40.

[0116] The failure during verification in step S32 leads to the failure in step S33 (see...). Figure 2 The method is terminated in this process.

[0117] In step S40, second dose data based on the first dose data (or the same as the first dose data) is downloaded from the cloud-based dose management system CBDMS 20 via the reactive pull module RPM 12. The second dose data includes or indicates the corresponding explicit study identification feature value (ESIK), for example, in a manner in which the second dose data includes the deidentified explicit study identification feature value diESIK.

[0118] In the case where the method is designed to enable the existence of a deidentified study identification feature value diESIK in the cloud-based dose management system CBDMS 20, this is likely the most critical scenario, prior to step S34 (see Figure 2 The function checks whether at least one explicit research identification feature value ESIK exists as a parameter of the URL being called.

[0119] If this is the case, then in step S35 (see...) Figure 2 In this process, a user token is generated based on the SAT token. This user token is used to obtain the association information between the corresponding explicitly identified study identification feature (ESIK) and the corresponding deidentified explicitly identified study identification feature (diESIK) from the medical data gateway MDGW 10, so that the correct second dose data can also be downloaded in step S40. This ensures that the query transmitted from the reactive pull module RPM 12 to the cloud-based dose management system CBDMS 20 is itself deidentified, i.e., it does not contain the explicitly identified study identification feature (ESIK) in plaintext.

[0120] In step S50 (see Figure 2 In this process, the reactive pull module RPM 12 checks whether the reporting system REP 40 currently has any incomplete tasks within the local intranet LIN, which are associated with the Explicit Study Identification Characteristic (ESIK) corresponding to the second dose data. Such incomplete tasks can be tasks that have not yet started being processed or executed, or tasks that are still in progress. As an example of the Explicit Study Identification Characteristic (ESIK), the so-called accession number is provided here.

[0121] Here, the re-identification of the second dose data is shown in S45 (see [link]). Figure 2 This is also feasible and necessary in some implementations because the explicit study identification feature value ESIK is typically present in plain text in the reporting system REP40, while the second dose data downloaded in step S40 in some implementations only includes the deidentified explicit study identification feature value ESIK. Different variations can be clearly envisioned here, such as re-identifying each diESIK in the form of a replacement with the ESIK on which it is based, in S45.

[0122] If the examination in step S50 is successfully performed, the second dose data is provided to the Radiology Information System (RIS) 30 in step S60 by retrieving a URL from the RIS. For example, the second dose data may include desired dose parameters, such as CTDIVOL and / or DLP, for example for the entire study (also referred to as the “examination”), or only for an individual dose event. The second dose data may be transmitted in different formats, such as one (or more) of the following formats:

[0123] - Text format (.txt file)

[0124] - PDF format (.pdf file)

[0125] - JSON format

[0126] - DICOM format (as a structured report dose RDSR).

[0127] All of the requirements and / or variations or options described herein may be provided as parameters to the URL in different implementations.

[0128] It should be understood that in the method described, another local device within the local intranet LIN can also replace the Radiology Information System RIS 30.

[0129] As part of, or in addition to, the second dose data, information regarding standard protocol mappings and / or standard reference values ​​may advantageously be provided to the local equipment (here: Radiology Information System RIS 30). For example, the dose parameters mentioned may be supplemented by standard mappings and standardized protocols such as RadLex or LOINC. Alternatively or additionally, the dose event itself and / or relevant dose reference values ​​automatically determined according to the standardized protocol mapping may also be added.

[0130] To supplement the second dose data, the reactive pull module RPM 12 can call the API provided by the cloud-based dose management system CBDMS 20 to obtain the corresponding standard allocation for a specific study and attach it to the second dose data. Providing the S60 with or without supplemental second dose data can also be done via different protocols, such as the DICOM send protocol, HTTP calls, REST protocols, or other types of file sharing.

[0131] Standard reference values ​​can be retrieved from the dose registration module (DRM) via the reactive pull module RPM 12, where the dose registration module (DRM) is combined with Figure 5 To elaborate further.

[0132] This aggregation of reference values ​​and actual dose parameters (dose values) for each dose event enables a completely new type of information display. In this way, for the first time, for example, it is possible to examine not only the actual radiation dose used but also the cumulative effects of different studies on patients based on dose reference values, with each study involving multiple dose events at different body sites.

[0133] Figure 3 The diagram illustrates a method for providing dose data from a cloud-based dose management system (CBDMS) in a local area network (LIN) according to another embodiment of the invention. Figure 3 The invention also describes a system 100 according to another embodiment of the second aspect of the invention, namely a system for providing dose data from a cloud-based dose management system CBDMS in a local area network (LIN).

[0134] Figure 4 The flowchart in the middle belongs to Figure 3 The flowchart schematically illustrates the various method steps again in the context.

[0135] According to Figure 1 and Figure 2 The main description of the pull mechanism is the opposite of the current description of the push mechanism. Figure 3 and Figure 4 The method is largely based on Figure 1 and Figure 2 The methods are the same or similar, so only the differences will be described below. Similarly, according to Figures 1 to 4 The methods can also be combined, meaning that not only can there be a push mechanism, but also a pull mechanism.

[0136] Correspondingly, the current description is as follows: the dose data providing module DDBM includes the active push module PPM14 instead of the reactive pull module RPM12, wherein it should be understood that the dose data providing module DDBM may also include not only the active push module PPM, but also the reactive pull module RPM12.

[0137] Reference Figure 3 and Figure 4 Steps S10 to S20, which have optional steps S1 and / or S2, are performed as described above.

[0138] In the current case, the triggering condition is also checked via the dose data providing module DDBM. However, in contrast to the above implementation, the triggering condition is checked as follows:

[0139] In step S36, the cloud-based dose management system CBDMS 20 informs the proactive push module PPM, implemented by the medical data gateway MDGW 10, that the new study has been fully uploaded to the cloud-based dose management system CBDMS 20 in step S20. Optionally, this can only be done if specific medical data sources 1 and 2 are enabled in the configuration page of special configuration software, such as a web application.

[0140] Therefore, in step S37, the existence of corresponding information (or: message, or: notification) through the cloud-based dose management system CBDMS 20 can be checked from the proactive push module PPM 14, and optionally additionally, it can be checked whether the push mechanism is desired for the specific study (e.g., related to a modality, i.e., a medical data source, etc.). Thus, in the latter case, the triggering condition consists of two separate sub-conditions that must be satisfied.

[0141] If the result of the check in step S37 is positive, that is, if the triggering condition is met, then steps S40 to S60 follow the procedure described in detail above, wherein the reactive pull module RPM 12 is replaced and the active push module PPM 14 is now running.

[0142] In addition, step S60 has been modified because no query due to URL call is performed before the push mechanism.

[0143] Alternatively, in the proposed embodiment, the local device to which the second dose data (with or without supplementary data) is transmitted is the reporting system REP 40. The reporting system REP 40 provides a URL to the active push module PPM 14, by means of which the second dose data can be transmitted. Therefore, by means of the URL provided by the reporting system REP 40, it is also ensured that the reporting system REP 40 is indeed prepared for and capable of receiving the second dose data. Due to the provided URL, it is at least expected that the reporting system REP 40 will either be able to receive the second dose data (with or without supplementary data), or that the reporting system will react erroneously if it (currently) cannot receive the second dose data.

[0144] In the push method, the correct allocation of the second dose data provided by the active push module PPM 14 is ensured by the corresponding explicit study identification feature value ESIK, which—by means of the above-mentioned optional variant of de-identification and re-identification via the medical data gateway MDGW 10 (specifically: via the identification service provided by the medical data gateway MDGW 10)—acts as a "magic cookie".

[0145] Therefore, in step S50, the URL provided by the reporting system REP 40 is invoked via the proactive push module PPM 14 to check the provided conditions, namely, to check whether there are any incomplete tasks in the reporting system REP 40 that are associated with the explicit research identification feature value ESIK, as has also been referred to. Figure 1 and Figure 2 The description specifically mentions a "login number." Therefore, the login number can be used as a "magic cookie" between systems that are otherwise completely different: on the one hand, in a local area network (LIN) reporting system like REP 40, typically installed and implemented in a protected hospital environment; and on the other hand, in a cloud-based dose management system like CBDMS 20, implemented as a public cloud solution for global use.

[0146] Additionally, the described identification / de-identification method also reconciles the following requirement: in a local area network (LAN) LIN, data must be associated with patients (or at least be able to be associated with patients), which is exactly what is not desired in a cloud solution.

[0147] In step S60, under the affirmative provision of conditions, the URL can eventually be invoked again to transmit, i.e., to provide (with or without supplementary) second dose data. Regarding the (with or without supplementary) second dose data, the above variations and options are again feasible.

[0148] Figure 5 A schematic diagram is shown illustrating a method according to another embodiment of the invention, namely, a method for providing dose data from a cloud-based dose management system (CBDMS) in a local area network (LIN). However, the method according to this embodiment offers additional advantages. Furthermore, Figure 5 The present invention describes a system 100 according to another embodiment of the second aspect of the invention, namely a system for providing dose data from a cloud-based dose management system (CBDMS) in a local area network (LIN).

[0149] Figure 6 The flowchart in the middle belongs to Figure 5 The flowchart schematically illustrates the various method steps again in the context.

[0150] This implementation basically describes local area network (LAN), such as the one mentioned above. Figures 1 to 4 The interaction between one or all of the graphs described by the local intranet and the national dose database or dose registry (or national REG).

[0151] according to Figure 5 and Figure 6 The method is largely based on Figure 5 and Figure 6 The methods are the same or similar, so that only the differences are described below, which can be used and understood as alternatives, but also as feasible supplements within the scope of the above embodiments.

[0152] Correspondingly, the current description is as follows: the dose data providing module DDBM includes the dose registration module DRM16 instead of the active push module PPM14. It should be understood that the dose data providing module DDBM may include not only the dose registration module DRM16, but also the active push module PPM, and may even include the reactive pull module RPM12.

[0153] Reference Figure 5 and Figure 6 Steps S10 to S20, with optional steps S1 and / or S2, are performed as described above.

[0154] In the current case, the trigger conditions are also checked via the dose data provision module DDBM, specifically in the same way as described above regarding steps S36 and S37. The difference is that, in this embodiment, the dose registration module DRM 16 performs the aforementioned steps.

[0155] Finally, in step S60, the second dose data (with or without supplementary data) is provided to the registration site service system REG 50 within the local intranet LIN.

[0156] Subsequently, in step S70, the third dose data based on the second dose data DD2 is transmitted to the National Dose Registration Calculation Unit NDRR 150 via the Registration Site Service System REG 50. The third dose data DD3 may be the same as (with or without supplementary) the second dose data DD2, or may, for example, contain extracts from it and / or include calculations based thereon.

[0157] Advantageously, the third dose data is mapped to the LOINC-compatible RadLex protocol (i.e., correctly assigned to each other), and in particular, each individual scan examined is mapped to the LOINC-compatible RadLex protocol.

[0158] In step S80, the Registration Site Service System REG 50 receives dose reference data DBD from the National Dose Registration Calculator 150.

[0159] Subsequently, in step S90, the registration site service system REG 50 informs the dose registration module DRM 16 of the availability of new dose reference data DBD.

[0160] Subsequently, in step S100, the dose registration module DRM 16 uploads the new dose reference data DBD to the cloud-based dose management system CBDMS 20. Therefore, the new dose reference data is again available as supplementary information regarding the second dose data DD2, or as part of the second dose data DD2, for example, for the reactive pull module RPM 12 and / or the active push module PPM 14.

[0161] also, Figures 1 to 6Embodiments of system 100 according to embodiments of the present invention will be described separately. As already described several times, the embodiments can also be combined such that system 100 can also be provided having a reactive pull module RPM 12, an active push module PPM 14, and a dose registration module DRM 16, or a selection thereof.

[0162] Figure 7 A schematic block diagram is shown for illustrating a computer program product 200 according to an embodiment of the third aspect of the present invention. The computer program product 200 includes executable program code 250 configured to, when executed, perform a method according to an embodiment of the first aspect of the present invention, particularly as shown in the embodiment of the first aspect of the present invention. Figures 1 to 6 The method is illustrated by one or more diagrams in the diagram.

[0163] Figure 8 A schematic block diagram is shown illustrating a computer-readable non-volatile data storage medium 300 according to an embodiment of the fourth aspect of the present invention. The computer-readable non-volatile data storage medium 300 includes executable program code 350 configured to, when executed, perform a method according to an embodiment of the first aspect of the present invention, particularly as shown in the embodiment of the first aspect of the present invention. Figures 1 to 6 The method is illustrated by one or more diagrams in the diagram.

[0164] Computer-readable media can also be data storage devices such as magnetic storage devices (e.g., magnetic core storage, magnetic tape, magnetic card, magnetic stripe, magnetic bubble storage, roller storage, hard disk, floppy disk, or replaceable storage), optical storage devices (e.g., holographic storage, optical tape, transparent tape (Tesafilm), laser optical disc, phase-change optical storage (Phasewriter Dual, PD), or ultra-density optical disc (UDO)), magneto-optical storage devices (e.g., miniature optical disc or magneto-optical disc (MO disk)), volatile semiconductor / solid-state storage devices (e.g., random access memory (RAM), dynamic RAM (DRAM), or static RAM (SRAM)) or non-volatile semiconductor / solid-state storage devices (e.g., read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrical EPROM (EEPROM), flash EEPROM (e.g., USB Memory Stick), ferroelectric RAM (FRAM), magnetoresistive RAM (MRAM), or phase-change RAM).

[0165] Although specific implementations have been illustrated and described herein, it will be apparent to those skilled in the art that multiple alternatives and / or equivalent implementations exist. It should be understood that the exemplary designs or implementations are merely examples and are not intended to limit the scope, availability, or configuration in any way. Rather, the above overview and detailed description provide a sufficient illustration for those skilled in the art to implement at least one preferred implementation, wherein it should be understood that different variations in the function and arrangement of the elements described in the exemplary designs do not exceed the scope of application shown in the appended claims and their legal equivalents. Generally, this application is intended to cover all modifications or variations of the specific implementations discussed herein.

[0166] For example, all processes, concepts, system components, and / or methodological steps described regarding dose data or dose data management can be similarly applied to comparison management or protocol management.

[0167] In the detailed description above, different features are summarized in one or more instances to keep the disclosure concise. It should be understood that the above description is illustrative and not restrictive. The description should cover all alternatives, variations, and equivalents that may be included within the scope of this invention. Several other examples will become apparent to those skilled in the art upon studying the above disclosure.

[0168] To enable a full understanding of the invention, specific terminology used in the foregoing disclosure is employed. However, given that the description contained herein will be clear to those skilled in the art, the specific details of the invention need not be applied. Therefore, the foregoing description of specific embodiments of the invention is shown for illustrative and descriptive purposes. The description is not intended to be exhaustive or to limit the invention to the precise embodiments disclosed above; obviously, various modifications and variations are possible with respect to the foregoing teachings. Embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby providing other experts with the possibility of best applying the invention and different embodiments with different modifications and seemingly suitable for corresponding uses. Throughout the specification, the terms “comprising” and “wherein” are used as equivalents to the corresponding terms “including” or “in which”. Furthermore, the terms “first,” “second,” “third,” etc., are used only as names and are not intended to impose numerical requirements on objects or presuppose a particular priority. In conjunction with this specification and the claims, the conjunction “or” should be understood as acceptance (“and / or”) and not as exclusive (“either…or”).

Claims

1. A method for providing dose data from a cloud-based dose management system (CBDMS) in a local area network (LIN), comprising: Research data is received (S10) from the image archiving and communication system PACS (3) within the local intranet at the medical data gateway MDGW (10) within the local intranet, based on at least one predefined selection criterion; Based on the received research data, at least the first dose data is uploaded (S20) to the cloud-based dose management system CBDMS (20) through the medical data gateway MDGW (10), wherein the first dose data includes or indicates at least one corresponding explicit research identification feature value ESIK; The dose data provision module DDBM (12; 14; 16) implemented in the medical data gateway MDGW (10) within the local intranet checks (S32) whether a predefined trigger condition exists, and if so, then: Generate a user token, which is used to obtain at least one corresponding explicit research identification feature value ESIK and a corresponding deidentified explicit research identification feature value diESIK from the medical data gateway MDGW (10), wherein the user token is generated based on a service access token, and wherein the deidentified explicit research identification feature value cannot be associated with a specific patient. The dose data provision module DDBM (12; 14; 16) downloads (S40) second dose data based on the first dose data from the cloud-based dose management system CBDMS (20), wherein the second dose data includes or indicates the corresponding explicit study identification feature value ESIK; as well as The second dose data is provided (S60) either automatically or when predefined provision conditions are met to the reporting system REP (40) within the local intranet (LIN) or another local device (30; 50). The dose data providing module DDBM includes a reactive pull module RPM (12) that provides a URL, wherein the predefined triggering condition includes receiving a call to the provided URL, wherein, upon call, the URL includes at least one corresponding explicit research identification feature value ESIK and the service access token as parameters of the URL.

2. The method according to claim 1, The explicitly identified feature value ESIK is at least one of the following features and / or is based on at least one of the following features: - Login number AN, which represents the process number in the radiology information system (30) within the local intranet (LIN); - Patient identification feature value PIK; and / or - Research Entity UID, which is designed to explicitly identify research related to the Structured Reporting Document (SDR).

3. The method according to claim 1 or 2, The URL can be invoked by the local device (30; 50) within the local intranet (LIN) to request the second dose data via the local device (30; 50); and The second dose data is provided to the local device (30; 50) via the reactive pull module RPM (12).

4. The method according to claim 3, During the URL call at the local device (30; 50), the service access token is checked by the reactive pull module RPM (12) to verify the call, and the predefined triggering condition includes successful verification of the service access token SAT.

5. The method according to claim 3, The local device mentioned above is the Radiology Information System (RIS) (30).

6. The method according to claim 1 or 2, The dose data providing module DDBM includes an active push module PPM (14). The predefined triggering conditions include receiving information from the cloud-based dose management system CBDMS (20) that the study has been fully uploaded to the cloud-based dose management system CBDMS (20).

7. The method according to claim 1 or 2, The medical data gateway MDGW (10) de-identifies the first dose data and uploads the first dose data in a de-identified form to the cloud-based dose management system CBDMS (20).

8. The method according to claim 7, The medical data gateway MDGW (10) re-identifies the downloaded second dose data based on the corresponding explicit research identification feature value ESIK through the dose data providing module DDBM (12; 14; 16).

9. The method according to claim 1 or 2, This includes, as part of or in addition to, the information provided regarding standard protocol allocations and / or standard reference values.

10. The method according to claim 1 or 2, The predefined provisioning condition VDB includes a positive result of the following check: whether there is currently an incomplete task at the reporting system REP (40) associated with the explicit study identification feature value ESIK, which is associated with the second dose data.

11. The method according to claim 1 or 2, The dose data providing module DDBM includes a dose registration module DRM (16). When the study has been fully uploaded to the cloud-based dose management system CBDMS (20), the cloud-based dose management system CBDMS (20) informs (S36) the dose registration module DRM (16) implemented in the medical data gateway MDGW (10). Subsequently, the dose registration module DRM (16) provides (S60) the second dose data (DD2) to the registration site service system REG (50), which is the local device within the local intranet (LIN). The registration site service system REG (50) transmits (S70) the third dose data (DD3) based on the second dose data (DD2) to the National Dose Registration Calculator NDRR (150).

12. The method according to claim 11, The Registration Site Service System (REG) receives (S80) dose reference data (DBD) from the National Dose Registration Calculation Unit (NDRR) (150). Subsequently, the REG (50) informs the Dose Registration Module (DRM) (16) of the availability of new dose reference data (DBD). Then, the DRM (16) uploads (S100) the new dose reference data (DBD) to the cloud-based dose management system (CBDMS) (20).

13. The method according to claim 1 or 2, The cloud-based dose management system CBDMS (20) additionally functions as a global dose registry, a cloud-based comparison management system, and / or a cloud-based protocol management system.

14. A system (100) for providing dose data from a cloud-based dose management system (CBDMS), comprising: The medical data gateway MDGW (10) within the local area network of the system, wherein the medical data gateway MDGW (10) constitutes a dose data provision module DDBM for implementing the dose data provision module; The reporting system REP within the local area network; and The cloud-based dose management system (CBDMS) is located outside the local area network. The system configuration described therein is used to perform the method according to any one of claims 1 to 13.

15. A computer program product (200) comprising executable program code (250) configured to perform the method according to any one of claims 1 to 13 when the program code is executed.

16. A computer-readable non-volatile data storage medium (300) comprising executable program code (350) configured to perform the method according to any one of claims 1 to 13 when the program code is executed.

Images