Очікуваний результат

Має бути надано можливість згенерувати сертифікат для другого бустера (додатково до функціоналу сертифікатів про первинну вакцинацію та перший бустер).

Кейси щодо вакцинації другим бустером в Україні див. у Бізнес-вимоги Другий Бустер (business requirement) Бізнес-вимоги Другий Бустер (business requirement) | Таблиця передумов та наслідків

Передумови

1. Запис про вакцинацію має валідний статус (status != "entered_in_error":"Внесений помилково") та not_givent = false та vaccination_protocols != null

2. Код вакцини повинен дорівнювати значенню з конфіг-файлу (vaccine_code = acceptable-vaccine-codes)

3. Визначено, якому запису з “Довідника вакцин проти КОВІД” (dgc.vaccine_metadata) відповідає вакцина, яка зафіксована в поточному записі про імунізацію, та розпізнано лот вакцини (lot_number)

4. Бустерная доза - це доза яка має:

   1. Пояснення причин вакцинації дорівнює значенню з конфіг-файлу reason_explanations={booster-reason-code: "immunization_by_calendar,immunization_by_condition,immunization_by_epidemic_indicators"}

   2. ТА значення порядкового номеру дози (vaccination_protocols.dose_sequence) и загальної кількості у серії (vaccination_protocols.series_doses) = 1/1

   3. ТА первинне джерело primary_source = true або, якщо primary_source = false, тоді вимоги до первинного джерела без змін (детально DCC v2 - CR. Primary_source 2.0)

   4. ТА дата запису про імунізацію більше дати бустеру в конфігфайлі date > booster-applicable-since - конфіг має бути видалено з логіки як такий що втратив актуальність

Зміни

1. Конфігурація booster-applicable-since має бути вилучена з логіки, такиии чином будь-який запис про вакцинацію 1/1 може бути як бустером так і повною дозою (для однодозних вакцин_ без обмежень за датою

2. Дози, що відповідають розділу передумов, отримують проміжний СтанОбробкиЗапису = “пре-бустер”

3. СтанОбробкиЗапису = “пре-бустер” доз може бути будь-яка кількість: 0..*

4. При наявності “пре-бустер” дози вибудувати перелік в хронологічному порядку

5. Доза в СтанОбробкиЗапису “Пре-бустер” з найменшою датою повина бути оцінена алгоритмом за існуючими правилами (а саме - перевірена передумова наявність етапу “повний цикл вакцинації” та часової відстані між ними відповідно до booster_config де connection = ‘booster_1’) та в випадку позитивної перевірки набути СтанОбробкиЗапису = “Бустер_1“. У випадку якщо не вдалося присвоїти даній дозі статус “Бустер_1” необхідно взяти наступну за порядком дозу із статусом “пре-бустер”. Доз із статусом “Бустер_1” може бути не більше 1 : 0..1

6. Кожна наступна із наступних “пре-бустер” доз, має бути порівнена з датою запису про вакцинацію, який має СтанОбробкиЗапису = “Бустер_1“. При цьому використовуються правила з booster_config де connection = ‘booster_2’

   1. Перевіряється комбінація між значеннями “mp” вакцин на допустимість mp_last_dose, mp_booster_dose - згідно з таблицею бустерної конфігурації (значення для порівненої дози та відповідної пари значень mp_last_dose та mp_booster_dose - див. нижче зміни до таблиці ). Якщо комбінація валідна, то перейти до наступного пункту 5b. Якщо комбінація не валідна, то взяти наступну дозу із списку записів в СтанОбробкиЗапису “Пре-бустер” та повторити кроки п.5. Якщо записів не залишилося, то завершити цикл.

   2. Додатково перевіряється періоди між дозами. При цьому різниця (distance) між датою порівняної дози з дозою, що має СтанОбробкиЗапису = “Бустер_1“ знаходиться в межах конфігураційних параметрів (min_days_before<=distance<= max_days_before) згідно з таблицею бустерної конфігурації (dgc.booster_config), тоді такій дозі має бути присвоєний СтанОбробкиЗапису = “Бустер_2“. Доза “Бустер_2” може бути тільки одна. Всі інші записи із статусом “пре_бустер” мають отримати статус “неповний курс вакцинації”. Якщо перевірка не пройдена, то взяти наступну дозу із списку записів в СтанОбробкиЗапису “Пре-бустер” та повторити кроки п.5. Якщо записів не залишилося, то завершити цикл.

7. Для “Бустер_1” медичні дані формуються відповідно до актуальоної логіки для записів із СтанОбробкиЗапису = “Бустер_1”

8. На запис із СтанОбробкиЗапису = “Бустер_2“ має бути сформован блок медданих для подальшої передачі у ДІЮ

   1. "extention":[
      {
      "type":"booster",
      "value":"true"
      }

   2. vp, tg, mp, ma та co відповідно до розпізнанної вакцини за lot_number

   3. dn, sd - вирахувані на основі параметрів sequence_dose+1 та series_dose+1 запису зі СтанОбробкиЗапису = “Бустер_1”

   4. dt = даті запису про вакцинацію зі СтанОбробкиЗапису = “Бустер_2“

   5. dateFrom = даті запису про вакцинацію зі СтанОбробкиЗапису = “Бустер_2“

   6. dateUntil = dt + deactivates_after_days

Варіант схеми бізнес-процесу з умовами переходу по крокам TO BE зображена в бізнес-вимогах Бізнес-вимоги Другий Бустер (business requirement) | Варіант Схема з умовами переходу по крокам TO BE

Зміни до тексту помилок

Обробка помилок - без змін, але зміна в тексті помилки RESULT_STATUS=82. Текст помилки викласти в наступній редакції: “Відхилений: вакцинація проведена в іншій країні та/або невідомому ЗОЗ, що не відповідають чиному законодавству”

Доопрацювання таблиці бустерних конфігурацій dgc.booster_config

1. В таблицю DGC.booster_config додати одну колонку зі значенням номеру бустеру (наприклад, connection - тип даних text, not null,), в якій проставляється номер бустеру (наприклад, booster_1, booster_2), що вказан в колонці “mp, Booster dose”. Таким чином, інформація по другому бустеру буде заноситься в таблицю DGC.booster_config новими рядками. Алгоритм при визначені дози вакцини як другого бустера (а також третього, четвертого та наступних) буде брати значення mp по першому бустеру з колонки “mp, Last dose”, а значення mp по другому бустеру з колонки “mp, Booster dose” та буде приймати всі необхідні значення цього рядка як бустер, номер якого вказано в connection.

Примітка. При додавані нового поля connection всім записам проставити значення connection = ‘booster_1’

1. Доопрацювати поля dn та sd: можуть бути null.