I detta dokument specificeras hur ett journalsystem kan göra en integration med 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:

...

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.

...

• 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.

...

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

...

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

...

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

...

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.

...

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. 

...

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

...

<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. 

...

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.

...

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.

...

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.

...

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:

...

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. 

...

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

...

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.

...

• 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.

...

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 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.

...

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-kortet. 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-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 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. 

...

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.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

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