Systemöversikt SPOR. Svenskt PeriOperativt Register 2.0 KARL NYBERG, JOEL DAMBERG, TOMAS SNÄCKERSTRÖM, RODRIGO FUNES, JÖNS WEIMARCK

Transkript

1 Systemöversikt SPOR Svenskt PeriOperativt Register 2.0 KARL NYBERG, JOEL DAMBERG, TOMAS SNÄCKERSTRÖM, RODRIGO FUNES, JÖNS WEIMARCK

2 Innehållsförteckning 1. Inledning 4 2. Roller 5 3. Översikt över systemets funktioner Inloggning Min enhet Ingående nyckeltal och grafer Sök registrering Registreringsdetaljer Fellista Rapporter Filbaserad dataöverföring Överföringsstatistik Administrera operationskliniker Skapa/namnge kliniker administrera kliniker Godkänna salar och kliniker Administration av användaruppgifter Organisations- och lokalhierarkier Grundläggande organisationshierarki Datamodell Registreringsinformation Identifiering av sändande system (webservice) Registrerande operationsenhet (110) Behandlingsnummer (120) Uppgiftslämnare (130) Patientinformation Födelsedatum (220) Kön (230) Epostadress (240) Operationsanmälan Akut/elektiv (320) Akut planering (325) Funktionsbedömning ASA (350) 15 2

3 5.4. Planering Strykning Strykningsorsak (445) Avförs från väntelista (450) Operation Operationssal (590) Operationsklinik (595) Huvudoperationskod (600) Bioperationskoder (601) Anestesikoder (610) Huvuddiagnos (620) Peroperativa komplikationer (680, 685) Verklig eftervårdsnivå efter operation (690) Postop Postperativa komplikationer (840, 845) Systemarkitektur Systemberoenden Övrig information Relaterade dokument Övrigt 20 3

4 1. Inledning Svenskt Perioperativt Register är ett kvalitetsregister och leds av en arbetsgrupp med representater från olika intresseorganisationer. Huvuddelen av medlemmarna i styrgruppen kommer från SFAI (Svensk förening för anestei och intensivvård) som också tog initiativet till registret. Registret utvecklas och förvaltas av UCR (Uppsala kliniska forskningscentrum) som är ett nationellt registercentrum. Mer information om registret finns på Svenskt Perioperativt Register syftar till att kunna driva kvalitetsförbättringsarbete med den perioperativa processen.den perioperativa processen börjar med operationsanmälan och slutar med ett av följande: 1. Patienten avförs från väntelistan 2. Patienten lämnar operation utan att gå till postop 3. Patienten lämnar postop Exempel på frågeställningar är: Patientens upplevelse av operationen Operationplaneringens påverkan på patienten Operationplaneringens påverkan på personal och resurser Resursutnyttjande (lokalutnyttjande) Utfall av operationen Komplikationsfrekvenser Case-mix Produktionssiffror I första och andra versionen av SPOR tas data framför allt från operationplaneringssystem. Detta för att det sågs som den enklaste källan att utgå från. Registret är helt beroende av den datakvalité som finns i källsystemen samt hur bra integrationen är gjord. Anledingen till det senare är att en bra översättning från lokala variationer till SPORs datamodell krävs för att kunna göra en analys. Detta dokument beskriver SPOR registret i version

5 2. Roller Följande roller finns implementerade: Nivå Tillgängliga roller Land Landskoordinator Hanterar stöddata för hela registret Vårdgivare Lokalkoordinator Koordinatorn hanterar användare, stöddata och inmatning för vårdgivaren Sjukhus Lokalkoordninator Kvalitetsutvecklare Koordinatorn hanterar användare, stöddata och inmatning för sjukhuset Kvalitetsutvecklaren kan se data och rapporter för sitt sjukhus. Opererande enhet Kvalitetsutvecklare Kvalitetsutvecklaren kan se data och rapporter för sin enhet. 3. Översikt över systemets funktioner Här följer en översikt över de funktioner som finns i version 2.0 av registret Inloggning 5

6 Inloggning sker med e-tjänstekort. Direkt efter inloggningen väljer man vilken opererande enhet inloggningen ska på om flera möjligheter finns. Detta styrs av den roll eller de roller man har i systemet enligt Roller. Har man bara en (1) roll kommer man automatiskt att loggas in på den nivå som rollen är knuten till Min enhet Sida med nyckeltal och översiktliga grafer över de opererande enheter inloggningen ger tillgång till. Datat är aggregerat upp till den nivå inloggningen skett på. Är man inloggad på sjukhusnivå ger därmed sidan data för sjukhusets alla opererande enheter, aggregerad till sjukhusnivå. All data visas per dag för en valbar månad Ingående nyckeltal och grafer Antal genomförda operationer (elektiva/akuta) Omplanerade operationer samma dag Antal planerade operationer som avförts från väntelistan 3.3. Sök registrering Söksida för registreringar. Sökning sker på behandlingsnummer. De registreringar som kan hittas styrs av vilken nivå man är inloggad på. Är man inloggad på sjukhusnivå kan man till exempel hitta registreringar för sjukhusets alla opererande enheter. En sökning leder till sidan för registreringsdetaljer nedan Registreringsdetaljer 6

