PrivaSure 2.0 — De-identify clinical data. Preserve what the analysis needs.

PrivaSure 2.0 by

NEW 2.0Dual tokenization and transformation lineage in one workflow

De-identify Clinical Data. Preserve What the Analysis Needs.{{ caret }} Preserve What the Analysis Needs.{{ caret }}

PrivaSure combines identifier removal, risk assessment, dual tokenization, and transformation traceability to prepare authorized healthcare datasets for research and AI development.

{{ pulseDot }}{{ urgencyText }}

Onboarding capacity is limited each quarter. No PHI is needed to start the conversation.

HIPAA Safe Harbor processing
Expert Determination support
Re-identification mapping stays with the data owner

~/requests/RQ-0412/{{ demoFile }}

Identifiers

Context kept

Re-id risk

Transformation lineage{{ lineageCount }}
{{ ln.t }}{{ ln.verb }}{{ ln.what }}

Same token TK-8F2C91 across notes, records and DICOM headers. Mapping stays with the data owner. Sample data is illustrative.

[02]Who we help

Data Access Does Not Mean Data Readiness

A data agreement may be in place while the usable dataset is still weeks of work away. Source exports differ, identifiers appear in more than one field or file, and a transformation that protects privacy can also remove information the analysis requires.

Select your team {{ audHint }}

Team 01 / 06

Clinical AI Companies

Where readiness breaks

Hospital data sits across multiple tables and FHIR resources. Broken patient or encounter joins make feature generation and outcome validation unreliable.

Your sourcesidentifiable

EHR tablesFHIR resourcesEncounter records

PrivaSure 2.0applies

Dual-token linkageStructured transformation

What the dataset keepsanalysis-ready

Patient and encounter joinsFeature generation inputsOutcome labels for validation

Team 02 / 06

Imaging AI Teams

Where readiness breaks

Images, reports, and labels often come from separate systems. De-identification must preserve the relationships needed to match them.

Your sourcesidentifiable

DICOM imagesRadiology reportsLabels

PrivaSure 2.0applies

DICOM de-identificationClinical text redactionStudy tokens

What the dataset keepsanalysis-ready

Image-to-report matchingStudy and series relationshipsLabel links

Team 03 / 06

MedTech & Biotech Teams

Where readiness breaks

Cohorts depend on events and follow-up records over time. Missing records or altered chronology can change the analysis.

Your sourcesidentifiable

Clinical eventsFollow-up records

PrivaSure 2.0applies

Patient tokensRisk assessment

What the dataset keepsanalysis-ready

Cohort membershipEvent chronologyFollow-up continuity

Team 04 / 06

CROs & Research Partners

Where readiness breaks

Sites deliver different schemas, codes, and levels of completeness. Each dataset needs reconciliation against the agreed study specification.

Your sourcesidentifiable

Site A exportSite B exportSite C export

PrivaSure 2.0applies

Configured rules per siteTransformation lineage

What the dataset keepsanalysis-ready

Agreed study specificationComparable site datasets

Team 05 / 06

Hospital Data Teams

Where readiness breaks

Requests draw on EHRs, PACS, laboratory systems, and documents. Extracting, reconciling, and checking them takes specialist time.

Your sourcesidentifiable

EHRPACSLaboratoryDocuments

PrivaSure 2.0applies

One workflow across data typesRepeatable configuration

What the dataset keepsanalysis-ready

Checked outputProcessing historyFaster repeat extracts

Team 06 / 06

Privacy & Governance Teams

Where readiness breaks

Detailed records can remain identifiable after direct identifiers are removed. Reviewers need risk evidence and control over linkage mappings.

Your sourcesidentifiable

Detailed recordsLinkage mappings

PrivaSure 2.0applies

Re-identification risk assessmentDual-token architecture

What the dataset keepsanalysis-ready

Risk evidence for reviewMapping kept by data ownerRecord of what changed

[03]PrivaSure capabilities

One De-identification Workflow Across Clinical Data Types

Hover or tap a card to run it

18 categories{{ shStat }}

01Method

Safe Harbor Processing

Supports detection and removal of the identifier categories specified under the HIPAA Safe Harbor method. Teams can inspect the processed output and exceptions before using it.

threshold

risk by record class{{ edStat }}

02Method

Expert Determination Support

Produces statistical risk analysis and documentation for review by an appropriately qualified expert. The expert’s determination remains a separate professional decision.

clinical NLP{{ ctStat }}

03Text

Clinical Text De-Identification

Uses clinical NLP to identify and redact patient information in narrative content such as notes, discharge summaries, and reports.

{{ r.k }}{{ r.v }}{{ r.act }}

extract.csv{{ stStat }}

04Tabular

Structured Data Transformation

Applies configured rules to fields in clinical records and extracts, with checks against the required output schema and analytical variables.

{{ r.k }}{{ r.v }}{{ r.act }}

series_3.dcm{{ dcStat }}

05Imaging

DICOM De-Identification

Supports imaging data preparation. The resulting files and retained metadata should be validated against the specific study or model requirements.

Identity

