Wie können wir helfen?

View Categories

07 Exemplarische Vorgehensweise für ein Testsystem

0:00 8:17

Ziel

Dieses Kapitel beschreibt beispielhaft, wie eine MCDMS WebAkte in einer Testumgebung eingerichtet und schrittweise geprüft werden kann.

Ziel ist eine Umgebung, die dem späteren Klinikbetrieb möglichst nahekommt:

MCDMS-Testinstallation
↓
interner DNS-Name
↓
HTTPS-Zertifikat
↓
MCDMS WebAkte
↓
MCDMS-Benutzer
↓
Testpatient
↓
erstes Formular
↓
Rechte / Scripts / Datenbank

Für produktive Kliniksysteme sollten vorhandene DNS-, PKI-, Zertifikats- und Clientverwaltungsstrukturen verwendet werden.

1. Testsystem festlegen

Vor Beginn sollten mindestens folgende Werte bekannt sein:

MCDMS APPPATH
Servername
IP-Adresse
DNS-Name der WebAkte
HTTPS-Port
Dienstkonto
Testbenutzer
Testpatient

Beispiel:

APPPATH:
D:\Kliniken\TEST\MCDMS

Server:
TEST-MCDMS01

IP-Adresse:
192.168.2.50

DNS:
mcdms-webakte.test.local

HTTPS-Port:
8443

Der DNS-Name sollte während der gesamten Einrichtung identisch verwendet werden.

Also:

DNS
mcdms-webakte.test.local

Zertifikat SAN
mcdms-webakte.test.local

HTTPS-Prefix
https://mcdms-webakte.test.local:8443/

Browser
https://mcdms-webakte.test.local:8443/

2. MCDMS-Testumgebung prüfen

Bevor die WebAkte eingerichtet wird, sollte die vorhandene MCDMS-Testinstallation selbst funktionieren.

Prüfen:

  • MCDMS startet
  • MCDMS-Benutzer kann sich anmelden
  • Testpatient vorhanden
  • Patient kann in MCDMS geöffnet werden
  • MCDMS5API installiert und registriert
  • verwendete SQL-Verbindung funktioniert
  • benötigte Access-Datenbanken erreichbar
  • MCDMS-Scripts grundsätzlich ausführbar

Die WebAkte sollte nicht zur Fehlersuche einer bereits fehlerhaften MCDMS-Testinstallation verwendet werden.

3. Internen DNS-Namen anlegen

Auf dem internen DNS-Server wird ein Eintrag für die WebAkte angelegt.

Beispiel:

mcdms-webakte.test.local
→ 192.168.2.50

Auf einem Client prüfen:

Resolve-DnsName mcdms-webakte.test.local

Die zurückgegebene IP-Adresse muss dem WebAkte-Server entsprechen.

4. Serverzertifikat bereitstellen

Wenn bereits eine interne Zertifizierungsstelle vorhanden ist, sollte diese verwendet werden.

Benötigt wird ein Serverzertifikat für:

mcdms-webakte.test.local

Der DNS-Name muss im Subject Alternative Name enthalten sein.

Das Zertifikat wird im Zertifikatspeicher des lokalen Computers installiert:

Lokaler Computer
└─ Persönlich
   └─ Zertifikate

Prüfen:

Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey

Erwartet:

HasPrivateKey = True

Den Thumbprint des Serverzertifikats notieren.

5. Optional: eigene Test-CA

Nur wenn für das Testsystem keine vorhandene Zertifizierungsstelle genutzt werden kann, kann eine eigene Test-CA eingerichtet werden.

Diese sollte ausschließlich für die Testumgebung verwendet werden.

Für einen produktiven Klinikbetrieb ist normalerweise keine eigene WebAkte-Zertifizierungsstelle erforderlich.

Die WebAkte verwendet dort das von der Klinik bereitgestellte Serverzertifikat.

Die bisherige Testsystembeschreibung enthält hierfür bereits einen ausführlichen optionalen Test-CA-Ablauf. 07 Exemplarische Vorgehensweise…

6. Clientvertrauen prüfen

Der Testclient muss der ausstellenden Zertifizierungsstelle vertrauen.

Beim Browseraufruf darf später keine Zertifikatswarnung erscheinen.

