Done. 27 seconds :)

https://youtube.com/shorts/jo7uaF3hHdc

ㅤ

ㅤ

ㅤ

ㅤ

Call for Action

Looking for hackathon contributors

We're building a live, end-to-end prototype that opens a Swiss e-Health Dossier in 30 seconds — swiyu (e-ID), Verifiable Presentations, the existing EPD Bridge. Verifier from Adnovum; doctor-side client already real. We need help with the citizen side, the EGD backend, and demo polish.

Join if you bring:

• Frontend (React / TypeScript) — Swiss Health App, mobile-first
• Backend (Java / HAPI FHIR) — Matchbox interceptors
• UX / Visual design — the 30-second narrative
• DevOps (podman, Cloudflare, Infomaniak) — deploy stack
• FHIR / IHE domain advisors — CH:PPQm, CH:MHD reviewers
• Patient-perspective reviewers — would your grandmother make it in 30 seconds?

📬 Interested? Email your GitHub handle to aliaksei@dearauditor.ch — we'll add you as a collaborator on github.com/Gesundheitsdatenraum/30s2egd.

👉 The full story is in the deck. Sections below are a scan summary.

Problem & Target Group

Today's EPD onboarding is paper-bound, slow, and full of "paper & SOAP" media breaks. Identity, consent, and access live in disconnected worlds.

Affected: citizens still facing counter hours and postal mail, and the "long tail" of small ambulatory practices that need a legally sound path to patient-authorized data.

Available & Unavailable Data

Live: swiyu Public Beta + OID4VP (verifier from Adnovum); our swiyu-issuer for a Beta EPR-SPID credential; EPD Bridge (HIN, PDQm, MHD — production against Post Sanela); CH:EPR-FHIR v5.0.0, CH:PPQm 201/301, Matchbox; refdata.ch GLN sample.

Mocked: the productive EGD API, the citizen app, real patient data.

Expected Value

The dossier is opened end-to-end digitally on the patient's own phone — in the waiting room, no paper, no waiting. Consents are cryptographically signed and patient-readable. Interoperability stops being a pamphlet, becomes a workflow.

Hackathon Goal

Live demo on 28–29 May 2026:

1. Phase 1 — Auth. Patient → Swiss Health App → swiyu → dossier opens in 30 s (JIT POST /Patient + Consent template 201).
2. Phase 2 — Consent. Patient picks a doctor by GLN, grants access (template 301), optional research consent.
3. Phase 3 — Doctor loop. Doctor opens EPD Bridge, HIN-auths, finds the patient via PDQm, retrieves a pre-seeded document via MHD.

One coherent flow — no UI mockup.

Solution Approach

Four moving parts:

• Swiss Health App — citizen frontend (own).
• swiyu — OID4VP. Verifier from Adnovum.
• Mock EGD API — Matchbox + our HAPI interceptors (IUA, JIT onboarding, consent gating).
• EPD Bridge — already proves the doctor side works.

Code MIT at github.com/Gesundheitsdatenraum/30s2egd. Live demo: 30s2egd.dearauditor.ch.

Partners. Project lead — DearAuditor (Aliaksei Tsitovich, EPD Bridge developer). Verifier — Adnovum (Yves Lehner, David Freiburghaus, Axel Schild). Sustainability — Verein Gesundheitsdatenraum Schweiz (Ernst Hafen).

Constraints

• Test data only.
• No productive document storage, demo PDFs.
• Live EPD Bridge upload out of scope (post-hackathon).
• Research consent informal; productive HFG conformance is post-hackathon.
• Open standards, modular, portable into a real EPD/EGD environment.

Bedarf/Problem und Zielgruppe

Im Rahmen der AI Innovation Sandbox des Kantons Zürich wurden in den vergangenen Jahren mehrere KI-Pilotprojekte unter realen Bedingungen begleitet. Dabei sind Berichte entstanden, die wertvolle Erkenntnisse enthalten, zum Beispiel zu rechtlichen Rahmenbedingungen, Datenzugang, organisatorischen Voraussetzungen, technischen Herausforderungen und möglichen Lösungswegen.

Auswahl von Sandbox-Projekten:

· KI bei Baubewilligungen – KI-basierter Vorabcheck von Baugesuchen (z. B. Solaranlagen, Wärmepumpen)
· Maschinelle Übersetzung für Verwaltungstexte – automatische Übersetzung amtlicher Dokumente
· Autonome Inspektionssysteme – KI-gestützte Roboter für Anlagen- und Infrastrukturkontrollen
· Automatisierte Infrastrukturüberwachung – KI analysiert Sensordaten zur Wartung von Bauwerken
· Smart Parking – KI erkennt freie Parkplätze anhand von Kamerabildern
· KI in der medizinischen Dokumentation – automatische Erstellung medizinischer Berichte aus Gesprächen

Diese Erkenntnisse sind heute jedoch vor allem in einzelnen Berichten dokumentiert. Das erschwert den Zugang und die praktische Nutzung. Wer ein neues KI-Vorhaben plant, muss relevante Informationen oft erst mühsam suchen, einordnen und auf den eigenen Fall übertragen.

Das Problem betrifft insbesondere:

· Mitarbeitende der Verwaltung, die KI-Projekte prüfen, begleiten oder umsetzen
· Unternehmen und Start-ups, die KI-Lösungen im regulierten Umfeld entwickeln oder testen
· weitere Organisationen, die aus bisherigen Pilotprojekten lernen möchten

Gesucht ist daher eine Lösung, die das vorhandene Wissen so aufbereitet, dass es für diese Zielgruppen einfacher nutzbar und für neue Vorhaben anwendbar wird.

(Nicht) verfügbare Daten

Als zentrale Grundlage stehen die bestehenden Berichte und Erkenntnisse aus der AI Innovation Sandbox zur Verfügung. Diese enthalten konkrete Erfahrungen aus bereits umgesetzten Projekten und bilden die inhaltliche Basis der Challenge.

Voraussichtlich verfügbar sind:

· ausgewählte Berichte aus der AI Innovation Sandbox
· Kontext zur Zielsetzung und Arbeitsweise der Sandbox

Nicht im Fokus stehen:

· der Aufbau eines vollständig produktionsreifen Systems
· umfassende neue Datenerhebungen
· eine vollständige rechtliche Prüfung aller Inhalte
· der Zugriff auf beliebige zusätzliche Verwaltungsdaten ausserhalb des bereitgestellten Materials

Im Zentrum steht somit die Frage, wie das bereits vorhandene Wissen besser erschlossen, strukturiert und zugänglich gemacht werden kann.

Erwarteter Nutzen

Wenn das Problem gelöst ist, können künftige Nutzerinnen und Nutzer schneller und gezielter auf das Wissen aus der Sandbox zugreifen. Statt lange Berichte einzeln durchzuarbeiten, erhalten sie relevante Hinweise in einer Form, die für ihr konkretes Vorhaben verständlich und direkt nutzbar ist.

Das würde insbesondere bedeuten:

· Erkenntnisse aus früheren Projekten werden leichter auffindbar
· wiederkehrende Herausforderungen werden früher erkannt
· wichtige rechtliche, organisatorische und technische Fragen können früher berücksichtigt werden
· neue KI-Projekte können fundierter vorbereitet werden
· das in der Sandbox aufgebaute Wissen entfaltet mehr Wirkung über einzelne Projekte hinaus

Damit würde aus einer Sammlung von Berichten ein praktisch nutzbarer Wissensbestand für neue KI-Vorhaben.

Ziel für den Hackathon

Ziel des Hackathons ist es, einen überzeugenden Prototypen oder ein klar ausgearbeitetes Lösungskonzept zu entwickeln, das zeigt, wie die Erkenntnisse aus den Berichten der AI Innovation Sandbox künftig besser zugänglich und nutzbar gemacht werden können.

Die Lösung soll idealerweise aufzeigen, wie Personen mit einem konkreten KI-Vorhaben gezielt zu den für sie relevanten Erkenntnissen gelangen, zum Beispiel in Form von Hinweisen, Einordnungen, Checklisten oder Empfehlungen. Wichtig ist dabei, dass die Ergebnisse nachvollziehbar bleiben und auf die zugrunde liegenden Berichte zurückgeführt werden können. Als Fokus könnten beispielsweise Verwaltungsmitarbeitende gewählt werden, welche ein KI-Projekt bzw. -Piloten starten möchten.

Lösungsansätze

Ein möglicher Ansatz besteht darin, die vorhandenen Berichte digital aufzubereiten und mit Unterstützung von KI besser nutzbar zu machen.

Denkbar sind insbesondere folgende Elemente:

· Die Inhalte der Berichte werden so aufbereitet, dass sie systematisch durchsucht werden können.
· Nutzerinnen und Nutzer beschreiben ein geplantes KI-Projekt oder eine Fragestellung.
· Das System identifiziert dazu passende Erkenntnisse aus den vorhandenen Berichten.
· Die Lösung stellt die relevanten Hinweise in verständlicher Form dar, etwa als Übersicht, Antwort, Checkliste oder Handlungshinweise.
· Die Aussagen werden mit Verweisen auf die zugrunde liegenden Berichte nachvollziehbar gemacht.

Ergänzend kann es sinnvoll sein, Inhalte aus den Berichten strukturiert zu erfassen, zum Beispiel nach Themen wie Daten, Regulierung, Governance, Technik oder Umsetzung. Dadurch kann die Suche verbessert und die Relevanz für neue Anwendungsfälle leichter erkannt werden.

Was bereits verfolgt wird: Zur Unterstützung der Wissensvermittlung wurden auch Kurzvideos für jeden Bericht erstellt.

Einschränkungen

Die Challenge soll in einem begrenzten Zeitraum bearbeitet werden. Entsprechend geht es nicht um eine vollständige Endlösung, sondern um einen realistischen und überzeugenden Prototypen.

Worauf besonders zu achten ist:

· Die Lösung soll für nicht-technische Nutzerinnen und Nutzer verständlich sein.
· Die Inhalte müssen nachvollziehbar bleiben; Aussagen sollten auf konkrete Berichtsinhalte zurückgeführt werden können.
· Die Lösung soll sich eng an den tatsächlich vorhandenen Informationen orientieren und keine unbelegten Aussagen erzeugen.
· Der Umgang mit sensiblen Informationen und potenziell rechtlich relevanten Aussagen erfordert Sorgfalt.
· Der Fokus liegt auf praktischem Nutzen und nicht auf technischer Komplexität um ihrer selbst willen.
· Eine weitere Herausforderung ist auch die Aktualität der Inhalte – da wir bereits seit 4 Jahren Berichte erzeugen und sich die Rechtslage / Einschätzung im Bereich KI schnell verändern kann. Zum einen muss sichergestellt werden, dass die Informationen korrekt (d.h. nicht veraltet sind) und zum anderen muss es relativ einfach möglich sein, Informationen zu aktualisieren.

Falls möglich und im zeitlichen Rahmen ist eine mögliche Einbettung auf der Webseite der AI Innovation Sandbox zu berücksichtigen.

Nachhaltigkeit

Die Ergebnisse des Hackathons dienen als Grundlage für die weiteren Diskussionen zur künftigen Nutzung und Aufbereitung der Erkenntnisse aus der AI Innovation Sandbox.

Der Hackathon soll damit nicht nur Ideen sammeln, sondern konkrete Ansätze sichtbar machen, die das Potenzial haben, nach dem Anlass weiterverfolgt, vertieft oder in angepasster Form übernommen zu werden.

Unterlagen

I89H6B1C.pdf 3WA7IZVY.pdf 87MXEKJ3.pdf ACKRXKWG.pdf E6XDSMXU.pdf 3X6I8GB6.pdf NRFS5YOL.pdf XRQ98GZD.pdf 1Z71YRRF.pdf 📎 IE85U0OS.pdf sandbox de.pdf

GitHub-Repository

Official Repository: Innovation Sandbox for AI (Canton of Zurich)

Challenge pitch deck: https://s3.govtech.digisus-lab.ch/govtech/uploads/10/E66IA/W9M23L0C.pdf

Bedarf/Problem und Zielgruppe

Zielgruppe

Die Persona Freddy Fremd ist neu in der Schweiz, spricht die Sprache kaum und verliert seinen Job. Freddy repräsentiert ca. 40% der im Kanton Bern gemeldeten arbeitslosen Personen.

Problem

Arbeitslos zu sein ist hart genug und Freddy hat Existenzängste. Doch die Behördensprache und insbesondere die aktuelle digitale Journey machen es noch schwieriger arbeitslos zu sein: Er muss sich bei der Regionalen Arbeitsvermittlung (RAV) anmelden um sich danach mit AGOV für Job-Room (E-Service Plattform vom SECO) zu registrieren, wo er den Antrag auf Arbeitslosenent-schädigung einreichen muss, um Arbeitslosengeld zu erhalten. Dabei stösst er unter anderem auf folgende Hindernisse:

• Sprachbarriere
• Komplizierter Registrations- und Login-Prozess für Job-Room via AGOV
• Unübersichtliches Userinterface, Wordingprobleme und unklare User-Flows in Job-Room
• Verstreute Informationen über E Mails, SMS und Websites von verschiedenen Absendern
• Fehlende Kundenführung: Niemand nimmt mich in dieser Informationsflut wirklich an die Hand, damit ich weiss was wann, wie gemacht werden muss.
• Technische Hürden / Medienbrüche: Dateigrössen, Dateiformat, Drucker wird benötigt
• Angaben müssen mehrfach gemacht werden.

Verfügbare Daten

Verfügbare Daten in Systemen Wir als AVA Amt für Arbeitslosenversicherung haben Zugriff auf die Daten der Stellensuchenden. Diese werden in den vom SECO zur Verfügung gestellten Systemen AVAM und ASAL verwaltet. Es existieren sowohl strukturierte wie auch unstrukturierte Daten. Die Ownerschaft der Daten liegt bei SECO. Daten der arbeitlosen Personen sind besonders schützenswerte Daten.

Verfügbare Daten für Hackathon

• Persona Freddy Fremd
• Ist-User Journey Freddy Fremd inkl. Kommunikationsmittel
• Zugang zu Trainingsumgebung Job-Room
• Telefonischer Kontakt zu AVA Fachpersonen für fachliche Auskünfte
• Datenattribute einer Arbeitslosen Person in den Systemen

