INFORMATIONSÖVERFÖRING FRÅN PRIVATPRAKTISERANDE VÅRDGIVARE

STOCKHOLM LÄNS LANDSTING INFORMATIONSÖVERFÖRING FRÅN PRIVATPRAKTISERANDE VÅRDGIVARE VERSION: 3.5 DATUM: 2012-04-11

Beskrivning av kassafil 2012-04-11 Sid: 2 (13) INNEHÅLLSFÖRTECKNING 1 INLEDNING... 3 1.1 FÖRÄNDRINGAR FRÅN UTGÅVA 2.4 TILL 2.5... 3 1.2 FÖRÄNDRINGAR SEDAN FÖREGÅENDE UTGÅVA AV DOKUMENTET (2.5)... 3 2 ELEKTRONISKA MEDDELANDEN OCH DATAKOMMUNIKATION... 3 2.1 ÖVERFÖRING MED HJÄLP AV DISKETT ( UTGICK 2006 03 16 )... 3 2.2 DATAKOMMUNIKATION... 3 3 EDI-KONVERTERING... 4 4 SÄKERHET... 4 5 EDI-KUVERT... 5 5.1 FORMAT PÅ EDI-KUVERT.... 5 5.2 EXEMPEL PÅ EDI-KUVERT.... 5 6 FILFORMAT KASSARAPPORT.... 6 6.1 BESKRIVNING AV INGÅENDE DELAR I KASSARAPPORT.... 7 6.2 EXEMPEL PÅ KASSAFIL. (INKLUSIVE EDI-KUVERT)... 8 7 ÖVRIGA KRAV PÅ APPLIKATIONEN... 9 7.1 RÄTTNINGSPOSTER... 9 7.2 FUNKTIONALITET... 9 8 DETALJERAD BESKRIVNING AV INFORMATIONSINNEHÅLLET... 11

Beskrivning av kassafil 2012-04-11 Sid: 3 (13) 1 Inledning Detta dokument beskriver teknisk lösning och krav på system som skall sända räkningar till Stockholms läns landstings uppföljningssystem för privata vårdgivare (ARV). Målet för lösningen är att kunna sända elektronisk information av vårdkvitton med hjälp av EDI hos den privata vårdgivaren utan att införa nya tidskrävande rutiner för den privata vårdgivaren. I tidigare rutiner hanterades allt manuellt med papperskvitton. Dessa papper kommer inte att behövas med denna lösning. Grunden för att kunna skicka sina vårdgivarkvitton elektroniskt är att den privata vårdgivaren har ett lokalt system som hanterar sjukvårdskvitton (kassaprogram). Detta system införskaffas oftast från en produktleverantör och är ofta sammankopplat med program för journal och tidbokningssystem. För att klara att skicka räkningarna elektroniskt måste programmet ha funktioner för att kunna skapa en EDI-fil. 1.1 Förändringar från utgåva 2.4 till 2.5 Filformat skall vara 2 (Filformat 1 utgår som valmöjlighet) Direkt kommunikation med modem till ARV upphörde 1999-12-31 Fr.o.m. våren 2001 kan vårdgivare sända filer via ARV-portalen på Internet 1.2 Förändringar sedan föregående utgåva av dokumentet (2.5) Utökade krav på leverantörssystem 2 Elektroniska meddelanden och datakommunikation För att alla olika system som finns hos de privata vårdgivarna skall kunna ge information på samma format så används ett standardiserat sätt att skicka informationen. Informationen skall vara förpackat enligt ett för ARV godkänt Fil-format. Denna information kan sedan överföras från lokal applikation till ARV på olika sätt: Via ARV-portalen på Internet eller med hjälp av diskett. 2.1 Överföring med hjälp av diskett ( Utgick 2006 03 16 ) För överföring med diskett förpackas kassainformationen enligt given formatbeskrivning på 3½ diskett och skickas in på samma sätt och till samma adress som används för papperskvitton. 2.2 Datakommunikation För att kunna skicka informationen från den lokala applikationen hos den privata vårdgivaren behövs det en Internetanslutning och en webbläsare. Internet Explorer version 5 eller senare rekomenderas. Användaren kan då via ARV-portalen läsa in sina kvittofiler. Adressen till ARV-portalen är https://arvportal.sll.se. ARV-portalen tar emot en fil som är formaterad enligt givet filformat och tar hand om både kommunikation samt kryptering och signering utan extra säkerhetsprogramvara.

