DPSD2 Guide 3: - og samspillet med SOR og SEB. Initialmodtagelse og mapninger i DPSD2

Transkript

1 DPSD2 Guide 3: Initialmodtagelse og mapninger i DPSD2 - og samspillet med SOR og SEB. Denne guide henvender sig til brugere af DPSD2 der ønsker at vide mere om initialmodtagelse og mapninger i DPSD2 og samspillet imellem DPSD2, SOR og SEB. Version 1.1b 13. januar 2011 Roy Verdiani, IT-enheden Sundhedsstyrelsen

2 Indledning Guiden er til brugere, der ønsker bedre indsigt i mekanismerne bag initialmodtagelse samt sammenspillet imellem DPSD2, SOR (Sundhedsvæsenets Organisations Register). og SEB (Sundhedsstyrelsens Elektroniske Brugeradministration). Formålet med guiden er at beskrive Samspillet imellem DPSD2, SOR og SEB Mekanismerne bag initialmodtagelse i DPSD2 Hvorfor der overhovedet er et mapningsbehov? Derudover er formålet at beskrive de forskellige mapninger individuelt, deres formål og virkemåde samt hvilke overvejelser der skal gøres decentralt i forhold til de muligheder mapningerne giver. Guiden indeholder et indledende afsnit omkring SOR, SEB og deres overordnede sammenhæng med DPSD2 efterfulgt af en gennemgang af mekanikken bag initialmodtagelse. Guiden beskriver derefter detaljeret om de 4 primære mapninger: Mapninger Side A SOR, SEB og DPSD2 3 B Mekanikken bag initialmodtagelse 8 C Alias 16 D Frasorter 17 E Fysiske Sygehuse og enheder på fysiske 19 sygehuse F Delegeret enhedsansvar (Regional 23 primærsektormapning) 2

3 A SOR, SEB og DPSD2 Det overordnede formål med DPSD2 er at give rapportører mulighed for at rapportere utilsigtede hændelser der sker i sundhedsvæsenet til læringsformål. En vigtig information i denne rapportering er specificeringen af hændelsesstedet hvor skete den utilsigtede hændelse? Dette skal specificeres entydigt i forbindelse med rapportering. Den entydige specificering har flere formål: 1. at sikre at hændelsesstedet identificeres entydigt 2. at sikre at der senere kan laves meningsfyldt statistik og rapporter 3. at sikre at rapporten ender hos den/de initialmodtagerer, der er ansvarlig for at visitere sager for det valgte hændelsessted DPSD2 skal kunne rumme entydige hændelsessteder, som omfatter alle enheder i primær- og sekundærsektoren samt enheder i det kommunale område. Dette er et meget stort antal organisatoriske enheder. I SOR er der i dag ca enheder. SOR er stadig ikke 100% dækkende, så det forventes at tallet stiger yderligere de kommende år (eksempelvis er der ca plejehjem i Danmark, og kun et fåtal af disse er registreret i SOR) DPSD1 dækkede kun sekundærsektoren. Derfor kunne sygehusenes hændelsessteder vedligeholdes direkte i DPSD1 systemet. Med DPSD2 og tilføjelsen af nye sektorer stiger antallet af enheder betydeligt, og det er ikke praktisk muligt at vedligeholde disse direkte i DPSD2. Derfor er SOR valgt som den serviceleverandør, der kan levere informationer om hændelsessteder i sundhedsvæsenet til DPSD2. Hvad er SOR? SOR er Sundhedsvæsenets Organisatoriske Register, og er et hierarkisk opbygget register, der afspejler organisatoriske enheder i sundhedsvæsenet. SOR er overordnet inddelt i 4 sektorer: Statslig Regional Kommunal Privat Hver af disse 4 sektorer indeholder hver deres hierarki af sektor specifikke enheder, der grundlæggende alle følger samme logiske opbygning. 3

4 I første niveau findes det der kaldes Institutions ejere, som forkortes IE. Eksempler på institutions ejere for hver af de 4 sektorer kunne være Sundhedsstyrelsen, region midt, Egedal Kommune og Aabenraa Løve Apotek. Oprettelse af IE enheder kan bestilles af organisationens SOR ansvarlige, men skal udføres af Sundhedsstyrelsen. I andet niveau findes enheder, der defineres som Sundheds institutioner som forkortes SI, eksempelvis sygehuse for den regionale sektor og plejehjem, genoptræningscentre mv. for den kommunale sektor. Oprettelse af SI enheder kan bestilles af organisationens SOR ansvarlige, men skal udføres af Sundhedsstyrelsen. Resterende niveauer, uanset hvor dybe de er, er defineret som Organisatoriske enheder som forkortes OE. For det regionale niveau, er det medarbejdere i regionerne der varetager oprettelse og vedligeholdelse af alle OE enheder. For de andre sektorer er det indtil videre Sundhedsstyrelsen, der varetager oprettelse og vedligehold af enheder på OE niveau. Illustration af forskellen imellem IE, SI og OE enheder i SOR For hver enkelt enhed i SOR er der defineret en række stamdata, herunder information om adresse, enhedstype, hovedspecialet der udøves på enheden, adressen mv. Især enhedstypen er interessant i DPSD2 sammenhæng, da den giver mulighed for at DPSD2 kan fremsøge specifikke typer enheder som eksempelvis alle apoteker, lægepraksis, ergoterapiklinikker mv. 4

