摘要

本报告以用户提供的《中山大学.xlsx》Sheet1为唯一事实数据源，对其中第2—24行的23条项目记录开展结构化梳理。原始字段包括项目名称、时间、单位、公司和金额。记录所涉单位以中山大学附属第一医院为主，并包含中山大学附属第一医院贵州医院相关项目。报告的核心任务不是对医院整体信息化水平作外部评价，而是对附件所呈现的项目组合、金额披露、供应商分布、建设主题和管理关注点进行可复核的案头分析。除非特别说明，文中“金额”均沿用附件数值，附件未标注货币种类或计量单位，因此不作币种、含税口径、预算口径或合同口径的推断。

从记录完整性看，23条项目中有17条记录填列了金额，合计为51,223,800；另有6条记录的金额栏以“－”呈现。金额缺失不等于项目金额为零，也不代表项目未实施，因此本报告将其视为“金额未披露/未提供”，在金额汇总、比例和均值计算中予以剔除，同时在项目数量分析中保留。2023年共有6条记录，但6条均未给出金额；2024年7条记录均给出金额，已知金额合计26,084,900；2025年10条记录均给出金额，已知金额合计25,138,900。就附件可观察范围而言，2024—2025年已知金额总额为51,223,800，两个年度的规模接近，但2025年项目记录数较2024年增加。

从项目主题看，附件记录呈现出“数据平台与基础系统、临床诊疗与检验、运营后勤与协同、其他信息化服务”并行的组合特征。该分类仅依据项目名称中的可辨识关键词进行研究性归类，不改变原始项目名称，也不将其视作采购目录或医院官方分类。按已知金额汇总，数据平台与基础系统类为21,905,800，占已知金额42.76%；临床诊疗与检验类为19,243,000，占37.57%；运营后勤与协同类为9,790,000，占19.11%；其他信息化服务类为285,000，占0.56%。这一结构说明，在附件覆盖的已知金额项目中，平台、基础系统和数据治理相关事项与面向临床流程的应用建设共同构成了主要资金落点。

供应商维度方面，深圳凯瑞康德科技有限公司在附件中出现3次，其中1条金额未披露，已知金额合计12,729,900；南京海泰医疗信息系统有限公司出现4次，其中1条金额未披露，已知金额合计8,460,000；深圳市易聆科信息技术股份有限公司、南京天溯自动化控制系统有限公司和杭州博欣科技有限公司的已知金额分别为7,910,000、7,840,000和6,980,000。该结果描述的是“附件记录中的项目关联与已知金额集中度”，不能外推为供应商市场份额、医院完整采购份额、合同履约质量或合作关系排他性判断。

基于上述观察，本报告提出的管理建议聚焦于四个层面：第一，建立统一的项目台账与金额披露字段，显式区分预算、成交、合同、结算及未披露状态；第二，以业务流程、数据对象、接口边界和责任主体为主线，强化跨项目协同；第三，对持续出现的供应商或同类项目设置关联项目视图，形成服务、变更、运维和绩效的可追溯链条；第四，在后续年度的组合管理中，将新增建设、既有系统运维、数据治理、安全运营和临床场景应用置于同一治理框架。以上建议为基于附件结构的管理性建议，不构成对任何单位、系统或供应商的事实性评价。

一、研究背景、目的与边界

（一）研究背景

医院信息化项目通常具有多部门参与、建设周期不一、项目形态差异显著和供应商协作链条较长等特征。即便仅从有限项目记录出发，也可以通过对时间、项目名称、服务单位、供应商及金额字段的统一整理，形成对项目组合的初步观察。附件中既包含平台建设、基础系统维护、电子病历相关服务，也包含临床检验、PACS、智能采血、超声工作站、日间诊疗、后勤管理、办公协同和数据安全等项目名称。这些项目名称覆盖的业务对象不同，所反映的建设逻辑也不相同：有的偏向基础能力与数据底座，有的直接服务临床诊疗流程，有的服务医院运营支撑，还有的更接近安全治理与管理协同。

