System and method for facilitating radiation advisory

Abstract

Systems, devices, and methods provide for matching patient data to an individual patient. For example, such operations include determining a data requirement based on content of a consultation request for a consultation. Missing information is identified based on the determined data requirements by retrieving available data from the data source and identifying unavailable data based on the retrieved available data and the determined data requirements. A summary is generated by extracting clinical information related to performing the consultation from the retrieved available data. The summary is prioritized in the context of the consultation request and the identified unavailable data is highlighted.

Description

Technical Field

[0001] The following generally relates to medical records. More specifically, embodiments herein relate to managing patient data for radiologist consultation support. Background Art

[0002] In a patient care environment, patient data typically exists from various sources. Generally, healthcare platforms (e.g., performance management data platforms, virtualized imaging solutions, interoperability solutions, electronic medical records (EMR), radiology information systems (RIS), picture archiving and communication systems (PACS), etc.) typically have information about patients.

[0003] For example, in a radiology context, a radiology information system (RIS) has information about patients, a picture archiving and communication system (PACS) has all the images, and machine logs have information about imaging protocols and timestamps of various activities that occurred while the patient was on the machine. However, none of these systems create a complete record of patient care.

[0004] Typically, data for the same patient is usually kept in different information silos, and these individual data packets are usually not coordinated for use by radiologists. Current methods of extracting patient data from various sources are typically done manually by sifting through logs, making phone calls, and having conversations with different people in the hospital. Such operations are laborious and prone to human error.

[0005] In addition to the primary task of integrating clinical information, image data, and clinical interpretations, radiologists also have the responsibility of providing consultations for technicians, referring physicians, radiology residents, physicians from other disciplines, etc. Research has shown that these activities take up more than 26% of a radiologist's time, while image interpretation tasks take up approximately 37% of the time.

[0006] Certain improvements that overcome these and other problems are disclosed below. Summary of the Invention

[0007] As mentioned above, providing complete data to radiologists for consultation tasks is currently challenging. Consultation tasks mainly include solving problems related to the clinical management of patients, research review, answering order questions, image quality checks, protocol requests, process questions, protocols, etc., for which radiologists will refer to the research and the patient's clinical background. For all these examples, the research and the patient's clinical background are typically used to perform these tasks.

[0008] Although clinical decision support systems have been developed to improve the efficiency and quality of report interpretation, there is a lack of systems that facilitate the consultation task. Incomplete or missing information or redundant, irrelevant, or fragmented data are typically presented to radiologists, which takes time to navigate to the information of interest or additional communication.

[0009] Similar to report interpretation, the ability to appropriately collect, extract, and interpret patient information is generally useful for providing quality consultations. However, incomplete or missing information or redundant, partially irrelevant data from various sources are typically presented to radiologists, which generally takes time to collect and integrate clinical data.

[0010] For example, the clinical information needed to provide an appropriate consultation varies depending on the specific consultation task. For protocol preparation, radiologists typically utilize patient demographics (e.g., height, weight), laboratory data (e.g., estimated glomerular filtration rate (eGFR)), and the patient's current and previous clinical background to obtain an overall view of the patient. For image quality inspection, radiologists typically will access the Digital Imaging and Communications in Medicine (DICOM) images of current and previous studies, study information (e.g., modality, protocol, etc.), contrast agent use, modality settings, patient clinical background (e.g., relevant history and physical examination), etc. There are also cases where radiologists will utilize access to DICOM or console information, and the DICOM or console information can be shared via real-time access to the DICOM / console system, enabling screen sharing of captured screenshots for remote viewing.

[0011] As will be described in more detail below, in some embodiments discussed herein, a radiologist consultation support system is described that provides basic clinical background to radiologists in a prioritized and summarized manner. Such embodiments can save time, improve quality, and / or reduce potential errors. One aspect of the radiologist consultation support system is to infer data requirements based on specific consultation requests to ensure access to all necessary data. The radiologist consultation support system then presents prioritized summary data according to the consultation request to enable efficient access to an accurate and overall view of the patient background.

[0012] In some embodiments discussed herein, systems, devices, and methods provide for matching patient data to an individual patient. For example, such operations include determining data requirements based on the content of the consultation request for the consultation. Missing information is identified based on the determined data requirements by retrieving available data from data sources and identifying unavailable data based on the retrieved available data and the determined data requirements. A summary is generated by extracting clinical information relevant to performing the consultation from the retrieved available data. The summary is prioritized and the identified unavailable data is highlighted in the context of the consultation request.

[0013] In one aspect, a radiologist consultation support system includes an inference module, a missing data module, a summarization module, and a prioritization module. The inference module is configured to determine data requirements based on the content of a consultation request for a consultation. The missing data module is communicatively coupled to the inference module to identify missing information based on the determined data requirements by retrieving available data from a data source module, and to identify unavailable data based on the retrieved available data and the determined data requirements. The summarization module is communicatively coupled to the missing data module to generate a summary by extracting clinical information related to performing the consultation from the retrieved available data. The prioritization module is communicatively coupled to the summarization module to prioritize the summary and highlight the identified unavailable data in the context of the consultation request.

[0014] In another aspect, a method for radiologist consultation support includes determining data requirements via an inference module based on the content of a consultation request for a consultation. Via a missing data module communicatively coupled to the inference module, unavailable data is identified based on the determined data requirements by retrieving available data from a data source module and based on the retrieved available data and the determined data requirements, thereby identifying missing information. Via a summarization module communicatively coupled to the missing data module, a summary is generated by extracting clinical information related to performing the consultation from the retrieved available data. Via a prioritization module communicatively coupled to the summarization module, the summary is prioritized and the identified unavailable data is highlighted in the context of the consultation request.

[0015] In yet another aspect, at least one machine-readable storage includes a set of instructions that, when executed by a computing device, cause the computing device to determine data requirements based on the content of a consultation request for a consultation. Missing information is identified based on the determined data requirements by retrieving available data from a data source and based on the retrieved available data and the determined data requirements. A summary is generated by extracting clinical information related to performing the consultation from the retrieved available data. The summary is prioritized and the identified unavailable data is highlighted in the context of the consultation request.

[0016] In yet another aspect, a device for radiologist consultation support includes means for determining data requirements based on the content of a consultation request for a consultation. Means for identifying missing information is based on the determined data requirements by retrieving available data from a data source and based on the retrieved available data and the determined data requirements. Means for generating a summary is based on extracting clinical information related to performing the consultation from the retrieved available data. Means for prioritizing the summary and highlighting the identified unavailable data operates in the context of the consultation request.

