Intelligent clinical user interface

Abstract

The present disclosure provides systems or techniques that facilitate an intelligent clinical user interface. In various embodiments, the system can access attribute data (e.g., 104) corresponding to a medical patient and can access real-time measurements (e.g., 108) of a plurality of vital sign categories (e.g., 106) of the medical patient. In various aspects, the system can identify which of the plurality of vital sign categories is clinically related to the medical patient via execution of a machine learning model (e.g., 302) on the attribute data, thereby generating an identified vital sign category (e.g., 402). In various cases, the system can visually present real-time measurements (e.g., 602) of identified vital sign categories on a graphical user interface (GUI) (e.g., 502). In various cases, the system can determine a visual pattern (e.g., 404) via the machine learning model to assist the medical patient in viewing the GUI, and the system can visually present the real-time measurements of the identified vital sign category according to the visual pattern.

Description

Technical Field

[0001] The present disclosure generally relates to clinical user interfaces, and more particularly to intelligent clinical user interfaces. Background Art

[0002] When given a medical patient whose vital signs are being monitored, it may be desirable to display the vital sign measurements of the medical patient on a graphical user interface. The prior art implements this in a static, standardized manner. Summary of the Invention

[0003] The following presents a summary of the invention to provide a basic understanding of one or more embodiments. This summary is not intended to identify key or critical elements, nor to delineate any scope of particular embodiments or any scope of the claims. Its sole purpose is to present concepts in a simplified form as a prelude to the more detailed description that is presented later. In one or more embodiments described herein, devices, systems, computer-implemented methods, apparatuses, or computer program products that facilitate intelligent clinical user interfaces are described.

[0004] According to one or more embodiments, a system is provided. The system may include a non-transitory computer-readable memory that may store computer-executable components. The system may also include a processor that may be operatively coupled to the non-transitory computer-readable memory and may execute the computer-executable components stored in the non-transitory computer-readable memory. In various embodiments, the computer-executable components may include an access component that may access attribute data corresponding to a medical patient and may access real-time measurements of multiple vital sign categories of the medical patient. In various aspects, the computer-executable components may include a model component that may identify, via execution of a machine learning model on the attribute data, which one of the multiple vital sign categories is clinically relevant to the medical patient, thereby generating the identified vital sign category. In various cases, the computer-executable components may include a display component that may visually present the real-time measurements of the identified vital sign category on a graphical user interface. In various cases, the model component may determine, via execution of the machine learning model, a visual style that is predicted to assist the medical patient in viewing the graphical user interface or assist the attending clinician in viewing the graphical user interface, and the display component may visually present the real-time measurements of the identified vital sign category according to the visual style.

[0005] According to one or more embodiments, a computer-implemented method is provided. In various embodiments, the computer-implemented method may include: accessing, by a device operatively coupled to a processor, attribute data corresponding to a medical patient and real-time measurements of multiple vital sign categories of the medical patient. In various aspects, the computer-implemented method may include: identifying, by the device and via execution of a machine learning model on the attribute data, which one of the multiple vital sign categories is clinically relevant to the medical patient, thereby generating the identified vital sign category. In various instances, the computer-implemented method may include: visually presenting, by the device and on a graphical user interface, the real-time measurements of the identified vital sign category. In various instances, the computer-implemented method may include: determining, by the device and via execution of a machine learning model, a visual style predicted to assist the medical patient in viewing the graphical user interface or to assist an attending clinician in viewing the graphical user interface, wherein the real-time measurements of the identified vital sign category may be visually presented according to the visual style.

[0006] According to one or more embodiments, a computer program product for facilitating an intelligent clinical user interface is provided. In various embodiments, the computer program product may include a non-transitory computer-readable memory having program instructions embodied thereon. In various aspects, the program instructions may be executable by a processor to cause the processor to access attribute data corresponding to a medical patient and real-time measurements of multiple vital sign categories of the medical patient. In various instances, the program instructions may also be executable to cause the processor to identify, via execution of a machine learning model on the attribute data, which one of the multiple vital sign categories is clinically relevant to the medical patient, thereby generating the identified vital sign category. In various instances, the program instructions may also be executable to cause the processor to communicate the real-time measurements of the identified vital sign category via an electronic user interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 A block diagram illustrating an exemplary non-limiting system for facilitating an intelligent clinical user interface in accordance with one or more embodiments described herein.

[0008] Figure 2 A block diagram illustrating an exemplary non-limiting diagram showing multiple patient vital sign categories and multiple real-time vital sign measurements in accordance with one or more embodiments described herein.

[0009] Figure 3 A block diagram illustrating an exemplary non-limiting system for facilitating an intelligent clinical user interface including a deep learning neural network and one or more GUI-related inferences in accordance with one or more embodiments described herein.

[0010] Figure 4 An exemplary non - restrictive block diagram illustrating how a deep - learning neural network can generate one or more GUI - related inferences according to one or more embodiments described herein.

[0011] Figure 5 A block diagram of an exemplary non - restrictive system that promotes an intelligent clinical user interface and includes a GUI modulated for a patient according to one or more embodiments described herein.

[0012] Figure 6 An exemplary non - restrictive block diagram showing a GUI modulated for a patient according to one or more embodiments described herein.

[0013] Figure 7 A block diagram of an exemplary non - restrictive system that promotes an intelligent clinical user interface and includes clinician metadata according to one or more embodiments described herein.

[0014] Figure 8 An exemplary non - restrictive block diagram illustrating how a deep - learning neural network can take into account clinician metadata according to one or more embodiments described herein.

[0015] Figure 9 A block diagram of an exemplary non - restrictive system that promotes an intelligent clinical user interface and includes a training component and a training data set according to one or more embodiments described herein.

[0016] Figure 10 An exemplary non - restrictive block diagram of a training data set according to one or more embodiments described herein.

[0017] Figure 11 An exemplary non - restrictive block diagram showing how a deep - learning neural network can be trained according to one or more embodiments described herein.

[0018] Figure 12 A flowchart of an exemplary non - restrictive computer - implemented method that promotes an intelligent clinical user interface according to one or more embodiments described herein.

[0019] Figure 13 A block diagram of an exemplary non - restrictive operating environment in which one or more embodiments described herein can be promoted.

[0020] Figure 14 An exemplary networked environment operable to execute various implementations described herein. Detailed Description

[0021] The following specific embodiments are merely illustrative and are not intended to limit the implementation or application / use of the embodiments. Additionally, there is no intention to be bound by any explicit or implicit information presented in the foregoing "Background" or "Summary of the Invention" sections or the "Detailed Description" section.

[0022] Reference is now made to the drawings to describe one or more embodiments, where the same reference numerals are always used to denote the same elements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a more thorough understanding of one or more embodiments. However, it is evident that in various instances, one or more embodiments may be practiced without these specific details.

[0023] The vital signs (e.g., body temperature, blood pressure, heart rate) of a medical patient can be measured in real time via any suitable medical equipment (e.g., thermometer, sphygmomanometer, pulse monitor). During such real-time monitoring, it may be desirable to display the measurement results of the vital signs of the medical patient on a graphical user interface (GUI). For example, such a GUI can be presented on an electronic screen of a smart device or a hospital computing console. Thus, the medical patient (or their attending clinician) can view the GUI to learn about the current health status of the medical patient.

[0024] The prior art facilitates such display in a static, standardized manner. In particular, when the prior art is implemented, the clinical GUI displays a consistent set of vital sign measurement results in a consistent manner, regardless of who the medical patient is to whom those vital sign measurement results correspond. In other words, the inventors of the various embodiments described herein recognize that such prior art GUIs are made in a one-size-fits-all manner and are not customized or tailored for individual medical patients.

[0025] Therefore, a system or technique that can solve one or more of these technical problems may be desirable.

[0026] The various embodiments described herein can address one or more of these technical problems. One or more embodiments described herein can include systems, computer-implemented methods, devices, or computer program products that can facilitate an intelligent clinical user interface. In particular, when given a medical patient whose vital signs are being monitored in real time, the various embodiments described herein can involve generating a clinical GUI that is modulated for the given medical patient by leveraging a machine learning model. In fact, in some cases, the machine learning model can be configured to identify which specific vital signs are most clinically relevant to a given medical patient, and the modulated clinical GUI can be presented so as to prominently depict real-time measurements of the identified vital signs (e.g., real-time measurements of other non-relevant vital signs can be minimized or omitted from the modulated clinical GUI). In other cases, the machine learning model can also be configured to determine a visual style (e.g., font size, color scheme) that would be appropriate or comfortable for a given medical patient, and the modulated clinical GUI can be presented in accordance with that visual style. In still other cases, the machine learning model can also be configured to determine such a threshold that depicts an upper or lower boundary of healthy or acceptable behavior of the identified vital signs of a given medical patient, and whenever the real-time measurements of the given medical patient fail to meet the threshold, the modulated clinical GUI can depict a warning. In other words, as recognized by the present inventors, existing clinical GUIs can be considered as general-purpose interfaces that fail to take into account the clinical idiosyncrasies of different medical patients. In contrast, the various embodiments described herein can utilize artificial intelligence to generate such a clinical GUI that is uniquely modulated or adjusted for the clinical idiosyncrasies of different medical patients (e.g., different vital signs may be more or less clinically relevant to different medical patients; different visual styles may be more or less appropriate or comfortable for different medical patients; the upper or lower boundaries of healthy vital sign behavior may be different for different medical patients). Thus, the various embodiments described herein can be considered as superior to the prior art.

[0027] The various embodiments described herein can be considered as computerized tools (e.g., any suitable combination of computer-executable hardware or computer-executable software) that can facilitate an intelligent clinical user interface. In various aspects, such computerized tools can include an access component, a model component, or a display component.

[0028] In various embodiments, patient metadata may exist. In various aspects, the patient metadata may correspond to any suitable medical patient. In various situations, the patient metadata may indicate, quantify, convey, or otherwise represent any suitable physical characteristics, attributes, or demographic data of the medical patient (e.g., age, gender, weight, height, health habits, pathology, prosthesis, symptoms, occupation, education level). In some situations, the patient metadata may represent or otherwise be derived from all or a portion of the medical history of the medical patient.

[0029] In various embodiments, there may be multiple vital sign categories (e.g., blood pressure category, heart rate category, body temperature category). In various aspects, multiple real-time vital sign measurements corresponding to the multiple vital sign categories may be tracked or recorded for a medical patient (e.g., the real-time blood pressure measurement of the medical patient may be tracked; the real-time heart rate measurement of the medical patient may be tracked; the real-time body temperature measurement of the medical patient may be tracked). In various situations, the multiple real-time vital sign measurements may be recorded or otherwise captured by any suitable medical diagnostic equipment (e.g., sphygmomanometer, pulse monitor, thermometer).

[0030] In various situations, it may be desirable to display various real-time vital sign measurements on a clinical GUI that can be viewed by or is viewable to a medical patient. As described herein, computerized tools may facilitate such display.

[0031] In various embodiments, the access component of the computerized tool may electronically receive or otherwise electronically access the patient metadata or the multiple real-time vital sign measurements. In some aspects, the access component may electronically retrieve the patient metadata or the multiple real-time vital sign measurements from any suitable centralized or decentralized data structure (e.g., graphical data structure, relational data structure, hybrid data structure) (whether remote from or local to the access component). In other aspects, the access component may electronically retrieve the patient metadata or the multiple real-time vital sign measurements from any medical equipment that measures, captures, or stores the patient metadata or the multiple real-time vital sign measurements. In any case, the access component may electronically obtain or access the patient metadata or the multiple real-time vital sign measurements such that the access component may act as a conduit through which other components of the computerized tool may electronically interact (e.g., read, write, edit, copy, manipulate) with the patient metadata or with the multiple real-time vital sign measurements.

[0032] In various embodiments, the model component of the computerized tool can be stored, maintained, controlled, or otherwise accessed electronically for a deep learning neural network. In various aspects, the deep learning neural network can have any suitable deep learning internal architecture. For example, the deep learning neural network can include any suitable number of any suitable type of layers (e.g., an input layer, one or more hidden layers, an output layer, any of which can be a convolutional layer, a dense layer, a non-linear layer, a long short-term memory (LSTM) layer, a pooling layer, a batch normalization layer, or a padding layer). As another example, the deep learning neural network can include any suitable number of neurons in the various layers (e.g., different layers can have the same or different numbers of neurons from each other). As yet another example, the deep learning neural network can include any suitable activation function among the various neurons (e.g., different neurons can have the same or different activation functions from each other) (e.g., softmax, sigmoid, hyperbolic tangent, rectified linear unit). As yet another example, the deep learning neural network can include any suitable inter-neuron connections or inter-layer connections (e.g., forward connections, skip connections, recurrent connections).

[0033] In various cases, the deep learning neural network can be configured to receive medical information as input and generate various GUI-related predictions as output based on the input medical information. Thus, in various cases, the model component can execute the deep learning neural network on patient metadata, and such execution can cause the deep learning neural network to generate one or more GUI-related inferences about a medical patient. More specifically, the model component can feed the patient metadata into the input layer of the deep learning neural network. In various aspects, the patient metadata can complete a forward pass through one or more hidden layers of the deep learning neural network. In various cases, the output layer of the deep learning neural network can calculate the one or more GUI-related inferences based on the activation maps provided by the one or more hidden layers.

