2.1 Architekturübersicht
Der MCDMS WebService ist bewusst einfach aufgebaut und besteht aus wenigen, klar voneinander getrennten Komponenten.
HTTPS / REST
+--------------------------------------------------+
| |
| Partner- oder Fremdsystem |
| |
| VB.NET • C# • Java • Python • Batch • curl |
| |
+-------------------------+------------------------+
|
|
v
+--------------------------------------------------+
| MCDMS WebService |
|--------------------------------------------------|
| |
| • HTTPS |
| • API-Key Prüfung |
| • IK-Prüfung |
| • REST-Endpunkte |
| • Datei-Upload |
| • Datei-Download |
| • Dateiliste |
| • Datei löschen |
| |
+-------------------------+------------------------+
|
|
v
+--------------------------------------------------+
| Dateisystem |
|--------------------------------------------------|
| |
| Daten |
| ├── Eingang |
| │ ├── IK 123456789 |
| │ └── IK 987654321 |
| │ |
| └── Ausgang |
| ├── IK 123456789 |
| └── IK 987654321 |
| |
+--------------------------------------------------+
Der WebService bildet die zentrale Kommunikationsschnittstelle zwischen externen Anwendungen und dem Dateisystem.
2.2 Komponenten
Der WebService besteht aus den folgenden Komponenten:
| Komponente | Aufgabe |
|---|---|
| Windows-Dienst | Stellt den WebService dauerhaft bereit |
| REST-API | Entgegennahme und Bereitstellung von Dateien |
| HTTPS | Verschlüsselte Kommunikation |
| API-Key | Authentifizierung des Partners |
| IK-Prüfung | Zugriff ausschließlich auf freigegebene IK |
| Dateisystem | Speicherung der Dateien |
| Protokollierung | Nachvollziehbarkeit und Fehleranalyse |
Es werden keine Datenbanken benötigt.
2.3 Kommunikationsmodell
Die Kommunikation erfolgt ausschließlich über HTTPS.
Der WebService arbeitet nach dem klassischen Request-/Response-Prinzip.
Partnerprogramm
│
│ POST
▼
WebService
│
Datei speichern
│
HTTP 200
oder
Partnerprogramm
│
│ GET
▼
WebService
│
Datei lesen
│
HTTP 200 + Datei
Der Dienst verarbeitet die Datei selbst nicht. Er speichert oder liefert sie lediglich aus.
2.4 Dateiorganisation
Alle Dateien werden im Dateisystem abgelegt.
Die Ablage erfolgt grundsätzlich getrennt nach:
- Eingang
- Ausgang
- IK
Beispiel:
Daten
│
├── Eingang
│ ├── 123456789
│ │ Auftrag.xml
│ │ Auftrag.xml.meta.json
│ │
│ └── 987654321
│ Befund.pdf
│ Befund.pdf.meta.json
│
└── Ausgang
├── 123456789
│ Ergebnis.xml
│ Ergebnis.xml.meta.json
│
└── 987654321
Labor.pdf
Labor.pdf.meta.json
Jede Datei besitzt eine zugehörige Metadatendatei.
Diese enthält beispielsweise Informationen über:
- Dateiname
- Erstellungszeitpunkt
- Dateigröße
- Inhaltstyp
- Uploadinformationen
Dadurch bleiben Nutzdaten und Verwaltungsinformationen sauber getrennt.
2.5 Authentifizierung
Jede Anfrage muss einen gültigen API-Key enthalten.
Zusätzlich wird geprüft, ob die angegebene IK für den Zugriff freigegeben wurde.
Anfrage
│
▼
API-Key gültig?
│
├── Nein → HTTP 401
│
▼
IK freigegeben?
│
├── Nein → HTTP 403
│
▼
Anfrage ausführen
Dadurch kann jede Klinik ausschließlich auf ihren eigenen Datenbestand zugreifen.
2.6 Dateiverarbeitung
Der WebService interpretiert keine Dateien.
Folgende Dateitypen sind beispielsweise möglich:
- XML
- JSON
- ZIP
- CSV
- TXT
- JPEG
- PNG
- DICOM
- beliebige Binärdateien
Die Datei wird unverändert gespeichert.
2.7 Plattformunabhängigkeit
Der WebService kann von nahezu jeder Software genutzt werden.
Beispiele:
- VB.NET
- C#
- Java
- Delphi
- Python
- PHP
- PowerShell
- Batch-Dateien
- Linux-Skripte
- Docker-Container
Voraussetzung ist lediglich die Möglichkeit, HTTPS-Anfragen zu senden.
2.8 Trennung von Fachlogik und Transport
Ein wesentliches Architekturprinzip des MCDMS WebService besteht darin, Transport und Fachlogik strikt voneinander zu trennen.
Der WebService übernimmt ausschließlich den sicheren Transport von Dateien.
Fachliche Funktionen wie beispielsweise:
- XML-Erzeugung
- HL7
- FHIR
- Clinisys-Anbindungen
- Patientenverwaltung
- Befundverarbeitung
- Auftragslogik
- Validierungen
gehören ausdrücklich nicht zum Aufgabenbereich des WebService.
Dadurch bleibt der Dienst schlank, performant und universell einsetzbar.