5 Hvis en organisations netværk er tilkoblet Sundhedsdatanettet, kan der nedenfor ses hvordan organisationer selv kan få adgang til SOR og se, hvordan specifikke organisationer er afbilledet i SOR. For at få adgang til SOR Forudsætter adgang til Sundhedsdatanettet 1. SOR findes på 2. Klik på [Gæsteadgang] 3. Vælg menu Alle Enheder Hvad er SEB? SEB er Sundhedsstyrelsens Elektroniske Brugeradministration, og er i princippet blot et basalt brugeradministrationssystem for de produkter, som Sundhedsstyrelsen udbyder, herunder LPR, esundhed og DPSD2. Sundhedsstyrelsens produkter benyttes af en masse organisationer: Kommuner, regioner, overordnede organisationer, private mv. Der er et stort antal brugere, når alle systemerne tælles sammen. Det ville ikke være praktisk muligt eller lovmæssigt forsvarligt at administrere alle de eksterne organisationers brugere centralt i SST. Ansvaret for at oprette brugere og tildele roller og rettigheder er derfor placeret decentralt hos den organisation, hvor brugerne er tilknyttet. Dette skyldes primært den administrative byrde og at Sundhedsstyrelsen ikke lovmæssigt kan stå inde for hvem organisationens brugere er og hvilke systemer de skal kunne tilgå med hvilke rettigheder. SEB er så at sige organisationernes eget brugeradministrationssystem. Sundhedsstyrelsen er i den sammenhæng blot den part, der stiller værktøjet til rådighed. Der er 2 grundpræmisser i DPSD2 der nødvendiggør brugeradministration: Det er personfølsomme data og kun brugere med specifikke rettigheder må kunne tilgå sagerne Som beskrevet tidligere, er det nødvendigt at binde brugere til hændelsessteder, således at brugere i én organisation, ikke får adgang til en sag der er rapporteret for en anden organisation. For at anvende DPSD2 skal brugeren altså have de fornødne rettigheder. Det er den lokale brugeradministrator der tildeler brugeren rettigheder til DPSD2. Dette gøres inde i SEB, ved at brugeren tildeles en eller flere roller for en eller flere organisatoriske enheder. 5

6 Det er nemlig sådan at adgangen til sager i DPSD2, er afgrænset af flere faktorer: Hvem er brugeren? Hvad er hans rolle? Hvor er brugeren tilknyttet organisatorisk? (Ud fra SOR hierarkiet) Eksempelvis kan Jens være Sagsbehandler og se alle sager. Det bør dog kun gælde for sager som vedrører Jens i forhold til hvor han er ansat. Derfor er det nødvendigt at der også specificeres at Jens kun må være Sagsbehandler på sager det vedrører Hjerte afdeling 1 på Ullerup Sygehus. I en tidligere guide DPSD2 guide - Sådan sikrer du at du kan logge ind i DPSD2 som kan findes nederst i højre hjørne på forsiden af er der yderligere informationer om SEB, herunder links til vejledninger mv. De 2 SEB roller i DPSD2: Initialmodtager og decentral sagsbehandler Der findes kun 2 roller der er nødvendige for at sikre sig adgang til DPSD2: Initialmodtager Decentral sagsbehandler Rollen Initialmodtager har en direkte sammenhæng til den fane der i DPSD2 hedder Indbakke. Alle nye rapporter der ikke er accepteret eller afvist endnu, ender i indbakken hos den rette initialmodtager. Hvem der er den rette initialmodtager i forhold til hændelsessted, beskrives detaljeret senere i dokumentet, men udgangspunktet for at have en indbakke er at man er initialmodtager. Initialmodtageren kan til gengæld intet andet foretage sig end at modtage og visitere sager. Rollen Decentral sagsbehandler betyder at brugeren kan alt andet i DPSD2 end at se en indbakke (hvilket er initialmodtagerens funktion). Sagsarbejde, søgning, visitering, handleplaner, statistik og alle de andre funktioner forudsætter at brugeren er decentral sagsbehandler. Der er ingen begrænsninger i hvad en sagsbehandler kan. Som beskrevet, kan der være begrænsning for hvilke sager sagsbehandleren har adgang til, på baggrund af sagens hændelsessted. Dette uddybes senere i guiden. En bruger kan godt tildeles begge roller og vil således have både indbakke og sagsbehandler rettigheder i DPSD2. Årsager til mapningsbehov ifht. DPSD2 Fysiske Sygehuse og enheder på fysiske sygehuse Det hierarki SOR afspejler, beskriver den organisatoriske opbygning fra et økonomisk og administrativt perspektiv, i stil med et organisationsdiagram for en virksomhed. For den regionale sektor, er det regionerne selv der har organiseret deres enheder i SOR. Den økonomiske-administrative organisering har betydet at ikke alle fysiske sygehuse er afspejlet i SOR. 6

