Back to Details

digital-health-compliance-planning

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- This source file is part of the Stanford Spezi open-source project. SPDX-FileCopyrightText: 2026 Stanford University and the project authors (see CONTRIBUTORS.md) SPDX-License-Identifier: MIT -->
<!-- This source file is part of the Stanford Spezi open-source project. SPDX-FileCopyrightText: 2026 Stanford University and the project authors (see CONTRIBUTORS.md) SPDX-License-Identifier: MIT -->

Compliance Planner

合规规划手册

Plan privacy, research, regulatory, and governance requirements for a digital health product in a framework-agnostic way.
以框架无关的方式规划数字健康产品的隐私、研究、监管及治理要求。

When to Use

适用场景

Use this skill when you need to:
  • assess whether a product handles regulated health or research data
  • prepare for HIPAA, IRB, FDA, GDPR, or institutional review conversations
  • define consent, retention, export, deletion, and audit expectations
  • identify compliance work that should shape product scope early
在以下场景中使用本指南：
  • 评估产品是否处理受监管的健康或研究数据
  • 为HIPAA、IRB、FDA、GDPR相关沟通或机构审查做准备
  • 定义知情同意、数据留存、导出、删除及审计的预期要求
  • 尽早识别应影响产品范围的合规工作

Working Style

工作流程

Do not jump straight to controls. First understand:
  1. product purpose
  2. who the users are
  3. whether the product is clinical care, research, wellness, operations, or education
  4. what data is collected, derived, shared, or exported
  5. which regions, institutions, and partners are involved
Then produce a concise compliance planning brief with assumptions, risks, open questions, and recommended next steps.
不要直接跳到控制措施。首先需明确：
  1. 产品用途
  2. 用户群体
  3. 产品属于临床护理、研究、健康管理、运营还是教育类
  4. 收集、衍生、共享或导出的数据类型
  5. 涉及的地区、机构及合作伙伴
随后生成一份简洁的合规规划简报，包含假设、风险、待解决问题及建议的后续步骤。

Core Questions

核心问题

Ask about:
  • intended use and claims
  • user groups such as patients, participants, clinicians, coordinators, or caregivers
  • data types collected, inferred, uploaded, or connected from external systems
  • whether the product supports research, quality improvement, or direct care
  • data storage, processing, and sharing locations
  • third-party vendors and subprocessors
  • admin access, audit needs, and incident response expectations
  • export, deletion, correction, and retention requirements
需询问以下问题：
  • 预期用途及声明
  • 用户群体，如患者、研究参与者、临床医生、协调员或护理人员
  • 收集、推断、上传或从外部系统接入的数据类型
  • 产品是否支持研究、质量改进或直接护理
  • 数据存储、处理及共享的地点
  • 第三方供应商及分包商
  • 管理员权限、审计需求及事件响应预期
  • 数据导出、删除、更正及留存要求

Compliance Areas To Review

需审查的合规领域

HIPAA and Institutional Privacy

HIPAA与机构隐私

Check whether the product likely handles protected health information or institution-controlled data.
Review:
  • what identifiers are present
  • who is a covered entity or business associate
  • minimum necessary access expectations
  • workforce, admin, and support access boundaries
  • logging, monitoring, and breach response needs
检查产品是否可能处理受保护的健康信息或机构控制的数据。
审查内容：
  • 存在哪些标识符
  • 谁是受保实体或业务关联方
  • 最小必要访问权限的预期
  • 员工、管理员及支持人员的权限边界
  • 日志记录、监控及数据泄露响应需求

Research and IRB

研究与IRB

If the product supports a study, review:
  • study purpose and protocol maturity
  • recruitment and consent approach
  • risk level and participant burden
  • withdrawal process
  • de-identification or anonymization approach
  • data sharing and secondary use plans
若产品支持研究项目，需审查：
  • 研究目的及方案成熟度
  • 招募及知情同意方式
  • 风险等级及参与者负担
  • 退出流程
  • 去标识化或匿名化方式
  • 数据共享及二次使用计划

FDA and Product Claims

FDA与产品声明

Evaluate whether the product may be treated as software with medical-device implications.
Ask:
  • does it diagnose, recommend treatment, monitor for intervention, or drive clinical action
  • are outputs informational, advisory, or action-triggering
  • what happens if the product is wrong, unavailable, or delayed
评估产品是否可能被视为具有医疗设备属性的软件。
需询问：
  • 产品是否用于诊断、推荐治疗、监测干预需求或驱动临床行动
  • 输出内容是信息性、建议性还是触发行动的
  • 若产品出现错误、不可用或延迟会产生何种影响

