GitLab 创始人用"工程师思维"对抗骨癌：开源医疗数据与并行治疗的技术路径

摘要

• GitLab 联合创始人 Sytse Sijbrandij 被确诊为脊椎骨肉瘤（T5 椎体），在标准治疗方案耗尽后，自主构建了一套"最大化诊断 + 并行治疗 + 数据开放"的个人医疗工程体系。
• 他将个人治疗数据（约 25TB）存储于公开可读的 Google Cloud 存储桶，以开源方式向外部研究者开放。
• 他以此为基础创办公司（evenone.ventures），试图将这套个人化、数据驱动的治疗方法规模化复制给其他患者。
• 核心主张：医疗行业应更以患者为中心，现有官僚体制正在阻碍治疗机会的获取。
• 信息不足：具体治疗方案的临床有效性数据、公司产品形态、技术栈细节均未在素材中披露。

---

背景与问题定义

问题场景：晚期罕见癌症患者在标准治疗方案（Standard of Care）耗尽后，通常面临两条路：等待临床试验名额，或放弃积极治疗。

Sytse 的情况正是如此——T5 椎体骨肉瘤，标准方案用尽，无可用临床试验。

他识别出的系统性缺陷：

1. 医疗决策链条过长，患者处于被动接受端。
2. 个人医疗数据高度碎片化，缺乏统一可查询的格式。
3. 治疗方案是串行的（一种失败再换下一种），而非并行探索。
4. 医疗官僚体制（审批、流程、准入）拖慢了患者获取潜在有效治疗的速度。

这是一个典型的信息不对称 + 流程串行化问题。他用工程师的方式来重新定义问题边界。

---

核心发现与技术要点

1. 最大化诊断（Maximum Diagnostics）

是什么：在标准诊断之外，主动获取尽可能多的诊断数据，而不是依赖单一医疗机构的检测结论。

为什么重要：

• 骨肉瘤是罕见癌症，单一机构的数据样本极为有限。
• 更多诊断数据意味着更多可能的治疗靶点被识别。
• 这与软件工程中的"可观测性优先"原则一致：你无法优化你看不到的东西。

信息不足：具体采用了哪些诊断技术（基因组测序、液体活检、影像组学等）未在素材中说明。

---

2. 并行治疗（Treatments in Parallel）

是什么：同时尝试多种治疗路径，而不是等一种方案失败后再启动下一种。

为什么重要：

• 串行试错在时间维度上代价极高，对晚期癌症患者尤为致命。
• 并行化是工程加速的核心手段——这里被直接迁移到医疗决策中。
• 风险是：并行治疗的副作用叠加和交互影响难以控制。

信息不足：并行治疗的具体组合方案、安全性监控机制未披露。

---

3. 数据开放与 25TB 公开存储桶

是什么：Sytse 将个人治疗时间线和医疗数据（约 25TB）存储在 Google Cloud 公开可读的存储桶中，任何人可访问（见 osteosarc.com）。

为什么重要：

• 这是一个罕见的个人级医疗数据开源行为。
• 25TB 的体量意味着可能包含高分辨率影像（CT/MRI/PET）、基因组数据、时序治疗记录等。
• 对研究者而言，这是一个真实的、纵向的骨肉瘤病例数据集——此类数据在公开领域极为稀缺。
• 技术上，Google Cloud 公开存储桶支持匿名访问，无需身份验证即可读取，降低了数据获取门槛。

数据访问路径：

https://osteosarc.com/
# 包含治疗时间线 + 数据概览文档 + GCS bucket 地址

---

4. 规模化复制：从个人实践到公司（evenone.ventures）

是什么：将上述个人医疗方法论抽象为可复用的产品/服务，通过创业公司的方式向其他患者推广。

为什么重要：

• 个人经验不等于可复制的系统。创业是一种将非标准流程产品化的手段。
• 这与开源软件的逻辑相似：个人解决了一个问题，然后将解决方案工程化，让更多人受益。

信息不足：evenone.ventures 的具体产品形态、商业模式、技术栈均未在素材中披露。

---

工程视角解读

对医疗数据工程的影响

数据孤岛是核心障碍。现有医疗系统中，患者数据分散在不同医院的不同系统，格式不统一，患者本人通常没有完整访问权。Sytse 的做法是绕过这一障碍——自己掌控数据主权，自己选择存储和开放方式。

这对医疗数据平台的产品设计有直接启示：患者数据所有权应归患者，平台应提供数据导出和授权共享能力。

可执行的改进方向

• 方向 1：构建个人医疗数据聚合工具
  开发者可以参考 osteosarc.com 的思路，构建一个将多源医疗数据（DICOM 影像、基因组 VCF 文件、血液检测 CSV）统一存储和版本管理的工具链。技术栈可选：Google Cloud Storage + BigQuery + DVC（数据版本控制）。

• 方向 2：为罕见病患者设计"并行假设管理"系统
  类似 A/B 测试框架，为患者和医生提供多个治疗假设的并行跟踪看板，记录每个方案的启动时间、剂量、生物标志物响应。核心是时序数据建模，推荐使用 TimescaleDB 或 InfluxDB。

• 方向 3：贡献或使用 osteosarc.com 的公开数据集
  如果你在做医学影像 AI、肿瘤基因组学或生存分析，这个数据集值得关注。25TB 的纵向真实数据在公开领域罕见。可以用 gsutil 或 GCS Python SDK 访问公开桶。

---

风险与边界

已确认事实

• Sytse Sijbrandij 确诊 T5 椎体骨肉瘤。
• 标准治疗方案已耗尽，无可用临床试验。
• 已采取最大化诊断、并行治疗、数据开放三类行动。
• 25TB 数据存储于 Google Cloud 公开存储桶。
• 已创办 evenone.ventures 尝试规模化这一方法。
• 在 OpenAI Forum 进行过公开演讲。

信息不足项

• 具体治疗方案内容（药物、剂量、组合逻辑）未披露。
• 并行治疗的安全性监控机制未说明。
• evenone.ventures 的产品形态、技术架构、融资情况未披露。
• 25TB 数据的具体构成（影像比例、基因组数据比例等）未说明。
• 治疗效果的量化指标未在素材中出现。

可能误用场景

• 不要将此案例解读为"患者可以自行替代医生进行治疗决策"。并行治疗在无医学监督的情况下风险极高。
• 不要将 25TB 数据直接用于模型训练而不审查数据质量和偏差——单一病例的纵向数据存在严重的样本偏差问题。
• 不要将"创业解决医疗问题"的框架简单套用——医疗监管合规是硬约束，不是可以绕过的流程。

---

实践清单（Checklist）

• 访问 osteosarc.com 查看数据结构，评估是否适合你的研究方向
• 用 gsutil ls gs://<bucket-name> 探索公开 GCS 存储桶的数据组织方式，学习大规模医疗数据的存储实践
• 阅读 Ruxandra 的文章（writingruxandrabio.com），了解医疗官僚体制对患者获取治疗机会的具体阻碍机制
• 如果你在做医疗 AI 产品，检查你的产品是否支持患者导出和掌控自己的数据
• 关注 evenone.ventures 的进展，评估其产品化路径对医疗数据工程领域的参考价值

---

参考

• 原始标题：Founder of GitLab battles cancer by founding companies
• 数据网站：https://osteosarc.com/
• 创业公司：https://evenone.ventures/
• 相关阅读：https://www.writingruxandrabio.com/p/the-bureaucracy-blocking-the-chance
• 联系方式：cancer@sytse.com