Decision support for a patient undergoing treatment provided by a medical device at a treatment site

Abstract

The present disclosure relates to a system, method and non-transitory computer-readable media designed for decision support in treatment using a medical device at a treatment site. A medical device collects (S702) and transmits (S704) healthcare data to a first server of one or more servers. This server runs (S706) an application providing a first graphical user interface (GUI) based on the healthcare data. The system includes a portable device equipped with a sensor to retrieve (S708) identification data of the medical device and transmit (S710) derived data to the servers. The servers compare this data with stored data to determine (S712) that the healthcare data can be displayed on the portable device. The servers generate (S714) a URL to the server application, which is then sent to the portable device. The portable device uses this link to connect (S716) to the server application and display the first GUI.

Description

[0001] DECISION SUPPORT FOR A PATIENT UNDERGOING TREATMENT PROVIDED BY A MEDICAL DEVICE AT A TREATMENT SITE

[0002] Technical Field

[0003] The present disclosure relates to generally to decision support in a healthcare setting. More specifically, it relates to a system and method for decision support for a patient undergoing a treatment provided by a medical device at a treatment site.

[0004] Background

[0005] In the field of healthcare, providing timely and accurate decision support for a patient undergoing a treatment provided by a medical device is a critical aspect of patient treatment. This encompasses a range of activities including diagnosis, treatment selection, monitoring of patient status, and adjustment of treatment protocols as needed. However, several challenges hinder the effectiveness of decision support in healthcare settings.

[0006] One of the primary challenges is the availability of medical staff at the point of care. In many healthcare environments, especially those with high patient volumes or in remote or underserved areas, it is often difficult to ensure the constant presence of qualified medical personnel. This limitation can delay decision-making processes, potentially affecting patient outcomes.

[0007] Additionally, the traditional approach to healthcare decision support often involves manual processes, such as the physical transfer of patient notes, medical histories, and treatment information for review by medical staff. These processes are not only time-consuming but are also prone to errors and inefficiencies. In healthcare situations, delays in information transfer and decision-making can have severe consequences for patient care.

[0008] There is thus a need for improvements in this context.

[0009] Summary

[0010] In view of the above, solving or at least reducing one or several of the drawbacks discussed above would be beneficial, as set forth in the attached independent patent claims. According to a first aspect of the present disclosure, there is provided system for decision support for a patient undergoing a treatment provided by a medical device at a treatment site, the system comprising one or more servers.

[0011] The medical device is configured for collecting healthcare data and transmitting the healthcare data to a first server of the one or more servers.

[0012] As used herein, the term healthcare data covers all types of data relevant to healthcare settings, including but not limited to, clinical data (such as breathing frequency, heart rate, blood pressure, and laboratory results such as blood count, among other personal health information), patient-specific information (such as medical history, diagnostics, treatment information) and data generated by medical devices (such as device performance metrics, device configurations, usage statistics, and diagnostic outputs).

[0013] The first server is configured to running a server application configured to provide a first graphical user interface, GUI, comprising first GUI items based on the healthcare data.

[0014] The server application is thus a software program designed to manage, process, and display healthcare data. The server application may for example be configured for aggregating, storing, and organizing healthcare data. The server application may for example be configured for processing incoming healthcare data in real-time. The server application is configured to generate a GUI that displays healthcare data. The GUI comprises GUI items which may include various interface elements such as charts, graphs, alerts, and data tables, and may be designed to provide insights into the health data, e.g., into patient health and / or medical device status.

[0015] The system further comprises a portable device configured for retrieving identification data of the medical device using a sensor of the portable device.

[0016] The portable device is thus equipped with a sensor which is utilized to retrieve identification data from a medical device. This process involves the portable device's sensor scanning or detecting identifiers associated with the medical device. These identifiers could be in various forms, such as barcodes, QR codes, RFID tags, or other types of digital markers embedded in or attached to the medical device.

[0017] The portable device is transmitting first data derived from the identification data to the one or more servers. The first data may be the entire identification data as retrieved, or parts of such identification data, possibly enriched or contextualized. The portable device might filter and extract only the pertinent information from the complete set of identification data. The portable device may enrich the identification data with additional context. This could include adding timestamps to record the exact time of the scan or associating the data with location information to track where the device was scanned, etc. The identification data may be reformatted or structured into a format that is compatible with requirements of the receiving server. The first data may be encrypted.

[0018] The one or more servers is configured for comparing the first data with stored data, the stored data indicating whether the healthcare data is allowed to be visualized on the portable device. Upon the healthcare data is allowed to be visualized on the portable device, a uniform resource locator, URL pointing to the server application is determined and transmitted to the portable device.

[0019] As used herein, the term "URL” refers to a reference to a resource that specifies its location on a computer network and a mechanism for retrieving it. A URL consists of several components, including the protocol (e.g., HTTP, HTTPS), the domain name or IP address of the server, and optionally, a port number, path, and query parameters. The path and parameters can specify a particular resource or action that the server application should respond to. The URL may for example be embodied as a redirect link, API request, content delivery network (CDN) URL or any other suitable implementations of a URL.

[0020] As used herein, the term "redirect link" refers to a specific type of URL or web address that the server generates and sends to the portable device. The primary purpose of this link is to direct or "redirect" the user of the portable device to the server application's interface, typically accessed via a web browser. As used herein, the term "API request" refers to a method for the portable device to make e.g., a HTTP API request to the first server. The server may then respond with HTML content (or other content as described below) provided by the server application, which can be directly rendered within a e.g., a web view in the portable device. This method is particularly useful for fetching dynamic content that needs to be displayed by the portable device.

