DE10112409A1

DE10112409A1 - Verfahren und System zur Datenverwaltung

Info

Publication number: DE10112409A1
Application number: DE10112409A
Authority: DE
Original assignee: Creations M GmbH
Current assignee: Creations M GmbH
Priority date: 2001-03-13
Filing date: 2001-03-13
Publication date: 2002-09-19
Anticipated expiration: 2021-03-14
Also published as: WO2002073496A3; WO2002073496A2; DE10112409B4; EP1388116A2

Abstract

Die vorliegende Erfindung betrifft ein Vefahren zur Datenverwaltung, wobei Daten auf mindestens einem mit einer Software (Frontend) versehenen mobilen Rechner (20) eingegeben und bearbeitet werden, Daten auf mindestens einem Zentralrechner (40, 50) mittels einer Software (Backendsystem) gesammelt und gespeichert werden, wobei über mindestens einen lokalen Rechner (30) ein Datenaustausch zwischen dem mindestens einen mobilen Rechner (20) und dem mindestens einen Zentralrechner (40, 50) vorgenommen wird und die Software (Middleware) des lokalen Rechners (30) zumindest auch zur Zwischenübersetzung und Schnittstellenkontrolle dient. Erfindungsgemäß ist vorgesehen, dass auf dem mindestens einen Zentralrechner (40, 50) allgemeine, für jeden mobilen Rechner (20) zugängliche Daten gesammelt und gespeichert werden und dass mittels einer weiteren Software (Customiser) anwendungsspezifische, für einen oder mehrere mobile Rechner (20) individuelle Daten auf einem Rechner (20, 30, 60) gesammelt und gespeichert werden, wobei ein Datenaustausch zwischen dem mobilen Rechner (20) und dem Rechner (20, 30, 60) erfolgt, derart, dass die auf dem mobilen Rechner (20) vorhandene Software (Frontend) anwendungsspezifisch konfiguriert wird.

Description

Die vorliegende Erfindung betrifft ein Verfahren zur Datenverwaltung nach dem Oberbegriff des Anspruchs 1 sowie ein System zur Datenverwaltung nach dem Oberbegriff des Anspruchs 9.

Der Gegenstand der Erfindung betrifft somit mobile Anwendungslösungen zur Datenverwaltung. Aufgrund der mobilen Natur einiger Berufsbilder besteht ein großer Bedarf an derartigen mobilen Anwendungslösungen, bspw. für sogenannte Handheld- oder Westentaschenrechner, die eine höchstmögliche Mobilität gewährleisten. Erwünscht sind hochmobile Anwendungen, die auf mobi len Kleinstgeräten laufen, Gruppenarbeit und Netzwerkfähigkeit sowie eine Anbindung an zentrale Datenbestände ermöglichen.

Ein besonderer Bedarf besteht zum Beispiel im Zusammenhang mit der Verwaltung von Patienten daten in einem Krankenhaus: Ein Arzt will am Bett seines Patienten während des Stationsbesuches eine Diagnose dokumentieren. Mit Hilfe einer mobilen Anwendung lädt er sich vorher die Patien tendaten aus einem zentralen Informationssystem auf seinen mobilen Westentaschenrechner, do kumentiert einfach und schnell mit fertigen Textbausteinen und spielt diese wieder in das Kranken haus-Dokumentationssystem ein. Dort können sie in der gewohnten Form weiterverarbeitet wer den.

Ein derartiges gattungsgemäßes Verfahren bzw. System ist in der WO 99/41682 beschrieben. Das bekannte Verfahren bzw. System betrifft ausschließlich die Verwaltung von Patientendaten im Krankenhaus. Das bekannte System besteht im wesentlichen aus mindestens einem mobilen Rech ner, einem lokalen Anwendungsrechner und mindestens einem Zentralrechner. Der lokale Anwen dungsrechner vermittelt den Datenaustausch zwischen dem mobilen Rechner und dem Zentral rechner, bspw. einer Datenbank mit Patientendaten und stellt diese Patientendaten sowie Form blätter, Eingabemasken u. dgl. zur Eingabe von Patientendaten zur Verfügung. Somit kann der Arzt am Krankenbett Patientendaten abrufen, diese Daten aktualisieren bzw. neue Daten eingeben und auf dem lokalen Anwendungsrechner speichern. Die neuen Daten werden dann weiterverarbeitet, bspw. in eine auf einem Zentralrechner gespeicherte zentrale Patientendatei eingelesen oder neu formatiert, bspw. um die Daten in verschiedenen Datenbanken auf verschiedenen Zentralrechnern abzulegen. Die Datenübertragung und der Datenabgleich zwischen dem mobilen Rechner und dem lokalen Anwendungsrechner können synchron, bspw. über eine Telefon- oder Funkverbindung oder asynchron durch Andocken des mobilen Rechners an ein Terminal erfolgen.

Problematisch bei diesem Lösungsvorschlag ist, dass dieses Verfahren bzw. System nur sehr schwer an die individuellen Bedürfnisse einzelner Nutzer angepasst werden kann. Zwar können mit diesem System vorgegebene Listen gepflegt werden, aber grundsätzlich ist eine Änderung der auf dem mo bilen Rechner ablaufenden Anwendung nur durch eine neue Programmversion möglich. Dies schränkt auch die Anwendung des bekannten Verfahrens bzw. Systems in weiteren Anwendungsbe reichen wie Vertrieb, Lagerhaltung oder Service ein. Bei allen diesen Einsatzgebieten muss zur Um setzung einer möglichst optimalen Lösung eine Verbindung der mobilen Einheit zu den Daten aus zentralen Systemen hergestellt und die Arbeit in der Gruppe ermöglicht werden. In den verschiede nen Einsatzgebieten bestehen jedoch je nach Art der Aufgabenstellung unterschiedliche Anforde rungen an sowohl die mobile Komponente als auch an die Verbindung zu den zentralen Datenbe ständen. Alle bisher verfügbaren Lösungen berücksichtigen lediglich die mobile Komponente als "Einzelplatz", wobei nur ein Datenabgleich mit einem einzelnen Rechner möglich ist. Eine Anpas sung der Einzelplatzversion kann ausschließlich innerhalb der mobilen Anwendung selbst erfolgen, was zeitaufwendig und aufgrund der schlechten Eingabemöglichkeit bei mobilen Kleinstgeräten meist umständlich zu bewerkstelligen ist.

