Immunisation records as verifiable credentials

Terms

Terms used on this page

The words below have a narrow technical meaning in this field. This page uses them in that meaning throughout. Each term links to its entry in the DIDAS Glossary, which defines the same words for the whole Swiss ecosystem and carries them in German, French and Italian.

Background

An architectural consideration

meineimpfungen.ch held the national electronic vaccination record until its closure in 2021, after which the records it held were no longer accessible to the people they described.

The episode illustrates the availability and continuity risks associated with relying on a single service for access to longitudinal health information. This showcase explores a different distribution model rather than a judgement on that platform.

In this showcase each administered dose is issued as its own credential, signed by the vaccinator that administered it, and stored in the patient's wallet. A credential already issued remains usable by its holder if the issuing organisation ceases to operate, subject to the status and revocation mechanisms the profile defines and to the continued availability of the identifier, status and trust infrastructure a verifier reads.

The mechanism

How credentials reach the wallet and how claims are presented

Four organisations issue credentials to the wallet: the Confederation, a health insurer, a practice and a pharmacy. Each issues the credential types its role permits in this project's policy configuration. Claims leave the wallet in response to a specific presentation request from a verifier, after the patient confirms that request in the wallet, one request at a time. Issuer and verifier exchange no clinical payload through a shared store. The component both sides read is the status list published by the Confederation's Base Registry, which carries a status entry per credential and no clinical payload or patient attributes. Both parties also resolve identifiers through the Base Registry and read trust statements from the Trust Registry.

Selective disclosure

What each verifier receives

The immunization credential type defines eighteen claims. This project's policy layer attaches an entitlement to each verifier role, naming the claims a verifier in that role may request. A query naming a claim outside that entitlement is rejected by the policy layer while the query is being built, before any request reaches the wallet.

The point at which that check runs is a design decision. A check applied after the wallet has responded operates on data the verifier already holds, so it constrains what the verifier is permitted to do with the claims rather than which claims it received.

For comparison, the alternatives in routine use disclose differently: a paper booklet is read as a whole page, and a PDF exported from a portal is transferred as a whole file. Selective disclosure narrows the presentation to the claims the request selects and the wallet releases. It says nothing about correlation across presentations, which depends on the credential identifier, the holder key, the disclosed claim values, the status-list reference, timing and network metadata.

Governance

What happens before a clinical fact is accepted

A presentation raises several distinct questions. The technical profile and the trust infrastructure answer some of them: protocol validity, cryptographic validity, credential and status validity, holder key binding and issuer trust. Three further questions are governance questions and are answered here.

First, whether the issuing party may assert a clinical fact of this kind. A signature that verifies establishes which key signed and, through identifier resolution, which issuer holds that key. It does not establish that the issuer holds the role this project requires for the assertion. Second, whether the requesting party may ask for the claims it is requesting, which is a separate question from whether the request is well formed. Third, whether this particular presentation should be accepted, given its scope and context. Each question is implemented as its own function; the three run in a fixed order, and each records its reasoning whether the outcome is acceptance or refusal.

Some of the Swiss Profile's trust rules are stated at SHOULD level and cannot be satisfied in the Sandbox, because the Sandbox makes the official verification of an organisation optional. The Sandbox policy records each such rule as waived. The journal then shows which rule was relaxed and on what grounds. A demonstrator that deletes the rule instead reports the same success and leaves no trace that anything was skipped. On production swiyu the same code runs the strict policy, which requires the markers this one waives. That is one environment variable. It is the smallest of the differences between the two environments: what changes on production swiyu →

The journal records claim names and no claim values, so it evidences which rules were applied to an interaction without becoming a second copy of the patient's data. A test asserts that no AHV number and no vaccine lot number reaches it.

Standards

Composing with the openEHR and HL7 FHIR information models

HL7 FHIR and openEHR address healthcare semantics, information models and clinical data exchange and persistence. Verifiable credentials and the swiyu Trust Infrastructure address authenticity, provenance, controlled presentation and trust relationships. These are different layers and they can be composed. This project reuses the information models and does not itself operate a clinical data repository; that is a property of this demonstrator, not a position on how FHIR or openEHR should be deployed.

Every claim carries the FHIR element path it corresponds to and, where one exists, its openEHR archetype path. When a presentation arrives, the receiving system can rebuild the representation it already understands from the claims the holder released, locally. The mappings below are this project's own and have not been reviewed by the standards bodies concerned.

"resourceType": "Immunization",
"status": "completed",
"vaccineCode": {
  "coding": [{
    "system": "http://snomed.info/sct",
    "code": "871895005" }],
  "text": "dTpa-IPV combination vaccine" },
"occurrenceDateTime": "2026-09-11",
"lotNumber": "S4021-B",
"protocolApplied": [{
  "targetDisease": [ … ],
  "doseNumberPositiveInt": 1,
  "seriesDosesPositiveInt": 3 }]

immunisation/medication_management/
  medication_item:      "dTpa-IPV combination vaccine"
immunisation/medication_management/
  medication_item/code: "871895005"
immunisation/medication_management/
  time:                 "2026-09-11"
immunisation/medication_management/
  batch_id:             "S4021-B"
immunisation/medication_management/
  route:                "IM"
immunisation/territory|code:    "CH"

Two properties hold for every projection. The code states both wherever it performs one. First, a projection is derived and not authoritative. The signed credential remains the evidence. Second, a projection is legitimately partial. After selective disclosure a FHIR resource may carry findings and no patient name. A receiving system therefore has to treat an absent element as an expected outcome of the disclosure rather than as a data error. Handling those partial resources is the main integration cost of this approach.

The blueprint

Eleven documented flows

Each of the eleven is a self-contained file holding machine-readable front matter, a diagram, the governance constraints that apply, the standardisation constraints that apply and the questions it leaves open. The file is the specification; every entry below links to it. Each file can be moved into a trust flows repository and sit beside flows from unrelated sectors.

The eleven are not the same kind of object, and the ways they differ are independent of each other. Each file declares four characteristics: whether it is a flow or a transformation, whether messages cross a party boundary (multi-party, local or unresolved), whether it is atomic or composed, and whether it concerns a discrete event or a continuous stream. F-08 is composed and an inter-party exchange; F-10 is continuous, which says nothing about whether it is local or multi-party, so those two fields are unresolved for it.

The seven modelled interaction flows are also drawn in LikeC4, in the same form as the DIDAS reference flow, so that they can move without being redrawn. Every step in the model carries the protocol, the data format and the eHealth Suisse rule behind it in its notes. Interaction scope decides which entries have a diagram, not maturity. F-07 is implemented and has none because it is a local projection step rather than an exchange between parties: it begins after a presentation has completed and maps the disclosed claims into FHIR or openEHR representations inside the verifying organisation. F-08 and F-09 are multi-party and could carry one; both are roadmap flows and are not yet modelled. F-10 leaves its interaction scope unresolved, so there is no exchange to draw. Three of the eleven depend on a mechanism the current Swiss Profiles do not define, recorded with stable identifiers in the Swiss Profile gap register. Open all the diagrams →

Roadmap

Planned work, 2026 to 2028

Step 1, item by item

The IPS sections step 2 has to cover

Step 1 covers Immunizations. It reaches partway into Medications and Results. The remaining sections are the natural unit of work for 2027. Their LOINC codes are the ones the IPS uses.

Allergies are the one gap here against the project this work continues: the 2024 wallet carried allergies and the practice asked for them at check-in. Everything else in this table is an extension of what step 1 built.

The other 2026 showcase

openEHR Switzerland brought a second vaccination showcase to the same hackathon: FHIR intake in CH VACD format, persisted as an openEHR composition in a clinical data repository. openEHR Switzerland and HL7 Switzerland have since formed a joint working group to turn it into a reusable implementation blueprint. They raise the substantive objection to the design on this page. A vaccination record has to stay clinically usable for a lifetime. A document exchanged at one moment is a different object from a record maintained over decades.

The 2024 project's own staging is where the two approaches meet. It described three stages: document-oriented "EPD 1.0", structured and server-based "EPD 2.0", structured and wallet-based "EPD 3.0". The openEHR showcase is a working stage 2 and this project is a working stage 3. Composition in both directions is already specified. A repository can issue credentials from the records it holds. A presented credential can project into the ingestion path that blueprint defines. Building that composition is the main item on the 2027 list.

Public health

Vaccination coverage monitoring in Switzerland

Switzerland measures vaccination coverage through the Swiss National Vaccination Coverage Survey, run since 1999 by the Epidemiology, Biostatistics and Prevention Institute (EBPI) at the University of Zurich with the Federal Office of Public Health and all 26 cantons. It samples randomly selected households of 2-, 8- and 16-year-olds on a three-year rolling cycle. It asks the family to post a copy of the child's vaccination record.

The data source is already the record the family holds. Coverage monitoring never depended on a central register. When meineimpfungen.ch closed in 2021 the survey carried on, because it had never read from it.

Today a family posts a photocopy of the child's vaccination record, which shows every dose, every date, the vaccinating physician and usually the child's name. The presentation modelled here selects five claims and no person identifier, so of the eleven flows it is the one whose disclosure is narrower than the procedure it would replace. The survey response does not require the presentation of an explicit person identifier; the stratum the analysis needs arrives inside the invitation credential. Other disclosed values and protocol metadata may still contribute to correlation, which the section below sets out. The approval step is not new either: households are invited by letter today and may decline today, and the wallet adds a confirmation of the presentation request rather than a new legal consent.

One methodological constraint governs the whole design. The wallet is a response channel and not a sampling frame. A survey that accepted volunteered credentials would measure the population that chose to volunteer, and that selection bias cannot be corrected from inside the sample. EBPI draws the sample from the population register or an equivalent method, and the wallet is used only to return a response to an invitation already issued.

Unlinkability

Unlinkability is used here for two distinct properties. First, that the receiving party cannot associate a response with the household it came from. Second, that it cannot associate two responses with each other. Each depends on a specific correlation surface: the credential identifier, the holder key, the disclosed claim values, the status-list reference, the issuer, timing and network metadata. For a coverage survey the first property is the one that decides the design, because a response that can be associated with a household makes the survey a record of who replied and what they replied.

The design addresses the first half. The invitation posted to the household carries a single-use credential holding the stratum (age band, canton, survey cycle) and no household identifier. The wallet presents it together with the dose claims in one presentation, and the survey revokes it once the response is accepted, using the same two bits on a public status list that make a prescription single-use in F-05. From the response itself the survey learns that a household in a given canton with an 8-year-old reported a given set of doses. No person identifier is disclosed that the survey could use to join that response to its sampling record.

Until one of those two mechanisms is implemented, the property rests on the survey operator following the retention rules above rather than on the protocol preventing the correlation, which is the weaker of the two positions. A zero-knowledge presentation would let the wallet demonstrate that it holds an invitation credential whose status entry is still unset, without disclosing which invitation that is. That would remove the correlation available through the invitation index and its revocation timing. The candidate scheme and its fit to this profile are tracked in issue 10, Longfellow ZK.

Open the F-11 diagram →

Scope

What this prototype is and is not

This is a prototype for exploration and discussion. It has not undergone a security review, a data protection impact assessment or operational hardening, and it is not production-ready.

• Sandbox only. Nothing here has been run against a production deployment of the swiyu Trust Infrastructure. Conformance rules are enforced against the profile text.
• The bundled demonstration runs against a mock. In its default mode the runnable application exercises the business flow and the governance rules against a simulated wallet and simulated generic components. That mock performs no signing, no DPoP, no encryption and no identifier resolution, and establishes nothing about protocol conformance.
• No predicate proofs. The Swiss Profile mandates SD-JWT VC, in which claims are individually disclosable. Demonstrating a property of a claim, such as that a date falls within a range, without disclosing the claim value is not available in this profile.
• Unlinkability is not claimed. Selective disclosure narrows the claims included in a presentation. It does not remove the correlation surfaces two verifiers could use, which include the credential identifier, the holder key, the disclosed claim values, the status-list reference, timing and network metadata; see below.
• The semantic mappings are unreviewed. The FHIR and openEHR bindings are this project's own and have not been endorsed by the standards bodies concerned.
• Demonstration data is illustrative. SNOMED CT codes, GLNs, BAG numbers, GTINs and LOINC codes shown here are plausible and not real.

Open questions

What is not solved

Next step

Discuss, test and learn

The open questions above are not resolved by architecture alone. Further dialogue among healthcare actors, regulators, patient representatives, insurers and implementers is needed to decide which use cases are worth pursuing, which concerns matter in their specific context and which technical or governance choices are proportionate.

Bounded experiments can turn those discussions into evidence. A pilot can test an actual workflow, observe user and operational effects, surface unintended consequences and feed the results into the next design cycle. The objective is iterative learning rather than confirming a preselected solution: define a use case, test a limited model, evaluate the outcomes and concerns, and refine or discard the approach.

As an official swiyu Orchestrator, DIDAS can help convene the multi-stakeholder dialogue and support regulatory sandboxing or other controlled experimentation where the use case calls for it.

Where an experiment requires a temporary deviation from rules under the Federal Health Insurance Act, Article 59b KVG (the Experimentierartikel) provides a basis for EDI-approved pilot projects in specified areas, including strengthening quality and promoting digitalisation. Its applicability has to be assessed for the concrete use case; it is not a general sandbox for health regulation.

Origins

Where this work comes from

This showcase was prompted by two GovTech Hackathons. Both supplied part of the basis it builds on.

The code in this repository and the runnable application it builds were originally developed and contributed by Accelerate GmbH.