| Official URL: https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementDokumentenverwaltungRolle | Version: 6.0.0-rc | |||
| Active as of 2025-12-17 | Computable Name: ISiKCapabilityStatementDokumentenverwaltungRolle | |||
Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.
Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements).
Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN,
wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.
CapabilityStatement für die Rolle "ISiKCapabilityStatementDokumentenverwaltungRolle". Diese Rolle beschreibt verpflichtende Interaktionen zur Erstellung, dem Abruf und der Aktualisierung von Dokumenten.
application/fhir+xml, application/fhir+jsonNote to Implementers: FHIR Capabilities
Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.
serverThe summary table lists the resources that are part of this configuration, and for each resource it lists:
_include_revinclude| Resource Type | Profile | R | S | U | C | Searches | _include | _revinclude | Operations |
|---|---|---|---|---|---|---|---|---|---|
| DocumentReference | Supported Profiles Erforderliche Metadaten für Dokumentenaustausch in ISiK | Y | Y | Y | _id, _tag, _count, _has, status, identifier, patient, type, category, creation, encounter | DocumentReference:patient, DocumentReference:encounter | |||
| Binary | Supported Profiles ISiKBinary | Y |
search-typecreatesiehe {{pagelink:Dokumentenbereitstellung}}
readsiehe {{pagelink:Dokumentenabfrage}}
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | _id | token | Beispiel:
|
| SHALL | _tag | token | Beispiel:
|
| SHALL | _count | number | Beispiel:
|
| SHALL | status | token | Beispiel:
|
| SHALL | identifier | token | Beispiel:
|
| SHALL | patient | reference | Beispiel:
|
| SHALL | type | token | Beispiel:
|
| SHALL | category | token | Beispiel:
|
| SHALL | creation | date | Beispiel:
|
| SHALL | encounter | reference | Beispiel:
|
| MAY | _has | string | Beispiel: Suche nach allen Patienten, die eine Observation mit dem Code '1234-5' haben
|
readFür die Ressource Binary MUSS die REST-Interaktion read implementiert werden.
Es MÜSSEN die Regeln aus der FHIR-Kernspezifikation zur Abfrage einer Binary Ressource beachtet werden.
Siehe Serving Binary Resources using the RESTful API.
Um die Handhabung der base64-kodierten Binary-Ressourcen clientseitig zu erleichtern,
MUSS ein bestätigungsrelevantes System (Server) bei READ-Interaktionen Accept-Header
mit einem Wert außer den [FHIR-Mime-Types](https://www.hl7.org/fhir/R4/http.html#mime-type) unterstützen.
Falls ein solcher Accept-Header durch einen Client verwendet wird, MUSS bestätigungsrelevante System (Server)
das Binary in seiner nativen Form (definiert durch Binary.contentType) zurückgeben.