Die Aufgabe der vorliegenden Erfindung besteht somit darin, das bekannte Verfahren bzw. System derart weiter zu entwickeln, dass es in verschiedenen Einsatzgebieten an unterschiedliche Anforde rungen der individuellen Anwender angepasst werden kann.

Damit die Anwendung individuell ausgestaltet werden kann, muss eine entsprechende, leicht zu bedienende und für alle Anwender zentral zu pflegende Anwendungsanpassung ermöglicht werden.

Die Lösung besteht in einem Verfahren mit den Merkmalen des Anspruchs 1 sowie in einem Verfah ren mit den Merkmalen des Anspruchs 9. Erfindungsgemäß ist also ein System vorgesehen, bei dem ein lokaler Rechner bzw. dessen Software (Middleware) die Kommunikation zwischen dem mobilen Rechner und dem Zentralrechner vermittelt, Daten abgleicht, konvertiert und/oder formatiert. Der lokale Rechner dient also vorwiegend als Zwischenübersetzer und Schnittstellenkontrolleur. Neben dem lokalen Rechner ist ein Zwischenrechner mit einer Anwendungssoftware (Customiser) vorgese hen, mit der die Software auf de mobilen Rechner an individuelle Bedürfnisse angepasst wird. Die zwischen dem zentralen Rechner und dem mobilen Rechner über den lokalen Rechner ausge tauschten Daten sind allgemeiner Natur und nicht individualisiert. Beispiele sind allgemeine Patientendaten in einer Krankenhausdatenbank, allgemeine Daten über Lagerbestände, allgemeine statistische Daten, allgemeine Verwaltungs- und Abrechnungsdaten. Die spezielle Anwendungssoftware auf dem Zwischenrechner (Customiser) liefert individualisierte Daten und individuelle Bearbeitungsvorlagen, bspw. anwendungsspezifische Formulare und Datenblätter zum Ausfüllen, standardisierte Formulareinträge, automatisierte Abfrageroutinen, Textbausteine, indivi duelle Daten, Listen und Protokolle, neue Menüstrukturen bzw. Anpassung bestehender Menüs. Damit können die vom Zentralrechner stammenden allgemeinen Daten individuell angepasst, ausgewertet und genutzt werden. Die Anwendungssoftware kann diese individualisierten Daten auch mehreren Nutzern mobiler Rechner mit gleichen Bedürfnissen (bspw. mehreren Ärzten der gleichen Abteilung, mehreren Außendienstmitarbeitern etc.) gleichzeitig zur Verfügung stellen, nachdem die Daten von einem Nutzer angepasst worden sind. Es findet also eine zentrale Anpassung der Software des mobilen Rechners statt. Die Anwendungssoftware erlaubt das einfache Gestalten persönlicher Programme und verarbeitet neue Daten und Programmelemente im Zusammenspiel mit dem Zentralrechner und/oder dem lokalen Rechner.

Die vorliegende Erfindung verfolgt somit einen generischen und modularen Ansatz, d. h. neben der Anbindung an die zentralen Datenbestände existiert eine separate Anwendungssoftware. Mit die ser Software werden typische "Arbeitsdaten", die häufig gebraucht werden, zentral zusammen ge stellt und gepflegt. Diese Daten, aber auch Felder, Konfigurationen, Menüs, Menüstrukturen usw. werden dann auf den mobilen Rechner überspielt. Diese Individualkonfiguration kann durch Ver mittlung eines lokalen Rechners und seiner Software mit einem oder mehreren Zentralrechnern zu sammenarbeiten. Nach der Individualkonfiguration ist also jeder berechtigte Nutzer in der Lage, über den lokalen Rechner und dessen Software allgemeine Daten aus dem Zentralrechner auf den mobilen Rechner zu laden und diese zu bearbeiten. Die bearbeiteten Daten werden rückgespeichert und über den lokalen Rechner dem Zentralrechner zur Verfügung gestellt. Damit kann jeder individuelle Nutzer die für seinen mobilen Rechner vorgesehenen Anwendungen einfach anpassen, z. B. Listen oder Listeneinträge bequem pflegen, so dass seinen Anforderungen individuell Sorge getra gen werden kann.

Die grundlegende Idee der Lösung ist es, dem Nutzer ein einfaches Gestalten persönlicher Pro gramme auf dem mobilen Gerät in einer Form zu ermöglichen, in der dieses Programm dann die neuen Elemente im Zusammenspiel mit z. B. einer zentralen Unternehmensdatenbank weiterhin ver arbeiten kann.

Vorteilhafte Weiterbildungen ergeben sich aus den Unteransprüchen. Die Anbindung der mobilen Komponenten kann über ein Netzwerk erfolgen, so dass auch das Arbeiten in der Gruppe ermög licht wird. Beim Abgleich des mobilen Systems können die Änderungen somit auf alle gewünschten Endgeräte übertragen werden. Dieser Vorgang funktioniert netzweit, so dass die Anpassungen zent ral vorgenommen werden können und anschließend an alle Benutzer automatisch verteilt werden.

