request for proposal rfp # 2015-048 - path: driving … · · 2015-07-09request for proposal ....

Request for Proposal RFP # 2015-048

Better Immunization Data (BID) Initiative, Zambia Immunization Registry

I. Summary of Deadlines

Release of Request for Proposal July 10th, 2015

Confirmation of interest email and fact-finding questions submitted by July 17th, 2015

Responses to fact-finding questions sent to all interested parties July 24th, 2015

Proposals due by 5pm PDT August 14th, 2015

Announcement of decision August 28th, 2015

II. PATH Statement of Business PATH is the leader in global health innovation. An international nonprofit organization, we save lives and improve health, especially among women and children. We accelerate innovation across five platforms—vaccines, drugs, diagnostics, devices, and system and service innovations—that harness our entrepreneurial insight, scientific and public health expertise, and passion for health equity. By mobilizing partners around the world, we take innovation to scale, working alongside countries primarily in Africa and Asia to tackle their greatest health needs. Together, we deliver measurable results that disrupt the cycle of poor health. Learn more at www.path.org. III. Project Background and Purpose of RFP A. Project Background: Led by PATH and funded by the Bill & Melinda Gates Foundation, the BID Initiative is grounded in the belief that better data, plus better decisions, will lead to better health outcomes. Its vision is to empower countries to enhance immunization and overall health service delivery through improved data collection, quality, and use. Reaching this vision requires investments in information system products, practices, people, and packaging. In Zambia, the BID Initiative is collaborating with the government through the Ministry of Community Development, Mother and Child Health (MCDMCH) whose vision is to be “Pioneers in the provision of integrated social protection and primary health care”, and mission is, “To effectively and efficiently facilitate the provision of equitable social protection and quality primary health care services to communities in order to contribute to sustainable human development.”

of 43

http://www.path.org/