[0021] The portable device is configured for connecting to the server application using the URL and displaying the first GUI provided by the server application. The described system adeptly integrates portable device functionality, enhancing mobility and accessibility for healthcare professionals in care settings. This integration allows medical staff to retrieve and transmit data seamlessly, facilitating access of healthcare data from anywhere, not just within the confines of a treatment room. Such mobility may be essential in dynamic and urgent care environments, enabling swift response to patient needs. Additionally, the system emphasis on data security and regulatory compliance, employing mechanisms to verify whether the healthcare data collected by the medical device is authorized for display on the portable device. This feature may aid in maintaining patient privacy and adhering to healthcare regulations, ensuring that sensitive health information is protected and accessed only when authorized. Additionally, the process of scanning a medical device to obtain its identification data may reduce the risk of medical errors, which could arise from the confusion of patient or device information. The combination of these elements, portable device integration and secure, regulated data access, may enhance the efficacy and safety of patient monitoring and treatment.

[0022] Moreover, the portable device displays the GUI being determined on the first server by the server application. This approach may be referred to as server-side rendering (SSR) which is an approach for providing the GUI for mobile applications. In SSR, the server generates HTML, CSS, JavaScript, or other suitable code that represents the user interface (the GUI and the GUI items). This code is then sent to the mobile client, via a URL, which renders it on the screen. SSR may have advantages concerning the handling of sensitive data compared to client-side rendering (CSR). By processing and rendering sensitive data on the server, SSR may reduce the exposure of this data to client-side vulnerabilities and thus reduces the risk of data being intercepted or improperly accessed. Advantageously, this method may allow for a more secure control and monitoring environment, facilitating the adherence to data protection laws like GDPR. Additionally, SSR may facilitate that only necessary information is transmitted to the client, keeping sensitive details like API keys and database credentials secure on the server. Such a controlled approach to data management and transmission may provide a robust framework for maintaining the integrity and confidentiality of sensitive information within web applications. In some examples, the medical device comprises a display for displaying a second GUI comprising second GUI items based on the healthcare data, wherein the server application is configured to provide the first GUI being a virtual replica of the second GUI, such that each GUI item of the second GUI items has a corresponding GUI item among the first GUI items. For example, the server application may be configured according to properties and functionalities of (one or more) software running on the medical device. Such software may be used for visualization and / or analysis of healthcare data when being at the physical location of the medical device, e.g., via a display on the medical device.

[0023] Advantageously, the server application may thus extend the functionality of the software of the medical device to a broader platform. The server application may be configured to provide a first GUI that is essentially a virtual replica, or a “digital twin”, of the second GUI on the medical device. This means that every GUI item displayed on the medical device's screen has a corresponding item in the server application's GUI. In the context of this disclosure, “corresponding” means that for each GUI item in the medical device's interface (the second GUI), there is a functionally equivalent item in the server application's interface (the first GUI). For example, a GUI item on the interface of the medical device that allows healthcare professionals to change a specific setting, such as adjusting the sensitivity of a heart rate monitor may have a corresponding GUI item in the GUI of the server application, i.e., a GUI item that enables the same adjustment to be made remotely. Another example is a graph displaying patient data, like a heart rate trend over time. If such a graph is part of the medical device's GUI, its corresponding item in the server application's GUI may be a graph that displays the same patient data in a similar format. Interacting with this graph on either interface (such as zooming in on a specific time period or selecting data points for more details) may thus provide a consistent experience.

[0024] The server application might also be capable of mimicking the physical interactions associated with the medical device, including elements like tactile push buttons and similar controls.

[0025] In some examples, the medical device comprises a display for displaying a second GUI comprising second GUI items based on the healthcare data, wherein the second GUI items comprises at least one unique GUI item not corresponding to a GUI item among the first GUI items.

[0026] Alternatively to offering a GUI that functions as a digital twin of the interface of the medical device, the server application may also be capable of presenting a GUI in which features from the medical device are not mirrored. This means that the server application may provide a different, or simplified GUI compared to what is shown on the medical device. Advantageously, the server application may offer a flexible GUI, tailored to the needs or capabilities of the user of the portable device.

[0027] In some examples, the portable device is configured to: enable a first application of the portable device to access and utilize data from the sensor; and enable a second application, distinct from the first application, to access and utilize data from the sensor; wherein the retrieving identification data of the medical device using a sensor of the portable device comprises using the second application;

[0028] In this example, the portable device is configured for, upon using the first application to access and utilize data from the sensor, accessing a user manual of a medical device.

[0029] Advantageously, the portable device is configured to support dual applications, each leveraging data from the sensor of the device, such as a camera, NFC reader or RFID reader. The first application may be a standard, built-in camera app, NFC or RFID reader. The second application is distinct and specialized.

[0030] When a user operates the first application, for example, the default camera app on the portable device, the user can utilize the capabilities of the sensor. For instance, by scanning a QR code on the medical device using this camera app, the user may be conveniently provided with an option to access the user manual of the medical device, possibly through a clickable web link shown in the first application. On the other hand, activating the second application triggers a different process: it initiates the determining of a URL to the server application as described herein. This dual-functionality approach, where the same means of identification (like a QR code or an NFC chip) on the medical device serves two distinct purposes, may offer significant advantages. For example, user interaction may be streamlined by allowing a single identifier to facilitate both immediate access to essential information (like user manuals) through the first application and more complex operations (such as linking to the server application) via the second application.

[0031] In some examples, the first application is a pre-installed application integrated into an operating system, OS, of the portable device. Advantageously, any medical staff with a portable device (with the pre-installed application) may access the manual.

[0032] In some examples, the sensor is a camera, wherein the medical device comprises a barcode attached to a housing of the medical device. Advantageously, a low complexity and low-cost implementation of the techniques described herein may be achieved.

