MO-52 Logging-monitoring en rapporteren
- Kailesh Bansi (Deactivated)
- Casper van der Harst
1. Managementsamenvatting
-
2. Koppelingen
MO-24 Duiding van fouten: de logging kan worden gebruikt voor het vertalen van fouten naar bruikbare informatie voor de PGO/gebruiker.
AOF-LSP+: RB/ RS log interface. Er wordt meer gelogd dan daadwerkelijk wordt gebruikt voor de rapportages door LSP+
Validatieloket: Het validatieloket heeft een memo opgesteld betreft logging en rapportages
https://confluence.vzvz.nl/x/KUziBQ
3. Inleiding
3.1.1. Bron: Project Logging
Logging heeft tot doel een betrouwbaar overzicht te kunnen leveren van de gebeurtenissen waarbij persoonlijke gezondheidsinformatie is verwerkt. De achterliggende businessdrivers zijn:
Raadplegingen door de patient
Raadplegingen van logging kunnen zich voordoen op verzoek van de patiënt. De patiënt heeft vanuit de wetgeving en NEN-norm recht op de inzage van inzage en afschrift van logbestanden of delen van logbestanden die op hem of haar van toepassing zijn.
Track and trace
Dit omvat het traceren van de data en bijhouden van de uitwisseling en applicatie interactie. Dit includeert onder andere:
Auditing
Het leveren van bewijs dat is voldaan aan de eisen vanuit de wet- en regelgeving.
Foutafhandeling en foutpatronen
Het achterhalen van foutpatronen en de afhandeling van fouten door de systeembeheerder
Reporting
Rapportages geven de prestaties weer en daarmee de mogelijke kansen voor verbetering op basis van besluiten door het management.
(preventieve) Monitoring en alarmering
Het voorzien in preventieve monitoring zorgt ervoor dat de beheerder van applicaties voortijdig kan zien of zijn applicaties dreigen vast te lopen en hij daardoor anticiperend actie kan ondernemen dan wel in de gaten kan blijven houden voor verdere escalaties.
Om logging mogelijk te maken dient er rekening te worden genomen met een aantal aspecten. De NEN7513 noemt:
de verantwoordelijkheid voor de logging (8.2);
de beschikbaarheid van de logging (8.3);
welke eisen er gelden over de toegang tot de logging (8.4);
de bewaartermijn van loggegevens (8.5);
voorwaarden voor interoperabiliteit (8.6).
Dit issue focust zich op de monitoring en alarmering door middel van de logging van berichten op agerende en reagerende systemen. Op basis van deze logging kunnen rapportages worden uitgedraaid.
4. Huidige situatie
4.1. Probleemstelling
Momenteel bestaat de rapportage bij MedMij uit een aantal indicatoren die niet goed weergeven wat de beschikbaarheid is van het afsprakenstelsel/netwerk. Door de (realtime) berichtuitwisseling te loggen kan een beter beeld worden geschetst van de beschikbaarheid is en technische uitvoering door het netwerk. Uit de dagelijkse praktijk van Ketenregie kunnen zij hun functie niet naar behoren invullen door een vertraagde inzage
RACI:
De behoefte komt voornamelijk vanuit Ketenregie. Zij geven aan dat zij hun rol als ketenbeheerder niet goed kunnen overzien/monitoren door het ontbreken van de juiste indicatoren die een goed werkend netwerk weergeven.
De DVA's hebben ook baat bij betere monitoring en rapportages voor optimalisatie van eigen prestaties en voortijdig ingrijpen op hick-ups. Ketenregie geeft aan dat ondanks de verantwoordelijkheid die bij DVA's ligt betreft logging, zij alsnog de monitoring door MedMij willen zien.
R&S bij het bereiken van een bepaalde trashhold wordt een signaal gestuurd naar R&S ihkv AORTA die vervolgens Ketenregie benaderen.
Daarnaast heeft stichting MedMij belang bij goede monitoring ter verantwoording aan de sponsoren en voor toekomstige verbeteringen van het afsprakenstelsel.
Momenteel wordt er gelogd op de verschillende interfaces: Authorisatie, Token en Resource interface.
5. Doel / Gewenste situatie
De ideale situatie is er een waarin ketenregie het totale verkeer en elke interactie tussen componenten kan loggen en monitoren om te zien hoe het verkeer tussen de componenten/partijen verloopt. Dit dient near-realtime te zijn, zodat Ketenregie hierop kan sturen en de partijen kan benaderen. Dit kan het streven van een ketennorm bevorderen.
Aangezien MedMij werkt met decentrale componenten en asynchrone bevragingen- (1 ZIB bestaat uit 27 blokjes) dienen de partijen bv gebruik de maken van tracing naast de logging om de berichtenketting te kunnen traceren en waar deze wordt onderbroken. Aangezien MedMij uit decentrale componenten bestaat is er een oplossing in de vorm van een (CENTRAAL) Log Opslag component dat valt onder MedMij regie/beheer. Het Log Opslag component in de logging infrastructuur bestaat uit een of meer logservers die de loggegevens van de Log Generator ontvangen of kopieën van loggegevens van het systeem. De gegevens worden in real-time of bijna real-time naar de logservers overgebracht, of in incidentele batches op basis van een schema of de hoeveelheid loggegevens die wacht om te worden overgedragen. Servers die loggegevens ontvangen van meerdere Log Generatoren worden soms collectors of aggregaties (samenvoegen van loggegevens) genoemd. Loggegevens kunnen worden opgeslagen op de logservers zelf of op afzonderlijke databaseservers.
Voorwaarden: per regio voor M&K kunnen rapporteren, koppeling met AS/ZAB
6. Oplossingsrichtingen
6.1. Usecases
Kunnen loggen van realtime berichtenuitwisseling tussen componenten- DVA & toekomstig de bronsysteem.
Gebruik van een trace ID (keten) en een Correlation ID (interactie tussen)
Vanuit de DVA wordt een redirect uitgevoerd richting DigiD. Op dit moment wordt gebruik gemaakt van de timestamps (ivm de timeouts). Daarentegen (https://www.logius.nl/diensten/digid/documentatie/koppelvlakspecificatie-digid-saml-authenticatie)
6.2. Voor- en nadelen
Het overtuigen van en medewerking krijgen van de verschillende betrokken partijen.
Voorwaarde stellen dat: de log mag niet herleidbaar zijn naar de persoon/persoonsgegevens bevatten. (Zie nen7513)
Momenteel wordt de