[0017] It should be understood that all combinations of the foregoing concepts and the additional concepts discussed in more detail below (assuming these concepts are not mutually contradictory) are considered to be part of the subject matter disclosed herein. In particular, all combinations of the claimed subject matter appearing at the end of this disclosure are contemplated as part of the subject matter disclosed herein. It should also be understood that terms explicitly employed herein that also may appear in any incorporated by reference disclosure should be accorded a meaning most consistent with the particular concepts disclosed herein.

[0018] These and other aspects of the various embodiments will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Upon reading the following specification and the appended claims, and by reference to the following drawings, the various advantages of the embodiments will become apparent to those of ordinary skill in the art, wherein:

[0020] Figure 1 is a diagrammatic illustration of a block diagram of an exemplary radiologist consultation support system according to an embodiment;

[0021] Figure 2 is a diagrammatic illustration of a block diagram of another exemplary radiologist consultation support system according to an embodiment;

[0022] Figure 3 is a diagrammatic illustration of a flowchart of data extraction according to an embodiment;

[0023] Figure 4 is a diagrammatic illustration of a user interface according to an embodiment;

[0024] Figure 5 is a diagrammatic illustration of another user interface according to an embodiment;

[0025] Figure 6 is a diagrammatic illustration of a flowchart of a method for managing radiologist consultations for an individual patient according to an embodiment;

[0026] Figure 7 is a diagrammatic illustration of a flowchart of another method for managing radiologist consultations according to an embodiment;

[0027] Figure 8 is a diagrammatic illustration of a block diagram of a computer program product according to an embodiment;

[0028] Figure 9 is a further illustration of an EMR management system according to an embodiment; and

[0029] Figure 10 is a diagrammatic illustration of a hardware device including a semiconductor package according to an embodiment. DETAILED DESCRIPTION

[0030] In some embodiments discussed herein, as will be described in more detail below, systems, devices, and methods provide for matching patient data to an individual patient. For example, such operations include determining data requirements based on the content of a consultation request for a consultation. Missing information is identified based on the determined data requirements by retrieving available data from data sources and identifying unavailable data based on the retrieved available data and the determined data requirements. A summary is generated by extracting clinical information relevant to performing the consultation from the retrieved available data. The summary is prioritized and the identified unavailable data is highlighted in the context of the consultation request.

[0031] Advantageously, some implementations of the radiologist consultation support system described herein help improve the quality and efficiency of the radiologist's communication system. Additionally or alternatively, the radiologist consultation support system can also be used as a pre-check of an order or consultation request to ensure that relevant and essential data is provided to the radiologist in response to the request.

[0032] Figure 1 FIG. is a diagrammatic illustration of a block diagram of an exemplary radiologist consultation support system 100 according to an embodiment. For example, the radiologist consultation support system 100 can be centralized or can be distributed and can include some or all of the elements and components of one or more computers or computer systems.

[0033] In the illustrated implementation, the radiologist consultation support system 100 can include a main platform 102 (e.g., also referred to herein as a care platform). In some embodiments, the main platform 102 can be embodied as a server computer or multiple server computers (e.g., interconnected to form a server cluster, cloud computing resources, etc. and / or combinations thereof).

[0034] In some embodiments, the main platform 102 is a care platform designed for one or more aspects of patient care. In such an example, the main platform 102 includes one or more of the following care platforms: a performance management data platform, a medical asset tracking and tracing system, a virtualized imaging solution, a centralized care management system, an interoperability solution, an electronic medical record (EMR), a radiology information system (RIS), a picture archiving and communication system (PACS), etc. In a patient care environment, there may be many care platforms connected to various clinical and operational data sources (e.g., Health Level 7 (HL7), Fast Healthcare Interoperability Resources (FHIR), machine logs, real-time location systems (RTLS), sensors, etc.). As described above, due to technology or platform limitations, all of these data sources typically only have partial data about an individual patient.

[0035] In some implementations, the first application 104 to the Nth application 106, which may include the radiologist consultation support application 108, can be associated with the main platform 102. As will be described in more detail below, the operation of the radiologist consultation support application 108 provides patient data that matches an individual patient. For example, such operations include determining data requirements based on the content of a consultation request for a consultation. Missing information is identified based on the determined data requirements by retrieving available data from a data source and identifying unavailable data based on the retrieved available data and the determined data requirements. A summary is generated by extracting clinical information related to performing the consultation from the retrieved available data. The summary is prioritized and the identified unavailable data is highlighted in the context of the consultation request.

[0036] Additionally or alternatively, the radiologist consultation support system 100 can include a patient monitor 110, sensors 112 (e.g., one or more sensors 112 that may be associated with a care facility, sensors 112 that may be associated with a patient 114, etc. and / or combinations thereof), a treatment device 116, a medical management device 118, a medical imager 119, a database 120, a user interface 122 (e.g., one or more user interfaces 122 may be associated with a user 124), an information system 126, etc. and / or combinations thereof. For example, the main platform 102, the patient monitor 110, the sensors 112, the treatment device 116, the medical management device 118, the medical imager 119, the database 120, the user interface 122, and / or the information system 126 can communicate with each other via Internet-based communication, cloud-based communication, wired communication, wireless communication, etc. and / or combinations thereof.

[0037] In an example, the patient monitor 110 can be used to access patient data from the database 120 and / or input patient data into the database 120. For example, the patient monitor 110 can determine measured patient data (e.g., via one or more of the sensors 112). In such examples, the patient monitor 110 can be configured to monitor a patient's vital signs, etc., and the patient monitor 110 can transmit such measured patient data to the database 120. For example, the sensors 112 can determine dynamic patient condition data including a patient's vital signs (e.g., blood pressure, pulse, temperature, respiration, etc.) and / or patient test results (e.g., creatinine level, urine flow, potassium level, oxygen saturation, blood glucose level, carbon dioxide level, etc.).

[0038] In some embodiments, the patient monitor 110 can include a bedside monitor, a transport monitor, a central station monitor, etc. and / or combinations thereof.

[0039] In some embodiments, sensor 112 can be a minimally invasive sensor (e.g., by piercing the skin, sensing through the skin, etc. and / or combinations thereof). Sensor 112 can be wired or wireless.

[0040] In another example, treatment device 116 can be used to access patient data from database 120 and / or input patient data into database 120. For example, treatment device 116 can determine measured patient data. In such an example, treatment device 116 can be configured to monitor the delivery of a particular treatment (e.g., non-pharmacological intervention) to a patient and can transmit such measured patient data to database 120.

