AMTS ISiK Implementierungsleitfaden
Version 6.0.0-rc - ballot

CapabilityStatement: CapabilityStatement für Rolle StammdatenRolle

Official URL: https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementStammdatenRolle Version: 6.0.0-rc
Active as of 2026-04-02 Computable Name: ISiKCapabilityStatementStammdatenRolle

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 ISiKCapabilityStatementStammdatenRolle. Diese Rolle beschreibt Interaktionen zum Abruf und der Verarbeitung grundlegender Stammdaten.

CapabilityStatement für Rolle StammdatenRolle

  • Implementation Guide Version: 6.0.0-rc
  • FHIR Version: 4.0.1
  • Supported Formats: application/fhir+xml, application/fhir+json
  • Published on: 2026-04-02
  • Published by: gematik GmbH

Note 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.

SHALL Support the Following Implementation Guides

  • https://gematik.de/fhir/isik/ImplementationGuide/ISiK-Basismodul

FHIR RESTful Capabilities

Mode: server

Capabilities by Resource/Profile

Summary

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).
  • The linked resources enabled for _include
  • The other resources enabled for _revinclude
  • The operations on the resource (if any)
Resource TypeProfileRSUCSearches_include_revincludeOperations
PatientSupported Profiles
  ISiKPatient		YY_id, _count, _has, _tag, _lastUpdated, identifier, family, given, birthdate, gender$Patient-everything
EncounterSupported Profiles
  ISiKKontaktGesundheitseinrichtung		YY_id, _count, _has, _tag, _lastUpdated, identifier, status, class, type, patient, account, date, date-start, end-dateEncounter:patient$Encounter-everything
Core FHIR Resource
Patient
Reference Policy
Interaction summary
  • SHALL support read, search-type.

Supported Profiles

ISiKPatient

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken

Beispiel: GET [base]/[Resourcetype]?_id=103270 Anwendungshinweis: 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_countnumber

Beispiel: GET [base]/[Resourcetype]?_count=100 Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Page Count.

SHALL_lastUpdateddate

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.

SHALLidentifiertoken

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.

SHALLfamilystring

Beispiel:
GET [base]/Patient?family=Musterfrau
Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.

SHALLgivenstring

Beispiel:
GET [base]/Patient?given=Erika
Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Dieser Suchparameter ist für die Umsetzung des IHE PDQm Profils verpflichtend.

SHALLbirthdatedate

Beispiel:
GET [base]/Patient?birthdate=1964-12-08
Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.

SHALLgendertoken

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_hasstring

Beispiel: Suche nach allen Patienten, die eine Observation mit dem Code '1234-5' haben GET [base]/Patient?_has:Observation:patient:code=1234-5 Beispiel: Suche nach allen Encountern, bei denen die Diagnose 'A12.3' gestellt wurde GET [base]/Encounter?_has:Condition:encounter:code=A12.3 Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Reverse Chaining.

MAY_tagtoken

Beispiel: GET [base]/[Resourcetype]?_tag=https://example.org/codes|needs-review Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Parameters for all resources sowie Abschnitt Tags.

 
Extended Operations
ConformanceOperationDocumentation
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.

Core FHIR Resource
Encounter
Reference Policy
Interaction summary
  • SHALL support read, search-type.

Supported Profiles

ISiKKontaktGesundheitseinrichtung

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken

Beispiel: GET [base]/[Resourcetype]?_id=103270 Anwendungshinweis: 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_countnumber

Beispiel: GET [base]/[Resourcetype]?_count=100 Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Page Count.

SHALL_lastUpdateddate

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.

SHALLidentifiertoken

Beispiel:
GET [base]/Encounter?identifier=http://test.krankenhaus.de/fhir/sid/fallnr|123456
Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.

SHALLstatustoken

Beispiel:
GET [base]/Encounter?status=finished
Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.

SHALLclasstoken

Beispiel:
GET [base]/Encounter?class=IMP
Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.

SHALLtypetoken

Beispiel:
GET [base]/Encounter?type=http://fhir.de/CodeSystem/kontaktart-de|stationaer
Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.

SHALLpatientreference

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.

SHALLaccountreference

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.

SHALLdatedate

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.

SHALLdate-startdate

Beispiel:
GET [base]/Encounter?end-date=lt2020-26-10
Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Bei diesem Suchparameter handelt es sich um eine Präadoption eines Suchparameters, der in FHIR R5 hinzugefügt wurde.

SHALLend-datedate

Beispiel:
GET [base]/Encounter?end-date=lt2020-26-10
Anwendungshinweis:
Weitere Details siehe FHIR-Kernspezifikation.
Bei diesem Suchparameter handelt es sich um eine Präadoption eines Suchparameters, der in FHIR R5 hinzugefügt wurde.

MAY_hasstring

Beispiel: Suche nach allen Patienten, die eine Observation mit dem Code '1234-5' haben GET [base]/Patient?_has:Observation:patient:code=1234-5 Beispiel: Suche nach allen Encountern, bei denen die Diagnose 'A12.3' gestellt wurde GET [base]/Encounter?_has:Condition:encounter:code=A12.3 Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Reverse Chaining.

MAY_tagtoken

Beispiel: GET [base]/[Resourcetype]?_tag=https://example.org/codes|needs-review Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Parameters for all resources sowie Abschnitt Tags.

 
Extended Operations
ConformanceOperationDocumentation
SHALL$Encounter-everything

Im Kontext von ISiK werden auf Basis der Core-Definition der Operation Encounter-everything folgende Festlegungen getroffen:

- 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.