Hersteller von Produkten, die E-Rezept-FHIR produzieren (PVS, AVS, Apotheken- und evtl. auch Kassenrechenzentren) können nach Aufnahme neuer Profilpaketversionen in den Referenzvalidator der uAG ein ZIP mit FHIR-Ressourcen für diese neuen Versionen schicken. Diese Ressourcen werden dann Teil des Akzeptanz- bzw. Regressionstests für den Referenzvalidator, solange die betreffenden Profilpaketversionen vom Referenzvalidator unterstützt werden.
Voraussetzung für die Aufnahme in den Korpus ist natürlich, daß die Ressourcen zum Zeitpunkt der Einreichung als valide akzeptiert werden. Das ZIP braucht also gar nicht erst abgeschickt zu werden, wenn der Referenzvalidator nicht alle enthaltenen Ressourcen klaglos akzeptiert. Bei dieser Vorbereitungsarbeit kann der Absender Fehler im eigenen System finden, aber auch welche in den Profilen und/oder im HAPI und/oder im Referenzvalidator (und dann an die uAG melden). Aber die Regel ist, daß nur bei Akzeptieren aller Ressourcen im ZIP (maschinelle Prüfung) diese Datei überhaupt von einem Menschen in der uAG angeschaut werden muß. Bei Fehlern gibt es bestenfalls eine maschinelle Ablehnungsmeldung. Und im Akzeptanzfall gibt es kaum mehr zu tun, als das ZIP in das passende Verzeichnis zu sortieren (i.e. Testlauf erfolgt gleich gegen das ZIP, Auspacken ist nicht notwendig).
Für den Absender/Ersteller des ZIPs liegt der Vorteil im Vermeiden der Gefahr, daß zukünftige Auflagen des Referenzvalidators auf einmal anfangen, diese Ressourcen abzulehnen.
Für uns liegt der Vorteil darin, daß wir mehr Testfälle mit größerer Variation in die Hand bekommen, was einen größeren Schutz vor Regressionen und vor unvorhergesehenen Interaktionen zwischen Daten und Regeln bedeutet. 'Unvorhergesehen' kann bei der aktuell hohen Änderungsfrequenz der Vorschriften/Spezifikationen schnell passieren.
Z.B. stünde man bei Verwendung des FiveRX-Protokolls (bzw. ApoTI 0.9) momentan vor einem Problem, wenn jemand auf einem T-Rezept auseinzeln täte. Auseinzelung bedeutet Transaktionsnummer + Hash + Zusatzdaten, die nur bei Wahl des Elements pRezept kodierbar sind. Die T-Rezept-Felder sind aber im pRezept gar nicht enthalten; die gibt es nur im Element eMuster16. Ähnlich ist die Lage für Impfstoffe oder BG-Rezepte mit Auseinzelung/Rezepturen.
Ein Fachexperte - e.g. AVS-Hersteller - wird solche Fälle eher vorhersehen können, da seine Software diesen Fall ja irgendwie abdecken muß (selbst wenn es nur in ausschließender Weise ist, i.e. 'aufgrund der geltenden Vorschriften kann der Fall momentan nicht auftreten'). Diese Expertise kann über den hier vorgeschlagenen Mechanismus auch dem Referenzvalidator zugute kommen.
Softwarehersteller müssen sich auch im Fall von Grauzonen oder Grenzfällen so oder so für irgendeine Lösung entscheiden. Durch Einreichen entsprechender Testfälle können sie sich gewissermaßen eine Art Frühwarnsystem schaffen und bösen Überraschungen vorbeugen. Zumindest wird vermieden, daß durch Änderungen des Referenzvalidators jemandem ungewollt Sand ins Getriebe geschüttet wird.
Insgesamt kann das für die Akzeptanz des Referenzvalidators nur von Vorteil sein.
Hersteller von Produkten, die E-Rezept-FHIR produzieren (PVS, AVS, Apotheken- und evtl. auch Kassenrechenzentren) können nach Aufnahme neuer Profilpaketversionen in den Referenzvalidator der uAG ein ZIP mit FHIR-Ressourcen für diese neuen Versionen schicken. Diese Ressourcen werden dann Teil des Akzeptanz- bzw. Regressionstests für den Referenzvalidator, solange die betreffenden Profilpaketversionen vom Referenzvalidator unterstützt werden.
Voraussetzung für die Aufnahme in den Korpus ist natürlich, daß die Ressourcen zum Zeitpunkt der Einreichung als valide akzeptiert werden. Das ZIP braucht also gar nicht erst abgeschickt zu werden, wenn der Referenzvalidator nicht alle enthaltenen Ressourcen klaglos akzeptiert. Bei dieser Vorbereitungsarbeit kann der Absender Fehler im eigenen System finden, aber auch welche in den Profilen und/oder im HAPI und/oder im Referenzvalidator (und dann an die uAG melden). Aber die Regel ist, daß nur bei Akzeptieren aller Ressourcen im ZIP (maschinelle Prüfung) diese Datei überhaupt von einem Menschen in der uAG angeschaut werden muß. Bei Fehlern gibt es bestenfalls eine maschinelle Ablehnungsmeldung. Und im Akzeptanzfall gibt es kaum mehr zu tun, als das ZIP in das passende Verzeichnis zu sortieren (i.e. Testlauf erfolgt gleich gegen das ZIP, Auspacken ist nicht notwendig).
Für den Absender/Ersteller des ZIPs liegt der Vorteil im Vermeiden der Gefahr, daß zukünftige Auflagen des Referenzvalidators auf einmal anfangen, diese Ressourcen abzulehnen.
Für uns liegt der Vorteil darin, daß wir mehr Testfälle mit größerer Variation in die Hand bekommen, was einen größeren Schutz vor Regressionen und vor unvorhergesehenen Interaktionen zwischen Daten und Regeln bedeutet. 'Unvorhergesehen' kann bei der aktuell hohen Änderungsfrequenz der Vorschriften/Spezifikationen schnell passieren.
Z.B. stünde man bei Verwendung des FiveRX-Protokolls (bzw. ApoTI 0.9) momentan vor einem Problem, wenn jemand auf einem T-Rezept auseinzeln täte. Auseinzelung bedeutet Transaktionsnummer + Hash + Zusatzdaten, die nur bei Wahl des Elements
pRezeptkodierbar sind. Die T-Rezept-Felder sind aber impRezeptgar nicht enthalten; die gibt es nur im ElementeMuster16. Ähnlich ist die Lage für Impfstoffe oder BG-Rezepte mit Auseinzelung/Rezepturen.Ein Fachexperte - e.g. AVS-Hersteller - wird solche Fälle eher vorhersehen können, da seine Software diesen Fall ja irgendwie abdecken muß (selbst wenn es nur in ausschließender Weise ist, i.e. 'aufgrund der geltenden Vorschriften kann der Fall momentan nicht auftreten'). Diese Expertise kann über den hier vorgeschlagenen Mechanismus auch dem Referenzvalidator zugute kommen.
Softwarehersteller müssen sich auch im Fall von Grauzonen oder Grenzfällen so oder so für irgendeine Lösung entscheiden. Durch Einreichen entsprechender Testfälle können sie sich gewissermaßen eine Art Frühwarnsystem schaffen und bösen Überraschungen vorbeugen. Zumindest wird vermieden, daß durch Änderungen des Referenzvalidators jemandem ungewollt Sand ins Getriebe geschüttet wird.
Insgesamt kann das für die Akzeptanz des Referenzvalidators nur von Vorteil sein.