Die folgenden Inhalte beschreiben den ursprünglichen Scope des MVP. Dieser wurde inzwischen geändert. Aktualisierte Informationen finden Sie in den Folien des 5. Industriedialogs.

Zielsetzung 

Die derzeitigen Abrechnungsprozesse bei privaten Krankenversicherungen (PKV) und Beihilfestellen basieren aktuell vielfach auf papiergebundenen Rechnungen, Einreichungen und Abrechnungen. Der Versicherte erhält seine Rechnungen vom Arzt oder einem Abrechnungsdienstleister (ADL) in Papierform. Er entscheidet, welche Rechnungen er bei seiner PKV einreichen möchte, wozu eine Rechnung oftmals noch per Post eingesendet werden muss. Zwar haben einige PKV-Unternehmen bereits digitale Einreichungslösungen und manche Abrechnungsdienstleister digitale Zustellmöglichkeiten. Eine standardisierte branchen-übergreifende Lösung existiert allerdings nicht.

Eine solche branchenübergreifende digitale Lösung für den Abrechnungsprozess privater Gesundheitsleistungen soll durch den neu zu erstellenden eRg FD geschaffen werden. Standard-Formate und -Schnittstellen sollen allen am Prozess beteiligten Institutionen sowie den Versicherten über nutzerfreundliche Oberflächen zur Verfügung gestellt werden. Ziel ist es, eine Lösung für die digitale Abrechnung zu schaffen, die Medienbrüche sowie Postversand vermeidet und für den Versicherten komfortabel in der Nutzung ist.

Zusätzlich zur digitalen Einreichung von Rechnungen ist auch eine Prozessalternative vorgesehen. Diese betrifft den Fall, dass ein Rechnungsempfänger eine digital empfangene Rechnung ausdruckt und beispielsweise postalisch einreicht. Die Rechnung geht beim Kostenträger (KTR) über den Postweg ein, enthält aber einen vom eRg FD aufgedruckten visuellen Code (z.B. Barcode). Vorteil zum derzeitigen papiergebundenen Prozess ist es, dass die Rechnungen damit eine digitale Referenz besitzen und über diese dann vom KTR wie rein digital eingereichte E-Rechnungen behandelt werden können.

E2E-Prozess inkl übergeordnete Nutzerrollen

Der digitalisierte E2E-Prozess besteht aus den Teilen

Die folgende Abbildung beschreibt die Nutzergruppen der E-Rechnung und die adressierten Mehrwerte der Lösung:


Die folgende Abbildung zeigt die einzelnen Schritte des E2E-Prozesses:

Inhaltliche Roadmap

Der Fachdienst zur Unterstützung des Prozesses soll in mehreren Stufen (iterativ) entwickelt werden. Die Planung sieht folgende Stufen vor:

Die folgende Abbildung beschreibt die aktuell geplanten Ausbaustufen anhand der fachlichen Funktionalitäten:

Abgrenzung von anderen Marktlösungen

XRechnung ("E-Rechnung des Bundes")

XRechnung ist ein Standard für die Art und die technische Zusammensetzung der Rechnungsinformationen in einem XML-Datensatz. Dieser XML-Datensatz entspricht einer elektronischen Rechnung. Der Standard ermöglicht den Empfang und die Weiterverarbeitung durch unterschiedliche Softwaresysteme. Siehe LINK.

Für die Ausstellung von elektronischen Rechnungen an die Bundesverwaltung ist grundsätzlich der Standard XRechnung in der jeweils aktuellen Fassung zu verwenden oder auch  z.B. ZUGFeRD Version 2.2.0 im Profil XRECHNUNG als rein strukturierte XML-Datei. Der Standard XRechnung wird von der KoSIT (Koordinierungsstelle für IT-Standards) im Auftrag des IT-Planungsrats betrieben.

ZUGFeRD

PDF inkl. strukturierte Daten im XML Format, seit der Einführung von ZUGFeRD 2.0 müssen Rechnungen dem europäischen Standard EN16931 entsprechen. Mit ZUGFeRD 2.1 wurde die Möglichkeit geschaffen, XRechnung in das ZUGFeRD-Format zu integrieren.

Europäischen Norm für die elektronische Rechnungsstellung EN 16931