[0041] In some embodiments, treatment device 116 can supply and / or monitor the administration of one or more patient procedures (e.g., dialysis).

[0042] In another example, medical management device 118 can be used to access patient data from database 120 and / or input patient data into database 120. For example, medical management device 118 can determine measured patient data. In such an example, medical management device 118 can be configured to monitor the delivery of medications to a patient and can transmit such measured patient data to database 120. In some embodiments, medical management device 118 can supply and / or monitor the administration of one or more patient medications (e.g., blood pressure medications, diuretic medications, anti-anemia medications, cholesterol-lowering medications, vitamin supplements, etc.).

[0043] In some examples, medical imager 119 includes one or more medical imaging devices, medical imaging systems, etc. and / or combinations thereof. For example, medical imager 119 includes magnetic resonance imaging (MRI) devices, ultrasound devices, X-ray devices, computed tomography (CT) devices, radiology information systems (RIS), picture archiving and communication systems (PACS), etc. and / or combinations thereof. In such embodiments, medical imager 119 is associated with standardized format medical imaging information for transmitting, storing, retrieving, printing, processing, and displaying medical imaging information (e.g., Digital Imaging and Communications in Medicine (DICOM) data).

[0044] Additionally or alternatively, in yet another example, the user interface 122 can be used to access patient data from the database 120 and / or input patient data into the database 120. In some embodiments, the user interface 122 can be implemented via one or more form factor devices (e.g., smart phone, tablet computer, laptop computer, workstation, etc.), an interface associated with the main platform, and / or an interface associated with the patient monitor 110. Additionally or alternatively, a care provider (e.g., user 124) can access and / or input patient data through an analog device, a non-networked patient monitor, a non-networked treatment device, a non-networked medical management device, etc. and / or a combination thereof.

[0045] In the illustrated embodiment, the database 120 can include one or more types of patient data. For example, the database 120 can include patient data, including medical images, laboratory result data, microbiology data, drug data, vital sign data, care order data, admission / discharge and transfer data, etc. As used herein, the term "database" refers to a collection of data and information organized in a manner that permits storage, retrieval, update, and / or manipulation of data and information. The term "database" as used herein can also refer to a database that can reside locally or can be accessed from a remote location (e.g., via a remote web server).

[0046] As used herein, the term "patient data" refers to clinical data, imaging, or information related to an individual patient. Patient data can include measured patient data from medical imaging devices, analog medical devices, sensors, patient monitors, treatment devices, medical management devices, etc. and / or a combination thereof.

[0047] In the illustrated embodiment, the information system 126 can have or can access the same or additional one or more types of patient data as the patient data in the database 120. For example, the information system 126 can be a hospital information system (HIS). Such a hospital information system (HIS) has patient data including: Health Level 7 (HL7) data, Fast Healthcare Interoperability Resources (FHIR) data, etc. and / or a combination thereof. Additionally or alternatively, in some embodiments, the information system 126 has or can access one or more of the following information sources: electronic medical record (EMR), radiology information system (RIS), picture archiving and communication system (PACS), Digital Imaging and Communications in Medicine (DICOM), medical imaging devices, real-time location system (RTLS), sensors, machine logs, performance management data platform, medical asset tracking and tracing system, virtualized imaging solution, centralized care management system, interoperability solution, etc. As described above, due to technical or platform limitations, all of these data sources typically only have partial data on an individual patient and do not have a complete care timeline on a per-patient basis.

[0048] Additionally or alternatively, in some embodiments, database 120 and / or information system 126 may include or be associated with an analog database. In such an example, such an analog database may generate the estimated patient data. For example, the analog database may utilize some of the measured patient data from patient monitor 110, sensors 112, treatment device 116, medical management device 118, medical imager 119, and / or user interface 122 to generate some other estimated patient data. For example, such an analog database may utilize digital twin technology to perform the estimation. In such an example, such estimated patient data may be tagged to indicate its estimated nature (as opposed to the measured patient data). Additionally or alternatively, a weight factor may be applied to the estimated patient data such that the estimated patient data may have a lower weight than the corresponding measured patient data.

[0049] In some embodiments, the radiologist consultation support system 100 may be used as an element of an integrated clinical environment (ICE). As used herein, "integrated clinical environment (ICE)" refers to a platform for creating a medical Internet of Things (IoT) associated with the care of a patient. In such an embodiment, the radiologist consultation support system 100 may support a number of real-time clinical decision support algorithms. Additionally or alternatively, the radiologist consultation support system 100 may support closed-loop control algorithms for medical devices in the ICE.

[0050] Advantageously, in some embodiments, the radiologist consultation support application 108 may help improve the quality and efficiency of the communication system for radiologists. Additionally or alternatively, the radiologist consultation support application 108 may also be used as a pre-check for orders or consultation requests to ensure that relevant and essential data is provided to the radiologist in response to the request.

[0051] As will be described in more detail below, the radiologist consultation support system 100 and / or the radiologist consultation support application 108 may include a number of operable components.

[0052] Figure 2 Is an illustration of a block diagram of another example radiologist consultation support system 200 according to an embodiment. As shown, the radiologist consultation support system 200 includes a data source module 202, an inference module 204, a missing data module 206, a summary module 208, and / or a prioritization module 210.

[0053] In the illustrated embodiment, the data source module 202 is used to provide access to electronic medical records (EMRs), radiology information systems (RISs), picture archiving and communication systems (PACSs), medical imaging devices, etc. and / or combinations thereof. For example, the data source module 202 can provide access to medical imagers 119, databases 120, information systems 126, etc. and / or combinations thereof (e.g., as discussed above with respect to Figure 1 ).

[0054] In some examples, the data source module 202 provides access to relevant data typically used by radiologists. For example, for patient clinical context, the data source can include patient demographics (e.g., such as patient weight and height), laboratory results for biometric data (e.g., eGFR, blood pressure, etc.), imaging data (e.g., modality scans of current and previous studies), patient history (e.g., including previous reports / findings), diagnostic findings (e.g., key and incidental findings), reason and urgency of the study, orders, etc. and / or combinations thereof.

[0055] For study information context, the data source can include relevant clinical staff of the study (e.g., technicians, referring physicians, etc.), modality, settings of the modality scan, contrast agent use, protocol use, patient status indicating whether the patient is on the scanner table, screenshots of the console, DICOM images of previous or current studies, etc. and / or combinations thereof.

