Sundhedsvæsenets Organisationsregister (SOR) Regler i relation til Sygehus-afdelinger

Transkript

1 Sundhedsvæsenets Organisationsregister (SOR) Regler i relation til Sygehus-afdelinger

2 Indhold 1 SghAfd-regler Grundlæggende funktionalitet i SOR-applikationen Anvendt terminologi Regler for SghAfd Konsistens i SghAfd Regler ved redigering af SghAfd Redigeringsvejledning Note vedr. konsekvenser af SghAfd-regler: SghAfd-forretningslogik, formel Konsistens i forhold til SOR-træet Omlægninger til nye SghAfd-koder Gyldighedskriterier for SghAfd-koder Regler for konsistens i mapningen Delgrene i SOR-træet Opret, flyt og luk SOR-kode Opret, flyt og luk SghAfd-mapning SghAfd-udtræk Deltaudtræk Udtræk af SghAfd-total Udtræk af SghAfd-koder mappet fra SOR Placering af SghAfd-udtræk Brugergrænseflader 23 1

3 1 SGHAFD-regler Den nuværende Sygehus-afdelingsklassifikation (SghAfd) vil trods integrationen i SOR-applikationen fortsat leve sit eget liv. For også efter overgangen til SOR at kunne anvendes i de eksisterende PAS-systemer og til opgørelser mv. skal den nuværende forretningslogik for vedligehold af SghAfd isoleret set stadig være gældende. 1.1 Grundlæggende funktionalitet i SOR-applikationen Idet SOR og SghAfd ud fra et logisk synspunkt må ses som to klassifikationer, der lever hver deres liv mens de i praksis, inden for deres respektive begrænsninger, grundlæggende skal afspejle den samme virkelighed vil der blive mulighed for at vedligeholde og redigere dem hver for sig. Således kan oprettelsen af et nyt delhierarki i SOR med tilhørende mapning til SghAfd logisk anskues som en række handlinger i 3 trin: oprettelse af SghAfd-koder oprettelse af SOR-koder oprettelse af mapning fra SOR til SghAfd SghAfd-koderne kan oprettes i en separat handling, således at de inden for rammerne af de almindelige SghAfd-regler og -retningslinier kan oprettes med tilbagevirkende kraft. Dette gør at det er muligt at anvende dem i de lokale patientadministrative systemer til overførsel af henvisningsperioder mv. inden den faktiske ibrugtagning, dvs. inden de reelt skal anvendes i den løbende patientregistrering. SOR-koderne kan oprettes i en separat handling inden for de regler, der gælder for SOR-delen. Hvis de SghAfd-koder, som nye SOR-koder skal mappe til, allerede er oprettet og gyldige med hensyn til SghAfd-historik, kan relevante SOR-koder sættes til at mappe til disse i samme arbejdsgang. I modsat fald må SghAfd-koderne oprettes og mapningen efterfølgende foretages i en egen arbejdsgang. Det vil derfor generelt være hensigtsmæssigt, at SghAfd-koder, der skal mappes fra SOR, er oprettet på forkant. Både i forbindelse med SOR og SghAfd vil det gælde, at koder oprettes "oppefra og ned", mens koder lukkes "nedefra og op". Sundhedsvæsenets Organisationsregister - SOR 2

4 1.2 Anvendt terminologi Der er af historiske årsager ikke overensstemmelse mellem den terminologi, der anvendes i selve SghAfd i dag og den terminologi, der anvendes i kontaktmodellen som denne er defineret i Fællesindholdet og implementeret i Landspatientregisteret (LPR). Tabellen nedenfor angiver sammenhængen mellem SghAfd og kontaktmodellens terminologi, dvs. den terminologi, der er anvendt i Fællesindholdet. LPR-terminologi SghAfd-terminologi Antal SghAfd-karakterer Sygehus Sygehus 4 karakterer Afdeling/stamafdeling Overafdeling 6 karakterer Afsnit/stamafsnit Afdeling 7 karakterer Bemærk at termen 'afdeling' således anvendes i begge domæner, men i forskellig betydning I det følgende vil der overvejende blive anvendt LPR-terminologi, dvs. sygehus (4 karakterer), afdeling (6 karakterer) og afsnit (7 karakterer). Syntaks mv. for de tre typer af koder er opstillet i separat regne ark. En komplet post med samtlige attributter kaldes en SghAfd-kode, mens selve 4-, 6- eller 7-karakters koden i lighed med tidligere kaldes SKS-koden. Det hierarkiske træ, der kan bygges på grundlag af SghAfd-kodernes SKS-kode betegnes SghAfd-træet. I det følgende angives forretningslogik for validering af SghAfd-træet og efterfølgende for SghAfd-konsistens i forhold til SOR-træet. Sundhedsvæsenets Organisationsregister - SOR 3