The BID Initiative is unique. It is designed to partner with countries in Africa through the BID Learning Network (BLN) (see http://bidinitiative.org/bid-learning-network/) to introduce information system products and immunization practices that can be tested in a few demonstration countries, packaged for dissemination, and then deployed at scale in many countries. The BID Initiative also starts with the premise that it will build new information system products or practices only as a last resort. Instead, investments will be made to embrace and extend existing information system products and investments already made by donors and national governments in immunization best practices wherever possible. B. Purpose of the RFP: PATH is soliciting proposals from qualified vendors to provide software development services to cover identified gaps of pre-selected immunization registries and fulfill the requirements of the government of Zambia, MCDMCH. The immunization registry is to be scaled nationally and help manage the routine immunization of approximately 782,000 new children born every year as well as any carryover from the previous year. Zambia’s MCDMCH has strengthened its immunization programs, yet systemic problems such as identifying the under-vaccinated and unvaccinated children continue to stall efforts. Zambia continues to face challenges related to data quality and has identified a few of the challenges such as: incomplete or untimely data, multiple vertical data collection systems, complex data collection forms and tools, insufficient supply chains and logistics management, inadequate data management and use capacity throughout all levels of the health system, inaccurate or uncertain denominators for calculating immunization rates, difficulty identifying children who do not start immunization or who drop out (defaulter tracing), and poor data and stock visibility into supplies at the facility level to district level. The challenges of high priority include the following:

Accurate denominator

The source used to estimate the number of clients for each clinic is provided by the Central Statistics Office (CSO). However, in practice, the actual client numbers in any given catchment area often vary widely from the estimated numbers.

Defaulter tracing

Ability to identify children that may not have received their full dosing regimen/vaccine for the designated age within the past one month.

Unique identification of

children

Often, individuals are associated with a particular health facility. If they receive services from another clinic, their full immunization history may not be captured accurately.

Complexity of data collection

forms

The complexity of data collection and reporting forms increases the work burden on health workers and the chances of errors.

Data visibility

It is practically impossible to review data from clinics at the village or even district levels, especially stock status, defaulters and children due for immunization in each month.

Vaccine supply chain

Manual and paper-based vaccine information management systems make it difficult to ensure accurate monitoring of vaccine stocks, receipts, and deliveries. The goal is to minimize under and over-stocking at all levels of the supply chain system.

of 43

http://bidinitiative.org/bid-learning-network/

Information systems and a culture of evidence-based decision making that would help solve these operational issues and provide actionable information to users are unfortunately very weak in Zambia. While technological capabilities and internet/network connectivity are improving rapidly in Zambia, effective and affordable information systems that automate national immunization data collection and support delivery of routine child health services (e.g., immunizations, nutrition screening, and counseling) for health workers have not yet been built or deployed at scale. Information and computer technology (ICT) systems for the national health management information system (HMIS), monthly immunization reporting, and supply chain logistics are not interoperable with one another nor linked into an emerging national-level eHealth architecture. IV. Scope of Work This RFP is soliciting competitive proposals to conduct the following scope of work with the following deliverables:

1. Evaluate the appropriate fit of DHIS2 Tracker against the current set of business

processes, requirements, and the Key User Scenario defined by the Zambia MCDMCH and documented by the BID Initiative in Appendix A.

2. Enhance functionality of DHIS2 Tracker and supply chain solution to fulfill the requirements in Appendix C.

3. Working closely with the BID Initiative team and using an agile or iterative design methodology, work towards a final system design and development.

4. Provide training of trainers and key staff on the functioning, troubleshooting, and maintenance of the system.

5. Provide documentation in the form of user manuals and troubleshooting guides. 6. Migrate of system to selected data center from the development environment.

The overall deliverable is a fully functional immunization registry and supply chain system that meets the minimum requirements specified in Appendix C. The quality of the system shall at minimum be a product that addresses the non-functional requirements in Appendix E and be a product that can potentially extended to future functionality. Future extensions and functionality would be expected to be in alignment with the country’s eHealth strategy, which can be found at http://www.who.int/goe/policies/countries/zmb_ehealth.pdf?ua=1. Considerations and Guidance for System Development

The Government of the Republic of Zambia (GRZ) has indicated that they would like a national immunization registry based on DHIS2 tracker (https://www.dhis2.org/individual-data-records). Zambia also has an existing electronic record system called SmartCare which has been deployed in a number of facilities throughout the country. The overall solution will require immunization-level data to be shared between DHIS2-Tracker and SmartCare through an interoperability layer. Any required development on the SmartCare side to accommodate this will not be in the scope of this RFP. The BID Initiative supports interoperability and standards as one of its core principles. While Zambia does not have any published and officially adopted standards, in order to ensure the ultimate goal of interoperability, any solution will need to utilize internationally balloted standards. We have outlined our desired approach in Chapters 7 and 8 of the Product Vision document which can be found at: http://bidinitiative.org/wp-content/files_mf/1411080424FINAL_BIDProductVision09122014.pdf.

of 43

http://www.who.int/goe/policies/countries/zmb_ehealth.pdf?ua=1

https://www.dhis2.org/individual-data-records

http://bidinitiative.org/wp-content/files_mf/1411080424FINAL_BIDProductVision09122014.pdf

http://bidinitiative.org/wp-content/files_mf/1411080424FINAL_BIDProductVision09122014.pdf

While we would consider other information system standards, there is a strong preference for the use of standards outlined in the IHE Patient Care Coordination Technical Framework in particular the Immunization Content component (Section 6): http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Rev10.0_Vol1_FT_2014-11-04.pdf. Therefore, the successful bidder will be expected to identify and incorporate interoperability requirements with existing systems and the expected functionality gaps (especially as it relates to functionality and interoperability with Zambia’s eHealth architecture), and propose how the selected system will incorporate these requirements and cover the identified gaps.

While we are open to a variety of potential architected solutions, we do anticipate a fairly substantial revision to the user interface and front end currently provided in DHIS Tracker. This is driven in part by the requirement to pass data through an interoperability layer, as well as the need to function offline for significant periods of time (such as a month). Offline devices will be required to sync between devices in the same facility. We do understand the challenge this poses, and are open to solutions that range from peer networks to manual syncing through an intermediary device such as an external hard drive. Solutions that require the use of a local area network (LAN) or local wifi connection will not be considered as these are not available in most facilities. Protection of Personal Health Information Zambia is concerned about the protection of personal health information (PHI). While there are currently no formal laws, policies, or guidelines regarding the protection of personal health information in Zambia, it is the position of the BID Initiative, supported by the GRZ, that any electronic information systems shall conform to generally accepted international norms on the protection of PHI. These include the incorporation of the following elements:

• Role-based security and access • Password protection • Audit logs of individual activities • The protection of data at rest • Encryption

While this list is not exhaustive, it is fairly representative. These items will also appear in the non-functional requirements in Appendix E. Systems that are Health Insurance Portability and Accountability Act (HIPAA) compliant for example, would be considered suitable although would not be the only appropriate guideline considered.

Hosting The GRZ requires that the servers hosting PHI should be located in country. They also have a preference (although not a mandatory requirement) for hosting to be held at the government’s Zamtel data center. Arrangements and hosting setup will be out of scope for this RFP. However, we would expect that the migration to this data center from the development environment would be in scope. Equipment Specifications Responses to this RFP must take into consideration a cost-conscious approach for the intended purchase of tablets and phones. An open source platform such as Android is preferred. The

of 43

http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Rev10.0_Vol1_FT_2014-11-04.pdf

http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Rev10.0_Vol1_FT_2014-11-04.pdf

government requires this approach in order to plan for national scale at a sustainable cost. A survey of available devices in Zambia done by the BID Initiative team currently available at the lower price points indicate the following general specifications for a tablet:

• Resolution of 1280x800 • Available 3G- battery life of 6 to 8 hours • A minimum of 1.2GHz processor • Screen size between 8 to 10.1 inches (20.3 to 25.6 cm).

The standard specifications for an android phone should include:

• Resolution of 1280x800 • Available 3G • A minimum of 1.2GHz processor • A minimum of a 1.3MP camera • Screen size between 5 to 7 inches (12.7 to 17.8cm).

While these are just initial guidelines, proposed solutions should be developed with these specifications in mind.

We do not expect one system to serve as both an immunization registry and a full stock management system. Some stock functionality, particularly as it relates to facility-level stock, may be incorporated into DHIS2. We would also anticipate being it being integrated to, or interoperable with, a more fully functioning electronic Logistics Management System (eLMIS). Please include in your proposal how you would plan to achieve this current integration/interoperability with stock requirements as well as for future integration with eLMIS. Reporting and Dashboards We envision the solution to help users and the Ministry to collect quality data, analyze, report, and use it for decision making. The system should provide some dashboard reporting functionality to help the users analyze and easily understand the data. The dashboards will be based on the data collected and the matching indicators provided by the Ministry. See Appendices F and G for examples of the types of dashboards, indicators, and data elements. For a sample of the facility reports, see Appendix H.

V. Proposal Requirements – Financial Provide itemized costs for the entire project based on the scope of work and deliverables outlined in Section IV. The final scope of work may be subject to negotiation. However, bidder selection will be made against the original scope of work. Bids should include itemized costs for key elements of the scope of work, including:

• Percent participation in total level of effort according to key staff. • Rates of key staff. • Estimated total level of effort and associated costs. • Itemization of all other costs, (e.g., agency costs, agency fees, service tax,

administrative costs, supplies, etc.). • Estimated schedule of anticipated expenses (e.g., travel, sub-contracted resources,

supplies, outside resources, etc.).

of 43

Special Note on Indirect Costs Indirect costs are overhead expenses incurred as a result of the project but not easily identified with the project’s activities. These are administrative expenses that are related to overall general operations and are shared among projects and/or functions. Examples include executive, existing facilities costs, accounting, grants management, legal expenses, utilities, and technology support. Indirect rate allowances: These rates are maximum allowances. If the organization has lower rates, the lower rates should be used. To the extent that indirect costs are applicable, they are subject to the following limits:

• Up to 10% for U.S. universities and other academic institutions. • Up to 15% for non-U.S. academic institutions, and all private, voluntary, and

nongovernmental organizations, regardless of location. • No indirect costs will be paid to U.S. government agencies, other private foundations,

and for-profit organizations. • Rates apply both to the primary grantee, sub-grantees, and sub-contracts that are part of

the proposal.

Please note, in so far as possible, identifiable (allocable) costs should be documented and justified in the proposal as direct costs, including those for dedicated ongoing project management and support. Newly acquired facility costs that can be allocable to the project are acceptable as direct costs. VI. Proposal Requirements – Technical

Provide a narrative on your technical approach to accomplish the scope of work and deliverables per section IV, including:

• Description of software development approach. • Discussion of project management and roles of project team. • Timeline to meet the deliverables. • Potential obstacles and plan to overcome them. • Identification of major internal and external resources. • Overall capability and capacity related to the scope of work and Key User Scenario

described in Appendix A. • Responses to vendor questions (as applicable) listed in Appendix B. • Evaluations of current immunization registry and supply chain requirements against the

requirements listed in Appendix C. • High-level system architecture showing how different components fit together. • Description of the existing or planned standards that will be utilized and supported.

Provide information on your overall qualifications, including:

• Profile of relevant organization qualifications. • Profile of relevant experience and examples of related work. • Qualifications of key members of the proposed project team (attach CVs and provide

details of back-up/standby teams). • Number of years in business.

of 43

• If your organization has more than one location, please indicate these qualifications for the site that is responding.

VII. Proposal Evaluation Criteria The following is a list of significant criteria against which proposals will be assessed. The criteria are listed in order of priority, however they are not weighted.

1. Technical a. Able to develop and release beta version by March, 2016. b. Software development methodology used. c. Proposed work plan. d. Commitment to documentation. e. Project management and project progress-monitoring and reporting systems. f. Demonstrated understanding of the requirements.

2. Experience a. Past experience in related projects. b. Experience of proposed project management and technical staff. c. Number of successful implementations.

3. Costs (as detailed in Section V) a. Total cost compared with other bids. b. Annual maintenance cost.

Note: PATH reserves the right to include additional criteria. VIII. Instructions and Deadlines for Responding A. PATH Contacts Procurement Contact: Keith Neroutsos, [email protected] Program Contact: Kelly Fallt, [email protected] B. Confirmation of Interest Please send a statement acknowledging receipt of this solicitation and your intent to respond or not respond no later than July 17th, 2015. Send the confirmation to the contacts listed above. C. Fact-finding Questions Questions on this solicitation will be accepted via email to the contacts listed above through July 17th, 2015. All submitted questions and answers will be provided to all participants who confirmed interest per Section VIII.B on July 24th, 2015. Please note that responses will not be confidential except in cases where proprietary information is involved. Inquiries after this date cannot be accommodated. D. Proposals Due: August 14th, 2015 by 5pm PDT Completed proposals should be submitted by email to the contacts listed above. The subject line of the email should read: RFP# 2015-048 -Better Immunization Data (BID) Initiative Zambia Immunization Registry (your organization name). We advise that you send files and documents commonly recognized by Microsoft Office or PDF format. We will not accept responsibility for resolving technical transmission problems with proposals. A hard copy of the proposal should not be sent. Your proposal should only include information specific to accomplishing the scope of work. Additional information submitted outside of the proposal requirements will be reviewed at PATH’s discretion only.

of 43

mailto:[email protected]

mailto:[email protected]

E. Selection of Short-list PATH reserves the right to select a short list from the bids received. PATH has the option to interview and discuss specific details with those candidates who are on the short-list. F. Conclusion of Process Applicants will be notified of PATH’s decision by August 28th, 2015. Final award is subject to the terms and conditions included in this solicitation as well as successful final negotiations of all applicable terms and conditions affecting this work. IX. Terms and Conditions of the Solicitation A. Notice of Non-binding Solicitation PATH reserves the right to reject any and all bids received in response to this solicitation and is in no way bound to accept any proposal. B. Confidentiality All information provided by PATH as part of this solicitation must be treated as confidential. In the event that any information is inappropriately released, PATH will seek appropriate remedies as allowed. Proposals, discussions, and all information received in response to this solicitation will be held as strictly confidential, except as otherwise noted. C. Communication All communications regarding this solicitation shall be directed to appropriate parties at PATH indicated in Section VIII. A. Contacting third parties involved in the project, the review panel, or any other party may be considered a conflict of interest and could result in disqualification of the proposal. D. Acceptance Acceptance of a proposal does not imply acceptance of its terms and conditions. PATH reserves the option to negotiate on the final terms and conditions. PATH additionally reserves the right to negotiate the substance of the finalists’ proposals as well as the option of accepting partial components of a proposal if appropriate. E. Right to Final Negotiations PATH reserves the option to negotiate on the final costs and final scope of work. PATH also reserves the option to limit or include third parties at its sole and full discretion in such negotiations. F. Third-party Limitations PATH does not represent, warrant, or act as an agent for any third party as a result of this solicitation. This solicitation does not authorize any third party to bind or commit PATH in any way without our express written consent. G. Proposal Validity Proposals submitted under this request shall be valid for 90 days from the date the proposal is due. The validity period shall be stated in the proposal submitted to PATH.

of 43

Appendix A: Key User Scenario – Administer and document care [Adapted from BID Initiative. Product Vision for the Better Immunization Data Initiative. Seattle, WA: PATH; 2014.] Administering and documenting care, that is immunizing children and keeping their health records current, is one of the most important stages of the immunization system. Updating the forms and processes used during this stage in order to improve data quality and ease of collection is a significant focus of the BID Initiative. Moving from a backward audit log to a forward-looking action list is a fundamental change in how information is used to support the immunization system. We envision one option for busy clinics (see section below on “applying techniques to busy clinics”) where the health worker will enter data online in real time. The system has been redesigned in the following ways:

• It identifies which children/clients are expected for their immunizations in the upcoming month.

• It makes it easy to record that the child/client received their scheduled vaccines by using check boxes as well a way to record other key data (e.g., demographics, weight, dates, etc.).

• It provides an action list which includes the name of the mother, child, and village (and potentially other data points) which will help identify and follow up on defaulters.

• It incorporates stock data to help identify any potential shortages based on actual and projected consumption.

User Workflows

1. Capture birth data. A community health worker (CHW), volunteer, or village representative collects basic information about births that do not occur in a clinic and sends the information via short message service (SMS) to the electronic immunization registry where it will be added to the national database. The system will have the ability to allow the facility to register community health workers under their mobile numbers which will be used to conduct registration. This means the CHW is associated with the facility they are registered under and the data will allow the births they register to be associated to that facility. Once the birth data has been added, it will be included in future reports. The system must be able to process a birth registration sent via a coded SMS message. It must also be able to process the same registration done by accessing the system directly (in online or offline mode). The system will assign a temporary ID to the new registration as a placeholder for the child in the system.

2. Assign, add, and manage identification numbers. A medical attendant or nurse at a health clinic assigns a permanent identification number to each baby who goes to the clinic who does not already have one. These unique IDs will be obtained from a list of preprinted ID barcoded stickers (with human readable ID number) that will be generated centrally (either by the system or through another system), and distributed to the facilities. This will be affixed to the child health card and updated electronically either online or offline (for later synching). There will also need to be functionality to maintain and manage IDs including the management of duplicates, the warning that an ID has already been assigned, and methods by which an ID can be inactivated. This functionality will largely be an administrative function, not done by the typical nurse end user.

of 43

3. Capture patient data. The medical attendant or nurse records the weight for each child and date of immunization administered. This data is stored in the child’s electronic health record inside the immunization registry. For children who are not immunized, the medical attendant records their weight on a simple tally sheet. All children seen at any health clinic will have their data entered online in real time.

4. Compile district-level reports. The District Health Information Officer (DHIO) or the Maternal and Child Health (MCH) Coordinator will use the electronic immunization registry to summarize the data for monthly reporting for the various national systems and to provide input for immunization supply chain needs.

5. Defaulter tracing. The system will need to generate SMS reminders when a child has missed an appointment. This reminder will be sent to the caregiver on the number associated to that child’s record. In addition to SMS reminders, the system should be able to produce reports (on demand as well as scheduled), showing all children that are late for a vaccine within a given facility’s catchment area. See Figure A-6 for the workflow diagrams.

Figure A-3. Administer and document care.

Sim

oong

aSi

moo

nga

clin

icLi

ving

ston

e

Villa

geH

ealth

clin

icD

istri

ct

Start

1. Report births in village to clinic via SMS.

eHea

lth

Infr

astr

uctu

re

Imm

uniz

atio

n re

gist

ry

2. Assign unique identification number to

newborns.

3. Check for and flag duplicate records or if ID already assigned to a record. Delete or Merge if required, or assign another ID

4. Capture patient data (i.e., weight) in

electronic health record.

5. Submit monthly report to DHIO and

create follow-up action list.

6. Compile district-level reports and submit to

eHealth database.End

Health Impact Improving the documentation of care administrated in the clinic and later using these data to guide decision-making is the key to success of the overall BID Initiative. The refinements discussed in this section will:

• Help address the “denominator problem (Figure A-4),” thereby yielding better data regarding the true number of children who need vaccinations in a given area and assisting with national planning.

• Minimize non value-added data entry and tallying currently required from nurses and front-line caregivers. Instead, this data will be parsed from the data capture sheet and readily summarized and aggregated by the immunization registry. The aggregated results regarding immunizations will be generated by summarizing these data. Similarly, data regarding vaccine inventory consumption will be developed based on the immunization “transactions”. Wastage will be calculated based on the physical counts

of 43

logged at the time of inventory replenishment. As long as these wastage values are not outside of expected ranges, further analysis will not be required.

Applying Techniques to Busy Clinics In a busy clinic, there will often be queuing on first come first serve and batching for babies due for BCG or other vaccines. One of the goals of the BID Initiative is to leverage useful technology and process redesign interventions to help improve the immunization workflow where it is practical to do so. There are opportunities to manage the work in a busy clinic in a way that helps increase efficiencies throughout their work to serve more children more quickly. To leverage techniques and make use of available technologies, a suggested workflow design is depicted in Figure A-5. Note that all the information collected from the immunization activities is meant to support decision making.

• The red arrows indicate physical flows of people and vaccines.

• The green dotted arrows indicate information flow.

• The yellow arrow at the top-left of the diagram indicates a one-time data entry process.

The Denominator Problem Calculating the true number of children to be vaccinated in a given year can be difficult. This challenge is often referred to as the “denominator problem.” The denominator is the total number of children in an area used to calculate the coverage percentage required. For example, if the catchment of children under one year of age is 200 and the facility has fully immunized 100 of them, the fully immunized coverage rate is 50 percent. Since this number is often used for reporting, resource planning, and stock calculations, it can have a serious impact if it is incorrect. Another aspect of this problem is the referral to percentages and not individual children. Finding the 20 percent of children who are not immunized in an area is very different than finding a list of 30 specific children by name who are not immunized.

Figures A-4. The denominator problem.

Figure A-5. Suggested immunization workflow (busy clinic).

1

2

3

4

5

6

7

8

9

10

of 43

1. The mother brings her baby to be immunized. Upon arriving at the immunization clinic,

the barcode on the baby’s immunization card is scanned. • If the mother does not have an immunization card or if she has a card without a

barcode, a health care worker or a volunteer at the clinic will manually enter the baby’s demographic information into the immunization registry and generate a barcoded identification card. After this one time process and for each subsequent visit, the mother will be able to move through the workflow as described below.

2. Mother and baby join the queue waiting for the baby to be weighed. 3. Based on the barcode identification, the baby’s child health record is retrieved from the

immunization registry system and loaded onto the tablet computers used by the nurses. 4. When the baby is weighed, the barcode identification is again scanned, displaying the

baby’s health record on the nurse’s tablet computer (or laptop, or even Smartphone) and indicates if the mother is to proceed along the “fast path” or the “slow path”. Regardless of the path, the baby’s weight is recorded on the immunization card and entered on the tablet computer, which saves it to the immunization registry.

5. If the mother is on the fast path, she either joins the immunization queue or she is reminded of her baby’s next visit and she is free to leave.

6. If the mother is on the slow path because the child’s weight was not within desired limits, she is counseled appropriately and then she joins either the immunization queue or she is reminded of her baby’s next visit and she is free to leave.

7. The appropriate vaccine inventory is moved to the immunization room based on information from the eHealth system based on the babies that are due to receive immunizations.

8. The nurse calls babies from the immunization queue into the immunization room on first come first serve and/or in groups for babies receiving BCG and/or OPV0 to receive their doses. The nurse groups these babies who are receiving the same immunizations to improve throughput and reduce medical errors.

9. The immunizations given to each baby are recorded on the baby’s immunization card and updated to the immunization registry. The mother is reminded of the timing of the baby’s next immunization visit.

10. After the baby is immunized, and the mother has waited to ensure there are no adverse effects, the mother and baby are free to leave.

Health Impact There are several positive effects from this updated workflow:

• The average duration for mothers whose babies do not require immunization will go down by segregating fast and slow workflows. Assuming there are no other issues that necessitate a counseling session (such as out-of-band weight off-scheduled visits), a well-baby visit will be very quick.

• We will be able to capture real-time information about the babies that are coming for vaccination and provide real-time feedback to the nurse about the baby’s immunization and overall health history. In a busy urban setting, this capability is especially important since mothers are more likely to receive care at multiple facilities over the course of the baby’s immunization schedule.

• The workload on nurses to separately capture and collate data for aggregated reporting is reduced. This task will be done automatically by the electronic immunization registry.

• For mothers that scan their babies’ card when they arrive but who do not, for whatever reason, complete the workflow, we will have a record of these “incomplete” events for follow-up.

of 43

• To support workflow analysis and improvement, we will also be able to compare time stamps between when a baby is scanned upon arrival, when they are scanned for weighing, and when they are scanned for immunization. Scan patterns will allow us to conduct useful industrial engineering analyses that can help inform future system improvements.

Defaulter tracing

The MCDMCH through the EPI program would like to pursue the use of SMS in the immunization program to improve coverage through registration of all home births and tracing and reminding all children that have missed a vaccine for a specified period from the due date. The system should have the ability to auto-generate SMS reminders/alerts for missed vaccination schedules to mothers/caregiver and contact person (e.g. CHW). The time between a missed vaccine and the reminder can be set by the administrator of the system. Rapid Pro will be the preferred platform for SMS functionality and the development of the system should put this into consideration although other solutions will be considered. The system should have the ability for messages to be supported and compatible on a mobile phone, support mobile query and updates through SMS application, and be able to support inbound SMS services or response messages from the mothers/caregiver and contact person (e.g. CHW). The query should be able to provide the latest transaction on the child stored on the system. Figure A-6. Defaulter tracing.

Sim

oong

aSi

moo

nga

clin

ic

Villa

geH

ealth

clin

ic

Start

CHW follow up defaulters

eHea

lth In

fras

truc

ture

Imm

uniz

atio

n re

gist

ry Send SMS to mothers who missed

immunizations

Produce list of defaulters

Followed up mothers Report to facility for

immunizationEnd

Stock Management Zambia currently has no vaccine supply chain electronic system to monitor stocks at all levels in the supply system and would like an electronic supply chain system to be part of the solution to address their current challenges.

of 43

The solution should be able to capture data of receipt and issue of vaccines into the system, and should take into account the use of barcodes to capture data at national, provincial and district levels to enter information such as:

• Vaccine details (e.g. batch numbers, lot numbers, expiration dates, and manufacturer information).

• Other information as applicable via use of forms.

The solution will be able to update stock information and balances at all levels of the system—national, provincial, district, and health facility (service center)—and provide pre-alerts based on configurable preset minimum, maximum, and buffer levels. Zambia envisions the solution to provide reports and information on supply chain in relation to the data in the immunization registry to allow for a level of decision making at all levels to forecast and plan better. The planning decisions will be based on actual data of vaccines given, births, wastage, and health workers, districts workers, and logisticians will be enabled to have visibility on the much needed stock information (now more accurate and reliable). The solution will fulfil the detailed requirements in Appendix C. National Vaccine Store The national logisticians receive vaccine stock, and then they or the cold chain personnel capture the details of stock received including batch number, lot number, expiration dates, manufacturer details, and quantities received by entering them into the system using a form for receiving stock or via a barcode scanning input device which will scan all vaccines secondary packages. The details of stock in the system are updated to include received stock and provide updated balances. The system should be able to show the stock levels down to the district level.

During distribution, the national level logisticians enter the quantities and stock details (which includes batch number, lot number, expiration date) as well as the location (i.e. province) to which the stock is being issued to via a form in the system. This entered information updates the balance of stock in the system with issued quantities deducted. The stock is then loaded into the trucks and transported to be delivered in the provinces with corresponding delivery notes. The logistician should have access to see the stock details that include (balance of vaccines, syringes and diluents, expiry date of vaccines) of the province and districts to monitor their consumption as this information is used for planning the ongoing distribution activities. The visibility into the stock levels of the district and province helps the logisticians determine the amount of stock to give as consumption can provide detailed justification, especially where a request of stock is being initiated by the province. The logisticians should be able to view a list of requisitions for stock made by the provinces in the system.

Provincial Vaccine Store Provinces receive stock quarterly as routine replenishments are sent to the provinces from the national level. Occasionally, there is also a need for an emergency replenishment. The requisitioning of the stock will be done electronically and supported by either an email/SMS or phone alerts when requisitioning is necessary. The cold chain manager/logistician receives stock at the province level and records details of the stock received into the system. The system will allow the province to match the barcode information of the stock with the identical one entered into the system at national level via a dropdown list. The details entered into the system update the stock balances with quantities and details of the vaccines received.

of 43

The logisticians acknowledges the receipt by signing the delivery notes to provide to the driver. In case of discrepancy or damages, these are documented and the applicable stock is not received. When receiving, they will only enter what they have received in the system. Once a month, the provincial stores will send stock to the districts and the amount will be determined by district average consumption, any additional order from district, and/or the capacity of their cold chain storage. Current stock levels at the provincial level should also be considered and displayed. The system should be able to produce a list of all active requisitions to help in decision making or prioritization around vaccine allocation. The system would be expected to produce a “pick list” of the required vaccines for each district to facilitate fulfilling the stock distribution that will be a printed report from the system. This list should be per district and should help ensure they are assigning the vaccines closest to their expiration date first. The province can requisition for stock by submitting the details of current stock available and quantities requested (all applicable details as completed on requisition vouchers currently), which is sent to the national logisticians via email, SMS, and/or be displayed in the system for logisticians to view. During distribution, the provincial logisticians enter the quantities and stock details (which includes batch number, lot number, and expiration date) as well as the district to which the stock is being issued to via a form in the system. This entered information updates the balance of stock in the system with issued quantities deducted and corresponding batch number or lot number which could be automated. The stock is then loaded into the trucks and transported to be delivered in the districts with corresponding delivery notes. The Province will require to see the stock information of the district and facilities in the system and monitor the consumption. The consumption data will come from the immunization registry (using Patient Tracker in DHIS2). There will be a need to be able to link the various levels of the health system to see stock levels throughout.

District Vaccine Store Districts receive their stock monthly although this usually depends on the availability of transportation. The cold chain manager/logistician at the district level receives stock and enters the details into the system using the forms for receiving stock, including the vaccine details (batch number, lot number, expiration dates, and quantities). The district should match the details on the form with what is in the system without having to re-enter details already captured in the system at national level. This information updates the stock details in the system. Once a month, the district stores will send the stock to the facilities (or possibly more often if facilities can come collect weekly or fortnightly). The requisitioning of the stock will be done electronically from district to province, but on paper from district to facility, and supported by either an email/SMS or phone alerts when requisitioning is due (See Appendix I for requisition voucher). However, the system should be able to produce a list of all active requisitions to help in decision making or prioritization around vaccine allocation. The system would be expected to produce a “pick list” of the required vaccines for each district to facilitate fulfilling the stock distribution. This list should be per facility and should help ensure they are assigning the vaccines closest to expiration date first. The “picking list” is then used to pack the facility cold boxes and for acknowledging receipt including discrepancies and/or damages where applicable. This information should also be captured in the system.

of 43

Facilities usually collect stock from the district office. The district officer will need to have updated information readily available to aid them in making the best decisions regarding distribution to facilities. This information includes:

• Their stock on hand at district level. • The previous consumption from the facilities (last month as well as monthly average). • Projected consumption for next month (based on immunization registry data). • Fridge capacity at the facility. • Facility stock on hand. • Predetermined buffer levels per facility. • Other delivery challenges that may alter decisions (such as rainy season, distance from

district, availability of transport, etc.) This data is known by the district officer and is not anticipated to be automated.

The district will enter the information/details of stock issued to the facility including quantities, lot number/batch number. This should be automated in a similar way to provincial to district automation. Facilities Facilities collect their stock from the district ideally weekly or fortnightly. However due to logistical or administrative challenges this is often done monthly. Facilities enter data of stock received into the system and details of the lot number and batch number as well as expiration dates for the vaccines. The immunization registry provides details of vaccines/doses given which deducts the balance of stock used from the balances, essentially updating information on consumption. As we envision most facilities operating offline for most of the month, the stock balances versus consumption will need to be a functionality of the immunization registry front end application. The system should also provide alerts on stock expiration including the details of VVM status for the in-charge or nurse at the facility to see updated information on the stock. (VVM status will need to be entered by the nurses). The system should be able to update information on calculated wastage of vaccines and also allow for capturing of other types of wastage (breakages, etc.). This may be done in either the supply chain system or the immunization registry depending on how the solution is architected. Figure A-7 and A-8 show workflows for distribution and inventory management. More detailed requirements are found in Appendix C. This stock management business process shows the activities taking place in distribution of vaccines from one level to the other. Distribution from district to the health facility is supposed to occur monthly. Inventory management refers to the activities that are taking place in managing vaccine stock at appropriate environment conditions and the right quantities without being under or overstocked.

of 43

Figure A-7: Vaccine Distribution to Service Delivery Point Business Process

Serv

ice

Del

iver

y Po

int

Dis

tric

t Co

ld C

hain

O

ffic

erV

acci

ne S

tore

Inch

arge

Start

Dis

tric

t St

ore

4. Estimate HF need

1. Prepare vaccine usage

report

2. Perform physical count

5. Pick From Stock Location

6. Update Ledger

3. Submit usage and stock on

hand

A

Serv

ice

Del

iver

y Po

int

Dis

tric

t Co

ld C

hain

O

ffic

erV

acci

ne S

tore

Inch

arge

Dis

tric

t St

ore

7. Document for Delivery

A

End

11. Record Receipt

12. Place in Stock

Yes

No

13. Update ledger

8. Inspect delivery 10. Reject 14. Notify district level

9. Damage/discrepancy?

of 43

General Process Notes Objective: Dispatch vaccines between stores or from a store to the health facility. 1. Prepare vaccine usage report • Order request often different from

monthly report. 2. Perform physical count • Record current stock. 3. Submit usage and stock on hand • Calculate required quantities based

on guidelines and rules. • Requisition form varies from none

to handwritten. 4. Estimate health facility need • Based on calculations, considering

minimum and maximum safety levels.

• May be push or pull model, need may be estimated by district MCH Coordinator or facility.

5. Pick from stock location • Stock is picked based on the

inventory control method (FIFO, FEFO).

6. Update ledger • Update ledger and SMT with new

quantity on hand after stock is picked for order.

7. Document for delivery • Issue voucher at district is

formalized but varies by location and completeness.

8. Inspect delivery • Perform physical inspection. • Monitor VVM status. • Check expiry date.

9. Record receipt • Double signatures on receipt. 10. Place in stock • After vaccines are checked and

approved, they are formally released to stock and moved into storage in the appropriate area.

11. Update ledger • Record receipt information on

ledger. • Best practices include adding lot,

expiration date, and VVM status. 12. Notify district level • Reject shipment if VVM status is

above threshold or if discrepancy in numbers.

of 43

Figure A8: Inventory Management Business Process

Vacc

ine

Stor

e

Stor

e ke

eper

Start

End

4. Record loss and

adjustments

No

5. Update Ledger

7.Estimate need

8. Issue emergency requisition3. Match running

balance Yes

6. Reaching re-order level?

Yes

No

2. Monitor Stock

Environment

1. Perform Physical count and checks

expiry

General Process Notes Objective: Manage vaccine inventory. 1. Perform physical count and observe expiry date • Perform physical count monthly at

district and regional level, every three months for National Vaccine Store.

• Perform physical check for damages.

• Check expiry dates. • Perform physical count of diluents. • Health facility records daily,

district/region records monthly, National Vaccine Store records every three months.

• Record temperature.

• Recording diluents with vaccine on ledger (best practice).

2. Monitor stock environment • Action based on fridge tag alarms

unclear. 3. Match running balance • Compare the number of unexpired

and undamaged vaccines with running balance.

4. Record loss and adjustments • Record the discrepancy as loss

and adjustments and the reason for the discrepancy.

• Loss and adjustments not always captured on ledger.

5. Update ledger, VCC and SMT • Update ledger, VCC, and SMT with

physical count quantity.

• Some bin cards in use. 6. Reaching re-order level? • Compare physical count quantity

with allowed minimum balance. 7. Estimate need • Calculate required quantities based

on guidelines and rules. • Regional/national levels: requires

counting diluents and syringes as well.

8. Issue emergency requisition • Create requisition based on

estimated needs. • Consider minimum and stock levels

safety levels. • Often via phone or travel to district

store.

of 43

Appendix B: Vendor Questions Question Response What is your largest

implementation? How many users? How many records in the database?

How many users can use the system at the same time?

What components of the proposed platform are proprietary? What components use commercial off-the-shelf software? What components are open source?

What service-level agreement for uptime do you guarantee each month? How many hours of maintenance is the system unavailable each month and when are those typically scheduled?

How often are updates or upgrades released?

How would you integrate with Zambia’s health information system (DHIS2)? Can you provide examples of how you have done this before?

Describe your approach and available features that provide security and privacy of data.

Describe your backup and restore functionality.

What training and support services do you provide?

What language(s) does your application support?

What is the annual maintenance and licensing fee? How much is this expected to increase annually?

of 43

Appendix C: Immunization Registry Requirements

ID Component System Requirement Fully Meets Part. Meets Planned N/A

1.1 Immunization Registry

Child is registered at birth in the maternity ward with minimum information.


Child is linked with the caregiver (likely mother) through a field (as an attribute of the child’s record).


Additional missing information about the child can be added later (e.g., at the first encounter in a health facility) in the system.


Has the ability to enter historical data upon first visit to health center (e.g. doses given at birth).


Has the ability to enter data from a flat file of back entered data (The exact fields in that file can be defined but will include demographic data, weights, immunization history, etc.).


Capture a time stamped audit of activities including: time of scan, time weight was entered, time of immunization, time user logged in and out. Also to include an audit of changes to administrative data such as edits to a facility record.

1.7 Immunization Registry Can update vaccines administered as separate a process.


Warn user if a child is being registered with the same first name, last name, date of birth, and gender as an already registered child.


Warn user if the ID being assigned is already assigned to another child.

of 43


Personal information-entered into the system includes identification data such as: First name (optional) Family name Mother (ref. or name) Place of birth (ref.) National ID (e.g. birth certificate) (OPTIONAL) Immunization ID / barcode Gender Date of birth Contact information (e.g. mother/caregiver mobile phone, village/street ) CHW/volunteer phone Caregiver name


Ability to register and update child records using SMS-based application.


Enforce field validation to refer to a reference table (ref.) of pre-populated values (e.g., villages within health facility capture radius or with in the country). Ability to allow administrator to prepopulate names of communities served by each facility.


Define communities, places of birth, and places of domicile, coverage areas, and any dependencies between them.


Search child records based on a combination of any of the fields used for child registration or given demographic information.


Maintain the status of a child record. This status field will be used for reporting and vaccination planning in other areas of the system.


Define which vaccines are offered by the national immunization program and at what age the respective doses are recommended. This must be able to be configured by an administrator.


Plan for the vaccination of a child in their respective areas with all the vaccines in the schedule. The system should help them determine which children are due or overdue at any given time.

of 43


Monitor the performance of the immunization program by comparing the immunized children to the number of children that live in their area.


Raise flag and generate performance alerts and reminders for facilities under-performing (e.g., below minimum coverage threshold, late or overdue report/forms submissions).


Support time-based and event-based reminders and automatic escalations to concerned users after a specified period of time.


Define the ideal age within the national vaccine schedule at which children should support three constraints (below). This should provide a warning message, however the provider can override the message to proceed anyway.


a) The minimum age before which a child is not eligible for a certain dose.


b) The maximum age beyond which a child is not eligible for a certain dose.