7 Et eksempel er region syd, hvor Sygehus Lillebælt er den organisation, hvor alle afdelinger for sygehusene Vejle, Give, Kolding, Middelfart og Fredericia er tilknyttet administrativt. Det betyder at disse 5 sygehuse ikke findes som selvstændige enheder i SOR. Det kan i DPSD2 sammenhæng være en udfordring for brugerne at finde frem til et hændelsessted på Anæstisi Give, hvis ikke Give Sygehus kan fremfindes blandt valgmulighederne for region syd. Dette er udfordringen som imødekommes i mapningen Fysiske Sygehuse og enheder på fysiske sygehuse Delegeret enhedsansvar (Regional primærsektormapning) Det er regionerne, der er ansvarlige for at modtage rapporter for den regionale primærsektor. I beskrivelsen af SEB stod der, at der var 3 faktorer, der udgjorde hvilke sager Jens måtte få adgang til. En af disse er tilknytningen imellem Jens s rolle (eks. Initialmodtager) og den organisatoriske enhed Jens er tilknyttet til (eks. Hjerte afdeling 1 på Ullerup Sygehus). Alle primærsektor enheder er placeret under Private i SOR. De har alle deres eget organisationshierarki lige som regioner, kommuner og statslige myndigheder. Af sikkerhedsmæssige grunde er det ikke muligt i SEB at tilknytte en bruger fra én organisation, til en enhed der ligger i en anden organisation. Det er eksempelvis ikke muligt at knytte Jens, som arbejder i en region, til primærsektorenheden Aabenraa Løve Apotek. Dette er udfordringen som imødekommes i mapningen Delegeret enhedsansvar (Regional primærsektormapning) Alias og Frasorter En række enheder i SOR giver ikke mening i forhold til valg af hændelsessted for en utilsigtet hændelse, eksempelvis testafdeling o.lign. Frasorter mapning imødekommer denne udfordring. Andre enheder har navne som ikke identificere enheden tydeligt eller er forkortelser som ønskes ændret. Alias mapning imødekommer denne udfordring. 7

8 B Mekanikken bag initialmodtagelse Initialmodtagelsen fungerer på 4 forskellige måder som svarer til den inddeling der er på valg af hændelsessted i rapporteringsskemaet (lokationsopslag): Forskellen imellem de 4 er tydelig i forhold til de efterfølgende skærmbilleder brugeren skal igennem for at specificere hændelsesstedet, de såkaldte wizards. Eksempelvis vil valg af hændelsessted for Hospital føre videre til én type wizard, hvor rapportøren først skal vælge en region, og dernæst vælge et sygehus eller en afdeling ud fra et organisationshierarki for den valgte region. Vælger rapportøren i stedet en enhedstype under Kommune vil brugeren i stedet alene skulle vælge en kommune. For Andet regional vil wizarden bede brugeren om at specificere regionen for derefter at præsentere en søgefunktion. For Privat er det kun søgefunktionen der vises. Der er altså behov for forskellige måder at fremsøge hændelsessteder på, i forhold til hvilken af de 4 typer hændelsesstedet tilhører. Det er ligeledes gældende for den efterfølgende behandling og mekanik omkring initialmodtagelse. Der findes derfor 4 måder at håndtere initialmodtagelse på, som er gengivet herunder: Initialmodtagelse for regioner Initialmodtagelse for andre regionale enheder Initialmodtagelse for privathospitaler Initialmodtagelse for kommunale enheder Herunder vil de 4 typer beskrives: Initialmodtagelse for regioner (Lokationsopslag = Hospital) Som beskrevet ovenfor vil valg af Hospital vise en wizard, hvor regionen skal vælges for derefter at vise et organisationshierarki over den valgte region. For eksemplet er der herunder lavet et forsimplet hierarki for region midtjylland. 8

9 I eksemplet ovenfor er der gengivet et hierarki, som består af overordnede og underordnede enheder lidt som et familietræ. Man anvender derfor også betegnelser som Børn og Forælder om relationen imellem enhederne i hierarkiet. Eksempelvis er Børneafdelingen og Kirurgisk afdeling børn til Regionshospitalet Herning og Regionshospitalet Herning er Børneafdelingens forælder. Hver eneste enhed i hierarkiet ovenfor betegner man med tekniske termer for en node som på gameldavs dansk kunne oversættes til knudepunkt. I forbindelse med initialmodtagelse i DPSD2 kan man med fordel betragte hver node som en postkasse, hvor der kan afleveres breve i. Breve der indeholder rapporter om utilsigtede hændelser. Hvis man ønsker at kunne læse de breve der afleveres til en postkasse, er forudsætningen at man har adgang til postkassen. Dette kræver en nøgle en nøgle der i DPSD2 kaldes initialmodtager rollen. Behovet for at give specifikke personer, nøgler til specifikke postkasser imødekommes i SEB, hvor man: Giver nøglen til en person (rollen initialmodtager ) for en specifik postkasse (tilknytning til specifik SOR enhed) I eksemplet ovenfor er der 12 postkasser, og det ville ikke være særligt effektivt, hvis der skulle udleveres 12 nøgler til en person for at give adgang til samtlige postkasser. Derfor er der lavet universalnøgler som virker til flere postkasser. De har dog den begrænsning at de aldrig virker på de sidestillede eller overordnede postkasser. Hvis der f.eks. laves en universalnøgle for Regionshospitalet Herning vil den kun virke på denne samt dens 2 børn, altså Børneafdelingen og Kirurgisk afdeling. Alle breve der sendes til én af disse 3 postkasser kan altså hentes af den person, der har universalnøglen for Regionshospitalet Herning. Det er klart at der skal være mindst én person der har en universalnøgle for den øverste postkasse for region midt, ellers kan man komme i en situation, hvor et brev bliver 9

