...

Version 0.7, 2017-03-14

Indhold
1 Formål
2 Arkitekturoverblik
2.1 BRS-Frontend
2.2 BRS-Backend
3 Logisk arkitektur
3.1 Webservices
3.2 Batchjobs i Backoffice
3.3 Fælles valideringsbibliotek
4 Flowchart
5 Fysisk datamodel
5.1 Datamodel for opfølgningsdatabaserne (followup)
5.1.1 Opfølgningstabel på dNSP og cNSP (brs2_followup)
5.1.2 Opfølgningstabel i Backoffice (brs2_treatmentrelationfollowup)
5.2 Datamodel for register- og notifikationsdatabasen (register_notifications)
5.2.1 Landspatientregister (LPR)
5.2.2 Sygesikringsregister (SSR)
5.2.3 Henvisningshotellet (Refhost)
5.2.4 Notifikationstabel (brs2_notification)
5.3 Datamodel for data hentet fra Stamdata
6 Valideringsregler for behandlingsrelationer
7 Teknologiarkitektur
8 Ændringslog

Anchor
_Toc292960798 _Toc292960798

Anchor
_Toc477260548 _Toc477260548

Formål

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.

Anchor
_Toc292960799 _Toc292960799

Anchor
_Toc477260549 _Toc477260549

Arkitekturoverblik

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

Anchor
_Toc477260550 _Toc477260550

BRS-Frontend

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

Anchor
_Toc477260551 _Toc477260551

BRS-Backend

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:

...

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.

Anchor
_Toc292960800 _Toc292960800

Anchor
_Toc477260552 _Toc477260552

Logisk arkitektur

Anchor
_Toc477260553 _Toc477260553

Webservices

På NSP-miljøerne udstilles følgende webservices:

...

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.

Anchor
_Toc292960805 _Toc292960805

Anchor
_Toc477260554 _Toc477260554

Batchjobs i Backoffice

Backoffice indeholder to batchjobs der begge afvikles periodisk. Schedule for jobs kan konfigureres vha. en cron expression.

...

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.

Anchor
_Toc292960806 _Toc292960806

Anchor
_Toc477260555 _Toc477260555

Fælles valideringsbibliotek

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.

Anchor
_Toc292960807 _Toc292960807

Anchor
_Toc477260556 _Toc477260556

Flowchart

Nedenfor er der et flowchart, for det overordnede flow i systemet.

Anchor
_Toc292960808 _Toc292960808

Anchor
_Toc477260557 _Toc477260557

Fysisk datamodel

Der er to typer databaser i datamodellen:

...

Tabellerne på de to typer databaser er beskrevet i det følgende.

Anchor
_Toc477260558 _Toc477260558

Datamodel for opfølgningsdatabaserne (followup)

Anchor
_Toc477260559 _Toc477260559

Opfølgningstabel på dNSP og cNSP (brs2_followup)

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.

...

CVR-nummeret bestemmer hvem der har adgang til eventuelle notifikationer. uid benyttes som identifikation af rækker over hele systemet, på tværs af NSP-miljøer. Grunden til at pk ikke kan benyttes er, at den ikke er unik på tværs af NSP'erne.

Anchor
_Toc477260560 _Toc477260560

Opfølgningstabel i Backoffice (brs2_treatmentrelationfollowup)

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.

...

Tidspunktet i nextCheck benyttes af opfølgningsjobbet til at vurdere om en opfølgning skal behandles på kørselstidspunktet.

Anchor
_Toc477260561 _Toc477260561

Datamodel for register- og notifikationsdatabasen (register_notifications)

Anchor
_Toc292960813 _Toc292960813

Anchor
_Toc477260562 _Toc477260562

Landspatientregister (LPR)

Relationstypen kan antage værdierne "REFERRING_UNIT", "TREATMENT_UNIT" eller "DISCHARGED_TO_OWN_DOCTOR" svarende til om der er tale om en henvisende afdeling, en behandlingsafdeling eller om patienten er udskrevet til egen læge. Hvis patienten er udskrevet til egen læge skal feltet organisationIdentifier indeholde et ydernummer, ellers skal det indeholde et sks.

Anchor
_Toc292960814 _Toc292960814

Anchor
_Toc477260563 _Toc477260563

Sygesikringsregister (SSR)

Anchor
_Toc477260564 _Toc477260564

Henvisningshotellet (Refhost)

Anchor
_Toc477260565 _Toc477260565

Notifikationstabel (brs2_notification)

Notifikationstabellen i Backoffice-miljøet indeholder alarm-notifikationer for behandlingsrelationer, som der ikke kunne findes evidens for indenfor tidsfristen.

...

Det eksterne referenceid svarer til den id der blev modtaget i den oprindelige opsamlingsforespørgsel. CVR-nummeret bestemmer hvem der har adgang til notifikationen. Den unikke nøgle svarer til den unikke nøgle på opsamlingsforespørgselstabellen på NSP.

Anchor
_Toc477260566 _Toc477260566

Datamodel for data hentet fra Stamdata

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.

Anchor
_Toc292960817 _Toc292960817

Anchor
_Toc477260567 _Toc477260567

Valideringsregler for behandlingsrelationer

Anchor
_Toc292960818 _Toc292960818

Anchor
_Toc477260568 _Toc477260568

Teknologiarkitektur

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.

Anchor
_Toc263424147 _Toc263424147

Anchor
_Toc292960819 _Toc292960819

Anchor
_Toc477260569 _Toc477260569

Ændringslog

Kilden til dette dokument kan findes på:
https://svn.nspop.dk/svn/trifork/brs/trunk/doc/

...