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 Register) 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 ved hjælp af  applikationen ”SOR GUI” som læste og ændrede direkte i SORs interne database. 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 via NSP (den Nationale Serviceplatform). 

SOR blev oprindeligt implementeret i 2009 for at erstatte den eksisterende SHAK-klassifikation (SygeHusAfdelingsKode-klassifikation) og for dermed at imødekomme formatmæssige begrænsninger. 

Funktionalitet og målgruppe 

.

SOR Opdateringsservice (SORUS) 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 use case er beskrevet detaljeret med information om testcasens forløb, pre- og postconditions, fejlscenarier og begreber og definitioner.

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

SOR's Opbygning

SOR's opbygning består af hele det danske sundhedsvæsens enheder – dvs. alt fra Rigshospitalet, til fodterapeuter og mindre private lægepraksis. Alle 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):

...

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 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:

Begreber og definitioner

Guide til anvendere; Information om operationer og input.

...