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.