PU-relaterade sidor ligger nu istället i Ineras Confluence Personuppgiftstjänsten

Innehåll:



1.1. Inledning

Detta är svar på vanligt förekommande frågor om Personuppgiftstjänstens funktionalitet och teknik. Avsikten är inte att vara heltäckande när det gäller de regler och den informatik som finns för folkbokföringen i Sverige. Skatteverket förvaltar den källa, Navet, som Personuppgiftstjänsten grundar sig på. Svar på frågor kan finnas här https://skatteverket.se/navet, alternativt så går det bra att skicka frågor direkt till Skatteverket navet.solna@skatteverket.se 

1.2. Fråga: om jag vill veta mera om Personuppgiftstjänsten i syfta att ansluta en tjänst till den, var hittar jag information om funktionalitet och teknik?

1.3. Fråga: vilka format på personidentiteten stödjer Personuppgiftstjänsten och vad är skillnaden mellan dem?

1.4. Fråga: Skatteverket har sina benämningar och Personuppgiftstjänsten har andra, var hittar jag översättningen mellan Skatteverket och Personuppgiftstjänsten?

1.5. Fråga: hur ska befintliga nationella tjänster som inte hanterar samtliga typer av personidentifierare i dagsläget förändras?

  • Befintliga nationella tjänster som Inera förvaltar kommer att anpassas medstöd för nationellt ReservID, dvs. få stöd för de nationellt accepterade PNR (personnummer), SNR (samordningsnummer), och NRID (nationellt ReservID)

1.6. Fråga: kommer nationella e-tjänster, exempelvis NPÖ göras ett anrop per tjänstekontrakt per PNR+SNR+NRID?

1.7. Fråga: hur påverkas engagemangsindex (EI)? Kommer samtliga format stödjas och ska EI skapas även för NRID? Rensas EI med NRID när koppling har gjorts med SNR/PNR?

  • Engagemangsindex stödjer att registrera indexposter med PNR, SNR eller NRID som nyckel. Dokumentationen i tjänstedomän för EI har uppdaterats för att tydliggöra stödet för NRID.EI-poster i de aktuella tjänstedomänerna ska skapas även då NRID är huvudidentiteten.

  • För detaljer om regelverket se tjänstekontraktsbeskrivning för Engagemangsindex  http://rivta.se/domains/itintegration_engagementindex.html . 

  • Regelverk kopplat till tjänstedomänen för Engagemangsindex reglerar vad tjänstekonsumenter/producenter behöver stödja relativt NRID, samt hur hantera indexuppdateringar när individens kopplingsinformation ändras, t.ex. då det sker en lokal koppling av NRID till PNR för en individ.

1.8. Fråga: finns något tänkt kring att propagera ut förändringar på persons huvudidentitet till de olika parterna?

  • Huvudregeln är att uppgift om huvudidentitet aktualiseras genom uppslag till Personuppgiftstjänst. Uppgift om huvudidentitet ingår i den minsta valbara svarsprofilen, dvs. det går att minimera den information som behöver hämtas.  Normalt mellanlagras uppgifterna i en cache hos det system som efterfrågar dem för att minimera antalet externa anrop.
    Det här är ett område som förvaltningen av Inera Personuppgiftstjänst kommer att följa för att se om ytterligare tjänster efterfrågas, och i så fall är möjliga att realisera både juridiskt och tekniskt.

  • Via Personuppgiftstjänstens uppdateringsflöde kan alla ändringar av huvudidentitet utläsas, för de personer som finns inom befolkningsområdet (i praktiken de områden man avtalat om att få aviseringar på). I Personuppgiftstjänsten ingår även uppdateringar av ändrade personposter personer som endast har NRID som huvudidentitet, samt kontaktuppgifter.

1.9. Fråga: vad skiljer Ineras aviseringsflöde gentemot Skatteverkets?

  • Inera tillhandahåller tjänster med funktionalitet som efterliknar Skatteverkets aviseringsflöde men det är upp till kundens anslutande system att efterfråga information så beteckningen avisering är missvisande i Ineras fall. Vad man kan som anslutande part är att fråga efter uppdateringar så vi har valt att kalla flödet för uppdateringsflöde.
  • Från och med Personuppgiftstjänst 4.0 kommer Ineras uppdateringsflöde även inkludera kontaktuppgifter och personer med reservidentitet, vilket inte finns någon motsvarighet till hos Skatteverket.
  • Personuppgiftstjänstens uppdateringsflöde bygger på användning av tjänstekontrakt där verksamheten agerar tjänstekonsument. Presentationen beskriver summariskt aviseringsflödet som gäller från och med 4.0. Aviseringsflöde 4.0
  • Observera att genom att använda tjänstekontrakten för aviseringsflödet så har konsumenten full kontroll på vilken data som levereras i filen. Se https://confluence.cgiostersund.se/pages/viewpage.action?pageId=189899226 om hur tjänstekontrakten ska användas och se även http://rivta.se/domains/strategicresourcemanagement_persons_person.html för detaljer om tjänstekontrakten.
  • En detalj med Personuppgiftstjänstens aviseringsflöde från 4.0 är att hela svaret överförs i en fil, därför är antal filreferenser i svaret frånGetFilesForOrderId alltid lika med ett i detta fall.
  • Se release notes för Personuppgiftstjänsten för mera detaljer https://confluence.cgiostersund.se/display/PU/Versioner.

1.10. Fråga: Om Personuppgiftstjänsten får sina aviseringar via avtal från regionerna mot Skatteverket, hur kan tjänsten stödja samordningsnummer? Dessa kommer inte med i aviseringarna till regionerna.


  • För alla personposter som saknas i Personuppgiftstjänsten så gör tjänsten ett direktuppslag mot Skatteverket om personposten efterfrågas av en e-tjänst. Detta gäller även personposter med samordningsnummer.
  • Observera att det är endast get-kontrakten som ger denna verkan. Search-kontrakten stannar i Personuppgiftstjänstens databas.
    Notera att eftersom Stockholm har valt att inte avtala med Skatteverket att avisera sina personposter till Inera så kommer searchkontrakten ge ofullständigt resultat när man använder searchkontrakten och vill att sökresultatet ska inkludera Stockholms invånare.
    Aviseringsfiler för Region Stockholm läses in sedan oktober 2021.

1.11. Fråga: Vilken aktualitet har Personuppgiftstjänsten?


  • Personuppgiftstjänsten får aviseringar från Skatteverket fem gånger i veckan
  • Saknas en Personpost i tjänsten, slår Personuppgiftstjänsten mot Skatteverket för att hämta in den saknade posten.

1.12. Fråga: hur skapas ett nationellt Reservid (NRID)?

1.13. Fråga: tjänsten ska kunna hantera bilder som bilagor när man skapar ReservID men det står inte i tjänstekontraktsbeskrivningen hur det går till, står det någon annanstans?

1.14. Fråga: vad menas med linkedIdentity och primaryIdentity? Dessa refereras till i Tjänstekontraktsbeskrivningen http://rivta.se/domains/strategicresourcemanagement_persons_person.html

  • De används för för att koppla olika identiteter till varandra, t ex om det finns en koppling mellan ett personnummer och ett nationellt Reservid. Observera att även Skatteverkets kopplingar, t ex mellan ett personnummer och samordningsnummer, finns här.
  • Flaggan primaryIdentity indikerar om identiteten är en huvudidentitet. Detta är speciellt viktigt att notera eftersom det kan finnas flera länkade identiteter men bara en av dem är en huvudidentitet.

1.15. Fråga: i  kontraktet getPersonsForProfile så kan man välja om man vill ha exakt den identitet som man efterfrågar genom att sätta ignoreReferredIdentity till true, om man vill ha huvudidentiteten sätts flaggan till false. Hur fungerar detta med SearchPersonsForProfile och -Order?

  • Kontrakten returnerar alltid de eftersökta identiteterna via det villkor man sätter i queryLanguage, dvs som om ignoreReferredIdentity är satt till true i anropet.

