ArchivDeutsches Ärzteblatt26/2018Regelung der Kassenärztlichen Bundesvereinigung zur Festlegung der Schnittstellen nach § 291d Absatz 1a Satz 1 Nr. 1 SGB V

BEKANNTGABEN DER HERAUSGEBER: Kassenärztliche Bundesvereinigung

Regelung der Kassenärztlichen Bundesvereinigung zur Festlegung der Schnittstellen nach § 291d Absatz 1a Satz 1 Nr. 1 SGB V

Dtsch Arztebl 2018; 115(26): A-1288 / B-1086 / C-1078

Als E-Mail versenden...
Auf facebook teilen...
Twittern...
Drucken...
LNSLNS

Bekanntmachungen

Regelung der Kassenärztlichen
Bundesvereinigung zur Festlegung der Schnittstellen

nach § 291d Absatz 1a Satz 1 Nr. 1 SGB V

Anzeige

Die Ver­tre­ter­ver­samm­lung der Kassenärztlichen Bundesvereinigung hat folgende Festlegung der Schnittstellen nach § 291d Absatz 1a Satz 1 Nr. 1 SGB V in ihrer Sitzung am 07.05.2018 beschlossen, die damit wie folgt in Kraft tritt:

1 Einleitung

Das vorliegende Dokument legt die Schnittstellen nach § 291d Absatz 1a Satz 1 Nummer 1 SGB V fest. Vertragsärzte und -psychotherapeuten können mittels dieser Schnittstelle, die Verordnungssoftware gemäß § 73 Absatz 9 Satz 1 SGB V wechseln, ohne dabei die bislang gespeicherten patientenbezogenen Verordnungsdaten zu verlieren. Des Weiteren wird die Kommunikation zwischen einem PVS und einer Verordnungssoftware für alle nach § 291d Absatz 1a Satz 1 Nummer 1 von der KBV zugelassenen Systeme festgesetzt. Folglich wird für den Vertragsarzt und -psychotherapeuten ein einfacher Wechsel der Verordnungssoftware ermöglicht.

In diesem Dokument werden folgende Begrifflichkeiten verwendet:

a) Praxisverwaltungssystem

Ein elektronisches Programm aus dem ein Anwender eine Funktion einer Verordnungssoftware aufruft. Im Praxisverwaltungssystem erfolgt i.d.R. die Verwaltung und Speicherung der Patienten-, Arzt1- und Betriebsstättendaten. Im PVS ist die Dokumentation der Behandlung des Patienten in der elektronischen Patientenakte gespeichert. Der Begriff Praxisverwaltungssystem bezieht sich auf IT-Systeme, die in der vertragsärztlichen Versorgung eingesetzt werden.

b) Verordnungssoftware

Die Verordnungssoftware ist ein elektronisches Programm, welches für die Verordnung von Arzneimitteln auf Basis des [Anforderungskatalog AVWG] von der KBV zugelassen ist. Die umzusetzenden Funktionen für diese Programme sind im [Anforderungskatalog AVWG] definiert.

c) Verordnungshistorie

Die Verordnungshistorie ist eine dem Patienten eindeutig zugeordnete Liste (z.B. Patientenliste, Eintrag in der Patientendokumentation etc.), welche den bisherigen Verordnungsverlauf mit den dazugehörigen Informationen für den Patienten enthält.

d) Hausapotheke

Bei der Hausapotheke handelt es sich um besondere Verordnungslisten, die beispielsweise arzt- oder betriebsstättenbezogen vorliegen können. Nähere Erläuterungen sind dem [Anforderungskatalog AVWG] zu entnehmen.

e) Anwender/Behandler

Der Anwender ist die Person, welche die beteiligten Systeme nutzt. Hierbei kann es sich um den Vertragsarzt, -psychotherapeuten oder eine Person aus dem Praxisteam handeln.

f) Arzneimittel/Medikament

Arzneimittel/ Medikamente sind Präparate, die dem Patienten mittels der Verordnungssoftware verordnet werden können.

2 Überblick

Bei der Festlegung der Schnittstellen geht die KBV von nachstehender Systemarchitektur aus.

Abbildung 1: Systemarchitektur
Abbildung 1: Systemarchitektur

Im Praxisverwaltungssystem werden die Patienten-, Arzt-, und Betriebsstättendaten verwaltet und gespeichert. Neben dem Einlesen von Versichertenkarten übernimmt das PVS die Speicherung der patientenbezogenen Daten so auch die dem Patienten zugeordneten Verordnungsdaten (sog. Verordnungshistorie) und Medikationspläne.

