...
Om dit probleem op te lossen in een vergelijkbare manier als bij MedMij moeten alle AuditEvents als logregel worden aangeleverd aan een centrale log component. Hierbij mogen er geen gevoelige gegevens (welke eventueel in de query string van search events zijn opgenomen) meegenomen worden in de export.
| Drawio | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Hergebruik | een groot deel van de MedMij oplossing kan gebruikt worden. | |
Beschikbaarheid van brongegevens | Zelf ophalen van de bron gegevens is gedeeltelijk van toepassing. Om alle bron gegevens zelf op te halen moet iedere bron voorzien in een mogelijkheid om informatie te lezen. Een mogelijkheid om te lezen is ook een mogelijkheid om te lekken. De bron gegevens kunnen zelf opgehaald worden bij de centrale voorziening. | |
Integriteit brongegevens | Alle partijen leveren de data aan deze wordt alleen geanonimiseerd. Andere aanpassingen zijn in het stelsel niet toegestaan. | |
Wensen voor eindgebruikers | Alle auditevents zijn beschikbaar een voorzien daardoor in de iedere individuele behoefte. |
Vragen ten behoeve van product acceptatie
Vertaling naar nieuwe formaat
Welke informatie uit AuditEvent moet over, en welke niet?
Informatie over MedMij oplossing.
Dat het in JSON formaat aangeleverd moet worden.
Wat er geanonimiseerd moet worden en op welke plek in het proces.
Of het een geautomatiseerd proces moet worden en met welke frequentie?
Wie heeft welke autorisatie nodig om gegevens aan te leveren?
Gaan er bij het versturen ook tellingen of hashtotolen toegevoegd worden?
Is er nagedacht over sizing? Verwachte groei?
Wat moet de bewaartermijn worden van gegevens op de centrale logging? Hoe wordt het geschoond?