---
title: 'SafeShare: Real-Time Anonymization'
url: https://www.emergentmind.com/topics/safeshare
type: topic
---

# SafeShare: Real-Time Anonymization

SafeShare is an interaction technique for online medical consultation platforms that leverages localized LLM to redact consultations in real time, with the stated aim of balancing utility and privacy through selective anonymization of private information before transmission [2508.00328]. Its immediate target is the mismatch between patients’ desire for anonymity and control and platform designs that place the burden of disclosure management on users themselves. In that framing, SafeShare is not merely a medical named-entity recognizer; it is a pre-transmission privacy layer embedded in the consultation workflow, intended to reduce “privacy labor” while preserving diagnostically necessary content.

## 1. Problem context and user-centered motivation

The motivating problem is the privacy structure of online medical consultation rather than the generic sensitivity of health data. The interview study reported for SafeShare involved 12 participants, with 5 male and 7 female participants, a mean age of 22.2, and \(SD = 3.6\); interviews were conducted via Tencent Meeting, recorded with consent, transcribed, and analyzed using thematic analysis [2508.00328]. The study identifies three main perceived privacy risks: platform-level data exploitation, unauthorized disclosure by individual practitioners, and distrust driven by platform profit motives and data-display practices. A recurring concern is identity linkage: participants were often willing to disclose symptom descriptions, photos, and medical history, but were reluctant to disclose names, national ID numbers, phone numbers, and related identifiers.

The reported usage contexts are also specific. Participants described online consultation as attractive in low-stakes triage and prescription-access scenarios, but they performed a privacy calculus when deciding what to disclose. Anonymity was especially valued for stigmatized conditions such as HPV or HIV. This yielded a distinction between diagnostically necessary medical information and personally identifiable information, with the latter treated as a category that users strongly resist sharing unless forced by workflow or regulation [2508.00328].

The paper also reports substantial user-initiated mitigation: pseudonyms, approximate ages, describing the patient as a “friend” or “relative,” cropping image backgrounds, blurring names and ID numbers on reports, and preferring trusted platforms such as official hospital apps. These practices were described as burdensome, only partly effective, and unsustainable over time, leading to privacy fatigue. The resulting design requirements were explicit: granular control over what gets shared, data ephemerality or a right to be forgotten, transparency and accountability, and support that reduces manual privacy labor rather than merely warning about it [2508.00328].

## 2. System architecture and interaction workflow

SafeShare is presented as an intelligent intermediary within the consultation interface. The paper describes two major modules: a real-time anonymization module and an in-context justification module [2508.00328]. At the architectural level, the system “acts as a bridge between users and cloud service, anonymizing medical private information,” which locates it at the disclosure boundary rather than at the storage backend.

The workflow described in the paper is sequential. A user composes a consultation message and may attach images or reports. SafeShare analyzes the input locally in real time, detects candidate PII, and uses the justification module to examine context and intent via the user’s query history. On that basis, it determines which sensitive entities should be anonymized and generates an “optimal anonymization list.” The input is then selectively anonymized, the output is parsed and replaces the users’ original input locally, and the anonymized content is presented for one-click approval before transmission [2508.00328].

This design makes user approval part of the privacy mechanism rather than an afterthought. The justification module is conceptually important because the system is not intended to redact every sensitive string indiscriminately. Instead, it attempts to decide which entities are unnecessary for the consultation’s diagnostic or informational purpose. The paper does not provide a formal algorithm for this module, but its stated role is to support real-time, context-aware decisions about what should remain visible and what should be abstracted away [2508.00328].

A representative example in the paper illustrates the system’s semantics. The original input is:

> “I am worried about the test results for my daughter Jane Doe from her appointment on May 20, 2025, with Dr. Smith at Peking University Hospital. We can be reached at 138-0000-0000 if needed.”

The anonymized output is:

> “I am worried about the test results for my daughter [PATIENT] from her appointment on May [DATE], 2025, with [DOCTOR] at [HOSPITAL]. We can be reached at [PHONE] if needed.” [2508.00328]