本研究的价值在于把分散的项目记录转化为可讨论的管理对象。一方面，单条项目记录可以呈现某个事项的名称、时间、供应商和金额；另一方面，跨项目汇总后可以观察项目数量、金额披露完整性、年度分布、主题分布、供应商重复出现情况及大额项目的结构位置。此类分析不应替代采购文件、合同文本、验收材料、财务凭证、项目立项资料或业务绩效数据，但能够为后续的资料补充、访谈提纲、台账建设和治理检查提供线索。

（二）研究目的

·对附件内23条项目记录建立统一的分析口径，说明字段含义、数据边界与金额缺失处理方式。

·对2023—2025年的项目记录数量、已知金额和金额披露完整性进行年度比较，避免把缺失金额误读为零金额。

·基于项目名称开展研究性主题归类，识别附件记录中平台基础、临床应用、运营后勤和其他服务的相对结构。

·汇总供应商在附件中的出现次数与已知金额，形成关联项目的观察视图，而不对市场份额或履约质量作越界推断。

·提出可操作的项目组合管理、数据治理、运维衔接、供应商协同和后续调研补充建议。

（三）研究边界与限制

第一，数据源边界。本报告只使用《中山大学.xlsx》Sheet1的原始记录及由其直接计算的统计结果。未使用互联网检索、第三方数据库、院方公告、采购平台页面或其他外部资料。因此，任何未在附件出现的项目、金额、供应商、时间节点、技术架构和业务绩效均不在本报告事实范围内。

第二，金额口径边界。附件的“金额”列未说明其是预算金额、中标金额、合同金额、结算金额还是其他财务口径，且未标注币种和单位。报告保留原始数值并以“已知金额”称呼，不进行单位换算、币种换算或含税与不含税换算。金额为“－”的记录视为缺失披露，而非零值。因而，本报告中的金额集中度只能代表已知金额记录的分布，不能代表全部项目真实投入的精确比例。

第三，项目去重边界。附件中存在名称相近或主题延续的项目，例如后勤综合智能管理平台二期、日间诊疗管理平台等在不同日期出现的记录。由于附件未提供项目唯一编号、合同编号、采购批次、项目阶段或变更关系，本报告按原表逐条计数，不自行合并、拆分或判断是否为同一事项的不同阶段。由此，项目数量表示记录条数，不能机械等同于独立项目个数。

第四，分类边界。为便于结构分析，报告依据项目名称中的关键词作了研究性归类。分类方法的目的在于揭示项目组合的主题轮廓，而不是认定项目的技术边界、采购分类、预算科目或责任部门。对于跨多个主题的项目，归类只能体现名称中较为显著的分析线索，不能替代项目说明书和业务架构文档。

二、数据来源、方法与口径

（一）原始数据结构

原始工作表共5个字段：项目名称、时间、单位、公司和金额。数据区位于Sheet1第2—24行，共23条记录。项目名称字段提供了识别建设主题的主要文本依据；时间字段同时出现“2025-09-29”与“20240828”等格式，报告在年度统计中均按前四位年份识别；单位字段主要为中山大学附属第一医院，另有中山大学附属第一医院贵州医院；公司字段用于形成供应商关联视图；金额字段用于已知金额汇总。附件中没有项目唯一编号、采购方式、合同状态、部门归属、验收状态、项目周期、功能范围、数据接口、用户规模和绩效指标等字段。

（二）统计与分类方法

本报告采用描述性统计和文本主题归类相结合的方法。描述性统计包括：按年度计算项目记录数、填列金额的记录数、金额缺失记录数、已知金额总额、已知金额均值和单项最大已知金额；按公司计算出现记录数、已知金额和金额缺失记录数；按研究性类别计算项目记录数、已知金额和金额缺失数。所有金额汇总均只对“金额”字段为数值的记录求和。

主题归类依据如下：凡项目名称包含“后勤”“织物”或“办公协同”等词的，归入“运营后勤与协同”；包含“PACS”“采血”“超声”“检验”“日间诊疗”“跨科诊疗”或“输液”等词的，归入“临床诊疗与检验”；包含“数据分类”“CDM”“数据建模”“集团化医疗平台”“信息集成”“电子病历”“核心信息系统”或“智慧平台”等词的，归入“数据平台与基础系统”；其余纳入“其他信息化服务”。这是一种为数据分析服务的规则，不是对项目内容的官方定性。

