I detta dokument specificeras hur ett journalsystem kan göra en integration med Webcert. 

Revisionshistorik

Referenser

Inledning

I planeringen för att börja använda Webcert för intygshantering ingår att bestämma vilket behov av integration mot Webcert som finns. Webcert kan användas som en fristående applikation eller integreras med ett journalsystem. De olika varianterna ger olika fördelning av funktionalitet mellan journalsystemet och Webcert. Detta dokument fokuserar huvudsakligen på hur Webcert integreras med ett journalsystem. 

1 Arbetsflöden

Arbetsflöden som är generella för hela intygsdomänen oavsett intygsmottagare beskrivs i R1.

Arbetsflöden som är specifika för hanteringen av Försäkringskassans intyg beskrivs i R2.

2 Beskrivning av Webcert

För den som inte är bekant med Webcert följer här en beskrivning av dess funktionalitet och förutsättningar för användning. Beskrivningen gäller befintliga funktionalitet när applikationen körs som en fristående applikation och inkluderar således inte den nya funktionalitet som beskrivs i kravspecifikationen för utökat elektroniskt informationsutbyte samt den funktionalitet som beskrivs från kap 3 och framåt i detta dokument. Detta för att tydliggöra skillnaden mellan de två olika lösningarna.

Webcert är en webbapplikation som körs antingen som en fristående webbapplikation eller som ett inbäddat fönster i journalsystemet som det är integrerat med. Webcert används för att skriva intyg och hantera eventuell ärendekommunikation kring läkarintyg. Med Webcert får man tillgång till alla typer av intyg som hanteras av Intygstjänsten, ifyllnadsstöd för intygsutfärdande och en samlad plats för kommunikationen angående intyg med berörda intygsmottagare.

2.1 Behörighet

I Webcert finns (något förenklat) två roller som styr vad användaren får göra. Dessa roller är:

• Läkare (inkl. tandläkare)

• Vårdadministratör

All hälso- och sjukvårdspersonal som innehar medarbetaruppdrag ”vård och behandling”, som inte är läkare, får rollen Vårdadministratör. Skillnaden i behörighet mellan dessa båda roller är att endast rollen Läkare har rätt att signera intyg. Det är också bara rollen Läkare som kan makulera intyg. En mer specifik beskrivning av rollerna i Webcert finns beskriven i Webcerts användarmanual som kan laddas ned på Ineras hemsida.

Behörighet är alltid knuten till en specifik vårdenhet. En användare kan ha behörighet till flera olika vårdenheter, men kan bara var inloggad i Webcert på en vårdenhet åt gången.

2.2 Inloggning

Inloggning till Webcert sker med hjälp av SITHS, antingen direkt i Webcert eller via journalsystemet ifall användaren kommer via det. Inloggningen med SITHS görs via Ineras säkerhetstjänster. Det finns numera också möjlighet för privatläkare (läkare utan medarbetaruppdrag i något landsting) att utfärda intyg via Webcert och inloggning sker då via E-legitimation.

Open

Figur 1. Vy innan inloggning 

2.3 Funktioner 

Efter inloggning kan användaren välja att:

• Söka efter existerande intyg för en specifik patient.

• Skriva ett nytt intyg för en specifik patient.

• Få en överblick över sin ärendekommunikation med Försäkringskassan.

• Få en lista över sina osignerade intyg.

• Få mer information om Webcert.

Open

Figur 2. Vy som användaren kommer till efter inloggning

2.4 Användning av Webcert idag

Idag används Webcert i olika utsträckning i ett flertal landsting och regioner. Norrbottens läns landsting och Region Halland har utvecklat en integration mellan journalsystemet VAS och Webcert som breddinfördes våren 2015. De landsting som använder journalsystemet Cosmic gjorde initialt en enklare integration med Webcert för att hantera ärendekommunikationen kring ett befintligt intyg. Detta gjordes via ett uthopp från Cosmic till Webcert. Under 2017 och 2018 har Cosmic-landstingen utvecklat en liknande integrationslösning som Norrbotten och Halland för att använda Webcert i sin helhet, det vill säga även skriva intyg i Webcert. Ytterligare landsting kommer under 2018 att göra en integration med Webcert och vid årsskiftet 2018-2019 kommer minst 18 av 21 landsting att ha integrerat med Webcert.

3 Integrationslösningar för nya anslutningar

För nya anslutningar till Webcert kommer tjänsten att kunna köras antingen fristående eller som en integrerad applikation. Följande kapitel beskriver vad alternativen innebär.

3.1 Webcert som en fristående applikation

Användning av Webcert som en fristående applikation innebär att all intygshantering sker i Webcert. Ingen informationsöverföring görs från Webcert till journalsystemet. Webcert kan startas genom att användaren anger adressen till Webcert i sin webbläsare, men rekommenderad lösning är att implementera en uthoppslänk i journalsystemet och skapa Single Sign-On via SAML så att användaren inte behöver autentisera sig i Webcert. Används Webcert som fristående applikation meddelas vårdenheter per mail att ärendekommunikation inkommit från Försäkringskassan. Det är den e-postadress som vårdenheten har registrerat i HSA som Webcert skickat mail till.

3.2 Integrerad applikation

Användning av Webcert som integrerad applikation innebär att journalsystemet står för delar av den intygsrelaterade funktionaliteten. Journalsystemet visar översikter över en patients intyg och relaterad ärendekommunikation, medan visning och redigering av enskilda intyg, samt hantering av ärendekommunikation, görs i Webcert. Webcerts användargränssnitt anpassas så att de funktioner som inte är relevanta när applikationen körs som en integrerad applikation döljs. Det gäller till exempel att välja patient, visa översikter och byta vårdenhet, som är funktioner som utförs i journalsystemet. Anpassningen av användargränssnittet sker när uthoppet till Webcert görs till en speciell adress. Samma användare som kan nå Webcert via en integration i sitt journalsystem kan använda Webcert som en fristående applikation. Detta innebär att användaren kan använda Webcert även i en situation då åtkomst till journalsystemet saknas. I lösningen ingår att alla ändringar i Webcert återkopplas till journalsystemet, oavsett om användaren har använt Webcert via sitt journalsystem eller som en fristående applikation. Det journalsystem som har en integration med Webcert har således alltid aktuell information om en vårdenhets intyg. Ett antal av de journalsystem som integrerat med Webcert idag har lösningar som gör att återkopplingen till journalsystemet inte fungerar. Det beror på att de kräver viss information vid återkopplingen som inte finns tillgänglig i den fristående versionen av Webcert.

