Versions Compared

Old Version 2

changes.mady.by.user Unknown User (louise.kretzschmer@capgeminisogeti.dk)

Saved on

compared with

New Version 3

changes.mady.by.user Unknown User (louise.kretzschmer@capgeminisogeti.dk)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Anchor
_Toc40578283
_Toc40578283











Behandlingsrelations- og Opfølgningsservice
Driftsvejledning


Version 2.0, 2017-03-10
Anchor
_GoBack
_GoBack


Anchor
_Toc477260958
_Toc477260958
Indholdsfortegnelse

Indholdsfortegnelse
1 Formål
2 Komponenter og funktionalitet
3 Daglig drift
4 Konfiguration
4.1 Tilføjelse af CVR-numre og typer
5 Overvågning
5.1 Fortolkning af HTML overvågningsside
5.2 Overvågningstyper
5.3 Logfiler og fortolkning af disse
5.4 Konfiguration af overvågning
5.5 Eksempler på status-sider
6 Standard fejlsøgning
7 Krav til backup m.m.
8 Ændringslog


Anchor
_Toc326916714
_Toc326916714
Anchor
_Toc405782831
_Toc405782831
Anchor
_Toc477260959
_Toc477260959
Formål

Dokument målrettet systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenten.
Driftsvejledningen indeholder information om komponentens version, standard placering af logfiler og konfigurationsfiler, eksterne afhængigheder, og evt. krav til genstart af applikationer hvis komponenten ikke er responsiv.
Start/stop vejledning for komponenten beskrives, herunder hvilke andre applikationer der evt. skal genstartes. En generel læsevejledning til logfiler vedlægges.

Anchor
_Toc326916715
_Toc326916715
Anchor
_Toc477260960
_Toc477260960
Komponenter og funktionalitet

Dette dokument dækker følgende komponenter på NSP og Backoffice:

  • NSP: BRS Frontend
    • Statusurl: <serverurl>/brs-nsp/status
    • Filnavn: brs-frontend-<version>.war
    • Behandlingsrelationsservice
      • Type: Webservice
      • Url: <serverurl>/brs-nsp/service/brs
      • Funktionalitet: benyttes af klienter til kontrol af behandlingsrelationer
    • Notifikationsservice
      • Type: Webservice
      • Url: <serverurl>/brs-nsp/service/notification
      • Funtionalitet: Benyttes af klienter til at hente notifikationer
    • ReplicationJob (tidligere kendt som "GOS")
      • Type: Batchjob
      • Funktionalitet: overfører opfølgninger til backend


  • Backoffice: BRS Backend
    • Statusurl: <serverurl>/brs-backend/status/
    • Filnavn: brs-backend-<version>.war
    • ReplicationService
      • Type: Webservice
      • Url: <serverurl>/brs-backend/XXXXXXX
      • Funktionalitet: modtager data fra frontend ReplicationJob
    • FollowupJob
      • Type: Batchjob
      • Funktionalitet: verificerer om ønsket evidensniveau er opnået. Genererer notifikationer hvis tidsfristen for ønsket evidens er overskredet.
    • CleanupJob
      • Type: Batchjob
      • Funktionalitet: Sletter forældede notifikationer




