Das Teilprojekt 3 des Forschungsverbundes Care Regio, hat sich zum Ziel gesetzt, den Datenübertragungsprozess von pflegerelevanten Patientendaten im Rahmen einer Patientenüberleitung von einer Pflegeeinrichtung in eine andere zu digitalisieren und zu optimieren. In diesem Teilprojekt arbeiten die Technische Hochschule Augsburg, das Universitätsklinikum Augsburg und zwei kooperierenden Pflegeeinrichtungen in Augsburg zusammen an der Konzipierung und Implementierung eines PIO-ULB Editors. Unser Editor ist eine der ersten nutzbaren Implementierungen des PIO-ULB Standards überhaupt.

Der Editor soll PIO-ULB Dateien standardkonform generieren und importieren können. Ein nutzerfreundliches User Interface erleichtert dem Pflegepersonal das arbeiten mit dem neuen Standard. Beim Import von PIO-ULB Dateien wird die Datei auf Konformität zum Standard validiert.

Der PIO-ULB Editor kann auf unserer Website kostenfrei genutzt werden (siehe hier). Nach einer Anmeldung mittels Vor- und Nachnamen, können beliebige standardkonforme XML-Dateien (= PIOs) generiert und wieder importiert werden. Der angegebene Name wird automatisch als Autor im PIO-ULB hinterlegt.

Die eingetragenen Daten werden nur für die aktive Nutzungsdauer gespeichert und anschließend sofort gelöscht. Es gibt also keine Möglichkeit, Daten nach dem Schließen des Browserfensters oder einem Logout wiederherzustellen.

Der gesamte Quellcode des PIO-ULB Editors ist auf GitHub veröffentlicht und wird auf dem aktuellen Stand gehalten (siehe hier, Stand 09.10.2024).

Weitere Informationen zur Softwarearchitektur sind unter Punkt 3 zu finden.

Da alle Ergebnisse aus dem Care Regio Forschungsprojekt open source zur Verfügung stehen sollen, kann auch der Quellcode des PIO-ULB Editors für andere (auch kommerzielle) Projekte genutzt werden. Unser PIO-ULB Editor wurde im Dezember 2023 unter der Apache 2.0 Lizenz veröffentlicht.

Alle Komponenten des PIO-ULB Editors sind dockerisiert und können wie ein üblicher Docker Container gestartet werden. Folgende Komponenten / Docker Container müssen gestartet werden, damit der PIO-ULB Editor auf dem lokalen Computer funktioniert:

Wenn alle Komponenten gestartet wurden, kann der PIO-ULB Editor unter http://localhost:3000/ im Browser aufgerufen werden.

Detailliertere Informationen bezüglich des Starts der Docker Container beinhalten die README Dateien auf GitHub (siehe 1.4).

Nein, der PIO-ULB Editor implementiert ungefähr nur zwei Drittel des gesamten ULB-Spezifikationsumfangs. Wir haben ein eigenes Dokument verfasst, in dem alle Abweichungen des PIO-ULB Editors zum spezifizierten Standard beschrieben sind. Dieses Dokument kann im PIO-ULB Editor selbst heruntergeladen werden (siehe sich automatisch öffnender Disclaimer beim erstmaligen Starten des Editors).

Alternativ kann das Dokument auch hier heruntergeladen werden: PIOEditorLimitationen.pdf

Grund für die Reduzierung des Umfangs waren knappe Ressourcen im Forschungsprojekt sowie die von Pflegekräften bestätigte Erkenntnis, dass die PIO-ULB Spezifikation zu komplex und zu umfangreich für den alltäglichen Gebrauch ist.

Daten, die der PIO-ULB Editor nicht unterstützt, können vom Nutzer nicht eingegeben und exportiert werden, da die Benutzeroberfläche kein entsprechendes Eingabeelement bereitstellt. Sollte ein PIO-ULB importiert werden, welches nicht unterstützte Informationen enthält, werden diese Daten in einem dritten Reiter angezeigt (siehe Abbildung). Somit können die Informationen wenigstens gelesen werden, ein Editieren oder ein erneuter Export ist für diese Daten jedoch nicht möglich.