4 Teknisk lösning för integrerad applikation

Detta kapitel beskriver den tekniska lösningen för integrerad intygsapplikation.

Figur 3. Systemlandskapet för ett integrerat journalsystem.

Bilden ovan visar systemlandskapet där ett integrerat journalsystem kommunicerar med Intygstjänster och där intygsmottagare tar emot intyg och makuleringsmeddelande. Pilarna visar i vilken riktning anrop görs. Mellan Intygstjänsten och RegisterCertificate samt RevokeCertificate finns dubbelriktade pilar som illustrerar att det finns anrop i bägge riktningarna, men det avser olika anrop. Svar på anrop visas inte i bilden.

4.1 Uppdatering av information i journalsystem

De översikter som visas i journalsystemet måste innehålla aktuella uppgifter. Webcert synkroniserar journalsystemet med en tjänst som implementeras i journalsystemet (CertificateStatusUpdateForCare). Där skickas uppdateringar från Webcert till journalsystemet i samband med att en relevant händelse inträffar i Webcert. Observera att det finns specifika fältregler att följa vid användning av tjänstekontraktet CertificateStatusUpdateForCare, för mer information se kapitel 5.

Lösningen innebär att aktuell intygsinformation alltid finns tillgänglig i journalsystemet. Uppdateringarna skickas då en händelse inträffar. Genom att journalsystemet hela tiden har den senaste informationen om ett intyg ger det en stor flexibilitet då det är fritt att definiera önskade vyer över informationen i journalsystemet. Webcert har en autospar-funktion som sparar intyg per automatik med ett givet tidsintervall (ett fåtal sekunder). Det innebär att ett intyg där ett flertal fält uppdateras kommer att sparas flera gånger men det är inte önskvärt att ett journalsystem blir överöst med uppdateringar om att ett intygsutkast redigerats. Antalet statusuppdateringar som skickas till journalsystemet för denna händelse (”intygsutkast ändrat”) kommer att hållas nere genom att Webcert skickar maximalt en statusuppdatering var femte minut som intygsutkastet redigerats. Denna tidsenhet kan vid behov komma att göras konfigurerbar.

Svarsvärden som inte uppfyller ett intygs innehållsvalidering ska inte överföras till integrerande journalsystem. Webcert har därför en filtrering som gör att värden som ska vara på ett givet format (t.ex. datum, diagnoser och perioder) bara skickas med i statusmeddelanden om de är korrekt ifyllda (gäller från WC-6.4.0).

4.1.1 Det är inte givet att händelser når journalsystemet i den ordning de skapades

Störst risk för att detta inträffar uppstår när ett journalsystem under en period är otillgängligt och Webcert använder sin omsändningsfunktionalitet. Denna skickar om meddelanden med stigande tidsintervall, vilket innebär att händelser inte ens behöver uppstå särskilt nära varandra i tid för att nå journalsystemet i omvänd ordning. Ett annat exempel när detta kan inträffa är när ett intyg markeras klar för signering av en sekreterare. Då kan händelsen ”intygsutkast klart för signering” komma före ”intygsutkast ändrat”, då Webcert sparat en sådan händelse. Information om händelsens faktiska tidpunkt ingår i meddelandet. Det finns fler exempel som kan ges men det vore inte rätt att försöka ta fram en lista på möjliga fall här eftersom det då lätt leder till tron att listan är komplett och konstant över tiden. 

Notera att intygen vid hantering i dessa tjänstekontrakt ej behöver vara kompletta. De kommer alltid att innehålla den information som krävs för validering enligt XML-schemat, men ett intygsutkast behöver inte innehålla svar på alla obligatoriska frågor och kan därmed inte valideras ytterligare med samma schematron-filer som används för att validera signerade intyg.

Här nedan är ett flödesdiagram som tydliggör hur de olika händelserna relaterar till varandra och när de uppkommer. Observera att händelsen LAST inte är implementerad i skrivande stund, däremot går ett låst intygsutkast fortfarande att makulera.

Figur 4. Flödesdiagram över hur händelser relaterar till varandra.

Vid större avbrott, eller problem med både skickande och mottagande köer kan på grund av infrastrukturproblem statusmeddelanden tappas bort. Då finns tjänsten ListCertifcateForCareWithQA. Det är en tjänst där journalsystemet anropar Webcert, med enhet, patient och tidsintervall. I retur fås intyg och händelser skapade på den enheten och personen under det tidsintervallet och journalsystemet kan synkronisera sig med Webcert. Observera att detta endast ska användas vid större katastrofer och i samråd med Ineras förvaltning då det medför stora mängder slagningar mot Webcert under en viss tid.

4.1.2 Konfiguration för statusuppdateringar

Den enhet som ska ta emot statusuppdateringar (via CertificateStatusUpdateForCare) registreras i en tabell i Webcert. Det sker automatiskt första gången det skapas ett intygsutkast på den enheten. Statusuppdateringar kommer sedan att skickas för samtliga intyg som skapas på enheten, även om användaren, när ett intyg skapas kör Webcert som en fristående applikation. 

4.2 Skapa intyg

Intyg skapas från journalsystemet, där valet av typ av intyg görs. Detta innebär att man i journalsystemet kan avgränsa vilka typer av intyg som kan skapas. (Notera att detta endast gäller när användaren når Webcert från sitt journalsystem och inte då hen går in i Webcert annan väg. När Webcert startas som en fristående applikation kommer det vara möjligt att skapa alla de intyg som Webcert totalt sett hanterar.) Man behöver också en rutin för att hantera tillägg av nya intygstyper när dessa införs. En del i detta blir att hantera den beskrivande text som tas fram för varje intygstyp, och som bör kunna visas i journalsystemet för att hjälpa användaren att använda intygen på rätt sätt.