Der Customiser kann auf einem Rechner, bspw. einem Server oder auch, insbesondere für kleinere Änderungen, auch auf dem mobilen Gerät installiert sein. Darüber hinaus können Frontend und Middleware oder Frontend und Customiser oder Middleware und Customiser auf demselben Rech ner, bspw. dem lokalen Rechner, dem Zwischenrechner oder auch dem mobilen Rechner installiert sein.

Die Middleware und der Customiser können inklusive der Schnittstellen in der Programmiersprache Java verwirklicht sein, da diese Programmiersprache aufgrund ihrer Datenbank-Schnittstellen und ihrer Portabilität Vorteile in der Anwendung bietet.

Die Verbindung zwischen dem mobilen Rechner und dem lokalen Rechner kann asynchron, bspw. über ein Einsteckmodul oder synchron durch ein Netzwerk, auch eine kabellose Verbindung, erfol gen. Die Kommunikation zwischen dem lokalen Rechner und dem Zentralrechner findet bevorzugt über standardisierte oder individuelle Schnittstellen statt.

Vorzugsweise ist der Zwischenrechner nur einem ausgewählten Benutzerkreis zugänglich, und der Customiser enthält Berechtigungskonzepte und -routinen zur Kontrolle der Zugangsberechtigung der jeweiligen Nutzer.

Ein Ausführungsbeispiel der vorliegenden Erfindung wird im Folgenden anhand der beigefügten Zeichnungen näher erläutert. Es zeigen:

Fig. 1 eine schematische Darstellung eines erfindungsgemäßen Systems zur Datenverwaltung;

Fig. 2 eine schematische Darstellung der Anwendung des erfindungsgemäßen Systems zur Verwaltung von Patientendaten;

Fig. 3 eine schematische Darstellung der Anwendung des erfindungsgemäßen Systems zur Qualitätskontrolle an Fertigungsstraßen;

Fig. 4 eine schematische Darstellung der Anwendung des erfindungsgemäßen Systems für das Paybox-System (Zahlung per Mobiltelefon);

Fig. 5 eine Variante der Anwendung gemäß Fig. 4;

Fig. 6 bis 18 beispielhafte Darstellungen des Bildschirms eines mobilen Rechners für die verschiede nen Anwendungen gemäß den Fig. 1 bis 5.

Das Gesamtsystem 10 besteht aus mehreren Komponenten und Modulen. Jeder Nutzer kommuni ziert mit dem System über einen mobilen Rechner 20 mittels einer Softwarekomponente, im Fol genden Frontend genannt. Der mobile Rechner wiederum kommuniziert mit einem lokalen Rechner 30, auf welchem eine weitere Softwarekomponente, im Folgenden Middleware genannt, installiert ist. Dieser lokale Rechner 30 stellt schließlich die Verbindung mit dem oder den Zentralrechnern 40, 50, her und vermittelt den Datenaustausch zwischen mobilem Rechner 20 und Zentralrechnern 40, 50. Auf dem oder den Zentralrechnern 40, 50 können verschiedene Systeme, bspw. Datenbanksys teme, installiert sein, die in Folgenden zusammenfassend als Backendsysteme bezeichnet werden. Zur Anpassung des Frontend an individuelle Anforderungen des jeweiligen Nutzers dient eine spezielle Anwendungskomponente, im Folgenden Customiser genannt, welche auf einem Zwischen rechner 60 installiert ist, der mit dem lokalen Rechner 30 kommuniziert.

Selbstverständlich können Customiser und Middleware auf einem Rechner installiert sein, ebenso wie bspw. Frontend und Customiser oder Frontend und Middleware.

Frontend

Das Frontend ist die Benutzerschnittstelle für den Anwender. Hiermit werden sowohl Daten ange zeigt als auch durch den Nutzer manipuliert. Dazu werden verschiedene Masken und Listen zur Verfügung gestellt. Das Design der Benutzerschnittstelle ist speziell für die kleinen Endgeräte mit meist nur begrenztem Display optimiert.

Je nach Anforderung an die Mobilität und die Datenverfügbarkeit kann das Frontend synchron oder asynchron mit dem Backendsystem abgeglichen werden. Der synchrone Abgleich bedeutet, dass der mobile Rechner 20 für den Einsatz in einem kabellosen Netzwerk geeignet ist. Der Nutzer ist somit ständig online über den lokalen Rechner 30 mit dem oder den Zentralrechnern 40, 50 verbunden, so dass Änderungen sofort in die Middleware und/oder in das Backendsystem übernommen werden. Beim asynchronen Abgleich werden die Daten über eine stationäre Verbindung mit dem lokalen Rechner 30 abgeglichen. Verändert der Nutzer Daten auf dem mobilen Gerät, so werden diese Än derungen nach einem erneuten Abgleich in der Middleware und/oder im Backendsystem wirksam.

Die Frontendkomponente läuft generell auf allen mobilen Rechnern, wie Mobiltelefonen (bspw. mit UMTS-Standard), Handheldgeräten, Palmtops oder Laptops. Bevorzugt werden zur Zeit sogenannte Handheldgeräte (oder auch Westentaschenrechner, Personal Digital Assistants (PDA) etc.). Der meistverbreitete PDA wird von der Firma Palm™ hergestellt und mit dem Palm Operating System (Palm OS) betrieben. Weitere Palm OS Geräte werden u. a. von den Firmen Handspring und TRG her gestellt. Neben den Palm OS Geräten kann die Frontendhardware auf dem Betriebssystem WinCE der Firma Microsoft betrieben werden. Hier gibt es eine Vielzahl von Herstellern. Zukünftige Ent wicklungen in diesem Bereich sind vor allem in der Migration von handelsüblichen Handys zu mo bilen Kleinstcomputern zu erwarten.