1.16. Fråga: hur hanteras koppling av NRID när inget SNR/PNR håller ihop dessa? Finns risk att många NRID inte blir kopplade?

  • NRID kan i tjänsten kopplas till PNR, SNR eller annat NRID (vilket blir den nya huvudidentiteten). Som stöd till verksamheten att återsöka samma individ trots avsaknad av PNR/SNR, finns i tjänsten sökbar information med legitimeringsuppgifter (passnummer eller dylikt), namn, adress, ålder, kön mm.
  • Det finns också ett gemensamt verksamhetsramverk som bl.a. syftar till att ge vägledning till hur hantera personidentifiering och koppling av personidentifierare. https://inera.atlassian.net/wiki/spaces/PNRFHAR/pages/282568677

1.17. Fråga: finns det en fördröjning när kopplingen görs?

  • Nej, när kopplingen är gjord så finns informationen tillgänglig i Personuppgiftstjänsten.

1.18. Fråga: går det att registrera lokala reservidentiteter i Personuppgiftstjänsten och koppla dessa? Ska man göra det?

  • Huruvida man ska överföra befintliga lokala kopplingar mellan personidentifierare eller ej till den gemensamma tjänsten är primärt en verksamhetsfråga.Det finns dock funktioner i Personuppgiftstjänsten för att registrera lokala kopplingar, både i användargränssnitt och i tekniska systemgränssnitt (tjänstekontrakt för koppling). 
  • Det finns också ett gemensamt verksamhetsramverk som bl.a. syftar till att ge vägledning till hur hantera personidentifiering och koppling av personidentifierare. https://inera.atlassian.net/wiki/spaces/PNRFHAR/pages/282568677
  • Kopplingarna i Personuppgiftstjänsten kan endast göras till de nationellt accepterade PNR, SNR eller NRID. En lokal reservidentitet kan alltså kopplas till personens huvudidentitet, men inte kopplas till en annan lokal reservidentitet i Personuppgiftstjänsten. Om PNR eller SNR saknas, kräver en koppling av en lokal reservidentitet alltså uttag av ett NRID.
  • I tjänstekontraktsbeskrivningen hittar du information om de tekniska gränssnitten.
    http://rivta.se/domains/strategicresourcemanagement_persons_person.html
  • Se även filmer för att använda tjänstens administrationsgränssnitt för att koppla identiteter.
    https://www.youtube.com/playlist?list=PLofvkub1C51e0kCIguNHg6WD7NYGe4Dly

1.19. Fråga: hur samexisterar de kopplingar som Skatteverket gör i folkbokföringen med de kopplingar som görs i tjänsten?

  • Personuppgiftstjänsten håller reda på kopplingar som görs av Skatteverket och de kopplingar som görs av verksamheten. I filmen som visar hur man använder administrationsgränssnittet för att koppla identiteter finns det exempel som visar på hur tjänsten håller reda på kopplingar och alltid har en huvudidentitet för en person.
    https://www.youtube.com/playlist?list=PLofvkub1C51e0kCIguNHg6WD7NYGe4Dly

1.20. Fråga: hur hanterar Skatteverket felaktiga kopplingar mellan samordningsnummer och personnummer?

  • Kopplingen tas bort av Skatteverket och samordningsnummret blir åter gällande.

1.21. Fråga: Aktör (actor) ska anges för vissa kontrakt men fältet kan också utelämnas. Vad är tanken med det?

  • När en invånare via 1177 lägger in sina kontaktuppgifter agerar invånaren utan att tillhöra någon organisation, då kan aktör utelämnas. När t ex en vårdorganisation gör någon uppdatering i tjänsten så ska aktör finnas med.