Beskrivning av kassafil 2012-04-11 Sid: 4 (13) 3 EDI-Konvertering De vårdsystem (kassamodul) som finns hos vårdgivarna ser olika ut och har olika sätt att få ut information ur systemet. För att informationen skall se likadant ut från alla olika vårdsystem så är det bestämt ett standardformat för den information som skall komma från systemen. För att kunna skapa detta Fil-format måste man ibland göra en konvertering av sin information till standardformatet. Antingen skapas formatet direkt eller så används ett konverteringsprogram i datorn. Detta konverteringsprogram måste då anpassas till aktuell vårdgivarapplikation. Samma konverteringsprogram kan sedan användas för att konvertering av information till andra system, då dessa också använder sig av EDI. Exempel på detta är remiss-svar från lab, elektroniska recept till Apotek, mm. Aktuellt dataformat för ARV finns beskrivet senare i detta dokument. 4 Säkerhet Ett av de viktigaste kraven på ARV-systemet är att det skall hålla en hög säkerhetsnivå. Detta innebär för lokala system ute hos privata vårdgivaren att information som skickas i väg skall vara skyddat mot insyn på ett speciellt sätt (kryptering), att man kan garanterat veta vem som har skickat informationen (elektronisk signering). Förbindelse med ARV-portalen är säkrad med hjälp av SSL.

Beskrivning av kassafil 2012-04-11 Sid: 5 (13) 5 EDI-kuvert För att EDI-filerna skall kunna skickas till rätt mottagare så skall EDI-filen ha ett EDI-kuvert runt informationen. EDI-kuvertet följer EDI-standarden EDIFACT och gäller som standard för sjukvården i Sverige. 5.1 Format på EDI-kuvert. Början av meddelandet: UNA:+,? UNB+SyntaxId:SyntaxVersion+SLLOrgnr:30:SändarID+SLLOrgnr:30: MottagarId+Sändningsdatum:SändningsTid+UnikÖverföringId++MeddelandeTyp --- (Innehåll enligt filformat kassarapport) --- Slutet av meddelandet: UNZ+AntalMeddelanden+UnikÖverföringsId 5.2 Exempel på EDI-kuvert. EDI-kuvertet har samma struktur oavsett vilket filformat som används för kassainformationen. UNA:+,? UNB+UNOC:2+00072321000016:30:K10013101M01+00072321000016:30: S7010+950510:1310+SGX12100000024++SLLPVR --- --- --- (Innehåll enligt filformat kassarapport) --- --- --- UNZ+1+SGX12100000024 I exemplet ovan är Fetstilmarkerade fält sådana som är unika och skapas av applikationen vid varje överföring. Understruket fält anger avsändaren av meddelandet. Dvs KOMBIKAkoden för den privata vårdgivarens huvudpraktik, inledd med ett stort K. Alla alfatecken skall vara versaler.

Beskrivning av kassafil 2012-04-11 Sid: 6 (13) 6 Filformat kassarapport. Detta avsnitt beskriver informationsinnehåll och den formattypen (formattyp 2) som är godkänd att skicka från lokala vårdapplikationer till ARV-systemet inom SLL. ARV tar emot EDI-filer som paketeras enligt filformat 2 som beskrivs i detta dokument. Formattyp 1 som tidigare även fanns supportas ej längre. EDI-Kuvert skall användas omkring det beskrivna filformatet. Säkerheten hanteras av SSL och certifikat. Informationen i meddelandet separeras av olika rubriker. Under varje rubrik återfinns data tillhörande rubriken. Nedan följer en översikt för innehållet. UNH M 1 Meddelandehuvud BSK M 1..99999 Besöksinformation ATG M 1 Åtgärdsrad DIA C 0..99 Diagnosrad REM C 0..99 Remissrad M x..y C x..y M: Mandatory (obligatorisk) x..y: Förekommer minst y och högst x antal gånger. C: Conditional (kan förekomma) x..y: Kan förekomma, minst y och högst x antal gånger. Meddelande Struktur: UNH (M 1) BSK (M 1..99999) ATG (M 1) DIA (C 0..99) REM (C 0..99) UNT (M 1) En överföring kan innehålla 1 till 99999 besök. Varje besök skall sedan innehålla en åtgärd, upp till 99 diagnoser och upp till 99 remissmottagare, alla var och en för sig inom ett besök.

