Page History
...
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
- SDM4 stamdata importeres. Der er i dag 4 registre som importeres og danner evidens-grundlag for visse behandlingsrelationer (henvisningshotellet/Refhost, Landspatientregisteret/LPR, ydelsesregisteret og sikrede registeret).
- Disse replikeres løbende fra den centrale database til cNSP'ens og dNSP'ernes databaser.
- 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.
- BRS servicen checker først om der kan etableres tilstrækkelig evidens for en behandlingsrelation ud fra eksisterende evidens kilder.
- Hvis ikke, så skrives opslaget til Kafka.
- FollowupServlet kaldes løbende, og henter et batch fra Kafka.
- Bestillingerne behandles ud fra stamdata, eller lægges tilbage i køen hvis de først skal behandles senere.
- Notifikationer til service providers replikeres til databaserne på NSP'erne.
- 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.
- Efter en fastsat periode slettes notifikationerne, uagtet om de er hentet af service providerne eller ej.
Logisk arkitektur
Webservices
...
| HTML |
|---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/14616003-c1ad-40ab-822a-146eb00293a1.html" name="test" height="500" width="600800">You need a Frames Capable browser to view this content.</iframe> |
...
Behandling af opfølgningsbestillinger foregår ved at frontend'en lægger beskeder i kø i Kafka, og backend'en tager dem af og behandler dem. Det er muligt at udsætte behandling til senere ved brug af nextCheck-tidsstemplet. Hvis backend'en forsøger at behandle en bestilling, der først skal behandles i fremtiden, lægges bestillingen blot tilbage i køen.
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).
Ændringslog
...
Version
...
Dato
...
Ændring
...
Ansvarlig
...
- .
...
2011-06-15
...
Initielt dokument
...
Trifork
...
0.2
...
2011-07-27
...
Ændringer jf. databaseskema indeholdende generelle notifikationer
...
Trifork
...
0.3
...
2011-08-10
...
Opsplitning af dokumentation jf. BRS og GOS opsplitning
...
Trifork
...
0.4
...
2011-10-05
...
Tilføjelse af information om eksternt "Sikrede" register fra Stamdata
...
Trifork
...
0.5
...
2013-10-21
...
Opdateret SVN link
...
Trifork
...
0.6
...
2017-03-10
...
Tilpasset til BRS2
...
Trifork
...
0.7
...
2017-03-14
...
Rettet betegnelser på NSP-miljøer
...
Trifork
...