Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Introduksjon

Denne siden gir noen generelle anbefalinger om hvordan du som leverandør av medlemssystem bør håndtere medlemsdata, og hvordan du bør bygge en robust integrasjon.

Medlemsinformasjon

Profilhåndtering

Dersom leverandørene ønsker det, kan de selv berike medlemsdata fra NIF med kontakt- og adresseopplysninger som lagres lokalt i egen database. NIF besitter og utleverer primært opplysninger som er vasket mot Folkeregisteret. Dette innebærer at medlemmer kan ha en annen bostedsadresse hos NIF enn der de faktisk oppholder seg. Feks. studenter. NIF krever at selve personobjektet og dets medlemsskap er synkronisert.

Adressesperre i Folkeregisteret

Generelt om adressesperre

Adressesperre i Folkeregisteret er et tiltak for å beskytte trusselutsatte personer, dvs. personer som står i fare for å bli utsatt for alvorlig kriminalitet rettet mot liv, helse eller frihet. Typiske eksempler er vitner, informanter og personer som har blitt eller er utsatt for vold og trusler. Mer enn 450 personer i Norge lever til enhver tid med beskyttelsestiltaket adressesperre. Adressesperre er et tidsbegrenset beskyttelsestiltak som er gjenstand for en løpende vurdering og gjelder så lenge det er behov for det. 

Adressesperre innebærer at det er begrenset tilgang til opplysninger om personers adresse og annen geolokaliserende informasjon. Det at en person er trusselutsatt og har sperret adresse, er ikke konfidensielt. 

To offentlige etater kan beslutte å gi personer adressesperre og legge det inn i Folkeregisteret: 

  • Politiet kan, i samråd med den trusselutsatte, beslutte å gi adressesperre som beskyttelsestiltak til voksne. Ved en slik beslutning sperres også adressen til eventuelle barn og resten av husstanden. 

  • Fylkesnemnda for barnevern og sosiale saker vurderer og kan beslutte adressesperre for barnet i saker om omsorgsovertakelse. I hastesaker kan også barnevernsleder i kommunen beslutte adressesperre for barnet. 

Avgjørelsen om adressesperre skal i begge tilfeller skje på grunnlag av en trusselvurdering med etterfølgende beslutning og basert på en helhetsvurdering. Adressesperringen skjer i Folkeregisteret.

Adresse sperres enten som:

FORTOLIG eller STRENGT fortrolig (hhv kode 7 og kode 6).

"FORTROLIG adresse" innebærer at adressen til den trusselutsatte ikke leveres til private, men er tilgjengelig for den delen av det offentlige som har hjemmel til opplysninger fra Folkeregisteret. 

"STRENGT fortrolig adresse" innebærer at opplysninger om adressen ikke leveres til noen.

Geolokalisere opplysninger

Geolokalisererende opplysninger er alle opplysninger som kan si noe om hvor en trusselutsatt person befinner seg eller kommer til å befinne seg i fremtiden, eller hvor h*n har oppholdt seg tidligere. Opplysninger om avtaler med offentlige eller private virksomheter må beskyttes, f.eks. timeavtaler i det offentlige, fritidsaktiviteter og andre støtte- eller brukertjenester.

Når en aktør behandler opplysninger om personer med adressesperre, er det viktig at det fremkommer tydelig at opplysningene har et særskilt beskyttelsesbehov, slik at de som behandler opplysningene vet dette.

NIF mottar ikke adresseinformasjon til personer med adressesperre, og dermed utleveres heller ikke adresseinformasjon til 3.parter. Personer som har vedtak om adressesperre, vil ha følgende merking i Idrettens Sentrale Database (ISD):

"AddressLine1":"SPERRET ADRESSE"
"PostCode":"9999",
"City":"MANGLER POSTSTED"

Personopplysninger i Idrettens Sentrale Database (ISD) vaskes mot Folkeregisteret. Det er avgjørende at alle personer som har Fødsels- eller D-nummer er validert med dette. Dette for å sikre til en hver tid oppdatert adresseinformasjon fra Folkeregisteret. NIFs anbefaling for sikker validering av personer, er at personen oppretter en bruker med Idrettens ID.

Dersom leverandører av medlemssystem har beriket personobjekter med annen adresseinformasjon i sine løsninger, er det leverandøren selv som har ansvar for at geolokaliserende opplysninger om personer med adressesperre ikke eksponeres.

Kilder:
https://www.ehelse.no/normen/normen-dokumenter/sperret-adresse-i-folkeregisteret-faktaark-55
https://www.politiet.no/globalassets/rad-og-veiledning/vold-i-nare-relasjoner/veiledning-behandling-av-opplysninger-om-personer-med-adressesperre.pdf

Betalingsinformasjon

Innrapportering av betalingsobjekter

NIF anbefaler at leverandørene innrapporterer betalingsobjekter APIet umiddelbart etter at transaksjonen har gått igjennom i leverandørens systemer. På denne måten er informasjonen anvendbar i andre systemer i idrettens økosystem. Les mer om innrapportering av betalingsobjekter her.

Implementasjon - Generelle tips

Håndtering av meldinger og oppdateringer i sekvens

Prosessering av informasjon sendt via API’et kan enkelte ganger ta noe tid. Dette skyldes at det er flere operasjoner som skal foregå i sekvens, både ved innmelding og utmelding av medlemmer. For å ikke skape utfordringer for medlemmet kan det være hensiktsmessig å legge en sperre for ytterligere oppdateringer på personen til leverandøren har fått bekreftelse på meldingskøen på at behandlingen har blitt behandlet riktig av NIF.

Eksempel på en typisk feilsituasjon:

Eksternt medlemssystem melder Mikro Midas inn i et idrettslag med membership (add). Mikro Midas finnes fra før i Idrettens Sentrale Database, men han ligger registrert med feil organisasjonstilknytning og medlemskapet kunne ikke opprettes maskinelt. Medlemskapet til Mikro Midas i dette idrettslaget er ikke å anse som opprettet før leverandøren har fått en “ActiveMembershipId” i retur på Subscription Queue.

Eksternt medlemssystem melder Mikro Midas ut av et idrettslag med membership (cancel). Medlemssystemet forsøker å melde Mikro Midas inn i samme idrettslag igjen. Dersom prosesseringen av den første utmeldingen ikke er klar, vil innmelding feile. Utmelding er ikke fullstendig før leverandøren har fått den aktuelle MembershipId med verdien “IsPassive=1” i retur på Subscription Queue.

  • No labels