Ankündigung des neuen Terminsuchemodells

Seit einiger Zeit entwickeln wir nun an einem neuen Terminsuchemodell - teilweise auch als das neue Ressourcenmodell bezeichnet. Dieses möchten wir Ihnen gerne in diesem Beitrag vorstellen. Sollten Sie zu gewissen Punkten Anmerkungen haben, kommentieren Sie gerne unseren Beitrag.

 

Die Entwicklungen fanden hauptsächlich aus zwei Gründen statt:
1. Unsere bisherige Logik unterscheidet sich in einigen Punkten von der Herangehensweise anderer Hersteller. Dies führte in Praxen immer wieder zur Verwirrung und recht unvorteilhaften Konfigurationen.
2. Aufgrund der anderen Logik, waren in vielen Fällen sogenannte Subterminsuchen nötig. Dieser Workaround wurde von vielen von Ihnen als sehr komplex wahrgenommen.


Wir haben uns Ihr Feedback zu Herzen genommen und nach der für Sie optimalen Lösung gesucht. Der Fokus lag hierbei auf der Anpassung und Verallgemeinerung der Begriffe, sowie die Vereinfachung der Konfiguration. (vor allem in komplexen Fällen)


Um die Umstellung für Sie so einfach wie möglich zu halten, wird es eine Übergangzeit geben, in der beide Modelle parallel laufen. Perspektivisch möchten wir uns auf das neue Modell beschränken. Ab wann dies der Fall sein wird, ist zum aktuellen Zeitpunkt nicht entschieden.

 

Bezeichnungsanpassungen

Im Kern der Umbenennungen steht der Fakt, dass insbesondere die Begriffe/Funktionen Kalender und Ressourcen häufig verwechselt bzw. anders als eigentlich gedacht verstanden/genutzt wurden. Kalender werden oft für etwas verwendet, was in Ihrem Jargon eher einer Ressource entspricht - für Ärzte, MFAs, Geräte oder Räume - und Ressourcen eher für etwas, das einem Zeitraum entspricht, in dem bestimmte Tätigkeiten/Behandlungen stattfinden können.

 

Entsprechend dessen werden die Bezeichnungen ihrer häufigen Verwendung angepasst. Kalender werden von nun an in Ressourcen umbenannt. Statt jeweils einen Kalender für Arzt A, Arzt B, Arzt C zu haben, sind diese nun also jeweils als Ressourcen zu verwalten. Ressourcenblöcke - also Ressourcen in der realisierten Form im Kalender über die Schemaverwaltung - werden in Verfügbarkeiten umbenannt, da sie die Verfügbarkeit einer Ressource in einem Zeitraum angeben. Ressourcenarten hingegen werden zu Funktionalitäten, da sie darstellen, in welcher Funktion eine Verfügbarkeit vorliegt.

Beispiel eine Ressource für Arzt A, in welcher z.B. Verfügbarkeiten von 8-13 und 14-17 in der Funktionalität Arzt (oder genauer Arzt-OP oder Arzt-Sprechstunde) liegen.
 

Änderungen an der Terminsuche

Die Hauptsächliche Änderung in den Terminsuchen besteht darin, dass die nötigen Funktionalitäten (Ressourcenarten im früheren Sinn) nicht mehr durch die Terminsuche, sondern die Terminart bestimmt werden. Wenn man vorher also eine Suche über die Kalender (oder-Verknüpft) MFA A und Arzt A mit den Ressourcen MFA und Arzt getätigt hat, um gleichzeitig die MFA und den Arzt für den Termin bereit zu haben, der würde nun weiterhin über die beiden Kalender suchen, aber in seiner Terminart entsprechend MFA und Arzt als Anforderungen einstellen.
Beispiel Anforderung: Für die Terminart „Check-Up“ benötige ich sowohl 1 MFA als auch 1 Arzt.


 

Dies ist insbesondere dann relevant, wenn man eine beliebige MFA und einen beliebigen Arzt haben will. Bisher erforderte dies Subterminsuchen, kann jedoch nun einfach darüber gelöst werden, dass alle MFA-Kalender und alle Arzt-Kalender ausgewählt werden, aber die Terminart nur eine MFA und einen Arzt braucht.
Die Konfiguration der nötigen Anforderungen findet entsprechend im Terminarten-Verwaltungsfenster statt:

Altes Modell



Neues Modell

Hier, als Beispiel, mit einer Terminart, welche 2 MFAs, einen OP-Arzt und einen OP-Raum braucht und zusätzlich auch noch eine MFA in der Ausbildung zulässt.

Die Anforderungen bauen sich entsprechend aus zwei Arten von Einträgen zusammen. Es gibt die Funktionalitätseinträge, welche eine konkrete Funktionalität samt ihrer Anzahl angeben (2 MFA’s, 1 OP-Arzt und 1 OP-Raum), und die Blockeinträge, welche untergeordnete Einträge haben und welche jeweils aussagen, dass entweder alle diese Einträge gegeben sein müssen oder nur einer. (2 MFA’s, 1 OP-Arzt und 1 OP-Raum müssen erfüllt sein. Es kann 1 MFA in Ausbildung teilnehmen ODER keine)

Die simpelste Konfiguration für mehrere beliebige Zusammenstellungen an möglichen Anforderungen ist in diesem Fall zum Beispiel, einen „Eine der Anforderungen“-Block zu verwenden und diesen für jeden Anforderungssatz mit einem „Alle der Anforderungen“-Block zu füllen.

 

Ein Nebeneffekt von dieser Umstellung ist, dass die Einzelsuchen im Terminsuchefenster keine Ressource mehr zur Auswahl haben, sondern anhand der ausgewählten Terminart automatisch die Anforderungen bestimmen. Hierdurch sind entsprechend auch komplizierte Suchen ohne definierte Terminsuche möglich.
 

Umstellung auf das neue Modell

Um die Umstellung auf das neue Terminsuchemodell zu erleichtern, wurde ein Migrationsassistent erstellt. Dieser soll Ihnen helfen, Ihre Terminsuchen möglichst unverändert zu lassen, jedoch ist es hierfür nötig, Ihre Terminarten entsprechend anzupassen. Wenn man vorher zwei verschiedene Suchen für die gleiche Terminart hatte, welche aber verschiedene Ressourcen brauchten, so ist es nicht möglich deren Ressourcenanforderungen in die Anforderungen der Terminart zu übertragen. Die beiden Suchen würden sich fundamental ändern, da sie nun die Anforderungen der jeweils anderen Suche akzeptieren würden. Entsprechend müssen in solchen Fällen die Terminarten aufgespalten werden, sodass Sie möglicherweise im Anschluss eine Suche pro Terminart haben.

Dargestellt wird das auf diese Art und Weise im Migrationsassistenten:

Linksseitig im Migrationsassistenten sehen Sie ihre bestehenden Terminarten - die rot gekennzeichneten besitzen Terminsuchen mit verschiedenen Ressourcenanforderungen und wurden entsprechend vom Assistenten aufgespalten. Durch die Öffnung dieser können Sie entsprechend die Details der Aufspaltung betrachten. An dieser Stelle ist es auch möglich, die Terminart nicht so weit aufzuspalten, wie es unser Assistent vorschlägt, indem man die Ergebnisse wieder vereinigt - hierdurch ändern sich jedoch möglicherweise die Ergebnisse Ihrer Suchen.

 

Es muss angemerkt werden, dass das neue Modell den Fall nicht unterstützt, dass man über Subterminsuchen entscheidet, aus welchen Kalendern bzw. in welchen Zeiträumen bestimmte Ressourcen genommen werden dürfen, da die nötigen Ressourcen durch die Terminart der Obersuche bestimmt werden und entsprechend nicht in den Subterminsuchen angepasst werden können. Ausbesserungs- und Erweiterungsmöglichkeiten für diese Fälle sind in Planung, jedoch bisher noch nicht konkret genug, um weitere Aussagen darüber zu treffen.

Subterminsuchen als solches werden jedoch weiterhin unterstützt.

Wir freuen uns auf Ihr Feedback!