5 1.3 Regler for SghAfd Konsistens i SghAfd Generelt gælder det princip, at SghAfd sorterer sig selv via SKS-koden. Den sorteres som en flad fil efter kodenummerorden. Træstrukturen i SghAfd ligger derfor kun implicit i SKS-koden, hvor en SghAfd-kode fortolkes som mor til en SghAfdkode på næste hierarkiske niveau (dvs. kodelængde), når sidstnævnte indeholder førstnævntes SKS-kode som præfix. Således vil SghAfd-koden med SKS-koden '1234' tolkes som mor til SghAfdkoden med SKS-koden '1234A1', mens sidstnævnte igen vil tolkes som mor til SghAfd-koden med SKS-koden '1234A19'. De følgende fire regler skal derfor sikre konsistens i SghAfd-træet i sig selv og medfører, at når et sygehus- eller en overafdelingskode mister sit sidste barn, skal den selv lukkes, og at en gyldig afdelings- eller afsnitskode ikke kan leve videre uden en mor. I disse regler indgår altså også et tidsaspekt, hvor det gælder, at en SghAfd-kode ikke kan have et tidsmæssigt gyldighedsinterval, der rækker ud over dens hierarkiske mors samlede gyldigheddsinterval. 1. Bottom-up (Skal sikre, at hierarkiet er et ægte monohierarki): a. Hvis der findes en gyldig afsnitskode (7 karakterer), skal der findes én og kun en gyldig afdelingskode, som er lig med de første 6 karakterer for afnitskoden. b. Hvis der findes en gyldig afdelingskode (6 karakterer), skal der findes én og kun en gyldig sygehuskode, som er lig med de første 4 karakterer for afdelingskoden. 2. Top-down (Skal sikre, at der ikke findes barnløse forældre, dvs. 4- eller 6- karakters koder uden børn): a. Hvis der findes en gyldig sygehuskode (4 karakterer), skal der findes mindst én gyldig afdelingskode (6 karakterer), hvis første 4 karakterer er lig med sygehuskoden. b. Hvis der findes en gyldig afdelingskode (6 karakterer), skal der findes mindst én gyldig afsnitskode (7 karakterer), hvis første 6 karakterer er lig med afdelingskoden. Reglerne 1a og 1b skal altid være opfyldt, da forældreløse børn ikke tillades. Hvornår reglerne 2a og 2b skal valideres, skal afklares. Der vil være tidsrum, hvor disse regler ikke vil være opfyldt, da de højere niveauer i SghAfd-træet i sagens natur må oprettes før børnene kan oprettes. Kernen i disse regler er, at sygehus- og afdelingskoder ikke kan stå barnløse i længere tid Regler ved redigering af SghAfd I dag valideres den gældende forretningslogik især vedrørende store og små ændringer (dvs. med og uden historik) til dels humant. Det er altså ofte et vurderingsspørgsmål, hvorvidt en ændring af en SghAfd-kode skal foretages som en stor eller lille ændring. De generelle retningslinier foreskriver, at en ændring, der begrebsmæssigt ændrer indholdet af en SghAfd-kode, skal udføres som en stor ændring, dvs. med historik, Sundhedsvæsenets Organisationsregister - SOR 4

6 hvor den gældende kode lukkes og en ny med samme SKS-kode og det ændrede indhold oprettes. Ændring af specialeangivelser vil pr. definition altid være en stor ændring. Derimod vil en mindre ændring af selve kodeteksten fx rettelse af stavefejl e.l. kunne foretages som en overskrivning af eksisterende kodetekst, dvs. som en lille ændring. Men som nævnt vil det fremover stadig være en vurderingssag, hvorvidt en given ændring af en kodetekst for en SghAfd-kode medfører en begrebsmæssig ændring, og der vil være grænsetilfælde, hvor der kan argumenteres både for og imod. I sådanne tilfælde anbefales det at udføre ændringen som en stor ændring. For at kunne udføre mere af valideringsarbejdet maskinelt, opstilles nedenfor en simplificeret forretningslogik, som dog samtidig opretholder den grundlæggende logik Redigeringsvejledning 1. Oprettelse af ny SghAfd-enhed: 1.1. Tidligere anvendte SghAfd-koder (for såvel lukkede som aktuelt gyldige enheder) kan ikke anvendes for ny enhed Oprettelse af en enhed kan ske med tilbagevirkende kraft pr året før aktuelle år. For afdelinger og afsnit kan startdato dog tidligst sættes til moderens startdato. Moderens startdato regnes fra startdatoen for den samlede serie af potentielt flere mulige SghAfd-poster med samme SghAfd-kode, der over tid har afløst hinanden 1.3. Der kan ikke oprettes ny enhed under en lukket enhed, uanset om moderen er de facto lukket eller ej Nyoprettelse under en lukket enhed ville medføre, at enhedens gyldighedsinterval ville række ud over moderens En enheds navn (kodeteksten) kan ikke være på mere end 60 karakterer 1.5. For sygehuse skal der angives institutions- og ejertype. For regionalt ejede sygehuse skal der angives ejer For afsnit skal der angives mindst ét speciale (hovedspecialet) og optionalt 3 bispecialer. Specialerne skal udfyldes i rækkefølge "oppefra". Der må ikke være dublerede specialeangivelser for et afsnit. 2. Ændring af eksisterende SghAfd-enhed uden historik: Ved ændring uden historik overskrives den eksisterende kode for den enhed, der er valgt Der kan kun ændres i enhedens navn (kodeteksten) for den valgte enhed Der kan ikke foretages ændring for en enhed, der er de facto lukket En enhed er de facto lukket når dens slutdato ligger mindre end 8 dage efter dags dato 3. Ændring af eksisterende SghAfd-enhed med historik: Ved ændring med historik lukkes den eksisterende kode for den enhed, der er valgt og lukkedato sættes til dagen før den valgte ikrafttrædelsesdato for ændringen. Der oprettes en ny kode med startdato svarende til ikrafttrædelsesdato for ændringen og slutdato svarende til slutdatoen for den valgte enhed. Dette betyder, at den nye kode "arver" lukkedatoen for den valgte enhed uanset om denne er åben (slutdato = ' ') eller lukket (slutdato < ' '). Sundhedsvæsenets Organisationsregister - SOR 5

7 3.2. Der kan ændres i enhedens navn (kodeteksten) for den valgte enhed. For sygehuskoder kan der ændres i angivelser af ejer- og institutionstype samt institutionsejer. For afsnitskoder kan der ændres i specialeangivelser Der kan ikke foretages ændring for en enhed, der er de facto lukket En enhed er de facto lukket når dens slutdato ligger mindre end 8 dage efter dags dato 3.4. Ikrafttrædelsesdatoen for ændringen skal ligge mellem den valgte kodes start- og slutdato, dog tidligst dags dato plus 8 dage. Da ændringen medfører en lukning af den valgte kode, skal ikrafttrædelsesdatoen ligge mindst 8 dage fremme. 4. Lukning af SghAfd-enhed: Ved lukning lukkes den eksisterende kode for den valgte enhed ved overskrivning af den hidtil gældende slutdato 4.2. Der kan ikke foretages lukning for en enhed, der er de facto lukket En enhed er de facto lukket når dens slutdato ligger mindre end 8 dage efter dags dato En enhed kan ikke lukkes, hvis den har aktive børn, der har et gyldighedsinterval, der kommer til at række ud over koden, der skal lukkes Lukkedato kan tidligst være dags dato plus 8 dage En allerede lukket, men ikke de facto lukket enhed kan lukkes med ny lukkedato eller genåbnes, hvis dens gyldighedsinterval ikke kommer til at række ud over gyldighedsintervallet for dens mor. Dette betyder, at for enheder, der er lukket men ikke de facto lukket, kan lukkedatoen ændres under iagttagelse af reglerne 4.2, 4.3 og 4.4. Derved kan en enhed i princippet også genåbnes (datotil = ' ') Note vedr. konsekvenser af SghAfd-regler: En af konsekvenserne ved ovenstående regler er, at det ikke er muligt at rette (herunder lukke) allerede oprettede koder med tilbagevirkende kraft (bortset fra ændringer af kodeteksten for en enhed, der kan udføres som en lille ændring). Hvis man har oprettet en ny afsnitskode med tilbagevirkende kraft dvs. med en startdato, der ligger før dags dato, og man senere opdager, at der fx er sat forkert speciale på, så skal en rettelse foretages som en stor ændring, dvs. en ændring med historik. Dette medfører igen, at man tidligst kan effektuere ændringen 8 dage fra dags dato, hvorved de fejlagtige specialer står ved magt fra den oprindelige startdato og frem til ændringsdatoen. Da koden i princippet er publiceret, når den bliver kommittet til databasen via gemknappen, er det ikke umiddelbart muligt at stille en simpel slettefunktion til rådighed, der fjerner den fejlagtige kode fra databasen. Dette ville kræve en tilsvarende mulighed for at melde sletninger af koder ud via opdateringsfilerne, en mulighed, der ikke eksisterer idag. Hvis denne konsekvens på sigt viser sig at være for uhensigtsmæssig, er der flere muligheder for logisk at løse dette, men alle kræver ændringer i forretningslogik og deraf følgende ny-implementering. Der gives mulighed for, at ændring af specialer på lige fod med kodeteksten kan udføres som lille ændring Sundhedsvæsenets Organisationsregister - SOR 6

8 o Dette giver mulighed for at rette specialer arbitrært langt tilbage i tiden, hvorfor denne mulighed i praksis næppe vil blive anset for at være hensigtsmæssig. Løsningen giver ikke mulighed for at slette decideret fejloprettede koder. Der gives mulighed for, at ændring af specialer kan udføres som lille ændring inden for et begrænset antal dage efter oprettelsen o Denne løsningsmulighed giver i lighed med den første ikke mulighed for at slette fejloprettede koder. Der indføres en slettefunktion, hvor Validering D = '2' oplyser de lokale systemer om, at pågældende eksisterende kode skal slettes fra lokale stamdata, svarende til at Validering D = '1' og Validering D = '3' betyder henholdsvis oprettelse af ny kode og ændring af eksisterende i dag. o Dette er en løsning, der formentlig vil kræve ny-implementering i alle lokale systemer, der anvender SKS og SghAfd. Løsningen kunne alligevel være relevant, da det tidligere har vist sig uhensigtsmæssigt at slettemuligheden oprindeligt blev fravalgt, hvorfor det i dag ikke er muligt at meddele sletninger af deciderede fejloprettede SKS- og SghAfd-koder SghAfd-forretningslogik, formel Anvendte termer: ID2: newcode: sættet af koder, der er identiske på de to første nøglefelter i SghAf, dvs. recordart og SKS-kode. Hvis der er flere koder i sættet, vil det oftest være koder, der over tid afløser hinanden, svarende til en kode, der har undergået en eller flere ændringer med historik. angiver en ny kode ved henholdsvis nyoprettelse samt ny kode indeholdende ændringer i forbindelse med stor ændring (med historik) currentcode: angiver en eksisterende kode ved henholdsvis lille ændring (uden historik), lukning samt eksisterende kode, der skal lukkes ved stor ændring (med historik) DagsDato: datoen for udførelsen af en SghAfd-handling Følgende er "pladsholdere" for brugerens angivelser af data via brugergrænsefladerne: NySKSkode, NyStartdato, NySlutdato, NyKodetekst, NyInstitutionsart, NyEjerforhold, NySpeciale_A, NySpeciale_B, NySpeciale_C, NySpeciale_D Sundhedsvæsenets Organisationsregister - SOR 7

9 Tabel 1: Handling: oprettelse kompleks nøgle recordart Oprettelse af ny kode kan ske under hensyntagen til konsistens i SghAfd-hierarkiet Ved nyoprettelse er genbrug af eksisterende gyldige såvel som lukkede koder ikke tilladt sættes af system sygehuskode: newcode.recart := 'sgh' afdelingskode, afsnitskode: newcode.recart := 'afd' SKSkode sættes af bruger HVIS NySKSkode <> ID2.alle [1] SÅ newcode.skscode := NySKSkode datofra sættes af bruger sygehuskode: HVIS NyStartdato >= aktuelle år - 1 år SÅ newcode.date_from := NyStartdato afdelingskode, afsnitskode: HVIS NyStartdato >= aktuelle år - 1 år OG NyStartdato >= parentcode.date_from [2] OG parentcode.date_to = ' ' [3] SÅ newcode.date_from := NyStartdato datotil sættes af system newcode.date_to := ' ' [4] kodetekst sættes af bruger HVIS LEN(NyKodetekst) <= 60 [5] SÅ newcode.code_text := NyKodetekst gruppe A: hovedspeciale sættes af bruger gruppe B: bispeciale 1 sættes af bruger gruppe C: bispeciale 2 sættes af bruger gruppe D: bispeciale 3 sættes af bruger gruppe E validering D datoændring sygehuskode: newcode.grp_a := NyInstitutionsart afsnitskode: newcode.grp_a := NySpeciale_A sygehuskode: newcode.grp_b := NyEjerforhold afsnitskode: HVIS NySpeciale_B <> NySpeciale_A SÅ newcode.grp_b := NySpeciale_B afsnitskode: HVIS NySpeciale_C <> NySpeciale_A OG NySpeciale_C <> NySpeciale_B SÅ newcode.grp_c := NySpeciale_C afsnitskode: HVIS NySpeciale_D <> NySpeciale_A OG NySpeciale_D <> NySpeciale_B OG NySpeciale_D <> NySpeciale_C SÅ newcode.grp_d := NySpeciale_D sættes af system newcode.grp_e := 'SKS' sættes af system newcode.val_d := '1' sættes af system newcode.date_changed := DagsDato [1] Betingelsen "NySKSkode <> ID2.alle" skal udtrykke, at ved en nyoprettet SghAfd-kode skal SKS-koden være forskellig fra alle hidtidigt anvendte SKSkoder. Det eneste tilfælde, hvor en form for genbrug er tilladt, er ved specialtilfældet 'ændring med historik', dvs. en stor ændring (se tabel 3) [2] Startdatoen (DATE_FROM) for moren til den nye kode vil være startdatoen for den første kode i en serie af potentielt flere SghAfd-koder med samme SKS-kode, der via store ændringer har afløst hinanden. En sådan serie betragtes ud fra en tidsmæssig synsvinkel som én kode. Reglen har som logisk konsekvens, at SghAfd-træet i forbindelse med et givet sygehus skal oprettes oppe fra og ned (ligesom det ved lukning skal lukkes nede fra og op). Sundhedsvæsenets Organisationsregister - SOR 8

