Implementierungsleitfaden ISiK-Terminplanung

Akteur: ISiKCapabilityStatementTerminRepository
Rolle: ISiKCapabilityStatementTerminRepository

CapabilityStatements

ISiK CapabilityStatement Termin-Repository Akteur - Konformitätserklärung (CapabilityStatement)

Beschreibung

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

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.

Zweck
Das vorliegende CapabilityStatement fasst die Rollen (und entsprechende Interaktionen) zusammen, die ein Akteur 'Termin-Repository' zur Unterstützung des Termin-Workflows implementieren muss.

CanonicalURL	https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementTerminRepositoryAkteur
Intention	requirements
Status	active
Version	5.1.0

Zu importierende Rollen

SHALL Rollen
https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementTerminologieRolle, https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementStammdatenRolle, https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementTerminRepositoryRolle

ISiK CapabilityStatement Termin-Repository Rolle - Konformitätserklärung (CapabilityStatement)

Beschreibung

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

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.

Zweck
Das vorliegende CapabilityStatement beschreibt Interaktionen für ein System, das Termin-Repository-Daten exponiert.

CanonicalURL	https://gematik.de/fhir/isik/CapabilityStatement/ISiKCapabilityStatementTerminRepositoryRolle
Intention	requirements
Status	active
Version	5.1.0

Anforderungen an die FHIR-API

Modus	server

Interaktionen

Ressourcentyp	Verbindlichkeit	READ	SEARCH
Appointment	SHALL	SHALL	SHALL
HealthcareService	SHALL	SHALL	SHALL
Schedule	SHALL	SHALL	SHALL
Slot	SHALL	SHALL	SHALL

Profile

Ressourcentyp	Profile
Appointment	https://gematik.de/fhir/isik/StructureDefinition/ISiKTermin
HealthcareService	https://gematik.de/fhir/isik/StructureDefinition/ISiKMedizinischeBehandlungseinheit
Schedule	https://gematik.de/fhir/isik/StructureDefinition/ISiKKalender
Slot	https://gematik.de/fhir/isik/StructureDefinition/ISiKTerminblock

Ressourcentyp-spezifische Operations

RessourcenTyp	Name	Spezifikation	Verbindlichkeit
Appointment	book	https://gematik.de/fhir/isik/OperationDefinition/AppointmentBook	SHALL

Globale Operations

Dokumenten-Endpunkt

Suchparameter

