Treatment Sharing Method Implemented on a Treatment Machine

Abstract

The present disclosure relates to a method for executing a sharing enabler of a registered medical treatment machine. The registered medical treatment machine is used in a shared medical treatment system. The method comprises the method steps: Providing a registration procedure for registering the medical treatment machine in the shared medical treatment system; Receiving an initiation request for initiating a medical treatment for a patient, being registered in the shared medical treatment system; Checking whether the received initiation request is valid by receiving a confirmation signal and if yes: Unlocking the medical treatment machine in reply to the received confirmation signal for use for the patient; Operating the medical treatment machine according to a treatment procedure in a sharing mode.

Claims

1-21. (canceled)

22. A method for executing a sharing enabler of a registered medical treatment machine, to be used in a shared medical treatment system, wherein the method comprises: providing a registration procedure for registering the medical treatment machine in the shared medical treatment system; receiving an initiation request for initiating a medical treatment for a patient being registered in the shared medical treatment system; determining whether the received initiation request is valid by receiving a confirmation signal; and in response to determining that the received initiation request is valid: (i) unlocking the medical treatment machine in reply to the received confirmation signal for use for the patient; and (ii) operating the medical treatment machine according to a treatment procedure in a sharing mode.

23. The method according to claim 22, wherein the medical treatment machine is hosted by a provider.

24. The method according to claim 22, wherein the medical treatment machine is hosted by a provider who is the patient.

25. The method according to claim 22, wherein the determining whether the received initiation request is valid further comprises checking availability of consumables necessary for executing the requested medical treatment and/or checking availability of necessary emergency providers for the requested medical treatment.

26. The method according to claim 22, wherein the operating the medical treatment machine is based on a prescription received from a physician's device via a network connection.

27. The method according to claim 22, wherein the registration procedure for registering the medical treatment machine comprises checking a set of certificates.

28. The method according to claim 27, wherein the method further comprises: sending a provider confirmation request to a treatment provider; and receiving a confirmation signal of the treatment provider indicating that the treatment provider confirms itself for the patient.

29. The method according to claim 27, wherein the method further comprises: sending a physician confirmation request to a physician's device; and receiving a confirmation signal of the physician's device, indicating that a treatment provider is confirmed for the patient.

30. The method according to claim 22, wherein the method further comprises establishing a network connection to a hub system, treatment provider's device, and/or to a physician's device.

31. The method according to claim 22, wherein the method further comprises: receiving or measuring patient related vital parameters from a set of sensors for checking eligibility of the patient for the requested medical treatment; and in case of non-compliance with a set of pre-configured reference intervals, issuing a failure message and initiating a vital data non-compliance procedure.

32. The method according to claim 31, wherein measured patient related vital parameters are compared with received patient related vital parameters for the purpose of verification and, in case of deviations above a pre-configured threshold, corrections measures are initiated.

33. The method according to claim 32, wherein a consistency check is executed for the vital parameters which have been provided by manual input, wherein the consistency check is based on an additional measurement of the vital parameters by means of sensors, which is be provided in wearables or in the medical treatment machine or at a treatment provider.

34. The method according to claim 22, wherein patient's vital parameters are sent to a metabolic model for checking consistency and for approving a prescription and/or for improving a metabolic model and/or a prescription, based on currently measured vital parameters.

35. The method according to claim 22, wherein the method further comprises establishing a communication channel to a treatment provider's device and/or to a hub system for transmitting messages.

36. The method according to claim 22, wherein the determining whether the received initiation request is valid comprises receiving result data of an executed patient eligibility test for self-treatment.

37. The method according to claim 22, wherein the confirmation signal is received from a patient device, a hub system, a treatment provider's device, and/or by a physician's device.

38. The method according to claim 22, wherein after unlocking and before operating the medical treatment machine, a preparation procedure is initiated for setting up the medical treatment machine and for loading a prescription.

39. The method according to claim 38, wherein after unlocking and before or during operating the medical treatment machine, a treatment support function will be executed, which comprises a set of pre-configurable watchdog functions and may comprise output of operating instruction messages.

40. The method according to claim 39, wherein the treatment support function comprises a rating function for rating the machine, the treatment provider, and/or for rating the medical treatment.

41. The method according to claim 22, wherein the medical treatment machine is hosted and administered by a treatment provider within a local network and may be part of a set of treatment machines of the same provider.

42. A computer program with program elements which induce computer to carry out the steps of the method according to claim 22, when the program elements are loaded into a memory of the computer.

43. A sharing enabler which is implemented on a medical treatment machine and which is configured to execute a method according to claim 22.

Description

BRIEF DESCRIPTION OF THE DRAWING

[0087] The properties, features and advantages described above, as well as the manner they are achieved, become clearer and more understandable in the light of the following description and embodiments, which will be described in more detail in the context of the drawings. This following description does not limit the invention on the contained embodiments. Same components or parts can be labeled with the same reference signs in different figures. In general, the figures are not for scale. It shall be understood that an embodiment can also be any combination of the above embodiments.

[0088] In the following possible embodiments are described in more detail with reference to the enclosed figures.

[0089] The scope of the present invention is given by the claims and is not restricted by features discussed in the description or shown in the figures. Generally, any reference signs in the patent claims should not be construed as limiting the scope.

[0090] FIG. 1 is a schematic representation of a treatment machine connected to a shared medical treatment system;

[0091] FIG. 2 is a schematic representation of a treatment machine connected to a shared medical treatment system;

[0092] FIG. 3 is a flowchart of a treatment sharing method;

[0093] FIG. 4 shows a perspective view of a fluid conditioning system that can operate with a medical treatment machine, e.g., with a dialysis machine, to carry out a fluid conditioning cycle that includes a medical treatment;

