Metadaten des Datensatzes;@Datenannahmestelle:Wenn die Exportdatei valide ist nach +weicher Schemaprüfung UND+Ausführung der Prüfungen aus QSDOK.vPruefung mit dpp = false UND case_admin_persistieren = falsedann werden die Metadaten persistiert. Auch wenn ./case_admin/protocol/status_case/@V oder /root/header/protocol/status_document/@V gleich ERROR ist, ist die Persistierung der Metadaten notwendig. Ist die Exportdatei nach den zwei eben genannten Prüfschritten nicht valide, dann werden die Metadaten nicht persistiert.Im Unterschied zu den Metadaten sind die gelieferten Daten unter qs_data nur dann gültig, wenn status_document/@V nach allen Prüfschritten ungleich ERROR ist.(siehe Technische Dokumentation (TechDok) "Prozesse in den Datenannahmestellen")Sollte status_document/@V gleich ERROR sein, dann bleiben bereits gelieferte qs_data gültig. Chronologisch nachfolgende Lieferungen können nur dann gültig sein, wenn case/case_admin/version/@V höher ist als bereits gelieferte.Info intern: Im Rahmen der Strukturabfrage darf ein Leistungserbringer nur einen Vorgang pro Jahr liefern (Aktualisierungen eines Vorganges sind jedoch unbegrenzt möglich.). Es gibt daher nicht die Situation, dass in einer Exportdatei valide und invalide Datensätze sein können. Die Schemata erfordern/erlauben genau einen Datensatz pro Exportdatei.Daher gilt:Wenn status_case/@V gleich ERROR, dann ist status_document/@V gleich ERROR.siehe auch Dokumentation zu /root/body/data_container/cases/case/case_admin/protocol/status_case
<xs:element name="case_admin" type="case_admin_type" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Metadaten des Datensatzes; @Datenannahmestelle: Wenn die Exportdatei valide ist nach +weicher Schemaprüfung UND +Ausführung der Prüfungen aus QSDOK.vPruefung mit dpp = false UND case_admin_persistieren = false dann werden die Metadaten persistiert. Auch wenn ./case_admin/protocol/status_case/@V oder /root/header/protocol/status_document/@V gleich ERROR ist, ist die Persistierung der Metadaten notwendig. Ist die Exportdatei nach den zwei eben genannten Prüfschritten nicht valide, dann werden die Metadaten nicht persistiert. Im Unterschied zu den Metadaten sind die gelieferten Daten unter qs_data nur dann gültig, wenn status_document/@V nach allen Prüfschritten ungleich ERROR ist. (siehe Technische Dokumentation (TechDok) "Prozesse in den Datenannahmestellen") Sollte status_document/@V gleich ERROR sein, dann bleiben bereits gelieferte qs_data gültig. Chronologisch nachfolgende Lieferungen können nur dann gültig sein, wenn case/case_admin/version/@V höher ist als bereits gelieferte. Info intern: Im Rahmen der Strukturabfrage darf ein Leistungserbringer nur einen Vorgang pro Jahr liefern (Aktualisierungen eines Vorganges sind jedoch unbegrenzt möglich.). Es gibt daher nicht die Situation, dass in einer Exportdatei valide und invalide Datensätze sein können. Die Schemata erfordern/erlauben genau einen Datensatz pro Exportdatei. Daher gilt: Wenn status_case/@V gleich ERROR, dann ist status_document/@V gleich ERROR. siehe auch Dokumentation zu /root/body/data_container/cases/case/case_admin/protocol/status_case</xs:documentation></xs:annotation></xs:element>
qs_data ist optional, wenn parent::case/case_admin/action/@V gleich "delete" ist. Für Datenlieferungen mit "create" oder "update" in action/@V ist qs_data verpflichtend. Der Typ für das Element qs_data wird erst in der Exportdatei mit dem Attribut qs_data/@xsi:type definiert. Beispiel:<qs_data module="FFXE" xsi:type="qs_data_ffxe_type">Der Wert für xsi:type muss QSDOK.ExportModul.type_QS_data entsprechen.Navigationshilfe in der XML-Dokumentation:Link qs_data_type in Zeile Type, dann sind dort nach Click/Weiterleitung in Zeile Used by und Complex Types die Typen mit den entsprechenden Teildatensätzen aufgelistetDie Teildatensätze entsprechen QSDOK.ExportFormatExportModul.Bogen_name .
<xs:element name="qs_data" type="qs_data_type" minOccurs="0" maxOccurs="1"><xs:annotation><xs:documentation>qs_data ist optional, wenn parent::case/case_admin/action/@V gleich "delete" ist. Für Datenlieferungen mit "create" oder "update" in action/@V ist qs_data verpflichtend. Der Typ für das Element qs_data wird erst in der Exportdatei mit dem Attribut qs_data/@xsi:type definiert. Beispiel: <qs_data module="FFXE" xsi:type="qs_data_ffxe_type"> Der Wert für xsi:type muss QSDOK.ExportModul.type_QS_data entsprechen. Navigationshilfe in der XML-Dokumentation: Link qs_data_type in Zeile Type, dann sind dort nach Click/Weiterleitung in Zeile Used by und Complex Types die Typen mit den entsprechenden Teildatensätzen aufgelistet Die Teildatensätze entsprechen QSDOK.ExportFormatExportModul.Bogen_name .</xs:documentation></xs:annotation></xs:element>
<xs:complexType name="case_type"><xs:sequence><xs:element name="case_admin" type="case_admin_type" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Metadaten des Datensatzes; @Datenannahmestelle: Wenn die Exportdatei valide ist nach +weicher Schemaprüfung UND +Ausführung der Prüfungen aus QSDOK.vPruefung mit dpp = false UND case_admin_persistieren = false dann werden die Metadaten persistiert. Auch wenn ./case_admin/protocol/status_case/@V oder /root/header/protocol/status_document/@V gleich ERROR ist, ist die Persistierung der Metadaten notwendig. Ist die Exportdatei nach den zwei eben genannten Prüfschritten nicht valide, dann werden die Metadaten nicht persistiert. Im Unterschied zu den Metadaten sind die gelieferten Daten unter qs_data nur dann gültig, wenn status_document/@V nach allen Prüfschritten ungleich ERROR ist. (siehe Technische Dokumentation (TechDok) "Prozesse in den Datenannahmestellen") Sollte status_document/@V gleich ERROR sein, dann bleiben bereits gelieferte qs_data gültig. Chronologisch nachfolgende Lieferungen können nur dann gültig sein, wenn case/case_admin/version/@V höher ist als bereits gelieferte. Info intern: Im Rahmen der Strukturabfrage darf ein Leistungserbringer nur einen Vorgang pro Jahr liefern (Aktualisierungen eines Vorganges sind jedoch unbegrenzt möglich.). Es gibt daher nicht die Situation, dass in einer Exportdatei valide und invalide Datensätze sein können. Die Schemata erfordern/erlauben genau einen Datensatz pro Exportdatei. Daher gilt: Wenn status_case/@V gleich ERROR, dann ist status_document/@V gleich ERROR. siehe auch Dokumentation zu /root/body/data_container/cases/case/case_admin/protocol/status_case</xs:documentation></xs:annotation></xs:element><xs:element name="qs_data" type="qs_data_type" minOccurs="0" maxOccurs="1"><xs:annotation><xs:documentation>qs_data ist optional, wenn parent::case/case_admin/action/@V gleich "delete" ist. Für Datenlieferungen mit "create" oder "update" in action/@V ist qs_data verpflichtend. Der Typ für das Element qs_data wird erst in der Exportdatei mit dem Attribut qs_data/@xsi:type definiert. Beispiel: <qs_data module="FFXE" xsi:type="qs_data_ffxe_type"> Der Wert für xsi:type muss QSDOK.ExportModul.type_QS_data entsprechen. Navigationshilfe in der XML-Dokumentation: Link qs_data_type in Zeile Type, dann sind dort nach Click/Weiterleitung in Zeile Used by und Complex Types die Typen mit den entsprechenden Teildatensätzen aufgelistet Die Teildatensätze entsprechen QSDOK.ExportFormatExportModul.Bogen_name .</xs:documentation></xs:annotation></xs:element></xs:sequence></xs:complexType>