System and method for radiation input in dose management

Abstract

Various methods and systems are provided for the agnostic transmission of radiation information data. For example, the Radiation Manual Input Tool (RMET) includes a series of worklist access components configured to receive a first user input requesting access to a modality worklist via a network, convert the first user input from a first format to a second format, transmit the first user input via the network, and receive the requested modality worklist via the network. The RMET further includes a series of data submission components configured to receive a second user input containing manually entered radiation dose information for the requested modality worklist via the network, convert the second user input from a first format to a second format, transmit the second user input via the network, and receive a message confirming receipt of the manually entered radiation dose information for the scheduled procedure of the requested modality worklist via the network.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims priority to U.S. Patent Application No. 18 / 305,017, filed on April 21, 2023, with the title "SYSTEMS AND METHODS FOR RADIATION ENTRY IN DOSE MANAGEMENT". The entire content of the aforementioned application is incorporated herein by reference for all purposes.

[0002] Each example of the subject matter disclosed in this document relates to the analysis and management of radiation through the transmission of agnostic medical data.

Background Art

[0003] Medical data and radiation information collected by an irradiation modality that administers radiation to a patient are typically stored in a database of a radiation dose management system. Some irradiation modalities may be configured to interact only with a dose management system and its database that uses some format for data composition. For example, an irradiation modality may be tied to a supplier of a particular radiation dose management system. When each irradiation modality is configured by the manufacturer of the radiation dose management system to enable direct communication between the two, the operation of these irradiation modalities is dedicated to this radiation dose management system, which can lead to delays and / or cumbersome processes when the radiation dose management system is updated. Additionally, this can result in network traffic and complexity when a healthcare system (e.g., a hospital) includes irradiation modalities configured to communicate using formats for different data compositions with a radiation information system and / or a dose management system.

[0004] Some radiation modalities may not include components that automatically output medical data and radiation information to a dose management system, and therefore may not be configured to interact with a dose management system. In these embodiments, hospitals may manage radiation data administered to patients through manual data entry by manually reading radiation data from the radiation modality console and manually reporting the radiation data as a data file. Manually recorded data may be entered into a dose management system via its own manual entry (ME) component. However, not all dose management systems include an ME component, and there is no known standalone radiation manual entry application that can agnostically connect to any dose management system using a standardized data transfer method. [Prior art documents] [Patent Documents]

[0005] [Patent Document 1] U.S. Patent Application Publication No. 2012 / 0106817 [Overview of the Initiative]

[0006] In one example, a system for the agnostic transmission of radiation dose data includes a Radiation Manual Input Tool (RMET) having a series of worklist access components configured to receive a first user input via a network requesting access to a modality worklist, convert the first user input from a first format to a second format, transmit the first user input via the network to a radiation information system (RIS) coupled to the network, and receive the requested modality worklist from the RIS via the network. The RMET further includes a series of data submission components configured to receive a second user input via the network containing manually entered radiation dose information, convert the second user input from a first format to a second format, transmit the second user input via the network to a dose management system (DMS) coupled to the network, and receive a message via the network confirming receipt of the manually entered radiation dose information regarding the scheduled procedure for the requested modality worklist.

[0007] A method for the agnostic transmission of medical data that can be performed by RMET includes the steps of receiving a first user input in a first format via a network, which is a first user input requesting access to a modality worklist; converting the first user input in the first format to a second format; transmitting the first user input in the second format via the network to access the requested modality worklist; and receiving the requested modality worklist via the network. The user can interact with the received modality worklist via a user interface and manually input radiation dose data as the second user input. The method further includes the steps of receiving a second user input in a first format via a network, which includes manually entered radiation dose information for the scheduled procedures of a requested modality worklist; converting the second user input in the first format to the second format; transmitting the second user input in the second format via the network to submit the manually entered radiation dose information for the scheduled procedures of a modality worklist; and receiving a message confirming receipt of the manually entered radiation dose information for the scheduled procedures.

[0008] RMET may be used in a medical environment that includes a workstation that displays a user interface and is operationally coupled to a network, a RIS operationally coupled to the network, a DMS operationally coupled to the network, and RMET itself. RMET is configured to receive a first user input in a first format requesting access to a modality worklist from the workstation via the network, convert the first user input to a second format and / or a third format, send the first user input to the RIS via the network, receive the requested modality worklist from the RIS, receive a second user input in a first format from the workstation via the network, which includes manually entered radiation dose information for the scheduled procedure of the requested modality worklist, convert the second user input in the first format to a second format and / or a third format, send the information from the second user input to the DMS via the network, and receive a message from the DMS confirming receipt of the manually entered radiation dose information for the scheduled procedure.

[0009] It should be understood that the above brief description is provided in a simplified form to introduce various concepts that will be further described in the detailed description. Such description is not intended to identify the principal or essential features of the claimed subject matter, and the scope of the claimed subject matter is uniquely defined by the claims following the detailed description. Furthermore, the claimed subject matter is not limited to any embodiment that solves any of the shortcomings described above or in any part of this disclosure. [Brief explanation of the drawing]

[0010] This disclosure will be better understood by reading the following detailed description of non-limiting examples in relation to the attached drawings.

[0011] [Figure 1] This is a schematic block diagram of a medical environment including a Radiation Manual Input Tool (RMET). [Figure 2A]This diagram shows the RMET method for submitting manually entered data to the Dose Management System (DMS). [Figure 2B] This diagram shows the RMET method for submitting manually entered data to the Dose Management System (DMS). [Figure 3] This diagram shows the method of the Radiation Information System (RIS) for sending modality worklists to RMET. [Figure 4] This diagram shows how DMS receives manually entered data from RMET. [Figure 5] This diagram shows a first example of a user interface used to access a scheduled worklist and share radiation dose data. [Figure 6] This figure shows a second example of a user interface used to share manually entered radiation dose data. [Figure 7] This diagram shows an example configuration of a manual input method based on "Digital Images and Communications in Healthcare" (DICOM® [registered trademark]). [Figure 8] This is a sequence diagram of the first example of a manual input method based on DICOM(R). [Figure 9] This diagram shows an example configuration of a manual data entry method based on mixed Fast Health Information Interoperability Resources (FHIR(R)) / DICOM(R). [Figure 10] This is a sequence diagram of a second example of a manual input method based on mixed FHIR(R) / DICOM(R) formats. [Figure 11] This diagram shows an example configuration of a manual input method based on FHIR(R). [Figure 12] This is a sequence diagram of the third example of a manual input method based on FHIR(R). [Modes for carrying out the invention]

[0012] This document describes methods and systems for the agnostic transmission of manually entered radiation dose data to a dose management system (DMS). Since some irradiation modalities are not configured to transmit data to the DMS, and some DMSs do not include a manual entry (ME) component, this document introduces a Radiation Manual Entry Tool (RMET). The RMET includes components that enable agnostic communication with various elements of the medical system for transmitting radiation dose data to the DMS. The methods and systems described in this document enable the DMS to receive and store radiation dose data from irradiation modalities not configured to communicate directly with the DMS. This may allow the DMS to store a larger amount of data.

[0013] While some DMSs may include ME tools, existing ME tools may have difficulties communicating with third-party tools. For example, communication between the front-end and back-end components of an existing ME tool may involve a proprietary application programming interface (API). Manually entered data may also be packaged with proprietary tags that are incomprehensible to third-party DMSs. The RMET described in this document enables the sharing of manually entered radiation dose data among different stakeholders by collecting, transforming, and sharing data using standardized methods, thereby improving the interoperability and quality of the shared data.

[0014] Figure 1 shows a medical environment in which RMET may be deployed. The medical environment includes RMET, a workstation used by users to input radiation dose data, a Radiation Information System (RIS) that stores modality worklists, and a Data Management System (DMS) that stores radiation dose data. Figures 2A and 2B show how RMET requests access to the modality worklist from the RIS and submits manually entered radiation dose data to the DMS. Figure 3 shows how the RIS delivers the modality worklist to RMET, and Figure 4 shows how the DMS receives manually entered radiation dose data from RMET. Figure 5 shows a first example user interface displayed on the workstation and accessible by the user to access the modality worklist. Figure 6 shows a second example user interface, also displayed on the workstation and accessible by the user to manually enter radiation dose data. The RIS and DMS in the medical environment of Figure 1 may include different formats for data organization in different embodiments. For example, Figures 7 and 8 show methods and sequence diagrams for manual data entry based on Digital Images and Communications in Healthcare (DICOM(R)), respectively. Figures 9 and 10 show methods and sequence diagrams for manual data entry based on mixed Fast High-Speed ​​Interoperability Resources (FHIR(R)) / DICOM(R), respectively. Figures 11 and 12 show methods and sequence diagrams for manual data entry based on FHIR(R), respectively.

[0015] Moving to Figure 1, the medical environment 100 is illustrated as a schematic block diagram. The medical environment 100 includes an RMET 150, which may be stored in a server 110 that is communicably coupled to the network of the medical environment 100 via wired and / or wireless connections. The RMET 150 includes several components that enable the RMET 150 to receive user input, convert data between different formats for data composition, transmit data, and receive responses to the transmitted data from other elements of the medical environment 100. These will be described in more detail in this document.

