A hospital with one patient

A pathway to privacy

Part 2 of 5

This is part II of our blog series, 'A hospital with one patient'. In part I we described the importance of a unifying use case for the Privacy Enhancing Technology (PET) industry. Our proposal was to consider a hospital with one patient, and to explore privacy through the patient's participation in a Smart Health ecosystem.

The first step in a constructive exploration of this use case is the term consensus. A challenge we face in privacy enhancing technology is the lack of clear and concise definitions. The ambiguity of foundational abstractions adds an unnecessary burden to our value proposition.

All pathways to privacy must be paved with data. And that's where our journey will begin.

Data is the new oil, or so we've heard. But what is data? Can civil engineers and data scientists point and agree? Do regulators in different industries have a single reference? Big data, health data, Internet data, velocity, variety, volume and on and on.

Our definitions of things sometimes depend on what we do. A conversation about water between a plumber and a pirate could make us dizzy. And water we thought we knew!

We need to decouple data from its analytic potential. Otherwise, we mire ourselves into boggy domains without helping our use case. We should also craft our description of data to anticipate downstream obstacles. Any access to patient data will eventually accelerate our use case into a regulatory brick wall. Factoring in a compliance perspective may make those walls easily scalable.

As our use case deals with a person, let's agree on the following: people don't produce data. Things produce data.

I don't create a Facebook post. My browser does, on my behalf. I don't produce a blood pressure reading. The thing the nurse wraps around my bicep does.

If I go for a walk in the park I'm not producing data. If I go for that same walk with my smartphone I produce a ton of data. Whether through my spotty telco or the tightly-packed sensors or the unnecessary apps, my phone is not just collecting data. It is producing data into existence for the first time. And all of it is somehow associated with me.

Let's imagine that my phone has a motion sensor and as I walk through the park an app counts my steps. We begin by recognizing that data has two mandatory components: a value and a description of that value.

The value, for example, 100 steps, requires the trailing qualifier 'steps' to make any sense of '100'. It's not simply '100'. It's also not 100 jumps, or 100 kicks, or 100 somersaults.

Let's also allow each 'data element' to be grouped together into arbitrary 'datasets', which represent 'chronologically consistent' sets of 'data elements'.

Finally, let's define 'data events', which represent a domain-specific trigger for the creation and completion of 'dataset' boundaries. In our example above we could have a 'data event' to represent when the walk began, and when the walk ended.

The creation or production of data, while important, is just the beginning of a complex journey. The 'data path' is another foundational abstraction that needs defining and bounding.

Following our example above, we want to avoid coupling the 'data path' with any specific analytical outcome. Regulators are concerned with enforceability. As our downstream intention is patient privacy with compliance, we should endeavor to pattern our 'data path' in harmony with governable oversight.

These loosely defined, but broadly regulated, stages for a 'data path' should satisfy our use case, and many others:

These descriptions of data get us one step closer to understanding how privacy enhancing technology can solve our difficult privacy use case for a hospital with one patient.

This is part two of a five-part series of blog articles that will explore this use case, to identify the challenges and pitfalls we need to overcome to bring PET into the mainstream.

We hope these articles will be informative, and we hope you'll join us on this endeavor to explore and resolve this unique privacy use case.

arrow_back_ios Previous: A hospital with one patient - Sketching value with obscurity (Part 3 of 5)
Next: A hospital with one patient – The hardest data privacy use case (Part 1 of 5) arrow_forward_ios