A hospital with one patient
Empowering patients with data safety
Part 4 of 5
This is part IV of our blog series, 'A hospital with one patient'. In parts I, II, and III we proposed a use case, a hospital with one patient, and defined important terms like 'Data', 'Pathways' and 'Privacy'. We also defined a Smart Health ecosystem with service providers.
The challenge we set ourselves was to define a use case to help us bound the privacy spectrum for data protection. We've created a set of logical axioms to establish a framework for solution exploration. The final element we need to establish is a mechanism for privacy itself.
Anonymization is the act of removing identifiable particulars from data prior to sharing or processing or analysis. In Part IV of our series we will explore how different types of anonymization can be used by the hospital to participate in a Smart Health ecosystem.
There are many types of anonymization, each nuanced for specific privacy scenarios. To keep this use case simple, we will stick to the following three:
- No-Anonymization
- Full-Anonymization
- Pseudo-Anonymization
We have previously identified a 'data element', which includes a 'value' and a 'description of that value'. (See Fig.IV.1) Anonymization policy must be concentrated at the data-element layer for flexible ecosystem participation.
Fig. IV.1
Let's imagine that the hospital's single patient, John Doe, came in with a hand injury. The hospital staff provides John Doe with care, which includes blood sample collection and taking an X-Ray of the patient's hand.
The resulting data produced during John Doe's visit can be summarized as follows:
- Patient-Name: John Doe, via 'data-entry'
- Patient-Address: 123 Main St. via 'data-entry'
- Hospital-Name: St. Mary's via 'data-entry'
- X-Ray: image001.jpg via 'instrument'
- Blood-sample: {sample-data} via 'data-entry'
All the 'data elements' were created through 'data entry' except for the X-Ray, which was created through an X-Ray machine.
This data, which all belongs to the patient, needs to be accessed by the Hospital staff to provide health care to John Doe.
The first type of anonymization we define is 'No-Anonymization', which we define simply as removing NONE of the identifiable particulars from a 'data element'. (See Fig. IV.2)
Fig. IV.2
Data pathways 1 - 5 allow the hospital staff the necessary access they need to provide care for John Doe. Granular policy control and auditable transparency become available become through the establishment of these pathways.
The next type of anonymization is 'Full-Anonymization', which we define simply as removing ALL the identifiable particulars from a 'data element'.
X-Ray Service Ltd. requires the X-Ray image to do their analysis. They also require the name of the hospital requesting the X-Ray analysis. (See Fig. IV.3)
Fig. IV.3
Data pathways 6 - 10 allow X-Ray Service Ltd. to analyze John Doe's X-Ray without having access to any PII.
Blood Works Ltd. offers two different types of Smart Health services:
- Blood-work analysis for a given sample
- Historical and trend-based blood-work analysis for individual patients
Historical analysis provides our patient, John Doe, more comprehensive health care. Analyzing the patterns of change enables next-generation preventive, predictive and diagnostic care for John Doe.
The challenge, of course, is how does the hospital share the necessary information to Blood Works Ltd. without exposing John Doe's PII?
Here we introduce 'Pseudo-Anonymization', which we define as replacing the patient's PII with an artificial identifier. In the case of our patient John Doe, we will replace his name with an artificial-id. This artificial-id will be unique and consistent for our patient.
This artificial-id allows Blood Works Ltd. to associate every instance of John Doe's blood-work historically with a single patient, without ever being able to reverse engineer the artificial-id and identify John Doe directly. (See Fig. IV.4)
Fig. IV.4
Data pathways 11 - 15 allow X-Ray Service Ltd. to analyze John Doe's blood work without having access to any PII.
Not all of John Doe's data elements must be shared with all parties. Defining clear 'data pathways' per element granular policy enforcement as well auditable traceability. (See Fig.IV.5)
Fig. IV.5
We have begun to understand how patient data can be safely introduced into a data ecosystem, even for extreme use case like a 'hospital with one patient'.
This is only the beginning of our journey. By orienting ourselves around a common use case, and by defining a common set of terms and concepts in agreement with enterprises and regulators and vendors, we can all collectively move the PET industry forward.
We hope these articles have been informative so far, and we hope you'll join us for the final article in this series, where we'll discuss solution requirements and the broad categories of questions we need to solve as an industry.