# Covid-19 vaccination **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2020-12-04 08:53 UTC **Views:** 2263 **Replies:** 37 **URL:** https://discourse.openehr.org/t/covid-19-vaccination/1143 --- ## Post #1 by @varntzen This topic is a starting point of a broad discussion, and perhaps a place to share ideas or already made templates on how to structure Covid-19 vaccinations in openEHR. There are archetypes available in the international CKM, but might need tweeking or spesialization. It is anticipated that there will be national requirements that has to be solved locally, but there is a hope that we at least can share a few general structures. As per now, there will be no formal lead of the work, any volunteers are welcome. --- ## Post #2 by @joostholslag see also: https://discourse.openehr.org/t/sars-cov-2-immunisation/1120/6 or should we stick to that forum? --- ## Post #3 by @ian.mcnicoll Don't think it matters really maybe start again here with a bit more scene-setting. e.g. https://discourse.openehr.org/t/openehr-covid-19-project/448 and we can refer to the other conversation and pull through the artefacts. --- ## Post #4 by @joostholslag I finally found time to work on the idea of specialising CLUSTER.medication to record vaccin information. I think it works pretty well. Only renamed some discriptions (some yet to be done). And added an element for 'treated disease'. That could even make sense to be added to the parent archetype so that we don't need this specialisation but could just do it in a template. Interested to hear your feedback. [openEHR-EHR-CLUSTER.medication-vaccin.v1.adl|attachment](upload://9kbOEvn2H2QM9oM9cqp5tNFpHmu.adl) (80.9 KB) --- ## Post #5 by @ian.mcnicoll Interesting. @Paulmiller and I did something a little different which was to add the Target disease and some other elements that are required for public health reporting and vaccine certification to a specialisation of the ACTION.medication archetype. This is the Vaccination record in the context of a Vaccination certificate template (in line with EU/WHO recommendations). https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJGRmNTIzOWYzYjNjNzRjNGM5NzdiYTQ1M2UzNDcxYThi We think this will work pretty well. One thing that we have to capture and can be a bit confusing is 1. The target disease: ' covid-19' 2. The generic vaccine medication name : 'Covid-19 vaccine' - e popped this under Medication name in the root ACTION.medication specialisation 3. The specific product name : 'AstraZeneca Covid-19 vaccine'.... this seemed to work under the CLUSTER.medication name 4. The immunisation protocol (not used in this template but might be something like 'Covid-19 2 dose protocol' One other thing that we needed to extend was the total number of expected doses in the protocol, which is not in the original meds archetype but perhaps should be. --- ## Post #6 by @joostholslag Hi Ian, 1. I generally agree. I do think it's more about immunisation to an infectious agent (e.g. immunisation against SARS-CoV-2) instead of a disease (COVID-19). But either could work. If we'd go for the 'target disease' I think you could specialise the 'clinical indication' element in ACTION.medication. 2 and 3 I had the same thought. But I think we have the same need for medications that are not vaccines. So I'd like to add elements for 'generic name (Pfizer covid vaccin)', 'brand name (comirnaty)' and 'product name (flask of 3ml of pfizer covid vaccine, as a powder for injection)'. 4. agreed that information is most relevant in the protocol of an action and instruction. But we could make a field for 'standard protocol'. This as well makes sense for many medications. e.g. antibiotics. I would like to work this out on CLUSTER.medication because that can efficiently be reused in ACTION.medication, INSTRUCTION.medication_order OBSERVATION.medication/vaccination_statement and the new EVALUATION.medication_summary --- ## Post #7 by @ian.mcnicoll 1. Yes I also wondered about target disease vs. clinical indication but 'target disease' tends to be how the public health folks /WHO describe it and I suspect this may be more about reporting, so felt it better tp keep it separate from clinical indication. 2. The Medication clusters were designed to be nested to handle potentially complex detail or mixtures so '‘brand name (comirnaty)’ and ‘product name (flask of 3ml of pfizer covid vaccine, as a powder for injection)’ could both be handled as separate Medication Clusters - BTW this is pretty well identical to the way that the FHIR Medicaiton resource works. --- ## Post #8 by @joostholslag > '‘brand name (comirnaty)’ and ‘product name (flask of 3ml of pfizer covid vaccine, as a powder for injection)’ could both be handled as separate Medication Clusters how about nesting the comirnaty cluster in the product name cluster? I do feel it has value to create seperate elements for generic name and brand name and product name, because they can have a different meaning and you want to be able to display a different variant of the name in the interface. If target disease is the name of the element I would not put it under clinical indication either. But if you want to register the indication of the vaccine (immunisation against sars-cov2) that could very well go under clinical indication right? Or is that more a goal than an indication? --- ## Post #9 by @heather.leslie [quote="ian.mcnicoll, post:5, topic:1143"] target disease [/quote] In the Immunisation summary archetype, we currently have 'Infectious disease or agent', which is the target [quote="ian.mcnicoll, post:5, topic:1143"] One other thing that we needed to extend was the total number of expected doses in the protocol, which is not in the original meds archetype but perhaps should be. [/quote] We need to be able to clearly manage recording #1 of a course of 'n' vaccinations, plus manage the textual status for 'Booster' - see CR-363 in CKM. It's not as simple as a count, but maybe needs to be SCT coded as 'first', 'second', 'booster'. In addition, curious why you modelled the certification as an admin archetype. Is it possible or reasonable to add it as part of protocol? Does/could/will the vaccinator also do the certification or is this likely to be a secondary step by someone else? Cheers H --- ## Post #10 by @ian.mcnicoll [quote="heather.leslie, post:9, topic:1143"] We need to be able to clearly manage recording #1 of a course of ‘n’ vaccinations, plus manage the textual status for ‘Booster’ - see CR-363 in CKM. It’s not as simple as a count, but maybe needs to be SCT coded as ‘first’, ‘second’, ‘booster’. [/quote] We possibly need to handle this in a variety of ways. For the SNOMED Coded values, the plan was to use the 'Vaccination procedure' element in protocol - as in the UK GP systems we would have things like 'First Tetanus', Booster tetanus' that are really abut schedule management. Vaccine Certificate as ADMIN_ENTRY.? TBH a bit of an arbitrary choice. I guess we had seen this as something different to the vaccine recorditself but much of the official certificate dataset is essentially directly drawn from the record so I could easily be persuaded to add this to protocol. Do we think directly into protocol or as a CLUSTER in case we end up with some variations? (Hope not but !!). --- ## Post #11 by @KBarwise @ian.mcnicoll could you share the adl for this template that you shared? the link is no longer active. TIA --- ## Post #12 by @ian.mcnicoll https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDExNmE2YzgwZmQ3YzQwZWFiN2I4MmY4YTg2MjExOTVj I think that was it --- ## Post #13 by @KBarwise :pray: Thanks Ian --- ## Post #14 by @KBarwise Has anyone else made any headway in terms of vaccination certificates? We are slated to join the EC initiaitve and will need the following data points as discussed previously (a) name: surname(s) and forename(s), in that order; (b) date of birth; (c) disease or agent targeted: COVID-19 (SARS-CoV-2 or one of its variants); (d) COVID-19 vaccine or prophylaxis; (e) COVID-19 vaccine product name; (f) COVID-19 vaccine marketing authorisation holder or manufacturer; (g) number in a series of doses as well as the overall number of doses in the series; (h) date of vaccination, indicating the date of the latest dose received; (i) Member State or third country in which the vaccine was administered; (j) certificate issuer; (k) unique certificate identifier. Which currently feels like a mix of the immunisation summary, Medication management, Medication cluster. I know within the EHR items like (a) & (b) would be captured elsewhere in the EHR (or is it ok to capture here for a certificate) but how would we capture (i), (j) & (k) a new archetype? I have started playing around [here](https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDQ2NzljYzAwNzkxNTRkMTZiNTU0NjdlYTEzOTFjNWQ2), using @ian.mcnicoll's template but feel my new archetype (Vaccination Certificate Details) is very much a bastardization. Any advice would be appreciated. --- ## Post #15 by @ian.mcnicoll https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDk3OWU5N2FjM2QwOTQ0N2FiNzUzYmQ4Zjk1YTM3NWI5 Did this a while ago, so the requirements may have changed but should be close to the EU --- ## Post #16 by @birger.haarbrandt Isn't there a version of the vaccination certificates in Slovenia based on openEHR? --- ## Post #17 by @KBarwise Thanks Ian! will check this out @birger.haarbrandt ! Thank You! is the Slovenia Ministry of Health CKM open? --- ## Post #18 by @heather.leslie Here's my take on documenting the requirements for a [Vaccination certificate](https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDY0ODVhNjQ2ZWMxYzQ3Nzg4ZDMzN2UxNDk4NjA2NDBh)... by extending the EVALUATION.Immunisation_summary (suitable for any vaccine or course) and creating a COMPOSITION for a Certificate. --- ## Post #19 by @KBarwise The slot for clinical evidence , could the recovery certificate sit there? or we should be thinking otherwise?? --- ## Post #20 by @heather.leslie Hi Keisha, I haven't seen examples of content, but I would think that a recovery or test result certificate would be standalone documents, perhaps re-using the COMPOSITION I have proposed (and uploaded as a candidate to and incubator on CKM - https://ckm.openehr.org/ckm/archetypes/1013.1.5797. The content would be purpose-specific, hopefully reusing existing content eg the OBS.laboratory_test_result etc. I can also imagine that both the recovery and test result certificates could/should be linked to the Problem/diagnosis archetype for COVID, rather than a vaccination certificate. But I'm guessing without seeing the requirements... Cheers --- ## Post #21 by @varntzen Hi, everyone I realised I started this topic, and just disappeared. Shame on me! :crazy_face: I think both Ian's and Heather's template will work. And Ian's is already in use, I suppose. My comments: **First, the COMPOSITION:** I like the new Certificate COMPOSITION, as linked to the CKM above . There are a lot of use cases for certificate: Death certificate, Birth certificate, Medical condition certificate (i.e. needing assistance), Medication certificate (i.e. bringing opioid medications with you abroad and prevent you from being arrested for drug traffic), Vaccination status, Stating you are fit to (still) drive a car, etc. Keeping certificates apart from other COMPOSITIONS is a wise thing to do, IMO. Likewise to add elements relevant to the certificate within that context is a good idea, i.e. the certificate issuer, validity, .... I don't know if it should be only one general certificate COMP, and specialize them, or having more specific certificate COMPOSITIONS. Any thoughts on that? **Secondly, EVALUATION.Immunisation_summary vs ACTION.medication-vaccination:** I see that the health service provider need an ACTION to record that a specific vaccine has been given. I might demonstrate my lack of understanding, but is it the ACTON that leads to the vaccination certificate? The ACTION.medication is for recording a given medication, regardless of if it is a vaccine or another product. It even says so in the Concept description. Shouldn't the ACTION populate a persistent archetype which keeps track of which number in a (potential) sequence of jabs, and when the next vaccination is due? This is what the EVAL.Immunisation_summary does. It would be nice to agree upon how to deal with vaccinations within the community. I fear that implementations are deviating, and will cause trouble later. --- ## Post #22 by @joostholslag Hi Vebjørn, Thank you for bringing up these good questions. Late last year we tried to get a common approach to vaccinations of the ground just before covid started. But in the end everybody did his own thing with only loos correlation. I for Nedap created a quick and dirty archetype. The only semi decent pattern is it uses a “covid vaccine” CLUSTER that specialises CLUSTER.medication (it includes Dutch batchid valuesets and rules to set the manufacturer name based on the valueset). With my current level of understanding maybe this should have been a template cluster. What we can learn from this is using medication.cluster can work for a vaccination usecase. Furthermore I’d like to share that I’m concerned about the certificate based on EHR data. Especially if it has legal status (not just health information for other caregivers), as it does in the Netherlands and many other countries. This fundamentally changes/adds to the usecases of the EHR data. And I’m concerned that it will impact the way we uses the EHR since it’s no longer just used to record information to the benefit of the individual patient. Please let me know if my concern resonates, I’m struggling to explain it😅 I guess we can’t (shouldn’t) be against secondary use of the EHR data, but let’s think carefully before adding certificates to the EHR. Leaving that for now, semantically I think you’re right the process should be vaccination action -> immunisation evaluation -> immunisation certificate composition. Maybe it’s possible to generate a evaluation based on a decision logic that takes (only) the action into account. But sementicaly you’re interested in the immunisation status, not the vaccination action. Although the difference for covid is non existent atm for the certificate. But for other vaccinations eg hep b it’s common to judge the immunisation status with a blood (antigen titer) test, not just the action. https://github.com/nedap/archetypes/blob/master/COVID/openEHR-EHR-CLUSTER.covid_vaccin.v1.38.0.adls --- ## Post #23 by @varntzen Hi Joost Thanks for your support and views! [quote="joostholslag, post:22, topic:1143"] But sementicaly you’re interested in the immunisation status, not the vaccination action. [/quote] Excactly, thank you for wording that better than I did! [quote="joostholslag, post:22, topic:1143"] Furthermore I’d like to share that I’m concerned about the certificate based on EHR data. [/quote] I guess that will vary between legislations. If there is a need to issue a "certificate-like" statement from a clinician, and from the EHR, then we should provide a COMPOSITION for that. And if it is not suitable in a country, then don't use it. Mayby the name "certificate" is the issue here? We can change to something different, if it helps. "Medical statement" or similar? I guess how and by whom issuing of COVID-19 certificate is done, is different between countries. In Norway it's issued from a "Core EPR" run by a governmental organisation, which recieves messages from different parts of the health system. Nevertheless, all data has to be captured , stored and sent from each potential health service provider. Whether this is sent using a "Certificate" COMP, or "Medical statement" COMP, or simply by creating a message directly from ACTION and/or OBS and/or EVAL archetypes is not important. Either way will work, AFAIK. But it will be easier to trace what has been sent if it is within a COMPOSITION. Any vendor, please correct me if I'm wrong. --- ## Post #24 by @varntzen [quote="joostholslag, post:22, topic:1143"] Late last year we tried to get a common approach to vaccinations of the ground just before covid started. [/quote] And yes, I do remember. Everyone suddenly got very busy! I think the next pandemic should be better planned. I suggest that it will be notified at least one year ahead, so we can prepare better :wink: --- ## Post #25 by @joostholslag My concern is more about the goal and context of a certificate, e.g. a covid vaccination certificate is used to allow e.g. entrance to restaurants (in the Netherlands) and should be issued by a (government) authority. Stuff like chain of evidence, verifiability, trust in the authority etc is very important in that context. And moreover it's very black and white. It's either valid or invalid, while most of the info in the EHR is on a much more subtle scale between true and not true. The goal of the EHR is to record information used to care for an individual. And I'm concerned that the requirements for a legal piece of evidence will interfere with that main goal of the EHR. --- ## Post #26 by @ian.mcnicoll Ho Joost, That's a perfectly reasonable cultural perspective, but AFAIK, in the UK the source of truth is ultimately the original vaccination record or Covid test record, which would , at least in the UK, definitely be stored in the EHR (may be cached elsewhere). And it 's not just vaccination info that is 'black and white', at least in terms of decision support. As an example UK Covid shielding/ vaccination prioritisation was very largely based on coded diagnosis entries in GP systems. I'm not against an approach that has a specific certification composition but in other contexts in can imagine that this may be 'assembled' dynamically from the core EHR records, albeit via s specific service which 'assures' the certification. --- ## Post #27 by @varntzen Hi Joost, I've been down with a airway infection some days, haven't seen your reply until now. Sorry. Regarding: [quote="joostholslag, post:25, topic:1143"] The goal of the EHR is to record information used to care for an individual. And I’m concerned that the requirements for a legal piece of evidence will interfere with that main goal of the EHR. [/quote] Yes, you are of course right, with the primary goal of the EHR. However, information from the EHR serves, or can serve, more purposes, Secondary use, i.e. local or national registries, de- or pseudoanonymized data for research, and - in some countries for different types of "certificates". What the owner of the data actually uses the data for, is up to local regulations and implementations to decide. I really don't see the problem of facilitating compositions for certificate-like usecases. --- ## Post #28 by @varntzen [quote="ian.mcnicoll, post:26, topic:1143"] That’s a perfectly reasonable cultural perspective, but AFAIK, in the UK the source of truth is ultimately the original vaccination record or Covid test record, which would , at least in the UK, definitely be stored in the EHR (may be cached elsewhere). [/quote] Yep. Data of both vaccination and test results are "born" in various EHR-systems in Norway as well, and fed to a central hub ("Core EHR"), and the certificate is issued by it. I guess it will be something similar in other countries as well. --- ## Post #29 by @siljelb [quote="heather.leslie, post:20, topic:1143"] re-using the COMPOSITION I have proposed (and uploaded as a candidate to and incubator on CKM - [Clinical Knowledge Manager ](https://ckm.openehr.org/ckm/archetypes/1013.1.5797). [/quote] I think this COMPOSITION archetype has a potential for broad re-use in all sorts of certificates, for example death certificates. My only real question about it is about the 'Vaccinated individual' SLOT which I don't understand the purpose of. --- ## Post #30 by @KBarwise @siljelb it was created to facilitate a mock up (for us) , but would not be necessary in real world usage in the CDR. --- ## Post #31 by @KBarwise I have been curious, about how Countries that are adopting the [EC Digital Covid certificate](https://ec.europa.eu/info/live-work-travel-eu/coronavirus-response/safe-covid-19-vaccines-europeans/eu-digital-covid-certificate_en), have been capturing "immunity data" Is it a combination of the positive covid test and number of days without symptoms? or number of days past the positive covid test? How do we account for patients who were presumed positive without a test, maybe based on symptoms? Interested to see how this is being done Keisha --- ## Post #32 by @joostholslag Hi Keisha, We’ve not implemented the immunity data. But my initial thought are around using lab result archetypes, sign/symptom, and problem/diagnosis. Afaik patients who are presumed to have recovered, without a positive pcr, are not eligible for the certificate: > * **Recovered persons**, holding an EU Digital COVID Certificate should be exempt from travel-related testing or quarantine **during the first 180 days** after a positive PCR test. But for modelling it wouldn’t be a problem, you could probably use the problem/diagnosis archetype based on the clinical decision alone. You could also have a look at the covid templates on CKM for inspiration, or maybe you know them well? Hope this helps. --- ## Post #33 by @joostholslag @heidi.koikkalainen any update on your work? We discussed my design ideas in person. It would be nice to share them here, otherwise I would have to built them just to show my ideas. (My current design is a terrible model, due to haste and technical limitations) --- ## Post #34 by @joostholslag [quote="varntzen, post:27, topic:1143"] Yes, you are of course right, with the primary goal of the EHR. However, information from the EHR serves, or can serve, more purposes, Secondary use, i.e. local or national registries, de- or pseudoanonymized data for research, and - in some countries for different types of “certificates”. What the owner of the data actually uses the data for, is up to local regulations and implementations to decide. I really don’t see the problem of facilitating compositions for certificate-like usecases. [/quote] I’d strongly be in favour of storing those certificates outside of the EHR/CDR. Because the goal of the EHR is so different: legal prove vs information to take care of a patient. I’m really worried about the requirements around chains of evidence and authorisations creeping into openEHR/ the CDR. And mixing up our basic design principles and assumptions. I’m struggling to come up with good examples. Maybe @thomas.beale shares my concern and has some examples. A related example is in my country physical checks for drivers license can never be performed by a doctor that has a normal treatment relationship with a patient, for it will mix up the incentives. It’s off course fine to share clinical data as input for a certificate, but the decision logic and attributes of a certificate should stay out of the CDR. --- ## Post #35 by @KBarwise Thank you for your response. I will definitely take a look at the covid templates on the CKM, I would not say i'm very familiar with them. --- ## Post #36 by @heidi.koikkalainen Hi Joost, I built a Vaccine Record template for a Finnish use case taking the same approach as NDS in Scotland and DIPS in Norway. It's based on the ACTION.medication.v1 archetype with some international CLUSTER archetypes and local extensions nested in. The scope of it is to record details of vaccination administration so it doesn't include immunity data. However, I'm not sure at the moment whether the template will actually be implemented as the client might choose to take a more localised approach. I'll keep you updated! Btw, I actually haven't looked at your models yet as I couldn't figure out how to import ADL2 archetypes to AD :sweat_smile: --- ## Post #37 by @KBarwise So i'm unclear, is protocol is something that we would populate in these kinds of templates? --- ## Post #38 by @ian.mcnicoll The Scottish template is at https://ckm.apperta.org/ckm/templates/1051.57.288 and carries the Country, AppointmentID, vaccination Centre and Target disease in a CLUSTER inside a slot in protocol --- **Canonical:** https://discourse.openehr.org/t/covid-19-vaccination/1143 **Original content:** https://discourse.openehr.org/t/covid-19-vaccination/1143