Problem att logga in

Har du problem att logga in i någon av Intygstjänsterna?
Här finns instruktioner för hur du kan felsöka.

Kontrollera att du har abonnemang och rätt behörighet

För att använda Intygstjänster krävs ett abonnemang - läs mer här Webcert - Inera
Behörighet till Intygstjänsterna beslutas av Verksamhetschef på den aktuella vårdenheten och tilldelas av en lokal HSA-administratör. Inera kan inte ge dig behörighet.

Webcert - vid inloggning med SITHS krävs Medarbetaruppdrag syfte Vård- och behandling.

Rehabstöd - kräver inloggning med SITHS Medarbetaruppdrag syfte Vård och behandling samt om du är Rehabkoordinator en särskild roll hsaSystemRole. Läs mer här https://inera.atlassian.net/wiki/spaces/EIT/pages/412354133

Intygsstatistik - kräver inloggning med SITHS, Medarbetaruppdrag syfte Statistik

Felsökning vid användning av SITHS med NetID

• Kontrollera att din webbläsare stödjer de tekniska kraven och att du har rätt version av NetID installerat. Kontakta din lokala IT-support om du behöver hjälp.

• Starta om datorn och gör sedan om inloggningsproceduren.

• Kontrollera ditt SITHS genom att:

  • kontrollera att det sitter rätt i kortläsaren

  • prova att läsa in kortet på nytt genom att högerklicka på NetID-ikonen och välj ”Läs in kortet på nytt”.

  • kontrollera att du inte har några problem med att använda ditt SITHS i övrigt, till exempel i Pascal.

  • kontrollera om SITHS-kortets certifikat är giltigt. Om du inte vet hur du gör det, kontakta din lokala IT-support.

  • kontrollera att du har valt rätt certifikat.

• Rensa webbläsarens temporära internetfiler (cache) - kontakta din lokala IT-support om du behöver hjälp

• Kontrollera att det fungerar för en annan användare att logga in i tjänsten på samma dator.

• Kontakta din lokala HSA-administration och säkerställ att du har medarbetaruppdrag med ändamål för vård och behandling på den aktuella vårdenheten.

• Om Citrix används, prova att logga in på en dator utan Citrix.

• Här kan du testa SITHS eID https://minasidor.siths.se/ineraauthority/Test

Felsökning inloggning med SITHS eID

• Kontrollera att din webbläsare stödjer de tekniska kraven och att du har rätt version av SITHS eID installerat. Kontakta din lokala IT-support om du behöver hjälp.

• Starta om datorn och gör sedan om inloggningsproceduren.

• Kontrollera ditt SITHS genom att:

  • kontrollera att det sitter rätt i kortläsaren

  • prova att trycka på F5 för att ladda om SITHS eID klienten och anslutna kort

  • kontrollera att du inte har några problem med att använda ditt SITHS i övrigt, till exempel i Pascal.

  • kontrollera om SITHS-kortets certifikat är giltigt. Om du inte vet hur du gör det, kontakta din lokala IT-support.

  • kontrollera att du har valt rätt certifikat.

• Rensa webbläsarens temporära internetfiler (cache) - kontakta din lokala IT-support om du behöver hjälp

• Kontrollera att det fungerar för en annan användare att logga in i tjänsten på samma dator.

• Kontakta din lokala HSA-administration och säkerställ att du har medarbetaruppdrag med ändamål för vård och behandling på den aktuella vårdenheten.

• Om Citrix används, prova att logga in på en dator utan Citrix.

• Här kan du testa SITHS eID https://minasidor.siths.se/ineraauthority/Test

LoA-nivåer

Tidigare beslut har inneburit att Ineras tjänster som innehåller patientuppgifter, däribland Intygstjänster, skulle kräva SITHS-certifikat med LoA3 från och med 2020-12-09. Där har ett nytt beslut tagits som innebär att alla SITHS-certifikat (LoA2 och LoA3) fortsättningsvis kommer att vara godkända för inloggning i Ineras tjänster. Beslutet gäller tillsvidare.

Inloggning med e-legitimation mobilt BankID

Privatläkare som inte har SITHS och som har en enskild näringsverksamhet/firma kan logga in i Webcert genom att använda sig av e-legitimation mobilt BankID.

Felsökning e-legitimation

Du kan använda BankID på kort, mobilt BankID eller Telia e-legitimation. Det är endast den läkare som utfärdat intyget som kommer kunna se det i Webcert.
Giltighetstiden för en e-legitimation är begränsad, kontrollera på utgivarens webbplats om giltighetstiden har gått ut.

Krav på webbläsare

Tjänsterna är utvecklade och testade för Edge Chromium och Chrome
Tjänsterna fungerar även med Internet Explorer 11, dock kommer webbläsaren att fasas ut under 2023

För att signera med SITHS eID i webbläsarna Edge Chromium och Chrome behöver användaren installera SITHS eID Windowsklient. För mer information se https://inera.atlassian.net/wiki/x/uYBWhw

Problem med signering

Användare är inloggad som Vårdadmin = saknar Läkarbehörighet i HSA

En användare definieras som läkare om det i HSA går att styrka att användaren tillhör den legitimerade yrkesgruppen Läkare, har befattningskoden 203020 eller 204010 eller har någon av befattningskoderna 203090 och 204090 i kombination med vissa förskrivarkoder. Se Användarmanual, Tabell 1, Kapitel 2.1 för detaljer.

SITHS eID saknas

Har Vårdgivaren gått över till Underskriftstjänsten behöver användaren ha installerat SITHS eID Windowsklient. För mer information se https://inera.atlassian.net/wiki/x/uYBWhw

Användare som tidigare har haft ett samordningsnummer och nyligen fått ett svenskt personnummer

Dessa användare kan fortfarande logga in i Webcert med sina SITHS-kort men kan i vissa fall få problem vid signering. Felmeddelandet som brukar visas är: “saknar förutsättningar för att signera i annan webbläsare än Internet Explorer”.

Problemet uppstår när användaren försöker signera med sitt befintliga SITHS-kort men det gamla certifikatet för samordningsnummer ligger kvar på SITHS-kortet och fortfarande väljs vid signeringen. När Underskriftstjänsten sedan använder det gamla samordningsnumret för kontroll mot HSA får Underskriftstjänsten ingen träff och då misslyckas signeringen.