Die Verbindung der mobilen Rechner 20 mit dem lokalen Rechner 30 kann auf verschiedene Weisen erfolgen. Sollen die mobilen Rechner 20 über ein kabelloses Netzwerk eingebunden werden, so sind z. B. DECT- oder Bluetoothnetze geeignet. Erfolgt der Datenabgleich über eine feste Station, so wird diese, bzw. der an die mobile Station angebundene PC über ein Netzwerk mit dem lokalen Rechner 30 verbunden. Auch eine Verbindung über GSM ist möglich. Ferner ist mit zukünftigen Entwicklun gen zu rechnen wie z. B. Kombinationen (sog. Clones) aus den heutigen Handys und mobilen Com putern.

Das Frontend kann vorzugsweise für mobile Kleincomputer, bspw. mit den Betriebssystemen PalmOS, Windows CE oder EPOC, verwirklicht werden. Durch die Verwendung einer portablen Pro grammiersprache, bspw. Java, ist es leicht möglich, andere existierende und neue Hardware-Geräte zu unterstützen. Das Frontend kann über eine eigens definierte Schnittstelle die durch den Custo miser erzeugten Anwendungsvorgaben (welche Listen wohin, welche Menüs sollen welche Funktio nen erfüllen etc.) in Form einer Anwendungsbeschreibung einlesen. Die Anwendungsbeschreibung entspricht daher in einem gewissen Sinne einer AP) (Application Programming Interface). Nach Ein richtung des Frontends werden über dieses die Daten, die von der Middleware geliefert wurden, verarbeitet, modifiziert und wieder an die Middleware zurückgereicht. In der Version für den loka len Rechner 30 kann diese Funktionalität über Java Beans und in der Version für den mobilen Rechner 20 in einer direkten Form in eigenen Tabellen des mobilen Rechners realisiert werden.

Middleware

Damit das Frontend mit dem jeweils vorhandenen Backendsystem reibungslos kommunizieren kann, wird eine geeignete Middleware eingesetzt. Die Middleware wird auf einem lokalen Rechner 30 ausgeführt, der vorzugsweise je nach Ausprägung und Größe des Gesamtsystems ein handelsübli cher zentraler Server oder ein per Netzwerk angebundener Personal Computer (PC) sein kann. Be triebssystemseitig sind hier alle Lösungen möglich, vorzugsweise solche, auf denen die Program miersprache Java zur Verfügung steht.

Die Kommunikation mit dem oder den Zentralrechnern 40, 50, also den Backendsystemen, erfolgt entweder auf der Basis von standardisierten Schnittstellen oder auf der Basis von speziell entwi ckelten Schnittstellenlösungen. In beiden Fällen erfolgt eine Übersetzung des benötigten Auszugs aus dem Datenmodell des Backendsystems in das Datenmodell des Frontendsystems und umge kehrt. Diese Übersetzung oder Formatierung wird von der Middleware vorgenommen.

Zusätzlich hat das Middleware-Programm auch vollständige Schnittstellen zu dem mobilen Rech ner 20 (bei einem Palm™ wäre dies z. B. eine Erweiterung des sogenannten "HotSync"-Programmes). Damit ist gewährleistet, dass die Daten, die vom Customizer und von dem oder den Zentralrechnern 40, 50, also verschiedenen Backendsystemen (z. B. SAP) kommen, in geeigneter Form zusammenge stellt werden und in der zusammengestellten Form dem mobilen Rechner 20 zur Verfügung gestellt werden.

Die Middleware kann in mehreren Versionen verwirklicht werden, bspw. je eine für den lokalen Rechner 30 und/oder Zwischenrechner 60 (z. Bsp. für die Betriebssysteme Linux und Windows) und für den mobilen Rechner 20. Bei letzterer handelt es sich bevorzugt um eine kleinere Middleware- Komponente, die bspw. auf einem Handheld läuft.

Die für den lokalen Rechner 30 bzw. den Zwischenrechner 60 vorgesehene Komponente der Midd leware weist neben verschiedenen anderen Schnittstellen bspw. auch BAPI-Schnittstellen zu SAP R/3 in den Versionen 4.x der Module mm und IS-H auf. Hierzu wurden entlang der Programmier richtlinien von SAP Business-Objekte kompiliert, die über Java Beans ansprechbar sind. In Richtung des Frontends (bspw. PDA der Fa. Palm) wird auch über Java eine Verbindungsschnittstelle ange sprochen, die sich direkt in das HotSync-Protokoll des PDA einklinkt und damit die Synchronisation zum Frontend ermöglicht.

Innerhalb der Middleware läuft neben einem hochkomplexen Programmteil auch eine relationale Datenbank, die ein Ansprechen ihrer Tabellen über JDBC ermöglicht. In diese Datenbank werden von den Funktionen der Middleware die Daten aus verschiedenen Übertragungen vom Frontend auf Konsistenz geprüft und zusammengeführt. Zusätzlich spricht der Customiser über Java Beans diese Datenbank an, um hier eine Datenbank-unterstützte Katalogpflege zu ermöglichen. Auch die vom Benutzer auf dem mobilen Rechner 20 gewünschte Menü-Struktur wird in dieser Datenbank ge speichert. Aufgrund der nutzerspezifisch anzupassenden Menüstruktur wird die Datenbank direkt über JDBC angesprochen.

