Ein eigenes Batteriepass-System zu bauen ist machbar, doch die Arbeit steckt überwiegend in unsichtbarer regulatorischer Infrastruktur statt in der sichtbaren Webseite. Sie übernehmen die Umsetzung der Zugriffsebenen aus Anhang XIII, der Kennungen nach ISO/IEC 15459, des von Artikel 77 Absatz 1 verlangten Modells je Batterie, der QR-Erzeugung, eines unveränderlichen URL-Schemas und eines dauerhaften Hostings über den gesamten Aufbewahrungszeitraum.
| Fähigkeit | Eigenentwicklung | Batteriepass-Werkzeug |
|---|---|---|
| Modell „Pass je Batterie“ | Sie entwerfen es selbst korrekt | Eingebaut |
| Durchsetzung der Anhang-XIII-Ebenen | Sie implementieren serverseitiges Gating | Eingebaut |
| QR-Erzeugung (druckfähig) | Sie bauen sie | Eingebaut |
| Unveränderliche Pass-URL | Sie entwerfen das Schema | Eingebaut |
| 10 Jahre Aufbewahrung | Hosting-Beständigkeit liegt bei Ihnen | Bereitgestellt |
| Regulatorische Aktualisierungen | Ihr Team verfolgt und implementiert sie | Vom Anbieter gepflegt |
- Eigenentwicklung passt zu Teams mit Plattform-Engineering-Kapazität und individuellem Integrationsbedarf.
- Ein Werkzeug passt zu Teams, die schnell einen konformen Pass zu planbaren Kosten brauchen.
- In beiden Fällen sind Granularität je Batterie und Zugriffsebenen nicht verhandelbar.
Frequently asked
Wie lange dauert es, ein Batteriepass-System selbst zu bauen?
Das variiert, doch eine korrekte Umsetzung umfasst mehr als eine Webseite: Zugriffsgating, eindeutige Kennungen, QR-Erzeugung, ein unveränderliches URL-Schema und dauerhaftes Langzeit-Hosting. Typischerweise Wochen bis Monate — gegenüber demselben Tag mit einem spezialisierten Werkzeug.
Was machen die meisten Eigenentwicklungen falsch?
Die beiden häufigsten Fehler sind, Pässe je Modell statt je Batterie zu bauen (ein Verstoß gegen Artikel 77 Absatz 1) und die Zugriffsebenen nach Anhang XIII nicht serverseitig durchzusetzen.