10 [3] Det er kun muligt at oprette afdelings- og afsnitskoder, hvis moderen selv er en åben kode (dvs. har en slutdato lig ). [4] Sættes default til ' ' svarende til en åben kode. Hvis koden ønskes oprettet i et begrænset tidsrum, må lukkedato efterfølgende sættes i separat arbejdsgang i form af lukning. [5] Længden af selve kodeteksten må i overensstemmelse med de almindelige SKS-regler ikke være på mere end 60 karakterer. Ændring af eksisterende kode Ændringer af eksisterende koder kan ske med eller uden historik (store og små ændringer; tabel 2 og 3) Ved ændring uden historik kan kun kodeteksten ændres. Denne ændring vil altså slå igennem bagud i tid fra kodens oprindelige startdato og derfor gælde i hele kodens tidsmæssige gyldighedsinterval. Ved ændring med historik lukkes den valgte kode og en ny med samme SKS-kode oprettes. Ved en sådan ændring kan både kodeteksten og specialeangivelserne ændres. Ændring af speciale for et afsnit kan kun udføres med historik, så denne ændring ikke får lov til at slå bagud i tid og derved i praksis ændre allerede genererede statistikker mv. baseret på specialeangivelser. Om en ændring af kodeteksten skal ske med eller uden historik er en vurderingssag. Dette bestemmes normalt ud fra en overvejelse om, hvor vidt ændringen medfører en semantisk ændring af informationsindholdet i kodeteksten eller bare er en rettelse af stavefejl og andre uhensigtsmæssigheder. Der kan dog være tilfælde, hvor det er ønskeligt at en semantisk ændring slår tilbage i tid, og koden derfor ændres uden historik. Tabel 2: Den kode, der skal undergå en ændring, vælges og den nye kodetekst angives. Ved lille ændring er det kun muligt at ændre kodetek- Handling: ændring uden historik sten. kompleks recordart nøgle SKSkode datofra datotil kodetekst sættes af bruger HVIS currentcode.date_to >= DagsDato + 8 [1] OG LEN(NyKodetekst) <= 60 SÅ currentcode.code_text := NyKodetekst gruppe A: hovedspeciale gruppe B: bispeciale 1 gruppe C: bispeciale 2 gruppe D: bispeciale 3 gruppe E validering D datoændring sættes af system currentcode.grp_e := 'SKS' sættes af system currentcode.val_d := '3' sættes af system currentcode.date_changed := DagsDato [1] Betingelsen sikrer, at der ikke kan ændres i en kode, der er de facto lukket Sundhedsvæsenets Organisationsregister - SOR 9

11 Tabel 3: Handling: ændring med historik kompleks nøgle Den kode, der skal undergå en ændring, vælges. Ved stor ændring er det muligt at ændre kodeteksten samt speciale angivelser. De to delhandlinger, hvor den valgte kode lukkes og der oprettes en ny med samme SKS-kode, udføres som én transaktion ud fra brugerens angivelser Luk gældende kode Den kode, der skal ændres, vælges og der skal angives en dato for, hvornår ændringen skal træde i kraft (NyStartdato). Det skal sikres, at kun den sidste post i et sæt af poster med samme SKS-kode (ID2.sidste), kan lukkes i forbindelse med en ændring med historik, og denne kan kun lukkes, hvis lukkedato ikke allerede er overskredet Ændringen kan ikke ske med tilbagevirkende kraft, da dette vil medføre, at den gældende kode skulle lukkes med tilbagevirkende kraft. recordart SKSkode datofra datotil sættes af bruger HVIS currentcode = ID2.sidste [1] OG currentcode.date_to >= DagsDato + 8 [1] OG NyStartdato >= DagsDato + 8 [2] OG NyStartdato >= currentcode.date_from [3] OG NyStartdato <= currentcode.date_to [3] SÅ currentcode.date_to := NyStartdato 1 dag kodetekst gruppe A: hovedspeciale gruppe B: bispeciale 1 gruppe C: bispeciale 2 gruppe D: bispeciale 3 gruppe E sættes af system currentcode.grp_e := 'SKS' validering D sættes af system currentcode.val_d := '3' datoændring sættes af system currentcode.date_changed := DagsDato fortsættes næste side [1] De to betingelser skal sikre, dels at den valgte kode er den sidste i en eventuel række af flere mulige med samme SKS-kode, og dels at denne kode ikke er de facto lukket, dvs. allerede er lukket eller lukker inden for de næste 8 dage. [2] Da NyStartDato er udgangspunktet for lukning af den valgte kode, der skal ændres, må NyStartDato ligge et antal dage (>= 8) ude i fremtiden, for at den valgte kode ikke lukkes med tilbagevirkende kraft. [3] De to betingelser sikrer tilsammen at NyStartDato ligger inden for den valgte kodes gyldighedsinterval. Sundhedsvæsenets Organisationsregister - SOR 10