Det är nämligen skillnad på vilken typ av certifikat som används vid inloggning och signering i Webcert. Vid traditionell inloggning mha mTLS använder Ineras IdP HSA-id-certifikatet (SITHS e-id Person HSA-id [2-3] CA v1) men Underskriftstjänsten och SITHS eID-klient använder sig av PNR-certifikaten (SITHS e-id Person ID [2-3] CA v1). Båda typerna skall alltid finnas på alla SITHS-kort.

Lösningsförslag:

• Beställ nytt SITHS-kort när användare fått dessa problem. Då utan det gamla certifikatet med samordningsnummer och med det nya personnummer-certifikatet.

• Ett annat alternativ är att be en HSA-administratör hjälpa användaren att ta bort certifikatet med samordningsnummer från SITHS-kortet så att detta inte kan väljas vid signering. Då måste man även försäkra sig om att ett nytt certifikat med användarens nya personnummer har laddats ner till SITHS-kortet så att det finns ett pnr-cert på kortet som kan användas av SITHS eID-klient.

Felanmälan och användarstöd

Kontakta din lokala it-support

Om din felsökning inte löser ditt problem ska du i första hand kontakta din lokala it-support.

När du kontaktar din lokala support underlättar det om du har följande information till hands:

• tidpunkt för inloggningsförsök

• ditt HSA-Id (användare)

• eventuellt felmeddelande

Kontakta Inera support

Om problem inte går att lösa lokalt, kontakta Inera support.

Webcert

Intygstyper i Webcert

Följande intygstyper kan hanteras i Webcert:

Försäkringskassan

• Läkarintyg för sjukpenning

• Läkarutlåtande för aktivitetsersättning vid förlängd skolgång

• Läkarutlåtande för aktivitetsersättning vid nedsatt arbetsförmåga

• Läkarutlåtande för sjukersättning

Arbetsgivare (via invånaren)

• Läkarintyg om arbetsförmåga

• Läkarintyg om arbetsförmåga – sjuklöneperioden

Transportstyrelsen

• Läkarintyg avseende högre körkortsbehörigheter eller taxiförarlegitimation

• Läkarintyg diabetes

Skatteverket

• Dödsbevis

Socialstyrelsen

• Dödsorsaksintyg

Patientidentitet

Webcert hanterar endast person- och samordningsnummer som patient-id. Personer med reservnummer stöds alltså inte av intygstjänsterna och Försäkringskassan tar inte emot läkarintyg utfärdat på ett reservnummer. Däremot finns det en hantering av reservnummer för Webcert genom parametern alternatePatientSSn, för mer information se dokumentet https://inera.atlassian.net/wiki/x/noJi .

Hantering av skyddade personuppgifter

Hantering av skyddade personuppgifter - patient

I Intygstjänster behandlas all personlig data som om patienten har skyddade personuppgifter. Därför har namn- och adressuppgifter för samtliga intyg tagits bort.

När du utfärdar intyg för patienter med skyddade personuppgifter hanteras endast personnummer. På så sätt går det inte att särskilja intyg för patienter med skyddade personuppgifter från intyg utfärdade på andra patienter. För att underlätta för läkare som ska utfärda intyg visas namn fortfarande upp i Webcert, tillsammans med en indikation om att patienten har skyddade personuppgifter.

Hantering av skyddade personuppgifter - läkare

Om du som intygsutfärdande läkare har skyddade personuppgifter finns det stöd även för detta i Webcert. När du ska utfärda ett intyg kommer det upp en varning som informerar om riskerna och berättar vilka uppgifter som kommer att stå på intyget. Du kan sedan själv välja om du vill fortsätta använda Webcert för att utfärda intyg. Den information som följer med intyget är ditt namn och vårdenhetens kontaktuppgifter, dessa uppgifter syns även i loggar och loggutdrag.

Vill du inte signera med ditt namn kan du som alternativ ändå författa ett intygsutkast och låta en annan läkare på vårdenheten signera intyget.

Behörigheter för hantering av personer med skyddade personuppgifter

Till skillnad från vården exkluderas vårdadministratörer i hanteringen av personer med skyddade personuppgifter. Detta har sin grund i att det inte finns några rättsliga regler kring hanteringen av skyddade personuppgifter mellan organisationer/myndigheter. Offentlighet- och sekretesslagen kommer således att avgöra vilka uppgifter som kan lämnas ut från respektive aktör. Skyddade personuppgifter innebär inte någon absolut sekretess. Varje myndighet ansvarar för sina egna rutiner. Enligt SOSFS 2008:14 ska en vårdgivare ha rutiner för att hantera journalföring för patienter med skyddade personuppgifter. Varje myndighet bör särskilt beakta hanteringen av skyddade personuppgifter vid utveckling av IT-stöd. IT-stödet bör utformas så att endast ett fåtal personer med särskild behörighet har tillgång till skyddade personuppgifter. Därav begränsningen till att det enbart är läkare och tandläkare som har åtkomst till intyget.

Utfasning av läkarintyget ”FK7263”

Det går inte att skapa, redigera, signera eller skicka läkarintyg FK7263 till Försäkringskassan. Det är inte heller möjligt att hantera ärendekommunikation samt besvara befintliga frågor.

Det går fortfarande att öppna befintliga intyg samt att manuellt markera frågor och kompletteringar som hanterade. Makulering av intyg är också möjlig, men ingen makuleringsnotifiering till Försäkringskassan skickas.   

Sammanhållen journalföring (SJF)

Webcert har inte stöd för sammanhållen journalföring (SJF). Däremot kan SJF möjliggöras för vårdgivare och deras journalsystem genom flaggan ”sjf”. Detta kräver ett tilläggsavtal för Webcert och integration med journalsystem.

Sammanhållen journalföring, flaggan sjf = true:

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.” Saknas sjf och användaren försöker få åtkomst till ett intyg hos en annan vårdgivare än den användaren är inloggad på, kommer användaren nekas åtkomst till intyget.

Behörighetsmodellen för Webcert mellan vårdenheter inom samma vårdgivare, eller mellan vårdgivare om sjf=true

Arbetsgivarintyg (AG7804 och AG1-14)

Skapa AG7804 utifrån FK7804