[0033] In some examples, the one or more servers comprising only the first server. The first server may thus implement all server functionality needed to achieve the functionality described herein. The first server may be a local server, i.e., connected to a local area network, LAN. The first server may in other examples be an external server, i.e., connected to an external network.

[0034] In some examples, the one or more servers comprises the first server and a second server, wherein the portable device is configured for transmitting the first data derived from the identification data to the second server. In this example, the second server is configured for: performing the comparison between the first data with the stored data; determining the URL pointing to the server application; and transmitting the URL to the portable device.

[0035] Beneficially, the use of a second server, which could be an external entity such as a server managed by an organization outside the healthcare environment, may offer an added layer of verification to ensure that healthcare data is permissible for display on the portable device. This external server may be used to adhere to various countryspecific regulations concerning data access. Moreover, the external server may facilitate the implementation of licensing agreements or fee schedules tailored to the different functionalities within the healthcare environment where the medical device operates.

[0036] In some examples, the first server and the medical device is connected to a local area network, LAN, and wherein the second server is connected to an external network. Such a setting facility external control over the determining of the URL and transmitting the link to the portable device, which in turn may increase security of the system. In some examples, the first server and the medical device is connected to a LAN and wherein the portable device can only connect to the application using the URL upon being connected to the LAN. Advantageously, such setup may facilitate a secure communication environment. By restricting access to the application to devices on the LAN, the risk of unauthorized access from external networks may be reduced. This may be advantageous in healthcare settings where sensitive patient data is handled and may align with stringent data protection and privacy regulations.

[0037] In some examples, the first server and the medical device is connected to a LAN and wherein, upon the portable device being connected to an external network different from the LAN, the portable device can only connect to the application using the URL upon providing a valid password. This example may offer flexibility and mobility, as healthcare professionals can access the application and necessary data from remote locations, which in turn may facilitate continuity of care and efficient decision-making, regardless of their physical location. Moreover, by requiring a password or additional authentication steps, unauthorized access may be effectively deterred, safeguarding sensitive healthcare data against potential cybersecurity threats.

[0038] In some examples, wherein the portable device is further configured to: retrieving second identification data of the patient using a sensor of the portable device; and transmitting second data derived from the identification data and the second identification data to the first server. The first server is in this example configured for establishing a mapping between the patient and the medical device in a database connected to the first server. Advantageously, a mapping between the patient and the medical device may be established using the same portable device which may be used for providing decision support as discussed herein. This may provide additional safety and reduce the risk of confusion of patient or device information and may be used by the first server when running the server application, such that correct information presented by the first GUI is ensured.

[0039] In some examples, the medical device is at least one of a cardiac support device, a respiratory support device, or a monitoring device.

[0040] According to a second aspect of the disclosure, the above object is achieved by a method for decision support for a patient undergoing a treatment provided by a medical device at a treatment site, the method comprising: • collecting, by the medical device, healthcare data;

[0041] • transmitting, by the medical device, the healthcare data to a first server of one or more servers;

[0042] • running, at the first server, a server application configured to provide a first graphical user interface, GUI, comprising first GUI items based on the healthcare data;

[0043] • retrieving identification data of the medical device using a sensor of a portable device;

[0044] • transmitting, by the portable device, first data derived from the identification data to the one or more servers;

[0045] • comparing, by the one or more servers, the first data with stored data, the stored data indicating whether the healthcare data is allowed to be visualized on the portable device;

[0046] • upon the healthcare data is allowed to be visualized on the portable device, determining, by the one or more servers, a URL pointing to the server application and transmitting the URL to the portable device;

[0047] • connecting, by the portable device, to the server application using the URL and displaying the first GUI provided by the server application.

[0048] According to a third aspect of the disclosure, the above object is achieved by one or more non-transitory computer-readable media storing instructions executable by a plurality of processors of a system for decision support for a patient undergoing a treatment provided by a medical device at a treatment site, wherein the instructions, when executed, cause the plurality of processors to perform operations comprising:

[0049] • collecting, by the medical device, healthcare data;

[0050] • transmitting, by the medical device, the healthcare data to a first server of one or more servers;

[0051] • running, at the first server, a server application configured to provide a first graphical user interface, GUI, comprising first GUI items based on the healthcare data;

[0052] • retrieving identification data of the medical device using a sensor of a portable device; • transmitting, by the portable device, first data derived from the identification data to the one or more servers;

[0053] • comparing, by the one or more servers, the first data with stored data, the stored data indicating whether the healthcare data is allowed to be visualized on the portable device;

[0054] • upon the healthcare data is allowed to be visualized on the portable device, determining, by the one or more servers, a URL pointing to the server application and transmitting the URL to the portable device;

[0055] • connecting, by the portable device, to the server application using the URL and displaying the first GUI provided by the server application.

[0056] The second and third aspects may generally have the same features and advantages as the first aspect. It is further noted that the disclosure relates to all possible combinations of features unless explicitly stated otherwise.

[0057] Brief Description of the Drawings

[0058] The above, as well as additional objects, features, and advantages of the present disclosure, will be better understood through the following illustrative and non-limiting detailed description of embodiments of the present disclosure, with reference to the appended drawings, where the same reference numerals will be used for similar elements, wherein:

[0059] Figures 1-4 show systems for decision support for a patient undergoing a treatment provided by a medical device at a treatment site according to embodiments;

[0060] Figures 5-6 show by way of example graphical user interfaces displayed on a medical device and a portable device, respectively.

[0061] Figure 7 shows a method for decision support for a patient undergoing a treatment provided by a medical device at a treatment site.

[0062] Detailed Description

