Version 1.0 september 2019

Indledning

SOR (Sundhedsvæsenets OrganisationsRegister) indeholder alle organisationsenheder inden for det danske sundhedsvæsen – regionale sygehuse, såvel som private lægepraksis, apoteksfilialer, osv.

Disse er bygget op i hierarkier af SOR-enheder (SOR entities) og blev oprindeligt vedligeholdt vba. den såkaldte ”SOR GUI” som læste og ændrede direkte i SORs interne database, men med implementeringen af SOR-services, mere specifikt i dette tilfælde: ”SOR Opdateringsservice” (SORUS), er det nu muligt at lave ”System-til-System”-opdateringer af SOR, fra NSP (den Nationale ServicePlatform). Dette simplificerer muligheden for ekstern brug af SOR.

Kort beskrivelse af baggrunden for SORUS

SOR blev oprindeligt implementeret i 2009 for at erstatte den eksisterende SHAK-klassifikation (SygeHusAfdelingsKode-klassifikation), for at imødekomme formatmæssige begrænsninger. Disse begrænsninger var dog imidlertid ikke så kritiske som forventet og derfor blev SOR introduceret, men kun brugt i begrænset omfang. Dette var realiteten indtil for nyligt, hvor man vedtog lovkrav om rapportering af budget og lign. på et finere granuleret niveau, og i denne sammenhæng har man nu brug for den detaljegrad som er tilladt i SOR, til forskel for SHAK.

For at hjælpe med til en bredere accept af SOR, implementerer man ”SOR Services”.

Diagram over løsning

Funktioner og Testcases

SORs Opbygning

SORs opbygning består af hele det danske sundhedsvæsens enheder – dvs. alt fra Rigshospitalet, til fodterapeuter og mindre private lægepraksis. Alle disse enheder er bygget op i ”træstrukturer” – heri kaldet ”hierarkier”. I disse hierarkier eksisterer relationsmæssige regler, ud fra SOR-typerne: (dansk / engelsk – begge notationer bruges aktivt)

Ud over regler for hvorledes et hierarki er bygget er der også krav til at det skal bestå af minimum tre niveauer, for at være validt og blive trukket ud af SOR, i forbindelse med udtræk.

I forbindelse med denne tilslutningstest vil det kun være Organisatoriske Enheder der er af relevans. 

SOR-typer og data

Alle enheder i SOR indeholder masser af information, hvilket til tider kan være svært at gennemskue. For at gøre datamodellen mere transparent, forsøges her at give en kort gennemgang af al obligatorisk information på tværs af typer:

• SOR-type: IO, HI eller OU.
• Adresser: Afhængig af SOR-typen har en enhed 2-4 forskellige adressetyper: ”Postadresse”, ”Besøgsadresse”, ”Aktivitetsadresse” og "Virtuel adresse"; disse kan arves fra en enheds hierarkiske mor.
• Enhedsnavn: Navn på den pågældende enhed.
• Enhedstype: Teknisk nøgle for EntityType (SNOMED Concept Id); information om en given enheds faktiske funktion: eks. ”Fodterapeut” eller ”Hospital”.
• EAN LokationskodeStatus: Kan være ”Own”, ”None” eller ”Inherited”; afhængig af status vil enheden have egen unik ”EAN lokationskode”, arve fra hierarkisk mor eller ikke have nogen lokationskode.

Mere information om dette data kan ses i delafsnittende nedenfor.

SOR-typer:

IO – Institution Owner

Øverste instans, niveau 1, i enhedshierarkier. Disse kommer i fire enhedstyper: Privat, Regional, Kommune og Stat. Der eksisterer nogle begrænsninger på indhold i underliggende enheder, afhængig af IO’ens enhedstype.

Yderligere detaljer:

HI – Health Institution

Niveau 2, i alle hierarkier. Disse kommer i 53 forskellige enhedstyper, bl.a. ”Apoteker”, ”Fodterapeuter”, ”Administrative enheder”, m.fl. Af særheder tilknyttet HI-typen kan nævnes at HI’er af typen ”Apotek” er den eneste form for enhed der kan indeholde parameteren: ”Pharmacy Identifier”. Derudover er det kun HI’er af typen ”Hospital”, under en IO af typen ”Regional”, der kan have en såkaldt ”Geografisk Lokalitet”. Rent funktionelt betyder det at de er tilknyttet en adresse, som indgår i ”Geographical Localization”-tabellen, i databasen.

