Sources Sought - Notice ID 80566.docx

The Centers for Disease Control and Prevention (CDC), Office of Acquisition Services (OAS) is releasing the following Sources Sought to gather information in preparation of a potential requirement. The intent of this Sources Sought is to gain a list of potential vendors for the identified services and determine the viability of a Small Buisness set-aside. This is not an invitation for bid, request for proposal, or other solicitation, and in no way obligates the Centers for Disease Control and Prevention (CDC) to award a contract.

Interested vendors are requested to submit the following information:

1. A brief – no more than 4 pages – response to the attached SOO that contains relevant past experience on similar projects and vendors capacity to acomplish the requirements set in the SOO.

2. Company contact information (point of contact, UEI, current NAICS codes, business size categorization

Interested vendors are invited to submit a response to this sources sought notice by Tuesday April 30th, at 1PM EST. Responses should be emailed to the Contracting Officer, Matthew Nelson at mnelson2@cdc.gov.

1. Statement of Objectives

1.1. Background

The Centers for Disease Control and Prevention (CDC) has a mission to protect America from health, safety, and security threats, both foreign and in the U.S. The CDC seeks to accomplish its mission by working with partners throughout the nation and the world to:

· Monitor health

· Detect and investigate health problems

· Conduct research to enhance prevention

· Develop and advocate sound public health policies

· Implement prevention strategies

· Promote healthy behaviors

· Foster safe and healthy environments

· Provide leadership and training

Advancing Immunization Information Systems (IIS) is one of many ways CDC protects the Nation’s health. IIS are confidential, population-based, computerized databases that record all immunization doses administered by participating providers to persons residing within a given geopolitical area. At the point of clinical care, an IIS can provide consolidated immunization histories for use by a vaccination provider in determining appropriate client vaccinations. At the population level, an IIS provides aggregate data on vaccinations for use in surveillance and program operations, and in guiding public health action with the goals of improving vaccination rates and reducing vaccine-preventable disease.

IIS have many functions that play a critical role to improving individual and population health. IIS combine immunization information from different sources into a single record and provide official immunization records for school, day care, and camp entry requirements. IIS remind families when an immunization is due or has been missed. IIS help providers and parents determine when immunizations are due and help ensure that children get only the vaccinations they need. IIS are capable of exchanging immunization information with immunization healthcare providers. They also play an essential role in assessing vaccine uptake, assisting with vaccine evaluation and forecasting, assisting with vaccine ordering and inventory management, supporting outbreak investigation, calculating vaccine coverage estimates, and much more.

The National Center for Immunization and Respiratory Diseases (NCIRD), Immunization Services Division (ISD), Immunization Information Systems Support Branch (IISSB) works with CDC’s Office of Financial Resources to award and support 64 jurisdictions through the Vaccines for Children and 317 cooperative agreements. As an indicator of the scale of data in IIS processes, a representative IIS holds 10,000,000 patients and 100,000,000 vaccinations.

Current (legacy) Wisconsin Immunization Registry (WIR):

This WIR platform is one of three primary IIS platforms used in the United States and supported by the Immunization Cooperative Agreement. The WIR platform was created nearly 20 years ago using a combination of State and Federal funds and has enabled more than a dozen states to leverage the system using a free license rather than purchasing or creating their own. The WIR platform has evolved over many years, with each jurisdiction modifying their version of the system to meet their specific needs and design preferences. While these modifications allow for jurisdiction-specific enhancements, they were made at times without coordinating with other jurisdictions and their system design teams. This results in different coding styles/architecture across the WIR platforms and redundancy of modifications when another jurisdiction may have been working on a similar enhancement, thereby limiting potential functionality and joint business development.

Development of WIR Consortium governance mechanism:

The sustainability and architecture challenges due to uncoordinated system development are exacerbated by a lack of a collaborative governance structure. Creating and implementing a governance structure that enables consistent collaboration and planning among WIR jurisdictions could allow for shared services and avoidance of redundant maintenance, operations, and infrastructure costs. To address these challenges, the Wisconsin Department of Public Health and the CDC Immunization Services Division evaluated options to improve the sustainability, governance, licensing, and innovation of the WIR platform. As part of this process, Wisconsin Department of Public Health, with Government support, convened members of WIR Consortium and collaboratively determined the best path forward was development of a modern, cloud-based IIS with a microservices architecture that includes a modern user interface/user experience (IU/UX) that will be implemented to WIR Consortium member jurisdictions under a shared governance WIR Consortium shared governance mechanism, which is currently under development.

Current state of new cloud-based WIR IIS platform development:

An initial version of a new WIR IIS platform began development in September 2020 development and continued until September 2022. Requirements developed for the new WIR IIS platform considered CDC’s IIS Functional Standards and other IIS community documentation (e.g., CDC IIS Technical guidance and recommendations, Data Quality Assurance in Immunization Information Systems: Recommendations of the AIRA Operations Workgroup (MIROW), evolving emergency immunization data reporting requirements, HL7, etc.) and business requirements From the WIR Consortium (see Appendices B-F).

Development is incomplete with most of the required functions listed in the WIR Consortium’s “minimum viable product (MVP)” partially developed. The previous scope of work described an MVP containing a list of functional requirements. Please see Appendix C for the MVP required functions and state of development.

The WIR Consortium has reanalyzed and updated their requirements to reflect lessons learned from the COVID-19 pandemic, MPox outbreak, evolving program requirements, as well as incorporate the most current guidance documents (see Appendix D). The updated functions and capabilities, and attributes are listed in Appendix E and will be refined and finalized during the gap analysis in the beginning of the Base Period.

WIR Consortium jurisdiction readiness for migration to new platform The WIR Consortium expects up to 2 jurisdictions will be ready to pilot (beta) the new WIR IIS Platform by the end of calendar year (CY) 2023. The remaining WIR Consortium jurisdictions will be ready for implementation of the fully deployable WIR IIS platform in CY 2024.

WIR Consortium governance model development The WIR Consortium is currently developing a shared governance mechanism. The governance of the new WIR IIS Platform will transition to the WIR Consortium at the end of this contract.

Purpose of acquisition:

The Contractor shall execute the final development of a fully deployable WIR IIS platform, to develop and execute an implementation strategy, to provide operations and maintenance of the new WIR IIS platform including cloud hosting services, manage product backlog and develop approved optimizations and enhancements agreed upon by the Government, provide cost model analysis support, and project management. This new contract is intended to provide adequate time and support services to enable WIR Consortium jurisdictions to migrate to the new platform and migrate of governance of the WIR IIS platform from the Government to the WIR Consortium.

1.2. General

1.2.1. Current Structure

Current legacy WIR IIS: 14 WIR jurisdictions host and use their own modified instance of the legacy WIR application. Each WIR jurisdiction contracts with a Vendor to support operations and maintenance of its current unique legacy WIR instance. This outdated legacy system does not allow for shared cost and shared governance.

New WIR IIS Platform: Will consist of a collection of micro-services that operates within Docker containers and is intended to provide the key functionality of a full-featured IIS. These micro-services provide:

· Patient Demographic Records

· Immunization Records

· Vaccine Inventory

· Reporting

· Immunization (IZ) Gateway Connectivity

· Administrative Interface Management

· Data Exchange Services

WIR provides Application Programming Interfaces (API) that allow healthcare systems such as Electronic Health Record (EHR) platform to submit immunization data (see Appendix A).

WIR IIS provides direct interaction with jurisdictional, healthcare, and administrative users and is available via a web-based user interface / user experience (UI/UX) which is accessed by standard web browsers such as Chrome, Edge, Safari, etc., on desktop, laptop, tablets, and smartphones.

System Organization

WIR runs on Linux, and initial development was tested thoroughly on Ubuntu Linux 20.04 LTS and 22.04 LTS. Other variants of Linux may be utilized, but the installation instructions contained in this document are specific to Ubuntu regarding package management and specific installation commands.

Development was performed on a Virtual Machine with 32GB of RAM, and 4 processor cores. Actual system memory and CPU requirements will vary according to the production database size and expected user load.

For simple installations, these components are represented by Virtual Machines implemented as Docker Containers. These containers emulate a complete Linux operating environment and contain the required dependencies and software elements to run WIR.

The Docker containers utilized by WIR include:

· Front-end Proxy

· Database Server

· Report Services

· Inventory Services

· Web Server

In a production environment, these containers would need to be adequately sized to handle the processing and storage load required by the Jurisdiction.

The microservices-based architecture that WIR is built upon lends itself to “horizontal” expansion, meaning that more Virtual or Physical hosts can be added to the server farm to increase capacity and performance on a whole, rather than a fewer number of larger servers/instances. For example, improving the performance of the Database Server can be accomplished by adding more read-only database replicas. More reports can be run simultaneously by adding additional reporting instances.

1.3. Objectives

Note: The Statement of Objectives (SOO) will be removed at time of award and replaced with the Offeror’s Performance Work Statement (PWS). All listed objectives and requirements shall be included as part of the Offeror’s PWS.

Overview The objective of this contract is to 1) finalize development of a fully deployable new WIR IIS platform; 2) develop and execute an implementation strategy for the new WIR IIS platform 3) provide operations and maintenance services for the new WIR IIS platform; 4) manage product backlog for the new WIR IIS Platform and develop enhancements and optimizations agreed upon by the Government; 5) provide Cost Model support to the WIR Consortium to support planned transition of shared governance from Government to WIR Consortium (anticipated by September 2026; and 6) project management.

