-
Gebiet der
Erfindung
-
Die
Erfindung betrifft ganz allgemein das Gebiet von Informationssystemen.
Insbesondere betrifft die vorliegende Erfindung ein System und Verfahren
zur Erleichterung eines visuellen Vergleichs von Eingangsdaten mit
bestehenden Daten.
-
HINTERGRUND
ZU DER ERFINDUNG
-
Gegenwärtige Systeme
zur Übertragung
von Daten in bestehende elektronische Datenbanken ermöglichen
es Benutzern nicht ohne weiteres, Eingangsdaten mit bestehenden
Daten visuell zu vergleichen, um Daten auszuwählen, die aktualisiert werden
sollen. Es ist daher aufwändiger
manueller Eingriff erforderlich, um zu bestimmen, in welcher Weise
Eingangsdaten einzusetzen sind, die keine vollständige und automatisierte Aktualisierung
für die
bestehenden Daten bilden. Ein solches Eingreifen kann sehr zeitaufwendig
sein und gegebenenfalls den Einsatz manueller Dateneingabetechniken
erfordern. Obwohl automatisierte Abgleichtechniken eingesetzt werden
können,
mit dem Ziel, zu bestimmen, ob ein oder mehrere Datenfelder aktualisiert
werden sollten, erfüllen
in vielen Fällen
menschliche Datennutzer innerhalb einer Organisation den Zweck einer Datenabgleicheinrichtung
am besten. Ein Mensch ist in der Lage, in einer sehr zuverlässigen Weise
nach Betrachten der Daten intuitiv Folgerungen zu ziehen. Er braucht keine
extensiven Datennachforschungen durchzuführen oder komplexe Algorithmen
zu benutzen; er setzt ganz einfach seine bisherige Erfahrung und
sein Wissen ein, um die richtige Entscheidung zu treffen.
-
Falls
ein Benutzer einer bestehenden elektronischen Datenbank eingehende
Daten benutzen möchte, um
bestehende Daten zu aktualisieren, kann im gegenwärtigen Stand
der Technik ein Abbildungsverfahren verwendet werden, das logische
Regeln verwendet, um die Disposition der Daten vorzubestimmen. Allerdings steht
dem Endbenutzer keine Möglichkeit
zur Verfügung,
die Daten vor einer Aktualisierung durchzusehen, um im erforderlichen
Fall eine abweichende Wahl für
ein spezielles Datenfeld treffen zu können. Statt dessen wird häufig eine
manuelle Liste von Eingangsdatenwerten erzeugt, die ein spezielles
Kriterium für
eine Disposition, d.h. "Abweichungsdaten", nicht erfüllen, und
diese Liste muss dann überprüft werden.
-
Häufig kann
die Überprüfung einer
derartigen manuellen Liste beinhalten, dass ein Belegschaftsmitglied
der Organisation ein manuelles Nachschlagen der bestehenden Daten
durchführt,
um die Abweichungsdaten mit den bestehenden Daten zu vergleichen
und anschließend
zu bestimmen, wie die Abweichungsdaten, so vorhanden, verwendet
werden sollten. Diese Bestimmung wird in der Regel anschließend manuell
notiert, und ein nachfolgender manueller Dateneingabeschritt, wird
gewöhnlich
durchgeführt,
um bestehende Daten zu aktualisieren oder, um neue Datenfelder oder
neue Datensätze
zu erzeugen, um die Abweichungsdaten festzuhalten, falls die Abweichungsdaten
in der bestehenden elektronischen Datenbank noch nicht vorhanden sind,
eine Speicherung derselben darin jedoch gewünscht ist.
-
Darüber hinaus
besteht in vielen Datenbanken, z.B. Gesundheitsfürsorgedatenbanken, ein Bedarf, über eine
große
Vielfalt an Kriterien zum Abgleichen von Eingangsdaten mit bestehenden
Daten verfügen
zu können.
Herkömmliche
Systeme und Anwendungen von Gesundheitsfürsorgeunternehmen lassen sich
häufig nur
sehr beschränkt
abgleichen und erlauben die Durchführung eines Abgleichs lediglich
basierend auf einem vorbestimmten Patientenkennzeichen, z.B. dem
Namen des Patienten oder einer eindeutigen Krankenblattnummer, und
dergleichen. Außerdem
werden die Eingangsdaten in vielfältigen Transaktionsformaten
empfangen, z.B. in unterschiedlichen Versionen von HL7- und ANSI-X12-Formaten
sowie in Formaten, deren Natur in höherem Maße anwenderspezifisch ist.
Für jeden
Typ von Format und Transaktion besteht gegenwärtig kaum eine Möglichkeit,
anzuzeigen, welche Datenfelder für
das bestehende Gesundheitsfürsorgesystem
als Abgleichfelder berücksichtigt
werden sollten, und auf welche Weise das Abgleichen stattfinden
soll. Außerdem besteht
ein Bedarf, über
die aktuellsten Informationen zu verfügen, die sowohl für die Finanzen
der Gesundheitsfürsorgeorganisation
als auch für
die Gesundheit der Patienten von großer Bedeutung sein können. Durch eine
Beschleunigung des Aktualisierungsverfahrens werden die Dienstleister
und die Belegschaft von Gesundheitsfürsorgeorganisationen Zugriff
auf die aktuellsten Daten haben.
-
KURZDARSTELLUNG
DER ERFINDUNG
-
In
einem Aspekt betrifft die vorliegende Erfindung ein Verfahren zum
Erleichtern eines visuellen Vergleichs einer Anzahl von Eingangsdatenwerten
mit einer Anzahl von Zieldatenwerten. Die Anzahl von Eingangsdatenwerten
sind jeweils einer Anzahl von Eingangsdatenfeldern zugeordnet, und
die Anzahl von Zieldatenwerten sind jeweils einer Anzahl von Zieldatenfeldern
zugeordnet und in mindestens einem Zieldatenspeicher gespeichert.
Das Verfahren beinhaltet die Schritte: Empfangen einer Auswahl von
wenigstens einem Eingangsdatenfeld aus der Anzahl von Eingangsdatenfeldern über eine
erste Benutzerschnittstelle. Die Anzahl von Zieldatenwerten werden
als Funktion des wenigstens einen ausgewählten Eingangsdatenfeldes aus
dem wenigstens einen Zieldatenspeicher ausgelesen. Die Anzahl von
Zieldatenwerten und die Anzahl von Eingangsdatenwerten werden gleichzeitig
miteinander auf einem Bildschirm abgebildet, um einen visuellen
Vergleich der Anzahl von Zieldatenwerten und der Anzahl von Eingangsdatenwerten
zu erleichtern.
-
In
einem weiteren Aspekt betrifft die vorliegende Erfindung ein System
zur Erleichterung eines visuellen Vergleichs einer Anzahl von Eingangsdatenwerten
mit einer jeweils entsprechenden Anzahl von Zieldatenwerten. Die
Eingangsdatenwerte werden jeweils Eingangsdatenfeldern zugeordnet,
und die Zieldatenwerte werden jeweils Zieldatenfeldern zugeordnet.
Das System enthält
ein erstes Mittel zum Anzeigen der Anzahl von Zieldatenwerten und
der Anzahl von Eingangsdatenwerten im Wesentlichen Seite an Seite,
um einen visuellen Vergleich von Werten derselben Art aus der Anzahl
von Eingangsdatenwerten und der Anzahl von Zieldatenwerten zu erleichtern.
Ein zweites Mittel ist vorgesehen, um einem Benutzer zu ermöglichen,
wenigstens eines aus der Anzahl von Eingangsdatenfeldern auszuwählen und
das aus der Anzahl von Eingangsdatenfeldern ausgewählte Datenfeld
zu verwenden, um die Anzahl von Zieldatenwerten bzw. den Zieldatenwert
abzurufen.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
Zur
Veranschaulichung der Erfindung zeigen die Zeichnungen eine Ausführungsform
der Erfindung, die im Vorliegenden bevorzugt ist. Es sollte allerdings
klar sein, dass die vorliegende Erfindung nicht auf die genauen
Anordnungen und Funktionalitäten
beschränkt
ist, wie sie in den Figuren gezeigt sind:
-
1A veranschaulicht
in einem schematisierten Diagramm hoher Ordnung ein System, das
ein Datenvergleichs- und -aktualisierungssystem der vorliegenden
Erfindung enthält;
-
1B zeigt
in einem schematisierten Diagramm hoher Ordnung eine Betriebsumgebung,
in der die Systeme von 1A verwendet werden können;
-
2 zeigt
in einem schematisierten Diagramm hoher Ordnung das Datenvergleichs-
und -aktualisierungssystem von 1A;
-
3 zeigt
eine Bildschirmaufnahme eines Akzeptierte-Meldung-Format-Setup-Startbildschirms
des Datenvergleichs- und
-aktualisierungssystems von 1A und 2;
-
4A zeigt
eine Bildschirmaufnahme eines Meldungs-Setup-Startbildschirms des Datenvergleichs- und
-aktualisierungssystems von 1A und 2;
-
4B zeigt
eine Bildschirmaufnahme eines Datenabgleich-Setupschirms des Datenvergleichs-
und -aktualisierungssystems von 1A und 2;
-
4C zeigt
eine Bildschirmaufnahme eines Daten-Querbezugs-Schirms des Datenvergleichs-
und -aktualisierungssystems von 1A und 2;
-
4D zeigt
eine Bildschirmaufnahme eines Querbezugs-Definitionsfensters des Datenvergleichs- und
-aktualisierungssystems von 1A und 2;
-
5 zeigt
eine Bildschirmaufnahme eines VERGLEICHEN/AKTUALISIEREN-Schirms
des Datenvergleichs- und -aktualisierungssystems von 1A und 2;
und
-
6A–B veranschaulichen
in einem Flussdiagramm ein Datenvergleichs- und -aktualisierungsverfahren
der vorliegenden Erfindung, das von dem Datenvergleichs- und -aktualisierungssystem
von 1A und 2 ausgeführt werden kann.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
Mit
Bezugnahme auf die Zeichnungen veranschaulicht 1A ein
System 100, das ein Datenvergleichs- und -aktualisierungs-(DCU
= Data Compare and Update)-System 104 der vorliegenden
Erfindung enthält.
Im Allgemeinen ermöglicht
das DCU-System 104 einem
(nicht gezeigten) Benutzer, basierend auf den in dem DCU-System
eingehenden Eingangsdaten 116 eine automatisierte Aktualisierung
von in einem oder mehreren Zieldatenspeichern 112 enthaltenen
Zieldaten 108 visuell zu verifizieren und manuell einzuleiten.
(Zu beachten ist, dass die Begriffe "Aktualisieren", "Aktualisierung" und Ableitungen
davon, wie sie im Vorliegenden und in den beigefügten Patentansprüchen verwendet
werden, den Austausch von speziellen Datenwerte von Zieldaten 108 gegen
spezielle Datenwerte von Eingangsdaten 116, eine Belegung
von bisher nicht besetzten bestehenden Zieldatenfeldern, Datensätze, usw.
mit jeweils entsprechenden Eingangsdatenwerten sowie eine Erzeugung
neuer Zieldatenfelder und Belegung derselben mit jeweils entsprechenden
Eingangsdatenwerten beinhalten).
-
Das
DCU-System 104 kann in einem beliebigen geeigneten Computer 118,
z.B. einem Universalrechner, einem anwendungsspezifischen Computer,
einem Server, usw. verwendet werden. Allgemein ausgedrückt, können Eingangsdaten 116 nahezu
beliebige Daten sein, die nicht Zieldaten 108 sind. Typischerweise werden
Eingangsdaten 116 von dem DCU-System 104 von einer
anderen Quelle als dem Datenspeicher 112 entgegengenommen.
Beispiele solcher Quellen von Eingangsdaten 116 beinhalten,
ohne darauf beschränkt zu
sein, Fremddatenspeicher, z.B. den Fremddatenspeicher 120 und/oder
Softwareanwendungen, z.B. die Softwareanwendung 124, die
die Eingangsdaten im Wesentlichen anhand von Daten, die in einem
oder mehreren Datenspeichern gespeichert sind, und/oder anhand von
flüchtigen
Daten assembliert, die nicht in einem herkömmlichen Sinn in einem Datenspeicher
gespeichert sind. In dieser Hinsicht ist dem Fachmann ohne weiteres
klar, dass die Eingangsdaten 116 in der Praxis gemeinsam
mit den Zieldaten 108 in dem Datenspeicher 112 gespeichert
sein können.
Es ist ferner zu beachten, dass jeder Zieldatenspeicher 112 nicht
notwendig, wie in 1A dargestellt, in einem einzigen
Speichergerät 126 angeordnet
sein muss, sondern vielmehr auf zwei oder mehr Speichergeräte verteilt
sein kann, wobei unter anderem vielfältige Arten von Langzeitspeichereinrichtungen,
z.B. Magnetplatten, optische Platten, Magnetband, nicht flüchtige Speicher,
usw. und Kurzzeitspeichergeräte,
z.B. flüchtige
RAM-Speicher Beispiele hierfür
sind.
-
1B veranschaulicht
ein Beispiel einer Umgebung 130, in der das System 100 der
vorliegenden Erfindung verwendet werden kann. Obwohl nicht erforderlich,
wird die Erfindung im Allgemeinen mit Blick auf von einem Computer
ausführbare
Befehle, z.B. Programmmodule beschrieben, die durch einen herkömmlichen,
universellen, digitalen Rechner ausgeführt werden. Typischerweise
beinhalten Programmmodule Programmroutinen, Programme, Objekte,
Komponenten, Datenstrukturen, usw., die spezielle Aufgaben ausführen. Die
Erfindung kann in Verbindung mit vielfältigen Rechnersystemkonfigurationen
verwendet werden, beispielsweise vernetzten Client-Server Rechnersystemen,
Handgeräte,
programmierbaren Verbraucherelektronikeinrichtungen, Minicomputern,
Großrechnern,
und dergleichen. Die Erfindung wird gewöhnlich, jedoch nicht notwendig,
in verteilten Computerumgebungen eingesetzt, wo Aufgaben durch entfernt
angeordnete Prozessoreinheiten durchgeführt werden, die durch ein Kommunikationsnetzwerk,
beispielsweise ein LAN-, WAN- oder ein auf dem Internet basierendes
Netzwerk, verknüpft
sind. In einer verteilten Computerumgebung können Programmmodule sowohl
in lokalen als auch dezentralen Arbeitsspeichervorrichtungen angeordnet
sein.
-
Darüber hinaus
wird in Erwägung
gezogen, dass das System 100 in der Lage ist, jedoch nicht
unabdingbar, in einer vernetzten Computerumgebung 130 zu
arbeiten, in der der Computer 118 mittelbar oder unmittelbar über ein
Netzwerk 134 (z.B. über
LAN, WAN, das Internet oder eine Kombination davon), mit einem oder
mehreren Netzwerkservern 138 verbunden ist. In manchen
Fällen
kann ein Rechner/Computer 118 mehrere Computer 118 umfassen,
die über
ein (nicht gezeigtes) LAN-, WAN-Netzwerk, das Internet oder Kombination
davon geeignet verbunden sind. Der Rechner 118 kann eine
oder mehrere Rechnerzentraleinheiten 142, einen Rechnerarbeitsspeicher 146 und
Eingabe- /Ausgabegeräte 150 umfassen.
Die Umgebung 130 und Komponenten davon enthalten Computerprogramme 154,
die bei der Ausführung
durch Rechner-Ressourcen in der Rechnerumgebung die Funktionalität der vorliegenden
Erfindung bereitstellen.
-
Wie
weiter unten im Einzelnen erörtert,
kann das DCU-System 104 dazu
eingerichtet sein, die Eingangsdaten 116 zu handhaben,
die in einem beliebigen aus einer Anzahl von Datenformaten und in
Form einer oder mehreren Meldungstypen vorliegen. Obwohl die breiten
Konzepte von Datenformat- und Meldungstypen im folgenden anhand
eines Beispiels im Zusammenhang mit der Gesundheitsfürsorgeindustrie
veranschaulicht sind, wird der Fachmann sofort erkennen, dass die
vorliegende Erfindung in nahezu jeder Industrie oder auf jedem Gebiet
durchgeführt
werden kann, wo es von Vorteil oder gewünscht ist, basierend auf den
Eingangsdaten 116 eine computergestützt durchgeführte manuelle
Datenverifikation und eine manuelle Initialisierung einer Aktualisierung
von Zieldaten 108 zu ermöglichen. Beispiele von Anwendungen
eines DCU-Systems der vorliegenden Erfindung beinhalten Bankwesen,
Kreditbericht, Lagerbestandskontrolle in nahezu jedem Betrieb, in
dem Posten hinzugefügt
und abgezogen werden, menschliche Ressourcen, z.B. für die Verwendung
zwischen Systemen wie Zeitberichts-, Gehalts- und Beschäftigtendatenbanken
und/oder für
den Einsatz in der Verwaltung von Sozialleistungen, z.B. Gesundheitsfürsorge,
Lebens- und Invaliditätsversicherung,
usw. Die vorstehende Liste ist selbstverständlich exemplarisch und nicht
beschränkend.
Dem Fachmann wird klar sein, dass die Zahl der Anwendungen der vorliegenden
Erfindung zu groß ist,
um eine erschöpfende
Liste zu unterbreiten. Selbstverständlich ist die Art von Daten,
z.B. wissenschaftliche, demographische, geographische, Finanz-,
Geschäftstransaktionsdaten, usw.,
die für
eine Handhabung durch die vorliegende Erfindung in Frage kommen,
ebenfalls breit gestreut.
-
Zu
Beispielen von in der Gesundheitsfürsorgeindustrie verwendeten
Datenformaten gehören
unter anderem, das X12-Einheitsstandardformat,
das durch das Accredited Standards Committee (ASC) of the American
National Standards Institute (ANSI) for business-to-business transactions
(www.x12.org), verkündigt
wurde, das HL7-Einheitsstandardformat, das durch die Health Level
Seven Standards Developing Organization (SDO) of ANSI for healthcare
domain transactions (www.h17.org) verkündigt wurde, und vielfältige anwendereigene/maßgeschneiderte
Formate, die durch Softwarefirmen und sonstige Instanzen ersonnen
wurden. Kurz gesagt, der ASC-X12-Standard stellt mehr als 315 standardisierte
elektronische Datenaustausch-(EDI
= Electronic Data Interchange)-Transaktionen zur Verfügung, die
einen sicheren B2B-E-Commerce-Nachrichtenaustausch auf vielfältigen Gebieten
ermöglichen,
zu denen beispielsweise Versicherung, Finanzwesen, Regierung, Versorgungsketten,
Transport, technische Begutachtung, Datenkommunikationen/Bedienelemente
und Bildungswesen gehören.
Im Allgemeinen stellt jede Transaktion eine vorformatierte Struktur
bereit, die es Firmen oder sonstigen Instanzen ermöglicht,
untereinander Daten, insbesondere Transaktionsdaten auszutauschen.
Jede Standardtransaktion kann auf einem beliebigen der vielfältigen Gebiete,
z.B. Gesundheitsfürsorge,
Bankwesen, Lebensversicherung, usw., gemäß einer "Durchführungsanleitung" (IG = Implementation
Guide) durchgeführt
werden, die für
das betreffende Gebiet spezifisch ist. Beispielsweise stellt der
ASC-X12-Standard
im Zusammenhang mit der Gesundheitsfürsorge als Standard-Transaktionsnummer
278 einen Krankenversicherungstransaktionssatz für "Gesundheitsfürsorgedienst-Überprüfungsdaten" zur Verfügung. Eine
der 278-IGs definiert diese Trans aktion für die Anforderung und den Empfang
einer Genehmigung von einem Gesundheitsfürsorge-Versicherer für Überweisungen
eines Patienten, um zu gewährleisten,
dass eine betreffende Leistung durch den Versicherer gedeckt ist,
bevor die Leistung ausgeführt
wird. Eine weitere IG für
die 278-Transaktion wird für
Abfragen hinsichtlich des Status einer Überweisung verwendet. Weitere
Beispiele sind mehrere IGs für
vielfältige
Ausführungen
der 837-Anspruchseinreichungstransaktion, zu der unter anderem IGs
für professionelle,
institutionelle, pharmazeutische und dentale Ansprüche gehören. Im
Allgemeinen werden die Nutzungen von EDI-Transaktionen und deren
Durchführungen
häufig
mit den Ordnungszahlen der ASC-X12-Transaktion bezeichnet. Dementsprechend
wird die Nutzung einer Durchführung
der Gesundheitsfürsorgedienst-Überprüfungsdaten-Transaktion üblicherweise
als eine "278-Transaktion" bezeichnet. Andere Beispiele
von ASC-X12-EDI-Transaktionen im Zusammenhang mit Gesundheitsfürsorge sind
in der folgenden Tabelle I aufgelistet. Zu beachten ist, dass diese
Tabelle nicht erschöpfend
ist, sondern lediglich der Veranschaulichung dient. Dies sind Beispiele,
die die Standard-Versionen sämtlicher
dieser Transaktionen sind.
-
Tafel I
-
Exemplarische, die Gesundheitsfürsorge betreffende
ASC-X12-Transaktionen
-
- 270
- Anfrage
hinsichtlich Gesundheitsfürsorge-Anrechnungsfähigkeit/Leistungen
- 271
- Daten
hinsichtlich Gesundheitsfürsorge-Anrechnungsfähigkeit/Leistungen
- 275
- Patientendaten
- 276
- Abfrage
hinsichtlich des Gesundheitsfürsorgeanspruchsstatus
- 277
- Meldung
hinsichtlich Gesundheitsfürsorgeanspruchsstatus
- 278
- Gesundheitsfürsorgedienst-Überprüfungsdaten
- 820
- Zahlungsauftragsüberweisungsanzeige
- 834
- Beihilfeneintragung
und -aufrechterhaltung
- 835
- Auszahlung/Mitteilung
eines Gesundheitsfürsorgeanspruchs
- 837
- Gesundheitsfürsorgeanspruch
-
Wie
oben erwähnt,
kann das DCU-System 104 dazu eingerichtet sein, eine oder
mehrere Meldungstypen zu handhaben. Im Zusammenhang mit den Eingangsdaten 116,
entspricht (entsprechen) der (die) Meldungstyp(en) dem (den) Zweck(en),
der (den) Verwendung(en) oder Funktion(en) der Eingangsdaten oder dem
(den) Grund (Gründen)
für die
Eingangsdaten. Beispielsweise können
die Zieldaten 108 im Zusammenhang mit Gesundheitsfürsorge eine
Anzahl Patientendatensätze
beinhalten, die jeweils auf vielfältige Felder verteilt sind,
beispielsweise ein Krankenblattnummer-Feld, Patientenname-Feld,
Geburtsdatum-Feld, Geschlecht-Feld und eine Anzahl von Feldern,
die Überweisungen
betreffen, die der entsprechende Patient erhalten hat. Die Überweisung-Felder
können
unter anderem ein Sta tus-Feld für
jede Überweisung
zur Aufnahme eines den Status jener Überweisung angebenden Datenwerts
beinhalten, z.B. anhängig,
genehmigt, verweigert, usw.
-
In
einem Beispiel können
die Eingangsdaten 116 eine von einem Versicherer ausgehende ASC-X12-278-Transaktion
sein, die eine Zertifizierung einer speziellen Überweisung für einen
bestimmten Patienten beinhaltet. In diesem Fall basiert der Zweck
oder Grund der Eingangsdaten 116 darauf, einen Dienstleister
auf dem Gebiet der Gesundheitsfürsorge
zu benachrichtigen, dass der Versicherer die Überweisung genehmigt hat. Darüber hinaus
liegt ein Nutzen der Eingangsdaten 116 darin, den Status
der Überweisung
für den
betreffenden Patienten, in diesem Falle als "genehmigt" zu aktualisieren. Folglich kann ein
geeigneter Meldungstyp für
diese Transaktion mit "Überweisung" oder mit einem ähnlichen
erklärenden
Ausdruck bezeichnet werden. Beispiele sonstiger Meldungstypen für Durchführungen
anderer der in Tabelle I aufgelisteten ASC-X12-Transaktionen können von
der Art sein, wie sie in der nachstehenden Tabelle II erläutert sind.
An dieser Stelle sei vermerkt, dass die 278-Transaktion zusätzlich zu
dem Status "genehmigt" andere auf den betreffenden
Patienten bezogene Daten enthält,
z.B. Name, Geburtsdatum, Versicherungsvertragsnummer, Zertifizierungsnummer,
usw., die den Patienten und die Transaktion eindeutig identifizieren.
Wie nachstehend erläutert,
kann das DCU-System 104 durch den Anwender konfigurierbar
sein, um Abweichungsdaten in den Eingangsdaten 116 in Bezug
auf die Zieldaten 108 hervorzuheben, und einem Benutzer
zu ermöglichen,
manuell auszuwählen,
ob die Zieldaten mit irgendwelchen der Abweichungsdaten aktualisiert
werden sollten oder nicht. Tafel II zeigt Beispiele der Daten, die
gewöhnlich
geändert
oder einem Empfangssystem eines Empfängers hinzugefügt werden,
wenn der Empfänger
ein Dienstleister ist, und der Sender ein Gesundheitsvorhaben ist. Tafel
III zeigt Beispiele der Daten, die gewöhnlich geändert oder dem Empfangssystem
des Zahlers hinzugefügt
werden, wenn der Empfänger
ein Zahler ist, und der Sender ein Arbeitgeber oder ein Dienstleister
ist.
-
Exemplarische
Meldungsarten für
ASC-X12-Transaktionen in Tabelle I Dienstleister empfängt gerade
die Daten von einem Zahler Tafel
II
-
Zahler
empfängt
gerade die Daten von eine Arbeitgeber oder Dienstleister Exemplarische
Meldungstypen für
ASC-X12-Transaktionen in Tabelle I Tafel
III
-
HL7-Meldungen
betreffen ihrer Natur nach das Klinikwesen, so dass gewöhnlich sowohl
der Sender als auch der Empfänger
Gesundheitsfürsorgesysteme
sind. Meldungsbeispiele sind gewöhnlich
die Übermittlung
von Laborergebnissen von einem Laborrechnersystem zu einem Klinikberichts-Rechnersystem
innerhalb derselben Klinik. Oder die Meldung könnte von dem Laborrechnersystem
an ein Arztpraxenrechnersystem übermittelt
sein, das nicht Teil des Klinik-Informationssystems ist. Der HL7-Einheitsstandard
für Meldungen
auf dem Gebiet der Gesundheitsfürsorge
weist eine Struktur auf, die gegenüber der Struktur des ASC-X12-Standards
im Wesentlichen parallel ist. D.h., der HL7-Einheitsstandard weist
ein spezielles Format auf, das vielfältigen Meldungstypen gemein
ist, weitgehend in derselben Weise, wie der ASC-X12-Standard ein
spezielles Format aufweist, das vielfältigen Transaktionen gemein
ist. Beispielsweise kann der HL7-Einheitsstandard genutzt werden,
um vielfältige
Schablonen oder Daten-"Modelle" zu erzeugen. Im Allgemeinen
ist eine Schablone eine strukturierte Sammlung von Daten/Informationen,
die für
einen oder mehrere Gesundheitsfürsorgeinteressenten
von Interesse sind. Jede Schablone kann als einem entsprechenden
Meldungstyp entsprechend angesehen werden, in der Weise, dass Durchführungen
von ASC-X12-Transaktionen
jeweils einem entsprechenden Meldungstyp entsprechen. Andererseits ähnelt ein
Datenmodell "Durchführungen" in den ASC-X12-Konstrukten.
D.h., HL7-Datenmodelle werden verwendet, um den Einheitsstandard
für spezielle
Anwendungen zu definieren. Beispiele von HL7-Schablonen und -Datenmodellen
oder einfachen "Meldungen" und entsprechenden
Meldungstypen sind in der folgenden Tabelle III aufgelistet. Dem
Fachmann wird klar sein, dass die Liste von HL7-Meldungen in Tabelle
III lediglich der Veranschaulichung dient und nicht erschöpfend ist. Exemplarische
HL7-Meldungen und Meldungstypen Tafel
IV
Meldung | Meldungstyp |
Laborergebnis | Blutlabor |
DiabTemp | Diabetesschablone |
DeprTemp | Depressionsschablone |
Biopsie | Gewebebiopsie |
-
Es
ist selbstverständlich,
dass die vorausgehenden Beispiele für Format und Meldungstypen
der Eingangsdaten 116 bezüglich der ASC-X12- und HL7-Standards
spezialisiert sind und sich im Laufe der Zeit wahrscheinlich ändern werden.
Allerdings ist dem Fachmann ohne weiteres klar, dass die im Zusammenhang
mit speziellen Beispielen oben beschriebenen weiten Konzepte von
Datenformat und Meldungstyp auf viele sonstige Datenmeldungs/Datenaustausch-Standards über einen
großen
Bereich von Gebieten anwendbar sind, und dass diese Konzepte sich
sehr wahrscheinlich in beliebigen zukünftigen Versionen der ASC-X12-
und HL7-Standards und sonstigen Datenmeldungs/Datenaustausch-Standards
anwenden werden lassen. Zusätzlich
zu der Tatsache, dass das DCU-System 104 konfigurierbar
ist, um die nach nahezu beliebigen Datenstandards übermittelten
Eingangsdaten 116 zu handhaben, kann es außerdem dazu
eingerichtet werden, Eingangsdaten zu handhaben, die eine nahezu
beliebige anwenderspezifische Struktur aufweisen.
-
2 veranschaulicht
das DCU-System 104 von 1A detaillierter. 2 zeigt,
dass das DCU-System 104 eine Anzahl von "Modulen" 200, 204, 208 aufweisen
kann, die jeweils eine oder mehrere gewünschte Funktionen bereitstellen,
um die Gesamtfunktionalität
des Systems zu erreichen. In diesem Zusammenhang ist zu beachten,
dass der Begriff "Modul" in dem hier und
in den beigefügten
Patentansprüchen
verwendeten Sinne eine logische Gruppierung einer oder mehrerer
verwandter Funktionen und nicht notwendig eine diskrete physikalische
Konstruktion bedeutet, die eine solche Funktionalität bereitstellt.
In der Tat wird (werden) in den wahrscheinlichsten Konkretisierungen
eines DCU-Systems der vorliegenden Erfindung die Funktion(en) der
vielfältigen "Module" nicht in Form diskreter
physikalischer Konstruktionen, sondern vielmehr als von durch einen
Computer ausführbare
Befehle, z.B. Software, verwirklicht sein, die durch eine oder mehrere
Prozessoren zur geeigneten Zeit in einem geeigneten Rechnersystem
ausgeführt
werden, um die Funktionen durchzuführen. In dieser Hinsicht kommt
in Betracht, dass die Module der vorliegenden Erfindung in Form
diskreter physikalischer Konstruktionen, z.B. elektronischer Module,
verwirklicht sein können,
die in der Lage sind, die jeweils entsprechende(n) Funktion(en)
durchzuführen.
Solche von einem Computer ausführbare
Befehle können
auf einem beliebigen geeigneten von einem Rechner auslesbaren Medium
oder auf einer Kombination von Medien enthalten sein, zu denen,
jedoch ohne darauf beschränken
zu wollen, flüchtige
und nicht flüchtige
Speicher, digitale oder analoge Signale oder Speichergeräte, wie
magnetische und optische Einrichtungen und Lochkarten gehören, um
nur einige zu nennen.
-
Unter
Bezugnahme auf 2 kann das DCU-System 104 ein
Meldungsidentifikations-(ID)-Modul 200, ein Datenabgleichmodul 204 und
ein Vergleichs/Aktualisierungs-(C/U)-Modul 208 aufweisen.
Auf einem hohen Niveau kann das Meldungs-ID-Modul 200 konstruiert
sein, um eine Funktionalität
bereitzustellen, die es einem Benutzer ermöglicht, das DCU-System 104 zu
konfigurieren, so dass dieses eine oder mehrere Transaktion oder
Meldungsformate basierend auf geeigneten Erkennungskriterien, z.B.
Dateinamenerweiterungen und/oder Identifizierungskennzeichnungen,
die die Eingangsdaten 116 begleiten, erkennt und unterscheidet. In
diesem Zusammenhang ist zu beachten, dass die Eingangsdaten 116 auf
beliebigem Wege in das DCU-System 104 gelangen können, insbesondere
in Form einer oder mehrerer diskreter Dateien oder als eine oder
mehrere Datenstromdateien. Das Meldungs-ID-Modul 200 kann
außerdem
dazu eingerichtet sein, einem Benutzer zu ermöglichen, das Datenaustauschverfahren
zu konfigurieren, durch das die Eingangsdaten 116, d.h.
eine spezielle Meldung, von dem DCU-System 104 entgegen genommen
wird. Beispielsweise kann das Datenaustauschverfahren unmittelbar über einen
bestimmten Datenkommunikationskanal, über eine Internetverbindung,
durch Internet-Protokoll nach OSI (FTP), usw. stattfinden. Das Datenaustauschverfahren
jeder Meldung, für
die ein Benutzer möglicherweise
eine Handhabung durch das DCU-System 104 wünscht, wird gewöhnlich bekannt
sein.
-
Das
Meldungs-ID-Modul 200 kann einen ID-Setup-Manager 220 enthalten,
der eine Benutzerschnittstelle, z.B. eine ID-Setup-Benutzerschnittstelle (GUI) 300 von 3 bereitstellt,
die es einem Benutzer u. a. ermöglicht:
1) eine oder mehrere Meldungsformate auswählen, die das DCU-System 104 erkennen
soll; 2) das Meldungs-ID-Modul so zu konfigurieren, dass es ein
oder mehrere Meldungsformate erkennt, die noch nicht durch das Meldungs-ID-Modul
identifizierbar sind; 3) die Erkennungs-(Identifizierungs)-Kriterien
eines oder mehrerer der in dem ID-Setup-Manager bereits repräsentierten
Meldungsformate zu modifizieren; 4) ein oder mehrere der bereits
in dem Datenformat-ID-Modul repräsentierten
Meldungsformate zu löschen;
und 5) das Datenaustauschverfahren für jedes Meldungsformat zu konfigurieren.
Im Allgemeinen wird der ID-Setup-Manager 220 verwendet,
um eine Bibliothek 224 (2) von Meldungstypen
und entsprechenden Datenaustauschverfahren zu erstellen, für die ein
oder mehrere Benutzer eine Identifizierung und Handhabung durch dass
DCU-System 104 wünschen.
-
3 veranschaulicht
insbesondere eine Akzeptierte-Meldung-Formate-Einrichtungsstartschirm 304 der
ID-Setup-GUI 300, d.h. den ersten Schirm, der durch den
ID-Setup-Manager 220 bei jeder anfänglichen Aktivierung der GUI
angezeigt wird. In einer auf das World Wide Web gestützten Durchführung des
DCU-Systems 104 (1A und 2)
kann der Startschirm 304, um mit der geeigneten Terminologie
konsistent zu sein, als die "Homepage" der Format-ID-GUI 300 bezeichnet
werden. Während
die ID-Setup-GUI 300 und sonstige unten beschriebenen GUIs
weitgehend als Vollbild-GUIs veranschaulicht sind, ist dem Fachmann ohne
weiteres klar, dass eine oder mehrere dieser GUIs in anderer Weise,
z.B. als Popup-Fenster, Dialogfenster, usw., durchgeführt sein
können,
um zu einem speziellen Entwurf zu passen. Während die ID-Setup-GUI 300 und
sonstige unten beschriebene GUIs in der dargestellten und beschriebenen
Form besondere Layouts und spezielle Merkmalarten, z.B. Kontrollkästchen,
Tasten/Knöpfe,
Hyperlinks, usw., aufweisen, sollte dem Fachmann darüber hinaus
klar sein, dass diese Layouts und Merkmalarten der Veranschaulichung
dienen und nicht beschränken
sollen. Wo es angebracht ist, sind eine oder mehrere Alternativen
hinsichtlich der gezeigten Layouts und Merkmalarten erwähnt. Dennoch
sollte dem Fachmann klar sein, dass eine wesentlich größere Anzahl
von nicht erwähnten
Abwandlungen für
das Meldungsformat und die Merkmalarten existieren, die hinlänglich aus
dem Stand der Technik von GUI-Entwürfen bekannt
sind und auf einfache Weise in der ID-Setup-GUI 300 und sonstigen
gezeigten und hier beschriebenen GUIs substituiert werden könnten.
-
Der
Akzeptierte-Meldung-Format-Setup-Startbildschirm 304 kann
eine Meldungsformatliste 308 anzeigen, die die Meldungsformate
enthält,
für die
das DCU-System 104 (1A und 2)
aktuell hinsichtlich eines Erkennens eingerichtet ist. Wie oben
erwähnt,
können
Daten, die die Meldungsformatliste 308 betreffen, in der
Bibliothek 224 gespeichert werden, die auf demselben Speichergerät 126 wie
die Zieldaten 108 (1A) angeordnet
sein kann oder auch nicht. Im veranschaulichten Fall ist das Meldungs-ID-Modul 200 eingerichtet, um
ASC-X12- und HL7-Standardformate
sowie ein anwendereigenes Format zu erkennen, das mit "PHARMdBv2" bezeichnet ist,
das ein fiktives anwendereigenes Format ist, um Verschreibungsdaten
aus einer anwendereigenen Lagerbestandcomputeranwendung auszutauschen,
um Pharmadaten für
eine klinikinterne Apotheke zu verfolgen und zu verwalten. Zum Zweck
der Veranschaulichung verwendet das PHARMdBv2-Meldungsformat ein
herkömmliches ".dbf"-Dateiformat und enthält einen Kennsatz der "PHARMdBv2" beinhaltet, um die
Daten als von dem "PHARMdBv2"-Typ zu identifizieren.
Die ID-Setup-Startseite 304 kann ferner einen oder mehrere
Selektoren, z.B. Kontrollkästchen 312,
aufweisen, die es einem Benutzer ermöglichen, eines oder mehrere
Datenformate anzugeben, die für
eine spezielle Anwendung des DCU-Systems 104 aktiviert
werden sollen. Im veranschaulichten Fall ist das DCU-System 104,
wie durch die anwesenden oder nicht anwesenden Kontrollhäkchen in
den Kontrollkästchen 312 angezeigt,
so konfiguriert, dass die Formate ASC-X12 und PHARMdBv2 erkannt
werden, nicht jedoch das HL7-Format.
-
Das
Meldungs-ID-Modul 200 (2) kann
Regeln 228 für
die Handhabung von bewusst nicht zur Erkennung freigegebenen Meldungsformaten
enthalten, d.h. Meldungsformaten, die zwar auf dem Meldungsformat-Setup-Startbildschirm 304 angezeigt
werden, jedoch nicht ausgewählt
sind, sowie nicht identifizierbare Formate, d.h. Formate, die nicht
auf der Startseite angezeigt sind. Beispielsweise kann eine Regel
für ein
bewusst nicht zur Erkennung freigegebene Format das Meldungs-ID-Modul 200 dazu
veranlassen, ein (nicht gezeigtes) Popup-Fenster auf dem Schirm zu öffnen, das
die Meldung "Das
System hat HL7-Daten empfangen, die bewusst von dem System abgewiesen
wurden. Sie können:
(1) diese Daten einsehen, indem Sie unten die 'Ansicht'-Taste wählen; (2) dem System erlauben,
diese Daten zu identifizieren, indem Sie den Identifizierungsstatus
durch Auswahl der unten angeordneten 'Status- Ändern'-Taste ändern; oder
(3) diese Daten ignorieren, indem Sie unten die 'Ignorieren'-Taste wählen" oder eine ähnliche Meldung anzeigt. In
Entsprechung kann das DCU-System 104 die absichtlich nicht
zu identifizierenden Eingangsdaten puffern. Als weiteres Beispiel
kann eine Regel für
ein nicht identifizierbares Format das Meldungs-ID-Modul 200 veranlassen,
ein (nicht gezeigtes) alternatives Popup-Fenster auf dem Schirm
zu öffnen,
das die Meldung "Das
System hat nicht identifizierbare Daten empfangen. Sie können diese
Daten einsehen, indem Sie unten die 'Ansicht'-Taste wählen, oder diese Daten ignorieren,
indem Sie unten die 'Ignorieren'-Taste wählen" oder eine ähnliche
Meldung anzeigt. Ein Benutzer kann sich je nach Sachlage entscheiden,
den Status eines speziellen Formats zu ändern oder ein neues Format
hinzuzufügen.
-
Die
Meldungsformatliste 308 kann für jedes aufgelistete Meldungsformat
die ID-Kriterien 316A–C
beinhalten, die das Meldungs-ID-Modul 200 verwendet, um
das Format einer eingehenden Meldung 116 (1A und 2)
gegenüber
den identifizierbaren Formaten in der Meldungsformatliste zu identifizieren.
In dem veranschaulichten Beispiel sind die ID-Kriterien 316A–B für die ASC-X12-
und HL7-Formate einfach die Dateitypenerweiterungen ".x12" und ".h17.11".
-
Allerdings
weisen die ID-Kriterien 316C für das PHARMdBv2-Format die
Dateitypenerweiterung ".dbf" und das Element "PHARMdBv2" auf, das in dem
Dateikennsatz einer derartigen Datei erscheint. Die ID-Kriterien 316A–C können in
der Bibliothek 224 (2) gespeichert
sein. Für
jedes aufgelistete Meldungsformat kann außerdem in einer "Meldungstyp"-Spalte 320 angezeigt sein,
welche Meldungstypen in einem Meldungsformat gültig sind. Beispielsweise kann
das ASC-X12-Format
gültige
Meldungstypen wie 270, 271 und 834 aufweisen.
-
3 veranschaulicht
die ASC-X12-Meldungstypen 834 und 271, wie sie in dem DCU-System 104 (1A und 2)
verwendet sind. Jeder aufgelistete Meldungstyp kann ferner einen
entsprechenden Datenaustauschverfahrensindikator 318 beinhalten,
beispielsweise wie gezeigt 318A–C, der für den Benutzer und das DCU-System 104 (1A und 2)
das Datenaustauschverfahren identifiziert, durch das das System
den betreffenden Meldungstyp empfangen wird. Die Datenaustauschverfahren
können
unterschiedliche Verbindungskanalnummern für TCIP-Verbindungen, Internetadressen,
wie URLs, für
Internetverbindungen, oder Wählnummern
für Modemverbindungen
verwenden. Verfahrensindikatoren 318A–C und geeignete Maschinenspracheanweisungen
zur Handhabung der angezeigten Datenaustauschverfahren können in
der Bibliothek 224 gespeichert sein. Eine Statusspalte 324 kann
vorgesehen sein, um den Aktivitätspegel
oder die aktuelle Nutzungsstufe jedes Meldungstyps anzuzeigen. In
dem vorliegenden Beispiel kann der Status eines Meldungstyps "Aktiv", "Inaktiv" oder "Test" sein, wobei "Aktiv" bedeutet, dass die
Meldung gegenwärtig
in Betrieb ist, "Inaktiv" bedeutet, dass der
Meldungstyp gerade nicht verwendet wird, und "Test" bedeutet,
dass der Meldungstyp gerade eingerichtet wird oder für Test-Transaktionen
und nicht im Live-Aktivmodus verwendet wird.
-
Der
Meldungsformat-Setup-Startbildschirm 304 kann ein Löschen-Merkmal
zum selektiven Löschen jedes
Meldungsformats aus der Meldungsformatliste 308 enthalten.
Das Löschen-Merkmal kann eine "Löschen"-Taste 328 (oder -Hyperlink,
usw.) beinhalten, die auf die Auswahl durch einen Benutzer hin ein
(nicht gezeigtes) Popup-Fenster anzeigen kann, das den Benutzer
auffordert, die Löschung
zu bestätigen.
Der Meldungsformat-Setup-Startbildschirm 304 kann ferner
ein Ändern-Merkmal
für selektives
Modifizieren der Meldungsformatbezeichner 332, der entsprechenden
ID-Kriterien 316A–C
und/oder des entsprechenden Verfahrensindikators 318A–C aufweisen.
Das Ändern-Merkmal kann eine "Ändern"-Taste 336 (oder -Hyperlink,
usw.) beinhalten, die auf eine Auswahl durch einen Benutzer hin
ein (nicht gezeigtes) Popup-Fenster (oder einen weiteren Schirm/Seite,
usw.) anzeigen kann, das es dem Benutzer ermöglicht, die Daten in einer
geeigneten Weise zu ändern.
Der Meldungsformat-Setup-Startbildschirm 304 kann ferner
ein Hinzufügen-Merkmal enthalten,
um der Formatliste 308 ein Meldungsformat hinzuzufügen. Ein
solches Hinzufügen-Merkmal
kann eine "Meldungsformat-Hinzufügen"-Taste 340 (oder
-Hyperlink, usw.) beinhalten, die auf eine Auswahl durch einen Benutzer
hin ein (nicht gezeigtes) Popup-Fenster (oder einen weiteren Schirm/Seite,
usw.) anzeigen kann, das es dem Benutzer ermöglicht, einen neuen Meldungsformatbezeichner 332,
geeignete ID-Kriterien 316 und geeignete Datenaustauschverfahrensbezeichner 318 hinzuzufügen. Nachdem
ein Benutzer den ID-Setup-Manager 220 (2)
abgearbeitet hat, kann der Benutzer einen geeigneten Selektor auswählen, z.B.
eine "Schließen"-Taste 344,
die die ID-Setup-GUI 300 schließt.
-
Das
Datenabgleichmodul 204 (2) kann
einen Datenabgleichmanager 232 enthalten, der eine Benutzerschnittstelle,
z.B. die Meldungs-Setup-GUI 400 von 4A–D bereitstellt,
die es einem Benutzer u. a. ermöglicht:
1) einen oder mehrere Meldungstypen auszuwählen, die für das DCU-System 104 ( 1A und 2)
identifizierbar sein sollen; 2) das Meldungsabgleichmodul so zu
konfigurieren, dass es einen oder mehrere durch das Modul noch nicht
identifizierbare Meldungstypen erkennt; 3) die Erkennungskriterien
eines oder mehrerer Meldungstypen zu modifizieren, die bereits in
dem Meldungsabgleich-Manager repräsentiert sind; 4) einen oder
mehrere Meldungstypen zu löschen,
die in dem Meldungsabgleichmodul be reits repräsentiert sind; 5) ein oder
mehrere Datenfelder der Eingangsdaten 116 (1A und 2)
auszuwählen,
um die Eingangsdaten mit den geeigneten Zieldaten 108 abzugleichen;
und 6) die Datenfelder der anzuzeigenden Eingangsdaten auszuwählen, um
die Vergleichs- und Aktualisierungs-Funktionalität zu schaffen, wie sie oben
und im folgenden beschrieben ist. In dem vorliegenden Ausführungsbeispiel
werden die unmittelbar vorstehenden Funktionen 1–4 durch eine "Meldungs-Setup"-Startseite 404 (4A)
bereitgestellt, die Funktion 5 wird durch einen "Datenabgleich-Setup"-Schirm 406 (4B)
zur Verfügung
gestellt, und die Funktion 6 wird durch einen "Daten-Querbezugs"-Schirm 408 (4C)
bereitgestellt. Jeder dieser Schirme 404, 406, 408 ist
im folgenden beschrieben. Selbstverständlich wird dem Fachmann einleuchten,
dass die Meldungs-Setup-GUI in mannigfaltiger Form abweichend von
den Schirmen 404, 406, 408 verwirklicht
werden kann. Der Meldungs-Setup-Startbildschirm 404, der
Datenabgleich-Setupschirm 406 und der Daten-Querbezugs-Schirm 408 sind
im folgenden näher
beschrieben.
-
Der
in 4A veranschaulichte Meldungs-Setup-Startbildschirm 404 kann
eine Meldungstypenliste 410 anzeigen, die den (die) Meldungstyp(en)
für jedes
Meldungsformat beinhaltet, das auf der Meldungsformatliste 308 (3)
der ID-Setup-GUI 300 aufscheint.
Daten, die die Meldungstypenliste 410 betreffen, können in
einem geeigneten Datenspeicher, z.B. Datentypenspeicher 236 (2)
gespeichert sein, der auf demselben Speichergerät 126 wie die Zieldaten 108 (1A)
angeordnet sein kann oder auch nicht. In dem vorliegenden Beispiel
wird das Meldungstyp-Setup-Modul 204 eingestellt, um die
Datentypen "Anrechnungsverifikation" und "Anspruchsstatus" für das ACS-X12-Format,
die Datentypen "Laborergebnis" und "Diabetesschablone" für das HL7-Format,
und den Datentyp "Klinikapotheke" für das PHARMdBv2-Format
zu erkennen. In diesem Beispiel ist zu beachten, dass die Datentypen
Laborergebnis und Diabetesschablone unter dem HL7-Format "grau dargestellt" sind, um anzuzeigen,
dass sie nicht aktiv sind, wie durch das Fehlen eines Kontrollhäkchens in
dem entsprechenden Kontrollkästchen 312 in
dem Meldungsformat-Setup-Startbildschirm 304 von 3 angezeigt.
Der Meldungs-Setup-Startbildschirm 404 kann ferner eine
oder mehrere Selektoren, z.B. Kontrollkästchen 412, aufweisen,
die es einem Benutzer ermöglichen,
anzugeben, welche Datentypen für
eine spezielle Anwendung des DCU-Systems 104 aktiviert
werden sollen. In dem vorliegenden Beispiel ist das DCU-System 104,
wie durch die Anwesenheit oder Nichtanwesenheit von Kontrollhäkchen in
den Kontrollkästchen 412 angezeigt,
konfiguriert, um den Datentyp Anrechnungsverifikation des ASC-X12-Formats,
die Datentypen Laborergebnis und Diabetesschablone des HL7-Formats
(wobei jedoch zu bedenken ist, dass das HL7-Format inaktiv ist)
und den Datentyp Klinikapotheke des PHARMdBv2-Formats zu erkennen.
-
Das
Meldungs-Setup-Modul 204 (2) kann
Regeln 240 (2) für eine Handhabung absichtlich nicht
zu identifizierender Datentypen beinhalten, d.h. Typen, die in dem
Meldungs-Setup-Modul enthalten sind, jedoch nicht ausgewählte und
nicht identifizierbare Typen sind, d.h. Typen, die nicht in dem
Modul enthalten sind. Beispielsweise kann eine Regel für einen
absichtlich nicht zu identifizierenden Datentyp das Datenabgleichmodul 204 dazu
veranlassen, ein (nicht gezeigtes) Popup-Fenster zu öffnen, das
die Meldung "Das
System hat HL7-Laborergebnisdaten empfangen, die von dem System
absichtlich abgewiesen wurden. Sie können: (1) diese Daten einsehen,
indem Sie unten die 'Ansicht'-Taste wählen; (2)
diese Daten zulassen, indem Sie unten die 'Daten-Zulassen'-Taste wählen; oder (3) diese Daten
ignorieren, indem Sie unten die 'Ignorieren'-Taste wählen" oder eine ähnliche
Meldung anzeigt. In Entsprechung kann das DCU-System 104 die
Eingangsdaten, die absichtlich nicht identifiziert werden sollen,
puffern. Als weiteres Beispiel kann eine Regel für eine nicht identifizierbares
Format das Datenabgleichmodul 204 dazu veranlassen, ein
(nicht gezeigtes) alternatives Popup-Fenster auf dem Schirm zu öffnen, das
die Meldung "Das
System hat nicht identifizierbare Daten empfangen. Sie können diese
Daten einsehen, indem Sie unten die 'Ansicht'-Taste wählen, oder diese Daten ignorieren,
indem Sie unten die 'Ignorieren'-Taste wählen" oder eine Meldung ähnlichen
Inhalts anzeigt. Ein Benutzer kann je nach Sachlage entscheiden,
den Status eines speziellen Datentyps zu ändern oder einen neuen Datentyp
hinzuzufügen.
-
Die
Meldungstypenliste 410 kann für jedes aufgelistete Meldungsformat
die ID-Kriterien 416A–E
beinhalten, die das Datenabgleichmodul 204 verwendet, um
den Typ der eingehenden Meldung 116 (1A und 2)
mit den identifizierbaren Arten abzugleichen, die in der Meldungstypenliste
aufscheinen. In dem veranschaulichten Beispiel sind die ID-Kriterien 416A–B für die ASC-X12-Anrechnungsverifikation
und -Anspruchsstatus-Meldungstypen
die Transaktionsbezugszeichen der entsprechenden ASC-X12-Transaktionen
(siehe oben Tafel I), in diesem Falle "X12 271" bzw. "X12-277". Diese Feldnamen werden gewöhnlich in
den Körpern von
Dateien gefunden, die derartige Transaktionen beinhalten, d.h. Meldungstypen.
In ähnlicher
Weise können die
ID-Kriterien 416C–D
für das
HL7-Laborergebnis und -Diabetesschablone die Feldnamen "HL7-Laborergebnis" und "HL7-Diabetesschablone" sein, die in ähnlicher
Weise gewöhnlich
in dem Körper
von Dateien vorhanden sind, die solche Meldungstypen enthalten.
Das ID-Kriterium 416E kann der Be zeichner "PHARMdBv2" sein, der in dem
Kennsatz einer entsprechenden ".dbf" Datei vorhanden
ist, die einen derartigen Meldungstyp enthält.
-
Meldungen
die für
ein spezielles Format als gültig
festgelegt sind, können
in 4A näher
definiert werden. Die Meldungs-Setup-Startseite 404 kann
ein (z.B. durch Sender-Tasten 420 verwirklichtes)
Sender-Merkmal beinhalten, das es einem Benutzer ermöglicht, über einen
Link zu einem Schirm zu wechseln, um Charakteristiken der Transaktion
mit speziellen Handelspartnern einzustellen, z.B. Absenderidentifikation, Name
und Adresse des Absenders und sonstige den Datenaustausch betreffende
Daten. Der Meldungs-Setup-Startbildschirm 404 kann ferner
ein Modifizieren-Merkmal enthalten, um den Meldungstypbezeichner 424 und/oder
die entsprechenden ID-Kriterien 416A–E selektiv zu modifizieren.
Das Ändern-Merkmal
kann eine "Ändern"-Taste 428 (oder
-Hyperlink, usw.) beinhalten, die auf eine Auswahl durch einen Benutzer
hin ein (nicht gezeigtes) Popup-Fenster (oder einen weiteren Schirm/Seite,
usw.) anzeigen kann, das es dem Benutzer ermöglicht, die entsprechende Meldung
in einer geeigneten Weise zu ändern.
Der Meldungs-Setup-Startbildschirm 404 kann ferner ein
Hinzufügen-Merkmal
enthalten, um der Meldungstypenliste 410 einen Meldungstyp
hinzuzufügen.
Ein solches Hinzufügen-Merkmal
kann eine "Meldungstyp-Hinzufügen"-Taste 432 (oder
-Hyperlink, usw.) beinhalten, die auf eine Auswahl durch einen Benutzer
hin ein (nicht gezeigtes) Popup-Fenster (oder einen weiteren Schirm/Seite,
usw.) anzeigen kann, der es dem Benutzer ermöglicht, einen neuen Meldungstypbezeichner 424 und
geeignete ID-Kriterien 416 hinzufügen. Der Meldungs-Setup-Startbildschirm 404 kann
ferner einen Selektor enthalten, z.B. eine "Schließen"-Taste 434, die ein Benutzer
auswählen kann,
wenn er die Meldungsabgleich-GUI 400 erledigt hat.
-
Die
Datenabgleich-GUI 400 kann ein Abgleich-Setup-Merkmal enthalten,
das es einem Benutzer ermöglicht,
auszuwählen,
welches (welche) Datenfeld(er) in jedem Satz von Eingangsdaten 116 (1A)
und welches (welche) Datenfeld(er) in jedem Satz von Zieldaten 108 das
DCU-System 104 beim Abgleichen des (der) Eingangsdatensatzes
(Sätze)
mit dem (den) geeigneten Zieldatensatz (Zieldatensätzen), so
vorhanden, verwenden soll, so dass der (die) geeignete(n) Zieldatensatz
(Zieldatensätze)
mit dem (den) Eingangsdatensatz (Eingangsdatensätzen) ausgelesen und verglichen
wird/werden. Beispielsweise kann es, falls die Eingangsdaten 116 Versicherungsanrechnungssdaten
des Patienten sind, erwünscht
sein, den (die) geeigneten Zieldatensatz (Zieldatensätze), der
(die) auf einem oder mehreren Feldern von Patientenstatistikdaten,
z.B. Name des Patienten, Sozialversicherungsnummer, Geburtsdatum
und Zertifikatsnummer basiert (basieren), abzugleichen und abzurufen.
Das Abgleich-Setup-Merkmal kann für jeden Datentyp in der Datentypliste 410 durch
eine jeweils entsprechende "Abgleich-Setup"-Taste 436 (oder
-Hyperlink, usw.) initiiert werden, die die Anzeige des Datenabgleich-Setupschirms 406 (oder
eines Popup-Fensters, Dialogfensters, usw.) von 4B initiiert. 4B veranschaulicht
einen Abgleich-Setup mit Bezug auf den Datentyp Anrechnungsverifikation des
in 4A veranschaulichten ASC-X12-Formats, wie es in
dem Kennsatz 438 in dem Abgleich-Setup-Schirm 406 von 4B identifiziert
ist.
-
Der
in 4B veranschaulichte Abgleich-Setup-Schirm 406 kann
eine Anzahl von Eingangsdatenfeldselektoren 440 (z.B. Dropdown-Menüs) und eine
Anzahl jeweils entsprechender Zieldatenfeldselektoren 442 (z.B.
Dropdown-Menüs)
enthalten, die es einem Benutzer ermöglichen, jeweils das (die)
Datenfeld(er) der Eingangsdaten 116 (1A)
und das (die) Daten feld(er) der Zieldaten 108 auszuwählen, das
(die) für
das Abgleichen und Abrufen der richtigen Zieldaten zu verwenden
ist (sind). Jeder Eingangsdatenfeldselektor 440 kann sämtliche
oder einen Teilsatz der in den Eingangsdaten 116 aufscheinenden
Felder, beispielsweise in Abhängigkeit
von Informationen anzeigen, die über
den speziellen Typ der betreffenden eingehenden Meldung bekannt
sind. Ein Benutzer würde
anschließend
einen oder mehrere der Eingangsdatenselektoren 440 benutzen, um
das (die) gewünschte(n)
Eingangsdatenfeld(er) auszuwählen,
das (die) bei dem Abrufen der geeigneten Felder (Datensatzes, usw.)
der Zieldaten 108 für
den Vergleich mit den Eingangsdaten 116 zu verwenden ist (sind).
Die Zieldatenfeldselektoren 442 können in einer ähnliche
Weise wirken, jedoch um es einem Benutzer zu ermöglichen, auszuwählen, welches
(welche) jeweils entsprechende(n) der Zieldatenfelder zum Abrufen des
geeigneten Abschnitts der Zieldaten 108 zu verwenden ist
(sind).
-
Abhängig von
der Konfiguration der Zieldaten 108 ( 1A),
d.h. wie die Zieldaten in Feldern, Datensätzen oder sonstigen Datengruppen
angeordnet sind, kann der Datenabgleich-Setupschirm 406 von 4B einen "Zielquellen"-Selektor 444 (z.B.
ein Dropdown-Menü)
enthalten, der es einem Benutzer ermöglicht, eine Klasse von Daten
auszuwählen,
die einen Teilsatz von Feldern für
das Datenabgleichmodul 204 anzeigen, der in den Dropdown-Menüs der Zieldatenfeldselektoren 442 aufscheinen
wird. Falls die Zieldaten 108 beispielsweise Patientendaten
in der Klinikbetreibersoftware sind, können die Datenfelder für jeden
Patienten Patientenstatistikfelder, Versicherungsfelder, Dienstleisterfelder,
klinische Felder, usw. enthalten, die Daten beinhalten, die den
entsprechenden Feldarten entsprechen. Im veranschaulichten Fall
ist die angezeigte Zielquelle 446 "Patientenstatistik", was dem Daten abgleichmodul 204 angibt,
dass in dem Dropdown-Menü jedes
Zieldatenfeldselektors 442 lediglich Patientenstatistikdatenfelder
anzuzeigen sind. Der Zielquellenselektor 444 stellt ein
Mittel bereit, die Felder, die für
eine Auswahl mittels der Zieldatenfeldselektoren 442 verfügbar sind,
einzuschränken,
falls eine solche Einschränkung
benötigt
wird. Selbstverständlich
brauchen andere Ausführungsbeispiele
den Zielquellenselektor 444 oder ihre zugeordnete Funktionalität nicht
notwendig zu enthalten.
-
In
einigen Ausführungsbeispielen
kann es erwünscht
sein, das Datenabgleichmodul 204 mit einem oder mehreren
Merkmalen zu versehen, die es einem Benutzer ermöglichen, vielfältige Abgleichregeln
auf den Abgleich anzuwenden, den das Datenabgleichmodul durchführt, wenn
es Eingangsdaten 116 empfängt, die von dem DCU-System 104 erkannt
werden. Beispielsweise kann es auf dem Feldniveau in manchen Fällen erwünscht sein,
einen Abgleich hinsichtlich der vollständigen Ruf- und Familiennamen
von Patienten vorzunehmen, wohingegen es in anderen Fällen erwünscht sein
kann, lediglich die ersten zwei oder drei Buchstaben der Ruf- und
Familiennamen abzugleichen. Folglich kann der Datenabgleich-Setupschirm 406 für jedes
aus einem Eingangsdatenfeldselektor 440 und einem Zieldatenfeldselektor 442 gebildete
Paar einen Regelselektor 448, z.B. ein Dropdown-Menü, enthalten,
das es einem Benutzer ermöglicht,
eine gewünschte
Regel für das
Abgleichen der entsprechenden Eingangsdaten- und Zieldatenfelder
auszuwählen.
Darüber
hinaus kann es ebenfalls erwünscht
sein, Abgleichregeln auf höherem
Niveau zu implementieren, insbesondere, wenn mehrere Paare von Eingangsdaten-
und Zieldatenfeldern abzugleichen sind. Beispielsweise kann eine
Situation auftreten, in der ein Abgleichen in Bezug auf vier Zieldatenfelder
durchgeführt
wird, wobei zwei der Felder von der Art sind, dass lediglich eines
der Felder für
einen beliebigen vorgegebenen Patienten besetzt ist, wobei das Feld
als eine Funktion des Werts in einem dritten der vier Felder besetzt
ist. In diesem Fall kann eine Regel verwendete werden, die einem
Datenabgleichmodul 204 angibt, welche der beiden Felder
basierend auf dem Wert in dem dritten Feld zu beachten sind. Der
Datenabgleich-Setupschirm 406 kann
einen Regelselektor 450 enthalten, z.B. ein Dropdown-Menü, der es
einem Benutzer ermöglicht,
eine geeignete Regel für
die betreffenden speziellen Eingangsdaten 116 auszuwählen.
-
4C veranschaulicht
den Daten-Querbezugs-Schirm 408, auf den ein Benutzer ausgehend
von dem Meldungstype-Setup-Schirm 404 von 4A,
z.B. durch eine "Daten-Querbezugs"-Taste 452 (oder -Hyperlink,
usw.) zugreifen kann, um vorzugeben, welche Felder der Eingangsdaten 116 (1A und 2)
und der Zieldaten 108 das DCU-System 104 (auf
dem VERGLEICHEN/AKTUALISIEREN-Schirm 504 von 5) anzeigen
wird, und einzustellen, inwiefern das System einem Benutzer erlauben
wird, Abweichungsdaten zu behandeln. Der Daten-Querbezugs-Schirm 406 (4B)
kann einen Meldungstypindikator 454 enthalten, der anzeigt,
welcher Typ von Meldung in Frage kommt. In dem vorliegenden Beispiel
ist der Meldungstypindikator 454 Anrechnungsfähigkeitsergebnisse", der anzeigt, dass
sich die betreffenden maßgebenden
Felder auf Patientenstatistikdaten und das Datum beziehen, das der
Versicherungsanrechnungsfähigkeit
entspricht. Der Daten-Querbezugs-Schirm 406 (4B)
kann ferner einen Feldanzeigebereich 456 enthalten, der
die Bezeichner 458 von Feldern in den Eingangsdaten 116,
die Bezeichner 460 der jeweils entsprechenden Felder von
Zieldaten und "Werte-anzeigen"- und "Aktualisierung-zulassen"-Selektoren, z.B.
Kontrollkästchen 462, 464,
anzeigt, die es einem Benutzer ermöglichen, jeweils auszuwählen, welche
Datenfeld werte das DCU-System 104 auf dem VERGLEICHEN/AKTUALISIEREN-Schirm 504 (5)
anzeigen sollte, wenn Abweichungsdaten in den Eingangsdaten 116 vorhanden
sind, und welche Eingangsdatenwerte ein Benutzer zur Aktualisierung
der entsprechenden Zieldatenwerte auswählen kann. Wie sich weiter
unten ersehen lässt,
bedeutet die Tatsache, dass der Daten-Querbezugs-Schirm 406 (4B)
anzeigt, dass ein Anwender bis zu diesem Zeitpunkt mittels der Kontrollkästchen 462 die
Felderpaare FAMILIENNAME.VORNAME/NAME, MITGLIEDSNR/SSN (Sozialversicherungsnummer),
GEBURTSDATUM/DOB (Date Of Birth) und ADDRESSLNI/ADDR1 ausgewählt hat,
dass die in diesen Feldern enthaltenen Datenwerte während einer
Vergleichen/Aktualisieren-Sitzung auf dem VERGLEICHEN/AKTUALISIEREN-Schirm 504 von 5 angezeigt
werden. Zusätzlich zu
den Zeige-Werte- und Erlaube-Aktualisierung-Kontrollkästchen 462, 464 kann
der Feldanzeigebereich 456 für jedes Felderpaar eine "Querbezugs-Definitions"-Taste 466 (oder
-Hyperlink, usw.) enthalten, die es einem Benutzer erlaubt auf ein "Querbezugs-Definitions"-Fenster 468 von 4D zuzugreifen,
das es einem Benutzer ermöglicht,
für jedes
Feld der Eingangsdaten 116 ein oder mehrere Beziehungen
zwischen dem Eingangsfeld und einem (oder mehreren) Feld(ern) der
Zieldaten 108 zu definieren.
-
Wie
insbesondere in 4D gezeigt, kann das Querbezugs-Definitionsfenster 468 einen "Eingangsdatenfeld"-Bereich 470,
einen "Vergleiche-Daten-mit/Zeige-Daten-an-von"-Bereich 472,
einen "Akutalisiere-Daten-nach"-Bereich 474 und
einen "Füge-hinzu-und-trage-in-neues-Feld-ein"-Bereich 476 enthalten.
Der Eingangsdatenfeldbereich 470 kann einen Eingangsdatenfeldbezeichner 470A anzeigen,
der das aktuelle Eingangsdatenfeld identifiziert, das ausgewählt ist,
um die Querbezugs-Definition
mit einem oder mehreren jeweils entsprechenden Datenfeldern von
Zieldaten einzustellen. Der "Vergleiche-Daten- mit/Zeige-Daten-an-von"-Bereich 472 ermöglicht es
einem Benutzer zu definieren, welcher Zieldatenwert mit dem Eingangszielwert
verglichen werden wird, der in dem Eingangsdatenfeld enthalten ist,
das durch den Eingangsdatenfeldbezeichner 470A des Eingangsfeldbereichs
identifiziert ist. Im Allgemeinen definiert der Benutzer diesen
Zieldatenwert durch Auswahl eines speziellen Feldes der Zieldaten 108 (1A)
mittels einem oder mehreren Zieldaten-Selektoren in Abhängigkeit
von der Konfiguration der Zieldaten. Wie unterhalb im Zusammenhang
mit dem VERGLEICHEN/AKTUALISIEREN-Schirm 504 von 5 und
einem DCU-Verfahren 600 von 6 erörtert, wird
der in dem ausgewählten
Zieldatenfeld enthaltene maßgebende
Zieldatenwert auf dem VERGLEICHEN/AKTUALISIEREN-Schirm angezeigt,
falls der Anwender das Eingangsdaten-/Zieldatenfeldwert-Paar zur
Anzeige ausgewählt
hat, und tatsächlich
Abweichungsdaten in den Eingangsdaten 116 (1A) vorhanden
sind, für
die der Anwender konfiguriert hat, dass das DCU-System 104 ( 1A und 2)
diese identifizieren soll.
-
Um
die Auswahl eines geeigneten Zieldatenfelds zu erleichtern, kann
der "Vergleiche-Daten-mit/Zeige-Daten-an-von"-Bereich 472 einen "Zieldatenspeicher"-Selektor 472A,
einen "Feld"-Selektor 472B und
einen Feldspeicherortbereich 472C enthalten. Der Zieldatenspeicherselektor 472A und
der Feldselektor 472B können
z.B. Dropdown-Menüs 472D, 472E sein,
die es einem Benutzer ermöglichen,
zunächst
den maßgebenden
Datenspeicher 112 (1A) auszuwählen und
anschließend
das Zieldatenfeld jenes Datenspeichers auszuwählen, für den auf dem VERGLEICHEN/AKTUALISIEREN-Schirm 504 von 5 Daten
angezeigt werden sollen. Das Dropdown-Menü 472B kann Feldnamen 472F sämtlicher
in dem ausgewählten
Datenspeicher 212 vorhandener Zielfelder enthalten. Wenn
einer der Feldnamen 472F ausgewählt ist, kann der Feldspeicherortbereich 472C den
Ort des entsprechenden Zielfelds, z.B. durch Angabe eines Tabellennamens 472G und einer
Spaltenbezeichnung 472H anzeigen, falls der (die) relevante(n)
Zieldatenspeicher 112 entsprechend konfiguriert ist/sind.
Die anfängliche
Auswahl eines Zieldatenspeichers 112 mittels des Zieldatenspeicherselektors 472A kann
die Verwendung eines Verzeichnisses 256 (2)
für die
Auswahl eines Zieldatenfeldes durch den Feldselektor 472B einbeziehen.
Das Verzeichnis 256 kann Daten für den ausgewählten Zieldatenspeicher 112 enthalten,
die Datenfeldbezeichner, Feldnamen 472F und Tabellennamen
und Spaltenbezeichnungen 472G–H miteinander in Beziehung
setzen.
-
In
einigen Fälle
wird es erwünscht
sein, mehrere ähnliche
Zieldatenfelder, die in demselben oder in verschiedenen Zieldatenspeichern 112 (1A)
angeordnet sind, mit demselben in den Eingangsdaten 116 enthaltenen
Eingangsdatenwert zu aktualisieren. Falls beispielsweise ein Eingangsdatenwert
eine Gesundheitszertifikatsnummer ist, und eine spezielle Gesundheitsfürsorgeinstanz
die Zertifikatsnummer in einem Finanz-Dienstleister-Datenspeicher
und in einem Gesundheitsfürsorgeplan-Datenspeicher
speichert, wäre
es erwünscht,
beide Datenspeicher mit einer in den Eingangsdaten 116 vorhandenen
eventuellen neuen (und verifizierten) Zertifikatsnummer zu aktualisieren.
Folglich kann der "Aktualisiere-Daten-zu"-Bereich 474 mehrere Sätze von "Zieldatenspeicher"-Selektoren 474A, "Feld"-Selektoren 474B und
Feldspeicherortregionen 474C enthalten.
-
Jeder
Zieldatenspeicherselektor 474A und entsprechender Feldselektor 474B und
Feldspeicherortbereich 474C kann in einer ähnlichen
Weise arbeiten, wie der Zieldatenspeicherselektor 472A,
der Feldselektor 472B und der Feldspeicherortbe reich 472C des "Vergleiche-Daten-mit/Zeige-Daten-an-von"-Bereichs 472.
-
D.h.,
jeder Feldselektor 474B und jeder entsprechende Datenspeicherselektor 474A kann
einem Benutzer ermöglichen,
ein spezielles Zieldatenfeld eines speziellen Datenspeichers 112 auszuwählen, um
eine Aktualisierung vorzunehmen, falls der Anwender, wie oben in
Bezug auf 4C erörtert, ausgewählt hat,
dass eine derartige Aktualisierung zu erlauben ist. Falls ein Anwender
die Durchführung
einer Aktualisierung in Bezug auf ein spezielles Feld der Eingangsdaten 116 ( 1A und 2)
nicht genehmigt hat, kann der gesamte "Aktualisiere-Daten-zu"-Bereich 474 deaktiviert
werden und als ein solcher beispielsweise durch eine "Grauschattierung" des gesamten Bereichs
markiert werden.
-
In
diesem Zusammenhang ist zu beachten, dass zusätzlich zu der Bereitstellung
des Zeige-Werte-Kontrollkästchens 462 und
des Erlaube-Aktualisierung-Kontrollkästchens 464 auf dem
Setup-Schirm 408 von 4C das
Querbezugs-Definitionsfenster 468 duplikative Zeige-Werte-
und Erlaube-Aktualisierung-Kontrollkästchen 478, 480,
wie in 4D veranschaulicht, enthalten
kann. Diese duplikativen Kontrollkästchen 478, 480 ermöglichen
einem Benutzer, den Status der Erlaubnis, die Eingabedaten-/Zieldatenwerte
auf dem VERGLEICHEN/AKTUALISIEREN-Schirm 504 (5)
anzuzeigen, und/oder der Erlaubnis einer Aktualisierung zu ändern, ohne
dass zwischen dem Querbezugs-Definitionsfenster 468 und
dem Daten-Querbezugs-Schirm 408 hin- und hergewechselt
werden muss. Ein Platzieren der Zeige-Werte- und Erlaube-Aktualisierung-Kontrollkästchen 478, 480 auf
dem Querbezugs-Definitionsfenster 468 steigert den Komfort
für einen Benutzer,
falls z.B. der "Aktualisiere-Daten-zu"-Bereich 474 grau
markiert ist, um anzuzeigen, dass eine Aktualisierung des Wertes
in dem ausgewählten
Feld nicht zugelassen ist, und der Benutzer tatsächlich eine Aktualisierung
zulassen möchte.
In diesem Fall kann der Benutzer einfach das Erlaube-Aktualisierung-Kontrollkästchen 480 auswählen, um
den "Aktualisiere-Daten-zu"-Bereich 474 zu
aktivieren und dem Benutzer zu ermöglichen, das (die) entsprechende(n)
zu aktualisierende(n) Zielfeld(er) auszuwählen.
-
Wie
oben erörtert,
kann es in einigen Anwendungen erwünscht sein, einen speziellen
Eingangsdatenwert mit einem speziellen Zieldatenwert eines gewissen
Zieldatenfeldes zu vergleichen und ein anders Zieldatenfeld mit
dem Eingangsdatenwert zu aktualisieren. Das alternative Datenfeld
kann ein in naher Beziehung stehendes Feld oder eine dazu völlig beziehungsloses
Feld sein. Ein Beispiel für
ein in naher Beziehung stehendes alternatives Feld könnten Versicherungsdaten
sein, die gewöhnlich
in dem Hauptversicherungsfeld gespeichert sind. Falls die Eingangsdaten
für Versicherung
einen neuen oder abweichenden Wert anzeigen, können die neuen Daten an einer
anderen Stelle, beispielsweise "Andere
Versicherung" gespeichert
werden. Ein Beispiel für
die Erfordernis einer Aktualisierung eines keine Beziehung aufweisenden
Feldes würde
der Fall eines Überweisungsauftrags
sein, der eingehende Genehmigungsdaten enthält, die dann mit vorhandenen Daten
verglichen werden, die Kalenderdaten von Dienstleistungen betreffen.
Falls die Genehmigungsdaten für den
genehmigten Überweisungszeitraum
ein späteres
Datum anzeigen, können
die vorhandenen Daten hinsichtlich des neuen Datums aktualisiert
werden und der bestehende Überweisungsstatus
kann mit "Verlängert" aktualisiert werden.
-
In
den meisten Fällen
ist das neue (d.h. nicht verglichene) Zieldatenfeld vorhanden und
muss lediglich aus einer Liste bestehender Datenfelder ausgewählt werden.
In anderen Fällen
ist es nicht vorhanden und muss erst angelegt werden. In letzterem
Fall erlaubt der "Füge-hinzu-und-trage-in-neues-Feld-ein"-Bereich 476 einem
Benutzer, die neuen Zielfelder zu erzeugen. Um diese Funktionalität bereitzustellen,
kann der "Füge-hinzu-und-trage-in-neues-Feld-ein"-Bereich 476 einen "Felddefinitions"-Bereich 482 enthalten,
der es einem Benutzer ermöglicht, über ein "Neue-Feldnamen"-Eingabefeld 482A einen
neuen Feldnamen bereitzustellen und den Speicherort des neuen Feldes
in den Zieldaten 108 mittels einer oder mehrerer geeigneter "Feldspeicherort"-Eingabefelder 482B.482C in
Abhängigkeit
von der Art der Konfiguration der Zieldaten 108 zu definieren.
Im vorliegenden Fall wird davon ausgegangen, dass die Zieldaten 108 in
Tabellen angeordnet sind. Folglich kann der Felddefinitionsbereich 482 ein "Tabellenname"-Eingabefeld 482B und
ein "Spaltenbezeichnung"-Eingabefeld 482C enthalten.
In dem Fall, dass das neue Zieldatenfeld in einer neuen Tabelle
angeordnet ist, kann der "Füge-hinzu-und-trage-in-neues-Feld-ein"-Bereich 476 einen "Definiere-neue-Tabelle" Bereich 484 enthalten,
der es einem Benutzer ermöglicht,
in den Zieldaten 108 eine neue Tabelle zu definieren. Das
Definieren einer neuen Tabelle kann ein Eingeben eines neuen Tabellennamens
unter Verwendung eines "Neuer-Tabellenname"-Eingabefeldes 484A und ein
Konfigurieren der Tabelle, beispielsweise unter Verwendung einer
(nicht gezeigten) geeigneten Tabellen-Setup-GUI, beinhalten, auf
die über
einen "Tabellen-Setup"-Selektor 484B,
beispielsweise eine Taste oder ein Hyperlink usw., zugegriffen werden
kann. Wenn für
den Benutzer der Einsatz des Daten-Querbezugs-Schirms 406 erledigt
ist, kann der Benutzer den Schirm unter Verwendung eines geeigneten
Selektors, z.B. einer "Schließen"-Taste 486 verlassen.
-
Das
C/U-Modul 208 (2) kann einen Benutzer-Schnittstellengenerator 244 enthalten,
der eine C/U-GUI, z.B. eine in 5 veranschaulichte
C/U-GUI 500, bereitstellt. Wie in 5 gezeigt,
kann die C/U-GUI 500 einen "VERGLEICHEN/AKTUALISIEREN"-Schirm 504 aufweisen,
der in einer Vergleichen-und-Aktualisieren-Sitzung
und zu sonstigen Gelegenheiten während
des Gebrauchs des DCU-Systems 104 angezeigt wird. Beispielsweise
kann der VERGLEICHEN/AKTUALISIEREN-Schirm 504 die Startseite
des DCU-Systems 104 (1A und 2)
sein, die als Erstes bei jedem Start des Systems angezeigt wird.
Der VERGLEICHEN/AKTUALISIEREN-Schirm 504 kann ferner einen
Datenfeldbezeichnerbereich 516, einen Eingangsdatenwertanzeigebereich 520 und
einen Zieldatenwertanzeigebereich 524 enthalten, die sämtliche
nebeneinander angezeigt werden, um ein komfortables Betrachten der
relevanten Datenfeldnamen und der entsprechenden Werte sowohl der
Eingangsdaten 116 als auch der Zieldaten 108 zu
ermöglichen,
so dass ein Benutzer diese bequemen visuell vergleichen kann.
-
Der
Datenfeldbezeichner-Bereich 516 zeigt Datenfeldbezeichner 528 an,
die den Datenfeldern entsprechen, für die die Datenwerte durch
die Anwesenheit von Kontrollhäkchen
in dem entsprechenden der Zeige-Werte-Selektoren 462 gekennzeichnet
sind, um auf dem Daten-Querbezugs-Schirm 408 ( 4C)
angezeigt zu werden. In dem vorliegenden Beispiel sind die für eine Anzeige
ausgewählten
Datenfelder für
eine eingehende 271-Transaktion die Datenfelder für den Datentyp
ASC-X12-Anrechnungsfähigkeitsverifikation.
In Entsprechung zeigt der Eingangsdatenwert-Anzeigebereich 520 die
Eingangsdatenwerte 532 an, die für die angezeigten Felder in
den Eingangsdaten 116 (1A und 2)
enthalten sind. Desgleichen enthält
der Zieldatenwertanzeigebereich 524 die Zieldatenwerte 536 für die angezeigten
Felder, wie sie aus dem (den) Zieldatenspeicher(n) 112 (1A)
ausgelesen sind.
-
Zusätzlich zur
Erleichterung des visuellen Vergleichs von Eingangsdatenwerten 532 mit
Zieldatenwerten 536 durch ein Platzieren dieser Werte in
einer im Wesentlichen nebeneinander liegenden Weise kann das C/U-Modul 208 dazu
eingerichtet sein, Abweichungsdatenwerte 540, d.h. solche
Eingangsdatenwerte, die mit den jeweils entsprechenden Zieldatenwerten 536 nicht
identisch sind, visuell zu kennzeichnen. Die zum Anzeigen von Abweichungsdatenwerten 540 verwendete(n)
visuelle(n) Kennzeichnung(en) kann (können) von beliebiger Art sein.
In dem vorliegenden Beispiel sind die visuellen Kennzeichnungen
Hervorhebungen 544 (schattierte Regionen) in den Eingangsdatenwert-Anzeigebereichen 548,
die die Abweichungsdaten enthalten. Ähnliche könnten, falls gewünscht, (nicht
gezeigte) Hervorhebungen zusätzlich
oder alternativ in den Zieldatenwertanzeigebereichen 552 angeordnet
sein. Beispiele anderer visueller Kennzeichnungen beinhalten eine
Box oder eine sonstige eine Abweichungsdatenwert umgebende Form,
die Fetthervorhebung des Textes eines Abweichungsdatenwerts, die
Unterstreichung des Texts eines Abweichungsdatenwerts, das Platzieren eines
Sternchens oder eines sonstigen Symbols in Nähe eines Abweichungsdatenwertes,
usw. Die Einsetzung derartiger visueller Anzeigen kann einen Benutzer
hervorragend unterstützen,
Abweichungsdatenwerte, z.B. Abweichungsdatenwerte 540,
zu erkennen und daher rasch zu entscheiden, ob gewisse der Zieldatenwerte 536 aktualisiert,
d.h. durch die jeweils entsprechenden Eingangsdatenwerte 532 ersetzt
werden sollten oder nicht. Zu beachten ist, dass der Begriff "ersetzen" in diesem Sinne
das Szenario abdecken soll, in dem sowohl der Zieldaten als auch
der Eingangsdatenwert 536, 532 eine Nullität sind,
d.h. das entsprechende Datenfeld leer ist.
-
Der
VERGLEICHEN/AKTUALISIEREN-Schirm 504 kann ferner einen
Aktualisierungauswahlbereich 556 beinhalten, der Selektoren,
z.B. Kontrollkästchen 560,
enthält,
die es einem Benutzer ermöglichen,
den oder diejenigen der Abweichungsdatenwerte 540, so vorhanden,
auszuwählen,
die verwendet werden sollen, um den (die) jeweils entsprechenden
Zieldatenwert(e) 536, wie er (sie) in einem oder mehreren
der Zieldatenspeicher 112 (1A) gespeichert
ist (sind), zu aktualisieren. Falls ein Benutzer wünscht, dass
ein oder mehrere Zieldatenwerte 536 aktualisiert werden
sollen, wählt
der Benutzer gewöhnlich
das (die) neben dem (den) entsprechenden Eingangsdatenwert(en) angeordnete(n)
Kontrollkästchen
aus. Anschließend
kann der Benutzer nach Abschluss des Auswahlverfahrens eine "Schließen"-Taste 564 (bzw.
-Hyperlink, usw.) auswählen,
der das Aufscheinen eines (nicht gezeigten) Popup-Menüs auslösen kann.
Das Popup-Menü kann
eine Meldung "Möchten Sie
die Zieldatenwerte jetzt aktualisieren?" oder dgl. anzeigen und entsprechende "Ja"- und "Nein"-Tasten zur Steuerung
des nächsten
Schritts enthalten. Falls der Benutzer die Ja-Taste wählt, wird
das C/U-Modul 208 den (die) geeignete(n) Zieldatenspeicher 112 mit
den ausgewählten
Eingangsdatenwerten 532 aktualisieren. Falls der Benutzer
andererseits die Nein-Taste wählt,
verschwindet das Popup-Fenster, und der VERGLEICHEN/AKTUALISIEREN-Schirm 504 wird
wieder aktiv. Dem Fachmann wird klar sein, dass sich, obwohl die
Kontrollkästchen 560 dargestellt
und beschrieben sind, in Abwandlungen auch andere Auswahl-Merkmale
auf einfache Weise verwenden lassen. Beispielsweise kann das Auswahl-Merkmal
ein Auswählen
des Datenfeldbezeichners 528, Zieldatenwerts 536 oder
des Abweichungsdatenwerts 540 für jeden Zielwert, für den eine
Aktualisierung gewünscht
ist, durch Klicken auf das betreffende Element beinhalten. Nach
dem Klicken auf ein Element kann der Benutzer-Schnittstellengenerator 244 das
Element z.B. durch eine Her vorhebung kennzeichnen, die möglicherweise
eine Farbe oder Schattierung aufweist, die sich von den Hervorhebungen 544 unterscheidet,
um zwischen den beiden Arten von Hervorhebungen zu differenzieren.
-
Im
Allgemeinen verleiht das Vorhandensein der Module 200, 204, 208 (2)
dem DCU-System 104 große
Flexibilität,
die es im Wesentlichen erlaubt, das DCU-System 104 beispielsweise
als eine eigenständige Computeranwendung
zu verwirklichen und so zu konfigurieren, dass es in der Lage ist
Eingangsdaten nahezu jeden Datenformats und Datentyps zu handhaben,
die eine beliebige Anzahl von Datenformaten und Datentypen beinhalten.
Es ist jedoch ohne Weiteres klar, dass ein DCU-System der vorliegenden
Erfindung nicht notwendig mit der gesamten erwähnten Funktionalität ausgestattet
sein muss. Vielmehr braucht lediglich die für eine spezielle Anwendung
erforderliche Funktionalität
vorgesehen sein. Falls beispielsweise ein DCU-System der vorliegenden
Erfindung nicht unbedingt konfigurierbar sein muss, um im Zusammenhang
mit vielfältigen Zieldatenspeichern
einsetzbar zu sein, braucht das DCU-System nicht unbedingt die Zieldatenspeicherselektoren 472A, 474A des
Querbezugs-Definitionsfensters 468 aufzuweisen. Dies kann
beispielsweise der Fall sein, wenn das DCU-System keine eigenständige Computeranwendung ist,
sondern vielmehr in einer anderen Computeranwendung, z.B. einer
Versicherungsanrechnungsverifikationsanwendung, z.B. der Anrechnungsverifikationsanwendung
der von IDX Systems Corporation, Burlington, Vermont, beziehbaren
FLOWCAST® Gesundheitsfürsorgedatentechnologielösung, integriert
ist, oder eine eigenständige
Anwendung ist, die für eine
Schnittstellenrealisierung mit nur einem einzigen bekannten Zieldatenspeicher
vorkonfiguriert ist. In ähnlicher
Weise kann das System, falls bekannt ist, dass ein DCU-System der
vorliegenden Erfindung für
Eingangsdaten mit nur einem einzigen und bekannten Format verwendet
werden wird, unter Verzicht auf das Datenformat-ID-Modul 200 konstruiert
sein. Folglich ist dem Fachmann ohne weiteres klar, dass vielfältige DCU-Systeme,
die in den Schutzbereich der vorliegenden Erfindung fallen, auf
einfache Weise in einer Reihe unterschiedlicher Ausprägungen konstruiert
und durchgeführt
sein können.
-
6A–B veranschaulichen
ein DCU-Verfahren 600 der vorliegenden Erfindung, das durch
das DCU-System 104 von 1A und 2 oder
ein sonstiges erfindungsgemäß hergestelltes
DCU-System ausgeführt
werden kann. Zum Zwecke der Vereinfachung ist das DCU-Verfahren 600 in
Verbindung mit dem DCU-System 104 veranschaulicht.
Dementsprechend wird für
die Beschreibung des DCU-Verfahrens 600 auf 1–5 Bezug
genommen. Um den Bezug auf die Zeichnungen zu erleichtern, wird
darauf hingewiesen, dass die erste Ziffer jedes Bezugszeichens eines
Elements der Nummerierung der Figur entspricht, die das Element
enthält.
Im Allgemeinen ist die einzige Ausnahme hiervon, dass manche Bezugszeichen
der "100"-Serie sowohl in 2 als
auch in 1 aufscheinen. Das DCU-Verfahren 600 kann
als in Schritt 602 beginnend angesehen werden, wo das DCU-System 104 die
Eingangsdaten 116 gewöhnlich
anlässlich
einer Transaktion oder, allgemeiner ausgedrückt, Meldung aufnimmt. Nachdem
die eingehende Meldung empfangen ist, kann in Schritt 604 das
Meldungsformat-ID-Modul 200 an der eingehenden Meldung 116 und/oder
an dem Dateinamen der Datei, die die eingehende Meldung enthält, einen
Abgleichalgorithmus durchführen,
um zu ermitteln, ob das Format der Meldung in der Datei identifizierbar
ist. Der Abgleichalgorithmus kann ein beliebiger geeigneter Zeichen-,
Zeichenketten-, Text- oder sonstiger herkömmlicher oder davon abweichender Abgleichalgorithmus
sein.
-
Falls
das Meldungs-ID-Modul 200 in Schritt 606 ermittelt,
dass das Meldungsformat nicht identifizierbar ist, d.h. das Meldungsformat
nicht in das Meldungsformat-ID-Modul eingegeben wurde, kann das
Meldungs-ID-Modul 200 in Schritt 608 dem Benutzer
melden, dass die Meldung (das Format) nicht identifizierbar ist,
und kann außerdem
den Benutzer in Schritt 610 fragen, ob er die eingehende
Meldung sehen oder ignorieren möchte.
Falls in Schritt 612 ermittelt wird, dass der Anwender
die Eingangsdaten nicht einsehen möchte, kann das DCU-System 104 in
Schritt 614 in einen Warten-Status eintreten, der auf eine
neue eingehende Meldung oder einen Benutzervorgang wartet, beispielsweise
ein Navigieren zu einer beliebigen der vielfältigen GUIs des Systems, z.B.
zu der Format-ID-GUI 300 oder
der Meldungsabgleich-GUI 400. Falls in Schritt 612 allerdings
ermittelt wird, dass der Anwender die nicht identifizierbare Meldung
sehen möchte,
beispielsweise dadurch, dass der Benutzer eine geeignete Taste oder
einen sonstigen Selektor auswählt,
kann das Meldungsformat-ID-Modul 200 in Schritt 616 die
eingehende Meldung anzeigen, beispielsweise so, dass der Anwender in
der Lage ist, visuell zu entscheiden, ob die Meldung von einer Art
ist, für
die das DCU-System 104 konfiguriert werden sollte, diese
zu handhaben, oder ob dies nicht der Fall ist. Im Zusammenhang mit
der Anzeige der eingehenden Meldung kann das DCU-System 104 ein
(nicht dargestelltes) Merkmal bereitstellen, das es dem Benutzer
ermöglicht,
die Information über
das Meldungsformat und den Meldungstyp der eingehenden Meldung 116 sowie
die Zielmeldung 108 betreffende Daten in das System einzugeben,
so dass das System in der Lage ist, die Meldung zu erkennen und
zu verarbeiten. Das DCU-System 104 kann einen Puffer 264 oder
ein sonstiges Speichermittel verwenden, das die eingehende Meldung 116 speichert,
so dass die Meldung für
eine Verarbeitung verfügbar
ist, wenn der Anwender das System in der geeigneten Weise konfiguriert,
so dass es das neue Meldungsformat und den Meldungstyp erkennt und
handhabt. In dieser Hinsicht kann das DCU-System 104, falls
der Benutzer nicht möchte,
dass die Meldung erkannt und verarbeitet wird, dem Benutzer die Option
zur Verfügung
stellen, die Meldung einfach zu ignorieren.
-
Falls
das Meldungs-ID-Modul 200 in Schritt 606 ermittelt,
dass das Format der eingehenden Meldung, die die Eingangsdaten 116 enthält, mittels
eines geeigneten Abgleichalgorithmus identifizierbar ist, kann das Meldungs-ID-Modul
in Schritt 618 ermitteln, ob das Format erkannt wird oder
nicht, d.h. falls das Format in das DCU-System 104 eingegeben
wurde und gegenwärtig
aktiv ist. Das Meldungs-ID-Modul 200 kann den aktiven Status
des betreffenden Formats bestimmen, indem es ermittelt, ob das Kontrollkästchen 312 in
dem Meldungsformat-Setup-Startbildschirm 304 ein
Kontrollhäkchen
enthält
oder nicht. Falls das Meldungsformat nicht aktiv ist, kann das Meldungs-ID-Modul 200 in
Schritt 620 dem Benutzer melden, dass die Meldung (das
Format) identifizierbar ist, jedoch gegenwärtig nicht erkannt wird, da
es nicht aktiv ist. In Schritt 622 kann das Meldungs-ID-Modul 200 den
Benutzer fragen, ob der Benutzer wünscht, die Meldung zu sehen,
die Meldung zu genehmigen oder die Meldung zu ignorieren. Falls
das Meldungs-ID-Modul 200 in Schritt 624 ermittelt,
dass der Anwender, z.B. über
die Wahl einer geeigneten Taste oder eines sonstigen Selektors,
die eingehende Meldung sehen möchte,
kann das Meldungs-ID-Modul die Meldung anzeigen.
-
Unabhängig davon,
ob der Benutzer in Schritt 626 eine Einsicht in die Meldung
anfordert oder nicht, kann das Meldungs-ID-Modul 200 in
Schritt 628 bestimmen, ob der Benutzer eine Verarbeitung
der eingehenden Meldung ermöglichen
möchte.
-
Dies
kann erreicht werden, indem jeder (nicht gezeigte) Meldungsbildschirm
oder jedes (nicht gezeigte) Dialogfenster mit einer oder mehreren
Tasten oder sonstigen Selektoren ausgestattet ist, die es dem Benutzer
ermöglichen,
eine geeignete Wahl zu treffen. Falls das Meldungs-ID-Modul 200 ermittelt,
dass der Anwender die eingehende Meldung nicht erlauben möchte, kann
das DCU-System 104 in Schritt 630 in einen Warten-Status eintreten,
der auf eine neue eingehende Meldung oder einen Benutzervorgang
wartet, z.B. auf ein Navigieren zu einer beliebigen der vielfältigen GUIs
des Systems. Falls in Schritt 628 allerdings bestimmt wird,
dass der Anwender die nicht erkannte Meldung sehen möchte, kann
das Meldungs-ID-Modul 200 in Schritt 632 das
Format aktivieren, so dass das DCU-System 104 die eingehende
Meldung weiterverarbeiten kann.
-
Falls
das Meldungs-ID-Modul 200 in Schritt 618 ermittelt,
dass die eingehende Meldung 116 erkannt wird, oder alternativ
in Schritt 632 ermittelt, dass der Anwender das Format
aktiviert hat, kann das Verfahren 600 mit Schritt 634 fortfahren.
In Schritt 634 kann das Datenabgleichmodul 204 unter
Verwendung der auf dem Datenabgleich-Setupschirm 406 eingerichteten
Abgleichkriterien an einem ersten Satz von Eingangsdaten 116 einen
Abgleichalgorithmus durchführen,
um zu ermitteln, ob ein passender Datensatz in den Zieldaten 108 vorhanden
ist. Der Abgleichalgorithmus kann auf beliebigen geeigneten Vorgaben
von Kriterien oder Regeln basieren. Falls das Datenabgleichmodul 204 in
Schritt 636 ermittelt, dass der erste Satz von Eingangsdaten 116 nicht
in Übereinstimmung
gebracht ist, d.h. dass der Eingangsdatensatz nicht mit einem jeweils
entsprechenden Datensatz in den Zieldaten 108 in Übereinstimmung
gebracht wurde, kann das Datenabgleichmodul 204 in Schritt 638 dem
Benutzer melden, dass es keinen passenden Zieldatensatz für den betreffenden
speziellen Ein gangsdatensatz gefunden hat. In Schritt 640 kann
das Datenabgleichmodul 204 ferner den Benutzer fragen,
ob dieser den Eingangsdatensatz sehen oder ignorieren möchte.
-
Falls
durch den Datenabgleichmodul 204 in Schritt 642 ermittelt
wird, dass der Anwender den Eingangsdatensatz nicht sehen möchte, kann
das DCU-System 104 in Schritt 644 in einen Warten-Status
eintreten, der auf einen neuen Satz von Eingangsdaten 116 oder
einen Benutzervorgang wartet, z.B. eine Navigation zu einem beliebigen
der vielfältigen
GUIs des Systems. Falls allerdings das DCU-System 104 in
Schritt 642 ermittelt, dass der Anwender den nicht passenden
Datensatz sehen möchte,
indem der Benutzer beispielsweise eine geeignete Taste oder einen
sonstigen Selektor auswählt,
kann das Datenabgleichmodul 204 in Schritt 646 den
Eingangsdatensatz 116 beispielsweise anzeigen, so dass
der Anwender in der Lage ist, visuell zu entscheiden, ob der Datensatz
in Übereinstimmung
gebracht werden kann oder nicht. Im Zusammenhang mit der Anzeige
des Eingangsdatensatzes 116 kann das DCU-System 104 in
Schritt 648 einem Benutzer ermöglichen, die Option zu wählen, den
eingehenden Datensatz manuell anzupassen und dem System zu erlauben,
den Datensatz zu verarbeiten. Wie oben erwähnt, kann das DCU-System 104 den
Puffer 264 oder ein sonstiges Speichermittel verwenden,
das den Eingangsdatensatz speichert, so dass der Datensatz für eine Verarbeitung zur
Verfügung
steht, wenn der Anwender den neuen Eingangsdatensatz in der geeigneten
Weise abgeglichen hat. In dieser Hinsicht kann das DCU-System 104,
falls der Benutzer nicht möchte,
dass der Datensatz abgeglichen wird, dem Benutzer die Option zur
Verfügung
stellen, den Datensatz einfach zu ignorieren. In Schritt 650 kann
der DCU-System 104 bestimmen, ob weitere Datensätze in den
Eingangsdaten 116 enthalten sind oder nicht. In diesem
Fall kann das DCU-Verfahren in einer Schleife zu Schritt 634 zurückkehren,
um einen Abgleich mit dem nächsten
eingehenden Datensatz durchzuführen,
um einen entsprechenden Datensatz aus den Zieldaten 108 abzurufen.
Falls andererseits keine weiteren eingehenden Datensätze vorhanden
sind, kann das DCU-Verfahren 600 mit Schritt 652 fortfahren,
in dem die Abgleichschleife 654 nicht fortgesetzt wird.
-
Falls
das Datenabgleichmodul 204 in Schritt 636 ermittelt,
dass der Typ der Eingangsdaten 116 in Übereinstimmung gebracht ist,
kann es mit Schritt 656 fortfahren, in dem das C/U-Modul 208 Datenwerte
der Eingangsdaten 116 mit jeweils entsprechenden Datenwerten
der Zieldaten 108 der relevanten Datensätze für die auf dem Daten-Querbezugs-Schirm 408 ( 4C)
ausgewählten
Datenwerte vergleichen kann. In diesem Schritt kann das C/U-Modul 208 außerdem,
sofern vorhanden, Abweichungsdatenwerte 540 kennzeichnen, die
in den Eingangsdaten 116 enthalten sind. In Schritt 658 kann
das C/U-Modul 208 auf dem VERGLEICHEN/AKTUALISIEREN-Schirm 504 in
einer im Wesentlichen nebeneinanderliegenden Weise Feldnamen 528,
Zieldatenwerte 536 und Eingangsdatenwerte 532 anzeigen,
die irgendwelche Abweichungsdatenwerte 540 enthalten. In
Schritt 658 kann das C/U-Modul 208 außerdem,
so vorhanden, Abweichungsdatenwerte 540 kennzeichnen, z.B.
aufhellend hervorheben, um einem Benutzer eine rasche Identifizierung
von Abweichungsdaten zu erleichtern. Wie oben erörtert, kann ein Benutzer die
zu kennzeichnenden Abweichungsdatenwerte 540 auswählen. Das
C/U-Modul 208 kann außerdem
beliebige Aktualisierungs-Kontrollkästchen 560 auf dem VERGLEICHEN/AKTUALISIEREN-Schirm 504 anzeigen
oder aktivieren, für
die ein Anwender festgelegt hat, dass diese aktiv sind (siehe obige
Beschreibung der "Aktualisierung-zulassen"-Selektoren 464, 480),
so dass ein Benutzer in der Lage ist, die Aktualisierung von Zieldatenwerten 536 durch
jeweils entsprechende Abweichungsdatenwerte 540 einzuleiten.
-
In
Schritt 660 kann das DCU-System 104 ermitteln,
ob ein Anwender mit der Durchsicht des VERGLEICHEN/AKTUALISIEREN-Schirms 504 und/oder
dem Auswählen
von Abweichungsdatenwerten 540 für eine Aktualisierung fertig
ist oder nicht. Das DCU-System 104 kann
diese Ermittlung durch Abfrage einer Ende-Taste 564 auf dem C/U-Schirm 504 durchführen. Falls
das DCU-System 104 ermittelt,
dass der Anwender nicht fertig ist, kann das DCU-Verfahren 600 einfach
in eine Schleife 662 eintreten, die bewirkt, dass das System wartet,
bis es feststellt, dass der Benutzer zum Abschluss gekommen ist.
Falls das DCU-System 104 in Schritt 660 allerdings
ermittelt, dass der Anwender fertig ist, kann das C/U-Modul 208 in
Schritt 664 ermitteln, ob der Anwender gewählt hat,
dass irgendwelche Abweichungsdatenwerte 540 die jeweils
entsprechenden Zieldatenwerte 536 ersetzen sollen oder
nicht. Das C/U-Modul 208 kann diese Ermittlung durchführen, indem
es einfach erkennt, ob irgendwelche Kontrollkästchen 560 auf dem
C/U Schirm angekreuzt sind. Falls das C/U-Modul 208 in
Schritt 664 ermittelt, dass der Anwender keine Abweichungsdatenwerte 540 zur
Aktualisierung ausgewählt
hat, kann das Modul ein (nicht gezeigtes) Dialogfenster anzeigen,
das den Benutzer auffordert, zu bestätigen, dass der Anwender die
Sitzung beenden möchte,
ohne eine Auswahl zu treffen. Selbstverständlich würde das C/U-Modul 208 ein
derartiges Dialogfenster lediglich dann anzeigen, wenn Abweichungsdatenwerte zur
Aktualisierung vorhanden ist. Nach der Anzeige eines derartigen
Dialogfensters und dem Erhalt einer Benutzerantwort kann das DCU-Verfahren 600 mit
Schritt 650 fortfahren, in dem das DCU-System 104 ermitteln kann,
ob die Eingangsdaten 116 weitere zu verarbeitende Datensätze enthalten
oder nicht.
-
Falls
das C/U-Modul 208 in Schritt 664 andererseits
ermittelt, dass der Anwender Abweichungsdatenwerte 540 zur
Aktualisierung ausgewählt
hat, kann das C/U-Modul 208 in Schritt 666 beispielsweise über ein (nicht
gezeigtes) Dialogfenster eine Bestätigung darüber einholen, dass der Anwender
tatsächlich
eine Aktualisierung sämtlicher
Werte ausgewählt
hat, für
die er eine Aktualisierung wünscht.
Nachdem der Anwender eine derartige Bestätigung abgegeben hat, kann
das C/U-Modul 208 in Schritt 668 die geeigneten
Zieldatenwerte 536 mit den jeweils entsprechenden Abweichungsdatenwerten 540 aktualisieren.
Nach der Aktualisierung in Schritt 668 kann das DCU-Verfahren 600 mit
Schritt 650 fortfahren, in dem das DCU-System 104 ermitteln
kann, ob die Eingangsdaten 116 weitere zu verarbeitende
Datensätze
enthalten oder nicht.
-
Obwohl
die Erfindung mit Bezug auf ein Ausführungsbeispiel der Erfindung
beschrieben und veranschaulicht wurde, sollte dem Fachmann klar
sein, dass die vorausgehenden und vielfältige sonstige Änderungen,
Auslassungen und Hinzufügungen
daran vorgenommen werden können,
ohne dass von dem Gegenstand der vorliegenden Erfindung abgewichen
wird.
-
-
-
-