Metadaten des Datensatzes;@Datenannahmestelle:Wenn die Exportdatei valide ist nach +wohlgeformt UND schemakonform UND+Prüfungen aus QSDOK.vPruefung mit meta_DS = true nicht verletzt sind,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. 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 "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 @V.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.
<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 +wohlgeformt UND schemakonform UND +Prüfungen aus QSDOK.vPruefung mit meta_DS = true nicht verletzt sind, 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. 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 "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 @V. 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.</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 XML-Editoren wie Oxygen:Kindelemente unterQSFFx_XML-Schema\types\qs_data_typesExportmodul --- Einstiegspunkt: F_NW --- qs_data_fnw_type F_SA --- qs_data_fsa_type F_SA23 --- qs_data_fsa23_type FFXE --- qs_data_ffxe_type (Quelle: QSDOK.ExportModul.type_QS_data)Navigationshilfe in der XML-Dokumentation (HTML-Ansicht):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 XML-Editoren wie Oxygen: Kindelemente unter QSFFx_XML-Schema\types\qs_data_types Exportmodul --- Einstiegspunkt: F_NW --- qs_data_fnw_type F_SA --- qs_data_fsa_type F_SA23 --- qs_data_fsa23_type FFXE --- qs_data_ffxe_type (Quelle: QSDOK.ExportModul.type_QS_data) Navigationshilfe in der XML-Dokumentation (HTML-Ansicht): 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 +wohlgeformt UND schemakonform UND +Prüfungen aus QSDOK.vPruefung mit meta_DS = true nicht verletzt sind, 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. 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 "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 @V. 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.</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 XML-Editoren wie Oxygen: Kindelemente unter QSFFx_XML-Schema\types\qs_data_types Exportmodul --- Einstiegspunkt: F_NW --- qs_data_fnw_type F_SA --- qs_data_fsa_type F_SA23 --- qs_data_fsa23_type FFXE --- qs_data_ffxe_type (Quelle: QSDOK.ExportModul.type_QS_data) Navigationshilfe in der XML-Dokumentation (HTML-Ansicht): 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>