This page shows how openIMIS vocabulary codes map to PublicSchema canonical values. If you work with openIMIS and spot an error, please report it.
10 vocabularies covered: 10 value mapping. 1 property mapping.
Vocabularies
| Vocabulary | System name | Relationship | Coverage | Gaps |
|---|---|---|---|---|
| delivery-channel | PayTypeChoices | Value mapping | 3/4 mapped | 3 not covered |
| education-level | Education | Value mapping | 6/7 mapped | 3 not covered |
| gender-type | Gender | Value mapping | 3/3 mapped | 1 not covered |
| group-role | GroupIndividualRole | Value mapping | 14/14 mapped | 4 not covered |
| group-type | FamilyType | Value mapping | 6/6 mapped | 1 not covered |
| identifier-type | Value mapping | 4/4 mapped | 16 not covered | |
| payment-status | BenefitConsumptionStatus | Value mapping | 7/7 mapped | 4 not covered |
| relationship-type | Value mapping | 13/13 mapped | 7 not covered | |
| sp/enrollment-status | BeneficiaryStatus | Value mapping | 4/4 mapped | 2 not covered |
| sp/grievance-status | Value mapping | 5/5 mapped | 4 not covered |
Properties
| Vocabulary | System name | Coverage | Gaps |
|---|---|---|---|
| administrative_level | LocationType | 4/4 mapped | 1 not covered |
Documented gaps
PublicSchema items that openIMIS does not model, with the documented reason.
| PublicSchema item | Reason |
|---|---|
| benefit-frequency | OpenIMIS does not define a payment frequency vocabulary. Payment cycle cadence is configured per product as numeric date fields (start/end dates and recurring periods), not as a categorical enumeration. |
| benefit-modality | OpenIMIS does not have an explicit benefit modality vocabulary. The social protection module handles cash transfers; in-kind or voucher modalities are not represented as a categorical field. |
| conditionality-type | OpenIMIS does not model conditionality as a categorical attribute on benefit plans. Conditions are managed outside the core schema. |
| eligibility-status | OpenIMIS does not have a dedicated eligibility determination status vocabulary. Eligibility logic is embedded in benefit plan rules and BeneficiaryStatus; there is no separate EligibilityDecision record with its own status field. |
| hazard-type | OpenIMIS does not model hazard or shock events. The system has no shock-registry or emergency-trigger module. |
| marital-status | OpenIMIS does not include a marital status vocabulary in the extracted modules. The insuree model does not have a marital status field in the social protection or insuree modules covered here. |
| referral-status | OpenIMIS does not have a referral module or referral status vocabulary in the extracted codebase. The grievance module handles complaints, not inter-program referrals. |
| targeting-approach | OpenIMIS does not expose a targeting approach vocabulary. The benefit plan configuration does not categorise the method used to identify beneficiaries as a controlled value set. |
| event-severity | v2 event-severity classifies hazard/disaster impact (OASIS CAP v1.2). OpenIMIS's closest scale is grievance TicketPriority (Critical/High/Normal/Low) on the grievance_social_protection module, which measures grievance urgency, not disaster impact. The domains differ, so no semantic mapping is offered. If OpenIMIS deployments record hazard events, they would need a separate severity field aligned with CAP. |
| event-certainty | OpenIMIS does not model event certainty. This vocabulary is used for shock or hazard events, which are outside the scope of the openIMIS modules. |
Help improve this page
Highlight any text on this page to leave an annotation. Join our review group to get started.
If you have a GitHub account, click the feedback icon next to any section heading to report a specific issue.