对于项目名称中可能同时涉及多个主题的情形，本研究不进行金额拆分。例如，“集团化医疗平台及院内信息平台支撑能力升级改造项目”既可能涉及平台能力，也可能关联多个业务场景，但在本分析中被统一放入数据平台与基础系统，以避免在缺少合同范围与费用分项时作任意拆分。类似地，维护服务项目的金额也不与新增建设项目强行比较其产出效率，而是作为不同项目类型共同呈现在组合结构中。

（三）数据质量判断原则

数据质量判断遵循“如实呈现、审慎解释、不得补造”的原则。对于可直接读取的字段，本报告保留其原始语义；对于可由原始字段简单推导的结果，例如年度项目数、已知金额总额、供应商已知金额及分类占比，采用明确规则计算；对于附件无法支持的结论，例如系统是否上线、是否验收、是否节约成本、是否改善患者体验、是否发生重复采购或供应商履约是否达标，本报告不作判断。报告中使用“可能”“建议”“需要进一步核验”等表述时，均为管理性分析或后续调研建议，而不是对事实的确认。

三、样本总体画像与年度分布

（一）项目记录与金额披露情况

附件样本共计23条项目记录。按金额字段是否有效可分为两组：一组为17条已知金额记录，合计51,223,800；另一组为6条金额为“－”的记录。已知金额记录占全部记录约73.91%，金额未披露记录占约26.09%。这一比例仅反映附件中的字段填报状态，不宜直接视为采购透明度、信息披露合规性或财务管理水平的评价。对本次调研而言，它首先意味着所有金额相关比较都必须同时报告“可计算范围”和“未披露数量”，否则容易将2023年的六条记录错误地理解为没有投入。

从时间分布看，2023年6条、2024年7条、2025年10条。记录数在2025年达到样本内最高值，而已知金额在2024年略高于2025年。二者之间的差异提示：项目数量与金额规模并不总是同向变化。一个年度的项目记录较多，可能由多个中小型项目、服务项目或拆分事项构成；一个年度的已知金额较高，则可能受到少数大额项目驱动。由于附件未提供每个项目的完整工作范围和合同状态，不能把金额差异直接解释为建设力度、业务价值或项目优先级的差异。

图1附件项目记录的年度数量与已知金额分布（数据来源：中山大学.xlsx，Sheet1，第2—24行）

（二）年度结构解读

2023年包含6条记录，项目名称涉及电子病历系统驻场维护、发热门诊智能输液系统、电子病历归档系统三期、基于通用数据模型的疾病队列数据基础治理与开放共享平台（一期）、专科与人才评价数据建模一体化智能服务平台一期等。上述名称显示，2023年的记录既涉及既有信息系统运维，也涉及电子病历归档、临床场景应用和数据治理/评价建模等方向。但由于这6条记录金额均为“－”，本报告不能对其投入规模、项目重要程度或与后续年度的金额差异作量化比较。它们的存在仍然提示，若要形成连续的项目组合画像，需要补充2023年对应的预算、成交、合同或结算金额及项目状态。

2024年共有7条记录，全部填列金额，已知金额合计26,084,900，单项最大金额为7,910,000，对应“数据分类分级及安全监管运营一体化平台项目”。同年还包括集团化医疗平台及院内信息平台支撑能力升级改造、后勤综合智能管理平台二期、日间诊疗管理平台、智能办公协同改造、医用织物管理系统（二期）和医保综合管理系统维护服务等。这一年度的名称结构同时覆盖安全治理、平台支撑、后勤管理、临床日间诊疗、办公协同和运维服务，体现出样本内项目主题的多样性。需要强调的是，单项大额项目对年度总额影响显著，不能仅以年度总额判断所有主题的相对优先级。

2025年共有10条记录，均填列金额，已知金额合计25,138,900，单项最大金额为6,980,000，对应智能采血传输系统项目。该年度的项目数量高于2024年3条，但已知金额低于2024年946,000。2025年记录涉及跨科诊疗管理、PACS二期、后勤综合智能管理平台二期、日间诊疗管理平台、智慧平台及应用维护、临床检验智慧应用、智能采血传输，以及贵州医院的信息集成平台维护、核心信息系统维保和门诊超声工作站等。从名称上看，临床工作流、检验与影像、后勤平台、运维服务及分院区/协作单位相关系统均有出现，项目组合的颗粒度更细。