[0034] In various aspects, the one or more GUI-related inferences can be any suitable electronic data that represents, conveys, indicates, describes, or otherwise characterizes substantial or aesthetic content that would be suitable (from the perspective of the deep learning neural network) for viewing by a medical patient.

[0035] As a non - limiting example, the one or more GUI - related inferences may include an indication of relevant vital sign categories. In various aspects, the indication of relevant vital sign categories can be any suitable electronic data that indicates or specifies which one (or more) of the plurality of vital sign categories is (are) most clinically relevant to the medical patient (as determined by a deep - learning neural network). In fact, different medical patients can have different clinical profiles (e.g., different physical attributes, different medications, different pathologies, or different severities of pathologies). Additionally, different vital sign categories can be considered more or less relevant to different clinical profiles. Thus, certain vital sign categories can be considered relevant to some medical patients and those same certain vital sign categories can conversely be considered irrelevant to other medical patients. Accordingly, in various situations, patient metadata can be considered to represent the specific clinical profile of the medical patient, and the indication of relevant vital sign categories can represent or specify which one or more of the plurality of vital sign categories the deep - learning neural network has inferred or predicted to be relevant to those specific clinical profiles.

[0036] For example, assume that the patient metadata indicates that the medical patient has a known history of glaucoma. In such a case, the deep - learning neural network may infer that blood pressure is a relevant vital sign category with respect to glaucoma (e.g., because glaucoma is significantly closely associated with excessive intraocular pressure). Thus, the indication of relevant vital sign categories can indicate or specify that blood pressure is particularly relevant to the medical patient and that other vital sign categories (e.g., heart rate, body temperature) are less relevant to the medical patient. As another example, assume that the patient metadata indicates that the medical patient is on an antimicrobial drug regimen. In such a case, the deep - learning neural network may infer that body temperature is a relevant vital sign category with respect to the antimicrobial drug (e.g., because antimicrobial drugs are typically associated with inducing fever). Thus, the indication of relevant vital sign categories can indicate or specify that body temperature is particularly relevant to the medical patient and that other vital sign categories are less relevant to the medical patient.

[0037] As another non-limiting example, the one or more GUI-related inferences may include a recommended visual style indication identifier. In various aspects, the recommended visual style indication identifier can be any suitable electronic data that indicates or specifies various visually stylized elements (e.g., font size, color scheme, brightness, contrast, geometric pattern) that will assist, facilitate, or otherwise improve (from the perspective of a deep learning neural network) the GUI visibility for a medical patient. In fact, as described above, different medical patients may have different clinical characteristics. Additionally, depending on such different clinical characteristics, different visually stylized elements may be considered to be more comfortable to view or less comfortable to view. Thus, certain visually stylized elements may be considered to be comfortable for some medical patients to view, and those certain visually stylized elements may conversely be considered to be uncomfortable for other medical patients to view. Therefore, in various cases, patient metadata may be considered to represent the specific clinical characteristics of a medical patient, and the recommended visual style indication identifier may represent or specify various visually stylized elements that the deep learning neural network has inferred or predicted to be comfortable or highly suitable for those specific clinical characteristics.

