Übersetzung als Serviceleistung. Bei Abweichungen ist die italienische Fassung dieses Dokuments maßgeblich.

Sicherheit und Datenschutz

Version 0.3 · Letzte Überprüfung: 8 novembre 2026

Entwurf nicht unterzeichnet, zur Konsultation veröffentlicht. Die Gesellschaft, die den Dienst erbringt, hat eine Umsatzsteuernummer; die REA-Nummer wird ergänzt, sobald die Eintragung ins Unternehmensregister abgeschlossen ist. Bis dahin kann dieses Dokument nicht unterzeichnet werden.

Überarbeitung vom 19. Oktober 2026. Die Abschnitte zu Verschlüsselung, Zugriff auf den Server, Sicherungskopien und Entwicklung wurden anhand von Code und Server korrigiert. Insbesondere ist die Datenbank im Ruhezustand nicht verschlüsselt, und die Sicherungskopie an einem externen Standort ist noch nicht aktiv. Die übrigen Abschnitte werden vor der Unterzeichnung des ersten Vertrags noch Zeile für Zeile erneut geprüft.

Dieses technische Datenblatt beschreibt die technischen und organisatorischen Sicherheitsmaßnahmen, die Fibonacci (nachfolgend „Fibonacci“ oder der „Auftragsverarbeiter“) bei der Bereitstellung der SaaS-Software Fibonacci für die digitale Patientenakte (nachfolgend der „Dienst“ oder „Fibonacci“) umsetzt. Das Dokument wird gemäß Artikel 32 der Verordnung (EU) 2016/679 (nachfolgend „GDPR“) bereitgestellt und bildet die Anlage A der Vereinbarung zur Auftragsverarbeitung (DPA), die der Arzt als Kunde in seiner Eigenschaft als Verantwortlicher unterzeichnet. Die beschriebenen Maßnahmen gelten für die Verarbeitung besonderer Kategorien von Daten im Sinne von Art. 9 GDPR (Gesundheitsdaten), die im Rahmen des Dienstes im Auftrag des Verantwortlichen erfolgt.

Das Dokument ist unter https://fibonaccimedica.it/sicurezza (öffnet in einem neuen Tab) veröffentlicht und wird regelmäßig aktualisiert, entsprechend der technischen Weiterentwicklung des Dienstes und dem Stand der Technik im Bereich der Informationssicherheit. Wesentliche technische Änderungen werden den Kunden als Verantwortlichen auf die am Ende dieses Dokuments angegebene Weise mitgeteilt.

1. Sicherheitsarchitektur

Die Sicherheitsarchitektur von Fibonacci ist in drei konzentrische Ebenen gegliedert, die jeweils unabhängige und sich ergänzende Kontrollen umsetzen. Die Verteidigungslogik folgt dem Prinzip der Tiefenverteidigung (Defense in Depth): Der Ausfall einer einzelnen Ebene genügt nicht, um die Vertraulichkeit, Integrität oder Verfügbarkeit der klinischen Daten zu gefährden.

1.1 Netzwerkebene (Perimeter)

Der Netzwerkperimeter wird in der Infrastruktur von Aruba S.p.A. betrieben, in einem italienischen Netz und damit innerhalb der Europäischen Union. Der eingehende Datenverkehr läuft ausschließlich über einen Caddy-Reverse-Proxy, der TLS (Versionen 1.2 und 1.3) terminiert und die in Abschnitt 6 beschriebenen HTTP-Sicherheitsheader setzt. Das Anwendungs-Backend ist nicht direkt aus dem öffentlichen Internet erreichbar: Die Docker-Container kommunizieren über ein privates Netzwerk, und der administrative Zugriff auf den Server ist nur mit SSH-Schlüssel möglich, ohne Passwortauthentifizierung (Konfiguration geprüft am 19. Oktober 2026).