[0056] For consultation log data context, the data source can include that if communication and response to consultation requests are in a web-based text format, a log file can be generated to store the communication.

[0057] In some examples, the inference module 204 is used to determine data requirements based on the content of a consultation request.

[0058] In some embodiments, the inference module 204 is used to infer data needs based on the content of a consultation request. For example, the inference module 204 can automatically infer the data needs of a radiologist in response to a consultation request. For example, the output of the inference module 204 is a list (or other compilation) of the required data customized based on the content of the consultation request.

[0059] For example, the data required to provide appropriate consultations can vary according to specific consultation request tasks. Such consultation request tasks can be classified into several categories, including image examination, protocol preparation, research review, order questions, process questions, etc. For protocol preparation, radiologists typically utilize patient demographics (e.g., height, weight), laboratory data (e.g., eGFR), and the patient's current and previous clinical backgrounds to obtain an overall view of the patient. For image quality examination, radiologists typically will utilize access to DICOM images of current and previous studies, study information (e.g., modality, protocol, etc.), contrast agent use, modality settings, patient clinical backgrounds (e.g., relevant history and physical examination), etc.

[0060] In some examples, thus, the inference module 204 can infer data requirements based on the consultation request (e.g., the type of consultation request category and / or task). To automatically infer data requirements, the inference module 204 can first identify the consultation category, which can be directly indicated in most cases. In some examples, prefabricated consultation content labels can be provided for this purpose. For example, if a technician asks a radiologist to examine the image quality before discharging a patient, the label "image quality examination" can be given as a direct input to the inference module 204. Additionally or alternatively, one or more artificial intelligence (AI) models can be trained to automatically classify consultations. Using the previous example, a technician can ask "Can you view this image?" In this case, a classification model based on natural language processing (NLP) can be used to automatically identify the content. In such an example, the inference module 204 can first tokenize the sentence and remove less informative words such as "please", "you", and "the". Then, the word data can be converted by the inference module 204 into a vector representation used as the input to the NLP model. Then, the inference module 204 can assign a consultation category to the request in response to the output of the NLP model.

[0061] In some embodiments, the missing data module 206 is communicatively coupled to the data source module 202 and the inference module 204. For example, the missing data module 206 is used to identify missing information based on the determined data requirements by retrieving available data from the data source module 202, and to identify unavailable data based on the retrieved available data and the determined data requirements.

[0062] In some examples, the missing data module 206 is used to identify missing data. For example, identify missing information based on the data requirements for performing a specific consultation task, and send a request for data access. For example, when presenting to the user to notify the radiologist that only partial data is provided, the missing data will be outlined.

[0063] In some examples, the missing data module 206 is used to send an alert of data availability to the radiologist. For example, with such an alert of data availability, the radiologist can decide whether they can use the existing data to respond to a consultation request.

[0064] In some embodiments, the summarization module 208 is communicatively coupled to the missing data module 206. For example, the summarization module 208 is used to generate a summary by extracting clinical information related to performing the consultation from the retrieved available data.

[0065] In some examples, the prioritization module 210 is communicatively coupled to the summarization module 208. For example, the prioritization module 210 is used to prioritize the summary in the context of the consultation request and highlight the identified unavailable data.

[0066] For example, the summarization module 208 is used to summarize, and the prioritization module 210 is used to prioritize the data to be presented. For example, a summary of key clinical information is extracted from the data, and the presentation is prioritized based on the clinical relevance of performing the consultation.

[0067] In operation, the radiologist consultation support system 200 can help improve the quality and efficiency of clinical communication and collaboration. In some embodiments, the radiologist consultation support system 200 can be provided as a stand-alone application, or can be integrated with clinical and collaboration applications (such as, a remote command center, etc.) and / or with other hospital information systems. Some examples herein can be implemented at the user interface (UI) level of a hospital information system (such as, a PACS, etc.), a clinical and collaboration system (such as, a radiology operations command center (ROCC) platform, etc.), etc. and / or a combination thereof.

[0068] Figure 3 is an illustration of a data extraction flowchart 300 according to an embodiment. As shown, the data extraction flowchart 300 shows an example of extracting a list of data requirements based on the content of a consultation request (e.g., which can be the Figure 2 output of the inference module 204).

[0069] In some embodiments, another AI model (e.g., in addition to Figure 2 the AI model discussed with respect to the inference module 204 in Figure 2The AI model discussed regarding the inference module 204) can be trained to learn data requests at each patient and each study level to provide a more complete, accurate, and patient-specific overview. For example, since there is a finite set of consultation request categories, radiologists can provide the data access requirements for each category. Thus, data requirements can be inferred from multiple data sources, which can include but are not limited to communication logs, any logs of DICOM image reviews, logs of information access requests, etc. and / or combinations thereof.

[0070] For example, communication logs can track all communication history. If information is missing, there is likely a session around the lost data and access requests, which can be recorded. Logs of DICOM image views can be used to infer the need for image data since they indicate whether DICOM images will be needed or which DICOM images will be needed for specific cases. Logs tracking information access in other hospital systems (e.g., electronic health record (HER) systems, electronic medical record (EMR) systems) can also be used for such data requirements. Most of the data requirement information can be conveyed through the communication history. The inference module 204 ( Figure 2 shown) can consume any data source (single or combined) since the data input, output, and performance of the inference module 204 ( Figure 2 shown) will vary accordingly.

[0071] In some examples, at processing block 306, in the case where the consultation category of the current protocol request is identified, the radiologist consultation support system 200 ( Figure 2 shown) can extract all logs 308 from the same consultation category of the current request 302 found in the communication logs of all communication histories 304, and these logs will be used as the input to the AI module.

[0072] At processing block 310, the AI module can process each data point, learn the context of the study, and output the required data fields.

[0073] At processing block 312, the output of the AI module will be a list of data indicated by the log document as needed.

[0074] At processing block 314, a subset of the data can be selected since some data requirements may be very specific to the training data and not applicable to the current context.

[0075] At processing block 316, the selected data list is combined with the input data requirements 318 provided by the radiologist to generate and customize output data requirements based on the content of the current consultation request. In some examples, the data requirements list is not limited to text-based data and can cover image data and the like. For example, for an image quality inspection consultation, relevant prior images can be utilized.

[0076] Figure 4 is an illustration of a user interface 400 according to an embodiment. As shown, the radiologist consultation support system 200 ( Figure 2 shown) may also include a screen sharing module (not shown) to infer the need for screen sharing. For example, such a screen sharing module can provide an indication to the question initiator as shown in the example user interface 400 to convey the potential need to call or start screen sharing. For example, there may be a situation where the radiologist prefers to access study / patient information or communicate with the question initiator (e.g., technician, referring physician, etc.) via call or screen sharing. In such a case, the question initiator should expect to contact the radiologist or initiate a call / screen sharing.

