Swiss vaccination record in openEHR – best practices for modeling?

Clinical
1

The openEHR community in Switzerland would like to demonstrate the feasibility of long-term storage of administered vaccinations using openEHR, as part of a productive prototype for a central vaccination record per citizen. A working group has been appointed to carry out the modeling and to document best practices.

Background

  • The Swiss Federal Office of Public Health provides a paper vaccination card.
  • Within the framework of eHealth Switzerland, the vaccination record is legally prescribed in an HL7 FHIR format called CH-VACD (Implementation Guide).

Since FHIR is legally mandated, we want to demonstrate how FHIR-based communication can be combined with openEHR for long-term storage and semantic persistence. During our research and early modeling iterations, we have encountered many questions about recommended modeling patterns and best practices.

Archetypes

We found the following potentially relevant archetypes in the CKM:

  • COMPOSITION.vaccination_list.v0
  • COMPOSITION.health_certificate.v1
  • SECTION.immunisation_list.v0
  • OBSERVATION.vaccination_status.v0
  • OBSERVATION.vaccination_screening.v0
  • EVALUATION.vaccination_summary.v0
  • ACTION.vaccination_management.v0
  • ACTION.medication.v1
  • OBSERVATION.medication_statement.v0

For the administered vaccinations we currently plan to use:

  • COMPOSITION.vaccination_list.v0
  • SECTION.immunisation_list.v0
  • ACTION.vaccination_management.v0

However, we did not find uniform recommendations across implementations.

Template/Composition strategy

We see two main options for storing administered vaccinations:

  • a single curated, persistent COMPOSITION containing all vaccination events (versioned over time), or
  • one COMPOSITION per vaccination event.

Questions

  1. Are there established best practices for modeling administered vaccinations in openEHR and are the selected archetypes suitable?
  2. For administered vaccinations, is it recommended to store one COMPOSITION per vaccination event, or to maintain a single persistent COMPOSITION that contains all vaccination events?
  3. Are there existing openEHR projects, reference templates, or implementation guides for a vaccination record that we could reuse as a starting point?

Many thanks for your feedback, Jean-Pierre

1 Like
2

Hi Jean-Pierre

We have a national vaccines store in Scotland, but it runs on an SQL database and maps to the FHIR resources.

I did some work modelling the administration events as an openEHR template and would be happy to share the Archetype Designer file set with you. That work is around 4 years old.

This used an event composition and a couple of other local archetypes to capture things like country of vaccination and vaccination centre.

We did not work up a persistent composition / vaccination list but that would almost certainly be needed as a requirement if we were persisting the administration events in openEHR.

The admin event would capture specific data on the vaccine product, its context, and the administration itself.

The vaccine list persistent composition would use only some of that data, depending on the use case.

So: two separate things.

Looking at the template we authored, it is not quite right from an occurence perspective, as it probably needs to be able to record mulitple vaccine administration at a single care event (you give an Influenza and a Covid 19 vaccination at the same visit), and I have a 0..1 on medication (vaccine) management action archetype in the current model so it would not support that.

But, as I say, we never refined it to production so it is not perfect. Even so, you might still find the model useful as you progress your work.

I would prefer that this data was persisted in openEHR rather than where we have it, as it needs to exist for a person’s whole life, and it is more vulnerable in its current format. It is managed by our organisation, which is part of the public sector health service, so that affords it some protection - at least it is not all sitting in multiple, scattered proprietary systems. The vaccine records we currently have are not comprehensive, however, and some vaccination records still exist only in closed vendor systems.

Happy to help if I can.

Best wishes, and good luck!

Paul

3

Hi @JPMesserli ,
I see the vaccination list as analogous to the medication list: it should be represented as a single curated, persistent COMPOSITION. It represents a long-term (potentially lifelong) person state (i.e., a continuant), rather than discrete events.

In this model, the vaccination list would:

  1. be updated through reconciliation workflows or clinical reviews.
  2. serve as the source of truth for clinical decision support (CDS) and user interfaces.
  3. be typically derived from vaccination orders and administration actions recorded in the person’s record.

Vaccination administration events should be recorded in event compositions (e.g., Encounter compositions) using vaccination ACTION entries. These represent what happened at a specific time, such as a dose given, withheld, stopped, or adverse effects observed.

Conceptually in openEHR:
Persistent compositions represent patient state summaries.
Event compositions represent clinical occurrences.

One might ask whether the persistent vaccination list duplicates vaccination administration data. The short answer is yes, but deliberately, by design. The two artefacts have different semantics and lifecycles, and both are clinically necessary.

This is my current recommendation from a modelling perspective, but I’m open to other views.

1 Like
4

Thank you very much for your assessment. Which archetypes from the CKM would you use for the curated list of vaccinations administered? I have listed the existing ones above.

5

Shouldn’t the medication list be the sum of queries on the vaccination events in the patient records in the countries the patient has lived in? An international repository isn’t going to happen.

6

That’s adjacent enough to a software design choice for me to comment. I cannot comment on the preferred modelling of a medication list since that’s the clinician’s preference, but for the vaccinations, my understanding of @chunlan.ma ‘s suggestion is that the persistent composition acts as the up-to-date projection of vaccination status which is a projection of actual vaccination events. So if you want to know the vaccination status of a patient, that’s just one composition with complete information, as known to a specific system.

If I was tasked with building a combined vaccination status of a patient based on information in N openEHR systems, I’d first attempt to merge the information from persistent compositions from all those systems as long as the assumption of each persistent composition being an up to date and complete projection of the vaccination events recorded by that source system holds.

My reason for going for this would be to avoid fetching N event streams and merging it all instead of merging their already merged current states. The interesting question based on the above assumptions would be: how do we state that a composition can be safely interpreted as a complete and up to date summary/projection of a particular set of clinical events? It’s never simple is it?

1 Like
7

Thank you very much. We are modeling an electronic vaccination card that will be made available as a standalone solution on an openEHR platform in the cloud.

The vaccinations administered will be delivered in accordance with Swiss legal requirements using the FHIR Vaccination Record Document https://www.fhir.ch/ig/ ch-vacd/vaccination-record-document.html or FHIR Immunization Administration Document Immunization Administration Document - Implementation Guide CH VACD v6.0.0 and persisted in openEHR for long-term storage.

A standalone vaccination record in openEhR is modeled accordingly. This raises the question of which archetypes we should use from the CKM?

8

In Switzerland, a national repository for a digital vaccination card is planned. The legal basis for this is provided by the CH-VACD (FHIR) exchange format, which is enshrined in law. As openEHR Switzerland, we would like to demonstrate the interaction between FHIR for communication and openEHR for long-term storage.

1 Like
9

As can be clear from the great conversation so far, vaccination is surprisingly complex.

There are at least 3 overlapping aspects, a record of the vaccination administration itself, which is in turn a kind of medication administration, and may be preceded by a normal prescribing/dispensing cycle, and then a whole set of scheduling, call/recall some of which is reference information (target schedule), but other aspects need patient-level data - when last invited, reasons for exclusion, how many invites etc. I guess the latter is out of scope.

So I would probably start with the NHS Scotland model Vaccination administration record, which we are using/ have adapted in Ireland and Slovenia. My personal preference would have been to have a specific vaccination record archetype from the ACTION.medication archetype but the embedded template approach is fine.

It might be worth cross-checking the FHIR Immunization resource, as there are a few useful additions like ‘primary source’ and sub-potent’ that we should consider, as this will help with historical/reported immunisations.

I think the vaccination admin record should be the ‘truth’ and it could be argued that we could construct an overall immunization record by live-querying, as we might do for a medication record in a prescribing system i.e we would only use medication statements, where the list of medications was sourced from patient report or non-prescribing systems.

However, I can see the value of using a persistent immunization list composition as a key EHR component, also helpful to record global exclusions, but might link to the original vaccination record compositions/entries, rather than persist copies of these in the persistent composition.

10

Is that your preference when all the data is in a single CDR? If yes, could you share why you’d prefer that?

11

@ian.mcnicoll Hi Ian
Thank you very much for your thoughts.

We are trying to model the vaccination card for Switzerland, which is managed standalone on a platform in the cloud. This platform is embedded in the Swiss Health Data Space (SHDS), which has legally regulated FHIR as the exchange format:

  • All vaccinations performed are transmitted from the primary systems to the platform using an FHIR profile.
  • The long-term storage and semantic consistency of the vaccinations performed is ensured on the platform with openEHR.
  • The vaccination card can then be retrieved as an FHIR profile.
  • The conversion from FHIR to openEHR and openEHR to FHIR is therefore predetermined.

In the attachment, you will find my mind map, which describes all of the CH-VACD FHIR data fields for the Vaccination Document:

Xmind Vaccination record FHIR to openEHR 23.02.2026.xmind (263.5 KB)

  • Immunization
  • Basic Immunization
  • Medication for Immunization

All valuesets are listed in the mind map, including the link to the FHIR valueset. The URLs to the corresponding FHIR profiles can be found in the notes. I am now trying to group the data fields in this mind map into Data, Protocol, Context, and Reference Model.

Vaccinations are recorded and coded generically (Swissmedic-Code or Snomed CT). The commercially vaccination products administered are listed separately in ‘Medication for Immunization’ with GTIN-Code. In addition, vaccinations recorded in the medical history can also be recorded in ‘Basic Immunization’ without a medication being recorded.

Based on the above discussion, all vaccinations performed should be stored in a single composition as a common curated list in the sense of a single source of truth.

Questions based on the above supplementary information:

  • Use openEHR-EHR-COMPOSITION.vaccination_record.v0?
  • Use SECTION.immunisation_list.v0 (for subdivision)
  • Use ACTION.vaccination_management.v0, which is vaccination-specific with a cluster for ‘Medication for Immunization’?
    Or use openEHR-EHR-ACTION.medication.v1 with other medication clusters?
  • Or would it be better to create a new archetype for the Vaccination Card that neatly maps all FHIR data fields?
12

Now that is a very good question!!

There is definitely a case for persistent compositions but I’ve always been a bit bothered by the relationship between the ‘original record’ and the persisted ‘copy’.

In the Swiss example, there is a specific vaccination event, captured in the CH VACD Immunization Administration Document, along with supportive background information.

In a pure openEHR system, this would be captured in an event composition (and this is basically what the Scottish approach does).

So how do we manage the full vaccination record?

We could just query for existing vaccination events but that feels quite brittle, and I agree with Chunlan’s suggestion to use a persistent composition.

However, traditionally, this has meant cloning the original vaccination admin event into the persistent composition, which introduces some redundancy and potential concurrency issues if changes have to be made to either record.

That would be improved, I think, by referencing the vaccination events from the persistent composition, rather than cloning, though I appreciate it does complicate querying at the moment.

In summary, avoid cloning original records and leave the vacc entry in its original event composition context.

1 Like
13

You make some good cases related to this. I think we can agree on the problem of more than one source of truth when the clinical modelling produces a series of vaccination events and a persisted composition. We need the event semantics for vaccinations themselves, but also the state of vaccination, which is a distilled derivation of the events.

The problem is (please confirm), the modellers do not have a way of indicating what subset of events represents a state of vaccination. That justfies @chunlan.ma ‘s persisted composition suggestion suggestion IMHO.

However, now we have to mechanisms to not only access (read) vaccination info, but to record (write) as well! The persistent composition can be updated on its own: so those who use the series of events to build vaccination state may miss some data that was written over the persistence composition, and there’s even an edge case (depending on implementation, which I won’t go) in which direct writes to persistence composition can be lost.

So what do we do? If we go with “fetch all events and build vaccination state”, then the state of vaccination is not a first class clinical concept and its interop relies on everyone using the same way of stitching/distilling events. I’m not in favour of that.

If we go with a persistent composition, multiple ways of updating vaccination data can lead to data loss (patient safety issue).

I think we need to discuss how to adopt some mature architectural approaches at the spec level. Did we discuss read only compositions? Do we already have them?

My knee jerk approach would be the following:

  • Model both vaccination events and their projected current-state composition
  • Introduce a projected/computed composition category/type that cannot be updated directly from the REST API (similar to persistent)
  • Make it a recommendation to model events and their meaningful projections using this combination
  • Modify REST API specs to return metadata when an event with a downstream projection is modified, a location header to computed composition etc.

The above allows clinicians to define event details and event-summary/state details separately. System implementers are responsible with updating the projection compositions based on modifications to source events. Specs keep it lightweight, just a new category for compositions.

We may already have had this discussion, SEC has been busy for the past few years. Pointers are welcome if that’s the case.

I’m trying hard not to hijack a modelling question here, so my priority is to confirm vaccination events and vaccination status are both first class clinical concepts to model. If that’s the case, then the above issues should be addressed, but that’s secondary stuff in a clinical modelling discussion.

1 Like
14

As mentioned, we are also legally required to comply with FHIR. CD-VACD FHIR clearly distinguishes between four profiles, including:

  • Vaccination Record Document
  • Immunisation Administration Document

‘The Vaccination Record document describes the content and format of a vaccination record document. It is a compilation of all available immunisation-related content and thus shows the patient’s immunisation status at a specific point in time…’

‘The Immunisation Administration document describes the content and format of an immunisation administration document. It serves to document changes in the immunisation status and contains information on applied immunisations and further relevant chapters…’

From this and from the discussions so far, I would conclude that both are needed:

  • One single, persistent and jointly curated composition with all vaccinations performed
  • Action-Archetypes that document the administration of a vaccination. Must then be transferred to the above composition.

This could be similar to the diagnoses. A diagnosis can be recorded in the progress notes or clinical findings. At the same time, a list of diagnoses is kept and curated jointly.

What are the answers to the specific questions I have formulated above?

15

My short answer to this question is “should not“.
In theory, a global event-derived immunisation history would be ideal, but in practice there is no global repository, and records are fragmented and incomplete. Therefore, a curated immunisation statement is clinically necessary and should not be replaced by event queries alone.

In addition, my view is that vaccination administration events (normally represented using openEHR Instructions and Actions) are the source of factual evidence about what happened at a specific point in time. They provide the most granular and auditable data.
However, the vaccination list should represent a curated immunisation statement and immunisation status, which is better modelled as an openEHR Evaluation (i.e. a healthcare provider’s clinical assessment or conclusion). This status may be derived from administration events, but it may also be derived by other evidence such as patient infection history, external records, serology results, or clinical judgement. Therefore, it cannot always be directly or reliably computed from administration events alone.
In other words, vaccination administration represent point-in-time events, while the vaccination list represents a continuant clinical state. The vaccination list acts as a clinical abstraction layer and a medico-legal snapshot of the patient’s immunisation status at a given time, rather than a simple aggregation of events. The two artefacts have different semantics and lifecycles, and therefore serve different clinical and operational purposes.

2 Likes
16

Thanks @Seref . I think both vaccination events and vaccination status are both first class clinical concepts. Some vaccination status could be derived from events, but some cannot and may depend on external records, serology, or clinical judgement.

1 Like
17

Thanks. This is why I was asking for confirmation. This kills my read-only composition suggestion. I think positioning a persistent composition as the source of truth and feeding it both from events and direct updates is the only option left. Your clarification also presents another counter argument against populating vaccination status from events via querying.

1 Like
18

I have tried, but cannot find those archetypes you listed, I think you’ve identified the most relevant ones. Well done.
For the persistent, curated vaccination list I’d suggest:

COMPOSITION.vaccination_list.v0
SECTION.immunisation_list.v0 (optional, for grouping)
EVALUATION.vaccination_summary.v0 (core for clinical summary/status)

For vaccination administration events:

COMPOSITION.encounter.v1 (or equivalent episodic composition)
SECTION.immunisation_list.v0 (optional)
ACTION.vaccination_management.v0

2 Likes
19

@JPMesserli @ian.mcnicoll

Although I mentioned that the vaccination list is similar to the medication list, there are important differences between them. A vaccination list is typically lifelong, may not always be directly derived from administration events, is often required for public health purposes, and has stronger evaluative semantics.
Vaccination history represents a record of discrete vaccination administration events, whereas vaccination status represents a longitudinal clinical state (i.e. an evaluation). When modelling a vaccination list, a key question is whether the vaccination list is intended to represent vaccination history, vaccination status, or both.
In FHIR, the Immunization FHIR resource represents vaccination administration event, ImmunizationEvaluation resource represents vaccination status.
I think answering the question above may help clarify the modelling.