Intyget AG7804 är avsett för arbetsgivaren och ska förmedla i stort sett samma information som Försäkringskassan får via sitt intyg FK7804. För att förenkla för användaren som utfärdar intygen så ska all information som går att förifylla flyttas över från det signerade FK7804 till utkastet för AG7804 när funktionen skapa AG7804 från FK7804 används.

För att detta ska vara möjligt krävs dock att vissa förutsättningar är på plats:

• Användaren använder Webcert integrerat i journalsystem

• Användaren är inloggad på den enheten där det ursprungliga intyget (FK7804) utfärdats

• Tillgängligt FK7804 är:

  • signerat

  • inte makulerat

  • utfärdat på samma personnummer

  • utfärdat på samma vårdenhet som anges i överhoppet eller underenhet till denna

Anpassa intyg till arbetsgivare (AG-intygen) i 1177, Mina Intyg

Arbetsgivarintygen (AG1-14 ochAG7804) är framtagna för att säkerställa att arbetsgivarna får tillräcklig information för att kunna bevilja invånaren sjuklön och vid behov erbjuda rehabilitering.

• Om läkaren har uppgett diagnos i AG-intygen kan invånaren välja att dölja denna när intyget skrivs ut från 1177, Mina intyg.

• Om läkaren inte har uppgett diagnos i AG-intygen finns det inget för invånaren att dölja och funktionen i 1177, Mina intyg är inaktiverad.

Medarbetaruppdrag på nedlagd enhet

För att få skapa, ändra och vidare hantera intyg i Webcert krävs behörighet i form av medarbetaruppdrag med ändamål Vård och behandling på enheten. Det är på så sätt systemet säkerställer att du har en patientrelation och enligt patientdatalagen har rätt att ta del av intygen, som är att betrakta som journalhandlingar.

Vid nedläggning av en enhet tas medarbetaruppdraget bort och intyget blir då inte längre åtkomligt via Webcert, eftersom användaren inte längre har behörighet till enheten där intyget utfärdats.

Om journalsystemet är integrerat med Webcert och intyget är åtkomligt i journalsystemet kan intyget tillgängliggöras för journalsystemet i följande fall.

• Intyget som skapats på en nedlagd enhet kan läsas av användare som har medarbetaruppdrag på en enhet inom samma vårdgivare

• Intyget som skapats på en nedlagd enhet kan läsas av användare som har medarbetaruppdrag på en annan vårdgivare genom att använda funktionen för sammanhållen journalföring

Vid frågor gällande intygs åtkomlighet i journalsystemet hänvisas till journalsystemsleverantören.

Automatiskt sparande

Den information som en användare skriver i ett intyg sparas var 5:e sekund i Webcert.

Makulera intyg

Endast läkare kan makulera intyg i Webcert. Vid mindre allvarliga fel ska intyget ersättas istället för makuleras. Att utfärda ett intyg på fel patient är ett exempel på allvarligt fel där intyget omgående ska makuleras.

När intyg makuleras i Webcert så skickas en statusuppdatering tillbaka till ett integrerat journalsystem. Om det blir fel i denna statusuppdatering och den inte kan levereras, eller tar längre tid än normalt, så vet journalsystemet inte om att intyget är makulerat.

Läs mer här hur intyg makuleras i Webcert

Obs! Inera är endast personuppgiftsbiträden och kan inte ta bort felaktiga intyg mer än i undantagsfall, t ex då ett journalsystem inte längre finns.

Nationella spärrtjänsten

För de som integrerat sitt journalsystem med Webcert sker all patient- och processhantering i journalsystemet och även kontroll av aktuella spärrar. Detta regleras i det avtal som tecknas mellan vårdgivare och Inera vid integration med Webcert. Webcert är alltså inte anslutet till nationella spärrtjänsten.

Tjänstekontrakt och Parametrar

Skapa intygsutkast - CreateDraftCertificate

När ett nytt intyg skapas överförs uppgifter från journalsystemet som sedan inte kan ändras i Webcert. Uppgifterna överförs oavsett vilken typ av intyg som skapas genom 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 Webcert. Användaren kan därefter redigera intyget i Webcert. Alltså, vid ett tjänsteanrop till CreateDraftCertificate kommer intygs-id:t att returneras synkront.

ListCertificate

Vid ett scenario där ett utkast blivit skapat i Webcert, men en incident gör att vårdsystemet förlorat intygs-id:t innan något är sparat i vårdsystemet, så kan tjänstekontraktet ListCertificateForCareWithQA användas. Om man väljer att implementera tjänstekontraktet ListCertificateForCareWithQA är det möjligt för ett vårdsystem att hämta en patients intyg från Webcert. Detta ska ses som en nödlösning om det sker något oförutsett och ska därför inte göras regelbundet.

Signeringsansvarig - responsibleHospName

I dagsläget är Webcert utvecklat endast som en intygsutfärdande applikation och all process-/patient-/läkarhantering sker i journalsystemet.. Det finns dock i Webcert en parameter responsibleHospName som anger information om den HoS-person (Hälso- och sjukvårdspersonal) som är ansvarig för att signera intyget. Denna parameter används när det inte är samma person som skriver intygsutkastet och information om detta visas som ett separat fält på intyget. Detta gör att det blir synbart vem som är ansvarig intygsutfärdare på intygsutkast som ej är signerade.

För ett scenario där signeringsansvarig behöver ändras vid förnyandet av ett intyg, där till exempel det ursprungliga intyget signerats av en läkare som avslutat sin anställning fungerar det som följande; Tjänstekontraktet CertificateStatusUpdateForCare returnerar attributet skapadAv via objektet Intyg. SkapadAv innehåller den Hälso- och sjukvårdspersonal som har utfärdat intyget. Läs mer om skapadAV i Tjänstekontraktsbeskrivningen på rivta.se som beskriver hur detta attribut sätts vid skapande av intyg, redigering av intyg och signering av intyg. I version 6.4.0 av Webcert tillkom också parametern hanteratAv som också anger uppgifter om vilken hälso- och sjukvårdspersonal som hanterat intyget och givit upphov till en statusuppdatering. Detta anges för alla händelser som initieras av en person.

KopieringOK

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. Om parameter kopieringOK helt utelämnas i anropet så är det samma sak som kopieringOK = True, dvs det upp till journalsystemet att avgränsa om man ska få kopiera och om det får ske över vårdgivargränser. Om kopieringOK != True  (dvs False eller tomt eller något annat värde vilket som helst) så får man INTE kopiera