Es ist keine Netzwerk-Zwischenstelle zwischengeschaltet. Die Domain des Dienstes wird direkt auf die Adresse der oben beschriebenen Infrastruktur aufgelöst: Es werden keine Content-Delivery-Netzwerke, keine Reverse-Proxys Dritter und keine von Dritten verwalteten Web Application Firewalls eingesetzt, und es gibt keine Stelle, an der eine andere Person als der Auftragsverarbeiter die vom Browser kommende verschlüsselte Verbindung terminiert. Dies lässt sich von außen mit einer DNS-Abfrage auf die Domain des Dienstes überprüfen.

1.2 Anwendungsebene

Auf Anwendungsebene setzt Fibonacci Multi-Faktor-Authentifizierung, eine gehärtete Sitzungsverwaltung, rollenbasierte Zugriffskontrolle (RBAC) und eine FHIR-Kompartimentierung pro ärztlichem Mandanten (Tenant) um. Jede Anfrage wird durch serverseitige Middleware zur Bereinigung der Eingaben, durch CSRF-Schutz und durch Rate Limiting pro Benutzer und pro IP-Adresse geprüft. Die Anwendungslogik ist in stark typisierten Sprachen geschrieben und folgt den in Abschnitt 7 beschriebenen Praktiken der sicheren Entwicklung.

1.3 Datenebene

Auf Datenebene verschlüsselt Fibonacci die klinischen Fotos vor dem Hochladen im Browser mit AES-256-GCM. Der Schlüssel jedes Fotos wird durch einen Schlüssel pro Praxis (Key Encryption Key, KEK) geschützt, der vom Signaturdienst verwaltet und nie an den Browser ausgeliefert wird. Die Sicherungskopien werden vor dem Schreiben verschlüsselt. ⚠️ Zum Zeitpunkt dieser Revision ist die Datenbank im Ruhezustand nicht verschlüsselt, weder auf Festplattenebene noch für einzelne Felder: Sie ist durch den Zugriffsschutz auf den Server und durch die Trennung nach Praxis geschützt. Jeder CRUD-Vorgang auf klinische Ressourcen wird in einem unveränderlichen Audit-Log im Format FHIR AuditEvent protokolliert, signiert in einer SHA-256-Hash-Kette (Abschnitt 4).

1.4 Vereinfachtes Flussdiagramm

                              TLS, ohne Zwischenstellen
   [Browser Arzt]  ----------------------------------->  [Caddy Reverse-Proxy / Aruba IT]
                       (Cookie httpOnly Secure)                     |
                                                                    |  privates Netzwerk
                                                                    v
                                                       [App-Container Fibonacci]
                                                                    |
                                       +----------------------------+----------------------------+
                                       |                            |                            |
                                       v                            v                            v
                              [PostgreSQL]              [Foto-Speicher AES-256]         [Audit-Log Hash-Kette]
                                       |
                                       v
                                  [Tägliches verschlüsseltes Backup (age)]  

2. Verschlüsselung

Die Verschlüsselung ist die wichtigste Maßnahme zur Minderung des Risikos von Datenexfiltration und unbefugtem Zugriff auf die Daten. Fibonacci setzt Verschlüsselung bei der Übertragung, Verschlüsselung der klinischen Fotos und Verschlüsselung der Sicherungskopien ein.

2.1 Schlüsselverwaltung

Die Verschlüsselungsschlüssel der Anwendung (Key Encryption Keys) werden serverseitig verwahrt und dem Browser der ärztlichen Nutzer nie offengelegt. Die Ableitung der Data Encryption Keys (DEK) für den einzelnen Datensatz erfolgt im Arbeitsspeicher des Backends zum Zeitpunkt des Schreib- oder Lesevorgangs. Die Schlüssel werden bei Backups nicht im selben Paket wie die verschlüsselten Daten abgelegt. Die Rotation der KEK ist ein dokumentiertes Verfahren und verschlüsselt die vorhandenen Daten schrittweise neu, ohne den Dienst zu unterbrechen.

2.2 Integrität