年度比较还需要关注记录日期字段的解释边界。附件所记录的时间可能是公告、采购、合同、招标、中标或其他节点的日期，但原表未给出字段定义。因此，本文仅将其用于年度归集，而不将其等同于项目启动日、上线日、验收日或付款日。若后续需要形成投资节奏、建设周期或项目交付进度判断，应补充统一的日期字段，例如立项日期、采购公告日期、成交日期、合同生效日期、上线日期、验收日期及结算日期。

四、供应商关联项目与已知金额分布

（一）供应商记录概况

附件中出现的公司名称共15家。按项目记录次数看，南京海泰医疗信息系统有限公司出现4次，深圳凯瑞康德科技有限公司、南京天溯自动化控制系统有限公司各出现3次，广州医博信息技术有限公司出现2次，其余公司各出现1次。出现次数反映的是附件内项目记录的关联频率，不代表供应商实际服务范围、合同规模、市场竞争地位或院方评价。尤其需要注意，部分供应商的某些记录金额为“－”，因此按已知金额排序与按记录次数排序并不完全一致。

深圳凯瑞康德科技有限公司在附件中关联“电子病历归档系统三期中标公告”“智慧平台及应用维护服务项目（一年）”及“集团化医疗平台及院内信息平台支撑能力升级改造项目”等3条记录，其中电子病历归档系统三期金额未披露，另外两条已知金额合计12,729,900。南京海泰医疗信息系统有限公司关联跨科诊疗管理平台、日间诊疗管理平台及电子病历系统驻场维护等4条记录，其中电子病历系统驻场维护的金额未披露，已知金额合计8,460,000。两家供应商均在多个项目名称中出现，提示后续台账建设可以按“供应商—项目—模块—服务期—接口—验收—运维”建立关联视图，而不应只保留单项目孤立记录。

图2供应商已知金额排序（按附件记录汇总；仅汇总金额非“－”的记录）

（二）已知金额排序与集中度观察

按附件已知金额汇总，前五家供应商的已知金额分别为12,729,900、8,460,000、7,910,000、7,840,000和6,980,000，合计43,919,900，占全部已知金额约85.74%。这一计算可以说明已知金额记录存在一定集中度，但不能据此判断供应商集中风险的实际程度。原因在于：其一，金额缺失记录可能改变真实比例；其二，项目金额不等于在服务期内的实际收入或结算额；其三，供应商之间的产品边界、服务边界和项目类型不同，不应简单作为可替代对象比较；其四，附件覆盖范围可能并非该医院所有信息化采购事项。

从管理视角看，供应商在不同项目、不同年度或不同系统层级上的持续出现，至少带来两类值得核验的议题。第一类是协同议题：当基础系统、平台能力、临床应用和运维服务由多个公司分别承担时，接口、数据标准、权限边界、故障责任和变更流程需要明确。第二类是延续性议题：当同一公司同时关联建设项目和维护项目，或关联同一主题的不同阶段时，应在台账中建立版本、合同、服务期、验收、续保与变更的关系，避免仅凭名称相似进行主观判断。报告并不认为供应商重复出现本身构成问题，而是提示应以可追溯信息支撑后续管理。

（三）供应商管理的建议性框架

建议把“供应商信息”从静态名称字段扩展为可治理的关系对象。对于每个供应商，可在不改变采购合规流程的前提下，形成四层信息：第一层是基础身份信息，包括统一名称、法定主体、联系人和资质文件；第二层是项目关联信息，包括项目编号、系统名称、合同范围、金额口径和时间节点；第三层是交付与服务信息，包括上线、验收、故障响应、维护期限、版本更新和培训记录；第四层是依赖与风险信息，包括关键接口、数据交接、源代码或配置文件归属、账号权限、备份与退出安排。这样做的目的不是增加无效台账，而是在跨项目管理时能够快速回答“谁在什么范围内负责什么、责任从何时开始、与哪些系统存在依赖”。

五、项目主题结构与建设组合分析

（一）研究性类别的金额与数量结构

