...

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

...

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

Image Modified

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

...