Hallo,

in dem Beispiel unter https://github.com/gematik/api-erp/blob/master/docs/erp_chargeItem.adoc#anwendungsfall-pkv-abrechnungsinformationen-durch-den-abgebenden-leistungserbringer-bereitstellen
wird die Versichertennummer als System http://fhir.de/sid/gkv/kvid-10 angegeben.

Sollte das nicht eher http://fhir.de/sid/pkv/kvid-10 sein?

Leider ist es nicht möglich, mit der JavaScript-API des Browsers (fetch, Axios) die Ressource https://idp-ref.app.ti-dienste.de/.well-known/openid-configuration aufzurufen. Die CORS-Einstellungen des Servers erlauben dies nicht. Ist dies beabsichtigt, bzw. haben Sie eine alternative Implementierung dafür vorgesehen?

In der Dokumentation zum E-Rezept abrufen ist in der Response die Extension GEM_ERP_EX_PrescriptionType mit den dazugehörigen Daten doppelt gelistet. Der Standard lässt hier aber nur genau einen Eintrag zu.

Bei https://github.com/gematik/api-erp/blob/master/docs/erp_chargeItem.adoc#anwendungsfall-abrechnungsinformation-zum-ändern-abrufen bekomme ich für https://prescriptionserver.telematik/ChargeItem/200.000.000.022.127.38?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea

<?xml version="1.0" encoding="utf-8"?>
<OperationOutcome xmlns="http://hl7.org/fhir"><meta><profile value="http://hl7.org/fhir/StructureDefinition/OperationOutcome"/></meta><issue><severity value="error"/><code value="not-supported"/><details><text value="no matching handler found."/></details></issue></OperationOutcome>

Ich vermute, dass analog zu https://github.com/gematik/api-erp/blob/master/docs/erp_chargeItem.adoc#anwendungsfall-pkv-abrechnungsinformationen-durch-den-abgebenden-leistungserbringer-bereitstellen der Aufruf https://prescriptionserver.telematik/ChargeItem?task=200.000.000.022.127.38&ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea lauten müsste.

Bekomme dann allerdings

<?xml version="1.0" encoding="utf-8"?>
<OperationOutcome xmlns="http://hl7.org/fhir"><meta><profile value="http://hl7.org/fhir/StructureDefinition/OperationOutcome"/></meta><issue><severity value="error"/><code value="forbidden"/><details><text value="No or invalid secret provided for referenced Task"/></details></issue></OperationOutcome>

Bin mir also nicht sicher, ob es wirklich daran liegt (invalid secret, obwohl ja hier der access code angegeben werden soll, oder ist es nur ein Wording-Problem in der Fehlermeldung?).

ist nicht einer der Andwendungsfälle, eine Nachricht als Versicherter zu löschen?

https://github.com/gematik/api-erp/blob/master/docs/erp_communication.adoc#anwendungsfall-nachricht-als-apotheke-löschen

Könnt ihr bitte noch unter https://github.com/gematik/api-erp/blob/master/docs/erp_fhirversion_changes.adoc
die in der Sprechstunde angesprochene Exceldatei, die die Änderungen der Profile zusammenfasst, mit bereitstellen?

Ich dachte ich eröffne jetzt einfach mal ein GitHub issue zu diesem Thema.

Die Dokumentation ti_configuration.adoc ist sehr hilfreich, wie ich die Tage beim einrichten des eRezeptes in zwei Praxen feststellen durfte. Leider fehlt mir der Hinweis das gerade Enterprise Router/Gateways die den DNS Server zB. über den Dienst Unbound stellen, meistens auch "DNS rebind protection" aktiviert haben, dies führt dazu das die DNS records *.splitdns.ti-dienste.de nicht aufgelöst werden bzw. dürfen, da die Zurückgegebenen IP Adressen aus dem Privaten bzw. Shared Address-raum stammen. Dies ist so für die DNS abfragen eigentlich nicht vorgesehen und aus Sicherheitsgründen durch die DNS rebind protection unterbunden.

Man erhält folgende Antwort:

>nslookup erp.zentral.erp.splitdns.ti-dienste.de
Server:  OPNsense.home
Address:  192.168.1.1

*** Keine internal type for both IPv4 and IPv6 Addresses (A+AAAA)-Einträge für erp.zentral.erp.splitdns.ti-dienste.de verfügbar.

Wird der Eintrag dieser Records in den DNS Einstellung gesetzt, hier exemplarisch an einem OPNsense Gateway mit Unbound als DNS Server gezeigt =>

...funktioniert die Auflösung der DNS records ohne Probleme.

>nslookup erp.zentral.erp.splitdns.ti-dienste.de
Server:  OPNsense.home
Address:  192.168.1.1

Nicht autorisierende Antwort:
Name:    erp.zentral.erp.splitdns.ti-dienste.de
Addresses:  100.102.28.10
          100.102.29.10

Nach setzen der Routen (wie im .adoc gezeigt, angepasst an vorhandenes Gateway) funktioniert das eRezept wie es soll.

Ein Hinweis das DNS rebind protection der Grund für das "Nicht-funktionieren" sein könnte, wäre nicht verkehrt. Gerne kann ich hierzu auch ein PR erstellen.

unter "Anwendungsfall Nachricht als Apotheke an einen Versicherten schicken" findet sich das Bsp:
<contentString value="Hallo, wir haben das Medikament v ...

Das ist so nicht korrekt. Im ContentString wird ein JSON akzeptiert mit version, info_text, pickUpCodeDMC usw.
Ob Klartext 'auch' akzeptiert wird, kann ich nicht sagen.