[0038] For example, assume that the patient metadata indicates that the medical patient is an elderly person. In such cases, the deep learning neural network may infer that the elderly person generally has an easier time viewing large font sizes and a more difficult time viewing small font sizes (e.g., because visual acuity generally decreases with age). Thus, the recommended visual style indication identifier may indicate or specify that a large font size would be appropriate for the medical patient, or that a small font size would be inappropriate for the medical patient. As another example, assume that the patient metadata indicates that the medical patient is a young child. In such cases, the deep learning neural network may infer that children have an easier time viewing a colored GUI and a more difficult time viewing a monotonously colored GUI (e.g., because color variety can help maintain a child's attention). Thus, the recommended visual style indication identifier may indicate or specify that a rainbow color scheme would be appropriate for the medical patient, or that a monochromatic color scheme would be inappropriate for the medical patient.

[0039] As yet another non-limiting example, the one or more GUI-related inferences may include recommended vital sign thresholds. In various aspects, the recommended vital sign thresholds may be any suitable scalar that demarcates, delineates, or otherwise serves as a boundary for healthy behavior for any vital sign category identified by a relevant vital sign category indication identifier. In fact, as noted above, different medical patients may have different clinical profiles. Further, what vital sign behaviors are considered healthy or acceptable may vary across such different clinical profiles. Thus, certain vital sign behaviors may be considered healthy or acceptable for some medical patients, and those same vital sign behaviors may conversely be considered unhealthy or unacceptable for other medical patients. Accordingly, in various situations, patient metadata may be considered to represent the specific clinical profile of a medical patient, a relevant vital sign category indication identifier may specify the vital sign categories that a deep learning neural network has inferred or predicted to be relevant to those specific clinical profiles, and the recommended vital sign thresholds may be numerical markers inferred or predicted by the deep learning neural network that represent the boundary for healthy or acceptable behavior for that vital sign category of those specific clinical profiles.

[0040] For example, assume that the relevant vital sign category indication identifier specifies blood pressure, and further assume that the patient metadata indicates that the medical patient has a known history of glaucoma. Now, the deep learning neural network may infer that glaucoma is associated with high blood pressure, and thus the deep learning neural network may generate a recommended vital sign threshold as an upper-bound blood pressure value. If the patient metadata indicates that the medical patient has experienced only mild glaucoma, the deep learning neural network may make the upper-bound blood pressure value a less conservative value (e.g., the deep learning neural network may infer that 135 millimeters of mercury (mmHG) may be the upper boundary for acceptable blood pressure for the medical patient). Conversely, if the patient metadata indicates that the medical patient has experienced severe glaucoma, the deep learning neural network may make the upper-bound blood pressure value a more conservative value (e.g., the deep learning neural network may infer that 120 mmHG may be the upper boundary for acceptable blood pressure for the medical patient).

[0041] In any case, the model component may perform the deep learning neural network on the patient metadata, and such performance may result in the one or more GUI-related inferences.

[0042] In various embodiments, a display component of the computerized tool may electronically control any suitable electronic display (e.g., a computer screen, a smart phone screen). In various aspects, the display component may visually present a GUI modulated for the patient on the electronic display based on the one or more GUI-related inferences generated by the deep learning neural network.

[0043] In particular, as described above, a medical patient can be associated with the plurality of vital sign categories, and real-time measurements corresponding to the plurality of vital sign categories can be captured or recorded from the medical patient by any suitable medical equipment. In various aspects, the GUI modulated for the patient can prominently depict, illustrate, or otherwise show in text, numerical, or graphical form the real-time measurements corresponding to any vital sign category designated by the indication identifier indicated by the relevant vital sign category. In fact, in some cases, the GUI modulated for the patient can depict the real-time measurements corresponding to the indication identifier of the relevant vital sign category and can exclude, omit, hide, or otherwise not depict any real-time measurements corresponding to the remaining vital sign categories among the plurality of vital sign categories. However, in other cases, the GUI modulated for the patient can depict the real-time measurements corresponding to the indication identifier of the relevant vital sign category and can depict the real-time measurements corresponding to the remaining vital sign categories among the plurality of vital sign categories, but can illustrate the latter in a smaller size (e.g., half or multiple times smaller) than the former (e.g., can visually minimize the latter so that visual attention is attracted to the former). In any case, the GUI modulated for the patient can be considered to prominently display visually the real-time measurements of any vital sign category that the deep learning neural network has inferred or predicted to be clinically relevant to the medical patient, and thus is called "modulated for the patient".

[0044] Furthermore, in various aspects, the display component can present the GUI modulated for the patient in accordance with the recommended visual style indication identifier. In other words, the recommended visual style indication identifier can specify various visually stylized elements (e.g., font size, color scheme, brightness) that the deep learning neural network has inferred or predicted to be easy, appropriate, or comfortable to view for the medical patient, and the GUI modulated for the patient can be constructed from such visually stylized elements, and is also thus called "modulated for the patient".

[0045] Further, in various cases, the display component may continuously, persistently, or periodically check whether the real-time measurement results prominently depicted by the GUI modulated for the patient meet the recommended vital sign thresholds. If the display component determines that those real-time measurement results fail to meet the recommended vital sign thresholds (e.g., if those measurements exceed the upper boundary represented by the recommended vital sign thresholds; if those measurements fall below the lower boundary represented by the recommended vital sign thresholds), then the display component may cause the GUI modulated for the patient to depict or illustrate an electronic warning indicating such failure. In other words, whenever the real-time measurement results of any vital sign category inferred or predicted by the deep learning neural network as being particularly relevant to a medical patient fail to meet the customized thresholds inferred or predicted by the deep learning neural network for the medical patient, the GUI modulated for the patient may depict a visual warning or a warning notification, also thus referred to as "modulated for the patient".

[0046] In any case, the GUI modulated for the patient can be considered such a clinical GUI that is substantially or aesthetically customized or adapted for the clinical characteristics of the medical patient (e.g., for unique physical attributes, for unique medical histories). This is in contrast to the prior art, where the clinical GUI only displays standardized vital sign measurement results in a standardized layout or format for each medical patient, regardless of their clinical characteristics.

[0047] To help make the one or more GUI-related inferences described herein accurate, the deep learning neural network may first be trained. In various aspects, the computerized tools described herein may facilitate such training in any suitable manner (e.g., in a supervised manner) based on any suitable training dataset.

[0048] The various embodiments described herein can be used to solve problems that are highly technical in nature (e.g., to facilitate an intelligent clinical user interface) using hardware or software, which are not abstract and cannot be performed as a set of mental acts of a human. Additionally, some of the processes performed can be carried out by a dedicated computer (e.g., a deep learning neural network with internal parameters such as convolutional kernels) to implement defined actions related to the clinical user interface. For example, such defined actions can include: accessing, via a device operatively coupled to a processor, attribute data corresponding to a medical patient and real-time measurements of multiple vital sign categories of the medical patient; identifying, via the device and by performing a machine learning model on the attribute data, which of the multiple vital sign categories is clinically relevant to the medical patient, thereby producing the identified vital sign category; and visually presenting, via the device and on a graphical user interface, the real-time measurements of the identified vital sign category. In various aspects, such defined actions can further include: determining, via the device and by performing a machine learning model, a visual style predicted to assist the medical patient in viewing the graphical user interface, wherein the real-time measurements of the identified vital sign category can be visually presented according to the visual style. Still further, such defined actions can include: generating, via the device, an electronic warning in response to the real-time measurements of the identified vital sign category failing to meet a threshold, wherein the threshold can be calculated by a machine learning model.

[0049] Such defined actions are not performed manually by a human. In fact, neither the human mind nor a person with pen and paper can: electronically perform an artificial neural network on a patient's metadata so that the artificial neural network identifies which of multiple vital sign categories (e.g., heart rate category, blood pressure category) is most clinically relevant to the patient, determine how to stylize (e.g., in terms of font size or color scheme) real-time measurements of such identified vital sign categories visually to facilitate or improve the patient's viewing comfort, and calculate a unique numerical threshold that separates attentive behavior from inattentive behavior of the real-time measurements of the identified vital sign categories; and electronically present such a GUI that displays such real-time measurements of the identified vital sign categories according to the determined visual style and displays a warning notification when such real-time measurements fail to meet the calculated threshold. In fact, a machine learning model (e.g., an artificial neural network) is an inherently computerized construct that cannot be meaningfully performed or trained in any way by the human mind without a computer. Similarly, a GUI is an inherently computerized construct that is electronically presented or projected onto a computer screen and cannot be meaningfully realized by the human mind in any way without a computer. Thus, a computerized tool that can electronically present a clinical GUI whose substantial or aesthetic content is automatically modulated or customized for a patient by a machine learning model is also inherently computerized and cannot be realized in any sensible, practical, or reasonable way without a computer.

[0050] In addition, the various embodiments described herein can integrate various teachings related to intelligent clinical user interfaces into practical applications. As described above, the prior art generates clinical GUIs in a static, standardized manner. That is, such prior art clinical GUIs display real-time measurements of the same, consistent vital sign categories in the same, consistent visual format or layout for all patients. Unfortunately, although such consistent vital sign visualization may be comfortable, appropriate, or relevant for some patients, it is generally not comfortable, appropriate, or relevant for all patients.

[0051] As recognized by the present inventors, such disadvantages of the prior art can be improved by leveraging artificial intelligence. In particular, various embodiments described herein may involve configuring a deep learning neural network to receive metadata (e.g., physical characteristics, demographics, medical history) regarding any given medical patient as input and to produce as output one or more GUI-related inferences regarding the given medical patient. In some aspects, such one or more GUI-related inferences may include a determination as to which one of a defined set of vital sign categories is most clinically relevant to the given medical patient (e.g., different vital sign categories may be more or less relevant to different patients with different pathologies or different physical attributes). In other aspects, such one or more GUI-related inferences may include a determination as to what visual style will help improve or facilitate the viewing comfort of the given medical patient (e.g., different patients with different pathologies or different physical attributes may find different visual styles more or less appealing or discordant). In still other aspects, such one or more GUI-related inferences may include a calculation of the numerical boundaries that uniquely discriminate healthy, non-concerning, or acceptable vital sign activity from unhealthy, concerning, or unacceptable vital sign activity. In various cases, the various embodiments described herein may also include visually presenting such a clinical GUI that is based on or otherwise complies with such one or more GUI-related inferences (e.g., depicting real-time measurements of any vital sign category predicted by the deep learning neural network to be most clinically relevant to the given medical patient; utilizing visually stylized elements predicted by the deep learning neural network to enhance the viewing comfort of the given medical patient; depicting a warning when real-time measurements of a clinically relevant vital sign category fail to meet the unique threshold calculated by the deep learning neural network for the given medical patient). Thus, the various embodiments described herein may be considered to utilize artificial intelligence to automatically generate personalized or customized clinical GUIs (e.g., personalized or customized vital sign visualizations) based on the clinical uniqueness of an individual medical patient. In stark contrast, prior art clinical GUIs use a uniform aesthetic to display uniform vital sign information without considering the clinical uniqueness of an individual medical patient.

[0052] For at least these reasons, compared to the prior art, the various embodiments described herein facilitate improved clinical GUIs. Accordingly, the various embodiments described herein of course constitute a tangible and specific technological improvement or technological advantage in the field of clinical user interfaces. Thus, such embodiments are clearly eligible as a useful and practical application of a computer.

[0053] In addition, the various embodiments described herein can control real-world tangible devices based on the disclosed teachings. For example, the various embodiments described herein can electronically train or execute a real-world deep learning neural network on real-world patient metadata and can electronically present a real-world clinical GUI on a real-world computer screen based on the inference results generated by such real-world deep learning neural networks.

[0054] It should be understood that the figures and descriptions herein provide non-limiting examples of the various embodiments and are not necessarily drawn to scale.

[0055] Figure 1 A block diagram of an exemplary non-limiting system 100 that can facilitate an intelligent clinical user interface in accordance with one or more embodiments described herein is illustrated. As shown, the intelligent clinical user interface system 102 can be electronically integrated with patient metadata 104 or with a plurality of real-time vital sign measurements 108 via any suitable wired or wireless electronic connection.

[0056] In various embodiments, patient metadata 104 may correspond to or be associated with any suitable medical patient (e.g., human, animal, or otherwise). In various aspects, patient metadata 104 can be one or more scalars, one or more vectors, one or more matrices, one or more tensors, one or more strings, or any suitable combination thereof, which indicate, convey, or otherwise represent any suitable attribute or characteristic of the medical patient. As a non-limiting example, patient metadata 104 may indicate, convey, or otherwise represent the age or age range of the medical patient. As another non-limiting example, patient metadata 104 may indicate, convey, or otherwise represent the biological sex or gender of the medical patient. As yet another non-limiting example, patient metadata 104 may indicate, convey, or otherwise represent the weight or body mass of the medical patient. As yet another non-limiting example, patient metadata 104 may indicate, convey, or otherwise represent the height or body width of the medical patient. As yet another non-limiting example, patient metadata 104 may indicate, convey, or otherwise represent the body fat percentage of the medical patient. As another non-limiting example, patient metadata 104 may indicate, convey, or otherwise represent one or more health habits or lifestyle habits of the medical patient, such as: how much or what type of tobacco (if any) the medical patient uses per day, week, month, or year; how much or what type of physical exercise (if any) the medical patient performs per day, week, month, or year; or how much or what type of alcohol (if any) the medical patient consumes per day, week, month, or year. As yet another non-limiting example, patient metadata 104 may indicate, convey, or otherwise represent one or more health states of the medical patient, such as: whether the medical patient is pregnant; how long the medical patient has been pregnant; whether the medical patient has a known pathology (e.g., cancer, heart disease, diabetes, asthma, COVID-19, glaucoma); or how severe such known pathology is (e.g., metastatic cancer compared to non-metastatic cancer). As another non-limiting example, patient metadata 104 may indicate, convey, or otherwise represent one or more prescribed treatments of the medical patient, such as: what type of medication (if any) the medical patient consumes; what type of physical therapy or chemotherapy (if any) the medical patient undergoes; or what type of medical procedure or surgical intervention (if any) the medical patient has received. As yet another non-limiting example, patient metadata 104 may indicate, convey, or otherwise represent one or more previously captured medical images of the medical patient, such as: an X-ray image of the anatomy of the previously captured medical patient; a magnetic resonance image of the anatomy of the previously captured medical patient; or a computed tomography image of the anatomy of the previously captured medical patient.As yet another non - limiting example, the patient metadata 104 may indicate, convey, or otherwise represent one or more prosthetics or implants that a medical patient has, such as: a prosthetic limb; a pacemaker; an intravenous stent; or a spinal rod. As yet another non - limiting example, the patient metadata 104 may indicate, convey, or otherwise represent one or more symptoms that a medical patient complains of, such as: shortness of breath; exercise intolerance; or chest pain. As another non - limiting example, the patient metadata 104 may indicate, convey, or otherwise represent the occupation or profession of a medical patient, such as: an office clerk; a truck driver; or a coal miner. As yet another non - limiting example, the patient metadata 104 may indicate, convey, or otherwise represent the educational level of a medical patient, such as: elementary school; middle school; undergraduate school; or graduate school. Thus, the patient metadata 104 may be considered to be or to include at least a portion of the unique medical history of a medical patient. In other words, the patient metadata 104 may be considered to represent the various clinical characteristics of a medical patient. In various cases, the patient metadata 104 may be input into or otherwise accessed by any suitable computing device having any suitable human - machine interface, such as: a desktop computer; a laptop computer; a smart phone; or a tablet device.

[0057] In various embodiments, a medical patient may be considered to be associated with a plurality of patient vital sign categories 106. In various aspects, the plurality of patient vital sign categories 106 may include any suitable number of patient vital sign categories, where a patient vital sign category may be any suitable different type or class of measurable biological vitality signal. In various cases, the plurality of real - time vital sign measurements 108 may respectively correspond to the plurality of patient vital sign categories 106. With respect to Figure 2 non - limiting aspects are described.

[0058] Figure 2 Exemplary non - limiting block diagram 200 showing the plurality of patient vital sign categories 106 and the plurality of real - time vital sign measurements 108 in accordance with one or more embodiments described herein is illustrated.

[0059] In various aspects, as shown in the figure, the plurality of patient vital sign categories 106 can include n categories, where n is any suitable positive integer: patient vital sign category 106(1) to patient vital sign category 106(n). In various cases, each patient vital sign category among the plurality of patient vital sign categories 106 can be one or more scalars, one or more vectors, one or more matrices, one or more tensors, one or more strings, or any suitable combination thereof, which can indicate, convey, or otherwise represent a unique or different type or class of quantifiable anatomical health or vitality signals of a medical patient. As a non-limiting example, one patient vital sign category among the plurality of patient vital sign categories 106 can be a blood pressure category, which can refer to the fluid pressure exhibited by the veins or arteries of a medical patient. As another non-limiting example, one patient vital sign category among the plurality of patient vital sign categories 106 can be a pulse rate category, which can refer to the rate of the heartbeat of a medical patient. As yet another non-limiting example, one patient vital sign category among the plurality of patient vital sign categories 106 can be a pulse intensity category, which can refer to the perfusion index exhibited by the heart of a medical patient. As still another non-limiting example, one patient vital sign category among the plurality of patient vital sign categories 106 can be an electrocardiogram category, which can refer to the myocardial depolarization and repolarization exhibited by the heart of a medical patient. As even another non-limiting example, one patient vital sign category among the plurality of patient vital sign categories 106 can be a seismocardiogram category, which can refer to the chest wall acceleration and deceleration induced by myocardial weakness exhibited by a medical patient. As another non-limiting example, one patient vital sign category among the plurality of patient vital sign categories 106 can be a phonocardiogram category, which can refer to the sounds or murmurs exhibited by the heart of a medical patient. As yet another non-limiting example, one patient vital sign category among the plurality of patient vital sign categories 106 can be a body temperature category, which can refer to the temperature exhibited by any suitable anatomical structure of a medical patient (e.g., oral temperature, rectal temperature, axillary body temperature, ear temperature, skin temperature). As still another non-limiting example, one patient vital sign category among the plurality of patient vital sign categories 106 can be a respiratory rate category, which can refer to the rate at which a medical patient breathes. As even another non-limiting example, one patient vital sign category among the plurality of patient vital sign categories 106 can be an endoscopy category, which can refer to the endoscopic visual monitoring of any suitable anatomical structure of a medical patient (e.g., an endoscope inserted transorally can visually monitor the trachea, lungs, esophagus, or stomach of a medical patient; an endoscope inserted transanally can visually monitor the rectum, small intestine, or large intestine of a medical patient; an endoscope inserted transnasally can visually monitor the sinus cavities of a medical patient).As another non-limiting example, one of the plurality of patient vital sign categories 106 can be a blood glucose category, which can refer to the concentration of glucose in the blood of a medical patient.

[0060] In various cases, as shown, the plurality of real-time vital sign measurements 108 can respectively correspond to the plurality of patient vital sign categories 106. Thus, since the plurality of patient vital sign categories 106 can include n categories, the plurality of real-time vital sign measurements 108 can similarly include n sets of measurements: real-time vital sign measurements 108(1) through real-time vital sign measurements 108(n). In various aspects, each of the plurality of real-time vital sign measurements 108 can be one or more scalars, one or more vectors, one or more matrices, one or more tensors, one or more strings, or any suitable combination thereof, which represent a time series of electronically measured data points corresponding to a respective one of the plurality of patient vital sign categories 106.

[0061] As a non-limiting example, the real-time vital sign measurement result 108(1) may correspond to the patient vital sign category 106(1). Thus, the real-time vital sign measurement result 108(1) can be a time series of currently recorded electronically measured data points of any unique or distinct type or class that is associated with a medical patient and that belongs to a quantifiable anatomical health or vitality signal represented by the patient vital sign category 106(1). For example, assume that the patient vital sign category 106(1) is a blood pressure category. In such a case, the real-time vital sign measurement result 108(1) can be a time series showing how the electronically measured blood pressure of the medical patient is currently behaving over time. In another example, assume that the patient vital sign category 106(1) is a pulse rate category. In such a case, the real-time vital sign measurement result 108(1) can be a time series showing how the electronically measured pulse rate of the medical patient is currently behaving over time. In yet another example, assume that the patient vital sign category 106(1) is a pulse intensity category. In such a case, the real-time vital sign measurement result 108(1) can be a time series showing how the electronically measured pulse intensity (e.g., expressed as a perfusion index value) of the medical patient is currently behaving over time. In still another example, assume that the patient vital sign category 106(1) is an electrocardiogram category. In such a case, the real-time vital sign measurement result 108(1) can be an electrocardiogram trace showing how the myocardium of the medical patient is currently polarizing or depolarizing over time. In an even further example, assume that the patient vital sign category 106(1) is a seismocardiogram category. In such a case, the real-time vital sign measurement result 108(1) can be a seismocardiogram trace showing how the chest wall of the medical patient is currently accelerating or decelerating over time. In another example, assume that the patient vital sign category 106(1) is a phonocardiogram category. In such a case, the real-time vital sign measurement result 108(1) can be a phonocardiogram trace showing what kind of noise the heart of the medical patient is currently emitting over time. In yet another example, assume that the patient vital sign category 106(1) is a body temperature category. In such a case, the real-time vital sign measurement result 108(1) can be a time series showing how the anatomical temperature of the medical patient is currently behaving over time. In still another example, assume that the patient vital sign category 106(1) is an endoscopy category. In such a case, the real-time vital sign measurement result 108(1) can be the currently recorded video feed generated by an endoscope inserted into the medical patient. In an even further example, assume that the patient vital sign category 106(1) is a blood glucose category. In such a case, the real-time vital sign measurement result 108(1) can be a time series showing how the electronically measured blood glucose level of the medical patient is currently behaving over time.

[0062] As another non-limiting example, the real-time vital sign measurement results 108(n) may correspond to the patient vital sign categories 106(n). Thus, as described above, the real-time vital sign measurement results 108(n) can be a time series of electronically measured data points currently being recorded that are associated with a medical patient and are of any unique or distinct type or class of quantifiable anatomical health or vitality signals represented by the patient vital sign categories 106(n).

[0063] In various aspects, any suitable medical diagnostic equipment or sensor can be attached to, inserted into, or worn by a medical patient to electronically capture, record, load, document, or otherwise measure the plurality of real-time vital sign measurement results 108. As some non-limiting examples, such equipment or sensors can include: a sphygmomanometer; a pulse tracker; a pulse oximeter; an electrocardiogram monitor; a seismocardiogram monitor; a phonocardiogram monitor; a clinical thermometer; a clinical endoscope; or a clinical blood glucose monitor.

[0064] Referring back Figure 1 , it may be desirable to generate such a clinical GUI that displays at least some of the plurality of real-time vital sign measurement results 108 in a manner customized or modulated for a medical patient. As described herein, the intelligent clinical user interface system 102 can facilitate such generation.

[0065] In various embodiments, the intelligent clinical user interface system 102 can include a processor 110 (e.g., a computer processing unit, a microprocessor) and a non-transitory computer-readable memory 112 that is operatively or operationally or communicatively connected or coupled to the processor 110. The non-transitory computer-readable memory 112 can store computer-executable instructions that, when executed by the processor 110, can cause the processor 110 or other components of the intelligent clinical user interface system 102 (e.g., the access component 114, the model component 116, the display component 118) to perform one or more actions. In various embodiments, the non-transitory computer-readable memory 112 can store computer-executable components (e.g., the access component 114, the model component 116, the display component 118), and the processor 110 can execute the computer-executable components.

[0066] In various embodiments, the intelligent clinical user interface system 102 may include an access component 114. In various aspects, the access component 114 may electronically receive or otherwise electronically access the patient metadata 104 or the plurality of real-time vital sign measurements 108. In various cases, the access component 114 may electronically retrieve the patient metadata 104 or the plurality of real-time vital sign measurements 108 from any suitable centralized or decentralized data structure (not shown) or from any suitable centralized or decentralized computing device (not shown), whether local to or remote from the access component 114. As a non-limiting example, the access component 114 may electronically retrieve the patient metadata 104 from any computing device (e.g., a desktop computer, a laptop computer, a smart phone, a tablet computer) responsible for maintaining, storing, or collecting the patient metadata 104. As another non-limiting example, the access component 114 may electronically retrieve the plurality of real-time vital sign measurements 108 from any medical diagnostic equipment (e.g., a pulse monitor, an electrocardiogram monitor, an endoscope) used to measure, capture, or create the plurality of real-time vital sign measurements 108. In any case, the access component 114 may electronically obtain or access the patient metadata 104 or the plurality of real-time vital sign measurements 108 such that other components of the intelligent clinical user interface system 102 may electronically interact with the patient metadata 104 or with the plurality of real-time vital sign measurements 108 (e.g., via a proxy).

[0067] In various embodiments, the intelligent clinical user interface system 102 may include a model component 116. In various aspects, as described herein, the model component 116 may execute a deep learning neural network on the patient metadata 104, thereby generating various GUI-related inferences about a medical patient.

[0068] In various embodiments, the intelligent clinical user interface system 102 may include a display component 118. In various cases, as described herein, the display component 118 may visually present a clinical GUI modulated for a medical patient based on the various GUI-related inferences generated by the deep learning neural network.

[0069] Figure 3 A block diagram illustrating an exemplary non-limiting system 300 that may facilitate an intelligent clinical user interface including a deep learning neural network and one or more GUI-related inferences, according to one or more embodiments described herein. As shown, in some cases, system 300 may include the same components as system 100 and may further include a deep learning neural network 302 and one or more GUI-related inferences 304.

[0070] In various embodiments, the model component 116 may store, maintain, control, or otherwise access the deep learning neural network 302 electronically. In various cases, the deep learning neural network 302 may have or otherwise exhibit any suitable deep learning internal architecture. For example, the deep learning neural network 302 may have an input layer, one or more hidden layers, and an output layer. In various instances, any of such layers may be coupled together by any suitable inter-neuron or inter-layer connections (such as forward connections, skip connections, or recurrent connections). Additionally, in various cases, any of such layers may be any suitable type of neural network layer having any suitable learnable or trainable internal parameters. For example, any of such input layer, one or more hidden layers, or output layer may be a convolutional layer, and the learnable or trainable parameters of the convolutional layer may be convolutional kernels. As another example, any of such input layer, one or more hidden layers, or output layer may be a dense layer, and the learnable or trainable parameters of the dense layer may be weight matrices or bias values. As yet another example, any of such input layer, one or more hidden layers, or output layer may be a batch normalization layer, and the learnable or trainable parameters of the batch normalization layer may be shift factors or scale factors. As even another example, any of such input layer, one or more hidden layers, or output layer may be an LSTM layer, and the learnable or trainable parameters of the LSTM layer may be input state weight matrices or hidden state weight matrices. Further still, in various cases, any of such layers may be any suitable type of neural network layer having any suitable fixed or non-trainable internal parameters. For example, any of such input layer, one or more hidden layers, or output layer may be a non-linear layer, a padding layer, a pooling layer, or a concatenation layer.

[0071] In various aspects, the deep learning neural network 302 may be configured to make various determinations related to the clinical GUI based on the input medical data. Thus, in various cases, the model component 116 may electronically execute the deep learning neural network 302 on the patient metadata 104, and such execution may cause the deep learning neural network 302 to generate the one or more GUI-related inferences 304. The various non-limiting aspects are described with respect to Figure 4 to describe the various non-limiting aspects.

[0072] Figure 4 Exemplary non-limiting block diagram 400 illustrates how the deep learning neural network 302 may generate the one or more GUI-related inferences 304 in accordance with one or more embodiments described herein.

[0073] In various embodiments, the model component 116 may electronically execute a deep learning neural network 302 on patient metadata 104. In various aspects, such execution may produce the one or more GUI-related inferences 304. More specifically, the model component 116 may feed the patient metadata 104 into the input layer of the deep learning neural network 302. In various cases, the patient metadata 104 may complete a forward pass through one or more hidden layers of the deep learning neural network 302. In various cases, the output layer of the deep learning neural network 302 may calculate or compute the one or more GUI-related inferences 304 based on the activation maps provided by the one or more hidden layers.

[0074] In various aspects, the one or more GUI-related inferences 304 may be any suitable electronic data that exhibits any suitable format, size, or dimension and that indicates, conveys, or otherwise specifies any suitable substantive GUI content or any suitable aesthetic GUI format or arrangement that would be well-suited, comfortable, or otherwise relevant to a medical patient. Put another way, the patient metadata 104 may be considered to represent the clinical characteristics (e.g., unique attributes, unique medical history) of a medical patient, and the deep learning neural network 302 may be considered to infer or predict what content would be suitable to visually display to the medical patient on a clinical GUI or how that content should be visually presented in order to best commensurate or align with those clinical characteristics.

[0075] In various aspects, the one or more GUI-related inferences 304 can include a relevant vital sign category indication identifier 402. In various cases, the relevant vital sign category indication identifier 402 can be one or more scalars, one or more vectors, one or more matrices, one or more tensors, one or more strings, or any suitable combination thereof, which indicates, conveys, or otherwise specifies which one of the plurality of patient vital sign categories 106 is most clinically relevant or related to the medical patient. In other words, the patient metadata 104 can represent the clinical characteristics of the medical patient, and given such clinical characteristics, the relevant vital sign category indication identifier 402 can specify which one of the plurality of patient vital sign categories 106 is predicted by the deep learning neural network 302 to be particularly worthy of monitoring on the clinical GUI. In some aspects, the relevant vital sign category indication identifier 402 can be considered a segmentation mask that specifies an inferred or predicted relevance score (e.g., a scalar between 0 and 1, where 0 indicates no relevance and 1 indicates maximum relevance) for each of the plurality of patient vital sign categories 106. In some cases, any one of the plurality of patient vital sign categories 106 having the highest available relevance score can be considered to be most clinically relevant or related to the medical patient.

[0076] Although the disclosure herein mainly describes the relevant vital sign category indication identifier 402 as specifying or indicating a single patient vital sign category among the plurality of patient vital sign categories 106, this is a non-limiting example for ease of explanation. In various aspects, the relevant vital sign category indication identifier 402 can specify or indicate any suitable number (e.g., one or more) of clinically relevant patient vital sign categories. For example, in some cases, the relevant vital sign category indication identifier 402 can be considered a segmentation mask that specifies an inferred or predicted relevance score for each of the plurality of patient vital sign categories 106, and any one of the plurality of patient vital sign categories 106 having an inferred or predicted relevance score higher than any suitable threshold can be considered to be clinically relevant to the medical patient. As another example, in some cases, the relevant vital sign category indication identifier 402 can be considered a segmentation mask that specifies an inferred or predicted relevance score for each of the plurality of patient vital sign categories 106, and any one of the plurality of patient vital sign categories 106 corresponding to the top x inferred or predicted relevance scores (where x is any suitable positive integer) can be considered to be clinically relevant to the medical patient.

[0077] In any case, the relevant vital sign category indication identifier 402 can be considered to identify or specify a patient vital sign category from among the plurality of patient vital sign categories 106 that the deep learning neural network 302 has determined to be clinically particularly relevant to the patient metadata 104 and thus to the medical patient. After all, different medical patients can have different clinical characteristics (e.g., different pathologies, different degrees of pathology severity, different medications, different lifestyles, different occupational risks), and thus different vital sign categories can be considered to be more or less clinically relevant to such different medical patients.

[0078] For the purpose of illustrating various non-limiting examples, assume that the plurality of patient vital sign categories 106 includes the following: blood glucose category; pulse rate category; body temperature category; phonocardiogram category; and enteroscope category. In other words, assume that a medical patient (e.g., who may currently be in a hospital bed) is currently equipped with: a blood glucose monitor; a heart rate monitor; a thermometer; a phonocardiogram monitor; and an enteroscope.

[0079] Now, assume that the patient metadata 104 indicates that the medical patient has diabetes. In such a case, the deep learning neural network 302 can infer or predict that blood glucose is more clinically relevant to the medical patient than pulse rate, body temperature, phonocardiogram, or enteroscope. After all, although it can be considered prudent to monitor all of blood glucose, pulse rate, body temperature, phonocardiogram, or enteroscope for the medical patient, diabetes is a specific pathology that uniquely affects or is affected by blood glucose (e.g., an individual with diabetes faces a higher risk of hypoglycemia or hyperglycemia). Therefore, the relevant vital sign category indication identifier 402 can indicate, designate, or specify the blood glucose category as being clinically relevant to the medical patient.

[0080] In another example, assume that the patient metadata 104 instead indicates that the medical patient has had three heart attacks in the previous two years. In such a case, the deep learning neural network 302 can infer or predict that pulse rate is more clinically relevant to the medical patient than blood glucose, body temperature, phonocardiogram, or enteroscope. After all, although it can be considered prudent to monitor all of blood glucose, pulse rate, body temperature, phonocardiogram, or enteroscope for the medical patient, a history of extensive heart attacks indicates that the medical patient is uniquely prone to an unstable or erratic heart rate (e.g., an individual with many heart attacks faces a higher risk of tachycardia or bradycardia). Therefore, the relevant vital sign category indication identifier 402 can indicate or designate the pulse rate category as being clinically relevant to the medical patient.

[0081] In yet another example, assume that the patient metadata 104 instead indicates that the medical patient is on a trazodone regimen. In such cases, the deep learning neural network 302 can infer or predict that body temperature is more clinically relevant to the medical patient than blood glucose, pulse rate, phonocardiogram, or enteroscopy. After all, although it may be considered prudent to monitor all of blood glucose, pulse rate, body temperature, phonocardiogram, or enteroscopy for the medical patient, trazodone is a particular drug known to cause anatomical temperature fluctuations (e.g., night sweats) as a side effect. Accordingly, the relevant vital sign category indication identifier 402 can indicate or designate the body temperature category as being clinically relevant to the medical patient.

[0082] In even another example, assume that the patient metadata 104 instead indicates that the medical patient has complained of persistent chest pain and cough. In such cases, the deep learning neural network 302 can infer or predict that a phonocardiogram is more clinically relevant to the medical patient than blood glucose, pulse rate, body temperature, or enteroscopy. After all, although it may be considered prudent to monitor all of blood glucose, pulse rate, body temperature, phonocardiogram, or enteroscopy for the medical patient, persistent chest pain and cough are symptoms commonly associated with heart murmurs or heart valve disease, and phonocardiogram tracings are well-suited to diagnosing heart murmurs or heart valve disease. Accordingly, the relevant vital sign category indication identifier 402 can indicate or designate the phonocardiogram category as being clinically relevant to the medical patient.

[0083] In yet another example, assume that the patient metadata 104 instead indicates that the medical patient is afflicted with tapeworms. In such cases, the deep learning neural network 302 can infer or predict that enteroscopy is more clinically relevant to the medical patient than blood glucose, pulse rate, body temperature, or phonocardiogram. After all, although it may be considered prudent to monitor all of blood glucose, pulse rate, body temperature, phonocardiogram, or enteroscopy for the medical patient, tapeworms are parasites that typically invade the digestive tract and can thus be viewed or detected via enteroscopy. Accordingly, the relevant vital sign category indication identifier 402 can indicate or designate the enteroscopy category as being clinically relevant to the medical patient.

[0084] Thus, the deep learning neural network 302 can be considered to infer or predict which one of the plurality of patient vital sign categories 106 will be most helpful, most needed, or otherwise most warranted given the clinical characteristics represented by the patient metadata 104, and the relevant vital sign category indication identifier 402 can communicate or represent such an inference or prediction.

[0085] In various aspects, the one or more GUI-related inferences 304 can include a recommended visual style indication identifier 404. In various cases, the recommended visual style indication identifier 404 can be one or more scalars, one or more vectors, one or more matrices, one or more tensors, one or more strings, or any suitable combination thereof that indicates, conveys, specifies, characterizes, describes, or otherwise defines any suitable visual style that will assist, improve, facilitate, or otherwise benefit the viewing comfort of a medical patient. Put another way, the patient metadata 104 can represent the clinical characteristics of a medical patient, and the recommended visual style indication identifier 404 can indicate a visual style that is predicted by the deep learning neural network 302 to be comfortably viewable, appealing, or otherwise recommended for those medical patients having such clinical characteristics. In various cases, the recommended visual style indication identifier 404 can be considered a classification label that identifies any suitable number of any suitable type of visually stylized elements that are predicted to be comfortably viewable by a medical patient. As a non-limiting example, such visually stylized elements can include font size. That is, the recommended visual style indication identifier 404 can specify one or more font sizes to use or to avoid in order to improve or preserve the viewing comfort or enjoyment of a medical patient. As another non-limiting example, such visually stylized elements can include color scheme. That is, the recommended visual style indication identifier 404 can specify one or more colors or color combinations to use or to avoid in order to improve or preserve the viewing comfort or enjoyment of a medical patient. As yet another non-limiting example, such visually stylized elements can include brightness or contrast. That is, the recommended visual style indication identifier 404 can specify one or more screen brightness or contrast levels to use or to avoid in order to improve or preserve the viewing comfort or enjoyment of a medical patient. As yet another non-limiting example, such visually stylized elements can include geometric elements. That is, the recommended visual style indication identifier 404 can specify one or more geometric or spatial shapes or patterns to use or to avoid in order to improve or preserve the viewing comfort or enjoyment of a medical patient.

[0086] In any case, the recommended visual style indication identifier 404 can be considered to identify a visual style that the deep learning neural network 302 has determined to be comfortable or appealing (and thus comfortable or appealing to a medical patient) given the patient metadata 104. After all, different medical patients can have different clinical characteristics (e.g., different pathologies, different pathology severities, different medications, different lifestyles, different occupational risks), and different visual styles can thus be more or less tolerable for such different medical patients.

[0087] For example, assume that patient metadata 104 indicates that a medical patient is diagnosed with macular degeneration and uses corrective eyeglass lenses with a prescription of more than three diopters. In such cases, the deep learning neural network 302 can infer that the medical patient has very poor eyesight and can predict or infer the minimum font size that the medical patient may be able to comfortably view given their unique macular degeneration and eyeglass prescription. Thus, when presenting the clinical GUI to the medical patient, the recommended visual style indication identifier 404 can indicate or specify that fonts smaller than the predicted or inferred minimum font size should not be used.

[0088] As another example, assume that patient metadata 104 instead indicates that a medical patient is diagnosed with red color blindness. In such cases, the deep learning neural network 302 can infer that the medical patient cannot reliably or comfortably distinguish red shades. Thus, when presenting the clinical GUI to the medical patient, the recommended visual style indication identifier 404 can indicate or specify that red shades should be avoided.

[0089] As yet another example, assume that patient metadata 104 instead indicates that a medical patient is diagnosed with photic sneezing syndrome. In such cases, the deep learning neural network 302 can infer that the medical patient tends to suddenly sneeze when suddenly exposed to bright light and can predict or infer the maximum screen brightness level at which the medical patient can comfortably view (e.g., without sneezing) given their unique syndrome. Thus, when presenting the clinical GUI to the medical patient, the recommended visual style indication identifier 404 can indicate or specify that screen brightness levels higher than the predicted or inferred maximum brightness level should not be used.

[0090] As even another example, assume that patient metadata 104 instead indicates that a medical patient has a history of light-induced seizures. In such cases, the deep learning neural network 302 can infer that the medical patient tends to seize when exposed to highly alternating geometric patterns such as checkerboards, stripes, or spirals. Thus, when presenting the clinical GUI to the medical patient, the recommended visual style indication identifier 404 can indicate or specify that checkerboard patterns, striped patterns, or spiral patterns should not be used.

[0091] In this way, the deep learning neural network 302 can be considered to infer or predict what aesthetic format or visual scheme would be most comfortable, tolerable, or appealing given the clinical characteristics represented by patient metadata 104, and the recommended visual style indication identifier 404 can communicate or represent such inferences or predictions.

[0092] In various aspects, the one or more GUI-related inferences 304 may include the recommended vital sign thresholds 406. In various cases, the recommended vital sign thresholds 406 may be one or more scalars, one or more vectors, one or more matrices, one or more tensors, or any suitable combination thereof, which indicate or otherwise represent the numerical boundaries that demarcate, delineate, or define the healthy or acceptable behavior of any one patient vital sign category indicated by the associated vital sign category indication identifier 402. Put another way, the patient metadata 104 may represent the clinical characteristics of a medical patient, and given those clinical characteristics, the associated vital sign category indication identifier 402 may specify which particular vital sign category is clinically most relevant, and given those clinical characteristics, the recommended vital sign thresholds 406 may indicate the predicted upper boundary (or predicted lower boundary) that the measurements for that particular vital sign category should not exceed (or fall below). That is, given the patient metadata 104, the recommended vital sign thresholds 406 may be considered to identify the numerical boundaries that the deep learning neural network 302 has determined to separate healthy or acceptable vital sign behavior from unhealthy or unacceptable vital sign behavior. After all, different medical patients may have different clinical characteristics (e.g., different pathologies, different degrees of pathology severity, different medications, different lifestyles, differential occupational risks), and what constitutes or is eligible as acceptable vital sign activity may vary across such different medical patients.

[0093] As a non-limiting example, assume that the associated vital sign category indication identifier 402 designates blood pressure as the clinically relevant vital sign category, and also assume that the patient metadata 104 indicates that the medical patient has a history of hypertension. In such cases, the deep learning neural network 302 may infer that the medical patient is prone to having high blood pressure. Accordingly, the deep learning neural network 302 may predict a unique maximum blood pressure value above which the blood pressure of the medical patient will be considered a concern or unhealthy, and the recommended vital sign threshold 406 may be considered that unique maximum blood pressure value. Note that the conservativeness of that unique maximum blood pressure value may be based on any other information provided in the patient metadata 104. For example, if the patient metadata 104 indicates that the medical patient is sedentary and obese, the deep learning neural network 302 may make that unique maximum blood pressure value more conservative (e.g., at a lower maximum value because the patient's lifestyle indicates less physical resilience). On the other hand, if the patient metadata 104 indicates that the medical patient is physically active and not obese, the deep learning neural network 302 may make that unique maximum blood pressure value less conservative (e.g., at a higher maximum value because the patient's lifestyle indicates greater physical resilience).

[0094] As another non - limiting example, assume that the relevant vital sign category indication identifier 402 designates blood pressure as a clinically relevant vital sign category, and further assume that the patient metadata 104 indicates that the medical patient has a history of having low blood pressure. In such a case, the deep - learning neural network 302 can infer that the medical patient is prone to having too low blood pressure. Thus, the deep - learning neural network 302 can predict a unique minimum blood pressure value below which the medical patient's blood pressure will be considered a concern or unhealthy, and the recommended vital sign threshold 406 can be considered this unique minimum blood pressure value. As described above, note that the conservativeness of this unique minimum blood pressure value can be based on any other information provided in the patient metadata 104. For example, if the patient metadata 104 indicates that the medical patient is a habitual smoker, the deep - learning neural network 302 can make this unique minimum blood pressure value more conservative (e.g., at a high maximum value because the medical patient's lifestyle indicates less physical resilience). On the other hand, if the patient metadata 104 indicates that the medical patient is not a habitual smoker, the deep - learning neural network 302 can make this unique minimum blood pressure value less conservative (e.g., at a lower minimum value because the medical patient's lifestyle indicates greater physical resilience).

[0095] In this way, the deep - learning neural network 302 can be considered to not only infer or predict which patient vital sign category will be most clinically relevant given the clinical traits represented by the patient metadata 104, but also infer or predict the numerical boundaries derived from those clinical traits that delineate healthy or acceptable behavior for that patient vital sign category. The recommended vital sign threshold 406 can convey or represent such numerical boundaries.

[0096] Figure 5 A block diagram illustrating an exemplary non - limiting system 500 that can facilitate an intelligent clinical user interface including a patient - tailored GUI in accordance with one or more embodiments described herein. As shown, in some cases, system 500 can include the same components as system 300 and can also include a graphical user interface tailored for the patient 502 (hereinafter referred to as "patient - tailored GUI 502").

[0097] In various embodiments, the display component 118 may electronically generate a patient-modulated GUI 502 based on the one or more GUI-related inferences 304. In various aspects, the display component 118 may visually present or otherwise cause to be visually presented the patient-modulated GUI 502 on any suitable electronic display of any suitable computing device. As a non-limiting example, the display component 118 may cause the patient-modulated GUI 502 to be presented on the electronic computer screen of any suitable smart phone device (e.g., the smart phone of a medical patient). As another non-limiting example, the display component 118 may cause the patient-modulated GUI 502 to be presented on the electronic computer screen of any suitable wearable device (e.g., the smart watch of a medical patient, the smart glasses of a medical patient). As yet another non-limiting example, the display component 118 may cause the patient-modulated GUI 502 to be presented on the electronic computer screen of any suitable hospital console device (e.g., a bedside hospital monitor near a medical patient). In any case, the substantial content or aesthetic formatting of the patient-modulated GUI 502 may be based on the one or more GUI-related inferences 304 and may thus be considered to be customized or modulated for the medical patient. With respect to Figure 6 describe the various non-limiting aspects.

[0098] Figure 6 Illustrates an exemplary non-limiting block diagram 600 showing a patient-modulated GUI 502 in accordance with one or more embodiments described herein.

[0099] In various embodiments, as shown, the GUI 502 modulated for a patient may include real-time vital sign measurements 602. In various aspects, as described above, the relevant vital sign category indication identifier 402 may identify the patient vital sign category among the plurality of patient vital sign categories 106 as clinically relevant to the medical patient. In various cases, the real-time vital sign measurement 602 may be any one of the plurality of real-time vital sign measurements 108 corresponding to the identified patient vital sign category. As a non-limiting example, assume that the relevant vital sign category indication identifier 402 identifies the patient vital sign category 106(1) as clinically relevant to the medical patient. In such cases, the real-time vital sign measurement 108(1) may be considered as the real-time vital sign measurement 602. As another non-limiting example, assume that the relevant vital sign category indication identifier 402 instead identifies the patient vital sign category 106(n) as clinically relevant to the medical patient. In such cases, the real-time vital sign measurement 108(n) may be considered as the real-time vital sign measurement 602. In any case, the real-time vital sign measurement 602 may be a time series showing the current time-varying behavior or activity of the identified patient vital sign category, and the GUI 502 modulated for the patient may visually display (e.g., numerically or graphically) such a time series. In other words, the GUI 502 modulated for the patient may be considered to visually depict or illustrate the real-time measurement results of any one vital sign category predicted or inferred by the deep learning neural network 302 as being most clinically relevant to the medical patient. For at least this reason, the term "modulated for the patient" may be considered appropriate.

[0100] In some cases, the GUI 502 modulated for a patient may omit or exclude all of the remaining real-time vital sign measurements 108 among the plurality of real-time vital sign measurements 108. However, this is only a non-limiting example. In other cases, the GUI 502 modulated for a patient may display any other real-time vital sign measurements 108 among the plurality of real-time vital sign measurements 108 together with the real-time vital sign measurement 602. However, in such cases, those other real-time vital sign measurements may be visually depicted or illustrated in a minimized manner. As a non-limiting example, a smaller font size, a smaller graphic size, or a less prominent or obvious color than that used for the real-time vital sign measurement 602 may be used to depict or illustrate those other real-time vital sign measurements in the GUI 502 modulated for the patient. Thus, those other real-time vital sign measurements may be depicted or illustrated without significantly diverting attention from the real-time vital sign measurement 602.

[0101] In various aspects, the GUI 502 modulated for a patient may be visually presented according to or otherwise in compliance with the recommended visual style indicating the identifier 404. As a non-limiting example, assume that the recommended visual style indicating the identifier 404 specifies a minimum or maximum font size predicted to be beneficial to the viewing comfort or tolerance of a medical patient. In such cases, the GUI 502 modulated for the patient may depict or illustrate real-time vital sign measurements 602 that conform to such minimum or maximum font size. As another non-limiting example, assume that the recommended visual style indicating the identifier 404 specifies color restrictions predicted to be beneficial to the viewing comfort or tolerance of a medical patient. In such cases, the GUI 502 modulated for the patient may depict or illustrate real-time vital sign measurements 602 that conform to such color restrictions. As yet another non-limiting example, assume that the recommended visual style indicating the identifier 404 specifies a minimum or maximum screen brightness level predicted to be beneficial to the viewing comfort or tolerance of a medical patient. In such cases, the GUI 502 modulated for the patient may depict or illustrate real-time vital sign measurements 602 that conform to such minimum or maximum screen brightness level. As still another non-limiting example, assume that the recommended visual style indicating the identifier 404 specifies geometric pattern restrictions predicted to be beneficial to the viewing comfort or tolerance of a medical patient. In such cases, the GUI 502 modulated for the patient may depict or illustrate real-time vital sign measurements 602 that conform to such geometric pattern restrictions. In other words, the GUI 502 modulated for the patient may be considered to be visually presented in any aesthetic manner predicted or inferred by the deep learning neural network 302 to be uniquely comfortable or tolerable for a medical patient. Similarly, for at least this reason, the term "modulated for the patient" may be considered appropriate.

[0102] In various aspects, the GUI 502 modulated for a patient may include a vital sign warning 604. In various situations, the vital sign warning 604 can be any suitable electronic data (e.g., one or more scalars, one or more vectors, one or more matrices, one or more tensors, or any suitable combination thereof) that indicates, communicates, or otherwise represents that the real-time vital sign measurements 602 exhibit unhealthy behavior or activity. In particular, the display component 118 can electronically compare the real-time vital sign measurements 602 (or at least its most recent data input) with the recommended vital sign thresholds 406 (e.g., on a continuous, periodic, or ad hoc basis). If the real-time vital sign measurements 602 (or at least its most recent data input) fail to meet the recommended vital sign thresholds 406, the display component 118 can cause the GUI 502 modulated for a patient to electronically depict or illustrate the vital sign warning 604. On the other hand, if the real-time vital sign measurements 602 (or at least its most recent data input) meet the recommended vital sign thresholds 406, the display component 118 can instead inhibit causing the GUI 502 modulated for a patient to electronically depict or illustrate the vital sign warning 604. Thus, the GUI 502 modulated for a patient can be electronically alerted when any one vital sign category predicted to be clinically relevant to a medical patient deviates from any numerical boundary predicted to distinguish healthy and unhealthy vital sign activity for the medical patient. Also, for at least this reason, the term "modulated for a patient" can be considered appropriate.

[0103] It should be understood that any other suitable aspects or details associated with the clinical GUI can be implemented in conjunction with the GUI 502 modulated for a patient. As some non-limiting examples, the GUI 502 modulated for a patient can implement: any suitable data encapsulation, analysis, or output techniques (e.g., a diagnostic model can analyze the real-time vital sign measurements 602); any suitable augmented reality or virtual reality techniques (e.g., if scans or endoscopic images of the medical patient are available, they can be utilized to construct two-dimensional or three-dimensional virtual models of the anatomical structure of the medical patient, and such two-dimensional or three-dimensional models can be superimposed on an image or live feed depicting the medical patient); any suitable gamification techniques (e.g., reward points can be defined or earned based on how much user interaction the GUI 502 modulated for a patient receives); any suitable social media or telemedicine techniques (e.g., the real-time vital sign measurements 602 can be streamed to any suitable remote device or electronic social media account); or any suitable preference selection techniques.

[0104] Figure 7A block diagram of an exemplary non - limiting system 700 that illustrates a clinician metadata for facilitating an intelligent clinical user interface in accordance with one or more embodiments described herein. As shown, in some cases, system 700 may include the same components as system 500 and may also include clinician metadata 702.

[0105] In various embodiments, clinician metadata 702 may correspond to or be associated with any suitable clinician (e.g., physician, nurse, medical technician) who is caring for, treating, or otherwise associated with a medical patient. In various aspects, clinician metadata 702 may be one or more scalars, one or more vectors, one or more matrices, one or more tensors, one or more strings, or any suitable combination thereof, which indicate, convey, or otherwise represent any suitable attribute or characteristic of the attending clinician (e.g., age, lifestyle, pathology, education level, preferences). In various cases, access component 114 may electronically receive, retrieve, or access clinician metadata 702 from any suitable source. In various cases, the one or more GUI - related inferences 304 may be based on clinician metadata 702 such that the GUI 502 modulated for a patient may be considered to be modulated also for the attributes of the attending clinician. With respect to Figure 8 describe various non - limiting aspects.

[0106] Figure 8 An exemplary non - limiting block diagram 800 is illustrated that shows how clinician metadata 702 may be taken into account in accordance with one or more embodiments described herein.

[0107] In various aspects, instead of performing the deep - learning neural network 302 on the patient metadata 104 alone, model component 116 may instead electronically perform the deep - learning neural network 302 on both patient metadata 104 and clinician metadata 702. In various cases, such performance may result in the one or more GUI - related inferences 304. More specifically, model component 116 may concatenate patient metadata 104 and clinician metadata 702 and may feed the concatenation into the input layer of the deep - learning neural network 302. In various cases, the concatenation may complete a forward pass through the one or more hidden layers of the deep - learning neural network 302. In various aspects, the output layer of the deep - learning neural network 302 may calculate or compute the one or more GUI - related inferences 304 based on the activation maps provided by the one or more hidden layers.

[0108] In various cases, the relevant vital sign category indication identifier 402 and the recommended vital sign thresholds 406 may be as described above. However, in various cases, when the deep learning neural network 302 is executed on the clinician metadata 702, the recommended visual style indication identifier 404 may be slightly different from that described above. In particular, when the deep learning neural network 302 is executed on the clinician metadata 702, the recommended visual style indication identifier 404 may indicate or specify a visually stylized element that will facilitate, assist, or otherwise improve the viewing comfort, enjoyment, or tolerance of not only the medical patient but also the attending clinician. As some non-limiting examples, the recommended visual style indication identifier 404 may indicate or specify a font size, color scheme, brightness level, contrast level, or geometric pattern (e.g., in addition to or instead of those predicted to be comfortable or attractive to the medical patient) that is predicted by the deep learning neural network 302 to be comfortable or attractive to the attending clinician. Thus, in such cases, the GUI 502 modulated for the patient may be considered to be modulated not only for the medical patient but also for the attending clinician.

[0109] In order for the one or more GUI-related inferences 304 to be accurate, correct, or reliable, the deep learning neural network 302 may first be trained, as described with respect to Figures 9 to 11 that described above.

[0110] Figure 9 FIG. 9 illustrates a block diagram of an exemplary non-limiting system 900 including a training component and a training data set that may facilitate an intelligent clinical user interface in accordance with one or more embodiments described herein. As shown, in some cases, system 900 may include the same components as system 700 and may further include a training component 902 and a training data set 904.

[0111] In various aspects, the access component 114 may electronically receive, retrieve, or otherwise access the training data set 904 from any suitable source, and the training component 902 may electronically train the deep learning neural network 302 on the training data set 904. Various non-limiting aspects are described with respect to Figures 10 to 11 that described above.

[0112] Figure 10 FIG. 10 illustrates an exemplary non-limiting block diagram 1000 of a training data set 904 in accordance with one or more embodiments described herein.

[0113] In various aspects, the training data set 904 can include a set of training inputs 1002. In various cases, the set of training inputs 1002 can include q inputs (where q is any suitable positive integer): training input 1002(1) to training input 1002(q). In various cases, each training input in the set of training inputs 1002 can train patient metadata having the same format, size, or dimension as the patient metadata 104. In various other cases, each training input in the set of training inputs 1002 can be a concatenation between training patient metadata (e.g., having the same format, size, or dimension as the patient metadata 104) and training clinician metadata (e.g., having the same format, size, or dimension as the clinician metadata 702).

[0114] In various aspects, the training data set 904 can include a set of ground truth annotations 1004 that can respectively correspond to the set of training inputs 1002. Thus, since the set of training inputs 1002 can have q inputs, the set of ground truth annotations 1004 can have q annotations: ground truth annotation 1004(1) to ground truth annotation 1004(q). In various cases, each ground truth annotation in the set of ground truth annotations 1004 can be one or more correct or accurate GUI-related inferences (e.g., having the same format, size, or dimension as the one or more GUI-related inferences 304) that are known or believed to correspond to the corresponding one of the training inputs in the set of training inputs 1002. As a non-limiting example, ground truth annotation 1004(1) can correspond to training input 1002(1). Thus, ground truth annotation 1004(1) can be a correct or accurate GUI-related inference (e.g., a correct or accurate relevant vital sign category indication; a correct or accurate recommended visual style indication; a correct or accurate recommended vital sign threshold) that is known or believed to correspond to training input 1002(1). As another non-limiting example, ground truth annotation 1004(q) can correspond to training input 1002(q). Thus, ground truth annotation 1004(q) can be a correct or accurate GUI-related inference that is known or believed to correspond to training input 1002(q).

[0115] Figure 11 Illustrates an exemplary non-limiting block diagram 1100 showing how a deep learning neural network 302 can be trained according to one or more embodiments described herein.

[0116] In various aspects, before starting training, the trainable internal parameters (e.g., convolutional kernels, weight matrices, bias values) of the deep learning neural network 302 can be initialized in any suitable manner (e.g., via random initialization).

[0117] In various aspects, the training component 902 can select a training input 1102 and a ground truth annotation 1104 corresponding to the training input 1102 from a training data set 904. In various cases, the training component 902 can execute a deep learning neural network 302 on the training input 1102, such that the deep learning neural network 302 produces an output 1106. More specifically, in some cases, the training component 902 can feed the training input 1102 into an input layer of the deep learning neural network 302, the training input 1102 can complete a forward pass through the one or more hidden layers of the deep learning neural network 302, and an output layer of the deep learning neural network 302 can calculate the output 1106 based on an activation map or a feature map provided by the one or more hidden layers of the deep learning neural network 302.

[0118] Note that the format, size, or dimension of the output 1106 can be determined by the number, arrangement, size, or other characteristics of the neurons, convolutional kernels, or other internal parameters of the output layer (or any other layer) of the deep learning neural network 302. Thus, the output 1106 can be forced to have any desired format, size, or dimension by adding, removing, or otherwise adjusting the characteristics of the output layer (or any other layer) of the deep learning neural network 302. Accordingly, the output 1106 can be considered as a predicted GUI-related inference (e.g., a predicted relevant vital sign category indication identifier; a predicted recommended visual style indication identifier; a predicted recommended vital sign threshold) that the deep learning neural network 302 believes should correspond to the training input 1102. In contrast, the ground truth annotation 1104 can be considered as a correct or accurate GUI-related inference (e.g., a correct or accurate relevant vital sign category indication identifier; a correct or accurate recommended visual style indication identifier; a correct or accurate recommended vital sign threshold) that is known or considered to correspond to the training input 1102. Note that if the deep learning neural network 302 has not been trained at all or has been trained very little so far, the output 1106 can be highly inaccurate (e.g., can be very different from the ground truth annotation 1104).

[0119] In various aspects, the training component 902 can calculate any suitable error or loss (e.g., mean absolute error, mean squared error, cross-entropy error) between the output 1106 and the ground truth annotation 1104. In various cases, the training component 902 can incrementally update the trainable internal parameters of the deep learning neural network 302 via backpropagation (e.g., stochastic gradient descent) driven by the calculated error or loss.

[0120] In various cases, such execution and update processes can be repeated for any suitable number of training inputs (e.g., for each training input in training dataset 904). This can ultimately cause the trainable internal parameters of deep learning neural network 302 to become iteratively optimized based on the input patient metadata (which may or may not be accompanied by input clinician metadata) to accurately generate GUI-related inferences (e.g., relevant vital sign category indication identifiers; recommended visual style indication identifiers; recommended vital sign thresholds). In various aspects, training component 902 can implement any suitable training batch size, any suitable error, loss, or objective function, or any suitable training termination criterion.

[0121] Although the above description mainly describes deep learning neural network 302 as being trained in a supervised manner, this is just a non-limiting example for ease of illustration and explanation. In various cases, training component 902 can implement any other suitable training paradigm (e.g., unsupervised training, reinforcement learning) to train deep learning neural network 302.

[0122] Figure 12 A flowchart of an exemplary non-limiting computer-implemented method 1200 that can facilitate an intelligent clinical user interface in accordance with one or more embodiments described herein is illustrated. In various cases, intelligent clinical user interface system 102 can facilitate computer-implemented method 1200.

[0123] In various embodiments, action 1202 can include: accessing, via a device (e.g., via 114) operatively coupled to a processor (e.g., 110), attribute data corresponding to a medical patient (e.g., 104) and real-time measurements (e.g., 108) of the plurality of vital sign categories of the medical patient (e.g., 106).

[0124] In various aspects, action 1204 can include: identifying, via a device (e.g., via 116) and via execution of a machine learning model (e.g., 302) on the attribute data, which vital sign category among the plurality of vital sign categories is clinically relevant to the medical patient, thereby generating the identified vital sign category (e.g., indicated by 402).

[0125] In various cases, action 1206 can include: visually presenting, via a device (e.g., via 118) and on a graphical user interface (e.g., 502), real-time measurements (e.g., 602) of the identified vital sign category.

[0126] Although in Figure 12Although not explicitly shown in [the figure], the computer-implemented method 1200 may include: determining, by the device (e.g., via 116) and via execution of a machine learning model, a visual style (e.g., indicated by 404) that is predicted to assist a medical patient in viewing a graphical user interface or assist an attending clinician in viewing a graphical user interface, wherein real-time measurements of the identified vital sign categories may be visually presented according to the visual style.

[0127] Although in Figure 12 [the figure] not explicitly shown, the visual style may include: a font size to use or avoid; a color to use or avoid; a geometric pattern to use or avoid; or a screen brightness or contrast to use or avoid.

[0128] Although in Figure 12 [the figure] not explicitly shown, the computer-implemented method 1200 may include: generating, by the device (e.g., via 118), an electronic warning (e.g., 604) in response to real-time measurements of the identified vital sign categories failing to meet a threshold (e.g., indicated by 406). In various cases, the computer-implemented method 1200 may include: calculating, by the device (e.g., via 116) and via execution of a machine learning model, the threshold.

[0129] Although in Figure 12 [the figure] not explicitly shown, the graphical user interface may be associated with a mobile computing device or with a hospital console.

[0130] Although in Figure 12 [the figure] not explicitly shown, the graphical user interface may incorporate an augmented reality overlay (e.g., a two-dimensional or three-dimensional reconstruction model of a medical patient's organ) superimposed on an image of the medical patient (e.g., the image may be captured by the medical patient's smart phone or by a hospital camera facing the medical patient).

[0131] Although various embodiments are described herein with respect to a GUI, this is for non - limiting examples for ease of explanation and illustration. In various other embodiments, the teachings described herein can be applied to or extrapolated to any suitable electronic user interface (e.g., not limited to graphical user interfaces only). As a non - limiting example, the various embodiments described herein can be applied to or implemented in an audio user interface. In such cases, the GUI 502 modulated for the patient can instead be considered as an audio user interface modulated for the patient, the real - time vital sign measurement results 602 can be communicated in an audible manner rather than a visual manner, and the recommended visual style indication identifier 404 can instead be considered as a recommended audible style indication identifier (e.g., audible - stylized elements such as volume, pitch, or tone color that are predicted to increase or benefit the listening comfort or tolerance of a medical patient can be specified). As another non - limiting example, the various embodiments described herein can be applied to or implemented in a haptic user interface (e.g., an electronic braille interface). In such cases, the GUI 502 modulated for the patient can instead be considered as a haptic user interface modulated for the patient, the real - time vital sign measurement results 602 can be communicated in a haptic or tactile manner rather than a visual manner, and the recommended visual style indication identifier 404 can instead be considered as a recommended tactile style indication identifier (e.g., tactile - stylized elements such as the sensitivity of haptic feedback that are predicted to increase or benefit the tactile comfort or tolerance of a medical patient can be specified). In any case, the various embodiments described herein can be considered as facilitating the automatic and intelligent customization or modulation of a clinical user interface based on patient characteristics.

[0132] In fact, various embodiments can include a computer program product for facilitating an intelligent clinical user interface. In various aspects, the computer program product can include a non - transitory computer - readable memory (e.g., 112) having program instructions embodied therewith. In various cases, the program instructions can be executable by a processor (e.g., 110) to cause the processor to: access attribute data corresponding to a medical patient (e.g., 104) and real - time measurement results (e.g., 108) of multiple vital sign categories (e.g., 106) of the medical patient; identify, via execution of a machine - learning model (e.g., 302) on the attribute data, which one of the multiple vital sign categories is clinically relevant to the medical patient, thereby producing the identified vital sign category (e.g., indicated by 402); and communicate, via an electronic user interface (e.g., 502 as a non - limiting example), the real - time measurement results of the identified vital sign category (e.g., 602).

[0133] In some aspects, the electronic user interface can be a graphical user interface (e.g., 502), and the program instructions can also be executable to cause the processor: to determine, via execution of a machine learning model, a visual style (e.g., 404) predicted to assist a medical patient in interacting with the graphical user interface, and to present real-time measurements of the identified vital sign categories according to the visual style.

[0134] In other aspects, the electronic user interface can be an auditory user interface (e.g., an auditory or audible or hearing version of 502), and the program instructions can also be executable to cause the processor: to determine, via execution of a machine learning model, an auditory style (e.g., an auditory or audible or hearing version of 404) predicted to assist a medical patient in interacting with the auditory user interface, and to present real-time measurements of the identified vital sign categories according to the auditory style.

[0135] In yet other aspects, the electronic user interface can be a haptic user interface (e.g., a haptic version of 502), and the program instructions can also be executable to cause the processor: to determine, via execution of a machine learning model, a haptic style (e.g., a haptic version of 404) predicted to assist a medical patient in interacting with the haptic user interface, and to present real-time measurements of the identified vital sign categories according to the haptic style.

[0136] In various instances, the machine learning algorithms or models can be implemented in any suitable manner to facilitate any suitable aspect described herein. To facilitate some of the machine learning aspects of the above-described machine learning aspects of the various embodiments, consider the following discussion of artificial intelligence (AI). The various embodiments described herein can employ artificial intelligence to facilitate the automation of one or more features or functionalities. These components can employ various AI-based schemes to perform the various embodiments / examples disclosed herein. To provide or assist with the numerous determinations (e.g., determine, detect, infer, calculate, predict, prognose, estimate, derive, forecast, detect, estimate) described herein, the components described herein can examine all or a subset of the data to which they are granted access and can provide reasoning about or determine the state of a system or environment from a set of observations captured via events or data. For example, a determination can be used to identify a particular context or action, or a probability distribution of a state can be generated. These determinations can be probabilistic; that is, the calculation of a probability distribution of a state of interest is based on the consideration of data and events. A determination can also refer to techniques for composing higher-level events from a set of events or data.

[0137] Such determination can result in constructing new events or actions from a set of observed events or stored event data, whether or not the events are temporally close, and whether the events and data are from one or more event and data sources. The components disclosed herein can employ various classification (explicitly trained (e.g., via training data) and implicitly trained (e.g., via observed behavior, preferences, historical information, receiving extrinsic information, etc.)) schemes or systems (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, etc.) in conjunction with performing automatic or determined actions related to the claimed subject matter. Thus, classification schemes or systems can be used to automatically learn and perform a variety of functions, actions, or determinations.

[0138] A classifier can map an input attribute vector z = (z1, z2, z3, z4, z n ) to a confidence that the input belongs to a certain class, e.g., according to f(z) = confidence(class). Such classification can employ probability or statistics-based analysis (e.g., analyzing utility and cost considerations) to determine actions to be automatically performed. A support vector machine (SVM) can be an example of a classifier that can be used. An SVM operates by finding a hypersurface in the space of possible inputs, where the hypersurface attempts to separate triggering criteria from non-triggering events. Intuitively, this makes the classification correct for testing data that is close to but different from the training data. Other directed and undirected model classification methods include, for example, naive Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, or any of the probabilistic classification models that can provide different independent models. Classification as used herein also includes statistical regression for developing priority models.

[0139] To provide additional context for the various embodiments described herein, Figure 13 and the following discussion is intended to provide a brief general description of a suitable computing environment 1300 in which the various embodiments described herein can be implemented. Although the embodiments have been described above in the general context of computer-executable instructions that may run on one or more computers, those skilled in the art will recognize that these embodiments can also be implemented in conjunction with other program modules or as a combination of hardware and software.

[0140] Typically, a program module includes routines, programs, components, data structures, etc. that perform a particular task or implement a particular abstract data type. Additionally, those skilled in the art will understand that the methods of the present invention may be practiced with other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, and personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, etc., each of which is operatively coupled to one or more associated devices.

[0141] The illustrated embodiments of the present implementation may also be practiced in a distributed computing environment where specific tasks are performed by remote processing devices linked through a communication network. In a distributed computing environment, program modules may be located in local and remote memory storage devices.

[0142] A computing device generally includes various media, which may include computer-readable storage media, machine-readable storage media, or communication media, where the use of these two terms is different from each other herein, as described below. Computer-readable storage media or machine-readable storage media can be any available storage media accessible by a computer, and include volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, computer-readable storage media or machine-readable storage media can be implemented in conjunction with any method or technology for storing information such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0143] Computer-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage devices, magnetic tape cartridges, tapes, magnetic disk storage devices or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible or non-transitory media that can be used to store the required information. In this regard, the terms "tangible" or "non-transitory" as applied to storage devices, memory, or computer-readable media herein should be understood to exclude only propagating transient signals themselves as modifiers, and do not disclaim the rights to all standard storage devices, memory, or computer-readable media other than propagating transient signals themselves.