Nein, der PIO-ULB Editor ist ein Prototyp, der nicht für den pflegerischen Alltag gedacht und zertifiziert ist. Im Wesentlichen soll dieser Prototyp eine Diskussionsgrundlage durch die nutzerverständliche Visualisierung des PIO-ULB Standards schaffen sowie für weiterführende Implementierungen (z.B. durch Primärsystemhersteller) als Vorlage dienen.

Nein! Durch den Klick auf den “Export” Button im PIO-ULB Editor werden alle eingegebenen Daten als standardkonforme XML-Datei (= PIO) im Downloadmanager des Browsers heruntergeladen. Diese nun lokal verfügbare Datei kann mithilfe anderer Tools an die Einrichtung, die den Patienten empfängt, vorab gesendet werden.

Im Rahmen unseres Forschungsprojektes haben wir die XML-Datei mit Hilfe des KIM-Services versendet. KIM (Kommunikation im Medizinwesen) ist ein E-Mail-Dienst für Gesundheitseinrichtungen, mit dem Patientendaten datenschutzkonform verschickt werden können. Alternativ könnte die XML-Datei in die persönliche elektronische Patientenakte des Patienten hochgeladen werden. Anschließend kann die empfangende Einrichtung die Datei aus der elektronischen Patientenakte herunterladen. Für beide Übertragungsszenarien muss sowohl die sendende als auch die empfangende Einrichtung an die Telematikinfrastruktur (sicheres Netzwerk zum Austausch sensibler Gesundheitsdaten in Deutschland) angeschlossen sein.

Nein! Eine Schnittstelle zu KIS-Systemen (Krankenhausinformationssystem) oder anderen Pflegedokumentationssystemen ist wünschenswert, um den Erstellungsprozess des PIO-Überleitungsbogens zu automatisieren, kann aber im Rahmen des Forschungsprojektes nicht realisiert werden. Hier müssen die Primärsystemhersteller selbst tätig werden und ihre interne Datenstruktur auf den PIO-ULB mappen. Eine fehlende gesetzliche Verpflichtung zur Umsetzung des PIO-ULBs, der aktuell sehr geringe Verbreitungsgrad des PIO-ULBs und die hohe Komplexität des PIO-ULB Standards lassen Primärsystemhersteller zögern, eine PIO-ULB Schnittstelle zu implementieren.

Aktuell muss das Pflegefachpersonal die Patientendaten manuell in unseren PIO-ULB Editor eingeben. Für einen hochgradig automatisierten und digitalisierten Datenüberleitungsprozess ist es unverzichtbar, dass Primärsystemhersteller den PIO-ULB Standard unterstützen. Deshalb versuchen wir im Rahmen des Forschungsprojektes, diese Thematik an verschiedene Softwarehersteller heranzutragen und bieten unsere Unterstützung an.

FHIR (Fast Healthcare Interoperability Resources) ist ein international anerkannter Standard zur Abbildung von Gesundheitsdaten. FHIR bietet so viele Freiheiten, dass der Standard leicht an nationale Gegebenheiten und anwendungsspezifische Kontexte angepasst werden kann. Alle MIOs und PIOs wurden als FHIR Projekt umgesetzt.

Ein FHIR Datensatz (z.B. ein Überleitungsbogen) besteht aus vielen verschiedenen FHIR Ressourcen, die als einzelne Bausteine für den gesamten Datensatz dienen. So gibt es zum Beispiel Ressourcen, die Hausärzte, Diagnosen, Vitalwerte, Patientenstammdaten, Kontaktpersonen, Bevollmächtigungen, Medikamente, usw. abbilden und in ihrer Gesamtheit ein PIO-ULB darstellen. Jede Ressource bzw. jeder Baustein in einem FHIR Datensatz ist mit einer eindeutigen ID (z.B. UUID) versehen.