MRN 00482917

token

Analytical data

{{ dtRight }}

Mapping held by the data owner

controlled linkage{{ dtStat }}

06Linkage

Dual-Token Architecture

Separates patient identity from the analytical data while supporting controlled record linkage. The re-identification mapping remains with the data owner.

Re-id risk

per recipient{{ rkStat }}

07Risk

Re-Identification Risk Assessment

Documents risk for the processed dataset so it can be reviewed in the context of its intended recipient and use.

+0.00sLOADnote_0412.txt
+0.42sREMOVEpatient_name
+0.84sTOKENIZEmrn → TK-8F2C91
+1.26sRETAINfinding
+1.68sLOGGEDrun_0412 · repeatable

08Audit

Transformation Lineage

Logs processing steps so teams can trace how an output was produced, investigate exceptions, and repeat an agreed preparation process.

[04]How the workflow is defined

Start With the Output Contract, Then Configure the Transformations

A de-identification run should begin with a specification of what the recipient needs to do with the data. That specification determines which transformations are acceptable and what the finished output must be able to support.

~/requests/RQ-0412/workflowselect a step to inspect

Step 01·{{ wfStepState }}

Define the dataset

Identify the source systems, cohort logic, file types, required fields, refresh frequency, recipient, and permitted purpose. Specify whether the project needs patient-level continuity, encounter-level linkage, or independent records.

Step 02·{{ wfStepState }}

Map identifiers and dependencies

Locate direct identifiers and potentially identifying combinations of fields. Map relationships between structured records, narratives, images, and reports before changing values that connect them.

Step 03·{{ wfStepState }}

Select and configure the method

Apply the agreed Safe Harbor, risk-based, tokenization, and project-specific rules. Where Expert Determination is used, provide the analysis and documentation for qualified expert review.

Step 04·{{ wfStepState }}

Run privacy and utility checks

Inspect residual identifiers and exceptions. Then test the output against its intended use: record counts, joins, chronology, required variables, file validity, and retained imaging or clinical context.

Step 05·{{ wfStepState }}

Document and review

Provide the transformed dataset, risk assessment, and processing history to the data owner’s designated reviewers. The owner decides whether the output can be released under the applicable permissions and agreements.

Output contract artifacts{{ wfArtCount }}

Dataset specification {{ wfArtSt0 }}

Identifier and dependency map {{ wfArtSt1 }}

Method configuration {{ wfArtSt2 }}

Privacy and utility report {{ wfArtSt3 }}

Release package for review {{ wfArtSt4 }}

✓ Package delivered. The release decision stays with the data owner.

[05]Business value

Reduce the Work Between Data Access and Data Use

An approved data request can still take weeks of extraction, custom scripts, identifier checks, broken joins, and privacy review before the dataset is usable. Each revision consumes engineering and governance time that could be spent on development and validation.

From approved request to accepted datasetTime →

After approval, todayManual, rebuilt for every delivery

↺ Each revision restarts the cycle

ExtractionEvery source, every refresh Custom scriptsWritten per request Identifier checksField by field, file by file Broken joinsFound after transformation Privacy reviewRepeated for each revision Usable dataset

With PrivaSureOne repeatable preparation workflow

Configure & runTo the dataset spec CheckPrivacy and utility ReviewRisk evidence and lineage Accepted dataset Time returned to development and validationRepeat extracts run against the established specification

PrivaSure brings de-identification, risk assessment, controlled linkage, and transformation records into a repeatable preparation workflow.

Less Manual Rework

Apply configured transformations and check the output against the dataset specification.

More Useful Data

Preserve the approved record relationships and clinical context needed for analysis.

Clearer Privacy Review

Give reviewers the risk assessment and a record of what changed.

Easier Repeat Extracts

Prepare updated datasets against an established specification instead of rebuilding the process for every delivery.

Measure the value

Compare staff hours, review cycles, and time to an accepted dataset before and after implementation.

[06]Technical evaluation

Validate Privacy and Analytical Utility on the Same Dataset

Test PrivaSure on an authorized sample that reflects your production data. Agree on the output schema, permitted linkage, de-identification method, and acceptance thresholds before processing.

Agreed before processing · tap to confirm {{ agreedLabel }}

✓ All four agreed — you’re ready to scope an evaluation.

PrivacyUtility

Clinical Text

Measure residual PHI and false redactions across note types. Check that findings, negation, and other information required for analysis remain interpretable.

Utility

Structured and Longitudinal Data

Compare row counts, null rates, join cardinality, event order, cohort membership, and label availability before and after transformation.

UtilityPrivacy

Imaging

Confirm that processed DICOM files load in the intended pipeline. Test study and series relationships, report-to-image matching, required metadata, and residual identifiers.

Governance

Risk and Controls

Review the risk analysis, transformation logs, token-map custody, and access boundaries against the proposed recipient and use.

[07]Case studies

Clinical Data Workflows in Practice

Explore how PrivaSure is applied to specific data requests: the source formats, de-identification approach, linkage requirements, validation checks, and review process behind each delivered dataset.