[0094] FIG. 5 is a front perspective view of a hemodialysis system;

[0095] FIG. 6 shows an example of a peritoneal dialysis system;

[0096] FIG. 7 is a block diagram of more abstracted generalized representation of a computing entity according to an embodiment of a patient device;

[0097] FIG. 8 shows a schematic flowchart representing the requesting of a treatment machine;

[0098] FIG. 9 shows a schematic flowchart representing a daily check of a patient;

[0099] FIG. 10 shows a schematic flowchart representing the preparation of a medical treatment; and

[0100] FIG. 11 shows a schematic flowchart representing the medical treatment.

DETAILED DESCRIPTION OF THE DRAWINGS

[0101] FIG. 1 shows an overview figure with a plurality of treatment providers Pr, respectively treatment machines, which may register in a shared medical treatment system. Each provider Pr and/or the treatment machines M may establish a communication connection to a network N for connecting to a central hub H of the shared medical treatment system. The central hub H is a computer entity and could be a server or a virtual computer, or a computer instance processed on a server or server system. The central hub H may comprise an interface for providing a communication connection to the network N. The central hub H may comprise a matching module MM that is implemented in a computing entity 10 (electronic module) for matching a patient Pa to a matching treatment machine M. A plurality of providers Pr and/or treatment machines may register to participate in the shared medical treatment system. A provider Pr may comprise at least one treatment machine M, e.g., a dialysis machine M, explained in more detail with respect to FIG. 5 and FIG. 6. A provider Pr or may be a hospital or a dialysis department or a private person that wants to offer the treatment machine M to other patients Pa for self-treatment is shown. A provider Pr may therefore provide at least one treatment machine M for medical treatment services. As presented in FIG. 1, provider Pr1 provides two machines M. Further, the provider Pr1 may provide sensors S, which are configured to detect environment data of the treatment machine M while performing the medical treatment, before, and/or after the medical treatment, for detecting, e.g., whether other persons or animals entered the treatment location. In case a person or animal entered the treatment location, a further disinfection may be initiated. Further, the provider Pr1 may provide or may linked with a computing entity 10 for processing a matching module MM, or solely a provider's part thereof (in the embodiment, where the matching module MM is implemented in a distributed manner). In this case, the other, e.g., a patient's part may be implemented and processed in the computing entity 10 of the central hub H or in the computing entity 10 of the patient device PaD.

[0102] In another preferred alternative embodiment, another setting of the provider Pr and the treatment machine M is applied, which is shown by way of example in FIG. 1 with provider Pr2. In this setting, the machine M is staffed with electronic modules, e.g., with local sensors S. The sensors S may be designed to detect the (correct) handling and usage of the treatment machine M while performing the medical treatment, and thus may indirectly provide information relating to the patient's cooperation and treatment behavior, e.g., how long a certain task lasts and whether or not the patient Pa is acting sufficiently precise by executing one step after the other without too long breaks and/or whether or not he or she fulfills all self-treatment requirements. In this case the sensors S are located locally at the machine M of provider Pr2. Nevertheless, in addition the provider Pr2 may also be equipped with sensors S for detecting other parameters, e.g., a loading and/or status of the different machines M of the provider Pr. Further, the sensors S of the machine can be configured to detect possible disturbance, and or providing data for a planned maintenance.

[0103] In another embodiment, another setting of the machine M is applied, which is shown by way of example in FIG. 1 with machine M3. This setting relates to the machine M3, which is usually equipped with a computer unit (CPU etc.). This computer unit may be configured to include the computing entity 10, which has implemented thereon the matching module MM or a provider's part thereof. In this setting, the machines M are staffed with more CPU power and are made more intelligent and do comprise the control software, e.g., the sharing enabler for participating in the sharing system by themselves. Thus, the patient device PaD may directly interact with the corresponding (sharing enabler) the machine M3 of a provider Pr.

[0104] Generally, the computing entity 10 and/or the matching module MM may be distributed over several computer hardware or nodes in the communication network. Thus, there does exist different parts or portions of one functional entity. The functional entity may, e.g., be implemented in software as an application in short app, and thus, with a patient device part app and with a machine or provider's part app.

[0105] FIG. 2 shows an overview figure with a patient Pa using an electronic device, e.g., a patient device PaD. The patient device PaD may be an electronic wearable, e.g., a handheld or a smartwatch that can be used to register in a shared medical treatment system. The patient Pa is uniquely associated to a patient identifier Pa-ID. The patient identifiers serve to uniquely identify a particular patient Pa. The patient identifier Pa-ID may be an electronic code, e.g., in form of an electronic fingerprint, a data structure or a biometrical dataset. Generally, a patient Pa needs to register in the shared medical treatment system. Thus, not all patients Pa are registered patients. The patient identifier Pa-ID can be combined with an additional secret, e.g., a password comprising a random combination of numbers, letters, and/or characters. The password has to fulfill specific criteria relating to length and combination. The patient-identifier Pa-ID may be generated on or by means of the patient device Pa-D. Further, the patient identifier Pa-ID is associated to a password as a further part of the authorization credentials. The authorization credentials may be used to authenticate a patient Pa or the patient device Pad to other parties, e.g., computing entities 10, server etc. of the shared medical treatment system. In an embodiment, a two-factor authentication using a different communication channel for providing the second factor can be used. The patient device PaD preferably is a handheld or a smartwatch, but alternatively could be a computer, e.g., a laptop or workstation that includes respective interfaces, e.g., communication interfaces for connecting with the shared medical treatment system and its computing units.

