Version 1.0 september 2019

Indledning

...

Certificering til anvendelse af SORUS i produktion, opnås ved at dokumentere at basale use cases i SORUS Testprotokol kan gennemføres uden fejl ved test afviklet på NSP testmiljø.

Funktionalitet og målgruppe 

SOR (Sundhedsvæsenets Organisations RegisterSOR (Sundhedsvæsenets OrganisationsRegister) indeholder alle organisationsenheder inden for det danske sundhedsvæsen – regionale sygehuse, kommunale sundhedsinstitutioner, 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

SORs Opbygning

.

SOR Opdateringsservice (SORUS) anvendes til administration af regioners SOR data.

Servicen indeholder funktionalitet til at oprette, opdatere, flytte, erstatte og nedlægge enheder i SOR. Endvidere er det muligt at opdatere EDI oplysninger på en enhed.

Servicens brugere er regionernes SOR ansvarlige.

Diagram over forretningsprocesser i løsningen

Testprotokolens testcases  

Nedenstående 6 test cases indeholder de basale funktioner, der understøttes i SORUS.

De er beskrevet detaljeret med information om testcasens forløb, pre- og postconditions, fejlscenarier og begreber og definitioner.

Klik på linket for at gå til den enkelte testcase. 

SOR's Opbygning

SOR's 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 gives en kort gennemgang af al obligatorisk information på tværs af typer:

...

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.

...

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.

...

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

...

...

Adressetyper

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

...

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:

...

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:

Testcases

Begreber og definitioner

Guide til anvendere; Information om operationer og input.

...