The CDC ISD is seeking a Contractor with agile software development and project management practices experienced in rapid product development of public health information systems, modern web application frameworks, user-centered design, implementation of user interface/user experience (UI/UX), and migration of legacy applications and databases to modern infrastructure. Extensive knowledge and experience with immunization data systems, data management, and immunization program operations and support are essential.

The Government intends for this project to be completed by working in short development iterations of several weeks, each of which will typically result in the delivery of functioning software that can be tested with internal and external users and implemented by up to 15 jurisdictions.

The success of this product will be based on ease of use including ease of configurability, end user acceptance and adoption, ease of maintenance, the implementation of industry best practices, and rapid time to market for all development efforts. To accomplish this, these services shall be provided via agile software development processes that achieve results through continuous capability enhancement, prompt response to emerging needs, demonstrated reliability, and optimized performance with resource utilization minimized.

Iterations should rapidly develop any additional functional, non-functional, and technical capability needed to meet the WIR Consortium’s requirements for a fully deployable WIR IIS Platform. Please see Appendix C for overview of feature development to date and Appendix E for updated draft requirements for fully deployable WIR IIS platform. The Contractor shall develop final requirements for the fully deployable WIR IIS platform in collaboration with the WIR Consortium by performing a thorough gap analysis, pilot testing of the new WIR IIS Platform, and updating requirements to ensure the WIR IIS platform meet the jurisdictions’ operational needs (e.g. CDC IIS Functional Standards, IPOM objectives, technical standards or code set updates, etc. see Appendix D). The Contractor shall also manage product backlog and develop approved updates to the WIR IIS platform to meet the evolving needs of the jurisdictions (see known enhancement backlog Appendix F). This product shall be designed using industry best practices to build effective, modern, intuitive digital services (e.g., The, Digital.gov — Guidance on building better digital services in Government, see Appendix D) and will replace the WIR Consortium’s legacy IIS, allowing WIR Consortium to decommission its existing systems as features and capabilities are replaced by this new platform.

