Abbildung einer Fachpersonal&Raum Planung (Kommentierung Stufe 3)
f-peverali opened this issue · 7 comments
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.
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
@jcaumann spricht für Dich etwas dagegen für den geschilderten Fall die Slot zu Schedule Bindung zu lockern?
Für die meistens Clients würde dies bedeuten, dass sie die Slots auflösen müssen um zu sehen, welcher Slot für sie potentiell relevant ist. Ursprünglich waren mehrere Slots nur dafür gedacht, einen Termin der über mehrere Slots verteilt ist abzubilden. Den Use Case unterstütze ich. Es klingt fast danach als müsste man an die Slot-Referenz eine Extension hängen um zu sagen, in welcher Relation diese stehen. Eine weitere Herausforderung ergibt sich dadurch, dass der Termin im Behandler- als auch Raum-Kalender sich über mehrere Slots erstrecken kann.
Ich kann verstehen, dass es unhandlich ist beide Fälle als zwei Appointments abzubilden. Dies wäre jedoch gerade der Workaround.
was spricht denn dagegen, nur den Constraint fallen zu lassen, dass die Slots zu einem Appointment aus demselben schedule kommen müssen? Wenn zB ein MRT-Termin gebucht wird, dann wird da ein Slot aus dem Geräte-Kalender und ein Slot aus dem Befunder-Kalender dran gebunden. Wichtig ist doch vor allem, dass über die Status der Slots jederzeit in den Kalendern ermittelbar ist, wo noch freie Zeiten sind. Da sehe ich das Problem mit dem Vorschlag der 2 Appointments. Wenn ein Termin abgesagt wird, muss ich beide Appointments anfassen und die daran hängenden Slots wieder freigeben. Der Patient sieht aber protenziell nur ein Appointment, dh wenn er dadrauf eine Absage schickt, dann muss irgendeine Logik dafür sorgen, dass auch die Slots an dem anderen Appointment wieder freigegeben werden. Da sehe ich viel Fehlerpotenzial.
Das von @alexzautke skizzierte Problem mit der Slot-Semantik halte ich in dem Szenario für potenziell immanent, d.h. das wird sich nicht vermeiden lassen, dass man da eine Business-Logik in der Bindung von Slots und Appointment anwenden muss.
In dem Beispiel mit dem MRT brauche ich zB eine Business-Regel, wie aus den Slots start und end Elemente in dem Appointment gesetzt werden, das dem Patienten zB im Patientenprotal angezeigt wird:
- für den Patient ist nur relevant, wann er im MRT liegt; die Befundung passiert später und wird separat organisiert. Im Appointment sind damit die Zeiten aus dem Slot aus dem MRT-Kalender.
- direkt nach der Aufnahme erfolgt die Befundung, damit der Patient den Bericht gleicht mitnehmen kann. start im Appointment ist der Start des Slots aus dem MRT-Kalender und end im Appointment ist das Ende des Slots aus dem Befunder-Kalender.
Will sagen: Wenn wir Abbildungen von Terminen (ob 1 oder 2 Appointments) auf 2 Kalender zulassen, dann wird sich das IT-System an irgendeiner Stelle mit der Semantik des Zusammenspiels der Kalender rumschlagen müssen. Dann können wir aus meiner SIcht auch die einfachste Lösung nehmen und einfach zulassen, dass ich an ein Appointment Slots aus mehreren Kalendern binden kann. Für den Patienten ist dann nur wichtig, dass start und end im Appointment richtig gesetzt werden, da das vermutlich doch das einzige ist, was er vom Appointment sieht; die Slots sind dann eher nur intern sichtbar und für das Ressourcenmanagement.
Insbesondere wenn man mit virtuell Slots arbeitet (d.h. Slots die erst vollständig generiert werden, sobald der Slot angefragt wird) ist die Anfrage potentiell Ressourcen-intensiv. Ich bin dabei wenn es darum geht den Constraint fallen zu lassen. Meine Anmerkung zielte darauf ab, dass wir vielleicht nochmal nachdenken sollten wie man dem Client das Leben hier einfacher machen kann. Gut möglich, dass der Client mit dieser Komplexität klarkommen muss.
Im Fazit kann die Änderung vorgenommen werden: "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."
Weitere Lösungen würde ich im Rahmen der Ausbaustufe 4 angehen wollen.
Ok