[0016] The medical environment 100's network also includes a user input system, such as a workstation 120, which includes a user interface (UI) 122 and a display device 124. As described in more detail in this document, users can interact with the workstation 120 to submit user inputs to the RMET 150, such as requests to access modality worklists and submissions of manually entered radiation dose data. The medical environment 100 also includes a DMS 140 and a RIS 130, which are also connected to the network in a communicative manner. In some embodiments, the DMS 140 and the RIS 130 may each be stored in a location remote from the server 110 where the RMET 150 is stored, and which is connected to the network in operation. For example, the RIS 130 may be stored in a first location 132 and the DMS 140 may be stored in a second location 142. In some examples, the DMS 140 and the RIS 130 may be stored in the same location. As will be described in more detail in this book, DMS140 and RIS130, respectively, may use the same or different formats for data organization, such as the DICOM(R) standard and / or the FHIR(R) standard. For example, RIS130 may be a radiology laboratory including a DICOM(R) modality worklist (MWL) server and / or an MWL server based on FHIR(R). FHIR(R) is a standard for medical data exchange published by Medical Level 7 (HL7(R)) that defines several mechanisms used to exchange data sequentially without loss of meaning or misunderstanding of data during transmission between parties. The FHIR(R) API may enable the sharing of summaries of radiology procedures related to a specific patient using standardized FHIR(R) resources. This can help third parties easily integrate the data of the radiology procedure summaries into their applications without the use of a DICOM(R) interpreter. DICOM(R) is a standard for the communication and management of medical imaging information and related data, widely used for storing and transmitting medical images, and enabling the integration of multiple medical imaging devices (e.g., irradiation modalities) from numerous manufacturers into the same medical environment.The RIS130 can store at least one modality worklist, which is a scheduled worklist of procedures, for hospital modalities such as irradiation modalities and / or imaging systems. The DMS140 may include a DICOM(R) Listener Service Class Provider (SCP) and / or a radiation server based on FHIR(R). The DMS140 can store radiation information, including medical data and radiation dose data, and may be communicably coupled to one or more third-party tools for the analysis of radiation data.

[0017] The medical environment 100 may include one or more irradiation modalities 160 that collect radiation dose data, and this data may be manually entered into the RMET 150. However, one or more irradiation modalities 160 may not be communicably connected to the network and / or DMS 140. For example, at least one of the one or more irradiation modalities 160 may not include the DICOM(R) standard and / or FHIR(R) standard for radiation dose data output. Irradiation events may be performed by one of the one or more irradiation modalities 160, and radiation dose data may be read from the irradiation modality's console and manually recorded by the user (e.g., written and / or entered into an Excel(R) file). Manually recorded data may be submitted to the DMS 140 via the RMET 150, which will be described in more detail in this document with respect to Figures 2A and 2B.

[0018] RMET150 includes a worklist access component series 152 and a data submission component series 154. The worklist access component series 152 is configured to receive a first user input requesting access to a modality worklist via the network, convert the first user input from a first format to a second format, transmit the first user input (e.g., in the second format) to the RIS130 via the network, and receive the requested modality worklist from the RIS130 via the network. In some embodiments, the worklist access component series 152 is further configured to convert the first user input from the second format to a third format according to the format standard of the RIS130 that stores the requested worklist modality. The data submission component series 154 is configured to receive a second user input including manually entered radiation dose data via the network, convert the second user input from a first format to a second format, transmit the second user input to the DMS140 via the network, and receive a message via the network to confirm receipt by the DMS140 of the manually entered radiation dose information for the scheduled procedure of the requested modality worklist.

[0019] In some examples of RMET150 configurations, as further described with respect to Figures 7 to 12, the components of the Worklist Access Component Series 152 and the Data Submission Component Series 154 can be stored in the front and back ends of RMET150. For example, the Worklist Access Component Series 152 includes a Hypertext Markup Language (HTML) Worklist Access Component 156 and optionally a DICOM(R) MWL Collector 158. The Data Submission Component Series 154 includes a Radiation Manual Input POST Component 162 and optionally a DICOM(R) Structured Report (SR) Generator 164. The HTML worklist access component 156 of worklist access component series 152 and the radiation manual input POST component 162 of data submission component series 154 may be stored in the front end, while the DICOM(R) MWL collector 158 of worklist access component series 152 and the DICOM(R) SR generator 164 of data submission component series 154 may be stored in the back end. Communication between the front end and the back end may be enabled by the FHIR(R) standard. Front-end components may communicate with RIS130 and / or DMS140 through standard FHIR(R) services. Back-end components may communicate with RIS130 and / or DMS140 through standard DICOM(R) message service element (DIMSE) services.

[0020] The component used to connect RMET150 to RIS130 and / or DMS140 in terms of operation (e.g., sending and receiving data from each other) can be automatically selected by the RMET150 method based on the format of the data format standards used by RIS130 and DMS140. This will be described again with reference to Figures 2A and 2B. Briefly speaking, one or more back-end components do not need to be used by RMET150 to send and receive data. For example, if the format of the data format used by DMS140 is known and the front-end component of RMET150 is configured in the format of the data format used by DMS140, then the front-end component of RMET150 can be used, and the unused back-end component does not need to be loaded into the server 110 storing RMET150. If the format of the DMS140 is unknown, all components of the RMET150 may be loaded into the server 110, and each back-end component may be loaded and / or activated into the server 110 as needed during the operation as described in this document with respect to Figures 2A to 4. This reduces the processing demand of the RMET150 compared to loading all back-end components even if some are not used. In another example, all back-end components may be loaded regardless of whether the data format of the DMS140 is known or not. In this way, even if an additional DMS140 with a different data format is added to the medical environment 100, the RMET150 can already be configured to communicate with this additional DMS140, thus reducing the waiting time for sending data to the new DMS140 compared to when the additional components of the RMET150 must be loaded into the server 110.

[0021] As described in this document, RMET150 includes components that enable DMS140 to receive dose data from one or more irradiation modalities 160, regardless of the output data format (or lack thereof) of one or more irradiation modalities 160. In other words, RMET150 improves interoperability in the medical environment and enhances the quality of shared data by enabling agnostic sharing of manually entered data using a standardized method for collecting and sharing dose data. RMET150 can be agnostically connected to any DMS using a standardized data transfer method, and irradiation data can be manually entered into the DMS. The RMET150 system and method can improve the performance of the DMS because it can enable DMS140 to receive and store irradiation data from many more modalities, not just those that output data in the same data format as the DMS140 is configured to use. This further improves network efficiency by reducing the amount of network data transferred.

[0022] Moving to Figures 2A and 2B, Method 200 is shown, which requests access to the Modality Worklist and submits manually entered radiation dose data to the DMS. Method 200 described herein can be executed by RMET150 in Figure 1, and therefore, references to RIS and DMS should be interpreted as referring to RIS130 and DMS140 in Figure 1. Instructions for Method 200 are stored in the memory of Server 110 and can be executed by the processor of Workstation 120. The processor can receive inputs / requests / selections that can be entered by the user via the UI (e.g., UI122 of Workstation 120 in Figure 1) as described herein.

[0023] In block 202, method 200 includes the step of receiving a first user input in a first format requesting access to a modality worklist. The first user input may be entered by a user via a user interface such as UI 122 of workstation 120 in Figure 1. The first user input may be transmitted from workstation 120 to RMET via the network of the medical environment 100. The request for access to the modality worklist may include interacting with UI 122 to select an irradiation modality from a list of irradiation modalities (e.g., one or more irradiation modalities 160 in Figure 1), selecting a time frame for the modality worklist, etc. For example, the first user input may include a request for RMET to collect a list of irradiation events / procedures performed by the first irradiation modality over a week. The first format of the first user input may be HTML or other standard markup language for the displayed document.

[0024] In block 204, method 200 includes a step of converting a first user input from a first format to a second format. For example, the first user input may be received by the HTML worklist access component 156 of the worklist access component series 152, and component 156 can convert the first user input from HTML format to an FHIR(R) standard format, such as an FHIR(R) service request query. The first format may be the original format, such as HTML, when the first user input was submitted via workstation 120. The second format is a first standard data format configuration, which may be available by RIS 130 and / or DMS 140, in this case an FHIR(R) standard format. In other embodiments, other data format standards may be utilized by at least one of the workstations 120, RIS 130, and DMS 140, and each element of RMET 150 that converts user input (e.g., first user input and second user input) from the first format to the second format, and from the second format to the third format, may be adapted to elements corresponding to other data format standards. As described herein, "converting" user input from the first format to the second format, and from the second format to the third format, may involve changing the structure, packaging, or other appearance of the user input data while preserving the data information. For example, the HTML Worklist Access Component 156 may include a library of instructions (e.g., queries and responses) in both HTML format and FHIR(R) standard format, and thus it is possible to translate the requests of the first user input from HTML format to FHIR(R) format, thereby converting the data of the first user input from the first format to the second format.