Der GCM-Modus (Galois/Counter Mode) gewährleistet gleichzeitig Vertraulichkeit und Integrität. Der Auth-Tag prüft, dass die Nutzdaten nicht verändert wurden, und weist jeden Manipulationsversuch am Ciphertext zurück. Diese Eigenschaft ist besonders wichtig für klinische Fotos, bei denen die Änderung eines einzigen Bits den Beweiswert der Daten aufheben würde.

3. Zugriffskontrolle und Authentifizierung

Die digitale Identität ist die primäre Angriffsfläche einer Cloud-Anwendung im Gesundheitswesen. Fibonacci setzt auf Multi-Faktor-Authentifizierung, robustes Passwort-Hashing, eine gehärtete Sitzungsverwaltung sowie eine Abschottung der Datendomäne auf Rollenbasis und auf FHIR-Basis.

3.1 Authentifizierung

3.2 Sitzung

Die Benutzersitzungen werden über Cookies mit den Attributen httpOnly, Secure und SameSite=Strict verwaltet. Das Attribut httpOnly verhindert den Zugriff auf das Cookie über clientseitiges JavaScript und verringert damit die Auswirkungen möglicher XSS-Schwachstellen. Das Attribut Secure erzwingt die Übertragung ausschließlich über TLS. Das Attribut SameSite=Strict mindert Angriffsklassen wie Cross-Site-Request-Forgery und Cross-Site-Leaks. Das Sitzungstoken wird rotiert: Jede Erhöhung der Berechtigungen (Login, Passwortänderung, Aktivierung der MFA) erzeugt eine neue Kennung und macht die vorherige ungültig.

3.3 RBAC und Abschottung

Der Zugriff auf klinische Ressourcen wird durch ein RBAC-Modell mit den folgenden Mindestrollen geregelt:

Oberhalb des RBAC-Modells greift die FHIR-Abschottung über die AccessPolicy von Medplum: Jeder Arzt ist auf seine eigenen Patienten beschränkt, die FHIR-Abfragen werden serverseitig gefiltert, und ein mandantenübergreifender Leseversuch wird abgelehnt und im Audit-Log protokolliert. Die Abschottung ist die wichtigste Maßnahme zur Minderung des Risikos von Lateral Movement und von unbefugtem Zugriff zwischen verschiedenen Arztpraxen, die dieselbe Instanz nutzen.

4. Integrität und Nachvollziehbarkeit

Bei Gesundheitsanwendungen ist die Integrität der Daten Voraussetzung für ihren Beweiswert und ihre klinische Aussagekraft. Fibonacci implementiert ein unveränderliches Audit-Log im Format FHIR AuditEvent mit kryptografischer Verkettung der Einträge (Hash-Chain).

4.1 Audit-Log

Jeder CRUD-Vorgang auf FHIR-Ressourcen (Patient, Encounter, Observation, Condition, MedicationStatement, DocumentReference, Consent, ImagingStudy und vergleichbare) erzeugt einen AuditEvent-Eintrag mit folgenden Angaben:

• Kennung des Akteurs (Arzt, Rolle, Sitzung);
• hochauflösender UTC-Zeitstempel;
• Art der Aktion (create, read, update, delete, sign);
• Verweis auf die betroffene Ressource;
• Ergebnis (success, failure) und Grund einer etwaigen Verweigerung;
• IP-Adresse der Herkunft und User-Agent.

4.2 Hash-Chain

Jeder Audit-Eintrag enthält den SHA-256-Digest des vorhergehenden Eintrags und bildet so eine Hash-Kette, die einem Append-only-Register entspricht. Jede nachträgliche Manipulation eines dazwischenliegenden Eintrags würde die Kette unterbrechen und ließe sich durch deterministische Überprüfung des Registers feststellen. Der Digest des letzten Eintrags kann als regelmäßiger Integritätsnachweis exportiert werden.

4.3 Zugriff und Aufbewahrung

Das Audit-Log ist für den Verantwortlichen über den Bereich /audit des geschützten Bereichs zugänglich, mit Filtern nach Akteur, Ressource und Zeitfenster. Die Aufbewahrungsdauer beträgt zehn Jahre ab dem Ereignis, entsprechend der Aufbewahrungspflicht für Gesundheitsdokumentation. Nach Ablauf wird der Datensatz sicher gelöscht oder anonymisiert, gemäß den Weisungen des Verantwortlichen.

