C_12506_Anlage_V1.0.0
Prereleases:
C_12506_Anlage
Inhaltsverzeichnis
1 Änderungsbeschreibung
Clients können Fehlermeldungen nur dann verarbeiten und nutzerverständliche Fehlermeldungen erzeugen, wenn die Fehlerinhalte verarbeitet werden können. Das wird erheblich vereinfacht, wenn die Fehlermeldungen in allen Aktensystemen hinsichtlich Struktur und Inhalt einheitlich sind. Diese Vereinfachung soll die Entwicklung und den Produktivbetrieb von Primärsystemen erleichtern.
Aus der Fehlermeldung soll hervorgehen welches Dokument den Fehler verursacht hat.
Bei einer konkreten Fehlerprüfung sollen alle Dokumente des SubmissionSet auf diesen Fehler geprüft werden, ohne nach dem ersten Auftreten des Fehlers abzubrechen. Es soll die Möglichkeit geben, dass weitere Informationen zu diesem Fehler zurückgegeben werden.
Es wird geregelt, wie im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements die Informationen zum Fehler angegeben werden.
2 Änderung in gemSpec_Aktensystem_ePAfuerAlle
Neue Anforderung:
A_28657 - XDS Document Service – Fehlerprüfung für alle im Request enthaltenen Dokumente
Der XDS Document Service MUSS alle im SubmissionSet enthaltenen Dokumente in eine konkrete Fehlerprüfung einbeziehen ohne nach dem erstem Fehler abzubrechen. Die RegistryErrorList MUSS jeweils einen RegistryError für jedes zu diesem Fehler erkannte Dokument enthalten, wobei der Inhalt des RegistryError den Vorgaben für diesen Fehler entsprechen muss. [<=]
Hinweis:
Die Anforderung bezieht sich auf eine konkrete Fehlerprüfung. Ziel ist es nicht, alle Ergebnisse aller Fehlerprüfungen in der Response zu übermitteln.
Es gibt normative Vorgaben, die fordern, dass im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements die uniqueID des Dokuments, welches den Fehler verursacht zurückgegeben wird.
Es wird festgelegt, dass im Fehlerfall immer, wenn möglich, die uniqueID zurückgegeben wird und mit welcher Syntax das erfolgt.
Neue Anforderung:
A_28654 - XDS Document Service – Fehler mit uniqueId in codeContext
Falls im XDS Document Service ein IHE-Fehler auftritt, der sich auf ein SubmissionSet, DocumentEntry oder Folder zurückführen lässt, und dessen uniqueId bekannt ist und für den Fehler keine spezifischere Fehlerregelung vorgegeben ist, MUSS in codeContext die entsprechende uniqueId wie folgt enthalten sein: "uniqueId='<DocumentEntry.uniqueId>'". [<=]
Beispiel:
codeContext = "uniqueId='2.25.269167723254896828623'"
Hinweis:
Der Fehler, dass die Telematik-ID nicht zur Session passt (A_24497*), erfolgt ohne Angabe der uniqueId.
Es wird festgelegt wie die Informationen zum Fehler im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements aufgenommen werden.
Neue Anforderung:
A_28655 - XDS Document Service – Formatvorgaben für CodeContext
Der XDS Document Service MUSS Key-Value Paare in codeContext nach folgenden Regeln behandeln:
- Key-Value Paare sind mit <key>=<value> gekennzeichnet,
- Die Reihenfolge der Key-Value Paare ist nicht vorgegeben,
- Trennung von Key-Value Paaren erfolgt mit ‘;’ ,
- <key> wird normativ vorgegeben und kann gegebenenfalls mehrfach auftreten,
- ein identisches Key-Value Paar kann in einem codeContext nur einmal auftreten,
Für <value> gilt: - value wird immer durch Hochkommata ("'") umschlossen, z.B.: errorText='RootDocumentUniqueId must not be changed'
- Escape von einfachen Anführungszeichen (‘) erfolgt mit "\‘",
- Escape von Backslash (\) erfolgt mit "\\",
- Maximale Anzahl von Zeichen: 1000 (Single Quotes als Beginn und Endezeichen zählen mit),
- White spaces sind außerhalb von <value> nicht erlaubt.
Es soll die Möglichkeit geben, dass über die normativen Forderungen hinaus weiter Informationen zum Fehler zurückgegeben werden können.
Neue Anforderung:
A_28656 - XDS Document Service – Format für Fehlerdetail
Der XDS Document Service KANN bei einem IHE-Fehler weitere Informationen zur Fehleranalyse im codeContext des Fehlers als <key>=<value>-Paar einfügen, ausschließlich mit:
- errorDetail='<Details zum Fehler>'
- <Details zum Fehler>='<weiterführende Informationen zum Fehler>'
In der Produktivumgebung gilt: Es dürfen keine personenbezogenen Daten, medizinische Daten, Error Stack Traces oder die Offenbarung von Programmierdetails enthalten sein.
Prüfverfahren: Sich.techn. Eignung: Produktgutachten
Beispiel:
ErrorCode=InvalidDocumentContent
codeContext="uniqueId='2.25.269167723254896828623';errorDetail='Fehlerhafter Aufrufparameter [PDF service encountered an unacceptable document format for validatePDF'"
Die folgenden Anforderungen werden entsprechend der Forderung zu "XDS Document Service – Formatvorgaben für CodeContext" angepasst:
Alt:
A_24451-01 - XDS Document Service - Automatisches initiales Erzeugen einer versionsübergreifenden ID für Dokumente
Der XDS Document Service MUSS beim initialen Einstellen eines Dokumentes die DocumentEntry.uniqueId als Eintrag einer ReferenceID in die ReferenceIDList in folgendem Format einstellen:
<DocumentEntry.uniqueId>^^^^urn:gematik:iti:xds:2023:rootDocumentUniqueId
Beim Upload einer neuen Version des Dokumentes DARF dieser Eintrag in der ReferenceIDList, d.h. die rootDocumentUniqueId, NICHT verändert werden. Er bleibt über alle Versionen des Dokumentes hinweg unverändert erhalten. Der Versuch eines Clients, die rootDocumentUniqueId durch ein Metadata-Update oder im Zuge des Einstellens einer neuen Dokumentenversion zu verändern, MUSS mit einem IHE-Error XDSRegistryMetadataError abgebrochen werden. Es MUSS im codeContext-Attribut des zurückgegebenen XDSRegistryMetadataError-Elements der Text „rootDocumentUniqueId must not be changed“ zurückgegeben werden. [<=]
Neu:
A_24451-02 - XDS Document Service - Automatisches initiales Erzeugen einer versionsübergreifenden ID für Dokumente
Der XDS Document Service MUSS beim initialen Einstellen eines Dokumentes die DocumentEntry.uniqueId als Eintrag einer ReferenceID in die ReferenceIDList in folgendem Format einstellen:
<DocumentEntry.uniqueId>^^^^urn:gematik:iti:xds:2023:rootDocumentUniqueId
Beim Upload einer neuen Version des Dokumentes DARF dieser Eintrag in der ReferenceIdList, d.h. die rootDocumentUniqueId, NICHT verändert werden. Er bleibt über alle Versionen des Dokumentes hinweg unverändert erhalten. Der Versuch eines Clients, die rootDocumentUniqueId durch ein Metadata-Update oder im Zuge des Einstellens einer neuen Dokumentenversion zu verändern, MUSS mit einem IHE-Error XDSRegistryMetadataError abgebrochen werden. Es MUSS im codeContext-Attribut des zurückgegebenen XDSRegistryMetadataError-Elements der Text "errorText='Cannot register document: RootDocumentUniqueId must not be changed'" zurückgegeben werden. [<=]
Alt:
A_14938-02 - XDS Document Service – Validierung der Metadaten aus ITI Document Sharing-Profilen
Der XDS Document Service MUSS die SubmissionSet- sowie die DocumentEntry-Metadaten der eingehenden Nachricht vor einer Zugriffskontrolle gemäß Konformität zu den Nutzungsvorgaben in [A_14760-*] prüfen. Der XDS Document Service MUSS das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem XDSRepositoryMetadataError quittieren, sofern die Metadaten nicht konform zu den Nutzungsvorgaben sind. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements angegeben werden, welches Metadatenattribut nicht den Nutzungsvorgaben entspricht. [<=]
Neu:
A_14938-04 - XDS Document Service – Validierung der Metadaten aus ITI Document Sharing-Profilen
Der XDS Document Service MUSS die SubmissionSet- sowie die DocumentEntry-Metadaten der eingehenden Nachricht vor einer Zugriffskontrolle gemäß Konformität zu den Nutzungsvorgaben in [A_14760-*] prüfen. Der XDS Document Service MUSS das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem XDSRepositoryMetadataError quittieren, sofern die Metadaten nicht konform zu den Nutzungsvorgaben sind. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Text "errorText='Cannot register document: Metadata do not match A_14760'" und wie folgt angegeben werden, welche Metadatenattribute nicht den Nutzungsvorgaben entsprechen:
"metadata=<Name Metadatum_1>;metadata=<Name Metadatum_2>;...;metadata=<Name Metadatum_n>"
[<=]
Hinweis:
uniqueId kann auch auf ein SubmissionSet zeigen. In diesem Fall entsprechen die Metadatenattribute des SubmissionSet nicht den Nutzungsvorgaben.
Beispiel:
codeContext = "uniqueId='2.25.269167723254896828623';metadata='authorPerson';metadata='authorRole';errorText='Cannot register document: Metadata do not match A_14760'"
Alt:
A_24988-02 - XDS Document Service - Dublettenprüfung für Dokumente
Der XDS Document Service MUSS beim Einstellen von Dokumenten in die Akte für jedes Dokument den hash-Wert vergleichen mit allen bereits in dieser Akte existierenden hash-Werten der Dokumente und bei einer Übereinstimmung das Einstellen mit dem Fehlercode XDSDuplicateDocument ablehnen, sofern nicht der Parameter "EnableDocumentReuse=true" (siehe A_27700) verwendet wird.
Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements die Liste der UUIDs (DocumentEntry.entryUUID) der identifizierten Dokumente angegeben werden. [<=]
Neu:
A_24988-03 - XDS Document Service - Dublettenprüfung für Dokumente
Der XDS Document Service MUSS beim Einstellen von Dokumenten in die Akte für jedes Dokument den hash-Wert vergleichen mit allen bereits in dieser Akte existierenden hash-Werten der Dokumente und bei einer Übereinstimmung das Einstellen mit dem Fehlercode XDSDuplicateDocument ablehnen, sofern nicht der Parameter "EnableDocumentReuse=true" (siehe A_27700*) verwendet wird.
Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Text "errorText='Cannot register document: Duplicate already exists'" die Liste der UUIDs (DocumentEntry.entryUUID), der in der Akte identifizierten Dokumente, wie folgt angegeben werden:
"entryUUID=<entryUUID von document_1>;entryUUID=<entryUUID von document_2>;...;entryUUID=<entryUUID von document_n>"
<=
[<=]
Alt:
A_23098-01 - XDS Document Service – Keine Registrierung bei zeitlicher Ungültigkeit von strukturierten Dokumenten
Der XDS Document Service MUSS beim Einstellen eines strukturierten Dokuments sicherstellen, dass die Vorgaben gemäß [gemSpec_IG_ePA] hinsichtlich der zeitlichen Gültigkeit erfüllt werden und andernfalls das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem XDSRepositoryMetadataError quittieren. Es MUSS im codeContext-Attribut des zurückgegebenen XDSRepositoryMetadataError-Elements der Text „Version of submitted structured document is not supported“ zurückgegeben werden. [<=]
Neu:
A_23098-03 - XDS Document Service – Keine Registrierung bei zeitlicher Ungültigkeit von strukturierten Dokumenten
Der XDS Document Service MUSS beim Einstellen eines strukturierten Dokuments sicherstellen, dass die Vorgaben gemäß [gemSpec_IG_ePA] hinsichtlich der zeitlichen Gültigkeit erfüllt werden und andernfalls das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem XDSRepositoryMetadataError quittieren. Es MUSS im codeContext-Attribut des zurückgegebenen XDSRepositoryMetadataError-Elements der Text "errorText='Cannot register document: Version of submitted structured document is not supported'" zurückgegeben werden. [<=]
Beispiel:
codeContext = "uniqueId='2.25.269167723254896828623';errorText='Cannot register document: Version of submitted structured document is not supported'"
Alt:
A_15082-02 - XDS Document Service – Validierung der Metadaten aus ITI Document Sharing-Profilen
Der XDS Document Service MUSS die übermittelten DocumentEntry-Metadaten der Operation RestrictedUpdateDocumentSet dahingehend prüfen, dass gegenüber den Bestandsdaten die geänderten Metadaten konform zu den Nutzungsvorgaben in [A_14760-*] geändert werden. Der XDS Document Service MUSS das Aktualisieren der Metadatenattribute ablehnen und mit einem XDSRepositoryMetadataError quittieren, sofern die Metadaten nicht konform zu den Nutzungsvorgaben sind. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements angegeben werden, welches Metadatenattribut nicht den Nutzungsvorgaben entspricht. [<=]
Neu:
A_15082-04 - XDS Document Service – Validierung der Metadaten aus ITI Document Sharing-Profilen
Der XDS Document Service MUSS die übermittelten DocumentEntry-Metadaten der Operation RestrictedUpdateDocumentSet dahingehend prüfen, dass gegenüber den Bestandsdaten die geänderten Metadaten konform zu den Nutzungsvorgaben in [A_14760-*] geändert werden. Der XDS Document Service MUSS das Aktualisieren der Metadatenattribute ablehnen und mit einem XDSRepositoryMetadataError quittieren, sofern die Metadaten nicht konform zu den Nutzungsvorgaben sind. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Text "errorText='Cannot update metadata: Metadata not match A_14760'" und wie folgt angegeben werden, welche Metadatenattribute nicht den Nutzungsvorgaben entsprechen:
"metadata=<Name Metadatum_1>;metadata=<Name Metadatum_2>;...;metadata=<Name Metadatum_n>"
[<=]
Alt:
A_25173 - XDS Document Service - Restricted Update Document Set nicht für MIOs
Falls die Operation RestrictedUpdateDocumentSet für Dokumente einer mixed- oder uniform-Sammlung aufgerufen wird MUSS der XDS Document Service das Aktualisieren der Metadatenattribute ablehnen, mit einem XDSRepositoryMetadataError quittieren und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den Text "Metadata Update for MIOs not allowed" angeben.
[<=]
Neu:
A_25173-01 - XDS Document Service - Restricted Update Document Set nicht für MIOs
Falls die Operation RestrictedUpdateDocumentSet für Dokumente einer mixed- oder uniform-Sammlung aufgerufen wird MUSS der XDS Document Service das Aktualisieren der Metadatenattribute ablehnen, mit einem XDSRepositoryMetadataError quittieren und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den Text "errorText='Cannot update metadata: Update for MIOs not allowed'" angeben.
[<=]
Alt:
A_24456 - XDS Document Service - Durchsetzung von Uniqueness beim Einstellen von Notfalldaten
Der XDS Document Service MUSS beim Einstellen eines Dokumentes der Kategorien "emergency" sicherstellen, dass es innerhalb des entsprechenden Ordners nur ein einzelnes NFD- und ein einzelnes DPE-Dokument im Status "approved" gibt. Der Versuch, innerhalb dieses Ordners ein zweites NDF- oder DPE-Dokument einzustellen, MUSS mit dem IHE-Error InvalidDocumentContent abgebrochen werden. Es MUSS im codeContext-Attribut des zurückgegebenen InvalidDocumentContent-Elements der Text "Medical information object has to be unique" zurückgegeben werden. [<=]
Neu:
A_24456-01 - XDS Document Service - Durchsetzung von Uniqueness beim Einstellen von Notfalldaten
Der XDS Document Service MUSS beim Einstellen eines Dokumentes der Kategorien "emergency" sicherstellen, dass es innerhalb des entsprechenden Ordners nur ein einzelnes NFD- und ein einzelnes DPE-Dokument im Status "approved" gibt. Der Versuch, innerhalb dieses Ordners ein zweites NDF- oder DPE-Dokument einzustellen, MUSS mit dem IHE-Error InvalidDocumentContent abgebrochen werden. Es MUSS im codeContext-Attribut des zurückgegebenen InvalidDocumentContent-Elements der Text "errorText='Cannot register document: Medical information object has to be unique'" zurückgegeben werden. [<=]
Alt:
A_21817-02 - XDS Document Service – Löschen von strukturierten Dokumenten durch ein Primärsystem
Der XDS Document Service MUSS Löschanfragen eines dynamischen Ordners durch ein Primärsystem ablehnen, wenn zugehörige Submission Sets, Associations oder zugeordnete Dokumente in der Löschanfrage enthalten sind. Das Löschen dieses Ordners impliziert aktensystemseitig immer das Löschen zugehöriger SubmissionSets, Associations sowie zugeordneter Dokumente. Liegt eine Verletzung der Löschvorgaben vor, MUSS die Nachricht mit XDSRegistryError-Fehlercode zurückgeben werden. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Wert "Anfragenachricht darf ausschließlich entryUUID für Folder beinhalten" belegt werden. [<=]
Neu:
A_21817-03 - XDS Document Service – Löschen von strukturierten Dokumenten durch ein Primärsystem
Der XDS Document Service MUSS Löschanfragen eines dynamischen Ordners durch ein Primärsystem ablehnen, wenn zugehörige Submission Sets, Associations oder zugeordnete Dokumente in der Löschanfrage enthalten sind. Das Löschen dieses Ordners impliziert aktensystemseitig immer das Löschen zugehöriger SubmissionSets, Associations sowie zugeordneter Dokumente. Liegt eine Verletzung der Löschvorgaben vor, MUSS die Nachricht mit XDSRegistryError-Fehlercode zurückgeben werden. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements enthalten sein:
- errorText='Cannot delete structured document: Only entryUUID of dynamic folder is allowed; do not use contained elements'
- entryUUID='<entryUUID des dynamischen Folder, der nicht gelöscht werden kann>'
- Liste der, den Fehler verursachenden Dokumente mit jeweils:
offendingEntryUUID='<entryUUID des Dokuments welches den Fehler verursacht>'
Beispiel:
errorCode = XDSRegistryError
codeContext = "entryUUID='2.25.514739840497321348259';offendingEntryUUID=’2.25.269167723254896828623’;offendingEntryUUID=’2.25.269167723254896828623’;errorText='Cannot delete structured document: Only entryUUID of dynamic folder is allowed; do not use contained elements'"
Alt:
A_24509 - XDS Document Service - Prüfung der Legal Policy außer Suchanfragen
Der XDS Document Service MUSS die Ausführung einer Operation mit dem Fehlercode LegalPolicyViolation beenden, wenn für den angemeldeten Nutzer die Regeln der Legal Policy nicht erfüllt sind und es sich nicht um eine Suchanfrage handelt.
Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements die Liste der UUIDs (DocumentEntry.entryUUID) der identifizierten Dokumente angegeben werden. [<=]
Neu:
A_24509-01 - XDS Document Service - Prüfung der Legal Policy außer Suchanfragen
Der XDS Document Service MUSS die Ausführung einer Operation mit dem Fehlercode LegalPolicyViolation beenden, wenn für den angemeldeten Nutzer die Regeln der Legal Policy nicht erfüllt sind und es sich nicht um eine Suchanfrage handelt.
Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Fehlertext "errorText='Legal Policy violation'" angegeben werden. [<=]
Alt:
A_28142 - XDS Document Service – Fehler Verwendung von Codes im Status inactive
Der XDS Document Service MUSS das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit dem Fehler XDSInactiveCode quittieren, falls ein Metadatum Code den Status "inactive" besitzt. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements angegeben werden, welcher Code nicht mehr unterstützt wird (im Format "codeSystem|code" bzw. ggf. mit Version gemäß A_27759).
Es gibt zwei Ausnahmen: Beim Aktualisieren eines bestehende Codes mittels RMU-Operation oder beim Ersetzen eines Dokuments in der RPLC-Kette wird ein Code im Status "inactive" akzeptiert, sofern er bereits auch an dieser Stelle im zu aktualisierenden/ersetzenden Objekt vorhanden ist. In diesen beiden Fällen MUSS der XDS Document Service den Code ohne Fehler verarbeiten können. [<=]
Neu:
A_28142-01 - XDS Document Service – Fehler Verwendung von Codes im Status inactive
Der XDS Document Service MUSS das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit dem Fehler XDSInactiveCode quittieren, falls ein Metadatum Code den Status "inactive" besitzt. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Text "errorText='Cannot update metadata: Code is inactive'" angegeben werden und welche der Codes nicht mehr unterstützt werden (im Format "code^^codeSystem" bzw. ggf. mit Version gemäß A_27759 "code^^codeSystem|version"):
"code=<code_1^^codeSystem_1>;code=<code_2^^codeSystem_2>;...;code=<code_n^^codeSystem_n>"
Es gibt zwei Ausnahmen: Beim Aktualisieren eines bestehende Codes mittels RMU-Operation oder beim Ersetzen eines Dokuments in der RPLC-Kette wird ein Code im Status "inactive" akzeptiert, sofern er bereits auch an dieser Stelle im zu aktualisierenden/ersetzenden Objekt vorhanden ist. In diesen beiden Fällen MUSS der XDS Document Service den Code ohne Fehler verarbeiten können. [<=]
Alt:
A_24497 - XDS Document Service - Verwendung der korrekten Telematik-ID beim Einstellen
Der XDS Document Service MUSS die Telematik-ID aus dem ID-Token der aktuellen User Session abgleichen mit der Telematik-ID aus SubmissionSet.authorInstitution und das Abweichen der Telematik-Ids mit einem XDSRepositoryMetadataError-Fehlercode quittieren und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den Text "Telematik-ID does not match" angeben. [<=]
Neu:
A_24497-01 - XDS Document Service - Verwendung der korrekten Telematik-ID beim Einstellen
Der XDS Document Service MUSS die Telematik-ID aus dem ID-Token der aktuellen User Session abgleichen mit der Telematik-ID aus SubmissionSet.authorInstitution und das Abweichen der Telematik-Ids mit einem XDSRepositoryMetadataError-Fehlercode quittieren und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den Text "errorText='Telematik-ID does not match'" angeben. [<=]
Alt:
A_24797-04 - XDS Document Service - Ablehnung Upload bei veränderten Metadaten bei einer RPLC Assoziation
Der XDS Document Service MUSS Uploads, die als Resultat ein zum Vorgängerdokument verändertes Metadatum enthalten, mit einem XDSRegistryMetadataError ablehnen.
Einzige Ausnahmen sind:
- Metadatenattribute creationTime, entryUUID sowie uniqueId und confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491).
- Das Metadatenattribut DocumentEntry.referenceIdList DARF ohne die rootDocumentUniqueId gesendet werden; in dem Fall wird die rootDocumentUniqueId automatisch vom XDS Document Service gesetzt (Wert identisch zu dem des ersetzten Dokuments).
Neu:
A_24797-05 - XDS Document Service - Ablehnung Upload bei veränderten Metadaten bei einer RPLC Assoziation
Der XDS Document Service MUSS Uploads, die als Resultat ein zum Vorgängerdokument verändertes Metadatum enthalten, mit einem XDSRegistryMetadataError ablehnen. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements wie folgt angegeben werden, welche Metadatenattribute nicht den Nutzungsvorgaben entsprechen:
"errorText='Cannot register document: Change of metadata not allowed';metadata=<Name Metadatum_1>;metadata=<Name Metadatum_2>;...;metadata=<Name Metadatum_n>"
Einzige Ausnahmen sind:
- Metadatenattribute creationTime, entryUUID sowie uniqueId und confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491).
- Das Metadatenattribut DocumentEntry.referenceIdList DARF ohne die rootDocumentUniqueId gesendet werden; in dem Fall wird die rootDocumentUniqueId automatisch vom XDS Document Service gesetzt (Wert identisch zu dem des ersetzten Dokuments).
Alt:
A_15083-09 - XDS Document Service – Prüfung auf ausschließliche Aktualisierung der erlaubten Metadaten
Der XDS Document Service MUSS die übermittelten DocumentEntry-Metadaten der Operation RestrictedUpdateDocumentSet dahingehend prüfen, dass gegenüber den Bestandsdaten ausschließlich die folgenden Metadaten geändert werden:
- DocumentEntry.author
- DocumentEntry.classCode
- DocumentEntry.comments
- DocumentEntry.confidentialityCode (confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491) ist nicht erlaubt)
- DocumentEntry.creationTime
- DocumentEntry.eventCodeList
- DocumentEntry.formatCode
- DocumentEntry.healthcareFacilityTypeCode
- DocumentEntry.languageCode
- DocumentEntry.legalAuthenticator
- DocumentEntry.practiceSettingCode
- DocumentEntry.referenceIdList
- DocumentEntry.serviceStartTime
- DocumentEntry.serviceStopTime
- DocumentEntry.title
- DocumentEntry.typeCode
- DocumentEntry.URI
Werden unerlaubte Metadatenänderungen geschickt, muss die Operation mit einem LocalPolicyRestrictionError-Fehlercode abgebrochen werden. Werden Metadatenattribute mit leeren Werten übermittelt, signalisiert dies ein Löschen des Metadatums (z.B. DocumentEntry.comments). Es müssen die Kardinalitäten in A_14760-* berücksichtigt bzw. dürfen nicht verletzt werden (Ausnahme für Altdaten: eventCodeList darf mehr als einen DMP- oder KDL-Code in der eventCodeList enthalten, wenn der alte Metadatensatz bereits dieselben DMP- und KDL-Codes führt). Das Metadatum DocumentEntry.referenceIdList MUSS dabei mindestens die rootDocumentUniqueId enthalten.
Wenn in der Eingangsnachricht keine Aktualisierung für die erlaubten Metadaten enthalten ist, ist die Weiterverarbeitung abzubrechen und die Nachricht mit einem LocalPolicyRestrictionError-Fehlercode zu quittieren. [<=]
Neu:
A_15083-11 - XDS Document Service – Prüfung auf ausschließliche Aktualisierung der erlaubten Metadaten
Der XDS Document Service MUSS die übermittelten DocumentEntry-Metadaten der Operation RestrictedUpdateDocumentSet dahingehend prüfen, dass gegenüber den Bestandsdaten ausschließlich die folgenden Metadaten geändert werden:
- DocumentEntry.author
- DocumentEntry.classCode
- DocumentEntry.comments
- DocumentEntry.confidentialityCode (confidentialityCode = "CON" (codeSystem = urn:oid:1.2.276.0.76.5.491) ist nicht erlaubt)
- DocumentEntry.creationTime
- DocumentEntry.eventCodeList
- DocumentEntry.formatCode
- DocumentEntry.healthcareFacilityTypeCode
- DocumentEntry.languageCode
- DocumentEntry.legalAuthenticator
- DocumentEntry.practiceSettingCode
- DocumentEntry.referenceIdList
- DocumentEntry.serviceStartTime
- DocumentEntry.serviceStopTime
- DocumentEntry.title
- DocumentEntry.typeCode
- DocumentEntry.URI
Werden unerlaubte Metadatenänderungen geschickt, muss die Operation mit einem LocalPolicyRestrictionError-Fehlercode abgebrochen werden. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements wie folgt angegeben werden, welche Metadatenattribute nicht geändert werden dürfen:
"errorText='Cannot update metadata: Metadata is not permitted';metadata=<Name Metadatum_1>;metadata=<Name Metadatum_2>;...;metadata=<Name Metadatum_n>"
Werden Metadatenattribute mit leeren Werten übermittelt, signalisiert dies ein Löschen des Metadatums (z.B. DocumentEntry.comments). Es müssen die Kardinalitäten in A_14760-* berücksichtigt bzw. dürfen nicht verletzt werden (Ausnahme für Altdaten: eventCodeList darf mehr als einen DMP- oder KDL-Code in der eventCodeList enthalten, wenn der alte Metadatensatz bereits dieselben DMP- und KDL-Codes führt). Das Metadatum DocumentEntry.referenceIdList MUSS dabei mindestens die rootDocumentUniqueId enthalten.
Wenn in der Eingangsnachricht keine Aktualisierung für die erlaubten Metadaten enthalten ist, ist die Weiterverarbeitung abzubrechen und die Nachricht mit einem LocalPolicyRestrictionError-Fehlercode zu quittieren. [<=]
Alt:
A_26324-03 - XDS Document Service - Aktenkonto im Umzug oder im Wartungsmodus
Falls sich ein Aktenkonto im Zustand SUSPENDED oder im Status INACCESSIBLE befindet MUSS der XDS Document Service die Verarbeitung ablehnen und mit einem StatusMismatch-Fehlercode gemäß [IHE-ITI-TF3#4.2.4] quittieren und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den passenden Fehlertext angeben:
Tabelle 1 : Fehlertexte zu StatusMismatch-Fehlercode
| Aktenkontostatus | Wert für codeContext in rs:RegistryError |
|---|---|
| SUSPENDED | "Health Record Relocation in progress" |
| INACCESSIBLE | "Health Record is inaccessible" |
Neu:
A_26324-04 - XDS Document Service - Aktenkonto im Umzug oder im Wartungsmodus
Falls sich ein Aktenkonto im Zustand SUSPENDED oder im Status INACCESSIBLE befindet MUSS der XDS Document Service die Verarbeitung ablehnen und mit einem StatusMismatch-Fehlercode gemäß [IHE-ITI-TF3#4.2.4] quittieren und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den passenden Fehlertext mit "errorText=<Fehlertext>" angeben:
Tabelle 2 : Fehlertexte zu StatusMismatch-Fehlercode
| Aktenkontostatus | Wert für <Fehlertext> in codeContext |
|---|---|
| SUSPENDED | 'Health Record Relocation in progress' |
| INACCESSIBLE | 'Health Record is inaccessible' |
Alt:
A_27700 - XDS Document Service - Option zum Akzeptieren von Duplikaten
Der XDS Document Service MUSS in der Lage sein Duplikate, das heißt Dokumente, bei dem der DocumentEntry.hash eines einzustellenden Dokuments identisch ist mit einem existierenden Dokument, ohne Fehler zu akzeptieren, wenn
die Anfrage in der <RequestSlotList> den folgenden Parameter enthält
<Slot name="urn:gematik:iti:xds:EnableDocumentReuse">
<ValueList>
<Value>true</Value>
</ValueList>
</Slot>
und wenn
- die Anfrage auch erfolgreich wäre, wenn die Dokumente noch nicht vorhanden wären,
- das bestehende Dokument in derselben Kategorie existiert, in die auch das neue einsortiert würde,
- das bestehende Dokumente sichtbar ist für das einstellende System,
- das Einstellen einer etwaigen Anhangsbeziehung nicht die Anforderungen an Anhänge verletzt (etwa durch Überschreiten der maximalen Länge von Anhangsketten durch das Hinzufügen des Dokuments als Anhang oder Hauptdokument).
Wird der SubmissionRequest gemäß der obigen Bedingungen akzeptiert, MUSS der XDS Document Service
- Anhangsbeziehungen, die noch nicht in den Metadaten des bestehenden Dokuments vorhanden sind, dort und in der Gegenreferenz im referenzierten Dokument nachtragen (bestehende Anhangsbeziehungen werden davon nicht berührt),
- das Dokument und den DocumentEntry aus der Anfrage verwerfen und stattdessen das bestehende Dokument weiter verwenden (ohne die Metadaten des bestehenden Dokuments zu verändern),
- den dazugehörigen einzustellenden DocumentEntry und die Association, die ihn mit dem mitgelieferten SubmissionSet verbindet, aus dem mitgelieferten SubmissionSet entfernen,
- das SubmissionSet selbst verwerfen, sofern keine Associations, DocumentEntries oder Folders neu gespeichert werden (es also im Endeffekt "leer" wäre),
- die Antwort (mit dem üblichen Status "Success") in der <RegistryResponse> um folgende <ResponseSlotList> ergänzen (mit einem Slot für jedes vorhandene Dokument):
<ResponseSlotList>
<Slot name="urn:gematik:iti:xds:ReusedDocumentMapping">
<ValueList>
<Value>$uniqueId_neu|$uniqueId_alt</Value>
</ValueList>
</Slot>
</ResponseSlotList>
wobei $uniqueId_neu die DocumentEntry.uniqueId des Dokuments aus dem SubmissionRequest ist, während $uniqueId_alt die DocumentEntry.uniqueId des bestehenden Dokuments darstellt.
- mit dem Fehler XDSRegistryMetadataError antworten, wenn die Kategorie des neuen Dokuments abweicht,
- mit dem Fehler XDSInvalidRequest antworten, wenn der Parameter "EnableDocumentReuse" mit einem anderen Wert als "true" verwendet wird,
- ansonsten mit dem üblichen Fehler antworten, der auch sonst beim Einstellen der Anfrage (d.h. ohne EnableDocumentReuse) zurückgegeben würde.
Neu:
(Hinweis: diese Anforderung wird gemerged mit dem Ausbau des neuen Features für Anhänge aus der 3.1.3. Als Ergebnis dieses Merge wird es A_27700-02 geben, mit der hier aufgeführten Änderung.
A_27700-01 - XDS Document Service - Option zum Akzeptieren von Duplikaten
Der XDS Document Service MUSS in der Lage sein Duplikate, das heißt Dokumente, bei dem der DocumentEntry.hash eines einzustellenden Dokuments identisch ist mit einem existierenden Dokument, ohne Fehler zu akzeptieren, wenn
die Anfrage in der <RequestSlotList> den folgenden Parameter enthält
<Slot name="urn:gematik:iti:xds:EnableDocumentReuse">
<ValueList>
<Value>true</Value>
</ValueList>
</Slot>
und wenn
- die Anfrage auch erfolgreich wäre, wenn die Dokumente noch nicht vorhanden wären,
- das bestehende Dokument in derselben Kategorie existiert, in die auch das neue einsortiert würde,
- das bestehende Dokumente sichtbar ist für das einstellende System,
- das Einstellen einer etwaigen Anhangsbeziehung nicht die Anforderungen an Anhänge verletzt (etwa durch Überschreiten der maximalen Länge von Anhangsketten durch das Hinzufügen des Dokuments als Anhang oder Hauptdokument).
Wird der SubmissionRequest gemäß der obigen Bedingungen akzeptiert, MUSS der XDS Document Service
- Anhangsbeziehungen, die noch nicht in den Metadaten des bestehenden Dokuments vorhanden sind, dort und in der Gegenreferenz im referenzierten Dokument nachtragen (bestehende Anhangsbeziehungen werden davon nicht berührt),
- das Dokument und den DocumentEntry aus der Anfrage verwerfen und stattdessen das bestehende Dokument weiter verwenden (ohne die Metadaten des bestehenden Dokuments zu verändern),
- den dazugehörigen einzustellenden DocumentEntry und die Association, die ihn mit dem mitgelieferten SubmissionSet verbindet, aus dem mitgelieferten SubmissionSet entfernen,
- das SubmissionSet selbst verwerfen, sofern keine Associations, DocumentEntries oder Folders neu gespeichert werden (es also im Endeffekt "leer" wäre),
- die Antwort (mit dem üblichen Status "Success") in der <RegistryResponse> um folgende <ResponseSlotList> ergänzen (mit einem Slot für jedes vorhandene Dokument):
<ResponseSlotList>
<Slot name="urn:gematik:iti:xds:ReusedDocumentMapping">
<ValueList>
<Value>$uniqueId_neu|$uniqueId_alt</Value>
</ValueList>
</Slot>
</ResponseSlotList>
wobei $uniqueId_neu die DocumentEntry.uniqueId des Dokuments aus dem SubmissionRequest ist, während $uniqueId_alt die DocumentEntry.uniqueId des bestehenden Dokuments darstellt.
- mit dem Fehler XDSRegistryMetadataError und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den Text "errorText='Cannot register document: Duplicate does not match category of existing document'" antworten, wenn die Kategorie des neuen Dokuments abweicht,
- mit dem Fehler XDSInvalidRequest und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den Text "errorText='Cannot register document: EnableDocumentReuse only allows value true to indicate duplicate'" antworten, wenn der Parameter "EnableDocumentReuse" mit einem anderen Wert als "true" verwendet wird,
- ansonsten mit dem üblichen Fehler antworten, der auch sonst beim Einstellen der Anfrage (d.h. ohne EnableDocumentReuse) zurückgegeben würde.
Alt:
A_21610-03 - Sonderfälle Anlegen von Foldern durch Clientsysteme
Der XDS Document Service MUSS sicherstellen, dass ausschließlich dynamische Ordner vom Typ "Schwangerschaft und Geburt" (Folder.Code = pregnancy_childbirth) durch Clients angelegt werden können. [<=]
Neu:
A_21610-04 - Sonderfälle Anlegen von Foldern durch Clientsysteme
Der XDS Document Service MUSS sicherstellen, dass ausschließlich dynamische Ordner vom Typ "Schwangerschaft und Geburt" (Folder.Code = pregnancy_childbirth) durch Clients angelegt werden können und andernfalls mit dem Fehler XDSRegistryMetadataError antworten. Im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements MUSS in dem Fall der Text "errorText='Cannot create folder: Invalid category'" enthalten sein. [<=]
Alt:
A_21714-03 - XDS Document Service – Löschen von strukturierten Dokumenten durch ein ePA-FdV
Der XDS Document Service MUSS Löschanfragen eines dynamischen Ordners durch ein ePA-FdV ablehnen, wenn zugehörige Submission Sets, Associations oder zugeordnete Dokumente in der Löschanfrage enthalten sind. Das Löschen dieses Ordners impliziert aktensystemseitig immer das Löschen zugehöriger SubmissionSets, Associations sowie zugeordneter Dokumente. Liegt eine Verletzung der Löschvorgaben vor, MUSS die Nachricht mit dem XDSRegistryError-Fehlercode zurückgeben werden. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Wert "Anfragenachricht darf ausschließlich entryUUID für Folder beinhalten" belegt werden. [<=]
Neu:
A_21714-04 - XDS Document Service – Löschen von strukturierten Dokumenten durch ein ePA-FdV
Der XDS Document Service MUSS Löschanfragen eines dynamischen Ordners durch ein ePA-FdV ablehnen, wenn zugehörige Submission Sets, Associations oder zugeordnete Dokumente in der Löschanfrage enthalten sind. Das Löschen dieses Ordners impliziert aktensystemseitig immer das Löschen zugehöriger SubmissionSets, Associations sowie zugeordneter Dokumente. Liegt eine Verletzung der Löschvorgaben vor, MUSS die Nachricht mit dem XDSRegistryError-Fehlercode zurückgeben werden. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements der Wert "errorText='Cannot delete folder: Use only entryUUID of folder'" belegt werden. [<=]
Alt:
A_20579-01 - XDS Document Service – Löschen von Ordnern
Der XDS Document Service MUSS Requests, die darauf abzielen, einen statischen Folder direkt zu löschen, mit einem XDSRegistryMetadataError ablehnen. [<=]
Neu:
A_20579-02 - XDS Document Service – Löschen von Ordnern
Der XDS Document Service MUSS Requests, die darauf abzielen, einen statischen Folder direkt zu löschen, ablehnen und mit dem Fehler XDSRegistryMetadataError und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements den Text "errorText='Cannot create folder: Invalid category'" antworten. [<=]
Alt:
A_15061-08 - XDS Document Service – Ablauflogik für Restricted Update Document Set
Der XDS Document Service MUSS die Umsetzung der Operation RestrictedUpdateDocumentSet gemäß der definierten Ablauflogik in [IHE-ITI-RMU#3.92.4.1.2 und 3.92.4.1.3] implementieren und sicherstellen, dass (nur) die folgenden Metadatenobjekte gesendet werden:
- ein neues SubmissionSet,
- einen DocumentEntry inklusive der entryUUID des zu ändernden DocumentEntry-Objekts. Das übermittelte DocumentEntry-Objekt kann sowohl alle vollständigen Metadatenattribute als auch nur zu ändernde Metadatenattribute enthalten. In jedem Fall dürfen Änderungen ausschließlich gemäß A_15083-* angenommen und durchgeführt werden.
- für das Hinzufügen, Ändern oder Löschen eines einzelnen oder mehrerer Werte in DocumentEntry.author, DocumentEntry.confidentialityCode, DocumentEntry.eventCodeList und DocumentEntry.referenceIdList gilt darüber hinaus:
- es MÜSSEN alle und nicht nur die zu ändernden Werte (z. B. Autoren) über ihre jeweiligen <classification classificationScheme="urn:uuid:...>-XML-Elemente im gewünschten Soll-Zustand gesendet werden.
- das Löschen aller Werte (z. B. Autoren) MUSS durch Übertragung ein einzelnen, komplett leeren <classification="urn:uuid:...>-XML-Elements signalisiert werden.
- eine SS-DE HasMember-Association, die das SubmissionSet mit dem geschickten DocumentEntry verbindet.
- die „lid“ (logicalID) DARF NICHT gesendet werden.
- der Slot "PreviousVersion" MUSS immer mit dem Wert "1" gesendet werden.
- der Slot „AssociationPropagation“ MUSS auf „no“ gesetzt werden. Zusätzlich MUSS der alternative Slot-Name "associationPropagation" akzeptiert werden.
Neu:
A_15061-09 - XDS Document Service – Ablauflogik für Restricted Update Document Set
Der XDS Document Service MUSS die Umsetzung der Operation RestrictedUpdateDocumentSet gemäß der definierten Ablauflogik in [IHE-ITI-RMU#3.92.4.1.2 und 3.92.4.1.3] implementieren und sicherstellen, dass (nur) die folgenden Metadatenobjekte gesendet werden:
- ein neues SubmissionSet,
- einen DocumentEntry inklusive der entryUUID des zu ändernden DocumentEntry-Objekts. Das übermittelte DocumentEntry-Objekt kann sowohl alle vollständigen Metadatenattribute als auch nur zu ändernde Metadatenattribute enthalten. In jedem Fall dürfen Änderungen ausschließlich gemäß A_15083-* angenommen und durchgeführt werden.
- für das Hinzufügen, Ändern oder Löschen eines einzelnen oder mehrerer Werte in DocumentEntry.author, DocumentEntry.confidentialityCode, DocumentEntry.eventCodeList und DocumentEntry.referenceIdList gilt darüber hinaus:
- es MÜSSEN alle und nicht nur die zu ändernden Werte (z. B. Autoren) über ihre jeweiligen <classification classificationScheme="urn:uuid:...>-XML-Elemente im gewünschten Soll-Zustand gesendet werden.
- das Löschen aller Werte (z. B. Autoren) MUSS durch Übertragung ein einzelnen, komplett leeren <classification="urn:uuid:...>-XML-Elements signalisiert werden.
- eine SS-DE HasMember-Association, die das SubmissionSet mit dem geschickten DocumentEntry verbindet.
- die „lid“ (logicalID) DARF NICHT gesendet werden.
- der Slot "PreviousVersion" MUSS immer mit dem Wert "1" gesendet werden. Andernfalls MUSS der XDS Document Service die Operation ablehnen und mit dem Fehler XDSRegistryMetadataError und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements dem Text "errorText='Cannot update metadata: History not allowed'" antworten.
- der Slot „AssociationPropagation“ MUSS auf „no“ gesetzt werden. Zusätzlich MUSS der alternative Slot-Name "associationPropagation" akzeptiert werden.
Alt:
A_23369-02 - XDS Document Service – Verpflichtender Dokumententitel in DocumentEntry.title
Der XDS Document Service MUSS sicherstellen, dass ePA-Clients beim Upload von Dokumenten und dem Ändern von Metadaten an Dokumenten DocumentEntry.title befüllen. Der Titel des Dokumentes soll eine fachliche Beschreibung des Dokumentes enthalten. Bei DocumentEntry.title MÜSSEN führende und endende Leerzeichen entfernt werden. In DocumentEntry.title DARF NICHT leer sein (!= "") (insbesondere auch nicht nach etwaigen Entfernen von Leerzeichen vorne und hinten). In Document.title DÜRFEN keine nicht-druckbaren Zeichen enthalten sein. [<=]
Neu:
A_23369-03 - XDS Document Service – Verpflichtender Dokumententitel in DocumentEntry.title
Der XDS Document Service MUSS sicherstellen, dass ePA-Clients beim Upload von Dokumenten und dem Ändern von Metadaten an Dokumenten DocumentEntry.title befüllen. Der Titel des Dokumentes soll eine fachliche Beschreibung des Dokumentes enthalten. Bei DocumentEntry.title MÜSSEN führende und endende Leerzeichen entfernt werden. In DocumentEntry.title DARF NICHT leer sein (!= "") (insbesondere auch nicht nach etwaigen Entfernen von Leerzeichen vorne und hinten). In Document.title DÜRFEN keine nicht-druckbaren Zeichen enthalten sein.
Andernfalls MUSS der XDS Document Service die Operation mit dem Fehler XDSRegistryMetadataError ablehnen und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements mit: "errorText='Invalid metadata';metadata='title'" antworten.
[<=]
Alt:
A_14762-05 - XDS Document Service – Nutzungsvorgabe für authorPerson als Teil von DocumentEntry.author und SubmissionSet.author
Der XDS Document Service MUSS sicherstellen, dass ePA-Clients beim Upload von Dokumenten und dem Ändern von Dokumenten-Metadaten an authorPerson unterhalb von DocumentEntry.author und SubmissionSet.author neben [IHE-ITI-TF3#4.2.3.1.4.2] auch die folgenden Vorgaben beachten.
Bei Leistungserbringer als Autor:
- Lebenslange Identifikationsnummer eines Arztes (Lebenslange Arztnummer - LANR 9 Stellen) oder im Falle eines Zahnarztes die Zentrale Zahnarztnummer (ZANR)- sofern die ZANR bekannt ist
- "^"
- Nachname
- "^"
- Vorname
- "^"
- Weiterer Vorname
- "^"
- Namenszusatz
- "^"
- Titel
- "^^^&" - sofern LANR oder ZANR angegeben, ansonsten "^^^"
- "1.2.276.0.76.4.16" - sofern LANR angegeben oder "1.2.276.0.76.4.296", falls ZANR angegeben
- "&ISO" - sofern LANR oder ZANR angegeben
165746304^Weber^Thilo^^^Dr.^^^&1.2.276.0.76.4.16&ISO
^Zahnschmerz^Eberhard^^^Dr.^^^
Bei Versichertem als Autor:
- Der unveränderbare Teil der KVNR (10 Stellen)
- "^"
- Nachname
- "^"
- Vorname
- "^"
- Weiterer Vorname
- "^"
- Namenszusatz
- "^"
- Titel
- "^^^&"
- "1.2.276.0.76.4.8"
- "&ISO"
Sowohl beim LE als auch beim Versicherten müssen Vorname und Nachname belegt werden.
Software-Komponente bzw. Gerät als Autor
Beim (automatisierten) Einstellen von Dokumenten MUSS der max. 256-Zeichen lange Name der Software-Komponente bzw. des Geräts als Nachname und ggf. als Vorname(n) eingetragen werden.
Beispiel: ^PHR-Gerät-XY^PHR-Software-XY
Im Falle einer DiGA MUSS das Feld Autor folgendermaßen aufgebaut sein:
- Telematik-ID der DiGA
- "^"
- Name der DiGA (Name der Verordnungseinheit)
- "^"
- Name des DiGA-Herstellers
- "^"
- optionale Ergänzung der Bezeichnung der SW
- "^"
- optionale Ergänzung der Bezeichnung der SW
- "^"
- optionale Ergänzung der Bezeichnung der SW
- "^^^&"
- <OID für DiGAs, wie in professionOID>
- "&ISO"
Für alle drei Arten von Autoren (Versicherter, LE, Gerät) MUSS jeweils Vorname und Nachname angegeben sein. [<=]
Neu:
A_14762-06 - XDS Document Service – Nutzungsvorgabe für authorPerson als Teil von DocumentEntry.author und SubmissionSet.author
Der XDS Document Service MUSS sicherstellen, dass ePA-Clients beim Upload von Dokumenten und dem Ändern von Dokumenten-Metadaten an authorPerson unterhalb von DocumentEntry.author und SubmissionSet.author neben [IHE-ITI-TF3#4.2.3.1.4.2] auch die folgenden Vorgaben beachten.
Bei Leistungserbringer als Autor:
- Lebenslange Identifikationsnummer eines Arztes (Lebenslange Arztnummer - LANR 9 Stellen) oder im Falle eines Zahnarztes die Zentrale Zahnarztnummer (ZANR)- sofern die ZANR bekannt ist
- "^"
- Nachname
- "^"
- Vorname
- "^"
- Weiterer Vorname
- "^"
- Namenszusatz
- "^"
- Titel
- "^^^&" - sofern LANR oder ZANR angegeben, ansonsten "^^^"
- "1.2.276.0.76.4.16" - sofern LANR angegeben oder "1.2.276.0.76.4.296", falls ZANR angegeben
- "&ISO" - sofern LANR oder ZANR angegeben
165746304^Weber^Thilo^^^Dr.^^^&1.2.276.0.76.4.16&ISO
^Zahnschmerz^Eberhard^^^Dr.^^^
Bei Versichertem als Autor:
- Der unveränderbare Teil der KVNR (10 Stellen)
- "^"
- Nachname
- "^"
- Vorname
- "^"
- Weiterer Vorname
- "^"
- Namenszusatz
- "^"
- Titel
- "^^^&"
- "1.2.276.0.76.4.8"
- "&ISO"
Sowohl beim LE als auch beim Versicherten müssen Vorname und Nachname belegt werden.
Software-Komponente bzw. Gerät als Autor
Beim (automatisierten) Einstellen von Dokumenten MUSS der max. 256-Zeichen lange Name der Software-Komponente bzw. des Geräts als Nachname und ggf. als Vorname(n) eingetragen werden.
Beispiel: ^PHR-Gerät-XY^PHR-Software-XY
Im Falle einer DiGA MUSS das Feld Autor folgendermaßen aufgebaut sein:
- Telematik-ID der DiGA
- "^"
- Name der DiGA (Name der Verordnungseinheit)
- "^"
- Name des DiGA-Herstellers
- "^"
- optionale Ergänzung der Bezeichnung der SW
- "^"
- optionale Ergänzung der Bezeichnung der SW
- "^"
- optionale Ergänzung der Bezeichnung der SW
- "^^^&"
- <OID für DiGAs, wie in professionOID>
- "&ISO"
Für alle drei Arten von Autoren (Versicherter, LE, Gerät) MUSS jeweils Vorname und Nachname angegeben sein.
Falls die Vorgaben nicht erfüllt werden, MUSS der XDS Document Service die Operation mit dem Fehler XDSRegistryMetadataError ablehnen und im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements antworten mit: "errorText='Invalid metadata';metadata='author.authorPerson'" antworten.
[<=]
Alt:
A_20707-04 - XDS Document Service – Keine unpassenden Dokumente in nicht-statische Ordner
Falls das Dokument nicht den Vorgaben der Metadaten für strukturierte Dokumente gemäß [gemSpec_IG_ePA] entspricht, MUSS der XDS Document Service das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem IHE-Fehlercode BadFolderAssociation quittieren. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements die UUID (DocumentEntry.entryUUID) des identifizierten Dokuments angegeben werden. [<=]
Neu:
A_20707-05 - XDS Document Service – Keine unpassenden Dokumente in nicht-statische Ordner
Falls das Dokument nicht den Vorgaben der Metadaten für strukturierte Dokumente gemäß [gemSpec_IG_ePA] entspricht, MUSS der XDS Document Service das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem IHE-Fehlercode BadFolderAssociation quittieren. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements angegeben werden:
- errorText='Cannot register document: Structured document is not permitted for dynamic folder: invalid metadata'
- Liste der Metadaten, die nicht korrekt angegeben wurden mit: metadata=<value_1>;...;metadata=<value_n>"
-------------------------NEU ----------------------------------------------------------
Das Feature Anhänge wird nicht im Release 3.1.3 enthalten sein. Deshalb wird A_23124 wieder in gemSpec_Aktensystem_ePAfuerAlle aufgenommen und für diesen Change angepasst.
Alt:
A_23124 - XDS Document Service – Addendum nur mit einem Dokument verknüpfen
Der XDS Document Service DARF ein Addendum NICHT mit mehr als einem Dokument verknüpfen. [<=]
Neu:
A_23124-01 - XDS Document Service – Addendum nur mit einem Dokument verknüpfen
Der XDS Document Service DARF ein Addendum NICHT mit mehr als einem Dokument verknüpfen.
Ist die Bedingung nicht erfüllt, MUSS der XDS Document Service das Registrieren und Speichern von Metadaten und Dokument(en) ablehnen und mit einem IHE-Fehlercode XDSRegistryMetadataError quittieren. Es MUSS im codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements "errorText='Cannot create association: Only one addendum is allowed'" angegeben werden. [<=]
Alt:
A_27760-01 - XDS Document Service - Ablehnen von RPLC-Ersetzungen bei nicht erlaubten Dokumententypen
Der XDS Document Service MUSS das Ersetzen von Dokumenten via RPLC-Associations mit dem Fehlercode XDSReplacementForbidden ablehnen, wenn das zu ersetzende Dokument weder einen der folgenden DocumentEntry.formatCode-Werte besitzt,
Tabelle 3 : Liste mit Dokumententypen, die ersetzt werden können
| Dokument | codeSystem | code |
|---|---|---|
| eMP | 1.3.6.1.4.1.19376.3.276.1.5.6 | urn:gematik:ig:Medikationsplan:r3.1 |
| NFD | 1.3.6.1.4.1.19376.3.276.1.5.6 | urn:gematik:ig:Notfalldatensatz:r3.1 |
| DPE | 1.3.6.1.4.1.19376.3.276.1.5.6 | urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1 |
| DiGA | 1.3.6.1.4.1.19376.3.276.1.5.6 | urn:gematik:ig:diga:v1.1 |
| Notizen Kinderuntersuchungsheft | 1.3.6.1.4.1.19376.3.276.1.5.6 | urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.0 oder
urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.1 |
noch in einen der folgenden Ordner einsortiert ist:
Tabelle 4 : Liste mit Ordnern, in denen Dokumente ersetzt werden dürfen
| Ordner-Kategorie | Folder.entryUUID | |
|---|---|---|
| receipt | 91420e5e-e055-4c7d-b14e-96239e8f0d6d | |
| technical | f88dc706-d2df-4ca0-a850-491cfaab2d31 |
Neu:
A_27760-02 - XDS Document Service - Ablehnen von RPLC-Ersetzungen bei nicht erlaubten Dokumententypen
Der XDS Document Service MUSS das Ersetzen von Dokumenten via RPLC-Associations mit dem Fehlercode XDSReplacementForbidden ablehnen und in codeContext-Attribut des zurückgegebenen rs:RegistryError-Elements "errorText='Cannot replace document: formatCode not allowed'" angegeben, wenn das zu ersetzende Dokument weder einen der folgenden DocumentEntry.formatCode-Werte besitzt,
Tabelle 5 : Liste mit Dokumententypen, die ersetzt werden können
| Dokument | codeSystem | code |
|---|---|---|
| NFD | 1.3.6.1.4.1.19376.3.276.1.5.6 | urn:gematik:ig:Notfalldatensatz:r3.1 |
| DPE | 1.3.6.1.4.1.19376.3.276.1.5.6 | urn:gematik:ig:DatensatzPersoenlicheErklaerungen:r3.1 |
| DiGA | 1.3.6.1.4.1.19376.3.276.1.5.6 | urn:gematik:ig:diga:v1.1 |
| Notizen Kinderuntersuchungsheft | 1.3.6.1.4.1.19376.3.276.1.5.6 | urn:gematik:ig:KinderuntersuchungsheftNotizen:v1.0.1 |
noch in einen der folgenden Ordner einsortiert ist:
Tabelle 6 : Liste mit Ordnern, in denen Dokumente ersetzt werden dürfen
| Ordner-Kategorie | Folder.entryUUID | |
|---|---|---|
| receipt | 91420e5e-e055-4c7d-b14e-96239e8f0d6d | |
| technical | f88dc706-d2df-4ca0-a850-491cfaab2d31 |