[0106] The patient device Pad includes a user interface DI for communication to and from a patient Pa. The user interface can be configured as a touch screen interface providing input and output capabilities.

[0107] The touch screen can be used to authenticate and sign-in in a patient application PaApp processed by the electronic module 10, e.g. a processing unit. Further, the touch screen can be used to display the patient application PaApp. The patient application PaApp is designed for register or sign-in in the shared medical treatment system. Further the patient application PaApp provides capabilities for requesting a medical treatment, receiving a message with a suggestion for suggested treatment provider, and/or suggested treatment machine based on a matching algorithm. Further, the patient application PaApp may provide an eligibility check of the patient, a scoring and rating procedure for registered providers, treatment machines, and/or medical treatments. Further, the patient application PaApp may include a transportation support for getting to the providers location using an online map service provider, e.g., Google Earth, Google Maps. Further, the patient application PaApp may support a patient Pa for preparing the medical treatment or while performing the medical treatment with help instruction messages. Further, the patient application PaApp may alarm an emergency operator or physician in case of a medical emergency or malfunction of the treatment machine M. The patient application PaApp may implement a matching module performing a matching algorithm. Typically, the patient application PaApp is used by the patient him/herself. However, if he/she is not in the position to use the app, a trusted person (e.g., parents, or child, or family member) may use the app on behalf of the patient.

[0108] The patient device PaD may comprise further electronic modules 10, e.g., a memory for storing the operation system of the patient device PaD, the patient application PaApp, further applications, data measured by sensors of the patient device PaD or with the patient device, or connected sensors. Further, data concerning the entire medical treatment as well as data from sensors included in the treatment machine can be stored in the memory. The data can be stored in a database stored in the memory. Further, the data can be used to train a metabolic model that can be stored in the memory. Further, the patient device PaD may comprise further interface for connecting to the treatment machines M or to the provider Pr or to further computing units, e.g., a hub H, which can be implemented as a computing unit, e.g., a server. The interface I can be configured to implement a wireless communication connection, e.g., WIFI, Bluetooth, Infrared, etc. or a wired communication connection, e.g., serial communication connection.

[0109] The patient device PaD is connected to the hub H over a communication network N. The hub H can be implemented as central computer or server and/or virtual instance in server/cloud system. The hub H may comprise an interface I for connecting the hub to the communication network N. The interface I can be configured to establish a wireless communication connection, e.g., Wifi, or a wired communication connection, e.g., LAN. The hub H can be configured to process and store applications, e.g., a matching algorithm. In an embodiment, the matching algorithm may be implemented as an electronic module, e.g., a matching module for matching a patient Pa to a matching treatment machine M, which are depicted on the right-hand side of FIG. 2. In an embodiment, the matching module can be distributed and/or processed on different electronic modules in different hardware, e.g., a patient device PaD, a hub H, or a treatment machine M. In this way, the processing of the matching module MM can be split corresponding to the matching algorithm necessary for each party involved in the treatment sharing method. Further, the hub H may be configured to process the communication between the different parties.

[0110] A plurality of providers Pr may register to participate in the shared medical treatment system. Each provider Pr may comprise at least one treatment machine M, like a dialysis machine, explained in more detail below with respect to FIGS. 5 and 6. A provider Pr may be a hospital or a dialysis department or a private person, who wants to offer his or her dialysis machine M to other patients for self-treatment. A provider Pr may therefore provide at least one treatment machine M for treatment services. As shown in the example in FIG. 2, the provider Pr1 has two treatment machines M11, M12 and the second provider Pr2 has one treatment machine M21 and the n-th treatment machine provider Pm offers j treatment machines, Mn1, Mn2, Mnj. The treatment machine M may comprise an interface I that is configured to establish a wireless or wired communication connection to the network N for connecting to the hub H and/or the patient device PaD. The hub H may interact with a physician's device PhD. A physician Ph may use the physician's device to confirm the initiation request for unlocking the treatment machine M. The hub H may further interact to an emergency provider's device E-PrD. An emergency provider E-Pr may use the emergency provider's device E-PrD in case of emergency to support the patient Pa and/or the treatment provider Pr to prevent damage from the patient Pa and/or treatment machine M.

[0111] FIG. 3 is a flowchart of a treatment sharing method. The treatment sharing method, e.g., the sharing enabler E may be implemented on a computing entity 10 or of an electronic module of the computing entity 10. The computing entity 10 may be implemented in a registered treatment machine M, to be used in a shared medical treatment system. The sharing enabler E can be designed and programmed according to the operation system of the treatment machine M. After start of the sharing enabler, in step S1 a registration procedure for registering the medical treatment machine M in the shared medical treatment system is provided. In step S2 an initiation request for initiating a medical treatment for a patient Pa, being registered in the shared medical treatment system is received. In step S3, the received initiation request is checked, whether it is valid. The check is performed by receiving a confirmation signal. If the received initiation request is valid, the medical treatment machine M is unlocked, in step S4, in reply to the received confirmation signal for use for the patient Pa. Finally, in step S5, the medical treatment machine M is operated according to a treatment procedure in a sharing mode.

[0112] FIG. 4 illustrates a fluid conditioning system 100 that can be operated to prepare conditioned dialysate for use in a dialysis system. For example, the fluid conditioning system 100 can be fluidly communicated with the dialysis system to deliver “fresh” (e.g., cleaned, conditioned) dialysate to the dialysis system, collect “spent” (e.g., contaminated, unconditioned) dialysate from the dialysis system, and regenerate (e.g., cleanse) and condition the spent dialysate in a continuous fluid flow loop to recycle the spent dialysate. Example dialysis systems with which the fluid conditioning system 100 can be fluidly communicated include hemodialysis (HD) systems, peritoneal dialysis (PD) systems, hemofiltration (HF), hemodiafiltration (HDF) and other related systems.

