I detta dokument specificeras integrationen med Webcert. Den ska ses över och uppdateras då nya intyg eller förändringar i integrationen görs. När en ändring är genomförd måste landsting och vårdsystemsleverantörer få veta vad vi ändrar och något bra sätt att kommunicera detta måste tas fram.

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 beskriver de olika lösningsalternativen.

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 Webcerts 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, och den funktionalitet som beskrivs från kap 3 och framåt i detta dokument.

Webcert är en webbapplikation som körs som en nationell instans (d.v.s. en gemensam installation för alla användare) för att skriva intyg och hantera ärendekommunikation kring ett läkarintyg. Intyg som idag kan utfärdas i Webcert är:

• Läkarintyg FK7263
• Transportstyrelsens läkarintyg
• Transportstyrelsens läkarintyg, diabetes

I kommande versioner av tjänsten blir det möjligt att utfärda fler typer av intyg, i första hand de intygstyper som omfattas av arbetet med ett utökat elektroniskt informationsutbyte. 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.

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-kort, antingen direkt i Webcert eller via journalsystemet ifall användaren kommer via det. Inloggningen med SITHS-kort 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.

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 sina ej hanterade frågor och svar till Försäkringskassan
• Få en lista över sina osignerade intyg
• Få mer information om Webcert

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 nio landsting som använder journalsystemet Cosmic använder Webcert för att hantera ärendekommunikationen kring ett befintligt intyg. Detta görs via ett uthopp från Cosmic till Webcert. Under 2017 och 2018 utvecklar de nio Cosmic-landstingen en liknande integrationslösning som Norrbotten och Halland för att använda Webcert i sin helhet, dvs. även skriva intyg i 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 relaterade frågor och svar, medan visning och editering av enskilda intyg, samt hantering av frågor och svar, 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 t.ex 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.

4 Teknisk lösning för integrerad applikation

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

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.

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. För läkarintyget FK7263 hölls därför antalet statusuppdateringar nere genom att antalet fält som triggade uppdateringar avgränsades. Denna typ av avgränsning är inte lämplig för de nya intygen, där Webcert inte avgränsar vilken intygsinformation som skickas och inte bör ta ställning till vilken information det integrerade journalsystemet ska nyttja. Antalet statusuppdateringar som skickas till journalsystemet för denna händelse (”intygsutkast ändrat”) kommer istället att hållas nere genom att Webcert skickar maximalt en statusuppdatering var femte minut som intygsutkastet editeras. Denna tidsenhet kan vid behov komma att göras konfigurerbar.

För att undvika onödiga statusuppdateringar har Webcert i fält vars data ska vara i ett givet format (t.ex. datum) kontroller på att fälten är fullständigt ifyllda innan någon händelse triggas.

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 tillstånden och händelserna relaterar till varandra och när de uppkommer.

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 journalystemet 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.1 Konfiguration för statusuppdateringar

De vårdenheter som ska ta emot statusuppdateringar (via CertificateStatusUpdateForCare) registreras i en tabell i Webcert automatiskt första gången det skapas ett intygsutkast på den enheten. Statusuppdateringar kommer sedan att skickas för samtliga intyg som skapas på vårdenheten, ä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 dock 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.) men 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. Det gäller följande uppgifter:

• Typ av intyg, enligt kodsystem KV_Intygstyp (samt kv_utlåtandetyp_intyg för Transportstyrelsens intyg)
• Patient (namn och adress (Postadress som kan användas för att kontakta patienten. Integrerat journalsystem väljer vilken adress som ska användas, men det är rekommenderat att folkbokföringsadressen används.))
• Skapat av (HoS-person, vårdenhet och vårdgivare)

Samma uppgifter överförs oavsett vilken typ av intyg som skapas. 

4.2.1 Implementation

Nya intyg skapas via tjänstekontraktet CreateDraftCertificate. Ovan angivna uppgifter 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 editera intyget i Webcert. Flödet synliggörs i nedanstående sekvensdiagram.

 Ö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.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 1 används <intygs-typ> i utlatande.typAvUtlatande.code
• För CreateDraftCertificate version 3 används <intygs-typ> i intyg.typAvIntyg.code

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

• I svaret för CreateDraftCertificate version 1 hämtas <intygs-id> från utlatande-id.extension
• 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 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 editera 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 gör ingen validering av de mottagna parametrarna, och kommer således att visa upp den adress som kommer med parametern, i det format det mottogs i. 

