Python+Django构建罕见病药物研发管理系统实践

接手罕见病药物研发的管理系统时，十有八九会有人问：总共就这么几个人，数据量也不大，能不能用 Excel 管？我最早也这么想过。等真正把靶点筛选、临床前实验、伦理审查、临床试验入组和随访全部串起来以后，才发现这东西的瓶颈从来不是数据量，而是流程、角色和合规。

这套基于 Python + Django 的罕见病药物研发管理系统，就是把一个多角色、多阶段、强合规的研发链条，从项目立项、化合物资料管理、临床前研究记录，一直管到临床试验中心与受试者随访，同时通过相对严格的角色权限、审批流和文件归档，保证关键节点都有据可查。文章里我会把设计思路、技术选型、核心代码和一些实战排查经验都写下来，自己踩过不少坑，希望能帮你把第一个版本跑起来。

1. 项目从哪来：罕见病药物研发的管理困境

1.1 罕见病研发到底特殊在哪

很多人一听“罕见病”，第一反应是“病人少，样本少，系统应该很轻”。但实际跑过研发项目就会知道，样本少恰恰意味着每一份数据都珍贵，不允许有记录丢失、版本混乱或者字段不完整。换句话说，数据量不大，但数据的严肃程度非常高。

普通疾病的新药研发，如果一套流程做歪了，还能靠大样本把问题稀释掉。罕见病不行，一个中心可能就入组几十个受试者，任何一个随访节点漏了，或者一个不良事件记录没跟上，都会直接影响整个试验的数据质量和伦理审查结论。这时候系统要解决的核心问题不是“存得下”，而是“流程不乱、权限不越、记录可审计”。

我梳理下来，至少有几个管理点是绕不开的：

• 研发阶段跨度大：从靶点发现、化合物库筛选、临床前动物实验，到 IND 申报、I/II/III 期临床试验、NDA 申报，一个项目可能跨好几年，团队换了三拨人，管理工具必须能沉淀历史。
• 多中心协同多：临床协调员、研究者、监查员、伦理委员会、合作方 CRO 分布在多个机构，文件传递靠邮件和微信很容易失控。
• 审批节点多：研究方案要审批，知情同意书版本更新要审批，受试者入组也要审批，每个动作都要留下“谁在什么时间做了什么决定”的痕迹。
• 文件版本敏感：知情同意书、病例报告表、实验原始记录，在审计时都要能追溯到版本变化，不是发一个 PDF 就算完。

所以我在做系统设计时，没有一上来就堆功能，而是先把“角色—阶段—审批—文件”这条主线画出来。后面 Djaongo 的建模、权限、状态机设计，全都是在围绕这条主线展开。

1.2 为什么是 Python + Django

每次给团队讲技术选型，都会有人问：这种管理类系统，为什么不用 XX 开源框架，甚至直接买一套现成的？我的答案很实际：罕见病药物研发管理这块，市面上现成产品要么面向大型药企、价格和部署成本都很高，要么流程固化，很难适配小团队快速调整的需求。自研的话，选 Python + Django 是我认为性价比最高的组合。

Java / Spring Boot 当然也能做，但项目初期团队往往只有三四个懂业务的人，Java 那一套工程化配置可能还没等业务逻辑写完，光环境搭建就耗掉不少时间。PHP 老项目能跑，但代码积累久了，维护安全性反而让人心里没底。Python 有天然优势：团队成员即使之前是做数据分析、生信或者科研背景，学习成本也很低，写起来接近自然语言，迭代速度肉眼可见。

Django 的好处则更像“自带电池”：用户认证、Admin 后台、ORM、表单处理、CSRF 防护这些都是内置的。对一个内部管理系统来说，这些不是加分项，是救命项。我见过太多用 Flask 或者 FastAPI 搭管理后台的项目，启动容易，后面所有基础模块都得自己造轮子；Django 把这些事一次给齐了，你能把精力放在真正的业务逻辑上。

另外还有一个隐含优势：Python 生态里有大量药物研发场景可以调用的库，比如分子指纹计算、结构分析、数据统计、机器学习模型。管理系统的数据后来可以直接喂给分析脚本，不用做一道很重的手工导出转换。这个便利在传统 Java 体系里想做也能做，但衔接成本明显更高。