[0113] The fluid conditioning system 100 includes a housing 101 that contains or supports components of the fluid conditioning system 100, a fluid cassette 102 that includes multiple fluid lines defining various fluid pathways, two relatively high capacity pumps 103 that can circulate fluid within the fluid lines of the fluid cassette 102, and two relatively low capacity pumps 104 that can deliver (e.g., infuse) conditioning agents into the fluid circulating within the fluid lines of the fluid cassette 102. The fluid conditioning system 100 has a compact footprint that facilitates lifting and transport of the fluid conditioning system 100. For example, the fluid conditioning system 100 typically has a length of about 30 cm to about 50 cm, a width of about 30 cm to about 50 cm, a height of about 30 cm to about 50 cm, and a weight of about 15 kg to about 20 kg. The housing 101 includes left and right side panels 105, 106, handles 107 positioned along the side panels 105, 106 for carrying the fluid conditioning system 100, a door assembly 108 that can be opened and closed to insert a heater bag, a front panel 109 to which the door assembly 108 is secured, rear and bottom panels 110, 111 that further enclose the interior components, an upper panel 112 that supports the fluid cassette 102 and the pumps 103, 104, and a cover 113 that protects the fluid cassette 102 and the pumps 103, 104. Example materials from which the exterior panels of the housing 101 may be made include plastics, such as acrylonitrile butadiene styrene (ABS) and polycarbonate blends, among others.

[0114] The cover 113 is typically made of ABS or polycarbonate and is transparent or translucent to allow visualization of the fluid cassette 102 and the pumps 103, 104. The cover 113 can be pivoted at a rear hinge 114 disposed along the upper panel 112 to open or close the cover 113. The upper panel 112 carries two latches 115 that can be closed upon a front edge 116 of the cover 113 to secure the cover 113 in a closed position. The latches 115 can also be pulled up and apart from the cover 113 to release the cover 113 from the closed position for accessing the fluid cassette 102 and the pumps 103, 104.

[0115] FIG. 5 shows a HD system 600 configured to wirelessly communicate with other medical devices. The HD system 600 includes a HD machine 602 connected to a disposable blood component set 604 that partially forms a blood circuit. The operator can manage and control treatment parameters of the HD system 600 using an external wireless keyboard 601. During HD treatment, an operator connects arterial and venous patient lines 606, 608 of the blood component set 604 to a patient. The blood component set 604 includes an air release device 612, which contains a self-sealing vent assembly that allows air but does not allow liquid to pass. As a result, if blood passing through the blood circuit during treatment contains air, the air release device 612 will vent the air to atmosphere. The blood component set 604 is secured to a module 630 attached to the front of the HD machine 602. The module 630 includes the blood pump 632 capable of circulating blood through the blood circuit. The module 630 also includes various other instruments capable of monitoring the blood flowing through the blood circuit. The module 630 includes a door that when closed, as shown in FIG. 5, cooperates with the front face of the module 630 to form a compartment sized and shaped to receive the blood component set 604. In the closed position, the door presses certain blood components of the blood component set 604 against corresponding instruments exposed on the front face of the module 630.

[0116] The operator uses a blood pump module 634 to operate the blood pump 632. The blood pump module 634 includes a display window, a start/stop key, an up key, a down key, a level adjust key, and an arterial pressure port. The display window displays the blood flow rate setting during blood pump operation. The start/stop key starts and stops the blood pump 632. The up and down keys increase and decrease the speed of the blood pump 632. The level adjust key raises a level of fluid in an arterial drip chamber. The HD machine 602 further includes a dialysate circuit formed by the dialyzer 610 various other dialysate components and dialysate lines connected to the HD machine 602. Many of these dialysate components and dialysate lines are inside the housing 603 of the HD machine 602 and are thus not visible in FIG. 5. During treatment, while the blood pump 632 circulates blood through the blood circuit, dialysate pumps (not shown) circulate dialysate through the dialysate circuit. A dialysate container 624 is connected to the HD machine 602 via a dialysate supply line 626. A drain line 628 and an ultrafiltration line 629 also extend from the HD machine 602. The dialysate supply line 626, the drain line 628, and the ultrafiltration line 629 are fluidly connected to the various dialysate components and dialysate lines inside the housing 603 of the HD machine 602 that form part of the dialysate circuit. During HD, the dialysate supply line 626 carries fresh dialysate from the dialysate container 624 to the portion of the dialysate circuit located inside the HD machine 602. As noted above, the fresh dialysate is circulated through various dialysate lines and dialysate components, including the dialyzer 610, that form the dialysate circuit. As will be described below, as the dialysate passes through the dialyzer 610, it collects toxins from the patient's blood. The resulting spent dialysate is carried from the dialysate circuit to a drain via the drain line 628. When ultrafiltration is performed during treatment, a combination of spent dialysate (described below) and excess fluid drawn from the patient is carried to the drain via the ultrafiltration line 629. The dialyzer 610 serves as a filter for the patient's blood. The dialysate passes through the dialyzer 610 along with the blood, as described above. A semi-permeable structure (e.g., a semi-permeable membrane and/or semi-permeable microtubes) within the dialyzer 610 separates blood and dialysate passing through the dialyzer 610. This arrangement allows the dialysate to collect toxins from the patient's blood. The filtered blood exiting the dialyzer 610 is returned to the patient. The dialysate exiting the dialyzer 610 includes toxins removed from the blood and is commonly referred to as “spent dialysate.” The spent dialysate is routed from the dialyzer 610 to a drain.