[0077] As shown, the user interface 400 includes an indication 402 that shows the question initiator (e.g., a technician in this case) the potential need to start a call / screen sharing with the radiologist for a specific consultation request. The indication 402 can include a text message 404 to show the action to be expected and a numerical indicator 406 to show the likelihood of requesting a call / screen sharing from the radiologist. Advantageously, such an indication 402 can enable the question initiator to proactively prepare or act.

[0078] In some embodiments, the indicator 402 can be implemented by a naive frequency-based algorithm. For example, in the case of identifying the question category, the percentage of consultation requests that establish a call or screen sharing is calculated. In this case, the percentage will be used to indicate the likelihood of initiating a call or screen sharing, which corresponds to the number shown under the indicator message.

[0079] In some examples, a threshold can be set to determine the message to be displayed in the indicator. For example, if more than 70% of the consultation requests in that question category will require a call / screen sharing, a message (e.g., such as "Please prepare to call / share screen") is shown; otherwise, no indication will be presented.

[0080] In some embodiments, an AI module can also be used to train the indication 402. For example, the training label would be a binary output indicating whether to initiate a call / screen sharing in such a case. In such an example, the dependent data would be considered as attributes of the consultation request, which can include but are not limited to patient status, problem category, patient background, etc. and / or combinations thereof. In this example, its output would be the likelihood of initiating a call / screen sharing. For example, logistic regression would be suitable for such an embodiment.

[0081] Figure 5 FIG. is an illustration summarizing a user interface 500 according to another example of an embodiment. As shown, the summarization module 208 and / or the prioritization module 210 of the radiologist consultation support system 200 ( Figure 2 shown) can output a summary user interface 500 to provide a summary of the clinical background.

[0082] In some examples, the summary user interface 500 includes a text summary 502 of the clinical background. For example, based on the data type, clinical data can be classified as non-text, text-based, and image data. Text-based data can be further classified as free text and coded text data, which uses predefined codes to represent text fields. For example, the code "LV001" can be used to represent left ventricular hypertrophy. Most clinical settings can provide, via the text summary 502, in the format of free text or coded text, such as diagnostic findings, patient history, reason for the study, etc.

[0083] In some examples, the summary user interface 500 includes an image summary 504. Modal scans are imaging data that contain rich clinical information but may be excessive for radiologists to view. Therefore, the image summary 504 of the clinical status will help radiologists quickly overview the clinical background of the case. Various AI models can be trained for implementation.

[0084] Additionally or alternatively, when clicking on the summary data in the summary user interface 500, the radiologist will access the complete data source from which the summary was extracted.

[0085] In some embodiments, the prioritization focuses on presenting the most relevant data first and using intelligent visualization to present the data so that the information can be better consumed. For example, such prioritization can be based on the context of the consultation request. In such an example, if the consultation request is for an "image examination", the summary should focus on image quality and prioritize key images with artifacts for the radiologist to view. On the other hand, if the request is for "protocol preparation", the summarization module 208 ( Figure 2 shown therein) can provide an overall summary of the patient's clinical background, and the prioritization module 210 ( Figure 2as shown) can prioritize the key reasons for the study, enabling the radiologist to understand the diagnostic focus of the case. If the request is for "initial review before release", the summarization module 208 and / or the prioritization module 210 ( Figure 2 as shown) can summarize and prioritize the key findings on the imaging data.

[0086] Additionally or alternatively, the summarization module 208 and / or the prioritization module 210 (shown in Figure 2 ) are used to present potential follow-up actions to be taken based on the summary data. For example, instead of manually typing a response, the radiologist can select from one or more automatically generated response messages for quick replies. For example, if important information is indicated as missing, "Please provide more information" is presented in the summary user interface 500 or other user interfaces. Other quick reply message options can be "Release the patient", "Perform additional contrast scans", "Schedule a PET CT", etc. and / or combinations thereof. In some examples, the most frequently used actions can be provided as quick reply message options and / or one or more AI modules can be trained to provide such quick reply message options.

[0087] Figure 6 illustrates an example method 600 for managing radiologist consultations according to an embodiment. Method 600 can generally be implemented in the radiologist consultation support system 100 ( Figure 1 ) and / or the radiologist consultation support system 200 ( Figure 2 ) that have been discussed.

[0088] In an embodiment, method 600 (and method 700 ( Figure 7 )) can be implemented in logical instructions (e.g., software), configurable logic (e.g., firmware), fixed-function hardware logic (e.g., hardware), etc. or any combination thereof.

[0089] The processing block 602 shown provides determining data requirements. For example, the inference module can determine data requirements based on the content of the consultation request for the consultation.

[0090] The processing block 604 shown provides identifying missing information.

[0091] For example, the missing data module communicatively coupled to the inference module can identify missing information based on the determined data requirements by retrieving available data from the data source module, and identify unavailable data based on the retrieved available data and the determined data requirements.

[0092] The illustrated processing block 606 provides for generating a summary. For example, a summary module communicatively coupled to the missing data module may generate a summary by extracting clinical information related to performing the consultation from the retrieved available data.

[0093] The illustrated processing block 608 provides for prioritizing the summary and highlighting the identified unavailable data. For example, a prioritization module communicatively coupled to the summary module may prioritize the summary and highlight the identified unavailable data in the context of the consultation request.

[0094] In some examples, the methods described herein (e.g., method 600 and / or method 700) may be performed, at least in part, by cloud processing.

[0095] It should be understood that some or all of the operations described herein that have been described using a “pull” architecture (e.g., polling for new information and then a corresponding response) may alternatively be implemented using a “push” architecture (e.g., sending such information when there is new information to report), and vice versa.

[0096] Additional and / or alternative operations of method 600 are described in more detail below in Figure 7 the description.

[0097] Figure 7 is a flowchart of an example of another method 700 for managing radiologist consultations according to an embodiment. Method 700 may generally be implemented in the radiologist consultation support system 100 ( Figure 1 ) and / or the radiologist consultation support system 200 ( Figure 2 ) that have been discussed.

[0098] As illustrated, the various processing blocks are shown to be performed in combination with each other by the data source module 202, the inference module 204, the missing data module 206, the summary module 208, and / or the prioritization module 210 (e.g., as discussed above in Figure 2 ).

