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, personalised and condition specific record views, and derived information such as scores or rankings 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). As such it takes advantage of the cross-application facilities such as user authentication, authorisation (e.g. single sign on) as well as the publication/ subscription rules defined by data sharing agreements and data sharing 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.
Status of document
This is the first and incomplete draft, focusing on some implementation capabilities required for a release of the Discovery Explorer that already exists. i.e. does not specify the utility in total at this stage
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, Explorer is able to make some or all of that data available. Access is further refined by access policies and related to levels of authentication and authorisation. In effect the combination of conventional role based access control and data policies makes 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:
- High level aggregate patient characteristics such as Age and ethnicity.
- Clinical and administrative value sets as defined by the project
- Specific sets of high level dashboards / reports as defined by the project.
- 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
- Patient characteristics as determined by the project.
- Clinical and administrative value sets as defined by the project
- Full access to all public visualisations.
- Specific additional dashboards
- 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. Below is SPARQL query representation of policy query using the information model:
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/:isWithin ?stp
UNION
{?userOrg :isWithin ?stp}.
{?stp :hasWithinIt Org
UNION
{?stp :hasWithinit/:commissions ?Org }}
Level 3
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 but also drill down to patient lists, condition specific record views and patient records
A data sharing project is configured as in level 2, 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 3, a person, already probably with a level 2 role would be assigned a role commensurate with authorisations to access their own organisational level patient data but no others, according to a data access authorisation policy.
This role would require 2 factor authentication
- Patient characteristics as determined by the project.
- Clinical and administrative value sets as defined by the project
- Full access to all public visualisations.
- Specific additional dashboards
- 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 (as in level 2)
- Access to patient lists including identifiable data
- Access to project configured record views
- Access to care record.
Access policy is configured to enable 6, 7, 8 for the user's own organisation. In the below example a standard organisational access policy is wrapped around any data access request to a record. Note that this would provide access to the identifiable record.
An example of organisational restriction
Select only those patients that comply with the following
Select patients where
For the user that has a role, that has an access permission to view an organisation record, and where the user has a role in the organisation that is managing the patient record
Or
SELECT ?Patient
WHERE {?user :hasRole/:accessRole viewOrganisationalRecord.
?user:_hasRoleInOrganisation ?Org.
?org : isManagingOrganisionOf ?Patient}
And thus only those entries linked to the patient and controlled by the user's organisation can be accessed.
When offering direct care, it is also likely that all data for a patient may be made available subject to data sharing. i.e. whilst the patient themselves must be managed by the organisation, the person record can be accessed. In this case the policy is amended:
SELECT ?Person WHERE {?user :hasRole/:accessRole viewOrganisationalRecord.
?user:_hasRoleInOrganisation ?Org. ?org : isManagingOrganisionOf ?Patient. ?Patient :isSamePersonAs ?Person}And thus only those patients controlled by the user's organisation can be accessed but their record may be accessed (subject to data sharing agreement filter)