7 Översiktssida för den registrerade processen. Processen är indelad i faser för överskådlighet Fellista Ger möjlighet att söka efter och visa registreringar som accepterats av registret, men där viss data är felaktig. Exempelvis kan det röra sig om felaktiga kvå-koder. Fellistan kan 7

8 därmed användas som verktyg för att kunna förbättra grunddatat och sedan uppdatera registreringarna Rapporter Statistiska rapporter som kan visas på skärmen. De olika rapporterna har olika urvalskriterier som användaren fyller i Filbaserad dataöverföring Sida som möjliggör uppladdning av data via lokal XML-fil. Efter uppladdning återkopplas nyckeltal för uppladdningen Överföringsstatistik 8

9 Antalet registreringar som laddats upp till registret per månad visas som en graf enligt nedan Administrera operationskliniker Användaren erbjuds här dels att skapa/namnge kliniker och delas att administrera redan skapade kliniker Skapa/namnge kliniker En lokalkoordinator eller kvalitétsutvecklare på ett sjukhus kan skapa och namnge operationskliniker. En klinik har ett id och ett namn, där id är det som används i registreringen och namn är det namn som används för kliniken i dagligt tal. Denna mappning behövs för att rapporter ska kunna skapas utifrån registreringar, men visa klinikernas namn istället för dess id. 9

10 Observera att detta sätt att godkänna kliniker inte längre är det föredragna och kan komma att försvinna. Se rubriken Godkänna salar och kliniker för ett alternativ administrera kliniker Redan skapade/godkända kliniker kan ges ett nytt namn eller raderas. Radering innebär att sals-id måste godkännas igen om det kommer med i en ny registrering Godkänna salar och kliniker Salar och kliniker identifieras i registreringar med ett id. För att säkerställa att data som skickas in är korrekt måste måste varje sådant id godkännas en gång. Vi sidan av menyalternativet ser man direkt hur många salar och kliniker som finns att godkänna. Denna siffra visas också uppe i menyraden. För varje sal och klinik vars id ännu är okänt för systemet, kan användaren välja att godkänna eller inte godkänna id:et med en knapptryckning. Vid ett icke-godkännande kommer salen/kliniken plockas bort ur fellistan, men den kommer att återkomma så fort samma id används igen vid en ny registrering. Vid godkännandet kommer salen kliniken att plockas bort ur fellistan och kommande registreringar kan använda id:et. Vid godkännandet kan man också ge salen/kliniken ett namn i klartext. Detta namn kommer då att kunna användas i rapporter istället för att använda id Administration av användaruppgifter 10

11 Genom att klicka på texten med inloggningsinformationen kan den inloggande användaren se och redigera sina användaruppgifter UCR:s tjänst för användarhantering. 4. Organisations- och lokalhierarkier 4.1. Grundläggande organisationshierarki Organisationshierarkin vårdgivare > sjukhus > opererande enhet används dels för åtkomstkontroll i systemet och dels vid registrering av en operation. För åtkomstkontroll gäller att en användare med en roll knuten till en viss nivå i hierarkin kan logga in på denna nivå. (För en tabell över kopplingen mellan roller och nivåer i hierarkin, se Roller) En användare med rollen kvalitétsutvecklare knuten till ett visst sjukhus kan därmed bara logga in på sjukhusnivå. Vill användaren också kunna logga in på någon av sjukhusets opererande enheter måste användaren ha en roll knuten till dessa. Vilken nivå användaren är inloggad på styr till exempel på vilken nivå data i rapporter kommer att aggregeras. Vid registrering av en operation används opererande enheten som registrerande operationsenhet och är definierad i variabellistan som Identifierare för den operationsenhet som skickar registreringen. Hanteringen av organsiationshierakier sker i UCRs tjänst för rättighetshantering. Mappningen av denna hieraki till den verkliga organisationshierarkin kan se olika ut på olika ställen i landet, eftersom ingen organsisation är den andra lik. Det är till exempel möjligt att begreppet sjukhus egentligen inte används organisatoriskt (finns inget HSA-ID) då de opererande enheterna sorterar direkt under en vårdgivare (exempelvis ett landsting). Sjukhus blir i detta fall bara den lokal som i råkar inhysa de opererande enheterna. En uppdiktad, men något realistisk, SPOR-organsisationshieraki skulle kunna se ut som följande: Vårdgivarens namn Mellanläns landsting Verkligt HSA-ID SE

