DE102006057149A1 - System und Verfahren zum Erleichtern eines visuellen Vergleichs von Eingangsdaten mit vorhandenen Daten - Google Patents

System und Verfahren zum Erleichtern eines visuellen Vergleichs von Eingangsdaten mit vorhandenen Daten Download PDF

Info

Publication number
DE102006057149A1
DE102006057149A1 DE102006057149A DE102006057149A DE102006057149A1 DE 102006057149 A1 DE102006057149 A1 DE 102006057149A1 DE 102006057149 A DE102006057149 A DE 102006057149A DE 102006057149 A DE102006057149 A DE 102006057149A DE 102006057149 A1 DE102006057149 A1 DE 102006057149A1
Authority
DE
Germany
Prior art keywords
data
user
input data
message
data values
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102006057149A
Other languages
English (en)
Inventor
Mary J. Roseville Ammer
Deborah J. Hinesburg Belcher
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
IDX Investment Corp
Original Assignee
IDX Investment Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by IDX Investment Corp filed Critical IDX Investment Corp
Publication of DE102006057149A1 publication Critical patent/DE102006057149A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/26—Visual data mining; Browsing structured data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T11/00—2D [Two Dimensional] image generation
    • G06T11/60—Editing figures and text; Combining figures or text

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • User Interface Of Digital Computer (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Ein Datenvergleichs- und -aktualisierungssystem (104), das ein Vergleichs-/Aktualisierungsmodul (208) enthält, das auf einem Bildschirm eine Vergleichs-/Aktualisierungs-GUI (GUI = Graphical User Interface, Grafische Benutzerschnittstelle) (500) anzeigt, die es einem Benutzer ermöglicht, Eingangsdaten (116), die in dem System eingehen, mit vorhandenen Zieldaten (108) visuell zu vergleichen. Das Vergleichs-/Aktualisierungsmodul (208) kann konfiguriert sein, um Abweichungsdaten (540) in den Eingangsdaten (116) bezüglich der Zieldaten (108) mit einem Kennzeichen zu versehen und dem Benutzer zu ermöglichen, auszuwählen, welche der Zieldaten, sofern vorhanden, mit den Abweichungsdaten zu aktualisieren sind. Das System enthält ferner ein Datenabgleichmodul (208), das es einem Benutzer ermöglicht, die Eignung von zu vergleichenden Daten zu bewerten und die Eingangsdatenfelder (440) auszuwählen, die in Zusammenhang mit dem Abrufen der geeigneten Zieldatenfelder (442) für einen Einsatz in dem visuellen Vergleich genutzt werden sollen. Das System (104) enthält Ausstattungsmerkmale, die es einem Benutzer ermöglichen, das System so zu konfigurieren, dass es Eingangsdaten vielfältiger Typen und Formate erkennt.

Description

  • 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
    Figure 00140001
  • Zahler empfängt gerade die Daten von eine Arbeitgeber oder Dienstleister Exemplarische Meldungstypen für ASC-X12-Transaktionen in Tabelle I Tafel III
    Figure 00150001
  • 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.
  • ELEMENTELISTE
    Figure 00510001
  • Figure 00520001
  • Figure 00530001
  • Figure 00540001

Claims (10)

  1. Verfahren zum Erleichtern des visuellen Vergleichs einer Anzahl von Eingangsdatenwerten (532) mit einer Anzahl von Zieldatenwerten (536), wobei die Anzahl von Eingangsdatenwerten jeweils einer Anzahl von Eingangsdatenfeldern (440) zugeordnet ist, und die Anzahl von Zieldatenwerten jeweils einer Anzahl von Zieldatenfeldern (442) zugeordnet und in mindestens einem Zieldatenspeicher (112) gespeichert ist, wobei das Verfahren die Schritte aufweist: a) Empfangen einer Auswahl (448) von wenigstens einem Eingangsdatenfeld (440) aus der Anzahl von Eingangsdatenfeldern (440) über eine erste Benutzerschnittstelle (400); b) Abrufen der Anzahl von Zieldatenwerten (536) von dem wenigstens einen Zieldatenspeicher (112) als Funktion des wenigstens einen ausgewählten Eingangsdatenfelds (440); und c) Anzeigen der Anzahl von Zieldatenwerten (536) und der Anzahl von Eingangsdatenwerten (532) gleichzeitig miteinander auf einem Bildschirm (504), um einen visuellen Vergleich der Anzahl von Zieldatenwerten (536) und der Anzahl von Eingangsdatenwerten (532) zu erleichtern.
  2. Verfahren nach Anspruch 1, wobei die Eingangsdatenwerte (532) in einer Datei enthalten sind, die ein Datenformat aufweist, und das Verfahren ferner den Schritt des Empfangens einer Identifizierung des Datenformats über eine zweite Benutzerschnittstelle (300) beinhaltet.
  3. Verfahren nach Anspruch 2, ferner mit den Schritten: Anzeigen einer Anzahl von Datenformatbezeichnern (332) auf dem Bildschirm und Empfangen einer Benutzerauswahl wenigstens eines aus der Anzahl von Datenformatbezeichnern (332), der dem Datenformat entspricht.
  4. Verfahren nach Anspruch 1, wobei die Eingangsdatenwerte (532) wenigstens einem Datentyp zugeordnet sind, und das Verfahren ferner den Schritt des Empfangens einer Identifizierung des wenigstens einen Datentyps über eine dritte Benutzerschnittstelle beinhaltet.
  5. Verfahren nach Anspruch 1, ferner mit den Schritt: Vergleichen jeweils entsprechender Datenwerte aus der Anzahl von Zieldatenwerten (536) und aus der Anzahl von Eingangsdatenwerten (532) miteinander, um zu ermitteln, ob oder irgendwelche aus der Anzahl von Eingangsdatenwerten in Bezug auf die Anzahl von Zieldatenwerten (536) Abweichungsdatenwerte (540) sind oder nicht.
  6. Verfahren nach Anspruch 5, ferner mit dem Schritt, Anzeigen eines Abweichungsdatenkennzeichens (544) auf dem Bildschirm (504) für zumindest einen Teil der Abweichungsdatenwerte (540).
  7. Verfahren nach Anspruch 6, ferner mit dem Schritt, Anzeigen eines Aktualisierungsselektors (560) für wenigstens einen der Abweichungsdatenwerte (540), wobei der Aktualisierungsselektor (560) operativ eingerichtet ist, in Reaktion auf seine Auswahl einen jeweils entsprechenden aus der Anzahl von Zieldatenwerten (536) mit dem wenigstens einen Abweichungsdatenwert (540) zu aktualisieren.
  8. Verfahren nach Anspruch 1, ferner mit dem Schritt: Anzeigen einer ersten Benutzerschnittstelle (408), die dazu eingerichtet ist, einem Benutzer zu ermöglichen, zwischen einigen der Anzahl von Eingangsdatenfeldern (440) und einigen der Anzahl von Zieldatenfeldern (442) Querbezüge herzustellen.
  9. Verfahren nach Anspruch 1, ferner mit dem Schritt: Anzeigen einer zweiten Benutzerschnittstelle (504), die dazu eingerichtet ist, einem Benutzer zu ermöglichen, einige aus der Anzahl von Eingangsdatenfeldern (440) auszuwählen, für die Abweichungsdatenwerte (540) darin mit einem Kennzeichen (544) auf dem Bildschirm (504) versehen sind.
  10. Verfahren nach Anspruch 1, ferner mit dem Schritt: Anzeigen einer dritten Benutzerschnittstelle, die dazu eingerichtet ist, einem Benutzer zu ermöglichen, einige aus der Anzahl von Eingangsdatenfeldern (440) auszuwählen, für die Abweichungsdatenaktualisierungsselektoren (560) auf dem Bildschirm angezeigt sind.