[0144] Computer-readable storage media can be accessed by one or more local or remote computing devices, for example, via access requests, queries, or other data retrieval protocols, to perform various operations with respect to the information stored by the media.

[0145] A communication medium typically includes computer-readable instructions, data structures, program modules, or other structured or unstructured data in a data signal, which can be, for example, a modulated data signal such as a carrier wave or other transmission mechanism, and includes any information delivery or transmission medium. The term "modulated data signal" or "signal" refers to a signal that sets or changes one or more of its characteristics to encode information in one or more signals. By way of example and not limitation, communication media include wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic, RF, infrared, and other wireless media).

[0146] Referring again to Figure 13 , an exemplary environment 1300 for implementing various embodiments of the aspects described herein includes a computer 1302, which includes a processing unit 1304, a system memory 1306, and a system bus 1308. The system bus 1308 couples system components (including but not limited to the system memory 1306) to the processing unit 1304. The processing unit 1304 can be any of a variety of commercially available processors. Dual microprocessors and other multi-processor architectures can also be used as the processing unit 1304.

[0147] The system bus 1308 can be any of several types of bus structures that can further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory 1306 includes a ROM 1310 and a RAM 1312. The basic input / output system (BIOS) can be stored in non-volatile memory (such as ROM, erasable programmable read-only memory (EPROM), EEPROM), where the BIOS contains basic routines that assist in transferring information between elements within the computer 1302, such as during startup. The RAM 1312 can also include high-speed RAM, such as static RAM for caching data.