Förifyllnad från integrerat journalsystem

Här nedan samlar vi alla frågor och svar som inkommit i samband med integrationsarbetet mellan Webcert och olika journalsystemsleverantörer

 

• Från när kan man börja förifylla FK7804 från vårt integrerade journalsystem?
  Svar: Webcert fick detta stöd i december 2019. Respektive region/vårdgivare behöver sedan implementera möjligheten att förifylla detta intyg.
  Länk till sida som innehåller mer information: http://www.rivta.se/domains/clinicalprocess_healthcond_certificate.html

• Vad händer i Webcert om ni får information i createDraftCertificate som ska fylla i aktivitetsbegränsning och/eller funktionsnedsättning, men ingen diagnos?
  Svar: Information fylls i för aktivitetsbegränsning och/eller funktionsnedsättning. Eftersom ingen diagnosinformation ha angetts kommer varken FMB- eller ICF-stödet finnas tillgängligt initialt.

• Vad händer i Webcert om ni får information i createDraftCertificate om diagnos samt aktivitetsbegränsning och/eller funktionsnedsättning? Kommer det inbyggda stödet i Webcert (ICF-stödet) då skriva över den information ni får i taggen ang. aktivitetsbegränsning och/eller funktionsnedsättning?
  Svar: Nej, information för aktivitetsbegränsning och/eller funktionsnedsättning fylls i intygsfälten. ICF-stödet finns tillgängligt utöver det men kommer inte påverkar den förifyllda texten

• Fundering från vår sida kring attribut. I den nya schemafilen kunde jag inte se KeyName och instans. Är de också borttagna som attribut?
  Svar: Klargörs med exempel-XML:en, se nedan.

• Funderingar kring diagnoser i den nya ifyllnadstaggen i createDraftCertificate:
  -Vad är skillnaden på displayName och värdet i 6.1? Skriver något över det andra?
  -Var visas 6.1 samt displayName i Webcert?
  -Vad vill Webcert få av COSMIC här? Bör vi skicka båda två?
  -Behöver vi skicka displayName för andra kodade värden? Vad händer om det inte stämmer överens med de alternativ i Webcert som koden motsvarar?
  Svar: displayName i 6.2 håller kodens klartext i enlighet med kodverket, dvs. ICD-10 i detta fall. Om läkaren får för sig att ändra denna klartext i Webcert så skickas den ändrade texten i 6.1, i enlighet med informationsspecifikationen. 

Open

I Webcert fungerar det som följande (givet att läkaren fyller i intyget i Webcert utan förifyllnad):

1. Läkaren letar upp diagnosen och så visas kodens klartext, i enlighet med kodverket, upp i textfältet efter kodfältet à denna klartext skickas med i displayName i 6.2

   1. Open

      

2. Läkaren kan ändra klartexten. Den ändrade texten visas i samma fält men själva ändrade texten skickas via 6.1 (och den ursprungliga klartexten skickas fortfarande via displayName i 6.2)
   b.

3. cv:displayName är inte obligatoriskt enligt schemat, och displayName används inte heller till något i förifyllnaden. (cv:codeSystem och cv:code däremot är viktiga och används) 

   Uppfattningen är att man inte behöver skicka cv:displayName för 6.2 men däremot delsvar 6.1. När det gäller andra CV:typer gäller samma sak, i förifyllanden spelar displayName ingen roll vad vi kan se.

• Vad skulle hända om vi skickade överlappande datumperioder för sjukskrivningsperioden?
  Svar: Vi gör inga valideringar kring periodernas rimlighet när vi tar emot information från er. Eventuella felaktigheter visas av WC GUI och får rättas till. I nedanstående exempel mockade vår utvecklare dels en period med  startdatum > slutdatum , samt 2 överlappande perioder för att illustrera GUI-beteendet:

Rekommendation från oss är följande (som jag även har uppdaterat i anvisningen):

1. Om en följd av sjukskrivningsperioder med olika grader på nedsättning av arbetsförmågan är aktuell bör det skickas in nedsättningsgrad & kompletta sjukskrivningsperioder (med start- och slutdatum) som inte överlappar. Skickar man bara in nedsättningsgrader och inga perioder får samtliga startdatum satt till dagens datum (enligt fall-back hanteringen som är beskrivit i kolumnen bredvid) vilket gör att ifyllandsstödet för perioder inte fungerar så bra som vid manuell inmatning.

2. Om denna hantering inte kan tillgodoses bör det övervägas att enbart skicka en nedsättningsgrad som då får dagens datum som start som sedan kan kompletteras.

• Returneras det felmeddelanden för förifyllnadsuppgifter som inte validerar?
  Svar: Nej, det returneras inte felmeddelanden för förifyllnadsuppgifter som inte validerar. De förifyllnadsuppgifter som validerar kommer med i statusmeddelanden.

• Ett exempel-XML på hur ett anrop till CreateDraftCertificate kan se ut när det finns förifyllnadsdata med i anropet.
  Svar:

Här nedan samlar vi alla frågor och svar som inkommit i samband med integrationsarbetet mellan Webcert och olika journalsystemsleverantörer

• Från när kan man börja förifylla FK7804 från vårt integrerade journalsystem?
  Svar: Webcert fick detta stöd i december 2019. Respektive region/vårdgivare behöver sedan implementera möjligheten att förifylla detta intyg.
  Länk till sida som innehåller mer information: http://www.rivta.se/domains/clinicalprocess_healthcond_certificate.html

• Vad händer i Webcert om ni får information i createDraftCertificate som ska fylla i aktivitetsbegränsning och/eller funktionsnedsättning, men ingen diagnos?
  Svar: Information fylls i för aktivitetsbegränsning och/eller funktionsnedsättning. Eftersom ingen diagnosinformation ha angetts kommer varken FMB- eller ICF-stödet finnas tillgängligt initialt.

• Vad händer i Webcert om ni får information i createDraftCertificate om diagnos samt aktivitetsbegränsning och/eller funktionsnedsättning? Kommer det inbyggda stödet i Webcert (ICF-stödet) då skriva över den information ni får i taggen ang. aktivitetsbegränsning och/eller funktionsnedsättning?
  Svar: Nej, information för aktivitetsbegränsning och/eller funktionsnedsättning fylls i intygsfälten. ICF-stödet finns tillgängligt utöver det men kommer inte påverkar den förifyllda texten

