Closed GeertThijs closed 2 years ago
Simplified objectdiagram to illustrate the proposed solution:
This comment was checked with a GDPR expert and brought up during the 4rd thematic workshop.
The composition of the agents (DataController and Dataprocessor) in the proposed model differ from the DPV model, which works with ThirdParties instead. Hence, it was agreed to adapt the current model by adding ThirdParty as an abstract class so that the PersonalDataHandling can never be instantiated unless you are able to specify if it is a data processor or data controller and to avoid the third party from being substantiated.
Additionally the attribute "involvesThirdParty" was added to the DPV::PersonalDataHandling class.
This is still to be checked by Geert Thijs when completing the data model.
Description In use case 2 Medilab is actually a DataProcessor working under the responsability of the DataController which we believe is UZ Gent (see issue #9). It is UZ Gent that asks for Consent and has determined to proces the Datasubject's medical record for the purpose of medical emergencies. Medilab holds the record for UZ Gent and enables consultation after checking that UZ Gent has the patient's Consent. It does not ask for Consent itself and UZ Gent remains responsible. DataProcessor is a term defined in the GDPR. The GDPR also provides a class ThirdParty, which is considered anyone else except the DataSubject and the DataController involved in the Processing. If we consider DataProcessor a subclass of ThirdParty, we can describe who processes the data for the DataController. In use case 1 KBC is apart from being a DataController for Consent1, a ThirdParty for Consent2 (see #8 where we state that there are actually two Consents) as the Processing is of the type DataSharing.
Solution Add ThirdParty. Add DataProcessor as a subclass of ThirdParty. Add an attribute involvedThirdParty to the class Processing. Change the objectdiagram of use case 2 accordingly.