Beskrivning av kassafil 2012-04-11 Sid: 7 (13) 6.1 Beskrivning av ingående delar i kassarapport. Rubrik återfinns på rad 1 och informationen om denna rubrik på raden under i form av fasta positioner. Om en rubrik är obligatorisk (Mandatory, M ) måste information finnas om denna. Om en rubrik är valfri (conditional, C ) och information saknas för denna, utelämnas rubriken helt. Om ett fältnamn i en rubrik är conditional i en rubrik och informationen saknas för denna, skall detta fält fyllas ut med blanka. Om informationen i ett fält inte utnyttjar alla positioner skall informationen vara vänsterjusterat (gäller för fält med variabla längder, ex an..14 ). Alla alfatecken skall vara versaler. Alla fält förklaras mer ingående i kapitel 8. Rubrik Fältnamn Obl Längd Position Kommentar UNH Medd_ref_nr M an..14 1-14 Unik per medd. Medd_Typ M an..6 15-20 Skall vara SLLPVR Medd_version M an..3 21-23 Skall vara = 1 Medd_release M an..3 24-26 Skall vara = 2 Kontrollorgan M an..2 27-28 Skall vara = ZZ BSK Posttyp M n1 1 Utf_enhet M an11 2-12 KOMBIKA-kod Vikarie C n5 13-17 Vikariekod KvittoNr M n8 18-25 Skatteform M an1 26 F eller A-skatt IdNummer C n12 27-38 Pnr IdTyp C an1 39 IdMarkör Födelsedatum C n6 40-45 ÅÅMMDD Besöksdatum M n6 46-51 ÅÅMMDD Besökstyp M n1 52 Akut M n1 53 Taxa M n2 54-55 Smittskydd C n1 56 RemissFrån C an11 57-67 KOMBIKA-kod RemissDatum C n6 68-73 YYMMDD ATG Åtgärd M an..4 1-4 Medicinsk åtgärd DIA Diagnos C an..5 1-5 ICD10-kod REM RemissTill C an2 1-5 Remiss till UNT SegmentAntal M n..6 1-6 Antal Rubriker Medd_ref_nr M an..14 7-20 Samma som i UNH

Beskrivning av kassafil 2012-04-11 Sid: 8 (13) 6.2 Exempel på kassafil. (inklusive EDI-kuvert) Exempel på fil med rubrik på rad och informationen om denna rubrik i fasta positioner på raden under. Rad 1 UNA:+,? UNB+UNOC:2+00072321000016:30:K10013101M01+ 00072321000016:30:S7010+950510:1310+SGX12100000024++SLLPVR Rad 2 UNH Rad 3 SGX12100000024SLLPVR1 2 ZZ Rad 4 BSK Rad 5 110013101M01 00000371F191212121212P 95050312010 Rad 6 ATG Rad 7 S331 Rad 8 BSK Rad 9 110013101M019367800000372F191111111114P 95050301010 Rad 10 ATG Rad 11 S316 Rad 12 REM Rad 13 03 Rad 14 UNT Rad 15 7 SGX12100000024 Rad 16 UNZ+1+SGX12100000024 Exemplet visar en överföring med två patientbesök, 2:a besöket med en remiss till röntgen samt utfört av vikarie 93678. Efter varje rad skall radbrytning förekomma: ( <CR>, <LF> )

