A hospital with one patient - Sketching value with obscurity (Part 3 of 5)

A hospital with one patient

Sketching value with obscurity

Part 3 of 5

This is part III of our whitepaper, 'A hospital with one patient'. In parts I and II we proposed a use case, a hospital with one patient, and began to define important terms like 'Data'. These terms are key for our collaborative exploration of privacy and Privacy Enhanced Technology (PET) solutions for complex use cases.

In part II we established a framework for both data and a data path. These data pathways, oriented around areas of regulatory focus, ensure that exploration of privacy use cases can translate to compliant market solutions.

The hospital in our use case has a single patient. Let's assume that the hospital is fully staffed with doctors and nurses and administrative staff, who all need access to the patient's data.

Privacy, like data, is an abstraction we need to distill for constructive discussion. We recognize that 'privacy cannot begin without establishing ownership'. In the case of 'data privacy', we begin by identifying the 'data owner'.

In our 'hospital with one patient', the 'patient is the data owner'.

We have noted previously that 'people don't produce data'. 'Things produce data'. With this in mind, let's imagine that our hospital is full of diagnostic instruments for collecting patient data: X-Ray machines, blood collection, EKGs, PET scans, CAT scans, etc.

Fig III.1

This creates a challenging data and privacy dilemma. (See Fig III.1)

1. The hospital owns the diagnostic instruments
2. The data produced by the instrument owners (the hospital) belongs to the patient
3. Without access to the patient-owned data the hospital staff cannot provide necessary health care

To explore this scenario, we begin by choosing two points of data collection:

• Blood collection
• X-Ray

We define a simple 'data element' for each type of data production. (Fig.III.2)

Fig III.2

We add more data elements to supplement the 'dataset' and provide broader context for the patient's data. These new data elements may not be produced by the instruments themselves. These data elements are, nevertheless:

1. Required to deliver adequate patient health care
2. Owned by the patient

It is simple, within this scenario of a single hospital, to imagine how the patient's data can be maintained with regulated and compliant privacy. The challenge we set ourselves, however, was to allow the hospital to participate in a Smart Health ecosystem.

Ecosystems, like many of our terms, is an abstraction. Let's define a simple ecosystem with a limited number of participants: (See Fig.III.3)

Fig III.3

1. An external clinic for X-Ray analysis, which the hospital can outsource the patient's X-Ray to for efficiency and reduced health care costs.
2. An external blood-analysis clinic, which will maintain the patient's blood work history for preventative and diagnostic analysis. We imagine here that this clinic has significant and specialized expertise in blood analysis, which would be challenging for our hospital to develop internally. We want to ensure that our patient has access to the best health care the market can provide.

Our simple ecosystem allows us to summarize a comprehensive set of 'data pathways'. (Fig. III.4) Each individual pathway allows us to narrowly define a specific set of prerequisites and policies to ensure.

Fig III.4

Data owner represents the patient for any data related directly or indirectly to John Doe. Data custodian, on the other hand, represents the hospital. The hospital does not own John Doe’s data, but they have a custodial responsibility for protecting the security and privacy for the individual data of every patient. In other words, the hospital never owns patient data, the hospital only owns the liability for protecting the patient’s data.

We've taken our use case and developed a comprehensive framework for discussion, exploration, and solution development. To summarize, we have:

• Separated 'data production' from 'data ownership'
• Defined our 'data elements’
• Defined our 'datasets'
• Created a superset of 'data pathways' for comprehensive ecosystem participation

Data pathways like the above provide the PET industry broad collaborative opportunities with enterprises, regulators, and solution providers. These collaborations can lead to rapid market solutions and introduce PET innovation across a wide spectrum of industries.

With our data pathways established, we're now ready to explore scalable policy enforcement to ensure patient-data privacy for next generation Smart Health services. This is part three 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.