[0063] In the rapidly evolving landscape of healthcare, remote decision support systems are emerging as pivotal tools in enhancing patient care and clinical efficiency. These systems represent a paradigm shift in how medical professionals access, analyse, and act upon healthcare data. Remote decision support enables healthcare providers to obtain insights (in real-time or based on stored data) and make informed decisions from various locations, breaking the traditional boundaries of in-hospital care. This approach is particularly beneficial in streamlining diagnostics, treatment planning, and monitoring, especially in scenarios where immediate specialist input is required but physical presence is constrained. By integrating data from various sources, remote decision support systems may provide a comprehensive view of patient health, facilitating timely and accurate medical interventions, as well as remote configuration of medical devices, etc.

[0064] However, accuracy and reliability of data from these various sources become paramount in remote decision support contexts. Unlike in-person evaluations where clinicians can use direct observation and manual verification, remote decision support relies heavily on the integrity of the data fed into the system. Erroneous or incomplete data can lead to misinformed decisions, emphasizing the necessity of robust data verification and validation processes.

[0065] Figure 1 shows by way of example a system 100 for decision support for a patient undergoing a treatment provided by a medical device at a treatment site, in which data integrity is facilitated.

[0066] The system 100 provides decision support for a patient 102 undergoing a treatment provided by a medical device 104 at a treatment site. Put differently, the system 100 may aid decision-making and facilitate treatment choices. The treatment may be a critical care treatment, primary care treatment, routine care treatment, monitoring, advanced monitoring, etc.

[0067] The medical device may for example be a cardiac support device, a respiratory support device, or a monitoring device. Other medical devices 104 are equally possible, such as infusion pumps or dialysis machines.

[0068] The medical device 104 is configured for collecting healthcare data 115. The healthcare data 115 may for example comprise patient data such as patient data collected from a patient 102 coupled to the medical device and 102 undergoing the treatment by the medical device 104. Such patient data collected by the medical device 104 may depend on the type of medical device 104 and / or the treatment provided by the medical device 104. The patient data may for example comprise breathing frequencies or breathing volume (for a ventilator device). The healthcare data 115 may alternatively or additionally comprise data generated by the medical device 104 such as device performance metrics, configuration data, usage statistics, and diagnostic output.

[0069] The system 100 (and similarly the systems described in conjunction with figures 2-4 below) may enable remote access to applications in relation to the treatment, such as patient data, medical device data, device configurations, etc. This may be accomplished by the medical device 104 transmitting the healthcare data 115 to a first server 116.

[0070] The first server may be connected to the medical device 104 via a local network (e.g., a local area network of a healthcare setting, such as a hospital) or external network, and the transmission of the data 115 may be accomplished by wired or wireless transmission. The medical device 104 and the first server 116 are thus provided with means for transmitting and receiving data, such as a wireless receiver and transmitter (or transceiver).

[0071] The first server 116 is configured for running a server application which processes the healthcare data 115. The first server 116 thus comprises an environment for running an application (the server application) that uses data 115 from the medical device 104 connected to the first server 116. It should be noted that typically the first server 116 is connected to a plurality of medical devices 104, but for ease of explanation, figure 1 (and figures 2-4 alike) only shows one medical device 104. The local server 102 may comprise an application runtime environment, comprising a container management platform such as a local Kubernetes platform. The environment may also be referred to as a Control Centre and may form a platform for various applications providing real-time information to a user and assisting in analytics, reporting and maintenance of the connected devices 104.

[0072] The server application is configured to provide a first graphical user interface, GUI, comprising first GUI items based on the healthcare data. The first GUI thus assisting a user in analytics, reporting and maintenance of the connected devices 104.

[0073] The system 100 further comprises a portable device 112, such as a smartphone, tablet, laptop, smart watch, VR / AR headsets, etc. The portable device comprises a sensor, for example a camera, RFID reader, microphone, etc. The portable device 112 is configured for retrieving identification data 108 of the medical device using the sensor. For example, the identification data 108 may be held by an identifier such as a bar code (e.g., a QR code), an NFC chip, a RFID chip, etc. It should be noted that any suitable sensor for sensing the identification data 115, and any suitable identifier for providing the identification data 115 may be employed. An embodiment of this system is the integration of barcode technology, specifically QR codes, with standard portable devices such as smartphones 112 or tablets 112 equipped with cameras. In this context, the portable device's 112 camera acts as a barcode scanner, allowing for a convenient and efficient method of capturing and interpreting the QR codes attached to medical devices 104. The QR code, a type of matrix barcode, is designed to hold a vast amount of information compared to traditional barcodes. When scanned, the QR code links to detailed information about the medical device, such as its type, serial number, manufacture date, and usage instructions. This not only streamlines the process of identifying and tracking medical devices 104 but also enhances the safety and efficiency of medical services by ensuring that critical information is readily accessible. Furthermore, considering the widespread use of smartphones and tablets, this approach leverages existing technology that is familiar to most users, thereby reducing the need for additional training or equipment.

[0074] The portable device 112 is further configured to, from the identification data 115, extract, interpret or otherwise derive first data 118. The first data 118 comprises the necessary data from the identification data 115, in a configured format, such that it can be employed using the techniques described herein. For example, the first data may be an encrypted version of (parts of) the identification data 115. The first data may identify the model and serial number of the medical device 104.

[0075] The first data 118 is transmitted to the first server 116. The first server 116 is configured to comparing the first data with stored data, the stored data indicating whether the healthcare data is allowed to be visualized on the portable device. The stored data may be stored in a database of the first server 116, or in an external database accessible by the first server 116. The stored data may comprise data that can be compared with the first data, such as data that can identify a medical device. In some embodiments, the stored data may comprise a data item per medical device in the hospital, wherein the data item indicates if the healthcare data is allowed to be visualized on the portable device. In other embodiments, the stored data may identify only such medical devices from which healthcare data are allowed to, or not allowed to, be visualized. The stored data may for example include license information (e.g., the medical device having a valid software license allowing the portable device to access the GUI of the server application), GDPR policies and / or patient specific requirements. The stored data may further identify if the medical device 104 has been properly installed and onboarded and e.g., configured to provide healthcare data in the right format or to a large enough extent.