Yderligere detaljer:

OU – Organizational Unit

Niveau 3 og under. Disse kommer i 48 forskellige enhedstype, og er den SOR-type der indeholder flest ”implicitte” begrænsninger (se tabel nedenfor). Et eksempel er at OU-enheder af enhedstypen: ”-hospital” (se SOR-lookupdata -> enhedstyper -> OEh), kun kan placeres under en HI-enhed af enhedstypen: ”Hospital”. 

I praksis vil langt de fleste OE’er, som ikke er tilknyttet hospitaler eller andre større instanser, være af typen: ”Supplerende Oplysninger”, for at indholde information om specialer, for sin tilknyttede IO og HI.

Yderligere detaljer:

Adressetyper

Alle enheder i SOR har såvel fysiske, som virtuelle adresser. Der eksisterer fire forskellige adressetyper:

• Postadresse
• Besøgsadresse
• Aktivitetsadresse
• Virtuel adresse

Som det kan læses i afsnittet ovenfor, ”SOR-typer”, er det ikke alle adressetyper der er relevante for alle enheder.

• IO-enheder har postadresse og virtuel adresse
• HI-enheder har postadresse, besøgsadresse og virtuel adresse
• OU-enheder har postadresse, besøgsadresse, aktivitetsadresse og virtuel adresse

På IO enheder er adresser obligatoriske, men på underliggende enheder vil en adresse-type som ikke er udfyldt, resultere i ”arv” – dvs. at adresseoplysninger vil blive hentet, enten fra en af enhedens egne adresse-typer eller fra en hierarkisk mor. 

Reglerne for arv af adresseoplysninger er som følger: 

1. Hvis Aktivitetsadresse er tom hentes Besøgsadresse
2. Hvis Besøgsadresse er tom, hentes Postadresse
3. Hvis Postadresse er tom, hentes Postadresse fra hierarkisk mor og så fremdeles; postadresse er obligatorisk på IO-niveau.

Virtuel adresse kan enten udfyldes eller efterlades tom. En tom virtuel adresse vil resultere i arv; virtuel adresse er obligatorisk på IO-niveau.

I forbindelse med oprettelse eller opdatering af en enhed vha. SORUS, vil en udfyldt adressetype resultere i en ”udfyldt” adresse, dvs. ingen arv, men hvis en adressetype efterlades tom, vil denne blive arvet fra parent.

Enhedsnavn (EntityName)

Enhedens navn – eks. ”Lægeklinik Vestergade”, ”Rigshospitalet”, osv.

Enhedstyper (EntityTypeIdentifier)

Teknisk nøgle for EntityType (SNOMED Concept Id); Enhedstyper (EntityTypeIdentifier) i SOR er et obligatorisk felt på alle enheder og indeholder yderligere information om hvad en SOR-enheds faktiske funktion er; et tænkt hierarki kan se ud som følger:

IO: EntityTypeID = 550891000005100, som er koden for ”Privat”

HI: EntityTypeID = 554061000005105, som er koden for ”Fodterapeut”

OU: EntityTypeID = 255203001, som er koden for ”Suplerende oplysninger”

Altså har vi med en privat fodterapeut at gøre, og OU’en indeholder nogle af de OU-specifikke informationer om enheden; eks. specialer. (se ovenfor)

Som nævnt i afsnittet ovenfor, eksisterer der til tider forskellige begrænsninger i datamodellen, på baggrund af disse enhedstyper. Eksempelvis kan kun apoteker indeholde ”Apoteks ID”, hospitalsenheder kan have information om ”Indlagte Patienter” osv.

EAN LokationskodeStatus (EanLocationCodeState)

Denne oplysning fortæller om hvorvidt en given enhed har et EAN Lokationsnummer, eller ej. Til forskel fra adressenedarvning – som enten kan være finde sted eller ej – kommer LokationsnummerStatus i tre varianter:

Begreber og definitioner

Guide til anvendere; Information om operationer og input.