|
| |
Allgemeines zu Plausibilitätsprüfungen und Fehlerhandling
 | Plausibiltätsprüfungen können an verschiedenen Ebenen des 3-Schichtenmodells
ausgeführt werden |
| Plausibiltätsprüfungen können zu verschiedenen Zeiten im Meldeablauf durchgeführt
werden |
| Plausibiltätsprüfungen finden sowohl bei den RS als auch in der ZDB statt |
| festgestellte Fehler können zu einer Ablehnung des Datums oder Datensatzes führen |
| Warnungen und Hinweise werden dem Benutzer nur zur Kenntnis gegeben |
| bestimmte Fehler müssen nach Bestätigung durch den Benutzer dennoch angenommen werden |
| nachträgliche Querprüfungen führen zu Kontroll- und Nachbearbeitungsaufwand |
| automatisch ausgelöste Aktionen erfordern Rücklauf- und Fristenkontrolle |
| für die Fehlernachbearbeitung und Korrektur sind die RS zuständig, die ZDB
unterstützt dabei |
| ein einheitliches und abgestimmtes Verfahren bei allen RS und der ZDB wird angestrebt.
Vorschläge zu einem Workflow zur Plausibilitätsprüfung, Fehlerverfolgung und -korrektur
liegt im Entwurf vor (siehe F0 in Datenfluss.vsd.) |
| Eine Liste der möglichen konkreten Fehlermeldungen siehe Plausi-Prüfungen im Data-Dictionary |
Verschiedene Typen der Plausibilitätsprüfung
| Typ |
Art |
Beschreibung |
| 0 |
System-Prüfung |
Prüfung von Systemfehlern, wie z.B. falsche Meldungen oder falsche
Spalten, Dialog-Ablauffehler und außerordentliche Ereignisse in der Programmsteuerung |
| 1 |
Syntaktische Prüfung |
Prüfung erfolgt ohne Kenntnis der Bedeutung eines Datums direkt bei der
Eingabe , z.B. Eingabe nicht numerisch (identisch bei RS und ZDB). |
| 2 |
Semantisch am Feld |
Prüfung erfolgt durch Wissen über die Bedeutung des einzelnen Datums,
z.B. Rasse zwischen 1 und 999 (identisch bei RS und ZDB). |
| 3 |
Semantisch im Satz-Kontext |
Prüfung erfolgt durch Wissen über die Bedeutung der Datenfelder im
Kontext und im Bezug im einzelnen Datensatz zueinander, z.B. Geschlecht bei Geburt nur 1
oder 2, LOM auf Betrieb nicht vorhanden (Prüfung i.d.R. gegen andere Tabelle, im
jeweiligen Kontext von RS und ZDB) |
| 4 |
Apriori im Gesamtkontext |
Prüfung erfolgt durch Vorabvergleich mit vorhandenen Sätzen, z.B. Tier
mit dieser LOM bereits abgegangen (Prüfung vor Speicherung, i.d.R. gegen selbe Tabelle,
im jeweiligen Kontext von RS und ZDB) |
| 5 |
Aposteriori |
Prüfung erfolgt im Nachhinein durch Abgleich vorhandenen Sätzen, z.B.
Abgang mit dieser LOM nirgends als Zugang gespeichert(Prüfung nach Speicherung, nur
zentral bei der ZDB) |
Unterschiedliche Fehler-Schwere
| Schwere |
Art |
Beschreibung |
Konsequenz |
| 0 |
OK |
Daten ohne jegliche Beanstandung |
Daten akzeptiert |
| 1 |
Hinweis |
Hinweis ausgeben |
Daten trotzdem akzeptiert |
| 2 |
Nachfrage |
Nachfrage ob das wirklich stimmt |
Daten erst mal nicht annehmen, bei Bestätigung hat die Plausi nur noch
Schwere 0 statt 2 |
| 3 |
Fehler |
nicht akzeptierbarer Fehler |
Daten werden nicht angenommen |
| 4 |
Panik |
schwerer Fehler |
Daten werden nicht angenommen, Verbindung wird unterbrochen |
Allgemeines zur Fehlerliste
| Jeder Fehler hat eine eindeutige Nummer, daraus geht folgendes hervor:
 | Fehlertyp |
| Schwere des Fehlers |
| betroffenes Datenfeld oder Datensatz |
| festgestelle Unplausibilität |
| Bezug zu anderen betroffenen Datensätzen |
|
| Je nach Ort der Plausiprüfung (RS, IVR, HIT-Server) können abweichende Regeln gelten.
Die verwendeten Fehlernummern sollten aber abgestimmt und überschneidungsfrei sein |
| zu jedem Fehler existiert eine eindeutige Fehlermeldung |
| zu jedem Fehler existiert eine Standardreaktion
| z.B. Ablehnung vom System |
| Meldung an RS |
| direktes Erstellen von Anschreiben |
|
| bei später hinzukommenden Prüfungen muß Datum der Einführung vermerkt werden |
Besondere Hinweise für RS
| Plausi-Fehler die mit ca. gleicher Wahrscheinlichkeit auch durch eine vorhandene falsche
andere Meldung oder eine fehlende andere Meldung verursacht werden können, werden zweimal
geprüft
| durch eine Plausi-Prüfungen vom Typ 2 bei der Eingabe mit Nachfrage, RS können diese
Nachfrage standardmäßig mittels FORCE (d.h. Aktions-Subcode /T oder /S ??) übergehen |
| durch eine Plausi-Prüfungen vom Typ 5 , mit Benachrichtigung aller möglicherweise
beteiligten RS |
|
| Wenn einer der beteiligten Meldungen durch Korrektur den Fehler auflöst, wird
automatisch auch der 2. betroffene Satz in einen korrekten Zustand überführt und eine
weitere Fehlerverfolgung ist nicht mehr nötig. |
| Es existiert ein konkreter Vorschlag zum Fehlermanagement an den
RS |
Besondere Felder
| Geburt:
| LOM : Wir akzeptieren DE000912345678 und DE0912345678 und 0912345678 und 276000912345678
nicht aber 2760912345678 !! ???
am Telefon kann bis auf die letzten 4 Stellen gekürzt werden (DE kommt sowieso nicht) |
| MUTTER:
 | Wir akzeptieren DE000912345678 und DE0912345678 und 0912345678 und 276000912345678
nicht aber 2760912345678 !! ??? |
| alte deutsche alphanumerische mit neuer vom LKV generierten DE-LOM (Herkunft damit noch
nicht deutsch) |
| Marken aus Mitgliedsstaaten:
AT123456789, FR123456789012 oder 2710000 ...., d.h. alpha oder numerisches
Länderkennzeichen und Ziffern
aber keine LOM mit alpha Teil außer Land |
| allemeine Routine zur Identifikation international gültiger LOM muß erstellt werden |
|
|
Fehlerliste
Den aktuellen Stand siehe HIT-Plausi-Prüfungen.
Die interne Version wird in Access gepflegt, siehe Datenstrukturen.zip.
|