Beskrivning av kassafil 2012-04-11 Sid: 9 (13) 7 Övriga krav på applikationen Ett antal övriga krav finns även på den applikation som skapar EDI-filen. 7.1 Rättningsposter När ett besök har inrapporterats till ARV kan det av olika orsaker blivit fel i informationen. Fall 1: ARV har en mängd kontrollfunktioner som utförs på besöksposterna som inkommer. Om dessa kontroller får fram att besöket av någon anledning inte är godkänt, exempelvis felaktigt personnummer, felaktig taxekod eller åtgärdskod så kommer ARV att generera en fellista ut till den privata vårdgivaren. Denna fellista kommer att ange vilket besök som är felaktigt och på vilket sätt den är felaktig. Besöket anges med besöksdatum+kvittonummer (vilket alltså måste vara en unik kombination). Personnummer på patienten kan ej ges i denna rapport då patientinformationen i ARV-datorn är avidentifierad (personnumret krypterat) Dessa felaktiga besök lagras ej vidare i ARV-systemets databas. Utifrån denna felrapport kan sedan vårdgivaren skicka om informationen efter att denna har rättats. Samma besöksdatum och kvittonummer skall användas (med posttyp 1). Fall 2: Om ett besök helt korrekt har godkänts in i ARV-systemet och lagrats i databasen samt även utbetalats till vårdgivaren kan ett besök senare ändå visa sig vara föremål för korrigering. Om exempelvis en patient vid ett besök glömt bort sitt frikort (vilket han senare kommer på), eller ett besök har helt enkelt registrerats på fel personnummer. Från ett vårdgivarsystem finns då möjligheten att korrigera detta med hjälp av en makuleringstransaktion (posttyp 2) + ett rättat nytt besök. En makuleringpost måste användas för att den ekonomiska bokföringen skall bli korrekt (och även generera ekonomiska korrigeringsbetalningar till vårdgivaren). En besökspost med exakt samma utseende som den tidigare felaktigt insända skickas alltså med posttyp 2 och en ny korrekt skickas med posttyp 1 (med nytt kvittonummer från samma serie löpnummer som används för nya kvitto). 7.2 Funktionalitet Användaren av applikationen skall själv kunna administrera sina åtgärdskoder. Ex lägga till och ta bort åtgärdskoder som används av applikationen. Användaren skall kunna se den ev. underliggande kod som applikationen använder vid överföringen. Detta för att underlätta användarens kommunikation med ARVsektionen vid problem med överföringen. Ex. Vid besök där patienten har frikort används taxekod 06 vid överföringen. Användaren skall i detta fallet kunna se att taxekod 06 användes vid överföringen. En kontroll skall göras av applikationen att checksiffra på angivet personnummer är korrekt. (modulo-10) Besöksdatum skall kunna väljas bakåt i tiden. Rekomenderat är att ha dagens datum som standardvärde. Om remiss från fältet är ifyllt skall även remissdatum vara ifyllt. Om remissdatum fältet är ifyllt skall även remiss från vara ifyllt.

Beskrivning av kassafil 2012-04-11 Sid: 10 (13) Applikationen skall kunna hantera patienter födda på 1800-, 1900- och 2000-talet. Applikationen skall ha en spärr som begränsar antal besök per fil till max 500 st. Denna spärr bör enkelt kunna ändras till annat antal då ändringar kan komma att ske.

