Hi all
Thanks for this interesting discussion.
I don't think it's as simple as set out in these posts, i.e. automatically reacting to statuses.
Bear in mind that personal data, i.e. data that is directly related to an Individual (and so covered by GDPR and parallel regulations), is likely to be spread over multiple silos and applications in the service provider IT and network. And there may need to be different retention strategies for different types of personal data. It's not a given that all data should be deleted as soon as the Individual requests such, there are many aspects that mandate retention, such as:
- Closure of final bill
- Dealing with outstanding debts (on either side)
- Retaining data to protect against subsequent legal claims
- Retaining data to allow investigation by law enforcement
- etc.
Probably each impacted organization (telco, CSP, DSP) needs to develop business processes that cover the handling, archival, and removal of personal data, accounting for issues such as I have raised and any local legislation/regulation.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Jan 13, 2023 05:14
From: Lutz Bettge
Subject: How to identify if Party data is still needed?
Thank you for clarification.
So this means we need a rule that defines that when any entity having a RelatedParty that refers a PartyRole is deleted (or set inactive or similar) must update the status of the PartyRole.
The problem then is that a given PartyRole might be referred by several entities, and if one entity updates the status, that might contradict the status needed from the point of view of the second entity.
On the other hand, one could define that a PartyRole may be referred only by one entity. does that make sense?
Regards
------------------------------
Lutz Bettge
Deutsche Telekom AG
Original Message:
Sent: Jan 13, 2023 04:38
From: Koen Peeters
Subject: How to identify if Party data is still needed?
Hi Lutz,
Every PartRole has a status attribute. This inevitable means that there exists a process exists that maintains the lifecycle of this PartyRole.
The actual lifecycle is currently not defined for any of the PartyRoles so you will have to define a lifecycle applicable in your environment.
The status can be updated by user interaction (pressing a button in a UI) or by an automated process (Change the status of PartRoles that have a validity.startDate + maxValidity < Today() to expired).
The OpenAPI implicitely define that if the status field changes a PartyRoleStateChangeEvent should be generated. In projects where I am involved this is a hard requirement of any OpenAPI implementation. Without this requirement an event driven architecture might behave erratically. You might have to enforce this on your implementations as well for the proposed solution to work.
Regards
------------------------------
Koen Peeters
OryxGateway
Original Message:
Sent: Jan 11, 2023 08:00
From: Lutz Bettge
Subject: How to identify if Party data is still needed?
Hi Koen,
this is similar to our approach, our RelatedParties also refer to a PartyRole, not a Party directly; using the event is new for us, good idea;
But our problem is not: to remove the RelatedParty when the Party is deleted, but vice versa: delete the Party when all RelatedParties are gone.
How do you trigger a state change of the PartyRole when the Product/... (anything having a RelatedParty) is deleted (or set inactive or similar)?
Without that, the RelatedParty is gone, and the PartyRole remains, and no event is triggered. So you end up with the PartyRole pointing to the Party, but nothing pointing to the PartyRole.
Any suggestion?
Regards;
Lutz
------------------------------
Lutz Bettge
Deutsche Telekom AG
Original Message:
Sent: Jan 11, 2023 07:16
From: Koen Peeters
Subject: How to identify if Party data is still needed?
Hi,
This is indeed an interesting question.
I don't think there is any official guidance from TM Forum on this and don't consider my answer below as legal advice.
The interpretation used at one of my projects is as follows (and violates some current interpretations in SID)
GDPR applies to Individuals and not necessarily to Organisations.
Every relationship with an individual is be modeled as a PartyRole and we use inheritance model to implement PartyRole on all entities derived from PartyRole.
- Customer inherits from PartyRole. A Customer is valid as long as there is an Agreement that is still valid.
- SalesLead inherits from PartyRole. It is used for Marketing related processes. A SalesLead needs a defined process flow and the first step in this process should involve getting concent. Usually a Saleslead has a predefined validity period and renewal of consent is asked to extend the validity
- SalesOpportunity inherits from PartyRole (my view, not alligned with current SID) It is used for the Selling Process. It is used for "tasks at the request of a data subject who is in the process of entering into a contract". This process should have a finite validity based on expected max duration of the selling process.
- Employee: ..
- Legal obligations are captured in other PartyRoles
Whenever a "PartyRoleStateChangeEvent" is received, a logic queries if there are remaining valid PartyRoles that have the same engagedParty. If none are remaining the Individual is deleted.
No need to verify relatedParties on any other entity. The links will automatically become stale when the individual is deleted.
I hope this helps.
Regards
------------------------------
Koen Peeters
OryxGateway
Original Message:
Sent: Jan 09, 2023 08:59
From: Lutz Bettge
Subject: How to identify if Party data is still needed?
According to European General Data Protection regulations (GDPR) and probably also other privacy-related regulations, person-related data may only be stored and processed if either that Person explicitely consented to it, or there exists a contractual or compliance necessity for it.
In terms of TMF OpenAPIs, regarding the second topic, in order to find out if there is a valid reason for keeping data of some person it would be necessary to find if somewehere there is any RelatedParty referring to the person's Party data record, either directly or indirectly via a PartyRole.
In other terms, it is necessary to navigate from a Party to any resource having a RelatedParty referring to that Party.
How can this be achieved without having to request all APIs that contain a RelatedParty as sub-resource?
Thank you,
Lutz
------------------------------
Lutz Bettge
Deutsche Telekom AG
------------------------------