5. Verfügbarkeit und Backup

Die kontinuierliche Verfügbarkeit der klinischen Daten ist ebenso wie Vertraulichkeit und Integrität eine Sicherheitseigenschaft und ist ausdrücklich Gegenstand von Art. 32 Abs. 1 Buchst. b und c GDPR.

5.1 Externe Kopie: erklärte Einschränkung

⚠️ Zum Zeitpunkt dieser Revision liegt die Sicherungskopie auf demselben Rechner, den sie schützt. Die Einrichtung für die Replikation bei einem externen Anbieter ist installiert und aktiv (der geplante Job läuft und protokolliert in seinen Logs ausdrücklich, dass kein Ziel konfiguriert ist), das entfernte Ziel ist jedoch noch nicht erworben und konfiguriert. Die Konsequenz muss vollständig benannt werden: Der Verlust des Hosting-Anbieters würde heute den Verlust des Systems und seiner Kopie zugleich bedeuten.

Die Einschränkung wird hier erklärt und nicht in einer Fußnote, weil es genau die Art von Information ist, die ein Verantwortlicher kennen muss, bevor er einem Auftragsverarbeiter Daten anvertraut, und weil die externe Kopie ausdrücklich Gegenstand von Art. 32 Abs. 1 Buchst. c GDPR ist. Das entfernte Ziel wird ein Anbieter sein, der sich von demjenigen unterscheidet, der die primäre Infrastruktur hostet, und der in der Europäischen Union ansässig ist: Eine Kopie, die beim selben Anbieter liegt, ist keine externe Kopie.

Dieser Absatz wird durch die Beschreibung der aktiven Maßnahme ersetzt, sobald diese in Betrieb und geprüft ist.

5.2 Wiederherstellungstest

Vierteljährlich wird ein vollständiger Wiederherstellungstest auf Grundlage des jüngsten Backups auf einer Nicht-Produktivinstanz durchgeführt. Dabei werden die Integrität der wiederhergestellten Daten und die tatsächliche Wiederherstellungszeit geprüft. Das Ergebnis des Tests wird protokolliert und als Nachweis gemäß Art. 32 Abs. 1 Buchst. d GDPR aufbewahrt (Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen).

6. Hardening der Anwendung

Fibonacci setzt eine Hardening-Konfiguration für Front-End und Back-End ein, die darauf abzielt, die Angriffsfläche der für Webanwendungen relevantesten Klassen der OWASP Top 10 zu verringern.

7. Sichere Entwicklung (Secure SDLC)

Die Sicherheit ist in den Entwicklungszyklus der Software integriert (Security by Design gemäß Art. 25 GDPR), und zwar durch automatische Kontrollen und menschliche Prüfung bei jeder Codeänderung.

Die Produktionsgeheimnisse (Schlüssel, Token, Dienstpasswörter) werden über einen Secret Manager der Infrastruktur verwaltet, sind nie im Quellcode enthalten und werden regelmäßig oder bei jedem Verdacht auf Offenlegung rotiert.

8. Incidentmanagement und Datenschutzverletzungen (Data Breach)

Fibonacci wendet ein dokumentiertes Incident-Response-Verfahren an, das Rollen, Eskalationsschwellen, Meldefristen und die Art der Kommunikation mit dem Verantwortlichen festlegt.

8.1 Meldung an den Verantwortlichen

Im Falle einer Verletzung des Schutzes personenbezogener Daten im Sinne von Art. 4 Nr. 12 GDPR, die Daten betrifft, die im Auftrag des Verantwortlichen verarbeitet werden, meldet Fibonacci dem Verantwortlichen den Vorfall innerhalb von 24 Stunden nach Entdeckung. Diese Frist ist strenger als die für den Auftragsverarbeiter in Art. 33 Abs. 2 GDPR vorgesehene Mindestanforderung „unverzüglich“ und soll dem Verantwortlichen gegenüber den 72 Stunden nach Art. 33 Abs. 1 für seine etwaige Meldung an die Aufsichtsbehörde einen großzügigen Spielraum verschaffen.

