Medical treatment system with a device for supplying patient-related data

[0001] The present invention relates generally to a medical treatment system with at least one device for carrying out a medical treatment and a device for supplying patient-related data, as well as, in particular, an extracorporeal blood treatment system, specifically a dialysis system with at least one dialysis device and a device for supplying patient-related data.

[0002] DE 10 2004 011 264 A1 discloses a plurality of patient stations incorporated with a central server, so that the treatment of each patient can be monitored and adjusted from one doctor's station. A dialogue between the doctor's station and the individual patient stations is possible via the data network. Further interconnected dialysis systems are known from EP 1195708 A1 and WO 2001/37899 A2.

[0003] A common feature of the dialysis systems of the prior art is that patient-related data that can be loaded from the individual treatment devices are supplied on a central server. In addition, patient-related data that are fed into the treatment device can be stored on the central server.

[0004] Because of the stringent safety requirements in medical engineering, very high safety demands are imposed on the data transfer between the treatment devices and the server in order to eliminate both operating errors and malfunctions of the medical treatment system.

[0005] One aspect of the present invention is a medical treatment system, in particular a dialysis system, which provides the operator with comprehensive information on the medical treatment, and safely eliminates input errors and malfunctions.

[0006] The input/display device of the present invention is designed so that machine-related data sets are displayed in a treatment mode and patient-related data sets are displayed in a patient mode. “Machine related data sets” are defined as all data that relate to the machine control system, for example the feed rates of the blood and dialyzing fluid pump, the ultra-filtration rate, etc. “Patient-related data sets” are defined as all data that has no influence on the control of the treatment device and serve only as information for the operator.

[0007] The input/display device of the medical treatment system according to the present invention is characterized by a plurality of means for entering and displaying different groups of patient-related data. Each means for entering and displaying a group of patient-related data exhibits means for displaying a plurality of data sets and means for selecting one or more data sets from the plurality of data sets. It is therefore possible to select the data sets required for the treatment from predetermined data sets without having to enter the data sets each time. Moreover, each means for entering and displaying a group of patient-related data exhibits means for displaying one or more of the selected data sets. It is therefore possible to automatically document the data sets selected during treatment for an operator.

[0008] In one embodiment, the input/display device is designed as a touch screen for entering and displaying the patient-related data, wherein the means for entering and displaying the different groups of patient-related data are pages that can be represented on the screen, containing fields that can be individually selected.

[0009] The data transfer takes place between the treatment device and a device for supplying patient-related data that has a facility for storing patient-related data. A group of patient-related data may, for example, incorporate a plurality of data sets that provide the operator information on the type and execution of the treatment. For example, information on the medications administered during the treatment, or medications prescribed for the treatment, as well as results obtained and actions initiated during treatment can be provided. This patient-specific data can be individually displayed to an operator.

[0010] In a further embodiment of the medical treatment system, different groups of patient-related data can be selected from a plurality of data sets, and means for inputting one or more data sets, which can be assigned to the selected data sets and displayed, are provided. An operator is therefore able to enter additional information relating, for example, to the method of treatment and treatment process, the medications administered, and the results obtained and actions initiated, so that this information is available to an operator in subsequent treatments. At least some of the data sets selected can preferably be stored with the storage device, so that the data sets are permanently available to an operator.

[0011] In patient mode, a patient-related display area is preferably only defined for displaying patient-related data sets. This display area serves exclusively to inform the operator about the patients, but does not allow control of the treatment device. In a preferred embodiment, the patient-related display area forms part of the screen of the treatment device, and can be designed as a touch screen.

[0012] When data are transferred from the device for supplying the patient-related data to the individual treatment devices there is a risk that the data sets may not be fully represented. To avoid operating errors or incorrect information the input/display device is provided with means for determining whether a patient-related data set can be represented within the limits of the patient-related display area without overlapping a data set already displayed, thereby preventing the data sets from being displayed if the limits are exceeded or overlap. This ensures that an operator is not provided with only partial information, which could result in incorrect conclusions.

[0013] The medical treatment system is also characterised by means for cyclic interrogation of patient-related data which indicate when new patient-related data are supplied from the device for supplying the patient-related data. If only machine-related data sets are displayed in the treatment mode, the operator is still informed of the presence of new patient-related data. The operator may then call up the patient mode to display the patient-related data sets and process them if necessary.

[0021] FIG. 1 shows the essential components of an extracorporeal blood treatment system, in particular a hemodialysis system, in a highly simplified diagrammatic representation. The dialysis system incorporates a plurality of dialysis devices, 1, 1′, 1″ and a device 2 for supplying patient-related data, which are connected to each other by a network 3.

[0022] The device for supplying the patient-related data 2, for example, a server, is provided with a device 2A for storing the patient-related data, e.g., a hard disk memory, and a device 2B for entering the patient-related data, for example, a PC with screen and keyboard.

[0023] The individual dialysis devices 1, 1′, 1″ are each provided with a machine part 1A and an input/display device 1B. The input/display device is a screen preferably designed as a touch screen with which both machine-related data for controlling the dialysis device and patient-related data can be entered and displayed. Machine part 1A of the dialysis device exhibits a central control unit for controlling the individual machine components.

[0024] FIG. 2 shows the screen surface of screen 1A of dialysis device 1. The screen surface is divided into a central display region 10 and a status bar 11, which can be located at the upper edge of the screen, and a menu bar 12, which can be located at the lower edge of the screen. The limits of the central area 10 are represented by dotted lines in FIG. 2. Status bar 11 and menu bar 12 each exhibit a plurality of selectable fields or buttons that can be selected with the finger or a cursor.

[0025] The operator may select either the treatment mode or the patient mode on the screen. FIG. 2 shows the treatment mode in which machine-related data can be entered and displayed. In this mode, for example, the parameters predetermined for the treatment can be entered for the central control unit of the dialysis device.

[0026] The patient mode, in which patient-related data can be entered and displayed on the screen, represents a function that is fully independent of the treatment mode. Inputs and displays in the patient mode therefore have no influence on the dialysis treatment and serve as information and documentation only.

[0027] The input and display of patient-related data in the patient mode takes place within the central display range 10, so that status bar 11 and menu bar 12, together with the left and right display areas 13, 14, in which further machine-related data, e.g. the arterial and venous blood pressure and the blood flow, can be represented, remain visible.

[0028] The patient-related data are loaded from server 2 of the dialysis system. Since the data are supplied centrally, changes and adaptations to customer requirements are possible and can quickly be made. In the patient mode, dynamic, interactive program sequences may take place which are not stored in the dialysis device but are loaded from the server. Since the program sequences in the dialysis device run in isolation from the machine control, they cannot influence the medical function of the dialysis device.

[0029] The interactive program sequences serve to represent the patient-related data on the screen in patient mode, e.g. laboratory data. Moreover, inputs by the operator are also possible. As a reaction to the inputs, the server can transmit further data to the dialysis device, thereby allowing specific user guidance.

[0030] The interactivity of the program sequences is achieved by screen pages which are loaded dynamically from the server and whose structure follows a page description language. Communication between the dialysis device and the server takes place with the protocol HTTP or HTTPS, the content of the pages being described in HTML. The page descriptions contain information on the control elements to be displayed on the screen, their attributes, where they are positioned, and how they are to react to user inputs.

[0031] The simplest form of a program sequence is the representation of a screen page generated by the server, with none or very few possibilities of data input by the operator. This page is selected via a menu point, for example, and closed by means of a button.

[0032] A complex program sequence may contain a sequence of screen pages whose order and content are established according to operator inputs. Interactive help or training pages whose sequence is controlled by the buttons are examples of this.

[0033] An even more complex program sequence enables patient-related data inputs to be received in the server using data which are made available elsewhere, e.g. from a dialysis data bank or by measured data acquisition from the dialyzer itself, in order to execute a calculation algorithm and therefore calculate medically relevant parameters which may be relevant to the present or future treatments of the patient.

[0034] The function of the screen in the patient mode is explained in greater detail below with reference to examples.

[0035] At predetermined intervals, the dialysis device asks the server cyclically whether new patient-related data is available. If this is the case, a patient button 15 bearing the name of the patient flashes in status bar 11 of the screen if the treatment mode, not the patient mode, is activated. The patient mode does not open until the operator selects the patient button 15. In any case, it is ensured that the operator is informed of all the safety-relevant data at all times.

[0036] The patient-related data defines graphic elements which can be displayed on the screen. FIG. 3 shows the screen surface in the patient mode. The graphic elements can be positioned by the server anywhere within central display area 10 (FIG. 2). Before the patient-related data appears on the screen in the patient mode, it is determined whether a display of the individual graphic elements is possible within the predetermined limits of the central display area 10 without overlapping elements already displayed. If this is the case, the display of the elements is prevented. Otherwise, the elements appear in the central display area of the screen. This ensures that there is no display until all the relevant information is available, thus excluding the possibility of misinterpretation of the displayed contents.

[0037] The graphic elements are first positioned virtually according to the position information in the HTML page description. Here it is determined, for each element, whether the position has not already been reserved for another element and whether the element lies fully within the central display area. Not until then is the position for this element released. However, if the position is already occupied, the page is not displayed and an error message appears on the page. In this case, the rest of the screen remains operable. Not until all the elements have been positioned successfully and virtually without collision is the complete page displayed.

[0038] To avoid malfunctions, only the graphic elements which are known to the dialysis devices are displayed on the screen, for which purpose the HTML elements are provided with a so-called class attribute. Before the individual elements are displayed on the screen it is determined whether the elements are provided with a class attribute. In this case, only the elements which are provided with a class attribute are displayed. On the other hand, elements without a class attribute are ignored. If the server is provided with a more recent software version than one of the dialysis devices, elements with unknown class attributes could be available. These elements with unknown class attributes are not displayed, preventing malfunctions. However, the user is alerted.