c) A minimum time that needs to pass between doses of the same vaccine.


In the event a provider overrides a warning message to provide a vaccine out of the recommended range, a reason should be given (based on a drop down list of choices, or a free text “other”).


Manage the vaccine schedule by defining the validity of a certain vaccine dose in the national schedule. This would allow a smooth vaccine introduction. For example, a country may decide to switch from pentavalent vaccine to hexavalent vaccine as of 1 Jan 2013. Pentavalent would then be the valid vaccine until 31 Dec 2012, while hexavalent becomes valid as of 1 Jan 2013. Typically, the birth date of a child, or date of first visit to the health center, will determine for which schedule (old or new) it is eligible.


Reproduce (display and print) a list of children requiring immunizations from a certain health center or district, with all the doses that are due and overdue over a specified date interval.

of 43


Calculate and display the number of doses that will be required to vaccinate all children in a certain health center or district over a specified date interval.


Update a child’s immunization record with the date of vaccination, the health center where the vaccination took place, and the vaccines and doses that were administered.


Ability to support mobile query and updates through SMS application.


Reproduce (display and print) a child’s vaccination history, together with all due and overdue appointments.


List vaccinations completed and not completed for a child according to schedule (vaccination card).


Reproduce (display and print) a coverage report that shows vaccination coverage as the percentage of the children living in a certain area, that were born in a certain timeframe, and that were vaccinated with a certain vaccine dose (cohort reporting).