Komponenterne og deres funktionalitet ses vist i nedenstående diagram:

  1. Anchor
    docs-internal-guid-796e5297-b24e-4ee0-b5
    docs-internal-guid-796e5297-b24e-4ee0-b5
    Image Added SDM4 stamdata importers. Der er i dag 4 registre som importeres og danner evidens-grundlag for visse behandlingsrelationer (henvisningshotellet/Refhost, Landspatientregisteret/LPR, ydelsesregisteret og sikrede registeret).
  2. Disse replikeres løbende fra den centrale database til cNSP'ens og dNSP'ernes databaser.
  3. Service providers (fx FMK og Sundhed.dk) kalder BRS for at registrere en adgang til data. Der angives hvilken person fra hvilken organisation, der har tilgået (eller skal til at tilgå) hvilken patient. Samtidig angives om, og i givet fald hvornår i fremtiden der ønskes opfølgning.
  4. BRS servicen checker først om der kan etableres tilstrækkelig evidens for en behandlingsrelation ud fra eksisterende evidens kilder.
  5. Hvis ikke, så registreres opslaget i databasen. Recorden ligger kun midlertidigt her, idet databasen fungerer som en kø.
  6. ReplicationJob læser periodisk i databasen for at se om der er dukket noget op.
  7. Nye entries sendes ind til den centrale komponent i Backoffice.
  8. Det checkes om den nye entry allerede er modtaget før (duplicate check), inden den gemmes.
  9. BRS FollowupJob finder (og sletter) løbende de entries, hvor det er tid til opfølgning (fx 90 dage efter registrering).
  10. BRS FollowupJob checker for hver entry om der fra evidens-kilderne kan findes en behandlingsrelation, og i givet fald med hvilken styrke. Hvis der ikke kan findes en tilstrækkelig god evidens på en behandlingsrelation, så registreres en notifikation til service provideren.
  11. Notifikationer til service providers replikeres til databaserne på NSP'erne.
  12. Service provider (fx FMK) kalder notifikations-servicen for at hente de genererede notifikationer. Ud fra disse kan den data-ansvarlige for service providerne (fx FMK eller Sundhed.dk) følge op på, om opslagene alligevel var berettigede, fx stikprøvevis.
  13. Efter en fastsat periode slettes notifikationerne, uagtet om de er hentet af service providerne eller ej.




Anchor
_Toc326916716
_Toc326916716
Anchor
_Toc477260961
_Toc477260961
Daglig drift

BRS kræver ingen daglig vedligeholdelse udover sædvanlig systemovervågning.

Anchor
_Toc326916720
_Toc326916720
Anchor
_Toc477260962
_Toc477260962
Konfiguration

Al konfiguration på hhv. NSP og Backoffice foregår ved redigering i hhv. brs-frontend.properties og brs-backend.properties, der placeres i "configuration"-folderen under Wildfly.
Bemærk at brs-frontend.properties og brs-backend.properties i visse situationer "overlapper", dvs. indeholder ens properties. Det skyldes fx at man forsøger at skabe evidens både i frontend og backend.
Nedenstående tabel giver en beskrivelse af hver property der kan sættes i filerne og dens default værdier.

Property

Beskrivelse

Default

dk.nsi.db.type

Angiver hvilken type database der bruges, værdier kan være "hsqldb" til udvikling og "mysqldb" til test og produktion.
Bruges mysqldb kræves det at databasen eksisterer inden services startes.

hsqldb

dk.nsi.validation.mode

Bruges til at bestemme hvordan SAML ID kort skal valideres, kan have 3 værdier "devel", "test" og "prod". bruges "devel" og "test" vil ID kort blive valideret mod seals SosiTestFactory, bruges "prod" vil ID kort blive valideret imod SOSI STS'en

devel

dk.nsi.auth.whitelistservice.type

Hvilken whitelistservice bruges der. Kan enten være "property" eller "database"
Bruges property vil følgende properties blive benyttet "dk.nsi.auth.brs.cvr.list", "dk.nsi.auth.create.type.cvr.list" og "dk.nsi.auth.query.type.cvr.list" disse properties beskrives nedenfor. Er værdien "database" skal data indsættes i whitelist:config tabellen som beskrevet i næste afsnit.

property

dk.nsi.auth.create.type.cvr.list

Bruges kun hvis "dk.nsi.auth.whitelistservice.type" er sat til "property"
Her angives en kommasepareret liste af cvr numre som har lov til at oprette nye opfølgninger. Hver indgang i listen består af <CVR>:<Opfølgningstype>, hvor opfølgningstype kan være "BRS" for behandlingsrelationer og "CPRSUBSCRIPTION" for opfølgninger på CPR numre
Eksempler kan være følgende:
55832218:BRS,12345678:CPRSUBSCRIPTION

<tom>

dk.nsi.auth.query.type.type.cvr.list

