| Official URL: https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementDokumentenServerAkteur | Version: 6.0.0-rc | |||
| Active as of 2025-12-17 | Computable Name: ISiKCapabilityStatementDokumentenServerAkteurExpanded | |||
Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diesen Akteur implementiert.
Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine CapabilityStatement-Ressource bereitstellen.
Hierzu MUSS die capabilities-Interaktion gemäß FHIR-Kernspezifikation unterstützt werden.
Der MODE-Parameter kann ignoriert werden.
Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar (kind = requirements).
Zur Unterscheidung von Rollen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN,
wird die CapabilityStatement-Imports-Expectation-Extension mit den möglichen Werten ‘SHALL’ (=MUSS) ‘SHOULD’ (=SOLL) ‘MAY’ (=KANN) ‘SHOULD-NOT’ (=SOLL NICHT) verwendet.
Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom kind = instance liefern und im Element software den Namen
und die Versionsnummer angeben.
Darüber hinaus MÜSSEN in CapabilityStatement.instantiates sämtliche Canonical URLs der implementierten Rollen angegeben werden.
Die mindestens zu implementierenden Profile für einen Akteur und Interaktionen entsprechen daher den aggregierten Anforderungen der einzelnen Rolle (per ‘imports’). In den CapabilityStatements zu den Rollen sind die Anforderungen tabellarisch gelistet und weisen so die zu implementierenden Profile aus.
Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement (bzw. der in ihm importierten Rollen - siehe ‘imports’) mit SHALL gekennzeichnet sind.
Das CapabilityStatement KANN darüber hinaus die mit MAY gekennzeichneten Funktionalitäten, sowie weitere Funktionalitäten auflisten,
sofern diese in der Instanz implementiert wurden.
Die Verwendung der CapabilityStatement-Expectation-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich.
CapabilityStatement für den Akteur "ISiKCapabilityStatementDokumentenServerAkteur". Dieser Akteur aggregiert die Rollen zur Erzeugung und dem Abruf von Metadaten für Dokumente.
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.