Reproduce (display and print) a report that shows all vaccinations administered by dose, health facility, or group of health facilities (district, region, country).


Reproduce (display and print) a report that shows all children (born between specified dates and living in a certain area) that have missed at least one vaccination.

1.36 Immunization Registry Ability to maintain child’s caregiver preferred contact method.


Ability to print a list of children by filtering (specific date ranges, clinics, or villages) as well as “sort by” options.


Prevent all records given an inactive or deceased status from being included in the list of children for reminder/recall.

1.39 Immunization Registry Ability to track notification attempts and link back to a child’s record.

of 43


Ability to edit, update, and override child information such as change of address (moved permanently or temporarily).


Ability to allow a child record to be inactive for a selected timeframe (e.g., temporarily lost residence, crop harvest).


Produce a report that identifies all children due for a vaccination within the next month. The inputs to this report should be the national vaccination schedule (rules based on each vaccine), and the individual’s immunization record.

1.43 Immunization Registry Ability to report cases of adverse events.


Display a list of children who missed their immunization for each vaccine.


Allow the user or Ministry to specify immunization schedules and thresholds for a child to qualify as requiring follow-up.


Allow the user to print/export to flexible formats, a list of children requiring follow-up.


Allow the user to assign residence or lowest administrative location to a child (e.g. village, etc.).


