Vaccination is when a vaccine is administered to you (usually by injection). Immunisation is what happens in your body after you have the vaccination
Thoughts
It makes more sense to have vaccination sequence number as Fully Specified Name as opposed to Immunization sequence number of this concept since we are tracking the vaccination instances as opposed to the general immunization process.
Following this video, we should consider extending the low_normal-high_normal to be 1-20 in the sense that 1-10 covers vaccine doses while 11-20 covers booster doses given of this concept
@mksd - As for the range, we don’t have range on our concept (which was created pre-CIEL). I defer to Andy if that makes sense. With our vaccination UI, it’s not necessary since we don’t capture as an entered number. It also appears that you could have more than 6 for DT (I likely have since tetanus vaccination is at least every 10 years
I’d suggest we just get rid of the “low_normal” and “hi_normal” values from the CIEL concept altogether. As I understand them, those values were intended to express clinically-relevant ranges for, e.g., lab results rather than just the acceptable values to store in the concept.
I’d think this is the kind of thing we’d want to be able to determine on a case-by-base basis rather than having this weird translation into numbers this way, since then every secondary use of this immunization data would need to be aware of this. I’m not sure that at the data level we need to make a distinction between the initial vaccination sequence and boosters. I.e., data-wise, I think things will be cleaner if we store things as “1, 2, 3” versus “1, 2, 11”.
I’d just like to go on the record in support of anything that takes us away from the kludge of adding 10 to a sequence number for booster shots or having an absolute range for them. Determining the correct range for a vaccine series to accommodate boosters feels to me like trying to calculate the correct number of wheels for a boat.
Using a sequence number to reference which among a pre-defined series of shots a vaccine represents makes sense. I would expect gaps (e.g., patient comes for 1st and 3rd shot but got their 2nd shot elsewhere) and I don’t see the purpose of numbering booster shots. Isn’t the date given enough?
Would also be great to have a standard data class and data type for the different vaccinations concepts…Procedure seems a logical data class. Not sure what the best data type would be since we are having some as boolean and others as N/A while others are coded. Perhaps @akanter could give a good background as to why we have these different variations.
Ultimately, Immunization may deserve being a first class citizen in our model (aligned with FHIR), since the information and care needs go well beyond the typical documentation of a procedure. Any compromises we use now (e.g., continuing with obs) would ideally be migrating toward supporting a FHIR-aligned solution.
Yikes, I am catching up on this conversation a little late. I think that the work we did with NY State and the EzVac module raised important issues about counting up vaccinations… just because a person gets a shot, doesn’t mean the shot was valid. It can be the wrong type, the wrong time, or the wrong patient. We need to make sure that we can calculate valid shots in a series despite being at different places and with different compositions. Can we get a call about this? Also, I agree CIEL should not have a range for immunization sequence number and that will be removed. In general, when a number cannot be negative I will put 0 as absolute low value.