Django 也不是没有短板。它的模板渲染和传统前端交互方式，不适合做高度动态的复杂页面；如果你未来要做一个强交互的移动端应用，还是得搭配 DRF 写接口。但这不影响它作为管理后台和监管后台的核心地位，至少在项目一期，它是最能保证交付质量的框架。

1.3 这套系统适合谁来参考

如果你是药物研发项目负责人、临床项目经理、科研秘书，或者公司里负责搭建内部工具的 IT 支撑人员，这套方案可以直接作为落地参考。它能解决的问题是：在没有庞大信息化预算的前提下，用一个可维护、可迭代的 Web 应用，把项目进展、临床数据、文档版本和审批信息统一管起来。

如果你只是一个人维护一个“个人实验记录本”，那杀鸡用牛刀，直接使用 Django 自带 Admin 都嫌重。如果你面对的是多租户 SaaS 场景、需要支持几十家药企同时使用的商业化平台，那这套设计也需要重新抽象，不能照抄。它最舒服的区间，就是“单组织内部管理 + 外部合作方受限访问”这个范围。

2. 从业务流程到技术栈：整体设计是怎么定出来的

2.1 核心模块拆解

做这种管理系统，最怕的就是模块拆得太碎。我见过有人一上来就建了三十多张表，最后一大半没人填。我设计这个系统时，坚持“业务动作驱动表结构”，只保留五个业务域：

• 研发项目管理：项目基本信息、里程碑、进度状态、项目成员。
• 候选药物与靶点资料：化合物编码、靶点、作用机制、适应症、所处研发阶段。
• 临床前与临床研究：实验记录、试验中心、受试者入组、随访数据、不良事件。
• 文档与审批中心：方案文档、知情同意书、各类报告，以及跨角色的审批流程。
• 系统设置与用户权限：用户、角色、部门、外部合作方账号、操作日志。

这五个域之间不是孤立的。一个项目可以挂多个候选药物，一个候选药物可以进入多个临床试验，一个临床试验又涉及多个中心和受试者。文档则像一条辅线，挂靠到项目、候选药物、试验和受试者上，每个文档都可能触发审批流。

这是很自然的业务拆法。好处是边界清楚，Django app 划分也顺理成章：project、druglib、clinical、document、account 五个 app。后面如果哪个模块要改，不会牵一发动全身。

2.2 技术栈与关键依赖

我的技术选型比较保守，核心诉求是“稳定、能快速改、部署不折腾”。

为什么坚持上 DRF？早期我也纠结过，Django 模板 + Bootstrap 明明能更快开发内部系统。但考虑到后续要做外部合作方只读账号，甚至可能给临床中心开一个独立 Portal，接口层早晚要拆。所以我在项目一开始就把数据返回统一走 API，页面渲染交给前端，这样一个后端既喂管理页面，也喂外部系统，不用后期推倒重来。

关于审批流，我用的是 django-fsm 而不是上正式的流程引擎。罕见病项目审批节点虽然多，但流程相对固定，用状态机描述足够，没必要引入 Activiti 这类重引擎，引入反而增加部署复杂度。文件管理这块，我用的是 django-private-storage，配合自定义权限校验，保证没有权限的用户无法直接猜 URL 下载文件。

2.3 角色权限与对象级访问控制

Django 自带用户、分组、权限模型，基础权限可以直接用，但做研发管理系统，光有“能不能访问这个菜单”远远不够。常见场景是：同一个用户能查看 A 项目的化合物资料，但不能查看 B 项目的受试者详情。这种“对象级权限”如果不在项目初期设计，后面补起来很痛苦。

我的做法是给用户添加一个 profile，里面存角色和组织信息：

python复制# account/models.py
class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    ROLE_CHOICES = (
        ('ADMIN', '系统管理员'),
        ('PI', '项目负责人'),
        ('RESEARCHER', '研究人员'),
        ('COORDINATOR', '临床协调员'),
        ('MONITOR', '监查员'),
        ('ETHICS', '伦理委员会'),
        ('EXTERNAL', '外部合作方'),
    )
    role = models.CharField(max_length=20, choices=ROLE_CHOICES)
    organization = models.CharField(max_length=200, blank=True)

