Schnittstellen und Standards

GDT 2.1

Messwerte und Konsultationsdaten gehen als GDT-Datei in die Krankengeschichte des Praxissystems — Blutdruck, Puls und die Werte aus der Konsultation. Die Praxis liest die Datei mit ihrem eigenen Importmechanismus ein.

Technisch: Satzart 6310 (Untersuchungsdaten übermitteln), Versionsfeld 9218 = 02.10, Zeichensatz ISO 8859-1 (Feld 9206 = 3), Patientenzuordnung über die Patientennummer des Praxissystems (Feld 3000).

Einschränkung: Erprobt gegen tomedo. Andere Praxissysteme lesen GDT ebenfalls, sind aber noch nicht getestet.

eMediplan (CHMED23A und CHMED16A)

Der Medikationsplan wird im Schweizer eMediplan-Format gelesen, in der Praxis geprüft und geändert und als QR-Code zurückgegeben, den das Praxissystem einliest. Dazu kommt ein Blatt für die Krankengeschichte.

Technisch: Gelesen wird CHMED23A. Für den Rückweg erzeugt BYOH zusätzlich CHMED16A, weil tomedo den Medikationsplan nur in dieser Fassung und nur per QR-Scan einliest. Beide Fassungen sind Transmission-Strings: Formatkennzeichen, dahinter Base64 über gzip-komprimiertes JSON.

Einschränkung: Erprobt im Zusammenspiel mit tomedo. Der Rückweg läuft über QR-Code und Blatt, nicht über einen Dateiimport: tomedo liest den Medikationsplan ausschliesslich per Scan in der geöffneten Medikamentenverordnung. Wer eine Dateischnittstelle für den eMediplan erwartet, wird sie dort nicht finden.

FHIR R4 mit Schweizer Profilen

Gibt eine Patientin ihre Daten für die Praxis frei, entsteht ein FHIR-Dokument mit Stammdaten, Medikation, Allergien, Impfungen, Diagnosen und Messwerten.

Technisch: CH Core 5.0.0 (Patient, Condition, Composition, Document), CH EMED 5.0.0 (MedicationStatement), CH AllergyIntolerance 2.0.0, CH VACD 5.0.0 (Immunization, mit Swissmedic-Codesystem), HL7 FHIR R4 (Observation, Blutdruckprofil). Die Profile werden in meta.profile deklariert.

Einschränkung: Die Profile sind deklariert und die Ressourcen danach gebaut. Eine Prüfung gegen den offiziellen Validator der Implementation Guides steht aus.

E-Rezept Schweiz

Der nationale Dienst ist der vorgesehene Weg für das elektronische Rezept mit qualifizierter Signatur. BYOH will dort andocken, statt einen eigenen Signaturweg zu bauen.

Technisch: Heute erzeugt BYOH das Rezept nach ärztlicher Freigabe als CHMED23A-Objekt (Typ Rezept oder Dauerrezept, mit der GLN der verschreibenden Person) und übergibt es als QR-Code sowie als Blatt mit SHA-256-Prüfwert an die Krankengeschichte.

Einschränkung: Nicht an den nationalen Dienst angebunden und ohne qualifizierte elektronische Signatur. Ein BYOH-Rezept ist damit kein rechtsgültiges elektronisches Rezept.