SafeShare: Real-Time Anonymization
- SafeShare is an online medical consultation technique that uses localized LLM to detect and selectively redact sensitive personal information in real time.
- The system integrates a dual-module workflow with a real-time anonymization component and a contextual justification module to preserve diagnostic content while reducing privacy labor.
- Empirical evaluations reveal a privacy–utility trade-off with notable anonymization accuracy and appropriateness, highlighting challenges in balancing effective data redaction with clinical relevance.
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 (Zhang et al., 1 Aug 2025). 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 ; interviews were conducted via Tencent Meeting, recorded with consent, transcribed, and analyzed using thematic analysis (Zhang et al., 1 Aug 2025). 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 (Zhang et al., 1 Aug 2025).
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 (Zhang et al., 1 Aug 2025).
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 (Zhang et al., 1 Aug 2025). 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 (Zhang et al., 1 Aug 2025).
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 (Zhang et al., 1 Aug 2025).
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.” (Zhang et al., 1 Aug 2025)
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 (Zhang et al., 1 Aug 2025). 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 (Zhang et al., 1 Aug 2025). 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” (Zhang et al., 1 Aug 2025). 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 (Zhang et al., 1 Aug 2025). 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 (Zhang et al., 1 Aug 2025). 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 (Zhang et al., 1 Aug 2025). To partially validate the LLM-as-judge setup, one experimenter manually coded 50 records, and agreement with the LLM judge yielded Cohen’s Kappa .
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 (Zhang et al., 1 Aug 2025). 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 (Zhang et al., 1 Aug 2025).
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 (Zhang et al., 1 Aug 2025).
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 (Zhang et al., 1 Aug 2025).
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 (Zhang et al., 1 Aug 2025). 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 (Wilson et al., 2014). 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 (Carpenter et al., 2023) | sharing-oriented DCFS using basic HTTP, linked data concepts, and automatic redaction systems | read-only sharing and integrated redaction |
| TwinCloud (Bicakci et al., 2016) | store encrypted files and keys in separate clouds | non-colluding providers and hidden key exchange |
| OmniShare (Paverd et al., 2015) | OOB-authenticated device onboarding and directory-based key hierarchy | high-entropy client-side keys across multiple devices |
| Protbox (Duarte et al., 2015) | eID-signed cloud-mediated key exchange over shared folders | strong identification, integrity checking, and deletion recovery |
| Bifrost (Sehat et al., 2022) | dual deduplication with a short secret over secure P2P | fixed-size secret transfer and cloud-side compression |
| A-SKY (Contiu et al., 2019) | TEE-assisted key enveloping for cloud file sharing | confidentiality plus sender/recipient anonymity |
| TIPS (Pasumarthy et al., 2024) | 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 (Zhang et al., 1 Aug 2025). The surrounding literature shows that this answer is important, but only one component of a larger secure-sharing stack.