När ett nytt intyg skapas överförs uppgifter från journalsystemet som sedan inte kan ändras i Webcert. Uppgifterna överförs vi tjänstekontraktet CreateDraftCertificate, för en fullständig lista med uppgifter som ingår i anropet för CreateDraftCertificate se Tjänstekontraktsbeskrivningen [R1]. Samma uppgifter överförs oavsett vilken typ av intyg som skapas. Observera att det finns specifika fältregler att följa vid användning av tjänstekontraktet CreateDraftCertificate, för mer information se kapitel 5.

Det förekommer att en intygstyp har många frågor som är gemensamma med en annan intygstyp. För att underlätta för användare att fylla i sådana intygstyper har Webcert en funktion som vid det första överhoppet till ett nytt intygsutkast kan kopiera över svar från ett tidigare signerat intyg av annan intygstyp. För integrerade användare fungerar funktionen på följande sätt:

1. Användaren skapar intygsutkastet från sitt journalsystem

2. När användaren sedan gör det första överhoppet till intygsutkastet gör Webcert automatiskt en sökning efter tidigare signerade intyg att kopiera ifrån

3. Om sökningen ger resultat får användaren ta ställning till om information från det hittade intyget ska användas i det nya intyget eller inte

4. Om användaren väljer att kopiera förifylls det nya intygsutkastet med de informationsmängder som intygen delar

Funktionen förifyllnad finns också för vissa intyg som en knapp i signerat-vyn på de intyg som information kan hämtas ifrån. Det sättet att initiera kopiering passar dock inte för alla intygstyper i integrerat läge och används därmed för vissa intygstyper bara i fristående läge. 

För information om vilka intygstyper som omfattas av denna funktionalitet se kolumnen "förifyllnad" i Intygslista.

4.2.1 Implementation

Nya intyg skapas via tjänstekontraktet CreateDraftCertificate. De uppgifter som specificerats i tjänstekontraktet skickas som parametrar, och i retur får man ett intygs-id som sedan används för att öppna intyget i Webcerts användargränssnitt via ett överhopp. Användaren kan därefter redigera intyget i Webcert. Flödet synliggörs i nedanstående sekvensdiagram.

Figur 5. Sekvensdiagram vid skapande av intyg

Överhoppet för att öppna det nya intygsutkastet använder samma länk som för att visa ett befintligt intygsutkast eller ett signerat intyg. Logiken för detta beskrivs närmare i nästa kapitel.

4.2.2 TAK-kontroll

När ett intyg skapas görs en kontroll av den enhet som intyget skapades på. Detta för att undvika att utkast skapas som antingen inte Webcert kan rapportera tillbaka statusuppdateringar på eller mottagaren kan ställa frågor på. Kontroll görs av alla de nödvändiga routingreglerna ("TAKningar") för enheten som CreateDraftCertificate-anropet kom in på. Kontrollen sker i två steg:

1. Kontroll av TAKning sker i första steget för samtliga intygstyper genom att kontrollera att CertificateStatusUpdateForCare med rätt version är TAKad. Som parameter till CreateDraftCertificate får man in enhetens HSA-id som används för att kontrollera TAKning. Enheten kan vara en vårdenhet alternativt en underliggande mottagning (underenhet). Eftersom Intygstjänsten inte vet hur man valt att TAKa kontrolleras först enheten som skickas in, om ingen träff fås så kontrolleras även eventuell överliggande enhet och slutligen vårdgivaren (så kallad trädklättring). Om ingen träff fås på någon nivå svarar CreateDraftCertificate med application error samt textsträng innehållandes feltext, enligt tjänstekontraktets standard för felrapportering.

2. I andra steget verifieras TAKning av ärendekommunikationen. Endast Försäkringskassans intyg har ärendekommunikation. För dessa intyg kontrolleras SendMessageToCare. 

Om TAK-API:t är nere eller inte svarar tillräckligt snabbt för att kontroll ska kunna genomföras inom konfigurerad tid, loggas detta som en varning och intyget tillåts att skapas utan TAK-kontroll. 

4.3 Visa intyg i Webcert via överhopp från journalsystem

För att visa ett intyg (oavsett om det är ett intygsutkast som precis skapats enligt flödet i föregående kapitel, eller ett redan existerande intyg) används följande:

<intygs-typ> sätts i payloaden vid anropet till CreateDraftCertificate och det är det värdet som ska användas i adressen ovan.

• För CreateDraftCertificate version 3 används <intygs-typ> i intyg.typAvIntyg.code

Notera att från och med Webcert 6.1 som släpps i november 2018 kommer URL:en för POST-anropet att ändras så att <intygs-typ> inte längre ingår. Båda POST-anropen kommer att finnas under en övergångsperiod.

<intygs-id> fås i svaret från anropet till CreateDraftCertificate. 

• I svaret för CreateDraftCertificate version 3 hämtas <intygs-id> från intyg-id.extension

Ett <intygs-id> består av två delar, root och extension, som man får som svar från anrop till CreateDraftCertificate. I överhoppen ska dock endast extension-delen anges i <intygs-id>. Detta eftersom Webcert alltid i detta element använder en Globally Unique Identifier (GUID), vilket gör root-delen redundant. Root-delen är den utfärdande enhetens HSA-ID från och med version 2.0 av tjänstekontraktet.

Webcert tillåter att signerade intyg visas så länge användaren har ett medarbetaruppdrag på en vårdenhet inom den vårdgivare där intyget har utfärdats. För att visa och redigera ett intygsutkast krävs däremot ett medarbetaruppdrag på den specifika enheten där intygsutkastet skapades.

Förutom ovanstående skickas ett antal parametrar som en query string. Dess innehåll beskrivs närmare i följande delkapitel.

Ett överhopp till Webcert innebär att en sessionskaka startas och ett fönster öppnas. Det är endast tillåtet att ha en sessionskaka per överhopp och patient igång, vilket innebär att Webcert hindrar öppnande av flera webbfönster från samma sessionskaka

4.3.1 Patientuppgifter

Följande parametrar används för att skicka journalsystemets aktuella patientuppgifter:

Webcert validerar endast att postnumret är i rätt format. För de andra parametrarna görs ingen validering och de kommer således att visas upp i det format det mottogs i. 