Einheitliches semantisches Datenmodell für e-Rechnungen in Europa; der Standard XRechnung repräsentiert eine nationale Ausgestaltung der Europäischen Norm EN 16931 (Ergänzungen in der nationalen Ausgestaltung, siehe https://www.e-rechnung-bund.de/faq/xrechnung/)

gematik E-Rechnung

Die gematik E-Rechnung standardisiert die Rechnungsdaten über alle Leistungserbringersektoren und über alle Prozessteilnehmer im Gesundheitsbereich. Der Datenaustausch erfolgt über die Telematikinfrastruktur (TI) auf FHIR-basierten Formaten. Bereits existierende Formate werden inhaltlich berücksichtigt.

Einordnung TI 2.0

Bei der Einführung der eRg als eine neue Anwendung der TI sollen die aktuellen Prinzipien aus dem Technologieportfolio der gematik verwendet werden. Dazu gehört insbesondere ein schrittweiser Ausbau der Anwendung in Richtung TI 2.0 Architektur:

Föderiertes Identitätsmanagement

Die Authentisierung der Versicherten wird über die GesundheitsID realisiert. Die KTR stellen ihren Versicherten mittels sektoraler Identity Provider (IdP) elektronische Identitäten bereit. Durch App2App-Flow, Web2App-Flow und 2-Geräte-Flow werden unterschiedliche Nutzungsszenarien abgedeckt: von der vollintegrierten 1-App Lösung bis zur separaten App für private Zusatzversicherungen für gesetzlich Versicherte.

Die Authentisierung der LE wird in der ersten Version der eRg über den vorhandenen IDP-Dienst der TI realisiert. Damit erfolgt die Authentisierung der LE/Leistungserbringerinstitutionen (LEI) weiterhin Smartcard-basiert analog zu E-Rezept und elektronischer Patientenakte (ePA).

Der eRg FD wird in die IDP- und Dienste-Föderation aufgenommen und ist dadurch ein vollwertiger Dienst der TI.

Universelle Erreichbarkeit der Dienste

Der eRg FD ist sowohl über das Internet als auch über das geschlossene Netz der TI erreichbar. Die Kommunikation mit dem eRg FD erfolgt, unabhängig vom Zugangsweg, über eine standardisierte Schnittstelle (REST API).

Der Zugriff über das Internet ist in der ersten Version nur für Versicherte möglich. Leistungserbringer und andere Institutionen (z.B. Abrechnungsstellen) können den Fachdienst nur über das geschlossene Netz der TI erreichen.

Moderne Sicherheitsarchitektur

Die eRg verwendet die ersten Bausteine der Sicherheitsarchitektur der TI 2.0. Dazu gehört insbesondere die Verwendung von OAuth2.0 und OpenID Connect für die Authentisierung und Autorisierung. Hinzu kommt die Verwendung von TLS und VAU-Protokoll für die sichere Kommunikation mit dem eRg FD.

Die Internet-Schnittstellen werden mittels Zero Trust Architektur abgesichert. Dabei kommt zusätzlich zur Authentisierung und Autorisierung der Nutzer auch die Registrierung und Attestation der Clients zum Einsatz.

Offener Punkt: Es ist gerade in Klärung, ob der Betrieb des Geräte Management Service (GMS) in der ersten Version in einer integrierten Betriebsumgebung mit dem eRg FD betrieben werden soll.


Verteilte Dienste

Beim eRg FD handelt es sich zunächst um einzelnen Dienst, der in der TI-Föderation registriert ist. Durch die Verwendung von standardisierten Schnittstellen und Protokollen kann die Nutzung des eRg FD in Kombination mit anderen Diensten mittels eines integrierten Frontends angeboten werden, um z.B. die Abrechnung oder die Dokumentation von Leistungen in der ePA zu vereinfachen.

Interoperabilität und strukturierte Daten

Die fachlichen Schnittstellen der E-Rechnung und ihre Informationsobjekte basieren auf HL7 FHIR. Dadurch reiht sich die E-Rechnung in die Reihe der FHIR-basierten Anwendungen der TI ein. Die Verwendung von FHIR ermöglicht die Interoperabilität mit anderen Anwendungen der TI und darüber hinaus.

Die Verarbeitung der personenbezogenen medizinischen Daten der E-Rechnung durch den Fachdienst setzt voraus, dass der E-Rechnung Fachdienst in einer Vertrauenswürdigen Ausführungsumgebung betrieben wird. Aufgrund der sicherheitstechnisch herausgehobenen Stellung des Geräte Management Service (GMS) gilt für diesen dieselbe Anforderung.

Automatisierte Verarbeitung der Zero Trust TI-Policy

Im Rahmen der Zero Trust Sicherheitsarchitektur der TI 2.0 wird die automatisierte Verarbeitung der TI-Policy, die sowohl übergreifende als auch fachdienstspezifische Zugriffsregeln umfasst, durch die Komponenten des eRg FD umgesetzt. Dies ermöglicht die Bereitstellung der Regeln für den eRg FD aus einem integrierten Policy Management der gematik. Der eRg FD wendet diese Regeln automatisch an. In der ersten Version der eRg wird das Policy Management zunächst fachdienstspezifisch aufgebaut.

Da Zero Trust per se kein Standard oder Produkt ist, sondern vielmehr ein Architekturprinzip, ist es geplant, einzelne Bausteine der Zero Trust Architektur iterativ nacheinander einzuführen.