In order to meet these objectives, the Contractor shall:

1.3.1. Finalize WIR IIS Platform Development

The Contractor shall rapidly assess and perform a gap analysis of the current WIR IIS platform code base and available documentation, and perform necessary development to remediate any technical and functional gaps to ensure the WIR IIS platform meets the WIR Consortium requirements for a fully deployable product. Activities shall include but are not limited to:

a. Perform an initial evaluation of the new code base to determine the extent to which it is modular, modern, and secure, ensuring that it addresses issues identified in the Feb 2020 evaluation (Appendix B), initial deployable WIR IIS Platform defined by the WIR Consortium (see Appendix E), and Government and Immunization Community standards, specifications, and best practice documents (Appendix D), and

b. Identify gaps, develop functional, non-functional, and technical requirements and design to remediate gaps (within 60 days of start of performance period). Note: Draft requirements are included in Appendices B-E and are expected to evolve during gap analysis, requirements development, testing, and pilot implementation by up to 2 WIR Consortium jurisdictions); and

c. Develop, test, and deploy any updates, enhancements, and/or infrastructure required to resolve any gaps found in the initial evaluation of the new WIR IIS platform to meet WIR Consortium defined requirements for the fully deployable product (within 12 months of start of the period of performance). Testing shall include implementation of beta product in production with up to 2 jurisdictions in order to develop any refinements necessary to meet the “fully deployable product” requirements needed by non-pilot WIR jurisdictions

