Wie können wir helfen?

View Categories

04 Formulare & Scripts

Die MCDMS-WebAkte verwendet HTML-Dateien zur Darstellung von Formularen und Seiten im Browser.

Die Zuordnung und Konfiguration erfolgt über:

{APPPATH}\Web\FORMULARE.INI

Ein Formular kann unter anderem definieren:

Titel
HTML-Datei
Render-Modus
Bearbeitbarkeit
Mehrfachdatensätze
Löschen
Duplizieren
Sortierung
Rollen
SQL-Datenquelle
MCDMS-Scripts
Action-Schaltflächen
optionalen Reload nach einer Action
zweite Speichern-Schaltfläche

Die MCDMS-WebAkte unterstützt dabei zwei grundsätzliche Arten von Formularen:

SQL-/Record-Formulare

und

datenbanklose Seiten / Action-Seiten

SQL-Formulare dienen zur Bearbeitung von Datensätzen.

Datenbanklose Seiten können beispielsweise für:

Dashboards
Übersichten
Workflow-Seiten
Scriptfunktionen
Druckfunktionen
fachliche Aktionen

verwendet werden.

Aufbau eines Formulareintrags

Beispiel für ein SQL-Formular:

[FORMULAR_LEISTUNGSERFASSUNG]
Title=Leistungs- & Minutenerfassung
HTML=HTML\Pflege\LeistungsMinutenerfassung.html
RenderMode=Document
Edit=TRUE
MultiRecord=TRUE
Delete=TRUE
AllowDuplicate=TRUE
Roles=
ScriptLoadHTML=CONFIG\Scripts\WEB\load.mcfscr
ScriptSaveHTML=CONFIG\Scripts\WEB\save.mcfscr
ScriptDelete=CONFIG\Scripts\WEB\delete.mcfscr
Database=FRM_LEISTUNGSERFASSUNG;FRMID;PatientID
OrderBy=FRMID;DESC
DoubleSaveButton=TRUE
Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

Beispiel für eine datenbanklose Seite:

[FORMULAR_WEBTEST_ACTION]
Title=Webtest Aktionen
HTML=HTML\Webtest\WEBTEST_ACTION.HTML
RenderMode=Document
Edit=FALSE
MultiRecord=FALSE
Delete=FALSE
Roles=
ScriptLoadHTML=
ScriptSaveHTML=
ScriptDelete=
Database=
Action_TEST=CONFIG\Scripts\WEB\WEBTEST_ACTION.MCFSCR

Jeder Abschnitt beschreibt genau ein Formular.

Formular-ID

Der Name des INI-Abschnittes ist die eindeutige Formular-ID.

Beispiel:

[FORMULAR_LEISTUNGSERFASSUNG]

Die Formular-ID muss nicht mit dem Namen der HTML-Datei identisch sein.

Title

Der sichtbare Titel des Formulars.

Beispiel:

Title=Leistungs- & Minutenerfassung

Bei SQL-Formularen wird der Titel zusammen mit der Datensatzliste angezeigt.

Bei datenbanklosen Formularen wird der Titel direkt als Schaltfläche in der Formularliste verwendet.

Beispiel:

[ Webtest Aktionen ]

Ein zusätzlicher Eintrag „Öffnen“ ist dafür nicht erforderlich.

HTML

Relativer Pfad der HTML-Datei innerhalb von:

{APPPATH}\Web

Beispiel:

HTML=HTML\Pflege\LeistungsMinutenerfassung.html

ergibt:

{APPPATH}\Web\HTML\Pflege\LeistungsMinutenerfassung.html

Die Zuordnung zu einem Aktenbereich erfolgt über den HTML-Unterordner.

Beispiel:

HTML=HTML\Pflege\LeistungsMinutenerfassung.html

gehört zum Bereich:

Pflege

wenn dieser unter:

{APPPATH}\Web\HTML\Pflege

liegt.

Die Reihenfolge der Aktenbereiche wird über die AKTENSTRUKTUR.INI gesteuert.

RenderMode

Unterstützt werden:

RenderMode=Inline

und:

RenderMode=Document

RenderMode=Inline

Bei Inline wird der Inhalt des Formulars direkt in die bestehende WebAkte-Oberfläche eingebunden.

Das Formular teilt sich damit den DOM- und CSS-Kontext der WebAkte.

Dies kann für einfache Formulare sinnvoll sein.

Bei umfangreichen HTML-Dokumenten kann es jedoch leichter zu Wechselwirkungen zwischen Formular-CSS und WebAkte-CSS kommen.

RenderMode=Document

Bei Document wird das Formular als eigenes HTML-Dokument in einem isolierten iframe dargestellt.

Beispiel:

RenderMode=Document

Vorteile:

eigene HTML-Struktur
eigenes CSS
saubere Trennung von der WebAkte-Oberfläche
weniger CSS-Wechselwirkungen
gut geeignet für umfangreiche oder dokumentorientierte Formulare

Für neue umfangreiche Formulare wird RenderMode=Document empfohlen.

JavaScript innerhalb von Document-Formularen

Document-Formulare laufen in einem sandboxed iframe.

Eigene <script>-Blöcke oder JavaScript innerhalb des Formulars werden deshalb nicht ausgeführt.

Beispiel:

<script>
    ...
</script>

wird im Document-Modus blockiert.

Dies ist beabsichtigt und dient der Isolation des Formulars.

Auch Konstruktionen wie:

<button onclick="...">

sollten deshalb nicht verwendet werden.