Bruges kun hvis "dk.nsi.auth.whitelistservice.type" er sat til "property"
Her angives en kommasepareret liste af cvr numre som har lov til at kalde notifikationsservicen, og hente notifikationer på opfølgninger for det pågældende CVR nummer og opfølgningstype. Hver indgang i listen består af <CVR>:<Opfølgningstype> som beskrevet for "dk.nsi.auth.create.type.cvr.list"
Eksempler kan ligeledes være følgende:
55832218:BRS,12345678:CPRSUBSCRIPTION

<tom>

dk.nsi.auth.brs.cvr.list

Bruges kun hvis "dk.nsi.auth.whitelistservice.type" er sat til "property"
Her angives en kommasepareret liste af cvr numre som har lov til at kalde behandlingsrelationsservicen. Hver indgang i listen består af et CVR nummer, eksempler kan ligeledes være følgende:
12345678,87654321

 

dk.nsi.db.{navn}.url

Database URL - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
Eksempel kan ligeledes være følgende:
jdbc:mysql://cnsp-db01/

 

dk.nsi.db.{navn}.driverclass

Database driver - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
Eksempel kan ligeledes være følgende:
com.mysql.jdbc.Driver

 

dk.nsi.db.{navn}.user

Database brugernavn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}

 

dk.nsi.db.{navn}.pwd

Database adgangskode - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}

 

dk.nsi.db.{navn}.database

Database navn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}

 

dk.nsi.replicationjob.enabled

Angiver om jobbet er enablet. Er obligatorisk

 

dk.nsi.replicationjob.schedule

CRON-udtryk der afgør hvornår jobbet kører. Se evt. denne beskrivelse. Er obligatorisk.
Eksempel: 15/30 * * * * *

 

dk.nsi.replicationjob.wsdlurl

Bruges af ReplicationJob til at replikere opfølgninger til backendens replication service.
Dette er URL'en til WSDLen, f.eks:
https://<host:port>/brs-backend/service/replication?wsdl

 

dk.nsi.replicationjob.transferWindow

Definerer det maksimale antal opfølgninger der må sendes ad gangen til backend.

1000

dk.nsi.replicationjob.maxtime

Max tid i minutter en replikering må tage før der laves en alarm.

120

dk.nsi.followupjob.enabled

Angiver om jobbet er enablet. Er obligatorisk

 

dk.nsi.followupjob.schedule

CRON-udtryk der afgør hvornår jobbet kører. Se evt. denne beskrivelse. Er obligatorisk.
Eksempel: 0/30 * * * * *

 

dk.nsi.followupjob.processingWindow

Definerer antallet af opfølgninger som behandles af gangen i én transaktion

1000

dk.nsi.followupjob.maxtime

Max tid i minutter en behandling af opfølgninger må tage før der laves en alarm.

120

dk.nsi.days.to.postpone.next.check

Bruges af FollowupJob: definerer tidsrummet for hvornår næste check af en opfølgning skal laves. Værdien er defineret i dage

2

dk.nsi.notificationcleanupjob.enabled

Angiver om jobbet er enablet. Er obligatorisk

 

dk.nsi.notificationcleanupjob.schedule

CRON-udtryk der afgør hvornår jobbet kører. Se evt. denne beskrivelse. Er obligatorisk.
Eksempel: 10 0/5 * * * *

 

dk.nsi.notificationcleanupjob.olderThanDays

Fjern alarmer som er ældre end denne værdi. Værdien er defineret i dage

75

dk.nsi.notificationcleanupjob.maxtime

Max tid i minutter en oprydning må tage før der laves en alarm.

120

dk.nsi.relation.assigneddoctor.update.frequency

Bruges af brs-nsp til at udregne hvilken relation der er mellem patient og læge.
Værdien defineres i dage og sammenlignes med en relations sluttid hvor imellem der bør være en opdatering fra AssignedDoctor. Hvis ikke, gives en E-relation, ellers en D-relation

10

dk.nsi.relation.refhost.update.frequency

Bruges af brs-nsp til at udregne hvilken relation der er mellem patient og læge.
Værdien defineres i dage og sammenlignes med en relations sluttid hvor imellem der bør være en opdatering fra REFHOST. Hvis ikke, gives en E-relation, ellers en D-relation

2

dk.nsi.relation.ssr.update.frequency