Erwarteter Nutzen

Wenn wir Freddy’s digitale Journey vereinfachen, helfen wir ihm folgendermassen:

• Er kann seine Aufgaben selbstständig und ohne Sprachbarriere erledigen.
• Er kann sich auf die Existenzsicherung und Arbeitssuche konzentrieren.
• Freddy passieren weniger Fehler und wird dadurch weniger sanktioniert (Einstelltage).
• Freddy nimmt die Mitarbeitenden zeitlich weniger in Anspruch und begegnet ihnen mit mehr Wohlwollen.

Ziel für den Hackathon

Wir wollen einen Prototypen entwickeln, der Freddy’s Digitale-Journey von der Anmeldung bei der Regi-onalen Arbeitsvermittlung (RAV) bis zum Antrag des Arbeitslosengeldes radikal vereinfacht.

Lösungsansätze

Was gibt es heute:

• Das SECO bietet mit Job-Room bestehende E Services. Job-Room ist jedoch nicht durchgängig in die Journey integriert weist eine schwache UX auf.
• Wir versuchen die Menschen kommunikativ mit E-Mails und Anleitungen besser zu führen. Die Sprachbarriere bleibt aber bestehen.
• Wir versuchen zudem auch die Kundschaft mittels SMS und E Mail Benachrichtigungen korrekt zu leiten, dies führt aber zu vielen Absprünge und viele Logins via AGOV, was immer eine menta-le Hürde ist.

Verschiedene kommunikative Optimierungen wurden umgesetzt, aber nie eine echte En-de zu Ende Perspektive aus Sicht eines vulnerablen Nutzers. Es wurden bisher keine konkreten Lö-sungsansätze implementiert oder getestet.

Einschränkungen

Die Daten gehören dem SECO-TC. und es gibt aktuell auch keine Schnittstellen, weil Daten explizit nicht zwischengespeichert werden dürfen.

• Datenschutz und Datensicherheit (DSG, kantonale Vorgaben)
• Transparenz und Nachvollziehbarkeit von KI-Entscheidungen
• Keine vollständige Automatisierung rechtlich relevanter Entscheide
• Realistische Integration in bestehende Systemlandschaft (keine „Greenfield-Utopie“)

Nachhaltigkeit

Was passiert danach:

• Weiterentwicklung im Rahmen der digitalen Transformation der Arbeitslosenversicherung
• Vertiefung als Pilotprojekt oder Innovationsinitiative
• Einbindung in strategische Programme (z. B. AVAM 2030 / digitale Transformation)

Ressourcen: Wir als AVA sind bereit das Projekt im Rahmen einer potenziellen Pilotierung weiterzutrei-ben. Wir bieten Zugang zu Fachexpertise (OE, Digitalisierung, Fachbereiche)

Gesuchte Skills

Welche Skills bringen wir bereits mit?

• Fachwissen
• UX-Expertise
• Digitale Projektleitung

Welche Skills suchen wir für unser Team am Hackathon?

• Frontend Entwickler/-innen
• Vibecoder/-innen
• Businessanalyse
• UX-Expert/-innen T8V24KJA.pdf

Testfiles

https://s3.govtech.digisus-lab.ch/govtech/uploads/27/G1N8X/2HOSEVMQ.pdf

A6BCHVVQ.pdf

8GG8NVD4.pdf

L44KEDND.pdf

AENISSWH.pdf

AIR72ERN.pdf

Bedarf/Problem und Zielgruppe

Die heutige digitale Behördenkommunikation ist fragmentiert: Bürgerinnen und Bürger nutzen unterschiedliche Portale, Logins und Kanäle je nach Behörde. Dies erschwert den Zugang, reduziert die Nutzerfreundlichkeit und schafft Abhängigkeiten von zentralen Plattformen. Betroffen sind insbesondere Einwohnerinnen und Einwohner, Unternehmen sowie Behörden auf kommunaler, kantonaler und nationaler Ebene.

(Nicht) verfügbare Daten

Verfügbar sind öffentlich bekannte Standards und Technologien wie Solid Pods, Verifiable Credentials, E-ID-Grundlagen sowie offene Schnittstellenkonzepte. Für einen Prototyp reichen synthetische Testdaten wie Steuerbescheide, Verfügungen oder Mitteilungen. Nicht verfügbar bzw. abzuklären sind produktive Verwaltungsdaten, bestehende Behördenschnittstellen, reale Zustellprozesse sowie zukünftige E-ID-Integrationen.

Erwarteter Nutzen

Bürgerinnen und Bürger hätten einen zentralen, selbst kontrollierten digitalen Briefkasten für Behördenkommunikation – unabhängig von einzelnen Portalen. Der Zugang zu staatlichen Leistungen würde einfacher, sicherer und nutzerfreundlicher. Behörden könnten standardisiert, interoperabel und effizient kommunizieren, während Datenhoheit, Transparenz und digitale Souveränität gestärkt würden

Ziel für den Hackathon

Ziel ist die Entwicklung eines klickbaren Prototyps oder End-to-End-Demos für eine dezentrale Behördenkommunikation auf Basis von Solid Pods. Gezeigt werden soll, wie eine Behörde ein Dokument sicher zustellt und wie Bürgerinnen und Bürger dieses nutzerfreundlich abrufen, verwalten und freigeben können. Zudem soll die technische Machbarkeit, Sicherheit und Interoperabilität des Konzepts validiert werden.

Lösungsansätze

Mögliche Lösungsansätze sind zentrale Zustellplattformen, klassische E-Government-Portale, E-Mail-basierte Kommunikation oder dezentrale Modelle mit Solid Pods und Verifiable Credentials. Bereits bekannt sind zentrale Ansätze wie „Meine digitale Post“ oder kantonale Portallösungen. Im Hackathon soll gezielt der dezentrale Ansatz mit Solid Pods, offenen Standards und optionaler E-ID prototypisch umgesetzt und mit bestehenden Modellen verglichen werden.

Einschränkungen

Zu beachten sind Datenschutz, Informationssicherheit und der rechtskonforme Umgang mit behördlichen Daten. Für den Hackathon sollten deshalb nur synthetische oder anonymisierte Testdaten verwendet werden. Die Lösung sollte auf offenen Standards, dokumentierten Schnittstellen und einer modularen Architektur basieren, damit Ergebnisse später weiterentwickelt und in bestehende Behördenlandschaften integriert werden können.

Nachhaltigkeit

Nach dem Hackathon werden die Ergebnisse dokumentiert und als Grundlage für eine mögliche Weiterentwicklung des Konzepts bewertet. Je nach Reifegrad kann ein Proof-of-Concept in eine weiterführende Pilotierung überführt werden.

Für eine mögliche Weiterentwicklung können begrenzte interne Ressourcen für Konzeptarbeit, technische Evaluierung und Architekturweiterentwicklung bereitgestellt werden. Ein fixes Budget oder dedizierte Projektmittel sind aktuell noch nicht definiert.

Teilnehmer:innen können bei Interesse in eine weiterführende Ideation- oder Pilotierungsphase eingebunden werden, z. B. über Workshops, technische Reviews oder eine spätere Open-Innovation- bzw. Community-Zusammenarbeit.

https://youtu.be/EVecVist64U

Bedarf/Problem und Zielgruppe

Für die Diplomatie der Schweiz stehen zahlreiche Datenquellen (z. B. IMF, World Bank, OECD, nationale Statistiken) zur Verfügung. Diese sind jedoch fragmentiert, unterschiedlich strukturiert und schwer kombinierbar. Dadurch entsteht ein hoher manueller Aufwand und wichtige Zusammenhänge für die datenbasierte Analyse bleiben ungenutzt. Betroffen sind insbesondere Mitarbeitende im EDA, in anderen Departementen sowie im Vertretungsnetz der Schweiz im Ausland, die regelmässig Länderanalysen, Berichte und Entscheidungsgrundlagen erarbeiten.

(Nicht) verfügbare Daten

Verfügbar sind zahlreiche offene Datenquellen wie IMF, World Bank, OECD, UNDP, SIPRI, sowie nationale Daten (BFS, SNB, SEM). Teilweise sind diese über APIs oder Downloads zugänglich. Nicht verfügbar bzw. eingeschränkt sind interne Daten oder lizenzpflichtige Quellen, die nur eingeschränkt genutzt werden können. Die Integration und Harmonisierung dieser Daten ist Teil der Challenge.

Erwarteter Nutzen

Daten könnten systematisch genutzt und kombiniert werden. Es entstünden strukturierte Länder- und Themenprofile, Trends und Vergleiche. Entscheidungsprozesse würden schneller, fundierter und datenbasierter erfolgen.

Ziel für den Hackathon

Ziel ist die Entwicklung eines Prototyps eines Datenportals, das verschiedene Datenquellen integriert, strukturiert darstellt und daraus Erkenntnisse sowie Synthesen (z. B. Trends, Vergleiche, Handlungshinweise) ableitet.

Lösungsansätze

Mögliche Ansätze sind Datenaggregation (APIs, Scraping), Datenmodellierung, Visualisierung (Dashboards) sowie Einsatz von KI zur automatischen Analyse und Zusammenfassung. Erste Ansätze bestehen in bestehenden Länderseiten (CH@World) und punktuellen Datenanalysen, jedoch ohne integrierte Gesamtsicht.

Open Data:

• https://int.api.eda.admin.ch/economics

• https://int.api.eda.admin.ch/openapi.json

• https://www.imf.org/en/Publications/SPROLLs/world-economic-outlook-databases#sort=%40imfdate descending

• https://data.imf.org/?sk=9d6028d4-f14a-464c-a2f2-59b2cd424b85

• https://data.imf.org/?sk=40313609-f037-48c1-84b1-e1f1ce54d6d5

• https://unctad.org/publication/world-investment-report-2023

• https://databank.worldbank.org/source/world-development-indicators

• https://population.un.org/wpp/

• https://www.sipri.org/databases/milex

• https://www.unhcr.org/refugee-statistics/download/?url=WEG34g

• https://www.iea.org/data-and-statistics

• https://hdr.undp.org/data-center/human-development-index#/indicies/HDI

• https://www.heritage.org/index/

• https://www.v-dem.net/

• https://www.transparency.org/en/cpi/2022

• https://www.wipo.int/edocs/pubdocs/en/wipo-pub-2000-2023-en-main-report-global-innovation-index-2023-16th-edition.pdf

• https://www.imd.org/centers/wcc/world-competitiveness-center/rankings/world-competitiveness-ranking/

• https://www.gate.ezv.admin.ch/swissimpex/

• https://app.powerbi.com/view?r=eyJrIjoiMTE0MmMxMWQtMjU2NS00Yzg5LWIyOWEtNDFlOGJmNjg3YTJmIiwidCI6IjZjNGI0ZWU0LWMxNmYtNGQyZC05NGQ4LTU5ZTE3ODUyYTkzZiJ9

• https://data.snb.ch/de/topics/aube/cube/fdiausbla

• https://www.bfs.admin.ch/bfs/de/home/statistiken/bevoelkerung/migration-integration/auslandschweizer.assetdetail.24310288.html

• https://www.bfs.admin.ch/bfs/de/home/statistiken/bevoelkerung/migration-integration/auslaendische-bevoelkerung/zusammensetzung.html

• https://www.sem.admin.ch/sem/de/home/publiservice/statistik/auslaenderstatistik/archiv/2023/12.html

• https://data.oecd.org/

• https://store.eiu.com/product/eiu-viewpoint-country-analysis/switzerland

Einschränkungen

Es dürfen nur frei zugängliche oder bereitgestellte Daten genutzt werden. Datenschutz und Lizenzbedingungen sind zu beachten. Der Fokus liegt auf einem Prototyp (kein produktiver Einsatz). Lösungen sollen modular und erweiterbar sein.

Nachhaltigkeit

Die Ergebnisse sollen intern weiterverwendet und in bestehende Plattformen (z. B. PowerBI, CH@World) integriert werden. Es können Ressourcen für eine Weiterentwicklung (Arbeitszeit, fachliche Begleitung) bereitgestellt werden. Eine Weiterarbeit mit interessierten Teilnehmenden ist nicht ausgeschlossen.

Bedarf/Problem und Zielgruppe

Entwickler:innen – und im Grunde jede Person, die Code veröffentlicht oder bestehende Projekte effizient wiederverwenden möchte.

(Nicht) verfügbare Daten

gimie: Ein Tool zur Erstellung von Turtle Knowledge Graphs aus Git-Repositories.

Publiccode-Quellen: Wir benötigen eine Liste von Repositories, die bereits publiccode.yml-Dateien nutzen. Diese Daten sind bereits öffentlich verfügbar; die Herausforderung liegt hier primär in der Kuratierung.

Erwarteter Nutzen

Wir möchten die Hürde für die Veröffentlichung von publiccode.yml-Dateien deutlich senken. Das Ziel ist ein Tool, das automatisch so viele Informationen wie möglich direkt aus GitHub extrahiert. So sparen sich Nutzer:innen Handarbeit und vermeiden Redundanz, da bereits vorhandene Metadaten direkt übernommen werden.

Ziel für den Hackathon

Die Entwicklung eines Erweiterungsmoduls für gimie, das in der Lage ist, die publiccode.yml-Datei eigenständig zu generieren.

Einschränkungen

Wir lieben lesbaren Code! KI-Tools sind super, solange ihr die Kontrolle über das Ergebnis behaltet. Da wir alle PRs sorgfältig prüfen, achtet bitte darauf, dass Dokumentation, Tests und Linting bereits „an Bord“ sind, bevor ihr den Request stellt.

Nachhaltigkeit

Das SDSC Ordes Team setzt gimie bereits aktiv in mehreren Projekten ein. Wir werden das Tool und die während des Hackathons entstehenden Erweiterungen daher auch langfristig betreuen und weiterentwickeln.8ZSWKXKX.pdf

Bedarf/Problem und Zielgruppe

Krisenstäbe und Führungsorgane auf Stufe Kanton und Gemeinde müssen regelmässig Krisen- oder Notlagesituationen üben (KFO, KFS, RFO, GFO, etc). Diese Übungen benötigen detallierte Szenarien und Drehbücher als Übungsgrundlage, aber entsprechende Szenarien, Übungsmeldungen und Abläufe zu erstellen ist aufwändig. Betroffen sind Gemeindeführungsstäbe, kantonale Führungsstäbe und die das BABS.

