OpenCRVS unreviewed

https://opencrvs.org

Open-source civil registration and vital statistics platform.

This page shows how OpenCRVS vocabulary codes map to PublicSchema canonical values. If you work with OpenCRVS and spot an error, please report it.

5 vocabularies covered: 5 value mapping.

Vocabularies

Vocabulary System name Relationship Coverage Gaps
crvs/civil-status-record-type EventDocument.type (country-configured string) Value mapping 3/3 mapped 3 not covered
crvs/registration-status EventStatus Value mapping 5/5 mapped 4 not covered
gender-type Gender Value mapping 4/4 mapped
payment-status PaymentOutcomeType Value mapping 3/3 mapped 5 not covered
sex Gender Value mapping 3/4 mapped

Concept matches

Entities in OpenCRVS that align with PublicSchema concepts.

PublicSchema concept System entity Match Notes
VitalEvent EventDocument Close EventDocument is the generic event envelope in v2: id, type (a free string such as "BIRTH" or "DEATH"), createdAt, updatedAt, actions, and trackingId. Our VitalEvent is the abstract supertype for civil registration events. The correspondence is close: both represent the occurrence entity, but EventDocument carries no domain fields; all content lives in the EventConfig.declaration fields of individual actions.
Birth EventDocument (type='BIRTH', country-configured) Broad In v2 core there is no BirthRegistration type. A birth event is an EventDocument whose type string is set to the country's birth event id (e.g. the Farajaland constant Event.Birth). All birth-specific fields (child name, birthDate, parentage, birthType, attendant, weight) live in the EventConfig.declaration form defined by the country config. Match is broad because the EventDocument envelope is genuinely wider than our Birth concept.
Death EventDocument (type='DEATH', country-configured) Broad Same pattern as Birth. A death event is an EventDocument whose type string is set to the country's death event id. Death-specific fields (deceased name, cause of death, manner of death, medical certifier) are country-configured EventConfig.declaration fields; none are typed at the v2 core level.
Marriage EventDocument (type='marriage', country-configured) Broad The Farajaland Event enum defines Event.Marriage = 'marriage', confirming the convention. A full EventConfig for marriage is not present in the Farajaland reference clone; the same EventDocument + country EventConfig pattern applies. Marriage-specific fields (bride/groom or party_1/party_2, witnesses, typeOfMarriage) would be country-configured EventConfig.declaration fields. Match is broad and confidence is null pending a concrete EventConfig example.
CivilStatusRecord RegisterAction Related RegisterAction is an ActionDocument variant (type=REGISTER) that carries a registrationNumber field. This is the closest v2 core equivalent to our CivilStatusRecord: the act of registration produces a registration number, which is the legal acte identifier. However, RegisterAction is an action within an EventDocument, not a standalone record; the structural roles differ. The registrationNumber field is optional (nullable) and is always present on accepted registrations.
Certificate PrintCertificateAction Related PrintCertificateAction is an ActionDocument variant (type=PRINT_CERTIFICATE). It carries an optional templateId content field. This is structurally narrower than our Certificate concept, which models the issued document with issuance metadata (issue date, issuing office, format, certificate number). PrintCertificateAction records the act of printing; it does not fully represent the certificate as a legal document object. Match is related rather than close because the scope has narrowed from v1's Certificate type.
PaternityRecognition RequestedCorrectionAction / ApprovedCorrectionAction Related PaternityRecognition remains without a first-class event type in v2. The correction workflow (ActionType.REQUEST_CORRECTION followed by ActionType.APPROVE_CORRECTION) is the operational mechanism for amending a birth record to add or change parentage information. The match is related for the same reason as v1: the target is a workflow action pair, not an event type. A country config could define a dedicated "paternity recognition" event type using a separate EventConfig.

Documented gaps

PublicSchema items that OpenCRVS does not model, with the documented reason.

PublicSchema item Reason
FetalDeath Not modelled as a distinct event type in v2 core. A country config could define a fetal death event; the Farajaland reference config does not. No fixed v2 core equivalent.
MarriageTermination Not modelled in v2 core or the Farajaland reference config. Neither divorce nor annulment registration exists as a first-class event type.
Adoption Not modelled in v2 core or the Farajaland reference config. Adoption scenarios would require a country-specific EventConfig.
Legitimation Not modelled in v2 core. Same pattern as PaternityRecognition: operationally a correction action on an existing birth record.
CivilStatusAnnotation No reified marginal-annotation type in v2. ActionBase carries an annotation field (an untyped key-value record) for action-specific metadata, but this is not an annotation in the legal CRVS sense (a signed marginal note on a register entry).
FamilyRegister V2 is event-record centric. There is no concept of a family register (livret de famille, koseki, hukou); families are not modelled as a tracked unit in v2 core or the Farajaland reference config.
Person V2 core has no Person type. All person data (name, date of birth, demographic attributes) lives in country-configured declaration fields inside EventDocument.actions[].declaration, a Record<string, FieldValue> keyed by country-specific strings. There is no reified temporal-snapshot Person entity in the event service.
Parent Our Parent is a reified link entity (Person + parental_role). V2 core has no such type. In Farajaland, parent data appears as declaration field groups with keys like mother.firstname, father.surname; the role is encoded in the field-key prefix, not a typed enum.
enrollment-status OpenCRVS has no concept of program enrollment. Civil registration records vital events; it does not track program participation.
eligibility-status No eligibility assessment in OpenCRVS. Eligibility determination is a social protection function with no CRVS equivalent.
benefit-frequency No benefit disbursement cycle in OpenCRVS. Payments in OpenCRVS are one-time service fees, not recurring benefit transfers.
benefit-modality No benefit type or modality concept in OpenCRVS. Cash, in-kind, and voucher transfers are social protection constructs absent from CRVS.
event-certainty No probability or certainty scoring in OpenCRVS. Used in v2 for targeting and assessment confidence levels with no CRVS analog.
conditionality-type Conditionalities (co-responsibilities attached to benefits) are a social protection concept with no equivalent in civil registration.
delivery-channel Delivery channel (how benefits reach beneficiaries) is a disbursement concept absent from OpenCRVS.
grievance-status OpenCRVS has no formal grievance management module. Complaints and appeals are social protection constructs.
grievance-type Same as grievance-status: no grievance classification in OpenCRVS.
group-role V2 group-role covers household membership roles in a social protection context. OpenCRVS captures family relationships as field-key prefixes in declaration data, not a shared enumeration.
group-type V2 group-type distinguishes household, family, farm, and other group structures used in social protection targeting. OpenCRVS has no equivalent grouping concept.
hazard-type Hazard classification is used in social protection for shock-responsive programming. No analog in civil registration.
referral-status Referral tracking between programs is a social protection construct with no civil registration equivalent.
event-severity Severity scoring (for shocks, grievances, or needs) is a social protection assessment concept absent from OpenCRVS.
targeting-approach Program targeting methodology is a social protection planning concept with no civil registration equivalent.
literacy OpenCRVS v2 (and the Farajaland reference config) does not include a literacy field. The UNSD binary literacy classification has no counterpart in v2 core or country configuration patterns.
employment-status OpenCRVS v2 does not include an employment status field. The ILO tripartite classification has no counterpart in v2 core.
status-in-employment OpenCRVS v2 does not include a status-in-employment field. The ILO ICSE-18 categories have no counterpart in v2 core.
crvs/registration-type Semantic mismatch. Our registration-type describes the timing and procedural route of registration (current, late, court_ordered, reconstruction). V2 EventDocument.type describes which event category is being registered (birth, death, marriage); that dimension maps to our civil-status-record-type vocabulary, not registration-type.
Report an issue with these mappings