[0148] The computer 1302 also includes an internal hard disk drive (HDD) 1314 (e.g., EIDE, SATA), one or more external storage devices 1316 (e.g., a magnetic floppy disk drive (FDD) 1316, a memory stick or flash drive reader, a memory card reader, etc.), and a drive 1320, such as a solid state drive, an optical disk drive, which can read from or write to a disk 1322 (such as a CD-ROM disk, a DVD, a BD, etc.). Alternatively, in the case of a solid state drive, the disk 1322 will not be included unless separately provided. Although the internal HDD 1314 is illustrated as being located within the computer 1302, the internal HDD 1314 can also be configured for use external to a suitable infrastructure (not shown). Additionally, although not shown in the environment 1300, a solid state drive (SSD) can be used as a supplement or alternative to the HDD 1314. The HDD 1314, the external storage device 1316, and the drive 1320 can be connected to the system bus 1308 through an HDD interface 1324, an external storage interface 1326, and a drive interface 1328, respectively. The interface 1324 for the external drive implementation can include at least one or both of the Universal Serial Bus (USB) and the Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies. Other external drive connection technologies are within the contemplation of the embodiments described herein.

[0149] The drive and its associated computer-readable storage medium provide non-volatile storage of data, data structures, computer-executable instructions, etc. For the computer 1302, the drive and the storage medium accommodate the storage of any data in a suitable digital format. Although the above description of the computer-readable storage medium relates to the corresponding type of storage device, those skilled in the art should understand that other types of storage media that are computer-readable (whether currently existing or to be developed in the future) can also be used in the exemplary operating environment, and furthermore, any such storage medium can contain computer-executable instructions for performing the methods described herein.