10 afleveret til en postkasse ingen har nøgle til og derved går tabt. Denne person kaldes i DPSD2 termer for en bagstopper. Ret og Pligt: Hvis der kun er én person, der har universalnøglen på øverste postkasse, kan det hurtigt blive trælst at denne ene person har pligt til at åbne 12 postkasser om dagen og læse alle de breve der kommer ind, da der jo ikke er andre, der gør det. I DPSD2 betyder det at personen får alle rapporter, der er rapporteret for alle enheder til egen Indbakke. Heldigvis har personen A en kollega B, der gerne vil hjælpe lidt til med at åbne postkasser for Regionshospitalet Herning og dennes 2 børn. Kollegaen får universalnøglen til Regionshospitalet Herning s postkasse og dermed også pligten til at hente breve fra disse 3 postkasser. Det betyder ikke at personen A ikke længere har retten til at åbne de 3 postkasser med sin universalnøgle, men blot at han ikke har pligt til at gøre det mere. I DPSD2 betyder det at rapporter ikke længere vil være synlige i indbakken for personen A men kun for kollegaen B, om end personen A fortsat vil kunne fremsøge rapporterne, afvise eller acceptere dem osv. Nu har kollega B altså pligten og retten til at åbne de 3 postkasser for Regionshospitalet Herning og dens børn. Det viser sig dog at der kommer så mange breve ind her, at kollegaen ikke magter at læse dem alle alene. Løsningen er derfor at der udleveres endnu en universalnøgle for Regionshospitalet Herning og dens børn til kollega C. Nu er de 2 personer der har pligt og ret til åbne disse 3 postkasser hver dag. I DPSD2 betyder det at initialmodtager rollen kan tildeles flere brugere på samme SOR node i SEB, hvorefter rapporter vil være synlige i både kollega B og kollega C s indbakker. Deres indbakker vil være synkrone. Initialmodtagelse for andre regionale enheder (Lokationsopslag = Andet Regional) Det er regionerne der er ansvarlige for at modtage rapporter, der rapporteres for regionale primærsektor enheder som eksempelvis apoteker, praktiserende læger mv. Valget af anden regional enhed forudsætter at rapportøren først vælger enhedstypen for hændelsesstedet, eksempelvis et apotek. Dernæst vil rapportøren skulle vælge en region og til sidst fremsøge den pågældende enhed i en søgefunktion. Det kunne f.eks. være Brande Apotek for region midtjylland. Brande Apotek er en selvstændig organisation med et selvstændigt hierarki i SOR, som ligger ved siden af region midtjylland, eksemplificeret nedenfor: 10

11 Hvis man skal fortsætte lidt i postkasse analogien, er problemet at postkassen for Brande Apotek ikke ligger under region midtylland, og derfor virker Person A s universalnøgle ikke til Brande Apoteks postkasse. Den umiddelbare løsning ville være at Brande Apotek så gav deres nøgle til Person A, men udfordringen er jo at der findes et hav af apoteker, så det ville være rigtig mange nøgler Person A skulle have og så var vi lige vidt. I DPSD2 ville det betyde at Person A skulle have tildelt initialmodtagerrollen på alle apoteker i regionen i SEB, hvilket dels ikke kan lade sig gøre af sikkerhedsmæssige årsager og dels ville kræve ekstraordinær administration. Person A tager en snak med postkontoret om der ikke findes en løsning, og det gør der! Postkontoret kan sagtens omfordele breve der sendes til samtlige apoteker i region midtjylland til en anden postkasse. De skal bare vide hvilken postkasse der skal sendes til 11

12 i stedet. Person A tænker at brevene skal sendes til postkassen Regional primærsektor enhed, da dem der sidder her i forvejen har forstand på det med apoteker. Samtlige apoteker bliver i DPSD2 sammenhæng identificeret ved at enheden i SOR har enhedstypen Apotek. Afgrænsningen af at det kun skal være apoteker i Midtjylland sker ud fra Apotekets postnummer dvs. postkontoret ved, hvilke postnummer der skal omfordeles/mappes til hvilken region. Den postkasse i region midtjyllands hierarki, der skal modtage apoteksrapporter skal vælges af regionen og sættes op i DPSD2 mapninger. Super! siger Person A Jeg har jo universalnøglen til hele region midtjylland, og derfor kan jeg jo bare hente de breve fra apotekerne, der bliver leveret her. Nej, desværre er svaret fra postkontoret. Vi vil helst ikke blande apoteksbreve sammen med de andre breve i modtager. Vi kommer i stedet og sætter en ny postkasse op ved siden af den eksisterende, så der nu står 2 postkasser samme sted: Den oprindelige postkasse og den nye for omfordelte breve. Den nye postkassen bruger godt nok den samme nøgle som den for Regional primærsektor enhed, men universalnøgler virker ikke til den. Når primærsektor rapporter mappes til enheder i regionens hierarki, gælder der ikke de samme regler hvad angår nedarvning af rettigheder, som ved rapporter der rapporteres direkte til en enhed i regionen som beskrevet ovenfor vedr. Initialmodtagelse for regioner. For at se mappede primærsektor sager i indbakken, skal brugeren have rollen Initial modtager for den pågældende enhed i eksemplet er det Regional Primærsektor enhed. Det samme gør sig gældende for at kunne fremfinde eller sagsbehandle sagen efterfølgende, hvor det kræves at brugeren har rollen Decentral Sagsbehandler for den enhed som primærsektorsager mappes til. Dette er yderligere eksemplificeret nedenfor: 12

13 I billedet ovenfor er der illustreret 3 brugere som er tilknyttet 3 forskellige enheder i region midt. Der er desuden også vist 3 sager der er rapporteret til forskellige enheder, hvor sag C er særlig, idet den er mappet via primærsektormapningen. Nedenfor er der skitseret hvilke brugere der har initialmodtager og sagsbehandler ret til de forskellige sager i deres livscyclus. Hvem er initialmodtager og kan se sagen i indbakken (=pligt)? Bruger Bruger A Bruger B Bruger C Handling Sag A i indbakke JA NEJ NEJ Sag B i indbakke NEJ JA NEJ Sag C i indbakke NEJ NEJ JA Hvem kan finde og redigere sager efter visitation (=ret)? I eksemplet forudsætter vi at alle 3 sager er accepteret og visiteret til Bruger B. Bemærk! Når sager visiteres til en udvalgt sagsbehandler, tilsidesættes de rettigheder der er givet i SEB, i forhold til sagsbehandlerens tilknytning til specifikke enheder. Sagsbehandleren kan altså godt få visiteret og arbejde med en sag selvom han ikke har rettigheder til det specifikke hændelsessted i SEB. Det samme gør sig gældende, hvis denne sagsbehandler efterfølgende tildeler en anden sagsbehandler særlig adgang til den pågældende sag, via Adgangsrettigheder. Dermed er det muligt at visitere sager til alle sagsbehandlere i DPSD2, uanset deres tilknytning til enheder i SEB. 13