按本报告的研究性分类，数据平台与基础系统类共有9条记录，其中4条金额未披露，已知金额21,905,800；临床诊疗与检验类有8条记录，其中1条金额未披露，已知金额19,243,000；运营后勤与协同类有4条记录，全部有金额，已知金额9,790,000；其他信息化服务类有2条记录，其中1条金额未披露，已知金额285,000。需要特别注意，数据平台与基础系统类的金额缺失记录数较多，因此其真实金额位置不能仅以21,905,800作为最终判断；同理，临床诊疗与检验类的“已知金额”也只代表已披露部分。

（二）数据平台与基础系统类

该类项目名称涵盖信息集成平台维护、核心信息系统维保、电子病历系统驻场维护、电子病历归档系统三期、基于通用数据模型的疾病队列数据基础治理与开放共享平台（一期）、专科与人才评价数据建模一体化智能服务平台一期、数据分类分级及安全监管运营一体化平台、集团化医疗平台及院内信息平台支撑能力升级改造以及智慧平台及应用维护服务等。虽然这些项目在技术范围上不必然相同，但从名称上均可观察到“平台、基础系统、数据、维护、集成、安全、支撑能力”等共性线索。

这一类别的管理重点不宜仅放在单点功能是否完成，还应关注跨系统能力的连续性。以信息集成、电子病历、数据治理、数据分类分级、安全监管、集团化平台和智慧平台维护等名称为例，后续调研可重点补充：各项目对应的主数据、数据标准、接口目录、数据交换频率、权限模型、日志留存、灾备安排、版本边界和责任界面。附件不足以确认这些内容是否已建立，但其项目名称已经显示出这些管理要素具有现实相关性。

该类已知金额的最大单项为7,910,000，对应数据分类分级及安全监管运营一体化平台项目；另有7,599,900的集团化医疗平台及院内信息平台支撑能力升级改造项目，以及5,130,000的智慧平台及应用维护服务项目（一年）。这三个已知金额较高的记录均包含平台、安全或应用维护相关表述。对后续管理而言，建议把“新增建设”与“持续运营”分开记录，又在总体架构层面关联起来：新增建设关注交付范围、接口、数据迁移和验收；持续运营关注服务级别、问题闭环、版本维护、性能监测和知识转移。两类项目都可能影响基础能力，但其考核指标不应相同。

（三）临床诊疗与检验类

该类项目名称包括门诊超声工作站、跨科诊疗管理平台、PACS系统二期、日间诊疗管理平台、临床检验智慧应用平台、智能采血传输系统、发热门诊智能输液系统以及医用织物管理系统（二期）。其中，医用织物管理与临床支撑、后勤管理可能存在交叉，本文根据名称中的“织物”将其归入运营后勤与协同类，因此临床诊疗与检验类的主要观察对象为超声、跨科诊疗、PACS、日间诊疗、检验、采血和输液等。

临床应用类项目的共同特点是与具体流程、角色和场景高度相关。不同项目可能分别服务门诊、检验、影像、治疗、日间诊疗或跨科协作。仅从项目名称无法确认其流程改造深度、终端部署范围、系统之间数据互联程度或实际使用效果，但可以明确后续管理不宜只以“是否上线”作为唯一判断。对于此类项目，较为关键的补充材料包括：业务流程图、上线范围、角色权限、与电子病历/检验/影像/收费/排班等系统的接口清单、异常处理规则、数据质量规则、培训覆盖以及使用与服务评价记录。

从已知金额看，智能采血传输系统为6,980,000，日间诊疗管理平台在2024年和2025年分别出现3,450,000的记录，PACS系统二期为2,800,000，临床检验智慧应用平台为978,000，跨科诊疗管理平台为1,560,000，门诊超声工作站为25,000。不同金额并不对应简单的技术优劣或业务价值高低，可能受到采购范围、设备与软件组成、服务期、实施范围、历史合同关系等多种未披露因素影响。正确的比较方式应建立在统一的项目范围、交付物、用户规模与服务边界上，而不是只比较金额大小。

（四）运营后勤与协同类

运营后勤与协同类包括后勤综合智能管理平台二期、医用织物管理系统（二期）和智能办公协同改造等项目记录。该类别共有4条记录，已知金额9,790,000，且不存在金额“－”的记录。与平台基础系统、临床应用相比，后勤与协同类更直接体现医院运营支撑场景。项目名称中的“后勤综合智能管理”“织物管理”“办公协同”说明，附件记录并非只覆盖临床核心系统，也呈现出对管理运营与保障环节的数字化投入。