Bitte mit den App-Entwicklern dafür sorgen, dass hier die gesamte API incl der JSON-Extensions beschrieben wird.
PS.: Die Beschreibung wie die App etwas losschickt ist nett, aber außerhalb der Gematik irrelevant. Da sollte man etwas kürzen, damit der Anwendungsfall klar ist, dass die App etwas schickt, aber Augenmerk muss hier klar, die Unterstützung für Umsetzung auf AVS-Seite sein.

Ein 2. Problem, ist leider, dass unter 'Anwendungsfall Alle Nachrichten vom E-Rezept-Fachdienst abrufen' im Bsp gezeigt wird, dass die App in Richtung AVS eine Belieferungsanfrage macht. Dies kann die App heute überhaupt nicht und daher ist da auch auf AVS-Seite nichts zu implementieren. Vielmehr kommen aber trotzdem GEM_ERP_PR_Communication_InfoReq Nachtrichten in die Apotheke Allerdings nur mit Freitextnachrichten, die der Patient geschrieben hat. Bitte unbedingt auf das Level korrigieren, was die App wirklich kann.

3. Problem:
   zu GEM_ERP_PR_Communication_DispReq gibt es zwar ein JSON-Bsp. wie die App das versendet. Aber es gibt kein Bsp, wie es auf Apothekenseite ankommt. Da kommt nie JSON sondern immer XML an

erp_consent.adoc
hier und ggf. in anderen parallelen Dokudateien wäre es sinnvoll gleich am Anfang klar zu machen, welches System (PVS, AVS oder eben NUR Gematik-App) diese API nutzen darf.

In der Dokumentation über den Abruf von eRezepten und vermutlich an vielen anderen Stellen wird der Aufruf an den Konnektor mit einer Beispielhaften IP angegeben. Vlt. wäre es besser hier direkt von konnektor.konlan auszugehen, und die Information über die CA-Zertifikate die zur Validierung heruntergeladen werden müssen anzufügen.

Diese Infomationen könnten auch gesammelt im Thema Netzwerkkonfiguration (ti_configuration.adoc) behandelt werden. Eine Auflistung der Zertifikatsdownload als Liste wäre sicher hilfreich:

• PU: https://download.tsl.ti-dienste.de
• RU: https://download-ref.tsl.ti-dienste.de/
• TU: https://download-test.tsl.ti-dienste.de/

As mentioned in #8, "patient data is the most intimate of our data". Therefore, E2EE should be mandatory. Especially for an app like this. So please implement E2EE.

Is the following news still up to date or obsolete?
https://www.heise.de/news/E-Rezept-kommt-ohne-Ende-zu-Ende-Verschluesselung-4927214.html
The article is in german only. Sorry for this. Basically it says, all data beeing transfered between E-Rezept-App and Telematik-Infrastruktur (TI) are not encrypted.

Hallo zusammen,
ich bin ehrlich ich schaue mir das ganze an und verstehe hier kaum was und finde auch leider nichts was mir selber direkt weiterhilft.

Ich suche bspw. verzweifelt eine OpenAPI Schnittstelle welche funktioniert aber weder die PU, RU noch die RU-DEV funktionieren bei mir.

Könnte man mir (und anderen unwissenden) vielleicht grob erklären wie der Aufbau ist? Denn ich habe auch nichts direktes zu authenfizierung gefunden oder auch nicht wie ich mir die E-Rezepte ausgeben lasse.

Dadurch dass ich mir selber eine kleine App dafür bauen wollte, wäre mir auch eine OpenAPI Dokumentation am liebsten wo man mit verschiedenenen Requests rum experementieren kann und weiß was grob zurückkommt + man auch versteht wofür welche Paramter stehen und auch Beispielwerte dafür.

Ich denke aber auch sehr aus der Sicht eines Entwicklers und vielleicht verstehe das Grundprinzip dieser Dokumentation nicht, wäre auf jeden Fall super wenn man mir hier weiterhelfen könnte!

Danke & Gruß
Justin

Thanks for open-sourcing the app and interface documentation.
I am posting here because I cannot open an issue here https://github.com/gematik/api-erp.

Unfortunately, the functional and technical design and implementation is now already in place, which means that reworking basic design decisions is now time-consuming and costly. It would be good if this was recorded in a lessons learnt register to management for future decisions.

Patient data is the most intimate of our data. This requires the highest security and data protection requirements on the system not only by the GDPR but also for acceptance. The current design is for prescriptions for insured persons to be stored entirely at Gematik. https://github.com/gematik/api-erp/blob/master/docs/erp_versicherte.adoc#anwendungsf%C3%A4lle-e-rezept-als-versicherter-verwalten

This entails great risks, which would not necessarily have to be taken. It would be conceivable, for example, that prescriptions are signed by Gematik when they are written (it would be even better if doctors had their own expiring, revocable keys, which in turn would be issued by a Gematik CA), but then not stored centrally but on the customer's device. As soon as the patient brings his prescription to a pharmacy, the authenticity of the prescription is checked via the signature and only one transaction is stored for redeeming and thus invalidating the prescription. This does not require any personal or prescription-related data to be stored, collected or processed.
The argument that prescriptions could be lost in this way does not apply here, as patients can also lose the printout or their Access_Token in the current solution.

My proposed solution is probably not state of the art. However, it would be good if the whole workflow could be reviewed with data protection experts on privacy by design and revised accordingly. Currently, the implementation means a significant unnecessary deterioration in the level of data protection of prescriptions.

In dieser Spezifikation wird nicht dargestellt wie Dritte in den Prozess eingebunden werden können. Die folgenden beispielhaften Fälle sollten von der Spezifikation abgedeckt werden:

• Wie kann ein Altenheim überprüfen, ob ein ausgestelltes Rezept korrekt ist?
• Wie kann ein pflegender Angehöriger ein Rezept einlösen?
• Wie kann ein Altenheim Rezepte für einen Bewohner anfordern?