12 Tabel 3: fortsat kompleks nøgle Opret ny, afløsende kode Ny kode til afløsning af den lukkede kode. Har identisk SKS-kode og skal starte dagen efter, at den kode, der skal ændres med historik, er lukket. Brugerspecificerede data (kodertekst og specialer) sættes af bruger sættes af system newcode.recart := currentcode.recart sættes af system newcode.skscode := currentcode.skscode recordart SKSkode datofra sættes af bruger newcode.date_from := NyStartdato [1] datotil sættes af system newcode.date_to := currentcode.date_to [2] kodetekst sættes af bruger HVIS LEN(NyKodetekst) <= 60 SÅ newcode.code_text := NyKodetekst gruppe A: hovedspeciale sættes af bruger sygehuskode: newcode.grp_a := NyInstitutionsart afsnitskode: newcode.grp_a := NySpeciale_A gruppe B: bispeciale 1 sættes af bruger sygehuskode: newcode.grp_b := NyEjerforhold afsnitskode: HVIS NySpeciale_B <> NySpeciale_A SÅ newcode.grp_b := NySpeciale_B gruppe C: bispeciale 2 sættes af bruger afsnitskode: HVIS NySpeciale_C <> NySpeciale_A OG NySpeciale_C <> NySpeciale_B SÅ newcode.grp_c := NySpeciale_C gruppe D: bispeciale 3 sættes af bruger afsnitskode: HVIS NySpeciale_D <> NySpeciale_A OG NySpeciale_D <> NySpeciale_B OG NySpeciale_D <> NySpeciale_C SÅ newcode.grp_d := NySpeciale_D gruppe E sættes af system newcode.grp_e := 'SKS' validering D sættes af system newcode.val_d := '1' datoændring sættes af system newcode.date_changed := DagsDato [1] Betingelserne for korrekt angivelse af NyStartDato er kontrolleret under koden, der er blevet lukket i ændringstransaktionen. [2] Den ny-genererede SghAfd-post overtager slutdatoen for den valgte SghAfd-post, uanset om denne var åben eller lukket (frem i tiden) på tidspunktet for ændringen. Sundhedsvæsenets Organisationsregister - SOR 11

13 Handling: lukning kompleks nøgle Den kode, der skal lukkes, vælges og lukkedato angives. Der kan kun vælges koder, der pr. dags dato ikke er lukket og ikke lukker inden for de næste 8 dage. Koder kan tidligst lukkes med effekt pr. dags dato plus 8 dage. Bemærk at for allerede lukkede koder (datofra <> ' '), hvor lukkedato er større end dagsdato, kan ny lukkedato, der i øvrigt opfylder reglerne for lukkedatos værdi, påføres. Dette vil sige, at når lukkedatoen endnu ikke er nået (dagsdato < lukkedato), og koden dermed pr. dagsdato stadig er gyldig, kan lukkedato ændres i henhold til de opstillede regler for lukning i øvrigt. Det skal sikres, at koder, der er lukket pga. en ændring med historik, ikke kan få ny lukkedato, selvom de pr. dagsdato stadig er gyldige (hvis ændringen først effektueres senere). Dette skal sikres ved, at kun den sidste post i et sæt af poster med samme SKSkode, kan få ny lukkedato. Der skelnes skarpt mellem ændringer og lukninger, hvor lukning er en funktionalitet, hvor kun lukkedatoen ændres. Dette vil sige at rettelser af stavefejl mv. i kodeteksten som ellers gerne må slå tilbage i tid (dvs. en lille ændring), ikke kan udføres sammen med en lukning, men må udføres i en egen arbejdsgang forinden lukningen. recordart SKSkode datofra datotil sættes af bruger Sygehuskode: HVIS currentcode = ID2.sidste [1] OG currentcode.date_to >= DagsDato + 8 [1] OG NySlutdato >= DagsDato + 8 OG NySlutdato <= ' ' [2] SÅ currentcode.date_to := NySlutdato; kodetekst gruppe A: hovedspeciale gruppe B: bispeciale 1 gruppe C: bispeciale 2 gruppe D: bispeciale 3 gruppe E validering D datoændring Afdelingskode, Afsnitskode: HVIS currentcode = ID2.sidste [1] OG currentcode.date_to >= DagsDato + 8 OG NySlutdato >= DagsDato + 8 OG NySlutdato <= parentcode.date_to [3] SÅ currentcode.date_to := NySlutdato; sættes af system currentcode.grp_e := 'SKS' sættes af system currentcode.val_d := '3' sættes af system currentcode.date_changed := DagsDato [1] De to betingelser skal sikre, dels at den valgte kode er den sidste i en eventuel række af flere mulige med samme SKS-kode, og dels at denne kode ikke er de facto lukket, dvs. allerede er lukket eller lukker inden for de næste 8 dage. [2] Da det er muligt at sætte ny slutdato til ' ', kan man på denne måde "genåbne" ellers lukkede SghAfd-koder. Dette er dog kun muligt så længe Sundhedsvæsenets Organisationsregister - SOR 12

14 den aktuelle lukkedato ikke er overskredet, og koden dermed vil være endeligt lukket. [3] For afdelings- og afsnitskoder skal lukkedatoen ligge før eller samtidig med dens hierarkiske mor. Disse koder kan derfor også "genåbnes", men en sådan "genåbning" kan kun gennemføres, hvis kodens mor ikke er lukket. 1.4 Konsistens i forhold til SOR-træet Dette afsnit vedrører mapningen fra SOR til SghAfd, og er et oplæg til forretningsregler, der skal sikre konsistens mellem SOR- og SghAfd-træet. Hvor mange og hvilke af disse, der skal give anledning til implementerede regler og valideringer i SOR-applikationen, skal afklares. Reglerne bygger på, at der foretages fuld mapning, dvs. at der fra SOR mappes til alle 3 niveauer i SghAfd. Bemærk, at der ikke kan valideres på, om konsistensen mellem SOR- og SghAfdtræet er semantisk meningsfuld. Der kan valideres på at SOR-træet er konsistent, at SghAfd-træet er konsistent samt at sammenhængen mellem de to træer er logisk konsistent, dvs. at enhver delgren i SOR-træet hvis den er SghAfd-relevant mapper til henholdsvis en 4, 6 og 7-karakters SghAfd-kode i den rigtige rækkefølge, men dette medfører ikke pr. automatik, at mapningen er semantisk hensigtsmæssig. Konsistensen kan gå fra den totale konsistens (ingen krydsende mapningslinjer mellem SOR- og SghAfd-træet) til kun at gælde konsistens i selve SghAfd-træet. Der skal rimeligvis fastlægges et niveau, der ligger et sted i mellem de to yderpunkter Omlægninger til nye SghAfd-koder Med de eksisterende lokale PAS-systemer og det deraf fortsatte behov for at indberette til LPR på grundlag af SghAfd, vil det stadig være et behov for at kunne oprette nye SghAfd-koder med unik SKS-kode, der tidsmæssigt overlapper med eksisterende SghAfd-koder til trods for at de repræsenterer de samme fysiske enheder. Samtidig er det en del af SOR-applikationens grundlæggende funktionalitet, at der fra en given SOR-kode kun kan mappes til én SghAfd-kode ad gangen. Hvis den samme SOR-kode derfor repræsenterer en enhed, der skal have ny sygehusafdelingskode fx i forbindelse med en omlægning af SghAfd, kan dette medføre et behov for at oprette den nye SghAfd-kode uden at der med det samme mappes til denne fra SOR-koden. Man kan via SOR editere selve mapningerne for sig. Med SOR som vedligeholdelsesapplikationen for SghAfd er det derfor muligt separat at oprette SghAfd-koder, uden at disse med det samme mappes fra SOR-træet. Samtidig er det muligt at lukke en mapning til en SghAfd-kode uden at denne samtidig lukkes Gyldighedskriterier for SghAfd-koder I forhold til i dag, hvor en SghAfd-kodes gyldighed udelukkende bestemmes ud fra dens start- og slutdato, kommer der med SOR og mapningen mellem SOR- og SghAfd-træet en ekstra dimension ind, der kan have indflydelse på opfattelsen af en SghAfd-kodes gyldighed vedr. anvendelse til registrering og indberetning. Sundhedsvæsenets Organisationsregister - SOR 13