[0117] A drug pump 692 also extends from the front of the HD machine 602. The drug pump 692 is a syringe pump that includes a clamping mechanism configured to retain a syringe 678 of the blood component set 604. The drug pump 692 also includes a stepper motor configured to move the plunger of the syringe 678 along the axis of the syringe 678. A shaft of the stepper motor is secured to the plunger in a manner such that when the stepper motor is operated in a first direction, the shaft forces the plunger into the syringe, and when operated in a second direction, the shaft pulls the plunger out of the syringe 678. The drug pump 692 can thus be used to inject a liquid drug (e.g., heparin) from the syringe 678 into the blood circuit via a drug delivery line 674 during use, or to draw liquid from the blood circuit into the syringe 678 via the drug delivery line 674 during use.

[0118] The HD machine 602 includes a user interface with input devices such as a touch screen 618 and a control panel 620. The touch screen 618 and the control panel 620 allow the operator to input various different treatment parameters to the HD machine 602 and to otherwise control the HD machine 602. The touch screen 618 displays information to the operator of the HD system 600. The touch screen 618 can also indicate whether a peripheral or accessory device, such as the keyboard 601, is connected to the HD machine 602. The keyboard 601 is a wireless keyboard that connects to the HD machine 602 by communicating directly or indirectly with a communication system 607 in the HD machine 602. During treatment, the keyboard 601 and other peripheral devices can be used to control, monitor, and determine treatment parameters and variables.

[0119] FIG. 6 shows a PD system 700 that includes a PD machine (also referred to as a PD cycler) 702 seated on a cart 704. The PD machine 702 includes a housing 706, a door 708, and a cassette interface that contacts a disposable PD cassette when the cassette is disposed within a cassette compartment formed between the cassette interface and the closed door 708. A heater tray 716 is positioned on top of the housing 706. The heater tray 716 is sized and shaped to accommodate a bag of dialysate (e.g., a 5-liter bag of dialysate). The PD machine 702 also includes a user interface such as a touch screen display 718 and additional control buttons 720 that can be operated by a user (e.g., a caregiver or a patient) to allow, for example, set up, initiation, and/or termination of a PD treatment. Dialysate bags 722 are suspended from fingers on the sides of the cart 704, and a heater bag 724 is positioned in the heater tray 716. The dialysate bags 722 and the heater bag 724 are connected to the cassette via dialysate bag lines 726 and a heater bag line 728, respectively. The dialysate bag lines 726 can be used to pass dialysate from dialysate bags 722 to the cassette during use, and the heater bag line 728 can be used to pass dialysate back and forth between the cassette and the heater bag 724 during use. In addition, a patient line 730 and a drain line 732 are connected to the cassette. The patient line 730 can be connected to a patient's abdomen via a catheter and can be used to pass dialysate back and forth between the cassette and the patient's peritoneal cavity during use. The drain line 732 can be connected to a drain or drain receptacle and can be used to pass dialysate from the cassette to the drain or drain receptacle during use. The PD machine 702 also includes a control unit 739 (e.g., a processor), a speaker 741, and a microphone 743. The control unit 739 can receive signals from and transmit signals to the touch screen display 718, the control panel 720, the speaker 741, the microphone 743, and the various other components of the PD system 700. The PD machine 702 can receive audio input (e.g., spoken commands) through the microphone 743 and provide audio output (e.g., spoken alarms, alerts, and instructions) through the speaker 741. The control unit 739 can control the operating parameters of the PD machine 702, for example, based in part on the audio input and output. In some implementations, the control unit 739 may be an MPC823 PowerPC device manufactured by Motorola, Inc.

[0120] FIG. 7 is a block diagram of more abstracted generalized representation of a computing entity 10 according to an embodiment of an electronic device. In FIG. 7 the computing entity 10 is shown and explained with several electronic modules. The computing entity 10 may be a computer and/or an embedded device. The computing entity 10 may also be a processor or a processing unit. The computing entity 10 can be implemented in the patient device PaD, treatment machine M or in the provider's device. Usually, in a basic embodiment, the computing entity 10 at least comprises an interface I for establishing a communication connection and the matching module MM. The matching module MM may also be provided at least on part on another entity, e.g. on the provider Pr. Further, the computing entity 10 may be distributed over several hardware units or virtualized, respectively. In the following, some embodiments are described in common, e.g., comprising the modules and checkers 1001 to 1009. For a person skilled in the art, all or a part of these modules may be selected for incorporation and implementation on the computing entity 10.

[0121] The matching module MM is may be a part of a computing entity 10 or distributed to a plurality of computing entities 10. The matching module MM implements a matching algorithm that serves to flexibly associate or match a registered patient Pa and a registered treatment machine M at provider Pr. If a provider Pr only hosts one single machine M, then the matching algorithm matches a registered patient Pa to a provider Pr (which represents the machine M). The matching algorithm matches a first set of criteria relating to the patient Pa (e.g., reachability/nearness, availability of special services etc.) and/or with a second set of criteria relating to the machine M (e.g., if the machine requires patients Pa who know to use the machine M, who have, for instance, a disinfection certificate and a set up certificate).

