PHI De-Identification and Secure Health Data Sharing Modules

Summary

We build de-identification and secure sharing modules that sit alongside health information exchange platforms. The exchange moves patient records between care providers in real time; research, population health analytics and quality reporting need the same clinical content without the identities attached. This kind of module produces that second stream: an authorised user defines what data to pull, from which source, with which identifiers removed, and where the result is sent. It is a controlled export pipeline with a transformation stage.

The Challenge

Correctness here is a compliance matter rather than a feature preference, and the dangerous fields are rarely the obvious ones. Free-text clinical notes carry names, employers, relatives and locations inside prose, so a module that masks structured columns and passes notes through unchanged has not de-identified anything. Quasi-identifiers combine: a rare diagnosis with an admission date and a partial postcode can single out an individual even when every explicit identifier is gone. Date shifting that is not consistent per patient destroys clinical intervals. Users routinely assume that masked means anonymous. Regional data protection law and consent conditions may restrict purpose and cross-border transfer beyond what any national rule requires.

The Solution

Choosing a de-identification route

Safe harbour removal enumerates the identifier categories that must go: names, geographic subdivisions below state level, date elements for an individual more precise than the annual level, contact details, account and record numbers, biometric identifiers and full-face images. Expert determination instead lets a statistician certify that re-identification risk is very small, retaining more analytical value at the cost of formal assessment. Between full anonymisation and raw data sits pseudonymisation, where identifiers are replaced by a consistent surrogate key so records stay linkable, with the mapping held separately under stricter control. That mapping is the whole risk of the approach and is treated as a secret with its own access policy.

Core components

• Query builder - selection of source system, cohort filters, target fields and destination, expressed in a form clinical staff can use without writing queries.
• Transformation rules - per-field policy covering suppression, generalisation such as date shifting or age banding, hashing with a secret salt, tokenisation and encryption.
• Reusable templates - saved combinations of source, filters and masking rules assignable to other authorised users, so recurring requests execute identically.
• Delivery - transfer to the approved destination over authenticated, encrypted channels, with the output recorded and retrievable for audit.
• Audit trail - an immutable record of who requested what, which rules were applied, and where the result went.

Free text and small cells

Free text passes a scrubbing stage with human review sampling rather than a pattern match alone, and small cell suppression and generalisation address the combinations that structured masking misses. Date shifting is applied consistently per patient so clinical intervals survive.

Fitting the host platform

The module inherits identity, roles and entitlements from the exchange platform rather than maintaining a second user directory, because a security model it competes with is one it will eventually contradict. Extraction sits behind a source adapter interface rather than one database dialect, so non-relational sources can be added later. Verification is explicit: test datasets seeded with known identifiers, automated checks that no seeded value survives an export, and review of sampled free-text output. Who may define rules is restricted separately from who may run them, a template cannot be edited silently after assignment, and the rule set version applied to every extract is logged so an output can be reproduced later.

What This Delivers

Research and analytics teams receive clinical content they are permitted to hold, through a route that is documented rather than improvised. Recurring requests run identically each time, because the rules live in an assigned template instead of an analyst's memory. Every export can be reconstructed afterwards: which rules were applied, by whom, and where the output went. And because reversible and irreversible transformations are distinguished in the interface, users can tell a surrogate key from true anonymisation.

Technologies and Tools

A .NET back end reads from source relational databases behind a source adapter layer that admits non-relational systems later, inheriting identity, roles and entitlements from the host exchange platform. The transformation layer covers suppression, generalisation, date shifting, age banding, salted hashing, tokenisation and encryption, with delivery over authenticated, encrypted channels and an immutable audit store. The module is security-critical software with its own threat model, since it is by design the one component authorised to read broadly and write outward.