Ability to generate and send a list of defaulted/overdue children to village leader or CHW.


Ability to auto-generate SMS reminders/alerts for missed vaccination schedules to mothers/caregiver and contact person (e.g. CHW).


Ability to query the database to determine the immunization status of a child using SMS.


Send a list of all children born in their area (that the village leader/Community Health worker/Volunteer has responsibility for) due for vaccinations prior to the first visit to a clinic.

1.52 Immunization Registry Categorize defaulter information by type of vaccine and location.


Allow for searching and matching on partial information (such as partial birthdates).

of 43


Allow searching for children based on family relationships or demographics.


Allow the user to search child records using immunization ID or barcodes.


Include results that look or sound similar to the search term (fuzzy logic), particularly for names.


Allow the user to select the health center of the child from a list as defined by the system administrator.

1.58 Immunization Registry Enforce a minimal data set to allow for a new registration.

1.59 Immunization Registry Uniquely identify every person in the registry.


Ability to automatically identify new child records as possible duplicates.

1.61 Immunization Registry Ability to automatically identify existing child records as duplicates.

1.62 Immunization Registry Flag duplicate records that require manual review.


Ability to combine two or more duplicate records according to business rules. (Note: Business rules should define which criteria to use to merge records (e.g., what information to keep from the duplicates).


Allow user to flag record as “not a duplicate” (Note: The system could believe records are duplicates, but they are not).

1.65 Immunization Registry Allow a record to have multiple alternate IDs.


When records are merged or combined, maintain a reference to the previous (or non-surviving) ID that could be found on search.

1.67 Immunization Registry Ability to prompt the user that the new vaccine is a duplicate.

1.68 Immunization Registry Ability to generate a list of possible child vaccine duplicates.

of 43


Ability to combine two or more duplicate event records (such as vaccinations or weights) according to business rules.

1.70 Immunization Registry Support an audit trail when event records are merged.


Support issues log, where user can escalate system-related issues to help desk and other non-system related issues (e.g. chores) to supervisors.


Support real time data entry validation and feedback to prevent data entry errors from being recorded.


Support the ability to calculate values on behalf of user (eliminating need to add, subtract, multiply, or divide).


Provide clinical decision support (e.g. recommend child for counselling based on weight entered/measured).

1.75 Immunization Registry Enable a task to be cancelled and rolled back to previous state.


Support the synchronization of devices that are offline and still in the same clinic (without the use of a LAN or other connection).


Support the synchronization of data between a facility device and the national system.


Trace and record changes to data taken by the system and by users (update/delete/add).


Ability to identify and present a list of folders, text, and documents (including metadata) that are eligible for destruction as a result of becoming irrelevant or reaching that phase in their lifecycle.


Allow users to create customized messages and ad hoc queries, set alerts, and create ad hoc assignments.


Ability to create and maintain reference to data (e.g. adding attachments (document, image, video, audio)).


Ability to record immunizations from children who are from other villages.

of 43


Record tally books for non-patient identified data (e.g. weight of children not receiving immunization; pregnant mothers receiving tetanus toxoid for women; vitamin A).


Ability to record that an immunization was given during an outreach campaign.


Allow facility to batch process number of children seen at same time (receiving same vaccine). The system should allow the user (nurse) to select a list of children that are receiving the same vaccine and have reported to the clinic as a batch and update their information accordingly.


Maintain a list of vaccines and other drugs that are provided in their country.


Ability to record and store data to be used for alerts and reports in offline mode.

1.88 Immunization Registry Ability to generate dashboards (see samples in Appendix F).


Ability to generate HIA2 report monthly (see Appendix H). This should be both printable as well as automatically imported into DHIS2.


Ability to produce details/report of vaccines/doses given in relation to stock on hand per batch or lot number in offline mode.

1.91 Stock Register stock counts, quantities of each vaccine, date of stock count, and possible item wastage for a certain reason.

1.92 Stock Create reports to display and visualize stock balances by health facility and compare to pre-set minimum and maximum levels.

1.93 Stock Show average consumption by health facility.

1.94 Stock

Show reported and calculated wastage Ability to allow administrator to populate and set wastage parameters and rates to be used in the system to report on wastage.

1.95 Stock Provide range estimates for vaccine need based on historical data (high and low ranges).

of 43

1.96 Stock Print list of necessary vaccines and accessories (syringes, wipes, etc.) based on projected need.

1.97 Stock Display availability of vaccines stock, where higher level of the health system will be able to view stock details at lower levels and each level can view their own details.

1.98 Stock Allow the user to receive stock and create a stock-receiving report. 1.99 Stock Ability to enter Vaccine Vial Monitor (VVM) status.

1.100 Stock Update stock records with quantity received per lot, expiry date, VVM record, etc.

1.101 Stock Have ability to print vaccine report and requisition form of stock received, used, and currently in stock.

1.102 Stock

Alert when VVM conditions, expiry date, or stock balances are outside threshold. Ability to allow administrator to set parameters to prevent expired stock from being administered or included on the report.

1.103 Stock Track lots and expiry dates. 1.104 Stock Record stock adjustments and prompt the user to enter reasons

from a dropdown list.

1.105 Stock Number of doses per global trade item number (GTIN) maintained as a GTIN-specific attribute (e.g. unit of measure conversions attributes to the stock item master record).

1.106 Stock Aggregate vaccine consumption tracked in terms of doses of vaccine type per time period (e.g. doses of BCG consumed since May-21), at the service delivery point (SDP) level.

1.107 Stock Vaccine inventory can be expressed in terms of "days of inventory" per vaccine type, especially at the national, provincial, and district levels.

1.108 Stock Safety stock levels can be maintained/defined by vaccine type by stock point (facility).

1.109 Stock Default re-order point and replenishment quantities can be maintained by vaccine type by stock point (facility).

of 43

1.110 Stock Supply chain data can be shared via Electronic Data Interchange. Full support for sharing (send & receive) requisitions, orders, and packing lists.

1.111 Stock Inventory transactions can be captured via barcode interfaces (e.g. GS1 datamatrix).

1.112 Stock Multiple inventory transactions can be automatically created by top level document ID (e.g. receive entire shipment, by packing list #, to specified putaway).

1.113 Reports Ability to submit aggregated data to calculate coverage rate. 1.114 Reports Allow user to select vaccine inventory parameters (e.g., time,

location, vaccine grouping, vaccine dose count, etc.).

1.115 Reports Allow user to select report output parameters (e.g., display options, summary vs. detail report, sort options, alphanumeric vs. date, etc.).

1.116 Reports Allow user to choose a report generation time frame (i.e., immediately run or set the time for later).

1.117 Reports Ability to save parameters as “public” to allow other users to generate the same report using the same parameters.

1.118 Reports Ability to prompt user to confirm the generation of a report at a later time if required.

1.119 Reports Allow user to delete and/or modify data elements within a report (Note: Allows the user to modify report based on the audience).

1.120 Reports Automatically schedule routine reports to run at a specific time. 1.121 Reports Ability to generate a report on health facility details.

1.122 Stock Ability to add/maintain/remove a facility and validate minimum mandatory information.

1.123 Stock Ability to validate vaccine availability/update stock counts. 1.124 Stock Ability to alert on low/expired stock level. 1.125 Stock Ability to generate stock request/track stock orders to delivery.

of 43

1.126 Stock Ability to enter inter-facility transfer of stock details. 1.127 Stock Ability to adjust stock balance based on given vaccines/doses

report in immunization registry.

1.128 Stock Ability to produce picklist that ensures stock is picked based on the inventory control method (FIFO, FEFO). The system should reject any request to issue stock not complying to this condition.

1.129 Stock

Ability to display stock balance/details in offline mode by downloading the stock information as at last synchronization. Ability to adjust stock information while in offline mode based on immunization registry transactions (i.e. vaccines given vs stock available).Ability to provide alerts on stock balances based on reorder, minimum, maximum, or buffer levels in offline mode.

of 43

Appendix D- Health Service Delivery Aggregation Form The following core data elements/indicators are what we would expect the Immunization Information System (IIS) to be able to provide to the national reporting systems DHIS2 /HIA2.

Ministry of Health Health Service Delivery Aggregation Form

Health Centre Form - - (HIA2) Facility Name:_______________________ District: ____________ Month:________________ Year:__________

1 Child Health & Nutrition (CHN) Source: Child Health Activity Sheet

1.1 Under 5 Clinic Attendance Code Value Comment Attendance child health <12 months male CHN1-005 Attendance child health <12 months female CHN1-010 Attendance child health 12-59 months male CHN1-015 Attendance child health 12-59 months female CHN1-020 Attendance child health total……..….. (Sum CHN1-005 to CHN1-020) CHN1-025 Attendance from outside catchment’s area CHN1-030 1.2 Growth Monitoring and Nutrition Child 0 – 23 months weighed CHN2-005 Child 24 – 59 months weighed CHN2-010 Total Child <5 years weighed………..(Sum CHN2-005 + CHN2-010) CHN2-015 Not gaining weight 0–23 months CHN2-020 Not gaining weight 24–59 months CHN2-025 Total "Not gaining" weight…………... (Sum CHN2-020 + CHN2-025) CHN2-030 Weight between -2Z & -3Z scores 0–23 months CHN2-035 Weight between -2Z & -3Z scores 24–59 months CHN2-040

of 43

Weight below -3Z scores 0–23 months CHN2-045 Weight below -3Z scores 24–59 months CHN2-050 Weight above +2Z scores 0–23 months CHN2-055 Weight above +2Z scores 24–59 months CHN2-060 Vitamin A supplement to 6-11 months infant CHN2-065 Vitamin A supplement to 12-59 months child CHN2-070 De worming dose to child 12-59 months CHN2-075 Children who received insecticide-treated nets (ITNs) CHN2-080 1.3 Immunisation BCG dose (<1 Year) CHN3-005 OPV 0 (<1 Year) CHN3-010 OPV 1 (<1 Year) CHN3-015 OPV 2 (<1 Year) CHN3-020 OPV 3 (<1 Year) CHN3-025 OPV 4 (<1 Year) CHN3-030 DPT-Hib+HepB 1 (<1 Year) CHN3-035 DPT-Hib+HepB 2 (<1 Year) CHN3-040 DPT-Hib+HepB 3 (<1 Year) CHN3-045 PCV 1 (<1 Year) CHN3-050 PCV 2 (<1 Year) CHN3-055 PCV 3 (<1 Year) CHN3-060 RV 1 (<1 Year) CHN3-065 RV 2 (<1 Year) CHN3-070 Measles 1st dose (<1 Year) CHN3-075 Fully Immunised (<1 Year) CHN3-080 Measles 2nd dose at 18 months CHN3-085 Number of days fridge non-functional CHN3-090

of 43

Appendix E: Non-functional Requirements

ID Component Description 1.1. Immunization Registry Should maintain an audit log of the changes and history. 1.2. Immunization Registry Ability to allow an administrator to configure screens or customize fields in forms. 1.3. Immunization Registry Provide informative error messages. 1.4. Immunization Registry All external communication between the system server and client must be encrypted. 1.5. Immunization Registry Enable users to work offline and then synchronize data when data connection is available. 1.6. Immunization Registry Allow a task to be interrupted and resumed.

1.7. Immunization Registry Enable backup of data so that information is recoverable in the event of a system or hardware failure.

1.8. Immunization Registry Accommodate loss of connectivity to hosted application (network may become unavailable while a user is in the process of submitting a form).

1.9. Immunization Registry Be deployed in an environment subject to power loss. 1.10. Immunization Registry Allow the administrator to establish access privileges and priorities. 1.11. Immunization Registry Maintain a transaction log history.

1.12. Immunization Registry The system should have user friendly messages that gives instructions to the user and re-directs the user to the working page or area needed to correct the mistake.

1.13. Immunization Registry Log and report all system errors to the administrator for corrections.

1.14. Immunization Registry Maintainable; the system should accommodate changes, fixes, and additions or updates.

1.15. Immunization Registry All system data must be backed up every 24 hours and the backup copies stored in a secure location (which is not in the same building as the system).

1.16. Immunization Registry Access permissions for system data may only be changed by the system’s data administrator and supported by an audit log for the changes made.

of 43

Appendix F: Examples of Data Visualization Dashboards

98.586.1 87.3 81.8

73.8

0

20

40

60

80

100

120

2010 2011 2012 2013 2014

% Imm fully <1 (annual)

of 43

Appendix G: Data Visualization Indicators Frequency: Monthly

# Category Community Rural Facility

Urban Facility District Province Comments/Questions/Clarifications

1

Patient data

# of births # of births # of births # of births # of births

2

% of children fully vaccinated on time for their age.





Calculation = (# of children vaccinated within allotted time for their age by vaccine/all children in catchment area) x 100.

3

3-month trend analysis on % of vaccines received on time.





This data will be made available as the data becomes available.

4

Last 2 years of % of vaccines received on time for the given month.





This data will be made available as the data becomes available.

5 % of fully immunized children.

% of fully immunized children.




A fully immunized child is a child who receives all the vaccines in the childhood schedule at the appropriate age and appropriate interval between doses in the first year of life.

of 43

6 % of dropouts.

% of dropouts.

% of dropouts.

% of dropouts.

% of dropouts.

Calculation = [(DTP1 - DTP3)/DTP1] x 100 (recommends the calculation of BCG and measles drop out).

7

Supply chain

# of stock outs (on any vaccine).




The definition of a stock out is 0 stock at the point of counting stock inventory.

8

# of days since last stock out (on any vaccine).

# of days since last stock out (on any vaccine).

10

Comparison data

Average % of children fully vaccinated on time for their age within the other communities in their facility catchment area.

Average % of children fully vaccinated on time for their age within the other facilities in the district.

Average % of children fully vaccinated on time for their age within the other facilities in the district.

Average % of children fully vaccinated on time for their age within the other districts in the region.

Average % of children fully vaccinated on time for their age within the other regions in the country.

11

Average # of stock outs (on any vaccine) per facility within the district.

Average # of stock outs (on any vaccine) per facility within the district.

Average # of stock outs (on any vaccine) per district within the region.

Average # of stock outs (on any vaccine) per region within the country.

of 43

12

Average # of days since last stock out within all facilities in the district.

Average # of days since last stock out within all facilities in the district.

# of stock outs reported for each facility within the district.

# of stock outs reported within each district within the region.

13

Average % of dropouts at within the other facilities in the district.

Average % of dropouts at within the other facilities in the district.

Average % of dropouts at within the other districts in the region.

Average % of dropouts at within the other regions in the country.

14 % of fully immunized children.




of 43

Appendix H: Sample of the Report Based on HIA2

of 43

Appendix I: Stock management Requisition/issue Voucher

of 43

Supply Voucher

of 43

Stock Control Card

of 43