• Fundering från vår sida kring attribut. I den nya schemafilen kunde jag inte se KeyName och instans. Är de också borttagna som attribut?
  Svar: Klargörs med exempel-XML:en, se nedan.

• Funderingar kring diagnoser i den nya ifyllnadstaggen i createDraftCertificate:
  -Vad är skillnaden på displayName och värdet i 6.1? Skriver något över det andra?
  -Var visas 6.1 samt displayName i Webcert?
  -Vad vill Webcert få av COSMIC här? Bör vi skicka båda två?
  -Behöver vi skicka displayName för andra kodade värden? Vad händer om det inte stämmer överens med de alternativ i Webcert som koden motsvarar?
  Svar: displayName i 6.2 håller kodens klartext i enlighet med kodverket, dvs. ICD-10 i detta fall. Om läkaren får för sig att ändra denna klartext i Webcert så skickas den ändrade texten i 6.1, i enlighet med informationsspecifikationen. 

I Webcert funkar det som följande (givit att läkaren fyller i intyget i Webcert utan förifyllnad):

1. Läkaren letar upp diagnosen och så visas kodens klartext, i enlighet med kodverket, upp i textfältet efter kodfältet à denna klartext skickas med i displayName i 6.2

2. Läkaren kan ändra klartexten. Den ändrade texten visas i samma fält men själva ändrade texten skickas via 6.1 (och den ursprungliga klartexten skickas fortfarande via displayName i 6.2)
   b.

3. cv:displayName är inte obligatoriskt enligt schemat, och displayName används inte heller till något i förifyllnaden. (cv:codeSystem och cv:code däremot är viktiga och används) 

   Uppfattningen är att man inte behöver skicka cv:displayName för 6.2 men däremot delsvar 6.1. När det gäller andra CV:typer gäller samma sak, i förifyllanden spelar displayName ingen roll vad vi kan se.

• Vad skulle hända om vi skickade överlappande datumperioder för sjukskrivningsperioden?
  Svar: Vi gör inga valideringar kring periodernas rimlighet när vi tar emot information från er. Eventuella felaktigheter visas av WC GUI och får rättas till. I nedanstående exempel mockade vår utvecklare dels en period med  startdatum > slutdatum , samt 2 överlappande perioder för att illustrera GUI-beteendet:

Rekommendation från oss är följande (som jag även har uppdaterat i anvisningen):

1. Om en följd av sjukskrivningsperioder med olika grader på nedsättning av arbetsförmågan är aktuell bör det skickas in nedsättningsgrad & kompletta sjukskrivningsperioder (med start- och slutdatum) som inte överlappar. Skickar man bara in nedsättningsgrader och inga perioder får samtliga startdatum satt till dagens datum (enligt fall-back hanteringen som är beskrivit i kolumnen bredvid) vilket gör att ifyllandsstödet för perioder inte fungerar så bra som vid manuell inmatning.

2. Om denna hantering inte kan tillgodoses bör det övervägas att enbart skicka en nedsättningsgrad som då får dagens datum som start som sedan kan kompletteras.

• Returneras det felmeddelanden för förifyllnadsuppgifter som inte validerar?
  Svar: Nej, det returneras inte felmeddelanden för förifyllnadsuppgifter som inte validerar. De förifyllnadsuppgifter som validerar kommer med i statusmeddelanden.