Der PIO-ULB Standard besteht laut simplifier aus 91 Profilen:

Bei genauerem Hinsehen bemerkt man, dass eines der Profile (KBV_PR_MIO_ULB_Identifier_PKV_KVID_10) keine eigenständige FHIR Ressource ist, da der Identifier nur als Abbildung einer 10-stelligen Versicherten-ID innerhalb der Ressource “KBV_PR_MIO_ULB_Patient” verwendet wird:

Daher besteht die PIO-ULB Spezifikation unserer Auffassung nach aus 90 FHIR Ressourcen.

Laut FHIR können Datensätze als XML- oder JSON-Datei erstellt werden. Die mio42 GmbH spezifizierte jedoch, dass alle MIOs und PIOs als XML-Datei gespeichert werden müssen.

Die Ressourcen “KBV_PR_MIO_ULB_Bundle“ und “KBV_PR_MIO_ULB_Composition“ sind besondere Ressourcen, während alle anderen nur als Informationsbausteine dienen. Diese zwei Ressourcen müssen verpflichtend in einem PIO-ULB vorkommen.

Jede Ressource bzw. jeder Informationsbaustein in einem FHIR Datensatz ist mit einer eindeutigen ID (z.B. UUID) versehen. Die Composition ist eine Art Inhaltsverzeichnis, welche alle IDs von jeder im Datensatz vorkommenden Ressource referenziert. Zusätzlich beinhaltet die Composition Informationen wie Erstellungsdatum, Informationen zum Autor und die empfangende Einrichtung.

Das Bundle ist die alles umfassende FHIR Ressource, die alle anderen Ressourcen (inkl. Composition) beinhaltet. Der XML-Root-Tag eines PIO-ULBs ist also <Bundle>. Außerdem beinhaltet das Bundle einen Zeitstempel.

Die Kardinalitäten (also wie oft ein bestimmtes Element minimal bzw. maximal vorkommen darf) sind für das gesamte PIO-ULB auf folgender Seite abgebildet:

Auflistung aller PIO-ULB Elemente inkl. Kardinalitäten [Stand: 10.10.2024]

Nach längerem Studieren der umfangreichen Tabelle stellt man fest, dass folgende FHIR Ressourcen mindestens im PIO-ULB enthalten sein müssen. Die Unterpunkte zu jeder Ressource geben an, welche Informationen in der jeweiligen Ressource verpflichtend angegeben werden müssen:

Alle mit * markierten Angaben müssen vom Nutzer aktiv eingegeben werden, alle anderen Angaben können automatisch generiert werden. Das heißt, ein Editor, der den PIO-ULB Standard abbildet, muss nur für die markierten (*) Informationen ein Eingabefeld bereitstellen.

Die Ressourcen, die lediglich das Vorhandensein von anderen Ressourcen abbilden, werden verwendet, um z.B. alle Allergien (für jede einzelne Allergie des Patienten gibt es ja eine eigene Ressource) zu bündeln. Die Ressource KBV_PR_MIO_ULB_Observation_Presence_Allergies referenziert zum Beispiel alle Allergie-Ressourcen (hält also deren IDs) und bündelt sie somit. Nun muss im Inhaltsverzeichnis (Composition) nicht mehr jede einzelne Allergie-Ressource referenziert werden, sondern lediglich die ID der Ressource KBV_PR_MIO_ULB_Observation_Presence_Allergies angegeben werden. Ein weiterer Vorteil ist, dass diese “Bündel-Ressourcen” zwischen “Nein, der Patient hat keine Allergien“ und “Es ist unbekannt, ob der Patient Allergien hat“ unterscheiden. Diese Differenzierung ist im pflegerischen Fachgebiet ein wichtiges Detail.

