Förfrågningsunderlag Leverans enligt ABA 99 Projekt Akutmottagning vid Norrlands Universitetssjukhus Program för Logistiksystem Sida 1
Teknisk specifikation på IT-tjänster Innehåll A. Förekommande IT system, leverantörsnamn och systemägare inom VLL B. Krav på systemet enligt Teknisk specifikation på IT-tjänster C. Teknisk Specifikation PÅ IT-TJÄNSTER, HÅRD- OCH MJUKVARUSYSTEM D. Tjänster mot befolkningsregistret Sida 2
A. Förekommande IT system, leverantörsnamn och systemägare inom VLL IT-System som nämnts som kommande kandidater för integration med systemet som upphandlas i projektet A-sim. Nedan listade med Leverantörsnamn och systemägare i VLL. Labsystem - Remiss och Svar (RoS) RoS (uppgraderas 2013) Leverantör: Tieto Webbplats: http://www.flexlab.com/index.html Databas: SQL Server från Microsoft Systemägare i VLL: Jens Boman Systemförvaltare: Annika Nilsson (Informatikenheten) RöntgenInformationsSystem (RIS) Sectra RIS (Informationssystem som är integrerat med röntgen bildlagringssystem PACS) Leverantör: Sectra Webbplats: http://www.sectra.com/medical/radiology_it/offering/diagnostic_imaging_suite/solutions/ Databas: SQL Server från Microsoft Systemägare i VLL: Katrine Ricklund Åslund Systemförvaltare: Tomas Uddståhl (Bild och FunktionsMedicin) Patientjournalsystem (Basjournal) SYSteam Cross (uppgraderas till NCS Cross under hösten 2013) Leverantör: Evry Webbplats: http://www.evry.se/itservices/health-care/journalforing/ Databas: Systemet är uppbyggt kring flera databaser (en per klinik) och en övergripande central databas (Cross). Databashanterare DB2 från IBM Systemägare i VLL: Göran Algers Systemförvaltare: Hans Nilsson (Informatikenheten) Ambulansjournal Paratus Leverantör: Webbplats: SAAB Performit http://www.saabperformit.se/sv/sidor/paratus-information-system.php SQL Server från Microsoft Databas: Systemägare i VLL: - Systemförvaltare: Hans Grubb (Ambulanssjukvården) Befolkningsregister Master Leverantör: Evry Webbplats: - Databas: Gränssnitt: SQL Server från Microsoft Till befolkningsregistret finns en webbtjänst med tillhörande tjänstegränssnitt. Bifogas i filen Tjänster mot befolkningsregistret.pdf Sida 3
Systemägare i VLL: Systemförvaltare: Tommy Sköld Elisabeth Hällgren VLL 951-2013 B. Krav på systemet enligt Teknisk specifikation på IT-tjänster Utgående från dokumentet Teknisk specifikation PÅ IT-TJÄNSTER, HÅRD- OCH MJUKVARUSYSTEM inom VLL:s miljö. Hela dokumentet kan ses som beskrivning av den IT-miljö där det upphandlade systemet ska kunna köras. För upphandlingen av Program för Logistiksystem, ställs kraven på systemet i nedanstående punkter i dokument C: 1: Hela 2: Hela 3.1.1 [TK3140] - [TK3160] [TK3182] - [TK3186] 3.1.3: Hela 3.2.1: Hela 3.2.2: Hela. Målsättningen är här att systemet tål att underliggande infrastruktur uppdateras i enlighet med befintlig rutin. Windows operativsystem uppdateras med sk säkerhetspatchar månatligen. VLL s sätt att installera programvara (Upkeeper) bör kunna användas. 3.2.4: Samtliga krav här är bör-krav. 3.2.5: Hela 3.2.6: Hela 3.2.7: [3854] 3.2.8: Hela 3.2.9: Hela 3.3: Hela 3.4: Hela 3.6.2: Hela 3.6.3: Hela 3.6.6: Ange krav på bildskärmar 4: Hela Dokumentation Hela kapitlet utom [10235] Sida 4
C. Teknisk Specifikation PÅ IT-TJÄNSTER, HÅRD- OCH MJUKVARUSYSTEM Inom VLL:s miljö FASTSTÄLLT Datum:. Sign:.. IT-Chef Jörgen Winqvist Datum:. Sign:. Infrastruktursystemägare Mikael Robertsson Teknisk Specifikation PÅ IT-TJÄNSTER, HÅRD- OCH MJUKVARUSYSTEM Inom VLL:s miljö Revision Datum Kommentar Signatur 1.0 2012-01-16 Dokumentet skapas Göte L 2.0 2012-09-05 Version 2.0 Göte L 2.1 2012-09-20 Version 2.1 Alla Sida 5
Innehållsförteckning VLL 951-2013 1. ALLMÄNT... 7 1.1 SEKRETESS... 7 2. KRAV PÅ TJÄNSTER... 9 2.1 LEVERANS... 9 2.2 RISKHANTERING... 9 2.3 DRIFT OCH FÖRVALTNING... 9 3. GENERELLA KRAV... 10 3.1 HÅRDVARA... 10 3.1.1 Nätverk... 10 3.1.2 Video... 12 3.1.3 Service... 13 3.2 IT-SÄKERHET... 14 3.2.1 Informationssäkerhet... 14 3.2.2 Säkerhetsuppdateringar... 14 3.2.3 Certifikat... 14 3.2.4 Lösenord och behörigheter... 14 3.2.5 Loggning... 15 3.2.6 Kryptering... 15 3.2.7 Återställning... 16 3.2.8 Antivirusskydd... 16 3.2.9 Active Directory... 16 3.2.10 Batterier och UPS... 16 3.3 DRIFTÖVERVAKNING... 16 3.4 SERVRAR... 17 3.4.1 Servertyp... 17 3.4.2 Operativsystem... 17 3.4.3 Hårdvarulås... 17 3.4.4 Databashanterare... 17 3.4.5 Webbservrar... 17 3.4.6 Integrationsplattform... 17 3.4.7 Geografisk placering av servrar... 17 3.5 LAGRING... 17 3.5.1 Lagring SAN... 17 3.5.2 Backupsystem... 17 3.6 KLIENTER OCH ÄNDUTRUSTNING... 18 3.6.1 Klienttyp... 18 3.6.2 Operativsystem... 18 3.6.3 Applikationsdistribution... 18 3.6.4 OS-distribution... 18 3.6.5 Utskrifter... 19 3.6.6 Bildskärm... 19 4. APPLIKATION... 20 5. DOKUMENTATION... 21 Sida 6
1. ALLMÄNT VLL 951-2013 Läkemedelsverkets föreskrifter om medicintekniska produkter LVFS 2003:11 samt Socialstyrelsens föreskrifter SOSFS 2005:12 om ledningssystem för kvalitet och patientsäkerhet inom hälso- och sjukvården samt SOSFS 2008:1 är styrande för IT och medicintekniska produkter. Från och med 2012 ska alla IT-produkter, både hårdvara och mjukvara, som klassas som medicintekniska produkter CEmärkas. Detta gäller alla produkter som används till diagnos, övervakning och behandling av patienter men också produkter som integreras eller används tillsammans med sådana produkter. Lagen om medicintekniska produkter och dess krav på CE-märkning omfattar nu alltså också t.ex Journalsystem och system som interagerar med detta. Läkemedelsverket och Socialstyrelsen har gemensamt förtydligat krav på system som ska integreras eller kommunicera med andra system (Se myndigheternas hemsidor!) Gränssnitt ska vara definierade antingen genom standardiserade format eller genom uppräkning av sådana system som tillverkaren har konstaterat vara kompatibla. System ska vara skyddade mot virusangrepp utan att validering blir ogiltig. Det aktuella systemet ska inte störa andra system. Om kommunikationskanaler och länkar inte är egna tillbehör utan t ex befintliga lokala nätverk, Internet, telenät, kabel etc., som man har mer eller mindre inblick i eller kontroll över, bör dessa betraktas som ett försörjningssystem 1. Tillverkaren måste då ta hänsyn till svagheter genom en riskanalys av en sådan länk och ta ställning till vad som händer vid ett avbrott samt vid behov överväga åtgärd för att kompensera för kommunikationsbortfall. 1 Försörjningssystem är ett begrepp som bl a används i Socialstyrelsen föreskrift om kvalitetssystem i vården SOSFS 2005:12: Försörjning av tjänster, produkter och teknik 7 Ledningssystemet skall säkerställa att det finns rutiner för inköp av tjänster, produkter, försörjningssystem (t.ex. el, vatten och gasanläggningar) och informationssystem (t.ex. tele och data) från leverantörer som är bedömda och godkända, och säker användning och hantering av produkter, försörjningssystem och informationssystem. 1.1 Sekretess Patientsekretess och Patientdatalagen (PDL) gäller för system och projekt inom VLL som även en extern leverantör som tillfälligt arbetar inom VLL omfattas av. Personuppgiftslagen (PUL) måste tas i beaktande vid hantering av personuppgifter vid registrering av användare mm. Användaren måste godkänna om uppgifter sparas. Upphovsrättslagen (URL) ska beaktas för bland annat programvara, mönsterskyddade symboler, dokument, bilder, foton, ljud, musik, film, videoinspelningar av t.ex TV-program. Spårbarhet är viktigt inom en offentlig myndighet som VLL och därför loggförs aktiviteter eller i vissa speciella fall skrivs minnesanteckningar. Hur detta går till finns dokumenterat för varje rutin. Sida 7
Utländska molntjänster och placering av servrar i annat land är inte tillåtet. Även placering av servrar utanför landstingets lokaler men inom landet måste prövas eftersom landstinget har juridiskt ansvar för informationen och biträdesavtal måste skapas och ingås med leverantören.. Sida 8
KRAV PÅ TJÄNSTER 2.1 Leverans [TK2000] Leverantören kan svara för leveranser inom hela Västerbottens Läns Landsting dit även filialer och kontor inom andra län omfattas. [TK2030] Projektledningsmodell ProjektIL eller uppdragsmodell UppdragIL används inom landstinget inom projektarbete. [TK2050] Medicinteknisk validering (ibland kallad certifiering), tillåts av läkemedelsverket att det sker efter installation i landstingets infrastruktur. På detta sätt undviks systemstatus egentillverkning och leverantören kan ta ansvaret fullt ut efter att ha verifierat installationen i samråd med landstinget. Villkor:Bör-krav 2.2 Riskhantering [TK2200] Innan installationen är slutförd utförs en riskanalys. Riskanalysen bör följa SS ISO 31000 FMEA (Failure Modes Effect Analysis) för systemet och SS ISO 27001 för informationssäkerhet. Föreskriven i SOSFS 2011:9 av Socialstyrelsen. [TK2220] Om leveransen innehåller certifierad medicintekniska produkter så bör hela projektet genomföras enligt SS-EN 80000 (ISO 80000) Riskhantering tillämpad på medicintekniska datanät som omfattar planering, projektering, installation, anslutning, konfiguration, drift, underhåll och avveckling och inkluderar personal från Leverantör, Informatik och Medicinteknik. 2.3 Drift och förvaltning [TK2230] Landstinget arbetar inom drift och förvaltning med en anpassad version av PM3 (kallad Systemförvaltningsmodell VLL) och med ramverket ITIL version 3 för alla system. Detta gäller även för alla nyanskaffningar. ITIL rekommenderas av Socialstyrelsen och kommer att ingå i regleringen av SDLF (System Development Life Cycle) för medicintekniska produkter. SLA:er (Service Level Agreement/Serviceavtal) upprättas för drift och teknisk service. Sida 9
3. GENERELLA KRAV 3.1 Hårdvara 3.1.1 Nätverk [TK3000] Utrustningen är CE-märkt. [TK3005] Anslutning till VLL:s partvinnade UTP kopparkabelnät sker via RJ45-kontakter TIA/EIA 568/ ISO 8877/IEC 60603. Eget draget kopparnät förekommer inte. Villkor: Skall-krav där kopparnät används. [TK3007] Anslutning till VLL:s fibernät sker via LC-kontakter (IEC 61754-20) och/eller SC-kontakter (IEC 61754-4). Eget draget fibernät förekommer inte. Villkor: Skall-krav där fibernät ska anslutas. [TK3010] Ethernet (10/100/1000 Mbit/s) IEEE 802.3 utgör LAN-standard för trådbundna nätverk inom VLL. IEEE 802.11 a,b,g eller n utgör WLAN (WiFi) standard för trådlösa nätverk som använder ISMfrekvensbanden 2,4 GHz och 5 GHz. Alla frekvenser och kanaler som används är dokumenterade och avstämda med landstinget IT-enhet och radiokanalsansvarig. [TK3015] All LAN-trafik hanteras av VLL:s befintliga nätverksutrustning och passar in i VLL:s nätverksarkitektur. All nätverksutrustning tillhandahålls av VLL. Villkor: Bör-krav där leverantör som uppfyller kravet värderas högre. [TK3016] All WAN- och WLAN-trafik hanteras av VLL:s befintliga nätverksutrustning och passar in i VLL:s nätverksarkitektur. [TK3020] All utrustning har redundanta nätverksanslutningar för största möjliga tillgänglighet. [TK3025] All utrustning som kopplas in i VLL:s nätverk har en internationellt unik MAC-adress enligt IEEE 802 EUI-48 och MAC-48. Det får inte existera duplikat i nätverket. [TK3030] Om systemet innehåller utrustning som nyttjar annan radiotrafik än WLAN och på andra frekvenser, ska de frekvenser som utnyttjas, deklareras och godkännas av VLL innan de får användas inom landstingets byggnader, så att inte störningar uppstår på befintliga system. [TK3040] Utrustning som ansluts till publikt mobilt datanätverk klarar GPRS, EDGE, HSDPA hos operatör som VLL vid aktuellt tillfälle har avtal med (dvs styrt av SIM-kort) samt bör kunna deltaga i VLL:s privata APN. Utrustning som dessutom kan överföra data över LTE ska väljas i första hand. Sida 10
[TK3045] Dokumentera utrustningens mått. Ange om utrustningen kan monteras i standard-rack. Villkor: bör-krav. [TK3100] IP (RFC 791) används som nätverksprotokoll. [TK3102] VLL är Local Internet Registrator (LIR) och kan registrera sina egna Internet-adresser. Alla IP-adresser som ska användas inom VLL:s nätverk ska begäras från VLL:s LIR-administratör (registrator@vll.se). Detsamma gäller autonoma system identiteter (ASID), virtuella LAN:s (VLAN ID), virtuella routers VRF-namn, IP-portar, Hostnames, Domännamn mm nätverksidentifikationer. [TK3110] Både IP version 4 (IPv4) RFC 791 och IP version 6 (IPv6) RFC 2460 stöds med s.k. Dual Stack så att båda versionerna kan samexistera. Villkor: Bör-krav där leverantör som klarar kravet värderas högre. [TK3115] Där IPv6 ännu ej är implementerat så finns en implementationsplan från leverantören och kostnaden för införandet av IPv6 tillkännagetts landstinget skriftligt i erbjudandet. [TK3120] IP version 6 (IPv6) stöds enligt IPv6Forums specifikationer Phase 1 och Phase 2 och är IPv6-Ready. Villkor: Bör-krav där leverantör som klarar kravet värderas högre. [TK3130] Typkonfigurationer och mallar för konfigurationer finns dokumenterade och tillgängliga. [TK3135] Baslägesparametrar ( Default-värden ) i driftläge och bör-värde samt gränsvärden finns dokumenterade. [TK3140] DHCP används av systemets klienter. Servrar har fast IP-adress. [TK3150] DNS användas av systemet. [TK3155] Alla adresser anges som namn och inte IP-nummer för att flexibelt kunna flyttas i nätverket. Sida 11
[TK3160] Hostname (Datornamn) ska kunna väljas fritt och följer VLL:s standard. [TK3170] Systemets bandbreddskrav är angivet. [TK3175] Minnesstorlek och cache anges där detta kräver övervakning eller konfiguration av Informatikenhetens personal. [TK3180] Systemet är inte känslighet för jitter (även benämnd IP Packet delay variation (IPDV) RFC3393, RFC5481) (<=5ms). Jittergränser anges. [TK3181] Systemet är inte känsligt för nätverks-latency (RTT <= 50ms). Gränsvärden angivna. [TK3182] Systemets känslighet för belastning (maximalt antal sessioner och anrop) anges. Ange eventuella lastbalanseringslösningar. [TK3183] Systemets är inte känsligt för normala (<=0,05%) packetförluster (Packet Loss). Ange gränsvärden. [TK3185] Samtliga IP-protokoll och portar som produkten använder finns dokumenterade. Villkor: Bör-krav [TK3186] Systemet ställer inga krav på QoS i nätverket. Villkor: Bör-krav 3.1.2 Video [TK3200] Digital video följer standard EIA/CEA-861 enligt Digital Visual Interface (DVI) revision 1.0 eller senare, DisplayPort eller High Definition Multimedia Interface (HDMI) version 1.3 eller senare. Villkor: Bör-krav [TK3210] Distribution via VLL:s nätverk ska ske med multicast. I särskilda fall tillåts unicast vilket avgörs av VLL:s informatikenhet. Villkor: Bör-krav [TK3220] För SDTV via IP används ISO MPEG2 över MPEG-TS (SPTS) ITU-T H.222/ISO 13818. För HDTV används ISO MPEG4 /ITU H264. Sida 12
[TK3230] VLL:s befintliga IPTV-streaming-servers kan användas som källa i IPTV-sammanhang. Lösning finns beskriven. 3.1.3 Service [TK3300] Modem får inte anslutas permanent till utrustning som är direkt eller indirekt ansluten till VLL:s nätverk. Utringande modem för diagnostik och support får inkopplas temporärt vid enstaka supporttillfälle och får då inte lämnas utan övervakning. [TK3320] Fjärrservice utförs främst via leverantörens Sjunet-anslutning som följer Sjunets uppsatta regelverk. I särskilda fall kan VLL medge att VLL:s VPN-klient får användas för anslutning via Internet. Sida 13
3.2 IT-Säkerhet 3.2.1 Informationssäkerhet [TK3400] Systemet stödjer Socialstyrelsens föreskrivna (SOSFS 2011:9) informationssäkerhetsstandard SS ISO 27001. [TK3410] Säkerhetsrutiner finns dokumenterade och är testade på plats efter installationen. [TK3420] VLL:s Säkerhetspolicy för Västerbottens läns landsting diarienr VLL 718:1-2011 med konkretiseringen Informationssäkerhet för VLL Riktlinjer diarienr 1392-2011, är styrande för informationssäkerhet inom landstinget. 3.2.2 Säkerhetsuppdateringar [TK3500] Systemet uppdateras kontinuerligt via service packs, patchar och fixar för att upprätthålla högsta möjliga säkerhet och tillgänglighet.. VLL använder Microsoft Windows System Update Services (WSUS) och för vissa programvaror distributionssystemet Upkeeper för att uppdatera systemen. Levererade produkter deltar i samma system. [TK3505] Om WSUS eller Upkeeper ej kan användas vid uppdatering beskrivs hur kontinuerlig uppdatering sker. Villkor: Bör-krav där leverantör som uppfyller kravet värderas högre. [TK3510] Periodicitet på uppdateringar redovisas. Villkor: Bör-krav [TK3520] Rutiner för uppdateringar finns dokumenterade. Om säkerhetspatchar, säkerhetsuppdateringar och antivirusuppdateringar saknas redovisas hur säkerheten säkerställs. Både Socialstyrelsen och Läkemedelsverket kräver att systemen ska vara skyddade mot virusangrepp och att antivirusuppdateringar inte häver validering/certifiering. 3.2.3 Certifikat [TK3600] Där certifikat används ingår dessa i VLL:s PKI-system där SITHS-certifikat används. 3.2.4 Lösenord och behörigheter [TK3700] Lösenordet och Användaridentiteten klarar minst sju (7) alfanumeriska tecken. Villkor: Bör-krav Sida 14
[TK3710] Lösenordet kan ändras av användaren själv. Villkor: Bör-krav [TK3720] Systemet kan användas på normalt sätt, utan att administratörsbehörighet behövs av normal användare. Endast systemadministration och konfiguration behöver administrationsrättigheter. Villkor: Bör-krav där leverantör som uppfyller kravet värderas högre. [TK3730] VLL har tillgång till högsta behörighet till systemets alla delar. Där leverantören inte kan medge högsta behörighet, motiveras detta i dokumentationen med det regelverk/rutiner som ska gälla. Villkor: Bör-krav [TK3750] SITHS-kort (SS 614314) används. Utrustningen ska då klara ICC smarta kort enligt ISO 7816-15 med RSA PKSC #15. SITHS-korten innehåller också avläsningsbar HiCo magnetremsa med 3 spår enligt ISO 7811 1-6. Dessutom finns RFID för närhetsavläsning enligt ISO 14443 A och streckkod för personnummer enligt ISO 15426-1 och 15416. Villkor: Skall-krav [TK3755] Finns specifika säkerhetsregler (t.ex Access Control List - ACL) så redovisas dessa. 3.2.5 Loggning [TK3800] VLL har central säkerhetsloggning. Levererat system loggar till det centrala säkerhetsloggningssystemet eller lokala Windows Händelselogg alla viktiga händelser. Om dessa loggningslösningar ej kan nyttjas så beskrivs annan loggningslösning. Villkor: Bör-krav där leverantör som uppfyller kravet värderas högre. [TK3810] Datum och tid för loggar är synkroniserade inom systemet och vilket finns dokumenterat. [TK3820] Datum och tid hämtas från VLL:s tidsservrar (NTP). 3.2.6 Kryptering [TK3830] Känsliga patientuppgifter som faller under Patientdatalagen krypteras vid överföring över nätverk. [TK3835] Känsliga patientuppgifter som faller under Patientdatalagen krypteras vid lagring. [TK3840] Kommunikation som innehåller information som allvarligt kan skada systemets funktion krypteras. T.ex används SSH istället för Telnet vid konfiguration av utrustning. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. Sida 15
3.2.7 Återställning VLL 951-2013 [TK3850] Återställning till fabriksinställningar finns dokumenterade men är skyddade. Detta kan också, beroende på systemtyp, ske med s.k. återställnings-cd som då tillhandahålls till och med fem år efter godkänd leverans. [TK3854] Backup- och Restore-rutiner finns dokumenterade. 3.2.8 Antivirusskydd [TK3860] Systemet har antivirusskydd (inkluderar Anti-Spyware, Anti-adware, Anti-Phishing, skydd mot skadlig kod) eller kan nyttja VLL:s antivirusplattform från McAfee (version 8.8 eller senare) som kontinuerligt uppdateras. Om virusskydd saknas så kommer systemet att isoleras. Om annat virusskydd används så ska detta vara väl dokumenterat med fungerande uppdateringsrutin men VLL kan välja att isolera systemet ändå. 3.2.9 Active Directory [TK3880] Systemet kan anslutas till VLL:s AD som är det centrala auktorisations- och autenticeringssystemet inom landstinget. System som inte kan deltaga som en del av VLL:s AD kommer att isoleras i ett eget nätverkssegment och tillåts inte kommunicera med andra system inom VLL. Villkor: Bör-krav där leverantör som uppfyller kravet värderas högre. 3.2.10 Batterier och UPS [TK3890] Viktiga systembatterier klarar minst 12 månader efter godkänd leverans upprätthålla minst 50% av ursprunglig laddningskapacitet. Underskrids värdet tillhandahåller leverantören utan kostnad ett nytt batteri. [TK3895] UPS (Un-interruptable Power Supply) finns som klarar minst en timmes drift om inte VLL:s centrala UPS kan användas eller är tillräcklig. 3.3 Driftövervakning [TK3900] Systemet klarar SNMPv2 eller Microsoft WMI 1.0 och kunna ingå i VLL:s övervakningssystem WhatsUp. MIB:ar och viktiga övervakningsparametrar ska finnas dokumenterade. Villkor: Bör-krav där leverantör som uppfyller kravet värderas högre. [TK3905] Systemet klarar SNMPv3. Sida 16
3.4 Servrar 3.4.1 Servertyp [TK4010] VLL:s standardserver är virtuell och inga restriktioner gällande version av hypervisor får förekomma. Krav på reservation av fysiskt minne och CPU till server tillåts ej. 3.4.2 Operativsystem [TK4020] Microsoft Windows Server 2008 R2 med senaste servicepack är standardoperativsystem för servrar. Installerat språk är engelska. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. 3.4.3 Hårdvarulås [TK4030] Där hårdvarulås används ansluts detta via en USB-IP hubb av märke Digi AnywhereUSB14. 3.4.4 Databashanterare [TK4040] Microsoft SQL Server 2008 R2 med senaste servicepack är standard inom VLL för databashanteringsservrar. Installerat språk är engelska. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. 3.4.5 Webbservrar [TK4050] Microsoft Internet Information Services 7.5 används som webbserver inom VLL. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. 3.4.6 Integrationsplattform [TK4060] Microsoft BizTalk Server används som integrationsplattform. 3.4.7 Geografisk placering av servrar [TK4065] Om lagring av VLL:s data ej sker inom VLL:s lokaler ska geografisk placering anges. Lagring utanför landets gränser är inte tillåtna. 3.5 Lagring 3.5.1 Lagring SAN [TK5010] Anslutning mot landstingets lagringsnätverk görs med fiber-channel med av landstinget godkända fiberkort (ex. QLogic). [TK5020] All volymhantering är virtualiserad med IBMs Storage Volume Controller (SVC) och hanteras av VLL. 3.5.2 Backupsystem [TK5060] IBM Tivoli Storage Manager (TSM) gäller som landstingets backupsystem vid central backuphantering och används av alla applikationssystem. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. Sida 17
3.6 Klienter och ändutrustning 3.6.1 Klienttyp [TK6010] VLL erbjuder idag våra användare fyra olika varianter av klientdator. Två stycken stationära och två stycken bärbara persondatorer. Stationär standard och stationär avancerad. Bärbar standard och bärbar avancerad. Grundkrav hårdvara stationär: USB 2.0, Grafikkort med VGA samt Displayport, Ethernet 10/100/1000, Svenskt Tangentbord, och COM-port Extra grundkrav hårdvara bärbara datorer: WIFI 802.11n 5GHz Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. [TK6012] VLL erbjuder också två olika typer av surfplattor. Den ena baserad på Apple IOS och den andra på Android. WIFI 802.11n 5GHz samt i vissa fall anslutning till det mobila näverket 3G/4G. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. [TK6015] Persondator-hårdvaran ska ha ett internationellt unikt UUID (ISO/IEC 9834-8) när programvara ska distribueras och underhållas centralt vid VLL. [TK6017] Vid uppstart är klientdator användbar efter maximalt 2 minuter. 3.6.2 Operativsystem [TK6020] Microsoft Windows 7 x64 Swe med senaste servicepack. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. 3.6.3 Applikationsdistribution 3.4.1.1 Upkeeper [TK6030] För distribution av applikationer och programvara använder VLL UpKeeper för central distribution. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. 3.6.3.2 Citrix / XenApp [TK6040] Citrix online plugin version 12 eller senare. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. [TK6045] Citrix XenApp ver 5.0. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. 3.6.4 OS-distribution [TK6050] För nyinstallation och ominstallation av klienter använder VLL upkeeper. Inga manuella installationer utförs av Informatikenheten. Sida 18
3.6.5 Utskrifter [TK6070] VLL har standardiserat skrivar-parken på 4 modeller. Lokal och liten arbetsgrupp, större arbetsgrupp, färgskrivare samt kopieringsvolymmaskin. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. 3.6.6 Bildskärm 3.4.1.2 Standardbildskärm [TK6080] 19 4/3 format. Upplösning 1280x1024. Bildskärmarna har DisplayPortanslutning. 3.4.1.3 Visningsskärm [TK6090] Större bildskärmar som också kan användas för film och TV ska ha minst två HDMIanslutningar, för att kunna ansluta Set.Top-Box och DVD-spelare samtidigt. Sida 19
4. APPLIKATION [TK7010] Mjukvarusystem som används inom vårdverksamhet eller integrerat med vårdsystem ska vara CE-märkt enligt Socialstyrelsens och Läkemedelsverkets regelverk. [TK7020] Beroenden till tredjepartsprogram, som Acrobat Reader, Java, ordbehandlare, med flera, och andra applikationssystem, dokumenteras och redovisas. [TK7050] Applikationen kan skala om sig till annan skärmsupplösning. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. [TK7060] Fungerar med mus, tangentbord. [TK7060] Fungerar med pekteknik (touch). [TK7065] Fungerar med röststyrning. [TK7070] Applikationen är oberoende av nätverksmedium och fungerar således lika bra i kabel-, fiberoch trådlösa nätverk. Sida 20
5. Dokumentation [TK10200] All dokumentation ska tillhandahållas i känt elektroniskt format som ISO/IEC 32000 PDF, ISO/IEC 26300 OpenDocument Format ODF, Microsoft Office 2003 format. [TK10210] Systembeskrivning med översiktlig flödesbeskrivning av systemet och alla dess komponenter (mjukvara och hårdvara) med arkitektur, teknologier, standards och protokoll ska levereras med produkten. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre [TK10211] Detaljerade hårdvaru- och mjukvaru-specifikationer för komponenterna inklusive subkomponenter (t.ex kretskortbestyckning, inbyggda extra enheter), nödvändiga tilläggsprodukter (kablar, pluggar, konverters mm) och mjukvarulicenser. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre [TK10220] Dokumentation av (1) systemkrav för server och klient, (2) hårdvarukrav, (3) operativsystem, (4) servicepack-nivå/patchnivå, (5) installationsanvisningar, (6) avinstallationsanvisningar, (7) användarmanualer, (8) administratörsmanualer, (9) driftinstruktioner ska finnas. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre [TK10230] Typkonfigurationer ingår i dokumentationen. Villkor: Bör-krav [TK10235] Mean Time Between Failure (MTBF) bör dokumenteras för kritiska delar av systemet. Villkor: Bör-krav [TK10236] Gränssnitt mot andra system är dokumenterade Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre. [TK10240] Databasstrukturer som tabeller, index och relationer ingår i dokumentationen. Villkor: Bör-krav [TK10250] Detaljerade Installations och migrationsplaner från andra eller äldre system, existerar. [TK10255] Dokumentation av kontaktuppgifter för VLL:s helpdesk och tekniker tillhandahålls. [TK10256] Beskrivning av tillvägagångssätt för överlåtelse och injustering av systemet under överlåtelseperioden, existerar. Sida 21
[TK10257] Dokumentation av alla fel-, varnings- och informations-meddelanden i sorterad ordning, där Meddelandet beskrivs, syftet med meddelandet, miljön/ursprung/modul där meddelandet skapades, Åtgärd/-er som krävs av systemanvändare/administratör/servicetekniker och förväntat resultat av åtgärden. Villkor: Bör-krav där leverantörer som uppfyller kravet värderas högre Sida 22
D. Tjänster mot befolkningsregistret version 2010-12 Innehåll Förutsättningar...24 Säkerhet...24 WSDL...24 Test...24 Produktion...24 Personnummerbyten...24 Adresser...25 Skyddade adresser...25 Tjänster...25 GetPerson...25 FindPerson...26 GetCountries...28 GetRegionalDevisions...28 GetCareChoice...28 Dataformat...29 Personnummer... 30 Nil...30 Person...30 Deregistration...31 SwedishAddress...31 ForeignAddress...32 Relation...32 Country...33 County...33 Municipality...33 Parish...33 CareChoice...33 PrimaryCareChoice...33 ArgumentFault...34 FormatFault...34 ServerFault... 34 Dokumenthistorik... 34 Sida 23
Inledning Det här dokumentet är en specifikation av de tjänster som Västerbottens läns landsting tillhandahåller för uttag av aktuella personuppgifter. Målgruppen är tekniskt ansvariga och de utvecklare som ska integrera ett system med befolkningsregistret. Dessa tjänster är det gränssnitt vilket Informatikenheten vill att alla system använder sig av. Om någon personuppgift saknas, eller om ett system har behov av att söka i befolkningsregistret på ett annat sätt, är vi förstås beredda att vidareutveckla tjänsterna. Förutsättningar Säkerhet Den teknik som används för autentisering är så kallad basic authentication enligt http-protokollet, där användarnamn och lösenord skickas Base64-kodat. I autentiseringen är det inte slutanvändarens identitet som kontrolleras, utan användarnamnet och lösenordet är unikt per anropande system. Om systemet redan har ett Active Directory-konto hos landstinget så kan detta användas. Annars tilldelas ett konto av Informatikenheten. Informatikenheten lägger också upp en åtkomstbehörighet till tjänsterna. Vi vill att lösningen byggs konfigurerbar så att våra administratörer kan ändra användarnamn och lösenord i efterhand. Även om det är det anropande systemet som autentiseras och auktoriseras för att komma åt tjänsterna, så loggar vissa av tjänsterna slutanvändarens namn för att få en fullgod spårbarhet. Kraven kring detta beskrivs närmare under respektive tjänst. För att skydda lösenord och övrig data så används alltid traditionell SSL-kryptering baserat på servercertifikat, det man brukar kalla https. WSDL Landstingets tjänster bygger på SOAP version 1.1 och en beskrivning i WSDL-format finns som bilaga till detta dokument, men kan också laddas ner från följande adresser: https://servicestest/population/2010-12/ eller https://servicestest.vll.se/population/2010-12/ Test För testkörning under utvecklingsfasen och för acceptanstest hos beställaren har vi särskilda versioner av tjänsterna. Dessa finns på en server som heter servicestest och den adress som finns i WSDL-filen går mot denna. För att komma åt testservern så behöver den part som utvecklar kopplingen antingen sitta inom landstingets interna nätverk, eller installera en VPNklient på sin dator. Beställning av en sådan VPNklient görs av systemägaren på landstinget. Produktion När det är dags för produktion så ska tjänsteanropen gå mot en server som heter services. Tjänsternas adress ändras då till: https://services/population/2010-12/ eller https://services.vll.se/population/2010-12/ Personnummerbyten System som arbetar med persondata kan behöva hantera personnummerbyten. En person kan få ett nytt personnummer av flera olika anledningar. Nationellt kan Skatteverket tilldela en person ett nytt nummer till exempel när ett sekretesskydd ska träda i kraft, eller när ett födelsedatum ska korrigeras. En person kan tillfälligt ha ett reservnummer som tilldelats lokalt av Västerbottens läns landsting som sedan knyts till ett nationellt personnummer när detta blir känt. Det kan till exempel gälla nyfödda eller akutfall där man inte med en gång kan bestämma identiteten. Ett system som behöver hantera personnummerbyten och som bygger på våra tjänster kan känna igen detta via elementet Deregistration i Person-posten. Om Reason är GN är Sida 24
personnumret avregistrerat och utbytt mot det som står i ReferenceId. Systemet kan då göra en till sökning på det nya personnumret. Detta kan behöva upprepas i fler än ett steg. Adresser För att bestämma aktuell adress utifrån de uppgifter som returneras i en Person-post, så gör man det normalt så här: Om personen är utvandrad, dvs Deregistration är inte nil och Deregistration.Reason = UV, ta adressen från ForeignAddress. Är ForeignAddress nil finns ingen adress som kan anses vara aktuell. Om personen inte är utvandrad, ta första adressen som inte är nil från 1) MailingAddress, 2) RegistrationAddress, eller 3) ForeignAddress. Till exempel kan personer med reservnummer ha status som ej utvandrad, men samtidigt bara ha en utlandsadress. Skyddade adresser Personer med skyddad adress markeras med Confidencial = J och får en RegistrationAddress som går till Skatteverket som handhar att vidarebefordra post till personen. County, Municipality och Parish är också knutna till Skatteverkets kontor, inte till personens verkliga bostadsort. Tjänster Nedan beskrivs de tjänster som finns mot befolkningsregistret. Allmänt kan sägas att argument som skickas in tolkas på ett förlåtande sätt. Nil och tom sträng hanteras ekvivalent och ingen skillnad görs mellan stora och små bokstäver. Svarstiderna som anges beskriver ett 99-procentigt konfidensintervall, men är bara tänkt att ge en uppfattning om vad man kan förvänta sig i normalfallet. Vid hög last eller uppstartsfaser kan det mycket väl ta längre tid att få svar. GetPerson Hämta personuppgifter för en eller flera fullständiga personnummer. Parametrar personids En lista av fullständiga personnummer. Som mest kan 1 000 personnummer anges. För giltiga format, se avsnitt Dataformat. applicationuser Identitet på den användare som gör sökningen. Ange nil eller tom sträng om sökningen inte är en del av en användarsession. Resultat Tjänsten returnerar en lista med en Person-post för varje personnummer i parametern personids. Första posten innehåller personuppgifterna för första personnumret, osv. Personnummer som inte finns i befolkningsregistret ger tillbaka en nil-post. Om något eller några personnummer i personids är felaktigt formatterade så orsakar detta inte ett vanligt SOAP-fel, utan förfrågan går vidare för de personnummer som är rätt formatterade. De som var felaktigt formatterade ger tillbaka en Person-post där FaultCode har värdet Format. Svarstid (millisekunder): 50 + 45N, där N = antal nummer i personids. De SOAP-fel som kan inträffa är: FaultCode Detail-typ Beskrivning Argument ArgumentFault Parametern personids har för många element. Server ServerFault Ett fel har orsakats av tjänsten eller bakomliggande system. Sida 25
Funktion GetPerson används när man har en eller flera identifierade personer och vill hämta de senaste uppgifterna om dessa. Till skillnad mot FindPerson så kan GetPerson också returnera information om relaterade personer i elementet Relations. För att entydigt kunna identifiera varje person måste personnumren vara fullständiga, men eftersom det förekommer att system inte arbetar med 12 teckens personnummer så är tolkningen förlåtande. 11 och 10 teckens personnummer, med eller utan bindestreck, accepteras också. För personnummer med 10 tecken kommer tjänsten att bestämma sekelsiffrorna genom att söka i befolkningsregistret efter senast giltiga personnumret. Om befolkningsregistret innehåller både 19080101-0101 (avliden) och 20080101-0101, så tolkas 080101-0101 som det senare. I resultatpostens PersonId-element kan det fullständiga personnumret med 12 tecken avläsas. Sökningen sker både bland aktuella och inaktuella personnummer. För inaktuella personnummer kommer Deregistration att ange en avregistreringsorsak och ett datum för avregistreringen, om det är känt. Speciell hantering kan behövas för avregistreringsorsak GN, se avsnitt Personnummerbyten. Reservnummer som registrerats lokalt hos Västerbottens läns landsting kan också sökas fram med GetPerson och hanteras på samma sätt som sökning på vanliga personnummer. Sekretesskyddade personer kan sökas fram med GetPerson, men kommer alltid att returneras med en RegistrationAddress som går till Skatteverket. Likaså County, Municipality och Parish är inte personens verkliga bostadsort. För att se om en person är sekretesskyddad testar man om Confidencial är skilt från nil och innehåller värdet J. För personer som aldrig bott i vår region, eller personer som har bott inom vår region och flyttat ut, kan uppgifterna man får tillbaka vara några dagar gamla. Sådana personer genererar en nationell sökning hos Skatteverket som sedan sparas några dagar i vårt lokala befolkningsregister. Personer som flyttat ut ur vår region de senaste åren kommer att ha datum för detta angivet i LeftRegion. Sökningar med GetPerson loggas och för att få spårbarhet i detta så ska namnet på den användare som gör sökningen anges i parametern applicationuser. Detta ska vara användarens identitet i det anropande systemet. Om sökningen görs i samband med ett bakgrundsjobb eller av annan anledning inte kan sägas vara initierad av en användare, så lämnas denna parameter tom eller sätts till nil. FindPerson Sök efter personer som matchar givna personuppgifter. Parametrar personid Personnummer, fullständigt eller ofullständigt. firstname Förnamn separerade med blanksteg. middlename Mellannamn, dvs ett andra efternamn. lastname Efternamn. address Utdelningsadress. postalcode Postnummer, 1-5 siffror. city Postort. birthdate Födelsedatum. Del av YYYYMMDD eller YYYY-MM-DD ner till Y-M-D. gender Sida 26
Kön, F = kvinna, M = man, U = obestämt. excludenationalids Sätts till true om man bara vill söka på reservnummer, nil eller förvalt värde är false. maxcount Högsta antalet träffar som önskas, eller nil för tjänstens förvalda värde. Anges ett värde ska det vara inom intervallet [0, 1 000]. applicationuser Identitet på den användare som gör sökningen. Ange nil eller tom sträng om sökningen inte är en del av en användarsession. Resultat Tjänsten returnerar en lista med Person-poster som matchar personpattern. Om ingen i befolkningsregistret matchar personpattern så returneras en lista med noll poster. Svarstid (millisekunder): 100 + 1,5N, där N = antal svarsposter. De SOAP-fel som kan inträffa är: FaultCode Detail-typ Beskrivning Argument ArgumentFault Parametern maxcount är utanför giltigt intervall. Format FormatFault Ett element i personpattern har ogiltigt format. Server ServerFault Ett fel har orsakats av tjänsten eller bakomliggande system. Funktion FindPerson används när man har en persons namn eller andra uppgifter och vill hitta den exakta identiteten. Tjänsten är byggd utifrån scenariot där sökresultatet presenteras som valalternativ för en användare. Därför är matchningen inte exakt. För namn, adress och postort görs en fonetisk sökning där liknande bokstäver matchar varandra och diakritiska tecken ignoreras. För alla termer gäller att matchning bara görs mot inledningen av varje ord, så att till exempel sökning på Ann ger träff på Anna och sökning på postnummer 907 ger träff på 90730. Om personnummer anges så kan århundrade och ett eller flera av de sista fyra tecknen utelämnas. Anger man endast ett fullständigt personnummer med 10, 11 eller 12 tecken, så kan en nationell sökning ske och man hittar då en person oavsett var i Sverige han eller hon är registrerad. Men anger man fler söktermer, eller ett ofullständigt personnummer, så sker sökningen bara i vår region. Personer som av någon anledning har avregistrerats, till exempel avlidna och utvandrade, är exkluderade från sökresultatet. Sökningen görs bara bland de senaste uppgifterna i befolkningsregistret. Man får alltså inte träff på gamla gatuadressen om en person har flyttat, eller på det gamla namnet om namnet har bytts. En annan begränsning är att sökning bara sker bland personer registrerade i norra regionen, dvs Västerbottens län, Västernorrlands län, Jämtlands län och Norrbottens län. Fältet Relations i Person-posten fylls inte i av FindPerson. Behöver man dessa uppgifter kan man göra ett kompletterande anrop till GetPerson. Reservnummer som registrerats lokalt hos Västerbottens läns landsting kan sökas fram med FindPerson, med den skillnaden att mellannamn inte finns i reservnummerdatabasen. Söker man på mellannamn får man därför ingen träff på reservnummer. Sekretesskyddade personer kan sökas fram med FindPerson, förutsatt att man angett ett fullständigt personnummer med 10, 11 eller 12 tecken. Dessa kommer alltid att returneras med en RegistrationAddress som går till Skatteverket. Likaså County, Municipality och Parish är inte personens verkliga bostadsort. För att se om en person är sekretesskyddad testar man om Confidencial är skilt från nil och innehåller värdet J. Sökningar med FindPerson loggas och för att få spårbarhet i detta så ska namnet på den användare som gör sökningen anges i parametern applicationuser. Detta ska vara användarens identitet i det anropande systemet. Om sökningen görs i samband med ett bakgrundsjobb eller av annan anledning inte kan sägas vara initierad av en användare, så lämnas denna parameter tom eller sätts till nil. Sida 27
GetCountries Hämta fullständig förteckning över landskoder och landsnamn. Parametrar Inga. Resultat Tjänsten returnerar en lista med Country-poster sorterad efter landsnamn. Svarstid (millisekunder): 100. De SOAP-fel som kan inträffa är: FaultCode Detail-typ Beskrivning Server ServerFault Ett fel har orsakats av tjänsten eller bakomliggande system. Funktion Förteckningen över landskoder och landsnamn bygger på kodstandarden i ISO 3166 med svensk namnsättning. Koderna kan användas till att översätta Citizenship i Person-poster till ett landsnamn, eller till att översätta landsnamnet i BirthCountry till en landskod. GetRegionalDevisions Hämta fullständig förteckning över Sveriges geografiska indelning. Parametrar Inga. Resultat Tjänsten returnerar en trädstruktur med County-, Municipality- och Parish-poster sorterade efter länsnamn, kommunnamn respektive församlingsnamn. Svarstid (millisekunder): 150. De SOAP-fel som kan inträffa är: FaultCode Detail-typ Beskrivning Server ServerFault Ett fel har orsakats av tjänsten eller bakomliggande system. Funktion Förteckningen över Sveriges geografiska indelning bygger på de tvåsiffriga koder som bestämts av SCB och Svenska kyrkan. I folkbokföringen används koderna för att registrera var personer bor och återfinns i Person-postens element County, Municipality och Parish. GetCareChoice Hämta hälsoval i Västerbotten för en eller flera fullständiga personnummer. Parametrar personids En lista av fullständiga personnummer. Som mest kan 1 000 personnummer anges. För giltiga format, se avsnitt Dataformat. applicationuser Identitet på den användare som gör sökningen. Ange nil eller tom sträng om sökningen inte är en del av en användarsession. Sida 28
Resultat Tjänsten returnerar en lista med en CareChoice-post för varje personnummer i parametern personids. Första posten innehåller hälsoval för första personnumret, osv. Personnummer som aldrig varit registrerade med ett hälsoval ger en nil-post tillbaka. Om något eller några personnummer i personids är felaktigt formatterade så orsakar detta inte ett vanligt SOAP-fel, utan förfrågan går vidare för de personnummer som är rätt formatterade. De som var felaktigt formatterade ger tillbaka en CareChoicepost där FaultCode har värdet Format. Svarstid (millisekunder): 20 + 8N, där N = antal nummer i personids. De SOAP-fel som kan inträffa är: FaultCode Detail-typ Beskrivning Argument ArgumentFault Parametern personids har för många element. Server ServerFault Ett fel har orsakats av tjänsten eller bakomliggande system. Funktion För att entydigt kunna identifiera varje person måste personnumren vara fullständiga, men eftersom det förekommer att system inte arbetar med 12 teckens personnummer så är tolkningen förlåtande. 11 och 10 teckens personnummer, med eller utan bindestreck, accepteras också. För personnummer med 10 tecken kommer tjänsten att bestämma sekelsiffrorna genom att söka efter senast giltiga personnumret. Om hälsoval finns registrerade för både 19080101-0101 (avliden) och 20080101-0101, så tolkas 080101-0101 som det senare. I resultatpostens PersonId-element kan det fullständiga personnumret med 12 tecken avläsas. Sekretesskyddade och reservnummer har aldrig något hälsoval registrerat och ger därför en nilpost tillbaka. PrimaryCareChoices innehåller historiken över personens hälsoval, senaste först och äldsta sist. From och To anger giltighetsintervallet för varje hälsoval. Observera att To är exklusiv, dvs dagen efter giltigheten upphört. Om ett aktivt hälsoval finns så har första posten i PrimaryCareChoices en To som är nil. I annat fall betyder det att personen haft ett hälsoval i Västerbotten, men har flyttat ut ur länet eller avregistrerats ur befolkningsregistret. Sökningar med GetCareChoice loggas och för att få spårbarhet i detta så ska namnet på den användare som gör sökningen anges i parametern applicationuser. Detta ska vara användarens identitet i det anropande systemet. Om sökningen görs i samband med ett bakgrundsjobb eller av annan anledning inte kan sägas vara initierad av en användare, så lämnas denna parameter tom eller sätts till nil. Dataformat Många element i de typer som tjänsterna arbetar med är kopierade från en motsvarande term hos Skatteverket. När så är fallet anges det i kolumnen Termkod, som är den beteckning som termen har i Skatteverkets system för distribution av folkbokföringsuppgifter Navet. I de formatbeskrivningar som ges används följande beteckningar: N en siffra. X en siffra eller en bokstav. Y del av ett årtal. M del av en månad, 01-12. D del av en dag, 01-31. Sida 29
Personnummer När personnummer skickas som resultat från tjänsterna har de konsekvent 12 tecken och inget bindestreck. För personnummer som skickas som argument till tjänsterna görs först ett försök att tolka det som ett fullständigt personnummer med 10, 11 eller 12 teckens längd, med eller utan bindestreck. Formatet på dessa är: 10 tecken: YYNNNN-XNNN eller YYNNNNXNNN 11 tecken: YYYNNNN-XNNN eller YYYNNNNXNNN 12 tecken: YYYYNNNN-XNNN eller YYYYNNNNXNNN Om personnumret inte kan läsas som ett fullständigt personnummer, tolkas det som ett ofullständigt personnummer. Detta ska bestå av de första sex till åtta siffrorna, men en eller flera av de sista fyra tecknen kan vara utelämnade. Tjänsterna lägger ytterligare begränsningar på kombinationer av N och X som kan resultera i ett FormatFault, men detta lämnas ospecificerat för att kunna stödja framtida person- och reservnummerformat. Nil Alla element kan vara nil och ska tolkas som att uppgiften är okänd eller inte meningsfull i sammanhanget. Person Element Typ Innehåll och format Termkod PersonId String Personnummer som posten gäller. YYYYNNNNXNNN 01001 Confidencial String Sekretessmarkering. J = sekretessmarkerad, nil/saknas = ej sekretessmarkerad 01003 ReferenceId String Gammalt eller nytt personnummer. YYYYNNNNXNNN 01005 Deregistration Deregistration Uppgifter om avregistrering. FirstName String Förnamn separerade med blanksteg. 1-80 tecken 01012 MiddleName String Mellannamn separerade med blanksteg. 1-40 tecken 01013 LastName String Efternamn separerade med blanksteg. 1-60 tecken 01014 County String Län där personen är folkbokförd. 2 siffror 01022 Municipality String Kommun där personen är folkbokförd. 2 siffror 01023 Parish String Församling där personen är folkbokförd. 2 siffror 01024 Property String Fastighetsbeteckning. Sida 30
1-40 tecken 01025 RegistrationAddress SwedishAddress Uppgifter om bostadsadress. MailingAddress SwedishAddress Uppgifter om särskild postadress. ForeignAddress ForeignAddress Uppgifter om adress i utlandet. BirthCountry String Födelseland i klartext. 1-40 tecken 01094 Relations ArrayOfRelation Relaterade personer. Citizenship String Land där personen är medborgare. 2 tecken 03001 GivenName String Tilltalsnamn i klartext. 1-80 tecken BirthDate String Födelsedatum. YYYYMMDD, nollor för okända delar Gender String Kön. F = kvinna, M = man, U = obestämt NYKOCode String Statistikområde enligt SCBs NYKO-register. 6 siffror LeftRegion String Datum för flytt ut ur vår region. YYYYMMDD, nollor för okända delar LMAId String LMA-nummer för flykting. NN-NNNNNN FaultCode String Felkod. Se avsnitt GetPerson Deregistration Element Typ Innehåll och format Termkod Reason String Orsak för avregistreringen. AV = avliden, UV = utvandrad, GN = gammalt personnummer, AN = annan anledning, GS = gammalt samordningsnummer, TA = tekniskt avregistrerad, OB = obefintlig 01006 02010 Date String Datum för avregistrering. YYYYMMDD, nollor för okända delar 01003 02011 SwedishAddress Element Typ Innehåll och format Termkod CareOf String Care of-adress. 1-35 tecken 01031 01051 Address1 String Utdelningsadress, rad 1. 1-35 tecken 01032 01052 Sida 31
Address2 String Utdelningsadress, rad 2. 1-35 tecken 01033 01053 PostalCode String Postnummer. 5 siffror 01034 01054 City String Postort. 1-27 tecken 01035 01055 VLL 951-2013 ForeignAddress Element Typ Innehåll och format Termkod Address1 String Utdelningsadress, rad 1. 1-35 tecken 01071 Address2 String Utdelningsadress, rad 2. 1-35 tecken 01072 Address3 String Utdelningsadress, rad 3. 1-35 tecken 01073 Country String Landsnamn i klartext. 1-35 tecken 01077 Date String Datum för utlandsadress. YYYYMMDD, nollor för okända delar 01078 Relation Element Typ Innehåll och format Termkod PersonId String Personnummer för relationspersonen. YYYYNNNNXNNN 02001 BirthTimeId String Födelsetid för ej folkbokförd relationsperson. YYYYMMDDNNNN 02002 RelationType String B = barn, MO = moder, FA = fader, F = förälder, V = vårdnadshavare, VF = vårdnadshavare för, M = make/maka, P = partner 02003 FromDate String Startdatum för relationen. YYYYMMDD, nollor för okända delar 02004 FirstName String Förnamn, ej folkbokförd relationsperson. 1-80 tecken 02005 MiddleName String Mellannamn, ej folkbokförd relationsperson. 1-40 tecken 02006 Sida 32
LastName String Efternamn, ej folkbokförd relationsperson. 1-80 tecken 02007 Deregistration Deregistration Uppgifter om avregistrering. Country Element Typ Innehåll och format Code String Landskod enligt ISO 3166. 2 tecken Name String Svenskt namn. 1-32 tecken County Element Typ Innehåll och format Code String Länskod. 2 siffror Name String Namn. 1-32 tecken Municipalities ArrayOf- Municipality Uppgifter om kommuner i detta län. Municipality Element Typ Innehåll och format Code String Kommunkod. 2 siffror Name String Namn. 1-32 tecken Parishes ArrayOf- Parish Uppgifter om församlingar i denna kommun. Parish Element Typ Innehåll och format Code String Församlingskod. 2 siffror Name String Namn. 1-32 tecken CareChoice Element Typ Innehåll och format PersonId String Personnummer som posten gäller. YYYYNNNNXNNN PrimaryCareChoices ArrayOfPrimary- CareChoice Historik över hälsoval i primärvården. Senaste valet först. FaultCode String Felkod. Se avsnitt GetCareChoice PrimaryCareChoice Element Typ Innehåll och format Status Integer Hur hälsovalet kom till. 1 = geografisk tilldelning, 2 = eget val From DateTime Startdatum (inkl). To Sida 33