Wir hatten als wir damals mit der Kartei angefangen haben mit insgesamt knapp 20 Ärzten verschiedene Versuche mit den beiden Richtungen gemacht, dabei waren sowohl Ärzte, die durch andere Systeme „vorbelastet“ waren, als auch „frische“ Ärzte. Am Ende war das Ergebnis sehr eindeutig, dass die „antichronologische“ Sortierung die sinnvollere ist. Hauptargument dafür: ALLE befragten Ärzten hatten immer die Vorgehensweise, dass sie sich zuerst die neuesten Einträge des Patienten anschauen und dann „rückwärts“ durch die Historie lesen, bis sie zu einem Punkt kommen, der für die aktuelle Behandlung nicht mehr relevant ist. Bei einer Sortierung wo die neuesten Einträge ganz unten stehen, bedeutet das, dass jeder Arzt immer unten anfängt zu lesen und sich „nach oben“ durchliest, also genau gegen das eigentliche Leseverständnis, wo man ja links oben beginnen würde. Steht der neueste Eintrag ganz unten, muss immer erst nach der „Einstiegsposition“ zum Lesen gesucht werden, d.h. erst wird erst mal alle andere Information die drüber steht überflogen und es dauert länger um die eigentlich relevanten Daten zu erfassen.
Zudem geht bei vielen modernen, Eintrags-basierten Systemen der Trend in die „antichronologische“ Richtung (z.B. Facebook, Youtube, Zendesk, fast alle Kommentarfunktionen in Nachrichtenportalen) sicherlich aus den oben genannten Gründen. Dass in den meisten anderen Arztsystemen die Sortierung von oben nach unten erfolgt, liegt meiner Ansicht nach vor allem daran, dass man seinerzeit auch auf Karteikarten von oben nach unten geschrieben hat (geht ja auch andersrum gar nicht). Wir sind uns hier bislang eigentlich einig, dass die derzeitige Sortierung die bessere ist und zu einer größeren Übersichtlichkeit führt, auch wenn hierfür für viele Nutzer eine Umgewöhnung erforderlich ist.
Bei der Sortierung der Leistungen ist das ein wenig kontroverser. Da es sich hierbei ja immer um „abgeschlossene Zeiträume“ handelt, lesen hier die Ärzte tendentiell tatsächlich vom ältesten zum neuesten Eintrag. Eigentlich müssten die also andersherum sortiert sein als die Kartei. Hier war dann aber dennoch der Konsens, dass eine mit der Kartei konsistente Sortierung der Leistungen wichtiger und sinnvoller ist als eine chronologische Sortierung, da so leichter erkannt werden kann, inwieweit Leistungen und Behandlungsdokumentation übereinstimmen, bzw. wo z.B. noch Leistungen fehlen. Da wir im Forum jedoch inzwischen Wunschäußerungen von fünf Praxen mit Bevorzugung der chronologischen Sortierung haben, werden wir das angehen, dass dort per Klick auf Datums-Spaltenkopf die Sortierrichtung geändert werden kann, so wie das in anderen Tabellen wie Terminübersicht, Statistik-Ergebnislisten und Kassenbuch bereits der Fall ist. Zeit-Ziel: bis spätestens Weihnachten.
Warum nicht auch für die Kartei? Weil das technisch dort noch einmal deutlich aufwändiger wäre, das ordentlich zu machen. So bieten Apples Frameworks z.B. keine Standardmöglichkeit, Tabellen ganz nach unten "vorzuscrollen". Wenn in der Kartei jedoch beim Öffnen erst einmal die ältesten (= obersten) Eintrag angezeigt würden und der Nutzer durch mehrere Jahre Historie scrollen müsste, bis er ganz unten bei den aktuellen ist, wäre das keine gute User-Experience. Apple Mail umgeht dieses Problem, indem es sich einfach die letzte Tabellenposition in der Inbox merkt und dort beim Öffnen von Mail wieder hinscrollt. Wir müssten (da ja jede Kartei eine unterschiedliche Länge hat) stattdessen händisch die Pixelposition des Scrollers berechnen, dazu im Voraus berechnen wie die einzelnen Karteieinträge umgebrochen werden (denn diese können ja mehrzeilig sein in der Karteitabelle), die einzelnen Pixelhöhen aufaddieren, und dann bis dahin vorscrollen, und das ganze performant bekommen. Das ist alles möglich, aber lohnt sich bei der geringen Anzahl an Nutzerwünschen nach chronologischer Sortierung der Kartei (obwohl wahrscheinlich inzwischen fast jede tomedo-Praxis diesen Tagbanuwa-Thread gelesen hat) nicht, unsere Programmier-Ressourcen da hineinzustecken im Vergleich zu anderen Programmverbesserungen. Außerdem würde die Unterstützung beider Modi auch jede zukünftige Programmieränderung an der Karteitabelle verlangsamen, da wir für immer Kompatibilität mit beiden Sortierrichtungen gewährleisten müssen und beide Modi vor Updates testen müssen. Bei den Leistungstabellen ist das alles einfacher, u.a. weil dort jeder Eintrag einzeilig ist.