Aus Hinweis "nicht validierbar" SOLL (manchmal) ERROR

[magrimuc]

In angehängtem BSP ist m.E. eine Schwierigkeit:

Die Datei GonalMitSPZN.xml.txt enthält einen Block von Zeile 137 bis 172

<lineItem>...<chargeItemCodeableConcept>...<code value="09999643"/> dazu diverse Zahlungsinformationen an der Abrechnungszeile. Die Daten sind redundant: auf Papierrezept war PZN 09999643 eine Steuernummer für künstliche Befruchtung. In eRezepten gibt es dafür Zusatzattribut mit Wert = 9.

Ausführlich: `

                        <extension url="Schluessel">
                            <valueBoolean value="true"/>
                        </extension>
                    </extension>`

Ich ergreife Partei für den Standpunkt: die Datei darf abgelehnt werden. Die (von mir derzeit nur erfundene) Gefahr besteht, dass optionale, nicht validierbare Segmente Fehler enthalten oder Widersprüche (meint: fachlich sich widersprechende Angaben) erzeugen. Deswegen SOLL: ERROR IST: VALID

ps: Hinweis (von Validator Version 5.5.11 (Git# 31e05f39fad9). Built 2021-11-11T06:52:38.169Z) `

Bundle.entry[3].resource.lineItem[0].chargeItem.ofType(CodeableConcept).coding[0] (l139/c15) | information | Code System URI "http://TA1.abda.de" ist unbekannt, so dass der Code nicht validiert werden kann -- | -- | -- Bundle.entry[3].resource.lineItem[1].chargeItem.ofType(CodeableConcept).coding[0] (l264/c15) | information | Code System URI "http://fhir.de/CodeSystem/ifa/pzn" ist unbekannt, so dass der Code nicht validiert werden kann Bundle.entry[3].resource.ofType(Invoice).lineItem[0].chargeItem.ofType(CodeableConcept).coding[0] (l139/c15) | information | Code System URI "http://TA1.abda.de" ist unbekannt, so dass der Code nicht validiert werden kann Bundle.entry[3].resource.ofType(Invoice).lineItem[1].chargeItem.ofType(CodeableConcept).coding[0] (l264/c15) | information | Code System URI "http://fhir.de/CodeSystem/ifa/pzn" ist unbekannt, so dass der Code nicht validiert werden kann

`

[DarthGizka]

A priori ist das Enthaltensein des Sonderkennzeichens 09999643 ein Verstoß gegen Anhang 1 von TA1 (0 in E-Rezept-Spalte sowie - schwächeres Kriterium - Nichterwähnung in 4.9.2).

Es liegt keinerlei Verstoß gegen irgendwelche FHIR-Profile vor; für die Emission eines Fehlers gibt es nicht wirklich eine Grundlage.

Eine Grauzone ist, ob sich die Arbeitsgruppe die Verantwortung zur maschinellen Umsetzung von Freitextprosa aus den Profilen auf den Tisch ziehen will (im vorliegenden Fall: "8-stelliges Sonderkennzeichen aus der Technischen Anlage 1 zur Arzneimittelabrechnungsvereinbarung gemäß § 300 Absatz 3 SGB V oder aus einer anderen vertraglichen Vereinbarung. Das Sonderkennzeichen muss mit einer Preisangabe verknüpft sein."). Sowohl dafür als auch dagegen gibt es gute Gründe, die mal ausdiskutiert werden müßten.

Auf gar keinen Fall sollte sich die Arbeitsgruppe darauf einlassen, beliebige Kriterien aus TA1, TA3 oder sonstwelchen Quellen prüfen zu sollen, die nicht in den FHIR-Profilen definiert sind (entweder als Constraints oder als zum menschlichen Verzehr bestimmter Freitext; nicht funktionierende Constraints kann man der letzteren Kategorie zuschlagen).

Die maschinelle Erzeugung von ValueSets für die Sonderkennzeichen aus TA1 ist durchaus machbar. Allerdings steht hier weniger die Machbarkeit in Frage als die Sinnhaftigkeit.

P.S.: die praktische Komplexität der maschinellen Umsetzung der Regeln von TA1 ist schon an dem Disaster nach der Einführung von TA1/035 im Juli zu erkennen. Quasi alle Prüfstellen der Kassen außer Bitmarck - allen voran DAVASO und die AOKen - sind damit auf die Nase gefallen und haben massiv unberechtigte Datenablehnungen produziert. Selbst Monate später kam es dadurch noch zu Zahlungsverweigerungen und/oder verspäteten Zahlungen seitens der Kassen, in Millionenhöhe (insbesondere ARGE hatte wohl arge Probleme).

[magrimuc]

nicht im fhir profil, sondern fachlich definierter / festgelegter Fall