Die notwendigen Funktionen für die Erstellung von Rezepten und Medikationsplänen stellt dagegen die Verordnungssoftware gemäß § 73 Absatz 9 SGB V sicher. Der Funktionsumfang ergibt sich aus dem [Anforderungskatalog AVWG]. In der Verordnungssoftware werden keine patientenbezogenen Daten gespeichert.

Folglich muss das PVS alle notwendigen Stammdaten der Verordnungssoftware zur Verfügung stellen, damit eine Verordnung für den Patienten durchgeführt werden kann. Hierbei handelt es sich bei der Erstverordnung um die Patienten-, Arzt-, und Betriebsstättendaten und bei der Wiederverordnung müssen zusätzlich noch die entsprechenden Verordnungsdaten, welche im PVS z.B. in der Verordnungshistorie des Patienten gespeichert sind, übermittelt werden. Im Gegenzug übergibt die Verordnungssoftware die bei einer Verordnung erstellten Rezeptdaten an das Praxisverwaltungssystem. Bei der Aktualisierung eines Medikationsplans müssen werden diese Informationen zwischen Verordnungssoftware und PVS ausgetauscht.

Der Datenaustausch zwischen den beteiligten Systemen erfolgt auf Basis des HL7® FHIR® Standards. Die hierfür erforderlichen Datenstrukturen sind in Kapitel 3 „FHIR®“ festgelegt. Aus dem vierten Kapitel können die Regelungen für den Datenaustausch via REST-Service zwischen dem Praxisverwaltungssystem und Verordnungssoftware entnommen werden. Im Kapitel 5 ist der Einsatz der Schnittstellen durch Praxisverwaltungssystem und Verordnungssoftware festgelegt.

Das folgende Informationsmodell stellt die jeweiligen Informationsklassen mit den wichtigsten Attributen, den grundlegenden Interaktionen (lesen/schreiben) und ihren Beziehungen untereinander dar – nicht alle Attribute sind in Abbildung 2 genannt. Die Klassen repräsentieren die logischen Informationsobjekte für die Schnittstellen. Diese logischen Informationsobjekte werden entsprechend Kapitel 3 als FHIR®-Elemente dargestellt.

Abbildung 2: Informationsmodell der Schnittstelle nach § 291d Absatz 1a Satz 1 Nummer 1
Abbildung 2: Informationsmodell der Schnittstelle nach § 291d Absatz 1a Satz 1 Nummer 1

3 FHIR®-Definitionen

Die FHIR®-Spezifikation definiert eine Reihe von Basis-Ressourcen, welche in verschiedenen Bereichen des Gesundheitswesens eingesetzt werden können. Für den Anwendungszweck gemäß § 291d Absatz 1a Satz 1 Nr. 1 wurden KBV-Profile erstellt, welche zum Teil von den Deutschen Basis-Profilen abgeleitet sind. Folglich können die KBV-Profile mit den Deutschen Basis-Profilen verwendet werden. Die FHIR®-Ressourcen und eine Zusammenstellung der, in der FHIR®-Notation spezifizierten Elemente, finden sich unter: http://hl7.org/fhir/STU3/. Die deutschen FHIR®-Basisprofile sind nicht Gegenstand dieses Dokuments.

Eine wichtige Eigenschaft der KBV-Profile bildet „must-support“. Hierbei handelt es sich um Elemente, die unabhängig von der Kardinalität (Ausnahme: 0…0) unterstützt werden müssen, sofern die entsprechenden Informationen dem Anwender vorliegen. Ein Beispiel hierfür ist die Hausnummer des Patienten. Dieses Element muss unterstützt werden, wenn dem Anwender die Hausnummer des Patienten vorliegt.

Die Elemente in den KBV-Profilen sowie deren Kardinalitäten, Datentypen und weitere Eigenschaften sind den FHIR®-XML-Definitionsdateien zu entnehmen. Diese sind zu finden unter: ftp://ftp.kbv.de/ita-update/291d_Abs_1a_Satz_1_Nr_1

3.1 Dateiname

Die Dateinamen setzen sich wie folgt zusammen.

  • Kürzel_Kategorie_Thema_Bezeichnung

Bedeutung

  • Kürzel – 74 (steht für KBV und ist ein fester Wert)
  • Kategorie – PR (Profil), EX (Extension), VS (ValueSet) und CS (CodeSystem)
  • Thema – VM (steht für Verordnungsmodul/ -software und ist ein fester Wert)
  • Bezeichnung – Bezeichnung für das entsprechende Thema

Beispiele:

  • Dateiname: 74_PR_VM_Patient
  • URL: http://www.kbv.de/fhir/Profil/74_PR_VM_System