1.3.2. Implementation planning and support for fully deployable WIR IIS Platform Activities shall include but are not limited to:

a. Develop and execute implementation strategy with written plan (see Appendix D for community best practices) to include readiness assessment, jurisdiction resource recommendations, rollout schedule, training plan and training for end users, data migration, and integration of external systems. (Comprehensive draft implementation plan completed within 60 calendar days of Period of Performance start with updates as code is completed to meet requirements for Initial deployable WIR IIS Platform).

· Anticipate up to 2 jurisdictions will implement (pilot jurisdictions) WIR IIS platform in Base Period.

· Anticipate up to 13 jurisdictions to engage in implementation planning activities in the Base Period.

· Anticipate up to 13 jurisdictions to complete implementation during Option Period 1.

1.3.3. Operations and maintenance (O&M) of the new WIR IIS Platform Activities shall include but are not limited to:

a. System monitoring and technical support, Tier 1-3 including help desk available 8am-5pm for the time zones supported (currently Pacific, Mountain, Central, Eastern time zones in US) and response during business hours within 2 hours for routine issues. Must include a plan for after-hours support and plan for reporting of, timely response to, and resolution of critical issues.

b. software, hardware, and network level support

c. database administration and maintenance

d. issue triage, tracking, prioritization, and resolution

e. Updates to include support for evolving Government IIS Functional Standards, terminology standards and specifications, technical standards and specifications, Government IPOMs, and other update to support routine, seasonal and emergency immunization management.

f. optimization of software and systems approved by the Government

g. product team meeting facilitation

h. Configuration Management (CM)

i. integration onboarding and support of connected systems (e.g., Vaccine Administration Management System, IZ Gateway, Immunization Calculation Engine, EHRs, etc.)

j. Execute an implementation strategy that supports business function and process migration for up to 14 current WIR Consortium member jurisdictions and up to 5 future WIR Consortium jurisdictions (determined by WIR Consortium governing body).

k. Develop and execute a data migration plan from old databases into the new infrastructure. This migration must ensure data integrity and a seamless transition from the legacy system to the new system.

1.3.4. Manage product backlog for the new WIR IIS Platform and develop enhancements and optimizations agreed upon by the Government Activities shall include but are not limited to:

a. conduct a planning and any required stage gate review process consistent with HHS/CDC Enterprise Performance Life Cycle (EPLC) requirements for each planned enhancement including development of written documentation throughout the process;

b. develop a release plan for new features to support ongoing improvement of the system;

c. current known enhancement backlogs in Appendix F for prioritization and will be considered for development after the fully deployable product is completed.

1.3.5. Provide Cost Model support to the WIR Consortium

Provide cost support to support planned transition of shared governance from the Government to WIR Consortium (anticipated to begin 09/2023 with full transition at the end of Option Period 1). Activities shall include but are not limited to:

a. developing a cost model with projected costs for operations & maintenance as well as enhancements of the WIR IIS platform;

b. planning for ongoing support to maintain the WIR infrastructure (hardware, software, integrations) in accordance with current standards (e.g., current version of database, use of the cloud) including hosting and user support, configuration management, continued implementation planning; and

c. migration from legacy WIR system to the new WIR Consortium governance entity, and management of future maintenance, optimization, and enhancement updates to the platform.

1.3.6. Project management

Activities shall include but are not limited to:

a) Maintain a tracking tool and metrics to monitor progress against the Agile Development Management Plan (ADMP);

b) Ensure products are compliant with Federal Section 508 requirements and CDC and HHS security requirements, as described in the Appendix H and Appendix I;

c) Cultivate a positive, trusting, and cooperative working relationship with the Government and other Vendors that support the Agency and the WIR Consortium jurisdictions;