[0150] Multiple program modules can be stored in the drive and the RAM 1312, including an operating system 1330, one or more application programs 1332, other program modules 1334, and program data 1336. All or part of the operating system, application programs, modules, or data can also be cached in the RAM 1312. The systems and methods described herein can be implemented using various commercially available operating systems or combinations of operating systems.

[0151] The computer 1302 can optionally include emulation technology. For example, a hypervisor (not shown) or other intermediary can emulate the hardware environment for the operating system 1330, and the emulated hardware can optionally be different from Figure 13The hardware exemplified herein. In such embodiments, the operating system 1330 may include one of a plurality of virtual machines (VMs) hosted at the computer 1302. Additionally, the operating system 1330 may provide a runtime environment for the application 1332, such as the Java runtime environment or the.NET framework. The runtime environment is a consistent execution environment that allows the application 1332 to run on any operating system that includes the runtime environment. Similarly, the operating system 1330 may support containers, and the application 1332 may be in the form of containers that are lightweight, independent, executable software packages that include, for example, the code of the application, the runtime, system tools, system libraries, and settings.

[0152] Additionally, the computer 1302 may be enabled by using a security module such as a Trusted Platform Module (TPM). For example, in the case of a TPM, the boot component is hashed in the next boot component and waits for the result to match a security value before loading the next boot component. This process may occur at any layer in the code execution stack of the computer 1302, for example, applied at the application execution level or the operating system (OS) kernel level, thus achieving security at any code execution level.