3.2 KBV-Profile

Die KBV-Profile geben Auskunft darüber, wie die Elemente und mit welchen Erweiterungen sowie Einschränkungen diese zu verwenden sind. Die Identifikation der KBV-Profile erfolgt durch die Angabe einer kanonischen URL.

3.3 KBV-Extensions

Mit den folgenden Extensions wurden notwendige Erweiterungen in den FHIR®-Ressourcen vorgenommen.

3.4 KBV-ValueSets und KBV-CodeSystems

Die CodeSystems definieren, welche Codes festgelegt wurden und was diese bedeuten. ValueSets hingegen beinhalten einen Satz von Codes aus einem CodeSystem, um anzugeben, welche Codes in einem bestimmten Kontext verwendet werden können.

3.5 FHIR®-Ressourcen

Die nachfolgenden Ressourcen werden durch die vorliegende Schnittstelle genutzt. Dabei gelten diese wie in [FHIR®] beschrieben. Die Inhalte dieser Ressourcen ergeben sich aus den Festlegungen des vorliegenden Dokumentes.

4  REST-Service

Das PVS stellt die Repräsentanzen, für die in Kapitel 3 „FHIR®-Definitionen“ beschriebenen Ressourcen der Verordnungssoftware, über einen REST-Service zur Verfügung. In diesem Zusammenhang fungiert das PVS als Server und die Verordnungssoftware als Client. Der vom Server zur Verfügung gestellte REST-Service wird anhand der Spezifikation der [FHIR®_RESTful-API] mit den in diesem Kapitel beschriebenen Festlegungen bzw. Einschränkungen bereitgestellt.

Das PVS stellt dabei sicher, dass nur Instanzen von FHIR®-Ressourcen verarbeitet werden, die den Festlegungen aus Kapitel 3 „FHIR®-Definitionen“ entsprechen.

4.1 Allgemeine Festlegungen

4.1.1 Style Guide

Grundlage ist das Kapitel „style Guide“ der [FHIR®_RESTful-API]. Es gilt wie folgt:

Zur Beschreibung der REST-Interaktionen wird folgende Notation verwendet

VERB [base]/[ressourcetype]/[id] {?_format=[mime-type]}

  • [ ] = verpflichtend
  • { } = optional
  • VERB = HTTP-Schlüsselwort für die Interaktion
  • base = Service Base URL
  • ressourcetype = Bezeichnung des Ressourcentyps
  • mime-type = der MimeType der Anfrage
  • id = logische ID der Ressource
  • vid = version ID der Ressource
  • compartment = Bezeichnung des Compartment
  • parameters = URL-Parameter der entsprechenden Interaktion

Die von dem PVS und der Verordnungssoftware genutzten URLs entsprechen dem RFC 3986 Section 6 Appendix A (d.h. spezifische Zeichen werden mit der %-Notation codiert).

Der „_“ Unterstrich wird zur Kennzeichnung von Schlüsselwörtern in Abgrenzung zu anderen Bezeichnungen für folgende Fälle genutzt:

  • um systemweite Such- und History-Interaktionen von Interaktionen auf FHIR®-Ressoucetypen zu unterscheiden
  • um Such-, History- und andere Interaktionen von einer Repräsentanz einer FHIR®-Ressource zu unterscheiden
  • um Suchparameter die für alle FHIR®-Ressourcen gelten, von Suchparameter einzelner FHIR®-Ressourcen zu unterscheiden.

4.1.2 Service Base URL & Type

Grundlage ist das Kapitel „2.21.0.1 Service Base URL“ der [FHIR®_RESTful-API]. Es gilt:

Das Praxisverwaltungssystem legt die Service Base URL ([base]) für seinen REST-Service fest.

Unter der Service Base URL sind alle in Kapitel 4.1.7 „Interaktionen auf den Ressourcen“ festgelegten FHIR®-Ressourcen ansprechbar. Die Service Base URL ergibt sich als: http://[server]{/path}. Dabei stellt server die Bezeichnung des Servers dar und /path einen optionalen Pfad zum REST-Service relativ zur Angabe server.

Jede in Kapitel 4.1.7 „Interaktionen auf den Ressourcen benannte FHIR®-Ressource hat einen sog. Ressource Manager, welcher über folgende URL ansprechbar ist: [base]/[type]. Wobei [type] dem Namen des FHIR®-Ressourcentyps (siehe StructureDefiniton.name in der FHIR®-Ressourcen-Beschreibung) entspricht.

Alle logischen Interaktionen werden relativ zur Service Base URL ([base]) ausgeführt.