(Nicht) verfügbare Daten

Verfügbar (für Prototyp, soweit öffentlich oder am Hackathon zugänglich): • Detailierte Gefährdungsszenarien der nationalen Risikoanalyse KNS www.risk-ch.ch/matrix • Übungsformat einer möglichen Tabletop-Übung (Forum für Wissen 2025: 73–86 doi.org/10.55419/wsl:39744; https://www.dora.lib4ri.ch/wsl/dload/wsl:39736/PDF/ ) • Ereignisanalysen des BAFU (Ereignisanalysen Hochwasser-Ereignisse etc.)

Nicht verfügbar oder klärungsbedürftig (kann Teil der Challenge sein): • Weitere öffentlich zugängliche Unterlagen zu vergangenen relevanten Ereignissen im In- und Ausland • Öffentlich zugängliche Unterlagen von vergangenen Übungen. • Spezifische Informationen auf Regionen oder Gebiete runtergebrochen (Szenario-relevante Informationen zu den geographischen Gegebenheiten, Bevölkerungsdichte, Infrastrukturknotenpunkte etc.)

Erwarteter Nutzen

• Ein KI-gestützter Szenario-Generator, der bei der Erstellung von Übungsgrundlagen und Material wie Übungszenario, Drehbuch und Übungsmeldungen unterstüzen kann, würde einen grossen Teil der Übungsvorbereitung abnehmen und viel Zeit bei der Erstellung von Übungen ersparen. Diese würde es erlauben mit bestehenden personellen Resourcen mehr Übungen durchzuführen, was sich wiederum positiv auf die Fähigkeiten und Erprobtheit der Führungsorgane im Bevölkerungsschutz auswirkt. • Gemeinde- und Kantonsstäbe und Fachstellen erhalten ein Werkzeug zur Erstellung konsistenter, nachvollziehbarer Übungsszenarien mit klarer Quellenlage. • Zivilschutzorganisationen könnten von den Szenarien und Meldung für Ausbildungszwecke profitieren. • Die Privatwirtschaft könnte dieses Tool für BCM-Zwecke nutzen.

Ziel für den Hackathon

• Prototyp “Bevölkerungsschutz Szenario Generator”: KI-gestützter Generator von Übungsszenarien für Krisenstäbe im Bevölkerungsschutz • Inhaltlicher Mindestumfang: Gefährdungsspezifisches Übungsszenario mit 2 bis 4 Eskalationsstufen. Optional: Szenarioanpassungen bezogen auf regionalen Unterschieden, automatisierte Meldungen und Einsatzberichte, fortgeschrittene Randomisierung möglicher Gefährdungen basierend auf Eintrittswahrscheinlichkeiten der naitonalen Risikoanalyse, Übersetzung in FR und IT. • Technischer Mindestumfang: reproduzierbare Pipeline (Datenbezug, Aggregation, Template), lauffähig mit offenen oder am Hackathon bereitgestellten Daten.

Lösungsansätze

Mögliche Ansätze: • AI-Chatbot, Custom GPT, Claude Project • Übungsvorlage basierend auf vergangenen Tabletop-Übungen: feste Struktur (Ausganglage, Eskalationsstufen). • Qualität: Anzeige von Quellenangaben.

Bereits ausprobiert (realistisch formulierbar, ohne Überclaim): • Erster Proof-of-Concept mit Claude Projekt

Einschränkungen

• Datenzugang und Lizenzen: Es dürfen nur Daten genutzt werden, die offen sind oder für den Hackathon rechtlich und technisch freigegeben werden; keine personenbezogenen oder vertraulichen Verwaltungsdaten. • Nachvollziehbarkeit: Ergebnisse müssen reproduzierbar sein (Code, Datenquellen, Parameter, Versionen), damit eine spätere Integration möglich ist. • Quellenpflicht: Jede Kennzahl, Karte und Textaussage im Übungsszenario muss auf klar benannte Datenquellen und Datenstände verweisen; keine nicht belegten Interpretationen. • Scope: Fokus auf Prototyp statt Vollabdeckung aller Themen. • Architektur: Möglichst offene Standards, einfache Deploybarkeit, keine harten Abhängigkeiten von proprietären Systemen, die in der Verwaltung nicht betrieben werden können.

Nachhaltigkeit

• Weiterverwendung: Der Prototyp soll als Grundlage für einen Piloten dienen und für geplante kantonale Übungen eingesetzt werden, falls technisch und organisatorisch tragfähig. • Ressourcen intern: Bereitstellung von fachlicher Begleitung und Produktverantwortung grob 1 bis 2 Personen mit Teilpensum über mehrere Wochen nach dem Hackathon, Budget primär über Arbeitszeit. • Einbezug Teilnehmende: Fortführung über öffentliches Repository, kurze Follow-up Sessions. • Das Hackathon-Team wird für seinen Beitrag anerkannt

Bedarf/Problem und Zielgruppe

Viele Bundesämter verfügen über Daten in Form von CSV- oder Excel-Dateien, die regelmässig aktualisiert und auf Webseiten visualisiert werden sollen. Ein standardisierter, durchgängiger Prozess, um diese Daten effizient in Web-Visualisierungen zu überführen, fehlt bislang.

Zwar stehen mit Tools wie Visualize und der LINDAS platform geeignete Lösungen zur Verfügung, deren Nutzung ist jedoch komplex, teilweise manuell und schwer skalierbar. Insbesondere die notwendige Transformation der Daten in eine Linked-Data-Struktur (RDF) stellen eine Hürde dar.

Ziel ist es, diesen Prozess zu vereinfachen, zu automatisieren und als skalierbare Lösung für Fachstellen, sowie Kommunikations-, Data und Webteams in Bundesämtern nutzbar zu machen.

(Nicht) verfügbare Daten

Beispielhafte CSV- oder Excel-Daten Demo Pipelines für Integration in LINDAS Zugriff auf bestehende Tools wie LINDAS, Visualize und Livingdocs

Zu klären: Dokumentation zu LINDAS / Linked Data

Erwarteter Nutzen

Daten können schneller und einfacher publiziert werden, Visualisierungen lassen sich automatisch aktualisieren, Reduktion von manuellen Arbeitsschritten und Fehlerquellen, Einheitlicher, wiederverwendbarer Prozess innerhalb der Verwaltung, niedrigere Einstiegshürden für Fachstellen ohne vertiefte technische Kenntnisse.

Ziel für den Hackathon

Entwicklung eines Proof of Concept für einen automatisierten End-to-End-Prozess, die Machbarkeit zu demonstrieren, den Prozess zu vereinfachen und dokumentieren

Lösungsansätze

Aufbau einer automatisierten Datenpipeline (z. B. mit Python), die CSV/Excel in RDF transformiert und in LINDAS lädt, Nutzung bestehender Tools zur Integration in Visualize und Einbindung in Livingdocs.

Einschränkungen

Fokus auf einen Proof of Concept, nicht auf eine produktionsreife Lösung. Ergebnisse sollten reproduzierbar und dokumentiert sein

Nachhaltigkeit

Die Ergebnisse dienen als Grundlage, um die Machbarkeit eines standardisierten Prozesses zu beurteilen und mögliche Pilotanwendungen zu initiieren. Bei geeigneten Resultaten ist vorgesehen den Ansatz intern weiterzuverfolgen und die Lösung in einem konkreten Anwendungsfall weiter zu testen und auszubauen.

📎 HFFNW8JK.pdf

📎 QTJIJ4KE.pdf

Live demo on Apertus powered and hosted by Infomaniak 🇨🇭 govtech.watts-drive.ch

Challenge

In vielen Verwaltungsdatensätzen werden gleiche Inhalte unterschiedlich beschrieben: Ein Datensatz nennt den Status "active", ein anderer "laufend". Frauen erhalten im einen Datensatz den Code “w" zugeweisen, im anderen "1". Noch kniffliger wirds, wenn Kategorien nur teilweise übereinstimmen – etwa, wenn ein Datensatz lediglich «Grundschule» beinhaltet, während ein anderer zwischen «Primarschule» und «Sekundarstufe I» unterscheidet.

Solche Unterschiede erschweren den Datenaustausch und führen zu Unschärfen in Auswertungen. In dieser Challenge entwickelst du einen Prototypen, der Gemeinsamkeiten und Unterschiede zwischen Attributen sichtbar macht – oder sogar Unterschiede auflöst.

Grundlage sind Dateien im SHACL-Format, in denen Struktur und Attribute von Datensätzen beschrieben sind. Deine Lösung detektiert semantisch harmonisierbare Attribute. Vielleicht macht deine Lösung die Gemeinsamkeiten und Unterschiede in einem Dashboard sichtbar. Oder vielleicht generiert sie eine Mapping-Tabelle. Auf jeden Fall helfen deine Ideen dabei, die Behördendaten semantisch zu harmonisieren.

(Nicht) verfügbare Daten

Sämtliche öffentlich publizierten Einträge auf der Interoperabilitätsplattform I14Y.admin.ch. Bei Bedarf: der Code der Plattform.

Erwarteter Nutzen

Datenfachleute kennen das Problem: Viele Datensätze können nicht zusammengeführt werden, weil Attribute unterschiedlich definiert wurden. Das Fernziel ist eine Datenharmonisierung: Alle sollen identische Attribute gleich erfassen. In einer Zwischenphase kann es aber nötig sein, die Gemeinsamkeiten und Unterschiede zu dokumentieren. Damit wird die Grundlage für eine Datenharmonisierung geschaffen. Und damit wird es möglich, Datensätze trotz kleiner Codierungsunterschiede rasch zu kombinieren.

Ziel für den Hackathon

Entwicklung von Ideen, Methoden und Prototypen zur Dokumentation von Gemeinsamkeiten und Unterschieden zwischen zwei Codelistenwerten. Automatisierte Generierung von Mapping-Tabellen.

Einschränkungen

Die Arbeiten an I14Y werden in diesem Jahr abgeschlossen. Anschliessend steht der Code der Plattform als Open-Source-Software zur Verfügung. Einfache Erweiterungen insbesondere im Bereich der Mapping-Tabellen können noch integriert werden. Komplexere Erweiterungen werden allenfalls erst im Nachfolgeprojekt metadata.swiss umgesetzt.

Nachhaltigkeit

Das Entwicklungsteam prüft die Ideen, Ansätze und Prototypen und implementiert allenfalls Teile davon in I14Y.

References

https://www.youtube.com/watch?v=lk9gYF4G758

https://youtu.be/WnAViUW93C8

In dieser Challenge nehmt ihr Open Governement Data der Schweizerischen Bundeskanzlei – von Abstimmungen über Initiativen bis hin zu politischen Akteuren – und verwandelt sie in klare Insights, starke Visualisierungen und echte Aha-Momente.

Findet Fehler, verbindet Datensätze, erzählt neue Geschichten – und macht komplexe politische Prozesse für alle zugänglich.

Eure Mission: Aus Daten Verständnis schaffen. Aus Komplexität Klarheit. Aus Open Data echten Impact.

Verfügbare Daten

• Abstimmungsvorlagen & Resultate:
• Initiativen, Referenden und Petitionen:
• Bundesrat
• Ausserparlamentarischen Kommissionen
• Terminologie-Daten (Termdat)

Weitere Informationen zu den Verfügbaren Daten können auf https://github.com/swiss/fch-opendata gefunden werden.

Erwarteter Nutzen

Ihr helft die direkte Demokratie verständlicher, transparenter und zugänglicher zu machen.

Ziel für den Hackathon

Die neusten Open Governement Datasets der Bundeskanzlei bekannt machen, und erste innovative Verwendungen und Veredelungen andenken und umsetzen.

Lösungsansätze

Siehe https://www.admin.ch/de/bundesrat-geschichte oder auch https://www.admin.ch/de/ausserparlamentarische-kommissionen-gremienverzeichnishttps://www.admin.ch/de/ausserparlamentarische-kommissionen-gremienverzeichnis als Beispiele für ein einfachen Endbenutzer Zugang.

Einschränkungen

Die Daten sollen möglichst so veredelt werden, dass keine bewusst falsche Interpretationen erwirkt werden.

Nachhaltigkeit

Gefundene (Daten-)probleme werden behoben, und Fragen zu den Daten werden beantwortet.

Umgesetzte Ideen werden den jeweiligen Fachbereichen als Inspiration zur Umsetzung auf den offiziellen Websites präsentiert.

Presentation

https://www.swisstransfer.com/d/5e6d5f67-b3a8-4147-b16e-d7a34adaad04

Challenge Story

https://youtu.be/oskh-X3Ncmw

Check out additional videos below for more details.

Challenge Language

This challenge was initially submitted in German. However, all documentation will be provided in English, in order to reach an international target audience.

Check out the briefing section below for a quick overview of the challenge objectives.

Challenge Submission Text

Bedarf/Problem und Zielgruppe

Diese Challenge ist Teil einer Gesamt-Initiative am GovTech Hackathon 2026 - https://drive.google.com/drive/u/0/folders/1YrEa5u3LyTDjOOz--Fnd38N4E9kpILdD

Weitere Informationen zu dieser Challenge sind zu finden im Ordner - https://drive.google.com/drive/u/0/folders/1YrEa5u3LyTDjOOz--Fnd38N4E9kpILdD

Diese Challenge fokussiert auf das Zusammenspiel von HL7 FHIR und openEHR auf einer offenen Datenplattform mit Open-Source-Komponenten. Ziel ist es, anhand eines konkret verständlichen Anwendungsfalls zu zeigen, wie sich diese beiden internationalen Standards im Gesundheitswesen sinnvoll ergänzen: FHIR für Interoperabilität und Datenaustausch, openEHR für persistente und longitudinale klinische Datenspeicherung.

Als exemplarischer Anwendungsfall wird das digitale Impfdossier gewählt. Impfungen eignen sich besonders gut, weil sich daran die Notwendigkeit einer langfristigen, lebenslangen und konsistenten Speicherung medizinischer Daten besonders gut zeigen lässt. Der Showcase soll damit einen Proof of Concept für FHIR-basierten Datenaustausch und openEHR-basierte Persistenz auf einer offenen Plattform liefern.

Im Gesundheitswesen werden Daten heute häufig entweder standardisiert ausgetauscht oder intern langfristig und strukturiert gespeichert, jedoch nur selten in einer Weise, die beide Anforderungen überzeugend verbindet. Es fehlt an praxisnahen Beispielen, die zeigen, wie internationale Standards wie FHIR für den Datenaustausch und openEHR für die klinische Langzeitpersistenz auf einer offenen Plattform sinnvoll zusammenspielen können.

Gerade bei medizinischen Informationen, die über viele Jahre oder ein ganzes Leben relevant bleiben, braucht es eine belastbare, strukturierte und semantisch robuste Langzeitspeicherung. Dies ist beim Impfdossier besonders offensichtlich: Impfungen müssen über lange Zeiträume nachvollziehbar dokumentiert, wiederverwendbar gespeichert und systemübergreifend ausgetauscht werden können.

Betroffen sind insbesondere Gesundheitsfachpersonen, die Impfungen dokumentieren, einsehen und über Systemgrenzen hinweg nutzen, Hersteller von Primärsystemen und Gesundheitsanwendungen, die interoperable Lösungen umsetzen, sowie Organisationen, die offene Gesundheitsplattformen oder Interoperabilitätslösungen aufbauen. Mittel- bis langfristig betrifft das Thema auch Bürgerinnen und Bürger, die von einem verlässlichen digitalen Impfdossier mit nachvollziehbaren und langfristig verfügbaren Impfdaten profitieren.

(Nicht) verfügbare Daten

Verfügbar sind die offizielle Schweizer CH VACD FHIR-Spezifikation, bereits vorhandene openEHR-Modellierungen von Impfdaten, Architekturentwürfe für eine offene Plattform, konzeptionelle Überlegungen zu einem Interoperabilitätslayer bzw. zu Interoperabilitätsservices, öffentlich verfügbare Standards, Profile und Terminologien sowie fachliche und technische Expertise in den Bereichen openEHR, FHIR, Modellierung und Architektur.

Darüber hinaus stehen Open-Source-Komponenten als technische Grundlage für den Proof of Concept zur Verfügung.

Nicht vorgesehen sind produktive Personendaten oder produktive klinische Daten. Für den Hackathon werden stattdessen synthetische und beispielhafte Daten bereitgestellt.

Erwarteter Nutzen

Es entsteht ein konkreter und nachvollziehbarer Nachweis, dass FHIR-basierter Datenaustausch und openEHR-basierte klinische Langzeitpersistenz auf einer offenen Datenplattform mit Open-Source-Komponenten in der Praxis sinnvoll zusammen funktionieren.

Der Mehrwert besteht in einem sichtbaren Proof of Concept für das Zusammenspiel zweier internationaler Standards, in einer belastbaren Architekturidee mit Interoperabilitätslayer sowie in einer lebenslangen, konsistenten Datengrundlage für Impfdaten. Gleichzeitig liefert der Showcase eine Blaupause für weitere klinische Inhalte, schafft eine Grundlage für ein digitales Impfdossier und ebnet den Weg für einen Ausbau in Richtung International Patient Summary (IPS).

Mit dem digitalen Impfdossier hat jeder Bürger hat seinen gesamten Impfverlauf jederzeit strukturiert und digital verfügbar und kann diesen bei Bedarf bei Gesundheitsfachpersonen und Behörden in der Schweiz und im Ausland vorweisen. Darauf aufbauend lassen sich Folgeimpfungen sowie Impf-Empfehlungen für Auslandsreisen ableiten. Darüber hinaus kann eine verantwortliche Person Impfungen für die Familie koordinieren (z.B. Eltern für ihre Kinder).

Ziel für den Hackathon

Erstellung einer ersten Version eines Showcases für eine App, basierend auf den internationalen Standards openEHR für die semantische klinische Persistierung sowie FHIR für den interoperablen Austausch. Der Showcase soll anschliessend als Initiative von openEHR Schweiz (https://openehr.atlassian.net/wiki/spaces/oech/pages/3468427363/2026+Showcase+Impf-Modul) weiterentwickelt werden, um Investoren für eine produktive Einführung zu erreichen.

Lösungsansätze

Grundsätzlich gibt es für diese Challenge verschiedene Lösungsansätze auf Ebene von Standards, Plattform und Architektur. Bereits erarbeitet wurden Architekturüberlegungen zum Zusammenspiel von Austausch, Persistenz und Interoperabilitätslayer. Darüber hinaus wurden bewährte technische Bausteine für eine offene Plattform identifiziert, die im Proof of Concept eingesetzt werden können, insbesondere Komponenten für FHIR, openEHR, Interoperabilitätsservices sowie für die Datenkonvertierung bzw. das Mapping zwischen beiden Standards.

Im Bereich Impfdossier gab es in der Schweiz bereits Vorläufer und Teillösungen: meineimpfungen.ch bot gute Funktionalitäten, wurde jedoch wegen Sicherheitsmängeln ausser Betrieb genommen. eHealth Suisse hat einen rein FHIR-basierten elektronischen Impfausweis entwickeln lassen, der in einigen Gemeinschaften im elektronischen Patientendossier (EPD) verfügbar ist. Zudem wurde bereits ein Prototyp einer Gesundheits-App (https://youtu.be/T5bYmy_oXMo) für Bürgerinnen und Bürger erstellt, die produktive Einführung wurde jedoch bis zu einer geeigneten EPD-Anbindung zurückgestellt.

Einschränkungen

Die Challenge ist als Proof of Concept konzipiert und nicht als vollständige Produktivlösung. Der Fokus liegt bewusst auf dem Zusammenspiel von FHIR und openEHR und nicht auf der vollständigen Abdeckung aller fachlichen Prozesse rund um das Impfen.

Wichtig für die Challenge sind die Orientierung an der Schweizer CH VACD FHIR-Spezifikation für den Austausch und an openEHR für die persistente klinische Speicherung, die Verwendung von synthetischen Daten, der Einsatz von offenen Standards und Open Source Komponenten sowie eine Architektur, die als offene Plattform und als Grundlage für eine spätere Weiterentwicklung konzipiert ist.

Ebenfalls wichtig ist, dass der entwickelte Programmcode zusammen mit der notwendigen Dokumentation vollständig und nachvollziehbar über GitHub (wird vorbereitet) bereitgestellt wird.

Nachhaltigkeit

Der Hackathon Challenge ist eine gemeinsame Initiative von openEHR Schweiz und HL7 Schweiz. Es ist bereits geplant, den Showcase bis 3Q2026 weiterzuentwickeln, um diesen Investoren vorstellen zu können. Zudem sollen die Erfahrungen mit dem Showcase als «Blaupause» für die Umsetzung weiterer Elemente im «International Patient Summary» (IPS, https://international-patient-summary.net) dienen, z.B. Allergien, Medikation.

*** English text ***

Showcase Digital Vaccination Record - Interoperability Through Standards

Interoperability in Healthcare - FHIR for Data Exchange, openEHR for Data Persistence; Vaccination Showcase

Need/Problem and Target Audience

This challenge is part of an overall initiative at the GovTech Hackathon 2026 - https://drive.google.com/drive/u/0/folders/1YrEa5u3LyTDjOOz--Fnd38N4E9kpILdD

More information about this challenge can be found in the folder - https://drive.google.com/drive/u/0/folders/1YrEa5u3LyTDjOOz--Fnd38N4E9kpILdD

This challenge focuses on the interaction between HL7 FHIR and openEHR on an open data platform with open-source components. The objective is to demonstrate - using a specific and widely understandable use case - how these two international healthcare standards meaningfully complement each other: FHIR for interoperability and data exchange, openEHR for persistent and longitudinal clinical data storage.

The digital vaccination record is chosen as an exemplary use case. Vaccinations are particularly suitable since they demonstrate the necessity of long-term, lifelong, and consistent storage of medical data. The showcase is intended to provide a proof of concept for FHIR-based data exchange and openEHR-based persistence on an open platform. In today’s healthcare environments, data is often either standardized for exchange or internally stored in a long-term and structured manner, but rarely in a way that convincingly combines both requirements. There is a lack of practical examples that show how international standards like FHIR for data exchange and openEHR for long-term clinical persistence can work together meaningfully on an open platform.

Particularly for medical information that remains relevant for many years or an entire lifetime, reliable, structured, and semantically robust long-term storage is required. This is especially evident with vaccination records: vaccinations must be documented comprehensibly over long periods, stored reusably, and exchanged across systems. Affected stakeholders include healthcare professionals who document, view, and use vaccinations across system boundaries, providers of primary systems and healthcare applications implementing interoperable solutions, and organizations building open health platforms or interoperability solutions. In the medium to long term, the topic also affects citizens who benefit from a reliable digital vaccination record with traceable and long-term available vaccination data.

Available (and unavailable) Data

Examples of available data are the official Swiss CH VACD FHIR specification, existing openEHR models of vaccination data, architectural designs for an open platform, conceptual considerations for an interoperability layer or interoperability services, publicly available standards, profiles and terminologies, as well as professional and technical expertise in openEHR, FHIR, modeling, and architecture.

In addition, open-source components are available as a technical foundation for the proof of concept.

Production personal data or production clinical data are not intended. Instead, synthetic and exemplary data will be provided for the hackathon.

Expected Benefit

A specific and comprehensive proof shall emerge, demonstrating that FHIR-based data exchange and openEHR-based long-term clinical persistence work together meaningfully in practice on an open data platform with open-source components.

The added value consists of a tangible proof of concept for the interaction of two international standards, a reliable architecture concept with an interoperability layer, and a lifelong, consistent data foundation for vaccination data. At the same time, the showcase provides a blueprint for additional clinical content, creates a foundation for a digital vaccination record, and paves the way for expansion toward the International Patient Summary (IPS).

With the digital vaccination record, every citizen has their entire vaccination history available digitally and in a structured form at all times and can present it to healthcare professionals and authorities in Switzerland and abroad as needed. Based on this, follow-up vaccinations and vaccination recommendations for foreign travel can be derived. Furthermore, a responsible person can coordinate vaccinations for the family (e.g., parents for their children).

Objective for the Hackathon

Creation of a first version of an end-to-end showcase for an app based on the international standards openEHR for semantic clinical persistence and FHIR for interoperable exchange. The showcase shall subsequently be further developed as an initiative of openEHR Switzerland (https://openehr.atlassian.net/wiki/spaces/oech/pages/3468427363/2026+Showcase+Impf-Modul) to reach investors for production introduction.

Solution Approaches

Fundamentally, there are various solution approaches for this challenge at the level of standards, platform, and architecture. Architectural considerations on the interaction of exchange, persistence, and interoperability layer have already been developed. In addition, proven technical building blocks for an open platform have been identified that can be used in the proof of concept, particularly components for FHIR, openEHR, interoperability services, and for data conversion or mapping between both standards.

In the vaccination record area, there were already predecessors and partial solutions in Switzerland: meineimpfungen.ch offered good functionality but was taken out of service due to security deficiencies. eHealth Suisse had a purely FHIR-based electronic vaccination certificate developed, which is available in some communities in the electronic patient record (EPD). Additionally, a prototype of a health app (https://youtu.be/T5bYmy_oXMo) for citizens was already created, but the production introduction was postponed until an EPD API for such apps becomes available.

Limitations

The challenge is designed as a proof of concept and not as a complete production solution. The focus is deliberately on the interaction between FHIR and openEHR and not on the complete coverage of all professional processes around vaccination.

Important for the challenge: orientation towards the Swiss CH VACD FHIR specification for exchange and to openEHR for persistent clinical storage, use of synthetic data, deployment of open standards and open-source components, and an architecture designed as an open platform and as a foundation for later development.

It is also important that the developed program code, together with the necessary documentation, is provided completely and comprehensibly via GitHub (being prepared).

Sustainability

The hackathon challenge is a joint initiative of openEHR Switzerland and HL7 Switzerland. It is already planned to further develop the showcase until Q3 2026 in order to present it to investors. Additionally, the experiences with the showcase shall serve as a «blueprint» for implementing further elements of the «International Patient Summary» (IPS, https://international-patient-summary.net), e.g., allergies, medication.

Briefing

Pitch Deck

Challenge Objective

1. The main objective of this challenge is to demonstrate the end-to-end implementation of FHIR and openEHR international standards in a showcase, based on the vaccination use case
2. The secondary objective is to demonstrate user oriented «apps» for data producers and consumers - «vibe coding» can be used for rapid prototyping (see Claude prototype in resources below)

A key objective of the showcase is to serve as blueprint for future clinical use cases.

Envisaged Architecture

A framework of the openEHR/FHIR stack is available in the challenge GitHub repository to serve as development harness.

Vibe coding (i.e. AI supported coding) is envisaged for the hackathon prototype.

Ambition

The ambition of our team is to establish a «Swiss Health App» which is as popular as the Swiss Federal Railway App, based n the following steps:

1. Complete the Immunization Showcase - 2026

• Demonstrate openEHR/FHIR interplay
• Implement end-to-end prototype
• Establish blue print for future clinical use cases

2. Extend to International Patient Summary (IPS) - 2027

• Extend prototype with additional use cases allergies, medication, ...
• Integrate official EHR (EGD)

3. Extend to «Swiss Health App» - 2029

• Extend prototpe with wearable information
• Optimize user experience towards «health information at the fingertips»

Resources

• Challenge preparation area, contains collaboration area
• Challenge collaboration area - working area for challenge team, more documents
• Challenge GitHub repository
• Challenge Teams chat channel
• Challenge project on Renku platform
• openEHR International
• openEHR Switzerland
• HL7 FHIR
• HL7 Switzerland
• International Patient Summary (IPS)
• DigiSanté
• ...

More Resources

• «Digital Health with the new E-ID trust infrastructure», award winning GovTech Hackathon 2024 challenge, see documentation, short video, resources
• IPS Health app prototype, short video
• IPS prototype with Claude in 30 minutes, short video
• Interview with Katrin Crameri, Co-Lead DigiSanté; bfs info, Die Schweiz im Hintertreffen: Digitalisierung im Gesundheitswesen
• PhD Thesis Ralph Baumgartner, Digitale Geschäftsmodelle im Schweizer Gesundheitswesen: theoretische und empirische Analyse ihrer Wirkung auf integrierte Versorgung
• ...

Please note also the associated health challenge «30 Seconds to EGD» of this GovTech Hackathon 2026.

Project Documentation

Project Team

• Peter Janes, challenge owner, openEHR Switzerland Board of Directors, DIDAS Health working group lead, founder and CEO of Abdagon AG
• Jean-Pierre Messerli, openEHR modeling expert, openEHR Switzerland data modeling group member, Senior Consultant at JPM Consultung GmbH
• Roeland Luykx, FHIR expert, Chair HL7 Switzerland, founder and CEO of RALY GmbH
• Oliver Deak, technical expert, founder and CEO of Valico AG
• Gasper Andrejc, openEHR/FHIR expert, founder of openFHIR
• Paul Schell
• Andreas Schweizer
• Simon Koller
• Simon Schweingruber
• Fabian Santi
• Fabien Tschanz

Supporters

• Hendrik Heiser, CISTEC AG, Clinical Data Modeler, openEHR.ch Data Modeling Group chair
• Fabian Bürki, Federal Office of Public Health, FOPH (BAG), Standards, openEHR.ch Data Modeling Group member
• Paul Spicher, Federal Office of Public Health, FOPH (BAG), Scientific Advisor Digital Health

High Level Program

Thu, 28.05.2026 - Day 1

• Team Introduction
• Challenge Briefing
  • Organization - Peter Janes
  • openEHR - Jean-Pierre Messerli
  • FHIR - Roeland Luykx
  • Development Framework - Oliver Deak
• Getting into framework
• 16:30 challenge technical Q&A - Teams Link
• Preparing test data
• Documentation (ongoing)

Fri, 29.05.2026 - Day 2

• Extending framework stack
• 09:00 briefing call, review achieved results, plan remaining activities (including final pitch) - Teams Link, Recording
• openEHR/FHIR mappings
• Front end development
• Documentation (ongoing)
• Final pitch preparation

28.05.2026 - Day 1

Initial Pitch

https://youtu.be/D0p-zhMCsO0

Finding room, preparing for work

Challenge briefing

As it turns out, openEHR, FHIR and the development are all bearing considerable complexity.

After the intensive briefing, the team is quite overwhelmed - despite considerable preparations of our experts Jean-Pierre Messerli, Roeland Luykx and Oliver Deak in mappings, pre-built services and a development environment.

The assignment for lunch break is to think about the preferred tasks, matching the respective skills of the team members.

After lunch - tasks assignments

Coaching , starting work

First part after assigning the tasks is «to get the hands dirty» with real code, with quite some coaching by our experts.

Discussing solutions

«Getting real» inevitaby raises questions about the most appropriate solution. That's the difference to just writing concepts.

https://youtu.be/tMYM8Z-pU6s

29.05.2026 - Day 2

Briefing Call

https://youtu.be/cAvtQVr4Vsg

Briefing chapters:

• 00:00:00 Intro
• 00:00:10 Welcome, Challenge Update - P. Janes
• 00:07:05 openEHR Perspektive - J.P. Messerli
• 00:10:45 FHIR Perspektive - R. Luykx
• 00:14:32 Technical Perspective - O. Deak
• 00:16:36 Wrap up - P. Janes
• 00:17:37 Adressing Questions
• 00:26:33 FOPH Perspective - P. Spicher
• 00:28:25 Next Steps, Ambition
• 00:34:40 International Interoperability
• 00:39:15 Outro
• 00:39:46 End

Results

Live Demonstration Flow

1. Vaccination at doctor's office
2. Vaccination documentation in doctor's system (PIS)
3. Persist in structure form in «Swiss Vaccination Data Platform» through architecture stack
4. Retrieve from «Swiss Vaccination Data Platform» through architecture stack
5. Display vaccinations in citizen's app at any time

See final pitch recording for live demonstration.

Architecture Stack

Relevant elements:

• Based on international standards
  • Data Exchange - HL7 FHIR
  • Data Persistence - openEHR
• Prerequisite for interoperability
• All components are open source

Takeaways

Key Takeaways

• It's complex - the learning curve to get into the architecture stack layers is steep
• It's running - within the two days of the hackathon, the full end-to-end prototype was implemented (based on substantial preparation work)
• It's clean - the prototype is based on the full architecture stack, which can now be used for other clinical use cases

Takeaways Breakdown

• Complexity – working with structured health data requires considerable domain knowledge and abstract thinking
• Preparation – both design and technical preparations were crucial to achieve the challenge objectives and results
• Team – highly motivated, software developers had very good technickal backgrounds, however getting used to digital health frameworks takes time and has a steep learning curve
• Coding – developing is increasingly library based and open source, Artificial Intelligence provides substantial support
• Blueprint – persistence design and modeling decisions are absolutely curcial, technology components are available, architectural structuring could be refined
• Awareness – conversations with FOPH, DigiSanté, and FSO took placebefore and during hackathon to inform about the initiative
• Pioneeering Work - as openEHR is rather new, not many comparable initiatives exist with the chosen end-to-end approach

Final Pitch

Final Pitch Presentation

https://youtu.be/WthPrgdpJX0

Bedarf/Problem und Zielgruppe

Das Projekt OK Klima macht Klimapolitik auf kantonaler und kommunaler Ebene sichtbar. Unsere Webseite https://ok-klima.ch/ stellt der Zivilgesellschaft Informationen zur kommunalen Klimapolitik zur Verfügung. Uns fehlen aber detaillierte Informationen über kommunale Klima-Subventionen.

(Nicht) verfügbare Daten

Wir haben bereits die Webseite https://www.energiefranken.ch/de analysiert und basierend darauf eine erste Liste über kommunale Klima-Subventionen erstellt. Mit diesen Daten können wir die Gemeinden mit Subventionen eruieren und in unsere Evaluationen aufnehmen. Wir wissen aber nicht, wie gut diese Subventionen sind, und ob die Gemeinden ohne Informationen effektiv keine Subventionen haben. Für diese zusätzlichen Informationen müssen direkt die Webseiten der Gemeinden konsultiert werden.

Erwarteter Nutzen

Die Zivilgesellschaft könnte sich in Gemeinden mit wenig klimarelevanten Subventionen gezielter politisch für solche einsetzen.

Ziel für den Hackathon

Bessere Information über kommunale Klima-Subventionen geben zu können. Und so Klimapolitik transparenter machen.

Lösungsansätze

Zur Zeit arbeiten wir nur mit Informationen von energiefranken.ch. Es ist wahrscheinlich möglich, von den Gemeinde-Webseiten mehr Informationen mittels Web Scraping und Textanalyse zu bekommen. Für Photovoltaik-Subventionen suchen wir beispielsweise den Betrag pro kWp. Teilweise wissen wir schon, wo diese Informationen zu finden sind (von energiefranken.ch), manchmal kennen wir nur die Webseite der Gemeinde (z.B. von Wikipedia).

Einschränkungen

Wir benötigen für unsere Auswertungen präzise Informationen. Wenn Zweifel an der Qualität der Informationen bestehen, ziehen wir es vor, diese nicht zu veröffentlichen. Allenfalls ist eine manuelle Überprüfung der automatisch erfassten Daten notwendig. Nach Bedarf müssten wir die Analyse auf Gemeinden mit mehr als 15.000 Einwohner:innen beschränken.

Nachhaltigkeit

Sollten wir qualitativ hochwertige Daten zu den kommunalen Subventionen erhalten, werden diese im Juni auf der Website von OK Klima veröffentlicht. Teilnehmende können sich bei OK Klima engagieren und gegebenenfalls als Freiwillige für weitere Datensammlungen mithelfen.

Pitch-Deck

link: (https://s3.govtech.digisus-lab.ch/govtech/uploads/250/VT375/P3KI9FVX.pdf)

Video

link: https://drive.google.com/file/d/15fo8R78h31u_Pvb-yUoc2ZotuPvt57Zk/view?usp=sharing

Bedarf / Problem und Zielgruppe

Strategische Entscheide in Verwaltung, Sicherheit und Politik erfordern eine frühzeitige Erkennung relevanter Entwicklungen. Heute sind Informationen zu Technologie, Wirtschaft, Demografie, Energie, Forschung oder Geopolitik auf zahlreiche Datenquellen verteilt. Strategic Radar x+12 schafft ein integriertes Lagebild und unterstützt Fachpersonen in der strategischen Planung, Beschaffung, Governance sowie Führungs- und Stabsorganisationen bei einer datenbasierten Entscheidungsfindung.

Verfügbare Daten

Strategic Radar x+12 nutzt ausschliesslich öffentlich verfügbare Datenquellen und APIs. Dazu gehören Open Government Data, Patentdaten, Forschungsdaten, Wirtschafts- und Finanzindikatoren, demografische Statistiken, Geodaten sowie weitere nationale und internationale Datensätze. Die Daten werden automatisiert integriert, harmonisiert und für Analysen nutzbar gemacht.

Erwarteter Nutzen

Die Lösung macht Trends, Risiken, Abhängigkeiten und schwache Signale frühzeitig sichtbar. Sie unterstützt die strategische Vorausschau, verbessert die Transparenz über Entwicklungen und reduziert den manuellen Analyseaufwand. Entscheidungsträger erhalten eine fundierte Grundlage für Szenarien, Investitionen, Beschaffungsvorhaben und langfristige Fähigkeitsplanung.

Ziel des Hackathons

Ziel ist die Entwicklung eines MVP von Strategic Radar x+12. Dieser integriert mindestens vier öffentliche Datenquellen in ein gemeinsames Datenmodell und visualisiert die Ergebnisse in einem interaktiven Dashboard. Ergänzend soll ein KI-gestützter Assistent erste Analysen, Trendabfragen und Szenarioauswertungen ermöglichen.

Lösungsansatz

Strategic Radar x+12 basiert auf einer modularen Daten- und Analyseplattform. Öffentliche Datenquellen werden automatisiert über ETL-/ELT-Prozesse integriert und in einem gemeinsamen Schema gespeichert. Darauf aufbauend ermöglichen Analyse- und Visualisierungskomponenten die Auswertung entlang des PEMESII-PTT-Modells. KI-gestützte Funktionen unterstützen bei der Erkennung von Zusammenhängen, der Identifikation von Risiken sowie der Erstellung von Szenarien und Prospective-Planning-Analysen.

Einschränkungen

Für den MVP werden ausschliesslich öffentlich zugängliche Daten verwendet. Die Nachvollziehbarkeit der Datenherkunft, die Dokumentation der Datenverarbeitung sowie die Reproduzierbarkeit der Ergebnisse haben hohe Priorität. Im Fokus steht ein schlanker und funktionierender Prototyp mit klar erkennbarem Nutzen.

Nachhaltigkeit

Strategic Radar x+12 ist als Grundlage für eine weiterführende Plattform konzipiert. Die Ergebnisse des Hackathons sollen zeigen, wie öffentliche Daten für strategische Frühwarnung und Prospective Planning genutzt werden können. Bei erfolgreichem Nachweis der Machbarkeit besteht Potenzial für Pilotierungen im Umfeld von Verwaltung, Sicherheit, Krisenvorsorge, Beschaffung und strategischer Governance.

Bedarf/Problem und Zielgruppe

Les services d'urgences hospitalières en Suisse font face à des pics d'affluence imprévisibles qui saturent les capacités d'accueil, allongent les temps d'attente et dégradent la qualité des soins. Ce problème affecte directement les patients, le personnel soignant, et les coordinateurs du SMUR/144. Actuellement, aucun outil national ne permet d'anticiper ces pics en croisant des données multi-sources (épidémiologiques, météorologiques, de mobilité). Les groupes cibles sont : les directions hospitalières, les cantons responsables de la planification sanitaire, et les opérateurs du 144.

(Nicht) verfügbare Daten

Plusieurs sources de données ouvertes suisses sont directement exploitables : statistiques hospitalières OFSP (données SpiGes), données épidémiologiques et de mortalité OFS, prévisions météorologiques MétéoSuisse (API ouverte), données de mobilité et de transport opentransportdata.swiss, et données démographiques cantonales. Ces jeux de données sont publics, documentés et accessibles via API ou fichiers téléchargeables.

Erwarteter Nutzen

Une anticipation fiable des pics d'affluence permettrait : une meilleure allocation des ressources humaines et matérielles dans les hôpitaux, une réduction mesurable des temps d'attente aux urgences, un dispatch ambulancier plus efficace, et une aide à la décision pour les cantons dans leur planification sanitaire. À terme, cela contribue directement aux objectifs du programme DigiSanté et à la résilience du système de santé suisse.

Ziel für den Hackathon

Développer un prototype fonctionnel (MVP) démontrant la faisabilité d'une prédiction d'affluence à 24–72h pour un ou plusieurs établissements hospitaliers suisses, en s'appuyant exclusivement sur des données ouvertes.

Lösungsansätze

Une analyse exploratoire des données disponibles a été réalisée en amont. Des approches de modélisation prédictive basées sur des séries temporelles ont été identifiées comme pistes pertinentes. Aucun prototype n'a encore été développé — c'est précisément l'objectif du Hackathon.

Einschränkungen

Les données utilisées devront être exclusivement issues de sources ouvertes et publiques, sans données patients ni informations personnelles identifiables (conformité RGPD/LPD suisse). Les résultats du Hackathon devront être publiés sous licence open source (ex. MIT) pour permettre leur réutilisation par les cantons et établissements hospitaliers intéressés.

Nachhaltigkeit

Le prototype développé sera publié en open source sur GitHub. Je m'engage personnellement à continuer le développement post-hackathon, avec un objectif de version pilote testable dans un contexte cantonal d'ici fin 2026. Je suis disponible pour collaborer avec des partenaires institutionnels (cantons, hôpitaux, OFSP) souhaitant poursuivre le projet. Les participants intéressés pourront rejoindre le projet en tant que contributeurs.

Results

• Repo: https://gitlab.com/geometalab/ogd-osm-bridge
• Web UI: https://osmpid.infs.ai/

Bedarf/Problem und Zielgruppe

Die Geodaten von OpenStreetMap (OSM) könnten die Open Government Data (OGD) in vielerlei Hinsicht ergänzen (vgl. dazu http://dx.doi.org/10.48350/159438#). Die OSM-Community hatte jedoch bisher keinen Anlass, selbst einen persistenten Identifikator anzubieten. Nun schlagen wir eine „OSM Persistent IDs Specification” (OSMPID) vor, die neu (als Draft) entwickelt wurde. Während staatliche Register wie das GWR dauerhafte IDs nutzen, sind OSM-IDs volatil und ändern sich häufig. Es fehlt eine stabile Verbindung zwischen amtlichen Geodaten und OpenStreetMap.

Zielgruppe sind Bundes- und Kantonsverwaltungen, die OSM-Zusatzdaten mit permanenten IDs für ihre Aufgaben nutzen möchten. Auch der Tourismus, Wikidata und Weitere können davon profitieren.

(Nicht) verfügbare Daten

Das Gebäude- und Wohnungsregisters (GWR) ist verfügbar. Weitere Verwaltungsdaten können auch am Hackathon noch dazu kommen.

Erwarteter Nutzen

Die bessere Verknüpfung von OGD und OSM schafft ein Ökosystem, in dem aufwändige Datenabgleiche zwischen Verwaltung und Community überflüssig werden. Von dem einmaligen Verknüpfen von Informationen profitieren Behörden, der Tourismus und weitere Akteure, da diese trotz Bearbeitungen in OSM stabil bleiben.

Ziel für den Hackathon

Das Ziel ist die Entwicklung eines funktionalen Prototyps, der eine Brücke zwischen den stabilen amtlichen Identifikatoren und einem neuen System stabilisierter OSM-Persistent-IDs schlägt. Dazu gehört ein API, ein Matching, und ggf. eine Webseite (dank AI-Coder Tools und Vibe Coding).

Lösungsansätze

Es gibt die „OSM Persistent IDs Specification” (OSMPID), Python Libraries, etc. und eine Menge Erfahrungen der Teilnehmer vom Challenge-Einreichenden (am Geometa LAb der FH OST), die dabei sein werden.

Einschränkungen

Gesucht sind Teilnehmende mit Know-how in Geoinformatik und Datenmodellierung sowie Erfahrung im Umgang mit OpenStreetMap-Strukturen. Der Tech-Stack setzt auf zukunftsweisende Technologien wie DuckDB für die Datenverarbeitung und GeoParquet für den effizienten Austausch der Verknüpfungstabellen, ergänzt durch Python oder Go für die API-Entwicklung.

Nachhaltigkeit

Alles ist Open Source und Open Data (v.a. Open Data Commons Open Database License, ODbL, v1.0). Repostitory. Webapp als Showcase.

Bedarf/Problem und Zielgruppe

Sie Schweiz produziert jährlich viele Millionen offener Dokumente — parlamentarische Vorstösse, Urteile, Gesetze, Vernehmlassungen, Forschungspublikationen — verteilt auf unzählige Quellen in 4 und mehr Sprachen. Zwei Beispiele:

Lea, Legistik und Justiz Kanton Solothurn, arbeitet an der Umsetzung des Stimmrechts für Menschen unter umfassender Beistandschaft. Genf hat 2020 als erster Kanton die politischen Rechte geöffnet (75% Ja), Appenzell Innerrhoden und Glarus folgten an Landsgemeinden, Zug nahm 2025 knapp an, Waadt lehnte deutlich ab. Das Parlament hat den Bundesrat per Motion beauftragt, eine Verfassungsänderung auszuarbeiten. Der Prozess ist eingeleitet, die eigentliche Vorlage steht aber noch aus. Lea muss wissen: Welche Kantone haben mit welchem Wortlaut legiferiert, welche Modelle wurden gewählt, wo laufen Vorlagen? Heute durchsucht sie dafür Fedlex, Lexfind, Swisslex etc., einzeln - keine Trendansicht, kein Überblick. Marc, Politikwissenschaftler UniBE, untersucht die kantonale Klimagesetzgebung. Seit 2021 hat sich eine dynamische Welle entfaltet: Bern schrieb Klimaschutz in die Verfassung (2021, 64% Ja), Basel-Stadt setzte mit Netto-Null 2037 das ehrgeizigste Ziel (2022), Freiburg verabschiedete das erste kantonale Klimarahmengesetz (2023), Wallis lehnte seines per Referendum ab (2024, 56% Nein). Marc codiert die Adoptionsdaten manuell aus 26 kantonalen Rechtssammlungen - monatelange Arbeit für eine einzige Studie. Ob gerade eine neue Diffusionswelle läuft, sieht er erst zwei Jahre später. Beide brauchen dasselbe: einen einheitlichen, analysierbaren Zugang zu Schweizer Rechts- und Politikdaten mit Trendanalyse. Heute existiert das nicht, obwohl alle Einzeldaten offen verfügbar sind. Betroffen sind: Verwaltungen (Bund, Kantone, Gemeinden), Parlamentsdienste, Forschende, Medien und Zivilgesellschaft.

(Nicht) verfügbare Daten

1. Verfügbar (bereitgestellt durch Challenge Owner) Scigate-Datenraum: Aktuell über 4 Mio. Dokumente aus 200+ Schweizer Quellen, in einem einheitlichen Index durchsuchbar; der Datenraum wächst laufend durch neue Connectoren und Quellen. Die verschiedenen Datenanbieter pflegen jeweils ihre eigene Domäne, Scigate verbindet sie zu einem analysierbaren Ganzen: a. Gerichtsurteile (Bundesgericht, alle 26 Kantonsgerichte, Bundesverwaltungsgericht) b. Bundesgesetzgebung (Fedlex, alle SR-Nummern) c. Parlamentarische Vorstösse aus 78 Parlamenten (OpenParlData.ch als Datenanbieter für die parlamentarische Domäne) d. 72 Open-Access-Journals und Repositorien Die Trending-Topics-Analyse wird erst durch diese Kombination möglich: Ein Thema taucht als Motion auf, wird zum Gesetzesentwurf, führt zu Urteilen. Dieser Lebenszyklus ist heute in keinem Schweizer Tool sichtbar. Weitere Ressourcen: a. REST API mit Volltextsuche (BM25 + kNN), Facetten und Zeitreihen-Aggregationen b. MCP-Server (17 Tools) für KI-Agenten-Integration (Claude, ChatGPT etc.) c. Über 5 Mio. Embedding-Vektoren (1024-dim) für semantische Analyse, mit wachsender Abdeckung d. Fertige Klassifikationsmodelle auf HuggingFace: ParlaCAP (21 Themen, multilingual), EP EuroVoc Classifier (7000 Deskriptoren, 24 Sprachen) e. Starter-Kit mit Beispielcode (BERTopic, Streamlit-Dashboard, Kantons-Heatmap, Diffusionskarte) f. Sample-Export (JSONL) als Offline-Fallback
2. Nicht verfügbar / wünschenswert a. Statistische Daten (BFS, Kantone); der Datenraum ist erweiterbar: neue Domänen können durch weitere Datenanbieter und Community-Connectoren integriert werden b. Medien-/Nachrichtendaten (GDELT, Media Cloud)

Erwarteter Nutzen

Lea könnte mit einer einzigen Abfrage sehen, welche Kantone das Stimmrecht bei Beistandschaft bereits geändert haben, mit welchem Wortlaut und Ergebnis, statt 26 Rechtssammlungen einzeln zu durchsuchen. Marc könnte die Klimagesetzgebungs-Welle in Echtzeit beobachten statt sie zwei Jahre später aus Akten zu rekonstruieren. Darüber hinaus: Kantone könnten voneinander lernen, statt das Rad neu zu erfinden. Forschende könnten messen, wie lange ein Thema vom Paper zum Gesetz braucht. Die Schweiz hätte ein offenes, transparentes Früherkennungsinstrument. Und es wäre gezeigt, dass ein gemeinsamer Datenraum funktioniert: Verschiedene Datenanbieter pflegen jeweils ihre Domäne, die analytische Infrastruktur verbindet sie - Infrastruktur einmal bauen, statt in jeder Organisation von vorne anfangen. Das Modell ist erweiterbar: weitere Domänen (Statistik, Umwelt, Gesundheit) können von ihren jeweiligen Domänenverantwortlichen integriert werden, ohne die bestehende Infrastruktur neu zu bauen.

Ziel für den Hackathon

Ein funktionierender Prototyp, der über den Scigate-Datenraum aufsteigende Themen identifiziert — als Dashboard mit: a. Trending Topics der letzten 6/12/24 Monate (Burst Detection) b. Themen-Diffusion über Kantone/Institutionen (Kantons-Heatmap) c. Optional: Cross-Domain-Signale (Motion → Gesetz → Urteil) Nicht das Ziel: ein Orakel, das die Zukunft vorhersagt. Sondern ein evidenzbasiertes Werkzeug, das zeigt, was in den Daten bereits sichtbar ist, aber heute niemand sieht.

Lösungsansätze

1. International FiscalNote, Quorum, Plural Policy (US, kommerziell) erkennen legislative Trends mit NLP. Polit-X (DE) monitort 12 Mio. politische Dokumente. Lobium (EU Datathon 2022 Gewinner) analysiert EU-Gesetzgebungsarenen. Alle sind proprietär, keines deckt die Schweiz ab. Westlaw/LexisNexis integrieren Hansard + Gesetze + Urteile, aber hinter Paywall.
2. In der Schweiz OpenParlData.ch (78 Parlamente, API) liefert parlamentarische Daten als Datenanbieter, bietet aber keine Trendanalyse. Geplante Klassifikationen ergänzt sich hervorragend mit unserer Challenge. POLITmonitor und politik.ch bieten manuelles Themen-Filtering, kein algorithmisches Trend-Surfacing. RestructFeedback (GovTech 2023) analysierte Vernehmlassungsantworten mit ChatGPT.
3. Bereits ausprobiert in Scigate Zeitreihen-Aggregationen (date_histogram), Zitier-Trend-Berechnung (steigend/fallend), Embedding-basierte Ähnlichkeitssuche, Cross-lingualer Thesaurus (25'000 Konzeptgruppen DE/FR/IT). Was fehlt: die analytische Schicht darüber: BERTopic-Clustering, Burst Detection, Diffusions-Visualisierung. Weltweit zeigt sich: Integration von Parlament + Gesetzgebung + Gerichte in einer Suche ist der Trend (EUR-Lex/CELLAR, UK i.AI Lex+Parlex, Finnland LawSampo). Die Schweiz hat diese Integration noch nicht.

Einschränkungen

a. Alle Daten sind öffentlich zugänglich (Open Access / Public Domain, Art. 5 URG). Kein Datenschutz-Problem. b. Die Volltexte im Index dienen dem Ranking und der Analyse, werden aber nicht direkt exponiert (Architektur-Prinzip: Scigate verlinkt zur Originalquelle). Teams arbeiten mit Titeln, Abstracts, Metadaten und Embedding-Vektoren. c. Ergebnisse müssen unter offener Lizenz veröffentlicht werden (gemäss Hackathon-Regeln). Scigate selbst: EUPL-1.2 (Code), CC0 (Anreicherungen), CC-BY-4.0 (Dokumentation).

Nachhaltigkeit

Der Prototyp wird weitergepflegt und in die Scigate-Plattform integriert (Open Source, EUPL-1.2). Das Modell eines offenen Datenraums mit verschiedenen Domänenverantwortlichen ist bewusst generisch und übertragbar. Der Challenge Owner (UZH) stellt Entwicklungskapazität bereit und betreibt die Infrastruktur (UZH ScienceCloud). Evtl. folgt eine Anschlussbewerbung beim Prototype Fund (opendata.ch), derselbe Weg, den Demokratis, owlly und Baloti erfolgreich gegangen sind. Der Datenraum wächst durch seine Teilnehmenden: Wer eine Datendomäne verantwortet, kann sie über einen Connector einbringen und alle profitieren davon. Teilnehmer:innen des Hackathons können als Contributors am Open-Source-Projekt weiterarbeiten und werden als Co-Autoren genannt.

Zieleinlauf

https://youtu.be/ixMytMh1vqg

Bedarf/Problem und Zielgruppe

Viele Open Government Data Datensätze sind bereits öffentlich verfügbar – meist als CSV oder Excel.

Damit erreichen sie das 3-Star-Level im Open-Data-Modell: maschinenlesbar, aber noch nicht wirklich vernetzbar.

Was fehlt: • semantische Beschreibung der Daten • standardisierte Metadaten • Links zu anderen Datensätzen

Ohne diese Verknüpfungen bleiben OGD-Daten oft isolierte Tabellen, statt Teil eines vernetzten Wissenssystems zu werden.

Das Problem: Die Transformation zu 5-Star Linked Open Data ist heute meist viel Handarbeit.

(Nicht) verfügbare Daten

Es ist alles verfügbar - wir müssen uns nun darum kümmern, alle Teile zusammenzubringen, und 5-Stern Daten zu generieren 👍

Erwarteter Nutzen

Wenn das Problem gelöst wäre, könnten Open‑Government‑Data automatisch vernetzt und von KI-Systemen direkt verstanden und genutzt werden – statt nur als einzelne CSV‑Downloads zu existieren.

Ziel für den Hackathon

Ziel: Während des Hackathons möglichst viele 3★ Open‑Government‑Data‑Datensätze automatisiert zu 5★ Linked Open Data anreichern und für KI‑Systeme nutzbar machen. Dabei die Pipeline testen und vielleicht sogar verbessern 😇

Lösungsansätze

Lösungsansätze • Automatische Generierung von semantischen Metadaten für OGD‑Datensätze • Umwandlung von Tabellen (CSV/Excel) in Linked Open Data (RDF / Knowledge Graph) • Automatisches Linking zu bestehenden OGD‑Datensätzen oder Referenzdaten • Nutzung von KI/LLMs, um Datenschemata zu verstehen und Ontologien vorzuschlagen • Aufbau einer Pipeline, die Datensätze direkt für KI‑Systeme nutzbar macht

Was wir bereits ausprobiert haben • Entwicklung eines KI‑gestützten Tools, das Datensätze analysiert und Metadaten generiert • erste automatische Vorschläge für semantische Strukturen und Links zwischen Datensätzen • Tests mit bestehenden OGD‑Datensätzen (z. B. aus data.bs.ch) • Integration der aufbereiteten Daten in den Melody Bot als Proof‑of‑Concept

Hier das github Repo mit der KI.-basierten Pipeline: https://github.com/opendatabs/ogd-to-lod

Da drauf findet ihr auch das erste Intro Video: https://www.youtube.com/watch?v=AbhaA7YhF3g

Hier das neuste Video, welches den Stand des Projekts Ende letzter Woche zeigt:

Einschränkungen

Nur offene Daten, offene Lizenzen, offene und dokumentierte Lösungen einsetzen, damit die Ergebnisse nach dem Hackathon weiter ausgebaut werden können.

Nachhaltigkeit

Die Ergebnisse werden an Fachtagungen wie den Schweizerischen Statistiktagen publiziert, damit weitere Institutionen von der Lösung profitieren können, und das LOD System Schweiz sich schneller entwickelt.

Bedarf/Problem und Zielgruppe

Trockenheitslagen müssen von Fachstäben (Kanton/Gemeinde) und Fachstellen in kurzer Zeit beurteilt und in verständlicher Sprache kommuniziert werden, aber entsprechende Informationen / Texte zu erstellen ist aufwändig, Daten und Diagramme oft nicht einfach lesbar für Fachfremde («Nicht-Experten). Das führt zu hohem manuellem Aufwand, uneinheitlichen Lagebildern und verzögerten, schwer vergleichbaren Berichten. Betroffen sind Gemeindeführungsstäbe, kantonale Führungsstäbe, Fachstellen (Wasser, Wald, Landwirtschaft, Umwelt), Lagezentren, sowie Kommunikationsstellen der Verwaltung. Sehr spannend wäre es wenn ein Kantonsvertreter direkt vor Ort wäre.

(Nicht) verfügbare Daten

Verfügbar (für Prototyp, soweit öffentlich oder am Hackathon zugänglich):

• Trockenheitsplattform des Bundes www.trockenheit.ch: Aktuelle Trockenheitsindikatoren und Kartenlayer aus dem Trockenheitskontext Bund (Lage, Indikatoren, regionale Einteilung): WMS und API Im speziellen: Numerische Daten der Trockenheitsplattform, BGDI STAC Collection ch.bafu.trockenheitsdaten-numerisch: Maschinenlesbare Indikator-Zeitreihen pro Region, geeignet als primäre Datenquelle für das Briefing.

• Administrative Geodaten für Regionalisierung (Gemeinden, Kantone, Einzugsgebiete, Warnregionen), mindestens als Geometrien und IDs.

  • Warnregionen als SHP files
  • swissBOUNDARIES3D (Gesamtdatensatz)*: Landes-, Kantons-, Bezirks- und Gemeindegrenzen in Vektorform, Aktualisierung jährlich.
  • swissBOUNDARIES3D Gemeindegrenzen*: Kleinste administrative Einheit, Grundlage für Gemeindebriefings.
  • swissBOUNDARIES3D Kantonsgrenzen*: Grenzen der 26 Kantone.
  • swissBOUNDARIES3D Bezirksgrenzen*: Zwischenebene zwischen Kanton und Gemeinde.
  • Warnung pro region: https://api3.geo.admin.ch/rest/services/api/MapServer/ch.bafu.trockenheitswarnkarte/33 "33" ist die region

• Grundlegende Metadaten, Legenden, Methodentexte für konsistente Interpretation der Indikatoren: Handbuch

• Einheitliche, dokumentierte Schnittstellen (API) für den automatisierten Bezug aller relevanten Layer in einem konsistenten Format.WMS und API und Feature API

• Empfohlene Terminologie für Trockenheitsbulletin

• Entwicklung eines Trockenheitsbulletins für Graubünden

• Trockenheitswarnungen und Verhaltensempfehlungen (38 Warnregionen): Definition der Warnregionen, Gefahrenstufen sowie ausformulierte Auswirkungsbeschreibungen pro Stufe (verwendbar als Textbaustein-Vorlage).

• Beispiele

  • Bulletin Trockenheit im Kanton GB_Beispiel_Landwasser_2023
  • Bulletin Trockenheit im Kanton SG 20230710
  • Trockenheitsbulletin_fiktives_20180726_bereinigt
  • Trockenheitsbulletin_fiktives_20180628_bereinigt
  • Point sécheresse du 10 juillet 2024
  • Warnung_bulletins_Kantone
  • Warnung_bulletins_Bund

• Beispiele Kt. Bern

  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/40/9HR8U/D0BCJ6DC.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/A2H50/X4QPUBJG.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/XEZ13/YIDWP6V0.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/4A171/UP3CE3TM.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/3MX0V/9WPCI2PK.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/W6GP0/GDQS5TLH.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/OC0PR/44CACIEN.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/05ESL/FRPW7DUL.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/96YRI/7OSZ5OOZ.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/NMUXD/WBSCNZIC.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/3I62T/KMWDJMLV.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/PYBXE/FDK9X788.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/ZDGRO/3KOL3M6S.pdf
  • [Bulletin Trockenheit im Kanton BE] https://s3.govtech.digisus-lab.ch/govtech/uploads/46/QDO5Q/RJMF3OTD.pdf

Einige weitere Nützliche Daten

• Hydrologische Daten (Abfluss, Pegel, Grundwasser, Temperatur):

  • Hydrodaten.admin.ch, Portal hydrologische Daten und Vorhersagen: Aktuelle und historische Werte zu Abfluss, Wasserstand, Wassertemperatur, Grundwasser sowie Hochwasservorhersagen.
  • Aktuelle hydrologische Daten beziehen (BAFU): Übersicht der Bezugswege (LINDAS, App «Meine Pegel», SMS-Dienst).
  • LINDAS Linked Data Service (Bund): SPARQL-Endpoint für Abfluss, Wasserstand, Wassertemperatur und Hochwassergefahrenstufen, Aktualisierung alle 10 Minuten.
  • Messstationen Wassertemperatur, opendata.swiss: Standorte des BAFU-Temperaturmessnetzes an Fliessgewässern.
  • Messstationen hydrologische Untersuchungsgebiete (HUG): Rund 40 Einzugsgebiete mit langjährigen Reihen für Abfluss, Gebietsniederschlag und Verdunstung.
  • Trockenheit und Grundwasser, NAQUA (BAFU): Beobachtungsindikatoren der Nationalen Grundwasserbeobachtung NAQUA (Quellabflüsse, Grundwasserstände, Grundwassertemperatur).

• Meteorologische und klimatologische Daten (MeteoSchweiz Open Data):

  • Open Data Portal MeteoSchweiz: Einstiegsseite zu OGD-Datenangeboten seit Mai 2025.
  • Open Data Dokumentation MeteoSchweiz: Technische Anleitung zum Datenbezug über die STAC-API.
  • Automatische Wetterstationen SMN, Collection ch.meteoschweiz.ogd-smn: Bodenmessnetz, Standardgranularitäten (10 min, Stunde, Tag, Monat, Jahr).
  • NBCN Klimastationen, Homogene Messwerte: Lange homogenisierte Zeitreihen (Temperatur, Niederschlag), Basis für Klimavergleiche.
  • Klimanormwerte 1961 bis 1990 und 1991 bis 2020: Referenzwerte für Temperatur, Niederschlag und weitere Grössen, Vergleichsbasis für CDI und SPI.
  • Trockenheitsindikatoren MeteoSchweiz, Drought indices: Beschreibung der Indizes (z.B. SPI, Trockenperioden, aufeinanderfolgende Trockentage).
  • Räumliche Klimadaten, bodengestützt (Gitterdaten ogd-surface-derived-grid): Übersicht der OGD-Collections inkl. flächendeckender Niederschlags- und Temperaturraster.

• Satellitengestützte Vegetations- und Trockenheitsindikatoren (swissEO):

  • swissEO VHI, Vegetation Health Index: Tagesaktueller Vegetationszustand (10 m), kombiniert Vegetationskondition (VCI) und Thermalkondition (TCI) zu VHI, Vergleich zu Referenzperiode 1991 bis 2020.

• Verwandte Indikatoren (Korrelate Trockenheit):

  • Waldbrandgefahr.ch (BAFU): Tägliche Waldbrandgefahrenstufen pro Warnregion, Massnahmen der Kantone.
  • Datensatz Waldbrandgefahrenwarnung (ch.bafu.gefahren-waldbrand_warnung): Maschinenlesbare Tageswerte über WMS und REST-API der BGDI.
  • Schneehydrologische Vorhersagen und Wasseräquivalent (MeteoSchweiz): Schneewasseräquivalent absolut und relativ, relevant für Frühjahrs-Trockenheitsbewertung.

*Daten Trockenheit Kanton Bern

• Trosec Karte: https://www.topo.apps.be.ch/pub/map/?lang=de&gpk=TROSEC_GPK
• Aktuelle Abflussdaten (XML): https://www.wada.sites.be.ch/wasserdaten/wasser/liste/index.xml
• Regionale Grundwasserauswertung: https://www.bvd.be.ch/de/start/themen/wasser/hydrologische-daten/regionale-grundwasserauswertung.html
• Aktuelle Wassertemperaturen (XML): https://www.wada.sites.be.ch/spez_pub/drought/index.xml
• Historische Datenreihen Oberflächengewässer: https://www.bvd.be.ch/de/start/themen/wasser/hydrologische-daten/datenbezug/datenkiosk-oberflaechengewaesser.html
• Historische Datenreihen Grundwasser: https://www.bvd.be.ch/de/start/themen/wasser/hydrologische-daten/datenbezug/datenkiosk-grundwasser.html
• Datenlieferung an das BAFU / GIN, die aktuellen Abfluss-Daten der letzten zwei Tage sind unter dem folgenden Link zugänglich: https://www.wada.sites.be.ch/spez_pub/drought/station_list_drought.html

• Schnittstellen und API-Zugriff (Karten):

  • STAC API Dokumentation (DE): Konzepte (Collection, Item, Asset) und Abfragebeispiele.
  • Technische Dokumentation geo.admin.ch: Übersicht aller Webdienste und Release-Notes.
  • map.geo.admin.ch, Viewer mit Permalink-Funktion: Kartenviewer zur visuellen Validierung und für teilbare Permalinks von Layer-Kombinationen.
  • WMS-Dienst geo.admin.ch: Standardisierte Kartendienste (WMS, WMTS) für die direkte Einbindung von Karten in das Briefing-Layout.

Nicht verfügbar oder klärungsbedürftig (kann Teil der Challenge sein):

• Einheitliche, dokumentierte Empfehlungen/ Vorschlag Massnahmen pro Trockenheitsstufe für den automatisierten Vertrieb für verschiedene biographische Regionen: Die Bewältigung ist Aufgabe der Kantone. Wenn ein Kantonsvertreter anwesend ist könnte darauf eingegangen werden.

• Zeitreihen in ausreichend hoher zeitlicher Auflösung für standardisierte Berichte (je nach Produkt und Aktualisierung).

• Operative Verwaltungsdaten zu Massnahmen, Einschränkungen, Entnahmen, Bewässerungsverboten, Schadensmeldungen, falls gewünscht.

Erwarteter Nutzen

• Auf den lokalen Kontext abgestimmte Lageberichte zur Trockenheit entstehen in Minuten statt Stunden und sind zwischen Regionen vergleichbar.

• Gemeindestäbe und Fachstellen erhalten Werkzeug zur Erstellung eines konsistenten, nachvollziehbaren Lagebild/Massnahmenkatalog mit klarer Quellenlage und Indikatorerklärung in verständlicher Sprache (im Gegensatz zu komplexeren Diagrammen und Datengrafiken)

• Auch Medien können diese Informationen einfacher wiederverwenden (als Diagramme und wissenschaftliche Grafiken), womit eine grössere Reichweite der Inhalte erzielt werden kann.

• Kommunikation wird kohärenter, weil Textbausteine (werden bereitgestellt) und Kernaussagen auf denselben Daten basieren.

• Ein Bulletin wird auch verfügbar wenn von Seiten Bund keine Warnung aktiv ist (aktuell wird nur ein Trockenheitsbulletin erstellt, wenn eine Warnung aktiv ist, aus Ressourcengründen)

-> erlaubt somit frühzeitige Erkennung von Verschärfungen wird bewusster vom Zielpublikum aufgenommen, weil Trends besser kommunizierbar werde

Ziel für den Hackathon

• Prototyp “One Click Drought Briefing”: Auswahl einer Region (Gemeinde/Kanton) und eines Zeitfensters, danach automatisierte Generierung eines Briefings (Webansicht plus Export als PDF/HTML).

• Inhaltlicher Mindestumfang: 2 bis 4 Kernindikatoren, 1 bis 2 Karten, 1 Zeitreihe, kurze standardisierte Textzusammenfassung inkl. Unsicherheiten und Quellen. Optional: Übersetzung in FR und IT.

• Technischer Mindestumfang: reproduzierbare Pipeline (Datenbezug, Aggregation, Template), lauffähig mit offenen oder am Hackathon bereitgestellten Daten

Lösungsansätze

Mögliche Ansätze:

• Datenpipeline: Indikatoren beziehen, auf Zielregion aggregieren (Flächenmittel, Perzentile, Anteil “kritisch”), konsistente Zeitfensterlogik.

• Briefing-Template: feste Struktur (Lage, Entwicklung, Einordnung, Datengrundlage), automatische Befüllung durch Kennzahlen und Karten.

• Textgenerierung: regelbasierte Textbausteine, optional zusätzlich ein Assistenzmodus, der Erklärtext aus Metadaten erzeugt, aber keine neuen Fakten erfindet.

• UX: Zwei Modi, “Behördenbriefing” (knapp, standardisiert, für Fachstellen oder Krisenstäbe) und “My Trockenheitsbulletin” (verständlicher, mehr Erklärung, für ein breites Zielpublikum oder Medien).

• Qualität: Plausibilitätschecks (fehlende Daten, Ausreisser, Aktualität), Anzeige von Datenstand und Abdeckung.

Bereits ausprobiert (realistisch formulierbar, ohne Überclaim):

• Konzept und Grobstruktur eines standardisierten Trockenheitsbriefings (Abschnitte, Kennzahlen, Karten).

• Erste Prototyp-Idee zur Regionalaggregation von Indikatoren und zur automatischen Textbausteinlogik.

• Abgleich typischer Nutzerfragen von Fachstellen, um Inhalt und Sprache des Briefings zu definieren

Einschränkungen

• Datenzugang und Lizenzen: Es dürfen nur Daten genutzt werden, die offen sind oder für den Hackathon rechtlich und technisch freigegeben werden; keine personenbezogenen oder vertraulichen Verwaltungsdaten.

• Nachvollziehbarkeit: Ergebnisse müssen reproduzierbar sein (Code, Datenquellen, Parameter, Versionen), damit eine spätere Integration möglich ist.

• Quellenpflicht: Jede Kennzahl, Karte und Textaussage im Briefing muss auf klar benannte Datenquellen und Datenstände verweisen; keine nicht belegten Interpretationen.

• Scope: Fokus auf Prototyp und Kernnutzen (ein Regionalbriefing mit wenigen Indikatoren) statt Vollabdeckung aller Themen.

• Architektur: Möglichst offene Standards, einfache Deploybarkeit, keine harten Abhängigkeiten von proprietären Systemen, die in der Verwaltung nicht betrieben werden können.

• Qualitätsgrenzen: Indikatoren haben Unsicherheiten, Auflösungsgrenzen und Aktualisierungszyklen; diese müssen im Briefing sichtbar gemacht werden (Datenstand, Abdeckung, Limitierungen).

• Sprache und Zielpublikum: Behördenmodus knapp, konsistent, ohne Alarmismus; optionaler Public Modus getrennt, damit Produkte nicht vermischt werden.

Nachhaltigkeit

• Weiterverwendung: Der Prototyp soll als Grundlage für einen Piloten dienen (Minimalprodukt für 1 bis 2 Regionen) und in bestehende Trockenheitskommunikation bzw. Portalumfeld überführt werden, falls technisch und organisatorisch tragfähig.

• Ressourcen intern: Bereitstellung von fachlicher Begleitung und Produktverantwortung (Use Cases, Textbausteine, Qualitätssicherung) sowie technischem Review (Datenpipeline, Aggregationslogik, Reproduzierbarkeit); grob 1 bis 2 Personen mit Teilpensum über mehrere Wochen nach dem Hackathon, Budget primär über Arbeitszeit.

• Einbezug Teilnehmende: Fortführung über öffentliches Repository, Issues, kurze Follow-up Sessions, klare Roadmap für ein Pilotziel; Beitragende können gezielt bei UX, Datenpipeline, Exportlayout und Dokumentation weiterarbeiten, sofern Lizenz und Rahmen passen.

• Das Hackathon-Team wird für seinen Beitrag anerkanntIXQANOS9.pdf

📎 W5UED0UM.pdf

📎 X4QPUBJG.pdf

GitHub

https://swisstopo.github.io/topo-drought-briefing/

README https://github.com/swisstopo/topo-drought-briefing/#drought-briefing-beta

Live on: https://swisstopo.github.io/topo-drought-briefing/

Teamchat

Teamchat

Next steps / backlog

Backlog

https://govtech-hackathon.vercel.app/

Bedarf/Problem und Zielgruppe

Qualitätsvolle Siedlungsentwicklung nach innen ist ein zentrales Gebot der Schweizer Raumplanung. Statt in die Fläche soll primär im bestehenden Siedlungsgebiet gebaut werden. Gleichzeitig fehlen - sowohl für Fachleute als auch für die breite Bevölkerung - allgemein zugängliche Instrumente, um Siedlungsqualität mittels verfügbarer und öffentlich zugänglicher Daten objektiv zu erfassen, darzustellen, zu vergleichen und zu kommunizieren. Bund, Kantone und die Open-Source-Community publizieren grosse Mengen an Geoinformationen. Diese Datenschätze werden in diesem Projekt zusammengeführt und in verständlichen Qualitätsprofilen dargestellt. Das zu entwickelnde Werkzeug analysiert und klassiert die öffentlich zugänglichen Daten und weist diese in Form eines Profils einem definierten Gebiet wie bspw. einem Quartier zu.

(Nicht) verfügbare Daten

Nützliche Ressourcen, die den fachlichen Diskurs zum Thema Siedlungsqualität zusammenfassen:

• ARE: Leitfaden hochwertige Siedlungsentwicklung nach innen (https://www.are.admin.ch/de/siedlungsentwicklung-nach-innen);
• Espace Suisse: Siedlungsqualitätsaspekte (https://www.espacesuisse.ch/sites/default/files/documents/Grafik-10-Qualitätsaspekt-Siedlungsentwicklung_de-A5h_Var2.pdf);
• Erklärung von Davos: "Hohe Baukultur" (https://www.bak.admin.ch/bak/de/home/baukultur/konzept-baukultur/erklaerung-von-davos-und-davos-prozess.html)

Verfügbare Daten: Bundesgeodaten

• Statistik der Bevölkerung & Haushalte (BFS) auf Hektarebene
• Statistik der Unternehmenstruktur STATENT (BFS) auf Hektarebene
• Lärm- & Umweltdaten (BAFU)
• ÖV-Erschliessungsgüte (ARE/SBB)
• SwissBuildings 3D (swisstopo)
• Bauzonen Schweiz (ARE)
• Gebäude- und Wohnungsstatistik (BFS) auf Hektarebene
• Swiss TLM (swisstopo): Grünflächen, Bäume/Einzelbaumdichte
• Erreichbarkeit von Dienstleistungen (BFS) auf Hektarebene
• Bundesinventare wie bspw. ISOS (BAK) oder UNESCO
• weitere (z.B. LINDAS)

Weitere mögliche Datenquellen:

• Kantonale Geodaten (z.B. GIS-Daten BE, ZH): Grünflächen?
• OpenStreetMap (OSM): Grünflächen, Points-of-interest, etc.
• Weitere weiterführende öffentlich zugängliche Datenquellen zu Siedlungsqualität (auch qualitativ, bspw. in Berichten, Beiträgen, Social Media etc.)

*Zugänge zu den Datensätzen werden in einem Renku-Projekt aufbereitet -> https://renkulab.io/p/yves.maurer/siedlungsqualitaet-im-profil

Erwarteter Nutzen

• Übersicht über Ausprägungen von Siedlungsqualität in verschiedenen Gebieten und somit besseres Verständnis von Siedlungsqualität in verschiedenen aggregierten Gebieten (Quartier, Region, Kanton).
• Individuen können ihren Wohnort oder ihr Quartier anhand objektiver Indikatoren profilieren und mit ähnlichen Orten vergleichen, z.B. bei der Wohnungssuche.
• Planungsfachleute erhalten ein niederschwelliges Instrument zur Beurteilung und Kommunikation von Raumqualität.
• Geodaten der öffentlichen Hand werden in konkreten gesellschaftlichen Nutzen übersetzt.

Ziel für den Hackathon

Erarbeitung eines transparenten und funktionierenden Prototyps, der:

1. ausgewählte Geodaten zu einem mehrdimensionalen Raumqualitätsprofil zusammenführt,
2. dieses Profil verständlich visualisiert (z.B. Spinnennetzdiagramm), und
3. einen Vergleich zwischen Orten ermöglicht. Nebenher sollen Fragen zur Methodik (Indikatorenwahl, Gewichtung, Massstäbe) diskutiert und dokumentiert werden.

Die Verfügbarkeit und Harmonisierung von Verwaltungsdaten auf Gemeindeebene ist eine der zentralen Herausforderungen. Die Abklärung und ggf. Bereitstellung fehlender Daten kann Teil der Challenge sein. Unterstützung durch den Hackathon bei der Datenbeschaffung wird begrüsst.

Lösungsansätze

Konzeptuell wurde die Idee eines mehrdimensionalen, vergleichbaren Raumprofils (Spinnennetzdiagramm) mit 7 Qualitätsdimensionen skizziert (Grünflächen, ÖV-Erschliessung, Versorgung, Lärm & Umwelt, Soziale Infrastruktur, Freiraumqualität, Bebauungsdichte). Die vorgeschlagenen Dimensionen von Siedlungsqualität sollen ergänzt, angepasst oder gestrichen werden.

Einschränkungen

• Nur frei verfügbare oder am Hackathon freigegebene Datenquellen verwenden.
• Code und Methodik offen dokumentieren, damit Ergebnisse weiterverwendet werden können.
• Datenschutz beachten: keine personenbezogenen Daten auf Einzelpersonenebene verarbeiten.
• Mindestgrösse eines Analyseperimeters klar definieren und transparent kommunizieren.
• Indikatorenwahl und Gewichtung begründen und dokumentieren.

Nachhaltigkeit

Die Ergebnisse haben das Potential , in einem Projekt weitergeführt zu werden. Konkrete Ressourcen (Arbeitszeit, Budget) sind noch zu klären, die Bereitschaft dazu ist grundsätzlich vorhanden. Allfällige Produkte werden als Open-Source-Projekte der Öffentlichkeit zur freien Nutzung zur Verfügung gestellt.

Bedarf/Problem und Zielgruppe

Die internationale Tierseuchenlage verändert sich laufend und relevante Informationen sind auf viele unterschiedliche Quellen verteilt. Heute müssen Fachpersonen diese Informationen manuell suchen, lesen, bewerten und zusammenführen. Das ist zeitaufwendig, fehleranfällig und erschwert eine schnelle Reaktion auf neue Risiken.

Es besteht daher Bedarf an einem intelligenten System, das:

• internationale Quellen automatisch überwacht
• relevante Meldungen erkennt und strukturiert
• Trends und Risiken frühzeitig sichtbar macht
• Fachpersonen bei Lagebeurteilung und Risikoeinschätzung unterstützt

Das Problem betrifft insbesondere:

• Fachpersonen in Veterinärämtern und Tiergesundheitsdiensten
• Behörden im Bereich Tierseuchen, Landwirtschaft und Gesundheit
• Expertinnen und Experten für Risikobeurteilung
• Landwirtschafts- und Nutztierbetriebe indirekt
• Organisationen im Bereich Tiergesundheit und Monitoring
• Forschungseinrichtungen und Fachstellen für Epidemiologie

(Nicht) verfügbare Daten

Verfügbare Daten und Ressourcen könnten sein:

Öffentliche Meldungen internationaler Organisationen wie World Organisation for Animal Health, World Health Organization oder Food and Agriculture Organization Berichte nationaler Veterinär- und Gesundheitsbehörden in Europa Nachrichtenquellen und Fachportale zu Tiergesundheit und Landwirtschaft Wissenschaftliche Publikationen und Datenbanken Historische Daten zu Tierseuchenfällen, betroffenen Regionen und Tierarten Geografische Daten zu Ländern, Regionen und Tierbeständen Open-Data-Quellen und APIs mit Informationen zu Ausbrüchen und Meldungen Manuell erstellte Lageberichte und Risikobeurteilungen als Trainings- oder Vergleichsdaten Übersetzungsdienste und Sprachmodelle für mehrsprachige Quellen

https://opendata.swiss/de/dataset/meldepflichtige-tierseuchen-in-der-schweiz https://ec.europa.eu/food/animals/animal-diseases/not-system_en
https://webgate.ec.europa.eu/tracesnt/adis/public/notification
https://wahis.woah.org/#/event-management
https://empres-i.apps.fao.org/diseases
https://shiny-public.anses.fr/shiny-vsi/
https://healthmap.org/en/
http://outbreaks.globalincidentmap.com/home.php
http://www.bfr.bund.de/de/bewertung_mikrobieller_risiken_von_lebensmitteln-674.html
http://medisys.newsbrief.eu/medisys/groupedition/diseases/en/AnimalDiseases.html

Erwarteter Nutzen

Wenn das Problem gelöst wäre, könnten relevante Tierseuchenmeldungen deutlich schneller erkannt und bewertet werden. Fachpersonen müssten weniger Zeit für die manuelle Suche und Sichtung von Informationen aufwenden und könnten sich stärker auf die eigentliche Analyse und Entscheidungsfindung konzentrieren.

Der Nutzen wäre unter anderem:

• schnellere Erkennung neuer Tierseuchenrisiken
• frühzeitigere Warnungen für die Schweiz
• bessere Übersicht über die Seuchenlage in Europa
• strukturierte und vergleichbare Informationen aus vielen Quellen
• Entlastung von Expertinnen und Experten bei repetitiven Aufgaben
• schnellere und fundiertere Risikoeinschätzungen
• bessere Entscheidungsgrundlagen für Behörden und Fachstellen
• höhere Reaktionsfähigkeit bei neuen Ausbrüchen
• indirekter Schutz von Tiergesundheit, Landwirtschaft und öffentlicher Gesundheit

Ziel für den Hackathon

Das Ziel für den Hackathon ist es, einen funktionierenden Prototypen für einen Tierseuchen-Screener zu entwickeln, der internationale Quellen automatisch analysiert, relevante Informationen extrahiert und übersichtlich für die Risikobeurteilung in der Schweiz aufbereitet.

Lösungsansätze

AI-Agenten, die verschiedene internationale Quellen automatisch durchsuchen Web-Scraping und API-Anbindungen für Behördenberichte, Fachportale und Nachrichtenquellen NLP-Modelle zur Erkennung von Tierseuchen, Regionen, Tierarten und Risikofaktoren Automatische Zusammenfassungen von Meldungen und Berichten Klassifikation von Meldungen nach Relevanz für die Schweiz Frühwarnindikatoren auf Basis von Trends, Häufungen und geografischer Nähe Risikoscoring für Tierseuchen nach Land, Tierart oder Ausbreitungswahrscheinlichkeit Benachrichtigungen bei neuen relevanten Entwicklungen Kombination aus AI-Auswertung und manueller Validierung durch Expertinnen und Experten

Einschränkungen

Datenschutz und Urheberrecht bei der Nutzung externer Quellen beachten Nur öffentlich verfügbare oder freigegebene Daten verwenden Ergebnisse müssen nachvollziehbar und transparent sein Quellen und Unsicherheiten klar kennzeichnen

Nachhaltigkeit

Nach dem Hackathon können erfolgreiche Ideen und Prototypen in bestehende Arbeiten und Projekte des Bundesamts zur Erneuerung des Radarbulletin-Prozesses einfliessen. Ziel ist es, geeignete Ansätze schrittweise weiterzuentwickeln und in bestehende Abläufe zu integrieren.

📬 Interessiert? Schick uns dein GitHub-Handle für das Onboarding als Collaborator fürs unser GitHub Repo!