For the complete DHIS2 documentation index, see llms.txt.

Aumentar a escala¶

Acquisitions¶

Scaling up a DHIS2 Android implementation is a complex but manageable process that begins after thorough testing and piloting. At this stage, decisions must be made regarding hardware acquisition, app distribution strategy, mobile device management, training programs, and—if relevant—SMS infrastructure. Planning well at this stage ensures stability, sustainability, and user satisfaction as the system is deployed at larger scale.

Purchasing of devices vs BYOD (bring your own device)¶

Initially you should buy different devices to allow users to evaluate them and provide you with feedback. Once the device that you will be using is decided upon, you should only buy 10 or less units, or whatever is needed for the testing and the pilot phases. Only when the pilot is coming to completion, you should buy equipment for the next 6 months roll-out. Some very large projects will take years for a national roll-out, and your hardware adquisicion plan should expand across years. Recommendations on the technical specs for devices are in the chapter Mobile devices specifications.

Você deve considerar a viabilidade de usar uma política de BYOD - este formato permite que os usuários tragam seus próprios dispositivos, desde que atendam a um padrão técnico mínimo, que você definirá para seu projeto. Normalmente, você oferecerá algum tipo de incentivo, provavelmente na forma de eCash ou tempo de antena. As vantagens desta abordagem são óbvias: evita o grande custo inicial de aquisição, bem como reduz os custos de administração e considerações logísticas. Por outro lado, você terá o desafio de um ambiente de hardware muito heterogêneo, ou seja, diferentes dispositivos e versões do sistema operacional Android. Isso afeta principalmente o processo de depuração.

Distribution of the app (now and later)¶

The DHIS2 Android Capture App is actively maintained, with four releases per year: two regular feature (minor/major) releases, and two patch releases focused on bug fixes and stability improvements. Each version is tested for compatibility with supported DHIS2 server versions and includes detailed release notes.

In addition to these scheduled releases, interim APKs may also be published when new or updated translations are submitted through Transifex. These APKs reflect the latest available language support and are especially valuable for multilingual implementations or training needs in local languages.

The official distribution channels are:

Google Play Store: Recommended for smaller implementations or BYOD scenarios. The app is available at DHIS2 on Play Store. Note that apps installed from the Play Store may auto-update unless this is manually disabled on the device.
GitHub Releases: Every official version is published on DHIS2 GitHub, where you can download the APK files manually. APKs installed this way will not update automatically, which is preferable for implementations requiring version control and pre-release testing.

As an implementer, once your testing and training materials are finalized, it is critical that the app version used during training is frozen and not updated automatically during rollout. New versions can introduce changes in UI, program rule behavior, or compatibility issues with your specific configuration. Each new version should be carefully tested before adoption.

For larger implementations, we recommend:

Avoiding auto-updates from the Play Store by disabling them on all devices.
Using a Mobile Device Management (MDM) system or custom APK hosting page to control which version is used and when it is updated.
Clearly documenting the version and configuration used during training to ensure consistency throughout rollout.

Note If MDM tools are not available, alternatives include APK distribution via a secure internal portal, shared folders, or QR-based install links generated during configuration.

For detailed guidance on MDM and alternative distribution options, refer to the Mobile Device Management section.

Alternatives and Complements to MDM: APK Distribution Strategies¶

If a full MDM setup is not feasible, there are alternative methods to distribute and manage the DHIS2 Android app, depending on the technical capacity of your team and the scale of the implementation.

APK Distribution Web App

To support projects that need controlled rollout without complex infrastructure, the DHIS2 Android team provides an official APK Distribution Web App. This tool allows administrators to host a simple internal or public-facing webpage that shares trusted APK builds.

This method is especially effective when:

You want to lock the app to a specific version that has been tested and validated.
Google Play is unreliable or blocked.
Updates need to be managed manually, not automatically.

The app provides version history, changelogs, and contextual guidance. Devices must allow installations from unknown sources, but this approach is simple to maintain and widely adopted across DHIS2 implementations.

Google Play Store (with Caution)

Installing the DHIS2 Android Capture App from the Google Play Store provides convenience, but should be used carefully in structured rollouts. Automatic updates can break compatibility or introduce UI changes unexpectedly. If Play Store is used, configure devices to disable auto-updates for DHIS2, or restrict them via managed Play Store in enterprise setups.

F-Droid and Private App Repositories

Some implementers prefer using F-Droid, an open-source Android app repository that allows for hosting private app channels. With F-Droid, you can offer secure, controlled app delivery without relying on commercial app stores. However, it has limitations in bandwidth control and device management.

Choosing the Right Approach

Ultimately, the right distribution and device management strategy depends on:

The number of users and devices.
Whether devices are owned by the institution or BYOD.
Network availability.
Security needs.
Your internal support capacity.

For smaller rollouts or pilots, a shared APK via a webpage or Google Drive folder might suffice. For national programs, an MDM combined with APK hosting and a robust SOP for app version control is highly recommended.

Telecommunication contracts¶