• Ett exempel-XML på hur ett anrop till CreateDraftCertificate kan se ut när det finns förifyllnadsdata med i anropet.
  Svar:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"  xmlns:urn="urn:riv:itintegration:registry:1"  xmlns:urn1="urn:riv:clinicalprocess:healthcond:certificate:CreateDraftCertificateResponder:3"  xmlns:urn2="urn:riv:clinicalprocess:healthcond:certificate:types:3"  xmlns:urn3="urn:riv:clinicalprocess:healthcond:certificate:3"  xmlns:urn4="urn:riv:clinicalprocess:healthcond:certificate:3.2"  xmlns:urn5="urn:riv:clinicalprocess:healthcond:certificate:3.3">    <soapenv:Header>       <urn:LogicalAddress></urn:LogicalAddress>    </soapenv:Header>    <soapenv:Body>  <urn1:CreateDraftCertificate xmlns:urn="urn:riv:itintegration:registry:1"     xmlns:urn1="urn:riv:clinicalprocess:healthcond:certificate:CreateDraftCertificateResponder:3"     xmlns:urn2="urn:riv:clinicalprocess:healthcond:certificate:types:3"     xmlns:urn3="urn:riv:clinicalprocess:healthcond:certificate:3"     xmlns:urn5="urn:riv:clinicalprocess:healthcond:certificate:3.3">   <urn1:intyg>     <urn1:typAvIntyg>       <urn2:code>LISJP</urn2:code>       <urn2:codeSystem>b64ea353-e8f6-4832-b563-fc7d46f29548</urn2:codeSystem>     </urn1:typAvIntyg>     <urn1:patient>       <urn3:person-id>         <urn2:root>1.2.752.129.2.1.3.1</urn2:root>         <urn2:extension>191212121212</urn2:extension>       </urn3:person-id>       <urn3:fornamn>Per</urn3:fornamn>       <urn3:efternamn>Persson</urn3:efternamn>       <!--Optional:-->       <urn3:mellannamn>Svensson</urn3:mellannamn>       <urn3:postadress>Torsgatan 18</urn3:postadress>       <urn3:postnummer>Torsbyn</urn3:postnummer>       <urn3:postort>24680</urn3:postort>     </urn1:patient>     <urn1:skapadAv>       <urn1:personal-id>         <urn2:root>1.2.752.129.2.1.4.1</urn2:root>         <urn2:extension>SE4815162344-1B01</urn2:extension>       </urn1:personal-id>       <urn1:fullstandigtNamn>Ivar Integration</urn1:fullstandigtNamn>       <urn1:enhet>         <urn1:enhets-id>           <urn2:root>1.2.752.129.2.1.4.1</urn2:root>           <urn2:extension>SE4815162344-1A02</urn2:extension>         </urn1:enhets-id>         <urn1:enhetsnamn>WebCert-Integration Enhet 1</urn1:enhetsnamn>       </urn1:enhet>     </urn1:skapadAv>     <urn1:ref>journal-system-referens</urn1:ref>     <urn5:forifyllnad>       <urn5:svar id="27">         <urn3:delsvar id="27.1">false</urn3:delsvar>       </urn5:svar>       <urn5:svar id="1">         <urn3:instans>1</urn3:instans>         <urn3:delsvar id="1.1">           <urn2:cv>             <urn2:code>UNDERSOKNING</urn2:code>             <urn2:codeSystem>KV_FKMU_0001</urn2:codeSystem>             <urn2:displayName>Min undersökning av patienten</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="1.2">2017-05-26</urn3:delsvar>       </urn5:svar>       <urn5:svar id="1">         <urn3:instans>2</urn3:instans>         <urn3:delsvar id="1.1">           <urn2:cv>             <urn2:code>TELEFONKONTAKT</urn2:code>             <urn2:codeSystem>KV_FKMU_0001</urn2:codeSystem>             <urn2:displayName>Min telefonkontakt med patienten</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="1.2">2017-05-26</urn3:delsvar>       </urn5:svar>       <urn5:svar id="1">         <urn3:instans>3</urn3:instans>         <urn3:delsvar id="1.1">           <urn2:cv>             <urn2:code>JOURNALUPPGIFTER</urn2:code>             <urn2:codeSystem>KV_FKMU_0001</urn2:codeSystem>             <urn2:displayName>Journaluppgifter från den</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="1.2">2017-05-26</urn3:delsvar>       </urn5:svar>       <urn5:svar id="1">         <urn3:instans>4</urn3:instans>         <urn3:delsvar id="1.1">           <urn2:cv>             <urn2:code>ANNAT</urn2:code>             <urn2:codeSystem>KV_FKMU_0001</urn2:codeSystem>             <urn2:displayName>Annat</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="1.2">2017-05-26</urn3:delsvar>         <urn3:delsvar id="1.3">baserat på annat</urn3:delsvar>       </urn5:svar>       <urn5:svar id="28">         <urn3:instans>1</urn3:instans>         <urn3:delsvar id="28.1">           <urn2:cv>             <urn2:code>NUVARANDE_ARBETE</urn2:code>             <urn2:codeSystem>KV_FKMU_0002</urn2:codeSystem>             <urn2:displayName>Nuvarande arbete</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="28">         <urn3:instans>2</urn3:instans>         <urn3:delsvar id="28.1">           <urn2:cv>             <urn2:code>ARBETSSOKANDE</urn2:code>             <urn2:codeSystem>KV_FKMU_0002</urn2:codeSystem>             <urn2:displayName>Arbetssökande</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="28">         <urn3:instans>3</urn3:instans>         <urn3:delsvar id="28.1">           <urn2:cv>             <urn2:code>FORALDRALEDIG</urn2:code>             <urn2:codeSystem>KV_FKMU_0002</urn2:codeSystem>             <urn2:displayName>Föräldraledighet för vård av barn</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="28">         <urn3:instans>4</urn3:instans>         <urn3:delsvar id="28.1">           <urn2:cv>             <urn2:code>STUDIER</urn2:code>             <urn2:codeSystem>KV_FKMU_0002</urn2:codeSystem>             <urn2:displayName>Studier</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="29">         <urn3:delsvar id="29.1">Ett yrke med arbetsuppgifter</urn3:delsvar>       </urn5:svar>       <urn5:svar id="6">         <urn3:delsvar id="6.2">           <urn2:cv>             <urn2:code>J22</urn2:code>             <urn2:codeSystem>1.2.752.116.1.1.1.1.3</urn2:codeSystem>             <urn2:displayName>Icke specificerad akut infektion i nedre luftvägarna</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="6.1">Läkares egna inofficiella diagnosbeskrivning</urn3:delsvar>         <urn3:delsvar id="6.4">           <urn2:cv>             <urn2:code>M46</urn2:code>             <urn2:codeSystem>1.2.752.116.1.1.1.1.3</urn2:codeSystem>             <urn2:displayName>Andra inflammatoriska sjukdomar i ryggraden</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="6.3">Andra inflammatoriska sjukdomar i ryggraden</urn3:delsvar>         <urn3:delsvar id="6.6">           <urn2:cv>             <urn2:code>S22</urn2:code>             <urn2:codeSystem>1.2.752.116.1.1.1.1.3</urn2:codeSystem>             <urn2:displayName>Fraktur på revben, bröstbenet och bröstkotpelaren</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="6.5">Fraktur på revben, bröstbenet och bröstkotpelaren</urn3:delsvar>       </urn5:svar>       <urn5:svar id="35">         <urn3:delsvar id="35.1">Funktionell nedsättningen</urn3:delsvar>       </urn5:svar>       <urn5:svar id="17">         <urn3:delsvar id="17.1">Begränsning i aktiviteten</urn3:delsvar>       </urn5:svar>       <urn5:svar id="19">         <urn3:delsvar id="19.1">En pågående behandling</urn3:delsvar>       </urn5:svar>       <urn5:svar id="20">         <urn3:delsvar id="20.1">En planerad behandling</urn3:delsvar>       </urn5:svar>       <urn5:svar id="32">         <urn3:instans>1</urn3:instans>         <urn3:delsvar id="32.1">           <urn2:cv>             <urn2:code>HELT_NEDSATT</urn2:code>             <urn2:codeSystem>KV_FKMU_0003</urn2:codeSystem>             <urn2:displayName>100%</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="32.2">           <urn2:datePeriod>             <urn2:start>2017-06-19</urn2:start>             <urn2:end>2017-07-10</urn2:end>           </urn2:datePeriod>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="32">         <urn3:instans>2</urn3:instans>         <urn3:delsvar id="32.1">           <urn2:cv>             <urn2:code>TRE_FJARDEDEL</urn2:code>             <urn2:codeSystem>KV_FKMU_0003</urn2:codeSystem>             <urn2:displayName>75%</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="32.2">           <urn2:datePeriod>             <urn2:start>2017-05-28</urn2:start>             <urn2:end>2017-06-18</urn2:end>           </urn2:datePeriod>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="32">         <urn3:instans>3</urn3:instans>         <urn3:delsvar id="32.1">           <urn2:cv>             <urn2:code>HALFTEN</urn2:code>             <urn2:codeSystem>KV_FKMU_0003</urn2:codeSystem>             <urn2:displayName>50%</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="32.2">           <urn2:datePeriod>             <urn2:start>2017-05-27</urn2:start>             <urn2:end>2017-05-27</urn2:end>           </urn2:datePeriod>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="32">         <urn3:instans>4</urn3:instans>         <urn3:delsvar id="32.1">           <urn2:cv>             <urn2:code>EN_FJARDEDEL</urn2:code>             <urn2:codeSystem>KV_FKMU_0003</urn2:codeSystem>             <urn2:displayName>25%</urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="32.2">           <urn2:datePeriod>             <urn2:start>2017-05-26</urn2:start>             <urn2:end>2017-05-26</urn2:end>           </urn2:datePeriod>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="37">         <urn3:delsvar id="37.1">Arbetsförmågan bedöms nedsatt en längre tid.</urn3:delsvar>       </urn5:svar>       <urn5:svar id="33">         <urn3:delsvar id="33.1">true</urn3:delsvar>         <urn3:delsvar id="33.2">Ett medicinskt skäl till annan förläggning</urn3:delsvar>       </urn5:svar>       <urn5:svar id="39">         <urn3:delsvar id="39.1">           <urn2:cv>             <urn2:code>ATER_X_ANTAL_DGR</urn2:code>             <urn2:codeSystem>KV_FKMU_0006</urn2:codeSystem>             <urn2:displayName>Patienten kommer med stor sannolikhet att återgå helt i nuvarande sysselsättning efter x antal dagar             </urn2:displayName>           </urn2:cv>         </urn3:delsvar>         <urn3:delsvar id="39.3">           <urn2:cv>             <urn2:code>NITTIO_DGR</urn2:code>             <urn2:codeSystem>KV_FKMU_0007</urn2:codeSystem>             <urn2:displayName>90 dagar</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>1</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>ARBETSTRANING</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Arbetsträning</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>2</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>ARBETSANPASSNING</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Arbetsanpassning</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>3</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>SOKA_NYTT_ARBETE</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Söka nytt arbete</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>4</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>BESOK_ARBETSPLATS</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Besök på arbetsplatsen</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>5</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>ERGONOMISK</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Ergonomisk bedömning</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>6</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>HJALPMEDEL</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Hjälpmedel</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>7</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>KONFLIKTHANTERING</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Konflikthantering</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>8</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>KONTAKT_FHV</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Kontakt med företagshälsovård</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>9</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>OMFORDELNING</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Omfördelning av arbetsuppgifter</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="40">         <urn3:instans>10</urn3:instans>         <urn3:delsvar id="40.1">           <urn2:cv>             <urn2:code>OVRIGA_ATGARDER</urn2:code>             <urn2:codeSystem>KV_FKMU_0004</urn2:codeSystem>             <urn2:displayName>Övrigt</urn2:displayName>           </urn2:cv>         </urn3:delsvar>       </urn5:svar>       <urn5:svar id="44">         <urn3:delsvar id="44.1">Övriga åtgärder finns</urn3:delsvar>       </urn5:svar>       <urn5:svar id="25">         <urn3:delsvar id="25.1">En del övrigt om patienten</urn3:delsvar>       </urn5:svar>       <urn5:svar id="26">         <urn3:delsvar id="26.1">true</urn3:delsvar>         <urn3:delsvar id="26.2">Gillar att prata i telefon</urn3:delsvar>       </urn5:svar>     </urn5:forifyllnad>   </urn1:intyg> </urn1:CreateDraftCertificate>    </soapenv:Body> </soapenv:Envelope>

