Concepts
Learn about the different types of concepts and their nuances
Concepts define the different pieces of information that you collect as part of your service delivery.
For example, if you collect the blood pressure of a subject in a form, then "Blood Pressure" should be defined as a concept. You would notice that every question in a form requires a concept.
The datatype of a concept determines the kind of data can be stored against a concept, and therefor against the form question or form element. Using concepts with datatypes ensures incorrect answers are not captured in a form question, and is helpful for eventually data aggregation, validation and reporting.
Supported DataTypes in Concepts
The following datatypes are supported while defining concepts to be used in forms:
Concept DataType | Description |
|---|---|
Numeric concepts | Numeric concepts are used to capture numbers. When creating a numeric concept, you can define normal ranges and absolute ranges. In the field application, if an observation for a concept collected goes beyond the normal range, then it is highlighted in red. Values above the absolute range are not allowed. For instance for concept: Blood Pressure (Systolic), you can choose a Numeric concept with ranges. |
Coded concepts (and NA concepts) | Coded concepts are those that have a fixed set of answers. For instance for Blood Group you would choose a coded concept with values: A+, B+, AB+, etc. These answers are also defined as concepts of NA datatype. |
ID datatype | A concept of Id datatype is used to store autogenerated ids. See Creating identifiers for more information on creating autogenerated ids. For instance PatientIDs, TestIDs, etc. |
Media concepts (Image, Video and Audio, File, ImageV2) | Images and videos can be captured using Image and Video concept datatypes. To capture Images with geotagging and other metadata associated, ImageV2 datatype can be used. For audio recording, Audio datatype can be used. For other generic file types, File datatype can be used. |
Text (and Notes) concepts | The Text data type helps capture one-line text while the Notes datatype is used to capture longer form text. |
Date and time concepts | There are different datatypes that can be used to capture date and time.
|
Location concepts |
Location concepts have 3 attributes:
|
Subject concepts |
Each Subject concept can map to a single subject type. Any form element using this concept can capture one or multiple subjects of the specified subject type. |
Phone Number concepts | For capturing the phone number. It comes with a 10 digit validation. OTP verification can be enabled by turning on the "Switch on Verification" option. Avni uses msg91 for OTP messages, so msg91 |
Group Affiliation concepts | Whenever automatic addition of a subject to a group is required Group Affiliation concept can be used. It provides the list of all the group subjects in the form and choosing any group will add that subject to that group when the form is saved. |
Encounter |
Each Encounter concept can map to a single encounter type. It should also provide the scope to search that encounter. Also, name identifiers can be constructed by specifying the concepts used in the encounter form. Any form element using this concept can capture one or multiple encounters of the specified encounter type. |
Showing counselling points in Forms
For showing counselling points in a form, always create a Form Element, using below coded Concept:
- Concept UUID: b4e5a662-97bf-4846-b9b7-9baeab4d89c4
- Concept Name: Placeholder for counselling form element
- Answers: <None, no answers, to avoid showing them any options>
Specify counselling point as the Form Element Name, add numbering if needed.
Note: You can reuse the same "Placeholder for counselling form element" multiple times in a single form, without worrying about uniqueness constraint breach concerns.
Location Concept Configuration
General Location Concept Behavior
When "Within Catchment" is set to FALSE
When using a "Location" type concept with "Within Catchment" set to false:
- You must ensure that you perform update of the form(s) using that concept
- So that on form save, the
organisation_configsettings gets auto-modified to sync locations outside catchment to the user's device - This ensures all locations are accessible while filling the form
When "Within Catchment" is set to TRUE (default)
When this option is enabled:
Requirements:
- Every user's catchment configuration must contain all required "Highest Level" type locations
- Without this, the form will not display any locations for selection
Display Behavior:
- Even if some users' catchments have locations higher than the Location concept's "Highest Level" type, those higher levels will not be shown
- The listing will start from the "Highest Level" type
- All locations across different lineages will be bunched together in a single list
CSJ Organization - Important Notes
Catchment Configuration Requirements
Note for CSJ org support: Please keep the following details for future reference:
-
Catchment Level: For CSJ org, User Catchments must be configured at District Level and above. This is due to the
HighestAddressLevelTypeconfiguration set for:- "Address of Applicant" in "Case" Registration
- "Address of applicant - Claim" in "Claim" Registration
-
Location Hierarchy: User Catchments should include both "Administrative State" and "State" hierarchy locations.
Known Limitation
Due to the form concept configuration restriction mentioned above:
- State information will not be shown on the app while filling in the address fields
- This applies irrespective of the catchment configuration for a user
- For users with large catchments, all districts across different states will appear in a single listing
- There is no ability to categorize districts by their respective states
Updated 7 days ago