值得注意的是，后勤综合智能管理平台二期在2024年和2025年均出现2,950,000的记录，日间诊疗管理平台也在相邻年度出现同额记录。由于缺少项目编号、采购批次、合同状态和项目关系字段，本报告不能判断这是否为同名项目的重复记录、不同阶段、不同主体、续建事项或其他情况。对于类似记录，建议在后续台账中增加“关联项目ID”“阶段属性”“是否续建/变更/维保”“上期合同编号”“本期增量范围”等字段，从源头避免仅以名称比对造成误读。

六、重点项目观察与项目组合逻辑

（一）大额已知金额项目的结构位置

从前八项已知金额项目看，金额最高的三个项目分别为数据分类分级及安全监管运营一体化平台项目（7,910,000）、集团化医疗平台及院内信息平台支撑能力升级改造项目（7,599,900）和智能采血传输系统项目（6,980,000）。这些记录分别指向安全/数据治理、平台支撑能力和临床检验流程等不同方向。其共同点不是技术内容相同，而是均可能涉及较广的系统边界、设备/软件/服务组合或实施范围；但这只是一种基于名称与金额的管理性观察，具体构成仍须以采购文件和合同清单为准。

紧随其后的智慧平台及应用维护服务项目（一年）金额为5,130,000，表明在附件记录中，运维服务也可能形成较高金额。该现象提醒项目组合管理不能只关注“建设项目”的立项和验收，也要关注持续服务项目的服务目录、响应级别、故障分类、驻场安排、变更边界、数据安全责任、续约条件和退出机制。对于医院信息化体系而言，新增建设与稳定运行并非相互替代；若没有清晰的运维治理，新增能力也可能难以形成持续价值。

（二）同主题跨年度记录的解释边界

附件中存在若干名称相近的跨年度记录。例如，后勤综合智能管理平台二期在2024年和2025年均出现；日间诊疗管理平台在2024年与2025年均出现；某些平台、维护和系统升级项目也呈现不同时间的关联线索。面对此类情况，分析者容易作出“重复采购”或“持续建设”的判断，但附件并不提供足够证据支持其中任何一种结论。项目名称相同可能意味着不同院区、不同批次、不同模块、不同服务期、续建、扩容、变更，甚至可能是数据录入口径不同。

因此，本报告建议将“名称相似”视为需要核验的台账线索，而不是事实结论。核验可从四个问题展开：是否有相同的项目编号或合同编号；是否具有不同的建设范围或交付物；是否属于新增、续建、扩容、维保或变更；是否面向不同单位、院区或业务部门。只有在取得这些信息后，才能进一步判断项目的生命周期关系、金额累积关系和管理责任关系。

（三）从单项目管理到项目组合管理

单项目管理通常关注立项、采购、合同、实施、验收和付款等环节；项目组合管理则需要进一步回答：多个项目共同服务什么目标，是否共享数据和接口，是否存在重复建设风险，是否有共同的安全要求，是否对同一业务部门带来过多并行变更，运维资源是否能够承接，以及是否形成了可持续的能力。附件中同时出现基础平台、电子病历相关、数据治理、安全运营、临床应用、后勤协同和维护服务，说明仅以孤立项目清单来管理可能不足以呈现全貌。

建议以“业务域—系统域—数据域—服务域—供应商域”五维框架整理项目组合。业务域对应临床、检验、影像、后勤、办公、管理等场景；系统域对应核心系统、集成平台、专题应用、终端设备和运维工具；数据域对应主数据、业务数据、日志、指标和数据交换；服务域对应建设、维护、驻场、运营和安全服务；供应商域对应合同主体、服务边界、接口责任与交接机制。该框架不要求一次性重建所有资料，而可先从附件的23条记录开始，通过逐步补充形成可查询、可比较、可审计的项目地图。

七、管理风险与需要进一步核验的事项

（一）金额口径与台账一致性风险