If your installation plans to include the use of SMS for transmitting selected records via SMS when mobile data is not available, you will need to establish a contract with a local aggregator which can provide you with an incoming number to receive the SMS. You should configure your server to receive & send SMSs - please see DHIS 2 developers documentation on SMS connections . You will need to estimate the number of messages per month to be able to forecast the monthly cost.

O processo de seleção e assinatura de um contrato com um provedor de SMS varia de acordo com o país e depende dos procedimentos de aquisição de sua organização.

Planning large acquisitions¶

Cada projeto precisará de uma combinação de tipos de dispositivos: telefones, tablets e Chromebooks. A maioria dos dispositivos móveis provavelmente será alocada a um usuário dedicado. Os itens a serem considerados incluem a natureza do trabalho. Por exemplo, os trabalhadores comunitários usarão smartphones ou tablets. Mas os profissionais de saúde que trabalham em uma instalação podem preferir um tablet com um teclado externo ou um Chromebook.

A aquisição real em grande escala deve ser adiada o máximo possível. Inicialmente, a recomendação é comprar o mínimo de dispositivos possível para testar a configuração e dar algum nível de escolha aos futuros usuários. Uma vez que a decisão de mudar para um piloto for acordada, a segunda compra deve, idealmente, ser limitada aos dispositivos necessários para o piloto. Se o plano de implementação se estender por mais de um ano, a aquisição dos dispositivos também deve ser dividida ao longo do tempo: dispositivos melhores com a mesma faixa de preço são constantemente oferecidos pelos fabricantes em ciclos que variam entre 12-18 meses.

Exemplo de aquisição total de 100 a 1000 dispositivos.

Mês do Projeto	Estágio	Aquisição	# de dispositivos
Mês 2	Design e configuração inicial	Selecione 3 ou 4 fatores de forma possíveis. Compre de um ou dois fabricantes	2-8
Mês 4-6	Piloto	Compre apenas os dispositivos necessários para completar o piloto	10-30
Mês 6-12	Implementação - fase 1	Primeira aquisição em massa	50-500
Mês X	Implementação da Fase X	->	50-500
Mês 36-48	Substituição de atualização	Substituir dispositivos	X

Mobile Device Management¶

Gerenciamento de dispositivos móveis refere-se ao software usado para a administração de dispositivos móveis. Você precisará de um software MDM quando precisar oferecer suporte a centenas de dispositivos e for necessário controlar a distribuição do arquivo apk entre os dispositivos, fornecer suporte técnico e aplicar políticas institucionais. A maioria das opções é oferecida como serviços de taxa mensal. Alguns aplicativos gratuitos oferecem o modo quiosque, mas cobram uma taxa mensal pelo gerenciamento remoto básico.

Os recursos desejáveis de um software MDM podem ser classificados como básicos e avançados. Aqui está uma lista dos recursos desejáveis:

Recursos básicos:
Exigir uma senha de bloqueio de tela
Provisão de aplicativos autorizados
Bloqueie dispositivos e limpe as informações se eles forem perdidos ou roubados
Controlar a atualização do aplicativo Android
Aplicar políticas de backup
Características avançadas:
Aplicar políticas de força de senha
Aplicar políticas de uso de rede
Rastrear localização do dispositivo
Restringir o acesso a configurações e recursos (exemplo - wi-fi/rede, captura de tela)

Ao decidir qual é o melhor software de MDM para suas necessidades, deve tentar responder às seguintes perguntas:

Quantos dispositivos eu preciso gerenciar?
Com que frequência tenho acesso físico ao dispositivo?
Quais recursos eu realmente preciso?
Quais políticas devo implementar
Será difícil instalar e manter
Como isso afetará a experiência do usuário?
Precisamos permitir BYO? (Traga seu próprio aparelho).
Como isso afetará o dispositivo?

Na próxima página, você pode encontrar uma lista de softwares MDM disponíveis (lembre-se de que os preços e as condições mudarão com o tempo).

Mobilock Free (não é possível atualizar o software)
SOTI (MobiControl) (can be expensive - $2.20/device/month)
Miradore (sem suporte remoto)
Applock (incapaz de controlar a atualização do software)
AcDisplay (incapaz de controlar a atualização do software)
F-Droid (não é possível limitar o consumo de dados)
APPDroid (não é possível limitar o consumo de dados)
Lista Mestre (incapaz de controlar a atualização do software)
Firebase (não é possível limitar o consumo de dados)
Intunes (os usuários precisam fazer parte de uma implantação do MS Office 365)
MobileIron (pode ser caro - 3,15 USD / dispositivo / mês + 2,368 USD para implantação)
IBM Maas360 (muito caro - 1,60 USD / dispositivo / mês + 0,50 USD / dispositivo / mês para suporte remoto, para 3.000 dispositivos)
AirWatch (não responde e pode ser caro - 3,80 USD / dispositivo / mês para 3.000 dispositivos por 3 anos)
XenMobile (Citrix) (pode ser caro - 2,03 USD / dispositivo / mês para 3.000 dispositivos)
Bom para empresas (Blackberry) (pode ser caro - 2 USD / dispositivo / mês + 2,5K USD para implantação)