[0099] The illustrated processing block 703 provides for receiving a consultation request. For example, the inference module may receive a consultation request.

[0100] The illustrated processing block 705 provides for determining a problem category. For example, the inference module may determine a problem category in response to receiving a consultation request.

[0101] In some embodiments, the determination of the problem category is performed at least in part based on the type of workflow associated with the consultation request. For example, the type of workflow is image quality inspection, protocol preparation for confirming the relevance of the request, research review, process issues, answering order questions, protocol process requests, etc. and / or combinations thereof.

[0102] As used herein, the term "image quality inspection" refers to a radiologist requesting an ocular radiograph and evaluating whether it has diagnostic quality. If not, the image needs to be retaken.

[0103] As used herein, the term "protocol preparation" refers to assigning an imaging protocol to an imaging order of a referring physician. Sometimes, the referring provider does not fully know what order to place, and given the patient's symptoms / history, their order may be misguided. In such cases, the radiologist can make a judgment call.

[0104] As used herein, the term "research review" refers to a radiologist reviewing the images immediately after acquisition to ensure that there are no findings that require additional imaging. In such cases, the patient can remain on the table or in the hospital for subsequent imaging.

[0105] As used herein, the term "answering order questions" refers to responding to a referring provider who is entering an image order regarding what examination to select.

[0106] The illustrated processing block 707 provides for determining data requirements. For example, the inference module can determine data requirements based on the content of the consultation request for the consultation.

[0107] In some examples, for instance, the determination of data requirements is at least in part based on the problem category.

[0108] In some embodiments, the determination of data requirements is also at least in part based on information from one or more previous consultation requests.

[0109] The illustrated processing block 713 provides for identifying missing information. For example, the missing data module communicatively coupled to the inference module can identify missing information based on the determined data requirements by retrieving available data from the data source module at processing block 714, and identify unavailable data at processing block 715 based on the retrieved available data and the determined data requirements.

[0110] In some embodiments, the data source module is used to provide access to electronic medical records (EMRs), radiology information systems (RISs), picture archiving and communication systems (PACSs), medical imaging devices, etc. and / or combinations thereof.

[0111] The processing block 716 shown provides an identification of the information source. For example, the missing data module can identify the information source associated with the identified unavailable data.

[0112] The processing block 717 shown provides a determination of the desired response time frame. For example, the missing data module can determine the desired response time frame at least in part based on an assessment of the urgency of the consultation request.

[0113] The processing block 719 shown provides sending an alert. For example, the missing data module can send an alert to the identified information source, where the alert includes an indication of the identified unavailable data and the desired response time frame.

[0114] The processing block 721 shown provides sending a status update. For example, the missing data module can send a status update to the sender of the consultation request. In such an example, the status update can include an indication of the likelihood of the need to supplement data in response to the identified unavailable data indicated by the alert, an indication of the identified information source from which the supplementary data is requested, and / or an indication of the desired response time frame.

[0115] The processing block 723 shown provides receiving supplementary data. For example, the missing data module can receive supplementary data from the identified information source in response to the alert indication of the identified unavailable data.

[0116] The processing block 725 shown provides updating the identified unavailable data. For example, the missing data module can update the identified unavailable data (e.g., as well as the retrieved available data).

[0117] The processing block 736 shown provides generating a summary. For example, a summary module communicatively coupled to the missing data module can generate a summary by extracting clinical information relevant to performing the consultation from the retrieved available data.

[0118] The processing block 748 shown provides prioritizing the summary and highlighting the identified unavailable data. For example, a prioritization module communicatively coupled to the summary module can prioritize the summary and highlight the identified unavailable data in the context of the consultation request.

[0119] The processing block 751 shown provides determining that any remaining identified unavailable data exceeds a threshold. For example, the prioritization module can determine that any remaining identified unavailable data exceeds a threshold.

[0120] The processing block 753 shown provides transmitting an indication of the remaining identified unavailable data. For example, the prioritization module can transmit an indication of the consultation request, the available data, and / or the remaining identified unavailable data to a receiver associated with a radiologist in response to determining that the threshold has been exceeded.

[0121] The illustrated processing block 755 provides for determining that the available data is complete. For example, the prioritization module may determine that there is no remaining identified unavailable data and determine that the available data is complete.

[0122] The illustrated processing block 757 provides for transmitting the consultation request and the available data. For example, the prioritization module may transmit the consultation request and the available data to a receiver associated with a radiologist in response to determining that the available data is complete.

[0123] In some embodiments, the prioritization module may transmit the consultation request and the available data to a user interface associated with the assigned radiologist.

[0124] Additionally or alternatively, the processes described herein may provide a framework for the clinical deployment of decision support algorithms. These processes may work with many clinical decision support (CDS) algorithms such as acute kidney injury (AKI), acute respiratory distress syndrome (ARDS), acute decompensated heart failure (ADHF), etc. Clinical decision support (CDS) refers to computer-based support for clinical staff responsible for making decisions regarding patient care. Computer-based support for clinical decision makers may take many forms, from patient-specific visual / digital health status indicators to patient-specific health status predictions and patient-specific healthcare recommendations. In addition, the processes described herein may be deployed on an analysis platform (such as an inference engine, a critical care information system, an interoperability solution, etc.) in combination with CDS algorithms.

[0125] Figure 8 A block diagram of an example computer program product 800 is shown. In some examples, as Figure 8 shown, the computer program product 800 includes a machine-readable storage device 802, which may also include logic 804. In some embodiments, the machine-readable storage device 802 may be implemented as a non-transitory machine-readable storage device. In some embodiments, the logic 804 may be implemented as machine-readable instructions, such as software. In an embodiment, when executed, the logic 804 implements the methods 600 ( Figure 6 ), method 700 ( Figure 7 ) and / or implements one or more aspects of the system 100 ( Figure 1 and / or Figure 2 ).

[0126] Figure 9An illustrative example of a radiologist consultation support system 100 is shown. In the example shown, the radiologist consultation support system 100 can include a processor 902 and a memory 904 communicatively coupled to the processor 902. The memory 904 can include logic 906 as an instruction set. In some embodiments, the logic 906 can be implemented as software. In an embodiment, the logic 906, when executed by the processor 902, implements the method 600( Figure 6 ), the method 700( Figure 7 ), and / or implements one or more aspects of the system 100( Figure 1 and / or Figure 2 ).

[0127] In some embodiments, the processor 902 can include a general controller, a dedicated controller, a storage controller, a storage manager, a memory controller, a microcontroller, a general-purpose processor, a dedicated processor, a central processing unit (CPU), etc. and / or combinations thereof.

