https://dhis2.org/integration/
Data Capture
Validation
Analysis
Presentation
SDMX-HD and ADX standards for interoperability
SDMX: https://ec.europa.eu/eurostat/web/sdmx-infospace/trainings-tutorials
ADX: Aggregate Data Exchange
DHIS2 Web API
DHIS2 Core
It exposes REST API(s) over DHIS2 Core which we can utilise.
https://docs.dhis2.org/en/full/develop/dhis-core-version-master/developer-manual.html
DHIS2 provides Basic Auth, Two Factor Auth, Personal Access Token(PAT) and OAuth2. Basic Auth is the least secure and Two Factor Auth is for direct DHIS2 users.
PAT
By default PAT will have all the authorizations that the user has. This can be configured or a special user can be created having only the required permissions.
The token is configurable via API and only the constraints can be modified after a token is created.
Token key is returned only once when the token is generated.
Expiry of the token can be configured via Web API along with other constraints.
OAuth2
We can go with grant_type as password. This can be configured via Web API too. Grant_type password would involve sharing username and password. However, this will be in a POST call body.
http://43.205.92.152/dhis-web-commons/security/login.action
User: admin
Pass: district
List of the metadata which are required and there attributes
Note this data is extracted from the schemas endpoint of DHIS2
DHIS2 is District Health Information Software 2.
The DHIS 2 is a routine data based health information system which allows for:
data capture,
aggregation,
analysis, and
reporting of data.
The data model is generic in all dimensions in order to allow for capture of any item of data.
The model is based on the notion of a DataValue.
A DataValue can be captured for
any DataElement (which represents the captured item, occurrence or phenomena),
Period (which represents the time dimension), and
Source (which represents the space dimension, i.e. an organisational unit in a hierarchy).
Meta Data
Understanding on this
Remarks
DataSet
The DataSet is a collection of DataElements for which there is entered data presented as a list, a grid and a custom designed form.
A DataSet is associated with a PeriodType, which represents the frequency of data capture.
This is what is a campaign as per current understanding
Data Element
Basically a Form Field
The data element often represents a count of something, and its name describes what is being counted, e.g. "BCG doses given" or "Malaria cases".
Data Element Group
Group of Data Element
Indicator
Allows for data analytics and reporting. It is basically output of data capture. An Indicator is basically a mathematical formula consisting of Data Elements and numbers. The formula is split into a numerator and denominator.
IndicatorType
An Indicator is associated with an IndicatorType, which indicates the factor of which the output should be multiplied with.
A typical IndicatorType is percentage, which means the output should be multiplied by 100.
OrgUnit
Source or manageable area under which the data is captured
Category
METADATA Diagram taken from the DHIS2 technical documentation
The diagram is taken from the core technical documentation for understanding the relationships between the DHIS2:
While adding dhis2 client https://github.com/dhis2/dhis2-java-client
The following data is needed for DIGIT ecosystem
Boundary and Boundary Hierarchy is part of one time setup. All the fields cannot be fetched from the DHIS2 directly. Some manual intervention is needed.
DIGIT Field
DHIS2 Source
Comments
Code
DHIS2 has numerical short codes. DIGIT expects alphabets. We can directly use the Level codes - 1,2,3,4,5,6 as described by DHIS2
Boundary Hierarchy Type
Organizational Unit Level
Description
OrgUnit.Name
Clubbing projects and boundaries because both of these can be populated from same set of master data. These are directly correlated to Organisational Units. Targets to be fetched from forms. The forms of interest are “RTIs Metas Macroplano” and “RTIs Metas Microplano”. They are available at village level only. Projects and relevant targets can be fetched from the following boundary information.
DIGIT Field
DHIS2 Source
Comments
Boundary Code
OrgUnit.code
Boundary Name
OrgUnit.name
Parent Boundary Code
OrgUnit.parent.code
Boundary Type
OrgUnitLevel.name
Hierarchy Type Code
OrgUnitLevel
Campaign Start Date
Campaign End Date
Total Households
RTIs Metas Macroplano.Agregado familiar
Targetted Households
RTIs Metas Microplano.Agregados do Microplano
Total Individuals
RTIs Metas Macroplano.População
Targeted Individuals
RTIs Metas Microplano.População
Bednets estimated to be delivered
RTIs Metas Macroplano.Redes mosquiteiras
DIGIT Field
DHIS2 Source
Comments
Username
User.userCredentials.username
Can be kept same as DHIS2 username
Password
We will need to auto generate this, if user access needs to be provided.
Name
User.name
Mobile No
Not available
DHIS2 does not capture demographic and user information.
Gender
Not Available
DHIS2 does not capture demographic and user information.
Date of Birth
Not Available
DHIS2 does not capture demographic and user information.
Not Available
DHIS2 does not capture demographic and user information.
Correspondence Address
Not Available
DHIS2 does not capture demographic and user information.
Role
User.userRole
Multiple role assignments are possible. Role Maps need to be created between DIGIT and DHIS2 and appropriately assigned
Employment Type
Not Available
DHIS2 does not capture demographic and user information.
Date of Appointment
Not Available
DHIS2 does not capture demographic and user information.
Department*
Not Available
DHIS2 does not capture demographic and user information.
Designation
Not Available
DHIS2 does not capture demographic and user information.
Project
User.organisationalUnit
A user can be associated with multiple Organisational Units. We will need to map OU to Projects and appropriately map the project to the user
Product and Product variant are one time config
ration for a campaign. Unable to find equivalent in DHIS2. Will need to double check.
For Mozambique, the following are being tracked on DHIS2 at a team level.
Red Sticker
Green Sticker
Bednet
At the district and community warehouses only bed nets are being tracked.
OrgUnits have shapes (geometry) associated with them. Granularity is available only till district level. If we have to generate the shapefile dynamically, it will be tedious. Would be better to check with the CHAI team about how they are downloading the shapefiles from DHIS2 and replicate.
Unable to find on DHIS2. Will need to check with Mrunal and CHAI team.
Types of Data
There are two types of transactional data that we need to ingest into DIGIT from DHIS2.
Beneficiary - In the case of Moz it is Household data.
Service Delivery - In the case of Moz, this is the bed net being distributed.
Inventory management
Supervisor checklist - Forms are available in DHIS2, need to understand DIGIT models before this mapping can be done.
The following forms contain transactional data in DHIS2
DHIS2 Form
Translation
Comments
Ficha de entrega de material - Monitor (Entrega e Devolução)
Material delivery form for monitor.
Not sure about where this can be used. This contains details for all materials used as part of campaigns. Red stickers, Green stickers, bednets etc.
Ficha de entrega de material - Provincial (Entrega e Devolução)
Material delivery form - Provincial (Delivery and Return)
Need to understand use case
Ficha de entrega de material - Logistico (Entrega e Devolução)
Material delivery form - Logistics (Delivery and Return)
Need to understand use case
Ficha de Registo dos Agregados Familiares
Household registration form
This is the form of interest. This contains the service delivery information.
Gestão De Stock - Começo de cada dia
Stock management - Start of every day
This is stock management to each distribution team. How many Red and Green stickers, bed nets etc are being given to each team at the beginning of the day. Not of interest.
Gestão De Stock - No final de cada dia
Stock management - End of each day
This is stock management to each distribution team. How many Red and Green stickers, bednets etc are returned by the team at the end of each day. Not of interest.
AD (Armazém distrital) - Entradas
District Warehouse - Entry
AD (Armazém distrital) - Saidas
District Warehouse - Exit
AD (Armazém distrital)- Contagem física
District Warehouse - Physical Count
AC (Armazem Comunitarial) - Entradas
Community Warehouse - Entry
AC (Armazem Comunitarial) - Saidas
Community Warehouse - Exit
AC (Armazem Comunitarial) - Contagem física
Community Warehouse - Physical count
This data is extracted from the form called “Ficha de Registo dos Agregados Familiares”. The only Beneficiary field available is the Head of household’s name and memberCount of the household. The rest of the required fields will be empty.
DIGIT Field
DHIS2 Source
Comments
projectId
OrgUnit
This is an acquired field from DIGIT<>DHIS2 master data mapping. It will be associated with the relevant OU at the village level
tenantId
clientReferenceId
FormEntry.ID
This is to store the DHIS2 internal unique identifier of this beneficiary record from the form. This will be the ID of the form instance
memberCount
Número de membros do agregado familiar que vivem na mesma casa (incluindo o(a) chefe do agregado familiar)
address.tenantId
address.doorNo
NA
address.latitude
FormEntry.latitude
address.longitude
FormEntry.longitude
address.locationAccuracy
NA
address.type
HOUSEHOLD
address.addressLine1
NA
address.addressLine2
NA
address.landmark
NA
address.city
OrgUnit?
Can we populate from OrgUnit or can we ignore this
address.pincode
NA
address.buildingName
NA
address.street
NA
address.locality.code
OrgUnit.code
address.locality.label
OrgUnit.name
address.locality.latitude
NA
address.locality.longitude
NA
This data is extracted from the form called “Ficha de Registo dos Agregados Familiares”.
DIGIT Field
DHIS2 Source
Comments
projectId
OrgUnit
This is an acquired field from DIGIT<>DHIS2 master data mapping. It will be associated with the relevant OU at the village level
tenantId
clientReferenceId
FormEntry.ID
This is to store the DHIS2 internal unique identifier of this beneficiary record from the form. This will be the ID of the form instance
projectBeneficiaryId
DIGIT BeneficiaryID
After the beneficiary is created, we will need to fetch that ID and populate this field
resources.tenantId
resources.productVariantId
This is the product variant being distributed. Will be part of MDMS. We were told that if we configure at project level in MDMS, it will be auto populated.
resources.quantity
FormEntry.Número de redes distribuídas
resources.isDelivered
This will always be true, because entry is created in DHIS2 after service delivery
resources.deliveryComment
FormEntry.Observações
plannedStartDate
plannedEndDate
actualStartDate
actualEndDate
createdBy
FormEntry.Selecione equipe de distribuição
This is the name of the DHIS2 user who created this record. We will be importing these users as part of master data import, the equivalent DIGIT userID to be populated here.
createdDate
address.tenantId
address.doorNo
NA
address.latitude
FormEntry.latitude
address.longitude
FormEntry.longitude
address.locationAccuracy
NA
address.type
HOUSEHOLD
address.addressLine1
NA
address.addressLine2
NA
address.landmark
NA
address.city
OrgUnit?
address.pincode
NA
address.buildingName
NA
address.street
NA
address.locality.code
OrgUnit.code
address.locality.label
OrgUnit.name
address.locality.latitude
NA
address.locality.longitude
NA
At the start of the campaign we will need to ingest data from the physical count form. Entry and Exits are tracked through the entry and exit form mentioned above. We will need to do this for District and Community warehouses. The fields remain the same only the forms are changing. Which means the appropriate IDs will also change. The following are the forms:
AD (Armazém distrital) - Entradas
District Warehouse - Entry
AD (Armazém distrital) - Saidas
District Warehouse - Exit
AD (Armazém distrital)- Contagem física
District Warehouse - Physical Count
AC (Armazem Comunitarial) - Entradas
Community Warehouse - Entry
AC (Armazem Comunitarial) - Saidas
Community Warehouse - Exit
AC (Armazem Comunitarial) - Contagem física
Community Warehouse - Physical count
DIGIT Field
DHIS2 Source
Comments
clientReferenceId
FormInstance.ID
This is will be unique identity of the FormEntryInstance
tenantId
facilityId
Armazém distrital
This will be the district warehouse or community warehouse ID. We will need to fetch and do a mapping. This facility will be mapped to the project so we need only the facilityId.
productVariantId
This is a DIGIT field, created as part of master data creation
quantity
Nr. da guia de remessa *
referenceId
Unsure of what this is
referenceType
Entrada ou Devolucao
Entry or Exit
transactionReason
Entrada ou Devolucao
Return
transactingPartyId
User ID of the transacting party
transactingPartyType
WAREHOUSE
The spec of the survey service is being worked on at the product side. Once the design is completed, this section will be addressed.
On DHIS2 there is a single form that captures Bednet distribution as well as household registration (Both the required transactional data fields). This form is called “Ficha de Registo dos Agregados Familiares”. We will have to convert this single form data into two DIGIT payloads - Beneficiary and Benefit (or Service Delivery or Task).
All data is collected at a village level only in DHIS2. This form has the following fields.
DHIS2 Field Name
DIGIT Field
Comments
Org Unit
Beneficiary.projectId, Beneficiary.address[].locality,
Benefit.projectId,
Benefit.address[].locality
This corresponds to the Village in which the Bed Nets are distributed. Each Org Unit has a different unique identifier. This mapping needs to be maintained in configuration.
Latitude
Beneficiary.address[].latitude,
Beneficiary.address[].locality.latitude
Benefit.address[].locality.latitude, Benefit.address[].latitude
Longitude
Beneficiary.address[].longitude,
Beneficiary.address[].locality.longitude
Benefit.address[].locality.longitude, Benefit.address[].longitude
Equipe de distribuição
Beneficiary.userId, Benefit.createdBy
This is the user who does the distribution. Typically this is the user who distributes the Bednets.
Data hoje
Beneficiary.dateOfRegistration, Benefit.plannedStartDate, Benefit.plannedEndDate, Benefit.actualStartDate, Benefit.actualEndDate, Benefit.createdDate
Date when the form was filled/service was delivered.
Nome do(a) chefe do agregado familiar
Beneficiary.name.givenName
DHIS2 captures the full name of the head of the household. There is no way to syntactically split it into Given Name, Surname and otherNames as needed for the DIGIT ecosystem. So the assumption is that only the givenName will be populated
Selecione equipe de distribuição
Beneficiary.userId, Benefit.createdBy
Número de membros do agregado familiar que vivem na mesma casa (incluindo o(a) chefe do agregado familiar)
Beneficiary.memberCount
Número de redes por atribuir
No equivalent in DIGIT payload for service delivery. This is a calculated field on the UI. No persistence. The aggregate for a village will be persisted at the equivalent project level.
Número de redes distribuídas
Benefit.resources[].quantity
Observações
Benefit.deliveryComment
Verifique se seus números estão corretos antes de finalizar este formulário
This field is to let the distributor validate the information present in the form.
DHIS2 Field Name
Translation
DIGIT Field Mapping
Comments
Entrada ou Devolucao
Incoming or Outgoing
Armazém distrital
District warehouse
Identificação do fiel armazém (nome completo)
Identification of the faithful warehouse (full name)
Proveniência
Provenance
Especficar
Specify
Nr. da guia de remessa
Delivery note number
Nr. matrícula ou tipo de transporte
Registration no. or type of transport
Quantidade de redes indicadas na guia de remessa
Quantity of nets indicated on delivery note
Quantidade de redes recebidas
Quantity of nets received
Comentário
Comment