Alle hier spezifizierten URLs sind case-sensitive und UTF-8 codiert.

Auf Basis von Kapitel 4.4 „Sicherheit“ gelten die in diesem Dokument getroffenen Festlegungen für http als auch für https.

4.1.3 Logische ID, Metadata und Versionierung von Ressourcen

Grundlage ist das Kapitel „2.21.0.2 Resource Metadata and Versioning“ von [FHIR®_RESTful-API]. Es gilt:

id

Die Logische-ID id entspricht der vom PVS für eine FHIR®-Ressource vergebenen ID. Die logische ID wird in der URL der angefragten Interaktion des REST-Services genutzt. Die logische ID wird im Element Ressource.id angegeben.

Last modified

Das Datum der letzten Änderung einer FHIR®-Ressource wird über den http Last-Modified Header übertragen. Dieses Datum findet sich im Element Ressource.meta.lastUpdated der FHIR®-Ressource.

4.1.4 Return Content

Grundlage ist das Kapitel „2.21.0.5 Managing Return Content“ aus [FHIR®_RESTful-API]. Es gilt:

Das PVS setzt nur die Option „return=minimal“ um. Das heißt, wird eine der Interaktionen create, update, patch oder transaction von der Verordnungssoftware an das PVS angefragt und war das Erstellen der Ressource im Praxisverwaltungssystem erfolgreich, so antwortet das PVS mit einer http-Nachricht ohne Body.

Erzeugen die Interaktionen create, update, patch oder transaction einen Fehler im PVS, wird eine http-Antwort mit dem entsprechenden Statuscode (siehe Kapitel 4.1.7 “Interaktionen auf den Ressourcen“) und einer OperationOutcome-Ressource (siehe Kapitel 3.5 „FHIR®-Ressourcen“) im http-Body an die Verordnungssoftware übergeben.

4.1.5 Content Types und Encodings

Grundlage ist das Kapitel „2.21.0.6 Content Types and encodings“ aus [FHIR®_RESTful-API]. Es gilt:

Der Mime-Type für die über den REST-Service verarbeiteten Ressourcen ist application/fhir+xml. Praxisverwaltungssystem und Verordnungssoftware unterstützen nur diesen.

Praxisverwaltungssystem und Verordnungssoftware nutzen UTF-8 als Encoding im Body der http-Anfragen und –Antworten. Das Encoding ist über die Felder Content-Type, Accept oder Accept-Charset im http-Header zu übertragen.

4.1.6 Support for Versions

Grundlage ist das Kapitel „2.21.0.5 Managing Return Content“ aus [FHIR®_RESTful-API]. Es gilt:

Der REST-Service des PVS unterstützt keine Versionierung der Ressourcen.

4.1.7 Interaktionen auf den Ressourcen

4.1.7.1 Lesen – read

Grundlage ist das Kapitel „2.21.0.8 read“ aus [FHIR®_RESTful-API]. Es gilt:

Zur Abfrage einer Repräsentanz einer FHIR®-Ressource im PVS durch die Verordnungssoftware wird die Interaktion read definiert.

Die Interaktion read ist dabei durch die http-Methode GET vom PVS wie folgt anzubieten:

GET [base]/[type]/[id]

Das Praxisverwaltungssystem beantwortet die Anfrage wie in Tabelle 30 dargestellt.

Der Parameter _summary ist nicht zu unterstützen.

4.1.7.2 Schreiben – create

Grundlage ist das Kapitel „2.21.0.14 create“ aus [FHIR®_RESTful-API]. Es gilt:

Soll von der Verordnungssoftware eine FHIR®-Ressource an das Praxisverwaltungssystem übergeben werden, dann erstellt die Verordnungssoftware eine FHIR®-Ressource im Praxisverwaltungssystem mit der Interaktion create.

Die Interaktion create ist dabei durch eine http-Methode POST wie folgt vom Praxisverwaltungssystem anzubieten:

POST [base]/[type]

Im Body der Methode POST wird die zu erstellende Repräsentanz der FHIR®-Ressource von der Verordnungssoftware an das PVS übergeben. Das Element Ressource.id der FHIR®-Ressource ist dabei leer.

Das PVS beantwortet die Anfrage mit folgenden Statuscodes und Ergebnissen:

Die Interaktion conditional create ist vom PVS nicht zu unterstützen.

4.1.7.3 Suchen – Search

Grundlage ist das Kapitel „2.21.0.15 search“ aus [FHIR®_RESTful-API]. Es gilt:

Damit die Verordnungssoftware in den FHIR®-Ressourcen des PVS suchen kann und somit eine entsprechende Ergebnisliste erhält, wird die Interaktion search definiert.

