 In this session, we'll talk about extending DHIs to and the various options available. We will learn how to recognize where DHIs to core functionality could be improved or extended to better address a specific use case. We'll also contrast the various types of extensions which are available in the DHS to ecosystem. And finally, we'll learn how to determine how best to extend DHS to for the target audience or workflow. First, we'll learn about identifying the need to extend DHS to. DHS to is designed as an extendable platform. It can be customized to fit the needs of many projects and programs through the user interface with no coding skills required. This is often the easiest way to customize DHS to for a specific use case. For some uses, however, the native customization functionality is not flexible enough to provide added flexibility. DHS to has been designed to support the extending of the core software with custom plugins, Android and web applications integrations with external services and automation scripts. To identify the need to extend DHS to it's important to recognize where the core functionality of DHS to does not fully address the needs of your use case. The most common reasons to extend DHS to include user experience challenges, lack of inherent functionalities built into the core platform, a need to integrate with external systems and gaps in the native DHS to data model. In many cases, there might be a mismatch between the terminology used in DHS to and the organization's existing terminology. In these cases, it might be necessary to build a custom application. There are ways to address these terminology mismatches through the native customization functionality built into DHS to. However, if those needs go beyond the core capabilities, it might be possible to extend the core platform. Additionally, there may be specific processes or workflows which are not natively supported. For example, it may be necessary to simplify the user interface to support specialized tasks and specialized data entry users within DHS to Another common use case for extending DHS to is addressing a lack of functionality within the core DHS to platform. There is sometimes a need to add certain functionality to increase the relevance of the tool or app to a certain user group, potentially accommodating existing work practices. It may be necessary to integrate with pre existing specialized external systems. Extensions to DHS to can take care of data transfer or sharing with these external systems. Those systems might provide functionalities that are beyond the scope of what DHS to can do out of the box. For example, they might be dedicated platforms for advanced statistical analysis. They might be portals providing public access to healthcare data, or they might be other components of an integrated health information architecture, such as a client registry, a facility registry, or others. Finally, it might be necessary to extend DHS to to address gaps in the core data model. There are some situations where the DHS to data model is not sufficient to meet program needs. For example, the relationship model might need to be extended to address contact tracing or communicable diseases. Similarly, organization units or facilities and districts and national boundaries might need additional properties or features that are not built into DHS to natively. Next, we'll talk about the various extension options available and compare when and how to choose between them. There are several options for extending DHS to without altering the source code. These include dashboard plugins, web applications, Android applications, as well as integrations and scripts. We'll talk about each of these in turn. In addition to these extension options, it is also possible to modify the source code and create custom versions of DHS to components such as tracker widgets, custom APIs, dashboards, and more. However, this leads to significant additional maintenance challenges. Finally, it's possible to create custom applications outside of the DHS to platform. Developing fully standalone systems or applications is outside the scope of this presentation, but they can be the target of integrations which are extensions to DHS to. First, we'll discuss dashboard plugins. Dashboard plugins are widgets which can be added to the user dashboard to show additional content. They tend to be small, relatively simple, and display some configurable data visualization or use case specific contextualizing information. Some reasons you might choose to use a dashboard plugin include addressing missing functionality, for example, the built-in analytics plugins may be insufficient for your needs. For addressing user experience challenges, such as presenting additional information, new visualization types, and more to help dashboard users view information and contextualize it for their specific use case. Some advantages of dashboard plugins include that they are relatively easy to create and maintain. They're also typically simple to use with no significant learning curve for users. However, there are also limitations to this type of extension. Dashboard plugins offer limited functionality and should typically be read only so they cannot address or should not address situations where the user needs to modify data in the DHS to data model. Additionally, functionality can be limited to data visualization. Dashboard plugins are not meant for data collection system configuration or other non visualization use cases. Another type of extension in DHS2 is a custom web application. This is a standalone app that a user can select from the application menu. A web application can do anything the core web applications such as dashboards, data visualizer, capture, and more can do within the constraints of the DHS2 data model and API. The data store and user data store APIs can be leveraged to extend the DHS2 data model in small ways when building a web application. Some reasons to choose a web application when extending DHS2 include addressing missing functionality where the built-in applications in DHS2 do not support the user needs. Additionally, they can help to address user experience challenges where very specialized workflows and user interfaces are required for a particular use case. And finally, they can be useful in addressing data model gaps where the built-in data model cannot represent something needed for a particular use case. Some advantages of building web applications include full control of the user experience. The web application can be built in a way that targets the specific workflow and needs of the user base for this particular application. Additionally, the web application can access DHS2 APIs to leverage the core data model and to extend it through the data store. There are also some limitations to this type of extension. A web application is more difficult to develop and maintain than a plugin. Additionally, a web application cannot fully extend the data model or securely integrate with external systems, as we'll see in future types of extensions. You'll learn about the special considerations for custom applications in more detail later in this course. Another type of extension in the DHS2 ecosystem is an Android application. This is a custom mobile application which runs on Android mobile devices. They can leverage the DHS2 Android SDK to interact with the DHS2 server and data model, whether the user is online or offline. Some reasons to choose an Android application when extending DHS2 include addressing missing functionality. For example, the core Android capture app does not support the user needs for a specific use case. An Android application can address user experience challenges. This will allow the application to present specialized workflows and user interfaces that are required for a particular mobile use case. Finally, an Android application can also address data model gaps where the built-in data model cannot fully represent something needed for a particular use case. One of the advantages of building an Android application when extending DHS2 include having full control over the user experience. Similar to a web application, the developer of an Android application can control and design an interface that directly applies to the use case being designed for. Android applications are easy to use and familiar to low-level users who are comfortable installing and using Android applications in their everyday life. There are some limitations to Android applications as well. For example, they have high development and maintenance costs because a custom application needs to be built and maintained over time. Additionally, these Android applications are only available to users with Android mobile devices and not others such as iOS or Windows. Next, we'll discuss integrations and scripts, which are our final way to extend the DHS2 platform. Integrations connect DHS2 with other digital systems. These can be other DHS2 instances, other digital public goods like OpenMRS or RapidPro, or even bespoke local systems which are often developed and maintained in a single country. Data and events from one of these systems can be set up to trigger actions or updates in another system. Scripts are one way to automate tasks in DHS2 and can be an element in these system integrations. There are several reasons to use an integration or script when extending DHS2. The first is a need to integrate with existing or new external systems. The second is addressing missing functionality in the DHS2 core. For example, DHS2 does not support lab information management, but could integrate with an external LIMS system. Finally, integrations and scripts can address data model gaps. For example, the data in DHS2 might need to be enhanced or extended by an external system such as is the case when individual tracker data might be aggregated and then imported into a data set in a separate aggregate HMIS system. There are many advantages to using integrations and scripts. These include leveraging existing investments and established systems rather than reinventing them within or around DHS2. Integrations and scripts can also support workflows that require data to be processed and transferred in an automated way. However, there are also limitations as with every type of extension in the DHS2 ecosystem. For integrations and scripts, it can be challenging to develop and maintain, especially with security and performance considerations. Additionally, building and maintaining these integrations and scripts requires technical system administrators to understand and deploy often sophisticated server side components. When deciding which type of extension to use to extend the DHS2 core functionalities, it's important to try to make as small an extension as possible. Think about how you can achieve what is needed with a minimal amount of customer development. This is important because it's also important to consider long term implications of extensions. They will need to be maintained over time and this will cost money. For web and Android applications, this will be discussed in more detail later in the session on developing and maintaining custom applications. Additionally, it's important to try to keep the experience for the end user as simple and easy to understand as possible. This includes leveraging knowledge that users already have about the DHS2 ecosystem when designing new interfaces. To summarize, DHS2 can be extended in multiple ways to better address specific use case needs. These extensions often address common challenges such as user experience challenges, lack of functionalities, integration with external systems, and gaps in the DHS2 data model. The extensions developed to address these needs can take multiple forms including dashboard plugins, web applications, Android applications, as well as integrations and scripts. It's important to consider the implementation needs and the trade-offs when choosing to develop custom extensions of one type or another.