15 Der kan som konsekvens heraf opstilles to kriterier for gyldigheden af en SghAfdkode: Gyldighed for SghAfd-koden i sig selv, dvs. SghAfd-historikken beskrevet ved start- og slutdato Gyldighed i forhold til SOR-træet og mapning fra dette, dvs. alle koder, der aktuelt mappes til og som en konsekvens heraf må være gyldige mht. SghAfd-historik Logisk set vil det kun være de SghAfd-afsnitskoder, der aktuelt mappes til, der skal kunne anvendes ved indberetning. Hvis der derfor i et givet tidsrum ikke mappes til en ud fra den rene SghAfd-historik ellers gyldig SghAfd-kode fra SOR-træet, kan koden i dette tidsrum ikke anvendes til registrering og efterfølgende indberetning. Det skal samtidig være muligt at foretage efterregistreringer på koder, der aktuelt ikke er mappet, når disse registreringer vedrører tidsrummet, hvor koden var mappet. Ved lokale konverteringer til nye PAS-systemer, der anvender SghAfd, og de deraf følgende overførsler af henvisningsperioder skal det være muligt at angive henvisningsdatoer (og muligvis også andre oplysninger), der ligger forud for det tidspunkt, hvor en given SghAfd-kode bliver mappet fra SOR. 1.5 Regler for konsistens i mapningen Som nævnt tidligere bygger nedenstående regler på, at der foretages fuld mapning mellem SOR- og SghAfd-træet. Hvor mange af disse regler, der skal implementeres og hvornår, skal afklares i forbindelse med kommende versioner af SOR. I de følgende tabeller er oplistet handlinger og valideringer ved opret SOR-kode flyt SOR-kode luk SOR-kode opret mapning fra SOR til SghAfd flyt mapning fra SOR til SghAfd luk mapning fra SOR til SghAfd Opret, flyt og luk svarer grundlæggende parvis til hinanden, således at fx forskellen på 'opret SOR-kode' og 'opret mapning fra SOR til SghAfd' består i, at i første tilfælde oprettes SOR-koden i samme arbejdsgang som mapningen til eksisterende SghAfd-kode, mens SOR-koden i andet tilfælde allerede er oprettet inden mapningen oprettes i separat arbejdsgang. Alle tabeller er dog taget med for komplethedens skyld, da der på sigt kunne opstå behov for differentiering. Sundhedsvæsenets Organisationsregister - SOR 14

16 1.5.1 Delgrene i SOR-træet Ved ændringer i mapningen skal der generelt valideres for konsistens i mapningen, dvs. om berørte delgrene i SOR-træet mapper konsistent til SghAfd. Med en delgren i SOR-træet menes en gren, der går fra top til bund i lige linje, dvs. én kode fra hvert niveau i træet. Der vil derfor være ligeså mange delgrene, som der er blad-koder, dvs. koder på laveste niveau i træet. To eksempler på delgrene i det samme SOR-træ. Som det fremgår af eksemplerne behøves der ikke at være lige mange koder i delgrene for et givet del-træ. Sundhedsvæsenets Organisationsregister - SOR 15

17 1.5.2 Opret, flyt og luk SOR-kode Handling Opret SOR-kode SORtype SI OE SghAfd mapning sygehuskode Handling: SghAfd-mapning := gyldig sygehuskode; sygehuskode gyldig på starttidspunkt for SOR-kode; ingen Handling: afdelingskode Handling: SghAfd-mapning := gyldig afdelingskode; afdelingskode gyldig på starttidspunkt for SOR-kode; konsistens i mapning: SghAfd-mor mappet [1] ; afsnitskode Handling: SOR-kode := LPR-indberetningsniveau; angivelse af specialer for SOR-kode [2] ; SghAfd-mapning := gyldig afsnitskode; ingen afsnitskode gyldig på starttidspunkt for SOR-kode; konsistens i specialeangivelser [2] ; konsistens i mapning: SghAfd-mor mappet [3] ; konsistens i mapningsniveau [4] ; Handling: [1]: Ved oprettelse af mapning til en afdelingskode skal det valideres, at der også er mappet til afdelingskodens hierarkiske mor, dvs. den sygehuskode, der danner de første 4 karakterer i afdelingskoden. De to SghAfd-koder behøves dog ikke nødvendigvis at blive mappet fra samme delgren i SOR-træet. [2]: Der kan angives specialer på alle OE-niveauer i SOR-træet, hvor angivelsen på et højere niveau vil være en aggregering af angivelserne på niveauet umiddelbart under, hvis dette eksisterer. For nærværende er der kun krav om en obligatorisk angivelse af fra 1 til 8 specialer på SOR-koder, der defineres som LPR-indberetningsniveauet. Der skal være overensstemmelse mellem de specialer, der er angivet for en given SOR-kode på indberetningsniveauet og de maksimalt fire specialer, der er angivet for en SghAfd-afsnitskode, som SOR-koden mapper til, dvs. specialerne for afsnitskoden skal være indeholdt i de maksimalt 8 specialer for den mappende SOR-kode. [3]: Ved oprettelse af mapning til en afsnitskode skal det valideres, at der også er mappet til afsnitskodens hierarkiske mor, dvs. den afdelingskode, der danner de første 6 karakterer i afsnitskoden. De to SghAfd-koder behøves dog ikke blive mappet fra samme delgren i SOR-træet. [4]: Test på at der i berørte delgren i SOR-træet er én og kun en SOR-kode, der mapper til hver af de tre SghAfd-niveauer, og at disse kommer i korrekt rækkefølge. Dette valideres nedefra, dvs. at når en SOR-kode mappes til en af- Sundhedsvæsenets Organisationsregister - SOR 16