1.22. Fråga: hur hanteras personer med skyddad identitet när personen har flera olika personidentifierare?

  • Personuppgiftstjänsten  kontrollerar med hjälp av information från Skatteverkets Navet om personen har fått en sekretessmarkering i folkbokföringen. I dessa fall lämnas inte känsliga uppgifter ut vid uppslag mot  Personuppgiftstjänsten och det signaleras till det verksamhetssystem som används för uppslag att sekretess gäller kring denna person. 
  • Från och med Personuppgiftstjänst 4.0 kommer det att vara möjligt att få ut kompletta uppgifter även för personer med sekretessmarkering, om det finns ett verksamhetsbehov. Dessa tjänstekontrakt har suffix unrestricted.

1.23. Fråga: enligt tjänstekontraktsbeskrivningen returneras länskod för sekretessmarkerade personer, blir det 99 när en sekretessmarkerad person flyttar till annat län?

  • Nej, Personuppgiftstjänsten returnerar 01-25 som länskod. 99 aviseras visserligen till den region som som personen flyttar ifrån men eftersom Personuppgiftstjänsten får alla aviseringar så kommer det i slutändan bli 01-25.

1.24. Kan en person med samordningsnummer eller reservidentitet få en sekretessmarkering?

  • Nej, endast personer som är folkbokförda i Sverige, dvs de som har personnummer, kan få sekretessmarkering, alternativt skyddad folkbokföring.

1.25. I vilka fall får man inte uppgift om vårdnadshavare?

  • Alla barn under 18 år ska ha en vårdnadshavare registrerad på sig. Om vårdnaden skulle saknas för ett barn så kan det vara t.ex. ett ensamkommande flyktingbarn.
  • Registrerad vårdnadshavare behöver inte ha ett fullständigt personnummer. Det kan vara en person som inte är folkbokförd i Sverige. Då redovisas det med endast födelsetid och namn. 
  • Observera att i Personuppgiftstjänsten har vi information om vårdnadshavare för barn med sekretessmarkering eftersom vi har fått det från Skatteverket men vi har lagt på ett extra skydd och lämnar ut begränsade uppgifter, dvs personnummer, namn, länskod samt relaterade personposter (t ex om personen har haft samordningsnummer).
  • Skulle man behöva uppgifter utöver dessa finns det speciella tjänstekontrakt med suffix unrestricted som går att använda. Detta finns dokumenterat här http://rivta.se/domains/strategicresourcemanagement_persons_person.html

1.26. Fråga: har fall med nytt personnummer, efter t.ex. byte av juridiskt kön, beaktats? Kan även vara kombinerat med skyddad identitet.

  • Via Skatteverkets Navet får Personuppgiftstjänsten uppgift om ev. byten av  personnummer, tidigare personnummer blir då ett s k hänvisningsnummer kopplat till personens nya huvudidentitet. Personuppgiftstjänsten speglar alltså här uppgifterna i folkbokföringen.
  • Finns en sekretessmarkering i folkbokföringen för personen slår den också till i Personuppgiftstjänsten. 
  • Från och med Personuppgiftstjänst 4.0 kommer det att vara möjligt att få ut kompletta uppgifter även för personer med sekretessmarkering, om det finns ett verksamhetsbehov.  Denna möjlighet realiseras med hjälp av tjänstekontrakt som har postfix Unrestricted. För mera information, se http://rivta.se/domains/strategicresourcemanagement_persons_person.html
  • Noteras kan att vid särskilt allvarliga hot kan person få byta till fingerade personuppgifter med nytt personnummer. I dessa sällsynta fall finns ingen information om bytet i vare sig Skatteverkets Navet eller i Personuppgiftstjänsten.

1.27. Fråga: om man ska t ex till en slutanvändare visa vilket kön som en person har, vilken information som finns i Personuppgiftstjänsten ska jag då använda?