[0039] In the patient mode, different groups of patient-related data are displayed on different pages. The different groups include, for example, the treatment carried out, the prescribed medications, messages, and events or actions. The individual pages can be called with the finger by pressing the corresponding button on the upper edge of the pages. FIG. 3 shows the event page. Each page contains a plurality of data sets which include, on the event page, for example, the prescribed medications, e.g. Medication 1, Medication 2, Medication 3, etc., or different events, e.g. headaches, etc. These data sets are grouped into individual lists 16, 17, 18. If an event occurs during the treatment, the event can be documented with the time and an appropriate action by selecting the appropriate button.

[0040] The menu selection for the display and documentation of events and actions is described in further detail in the following with reference to FIGS. 4A to 4G. For example, the operator selects “Event 6” from the event list 17 of different predetermined events. This text is then highlighted, for example in green. Instead of an event the operator may now also select an action. If the operator has first selected an event, an action can now be selected.

[0041] For example, the operator selects the action “Medication 3, unit” from action list 16, thus the administration of a certain medication is selected from the list of medications. The operator then opens a new page (FIG. 4G) on which the number of units administered is entered. For example, the operator enters 5 units by pressing the corresponding button 5. The operator then returns to the previous page. The action “5 Medication 3, unit”, is now highlighted, for example in green. The entered data set “5” has been assigned to the selected data set “Medication 3, unit”.

[0042] After the inputs are confirmed the selected events and actions are displayed in a list 18 of stored events (Event History), with indication of the time of input (17:07). The text is given a colored background, for example blue. The operator can confirm this display by pressing the “OK” button. The text is now underlined, for example in grey. It is also possible to remove the events and actions shown in the “Event History” from the “History” by pressing the “Remove” button.

[0043] The patient mode therefore allows the assignment of certain events and certain actions to be selected, which can be stored in sequence for documentation. Here the data sets are stored in server 2, independently of the individual dialysis devices 1, 1′, 1″. The operator is therefore informed of the events and actions that have already taken place before new events and actions are selected. For example, it is indicated to the operator, before he inputs the event “Event 6” and the action “5 Medication 3, unit”, that the patient already had headaches and that medication 1 was already administered. The combination of the individual data sets from which the operator may make a selection, and the documentation of the data sets, increases the safety of the dialysis treatment.

[0044] If the operator selects the “Medications” page from among the different groups of patient-related data, a new page appears. FIGS. 5A to 5E show a flow chart to explain the logical sequence of the operation after the “Medications” page is called. The operator may make a further selection from within this group under a plurality of data sets. For example, the operator may select the desired medication, for example, Medication 3, Medication 4, or Medication 5, from the list of available medications loaded on the device to supply patient-related data. The text of the selected medication is now highlighted, for example in green. The operator may now accept or reject the selected prescribed medication by pressing the “Reject” or “Accept” button. If the operator accepts the medication selected, the medication is displayed under the list labeled “Medication History” and identified with a checkmark. If the operator rejects the medication selected, the medication is displayed under the list labeled “Medication History” and identified by an “x”.

[0045] After confirmation with “OK”, all entries in the “Medication History” list are taken over for documentation and stored in server 2, independently of the dialysis device. On the other hand, if the user quits the patient mode, all the selected inputs will be lost. If the “Medication” page is called again later, the patient-related data sets are loaded so the user is able to follow the progress of the treatment. For example, the user can see from the information displayed that medications 1 and 5 have been administered but medication 2 has not.

[0046] In addition to the display and documentation of events and actions, as well as the administration of medications, the server also makes patient-related messages available to the user of the individual dialysis devices. Messages can be stored in the dialysis system for each patient. These messages are entered centrally using the input device 2B of the device for supplying the patient-related data. For example, the messages are entered with a keyboard or read in on a data carrier. The messages may also be made available by other external devices not shown, which communicate with the server. FIGS. 6A to 6C show a flow chart to explain the logical sequence of the operation.

[0047] When the treatment mode is called, the patient button 15 flashes in status bar 11 when new messages are received. The operator may then activate the patient menu and select the “Messages” page. To read the messages, the operator presses a button displaying the title of the message, which opens a new page displaying the text of the messages with an indication of the time they were entered. By pressing the “Confirm” button the operator confirms reading the message. Otherwise, the operator closes the page by pressing the “Close” button.

[0048] After the operator confirms reading the message, the title of the message in the list of messages disappears. The title of the message now appears in the “Message History” list, with an indication of the time at which the user read the message. All the previously read messages also appear in the list. The operator can now open more unread messages, in sequence, and can store them for documentation with an indication of the time.

[0049] To avoid errors in documentation, all the contents of the pages are called several times, preferably at least three times, by the server and represented in different operating stages before they can be stored in the data bank of the server. The embodiments show that each element must first be selected, the selection then confirmed and the confirmed selection will finally be incorporated in the “History” list. The risk of incorrect inputs is thus reduced by the multiple confirmation stages.