Rehabstöd

Det visas patienter i sjukfallstabellen som inte är aktuella - sjukfall som har fått felaktigt slutdatum

Problem: Läkare har utfärdat ett Läkarintyg för sjukpenning och sjukskrev patienten i 50 år, hur tas intyget (sjukfallet) bort från sjukfallslistan?

• Om det gäller ett sjukintyg 7804 kan en behörig läkare ersätta intyget med ett nytt, som har korrekt slutdatum. Det första intyget kommer då inte visas i Rehabstöd.

• Gäller det ett äldre sjukintyg, 7263, behöver en läkare makulera det felaktiga intyget. Makulerade intyg visas inte i Rehabstöd.

Om läkaren som utfärdat intygen inte längre är aktiv på enheten kan en annan läkare på enheten utföra åtgärden. Läs mer här om hur intyg makuleras i Webcert

Om intyget har makulerats i journalsystemet men patienten ändå syns i Rehabstöd, så beror det på att intyget endast makulerats i journalsystemet och att det inte tagits bort i Intygstjänsten. Om detta sker behöver en läkare logga in i fristående Webcert och makulera intyget där. Det fungerar även om Vårdgivaren har begärt att användare ska blockeras från att utfärda nya intyg i fristående Webcert.

Obs! Inera är endast personuppgiftsbiträden och kan inte ta bort felaktiga intyg mer än i undantagsfall, t ex då ett journalsystem inte längre finns.

Problem att se ingående enheter vid inloggning

Direkt efter inloggning får de användare som har tillgång till flera enheter/vårdgivare upp en vy där de olika vårdenheterna listas. I figuren nedan kan man se att vårdenheterna tillhörande nmt_vg1 har en "nedåtpil" framför sig. Det menas att de har underliggande/ingående enheter. Klickar man på "nedåtpilen" visas den ingående enheten. Vårdenheterna under Rehabstöd-Vårdgivare1 har inga ingående enheter. 

Om en webbläsare som inte stödjer nedladdning av figurer (fonter) används kan i vissa fall "nedåtpilarna" försvinna. Lösningen på problemet kan vara att använda Rehabstöd i en annan webbläsare, förslagsvis Internet Explorer. 

Går det att ta fram en lista med sjukfall från tidigare år?

Det finns ingen möjlighet i Rehabstöd att extrahera historisk data.

Rehabstöd visar endast pågående sjukfall i sjukfallstabellen samt Läkarutlåtanden som utfärdats de tre senaste åren.

Hantering av namn och skyddade personuppgifter

I och med att intyg kan skrivas för invånare med skyddade personuppgifter hämtas patientens namn och eventuella skyddade personuppgifter från Personuppgiftstjänsten. Läkare som är inloggade på den enhet intyget utfärdades kommer att se patienter med skyddade personuppgifter men patientens namn ersätts med frasen ”Skyddad personuppgift”. Rehabkoordinator kan inte se patienter med skyddade personuppgifter.

Dölj personuppgifter i sjukfallstabellen