Die PDA-Komponente der Middleware ermöglicht unter der Verarbeitung der vorher durch den Customiser eingestellten Daten und Menüstrukturen die Verbindung zu einem Zentraldatenbank- System. Hierzu werden die Daten des Frontends mit den vom Customiser zur Verfügung gestellten Daten zusammengesetzt und per synchronem oder asynchronem Protokoll verarbeitet. Diese Versi on kann bspw. in einem Basic-Dialekt realisiert sein, da mit der aktuell verfügbaren Prozessortech nologie keine JVM (Java Virtual Machine, die Laufzeitgrundlage von Java auf einem Computer) mit akzeptabler Performance verfügbar ist.

Customiser

Je nach Einsatzgebiet und Aufgabenstellung soll das Frontend, also die konkrete Anwendung am mobilen Rechner 20, an die individuellen Vorgaben und Bedürfnisse jedes einzelnen Nutzers ange passt werden. Hierzu dient der Customiser. Durch ihn wird eine Anpassung der Frontendkomponen te und damit des gesamten mobilen Systems von einem zentralen Punkt aus vorgenommen. Der Customiser läuft in der Regel auf einem PC oder einem Server (dies kann auch der PC oder Server sein, auf dem die Middleware installiert ist), der im Vergleich zu mobilen Endgeräten eine wesent lich effizientere Bearbeitung der Daten ermöglicht, kann aber auch, bei kleineren Anwendungen, auf dem mobilen Rechner 20 installiert sein.

Im Customiser werden die individuellen Daten bzw. die individuellen Listen ausgewählt und bear beitet, die das Frontend auf dem mobilen Rechner 20 zur Verfügung stellen soll. Auch eine Anpas sung der Menüs oder der Menüstruktur kann hier erfolgen. Nach einem Abgleich der Frontendkom ponente mit der Middleware und/oder den Backendsystemen stehen die Änderungen den Endbe nutzern zur Verfügung. Vorteilhaft ist in diesem Zusammenhang insbesondere, dass Listen etc. nicht von einzelnen Anwendern gepflegt werden müssen, sondern allen Nutzern zentral zur Verfü gung gestellt werden, da sie von einem zentralen Administrator gepflegt werden. In der Regel hat nur ein ausgewählter Nutzerkreis Zugang zum Customiser. Dieser führt die entsprechenden Ände rungen durch und macht sie somit allen mobil angeschlossenen Anwendern verfügbar. Die entspre chenden Berechtigungskonzepte sind ein Bestandteil des Programms.

Die Daten des Customisers werden in einer dafür vorgesehenen und leicht erweiterbaren Daten bankstruktur gehalten. Zur Neuanlage bzw. zur Änderung von individuellen Vorgaben für die mobile Anwendung steht eine entsprechende Benutzerschnittstelle zur Verfügung, die es dem Anwender ermöglicht, Daten schnell und bequem zu ändern oder anzufügen.

Auch der Customiser kann bspw. in einer Version für den Zwischenrechner 60 und/oder lokalen Rechner 20 oder in einer Version für den mobilen Rechner 20 zur Verfügung gestellt werden.

Die Version für den Zwischenrechner 60 bzw. den lokalen Rechner 30 kann ebenfalls in Java reali siert sein. Der Customiser übersetzt eine benutzerfreundliche Oberfläche zum Beispiel mit Hilfe von Clickboxen, geschrieben mit den Java Swing-Bibliotheken, in eine Struktur von Textbausteinen, Lis ten und Menüs, die beim nächsten Synchronisationsbefehl auf dem mobilen Rechner 20 sichtbar werden. Um die gleichzeitige Unterstützung mehrerer mobiler Rechner 20 zu gewährleisten, wird die Ablage der vom Customiser zur Verfügung gestellten Daten in einer eigenen Datenbank sicher gestellt. Notwendige neue Tabellen werden hier über JDBC erstellt, ansonsten über die generierten Beans angesprochen. Diese Datenbankinhalte werden dann durch ein Funktionsset im Customiser, das die Textbausteinen und Menüstrukturen ausliest, für das Frontend des mobilen Rechners 20 umgesetzt, wobei vorher eine Konsistenzprüfung auf die Datenstrukturen des lokalen Rechners 30 bzw. der Middleware erfolgt. Bei der Umsetzung auf mehrere mobile Rechner 20 wird jeweils dieses Funktionsset angesprochen, das dann die für den entsprechenden mobilen Rechner 20 gewünschte Listen-, Textbaustein- und Menüstrukturen übersetzt und installiert.

Die kleinere Version des Customisers für den mobilen Rechner 20, insbesonderen einen PDA, unter stützt vorzugsweise keine Definition von Menüstrukturen, sondern nur die Definierbarkeit von Lis ten und Textbausteinen. Sie ist in dem oben genannten Basic-Dialekt verwirklicht, ansonsten struk turell der größeren Version des Customiser ähnlich, wenn auch sehr vereinfacht.

Backendsysteme

Als Backendsysteme kommen verschiedene zentrale Datenhaltungssysteme in Frage. Dazu gehören u. a. Krankenhausinformationssysteme (z. B. SAP R/3 mit den Modulen IS-H und IS-H*med), Enterpri se-Ressource-Planning (ERP) Systeme, Vertriebsinformationssysteme und Customer-Relationship- Management (CRM) Systeme. Die Anbindung des lokalen Rechners 30 zu den Zentralrechnern 40, 50 bzw. den Backendsystemen erfolgt vorzugsweise über ein Netzwerk. Der Datenaustausch erfolgt entweder über eine Standardschnittstelle oder eine speziell erstellte Kommunikationssoftware.

