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

...

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.

...

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

• NSP: BRS Frontend
  • Statusurl: <serverurl>/brs-nspbackend/status/
  • Filnavn: brs-frontendbackend-<version>.war
  • ReplicationServiceBehandlingsrelationsservice
    • Type: Webservice
    • Url: <serverurl>/brs-nspbackend/service/brsXXXXXXX
    • Funktionalitet: benyttes af klienter til kontrol af behandlingsrelationer
    Notifikationsservice
    • modtager data fra frontend ReplicationJob
  • FollowupJob
    • 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
  • • Batchjob
    • Funktionalitet:
  • 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. Image Removed SDM4 stamdata importersimporteres. 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 skrives 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.

...

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

1. til Kafka.
2. FollowupServlet kaldes løbende, og henter et batch fra Kafka.
3. Bestillingerne behandles ud fra stamdata, eller lægges tilbage i køen hvis de først skal behandles senere.
4. Notifikationer til service providers replikeres til databaserne på NSP'erne.
5. 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.
6. 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. Disse filer er volume-mappet, så de er tilgængelige på docker-hosten.
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.

...

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.

...

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

Konfiguration af FollowupJob

Servicens job til behandling af opfølgningsbestillinger bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af jobbet i fler-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.

Driften vedligeholder en cron, som kalder jobbets url i et fast mønster vha. curl.

Indstillinger relateret til behandling af opfølgningsbestillinger er beskrevet i tabellen ovenfor.

Kommando til kald af slettejob:

curl <server>/brs-backend/followup

Kaldet vil returnere 200 OK hvis alt går godt, ellers 500 Internal Server Error.

Konfiguration af Oprydningsjob

Servicens job til oprydning bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af jobbet i fler-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.

Driften vedligeholder en cron, som kalder jobbets url i et fast mønster vha. curl.

Kommando til kald af oprydningsjob:

curl <server>/brs-backend/notificationcleanupjob

Kaldet vil returnere 200 OK hvis alt går godt, ellers 500 Internal Server Error.

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.

Duplikering af data for CVR-nummer ifm. certifikatskift

I forbindelse med udskiftning af et anvendercertifikat kan det være nødvendigt at duplikere data for et CVR-nummer, som beskrevet i anvenderguiden, afsnit 2.5. Hvis der er behov for dette, køres nedenstående SQL-script.

Inden scriptet køres, justeres variablerne old_cvr og new_cvr.

set @old_cvr = '46837428';
set @new_cvr = '12345678';

use followup;

begin;

-- Duplicate from BRS2_TreatmentRelationFollowup
insert into BRS2_TreatmentRelationFollowup (
    nextCheck,
    queryableCvr,
    externalReferenceId,
    uid,
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    created,
    sor
)
select
    nextCheck,
    @new_cvr, -- the new cvr
    externalReferenceId,
    uuid(), -- new uid
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    created,
    sor
from
    BRS2_TreatmentRelationFollowup
where
    queryableCvr = @old_cvr;

-- Duplicate from BRS2_Followup
-- We need a relation between old and new serial numbers later on, when duplicating into the BRS2_Notification table, as that table refers into BRS2_Followup through the followupSerialNumber-column.
-- We achieve this by creating a temp table of the followups that need to be duplicated, and generate fresh uid's there. The contents of the temp table are then inserted into BRS2_Followup. This allows us to relate serial numbers through the chain <old serial> <-> <old uid> <-> <new uid> <-> <new serial>.

-- Create the temp table
create temporary table BRS2_Followup_tmp select * from BRS2_Followup where queryableCvr = @old_cvr;
alter table BRS2_Followup_tmp add column newUid varchar(36);
update BRS2_Followup_tmp set newUid = uuid();

-- Insert into into BRS2_Followup (from the temp table)
insert into BRS2_Followup (
    queryableCvr,
    externalReferenceId,
    uid, -- The uid we just generated. 
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    created,
    errorCount,
    nextSync,
    sor
)
select
    @new_cvr, -- the new cvr
    externalReferenceId,
    newUid, -- The new uid we just generated
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    created,
    errorCount,
    nextSync,
    sor
from
    BRS2_Followup_tmp;

commit;

use register_notifications;

begin;