1.28. Fråga: hur får nyfödda ett nytt personnummer och namn?

  • Inera förvaltar en tjänst som heter Födelseanmälan där man via ett journalsystem, som ansluts till tjänsten Födelseanmälan, elektroniskt kan anmäla ett barns födelse och som svar få tillbaka ett personnummer, se https://www.inera.se/tjanster/Fodelseanmalan
  • Förnamn måste föräldrarna anmäla till Skatteverket.
  • När födelsen registreras så får barnet den födande förälderns efternamn inom // exempel mamman har efternamnet Karlsson barnet får då /Karlsson/ som efternamn. Innan barnet blir tre månader ska förälder/föräldrar anmäla ett efternamn för barnet. Om ingen anmälan kommer till Skatteverket förvärvar barnet i detta exempel Karlsson.
  • Beroende på vilka som är föräldrar och deras status vad gäller giftemål får barnet ett efternamn, regler för detta finns i namnlagen https://www.riksdagen.se/sv/dokument-lagar/dokument/svensk-forfattningssamling/lag-20161013-om-personnamn_sfs-2016-1013


1.29. Fråga: vilka tecken är tillåtna för namn?

  • Det finns en uppsättning tecken som är tillåtna för namn enligt denna lista från Skatteverket https://www.skatteverket.se/privat/folkbokforing/namn.4.18e1b10334ebe8bc80004083.html
  • Förutom dessa tecken kan det förekomma "-", "/", ":" "'", exempel
    • /Karlsson/ - nyfött barn där efternamnet ej är registrerat
    • J:son - inga nya namn registreras med kolon men äldre namn kan förekomma
    • Jan-Erik - bindestreck för dubbelnamn
    • O'Learys för apostrof

1.30. Fråga: det verkar som om bara address2 är nödvändig för att få ut en persons postadress, i vilka lägen används address1?

  • Om en adress inte får plats i address2, fortsätter den i address1. 
  • Maximalt antal tecken i address2 och address1 är 35.
  • Skatteverkets tjänst Navet har följande algoritm när det gäller hur address2 och adress1 hanteras (de kallar fälten för utdelningsadress 1 och 2)

Det som inte får plats i Utdelningsdress 2 fortsätter i utdelningsadress 1, t.ex om en adress är för lång. 

Man skapar en folkbokföringsadress i 2 strängar på max 35 tecken var utifrån ett antal adressdelar.

Parametrarna och deras maximala längd:

Inparametrar:
1. Gatunamn 35
2. Gårdsnamn 35
3. Adressplatsnamn 35
4. Gatunummer  9
5. Metertal 10
6. Littera 2
7. adresstillägg 5
8. lägenhetsbet 5 (används ej)
9. populärnamn 35

Utparametrar:
1. adressforts 35
2. adressrad   35

Inparametrarna kopieras först till lokala variabler där de redigeras på så sätt att inledande och avslutande blanka tas bort, samt att flera blanka i rad ersätts med ett blanktecken.

Hur redigeringen nu ska göras beror på längden av inparametrarna. Med längd 1-7 menar jag längden på den sträng man får om man slår ihop de 7 första inparametrarna med ett blanktecken mellan. Med längd 1-6 menar jag längden av de 6 första inparametrarna osv.

Fall 1 (felfall)
======

Om någon av parametrarna är längre än de får vara eller om längd 1-3 är mer än 70 tecken så sätts adressrad och adressforts till tomma strängar. 

Fall 2
======

Om längd 1-8 är max 35 tecken så läggs de 8 första inparametrarna i adressrad och populärnamn i adressforts.

Fall 3
======

Om längd 1-6 är max 35 tecken så läggs de 6 första inparametrarna i adressrad. Parametarna 7-8 läggs i adressforts. Om hela populärnamn ryms så läggs det sist i adressforts annars skippas populärnamn.

Övriga fall
===========

Parametrarna 1-8 sätts ihop till en sträng. Sedan plockas ord för ord av denna sträng (ord anses avskiljas av blanktecken) och läggs så många som ryms först i adressrad och därefter så många som ryms i adressforts. Om hela populärnamn ryms så läggs det sist i adressforts.


1.31. Fråga: vid avregistreringsorsak AV, vad står avregistreringsdatumet för då?