Interaktive Funktionen der MCDMS-WebAkte werden stattdessen über die vorgesehenen HTML-Attribute bereitgestellt, beispielsweise:

data-mcdms-action="DRUCKEN"

Die eigentliche Verarbeitung erfolgt durch die äußere WebAkte.

Edit

Steuert, ob ein SQL-Formular bearbeitet werden darf.

Edit=TRUE

Das Formular ist editierbar.

Edit=FALSE

Das Formular wird nur angezeigt.

Bei Edit=FALSE wird keine normale Speichern-Schaltfläche angezeigt.

MultiRecord

Steuert, ob für einen Patienten mehrere Datensätze vorhanden sein können.

MultiRecord=TRUE

Mehrere Datensätze sind möglich.

MultiRecord=FALSE

Es wird nur ein Datensatz pro Patient verwendet.

Delete

Steuert, ob ein Datensatz gelöscht werden darf.

Delete=TRUE

oder:

Delete=FALSE

Das Löschen erfolgt immer im Kontext:

aktueller Benutzer
aktuelle Session
ausgewählter Patient
aktueller Datensatz
konfiguriertes Formular

AllowDuplicate

Steuert, ob ein vorhandener Datensatz dupliziert werden darf.

Beispiel:

AllowDuplicate=TRUE

Beim Duplizieren wird ein neuer Datensatz aus den kopierbaren Feldern des vorhandenen Datensatzes vorbereitet.

Nicht übernommen werden insbesondere technische Felder wie:

Primärschlüssel
Identity-Spalten
berechnete Spalten
rowversion-Felder
Patientenzuordnung

Die Patientenzuordnung erfolgt immer über den aktuell ausgewählten Patienten.

OrderBy

Für MultiRecord-Formulare kann die Sortierung der Datensatzliste festgelegt werden.

Aufbau:

OrderBy=Spalte;ASC

oder:

OrderBy=Spalte;DESC

Beispiel:

OrderBy=FRMID;DESC

Damit werden die Datensätze nach FRMID absteigend angezeigt.

Beispiel:

OrderBy=DATUM;ASC

Die angegebene Spalte wird serverseitig gegen die tatsächlich vorhandenen SQL-Spalten geprüft.

Es ist bewusst nur eine einzelne Sortierspalte zulässig.

Fehlt OrderBy, ist der Eintrag leer oder ungültig, wird als sichere Standardsortierung verwendet:

Primärschlüssel ASC

Die Sortierung erfolgt serverseitig.

Der Browser baut keinen eigenen SQL-Ausdruck zusammen.

Roles

Über Roles kann der Zugriff auf ein Formular eingeschränkt werden.

Beispiel:

Roles=ARZT;OBERARZT

Mehrere Rollen werden durch Semikolon getrennt.

Leerer Eintrag:

Roles=

bedeutet, dass keine zusätzliche formularbezogene Rollenbeschränkung hinterlegt ist.

Die Rollenprüfung erfolgt serverseitig.

Database

Mit Database wird die SQL-Datenquelle des Formulars definiert.

Aufbau:

Tabelle;Primärschlüssel;Patientenfeld

Beispiel:

Database=FRM_LEISTUNGSERFASSUNG;FRMID;PatientID

Dabei bedeutet:

FRM_LEISTUNGSERFASSUNG

SQL-Tabelle

FRMID

technischer Primärschlüssel

PatientID

Zuordnung zum aktuell ausgewählten Patienten

Die WebAkte verwendet diese Angaben zum:

Laden
Speichern
Löschen
Duplizieren
Auflisten von Datensätzen

Datenbanklose Formulare

Database darf bewusst leer bleiben.

Beispiel:

Database=

Damit wird das Formular als datenbanklose Seite behandelt.

Ein solches Formular besitzt:

keine SQL-Datensatzliste
kein + Neu
kein SQL-Speichern
kein SQL-Löschen
kein Duplizieren

Es kann aber weiterhin:

HTML darstellen
Templatevariablen anzeigen
ScriptLoadHTML verwenden
Action-Schaltflächen verwenden
MCDMS-Scripts ausführen

Datenbanklose Seiten eignen sich beispielsweise für:

Startseiten
Dashboards
Patientenübersichten
Workflow-Seiten
fachliche Scriptfunktionen
Druckseiten
Funktionsmenüs

In der Aktenübersicht werden solche Seiten direkt über ihren Title geöffnet.

HTML-Felder

Bearbeitbare Formularfelder werden über:

data-field

und in der Regel zusätzlich über:

name

gekennzeichnet.

Beispiel:

<input
    data-field="GEBDATUM"
    name="GEBDATUM"
    type="text"
    value="[#GEBDATUM#]">

Textarea

<textarea
    data-field="DIAGNOSE1"
    name="DIAGNOSE1">[#DIAGNOSE1#]</textarea>

Checkbox

Beispiel für ein einzelnes boolesches Feld:

<input
    data-field="KONTROLLABOR"
    name="KONTROLLABOR"
    data-template-value="[#KONTROLLABOR#]"
    type="checkbox"
    value="1">

Eine einzelne Checkbox wird als einzelnes Formularfeld behandelt.

Radio-Buttons

Native HTML-Radio-Buttons werden unterstützt.

Mehrere Radio-Buttons gehören zu demselben Formularfeld, wenn sie denselben:

data-field

und denselben:

name

verwenden.

Beispiel:

<label>
    <input
        type="radio"
        name="GESCHLECHT"
        data-field="GESCHLECHT"
        value="M">
    männlich
</label>

<label>
    <input
        type="radio"
        name="GESCHLECHT"
        data-field="GESCHLECHT"
        value="W">
    weiblich
</label>

Gespeichert wird der exakte Wert des ausgewählten Radio-Buttons.

Es wird bewusst die native HTML-Funktion verwendet.

Eine zusätzliche proprietäre Choice-Komponente ist dafür nicht erforderlich.

HTML-Standard verwenden

Die MCDMS-WebAkte verwendet grundsätzlich vorhandene Webstandards.

Wenn HTML bereits eine geeignete Funktion bereitstellt, sollte diese direkt verwendet werden.

Beispiele:

input
textarea
select
checkbox
radio
button
CSS
DOM

Eigene Sonderkomponenten werden nur dort benötigt, wo eine echte MCDMS-spezifische Funktion erforderlich ist.

Templatevariablen

MCDMS-Variablen werden im HTML in folgender Form verwendet:

[#VARIABLE#]

Beispiel:

<div>[#GESAMTNAME#]</div>

oder:

<input
    data-field="ORT"
    name="ORT"
    value="[#ORT#]">

Beim Laden des Formulars ersetzt die WebAkte die Platzhalter durch die zur Laufzeit verfügbaren Werte.

Wiederholt vorkommende Variablen werden innerhalb eines Formular-Ladevorgangs nur einmal aufgelöst und anschließend für alle Vorkommen verwendet.

Dadurch können auch große und mehrseitige HTML-Formulare effizient verarbeitet werden.

Server- und Benutzervariablen

Zusätzlich zu normalen MCDMS-PatientVars stellt die WebAkte bestimmte serverseitig bestimmte Variablen bereit.

Unter anderem:

USERID
USERNAME
USERVORNAME
USERLOGINNAME
USERABTEILUNG
USERGRUPPE
USERSTATION
USERMAIL

zusätzlich steht im Scriptkontext zur Verfügung:

USERTYPE

Systemvariablen:

APPPATH
DATE
TIME
KWOCHE

Patientenbezogene Systemwerte können – sofern sie im aktuellen Patientenkontext vorhanden sind – beispielsweise umfassen:

PATIENTID
MANDANTNR
MCFLPATIENTID
IDDEV
IDDEVLAB
ALTER

Beispiel im HTML:

<div>Benutzer: [#USERNAME#]</div>
<div>Datum: [#DATE#]</div>

Beispiel im MCDMS-Script:

ERSTELLTAM={DATE}
ERSTELLTVON={USERID}

PATIENTID

PATIENTID wird niemals aus einem Browserfeld übernommen.

Die aktuelle Patientenzuordnung stammt ausschließlich aus der serverseitigen WebSession.

Datum und Formularwerte

Datumswerte werden innerhalb der WebAkte in einem für MCDMS geeigneten Format verarbeitet.

Je nach Feld und Quelle können unter anderem Werte wie:

15.09.2026

oder ISO-Datumswerte verarbeitet werden.

Die sichtbare Darstellung im Formular kann durch das HTML festgelegt werden.

Bestehende SQL-Datensätze: SQL ist die Wahrheit

Für bereits vorhandene SQL-Datensätze gilt eine besonders wichtige Regel:

Der vorhandene SQL-Datensatz ist die alleinige Datenquelle für seine Formularfelder.

Wenn ein SQL-Feld:

NULL

oder leer ist, bleibt es beim Laden des bestehenden Datensatzes leer.

Es wird nicht automatisch aus:

PatientVar
Servervariablen
Benutzervariablen
Defaultwerten

ergänzt oder überschrieben.

Damit wird verhindert, dass Daten eines bestehenden Datensatzes versehentlich durch andere aktuelle MCDMS-Werte ersetzt werden.

Neuer Datensatz

Bei + Neu wird bewusst ein neuer Formularzustand erzeugt.

Vorherige:

Primärschlüsselwerte
RecordId
editierbare Datensatzwerte

werden nicht weiterverwendet.

Die Patientenzuordnung stammt ausschließlich aus dem aktuell ausgewählten Patienten.

Bei neuen Datensätzen können für noch leere Felder kontrolliert Werte aus dem aktuellen Patientenkontext verwendet werden.

Nach erfolgreichem INSERT besitzt der Datensatz eine echte RecordId und wird anschließend wie ein vorhandener SQL-Datensatz behandelt.

Patientensicherheit beim Patientenwechsel

Beim Wechsel des Patienten wird der bisherige Patientenkontext kontrolliert beendet.

Vereinfacht:

ClosePatient
→ PatientVar.Clear
→ InitPatient(neuer Patient)
→ Benutzerkontext bereitstellen
→ ScriptPatientSelect

Schlägt das Beenden oder Zurücksetzen des alten Kontextes fehl, wird der neue Patient nicht einfach darüber initialisiert.

Dadurch wird verhindert, dass PatientVars unterschiedlicher Patienten miteinander vermischt werden.

Für jeden erfolgreich initialisierten Patienten wird ein patienten- und revisionsgebundener Ausgangszustand verwendet.

Schutz vor veralteten Formularantworten

Formularladevorgänge können unterschiedlich lange dauern.

Die WebAkte verhindert deshalb, dass eine ältere, langsamere Antwort einen inzwischen neu ausgewählten Patienten oder Datensatz im Browser überschreibt.

Nur die Antwort des aktuell gültigen Formular-/Patientenkontextes darf dargestellt werden.

DoubleSaveButton

Bei langen Formularen kann es unpraktisch sein, nach einer Änderung am oberen Formularbereich bis zum unteren Ende scrollen zu müssen.

Dafür kann optional eine zweite Speichern-Schaltfläche am oberen Formularrand aktiviert werden.

Beispiel:

DoubleSaveButton=TRUE

Verhalten:

DoubleSaveButton fehlt
→ Speichern nur unten

DoubleSaveButton=
→ Speichern nur unten

DoubleSaveButton=FALSE
→ Speichern nur unten

DoubleSaveButton=TRUE
→ Speichern oben und unten

Bei:

Edit=FALSE

wird unabhängig von DoubleSaveButton keine Speichern-Schaltfläche angezeigt.

Beide Schaltflächen verwenden exakt denselben serverseitigen Speichervorgang.

Es existiert keine getrennte Save-Logik.

Die Option funktioniert sowohl bei:

RenderMode=Inline

als auch bei:

RenderMode=Document

Scripts

Für Formulare können optional MCDMS-Scripts hinterlegt werden.

Unterstützt werden:

ScriptLoadHTML=
ScriptSaveHTML=
ScriptDelete=

Beispiel:

ScriptLoadHTML=CONFIG\Scripts\WEB\load.mcfscr
ScriptSaveHTML=CONFIG\Scripts\WEB\save.mcfscr
ScriptDelete=CONFIG\Scripts\WEB\delete.mcfscr

Die Scriptpfade werden relativ zu {APPPATH} angegeben.

Beispiel:

CONFIG\Scripts\WEB\load.mcfscr

entspricht:

{APPPATH}\CONFIG\Scripts\WEB\load.mcfscr

Mehrere Scripts können durch Semikolon angegeben werden.

Beispiel:

ScriptLoadHTML=CONFIG\Scripts\WEB\load1.mcfscr;CONFIG\Scripts\WEB\load2.mcfscr

Die Ausführung erfolgt von links nach rechts.

Scripts sind optional.

Ist kein Script erforderlich, bleibt der Eintrag leer:

ScriptLoadHTML=

Direkte MCDMS-Scriptausführung

Scripts werden direkt über die MCDMS5API ausgeführt.

Die WebAkte verwendet dafür die bestehende MCDMS-Framework-Instanz der angemeldeten Sitzung.

Es wird kein separates RUNScript.exe gestartet.

Dadurch laufen die Scripts im aktuellen:

Benutzerkontext
Patientenkontext
PatientVar-Kontext

der WebSession.

ScriptLoadHTML

ScriptLoadHTML wird beim Laden eines Formulars ausgeführt.

Es kann beispielsweise verwendet werden, um:

Variablen vorzubereiten
Werte zu berechnen
zusätzliche MCDMS-Informationen bereitzustellen
fachliche Voraussetzungen zu prüfen

Beispiel:

ScriptLoadHTML=CONFIG\Scripts\WEB\load.mcfscr

ScriptSaveHTML

ScriptSaveHTML wird im Zusammenhang mit dem Speichervorgang ausgeführt.

Beispiel:

ScriptSaveHTML=CONFIG\Scripts\WEB\save.mcfscr

Der eigentliche SQL-Speichervorgang der WebAkte bleibt davon getrennt.

Der Browser darf dadurch nicht beliebige zusätzliche PatientVars in den SQL-Datensatz einschleusen.

Zusätzliche Scriptwerte beim Speichern

Ein ScriptSaveHTML kann gezielt zusätzliche Werte erzeugen oder verändern.

Beispiel:

ERSTELLTAM={DATE}
ERSTELLTVON={USERID}

Die WebAkte erkennt dabei kontrolliert, welche Variablen durch den aktuellen Save-Scriptlauf neu erzeugt oder verändert wurden.

Nur sicher nachvollziehbare Werte können anschließend für tatsächlich vorhandene SQL-Spalten berücksichtigt werden.

Beliebige bereits vorhandene PatientVars werden nicht pauschal als SQL-Daten übernommen.

Technische bzw. geschützte Felder wie:

Primärschlüssel
Identity
Computed
rowversion
Patientenfeld
PATIENTID

werden nicht durch frei gelieferte Werte überschrieben.

Variablennamen wie DATE oder USERID

Variablennamen wie:

DATE
TIME
USERID
USERNAME

dürfen weiterhin als echte Zielvariablen bzw. SQL-Spalten verwendet werden, sofern die konkrete Formular- und Datenbankdefinition dies vorsieht.

Beispiel:

DATE={DATE}

Dabei ist:

rechte Seite {DATE}

der serverseitige Systemwert,

während:

linke Seite DATE

die Zielvariable des Scripts sein kann.

Ebenso:

ERSTELLTAM={DATE}
ERSTELLTVON={USERID}

PATIENTID bleibt davon ausgenommen und wird weiterhin ausschließlich über den aktuellen Patientenkontext kontrolliert.

ScriptDelete

ScriptDelete kann beim Löschen eines Datensatzes als zusätzlicher Script-Hook verwendet werden.

Beispiel:

ScriptDelete=CONFIG\Scripts\WEB\delete.mcfscr

Die normale serverseitige Löschlogik der WebAkte bleibt bestehen.

Action-Schaltflächen

Zusätzlich zu Laden, Speichern und Löschen können Formulare frei definierbare Script-Aktionen besitzen.

Damit können beispielsweise Schaltflächen für:

Drucken
PDF erzeugen
Freigeben
E-Mail
Workflow starten
fachliche Prüfung
Datenübernahme
Schnittstellenaktion

angelegt werden.

Eine Action besteht aus zwei Teilen:

HTML-Schaltfläche

und:

serverseitige Zuordnung in FORMULARE.INI

Action im HTML

Beispiel:

<button type="button" data-mcdms-action="DRUCKEN">
    Drucken
</button>

Der Browser kennt dabei lediglich den Action-Namen:

DRUCKEN

Er kennt keinen Scriptpfad.

Action in FORMULARE.INI

Passend dazu:

Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

Die Zuordnung lautet damit:

data-mcdms-action="DRUCKEN"

          ↓

Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

Der Scriptpfad wird ausschließlich serverseitig ermittelt.

Mehrere Actions

Ein Formular kann mehrere Actions besitzen.

Beispiel:

Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR
Action_PDF=CONFIG\Scripts\WEB\PDF.MCFSCR
Action_FREIGEBEN=CONFIG\Scripts\WEB\FREIGEBEN.MCFSCR

HTML:

<button type="button" data-mcdms-action="DRUCKEN">
    Drucken
</button>

<button type="button" data-mcdms-action="PDF">
    PDF erzeugen
</button>

<button type="button" data-mcdms-action="FREIGEBEN">
    Freigeben
</button>

Die technische Action-ID wird dem Benutzer nicht angezeigt.

Actions in SQL-Formularen

Actions können zusätzlich in ganz normalen SQL-Formularen verwendet werden.

Beispiel:

[FORMULAR_LEISTUNGSERFASSUNG]
Title=Leistungs- & Minutenerfassung
HTML=HTML\Pflege\LeistungsMinutenerfassung.html
RenderMode=Document
Edit=TRUE
MultiRecord=TRUE
Delete=TRUE
AllowDuplicate=TRUE
Database=FRM_LEISTUNGSERFASSUNG;FRMID;PatientID
Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

Das Formular bleibt dabei vollständig ein normales SQL-Formular.

Insbesondere bleiben unverändert:

Laden
Speichern
Löschen
Duplizieren
MultiRecord
+ Neu
RecordId
SQL als Datenquelle

Die Action ist lediglich eine zusätzliche Funktion.

Actions in datenbanklosen Seiten

Auch datenbanklose Seiten können Actions verwenden.

Beispiel:

[FORMULAR_WEBTEST_ACTION]
Title=Webtest Aktionen
HTML=HTML\Webtest\WEBTEST_ACTION.HTML
RenderMode=Document
Edit=FALSE
Database=
Action_TEST=CONFIG\Scripts\WEB\WEBTEST_ACTION.MCFSCR

HTML:

<button type="button" data-mcdms-action="TEST">
    Testaktion ausführen
</button>

Ein Script kann beispielsweise setzen:

TESTVAR=ABC123

und eine datenbanklose Seite kann diesen Wert anschließend über eine Templatevariable darstellen:

<div style="white-space: pre-line;">
    <strong>TESTVAR:</strong>
    [#TESTVAR#]
</div>

Zeilenumbrüche in Scriptwerten

MCDMS-Scripts können beispielsweise mit:

{RET}

Zeilenumbrüche erzeugen.

Normales HTML stellt solche Zeilenumbrüche innerhalb von Text jedoch standardmäßig als Leerraum dar.

Für eine mehrzeilige Darstellung kann beispielsweise verwendet werden:

<div style="white-space: pre-line;">
    [#TESTVAR#]
</div>

Damit bleiben die im Text enthaltenen Zeilenumbrüche sichtbar.

Feedback bei Actions

Nach dem Klick auf eine Action-Schaltfläche erhält der Benutzer eine direkte Rückmeldung über dieselbe Schaltfläche.

Beispiel:

Drucken

wird während der Ausführung zu:

Drucken...

Bei Erfolg kurz:

Ausgeführt

und anschließend wieder:

Drucken

Bei einem Fehler:

Drucken...
→ Fehlgeschlagen
→ Drucken

Während der Action wird nur die angeklickte Schaltfläche deaktiviert.

Es werden keine klassischen Windows-MessageBoxen und keine JavaScript-alert()-Fenster benötigt.

Die technische Action-ID wird nicht angezeigt.

ActionReload

Standardmäßig lädt eine Action das geöffnete Formular nach erfolgreicher Ausführung nicht neu.

Das ist insbesondere bei SQL-Formularen wichtig.

Ein Benutzer kann beispielsweise mehrere Felder geändert haben, ohne sie bereits gespeichert zu haben.

Ein automatischer Reload würde diese Eingaben verwerfen.

Deshalb gilt:

ActionReload_<NAME> fehlt
→ kein Reload

ActionReload_<NAME>=
→ kein Reload

ActionReload_<NAME>=FALSE
→ kein Reload

ungültiger Wert
→ kein Reload

ActionReload_<NAME>=TRUE
→ Reload nach erfolgreicher Action

Beispiel ohne Reload:

Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

Beispiel mit ausdrücklich gewünschtem Reload:

Action_AKTUALISIEREN=CONFIG\Scripts\WEB\AKTUALISIEREN.MCFSCR
ActionReload_AKTUALISIEREN=TRUE

Schutz ungespeicherter Eingaben bei ActionReload

Auch wenn:

ActionReload_AKTUALISIEREN=TRUE

konfiguriert ist, werden ungespeicherte Formulareingaben nicht einfach verworfen.

Hat der Benutzer das aktuell geöffnete Formular verändert:

Action wird ausgeführt
Reload wird anschließend unterdrückt
Eingaben bleiben erhalten

Die Action löst dabei keine automatische Speicherung aus.

Es erfolgt insbesondere kein:

automatisches Save
stilles Verwerfen
automatisches Überschreiben

Die Erkennung ungespeicherter Änderungen verwendet dieselbe Feldsammlung, die auch für den normalen Save-Pfad verwendet wird.

Actions speichern das Formular nicht

Eine Action bedeutet nicht automatisch:

Speichern

Beispiel:

<button type="button" data-mcdms-action="DRUCKEN">
    Drucken
</button>

führt das konfigurierte Script aus.

Ungespeicherte Eingaben des Formulars werden dadurch nicht automatisch in SQL geschrieben.

Das Speichern bleibt ausschließlich der normale, ausdrücklich ausgelöste Speichervorgang.

SQL-Formular und Action-Ergebnisse

Bei bestehenden SQL-Datensätzen bleibt SQL die einzige Wahrheit für die Formularfelder.

Eine Action darf deshalb nicht beliebige PatientVars nachträglich als vermeintliche SQL-Feldwerte in den Datensatz mischen.

Für typische Aktionen wie:

Drucken
PDF
Freigeben
E-Mail
Workflow

ist dies auch nicht notwendig.

Die Benutzerbestätigung erfolgt über das Action-Button-Feedback.

Keine separate ActionResult-Architektur

Die MCDMS-WebAkte benötigt keine zusätzliche Konfiguration wie:

ActionResult_...

für normale SQL-Actions.

Die Trennung bleibt bewusst einfach:

SQL-Formular
= SQL-Datensatz bearbeiten

Action
= zusätzlichen Vorgang ausführen

Dadurch bleibt die Konfiguration übersichtlich und die Datenherkunft eindeutig.

Beispiel: SQL-Formular mit Action

[FORMULAR_LEISTUNGSERFASSUNG]
Title=Leistungs- & Minutenerfassung
HTML=HTML\Pflege\LeistungsMinutenerfassung.html
RenderMode=Document
Edit=TRUE
MultiRecord=TRUE
Delete=TRUE
AllowDuplicate=TRUE
Roles=
ScriptLoadHTML=CONFIG\Scripts\WEB\load.mcfscr
ScriptSaveHTML=CONFIG\Scripts\WEB\save.mcfscr
ScriptDelete=CONFIG\Scripts\WEB\delete.mcfscr
Database=FRM_LEISTUNGSERFASSUNG;FRMID;PatientID
OrderBy=FRMID;DESC
DoubleSaveButton=TRUE
Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

HTML:

<button type="button" data-mcdms-action="DRUCKEN">
    Drucken
</button>

Ablauf:

Benutzer bearbeitet Formular
        ↓
klickt Drucken
        ↓
Drucken...
        ↓
MCDMS-Script wird ausgeführt
        ↓
Ausgeführt
        ↓
Drucken

Das Formular wird dabei standardmäßig nicht neu geladen.

Noch nicht gespeicherte Eingaben bleiben erhalten.

Beispiel: Action mit Reload

Action_AKTUALISIEREN=CONFIG\Scripts\WEB\AKTUALISIEREN.MCFSCR
ActionReload_AKTUALISIEREN=TRUE

HTML:

<button type="button" data-mcdms-action="AKTUALISIEREN">
    Aktualisieren
</button>

Sind keine ungespeicherten Änderungen vorhanden:

Action
→ erfolgreich
→ Reload derselben Form / RecordId

Sind ungespeicherte Änderungen vorhanden:

Action
→ erfolgreich
→ Reload wird unterdrückt
→ Eingaben bleiben erhalten

Beispiel: datenbanklose Action-Seite

FORMULARE.INI:

[FORMULAR_WEBTEST_ACTION]
Title=Webtest Aktionen
HTML=HTML\Webtest\WEBTEST_ACTION.HTML
RenderMode=Document
Edit=FALSE
MultiRecord=FALSE
Delete=FALSE
Roles=
ScriptLoadHTML=
ScriptSaveHTML=
ScriptDelete=
Database=
Action_TEST=CONFIG\Scripts\WEB\WEBTEST_ACTION.MCFSCR

HTML:

<!doctype html>
<html lang="de">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Webtest Aktionen</title>
</head>

<body>

<button type="button" data-mcdms-action="TEST">
    Testaktion ausführen
</button>

<div style="white-space: pre-line;">
    <strong>TESTVAR:</strong>
    [#TESTVAR#]
</div>

</body>
</html>

Script:

TESTVAR=UserID={USERID}{RET}"ABC123"
TESTVAR={TESTVAR}{RET}{RET}Funktioniert!

Damit kann eine datenbanklose Seite MCDMS-Scripts ausführen und deren PatientVar-Ergebnisse anschließend darstellen.

Gestaltung von Action-Buttons

Action-Schaltflächen sind normale HTML-Buttons und können mit CSS gestaltet werden.

Beispiel:

<style>
.action-button {
    display: inline-flex;
    align-items: center;
    justify-content: center;

    min-width: 195px;
    height: 48px;
    padding: 0 18px;

    border: 1px solid #2f6fed;
    border-radius: 7px;

    background: #3d7cf3;
    color: white;

    font-family: Arial, sans-serif;
    font-size: 14px;
    font-weight: 700;

    cursor: pointer;
}
</style>

HTML:

<button
    type="button"
    class="action-button"
    data-mcdms-action="DRUCKEN">
    Drucken
</button>

Das Aussehen des Buttons gehört vollständig zum jeweiligen Formular-HTML.

Die Action-Funktion selbst bleibt davon unabhängig.

Wichtiger Hinweis zu interaktiven Scriptbefehlen

Die MCDMS-WebAkte führt .MCFSCR-Scripts serverseitig über die MCDMS5API aus.

Die WebAkte läuft als Windows-Dienst.

Damit steht für Scripts kein normaler interaktiver Windows-Desktop zur Verfügung.

Interaktive Scriptbefehle dürfen deshalb in WebAkte-Scripts nicht verwendet werden.

Problematisches Beispiel:

DLG=DLGMESSAGE{Ich bin das Load-Script}

Solche Funktionen können den serverseitigen Ablauf blockieren.

Betroffen sind insbesondere:

Dialogfenster
Messageboxen
Eingabeaufforderungen
Desktop-Interaktionen
sonstige Funktionen, die eine Benutzeraktion auf dem Windows-Desktop erwarten

Für WebAkte-Scripts gilt deshalb:

Scripts müssen vollständig serverseitig und ohne Benutzerinteraktion ausführbar sein.

Geeignet sind beispielsweise Scripts, die:

MCDMS-Variablen lesen
MCDMS-Variablen setzen
Werte berechnen
Daten vorbereiten
fachliche Prüfungen durchführen
serverseitige Abläufe auslösen

Fehlersuche bei ScriptLoadHTML

Wenn ein Formular mit konfiguriertem ScriptLoadHTML nicht geladen werden kann, kann das Script testweise deaktiviert werden.

Aus:

ScriptLoadHTML=CONFIG\Scripts\WEB\load.mcfscr

wird vorübergehend:

ScriptLoadHTML=

Lädt das Formular anschließend korrekt, sollte das Load-Script insbesondere auf:

interaktive Befehle
ungültige Variablen
fachliche Fehler
nicht vorhandene Ressourcen

geprüft werden.

Formularfehler und Fehler-ID

Kann ein Formular technisch nicht geladen werden, zeigt die WebAkte eine Fehler-ID an.

Beispiel:

Formular konnte nicht geladen werden.
Fehler-ID: 20260915-142451-523B

Die Fehler-ID wird auch im Server-Log hinterlegt.

Dadurch kann ein beim Benutzer auftretender Fehler eindeutig einem Logeintrag zugeordnet werden.

Ein Diagnoseeintrag kann beispielsweise Informationen enthalten über:

Formular
Verarbeitungsschritt
Laufzeit
HTML-Größe
Datensatzanzahl
Anzahl unbekannter Templatevariablen
ExceptionType
ExceptionMessage
Fehler-ID

Patienteninhalte oder medizinische Formularwerte werden dabei nicht als Diagnoseinhalt protokolliert.

Detaillierte Formular-Ladediagnose

Für schwierige Fehlerfälle kann in:

{APPPATH}\Web\WEB.INI

unter:

[LOGGING]

gesetzt werden:

DetailedFormDiagnostics=TRUE

Dann können einzelne Verarbeitungsschritte mit Laufzeiten protokolliert werden.

Beispielsweise:

Config
DatabaseLoad
DatabaseReload
HtmlFile
ScriptLoad
TemplateReplacement
Render
Response

Im normalen Betrieb sollte verwendet werden:

DetailedFormDiagnostics=FALSE

Fehlt der Eintrag, gilt ebenfalls:

FALSE

Bei FALSE erzeugen erfolgreiche Formularaufrufe keine zusätzlichen detaillierten Diagnose-Logzeilen.

Unbekannte Templatevariablen

Wenn eine im HTML verwendete Templatevariable nicht aufgelöst werden kann, kann ein entsprechender Hinweis im Server-Log erscheinen.

Beispiel:

WARN FORM Unbekannte MCDMS-Templatevariable; Variable=...

Eine unbekannte Variable führt nicht automatisch dazu, dass das gesamte Formular fehlschlägt.

Bei mehrfacher Verwendung derselben Variable wird diese innerhalb eines Formular-Ladevorgangs nur einmal aufgelöst und nur einmal als unbekannt behandelt.

Sicherheit

Formularoperationen erfolgen immer serverseitig im Kontext:

aktueller Session
angemeldeter Benutzer
ausgewählter Patient
aktueller Datensatz
konfigurierte Rollen

SQL-Zugriffe werden nicht aus frei übermittelten Tabellen- oder Feldnamen des Browsers zusammengesetzt.

Die relevanten Tabellen- und Felddefinitionen stammen aus der serverseitigen:

FORMULARE.INI

Sicherheit bei Actions

Auch Actions werden serverseitig kontrolliert.

Der Browser übermittelt beispielsweise nur:

DRUCKEN

nicht jedoch:

CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

Der Server sucht die Action ausschließlich in der Konfiguration des aktuell geöffneten Formulars.

Beispiel:

Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

Nicht konfigurierte Actions können dadurch nicht beliebig vom Browser ausgeführt werden.

Zusätzlich gelten weiterhin:

gültige Session
angemeldeter Benutzer
aktiver Patient
Formularberechtigung
Rollenprüfung
Request-Schutz
serverseitige Scriptpfad-Prüfung

PatientID und SQL-Sicherheit

Die Patientenzuordnung eines SQL-Datensatzes stammt ausschließlich aus der aktuellen serverseitigen Session.

Ein HTML-Feld, Scriptwert oder Browserparameter darf nicht eigenständig einen anderen Patienten für den SQL-Datensatz festlegen.

Dadurch wird verhindert, dass Formulardaten versehentlich einem anderen Patienten zugeordnet werden.

Speichern eines vorhandenen Datensatzes

Bei einem bestehenden Datensatz gilt:

SQL ist die Datenquelle

Beim Speichern werden ausschließlich kontrollierte Formularfelder und ausdrücklich sichere Scriptwerte berücksichtigt.

Technische SQL-Spalten werden geschützt.

Dazu gehören insbesondere:

Primärschlüssel
Identity
Computed
rowversion
Patientenfeld

Speichern eines neuen Datensatzes

Bei einem neuen Datensatz:

+ Neu

wird kein vorheriger Record-Kontext weiterverwendet.

Nach erfolgreichem INSERT erhält das Formular die neue RecordId.

Ab diesem Zeitpunkt wird der Datensatz als bestehender SQL-Datensatz behandelt.

Duplizieren

Duplicate ist ein ausdrücklicher Kopiervorgang.

Nur dort dürfen Werte eines vorhandenen Datensatzes kontrolliert in einen neuen Datensatz übernommen werden.

Dies ist bewusst getrennt von:

+ Neu

und vom normalen Laden bestehender Datensätze.

Formularänderungen und Konfigurationsänderungen

HTML-Dateien werden beim Öffnen des Formulars neu gelesen.

Änderungen am HTML können deshalb normalerweise nach erneutem Öffnen sichtbar werden.

Die FORMULARE.INI wird dagegen beim Start des WebServers geladen.

Werden beispielsweise geändert:

Database
Roles
ScriptLoadHTML
ScriptSaveHTML
ScriptDelete
Action_*
ActionReload_*

muss der WebServer anschließend neu gestartet werden.

Beispiel:

Stop-Service MCDMS.WebAkte
Start-Service MCDMS.WebAkte

APF-Formulare und HTML

APF-Formulare können nicht direkt im Browser angezeigt werden.

Sie müssen zunächst mit dem MCDMS Designer in browserfähiges HTML umgewandelt werden.

Der Ablauf ist:

APF
→ MCDMS Designer
→ HTML
→ MCDMS-WebAkte
→ Browser

Die WebAkte verarbeitet ausschließlich das erzeugte HTML.

Große und mehrseitige Formulare

Die MCDMS-WebAkte unterstützt auch umfangreiche HTML-Formulare mit mehreren Seiten.

Solche Formulare können beispielsweise enthalten:

mehrere Formularseiten
viele Templatevariablen
wiederholt vorkommende Variablen
zahlreiche Formularfelder
eingebettete Base64-Bilder
große Dokumentlayouts

Die Formularverarbeitung ist dafür optimiert.

Wiederholt vorkommende Templatevariablen werden nicht unnötig mehrfach aufgelöst.

Eingebettete Base64-Bilder werden nicht unnötig dekodiert und neu verarbeitet.

Für solche Formulare eignet sich insbesondere:

RenderMode=Document

Empfehlung für neue SQL-Formulare

Für ein neues datenbankgebundenes Formular empfiehlt sich folgende Vorgehensweise:

  1. Formular im MCDMS Designer erstellen bzw. vorhandenes APF-Formular übernehmen.
  2. Formular in HTML konvertieren.
  3. HTML unter:
{APPPATH}\Web\HTML

im passenden Aktenbereich ablegen.

  1. Formulareintrag in FORMULARE.INI erstellen.
  2. SQL-Zuordnung über:
Database=Tabelle;Primärschlüssel;Patientenfeld

definieren.

  1. Bei MultiRecord-Formularen gegebenenfalls:
OrderBy=Spalte;ASC|DESC

festlegen.

  1. Nur wenn erforderlich:
ScriptLoadHTML
ScriptSaveHTML
ScriptDelete

ergänzen.

  1. Bei langen Formularen gegebenenfalls:
DoubleSaveButton=TRUE

setzen.

  1. Zusätzliche fachliche Funktionen bei Bedarf über:
Action_NAME=...

ergänzen.

  1. Actions standardmäßig ohne Reload betreiben.
  2. Nur wenn fachlich ausdrücklich erforderlich:
ActionReload_NAME=TRUE

setzen.

  1. Formular zunächst ohne interaktive Scriptbefehle testen.
  2. Bei Ladeproblemen Fehler-ID und gegebenenfalls DetailedFormDiagnostics verwenden.

Empfehlung für neue Action-/Workflow-Seiten

Wenn keine SQL-Datensatzbearbeitung erforderlich ist, kann ein datenbankloses Formular verwendet werden.

Beispiel:

[FORMULAR_WORKFLOW]
Title=Workflow
HTML=HTML\Start\WORKFLOW.HTML
RenderMode=Document
Edit=FALSE
MultiRecord=FALSE
Delete=FALSE
Roles=
ScriptLoadHTML=
ScriptSaveHTML=
ScriptDelete=
Database=
Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR
Action_FREIGEBEN=CONFIG\Scripts\WEB\FREIGEBEN.MCFSCR

Damit kann eine Seite reine MCDMS-Funktionen und Workflows bereitstellen, ohne dafür eine eigene SQL-Tabelle zu benötigen.

Grundprinzip

Die MCDMS-WebAkte trennt bewusst:

Darstellung
HTML / CSS

Datenhaltung
SQL / MCDMS

fachliche Logik
MCDMS-Scripts

Interaktion
WebAkte-Actions

SQL-Formulare bleiben SQL-Formulare.

Actions ergänzen diese lediglich um zusätzliche Vorgänge.

Datenbanklose Seiten können dagegen gezielt für Dashboards, Workflows und Scriptfunktionen verwendet werden.

Dadurch können bestehende MCDMS-Strukturen weiterverwendet und gleichzeitig moderne browserbasierte Oberflächen aufgebaut werden.