Beste Grüße
Ihr Kalender-Team 

Gefragt in Anderes von (1.2k Punkte)
0 Punkte
Das klingt sehr vielversprechend.

Bedeutet aber auch, dass man sich erstmal intensiv damit auseinandersetzen muss. In der Übergangszeit wäre es schön, wenn man schnell wieder zur alten Konfiguration switchen könnte, falls es am Anfang noch nicht wie gewünscht läuft. Dann hätte man erstmal ein System, mit dem sich alle Mitarbeiter auskennen. Ich denke, dass insgesamt die Vorteile überwiegen, es ein großer Fortschritt ist und freue mich schon darauf.

3 Antworten

Das klingt sehr interessant. Ändert das in der Terminkettensuche was?
Beantwortet von (11.2k Punkte)
0 Punkte
Guten Tag Herr Dr. Sirfy,

Terminkettensuchen bleiben an sich so wie sie sind - nur die dafür genutzten Terminsuchen funktionieren entsprechend anders.

Mit freundlichen Grüßen,

Toni Ringling
Hmmm, es ist erstmal einiges an Umdenken nötig. Und das v.a. bei den MFAs, die die Termine suchen. Mal sehen... Wann wäre es als Beta zum testen da?

Eine andere Frage möchte mir aber nicht verkneifen - wann gibt es denn Möglichkeit im Kalender/neu: Resource bestimmte Zeitabschnitte (und nicht nur ganze Tage) zu sperren??? Dies wurde schon mehrfach im Forum abgefragt/diskutiert und darauf warten wir seit langem sehensüchtig...
Beantwortet von (1.3k Punkte)
+2 Punkte

Zur zweiten Frage: Nach aktueller Planung mache ich die Überarbeitung der Urlaubstageverwaltung bereit für deren Beta-Phase (da sollte bis Jahresende noch eine Ankündigung von mir kommen) und solange mir keine neuen Themen/Probleme auf den Tisch kommen folgt die Erweiterung der Terminart-Rechteverwaltung auf das Legen von Terminen außerhalb von beliebigen Ressourcen(neu: Verfügbarkeiten), außerhalb passender Ressourcen(neu: Verfügbarkeiten) und parallel zu bestehenden Terminen(neu: ... ach ne weiter Termine).

Das könnte dann also frühestens die erste Version nach dem Quartalsupdate klappen. Das wäre dann also voraussichtlich die 121.

Das Konzept hört sich gut an. Um es richtig zu verstehen und beurteilen zu können, müsste man es mal testen.

Ab welcher Version wird man umstellen können?
Beantwortet von (16.6k Punkte)
0 Punkte
Guten Tag Herr Dr. Stenger,

die Umstellung ist momentan nur für zollsoft-Mitarbeiter möglich, aber nicht erwünscht. Wir wollten hier eigentlich erstmal grob einschätzen, ob es an sich schwere Kritik an dem neuen System gibt, bevor die tatsächliche Form an die Öffentlichkeit kommt. Wenn es erstmal in der Wildbahn ist, wird es schwer sein, es wieder verschwinden zu lassen.

Wir überlegen aber noch, ob es irgendeine plausible Möglichkeit gibt, das zum Test anbieten zu können.

Mit freundlichen Grüßen,

Toni Ringling
Ok. Das Problem für mich, wahrscheinlich aber für viele andere ist, dass sich das Konzept gut liest, man aber auch nicht direkt alles versteht und sich eventuelle "Probleme" und damit Verbesserungswünsche erst bei der Anwendung ergeben.

Vielleicht ist es möglich das ganze auf einem tomedo-Testserver auszuprobieren, auf den jeder zugreifen kann?
Ich sehe es ähnlich wie Herr Stenger - eine Möglichkeit zum testen in unseren Alltagssituationen ist fast unerlässlich, um es beurteilen zu können. Die bisherige Lösung klang ja auf dem Papier auch nicht schlecht. Die Probleme/Einschränkungen kommen fast immer erst im Einsatz heraus...
12,010 Beiträge
18,846 Antworten
31,421 Kommentare
6,395 Nutzer