Som aktør med et kundeforhold til en avdød
ønsker jeg tilgang til skifteattest-API'et i Altinn dødsbo
slik at jeg kan forberede henvendelser fra arving og utføre handlinger knyttet til skifte uten at annen skifteattest er nødvendig.
Krav/akseptansekriterier
Gitt at en skifteattest er mottatt i Digitalt dødsbo.
Når
en arving ønsker å dele denne informasjonen med en aktør
så skal
Digitalt dødsbo tilgjengeliggjør digital representasjon av skifteattesten fra aktører som har kundeforhold med den døde
og
varsel sendes aktøren om at skifteattest er klar for å hentes via skifteattest API'et (ev. annen mekaniske som avtales med den enkelte aktør)
og
arvinger skal ha tilgang til logg i DD vedrørende hvilke aktører som har laste ned skifteattest.
Utfyllende tekst
Er dette riktig for forsikring?: Det er aktører som inngår i MVP OG som har sendt opplysninger om avdøde til DD som skal få tilgang til skifteattest API'et.
Utfyllende informasjon
Funksjonelt
Status (ok, under avklaring, n/a):
Avklaringsområder:
[ ] Ønsker aktøren i MVP'en å tilpasse sine forretningsprosesser slik at de kan motta elektronisk representasjon av skifteattesten?
[x] Er dette i/utenfor MVP scope? (tb) hypotesen er at det kan tas med
[x] Hvilken informasjon skal sendes aktørene? (tb) den digitale representasjonen av skifteattesten ihht Tingrettens beskrivelse.
[x] Er det kun aktører som er innlemmet i Digitalt dødsbo OG som har sendt inn formue/gjeldssituasjon til avdøde, som skal kunne motta skiftefullmakt fra Digitalt dødsbo? (Aktøren viser ved dette at avdøde hadde et kundeforhold).(tb) Ja
GUI
Status: (ok, under avklaring, n/a):
Avklaringsområder:
Dokumentasjon:
Teknisk
Status(ok, under avklaring, n/a):
Avklaringsområder:
[ ] Hvilket utviklingsmønster
[ ] Hvilken informasjon skal brukes pr. aktør?
Dokumentasjon:
Ønsker aktører en hendelsesbasert trigger om at skifteattest er utstedt? I dag er det slik at arvingene leverer skifteattesten. Er det ønskelig med en tilsvarende løsning i Digitalt dødsbo?
Antagelse:
Aktør har etablert mottak av dig repr av skifteattest i sine systemer via API. Når kriterier er oppfylt for tilgjengeliggjøring av elektronisk skifteattest, så tilgjengeliggjør DD dette for aktøren.
Juridisk
Status(ok, under avklaring, n/a):
Avklaringsområder:
Dokumentasjon:
Lukkes. Som diskutert tidligere er tilgang til skifteattest-api-et uavhengig av forhold til avdøde og reguleres bare gjennom maskinporten-scopes - bruken av api-et og dataene reguleres av avtaleverk.
Brukerhistorie
Som aktør med et kundeforhold til en avdød ønsker jeg tilgang til skifteattest-API'et i Altinn dødsbo slik at jeg kan forberede henvendelser fra arving og utføre handlinger knyttet til skifte uten at annen skifteattest er nødvendig.
Krav/akseptansekriterier Gitt at en skifteattest er mottatt i Digitalt dødsbo. Når en arving ønsker å dele denne informasjonen med en aktør så skal Digitalt dødsbo tilgjengeliggjør digital representasjon av skifteattesten fra aktører som har kundeforhold med den døde og varsel sendes aktøren om at skifteattest er klar for å hentes via skifteattest API'et (ev. annen mekaniske som avtales med den enkelte aktør) og arvinger skal ha tilgang til logg i DD vedrørende hvilke aktører som har laste ned skifteattest.
Utfyllende tekst Er dette riktig for forsikring?: Det er aktører som inngår i MVP OG som har sendt opplysninger om avdøde til DD som skal få tilgang til skifteattest API'et.
Utfyllende informasjon
Funksjonelt Status (ok, under avklaring, n/a): Avklaringsområder:
GUI Status: (ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Teknisk Status(ok, under avklaring, n/a): Avklaringsområder:
Dokumentasjon: Ønsker aktører en hendelsesbasert trigger om at skifteattest er utstedt? I dag er det slik at arvingene leverer skifteattesten. Er det ønskelig med en tilsvarende løsning i Digitalt dødsbo?
Antagelse: Aktør har etablert mottak av dig repr av skifteattest i sine systemer via API. Når kriterier er oppfylt for tilgjengeliggjøring av elektronisk skifteattest, så tilgjengeliggjør DD dette for aktøren.
Juridisk Status(ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Prioriteringskriterier produktkø
Funksjonell viktighet (må, bør, vent): Teknisk modenhet (høy, medium, lav): Samarbeidspartnere tilgjengelig (klar, under avklaring, nei, na):
Estimat
Test (sprint)
Funksjonelt Akseptert (j/n): Avvik:
System Akseptert (j/n): Avvik:
Integrasjon Akseptert (j/n): Avvik:
Brukerhistorie
Som ... ønsker jeg å .... slik at ...
Akseptansekriterier
Gitt at.. Når ... så skal ... og...
Kvalitetskrav/akseptansekriterier
Gitt at.. Når ... så skal ... og...
Utfyllende tekst
..
Utfyllende informasjon
Funksjonelt Status (ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon
GUI Status: (ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Teknisk Status(ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Juridisk Status(ok, under avklaring, n/a): Avklaringsområder: Dokumentasjon:
Test (sprint) Akseptansetest bh (ok ev avvik): Systemtest (ok ev avik?): Integrasjonstest (ok ev avvik):
Estimat
Grov, ved innleggelse i produktkø, dv ( 60-31, 30-11,10-3, >3): Estimat (sprint til akseptansetest): dv
Prioriteringskriterier produktkø
Funksjonell viktighet (må, bør, vent): Teknisk modenhet (høy, medium, lav): Samarbeidspartnere tilgjengelig (klar, under avklaring, nei, na):
Test (sprint)
Funksjonelt Akseptert (j/n): Avvik:
System Akseptert (j/n): Avvik:
Integrasjon Akseptert (j/n): Avvik: