3.4 Sonstige Konzepte

• Daten in Textformaten, soweit sinnvoll
• alle anderen Formate offengelegt
• Programmreaktionszeit für sprechstundenrelevante Aufgaben muß immer kleiner 500ms sein
• Kontakt mit Kodierung nur dort für den Anwender notwendig, wo unumgänglich (aber natürlich überall möglich)
• eigene Ergänzungen und “offizielle” Daten dürfen sich nie überschneiden (ein “Update” darf niemals nicht praxisspezifisch erstellte Formulare überschreiben)
• Auswahlmöglichkeiten (z.B. Formularliste o.ä.) dürfen nie durch arbiträre Faktoren (Fenstergröße, verfügbare Buchstaben als Aufrufkürzel o.ä.) begrenzt werden
• saubere Trennung der Abrechnung und Kodierung (ICD) von der eigentlichen, übergeordneten Dokumentation
  • aber vielfältige Schnittstellen
  • dadurch ärztliche Dokumentation fördern, ohne Abrechnung zu stark zu gefährden
  • Diagnosenliste an sich und Zuordnungsliste Code<->Diagnosentext sind verschiedene Liste !!
  • Zuordnungsliste Code<->amtliche Bezeichnung ist eine dritte Liste !!
• aussagekräftige Fehlermeldungen
  • was geht warum nicht
  • was soll der Anwender tun
  • explizit Dateinamen und -pfade angeben
  • Hinweis auf Fehlerlog
• aussagekräftige Fehlerlogs
  • Ursachenforschung ermöglichen
• aussagekräftige Nutzerabfragen:
  • warum Nutzerabfrage (“Es soll ... getan werden. Das geht nicht automatisch, weil ...”
  • aktuelle Daten zeigen, die die Abfrage auslösen
  • Lösungsmöglichkeiten aufzeigen
• Nutzergemeinschaft fördern
  • versenden erstellter Formulare/Vordrucke/etc. per Knopfdruck an Mailingliste/Webseite
  • gemeinsames, automatisiertes Pflegen von Listen (ICD, Rechtschreibung)
• Querverweise, die aus der Praxis hinausführen (Internet, Praxisnetz) müssen klar erkennbar sein
• die Software soll auch unter widrigen Umständen funktional bleiben, z.B.:
  • bei Nichterreichbarkeit des Datenbankservers soll einfach ein alternativer Server angegeben werden können
  • fehlende Konfigurationseinstellungen dürfen den Programmablauf nicht verhindern
  • Fehlerlogs sollen nur geschrieben werden, wenn Platz vorhanden ist
  • wenn die Software von einem read-only Medium (CD) gestartet wird, sollen Zustandsdaten (temporäre Dateien, Logdateien, Konfigurationsdateien) auch in anderen als den Standardverzeichnissen abgelegt werden können
• konservativ
  • die Software soll bei eigenen Entscheidungen auf der sicheren Seite bleiben, z.B. bei Unklarheit Daten lieber doppelt speichern und den Nutzer darüber informieren, als sich auf mglw. unzuverlässige Programmlogik zu stützen
  • z.B. Löschen von Laborimportdateien erst nach einer festlegbaren Zeitspanne
• Zustandsfreiheit
  • Prozesse sollten möglichst wenig von transienten Zuständen im RAM abhängig sein - Plattenplatz ist billig !
  • checkpoints mit Wiederaufnahme des Ablaufs von dort
  • z.B. halb ausgefüllte Formulare können beliebig oft abgebrochen und weitergeführt werden
• sicher
• autonom - do one task and do it well