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.
ISiK CapabilityStatement Dokumenten Server Akteur (Expanded)
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.
The summary table lists the resources that are part of this configuration, and for each resource it lists:
The relevant profiles (if any)
The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
The required, recommended, and some optional search parameters (if any).
Beispiel:GET [base]/[Resourcetype]?_id=103270Anwendungshinweis:
Der Parameter _id wird selten alleinstehend verwendet, da sich zum Abruf einer Ressource
anhand der id die READ-Interaktion besser anbietet. Der Parameter kann jedoch verwendet werden,
um den Abruf einer Ressource bspw. mit einem _include weiterer Ressourcen zu verbinden,
z.B. zum Abruf eines Encounters in Verbindung mit dem zugehörigen Patienten:
GET [base]/Encounter?_id=103270&_include=Encounter:patient
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Parameters for all resources.
Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
SHALL
_count
number
Beispiel:GET [base]/[Resourcetype]?_count=100Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Page Count.
SHALL
_lastUpdated
date
Beispiel: Suche nach allen Patienten-Ressourcen, die seit dem 1. Januar neu angelegt oder geändert wurden: GET [base]/Patient?_lastUpdated=ge2026-01-01 Beispiel: Suche nach allen Observations eines Patienten im Zeitraum einer Stunde: GET [base]/Observation?_lastUpdated=ge2026-03-05T10:20:10.423+02:00&_lastUpdate=lt2026-03-05T11:20:10.423+02:00&patient=Patient/12345 Anwendungshinweis:
Dieser Suchparameter dient dem Datenabgleich zwischen Systemen und ist auch für die patientenübergreifende Suche zugelassen.
Server können die Anfrage mit einer OperationOutcome-Ressource und dem Fehlercode too-costly beantworten, wenn das vom Client gewählte Zeitfenster oder die Treffermenge zu groß ist
und die Durchführhung der Suchanfrage das System unverhältnismäßig stark belasten würde.
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt _lastUpdated.
Beispiel:GET [base]/DocumentReference?status=finalAnwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE MHD Profils für Clients und Server verpflichend.
Beispiel:GET [base]/DocumenReference?identifier=urn:oid:1.2.840.113556.1.8000.2554.58783.21864.3474.19410.44358.58254.41281.46340 Anwendungshinweis:
Durchsucht die Elemente DocumentReference.identifier und DocumentReference.masterIdentifier nach übereinstimmenden Dokumenten.
Beispiel:GET [base]/DocumentReference?patient=Patient/123GET [base]/DocumentReference?patient.identifier=http://mein-krankenhaus.example/fhir/sid/patienten|1032702GET [base]/DocumentReference?patient.identifier=1032702Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Weitere Informationen zur Suche nach verketteten Parametern finden sich in der FHIR-Kernspezifikation - Abschnitt Chained Parameters.
Dieser Suchparameter ist für die Umsetzung des IHE MHD Profils für Clients und Server verpflichend.
Beispiel:GET [base]/DocumentReference?type=http://dvmd.de/fhir/CodeSystem/kdl|AD010101Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE MHD Profils für Server verpflichtend.
Beispiel:GET [base]/DocumentReference?category=http://ihe-d.de/CodeSystem/IHEXDSclassCode|BEFAnwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE MHD Profils für Server verpflichtend.
SHALL
creation
date
Beispiel:GET [base]/DocumentReference?creation=2021-11-05Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist Teil der IHE-MHD-Spezifikation und für die Umsetzung des IHE MHD Profils für Server verpflichtend.
Beispiel:GET [base]/DocumentReference?encounter=Encounter/123Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
MAY
_has
string
Beispiel: Suche nach allen Patienten, die eine Observation mit dem Code '1234-5' haben
GET [base]/Patient?_has:Observation:patient:code=1234-5Beispiel: Suche nach allen Encountern, bei denen die Diagnose 'A12.3' gestellt wurde
GET [base]/Encounter?_has:Condition:encounter:code=A12.3Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Reverse Chaining.
Beispiel:GET [base]/[Resourcetype]?_tag=https://example.org/codes|needs-reviewAnwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Parameters for all resources
sowie Abschnitt Tags.
Fü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.
Beispiel:GET [base]/[Resourcetype]?_id=103270Anwendungshinweis:
Der Parameter _id wird selten alleinstehend verwendet, da sich zum Abruf einer Ressource
anhand der id die READ-Interaktion besser anbietet. Der Parameter kann jedoch verwendet werden,
um den Abruf einer Ressource bspw. mit einem _include weiterer Ressourcen zu verbinden,
z.B. zum Abruf eines Encounters in Verbindung mit dem zugehörigen Patienten:
GET [base]/Encounter?_id=103270&_include=Encounter:patient
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Parameters for all resources.
Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
SHALL
_count
number
Beispiel:GET [base]/[Resourcetype]?_count=100Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Page Count.
SHALL
_lastUpdated
date
Beispiel: Suche nach allen Patienten-Ressourcen, die seit dem 1. Januar neu angelegt oder geändert wurden: GET [base]/Patient?_lastUpdated=ge2026-01-01 Beispiel: Suche nach allen Observations eines Patienten im Zeitraum einer Stunde: GET [base]/Observation?_lastUpdated=ge2026-03-05T10:20:10.423+02:00&_lastUpdate=lt2026-03-05T11:20:10.423+02:00&patient=Patient/12345 Anwendungshinweis:
Dieser Suchparameter dient dem Datenabgleich zwischen Systemen und ist auch für die patientenübergreifende Suche zugelassen.
Server können die Anfrage mit einer OperationOutcome-Ressource und dem Fehlercode too-costly beantworten, wenn das vom Client gewählte Zeitfenster oder die Treffermenge zu groß ist
und die Durchführhung der Suchanfrage das System unverhältnismäßig stark belasten würde.
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt _lastUpdated.
Beispiel: GET [base]/Patient?identifier=http://fhir.krankenhaus.example|1032702 GET [base]/Patient?identifier=1032702 Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
Beispiel: GET [base]/Patient?family=Musterfrau Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
Beispiel: GET [base]/Patient?given=Erika Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
Beispiel: GET [base]/Patient?birthdate=1964-12-08 Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
MAY
_has
string
Beispiel: Suche nach allen Patienten, die eine Observation mit dem Code '1234-5' haben
GET [base]/Patient?_has:Observation:patient:code=1234-5Beispiel: Suche nach allen Encountern, bei denen die Diagnose 'A12.3' gestellt wurde
GET [base]/Encounter?_has:Condition:encounter:code=A12.3Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Reverse Chaining.
Beispiel:GET [base]/[Resourcetype]?_tag=https://example.org/codes|needs-reviewAnwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Parameters for all resources
sowie Abschnitt Tags.
Extended Operations
Conformance
Operation
Documentation
SHALL
$Patient-everything
In der Operation ist die Ergebnismenge wie folgt definiert: 'The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient(s), and any resource referenced from those, including binaries and attachments.'. Im Kontext von ISiK ist das so zu interpretieren, dass ein Akteur alle Ressourcen, die laut seinem CapabilityStatement über seine API abrufbar sind und die Teil des Patient-CompartmentDefinition sind, zurückgeben MUSS. Inklusive aller Ressourcen, die von diesen Ressourcen referenziert werden, einschließlich Binaries und Attachments.
Ein ISiK Akteur MUSS nur das das Instance-Level ([base]/Patient/[id]/$everything) unterstützen, nicht jedoch die Type-Level Operation ([base]/Patient/$everything).
Ein ISiK Akteur darf sinnvolle Limits für die Einschränkung der Ergebnismenge definieren, wie die Forcierung von Pagination über den Parameter _count oder die Einschränkung des Zeitraums der zurückgegebenen Ressourcen über den Parameter _since. Hierbei sollten die Hinweise und vorgaben der ISiK-Spezifikation zu Performance beachtet werden.
Beispiel:GET [base]/[Resourcetype]?_id=103270Anwendungshinweis:
Der Parameter _id wird selten alleinstehend verwendet, da sich zum Abruf einer Ressource
anhand der id die READ-Interaktion besser anbietet. Der Parameter kann jedoch verwendet werden,
um den Abruf einer Ressource bspw. mit einem _include weiterer Ressourcen zu verbinden,
z.B. zum Abruf eines Encounters in Verbindung mit dem zugehörigen Patienten:
GET [base]/Encounter?_id=103270&_include=Encounter:patient
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Parameters for all resources.
Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.
SHALL
_count
number
Beispiel:GET [base]/[Resourcetype]?_count=100Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Page Count.
SHALL
_lastUpdated
date
Beispiel: Suche nach allen Patienten-Ressourcen, die seit dem 1. Januar neu angelegt oder geändert wurden: GET [base]/Patient?_lastUpdated=ge2026-01-01 Beispiel: Suche nach allen Observations eines Patienten im Zeitraum einer Stunde: GET [base]/Observation?_lastUpdated=ge2026-03-05T10:20:10.423+02:00&_lastUpdate=lt2026-03-05T11:20:10.423+02:00&patient=Patient/12345 Anwendungshinweis:
Dieser Suchparameter dient dem Datenabgleich zwischen Systemen und ist auch für die patientenübergreifende Suche zugelassen.
Server können die Anfrage mit einer OperationOutcome-Ressource und dem Fehlercode too-costly beantworten, wenn das vom Client gewählte Zeitfenster oder die Treffermenge zu groß ist
und die Durchführhung der Suchanfrage das System unverhältnismäßig stark belasten würde.
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt _lastUpdated.
Beispiel: GET [base]/Encounter?identifier=http://test.krankenhaus.de/fhir/sid/fallnr|123456 Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Beispiel: GET [base]/Encounter?type=http://fhir.de/CodeSystem/kontaktart-de|stationaer Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Beispiel: GET [base]/Encounter?patient=Patient/123 Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE QEDm Profils verpflichtend.
Beispiel: GET [base]/Encounter?account=Account/123 GET [base]/Encounter?account:identifier=123456 GET [base]/Encounter?account:identifier=https://example.org/fhir/sid/abrechnungsfallnr|123456 Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Beispiel: GET [base]/Encounter?date=lt2020-26-10 Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Bei der Formulierung der Suche sollten die Vorgaben aus der Definition der
Such-Prefixe
- und hier insbesondere die Unterschiede zwischen lt und eb bzw. gt und sa - beachtet werden.
Beispiel: Suche nach allen Patienten, die eine Observation mit dem Code '1234-5' haben
GET [base]/Patient?_has:Observation:patient:code=1234-5Beispiel: Suche nach allen Encountern, bei denen die Diagnose 'A12.3' gestellt wurde
GET [base]/Encounter?_has:Condition:encounter:code=A12.3Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Reverse Chaining.
Beispiel:GET [base]/[Resourcetype]?_tag=https://example.org/codes|needs-reviewAnwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Parameters for all resources
sowie Abschnitt Tags.
- Ein Akteur MUSS alle Ressourcen zurückgeben, die laut seinem CapabilityStatement über seine API abrufbar sind und die Teil des [Encounter-CompartmentDefinition](http://hl7.org/fhir/R4/compartmentdefinition-encounter.html) sind.
- Im Kontext von ISiK werden assoziierte Encounter über die Verknüpfung mit dem selben Abrechnungsfall dargestellt. Aus dem Grund MÜSSEN alle Ressourcen beinhaltet sein, die auch auf Encounter verweisen, welche mit dem selben Abrechnungsfall (`Encounter.account.identifier`) verknüpft sind. Auf diese Encounter wird die selbe Logik wie in Punkt 1 und den folgenden Punkten angewendet.
- Zusätzlich (zum Encounter-Compartment) sind Ressourcen OHNE Fallbezug, die dem gleichen Patienten zugeordnet sind, einzubeziehen:
- AllergyIntolerances
- Es müssen alle Ressourcen inkludiert werden, die aus den oben identifizierten Ressourcen referenziert werden, einschließlich Binaries und Attachments.
Ein ISiK Akteur darf sinnvolle Limits für die Einschränkung der Ergebnismenge definieren, wie die Forcierung von Pagination über den Parameter _count oder die Einschränkung des Zeitraums der zurückgegebenen Ressourcen über den Parameter _since. Hierbei sollten die Hinweise und vorgaben der ISiK-Spezifikation zu Performance beachtet werden.
