请上传宽度大于 1200px,高度大于 164px 的封面图片
    调整图片尺寸与位置
    滚轮可以放大缩小图片尺寸,按住图片拖动可调整位置,多余的会自动被裁剪掉
取消
四月fighting(uid:385953)
职业资格认证:FCA-FineReport | FCA-FineBI | FCP-业务分析师
【2022BI数据分析大赛】工业制药-临床试验质量管理之稽查分析
Your browser does not support video tags. 一、选手简介 1.1 团队介绍 团队名称:临床数据BI小队 成员介绍: 队长白洋,就职于位列全国医药研发行业Top10的XXX制药集团。本人目前从事于临床试验全流程业务数字化、可视化及商业决策数据分析领域,负责事业部临床试验智能决策分析平台构建,是事业部数字化转型项目倡导者与负责人。 成员四月,就职于位列全国医药研发行业Top10的XXX制药企业,9年医药从业经验,精通数据仓库需求分析、建模、ETL等,擅长复杂的问题清晰化、简单化。 成员赵云,就职于位列全国医药研发行业Top10的XXX制药企业,5年临床试验相关工作经验,非常熟悉临床相关业务流程,擅长业务梳理、跨部门对接。   1.2 参赛初衷 随着全民数字化浪潮的兴起,“大数据分析助力业务发展”的理念也在临床试验领域得以扩散,目前众多的临床研究数字化产品还是专注于单个项目的数据,并未站在全流程及公司整体层面进行数据呈现与分析。我们BI小组因此应运而生,旨在深入探讨和挖掘临床数据与临床试验整体运营背后的商业价值。 参加此次比赛的作品,是临床试验质量管理体系里某一重要环节的应用场景;希望通过比赛与更多的医药同行交流探讨,学习各位大神的方法及思路,同时提升团队整体的数据分析能力。   二、作品介绍 2.1 业务背景/需求痛点 创新药研发、开发自主知识产权新药是传统制药企业保持市场竞争力、可持续发展的根本。为此,国内外的龙头制药企业均投入大量的资源用于药物研发。 新药研发的特点是涉及的环节多、研究严谨,一般耗时10-15年,耗资可达数十亿美元,临床试验是其中最重要的一环。临床试验每一环节的开展,都需要严格遵循国际标准的法律法规,容不得一丝纰漏。 国家药品监督管理局药品审评中心制定的GCP2003版的规定:申办者应建立对临床试验的质量控制和质量保证系统,可组织对临床试验的稽查以保证质量。药品监督管理部门、申办者可委托稽查人员对临床试验相关活动和文件进行系统性检查,以评价试验是否按照试验方案、标准操作规程以及相关法规要求进行,试验数据是否及时、真实、准确、完整地记录。 我公司作为药物研发的申办方,成立了专门的质量管理部,制定完善的SOP,针对临床试验涉及的所有研究中心或者供应商,随机抽取一个或多个进行临床试验过程质量的核查。通过记录成百个检查项标准的稽查数据,及时地评价试验过程质量,发现潜在风险,以保证试验质量,促进临床试验的顺利开展及风险规避。 稽查工作的流程如下: 图0-1:稽查工作流程   目前质量管理部在实际的工作过程中,存在如下迫切需要解决的问题: (1) 稽查数据分散在各个稽查员手里,没有统一管理; (2) 数据的收集和统计,仍然依赖于大量的人工上报及Excel统计,每次出报表都需要专人花费大量时间来重新规整和更新,效率极低; (3) 稽查过程及结果数据并没有得以有效的发掘,希望能够与项目、产品、中心等建立整体的联系; (4) 各QA(稽查员/审核员)的稽查效率、工作量分布无法得到有效的数据支撑; (5) 稽查出的问题分布及相关原因,单从Excel里无法得到有效的分析。 (6) 各任务环节一直无法得出合适的限定标准/评定标准。 针对问题项(1)和(2),通过简道云的流程梳理和数据收集,得以解决;对于数据的分析,则需要依托于数据仓库和FineBI来解决。   2.2 数据来源 本次参赛使用了企业数据。团队成员对公司数据做了脱敏处理,最终确定使用DM层的3张数据表。 分别是:稽查基本信息数据集、稽查质量问题数据集、稽查执行人员数据集。 本参赛作品计划针对以下分析角度: 1. 宏观指标; 2. 稽查类别及发现项统计; 3. 撰写稽查报告时效分析; 4. 稽查部门内人员贡献分析; 5. 稽查质量分析-项目维度; 6. 稽查质量分析-研究中心维度。      2.3 分析思路 2.3.1 核心指标体系搭建 本次参赛我们选择了临床试验稽查这个应用场景。相应的分析视角包含:团队内贡献分析、稽查过程整体时效分析、稽查质量分析。 分析框架与问题的拆解思路分别如下图1-1、图1-2所示。 图1-1:临床试验质量稽查框架     图1-2:问题拆解思路 这里以稽查时效分析为例,进行分析体系搭建说明: 1. 指标拆解,这里设计了3个指标,计算方法分别如下: 稽查时长 =结束时间-开始时间; 报告发布时长 =发布时间-结束时间; 是否按时关闭=计划时间-实际时间 2. 维度细分:稽查类别、时间纬度(年度/月度)。 3. 数据口径定义。 4. 全面检查复核所有指标的口径和维度,并确定更新周期。 说明:稽查大类分为4种:TMF稽查、中心稽查、供应商稽查、药品稽查,每种大类下各有细分的子类和明细项。   分析体系如下图所示: 图1-3:分析体系(稽查时效) 同理,可以对成员贡献、稽查质量进行分析体系搭建。此处不再赘述。   2.3.2 看板模块结构 以稽查全局看板为例: 整个数据看板可以分为两个部分,共计6个模块,各个模块拆分出不同的分析角度,如下图所示: 图1-3:看板架构 本次呈现的数据均为公司XXXX-XXXX年临床试验稽查数据,数据已脱敏处理。   2.4 数据处理 2.4.1 DM层数据集 由ODS层数据、EDW层数据制作用于看板使用的DM层数据集。 ODS层存储通过接口程序从多个应用系统抽取基础数据,在EDW层对数据进行清洗、转化、筛选、连接、汇总等操作,汇总成稽查基础信息数据集、稽查角色信息数据集、稽查质量数据集,并专门整理了某些专用数据集。 数据处理过程均使用Mysql数据库,编写存储过程,自动化运行生成最终数据集,并存放在数据仓库DM层。   2.4.2 维度与度量值 根据上文的分析架构体系,确定明确的数据指标及相关维度。   通过多个维度的交叉、联动,分析出相关指标的变化趋势,并依据历史数据分析因果,从而为相关业务人员制定合理的应对策略,持续、良性地提升临床试验质量。   2.5 可视化报告 2.5.1 看板整体布局 (1) 模块1:宏观指标展示 图2-1:宏观指标模块 宏观指标默认显示为总量,比如总稽查次数,总发现项数,总例次数等等。 本模块最右边设置了一个文本过滤组件(稽查年份),便于产生数据联动,展示出相应年份的宏观数据指标。   (2)模块2:稽查类别及发现项统计 图2-2-1:稽查类别及发现项统计模块 图2-2-2:稽查类别及发现项统计模块 图2-2-3:稽查类别及发现项统计模块 图2-2-4:稽查类别及发现项统计模块 此模块使用了7个组件: 组件1:柱状图中,展示了1个指标(总稽查次数、未关闭次数、延误次数),1个维度 (稽查年月)。 组件2:散点图,展示了2个指标(整改时长、延误时长),2个维度 (是否延误、稽查类别),4条警戒线(是否延误、延误均值、整改均值、整改上限)。 组件3:词云图中,展示了1个指标(每类延误原因统计数),1个维度 (延误原因)。 组件4:分区柱状图中,展示了2个指标(稽查次数、发现项数),1个维度 (稽查类别)。 组件5:饼图,展示了1个指标(发现项数),1个维度 (问题严重等级)。 组件6:雷达图中,展示了1个指标(稽查时长均值),1个维度 (稽查类别)。 组件7:堆积柱状图中,展示了3个指标(发现项数、例次、例次/发现项),2个维度 (发现项大类、问题严重等级)。   (3)模块3:撰写稽查报告时效分析 图2-3:撰写稽查报告时效分析模块 此模块使用了3个组件: 组件1:柱状图中,展示了1个指标(报告发布时长),2个维度 (稽查类别、稽查唯一标识),1条警戒线(撰写平均时长)。 组件2:散点图中,展示了2个指标(延误天数、发现项数),3个维度 (稽查唯一编号、稽查类别、例次),2条警戒线(平均发现项数、平均延误天数),1条拟合线。 组件3:散点图中,展示了2个指标(整改时长、发现项数),3个维度 (稽查唯一编号、稽查类别、例次),2条警戒线(平均发现项数、整改均值),1条拟合线。   (4)模块4:稽查部门内人员贡献分析 图2-4:稽查部门内部人员贡献分析模块 此模块使用了2个组件: 组件1:对比柱状图中,涉及1个指标(稽查次数), 2个维度(稽查角色、稽查人员)。 组件2:散点图中,涉及2个指标(稽查员次数,审核员次数), 1个维度(稽查人员唯一标识符),2条警戒线(稽查员次数均值,审核员次数均值)。   (5)模块5:稽查质量分析-项目维度 图2-5-1:稽查质量-项目维度模块 图2-5-2: 稽查质量-项目维度模块 此模块使用了5个组件: 组件1:分区柱状图中,展示了4个指标(稽查次数、发现项数、例次、例次/发现项数),1个维度 (项目)。 组件2:组合条状图中,展示了2个指标(发现项数、发现项数累计),1个维度 (项目编号),1条警戒线(80%发现项累计警戒线)。 组件3:组合条状图中,展示了2个指标(例次、例次累计),1个维度 (项目编号),1条警戒线(80%例次累计警戒线)。 组件4:组合条状图中,展示了2个指标(工时消耗、工时消耗累计),1个维度 (项目编号),1条警戒线(80%工时消耗累计警戒线)。 组件5:条状图中,展示了1个指标(例次/发现项),1个维度 (项目编号),1条警戒线(例次/发现项均值)。   (6)模块6:稽查质量分析-研究中心维度 图2-6: 稽查质量-研究中心维度模块 此模块使用了4个组件: 组件1:分区柱状图中,展示了4个指标(稽查次数、发现项数、例次、例次/发现项数),1个维度 (研究中心)。 组件2:条状图中,展示了1个指标(发现项数),2个维度 (项目编号、中心名称)。 组件3:条状图中,展示了1个指标(例次),2个维度 (项目编号、中心名称)。 组件4:条状图中,展示了1个指标(例次/发现项),2个维度 (项目编号、中心名称)。   2.5.2 可视化分析 2.5.2.1 概况 宏观指标体现稽查工作的汇总数据,包含稽查次数、发现项(即检查项)数量及类别、涉及的项目数、中心数、参与人员等等,整体层面的数据一目了然。 这些宏观指标会伴随过滤组件的变动产生数据联动。 图3-1:宏观指标呈现   2.5.2.2 稽查类别及发现项统计 下图3-2-1,按年度/月度的维度统计了总稽查次数/延误次数/未关闭次数,表明每一年度各月份工作量、是否延误、是否已关闭等信息。 可便于质量管理部在新一年年初时借鉴历史年度中工作量分布,来预测全年工作计划。 图3-2-1:稽查类别及发现项统计模块-稽查次数年度分布   下图3-2-2,使用波士顿矩阵分析法探索了延误时长与整改时长的内在联系,初步表明延误时长与整改时长呈线性关系。 后期可进一步探索影响整改时长的因素,优化出标准整改时长。 同时展示了延误原因词云图,展示造成延误的原因。从中我们可以看出最突出的几点延误原因,针对性地找出改进办法。   图3-2-2:稽查类别及发现项统计模块   下图3-2-3,展示了3部分内容: 左图展示了不同类别稽查,稽查次数与发现项统计量展示。图中可看出稽查次数/发现项都集中在中心稽查这一稽查类别,符合帕累托模型(25%的稽查类别工作量占比总工作量的80%),说明试验稽查工作重心在中心稽查这一稽查类别。 中图展示了问题严重级别分布,表明96%属于轻微类,后期可以根据三者占比刻画反应该中心稽查质量的相关度量指标。 右图雷达图展示了每一类稽查类别平均耗时,后期可刻画每类稽查安排时长的合理程度。 图3-2-3:稽查类别及发现项统计模块   下图3-2-4,展示各问题主类中产生的发现项、例次、例次/发现项3个指标分布。 后期可进一步分析,是否符合帕累托模型,然后着重解决那些产生80%发现项、例次的20%主类,快速提升临床试验稽查质量。 图3-2-4: 稽查类别及发现项统计模块   2.5.2.3 撰写稽查报告时效分析 下图3-3,展示了3部分内容: 上图展示了每次稽查报告撰写时长,且使用稽查类别作为颜色区分不同的稽查类别。同时添加了撰写时长均值警戒线,能够方便查看异常值,也能查看每次稽查撰写时长在均值附近的波动,据此制定每类稽查撰写报告标准时长。 左下图使用波士顿矩阵分析法,探索了延误时长与发现项数量的内在联系,初步表明延误时长与发现项数量呈线性关系。后期进一步探索发现项多、但延误较少的稽查,学习经验,优化标准整改时间。 右下图使用波士顿矩阵分析法,探索了整改与发现项数量的内在联系,初步表明整改时长与发现项数量也是呈线性关系。后期进一步探索发现项多、但整改较少的稽查,分析原因,优化标准整改时间。 图3-3: 撰写稽查报告时效分析模块     2.5.2.4 稽查部门内人员贡献分析 下图3-4,展示了2部分内容: 左图展示质量稽查部门各人员的贡献,从中可以发现主力员工。整体部门的工作量分布还是很集中的,主力员工承担了大部分工作。 右图展示质量稽查部门各人员的贡献象限图,该象限图可以作为团队绩效管理的参考,调整每一象限人员的职级、全年分工等,来优化团队,提升团队战斗力。 图3-4: 稽查部门内部人员贡献分析模块     2.5.2.5 稽查质量分析-项目维度 下图3-5-1,展示了各项目的4个度量指标(稽查次数、发现项、例次、例次/发现项),可以综合衡量各项目的稽查质量。 后期可以通过这些指标刻画一个项目的稽查质量整体情况。 图3-5-1: 稽查质量-项目维度模块   下图3-5-2,左3张图使用帕累托模型,分别从发现项、例次、工时去分析贡献80%(发现项、例次、工时)分别涉及到哪些项目,从中找到值得重点关注的项目。 右图衍生了KPI指标(例次/发现项),并降序排序,可分析各项目的发现项和例次的情况。排名第一的这个项目,说明存在很多的问题,需要增加稽查力度,比如增加稽查次数、扩大稽查的范围。   图3-5-2: 稽查质量-项目维度模块   2.5.2.6 稽查质量分析-研究中心维度 下图3-6,上半部分展示了各研究中心的4个度量指标(稽查次数、发现项、例次、例次/发现项),可以综合衡量各中心的稽查质量。后期可以通过这些指标刻画一个中心的稽查质量整体情况。 下半部分分别从发现项、例次、衍生KPI指标(发现项/例次)3种角度,以项目+中心组合为细粒度,对TOP10的医院重点展示,以便引起足够的重视。 图3-6: 稽查质量-研究中心维度模块       整体仪表盘图片: 03-工业制药-临床试验质量管理之稽查分析.pdf (1.46 M)       2.5.3 总结 此看板中,涉及项目维度(项目/中心)、人员维度(团队成员/角色)、稽查维度(稽查类别、是否延误、问题严重级别、发现项大类、延误原因、稽查唯一标识符)三大维度,10个细分,同时包含8个宏观指标。 看板的结构比较简单,没有采用过于花哨的图表,目的还是在于降低用户的学习成本,让用户能够清晰明了地获取到关键信息点。 看板交付之后,受到了业务部门的高度赞赏,反馈说除了给他们提供了精准的统计数据、减少工作压力之外,对于数据的挖掘和分析角度也给他们的管理提供了更开阔的思路。当然从团队自身来说,由于对于稽查相关业务的深度理解不够,还存在很大的提升空间。 希望能在此次大赛中学习到更多分析思路,去提升团队对BI系统的掌握及制作报告的能力,同时为后边去构建项目/中心/稽查多层次的质量稽查评测模型、稽查团队战斗力评测模型等打下坚实的基础。   三、参赛总结 3.1 FineBI工具 觉得比较好用的BI亮点功能如下: (1)Tab组件,能够很好地控制看板的长度。 (2)联动功能,能够很容易的实现数据联动。 (3)复用/复制功能,能够很大程度上节省看板设计的时间。 觉得不太人性化的地方如下: (1)警戒线不能自定义构造公式,期待后边可以实现自定义警戒线。 (2)能否将简道云的数据工厂模块集成到BI,增强BI的ETL功能。 (3)提示信息有覆盖,比如气泡图中,大气泡覆盖小气泡,则小气泡提示信息不能展示。 对数据分析价值的思考如下: (1)数据分析应用场景:数据监测、数据预测、数据检测。 (2)数据分析四维空间:人、货、场、时间。 (3)四大结论: 维度越低、检测越容易; 高维度的检测就要向低维度去拆解; 检测的方法就是先往下拆分,再左右比对; 要判断检测结果的正确性,需要从低维度,再回到高维度。 3.2 参赛总结 经过一年的数据沉淀和技术沉淀,相对于去年的参赛作品,今年我们团队的作品从分析思路、图表展现方面都有所提高。 当然,我们在进步,从事数据分析工作的同行们也在进步,从今年同学们提交的越来越多让人眼前一亮的作品能够看出,默默深耕的人越来越多了(“卷”起来!)。 比赛是最快速的成长方式,我们会与大家一起,沉下来打造我们自己的竞争力,与帆软一起向未来!  
【2021夏季挑战赛】工业制药-临床试验里的大数据分析
一、选手简介 1.1 团队介绍 团队名称:临床数据BI小队 成员介绍: 队长白洋,目前就职于位列全国医药研发行业Top10的XXX制药公司,从事临床试验商业数据分析工作。个人感兴趣的方向和领域:如何帮助传统制造企业实施数字化转型,以数据资产,驱动企业业务优化。 成员四月,就职于位列全国医药研发行业Top10的XXX制药公司,8年药企从业经验,精通数据仓库需求分析、建模、ETL等,擅长复杂的问题清晰化、简单化。 成员赵云,就职于位列全国医药研发行业Top10的XXX制药公司,5年临床试验相关工作经验,非常熟悉相关业务流程,擅长应用系统业务梳理及跨部门对接。 1.2 参赛初衷 目前大数据分析并未系统化的在临床试验领域大规模应用,公司成立数据BI小组,希望通过搭建数据仓库,整合数据,借助FineBI可视化工具,向领导及同事展示深挖临床数据的潜力,及临床试验整体运营背后的商业价值。 参加此次比赛的作品,是我们初步做出的样稿,希望能够提升团队的数据分析能力,学习各位大神的方法及思路,改进我们的不足。 二、作品介绍 2.1 业务背景/需求痛点 创新药研发、开发自主知识产权新药是传统制药企业保持市场竞争力、可持续发展的根本。为此,国内外的龙头制药企业均投入大量的资源用于药物研发。 新药研发的特点是涉及的环节多、研究严谨,一般耗时10-15年,耗资可达数十亿美元,临床试验是其中最重要的一环。近年来,我公司创新药临床试验项目逐年增多,由最开始的几个项目增至一百多个,公司投入也逐年加大,传统的人工管理方式存在进度管控延后、信息更新不及时、过程管理不规范等弊端,浪费大量人力、物力、财力。 为改善管理局面,研发部门开始使用相关的数据应用系统,包括IRT(随机系统)、EDC(临床数据管理系统)、CTMS(项目管理系统)等应用系统。但这些系统的运用存在如下3个主要问题: 数据使用不充分:系统生成的数据仅仅作为证据,用以撰写临床试验总结报告,在新药完成试验后递交给国家药监局审查,没有做进一步的延展使用。 数据孤立分散:各个系统以项目为范畴,独立开展,项目数据分散存在于各个项目组里。 无法统一管理:以上系统均为SaaS架构,数据分散存储于不同系统供应商的平台上,没有本地化,无法实现统一管理。 而实际上,这些数据的背后隐藏着每一类试验的关键节点、进度、受试者质量、财务花费是否合理等等信息,覆盖到临床试验运营的方方面面。数据的价值,并没有得以充分的挖掘。如果能够成体系的将这些数据沉淀下来、标准化,对于类似我公司这样创新型药企来说,将大大提升临床试验的运营效率,节省研发成本,真正地用数据创造财富。 我们要做的就是要打破临床试验各应用系统的数据壁垒,结构化、流程化、成体系的将临床试验相关数据沉淀下来,搭建数据仓库,制定数据相关标准,进一步服务于临床试验的运营,挖掘临床试验数据的商业价值。 2.2 分析思路 本次选取了临床试验过程中的【受试者】环节作为切入点,其涉及的业务逻辑较为简单,且受试者支出是研发费用的重要组成部分,是高层领导重点关注的。 本参赛作品计划针对以下几个问题进行设计与分析: 宏观指标看板,计划针对7个宏观指标(产品数/项目数/大区数/省份数/中心数/医院数/总样本量) 从治疗领域、研发类型、产品分类、申办方、试验分期等项目维度视角分析指标; 从地理纬度、产品维度结合项目维度,多层次分析某个核心指标。 2.2.1 核心指标体系搭建 业务流程上,临床试验中受试者的入组是重要节点。整个试验过程里,受试者需要参与的环节包含签署知情同意书、对受试者按照试验标准进行筛选、受试者随机入组(即开始服用试验药物)、受试者用药期间进行访视、异常出组、完成研究。 本次参赛我们提取了3个重要节点,分别是:参与筛选、随机入组、异常出组(即脱落)。 相应的核心指标分别为:筛败率(入组率)、达成率(差值)、脱落率。 由此延伸出2个指标:入组率、贡献度。 - 达成率=实际入组人数/计划入组人数; - 筛败率=筛选失败人数/参与筛选人数; - 入组率=实际入组人数/参与筛选人数; - 脱落率=异常退出人数/实际入组人数; - 贡献度=实际入组人数/项目样本量 2. 我们计划选取3个维度,分别是:地理纬度、项目维度、产品维度。每个维度均可进行不同层级的下钻。 - 地理纬度(中心/省份/大区) - 产品维度(项目/产品) 说明:产品与项目是一对多的关系,即一个产品(药物)可能会针对不同的病症开展多个项目。 - 项目维度(治疗领域/研发类型/项目类别/申办方/试验分期) 2.2.2 确立【维度-核心指标】模型 通过多个维度的交叉、联动,分析出相关指标的变化趋势,并依据历史数据预测未来一段时间内的数据,从而为相关业务人员制定合理的应对策略,持续、良性地推进相关项目进度。 2.2.3 模型示例 这里以筛败率为例展示模型: 指标拆解:筛败率=筛选失败人数 /筛选总体人数。 维度细分:项目维度(产品/项目)、地理纬度(大区/省份/中心)、项目归属维度(治疗领域/研发类型/产品分类/申办方/试验分期) 说明:项目维度里,产品与项目是一对多的关系,即一个产品(药物)可能会针对不同的病症开展多个项目。项目归属维度里,每个类别与项目均为一对多关系。 数据口径定义。开发接口对接各个系统供应商提供的数据,并根据业务逻辑,确定入组受试者信息优先取IRT系统,其次取CTMS,最后才取excel。 全面检查复核所有指标的口径和维度,并确定更新周期。 指标体系如下图所示: 图1-3:核心指标体系(筛败率) 同理,可以对达成率、脱落率进行指标体系搭建。此处不再赘述。 2.2.4 看板模块结构 依旧以筛败率为例: 整个数据看板可以分为5个模块:宏观指标查看、项目归属维度、项目维度(产品/项目)、地理维度(大区/省份/中心)、明细数据。 宏观指标可以根据其他维度的筛选进行联动。 说明:本次呈现的数据均为公司XXXX-XXXX年临床试验数据,数据已经过随机值处理和敏感信息处理。 2.3 数据处理 由ODS层数据、EDW层数据制作用于看板使用的DM层数据集。 ODS层存储通过接口程序从多个应用系统抽取基础数据,在EDW层对数据进行清洗、转化、筛选、连接、汇总等操作,汇总成受试者级数据集、中心级数据集、项目级数据集,并专门整理了漏斗图专用数据集。 数据处理过程均使用Mysql数据库,编写存储过程,自动化运行生成最终数据集,并存放在数据仓库DM层。 2.4 可视化报告 2.4.1 看板整体布局 以下内容以筛选失败人数与筛选总体人数为例进行梳理: (1)模块1,宏观指标展示。 图2-1:宏观指标模块 宏观指标默认显示为总量,比如总的样本量(预期入组人数),总的产品数,总的项目数等等,会伴随看板其他模块的点击,产生数据联动,展示出相应的宏观数据指标。 (2)模块2,项目归属维度筛选。 图2-2: 项目归属维度筛选模块 此饼状图、柱状图可以将数据按不同维度进行划分,并产生数据联动。 模块3-5均包含在Tab组件里面,下面将分别介绍。 (3)模块3,项目维度(产品/项目) 图2-3:项目维度(产品)模块 雷达图中,展示了3个指标(入组率、筛败率、入组进度),2条警戒线(产品入组进度100%、平均筛败率),1个维度(产品)。 图2-4:项目维度(项目)模块 条形图中,涉及2个指标(入组率/筛败率),1条警戒线(平均筛败率),1个维度(项目)。 (4)模块4,地理分析维度(大区/省份/中心) 图2-5:地理分析维度(大区)模块 气泡图中,涉及1个指标(筛败率),1条警戒线(平均筛败率),1个维度(大区)。 图2-6:地理分析维度模块(省份-矩形图) 矩形图中,涉及3个指标(筛败率、入组率、贡献度),2个维度(项目、省份)。 图2-7:地理分析维度模块(省份-地图) 中国地理区政图中,涉及3个指标(入组率、筛败率、贡献度),1个维度(省份)。 图2-8:地理分析维度模块(中心) 曲线图中,涉及1个指标(筛败率),1条警戒线(平均筛败率),2个维度(中心名称、项目名称)。 (5)模块5,明细数据 图2-9:明细数据模块 明细数据展示了模块3、4所涉及到的所有维度,并对入组率指标做了数据预警,红色圆圈表示入组率极低,橙色圆圈表示入组率低,蓝色圆圈表示入组率较好,绿色圆圈表示入组率优质;对筛败率、贡献度2个指标开启了数据条。 通过明细数据的展现,可查询到各中心具体的入组率、筛败率、贡献度,责任到人,有针对性地进行工作调整,避免资源重复浪费,提高项目整体的运营效率。 2.4.2 可视化分析 筛选与筛败看板最为核心的功能为联动分析。 2.4.2.1 概况 宏观数据:29种产品、53个项目、10个大区、29个省份、428个中心、205家医院、5713样本量。这些宏观指标会伴随项目归属维度(治疗领域/研发类型/项目类别/申办方/试验分期)、项目维度(产品/项目)、地理纬度(大区/省份/中心)的变动产生数据联动。 图3-1:宏观指标呈现 2.4.2.2 项目归属维度(治疗领域/研发类型/项目类别/申办方/试验分期) 可以对比分析宏观指标默认数据与点击项目归属维度后产生联动的数据,如图4-1与图4-2所示。 图4-1:未点击项目归属维度 图4-2:点击项目归属维度 可以看到点击每一个项目所属维度后,宏观指标所产生的数据变化。如果要进一步分析原因,可以结合Tab组件,针对某产品,某项目数据进行查看。 2.4.2.3 项目维度(产品/项目) (1)产品视角,此处我们分析筛败率。 依次查看三张图,图5-1为所有产品的雷达图,图5-2为肿瘤项目所有产品的雷达图,图5-3为非肿瘤项目所有产品的雷达图。 图5-1:所有产品雷达图 图5-2:肿瘤项目所有产品雷达图 图5-3:非肿瘤项目所有产品雷达图 结果说明: 由上图可知,所有产品的平均筛败率接近30%,肿瘤项目产品平均筛败率约25%,非肿瘤项目产品平均筛败率约为33%。我们可以进一步验证肿瘤项目相比非肿瘤项目筛败率是否普遍偏低,且找出相关原因。 同理,可查看核心指标入组率、入组进度。 同理,也可通过其他项目所属维度进行相关对比,比如研发类别、试验分期等等。 按照XX维度划分后,分析每一类别产品平均筛败率或高或低的原因,并在后续相关试验中提出更优质的策略,将筛败率控制在一个合理的阈值内。 (2)项目视角分析 我们假定分析:XX产品中各项目筛败率对比,查看不同试验分期的差别。点击Prod06产品系,发现此产品包含3个项目,分别属于I期、II期、III期临床试验。 Prod06产品系各项目筛败率及平均筛败率数据如图所示: 图5-4:项目维度分析 结果说明: 由上图可知该产品在I期,II期,III期临床试验中,筛败率分别为20%、20%、7%。我们需进一步分析,产生此筛败率的原因,应用于后续相关临床试验,以便筛败率保持在一个相对合理的阈值内。 同理,我们可以分析不同类别试验中,相关项目筛败率对比,比如分析肿瘤与非肿瘤项目,同为III期试验筛败率如何?并探索相关原因,然后提出相关策略,并应用于后续相关临床试验,这里不再赘述。 2.4.2.4 地理纬度(大区/省份/中心) (1)地理纬度-大区。 比如,我们分析XX产品,各项目,各大区筛败率数据分布。 我们假定选择Prod05产品系,此产品系包含3个临床试验项目:1112X1 (III期)、1112X3 (III期)、1112X5 (I期),在气泡图中分别以红色、粉色、绿色标识。 图6-1:地理纬度分析(大区) 结果说明: 由图所示,我们可以得出如下论点: 9个大区3个项目的平均筛败率约为43%。 1112X1项目(红色圆圈),筛败率相对较低。 1112X5 (绿色圆圈),只在华东二区开展试验,筛败率最高,达73%。 我们需进一步分析产生此筛败率的原因,并为后续试验提出合理措施,使得筛败率保持在一个合理的阈值内。 同理,我们可以分析,按照不同维度划分,分析对应项目在各大区的筛败率数据,然后再做出相对应论断,并找出相关原因,用于后续临床试验。 (2)地理纬度(省份-矩形图、省份-地图) 省份-矩形图,我们可以从项目维度,分析XX项目在各省份的筛败率;也可以去分析XX省份在同时推进哪些项目,这些项目的筛败率如何。同时,可以结合项目所属维度做关联分析。 图6-2:地理纬度分析(省份-矩形图) 结果说明: 由上图所示,北京市所在红色矩形框表示:北京市开展的所有项目;矩形块标签为:入组率/筛败率,矩形块颜色依据筛败率大小渐变, 0%使用绿色标识,向红色渐变,100%用红色标识。横向红色矩形框标识XX项目同时在哪些省份推进,各省份筛败率数据。 可结合项目归属维度,对比某几个项目在各大区的筛败率,进而推理出相关结论,并挖掘相关原因,提出相关策略,应用于后续相关临床试验,将筛败率控制在一个合理的阈值内。 省份-地图,我们可以查看XX项目各省份筛败率。 我们假定,查看1112X1项目,各省份筛败率如图所示。 图6-3:地理纬度分析(省份-地图) 通过省区-地图能够对各省份筛败率数据一目了然。数据提示中,能看到筛败率、总筛选量、筛败量等多个指标信息。 针对XX项目去分析各省份产生对应筛败率的原因,提出相关改进策略,使得在相关试验推进过程中,将筛败率控制在一个相对合理阈值内。 (3)地理纬度(中心) A:从上到下,可查看XX项目XX大区,各中心筛败情况分布。 比如,我们假定1112X1项目北京大区,各中心筛败率数据分布。 图6-4:地理纬度分析(中心)1 B:从下向上,可查看某中心,参与了哪些项目等信息。 比如,我们查看上海市1112医院参与了哪些项目。 图6-5:地理纬度分析(中心)2 由上图所示,本中心参与了5个项目。从筛败率视角分析,有3个项目筛败率高于平均筛败率,2个项目低于平均筛败率。可进一步分析原因,提出相关策略,以便应用于后续临床试验,使筛败率控制在一个合理阈值内。 2.4.2.5 明细数据 图7-1:明细数据 如上图所示,明细数据包含了项目维度、地理纬度及相关指标。并对入组率做了预警,对筛败率、贡献度开启了数据条展示。 2.4.3 业务价值 综上所述,此筛败率看板中,涉及项目维度(治疗领域/研发类型/项目类别/申办方/试验分期)、地理纬度(大区/省份/中心)、产品维度(产品/项目)。三大维度,10个细分,同时包含7个宏观指标。 此看板结构简单,图表没有过于花哨。但为公司临床试验运营管理层提供了高效且准确的数据查阅与分析平台,通过BI系统实现了从宏观至微观的数据可视化呈现。其业务价值体现在: ① 筛败率,反应一批受试者的入组质量。筛败率越低,质量越好,更有助于节省资金;反之,筛败率偏高,能够触发预警机制,从而发现问题,调整运营策略,以降低筛败率。 ② 基于业务背景,制定的专项分析看板如宏观指标、项目维度、产品维度、地理纬度等,能够深入了解项目运营情况,挖掘降低筛败率的机会及问题,将筛败率维持在一个合理区间,降低相关资金花销。 ③ 通过漏斗分析(筛选/入组/脱落),能够清楚地发现每一节点转化率,及时发现问题,提出调整策略,以提高运营效率,节省不必要的开支,使得在时间、金钱双维度上达到最佳效果。 ④ 从业务执行出发,沉淀项目运营数据,能够方便运营人员了解运营细节、灵活取数分析、定位具体问题、自助式分析等。 该看板可帮助运营团队减少工作压力,但仍有许多提升空间。希望能在此次大赛中学习到更多经验去提升团队对BI系统的掌握及制作报告的能力。 最终呈现的页面布局参见附件里的图片。(因为使用了Tab组件,所以只能显示部分图片效果,更多的联动展现请看视频)。 三、参赛总结 3.1 FineBI工具 觉得比较好用的BI亮点功能如下: (1)Tab组件,能够很好地控制看板的长度。 (2)联动功能,能够很容易的实现数据联动。 (3)复用/复制功能,能够很大程度上节省看板设计的时间。 觉得不太人性化的地方如下: (1)Tab组件中,每个Tab页面只能容纳一个组件。 (2)筛选框只能支持一个数据集,如果同一个看板引用多个数据集,不能实现筛选框的多数据库集控制。 对数据分析价值的思考如下: (1)数据分析应用场景:数据监测、数据预测、数据检测。 (2)数据分析四维空间:人、货、场、时间。 (3)四大结论: 维度越低、检测越容易; 高维度的检测就要向低维度去拆解; 检测的方法就是先往下拆分,再左右比对; 要判断检测结果的正确性,需要从低维度,再回到高维度。 3.2 参赛总结 ① 首先是做正确的事,然后才是正确做事。要想让数据BI项目成为正确的事情,数据的正确性、完整性是前提。因此我们在数据治理方面做了大量工作。 ② 数据指标要体系化。围绕核心指标(北极星指标)搭建指标体系,进一步搭建数据BI,发挥数据决策价值。 ③ 数据BI如同数据分析报告,重点不在于做的多么炫酷,更不应该止步于搭建完成。让业务人员看懂,能够根据业务指标去调整相关策略,进而实现数据BI的价值。 ④ 看板图表类型不需要太复杂、太花哨,只需要把问题说明白即可,有的时候柱状图、饼图、条形图等这些基础图表反而更受用户欢迎。 编辑于 2021-8-9 18:03
个人成就
内容被浏览28,494
加入社区4年216天
返回顶部