[Prev]

6.1 Dashboard

DASHBOARD views, features and functions for users (by Lex) 1. Portal for all connected Service Providers (included TAS IdP) 2. Accept Terms&Conditions TAS3 3. Accept Terms&Conditions SPs 4. Manage and view Policy Settings 5. Manage and view Transaction History 6. Manage and view Data Discovery Service 7. Manage and view Trust Ranking 8. Manage and view accessed data and attempts 9. Obtain legal confirmation of Views and Settings 10.Provide feedback to TAS3 system 11.Contact the TAS3 system (email, address, faq's) 12.Information for users (individuals, providers, technicians) on TAS3 13.Manage and view Workflow (BPE-Intalio) 14.Accept reactions from users (feed-back, complaints) 15.Legal information

Whiteboarding (by Sampo)

DASHBOARD - Features/modules/components (from Brendan / Meeting minutes in Kent)

------------ MUST DEMONSTRATE -----------------------

  1. Showing audit trails

    1. Audit trail drill down

      • should show: who (not actual identity, but role/type of user), has performed which action, upon which resource, and what time when, for what purpose [reqs 6.60, 6.64.1-2, 7.28, 9-5]

  2. - Showing a list of business processes [req 3.3]

------------ NICE TO IMPLEMENT * ---------------

  1. Privacy preference module

    1. Policy editor

    2. Policy viewer

    [reqs 3.11, 3.13, 4.1, 6.13, 7.7, 7.26, 9.2, 9.6, 9.24]

  2. Distributed Data Management [??]

  3. Consent interaction service (= where pre-specified policies are inadequate to realize requested service) [reqs 6.12, 6.16, 7.7]

  4. Data subject / patient rights module [req 6.59, 6.61]

    1. Right of access self-service (ability to see the data processed by a particular service provider) [reqs 6.51, 6.53] (subject will not be able to view data directly within dashboard due to technical complexity, but will be provided with pointers to service providers holding the data)

    2. Consent revocation service / implementation of blocking request (--> immediate effect of change in user privacy preferences?) [req 6.52, 6.62]

    3. Correction/modification/deletion request form [req 6.55, 6.56, 6.57]

    4. Notice service: once service provider is identified that corresponds with user privacy preference, he must be notified of certain elements (identity of controller, categories of recipients etc.) [req 6.59]

b + c: if granted, outcome must be pushed to relevant data recipients [req 6.58]

--------------------

(***

Hi Sampo,

For the most part, the solution you propose appears to be acceptable to me.

A few important remarks though:

  1. As a baseline, I think that only where Originating Authority/Data

Issuer = data subject, will the user be allowed to directly modify/correct --> all the rest will have to go through request forms.

Process: identify OA/DI -> link to request form -> OA/DI can then assess the request -> determine its legitimacy (according to legal criteria) -> grant/deny (but may require human intervention).

To enhance usability, it would be nice if the service providers in question make available standard forms both to request access; and next to request modification/deletion.

  1. The exceptions you imply for data consumers/burden you impose on

the user to contact the various SP data recipients might be an issue.

If a request for modification/deletion is unjustly denied, the data subject will have to take it up with the courts.

If the decision is granted, every service provider that qualifies as a controller is under an obligation to communicate the change/modification to relevant entities.

To a large extent this might be something we will only enforce through legal obligation. E.g., it might be a requirement for prospective participants to show that they have a defined procedure to follow-up on access/correction/ deletion requests and that they have outlined a procedure to communicate grant decisions to relevant actors.

But I'm concerned a bit with the language which suggests that there is no obligation on data consumers other than the OA/DI to deal with correction/deletion requests; or to propagate changes.

It's an obligation of any controller - if the dashboard provider does not control the information, it could simply provide notice that it wasn't propagated automatically, but the legal obligation to go and propagate remains with the controller to notify the relevant data recipients.

To give an example:

With regards to deletion request you write: "User MAY request deletion of the local copy from the SP using the data, but the using SP is not responsible for correcting the data at the origin. Instead the user really needs to contact the origin."

--> if the SP data consumer qualifies as a data controller, the data subject does have an actionable right towards this SP to demand correction/deletion/etc. Therefore if the user chooses to direct his request to the SP consuming the information, he must deal with it. You are correct that the SP consumer is not legally required to communicate the request to the OA/DI, but often he will be unsure of what is appropriate without contacting the OA/DI (not to request modification/deletion there, but to determine whether the data subject request is legitimate and whether it should be granted). If the consuming service provider feels it is necessary to check wit Originating Authority/Data Issuer, the burden is on the SP to communicate with the latter before locally implementing the changes. But in any case: any data consumer that qualifies as a controller has to be able to resolve the request.

I've made a couple of changes in the txt you forward to mitigate these concerns (but you might also want to give it another sanity check). (also there are still some open issues between square brackets)

Attached also the current version of the dashboard features - cross-referenced with relevant legal reqs.

Please incorporate a reference to these requirements when you outline the different functionalities of the dashboard which we envision (even if we only demonstrate a subset of these features during the review). (a finalized reqs list will be circulated soon).

)

[Prev | Next]