附件金额字段同时包含数值与“－”，且未标明金额性质。这会对预算控制、投资统计、供应商汇总、年度比较和项目绩效分析造成直接限制。若不同记录混用预算金额、成交金额、合同金额和结算金额，即使数值齐全，也会导致汇总口径不可比；若“－”被系统默认为零，可能低估实际投入；若“－”被随意补填，又可能引入无法追溯的数据。建议在后续台账中将金额拆分为预算金额、采购/成交金额、合同金额、累计结算金额、当期支付金额和未披露原因，并为每一金额字段记录来源文件与更新时间。

（二）项目关联与重复识别风险

名称相似的项目如果缺少唯一标识和关联关系，可能影响管理者识别项目是否续建、扩容、变更、维保或新建。附件中出现的同主题跨年度记录已足以说明这一风险具有现实相关性，但报告并不据此确认发生了重复建设。建议建立“项目主数据”与“项目版本/批次”双层结构：项目主数据描述长期对象，如某平台或某业务系统；项目版本/批次描述特定年度、特定合同、特定范围的事项。这样既能保持历史连续性，又可避免把不同批次错误合并。

（三）接口、数据与责任边界风险

当项目组合同时包含核心系统、信息集成、电子病历、数据治理、安全监管、临床应用和后勤平台时，跨系统接口与数据责任是重要治理对象。附件未提供接口清单、数据目录或责任矩阵，因此无法判断实际接口质量或数据一致性。但从管理设计上，建议每个项目在立项和验收资料中明确：新增或调整的接口、数据源与目标、交换频率、异常处理、权限管理、日志要求、主数据归属、数据质量责任、变更审批与回退方案。对于涉及多个供应商的接口，应明确谁负责提出需求、谁负责开发、谁负责联调、谁负责验证、谁负责长期维护。

（四）运维持续性与知识转移风险

附件中可见核心信息系统维保、信息集成平台维护、电子病历系统驻场维护、智慧平台及应用维护等记录，说明持续运维是样本内项目组合的重要部分。运维项目的风险不在于其是否属于“建设”，而在于服务范围与系统演进是否匹配。若运维合同缺少服务目录、响应时限、驻场范围、配置文档、版本台账、故障复盘、知识库、培训和退出交接要求，则可能在人员变动、合同转换或系统升级时形成隐性依赖。建议将运维交付物纳入可验收清单，并建立院方可掌握的配置与知识资产目录。

（五）绩效证据不足风险

当前附件只提供项目名称、时间、单位、公司和金额，不能直接支持关于效率提升、质量改善、患者体验、成本节约、业务量变化、故障率下降或安全水平提升的结论。若后续需要进行绩效评价，应为不同项目类型设置可验证指标：临床应用项目可关注流程时长、人工环节、异常率、使用覆盖和用户反馈；平台项目可关注接口可用性、数据质量、系统性能、变更成功率和服务等级；后勤项目可关注资产/物资/工单准确性、响应效率和协同闭环；安全项目可关注资产覆盖、策略执行、告警处置和审计留痕。上述指标只是建议性框架，具体指标应由业务、信息、财务、审计与采购等相关方共同确认。

八、后续治理与调研建议

（一）建立统一项目台账

建议以附件既有5字段为起点，建设轻量级但可扩展的统一项目台账。最小字段集可包括：项目唯一编号、项目名称、关联项目主数据、项目阶段、单位/院区、业务归属、信息归属、供应商、采购方式、预算金额、成交金额、合同金额、结算金额、金额单位与币种、关键日期、合同编号、项目状态、验收状态、服务期、接口清单链接、数据清单链接、风险等级、责任人和资料来源。台账应区分“事实字段”和“分析字段”：事实字段来源于合同、采购、验收等正式材料；分析字段如研究性分类、关联关系和风险标签，应保留规则、维护人和更新时间。

（二）设置项目立项与验收的共同检查项

对于未来新增或续建项目，建议在立项阶段和验收阶段设置一组跨项目通用检查项。立项侧重点是业务目标、范围边界、现状系统、接口依赖、数据要求、预算口径、实施资源与风险；验收侧重点是交付清单、功能覆盖、接口联调、数据迁移或初始化、性能与安全要求、培训、文档、运维移交和问题闭环。通用检查项不会取代不同项目的专业要求，但可以降低不同项目在基础治理信息上的不一致。

（三）形成项目组合评审机制