18 snitskode, så er denne underordnet (ikke nødvendigvis umiddelbart underordnet) en SOR-kode, der mapper til en afdelingskode, der igen er underordnet en SOR-kode, der mapper til en sygehuskode. Bemærk at de 3 koder, fra hver sit lag i SghAfd, der således skal mappes til fra en mapningsrelevant SOR-delgren, ikke behøves at komme fra samme del af SghAfd-træet, dvs. ikke behøves at have samme præfikser. Handling Flyt [1] SOR-kode SORtype SI OE SghAfd mapning sygehuskode Handling: ingen [2] ; ingen Handling: afdelingskode Handling: ADVARSEL: der flyttes SghAfd-mappende SOR-koder; Konsistens i mapningsniveau. afsnitskode Handling: ADVARSEL: der flyttes SghAfd-mappende SOR-koder; Konsistens i mapningsniveau. ingen [3] Handling: Hvis SghAfd-mappende underkoder så ADVARSEL: der flyttes SghAfd-relevante SOR-koder; Konsistens i mapningsniveau. [1]: Dækker rene flytninger af SOR-koder. En flytning af en SOR-kode, der ikke er et blad på SOR-træet, flytter implicit alle underordnede koder med. Hvis nogen af disse har SghAfd-mapninger, flyttes mapningen derfor også med. Dette har ingen konsekvens for SghAfd-træet i sig selv, men kan medføre at sorteringsrækkefølgen i SghAfd-træet set ud fra SOR-træet vil komme i uorden. Ved flytning af sundhedsinstitutioner, som pr. definition vil være en flytning til ny institutionsejer, kan dette trække mapninger til SghAfd-koder med, som den nye institutionsejer ikke har ejerskab til. Om en sådan flytning skal være tilladt, skal afklares senere. [2]: Sundhedsinstitutioner kan kun flyttes til en ny placering som underordnet til en anden institutionsejer. Da alle underordnede koder (i henhold til note 1) implicit flyttes med, er der ingen SghAfd-relevante valideringer. Hvis disse var i orden før flytningen, vil de også være i orden efter. [3]: En flytning af en ikke SghAfd-mappende kode, kan medføre inkonsistens mellem træerne, da eventuelle underordnede SghAfd-mappende koder implicit flyttes til nye placeringer Sundhedsvæsenets Organisationsregister - SOR 17

19 Handling Luk [1] SOR-kode SORtype SI OE SghAfd mapning sygehuskode Handling: Hvis sidste mapning til SghAfd-kode [2] så ADVARSEL [3] : Der eksisterer en gyldig SghAfd-kode, der ikke længere har en mapning; ingen Handling: afdelingskode Handling: Hvis sidste mapning til SghAfd-kode [2] så ADVARSEL [3] : Der eksisterer en gyldig SghAfd-kode, der ikke længere har en mapning; afsnitskode ingen [3] Handling: Hvis sidste mapning til SghAfd-kode [2] så ADVARSEL [3] : Der eksisterer en gyldig SghAfd-kode, der ikke længere har en mapning; Handling: [1]: Det antages, at SOR-valideringen generelt sørger for, at en SOR-kode ikke kan lukkes, hvis den har åbne børn, uanset hvilket niveau den befinder sig på i træet, med mindre de umiddelbare efterkommere tilknyttes en ny mor (dvs. undergår en flytning) i samme transaktion, dvs. i praksis før lukningen. [2]: Dette er den eneste validering, der foretages i forbindelse med lukning af SOR-koder. Det er ikke nødvendigt at validere for konsistens i mapningsniveau, da underordnede SOR-koder til koden, der lukkes, implicit lukkes på samme tid, hvis de ikke er flyttet til ny placering i forvejen. Derfor tager den generelle SOR-validering og validering i forbindelse med flytning af SghAfd-mappende SOR-koder sig af resten. [3]: Den opstillede advarsel er overvejende en hjælp til brugeren. Det vil fortsat være tilladt at have SghAfd-koder, der ikke er mappede, hvis dette ikke bryder med konsistensregler i øvrigt. Sundhedsvæsenets Organisationsregister - SOR 18

20 1.5.3 Opret, flyt og luk SghAfd-mapning Handling Opret [1] mapning SORtype SI OE SghAfd mapning sygehuskode Handling: SghAfd-mapning:= gyldig sygehuskode; sygehuskode gyldig på starttidspunkt for SOR-kode; ingen Handling: afdelingskode Handling: SghAfd-mapning:= gyldig afdelingskode; afdelingskode gyldig på starttidspunkt for SOR-kode; konsistens i mapning: SghAfd-mor mappet [1] ; afsnitskode Handling: SOR-kode:= LPR-indberetningsniveau; angivelse af specialer for SOR-kode [2] ; SghAfd-mapning:= gyldig afsnitskode; ingen afsnitskode gyldig på starttidspunkt for SOR-kode; konsistens i mapning: SghAfd-mor mappet [3] ; konsistens i mapningsniveau [4] ; Handling: [1]: Svarer til at oprette en SghAfd-relevant SOR-kode med tilhørende mapning. Kan medføre de samme inkonsistenser, som ved oprettelse [2]: se under Opret SOR-kode [3]: se under Opret SOR-kode [4]: se under Opret SOR-kode Sundhedsvæsenets Organisationsregister - SOR 19

