广州知识产权法院民 事 判 决 书（2019）粤73知民初1140号原告：联合大数据有限公司。住所地：广东省广州市番禺区***********（10xxxxxx12室。法定代表人：陈向东，职务：总经理。委托诉讼代理人：符小虎，该公司职员。委托诉讼代理人：史立艳，广东正始律师事务所律师。被告：广州市行心信息科技有限公司。住所地：广东省广州高新技术产业开发区**。法定代表人：林永强，职务：董事长兼总经理委托诉讼代理人：罗结玉，该公司职员。委托诉讼代理人：李春凤，该公司职员。原告联合大数据有限公司（以下简称联合公司）与被告广州市行心信息科技有限公司（以下简称行心公司）计算机软件委托开发合同纠纷一案，本院于2019年8月22日立案后，依法适用普通程序，于2019年11月26日公开开庭进行了审理。联合公司委托诉讼代理人符小虎、史立艳、行心公司委托诉讼代理人罗结玉到庭参加诉讼。本案现已审理终结。联合公司向本院提出诉讼请求：1.判令解除联合公司与行心公司签订的《联合医疗医联体云H**开发服务合同》；2.判令行心公司返还联合公司已付款18万元；3.判令行心公司支付逾期交付软件的累计违约金6万元（暂计）。事实和理由：双方在2018年10月9日签订《联合医疗医联体云H**开发服务合同》，合同第二条第2.1款约定合同签订之日起5个月内正式上线，联合公司已按约定支付了第一期合同款18万元。但行心公司没有按照合同约定按时按质交付软件，其交付的系统测试版安装存在问题且未及时处理，该软件无法满足交付验收标准。联合公司于2019年7月11日通过律师函催促行心公司按合同约定履行义务并根据涉案合同第九条9.3款的约定支付违约金，但行心公司不予理会。行心公司至今未按照合同履行义务，未能按照约定工期及要求交付合格系统，导致合同目的无法实现，构成根本违约。行心公司辩称：联合公司的诉讼请求没有事实和法律依据。一、行心公司已经按照合同约定开发了云H**系统，项目开发费用已产生。云H**系统未能按照工期上线并非行心公司原因所致，故行心公司无需返还已收取的合同款。对于联合公司主张的合同解除，行心公司同意终止履行。二、联合公司请求行心公司支付逾期交付的违约金没有依据。涉案合同是定制开发服务合同，合同约定“因为接口与相关流程改动无法在合同签订时进行约定，后期与第三方公司沟通后，以增补合同的方式补充签约”，联合公司按照行心公司提供的系统运行要求，提前准备好所需网络布线及调试，并进行调试、安装、培训协调等有关工作。云H**系统未交付原因在于联合公司主动放弃在工期内交付，让行心公司先把门诊部分以及一些接口完成后再上线HIS系统。故行心公司不存在违约行为。当事人围绕诉讼请求依法提交了证据，本院组织当事人进行了质证。对当事人无异议的证据，本院予以确认并在卷佐证。根据当事人陈述和经审查确认的证据，本院认定事实如下：一、涉案合同的签订及合同内容2018年10月，联合公司（合同甲方）与行心公司（合同乙方）签订《联合医疗医联体云H**开发服务合同》（以下简称云H**合同）。该合同约定基于双方2018年4月签订的《战略合作伙伴协议》，双方达成如下协议：第一条，合同价款。甲方与乙方就清远联合医院云H**系统项目达成协议，由乙方负责提供定制开发服务（详见附件一《系统功能清单》，总价为60万元。因为其中接口与相关流程改动无法在合同签订时进行约定，后期与第三方公司沟通后，以增补合同的方式补充签约。第二条，实施时间、地点。2.1时间：、地点8年10月1日正式开始实施，截至5个月内正式上线。2.2地点：清远联合医院。第三条，项目实施。3.1乙方在合同签订之日起三日内安排如下工程人员与甲方对接实施相关工作。由甲方人员进行实施，乙方远程技术指导。小组成员：……3.2乙方免费提供系统验收之后12个月内的售后服务和软件升级服务。第四条，付款方式。4.1本合同签订后10个工作日内，甲方向乙方支付合同总价款的30%，即18万元。4.2乙方向甲方交付安装包后的10个工作日内，甲方向乙方支付合同总价款的30%，即18万元。4.3系统安装调试并验收合格后10个工作日内，甲方向乙方支付合同总价款的30%，即18万元。4.4保修期届满之日起10个工作日内，甲方向乙方支付合同总价款的10%，即6万元。4.5甲方通过银行转账方式向乙方支付合同价款……第五条，甲方责任。5.1按照乙方提供的系统运行要求，要求使用方提前准备好所需网络布线及调试，并进行调试、安装、培训协调等有关工作。5.2按期拨付合同款项。……第六条，乙方责任。6.1确保软件系统的完整性、开放性、延续性。6.2保证软件版权的合法，……6.3乙方须按时交付所开发的软件产品及相关文档给甲方或甲方指定的第三方，并负责对提供给甲方的系统进行维护。……第七条，验收。7.1乙方协助甲方完成项目安装调试工作后，向甲方提出书面的验收申请并经甲方确认，甲方应在7个工作日内组织项目验收，验收合格后双方书面签字盖章确认。如甲方在乙方正式提交书面的验收申请后7个工作日内不进行验收，则视为甲、乙双方均同意验收合格。第八条，保修期。8.1乙方提供验收合格后12个月内免费保修，12个月内不再单独收取服务费用……8.3乙方向甲方提供维护与技术支持服务的范围包括：（1）系统应用程序维护：检查和保证用户使用的软件和源代码是一致的，而且是最新的版本；（2）源代码维护：随着系统中的各种代码都需要进行一定程度的增加、修改、删除，以及设置新的代码，乙方负责源代码的维护；（3）纠错性维护：乙方负责诊断和修正系统中遗留的错误。软件如出现漏洞（专业术语BUG），实行终身免费修改维护。（4）文档维护：对系统最新文档的维护，相应的文档进行更新。以及对用户不理解的文档内容进行补充、完善……第九条，违约责任。9.1甲、乙双方有责任按照本合同条款履行各自的职责和义务，如因乙方单方面的原因造成合同不能履行，有过错的一方应赔偿无过错一方因此造成的损失。9.2甲方必须按照合同要求及时付款，无故拖延付款应承担违约责任，每拖延一天，甲方需向乙方支付应付款金额的0.1%的违约金，累计不超过合同总价的20%。9.3因乙方技术产品的缺陷或履行合同时，因乙方原因造成工期拖延，每拖延一天，乙方需向甲方支付总价款0.1%的违约金，累计不超过合同总价的20%。第十条，合同的生效、终止和其他。10.1本合同经甲乙双方法定代表人或授权代理人签字并加盖有效印证后生效。10.2本合同在双方的责任、义务履行完毕后自行终止，在合同生效到自行终止前，对本合同的任何修改或解除要求，均应以双方法定代表人或授权代理人的书面文件为准。……10.5本合同含附件一《系统功能清单》……合同尾部有双方授权代表签名并加盖有双方合同专用章。前述合同附件为《系统功能清单》，该清单系统名称、功能模块、详细功能说明等三方面对涉案系统功能进行了描述，主要内容如下：（一）门诊挂号系统：1.病人管理与导诊：登记、修改、删除、打印和检索病人的基本信息；登记诊疗卡信息；换卡；导出病人信息。2.门诊挂号：根据病人卡号、姓名和读卡调出病人，系统根据病人类、专家自动算出挂号费用；支持重打发票、退号、限号、设置挂号起始发票。3.日排班维护：维护、更改当日医生出诊、停诊信息。4.病人查询：通过查询条件查询已做登记的病人信息，可打印或导出病人信息。5.门诊挂号查询：通过查询条件查询已挂号的病人挂号信息，可打印或导出病人信息。（二）门诊医生工作站：1.门诊就诊：处方的各种录入方式、修改、查看、打印、复制粘贴程序处方；可调用套餐，可查看以往处方的病历；病历、诊断（ICD）的录入；检验、检查、治疗、手术、材料等项目的快速录入，检验检查治疗手术申请单的打印；作废处方，套餐录入、修改、删除；传染病报告卡的录入、修改、删除；支持登记病人传染病报告卡。2.门诊病历模板维护：公共、科室、个人的病历模板进行新增、修改、删除。3.病人处方查询：通过处方日期、病人类别、项目等条件来查询病人处方信息，可打印、打出，可查看病史；4.医生处方查询：通过条件来查询处方信息，可进行打印、导出；5.模板维护：公共、科室、个人的诊断信息进行新增、修改、删除；6.门诊处方查询：通过条件来查询门诊处方信息，可查看处方详细信息，打印处方跟门诊处方列表、门诊记录，可查看病人病史、影像报告、检查报告；7.已诊病人查询：通过医生、科室等条件来查询已诊病人信息，可查看诊断、病史，可打印和导出。（三）门诊收费系统：1.门诊收费：刷卡或输入卡号等方式调出病人，对病人的处方进行收费、退费、打折、设定自负或优惠比例、打印发票等；可设置操作员起止发票号，支持录入删除手工处方，可重打发票，支持合并多张处方；2.门诊发票查询：通过条件查询门诊发票明细，支持打印、导出功能；3.门诊费用明细查询：通过条件查询门诊病人的费用明细清单，支持打印、导出功能；4.门诊收入查询：通过条件查询门诊收入明细，支持打印、导出功能；5.门诊转诊人数查询：通过条件查询门诊转诊人数，支持打印、导出功能。（四）门诊护士工作站：1.门诊护士执行单：对病人进行注射确认执行、打印注射单及瓶签，补打处方，录入皮试结果；2.门诊注射执行记录查询：通过条件查询注射记录，支持打印、导出功能；3.门诊注射室用药统计：通过条件查询门诊室用药的统计数据，支持打印、导出功能。（五）出入院管理系统：1.入院登记：登记病人的入院诊断信息，支持医保入院、出院召回、撤销出院、退院，可修改病人类别，设置固定费用等功能；2.按金管理：支持收取病人按金、作废按金、打印按金单据；3.费用透支登记：可开放欠费病人的费用限制，可修改和删除透支记录；4.住院按金查询：通过条件查询住院按金记录，支持打印、导出；5.中途结算：结算病人住院期间所发生的费用，支持医保病人费用上传、打印发票；6.出院结算：结算病人住院期间所发生的费用，支持医保病人费用上传，收费打印，退费注销等功能；7.出入院病人查询：通过条件查询出入院病人信息，支持打印、导出；8.住院发票查询：通过条件查询住院发票信息，支持打印、导出；9.住院费用明细查询：通过条件查询住院费用明细，支持打印、导出；10.住院收入查询：通过条件查询住院收入情况，支持打印、导出；11.转科病人查询：通过条件查询出转科病人情况，支持打印、导出；12.医保即时收费查询：通过条件查询医保费用情况，支持打印、导出；13.医保结算信息实时查询：通过条件查询住院医保结算信息，支持打印、导出。（六）住院护士工作站：1.护嘱管理：护士开护嘱、补录费用，发送药品申领单至药房，支持打印护嘱单和执行单，可作废护嘱，查看药品说明书、保存套餐、修改时间等；2.查对医嘱：护士录皮试结果、审核医嘱，审核后药品会自动生成领药申请单，支持取消审核，已发药的医嘱护士不能取消审核；可选择性审核，全区发送，支持删除费用、插入材料费等；3.中药处方查询与审核：支持查询和查对审核医生所开的住院中药处方，支持取消审核，打印服药单；4.床位一览：对病人进行床位分配、调换床位、转科、出院、包床等操作，对病危、病重的病人床位会有颜色标示；5.记账管理：对总的医嘱内容进行核对和实收、退费、费用合并，支持取消退费、打印等功能；6.新生儿登记：登记新生儿的基本信息，打印出生证名，可进行修改、删除；7.病房日志维护：查询病房人数的日志情况，可进行修改、导出，可查看入院明细、出院明细、转出明细等；8.申请单退药：进行退药申请，申请单传到药房；支持打印，可查看未退汇总与未退明细；9.医嘱执行：通过选择输入条件，对病人的医嘱进行执行确认，执行确认后会生成费用，支持取消执行，可打印瓶签、输液卡等各类执行；10.床位查询：通过条件查询床位情况，可选择科室进行查询；11.辅助科室项目查询：通过条件查询辅助科室项目的情况，可打印、导出；12.医嘱费用查询：审核医嘱费用，可打印、导出、查看病史；13.体温单：记录在院体温单数据，可自动生成体温图，可修改、删除、打印；支持修改入院、转科、出院时间；14.新生儿体温单：记录新生儿体温单数据，可自动生成体温图，可修改、删除、打印；15.体温单查询：通过条件查询体温单。（七）住院医生工作站：1.医嘱管理：录入长嘱和临嘱，支持删除、作废、停止医嘱；无处方权的医嘱登记要经过上级医生进行审核，可查看药品说明书，可维护套餐，可输入记事医嘱，支持对医嘱进行复制粘贴，录入出院通知单，查看检查、手术申请等，可以填写传染病报告卡；2.住院中药处方：录入中药处方，可修改、删除处方项目，可查看上张、下一张处方；3.电子病历：书写、提交、打印出入院记录、病程记录、手术记录、知情文件，可查看我的任务列表，可调用病历模板、维护病历模板等；4.病历浏览：可查看出入院病人的病案；5.病历关键字查询：可输入病历关键字对病人病历进行查询，可打印；6.病历质量检查控制：根据条件查询出（重度、中度、轻度、完整）病历，可对医生发送消息；7.评分标准：对评分标准进行修改、打印、导出；8.住院医嘱查询：通过条件查询住院医嘱信息，支持打印、导出；9.病案首页：书写病案首页，支持导出、打印等功能；10.医嘱修改记录查询：通过条件查询医嘱修改记录情况，可对记录进行打印、导出；11.长期医嘱打印：通过条件查询出长嘱，进行打印、导出；12.临时医嘱打印：通过条件查询出临嘱，进行打印、导出。（八）药房管理系统：1.领药申请：药房向药库申领药，支持修改、删除、导入、导出、打印等功能；2.药房退药：药房退药至药库，审核减库存，支持修改、删除、导入失效药品、打印等功能；3.报损出房：药房进行报损出房，审核减库存，可修改、删除、打印、导入等功能；4.调拨出房：药房之间进行药品调拨，需审核，支持导入、打印等功能（出药药房默认是当前登录的药房）；5.调拨申请：向同级药房进行调拨申请，需审核，支持导入、打印等功能（接收药房默认是当前登录的药房）；6.科室领药：门诊配药房导入注射室的用药申请，支持导入、修改、删除、打印等；7.科室退药：科室进行退药操作，支持门诊导入、打印等功能；8.住院发药：对住院病人进行发药、退药，可选择退药数量、发药科室，打印瓶签、汇总单等，打印长嘱、临嘱；9.住院退药：对住院病人进行退药处理，可取消退药；10.住院发药查询：通过条件查询住院发药情况，支持打印、导出；11.其他入房：新增、修改、删除其他入房单据，需要写入库原因，审核后库存增加，支持打印；12.其他出房：新增、修改、删除其他出房单据，审核减库存，支持导入、打印：13.住院中药发药：对中药处方进行发药，支持退药、打印处方、打印煎药证；14.住院中药发药查询：根据病人、科室等条件查询住院中药发药情况，支持打印导出；15.药房药品设置：支持查询、新增西药或中药的品种，支持删除、打印；16.出入房审核：对药品出入房单据进行审核；17.药房盘点：对药房库存数量进行盘点，支持修改、删除、结账记账，打印盘点单、打印汇总单、打印空白盘点单等功能；18.药房药品明细账查询：通过条件查询药房药品明细账，支持打印、导出；19.业务查询：药房药品库存查询，药房单据查询，药房历史库存查询，药房发药查询，进出日志查询，门诊注射发药记录查询，门诊注射室未执行的处方；20.统计报表：门诊药房工作量统计，住院中药工作量统计。21.辅助科室发药查询：根据条件查询出辅助科室发药情况，可打印、导出；22.出院带药查询：根据住院病人信息等条件查询出院带药情况，可打印；23.药房库存不足警报：对库存不足的药品会自动提示给药房用户；支持短信通知、Email通知、打印、导入等功能；24.药房有效期查询：根据药品、失效前天数查询出药品；25.药房调价查询：通过条件查询药房调价情况，支持打印、导出；26.药房药品有效期警报：对药品有效期提前发出警报提示药房用户；支持短信通知、Email通知、打印、导入等功能。（九）药库管理系统：1.采购申请：从医药公司申请药品，可导出、打印采购申请单；可导入库存不足的药品；2.采购入库：可调入采购申请单到采购入库中，可对单据进行审核、打印；3.药品购进验收记录：通过条件查询药品购进验收记录，可打印、导出；4.领药出库：用于对药房领药申请单进行出库，可新增出库单、修改、删除、打印等功能；5.退货出库：对退回给医药公司的药品进行退货出库，可修改、删除、打印，审核后减库存；6.报损出库：药房进行报损出库，审核减库存，可修改、删除、打印、导入等功能；7.其他入库：新增、修改、删除其他出库单据，审核库存增加，支持导入、打印；8.出入库审核：对出入库单据进行审核，使出入库单据生效，可打印；9.药库盘点：盘点到某一个日期的库存量，记录药库盘点信息，支持打印盘点单、汇总单、空白盘点单等功能；10.发票管理：管理发票对应的单据明细，可删除、打印、导出；11.入库发票查询：主要用来查询入库发票的使用情况，可打印、导出；12.药库药品明细账查询：主要是用来查询药品具体的明细费用，按照各种配置的申领算法，支持查询、打印；13.进出日志查询：主要是用来查询药品出入库日志，支持查询、打印、导出；14.药库单据查询：主要是用来查询药品出入库单据，支持查询、打印、导出；15.药库药品库存量查询：主要是用来查询药品库存量，支持查询、打印、导出库存明细等功能；16.药库历史库存查询：主要是用来查询药库历史库存量，支持打印、导出；17.药房药品库存量查询：用来查询药房药品的库存量，支持打印、导出；18.药库有效期查询：根据药品、失效前天数查询出药品；19.药库药品有效期警报：对药品有效期提前发出警报提示药库用户；支持短信通知、Email通知、打印等功能；20.调价历史查询：根据条件查询调价记录，可打印、导出；21.药库库存不足警报：对库存不足的药品会自动提示给药库用户；支持短信通知、Email通知、打印等功能；22.药库库存警报线设置：设置药库药品的库存下限、上限，支持打印；23.药库滞销药品查询：根据药库、消耗率、存储天数查询滞销药品，可打印、导出；24.定时调价：对药品作定时调价计划，可立即调价，可打印、修改、删除。（十）临床辅助决策支持系统：把“BMJ”BP系统深度结构化，引导医生从症状处方建立诊断假设，再告诉医生怎么去提供证据（症状和检查）证明自己所选的诊断假设，直至最终确诊，可以有效防止误诊和漏诊，对于不能确诊的病人指引医生转诊到高级别综合医院。对确诊的病人，会按病人组别开出明确的治疗方案提供给医生参考。（十一）报表中心：系统提供多种实时报表、门诊、住院、医生收入与工作量的统计；门诊、住院收费员交款提交，收费员的相关报表；门诊、住院病人费用的相关报表；出入院情况报表，护理、药房、药库等相关报表的查询；输入各种不同的护理、药房、药库等相关报表的查询；输入各种不同的条件，查询出不同的记过，都可以进行打印、导出功能。（十二）基础资料设置：1.仓库药（物）品维护：对药品的基本信息，药品用法，对应病人类别、科室、医保比例等信息进行维护；2.医疗项目维护：对医疗项目的基本信息，用法，对应病人类别、科室、医保比例等信息进行维护；3.其他项目维护：对其他项目（材料）的基本信息，用法，对应病人类别、科室、医保比例等信息进行维护；4.项目状态设置：对处方项目的有效标志、院内使用、禁止临床使用、限于套餐使用等进行设置，可修改、导出；5.项目新开与屏蔽记录：通过条件查询项目新开与屏蔽记录，可打印、导出；6.项目查询：通过条件查询项目信息，可打印、导出；7.套餐维护：新增、修改套餐内容，可维护成个人所有、科室所有、公共，支持打印；8.基本表维护：对居民信息基本表、库存管理、医院管理、项目、收费、诊疗相关的信息进行维护，可打印、导入、导出；9.角色权限设置：对不同科室进行系统各模块操作权限进行设置；10.用户权限设置：设置用户的使用角色和所属科室及登录密码；11.发票管理：设置对应部门的发票起始号和结束号，可修改、删除；12.设置门诊西药房所有科室打印到默认窗口：设置门诊配药房所有科室打印默认到窗口，设置目标打印机；13.设置报表打印机：设置报表对应的打印机地址及纸张信息；14.修改密码：修改当前用户的密码。《第三方系统接口清单》，记载如下：1.医保接口：采用医保Server通过医保专用网连接到医保平台。2.LIS接口，采用LIS>>集成平台>>XMLServer（HIS中间服务）>>HIS的模式单项获取信息，LIS的结果存入云端，HIS以链接地址+参数的模式在云端查看。3.PACS接口：采用PACS>>PACSServer（中间层）>>集成平台（云端）>>XMLServer（HIS中间服务）>>HIS的模式单向获取信息，PACS的结果存入局域网，HIS以链接地址+参数的模式在局域网内查看。4.SPAD接口：采用SPD>>SPDServer（SPD中间层）>>集成平台（云端）>>SPDServer（HIS中间层）>>HIS的模式单向模式连接，单设一个SPDServer（HIS端中间层）连接集成平台进行处理，不与之前的XMLServer统一，由SPD定时向集成平台抓取已付费处方信息并在处理之后反馈回HIS端，HIS端的库存被动与SPD同步的模式实现。参照现有模式：被动库存同步、已付费处方单独存放数据库指定表的模式嵌入。HIS不修改流程。5.智慧病区接口：采用移动护理>>Server（护理端Server）>>XMLServer（HIS中间层）>>HIS的模式单向模式连接，使用此直接模式进行交互。HIS不修改流程。6.医务通接口：HIS采用从WebAPI方式从HIS到医务通的单向模式连接，使用此直连模式进行交互。HIS不修改流程。2018年10月份，双方共签订了三份合同，另两份合同为《OA系统委托开发协议》《联合医疗医联体云H**开发服务合同》。双方因前述三份合同产生纠纷，联合公司向本院提起诉讼，本院分别以（2019）粤73知民初1138、1139、1140号立案审理。二、涉案合同履行情况2018年11月9日，联合公司向行心公司支付合同款18万元。在合同履行过程中，双方员工通过微信等沟通云H**系统的开发工作。双方微信聊天记录主要内容如下：2019年3月1日，在名为“联合医联体实施”的微信群中，联合公司询问：医保计划什么时候测试？医保测试需要跟清远医保申请测试，我们需要知道具体测试时间。并告知联合公司某员工：行心公司希望SPD对接、PACS对接测试，拟这边先于行心公司对接起来。行心公司回复：要马上启动清远的医保接口、SPD接口、PACS接口测试，越快越好。接口测试往往是需要不少时间的，因为是多方公司沟通，周期难控制，所以应该尽快进入测试。联合公司回复：收到。我协调。3月12日，行心公司林泳强与联合公司符小虎聊天内容如下：1.林泳强向符小虎发送截图一张，符小虎回复：昨天跟你提的APP接口是最花时间的，您截图给我的这些是系统对接、数据实现，所以东总让我跟您这边沟通评估工作量。林泳强回复：给我详细需求说明书。3月17日，符小虎询问：我们要开发APP，需要您这边提供接口，请问有确定吗？林泳强回复：沟通了，可以做。2.林泳强问：派人测试验收住院系统吗？符小虎答：今天过来。林泳强称：医保事前集中控制系统是签约后政府提出的新要求，工作量不小，应该属于增补合同的内容。今天你们没有测试，明天要安排人测试了。符小虎答：我今天找杜经理和洪秀林确定我们在大数据可以连接云H**，也就是演示数据库，到现在还没收到回复，也就是说无论是连接你的阿里云还是我们的云数据库，都无法正常对通云H**，这样即使测试通过都没法演示。刚才杜经理发来测试包，是走云H**的，我这边安排测试一下。符小虎又称：第一，如果你们的产品到一定程度，我安排测试可以，但明知道你们都没法使用和达不到基本要求，但又要我们派人测试，我没办法安排；第二，……第三，昨天，我让林健玲如实在你们行政办公平台上登记云H**慢的情况，但是结果是我们登记的记录都不存在了，这个给我不好的体验，所以我觉得还是等你们到一定程度我们再当面沟通吧……林泳强回复：以后你也叫他们在OA登记测试发现的BUG吧。符小虎称：我已经让他们关注你们的公众号，从公众号里提发现问题的情况……但如果涉及多个系统，就只能让其他系统用我的账号进去登记反馈情况了。3月8日，联合公司符小虎向行心公司洪秀林（云H**系统开发人员）询问：请问云H**在我们服务器上部署成功了吗？洪秀林称：数据库还在部署。昨晚只传上了数据库备份文件，没部署好。符小虎回复：我这边尽快安排测试一下。你们有测试运行debug包吗？测试运行效果如何？洪秀林回复：测试时流程是通过了。查对医嘱的审核和床位一览的出院的操作偶尔出现了远程服务器返回错误500，最大可能是这两个操作耗时太长而网络导致的。因为它是偶尔出现，就算出现了操作结果也是成功的，刷新一下就看到操作了，而且一样的文件和数据在我们公司是没有出现这个错的。……符小虎回复：主流程上，我们希望是周日演示时能够通过不报错，数据的准确性不做要求。数据一致性在大的方面能通过即可，后期真实测试才是要求必须一致的。次日，符小虎又问：云H**的病历能打开吗？洪秀林称只能保证打开看看，没有测试完。并发送了视频一份。符小虎回复了错误表述及错误源发的信息并称“打开电子病历报错了”。洪秀林称要安装电子病历控件。符小虎回复：一键安装和一键破解都是乱码哦。……2019年3月9日，行心公司杜美娟（云H**系统负责人）告知联合公司符小虎：今天在公司测试了一下，主流程能跑通，从登记入院到出院结算。登录到系统里有点慢，床位一览新增床位保存会报500的错，但是成功的；拉进床位和出院操作也会报500的错，但刷新完也是成功的；医生开长嘱查对医嘱时也会报500的错，但刷新后也是成功的。其他都没有报错。连我们公司的机器都不会报500的错。符小虎询问：云H**能打开电子病历吗？杜美娟称可以打开。又称：没有测过，只测了住院主流程。2019年3月12日，联合公司林健玲询问云H**有新版本吗？行心公司杜美娟回复“暂时没有”并询问“如果三层服务和缓存不放在你们的测试服务器上，那你们有其他服务器可以放吗？”林健玲回复：如果你们还没有整合好，可以先放在远程视频的服务器上。3月13日，在名为“联合医联体实施”的微信群中，行心公司称：请尽快配合把以下接口的测试环境搭建给我们测试：医保、事前、病案、Spd、Pacs、Lis、智慧病区、居家照护。联合公司回复：医保环境需测试卡，清远医院已在申请；事前审核已提供接口，请直接调用接口确认是否正确……；病案的接口测试在落实。3月29日，联合公司陈向东在名为“联合医联体实施群（24）”的微信群发送信息如下：“请集中精力解决医联体问题先了。医院云H**不急了。还有两天就要交报表给政府了。”6月4日，联合公司陈向东通过微信向行心公司林泳强发送了云门诊合同、OA系统合同、HIS系统合同等三份解除协议。6月5日，陈向东询问OA和HIS实际工作量？林泳强发送了“联合云H**工作总结”及“联合OA工作总结”两份文档给陈向东。行心公司提交了落款为2019年6月10日《履行合同催告函》及落款时间为2019年7月4日的《关于作废合同及重新签订合同的复函》并提交了QQ聊天记录拟证明其已向联合公司发送相关函件。上述函件中行心公司明确表示不同意解除合同及继续履行合同，同时催促联合公司配合对OA系统、云门诊系统及云H**系统进行验收并支付合同款；QQ聊天记录截图（群成员为Ken、LCF、行心科技罗姐）显示对话主要内容如下：Ken询问联合是不是应该发个催告要求他们履行合同，LCF回复：联合的已经发过复函了我们可以再次催告并询问催告函是和复函一起邮寄还是微信发？Ken回复，和之前的复函一起邮寄过去。LCF答：好。联合公司对QQ记录的真实性不予确认，亦否认收到上述函件。2019年7月12日，联合公司通过中国邮政速递向行心公司送达律师函，就双方约定的含涉案云H**合同在内的三个合同（另两个合同为《OA系统委托开发协议书》、《联合医疗医联体云门诊开发服务合同》）履行事宜致函。该函涉及云H**合同的主要内容为：云H**合同签订于2018年10月1日，约定合同签订之日起5个月内正式上线，且联合公司已经支付了第一期款项18万元，截至今日行心公司未能按时交付系统，已严重违反交付期限及相关约定。请行心公司收到函后5个工作日内积极按照上述合同约定完成交付义务，同时按合同违约责任条款约定支付违约金，其中，云H**合同逾期交付累计违约金为6万元。请行心公司收函后及时履行交付系统义务并支付违约金，否则联合公司将依法解除合同，并要求行心公司退款及承担赔偿损失等责任。行心公司确认收到该律师函。2019年9月26日，行心公司发送了三份文档给联合公司，三份文档分别是“联合众思OA项目总体计划表”、“联合云门诊项目总体计划”以及“联合清远医院信息系统云his计划”。其中，联合清远医院信息系统云his计划内容为：1.制定计划阶段，开会核对目前存在问题、签名确认问题，实施时间为2019年10月10日至11日；2.开发测试阶段，对问题清单开发测试，实施时间为2019年10月11日至11月10日；3.验收阶段，对照问题清单进行验收、结算第一期合同，实施时间为2019年11月11日至14日；4.维护阶段，进入维护阶段，与客户和客服部交接，问题在微信公众号登记受理，客户和客服部确认后撤离，项目移交给客服，实施时间2019年11月22日至2020年7月31日。注：开发内容不能偏离行心目前使用的OA系统。为证明涉案云H**系统未按合同约定按时按质交付且未按反馈问题及时处理、无法满足交付验收标准，联合公司提交了如下证据：1.系统测试安装包（仅有药房运行主文件His2.EXE）。2.系统问题（对应版本测试住院主流程情况）。版本为：V0.1.693，提供运行包中软件执行主文件为：His2.exe，修改日期为2019年3月9日。3.系统问题补充（系统负责人沟通截图、与沟通对应问题系统截图）。版本为：V0.1.693，提供运行包中软件执行主文件为：His2.exe，修改日期为2019年3月9日。行心公司质证后对上述证据的真实性、关联性均不认可，其认为其开发的云H**系统有多个版本，其仅向联合公司提供了V0.1.693版本的测试包，对证据中的沟通截图真实性、合法性、关联性均无异议。为证明涉案云H**系统已于2019年3月8日交付了测试包、双方经协商同意延迟实施系统且该系统主要功能是合格的，行心公司提交了如下证据：1.微信聊天记录截图。即2019年3月8日、12日、17日符小虎与林泳强的聊天记录（具体内容见前述查明事实）。2.微信群聊记录截图。即名为“联合医联体实施群（24）”微信群2019年3月29日的聊天记录（具体内容见前述查明事实）。3.云H**任务表。该证据是从行心公司OA系统中“开发任务管理”中导出的数据，数据附有原始ID号，导出的任务表有8726条数据。证明在合同履行过程中联合公司针对云H**系统所反馈的问题及提出的功能需求通过系统录入的方式反馈给行心公司，行心公司根据该反馈进行开发和解决。4.V0.1.693版云H**系统。拟证明行心公司开发的云H**系统主要功能合格。联合公司质证后认为，证据1为微信群聊中截取的部分内容，双方沟通后行心公司一直未履行合同，未按照合同开发清单按时交付软件给联合公司，而且双方沟通是关于云门诊的内容，与云H**无关；证据2是双方沟通群中截取的部分内容，该微信群是双方在软件测试出现异常时沟通所用，从截图内容看直到2019年3月29日，云H**系统都未开发完，也没有交付给联合公司，根据云H**合同10.2条的约定，对合同的任何修改应以双方法定代表人或委托代理人的书面文件为准，故双方并没有变更过软件交付时间；证据3为行心公司系统内的内容，是其单方提供的统计数据表，真实性无法确认。三、涉案软件勘验情况2020年5月14日，本院组织双方当事人对涉案软件进行勘验，本院依法指派技术调查官参与了此次勘验，双方对此均无异议。双方均同意以2019年3月9日行心公司最初部署到联合公司电脑上的版本进行勘验，亦同意以技术调查官及双方技术人员作为专家辅助人的方式进行勘验。当日，因数据库等方面的原因无法勘验涉案云H**系统。5月21日，双方在本院搭建软件运行环境，由行心公司将云H**系统部署到本地电脑进行勘验，双方对勘验软件及版本均无异议，双方亦确认云H**系统可以正常登陆使用。5月22日，双方以云H**合同附件一系统功能清单及第三方系统接口清单记载的内容对涉案软件存在的主要问题逐一进行勘验，具体勘验过程如下：1.门诊挂号系统中门诊挂号模块，联合公司主张其中“设置挂号起始发票”功能仅支持一个挂号窗口的发票有效，不支持多个挂号窗口同时挂号，挂号后没有任何指引信息给患者。行心公司称其他医院是如此操作的，若联合公司有需求可添加上述功能。2.门诊医生工作站系统，打开该系统即弹出提示窗口，提示TXTEXT控件为试用版有使用期限。行心公司回复会在正式使用的版本里面重新注册。3.门诊医生工作站系统中的“病人处方查询”模块，联合公司称该功能未实现，输入病人名字不能查出处方信息。行心公司称系统默认医生只能查询其所在科室的病人数据，可以通过设置医生权限使其能查到全院病人的数据，行心公司确认输入病人名字不能查出处方信息。4.门诊收费系统中的“门诊收费”模块，联合公司称门诊收费和退费时出现两次错误提示窗口，提示云服务错误。行心公司确认存在该问题，但认为该提示为打印错误提示，因为勘验电脑没有连接真实的打印机，仅连接了虚拟的打印机来测试。5.门诊收费系统中的“门诊收费”模块，联合公司称药房收不到退费或收费后的单据，药房的发药和输液无法验证。行心公司确认存在该问题，但认为该问题是由于上述打印错误所致。6.门诊收费系统中的“门诊费用明细查询”模块，联合公司主张查询时会出错，提示错误信息为ORA-06550语句错误。行心公司称该问题系因前端程序及后台布置的版本不一致引起，不是严重致命问题，可通过报表系统查询。7.门诊护士工作站系统无法测试，行心公司称因第四个问题的错误数据无法传输导致无法测试，该功能已实现，只是因为没有数据而无法测试。8.住院医生工作站系统中的“电子病历”模块，联合公司称书写下载模板后弹出错误提示窗口，提示错误信息为ORA-01400语句错误。行心公司确认存在该问题，因为下载电子病历是辅助功能。9.出入院管理系统中“入院登记”模块，出院召回功能报错。行心公司确认存在该问题，主张系安装问题导致且不属于主要功能。10.出入院管理系统中的“出院结算”模块，退费注销功能不能退费。行心公司确认存在该问题，主张系安装问题导致。11.药库管理系统中的“药品购进验收记录、调价历史查询”两个模块，通过查询条件查不到记录。行心公司确认存在该问题，主张是系统的BUG，并认为不是系统主要功能。12.药房管理系统中的“药房盘点”模块，联合公司主张其中的结转记账功能报错，提示错误信息为ORA-26010。行心公司确认存在该问题，主张系安装问题导致。13.第三方系统接口清单中无接口对接，所有接口都没有实现对接。行心公司确认没有接口，但认为联合公司没有提供所需要的接口场景，所以没有开发，只要联合公司提供接口文档和场景需求，其即可开发。勘验时，联合公司当庭提交了云H**测试包及云H**系统问题PDF文件，其主张该测试包系行心公司在2019年3月9日交付的版本（而非勘验软件版本），该版本无法运行。行心公司对该测试包的真实性、关联性均有异议，其认为该测试包文档中修改日期显示的修改时间一栏是紊乱而非同步的，无法确认与行心公司提交的版本是否一致；对云H**系统问题PDF文件的真实性、关联性亦不予确认。庭后，联合公司提交了《开庭勘验软件及产生问题的说明意见》。该意见主要内容如下：勘验软件为行心公司于2020年5月21日部署到行心公司电脑上的，联合公司没有收到过该软件，也从未部署到联合公司测试服务器上；联合公司仅收到过行心公司提交的云H**测试客户端（即联合公司提交的文件日期为2019年3月29日的云H**测试包），因行心公司将运行环境全部撤除，该系统已无法正常运行。为了配合勘验，仅对云H**主流程进行勘验，而忽略了细节。对勘验时出现的问题说明如下：第一个问题，设置挂号起始发票仅支持一个端口号，即使用该系统仅支持一个窗口挂号，不符合挂号要求。第二个问题，门诊医生工作站弹出电子病历试用期提示，还没有交给客户的产品即已过期，虽然行心公司解释交付后可以续费，但该行为缺乏职业精神。第三个问题，病人处方查询功能是用于查询病人在不同科室的处方信息，对医生临床看诊有直接的参考、指导作用。第四个问题，门诊收费、退费弹出两次错误提示，实际是主流程数据传递错误，属于软件的灾难性的问题，该错误导致数据无法流转到药房，后续门诊护士站无法测试。第五个问题，药房无门诊收费单据无法测试药房发药、门诊护士站，主流程灾难性问题，可以确定云H**系统严重不合格。第六个问题，门诊费用查询报错，无法使用，与费用相关的功能不应出现错误，可以认定软件不合格。第七个问题，门诊护士站，因主流程灾难性问题，无法勘验。第八个问题，电子病历下载模板功能异常，单机版的云H**系统出现该问题说明软件不合格。第九个问题，出院召回功能报错，该功能属于主流程的收尾功能，缺少该功能直接影响医院运营，该故障属于住院流程中的灾难性问题。第十个问题，出院结算中的退费注销功能报错会直接影响医院运营，该功能是次要流程中必不可少的。第十一个问题，药库管理系统中的药品购进验收记录、调价历史查询都是对药品数据信息的验证，属于严重的BUG。第十二个问题，药房的结转记账功能报错，属药房管理的必要环节，影响医院的整体运作，属于灾难性错误。第十三个问题，第三方接口未开发，联合公司于2019年1月9日提供另一份完整的接口《云H**接口.rar》（云门诊、云H**均为同样接口）给行心公司杜美娟。该问题所附微信截图显示：行心公司杜美娟于2019年1月2日向联合公司员工发送截图一张并称“这些是你前段时间发我的，我感觉文档有点乱，你那边能按你上面提供的接口分类成每个文件夹发给我吗？这样比较清楚，给到开发人员也不会漏掉。”该截图显示联合公司发送文档包括：智能审核补充通知.rar；关于《关于推进我市医疗保险智能审核系统对接工作的通知》的补充通知.pdf；平安智慧事前事中系统医院改造文档.docx；关于全面推进我市医疗保险智能审核系统对接工作的通知.pdf；SPD接口方案（webservice）20181115.docx；联合医疗医联体云门诊功能清单-20181109.docx；清远社保病案首页上传接口规范.doc；MIS-CS-2015-7-SS-JK-广东省定点医药机构医保接口规范2018-07-24.doc；联合众思HIS系统SPD接口说明（v1.4）.doc等。联合公司员工于1月9日发送了一份“云H**接口.rar”文档。对上述说明意见，行心公司回应如下：软件的环境部署与软件的性能不是同一问题，并不能以环境部署出现异常而认为云H**系统不合格。勘验中提出的十三个功能问题均不是系统的主要功能，可以通过完善和维护的方式进行修复，系统主流程并不会影响客户正常的业务使用。在勘验中出现部分问题是因为系统环境和配置参数导致，建议重新勘验。云H**系统是成熟的产品，有两百家二级医院成功案例，产品成熟度经过市场验证。云H**系统是达到正常使用标准的。四、其他事实诉讼中，双方就相关问题陈述如下：关于云H**合同签订时间，双方均确认合同签订时间为2018年10月15日。关于合同性质和效力，双方均确认云H**合同是计算机软件委托开发合同，合同合法有效。关于云H**合同开发要求及验收标准，双方均确认是按照涉案合同附件一《系统功能清单》及第三方系统接口清单的约定进行开发并进行验收。关于云H**软件开发周期，联合公司主张是从2018年10月1日起5个月内，即至2019年3月31日止，行心公司则认为是从2018年10月18日计算5个月，即起至2019年4月17日止。关于合同解除依据，联合公司主张行心公司迟延交付软件，构成根本违约；行心公司不同意解除涉案合同，但同意终止履行。行心公司于2019年8月29日收到本案起诉状副本等诉讼材料。本院认为，联合公司与行心公司签订的《联合医疗医联体云H**开发服务合同》即云H**合同是双方当事人的真实意思表示，其内容未违反法律法规的强制性规定，合法有效，双方均应按照约定全面履行各自所负合同义务。涉案合同约定行心公司为联合公司开发云H**系统软件，根据合同权利义务的约定，涉案合同应为计算机软件开发合同。根据双方的诉辩意见，本案争议焦点为行心公司交付的云H**系统是否符合涉案合同约定的交付标准、行心公司是否存在迟延履行的违约行为、涉案云H**合同是否应予解除以及合同解除后的责任承担问题。一、关于云H**系统是否符合合同约定的交付标准行心公司主张其于2019年3月8日交付的云H**系统主要功能是合格的，故主张其已经按照云H**合同的约定履行了交付义务，而联合公司则认为行心公司仅交付过一个不能运行的测试包。对此，本院分析如下：关于交付标准问题，联合公司、行心公司均确认云H**合同开发要求及验收标准是根据涉案合同附件一《系统功能清单》及第三方系统接口清单的约定进行开发并进行验收，故云H**系统是否符合合同约定应当以上述清单记载的内容进行判断。本案勘验时系由行心公司将云H**系统部署到本地电脑进行勘验，双方对勘验软件及版本均无异议，故该勘验结果可以作为判定行心公司开发的软件是否符合合同的约定。至于行心公司重新勘验的建议，从勘验过程看，本院在2020年5月14日即组织双方当事人对涉案软件进行勘验，双方均同意以2019年3月9日行心公司最初部署到联合公司电脑上的版本进行勘验，但因数据库等问题导致未进行勘验。同年5月21日，双方在本院搭建软件运行环境，由行心公司将云H**系统部署本地电脑进行勘验，双方对勘验软件及版本均无异议，双方亦确认云H**系统可以正常登陆使用。次日，双方在技术调查官参与下完成了云H**系统的勘验。可见，勘验云H**系统前已经给予双方充足的时间准备且勘验时双方对勘验的系统环境等均未提出异议。故行心公司重新勘验的建议缺乏依据，且联合公司亦不同意对云H**软件重新勘验，故对行心公司该项建议，本院不予支持。经勘验，云H**系统存在13个方面的问题，故本院将根据该勘验结果判定行心公司交付的云H**系统是否符合合同约定的交付标准。根据合同约定及双方履行情况，就上述问题具体分析如下：1.门诊挂号系统中的“设置挂号起始发票”功能，仅支持一个挂号窗口的发票有效，不能支持多个挂号窗口同时挂号。因涉案合同中并未详细约定该功能应支持的窗口数，故可以认定该功能符合涉案合同的约定。2.打开“门诊医生工作站”提示TXTEXT控件为试用版有使用的期限，该错误提示为第三方控件时效性问题，不属于系统功能性问题，故亦可认定该功能符合涉案合同约定。3.门诊医生工作站中的“病人处方查询”功能，输入病人名字无法查出处方信息，行心公司亦确认存在该问题，故应认定该功能不符合涉案合同约定。4.门诊收费和退费打印时弹出云错误提示窗口，但打印内容没问题。行心公司认为该错误提示系因法庭现场电脑没有连接真实打印机导致，该解释合理，故应认定该功能符合涉案合同的约定。5.药房收不到收费或退费后的单据以及药房的发药和输液无法验证的问题，行心公司确认该问题存在并称是由于前述打印错误导致，因该解释真实性难以确定且行心公司亦未提交其他证据佐证，故应认定该功能不符合涉案合同约定。6.查询门诊费用明细时出错，行心公司称系前端程序和后台布置的版本不一致导致，且可通过报表系统查询，因该解释真实性难以确定且行心公司亦未提交其他证据佐证，故应认定该功能不符合涉案合同约定。7.门诊护士工作站无法测试，行心公司确认存在该问题并称系由于前述打印错误导致，并称该功能已实现，仅因没有数据无法测试。因该解释真实性难以确定且行心公司亦未提交其他证据佐证，故应认定该功能不符合涉案合同约定。8.住院医生工作站下载电子病历模板时弹出错误提示窗口，行心公司确认存在该问题，故应认定该功能不符合涉案合同约定。9.出入院管理系统中的“出院召回”功能报错，行心公司确认存在该问题但称是安装问题导致，且该功能不是主要功能。因该解释真实性难以确定且行心公司亦未提交其他证据佐证，故应认定该功能不符合涉案合同约定。10.出入院管理系统中的“退费注销”功能不能退费，行心公司确认存在该问题并称是安装问题导致。因该解释真实性难以确定且行心公司亦未提交其他证据佐证，故应认定该功能不符合涉案合同约定。11.药库管理系统中的药品购进验收记录和调价历史查询功能中查不到记录，行心公司确认存在该问题，故应认定该功能不符合合同约定。12.药库管理系统中的结转记账功能报错，行心公司确认存在该问题但称系安装问题所致，因该解释真实性难以确定且行心公司亦未提交其他证据佐证，故应认定该功能不符合涉案合同约定。13.行心公司确认未按照“第三方系统接口清单”开发该清单所载接口，其认为是因为原告没有提供接口应用场景，亦没有提供环境配合行心公司测试及演示。联合公司则认为其已配合行心公司开发需求提供接口文档，且集成平台系统随时可以接入云H**系统。根据双方微信聊天记录等证据，本院认为，首先，行心公司杜美娟曾于2019年1月2日发送截图一张并称因截图上文档有点乱而希望联合公司按接口分类提供相关文档，联合公司于同年1月9日发送了云H**接口文档给行心公司。从上述截图包括联合众思HIS系统SPD接口说明、清远社保病案首页上传接口规范等文档，可见，在2019年1月2日前联合公司即已经发送了云H**第三方系统接口清单给行心公司，并于1月9日按照联合公司要求再次发送了第三方系统接口清单。其次，名为“联合医联体实施”的微信群聊记录显示，行心公司于2019年3月1日要求马上启动清远医保接口、SPD接口、PACS接口等第三方接口的测试，联合公司回复协调配合测试；3月13日，行心公司再次提出医保、事前、病案、SPD、PACS、LIS、智慧病区、居家照护等接口测试，联合公司回复事前审核接口已提供、医保环境测试卡在申请、病案接口在落实，可见，联合公司曾按照行心公司要求配合接口测试。而在此后的聊天记录中未显示行心公司对接口测试提出要求或进一步与联合公司协商接口开发的相关问题。“第三方系统接口清单”中的接口是实现将多个第三方系统中的数据单向传输到涉案云H**系统中，再根据涉案软件具体需求将这些数据应用于具体场景中。这些第三方系统接口的开发需要双方共同协商确定。现有证据显示联合公司已经按照行心公司要求提供第三方接口文档并配合其进行测试，但行心公司并未提交证据证实上述文档不符合开发需求或其对接口测试提出异议。因此，行心公司辩称未完成第三方接口开发原因系因联合公司未提供第三方接口文档、不配合测试等缺乏依据，本院不予采信。故应认定该功能不符合涉案合同约定。综上，勘验的云H**系在上述十个功能上存在问题，上述问题导致该软件无法正常运行使用，故应视为云H**系统不符合涉案合同约定的交付标准。二、关于行心公司是否存在迟延履行的违约行为联合公司主张行心公司存在延期交付云H**系统的违约行为，构成根本违约；而行心公司则辩称联合公司主动放弃工期交付，让行心公司先把云门诊部分以及一些接口完成后再上线HIS系统，其不存在迟延履行。对此，本院分析如下：首先，联合公司主张云H**系统的开发周期是从2018年10月1日起5个月内，即至2019年3月31日止，而行心公司认为是从2018年10月18日计算5个月，即起至2019年4月17日止。根据涉案合同第2.1条约定涉案项目“2018年10月1日正式开始实施，截至5个月内正式上线”，行心公司主张从2018年10月18日开始计算开发周期不符合前述约定，本院不予支持。其次，行心公司辩称联合公司同意延期开发并提交了微信聊天记录等证明，该记录显示联合公司员工于2019年3月29日在名为“联合医联体实施群（24）”的微信群发送了“请集中精力解决医联体问题先了。医院云H**不急了。还有两天就要交报表给政府了”等信息，从上述内容看仅能得出医联体存在的问题优先于云H**系统解决的结论，并不能得出双方协商一致延迟了云H**系统交付日期。云H**合同第10.2条约定关于“对本合同的任何修改或解除要求，均应以双方法定代表人或授权代理人的书面文件为准”，且涉案软件的交付时间为计算机软件开发合同的核心条款，在没有其他证据佐证的情况下，故上述微信聊天记录不足以证实双方协商一致变更了云H**系统的交付时间。故，云H**系统的交付时间应为2019年3月31日。第三，关于是否构成延迟交付的问题，本案勘验的云H**系统是由行心公司提供并部署在本地电脑上，其主张该系统为2019年3月9日测试包版本，但其未提供详细说明或相关证据证实勘验软件的版本，故无法确认其开发完成时间。即使如期所属系2019年3月9日开发完成，但因云H**系统勘验存在多方面的功能问题，不能视为其在约定的期限完成了涉案软件的开发，故亦不能视为其在合同约定的开发周期内完成了云H**系统的开发。综上，联合公司在2019年7月12日向行心公司送达律师函催告履行并要求行心公司在收到函件后5个工作日内完成云H**合同约定的交付义务并支付逾期交付的违约金，而行心公司并未在上述催告时间内履行交付云H**系统的义务，构成根本违约。三、云H**合同是否应予解除及解除后的责任承担《中华人民共和国合同法》（以下简称《合同法》）第九十四条第（四）项规定，当事人一方迟延履行债务或者有其他违约行为致使不能实现合同目的，守约方有权解除合同。本案中，联合公司主张行心公司未按期交付符合涉案合同约定的云H**系统，构成根本违约，其依法有权解除合同。如前所述，行心公司未按照合同约定完成涉案软件的开发，构成根本违约，联合公司有权依据《合同法》第九十四条第（四）项的规定解除涉案云H**合同。关于合同解除时间，联合公司提起本案诉讼时明确主张解除涉案合同，行心公司于2019年8月29日收到本案起诉状副本等诉讼材料，故本院确认涉案合同于2019年8月29日解除。《中华人民共和国合同法》第九十七条规定，“合同解除后，尚未履行的，终止履行；已经履行的，根据履行情况和合同性质，当事人可以要求恢复原状、采取其他补救措施、并有权要求赔偿损失。”第一百零七条规定，“当事人一方不履行合同义务或者履行合同义务不符合约定的，应当承担继续履行、采取补救措施或者赔偿损失等违约责任。”本案中，行心公司构成根本违约，故依法应当承担恢复原状、赔偿损失等民事责任，故，对联合公司要求行心公司退还已支付的合同款18万元的主张，本院予以支持。关于联合公司主张赔偿违约金的问题。《合同法》第一百一十四条第一款规定，“当事人可以约定一方违约时应当根据违约情况向对方支付一定数额的违约金，也可以约定因违约产生的损失赔偿额的计算方法。”涉案合同第9.3条约定，因行心公司技术产品的缺陷或履行合同时，因行心公司原因造成工期拖延，每拖延一天，行心公司需向联合公司支付总价款0.1%的违约金，累计不超过合同总价的20%。行心公司构成违约，联合公司有权依据涉案合同第9.3第1款的约定要求行心公司支付违约金。涉案合同于2019年8月29日解除，故，涉案合同违约金计算期限为2019年4月1日至8月29日。涉案合同总价为60万，据此计算，违约金为600000元*0.1%*151天=90600元,该金额并未超过合同总价的20%。联合公司于本案起诉时主张违约金为6万元，该金额为暂时计算至本案起诉时的金额，现涉案合同的违约金应为90600元，故行心公司应向联合公司支付迟延履行的违约金90600元。综上所述，联合公司的诉讼请求，有事实及法律依据，本院予以支持。依据《中华人民共和国合同法》第九十四条第（四）项、第九十七条、第一百零七条、第一百一十四条第一款的规定，判决如下：一、联合大数据有限公司与广州市行心信息科技有限公司签订的《联合医疗医联体云H**开发服务合同》于2019年8月29日解除；二、广州市行心信息科技有限公司于本判决生效之日起十日内向联合大数据有限公司返还合同款18万元；三、广州市行心信息科技有限公司于本判决生效之日起十日内向联合大数据有限公司支付违约金90600元。如果未按本判决指定的期间履行给付金钱义务，应当依照《中华人民共和国民事诉讼法》第二百五十三条规定，加倍支付迟延履行期间的债务利息。案件受理费5359元，由广州市行心信息科技有限公司负担（该受理费已由联合大数据有限公司预交，本院不作退回，其同意广州市行心信息科技有限公司应负担部分于上述判决履行期限内向其径付）。根据《中华人民共和国民事诉讼法》第二百二十四条和《最高人民法院关于知识产权法院案件管辖等有关问题的通知》第六条的规定，本案需要强制执行的，由广州市中级人民法院或者被执行的财产所在地中级人民法院执行。如不服本判决，可以在判决书送达之日起十五日内，向本院递交上诉状，并按照对方当事人或者代表人的人数提出副本，上诉于最高人民法院。审 判 长  彭 盎人民陪审员  韦志阮人民陪审员  梁建峰二〇二〇年十月十二日法官 助理  李云端技术调查官林奕濠书记员郑志豪书记员钟佳倩