[0025] In some embodiments of the medical environment 100, the data format of the RIS may be known to the RMET. For example, during the initial setup of the RMET (e.g., connecting the RMET to the medical environment network) and / or during the connection of the RIS to the medical environment network, the format of the data format used by the RIS may be submitted to the RMET. In these cases, as described again with respect to Figures 7 to 12, the first user input may be automatically converted from the first format to the format used by the RIS. For example, if it is known that the RIS does not accept the second format and therefore the modality worklist cannot be collected by the RIS, instead of sending the first user input in the second format to the RIS, the first user input may be converted from the first format to the second format and from the second format to the third format prior to being sent to the RIS. Operation 204 of method 200 can proceed to operation 210 without proceeding through operations 206 to 208. This reduces the processing demand on the RMET and improves the efficiency of data transmission in the medical environment.

[0026] In block 206, method 200 includes the step of sending a first user input in a second format to the RIS to request access to a modality worklist stored in the RIS. Depending on the format of the RIS's data structure, the RIS may or may not be able to receive the first user input in an usable format. For example, if the RIS is configured to operate using the FHIR(R) standard (for example, as described again with respect to Figure 11, the RIS includes an MWL server based on FHIR(R)), then the first user input as an FHIR(R) service request query (e.g., the second format) may be received by the RIS in an usable format. Details regarding the reception of the first user input from the RIS's perspective are described with respect to Figure 3. If the RIS is not configured to operate using the FHIR(R) standard, then the first user input as an FHIR(R) service request query may not be received by the RIS in an usable format, and therefore the RIS cannot retrieve the requested modality worklist.

[0027] If, in block 208, RMET determines that it has not received the requested modality worklist from the RIS, method 200 proceeds to block 210 to convert the first user input from the second format to the third format. The third format is a second standard data format configuration that may be available from RIS 130 and / or DMS 140, in this case the DICOM(R) standard format. For example, in response to not receiving the requested modality worklist, method 200 may determine that the first user input is not in a format available from the RIS. A back-end component of the worklist access component series (e.g., DICOM(R) MWL collector 158) may convert the first user input from the second format (e.g., FHIR(R) service request query) to the third format (e.g., DICOM(R) MWL query).

[0028] In block 212, method 200 includes the step of sending the first user input in a third format to the RIS to request access to the modality worklist again. The RIS may or may not be able to receive the first user input in an available format. For example, if the RIS is configured to operate using the DICOM(R) standard (for example, the RIS includes a DICOM(R) modality worklist, as described again with respect to Figure 7), then the first user input as a DICOM(R) MWL query (e.g., in the third format) may be received by the RIS in an available format. Details regarding the reception of the first user input from the RIS's perspective are described with respect to Figure 3. If the RIS is not configured to operate using the DICOM(R) standard, then the first user input as a DICOM(R) MWL query may not be received by the RIS in an available format, and therefore the RIS cannot retrieve the requested modality worklist.

[0029] In block 214, if it is determined that RMET has not received the requested modality worklist from RIS, method 200 proceeds to block 216, in which RMET outputs the message "RIS connection failed" to the workstation (e.g., display device 124 on workstation 120). Method 200 then terminates.

[0030] Moving on to Figure 3, a method 300 for retrieving the requested modality worklist is shown. Method 300 can be executed by the RIS 130 in Figure 1. The instructions for method 300 can be stored in the memory of the RIS 130 and executed by the processor of the RIS 130. The processor can receive inputs / requests / selections that can be entered by the user via the UI (e.g., UI 122 of workstation 120 in Figure 1) and sent to the RIS 130 by the RMET 150 via the network of the medical environment 100, as described in this document.

[0031] In block 302, method 300 includes the step of receiving a first user input from RMET. As described with respect to Figures 2A to 2B, the first user input may be sent to the RIS in a second or third format. If the first user input is in a format different from the format in which the RIS is configured, the RIS cannot receive the first user input. The RIS can receive the first user input in block 302 if the format of the first user input is the same as the format in which the RIS is configured, as described above with respect to Figures 2A to 2B.