然后用 QuerySet 管理数据可见范围。比如临床协调员只能看到自己负责中心的受试者，项目负责人能看到自己名下的项目数据，系统管理员可以看全部：

python复制# clinical/managers.py
class SubjectQuerySet(models.QuerySet):
    def visible_to(self, user):
        if user.is_superuser:
            return self
        profile = getattr(user, 'profile', None)
        if not profile:
            return self.none()
        if profile.role == 'PI':
            return self.filter(trial__project__owner=user)
        if profile.role == 'COORDINATOR':
            return self.filter(site__coordinators=user)
        return self.none()

这一步做得好，后面的列表页、详情页、下载文件、生成报表，只需要统一调用 visible_to 这个入口，就不会出现“有权限查列表，却没权限看详情”之类的低级漏洞。

2.4 数据模型与状态设计

研发系统的数据模型有一个隐藏要求：所有主数据都要保留历史痕迹，不能轻易物理删除。所以我在核心表里都加了一组“生命周期”字段：

• is_active：软删除标记。
• created_at / updated_by：审计字段。
• version：文档和数据结构的版本号。

举个例子，知情同意书如果更新了版本，旧版本不能删，要归档到文档库，并且让审批记录里能查到旧版本是谁提交的。这个思路用到普通业务表也成立：实验记录如果填错了，应该允许更正，但更正动作本身要记录，而不是直接把原记录删掉。做法是在模型层重写 delete()：

python复制class BaseModel(models.Model):
    is_active = models.BooleanField(default=True)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def delete(self, using=None, keep_parents=False):
        self.is_active = False
        self.save()

    class Meta:
        abstract = True

这样在 Admin、DRF 里调用 delete() 时，都只会做软删除，查询时默认过滤 is_active=True。

3. 核心功能落地：从建表到文件审批的完整实操

3.1 环境准备与项目初始化

先说我用的环境：Ubuntu 22.04 服务器，Python 3.10，PostgreSQL 14，本地开发用 Windows 11。项目代码管理走 Git，前后端分开两个目录。

初始化步骤：

bash复制# 1. 建虚拟环境
python -m venv venv
source venv/bin/activate

# 2. 安装核心依赖
pip install django==4.2.16 djangorestframework django-cors-headers django-filter django-fsm django-private-storage psycopg2-binary celery redis

# 3. 创建项目
django-admin startproject config .

# 4. 创建业务 app
python manage.py startapp account
python manage.py startapp project
python manage.py startapp druglib
python manage.py startapp clinical
python manage.py startapp document

这一步常见的失误是 app 划分和业务域对不上。我的建议是，第一次做千万别把 clinical 拆成 trial、subject、visit 三个 app，数据上的关联会让 migration 顺序非常头疼。等业务稳定了，再拆不迟。

创建完之后需要在 settings.py 里注册 app，并把 AUTH_USER_MODEL 指向自定义用户模型。我强烈建议接手类似项目时，从第一天就自定义 User，哪怕只是给 Django 内置用户加一个 user_type 字段。否则后期想加手机号、工号、单位信息，迁移成本会高到你怀疑人生。

python复制# account/models.py
from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    user_type = models.CharField(max_length=20, choices=USER_TYPE_CHOICES)

3.2 核心模型怎么建

核心模型我把它们分成三类：主数据、业务记录、流程记录。主数据如化合物、靶点、试验中心；业务记录如实验数据、访视数据；流程记录如审批单、文档变更记录。

先看主数据模型：

python复制# druglib/models.py
class DrugCandidate(BaseModel):
    code = models.CharField(max_length=50, unique=True, verbose_name='药物编号')
    name = models.CharField(max_length=200, verbose_name='药物名称')
    target = models.ForeignKey('Target', on_delete=models.PROTECT, verbose_name='靶点')
    mechanism = models.CharField(max_length=200, blank=True, verbose_name='作用机制')
    owner = models.ForeignKey('account.User', on_delete=models.PROTECT, verbose_name='负责人')
    stage = models.CharField(max_length=30, choices=STAGE_CHOICES, default='discovery', verbose_name='当前阶段')

    def __str__(self):
        return f'{self.code} - {self.name}'