Note

Check the specific Mobile Device Management Guideline for more information about this topic.

Treinamento¶

Uma etapa importante antes do roll up é o treinamento dos usuários e se necessário, o treinamento das equipes de suporte aos usuários. Existem muitas estratégias de treinamento que você pode seguir e isso vai depender do tamanho do grupo que precisa ser treinado, seu nível de habilidade, o prazo disponível, o orçamento, etc. É importante que você coloque tempo e energia no projeto sua estratégia de treinamento e alocar tempo suficiente para cumprir seus objetivos de treinamento. Ter seus usuários bem treinados e informados reduzirá a ansiedade do usuário e os problemas de adoção e também aumentará a qualidade dos dados coletados.

Technical Preparations for the Training¶

Ao se preparar para o treinamento, certifique-se de que todos os requisitos técnicos práticos foram atendidos. Isso inclui ter os tablets / dispositivos móveis prontos, com o novo aplicativo DHIS 2 Capture Android instalado. Dependendo da disponibilidade de conectividade com a internet na área onde você irá realizar o treinamento, você pode ter todos os tablets pré-sincronizados com o servidor, para que você tenha dados suficientes e a configuração certa para o treinamento. Antes de fazer o treinamento , os exercícios devem ser testados para garantir que tudo esteja funcionando. Solucione problemas detectados durante o teste para que não apareçam durante o treinamento. Você pode querer fazer uma segunda rodada do teste para detectar quaisquer problemas perdidos na primeira rodada.

Se o treinamento for feito com dados e configuração pré-sincronizados, ao final do treinamento, certifique-se de permitir que os trainees experimentem o App acessando o servidor remoto DHIS 2. Isso dará aos trainees a possibilidade de experimentar uma experiência de sincronização na vida real, que pode incluir atrasos na rede. Sem sofrer atrasos, eles podem posteriormente interpretar os atrasos da rede como falhas em seus dispositivos.

Training Budget¶

A seguir, há algumas diretrizes sobre a preparação do orçamento, retiradas das DHIS 2 Community Health Information System Guidelines publicado pela Universidade de Oslo:

Siga as políticas organizacionais ao usar taxas e modelos de orçamento aprovados (indireto, DSAs, etc.) para todas as despesas, incluindo:
Viagem (por exemplo, combustível, aluguel de carro, hospedagem)
Pessoal (por exemplo, diárias, custos de refeição)
Local (por exemplo, espaço para conferências, intervalos para chá)
Materiais (por exemplo, impressão, hardware, projetores)
Itens variados
Elabore o orçamento com base em cálculos em folha de materiais necessários, custo unitário desse material e número de unidades necessárias. Você também pode criar multiplicadores adicionais para ilustrar o número de unidades por participante. Isso permite flexibilidade na atualização do orçamento se os custos unitários mudarem ou o número de participantes aumentar ou diminuir.
Orçamento de despesas antecipadas em moeda local, com uma taxa de conversão embutida (que pode ser atualizada conforme necessário) para converter para a moeda desejada de sua organização ou financiador. (2).

Training Agenda¶

O documento [DHIS 2 Community Health Information System Guidelines] (https://s3-eu-west-1.amazonaws.com/content.dhis2.org/Publications/CHIS+Guidelines+En.pdf) escrito pela Universidade de Oslo recomenda que você considere:

O tipo de assento de que necessita (mesa redonda, secretárias individuais, etc.).
Requisitos tecnológicos (computadores para todos, largura de banda Wi-Fi, etc.),
Financiar subsídios para centros de conferências, alimentos e bebidas para participantes
Os treinadores precisam de espaço para caminhar e observar e ajudar cada participante.

Esteja ciente do número de participantes que você espera em cada treinamento, pois será necessário fornecer materiais e espaço suficientes. O espaço do evento deve ser grande o suficiente para o grupo e também apropriado para as atividades planejadas.

Training Materials¶

No mesmo documento, encontramos recomendações também para os materiais de treinamento, que incluímos aqui. Os materiais de que você precisará para seus treinamentos dependerão de suas atividades. Para garantir que você esteja planejando tudo, analise sua agenda de treinamento com um parceiro e discuta o que será feito em cada parte do treinamento, anotando os materiais necessários.

A agenda das sessões de treinamento deve ser definida bem antes do treinamento e incluída nos materiais distribuídos.

A documentação do usuário deve ser empacotada em manuais mínimos. Estes manuais explicam uma tarefa de trabalho específica (por exemplo, insira dados mensais do registro de saúde da aldeia ou compare a saúde em sua aldeia com as das aldeias vizinhas). Depois de explicar a tarefa de trabalho, o Manual mínimo fornece instruções passo a passo numeradas com capturas de tela, para que os usuários saibam o que fazer. Lembre-se de que os Manuais mínimos NÃO explicam a funcionalidade do aplicativo, um por um, como um manual de usuário de fornecedor típico. Uma vez que os usuários preferem fazer e não ler, os manuais devem ser o mais curtos possível, mas contendo todas as etapas.