In einer realen Klinik erfolgt die Zertifikatsverteilung üblicherweise zentral, beispielsweise über:

  • Active Directory
  • Gruppenrichtlinien
  • MDM

7. WebAkte bereitstellen

Das freigegebene Deployment wird nach:

{APPPATH}\Web

kopiert.

Beispiel:

D:\Kliniken\TEST\MCDMS\Web

Die wesentliche Struktur lautet:

Web\
├─ WEB.INI
├─ FORMULARE.INI
├─ PROGRAM\
├─ SETUP\
├─ LOGS\
├─ HTML\
├─ CSS\
├─ JS\
└─ IMAGES\

8. WEB.INI für das Testsystem vorbereiten

Beispiel:

[SERVER]
EnvironmentName=Production
Prefixes=https://mcdms-webakte.test.local:8443/
AllowedHosts=mcdms-webakte.test.local
AllowInsecureHttpDevelopment=FALSE

Auch ein produktionsnahes Testsystem sollte bereits mit HTTPS betrieben werden.

Weitere Konfigurationen wie Patientensuche, Session und Aktenstruktur können anschließend ergänzt werden.

9. WebAkte installieren

PowerShell 5.1 als Administrator öffnen.

Zum Setup-Verzeichnis wechseln:

cd "D:\Kliniken\TEST\MCDMS\Web\SETUP"

Bei lokaler MCDMS-Installation beispielsweise:

.\Install.ps1 -ServiceAccount LocalSystem

Während der Installation werden unter anderem benötigt:

HTTPS-Prefix
CertificateThumbprint
MCDMS APPPATH

Beispiel:

HTTPS-Prefix:
https://mcdms-webakte.test.local:8443/

CertificateThumbprint:
<Thumbprint des Serverzertifikats>

APPPATH:
D:\Kliniken\TEST\MCDMS

Das Setup richtet die erforderlichen Komponenten ein, insbesondere:

  • WEB.INI-Serverkonfiguration
  • HTTP.sys
  • HTTPS-Zertifikatbindung
  • erforderliche URLACL
  • gegebenenfalls Firewallregel
  • Windows-Dienst
  • automatischen Start
  • Recovery-Konfiguration

10. Windows-Dienst prüfen

Get-Service MCDMS.WebAkte

Erwartet:

Status : Running

Falls erforderlich:

Start-Service MCDMS.WebAkte

11. HTTPS-Port prüfen

Beispiel:

netstat -ano | findstr ":8443"

oder vom Client:

Test-NetConnection mcdms-webakte.test.local -Port 8443

Erwartet:

TcpTestSucceeded : True

12. Status-Endpunkt prüfen

Invoke-WebRequest `
  https://mcdms-webakte.test.local:8443/api/status `
  -UseBasicParsing

Erwartet:

StatusCode : 200

Damit ist zunächst nur bestätigt, dass der WebServer erreichbar ist.

13. Browserzugriff testen

Im Browser:

https://mcdms-webakte.test.local:8443/

Es darf keine Zertifikatswarnung erscheinen.

Danach zunächst nur die Grundfunktionen prüfen:

Login
↓
Patientenliste
↓
Patientensuche
↓
Patient auswählen
↓
Patientenstammblatt
↓
Navigation

14. MCDMS-Login testen

Mit einem vorhandenen MCDMS-Testbenutzer anmelden.

Prüfen:

  • Anmeldung erfolgreich
  • Benutzername korrekt
  • Klinikname korrekt
  • keine erneute Anmeldeschleife
  • keine COM-/MCDMS-Fehler im Log

15. Testpatient auswählen

Einen bekannten Testpatienten suchen.

Prüfen:

  • Patient erscheint in der Liste
  • Suche funktioniert
  • Patient kann ausgewählt werden
  • Patientenkopf wird angezeigt
  • Patientenwechsel funktioniert
  • „Zuletzt“ wird aktualisiert

Für alle weiteren Tests sollte ausschließlich ein freigegebener Testpatient verwendet werden.

16. Erstes einfaches Formular anlegen

Als erstes sollte bewusst ein sehr einfaches SQL-Formular verwendet werden.

Beispiel:

[FORMULAR_TEST]
Title=Testformular
HTML=HTML\Test\TEST.html
Edit=TRUE
MultiRecord=TRUE
Delete=TRUE
AllowDuplicate=TRUE
Database=FRM_WEBTEST;FRMID;PatientID
OrderBy=FRMID;DESC

Beispieltabellenstruktur:

FRMID       int Identity PK
PatientID   int
TEXT1       nvarchar(255)
DATUM       date
AKTIV       bit

HTML:

<!doctype html>
<html lang="de">
<head>
    <meta charset="utf-8">
    <title>Testformular</title>
</head>

<body>

<div class="testformular">

    <label>
        Text
        <input type="text"
               name="TEXT1"
               data-field="TEXT1">
    </label>

    <label>
        Datum
        <input type="date"
               name="DATUM"
               data-field="DATUM">
    </label>

    <label>
        <input type="checkbox"
               name="AKTIV"
               data-field="AKTIV">
        Aktiv
    </label>

</div>

</body>
</html>

17. Formularfunktion testen

Der Test sollte mindestens umfassen:

+ Neu
↓
Werte eingeben
↓
Speichern
↓
Datensatz erneut öffnen
↓
Werte vergleichen
↓
ändern
↓
erneut speichern
↓
löschen
↓
duplizieren

Dabei prüfen:

  • PatientID wurde korrekt gesetzt
  • technischer Primärschlüssel wurde automatisch erzeugt
  • Browser kann PatientID oder PK nicht manipulieren
  • Datensatz erscheint nur beim richtigen Patienten

18. Rechte testen

Jetzt sollte nicht nur mit einem Administrator getestet werden.

Empfohlen sind mindestens:

Administrator
Benutzer mit Recht 3
Benutzer mit Recht 2
Benutzer mit Recht 1
Benutzer ohne Recht

Bei einem MCDMS-Formular beispielsweise:

MATCHCODE=TEST_WEB

Prüfen:

  • Anzeige
  • Bearbeitung
  • Neuerfassung
  • Löschen
  • Eigentümerregel

Auch negative Tests durchführen:

Ein Benutzer ohne Berechtigung darf das Formular nicht allein durch Eingabe einer URL öffnen können.

19. ScriptLoadHTML testen

Beispiel:

ScriptLoadHTML=CONFIG\Scripts\WEB\Test\load.mcfscr

Das Script kann beispielsweise eine PatientVar setzen.

Im HTML:

<div>[#TESTVAR#]</div>

Prüfen:

  • Script läuft
  • richtiger Patientenkontext
  • Wert wird angezeigt
  • keine interaktive Desktopfunktion benötigt

20. ScriptSaveHTML testen

Beispiel:

ScriptSaveHTML=CONFIG\Scripts\WEB\Test\save.mcfscr

Test:

Datensatz speichern
↓
SQL kontrollieren
↓
Scriptwirkung kontrollieren
↓
Formular erneut laden

Wichtig:

ScriptSaveHTML läuft nach dem SQL-Commit.

Ein Scriptfehler darf daher nicht mit einem fehlgeschlagenen SQL-Speichern verwechselt werden.

21. Master-/Detailformular testen

Erst wenn das einfache Formular funktioniert, sollte ein Master-/Detailformular eingerichtet werden.

Beispiel:

Database=FRM_TEST;FRMID;PatientID#FRM_TEST_DETAIL;ID;FRMID;PatientID

Prüfen:

  • Master speichern
  • mehrere Detailzeilen
  • Zeile hinzufügen
  • Zeile ändern
  • Zeile entfernen
  • vollständiges Speichern
  • erneut laden
  • Duplizieren
  • Löschen

22. Mehrere Detailbereiche testen

Danach können mehrere sichtbare Detaillisten verwendet werden:

<tbody data-mcdms-detail-list></tbody>

<tbody data-mcdms-detail-list></tbody>

<tbody data-mcdms-detail-list></tbody>

mit genau einem gemeinsamen:

<template data-mcdms-detail-row>

Die fachliche Verteilung, beispielsweise nach einem Feld BEREICH, erfolgt durch das Formular.

Das ist beispielsweise das Prinzip des Medikationsplans:

REGEL
BESONDERE_ZEITEN
SELBST

23. RecordView=LIST testen

Anschließend kann ein Listenformular getestet werden.

Beispiel:

MultiRecord=TRUE
RecordView=LIST
Database=DIAGNOSEN;ID;PatientID
OrderBy=ICDRANG;ASC

Testen:

  • mehrere vorhandene Datensätze
  • neue Zeile
  • ändern
  • löschen
  • duplizieren
  • Reihenfolge
  • Speichern
  • erneutes Laden

24. Native MCDMS-Akte testen

Wenn die native Aktenintegration genutzt werden soll:

[NATIVE_AKTE]
Enabled=TRUE
Typ=...

Prüfen:

  • vorhandene native Akteneinträge sichtbar
  • Gruppen / Untergruppen korrekt
  • Dokumente öffnbar
  • Rechte korrekt
  • Status korrekt
  • externe Änderungen nach erneutem Öffnen des Zweigs sichtbar

25. Fehlerdiagnose testen

Es empfiehlt sich, im Testsystem bewusst einen kontrollierten Fehler zu erzeugen.

Beispielsweise ein HTML-Masterfeld, für das keine reale SQL-Spalte vorhanden ist.

Dann prüfen:

  • Benutzer erhält verständlichen Fehlerdialog
  • Fehler-ID vorhanden
  • Serverlog enthält dieselbe Fehler-ID
  • technische Details stehen nur im Log
  • keine medizinischen Feldwerte werden unnötig protokolliert

Logverzeichnis:

{APPPATH}\Web\LOGS

26. Patientenwechsel testen

Besonders wichtig:

Patient A auswählen
↓
Formular öffnen
↓
Patient B auswählen
↓
Formular öffnen

Prüfen:

  • kein Datensatz von Patient A sichtbar
  • keine PatientVar-Werte vermischt
  • RecordIDs nicht patientenübergreifend verwendbar
  • Navigation entspricht Patient B

27. Direkt-URLs testen

Beispiele:

/1043
/1043/medikation
/1043/medikation/FORMULAR_MEDIKATIONSPLAN
/1043/medikation/FORMULAR_MEDIKATIONSPLAN/24

Prüfen:

  • authentifizierter gültiger Deep-Link funktioniert
  • falscher Patient wird nicht akzeptiert
  • falsches Formular wird nicht akzeptiert
  • fehlendes Recht verhindert den Zugriff

28. Browser und unterschiedliche Bildschirmgrößen

Mindestens testen:

  • aktueller Chrome/Edge auf Windows
  • Desktopbreite
  • Tabletbreite
  • Smartphonebreite, sofern vorgesehen
  • Hoch-/Querformat

Zu prüfen sind insbesondere:

  • Navigation
  • Formulare
  • Tabellen
  • Dialoge
  • Save-Buttons
  • Scrollen
  • Druckdarstellung

29. Abschlussprüfung des Testsystems

Vor einer Freigabe sollte mindestens folgende Kette vollständig funktionieren:

HTTPS
✓

Login
✓

Patientensuche
✓

Patientenauswahl
✓

Patientenwechsel
✓

Navigation
✓

Formular laden
✓

Datensatz neu
✓

Datensatz speichern
✓

Datensatz ändern
✓

Datensatz löschen
✓

Rechte
✓

Scripts
✓

Logging / Fehler-ID
✓

Je nach Einsatz zusätzlich:

Master/Detail
LIST
Native Akte
Dokumente
Status
Access
Mobile Darstellung

Produktive Übernahme

Ein erfolgreiches Testsystem bedeutet nicht, dass seine gesamte Konfiguration unverändert in eine Klinik kopiert werden sollte.

Produktiv werden von der jeweiligen Klinik insbesondere vorgegeben:

  • DNS
  • Serverzertifikat
  • Zertifizierungsstelle
  • Netzwerk
  • Firewall
  • Dienstkonto
  • MCDMS-APPPATH
  • SQL-Zugänge
  • Benutzer und Rechte
  • klinikspezifische Formulare
  • Aktenstruktur

Die MCDMS WebAkte benötigt keine eigene PKI.

Sie nutzt das für den jeweiligen Klinikbetrieb bereitgestellte Serverzertifikat. Das entspricht auch dem Abschluss der bisherigen Testsystembeschreibung. 07 Exemplarische Vorgehensweise…