14 I eksemplet nedenfor har Bruger B ret til at se alle sager, qua ovenstående bemærkning. Bruger Bruger A Bruger B Bruger C Handling (Sagsbehandler) Søg Sag A JA JA NEJ Søg Sag B JA JA NEJ Søg Sag C NEJ JA JA Når det drejer sig om sager der er mappet, som de regionale primærsektorsager, er det altså ikke nok at tildele adgang på øverste niveau for en overordnet sagsbehandler eller bagstopper, for at sikre at denne bruger har adgang til samtlige sager. Denne bagstopper skal også have specifik adgang til de enheder, som der mappes til vedr. de regionale primærsektorenheder, for at kunne fremsøge samtlige regionale sager såvel som primærsektor sager. Initialmodtagelse for privathospitaler (Lokationsopslag=Privat) Ved valg af Privat vises en søgefunktion, hvor brugeren kan fremsøge et privat hospital eller hospice efter navn, vejnavn eller postnummer. Afgrænsningen sker ved at alle SI enheder i SOR af typen hospital, der har en overordnet institutionsejer (IE) af typen Privat er med i søgepuljen. Når brugeren vælger en enhed der opfylder ovenstående krav, bliver rapporten sendt ind på den valgte enheds SOR id, og der sker ikke særlige mapninger i forhold til initialmodtagelsen. Private hospitaler/hospicer er efter loven selv ansvarlige for at modtage og analyser rapporter om hændelser, som har fundet sted inden for deres virksomhedsområde. Uagtet at disse enheder har indgået en eller anden driftsaftale med regionen vil de i lovens forstand og i SOR være selvstændige enheder. Regionen kan derfor ikke få indsigt i deres rapporter. Det betyder at private hospitaler og hospices skal have oprettet egne initialmodtagere og sagsbehandlere på SI (eller det overordnede IE) niveau for at modtage og sagsbehandle sager, der rapporteres til dem. Initialmodtagelse for kommunale enheder (Lokationsopslag=Kommune) Dækningsgraden af kommunale enheder i SOR er ikke særlig stor. Det er derfor aftalt med KL, at DPSD2 som udgangspunkt ikke skulle benytte SOR hierarkiet til valg af hændelsessted for kommunale enheder. I stedet visiteres alle rapporter til kommunens overordnede IE niveau, og skemaet er udbygget med et felt om institutionstype som kan hjælpe med at differentiere sagerne for de kommunale initialmodtagere. Der foregår i øjeblikket et arbejde med at udbygge SOR således at struktur og dækningsgraden for kommunale enheder bliver ajourført med den faktiske tilstand. Dette arbejde kan betyde at valg af hændelsessted for kommunale enheder vil blive ændret, og komme til at ligne det for regionerne. Nedenfor er det dog systemets nuværende virkemåde, der beskrives. 14

15 Ved valg af en institutionstype under Kommune, vil brugeren herefter skulle vælge den pågældende kommune som er afgørende for hvilken postkasse rapporten ender i. Initialmodtagelsen sker altså i forhold til de 98 IE enheder for kommuner. Hver enkelt kommune skal derfor have oprettet egne initialmodtagere og sagsbehandlere på kommunens IE niveau, for at modtage og sagsbehandle sager, der rapporteres til dem. Som beskrevet vil rapporterne indeholde et felt om institutionstypen som kan hjælpe initialmodtageren med at vurdere hvilken sagsbehandler, der skal arbejde videre med sagen, uden at denne initialmodtager behøver at læse sig til denne viden i sagens indhold. 15

16 C Alias Resume En række enheder i SOR ønskes præsenteret i DPSD2 s valg af hændelsessted, men med et andet navn end det der er defineret i SOR. Alias mapning imødekommer denne udfordring. Formål Ændre navnet i DPSD2, i forhold til hvad navnet er i SOR. Eks. Afd. HjKar OP >> Afdelingen for Hjerte-Kar operationer Nuværende konfiguration Mapningstabellen består af 2 kolonner Eksisterende SOR id Alias Regionerne har allerede produceret en liste over organisatoriske enheder, hvor der ønskes anvendt et andet navn/alias end det navn, der er registreret i SOR. Særlige omstændigheder Ingen Hvad skal du gøre? Vurdere om der er enheder i egen organisation der burde hedde noget andet i DPSD2 end de gør i SOR Overvej og tag dialog med den SOR ansvarlige i egen organisation, om hvorvidt navnet skal ændres i SOR generelt eller navneændringen kun giver mening i.fht. DPSD2 Send en samlet opgørelse over ændringsønsker til navne til dpsdsupport@sst.dk. Opgørelsen skal indeholde SOR-id og ønskede alias, qua beskrivelsen ovenfor. 16

