Informationsutbyte med Intygstjänster

Integrerad intygsapplikation

Inledning

Med intygsapplikation menas en applikation som används för att skapa och signera intyg. Webcert är Intygstjänsters intygsapplikation. En fristående sådan applikation är en som inte ingår i Intygstjänster, vanligen utvecklad av en journalsystemsleverantör.

Intygsapplikationer, oavsett om de är fristående eller ej, används för att skapa intyg, arbeta med intygsutkast, samt för att signera intyg och skicka dem till Intygstjänsten. Intygstjänsten tar emot och lagrar signerade intyg, och kan skicka dem till intygsmottagare. Efter att ett intyg blivit signerat kan dess innehåll inte förändras.

Mer om förutsättningar för informationsutbyte kan läsas i dokumentet "Integration med Webcert".

Frågor från VAS och svar

Fråga: i intyget som levereras med statusmeddelanden så kan adressuppgifter vara tomma. Journalsystemet kan för närvarande inte ta emot intyg där uppgifterna är tomma. Hur ska detta hanteras?

Svar: journalsystemet ska anpassas så att statusmeddelanden kan hanteras även när adressuppgifter är tomma strängar. Tjänstekontraktsbeskrivningen, TKB, kommer att uppdateras med förtydligande



Fråga: i intyget som levereras med statusmeddelanden så kan versionsnummer vara tomt. Hur ska detta hanteras?

Svar: journalsystemet ska anpassas så att statusmeddelanden kan hanteras även när version består av tom sträng. Tjänstekontraktsbeskrivningen, TKB, kommer att uppdateras med förtydligande



Fråga: Webcert hanterar i dagsläget inte uthopp där adressparametrarna är tomma. Hur ska detta lösas?

Svar: Webcert kommer att anpassas så att tomma adressparametrar kan hanteras. Exakt hur detta löses kommer att beskrivas när lösningsförslag är framtaget och beslutat. Dokumentet "Integration med Webcert" kommer sannolikt att behöva uppdateras. Om journalsystemet skickar "dummyvärden" i de fall där namn eller adress saknas så kommer informationsrutor att visas i Webcert med information om att namn eller adress skiljer sig från motsvarande uppgifter i Ineras PU-tjänst. Detta inträffar om "dummyvärden" skickas innan Webcert har anpassats.

Fristående intygsapplikation

Inledning

Med intygsapplikation menas en applikation som används för att skapa och signera intyg. Webcert är Intygstjänsters intygsapplikation. En fristående sådan applikation är en som inte ingår i Intygstjänster, vanligen utvecklad av en journalsystemsleverantör.

Intygsapplikationer, oavsett om de är fristående eller ej, används för att skapa intyg, arbeta med intygsutkast, samt för att signera intyg och skicka dem till Intygstjänsten. Intygstjänsten tar emot och lagrar signerade intyg, och kan skicka dem till intygsmottagare. Efter att ett intyg blivit signerat kan dess innehåll inte förändras.

Hantering av signerade intyg

Signerade intyg kan hanteras av fristående Webcert efter att intygen lagrats hos Ineras Intygstjänst. Via fristående intygsapplikation eller Webcert kan sådana intyg förnyas, ersättas eller makuleras. Dessutom kan ärendekommunikation ske i form av frågor och svar mellan intygsutfärdare och intygens huvudmottagare. 

Ärendekommunikation

Ärendekommunikation

Meddelanden mellan intygsutfärdare och intygsmottagare benämns ofta ärendekommunikation. Sådan kommunikation kan ske via fristående intygsapplikation, om applikationen utvecklar sådan funktionaltet, men kan också ske via Webcert (antingen fristående eller integrerad med uthopp från journalsystem till Webcert, mer om detta kan läsas i dokumentet "Integration med Webcert"). Kompletteringsfråga från Försäkringskassan kan besvaras genom att ett nytt intyg skickas till Försäkringskassan.

Meddelanden från intygsmottagare till journalsystem:

  • Integrerat journalsystem som använt CreateDraftCertificate får information genom att anrop sker till journalsystemet via CertificateStatusUpdateForCare

  • Andra journalsystem får information om meddelande via e-postnotifiering. Intygstjänster försöker hämta vårdenhetens e-postadress via HSA, och skickar notifiering om e-postadressen finns

Meddelanden från journalsystem/inygsapplikation till intygsmottagare:

  • Integrerat journalsystem får information om att meddelande skickats via tjänstekontraktet CertificateStatusUpdateForCare

  • Om det skickas ett meddelande från fristående Webcert till huvudmottagare avseende ett intyg som har skapats i en fristående intygsapplikation så skickas inget meddelande om detta till den fristående intygsapplikationen, men om applikationen implementerar tjänstekontraktet SendMessageToCare så kan de få information om att huvudmottagaren har svarat på meddelandet (se ovan).