要注意 on_delete=models.PROTECT。研发数据里，业务记录一旦生成，上游主数据就不能随便删，否则历史统计全部失效。比如有人提交了实验记录，引用了一个化合物，这个化合物就不能直接 CASCADE 删掉。用 PROTECT 可以在数据库层面拦住误删，至少让你有个机会重新走审批流程。

临床试验模型建议采用“试验中心—受试者—访视”三层结构。第一次做最容易踩的坑，是把受试者信息直接平铺在试验表里，导致后续加随访记录、不良事件时无从下手。

python复制# clinical/models.py
class Trial(BaseModel):
    code = models.CharField(max_length=50, unique=True)
    name = models.CharField(max_length=300)
    phase = models.CharField(max_length=20, choices=PHASE_CHOICES)
    drug = models.ForeignKey('druglib.DrugCandidate', on_delete=models.PROTECT)
    sites = models.ManyToManyField('Site', related_name='trials')
    status = models.CharField(max_length=30, choices=STATUS_CHOICES, default='draft')

class Site(BaseModel):
    name = models.CharField(max_length=200)
    principal_investigator = models.ForeignKey(
        'account.User', on_delete=models.PROTECT, related_name='managed_sites'
    )

class Subject(BaseModel):
    serial_no = models.CharField(max_length=50, unique=True, verbose_name='受试者编号')
    trial = models.ForeignKey(Trial, on_delete=models.PROTECT, related_name='subjects')
    site = models.ForeignKey(Site, on_delete=models.PROTECT)
    enrollment_date = models.DateField()
    status = models.CharField(max_length=20, choices=SUBJECT_STATUS, default='screening')

受试者编号我建议直接用 随机编号，不要放姓名、身份证号甚至缩写的真实姓名。受试者隐私在研发系统里是绝对的底线，外部监查员需要看数据时，看到脱敏编号就够了。

3.3 审批流用什么方式写

审批流是这个系统的核心功能，也是最容易做过度的地方。我不建议一开始就引入完整的工作流引擎。对一个罕见病管理系统，我用的方案是“状态机 + 审批记录表”：

• 状态机定义业务对象走到哪一步。
• 审批记录表记录每一步是谁操作、操作时间、意见、附件。

我以“试验方案审批”为例，用 django-fsm 写：

python复制# clinical/models.py
from django_fsm import FSMField, transition

class Trial(BaseModel):
    # ...
    approval_status = FSMField(default='draft', protected=True)

    @transition(field=approval_status,
                source='draft',
                target='submitted',
                permission=lambda user: user.has_perm('clinical.submit_trial'))
    def submit(self):
        pass

    @transition(field=approval_status,
                source='submitted',
                target='approved',
                permission=lambda user: user.has_perm('clinical.approve_trial'))
    def approve(self):
        pass

    @transition(field=approval_status,
                source='submitted',
                target='rejected',
                permission=lambda user: user.has_perm('clinical.approve_trial'))
    def reject(self):
        pass

调用方只需要在视图里：

python复制trial = get_object_or_404(Trial, pk=pk)
if not trial.can_submit(request.user):
    raise PermissionDenied
trial.submit()
trial.save()
ApprovalRecord.objects.create(
    target_type='Trial',
    target_id=trial.id,
    action='submit',
    operator=request.user,
    comment='提交卫健委伦理审查资料'
)

这个写法的好处是：审批逻辑是显式状态转移，一眼能看懂；权限直接在状态转移上声明，不会出现“状态都变了才发现权限没校验”的低级错误。审计记录和业务表分离，想查任何对象的历史轨迹，只需要按 target_type + target_id 过滤。

protected=True 在这里很重要，它保证状态只能通过定义好的 transition 方法修改，别的地方写不进去。我见过有人在视图里直接 trial.approval_status = 'approved' 然后 save()，这就是常规 Django 写法，但会绕过所有审批校验，审计也白做了。

3.4 隐私文件不能直接挂静态目录

