gematik / spec-isik-terminplanung

The ISiK module "Appointment Scheduling" (Terminplanung) provides FHIR resources as a specification, examples and an implementation guide. The resources allow the following task processing: Retrieval of images of available partial and full inpatient treatment services by a hospital, query of appointments and availabilities, booking management of available appointments, notifications of appointment changes as well as creation of a new patient in the appointment-keeping system (transmission of patient/insurance information).

ISiK-Terminplanung

Table of Contents

1. About The Project
   • Release Notes
2. License
3. Contact

About The Project

For full information and details, see Simplifier Project Page for ISiK Terminplanung Stufe 3

Overview Versions

For overview on preceding versions , see ISiK Terminplanung.

Release Notes

See ReleaseNotes.md for all information regarding the (newest) releases.

License

Copyright 2024 gematik GmbH

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.

See the APACHE_LICENSE.md for the specific language governing permissions and limitations under the License.

Unless required by applicable law the software is provided "as is" without warranty of any kind, either express or implied, including, but not limited to, the warranties of fitness for a particular purpose, merchantability, and/or non-infringement. The authors or copyright holders shall not be liable in any manner whatsoever for any damages or other claims arising from, out of or in connection with the software or the use or other dealings with the software, whether in an action of contract, tort, or otherwise.

The software is the result of research and development activities, therefore not necessarily quality assured and without the character of a liable product. For this reason, gematik does not provide any support or other user assistance (unless otherwise stated in individual cases and without justification of a legal obligation). Furthermore, there is no claim to further development and adaptation of the results to a more current state of the art.

Gematik may remove published results temporarily or permanently from the place of publication at any time without prior notice or justification.

Contact

Team Data – ISiK and ISiP

For issues and requests please refer to: https://service.gematik.de/servicedesk/customer/portal/16

spec-isik-terminplanung's Issues

Mocked ValueSets austauschen

Maintenance

• SUSHI Version erhöhen
• Validierungsfehler prüfen
• Use slice name instead of numeric index access
• Fix eventual errors

Falscher link ISiKMedizinischeBehandlungseinheit (HealthcareService)

Der Link https://simplifier.net/guide/isik-terminplanung/I-markdown-Datenobjekte-ISiKMedizinischeBehandlungseinheitHealthcareService?version=current im Titel zeigt auf die falsche Seite http://hl7.org/fhir/communication.html. Korrekt sollte hier https://hl7.org/fhir/R4/healthcareservice.html sein.

Tasks

Beta Give feedback

1. Stufe 2
2. Stufe 3

ist ein 2-Stunden-Slot realistisch? ich würde als Ende in dem Beispiel besser 2022-12-10T09:30:00Z verwenden. (es sei denn, dass derselbe Slot auch als Beispiel für die Slot-Ressource verwendet wird und da wirklich auf 2 Stunden gesetzt ist).

          ist ein 2-Stunden-Slot realistisch? ich würde als Ende in dem Beispiel besser 2022-12-10T09:30:00Z verwenden. (es sei denn, dass derselbe Slot auch als Beispiel für die Slot-Ressource verwendet wird und da wirklich auf 2 Stunden gesetzt ist).

Originally posted by @jcaumann in #93 (comment)

Fallbezug bei einer Terminvereinbarung

Als Primärsystemhersteller muss ich nach einer Terminvereinbarung wissen, welchen Fallbezug dieser dann haben wird.

• Es wurde eine Lösung erarbeitet, wie mit einem Termin ohne Fallbezug umgegangen wird.
• Es wurde eine Lösung erarbeitet, wie ein Fallbezug im Nachgang mit einem bestehenden Fall hergestellt werden kann.

Präzisieren der Anforderung für Encounter

spec-ISiK-Terminplanung/ImplementationGuide/markdown/Datenobjekte/ISiKTerminKontaktMitGesundheitseinrichtung.md

Line 7 in 75c4931

Das Datenobjekt ISiKKontaktMitGesundheitseinrichtung dient der Verknüpfung des ISiK-Basis-Encounters (ISiKKontaktGesundheitseinrichtung) mit einem Termin (Appointment) und - darauf aufbauend - der Dokumentenkommunikation.

hier noch genauer klären:
-Welches System stellt die Verknüpfung her?
-Wie wird die Verknüpfung hergestellt?

