一、背景：医保结算为何走向“刷脸”
医保就医购药的身份核验介质，大致经历了三个阶段的演进：
- 实体卡阶段：医保卡作为唯一凭证，存在易忘带、易丢失、易转借的问题，而转借直接带来冒用就医、基金流失的风险。
- 电子凭证阶段：医保码将身份凭证搬到手机上，缓解了“忘带卡”的问题，但仍依赖手机电量与应用可用性，对不熟悉智能手机的老年群体并不友好。
- 生物识别阶段：以人脸识别为核验手段的医保刷脸终端，把“凭证”彻底收归“本人”——脸即是凭证，实现无介质、强实名、秒级核验。
从风控视角看，刷脸的本质价值在于将“持有凭证”升级为“证明本人”：卡可以被捡到、码可以被截图，而配合活体检测的人脸核验几乎无法被转借，从源头压缩了冒用就医的空间。
二、核心工作原理
2.1 三要素：可信终端 + 医保码 + 双因子核验
医保刷脸支付体系可以拆解为三个关键要素：
- 统一管理、统一认证的终端载体。刷脸终端属于医保业务综合服务终端的一种，由国家医保主管部门统一管理与统一认证。这意味着设备的准入、安全能力、接入规范均有统一约束，从源头上保证“采集人脸的这台机器”是可信且受控的。
- 以医保码为媒介的身份体系。医保码是参保人的线上电子身份凭证。刷脸终端并非孤立地“认脸”，而是把现场采集的人脸特征，映射到医保码背后的参保身份与个人账户上，完成“线下人脸—线上账户”的打通。
- “生物识别 + 实名认证”的核验技术。人脸生物特征回答“操作者是不是活人本人在场”，实名认证回答“这个人在医保系统里对应哪一位参保人”。两者结合，才把一张脸与一个医保身份、一个个人账户可靠地关联起来。
2.2 身份核验链路拆解
一次完整的刷脸核验，技术上通常包含以下环节：
- 图像采集与质量检测：终端摄像头采集人脸图像，先做质量判断——光照是否充足、人脸是否完整、姿态角度是否过大、清晰度是否达标。质量不达标会在前置环节直接拦截，避免无效比对。
- 活体检测：判断镜头前是真实人脸而非照片、屏幕翻拍或面具，是防伪造攻击的关键闸门。
- 特征提取：将人脸图像转换为高维特征向量。比对与存储均基于特征值进行，而非原始照片，这本身就是一层隐私保护。
- 特征比对：分两种模式：
- 1:1 比对：已知身份（如激活时输入了身份证号），将现场人脸与权威留底照片比对，确认“人证一致”；
- 1:N 检索：仅刷脸、不输入证件号，在已建立关联的特征库中检索最相近的参保人，确认“这张脸对应哪个账户”。
- 结果返回与授权：核验通过后，终端获得该参保人的授权上下文，随后调起费用结算与个人账户扣减。
2.3 首次激活与日常使用
首次使用：参保患者需在刷脸终端上输入身份证号码，并现场完成人脸采集。系统执行“人证 1:1 比对”，通过后将“证件号—人脸特征—医保个人账户”三者绑定，完成刷脸认证激活。这一步的本质是建立 1:N 检索所需的信任锚点——没有这次实名绑定，后续“只刷脸不亮证”便无从谈起。
后续使用：由于绑定关系已经建立，参保人到医药机构就诊购药时无需再次激活，直接刷脸即可完成身份核验与结算授权，实现“刷脸就医购药”。
三、端到端技术架构
从开发者视角，整体链路可划分为四层：
- 终端层：包含摄像头（常见方案为可见光摄像头叠加红外双目，部分硬件采用 3D 结构光以增强活体能力）、触摸屏与语音交互模块、身份证号输入组件，以及用于密钥保存与报文签名的内置安全模块。
- 接入层：终端与平台之间通过加密通道通信，终端需先完成设备级准入认证（证明“这是台经过认证的合法终端”），业务报文附加签名与时间戳以防篡改、防重放。
- 服务层：包括人脸核验服务（质量检测、活体、特征比对）、身份与账户服务（医保码体系、个人账户）、结算引擎，以及识别高频失败、异地异常等可疑模式的风控引擎。
- 数据与审计层：人脸特征库加密存储，全链路操作留痕，日志支持审计追溯。
[终端层] 摄像头 / 屏幕 / 输入组件 / 安全模块 │ 设备准入认证 + 加密通道 + 报文签名[接入层] 通道加密 · 防篡改 · 防重放 │[服务层] 人脸核验 ── 身份与账户 ── 结算引擎 │ └──── 风控引擎[数据层] 特征库(加密) · 审计日志 · 脱敏归档
四、安全与隐私保护设计
4.1 活体检测：对抗伪造的第一道闸门
常见攻击手段包括打印照片、屏幕翻拍视频、立体面具等，业界通用的防御思路是多模态融合：
- 交互式配合：随机指令眨眼、张嘴、转头，抬高攻击成本；
- 红外/双目成像：利用真实皮肤与平面介质在红外光谱下的成像差异，识别纸张与屏幕；
- 3D 结构光：获取人脸深度信息，对抗平面照片与屏幕攻击；
- 静默活体：通过多帧图像的光影与微纹理变化判断真伪，无需用户配合，体验更顺滑。
工程上通常将多种手段级联或融合评分，在安全强度与通过率之间取得平衡。
4.2 数据最小化与特征保护
- 以特征值代替原始图像：比对与绑定基于不可逆的人脸特征向量进行，原始影像在完成采集与提取后即可删除或加密归档，降低泄露后的风险敞口；
- 加密存储与传输：特征数据落盘加密，链路采用强加密协议，密钥由终端安全模块保管；
- 授权与留存管理：明确告知采集目的与留存期限，提供解绑途径，遵循个人信息保护相关法律法规要求。
4.3 链路与运营安全
- 终端可信：设备统一认证、密钥内置，防止伪冒终端混入采集链路；
- 报文防重放：请求携带时间戳与随机数，服务端校验有效窗口；
- 风控与审计：对高频失败、异地并发、异常时段等模式实时监测，触发限流或人工复核，全部操作留痕可审计。
4.4 体验兜底：合规与可用性的平衡
生物识别不应成为唯一通道。稳妥的方案会保留扫码、刷卡等替代核验方式，作为刷脸失败（光照异常、面部特征变化等）时的降级路径，既保障业务连续性，也尊重不愿使用生物识别的用户的选择权。
五、关键流程示意
以下为流程说明用的示意代码，非真实接口定义：
# 首次激活（1:1 人证比对 + 绑定）function activate(patient): id_number = input("请输入身份证号") frames = camera.capture(frames=8) assert quality_check(frames) # 光照/姿态/清晰度前置校验 assert liveness_detect(frames) == PASS # 活体检测 assert verify_id_face(id_number, frames) == PASS # 人证 1:1 比对 bind(id_number, extract_feature(frames), account_of(id_number)) return ACTIVATED# 日常使用（1:N 检索 + 结算授权）function pay_by_face(): frames = camera.capture() assert liveness_detect(frames) == PASS identity = search_account(extract_feature(frames)) # 1:N 检索 if identity is None: fallback_to_qrcode() # 降级兜底 return authorize_settlement(identity)
终端上报的核验请求（仅示意字段语义）：
{ "scene": "medical_settlement", "terminal_id": "<经统一认证的终端编号>", "liveness": "PASS", "face_feature_cipher": "<加密后的特征数据>", "nonce": "<随机数防重放>", "timestamp": 1730000000, "sign": "<终端密钥签名>"}
六、部署与运维实践要点
- 环境适配：终端应部署在光照均匀、避免逆光与强反光的位置，摄像头高度与俯仰角贴合站立者的自然视线；门诊大厅等嘈杂环境建议配合语音引导。
- 网络可靠性：结算链路对可用性敏感，建议冗余网络出口，并设计弱网/断网下的降级策略（如引导走扫码通道）。
- 可观测性：在云上部署场景中，可借助云平台通用的日志服务、监控告警等能力，对核验成功率、活体通过率、接口时延等指标建立看板与阈值告警，例如基于百度智能云的日志与监控类产品构建统一观测面。
- 适老化与无障碍：界面大字化、语音播报、简化交互步骤；对行动不便或面部特征变化较大的人群，保留人工与替代核验通道。
- 密钥与设备管理：终端密钥定期轮换，设备生命周期（注册、启用、停用、注销）全程管理，防止失窃终端成为攻击入口。
七、常见挑战与应对
- 光照与角度干扰：多帧采集 + 质量前置校验过滤低质量样本，部署阶段做好补光；
- 相似人脸误识：比对阈值分级设置，低置信度结果叠加补充校验或转人工处理，避免“便捷”侵蚀“准确”；
- 面部特征随时间变化：提供便捷的重新激活与信息更新机制，保证特征库与本人当前状态一致；
- 公众隐私顾虑：以显著方式告知采集目的与保护措施，公开替代核验方式，用透明换取信任。
八、结语
医保刷脸终端是医保服务“无介质化”的代表性形态：以统一认证的可信终端为载体、以医保码为身份媒介、以“生物识别 + 实名认证”为核验内核，把一张脸可靠地映射到一个参保身份与个人账户。对技术团队而言，落地的关键不在于“能不能识别人脸”，而在于四件事：链路可信、活体可靠、数据合规、体验有兜底。把这四点做扎实，刷脸才能既便捷又安全地成为日常就医购药的基础设施。