Das erfindungsgemäße Verfahren kann wie folgt durchgeführt werden: Zunächst legitimiert sich der Nutzer an dem jeweiligen mobilen Rechner 20 mit Benutzername und Kennwort. Bei erfolgrei cher Anmeldung erhält er nach einem Abgleich mit der Middleware des lokalen Rechners 30 die ak tuell verfügbare Information aus dem zentralen Datenbestand des Backendsystems (z. B. Kundenda ten) sowie aus dem Customiser (z. B. neue Vorgabetabellen und Vorlagen). Die Informationen wer den dem Anwender in Listenform oder in Form von Auswahlfeldern zur Verfügung gestellt. Such funktionen über den Datenbestand oder über einzelne Listen stehen ebenso zur Verfügung. Zur Manipulation oder Neueingabe von Daten stehen dem Anwender verschiedene Werkzeuge, bspw. Auswahllisten, vordefinierte Textbausteine, Ja-Nein-Felder und die Eingabe von freiem Text, zur Verfügung. Nach erfolgten Änderungen oder Neueingaben wird das Frontend wiederum mit dem Backendsystem abgeglichen, so dass die zentral gehaltenen Daten wieder auf den aktuell gültigen Stand gebracht werden.

Will ein Anwender einen Abgleich der Daten des Frontend mit dem Backendsystem durchführen, wird zunächst eine Netzwerkverbindung zwischen dem mobilen Rechner 20 und dem lokalen Rech ner 30 hergestellt. Dort wird dann die Anfrage bearbeitet. Sollen Daten aus dem Backendsystem angezeigt oder geändert werden, stellt der lokale Rechner 30 eine Verbindung zu dem oder den Zentralrechnern 40, 50, also zum Backendsystem her, vorzugsweise über ein Netzwerk. Anschlie ßend werden die angeforderten Daten aus dem Backendsystem geladen bzw. geänderte Daten in das Backendsystem zurückgeschrieben. Die Middleware sorgt auch für die Verarbeitung eines Ab gleichs mit den Daten des Customiser.

Auf dem mobilen Gerät können die Daten dann mit dem Frontend vor Ort, also z. B. am Krankenbett oder beim Kunden, bearbeitet werden, es können Dokumentationen erstellt, Kalkukationen durchgeführt oder Anfragen ausgeführt werden. Die so bearbeiteten Daten werden dann über die Middleware zwischenformatiert und zurück auf den oder die Zentralrechner 40, 50, bspw. eine eigene Datenbank oder eine Zentraldatenbank (z. B. SAP) übertragen.

Im Folgenden sollen verschiedene Anwendungsbeispiele des erfindungsgemäßen Systems bzw. Ver fahrens beschrieben werden.

1. Verwaltung von Patientendaten (vgl. Fig. 2, Fig. 6 bis 14)

Die Funktion des Customisers für diese Anwendung lässt sich wie folgt beschreiben: Jede Fachrich tung erbringt verschiedene Leistungen und muss unterschiedliche Diagnosen stellen. Im Customiser werden die für die jeweilige Abteilung relevanten Diagnosen, Medikamente und Leistungen in Form von Listen erstellt. Des weiteren können neue Listen zur Speicherung von Textbausteinen für z. B. Arztbriefe, Stationslisten oder Telefonnummern erstellt werden, aber auch Listen mit den für die Anwender häufigsten ICD10-Verschlüsselungscodes und OPS zur automatischen Verschlüsselung von Diagnosen und Leistungen direkt auf dem mobilen Rechner 20. Dies erfolgt im Normalfall le diglich auf dem lokalen Rechner 30, bspw. einem Abteilungsserver. Nach einem Abgleich des mobi len Rechners 20 mit dem lokalen Rechner 30 erhält jeder das System nutzende Arzt automatisch die aktuelle Fassung der Listen und Textbausteine.

Vor dem Patientenbesuch gibt der Arzt (bei einem neu aufgenommenen Patienten) die relevanten Patientendaten in ein Formular ein (vgl. Fig. 6), welches vom Customiser abteilungsspezifisch zur Verfügung gestellt wird. Andernfalls gleicht der Arzt (z. B. asynchron) auf seinem mobilen Rechner 20 den für ihn relevanten Patientendatenbestand ab (vgl. Fig. 7, 8). Damit stehen ihm die aktu ellen Patientendaten zur Verfügung. Im Laufe des Patientenbesuchs erfasst er z. B. Diagnose- und Leistungsdaten (vgl. Fig. 9) und fügt Anordnungen ein. Dazu stellt ihm der Customiser z. B. eine Liste der möglichen bzw. in der entsprechenden Fachrichtung häufigsten Diagnosen (vgl. Fig. 10, 11) und Medikamente (Fig. 12, 13, bspw. die gängigsten Analgetika) sowie ein auf seine Abteilung angepasstes Set an Textbausteinen und weiteren Listen zur Verfügung. Der Arzt braucht also die einzelnen Positionen nicht mehr von Hand in den mobilen Rechner 20 einzugeben, sondern es genügt ein einfaches Antippen einer Position in einer Liste. Nach erfolgtem Patientenbesuch führt er wiederum einen Abgleich durch (vgl. Fig. 14). Die neuen Daten sind damit zur weiteren Bearbeitung im oder in den Zentralrechnern 40, bspw. im Krankenhausinformationssystem, abge legt.