RessourcenTyp	SuchParameter	Verbindlichkeit	Hinweise	Definition
Schedule	_id	SHALL	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.	http://hl7.org/fhir/SearchParameter/Resource-id
Schedule	_tag	SHALL	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.	http://hl7.org/fhir/SearchParameter/Resource-tag
Schedule	_count	SHALL	Beispiel: `GET [base]/[Resourcetype]?_count=100` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Page Count.
Schedule	_has	MAY	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.
Schedule	active	SHALL	Beispiel: `GET [base]/Schedule?active=true` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Schedule-active
Schedule	service-type	SHALL	Beispiel: `GET [base]/Schedule?service-type=http://example.org/fhir/CodeSystem/ScheduleServiceType\|CT` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Schedule-service-type
Schedule	specialty	SHALL	Beispiel: `GET [base]/Schedule?specialty=urn:oid:1.2.276.0.76.5.114\|535` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Schedule-specialty
Schedule	actor	SHALL	Beispiel: `GET [base]/Schedule?actor=Practitioner/ISiKPractitionerExample` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Schedule-actor
Slot	_id	SHALL	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.	http://hl7.org/fhir/SearchParameter/Resource-id
Slot	_tag	SHALL	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.	http://hl7.org/fhir/SearchParameter/Resource-tag
Slot	_count	SHALL	Beispiel: `GET [base]/[Resourcetype]?_count=100` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Page Count.
Slot	_has	MAY	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.
Slot	schedule	SHALL	Beispiel: `GET [base]/Slot?schedule=Schedule/ISiKKalenderExample&start=2022-12-10T09:00:00Z` `GET [base]/Slot?schedule=Schedule/ISiKKalenderExample` Anwendungshinweis: Der Suchparameter `schedule` MUSS in Kombination mit einem definierten Startzeitpunkt mittels Suchparameter `start` unterstützt werden. Der Suchparameter `schedule` KANN alleinstehend unterstützt werden. Beim Fehlen des `start`-Suchparameters SOLL der aktuelle Zeitpunkt des Servers als Startzeitpunkt per Default verwendet werden. In diesem Fall ist auch ein Chaining auf weitere verknüpfte Akteure möglich: `GET https://example.org/fhir/Slot?schedule.actor:HealthcareService.type=https://example.org/fhir/CodeSystem/Behandlungsleistung\|CT` Dies kann notwendig sein, falls interdisziplinäre Kalender durch das Termin-Repository gepflegt werden (z.B. ein Kalender pro Station). In solchen Fälle wäre es sinnvoll, wenn das Termin-Repository einem Termin-Requestor eine Verknüpfung zwischen Kalender (Schedule) und Behandlungsleistung (HealthcareService) bereitstellen würde. Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Slot-schedule
Slot	status	SHALL	Beispiel: `GET [base]/Slot?status=free&schedule=Schedule/ISiKTerminExample` `GET [base]/Slot?status=free&schedule.actor:Practitioner.name=Musterarzt` Anwendungshinweis: Der Suchparameter `status` MUSS in Kombination ('&') mit dem Parameter `schedule` unterstützt werden. Diese Abfrage KANN entweder eine direkte Angabe einer Referenz oder eine Angabe von weiteren Chaining-Parametern sein. Der Suchparameter MUSS NICHT alleinstehend unterstützt werden. Falls der Parameter nicht alleinstehend unterstützt wird, dann SOLL der Server einen Fehler-Code 422 (Unprocessable Entity) zurückgeben, falls ein Client den Parameter alleinstehend verwendet. Zudem SOLL eine OperationOutcome über die fehlende Kombination bei der Suchanfrage Auskunft geben. Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Slot-status
Slot	start	SHALL	Beispiel: `GET [base]/Slot?start=2022-12-10T09:00:00Z&schedule=Schedule/ISiKTerminExample` `GET [base]/Slot?start=2022-12-10T09:00:00Z&schedule.actor:Practitioner.name=Musterarzt` Anwendungshinweis: Der Suchparameter `start` MUSS in Kombination ('&') mit dem Parameter `schedule` unterstützt werden. Diese Abfrage KANN entweder eine direkte Angabe einer Referenz oder eine Angabe von weiteren Chaining-Parametern sein. Der Suchparameter MUSS NICHT alleinstehend unterstützt werden. Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Slot-start
Appointment	_id	SHALL	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.	http://hl7.org/fhir/SearchParameter/Resource-id
Appointment	_tag	SHALL	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.	http://hl7.org/fhir/SearchParameter/Resource-tag
Appointment	_count	SHALL	Beispiel: `GET [base]/[Resourcetype]?_count=100` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Page Count.
Appointment	_has	MAY	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.
Appointment	status	SHALL	Beispiel: `GET [base]/Appointment?status=booked` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Appointment-status
Appointment	service-type	SHALL	Beispiel: `GET [base]/Appointment?service-type=http://example.org/fhir/CodeSystem/ScheduleServiceType\|CT` Anwendungshinweis: Anwendungshinweise: Bei einer Suche mit dem `:not`-Modifier MÜSSEN Ressourcen, die keinen Wert für `Appointment.serviceType` enthalten, im Suchergebnis enthalten sein. Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Appointment-service-type
Appointment	specialty	SHALL	Beispiel: `GET [base]/Appointment?specialty=urn:oid:1.2.276.0.76.5.114\|535` Anwendungshinweis: Anwendungshinweise: Bei einer Suche mit dem `:not`-Modifier MÜSSEN Ressourcen, die keinen Wert für `Appointment.specialty` enthalten, im Suchergebnis enthalten sein. Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Appointment-service-type
Appointment	date	SHALL	Beispiel: `GET [base]/Appointment?date=2022-12-10T09:00:00Z` Anwendungshinweis: Die Suche wird gegen das Element `Appointment.start` ausgewertet. Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Appointment-date
Appointment	slot	SHALL	Beispiel: `GET [base]/Appointment?slot=Slot/ISiKSlotExample` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Appointment-slot
Appointment	actor	SHALL	Beispiel: `GET [base]/Appointment?actor=Patient/ISiKPatientExample` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/Appointment-actor
HealthcareService	_id	SHALL	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.	http://hl7.org/fhir/SearchParameter/Resource-id
HealthcareService	_tag	SHALL	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.	http://hl7.org/fhir/SearchParameter/Resource-tag
HealthcareService	_count	SHALL	Beispiel: `GET [base]/[Resourcetype]?_count=100` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation, Abschnitt Page Count.
HealthcareService	_has	MAY	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.
HealthcareService	active	SHALL	Beispiel: `GET [base]/HealthcareService?active=true` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/HealthcareService-active
HealthcareService	service-type	SHALL	Beispiel: `GET [base]/HealthcareService?service-type=http://example.org/fhir/CodeSystem/ScheduleServiceType\|CT` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/HealthcareService-service-type
HealthcareService	specialty	SHALL	Beispiel: `GET [base]/HealthcareService?specialty=urn:oid:1.2.276.0.76.5.114\|535` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/HealthcareService-specialty
HealthcareService	name	SHALL	Beispiel: `GET [base]/HealthcareService?name=Medizinische Behandlungseinheit Des Fachbereichs 0100` Anwendungshinweis: Weitere Details siehe FHIR-Kernspezifikation.	http://hl7.org/fhir/SearchParameter/HealthcareService-name

(Reverse-)Include

RessourcenTyp

table

Schedule

Slot

Slot:schedule (MAY)

Appointment

Appointment:slot (MAY)

Appointment:actor (MAY)

HealthcareService

Schedule:actor (MAY)

Appointment:actor (MAY)