Vanliga frågor och svar
- 1 Problem att logga in
- 2 Krav på webbläsare
- 3 Problem med signering
- 4 Felanmälan och användarstöd
- 5 Webcert
- 5.1 Intygstyper i Webcert
- 5.2 Patientidentitet
- 5.3 Hantering av skyddade personuppgifter
- 5.4 Utfasning av läkarintyget ”FK7263”
- 5.5 Sammanhållen journalföring (SJF)
- 5.6 Arbetsgivarintyg (AG7804 och AG1-14)
- 5.7 Medarbetaruppdrag på nedlagd enhet
- 5.8 Automatiskt sparande
- 5.9 Makulera intyg
- 5.10 Nationella spärrtjänsten
- 5.11 Tjänstekontrakt och Parametrar
- 5.12 Förifyllnad från integrerat journalsystem
- 6 Rehabstöd
- 6.1 Det visas patienter i sjukfallstabellen som inte är aktuella - sjukfall som har fått felaktigt slutdatum
- 6.2 Problem att se ingående enheter vid inloggning
- 6.3 Går det att ta fram en lista med sjukfall från tidigare år?
- 6.4 Hantering av namn och skyddade personuppgifter
- 6.5 Vilka behörigheter finns i Rehabstöd
- 6.6 Sjukfall saknas efter en omorganisation
- 6.7 Filterval är utgråade och går inte att använda
- 6.8 Intygsid - hur hittar jag det?
- 7 Validering i produktionsmiljö
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 med ändamål Vård och behandling.
Rehabstöd - kräver inloggning med SITHS Medarbetaruppdrag med ändamål Vård och behandling samt om du är Rehabkoordinator en särskild roll hsaSystemRole. Läs mer här Mer om Rehabstödarchived
Intygsstatistik - kräver inloggning med SITHS, Medarbetaruppdrag med ändamål 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-kort 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 eller mobilt BankID. 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.
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
Den nya underskriftslösningen kräver att användaren har 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) medan 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
Intyg om tillfällig föräldrapenning
Intyg om graviditet
Läkarutlåtande för merkostnadsersättning
Läkarutlåtande för närståendepenning
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 skickas till Försäkringskassan.
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
Mellan vårdenheter eller mellan vårdgivare om sjf=true | Läkare och Tandläkare | Vårdadmin |
|---|---|---|
Utkast | Läsa | Läsa |
Låst utkast | Läsa, Kopiera | Läsa, Kopiera |
Signerat intyg | Läsa, förnya, läsa ärendekommunikation (ej skapa fråga eller svar) | Läsa, förnya, läsa ärendekommunikation (ej skapa fråga eller svar) |
Arbetsgivarintyg (AG7804 och AG1-14)
Skapa AG7804 utifrån FK7804
Webcert integrerat
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.
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
Fristående Webcert
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. I det signerade intyget kan funktionen “Skapa AG7804“ användas för att skapa ett intygsutkast.
För att detta ska vara möjligt krävs dock att vissa förutsättningar är på plats:
Användaren använder Webcert fristående
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
Anpassa intyg till arbetsgivare (AG-intygen) i 1177 intyg
Arbetsgivarintygen (AG1-14 och AG7804) ä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 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 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 Utfärda intyg | Hur tar jag bort ett intyg 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 är 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
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.htmlVad 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 textenFundering 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 fungerar det som följande (givet att läkaren fyller i intyget i Webcert utan förifyllnad):
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
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.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:
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) vilket gör att ifyllandsstödet för perioder inte fungerar så bra som vid manuell inmatning.
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/" <urn5:forifyllnad> <urn5:svar id="27"> |