Beim ersten Abgleich werden vom lokalen Rechner 30 zunächst Daten vom mobilen Rechner 20 bzw. vom Frontend angefordert. Die Middleware überprüft die Legitimation des Arztes und stellt die Verbindung zum Zentralrechner 40, 50, bspw. zum Krankenhausinformationssystem (KIS) her, um die Daten (z. B. Patientendaten) an den mobilen Rechner 20 bzw. das Frontend zu übertragen. Die Verbindung zum KIS wird z. B. über eine standardisierte HL7-Schnittstelle hergestellt. Nach dem Patientenbesuch des Arztes mit z. B. Dokumentationen oder Laboranforderungen auf dem mobilen Rechner 20 bzw. Frontend erfolgt ein erneuter Abgleich der Daten des mobilen Rechners 20 in Richtung zum KIS über den lokalen Rechner 20 bzw. die Middleware. Sollen neue, individuell ange passte Listen (z. B. fachrichtungsspezifische Diagnosen) oder Anwendungsdaten auf den mobilen Rechner 20 bzw. das Frontend eingespielt werden, erfolgt über die Middleware ein Abgleich mit den Daten des Customisers.

2. Kontrolle von Fertigungsstraßen (Fig. 3)

Entlang einer Fertigungsstraße 80, bspw. in der Automobilproduktion, sind an einzelnen Ferti gungsetappen 80a, 80b, 80c Qualitätskontrollen eingerichtet. Jeder Kontrollpunkt ist mit einem mobilen Rechner 20 ausgerüstet, welcher über einen eigenen lokalen Rechner und Customiser mit spezifischen Daten (Tabellen, Listen etc.) für die vorgegebene Qualitätskontrolle versorgt wird. Selbstverständlich können die einzelnen lokalen Rechner 30 und/oder Customiser auf einem ge meinsamen Rechner, bspw. einem Server, abgelegt sein. Jeder Nutzer an jedem Kontrollpunkt gibt für jedes kontrollierte Produkt die entsprechenden Daten in den mobilen Rechner ein bzw. füllt die vom jeweiligen Customiser vorgegebenen Formulare aus. Die Daten werden über den oder die loka len Rechner 30 zu einem Zentralrechner 50 gesendet, welcher die Daten für jedes Produkt zusam menführt und auswertet. Der lokale Rechner 30 oder der Zentralrechner 50 liefern auch für jedes Produkt am Ende der Fertigungsstraße einen Qualitätsbericht mit einem aufsummierten Fehlerpro tokoll, d. h. den jeweiligen, an den einen Kontrollpunkten ermittelten Fehlermeldungen, der am En de der Fertigungsstraße ausgedruckt wird.

3. Außendienst (Fig. 1)

Mit dem erfindungsgemäßen System bzw. Verfahren können Außendienstmitarbeiter mit dem mo bilen Rechner 20 bspw. Lagerbestände abfragen oder Informationen zu Angeboten und Konditionen einholen und Bestellungen aufgeben. Je nach Aufgabengebiet liefert der Customiser bspw. Antwor ten zu FAQs der Kunden, automatisierte Lagerbestandsabfragen, wobei die am häufigsten gefragten Produkte zuerst gelistet werden, Textbausteine für häufige Abfragen am Zentralrechner oder häufi ge Bestellungen, etc. Das erfindungsgemäße System kann hier also bspw. als Servicesystem, CRM- Modul (customer relationship management) oder als mobiles Bestell- bzw. Kaufsystem (Sales- System) dienen.

4. Bezahlen von Taxifahrten mit dem Paybox-System (Fig. 4)

In diesem Fall ist der Taxifahrer der Nutzer des mobilen Rechners 20, der gleichzeitig als Zwischen rechner 60 dient, weil der Customiser im mobilen Rechner integriert ist. Der Customiser stellt die individuellen Daten des Taxis bzw. Taxifahrers zur Verfügung, während das Frontend den Rech nungsbetrag ermittelt und bspw. über ein GSM-Modul die Telefonverbindung zum lokalen Rechner 30 herstellt. Der lokale Rechner 30 wiederum vermittelt zwischen den verschiedenen Frontends einzelner mobiler Rechner 20 (z. Bsp. Verschiedener Taxiunternehmen) und stellt die Telefonverbin dung zum Paybox-Zentralrechner her, der hier als Zentralrechner 40 fungiert. Dann kann der Rück ruf auf das Mobiltelefon des Fahrgastes erfolgen, mit dem dieser die Zahlung bestätigt.

5. Bezahlen von Lieferdiensten mit Paybox am Beispiel eines Pizza-Service (Fig. 5, Fig. 15 bis 18)

Hier ist der Bote des Lieferdienstes der Nutzer des mobilen Rechners 20. Über den Customiser wird dem mobilen Rechner die Speise- und Getränkekarte des Lieferdienstes samt Preisen mittels Text bausteinen zur Verfügung gestellt. Das Frontend enthält ein Programm zur Ermittlung des Rech nungsbetrages sowie die Middleware zur Herstellung der Telefonverbindung mit dem Paybox- Zentralrechner 40. Zur Bezahlung des Rechnungsbetrages tippt der Bote die bestellten Speisen im mobilen Rechner an (Fig. 15, 16). Das Frontend ermittelt den Rechnungsbetrag (vgl. Fig. 17), nimmt Verbindung mit dem Paybox-Zentralrechner auf (vgl. Fig. 18) und übermittelt die Zah lungsdaten des Kunden. Dann erfolgt wieder der Rückruf vom Zentralrechner 40 zum Mobiltelefon des Kunden zur Abbuchungsbestätigung.

Claims