21 Handling Flyt [1] mapning SORtype SI OE SghAfd mapning sygehuskode Handling: SghAfd-mapning:= gyldig sygehuskode; sygehuskode gyldig på starttidspunkt for SOR-kode; ingen Handling: afdelingskode Handling: SghAfd-mapning:= gyldig afdelingskode; afdelingskode gyldig på starttidspunkt for SOR-kode; konsistens i mapning: SghAfd-mor mappet [1] ; afsnitskode Handling: SghAfd-mapning:= gyldig afsnitskode; afsnitskode gyldig på starttidspunkt for SOR-kode; konsistens i mapning: SghAfd-mor mappet [3] ; ingen Handling: [1]: Svarer til oprettelse af ny SghAfd-mapning ved "overskrivning" af hidtil gældende mapning fra eksisterende SOR-kode. Dette svarer igen til oprettelse af SOR-kode med tilhørende mapning. Det antages generelt, at der ved skift af mapning skiftes til en til en tilsvarende SghAfd-kode, fx fra afdelings- til afdelingskode. [2]: se under Opret SOR-kode [3]: se under Opret SOR-kode Sundhedsvæsenets Organisationsregister - SOR 20

22 Handling Luk [1] mapning SORtype SI OE SghAfd mapning sygehuskode Handling: SghAfd-mapning:= Null; Konsistens i mapningsniveau; Hvis sidste mapning til SghAfd-kode [2] så ADVARSEL [3] : Der eksisterer en gyldig SghAfd-kode, der ikke længere har en mapning; ingen Handling: afdelingskode Handling: SghAfd-mapning:= Null; Konsistens i mapningsniveau; Hvis sidste mapning til SghAfd-kode [2] så ADVARSEL [3] : Der eksisterer en gyldig SghAfd-kode, der ikke længere har en mapning; afsnitskode ingen [3] Handling: SGHAFD-mapning:= Null; Konsistens i mapningsniveau; Hvis sidste mapning til SghAfd-kode [2] så ADVARSEL [3] : Der eksisterer en gyldig SghAfd-kode, der ikke længere har en mapning; Handling: [1]: Adskiller sig på ét væsentligt punkt fra lukning af SOR-kode, idet det netop kun er selve mapningen, der lukkes. Derved lever SOR-kodens og dennes eventuelle underkoder incl. deres mulige SghAfd-mapninger videre, hvorved der kan opstå inkonsistens i mapningen. [2]: se under Luk SOR-kode [3]: se under Luk SOR-kode Sundhedsvæsenets Organisationsregister - SOR 21

23 1.6 SghAfd-udtræk 3 typer af udtræk deltaudtræk o format: Fastbredde SghAfd-totaludtræk pr. dags-dato o format: Fastbredde SOR- SghAfd-udtræk o format: Fastbredde og evt. XML Deltaudtræk Medtager alle SghAfd-opdateringer i et angivet tidsinterval sorteret i korrekt rækkefølge. Ændringerne formateres i det eksisterende standard fastbredde tekstfilformat. Der medtages opdateringer fra og med valgte fra-dato og frem til den valgte til-dato, dvs. indtil kl. 24:00:00 dagen før. Dette medfører, at der udelukkende leveres opdateringer for hele døgn. Ved valg af opdateringeintervallet fra til vil der udtrækkes opdateringer fra kl. 00:00:00 og indtil , dvs kl. 24:00:00. Ved næste udtræk skal der således vælges et interval, der starter med , som vil udtrække data fra kl. 00:00:00, hvorved det sikres, at man ikke modtager dubletter eller værre endnu mister opdateringer. Dette medfører dog også, at man ikke kan udtrække opdateringer for SghAfd-ændringer, man har registreret samme dag, selvom man vælger dags dato som til-dato. Med SOR kan den samme SghAfd-kode undergå flere ændringer (incl. lukninger) på samme dag. Disse ændringer vil ikke med dagens SghAfd-oplysninger kunne sorteres i korrekt rækkefølge, da der i datasættet kun indgår ændringsdato og ikke ændringstidspunkt. Derfor vil deltaudtrækkene være oplistet i den rækkefølge, de skal opdateres i de lokale systemer. Det er altså væsentligt, at deltaudtræk ikke omsorteres i forbindelse med indlæsningen, da man således kan ende op med det forkerte slutresultat for en given SghAfd-kode Udtræk af SghAfd-total Medtager alle koder, de er gyldige eller har været gyldige på et tidspunkt. Må kun medtage den sidste kode af hvert ID3-sæt Udtræk af SghAfd-koder mappet fra SOR Medtager alle SghAfd-koder, der aktuelt er mappet fra SOR-træet, uanset om SghAfd-koderne er gyldige eller ej (der er endnu ingen validering på, om åbne SOR-koder mapper til lukkede SghAfd-koder) 1.7 Placering af SghAfd-udtræk SghAfd-total og SghAfd-deltaudtræk placeres på et FTP-site som der kan linkes til på Hver nat efter midnat lægges et total-udtræk med alle SghAfd-koder frem til dagen før kl. 24:00:00. Filen navngives SghAfd_total.txt og overskrives ved opdatering. De centrale registre vil blive opdateret dagligt på grundlag af totalen. Sundhedsvæsenets Organisationsregister - SOR 22

24 En gang om ugen lægges en samlet deltafil med både sgh- og afd-koder på FTPsitet. Disse navngives SghAfd_opdat_YYYY-UU (fx SghAfd-opdat_ for opdateringer i uge 15, der lægges ud i starten af uge 16). Dette medfører, at systemer, der opdateres på grundlag af delta-udtrækkene, vil have et efterslæb på op til en uge. Indtil et nyt format (XML) for delta-udtræk er på plads, vil EDIFACTopdateringerne blive udsendt på grundlag af disse ugentlige opdateringer 1.8 Brugergrænseflader I supplerende bilag er beskrevet et oplæg til brugergrænseflader, hvor SghAfd redigeres separat. Dette skal således kun ses som et oplæg til de brugerfunktionaliteter, der skal bibringe de relevante SghAfd-oplysninger, og må derfor ikke opfattes som det endelige design af grænsefladerne. Sundhedsvæsenets Organisationsregister - SOR 23