简介一套基于Java技术的区块链电子病历共享平台面向毕业设计、课程设计及医疗信息化研究者重点解决电子病历的安全存储、可信共享与隐私保护问题。压缩包共263个文件约9.92MB包含Java业务源码、Solidity智能合约、开发文档、数据库与配置资源以及前端脚本等按模块归放易于筛选。代码涵盖病历服务、数据访问控制等核心类附带合约目录、区块链初始配置和说明文档便于理解数据上链与系统调用流程。已有37人学习浏览平台利用区块链不可篡改与去中心化特性结合Java跨平台优势适合作为医疗区块链原型搭建、教学演示或功能二次开发的起点。系统代码经过完整验证配合41个docx开发文档和数据库、前端等辅助资源可支撑从环境搭建到业务扩展的实践路径资源仅供学习交流请勿用于商业使用时请尊重原作者版权。1. 电子病历共享平台的 Java 技术边界先把链上链下定清楚先说一个反直觉的结论做“基于Java技术的区块链电子病历共享平台”第一步要建立的自我约束是——别急着把病历正文写进区块。区块链在电子病历共享里解决的是“谁、在什么时间、依据哪条授权、把哪份病历交给了谁”的可信审计问题不是替代医院内部数据库。医院内部看诊流程、报告流转、影像文件仍应留在原系统里链上放脱敏的患者映射、病历摘要哈希、授权状态和操作日志。这层边界定了后续 Java 代码、链码、接口文档才不是摆设。这个定位直接命中跨院复诊、体检互认、医联体协查一类场景。对 Java 后端工程师来说整条链路涉及 Spring Boot 服务编排、Fabric Java Gateway 调用、链码状态机设计、加密与患者主索引四块。下面把每一步拆到可抄作业的粒度熟手也能在参数和边界上看到值得推敲的点。2. 基于Java技术的电子病历共享平台Fabric通道划分与链上链下双存储设计2.1 为什么医疗共享场景优先选联盟链而不是公链电子病历共享里区块链选型不是越有名越好。公链的匿名节点、代币激励和全局公开账本在医疗场景里是负资产病历访问主体必须是实名机构审计必须能回溯到具体医生数据绝不能向无关节点广播。所以医疗共享平台落地时普遍选联盟链Hyperledger Fabric 是 Java 技术栈里最主流的一个。选择 Fabric 的理由可以落在四点参与方边界明确。医院、检验机构、体检中心都是已知机构不需要匿名 PoW 或 PoS 共识交易需要审批。背书策略可以让开单医院和监管节点共同签字交易才真正上链节点数少、出块参数可调常见配置下秒级最终性够病历共享查询用私有数据集合Private Data Collection支持部分参与方可见和病历这类敏感数据的共享语义天然贴合。如果换成公链单是“把病历哈希广播到全网账本”这一步就很难过隐私评审。联盟链的圈内共享模型才是平台立项的前提。2.2 Fabric 通道划分按信任域拆别把所有医院塞进一条链通道Channel是 Fabric 里同一联盟下的子网络只有加入通道的 peer 能看到该通道账本。电子病历共享平台最常见的通道划分是医联体内牵头医院、成员医院、独立检测机构各是一个组织另加一个监管组织组成“跨机构共享通道”医院内部收费、排队、分诊数据不进这条通道。这样划分的好处是背书节点少、账本爆炸半径可控。患者撤回授权后影响范围只在共享通道内医院内部业务完全不受牵连。configtx.yaml 中最少要声明每个组织的 MSP 和消息策略下面是最小片段Organizations: - HospitalA Name: HospitalA ID: HospitalAMSP MSPDir: crypto-config/hospital-a/msp Policies: Readers: Type: Signature Rule: OR(HospitalAMSP.member) Writers: Type: Signature Rule: OR(HospitalAMSP.member) Admins: Type: Signature Rule: OR(HospitalAMSP.admin) AnchorPeers: - Host: peer0.hospital-a.example.com Port: 7051注意四点。MSPDir 指向由 Fabric CA 生成的目录admin 证书、CA 根证书、TLS 证书都在里面Readers 和 Writers 策略分别控制读账本和背书提交的权限写得太宽会让无权节点也能背书看数据AnchorPeers 是跨组织 gossip 发现用的入口配置错会出现 org 之间发现不了对方 peer 的报错换证书重新加入组织时需要重新执行通道更新命令日志里如果出现Failed to reach implicit threshold基本是 MSP 配置不一致。2.3 链上链下双存储CouchDB 状态库到底放什么“链上链下双存储”里的链上指的是应用通道的账本和世界状态World State。Fabric 支持 LevelDB 和 CouchDB 两种状态库医疗场景建议选 CouchDB因为它支持索引和富查询可以按患者哈希、时间、机构编号组合查病历台账。链上字段保持精简字段示例说明docNoEMR-2024-00831病历唯一编号医院 EMR 系统生成patientHasha1b2…9fSHA-256脱敏后的患者主索引不存证件号原文orgIdhospital-a病历归属机构对应 MSP IDrecordHashe5c1…7a加密后的病历文件摘要consentStatusGRANTED当前授权状态由链码维护ts2024-08-31T10:15:30Z链码写入交易时的时间戳真正的病历正文、影像文件和结构化报告放链下要么留在医院自有 EMR 库里由 Java 服务控制出库要么加密后放进 MinIO 这类对象存储区块链只记文件 SHA-256 校验值。查询时 Java 后端先从链上拿到 recordHash再到链下取文件重算哈希两边一致才把病历出库。这套设计推理和字段取值建议整理成配套开发资料里的《链上字段规范》文档。对 5 年以上工程师多说一句链码写入的 key 设计直接影响 CouchDB 并发。如果每一条就诊记录都去更新同一个患者聚合键背书节点的 LevelDB/CouchDB 会形成热点锁。我一般以docNo为 key 存病历摘要台账patientHash交给索引字段主键里不做患者维度聚合。2.4 出块参数三个值决定共享平台的秒级最终性Fabric 不需要等六个区块确认但 Orderer 的BatchTimeout、MaxMessageCount、AbsoluteMaxBytes三个参数直接决定交易确认时延和打包效率。Orderer: BatchTimeout: 1s BatchSize: MaxMessageCount: 50 AbsoluteMaxBytes: 10 MB PreferredMaxBytes: 2 MBBatchTimeout是打包等待窗口取 1 到 2 秒能在时延和网络负载间平衡MaxMessageCount表示一个区块里最多装多少笔交易做体检报告批量上链时可以调到 100AbsoluteMaxBytes是区块体积上限超限强制切块。PreferredMaxBytes则是软上限区块会尽量控制在 2 MB 以内。线上调优比理想值还要重要一点先拿你自己的链码跑压测再动这些值别照抄网上默认配置。3. 基于Java的电子病历共享授权链码状态机、索引与参数到底怎么定3.1 授权状态机区块链上的记录只有追加没有原地修改比特币交易天然只有“花掉”这一个语义Fabric 链码也类似同一个 key 上再putStringState旧值并不会被抹掉而是留在区块历史里成为可审计的 change set。这种追加式写法和病历修正天然贴近诊断写错了不能删除只能再追加一条修订记录指向旧的 docNo。电子病历共享平台的授权状态机我常用四个状态三次迁移SUBMITTED到GRANTED患者完成实名核验并同意共享链码写入授权关系GRANTED到REVOKED患者主动撤回授权或授权到期链码自动迁移SUBMITTED到REJECTED患者拒绝共享后台保留审计字段不产生任何出库授权GRANTED到EXPIRED链码在每次查询时惰性判断到期时间不依赖定时任务。为什么不用一个 bool 字段因为跨机构场景里门诊医生要读病历、影像科医生要读报告、检验科要读历史结果每个请求都要查授权状态、授权对象和到期时间。一个布尔值存不了多角色多机构的粒度。状态机里每一次迁移都是一条可审计交易谁在什么时候改了授权账本上永久可查。3.2 病历登记链码submitRecord 的 Java 实现用 fabric-chaincode-java 写链码核心类实现ContractInterface业务方法加Transaction注解。下面是登记节点上报病历摘要的最小实现package emr.chaincode; import java.time.Instant; import com.google.gson.Gson; import com.google.gson.JsonObject; import org.hyperledger.fabric.contract.Context; import org.hyperledger.fabric.contract.ContractInterface; import org.hyperledger.fabric.contract.annotation.Contract; import org.hyperledger.fabric.contract.annotation.Transaction; import org.hyperledger.fabric.shim.ChaincodeStub; Contract(name emrcc) public class EmrContract implements ContractInterface { private static final Gson GSON new Gson(); private static final String KEY_PATTERN emr_%s; Transaction(intent Transaction.TYPE.SUBMIT) public String submitRecord(Context ctx, String docNo, String patientHash, String orgId, String recordHash) { ChaincodeStub stub ctx.getStub(); String key String.format(KEY_PATTERN, docNo); if (!stub.getStringState(key).isEmpty()) { throw new IllegalArgumentException(病历编号已存在不能重复提交); } JsonObject rec new JsonObject(); rec.addProperty(docNo, docNo); rec.addProperty(patientHash, patientHash); rec.addProperty(orgId, orgId); rec.addProperty(recordHash, recordHash); rec.addProperty(consentStatus, SUBMITTED); rec.addProperty(ts, Instant.now().toString()); stub.putStringState(key, rec.toString()); return key; } Transaction(intent Transaction.TYPE.EVALUATE) public String queryRecord(Context ctx, String docNo) { String value ctx.getStub().getStringState(String.format(KEY_PATTERN, docNo)); if (value null || value.isEmpty()) { throw new IllegalArgumentException(病历记录不存在); } return value; } }参数说明和逻辑都在注释里了值得重复强调的几个点String.format(KEY_PATTERN, docNo)把自然键变成唯一 key避免不同医院生成相同 docNo 互相踩记录值用 JSON 存CouchDB 会把 JSON 展开成可索引的文档结构后面才能做富查询。Transaction.TYPE.SUBMIT对应背书节点上的写交易需要走 Orderer 排序上链TYPE.EVALUATE只读被 peer 直接应答不上链常规病历详情查询走 EVALUATE 能省掉排序节点带宽。还有一个高频坑链码里Instant.now()取的是背书节点本地时间同一笔交易在不同背书节点上可能拿到毫秒级差异。若对账需要严格统一的时间线改用区块时间戳或者 Orderer 对交易回执的时间戳团队里定一个固定取数源别两头都取。3.3 授权与吊销用 ClientIdentity 校验调用方身份病历授权必须确认“发起交易的人确实是该机构合法医生或者患者本人”。链码里拿不到 JWT能信的是 Fabric 证书身份。Java 端校验方式Transaction(intent Transaction.TYPE.SUBMIT) public String grantAccess(Context ctx, String docNo, String targetOrgMsp, String expireAt) { String callerMsp ctx.getClientIdentity().getMSPId(); if (!HospitalAMSP.equals(callerMsp)) { throw new IllegalArgumentException(只有病历归属机构可以发起授权); } ChaincodeStub stub ctx.getStub(); String authKey String.format(auth_%s_%s, docNo, targetOrgMsp); JsonObject auth new JsonObject(); auth.addProperty(docNo, docNo); auth.addProperty(targetOrgMsp, targetOrgMsp); auth.addProperty(status, GRANTED); auth.addProperty(expireAt, expireAt); auth.addProperty(grantedBy, ctx.getClientIdentity().getId()); stub.putStringState(authKey, auth.toString()); return authKey; }ctx.getClientIdentity().getMSPId()返回证书所属组织getId()返回身份签发标识。这里有个常见误用只按 MSP 判断组织不判断角色。同一家医院里也有医生、护士、管理员、信息科运维只校验组织意味着任意账号都能发起授权。生产环境建议在证书属性里注册roledoctor链码里用ctx.getClientIdentity().getAttributeValue(role)二次校验。3.4 CouchDB 富查询索引按患者和时间筛病历病历共享场景最常出现的查询是“某患者近半年的病历清单”。Fabric 链码里用stub.getQueryResult(queryString)走 CouchDB JSON 查询前提是链码包里放了对应索引文件{ index: { fields: [patientHash, ts] }, ddoc: idx-patients-ts, name: patientHash-ts, type: json }索引文件放在链码包META-INF/statedb/couchdb/indexes/目录下随链码一起安装部署。注意fields数组的顺序就是索引的排序键顺序[patientHash,ts]才能支持“先按患者筛选、再按时间排序”的两级查询如果写成[ts,patientHash]按患者筛查时索引就失效了。Java 服务端调用富查询时把查询字符串放进链码方法参数走 EVALUATE 交易即可不要用 SUBMIT。4. 用Java技术打通多机构电子病历共享患者主索引、文档加密与Gateway接入4.1 患者主索引EMPI在 Java 服务端的映射方案同一位患者在 A 医院是内科建档id1001在 B 医院是影像编号8899如何证明是同一人患者主索引就是解决这个问题的。纯中心库统一分配全局患者 ID 的模式接入成本高我推荐“映射表 脱敏哈希”双轨每个机构保留自己的本地患者 IDJava 服务端把证件号脱敏后做 SHA-256 加盐哈希生成patientHash映射表存localPatientId、orgId、patientHash展示给链码和前端时只用哈希不落明文。CREATE TABLE patient_mapping ( id BIGINT PRIMARY KEY AUTO_INCREMENT, org_id VARCHAR(64) NOT NULL, local_pid VARCHAR(64) NOT NULL, patient_hash CHAR(64) NOT NULL, UNIQUE KEY uk_org_local (org_id, local_pid), KEY idx_hash (patient_hash) ) COMMENT 跨机构患者主索引映射表;这个表不建在各医院而放在共享平台 Java 后端的主索引服务里。跨院查询流程是请求方传来证件号服务端重算哈希到patient_hash索引上查到各机构 ID再携patientHash去区块链查询病历台账。UNIQUE KEY uk_org_local很重要同时约束org_id和local_pid防止医院内部系统迁移、数据重导后同一本地 ID 出现两条映射导致追踪关系错乱。哈希盐值不要写死在代码里用配置中心下发并定期轮换。4.2 病历文档双加密链下 AES 密文与链上密钥信封链上只存哈希和授权状态peer 节点即使被拖库对方也拿不到病历内容。实际出库的病历文件常见做法是混合加密Java 文件服务为每份病历生成 256 位随机 DEKData Encryption KeyDEK 用 AES-256-GCM 加密病历文件正文密文落对象存储DEK 再用目标机构公钥做 RSA 或 SM2 加密得到密钥信封授权机构从链上取信封用自己的私钥解出 DEK再解密文件。这个方案必须接受一个事实授权撤销只影响新查询已发出的历史信封收不回来。因此每次出库前 Java 服务必须重新查链上consentStatus和expireAt不能因为上一次授权有效就跳过校验。下面这个校验函数是整个链路里最容易放水的地方public boolean verifyRecordChecksum(String fetchedFileHash, String chainRecordHash) { if (fetchedFileHash null || !fetchedFileHash.equalsIgnoreCase(chainRecordHash)) { throw new SecurityException(病历文件哈希不一致禁止出库); } return true; }不要小看这个函数。对象存储下载返回的是 302 临时 URL 还是直链文件流边下载边校验还是整个下载完再校验都可能成为哈希校验被绕过的入口。建议把这段逻辑和 4.3 节的 Gateway 连接参数写进配套开发资料的《安全校验对照表》上线前逐条打勾。4.3 Fabric Java Gateway 接入超时、重试与连接配置参数Java 服务端连 Fabric 用的是fabric-gateway-java典型写法是先加载 X.509 身份和连接配置文件再构造 Gateway 单例Path certPath Paths.get(crypto/hospital-a/admin-pub.pem); Path keyPath Paths.get(crypto/hospital-a/admin-key.pem); Identity identity new X509Identity(HospitalAMSP, Identities.readX509Certificate(certPath), Identities.readPrivateKey(keyPath)); Gateway gateway Gateway.createBuilder() .identity(identity) .networkConfig(Paths.get(connection-profile-hospital-a.yaml)) .evaluateOptions(Options.withTimeout(10, TimeUnit.SECONDS)) .commitOptions(CommitOptions.withTimeout(20, TimeUnit.SECONDS)) .connect(); Network network gateway.getNetwork(medshare-channel); Contract contract network.getContract(emrcc);三个与生产直接相关的参数说明evaluateOptions控制查询EVALUATE的 gRPC 超时。病历列表类接口建议 10 秒起步太短遇到网络抖动时前端直接转圈太长又会拖垮线程池commitOptions是背书、排序、上链确认的总回包时间写授权这类交易设 20 秒比较现实。实际压测中 5 秒超时经常出现“点完授权还在排队、客户端先报错”的现象connection-profile 里的hostnameOverride和tlsCACerts字段不能省。Fabric CA 签发的证书 SAN 写的是服务名不填 overrideJava 进程握手阶段就报证书校验失败。顺带提一个代码管理习惯Fabric CA 的根证书、admin 私钥这类敏感文件应当由部署脚本从环境变量注入路径生成不能提交进 Git 仓库。仓库里只保留.env.exampleCI 流水线生成真实文件能省掉大多数上线前的安全评审返工。4.4 背书策略让对方医院背书也让监管节点看到共享动作默认背书策略AND(HospitalAMSP.peer,HospitalBMSP.peer)要求双方 peer 都背书。电子病历共享场景更常写成AND(HospitalAMSP.peer, HospitalBMSP.peer, RegulatorMSP.peer)监管节点只参与背书不干预医院内部业务但任何跨院共享交易都会经过它留存背书痕迹审计时可以追溯到具体请求方和授权链条。注意背书节点与 Orderer 不要单机共置尤其是上线前的开发环境拉通问题方便不等于生产环境可以妥协。5. 区块链电子病历共享平台配套开发资料从单测到部署排错5.1 链码单元测试用 MockStub 预置状态链码写完不要马上起网络先用 fabric-chaincode-java 自带的MockStub在 JVM 里把状态流转测通。每个合约配一个测试类在BeforeEach里提交一条 SUBMITTED 记录再分别测授权正常流转、重复授权、过期查询三条路径MockStub stub new MockStub(emrcc, new EmrContract()); stub.mockInvoke(tx1, submitRecord, EMR-TEST-001, patienthash001, hospital-a, hash-abcd); String authKey (String) stub.mockInvoke(tx2, grantAccess, EMR-TEST-001, HospitalBMSP, 2025-12-31T23:59:59Z) .getPayload();MockStub 不依赖真实 peer测试跑在 CI 的普通 Java 构建里。可以把第 3.3 节的身份校验单独抽成一个工具类单测里伪造 MSP ID 覆盖异常分支这是链码质量最便宜的保险。5.2 配套开发资料该包含的三张表配套资料的“配套”价值在于统一口径让新接手的人不看源码也能排错。我一般会沉淀三类表表名覆盖内容解决的上线问题链码接口说明每个接口的入参、出参 JSON 示例、背书策略、权限要求调用方联调时参数漏传部署命令清单test-network 起链、安装链码、配置通道的命令与预期输出环境一换就起不来Java 服务端配置字典数据源、对象存储、Fabric 连接相关的环境变量说明换库换证书后调试耗时编写时注意接口说明里把状态字段的可选值全部列出并标明谁在什么条件下把状态切到下一个值。状态机不写清楚联调阶段一半的群里提问都和状态对不上有关。5.3 上线前最低限度的验证命令最后一条验证命令值得写进部署手册peer chaincode query -C medshare-channel -n emrcc \ -c {Args:[queryRecord,EMR-2024-00831]}如果 peer 命令能查到链上 JSON但 Java 接口超时 504第一排查优先级是证书路径与 connection-profile 的 peer 地址不匹配。先运行openssl x509 -in admin-pub.pem -noout -subject确认证书签发机构再比对 yaml 里的tlsCACerts是否指向同一根证书。这两个值对上以后504 基本会消失如果仍然存在再检查commitOptions超时与 OrdererBatchTimeout之间的量级关系调低出块等待窗口而不是无限加大客户端超时。本文还有配套的精品资源点击获取