QuickForms wird vollständig über Konfigurationsdateien gesteuert. Dadurch kann das System für unterschiedliche Formulare, Datenquellen und Arbeitsabläufe eingesetzt werden, ohne dass Änderungen am Programmcode erforderlich sind. Für die Inbetriebnahme sind insbesondere die Projektkonfiguration, die APF-Datei selbst sowie benutzerspezifische Einstellungen relevant.

Exemplarische Vorgehensweise:

Grundprinzip der Konfiguration

Die Konfiguration ist so aufgebaut, dass ein Formularprojekt aus mehreren Bausteinen besteht. Dazu gehören insbesondere:

• die Projektdefinition in der projekt.cfg
• die Formularbeschreibung in der zugehörigen APF-Datei
• optionale benutzerspezifische Einstellungen in der user.ini
• optionale Scripts für Neuanlage, Speichern, Löschen oder Menüfunktionen

Über diese Dateien wird festgelegt:

• welches Formular geladen wird
• aus welcher Stammdatenquelle die Grunddaten kommen
• ob eine zusätzliche SQL-Formulartabelle verwendet wird
• welche Felder angezeigt, gespeichert oder verborgen werden
• welche Suchabfragen und Menüfunktionen zur Verfügung stehen
• welche Scripte bei bestimmten Aktionen ausgeführt werden

Projektdefinition in der projekt.cfg

Die zentrale Projektdefinition erfolgt im Abschnitt [SETTINGS]. Hier werden die allgemeinen Eigenschaften des Formularprojekts festgelegt.

Wichtige Parameter sind unter anderem:

• MATCHCODE
  Interner eindeutiger Projektname. Er wird auch für Scriptzuordnungen und weitere interne Funktionen verwendet.
• TITEL
  Anzeigename des Formulars in der Oberfläche.
• ENABLED
  Aktiviert oder deaktiviert das Projekt.
• LISTVIEW
  Steuert, ob die Anzeige als Listenansicht verwendet wird.
• MEHRMALIGERSTELLBAR
  Legt fest, ob pro Stammdatensatz mehrere Formulareinträge erzeugt werden können.
• PRIMARYID
  Definiert den fachlichen Schlüssel der Stammdaten, meist beispielsweise PatientID.
• MULTIRECORD
  Ergänzende Einstellung für Mehrfacheinträge.
• FORMULAR
  Verweis auf die zu ladende APF-Datei.
• MATCHCODEMENU
  Steuert projektbezogene Menüfunktionen.

Zusätzlich können im Abschnitt [SETTINGS] Scripte für bestimmte Aktionen hinterlegt werden:

• RUN_NEW für die Neuerzeugung eines Datensatzes
• RUN_SAVE für Aktionen nach dem Speichern
• RUN_DELETE für Aktionen nach dem Löschen

Wenn RUN_NEW verwendet wird, erwartet das System aus dem Script die Variable SCRIPT.RESULT. Nur wenn diese auf TRUE gesetzt wird, wird die aktuelle Zeile mit den übergebenen Werten gefüllt. Die vom Script gelieferten Variablen müssen den Feldnamen aus der Formular- bzw. Datenbankdefinition entsprechen.

Scriptaufrufe erfolgen so, dass die Variablen der aktuellen Zeile mit Feldname und Wert an das Script übergeben werden. Dadurch kann das Script direkt auf den aktuellen Datensatzkontext zugreifen.

//MCDMS-QuickForms
//DEMO_NEW.MCFSCR
MSG=""
MELDEANLASS="statusmeldung"
TMP_PATIENTID={IDDEV}
SQL=""
SQL=Select * FROM Diagnosen WHERE PATIENTID={PATIENTID} AND DIAGTYP=0 AND ICDNR='C61'
ANZREC=DB.OPEN{{APPPATH}\DATABASE\MEDDOK{IDDEV}.MDB,{SQL},True}
DBCLOSE=DB.CLOSE{}
IFBLOCK{ANZREC>0}
	//???
ENDIF

DIAGNOSEGESAMT=""
AUFDIAGNOSEGESAMT=""
VERSICHERTENDATEN="GKV"
UNTERSUCHUNGSDATUM_VERLAUF={ENTDATUM}
TMP_DATUM=""
TMP_DATUM=DATEADD{d,1,{AUFDATUM}}
DATUMPSA={TMP_DATUM}
PRIMAERTUMOR_ICD={PATIENTID}
SCRIPT.RESULT="True"

Akteneinträge und Zusatzfunktionen

Mit AKTECHECK=TRUE wird aktiviert, dass Akteneinträge zu Formularvorgängen verwaltet werden. Ist diese Einstellung nicht gesetzt, erfolgt keine Verwaltung der entsprechenden Akteneinträge.

Bei mehrfach erstellbaren Formularen entspricht MEHRMALIGERSTELLBAR funktional dem Verhalten MULTIRECORD in MCDMS. Damit können zu einem Stammdatensatz mehrere Formulareinträge existieren.

