Personal Data Stores and Data Sharing
This blog is the second in a series explaining how Mydex’s personal data infrastructure works. It explains how our platforms help deliver our mission of empowering individuals with their own data, enabling them to use this data to manage their lives better and assert their human rights in practical ways on a daily basis.
Personal data stores (PDSs) equip individuals with the means of collecting, holding and using their own data for their own purposes, under their own control, independently of the organisations that collect data about them. Our last blog on PDSs themselves described how we have implemented this core functionality so that it can operate at scale.
But PDSs have limited functionality if operating just by themselves. Sure, they provide a secure digital ‘filing cabinet’ for your data, but this doesn’t include processes for putting data into this filing cabinet, taking data out of it, or sharing it with others when needed.
This is where the real day-to-day usefulness of the PDS kicks in. There are occasions when simply being able to look our own data up, or to use our own means of ‘crunching’ this data, helps us manage our lives better. But usually we need the help of domain experts — specialist service providers.
There are countless such service providers out there offering different ways of helping us manage our different ‘life departments’ (e.g. money, home, health, travel, work, leisure activities and so on). But they all need to access at least some personal data in order to configure what they do to our particular needs and circumstances. That’s where data sharing comes in. This is the job of our second platform: our Personal Data eXchange (PDX).
The workhorse at work
The PDX is the real workhorse of our infrastructure. It’s where stuff happens (as opposed to the PDS where our personal data is stored statically).
Most of this work is done via secure APIs or ‘Application Program Interfaces’. An API is a set of commands, functions, protocols, and objects that software programmers can use for one software system to communicate or interact with another software system in a safe, automated way. APIs allow computers to ‘talk’ to each other following a set of pre-agreed rules.
Using our APIs, service providers can connect their systems to an individual’s PDS, enabling them (and the individual) to share and receive data, potentially in an ongoing, automated manner according to predefined rules. Each such request or communication is uniquely encrypted in such a manner that it can only be decrypted in the specific context of the relationship between the Mydex Member and the service provider in question.
Practically speaking, this involves lots of to-ing and fro-ing between the individual’s PDS and the service provider’s systems, as shown by this page on our developer documentation website. These handshakes between computer systems are built into how our infrastructure works and are designed to carry on working in an automated way, always according to the data sharing agreements terms defined by the service provider and approved by the individual. In other words, always under the control of the individual.
To ordinary mortals who are not software developers, the details can look daunting. Take a look at these guidelines for developers as an example. But for individuals using their PDS all this activity takes place under the hood. All that matters for the Mydex Member is that the right data can be moved in or out at the right times, safely, securely and easily. The result is a bit like a direct debit or automated payment mechanism like a salary payment: once it has been set up it keeps on running, automatically, until the person who set it up decides to change (or stop) it.
As part of what we do, we provide developers with all sorts of support systems and advice to help them deal with all the necessary technicalities. You can see an example here.
The PDX is available 24hrs a day and 365 days a year. It is ‘always on’ and always available. It creates a safe, secure cloud of connectivity between people and their service providers which is fully GDPR compliant.
Data Sharing Agreements
At the heart of this process is our Data Sharing Agreements.
In today’s system, consent has become a stick to beat individuals with. Each organisation writes their own privacy policy and terms and conditions in their own, different way, and corporate lawyers sometimes craft the wordings of these documents to be as confusing and open-ended as possible. This can make it as hard for people to protect themselves from privacy invasions and data landgrabs. Many people give up even trying.
Our Data Sharing Agreements are designed to rectify this situation.
First off, as part of subscribing to the platform, service providers have to sign up to a Trust Framework. You can see its core principles of citizen data empowerment here.
Data Sharing Agreements are written in a standard, easy-to-understand format. (You can see a template of an agreement here.) They focus on specifics: exactly what data is needed to do what, over what time period. The organisation creates the data sharing agreement, which is designed to be GDPR compliant, and makes their GDPR declarations as part of setting up their connection to the Mydex PDX API platform. As part of their terms for subscribers they acknowledge their legal commitment and liability if they fail to keep their side of the contract.
For organisations wanting to game current consent systems, our Data Sharing Agreements represent a horrifying prospect. But for bona fide service providers it’s actually a bonus. It cuts costs and complexity, creates added trust and assurance, and ensures they are GDPR compliant by default. It creates a value-releasing win-win.
The PDX uses these Data Sharing Agreements to operate. Once the individual approves the Data Sharing Agreement (DSA), the PDX notifies the subscriber that the DSA is active and they can commence delivery and collection. The PDX enforces the scope of the DSA — and only that scope. If an organisation seeks to access any data outside the terms of the DSA, the PDX blocks it. It will only allow transactions that are compliant with the DSA; that constitute a valid request. Thus, once the DSA has been set up, it operates continuously and automatically on behalf of the member.
Subscribers can create multiple connections and data sharing agreements to join the dots between their own systems. The system allows for fine tuning of the agreements to reflect service evolution and changing requirements safely, easily and in a fully auditable manner. Support services include as examples notifications of changes or additions to a Member’s PDS, or supporting batch data delivery for high volume data payloads (such as ‘smart’ meter electricity consumption data which can be generated every thirty seconds every day of the week).
Interoperability and data sharing
Working with the PDS, the PDX is an interoperability engine. Different organisations use different software systems using different standards and different formats. That’s not going to change any time soon.
This is one of our core challenges — and source of added value. Our infrastructure allows any service provider to interact with the member’s PDS using whatever software, standards and formats they currently use, and to access data shared by the individual that may have been originated elsewhere, using completely different software systems, standards and formats. We work as a translation service between these standards. This activity is built into how the infrastructure works.
Even so, one of the biggest potential benefits of our infrastructure is the way it enables data sharing between organisations via the individual who the data relates to. There are a very large number of scenarios across all industries where no one, single, service provider provides everything an individual needs to solve a problem or get a task done. That leaves individuals having to integrate the different inputs of different service providers to create an integrated whole.
Recognising this, often organisations try to set up direct ways of sharing data about the individual i.e. with each other. This quickly becomes nightmarishly complex, ethically and operationally risky, and costly. So much so that even where the need is great, often it still ends up not happening or happening slowly, badly and at great cost. Our Personal Data eXchange and PDSs are designed to eradicate this complexity, cost and risk.
Where the real value lies
One important point about this is that it’s all about data logistics. ‘Data logistics’. That’s not something that most people think about day to day. But it is immensely — pivotally — important for the provision of efficient, effective services. It is also the subject of many unhelpful misconceptions about where the value of personal data lies.
The way many people talk, you could be forgiven for thinking that data becomes valuable only when it is assembled in a massive database and when some clever algorithm or piece of AI gets to work on it, identifying patterns, correlations and trends within it, and so on. Data analytics in other words.
In lots of conversations this is treated as the be all and end all. But it isn’t. Not by a long shot. For real life services to work efficiently exactly the opposite is needed. Whatever the service is — planning and delivering a cancer intervention, say, or deciding on a mortgage or benefit application — what the service provider needs is access to exactly the right, reliable, relevant data at the right time. No more and no less. This is not about ‘the more data the better’. You don’t need a person’s inside leg measurement to decide on that mortgage application. It is all about the right data, and only the right data. It is highly focused and specific.
Our PDX infrastructure is modular and flexible, its potential data points infinitely configurable. It provides the data logistics infrastructure that every service provider (and every individual) needs to make sure that exactly the right data flows to and from the right people at the right times for every possible service relating to that individual.
Verified Attributes
A key part of all this is the ability to share what we call ‘verified attributes’.
For a service provider to be able to efficiently use data that has been shared by an individual, they have to be able to rely on it. To trust it. There’s no point in the person sharing the data only for the service provider to have to stop what they are doing to go and check to see if it is accurate or true.
What we all need is a system by which service providers can be confident in the reliability of the data they are receiving — for trust to be able to travel with the data. The PDX provides systems that enable this to happen. ‘Metadata’ — data about the data — lies at the heart of these systems.
When sharing any data, the PDX also shares additional data about the data, for example, the time and date of its origination, who originated it, when it was last updated, and so on. Thus, for example, if the data is about an educational qualification, it’s not just the individual claiming to have passed the exam. They could be lying. It includes data from the educational establishment concerned, verifying that the individual has passed their exam and when they did so.
Depending on the type of data concerned, these levels of verification can vary. If an individual is merely expressing a preference e.g. “I like it pink”, the only piece of relevant metadata is the time and date of them saying so. If it’s a person claiming to be a qualified doctor, or that they are entitled to a certain benefit or payment, much more metadata is required, as explained here. But the way our PDX infrastructure is designed, it doesn’t matter. It is designed to send all the appropriate, relevant metadata about the data routinely, as a matter of course.
Ongoing development
Providing a service like this is a bit like painting the Forth Bridge. There is always more we can do — and we have a roadmap for doing so. Some of the things included in this roadmap are Personal Data Adaptors that enable Members to invoke new connections themselves; extended interoperability and transformation of inbound and outbound payloads to accept and deliver payloads in the required format; dynamically configurable templates to enable subscribers to draw maps that correlate data held in the member’s Personal Data Store and their own internal systems; and support for ‘dynamic consent’ so that Data Sharing Agreements can be extended for one-time or defined-time periods to support specific transactions.
But behind these ongoing developments lie some very simple, general rules of thumb: make once, use many times and ‘FERC elimination’ — in whatever we do, the goal is to reduce or eliminate all possible Friction, Effort, Risk and Cost while always keeping individuals in control of their data.
Conclusion
We started this series on Mydex CIC’s personal data infrastructure by describing it as a sort of plumbing system. Personal Data Stores act as the ‘tank’ holding the data, with the Personal Data eXchange (PDX) acting as the pipes via which data flows in and out. Like a motor car’s engine, both those core infrastructure constituents work mainly under the hood. Largely invisible, and hardly ever directly experienced by individuals using their PDSs. The direct Member experience — the equivalent of the taps and valves via which data flows are managed — comes from what we call the experience layer. That is the subject of our next blog.
