NPHCDA Immunization FHIR IG
1.0.0 - ci-build
NPHCDA Immunization FHIR IG, published by https://nphcda.gov.ng. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/Nigeria-FHIR-Community/ImmunizationIG/ and changes regularly. See the Directory of published versions
A business process, or process, is a set of related activities or tasks performed together to achieve the objectives of the health Programme area, such as registration, counseling, and referrals. Workflows are a visual representation of the progression of activities (tasks, events, and interactions) that are performed within the business process. The workflow provides a story for the business process being diagrammed and is used to enhance communication and collaboration among users, stakeholders, and engineers.
The business processes here have been informed by WHO Digital adaptation kit for immunizations.
# | Process Name | Process ID | Personas | Objectives | Task Set |
---|---|---|---|---|---|
Title | ID used to reference this process throughout the DAK | Individuals interacting to complete the process | A concrete statement describing what the process seeks to achieve | The general set of activities performed within the process | |
A | Health Facility Registration
![]() |
IMMZ.A | System administrator | All vaccinator locations (public and private facilities) able to administer vaccines should be registered and uniquely identified to allow appropriate tracking of vaccine coverage and stock. |
Starting point: The system administrator registers a new vaccination location (e.g, a PHC).
|
B | Plan immunization session
![]() |
IMMZ.B | Health worker | In preparation for a vaccination session, ensure sufficient supply and plan their workload. |
Starting point: The health worker reviews vaccination records to determine vaccine needs estimates.
|
C | Client Registration
![]() |
IMMZ.C | Health worker | To create, retrieve and/or update a Client's lifelong vaccine record in the EIR (or Immunization module in EMR) to support future vaccine administration. |
Starting point: The Client arrives at the vaccination point and the health worker locates the client’s immunization history.
|
D | Administer Vaccine
![]() |
IMMZ.D | Health worker | To determine what vaccines a Client needs, administer those and record the data both in the system and the client’s home-based vaccination record. |
Starting point: The Client has been registered in the system.
|
E | Manage and Report AEFI
![]() |
IMMZ.E | Health worker | To monitor, record, and report AEFI. |
Starting point: The Client reports AEFI or present with AEFI complaint at health facility
|
F | Client reminder
![]() |
IMMZ.F | Health worker | This is to remind clients that it is time to return for vaccination. |
Starting point: The Client’s records are evaluated to determine if they meet the defined criteria to recieve reminders.
|
G | Defaulter tracking
![]() |
IMMZ.G | Community health worker | To identify clients that are overdue for follow-up. |
Starting point: Clients are overdue for vaccination.
|
H | Report generation
![]() |
IMMZ.H | Health worker | To provide data access and analysis for decision-making. |
Starting point: Define the reporting parameters.
|
I | Resolve duplicate Client records
![]() |
IMMZ.I | Health Facility Systems Administrator | To ensure accurate and unified client data by identifying and merging duplicate records. |
Starting point: Flag duplicate client records for evaluation and resolution.
|
J | Resolve duplicate vaccination events
![]() |
IMMZ.J | Routine immunization service provider | To maintain reliable immunization records by detecting and resolving duplicate vaccination entries. |
Starting point: Identify groups of vaccination events for evaluation and resolution.
|
Symbol | Symbol Name | Description |
---|---|---|
![]() |
Swim lane | Each individual or type of user is assigned to a swim lane, a designated area for noting the activities performed or expected of that specific actor. For example, a family planning health worker may have one swim lane; the supervisor would be in another swim lane; the clients/patients would be classified in another swim lane. If the activities can be performed by either actor, then those activities can be depicted overlapping the two relevant swim lanes. |
![]() |
Start event or Trigger event | The workflow diagram should contain both a start and an end event, defining the beginning and completion of the task, respectively. |
![]() |
End event | There can be multiple end events depicted across multiple swimlanes in a business process diagram. However, for diagram clarity, there should only be one end event per swim lane. |
![]() |
Activity, Process, Step or Task | Each activity should start with a verb, e.g., “Register client”, “Calculate risk”. Between the start and end of a task, there should be a series of activities noted - in the successive actions performed by the actor for that swim lane. There can also be sub-processes within each activity. |
![]() |
Activity with sub-process | This symbol denotes an activity that has a much longer sub-process, to be detailed in another diagram. If the diagram starts to become too complex and unhelpful, the sub-process symbol should be used to reference this sub-another process depicted on another diagram page. (Activity with sub-process in grey box is not covered in this DAK). |
![]() |
Sequence flow | This symbol denotes the flow direction from one process to the next. The end event should not have any output arrows. All symbols (except the Start event) may have an unlimited number of input arrows. All symbols (except the end event and the Gateway) should have one and only one output arrow, leading to a new symbol, looping back to a previously used symbol, or pointing to the End event symbol. Connecting arrows should not intersect (cross) each other. |
![]() |
Gateway | This symbol is used to depict a fork, or decision point, in the workflow, which may be a simple binary (for example, yes/no) filter with two corresponding output arrows or a different set of outputs. In this document, there should typically be only two different outputs that originate from the decision point. If you find yourself needing more than two “output” or sequence flow direction arrows, this is most likely trying to depict “decision-support logic” or a “business rule”. This should be depicted as an “Activity with business rule”. |
![]() |
Throw – Link | The “Throw–Link” serves as the start of an off-page connector. It is the end of the process when there is no more room on your page for that workflow. It is the end of a process on your current page or the end of a sub-process that is part of a larger process. When used, there will need to be a corresponding “Catch–Link” on the other page that shows the continuation of the workflow that follows the “Throw–Link”. |
![]() |
Catch – Link | The “Catch–Link” serves as an off-page connector. It is the start of a new process that follows a previous process, a continuation of a process from a previous page, on a different page from the “Throw – Link” or the start of a sub-process that is part of a larger process. Every “CatchLink” needs to align with at least one corresponding “Throw–Link” that is aligned to the prior process diagram “Catch–Link”. |
![]() |
Loop Activity | This “Loop Activity” or loop task symbolizes an activity or task that is repeated until it no longer needs to be repeated. For example, vaccine administration can happen as many times as the number of vaccines that need to be given. |
The overview of the business processes in this DAK captures all business processes at a high level.
Objective: To register and uniquely identify vaccination locations in order to administer vaccines and enable appropriate tracking of vaccine coverage and stock.
Objective: To prepare for an immunization session, either at the vaccination location or done at an outreach site.
Objective: To start the client’s lifelong immunization record.
Objective: To determine what vaccines a client needs, administer those, and record the data both in the system and on the client’s vaccination card.
Objective: To manage caregiver reports or client presenting at health facilities with cases of AEFI based on set triggers.
Objective: To send vaccination reminders to community health workers that certain clients are due for vaccination.
Objective: To identify clients that are overdue for follow-up
Objective: To provide data access and analysis for decision-making
Objective: To ensure accurate and unified client data by identifying and merging duplicate records.
Objective: To maintain reliable immunization records by detecting and resolving duplicate vaccination entries.