12 Sjukhusets namn Mellanstads sjukhus Mindreby sjukhus Verkligt HSA-ID SE Saknas, sjukhuset finns inte organisatoriskt Opererande enhetens namn Verkligt HSA-ID Sjukhus Mellanstad Öronoperation SE Mellanstad Mellansstad Barnkirugi SE Mellanstad Mindreby Centraloperation SE Mindreby 12

13 5. Datamodell Datamodellen definieras av de krav som finns i registrets variabellista (se sporvariabellista-1.0). Här presenteras information om de variabler som kan behöva extra föklaringar. Inom parentes anges den variabelbeteckning som anges i variabellistan. Datamodellen försöker fånga data från den generaliserade process som finns beskriven i bilden nedan. SPOR: förenklat flöde över perioperativ process Operationanmälan Planering Genomförs som planerat? JA Operation Till UVA/Postop? NEJ Patient ut från operation NEJ JA Strykning UVA/Postop Patient ut från UVA/ Postop NEJ Skall avföras från väntelista? JA Patient avförs från väntelista 5.1. Registreringsinformation En registrering i ett kvalitetsregister har ett lagkrav från patientdatalagen på det grunddata som måste finnas för registreringen Identifiering av sändande system (webservice) Vid användning av webservice identifieras sändande system mot den lista av kända system som förvaltas av SPOR. Systemet ges rättighet att registrera för ett antal enheter Registrerande operationsenhet (110) Registrerande operationsenhet är den organisation som ansvarar för registreringen av den perioperativa processen. Det är den lägsta nivån i SPORs organisations-hierarki. Registrerande operationsenhet sorterar under sjukhuset som sorterar under vårdgivaren. Registrerande operationsenhet identifieras med sitt HSA-ID mot den lista av operationenheter som förvaltas av SPOR. 13

14 Behandlingsnummer (120) Behandlingsnummret är det löpnummer som skapas när operationanmälan görs. Om inget sådant nummer finns måste ett skapas innan sändning av data. Detta nummer hanteras som ett korrelations-id för det data som skickas. Behandlingsnummret ska kunna användas för att spåra data tillbaka till källsystemen Uppgiftslämnare (130) Patientdatalagen kräver att kvalitetsregistret sparar information om den ansvarar för överlämningen av patientuppgifterna till registret. Uppgiftslämnaren identifieras lämpligen med sitt HSA-ID Patientinformation En patient identifieras med ett av följande identitetsnummer. Svenskt personnummer (Tilldelat av Skatteverket) Svenskt samordningsnummer (Tilldelat av Skatteverket) Reservnummer (Vårdgivarspecifikt och unikt inom vårdgivaren) Att angivet personnummer/samordningsnummer är korrekt och stöds av ID-handling är ett lokalt ansvar. Ett reservnummer som angivits på en otillräknelig patient kan ersättas med ett personnummer eller samordningsnummer genom en uppdatering av registreringen. Att använda personnummer/samordningsnummer är att föredra eftersom det möjliggör samkörning med andra register. Det gör även att samma patient kan följas över flera operationer och mellan vårdgivare (till exempel vid reoperationer och byte av vårdgivare på grund av kö) Födelsedatum (220) Födelsedatum beräknas från samordningsnummer och personnummer och behöver därför bara ges vid användning av reservnummer. Från födelsedatum beräknas följande variabler: Ålder vid operationsanmälan Ålder vid operation Kön (230) Kön beräknas från personnummer och samordningsnummer så det behöver bara anges vid användning av reservnummer Epostadress (240) 14

15 Patientens e-postadress anges för att registret ska kunna kontakta patienten för uppföljning via webbaserade enkäter. Hur och under vilkaförutsättningar denna uppföljning ska ske är under utredning Operationsanmälan Akut/elektiv (320) Variabeln handlar om resursplanering och medicinsk angelägenhetsgrad vid sådan planering Akut planering (325) Denna variabel är bara relevant om variabel 320 är satt till AKUT. Denna variabel kräver ett översättningsarbete från lokal standard till SPORs kategorier Funktionsbedömning ASA (350) Kan finnas på många ställen i operationsplaneringssystemet. Skall tas så sent som möjligt i processen 5.4. Planering Planeringsvariablerna söker fånga data som är viktiga för den planerade operationen och när planeringen gjordes Strykning Strykningsvariablerna ska fånga när och varför operationen planerades om Strykningsorsak (445) Det finns ingen nationell standard för strykningsorsaker. Därför har SPORs styrgrupp kategoriserat de huvudanledningar som bedöms finnas. Här behövs ett lokalt översättningsarbete till SPORs kategorier. Strykningsorsakerna definieras i bilaga 1 i dokumentet spor-variabellista-1.0. Två nivåer finns och sändande system kan välja att skicka data på nivå ett eller två. Aggregerad data på nationell nivå kommer alltså bara att kunna göras på nivå ett. I framtiden är målet att alla skall leverera data på nivå två för att möjliggöra en nogrannare uppföljning Avförs från väntelista (450) 15

