简介毕业设计课题聚焦基于区块链的医疗存储系统适用于计算机、软件工程等专业学生作为毕业设计选题参考与开发模板。资源围绕去中心化、不可篡改的链上医疗数据管理展开针对传统中心化存储中的病历数据孤岛、容灾脆弱、患者缺乏控制权等痛点给出涵盖患者病历分布式存储、隐私保护与共享授权的系统化方案能帮助读者快速建立从需求分析到系统实现的技术框架。压缩包共209个文件、11.17MB包含Java/Go源码、YAML配置、PEM/CRT密钥证书、SQL脚本以及docx/PDF文档等可覆盖代码实现、环境部署、数据表设计和说明文档等完整链路其中任务书、中期报告、答辩PPT、外文翻译原文与译文等材料还可直接辅助毕业设计各阶段材料撰写。当前已有49人学习适合需要系统梳理区块链医疗存储方案并希望按高校规范完成毕业设计文档与演示的读者。1. 医疗存储系统里区块链真正要解决的是信任问题很多人在毕业设计里把CT影像、病历全文直接写成区块链交易跑完发现存储爆炸、查询极慢。反直觉的结论是区块链在医疗存储系统里的角色不是“存数据”而是“存证据”。一台CT机生成的影像可能有50MB链上放不下也没必要放需要链上固定的是数据的哈希、归属关系、访问授权和操作日志。中心化数据库仍然保存原始密文区块链保证这些密文在什么时间、由谁、根据什么授权被写入和读取一旦事后发生纠纷哈希比对就能证明数据是否被篡改。这个方案适合需要实现跨机构病历共享、电子处方流转、科研数据审计的医疗信息化课题。它能回答评审老师最常见的问题和普通数据库加日志相比区块链到底提供了哪些不可替代的能力。本文按“链上存证、链下存储”的思路把数据模型、Fabric网络搭建、加密授权和性能验证讲清楚所有命令和代码都能在单机环境复现。2. 链上存证医疗记录的数据模型与哈希设计2.1 数据分层什么字段进区块什么字段进对象存储医疗存储系统的第一决策不是选链而是划分数据边界。常见做法是分三层原始数据DICOM影像、PDF报告、元数据患者ID、检查类型、时间戳、报告结论、存证指纹SHA-256哈希、加密算法标识、数据位置指针。原始数据放在医院的分布式文件系统或IPFS等链下存储元数据和存证指纹才写入区块链。这样设计的原因是区块链的每个块都有容量和写入延迟约束把大文件塞进去会把交易成本推高几个数量级而且所有节点都会同步完整数据等于把患者隐私广播给了所有参与者。数据类型典型内容存储位置链上内容原始数据DICOM、PDF、JPEG链下对象存储无元数据患者ID(脱敏)、检查类型、科室、时间链下数据库链上摘要加密后的关键过滤字段存证指纹SHA-256、加密算法、存储桶路径链上哈希、路径、授权策略这里需要注意患者ID不能直接明文上链应该先用医院内部的匿名化映射表转换成伪ID。如果课题要过隐私评审这一步是必须有的。很多毕业设计忽视这一点直接把姓名和身份证号放进交易提案虽然Fabric通道内其他组织不一定会看到但这种设计经不起审计追问。2.2 原始文件的哈希计算与链上内容封装在写链码之前先在离线环境中计算文件的SHA-256。用Python的hashlib库是最直接的做法import hashlib, json, time, os def compute_file_hash(file_path: str) - str: sha256 hashlib.sha256() with open(file_path, rb) as f: # 分块读取避免大文件一次性占用内存 for chunk in iter(lambda: f.read(1024 * 1024), b): sha256.update(chunk) return sha256.hexdigest() def build_chain_payload(patient_alias: str, exam_type: str, file_hash: str, bucket_path: str, encrypted_sym_key: str) - dict: payload { docType: medical_record, patientAlias: patient_alias, examType: exam_type, fileHash: file_hash, bucketPath: bucket_path, encryptedKey: encrypted_sym_key, createTime: int(time.time()) } return payload if __name__ __main__: h compute_file_hash(sample_chest_ct.dcm) payload build_chain_payload(P-2024-001, CT-CHEST, h, s3://hospital-bucket/ct/P-2024-001.dcm, aes_gcm_key_base64_placeholder) print(json.dumps(payload, ensure_asciiFalse, indent2))逻辑说明compute_file_hash用1MB缓冲区分块读取避免DICOM文件过大时内存溢出build_chain_payload把患者别名、检查类型、哈希和存储路径组装成将要提交给链码的JSON结构。参数说明bucketPath是链下存储的唯一资源定位符链上保存这个路径而不是实际文件encryptedKey是后续章节要讲的患者数据加密密钥先占位。重复计算同一文件哈希如果结果不同说明传输或存储环节发生篡改这是后期审计的核心依据。这里有个容易踩的坑不要用加密后的密文直接算哈希应该对原始文件计算哈希再加密文件。因为如果对密文算哈希患者隐私被泄露时密文对应的哈希无法证明原始文件的完整性。正确顺序是原始文件先算哈希再加密再把哈希和密文一起保存。另外算法选择上SHA-256目前仍是医疗存证系统的安全底线SHA-1已经不推荐MD5更不要用。链码里用哈希前缀做状态键但验证完整性时必须使用完整哈希。2.3 用Go语言写医疗记录存证链码Hyperledger Fabric链码官方推荐用Go、Java或Node.js编写。在医疗存储系统里我一般选Go因为Fabric的链码SDK在Go下类型约束最清晰而且最终生成的是单一二进制文件部署时少三层依赖。下面是一个可以最小运行的数据存证链码骨架package main import ( encoding/json fmt time github.com/hyperledger/fabric-contract-api-go/v2/contractapi ) type MedicalRecord struct { DocType string json:docType PatientAlias string json:patientAlias ExamType string json:examType FileHash string json:fileHash BucketPath string json:bucketPath EncryptedKey string json:encryptedKey CreateTime int64 json:createTime Operator string json:operator } type RecordContract struct { contractapi.Contract } func (c *RecordContract) CreateRecord(ctx contractapi.TransactionContextInterface, patientAlias string, examType string, fileHash string, bucketPath string, encryptedKey string) error { // 防止重复存证同一文件哈希如果已存在直接返回错误 exists, _ : ctx.GetStub().GetState(REC_ fileHash[:16]) if exists ! nil { return fmt.Errorf(record already exists for hash prefix %s, fileHash[:16]) } record : MedicalRecord{ DocType: medical_record, PatientAlias: patientAlias, ExamType: examType, FileHash: fileHash, BucketPath: bucketPath, EncryptedKey: encryptedKey, CreateTime: time.Now().Unix(), Operator: admin, } recordJSON, _ : json.Marshal(record) // 使用哈希前缀做部分key避免暴露完整哈希造成查询侧的信息泄漏 return ctx.GetStub().PutState(REC_fileHash[:16], recordJSON) } func (c *RecordContract) QueryByHash(ctx contractapi.TransactionContextInterface, fileHash string) (*MedicalRecord, error) { recordJSON, err : ctx.GetStub().GetState(REC_ fileHash[:16]) if err ! nil { return nil, fmt.Errorf(failed to query record: %v, err) } if recordJSON nil { return nil, fmt.Errorf(record not found for hash prefix %s, fileHash[:16]) } record : new(MedicalRecord) err json.Unmarshal(recordJSON, record) return record, err } func main() { chaincode, _ : contractapi.NewChaincode(new(RecordContract)) if err : chaincode.Start(); err ! nil { fmt.Printf(Error starting medical record chaincode: %v, err) } }逻辑说明CreateRecord先把文件哈希的前16个字符作为状态键的一部分这样既保证同一文件可以快速查重又避免完整哈希直接出现在键里被排序并被邻居观察到QueryByHash用同样规则做读取。参数说明ctx.GetStub().PutState是Fabric链码写状态的唯一入口后续所有的授权检查都应该加在进入PutState之前的函数里。contractapi.NewChaincode会扫描挂在RecordContract上的所有公开方法自动生成合约描述所以不需要手动实现Init和Invoke。如果你不想用Go用Node.js写链码也可以但需要额外处理Buffer和JSON序列化的差异。Go链码的部署包在peer lifecycle chaincode package时只需要源码目录Fabric会拉取依赖进行编译如果网络拉不到fabric-contract-api-go需要先配置Go模块下载源。这个骨架没有做访问控制下一章会在网络层和链码层补上。3. 医疗存储系统的Fabric网络从编排到链码部署3.1 为什么选Fabric而不是以太坊或bitcoin区块链数据虽然以太坊的智能合约生态更成熟但医疗存储系统必须满足“参与方白名单”和“隐私授权”两个硬要求。比特币和以太坊这种公开链对所有节点广播交易任何节点都能看到完整的交易元数据这和医疗数据的保密性是冲突的。Hyperledger Fabric是许可链节点必须先加入组织拿到证书才能交易而且支持通道隔离心内科和影像科可以运行在同一个通道也可以拆到不同通道。和bitcoin区块链数据那种UTXO模型相比Fabric的账本状态模型更像传统数据库的“键-值”更新方便直接表达“某个患者的某条记录被更新”。对于毕业设计场景Fabric还有一个好处它自带一套比较完整的身份体系能讲清楚“医生能写、护士能读、患者只能看自己的”这类规则。如果拿以太坊做就得自己写一套角色管理合约工作量会大不少。3.2 使用test-network快速拉起单机开发链Fabric官方提供的fabric-samples仓库里带着test-network脚本这是本地开发最常见的起点。你的本机只需要装好Docker、docker-compose和jq。进入fabric-samples/test-network目录后执行./network.sh down ./network.sh createChannel -c medchannel -ca第一行清掉上次的残留容器和卷避免端口冲突第二行创建名为medchannel的医疗专用通道并启用Fabric CA。启用CA的意思是每个组织都有自己的证书颁发机构后续可以给医生、护士、患者签发不同属性的身份证书。如果没有加-catest-network会使用自带证书无法演示属性授权所以这里必须加。启动完成后再执行docker ps能看到至少六个容器一个orderer、两个peer、一个CA和两个CLI工具容器。下表是主要容器和端口容器作用监听端口orderer.example.com排序节点负责给交易排序出块7050peer0.org1.example.comOrg1的peer节点7051peer0.org2.example.comOrg2的peer节点9051ca_org1 / ca_org2组织CA7054 / 8054如果你的机器只有8GB内存建议关闭其他服务。链码容器是之后部署链码时才会动态拉起的不在这个初始列表里。启动时如果报端口占用用docker ps -a看看有没有残留同名容器不要直接改端口因为后续peer命令的TLS配置都默认指向这些端口。3.3 链码部署三步打包、审批、提交Fabric 2.x版本的链码生命周期是打包、安装、审批、提交。执行export PATH$PATH:../bin export FABRIC_CFG_PATH$PWD/../config peer lifecycle chaincode package medcc.tar.gz \ --path ../asset-transfer-basic/chaincode-go \ --lang golang \ --label medcc_1.0 peer lifecycle chaincode install medcc.tar.gz peer lifecycle chaincode queryinstalled先解释打包命令--path指向链码源码目录这里先用仓库自带的asset-transfer-basic示例链码验证网络等网络通了再换成你自己的医疗记录链码--label里的medcc_1.0是给链码包起的名字后续审批时版本号靠它区分。queryinstalled会返回一个PACKAGE_ID格式类似medcc_1.0:hash这个ID在审批命令里要用到。你需要把下面命令里的PACKAGE_ID替换成实际的输出值。peer lifecycle chaincode approveformyorg -o localhost:7050 \ --ordererTLSHostnameOverride orderer.example.com \ --channelID medchannel \ --name medcc \ --version 1.0 \ --package-id $PACKAGE_ID \ --sequence 1 \ --tls \ --cafile $PWD/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem peer lifecycle chaincode commit -o localhost:7050 \ --ordererTLSHostnameOverride orderer.example.com \ --channelID medchannel \ --name medcc \ --version 1.0 \ --sequence 1 \ --tls \ --cafile $PWD/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem参数说明--sequence是链码版本序号从1开始后续升级到2.0时改成2--cafile指向orderer的TLS根证书Fabric 2.x强制要求TLS。审批和提交看起来很像区别是approveformyorg只需要当前组织背书commit需要通道内多数组织批准后真正激活链码。test-network默认两个组织所以要先分别给Org1和Org2执行approveformyorg再执行一次commit。如果跳过某一步commit时会报“chaincode definition not agreed to by this org”。部署后调用一组测试命令验证peer chaincode invoke -o localhost:7050 -C medchannel -n medcc \ -c {function:CreateRecord,Args:[P2024-1001,CT-CHEST,abc123...,s3://hospital-bucket/ct/P2024-1001.dcm,encryptedKey]} \ --tls --cafile $PWD/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem peer chaincode query -o localhost:7050 -C medchannel -n medcc \ -c {function:QueryByHash,Args:[abc123...]} \ --tls --cafile ...注意CreateRecord如果返回“record already exists”说明哈希重复属于正常保护QueryByHash能用哈希前缀查到JSON记录网络才算真正跑通。如果查询时返回“Error endorsing query: chaincode not found”多半是提交还没有完成用peer lifecycle chaincode checkcommitreadiness检查通道上各组织的审批状态。如果在approveformyorg时出现权限拒绝通常是用Org1的环境变量操作Org2的peer重新加载对应组织的环境变量即可。4. 医疗存储系统的数据加密与权限控制实现4.1 文件加密与密钥分发的常用组合把原始文件直接传到对象存储是危险的尤其是影像数据包含患者姓名、检查日期等敏感信息。常见做法是对每个文件生成一个随机对称密钥用AES-256-GCM加密文件然后用接收方如医生或科室的公钥RSA加密这个对称密钥把加密后的密钥随文件一起存储。这样同一个文件可以发给多个授权人只需用各自的公钥加密对称密钥即可。使用openssl命令验证这一过程# 1. 生成文件密钥 openssl rand -base64 32 file_key.bin # 2. 用AES-256-GCM加密DICOM文件 openssl enc -aes-256-gcm -salt -pbkdf2 -iter 100000 \ -in sample_chest_ct.dcm -out sample_chest_ct.dcm.enc -pass file:file_key.bin # 3. 用影像科公钥加密文件密钥 openssl pkeyutl -encrypt -pubin -inkey radiology_pub.pem \ -in file_key.bin -out file_key.bin.enc逻辑说明-iter 100000指定PBKDF2迭代次数用于从密钥文件派生加密参数这是OpenSSL为了防止暴力破解加的参数openssl pkeyutl用非对称加密把对称密钥保护起来。参数说明file_key.bin是临时文件实际系统里应该放在内存或KMS里不能落盘radiology_pub.pem是使用方的公钥公钥可以明文分发私钥永远不能离开使用者设备。这个方案的常见误用是为了省事直接用同一把RSA公钥加密所有文件。一旦私钥泄露全部文件都会暴露。正确做法是每文件独立密钥而不是每用户一把密钥。对于毕业设计可以用下表说明访问级别角色能做的操作需要的材料医生读取/写入本科室记录个人证书、科室私钥对应的解密能力护士读取基础体征记录只读证书不能写入患者查看本人记录、授权他人本人证书需要授权记录审计员校验哈希、查操作日志只读区块链状态无文件解密权限4.2 链码层实现基于属性的访问控制Fabric CA签发的证书可以携带attrs属性比如roledoctor、departmentradiology。链码可以根据交易签名者的证书属性决定是否允许写入或读取。在Go链码中增加一个检查函数import github.com/hyperledger/fabric-contract-api-go/v2/contractapi func checkDoctor(ctx contractapi.TransactionContextInterface) error { cid, err : ctx.GetClientIdentity() if err ! nil { return fmt.Errorf(cannot get client identity: %v, err) } role, found, err : cid.GetAttributeValue(role) if err ! nil { return fmt.Errorf(cannot get attribute: %v, err) } if !found || role ! doctor { return fmt.Errorf(permission denied: role is %s, required doctor, role) } return nil }然后在CreateRecord和QueryByHash的入口调用checkDoctor。这样即使有人窃取了普通患者证书也无法写入新的医疗记录。注意GetAttributeValue只读取证书属性的明文部分如果属性是私密的需要用GetAttributeValue配合AssertAttributeValue来验证但不可读。对于医疗场景departmentcardiology也可以用于限制医生只能访问本科室记录。注意属性名要和CA签发时定义的完全一致。test-network里默认用户没有自定义属性需要先修改fabric-ca-server-config.yaml或在注册命令中加--enrollment.attrs否则GetAttributeValue会返回foundfalse。4.3 授权记录建模与撤销权限控制不只是“是不是医生”还要描述“哪个医生可以访问哪个患者的记录”。所以需要单独一类授权状态type AccessGrant struct { DocType string json:docType PatientAlias string json:patientAlias DoctorID string json:doctorId AccessLevel string json:accessLevel // read, write, admin ExpireAt int64 json:expireAt Revoked bool json:revoked }写入授权时先查患者状态再生成GRANT_patient_doctor键。撤销授权时把Revoked置为true保留历史而不是删除这样审计日志能看到完整的授权变更轨迹。链码的查询函数必须同时检查两个条件链上存在有效授权且当前时间小于ExpireAt。这两个条件缺一个就返回“access denied”。把Revoked字段放在授权状态里是常见做法避免撤销操作变成删除操作丢失审计证据。授权查询时通常需要分页因为一个患者可能授权给多个医生。Fabric的GetQueryResultWithPagination支持分页返回的bookmark可以用于下一页。如果使用levelDB这个函数不可用所以必须启动CouchDB。如果课题往“区块链的人工智能论文”方向延伸可以在链上存授权记录的同时存一份AI模型的推理版本哈希这样医生借用AI辅助诊断时系统能区分“人写的报告”和“AI生成的报告”审计时也能定位是哪一个模型版本给出的结论。这个设计不需要额外引入复杂算法只要在MedicalRecord结构里加一个modelVersion字段即可。5. 医疗存储性能瓶颈批量写入、查询索引与完整性验证技巧5.1 批量写入减少交易开销Fabric每个交易都要经过背书、排序、验证、提交四个阶段性能瓶颈在排序服务的共识环节。如果逐条提交医疗记录TPS会很难看。常见优化是“链下攒批链上批量提交”也就是将一批记录的哈希列表作为参数一次写入。可以在链码里定义一个BatchRecord结构{ docType: record_batch, batchId: b-20240601-001, recordCount: 10, hashMerkleRoot: ..., items: [ {patientAlias: P-1, fileHash: ..., bucketPath: ... } ] }链码只保存items数组里每一条的摘要和Merkle根查询时先用哈希比对单条记录是否在批量里。这个和bitcoin区块链数据的Merkle树结构类似但这里是为了压缩链上数据量不是为了挖矿。批量大小建议控制在10到50条之间太大单笔交易写入时间会超过背书超时阈值。批量写入时要注意链码函数必须对事务内的每条记录都调用PutState否则只有第一条被写入。5.2 使用CouchDB索引加速列表查询Fabric默认的levelDB只支持键查询如果链码用了query按examType过滤必须把状态数据库改成CouchDB。在core.yaml里把stateDatabase设为CouchDB后再给链码包添加一个索引文件META-INF/statedb/couchdb/indexes/recordType.json{ index: { fields: [docType, examType] }, ddoc: recordTypeIndex, name: recordTypeIndex, type: json }部署链码后用curl检查索引是否生效curl -s http://admin:adminpwlocalhost:5984/medchannel_medcc/_index | jq .indexes逻辑说明fields里的docType和examType是链码数据结构里的JSON字段CouchDB会把状态数据解析成JSON文档然后为这两个字段建立B-tree索引。参数说明ddoc是设计文档名name要和ddoc一致如果索引创建失败查询peer chaincode query会打印“no index found”警告但不影响功能只是性能差。注意CouchDB端口默认是5984admin:adminpw是test-network的默认账号生产环境必须改掉。除了examType还可以为patientAlias、createTime建立联合索引但要遵守最左前缀规则否则CouchDB不会命中索引。5.3 离线验证链上哈希与本地文件是否一致最后给一个最实用的技巧从对象存储拉回文件后重新计算SHA-256与链上查询的结果比对。写一个bash校验脚本#!/usr/bin/env bash set -euo pipefail LOCAL_FILE$1 EXPECTED_HASH$2 LOCAL_HASH$(sha256sum $LOCAL_FILE | awk {print $1}) if [ $LOCAL_HASH $EXPECTED_HASH ]; then echo VERIFY OK: $LOCAL_FILE matches on-chain hash else echo VERIFY FAIL: local hash $LOCAL_HASH, on-chain $EXPECTED_HASH 2 exit 1 fi调用方式./verify_medical_file.sh chest_ct.dcm $(peer chaincode query -o localhost:7050 -C medchannel -n medcc -c {function:QueryByHash,Args:[abc123...]} | jq -r .fileHash)脚本中set -euo pipefail让脚本在管道或命令出错时立即退出避免校验失败后继续后面的流程。EXPECTED_HASH来自链码查询结果通过jq -r .fileHash提取。把这个脚本接到你的CI或定时任务里每次数据备份恢复或跨院传输后自动比对这就是区块链存储系统带给医院的最直接价值。如果需要进一步优化可以把校验结果以事件回调的方式写回链上形成一条新的审计记录。本文还有配套的精品资源点击获取