Im Fall eines PIO-ULBs mit minimalem Umfang müssen diese “Bündel-Ressourcen” zwar existieren, deren Inhalt lautet dann aber einfach: “Nein, es gibt keine Allergien” etc.!

Ja, gibt es. Die mio42 GmbH hat zwei Fallbeispiele auf ihrer Internetseite veröffentlicht:

Fallbeispiele der mio42 GmbH als XML-Datei [Stand: 10.10.2024]

Weiterhin ist es möglich mit unserem PIO-ULB Editor eigene PIO-ULBs zu erstellen. Im Hauptmenü des PIO-ULB Editors kann ein Demo-PIO geöffnet werden (siehe Abbildung), welches einen schnellen Export eines vollständigen¹ PIO-ULBs ermöglicht, ohne alle Eingabefelder selbst ausfüllen zu müssen.

Eine extension ist ein Element von FHIR, welches FHIR Basis-Ressourcen erweitert. Dies ermöglicht es, den internationalen Standard an nationale Kontexte anzupassen. Zum Beispiel wurde für die PIO-ULB Spezifikation die Patienten-Basis-Ressource durch drei weitere Informationen erweitert (siehe Abbildung).

Da die mio42 GmbH und die Kassenärztliche Bundesvereinigung (KBV) viele MIOs und PIOs entwickeln, macht es Sinn, ein Basis-Set an Ressourcen und Profilen zu entwickeln, und diese immer wieder zu verwenden. Zum Beispiel stellt FHIR eine Ressource bereit, die eine Kontaktperson abbildet:

Die KBV hat dann auf dessen Basis eine eigene Ressource zur Abbildung einer Kontaktperson erstellt. Diese Ressource gehört zu den KBV-Basisprofilen, was an dem Namen erkenntlich ist (KBV_PR_Base_RelatedPerson):

Die mio42 GmbH hat nun für das spezielle Projekt PIO-Überleitungsbogen wiederum eine eigene Ressource erstellt, die von der KBV-Basisressource abgeleitet wurde:

Nun stellt sich die Frage, welche Basis-Sets für den PIO-ULB verwendet wurden? Das PackageManifest auf simplifier liefert die Antwort (siehe Abbildungen):

Man sieht, dass für den PIO-ULB KBV-Basisprofile ("kbv.basis"), deutsche Basisprofile ("de.basisprofil.r4") und die FHIR Core Profile ("hl7.fhir.r4.core") in verschiedenen Versionen verwendet werden.

Die Allergie-Ressource für den PIO-ULB ist hier zu finden, welche als Beispielressource zur Erklärung dienen soll:

Allergie-Ressource der PIO-ULB Spezifikation auf simplifier [Stand: 27.09.2024]

Simplifier stellt die Ressourcen mithilfe einer aufklappbaren hierarchischen Struktur dar, welche die Schachtelung der XML-Tags eins zu eins widerspiegelt. Für jedes Element sind Kardinalitäten (z.B. 0..*) angegeben. "Must support" elemente sind mit einem roten "S" gekennzeichnet. Im Folgenden soll der Aufbau der Allergie-Ressource genauer erklärt werden:

Der Header ist in jeder Ressource identisch aufgebaut. Hier sind die ID der Ressource (in diesem Fall eine UUID) und die Art der Ressource hinterlegt:

Der XML-Tag <id> ist auf simplifier nicht sichtbar, ist aber für jede FHIR Ressource verpflichtend. <id> wird von einer FHIR-Basisressource vererbt.

Simplifier verwendet folgende “Binding”- und “Pattern”-Symbole:

“Binding” bedeutet, dass der Wert an ein Codesystem gebunden ist, während “Pattern” einen fixen Wert vorgibt, für den keine Nutzereingabe erforderlich ist.

Nähere Informationen zu <extension> unter 2.8. Die Repräsentation einer <extension> in der XML-Datei sieht wie folgt aus:

Oft werden codierte Informationen als CodeableConcept abgebildet. Bei der Allergie-Ressource wird z.B. der Verifikationsstatus mit einem CodeableConcept codiert. CodeableConcepts sind immer identisch aufgebaut und an ein spezielles Codesystem gebunden (siehe Binding-Symbol in der Abbildung). Ein CodeableConcept sieht wie folgt aus:

Auch der Code der Allergie ist als CodeableConcept repräsentiert.

Neu ist hier das blaue Slice-Element, welches dem Nutzer in diesem Fall die Freiheit gibt, die Allergie mittels SNOMED oder ASK Code anzugeben. Die PIO-ULB Spezifikation lässt an dieser Stelle also zwei verschiedene Codesysteme zu. Unser PIO-ULB Editor unterstützt jedoch nur SNOMED Codes. Außerdem sieht man, dass ein CodeableConcept ein <text> Element besitzen kann. Dieses Element dient der Freitextbeschreibung des Codes. Der Nutzer hat also auch die Möglichkeit, keinen Code anzugeben, und die Allergie mit einem Freitext zu benennen. Die XML-Repräsentation könnte dann wie folgt aussehen:

Jede Ressource ist mithilfe einer ID (z.B. UUID) innerhalb eines PIO-ULBs eindeutig identifizierbar. Diese ID kann verwendet werden, um von einer Ressource auf eine andere zu referenzieren. Im Fall der Allergie kann der Diagnosesteller referenziert werden. Dies kann der Patient selbst sein oder ein Hausarzt bzw. behandelnde Person (= Practitioner).

Für den PIO-ULB werden verschiedene Terminologien verwendet. Das bevorzugte Codesystem ist SNOMED, es kommen aber weitere Codesysteme zum Einsatz wie z.B. LOINC, ICD, ATC, Alpha-ID. Alle verwendeten Codesysteme sind hier aufgelistet:

Verwendete Code Systeme im PIO-ULB (Auflistung der mio42 GmbH) [Stand: 10.10.2024]

Unser PIO-ULB Editor unterstützt jedoch nur SNOMED Codes. Sollte ein PIO-ULB importiert werden, welches andere Terminologien nutzt, kann unser Editor diese anzeigen (siehe Abbildung, “Turkish”):

Entsprechende Codes werden mit dem Vermerk (nicht unterstützter Code) versehen. Der Nutzer kann diesen Code lesen und auch wieder exportieren. Wurde der Code jedoch gelöscht, kann er nicht erneute aus dem Drop Down ausgewählt werden.

Folgende Liste enthält die URLs zu allen Codesystemen, die wir für unseren PIO-ULB Editor heruntergeladen haben:

Leider existieren die meisten SNOMED Codes aktuell nur auf Englisch. Es wird gerade an einer deutschen Übersetzung gearbeitet. An welchen Übersetzungen gerade gearbeitet wird, ist auf folgender Seite ersichtlich:

Bundesinstitut für Arzneimittel und Medizinprodukte: Deutsche Übersetzungen von SNOMED-CT-Konzepten [Stand: 10.10.2024]

Da nur das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) deutsche Übersetzungen von SNOMED Codes veröffentlichen darf, hat die mio42 GmbH einen Umweg gewählt, um kleinere Codesysteme zu “übersetzen”. Um nicht von einer “Übersetzung” sprechen zu müssen verwendet die mio42 GmbH sogenannte ConceptMaps. ConceptMaps stammen aus dem FHIR-Standard und mappen die originalen Codes auf eine deutsche Repräsentation.

Jede Ressource ist mithilfe einer ID innerhalb eines PIO-ULBs eindeutig identifizierbar. Diese ID kann verwendet werden, um von einer Ressource auf eine andere zu referenzieren. Im PIO-ULB Editor werden UUIDs als ID verwendet, weil die mio42 GmbH in ihren Beispiel PIO-ULBs (siehe 2.7) ebenfalls UUIDs verwendet hat. Ein Beispiel für eine Referenzierung befindet sich unter 2.10.