[0076] The first server 116 is further configured for, upon the healthcare data is allowed to be visualized on the portable device 112, determining a uniform resource locator, URL, 120 to the server application. The primary purpose of this URL 120 is to point, refer, direct, lead, etc., the user of the portable device 112 to the server application's interface (the first GUI), typically accessed via a web browser installed on the portable device 112. The first server 116 sends the URL 120 to the portable device 112. Upon the healthcare data not being allowed to be visualized on the portable device 112, an error message may be transmitted to the portable device 112 and displayed on the display to inform the user.

[0077] The portable device 112 is further configured to connect to the server application using the URL 120. This may include the user of the portable device interacting (clicking, selecting, etc.) with the URL. As a result, the portable device 112 displays the first GUI 114, which is provided by the server application that runs on the first server 116 based on the healthcare data 115 provided by the medical device 104.

[0078] In some embodiments, the patient 102 is further wearing or otherwise associated with means for providing second identification data 122. For example, the patient may wear a bracelet with a QR code or an embedded RFID tag. In this embodiment, the portable device may further be configured for retrieving second identification data 122 of the patient 102 using a sensor of the portable device. The portable device may further be configured for transmitting second data (not shown in figure 1) derived from the identification data and the second identification data to the first server 116. The first server 116 may then be configured for establishing a mapping between the patient and the medical device in a database connected to the first server.

[0079] To establish a link between the medical device 104 and the patient 102, an extra scanning / sensing step may thus be incorporated. The portable device first scans / sense the QR code (or other identifiers for providing the identification data 108) present on the medical device 102 using the sensor of the portable device 112. The portable device (e.g., and application running on the portable device) subsequently prompts the user to scan e.g., the bracelet of the patient 102. The mapping between the patient and the medical device may then be established by the first server 116. Such association / mapping between the medical device 104 and the patient 102 may facilitate additional functionalities. With the established identity of both the medical device 104 and the patient 102 following the aforementioned procedure, the system 100 (e.g., the server application) may be positioned to offer patient-specific decision support. For instance, for a ventilator 104, the server application can evaluate the current settings of a ventilator, assimilate data regarding the patient's condition and status, and provide recommendations for optimizing the ventilator settings. This level of personalized decision support not only enhances patient care but also aids clinicians in making more informed treatment decisions.

[0080] In certain embodiments, the portable device 112 is equipped with a specialized application, referred to here as the second application, designed specifically for retrieving the identification data 108 of the medical device 104 using the device's sensor. Such bespoke application may be developed by the manufacturer of the medical device or the entity responsible for setting up the system 100. It is configured to accessing and utilizing data from the portable device's sensor for its designated purpose.

[0081] Additionally, the portable device 112 may also contain another distinct application, known here as the first application. This could be a default application that comes pre-installed with the portable device's operating system, or an application provided by a different company than the one that developed the second application. Like the second application, this first application is also capable of accessing and utilizing data from the sensor.

[0082] The dual-application approach on the portable device allows for multifaceted functionality of the identification data 108 provision tools, such as QR codes or RFID tags. For instance, when the second application is employed, it can retrieve the medical device's identification data 108 and use it as described herein. On the other hand, using the first application may trigger alternative functions. This could include accessing a user manual for the medical device or redirecting the user to a webpage for requesting maintenance or service for the medical device 104. This versatility enhances the utility of the portable device 112, allowing it to serve multiple roles in the healthcare environment.

[0083] In figure 1, a single (first) server 116 includes all functionality to run the server application, determine whether the portable device is authorized to show the server application when processing the healthcare data 115, as well as providing the portable device 112 with the URL (and optionally to establish the mapping between the patient and the medical device). In other embodiments, a further server 202 is involved. Such an embodiment is shown in figure 2.

[0084] Figure 2 corresponds to figure 1 in many ways, but implemented using two servers, the first server 116 and a second server 202. In the embodiment of figure 2, the functionality of determining of whether the portable device 112 is authorized to show the (GUI of the) server application when processing the healthcare data 115, as well as providing the portable device 112 with the URL 120, are implemented in the second server 202. For that reason, in this embodiment, the portable device 112 is configured for transmitting the first data 118 derived from the identification data to the second server 202. The second server 202 is configured for performing the comparison between the first data with the stored data (as described above), determining the URL 120 pointing to the server application, and transmitting the URL 120 to the portable device 112. The second server 202 may be configured to determining the URL 120 to the server application by communicating (not shown in figure 2) with the first server 116. For example, the communicating may involve sending the first data 118 to the first server 116 and receiving the URL as a response. In other embodiments, the second server 202 may comprise or have access to a database of URLs which corresponds to IDs (first data 118) of medical devices 104.