1.32. Fråga: vid avregistrering ser det ut som avregistreringsorsak (deregistrationReasonCode) och avregistreringsdatum (deregistrationDate) är optionella i svaret från t ex GetPersonsForProfile. När kan det inträffa?

  • Personuppgiftstjänsten följer Skatteverkets regler för detta, som säger att dessa fält kan utelämnas i svaret men i praktiken sker detta aldrig, dock kan avregrestringsdatum vara 0.

1.33. Fråga: gallras uppgifter från Personuppgiftstjänsten?

  • Nej, alla uppgifter finns kvar, även vid avregistreringsorsak avliden. Skatteverket hade tidigare gallringar i Navet, som är källan för Personuppgiftstjänsten, men har i princip upphört med detta. Det kan då finnas personer som inte finns p g a tidigare gjorda gallringar. 
  • För information om hur Skatteverket historiskt har gallrat se Allmänn Beskrivning om Navet på Skatteverket, sök efter Gallring.

1.34. Fråga: stödjer Personuppgiftstjänsten fälten Anträffad död och Skyddad folkbokföring som Skatteverket införde 2019-01-01?

1.35. Fråga: hur påverkas relationer (relationship) vid avregistrering?

  • Avregistrering påverkar inte relationer för någon typ av avregistrering, oavsett om den görs av Personuppgiftstjänsten själv eller Skatteverket. Det enda undantaget är avregistreringsorsaken GN (Skatteverket) från gammalt tll nytt personnummer, då endast personnummer och namn finns kvar.