[0122] The first set of criteria relating to the patient Pa and the second set of criteria relating to the machine M are stored in a database or in a distributed database system. The matching algorithm associates or matches the specific criteria provided by the patient Pa and the machine M. For instance, the patient Pa seeks for a medical treatment opportunity at a specific location in a specific time period. Using the treatment sharing method, the patient Pa may request a medical treatment by providing and/or selecting a location of a medical treatment and a specific time period for the medical treatment. This information is stored in a database. A provider Pr of a treatment machine M and/or the treatment machine M itself operates the medical treatment according to a certain schedule and has the knowledge when the treatment machine M is in use respectively is available. The available times periods can be stored in the database and are thus displayed and/or provided accordingly for incoming requests. With the user request, a query with the corresponding criteria for the medical treatment is started. If the requested time period corresponds to the time period, where a treatment machine M is available, the provider Pr of the treatment machine M and/or the treatment machine M is suggested to the patient Pa. This only represents a possible embodiment for searching an available treatment machine M according to a criterion. It is also possible to combine a plurality of criteria, which have to match before a provider Pr or a plurality of providers Pr are suggested to be selected by the patient Pa. In an embodiment, the patient Pa may specify, which number of total requested criteria has to be matched. In a further embodiment, the criteria may comprise a factor that describes a significance of the criteria for the patient Pa. The significance may comprise a ranking starting from a high significance to a lower significance.

[0123] The matching algorithm may be based on pre-defined criteria, which may be stored in a central database. The pre-defined criteria can be provided to the patient Pa for selecting treatment machines M according to his/her treatment requirements. In this way, standardized criteria are provided. In a further embodiment, the matching algorithm may consider reviews of the patients Pa (for the machine or provider), and/or of the provider Pr (for the patient). The reviews may be based on credit points or assessments of the respective users.

[0124] A verification module 1001 is specifically designed for verifying the matching result of the matching module MM. Generally, a verification is implemented such that another entity and/or another party verifies the matching result, which has been generated automatically by means of the matching algorithm. For instance, it can be defined that a patient Pa needs to input a verification signal on his patient device PaD. It may also be defined that a physician needs to input a verification signal on his physician's device PhD. Further, the provider Pr or the operator thereof may need to input the verification signal. All or a part of the embodiments for the verification may be combined, e.g., that a provider Pr and a physician P or the patient Pa need to verify the matching result. The verification may be based on different criteria, e.g. on a scoring, on another revaluation, on actual conditions and parameters (traffic, availability of resources etc.).

[0125] A scoring module 1002 is adapted for scoring the matching results based on pre-configurable scoring criteria. In a preferred embodiment, the scoring module 1002 comprises different parts or portions which may be implemented on different entities, so that different types of users may give a feedback for the matching result which has been provided automatically by the matching algorithm. For example, first, a patient Pa may score and evaluate the matching result, e.g., after the medical treatment at the treatment machine M has been finished. So, he or she may provide an input how good the selected machine M indeed has fulfilled his personal requirements. Second, a provider Pr may score and evaluate the matching result, e.g., after the medical treatment at the device or machine M has been finished with that patient Pa. The provider Pr may, e.g., score the punctuality and timeliness as well as, e.g., the reliability or other patient-related criteria. Third, a physician P, may score the matching result, after finishing the treatment and after being provided with the sensor measurements after the treatment. For instance, the measurements may indicate that possibly another type of machine M would be better to be used for that particular patient Pa. The scoring may be used by the matching algorithm as feedback for improving the matching effectiveness.

[0126] A certification module 1004 is designed for certifying a provider Pr and/or a patient Pa, participating in the shared medical treatment system. The certification module 1004 thus is directed to different users or entities of the shared medical treatment system, on the one hand the patient Pa and at least on the other hand the provider Pr. Different certification functions may be defined in a preparation phase for configuring the certification. E.g., an augmented and/or virtual reality training certificate, a hygiene training may be provided for providing and training the patient Pa with capabilities for using the treatment machine and for preparing him- or herself for the training. E.g., a self-cannulation test may be defined so that a self-cannulation certificate may be necessary and checked before the patient Pa is allowed to participate in the system. The self-cannulation certificate is an important security feature, as the skills for executing a self-cannulation need to be acquired. The process of cannulation refers to fluidly connecting the patient's bloodstream to the extracorporeal blood circulation. A blood vessel puncture, also referred to as cannulation, is a routinely required step in the medical treatment. Cannulation is performed in the medical practice by physicians or trained personnel. The quality of the vascular access created by the cannulation depends on a large number of parameters, which are characterized, e.g., by the individually and temporally variable abilities of the medical personnel and physical properties of the patients to be treated as well as by the diversity of the technical aids used in the puncture. Therefore, specific skills need to be acquired and proofed by way of a providing a self-cannulation certificate before being allowed to undergo a self-cannulation.

[0127] Certification functions may thus also be defined for the provider Pr, e.g., an eligibility checker certificate, a machine installation and setup certificate, a hygiene audit by a nurse certificate and others.

[0128] A consumable checker 1005 is configured for checking availability of required consumables for the registered patient Pa. E.g., a prescription may define that a patient Pa needs to use a specific type of consumables or disposables, like tube sets, filters, adapters etc. Thus, it has to be assured that this kind of type of consumables is available at the treatment machine M and, e.g., available at the scheduled treatment time. For instance, the consumable checker 1005 may also be configured to check storage of consumables at the local treatment machine M and to replenish stock of consumables, e.g., after each medical treatment. In an embodiment, the consumable checker 1005 may comprise a waste checker. The waste checker is configured to prevent fraud with respect to hazardous waste (e.g., of the filters used).

[0129] A maintenance checker 1006 may be configured for checking required maintenance and repair measures for all the treatment machines M within the provider Pr. Thus, this checker serves to provide an automated maintenance of the treatment machine M and this may in turn lead to an auto block in a hub calendar in case the maintenance checker 1006 has determined that the treatment machine M needs maintenance measures and need not to be used for further treatment. This data is to be collated and synchronized with treatment machine M booking and reservation data (of the scheduling system).

[0130] A prescription checker 1007 may be designed for checking whether prescription requirements may be fulfilled at the selected treatment machine M. This prescription checker 1007 is applied before the matching is done by executing the matching algorithm. In the physician's P prescription, special requirements may be defined for the treatment (e.g., a supervision is necessary, because the patient Pa is not fully capable for self-treatment and needs support by a nurse or medical assistant).

[0131] A transportation checker 1008 may be configured for checking whether transportation services are available for transporting the patient Pa to the selected treatment machine M or for transporting the treatment machine M to the patient's home, abode, or present residence. The transportation checker 1008 may be in message exchange with external services like public transport, private transport organizations and platforms (e.g., uber, my taxi etc.). The transportation checker 1008 preferably is in data exchange with the scheduling module 1003.

[0132] A selection module 1009 may be configured for selecting a preferred medical treatment machine M from a set of suggested medical treatment machines M. In an embodiment, the matching algorithm may generate a matching result with a set of medical treatment machines M for a particular patient Pa, who seeks an appropriate treatment machine M for self-treatment within the sharing system. With other words, the matching algorithm finds several potentially matching treatment machines M. Now, the selection module 1009 executes a selection function for finding the best option within the matching results for the specific patient Pa. The selection function comprises different selection criteria. The selection function may implement the different modules and checkers 1001 to 1009 as mentioned above and/or others.

[0133] In general, all the checkers and modules 1001 to 1009, mentioned above, may be in data exchange with each other.

[0134] The checkers and modules 1001 to 1009, mentioned above, are activated in different time phases: [0135] The verification module 1001, the scoring module 1002, the prescription checker 1007 and/or the selection module 1009 are active after the matching result has been generated by the matching algorithm. [0136] The scheduling module 1003, the certification module 1004, the consumables checker 1005, the maintenance checker 1006, the transportation checker 1008 are executed before the matching result is provided, e.g., during execution of the matching algorithm.

[0137] In a configuration phase the checker and modules 1001 to 1009, mentioned above, may be selected for usage in the shared medical treatment system. Further checkers may be defined, for instance a checker for detecting fraud with respect to the treatment machine M. Thus, special movement sensors (e.g. location-based sensors, GPS or the like) may be provided in the shared medical treatment system at the provider Pr and/or at the treatment machine M in order to detect any movement of the treatment machine M. If any unusual and incorrect movement is detected, a message will automatically be generated and transmitted to the provider Pr or to other external systems.

[0138] FIG. 8 shows a schematic flowchart representing the requesting of a treatment machine M. In step 2001 the treatment sharing method is started, e.g., the patient application PaApp is started that is used for requesting a medical treatment by a dialysis treatment machine M. In step 2009, a calendar can be displayed for the patient Pa at the patient device PaD. Further, the patent application PaApp may provide selection fields or buttons for further input and/or to specify the request and/or query, e.g., filters 2010. Further, in the patient application PaApp, available time slots 2011 are displayed. Additionally, the patient Pa can select the disposable 2012. The disposable selection can be administrated by a disposable module 2021. The disposable module 2021 may provide certified sets 2022. In an embodiment, the disposable module 2021 may prompt 2023 the patient Pa for bringing his/her own disposables, order the disposables with the provider Pr, or deliver 2024 it to specific address that can be entered by the patient Pa.

[0139] After selecting the disposable 2012, the patient Pa or an authorized person has to select the method of payment 2013, e.g., down payment, guarantee, etc. After finishing the payment selection 2013, a specific time slot for performing the medical treatment can be booked 2015. In step 2002 a specific time slot can be selected by a specific provider Pr. In step 2003, a confirmation of the selected provider and/or the treatment machine M is expected. If the selection of the patient Pa is cancelled by the provider Pr or treatment machine M (−) the requesting of a treatment machine M has to be re-started with step 2001 or another provider Pr is selected from a list, what avoids reinput of data. Alternatively, if the selection is not confirmed (−) by the provider Pr or treatment machine M, a reminder can be sent by the patient Pa to the provider Pr or treatment machine M in step 2004. If the reminder is not successful and the requested treatment is cancelled, the requesting of a treatment machine M has to be re-started with step 2001. If the request is confirmed by the provider Pr, the requested time slot with the requested provider or treatment machine M is booked in step 2008. Further, a long-term pre-booking of a medical treatment 2005 can be performed. If the patient Pa wants to repeat the medical treatment continuously, a calendar can be displayed 2016 in the patient application PaApp for selecting timeslots 2017, disposable 2018, and the method for payment 2019. A booking can be performed in step 2020. In step 2006, the provider Pr and/or treatment machine M has to confirm the request. If the requested is confirmed (+), the request time slot is booked for the patient Pa. If the request is not confirmed, a reminder can be sent 2007.

[0140] FIG. 9 shows a schematic flowchart representing a daily check of a patient Pa. The patient Pa has to perform a daily health check 3001 for evaluating his/her health status and to plan future medical treatments. The daily check may comprise a review from preceding medical treatments 3003. Further, in step 3002 the patient Pa can be asked to input specific data on a daily basis. The data can be input by the patient device PaD, and/or via a user interface of the treatment machine M, and/or via the provider device. The daily patient data (vital parameters) 3012 may comprise weight 3013, blood pressure 3014, fluid intake 3015, well-being 3016, take own picture 3017, the body composition index 3018. After the data is input in step 3004, an evaluation can be processed. The evaluation 3004 compares the patient data input with preceding patient data and/or preceding medical treatments (historical data). Based on the evaluation, a hospital visit can be suggested or the patient Pa may carry on with the daily routine. The evaluation may comprise a plausibility test. If the vital data of the patient Pa are out of range (−) a visit in the hospital is recommended 3006. The visit in hospital may comprise further steps, e.g., schedule date at hospital, send patient data to the physician P, and if a dialyses was booked for this day, the time slot at the provider Pr and/or the treatment machine M will be automatically cancelled. Advantageously, these steps can be performed by using the treatment machine M and the sharing enabler and/or the patient application PaApp installed in the patient device PaD. If the vital data of the patient Pa are in range (+), the patient Pa may continue with his/her daily routine 3005. If a medical treatment is booked (+) for that day 3007, the preparation for the medical treatment can be performed 3009. If no medical treatment is booked (−) for that day 3007, the day is off. The patient Pa can e.g., organize new consumables. If the medical treatment is booked 3010, the transportation 3011 has to be provided.

