Skip to main content

Introduction

This documentation covers the OpenSRP Android App, which is code-named "FHIR Core" throughout. FHIR Core is a Kotlin application for delivering configurable, offline-capable, and mobile-first healthcare project implementations.

FHIR Core is architected as a FHIR-native platform powered by Google's Android FHIR SDK and HAPI FHIR. FHIR Core users experience a module-oriented design based on over a decade of real world experience implementing digital health projects with OpenSRP.

This repository contains the Android mobile application built to:

  • Load configuration data as FHIR resources
  • Support the WHO Smart Guidelines
  • Manage the identities of healthcare workers (HCWs), community health workers (CHWs), care teams, patients, and clients
  • Collect, view, and edit healthcare data with dynamic forms using FHIR's Structured Data Capture (SDC) implementation
  • Securely store healthcare data encrypted at rest and securely transmit healthcare data using TLS
  • Manage location hierarchies defined by community to national and international administrative boundaries

For remote data storage and login, the mobile application requires:

Programming Language​

Kotlin v1.7.10

Android Libraries​

  1. Hilt- for dependency injection
  2. Jetpack Compose - for building sharable declarative Android UI
  3. Jetpack Compose navigation - to navigate between compose screens
  4. Android navigation component - to navigate between activities and fragments
  5. Android Livedata and ViewModel

Architecture​

The app is architectured in the following manner:

  1. The app is built around MVVM architecuture with the data layer implemented using the Repository pattern.
  2. The entry point of the application also follows Single-Activity architecture after the user is logged in.

Generated documentation is available here.

Data Access​

The application uses FHIR Engine APIs from Google's Android FHIR SDK (which internally uses Room libary) to access the local Sqlite database.

Configurations​

The application syncs particular resources (conventionally, Composition and Binary) from the HAPI FHIR server to configure the app. The configurations control application workflows as well as the look and feel of the app.

Testing​

The OpenSRP Android app includes automated style, coverage, unit, user inteface / integartion, and performance testing. All tests are run through github actions on pull request and must be passed for a pull request to be merged without an admin override.

Style and coverage tests​

We use ktlint via spotless to run style checks against the entire codebase. We target to make these style checks as strict as possible in order to reduce bikeshedding in code reviews.

We use Jacoco for code coverage report generation and then codecov to track changes in coverage over time. We enforce a minimum coverage percent on the new code added in a pull request and a minimum reduction in overall coverage percentage change when consider the changes introduced through a pull request.

Unit tests​

Unit tests are divided among the engine, geowidget, and quest modules. These can be run locally and are run automatically through github actions when you submit a pull request. All tests must pass for a pull request to be merged.

User interface and integration tests​

We run tests against screen renderings that function as user interface and integations tests. These are defined in the quest module. These can be run locally and are run automatically through github actions when you submit a pull request. All tests must pass for a pull request to be merged.

Performance tests​

We include a set of performance tests to verify that the time taken to perform operations is not changing significantly as the code changes. These measure relative performance when running on the hosted continuous integration testing system and are not meant to reflect the amount of time an operation takes in a real world on-device scenario.