Bruges af brs-nsp til at udregne hvilken relation der er mellem patient og læge.
Værdien defineres i dage og sammenlignes med en relations sluttid hvor imellem der bør være en opdatering fra SSR. Hvis ikke, gives en E-relation, ellers en D-relation

62


Følgende databaser kan refereres via {navn} ovenfor:

Miljø

Navn

Beskrivelse

BRS-Frontend

stamdata

AssignedDoctor-stamdata

 

followup

Data der afventer afsendelse til BRS-Backend

 

register_notifications

Notifikationer til klienter samt SSR/LPR/REFHOST-stamdata. MySQL-replikeres fra backend

BRS-Backend

stamdata

AssignedDoctor-stamdata

 

register_notifications

Notifikationer til klienter samt SSR/LPR/REFHOST-stamdata. MySQL-replikeres til frontends

 

treatment_releation_followup

Data der modtages fra frontends



Anchor
_Toc477260963
_Toc477260963
Tilføjelse af CVR-numre og typer

Tilføjelse af CVR numre og typer på NSP'erne foregår i MySQL i tabellen whitelist_config i databasen register_notification. Når en ny af disse tilføjes replikeres opsætningen ud til de øvrige NSP'er automatisk. Der kræves ingen opdatering af brs-frontend/brs-backend.properties i den forbindelse.

Anchor
_Toc326916721
_Toc326916721
Anchor
_Toc477260964
_Toc477260964
Overvågning

BRS-frontend og BRS-backend udstiller overvågningssider, som findes i listen af komponenter i afsnit 2.
På overvågningssiderne fremgår komponentens version og build-dato, opstartstidspunkt samt tidspunkt for testudførsel. Desuden vises udvalgte metrikker angående kaldmængder/antal processeringer (se eksempler i afsnit 5.5).

Anchor
_Toc326916723
_Toc326916723
Anchor
_Toc477260965
_Toc477260965
Fortolkning af HTML overvågningsside

BRS-overvågningssider returnerer enten:

  • HTTP 200 hvis de i øjeblikket kører fint
  • HTTP 202 hvis BRS-frontend ikke kan få forbindelse til BRS-backend
  • HTTP 500 hvis der er opstået en fejl der kræver indgriben


Grunden til at der returneres HTTP 202 hvis der ikke er forbindelse til backend er, at BRS-frontend stadig kan modtage data, og derfor ikke skal tages ud af load-balanceren. Dog kan fejlen ikke ignoreres på længere sigt.

Anchor
_Toc326916724
_Toc326916724
Anchor
_Toc477260966
_Toc477260966
Overvågningstyper

Der overvåges databaseadgang for de enkelte datasources ved et simpelt "SELECT 1" statement.
For batchjob overvåges der seneste succesfulde kørsel. Hvis denne ikke er udført inden for det forventede tidsrum giver dette anledning til en fejl.
Enhver tilgang til en overvågningsside giver anledning til en mere detaljeret log-indgang hvis den giver fejl.

Anchor
_Toc326916725
_Toc326916725
Anchor
_Toc477260967
_Toc477260967
Logfiler og fortolkning af disse

Alle logfiler er at finde i "log" under Wildfly. Herunder findes en liste over alle logfiler med en beskrivelse af hvilke komponenter der skriver til dem. De enkelte filnavne er konfigureret i logging-profiles i configuration/standalone.xml. Alle logs benytter en rolling file appender, og indeholder derfor et postfix i filnavnet (fx brs-frontend.log.1) der ikke er præsenteret i nedenstående liste.

Logfilnavn

Komponenter der skriver til denne

brs-frontend.log

brs-frontend.war. Diverse logninger af komponentens opførsel, inklusiv fejllogninger.

brs-frontend-audit.log

brs-frontend.war, audit-logning af requests

brs-metrics.log

Indeholder udvalgte logninger om svartider, antal behandlede records osv. Skrives både af frontend og backend.

brs-backend.log

brs-backend.war. Diverse logninger af komponentens opførsel, inklusiv fejllogninger.


Ved en fejl på en overvågningsside skrives der til den relevante brs-frontend/brs-backend.log. Alle logs indekseres med Splunk.