[0141] FIG. 10 shows a schematic flowchart representing the preparation of a medical treatment. In step 4001, the preparation for a medical treatment is started. The embodiment presented in FIG. 10 shows the preparation of self-treatment 4002. The self-preparation 4002 may comprise the measurement of the vital data 4003 (vital parameters). The vital data may comprise weight, blood pressure. The vital data are personal data, which have to be managed and processed in a secure manner. Further, the vital data may be used to train the metabolic model 4008 of the patient Pa. The metabolic model 4008 can be used for a consistency check with the daily input data. In step 4004, the treatment machine M can be setup. In step 4004, a medication can be supplied, if required. In step 4005, the metabolic model can be updated. In step 4007, the prescription can be uploaded and the time for performing the medical treatment can be adjusted.

[0142] Further, in step 4009 the metabolic model, comprising data of the prescription for a specific medical treatment can be adjusted according to the patient Pa, vital data, and/or preceding medical treatments. The adjusted prescription provided by the metabolic model has to be approved, e.g., by a physician P. If the prescription is approved, the patient Pa may use the adjusted prescription 4010 and if the prescription is not approved, the patient Pa may use the original prescription 4011. In step 4012, a self-cannulation can be performed by the patient Pa. After cannulation, the medical treatment can be started 4013.

[0143] FIG. 11 shows a schematic flowchart representing a medical treatment. In step 5001, the medical treatment is started. After starting the medical treatment 5001, the medical treatment is performed for a specific time 5002. While performing the dialysis, the medical treatment is monitored by a watchdog 5003. The watchdog monitors continuously important parameters of the patient Pa and the treatment machine M. The watchdog can be configured to monitor and store specific parameter in a configurable interval. If a complication occurs during the medical treatment 5004, the patient Pa may be informed, respectively alarmed by the patient application PaApp or the treatment machine M. The patient application PaApp used with the patient device PaD or the treatment machine M may provide solutions to remedy the complication. If the patient Pa is able to solve the complications, the medical treatment continues in step 5013. If the patient Pa is not able to remedy the complication, the patient application PaApp or the treatment machine M may provide online help 5006. In this scenario, the patient application PaApp or the treatment machine M may connect the patient Pa to the online help, e.g., a provider Pr, a maintenance service, an experienced person, who can support. If the online help is available and the complication is remedied, the medical treatment continues in step 5013. If the patient Pa is not able to remedy the complication together with the online support, the patient Pa may call a technical support 5007. If the technical support may remedy the complication, the medical treatment continues in step 5013. If the technical support cannot remedy the complication, the medical treatment has to be aborted 5008. In step 5009, an alarm can be activated and a health check of the patient Pa has to be performed, because the required medical treatment has not been finished successfully. In step 5010, an emergency provider E-Pr has to be informed, because a dialysis which was not completed may lead into an emergency situation 5011. Further, if the medical treatment is aborted 5008 and an alarm is active, the physician P of the patient Pa is informed about the medical treatment. All data concerning the aborted medical treatment can be sent to the physician P.

[0144] If the medical treatment runs without any complication 5013, said medical treatment is finished in step 5014. In step 5015 a decannulation is performed. In step 5016, the treatment machine M is disarmed. The vital data of the patient Pa are controlled 5017 and can be sent to the physician P in step 5024. Further, the vital data and data measured while performing the medical treatment can be used to train the metabolic model. The treatment machine M has to be disinfected 5019 and the medical treatment has to be paid 5020. Further, in step 5021 the medical treatment, the provider Pr, and/or the treatment machine M can be rated. The rating can be used to provide a scoring for the selection process. Further, in step 5022 pictures of the treatment machine M and/or the location of the provider Pr can be taken to proof hygiene. In step 5023, the medical treatment is finished.

[0145] Wherever not already described explicitly, individual embodiments, or their individual aspects and features, described in relation to the drawings can be combined or exchanged with one another without limiting or widening the scope of the described invention, whenever such a combination or exchange is meaningful and in the sense of this invention. Advantages which are described with respect to a particular embodiment of present invention or with respect to a particular figure are, wherever applicable, also advantages of other embodiments of the present invention.

REFERENCE NUMERALS

[0146] E Sharing enabler [0147] E-Pr Emergency Provider [0148] E-PrD Emergency Provider Device [0149] H Hub [0150] I Interface [0151] In Input [0152] Out Output [0153] N Network [0154] Pa Patient [0155] PaD-M Patient Device Module [0156] PaD Patient Device [0157] PaApp Patient Application [0158] P Physician [0159] PhD Physician Device [0160] Pr Provider [0161] S1-S4 Method steps [0162] UI User Interface [0163] 1001-1009 Modules and Checker [0164] M Machine [0165] S Sensor [0166] 10 electronic module [0167] 2001-2024 steps for requesting [0168] 3001-3018 steps for check [0169] 4001-4013 steps for preparation [0170] 5001-5024 steps for medical treatment