16 Att patienten avförs från väntelistan är en slutpunkt i den perioperativa processen. Vissa strykningsorsaker ger implicit information om detta (t.ex. patienten avlidit) men vi har valt att ha en egen variabel för att ge flexibilitet vid användning av Annat. Har patienten avförts från väntelistan förväntar sig systemet att varken operations- eller postop-data anges Operation Operationsvariablerna ska fånga data som är beskrivande för operationen och operationens utfall Operationssal (590) Identifierare för den sal som operationen utfördes i. Kommer i ett framtida skede att utökas med strukturdata för operationssalen som till exempel ventilation. Salsidentifieraren måste vara unik inom sjukhuset Operationsklinik (595) Identifierare för huvudoperatörens organisatoriska hemvist enligt lokal definition. Detta är en variabel som ger möjlighet att aggregera data per operationsklinik på sjukhuset. Eftersom sjukhusen själva bestämmer klinikindelningen är det svårt att jämföra data på nationell nivå. I de fall då operationen har mer än en huvudoperatör väljs den mest relevanta för den uppföljning som sjukhuset vill göra. Värdet på variabeln måste överensstämma med den nyckel som registrerats i administrationsgränssnittet för operationskliniker för att data ska kunna aggregeras Huvudoperationskod (600) Kan finnas på flera ställen i opr plan systemet; den verkligt utförda koden skall anges Bioperationskoder (601) Kan finnas på flera ställen i operationsplaneringssystemet; den verkligt utförda koden skall anges Anestesikoder (610) Kan finnas på flera ställen i operationsplaneringssystemet; den verkligt utförda koden skall anges Huvuddiagnos (620) 16

17 Kan finnas på flera ställen i operationsplaneringssystemet; den verkligt utförda koden skall anges Peroperativa komplikationer (680, 685) Här anges alla de komplikationer som uppstått under pågående operation. Inträffade ingen komplikation anges det med kombinationen [A0, GRAD0]. Registreras inte komplikationer på sjukhuset skickas inget data alls Verklig eftervårdsnivå efter operation (690) En slutpunkt i perioperativa processen är då operationen är genomförd och patienten går vidare i vårdkedjan utan att hamna på UVA/Postop. Anges här POSTOP som nästa steg förväntar sig systemet att få en uppdatering med postop-data. Fram till postop-data levereras markeras registreringen som ofullständig Postop Postopvariablerna ska fånga data som är beskrivande för patientens vistelse på Postop/UVA. Det är bedömt att man i många landsting fortsätter att registrera i operationsplaneringssystemen även här och att man därför lätt kan exportera data ifrån denna fas (till skillnad från IVA, vårdavdelning där information journalförs i andra system) Postperativa komplikationer (840, 845) Här anges alla de komplikationer som uppstått efter operation. Inträffade ingen komplikation anges det med kombinationen [U0, GRAD0]. Registreras inte komplikationer på sjukhuset skickas inget data alls. 17

18 Webservice AccessControl Inlogg/Utlogg Registrerande Enheter Dataöversikt XML-inmatning Sök registrering Rapporter Registranter Registrering SPOR-webapp Registreringsformat SPOR-database SPOR-reportdata PatientAccessLog PersonalData Kodverk (KVÅ, ICD-10...) PROM Patienter 6. Systemarkitektur SPOR är en webbapplikation med ett antal systemberoenden. Som en del av webbapplikationen exponeras ett webserviceinterface och ett webb-gui Systemberoenden SPOR 2.0 har följande systemberoenden: 18

19 Uppströms: Nätverk/Webserver Nedströms: AccessControl användarhantering och säkerhet Databas lagring/läsning av registreringar och stöddata PatientAccessLog lagring av patientdataaccess 19

20 7. Övrig information 7.1. Relaterade dokument spor-variabellista-2.0: presentation och definition av registrets variabler spor-2.0-integration: beskrivning av hur integrationen mot registret är tänkt att göras 7.2. Övrigt Övrigt om SPOR-projektet samt kontaktuppgifter hittas på 20