[0128] Furthermore, embodiments can include distributed processing, component / object distributed processing, parallel processing, etc. and / or combinations thereof. For example, virtual computer system processing can implement one or more of the methods or functions described herein, and the processor 902 described herein can be used to support such virtual processing.

[0129] In some examples, the memory 904 is an example of a computer-readable storage medium. For example, the memory 904 can be any memory accessible to the processor 902, including but not limited to RAM memory, registers, and register files, etc. and / or combinations thereof. References to "computer memory" or "memory" should be construed as potentially being multiple memories. The memory can be, for example, multiple memories within the same computer system. The memory can also be multiple memories distributed among multiple computer systems or computing devices.

[0130] Figure 10 An illustrative semiconductor device 1000 (e.g., a chip and / or a package) is shown. The semiconductor device 1000 shown includes one or more substrates 1002 (e.g., silicon, sapphire, or gallium arsenide) and logic 1004 (e.g., configurable logic and / or fixed-function hardware logic) coupled to the substrate 1002. In an embodiment, the logic 1004 implements the method 600( Figure 6 ), the method 700( Figure 7 ), and / or implements one or more aspects of the system 100( Figure 1 and / or Figure 2 ).

[0131] In some embodiments, logic 1004 may include an array of transistors and / or other integrated circuit / IC components. For example, the configurable logic and / or fixed function hardware logic implementation of logic 1004 may include configurable logic such as, for example, a programmable logic array (PLA), a field programmable gate array (FPGA), a complex programmable logic device (CPLD), or fixed function logic hardware using circuit technology such as, for example, an application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS), or transistor-transistor logic (TTL) technology, etc. and / or combinations thereof.

[0132] All definitions defined and used herein shall be understood to control dictionary definitions, definitions in the documents incorporated by reference, and / or the ordinary meaning of the defined terms.

[0133] The subject matter described herein sometimes shows different components included within or connected to different other components. It should be understood that such depicted architectures are merely exemplary and that many other architectures that achieve the same functionality can actually be implemented. In a conceptual sense, any arrangement of components that achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Thus, any two components that are combined herein to achieve a particular functionality can be considered to be "associated" with each other such that the desired functionality is achieved, regardless of the architecture or intermediate components. The term "coupled" can be used herein to refer to any type of direct or indirect relationship between the components being discussed and can apply to electrical, mechanical, fluid, optical, electromagnetic, electromechanical, or other connections. Similarly, any two components so associated can also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components that can be so associated can also be considered to be "operably coupled" to each other to achieve the desired functionality. Specific examples of operably coupled include, but are not limited to, physically mating and / or physically interacting components.

[0134] In the claims, as well as in the above specification, the terms "first", "second", etc. may be used herein only to facilitate discussion and do not have a particular temporal or chronological significance unless otherwise stated.

[0135] In the claims, as well as in the above specification, all transitional phrases such as "comprising", "including", "carrying", "having", "containing", "involving", "holding", "consisting of", etc. shall be understood to be open-ended, i.e., meaning including but not limited to. Only the transitional phrases "consisting of" and "consisting essentially of" shall be closed or semi-closed transitional phrases, respectively.

[0136] Unless otherwise expressly stated, the indefinite articles "a" and "an" used in this specification and the claims shall be understood to mean "at least one".

[0137] As used herein, unless otherwise expressly stated or the context otherwise indicates, the term "or" or "and / or" is inclusive and not exclusive. Thus, as used herein, "A or B" means "A, B, or both", unless otherwise expressly indicated or the context otherwise indicates. Further, "and" is both conjunctive and plural, unless otherwise expressly stated or the context otherwise indicates. Thus, as used herein, "A and B" means "A and B, jointly or separately", unless otherwise expressly stated or the context otherwise indicates.

[0138] As used in the specification and claims herein, the phrase "at least one" with respect to a list of one or more elements should be understood to mean at least one element selected from any of the elements in the list of elements, but not necessarily including at least one of each element specifically listed within the list of elements, and not excluding any combinations of the elements in the list. This definition also allows that elements may optionally be present in addition to those specifically identified within the list of elements to which the phrase "at least one" refers, whether related or unrelated to those specifically identified.

[0139] As used in this application and the claims, a list of items joined by the term "one or more of" may represent any combination of the listed terms. For example, the phrase "one or more of A, B, or C" may represent A; B; C; A and B; A and C; B and C; or A, B, and C.

[0140] As described in more detail above, one or more processors, other units, etc. and / or combinations thereof may implement the functions of several items recited in the claims.

[0141] As described in more detail above, a computer program may be stored / distributed on a suitable computer-readable medium, such as an optical storage medium or a solid-state medium provided with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

[0142] It should also be understood that, unless expressly indicated to the contrary, in any method discussed herein that includes more than one step or action, the order of the steps or actions of the method is not necessarily limited to the order in which the steps or actions of the method are recited. Further, such methods may include additional or alternative steps or actions.

[0143] As used in the claims, the mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used advantageously.

[0144] It should also be noted that the claims may include reference signs / numbers in accordance with PCT Rule 6.2(b). However, the claims should not be construed as being limited to the exemplary embodiments corresponding to the reference signs / numbers.

[0145] Those skilled in the art will understand from the foregoing description that the broad techniques of the embodiments of the present invention can be implemented in various forms. Accordingly, while the embodiments of the present invention have been described in connection with specific examples thereof, the true scope of the embodiments of the present invention should not be so limited, since other modifications will become apparent to the skilled person after studying the drawings, the specification and the appended claims.

Claims

1. A radiologist consultation support system, comprising: An inference module for determining data requirements based on the content of a consultation request for a consultation; A missing data module communicatively coupled to the inference module, the missing data module for identifying missing information based on the determined data requirements by retrieving available data from a data source module, and for identifying unavailable data based on the retrieved available data and the determined data requirements; A summary module communicatively coupled to the missing data module, the summary module for generating a summary by extracting clinical information related to performing the consultation from the retrieved available data; And A prioritization module communicatively coupled to the summary module, the prioritization module for prioritizing the summary in the context of the consultation request and highlighting the identified unavailable data.

2. The radiologist consultation support system according to claim 1, wherein, The inference module is further configured to determine a problem category in response to receiving the consultation request, wherein the determination of the data requirements is based on the problem category.

3. The radiologist consultation support system according to claim 2, wherein, The determination of the data requirements is further based on information from one or more previous consultation requests.

