DET KORTA SVARET
En integrationsdiskussion blir enklare när den börjar med kundens fråga, inte en lista över alla tänkbara datafält. Ska personen förstå ett villkor, följa en förnyelse eller få en samlad bild av det underlag som finns? Svaret avgör vilken information och vilka kontroller som behöver undersökas.
Forsios plattformssida beskriver strukturerad försäkringsinformation, dokumentextraktion och analys. Vilka delar som kan stödja ert användningsfall behöver gås igenom och avtalas. Den här guiden är en checklista inför den diskussionen, inte en teknisk specifikation eller ett besked om omedelbar anslutning. [1][2]
Ta med dig det här
- Börja med ändamål, mottagare och minsta nödvändiga uppgifter.
- Behåll källan, perioden och osäkerheten när uppgifter visas vidare.
- Bekräfta omfattning och testfall innan ett integrationsupplägg beslutas.
STEG FÖR STEG
Så går ni igenom underlaget
Beskriv ett avgränsat användningsfall
Skriv vilken fråga kunden ska kunna besvara och vilka uppgifter som behövs för det. Skilj den enskildas översikt från statistik för en organisation. En affärsrelation med en arbetsgivare eller medlemsorganisation ger inte automatiskt åtkomst till personens privata försäkringar.
Bestäm också vilka parter som behandlar uppgifterna och för vilka ändamål. IMY skiljer personuppgiftsansvarig från personuppgiftsbiträde utifrån vem som bestämmer ändamål och hantering. Roller, rättsligt stöd och avtal behöver bedömas för den faktiska behandlingen. En integration avgör inte de frågorna åt er.
[3][2][6]Planera kundens val och vad som händer efteråt
Forsios beskrivna plattformsflöde förutsätter kundens samtycke till den mottagare som får uppgifterna. Kontrollera vilka uppgifter, ändamål och mottagare valet omfattar. Ett konto eller en teknisk inloggning ersätter inte det delningsvalet. Känsliga uppgifter har särskilda förutsättningar.
Detta ersätter inte er bedömning av rättslig grund. När behandlingen bygger på samtycke ska ett återkallande vara lika lätt som att samtycka, enligt IMY. Beskriv hur stoppad delning, rättelse och radering ska hanteras, även för mottagna kopior. Eventuellt fortsatt lagrande behöver ett eget stöd.
[1][6][4]Kom överens om vad varje uppgift betyder
För varje relevant uppgift: notera källdokument, version, försäkringsperiod och när underlaget hämtades eller kontrollerades. Bestäm hur ett förnyelsebrev skiljs från föregående period och hur samma dokument eller avtal identifieras vid en ny inläsning. Två dokument behöver inte vara två samtidiga försäkringar.
Skilj belopp som faktiskt är noll från uppgift som saknas, dold uppgift och tekniskt fel. Om JSON används är null och en utelämnad egenskap olika saker, vilket JSON Schemas dokumentation förklarar. Visningen behöver dessutom bevara betydelsen: Ej verifierat får inte bli ett säkert nej.
[2][5][1]Testa gränsfallen och fördela ansvaret
Gå igenom ett litet påhittat testunderlag innan riktiga personuppgifter används i ett prov. Ta med förnyelse, dubbla dokument, saknat belopp, ofullständig hämtning, motstridiga uppgifter och återkallad delning. Kontrollera att en tom lista inte visas som ett besked om att allt skydd saknas eller är fullständigt.
Utse ansvarig för källuppdateringar, rättelser, användarfrågor och incidenter. Beskriv vad som visas vid ett fel och hur ärendet tas vidare. Be också om en genomgång av de datakällor, format och leveranssätt som kan stödjas enligt det upplägg ni diskuterar.
[2][1]
Låt förklaringen följa med resultatet
En iakttagelse kan vila på en villkorspunkt, personens egna uppgifter eller tydligt angiven information som saknas. Behåll den skillnaden när resultatet visas i en annan produkt. Ett produktnamn bekräftar inte omfattning, och en ofullständig insamling visar inte hela försäkringsinnehavet.
Bestäm hur kunden ser källan och vad som behöver kontrolleras. En möjlig lucka är inte ett skadebeslut. Analysen ersätter inte försäkringsgivarens prövning eller en separat professionell bedömning.
[1][6]Gör nästa steg konkret
Ta med en kort skiss över kundflödet, en lista över nödvändiga uppgifter och era viktigaste testfall till en genomgång med Forsio. Be om bekräftelse på vad som kan visas i en demonstration, vad ett prov kräver och vad som behöver avtalas för ert fall.
Bestäm vilka uppgifter som får lagras, hur länge och vilka som får se dem. Använd inte hela original eller privata uppgifter i loggar bara för att de kan vara användbara senare. Det avgränsade upplägget behöver prövas mot både verksamhetens behov och dataskyddskraven.
[1][2]Påhittat exempel
Nytt brev. Inte automatiskt en ny försäkring.
En plattform skissar på hur ett förnyat hemförsäkringsunderlag ska visas. Exemplet är inget leveransformat.
- Period
- Förnyelsebrev och tidigare period
- Årspremie
- 3 060 kr i det nya brevet
- Försäkringsbelopp
- Ej verifierat
Det saknade försäkringsbeloppet är inte noll. Förnyelsebrevet behöver kopplas till rätt avtal och period innan dokumenten räknas eller jämförs.
Vanliga frågor
Hur börjar en integrationsdiskussion med Forsio?
Boka en genomgång med ert användningsfall, önskade uppgifter och testfall. Tillgängligt stöd, omfattning och tekniskt upplägg bekräftas för den diskussionen; guiden utlovar ingen färdig självbetjäningsanslutning. [1]
FÖR ORGANISATIONER
Diskutera ert integrationsbehov.
Ta med användningsfall och testfrågor. Vi går igenom relevant underlag och vad ett avgränsat upplägg kan kräva.
Källor och underlag
Källor kontrollerade
Guiden förklarar generella principer. Kontrollera aktuella avtal, roller och behörigheter för er organisation.
- Forsio: plattformar och diskussion om integration
- IMY: ändamål, uppgiftsminimering, riktighet och skydd
- IMY: personuppgiftsansvariga och personuppgiftsbiträden
- IMY: samtycke och återkallande
- JSON Schema: null är inte samma sak som en saknad egenskap
- Min Forsio: integritetspolicy och delning av personuppgifter