Page History
| Navitabs | ||||
|---|---|---|---|---|
|
...
Dette dokument beskriver arkitekturen for Behandlignsrelationsservicen (BRS).
Der beskrives
- Moduler i BRS
- Services og jobs, der rummes af BRS
- NSP miljøer, hvorpå i BRS modulerne er installeret
- Dataflow
- Datamodul, herunder databaser og tabelstruktur.
...
Behandlingsrelationsservicen (BRS) udstillet på NSP er en service til kontrol af behandlingsrelationer. BRS tilbyder at løfte opgaven med at klassificere behandlingsrelationer imellem sundhedsfaglige personer og patienter, således at nationale serviceudbydere i sundhedsvæsenet lettere kan overholde lovkrav til kontrol af sundhedsfaglige personers adkomst til data og funktionalitet.
Da der ikke findes et decideret "behandlingsrelationsregister", er det nødvendigt at udlede viden om faktiske behandlingsrelationer ved opslag i nationale registre over handlinger, registreringer og relationer indenfor sundhedsvæsenet. Endvidere er der ofte en tidsmæssig forsinkelse i opsamling af de nødvendige informationer, og det er derfor nødvendigt at give adgang til funktionalitet og data på basis af ukomplette informationer, og efterfølgende foretage en opfølgende kontrol af den faktiske relation på et senere tidspunkt.
Opslag og opfølgninger varetages af BRS.
Hvis en serviceudbyder giver adgang til en bruger under forudsætning af at brugerens adkomst senere kan bekræftes, men det ikke sker, udsteder BRS en alarm, som serviceudbyderen kan agere på (en manuel opfølgning).
Systemet er opdelt i to dele "frontend" og "backend".
...
Frontend'en indeholder behandlingsrelationsservicen og notifikationsservicen, som er de webservices, der kaldes udefra, fra eksempelvis FMK. Herudover afvikles et job som løbende replikerer behandlingsrelationer, der er sat til opfølgning, til backend'en.
Frontend'en er installeret i dNSP-miljøerne (decentral National Service Platform), samt til i cNSP-miljøet (central National Service Platform).
...
Backend'en indeholder en webservice, som modtager de data, der replikeres fra frontend'en. Herudover afvikles der et batchjob, der foretager løbende opfølgning på, om der er opnået evidens for de behandlingsrelationer, der er sat til opfølgning, og opretter alarm-notifikationer i de tilfælde, hvor evidens ikke blev opnået indenfor tidsfristen. Endelig afvikles et andet bachjob, der løbende sletter gamle notifikationer.
Backend'en er installeret i NSP's Backoffice-miljø (tidligere benævnt DoDi).
I Backoffice opsamles data fra følgende kilderegistre:
- Landspatientregistret (LPR)
- Sygesikringsregistret (SSR)
- Henvisningshotellet (Refhost)
- Sikrede (AssignedDoctor)
Data indsættes i de samme MySQL databaser, som BRS anvender, men det foretages i praksis af separate stamdata-importere.
Disse data, samt de notifikationer, der er oprettet af opføgningsjobbet, replikeres løbende til NSP-miljøerne, så data er tilgængelige for frontend'en. Denne replikering foretages i praksis som MySQL-databasereplikering.
...
På NSP-miljøerne udstilles følgende webservices:
Behandlingsrelationservice (BRS):
Servicen modtager en forespørgsel på en behandler (identificeret som person+sted), samt en patient (identificeret ved CPR), og skal afgøre hvilke kategorier af relationer der er mellem behandleren og patienten.
Der angives ligeledes et succeskriterie i form af et sæt af kategorier, der antages at være acceptable behandlingsrelationer. Skulle der ikke være en acceptabel behandlingsrelation, kan det afføde en opfølgning. For at understøtte dette, kan kalderen angive et sæt af kategorier der skal afføde en opfølgning. Dette kan også være sat til alle relationer.
Notifikationsservice:
Servicen vil returnere alle notifikationer, som er adresseret til kalderen. Notifikationer er fortløbende nummererede, og kalderen kan angive et offset, der sikrer at kun de nyeste notifikationer returneres. Servicen sletter alarmer efter et centralt konfigurerbart tidsinterval. Hvis man ikke angiver offset kan man risikere at modtage de samme alarmer flere gange.
De ovennævnte services udstilles via Den Gode Webservice (DGWS 1.0.1), og kan kun kaldes af systemer der bruger et System-IDKort udstedt til forhåndsgodkendte CVR numre. IDKort skal være udstedt af SOSI-STS.
...
Backoffice indeholder to batchjobs der begge afvikles periodisk. Schedule for jobs kan konfigureres vha. en cron expression.
Relationsopfølgning:
De gemte opfølgninger kontrolleres op imod valideringsbiblioteket for at undersøge om der er opstået relationer der giver anledning til at slette en opfølgning. Hvis en opfølgning ikke har opnået den krævede relationskategori inden dens udløb oprettes en alarm i notifikationsdatabasen via GOS.
Oprydning:
Alarm-notifikationer replikeres til frontend i NSP-miljøerne, hvor de kan hentes med notifikationsservicen. Dette sletter dog ikke notifikationerne, så for at undgå at der blot bliver flere og flere, er der på et oprydningsjob, som løbende sletter notifikationer, som er blevet tilpas gamle.
Sletningen replikeres, så data også slettes fra de øvrige miljøer.
...
Valideringsbiblioteker har adgang til data fra en række databaser, deriblandt landspatientregisteret og sygesikringsregisteret, for at kunne udlede om en behandlingsrelation er til stede. Valideringsbiblioteket tilgås af behandlingsrelationservicen i dNSP/cNSP-miljøerne samt relationsopfølgningsjobbet i Backoffice miljøet.
Valideringsbiblioteket er implementeret som en fælles kodebase, der deles af front- og backend modulerne.
...
Der er to typer databaser i datamodellen:
- En opfølgningsdatabase
- En database med registre og notifikationer
Tabellerne på de to typer databaser er beskrevet i det følgende.
...
Opfølgningstabellen indeholder behandlingsrelationer, som er modtaget af behandlingsrelationsservicen, og som er sat til opfølgning, idet der ikke umiddelbart kunne opnås tilstrækkelig evidens for relationen i forhold til evidenskilderne.
Tabellen udgør en form for kø. Replikeringsjobbet læser fra denne og sender data til backend'en, hvorefter data slettes fra tabellen.
Navn | Type | Beskrivelse |
Pk | bigint, auto_increment | Primær nøgle |
queryableCvr | char(8) | CVR-nummer |
externalReferenceId | varchar(50) | Id i kaldende system |
Uid | varchar(36) | Unik nøgle i systemet |
docorOrganisation | varchar(7) | Ydernummer for organisation |
hospitalOrganisation | varchar(7) | SKS kode for sygehus/afdeling |
ean | varchar(20) | EAN nummer for organisation |
patientCpr | char(10) | Patientens CPR-nummer |
healthProfessionalCpr | char(10) | Behandlers CPR-nummer |
relationLookupStart | datetime | Starttidspunkt for relation til patient |
relationLookupEnd | datetime | Sluttidspunkt for relation til patient |
timeLimit | datetime | Tidsfrist for opnåelse af relation inden alarm genereres |
acceptableRelations | varchar(20) | Acceptable evidensniveauer, kommasepareret |
followupRelations | varchar(20) | Evidensniveauer, der giver anledning til opfølgning |
authorisationIdentifier | varchar(20) | Autorisations-id |
serviceProviderName | varchar(50) | Navn på kaldende system |
serviceProviderVersion | varchar(20) | Version på kaldende version |
serviceProviderVendor | varchar(50) | Leverandør for kaldende version |
created | datetime | Tidspunkt for oprettelse af record |
errorCount | int | Antal gange record er forsøgt replikeret til backend |
nextSync | datetime | Tidspunkt for næste forsøg på replikering |
...
Opfølgningstabellen indeholder behandlingsrelationer, som er sat til opfølgning, og er blevet overført til backend'en. Data ligger i denne tabel så længe der ikke er opnået evidens for relationen, og tidsfristen ikke er overskredet.
Navn | Type | Beskrivelse |
serialNumber | bigint, auto_increment | Primær nøgle |
nextCheck | datetime | Tidspunkt for næste opfølgning |
queryableCvr | char(8) | CVR-nummer |
externalReferenceId | varchar(50) | Id i kaldende system |
uid | varchar(36) | Unik nøgle i systemet |
docorOrganisation | varchar(7) | Ydernummer for organisation |
hospitalOrganisation | varchar(7) | SKS kode for sygehus/afdeling |
ean | varchar(20) | EAN nummer for organisation |
patientCpr | char(10) | Patientens CPR-nummer |
healthProfessionalCpr | char(10) | Behandlers CPR-nummer |
relationLookupStart | datetime | Starttidspunkt for relation til patient |
relationLookupEnd | datetime | Sluttidspunkt for relation til patient |
timeLimit | datetime | Tidsfrist for opnåelse af relation inden alarm genereres |
acceptableRelations | varchar(20) | Acceptable evidensniveauer, kommasepareret |
followupRelations | varchar(20) | Evidensniveauer, der giver anledning til opfølgning |
authorisationIdentifier | varchar(20) | Autorisations-id |
serviceProviderName | varchar(50) | Navn på kaldende system |
serviceProviderVersion | varchar(20) | Version på kaldende version |
serviceProviderVendor | varchar(50) | Leverandør for kaldende version |
created | datetime | Tidspunkt for oprettelse af record |
...
Navn
...
Type
...
Beskrivelse
...
pk
...
bigint, auto_increment
...
Primære nøgle
...
patientCpr
...
varchar(80)
...
SHA-1 hash
...
admittedStart
...
datetime
...
admittedEnd
...
datetime
...
lprReference
...
varchar(40)
...
Fra inputdata – audit
...
relationType
...
varchar(40)
...
Se kommentarer
...
organisationIdentifier
...
varchar(7)
...
ydernummer eller SKS-kode
...
| Table of Contents |
|---|
Formål
Dette dokument beskriver installation og konfiguration af Behandlingsrelations-servicen (BRS).
Servicen omfatter to komponenter:
- brs-frontend til installation i NSP-miljøer (de decentrale dNSP miljøer og det centrale cNSP miljø). Denne indeholder webservices til opslag af evidens for behandlingsrelationer og hent af alarm-notifikationer.
- brs-backend til installation i det centrale Backoffice miljø. Denne service indeholder batchjobs til løbende opfølgning på evidens for behandlingsrelationer og generering af alarm-notifikationer.
I denne vejledning beskrives krav til operativsystem og serversoftware, samt installation og konfiguration af de ovennævnte komponenter.
Krav til miljø
Krav til applikationsservere
Komponenterne er udviklet og testet i Docker ved anvendelse af et base-image for NSP platformen.
Komponenternes konfiguration er således tilpasset deployering på WildFly 8.2 applikationsservere med OpenJDK 8.
Krav til operativsystem
Der stilles ingen krav til operativsystemet udover, at det skal være Linux, og docker skal være installeret.
Krav til database
Komponenten er testet mod MariaDB version 10.1.
Krav til hardware
Der er nogle minimumskrav for at kunne afvikle komponenten fornuftigt til testformål. Dog skal man forvente at bruge high-end hardware (både cpu, ram, netkort & diske) for at kunne opfylde svartidskravene på NSP platformen.
Minimumskravene, for fornuftig performance på et test-setup, er
- Intel Core 2 eller lignende CPU
- 2 GB ram
- Nødvendig harddisk plads for at kunne håndtere alle registre (10+ GB)
Oprettelse af databaser og tabeller
Herunder beskrives opsætningen af databaserne, samt oprettelsen af tabellerne. Alle filer der refereres til kommer fra et SVN checkout. Den seneste version samt tidligere releases kan findes på https://svn.nspop.dk/src/components/brs
Tilgang til Stamdataudstillet database
Behandlingsrelationsservicen benytter data fra Stamdatamodulet. Servicen benytter tabellen ”AssignedDoctori”. Databasen fra Stamdata indeholdende pågældende tabel skal derfor være til rådighed for både frontend-modulet i NSP-miljøerne og backend-modulet i Backoffice-miljøet.
Oprettelse af database og tabeller i Backoffice-miljøet
Databasen ”register_notifications” oprettes.
Følgende sql scripts skal køres på ”register_notifications” databasen (i nævnte rækkefølge):
- Behandlingsrelation/common/src/main/resources/sql/create-register_notifications-tables.sql
- Behandlingsrelation/common/src/main/resources/sql/mysql-register_notifications-alter-tables.sql
- Behandlingsrelation/common/src/main/resources/sql/create-whitelist_config-table.sql
Databasen ”followup” oprettes.
Følgende sql scripts skal køres på ”followup” databasen (i nævnte rækkefølge):
- compose/database/brs/database/04-create-treatmentrelationfollowup-tables.sql
- compose/database/brs/database/05-mysql-treatmentrelationfollowup-alter-tables.sql
NB: followup-databasen kan slettes, når migrering til Kafka er gennemført (se driftsvejledning for detaljer om migrering).
Oprettelse af database og tabeller i dNSP/cNSP-miljøer
Databasen ”register_notifications” oprettes som en replikeret kopi af samme database i Backoffice miljøet.
Databasen ”followup” installeres.
Følgende sql scripts skal køres på ”followup” databasen (i nævnte rækkefølge):
- compose/database/brs/database/06-create-followup-tables.sql
- compose/database/brs/database/07-mysql-followup-alter-tables.sql
NB: followup-databasen kan slettes, når migrering til Kafka er gennemført (se driftsvejledning for detaljer om migrering).
Deployment
Denne sektion beskriver hvordan komponenten deployes.
Jenkins
BRS bygges med NSP's Jenkins server via følgende jobs:
- BRS_build - Bygger koden (sker automatisk ved commits)
- BRS_push_snapshot - Pusher det nyeste snapshot image til NSP Docker Registry
NSP er selv ansvarlige for at pushe release versioner af BRS til NSP Docker Registry gennem Jenkins.
Docker
BRS består af to docker images som pushes til NSP Docker Registry under navnene:
- registry.nspop.dk/components/brs/brs-frontend:snapshot
- registry.nspop.dk/components/brs/brs-backend:snapshot
Docker-compose
BRS leveres samtidig som et sæt af Docker Compose filer i folderen https://svn.nspop.dk/src/components/brs/trunk/compose.
Compose folderen indeholder 5 underfoldere:
| configuration | Her ligger alle de konfigurationsfiler som det forventes af driften tilretter til det anvendte miljø. |
| database | Her ville alle de databasefiler som det forventes at driften lægger på en NSP database ligge, hvis der var nogen |
| development | Her ligger en Docker Compose fil til brug for udvikling. Se Guide til Udviklere. |
| test | Her ligger en Docker Compose fil der kan starte BRS i en standalone test konfiguration. |
| release | Her ligger den Docker Compose fil som det forventes driften anvender på både test og produktionsmiljøerne. |
Konfiguration af properties
I folderen https://svn.nspop.dk/src/components/brs/trunk/compose/configuration findes følgende konfigurationsfiler:
| backend/brs-backend.dev.properties | Konfiguration af brs-backend til udviklingsbrug. |
| backend/brs-backend-log4j.xml | Logopsætning af brs-backend. |
| backend/brs-backend.properties | Konfiguration af brs-backend. |
| backend/crl.skip | Skipliste til certificate revocation tjek. |
| backend/properties/Capgemini_Sogeti_Danmark_AS_SOR_FOCES.jks | Keystore til SOR kald. |
| backend/properties/module.xml | Module-fil. |
| frontend/brs-frontend.dev.properties | Konfiguration af brs-frontend til udviklingsbrug. |
| frontend/brs-frontend-log4j.xml | Logopsætning af brs-frontend. |
| frontend/brs-frontend.properties | Konfiguration af brs-frontend. |
| frontend/crl.skip | Skipliste til certificate revocation tjek. |
| frontend/properties/Capgemini_Sogeti_Danmark_AS_SOR_FOCES.jks | Keystore til SOR kald. |
| frontend/properties/module.xml | Module-fil. |
| sores/* | Konfiguration til brug i udviklersetup. |
Filerne brs-backend.properties og brs-frontend.properties skal tilrettes til de forskellige miljøer hvorpå de installeres. Filerne indeholder en konfiguration der passer i en standalone test konfiguration. Se driftsvejledningen for en beskrivelse af indholdet af filerne.
Konfiguration af logning
Logning konfigureres i log4j-filerne nævnt ovenfor. Se driftsvejledningen for en mere detaljeret beskrivelse af hvad der logges.
Der benyttes en rolling file appender, hvor størrelsen af log filerne og antallet af gemte log filer konfigureres med de to environment variable: LOG_MAX_FILE_SIZE og LOG_MAX_BACKUP_INDEX.
Deployment af komponenter
Herunder følger en tabel over komponenter, samt en kort beskrivelse af deres formål.
| Komponent | Komponent(er) | Beskrivelse |
|---|---|---|
| brs-backend | followupservlet | Kontrol af opfølgninger til sletning eller oprettelse af alarm-notifikationer. |
| Cleanupjob | Sletning af gamle notifikationer. | |
| brs-frontend | behandlingsrelationsservice | Service til forespørgsel på behandlingsrelationer. |
| notifikationsservice | Service til hent af notifikationer. |
Der henvises til driftsvejledningen for yderligere information
Opgradering af komponenter
Når der kommer opgraderinger til en komponent, vil der medfølge releasenotes, der beskriver opgradering, fallback, osv. for den enkelte komponent.
Whitelisting af services
Adgang til BRS services styres på CVR niveau. Adgang til services kan styres enten via property filen, eller via en lignende konfiguration i whitelist_config tabellen.
Vælges DATABASE som styringsmodel for whitelisting i propertyen "dk.nsi.auth.whitelistservice.type” anvendes de komma-separerede lister i propertyfilen ikke. I stedet indsættes en record i tabellen for hver adgang der skal gives. Nedenstående eksempler angiver formatet.
Eksempler på at oprette adgang til BRS
INSERT INTO whitelist_config (service_key, service_type, cvr) VALUES ('dk.nsi.auth.brs.cvr.list', 'NO_TYPE', '55832218');
Eksempler på at oprette query-adgang til notifications-servicen
INSERT INTO whitelist_config (service_key, service_type, cvr) VALUES ('dk.nsi.auth.query.type.cvr.list', 'BRS', '55832218');
Start/genstart af komponenterne
BRS backend og frontend startes og stoppes med Docker Compose kommandoer.
Standalone test
For en standalone test af BivWSP hentes "compose" folderen for den ønskede version med Subversion og kommandoen "docker-compose up" køres i folderen "test".
NSP Miljø
På et NSP miljø hentes "compose" folderen for den ønskede version med Subversion og kommandoen "docker-compose up" køres i folderen "release".
Ændringslog
...
Følgende tabel benyttes til mapning fra input SKS-koder til SOR-koder:
...
Navn
...
Type
...
Beskrivelse
...
Data fra LPR3 findes i en tabel med dette skema:
...
Navn
...
Type
...
Beskrivelse
...
pk
...
bigint, auto_increment
...
Primære nøgle
...
patientCpr
...
varchar(80)
...
SHA-1 hash
...
admittedStart
...
datetime
...
admittedEnd
...
datetime
...
lprReference
...
char(60)
...
Fra inputdata – audit
...
relationType
...
varchar(40)
...
Se kommentarer
...
sorKode
...
bigint(20)
...
SOR-kode
Relationstypen kan antage følgende værdier:
- FORLOEBSELEMENT
- KONTAKT
- PROCEDURE
- INITIEL_HENVISNING
- HENVISNING
- RESULTATINDBERETNING
- OPHOLDSADRESSE
...
Navn
...
Type
...
Beskrivelse
...
pk
...
bigint, auto_increment
...
Primære nøgle
...
patientCpr
...
varchar(80)
...
SHA-1 hash
...
doctorOrganisationIdentifier
...
varchar(6)
...
ydernummer
...
admittedStart
...
datetime
...
admittedEnd
...
datetime
...
externalReference
...
varchar(40)
...
Fra inputdata - audit
...
Navn
...
Type
...
Beskrivelse
...
pk
...
bigint, auto_increment
...
Primære nøgle
...
healthProfessionCpr
...
varchar(80)
...
SHA-1 hash
...
doctorOrganisationIdentifier
...
varchar(6)
...
ydernummer
...
hospitalOrganisationIdentifier
...
varchar(7)
...
SKS-kode
...
EAN
...
char(13)
...
EAN-nummer
...
patientCpr
...
varchar(80)
...
SHA-1 hash
...
referralStart
...
datetime
...
Henvisningens start
...
referralEnd
...
datetime
...
refhostReference
...
varchar
...
Fra inputdata – audit
...
Notifikationstabellen i Backoffice-miljøet indeholder alarm-notifikationer for behandlingsrelationer, som der ikke kunne findes evidens for indenfor tidsfristen.
Navn | Type | Beskrivelse |
serialNumber | bigint, auto_increment | Primær nøgle |
externalReferenceId | varchar(50) | Id i kaldende system |
queryableCvr | char(8) | CVR-nummer |
creationTimestamp | datetime | Tidspunkt for oprettelse af record |
docorOrganisation | varchar(7) | Ydernummer for organisation |
hospitalOrganisation | varchar(7) | SKS kode for sygehus/afdeling |
ean | varchar(20) | EAN nummer for organisation |
patientCpr | char(10) | Patientens CPR-nummer |
healthProfessionalCpr | char(10) | Behandlers CPR-nummer |
relationLookupStart | datetime | Starttidspunkt for relation til patient |
relationLookupEnd | datetime | Sluttidspunkt for relation til patient |
timeLimit | datetime | Tidsfrist for opnåelse af relation inden alarm genereres |
acceptableRelations | varchar(20) | Acceptable evidensniveauer, kommasepareret |
actualRelations | varchar(20) | Bedste relation opnået under opfølgning |
followupRelations | varchar(20) | Evidensniveauer, der giver anledning til opfølgning |
authorisationIdentifier | varchar(20) | Autorisations-id |
serviceProviderName | varchar(50) | Navn på kaldende system |
serviceProviderVersion | varchar(20) | Version på kaldende version |
serviceProviderVendor | varchar(50) | Leverandør for kaldende version |
uid | varchar(36) | Unik nøgle i systemet |
...
Behandlingsrelationsservicen benytter data udstillet af Stamdatamodulet. Det drejer sig om tabellen AssignedDoctor der dækker registret "Sikrede". Dokumentationen af denne tabel forefindes i dokumentationen for Stamdata.
...
Der henvises til NSP-dokumentationen for information vedrørende den overordnede arkitektur og omkringliggende komponenter.
Komponenter og services beskrevet her følger de overordnede retningslinier og krav udstukket af NSP-operatøren, herunder:
- Alle services skal bruge MySQL databaser til persistering af data.
- Alle services skal kunne eksekveres på JBoss. Aktuelt anvendes Wildfly 8.2.
- Al tilgang til services udefra skal foregå ved brug af den gode webservice (DGWS) (STS-signerede IDkort, niveau 3).
- Internt anvendes usignerede DGWS niveau 1 ID-kort til kommunikation mellem frontend og backend.
...
Version | Dato | Ændring | Ansvarlig | ||
|---|---|---|---|---|---|
0.1 | 2011-06-15 | Initielt dokument | Trifork | ||
0.2 | 2011-06-21 | Opdatering af databaseoprettelser på NSP og DoDis opfølgningstabeller | Trifork | ||
0.3 | 2011-07-27 | Ændringer Opdateret jf. databaseskema indeholdende generelle notifikationerny struktur med generel notificationsservice. | Trifork | ||
0.34 | 2011-08-10 | Opsplitning af dokumentation jf. BRS og GOS opsplitningOpdateret dokumentation med GOS services | Trifork | ||
0.45 | 2011-10-05Tilføjelse af information om eksternt "Sikrede" register fra Stamdata | Opdateres dokumentation med CPRABBS service | Trifork | ||
0.6 | 2011-11-28 | Dokumentation opdateret med whitelist_config tabeloprettelse | Trifork | ||
0.57 | 2013-10-21 | Opdateret SVN linkkilde | Trifork | ||
| 0. | 68 | 20172014-03-12 | Opdateret med beskrivelse af propertyfil, og detaljer for hver property | Trifork | |
| 0.9 | 2016-09-01 | Opdateret til Wildfly 8 | Trifork | ||
| 0.10 | 2016-11-11 | Opdateret logning til profiler | Trifork | ||
| 0.11 | 2017-03-09 | Tilrettet | Tilpasset tilBRS2 | Trifork | |
| 0. | 712 | 2017-03-14 | Rettet | betegnelserbetegnelse på NSP-miljøer | Trifork |
...
| 0.13 | 2019-07-12 | Dokument fra repository lagt i confluence. Tidligere dokuments indhold var - forkert - arkitektur dokumentet | KvalitetsIT |
| 0.14 | 2020-07-23 | Opdateret med beskrivelse af docker-setup. | KvalitetsIT |
| 0.15 | 2020-11-23 | Gennemlæst og foretaget smårettelser (i krav til applikationsserver og operativsystem, hvor Docker er sat som krav) | KvalitetsIT |
...