[0085] Figure 3 shows the one server embodiment of figure 1, wherein the medical device 104, the portable device 112 and the server 116 of the system 300 all are connected to a same local area network, LAN 302. In some embodiments, the portable device 112 can only connect to the server application using the URL upon being connected to the LAN 302. In other embodiments, not shown in figure 3, upon the portable device 112 being connected to an external network different from the LAN 302, the portable device 112 can only connect to the server application using the URL upon providing a valid password. For example, the portable device may need to connect to the local area network 302 using a virtual private network, VPN requiring a password. A VPN allows the portable device 112 to establish a secure connection over the internet to another network, in this case the LAN 302. When a VPN is used to connect to a LAN, it essentially extends the private network across the internet, enabling the portable device 112 to interact with the LAN 302 as if the portable device 112 were physically connected to it. In other embodiments, connecting the portable device 112 to the LAN 302 via a VPN is not necessary. Instead, access to the server application through the URL could be secured using alternative methods, such as two- factor authentication or other robust security solutions including passwords, ensuring controlled and safe access to the application. In the single-server architecture depicted in Figure 3, the medical device 104, the portable device 112, and the server 116 thus operate within a LAN 302, creating a controlled and efficient network topology. The server 116, typically employs a robust operating system designed for stability and security, such as Linux or Windows Server, and hosts the necessary server applications and databases for managing the data of the medical device 104. The server 116 may be equipped with specialized software for network management and data security, including but not limited to, SQL databases for data storage and retrieval, SSL / TLS encryption for secure data transmission, and SNMP (Simple Network Management Protocol) for network management. The server 116 may be running database management systems like MySQL or PostgreSQL to handle patient data efficiently. The server may utilize Docker containers or Kubemetes for application deployment and management, enabling modular and scalable healthcare applications (server applications). The LAN 302 itself may be configured to support high data transfer rates, to facilitate real-time transmission of medical data, and may be protected by enterprisegrade security measures including hardware firewalls and advanced threat detection systems. Additionally, the server 116 may implement virtualization technologies, allowing for efficient resource management and scalability by hosting multiple virtual servers on a single physical machine 116.

[0086] Figure 4 illustrates a variant of a system 400 depicted in Figure 2, featuring a dual-server configuration. In this setup, the medical device 104, the portable device 112, and the first server 116 are all interconnected within the same Local Area Network (LAN 302). In contrast, the second server 202 is linked to a separate, external network 402, which could typically be the public internet. This second server 202 might be configured as a cloud-based server or a traditional bare metal server. In this specific embodiment, the first server 116 is typically managed by the hospital, providing localized control over its operations. Meanwhile, the second server 202, which may play a distinct role in the system as discussed above, falls under the jurisdiction of a different entity - potentially the manufacturer of the medical device, the provider of the server application, or another third party separate from the hospital. This delineation of control and connectivity between the two servers offers a versatile and potentially more secure framework for managing the different aspects of the healthcare system. In the dual-server architecture as outlined in Figure 4, the system thus incorporates two distinct servers: the first server 116 within the LAN 302, and the second server 202 connected to an external network 402. The first server 116, typically housed within the healthcare facility, may be optimized for low-latency local communications and are set up similar to as described above in conjunction with figure 3. The external second server 202 may leverage cloud computing platforms like AWS, Google Cloud, or Azure to provide scalable and flexible resources as per demand. The interaction between the internal LAN 302 and the external internet 402 is typically managed through a combination of hardware and software solutions, for example dedicated network interfaces, secure VPN services for encrypted connections, and / or comprehensive access control lists (ACLs) to manage the traffic that can cross from the LAN 302 to the internet 402 and vice versa.

[0087] With the techniques described herein, remote decision support may be facilitated, offering a flexible and dynamic approach to healthcare management. This adaptability allows for the creation of a versatile framework, where decision support is not just generic but can be tailored to the specific roles and functions of the user of the portable device 112. For instance, the first GUI, as rendered by the server application, and provided at the portable device 112 as described above, can either serve as a digital twin, accurately mirroring the user interface of the medical device 104, or it can venture beyond, offering additional functionalities that are distinct from those displayed or provided by the medical device 104 itself. This dual capability ensures that the decision support system is not only comprehensive but also highly customizable, catering to a wide range of user needs and enhancing the overall efficacy of the healthcare service. For example, the server application running at the first server may be targeted to the identity or role of the user of the portable device 112, for example by providing the ID of the portable device or user included in the first data 118 to the first server 116. In other embodiments, the server application is the same no matter which portable device 112 that is requesting the URL.

[0088] Figures 5-6 schematically show two different embodiments of GUIs displayed on the medical device 104 (e.g., on a display 110 of the medical device 104) and on the display of the portable device 112.

[0089] In figure 5, the first GUI 504 (shown on the portable device 112) is a virtual replica of the second GUI 502 (shown on the display 110 of the medical device 104). This means that each GUI item of the second GUI 502 items has a corresponding GUI item among the first GUI items of the first GUI 504. In the example of figure 5, the difference between the first GUI 504 and the second GUI 502 is that the arrows for interacting with the curve of the GUIs 502, 504 are black in the first GUI 504 and white in the second GUI 502. In figure 5, both the first and second GUIs 502, 504 are designed to provide medical staff with detailed views and interactive capabilities concerning patient data, essential for the treatment of patients using the medical device. These interfaces 502, 504 may be tailored to meet the specific needs of a doctor in a treatment scenario, facilitating effective interaction with and analysis of patient data as required in the course of patient care, including remote decision support as described herein.

[0090] In the context of Figure 5, while the first GUI 504 on the portable device 112 is intended as a virtual replica of the second GUI 502 on the medical device 104, there may be intrinsic differences between the two, for example due to the inherent variations in device characteristics and user needs. For example, the discrepancy between the screen resolutions of the portable device 112 and the medical device 104 can lead to variations in the display and layout of GUI items. The portable device 112, typically having a smaller screen, may need to adapt the GUI layout to fit the available display area, which can result in alterations such as the resizing or repositioning of GUI elements. Furthermore, user configurations may impact the presentation and functionalities of the GUI 504 on the portable device 112. Users may customize their interface based on personal preferences or role-specific requirements, which can lead to additional GUI items being displayed on the GUI 504. In another example, the GUI 504 of the portable device 112 may also incorporate features like alerts or notifications that are specifically designed for mobile or remote usage scenarios. These additions may be tailored to leverage the portable nature of the device 112, ensuring that users remain informed and can react promptly, even when away from the medical device 104. This level of customization and adaptability may facilitate that the GUI 504 not only serves as a virtual replica but also as an enhanced, user-centric interface that caters to the specific needs and conditions of its user.