4. The radiologist consultation support system according to claim 2, wherein, The determination of the problem category is performed based on the type of workflow associated with the consultation request, and wherein the type of workflow is one or more of the following: image quality inspection, protocol preparation for confirming the relevance of the request, study review, process issues, answering order questions, and protocol process requests.

5. The radiologist consultation support system according to claim 1 further includes the data source module, wherein, The data source module provides access to one or more of the following: electronic medical records (EMR), radiology information systems (RIS), picture archiving and communication systems (PACS), and medical imaging devices.

6. The radiologist consultation support system according to claim 1, wherein, The missing data module is further configured to: Identify information sources associated with the identified unavailable data; Determine a response time frame based on an assessment of the urgency of the consultation request; And Send an alert to the identified information source, wherein the alert includes an indication of the identified unavailable data and the response time frame.

7. The radiologist consultation support system according to claim 6, wherein, The missing data module is further configured to: Send a status update to the sender of the consultation request, wherein the status update includes an indication of the likelihood of needing to supplement data in response to the identified unavailable data of the alert, an indication of the identified information source from which the supplementary data is requested, and an indication of the response time frame.

8. The radiologist consultation support system according to claim 6, wherein, The missing data module is further configured to: In response to the indication of the identified unavailable data of the alert, receive supplementary data from the identified information source; and Update the identified unavailable data.

9. The radiologist consultation support system according to claim 8, wherein, The prioritization module is further configured to: Determine that there is no remaining identified unavailable data and that the available data is complete; And In response to determining that the available data is complete, transmit the consultation request and the available data to a receiver associated with a radiologist.

10. The radiologist consultation support system according to claim 8, wherein, The prioritization module is further configured to: Determine that any remaining identified unavailable data exceeds a threshold; and In response to determining that the threshold has been exceeded, transmit the consultation request, the available data, and an indication of the remaining identified unavailable data to a receiver associated with a radiologist.

11. A method for radiologist consultation support, comprising: Determining data requirements via an inference module based on the content of a consultation request for a consultation; Identifying missing information based on the determined data requirements by, via a missing data module communicatively coupled to the inference module, retrieving available data from a data source module and identifying unavailable data based on the retrieved available data and the determined data requirements; Generating a summary by, via a summary module communicatively coupled to the missing data module, extracting clinical information relevant to performing the consultation from the retrieved available data; And Prioritizing the summary in the context of the consultation request and highlighting the identified unavailable data via a prioritization module communicatively coupled to the summary module.

12. The method for radiologist consultation support according to claim 11, further comprising determining a problem category via the inference module in response to receiving the consultation request, wherein, The determination of the data requirements is based on the problem category, wherein the determination of the data requirements is further based on information from one or more previous consultation requests, wherein the determination of the problem category is performed based on the type of workflow associated with the consultation request, and wherein the type of workflow is one or more of the following: image quality inspection, protocol preparation for confirming the relevance of a request, study review, process issues, answering order questions, and protocol process requests.

13. The method for radiologist consultation support according to claim 11, further comprising: Identifying an information source associated with the identified unavailable data via the missing data module; Determining a response time frame via the missing data module based on an assessment of the urgency of the consultation request; Sending an alert to the identified information source via the missing data module, wherein the alert includes an indication of the identified unavailable data and the response time frame; Sending a status update to the sender of the consultation request via the missing data module, wherein the status update includes an indication of the likelihood of needing to supplement data in response to the identified unavailable data of the alert, an indication of the identified information source from which the supplementary data is requested, and an indication of the response time frame; Receiving supplementary data from the identified information source via the missing data module in response to an indication of the identified unavailable data of the alert; and Updating the identified unavailable data via the missing data module.

14. The method for radiologist consultation support according to claim 13, further comprising: Determining via the prioritization module that there is no remaining identified unavailable data and that the available data is complete; And In response to determining that the available data is complete, transmitting the consultation request and the available data to a receiver associated with a radiologist via the prioritization module.

15. The method for radiologist consultation support according to claim 13, further comprising: Determine, via the prioritization module, that any remaining identified unavailable data exceeds a threshold; and In response to determining that the threshold has been exceeded, transmit, via the prioritization module, the consultation request, the available data, and an indication of the remaining identified unavailable data to a receiver associated with a radiologist.

16. At least one machine-readable storage device, including an instruction set that, when executed by a computing device, causes the computing device to: Determine data requirements based on the content of a consultation request for a consultation; Identify missing information by retrieving available data from a data source based on the determined data requirements, and identify unavailable data based on the retrieved available data and the determined data requirements; Generate a summary by extracting clinical information related to performing the consultation from the retrieved available data; and Prioritize the summary and highlight the identified unavailable data in the context of the consultation request.

17. The at least one machine-readable storage device according to claim 16, wherein, The instruction set, when executed by the computing device, further causes the computing device to: Determine a problem category in response to receiving the consultation request, wherein the determination of the data requirements is based on the problem category, wherein the determination of the data requirements is further based on information from one or more previous consultation requests, wherein the determination of the problem category is performed based on the type of workflow associated with the consultation request, and wherein the type of workflow is one or more of the following: image quality check, protocol development for confirming the relevance of the request, study review, process issue, answering order questions, and protocol process request.

18. The at least one machine-readable storage device according to claim 16, wherein, The instruction set, when executed by the computing device, further causes the computing device to: Identify information sources associated with the identified unavailable data; Determine a response time frame based on an assessment of the urgency of the consultation request; Send an alert to the identified information sources, wherein the alert includes an indication of the identified unavailable data and the response time frame; Send a status update to the sender of the consultation request, wherein the status update includes an indication of the likelihood of needing to supplement data in response to the identified unavailable data indicated in the alert, an indication of the identified information sources from which the supplementary data is requested, and an indication of the response time frame; Receive supplementary data from the identified information sources in response to the indication of the identified unavailable data in the alert; and Update the identified unavailable data.

19. The at least one machine-readable storage device according to claim 18, wherein, The instruction set, when executed by the computing device, further causes the computing device to: Determine that there is no remaining identified unavailable data and that the available data is complete; and In response to determining that the available data is complete, transmit the consultation request and the available data to a receiver associated with a radiologist.

20. The at least one machine-readable storage device according to claim 18, wherein, The instruction set, when executed by the computing device, further causes the computing device to: Determine that any remaining identified unavailable data exceeds a threshold; and In response to determining that the threshold has been exceeded, the consultation request, the available data, and an indication of the remaining identified unavailable data are passed to a receiver associated with a radiologist.

Images