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

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

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