建议在单项目采购流程之外，定期形成项目组合评审。评审不需要对每个项目重新审批，而是从组合层面检查：本期新增项目是否与既有系统存在功能交叉；多个项目是否对同一接口、主数据或业务部门提出冲突要求；平台能力是否可以复用；系统运维和安全运营资源是否覆盖新增范围；供应商责任是否存在盲区；项目资料是否形成完整链条。附件中多主题项目并行出现，正适合作为建立组合视图的起点。

（四）围绕“数据—接口—安全—运维”建立闭环

在附件项目名称中，数据治理、安全监管、信息集成、电子病历、平台支撑与维护服务共同出现。建议后续把它们放在同一个闭环中理解：数据治理明确哪些数据、来自哪里、由谁负责；接口治理明确如何交换、何时交换、异常如何处理；安全治理明确谁能访问、如何审计、发生事件如何响应；运维治理明确系统如何持续运行、变更如何控制、知识如何留存。四者不是四份互不关联的材料，而应在项目台账、架构图、合同条款、验收清单和运行报告中形成对应关系。

（五）分阶段补充调研材料

如果要把本报告进一步升级为投资评价、采购合规核查、项目绩效审计或数字化规划报告，建议分阶段补充材料。第一阶段补齐基础台账与金额口径，重点解决“项目是什么、金额是什么、状态是什么”；第二阶段补充合同、采购、验收、服务和接口资料，重点解决“范围是什么、交付是什么、责任是谁”；第三阶段结合业务数据和访谈，重点解决“是否使用、产生何种效果、有哪些改进空间”。在材料尚未补齐之前，应避免用单一金额、单一供应商或单一项目名称作出过度结论。

九、结论

本调研基于《中山大学.xlsx》Sheet1的23条项目记录，形成了对2023—2025年样本内信息化项目组合的初步画像。数据中有17条已知金额记录，已知金额合计51,223,800；另有6条金额未披露记录，其中2023年6条全部未披露金额。因而，任何关于年度投入、供应商占比和类别结构的数值结论都应限定在“附件已知金额记录”范围内。

从已知金额的主题分布看，数据平台与基础系统、临床诊疗与检验、运营后勤与协同是三类主要方向；从项目名称看，平台支撑、信息集成、电子病历相关服务、数据治理与安全、临床诊疗流程、检验影像、后勤运营和办公协同均有覆盖。供应商维度存在多次出现和跨年度关联的情况，值得通过统一项目台账进一步建立项目阶段、合同、服务期、接口与责任关系，但不能只凭附件记录推断供应商关系或项目绩效。

对后续工作而言，最优先的不是扩展更多宏观判断，而是提升基础数据的可用性：统一金额口径，补齐“－”的含义和来源，建立项目唯一标识，维护同主题项目的关联关系，沉淀接口和数据责任信息，并把新增建设与持续运维纳入同一项目组合治理框架。只有在这些基础信息可追溯的前提下，后续的投资评估、项目绩效、风险识别和数字化规划才能形成更稳健的证据链。

附录A：数据口径说明

1. 项目记录数：按附件Sheet1第2—24行逐条统计，不对名称相近记录去重。

2. 已知金额：金额字段为数值的记录之和；金额字段为“－”的记录不计入求和。

3. 年度归集：按“时间”字段前四位识别年度；不判断该日期的业务含义。

4. 供应商已知金额：同一公司名称对应的已知金额逐条相加；不合并或剔除可能存在关联的项目。

5. 主题类别：由项目名称中的关键词进行研究性归类，仅用于本文结构分析。

附录B：资料补充清单（建议）

·项目立项资料与项目唯一编号

·采购文件、中标/成交通知、合同及补充协议

·预算、成交、合同、结算和支付的金额口径说明

·项目范围、功能清单、设备/软件/服务分项清单

·实施计划、上线与验收材料、培训与文档交接材料

·接口清单、数据目录、主数据责任与安全要求

·服务级别协议、运维工单、故障复盘与版本变更记录

·业务使用、质量、效率与用户反馈等绩效证据

参考资料

[1] 《中山大学.xlsx》：Sheet1，第2—24行。用户提供的项目记录数据源，访问于2026年8月17日。

文档生成校验：正文及附录段落文本字符数约为13325（不含图表内文字和表格单元格文字）。