DPSD2 Guide 3:

dpsd.dk

DPSD2 Guide 3:

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


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

primærsektormapning)

23

2


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. 30.000 enheder. SOR er stadig

ikke 100% dækkende, så det forventes at tallet stiger yderligere de kommende år

(eksempelvis er der ca. 1000 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


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


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.

Hvad er SEB?

For at få adgang til SOR

Forudsætter adgang til Sundhedsdatanettet

1. SOR findes på https://sor.sundhedsstyrelsen.dsdn.dk

2. Klik på [Gæsteadgang]

3. Vælg menu ”Alle Enheder”

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


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 http://www.dpsd.dk, 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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. 2010. 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


Eks. kan alle enheder med enhedstypen ”Apotek” og postnummer fra 7000-7500,

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


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

Er typisk både

initialmodtager og

sagsbehandler

(behovet for både

at modtage og

sagsbehandle

mappede sager)

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.

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 Syddanmark

Region Midt

Alle enhedstyper Region Midtjylland > Service og administrative funktioner > Region Midtjylland,

Primær Sundhed

Region Sjælland

Alle enhedstyper Region Sjælland > Patientsikkerhedskontoret

Region Nord

Alle enhedstyper 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


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


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


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. 2010 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. 2010 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