[0091] In figure 6, the first GUI 602 (shown on the portable device 112) are intended to represent a GUI 602 specifically designed for service technicians. This interface 602 includes GUI elements that allow detailed control and configuration of the medical device 104. Additionally, it features a chat icon, enabling technicians to easily request maintenance or servicing for the medical device 104. Meanwhile, the second GUI 502, visible on the display 110 of the medical device 104, continues to serve the purpose outlined in figure 5. It focuses on presenting detailed information about the patient data collected by the medical device 104, thereby differentiating the functionalities of the two GUIs to cater to distinct user roles and requirements. In figure 6, the first GUI 602 shown on the portable device 112 is thus not a digital twin of the interface (second GUI) 502 of the medical device, and as such, the GUI items of the second GUI 502 comprises at least one unique GUI item not corresponding to a GUI of the first GUI 602. In examples, the server application providing the first GUI 602 may include security measures such as lists or connections to other applications / databases that manage access rights based on the user's role. For instance, a service technician may need to access device configuration details without viewing sensitive patient data. Therefore, certain data visible on the second GUI 502 of the medical device 104 could be hidden or redacted on the GUI 602 of the portable device 112 when accessed by someone in a technician role.

[0092] The selection between the embodiments of figure 5 and 6, as well as the details described above, can be achieved through a combination of user authentication and role-based access control (RBAC) systems. For example, when a user logs into their account on the portable device 112, the system may check their credentials against a centralized database to verify their identity and role. Each user role is associated with specific configuration settings that determine the parameters for GUI item visibility and interaction as described above. For example, upon successful login, a user identified as a 'technician' might be granted access to GUI elements related to device maintenance and troubleshooting, but restricted from accessing patient-specific data fields, i.e. the embodiment of figure 6. Conversely, a 'doctor' role may enable access to comprehensive patient data and treatment options (e.g., figure 5 above), while possibly limiting technical device settings irrelevant to medical treatment. The system can use predefined lists or templates that contain subsets of GUI items tailored to each role, specifying which elements from the GUI 502 that should be shown or hidden when the GUIs 504, 602 is provided to the portable device 112. These lists may be maintained by system administrators and can be updated as roles evolve, or new data privacy regulations come into effect. By dynamically adjusting the GUI based on these role- defined parameters, the system may ensure that users have access to the necessary tools and information for their specific duties while maintaining patient confidentiality and data security.

[0093] Figure 7 shows a flow chart of a method of a method 700 for decision support for a patient undergoing a treatment provided by a medical device at a treatment site, as described herein. The method 700 may be embodied by one or more non-transitory computer-readable media storing instructions implementing the method. The instructions may be executable by a plurality of processors of a system as described herein. By way of example and not limitation, the processor(s) may comprise one or more central processing units (CPUs), graphics processing units (GPUs), integrated circuits (e.g., application-specific integrated circuits (ASICs)), gate arrays (e.g., field- programmable gate arrays (FPGAs)), and / or any other device or portion of a device that processes electronic data to transform that electronic data into other electronic data that may be stored in registers and / or memory.

[0094] The method comprises collecting S702, by the medical device, healthcare data. The method 700 further comprises transmitting S704, by the medical device, the healthcare data to a first server of one or more servers. The method 700 further comprises running S706, at the first server, a server application configured to provide a first GUI, comprising first GUI items based on the healthcare data. The method 700 further comprises retrieving S708 identification data of the medical device using a sensor of a portable device. The method 700 further comprises transmitting S710, by the portable device, first data derived from the identification data to the one or more servers. The method 700 further comprises comparing, by the one or more servers, the first data with stored data, the stored data indicating whether the healthcare data is allowed to be visualized on the portable device. If it is determined S712, that the healthcare data (collected by the medical device) can be visualized on the portable device, the method 700 continues, by determining S714, by the one or more servers, a URL pointing to the server application and transmitting the URL to the portable device. Finally, the method 700 comprises connecting S716, by the portable device, to the server application using the URL and displaying the first GUI provided by the server application.

[0095] It should be noted that the steps of the method 700 may be implemented in a different order compared to figure 7. For example, steps S708-S712 may be performed prior to steps S702-S706, wherein steps S702-S706 is conditionally performed upon it is determined that the healthcare data is allowed S712 to be visualized on the portable device.

[0096] In summary the present disclosure relates to a system, method and non- transitory computer-readable media designed for decision support in treatment using a medical device at a treatment site. A medical device collects S702 and transmits S704 healthcare data to a first server of one or more servers. This server runs S706 an application providing a GUI based on the healthcare data. The system includes a portable device equipped with a sensor to retrieve S708 identification data of the medical device and transmit S710 derived data to the servers (e.g., to the first server or to an optional second server). The servers (the first or second) compare this data with stored data to determine S712 that the healthcare data can be displayed on the portable device. The servers (first or second) generate S714 a URL to the server application, which is then sent to the portable device. The portable device uses this link to connect S716 to the server application and display the first GUI.

[0097] The above embodiments are to be understood as illustrative examples of the disclosure. Further embodiments of the disclosure are envisaged. For example, Bluetooth beacons could be implemented to provide the identification data of the medical device. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the disclosure, which is defined in the accompanying claims.

Claims

