[Immunization] V2 Implementation details

[dubdabasoduba]

Immunizations Context

• Health workflows incorporate immunizations for children and sometimes adults.
• V2 of immunizations on FHIR core aims to make some changes to the Task Scheduling and Profile configuration pieces.
• This discussion will define the changes we need to make and explain why they are needed.

How are immunizations intended to work

• Tasks will be used to represent Immunizations on the FHIR Core. These will be displayed on the patient profile and
  the upcoming encounters screen.
  • The upcoming encounter screen is a new screen that will be accessed via the profile menus.
• The profile screen will only display DUE & OVERDUE tasks.
  • This means we will have to update the configs to filter all the tasks we fetch for this page.
• All the UPCOMING tasks will be displayed on the upcoming encounter screen.
  • The tasks displayed here will be grouped during display.
• The 2 screens below show the profile and the upcoming encounters.

Patient Profile	Upcoming Encounters

• The upcoming tasks that are 7 days to their DUE date will be displayed on the user profile screen.
  • All the upcoming tasks displayed on the profile screen will not be displayed on the encounters screen
• Immunizations are sometimes grouped based on the age they are to start. This means we will have to create different
  cards on both the encounter and profile screens.
• These cards will have a title (on the left side of the screen) and a button (on the right side of the screen).
  They will launch a form that allows the users to record the immunization data for all the DUE and OVERDUE
  immunizations in the group.
  • Clicking on the individual immunization tasks will also launch a form that allows the user to record the data for
    the individual tasks.

Record all form	Record individual form

• Sometimes immunizations have other immunizations as their prerequisites. Most of the time the dependent immunizations
  cannot be administered/recorded before the prerequisites are administered/recorded.
  • The dependent immunizations might have to satisfy a certain condition period after the prerequisites are given
    e.g. OPV1
    can only be administered after 28 days after OPV0
  • This means we need to dynamically change the dependent DUE date based on the prerequisites date of
    administration.

How we intend to implement the above rules.

• Since the immunizations are recorded as Tasks we will be making the changes to satisfy the required rules on the
  tasking modules on FHIR Core.
• We will also define a new screen for upcoming encounters.
• The sets below are categorized as Code & Content Changes
  • Code Changes -- Code updates are needed to achieve the feature
  • Content changes -- Content changes are needed to achieve the feature

1. [Immunization] How to define tasks dependencies | Content Changes #2141
2. [Immunization] How to define the task timing | Content Changes #2142
3. [Immunization] How to calculate DUE dates for dependent Tasks | Code Changes #2140
4. [Immunization] `Record all` form functionality | Code or Content Changes #2139
5. [Immunization] How to close Tasks based on the selected items on the Record All forms | Code or Content Changes #2143
6. [Immunization] Upcoming Encounters Screen definition | Content Changes #2144
7. [Immunization] Defining Immunization dosages and propagating them to all the relevant resources | Content Changes #2765

Assumptions

• The current profile configuration work is adequate to define the Upcoming Encounters screen.
• The immunizations are grouped based on the patient's age.
• The immunization DUE, OVERDUE and EXPIRY status are based on the patient's age.
• The StructureMap author has correctly written the extraction to provide all the information needed for the dependency
  mapping.

Unscoped items

• Medical history page to show all the recorded/administered immunizations. @HenryRae and I to finalize its design then
  we can add it's scoping.

[pld]

Want to clarify some things, under code changes, when you say

• "The worker should only run if" isn't it that the worker always runs, but the below specifies what Tasks the worker searches for to update?
• Are these 2 bullets saying the same/an equivalent thing?

• The dependent task has an input.type attribute defined with
  the {"coding":[{"system":"http://snomed.info/sct","code":"900000000000457003","display":"Reference set attribute (foundation metadata concept)"}]}.
• The Task should also have the prerequisite tasks referenced on the input attribute with the reference code
  on the input.type attribute.
  • Here is an example {"type":{"coding":[{"system":"http://snomed.info/sct","code":"900000000000457003","display":"Reference set attribute (foundation metadata concept)"}]},"reference":"Task/"}.

• How is the "Immunization recording form" linked to the Task?
• Can we make explicit somewhere that the value in Task.input.value is in days?

For the "How the Record All form should work | Code or Content Changes" section, let's clarify that the task is to attempt to do with content only, if there's a blocker, report back to discuss, if we can't resolve we'll figure out a code solution, but not without sign-off.

For "Upcoming Encounters Screen | Code Changes" why can't we do this with the existing Profile configurations? Or, it sounds like we can w/this assumption, "The current profile configuration work is adequate to define the Upcoming Encounters screen.", what's the code change here?

[pld]

I'm gonna lock this, since you broke it down into multiple items