Die Interaktion search ist sowohl als http-Methode POST als auch als http-Methode GET wie folgt vom Praxisverwaltungssystem anzubieten:

GET [base]/[type]{?[parameters]}

bzw.

POST [base]/[type]/search{?[parameters]}

Die Umsetzung der Suchfunktionalität durch das Praxisverwaltungssystem muss die im Kapitel „2.21.1 search“ von [FHIR®] (http://hl7.org/fhir/search.html) beschriebenen Suchfunktionen ermöglichen. Zu dem muss das PVS die für die jeweiligen Ressourcentypen definierten Suchparameter zur Suche anbieten. Dabei sind nur die Suchparameter zu unterstützen, die nach der Profilierung noch in den Ressourcen vorliegen können.

Das Kapitel „2.21.0.15.1 Variant Searches“ aus [FHIR®_RESTful-API] ist durch das Praxisverwaltungssystem entsprechend umzusetzen.

Das PVS beantwortet die Anfrage mit folgenden Statuscodes und Ergebnissen:

4.1.7.4 Löschen – Delete

Grundlage ist das Kapitel „2.21.0.13 delete“ aus [FHIR®_RESTful-API]. Es gilt:

Soll von der Verordnungssoftware eine FHIR®-Ressource im Praxisverwaltungssystem gelöscht werden, nutzt die Verordnungssoftware dafür die Interaktion delete.

Die Interaktion delete ist dabei durch eine http-Methode DELETE wie folgt vom Praxisverwaltungssystem anzubieten:

DELETE [base]/[type]/[id]

Wurde eine Ressource gelöscht, so ist sie nicht mehr durch eine read- oder search-Interaktion von der Verordnungssoftware abrufbar.

Das PVS beantwortet die Anfrage mit folgenden Statuscodes und Ergebnissen:

Die Interaktion conditional delete ist vom PVS nicht zu unterstützen.

4.1.7.5 Capabilities

Grundlage ist das Kapitel „2.21.0.16 capabilities“ aus [FHIR®_RESTful-API]. Es gilt:

Das PVS stellt die Interaktion capabilities bereit. Wird diese von der Verordnungssoftware aufgerufen stellt das PVS eine FHIR®-Ressource vom Typ Capability Statement zur Verfügung, welche den Vorgaben aus 3.5 „FHIR®-Ressourcen“ entspricht.

Die Interaktion capabilities ist dabei durch eine http-Methode GET wie folgt vom Praxisverwaltungssystem anzubieten:

GET [base]/metadata

Das PVS beantwortet die Anfrage mit folgenden Statuscodes und Ergebnissen:

Die Standardinteraktionen (create, read etc.) auf Ressourcen vom Typ CapabilityStatement werden vom PVS nicht angeboten.

4.1.7.6 Nicht unterstützte Interaktionen

Die folgenden Interaktionen der [FHIR®_RESTful-API] -Spezifikation sind vom PVS nicht umzusetzen:

  • vread (Kapitel 2.21.0.9)
  • update (Kapitel 2.21.0.10)
  • patch (Kapitel 2.21.0.12)
  • conditional create (Kapitel 2.21.0.5.1 aus
    [FHIR®_RESTful-API])
  • conditional delete (Kapitel 2.21.0.13.1 aus
    [FHIR®_RESTful-API])
  • batch/transaction (Kapitel 2.21.0.17 aus
    [FHIR®_RESTful-API])
  • history (Kapitel 2.21.0.18 aus [FHIR®_RESTful-API])

4.1.8 Paging

Das Praxisverwaltungssystem bietet kein Paging an. Die Vorgaben aus [FHIR®] Kapitel 2.21.0.20 „paging“ aus [FHIR®_RESTful-API] sind nicht umzusetzen.

4.2 Konformität von Ressourcen

Der REST-Service des Praxisverwaltungssystems verarbeitet nur solche FHIR®-Ressourcen, die den in Kapitel 3 definierten FHIR®-Definitionen entsprechen. Somit werden nur solche FHIR®-Ressourcen bereitgestellt bzw. zur Verarbeitung angenommen, die den definierten Profilen entsprechen.

4.3 Interaktionen auf den Ressourcen

Das Praxisverwaltungssystem stellte die in Tabelle 35 beschriebenen Interaktionen auf den FHIR®-Ressourcen über den REST-Service zur Verfügung. Die Interaktionen sind in den Kapiteln 4.1.7.1 „Lesen – read“, 4.1.7.2 „Schreiben – create“, 4.1.7.3 „Suchen – Search“ sowie 4.1.7.4 “Löschen – Delete“ beschrieben.

4.4 Sicherheit

Der Datenaustausch über die REST-Schnittstelle sollte abgesichert werden können.

Daher bieten PVS und Verordnungssoftware die beiden nachstehenden Kommunikationsniveaus an. PVS und Verordnungssoftware ermöglichen dem Anwender das Kommunikationsniveau sowie die dafür notwendigen Einstellungen vorzunehmen.

Niveau 1:

Verwendung von http ohne Absicherung der Transportebene und keiner Authentifizierung von Server sowie Client.

Niveau 2:

a) Nachrichten zwischen PVS und Verordnungssoftware sind nur über eine verschlüsselte Verbindung auszutauschen. Für diese Transportverschlüsselung ist die TLS Version 1.2 zu verwenden.

