Niveauangivelse for Regionale SOR koder gennem hierarki/type attribut Et af tre centrale forretningsbehov fra RSI SOR projektet, i relation til endelig udfasning af SHAK
Visionen bag SOR SOR indførtes for over 10 år siden, som Sundhedsvæsenets fælles organisations register Med det formål at kunne rumme forskellige typer af organisationer, på tværs af stat, regioner, kommuner, private sundhedsaktører/-organisationer og praksis, skabe overblik ift disse og gøre det muligt at identificere disse organisationer og deres organisatoriske enheder på utvetydig og unik vis. SOR har således skullet udgøre det autoritative register på dette område, driftet af SDS, opdateret af sundhedsvæsenets parter, understøttet i form af én central database instans, med unikke SOR nøgler/koder, webservices og browserbaserede brugergrænseflader. 2
Forretningsarkitekturen Siden SOR's indførsel har det bl.a. omfattet (indeholdt) den tidligere bærende Sygehus/Afdelingsklassifikation, SHAK samt den tidligere Partnerskabstabel i form af lokationsnumre, med EDI koder. SHAK indeholder sygehuse, overafdelinger og afdelinger, ikke noget derunder Ift. SHAK har de enkelte regioner og hospitaler suppleret med lokale afdelinger og afsnit, normalt mange under de enkelte officielle og uofficielle afdelinger. I praksis har man gjort det ved at udbygge SHAK for egen regions vedkommende med yderligere koder for lokale/uofficielle afdelinger og afsnit, normalt med ekstra tegn (tal og bogstaver) samt flere positioner. Denne kombinerede lokale/uofficielle og officielle klassifikation med afsæt i SHAK har man kaldt SHAK+. 3
Forretningsarkitekturen, fortsat I praksis har SHAK/SHAK+ fungeret som rygraden for langt de fleste klinisk/administrative systemer, med SHAK+ i forhold til den interne sammenhæng i regionerne, og med SHAK i forhold til omgivelserne og kommunikation hertil, med registrering, indberetning og integrationer mv. De fleste systemer understøtter SHAK/SHAK+ som anskaffet gennem udbud med krav herom, og som anvendt i det daglige. Nyere systemer har været anskaffet med krav om SOR kompatibilitet, men SHAK/SHAK+ har alligevel været den praktisk gennemgående struktur, som indeholdt i SOR (i forhold til SHAK), og som den gennemgående hoveddimension. 4
Forretningsarkitekturen, fortsat Denne stærke fundering i SHAK/SHAK+ strukturen skal ikke mindst findes i den indbyggede niveau opdeling med hospital, overafdeling, afdeling og afsnit som findes i alle regioner. Den afspejles i forskellige indberetninger, anvendes i mellemregionale og tværsektorielle integrationer samt internt i regionerne ift. systemlandskaberne og deres utallige integrationer, herunder i relation til: Det fælles billede af hvilke patienter der er, og hvor de befinder sig, hvornår Rekvisitioner, herunder laboratorieprøver og røntgen (afsender, modtager, logistik) Indberetninger og afregninger Eksternt ift hospitaler i andre regioner, eller afdelinger i andre regioner, med afsendelse af MedCom beskeder, samt registreringer mm i forhold til tværgående workflow 5
Forretningsarkitekturen, fortsat SHAK/SHAK+ har endvidere fungeret som grundlaget med en set fra slutbrugeren meget let genkendelig og praktisk anvendelig kodestruktur, med de første fire positioner (tal) for hospital, de næste 2 for Overafdeling og den sidste for Afdeling, som fx 1330076 for "Kir. Gastro dagkirurgi" på Amager- Hvidovre Hospital (1330). DA SOR ikke har tilsvarende eller lignende struktur, heller ikke som indbyggede eller definerede niveauer, og samtidigt omfatter SHAK, har SHAK/SHAK+ de facto fungeret som den fælles rygrad de sidste 10 år, blot med SOR som en form for ramme. 6
Forretningsarkitekturen, fortsat SHAK/SHAK+ strukturen er nem at navigere efter, men giver omvendt en lang række bindinger med meningsbærende koder, begrænset udfaldsrum, udfordringer ved styring af historik og versionering, problematisk genbrug af koder, mangel på niveauer til andre formål og en struktur der giver meget få frihedsgrader fx ved større organisatorisk ændringer og omlægninger Det har derfor også længe været bredt erkendt at SHAK/SHAK+ reelt har udspillet sin rolle. Men for at SOR reelt kan løfte arven efter SHAK/SHAK+, må SOR bibringes noget af den struktur og det indhold som har manglet, og som i høj grad handler om at identificere niveauer i de regionale hospitalsorganisationer, såvel ift. LPR2 som LPR3 7
SOR i forhold til Databehov Organisationsdata er et centralt eksempel på Master Data. I generel forstand udgør Master Data definerende, principielle nøgledata for virksomheder (fx kunder, produkter, tjenester, aktiver, leverandører, ansatte og lokationer). Master Data går således igen på tværs af mange systemer og typer af systemer. De kan karakteriseres ved attributter og nøgler, og hvor attributterne ofte er specifikke for de enkelte systemer, er nøglerne gennemgående. Master Data er et område der kommer stadig mere fokus på ift. omkostninger, effektivitet, muligheder for datadrevne forbedringer og genbrug af data. Organisationsdata er således en blanding af officielle nationale og lokale regionale, med vidt forskellige supplerende informationer i de enkelte regionale systemer 8
SOR i forhold til Databehov, fortsat Regionerne har implementeret SOR forskelligt, fx med forskellige hierarkidybder (antal lag) og placering i SOR. Dette bl.a. for at tilgodese forskellige organisatoriske behov, fx i relation til samling af sygehuse fordelt på geografiske lokationer og forskellige logisk/fysiske strukturer, typisk med forskellige navnekonventioner med kombinationer af betegnelser, geografi og elementer fra tidligere struktur (herunder SHAK) som gør det muligt at orientere sig. Der er ikke altid fuld overensstemmelse mellem SOR og SHAK. Det er ikke forventeligt at Regionerne vil kunne om-implementere SOR ensartet, ligesom også SHAK har været vredet (bl.a. med logiske og fysiske hospitaler). 9
SOR i forhold til Databehov, fortsat Men visse fællesnævnere er nødvendige, for at kunne håndtere en rygrad af fælles struktur og for bl.a. at kunne kommunikere eksternt. Denne struktur kunne være en niveauangivelse i form af: Region Hospital Center/Klinik/Overafdeling Afdeling Afsnit Eventuelt angivelse af om en organisatorisk enhed skal kunne benyttes eksternt 10
SOR i forhold til Databehov, fortsat Relationerne mellem de hierarkiske niveauer i SOR I registreringsvejledning for LPR3 benyttes niveauerne: Region, Hospital, Center, Afdeling, Afsnit Af registreringsvejledningen fremgår endvidere hvorledes registreringerne skal knyttes til disse niveauer. Det er vanskeligt som SOR er nu (uden SHAK). Det samme gælder valideringer. 11
Integrationer Det burde lette og kvalificere integrationer baseret på SOR i stedet for SHAK, hvis SOR koderne suppleres med en tilsvarende (eksplicit) niveauangivelse/typebetegnelse efter ovenstående i meddelelser, services og dokumenter mm. Lokationsnumre kan knyttes til organisatoriske enheder rimelig vilkårligt, og i princippet også niveauer under Afdelinger, ligesom de kan nedarves til underliggende niveauer (som Afsnit, selvom vi endnu ikke kender eksempler herpå). Ekstern kommunikation på afsnitsniveau eller andre SOR-niveauer, der ikke er indbygget i EPJ er og andre systemer vil ikke kunne lade sig gøre. Det må anbefales at parterne aftaler på hvilke niveauer der kan kommunikeres eksternt (fx fra Afdeling og opefter), eller at det gøres muligt i SOR at angive om organisatoriske enheder skal kunne benyttes til ekstern kommunikation 12
Forslag til ændring af SOR Man kunne forestille sig Mulighed for tilføjelse af ny type af klassifikationer til OE'er Mulighed for definition af værdier i disse klassifikationer Procesmæssigt vil man skulle aftale begge ovenstående elementer mellem parterne, for regionerne særligt mellem disse og staten (SDS). Dog kunne andre parter, ikke mindst Kommunerne, have tilsvarende behov, herunder i samspillet mellem regionerne og kommunerne. Forretningsbehovene (RSI) er meldt ind til SDS og står overfor kommende prioritering og finansiering 13