Webcert hämtar person- och adressuppgifter, i regel, från Personuppgiftstjänsten (vidare benämnd PU-tjänsten). Notera att för de flesta intygstyper så kommer inte patientens adress att vara synlig, eller sparas till intyget.

Om patientens namn- och/eller adressuppgifter skiljer sig från det som angivits i intyget så kommer användaren att uppmärksammas om detta i vyn över det signerade intyget. För det fallet att ett intyg skapas utifrån ett annat, till exempel om ett intyg ersätts så kommer de aktuella uppgifterna att användas i det nya intyget, istället för de som finns på ursprungsintyget.

När ett tidigare skapat intygsutkast återöppnas med förändrade adressuppgifter kommer dessa uppgifter att uppdateras i intygsutkastet. Användaren kommer inte att upplysas om att adressuppgifterna har ändrats i Webcert om uppgifterna tagits från journalsystemet, eftersom de är desamma. Har däremot namnuppgifterna uppdaterats i PU-tjänsten sedan utkastet senast öppnades, alternativt skapades, så kommer det liksom vid öppnandet av ett signerat intyg att framgå i gränssnittet att en förändring har skett.

Om patientens personnummer skiljer sig, både vid öppnande av signerat intyg, och intygsutkast, kommer Webcert att använda personnumret i den medskickade parametern och visa användaren i gränssnitten att patienten har ett nytt personnummer.

Om den frivilliga parametern avliden finns med och har värdet true medför det att Webcert tolkar det som att patienten har avlidit sedan intyget utfärdades och det går då inte att skapa några nya intyg utifrån det tidigare skapade intyget, till exempel genom att ersätta. Notera att uppgiften även tas från PU-tjänsten och att Webcert alltid kommer att tolka en inkommen flagg att patienten är avliden som gällande. Det vill säga avliden-markering i PU-tjänsten trumfar parameter avliden = false, och patienten kommer att behandlas som avliden i Webcert och vice versa.

4.3.2 Enhet

Webcert behöver informeras om vilken enhet användaren är inloggad på i journalsystemet (vilket inte behöver vara samma enhet som intyget är utfärdat på), det vill säga på vilken enhet som användaren arbetar på när intyget öppnas.

Parametern enhet ska innehålla enhetens HSA-id. Webcert validerar att användaren har medarbetaruppdrag med ändamål ”Vård och behandling” på enheten. Om den enhet som anges är en underliggande enhet till en vårdenhet i HSA validerar Webcert att användare har medarbetaruppdrag med ändamål ”Vård och behandling” på den överliggande vårdenheten. I denna integrationslösning förväntas journalsystemet ange enhet. Webcert tillåter dock att enhet utelämnas, och kommer då att låta användaren välja enhet när personen öppnar Webcert. Detta kan följaktligen resultera i att användaren är inloggad på olika enheter i journalsystemet och i Webcert.

Om parametern inaktivEnhet finns med och har värdet true medför det att enheten är inaktiv i journalsystemet men ännu inte arkiverad i HSA. Det ska inte längre gå att skriva intyg på den enheten och användaren kommer inte kunna förnya eller ersätta ett intyg i Webcert på den enheten.

4.3.3 Övriga uppgifter

Det är dessutom möjligt att skicka följande parametrar:

Parametern alternatePatientSSn anger patientens person-id och används när patienten har fått ett nytt personnummer (felaktigt personnummer har rättats, eller ett samordningsnummer har bytts ut mot ett personnummer). Webcert visar en gul informationsruta som informerar om att patienten har ett nytt personnummer. Om ett nytt intyg skapas utifrån ursprungsintyget (exempelvis om intyget ersätts) ska det nya intyget skrivas med det nya personnumret. Samma gäller om alternatePatientSSn skickas med vid återöppnande av ett intygsutkast. Om intyget är skrivet på ett samordningsnummer och alternatePatientSSn identifieras som ett reservnummer (vilket görs genom att validera att identiteten varken är ett personnummer eller ett samordningsnummer) informerar Webcert användaren om detta. Värdet ska skickas i det format som ska visas för användaren, det vill säga inklusive bindestreck (och skiljer sig därmed från formatet som används för Person-id i tjänstekontrakt). Om ett nytt intyg skapas utifrån ursprungsintyget (exempelvis om intyget ersätts) ska det nya intyget skrivas på samordningsnumret, alltså inte på reservnumret. Samma gäller om alternatePatientSSn skickas med vid återöppnande av ett intygsutkast och identifieras som ett reservnummer. 

Parametern responsibleHospName anger namn på den HoS-person som är ansvarig för att signera intyget. Används när detta inte är samma person som skriver intygsutkastet. Informationen visas i ett separat fält på intyget. Denna information behövs för att kunna visa ansvarig intygsutfärdare på intygsutkast som inte är signerade.

Parametern sjf anger om sammanhållen journalföring gäller eller inte, och möjliggör att visa ett intyg som utfärdats inom en annan vårdgivare än den som användaren är inloggad på. Journalsystemet ansvarar för att se till att Patientdatalagens regelverk för sammanhållen journalföring är uppfyllt och att eventuella spärrar hanteras, när ett intyg från en annan vårdgivare ska visas. Informationen i det intyg som visas kan återanvändas till att skapa ett nytt intyg för den vårdenhet som användaren är inloggad på. Webcert PDL-loggar att intyget visats på samma sätt som om intyget utfärdats inom samma vårdgivare, med tillägget att intyget visats på begäran av journalsystemet inom ramen för sammanhållen journalföring. Tillägget görs för att man i loggarna ska kunna se varför visning av ett intyg från annan vårdgivare tillåtits. Om parametern utelämnas eller har annat värde än ”true” antas att sammanhållen journalföring inte gäller. Parametern ska alltså endast ha värde ”true” då ett intyg från en annan vårdgivare ska visas.

Parametern ref beskrivs i avsnitt 4.13 Intygsreferens med ref.

Parametern kopieringOK styr funktionen Förnya. Parametern sätts per default till true om inget anges. Sätts kopieringOK=false tillåts användaren inte att förnya ett signerat intyg (gäller från WC-6.4.0).

4.3.4 Överhoppslänken

Ett exempel på en överhoppslänk kan se ut så här:

https://webcert.intygstjanster.se/visa/intyg/a9f38f86-970c-4e76-b0a7-385fa31e1bb8?fornamn=Sverker&efternamn=Karlsson&mellannamn=Ohlsson&postadress=Gatuadressen&postnummer=12345&postort=Staden&sjf=true&ref=12345&inaktivEnhet=true

URL Encoding ska användas, enligt application/x-www-form-urlencoded (enl gällande version, definierad i RFC 3986 (https://tools.ietf.org/html/rfc3986)) och UTF-8.

Vid överhoppet till Webcert sker en kontroll av om detta är första gången eller om det redan har skett i en inloggning i Webcert. Om det inte finns en aktiv inloggning sker ett anrop till Säkerhetstjänstens autentiseringstjänst. Webcert har en konfiguration hos Säkerhetstjänsten där Webcert enbart begär information om vem användaren är (HSA-id), och ingen information om medarbetaruppdrag. Detta ger ingen dialog för val av medarbetaruppdrag utan detta hanteras i Webcert genom anrop till HSA.

4.4 Sekvensdiagram

4.4.1 Lista intyg

Nedanstående sekvensdiagram visar hur ett vårdsystem kan hämta en patientens intyg från Webcert med ListCertificateForCareWithQA om man väljer att implementera den tjänsten som backup. Observera att det finns specifika fältregler att följa vid användning av tjänstekontraktet ListCertificatesForCareWithQA, för mer information se kapitel 5.

Figur 6. Sekvensdiagram vid listning av intyg.

4.4.2 Hantera intyg

Nedanstående sekvensdiagram samlar alla flöden för att hantera intyg, inklusive det överhopp som beskrivits i föregående kapitel.

Figur 7. Sekvensdiagram för Webcerts olika funktioner.

4.4.2.1 Intygsutkast som skapas utan anrop via CreateDraftCertificate

Det finns ett flertal fall där intygsutkast kan skapas av användaren från Webcert. I alla dessa fall skapas det nya utkastet utan att vårdsystemet gjort något anrop till CreateDraftCertificate, se "4.1: Skapa intyg utifrån tidigare intyg" i figur 7. 

När det gäller funktionerna förnya intyg, ersätta intyg, komplettera intyg samt kopiera låst utkast skapas ett nytt intygsutkast av samma intygstyp som den användaren hoppat över till. Utkastet förmedlas sedan till integrerande vårdsystem via CertificateStatusUpdateForCare i ett meddelande med händelsekoden "SKAPAT". Vilken av funktionerna som använts för att skapa utkastet anges av ett kodat värde i fältet relation som också skickas med till vårdsystemet. I fältet relation framgår också identiteten på det ursprungliga intyget. Om användaren i överhoppet till Webcert hade en ref-parameter angiven hanteras denna enligt avsnitt 4.13 Intygsreferens med ref. 

Vidare så finns det också intygstyper där ett nytt utkast av en ny intygstyp kan skapas av användaren när denna befinner sig i Webcert. Dessa utkast är då förifyllda med svar från ett tidigare signerat intyg av annan typ. När detta sker kommer intygsutkastet att förmedlas till integrerade vårdsystem via CertificateStatusUpdateForCare i ett meddelande med händelsekoden "SKAPAT". Om användaren i överhoppet till Webcert hade en ref-parameter angiven hanteras denna enligt avsnitt 4.13 Intygsreferens med ref. 

Funktionerna ersätt och kopiera låst utkast används av alla intygstyper i Intygstjänster. För information om vilka intygstyper som omfattas av funktionerna förnya, komplettera och förifyll se kolumnerna Förnya, Ärendekommunikation (avser komplettera som är en del av funktionen Ärendekommunikation) och förifyllnad i Intygslista.

4.4.3 Hantering av ärendekommunikation från vården

Nedanstående sekvensdiagram visar flöden för ärendekommunikation där ärendet inleds med en fråga från vården. Ärendekommunikation implementeras inte för alla intygstyper. I dagsläget är det bara Försäkringskassan intygstyper som har ärendekommunikation.

Figur 8. Sekvensdiagram för ärendekommunikation.

4.4.4 Hantering av ärendekommunikation från intygsmottagare

Nedanstående sekvensdiagram visar flöden för hantering av inkommande ärenden, alltså ärenden som inleds med en fråga från en intygsmottagare. Även dessa flöden gäller enbart för intygstyper för vilka ärendehantering implementeras.

Figur 9. Sekvensdiagram för ärendekommunikation.

4.5 Modell för hantering av intygsberoende information

Den första implementationen av en integration mellan journalsystem och Webcert som togs fram tog inte höjd för att hantera de behov som kommande intygstyper skulle kunna ha kring överföring av olika informationsmängder. Nu är situationen en annan vilket kräver en ny flexibel och framtidssäker lösning. Detta uppnås genom att de tjänster som används för integration med Webcert migreras till att använda den nya flexibla modellen som lanseras inom intygsdomänen i och med implementationen av utökat elektroniskt informationsutbyte.

Den nya modellen beskrivs i tjänstedomänens informationsspecifikationen [R1]. Vilken information som förekommer i den flexibla delen (svar på frågor) skiljer sig för varje typ av intyg, och definieras i den informationsspecifikation som beskriver innehållet i en viss intygstyp.

4.6 Presentation i journalsystem

Med tillgång till samlad intygsinformation kan journalsystemet presentera översiktsvyer för intygen. Med översiktsvy avses tabell eller lista som visar den för användaren och situationen mest relevanta informationen. Det huvudsakliga scenariot är hantering av intyg i ett läge där en patient är vald.

En vy för hantering av intyg i journalsystemet bör innehålla följande funktionalitet:

• Funktion för att skapa nytt intyg: Användaren ges möjligheten att välja vilken typ av intyg som ska skapas. Detta val görs lämpligen via en lista. Denna lista behöver uppdateras för att ge användaren tillgång till nya intygstyper, något som bör kunna utföras via en enkel administrativ rutin som inte medför krav på omfattande förändringshantering vid införande av nya typer av intyg. Valet resulterar i att författarstödet för vald intygstyp öppnas i Webcert.

• Översiktsvyer med patientens intyg: En eller flera listor innehållande övergripande information om befintliga intyg. När användaren klickar på ett intyg öppnas det i Webcert.

4.6.1 Hantering av översiktsvyer

Webcert kommer att leverera fullständig intygsinformation i statusuppdateringar. Detta val är gjort utifrån att informationsmängden per intyg inte är särskilt omfattande varför det faller sig lämpligare att låta varje konsument av informationen själv avgöra vilka avgränsningar som ska göras än att avgränsa vid källan, vilket skulle kräva att alla parter först överenskommer om vilken information som ska tas med.

Översiktsvyerna måste ge tillräcklig information för att en användare ska kunna avgöra vilket intyg som ska öppnas i Webcert. Vilken information som krävs för detta får bedömas för varje journalsystem. Beroende på kraven kan olika lösningar väljas. Nedan följer förslag på lösningar.

4.6.1.1 Statisk tabell

Den tekniskt enklaste lösningen är att presentera alla intyg i en lista med fördefinierade kolumner som endast innehåller information som är gemensam för samtliga intygstyper. Med denna lösning är det enkelt att lägga till nya typer av intyg.  Risken med lösningen är att användaren inte kommer att se tillräckligt med information i översikten, vilket försvårar arbetsprocessen.

4.6.1.2 Dynamiska tabeller

För att visa mer utförlig information om intygen behöver lösningen ta hänsyn till skillnaderna mellan olika typer av intyg, och i tabellerna komplettera gemensam information med intygsspecifik information. Detta kan göras genom att per intygstyp definiera vilka delsvar som ska visas, och vilken rubrik kolumnen för varje delsvar ska ha. Informationen bör kunna uppdateras via en administrativ rutin utanför ordinarie releaser för journalsystemet, för att möjliggöra ett enkelt införande av nya intyg. Tabellerna kan sedan dynamiskt byggas upp och populeras via generell logik.

Eftersom olika intygstyper kommer leverera olika delsvar kan en gemensam tabell för alla intygstyper komma att växa med många kolumner, och kolumnerna kommer bara att kunna populeras för vissa typer av intyg. Det kan därför vara bättre att skapa en separat tabell för varje typ av intyg, alternativt för varje typ av intygsmottagare (Försäkringskassan, Transportstyrelsen etc.). Det senare kan vara lämpligt då de intygstyper som har gemensam mottagare kan antas dela många egenskaper.

4.7 Klartexter

För att möjliggöra en enkel men användarvänlig presentation levererar Webcert klartexter för koder i kodverk. Dessa klartexter behöver inte finnas lagrade på intyget, utan informationen berikas innan den överförs till journalsystemet. Logiken kan endast appliceras om relationen mellan kod och klartext är 1:1. Här utgör diagnoskoder ett känt undantag. I det fallet är det dock så att användaren inte bara kan välja ur en uppsättning klartexter, det går även att redigera den valda klartexten. Av denna anledning sparas klartexten som ett separat delsvar (istället för som en klartext tillhörande en kod), och det är därifrån den ska hämtas för presentation.

4.8 Hantering av befintliga intyg vid nya integrationer

De första intyg som implementerades i Webcert, FK 7263 och Transportstyrelsens två läkarintyg, använder inte samma informationsmodell som de nya intyg som införs i och med "Utökat elektroniskt informationsutbyte" [R3]. Den nya versionen av tjänstekontrakten är avsedd för de nya intygen och deras generiska informationsmodell. För att de befintliga intygen ska kunna hanteras denna väg måste de transformeras till den nya modellen.

Här beskrivs hur intygen planeras att hanteras när nya landsting integrerar mot Webcert.

4.8.1 Transportstyrelsens intyg

Transportstyrelsens intyg finns idag tillgängliga i Webcert. Webcert är också enda vägen för att utfärda dessa intyg elektroniskt. De landsting som inte har integrerat sina journalsystem med Webcert har därför inte utfärdat dessa intyg. Det gör övergången till en ny situation relativt enkel, då det inte finns någon egentlig historik att hantera.

Då landstingens införandeplaner inte gäller för dessa intyg har krav kring hantering av dem inte heller lyfts fram av alla landsting, men det står ändå tydligt att Transportstyrelsens intyg måste kunna utfärdas via ett integrerat journalsystem. För att möjliggöra hanteringen har informationsspecifikationer tagits fram som beskriver intygen enligt samma informationsmodell som används för Försäkringskassans intyg.  

4.8.2 FK 7263

För FK 7263 finns det tre typer av övergångar att hantera:

1. Landsting som har hela lösningen (för FK 7263) i sitt journalsystem.

2. Landsting som utfärdar FK 7263 via sitt journalsystem, men använder Webcert som en fristående applikation för ärendekommunikation kring intyget.

3. Landsting som använder Webcert som en integrerad intygsapplikation för FK 7263.

För 1 och 2 införs den nya lösningen utan någon påverkan på den befintliga hanteringen av FK 7263. Om en användare vid något av dessa landsting skulle gå in i Webcert så kommer denne inte att kunna utfärda FK 7263. Ärenden som inkommer rörande FK 7263 för landsting av typ 2 kommer fortsatt resultera i notifieringar per e-post.

För landsting av typ 3 kommer Webcert skicka statusmeddelande för FK 7263 samt de nya intygen med den senaste versionen av CertificateStatusUpdateForCare. Journalsystemet behöver kunna ta emot och hantera detta under övergången då FK 7263 fasas ut ur hanteringen.

4.9 Inloggning i Webcert

Vid överhopp till Webcert sker ett anrop till Säkerhetstjänstens autentiseringsfunktion som gör en inloggning med hjälp SITHS. Konfigurationen för Webcert hos Säkerhetstjänsten är sådan att enbart HSA-id begärs vid en inloggning, och inte som normalt även ett medarbetaruppdrag. Detta medför att ingen dialog för att välja medarbetaruppdrag behöver visas, vilket normalt skulle ske om det finns fler än ett medarbetaruppdrag.

Användaren, i journalsystemet som överhoppet sker ifrån, behöver ha loggat in med SITHS. Om detta inte har gjorts kommer SITHS inloggning krävas vid inloggningen till Webcert. Vid inlogg med SITHS-kort kommer en PIN-kod för autentisering behöver matas in för kontroll av ägande av SITHS-kortet. PIN-koden för SITHS-kortet cachas (mellanlagras) så länge kortet sitter i kortläsaren. Tas kortet ut kommer den cachade PIN-kod raderas.

Ett överhopp till Webcert kan ske på flera sätt, före 3 december 2019 har det varit möjligt att starta en iFrame som hanterar Webcert dialogen, men detta är inte längre möjligt beroende på säkerhetsinställningar i den nationella IdPn som Webcert använder vid inloggning (läs mer i länken nedan under stycket, ”2.8. Webbläsartekniska aspekter”: https://inera.atlassian.net/wiki/pages/viewpage.action?pageId=3475211171#AnpassningavSPvidbytefr%C3%A5nnuvarandeautentiseringstj%C3%A4nsttillIneraIdP1.0-Webbl%C3%A4sartekniskaaspekter. När tiden är inne för att skapa ett intyg behöver intyget skapas först via ett tjänstekontraktsanrop och sedan, med hjälp av information från detta anrop, byggs en URL upp som används för att starta Webcert i inline fönstret.

Vid överhoppet till Webcert kontrolleras om detta är första gången inloggning sker eller om det redan har skett en tidigare inloggning i Webcert. Det görs genom att kontrollera om en cookie för Webcert är satt eller inte. Om det inte finns en aktiv inloggning sker ett anrop till Säkerhetstjänstens autentiseringstjänst genom en omdirigering (redirect) av URL-adress med returadress tillbaka till Webcert.

Vid omdirigering av URL till Säkerhetstjänstens autentiseringsfunktion görs en inloggning med hjälp SITHS. Detta sker genom att sidan som omdirigeringen har blivit gjord till kräver dubbelriktad TLS (Transport Layer Security) med en tom sida (inget visas). När TLS lyckats sker en omdirigering tillbaka till Webcert med det resulterande SAML-identitetsintyget.

Figur 10. Flöde för inloggning till Webcert från journalsystem.

Bilden ovan visar en sammanfattning av flödet:

1. Användaren begär att visa intyg eller skapa nytt intyg. Intyg skapas med ett tjänstekotraktsanrop. En webbläsare startas i användargränssnittet.

2. En URL byggs för HTML-komponenten som visas i webbläsaren. Webcert startas.

3. Webcert kontrollerar om användaren redan är inloggad (finns en sessionscookie) om denna finns och sessionen är aktiv ges användaren åtkomst enligt sin behörighet.

4. Om en inloggnings krävs, sker en omdirigering av URL till Säkerhetstjänsten med returadress Webcert. Sidan som omdirigeringen pekar ut är en TLS-skyddad sida som kräver klientcertifikat. Eftersom PIN-koden är cached I Net iD-klienten sker ingen användardialog utan TLS-förhandlingen använder nyckeln från SITHS för att skapa TLS-sessionen.

5. Misslyckas TLS-förhandlingen får man upp en generell felsida. Lyckas den skapas ett SAML-identitetsintyg (signerad XML) och en omdirigering tillbaka till Webcert sker. Validering av SAML-identitetsintyget sker.

6. Webcert visar intyget för HTML-komponenten i webbläsaren.

7. Användaren fyller i intyget.

8. När användaren är klar stängs webbläsaren. 

Efter att inloggningen är klar hämtas alla behörighetsinformation för Webcert. Denna ligger lagrad för Webcert som medarbetaruppdrag.

4.10 Sessionscookien i Webcert

Webcert använder en sessionscookie för att hålla reda på om användaren är inloggad eller inte. Denna skapas i och med att man valt att logga in, i och med detta har man rätt enligt den information som finns om cookies i Webcert att lagra denna sessionscookie.

Sessionscookien för Webcert bör hanteras i linje med inloggning till journalsystemet. Det vill säga loggas användaren ut från journalsystemet bör Webcert loggas ut samtidigt, samt vice versa. Inloggningsinformationen för Säkerhetstjänstens IdP gäller en timme. Det betyder att Webcert kommer att tvinga fram en ny inloggning och uppdatera sessionen i Webcert.

Användaren loggas ut på grund av inaktivitet efter 30 minuter genom den timeout som finns i Tomcat.

4.11 Medarbetaruppdraget

För användare med SITHS hämtas i samband med autentisering användarens HSA-id från SITHS. Utifrån detta HSA-id slår sedan Webcert upp vilka vårdenheter som användaren har medarbetaruppdrag på genom anrop till HSA. Information om vilka vårdenheter användaren har medarbetaruppdrag på sparas tills sessionen avslutas genom utloggning. Detta gör det möjligt för användare som är anslutna till Webcert som fristående lösning eller som uthoppslösning att byta aktiv vårdenhet utan att behöva logga ut och sedan logga in igen för en annan vårdenhet. Från HSA hämtas även ytterligare information om medarbetaren, såsom specialistkompetenser samt information om vårdenheterna. Med information från HSA-slagningarna avgör Webcert vilken roll användaren ska loggas in som.

Medarbetaruppdraget gäller för den enhet som det ligger lagrat på, det vill säga den Vårdenhet som det gäller för samt de enheter som ligger direkt under. Webcert hanterar inte attributet hsaHealthCareUnitMember. Detta kan skapa problem och är under utredning. Enligt attributet kan man ha en enhet som tillhör Vårdenheten där medarbetaruppdraget är lagrat men ligger någon annanstans i HSA-trädet.

Defintion enligt HSA katalogen:

4.12 Krav på klient

För att integrationen med överhopp ska fungera måste vissa tekniska krav gällande användarens klient vara uppfyllda. Webcert avser att stödja de klienter (operativsystem och webbklient) som definieras av eKlient. Ytterligare krav, gällande till exempel inställningar för active-x-kontroller och Net iD-klient, ägs av Säkerhetstjänster.

Vid utskrift av intyg och utkast från Webcert, laddas en PDF ned, som sedan får skrivas ut. Hur den nedladdade PDF:en sparas till datorn och om den ska raderas direkt, är upp till den som gör en integration med Webcert.  

4.13 Intygsreferens med ref

Ref är ett fält som förekommer i alla tre tjänstekontrakt som vårdsystem använder för att integrera med Webcert samt som överhoppsparameter i URL-överhoppet till Webcert. Värdet för ref är en sträng som kan användas för information som journalsystemet önskar knyta till ett intyg, t.ex. i syfte att kunna koppla ett intyg som förmedlas från Webcert till vårdsystemet till ett redan känt värde och på så vis uppnå state-less sessionshantering. Ref-värdet kan förmedlas från vårdsystem till Webcert på två sätt, antingen via fältet i CreateDraftCertificate eller via överhoppsparametern vid URL-överhoppet till Webcert.

4.13.1 Webcerts hantering av ref-värden

Webcert hanterar de ref-värden som vårdsystem anger på följande sätt:

• Om CreateDraftCertificate-anrop sker med ett värde angivet i ref-fältet så sparas värdet med intygsutkastet.

• Om uthopp sker till signerat intyg och ett värde finns angivet i överhoppsparametern ”&ref=” så sparas värdet på eventuella nya intygsutkast som skapas ifrån det signerade intyget. Ref-värdet för det signerade intyget ändras inte om det redan finns sparat. 

• Om uthopp sker till intygsutkast eller signerat intyg som inte redan har ett ref-värde sparat så kommer ett värde som är angivet i överhoppsparametern ”&ref=” att sparas ner till intyget användaren har hoppat över till. 

Detta leder till att:

• Intyg som skapas via CreateDraftCertificate, i alla överföringar tillbaka till vårdsystemet, kommer ha det ref-värde som sattes i CreateDraftCertificate.

• Intyg som skapas i Webcert (med någon av funktionerna ersätt, förnya, komplettera, kopiera låst utkast eller förifylla) i alla överföringar tillbaka till vårdsystemet kommer ha det ref-värde som sattes i överhoppet.

5 Fältregler för tjänstekontrakt från domänen Intygshantering

Detta kapitel beskriver vilka fältregler som gäller för tjänstekontrakten i domänen Intygshantering vid integration med Webcert.

5.1 CreateDraftCertificate

5.2 CertificateStatusUpdateForCare

5.3 ListCertificateForCareWithQA

5.4 Fält som är gemensamma för ovanstående tjänstekontrakt

6 Versionshantering av intyg

De digitala intygstyper som hanteras av Webcert (och övriga system i Ineras Intygstjänster) kravställs i form av en intygsspecifikation och en XML-fil med intygstexter. För att möjliggöra flexibla uppdateringar av intygstyperna finns det två nivåer av versioner, huvudversion och underversion. En huvudversion avser ett visst informationsinnehåll och representeras av intygsspecifikationen, medan en underversion avser vilka texter som används vid ifyllande och visning av intyget och representeras av XML-filen med intygstexter. 

Inför att ett intyg versionsuppdateras publiceras information om detta av Intygstjänsters förvaltning på Confluence-sidan Intyg Krav. 

6.1 Intygsspecifikationer och XML med intygstexter

För att identifiera intygsspecifikationer och XML-filer med intygstexter används två olika attribut, Intyg.typ och Intyg.version. Attributet Intyg.typ pekar ut vilken typ av intyg som avses (t.ex. Arbetsförmedlingens medicinska utlåtande). Attributet Intyg.version består av två delar, där det första heltalet avser huvudversionen. Om en befintlig intygstyp uppdateras och förändringarna leder till att informationsinnehållet (intygsspecifikationen) förändras hanteras detta genom att en ny huvudversion upprättas. I detta fall förändras versionen som följer: Intyg.typ = "AF00213", Intyg.version = "1.0" blir Intyg.typ = "AF00213", Intyg.version = "2.0". Det andra heltalet i Intyg.typ avser underversionen. Om en befintlig intygstyp uppdateras och förändringarna enbart är textuella hanteras detta genom att en ny version av XML-filen med intygstexter upprättas, och aktiveras, för intygstypen i den aktuella huvudversionen. I detta fall förändras versionen som följer: Intyg.typ = "AF00213", Intyg.version = "1.0" blir Intyg.typ = "AF00213",  Intyg.version = "1.1". 

Intygsspecifikationerna publiceras per huvudversion av intygen och beskriver hur denna ska se ut och fungera. Den används för att utforma intyget i XML-format samt för att ta fram de schematron-filer som används för att validera informationstrukturen och informationsinnehållet i ett intyg. En ny huvudversion leder till att en ny intygsspecifikation upprättas och publiceras parallellt med tidigare huvudversioner. Vid huvudversionsuppdatering av ett intyg inkluderar intygsspecifikationen för den nya versionen en beskrivning av vad som ändrats jämfört med den tidigare huvudversionen. Mellan olika huvudversioner av en intygstyp kan det hända att uppsättningen av fråge-id:n skiljer sig åt eftersom informationsinnehållet kan ha förändrats. 

XML-filerna med intygstexter publiceras per underversion och tillhör alltid den huvudversion som det första heltalet i Intyg.version anger. Olika underversioner inom samma huvudversion ser oftast som XML-filer i överföringen, likadana ut, men texterna som används vid presentation av intyget skiljer sig åt. Undantaget från att underversioner alltid ser likadana ut i XML-formatet är de intygstyper där tilläggsfrågor kan förekomma. Där kan det i slutet av intygs XMLen tillkomma nya frågor mellan två underversioner. 

6.2 Webcerts hantering av intygsversioner

Webcert skapar alltid nya intygsutkast i den senaste aktiverade versionen när ett integrerande system anropar CreateDraftCertificate. 

Webcert tillåter inte kopiering (ersätt, förnya, komplettera och kopiera låst utkast) av information mellan olika huvudversioner av intyg. Hur dessa funktioner hanteras för en huvudversion som ersätts av en nyare huvudversion kan skilja sig åt mellan olika intygstyper. Det vanligaste är dock att befintliga intyg kan fortsätta hanteras i sina tidigare huvudversioner även efter det att en ny huvudversion aktiverats. Detta leder till att utkast i äldre huvudversion fortfarande kan signeras, och att nya utkast i äldre version kan komma att skapas via kopieringsfunktionerna. Integrerande system måste därför kunna ta emot intygstyper i alla versioner som de förekommit i.