GDPR and Cross-Border Privacy

GDPR与跨境隐私

If EU or UK users may be involved, review:
  • lawful basis
  • consent and withdrawal mechanics
  • subject rights handling
  • transfer mechanisms
  • retention, deletion, and processing-record expectations
若涉及欧盟或英国用户，需审查：
  • 合法依据
  • 知情同意及撤回机制
  • 主体权利处理方式
  • 数据传输机制
  • 数据留存、删除及处理记录的预期

Planning Outputs

规划产出

Produce a brief with these sections and save it as 
docs/planning/compliance-brief.md
in the project repository:
生成包含以下部分的简报，并保存至项目仓库的
docs/planning/compliance-brief.md
路径下：

1. Scope Summary

1. 范围摘要

  • product purpose
  • user groups
  • jurisdictions and institutions
  • data categories in scope
  • 产品用途
  • 用户群体
  • 管辖区域及机构
  • 涵盖的数据类别

2. Likely Compliance Domains

2. 可能涉及的合规领域

Mark each as 
likely
, 
possible
, or 
unlikely
:
  • HIPAA or institutional privacy
  • IRB or human subjects review
  • FDA or software-as-medical-device review
  • GDPR or other regional privacy obligations
  • security review by enterprise or academic partners
将每个领域标记为
likely
（可能）、
possible
（潜在）或
unlikely
（不可能）：
  • HIPAA或机构隐私
  • IRB或人类受试者审查
  • FDA或软件类医疗设备审查
  • GDPR或其他地区隐私义务
  • 企业或学术合作伙伴的安全审查

3. Key Risks

3. 主要风险

Call out the highest-risk issues, such as:
  • unclear product claims
  • unnecessary data collection
  • missing consent boundaries
  • unclear vendor or data-sharing relationships
  • lack of export, deletion, or audit processes
指出高风险问题，例如：
  • 产品声明不明确
  • 不必要的数据收集
  • 缺失知情同意边界
  • 供应商或数据共享关系不清晰
  • 缺乏数据导出、删除或审计流程

4. Required Decisions

4. 待决策事项

List decisions the team must make soon, for example:
  • exact data categories to collect
  • whether identifiable data is actually required
  • whether the product is research, care delivery, or wellness
  • retention timelines
  • who can access what data and why
列出团队需尽快做出的决策，例如：
  • 需收集的确切数据类别
  • 是否确实需要可识别的数据
  • 产品属于研究、护理交付还是健康管理类
  • 数据留存期限
  • 谁可以访问哪些数据及访问原因

5. Recommended Controls

5. 建议的控制措施

Express these as implementation-neutral capabilities, not code:
  • access control and least privilege
  • encryption in transit and at rest
  • audit logging
  • consent capture and versioning
  • export and deletion workflows
  • vendor review and data processing agreements
  • documented retention and incident response procedures
以独立于具体实现的能力形式呈现，而非代码：
  • 访问控制与最小权限原则
  • 传输及静态数据加密
  • 审计日志
  • 知情同意捕获与版本管理
  • 数据导出与删除工作流
  • 供应商审查与数据处理协议
  • 文档化的留存及事件响应流程

Important Guardrails

重要注意事项

  • Do not present legal conclusions as certainties.
  • Distinguish clearly between product guidance and legal advice.
  • Prefer “you likely need to evaluate” over “you must” unless the requirement is explicit and well established.
  • Flag when local counsel, compliance officers, IRB staff, or institutional privacy teams should review the plan.
  • 不要将法律结论表述为确定性内容。
  • 明确区分产品指导与法律建议。
  • 除非要求明确且已确立，否则优先使用“您可能需要评估”而非“您必须”的表述。
  • 标记出何时需由本地法律顾问、合规官员、IRB工作人员或机构隐私团队审查规划方案。

Checklist

检查清单

  • Product purpose and claims clarified
  • User groups and jurisdictions identified
  • Data categories and sharing paths mapped
  • Research and clinical context assessed
  • Likely compliance domains identified
  • High-risk gaps called out
  • Required decisions listed
  • Recommended controls framed without platform-specific implementation details
  • 明确产品用途及声明
  • 确定用户群体及管辖区域
  • 梳理数据类别及共享路径
  • 评估研究及临床背景
  • 识别可能涉及的合规领域
  • 指出高风险差距
  • 列出待决策事项
  • 以无平台特定实现细节的形式呈现建议的控制措施