b) Die Authentifizierung des PVS erfolgt über ein Serverzertifikat. Das Zertifikat muss für die jeweilige Installation vom Anwender erzeugt werden können. Das Verwenden von mitgelieferten Serverzertifikaten, die in allen Installationen gleich sind, ist nicht zulässig.

c) Die Authentifizierung der Verordnungssoftware erfolgt über Benutzername/ Passwort. Benutzername und Passwort dürfen nur über eine mit TLS gesicherte Verbindung übertragen werden. Das PVS darf die Passwörter nicht im Klartext speichern. Für die Übertragung von Benutzername und Passwort ist Basic Authentication nach RFC 7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication zu verwenden. Benutzername und Passwort können vom Anwender festgelegt werden.

5  Festlegungen für PVS und Verordnungssoftware

Die Kommunikation zwischen dem PVS und der Verordnungssoftware erfolgt nach dem in Abbildung 3 dargestellten Ablauf.

Abbildung 3: genereller Ablauf
Abbildung 3: genereller Ablauf

Der Anwender ruft aus seinem Praxisverwaltungssystem die Verordnungssoftware auf. Dabei kann das Praxisverwaltungssystem die Verordnungssoftware ohne Aufrufkontext aufrufen. Dann erfolgt in der Verordnungssoftware die Auswahl der gewünschten Funktion. Alternativ kann das Praxisverwaltungssystem einen Aufrufkontext übergeben. Dieser Aufrufkontext gibt die vom Anwender gewünschte Verordnungsfunktionalität mit. Wird z.B. der Aufrufkontext „Erstverordnung“ übergeben, gelangt der Anwender beim Aufruf der Verordnungssoftware direkt in die „Erstverordnungsfunktion“. Hinsichtlich des Aufrufes der Verordnungssoftware gelten die Festlegungen aus den Kapiteln 5.1.1 sowie 5.2.1.

Ist die Verordnungssoftware gestartet, arbeitet der Anwender in der Verordnungssoftware und nicht mehr im Praxisverwaltungssystem. Der Anwender kann nun die von der Verordnungssoftware bereitgestellten Funktionen nutzen. Die für die jeweiligen Funktionen notwendigen Daten fragt die Verordnungssoftware über den REST-Service beim Praxisverwaltungssystem ab. Hat die Verordnungssoftware Daten erstellt, die im Praxisverwaltungssystem gespeichert werden sollen, so übergibt die Verordnungssoftware diese Daten über den REST-Service an das PVS. Dies ist z.B. der Fall, wenn ein Rezept erstellt (gedruckt) oder ein Medikationsplan erstellt bzw. aktualisiert wird. In diesem Fall werden die Rezeptdaten und der erstellte/ aktualisierte Medikationsplan zur Speicherung an das Praxisverwaltungssystem übergeben. Es gelten die Festlegungen aus den Kapiteln 5.1.2, 5.1.3, 5.2.2 sowie 5.2.3.

Nach Beendigung der Arbeiten in der Verordnungssoftware wechselt der Anwender zurück in das Praxisverwaltungssystem. Die Arbeiten in der Verordnungssoftware sind beendet und die Verordnungssoftware wird verlassen. Es gelten die Festlegungen aus den Kapiteln 5.1.4 sowie 5.2.4.

5.1 Festlegungen für die Verordnungssoftware

Die Verordnungssoftware muss durch die Einhaltung der in diesem Dokument beschriebenen Festlegungen sicherstellen, dass ein Arzt seine Verordnungssoftware wechseln kann, ohne dabei sein PVS zu wechseln.

Hierbei muss der Anwender die Möglichkeit der Konfiguration im PVS haben, in der Form, dass der Anwender die für die Nutzung der Verordnungssoftware notwendigen Einstellungen eigenständig vornehmen kann. Dabei ist insbesondere sicherzustellen, dass der Anwender die derzeit angebundene Verordnungssoftware gegen eine andere austauschen kann.