1.36. Fråga: hur fungerar icke-biologiskt vårdnadsskap (t ex adoption, fosterförälder) med ombud i t ex 1177.se och Journalen?

  • Vid registrering av adoption eller fosterföräldraskap skapas dels relationen mellan barnet och den vuxne under kategorin "Särlösning" (Adoptivmor, AM, Adoptivfar, AF respektive Annan person, AP) men denna relation kompletteras också senare med en relation: Vårdnadshavare på barnet, V och även med Vårdnadshavare för, VF på den vuxne. Det är endast den sistnämnda relationen som förmedlas till tjänsten från Skatteverkets tjänst Navet och därmed den som e-tjänster såsom 1177 kan nyttja i ombudfunktionalitet.
    OBS: det sista steget är en manuell handläggning och kan i vissa fall utebli hos Skatteverket. Typfallet är när det juridiska beslutet ska verkställas men den vuxne redan tidigare haft relationer till barnet. Därmed kommer (ibland) barnets V-relation finnas men inte den vuxnes VF, detta kan först kontrolleras av den enskilde hos Skatteverket och folkbokföringens etjänst (https://www.skatteverket.se/privat/folkbokforing.4.18e1b10334ebe8bc800039.html) men behöver inte vara samstämmigt med data i Personuppgiftstjänsten - meddelandet från Skatteverket om en förändring kan i dessa fall utebli. I förlängningen kan problematiken behöva tas direkt med SKV på telefon, mejl, ärende eller chatt (Skatteverket) för att Ineras tjänster ska kunna visa korrekta personuppgifter.

1.37. Fråga: i vilka fall saknas länskod (countyCode)?

  • Personposter med ReservID och Samordningsnummer samt personer som är avregistrerade saknar länskod. Om en personpost är märkt med avregistreringskod AV eller UV kommer det att finnas en länskod.
  • En sekretessmarkerad person har 01-25 eller 99 som länskod.

1.38. Fråga: i vilka lägen kan civilstånd (maritalStatus) utelämnas i svaret på tjänstekontraktet getPersonsForProfile?

  • Personuppgiftstjänsten följer Skatteverkets aviseringsfiler och där kan teoretiskt civilstånd utelämnas. I praktiken sker detta aldrig, civilstånd finns alltid för alla folkbokföringsposter, med civilståndskod (maritalStatusCode).
  • Civilståndsdatum (maritalStatusDate) finns för alla personposter från Skatteverket, utom för personer med civilståndskod lika med OG (ogift).

1.39. Finns det historisk information om personer, t ex var de har bott tidigare?

  • Via Personuppgiftstjänsten kan man få ut den historiska information som finns i folkbokföringsregistret. Tjänsten har ingen egen historik. Tjänstekontraktet för Personuppgiftstjänsten är konstruerat så att via en profilhantering så kan man styra hur mycket som tjänsten ska returnera efter anrop. Detta finns beskrivet i tjänstekontraktsbeskrivningen
    http://rivta.se/domains/strategicresourcemanagement_persons_person.html
  • Observera att den historiska delen av personposten inte innehåller komplett information motsvarande folkbokföringsposter. T ex saknas relationer. Skatteverkets dokumentation om Navet beskriver detta i det dokument som kallas för Allmän beskrivning.
  • Fält i de historiska posterna kan användas för att konstruera frågor via Personuppgiftstjänstens SimpleQL, https://confluence.cgiostersund.se/display/PU/SimpleQL.

1.40. Fråga: är tanken att NRID ska "buffras" lokalt dvs. att ett antal NRID tas ut i förväg i händelse av katastrof- och nödsituationer? 

  • Alla verksamheter ska ha lokala rutiner för driftstopp och katastrof- och nödsituationer, så det är primärt en verksamhetsfråga.

  • Det kommer vara möjligt för verksamheterna att ta ut ett antal NRID i förväg för att använda i katastrof- och nödsituationer. Dessa tas alltid ut via den nationella Personuppgiftstjänsten.

  • När mer information om personerna som tilldelats en sådan NRID framkommit, kan uppgifterna kompletteras i Personuppgiftstjänsten.

  • Det finns också ett gemensamt verksamhetsramverk som bl.a. syftar till att ge vägledning för detta. https://inera.atlassian.net/wiki/spaces/PNRFHAR/pages/282568677

1.41. Fråga: hur realiseras uppdatering av patientens kontaktuppgifter via 1177? När är de tillgängliga för vården?

  • Det finns specifika tjänstkontrakt (de som innehåller ordet "contact") som ska användas för uppdatering av patientens kontaktuppgifter. Se http://rivta.se/domains/strategicresourcemanagement_persons_person.html
  • Kontaktuppgifterna lagras i Personuppgiftstjänsten och blir efter uppdatering omedelbart tillgänglig för vårdsystemen via tjänstekontrakt för läsning, när vårdsystemen har anslutit sig till dessa tjänstekontrakt.

1.42. Fråga: I tjänstekontraktsbeskrivningen för UpdatePersonContactInformation så är är kardinaliteten för versionToUpdate 0..1 trots att det står att man ska ange den, hur fungerar det? 

  • versionToUpdate måste alltid anges för kontraktet UpdatePersonContactInformation. Annars får man ett fel tillbaka. Tjänstekontraktsbeskrivningen kommer att korrigeras i nästa majorversion.

1.43. Fråga: i tjänstekontraktsbeskrivningen finns fältet GivenNameIndicator, motsvarande Skatteverkets Tilltalsnamnsmarkering. Värdemängden är 10-99 som beskriver vilka förnamn som är tilltalsnamn. Förutom det som står i informationsspecifikationen, finns det andra restriktioner kring värdemängden?

  • Den andra siffran är antingen lika med 0 eller har ett värde som är större än den första siffran. Dvs värden som 51 förekommer inte. 10, 16 och 89 är värden som kan förekomma.

1.44. Fråga: vissa fält i tjänstekontraktsbeskrivningen har ingen begränsning i längd. Finns det någon begränsning för dessa fält?

  • De fält som inte har någon explicit begränsning har i tjänsten en faktiskt begränsning på 256 tecken.

1.45. Fråga: Viss informatik i informationsspecifikationen, t ex koder, är hämtad från Skatteverket, var hittar jag mera information?


1.46. Fråga: I informationsspecifikationen finns en bild på informationsmodellen men den är svårläst, finns motsvarande bild i bättre upplösning?

Klicka för bättre upplöst bild nedan

Informationsmodell

1.47. Fråga: finns det någon test-suite?



  • No labels

Publik Information