Anchor
_Toc477260968
_Toc477260968
Konfiguration af overvågning

Følgende settings påvirker overvågningssnitfladen
dk.nsi.followupjob.maxtime=120
dk.nsi.notificationcleanupjob.maxtime=120
dk.nsi.replicationjob.maxtime=120
Her angiver man i minutter hvor langt tid de enkelte jobs max må tage at udføre inden overvågningssnitfladen vil begynde at returnerer HTTP 500.

Anchor
__RefHeading___Toc1113_4855908941
__RefHeading___Toc1113_4855908941
Anchor
_Toc477260969
_Toc477260969
Eksempler på status-sider


BRS-frontend OK:
Image Added BRS-frontend med warning om manglende forbindelse til backend (HTTP 202):
Image Added
BRS-backend OK:
Image Added BRS-backend med fejl pga. MySQL (HTTP 500):
Image Added Status-siderne er også i stand til at trække yderligere informationer om køstørrelser osv. fra MySQL. Disse oplysninger inkluderes dog ikke i de normalt responses, da de genererer et vist load på MySQL, men de kan trækkes ved at tilføje en "?detailed"-parameter på URLen til status-siden (fx http://host:port/brs-nsp/status?detailed).
Nedenfor ses eksempler på hvilke oplysninger der inkluderes på hhv. frontend og backend. På frontend ses det at der ligger 5 records der afventer overførsel til backend, samt 1 notification der kan hentes af klienter:
Image Added På backend rapporteres det, at followup-jobbet har 5 records der afventer behandling, 85 records der er udsat til senere check, samt en notifikation der kan hentes af klienter:
Image Added


Anchor
_Toc326916726
_Toc326916726
Anchor
_Toc477260970
_Toc477260970
Standard fejlsøgning

  • Hvis status-siden giver HTTP 500 bør man checke den tilsvarende brs-frontend/brs-backend.log, som typisk vil indeholde en mere detaljeret fejlmeddelelse end status-siden (stacktrace osv).
  • Ved problemer med indlæsning af brs-frontend/brs-backend.properties bør man verificere at filen ligger korrekt i configuration/ biblioteket. Vær opmærksom på at filen ikke læses hvis den ikke er til stede ved opstart af Wildfly.
  • Kontroller altid præcist hvilke jobs og services der er nede. Hvis BRS-backend er nede vil det også give sig udslag i warning på BRS-frontend, som i så fald ikke kan sende data videre. I den situation hjælper det ikke at genstarte BRS-frontend. Hvor ofte jobs køres kan konfigureres i property-filerne.
  • En service eller et job kan genstartes ved at kalde touch på den tilsvarende war-fil. I yderste konsekvens kan Wildfly genstartes ved at bruge /etc/init.d/wildfly8 restart.


Anchor
_Toc326916727
_Toc326916727
Anchor
_Toc477260971
_Toc477260971
Krav til backup m.m.

Data fra eksterne registre vil løbende blive slettet. Der bør derfor foretages backup af indkomne registerdata på en forsvarlig måde, i tilfælde af behovet for en genetablering af data på register_alarm i tilfælde af nedbrud. Disse skal opbevares på en forsvarlig måde da der er tale om personhenførbare data.

Anchor
_Toc263424147
_Toc263424147
Anchor
_Toc326916728
_Toc326916728
Anchor
_Toc477260972
_Toc477260972
Ændringslog

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

Version

Dato

Ændring

Ansvarlig

0.1

2011-06-15

Initielt Dokument

Trifork

0.2

2011-07-27

Opdatering af dokumentation jf. implementation af generelle notifikationer

Trifork

0.3

2011-08-10

Opsplitning af dokumentation jf. opsplitning af BRS og GOS

Trifork

0.4

2011-10-05

Mindre tilretninger jf. Stamdatas replikering af Sikrede data

Trifork

1.0

2012-06-08

Tilføjet SQL til oprydning på BRS tabeller

Trifork

1.1

2013-10-21

Opdateret SVN link

Trifork

2.0

2017-03-10

Diverse opdateringer ifm. BRS2

Trifork

...