Sekvensdiagram: meddelande från intygsmottagare till  intygsutfärdare



Sekvensdiagram: meddelande från intygsutfärdare till intygsmottagare



Ärendekommunikationsåtgärder

Det är inte alla ämnen som stödjs i tjänstekontraktet och som anges i kodverket, som bör implementeras i ärendekommunikationen. Följande ämnen är de som är implementerade i Webcert och därmed de som Försäkringskassan har godkänt för den upprättade ärendekommunikationen mellan dem och vården kring ett intyg i Webcert. Övriga ämnen finns det inte stöd för i mottagande system. 



Frågeställare

Ämne

FK

PAMINNELSE1

FK

OVRIGT

FK

KOMPLETTERING

FK

AVSTAMNINGSMOTE

FK

KONTAKT

FK

MAKULERING2

Vården

OVRIGT

Vården

AVSTAMNINGSMOTE

Vården

KONTAKT

Vården

MAKULERING*

1svar på påminnelser stöds inte i intygstjänsten och att svara på påminnelser bör förhindras, alt. peka på originalfrågan.

2 Ämne som endast kommuniceras mellan intygstjänsten och Försäkringskassan. Används i den gamla domänen, det vill säga insuranceprocess:healthreporting.

 

Tjänstekontraktsanvändning

Dessa tjänstekontrakt implementeras av Intygstjänsten och konsumeras av fristående intygsapplikation:

  • RegisterCertificate (skicka intyg till Intygstjänsten)

  • RevokeCertificate (makulera intyg hos Intygstjänsten)

  • SendCertificateToRecipient (skicka intyg till intygsmottagare via Intygstjänsten)

  • SendMessageToRecipient (skicka meddelande till intygsmottagare)

Tjänstekontraktet SendMessageToCare implementeras av intygsapplikationen så att den kan ta emot meddelanden från intygsmottagare via Intygstjänsten


Frågor från Cerner och svar

  1. Fråga: i informationsspecifikationerna står det att det är en begränsning på diagnostexter på 81 tecken. Hur ska texter som är längre än så hanteras? Ska de trunkeras?

    1. Svar: Försäkringskassan har fått den här frågan, och eftersom det är de som har ställt kravet, så det är lämpligt att ta kontakt med dem för att diskutera kravet och hur det bör implementeras för diagnostexter som överskrider kravställd maxlängd.

  2. Fråga: från TKB kap 6.4.3.4 ang dubletthantering: ” Om intyget redan skulle vara registrerat returnerar tjänsten information om detta med result.resultCode=”INFO”. Det betraktas således inte som ett fel.”. Innebär det att intyget skrivs över eller lämnas det orört?

    1. Svar: Det sparade intyget påverkas inte (skrivs INTE över)

  3. Fråga: från TKB kap 6.7.3.8: ”En fråga får endast besvaras en gång.”. Det är oklart vad som definierar en fråga och ett svar. Kan man fortsätta en meddelande tråd genom att svara på ett svar (enligt definitionen att ett svar är ett meddelande som pekar på ett annat meddelande)?

    1. Svar: Nej, meddelandetrådarna stannar vid en fråga och ett svar. 

  4. Fråga: enhetsnamn, postadress mfl är obligatoriska, men är det OK att skicka in tomma strängar? (De är inte definierade med typen nonEmptyString). Denna typ av information kan vara ganska bristfällig, så frågan är hur fälten ska hanteras om t.ex. telefonnummer till enheten saknas. Får tomma fält skickas?

    1. Svar: Försäkringskassan har fått den här frågan

  5. Fråga: hur kommer det ”gamla” sättet att föra administrativ dialog att fungera då man går igång med de nya intygen och kontrakten? T.ex. så kan man ju tänka sig att FK skickar en begäran om komplettering på ett FK7263, kommer detta att ske via det nya tjänstekontraktet eller på det gamla sättet?

    1. Svar: Med stor sannolikhet så kommer Försäkringskassan att ställa frågor om FK7263 via ReceiveMedicalQuestion och för de nya intygen (SMI-intygen) så används troligen SendMessageToCare. Det kommer inte att fungera att skicka meddelanden avseende FK7263-intyg via SendMessageToCare

  6. Fråga: hittills har inte resultcode INFO (TKB kap 7.6) visat sig vara tillämpligt. Finns några riktlinjer för när detta ska användas?

    1. Svar: I TKB 7.6.1.1 står följande: "Transaktionen har utförts enligt begäran, men det finns ett meddelande som konsumenten bör visa upp". Detta ska betraktas som riktlinje för användning av INFO.