ISiKKalender erstellen

• active 1..1 MS
• serviceType 1..* MS extensible binding auf TBD ValueSet
• specialty 1..* MS: Slice 1..1 MS mit required binding auf https://simplifier.net/basisprofil-de-r4/ihexdsauthorspeciality
• actor 1..* MS: type
  • reference.display 1..1 MS
  • slice mit Reference(Practitioner or HealthcareService) mit reference.reference 1..1 MS
• extension[Name] 0..1 mit valueString 1..1 MS

ISiKTermin erstellen

• meta.tag 0..* MS mit slice auf TBD HL7 CodeSystem für internal/external
• identifier 0..* MS
• status 1..1 MS (proposed | booked | fulfilled | cancelled | entered-in-error | noshow)
• cancellationReason 0..1 MS required binding auf (pat | prov | maint | meds-inc | other)
• priority.extension 0..1 MS mit valueCodeableConcept extensible binding auf intensionales ValueSet mit diese Children: https://browser.ihtsdotools.org/?perspective=full&conceptId1=272125009&edition=MAIN/2022-02-28&release=&languages=en
• serviceType 1..* MS mit extensible binding auf TBD ValueSet
• specialty 1..* MS: Slice 1..1 MS mit required binding auf https://simplifier.net/basisprofil-de-r4/ihexdsauthorspeciality
• start 1..1 MS
• end 1..1 MS
• slot 1..* MS
• comment 0..1 MS
• patientInstruction 0..1 MS
• extension[PatientComment] 0..1 MS valueReference auf ISiKCommunication
• participant 1..* MS
• participant.actor 1..1 MS
• participant.status 1..1 MS
• constraint 1: start <= end

CapabilityStatement ist unvollständig

Die Terminplanungs-Profile verwenden auch die Patient- und Practitioner-Profile aus ISiK Basis.
Diese Profile sollten im CapabilityStatement von ISiK Terminplanung ebenfalls aufgeführt sein.

Angrenzung SMART on FHIR: Bereitstellung von Slots nur für Vertragspartner

Appointment.serviceType Kardinalität revert

Appointment.serviceType sollte wieder die Kardinalität "1..*" und "MS" erhalten (entspricht Status quo Stufe 2).
Dazu Beschluss in synchronem Meeting; siehe auch Diskussion in #72.

Testarchitektur für das Modul Terminvereinbarung

Als Entwickler vom Titus-Testsystem möchte ich wissen, wie die Testarchitektur für das Modul Terminvereinbarung aussehen könnte, um zu entscheiden, welche Funktionalitäten für das Titus-System entwickelt werden müssen.

AC:

• Die möglichen Architekturen wurden skizziert.

• Die dazugehörigen Sequenzdiagramme wurden skizziert.

ISiKSlot erstellen

• schedule 1..1 MS
• status 1..1 MS
• start 1..1 MS
• end 1..1 MS
• constraint 1: start <= end

ISiKNachricht erstellen

• subject 1..1 MS Referenz auf ISiKPatient
• recipient 1..* MS
• payload 1..* MS

HTTP Code definieren?

spec-ISiK-Terminplanung/Resources/input/fsh/ISiKBookOperation.fsh

Line 44 in c38e9ea

* documentation = "Als Return-Parameter MUSS ein Appointment oder ein OperationOutcome zurückgegeben werden. Das id-Element der Ressource MUSS korrekt gefüllt werden. Der Status der Appointment-Ressource muss auf 'booked' oder 'pending' geändert werden. Der Server MUSS die verwendeten Slot-Ressourcen als Referenz im Appointment angeben. Im Falle dass die Terminbuchung grundsätzlich akzeptiert wird, d. h. der neue Status 'booked' oder 'pending' ist, MUSS das Appointment persistiert werden."

1. Momentan bleibt undefiniert, was im erfolgsfall als HTTP-Code zurückzugeben ist.

@alexzautke was sagst Du? Fehlt hier ggf. 200 oder 201?

2. Für den Bad request muss gf. auch nachgebessert werden - siehe folgenden Hinweis (von @alexey-tschudnowsky ):

Terminplanung: "Invalide Appointment-Ressourcen MÜSSEN mit einer OperationOutcome und dem Status Code HTTP 400 - Bad Request abgewiesen werden"