Die Verordnungssoftware stellt sicher, dass nur solche FHIR®-Ressource erstellt und verarbeitet werden, die die Definitionen aus Kapitel 3 „FHIR®-Definitionen“ einhalten.

5.1.1 Aufruf der Verordnungssoftware

Die Verordnungssoftware muss über ein Aufrufkommando aufgerufen werden können, welches als Systemaufruf aus dem PVS ausgeführt werden kann. Im Aufrufkommando ist ein Parameter anzugeben. Dieser Parameter ist wie folgt definiert:

  • Name: kID
  • Typ: eine beliebige Kombination aus Zahlen, Groß- und Kleinbuchstaben sowie „-„ oder „.“ ([A-Za-z0–9\-\.]{1,64})
  • Länge: max. 64 Zeichen

Die Verordnungssoftware stellt dem Anwender eine Dokumentation zur Verfügung aus der das Aufrufkommando hervorgeht.

Tritt beim Aufrufen der Verordnungssoftware ein Fehler auf, so gibt die Verordnungssoftware eine aussagekräftige Fehlermeldung aus.

Wurde die Verordnungssoftware erfolgreich gestartet, fragt die Verordnungssoftware mit dem Wert des Übergabeparameters kID die mit dieser ID vom PVS bereitgestellte FHIR®-Ressource vom Typ Bundle entsprechend der Definition von 74_PR_VM_Bundle in Kapitel 3 „FHIR®-Definitionen“ ab. Mit dem in dieser Ressource übergebenen Aufrufkontext stellt die Verordnungssoftware sicher, dass die entsprechende Funktionalität ausgeführt wird, ohne dass der Anwender die entsprechende Funktion erneut in der Verordnungssoftware aufrufen muss. Mit den in dieser Ressource übergebenen Informationen lädt die Verordnungssoftware zudem die für die entsprechende Funktion notwendigen Daten (z.B. Patientendaten) aus dem PVS nach.

Nach dem Start der Verordnungssoftware arbeitet der Anwender in der Verordnungssoftware.

5.1.2 Abfrage der notwendigen Daten

Führt der Anwender eine entsprechende Funktion in der Verordnungssoftware aus, so fragt die Verordnungssoftware über die read- und search-Interaktion des REST-Services die benötigten FHIR®-Ressourcen vom PVS ab. Dabei gelten die Festlegungen aus den Kapiteln 3 „FHIR®-Definitionen“ und 4 „REST-Service“.

5.1.3 Übergabe der Verordnungs- und Medikationsplandaten

Werden während der Ausführung der Verordnungssoftware patientenbezogene Daten, bspw. ein Medikationsplan oder Rezept, erstellt, so übergibt die Verordnungssoftware diese Daten als FHIR®-Ressourcen über den REST-Service unter Nutzung der Interaktion create an das Praxisverwaltungssystem. Dabei gelten die Festlegungen aus den Kapiteln 3 „FHIR®-Definitionen“ und 4 „REST-Service“.

5.1.4 Beendigung der Verordnungssoftware

Hat der Anwender seine Arbeit in der Verordnungssoftware beendet und möchte wieder ins Praxisverwaltungssystem wechseln, löscht die Verordnungssoftware mit der Interaktion delete die FHIR®-Ressource entsprechend der Definition von 74_PR_VM_Bundle in Kapitel 3 „FHIR®-Definitionen“, die mit dem Parameter kID beim Start der Verordnungssoftware übergeben wurde. Anschließend wird die Verordnungssoftware aus Sicht des Anwenders beendet. Der Anwender arbeitet nun im Praxisverwaltungssystem weiter.

5.2 Festlegungen für Praxisverwaltungssysteme

Das PVS muss durch die Einhaltung der in diesem Dokument beschriebenen Festlegungen sicherstellen, dass ein Arzt seine Verordnungssoftware wechseln kann, ohne dabei sein PVS zu wechseln.

Der Anwender muss die Möglichkeit der Konfiguration im PVS haben, in der Form, dass der Anwender die für die Nutzung der Verordnungssoftware notwendigen Einstellungen eigenständig vornehmen kann. Dabei ist insbesondere sicherzustellen, dass der Anwender die derzeit angebundene Verordnungssoftware gegen eine andere austauschen kann.