[0153] The user may input commands and information into the computer 1302 through one or more wired / wireless input devices (e.g., keyboard 1338, touch screen 1340, and pointing devices such as mouse 1342). Other input devices (not shown) may include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control or other remote controls, a joystick, a virtual reality controller or virtual reality headset, a gamepad, a stylus, an image input device (e.g., a camera), a gesture sensor input device, a visual motion sensor input device, an emotion or face detection device, a biometric input device (e.g., a fingerprint or iris scanner), etc. These input devices and other input devices are typically connected to the processing unit 1304 through an input device interface 1344, which may be coupled to the system bus 1308, but these input devices and other input devices may be connected through other interfaces (such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, interface, etc.).

[0154] The monitor 1346 or other type of display device may also be connected to the system bus 1308 via an interface such as a video adapter 1348. In addition to the monitor 1346, the computer typically also includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0155] Computer 1302 can operate in a networked environment using a logical connection to one or more remote computers, such as remote computer 1350, via wired or wireless communication. Remote computer 1350 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment appliance, peer device, or other common network node, and typically includes many or all of the elements described relative to computer 1302, but for simplicity only memory / storage device 1352 is shown. The depicted logical connections include a wired / wireless connection to a local area network (LAN) 1354 or a larger network, such as a wide area network (WAN) 1356. Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to a global communications network, such as the Internet.