17 D Frasorter Resume En række enheder i SOR giver ikke mening i forhold til valg af hændelsessted for en utilsigtet hændelse, eksempelvis testafdeling og lign. Frasorter mapning imødekommer denne udfordring. Formål At frasortere tværgående enheder i SOR, som ikke ønskes gengivet i DPSD2 til valg af hændelsessted. Eks. kan alle enheder der indeholder test i deres navn frasorteres. Nuværende konfiguration Mapningstabellen består af 1 kolonne Navn Indeholder Hvis der i frasorterlisten er angivet toi, vil alle enheder i SOR der indeholder teksten toi frasorteres og de vil ikke kunne findes i DPSD2. Dvs. at både enheden toilet og enheden herretoilet vil blive frasorteret. Bemærk! Sundhedsstyrelsen har ikke tidligere retvisende beskrevet hvad frasorter listen kunne bruges til. Det har medført en misforståelse mht. muligheden for at frasortere individuelle enheder. Det er IKKE tiltænkt eller designet at frasorter kan hjælpe til med at fjerne individuelle enheder, med mindre de lever op til følgende krav: 1. Enhederne der frasorteres må ikke have underordnede enheder der ikke ønskes frasorteret er enheden frasorteret er det hele enheden inklusiv dens børn. 2. Navn indeholder skal være generisk og må ikke ramme uskyldige. Enheder der indeholder test, restgruppe, konvertering mv. kan sige at gælde på tværs af regioner, kommuner og private Dette er ikke tilfældet for navne som eksempelvis HU6212. Særlige omstændigheder Frasorter funktionaliteten skal anses som en overordnet mulighed for at indikere hvilke enheder, der på tværs af alle sagsbehandler organisationer ikke anskues som værende 17

18 nødvendige ifht. håndtering af utilsigtede hændelser. Det er ikke tænkt som et værktøj, der giver mulighed for at frasortere individuelle enheder. Dette skyldes at frasorteringen gælder hele SOR, så hvis f.eks. en organisation ønsker at frasortere alle enheder i egen organisation, der indeholder tele og en anden organisation har enheder der også indeholder tele som ikke ønskes frasorteret, kan frasorteringen ikke foretages. Bemærk! Der foretages i forvejen en filtrering af enheder, der vises i DPSD2 baseret på deres enhedstype og andre informationer. Eksempelvis vil enheder med enhedstypen Service enhed kun medtages i DPSD2, hvis enheden har registreret et hovedspeciale. Alle andre Service enheder uden hovedspeciale, vil automatisk blive frasorteret eksempler på service enheder uden hovedspeciale er Køkken, Toilet, IT enhed mv. Hvad skal du gøre? Hvis der findes enheder i lokationsopslag, som lever op til de krav, der er beskrevet i bemærk feltet på forrige side, kan Sundhedsstyrelsen gøres opmærksom på dette ved at maile til dpsdsupport@sst.dk. Sundhedsstyrelsen vil overveje om navnet lever op til kravene beskrevet på forrige side, dvs. generiske og tværgående. Sundhedsstyrelsen vil tillige vurdere om enhederne skal frasorteres på baggrund af navn eller om det ville være bedre at dette skete på baggrund af en kombination af enhedstype, hovedspeciale mv. 18

19 E Fysiske Sygehuse og enheder på fysiske sygehuse Resume Det hierarki SOR afspejler, beskriver den organisatoriske opbygning fra et økonomisk og administrativt perspektiv, hvilket betyder at ikke alle fysiske sygehuse er afspejlet i SOR. Brugerne af DPSD2 vil have svært ved at finde frem til et hændelsessted på afdelinger, når de fysiske sygehuse ikke er en del af hierarkiet. Mapningen sørger for at de manglende fysiske sygehuse kan oprettes, at afdelinger kan knyttes til disse og at det kan præsenteres for rapportøren i valg af hændelsessted. Formål At tilføje fysiske sygehuse og mappe enheder til disse, for at gøre det nemmere for rapportører at fremfinde hændelsessteder. Eks. findes Vejle Sygehus ikke i SOR, om end en række afdelinger under Sygehus Lillebælt er afdelinger, der fysisk er placeret på Vejle Sygehus. Ved at oprette Vejle Sygehus som et fysisk sygehus i DPSD2, kan valg af hændelsessted vise Vejle sygehus og herunder de afdelinger, der ligger her. I billedet nedenfor er der gengivet hvordan valg af hændelsessted ser ud, når der er oprettet fysiske sygehuse under Sygehus Lillebælt. 19

20 Nuværende konfiguration Der anvendes 2 mapningstabeller: én til at angive de fysiske sygehuse og én til at angive hvilke enheder, der skal mappes til hvilket fysisk sygehus. Mapningstabellen for fysiske sygehuse består af 2 kolonner: Fysisk Sygehus ID Fysisk Sygehus Navn Mapningstabellen for mapning af enheder til fysiske sygehuse består af 2 kolonner: Fysisk Sygehus ID SOR ID for enhed Sundhedsstyrelsen har allerede produceret en liste over fysiske sygehuse og mapning af enheder baseret på vores kendskab til organisationerne samt ved opslag på regionernes og sygehusenes hjemmesider mv. Særlige omstændigheder De fysiske sygehuse er enheder, der indsættes imellem andet niveau i SOR (SI Sundhedsinstitutioner) og 3 niveau (OE organisatoriske enheder) som gengivet nedenfor: Uanset hvordan enheder vil blive mappet til forskellige fysiske sygehuse, er det ikke muligt at lave huller i det hierarki, der i forvejen ligger i SOR. Hvordan dette håndteres, beskrives i de 3 følgende eksempler: 20