d) Ensure that the Government maintains ownership of and has ready access to all source code, tests, documentation, deployment scripts, designs, user research documentation, and all other materials related to developing and deploying these capabilities;

e) Leverage most current technology capabilities to meet customer needs with timely and seamless access to the cloud-based infrastructure, business applications, and data. This includes staying abreast of new feature offerings and new and innovative ways to provide technology value to Agency customers, including, but not limited to, open sourcing the applications, or the development of APIs;

f) In accordance with Agile techniques, maintain a dialogue between the service provider and all project stakeholders, rather than trying to comprehensively specify requirements up-front. This focus will be assisted by working through short, tightly scoped product iterations in which working software is delivered to users regularly, and adjustments are made based on feedback gleaned from these iterations; and

g) Lead and collaborate with the Contracting Officer’s Representative (COR), workgroups, and stakeholders in requirements sessions in order to develop recommendations and approaches, to be approved by the Government to satisfy the objectives and purposes of this contract. Results of these sessions will generate the Product Road Map, Epics, and User Stories, business logic and rules, functionality, and system documentation.

h) EPLC framework: The Contractor (and/or any Subcontractor) shall comply with information security and privacy requirements, EPLC processes, HHS Enterprise Architecture requirements. All information systems development or enhancement tasks supported by the Contractor shall follow the HHS EPLC framework and methodology. The Contractor shall follow the EPLC framework, which will provide a standard structure for planning, managing, and overseeing IT projects over their entire life cycle. The framework consists of ten life cycle phases. Within each phase, activities, responsibilities, reviews, and deliverables are defined. Templates for the deliverables are available to the Contractor after award. Exit criteria are established for each phase and Stage Gate reviews are conducted through the Government’s IT Governance process to ensure that the project’s management quality, soundness, and technical feasibility remain adequate, and the project is ready to move forward to the next phase. All IT projects in support of this task must adhere to the EPLC requirements and pass each State Gate as appropriate. More information about EPLC can be found at https://www.hhs.gov/web/governance/digital-strategy/it-policy-archive/policy-for-informationtechnology-enterprise-performance.html

“Fully deployable WIR IIS platform updated draft requirements” (Appendix E) provides a breakdown of the desired functionality as identified at this time. The initial deployable WIR IIS Platform, optimized deployable WIR IIS Platform and initial product backlog are not binding documents, but rather a representative sample of the functionality that is anticipated will be required to be delivered under this contract. The specific user stories will be identified through the agile development process as proposed in the Offeror’s PWS. Initial deployable WIR IIS Platform, optimized deployable WIR IIS Platform and initial product backlog appendices provide some guidance on specific objectives that should be included in each project.

The PWS shall provide a detailed process for working with the Product Manager, Government staff, and End Users (primarily WIR Consortium and users in the participant jurisdictions) to capture, prioritize, and work-off the product backlog. The prioritization effort may include working backlog items across multiple projects concurrently based on the team’s capacity and end user priorities.

Identifying and achieving specific milestones in the Base Period will be critical to this project’s success and include but are not limited to:

a. Perform gap analysis of the code and documentation for the new WIR IIS platform and define requirements needed to complete the development of fully deployable WIR IIS Platform version 1 (as defined by the WIR Consortium); and

b. Develop and deploy the fully developed WIR IIS Platform by the end of the Base Period. This includes implementing beta version to up to 2 pilot jurisdictions that allows for refinement and optimization based on pilot users experience prior to delivering WIR IIS Platform version 1; and

c. Implement planning and pre-implementation activities within first 6 months of Period of Performance; and

d. Operations and Maintenance activities; and

e. Manage product backlog and develop enhancements agreed upon by the Government (see Appendix B-F);

f. Perform Cost Model analysis and provide cost model support to the WIR Consortium to assist with planned transition of shared governance from the Government to WIR Consortium (planned to begin Sept 2025); and

g. Perform project management.

Key project milestones and sample deliverables for Base Period The timeline below highlights key project milestones and sample deliverables for the Base Period of the contract (see Figure 1: Key milestones and sample deliverables for more detail).

Figure 1: Key project milestones and sample deliverables

2. Critical timelines and inspection items

Deliverables under this contract are defined as the completion and acceptance according to the “Definition of Done” of the iterations completed, which are based on the Contractor’s Agile Software Development methodology. This methodology defines the repeatable process of providing development and deployment services in small iterations lasting two to five weeks which results in the delivery of design, usable software, data, or product, which have little to no inherent defects. Each iteration shall be defined in the PWS but should document how planning, requirement analysis (user story building), design, coding, testing, quality assurance, and documentation will all meet the Contractor’s “Definition of Done”.

Each deliverable shall incorporate Government and WIR Consortium requirements as detailed in the Appendices B-F of this document, comply with HHS and CDC EPLC requirements and be compliant with Section 508.

Functional Requirements, translated into Epics and User Stories that will be used to populate the Product Backlog may include, but are not limited to:

· Findings from the initial review of the new WIR IIS Platform that require remediation

· System configurations to support business processes

· Integration for data input and output (e.g., IZ Gateway, VAMS or other mass vaccination tool, consumer access applications, VTrcKs, electronic health record systems, immunization calculation engine, data aggregators, etc.)

· Workflow design and implementation

· Overall collaboration of connected applications

· Enhancements, patches, and updates to applications, data, or cloud systems

· Data import of records collected from legacy systems

· Automated and user acceptance testing

· Training of end users on the systems Table 1: Critical timeline and inspection times Below are critical timelines needed by the Government and WIR Consortium for this project. This is not intended to include a complete list of deliverables. Rather, to inform the Offeror key priority milestones and deliverables known at this time.

· Functional, non-functional, and technical requirements to complete Initial deployable WIR IIS Platform

· Data dictionary and entity relationship diagram

· Draft design document

· Project plan to complete Initial deployable WIR IIS Platform design, development, testing (to include pilot of up to 2 jurisdictions), and deployment.

No later than 2 months after start of Base Period Performance Updates to Requirements, Data Dictionary, Design document at the end of each sprint (where updates are needed).

· Expect iterations leading up WIR IIS Platform aligned with agile development process and include pilot testing with up to 2 jurisdictions to refine the product prior to release.

Iterative deployment of code to development (and production environment when appropriate) after each sprint.

Deployment of “fully deployable product” and code delivery no later than 12 months after start of Base Period Performance.

Develop implementation strategy with written plan Anticipate the following:

· Up to 2 jurisdictions will complete implementation of WIR IIS Platform in Base Period to serve as pilot jurisdictions during the development of the fully deployable product.

· Up to 13 jurisdictions to engage in implementation planning activities in the Base Period

· Up to 13 jurisdictions will complete implementation in Option Period 1

· Final implementation plan and schedule

Before start of final UAT of fully developed WIR IIS Platform (estimated 9 months after start of the Period of Performance) Update at least monthly for remaining Base Period and Option Period 1.

· Service Level Agreement Initial drafts no later than 2 months after start of Base Period of Performance Final documents due no later than 6 months after the start of the Base Period of Performance and will be reviewed and updated every 3 months through the Base Period and Option Period 1.

· Draft training materials

No later than 2 months after start of Base Period Performance

· Updates to draft training plan draft

· Update draft training materials With each sprint release

· Final training plan

· Final training materials (for Initial deployable WIR IIS Platform)

No later than start of final Initial deployable WIR IIS Platform UAT (estimated 5 months after start of Period of Performance) Updates to documents if needed with each sprint release.

No later than 2 months after start of Base Period Performance and updates monthly there after

This includes any documentation required for obtaining or updating the Authority to Operate

Updates to documentation required for ATO due no later than 3 months after start of Base Period Performance.

3. Stakeholders

Stakeholders for this project include, but are not limited to, the WIR Consortium Technical and Executive committees, WIR Consortium jurisdiction end users, CDC Informatics and Data Analytics Branch Chief and relevant Government staff, the Contracting Officer (CO)/Contract Specialist (CS) and all relevant personnel in the CDC Office of Financial Resources/Office of Acquisition Services, the Contracting Officer’s Representative (COR), Technical Monitors (TM) and Subject Matter Experts (SMEs), American Immunization Registry Association (AIRA), and Public Health Informatics Institute (PHII).

4. Agile Development Management Plan (ADMP) and Key Personnel Offerors shall propose an Agile Development Management Plan (ADMP) which demonstrates how the Offeror intends to manage, develop, implement, and maintain the requirements described in this SOO and the RFQ. The plan shall include, at a minimum:

· Contact information for all senior leaders and an organizational chart showing the Offeror’s organizational hierarchy and reporting structure, with specific designation of individuals as Key Personnel;

· Management resources;

· Technical resources and skill sets required to develop, implement, and maintain the proposed solution; and

· Details on the management of the Offeror’s team.

The ADMP and the listing of Key Personnel shall become part of the contract upon award.

5. System Documentation, Training, and Knowledge Management

The Contractor shall:

· Update existing, develop where necessary, and provide documentation and training to WIR Consortium jurisdiction staff (prefer primarily asynchronous training. However, some synchronous training may be appropriate in the overall training plan).

· Update existing, develop where necessary, provide effective training materials of all deliverables, including, but not limited to, “train the trainer” documentation.

· Conduct “train the trainer” sessions for up to 14 WIR Consortium jurisdiction staff. In planning, consider whether and when it may be appropriate to provide “train the trainer” sessions synchronously and asynchronously and when trainings may need to target an individual jurisdiction or can include groups of jurisdictions.

· Consult with the COR to determine what is appropriate, effective, and essential for training.

6. Transition

The Contractor shall:

Provide a Transition Out Plan and account for Transition Activities.

Section A: Appendices Appendix A: WIR IIS Platform architecture overview and software factory integration Hardware Architecture This project makes use of Docker Containers to hold each of the microservices and functional aspects of the application. As such, no specific hardware architecture is specified. The containers can run on Cloud-based virtual hosts or physical hosts at the option of the Jurisdiction that choose to implement the solution. Basic guidelines for container/virtual host sizing will vary based on the number of records to be managed, the inbound HL7 transaction volume, and the total number of simultaneous users that will operate the system.

Software Architecture The software architecture for this project depends on the following core requirements:

An Operating System – During development, both Apple MacOS and Ubuntu Linux LTS 20.04 have been utilized.

A database – During development, MySQL has been used. A software component called Hibernate has been selected which abstracts the database layer from the application layer, ensuring that a number of database options are viable if a Jurisdiction should standardize on something other than MySQL, such as SQL Server or PostGresQL.

Docker – Docker is used to containerize major functional areas of the system, such as the Patient Database, Inventory, Immunization, Reporting, Front-end, and HL7 processing.

Java Spring Boot is a microservices framework tool. Spring is the de facto standard for Java based microservices deployments.

The software development stack consists of the following components illustrated below:

Appendix B: WIR Code Review findings from February 2020 (Excerpt from WIR Consortium IIS Platform Modernization Briefing May 2020)

Background The jurisdictions using the Wisconsin Immunization Registry (WIR) Immunization Information Systems platform established a Consortium in May 2019 to address the known challenges with the WIR platforms, including that the system is outdated and non-modularized, limiting code and cost sharing opportunities, jurisdictions use different software versions, required proprietary software licenses to host and operate the legacy system are expensive, and WIR maintenance and enhancements are costly despite free code. In other words, the current system is not financially or technically sustainable over the long term.

The Consortium requested an independent technical code evaluation to assess the strengths and weaknesses of the WIR platform. To achieve this, the Government funded a code evaluation that was conducted by TechFlow, Inc. The WIR Consortium selected Georgia’s (adopted in 2003) and California’s (adopted in 2016) WIR platforms as samples for the evaluation.

Code Evaluation Findings

· The system uses obsolete technologies, creating reliance on expensive specialized developers. The systems are built on outdated and disparate technologies, some of which are unsupported, including an outdated database-served HTML framework. As these systems age, WIR jurisdictions are becoming increasingly reliant on expensive developers with difficult-to-find skillsets in obsolete technologies.

· Database passwords and Protected Health Information (PHI) is unsecured. Passwords are vulnerable to anyone with access to the database, as passwords are not hashed. Furthermore, PHI is currently leaking through application logs and is vulnerable to outside interception. This finding was communicated to the Consortium in February 2020 and is being addressed by jurisdictions’ current Vendor teams.

· Extensive code complexity and technical debt increases costs. Code complexity increases the time and cost to make changes in the system. With scarce system documentation and lack of in-line code commenting, updates to the system are more likely to introduce additional defects. Finally, the mechanisms for remediating data duplication are outdated.

· Poorly managed system resources and limited ability to handle fault tolerance, scalability, and availability increases costs. This system cannot handle increases in load without adding additional hardware, forcing usage of peak hardware at all times which results in higher costs. This also threatens system stability as capacity cannot be scaled up as needed.

· Unintuitive user interface requires more end user training. Navigation and overall user experience is dated and does not utilize modern practices. Specifically, reports are not well organized, there is a lack of form validation and user guidance, and the site does not accommodate mobile devices.

· Individually hosted systems and usage of Oracle creates additional costs. The hosted infrastructure in each jurisdiction requires redundant resources to administer and maintain system, and usage of Oracle database incurs added licensing costs for operations and maintenance.

Appendix C: WIR IIS platform development status by feature (based on minimum viable product features defined under previous scope of work)

Appendix D: Government and Immunization Community standards, specifications, and best practice documents

· CDC IIS functional Standards: IIS Functional Standards | CDC

· Core Data Elements: IIS Recommended Core Data Elements | CDC

· Data Code Sets: IIS Data Code Sets | CDC

· IIS Technical Guidance: IIS Technical Guidance | CDC

· Clinical Decision Support for Immunizations (see also HLN Consulting “ICE Forecaster” in row below): IIS: Clinical Decision Support (CDSi) | CDC

· Data Quality Assurance in Immunization Information Systems: Recommendations of the AIRA Operations Workgroup (MIROW), August 2022: Data Quality Assurance in Immunization Information Systems (immregistries.org)

· Meaningful use: Meaningful Use and Immunization Information Systems | CDC

· Vaccine 2D Barcodes: Vaccine 2D Barcodes - IIS | CDC

· CDC IIS activities (including “Mirow Best Practices guidebook): IIS Activities | CDC IS Data Quality Blueprint

· IIS Data Quality Blueprint IIS Data Quality Blueprint (cdc.gov) WIR IIS Platform developed ready to connect and/or exchange data with the following:

· VTrcKs ExIS compatibility: VTrckS: About the Vaccine Tracking System | CDC

· IZ Gateway connection ready: IZ Gateway for COVID-19 Vaccination Reporting | CDC

· VAMS ready: VAMS COVID-19 Vaccination Reporting | CDC Immunization program operations

· Immunization Program Operations Manual (IPOM): Foreword p.1 2022 IPOM The IPOM is a core companion document to the 2019 program announcement (CDC-RFA-IP19-1901) that covers the five-year cooperative agreement period of performance from July 1, 2019 through June 30, 2024.

· IPOM Chapter D sample activities 2022 https://www.cdc.gov/vaccines/programs/iis/downloads/IPOM-Chapter-D-Sample-Activities-2022.xlsx

1. Project Management

2. Change Management & Communication

3. Staffing

4. Training

5. Business Process Analysis

6. Requirements

7. Testing

IIS Migration Toolkit: IIS Migration Toolkit - PHII

8. Plan

9. Initiate

10. Execute

11. Monitor and Control

12. Close

Aggregate Analysis Reporting Tool (AART): Aggregate Analysis Reporting Tool (immregistries.org) AART meets a variety of needs for the Measurement and Improvement (M&I) Initiative:

· Allows IIS to declare their participation in all content areas and stages of the M&I Initiative.

· Allows IIS staff to determine who can see their results in named or unnamed form.

· Provides measures and test results in graphic or narrative form.

· Displays graphics to compare individual IIS results with other IIS across the full community.

US General Services Administration Digital.gov — Guidance on building better digital services in Government US General Services Administration Accessibility – Digital.gov

The ICE is an open source immunization calculation engine that provides clinical decision support for immunization. The WIR Consortium chose to use the ICE software system as its integrated immunization forecaster rather than develop a novel immunization calculation engine.

ICE forecaster ready: ICE – HLN Consulting, LLC

Appendix E: Fully deployable WIR IIS platform updated draft requirements WIR Consortium has reviewed and updated requirements for a fully deployable WIR IIS platform based on the PHII Requirements Traceability Matrix and tailored for the WIR Consortium needs.