Füllen Sie ein Formular aus und sehen Sie live, wie daraus eine FHIR-Ressource wird, und zum Vergleich eine klassische HL7-v2-Nachricht. Für alle, die mit IT, Herstellern und Schnittstellen sprechen.
formular → name, geburtsdatum, versichertennr., messwertfhir r4 → Patient + Observation, als jsonreferenz → Observation.subject → Patienthl7 v2 → MSH | PID | OBR | OBX, mit | und ^prüfung → pflichtfelder, formate, einheiten, codes
Ein Messwert, der in der Pflegesoftware erfasst wird, soll in der Arztpraxis ankommen, ohne dass ihn jemand abtippt. Dafür müssen beide Systeme dieselbe Sprache sprechen, und zwar auf drei Ebenen:
JSON, XML oder Zeilen mit Trennzeichen. Ohne gemeinsame Syntax kann das empfangende System die Daten nicht einmal zerlegen.
Ist „12,5“ eine Fläche in cm² oder ein Gewicht in kg? Codes und Einheiten aus festen Katalogen machen es eindeutig.
Welche Felder müssen da sein, welche Nummer bezeichnet die Person? Das legen Profile und Absprachen zwischen den Systemen fest.
Ohne Standard kein Austausch. Fehlt eine der drei Ebenen, bleibt nur der Umweg: abtippen, faxen, als PDF anhängen. Das kostet Zeit und erzeugt genau die Fehler, die später in Akte und Abrechnung auffallen.
Links ein Formular mit einer fiktiven Person und einer Messung. Daneben entsteht daraus live eine FHIR-R4-Ressource, darunter dieselben Daten als HL7-v2-Nachricht. Fahren Sie über eine Zeile, um zu sehen, welches Feld wohin wandert, und bauen Sie Fehler ein, um den Validator arbeiten zu lassen.
So geht’s: Ändern Sie links ein Feld oder fahren Sie über eine Zeile. Die passenden Stellen leuchten in Formular, FHIR und HL7 v2 gleichzeitig auf. Mit der Tastatur: in eine Code-Ansicht tabben, dann Pfeiltasten.
{ "resourceType": "Patient", "id": "pat-1", "identifier": [ { "system": "http://fhir.de/sid/gkv/kvid-10", "value": "B987654320" } ], "name": [ { "family": "Beispiel", "given": [ "Erika" ] } ], "gender": "female", "birthDate": "1948-03-12"}{ "resourceType": "Observation", "id": "obs-1", "status": "final", "code": { "text": "Wundfläche" }, "subject": { "reference": "Patient/pat-1" }, "effectiveDateTime": "2026-10-14", "valueQuantity": { "value": 12.5, "unit": "cm²", "system": "http://unitsofmeasure.org", "code": "cm2" }}
MSH|^~\&|WUNDDOKU|PFLEGEDIENST|PVS|PRAXIS|20261014101500||ORU^R01|MSG00001|P|2.5||||||UNICODE UTF-8PID|1||B987654320||Beispiel^Erika||19480312|FOBR|1|||BEFUND^Messwerte^LOBX|1|NM|^Wundfläche||12.5|cm2^cm²^UCUM|||||F|||20261014
| trennt Felder, ^ trennt Komponenten. Felder werden gezählt, nicht benannt: Fahren Sie über einen Wert, um seine Nummer zu sehen.
Zwei Details zum Ausprobieren: Im Bundle zeigt die Referenz auf eine vorläufige urn:uuid, die der Server beim Speichern durch die echte Adresse ersetzt. Und bei der Wundfläche fehlt bewusst ein Code: Welche Codierung gilt, legen Sie im Projekt fest. Die Prüfung hier ist vereinfacht, echte Schnittstellen prüfen gegen Profile mit einem FHIR-Validator.
Wer diese fünf Begriffe kennt, kann jedem Schnittstellengespräch folgen.
Ein abgegrenzter Baustein mit festen, benannten Feldern: eine Person, ein Messwert, ein Kontakt. Jede Ressource hat einen Typ (resourceType) und eine eigene Adresse, über die sie sich einzeln abrufen lässt.
Ressourcen verweisen aufeinander, statt Daten zu kopieren. Der Messwert speichert nicht Name und Geburtsdatum, sondern einen Zeiger auf die Person. Ändert sich die Adresse der Person, bleibt der Messwert richtig zugeordnet.
Der Grundstandard ist bewusst offen. Profile legen für einen Einsatzzweck fest, welche Felder Pflicht sind und welche Codes gelten. In Deutschland etwa die Basisprofile, die medizinischen Informationsobjekte (MIO) oder die Vorgaben für das E-Rezept.
Codes statt Freitext: LOINC für Messungen und Laborwerte, SNOMED CT für klinische Begriffe, UCUM für Einheiten, ICD-10-GM für Diagnosen. Erst Codes machen Daten über Systemgrenzen hinweg auswertbar.
Ein Paket aus mehreren Ressourcen. Als Transaktion wird es ganz oder gar nicht gespeichert, als Dokument zusammen verschickt, als Suchergebnis zurückgegeben.
Beide stammen von derselben Organisation, HL7 International. HL7 v2 ist das bewährte Arbeitspferd, FHIR die jüngere, webbasierte Generation. Keines ist „das Richtige“, es kommt auf die Aufgabe an.
HL7 V2 · Segmente und Felder, durch Trennzeichen getrennt. Felder werden gezählt, nicht benannt.
FHIR · Ressourcen mit benannten Feldern, als JSON oder XML.
HL7 V2 · Meist eine stehende Verbindung zwischen zwei Systemen, oft über einen Kommunikationsserver.
FHIR · Web-Schnittstellen über HTTPS. Ressourcen lassen sich einzeln abrufen, suchen und ändern.
HL7 V2 · Über die Reihenfolge in der Nachricht: Der Befund gehört zum Patienten davor.
FHIR · Über ausdrückliche Referenzen zwischen Ressourcen.
HL7 V2 · Eigene Segmente und Absprachen je Schnittstelle, oft nur im Kopf oder im Pflichtenheft.
FHIR · Profile und Erweiterungen, maschinenlesbar veröffentlicht und prüfbar.
HL7 V2 · Bewährt, schlank, ereignisgesteuert, etwa bei Aufnahme oder Befund. In Kliniken tief verankert.
FHIR · Gut für Apps, Portale und neue Anwendungen. Grundlage vieler TI-Anwendungen.
HL7 V2 · Jede Schnittstelle ist ein wenig anders. Was ein Feld bedeutet, hängt an Absprachen.
FHIR · Jünger. Versionen und Profile müssen zueinander passen, und noch nicht jedes System spricht es.
Kein Entweder-oder: In vielen Einrichtungen laufen beide nebeneinander, und ein Kommunikationsserver übersetzt dazwischen. Entscheidend ist, dass die Daten dort ankommen, wo sie gebraucht werden, ohne dass sie jemand abtippt.
Praxis, Klinik, Pflege, Labor und Kasse haben jeweils ihre eigene Formatgeschichte. Wählen Sie zwei Systeme, und die Matrix zeigt, ob sie eine gemeinsame Sprache haben oder ob dazwischen übersetzt werden muss. Die Angaben sind typische Muster; was Ihre Systeme können, klären wir in der Analyse.
Tabelle seitlich wischen →
| System | |||||
|---|---|---|---|---|---|
| in der Regel | teils | zunehmend | selten oder nicht | in der Regel | |
| teils | in der Regel | zunehmend | in der Regel | zunehmend | |
| selten oder nicht | teils | zunehmend | in der Regel | zunehmend | |
| in der Regel | in der Regel | zunehmend | selten oder nicht | teils | |
| selten oder nicht | selten oder nicht | zunehmend | in der Regel | zunehmend | |
| selten oder nicht | selten oder nicht | in der Regel | selten oder nicht | selten oder nicht | |
| selten oder nicht | selten oder nicht | zunehmend | selten oder nicht | selten oder nicht |
Gemeinsam wird es zunehmend über FHIR. Fragen Sie beide Hersteller, welche Version und welche Profile sie unterstützen. Dokumente lassen sich zusätzlich per KIM verschicken. Damit sie strukturiert übernommen werden, braucht es trotzdem ein gemeinsames Format.
Tipp: Klicken Sie auf einen Spaltenkopf, um zu sehen, was das Format ist.
Wir ersetzen keine Praxis-, Klinik- oder Pflegesoftware. Wir bauen um sie herum: Schnittstellen, Übersetzung und Prüfung dort, wo heute abgetippt, gefaxt oder exportiert wird.
Wir nehmen auf, welche Systeme Sie nutzen, welche Formate sie sprechen und wo heute Daten von Hand übertragen werden. Am Ende steht Ihre eigene Format-Matrix.
Daten ziehen schrittweise in eine EU-Cloud, mit dem Einverständnis und der Akzeptanz der Mitarbeitenden. Vorher werden Stammdaten bereinigt und Zuordnungen festgelegt.
Erst auf sauber verbundenen Daten setzt KI an, etwa um Dokumente zuzuordnen oder Freitext in Felder zu überführen, immer mit einem Prüfschritt durch Ihr Team.
Weiterlesen: Telematikinfrastruktur für KIM, ePA und E-Rezept, Datenqualität für saubere Stammdaten vor jeder Schnittstelle, und das Glossar für alle Abkürzungen.
Nein. Es hilft, die Begriffe zu kennen, damit Sie mit Herstellern und IT auf Augenhöhe sprechen: Welche Ressourcen, welche Profile, welche Version? Die technische Umsetzung übernehmen wir gemeinsam mit Ihren Herstellern.
Nicht über Nacht. HL7 v2 ist in Kliniken tief verankert und läuft zuverlässig. FHIR kommt vor allem bei neuen Anwendungen, Apps und in der Telematikinfrastruktur dazu. Viele Einrichtungen werden beides noch lange nebeneinander betreiben.
KIM ist ein Transportweg, sichere E-Mail innerhalb der Telematikinfrastruktur. FHIR ist ein Datenformat. Über KIM lassen sich Dokumente und auch strukturierte Daten verschicken; damit sie in der Akte landen, muss der Empfänger das Format verstehen.
Dann gibt es meist andere Wege: GDT- oder xDT-Exporte, HL7 v2, Exportdateien oder eine Herstellerschnittstelle. Eine Übersetzungsschicht vermittelt zwischen den Formaten. Ihre Software bleibt, sie wird nur besser verbunden.
Nein. Alles läuft in Ihrem Browser, nichts wird gesendet oder gespeichert. Person und Versichertennummer sind fiktiv. Bitte geben Sie keine echten Patientendaten ein.
Sie möchten wissen, welche Formate Ihre Systeme sprechen und wo heute abgetippt wird? Erstgespräch vereinbaren