[0032] In block 304, method 300 includes the step of retrieving a requested modality worklist. The RIS can store multiple worklists for multiple irradiation modalities in each environment in which the RIS is integrated (e.g., in the RIS's memory). For example, a worklist for a given irradiation modality may include an entry for each irradiation event performed and / or scheduled to be performed by the irradiation modality. This entry may include one or more of the following: an equipment identifier (e.g., name, identification number, and model number), the date and time the inspection was performed or will be performed, the patient name and / or other patient identifiers, the type of irradiation event, and the operator identifier. A first user input may request a modality worklist for one of multiple irradiation modalities (e.g., one or more irradiation modalities 160 in Figure 1), for example, for a given time frame. The RIS can retrieve the requested modality worklist from its memory by searching the stored worklists for the requested modality worklist.

[0033] In block 306, method 300 includes the step of sending the requested modality worklist to RMET. The requested modality worklist may be sent to RMET in the RIS data format, which is also the data format of the first user input. For example, if the first user input is sent to RIS as a DICOM(R)MWL query, as described again with respect to Figures 7 and 8, the requested modality worklist may be sent to RMET as a DICOM(R)MWL response. Method 300 then terminates.

[0034] Returning to Figures 2A and 2B, if it is determined in blocks 214 and 208 that RMET has received the requested modality worklist from the RIS, method 200 proceeds to block 218 and outputs the requested modality worklist for display (e.g., to the display device 124 of workstation 120). An example of the display of the requested modality worklist is shown in Figure 5, which will be explained further.

[0035] Moving on to Figure 5, a first display example 500 is shown, which includes elements for accessing the requested modality worklist 550. The first display example 500 can be displayed, for example, on the display device 124 of the workstation 120 and may include the requested modality worklist retrieved from the RIS 130 by the RMET 150 in accordance with the methods described with respect to Figures 2A to 2B and Figure 3. The first display example 500 also includes a filter 520 that can be used to select the desired entry or format from the entries of the requested modality worklist 550. For example, the requested modality worklist 550 may be filtered by location (e.g., healthcare provider / location), device (e.g., individual device or type of device), and patient, etc. The filter 520 may be used to identify irradiation events for which radiation dose data has been manually recorded (e.g., read from the irradiation modality console and entered into an Excel(R) file).

[0036] The requested modality worklist 550 contains multiple entries within the range of parameters requested by the first user input (e.g., time frame, device, operator, and device type). The requested modality worklist 550 includes columns for each device, examination date and time, management number, patient name, patient ID, whether dose information has been entered for each entry, and each of the operation buttons 554. The indicator 552 can indicate whether dose information (e.g., radiation dose data) has been entered for each irradiation event. For example, a check mark may indicate that radiation dose data for each entry is included in the radiation information (e.g., sent to DMS140 using RMET150). An X mark may indicate that radiation dose data has not been entered for each irradiation event.

[0037] The user can interact with the UI (for example, UI 122 on workstation 120) to select an irradiation event from the requested modality worklist 550 that does not contain radiation information. For example, the user can select an operation button 554 that opens a second display containing further details of the selected irradiation event, as shown in Figure 6.

[0038] Figure 6 shows a second display example 600 containing details of an irradiation event selected from a requested modality worklist, as described in relation to Figure 5. The second display example 600 includes general information 620 such as the device name, examination content, and examination date and time, and patient information 640 including the patient's name, weight, and height. The second display example 600 further includes a manual input field 650 for entering radiation dose data (e.g., total dose-length product (DLP)) for the selected irradiation event. The user can manually enter the radiation dose data collected by the irradiation modality (e.g., the device indicated by the category in general information 620) into the manual input field 650 and submit the radiation dose data to the DMS 140, as described later in relation to Figures 2A and 2B, by selecting the "Save" button 652. In some cases, by selecting the "Save" button 652, the manually entered radiation dose data and related information (e.g., general information 620 and patient information 640) are temporarily stored, and the user returns to the first display example 500 in Figure 5, where one or more additional irradiation events can be selected and the corresponding radiation dose data can be manually entered in the same manner as described with respect to Figure 6. Following the manual entry of radiation dose data for one or more irradiation events, the "Submit" button (not shown in either Figure 5 or Figure 6) can be selected to submit the radiation dose data for one or more irradiation events as a single user input to the DMS 140. This reduces the amount of network data transferred and thus helps to improve the efficiency of the medical environment 100.

[0039] Returning to Figures 2A and 2B, in block 220, method 200 includes the step of receiving a second user input in a first format (e.g., HTML) which includes manually entered radiation dose data. For example, as described with respect to Figure 6, the second user input may include radiation dose data and corresponding identification information (e.g., patient identification information and the date and time of the event) for one or more irradiation events in a requested modality worklist retrieved from the RIS. The user can interact with the workstation UI to enter manually recorded radiation dose data from the irradiation modality and submit the manually entered data and corresponding information to the RMET (for example, by selecting a “Save” or “Submit” button as described with respect to Figure 6).

[0040] In block 222, method 200 includes a step of converting a second user input from a first format (e.g., HTML) to a second format. For example, the second user input may be received by the Radiation Manual Input POST component 162 of the Data Submission Component Series 154, which can convert the second user input from HTML format to an FHIR(R) standard format such as FHIR(R) observation.

[0041] In some embodiments of the medical environment 100, the data format of the DMS may be known to the RMET. For example, during the initial setup of the RMET (e.g., the RMET's connection to the medical environment network) and / or during the DMS's connection to the medical environment network, the data format used by the DMS may be submitted to the RMET. In these cases, the second user input may be automatically converted from the first format to the format used by the DMS, as described again with respect to Figures 7 to 12. For example, if it is known that the DMS does not accept the second format and therefore the radiation dose data cannot be received by the DMS, instead of sending the second user input in the second format to the DMS, the second user input can be converted from the first format to the second format and then converted from the second format to the third format before being sent to the DMS. Operation 222 of method 200 can proceed to operation 228 without proceeding through operations 224 to 226. This reduces the processing demand on the RMET and improves the efficiency of data transmission in the medical environment.

[0042] In block 224, method 200 includes the step of sending a second user input in a second format to the DMS in order to submit manually entered radiation dose data to the DMS's storage. Depending on the format of the DMS's data structure, the DMS may or may not be able to receive the second user input in an usable format. For example, if the DMS is configured to operate using the FHIR(R) standard (for example, the DMS includes an FHIR(R)-based radiation server, as described again with respect to Figure 11), then the second user input as an FHIR(R) observation (e.g., in the second format) may be received by the DMS in an usable format. Details regarding the reception of the second user input from the DMS's perspective are described with respect to Figure 4. If the DMS is not configured to operate using the FHIR(R) standard, then the second user input as an FHIR(R) observation may not be received by the DMS in an usable format, and therefore the DMS cannot receive the manually entered radiation dose data.

[0043] In block 226, if it is determined that the RMET has received an acknowledgment message from the DMS, method 200 proceeds to block 238, where it outputs an acknowledgment message from the DMS indicating that the manually entered radiation dose data has been received by the DMS for display (e.g., to the display device 124 of the workstation 120). Method 200 then terminates.

[0044] Moving on to Figure 4, a method 400 for receiving manually entered radiation dose data is shown. Method 400 can be performed by the DMS 140 in Figure 1. Instructions for method 400 are stored in the memory of the DMS 140 and can be executed by the processor of the DMS 140. The processor can receive inputs / requests / selections that can be entered by the user via a UI (e.g., UI 122 of the workstation 120 in Figure 1) and sent to the DMS 140 by the RMET 150 via the network of the medical environment 100, as described in this document.

[0045] In block 402, method 400 includes the step of receiving a second user input from RMET. As described with respect to Figures 2A to 2B, the second user input may be sent to the DMS in a second or third format. If the second user input is in a format different from the format in which the DMS is configured, the DMS cannot receive the second user input. The DMS can receive the second user input in block 402 if the format of the second user input is the same as the format in which the DMS is configured, as described above with respect to Figures 2A to 2B.

[0046] In block 404, method 400 includes a step of storing information from a second user input. For example, the DMS may store radiation dose data, as well as corresponding information such as patient information and / or general information as described in Figure 6 (e.g., in the DMS's memory).

[0047] In block 406, method 400 includes the step of sending a confirmation message to RMET. Following the receipt and storage of the second user input, DMS may generate a confirmation message in DMS data format (e.g., the same data format as the second user input) which may include text or other indicators that the manually entered radiation dose data has been received by DMS. DMS sends the confirmation message to RMET via the network of the medical environment 100. Method 400 ends.

[0048] Returning to Figures 2A and 2B, if it is determined in block 226 that the RMET has not received an acknowledgment message from the DMS, method 200 proceeds to block 228 (Figure 2B) to convert the second user input from the second format (e.g., FHIR(R) standard) to the third format (e.g., DICOM(R) standard). For example, as described with respect to Figure 4, after the DMS receives the second user input, the DMS may send an acknowledgment message to the RMET indicating that the radiation dose data has been received. If the RMET has not received an acknowledgment message in block 226, method 200 may determine that the second user input in the second format may not be available to the DMS. The back-end component of the data submission component series 154 (e.g., the DICOM(R)SR generator 164) can convert the second user input from the second format (e.g., FHIR(R) observation(R)) to the third format (e.g., DICOM(R)SR).

[0049] In block 230, method 200 includes the step of sending a second user input in a third format to the DMS in order to store manually entered radiation dose data in the DMS. The DMS may or may not be able to receive the second user input in an usable format. For example, if the DMS is configured to operate using the DICOM(R) standard (for example, the DMS includes a DICOM(R) listener SCP, as described again with respect to Figure 7), then the second user input as DICOM(R)SR (e.g., the third format) may be received by the DMS in an usable format. Details regarding the reception of the second user input from the DMS's perspective are described with respect to Figure 4. If the DMS is not configured to operate using the DICOM(R) standard, then the second user input as DICOM(R)SR may not be received by the DMS in an usable format, and therefore the DMS cannot store the manually entered radiation dose data and cannot send a confirmation message to the RMET.

[0050] In block 232, if it is determined that RMET has not received an acknowledgment message from DMS, method 200 proceeds to block 236, where RMET outputs a message to the workstation (e.g., display device 124 on workstation 120) indicating that "DMS connection failed". Method 200 then terminates. In block 232, if it is determined that RMET has received an acknowledgment message from DMS, method 200 proceeds to block 234, where it outputs an acknowledgment message from DMS indicating that the manually entered radiation dose data has been received by DMS for display (e.g., on display device 124 on workstation 120). Method 200 then terminates.

[0051] By implementing Method 200, the RMET150 can enhance the data storage capacity of the DMS140 and reduce network transfer volume, thereby increasing the efficiency of data transmission and improving the quality of medical data. For example, the DMS140 can be enabled to store medical information and radiation dose data from irradiation modalities that are not directly connected to the DMS140, thus enabling the radiation dose data from these imaging modalities to be stored in a standardized format. This can improve the accessibility of radiation dose data by third-party tools. In addition, as will be described in more detail later, the RMET150 can be adjusted to different operating modes based on medical environment conditions such as the data format configuration of the DMS140 and / or RIS130, thereby increasing the efficiency of the RMET150 and the medical environment by reducing data transmission time. This can further reduce network transfer volume, as the RMET150 can transmit output to the RIS130 and DMS140 in a format usable by the RIS130 and DMS140, as will be described in more detail later.

[0052] Figures 7 to 12 show three example scenarios in which the operation of RMET150 may be adjusted to correspond to the data format used by DMS140 and / or RIS130. For example, elements such as the DICOM(R) MWL collector 158 and DICOM(R) SR generator 164 of the Worklist Access Component Series 152 and / or Data Submission Component Series 154 are configured to connect RMET150 to RIS130 and DMS140 in operation when RIS130 and DMS140 are configured according to the DICOM(R) standard. In medical environment configurations where RIS130 and DMS140 are not configured according to the DICOM(R) standard, the DICOM(R) MWL collector 158 and DICOM(R) SR generator 164 may be omitted from RMET150 as described with respect to Figures 1 to 2B, or they may be included in RMET150 but in a non-operational state. This can reduce the processing demands of the RMET150 and / or help shorten the time it takes to transmit data to the DMS140.

[0053] Figure 7 shows a first configuration example, a manual input method 700 based on DICOM(R). Method 700 may be an adaptation of Method 200 in Figures 2A to 2B, and can be implemented by RMET150 when both RIS130 and DMS140 include the DICOM(R) standard for sending and receiving data. For example, RIS130 includes a DICOM(R) modality worklist component 710, and DMS140 includes a DICOM(R) listener SCP720. All components of RMET150 described in relation to Figure 1 are operational and loaded into server 110, and can be used to convert user input from a first format (e.g., HTML) to a second format (e.g., FHIR(R) standard), and from the second format to a third format (e.g., DICOM(R) standard), so that the modality worklist can be retrieved from RIS130 and the manually entered data can be submitted to DMS140. RMET150 can perform at least part of method 200 as described with respect to Figures 2A to 2B, RIS130 can perform at least part of method 300 as described with respect to Figure 3, and DMS140 can perform at least part of method 400 as described with respect to Figure 4.

[0054] A user can interact with workstation 120 and submit a first user input to RMET 150. Workstation 120 can send the first user input, formatted as HTML, to RMET 150 via the network of the medical environment 100 (1). For example, RMET 150 can communicate with workstation 120 via the Hypertext Transfer Protocol (HTTP). RMET 150's HTML worklist access component 156 can receive the first user input in HTML format, convert the first user input from HTML format (e.g., first format) to an FHIR(R) service request (e.g., second format), and send the first user input in second format to the DICOM(R) MWL collector 158 (2). As briefly described above, it may be known that DMS 140 and RIS 130 are configured to communicate using the DICOM(R) standard. The DICOM(R) MWL collector converts the first input from an FHIR(R) service request (e.g., the second format) to a DICOM(R) modality worklist (MWL) query (e.g., the third format) and sends the first input in the third format to the RIS130 (3). The RIS130 includes a DICOM(R) modality worklist component 710, and as described with respect to Figure 3, the RIS130 receives the MWL query (e.g., the first user input in the third format), locates and retrieves the requested modality worklist in the RIS130's memory, and can send the requested modality worklist to the RMET150. For example, the requested modality worklist may be sent as an MWL response to the DICOM(R) MWL collector in the RMET150. The requested modality worklist may be output for display, for example, on the UI122 of the workstation 120 (e.g., as shown in Figure 5).

[0055] The user can interact with the workstation 120 to submit a second user input to the RMET 150. For example, as described with respect to Figures 2A to 2B and Figures 5 to 6, the user can select a procedure from the requested modality worklist displayed on the UI 122 of the workstation 120 and submit radiation dose information for the selected procedure (a). In some examples, more radiation dose information for more than one procedure in the modality worklist may be submitted as the second user input. The second user input can be submitted in the first format (e.g., HTML) and received by the radiation manual input POST component 162 of the RMET 150, which is configured to convert the information of the second user input from HTML to an FHIR(R) observation (e.g., the second format). The radiation manual input POST component 162 can then post (e.g., send) the second user input as an FHIR(R) observation to the DICOM(R) SR generator 164 of the RMET 150 (b). The DICOM(R)SR generator 164 converts the second user input from an FHIR(R) observation (e.g., in a second format) to a DICOM(R)SR (e.g., in a third format) and sends the second user input as a DICOM(R)SR from the RMET 150 to the DMS 140, where the DICOM(R)SR may be received by the DMS 140's DICOM(R) listener SCP 720 (c). For example, the DICOM(R)SR generator 164 can execute the C-store protocol to send the DICOM(R)SR to the DMS 140 and instruct the DMS 140 to store the DICOM(R)SR. In response to receiving and storing the second user input (e.g., as a DICOM(R)SR), the DMS 140 can send a message to the RMET 150 confirming receipt of the manually entered radiation dose data for one or more scheduled procedures in the modality worklist.For example, this message may be data based on at least one of auditory, visual, and / or textual information, and may include data indicating that manually entered radiation dose information (e.g., second user input) regarding the scheduled procedure of the requested modality worklist has been received by DMS140.

[0056] Moving to Figure 8, a sequence diagram 800 is shown illustrating the data conversion and transmission by each element of the medical environment 100 as described in Figure 7. Elements from Figure 7 that are included in Figure 8 are given similar names and numbers. Figure 8 describes an embodiment of the disclosed system and method in which the first data format is HTML, the second format is FHIR(R), the third format is DICOM(R), and RIS130 and DMS140 each include elements according to the DICOM(R) standard. In other embodiments, one or more different formats, as well as associated query and response protocols, may be used.

[0057] At arrow 802, the user can access the front end of RMET150 through the user desktop (e.g., workstation 120) to access the scheduled procedure worklist. The step of accessing the front end of RMET150 involves submitting a first user input requesting access to the modality worklist stored in RIS130. The HTML worklist access component 156 converts the first user input from a first format (e.g., HTML) to a second format (e.g., FHIR(R)). At arrow 804, the front-end component of RMET150 makes a request to the back-end component of RMET150. More precisely, the HTML worklist access component 156 can make an FHIR(R) lookup query to the DICOM(R) MWL collector 158 for service request resources. The FHIR(R) lookup query is associated with an FHIR(R) service request lookup as described in Figure 7. For example, the collected FHIR(R) service request resources can be analyzed by HL7(R) and mapped to imaging service requests using HL7(R)V2 messages and DICOM(R)MWL messages. At arrow 806, the DICOM(R)MWL collector 158 performs MWL C-FIND-QR (e.g., converting a first user input to a second format and then to a third format) to collect the requested modality worklist from RIS 130 based on the parameters provided in the FHIR(R) service request query (e.g., the first user input). The DICOM(R)MWL collector 158 may be configured to periodically query the DICOM(R) modality worklist component 710 of RIS 130 to periodically collect and cache details of scheduled procedures stored in the modality worklist of RIS 130. At arrow 808, RIS130 sends a DICOM(R)MWL response containing the requested modality worklist to DICOM(R)MWL collector 158.The DICOM(R)MWL collector 158 converts the DICOM(R)MWL response into a bundle of FHIR(R) standard service request resources (e.g., an FHIR(R) service request), and at arrow 810, sends the FHIR(R) service request to the front end of the RMET 150 (e.g., the HTML worklist access component 156). At arrow 812, the FHIR(R) service request is converted into a primary format (e.g., HTML) by the HTML worklist access component 156 and output for display on the display device 124 of the workstation 120.

[0058] At arrow 814, the user selects a scheduled procedure (e.g., an entry from the requested modality worklist) via the UI 122 of workstation 120 and manually enters radiation dose data for the selected procedure into an HTML form (e.g., second display example 600). The contents of the HTML form are submitted to the Radiation Manual Input (ME) POST component 162 at arrow 816, where the contents (e.g., second user input) are converted into an FHIR(R) observation resource (e.g., second format). The FHIR(R) observation resource may include a radiation dose summary resource containing sufficient radiation information to report radiation dose data related to a given procedure. At arrow 818, an HTTP FHIR(R) post is sent to the DICOM(R) SR generator along with the observation resource. The observation resource conforms to the FHIR(R) and HL7(R) standards regarding the sharing of radiation data with FHIR(R). At arrow 820, the DICOM(R)SR generator 164 generates a DICOM(R)SR object based on the FHIR(R) observation resource received from the front-end application. Here, a mapping from FHIR(R) observation to DICOM(R)SR takes place. The DICOM(R)SR object is sent to the DCM listener SCP720 of the DMS140. A response (e.g., an acknowledgment message) is sent from the DMS140 to the workstation 120 to indicate that the submission of the form with radiation data has been thoroughly considered. For example, at arrow 822, a DCM C-STORE-RSP (response) is sent from the DMS140 to the DICOM(R)SR generator 164 of the RMET150, the DCM C-STORE-RSP is converted to an FHIR(R) response at arrow 824, sent to the front end of the RMET150, and returned to the workstation 120 for display at arrow 826.

[0059] In this way, the RMET150 enables manual input of radiation dose data to the DMS140, and therefore allows the DMS140 to store radiation dose data even if the radiation dose data collected by the irradiation modality is not configured in the output standard used by the DMS140. The RMET150 enables the submission of radiation information to the DMS140 without the use of a manual input tool for the DMS140, which may or may not exist and may be unique to the DMS140. This enhances the memory capacity of the DMS140, allowing it to accept radiation data inputs manually entered into the RMET150, regardless of the original data format of the radiation data. For example, through the use of the RMET150 as described in this document, the DMS140 can receive a larger number of radiation dose data inputs than it could accept without the use of the RMET150.

[0060] In the examples in Figures 7 and 8, all components of the RMET150 described in relation to Figure 1 are used to obtain the modality worklist and submit the dose information to the DMS140. As further described in relation to Figures 9 through 12, when the RIS130 and / or DMS140 use a data format configuration other than DICOM(R), some components of the RMET150 may not be used to retrieve the worklist and / or submit the radiation dose data.

[0061] Moving to Figure 9, a second configuration example is shown for a manual input method 900 based on FHIR(R) and DICOM(R). This method may be an adaptation of method 200 in Figures 2A and 2B and can be implemented by RMET150 when RIS130 includes the FHIR(R) standard and DMS140 includes the DICOM(R) standard for sending and receiving data. For example, RIS130 includes an MWL server 910 based on FHIR(R) and DMS140 includes a DICOM(R) listener SCP720. Since RIS130 is configured to receive transmissions formatted according to the FHIR(R) standard, a component of the worklist access component series 152 (e.g., a DICOM(R) MWL collector 158) used to convert the first user input from the FHIR(R) standard to the DICOM(R) standard can be turned off or excluded from RMET150. RMET150 can perform at least part of method 200 as described with respect to Figures 2A to 2B, RIS130 can perform at least part of method 300 as described with respect to Figure 3, and DMS140 can perform at least part of method 400 as described with respect to Figure 4.

[0062] A user can interact with workstation 120 and submit a first user input to RMET 150. Workstation 120 can send the first user input, formatted as HTML, to RMET 150 via the network of the medical environment 100 (1). The HTML worklist access component 156 of RMET 150 can receive the first user input in HTML format, convert the first user input from HTML format (e.g., first format) to an FHIR(R) service request query (e.g., second format), and send the first user input in second format to RIS 130 (2). As briefly described above, it may be known that RIS 130 is configured to communicate using the FHIR(R) standard. For example, during read / configuration of RMET 150, it may be indicated to RMET 150 that RIS 130 includes an MWL server 910 based on FHIR(R). The DICOM(R) MWL collector 158 at the back end of RMET150 can be deactivated, thus reducing the processing load on RMET150. As shown with respect to Figure 3, RIS130 can receive an FHIR(R) service request query (e.g., the first user input in the second format), locate and retrieve the requested modality worklist in RIS130's memory, and send the requested modality worklist to RMET150. The requested modality worklist can be output for display, for example, on the UI122 of workstation 120 (e.g., as shown in Figure 5).

[0063] The user can interact with the workstation 120 to submit a second user input to the RMET 150. For example, as described with respect to Figures 2A to 2B and Figures 5 to 6, the user can select a procedure from the requested modality worklist displayed on the UI 122 of the workstation 120 and submit radiation dose information for the selected procedure (a). In some examples, more radiation dose information for more than one procedure in the modality worklist may be submitted as a second user input. The second user input can be submitted in the first format (e.g., HTML) and received by the radiation manual input POST component 162 of the RMET 150, which is configured to convert the information of the second user input from HTML to an FHIR(R) observation (e.g., the second format). The radiation manual input POST component 162 can then post (e.g., send) the second user input as an FHIR(R) observation to the DICOM(R) SR generator 164 of the RMET 150 (b). The DICOM(R)SR generator 164 converts the second user input from an FHIR(R) observation (e.g., in a second format) to a DICOM(R)SR (e.g., in a third format) and sends the second user input as a DICOM(R)SR from the RMET 150 to the DMS 140, where the DICOM(R)SR may be received by the DMS 140's DICOM(R) listener SCP 720 (c). For example, the DICOM(R)SR generator 164 can execute the C-STORE protocol to send the DICOM(R)SR to the DMS 140 and instruct the DMS 140 to store the DICOM(R)SR. In response to receiving and storing the second user input (e.g., as a DICOM(R)SR), the DMS 140 can send a message to the RMET 150 confirming receipt of the manually entered radiation dose data for one or more scheduled procedures in the modality worklist.

[0064] Moving to Figure 10, a second sequence diagram 1000 is shown illustrating the data transformation and transmission by each element of the medical environment 100 as described in Figure 9. Elements from Figure 9 that are included in Figure 10 are given similar names and numbers. Figure 10 describes embodiments of the disclosed system and method in which the first data format is HTML, the second format is FHIR(R), and the third format is DICOM(R). RIS130 includes elements of the FHIR(R) standard, and DMS140 includes elements of the DICOM(R) standard. In other embodiments, one or more different formats, as well as associated query and response protocols, may be used.

[0065] The second sequence diagram 1000 is similar to the first sequence diagram 800 in Figure 8, except that operations 806 and 808, in which the DICOM(R) MWL collector 158 converts the first user input from the second format to the third format and sends it to the RIS 130 to collect the requested modality worklist based on the parameters provided in the FHIR(R) service request query, are removed. The method in the second sequence diagram 1000 is as follows: At arrow 1002, the user accesses the front end of the RMET 150 via a desktop (e.g., workstation 120) to access the scheduled procedure worklist. The step of accessing the front end of the RMET 150 includes submitting the first user input requesting access to the modality worklist stored in the RIS 130. The HTML worklist access component 156 converts the first user input from the first format (e.g., HTML) to the second format (e.g., FHIR(R)). At arrow 1004, the front-end component of RMET150 directly queries RIS130 for service request resources using FHIR(R) lookup. For example, the HTML worklist access component 156 sends the first user input in a second format (e.g., FHIR(R) service request query) to the FHIR(R)-based MWL server 910 to collect the requested modality worklist from RIS130 based on the parameters provided in the FHIR(R) service request query (e.g., the first user input). At arrow 1006, the collected modality worklist is returned from RIS130 to the front-end of RMET150 as a service request bundle (e.g., FHIR(R) service request). The HTML worklist access component 156 converts the FHIR(R) service request into an HTML response. At arrow 1008, the retrieved modality worklist is returned to workstation 120 as an HTML response, and the requested modality worklist is output for display on the display device 124 of workstation 120.

[0066] At arrow 1010, the user selects an entry from the collected modality worklist via the UI 122 of workstation 120 and manually enters radiation dose data into an HTML form (e.g., second display example 600). The contents of the HTML form are submitted to the Radiation Manual Input (ME) POST component 162 at arrow 1012, where the contents (e.g., second user input) are converted into an FHIR(R) observation resource (e.g., second format). The FHIR(R) observation resource may include a radiation dose summary resource containing sufficient radiation information to report radiation dose data related to a particular procedure. At arrow 1014, an HTTP FHIR(R) post is sent to the DICOM(R) SR generator along with the observation resource. The observation resource conforms to the FHIR(R) and HL7(R) standards regarding the sharing of radiation data with FHIR(R). At arrow 1016, the DICOM(R)SR generator 164 generates a DICOM(R)SR object based on the FHIR(R) observation resource received from the front-end application. Here, a mapping from FHIR(R) observation to DICOM(R)SR takes place. The DICOM(R)SR object is sent to the DCM listener SCP720 of the DMS140. A response (e.g., an acknowledgment message) is sent from the DMS140 to the workstation 120 to indicate that the submission of the form with radiation data has been thoroughly considered. For example, at arrow 1018, the DCM C-STORE-RSP is sent from the DMS140 to the DICOM(R)SR generator 164 of the RMET150, which is converted to an FHIR(R) response at arrow 1020 and sent to the front end of the RMET150, and then returned to the workstation 120 for display at arrow 1022.

[0067] In this way, RMET150 enables the retrieval of modality worklists from RIS130 and manual input of radiation dose data into DMS140, even when the data format configurations of RIS130 and DMS140 differ. This increases the data receiving capabilities of both RIS130 and DMS140. When the data format configurations of RIS130 and DMS140 are known, and as a result components of RMET150 are started and / or stopped during RMET150 operation, the processing demands of RMET150 can be reduced compared to when all elements of RMET150 are in operation (as described, for example, with respect to Figures 2A to 2B).

[0068] In the examples in Figures 9 and 10, back-end components of the RMET150 used to connect the RMET150 to a RIS that includes a data format configuration not included in the RIS130 are omitted from the operation and / or configuration of the RMET150. As described again with respect to Figures 11 and 12, when the RIS130 and DMS140 use a data format configuration other than DICOM(R), components of the RMET150 used to connect the RIS and DMS (e.g., DICOM(R) modality worklist component 710 and DICOM(R) listener SCP720, respectively) that include DICOM(R) elements are omitted from the RMET150. For example, in the embodiment of the RMET150 described with respect to Figures 11 and 12, both back-end components (e.g., DICOM(R) SR generator 164 and DICOM(R) MWL collector 158) do not need to be used to collect the worklist and / or submit the radiation dose data.

[0069] Moving to Figure 11, a third configuration example is shown for a manual input method 1100 based on FHIR(R). This method may be an adaptation of method 200 in Figures 2A and 2B and can be implemented by RMET150 when RIS130 and DMS140 include the FHIR(R) standard for sending and receiving data. For example, RIS130 includes an MWL server 910 based on FHIR(R) and DMS140 includes a radiation server 1110 based on FHIR(R). Since neither DMS140 nor RIS130 is configured to receive transmissions formatted according to the DICOM(R) standard, the RMET150 components used to convert the first and second inputs to a third format (e.g., DICOM(R)) can be turned off or excluded from RMET150. The front-end components of RMET150 can communicate directly with RIS130 and DMS140. For example, the HTML worklist access component 156 can communicate directly with the RIS 130, and the radiation manual input POST component 162 can communicate directly with the DMS 140. The RMET 150 can perform at least part of method 200 as described with respect to Figures 2A to 2B, the RIS 130 can perform at least part of method 300 as described with respect to Figure 3, and the DMS 140 can perform at least part of method 400 as described with respect to Figure 4.

[0070] A user can interact with workstation 120 and submit a first user input to RMET 150. Workstation 120 can send the first user input, formatted as HTML, to RMET 150 via the network of the medical environment 100 (1). The HTML worklist access component 156 of RMET 150 can receive the first user input in HTML format, convert the first user input from HTML format (e.g., first format) to an FHIR(R) service request query (e.g., second format), and send the first user input in second format to RIS 130 (2). As briefly described above, it may be known that RIS 130 is configured to communicate using the FHIR(R) standard. For example, during read / configuration of RMET 150, it may be indicated to RMET 150 that RIS 130 includes an MWL server 910 based on FHIR(R). The DICOM(R) MWL collector 158 at the back end of RMET150 can be deactivated, thus reducing the processing load on RMET150. As shown with respect to Figure 3, RIS130 can receive an FHIR(R) service request query (e.g., the first user input in the second format), locate and retrieve the requested modality worklist in RIS130's memory, and send the requested modality worklist to RMET150. The requested modality worklist can be output for display, for example, on the UI122 of workstation 120 (e.g., as shown in Figure 5).

[0071] The user can interact with the workstation 120 to submit a second user input to the RMET 150. For example, as described with respect to Figures 2A to 2B and Figures 5 to 6, the user can select a procedure from the requested modality worklist displayed on the UI 122 of the workstation 120 and submit radiation dose information for the selected procedure (a). In some examples, more radiation dose information for more than one procedure in the modality worklist may be submitted as a second user input. The second user input can be submitted in the first format (e.g., HTML) and received by the radiation manual input POST component 162 of the RMET 150, which is configured to convert the information of the second user input from HTML to an FHIR(R) observation (e.g., the second format). The radiation manual input POST component 162 can then post (e.g., send) the second user input as an FHIR(R) observation to the FHIR(R)-based radiation server 1110 of the DMS 140 (b). In response to receiving and storing a second user input (e.g., as an FHIR(R) observation), the DMS140 may send a message to the RMET150 confirming receipt of manually entered radiation dose data for one or more scheduled procedures in the modality worklist.

[0072] Moving to Figure 12, a third sequence diagram 1200 is shown, illustrating the data transformation and transmission by each element of the medical environment 100 as described in Figure 11. Elements from Figure 11 that are included in Figure 12 are given similar names and numbers. Figure 11 describes an embodiment of the disclosed system and method in which the first data format is HTML, the second format is FHIR(R), the third format is DICOM(R), and both RIS130 and DMS include elements of the FHIR(R) standard. In other embodiments, one or more different formats, as well as associated query and response protocols, may be used.

[0073] The third sequence diagram 1200 is similar to the second sequence diagram 1000 in Figure 10, except that operations 1016 and 1018, in which the DICOM(R)SR generator 164 converts the second user input from the second format to the third format and sends the second user input in this format to the DMS 140 for submission of manually entered radiation dose data, are omitted. The method in the third sequence diagram is as follows: At arrow 1202, the user accesses the front end of the RMET 150 via a desktop (e.g., workstation 120) to access the scheduled procedure worklist. The step of accessing the front end of the RMET 150 includes submitting the first user input requesting access to the modality worklist stored in the RIS 130. The HTML worklist access component 156 converts the first user input from the first format (e.g., HTML) to the second format (e.g., FHIR(R)). At arrow 1204, the front-end component of RMET150 directly queries RIS130 for service request resources using FHIR(R). For example, the HTML worklist access component 156 sends the first user input in a second format (e.g., an FHIR(R) service request query) to the FHIR(R)-based MWL server 910 to collect the requested modality worklist from RIS130 based on the parameters provided in the FHIR(R) service request query (e.g., the first user input). At arrow 1206, the collected modality worklist is returned from RIS130 to the front-end of RMET150 as a service request bundle (e.g., an FHIR(R) service request). The HTML worklist access component 156 converts the FHIR(R) service request into an HTML response. At arrow 1208, the retrieved modality worklist is returned to workstation 120 as an HTML response, and the requested modality worklist is output for display on the display device 124 of workstation 120.

[0074] At arrow 1210, the user selects an entry from the retrieved modality worklist via the UI 122 of workstation 120 and manually enters radiation dose data into an HTML form (e.g., second display example 600). The contents of the HTML form are submitted to the Radiation Manual Input (ME) POST component 162 at arrow 1212, where the contents (e.g., second user input) are converted into an FHIR(R) observation resource (e.g., second format). The FHIR(R) observation resource may include a radiation dose summary resource containing sufficient radiation information to report radiation dose data related to a particular procedure. At arrow 1214, an HTTP FHIR(R) post, along with the observation resource, is sent directly to the FHIR(R)-based radiation server 1110 of DMS 140. A response (e.g., a confirmation message) is sent from DMS 140 to workstation 120 to indicate that the submission of the form with radiation data has been thoroughly considered. For example, at arrow 1216, the FHIR(R) response is sent to the front end of RMET150, and at arrow 1218, it is returned to workstation 120 for display.

[0075] In this way, RMET150 enables manual input of radiation dose data to DMS140, and therefore allows DMS140 to store radiation dose data even if the radiation dose data collected by the irradiation modality is not configured in the output standard used by DMS140. RMET150 enables the submission of radiation information to DMS140 without using a manual input tool for DMS140, which is either non-existent or unique to DMS140. Since only the components of RMET150 corresponding to the data format configurations of DMS140 and RIS130 are operational, the processing and memory demands of RMET150 can be reduced compared to when all elements of RMET150 are operational (as described, for example, in relation to Figures 2A to 2B).

[0076] The technical benefits of the systems and methods described in this document include enhanced data storage capabilities of the DMS. RMET enables the agnostic transmission of manually entered radiation dose data collected by irradiation modalities, which may or may not include outputs with standard data format configurations, such as those used by RIS and / or DMS, via the methods described in this document. Thus, data format-related constraints on data that can be stored in the DMS are removed. The use of RMET reduces data transmission time, decreases network transfer volume, shortens the time between irradiation events and the retrieval / utilization of radiation dose data from the DMS by third-party tools, and increases the amount and accuracy of manually entered data stored in the DMS. In addition, RMET can be used in different configurations, further reducing data transmission time and alleviating the processing load on the server and processor hosting and executing the RMET method.

[0077] The Disclosure also provides support for a Radiation Manual Input Tool (RMET), which comprises a series of worklist access components configured to receive a first user input requesting access to a modality worklist via a network, convert the first user input from a first format to a second format, transmit the first user input in the second format via a network, and receive the requested modality worklist via a network; and a series of data submission components configured to receive a second user input containing manually entered radiation dose information for the requested modality worklist via a network, convert the second user input from a first format to a second format, transmit the second user input via a network, and receive a message confirming receipt of the manually entered radiation dose information for the scheduled procedure of the requested modality worklist via a network. In the first example of the system, the worklist access component series is further configured to convert the first user input from the second format to the third format in response to the worklist access component series not receiving the requested modality worklist following the transmission of the first user input in the second format. In the second example of the system, which optionally includes the first example, the worklist access component series includes a hypertext markup language (HTML) worklist access component configured to receive the first user input in the first format, convert the first user input from the first format to the second format, and output the first user input in the second format. In a third example of a system that optionally includes one or both of the first and second examples, the worklist access component series further includes a “Digital Imaging and Communications in Healthcare” (DICOM(R)) modality worklist (MWL) collector configured to receive a first user input in a second format from an HTML worklist access component, convert the first user input from the second format to the third format, and output the first user input in the third format.In a fourth example of a system that optionally includes one or more of the first to third examples, the data submission component sequence is further configured to convert the second user input from the second format to the third format in response to the data submission component sequence not having received a message confirming receipt of manually entered radiation dose information for a scheduled procedure following the submission of a second user input in the second format. In a fifth example of a system that optionally includes one or more of the first to fourth examples, the data submission component sequence includes a radiation manual input POST component configured to receive a second user input in the first format, convert the second user input from the first format to the second format, and output a second user input in the second format. In the sixth example of a system that optionally includes one or more of the first to fifth examples, or each of them selected, the data submission component sequence further includes a "Digital Images and Communications in Healthcare" (DICOM(R)) structured report (SR) generator configured to receive a second user input in a second format from a radiation manual input POST component, convert the second user input from the second format to a third format, and output the second user input in a third format. In the seventh example of a system that optionally includes one or more of the first to sixth examples, or each of them selected, the message includes data based on at least one of auditory, visual, and / or text indicating that manually entered radiation dose information about the scheduled procedure of the requested modality worklist has been received by the dose management system (DMS).

[0078] This disclosure also provides support for a method for a Radiation Manual Input Tool (RMET), the method comprising the steps of: receiving a first user input via a network, which is a first user input in a first format including a standard markup language, requesting access to a modality worklist; converting the first user input in the first format to a second format including a medical data transmission standard; transmitting the first user input in the second format via a network to access the requested modality worklist; receiving the requested modality worklist via a network; receiving a second user input via a network, which is a second user input in the first format, which includes manually entered radiation dose information for the scheduled procedure of the requested modality worklist; converting the second user input in the first format to a second format; transmitting the second user input in the second format via a network to submit the manually entered radiation dose information for the scheduled procedure of the modality worklist; and receiving a message confirming receipt of the manually entered radiation dose information for the scheduled procedure. In the first example of the method, the first format is a hypertext markup language (HTML) or another standard markup language. In the second example of the method, which optionally includes the first example, the second format is Fast Medical Interoperability Resources (FHIR(R)) or another medical data transmission standard. In the third example of the method, which optionally includes one or both of the first and second examples, the method further includes the steps of converting the first user input in the second format to the third format in response to not having received the requested modality worklist, following the transmission of the first user input in the second format, and transmitting the first user input in the third format. In the fourth example of the method, which optionally includes one or more of the first to third examples or each of them, the third format is "Digital Images and Communications in Healthcare" (DICOM(R)) or another medical data transmission standard.In the fifth example of the method, which optionally includes one or more of the first to fourth examples, the method further includes the steps of converting a second user input in the second format to a third format in response to not having received a message confirming receipt of manually entered radiation dose information for a scheduled procedure, and transmitting the second user input in the third format.

[0079] This disclosure also provides support for a system comprising: a user input system implemented on a workstation; a radiation information system (RIS) stored in a first location; a dose management system (DMS) stored in a second location; and a radiation manual input tool (RMET) which is communicably connected to each of the RIS, DMS, and user input systems via a network and stored on a server located remotely from each of the first and second locations, wherein the radiation manual input tool (RMET) takes the steps of: receiving a first user input in a first format requesting access to a modality worklist from the user input system; and converting the first user input to a second format and / or a third format. The instructions include the steps of: sending a first user input to the RIS via the network; receiving a requested modality worklist from the RIS; receiving a second user input from a workstation via the network, in the first format, which includes manually entered radiation dose information for the scheduled procedure of the requested modality worklist; converting the second user input in the first format to the second and / or third format; sending information from the second user input to the DMS via the network; and receiving a message from the DMS confirming receipt of the manually entered radiation dose information for the scheduled procedure. In the first example of the system, the first format is a standard markup language. In the second example of the system, which optionally includes the first example, the second format is the first medical data transmission standard, and the third format is the second medical data transmission standard. In the third example of the system, which optionally includes one or both of the first and second examples, the DMS and RIS each use either the first or second medical data transmission standard. In the fourth example of a system that optionally includes one or more of the first to third examples, or each of them, the DMS is configured to receive the second user input of the second and / or third format and send a message confirming receipt of the manually entered radiation dose information for the scheduled procedure.In the fifth example of a system that optionally includes one or more of the first to fourth examples, or each of them, the RIS is configured to receive the first user input in the second and / or third format and transmit the requested modality worklist.

[0080] Each element of the medical environment 100 and configurations 700 to 1200 can communicate with one another via a network that may be a suitable wired and / or wireless network. One or more of the devices described in this document may be implemented across a cloud or other computer network. The RMET communication module facilitates the transmission of electronic data within and / or between one or more systems. Communication via the communication module may be implemented using one or more protocols. In some examples, communication via the communication module occurs in accordance with one or more standards (e.g., HL7(R) and ANSI X12N). Communication may be via a wired interface (e.g., data bus connection and universal serial bus (USB) connection) and / or a wireless interface (e.g., radio frequency, infrared, and near-field communication (NFC)). For example, the communication module may communicate via a wired local area network (LAN), wireless LAN, and wide area network (WAN) using any past, present, or future communication protocol (e.g., BLUETOOTH®, USB 2.0, and USB 3.0). RMET may further include memory, which includes one or more data storage structures such as optical memory devices, magnetic memory devices, or solid memory devices for storing programs and routines executed by the processor(s) to perform the various functions disclosed herein. Memory may include any desired form of volatile memory and / or non-volatile memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, and read-only memory (ROM). The processor(s) of RMET may be, for example, any suitable processor, processing unit, or microprocessor. The processor(s) may also be a multiprocessor system, which may include one or more additional processors that are equivalent or similar to each other and coupled for communication via an interconnection bus.

[0081] In this book, the terms “sensor,” “system,” “unit,” or “module” may include hardware and / or software systems that operate to perform one or more actions. For example, a sensor, module, unit, or system may include a computer processor, controller, or other logic device that operates based on instructions stored in a tangible, non-transient, computer-readable storage medium such as computer memory. Alternatively, a sensor, module, unit, or system may include a wired device that operates based on the wired logic of the device. The various modules or units shown in the accompanying drawings may represent hardware that operates based on software instructions or wired instructions, software that instructs the hardware to perform these actions, or a combination thereof.

[0082] A “system,” “unit,” “sensor,” or “module” may include or represent hardware and associated instructions (e.g., software stored on a tangible, non-transient, computer-readable storage medium such as a computer hard drive, ROM, or RAM) that perform one or more of the operations described herein. Hardware may include and / or electronic circuits coupled to one or more logic devices such as a microprocessor, processor, or controller. These devices may be off-the-shelf devices appropriately programmed or instructed to perform the operations described herein from the instructions described above. In addition or alternatively, one or more of these devices may be wired to a logic circuit to perform these operations.

[0083] In this way, a new methodology is provided for implementing manually entered radiation data. This method involves standards-based communication with hospital-side components, as opposed to proprietary communication. This method is agnostic to the dose management system and thus provides a vendor-neutral solution. This method is a lightweight, agnostic, and standardized solution using the latest healthcare technology.

[0084] In this book, the terms "element" or "step" described in the singular and preceded by the singular indefinite article should be understood as not excluding the presence of multiple such elements or steps unless explicitly stated as such. Furthermore, references to "an example" of the present invention should not be interpreted as excluding the existence of additional examples that similarly incorporate the described features. Conversely, unless otherwise stated, examples that "comprising," "including," or "having" one or more elements having a particular characteristic may also include additional elements that do not possess that characteristic. The term "including" is used as a standard English synonym for "comprising," and the term "in which" is used as a standard English synonym for "wherein." Furthermore, terms such as "first," "second," and "third" are used merely as labels and do not impose numerical requirements or specific spatial orders on the objects of these terms.

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

[0086] 100 Medical Environment How to request access to the 200 Modality Worklist and submit manually entered radiation dose data to the DMS. How to retrieve the requested modality worklist (300 items) 400 How to receive manually entered radiation dose data 500 First display example including elements for accessing the required modality worklist 520 filters 550 Requested Modality Worklist 552 Indicator 554 Operation Buttons 600 Second display example including details of the irradiation event selected from the requested modality worklist. 620 General information 640 Patient Information 650 Manual input field 652 "Save" button 700 Manual input method based on DICOM(R) 800 Sequence diagram showing data conversion and transmission 900 Manual input method based on FHIR(R) and DICOM(R) 1000 Second sequence diagram showing data conversion and transmission 1100 Manual input method based on FHIR(R) 1200 Third sequence diagram showing data conversion and transmission

Claims

1. Radiation manual input tool (RMET), A series of worklist access components configured to receive a first user input requesting access to a modality worklist via a network, convert the first user input from a first format to a second format, transmit the first user input in the second format via the network, and receive the requested modality worklist via the network, A data submission component sequence configured to receive a second user input via the network, which includes manually entered radiation dose information for the requested modality worklist; convert the second user input from the first format to the second format; transmit the second user input via the network; and receive a message via the network confirming receipt of the manually entered radiation dose information for the scheduled procedure of the requested modality worklist. A radiation manual input tool (RMET) equipped with a radiation manual input tool.

2. The RMET according to claim 1, wherein the worklist access component series is further configured to convert the first user input from the second format to the third format in response to the worklist access component series not receiving the requested modality worklist following the transmission of the first user input in the second format.

3. The RMET according to claim 1, wherein the worklist access component series includes a hypertext markup language (HTML) worklist access component configured to receive the first user input in the first format, convert the first user input from the first format to the second format, and output the first user input in the second format.

4. The RMET according to claim 3, further comprising a “Digital Images and Communications in Medicine” (DICOM®) modality worklist (MWL) collector configured to receive the first user input in the second format from the HTML worklist access component, convert the first user input from the second format to the third format, and output the first user input in the third format.

5. The RMET according to claim 1, wherein the data submission component sequence is further configured to convert the second user input from the second format to the third format in response to the data submission component sequence not having received the message confirming receipt of manually entered radiation dose information for the scheduled procedure following the transmission of the second user input in the second format.

6. The RMET according to claim 1, wherein the data submission component series includes a radiation manual input POST component configured to receive the second user input in the first format, convert the second user input from the first format to the second format, and output the second user input in the second format.

7. The RMET according to claim 6, further comprising a “Digital Images and Communications in Healthcare” (DICOM®) Structured Report (SR) Generator configured to receive the second user input in the second format from the Radiation Manual Input POST component, convert the second user input from the second format to a third format, and output the second user input in the third format.

8. The RMET according to claim 1, wherein the message includes data based on at least one of auditory, visual, and / or text indicating that manually entered radiation dose information for the scheduled procedure of the requested modality worklist has been received by the dose management system (DMS).

9. A method for a Radiation Manual Input Tool (RMET), The steps include receiving a first user input via a network, which is in a first format including a standard markup language and requests access to a modality worklist, A step of converting the first user input of the first format into a second format including a medical data transmission standard, The steps include transmitting the first user input in the second format via the network in order to access the requested modality worklist, The steps include receiving the requested modality worklist via the network, The steps include receiving a second user input via the network, which is a second user input in the first format and includes manually entered radiation dose information for the scheduled procedure of the requested modality worklist, A step of converting the second user input of the first format to the second format, The steps include sending the second user input in the second format via the network in order to submit the manually entered radiation dose information for the scheduled procedure of the modality worklist, A step of receiving a message confirming receipt of the manually entered radiation dose information for the aforementioned scheduled procedure. A method for providing it.

10. The method according to claim 9, wherein the first format is a hypertext markup language (HTML) or another standard markup language.

11. The method according to claim 9, wherein the second format is a High-Speed ​​Medical Interoperability Resource (FHIR(R)) or another medical data transmission standard.

12. The method according to claim 9, further comprising the steps of: converting the first user input in the second format to a third format in response to not having received the requested modality worklist following the transmission of the first user input in the second format; and transmitting the first user input in the third format.

13. The method according to claim 12, wherein the third format is "Digital Images and Communications in Healthcare" (DICOM®) or another medical data transmission standard.

14. The method according to claim 13, further comprising the steps of: converting the second user input in the second format to the third format in response to not having received the message confirming receipt of the manually entered radiation dose information for the scheduled procedure; and transmitting the second user input in the third format.

15. A user input system implemented on the workstation, The Radiation Information System (RIS) stored in the first location, The dose management system (DMS) stored in the second location, A Radiation Manual Input Tool (RMET) is stored on a server located remotely from each of the first and second locations, and is communicably connected to each of the RIS, DMS, and user input systems via a network. A system comprising the following steps: the Radiation Manual Input Tool (RMET) includes instructions to receive a first user input in a first format requesting access to a modality worklist from the user input system; convert the first user input to a second format and / or a third format; transmit the first user input to the RIS via the network; receive the requested modality worklist from the RIS; receive a second user input in the first format from the workstation via the network, which includes manually entered radiation dose information for the scheduled procedure of the requested modality worklist; convert the second user input in the first format to the second format and / or a third format; transmit the information from the second user input to the DMS via the network; and receive a message from the DMS confirming receipt of the manually entered radiation dose information for the scheduled procedure. system.

16. The system according to claim 15, wherein the first format is a standard markup language.

17. The system according to claim 15, wherein the second format is a first medical data transmission standard, and the third format is a second medical data transmission standard.

18. The system according to claim 17, wherein each of the DMS and RIS uses the first medical data transmission standard or the second medical data transmission standard.

19. The system according to claim 15, wherein the DMS is configured to receive the second user input of the second format and / or the third format and to send the message confirming receipt of the manually entered radiation dose information for the scheduled procedure.

20. The system according to claim 15, wherein the RIS is configured to receive the first user input in the second format and / or the third format and transmit the requested modality worklist.

Images