The example is notable because it shows selective abstraction rather than total deletion: role information is retained, some temporal structure remains, and the diagnostic narrative is preserved.

## 3. Anonymization method and localized LLM pipeline

The technical core is an LLM-based PII detection and anonymization pipeline operating in a zero-shot setting. The paper states that the targeted anonymization categories include name, email, phone number, ID, online identity, geolocation, affiliation, demographic attributes, time, financial information, and educational records [2508.00328]. The model is prompted to identify “textual instances of sensitive entities whose sensitivity overweigh utility” from medical dialogue.

The prompting strategy has three stated components. First, the model receives a role instruction framing it as a professional medical and privacy expert specializing in NER. Second, the task definition emphasizes extraction of sensitive entities while preserving clinically relevant information. Third, the output must conform to a strict JSON schema, with keys as entity categories and values as lists of exact textual spans, enabling automated post-processing [2508.00328]. The appendix also notes the inclusion of a one-shot example and explicit machine-readable formatting guidance.

Localized deployment is central to the design rationale. The paper states that local processing was chosen because it “could potentially understand the task, ensuring both privacy and utility,” and because “ensuring localized processing could minimize the data uploading, thereby protecting privacy and mitigating privacy risks” [2508.00328]. Model selection was therefore restricted to smaller-than-8B models for evaluating on-device anonymization performance.

The evaluated models were DeepSeek-R1-7B, GPT-4o-mini, Qwen3-1.7B, Qwen3-4B, and Qwen3-8B [2508.00328]. The system’s conceptual pipeline is broader than text-only processing—the paper states that SafeShare can detect PII in both text and images—but the quantitative evaluation reported in the paper covers only text.

## 4. Empirical evaluation

The evaluation focuses on the core anonymization module and uses three online-consultation-related datasets: IMCS21 with 4,116 samples, 10 diseases, and 164,731 utterances; MedDG with 17,864 Chinese dialogues and 385,951 utterances; and ReMeDi with 96,965 conversations, 843 disease types, and 1,557 conversations with fine-grained labels [2508.00328]. The evaluation protocol is zero-shot across all models.

Two metrics are reported. “Anonymization accuracy” measures how correctly sensitive information is identified for redaction. “Anonymization appropriateness” measures whether the anonymized text retains sufficient information for meaningful diagnosis. Both metrics were assessed using qwen-max as an evaluator: once as a privacy expert validating extracted PII, and once as a physician scoring the diagnostic adequacy of the anonymized dialogue [2508.00328]. To partially validate the LLM-as-judge setup, one experimenter manually coded 50 records, and agreement with the LLM judge yielded Cohen’s Kappa \(= 0.81\).

The main quantitative pattern is a privacy–utility trade-off.

| Metric | Best reported model | Reported values |
|---|---|---|
| Anonymization accuracy | Qwen3-4B | 89.64% IMCS21; 84.86% MedDG; 82.41% ReMeDi |
| Anonymization appropriateness | Qwen3-1.7B | 92.40 IMCS21; 87.97 MedDG; 95.28 ReMeDi |

The paper highlights the 89.64% anonymization accuracy achieved by Qwen3-4B on IMCS21 [2508.00328]. The tabulated results also show that Qwen3-8B reaches 87.04% on MedDG, which suggests that scaling is not monotonic across datasets and that model size alone does not determine performance. More importantly, the best appropriateness scores come from Qwen3-1.7B rather than Qwen3-4B, making the privacy–utility tension empirically visible rather than merely conceptual.

In practical terms, the results indicate that stronger PII detection is not equivalent to better consultation support. Aggressive anonymization can reduce identity exposure while also removing information that remains relevant to diagnosis. SafeShare’s evaluation therefore supports feasibility, but it does not support a claim that there is a single uniformly optimal model across both objectives [2508.00328].

## 5. Security properties, limitations, and misconceptions

SafeShare’s privacy model is pre-transmission and disclosure-minimizing. Its strongest explicit claim is not end-to-end confidentiality of the whole consultation stack, but localized real-time protection support at the moment of disclosure. The local LLM architecture is intended to minimize data uploading during the protection step itself, and the interaction model keeps the user in the loop through one-click approval [2508.00328].

