 Okay, this session will cover the DHS2 roadmap and prioritization process. The learning objectives are to describe that process and also identify the available venues for feature requests and understand the timelines associated with development and release of those features. We'll first look at the introduction of the HISP approach to software development. Software development for DHS2 is a global collaboration managed by the HISP Center at the University of Oslo. Requirements for new versions of DHS2 are collected from the global user community, and priority is given to generic improvements that can have an impact across implementations, rather than those that are specific to one place. The generic is used in the academic sense derived from health information sciences. DHS2 is meant to be a generic toolbox that can be adapted to complex situations. The role of the HISP Center at the University of Oslo is to identify and implement generalizable improvements to the DHS2 platform that will support its use as a digital public good. Digital public goods are open source software that adhere to privacy and other applicable laws and best practices, do no harm by design, and help attain the sustainable development goals. This definition is operationalized through the DPG standard, a set of nine indicators that is used to determine whether a solution is a digital public good. You can see the nine relevant requirements for the digital public goods standard listed here, and DHS2 has been accepted and approved as one of the digital public goods. For example, the relevance to sustainable development goals, the use of approved open licenses such as the BSD3 clause license used by DHS2. Ownership platform independence documentation which is a key aspect of the DHS2 development process and is featured at docs.dhs2.org, mechanisms for extracting data, adherence to privacy and applicable laws which you will hear about in further sessions, adherences to standards and best practices, and doing no harm by design. The HISP Center at the University of Oslo is responsible for DHS2 software development, also implementation projects, capacity building and project support, as well as related research and education. There is organized around five groups, the software development team, the two groups under research and implementation that are looking specifically at information systems research and DHS2 implementation research, the training and communications team and project support. Now we'll take a look at the roadmap process. We conduct an initial prioritization of requirements annually in early September with key stakeholders that present their high level requirements. For example, their top five priorities per product. The key stakeholders that we seek input from are the ministries of health, the country governments represented by the regional HISP network divided into three geographical regions. The University of Oslo global project leads covering specific project deliverables and the University of Oslo management who represent the overall DHS2 strategy and direction. Once we've received these inputs we compile and analyze them with the product managers and technical leads of the DHS2 software combining similar features dividing up larger ones and resulting in a consolidated list of requests. Now for the final platform prioritization, another meeting held to convene the stakeholder groups to prioritize these high level tasks into a consolidated list of requests. This enables each stakeholder to adjust their own priorities and to rank inputs from the other groups. This list then guides the feature prioritization for upcoming releases. We're also learning more along the way and don't need to wait just for this process in order to get something onto the roadmap. For each individual release product managers meet with stakeholders to assess progress against prioritizations and add specific features to the next release to continue to work towards those priorities. In the annual roadmap and prioritization process we follow a ranking of four kind of inputs, country and ministry requests which are collected through this annual roadmap prioritization workshop, and also attending routine design meetings on specific features and functionality that have been requested. We also track deliverables and security requirements that come through the various partnerships that we have technical upgrades and ongoing system modernization to stay abreast of new developments and improve the architecture and platform responsiveness. And finally all requests coming through the community of practice being communicated to us either through the community of practice website, or also through direct communication and learning that's coming from the implementation and research that is being conducted by the university. This is just an illustrative timeline of the roadmap process steps starting at the beginning of the year. We have two annual releases of the platform in April and October. We begin the planning for the following release the month before the first release is done. And we have this annual platform prioritization that takes place in the fall that is meant to consider the progress so far any new priorities that have come in and plan again for further into the future. So we'll take a look at some of the relevant tools associated with this process. The first place to look if you are wondering what is coming in the roadmap is that dhs to dot org slash roadmap, where we routinely publish and update the planned functionality for individual releases. This information is available not only as a full roadmap that combines all functionality but also can be dived into for specific parts of the platform such as platform analytics tracker or Android. We also will add checkmarks to functionality as they are completed so that you can be sure that they're coming in the planned version, and for those that do not get finalized in time for the expected version they will be moved on to the following version and you can continue to follow their progress. Another source to look at the dhs to functionality as it's being worked on is through our open JIRA. Anybody can make an account for JIRA or even browse anonymously. There are multiple dashboards available to follow the specific functionality that is being worked on. In fact, this is where we the software development team track our own progress. The functionality is broken down into specific tickets and issues within JIRA. You can get the details for what that functionality will include. You can even interact through comments and ask questions and see if the functionality that you are seeking is meant to be included in the next release. So just giving you a look at the way that you could submit your own feature request using JIRA, creating a description of what the functionality would be. This would typically come from the community as user stories that would describe what the challenge is what you would like to be able to accomplish. And the response to this would come through in the form of some kind of functional design that would be added to a feature request. You can interact with the developers through JIRA you can see to the right who reported an issue and who is currently assigned. You can check the status of the development, which will be updated throughout the course of the development process. And again at the bottom you can add comments and ask questions. In conclusion, the dhs to software development is based on a public roadmap established through a transparent prioritization process. dhs to is a digital public good used in a large number of use cases, development of the core software focuses on generic features that are broadly useful, not specific to a single use case. The his center at the University of Oslo manages the prioritization process with input from stakeholders, including countries ministries of health, donors and others. The details on this process and the upcoming releases can be found on the dhs to website at dhs to dot org slash roadmap and feature request can be submitted and tracked on JIRA.