21 I billedet ovenfor findes eksemplets SOR træ i venstre side. I højre side er der (med rødt) oprettet et fysisk sygehus FysSygehus og Afd. A er mappet til dette fysiske sygehus (med blåt). Da Afd. A indeholder 2 afdelinger under sig som IKKE er mappet, kan Afd. A ikke fjernes fra sin oprindelige position, da dette ville medføre et hul i hierarkiet. Man vil som bruger finde Afd. A under både Oversygehus og FysSygehus I billedet ovenfor er Afd. B mappet til FysSygehus. Da Afd.B ligger under Afd. A, vil både Afd. A og Afd. B findes under FysSygehus for ikke at medføre et hul i hierarkiet. Da Afd. B ikke har enheder under sig, fjernes den fra sin oprindelige position I billedet ovenfor er både Afd. A, B og C mappet til FysSygehus, og de optræder alle kun under det fysiske sygehus. Hvad skal du gøre? Der eksisterer mange enheder, der skal mappes til mange fysiske sygehuse. Det kan være meget svært at overskue uden det rette værktøj. 21

22 Sundhedsstyrelsen har på den baggrund igangsat udviklingen af en applikation, der gør det nemmere at overskue og vedligeholde hierarkierne inklusiv fysiske sygehuse og enheder, der er mappet til disse. Værktøjet er ikke webbaseret, og kan ikke distribueres. Det er derfor ikke pt. muligt at give regionerne mulighed for at opdatere mapninger adhoc i eget regi. Det er derfor nødvendigt at vedligeholdelsen af mapninger foretages i samarbejde med Sundhedsstyrelsen. Hvis det vurderes at der er enheder i valg af hændelsessted, der skal placeres under et eksisterende eller nyt fysisk sygehus, skrives til dpsdsupport@sst.dk med henblik på at få etableret et arbejdsmøde. 22

23 F Delegeret enhedsansvar (Regional primærsektormapning) Resume Det er regionerne, der er ansvarlige for at varetage sager der rapporteres for regionale primærsektor enheder, som eksempelvis apoteker, praktiserende læger mv. Disse enheder er selvstændige organisationer, med selvstændige hierarkier i SOR, som ligger uden for regionernes ansvarsområde i SEB. Regionerne kan derved ikke direkte oprette initialmodtagere for de regionale primærsektorenheder. For at løse dette problem delegeres enhedsansvaret for de regionale primærsektorenheder til en eller flere specifikke SOR enheder i regionens SOR hierarki. Herefter kan regionen nu selv administrere, hvem af regionens brugere der skal initialmodtage sager fra de regionale primærsektorenheder. Delegationen til en SOR enhed i regionens hierarki sker ud fra 2 parametre: Enhedstype (Er det et apotek?) Postnummer (Hvilke postnummre gælder mapningen for?) Enhedstyper Følgende regionale primærsektor typer dækkes i DPSD2 per 15. dec På lokationsopslag under Andet Regionalt er primærsektorenhederne lagt sammen, hvilket nedenfor er illustreret med +: Lægepraksis Speciallægepraksis Tandlægepraksis + Tandpleje klinik Ergoterapiklinik + Fysioterapiklinik + Kiropraktorklinik + Statsautoriseret fodterapeut Jordemoderklinik Diætistklinik Apotek Lægevagt Regionale botilbud Formål At delegere rapporter til specifikke SOR enheder, når hændelsesstedet opfylder følgende krav Enheden har enhedstypen X Enhedens postnummer er Y 23

24 Eks. kan alle enheder med enhedstypen Apotek og postnummer fra , delegeres til en specifik SOR enhed i region X s SOR hierarki. Nuværende konfiguration Konfigurationen i forhold til denne mapning er flerstrenget, og beskrives herunder. Bemærk at punkt 1-4 er taget med i denne beskrivelse for at give overblik. Punkt 5 er den der reelt omhandler delegeringen af enhedsansvar, som dette afsnit omhandler. 1. Enhedstypen for primærsektorenheden (eks. Apotek) skal være oprettet i SOR så den kan tildeles til enheder i SOR. Det er Sundhedsdokumentation (kontor i Sundhedsstyrelsen) der varetager denne opgave. Enhedstyperne oprettes med udgangspunkt i SNOMED CT klassifikationen. 2. Der skal eksisterer en række enheder i SOR med pågældende enhedstype. Hvis enhedstypen er begrænset til SI niveau (som eks. lægevagt og bosted) er det medarbejdere i Sundhedsdokumentation, der skal oprette og vedligeholde enhederne på baggrund af input fra de SOR ansvarlige i regionerne. Hvis det er på OE niveau, kan regionerne selv oprette og vedligeholde enheden (eks. præhospitals enhed). 3. Enhedstypen skal aktiveres i DPSD2, med henblik på at definere hvilke kriterier der er med til at afgrænse netop denne enhedstype ud fra det samlede SOR register. Eksempelvis er Private hospitaler aktiveret som -> SI enheder med typen hospital, som har en overordnet IE af typen Privat. 4. Der skal oprettes en ny knap på siden med lokationsopslag for denne enhedstype, og den skal mappes til én af de 4 mulige overordnede hændelsessteder, som er beskrevet tidligere. 5. Der skal foretages en mapning for hver region, der definere hvordan rapporter for enheder med en specifik enhedstype, skal delegeres til en specifik SOR enhed i regionens hierarki. Hvilken region der modtager rapporten, vælges på baggrund af enhedens postnummer; at dette ligger i den specifikke region. I forhold til punkt 1-4, er der en vis proces i at oprette nye enhedstyper for DPSD2, som kræver at flere institutioner bliver enige. I forhold til punkt 5, er det mest af alt et spørgsmål om at se på de eksisterende enhedstyper og hvordan det kan sikres at de delegeres til de rette SOR enheder i regionernes SOR hierarki. 24