受试者知情同意书、临床实验记录，这些文件都属于敏感数据。如果放在 MEDIA_ROOT 并用 Nginx 直接通过 /media/ 公开访问，任何一个知道 URL 的人都能下载，这是灾难。

我采用的做法是：所有文件走一个私有文件视图，先校验用户权限，再返回文件流。用 django-private-storage 可以很优雅地实现这个逻辑。

python复制# document/views.py
from django.contrib.auth.decorators import login_required
from django.http import FileResponse, Http404
from .models import StudyDocument

@login_required
def protected_document(request, pk):
    doc = get_object_or_404(StudyDocument, pk=pk)
    # 这里调用统一的数据权限入口
    if not doc.can_view(request.user):
        raise Http404
    return FileResponse(doc.file.open(), content_type=doc.mime_type)

URL 配置走独立路径，不暴露物理文件名：

python复制# document/urls.py
urlpatterns = [
    path('doc/<int:pk>/download/', views.protected_document, name='protected-doc'),
]

文件上传时还要做两件事：一是重新生成文件名，避免中文名和特殊字符在跨平台传输时出问题；二是限制上传类型和大小。

python复制def upload_to(instance, filename):
    ext = os.path.splitext(filename)[1].lower()
    return f'docs/{instance.trial.code}/{uuid.uuid4().hex}{ext}'

我在生产环境里还会加一层防护：不要把这个 /doc/ 路径挂在公网 Nginx 的默认域名下，最好挂在内部网关后面。罕见病患者的隐私保护不是靠前端隐藏菜单，而是靠后端每一道入口都校验。

3.5 提醒任务与报表

研发系统免不了要发提醒：随访时间到了、审批单超时未处理、化合物阶段快要过期。这类任务用 Celery Beat 做定时任务比较合适。

我建了一个 common/tasks.py：

python复制# common/tasks.py
from celery import shared_task
from django.utils import timezone
from clinical.models import Visit

@shared_task
def send_visit_notifications():
    tomorrow = timezone.localdate() + timezone.timedelta(days=1)
    visits = Visit.objects.filter(visit_date=tomorrow, is_active=True)
    for visit in visits:
        send_mail(
            '受试者随访提醒',
            f'{visit.subject.serial_no} 计划于 {visit.visit_date} 随访',
            'no-reply@yourcompany.com',
            [visit.site.principal_investigator.email],
        )

定时任务配置：

python复制CELERY_BEAT_SCHEDULE = {
    'send-visit-notifications-daily': {
        'task': 'common.tasks.send_visit_notifications',
        'schedule': crontab(hour=8, minute=0),
    },
}

报表导出，我通常用 Pandas 在后端离线生成 Excel，再放到一个“报表下载中心”，比在线查询图表简单且稳定。这个思路在研发数据量不大时特别实用，一次生成的数据可以在浏览器端随意筛选，不会把数据库拖垮。

3.6 线上部署特别注意点

之前我把系统部署到一台内网 Linux 服务器，遇到了很多问题，总结下来几个关键点，新手照着做能少踩至少一天的坑。

首先，settings.py 要拆成 base.py / dev.py / prod.py，生产环境必须 DEBUG=False，并配置 ALLOWED_HOSTS。很多人图方便，生产也开 DEBUG，报错页面会把数据库查询和文件路径全部暴露出来，这在医药场景里是严重事故。

其次，静态文件要执行：

bash复制python manage.py collectstatic --noinput

再配置 Nginx：