Das PVS muss die Möglichkeit bieten mindestens mit einer Verordnungssoftware verbunden zu werden. Es kann auch mehr als eine Verordnungssoftware an das PVS angebunden sein. Der Anwender kann konfigurieren, welche der angebundenen Softwaren für die Verordnung genutzt werden soll. Jedoch kann ein Verordnungsvorgang immer nur in einer Verordnungssoftware erfolgen – eine Kommunikation zwischen verschiedenen Verordnungssoftwaren während eines Verordnungsvorgangs ist nicht gestattet.

Das Praxisverwaltungssystem stellt sicher, dass nur solche FHIR®-Ressource erstellt und verarbeitet werden, die die Definitionen aus Kapitel 3 „FHIR®-Definitionen“ einhalten.

5.2.1 Aufruf der Verordnungssoftware

Das PVS ermöglicht dem Anwender den Aufruf der Verordnungssoftware aus dem System heraus.

Beim Starten der Verordnungssoftware erstellt das PVS eine FHIR®-Ressource entsprechend der Definition von 74_PR_VM_Bundle in Kapitel 3 „FHIR®-Definitionen“ und stellt diese der Verordnungssoftware via REST-Service entsprechend Kapitel 4 „REST-Service“ zur Verfügung. Beim Erstellen dieser Ressource werden der Aufrufkontext sowie die notwendigen Informationen in der Ressource befüllt. Unter einem Aufrufkontext ist der Funktionskontext, mit dem die Verordnungssoftware aufgerufen wird zu verstehen und ist über das ValueSet 74_VS_VM_AufrufKontext bzw. CodeSystem 74_VS_VM_AufrufKontext definiert. Die bei der Erstellung dieser Ressource erzeugte ID wird beim Aufruf der Verordnungssoftware als kID-Parameter übergeben.

5.2.2 Abfrage der notwendigen Daten

Das Praxisverwaltungssystem stellt die in ihm vorliegenden Daten als FHIR®-Ressourcen über den REST-Service der Verordnungssoftware über die Interakationen read und search zur Verfügung. Dabei gelten die Festlegungen aus den Kapiteln 3 „FHIR®-Definitionen“ und 4 „REST-Service“.

5.2.3 Speicherung von übergebenen Daten

Übergibt die Verordnungssoftware patientenbezogene Daten als FHIR®-Ressourcen über den REST-Service mit der Interaktion create, so speichert das PVS diese Daten in der Patientendokumentation für den in der FHIR®-Ressource referenzierten Patienten. Dabei gelten die Festlegungen aus den Kapiteln 3 „FHIR®-Ressourcen“ und 4 „REST-Service“.

5.2.4 Beendigung der Verordnungssoftware

Führt die Verordnungssoftware eine Interaktion delete auf eine Ressource entsprechend der Definition von 74_PR_VM_Bundle in Kapitel 3 „FHIR®-Definitionen“ aus, so hat der Anwender die Arbeiten in der Verordnungssoftware beendet und möchte im Praxisverwaltungssystem weiter arbeiten. Das Praxisverwaltungssystem stellt dabei sicher, dass wenn der Anwender in der Verordnungssoftware in einem Patientenkontext gearbeitet hat und dieser Patientenkontext über die Ressource entsprechen 74_PR_VM_Bundle beim Aufruf der Verordnungssoftware übergeben wurde, dieser Patientenkontext im Praxisverwaltungssystem wieder vorliegt.

An einigen Stellen im Dokument wird zur besseren Lesbarkeit die Bezeichnung „Arzt“ genutzt. Selbstverständlich sind darunter auch Psychotherapeuten zu verstehen sowie die jeweilige weibliche Form der Berufsbezeichnungen.

Tabellen in der PDF-Datei

Abbildung 1: Systemarchitektur
Abbildung 1: Systemarchitektur
Abbildung 1
Abbildung 1: Systemarchitektur
Abbildung 2: Informationsmodell der Schnittstelle nach § 291d Absatz 1a Satz 1 Nummer 1
Abbildung 2: Informationsmodell der Schnittstelle nach § 291d Absatz 1a Satz 1 Nummer 1
Abbildung 2
Abbildung 2: Informationsmodell der Schnittstelle nach § 291d Absatz 1a Satz 1 Nummer 1
Abbildung 3: genereller Ablauf
Abbildung 3: genereller Ablauf
Abbildung 3
Abbildung 3: genereller Ablauf

Leserkommentare

E-Mail
Passwort

Registrieren

Um Artikel, Nachrichten oder Blogs kommentieren zu können, müssen Sie registriert sein. Sind sie bereits für den Newsletter oder den Stellenmarkt registriert, können Sie sich hier direkt anmelden.

Fachgebiet

Zum Artikel

Anzeige

Alle Leserbriefe zum Thema