WO2010057557A2 - Patientenverwaltungssystem mit intelligenter schnittstelleneinrichtung zur übertragung medizinischer daten - Google Patents

Patientenverwaltungssystem mit intelligenter schnittstelleneinrichtung zur übertragung medizinischer daten Download PDF

Info

Publication number
WO2010057557A2
WO2010057557A2 PCT/EP2009/007538 EP2009007538W WO2010057557A2 WO 2010057557 A2 WO2010057557 A2 WO 2010057557A2 EP 2009007538 W EP2009007538 W EP 2009007538W WO 2010057557 A2 WO2010057557 A2 WO 2010057557A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
management system
patient management
keyboard scan
interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2009/007538
Other languages
English (en)
French (fr)
Other versions
WO2010057557A3 (de
Inventor
Jürgen LINGMANN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
P&L EDV SYSTEME GmbH
Original Assignee
P&L EDV SYSTEME GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by P&L EDV SYSTEME GmbH filed Critical P&L EDV SYSTEME GmbH
Priority to CA2744131A priority Critical patent/CA2744131A1/en
Priority to EP09748996.7A priority patent/EP2356600B1/de
Priority to US13/129,895 priority patent/US20110264468A1/en
Publication of WO2010057557A2 publication Critical patent/WO2010057557A2/de
Publication of WO2010057557A3 publication Critical patent/WO2010057557A3/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H30/00—ICT specially adapted for the handling or processing of medical images
    • G16H30/20—ICT specially adapted for the handling or processing of medical images for handling medical images, e.g. DICOM, HL7 or PACS

Definitions

  • Patient management system with intelligent interface device for the transfer of medical data
  • the present invention relates to a patient management system and method, and an associated interface device for improved communication with patient management software.
  • patient management systems are used, which are implemented on a computer. These patient management systems are used to collect basic personal data such as name, first name (s), date of birth, gender, health insurance and a unique patient number. Furthermore, anamneses, findings, diagnoses, therapies and other procedures can be recorded. In addition, it is possible to generate and print recipes and transfers from these patient management systems, for example.
  • a medical device such as an X-ray or ultrasound device
  • data interfaces For data exchange between a medical device, such as an X-ray or ultrasound device, there are designed for this purpose data interfaces. Initially, physical disks such as floppy disks served to move the data from one device to another, but these were then displaced by other communication media, such as wired or wireless communication over network connections. These data interfaces are based on a defined standard, such as the ADT, GDT, BDT or HL7 standard. These interfaces are unique to the particular end-user software, i. In the case of the respective patient management program, different implementations have been implemented, since only a few of the cutaneous parameter parameters are bindingly defined (so-called mandatory fields).
  • Such a patient management system is known from DE 100 50 087 A1.
  • a database is provided here, on which already collected data are stored, including data obtained by medical measuring devices. Doctors connected to this central computer can then retrieve this data on their PC.
  • the aim of the technique described in this document is to improve the organization and communication between scattered physician practices.
  • a patient management system comprises a device which executes a patient management system program, a data source for providing medical data and an interface device, which is integrated between the device and the data source and receives data from the data source, in keyboard scanning systems. Converts codes specific to the patient management system program and outputs these keyboard scan codes to the device.
  • An interface device is arranged to be connected between a device which executes a patient management system program and a data source for providing medical data and receives the data from the data source, converts these into keyboard scan codes corresponding to the patient used - DMS are specific to, and outputs these keyboard scan codes to the device.
  • a method of the invention comprises receiving medical data from a data source for providing medical data, converting the medical data into keyboard scan codes specific to the patient management system program, and outputting the keyboard scan codes to the device.
  • Fig. 1 shows a schematic overview of the structure of the data interface.
  • Fig. 2 shows the schematic structure of the patient management system according to the invention.
  • FIGS. 3A and 3B show a flow chart of the method according to the invention.
  • the invention relates to a patient management system in which an interface device between a device that executes a patient management system program and a data source for providing medical data is integrated and receives the data from the data source, this in for the patient management system- Program specific keyboard scan codes are converted, and these keyboard scan codes are output to the device.
  • the device that executes the patient management system software may be a commercially available personal computer, but it is also conceivable that much more powerful server computers are used.
  • the advantage of using more powerful server computers is that they can handle increased data traffic in the event that the patient management system program is used in a hospital, clinic, or large-scale medical practice.
  • patient management system programs for example, programs such as MEDISTAR or PDE-TOP can be used.
  • Such computer programs also known by the term medical software, support the management, organization and operation of medical practices.
  • the functionality of such medical software includes patient administration, card indexing, document management and billing with health insurances.
  • the connection of electronic devices to this software is possible, for example, to enter the data stored on an insurance card via a card reader in this software. It is also possible to transmit findings electronically.
  • the interface device or data interface DS is connected between the device, which executes the patient management software and a data source, and receives data, in particular patient data, from the data source.
  • the data can be transmitted from the data source to the interface device via a defined GDT interface, this has the advantage that in the field of medical informatics such interfaces are frequently encountered and accordingly have very many data sources via this interface.
  • ultrasound devices or X-ray devices are equipped with a GDT interface, which enables a fast and efficient data transfer, at least of the basic data.
  • the basic patient data is transmitted via GDT, which sends image data via an interface according to the Dicom (Digital Imaging and Communications in Median) standard.
  • the medical data may be input via an input device that is specially configured to enter medical data.
  • an input device can be a personal computer or a laptop or a tablet PC which has a graphical input interface, which has the advantage that the input can be made in a time-saving manner via a graphical input interface, since the graphical interface available on a graphical interface Buttons are easily recognizable and clickable, which increases the input speed.
  • the input device is equipped with a touch screen, the input can be made not only by means of a mouse and keyboard, but by using the finger or a stylus provided for this, which allows an even faster and more intuitive operation of the input.
  • the data thus entered are, as described above, transferred via an interface provided for this purpose to the interface device.
  • the interface device converts this data into keyboard scan codes, which are output to the connected device for input to the patient management system program.
  • Keyboard scan codes in computer technology are data sent to it by the keyboard of a computer when a key is pressed or released.
  • the keyboard scan codes to be used are usually dependent on the patient management software used.
  • the interface device is informed of the software used, and the interface device can determine from a table which set of keyboard scan codes are needed for this software and can then use them accordingly. This has the advantage that the interface device can be adapted quickly to a changed patient management system software.
  • the functionality of the interface device may, in some embodiments, be programmed in an OS-independent programming language, such as TCL, such that the interface device is independent of the selected operating system, which is particularly advantageous when in a practice different operating systems, such as Windows, Linux and Mac OS are used. Due to the independence of the data interface ⁇ from the selected operating system, then the operation and the look-and-feel, i. the user experience, always the same, which eliminates the familiarization phase for operating the software.
  • OS-independent programming language such as TCL
  • the interface device is independent of data structure changes that may result from updates / updates of the end-user software. If the communication between the interface device and the patient management system program by means of a predefined interface, such as the GDT interface done, would usually change the input interface of the patient management system in a program update and an update of the interface device would be necessary. As a rule, the provider of the patient management system program does not disclose the data structure of the input interface to make it difficult for the competition to adapt to a changed data structure, a modified data structure of the device interface would have to be reconstructed, for example by a so-called reverse engineering, which involves a very large amount of time.
  • a predefined interface such as the GDT interface done
  • the combination of keyboard scan codes for communicating the input to the PVS program has the advantage that one can exploit just this constancy of the structuring of the graphical input mask.
  • the interface device still has some inherent intelligence in some embodiments, i. the data interface is able to classify the different received data and enter it correctly in the end user software.
  • the interface device is able to classify the received data into basic categories, whereby the basic categories may include medical history, findings, diagnoses, ICD codes, therapies, procedures, billing codes and forms.
  • the enumeration of the basic categories is not exhaustive and can be expanded as desired. This has the advantage that a dynamic adaptation to the respective requirements of the user is possible. For example, a specialist in orthopedics has different demands on the categories used than a cardiologist or a dermatologist.
  • the interface device of the present invention uses information transmitted along with the data.
  • the basic category may be defined by a prefix prefixed to the actual patient data.
  • a blood pressure value provided by the data source may be identified by a prefix "RR".
  • RR blood pressure value
  • the systolic value corresponds to the internal pressure of the vessel during dilation of the vessel
  • the diastolic value corresponds to the internal pressure of the vessel during contracting, which is why the systolic value is always greater than the diastolic value.
  • the measured values are 140 and 90, they can be passed through the data interface using the string "RR 140/90".
  • RR is the common abbreviation for Riva-Rocci, an Italian doctor who first used the arm cuff to measure Blood pressure and to whose memory the abbreviation "RR” was introduced.
  • the abbreviation "BD” could be used for "blood pressure” or "BP” for "blood pressure”.
  • the interface device determines that a character string ⁇ is started which begins with "RR”, it can thus be recognized as a blood pressure value. Since the operator of the PVS program knows in which part of the input mask blood pressure value ⁇ is to be entered, it is possible to use the keyboard scan codes to control the correct input field and to enter the blood pressure values there.
  • Determining the category associated with the provided data allows the interface device to verify this data. For example, again using the previously described blood pressure value, the data interface may check if the first value corresponding to the systolic blood pressure value is greater than the subsequent diastolic value. If this is not the case, it can be assumed that the data provided is faulty, and it is then possible to issue a corresponding warning message to the user of the PVS system. This has the advantage that incorrect entries can be detected in a timely manner, as a rule immediately after the examination of the patient. If there is a data inconsistency between the diagnosis and the billing numbers, for example, when settling with the health insurance, which can be a few days or weeks after the examination of the patient, it is usually no longer possible to correct this error.
  • the interface device can check the plausibility of the data by means of a set of rules.
  • the interface device checks the data by means of a set of rules before this data is forwarded to the end user software, for example it checks whether the ICD codes collected match the diagnosis to the drugs or if the site localizations in the diagnoses (eg right or left knee) to the site locations of the OPS keys selected at the digits.
  • This has the advantage that such an inconsistency within the data set can be detected in good time, especially with a view to avoiding such medical malpractice. If, for example, a diagnosis was made on the right knee on the basis of an X-ray image, but later surgery is planned for the left knee, the patient management system according to the invention can promptly output a corresponding warning or error message.
  • This interface of the PVS program is typically a graphical input mask that has a plurality of input fields and in which the user can enter the patient information.
  • Most of the currently available PVS programs are advertising-financed, which means that as data is entered into the program input interface, it basically opens up unwanted advertising windows or other advertisements. In certain cases, for example, if the patient has been diagnosed with a migraine disorder, a commercial ad that recommends a particular migraine medication to the physician may be made.
  • the input of the medical data in some embodiments takes place via a further data source, this avoids the advertising-related interface.
  • an advertisement in the form of an additionally opening window will cause the input focus to change, i. After opening the advertising window, the input focus is no longer the previously selected input field of the interface, but is the advertising window with a corresponding button for acknowledging this advertising window. Therefore, in some embodiments, the data interface or interface device according to the invention is set up to detect such a change of focus and to react accordingly. Such a corresponding response to a commercial insertion could include, for example, acknowledging the advertising window and then resetting the input focus to the last input field visited.
  • the interface device is configured to query from the device where in the current focus window the input may currently be made.
  • the current focus window usually has several input fields in which, for example, the patient name, prefix, and measured blood pressure can be entered. Each of these input fields has a unique ID for identification and this ID can be queried to determine which input field is currently active. If, for example, an error message was generated when entering the basic patient data and the entry was thus interrupted, it is not possible to trace directly at which entry field the interruption occurred. By querying the ID of the input field, it is possible to determine where the input can be continued.
  • the input mask does not have to be reset in order to put it in a defined state and then to send the data completely again, but that the input of the data can be continued while reducing the required data transmission bandwidth.
  • the input field can also be checked in terms of content. For example, the input field into which the date of an examination is inserted can be checked to see if the date corresponds to the current date or the date of the examination.
  • the interface device is set up to store the transferred data in any, modularly controllable database.
  • any, modularly controllable database This has the advantage that, if it is necessary after one of the previously discussed aborts or error messages to send the data again, this data can be used.
  • the storage of patient data can be taken into account any incompatibilities between the currently prescribed drugs and previously prescribed drugs. For example, if it is determined that the patient has previously been prescribed a blood thinner, and the same patient is currently prescribed a painkiller that can also cause blood thinning, a warning may be issued to increase the effects of these two drugs. In other cases, it may be considered that the efficacy of some antibiotics undesirably affects the efficacy of some contraceptives, and a warning may be issued.
  • an SQL database may be used in some embodiments.
  • the data interface 100 receives medical data via an interface 105 provided for this purpose, which in certain embodiments is a GDT interface.
  • the data interface ⁇ comprises a data validation module 110.
  • This data validation module is arranged to overwrite the received medical data, category by category. Hereby a syntax check takes place. If the structure of the received data does not correspond to the expected syntax, a corresponding error message can be output and the user can correct the input.
  • the data validation module may self-correct syntax errors, for example, a blood pressure value "RR 90/140" is received, but the syntax to be applied requires that the first value be the larger, the data validation module may exchange the two numerical values.
  • the data validation module obtains the syntax information and other rules from a table 115. In this table, expected categories and digits are stored and associated rules, and the underlying syntax is stored in tables. Likewise, ICD codes are in Table 115.
  • the interface device further comprises a data storage module 120.
  • This data storage module stores the received patient data in a memory unit provided therefor.
  • this dedicated storage device is a database 130.
  • This database may be separate from the interface device, for example, it may reside on a database server. In particular, in certain embodiments, this database may be an SQL database suitable for these purposes.
  • the interface device of FIG. 1 further shows a data evaluation module, which in certain embodiments is embodied in the interface device.
  • This optional data evaluation module 140 is capable of forming a patient score based on a look-up table 145 and taking into account the existing patient data.
  • This patient score is a measure of the likelihood of a specific disease of the patient.
  • the patient score includes age, gender, body weight, blood pressure history over a period of time, existing diagnoses, and recent findings. All of these factors are provided with weighting values that may be empirically determined, and these weighting factors are summed up. This patient score can be compared to one or more predefined values.
  • a message may be generated that recommends prescribing a particular drug to the patient or recommending a particular therapy. Lies the patient score above another, larger value may be recommended to refer the patient directly to a hospital.
  • the patient score is not formed by the interface device, but may be input to the interface device from the outside, for example, by the aforementioned care engine.
  • an error handling module 160 This error handling module queries appropriate programming interfaces of the operating system if an error message has been generated. If such an error message has been generated, it can be clarified whether the PVS program has generated the error message or whether the error message was generated by the operating system. If it is an error message generated by the operating system, it can be displayed to the user so that he can handle the operating system-specific error accordingly. However, if the error message has been generated by the PVS program, it requires a further analysis by the interface device, because an error message of the PVS program can be caused for example by an incomplete or incorrect data input. In this case, the error code output together with the error message is evaluated. If the error code indicates that the data transferred to the PVS program does not match the expected data, all data belonging to the currently transferred category can be resent.
  • the interface device accesses a buffer memory 125.
  • This buffer memory is connected to the data storage module 120.
  • the data intended for output may be stored in its entirety, but may also be stored in categories, or there may be only one category of the data in the buffer. This has the advantage that a renewed manual input of the data is not required, but it is also the data in the buffer memory can be accessed.
  • the data interface comprises a data conversion module 150.
  • This data conversion module converts the received medical data into keyboard scan codes. For this purpose, it is determined by means of the category associated with the respective data in which part of the input interface of the PVS program this data must be entered, and corresponding control codes are generated. For example, it is possible to tab between the individual input areas by means of a tab key For example, one or more keyboard scan codes corresponding to the entry of a tab key may be inserted. This information can be found in an assignment table 155.
  • This allocation table or keyboard scan code table assigns a keyboard scan code to output characters, that is to say that characters as well as control characters are output in coded form using the keyboard scan codes.
  • the keyboard scan code table still includes the unique IDs previously discussed that are used to identify and query the input fields. These IDs are linked to their respective categories in the keyboard scan code table. This has the advantage that the IDs of the input fields which are to be activated when transferring the data of a specific category are immediately available.
  • the data conversion module converts the received medical data in certain embodiments into keyboard scan codes by category, this has the advantage that if the data transmission fails, only the last transmitted category needs to be retransmitted / whereby transmission bandwidth can be saved.
  • the keyboard scan codes generated category by category are stored in the buffer memory 125 category by category in certain embodiments.
  • the interface device further comprises a data export module 190, which is set up to extract the data stored in the database 130 from this database, to prepare this data in whole or in part for export, and then to send these data in the form of Export data 180.
  • the processing of the data from the database is carried out in compliance with certain export rules 195.
  • certain export rules 195 may be specified in the Exportregel ⁇ that the data may be output only canceled, in this case, the data is given without information from patient names, and instead of the patient name, for example an arbitrarily dialed number can be issued, which makes it impossible to deduce the respective patient.
  • Such exported data could be passed on to a corresponding API of the device running the patient management system program, so that this device then sends this data via e-mail to a so-called Car ⁇ Engine.
  • a carbene engine is used to express a treatment recommendation based on the patient data in order to make it easier for the attending physician to work out a treatment plan.
  • This work can be time-saving taken over by a dedicated Care Engine, which in turn Issues a treatment recommendation.
  • a care engine may be configured to send a patient score to the interface device as an alternative or in addition to the treatment recommendation.
  • the export data 180 may, in certain embodiments, be sent to a utility research system rather than a care engine.
  • Such care research systems use anonymised data to statically examine the efficacy of different drugs across a large population of patients. If a doctor participates in such a service research program, this is associated with a double-entry of the data, since the patient data must be entered into a PVS program, but there is no practical way to get these data back from the PVS program to extract. Therefore, the patient data must be entered twice so that they are entered not only in the PVS program but also in a utility research program. This duplication of data typically discourages participation in such a care research program.
  • the interface device according to the invention offers the advantage, in certain embodiments, that such duplicate data acquisition is no longer necessary, and moreover offers the advantage that such an export of data can be accomplished via the optional data export module without noticeable additional expenditure.
  • the data interface has an output interface 170 which outputs the data converted into keyboard scan codes to the device executing the PVS program.
  • the generated keyboard scan codes are injected into an API of the target computer, which means that the target computer interprets the injected data as key strokes
  • the error handling module is able to reset the data acquisition of the PVS program to a defined state. That is, the corresponding keyboard scan codes, ie keyboard commands, are sent to the end user software. sends that cause the PVS program to reset the input interface to a defined initial state from which data input can occur.
  • FIG. 2 shows a schematic overview of the inventive patient management system.
  • the computing device 230 i. the device executing the PVS software includes an operating system 232, the PVS software 234, and a programming interface API 237.
  • the system further includes the interface device or data interface DS 220 and the data source 210.
  • the data source is connected to the interface device 220 communicatively coupled so that the interface device may receive data from the data source, and so that in certain embodiments the data source may receive error messages generated or relayed by the interface device.
  • the data source may be, for example, a medical device with a GDT interface or also a graphical input device, such as a medical tablet PC.
  • the input interface handles the data provided by the data source as previously described in connection with FIG.
  • the input interface outputs the data, the programming interface 237 of the computing device 230.
  • the computing device 230 may further be connected to a keyboard 240, a mouse 242, and a card reader 245.
  • the card reader 245 is integrated with the keyboard 240.
  • the computing device has a wide interface 239 that allows the computing device to communicate with other computers.
  • interface 239 may be a network interface that allows data to be transferred over communication protocols, such as TCP / IP.
  • the computer device can be connected via this network interface to the aforementioned defragmentation server, or else to a care engine or, in the simplest case, to other computer devices which are part of a computer network, for example in a practice or a hospital.
  • FIG. 3 schematically shows a method according to which embodiments of the inventive patient management system can be operated. As is clear from the previous description, not all steps of the described method are essential to the invention and are therefore to be regarded as optional.
  • step 305 the transfer of basic patient data to the input interface takes place.
  • this basic patient data is checked, for example, whether the patient already exists in step 315. If the patient is not yet available, this patient is included in Step 318 newly created. Thereafter, new patient data is received in step 320. This happens, for example, via the previously discussed GDT interface.
  • step 325 the categories of the received data are checked, for example, using a category or a number table.
  • step 330 the syntax of the received data is checked, for example, using an ICD code table.
  • step 335 in certain embodiments, the value ranges ⁇ of the received data are checked against a value range table, and possibly corrected.
  • step 340 a plausibility check of the received data is performed based on a comparison of the ICD cods, the OPS keys, digits, or drug lists. For example, a comparison of page localizations in the ICD codes and the billing digits can be performed here.
  • a patient score is determined, in step 350, this patient score is compared to a threshold. Although only comparison with a threshold is shown here, in some embodiments, multiple threshold comparisons are possible. If the patient score exceeds this threshold, a referral message is generated that recommends a particular treatment for the patient. The determination of the patient score is usually done by adding up individual weighting factors that depend, for example, on sex, age or blood pressure.
  • step 360 the data is stored in a database.
  • the patient data are transferred category by category to a target software.
  • the data of a category is prepared for transfer to a patient resiliency software.
  • the data is converted to keyboard scan codes using a Scan-Cod ⁇ table.
  • Step 365 in some embodiments, although not shown in the figure, also includes the intermediate buffer of the keyboard scan codes in an intermediate buffer memory.
  • the ID of the input field to be input flows further to ensure that the input is made using the correct input field. This ID is requested from the keyboard scan code table. This can be achieved, for example, by comparing the ID in the keyboard scan code table with the ID of the current input field.
  • the transfer of the prepared data takes place.
  • step 375 it is checked whether an error has occurred during the transfer of the data. If so, it is checked in step 380 if a focus change has occurred. If so, in step 385 the focus is corrected or reset. If not, the data is retransmitted. In the event that no error has occurred, steps 380, 385, 390 are not executed. In step 395 it is checked whether the data of all categories have been transferred. If this is not the case, steps 365 to 395 repeat accordingly. After all data has been output, the procedure ends.
  • the data in the buffer can be marked so that the data has not yet been transferred. As long as this flag is present, it can be seen that the handover has not yet been successful, and this flag can only be removed after successful transfer of the data.
  • the transfer of the data and the consistency of the data is ensured both in the interface device and in the PVS program.
  • This has the advantage that in the event of a power failure with a concomitant interruption of the data transmission, the interface device is able to understand which data has been completely transmitted and in which data record of a certain category the error has occurred.
  • This benefit relates not only to power failures, but also to simpler transmission probes, for example, through a faulty cable connection between the input interface and the program interface API of the computing device executing the PVS software.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • General Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • Business, Economics & Management (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Biomedical Technology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Ein erfindungsgemäßes Patientenverwaltungssystem umfasst ein Gerät, welches ein Patientenverwaltungssystem-Programm ausführt, eine Datenquelle zum Bereitstellen von medizinischen Daten sowie eine Schnittstelleneinrichtung, die zwischen dem Gerät und der Datenquelle eingebunden ist und Daten von der Datenquelle empfängt, in Tastatur-Scan-Codes umwandelt, die für das Patientenverwaltungssystem-Programm spezifisch sind, und diese Tastatur-Scan-Codes an das Gerät ausgibt. Eine erfindungsgemäße Schnittstelleneinrichtung ist eingerichtet, um zwischen einem Gerät, welches ein Patientenverwaltungssystem-Programm ausführt, und einer Datenquelle zum Bereitstellen medizinischer Daten eingebunden zu werden und empfängt die Daten von der Datenquelle, wandelt diese in Tastatur-Scan-Codes, die für das verwendetet Patientenverwaltungssystem-Programm spezifisch sind, um, und gibt diese Tastatur-Scan-Codes an das Gerät aus. Ein erfindungsgemäßes Verfahren umfasst das Empfangen von medizinischen Daten von einer Datenquelle zum Bereitstellen medizinischer Daten, das Umwandeln der medizinischen Daten in Tastatur-Scan-Codes, die für das Patientenverwaltungssystem-Programm spezifisch sind und das Ausgeben der Tastatur-Scan-Codes an das Gerät.

Description

Patientenverwaltungssystem mit intelligenter Schnittstelleneinrichtung zur Übertragung medizinischer Daten
Die vorliegende Erfindung bezieht sich auf ein Patientenverwaltungssystem und -verfahren, sowie einer zugehörigen Schnittstelleneinrichtung zur verbesserten Kommunikation mit ei- ner Patientenverwaltungssoftware.
Hintergrund der Erfindung
In Krankenhäusern, Kliniken oder Arztpraxen kommen sogenannte Patientenverwaltungs- systemβ zum Einsatz, die auf einem Computer implementiert sind. Diese Patientenverwaltungssysteme dienen zur Erfassung personenbezogener Grund-Daten, wie Name, Vorna- me(n), Geburtsdatum, Geschlecht, Krankenkasse sowie einer eindeutigen Patientennummer. Des Weiteren können Anamnesen, Befunde, Diagnosen, Therapien und weitere Pro- zedere erfasst werden. Darüber hinaus ist es möglich, aus diesen Patientenverwaltungssystemen beispielsweise Rezepte und Überweisungen zu erzeugen und auszudrucken.
Zum Datenaustausch zwischen einem medizinischen Gerät, wie beispielsweise ein Rönt- gen- oder Ultraschallgerät, gibt es hierfür entworfene Datenschnittstellen. Anfänglich dienten physische Datenträger wie beispielsweise Disketten dazu, die Daten von einem Gerät zu einem anderen zu transportieren, diese wurden aber dann durch andere Kommunikationsmedien, wie beispielsweise kabelgebundene oder kabellose Kommunikation über Netzwerkverbindungen, verdrängt. Diese Datenschnittstellen basieren auf einem definierten Standard, wie beispielsweise dem ADT-, GDT-, BDT- oder HL7-Standard. Diese Schnittstellen sind bei der jeweiligen Endbenutzersoftware, d.h. bei dem jeweiligen Patientβnver- waltungssystβm-Programm, unterschiedlich implementiert, da nur wenige der Schnittstβl- lenparametβr verbindlich definiert sind (sogenannte Muss-Felder). So ist bei der GDT- Schnittstelle lediglich die Übergabe des Patientennamens, Vornamens, Geburtsdatum, Ge- schlecht, Krankenkasse und Patientennummer zwingend erforderlich. Darüber hinaus sind in der Regel noch sehr viele weitere optionale Felder definiert oder definierbar. Ein Beispiel für ein solches optionales Feld ist ein Feld für die Übergabe von Blutdruckwerten.
Da sich der jeweilige Programmierer bei dem Entwerfen und Programmieren eines Patientenverwaltungsprogramms in der Regel nur an die zwingend erforderlichen Muss-Fβlder hält und optionale Felder (sogenannte Kann-Felder) nach Belieben oder Notwendigkeit de- finiert und auch wieder um-definiert, ist der Datenaustausch zwischen Patientenvβrwal- tungssystemen von unterschiedlichen Anbietern schwierig bis unmöglich.
Ein solches Patientenverwaltungssystem ist aus der DE 100 50 087 A1 bekannt. Auf einem Zentralrechner wird hier eine Datenbank bereitgestellt, auf dem bereits erfasste Daten gespeichert werden, darunter auch Daten, die durch medizinische Messgeräte gewonnen wurden. An diesen Zentralrechner angeschlossene Ärzte können diese Daten dann auf ihrem PC abrufen. Das Ziel der in diesem Dokument beschriebenen Technik liegt in der Verbesserung der Organisation und Kommunikation zwischen verstreut liegenden Arztpraxen.
Um die zuvor beschriebene Hürde beim Datenaustausch zu überwinden, gibt es bereits zahlreiche Kooperationen, die sich das Ziel gesetzt haben, eine einheitliche Definition der Schnittstelle zum direkten Datenaustausch zu erarbeiten. Aber die einheitliche Definition solch einer Schnittstelle ist mit der Schwierigkeit verbunden, dass, sobald sich die Struktur einer der Schnittstellen im Rahmen einer Aktualisierung ändert oder gar neu gestaltet wird, jegliche Änderungen übereinstimmend in allen Schnittstellen implementiert und auf Kompatibilität überprüft werden müssen. Dies hat den Nachteil, dass ein Großteil des Aufwandes nicht auf die Weiterentwicklung der Schnittstelle abzielen kann, sondern auf eine Prüfung und Sichβrstellung der Schnittstellen untereinander verwendet werden muss.
Übersicht über die Erfindung
Es ist die Aufgabe der vorliegenden Erfindung, den Datenaustausch mit einem Patientenverwaltungssystem, insbesondere die Dateneingabe in ein solches Patieπtenverwaltungs- system, zu verbessern.
Diese Aufgabe wird durch die Gegenstände der unabhängige Ansprüche gelöst.
Bevorzugte Ausführungsformen werden in den abhängigen Ansprüchen beschrieben.
Ein erfindungsgemäßes Patientenverwaltungssystem umfasst ein Gerät, welches ein Pati- βntenverwaltungssystem-Programm ausführt, eine Datenquelle zum Bereitstellen von me- dizinischen Daten sowie eine Schnittstelleneinrichtung, die zwischen dem Gerät und der Datenquelle eingebunden ist und Daten von der Datenquelle empfängt, in Tastatur-Scan- Codes umwandelt, die für das Patientenverwaltungssystem-Programm spezifisch sind, und diese Tastatur-Scan-Codes an das Gerät ausgibt. Eine erfindungsgemäße Schnittstelleneinrichtung ist eingerichtet, um zwischen einem Gerät, welches ein Patientenverwaltungssystem-Programm ausführt, und einer Datenquelle zum Bereitstellen medizinischer Daten eingebunden zu werden und empfängt die Daten von der Datenquelle, wandelt diese in Tastatur-Scan-Codes, die für das verwendetet Pati- entenverwaltungssystem-Programm spezifisch sind, um, und gibt diese Tastatur-Scan- Codes an das Gerät aus.
Ein erfindungsgemäßes Verfahren umfasst das Empfangen von medizinischen Daten von einer Datenquelle zum Bereitstellen medizinischer Daten, das Umwandeln der medizinischen Daten in Tastatur-Scan-Codes, die für das Patientenverwaltungssystem-Programm spezifisch sind und das Ausgeben der Tastatur-Scan-Codes an das Gerät.
Kurze Beschreibung der Figuren
Fig. 1 zeigt eine schematische Übersicht des Aufbaus der Datenschnittstelle.
Fig. 2 zeigt den schematischen Aufbau des erfindungsgemäßen Patientenverwaltungssystems.
Fig. 3A und 3B zeigen ein Ablaufdiagramm des erfindungsgemäßen Verfahrens.
Detaillierte Beschreibung erfindungsgemäßer Ausgestaltungen
Wie zuvor beschrieben betrifft die Erfindung ein Patientenverwaltungssystem, bei dem eine Schnittstelleneinrichtung zwischen einem Gerät, welches ein Patientenverwaltungssystem- Programm ausführt, und einer Datenquelle zum Bereitstellen von medizinischen Daten eingebunden ist und die Daten von der Datenquelle empfängt, diese in für das Patientenver- waltungssystem-Programm spezifische Tastatur-Scan-Codes umwandelt, und diese Tastatur-Scan-Codes an das Gerät ausgibt.
Das Gerät, welches die Patientenverwaltungssystem-Software ausführt, kann ein handelsüblicher Personal Computer sein, denkbar ist es aber auch, dass wesentlich leistungsfähigere Servercomputer zum Einsatz kommen. Der Einsatz von leistungsfähigeren Server- Computern hat den Vorteil, dass diese einem erhöhten Datenaufkommen gerecht werden, in dem Fall, dass das Patientenverwaltungssystem-Programm in einem Krankenhaus, Klinikum oder einer sehr großen Arztpraxis zum Einsatz kommt. Als Patientenverwaltungssystem-Programme Können beispielsweise Programme wie MEDISTAR oder PDE-TOP zum Einsatz kommen. Solche Computerprogramme, die auch unter dem Begriff Arztsoftwarβ bekannt sind, unterstützen die Verwaltung, die Organisation und den Betrieb von Arztpraxen. Die Funktionalität solcher Arztsoftware umfasst die Patientenverwaltung, Karteiführung, Dokumenten-Management bis hin zur Abrechnung mit den Krankenkassen. Die Anbindung von elektronischen Geräten an diese Software ist möglich, beispielsweise um die Daten, die auf einer Versichertenkarte gespeichert sind, über ein Kartenlesegerät in diese Software einzugeben. Ebenso ist es möglich, Befunde elektronisch zu übermitteln.
Die Schnittstelleneinrichtung oder auch Datenschnittstelle DS ist zwischen dem Gerät, wel- ches die Patientenverwaltungssoftware ausführt und einer Datenquelle eingebunden und empfängt Daten, insbesondere Patientendaten von der Datenquelle. In einer Ausführungsform können die Daten von der Datenquelle an die Schnittstelleneinrichtung über eine definierte GDT-Schnittstelle übertragen werden, dies hat den Vorteil, dass im Bereich der Medizininformatik solche Schnittstellen häufig anzutreffen sind und demnach sehr viele Daten- quellen über diese Schnittstelle verfügen. Beispielsweise sind Ultraschallgerätβ oder Röntgengeräte mit einer GDT-Schnittstelle ausgestattet, die einen schnellen und effizienten Da- tβntransfβr, zumindest der Grunddaten, ermöglicht. In der Regel werden im Fall eines Röntgengeräts die Patientengrunddaten über GDT übertragen, das Bilddaten über eine Schnittstelle gemäß dem Dicom- (Digital Imaging and Communications in Mediane) Standard gβ- sendet werden. Des Weiteren können in manchen Ausführungsformen die medizinischen Daten über ein Eingabegerät, welches speziell zum Eingeben von medizinischen Daten eingerichtet ist, eingegeben werden. Solch ein Eingabegerät kann ein Personal Computer oder ein Laptop oder ein Tablet-PC sein, welcher über eine grafische Eingabeschnittstelle verfügt, was den Vorteil hat, dass über eine grafische Eingabeschnittstelle die Eingabe zeit- sparend erfolgen kann, da die auf einer grafischen Schnittstelle vorhandenen grafischen Buttons leicht erkennbar und anklickbar sind, was die Eingabegeschwindigkeit erhöht. Insbesondere, wenn das Eingabegerät mit einem TouchScreen ausgestattet ist, kann die Eingabe nicht nur mittels Maus und Tastatur erfolgen, sondern durch die Verwendung des Fingers oder eines hierfür vorgesehenen Eingabestiftes, was eine noch schnellere und intuiti- vere Bedienung der Eingabe ermöglicht.
Die derart eingegebenen Daten werden, wie zuvor beschrieben, über eine hierfür vorgesehen Schnittstelle an die Schnittstelleneinrichtung übergeben. Die Schnittstelleneinrichtung wandelt diese Daten in Tastatur-Scan-Codes um, welche an das angeschlossene Gerät ausgegeben werden, um in das Patientenverwaltungssystem-Programm eingegeben zu werden. Tastatur-Scan-Codes sind in der Computertechnik Daten, die von der Tastatur eines Rechners an diesen gesendet wird, wenn eine Taste gedrückt oder losgelassen wird. Die zu verwendenden Tastatur-Scan-Codes sind in der Regel abhängig von der eingesetz- ten Patiβntenverwaltungssystem-Software. Der Schnittstelleneinrichtung wird die verwendete Software mitgeteilt, und die Schnittstelleneinrichtung kann aus einer Tabelle ermitteln, welcher Satz von Tastatur-Scan-Codes für diese Software benötigt werden, und kann diese dann entsprechend verwenden. Dies hat den Vorteil, dass die Schnittstelleneinrichtung schnell auf eine geänderte Patientenverwaltungssystem-Software angepasst werden kann. Dies hat darüber hinaus den weiteren Vorteil, dass die Eingangsschnittstelle der Schnittstelleneinrichtung, nämlich die zuvor beschriebene GDT-Schnittstelle, davon unberührt bleibt, wenn sich die verwendete Patientenverwaltungssystem-Software ändert. Dies ermöglicht es dem Anwender, die Eingabe in das Patientenverwaltungssystem in gewohnter Weise auszuführen, im idealen Fall bleibt es für den Verwender des Patientenvβrwaltungssystems unmerkbar, welche Patientenverwaltungssystem-Software verwendet wird. Deshalb fallen bei einem Wechsel des Patientenverwaltungssystem-Programms keine Umschulungen an, um mit dem neuen Programm umgehen zu können.
Die Funktionalität der Schnittstelleneinrichtung kann in manchen Ausführungsformen in einer betriebssystemunabhängigen Programmiersprache, beispielsweise TCL, programmiert sein, so dass die Schnittstelleneinrichtung unabhängig von dem gewählten Betriebssystem ist, was insbesondere dann von Vorteil ist, wenn in einer Praxis unterschiedliche Betriebssysteme, wie Windows, Linux und Mac OS zum Einsatz kommen. Durch die Unabhängigkeit der Datenschnittstellθ vom gewählten Betriebssystem ist dann die Bedienung und das Look-and-Feel, d.h. das Benutzerempfinden, immer das gleiche, was Eingewöhnungspha- sen zur Bedienung der Software wegfallen lässt.
Die erfindungsgemäße Schnittstelleneinrichtung ist unabhängig von Datenstrukturänderun- gen, die sich bei Aktualisierungen/Updates der Endbenutzer-Software ergeben können. Würde die Kommunikation zwischen der Schnittstelleneinrichtung und dem Patientenverwaltungssystem-Programm mittels einer vordefinierten Schnittstelle, wie beispielsweise der GDT-Schnittstelle, erfolgen, würde sich in der Regel bei einem Programm-Update die Eingangsschnittstelle des Patientenverwaltungssystems ändern und eine Aktualisierung der Schnittstelleneinrichtung wäre notwendig. Da in der Regel der Anbieter des Patientenver- waltungssystem-Programms die Datenstruktur der Eingangsschnittstelle nicht offenlegt, um es der Konkurrenz zu erschweren, sich auf eine geänderte Datenstruktur anzupassen, müsste eine geänderte Datenstruktur der Geräteschnittstelle beispielsweise durch ein sogenanntes Reverse-Engineering rekonstruiert werden, was einen sehr großen zeitlichen Aufwand mit sich bringt. Da in der Regel aber, die grafische Eingabemaske des Patienten- vβrwaltungssystem-Programms sich nicht ändert, um eine Kontinuität in der Bedienung des Programms zu sichern, hat die Verbindung von Tastatur-Scan-Codes zur Übermittlung der Eingabe in das PVS-Programm den Vorteil, dass man gerade diese Konstanz der Strukturierung der grafischen Eingabemaske ausnutzen kann.
Die Schnittstelleneinrichtung weist in manchen Ausführungsformen noch eine gewisse Ei- genintelligenz auf, d.h. die Datenschnittstelle ist in der Lage, die unterschiedlichen empfangenen Daten einzuordnen und in der Endbenutzer-Software richtig einzutragen. Hierzu ist die Schnittstelleneinrichtung in der Lage, die empfangenen Daten in Grundkategorien einzuordnen, wobei die Grundkategorien Anamnesen, Befunde, Diagnosen, ICD-Codes, Therapien, Prozederβ, Abrechnungsziffem und Formulare umfassen können. Die Aufzäh- lung der Grundkategorien ist nicht abschließend und kann noch beliebig erweitert werden. Dies hat den Vorteil, dass eine dynamische Anpassung an die jeweiligen Ansprüche des Benutzers möglich ist. Beispielsweise hat ein Facharzt für Orthopädie andere Ansprüche an die verwendeten Kategorien als ein Kardiologe oder ein Hautarzt.
Um die Kategorie der jeweiligen Untermenge der von der Datenquelle bereitgestellten me- dizinischen Daten zu ermitteln, greift in manchen Ausführungsformβn die erfindungsgemä- ße Schnittstelleneinrichtung auf Information zurück, die zusammen mit den Daten übertragen werden. Beispielsweise kann die Grundkategorie durch einen den eigentlichen Patientendaten vorangestaltenen Präfix definiert sein. Beispielsweise kann ein Blutdruckwert, der von der Datenquelle bereitgestellt wird, durch einen Präfix "RR" gekennzeichnet sein. Das Kürzel "RR" ist lediglich als beispielhaft anzusehen. Es ist üblich, Blutdruckwerte derart anzugeben, so dass zuerst der systolische und dann der diastolische Druckwert angegeben wird. Der systolische Wert entspricht dem Gefäß-Innendruck beim Ausdehnen des Gefäßes, der diastolische Wert entspricht dem Gefäß-Innendruck beim Zusammensziehen, weshalb der systolische immer größer ist als der diastolische Wert. Sind die gemessenen Werte beispielsweise 140 und 90, können diese über die Datenschnittstelle übergeben werden unter Verwendung der Zeichenfolge "RR 140/90". "RR" ist die übliche Abkürzung für Riva-Rocci, ein italienischer Arzt, der erstmalig die Armmanschettβ zur Messung des Blutdrucks beschrieben hat und zu dessen Andenken die Abkürzung "RR" eingeführt wurde. Alternativ könnte auch die Abkürzung "BD" für "Blutdruck" oder "BP" für "Blood Pressure" verwendet werden. Stellt die Schnittstelleneinrichtung fest, dass eine Zeichenkettβ bereitgestellt wird, die mit "RR" beginnt, kann diese somit als Blutdruckwert erkannt werden. Da dem Bediener des PVS-Programms bekannt ist, in welchem Teil der Eingabemaske Blutdruckwertθ eingegeben werden sollen, ist es möglich, durch den Einsatz der Tastatur- Scan-Codes das richtige Eingabefeld anzusteuern und dort die Blutdruckwerte einzugeben.
Das Ermitteln der mit den bereitgestellten Daten verbundenen Kategorie ermöglicht es der Schnittstelleneinrichtung, diese Daten zu überprüfen. Beispielsweise kann, erneut unter Verwendung des vorher beschriebenen Blutdruckwertes, die Datenschnittstelle überprüfen, ob der erste Wert, der dem systolischen Blutdruckwert entspricht, größer ist als der nachfolgende diastolische Wert. Ist dies nicht der Fall, ist davon auszugehen, dass die bereitgestellten Daten fehlerhaft sind, und es ist dann möglich, an den Benutzer des PVS-Systems eine entsprechende Warnmeldung auszugeben. Dies hat den Vorteil, dass Fehleingaben zeitnah entdeckt werden können, in der Regel unmittelbar nach der Untersuchung des Pa- tienten. Fiele eine Dateninkonsistenz zwischen der Diagnose und den Abrechnungsziffern erst beispielsweise bei der Abrechnung mit der Krankenkasse auf, was einige Tage oder Wochen nach der Untersuchung des Patienten sein kann, ist es in der Regel nicht mehr möglich, diesen Fehler zu korrigieren.
Des Weiteren ist es der Schnittstelleneinrichtung möglich, die Plausibilität der Daten an- hand eines Regelwerks zu überprüfen.
Bei einer solchen Plausibilitätsprüfung überprüft die Schnittstelleneinrichtung die Daten anhand eines Regelwerks, bevor diese Daten an die Endbenutzer-Softwarβ weitergeleitet werden, beispielsweise wird überprüft, ob die erhobenen ICD-Codes der Diagnose zu den Medikamenten passen oder ob die Seitenlokalisationen in den Diagnosen (z.B. rechtes oder linkes Knie) zu den Seitenlokalisationen der bei den Ziffern gewählten OPS- Schlüsseln passt. Dies hat den Vorteil, dass eine derartige Inkonsistenz innerhalb des Datensatzes rechtzeitig entdeckt werden kann, insbesondere im Hinblick darauf, dass so ärztliche Kunstfehler vermieden werden können. Wurde beispielsweise eine Diagnose aufgrund eines Röntgenbilds von dem rechten Knie angefertigt, erfolgt aber eine spätere Operations- planung für das linke Knie, kann das βrfindungsgemäße Patientenverwaltungssystem rechtzeitig eine entsprechende Warnung oder Fehlermeldung ausgeben. Des Weiteren bietet sich der Vorteil, dass es bei dem erfindungsgemäßβn Patientenverwal- tungssystem nicht notwendig ist, die eigentliche Schnittstelle zur Dateneingabe des PVS- Programms zu nutzen. Diese Schnittstelle des PVS-Programms ist in der Regel eine grafische Eingabemaske, die eine Vielzahl von Eingabefeldem aufweist und in die der Benutzer die Patienteninformation eingeben kann. Der Großteil der derzeit verfügbaren PVS-Pro- gramme ist werbungsfinanziert, d.h. dass während der Eingabe der Daten in die Programm- eingabeschnittstelle im Grunde unerwünschte Werbefenster geöffnet werden oder andere Werbeeinblendungen erfolgen. In bestimmten Fällen, z.B., wenn bei dem Patienten eine Migräne-Erkrankung diagnostiziert wurde, könnte eine Werbeeinblendung erfolgen, die dem Arzt ein bestimmtes Migräne-Medikament empfiehlt.
Da bei dem erfindungsgemäßen PVS-System die Eingabe der medizinischen Daten in manchen Ausführungsformen über eine weitere Datenquelle erfolgt, umgeht man so die werbungsbehaftetβ Schnittstelle. Jedoch hat eine Werbeeinblendung in Form eine zusätzlich sich öffnenden Fensters zur Folge, dass sich der Eingabefokus ändert, d.h. nach dem öffnen des Werbefensters ist der Eingangsfokus nicht mehr das zuvor angesteuerte Einga- befeld der Schnittstelle, sondern ist das Werbungsfenster mit einer entsprechenden Taste zum Quittieren dieses Werbβfenstβrs. Deshalb ist in manchen Ausführungsformen die erfindungsgemäße Datenschnittstelle oder Schnittstelleneinrichtung eingerichtet, um einen solchen Fokuswechsel festzustellen und entsprechend darauf zu reagieren. Eine solche entsprechende Reaktion auf eine Werbeeinblendung könnte beispielsweise das Quittieren des Werbefensters und danach Rücksetzen des Eingabefokus in das zuletzt besuchte Eingabefeld umfassen. Des Weiteren führt nicht nur das öffnen des Werbefensters zu einer ungewollten Fokusänderung, sondern auch vom Betriebssystem erzeugte Fehlermeldungen oder Benachrichtigungen, öffnet sich beispielsweise ein Benachrichtigungsfenster, das den Benutzer dazu auffordert, die Festplatte aufzuräumen, was unter den Windows- Betriebssystemen üblicherweise dann passiert, wenn die Kapazität der Festplatte weitgehend erschöpft ist, muss dieses Fenster ebenso quittiert werden und der Eingabefokus zurückgesetzt werden. Solche Systemfehlermeldungen können über die entsprechende Pro- grammierschnittstellθ (application programming interface - API) abgefragt werden.
In manchen Ausführungsformen ist die Schnittstelleneinrichtung eingerichtet, um vom dem Gerät abzufragen, an welcher Stelle in dem aktuellen Fokus-Fenster zur Zeit die Eingabe erfolgen kann. Das aktuelle Fokus-Fenster verfügt in der Regel über mehrere Eingabefelder, in die beispielsweise der Patienten-Name, -Vorname sowie dessen gemessener Blut- druck eingegeben werden kann. Jedes dieser Eingabefelder verfügt zur Kennzeichnung über eine einzigartige ID, und eben dies ID kann abgefragt werden, um zu bestimmen, welches Eingabefeld aktuell aktiv ist. Wurde beispielsweise bei der Eingabe der Patienten- grunddaten eine Fehlermeldung erzeugt und die Eingabe somit unterbrochen, ist nicht direkt nachvollziehbar bei welchem Eingabefeld die Unterbrechung aufgetreten ist. Durch Abfrage der ID des Eingabefelds kann bestimmt werden, wo die Eingabe fortgesetzt werden kann. Dies hat den Vorteil, dass somit nicht die Eingabemaske zurückgesetzt werden muss um diese in einen definierten Zustand zu versetzen um dann die Daten noch einmal komplett zu senden, sondern dass die Eingabe der Daten unter Reduzierung der erforderlichen Datenübertragungsbandbreite fortgesetzt werden kann. Darüber hinaus kann das Eingabefeld auch inhaltlich geprüft werden, so kann zum Beispiel das Eingabefeld, in welches das Datum einer Untersuchung eingefügt wird, darauf geprüft werden, ob das Datum dem aktuellen Datum oder dem Datum der Untersuchung entspricht.
Darüber hinaus ist die Schnittstelleneinrichtung in bestimmten Ausführungsformen dazu eingerichtet, die übergebenen Daten in eine beliebige, modular ansteuerbare Datenbank abzuspeichern. Dies hat den Vorteil, dass, wenn es nach einer der zuvor diskutierten Abbruche oder Fehlermeldungen notwendig ist, die Daten noch einmal zu versenden, kann auf diese Daten zurückgegriffen werden. Des Weiteren können durch die Speicherung der Patientendaten eventuelle Unverträglichkeiten zwischen den aktuell verordneten Medikamenten und zuvor verordneten Medikamenten berücksichtigt werden. Wird beispielsweise festgestellt, dass dem Patient zuvor ein Blutverdünnungsmittel verschrieben wurde, und wurde dem gleichen Patienten aktuell ein Schmerzmittel verschrieben, das ebenso eine Blutverdünnung bewirken kann, kann eine entsprechende Warnung ausgegeben werden, dass sich die Wirkungen dieser beiden Medikamente verstärken. In anderen Fällen könnte berücksichtigt werden, dass die Wirksamkeit mancher Antibiotika die Wirksamkeit von man- chen Kontrazeptiva unerwünscht beeinflusst, und eine entsprechende Warnung kann ausgegeben werden. Als eine solche Datenbank kann in manchen Ausführungsformen eine SQL-Datenbank zum Einsatz kommen.
Im Folgenden werden bevorzugte Ausgestaltungen noch einmal unter besonderer Berücksichtigung der beigefügten Zeichnungen erläutert.
Fig. 1 zeigt eine Ausführungsform der erfindungsgemäßen Datenschnittstelle 100. Die Datenschnittstelle empfängt medizinische Daten über ein hierfür vorgesehene Schnittstelle 105, welche in bestimmten Ausführungsformen eine GDT-Schnittstelle ist. Des Weiteren umfasst die Datenschnittstellβ ein Datθnübβφrüfungsmodul 110. Dieses Datenüberprü- fungsmodul ist eingerichtet, um die empfangenen medizinischen Daten kategorienweisβ zu übθφrtjfen. Hierbei findet eine Überprüfung bezüglich der Syntax statt. Entspricht der Aufbau der empfangenen Daten nicht der erwarteten Syntax, kann eine entsprechende Fehlermeldung ausgegeben werden und der Benutzer kann die Eingabe korrigieren. In anderen Ausführungsbeispielen kann das Datenüberprüfungsmodul Syntaxfehler selbständig korrigieren, beispielsweise wird ein Blutdruckwert "RR 90/140" empfangen, aber die anzuwendende Syntax verlangt, dass der erste Wert der größere ist, kann das Datenüberprüfungs- modul die beiden Zahlenwerte austauschen. Das Datenüberprüfungsmodul bezieht die Information betreffend die Syntax und weitere Regeln von einer Tabelle 115. In dieser Tabelle sind zu erwartende Kategorien und Ziffern abgelegt und damit verknüpfte Regeln, sowie die zugrundeliegende Syntax sind in Tabellen abgelegt. Ebenso befinden sich ICD-Codes in der Tabelle 115.
Die Schnittstelleneinrichtung umfasst des Weiteren ein Datenspeicherungsmodul 120. Dieses Datenspeicherungsmodul speichert die empfangenen Patientendaten in einer hierfür vorgesehenen Speichereinheit ab. In bestimmten Ausführungsformen ist diese hierfür vorgesehene Speichereinheit eine Datenbank 130. Diese Datenbank kann von der Schnittstel- leneinrichtung getrennt sein, beispielsweise kann diese sich auf einen Datenbankserver befinden. Insbesondere kann in bestimmten Ausführungsformen diese Datenbank eine SQL-Datenbank sein, welche für diese Zwecke geeignet ist.
Die Schnittstelleneinrichtung der Fig. 1 zeigt des Weiteren ein Datenbewertungsmodul, das in bestimmten Ausführungsformen in der Schnittstelleneinrichtung ausgeführt ist. Dieses optionale Datenbewertungsmodul 140 ist in der Lage, anhand einer Wertetabelle 145 und unter Berücksichtigung der vorhandenen Patientendaten ein Patienteπ-Score zu bilden. Dieser Patienten-Score stellt ein Maß dafür dar, wie wahrscheinlich eine bestimmte Erkran- kung des Patienten ist. Beispielsweise fließt in den Patienten-Score das Alter, das Geschlecht, das Körpergewicht, der Blutdruckverlauf über einen bestimmten Zeitraum, bestehende Diagnosen sowie aktuelle Befunde ein. Alle diese Faktoren werden mit Gewichtungswerten, welche empirisch ermittelt sein können, versehen, und diese Gewichtungsfaktoren werden aufsummiert. Dieser Patienten-Score kann mit einem oder mehreren vordefi- nierten Werten verglichen werden. Liegt der Patienten-Score beispielsweise über einem ersten Grenzwert, kann eine Nachricht erzeugt werden, die empfiehlt, diesen Patienten ein bestimmtes Medikament zu verschreiben oder eine bestimmte Therapie anzuraten. Liegt der Patiβntβn-Score über einem weiteren, größeren Wert, kann empfohlen werden, den Patienten direkt in ein Krankenhaus zu überweisen. In manchen Ausführungsformen wird der Patienten-Score nicht von der Schnittstelleneinrichtung gebildet, sondern kann von außen, beispielsweise von der zuvor erwähnten Care-Engine, in die Schnittstelleneinrichtung eingegeben werden.
Bestimmte Ausführungsformen der Schnittstelleneinrichtung weisen ein Fehlerbehandlungsmodul 160 auf. Dieses Fehlerbehandlungsmodul fragt entsprechende Programmier- schnittstellen des Betriebssystems ab, ob eine Fehlermeldung erzeugt wurde. Wenn eine solche Fehlermeldung erzeugt wurde, kann abgeklärt werden, ob das PVS-Programm die Fehlermeldung erzeugt hat, oder ob die Fehlermeldung von dem Betriebssystem erzeugt wurde. Handelt es sich um eine von dem Betriebssystem erzeugte Fehlermeldung, kann diese dem Benutzer angezeigt werden, damit dieser den betriebssystemspezifischen Fehler entsprechend behandeln kann. Ist jedoch die Fehlermeldung von dem PVS-Programm erzeugt worden, bedarf es einer weiteren Analyse durch die Schnittstelleneinrichtung, denn eine Fehlermeldung des PVS-Programms kann beispielsweise durch eine unvollständige oder fehlerhafte Dateneingabe hervorgerufen sein. In diesem Fall wird der zusammen mit der Fehlermeldung ausgegebene Fehlercode ausgewertet. Zeigt der Fehlercode an, dass die an das PVS-Programm übergebene Daten nicht den erwarteten Daten entsprechen, können sämtliche Daten, die zu der derzeitig übertragenen Kategorie gehören, erneut versendet werden.
Hierzu greift die Schnittstelleneinrichtung auf einen Pufferspeicher 125 zurück. Dieser Pufferspeicher ist mit dem Datenspeichβrungsmodul 120 verbunden. In diesem Pufferspeicher können die zur Ausgabe bestimmten Daten in ihrer Gesamtheit gespeichert sein, können aber auch kategorienweise gespeichert sein, oder es kann sich lediglich eine Kategorie der Daten in dem Pufferspeicher befinden. Dies hat den Vorteil, dass eine erneute manuelle Eingabe der Daten nicht erforderlich ist, sondern es kann auch die in den Pufferspeicher befindenden Daten zurückgegriffen werden.
Des Weiteren umfasst die Datenschnittstelle ein Datenumwandlungsmodul 150. Dieses Datenumwandlungsmodul wandelt die empfangenen medizinischen Daten in Tastatur- Scan-Codes um. Hierzu wird anhand der zu der jeweiligen Daten zugehörigen Kategorie festgestellt, in welchen Teil der Eingabeschnittstelle des PVS-Programms diese Daten eingegeben werden müssen, und entsprechende Steuercodes werden erzeugt. Beispielsweise ist es möglich, zwischen den einzelnen Eingabebereichβn mittels einer Tabulatortaste zu wechseln, deshalb Können beispielsweise ein oder mehrere Tastatur-Scan-Codes, die der Eingabe einer Tabulatortaste entsprechen, eingefügt werden. Diese Angaben können einer Zuordnungstabelle 155 entnommen werden.
Diese Zuordnungstabelle oder Tastatur-Scan-Code-Tabelle weist auszugebenden Zeichen einen Tastatur-Scan-Code zu, das heißt dass Zeichen und auch Steuerzeichen unter Ver- wendung der Tastatur-Scan-Codes kodiert ausgegeben werden. Darüber hinaus weist die Tastatur-Scan-Code-Tabelle in manchen Ausgestaltungen noch die zuvor besprochenen einzigartigen IDs auf, die zur Kennzeichnung und Abfrage der Eingabefelder dienen. Diese IDs sind in der Tastatur-Scan-Code-Tabelle mit den jeweiligen, zugehörigen Kategorien verknüpft. Dies hat den Vorteil, dass die IDs der Eingabefelder, die bei der Übertragung der Daten einer bestimmten Kategorie angesteuert werden sollen, unmittelbar zur Verfügung stehen.
Das Datenumwandlungsmodul wandelt die empfangenen medizinischen Daten in bestimmten Ausführuπgsformen kategorieweise in Tastatur-Scan-Codes um, dies hat den Vorteil, dass, wenn die Datenübertragung fehlschlägt, muss lediglich die zuletzt übertragene Kate- gorie erneut übertragen werden/wodurch Übertragungsbandbreite eingespart werden kann. Die kategorieweise erzeugten Tastatur-Scan-Codes werden in bestimmten Ausführungs- formen kategorieweise in den Pufferspeicher 125 abgelegt.
Die erfindungsgemäße Schnittstelleneinrichtung umfasst in bestimmten Ausführungsformen des Weiteren ein Datenexportmodul 190, welches dazu eingerichtet ist, die in der Daten- bank 130 abgelegten Daten aus dieser Datenbank zu extrahieren, diese Daten in Gänze oder teilweise für den Export vorzubereiten und diese Daten dann in Form von Exportdaten 180 auszugeben. Die Aufarbeitung der Daten aus der Datenbank erfolgt unter Einhaltung bestimmter Exportregeln 195. Beispielsweise kann in den Exportregelπ festgelegt sein, dass die Daten nur anullisiert ausgegeben werden dürfen, in diesem Fall werden die Daten ohne Angaben von Patientennamen ausgegeben, und anstelle des Patientennamens könnte beispielsweise lediglich eine willkürlich gewählte Nummer ausgegeben werden, anhand derer es nicht möglich ist, auf den jeweiligen Patienten zurückzuschließen. Solch exportierte Daten könnten an eine entsprechende API des Gerätes, das das Patientenverwaltungssystem-Programm ausführt, weitergegeben werden, so dass dieses Gerät dann diese Da- ten per eMail an eine sogenannte Carβ Engine versendet. Eine solche Carβ Engine dient dazu, anhand der Patientendaten eine Behandlungsempfeh- lung auszusprechen, um es dem behandelnden Arzt zu erleichtern, einen Behandlungsplan auszuarbeiten. Insbesondere im Falle von multimorbiden Patienten bedeutet es für den behandelnden Arzt eine deutliche Mehrbelastung, alle Wechselwirkungen der für die einzelnen Erkrankungen zu verschreibenden Medikamente in ihrer Gesamtheit zu berücksichti- gen. Diese Arbeit kann zeitsparend von einer hierfür eingerichteten Care Engine übernommen werden, die dann ihrerseits eine Behandlungsempfehlung ausgibt. Wie zuvor beschrieben, kann eine Care-Engine dazu eingerichtet sein, um alternativ oder zusätzlich zur Behandlungsempfehlung einen Patienten-Score an die Schnittstelleneinrichtung zu senden.
Die Exportdaten 180 können in bestimmten Ausführungsformen anstatt an eine Care Engi- ne an ein System zur Versorgungsforschung versendet werden. Solche Versorgungsfor- schungssysteme benutzen anonymisierte Daten, um die Wirksamkeit von unterschiedlichen Medikamenten anhand einer großen Gesamtheit von Patienten statisch zu untersuchen. Nimmt ein Arzt an solch einem Programm zur Versorgungsforschung teil, ist dies mit einer Doppelerfassung der Daten verbunden, da die Patientendaten einerseits in ein PVS-Pro- gramm eingepflegt werden müssen, es aber keine praktikable Möglichkeit gibt, diese Daten wieder aus dem PVS-Programm zu extrahieren. Deshalb müssen die Patientendaten doppelt eingegeben werden, so dass diese nicht nur in das PVS-Programm, sondern auch noch in ein Programm zur Versorgungsforschung eingegeben werden. Diese doppelte Dateneingabe schreckt in der Regel von der Teilnahme an einem solchen Versorgungsfor- schungsprogramm ab. Die erftndungsgemäße Schnittstelleneinrichtung bietet in bestimmten Ausführungsformen den Vorteil, dass eine solche doppelte Datenerfassung nicht mehr notwendig ist, und bietet darüber hinaus den Vorteil, dass über das optionale Datenexport- modul ein solcher Datenexport ohne merklichen Mehraufwand bewerkstelligt werden kann.
Die Datenschnittstelle verfügt über eine Ausgabeschnittstelle 170, welche die in Tastatur- Scan-Codes konvertierte Daten an das Gerät, welches das PVS-Programm ausführt, ausgibt. Bei der Ausgabe dieser Daten werden die erzeugten Tastatur-Scan-Codes in eine API des Zielrechners injiziert, dies bedeutet, dass der Zielrechner die injizierten Daten als Tas- tβnanschläge interpretiert
Des Weiteren ist das Fehlerbehandlungsmodul in der Lage, die Datenerfassung des PVS- Programms in einen definierten Zustand zurückzusetzen. Das heißt, es werden die entsprechenden Tastatur-Scan-Codes, d.h. Tastaturbefehle, an die Endbenutzer-Software ge- schickt, die das PVS-Programm veranlassen, die Eingabeschnittstelle in einen definierten Ausgangszustand zurückzusetzen, von dem aus die Dateneingabe erfolgen kann.
Fig. 2 zeigt eine schematische Übersicht über das erfindungsgemäßβ Patientenverwal- tungssystem. Das Computergerät 230, d.h. das Gerät, welches die PVS-Software ausführt, umfasst ein Betriebssystem 232, die PVS-Software 234 sowie eine Programmierschnittstel- Ie API 237. Das System umfasst des Weiteren die Schnittstelleneinrichtung oder Datenschnittstelle DS 220 sowie die Datenquelle 210. Die Datenquelle ist mit der Schnittstelleneinrichtung 220 kommunikativ verbunden, so dass die Schnittstelleneinrichtung von der Datenquelle Daten empfangen kann, und so dass in bestimmten Ausführungsformen die Datenquelle Fehlermeldungen, die von der Schnittstelleneinrichtung erzeugt oder weitergβ- geben werden, empfangen kann. Die Datenquelle kann beispielsweise ein medizinisches Gerät mit einer GDT-Schnittstellβ sein oder auch eine grafische Eingabeeinrichtung, wie beispielsweise ein medizinischer Tablet-PC. Die Eingabeschnittstelle behandelt die von der Datenquelle bereitgestellten Daten, wie zuvor in Zusammenhang mit Fig. 1 beschrieben. Danach gibt die Eingabeschnittstelle die Daten an, die Programmierschnittstelle 237 des Computergeräts 230 aus. Das Computergerät 230 kann des Weiteren verbunden sein mit einer Tastatur 240, einer Maus 242 und einem Kartenlesegerät 245. In manchen Ausführungsformen ist das Kartenlesegerät 245 in der Tastatur 240 integriert. In bestimmten Ausführungsformen weist das Computergerät eine weiter Schnittstelle 239 auf, die es dem Computergerät ermöglicht, mit anderen Computern zu kommunizieren. Beispielsweise kann die Schnittstelle 239 eine Netzwerkschnittstelle sein, welche es ermöglicht, dass Daten über Kommunikationsprotokolle, wie beispielsweise TCP/IP, übertragen werden. Das Computergerät kann über diese Netzwerkschnittstelle mit dem zuvor erwähnten Versäumungs- forschungsserver verbunden sein, oder aber auch mit einer Care Engine oder im einfachsten Fall mit weiteren Computergeräten, die Bestandteil eines Computernetzwerkes bei- spielsweise in einer Praxis oder einem Krankenhaus sind.
Fig. 3 zeigt schematisch ein Verfahren, nach dem Ausführungsformen des erfindungsgβ- mälien Patientenverwaltungssystems betrieben werden kann. Wie aus der vorherigen Beschreibung klar, sind nicht alle Schritte des beschriebenen Verfahrens erfindungswesentlich und sind daher als optional anzusehen.
In Schritt 305 erfolgt die Übergabe von Patientengrunddaten an die Eingabeschnittstelle. In Schritt 310 werden diese Patientengrunddaten überprüft, beispielsweise darauf, ob der Patient schon vorhanden ist in Schritt 315. Ist der Patient noch nicht vorhanden, wird dieser in Schritt 318 neu angelegt. Danach werden in Schritt 320 neue Patientendaten empfangen. Dies geschieht beispielsweise über die zuvor diskutierte GDT-Schnittstelle. In Schritt 325 werden die Kategorien der empfangenen Daten geprüft, beispielsweise anhand einer Kate- gorientabelle oder einer Ziffemtabelle.
Danach wird in Schritt 330 die Syntax der empfangenen Daten überprüft, beispielsweise anhand einer ICD-Codetabelle.
In Schritt 335 werden in bestimmten Ausführungsformen die Wertebereichβ der empfangenen Daten anhand einer Wertebereichstabelle überprüft, und eventuell korrigiert. In Schritt 340 erfolgt eine Plausibilitätsprüfung der empfangenen Daten anhand einer Vergleichs der ICD-Codβs, der OPS-Schlüssel, Ziffern oder Medikamentenlistβn. Beispielsweise kann hier ein Vergleich von Seitenlokalisierungen in den ICD-Codes und den Abrechnungsziffern durchgeführt werden.
In Schritt 345 wird ein Patienten-Score ermittelt, in Schritt 350 wird dieser Patienten-Score mit einem Grenzwert verglichen. Obwohl hier nur der Vergleich mit einem Grenzwert gezeigt ist, ist in manchen Ausführungsformen auch der Vergleich mit mehreren Grenzwerten möglich. Übersteigt der Patienten-Score diesen Grenzwert, wird eine Empfθhlungsmeldung erzeugt, die eine bestimmte Behandlung des Patienten empfiehlt. Das Ermitteln des Patienten-Score erfolgt in der Regel durch Aufsummieren einzelner Gewichtungsfaktoren, die beispielsweise vom Geschlecht, Alter oder auch dem Blutdruck abhängen.
Danach werden in Schritt 360 die Daten in einer Datenbank abgespeichert.
Im Nachfolgenden werden die Patientendaten kategorienweisβ an eine Zielsoftware übergeben. In Schritt 365 werden die Daten einer Kategorie zur Übergabe an eine Patienten- verwaftungssoftware vorbereitet. Hierzu werden die Daten in Tastatur-Scan-Codes unter Benutzung einer Scan-Codβ-Tabelle umgewandelt. Schritt 365 umfasst in manchen Ausführungsformen, obwohl dies in der Figur nicht gezeigt ist, auch das Zwischenpuffem der Tastatur-Scan-Codes in einem Zwischenpufferspeicher. In manchen Ausführungsformen fließt in Schritt 365 des weiteren die ID des Eingabefelds, in das die Eingabe erfolgen soll, mit ein, um sicherzustellen zu können, dass die Eingabe unter Verwendung des richtigen Eingabefelds erfolgt. Diese ID wird hierzu von der Tastatur-Scan-Code-Tabelle abgefragt. Dies kann beispielsweise dadurch erreicht werden, dass die ID in der Tastatur-Scan-Code- Tabelle mit der ID des aktuellen Eingabefeldes verglichen wird. In Schritt 370 findet die Übergabe der vorbereiteten Daten statt. In Schritt 375 wird überprüft, ob während der Übergabe der Daten ein Fehler aufgetreten ist. Ist dies der Fall, wird überprüft in Schritt 380, ob eine Fokusänderung aufgetreten ist. Wenn dies der Fall war, wird in Schritt 385 der Fokus korrigiert oder zurückgesetzt. Wenn dies nicht der Fall war, werden die Daten erneut übergeben. Für den Fall, dass kein Fehler aufgetreten ist, werden die Schritte 380, 385, 390 nicht ausgeführt. In Schritt 395 wird überprüft, ob die Daten aller Kategorien übergeben wurden. Ist dies nicht der Fall, wiederholen sich die Schritte 365 bis 395 entsprechend. Nachdem alle Daten ausgegeben sind, endet das Verfahren.
Um die Sicherheit der Übergabe der Daten zu steigern, können die Daten in dem Zwischenspeicher mit einer Markierung versehen werden, die ergibt, dass die Daten noch nicht über- tragen wurden. Solange diese Markierung vorhanden ist, ist ersichtlich, dass die Übergabe noch nicht erfolgreich war, und diese Markierung kann erst nach erfolgreicher Übergabe der Daten wieder entfernt werden. Anhand einer solchen Markierung ist die Übergabe der Daten sowie die Konsistenz der Daten sowohl in der Schnittstelleneinrichtung als auch in dem PVS-Programm gewährleistet. Dies hat den Vorteil, dass bei einem eventuellen Stromaus- fall mit einer einhergehenden Unterbrechung der Datenübertragung die Schnittstelleneinrichtung in der Lage ist, nachzuvollziehen, welche Daten vollständig übertragen wurden, und bei welchem Datensatz einer bestimmten Kategorie der Fehler aufgetreten ist. Dieser Vorteil bezieht sich nicht nur auf Stromausfälle, sondern auch auf einfachere Übertragungs- fβhler, beispielsweise durch eine fehlerhafte Kabelverbindung zwischen der Eingabe- Schnittstelle und der Programmschnittstelle API des Computergerätes, welches die PVS- Software ausführt.

Claims

Patentansprüche
1. Patientenverwaltungssystem, umfassend:
ein Gerät (230), welches ein Patientenverwaltungssystem-Programm ausführt;
eine Datenquelle (210) zum Bereitstellen medizinischer Daten; und
eine Schnittstelleneinrichtung (100; 220), die zwischen dem Gerät (230) und der Datenquelle (210) eingebunden ist und Daten von der Datenquelle (210) empfängt, in Tastatur-Scan-Codes umwandelt, die für das Patientenverwaltungssystem- Programm spezifisch sind, und diese Tastatur-Scan-Codes an das Gerät (230) aus- gibt.
2. Patientenverwaltungssystem gemäß Anspruch 1 , wobei die Datenquelle (210) ein medizinisches Gerät ist.
3. Patientenverwaltungssystem gemäß Anspruch 2, wobei das medizinische Gerät ein Röntgen-Gerät oder ein Ultraschall-Untersuchungsgerät ist.
4. Patientenverwaltungssystem gemäß Anspruch 1 , wobei die Datenquelle (210) eine grafische Eingabeschnittstelle ist.
5. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 4, wobei die Schnittstelleneinrichtung (100) über eine Schnittstelle für den Transfer von medizinischen Daten mit der Datenquelle (210) verbunden ist.
6. Patientenverwaltungssystem gemäß Anspruch 5, wobei die Schnittstelle für den
Transfer von medizinischen Daten eine GDT-Schnittstelle (105), eine BDT- Schnittstelle oder eine HL7-Schnittstelle ist.
7. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 6, wobei die Schnittstelleneinrichtung mindestens einen Teil der von der Datenquelle (210) emp- fangenen Daten anhand von Regeln überprüft.
8. Patientenverwaltungssystem gemäß Anspruch 7, wobei die Prüfung des mindestens einen Teils der empfangenen Daten kategorienweise durchgeführt wird.
9. Patientenverwaltungssystem gemäß Anspruch 8, wobei die Kategorien Anamnesen, Befunde, Diagnosen, ICD Codierungen, Therapien, Abrechnungsziffern oder Formulare umfassen.
10. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 9, wobei die Um- Wandlung in Tastatur-Scan-Codes anhand einer Zuordnungstabelle geschieht.
11. Patientenverwaltungssystem gemäß Anspruch 10, wobei die Zuordnungstabelle angibt, in welche Tastatur-Scan-Codes die von der Datenquelle (210) empfangenen Daten in Abhängigkeit von dem verwendeten Patientenverwaltungssystem- Programm umgewandelt werden.
12. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 11 , wobei das Ausgeben der Tastatur-Scan-Codes an das Gerät (230) kategorienweise ausgeführt wird.
13. Patientenverwaltungssystem gemäß Anspruch 12, wobei die Kategorien Anamnesen, Befunde, Diagnosen, ICD Codierungen, Therapien, Abrechnungsziffern oder Formulare umfassen.
14. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 13, wobei das Ausgeben der Tastatur-Scan-Codes an das Gerät (230) das Injizieren der Tastatur- Scan-Codes in eine API des Geräts (230) umfasst.
15. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 14, wobei die Tas- tatur-Scan-Codes in einem Pufferspeicher zwischengespeichert werden.
16. Patientenverwaltungssystem gemäß einem der Ansprüche 12 bis 15, wobei bei dem Kategorienweisen Ausgeben der Tastatur-Scan-Codes die aktuell auszugebenden Tastatur-Scan-Codes in dem Pufferspeicher vor der Ausgabe mit einem Marker versehen werden, der anzeigt, dass die Ausgabe noch nicht abgeschlossen ist.
17. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 16, wobei die Ausgabe der Tastatur-Scan-Codes an das Gerät (230) wiederholt wird, wenn die Schnittstelleneinrichtung im Zusammenhang mit der Ausgabe der Tastatur-Scan- Codes and das Gerät (230) eine Fehlermeldung von dem Gerät (230) empfängt.
18. Patientenverwaltungssystem gemäß Anspruch 17, wobei die Wiederholung der Ausgabe der Tastatur-Scan-Codes an das Gerät (230) unter Verwendung der in dem Pufferspeicher zwischengespeicherten Tastatur-Scan-Codes geschieht.
19. Patientenverwaltungssystem gemäß einem der Ansprüche 16 bis 18, wobei nach der Ausgabe der Tastatur-Scan-Codes an das Gerät (230), wenn die Schnittstelleneinrichtung im Zusammenhang mit der Ausgabe der Tastatur-Scan-Codes and das Gerät (230) keine Fehlermeldung vom Gerät (230) empfängt, der Marker, der anzeigt, dass die Ausgabe noch nicht abgeschlossen ist, wieder gelöscht wird.
20. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 19, wobei die Schnittstelleneinrichtung von dem Patientenverwaltungssystem-Programm einen Pa- tienten-Score empfängt und diesen Score mit einem oder mehreren vorgegebenen Score-Werte vergleicht.
21. Patientenverwaltungssystem gemäß Anspruch 20, wobei die Schnittstelleneinrichtung eine Benachrichtigung auslöst, wenn der empfangene Patienten-Score einen der vorgegebenen Score-Werte übersteigt.
22. Patientenverwaltungssystem gemäß Anspruch 21 , wobei die Benachrichtigung eine Behandlungsempfehlung oder eine Empfehlung zur Überweisung zum Facharzt oder Krankenhaus umfasst.
23. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 22, wobei die Schnittstelleneinrichtung die vom Gerät (230) empfangenen Daten in einer Datenbank speichert.
24. Patientenverwaltungssystem gemäß Anspruch 23, wobei die Datenbank zur Speicherung der vom Gerät (230) empfangenen Daten eine externe Datenbank ist.
25. Patientenverwaltungssystem gemäß Anspruch 24, wobei die externe Datenbank auf einem Datenbankserver betrieben wird.
26. Patientenverwaltungssystem gemäß einem der Ansprüche 23 bis 25, wobei die Datenbank eine SQL-Datenbank ist.
27. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 26, wobei die Schnittstelleneinrichtung eingerichtet ist, die vom Gerät (230) empfangenen Daten an ein weiteres Programm auszugeben.
28. Patientenverwaltungssystem gemäß Anspruch 27, wobei die Schnittstelleneinrich- tung des weiteren eingerichtet ist, die in der Datenbank gespeicherten Daten an das weitere Programm auszugeben.
29. Patientenverwaltungssystem gemäß einem der Ansprüche 27 und 28, wobei die Ausgabe der Daten anonymisiert erfolgt.
30. Patientenverwaltungssystem gemäß einem der Ansprüche 27 bis 29, wobei das wei- tere Programm eingerichtet ist, um in Erwiderung auf die von der Schnittstelleneinrichtung empfangenen Daten eine Behandlungsempfehlung für den/die Patienten auszugeben.
31. Patientenverwaltungssystem gemäß einem der Ansprüche 27 bis 30, wobei das weitere Programm eine Care-Engine ist.
32. Patientenverwaltungssystem gemäß einem der Ansprüche 1 bis 31 , wobei die
Schnittstelleneinrichtung eingerichtet ist, unter Verwendung einer Datenbank, die Wechselwirkungen zwischen Medikamenten beschreibt, die Daten in einer Kategorie auf mögliche Wechselwirkungen zu prüfen und eine Warnung auszugeben, wenn eine mögliche Wechselwirkung festgestellt wird.
33. Schnittstelleneinrichtung, die eingerichtet ist, um zwischen einem Gerät, welches ein
Patientenverwaltungssystem-Programm ausführt, und einer Datenquelle zum Bereitstellen medizinischer Daten eingebunden zu werden, und die Daten von der Datenquelle empfängt, in Tastatur-Scan-Codes umwandelt, die für das Patientenverwaltungssystem-Programm spezifisch sind, und diese Tastatur-Scan-Codes an das Ge- rät ausgibt.
34. Schnittstelleneinrichtung gemäß Anspruch 34, wobei die Schnittstelleneinrichtung angepasst ist, um gemäß einem der Ansprüche 2 bis 32 betrieben zu werden.
35. Patientenverwaltungsverfahren zum Betreiben einer Schnittstelleneinrichtung, welche mit einem Gerät, welches ein Patientenverwaltungssystem-Programm ausführt, verbindbar ist, wobei das Verfahren die folgenden Schritte umfasst:
Empfangen (320) von medizinischen Daten von einer Datenquelle zum Bereitstellen medizinischer Daten;
Umwandeln (365) der medizinischen Daten in Tastatur-Scan-Codes, die für das Patientenverwaltungssystem-Programm spezifisch sind; und
Ausgeben (370) der Tastatur-Scan-Codes an das Gerät.
36. Verfahren gemäß Anspruch 35, wobei die Datenquelle ein medizinisches Gerät ist.
37. Verfahren gemäß Anspruch 36, wobei das medizinische Gerät ein Röntgen-Gerät oder ein Ultraschall-Untersuchungsgerät ist.
38. Verfahren gemäß Anspruch 35, wobei die Datenquelle eine grafische Eingabeschnittstelle ist.
39. Verfahren gemäß einem der Ansprüche 35 bis 38, wobei die Schnittstellen- einrichtung über eine Schnittstelle für den Transfer von medizinischen Daten mit der
Datenquelle verbunden ist.
40. Verfahren gemäß Anspruch 39, wobei die Schnittstelle für den Transfer von medizinischen Daten eine GDT-Schnittstelle, BDT-Schnittstelle oder HL7-Schnittstelle ist.
41. Verfahren gemäß einem der Ansprüche 35 bis 40, des Weiteren umfassend: Überprüfen (325; 330; 335, 340) von mindestens einem Teil der von der Datenquelle empfangenen Daten anhand von Regeln.
42. Verfahren gemäß Anspruch 41 , wobei der Schritt des Überprüfens des mindestens einen Teils der empfangenen Daten kategorienweise durchgeführt wird.
43. Verfahren gemäß Anspruch 42, wobei die Kategorien Anamnesen, Befunde, Diag- nosen, ICD Codierungen, Therapien, Abrechnungsziffern oder Formulare umfassen.
44. Verfahren gemäß einem der Ansprüche 35 bis 42, wobei der Schritt des Umwandeins der medizinischen Daten in Tastatur-Scan-Codes anhand einer Zuordnungstabelle geschieht.
45. Verfahren gemäß Anspruch 44, wobei die Zuordnungstabelle angibt, in welche Tas- tatur-Scan-Codes die von der Datenquelle empfangenen Daten in Abhängigkeit von dem verwendeten Patientenverwaltungssystem-Programm umgewandelt werden.
46. Verfahren gemäß einem der Ansprüche 35 bis 45, wobei das Ausgeben der Tastatur-Scan-Codes an das Gerät kategorienweise ausgeführt wird.
47. Verfahren gemäß Anspruch 46, wobei die Kategorien Anamnesen, Befunde, Diag- nosen, ICD Codierungen, Therapien, Abrechnungsziffern oder Formulare umfassen.
48. Verfahren gemäß einem der Ansprüche 35 bis 47, wobei das Ausgeben der Tastatur-Scan-Codes an das Gerät das Injizieren der Tastatur-Scan-Codes in eine API des Geräts umfasst.
49. Verfahren gemäß einem der Ansprüche 35 bis 48, wobei die Tastatur-Scan-Codes in einem Pufferspeicher zwischengespeichert werden.
50. Verfahren gemäß einem der Ansprüche 46 bis 49, wobei der Schritt des kategorienweisen Ausgeben der Tastatur-Scan-Codes vor dem Schritt des Ausgebens umfasst:
Markieren der aktuell auszugebenden Tastatur-Scan-Codes in dem Pufferspeicher mit einer Markierung, die anzeigt, dass die Ausgabe noch nicht abgeschlossen ist.
51. Verfahren gemäß einem der Ansprüche 35 bis 50, wobei der Schritt des Ausgebens der Tastatur-Scan-Codes an das Gerät wiederholt (390) wird, wenn die Schnittstelleneinrichtung im Zusammenhang mit der Ausgabe der Tastatur-Scan-Codes and das Gerät eine Fehlermeldung von dem Gerät empfängt.
52. Verfahren gemäß Anspruch 51 , wobei die Wiederholung des Ausgebens der Tastatur-Scan-Codes an das Gerät unter Verwendung der in dem Pufferspeicher zwischengespeicherten Tastatur-Scan-Codes geschieht.
53. Verfahren gemäß einem der Ansprüche 50 bis 52, wobei das Verfahren nach dem Schritt des Ausgebens der Tastatur-Scan-Codes an das Gerät, den Schritt umfasst: Löschen der Markierung, die anzeigt, dass die Ausgabe noch nicht abgeschlossen ist, wenn die Schnittstelleneinrichtung im Zusammenhang mit der Ausgabe der Tastatur-Scan-Codes and das Gerät keine Fehlermeldung vom Gerät empfängt.
54. Verfahren gemäß einem der Ansprüche 35 bis 53, des Weiteren umfassend: Empfangen (345) eines Patienten-Score; und
Vergleichen (350) des empfangenen Patienten-Score mit einem oder mehreren vorgegebenen Score-Werte.
55. Verfahren gemäß Anspruch 54, des Weiteren umfassend: Auslösen (355) einer Benachrichtigung, wenn der empfangene Patienten-Score ei- nen der vorgegebenen Score-Werte übersteigt.
56. Verfahren gemäß Anspruch 55, wobei die Benachrichtigung eine Behandlungsempfehlung oder eine Empfehlung zur Überweisung zum Facharzt oder Krankenhaus umfasst.
57. Verfahren gemäß einem der Ansprüche 35 bis 56, des Weiteren umfassend: Speichern (360) die vom Gerät empfangenen Daten in einer Datenbank.
58. Verfahren gemäß Anspruch 57, wobei die Datenbank zur Speicherung der vom Gerät empfangenen Daten eine externe Datenbank ist.
59. Verfahren gemäß Anspruch 58, wobei die externe Datenbank auf einem Datenbankserver betrieben wird.
60. Verfahren gemäß einem der Ansprüche 57 bis 59, wobei die Datenbank eine SQL-
Datenbank ist.
61. Verfahren gemäß einem der Ansprüche 35 bis 60, des Weiteren umfassend: Ausgeben der von dem Gerät empfangenen Daten an ein weiteres Programm.
62. Verfahren gemäß Anspruch 61 , wobei der Schritt des Ausgebens der von dem Gerät empfangenen Daten an ein weiteres Programm die Ausgabe der in der Datenbank gespeicherten Daten an das weitere Programm umfasst.
63. Verfahren gemäß einem der Ansprüche 61 und 62, wobei das Ausgeben der Daten anonymisiert erfolgt.
64. Verfahren gemäß einem der Ansprüche 61 bis 63, wobei das weitere Programm eingerichtet ist, um in Erwiderung auf die von der Schnittstelleneinrichtung empfangenen Daten eine Behandlungsempfehlung für den/die Patienten auszugeben.
65. Verfahren gemäß einem der Ansprüche 61 bis 64, wobei das weitere Programm ei- ne Care-Engine ist.
66. Verfahren gemäß einem der Ansprüche 35 bis 65, des Weiteren umfassend: Prüfen, unter Verwendung einer Datenbank, die Wechselwirkungen zwischen Medikamenten beschreibt, der Daten in einer Kategorie auf mögliche Wechselwirkungen; und Ausgeben einer Warnung, wenn eine mögliche Wechselwirkung festgestellt wird.
PCT/EP2009/007538 2008-11-18 2009-10-21 Patientenverwaltungssystem mit intelligenter schnittstelleneinrichtung zur übertragung medizinischer daten Ceased WO2010057557A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA2744131A CA2744131A1 (en) 2008-11-18 2009-10-21 Patient administration system comprising intelligent interface device for the transmission of medical data
EP09748996.7A EP2356600B1 (de) 2008-11-18 2009-10-21 Patientenverwaltungssystem mit intelligenter schnittstelleneinrichtung zur übertragung medizinischer daten
US13/129,895 US20110264468A1 (en) 2008-11-18 2009-10-21 Patient administration system comprising intelligent interface device for the transmission of medical data

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008057910.6 2008-11-18
DE102008057910A DE102008057910B4 (de) 2008-11-18 2008-11-18 Patientenverwaltungssystem mit intelligenter Schnittstelleneinrichtung zur Übertragung medizinischer Daten

Publications (2)

Publication Number Publication Date
WO2010057557A2 true WO2010057557A2 (de) 2010-05-27
WO2010057557A3 WO2010057557A3 (de) 2010-11-11

Family

ID=41478996

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/007538 Ceased WO2010057557A2 (de) 2008-11-18 2009-10-21 Patientenverwaltungssystem mit intelligenter schnittstelleneinrichtung zur übertragung medizinischer daten

Country Status (5)

Country Link
US (1) US20110264468A1 (de)
EP (1) EP2356600B1 (de)
CA (1) CA2744131A1 (de)
DE (1) DE102008057910B4 (de)
WO (1) WO2010057557A2 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103218141B (zh) * 2013-04-08 2016-02-10 深圳市联新移动医疗科技有限公司 基于移动终端的生命体征信息录入方法及移动终端
CN103401835A (zh) * 2013-07-01 2013-11-20 北京奇虎科技有限公司 一种展现微博页面的安全检测结果的方法及装置
WO2023060470A1 (en) * 2021-10-13 2023-04-20 Citrix Systems, Inc. Prevention of inadvertent password disclosure
CN117409942B (zh) * 2023-12-14 2024-03-08 山东新时代药业有限公司 一种智慧医疗信息管理方法及系统

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5099444A (en) 1989-05-09 1992-03-24 Ansan Industries, Ltd. Peripheral data acquisition transmission and control device
US5261079A (en) 1990-12-18 1993-11-09 International Business Machines Corporation Interface for keyboard emulation provided by an operating system
US6049794A (en) 1997-12-09 2000-04-11 Jacobs; Charles M. System for screening of medical decision making incorporating a knowledge base
WO2001046016A1 (en) 1999-12-23 2001-06-28 Rast Rodger H System and method for providing individualized dosing
US6456277B1 (en) 1999-03-02 2002-09-24 International Business Machines Corporation Data conversion method used between different types of keyboards
WO2002084531A2 (en) 2001-04-10 2002-10-24 Univ Carnegie Mellon Systems and methods for deidentifying entries in a data source
US20030060688A1 (en) 2001-09-21 2003-03-27 Active Health Management Care engine
EP1416419A2 (de) 2002-10-22 2004-05-06 GE Medical Systems Information Technologies, Inc. Verfahren, Vorrichtung, Computerprodukt und Kodierungsformat zur Erzeugung von Anonymität beim Sammeln von Patientendaten
EP1471454A2 (de) 2000-09-04 2004-10-27 Enigma Health UK PLC Verbesserungen in Datenverwaltungssystemen
WO2005057465A2 (en) 2003-12-09 2005-06-23 Matsushita Electric Industrial Co., Ltd. Mobile medication history management apparatus, memory card, and management method
WO2006044518A2 (en) 2004-10-13 2006-04-27 Lifemasters Supported Selfcare, Inc. Method to identify and prioritize modifiable risk factors resulting in interventions that focus on individuals
EP1850342A1 (de) 2004-12-28 2007-10-31 International Business Machines Corporation Informationsaufzeichnungseinrichtung, datenflusssteuerung für die einrichtung und steuerverfahren für den datenfluss
DE102006042317A1 (de) 2006-09-08 2008-03-27 Robert Bosch Gmbh Verfahren und Vorrichtung zur Übertragung digitaler Daten
US20080263050A1 (en) 2007-04-20 2008-10-23 Michael Thomas Randazzo Decision support response systems and methods

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU750822B2 (en) * 1998-04-03 2002-08-01 Triangle Pharmaceuticals, Inc. Systems, methods and computer program products for guiding the selection of therapeutic treatment regimens
DE10050087A1 (de) * 2000-10-10 2002-05-02 Wolfgang Heinz Richard Pries Verfahren zur Organisation ambulanter Behandlungen
DE20217855U1 (de) * 2002-11-19 2003-01-16 Key Mouse Electronic Entpr Co Multimedia-Funktionen unterstützende Standard-Tastatur
US20060173713A1 (en) * 2005-01-26 2006-08-03 Alan Petro Integrated medical device and healthcare information system
US9355273B2 (en) * 2006-12-18 2016-05-31 Bank Of America, N.A., As Collateral Agent System and method for the protection and de-identification of health care data

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5099444A (en) 1989-05-09 1992-03-24 Ansan Industries, Ltd. Peripheral data acquisition transmission and control device
US5261079A (en) 1990-12-18 1993-11-09 International Business Machines Corporation Interface for keyboard emulation provided by an operating system
US6049794A (en) 1997-12-09 2000-04-11 Jacobs; Charles M. System for screening of medical decision making incorporating a knowledge base
US6456277B1 (en) 1999-03-02 2002-09-24 International Business Machines Corporation Data conversion method used between different types of keyboards
WO2001046016A1 (en) 1999-12-23 2001-06-28 Rast Rodger H System and method for providing individualized dosing
EP1471454A2 (de) 2000-09-04 2004-10-27 Enigma Health UK PLC Verbesserungen in Datenverwaltungssystemen
WO2002084531A2 (en) 2001-04-10 2002-10-24 Univ Carnegie Mellon Systems and methods for deidentifying entries in a data source
US20030060688A1 (en) 2001-09-21 2003-03-27 Active Health Management Care engine
EP1416419A2 (de) 2002-10-22 2004-05-06 GE Medical Systems Information Technologies, Inc. Verfahren, Vorrichtung, Computerprodukt und Kodierungsformat zur Erzeugung von Anonymität beim Sammeln von Patientendaten
WO2005057465A2 (en) 2003-12-09 2005-06-23 Matsushita Electric Industrial Co., Ltd. Mobile medication history management apparatus, memory card, and management method
WO2006044518A2 (en) 2004-10-13 2006-04-27 Lifemasters Supported Selfcare, Inc. Method to identify and prioritize modifiable risk factors resulting in interventions that focus on individuals
EP1850342A1 (de) 2004-12-28 2007-10-31 International Business Machines Corporation Informationsaufzeichnungseinrichtung, datenflusssteuerung für die einrichtung und steuerverfahren für den datenfluss
DE102006042317A1 (de) 2006-09-08 2008-03-27 Robert Bosch Gmbh Verfahren und Vorrichtung zur Übertragung digitaler Daten
US20080263050A1 (en) 2007-04-20 2008-10-23 Michael Thomas Randazzo Decision support response systems and methods

Also Published As

Publication number Publication date
CA2744131A1 (en) 2010-05-27
DE102008057910A1 (de) 2010-05-20
EP2356600A2 (de) 2011-08-17
WO2010057557A3 (de) 2010-11-11
EP2356600B1 (de) 2017-09-20
US20110264468A1 (en) 2011-10-27
DE102008057910B4 (de) 2010-10-07

Similar Documents

Publication Publication Date Title
DE69731884T2 (de) Rechnergestütztes medizinisches diagnose- und beratungssystem mit zugang zu einem kommunikationsnetz
EP3451211B1 (de) Verfahren und steuereinrichtung zur steuerung eines medizintechnischen bildgebenden systems
DE102008056013A1 (de) Patientenbehandlungsplanungssystem
DE102008020610A1 (de) Vorrichtungen und Verfahren zur Validierung klinischer Daten
DE102006000713A1 (de) Medizinisches Bildbetrachtungsmanagement- und Statussystem
DE112004000647T5 (de) Informationssystem für vorbeugende Gesundheitsfürsorge
DE112018001359T5 (de) Arzneimittelverschreibungsunterstützungsvorrichtung, verfahren und programmfeld
DE10316298A1 (de) Verfahren und Anordnung zur automatischen Aufbereitung und Auswertung medizinischer Daten
EP2356600B1 (de) Patientenverwaltungssystem mit intelligenter schnittstelleneinrichtung zur übertragung medizinischer daten
EP3528257A1 (de) Computerprogramm, system und verfahren zum verwalten von auf einen patienten bezogenen medizindaten
WO2008145309A1 (de) Vorrichtung und verfahren zur zentralen überwachung und/oder steuerung wenigstens eines geräts
CH713793B1 (de) Zentrales Stationsinformationssystem.
DE112007000368T5 (de) Verfahren und System zur Leitung von Information an einen geeigneten Dienstleister
DE112021002610T5 (de) System und Verfahren zur asynchronen Kommunikation von Infusionsinformationen und zur Erlangung von Fernhilfe für eine laufende Infusion
DE202022102083U1 (de) System zur Verwaltung von Patientenanfragen und Dienstleistungen auf einer Online-Plattform für Telemedizin unter Verwendung von maschinellem Lernen
EP3401816A1 (de) Dynamische erstellung von übersichtsnachrichten im gesundheitswesen
EP1351181B1 (de) Computersystem und Verfahren zur Datenerfassung für die Ermittlung des Verlaufs einer chronischen Erkrankung
DE112018005888T5 (de) Datenverarbeitungsvorrichtung, datenverarbeitungsverfahren und datenverarbeitungsprogramm
DE202022107224U1 (de) System zur sicheren Speicherung und Transaktion von Gesundheitsdaten in miteinander verbundenen implantierten medizinischen Geräten und Steuerungsserver
WO2007063057A1 (de) Aktivierungs- und kontrollvorrichtung zur kopplung zweier wechselseitig aktivierbarer automatisierter interventionssysteme
DE202022103482U1 (de) Aufbereitung von Diagnoseinformationen
DE112019003187T5 (de) Kognitive analyse und disambiguierung von elektronischen patientenakten zur darstellung von sachdienlichen informationen für einen medizinischen behandlungsplan
AT12107U1 (de) Datenverarbeitungssystem zur erzeugung eines signals
DE202023100662U1 (de) Ein System zur Fernüberwachung von Hochrisikopatienten mit Hilfe künstlicher Intelligenz
EP1399867A2 (de) Expertensystem zur aufdeckung von kontraindikationen bei begrenztem zugriffsrecht auf patientendaten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09748996

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2744131

Country of ref document: CA

REEP Request for entry into the european phase

Ref document number: 2009748996

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2009748996

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13129895

Country of ref document: US