-- Duplicate from BRS2_TreatmentRelationFollowup
insert into BRS2_Notification (
    externalReferenceId,
    queryableCvr,
    creationTimestamp,
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    actualRelations,
    followupSerialNumber,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    uid,
    sor
)
select
    n.externalReferenceId,
    @new_cvr,
    n.creationTimestamp,
    n.doctorOrganisation,
    n.hospitalOrganisation,
    n.ean,
    n.patientCpr,
    n.healthProfessionalCpr,
    n.relationLookupStart,
    n.relationLookupEnd,
    n.timeLimit,
    n.acceptableRelations,
    n.actualRelations,
    coalesce(f.pk, n.followupSerialNumber),
    n.followupRelations,
    n.authorisationIdentifier,
    n.serviceProviderName,
    n.serviceProviderVersion,
    n.serviceProviderVendor,
    uuid(),
    n.sor
from
    BRS2_Notification n
    left join followup.BRS2_Followup_tmp ft on
        n.followupSerialNumber = ft.pk
    inner join followup.BRS2_Followup f on
        ft.newUid = f.uid
where
    n.queryableCvr = @old_cvr;

commit;

Validering af SAML ID-kort

Der anvendes security-api til validering af SAML ID-kort. Hvis miljøvariablen NSP_TEST_FEDERATION er sat til true, vil ID kort blive valideret mod test-føderationen, ellers mod prod-føderationen

...

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

...

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

...

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.xmlhhv. brs-backend-log4j.xml og brs-frontend-log4j.xml, og er volume-mappet ind, så de er tilgængelige på docker--hosten. 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.

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

Logning af Evidens tjek

...

Det forventes at driften opsamler alle logninger fra dk.nsi.brs.common.audit.EvidenceLogger, da den udtømmende liste af logninger er forholdsvis stor. Den vil på sigt også kunne justeres, så der kommer ændrede logninger.

I forbindelse med at LPR3 gør brug af SORLSSORES, som kilde til bl.a. mapning fra Shak til Sor, så er der også indført en mere detaljeret logning af de tjeks der udføres, når klassifikation skal findes for hver af typerne LPR, LPR3, SIKREDE, REFHOST og SSR.