[0156] When used in a LAN networking environment, computer 1302 can be connected to local network 1354 through a wired or wireless communication network interface or adapter 1358. Adapter 1358 can facilitate wired or wireless communication with LAN 1354, which may also include a wireless access point (AP) disposed thereon for communicating with adapter 1358 in wireless mode.

[0157] When used in a WAN networking environment, computer 1302 can include a modem 1360, or can be connected to a communication server on WAN 1356 via other components for establishing communication through WAN 1356, such as through the Internet. Modem 1360, which can be an internal or external device and a wired or wireless device, can be connected to system bus 1308 via input device interface 1344. In a networked environment, program modules depicted relative to computer 1302 or portions thereof can be stored in remote memory / storage device 1352. It should be understood that the network connections shown are examples, and other components can be used to establish a communication link between computers.

[0158] When used in a LAN or WAN networking environment, in addition to or instead of the external storage device 1316 as described above, the computer 1302 can access a cloud storage system or other network-based storage systems, such as but not limited to network virtual machines that provide one or more aspects of information storage or processing. Generally speaking, the connection between the computer 1302 and the cloud storage system can be established, for example, by an adapter 1358 or a modem 1360 via the LAN 1354 or the WAN 1356 respectively. When connecting the computer 1302 to an associated cloud storage system, the external storage interface 1326 can manage the storage provided by the cloud storage system with the help of the adapter 1358 or the modem 1360, just like other types of external storage devices. For example, the external storage interface 1326 can be configured to provide access to cloud storage sources as if those sources were physically connected to the computer 1302.

[0159] The computer 1302 may be capable of operating to communicate with any wireless device or entity operatively set up in a wireless communication manner, such as a printer, a scanner, a desktop computer or a portable computer, a portable data assistant, a communication satellite, any equipment or location associated with being able to wirelessly detect tags (e.g., a self-service machine, a newsstand, a store shelf, etc.) and a telephone. This may include Wi-Fi (Wireless Fidelity) and wireless technologies. Thus, the communication can be of a predefined structure like a conventional network, or just an ad-hoc communication between at least two devices.

[0160] Figure 14 is a schematic block diagram of a sample computing environment 1400 with which the disclosed subject matter may interact. The sample computing environment 1400 includes one or more clients 1410. The clients 1410 can be hardware or software (e.g., threads, processes, computing devices). The sample computing environment 1400 also includes one or more servers 1430. The servers 1430 can also be hardware or software (e.g., threads, processes, computing devices). For example, the server 1430 can host threads to perform transformations by adopting one or more embodiments as described herein. A possible communication between the clients 1410 and the servers 1430 can be in the form of data packets adapted to be transmitted between two or more computer processes. The sample computing environment 1400 includes a communication framework 1450 that can be used to facilitate the communication between the clients 1410 and the servers 1430. The clients 1410 are operatively connected to one or more client data repositories 1420, which can be used to store information local to the clients 1410. Similarly, the servers 1430 are operatively connected to one or more server data repositories 1440, which can be used to store information local to the servers 1430.

[0161] The various embodiments can be a system, a method, an apparatus, or a computer program product at any possible technical detail level of integration. The computer program product can include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to implement aspects of the various embodiments. The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium can be, by way of example and not limitation, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium can also include the following: a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable) or an electrical signal transmitted through a wire.

[0162] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing / processing device. The computer-readable program instructions for carrying out operations of various implementations can be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can establish a connection with an external computer (e.g., through the Internet using an Internet service provider). In some implementations, an electronic circuit, including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), can execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit for various aspects.

[0163] Aspects described herein are illustrated by flowcharts or block diagrams of methods, apparatus (systems), and computer program products according to various embodiments. It should be understood that each block of the flowchart illustrations or block diagrams, and combinations of blocks in the flowchart illustrations or block diagrams, can be implemented by computer-readable program instructions. These computer-readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowchart or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the functions / acts specified in one or more blocks of the flowchart or block diagram. The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowchart or block diagram.

[0164] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowchart illustrations or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagram illustrations or flowchart illustrations, and combinations of blocks in the block diagram illustrations or flowchart illustrations, can be implemented by a system based on dedicated hardware that performs the specified functions or acts or a combination of dedicated hardware and computer instructions.

[0165] Although the subject matter has been described above in the general context of computer-executable instructions of a computer program product that runs on one or more computers, those skilled in the art will recognize that the present disclosure may also be implemented in whole or in part in conjunction with other program modules. In general, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In addition, those skilled in the art will appreciate that various aspects may be practiced with other computer system configurations, including single-processor or multi-processor computer systems, minicomputing devices, mainframe computers, and the like, as well as computer, hand-held computing devices (e.g., PDAs, cellular phones), microprocessor-based or programmable consumer or industrial electronic products, and the like. The illustrated aspects may also be practiced in distributed computing environments where tasks are performed by remote processing devices linked through a communications network. However, some (if not all) aspects of the present disclosure may be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in local and remote memory storage devices.

[0166] As used in this application, the terms "component", "system", "platform", "interface", etc. may refer to or may include a computer-related entity or an entity related to an operating machine with one or more specific functionalities. Entities disclosed herein may be hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to, a program running on a processor, a processor, an object, an executable, an execution thread, a program, or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process or execution thread, and a component may be located on one computer or distributed between two or more computers. As another example, a corresponding component may execute according to various computer-readable media having various data structures stored thereon. Components may communicate via local or remote processes, such as in accordance with signals having one or more data packets (e.g., data from one component that interacts with another component in a local system, a distributed system, or a network such as the Internet with other systems). As another example, a component may be a device having specific functionality provided by mechanical parts operated by an electrical or electronic circuit, where the electrical or electronic circuit is operated by software or firmware applications executed by a processor. In such cases, the processor may be internal or external to the device and may execute at least a portion of the software or firmware application. As yet another example, a component may be a device that provides specific functionality through electronic components rather than mechanical parts, where the electronic components may include a processor or other constructs for executing software or firmware that at least partially imparts functionality to the electronic components. In one aspect, a component may, for example, emulate an electronic component via a virtual machine within a cloud computing system.

[0167] In addition, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or clear from the context, "X employs A or B" is intended to mean any natural inclusive permutation. That is, if X employs A; X employs B; or X employs both A and B, then in any of the foregoing cases, "X employs A or B" is satisfied. As used herein, the term "and / or" is intended to have the same meaning as "or". In addition, unless otherwise specified or clear from the context as being for the singular form, the articles "a" and "an" used in this specification and the drawings generally should be understood to mean "one or more". As used herein, the terms "example" or "exemplary" are used to mean serving as an example, instance, or illustration. To avoid doubt, the subject matter disclosed herein is not limited by such examples. Additionally, any aspect or design described herein as "example" or "exemplary" need not be understood as more preferred or advantageous than other aspects or designs, nor does it mean excluding equivalent exemplary structures and techniques known to those of ordinary skill in the art.

[0168] The disclosure herein describes non-limiting examples. For ease of description or explanation, when discussing various examples, each part of the disclosure herein uses the terms "each", "every", or "all". Such usage of the terms "each", "every", or "all" is non-limiting. In other words, when the disclosure herein provides a description of "each", "every", or "all" of some specific objects or components applied to some specific objects or components, it should be understood that this is a non-limiting example, and it should also be understood that in various examples, there may be cases where such description applies to less than "each", "every", or "all" of the specific objects or components.

[0169] As used in this specification, the term "processor" can generally refer to any computing processing unit or device, including but not limited to a single-core processor; a single-processor with software multithreading execution capabilities; a multi-core processor; a multi-core processor with software multithreading execution capabilities; a multi-core processor with hardware multithreading technology; a parallel platform; and a parallel platform with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Further, a processor can utilize nanoscale architectures (such as but not limited to molecule- and quantum-dot-based transistors, switches, and gates) to optimize space usage or enhance the performance of user equipment. A processor can also be implemented as a combination of computing processing units. In the present disclosure, terms such as "repository", "storage device", "data repository", "data storage device", "database", and substantially any other information storage component related to the operation and functionality of a component are used to refer to "memory components", entities embodied in "memory", or components that include memory. It should be understood that the memory or memory components described herein can be volatile memory or non-volatile memory, or can include both volatile memory and non-volatile memory. By way of illustration and not limitation, non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or non-volatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM)). For example, volatile memory can include RAM that can serve as an external cache memory. By way of illustration and not limitation, RAM can be provided in various forms, such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). Additionally, the disclosed memory components of the systems or computer-implemented methods herein are intended to include but not be limited to including these and any other suitable types of memory.

[0170] The foregoing description includes only examples of systems and computer-implemented methods. Of course, it is not possible to describe every conceivable combination of components or computer-implemented methods for the purposes of describing the present disclosure, but many other combinations and permutations of the present disclosure are possible. In addition, to the extent that the terms "including," "having," "possessing," and the like are used in the detailed description, the claims, the appendices, and the drawings, such terms are intended to be inclusive in a manner similar to the term "comprising," as "comprising" is interpreted when used as a transitional word in the claims.

[0171] Descriptions of various embodiments have been given for purposes of illustration, but these descriptions are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent without departing from the scope and spirit of the described embodiments. The terms used herein are chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable other ordinary skilled artisans in the art to understand the embodiments disclosed herein.

Claims

1. A system, comprising: A processor (e.g., 110) that executes computer-executable components stored in a non-transitory computer-readable memory (e.g., 112), wherein the computer-executable components include: an access component (e.g., 114) that accesses attribute data corresponding to a medical patient (e.g., 104) and accesses real-time measurements (e.g., 108) of a plurality of vital sign categories (e.g., 106) of the medical patient; a model component (e.g., 116) that identifies which of the plurality of vital sign categories is clinically relevant to the medical patient via execution of a machine learning model (e.g., 302) on the attribute data, thereby generating an identified vital sign category (e.g., 402); and A display component (eg, 118) that visually presents real-time measurements (eg, 602) of the identified vital sign categories on a graphical user interface (eg, 502).

2. A system according to claim 1, wherein the model component determines, via the execution of the machine learning model, a visual style (e.g., 404) that is predicted to assist the medical patient in viewing the graphical user interface or assist the attending clinician in viewing the graphical user interface, and wherein the display component visually presents the real-time measurement results of the identified vital sign category in accordance with the visual style.

3. The system of claim 2, wherein the visual style comprises: font sizes to use or avoid; colors to use or avoid; geometric patterns to use or avoid; or Screen brightness or contrast to use or avoid.

4. The system of claim 1, wherein the display component generates an electronic alert (e.g., 604) in response to the real-time measurement of the identified vital sign category failing to meet a threshold (e.g., 406).

5. The system of claim 4, wherein the model component calculates the threshold via the execution of the machine learning model. The system of claim 1 , wherein the graphical user interface is associated with a mobile computing device.

7. The system of claim 1, wherein the graphical user interface is associated with a hospital console.

8. The system of claim 1, wherein the graphical user interface comprises an augmented reality overlay superimposed on an image of the medical patient.

9. A computer-implemented method, the computer-implemented method comprising: accessing, via a device operatively coupled to the processor (e.g., via 114), attribute data corresponding to a medical patient (e.g., 104) and real-time measurements (e.g., 108) of a plurality of vital sign categories (e.g., 106) of the medical patient; identifying, by the device (e.g., via 116) and via execution of a machine learning model (e.g., 302) on the attribute data, which of the plurality of vital sign categories is clinically relevant to the medical patient, thereby producing an identified vital sign category (e.g., 402); as well as Real-time measurements (eg, 602) of the identified vital sign categories are visually presented by the device (eg, via 118) and on a graphical user interface (eg, 502).

10. The computer-implemented method of claim 9, further comprising: Determining, by the device (e.g., via 116) and via the execution of the machine learning model, a visual style (e.g., 404) predicted to assist the medical patient in viewing the graphical user interface or assist the attending clinician in viewing the graphical user interface, wherein the real-time measurements of the identified vital sign category are visually presented according to the visual style.

11. The computer-implemented method of claim 10, wherein the visual style comprises: font sizes to use or avoid; colors to use or avoid; geometric patterns to use or avoid; Or what screen brightness or contrast to use or avoid.

12. The computer-implemented method of claim 9, further comprising: An electronic alert (eg, 604) is generated by the device (eg, via 118) in response to the real-time measurement of the identified vital sign category failing to meet a threshold (eg, 406).

13. The computer-implemented method of claim 12, further comprising: The threshold is calculated by the device and via the execution of the machine learning model.

14. The computer-implemented method of claim 9, wherein the graphical user interface is associated with a mobile computing device.

15. The computer-implemented method of claim 9, wherein the graphical user interface is associated with a hospital console.

Images