1. Verfahren zur Datenverwaltung, wobei
Daten auf mindestens einem mit einer Software (Frontend) versehenen mobilen Rechner (20) eingegeben und bearbeitet werden,
Daten auf mindestens einem Zentralrechner (40, 50) mittels einer Software (Backendsys tem) gesammelt und gespeichert werden,
wobei über mindestens einen lokalen Rechner (30) ein Datenaustausch zwischen dem mindestens einen mobilen Rechner (20) und dem mindestens einen Zentralrechner (40, 50) vorgenommen wird und die Software (Middleware) des lokalen Rechners (30) zumin dest auch zur Zwischenübersetzung und Schnittstellenkontrolle dient,
dadurch gekennzeichnet, dass
auf dem mindestens einen Zentralrechner (40, 50) allgemeine, für jeden mobilen Rechner (20) zugängliche Daten gesammelt und gespeichert werden,
und dass mittels einer weiteren Software (Customiser) anwendungsspezifische, für einen oder mehrere mobile Rechner (20) individuelle Daten auf einem Rechner (20, 30, 60) ge sammelt und gespeichert werden,
wobei ein Datenaustausch zwischen dem mobilen Rechner (20) und dem Rechner (20, 30, 60) erfolgt, derart, dass die auf dem mobilen Rechner (20) vorhandene Software (Fron tend) anwendungsspezifisch konfiguriert wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Datenaustausch zwischen dem mobilen Rechner (20) und dem Rechner (20, 30, 60) über die Software (Middleware) des lo kalen Rechners (30) erfolgt.

3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die wei tere Software (Customiser) auf einem separaten Zwischenrechner (60) gespeichert wird.

4. Verfahren nach einem der Ansprüche 1 und 2, dadurch gekennzeichnet, dass die weitere Software (Customiser) auf dem lokalen Rechner (30) gespeichert wird.

5. Verfahren nach einem der Ansprüche 1 und 2, dadurch gekennzeichnet, dass die weitere Software (Customiser) auf dem mobilen Rechner (20) gespeichert wird.

6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Fron tend und Customiser oder Frontend und Middleware oder Customiser und Middleware auf demselben Rechner gespeichert werden.

7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die wei tere Software (Customiser) mit mindestens einem Berechtigungskonzept zur Zugangskontrol le versehen wird.

8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der mindestens eine mobile Rechner (20) über ein Netzwerk an den mindestens einen lokalen Rechner (30) und/oder den mindestens einen Zwischenrechner (60) und oder den Zentral rechner (40, 50) angebunden wird.

9. System zur Datenverwaltung mit
mindestens einem mit einer Software (Frontend) versehenen mobilen Rechner (20) zur Eingabe und Speicherung von Daten,
mindestens einem Zentralrechner (40, 50) mit einer Software (Backendsystem) zum Sam meln und zur Speicherung von Daten,
mindestens einen lokalen Rechner (30) zum Datenaustausch zwischen dem mindestens ei nen mobilen Rechner (20) und dem mindestens einen Zentralrechner (40, 50), wobei die Software (Middleware) des lokalen Rechners (30) zumindest auch zur Zwischenüberset zung und Schnittstellenkontrolle dient,
dadurch gekennzeichnet, dass
eine weitere Software (Customiser) vorgesehen ist, mit der anwendungsspezifische, für ei nen oder mehrere mobile Rechner (20) individuelle Daten auf einem Rechner (20, 30, 60) gesammelt und gespeichert werden können,
wobei ein Datenaustausch zwischen dem mobilen Rechner (20) und dem Rechner (20, 30, 60) erfolgt, derart, dass die auf dem mobilen Rechner (20) vorhandene Software (Fron tend) anwendungsspezifisch konfiguriert ist.

10. System nach Anspruch 9, dadurch gekennzeichnet, dass ein Zwischenrechner (60) vorgesehen ist, auf dem die weitere Software (Customiser) gespeichert ist.

11. System nach einem der Ansprüche 9 und 10, dadurch gekennzeichnet, dass Frontend und Customiser oder Frontend und Middleware oder Customiser und Middleware auf demselben Rechner gespeichert sind.

12. System nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass die weitere Soft ware (Customiser) mit mindestens einem Berechtigungskonzept zur Zugangskontrolle verse hen ist.

13. System nach einem der Ansprüche 9 bis 12, dadurch gekennzeichnet, dass der mindestens ei ne mobile Rechner (20) über ein Netzwerk an den mindestens einen lokalen Rechner (30) und/oder den mindestens einen Zwischenrechner (60) und oder den Zentralrechner (40, 50) angebunden ist.

14. System nach einem der Ansprüche 9 bis 13, dadurch gekennzeichnet, dass Frontend und/oder Middleware und/oder Customiser in der Programmiersprache Java realisiert sind.

15. Verwendung des Verfahrens nach einem der Ansprüche 1 bis 8 und/oder des Systems nach einem der Ansprüche 9 bis 14 zur Verwaltung von Patientendaten in einem Krankenhaus.

16. Verwendung des Verfahrens nach einem der Ansprüche 1 bis 8 und/oder des Systems nach einem der Ansprüche 9 bis 14 für den Zahlungsverkehr mittels Paybox-System.

17. Verwendung des Verfahrens nach einem der Ansprüche 1 bis 8 und/oder des Systems nach einem der Ansprüche 9 bis 14 zur Verwaltung von Lager- und Bestelldaten.

18. Verwendung des Verfahrens nach einem der Ansprüche 1 bis 8 und/oder des Systems nach einem der Ansprüche 9 bis 14 zur Qualitätskontrolle in der Produktion, insbesondere an Ferti gungsstraßen.

19. Verwendung des Verfahrens nach einem der Ansprüche 1 bis 8 und/oder des Systems nach einem der Ansprüche 9 bis 14 als Kaufsystem (Sales-System)-, CRM- und/oder Servicesystem.