Case Study 01 · Academic medical center · Research data office

Clinical data preparation for research

EHR tablesClinical notesExpert DeterminationPatient tokens

01Challenge: An oncology outcomes study needed encounters, labs, medications, and clinical notes for roughly 18,000 patients, delivered to an external university partner every quarter. Each refresh relied on custom SQL, manual note review, and repeated rounds with the privacy office.
02Data and methods: Structured EHR extracts and 240,000 narrative notes. Clinical NLP redaction on notes, configured transformations on structured fields, and per-patient date shifting to keep treatment intervals intact. Statistical risk analysis and documentation were prepared for the qualified expert’s determination.
03Validation: Residual PHI and false redactions measured on a stratified sample of 2,000 notes. Row counts, join cardinality, and diagnosis-to-treatment intervals compared against the source before release.

04Measured result

8 daysTime to accepted datasetFrom about 6 weeks per refresh

1Privacy review cycleDown from 3 per refresh

−65%Staff hours per refreshAgainst the two prior refreshes

Released by the data owner’s designated reviewers under the existing data use agreement.

Case Study 02 · Clinical AI company · Inpatient deterioration model

Longitudinal dataset preparation for clinical AI

FHIR R4Two hospital sitesDual tokensDate shifting

01Challenge: Training an inpatient deterioration model required five years of encounters from two hospital partners. A previous de-identification pass had broken encounter joins and shuffled event order, so outcome labels no longer lined up with vital signs.
02Linkage design: Patient and encounter tokens generated separately at each site, with each hospital keeping its own re-identification mapping. Per-patient date shifting preserved event order and the intervals between observations, medications, and outcomes.
03Utility checks: Join cardinality between encounters and observations matched the source. Event order, cohort membership, and label availability were compared before and after transformation for both sites.

04Measured result

100%Encounter joins preservedPrior pass: 81%

9 daysTime to accepted datasetFrom about 5 weeks

QuarterlyRepeat extractsRun against the same specification

Token maps remain with each hospital. Release approved by both sites’ governance reviewers.

Case Study 03 · Imaging AI developer · Chest CT

DICOM and associated report preparation

DICOM CTRadiology reportsUID remappingStudy tokens

01Challenge: A chest CT model needed 42,000 studies and their radiology reports for training and external validation. Identifiers sat in standard and private DICOM tags, some images carried burned-in text, and every report had to stay matched to the right study.
02Imaging workflow: Header de-identification against an agreed tag profile, private tag removal, and consistent UID remapping across studies and series. Burned-in text was detected and routed for human review; reports were redacted with clinical NLP and linked to images through a study token.
03Metadata checks: Processed files were loaded in the team’s training pipeline. Study and series relationships, report-to-image matches, and required acquisition metadata such as slice thickness, kernel, and manufacturer were checked, along with a residual identifier scan.

04Measured result

99.6%Studies loaded on first runIn the team’s training pipeline

100%Report-to-image matchesAcross retained studies

312Studies flagged for reviewBurned-in text sent to human review

Delivered dataset and processing history reviewed by the data owner before release.

[08]Blogs & insights

From the Clinical Data Engineering Desk

Technical perspectives on preparing healthcare data for research and AI development, covering de-identification, data utility, interoperability, and governance.

De-identification Can Break a Longitudinal Dataset

How identifier removal affects joins, encounter sequences, cohort refreshes, and follow-up analysis.

Longitudinal data

What to Validate After DICOM De-identification

File integrity, study relationships, acquisition details, and the link between images and clinical context.

Imaging

Safe Harbor, Expert Determination, and Tokenization Solve Different Problems

Where each fits in a data preparation workflow, and which decisions still require human review.

Methods

[09]Next step

De-identify Clinical Data. Preserve What the Analysis Needs.{{ caret }} Preserve What the Analysis Needs.{{ caret }}

Data Access Does Not Mean Data Readiness

Clinical AI Companies

Imaging AI Teams

MedTech & Biotech Teams

CROs & Research Partners

Hospital Data Teams

Privacy & Governance Teams

One De-identification Workflow Across Clinical Data Types

Safe Harbor Processing

Expert Determination Support

Clinical Text De-Identification

Structured Data Transformation

DICOM De-Identification

Dual-Token Architecture

Re-Identification Risk Assessment

Transformation Lineage

Start With the Output Contract, Then Configure the Transformations

Define the dataset

Map identifiers and dependencies

Select and configure the method

Run privacy and utility checks

Document and review

Reduce the Work Between Data Access and Data Use

Less Manual Rework

More Useful Data

Clearer Privacy Review

Easier Repeat Extracts

Validate Privacy and Analytical Utility on the Same Dataset

Clinical Text

Structured and Longitudinal Data

Imaging

Risk and Controls

Clinical Data Workflows in Practice

From the Clinical Data Engineering Desk

De-identification Can Break a Longitudinal Dataset

What to Validate After DICOM De-identification

Safe Harbor, Expert Determination, and Tokenization Solve Different Problems

Your data agreement is in place.Now make the dataset ready.