25 Mapningstabellen for punkt 5 består af følgende kolonner: SOR id Rolle Enhedstype Postnummer fra Postnummer til Dette er SOR id på den SOR enhed rapporterne skal delegeres til Dette dækker hvilken SEB rolle der skal være gældende for mapningen Dette er enhedstypen (eks. apotek) defineret ved koden i SOR Mapningen gælder alle postnummer der er større eller lig med denne. og mindre eller lig med denne. Er typisk både initialmodtager og sagsbehandler (behovet for både at modtage og sagsbehandle mappede sager) Per 15. dec. 2010: Postnummer mapningen er ikke så detaljeret som den burde, hvilket kan betyde at nogle regioner modtager sager fra postnumre, der ligger i andre regioner. Dette vil blive løst i en kommende opdatering. I forhold til hvilke SOR enheder primærsektorsagerne skal delegeres til, er mapningen i dag som følger: Region Hovedstaden Alle enhedstyper Region Hovedstaden > Service og administrative funktioner > Region Hovedstaden, Koncern Praksis Region Syd Alle enhedstyper Region Midt Alle enhedstyper Region Sjælland Alle enhedstyper Region Nord Alle enhedstyper Region Syddanmark Region Midtjylland > Service og administrative funktioner > Region Midtjylland, Primær Sundhed Region Sjælland > Patientsikkerhedskontoret Region Nordjylland > Service og administrative funktioner > Region Nordjylland, Praksissektoren Det er altså for de fede enheder at hver region skal oprette initialmodtagere og sagsbehandlere for primærsektorsager. 25

26 Særlige omstændigheder Enhederne i SOR indeholder ikke information om hvilken specifik region, enhederne tilhører, men kun hvilket postnummer de har. Det er derfor nødvendigt at foretage en mapning imellem postnumre og regioner, og er det der er årsagen til de 2 sidste kolonner i mapningstabellen ovenfor. På sigt formodes det at SOR vil blive udvidet til at validere adresseoplysninger på Erhverv og Byggestyrelsens Adressewebservice (AWS), som kan udvide SOR med information om præcis hvilke region en specifik enhed ligger i, ud fra enhedens adresse og husnummer. Dette vil kræve tilpasning af DPSD2, men vil fjerne behovet for at mappe postnumre. Der findes 22 postnumre som deler region, hvor postnummeret ikke entydigt kan placeres i den ene eller den anden region. Eksempelvis ligger postnummer 4000 både i region hovedstaden og region sjælland. Det er ikke muligt at dele et postnummer, og derfor skal der vælges en specifik region for hver af de 22 postnumre. Sundhedsstyrelsen har lavet et oplæg ud fra bedste vurdering, som beskrives nedenfor. Hvis de implicerede regioner er enige om en anden deling, kan nedenstående deling tilpasses. Postnummer By Valgte region Anden region 2640 Hedehusene Region Hovedstaden Region Sjælland 3670 Veksø Sjælland Region Hovedstaden Region Sjælland 4000 Roskilde Region Sjælland Region Hovedstaden 6830 Nørre nebel Region Syddanmark Region Midtjylland 6870 Ølgod Region Syddanmark Region Midtjylland 6880 Tarm Region Syddanmark Region Midtjylland 7100 Vejle Region Midtjylland Region Syddanmark 7120 Vejle øst Region Midtjylland Region Syddanmark 7160 Tørring Region Midtjylland Region Syddanmark 7173 Vonge Region Syddanmark Region Midtjylland 7260 Sønder omme Region Syddanmark Region Midtjylland 7270 Stakroge Region Syddanmark Region Midtjylland 7330 Brande Region Midtjylland Region Syddanmark 7361 Ejstrupholm Region Midtjylland Region Syddanmark 8722 Hedensted Region Midtjylland Region Syddanmark 8970 Havndal Region Midtjylland Region Nordjylland 8990 Fårup Region Midtjylland Region Nordjylland 26

27 9500 Hobro Region Nordjylland Region Midtjylland 9550 Mariager Region Nordjylland Region Midtjylland 9620 Aalestrup Region Nordjylland Region Midtjylland 9631 Gedsted Region Nordjylland Region Midtjylland 9632 Møldrup Region Nordjylland Region Midtjylland 27

28 Hvad skal du gøre? Der er en række opgaver som skal håndteres for denne mapning. De er beskrevet herunder: Stillingtagen til postnummer fordelingen er den til at arbejde med? Er der behov for yderligere enhedstyper end dem der kan fremsøges på lokationsopslag for nuværende? Med opmærksomheden på at dette kræver en større proces som involverer flere parter, herunder SOR og DPSD2 folk i regionerne, skal opgaven jo initieres ved et konkret behov/ønske. Findes de enheder i regionens SOR hierarki, som har en type der svarer til de enhedstyper der kan fremsøges ved lokationsopslag? Eksempelvis er det kun region nordjylland der per 15. dec har en SI enhed for bosteder i sit hierarki, hvilket betyder at det ikke er muligt at fremsøge bosteder for de andre regioner. Dette kræver at SOR ansvarlige i regionen kontakter kontoret Sundhedsdokumentation i Sundhedsstyrelsen mhp. at få oprettet de nødvendige enheder eller at regionerne på tværs bliver enige om at fjerne disse enhedstyper som valgmulighed. Per 15. dec findes der meget få eller ingen regionale enheder i SOR, med følgende enhedstyper: Bosteder Jordemoder klinik Diætistklinik og derfor vil der komme få eller ingen søgeresultater, hvis der søges efter hændelsessteder for disse enhedstyper. 28