• msg
  • Start - Logges ved oprettelse af en EvidenceLog
  • Input - Oplysning omkring evidenskilder.
    
    • Key: Nøgle som bruges til at identifisere f.eks. input
    • Data: indhold af f.eks. input
    • Type: LPR3  - På sigt vil der komme yderligere typer til. Nu findes kun EvidensLog for LPR3
  • Execute - Ved en større gruppering af tjeks logges det om gruppering udføres.samling af tjek, der har en logisk sammenhæng,  logger vi om samlingen bliver udført eller om den springes over.
    • Action: Hvilken handling kan udføres
    • Active: Skal handlingen udføres - besvares med yes eller no
      
  • Collect - Når ekstern service kaldes for at samle input data (f.eks. kald af Sores Service)
    • Collect Identifier: Formatet for denne id er D? og den har sammenhæng med de identer der er på flowet for LPR3 under BRS - Design- og Arkitekturbeskrivelse
    • From: Hvilken kilde levere data
    • Into: Hvilken input nøgle gemmes data i
    • Parametre: Kommer altid i sæt af 2 i formatet KEY=VALUE. Antallet af parametre er ukendt, da det afhænger af hvilken service der blivver kaldt.
    • Type: LPR3  - På sigt vil der komme yderligere typer til. Nu findes kun EvidensLog for LPR3
    • Spørgsmål efterfulgt af yes eller no f.eks. "Skal XYZ udføre=yes"
    Input - Oplysning omkring evidenskilder.
    
    • Type: LPR3  - På sigt vil der komme yderligere typer til. Nu findes kun EvidensLog for LPR3
    • Key: Nøgle som bruges til at identifisere f.eks. input
    • Data: indhold af f.eks. input
  • Check - Tjek der udføres
    • Type: LPR3  - På sigt vil der komme yderligere typer til. Nu findes kun EvidensLog for LPR3
    • Check Identifier: Bruges til at idenfitifisere tjekket imod flowdiagrammet
    • Spørgsmål taget fra flowdiagram og besvaret med yes eller no
    • Check Identifier: Formatet for denne id er C? og den kobles med de identer der er angivet i flowet for LPR3 under BRS - Design- og Arkitekturbeskrivelse
      
    • Question: Det spørgsmål der ønskes besvaret. De kan være taget direkte fra flow diagrammet for LPR3 under BRS - Design- og Arkitekturbeskrivelse. Men dette er ikke et krav.
    • Answer: Spørgsmålet besvaret med fritekst eller med yes/no
  • Suggest - En rækker krav er opfyldt og en forløbig klassifikationer kan angives
    • Suggestion: Den klassifikation der ønskes
      
    • Current: Den nuværende klassifikation
  • Stop - EvidenceLog lukkes og endeligt klassifikationsresultat logges.
    • Classification Result (Se listen over klassifikationer under BRS - Design- og Arkitekturbeskrivelse samt Behandlingsrelationsservice (BRS) - Leverancebeskrivelse
      

For alle rækker i en Evidens log findes værdierne:

• Type: LPR3  - På sigt vil der komme yderligere typer til. Nu findes kun EvidensLog for LPR3

...

• flowID: Hvis den er sat på medcom headeren. Et samlet Evidenssæt vil have samme flowID.
• messageID: Hvis sat på medcom headeren.
• securityLevel: Hvis sat på medcom headeren.

19071800 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Start, securityLevel=3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=test, Type=LPR3
19291820 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Input, securityLevel=3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=test, Type=LPR3, Key=Opslagsdata, Data=CheckedRelationRelayerData[doctorOrganisationIdentifier:<null>,hospitalOrganisationIdentifier:730014730011,ean:<null>,sorIdentifier:<null>,patientCpr:4F49B059C4A7864051B7AA6D1E392DBF2B9C57F565663455A743AC4B1E2A2E5F40F01183C6C4824E,healthProfessionalCpr:<null>,relationLookupTimeInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000]
19291820 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Execute, Type=LPR3, Action=Executing with SHAK, securityLevel=3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=testActive=yes
1820 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Execute, Type=LPR3, IsAction=Executing executingwith withSOR, SHAKActive=yesno
19301821 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=InputCollect, securityLevelType=3LPR3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=test, Type=LPR3, KeyCollect identifier=D1, From=SorServiceDao.getShakSorMap, Into=SOR(sundhedsprof), DataShakIdentifier=[439061000016004]730011
19301821 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=InputCollect, securityLevelType=3LPR3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=test, Type=LPR3, KeyCollect identifier=D1, From=SorServiceDao.getShakSorMap, Into=SOR(sundhedsprof, sygehus), DataShakIdentifier=[]730011
19391821 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=InputCollect, securityLevelType=3LPR3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=test, Type=LPR3, Key=LPR3 data, Data=[LPR3[patientCpr:4F49B059C4A7864051B7AA6D1E392DBF2B9C57F5,admittedInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000,lprReference:111111111111111111111111111111111111111111111111111111111114,relationType:RESULTATINDBERETNING,sorIdentifier:439061000016004]]
1939Collect identifier=D2, From=SorServiceDao.searchAllChildren, Into=SOR(sundhedsprof), SOR(sundhedsprof)=[439061000016001]
1821 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Check, securityLevel=3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=testInput, Type=LPR3, Check identifier=C1, Findes LPR3 data for patienten på præcis Key=SOR(sundhedsprof) eller på en SOR kode der ligger under SOR(sundhedsprof) i SOR hierarkiet?=yes
1939, Data=[439061000016001]
1821 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Input, Type=LPR3, Key=SOR(sundhedsprof, sygehus), Data=[]
1827 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=CheckInput, Type=LPR3, securityLevelKey=3LPR3 data, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=test, Type=LPR3, Check identifier=C2, Er der overlap mellem dato-interval for LPR3 registreringer og input tidsintervallet?=yes
1939Data=[LPR3[patientCpr:65663455A743AC4B1E2A2E5F40F01183C6C4824E,admittedInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000,lprReference:111111111111111111111111111111111111111111111111111111111111,relationType:FORLOEBSELEMENT,sorIdentifier:439061000016001]]
1827 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Check, securityLevel=3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=test, Type=LPR3, Check identifier=C3C1, Hvilken type har de matchende LPR3 registreringer?=esultatindberetning eller opholdsadresse
1939 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Execute, securityLevel=3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=test, Type=LPR3, Is executing Check SOR(sundhedsprof, sygehus)=yes
2015Question=Findes LPR3 data for patienten på præcis SOR(sundhedsprof) eller på en SOR kode der ligger under SOR(sundhedsprof) i SOR hierarkiet?, Answer=yes
1827 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=InputCheck, securityLevelType=3LPR3, Check flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0eidentifier=C2, messageIDQuestion=test, Type=LPR3, Key=LPR3 data, Data=[LPR3[patientCpr:4F49B059C4A7864051B7AA6D1E392DBF2B9C57F5,admittedInterval:2018-01-14T12:00:00.000/2018-01-20T12:00:00.000,lprReference:111111111111111111111111111111111111111111111111111111111111,relationType:FORLOEBSELEMENT,sorIdentifier:439061000016001]]
2015Er der overlap mellem dato-interval for LPR3 registreringer og input tidsintervallet?, Answer=yes
1828 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=CheckSuggest, securityLevelType=3LPR3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0eSuggestion=A, messageID=test, Type=LPR3, Check identifier=C4, Findes LPR3 data for patienten med overlap på input tidsinterval og med typerne relationstyperne Current=E
1828 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Check, Type=LPR3, Check identifier=C3, Question=Hvilken type har de matchende LPR3 registreringer?, Answer=forløbslement, kontakt, procedure, intitiel henvisning eller henvisning?=yes
20161828 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=InputExecute, securityLevelType=3LPR3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=test, Type=LPR3, Key=SOR sygehuskode, Data=-9223372036854775808
2016Action=Executing Tjek SOR(sundhedsprof, sygehus), Active=no
1828 [main] INFO  dk.nsi.brs.common.audit.EvidenceLogger$SimpleEvidenceLog  - msg=Stop, securityLevel=3, flowID=a98bc41c-08b0-42aa-9337-8ab2e465ca0e, messageID=testEvidenceLogger$SimpleEvidenceLog  - msg=Stop, Type=LPR3, Classification Result=B

A

Audit logning

Auditlogning foretages med det officielle NSP Audit Log modul.

...

Anchor
__RefHeading___Toc1113_4855908941 __RefHeading___Toc1113_4855908941

Anchor
_Toc477260969 _Toc477260969

Eksempler på status-sider

BRS-frontend OK:

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

BRS-frontend med warning om manglende forbindelse til backend (HTTP 202):

Image Removed
BRS-backend OK:
Image Removed

BRS-backend med fejl pga. MySQL (HTTP 500):

Image Removed

BRS-backend med fejl pga. at behandlingstiden for en opfølgning er for lang. Fejlen opstår når et batch til opfølgning tager for lang tid. Og status viser både hvorhvornår en kørsel er kørt helt færdig (lastSuccessfullAllBatches), og hvornår et batch er blevet kørt færdig (lastSuccessfulRun). Er lastSuccessfullAllBatches blank, betyder det, at der er tale om den første batchkørsel siden start af servicen, og den endnu ikke er afsluttet.

Image Removed

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 Removed

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 Removed

...

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

...

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.

Image Added

BRS-backend med fejl pga. at behandlingstiden for en opfølgning er for lang. Fejlen opstår når et batch til opfølgning tager for lang tid. Og status viser både hvorhvornår en kørsel er kørt helt færdig (lastSuccessfullAllBatches), og hvornår et batch er blevet kørt færdig (lastSuccessfulRun). Er lastSuccessfullAllBatches blank, betyder det, at der er tale om den første batchkørsel siden start af servicen, og den endnu ikke er afsluttet.

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 er volume-mappet korrekt ind 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 stoppes og starter gennem docker.

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.

Migrering ved overgang til Kafka-løsning

I release 2.1.0 er BRS ændret, så Kafka anvendes til at vedligeholde køen af bestilte opfølgninger. Anvendelsen af Kafka erstatter den tidligere followup-database. I den forbindelse er der brug for at behandle de bestillinger der allerede ligger i followup-databasen, og sætte dem i kø i Kafka. Til dette formål er der udviklet en kommandolinjeapplikation, kafka-migration, som leveres som et docker-image (navn: registry.nspop.dk/components/brs/kafka-migration). Applikationen forbinder til followup-databasen og kafka-serveren, og fungerer som følger:

1. Hent et batch af bestillinger fra BRS2_TreatmentRelationFollowup-tabellen.
2. Hver bestilling sættes i kø som en kafka-besked.
3. Bestillingerne slettes fra BRS2_TreatmentRelationFollowup-tabellen.

Applikationen udfører ovenstående procedure, ind til BRS2_TreatmentRelationFollowup-tabellen er tom. I tilfælde af fejl standser applikationen.

Applikationen konfigureres i filerne kafka-migration.properties og log4j.properties. Disse filer volume-mountes på stien /config. Nedenfor dokumenteres indholdet af kafka-migration.properties. Indholdet af filen log4j.properties er standard og forventes ikke at skulle ændres, og en gennemgang af indholdet er derfor udeladt.

I development-setuppet (compose/development/docker-compose.yml) findes et eksempel på, hvordan applikationen sættes op.

...

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

...

KvalitetsIT

...