Datenbankkonfiguration

Die Datenquellen werden im Abschnitt [DATABASE] definiert. Dabei wird zwischen der Stammdatenquelle und der konnektierten Formulardatenbank unterschieden.

Für die Stammdatenbank werden unter anderem folgende Einstellungen verwendet:

• DATABASE_TYP
  Typ der Hauptdatenbank, beispielsweise ACCESS oder SQLSERVER.
• DATABASE_CONNECTIONSTRING
  Verbindungszeichenfolge zur Stammdatenquelle.
• StandardDatabase
  Pfad oder Referenz auf die Standarddatenbank.
• DATABASE_StandardOrder
  Standardsortierung der geladenen Stammdaten.
• DATABASE_EDIT
  Steuert, ob Stammdaten bearbeitet werden dürfen.

Die konnektierte Formulardatenbank wird über weitere Parameter gesteuert:

• DB_CONNECT
  Aktiviert die Zusatzdatenanbindung.
• DB_CONNECT_EDIT
  Legt fest, ob Zusatzdaten bearbeitet werden dürfen.
• DB_CONNECT_TYP
  Typ der verbundenen Formulardatenbank.
• DB_CONNECT_SOURCE
  Name der Tabelle oder Datenquelle für die Zusatzdaten.
• DB_CONNECT_PRIMARYID
  Primärschlüssel der Formulardatensätze, typischerweise FRMID.
• DB_CONNECT_ORDERBY
  Sortierung der Formulardatensätze. Diese wird ohne das Schlüsselwort ORDER BY angegeben.
• DB_CONNECT_ORDERBY_AKTE
  Sortierung für Akteneinträge. Hier ist zu beachten, dass sich Feldnamen je nach Datenbanktyp unterscheiden können.
• DB_CONNECT_SELECT
  Feld, das bei mehrfachen Formulareinträgen als sprechende Bezeichnung im Menü „Vorhandene“ verwendet wird.

Feldlisten und Sichtbarkeit

Mit DB_CONNECT_FIELDS wird festgelegt, welche Felder aus der SQL-Zusatztabelle verwendet werden. Diese Liste definiert gleichzeitig die technisch relevanten Datenbankfelder des Formulars.

Zusätzlich können weitere Felder gesteuert werden:

• DB_CONNECT_NOCOPYFIELDS
  Felder, die bei einer Kopier- oder Neuerzeugungsfunktion nicht übernommen werden sollen.
• DB_CONNECT_HIDDENFIELDS
  Felder, die technisch vorhanden sind, aber in der Oberfläche nicht angezeigt werden.
• DB_CONNECT_SORTFIELDS
  Felder, für die Sortierung in der Oberfläche explizit wieder zugelassen wird.

Damit lässt sich sehr fein steuern, welche Felder sichtbar, editierbar oder nur intern verwendet werden.

Formularfelddefinitionen

Die eigentliche fachliche Feldkonfiguration erfolgt im Abschnitt [DB_FORMULAR_FIELDS].

Jedes Feld wird hier mit seinen Eigenschaften beschrieben. Das allgemeine Format lautet:

Feldname=FeldTyp;FeldLänge;Pflicht;Format;Vordergrund;Hintergrund;Aliasname;ReadOnly

Dabei bedeuten die Angaben unter anderem:

• FeldTyp
  Der technische Typ des Feldes, beispielsweise Text, Zahl, Datum oder Auswahlfeld.
• FeldLänge
  Maximale Länge des Feldinhalts.
• Pflicht
  Kennzeichnung, ob ein Feld zwingend befüllt werden muss.
• Format
  Zusätzliche Formatdefinition, beispielsweise Datumsformat oder die Liste zulässiger Auswahlwerte bei Comboboxen.
• Vordergrund und Hintergrund
  Farbdefinitionen für die Darstellung des Feldes. Unterstützt werden Farbnamen oder Hexwerte.
• Aliasname
  Benutzerfreundliche Feldbezeichnung in der Oberfläche.
• ReadOnly
  Kennzeichnet, ob das Feld schreibgeschützt ist.

Bei Auswahlfeldern können in der Formateinstellung direkt die zulässigen Werte definiert werden. Bei Datumsfeldern kann darüber das Datumsformat gesteuert werden.

Wichtig ist außerdem, dass bestimmte technische Felder wie ERSTELLTAM und DATE vorhanden sein müssen, wenn sie von der zugrunde liegenden Datenbankstruktur automatisch erzeugt oder erwartet werden.

Suchdefinitionen

Im Abschnitt [SELECTIONS] werden vorbereitete Datenbankabfragen hinterlegt, die in der Oberfläche als auswählbare Datenbasis oder Filter dienen können.

Dadurch können für unterschiedliche Anwendungsfälle verschiedene Listen definiert werden, zum Beispiel:

• aktuelle Patienten
• letzte 90 Tage
• bestimmte Fachabteilungen
• Test- oder Musterauswahlen

Diese Definitionen bestehen aus einem frei wählbaren Anzeigenamen und der dazugehörigen SQL- oder Access-Abfrage.

Suchfelder

Im Abschnitt [SUCHFELDER] wird definiert, welche Felder für die Standardsuche verwendet werden.

Dadurch lässt sich festlegen, nach welchen Informationen Benutzer innerhalb der angezeigten Datensätze suchen können, beispielsweise nach:

• Name
• Vorname
• Fallnummer
• Geburtsdatum
• PatientID

Menü- und Scriptfunktionen

Im Abschnitt [RUN] können zusätzliche Menüfunktionen definiert werden. Diese erscheinen in der Oberfläche als ausführbare Aktionen und rufen externe Programme oder Scripts auf.

Typische Einsatzgebiete sind beispielsweise:

• Erzeugung von Exportdateien
• Versandprozesse
• Zähl- oder Prüfskripte
• externe Nachverarbeitung

Wenn keine projektspezifischen Scripts für ein Matchcode-Menü vorhanden sind, kann auf diese allgemeine RUN-Definition zurückgegriffen werden.

Zur Laufzeit werden dabei zusätzliche Variablen übergeben, etwa Zählerstände oder Endekennzeichen. Dadurch können auch mehrstufige oder stapelweise Verarbeitungen umgesetzt werden.

Benutzerspezifische Einstellungen in der user.ini

Neben der Projektkonfiguration können benutzerspezifische Einstellungen in einer user.ini gespeichert werden. Diese dienen typischerweise nicht der fachlichen Definition des Formulars, sondern der individuellen Arbeitsumgebung des jeweiligen Benutzers.

Dazu gehören je nach Ausbaustand beispielsweise:

• zuletzt verwendete Auswahl oder Selektion
• Fensterpositionen und Fenstergrößen
• Spaltenbreiten in der Listenansicht
• Sortierungen oder Filterzustände
• benutzerspezifische Anzeigeeinstellungen

Damit kann dieselbe Projektkonfiguration von mehreren Benutzern verwendet werden, ohne dass deren persönliche Arbeitsoberfläche verloren geht.

Inbetriebnahme eines neuen Formularprojekts

Die Inbetriebnahme eines neuen Projekts erfolgt in der Regel in mehreren Schritten.

Zunächst wird die APF-Datei erstellt oder angepasst. In ihr werden die fachlichen Felder, Feldtypen, Pflichtfelder, Farben, Aliase und Anzeigeeigenschaften definiert.

Anschließend wird in der projekt.cfg das Projekt eingerichtet. Dort werden Titel, Matchcode, Formularpfad, Datenbankquellen, Schlüsseldefinitionen und gegebenenfalls Scriptaufrufe festgelegt.

Danach wird die Stammdatenabfrage definiert. Diese legt fest, welche Datensätze überhaupt in der Liste erscheinen.

Im nächsten Schritt wird die Verbindung zur SQL-Zusatztabelle eingerichtet. Hierzu müssen insbesondere der Name der Zusatzdatenquelle, die Feldliste, der Primärschlüssel der Formulardaten sowie optionale Sortier- und Sichtbarkeitseinstellungen festgelegt werden.

Optional können vorbereitete Selektionen, Suchfelder und Script-Menüs ergänzt werden.

Nach der Einrichtung sollte das Projekt getestet werden. Dabei sind insbesondere folgende Punkte zu prüfen:

• Laden der Stammdaten
• korrekte Verknüpfung über PRIMARYID
• Laden und Speichern der Zusatzdaten
• Pflichtfeldprüfung
• Feldlängenprüfung
• Verhalten bei mehrfach erstellbaren Datensätzen
• Scriptaufrufe bei Neu, Speichern oder Löschen
• Sichtbarkeit und Sortierung der Felder

Wichtige technische Zusammenhänge

Für den stabilen Betrieb ist die Trennung der beiden Schlüssel besonders wichtig:

• PRIMARYID beschreibt den fachlichen Schlüssel des Stammdatensatzes, zum Beispiel PatientID
• DB_CONNECT_PRIMARYID beschreibt den technischen Primärschlüssel des Formulardatensatzes, zum Beispiel FRMID

Die Verknüpfung zwischen Stammdaten und Formular-Zusatzdaten erfolgt fachlich über PRIMARYID. Der technische Primärschlüssel der Formulartabelle wird dagegen für Update-, Lösch- und interne Verwaltungsoperationen benötigt.

Nur wenn diese Trennung korrekt konfiguriert ist, können neue, bestehende und mehrfach vorhandene Formulareinträge zuverlässig verarbeitet werden.

Durch diese Konfigurationsstruktur lässt sich QuickForms sehr flexibel an unterschiedliche fachliche Anforderungen anpassen und mit vergleichsweise geringem Aufwand in bestehende Systemlandschaften integrieren.