Familierelasjon i Person‑API

Denne siden gir en oversikt over hvordan familierelasjoner representeres og hentes i Person‑API.

Informasjonsdelen familyRelation beskriver en persons nåværende og historiske familierelasjoner.

Struktur og datapunkter

Informasjonsdelen familyRelation leveres som en liste med elementer, hvor hvert element representerer en spesifikk familierelasjon med tilhørende metadata. I motsetning til andre informasjonsdeler som kun kan ha ett gyldig element, kan familyRelation ha flere relasjoner som er gyldige samtidig. En person kan dermed ha flere aktive familieroller (f.eks. være barn av to foreldre og forelder til flere barn).

Hvert element i familyRelation‑listen inneholder vanligvis følgende datapunkter:

• relatedPerson: Det norske identifikasjonsnummeret (NIN) til den relaterte personen.
• relatedPersonWithoutIdentifier: Dette feltet brukes når identifikatoren til den relaterte personen ikke er tilgjengelig. I norsk dokumentasjon kalles det RelatertBiperson, og det gir identifiserende opplysninger om den relaterte personen når et NIN mangler. Opplysningene kan omfatte personens navn (for‑, mellom‑ og etternavn), fødselsdato, statsborgerskap og kjønn.
  • Det er viktig å merke seg at ingen av disse identifiserende feltene er påkrevd.
  • Selv om en person senere får et NIN, garanterer systemet ikke at biperson‑oppføringen erstattes med en fullstendig relatedPerson‑oppføring som inneholder NIN.
  • Det kan også hende at en person senere får et NIN, men systemet ikke nødvendigvis utfører oppgaver for å erstatte biperson‑oppføringer med tilsvarende folkeregisterperson‑oppføringer i registeret.
• relatedPersonsRole: Beskriver rollen til relatedPerson i forhold til hovedpersonen (f.eks. Child, SpouseOrPartner, Father, Mother). Dette tilsvarer Freg: RelatertPersonsRolle.
• myRoleForRelatedPerson: Beskriver hovedpersonens rolle i forhold til relatedPerson (f.eks. Father, Child). Dette tilsvarer Freg: MinRolleForPerson.

De lovlige verdiene for både relatedPersonsRole og myRoleForRelatedPerson er definert i kodelisten Familierelasjonstype. De tilgjengelige familierelasjonstypene er:

• Mother – Brukes for biologisk eller adoptivmor. Et barn kan ha opptil to relasjoner hvor relatedPersonsRole er mor.
• Father – Brukes for biologisk eller adoptivfar. Et barn kan ha opptil to relasjoner hvor relatedPersonsRole er far.
• CoMother – Brukes etter en beslutning i folkeregisteret. Et barn kan kun ha én person definert som medmor.
• Child – Brukes for et barn eller adoptert barn. Relasjonen er uavhengig av om foreldre har foreldreansvar for barnet.
• Sibling – Viser slektsforhold mellom søsken (både helt og halv). Feltet ble introdusert etter migrering fra DSF; systemet skiller foreløpig ikke mellom hel- og halv‑søsken, eller om de deler samme mor eller far – dette kan avledes ved å se på foreldrene til søsknene.
• SpouseOrPartner – Relasjon til en registrert person i folkeregisteret som er ektefelle eller partner til eieren av relasjonen.
• StillbornChild – Relasjon til en registrert person i folkeregisteret som er et dødfødt barn til eieren av relasjonen.

Metadata – Hvert element inneholder også standard metadata‑felter som angir gyldighet og kilde:

• registeredAt: Registreringstidspunkt i FREG.
• isValid: Boolsk verdi som indikerer om denne spesifikke relasjonen er aktuell og i bruk.
• source: Informasjonskilden (f.eks. Synutopia, KILDE_DSF).
• reason: Årsak til registreringen.
• validFrom: Tidspunkt da informasjonen ble gyldig.
• validTo: Utløpstidspunkt for historisk informasjon.

Hendelser for familierelasjoner

Når data i informasjons•elementet FamilyRelation endres, sender Person‑API en ChangeInFamilyRelation‑hendelse. Dette gjør det mulig for konsumenter å holde sine lokale kopier av data oppdatert.

JSON‑eksempel

Nedenfor er et eksempel på strukturen familyRelation i et svar fra Person‑API, som viser hvordan flere gyldige relasjoner kan forekomme. Merk at relatedPersonWithoutIdentifier er null i disse eksemplene, noe som indikerer at den relaterte personen har et NIN:

"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"
}
]

Et eksempel på når relatedPersonWithoutIdentifier kan være utfylt i stedet for null, vises som:

{
  "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
}

Relatert informasjon

Mens familyRelation dekker direkte familierelasjoner, finnes det andre relasjonstyper som er tilgjengelige:

• Foreldreansvar (parentalResponsibility)
  Dette er en egen informasjonsdel som viser både nåværende og historisk foreldreansvar. Flere poster kan være gyldige samtidig. Person‑API gir tilgang til denne informasjonen for helse‑virksomheter som har nødvendig juridisk grunnlag. Det finnes en ChangeInParentalResponsibility‑hendelse for oppdateringer. parentalResponsibility‑informasjonen inneholder hvem som har foreldre‑myndighet over en mindreårig person, og ansvaret vises som en to‑veis relasjon ved hjelp av identifikatorer eller identifiserende opplysninger.

• Daglig omsorg for barn
  Merk at informasjon om hvem som har daglig omsorg for barn ikke er et informasjonselement i Folkeregisteret (FREG), og er derfor ikke tilgjengelig via Persontjenesten.

Ofte stilte spørsmål (FAQ)

Q: Hva skjer med en persons familierelasjoner i Folkeregisteret (FREG) når vedkommende får et nytt norsk identifikasjonsnummer (NIN), for eksempel ved oppgradering fra D‑nummer til fødselsnummer?

A: Ifølge Folkeregisteret skal en persons eksisterende familierelasjoner oppdateres slik at de peker på det nye, gyldige fødselsnummeret når personen får tildelt et slikt. Prinsippet er at gjeldende familierelasjoner alltid må referere til den nyeste, gyldige identifikatoren. I praksis finnes det imidlertid enkelte historiske relasjoner hvor oppdateringen ikke er utført – et eksempel kan være en familierelasjon som fortsatt viser et gammelt D‑nummer etter at personen har fått et fødselsnummer. Dette anses som et internt oppryddingsproblem, spesielt for historiske relasjoner. En kilde presiserer videre at selv om en person senere får et norsk identifikasjonsnummer, garanterer systemet ikke at en oppføring som opprinnelig benyttet relatedPersonWithoutIdentifier (eller biperson i norsk dokumentasjon) automatisk erstattes med en relatedPerson‑oppføring som inneholder det nye NIN. Prinsippet om oppdatering til den nye identifikatoren gjelder for alle typer relasjoner, men unntak og feil i dataene forekommer.

Videre dokumentasjon

For en fullstendig forståelse av Person‑API‑ens informasjonsmodell, inkludert familyRelation og andre felter, referer du til den offisielle dokumentasjonen for FREG‑informasjonsmodellen:
FREG Information Model Documentation (PDF)

En oversikt over oversettelser fra norske termer i Folkeregisteret til engelske termer i Person‑API finnes her:
Translations