Review and implement privacy by design

[MaxGitHubAccount]

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.

[fnordlicht]

Thank you for your question.

The e-prescription is an official, transactional supply process in which it must be ensured that a prescription can only be filled once. If the insured person were to take a medically signed data record to the pharmacy on, for example, a USB stick, the following risks would exist:

• There is a risk of compromising the doctor's systems if the doctor records a USB stick.
• The pharmacist could have malicious code imposed on them to compromise their systems.
• Patients may have copied the data and filled a prescription more than once or even acquired it without permission (especially relevant for narcotics)
• Loss of the prescription due to loss of the USB stick
• Discriminatory supply scenarios, as the USB stick cannot be sent to online pharmacies

Local storage is therefore not feasible.

The e-prescriptions are transmitted in encrypted form from the doctor's practice to a central service, stored and processed there in encrypted form and retrieved again in encrypted form from the pharmacy. This protects the e-prescriptions from unauthorized access.
The data protection and security measures are ensured by two measures: Firstly, the components of the e-prescription are checked by independent experts before they are allowed to be used. Secondly, gematik monitors compliance with data protection and security by means of technical systems and by persons who regularly carry out audits of the operator of the e-prescription service. The independent experts prepare both a product expert assessment for the e-prescription service and a security expert assessment on the secure operation of the provider of the e-prescription service. In addition, the provider must prove through another expert assessment that it is capable of developing secure software. These expert assessments are reviewed by gematik. For the e-prescription app, gematik commissions (in accordance with the PDSG and SGB V §360 Para. 5) a security report, which is then reviewed by the Federal Office for Information Security and gematik. This assessment also includes the app's interfaces to the e-prescription specialist service and the identity provider. All expert assessments must be renewed regularly. In order to be able to recognise attacks on the e-prescription service in good time, permanent security monitoring takes place. This is carried out by gematik together with the provider of the e-prescription service. If the provider detects security incidents they must inform gematik. In addition to this constant technical monitoring, regular audits are carried out in which gematik checks whether the provider of the specialised e-prescription service is complying with the standards.

Issue was moved here from https://github.com/gematik/E-Rezept-App-Android. Please open issues only in their respective repositories as otherwise they will be closed as unrelated in the future.

[MaxGitHubAccount]

Good day,

Thank you for moving the issue. As you rightly point out, saving on a USB stick is not a good solution. That's why I was thinking of transferring the prescription to a device via a QR code, for example.

There is a risk of compromising the doctor's systems if the doctor records a USB stick.

does not apply with a QR-Code solution

The pharmacist could have malicious code imposed on them to compromise their systems.

does not apply with a QR-Code solution

Patients may have copied the data and filled a prescription more than once or even acquired it without permission (especially relevant for narcotics)

If you read the idea from above - once a patient uses his prescription it is invalidated on the central server.

Loss of the prescription due to loss of the USB stick

Does not apply as the solution would not be via an USB stick (you could btw also lose the print out in the current solution)

Discriminatory supply scenarios, as the USB stick cannot be sent to online pharmacies

Does not apply as the solution would not be via an USB stick

I think it's kind of rude describing a scenario with a usb stick which I never had in mind. It also misses the point. The main point is that this complete process should be reviewed with experts from IT, BA and the Commissioner for Data Protection. Thanks also for describing how security is ensured. I think it's very good that you have this process also including the BSI. However security != privacy and this process has a privacy problem so the BfDI would be the right person to include.

The process you describe processes and saves more data than necessary. The points you describe have value, but need to be tackled proportionally.

Like:

• You don't want to infect someones system (like usb stick) -> make it air gapped via scanning a code (your solution currently)
• You don't want a patient to use a code twice? make a anonymous log of used prescriptions
• …

No need for central data storage of all patients and all their prescriptions which could be abused. Think about it if this data is leaked some day. Insurances would value the data very high of what medicine I was using or my employer could see if I had burn out medicine before or if I plan to have a baby…

[Miademora]

Everyone assessing each other ad infinitum and burning money instead of implementing a secure solution, where a breach has no consequences, because theres no private data stored. What a way to wait for a security breach and burn money.
Back to dreamland where theres no leak ever, even when its been proven wrong thousands of times before.

[HendrikGematik]

As mentioned above, the e-prescription system has to enforce a workflow and validation of data and its signature. This is cannot be done with an end-to-end-encryption. To ensure privacy, integrity and avaliability the e-prescription server implements a trusted execution environment (TEE) that we call "VAU"-concept.

[MaxGitHubAccount]

Hi @HendrikGematik ,

thanks for your response. I also apologise for the rough answer which was given before (not by me), which I also can understand as if this data goes into wrong hands terrible things can happen - not even necessary in bad faith, could also happen via a not yet known security flaw (like log4j), so any data which isnt there in the first place is better (Datensparsamkeit). I honestly want this system as good as possible and made the effort to read the API-documentation. Could you please document or publish here (or link if I missed it) how you minimized data which could not be saved end-to-end and why? I am asking because e.g. for an email or n:n-video-chats there is end-to-end-encryption possible also ensuring signatures etc and I wonder why it isnt here and if it truly isnt possible that at least everything which could be hidden from the central server is hidden via e2ee as there is also no reason for any other data gathering (Zweckmäßigkeit).
It would be very kind if you could work with us instead of closing the issue which feels to me more like working against us.

[HendrikGematik]

@MaxGitHubAccount

Sorry to disappoint, this is not a matter of "with" or "against". You may trust the force. You may also accept, that there are workflows, that need to evaluate data in a serverside backend. In the ePrescription, data is minimized by design. As you can see for example in https://simplifier.net/erezept every object is minimized to the data that is needed for the process. And also, KBV, DAV and GKV name the purpose of each object's attribute in their technical appendixes to the Bundesmantelvertrag and related §§ in SGBV.
https://www.gkv-datenaustausch.de/media/dokumente/leistungserbringer_1/apotheken/technische_anlagen_aktuell/TA7_001_20210610.pdf
https://www.gkv-datenaustausch.de/media/dokumente/leistungserbringer_1/apotheken/technische_anlagen_aktuell/TA7_Anhang1_001_20210610_Mapping.pdf
https://update.kbv.de/ita-update/DigitaleMuster/ERP/KBV_ITA_VGEX_Technische_Anlage_ERP.pdf

Did you ever asked how your data is handled and protected outside the eHealth Telematikinfrastruktur?

I closed this issue, because any changes to this API description won't change the security architecture at all.

Best wishes for a merry christmas. Stay safe.

Hendrik

[MaxGitHubAccount]

Thanks for your response Hendrik. I will review your posts in time :-)

I also wish you and your family a wonderful christmas!