Die Meldung an den Verantwortlichen enthält, soweit zum Zeitpunkt der ersten Mitteilung verfügbar:

• Beschreibung der Art der Verletzung;
• Kategorien und ungefähre Zahl der betroffenen Personen und der betroffenen Datensätze;
• wahrscheinliche Folgen;
• zur Eindämmung ergriffene oder vorgeschlagene technische und organisatorische Maßnahmen;
• operative Kontaktstelle innerhalb von Fibonacci.

Informationen, die zum Zeitpunkt der ersten Meldung fehlen, werden dem Verantwortlichen schrittweise übermittelt, sobald sie verfügbar sind, im Einklang mit den EDPB-Leitlinien 9/2022.

8.2 Eskalation und Zusammenarbeit

Das interne Verfahren sieht die sofortige Aktivierung eines Incident Managers, die Isolierung des betroffenen Assets, die Sicherung forensischer Beweise und die Anlage eines Vorfallsregisters vor. Fibonacci arbeitet aktiv mit dem Verantwortlichen bei der Bewertung des Risikos für die betroffenen Personen und bei der Vorbereitung einer etwaigen Meldung an die Aufsichtsbehörde oder an die betroffenen Personen zusammen. Nach Abschluss des Vorfalls wird ein mit dem Verantwortlichen geteilter Post-Mortem-Bericht erstellt, der Timeline, Root Cause, umgesetzte Abhilfemaßnahmen und langfristige Korrekturmaßnahmen (Lessons Learned) enthält.

8.3 Register

Alle Vorfälle werden unabhängig von ihrer endgültigen Einstufung als meldepflichtige Verletzung im internen Vorfallsregister erfasst, das zu Audit-Zwecken und als Nachweis gemäß Art. 33 Abs. 5 GDPR geführt wird.

9. Internationale Übermittlungen

Für die Verarbeitung der Gesundheitsdaten der Patienten nimmt Fibonacci keine Übermittlung außerhalb der Europäischen Union vor. Der gesamte Anwendungsstack, die Datenbank, der Foto-Speicher und die Backups liegen in der Infrastruktur von Aruba S.p.A., in einem italienischen Netz.

9.1 Keine außereuropäischen Vermittler auf dem Datenweg

Der Weg, den das klinische Datum zwischen dem Browser des Arztes und der Datenbank zurücklegt, führt über keinen außereuropäischen Akteur, und zwar konstruktionsbedingt und nicht durch Konfiguration: Es wird weder ein Content Delivery Network noch ein Reverse Proxy eines Dritten noch eine von Dritten betriebene Web Application Firewall eingesetzt. Die Domain des Dienstes wird direkt auf die Adresse der Infrastruktur aufgelöst, und die verschlüsselte Verbindung wird ausschließlich vom Reverse Proxy des Auftragsverarbeiters terminiert.

Der Unterschied zum branchenüblichen Aufbau muss genannt werden, denn er ist der Grund, warum dieser Abschnitt kurz ist: Wenn ein Vermittler vorhanden ist, findet eine Übermittlung von Netzwerk-Metadaten in Drittländer statt, die mit Standardvertragsklauseln und zusätzlichen Maßnahmen gerechtfertigt werden muss. Hier gibt es die Übermittlung nicht, daher muss sie auch nicht gerechtfertigt werden. Dieser Umstand lässt sich von jedem von außen und ohne unsere Zustimmung durch eine DNS-Abfrage der Domain des Dienstes überprüfen.

9.2 Verbleibende Übermittlungen und ihr Umfang

Der einzige Unterauftragsverarbeiter der Kette mit Resilienz-Replikaten außerhalb der Europäischen Union ist der in Anhang B genannte Zahlungsdienstleister, der keine Daten von Patienten und keine klinischen Daten irgendeiner Art verarbeitet: Die Zahlungskette ist von der klinischen Kette getrennt, und der Abgleich erfolgt über eine opake Kennung. Für diesen Dienstleister gelten die Standardvertragsklauseln gemäß dem Durchführungsbeschluss (UE) 2021/914.