I sjukfallstabellen kan patientens personuppgifter döljas genom att avmarkera rutan “Visa personuppgifter”. Det kan vara användbart om man vill visa upp och diskutera sjukfallen i grupp. Det är även möjligt att välja så patientens personuppgifter inte alls presenteras i sjukfallstabellen genom att anpassa vilka kolumner som ska visas, detta gör man genom att använda funktionen “Anpassa tabellen”.  

Läkares HSA-Id visas istället för namn

Läkarens namn hämtas från HSA katalogen. Om det inte går att slå upp läkaren i HSA katalogen visas bara HSA-Id. Det gäller även att om det finns två läkare med samma namn visas läkarnas HSA-Id istället.

Vilka behörigheter finns i Rehabstöd

Läkare: En användare definieras som läkare i Rehabstöd om det i HSA går att styrka att användaren tillhör den legitimerade yrkesgruppen Läkare, har befattningskoden 204010 eller har någon av befattningskoderna 203090 och 204090 i kombination med vissa förskrivarkoder

Rehabkoordinator: En användare som har medarbetaruppdrag med ändamål ”Vård och behandling” i HSA samt hsaSystemRole på enheten (behövs MU + hsaSystemRole för alla enheter) definieras som Rehabkoordinator.

Läs mer behörigheter i Rehabstöds användarmanual: https://inera.atlassian.net/wiki/x/moiUG

Sjukfall saknas efter en omorganisation

Om sjukfall saknas efter en omorganisation bör den lokala HSA förvaltningen kontaktas för att kontrollera om det skett någon organisatorisk förändring i HSA strukturen och/eller för HSA-Id för enheten har ändrats.

Rehabstöd kontrollerar att intygen utfärdade på enheten tillhör den vårdgivare som finns angiven i HSA katalogen. Det vill säga en strikt VG kontroll. Om någon förändring skett kommer intygen inte att visas och felmeddelandet ”Det finns inga pågående sjukfall på enheten” kommer att visas. Felmeddelandet uppkommer i tjänsten eftersom de intyg som utfärdats på enheten har en annan angiven vårdgivare kopplat till sig i journalsystemet, än den som är angiven som vårdgivare i HSA katalogen . Rehabstöd betraktar då intygen som intyg från en annan vårdgivare.

• För att Rehabstöd ska visa upp sjukfall krävs att VE HSA id (journalsystem) + VG HSA id (journalsystem) = VE HSA id (HSA katalogen) + VG HSA id (HSA katalogen)   

För att enheten ska kunna använda Rehabstöd behövs därför en ändring så att korrekt HSA id skickas med intygen. Alla ändringar av HSAid i journalsystem ska genomföras enligt rutin tillsammans med en riskanalys.

Filterval är utgråade och går inte att använda

Om ett filter, t ex diagnos eller läkare, är grått och inte går att använda har du anpassat din tabell och valt att klicka ur den informationsmängden. Fälten kommer återigen bli valbara om du går in i “anpassa tabellen” och klickar i rutan alternativt väljer “Återställ” för att återställa till ursprungsinställningarna.

Intygsid - hur hittar jag det?

Alla intyget har försetts med ett unikt id - Intygsid. Att ha intygsid till hands underlättar väldigt mycket vid felsökning.

Du hittar intygsid längst ner på intyget. Det går att ta fram intygsid från Rehabstöd.

1. Klicka på patienten i sjukfallsvyn

2. Leta rätt på den rad för det intyg som du behöver intygsid för.

3. Längst till höger ser du en ruta “Visa intyg” klicka på den för att öppna intyget.

4. Scrolla allra längst ner - under adressinformation till enheten hittar du intygsid. Du kan markera, kopiera och klistra in det i ditt felärende/mail så slipper du skriva av alla siffror och bokstäver.

Validering i produktionsmiljö

Ineras produktionsmiljöer innehåller känsliga personuppgifter och omfattas av flera olika lagar och förordningar som ska se till att patienters och medarbetares integritet inte hotas. För validering i produktionsmiljö av system som är anslutna till Nationella tjänsteplattformen finns därför en anvisning som måste följas.

Anvisningen utgår ifrån Ineras riktlinjer för kvalitetssäkring och informationssäkerhet och ska ge en gemensam målbild för alla aktörer. Anvisningen består av ett huvuddokument som beskriver vad som gäller vid validering i produktionsmiljö samt en bilaga med valideringspersoner (testpersoner från Skatteverkets lista som enbart ska användas i produktionsmiljö). Valideringspersonerna är inlagda i Ineras Personuppgiftstjänstens produktionsmiljö så att validering i produktionsmiljö ska få respons från Personuppgiftstjänsten i det fall där en sådan koppling finns. De system som är kopplade till Skatteverkets Navet kommer inte att få träff på dessa valideringspersoner då de inte kommer att finnas inlagda i Navet.

Det är Ineras dotterbolag Nordic Medtest som ansvarar för anvisningarna. Länk till anvisningarna: https://nordicmedtest.atlassian.net/wiki/x/aeMJ

 Hantering av intyg utfärdade på valideringspersoner

• Intyg utfärdade på valideringspersoner är tillgängliga i samtliga vyer i Webcert men kan inte skickas till intygsmottagare. Därmed kan inte heller ärendekommunikation valideras.

• Intyg utfärdade på valideringspersoner visas inte i Mina intyg, Intygsstatistik eller Rehabstöd.

• Intyg utfärdade på valideringspersoner PDL-loggas inte.

• Intyg utfärdade på valideringspersoner gallras automatiskt bort då de är utfärdade för >=31 dagar sedan. De arkiveras inte utan raderas bort helt.

• Intygsförvaltningen kan följa upp dessa intyg loggar samt se vem som hanterat dem.

Aktivering av den nya Webcert-klienten (REACT)

Så länge inte alla regioner gått över till nya underskriftslösningen kommer den nya Webcert-klienten (REACT) inte aktiveras automatiskt. Varje region behöver därför beställa aktivering via den vanliga supportkanalen och bifoga en lista som innehåller HSA-ID för alla Vårdgivare inom regionen (både regionens egna och privata Vårdgivare med avtal med regionen). Därefter bestämmer vi ett lämpligt datum utifrån ordinarie release-schema. Det krävs en s.k. rullande omstart av Webcert för att aktiveringen ska slå igenom.