nginx复制server {
    listen 443 ssl;
    server_name mis.example.com;

    client_max_body_size 50m;

    location /static/ {
        alias /data/rd_drug_mis/static/;
    }

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Gunicorn 启动参数我建议写：

bash复制gunicorn config.wsgi:application --bind 127.0.0.1:8000 --workers 3 --timeout 120

--timeout 120 很重要，因为报表导出和批量文件下载都可能超过默认的 30 秒。

最后，把 Celery 和 Beat 用 systemd 或 supervisor 常驻，保证重启服务器后自动拉起。我第一版部署时忘了配 Celery 开机自启，结果每日提醒任务整整一周没跑，要不是用户反馈，问题还会继续躺着。

4. 上线前后最容易踩的问题

4.1 权限控制只做了一半，列表页全部泄露

新手做 Django 权限，最容易犯的错是：视图里用了 LoginRequiredMixin，觉得登录了就能看，于是所有列表接口都返回全部数据。表面上页面是好的，但研究员一点开网络请求，就能拿到其他项目的受试者列表。

排查思路很简单：在 get_queryset() 里统一调用 .visible_to(request.user)，并且不止在列表视图加，还要在详情视图、文件下载视图、Admin 后台的 get_queryset 里全部加上。我之前就是只改了 DRF 列表，忘了改 Django Admin，结果管理员后台里还能看到所有数据。

还有一个细节：权限测试不能只测“普通用户”，要建一个“外部合作方”账号整条链路跑一遍。外部合作方往往只是被授权查看某个试验的文件，很常见的情况是权限忘了收，导致整个数据库都能被搜索到。

4.2 列表查询慢，N+1 是元凶

Django 模型的优势是 ORM 写起来爽，但写不好就生成大量低效 SQL。比如受试者列表页，循环渲染每个受试者对应的试验、中心、负责医生，如果没有 select_related，一次请求可能发几百条 SQL。

优化建议就两条：

python复制# 用 select_related 处理外键
queryset = queryset.select_related('trial', 'site', 'site__principal_investigator')

# 用 prefetch_related 处理多对多和反向关联
queryset = queryset.prefetch_related('trial__sites')

在 DRF 的 get_queryset 里写好后，即使后续加了筛选、分页，性能也有底。一旦列表和详情页都跑顺了，别忘了在 Django Debug Toolbar 里看 SQL 数量，超过 20 条就要怀疑 N+1。

4.3 文件上传的几个隐形坑

文件上传这块，真实踩过的坑：

• 文件名带中文，在 Windows 开发环境正常，Linux 部署后保存路径变成乱码。解决：上传接口统一重命名，用 UUID。
• 上传超过 Nginx 限制，返回 413。解决：在 Nginx 和 Django 都配置 client_max_body_size 和 DATA_UPLOAD_MAX_MEMORY_SIZE。
• 文件类型校验只看后缀，伪造 .pdf 实际上传了一个可执行文件。解决：用 python-magic 读 MIME 类型做二次校验。
• 文件路径暴露在日志里。解决：日志里不要直接打 file.name，打 doc.id 和 doc.code 即可。

4.4 开发与生产环境不一致

有些项目团队在 Windows 本地开发，数据库用 SQLite，一开始没有任何问题。上了生产，切到 PostgreSQL，才发现 JSONField 的查询语法有差异，或某些 SQLite 支持的函数在 PostgreSQL 里写法不同。

我的建议是：本地开发环境也要用 Docker 跑一个 PostgreSQL 和 Redis，保证数据库一致，避免“在我电脑上是好的”这种经典悲剧。至少要把 requirements.txt 锁版本，不要用 pip freeze 直接导出一大堆无关包，手动整理核心依赖，然后提交到 Git。

5. 写在最后：几点施工建议

做这套系统前后改了三版，最终稳定下来，最核心的心得只有一句话：先把流程共识做出来，再写代码。技术上 Python + Django 的选型本身没有瓶颈，真正影响项目成败的，是你有没有先用纸把“谁能看、谁能批、文件存在哪、状态怎么流转”这四个问题跟业务方对齐。

我记得第一版时，我以为把所有字段都做成可编辑就行，结果研究员自己都不知道填哪些内容，表单做得再漂亮也没用。后来改成“每个阶段只展示当前阶段需要填的字段”，配合审批流控制状态，反而所有人都愿意用了。

还有一个建议是，不要一开始就想着自动化报表、AI 分析、智能预警——这些是后面的甜点。第一版只要能把数据存对、权限管住、审批走通，就已经解决了 80% 的管理问题。你先用 Django Admin 把核心三个模型跑起来，让真实用户用两周，你会发现真正的需求会自己浮出来，那时候再迭代，远比一次性设计更靠谱。

如果后面有精力，我会把多中心数据交换和受试者自主查询功能加上，但当前这个基础版本已经足够让团队在一个可控的流程里做研发管理了。希望这篇文章能给你少走点弯路，项目推进顺利。