Der PIO-ULB Standard wurde im Dezember 2022 als Version 1.0.0 festgelegt. Eine Änderung der Spezifikation halten wir für wahrscheinlich. Die Änderungen sollten sich aber auf kleine Anpassungen beschränken. Dies wird aber nicht in naher Zukunft passieren, da das PIO-ULB aufgrund neuer Gesetze des Deutschen Bundes den Fokus verloren hat. Andere MIOs haben aktuell höhere Priorität wie der PIO-ULB.

Simplifier besitzt einen Änderungs-Log, in dem alle Veränderungen an dem Projekt dokumentiert werden.

Änderungs-Log des PIO-ULB Projektes auf simplifier [Stand: 27.09.2024]

Alle Komponenten sind als JavaScript (nodeJS) Projekt implementiert. Die einzige Ausnahme stellt die Validator-Komponente dar. Sie ist in C-Sharp (.NET) geschrieben.

Der Validator verwendet das Firely Projekt, welches FHIR Bundles gegenüber Strukturdefinitionen offline validieren kann.

Je nachdem mit welcher Umgebungsvariable das Front- bzw. Backend gestartet wir, verhält sich das Session-Management unterschiedlich:

Da unser PIO-ULB Editor, der öffentlich im Internet abrufbar ist (siehe hier), weltweit Nutzern ermöglicht, auf dasselbe Backend zuzugreifen, wird für jede Anmeldung eine separate Session erstellt. Der Nutzer meldet sich durch die Angabe von Vor- und Nachnamen im Editor an. Das heißt, selbst wenn zwei Personen mit demselben Namen zur selben Zeit den Editor nutzen, erstellt das Backend separate Sessions, sodass es zu keinen ungewollten Überscheidungen kommen kann. Meldet sich der Nutzer wieder ab oder schließt das Browserfenster, wir die Session und alle eingegebenen Daten sofort gelöscht.

Die lokale Version ist für die Nutzung auf lokalen Computern oder in kleinen Netzwerken (z.B. Pflegeheim) gedacht. Meldet sich hier ein Nutzer (mittels Vor- und Nachname) an, wird eine neue Session erstellt. Sollte der Nutzer von anderen Aufgaben im Arbeitsalltag unterbrochen werden oder wird das Browser Fenster aus Versehen geschlossen, bleibt die Session für eine gewisse Zeit geöffnet und die Daten bleiben gespeichert. Meldet sich der Nutzer erneut mit seinem Namen an, öffnet sich seine Session erneut und er kann mit der Bearbeitung des PIO-ULBs fortfahren.

Es wurde absichtlich auf eine umfangreiche Nutzerverwaltung (mit Passwort und Username) verzichtet, weil dies die Anforderungen an einen prototypischen Editor übertroffen hätte.

Das Herzstück im Backend ist die Klasse RootObject, welches alle Daten eines PIO-ULBs abbildet. Für jede Session wird eine RootObject-Instanz erzeugt. Ein angemeldeter Nutzer kann also immer nur ein PIO-ULB erstellen/bearbeiten.

Das RootObject speichert alle Header-Daten des FHIR Bundles und der FHIR Composition in einer eigenen Klasse (PIOHeader). Eine weitere Klasse (PIOContent) speichert alle weiteren FHIR Ressourcen in einer einzigen großen JSON-Struktur. Diese Struktur wurde extra für das RootObject entwickelt, ähnelt aber sehr stark der Struktur, die später als XML exportiert wird. Weiterhin wurde die Struktur so entwickelt, dass sie möglichst Kompatibel mit der Library “fast-xml-parser“ ist (siehe 3.2).

Die Methode setValue(path: string, data: PrimitiveDataTypes) der PIOContent Klasse ermöglicht das Hinzufügen oder Überschreiben von Daten. Folgender Methodenaufruf würde eine neue Telefonnummer zu einer Kontaktperson hinzufügen:

Der Pfad (mit der Punktnotation und […]-Arraynotation) kann direkt so von der Library “lodash” verarbeitet werden (siehe 3.2) und beschreibt an welcher Stelle der JSON-Struktur die Daten eingefügt werden sollen. Die Daten selbst werden als PrimitiveDataTypes übergeben. Das Meta-Repository stellt für jeden von FHIR vordefinierten primitiven Datentyp (z.B. code, string, uri, date, etc.) eine entsprechende Klasse bereit (CodePIO, StringPIO, UriPIO, DatePIO, etc.).

Das Backend ist also möglichst generisch implementiert. Das Backend nimmt einfach Daten und Pfade, an denen die Daten gespeichert werden sollen, entgegen, ohne die PIO-ULB Struktur zu validieren.

Das RootObject stellt außerdem zwei Funktionen bereit, mit denen man alle im RootObject gespeicherten Daten in eine valide XML-Datei transformieren kann und umgekehrt:

Das Frontend definiert Basic-UI-Komponenten (z.B. InputTextField, InputDropDown, etc.), sodass die Eingabefelder über den gesamten PIO-ULB Editor stehts gleich erscheinen.

Diese Basic-UI-Komponenten werden dann in Formularen wiederverwendet. Die Formulare orientieren sich fast ausnahmslos an den FHIR Ressourcen. Das heißt, dass es für jede FHIR Ressource auch ein entsprechendes Formular gibt (z.B. ContactPersonForm). Jedes Formular hält die für sich relevanten Daten in einem React-State. Bei einem XML-Import initialisieren sich alle Formulare selbständig, indem sie ihre relevanten Daten beim Backend anfragen (die ContactPersonForm holt sich z.B. alle Daten über Kontaktpersonen). Editiert der Nutzer ein Eingabefeld wird der lokale State im Formular geupdated, der dann direkt an das Backend übermittelt wird. Nutzereingaben werden also in Echtzeit gespeichert. Die Front-Backend-Kommunikation funktioniert mittels SubTrees (siehe 3.6).

Da das Backend generisch ist, müssen die Formulare selbst die Nutzereingaben an die richtige Stelle in der PIO-ULB Struktur schreiben (mit Hilfe des Pfades, siehe 3.4). Das Wissen über den strukturellen Aufbau eines PIO-ULBs liegt also im Frontend und nicht im Backend.

Die Frontend-Formulare holen und senden die Daten in Form von SubTrees an das Backend. SubTrees sind beliebige Ausschnitte aus der Backend-Datenstruktur. Die Formulare können SubTrees auslesen und editieren. Zum Speichern von editierten SubTrees, wird dieser an das Backend geschickt. Dort wird der ausgeschnittene Teil wieder in die Datenstruktur eingefügt.

Mehr zur Front-Backend-Kommunikation unter 3.9.

Der Validator ist in C-Sharp (.NET) geschrieben, da das verwendete Projekt (Firely) in C-Sharp geschrieben ist. Firely ermöglicht es, ein FHIR-Bundle gegenüber FHIR-Strukturdefinitionen offline zu validieren. FHIR-Strukturdefinitionen enthalten detaillierte Informationen über den strukturellen Aufbau einer FHIR-Ressource oder den Inhalt von Codesystemen.

Quellcode des Validators auf GitHub [Stand: 27.09.2024]

Der PIO-ULB Editor ist als Stand-alone Software konzipiert und hat keine offenen Schnittstellen.

Eine Integration des gesamten PIO-Editors kann mittels <iframe> erfolgen. Laufen die Docker-Container auf ihrem System, ist der PIO-ULB Editor unter http://localhost:3000/ erreichbar (siehe 1.6). Folgender Code würde den PIO-ULB Editor dann in einem HTML-Dokument aufrufen: