[DEMIS2SORMAS] Map immunizations from physician reports to immunizations and vaccinations

[kwa20]

Situation Description

Physician reports contain information about the immunization of a case person in the QuestionnaireResponse / DiseaseQuestionsCVDD ressource via the attribute immunization which uses the yesOrNoOrNoInformation code system.

Furthermore, multiple vaccinations can be added when immunization is answered with yes.

Feature Description

• [ ] Map immunization to Case.vaccinationStatus when processing physician reports

  DEMIS name	DEMIS value	SORMAS value
  Ja	yes	VACCINATED
  Nein	no	UNVACCINATED
  Nicht ermittelbar	ASKU	UNKNOWN
  Nicht erhoben	NASK	null

• [ ] Map separate vaccination entries in the following way

  • [ ] Map Immunization.vaccineCode.coding to Immunization.vaccination.vaccineName

    DEMIS name	DEMIS value	SORMAS value
    Anderer Impfstoff	otherVaccine	OTHER
    Spikevax (COVID-19 Vaccine Moderna)	EU/1/20/1507	MRNA_1273
    COVID-19 Vaccine Janssen	EU/1/20/1525	AD26_COV2_S
    Comirnaty	EU/1/20/1528	COMIRNATY
    Vaxzevria (COVID-19 Vaccine AstraZeneca)	EU/1/20/1529	OXFORD_ASTRA_ZENECA
    Nuvaxovid (NVX-CoV2373)	EU/1/21/1618	NVX_COV_2373

  • [ ] Map Immunization.occurrenceDateTime to Immunization.vaccination.vaccinationDate

  • [ ] Map Immunization.lotNumber to Immunization.vaccination.vaccineBatchNumber

Acceptance Criteria

Implementation Details

Additional Information

[FredrikSchaefer]

Okay, let's try to clarify this. @kwa20 Do you agree with the following?

A physician's report consists of several entries. Each entry is of a certain profile. One can see the immunization information in a physician's report structured in a way similar to the one in SORMAS. It can be spread over entries of two different types:

1. In an entry of profile https://demis.rki.de/fhir/StructureDefinition/DiseaseInformationCVDD, there is an item with linkId == immunization. This can be seen as what is an immunization in SORMAS. This item holds the yesOrNoOrNoInformation you mentioned, which shall be mapped to Case.vaccinationStatus. When its value is yes (-> vaccinated), this item can hold (multiple) references to the second relevant type of entry (2.).
2. There may be several entries of profile https://demis.rki.de/fhir/StructureDefinition/ImmunizationInformationCVDD. They can be referenced by an entry according to 1., and represent what can be seen a vaccination in SORMAS. From there, Immunization.vaccineCode.coding, Immunization.occurrenceDateTime and Immunization.lotNumber can be mapped.

If everything is nicely set, the following mapping seems plausible: Map the yesOrNoOrNoInformation in the entry from 1. to the Case.vaccinationStatus. When its value is yes (-> vaccinated), add an immunization to the case and add a vaccination for every entry according to 2. to the immunization.

At the moment, a DEMIS server allows just one entry according to 1. But, there can be references to entries according to 2. in it, that don't exist/are not contained in the notification. Also, one can upload entries like 2., that are not referenced in 1.. I propose to only add a vaccination in 2. for each entry that is referenced in 1., and ignore the ones referenced in 1. that are not present in 2.

Let's assume there is one immunization with two vaccination transmitted in one physician's report. What to make of it when processing? If a new case get's created, it's probably a good idea to add those immunization and vaccinations to it. But what if an existing case gets seleceted, which already has an immunization and vaccinations? Shall the ones from the physician's report be added anyway? We just had problems with vaccination duplicates...

[FredrikSchaefer]

An example of a physican's report containing immunization data can be found here.

[kwa20]

Okay, let's try to clarify this. @kwa20 Do you agree with the following?

A physician's report consists of several entries. Each entry is of a certain profile. One can see the immunization information in a physician's report structured in a way similar to the one in SORMAS. It can be spread over entries of two different types:

1. In an entry of profile https://demis.rki.de/fhir/StructureDefinition/DiseaseInformationCVDD, there is an item with linkId == immunization. This can be seen as what is an immunization in SORMAS. This item holds the yesOrNoOrNoInformation you mentioned, which shall be mapped to Case.vaccinationStatus. When its value is yes (-> vaccinated), this item can hold (multiple) references to the second relevant type of entry (2.).
2. There may be several entries of profile https://demis.rki.de/fhir/StructureDefinition/ImmunizationInformationCVDD. They can be referenced by an entry according to 1., and represent what can be seen a vaccination in SORMAS. From there, Immunization.vaccineCode.coding, Immunization.occurrenceDateTime and Immunization.lotNumber can be mapped.

If everything is nicely set, the following mapping seems plausible: Map the yesOrNoOrNoInformation in the entry from 1. to the Case.vaccinationStatus. When its value is yes (-> vaccinated), add an immunization to the case and add a vaccination for every entry according to 2. to the immunization.

@FredrikSchaeferVitagroup Sounds good to me!

At the moment, a DEMIS server allows just one entry according to 1. But, there can be references to entries according to 2. in it, that don't exist/are not contained in the notification. Also, one can upload entries like 2., that are not referenced in 1.. I propose to only add a vaccination in 2. for each entry that is referenced in 1., and ignore the ones referenced in 1. that are not present in 2.

It seems odd that non-plausible combinations aren't prohibited for uploads, but I agree with that approach. Let's not try to make sense of things that should be handled in the external system. The users can decide what to enter regardless.

Let's assume there is one immunization with two vaccination transmitted in one physician's report. What to make of it when processing? If a new case get's created, it's probably a good idea to add those immunization and vaccinations to it. But what if an existing case gets seleceted, which already has an immunization and vaccinations? Shall the ones from the physician's report be added anyway? We just had problems with vaccination duplicates...

Good point, I think adding them to existing cases would generally not be as much of a problem because the user sees the entries before finishing the side by side view processing and could remove them if necessary. However, I can also imagine that users will not notice it and simply save what has been added automatically. This means that we might need some sort of duplicate detection, which would actually not be limited to vaccinations, though this would be an extensive additional issue, I suppose. Because of this, I would suggest we don't automatically add them to existing cases now and think of how to handle updating existing entities separately.