Terminplanintegration an Kliniken am Beispiel von Betty24 und AGFA ORBIS

Diese technische Dokumentation soll die Wiederverwendbarkeit des Quelltextes ermöglichen. Im Folgenden wird auf die Projektstruktur, die einzelnen Module und letztlich auch auf den Build- und Deploy-Prozess Bezug genommen.
Bei Fragen stehe ich gerne per Mail zur Verfügung.

Tobias Dillig
mail@tdillig.de


Allgemein

Das Projekt ist in 3 Module gegliedert:

Modul “seed”

Im Folgenden ist die Struktur des “seed”-Moduls abgebildet.

de.tdillig.ba.seed
    model
        Appointment.java
        Patient.java
        MyFactory.java
    ApplicationLogger.java
    Config.java
    Myfhir.java
    RDFReader.java
    RDFWriter.java

Die Klasse “MyFactory” dient dem Instanziieren von “Appointment”- und “Patient”-Objekten aus CSV- oder RDF-Daten. Der ApplicationLogger stellt eine einfache Logging-Funktion für die Wrapper bereit. Die Config-Klasse stellt Funktionen und Variablen bereit, welche von den Config-Klassen der Wrapper überschrieben werden können. Die Myfhir-Klasse ist automatisch generiert und ermöglicht die einfache Verwendung des Myfhir-Vokabulars mit Apache Jena. Der RDFReader und RDFWriter stellen MessageBodyReader und MessageBodyWriter für Jersey bereit.

Beim Build-Prozess des Moduls wird eine JAR-Datei erstellt und diese als Bibliothek im lokalen Maven-Repository hinterlegt. Die beiden Wrapper haben diese Bibliothek als Abhängigkeit eingetragen, sodass diese erst kompiliert werden können nachdem das “seed”-Modul kompiliert wurde.

betty2rdf

Das Modul “betty2rdf” ist einer der beiden Wrapper. Im Folgenden ist die Struktur des “betty2rdf”-Moduls abgebildet.

de.tdillig.ba.betty2rdf
    controller
        Calendar.java
        CalendarList.java
    Config.java (erbt von de.tdillig.ba.seed.Config)

Die beiden Controller stellen folgende REST-APIs bereit:

HTTP-Methode Pfad Beschreibung
GET /betty2rdf/rest/CalendarList Auflistung aller bei Betty24 verfügbaren Kalender
GET /betty2rdf/rest/Calendar/[id] Auflistung aller neuen/geänderten Termine pro Kalender (id = KalenderId aus der Kalenderliste)
POST /betty2rdf/rest/Calendar/[id] Hinzufügen eines neuen Termins zum Kalender mit der entsprechenden ID

Die Requests an die APIs des Wrappers werden verarbeitet, indem die Betty24-API abgerufen wird. Die JSON-Daten von Betty24 werden mittels Apache Jena in RDF umgewandelt und - im per Content-Negotiation angeforderten Format - ausgegeben. Per Post übermittelte RDF-Daten werden per Apache Jena gelesen und an die Betty24-API zum Blocken von Zeitslots weitergegeben.

rdf2csv

Das Modul “rdf2csv” ist einer der beiden Wrapper. Im Folgenden ist die Struktur des “rdf2csv”-Moduls abgebildet.

de.tdillig.ba.rdf2csv
    controller
        Calendar.java
        CalendarList.java
    Config.java (erbt von de.tdillig.ba.seed.Config)

Die beiden Controller stellen folgende REST-APIs bereit:

HTTP-Methode Pfad Beschreibung
GET /rdf2csv/rest/CalendarList Auflistung aller bei Betty24 verfügbaren Kalender
GET /rdf2csv/rest/Calendar/[id] Auflistung aller neuen/geänderten Termine pro Kalender (id = KalenderId aus der Kalenderliste)
POST /rdf2csv/rest/Calendar/[id] Hinzufügen eines neuen Termins zum Kalender mit der entsprechenden ID

Die Requests an die APIs des Wrappers werden auf Basis einer internen Ordnerstruktur verarbeitet. Die vorliegenden CSV-Dateien werden mittels Apache Jena in RDF umgewandelt und - im per Content-Negotiation angeforderten Format - ausgegeben. Per Post übermittelte RDF-Daten werden per Apache Jena gelesen und als CSV-Datei in der Ordnerstruktur abgelegt.

Schritte zur Inbetriebnahme

  1. Installation des JAVA 8 SDK
  2. Installation und Starten des Tomcat 8 Webservers
  3. Module als Maven-Projekt in Editor (Eclipse oder Intellij) importieren
  4. Anpassung der “pom.xml” der Wrapper:
    Tomcat-Konfiguration anpassen (Zeile 52 und 53) für automatisches Deployment auf den Tomcat-Server
  5. Betty24-API-Zugangsdaten in der Config.java des “betty2rdf”-Moduls anpassen
  6. Basis-Ordner in der Config.java des “seed”-Moduls anpassen
  7. Build (install -X) des Seeds, dann der beiden anderen Wrapper durchführen
  8. Deployment der Wrapper ausführen: tomcat7:redeploy -e
  9. Die Wrapper sind nun bereit um von ldfu angesprochen zu werden