Basismodul:
"Falls die im Dokumenten-Bundle enthaltene Patient-Ressource und/oder Encounter-Ressource nicht anhand der Business-Identifier oder anderer Matching-Kriterien im empfangenden System gefunden werden kann (d.h. der Patient oder der Encounter existiert im empfangenden System noch nicht), MUSS als Antwort der HTTP Status Code "422 - Unprocessable Entity" zurückgegeben werden."

-> ggf. wäre 422 auch bei der Terminplanung zutreffender (ggf. ein Breaking Change, hat daher Zeit und sollte diskutiert werden)

💡 [REQUEST] - Termine verschieben

Target Date

06 2024

Implementation PR

No response

Reference Issues

No response

Summary

In der Spezifikation https://simplifier.net/guide/isik-terminplanung-v3/ImplementationGuide-markdown-Datenobjekte-Operations?version=current steht zum Thema Termine verschieben der folgende Absatz:

"Für die vorliegende Spezifikation ist die Verschiebung eines Termin eins zwei-stufiger Prozess, bei dem ein Termin storniert und ein neuer Termin neu gebucht wird. Dieser Parameter repräsentiert die Ressourcen-Id des stornierten Appointments. Der uri-Parameter kann eine absoulte URL enthalten, Server SOLLEN jedoch nur Termine für ihre eigene Domäne verwalten. Im neu-angelegten Appointment MUSS eine Reference auf den abgesagten Termin hinterlegt werden (vgl. Appointment.extension:replaces). Der Status der abgesagten Ressource MUSS durch den Server angepasst werden."

Es wäre besser wenn die Möglichkeit geschaffen wird, Termine auch über eine Aktualisierung der Appointment Ressource zu verschieben. Diese Funktionalität ist aktuell verboten:

https://simplifier.net/guide/isik-terminplanung-v3/ImplementationGuide-markdown-Datenobjekte-Operations?version=current#aktualisierung-absage-eines-termins.

Leider lässt sich im Implementierungsleitfaden keine Begründung finden, warum eine Terminverschiebung immer ein zweistufiger Prozess sein muss. Es kann passieren das die Stornierung erfolgreich funktioniert, die Neu-Anlage dann aber nicht mehr funktioniert. Egal in welcher Reihenfolge die Verschiebung erfolgt besteht immer das Risiko ein Inkonsistenz. Erfolgt die Verschiebung über ein Update der Appointment Ressource ist das ausgeschlossen.

Common Examples

Termin durch den Patienten verschieben und Inkonsistenz vermeiden.

Drawbacks

aktuell keine bekannt

Unadressed questions

No response

Meta.tag bei Appointment status 'accepted'

https://github.com/gematik/spec-ISiK-Terminplanung/blob/39823ab3d1a842ec281e93e48f34ed7acf374253/ImplementationGuide/markdown/Datenobjekte/ISiKTerminAppointment.md?plain=1#LL55C93-L55C196

Falls das Datenobjekt dauerhaft in das Termin Repository gespeichert wird, MUSS der Tag entfernt werden

-> Sollte das mit einer accept-Antwort durch das Termin-Repository i.d.R. schon geschehen sein? Dann ggf. hier so formulieren und die Beispiele in Operations.md anpassen.

@jcaumann , was denkst Du?

Java Validation Error untersuchen

Der letzte verbleibende Validation Error stammt aus dem Java Validator:

*FAILURE*: 1 errors, 2 warnings, 3 notes
  Error @ Appointment (line 1, col2): Appointment.specialty:Fachrichtung: minimum required = 1, but only found 0 (from https://gematik.de/fhir/ISiK/v2/StructureDefinition/ISiKTermin)
  Information @ Appointment.specialty[0] (line 28, col6): This element does not match any known slice defined in the profile https://gematik.de/fhir/ISiK/v2/StructureDefinition/ISiKTermin
  Information @ Appointment.specialty[0] (line 28, col6): None of the codings provided are in the value set 'Practice Setting Code Value Set' (http://hl7.org/fhir/ValueSet/c80-practice-codes), and a coding is recommended to come from this value set) (codes = urn:oid:1.2.276.0.76.5.114#010)
  Information @ Appointment.specialty[0].coding[0] (line 30, col10): Code System URI 'urn:oid:1.2.276.0.76.5.114' is unknown so the code cannot be validated
  Warning @ Appointment.serviceType[0] (line 18, col6): The system "" http://terminology.hl7.org/CodeSystem/service-type was found but did not contain enough information to properly validate the code (mode = example) (from http://tx.fhir.org/r4)
  Warning @ Appointment.serviceType[0].coding[0] (line 20, col10): The system "" http://terminology.hl7.org/CodeSystem/service-type was found but did not contain enough information to properly validate the code (mode = example) (from http://tx.fhir.org/r4) for 'http://terminology.hl7.org/CodeSystem/service-type#1'

$book-Response (Kommentierung Stufe 3)

Zu erwägen ist Änderung des Return-Values von Bundle des Typs "searchSet" (möglicherweise zu Appointment).

FYI @markus020 , @jcaumann , @alexzautke

Ursprüngliche Anfrage:

Als Antwort für die $book-Operation wird ein Bundle vom Typ Search-Set als Rückgabe gefordert. Das führ zu Problemen, da dieses Bundle zusätzlich persistiert werden muss. Darüber hinaus erschließt sich der Sinn eines Searchset-Bundles nicht. Hier könnte eine Parameter-Ressource oder sogar nur eine Appointment bzw. OperationOutcome Ressource zurückgegeben werden. Diese kann dann unmittelbar abgerufen werden.

Auch das Beispiel scheint eine Parameter-Ressource im Bundle zu enthalten.

---

bei der Rückgabe macht dieses Tag aber eigentlich keinen Sinn, da der Empfänger hier aus dem "external" keine Information ziehen kann. Oder etwas doch?

          bei der Rückgabe macht dieses Tag aber eigentlich keinen Sinn, da der Empfänger hier aus dem "external" keine Information ziehen kann. Oder etwas doch?

Originally posted by @jcaumann in #93 (comment)

Vorschlag: Der Termin-Requestor KANN durch die Abfrage aller verfügbaren Kalender anschließend alle diesen Kalendern zugeordnetem Slot-Ressourcen abfragen und über diese dann die eigentliche Terminsuche und -buchung ausführen.

          Vorschlag: Der Termin-Requestor KANN durch die Abfrage aller verfügbaren Kalender anschließend alle diesen Kalendern zugeordnetem Slot-Ressourcen abfragen und über diese dann die eigentliche Terminsuche und -buchung ausführen.

Originally posted by @jcaumann in #93 (comment)

Broken link Konformitätserklärung (CapabilityStatement)

Auf der Seite https://simplifier.net/guide/isik-terminplanung/ImplementationGuide-markdown-Datenobjekte-CapabilityStatement?version=current findet sich bei

Erfüllung der Mindestanforderungen des [Moduls "Basis"](https://simplifier.net/guide/ImplementierungsleitfadenISiK-> Basismodul/Einfuehrung) erfoderlich:

ein broken link.

Tasks

Beta Give feedback

1. Stufe 2
2. Stufe 3

sollte bei einem gebuchten und bestätigten Termin nicht auch der Leistungserbringer - oder alterativ der HealthcareService - angegeben sein? Das würde es zumindest verständlicher machen.

          sollte bei einem gebuchten und bestätigten Termin nicht auch der Leistungserbringer - oder alterativ der HealthcareService - angegeben sein? Das würde es zumindest verständlicher machen.

Originally posted by @jcaumann in #93 (comment)

Example buggy

1. ISIKTermin-Example --> ggf. keine Änderung, da Illustrativ
2. ISiKKalenderExample -> DONE -- specialty set
3. HealthcareService-ISiKMedizinischeBehandlungseinheitExampl

spec-ISiK-Terminplanung/Resources/fsh-generated/resources/Appointment-ISiKTerminExample.json ----------------------------------------------------------------------------------------------------------------------------------------------
2023-03-24T10:31:55.5820500Z FAILURE: 4 errors, 1 warnings, 3 notes
2023-03-24T10:31:55.5821598Z Error @ Appointment.participant[0] (line 53, col6): Slicing cannot be evaluated: Problem evaluating slicing expression for element in profile https://gematik.de/fhir/isik/v2/Terminplanung/StructureDefinition/ISiKTermin path Appointment.participant[0] (fhirPath = true and (actor.resolve() is HealthcareService)): The URL 'Patient/example' is not known to the FHIR validator, and has not been provided as part of the setup / parameters
2023-03-24T10:31:55.5823164Z Error @ Appointment.participant[0] (line 53, col6): Slicing cannot be evaluated: Problem evaluating slicing expression for element in profile https://gematik.de/fhir/isik/v2/Terminplanung/StructureDefinition/ISiKTermin path Appointment.participant[0] (fhirPath = true and (actor.resolve() is Patient)): The URL 'Patient/example' is not known to the FHIR validator, and has not been provided as part of the setup / parameters
2023-03-24T10:31:55.5824806Z Error @ Appointment.participant[0] (line 53, col6): Slicing cannot be evaluated: Problem evaluating slicing expression for element in profile https://gematik.de/fhir/isik/v2/Terminplanung/StructureDefinition/ISiKTermin path Appointment.participant[0] (fhirPath = true and (actor.resolve() is Practitioner)): The URL 'Patient/example' is not known to the FHIR validator, and has not been provided as part of the setup / parameters
2023-03-24T10:31:55.5825728Z Error @ Appointment (line 1, col2): Appointment.specialty:Fachrichtung: minimum required = 1, but only found 0 (from https://gematik.de/fhir/isik/v2/Terminplanung/StructureDefinition/ISiKTermin)

---

spec-ISiK-Terminplanung/Resources/fsh-generated/resources/Schedule-ISiKKalenderExample.json ---------------------------------------------------------------------------------------------------------------------------------------------
2023-03-24T10:31:55.5850341Z FAILURE: 1 errors, 1 warnings, 3 notes
2023-03-24T10:31:55.5850806Z Error @ Schedule (line 1, col2): Schedule.specialty:Fachrichtung: minimum required = 1, but only found 0 (from https://gematik.de/fhir/isik/v2/Terminplanung/StructureDefinition/ISiKKalender)

---

spec-ISiK-Terminplanung/Resources/fsh-generated/resources/HealthcareService-ISiKMedizinischeBehandlungseinheitExample.json ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2023-03-24T10:31:55.5839401Z FAILURE: 1 errors, 1 warnings, 3 notes
2023-03-24T10:31:55.5839945Z Error @ HealthcareService (line 1, col2): HealthcareService.specialty:Fachrichtung: minimum required = 1, but only found 0 (from https://gematik.de/fhir/isik/v2/Terminplanung/StructureDefinition/ISiKMedizinischeBehandlungseinheit)

---

See validation run : https://github.com/gematik/spec-ISiK-Terminplanung/actions/runs/4510207877/jobs/7940886514

Identitäten für die Terminplanung

Als Primärsystemhersteller eines Krankenhausinformationssystem möchte ich wissen, welche Identität (z.B. Belegarzt o. Patient) einen Termin im KIS bucht, um den jeweiligen Prozess im jeweiligen Kontext zu starten.

• Ein Termin ist mit einer Identität verknüpft.

Abbildung einer Fachpersonal&Raum Planung (Kommentierung Stufe 3)

Feature anfrage

-Änderung des IGs für die Ermöglichung von Raum- und Personalkalender, anstatt eines einzigen (generischen?) Kalenders/Zeitplans (Schedule)

Lösung:
-IG Anpassung des zitierten Satzes (s.u.)

Zu Prüfen:
-Implikationen bei Änderung

---

Stammt aus Anfrage während Kommentierung zu Stufe 3 ANFISK-74 von @paylodyban

In der Praxis gibt es viele Planungsszenarien, in denen für einen Termin ein Behandler und ein Raum benötigt wird. Entsprechend gibt es dafür einen Behandler-Kalender und einen Raum-Kalender (insbesondere da sich Behandler Räumlichkeiten teilen).

Aktuell verstehe ich die Spezifikation so, dass dieses Planungsszenario in ISiK nicht abgebildet werden kann.

Quelle: https://simplifier.net/guide/Implementierungsleitfaden-ISiK-Modul-Terminplanung/ImplementationGuide-markdown-Datenobjekte-ISiKTerminAppointment?version=current

Der IG enthält für Appointment.slot diesen Hinweis: Die Referenzierung des Schedules kann durch einen oder mehrere Slots erfolgen. Falls mehrere Slots referenziert werden, MÜSSEN diese den gleichen Schedule referenzieren. Es kann keine Reihenfolge durch die Angabe der Slots abgeleitet werden.

Für die Abbildung einer Behandler&Raum Konstellation ist es notwendig, dass die verwendeten Slots jeweils den Behandler- und Raum-Kalender (also zwei Schedules) referenzieren.

---

FYI @jcaumann

Beispiele erstellen

kein rendering

spec-ISiK-Terminplanung/Resources/input/fsh/ISiKTerminplanungCapabilityStatement.fsh

Line 221 in 75c4931

* rest.resource[=].operation[0].extension.url = $capabilitystatement-expectation

Rendering Issue: warum auf folgender Seite nicht zu sehen? https://simplifier.net/guide/Implementierungsleitfaden-ISiK-Modul-Terminplanung-Stufe-3/ImplementationGuide-markdown-Datenobjekte-CapabilityStatement?version=current

[PTDATA-784]

Ermittlung fehlender Slots durch den Server

Für die Umsetzung der $book-Operation ist die folgende Vorgabe definiert: "Im Falle dass ein Appointment keine Referenz auf ein oder mehrere Slots enthält, MUSS der Server die benötigten Slots auf Basis der Referenz auf Schedule, sowie dem Start- und Endzeitpunkt im Appointment ermitteln."

FRAGE(N): Das Element "slot" hat die Kardinalität 0..*. Warum reicht hier nicht die Angabe von Start- und Endzeitpunkt? Ist damit gemeint, dass der Server sich einen passenden Slot "bastelt" (zB wenn er keinen findet oder keinen Zugriff auf die entsprechende Datenbank hat) und dann persistiert oder kann der auch inline übertragen werden?

Originally posted by @jcaumann in #90 (comment)

Kardinalität inkonsistent (gerendert) (Kommentierung Stufe 3 -> TC)

Die Kardinalität (bzw. das Rendering in Simplifier) muss korrigiert werden.

---

ursprüngliche Anfrage:

Hier sind drei Slices, wobei der Slice “AkteurPatient” die Kard. 1..* hat. Zusätzlich hat auch das das actor-Element ohne Slice eine Kard. von 1..1. Das ist in sich inkonsistent → besser: participant nur Kard. 1..* und Slice nur bei actor mit AkteurPatient Kard. 1..1 (<- da nur ein Pat. pro Termin?).

Zusätzlich sehen die Slices nur das Element status als Pflicht vor.

---

FYI @markus020

Tasks

Beta Give feedback

1. PTDATA-681

Diese Abfrage liefert alle an den Kalender gebundenen Slots, auch die die nicht verfügbar sind. Die Abfrage nach den VERFÜGBAREN Slots wäre: GET https://example.org/fhir/Slot?schedule=<Schedule/ISiKKalenderExample>&status=free

          Diese Abfrage liefert alle an den Kalender gebundenen Slots, auch die die nicht verfügbar sind. Die Abfrage nach den VERFÜGBAREN Slots wäre: GET https://example.org/fhir/Slot?schedule=<Schedule/ISiKKalenderExample>&status=free

Originally posted by @jcaumann in #93 (comment)

Extension "ISiKKalenderNameExtension" durch Empfehlung der Deutschen Basisprofile ersetzen

Anstatt der Extension ISiKKalenderNameExtension sollte eine Backport-Extension aus FHIR R5 verwendet werden. Siehe Empfehlung der Deutschen Basisprofile: hl7germany/basisprofil-de-r4#493

auch wenn es nur ein Beispiel ist, würde ich hier die NEMA DCM Kodierung nehmen:

          auch wenn es nur ein Beispiel ist, würde ich hier die NEMA DCM Kodierung nehmen:

n diesem Fall ist auch ein Chaining auf weitere verknüpfte Akteure möglich: GET https://example.org/fhir/Slot?schedule.actor:HealthcareService.type=http://dicom.nema.org/resources/ontology/DCM|CT

Originally posted by @jcaumann in #93 (comment)

Operation für die Buchung erstellen

Abruf von Behandlungsleistungen

Was ist gemeint mit
"Abruf von Abbildungen von verfügbaren teil- und voll- stationären Behandlungsleistungen durch ein Krankenhaus" ?
hier https://github.com/gematik/spec-ISiK-Terminplanung/blob/master/ImplementationGuide/markdown/Motivation.md
Vermutlich Typo und einfach:

"Abruf von verfügbaren teil- und voll- stationären Behandlungsleistungen durch ein Krankenhaus"

Beschreibung zu ISiKTermin.serviceType im IG hinzufügen

• Im Zuge dessen auch den Mock entfernen

TC 2 Hotfix innerhalb der Stufe 2 - Encounter

          Ok, dann schreit das nach Hotfix innerhalb der Stufe 2.

Vorschlag: ich erstelle asap ein Pull Request und würde das in zulip zur Diskussion stellen mit nachträglicher Kommentierungsphase.

@AnsgarHoeper FYI -> gibt es hier Bedenken deinerseits zu Vorgehen / Verfahren? WÜrde das in jedem FAll in Ruhe mit dir Abstimmen.

Zur Änderung:

Ich würde im Prinzip das ISiKKontaktGesundheitseinrichtung aus der Basis nachbauen, nur mit o.g. Anpassung
@alexzautke Fallen Dir Elemente auf, die darüber hinaus angepasst werden müssten?
mir auf Anhieb nichts weiter, außer dass ich die Änderung hier gematik/spec-ISiK-Basismodul#65 dann möglichst direkt umsetzen würde.

FYi @jcaumann

Originally posted by @f-peverali in #60 (comment)

Appointment.specialty auf 0..1 MS statt 1..1 (Kommentierung Stufe 3)

Hintergrund hier:

• Meldung von Performance-Problemen bei Implementierung
• Notwendigkeit der Angabe einer Fachrichtung für ein Appointment (bei Terminvereinbarung) ist nicht ersichtlich

---

@jcaumann hier übertrage ich nochmal deinen Input:

Beispiel:

Ein kleineres Krankenhaus bietet in einer Abteilung verschiedene Leistungen für Kinder an. Über ein Zuweiserportal sollen durch Kinderärzte sowohl Termine für bestimmte Untersuchungen als auch für bestimmte chirurgische Eingriffe gebucht werden können. Hierzu wird ein "schedule" angelegt. Die darin vermerkten "speciality" sind 304 (Kinderchirurgie) und 341 (Kinder- und Jugendmedizin). Als "serviceType" sind die angebotenen Leistungen eingetragen, die im Zuweiserporztal als Auswahlliste für die Terminsuche erscheinen.

Umsetzungsoption 1: In dem Kalender werden sowohl "slots" für chirurgische Eingriffe als auch für die angebotenen Untersuchungen eingetragen. Da hier jeweils andere Ressourcen (Räume, Personal, etc.) dran hängen, hat jeder "slot" immer genau eine "speciality" und als "serviceType" die in diesem "slot" angebotenen Leistungen. Der Kinderarzt wählt im Zuweiserprotal über die im "schedule" aufgelisteten "serviceType" aus, welche Leistung er für seinen Patienten buchen möchte. Anschließend werden die verfügbaren "slot" gesucht, die als "serviceType" die gesuchte Leistung besitzen. Der Kinderarzt wählt einen Termin aus und bucht diesen. Damit wird ein "appointment" angelegt. In diesen werden die "speciality" aus dem "slot" und der ausgewählte "serviceType" übernommen.

Fazit: Wenn Übernahme der "speciality", dann besser aus dem "slot" und nicht aus dem "schedule". Aber: In diesem Beispiel wird die "speciality" überhaupt nicht benötigt und könnte auch weggelassen werden.

Umsetzungsoption 2: Da chirurgische Eingriffe eher selten angefragt werden, werden alle "slots" des "schedule" ohne spezifische Zuordnung von "speciality" und "serviceType" angelegt. Analog zu Umsetzung 1 kann der Kinderarzt im Portal aus den "serviceType" wählen und bekommt eine Liste der freien Slots, aus denen er einen auswählt. Wenn er eine Untersuchung wählt, wird direkt das Appointment mit der "speciality" 341 und dem gewählten "serviceType" angelegt und der Termin gegenüber dem Kinderarzt bestätigt. Wenn ein chirurgischer Termin angefragt ist, erhält der Arzt nur eine Reservierungsbestätigung. Die Anfrage landet im Krankenhaus bei einen Disponenten, der prüft, ob der Termin einrichtbar ist. Erst dann wird das "appointment" angelegt und der einweisende Kinderarzt erhält eine Terminbestätigung (oder einen alternativen Terminvorschlag). Auch hier hat das "appointment" nur eine "speciality" (304) und einen "serviceType".

Fazit: Hier wäre die "speciality" in "schedule" und "slot" noch unwichtiger als in der ersten Umsetzung, da das Setzen der "speciality" im "appointment" nur anhand des gewählten "serviceType" erfolgt und eigentlich nur erforderlich ist, wenn der automatische Workflow weiterläuft und z. B. irgendwelche Ressourcenplanungen aus der "speciality" des "appointment" abgeleitet werden.

Gesamtfazit: Wenn das ein typischer UseCases ist, dann wäre bei "speciality" durchgängig eigentlich "0..*" passender und das "MS" wäre eher fraglich. Auch braucht man dann eine Abfrage nach "serviceType" auf "slot", die aktuell nicht vorgeschrieben ist.

ISiKTerminKontaktMitGesundheitseinrichtung ist im IG nicht unter Datenobjekte aufgeführt (Kommentierung Stufe 3)

Im IG wurde eine Unterseite vergessen. Diese sollte entsprechend dem Template der anderen Seiten unter Datenobjekte hinzugefügt werden.

Link Falsch - inhalt zu klären

spec-ISiK-Terminplanung/ImplementationGuide/markdown/Datenobjekte/ISiKMedizinischeBehandlungseinheitHealthcareService.md

Line 61 in c38e9ea

**Hinweis:** Diese Klassifikation sollte stets auch in Appointment.serviceType und Schedule.serviceType angegeben werden. Seitens der aktuellen Spezifikation werden keine Vorgaben bezüglich der zu verwendenden Terminologie gemacht. Entsprechend verwendete Kataloge müssen als CodeSystem- und ValueSet-Ressourcen exponiert werden. Siehe [Suchparameter "content-mode" in ISiK Basis - Datenobjekt ValueSet](https://simplifier.net/guide/implementierungsleitfadenisik-basismodul/ImplementationGuide-markdown-Datenobjekte-Datenobjekte-ValueSet?version=current).

Hier ist offensichtlich ein falscher Link.
Ist auch inhaltlich zu klären. Es gibt keinen content-mode in Datenobjekt Valueset, dafür aber in Datenobjekt Codesystem. Dennoch fraglich, ob das hier richtig wäre.

Entscheidende Frage war hier zunächst in Hinblick auf "Entsprechend verwendete Kataloge müssen als CodeSystem- und ValueSet-Ressourcen exponiert werden" -> wie müssen sie Exponiert werden? Dies auch relevant in Blick auf Testing - auch für das $book-Szenario (FYI @alexey-tschudnowsky ).

Herkunft einer Terminanfrage

Als Primärsystemhersteller eines Krankenhausinformationssystem möchte ich wissen, ob ein Termin von einem internen- oder externen Systems gebucht wurde, um zu verhindern, dass der Patient alle Prozesse (z.B. Prüfung des Versicherungsverhältnisses o. Adresscheck) im KIS durchläuft. Um dies festzustellen, wird ein Termin einen Tag (meta.tag) erhalten, falls dieser extern oder intern erstellt wurde.

Buchungsprozess "pending" (Stufe 3?)

Buchungsprozess - eine Änderung möglich, sodass der Status „pending“ vom KIS gesetzt wird im Falle eines konfigurierten manuellen Bestätigungsprozesses?

Hintergrund:

• Wissen über Regeln von Terminbuchungen sollte nur in einem System vorgehalten - Single Point of Truth - (beim Primärsystem - nicht beim CLient)
• Stand jetzt: Im Falle des Anwendungsszenarios "Manueller Buchungsprozess" muss Client-seitig Wissen vorhanden sein, um derzeitige asynchronous-$book operation ausführen zu können → hier Problem
• Auch mit Custom Operation ggf.

Auch hier dein Hinweis @jcaumann :

SIehe Umsetzungsoption-2 aus #72. Hier würde die Reservierung ein "appointment" mit status "pending" herausgegeben und erst nach der manuellen Freigabe der Reservierung der Status auf "booked" geändert. Somit finde ich den Vorschlag  gut, da das gerade für Patienten- und Zuweiserportale als Clients dann deutlich einfacher umsetzbar ist als die asynchrone "$book"-Operation.