Open kwa20 opened 2 years ago
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:
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.).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...
An example of a physican's report containing immunization data can be found here.
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:
- In an entry of profile
https://demis.rki.de/fhir/StructureDefinition/DiseaseInformationCVDD
, there is an item withlinkId
==immunization
. This can be seen as what is an immunization in SORMAS. This item holds the yesOrNoOrNoInformation you mentioned, which shall be mapped toCase.vaccinationStatus
. When its value isyes
(-> vaccinated), this item can hold (multiple) references to the second relevant type of entry (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
andImmunization.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 isyes
(-> 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.
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 withyes
.Feature Description
[ ] Map
immunization
toCase.vaccinationStatus
when processing physician reports[ ] Map separate vaccination entries in the following way
[ ] Map
Immunization.vaccineCode.coding
toImmunization.vaccination.vaccineName
[ ] Map
Immunization.occurrenceDateTime
toImmunization.vaccination.vaccinationDate
[ ] Map
Immunization.lotNumber
toImmunization.vaccination.vaccineBatchNumber
Acceptance Criteria
Implementation Details
Additional Information