Beskrivning av kassafil 2012-04-11 Sid: 11 (13) 8 Detaljerad beskrivning av informationsinnehållet Nedan följer en detaljerad beskrivning av informationen uppdelat på de olika rubrikerna. Under varje rubrik finns en förklaring på hur informationen skall tolkas. Alla alfatecken skall vara versaler. Rubrik: UNH (M 1) Fältnamn M/C Förklaring Medd_ref_nr M an..14 Unikt genererat Idnummer för varje meddelande. Skall vara unikt inom en tidsperiod av 1 år. Får vara samma Id som används i kuvertet (UNB). De tre första tecknen skall vara alfanumeriska och ge referens till vilken applikation som används lokalt. Nästföljande tre tecken ger version av applikationen. (Exempel: SGX12100000024 för en SGX-rapportering med version 1.21 för SGX) Medd_Typ M an..6 Talar om vilket EDI-meddelande som skickas. Skall för information från privata vårdgivare vara = SLLPVR Medd_version M an..3 Talar om vilken version av SLLPVR som används i denna överföring. Skall för denna version vara = 1 Medd_release M an..3 Talar om vilken releaseversion av SLLPVR som används i denna överföring. Används för att tala om vilket filformat som används. Skall vara = 2 för filformat 2 Kontrollorgan M an..2 Ansvarigt organ för detta meddelande. Skall vara = ZZ

Beskrivning av kassafil 2012-04-11 Sid: 12 (13) Rubrik: BSK (M 99999) Fältnamn M/C Förklaring Posttyp M n1 Anger om inrapporteringen är en nyregistering =1 eller en makulerad besökspost = 2 Utf_enhet M an11 Utförande enhets inrättningskod enligt KOMBIKAregistret Vikarie C n5 Skall anges om vikarie har utfört arbetet på annans etablering, annars skall det vara blankt. (5-siffrig inrättningskod enligt KOMBIKA-registret) KvittoNr M n..8 Löpnummer för aktuellt besök. Skall i kombination med besöksdatum vara unikt för varje besök. Besöksdatum+Kvittonummer används som referensnummer vid felrapportering från ARV. Upp till 8 siffror kan användas. Nummerserien skall börja från 1. När nummerserien når sitt tak, ex 99999999, börjar den om från 1 igen. Skatteform M an1 Anger om utföraren använder sig av A- eller F-skatt. A=A-skatt, F=F-skatt. Skall aktivt kunna ändras mellan inrapporteringstillfällena. IdNummer C n12 Svenskt personnummer enligt svensk standard: Exempel: 194303145376 (12 siffror med sekel) Vid smittskyddsmarkering får ej IdNummer skickas med. IdTyp C a1 Markering om IdNummer är personnummer. P=personnummer. Då smittskyddsmarkering är satt skall ej IdTyp användas, annars alltid. Födelsedatum C n6 Födelsedatum, anges då inte svenskt personnummer används. Behöver ej användas då riktigt personnummer finns. Vid smittskyddsmarkering får ej Födelsedatum skickas med. Besöksdatum M n6 Datum för patientbesöket. På formen ÅÅMMDD. Exempel: 950503 Besökstyp M n1 Anger typ av besök. Aktuella koder är följande: 0=Nybesök, 1=Återbesök Akut M n1 Anger om besöket är akut eller ej. Aktuella koder är följande: 0=Ej akutbesök, 1= Akutbesök Taxa M n2 Anger taxekoden för besöket i fråga. Kod enligt SLL s kodverk för taxor Smittskydd C n1 Anger om besöket är klassat enligt smittskyddslagen. 0=Ej smittskydd, 1=Smittskydd RemissFrån C an11 Remitterande enhets inrättningskod enligt KOMBIKAregistret RemissDatum C n6 Anger datum för remissen. Format ÅÅMMDD

Beskrivning av kassafil 2012-04-11 Sid: 13 (13) Rubrik: ATG (M 1) Fältnamn M/C Förklaring Åtgärd M an..4 Medicinsk åtgärd som är utförd. Vid kortare kod än 4 tecken skall de övriga vara vänsterjusterade Rubrik: DIA (C 99) Fältnamn M/C Förklaring Diagnos C an..5 Diagnoskod uttryckt med hjälp av en ICD10-kod. Rubrik: REM (C 99) Fältnamn M/C Förklaring RemissTill C an2 Anger typ av enhet som patienten har remitterats till. Rubrik: UNT (M 1) Fältnamn M/C Förklaring SegmentAntal M an..6 Anger antal segment (rubriker) som ingår i meddelandet. Medd_ref_nr M an..14 Unikt genererat Idnummer varje meddelande. Skall vara samma som i UNH