DE102006057149A 2005-12-01 2006-12-01 System und Verfahren zum Erleichtern eines visuellen Vergleichs von Eingangsdaten mit vorhandenen Daten Withdrawn DE102006057149A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/292,176 2005-12-01
US11/292,176 US20070127597A1 (en) 2005-12-01 2005-12-01 System and method for facilitating visual comparison of incoming data with existing data

Publications (1)

Publication Number Publication Date
DE102006057149A1 true DE102006057149A1 (de) 2007-06-28

Family

ID=37671788

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102006057149A Withdrawn DE102006057149A1 (de) 2005-12-01 2006-12-01 System und Verfahren zum Erleichtern eines visuellen Vergleichs von Eingangsdaten mit vorhandenen Daten

Country Status (6)

Country Link
US (1) US20070127597A1 (de)
JP (1) JP2007157151A (de)
CN (1) CN101030207B (de)
CA (1) CA2569768A1 (de)
DE (1) DE102006057149A1 (de)
GB (1) GB2433013A (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8620286B2 (en) 2004-02-27 2013-12-31 Synchronoss Technologies, Inc. Method and system for promoting and transferring licensed content and applications
US8615566B1 (en) 2001-03-23 2013-12-24 Synchronoss Technologies, Inc. Apparatus and method for operational support of remote network systems
WO2005010715A2 (en) 2003-07-21 2005-02-03 Fusionone, Inc. Device message management system
US9542076B1 (en) 2004-05-12 2017-01-10 Synchronoss Technologies, Inc. System for and method of updating a personal profile
KR20070038462A (ko) 2004-05-12 2007-04-10 퓨전원 인코포레이티드 향상된 접속 인식 시스템
US8271941B2 (en) * 2006-10-31 2012-09-18 International Business Machines Corporation Method and apparatus for representing and configuring flexible and extensible presentation patterns
KR20090113310A (ko) 2007-01-26 2009-10-29 퓨전원 인코포레이티드 모바일 디바이스에서 사용하기 위한 콘텐츠를 백업하는 시스템 및 방법
US9224179B2 (en) * 2007-05-14 2015-12-29 The University Of Utah Research Foundation Method and system for report generation including extensible data
US8635069B2 (en) * 2007-08-16 2014-01-21 Crimson Corporation Scripting support for data identifiers, voice recognition and speech in a telnet session
CN101751266B (zh) * 2008-12-02 2013-02-06 爱思开电讯投资（中国）有限公司 用于更新gui组件的方法和装置
US8943428B2 (en) * 2010-11-01 2015-01-27 Synchronoss Technologies, Inc. System for and method of field mapping
US8959604B2 (en) 2011-11-25 2015-02-17 Synchronoss Technologies, Inc. System and method of verifying a number of a mobile terminal
US10839046B2 (en) * 2012-03-23 2020-11-17 Navya Network, Inc. Medical research retrieval engine
US10489859B1 (en) * 2013-08-29 2019-11-26 Allstate Insurance Company Life insurance clearinghouse
US9257049B2 (en) * 2014-01-29 2016-02-09 Honeywell International Inc. Method for management of air traffic control center database used for air traffic control center logon
US11170019B1 (en) 2015-10-06 2021-11-09 Wells Fargo Bank, N.A. Data field transaction repair interface
US11087296B1 (en) * 2016-09-06 2021-08-10 Wells Fargo Bank, N.A. Programmatic reconciliation of electronic receivables
US11792305B1 (en) * 2022-06-21 2023-10-17 Fidus Global, Llc Warehouse control system

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5519606A (en) * 1992-01-21 1996-05-21 Starfish Software, Inc. System and methods for appointment reconciliation
US5392390A (en) * 1992-04-10 1995-02-21 Intellilink Corp. Method for mapping, translating, and dynamically reconciling data between disparate computer platforms
US5546580A (en) * 1994-04-15 1996-08-13 Hewlett-Packard Company Method and apparatus for coordinating concurrent updates to a medical information database
US5909568A (en) * 1996-09-03 1999-06-01 Apple Computer, Inc. Process and apparatus for transferring data between different file formats
US6212529B1 (en) * 1996-11-13 2001-04-03 Puma Technology, Inc. Synchronization of databases using filters
US5966717A (en) * 1996-12-20 1999-10-12 Apple Computer, Inc. Methods for importing data between database management programs
GB9713719D0 (en) * 1997-06-27 1997-09-03 British Telecomm Data model compiler
US6601071B1 (en) * 1999-08-04 2003-07-29 Oracle International Corp. Method and system for business to business data interchange using XML
US6718336B1 (en) * 2000-09-29 2004-04-06 Battelle Memorial Institute Data import system for data analysis system
US7143076B2 (en) * 2000-12-12 2006-11-28 Sap Aktiengesellschaft Method and apparatus for transforming data
US6668254B2 (en) * 2000-12-21 2003-12-23 Fulltilt Solutions, Inc. Method and system for importing data
US20040158567A1 (en) * 2003-02-12 2004-08-12 International Business Machines Corporation Constraint driven schema association
CN1632790A (zh) * 2003-12-22 2005-06-29 唐孟环 商务信息管理查询方法

Also Published As

Publication number Publication date
GB2433013A (en) 2007-06-06
CA2569768A1 (en) 2007-06-01
JP2007157151A (ja) 2007-06-21
CN101030207A (zh) 2007-09-05
CN101030207B (zh) 2012-11-14
GB0624155D0 (en) 2007-01-10
US20070127597A1 (en) 2007-06-07

Similar Documents

Publication Publication Date Title
DE102006057149A1 (de) System und Verfahren zum Erleichtern eines visuellen Vergleichs von Eingangsdaten mit vorhandenen Daten
DE112016002395T5 (de) Zugriffskontrolle für Datenressourcen
DE102004012839B4 (de) System und Verfahren zur Bereitstellung von Hilfeinformation
DE102005016561B4 (de) Verfahren und Vorrichtung zur strukturierten Erfassung und Bearbeitung von in einem System auftretenden Problemen
DE102014213036A1 (de) Datenqualitätsmonitore
DE10348371A1 (de) Mehrfachorganisationsdatenzugriffsüberwachungs- und -managementsystem
DE112010004946T5 (de) Dynamisches Verwalten einer sozialen Netzwerkgruppe
DE10348337A1 (de) Inhaltsverwaltungsportal und Verfahren zum Kommunizieren von Informationen
DE19844013A1 (de) Strukturierter Arbeitsordner
DE202011110895U1 (de) Echtzeitsynchronisierte Bearbeitung von Dokumenten durch mehrere Benutzer für das Bloggen
DE69628374T2 (de) Datenverwaltungssystem
WO2007022874A1 (de) System, verfahren und computerprogrammprodukt zur arbeitsflussbasierten datenverarbeitung
DE10129636A1 (de) Verfahren und Vorrichtung zum Verknüpfen elektronischer Tinte mit personengebundenen elektronischen Informationssystemen
DE112013006511T5 (de) Programm und Elektronisches-Handbuch-Anzeigevorrichtung
DE102009019319A1 (de) Verfahren zur Erzeugung mindestens einer Anwendungsbeschreibung
DE112020005268T5 (de) Automatisches erzeugen von schema-annotationsdateien zum umwandeln von abfragen in natürlicher sprache in eine strukturierte abfragesprache
DE10253676B4 (de) Verfahren und Vorrichtung für die Fernübertragung sensibler Daten
DE112020000004T5 (de) Informationsbereitstellungssystem und Informationsbereitstellungsverfahren
DE202019102730U1 (de) Lernmaschine für intelligente Kommunikation und Analyse
DE112020000003T5 (de) Informationsbereitstellungssystem und Informationsbereitstellungsverfahren
US20020055937A1 (en) Immigration case management system
DE69709918T2 (de) Relationelle datenbank die in einer speicherstruktur compiliert und gespeichert ist
DE60037681T2 (de) Verfahren zum automatischen und gesicherten suchen von daten mit hilfe eines datenübertragungsnetzwerks
EP1798673A1 (de) Computer-implementiertes System zur Erzeugung, Bearbeitung und Verwaltung von strukturierten Datensätzen
WO2005050471A2 (de) Datenverarbeitungssystem und -vorrichtung

Legal Events

Date Code Title Description
R005 Application deemed withdrawn due to failure to request examination

Effective date: 20131203