CLAIMS1. A system (100, 200, 300, 400) for decision support for a patient (102) undergoing a treatment provided by a medical device (104) at a treatment site, the system comprising one or more servers (116, 202), the medical device configured for: collecting (S702 healthcare data (115), and transmitting (S704) the healthcare data to a first server (116) of the one or more servers; wherein the first server is configured for: running (S706) a server application configured to provide a first graphical user interface, GUI, (504, 602, 114) comprising first GUI items based on the healthcare data; wherein the system further comprising a portable device (112) configured for: retrieving (S708) identification data (108) of the medical device using a sensor of the portable device; transmitting (S710) first data (118) derived from the identification data to the one or more servers; wherein the one or more servers are configured for: comparing the first data with stored data, the stored data indicating whether the healthcare data is allowed to be visualized on the portable device; upon the healthcare data is allowed (S712) to be visualized on the portable device, determining (S714) a uniform resource locator, URL, (120) pointing to the server application and transmitting the URL to the portable device; wherein the portable device is configured for: connecting (S716) to the server application using the URL and displaying the first GUI provided by the server application.

2. The system of claim 1, wherein the medical device comprises a display for displaying a second GUI (502) comprising second GUI items based on the healthcare data, wherein the server application is configured to provide the first GUI (504) being a virtual replica of the second GUI, such that each GUI item of the second GUI items has a corresponding GUI item among the first GUI items.

3. The system of claim 1, wherein the medical device comprises a display for displaying a second GUI (502) comprising second GUI items based on the healthcare data, wherein the second GUI items comprises at least one unique GUI item not corresponding to a GUI item among the first GUI items.

4. The system of any one of claims 1-3, wherein the portable device is configured to: enable a first application of the portable device to access and utilize data from the sensor; and enable a second application, distinct from the first application, to access and utilize data from the sensor; wherein the retrieving identification data of the medical device using a sensor of the portable device comprises using the second application; wherein the portable device is configured for: upon using the first application to access and utilize data from the sensor, accessing a user manual and / or product information of a medical device.

5. The system of claim 4, wherein the first application is a pre-installed application integrated into an operating system, OS, of the portable device.

6. The system of any one of claims 1-5, wherein the sensor is a camera, wherein the medical device comprises a barcode attached to a housing of the medical device.

7. The system of any one of claim 1-6, wherein the one or more servers comprising only the first server.

8. The system of any one of claims 1-7, wherein the one or more servers comprises the first server and a second server (202), wherein the portable device is configured for: transmitting the first data derived from the identification data to the second server; wherein second server is configured for: performing the comparison between the first data with the stored data;determining the URL pointing to the server application; and transmitting the URL to the portable device.

9. The system of claim 8, wherein the first server and the medical device is connected to a local area network, LAN, (302) and wherein the second server is connected to an external network (402).

10. The system of any one of claims 1-9, wherein the first server and the medical device is connected to a LAN (302) and wherein the portable device can only connect to the server application using the URL upon being connected to the LAN.

11. The system of any one of claims 1-9, wherein the first server and the medical device is connected to a LAN (302) and wherein, upon the portable device being connected to an external network different from the LAN, the portable device can only connect to the application using the URL upon providing a valid password.

12. The system of any one of claims 1-11, wherein the portable device is further configured to: retrieving second identification data (122) of the patient using a sensor of the portable device; and transmitting second data derived from the identification data and the second identification data to the first server; wherein the first server is configured for: establishing a mapping between the patient and the medical device in a database connected to the first server.

13. The system of any one of claims 1-12, wherein the medical device is at least one of: a cardiac support device, a respiratory support device, or a monitoring device.

14. A method (700) for decision support for a patient (102) undergoing a treatment provided by a medical device (104) at a treatment site, the method comprising: collecting (S702), by the medical device, healthcare data (115);transmitting (S704), by the medical device, the healthcare data to a first server (116) of one or more servers (116, 202); running (S706), at the first server, a server application configured to provide a first graphical user interface, GUI, (504, 602) comprising first GUI items based on the healthcare data; retrieving (S708) identification data (108) of the medical device using a sensor of a portable device (112); transmitting (S710), by the portable device, first data (118) derived from the identification data to the one or more servers; comparing, by the one or more servers, the first data with stored data, the stored data indicating whether the healthcare data is allowed to be visualized on the portable device; upon the healthcare data is allowed (S712) to be visualized on the portable device, determining (S714), by the one or more servers, a uniform resource locator, URL, (120) pointing to the server application and transmitting the URL to the portable device; connecting (S716), by the portable device, to the server application using the URL and displaying the first GUI provided by the server application.

15. One or more non-transitory computer-readable media storing instructions executable by a plurality of processors of a system for decision support for a patient (102) undergoing a treatment provided by a medical device (104) at a treatment site, wherein the instructions, when executed, cause the plurality of processors to perform operations comprising: collecting (S702), by the medical device, healthcare data (115); transmitting (S704), by the medical device, the healthcare data to a first server (116) of one or more servers (116, 202); running (S706), at the first server, a server application configured to provide a first graphical user interface, GUI, (504, 602) comprising first GUI items based on the healthcare data; retrieving (S708) identification data (108) of the medical device using a sensor of a portable device (112);transmitting (S710), by the portable device, first data (118) derived from the identification data to the one or more servers; comparing, by the one or more servers, the first data with stored data, the stored data indicating whether the healthcare data is allowed to be visualized on the portable device; upon the healthcare data is allowed (S712) to be visualized on the portable device, determining (S714), by the one or more servers, a uniform resource locator, URL, (120) pointing to the server application and transmitting the URL to the portable device; connecting (S716), by the portable device, to the server application using theURL and displaying the first GUI provided by the server application.

Images