Integration of DHIS2 through the use of the FHIR® specification constitutes an area of technology development through which existing implementations can extend from a top-down programmatic focus to the electronic health record orientation which is necessary for vaccine registries. The DHIS2 FHIR® Adapter is a tool that has been developed to exchange FHIR compliant data with DHIS2. For the past 2 years, our team has been leading the development of the DHIS2 FHIR® Adapter, and now maintains the official repository. The initial scope of the Adapter was the import of FHIR Resources into DHIS2 Tracker by using FHIR Subscriptions. The Itinordic team has deployed a system which uses the adapter to send FHIR Resources created via Android into DHIS2. The aim therefore is to develop the Adapter so it can be used to export DHIS2 Tracker data, in this case COVID-19 vaccination data, into FHIR Resources, conformant in this case with the DDCC:VS specification. The basis on which the adapter is built is, as previously alluded, the WHO-DHIS2 health data toolkits for COVID-19 surveillance and national vaccine delivery. According to the DHIS2 Website, at least 42 countries are using DHIS2 for COVID-19 surveillance and at least 40 for national vaccine delivery. These are standardised packages with coded elements, on which FHIRPath attributes can be added to complete the mapping to COVID-19 FHIR Compositions. We will have opportunity to pilot the DHIS2 DDCC:VS FHIR Adapter in some of these implementations in order to refine the technology. Our ongoing collaboration with the University of Oslo within a number of projects, including participation in the integration team, and our background of working with WHO on the feasibility of computable guidelines for FHIR implementation will server to assure our work is on the leading edge. A core component of the system is mapping between DHIS2 and FHIR data. DHIS2 is highly customisable and allows for the addition of FHIRPath attributes to existing data elements from the WHO-DHIS2 health data toolkits for COVID-19 surveillance and national vaccine delivery. The adapter will understand the meaning of these attributes and use them to do the mapping between DHIS2 and the DDCC:VS FHIR Compositions. As data is entered into DHIS2 in real time, a subscription service built on a robust messaging framework, will be able to recognise COVID-19 surveillance and vaccine data, and thereby begin the process to check and produce the DDCC:VS document. In addition, signing of the certificates can proceed using whatever the preferred Public Key Infrastructure a client chooses to implement in accordance with international standards. In particular, RabbitMQ will be incorporated as part of the DHIS2 FHIR® Adapter architecture, to provide an efficient and resilient data processing channel between interacting entities using the industrial standard, Advanced Message Queueing Protocol (AMQP-0.9.1/1.0). RabbitMQ is an industry trusted, multi-purpose messaging broker, built on highly scalable, fault tolerant and resilient technology, such as needed in critically deployed ecosystems as DHIS2. It is a feature-rich open source system, licensed under the Mozilla Public License v2.0. The unit of processing in RabbitMQ is it’s queues, which provide both persistent and/or transient message retention for high performant, asynchronous message processing between two or more applications or processes. Given the need for multiple systems to interact securely in this architecture, a robust identity management solution in accordance to industry standards such as OAuth2 and OpenId Connect will be implemented. A number of open source tools for identity management exist, such as keycloak and gluu. In this case, the focus will be on choosing best practices so we can benefit from the community which has for instance developed tools for integrating FHIR servers with some of the existing open source identity management tools. We aim to secure a a good test case to pilot the system as we will adopt the SCRUM methodology for rapid prototyping. We have certified scrum competence and experience in the team. This way we will ensure that while our approach is generic, it addresses real world challenges in the process and therefore mitigates the risk of failure. In addition, we will use a participatory approach with the community such as those working with DHIS2, FHIR and OpenHIE to ensure the ideas implemented have a good foundation. We have also discussed with colleagues who have expressed interest in implementing our solution. Another risk is the fact that COVID-19 certificates constitute a complex area of technology development which encompass a number of issues relating to trust and security. We will endeavour to assure implementors on the open source technologies used in the system such that it can be trusted. In addition, nations are using other systems besides DHIS2 we can incorporate into the the infrastructure that is developed. The team has gained experience in this arena of interoperability, mobility and standards, and these will be important in identifying and mitigating risk. A draft system flow diagram is attached. The anticipated timeline of the project is a total of 9 months, including analysis, development and testing. The first 6 weeks will be dedicated to analysis and design, where we will develop the idea into a project inception report. After inception, We will devote 4,5 (four and a half) months to development sprints. We expect the first prototype to be available for user testing within the first 8 weeks of the development phase, and more frequent releases made thereafter for new features and bug fixes. We would then pilot the system for an additional six weeks to get final feedback, and then complete product development and documentation in the remaining 6 weeks on the project.