Several limitations are explicit. The evaluation focuses mainly on the anonymization module rather than the full interactive system; the justification module is conceptually described but not equivalently evaluated. Image handling is mentioned but not quantitatively tested. The paper reports no latency or on-device runtime numbers, despite describing the system as real-time and localized. The interview sample is small and concentrated in a young adult cohort. Finally, the quantitative evaluation depends on an LLM-as-judge protocol rather than comprehensive physician annotation [2508.00328].

The framing also leaves open several failure modes. A plausible implication is the risk of false negatives that miss PII, false positives that over-redact diagnostically relevant content, context errors in relevance estimation, partial anonymization mismatch, and trust overreliance by users who may stop scrutinizing outputs once a protection layer is present [2508.00328]. These are especially salient in medicine, where apparently peripheral identifiers can carry clinically relevant context.

A common misconception is that privacy-preserving consultation is exhausted by transport encryption or “encrypted before upload” claims. Broader secure-sharing work shows that client-side encryption can protect stored, non-shared files, yet confidentiality may fail during sharing if the provider controls certificate issuance and validation for recipient public keys [1404.2697]. This suggests that SafeShare addresses one specific layer of the problem—content minimization before disclosure—rather than the full end-to-end problem of recipient authentication, storage confidentiality, revocation, or provider-readable sharing paths.

## 6. Relation to the secure-sharing literature

SafeShare belongs to a broader design space in which different systems solve different parts of secure sharing: redaction, split trust, client-side key distribution, anonymous dissemination, and permissioned trust channels.

| System | Primary mechanism | Main trust focus |
|---|---|---|
| CageCoach [2301.04214] | sharing-oriented DCFS using basic HTTP, linked data concepts, and automatic redaction systems | read-only sharing and integrated redaction |
| TwinCloud [1606.04705] | store encrypted files and keys in separate clouds | non-colluding providers and hidden key exchange |
| OmniShare [1511.02119] | OOB-authenticated device onboarding and directory-based key hierarchy | high-entropy client-side keys across multiple devices |
| Protbox [1501.03139] | eID-signed cloud-mediated key exchange over shared folders | strong identification, integrity checking, and deletion recovery |
| Bifrost [2201.10839] | dual deduplication with a short secret over secure P2P | fixed-size secret transfer and cloud-side compression |
| A-SKY [1907.06466] | TEE-assisted key enveloping for cloud file sharing | confidentiality plus sender/recipient anonymity |
| TIPS [2403.05210] | permissioned ledger with hybrid encryption, ABE, HE, and ZKP | trusted channels, auditability, and policy-rich access |

Relative to these systems, SafeShare is unusual because it does not begin from ciphertext storage or recipient key distribution. Its principal intervention is earlier in the pipeline: it attempts to reduce the sensitivity of what is ever sent. That makes it closer in spirit to redaction-capable systems such as CageCoach than to split-trust or multi-device storage systems, even though the underlying secure-sharing literature supplies complementary lessons about key authenticity, access governance, and lifecycle controls.

This broader comparison also clarifies what SafeShare does not currently try to do. It does not provide TwinCloud-style split trust across providers, OmniShare-style device-domain key management, Protbox-style eID-mediated access control, Bifrost-style tiny secret-channel sharing, A-SKY-style anonymous reader/writer sets, or TIPS-style permissioned-ledger auditability. A plausible synthesis is that SafeShare occupies the “selective disclosure” end of the secure-sharing spectrum: it is strongest when the main problem is pre-disclosure identity leakage in a consultation interface, and weaker when the dominant problem is post-upload governance, recipient authentication, or revocation.

In that sense, SafeShare contributes a specific answer to a specific question: how to shift privacy protection from burdensome manual self-sanitization toward localized, real-time, context-sensitive anonymization in online medical consultations [2508.00328]. The surrounding literature shows that this answer is important, but only one component of a larger secure-sharing stack.

Source: https://www.emergentmind.com/topics/safeshare