Webcert hämtar personuppgifter, i regel, från den nationella personuppgiftstjänsten (vidare benämnd PU-tjänsten). Notera att för Försäkringskassans intyg så kommer inte adress att vara synlig, eller sparas till intyget.

För intyg tas adressen från de medföljande parametrarna, medans övriga uppgifter hämtas från PU-tjänsten. För andra intysgtyper hämtas samtliga personuppgifter från PU-tjänsten. Skiljaktigheterna kan bland annat bero på krav från intygsägaren. Om patientens namn- och/eller adressuppgifter skiljer sig från det som anges 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 kopieras, vid förnyelse eller då det blir ersatt, 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 demsamma. 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 för användaren att en föränding 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änssnittent att patienten har ett nytt personnummer.

Om den frivilliga parametern avliden finns med och har det 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, t.ex. genom kopiering. 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. Dvs avlidenmarkering i PU-tjänsten trumfar parameter avliden = false, och patienten kommer att behandlas som avliden i Webcert.

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å), dvs. på vilken enhet som användaren arbetar åt 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 underenhet 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 men ännu inte arkiverad i HSA. Det ska inte längre gå att skriva intyg på den enheten och användaren kommer inte kunna kopiera eller förnya 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 med texten ”Patienten har ett nytt personnummer: [alternatePatientSSn]. Om ett nytt intyg skapas utifrån ursprungsintyget (exempelvis om intyget kopieras) 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, eftersom det inte finns någon standard för reservnummer, görs genom att validera att identiteten varken är ett personnummer eller ett samordningsnummer) visas texten ” Patienten har samordningsnummer kopplat till reservnummer: [alternatePatientSSn]”. Värdet ska skickas i det format som ska visas för användaren, dvs 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 kopieras) ska det nya intyget skrivas på samordningsnumret, dvs 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.

Värde ”true” i parametern sjf för anger att sammanhållen journalföring gäller, 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. Det visade intyget blir möjligt att kopiera till 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 när intyg utfärdade inom samma vårdgivare visas, 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 är en parameter som vården får använda fritt. Då denna parameter är satt till något då ett intyg skapas i Webcert (genom exempelvis komplettering eller kopiering, inte när ett intyg skapas från journalsystemet) kommer Webcert att skicka med uppgiften tillbaka till journalsystemet tillsammans med händelsen ”intygsutkast skapat”. Journalsystemet kan koppla ihop sin parameter ref på det sätt man önskar i journalsystemet. Te.x. använder Cosmic denna funktion för att knyta intyg skapade i Webcert till en så kallad vårdkontakt.

Parametern kopieringOK anger om Webcert ska tillåta kopiering av det visade intyget. Till kopiering räknas här även förnyelse av intyg. En anledning till att inte tillåta kopiering av ett intyg kan vara att den enhet som skickas med i parametern enhet (se ovan) av någon anledning inte kan garanteras vara den enhet där personen som öppnar intyget arbetar just nu. Kopiering av intyg med en felaktigt angiven enhet i överhoppslänken skulle medföra att det skapas ett nytt intyg på en felaktig enhet. Om användaren alltid väljer aktuell enhet i journalsystemet innan överhopp till Webcert, så är denna parameter inte aktuell att använda. Om parametern utelämnas kommer det att tolkas som värde ”true”, dvs. Webcert kommer tillåta kopiering.

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 autentiseringtjänst. Webcert har en konfiguration hos Säkerhetstjänsten där Webcert enbart begär information om vem användaren är (HsaId), 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.

4.4.2 Hantera intyg

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

4.4.3 Hantering av frågor från vården

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

4.4.4 Hantering av frågor 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.

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. Lösningen var implicit knuten till läkarintyget FK 7263, genom att den information som överfördes i exempelvis statusuppdateringar var den som krävdes för det aktuella intyget. Nu är situationen en annan där fler intygstyper för Försäkringskassan ska digitaliseras. Samtidigt finns det fler intressenter av integrationen 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/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 lista/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.

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.

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 befintliga intygen, FK7263 och Transportstyrelsens två läkarintyg, som redan är implementerade i Webcert sedan långt tidigare använder inte samma informationsmodell som de nya intyg som införs i och med utökat elektroniskt informationsutbyte. 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 tidigare har integrerat sina journalsystem med Webcert har 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 FK7263

För FK7263 har vi tre typer av övergångar att hantera:

1. Landsting som har hela lösningen (för FK7263) i sitt journalsystem.
2. Landsting som utfärdar FK7263 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 FK7263.

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

För landsting av typ 3 kommer Webcert skicka statusmeddelande för FK7263 samt de nya intygen med den senaste versionen av CertificateStatusUpdateForCare. Journalsystemet behöver kunna ta emot och hantera detta under övergången då FK7263 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-kortet. Konfigurationen för Webcert hos Säkerhetstjänsten är sådan att enbart HsaId 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 mer än ett medarbetaruppdrag.

Användaren i journalsystemet som överhoppet sker ifrån behöver ha loggat in med ett SITHS-kort. Om detta inte har gjorts kommer ett SITHS-kort krävas vid inloggningen till Webcert, och en autentiserings PIN-kod 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 denna cachade PIN-kod raderas.

Ett överhopp till Webcert kan ske på flera sätt, en möjlighet är att starta en iFrame som hanterar Webcert dialogen som inbyggd del i själva journalsystemets fönster. När tiden är inne för att skapa ett intyg, behöver intyget skapas först via ett WebService anrop 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 sker en kontroll av om detta är första gången eller om det redan har skett i en inloggning i Webcert genom kontroll av om 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 redirekt av URL adress(Post) med retur adress tillbaka till Webcert.

 Webcert har en konfiguration hos Säkerhetstjänsten där Webcert enbart begär information om vem användaren är (HsaId), och ingen information om medarbetaruppdrag. Detta ger ingen dialog för val av medarbetaruppdrag utan detta hanteras i Webcert genom anrop till HSA.

Vid redirekten av URL till till Säkerhetstjänstens autentiseringsfunktion som gör en inloggning med hjälp SITHS-kortet. Detta sker genom att sidan som redirekten har blivit gjord till kräver dubbelriktad SSL med en tom sida (inget visas) utan när TLS lyckats sker en redirekt tillbaka till Webcert med det resulterande SAML identitetsintyget.

Konfigurationen för Webcert hos Säkerhetstjänsten är sådan att enbart HsaId 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 mer än ett medarbetaruppdrag.

Användaren i journalsystemet som överhoppet sker ifrån behöver ha loggat in med ett SITHS-kort. Om detta inte har gjorts kommer ett SITHS-kort krävas vid uppsättandet av TLS förbindelsen i inloggningsdialogen för autentiseringstjänsten hos Säkerhetstjänsten, samt en autentiserings PIN-kod 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 denna cachade PIN-kod raderas. Det är detta skäl för att inget visas i överhoppet och inloggningen till Webcert. Även kallas smartkorts SSO.

Bild 2, Flöde för inloggning till Webcert från journalsystem

För att se flödet, visar bilden ovan. En sammanfattning av flödet:

1. Användaren begär att visa intyg eller skapa nytt intyg. Intyg skapas med ett WebService anrop. Eni Frame startas i användargränssnittet.
2. En URL byggs för HTML-komponenten som visas iFramen. Webcert startas.
3. Webcert kontrollerar om användaren redan är inloggad (finns en sessionscookie) om denna finns och sessionen är aktiv körs användaren med sin behörighet,
4. Om en inloggnings krävs, sker en redirect av URL till Säkerhetstjänsten med returaddress Webcert. Sidan som redirekten 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-kortet 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 redirect tillbaka till Webcert sker. Validering av SAML identitetsintyget sker.
6. Webcert visar intyget för HTML-komponenten i iFrame fönstret.
7. Användaren fyller i intyget.
8. När användaren är klar, stängs iFramen? Eller döljs denna?

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. Dvs 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 enbart en timma. Det betyder att Webcert kommer att tvinga fram en ny inloggning och uppdatera sessionen i Webcert.

Inaktivitetstimeout i Webcert är på 30 minuter genom den timeout som finns i Tomcat.

4.11 Medarbetaruppdraget

För användare med SITHS-kort hämtas i samband med autentisering användarens Hsa-id från SITHS-kortet. Utifrån detta Hsa -id slår sedan Webcert upp vilka vårdenheter som användaren har medarbetaruppdrag vid 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å, dvs den Vårdenhet som det gäller för samt de underenheter 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 i Hsa-trädet någon annanstans.

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 t.ex. inställningar för active-x-kontroller och NetID-klient, ägs av Säkerhetstjänster.

Vid utskrift av intyg och utkast från Webcert, laddas en PDF ner, 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 att ställa in för sina användare.