Family Relations in Persontjenesten

This page provides an overview of how family relationships are represented and accessed within the Person API.

The familyRelation information part details a person's current and historical family relationships.

Structure and Data Points

The familyRelation information part is provided as a list of items, each representing a specific family relationship with associated metadata. Unlike some other information parts that have only a single valid item, familyRelation can have multiple relationships valid concurrently. This means a person can have several active family roles (e.g., being a child to two parents and a parent to multiple children).

Each entry in the familyRelation list typically includes the following data points:

  • relatedPerson: The Norwegian identification number (NIN) of the related person.
  • relatedPersonWithoutIdentifier: This field is used when the identifier for the related person is not available. Referred to as RelatertBiperson in Norwegian documentation, it provides identifying information about the related person when a Norwegian identification number is missing. This identifying information can include the person's name (given, middle, and family name), birth date, citizenship, and gender.
    • It is important to note that none of these identifying information fields are obligatory.
    • Even if a person later receives a Norwegian identification number, the system does not guarantee that the biperson entry will be replaced with a full relatedPerson entry containing the NIN.
    • It is possible that a person later gets a Norwegian identification number, but the system does not guarantee that management tasks will be performed to replace biperson entries with their corresponding folkeregisterperson entries in the Register.
  • relatedPersonsRole: Describes the role of the relatedPerson relative to the primary person (e.g., "Child", "SpouseOrPartner", "Father", "Mother"). This corresponds to Freg: RelatertPersonsRolle.
  • myRoleForRelatedPerson: Describes the primary person's role relative to the relatedPerson (e.g., "Father", "Child"). This corresponds to Freg: MinRolleForPerson.

The legal values for both relatedPersonsRole and myRoleForRelatedPerson are defined by the Familierelasjonstype code list. These types of family relationships are:

  • Mother: Used for a biological mother or adoptive mother. A child can have up to two family relationships where the relatedPersonsRole is mor.

  • Father: Used for a biological father or adoptive father. A child can have up to two family relationships where the relatedPersonsRole is far.

  • CoMother: Used based on a population register decision. A child can only have one person defined as medmor.

  • Child: Used for a child or adopted child. The relationship is independent of whether parents have parental responsibility for the child.

  • Sibling: This is a new field showing the relationship between siblings (both full and half). It was not included in the Register during migration from DSF. The system does not currently differentiate between full and half-siblings, or if they share the same mother or father; this can be inferred by looking at the siblings' parents.

  • SpouseOrPartner: Relationship to a registered person in the Population Register who is the spouse or partner to the relationship owner.

  • StillbornChild: Relationship to a registered person in the Population Register who is a stillborn child to the relationship owner.

  • Metadata: Each entry also includes standard metadata fields, indicating its validity and origin:

    • registeredAt: Registration timestamp in FREG.
    • isValid: A boolean indicating whether this specific relationship is currently valid and in use.
    • source: The information source (e.g., "Synutopia", "KILDE_DSF").
    • reason: The reason for registration.
    • validFrom: Timestamp when the information became valid.
    • validTo: Expiration timestamp for historical information.

Events for Family Relations

When data in the FamilyRelation information element changes, the Person API emits a ChangeInFamilyRelation event. This allows consumers to keep their local copies of data up to date.

JSON Example

Below is an example of the familyRelation structure within a Person API response, demonstrating how multiple valid relationships can be present. Note the presence of relatedPersonWithoutIdentifier as null in these examples, indicating the related person has a NIN:

Json example 
"familyRelation": [
{
    "relatedPerson": "26879497719",
    "relatedPersonWithoutIdentifier": null,
    "relatedPersonsRole": "Child",
    "myRoleForRelatedPerson": "Father",
    "registeredAt": "2022-02-18T13:35:06.690672Z",
    "isValid": true,
    "source": "Synutopia",
    "reason": "Patch",
    "validFrom": "1994-07-25T23:00:00Z"
},
{
    "relatedPerson": "13926298253",
    "relatedPersonWithoutIdentifier": null,
    "relatedPersonsRole": "SpouseOrPartner",
    "myRoleForRelatedPerson": "SpouseOrPartner",
    "registeredAt": "2022-03-11T15:35:30.391334Z",
    "isValid": true,
    "source": "Synutopia",
    "reason": "Patch",
    "validFrom": "1991-02-09T15:35:30.143021Z"
},
{
    "relatedPerson": "22848797212",
    "relatedPersonWithoutIdentifier": null,
    "relatedPersonsRole": "Child",
    "myRoleForRelatedPerson": "Father",
    "registeredAt": "2022-02-23T14:55:25.645122Z",
    "isValid": true,
    "source": "Synutopia",
    "reason": "Patch",
    "validFrom": "1987-04-21T23:00:00Z"
},
{
    "relatedPerson": "07893049740",
    "relatedPersonWithoutIdentifier": null,
    "relatedPersonsRole": "Father",
    "myRoleForRelatedPerson": "Child",
    "registeredAt": "2022-03-11T15:35:31.290816Z",
    "isValid": true,
    "source": "Synutopia",
    "reason": "Patch",
    "validFrom": "1964-09-05T23:00:00Z"
},
{
    "relatedPerson": "04922649486",
    "relatedPersonWithoutIdentifier": null,
    "relatedPersonsRole": "Mother",
    "myRoleForRelatedPerson": "Child",
    "registeredAt": "2022-03-11T15:35:31.062102Z",
    "isValid": true,
    "source": "Synutopia",
    "reason": "Patch",
    "validFrom": "1964-09-05T23:00:00Z"
}
]

An example of when relatedPersonWithoutIdentifier might be populated, rather than null, is shown as:

Json example 
{
  "RelatedPerson": null,
  "RelatedPersonWithoutIdentifier": {
    "Name": {
      "GivenName": "ustabil",
      "MiddleName": "bra",
      "FamilyName": "kommode"
    },
    "BirthDate": "1973-06-21T00:00:00Z",
    "Citizenship": "AUS",
    "Gender": "Female"
  },
  "RelatedPersonsRole": "SpouseOrPartner",
  "MyRoleForRelatedPerson": "SpouseOrPartner",
  "RegisteredAt": "2024-04-13T11:26:53.9153644Z",
  "IsValid": true,
  "Source": "Synutopia",
  "Reason": "Innflytting",
  "ValidFrom": "2024-04-12T22:00:00Z",
  "ValidTo": null
}

While familyRelation covers direct familial ties, other related information types are available:

  • Parental Responsibility (parentalResponsibility): This is a separate information part that indicates current and historical parental responsibilities. Multiple records can be valid concurrently. The Person API does provide access to this information for health enterprises with the necessary legal basis. A ChangeInParentalResponsibility event exists for updates. The parentalResponsibility information contains who has parental authority for a minor person. The responsibility is shown as a two-way relationship using identifiers or identifying information.
  • Daily Care for Children: It's important to note that information regarding who has daily care for children is not an information element in the National Population Register (FREG) and therefore is not available through Persontjenesten.

Frequently Asked Questions (FAQ)

Q: What happens to a person's family relations in the National Population Register (FREG) when they receive a new Norwegian Identification Number (NIN), such as upgrading from a d-number to a fødselsnummer?

A: According to the National Population Register (FREG), when a person who previously had a d-number (and, for example, a family relation to a child) is issued a new, valid Norwegian Identification Number (fødselsnummer), the existing family relations involving that person should be updated to point to their new, current fødselsnummer. The general principle is that for current family relations, the link must always point to the most up-to-date, valid identifier. However, it is known that there are existing instances, particularly within historical family relations, where this update has not occurred; for example, a family relation might still reference an older d-number even after the individual has received a current fødselsnummer. This situation is acknowledged as an internal cleanup issue, especially for historical relationships. One of the sources further clarifies that even if a person later receives a Norwegian identification number, the system does not guarantee that an entry initially using relatedPersonWithoutIdentifier (or biperson in Norwegian documentation) will be replaced with a relatedPerson entry containing the new NIN. This principle of updating to the new, current identifier is intended to apply to all types of relations, though exceptions and errors in the actual data do exist.

Further Documentation

For a comprehensive understanding of the Person API's information model, including familyRelation and other fields, you can refer to the official FREG Information Model Documentation. You can also find a list of translations from Norwegian terms used in the National Population Register to English terms used in the Person API here: Translations.