Discovery Explorer- Specification

This version : (0-1 Draft)

Abstract

Discovery Explorer is a web based application that provides insights into population level and personal health data.

The types of insights or 'visualisations' include dashboards, reports, and lists, in addition to personalised and condition specific record views and derived information for decision support. The application is one of a suite of utilities that provide user interfaces that are part of the Discovery Data Service (DDS) and as such takes advantage of the cross-application facilities such user authentication, authorisation (e.g. single sign on) as well as the publication/ subscription rules defined by data sharing agreements and projects.

This specification does not cover the content of the visualisations, and is limited to describing the overall minimum capabilities of the application at a particular point in time.

Summary of changes

There have been no substantial changes since the previous version. For minor changes see the change log

Data sharing agreements and data sharing projects

Access to Data via DDS is subject to a data sharing agreement, no matter who is accessing the data. The data sharing agreement is a high level agreement, usually made at a local regional level, which describes the general purposes for which the data can be used and for which purposes. An agreement is made between a set of publishers (those that contribute the data and are the data controllers within Discovery) and a set of subscribers (those that wish to access some of the data made available), or sometimes a class of subscribers.

Access to Data via DDS is also subject to a data sharing project level agreement (DSPA). This level is more explicit about things such as the nature of the data flow, a specific data set, whether detailed or aggregate, project level consent model, scheduling of data and data format. Every DSPA is associated with one data sharing agreement and there are usually many project level agreements for each DSA.

Having established the policy of what data a subscriber, or class of subscribers, can access, the Explorer is able to make some or all of that data available as further defined by to the relevant levels of authentication and role based authorisations. In effect the combination of conventional role based access control and data policies make this an attribute based access control model.

In the context of use of explorer data sharing projects are established to enable access to a set of dashboards made available through the project data set.

Access- authentication and authorisation

This section covers the cross application Discovery capabilities of authentication and authorisation in the context of Explorer.The actual process of Authentication within Discovery is specified elsewhere, including the use of the openID Connect, protocol, as is the process of Authorisation as supported by the Oauth 2.0 protocol together with a form of derived attribute based access control which is used to fulfil the requirements in this specification.

In the context of Explorer, the approach to authentication is closely linked to the authorisation to access functionality within the application,

Authentication approach it is also associated with the nature and breadth of the data resources available via the application. The latter is specified at length via the data sharing manager specification and the data sharing project manage specification.To summarise these, suffice it to say that any data made available to a user has been made available as a result of specific permission of the data controllers of the data, for the explicit purposes within explorer, these permissions manifested through a set of machine readable data sharing rules. Any organisational related data is provided by permission from the organisations so named.

Specifically, 3 levels of authentication are supported, and each level is associated with authorisation to access the data made available via the DSPAs, commensurate with the level of identity management and authentication.

Level 1

Explorer is provisioned in a way that any member of the public can access high level information.

A data sharing project is configured to enable access to Discovery public Dashboards.

This is configured with a dynamic a data set which encompasses the data used in the dashboards i.e. is directly matched to the cumulative total of the value sets and patient characteristics used by the Dashboards. Only those dashboards and value sets authorised as part of the data sharing project will be designed and made available.

At level 1, a person, intending to be a user should able to create their own account, by entering their user id (email) their name and password and using email verification to activate account.

Once having created the account, a user is able to log on with user id and password, with an email based password refresh facility for lost or forgotten user ids

Once an account is created the user is assigned a "public role" that enables them to view only those dashboards configured to show data with restrictions.

Restrictions to data are defined by "data access authorisation policy" associated with the data sharing project. Such a policy for level 1 would consist of:

1. High level aggregate patient characteristics such as Age and ethnicity.
2. Clinical and administrative value sets as defined by the project
3. Specific sets of high level dashboards / reports as defined by the project.
4. Publisher organisational grouping level of CCG or above (e.g. STP, nationally). i.e. comparison of patient data aggregated to CCG according to the GP practice they are registered at.

Level 2

Explorer is provisioned in a way that a user in a role in relation to a subscriber organisation can view high level dashboards and more detailed information at the level of organisations.

A data sharing project is configured to enable access to Discovery Private Dashboards. Subscriber organisations are configured from the data sharing agreement in the standard way.

The project is configured with a dynamic a data set which encompasses the data used in the dashboards i.e. is directly matched to the cumulative total of the value sets and patient characteristics used by the Dashboards. Only those dashboards and value sets authorised as part of the data sharing project will be designed and made available.

At level 2, a person, intending to be a user would have an account created by them by the delegated super user facility i.e. a standard Discovery user manager approach, but with single factor authentication only being required.

Once having an account the user is assigned as a standard organisational based role with certain authorisations according to a data access authorisation policy

1. Patient characteristics as determined by the project.
2. Clinical and administrative value sets as defined by the project
3. Full access to all public visualisations.
4. Specific additional dashboards
5. Access to organisational level dashboard aggregate level, the grouping of organisations that a user can access at organisation level, being determined by the project access policy configuration. Two policy examples follow:

• Policy a) A user in role at a provider is authorised to access provider level data . Providers available for view include only those providers (practices) that are commissioned by their CCG. i.e. the access policy indicates that a user can only see the list of practices that are commissioned by the same CCG that their practice is commissioned by. A user at Mile end road Surgery can access practice level aggregate data for Chrisp Street but cannot access data at Barking Medical Group.
• Policy b) . A user in role at a provider is authorised to access provider level data for providers that are within the region covered by their STP i.e. the policy indicates that a user can only see the list of providers that have the relevant relationships. A user at Chrisp Street surgery would be able to view Homerton Trust an Barking Medical practice data

Select a list of organisation to view for the user's organisation
First find their commissioning CCG and the STP it is within OR directly find their STP.
Then find the other organisations that are within the STP directly, or indirectly via their CCG

SELECT ?Org
Where {{
        ?userOrg :isCommissionedBy/:is_withinSTP ?stp
         UNION
        {?userOrg  :is_within ?stp}.
        {?stp ^:isWithin ?Org
          UNION 
         {?stp ^isWithin/:isCommissionedBy ?Org }}                       

• Patient characteristics as determined by the project
• Specific set of high level