9.3 Weitere Unterauftragsverarbeiter außerhalb der EU

Etwaige weitere Unterauftragsverarbeiter außerhalb der EU werden ausschließlich mit Zustimmung des Verantwortlichen nach Maßgabe des DPA zugelassen und unterliegen denselben Garantien (SCC, zusätzliche Maßnahmen, Bewertung des Übermittlungsrisikos).

10. Betriebskontinuität

⚠️ Dieser Abschnitt beschrieb eine redundante Architektur, die der Dienst nicht hat. Die vorherige Fassung gab eine Verteilung auf mehrere Verfügbarkeitszonen an, mehrere Reverse-Proxy-Instanzen hinter Health Checks und eine Streaming-Replikation der Datenbank mit automatischer Promotion. Nichts davon ist in Betrieb: Der Dienst läuft auf einem einzigen Host. Eine nicht vorhandene Redundanz in einer unterzeichneten technischen Anlage anzugeben, ist genau die Art von Aussage, die der Verantwortliche nicht selbst überprüfen kann und bei der er Anspruch darauf hat, nicht getäuscht zu werden.

Es folgt der tatsächliche Stand, getrennt nach dem, was aktiv ist, und dem, was geplant ist.

11. Schulung und Governance

Technische Sicherheit ist nur wirksam, wenn sie von einer kohärenten organisatorischen Governance begleitet wird. Fibonacci verankert Schulungspflichten und klar definierte Verantwortlichkeiten in der eigenen Struktur.

12. Zertifizierungen und Referenzstandards

Derzeit ist Fibonacci nicht nach ISO/IEC 27001 zertifiziert. Auch ohne Zertifizierung wendet Fibonacci freiwillig die anwendbaren Kontrollen aus Annex A der Norm ISO/IEC 27001:2022 als Referenzrahmen für das eigene Sicherheitsniveau an, insbesondere in den Bereichen organisatorische Kontrollen, personenbezogene Kontrollen, physische Kontrollen und technologische Kontrollen. Dieser Bezug stellt keine zertifizierte Konformitätserklärung dar und darf nicht als Zertifizierungsbehauptung verstanden werden.

12.0 Was zertifiziert ist und von wem: die Unterscheidung, auf die es ankommt

Die Zertifizierungen, die einen Teil des Dienstes abdecken, gehören dem Infrastrukturanbieter, nicht Fibonacci. Die Unterscheidung wird hier ausdrücklich genannt, weil ein wenig gewissenhafter Anbieter sie weglässt und das Siegel seines Hosting-Anbieters vorzeigt, als wäre es sein eigenes.

⚠️ Was das konkret bedeutet: Dass das Rechenzentrum nach ISO/IEC 27001 zertifiziert ist, sagt etwas über die physische und organisatorische Sicherheit des Serverraums aus und nichts über die Qualität des Anwendungscodes von Fibonacci, über das Zugriffskontrollmodell oder über das Schlüsselmanagement. Wer die Zertifizierung seines Hosting-Anbieters als Garantie für die eigene Software präsentiert, beantwortet eine andere Frage als die gestellte.

Die Konformität mit der GDPR, insbesondere mit den Grundsätzen von Security by Design und Security by Default (Art. 25 GDPR) und mit den geeigneten technischen und organisatorischen Maßnahmen (Art. 32 GDPR), wird vom Auftragsverarbeiter auf Grundlage der internen Dokumentation und der aufbewahrten Prozessnachweise selbst bescheinigt.

Zu den weiteren Standards und Leitlinien, die bei der Konzeption der in diesem Dokument beschriebenen Maßnahmen berücksichtigt wurden, ohne Gegenstand einer Zertifizierung zu sein, zählen:

• OWASP Top 10 2021 und OWASP Application Security Verification Standard (ASVS) für sichere Entwicklungspraktiken und die Härtung der Anwendung;
• NIST Special Publication 800-53 als Vokabular für Sicherheitskontrollen;
• EDPB-Leitlinien 9/2022 zur Meldung von Verletzungen des Schutzes personenbezogener Daten.

12.1 Zertifizierungs-Roadmap

Fibonacci hat sich zum Ziel gesetzt, den Beginn des Zertifizierungswegs nach ISO/IEC 27001 zu prüfen, sobald die erste konsolidierte Runde von Pilotkunden des Dienstes erreicht ist. Der Fortschritt der Roadmap wird den Kunden als Verantwortlichen transparent durch regelmäßige Aktualisierungen dieses Dokuments und, wo angebracht, durch gesonderte Mitteilungen kommuniziert.

12.2 Europäischer Raum für Gesundheitsdaten: die Pflicht, die kommt

Die Verordnung (EU) 2025/327 errichtet den Europäischen Raum für Gesundheitsdaten (EHDS) und legt einen harmonisierten Rahmen für Systeme für elektronische Patientenakten fest. Die Verordnung gilt ab dem 26. März 2027; für Systeme, die für die Verarbeitung der prioritären Kategorien personenbezogener elektronischer Gesundheitsdaten nach Art. 14 Abs. 1 Buchst. a, b und c bestimmt sind, gelten die einschlägigen Bestimmungen ab dem 26. März 2029.

Für ein System für elektronische Patientenakten sieht die Verordnung folgenden Ablauf vor: Erstellung der technischen Dokumentation (Art. 37), Informationsblatt, das dem System beiliegt (Art. 38), EU-Konformitätserklärung hinsichtlich der wesentlichen Anforderungen aus Anhang II (Art. 39), Prüfung der harmonisierten Softwarekomponenten in einer europäischen digitalen Testumgebung (Art. 40), Anbringung der CE-Konformitätskennzeichnung (Art. 41) und Eintragung in die EU-Datenbank für Systeme für elektronische Patientenakten (Art. 49).

Fibonacci ist derzeit kein System mit CE-Kennzeichnung im Sinne von Kapitel III der Verordnung (EU) 2025/327 und gibt dies auch nicht an. Die Kennzeichnung kann heute nicht angebracht werden: Die gemeinsamen Spezifikationen der europäischen digitalen Testumgebung und das europäische Austauschformat für elektronische Patientenakten sind Durchführungsrechtsakten der Kommission vorbehalten.

Heute kann der Stand des Produkts in Bezug auf diejenigen Anforderungen des Anhangs II erklärt werden, die nicht von diesen Durchführungsrechtsakten abhängen:

13. Operative Kontakte

Meldungen von Schwachstellen sind willkommen und werden im Einklang mit den Praktiken der Responsible Disclosure bearbeitet. Auf Wunsch der meldenden Person kann ein verschlüsselter Kanal mithilfe des PGP-Schlüssels des Sicherheitsteams eingerichtet werden, der auf Anfrage zur Verfügung gestellt wird. Fibonacci verpflichtet sich, der meldenden Person innerhalb einer angemessenen Frist nach Eingang eine erste Rückmeldung zu geben, Meldungen, die in gutem Glauben und innerhalb des angegebenen Geltungsbereichs erfolgen, nicht rechtlich zu verfolgen und den Beitrag der meldenden Person öffentlich anzuerkennen, sofern keine Anonymität gewünscht wird.

14. Letzte Überarbeitung

Letzte Überarbeitung dieses Dokuments: 8 novembre 2026.

Dieses Dokument hat beschreibenden Charakter und entspricht dem aktuellen Stand der Software Fibonacci. Wesentliche technische Änderungen an den hier beschriebenen Sicherheitsmaßnahmen werden den Kunden, die Titolari (Verantwortliche) sind, per E-Mail an die im Dienstleistungsvertrag angegebene Kontaktadresse mitgeteilt, mit angemessener Vorlaufzeit vor ihrem Inkrafttreten. Version 0.3.