CN113436716A - 医院后勤运营管理生态平台 - Google Patents

医院后勤运营管理生态平台 Download PDF

Info

Publication number
CN113436716A
CN113436716A CN202110987399.7A CN202110987399A CN113436716A CN 113436716 A CN113436716 A CN 113436716A CN 202110987399 A CN202110987399 A CN 202110987399A CN 113436716 A CN113436716 A CN 113436716A
Authority
CN
China
Prior art keywords
data
service
hospital
ecological
management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110987399.7A
Other languages
English (en)
Other versions
CN113436716B (zh
Inventor
马如明
黄奕然
张军锋
曹远泊
王伟江
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nanjing Tiansu Automation Control System Co ltd
Original Assignee
Nanjing Tiansu Automation Control System Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nanjing Tiansu Automation Control System Co ltd filed Critical Nanjing Tiansu Automation Control System Co ltd
Priority to CN202110987399.7A priority Critical patent/CN113436716B/zh
Publication of CN113436716A publication Critical patent/CN113436716A/zh
Application granted granted Critical
Publication of CN113436716B publication Critical patent/CN113436716B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/254—Extract, transform and load [ETL] procedures, e.g. ETL data flows in data warehouses
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/21—Design or setup of recognition systems or techniques; Extraction of features in feature space; Blind source separation
    • G06F18/213—Feature extraction, e.g. by transforming the feature space; Summarisation; Mappings, e.g. subspace methods
    • G06F18/2135—Feature extraction, e.g. by transforming the feature space; Summarisation; Mappings, e.g. subspace methods based on approximation criteria, e.g. principal component analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G06Q10/06393—Score-carding, benchmarking or key performance indicator [KPI] analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G06Q10/06398—Performance of employee with respect to a job function
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • General Business, Economics & Management (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Operations Research (AREA)
  • Tourism & Hospitality (AREA)
  • General Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Game Theory and Decision Science (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Databases & Information Systems (AREA)
  • Evolutionary Computation (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Molecular Biology (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Biophysics (AREA)
  • Epidemiology (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)

Abstract

本发明公开了一种医院后勤运营管理生态平台，涉及医院后勤数据管理技术领域。本发明包括用户端和服务器端，服务器端包括数据管理单元、数据分析单元、应用中心、服务商管理单元、生态业务接入管理单元和生态技术接入管理单元；用户端根据用户类型的不同显示不同的界面，用户类型包括决策者用户、监管者用户和业务用户。本发明是一开放性平台，可实现第三方业务标准、快速地接入和即插即用，解决了医院方对多样化、定制化、专业化等后勤应用业务子系统的快速上线需求，业务运维服务管理单元可实现多独立系统的统一管理、统一展示和多系统间的数据交互，可有效解决现有技术中医院后勤管理困难、业务割裂、信息孤立和多系统独立部署成本高的问题。

Description

医院后勤运营管理生态平台
技术领域
本发明涉及医院后勤数据管理技术领域，更具体地说涉及一种医院后勤运营管理生态平台。
背景技术
医院后勤涉及的业务领域范围非常广泛，包括能源管理、机电系统及设备管理、综合监控、中央运送、医院安保、保洁、被服洗涤、医废处理、环境监测、护工陪护、物资仓储、停车门禁、饮食营养、基建管理等。随着医院规模的不断扩大和互联网IT技术、数字化转型的不断发展，后勤工作在医院的重要性逐步彰显，具体体现在：
1、医院的医疗、教学和科研越来越离不开后勤保障的支撑，后勤保障如果发展滞后会严重阻碍医院的发展，直接关系到国家三级公立医院绩效考核指标体系中医疗质量、运营效率、持续发展、满意度评价等4个方面指标达成；
2、随着医院规模的不断扩大，各类设备不断增多，水、电、气、油等能源消耗也越来越高，通过管理和技术优化，可降低能耗，减少医院运行成本；
3、医院后勤直接或间接给病人及家属提供服务，后勤管理质量与效益体现医院服务水平，关乎医院品牌形象；
4、随着医疗改革的深入，医院的创收能力相应减弱，可通过后勤保障部门大力发展第三产业来提高医院创收。
然而，目前并不存在可满足医院后勤管理实际运营需求的平台系统，现有技术中存在的仅仅是针对医院后勤管理中某一具体的需求的系统，比如医废管理系统、能耗管理系统、财务管理系统等，而不同的系统又是由不同的供应商提供的，系统之间很难做到数据的统一和兼容，使得医院后勤管理工作出现以下问题：
1、管理困难，由于医院后勤管理采用多独立系统的分类管理，使得医院方对安全、品质、服务、人、财、物难以进行一体化集中式精细化管理；
2、业务割裂，后勤业务繁多、系统复杂，难以形成大统一格局；
3、信息孤立，后勤各业务分别采用不同供应商提供的独立系统，各独立系统之间信息封闭，数据无法统一和兼容，无法共享，业务无法打通联动；
4、多系统独立部署成本较高，且多系统之间也无法做到统一管理。
发明内容
为了克服上述现有技术中存在的缺陷和不足，本发明提供了一种医院后勤运营管理生态平台，本发明的生态平台是基于医院后勤管理实际运营需求，实现平台设计一体化、多业务运营一体化以及建设与服务一体化，能有效解决管理困难、数据无法共享共用、信息孤岛、业务无法打通联动、多系统独立部署成本高、操作复杂等问题。本发明提供的医院后勤运营管理生态平台是一开放性平台，其生态业务接入管理单元可实现第三方应用业务标准地、快速地接入和业务的即插即用，解决了医院方对多样化、定制化、专业化等后勤应用业务子系统的快速上线需求，业务运维服务管理单元可实现多独立系统的统一管理、统一展示和多系统间的数据交互，可有效解决现有技术中医院后勤管理困难、业务割裂、信息孤立和多系统独立部署成本高的问题。
为了解决上述现有技术中存在的问题，本发明是通过下述技术方案实现的：
医院后勤运营管理生态平台，包括用户端和服务器端，用户端和服务器端建立数据连接；所述服务器端包括数据管理单元、数据分析单元、应用中心、服务商管理单元、生态业务接入管理单元和生态技术接入管理单元；用户端根据用户类型的不同显示不同的界面，用户类型包括决策者用户、监管者用户和业务用户，决策者用户的用户端界面为管理中心界面，监管者用户的用户端界面为运维中心界面，业务用户的用户端界面为客服中心界面；
所述数据管理单元包括基础数据管理模块、业务运行数据管理模块、指标数据管理模块和系统运行数据管理模块；其中基础数据管理模块为整个生态平台提供基础数据支撑，其管理的数据包括用户数据、组织架构数据、设备设施数据和空间数据；
业务运行数据管理模块中的数据与生态业务接入管理单元中接入的各业务子系统对应，当有新的业务子系统接入到生态业务接入管理单元中，则业务运行数据管理模块中对应增加新接入的业务子系统的数据；
所述指标数据管理模块中的数据包括安全指标数据、品质指标数据、工单指标数据、成本指标数据和能耗指标数据；
所述数据分析单元包括数据处理模块和模型管理模块，所述数据处理模块对数据管理单元中各类数据进行数据清洗、数据建模和/或数据计算处理；所述模型管理模块中包括有安全指标模型、成本指标模型、品质指标模型、能耗指标模型、告警信息分配模型、医院后勤服务指标模型和工单指标模型；数据分析单元中的数据处理模块对数据管理单元中的各业务运行数据进行处理，并根据模型管理模块中设定的各模型分析得到各指标数据，并将分析得到的各指标数据对应存储于数据管理单元中的指标数据管理模块中；
所述应用中心用于展示生态业务接入管理单元中接入的各业务子系统；所述服务商管理单元用于管理生态业务接入管理单元中接入的各业务子系统的服务商；
所述生态业务接入管理单元包括接入管理模块和若干个已接入的业务子系统；所述接入管理模块为待接入的业务子系统提供接入权限管理和接入接口管理服务；接入管理模块获取待接入的业务子系统的对接接口路径信息，通过接口回调的方式将动态验证码、医院租户标识和服务商应用唯一标识传输给待接入的业务子系统中；当待接入的业务子系统调用接入管理模块中的接口时，需要在接口中向接入管理模块传入访问令牌，接入管理模块对待接入的业务子系统进行鉴权；当接入管理模块调用待接入的业务子系统的接口时，在接口中向待接入的业务子系统传入鉴权令牌，待接入的业务子系统根据接入管理模块传入的鉴权令牌进行鉴权认证，鉴权认证通过后，待接入的业务子系统接入到生态业务接入管理单元中；
所述生态技术接入管理单元用于对接入的成熟技术进行管理，包括BIM可视化展示模块、IOT物联网管理模块、CV机器视觉管理模块、知识图谱模块、室内定位模块和AGV机器人管理模块，生态技术接入管理单元根据数据管理单元中的数据对应生态技术接入管理单元中接入的技术模块，并通过该技术模块向用户端发送对应数据信息；
所述管理中心界面中包括安全指标分析菜单、品质指标分析菜单、服务指标分析菜单、人员指标分析菜单、财务指标分析菜单、指标报告报表菜单和综合评价菜单；所述综合评价菜单用于展示业务用户对生态业务接入管理单元中接入的各业务子系统的反馈和评价信息，并对业务子系统提供的服务和整体运营情况进行评价，为决策者用户提供管理决策数据和辅助分析；
所述运维中心界面中包括机电系统和能源系统实时监控菜单、设备告警监控菜单、巡检视频监控菜单和应急响应服务菜单；对后勤各业务子系统运行提供一体化运营监控和评价；所述客服中心界面中包括报修工单下发菜单、巡检工单下发菜单、保洁工单下发菜单、工单管理服务菜单和历史工单分析菜单，实现面向医护病患，打通后勤服务的一站式服务及评价。
所述数据分析单元汇聚业务运行数据管理模块中各接入的业务子系统产生的实时业务数据和业务运行数据管理模块存储的历史数据，对数据进行清洗和格式化处理，并将格式化处理后的数据按照时间、空间、人员、事件、设备和费用六个维度进行整理，并计算各维度下的二级指标的指标值，将指标计算结果反馈至数据管理单元中的指标数据管理模块中，并通过生态技术接入管理单元中对应接入的技术模块向对应的用户展示。
所述生态平台的部署模式包括云端部署模式、院端部署模式和混合部署模式；所述云端部署模式是指将所述生态平台及其生态业务接入管理单元中接入的各业务子系统均部署在云服务器上且所有数据也均保存在云服务器上；所述院端部署是指将所述生态平台及其生态业务接入管理单元中接入的各业务子系统均部署在医院内部网络内的实体或虚体服务器中；所述院端部署根据服务器配置数量和组网模式分为标准模式、完整模式、外网简单模式和内网简单模式四个分支；所述混合部署是指所述生态平台部署在云服务器上，而生态平台的生态业务接入管理单元中接入的各业务子系统部署在医院内部网络内的实体或虚体服务器中。
所述院端部署模式中的标准模式至少需两台服务器，一台服务器作为堡垒网关服务器部署在医院的DMZ区与互联网连通，另一台作为生态平台及其生态业务接入管理单元中接入的各业务子系统的应用服务器及数据库服务器部署在医院的核心区。
所述院端部署模式中的外网简单模式至少需一台服务器，该服务器作为堡垒网关服务器、生态平台的应用服务器及数据库服务器，部署在医院的DMZ区与互联网连通。
所述院端部署模式中的内网简单模式至少需一台服务器，该服务器作为生态平台的应用服务器及数据库服务器部署在医院的核心区，不与互联网连通。
所述院端部署模式中的完整模式至少需要三台服务器，一台作为堡垒网关服务器部署在医院的DMZ区与互联网连通，另外两台分别作为生态平台的应用服务器和数据库服务器部署在医院的核心区。
所述用户端的呈现方式包括App、BIM、WEB、微信公众号、微信小程序、企业微信和钉钉中的任意一种或多种的组合。
所述综合评价菜单中展示的评价信息，是数据分析单元经过下述处理过程得到的：
数据分析单元中的数据处理模块采集接入到生态业务接入管理单元中各业务子系统产生的实时业务数据和存储于业务运行数据管理模块中的历史业务数据，对采集到的实时业务数据和历史业务数据进行校验，过滤掉非法记录后，汇聚成后勤业务数据，保存在数据管理单元的业务运行数据管理模块中，并将校验后的后勤业务数据传输至模型管理模块；
所述模型管理模块将接收到的后勤业务数据，根据按照人员、财务、物资、安全、质量和服务六个维度定义的医院后勤服务指标模型，计算出指标值，并将指标值保存在指标数据管理模块中，且计算出各指标值对应的权重值；
具体是采用层次分析法计算各个指标的权重值，对各个指标的指标值进行归一化处理，再根据各个指标的权重值使用加权平均法，计算出各个指标的加权平均值，最后将加权平均值作为医院后勤服务质量评分，并将医院后勤服务质量评分传输至综合评价菜单中，供决策者用户查看。
所述数据分析单元可根据大量的医院后勤服务质量评分，使用统计学建立医院后勤服务质量评级模型；并将医院后勤服务质量评分输入医院后勤服务质量评级模型中得到医院后勤服务质量评级，将医院后勤服务质量评级结果传输至综合评价菜单中，供决策者用户查看。
所述后勤业务数据包括生态业务接入管理单元中接入的综合监控类业务子系统的告警数据，业务运维类业务子系统的工单数据，患者服务类业务子系统的订单数据，财务管理业务子系统的后勤预算和成本数据、物资库存数据和工程项目数据。
所述生态业务接入管理单元中接入的综合监控类业务子系统包括能耗计量监控、电梯监控、医用气体监控、变配电监控、给排水监控、锅炉监控、空调监控和消防监控；所述告警数据包括告警等级、告警设备名、告警类型、告警系统名、告警事件、告警时间和恢复时间。
所述生态业务接入管理单元中接入的业务运维类业务子系统包括机电运维子系统、医废管理子系统、安保子系统、设备管理子系统、被服管理子系统、清洁服务子系统、运送管理子系统；所述工单数据包括工单类型、工单状态、工单位置、工单内容、工单下单人电话、工单下单人、工单下单部门、工单接单人员、工单下单时间、工单接单时间和工单完成时间。
所述生态业务接入管理单元中接入的患者服务类业务子系统包括护工护理子系统、停车场管理子系统、便利店管理子系统、餐饮服务子系统、共享轮椅管理子系统和陪护床租赁子系统；所述订单数据包括订单类型、订单状态、订单商品、订单内容、订单金额、订单下单人电话、订单下单时间和订单完成时间。
所述生态业务接入管理单元中接入的财务管理业务子系统包括预算管理模块、成本管理模块、物资管理模块和工程管理模块；所述预算和成本数据包括费用年度、费用科目、费用金额和费用时间；所述库存数据包括物资编码、物资名称、物资单位、物资数量、物资单价、物资操作人和物资操作时间；所述工程项目数据包括项目编码、项目名称、项目金额、施工单位、施工内容、项目操作人和项目操作时间。
所述采用层次分析法计算各指标的权重值的具体过程如下：
对同一层次不同指标的重要性进行两两打分，构建判断矩阵，对判断矩阵进行一致性校验，当判断矩阵通过一致性校验的情况下，根据判断矩阵的最大特征根，求解出判断矩阵归一化后的特征向量，作为权向量，其中，所述权向量中包含各指标的权重值。
各指标的指标值计算是利用数学方法将每一种指标通过数据转换公式变换到统一区间，数据转换公式为：
Figure 990444DEST_PATH_IMAGE001
，式中X（
Figure 91606DEST_PATH_IMAGE002
）是原实际指标值，[A,B]为指标对应 的取值范围，
Figure 199239DEST_PATH_IMAGE003
是将X转换到区间[N，M]后的指标值，所有指标都采用相同的N和M，N=0，M= 1。
所述医院后勤服务质量评分表示为
Figure 532131DEST_PATH_IMAGE004
，式中，K为医院后勤服务质量评 分，L表示指标数总数，
Figure 877662DEST_PATH_IMAGE005
表示第
Figure 621496DEST_PATH_IMAGE006
个指标的权重值，
Figure 419688DEST_PATH_IMAGE007
表示第
Figure 759533DEST_PATH_IMAGE008
个指标的转换值。
所述数据分析单元获得多家医院的后勤服务质量的综合评价得分，即第
Figure 959571DEST_PATH_IMAGE008
家医院 评价得分记为
Figure 218514DEST_PATH_IMAGE009
，将这些医院的评价得分从小到大进行排序后计算出1/4分位数、1/2分 位数、3/4分位数，分别记为
Figure 628635DEST_PATH_IMAGE010
、
Figure 631226DEST_PATH_IMAGE011
、
Figure 561136DEST_PATH_IMAGE012
；当医院评价得分
Figure 522139DEST_PATH_IMAGE013
则后勤服务质量 评级为“不合格”；当医院评价得分
Figure 29344DEST_PATH_IMAGE014
，则后勤服务质量评级为“合格”；当 医院评价得分
Figure 963189DEST_PATH_IMAGE015
，则后勤服务质量评级为“良好”；当医院评价得分
Figure 872239DEST_PATH_IMAGE016
，则后勤服务质量评级为“优秀”。
所述数据分析单元中数据处理模块中包括有告警数据采集子模块，所述告警数据采集子模块采集已接入平台的各业务子系统的告警信息，将采集到的告警信息保存到数据管理单元中，并对告警信息进行过滤和分配；将告警信息输入模型管理模块中的告警信息分配模型中，并输出分配结果，并将分配结果反馈至数据处理模块，所述分配结果包括告警通知策略、推送策略和工单处理策略；
所述数据处理模块中的告警数据处理子模块依照模型管理模块反馈的分配结果，向监管者用户推送告警通知消息；告警数据处理子模块和数据管理单元跟踪告警信息的生命周期；告警数据处理子模块根据工单处理策略向对应工单管理模块提交工单派发请求；
所述工单管理模块将告警数据处理子模块提交的工单派发请求派发至与该工单业务对应的业务子系统中，业务子系统生成工单后，将工单信息传输至对应该业务子系统的用户的客户端上，该工单信息在该用户的客服中心界面的工单管理服务菜单中显示；所述工单管理模块跟踪该工单的全生命周期，当工单的状态为已关闭后，工单管理模块将该工单的处理结果回馈至模型管理模块，模型管理模块将回馈的工单处理结果作为告警信息分配模型的优化参数，对告警信息分配模型进行优化。
所述告警数据采集子模块采集的告警信息的来源包括硬件设备告警信息、业务子系统告警信息和业务异常信息；所述硬件设备告警信息是指硬件设备中根据预设阈值的判断产生的告警信息；所述业务子系统告警信息是指生态业务接入管理单元中各业务子系统识别出的违反常态的业务信息；所述业务异常信息是指告警数据处理子模块和工单管理模块中工单状态或告警信息状态超出阈值的信息。
所述告警数据采集子模块采集的告警信息的信息格式包括来源类型、来源系统、异常类型、预设阈值、对象信息、对象位置、异常描述和告警发生时间；
所述模型管理模块中告警信息分配模型输出的分配结果的信息格式包括推送方式、推送人员、来源类型、来源系统、告警级别、对象信息、派单判定结果和告警发生时间；
所述工单管理模块中收到的派发工单请求的信息格式包括接单系统、工单处理级别、工单指派人员、工单监督人员、异常描述和告警发生时间；
所述工单管理模块中工单的处理结果的信息格式包括推送人员、修正工单处理级别、工单指派人员、工单监督人员、工单派发时间和处理状态。
所述告警信息分配模型的处理过程如下所示：
根据异常类型、预设阈值、对象信息、对象位置、异常描述，采用Apriori算法得出概率最高的级别值，作为告警级别和工单处理级别的输入内容；
根据来源类型、来源系统、对象信息、告警级别、告警发生时间和异常描述按照与预配置设定得出推送方式和推送人员信息；
根据来源类型、来源系统、对象信息、对象位置、异常描述，经过Apriori算法得出概率超过预设值的接单系统名，若无，则派单判定为否，若有则填入派单判定，若出现多个，则填入多个；
根据对象信息、对象位置、工单处理级别、系统当前时间和以上计算记过中得出的接单系统，经过Apriori算法得出概率超过预设值的派单人员列表和监督人员列表。
模型管理模块将回馈的工单处理结果作为告警信息分配模型的优化参数，对告警信息分配模型进行优化，具体是指，根据工单处理结果中的修正处理级别和处理状态，对与该工单处理结果对应的原始告警信息同类的告警信息的工单处理级别进行优化。
所述生态业务接入管理单元中接入有能源管理业务子系统，所述能源管理业务子系统包括能源数据采集模块、能源数据管理模块和能耗预测模块，所述能源数据采集模块通过Modbus、OPC或Socket接口协议采集底层能量计量设备的能耗数据，将采集到的能耗数据传输至能源数据管理模块进行汇总和监控，并保存在数据管理单元中；所述能耗预测模块将能源数据管理模块中汇总的一采集周期内的能耗数据输入到能耗预测模型中，得到未来一采集周期内的能耗预测数据。
所述能耗预测模型的通过下述训练过程训练得到的：
将能源数据管理模块中汇总的分类能耗数据折算成总能耗，得到总能耗数据，将总能耗数据作为样本数据；对样本数据进行预处理，并搭建特征库，对特征进行整理；采用主成分析法对特征进行降维，降维之后的样本数据划分为训练集和测试集；搭建LenNet-5网络模型或CNN训练网络模型，从而得到所述能耗预测模型。
与现有技术相比，本发明所带来的有益的技术效果表现在：
1、本发明的医院后勤运营管理生态平台是基于统一的平台、统一的数据和统一的架构，向医院后勤运营管理生态平台的生态业务接入管理单元中接入的各种类型的业务子系统提供快速接入、运行和运维所需的基础能力。具体表现为：本发明采用数据管理单元提供统一的用户、设备、空间、消息、协作和数据服务，实现了平台的一体化设计；采用生态业务接入管理单元对医院之外的服务商提供的业务子系统进行统一的接入管理，并通过数据管理单元和数据分析单元实现多业务子系统间的数据统一和数据共享，实现多业务运营一体化，建设与服务一体化，能有效解决多系统独立部署成本高、数据无法共享共用和信息孤岛等问题；而本发明还采用统一的用户客户端，只是根据不同的用户采用不同的用户界面进行展示，可实现多业务子系统的一体化管理，统一并简化了业务子系统的操作，解决了多业务子系统操作复杂和管理困难的问题。可实现了业务子系统的快速接入、即插即用，解决了医院用户对多样化、定制化、专业化等后勤应用业务子系统的快速上线需求。
2、本发明的医院后勤运营管理生态平台中，所谓的“生态”是采用迭代式线性开发框架，使得生态业务接入管理单元中接入的各业务子系统既能做到有机的统一，又能做到无依赖的线性开发，还能做到无依赖的部署和删除。本发明中生态业务接入管理单元中各业务子系统及生态平台中各功能组件可以任意顺序先后或独立部署。在本发明中，生态业务接入管理单元中各业务子系统通过数据管理单元的业务运行数据管理模块和数据分析单元实现信息互通，且可实现相关业务子系统的联动。
3、本发明中，数据管理单元中业务数据的来源是基于生态业务接入管理单元中接入的各业务子系统中的业务数据，在构建本平台时，除本平台中数据管理单元中用户、设备、空间、支付、消息、协作等中心单元进行设置部署外，其他业务子系统及其他业务子系统所涉及的基础设备的信息采集建设均不需要提前构建。由于医院后勤管理涉及领域交广，如在前期就由一家公司构建涵盖医院后勤管理所有领域的平台，是不现实的，也是无法实现的，因此本发明构建的数据管理单元，基于统一的接口标准和流程，使得生态业务接入管理单元是依赖于数据管理单元提供的基础能力，进行各业务子系统的接入、运行和监控；实现业务子系统的即插即用。
4、为统一医院用户的基础数据，打通医院各业务闭环，减少项目实施成本，医院的基础数据统一在数据管理单元中创建，并同步给各个业务子系统；本发明目前提供三类基础数据的同步：用户基础数据（用户和部门）；设备基础数据；空间基础数据（院区、楼栋、房间等空间信息）；数据同步包括增量同步和全量同步，第三方服务商应同时实现这两类同步方式；增量同步用于平台用户变化时做同步；全量同步用于医院首次创建本发明的生态平台以及定期检查，避免数据遗失错漏；其中增量同步：平台发送数据变化后，向第三方服务商的业务子系统注册的接口推送通知；第三方服务商的业务子系统向平台请求增量同步接口，完成同步持久化处理，回调平台接口通知平台已经同步的数据。全量同步：平台发送数据变化后，向第三方服务商的业务子系统注册的接口推送通知；第三方服务商的业务子系统向平台请求增量同步接口，获取用户列表、空间信息列表和设备信息列表；完成同步持久化处理，回调平台接口，通知平台已经同步的数据。
5、本发明公开的医院后勤运营管理生态平台，对于第三方服务商而言，可以实现第三方业务子系统标准地、快速地接入、运行和监控，同时实现服务的闭环评价；而对于医院用户而言，可实现统一的展示，管理和交互。本发明同时还提供多种不同的人机交互方式，更加直观、便捷和高效的进行平台的使用和管理。
6、本发明的医院后勤运营管理生态平台的用户客户端根据用户类型（决策者用户、业务用户和监管者用户）上分为管理中心界面、运维中心界面和客服中心界面，根据用户数据管理模块的用户权限进行分配，具体处理为：后勤业务的人员登陆至用户客户端之后，显示的为业务用户界面；管理中心界面显示供用户进行决策的决策信息，决策者用户一般为医院管理者，管理中心界面的构建使得医院管理者可以快速、简单、清晰地了解医院后勤管理状态，为医院管理者提供决策依据，监管者用户可实时对运营、运维信息进行监管和决策。
7、在本发明中，生态业务接入管理单元依赖于数据管理单元提供的基础服务（基础数据管理模块中的用户、设备、空间、支付、消息、协作和数据中心等服务），进行各业务子系统的接入、运行和监控，并为决策者用户提供数据支撑，同时各业务子系统之间，通过数据分析单元进行互通和联动。接入管理单元可提供多样的系统对接服务，使得整个生态平台可将医院已有的系统，如HRP、HIS、OA、BA等系统进行数据互通和业务联动，进行信息共享，最终实现统一的管理。
8、在本发明中，管理中心界面中的各菜单是根据整个生态平台和其他业务子系统采集的数据和信息，按照医院的运维管理要求，进行抽象、分析和汇总，以不同的维度提供给医院管理者，对医院管理者的决策进行支撑。其中，各业务子系统支持数据分析单元中的六维度分析抽取，决策支撑时，可以用其中的任意一个维度抽取数据进行分析对比。
9、在本发明中，用户客户端是根据不同的应用场景，提供App、BIM、WEB、微信公众号、微信小程序、企业微信和钉钉等方式，来实现对生态平台直观、高效和便捷地管理。其中BIM门户可通过三维立体方式，对运维对象进行直观地展示，可实现医院空间可视化、资产可视化、设备可视化、管线可视化、告警可视化、人员可视化、作业可视化等多专业动态可视化管理，并能够实现空间设备的快速定位、故障和应急预案的动态模拟、应急处置的过程调度等动态交互功能，大大提高了运维效率和准确性。WEB门户是通过Web方式，使用生态平台的各项业务子系统和各项服务，查看医院后勤的各项业务运行情况，能够高效完成日常的管理维护工作。APP方式，可利用智能移动设备随身携带的特点，提供后勤运维业务的移动办公的轻量化工具，使用户能够随时随地的处理工作，实施快捷的响应任务流程，查看医院后勤数据指标，掌握医院后勤最新动态；具有维护性高、稳定性好、安装部署方便、运维简单和信息主动推送等特点。
10、本发明的生态平台采用面向互联网的软件技术架构进行设计，具有支持高并发、高可靠、高可伸缩、高可扩展、高安全等技术特点，广泛采用微服务、大数据、AI等先进的互联网软件技术，向用户提供高效、可靠的业务流程、功能使用、数据分析等服务，具备先进的自动化运维能力。其中，采用统一网关作为生态平台与用户客户端进行交互的统一接口，具有负载均衡、API访问权限控制、用户身份鉴权、数据格式适配等功能。网关采用Nginx作软负载均衡，使用Zuul进行API访问控制与鉴权，自主开发实现与各种业态客户端的数据适配。由于所有外部请求都要经过服务网关，它很容易成为性能瓶颈，产生单点故障，因此必须采用Keepalive应用保证服务的高可用性。此外，各业务子系统服务对接生态业务接入管理单元中的接入管理模块，在生态业务接入管理单元保证每个API调用都需要先通过接入管理模块的认证，可以采取缓存认证结果的方式避免对接入管理模块产生过大的请求压力。
11、在本发明中，对于外部API调用或者客户端对后端API的访问，可以使用HTTP协议或者RESTful，但对于内部服务间的调用，一般都是通过RPC机制来调用。当系统服务逐渐增多，服务调用链越来越复杂，很多情况下，需要不停的更新文档来维护这些调用关系。一个对这些服务进行治理的框架可以大大减少繁琐的人力工作。生态平台的服务框架采用Spring Cloud中的Eureka来实现以下特性：（1）服务提供方的注册、管理（2）服务消费方的注册、管理（3）服务的版本管理、负载均衡、流量控制、服务降级、资源隔离（4）服务的容错与熔断。
12、本发明中生态平台可根据医院用户的实际情况，进行云端部署、院端部署、云端+院端混合部署三种部署模式。其中，云端部署模式是指，生态平台及所有业务子系统都部署在阿里云的服务器上，医院以租户方式存在，每个医院租户都有自己独有的账号体系和门户地址，可通过公网域名独立访问生态平台及被授权的业务子系统。所有医院的各类数据全部保存在云端，按租户和角色权限区分不同用户可见的数据。院端部署模式是生态平台及所有业务子系统都部署在医院的内部网络内，使用医院提供的实体或虚拟服务器。医院用户访问内网IP或域名使用生态平台及被授权的业务子系统，医院各类数据全部保存在医院端，各医院的平台部署是孤立存在的，无相互关系。混合部署模式是生态平台部署在阿里云的服务器上，各个业务子系统部署在医院内部服务器上，医院以租户方式存在，每个医院租户都有自己独有的账号体系和门户地址，可通过公网域名独立访问生态平台，但公网与医院内部网络需通关堡垒网关服务器连接，使得态平台系统可以与医院内部的业务子系统进行交互，传递数据。与平台相关的数据保存在云端，各个业务子系统的业务数据保存在医院内部。
13、在发明中，数据分析单元采集医院后勤各业务子系统的业务数据以及数据管理单元的基础数据，并对这些数据进行分析，按人员、财务、物资、安全、质量、服务六个维度来建立医院后勤管理指标模型；其次，对指标采用改进的层次分析法（AHP）进行进一步分析，确定各指标在后勤服务中的重要程度，计算出指标权重；最后，根据指标值及其权重计算出医院后勤服务的总体评价得分，综合多家医院的得分，采用统计学方法对医院后勤服务质量进行评级。为医院后勤管理提供重要参考依据。
14、本发明综合评价菜单中展示的评价信息，依靠数据分析单元和数据管理单元的数据支撑，可依据客观存在的数据对后勤管理进行评分，并可参考其他同等规模医院的后勤管理评分进行横向评价，可有效反映出医院在整个医院后勤行业中的地位状况，提高了医院的后勤服务体验，变成本中心为利润中心。
15、在本发明中，数据分析单元中将后勤业务数据按照人员、财务、物资、安全、质量和服务六个维度定义医院后勤服务指标模型，其定义的指标模型更能有效反映出后勤管理状态，依据指标模型最终确定的评分更加真实有效。
16、本发明为各业务子系统提供统一的告警服务。任何业务子系统产生告警信息后，生态平台都可以根据该信息的特征判断、安排后续的工单处理策略，之后对工单处理结果进行跟踪、分析，通过算法自学习不断优化改进分配策略的效果。
17、本发明中生态业务接入管理单元中的能源管理业务子系统的能耗预测模型可最大化利用数据特征，在已有数据的基础上进行数据分析，预测可靠度更高；该能耗预测模型是引入主成分分析法，对特征数据进行降维处理，便于后续数据处理，提高了收敛速度；并采用卷积神经网络进行学习或LeNet-5网络进行学习，得到相对准确的预测模型，确保了预测能耗数据的准确性。
附图说明
图1为本发明医院后勤运营管理生态平台的架构图；
图2为本发明医院后勤运营管理生态平台中决策者用户的数据流转架构图；
图3为本发明医院后勤运营管理生态平台中监管者用户的数据流转架构图；
图4为本发明医院后勤运营管理生态平台中业务用户的数据流转架构图；
图5为本发明院端部署中的标准模式的部署结构图；
图6为本发明院端部署中的外网简单模式的部署结构图；
图7为本发明院端部署中的内网简单模式的部署结构图；
图8为本发明院端部署中的完整模式的部署结构图；
图9为本发明医院后勤服务指标模型架构图。
具体实施方式
为了使本发明的发明目的、技术方案和技术效果更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细地说明。应当理解，此处描述的具体实施例仅仅用以解释本发明，并不用于限定本发明的保护范围。
如图1所示，医院后勤运营管理生态平台，包括用户端和服务器端，用户端和服务器端建立数据连接；所述服务器端包括数据管理单元、数据分析单元、应用中心、服务商管理单元、生态业务接入管理单元和生态技术接入管理单元；用户端根据用户类型的不同显示不同的界面，用户类型包括决策者用户、监管者用户和业务用户，决策者用户的用户端界面为管理中心界面，监管者用户的用户端界面为运维中心界面，业务用户的用户端界面为客服中心界面；
所述数据管理单元包括基础数据管理模块、业务运行数据管理模块、指标数据管理模块和系统运行数据管理模块；其中基础数据管理模块为整个生态平台提供基础数据支撑，其管理的数据包括用户数据、组织架构数据、设备设施数据和空间数据；
业务运行数据管理模块中的数据与生态业务接入管理单元中接入的各业务子系统对应，当有新的业务子系统接入到生态业务接入管理单元中，则业务运行数据管理模块中对应增加新接入的业务子系统的数据；
所述指标数据管理模块中的数据包括安全指标数据、品质指标数据、工单指标数据、成本指标数据和能耗指标数据；
所述数据分析单元包括数据处理模块和模型管理模块，所述数据处理模块对数据管理单元中各类数据进行数据清洗、数据建模和/或数据计算处理；所述模型管理模块中包括有安全指标模型、成本指标模型、品质指标模型、能耗指标模型、告警信息分配模型、医院后勤服务指标模型和工单指标模型；数据分析单元中的数据处理模块对数据管理单元中的各业务运行数据进行处理，并根据模型管理模块中设定的各模型分析得到各指标数据，并将分析得到的各指标数据对应存储于数据管理单元中的指标数据管理模块中；
所述应用中心用于展示生态业务接入管理单元中接入的各业务子系统；所述服务商管理单元用于管理生态业务接入管理单元中接入的各业务子系统的服务商；
所述生态业务接入管理单元包括接入管理模块和若干个已接入的业务子系统；所述接入管理模块为待接入的业务子系统提供接入权限管理和接入接口管理服务；接入管理模块获取待接入的业务子系统的对接接口路径信息，通过接口回调的方式将动态验证码、医院租户标识和服务商应用唯一标识传输给待接入的业务子系统中；当待接入的业务子系统调用接入管理模块中的接口时，需要在接口中向接入管理模块传入访问令牌，接入管理模块对待接入的业务子系统进行鉴权；当接入管理模块调用待接入的业务子系统的接口时，在接口中向待接入的业务子系统传入鉴权令牌，待接入的业务子系统根据接入管理模块传入的鉴权令牌进行鉴权认证，鉴权认证通过后，待接入的业务子系统接入到生态业务接入管理单元中；
所述生态技术接入管理单元用于对接入的成熟技术进行管理，包括BIM可视化展示模块、IOT物联网管理模块、CV机器视觉管理模块、知识图谱模块、室内定位模块和AGV机器人管理模块，生态技术接入管理单元根据数据管理单元中的数据对应生态技术接入管理单元中接入的技术模块，并通过该技术模块向用户端发送对应数据信息；
所述管理中心界面中包括安全指标分析菜单、品质指标分析菜单、服务指标分析菜单、人员指标分析菜单、财务指标分析菜单、指标报告报表菜单和综合评价菜单；所述综合评价菜单用于展示业务用户对生态业务接入管理单元中接入的各业务子系统的反馈和评价信息，并对业务子系统提供的服务和整体运营情况进行评价，为决策者用户提供管理决策数据和辅助分析；
所述运维中心界面中包括机电系统和能源系统实时监控菜单、设备告警监控菜单、巡检视频监控菜单和应急响应服务菜单；对后勤各业务子系统运行提供一体化运营监控和评价。所述客服中心界面中包括报修工单下发菜单、巡检工单下发菜单、保洁工单下发菜单、工单管理服务菜单和历史工单分析菜单，实现面向医护病患，打通后勤服务的一站式服务及评价。
如图1所示，将本申请的医院后勤运营管理生态平台按照能力划分，由下至上可分为数据能力层、生态能力层、核心能力层、业务能力层和呈现层；平台底层（数据能力层）具备设备、空间、人员、组织等基础数据的管理能力，具备业务运行数据的管理能力、具备数据分析结果的管理能力；同时具备对各类数据的清洗、指标建模和计算能力，可将所采集数据做标准化处理，并根据标准指标评价体系计算出分析结果；
本申请中生态能力层具备生态接入能力，提供数据格式、API接口标准等接入标准，具备对接入系统的管理能力，包括能源管理系统、设备管理系统等业务系统接入和BIM可视化、IOT物联网等技术接入；平台提供服务商管理单元，用于合作厂商接入生态业务，同时提供应用中心，用于展示当前所有已接入的业务系统；基于数据能力和生态能力，平台打造了通用的核心能力以支撑业务层呈现，包括工单管理、消息推送、AI智能识别、工作流引擎、定位服务等；在平台的用户界面呈现端，分为一站式管理中心、一站式运维中心、一站式客服中心和基础功能，一站式管理中心面向医院高层管理决策者，提供决策分析能力，一站式运维中心面向医院中层管理监督者和后勤业务执行层人员，提供运营运维监控、监督能力，一站式客服中心面向医护、病患及后勤客服、调度指挥操作者，提供业务处理能力，基础功能面向系统维护者，提供基础数据配置、权限配置等系统管理能力。
平台结合自身能力和生态接入打造了各类终端呈现方式，向使用者提供多种类型的使用界面，APP有益于快速查看和便捷操作，BIM可视化界面有益于把平面问题通过三维呈现，达到更直观效果，各类终端平台的引入能够使平台适配不同医院的实际管理场景。
如图2所示，图2中是标注的1-8是供决策者用户查看的数据流转顺序，更具体地是：当业务子系统完成生态接入后，平台将向其提供基础数据（第1步）；业务子系统在日常使用过程中产生的业务数据会沉淀在平台的数据管理单元中（第2步）；平台根据指标模型和业务运行数据计算出分析结果；分析结果被存储在数据管理单元中；数据分析单元可以从数据管理单元中获得指标分析结果（第3步）；分析结果返回至数据管理单元中进行保存（第4步），并经数据管理单元输出（第5步），第3步至第5步体现了生态平台的数据分析能力；分析结果呈现在一站式管理中心的相应指标分析菜单中（第6步）；一站式管理中心的指标分析结果可以在APP、WEB等多种终端页面中展示（第7步）；决策者可以登录终端后查看其关心的统计数据（第8步）。
如图3所示，图3中标注的1-8是供监管者用户查看的数据流转顺序，更具体地是：当业务子系统完成生态接入后，平台将向其提供基础数据（第1步）；业务子系统在日常使用过程中产生的业务数据会沉淀在平台的数据管理单元中（第2步）；业务子系统实时运行的数据（第3步）、业务子系统存储在数据管理单元中的历史数据（第4步），通过生态技术接入管理单元中接入的生态技术进行展示（第5步），使得业务数据可视化；生态平台能力层将整合的实时数据、历史数据和接入的生态技术，转化为标准化的监控可视化数据项各种业务监管场景赋能（第6步），如工作流监管、视频监控、定位监控等；一站式运维中心将根据不同业务类型提供相应的运维监控呈现方式（第7步），如室内定位之于设备设施管理、视频监控之于保洁管理；监管者可以登录终端检查各类业务的运行信息。监管者用户可以登录客户端后查看其关心的监控数据（第8步）。
如图4所示，业务用户可以登录各类终端进行业务执行，业务用户可以登录后进入一站式客服中心进行各类业务处理，其中包含设备报修、保养、运送、护工等多类业务的操作入口；当一站式客服中心接受到操作命令后会将内容提交至平台能力层，能力层提供了面向客服业务的标准化的能力模块，如工单管理、工作流管理、人脸识别语音识别等AI智能服务，辅助操作人员高效完成作业；平台能力层将接受到的请求根据业务分发至各业务系统，又业务系统处理具体业务；当业务系统完成生态接入后，平台将向其提供基础数据，保障业务系统可以正常运行；生态接入的技术能力将为能力层提供技术基础，如ACV机器视觉、AGV机器人等；业务系统在完成业务处理后会响应至平台能力层的相应模块；平台能力层的模块结合业务响应和生态技术赋能，向一站式客服中心反馈处理结果；平台能力层在完成业务处理后，会将相应的业务数据发送至平台数据管理层，作为指标分析和运维监控的数据来源；一站式客服中心收到结果后会将内容呈现在用户操作界面；操作者可在其登录的终端上查看到业务的处理结果。
对于服务提供商来，生态平台的目标是实现第三方应用业务标准的、快速地接入和业务子系统的即插即用，同时实现第三方服务的闭环评价；对于医院用户而言，实现了统一的展示、管理和交互。同时提供多种不同的人机交互方式，更加直观、便捷和高效的进行平台的使用和管理；对于平台自身，要支持云端和本地级的部署、支持系统的大容量、高并发、可扩展、高可用、可伸缩能力。
数据分析单元和数据管理单元用于汇聚用户端和生态业务接入管理单元中接入的业务子系统的业务数据，进行ETL后形成统一的数据标准，汇聚拉通后形成数据资产，计算各类分析指标，挖掘数据价值，向用户端和生态业务接入管理单元输出数据；所述数据分析单元和数据管理单元将汇聚的用户端和生态业务接入管理单元中的数据按照时间、空间、人员、事件、设备和费用六个维度进行梳理，并按照统一编码进行归纳、排列和组合，将各类数据汇聚拉通形成合力，挖掘数据潜在价值。
其中数据分析单元汇聚业务运行数据管理模块中各已接入的业务子系统产生的实时业务数据和业务运行数据管理模块存储的历史数据，对数据进行清洗和格式化处理，并将格式化处理后的数据按照时间、空间、人员、事件、设备和费用六个维度进行整理，并计算各维度下的二级指标的指标值，将指标计算结果反馈至数据管理单元中的指标数据模块中，并通过生态技术接入管理单元中对应接入的技术模块向对应的用户展示。
所述生态平台的部署模式包括云端部署模式、院端部署模式和混合部署模式；所述云端部署模式是指将所述生态平台及其生态业务接入管理单元中接入的各业务子系统均部署在云服务器上且所有数据也均保存在云服务器上；所述院端部署是指将所述生态平台及其生态业务接入管理单元中接入的各业务子系统均部署在医院内部网络内的实体或虚体服务器中；所述院端部署根据服务器配置数量和组网模式分为标准模式、完整模式、外网简单模式和内网简单模式四个分支；所述混合部署是指所述生态平台部署在云服务器上，而生态平台的生态业务接入管理单元中接入的各业务子系统部署在医院内部网络内的实体或虚体服务器中。
如图5所示，所述院端部署模式中的标准模式至少需两台服务器，一台服务器作为堡垒网关服务器部署在医院的DMZ区与互联网连通，另一台作为生态平台及其生态业务接入管理单元中接入的各业务子系统的应用服务器及数据库服务器部署在医院的核心区。
如图6所示，所述院端部署模式中的外网简单模式至少需一台服务器，该服务器作为堡垒网关服务器、生态平台的应用服务器及数据库服务器，部署在医院的DMZ区与互联网连通。
如图7所示，所述院端部署模式中的内网简单模式至少需一台服务器，该服务器作为生态平台的应用服务器及数据库服务器部署在医院的核心区，不与互联网连通。
如图8所示，所述院端部署模式中的完整模式至少需要三台服务器，一台作为堡垒网关服务器部署在医院的DMZ区与互联网连通，另外两台分别作为生态平台的应用服务器和数据库服务器部署在医院的核心区。
所述用户端的呈现方式包括App、BIM、WEB、微信公众号、微信小程序、企业微信和钉钉中的任意一种或多种的组合。
作为本实施例的一种较佳的实施方式，所述综合评价菜单中展示的评价信息，是数据分析单元经过下述处理过程得到的：
数据分析单元中的数据处理模块采集接入到生态业务接入管理单元中各业务子系统产生的实时业务数据和存储于业务运行数据管理模块中的历史业务数据，对采集到的实时业务数据和历史业务数据进行校验，过滤掉非法记录后，汇聚成后勤业务数据，保存在数据管理单元的业务运行数据管理模块中，并将校验后的后勤业务数据传输至模型管理模块；
所述模型管理模块将接收到的后勤业务数据，根据按照人员、财务、物资、安全、质量和服务六个维度定义的医院后勤服务指标模型，计算出指标值，并将指标值保存在指标数据管理模块中，且计算出各指标值对应的权重值；
具体是采用层次分析法计算各个指标的权重值，对各个指标的指标值进行归一化处理，再根据各个指标的权重值使用加权平均法，计算出各个指标的加权平均值，最后将加权平均值作为医院后勤服务质量评分，并将医院后勤服务质量评分传输至综合评价菜单中，供决策者用户查看。
更进一步的，所述数据分析单元可根据大量的医院后勤服务质量评分，使用统计学建立医院后勤服务质量评级模型；并将医院后勤服务质量评分输入医院后勤服务质量评级模型中得到医院后勤服务质量评级，将医院后勤服务质量评级结果传输至综合评价菜单中，供决策者用户查看。
所述后勤业务数据包括生态业务接入管理单元中接入的综合监控类业务子系统的告警数据，业务运维类业务子系统的工单数据，患者服务类业务子系统的订单数据，财务管理业务子系统的后勤预算和成本数据、物资库存数据和工程项目数据。所述生态业务接入管理单元中接入的综合监控类业务子系统包括能耗计量监控、电梯监控、医用气体监控、变配电监控、给排水监控、锅炉监控、空调监控和消防监控；所述告警数据包括告警等级、告警设备名、告警类型、告警系统名、告警事件、告警时间和恢复时间。所述生态业务接入管理单元中接入的业务运维类业务子系统包括机电运维子系统、医废管理子系统、安保子系统、设备管理子系统、被服管理子系统、清洁服务子系统、运送管理子系统；所述工单数据包括工单类型、工单状态、工单位置、工单内容、工单下单人电话、工单下单人、工单下单部门、工单接单人员、工单下单时间、工单接单时间和工单完成时间。所述生态业务接入管理单元中接入的患者服务类业务子系统包括护工护理子系统、停车场管理子系统、便利店管理子系统、餐饮服务子系统、共享轮椅管理子系统和陪护床租赁子系统；所述订单数据包括订单类型、订单状态、订单商品、订单内容、订单金额、订单下单人电话、订单下单时间和订单完成时间。所述生态业务接入管理单元中接入的财务管理业务子系统包括预算管理模块、成本管理模块、物资管理模块和工程管理模块；所述预算和成本数据包括费用年度、费用科目、费用金额和费用时间；所述库存数据包括物资编码、物资名称、物资单位、物资数量、物资单价、物资操作人和物资操作时间；所述工程项目数据包括项目编码、项目名称、项目金额、施工单位、施工内容、项目操作人和项目操作时间。
更进一步的，作为本发明又一种实施方式，所述数据分析单元中各模块主要运行流程如下所示：
数据处理模块采集后勤数据：（1）使用Modbus、OPC、Socket等接口协议采集计量监控类业务子系统的告警数据并存入生态平台的数据管理单元。计量监控类业务子系统包括能耗计量子系统、电梯监控子系统、医用气体监控子系统、变配电监控子系统、给排水监控子系统、锅炉监控子系统、空调监控子系统、消防监控子系统等；告警数据内容包括告警等级、告警设备、告警类型、告警系统、告警详情、告警时间、恢复时间等。
（2）使用Http、WebService等接口协议采集业务运维类业务子系统的工单数据并存入生态平台的数据管理单元。业务运维类业务子系统包括报修系统、巡检系统、保养系统、医废系统、安保系统、被服系统、保洁系统、运送系统等；工单数据内容包括工单类型、工单状态、工单位置、工单内容、下单人电话、下单人、下单部门、接单人员、下单时间、接单时间、完成时间等。
（3）使用Http、WebService等接口协议采集患者服务类业务子系统的订单数据并存入生态平台的数据管理单元。患者服务类业务子系统包括护工护理系统、停车场管理系统、便利店管理系统、点餐\营养餐管理系统、共享轮椅管理系统、陪护床租赁系统等；订单数据内容包括订单类型、订单状态、订单商品、订单内容、订单金额、下单人电话、下单时间等。
（4）使用Http、WebService等接口协议采集财务类业务子系统的后勤预算和成本、库存数据、工程项目数据并存入生态平台的数据管理单元。财务类业务子系统包括预算管理系统、成本管理系统、物资管理系统、工程管理系统等；预算和成本数据内容包括费用年度、费用科目、费用金额、费用时间等，库存数据内容包括物资编码、物资名称、物资单位、物资数量、物资单价、操作人、操作时间等，工程项目数据内容包括项目编码、项目名称、项目金额、施工单位、施工内容、操作人、操作时间等。
根据医院后勤的业务特点，结合国家卫健委颁布的《全国医院信息化建设标准与规范（试行）》、《医院后勤标准化作业指导书》等行业规范，按照人员、财务、物资、安全、质量、服务六个维度定义医院后勤服务指标模型。数据处理模块定期从业务运行数据管理模块中查询后勤业务数据，按照指标定义规则使用业务数据计算出指标值，并将指标值保生态平台的数据管理单元的指标数据管理模块中。
所述医院后勤服务指标模型如图9所示，包括六个一级指标和25个二级指标，各二级指标与一级指标的计算方式和对应关系如下表1、表2、表3、表4、表5和表6所示：
表1为一级——指标人员（P）指标下的二级指标列表
Figure 613930DEST_PATH_IMAGE017
表2为一级指标——财务（F）指标下的二级指标列表
Figure 874010DEST_PATH_IMAGE018
表3为一级指标——物资（G）指标下的二级指标列表
Figure 218404DEST_PATH_IMAGE019
表4为一级指标——安全（S）指标下的二级指标列表
Figure 372174DEST_PATH_IMAGE020
表5为一级指标——质量（Q）指标下的二级指标列表
Figure 409400DEST_PATH_IMAGE021
表6为一级指标——服务（E）指标下的二级指标列表
Figure 766563DEST_PATH_IMAGE022
使用层次分析法（AHP）计算各一级指标和二级指标的权重值，并将计算得到的权重值保存在数据中心；具体过程如下：
对不同指标重要程度的等级划分采用1-9分等级标度方法，如表7所示：
表7为不同因素对目标的重要程度等级划分定义表
等级 重要程度 划分定义
1 同等重要 a与b对目标贡献同等重要
3 稍微重要 a相对于b对目标稍微重要
5 基本重要 a相对于b对目标较强重要
7 强烈重要 a相对于b对目标强烈重要
9 绝对重要 a相对于b对目标绝对重要
2,4,6,8 中间值 a相对于b对目标的重要程度介于上述等级
1/2,1/3，…，1/9 等级倒数 a相对于b对目标的重要性与上述结果相反
根据国家标准及医院后勤领域专家对同一层次不同指标的重要性进行两两比较 打分，并判断矩阵一致性，从而保证重要性等级划分的科学合理性。一致性指数
Figure 180227DEST_PATH_IMAGE023
的计 算公式为：
Figure 798290DEST_PATH_IMAGE024
，式中
Figure 396630DEST_PATH_IMAGE025
为最大特征值，
Figure 100144DEST_PATH_IMAGE026
为矩阵阶数。
Figure 927286DEST_PATH_IMAGE023
值越大，表明判断 矩阵偏离完全一致性程度越大，即矩阵中的重要性程度值越不合理，此时需要重新调整。此 外，
Figure 931014DEST_PATH_IMAGE026
越大，人为造成偏差的可能性和偏差程度也越大。因此一致性判断显得尤为重要。
为了应对多评价指标的复杂情况（即
Figure 310043DEST_PATH_IMAGE026
值较大），引入平均随机一致性指标
Figure 156645DEST_PATH_IMAGE027
， 它是多次重复随机判断矩阵特征根的算术平均值，本文采用龚木森等在1986年得出的1-15 阶判断矩阵重复计算1000次的平均随机一致性指标，如表8所示。
表8 为1-15阶判断矩阵重复计算1000次的平均随机一致性指标
n 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
R.I. 0 0 0.52 0.89 1.12 1.26 1.36 1.41 1.46 1.49 1.52 1.54 1.56 1.58 1.59
最后利用一致性指标
Figure 787477DEST_PATH_IMAGE023
与同阶平均随机一致性指标
Figure 114554DEST_PATH_IMAGE027
之比
Figure 930063DEST_PATH_IMAGE028
作为 最终评判判断矩阵的标准，只有当
Figure 995452DEST_PATH_IMAGE029
时，才可认为判断矩阵具有满意的一致性，即说 明权重分配是合理的，否则就需要重新调整判断矩阵，直到取得满意的一致性为止。
根据国家、地区、行业的相关标准等信息，结合医院后勤专业的专家经验，得到了表9所示的后勤服务质量一级指标判断矩阵。
表9为一级指标判断矩阵（P、F、G、S、Q、E）
一级指标 人员P 财务F 物资G 安全S 质量Q 服务E 权重
Figure 289030DEST_PATH_IMAGE030
人员P 1 2 3 1/7 1/5 1/6 0.0569
财务F 1/2 1 1/2 1/9 1/4 1/6 0.0318
物资G 1/3 2 1 1/8 1/6 1/5 0.0383
安全S 7 9 8 1 6 5 0.5213
质量Q 5 4 6 1/6 1 1/2 0.1492
服务E 6 6 5 1/5 2 1 0.2025
上述行权重
Figure 877138DEST_PATH_IMAGE030
的计算方法为：首先计算判断矩阵第i行所有元素的乘积，并求该 乘积的n次方根，n为判断矩阵的维数（此处n=6）；例如第一行方根的计算方法为
Figure 332390DEST_PATH_IMAGE031
，以此类推计算出所有行的方根。其次将某一行的方 根除以所有行方根的总和，即获得该行的权重；例如第一行权重的计算方法为
Figure 763371DEST_PATH_IMAGE032
。以下其他判断指标矩阵的行权重计算方法相同。
上述判断指标矩阵最大特征值
Figure 985274DEST_PATH_IMAGE025
的计算方法为：首先将矩阵各行的权重构造成 特征向量并将判断指标矩阵乘以特征向量得到中间向量，其次将中间向量的每个元素除以 特征向量中对应位置的元素得到中间商，最后计算所有中间商的平均值，此平均值即为最 大特征值
Figure 552521DEST_PATH_IMAGE025
。
具体计算过程如下：
判断指标矩阵乘以特征向量得到中间向量，
Figure 319620DEST_PATH_IMAGE033
；
中间向量的每个元素除以特征向量中对应位置的元素得到中间商,计算所有中间 商的平均值，求出最大特征值
Figure 972318DEST_PATH_IMAGE025
，即
Figure 873278DEST_PATH_IMAGE034
；
Figure 419666DEST_PATH_IMAGE035
，
Figure 482300DEST_PATH_IMAGE036
，
Figure 497661DEST_PATH_IMAGE037
，因此上述判断指标矩阵是可接受的。以下其他判断指标矩阵的最大特 征值计算方案相同。
表10为二级指标判断矩阵（P1-P5）
Figure 936732DEST_PATH_IMAGE038
上述表格10中计算得到的
Figure 478572DEST_PATH_IMAGE039
，
Figure 102320DEST_PATH_IMAGE040
，
Figure 464032DEST_PATH_IMAGE041
， 因此上述判断指标矩阵是可接受的。
表11为二级指标判断矩阵（F1-F5）
二级指标 后勤预算总额F1 单位面积后勤成本F2 单位床位后勤成本F3 每万元收入后勤成本F4 单位住院人数后勤成本F5 权重
Figure 582160DEST_PATH_IMAGE042
后勤预算总额F1 1 1/4 1/6 1/5 1/7 0.0372
单位面积后勤成本F2 4 1 1/3 1/2 1/5 0.0919
单位床位后勤成本F3 6 3 1 3 1/4 0.2416
每万元收入后勤成本F4 5 2 1/3 1 1/3 0.1416
单位住院人数后勤成本F5 7 5 4 3 1 0.4877
上述表格11中计算得到的
Figure 712927DEST_PATH_IMAGE043
，
Figure 382943DEST_PATH_IMAGE044
，
Figure 359514DEST_PATH_IMAGE045
，因此上述判断指标矩阵是可接受的。
表12 为二级指标判断矩阵（G1-G4）
二级指标 库存物资总额G1 采购物资总额G2 医院资产总额G3 医院资产闲置率G4 权重
Figure 140388DEST_PATH_IMAGE046
库存物资总额G1 1 3 2 4 0.4547
采购物资总额G2 1/3 1 1/3 2 0.1394
医院资产总额G3 1/2 3 1 4 0.3205
医院资产闲置率G4 1/4 1/2 1/4 1 0.0855
上述表格12中计算得到的
Figure 532186DEST_PATH_IMAGE047
，
Figure 107524DEST_PATH_IMAGE048
，
Figure 709407DEST_PATH_IMAGE049
，因此上述判断指标矩阵是可接受的。
表13二级指标判断矩阵（S1-S4）
二级指标 告警平均恢复时间S1 告警及时恢复率S2 突发事件数S3 设备巡检保养率率S4 权重
Figure 153026DEST_PATH_IMAGE050
告警平均恢复时间S1 1 2 1/4 3 0.1993
告警及时恢复率S2 1/2 1 1/6 2 0.1154
突发事件数S3 4 6 1 5 0.6064
设备巡检保养率率S4 1/3 1/2 1/5 1 0.0790
上述表格13中计算得到的
Figure 523965DEST_PATH_IMAGE051
，
Figure 411149DEST_PATH_IMAGE052
，
Figure 969170DEST_PATH_IMAGE053
，因此上述判断指标矩阵是可接受的。
表14 二级指标判断矩阵（Q1-Q3）
二级指标 临床平均满意度Q1 考核平均得分Q2 服务好评率Q3 权重
Figure 357426DEST_PATH_IMAGE050
临床平均满意度Q1 1 3 1/4 0.2176
考核平均得分Q2 1/3 1 1/6 0.0914
服务好评率Q3 4 6 1 0.6910
上述表格14中计算得到的
Figure 707504DEST_PATH_IMAGE054
，
Figure 624645DEST_PATH_IMAGE055
，
Figure 76486DEST_PATH_IMAGE056
，因此上述判断指标矩阵是可接受的。
表15为 二级指标判断矩阵（E1-E4）
二级指标 工单及时完成率E1 工单超时率E2 工单平均响应时间E3 工单平均完成时间E4 权重
Figure 2854DEST_PATH_IMAGE050
工单及时完成率E1 1 1/3 2 3 0.2252
工单超时率E2 3 1 5 6 0.5728
工单平均响应时间E3 1/2 1/5 1 1/2 0.0902
工单平均完成时间E4 1/3 1/6 2 1 0.1118
上述表格15中计算得到的
Figure 817226DEST_PATH_IMAGE057
，
Figure 561060DEST_PATH_IMAGE058
，
Figure 359252DEST_PATH_IMAGE059
，因此上述判断指标矩阵是可接受的。
前面分别计算了一级指标判断矩阵和二级指标判断矩阵。在此基础上可进一步计算各二级指标在整个模型中的权重，计算公式如下：
Figure 699097DEST_PATH_IMAGE060
；其中为一级指标判断矩阵维度（
Figure 633555DEST_PATH_IMAGE061
即一级指标个数），
Figure 158077DEST_PATH_IMAGE062
为每个二级指标判断矩阵维度（即每个二级指标包含的指标个数）。根据上 述公式最终计算得到的全局指标权重如表16所示。
表16各级指标综合权重及排名
Figure 588707DEST_PATH_IMAGE063
至此，得到了不同指标的综合权重，再结合不同实际指标的转换指标
Figure 856877DEST_PATH_IMAGE064
就能计算 得到整个后勤服务质量的综合量化评价系数K，计算公式如下：
Figure 521208DEST_PATH_IMAGE065
；式中L是二级指标总数，本文为25。需要指出的是，不同二级指标应 该具备相同的量纲或取值范围，以保证结果的科学合理性。
后勤服务的六大块25项指标中，每一项指标的计算方式不尽相同，不仅表现在数值上的差异，同时也表现在量纲上的不同，如果直接将指标值作为参数计算综合后勤服务质量评价系数，会导致结果的错误（非误差）和不可解释性。为了解决这个问题，一类方法是将每一种指标转化为某种统一评价指标，比如全部转化为“得分”，但这会涉及到转化方法的科学性问题，目前并无统一方法；另一类方法是直接利用数学方法将每一种指标通过数据转换到统一的区间，这种方法实际上是利用了统一的转换规则，不仅不会影响原指标的物理意义，同时可以使最终的综合评价系数准确合理。第二类方法的本质实际上包含了第一类方法，只是省略了明确给出变换后数值物理意义的步骤，变换公式为：
Figure 482211DEST_PATH_IMAGE066
；式中X（
Figure 723836DEST_PATH_IMAGE067
）是原实际指标值及对应的取值范围，
Figure 920331DEST_PATH_IMAGE068
是将X转换到区间[N，M]后的值，所有指标都采用相同的N和M，本文取N=0，M=1。例如，后勤预 算总额指标，原指标为金额，是一个有明确意义的物理量，但它不能直接参与计算，根据本 文方法，必须给预算金额给定一个最大最小值，也就是上式中的A和B，例如A=2000万元，B=2 亿元，如果某医院的后勤预算为5000万元，则该医院后勤预算指标的转换指标
Figure 829381DEST_PATH_IMAGE069
。 其他指标按照相同的方式进行计算。
表17是某医院后勤各实际指标和转换指标结果
Figure 571072DEST_PATH_IMAGE070
根据表16和表17结果，再利用公式可计算得到K值，K值可作为医院后勤服务质量的综合评价得分，即
Figure 831152DEST_PATH_IMAGE071
。
医院后勤服务质量评级计算：按照上述方法，计算获得多家医院的后勤服务质量 的综合评价得分，第i家医院评价得分记为
Figure 175546DEST_PATH_IMAGE072
，将这些医院的评价得分从小到大进行排序后 计算出1/4分位数、1/2分位数、3/4分位数，分别记为
Figure 329316DEST_PATH_IMAGE073
、
Figure 366542DEST_PATH_IMAGE074
、
Figure 723705DEST_PATH_IMAGE075
。当医院评价得分
Figure 137369DEST_PATH_IMAGE076
则后勤服务质量评级为“不合格”；当医院评价得分
Figure 145645DEST_PATH_IMAGE077
，则后勤服务 质量评级为“合格”；当医院评价得分
Figure 619352DEST_PATH_IMAGE078
，则后勤服务质量评级为“良好”；当 医院评价得分
Figure 322865DEST_PATH_IMAGE079
，则后勤服务质量评级为“优秀”。
更进一步地，作为本实施例的又一种实施方式，所述数据分析单元中数据处理模块中包括有告警数据采集子模块，所述告警数据采集子模块采集已接入平台的各业务子系统的告警信息，将采集到的告警信息保存到数据管理单元中，并对告警信息进行过滤和分配；将告警信息输入模型管理模块中的告警信息分配模型中，并输出分配结果，并将分配结果反馈至数据处理模块，所述分配结果包括告警通知策略、推送策略和工单处理策略；
所述数据处理模块中的告警数据处理子模块依照模型管理模块反馈的分配结果，向监管者用户推送告警通知消息；告警数据处理子模块和数据管理单元跟踪告警信息的生命周期；告警数据处理子模块根据工单处理策略向对应工单管理模块提交工单派发请求；
所述工单管理模块将告警数据处理子模块提交的工单派发请求派发至与该工单业务对应的业务子系统中，业务子系统生成工单后，将工单信息传输至对应该业务子系统的用户的客户端上，该工单信息在该用户的客服中心界面的工单管理服务菜单中显示；所述工单管理模块跟踪该工单的全生命周期，当工单的状态为已关闭后，工单管理模块将该工单的处理结果回馈至模型管理模块，模型管理模块将回馈的工单处理结果作为告警信息分配模型的优化参数，对告警信息分配模型进行优化。任何业务子系统产生告警信息后，生态平台都可以根据该信息的特征判断、安排后续的工单处理策略，之后对工单处理结果进行跟踪、分析，通过算法自学习不断优化改进分配策略的效果。
更进一步地，所述告警数据采集子模块采集的告警信息的来源包括硬件设备告警信息、业务子系统告警信息和业务异常信息；所述硬件设备告警信息是指硬件设备中根据预设阈值的判断产生的告警信息；所述业务子系统告警信息是指生态业务接入管理单元中各业务子系统识别出的违反常态的业务信息；所述业务异常信息是指告警数据处理子模块和工单管理模块中工单状态或告警信息状态超出阈值的信息。
所述告警数据采集子模块采集的告警信息的信息格式包括来源类型、来源系统、异常类型、预设阈值、对象信息、对象位置、异常描述和告警发生时间；
所述模型管理模块中告警信息分配模型输出的分配结果的信息格式包括推送方式、推送人员、来源类型、来源系统、告警级别、对象信息、派单判定结果和告警发生时间；
所述工单管理模块中收到的派发工单请求的信息格式包括接单系统、工单处理级别、工单指派人员、工单监督人员、异常描述和告警发生时间；
所述工单管理模块中工单的处理结果的信息格式包括推送人员、修正工单处理级别、工单指派人员、工单监督人员、工单派发时间和处理状态。
所述告警信息分配模型的处理过程如下所示：
根据异常类型、预设阈值、对象信息、对象位置、异常描述，采用Apriori算法得出概率最高的级别值，作为告警级别和工单处理级别的输入内容；
根据来源类型、来源系统、对象信息、告警级别、告警发生时间和异常描述按照与预配置设定得出推送方式和推送人员信息；
根据来源类型、来源系统、对象信息、对象位置、异常描述，经过Apriori算法得出概率超过预设值的接单系统名，若无，则派单判定为否，若有则填入派单判定，若出现多个，则填入多个；
根据对象信息、对象位置、工单处理级别、系统当前时间和以上计算记过中得出的接单系统，经过Apriori算法得出概率超过预设值的派单人员列表和监督人员列表。
模型管理模块将回馈的工单处理结果作为告警信息分配模型的优化参数，对告警信息分配模型进行优化，具体是指，根据工单处理结果中的修正处理级别和处理状态，对与该工单处理结果对应的原始告警信息同类的告警信息的工单处理级别进行优化。
所述生态业务接入管理单元中接入有能源管理业务子系统，所述能源管理业务子系统包括能源数据采集模块、能源数据管理模块和能耗预测模块，所述能源数据采集模块通过Modbus、OPC或Socket接口协议采集底层能量计量设备的能耗数据，将采集到的能耗数据传输至能源数据管理模块进行汇总和监控，并保存在数据管理单元中；所述能耗预测模块将能源数据管理模块中汇总的一采集周期内的能耗数据输入到能耗预测模型中，得到未来一采集周期内的能耗预测数据。
所述能耗预测模型的通过下述训练过程训练得到的：
将能源数据管理模块中汇总的分类能耗数据折算成总能耗，得到总能耗数据，将总能耗数据作为样本数据；对样本数据进行预处理，并搭建特征库，对特征进行整理；采用主成分析法对特征进行降维，降维之后的样本数据划分为训练集和测试集；搭建LenNet-5网络模型或CNN训练网络模型，从而得到所述能耗预测模型。
更进一步地，以某三甲医院为实验示例，每隔一小时采集一次它的各类能耗数据，并折算为总能耗值（标煤），转换关系如表18所示。搭建特征值数据库，采集并存储多个特征值数据，作为数据支撑。包括历史温度、湿度、医院就诊量、人流量、床位使用数等。
表18是各种能源折标准煤参考系数
Figure 150007DEST_PATH_IMAGE080
由于可能影响能耗数据的因子较多，本实施方式采用了主成分分析法（PCA）对高纬度特征进行处理，只保留一些重要的特征，去除噪声和不重要的特征，以达到降维的目的。对特征的预处理可降低算法的计算开销，提高后续数据处理的速度。
PCA的主要思想是将m维特征映射到k维上，这k维是全新的正交特征也被称为主成分，是在原有m维特征的基础上重新构造出来的k维特征。PCA的工作就是从原始的空间中顺序地找一组相互正交的坐标轴，新的坐标轴的选择与数据本身是密切相关的。相当于保留包含绝大部分方差的维度特征，而忽略方差几乎为0的特征维度，实现对数据特征的降维。
假设特n个数据
Figure 153735DEST_PATH_IMAGE081
，
Figure 660327DEST_PATH_IMAGE082
为m维的特征向量，我们希望将
Figure 851137DEST_PATH_IMAGE082
的维度降到k维，希望这n个k维的数据集尽可能的代表原始数据集。PCA的算法实现流程为：
第一步：去平均值（去中心化），即每一个特征减去各自的平均值；
第二步：计算特征样本集的协方差矩阵：
Figure 481970DEST_PATH_IMAGE083
；
第三步：用特征值分解的法求协方差矩阵
Figure 340204DEST_PATH_IMAGE083
的特征值和特征向量；
第四步：将步骤三得到的特征值从大到小排序，选取其中最大的k个值，然后将其对应的k个特征向量分别作为行向量组成特征向量矩阵P。最后将数据转换到k个特征向量构建的新空间中，即
Figure 890134DEST_PATH_IMAGE084
，得到新的样本数据集，大小为n*k。
在训模型之前，通常需要将数据标准化，利用标准化之后的数据进行数据分析。不同评价指标往往具有不同的量纲和量纲单位，这样会影响到数据分析的结果，为了消除指标之间的影响，需要对数据进行标准化处理，把数据经过处理后使之限定在一定的范围内，及归一化。
本示例采用最大-最小标准化方法对样本数据进行归一化处理。最大-最小标准化是对原始数据进行线性变换，计算方法为：
Figure 958453DEST_PATH_IMAGE085
公式(1)；
公式中
Figure 986452DEST_PATH_IMAGE086
是特征列的原始值，
Figure 574560DEST_PATH_IMAGE087
、
Figure 560970DEST_PATH_IMAGE088
分别为特征列的最小值值和最大值，经过处理后会得到映射到[0,1]的
Figure 726372DEST_PATH_IMAGE089
。
预处理后的样本数据按照9:1的比例，划分训练集和测试集。采用LenNet-5网络模型进行训练，旨在得到相对精确的网络模型。
LenNet-5是一个较简单的神经网络。输入的二维图像，经过两次卷积层到池化层，再经过全连接层，最后使用softmax分类作为作为输出层。它包含了深度学习的基本模块：卷积层，池化层，全连接层。
它的训练方法如下：
第一阶段，向前传播阶段：
从样本集中取一个样本(X,Yp)，将X输入网络；
计算相应的实际输出Op。
在此阶段，信息从输入层经过逐级的变换，传送到输出层。这个过程也是网络在完成训练后正常运行时执行的过程。
第二阶段，向后传播阶段：
a）算实际输出Op与相应的理想输出Yp的差；
b）按极小化误差的方法反向传播调整权矩阵。
本实施方式中，以某三甲医院为示例，降维后的样本特征最终由温度、湿度、人流 量、床位使用率、是否是工作日、时间戳、能耗值组成，构成一个
Figure 948275DEST_PATH_IMAGE090
的向量。即：[温度(t), 湿度(t),人流量(t),床位使用率(t),dateType,time,能耗值(t)]，考虑到医院运行的特殊 性，本文将dateType(时间类型)作为能耗影响因子，非工作日dateType=1，工作日dateType =0。LeNet-5模型的输入选择的是连续n个时间点的样本数据，组成维度为
Figure 515523DEST_PATH_IMAGE091
的矩阵，模 型的输出是
Figure 813780DEST_PATH_IMAGE092
的预测出的
Figure 856691DEST_PATH_IMAGE093
时刻的能耗数据。在网络构建的过程中，可以根据实际情 况调整n的大小，使损失函数尽可能小，本文中n=28。
LeNet-5共有7层：2个卷积层、2个池化层、3个全连接层，不包含输入，每层都包含可训练参数。
第一层为卷积层，选取卷积核大小为
Figure 226493DEST_PATH_IMAGE094
，步长为1；
第二层是池化层，池化过滤器大小为
Figure 913826DEST_PATH_IMAGE095
，步长为2；
第三层为卷积层，选取卷积核大小为
Figure 851826DEST_PATH_IMAGE094
，步长为1；
第四层是池化层，池化过滤器大小为
Figure 991820DEST_PATH_IMAGE095
，步长为2；
第五层为全连接层，主要将空间数据特征展开表示，输入为特征图的张量表示，输出为特征图的一维展开向量表示；
第六层为全连接层；
第七层为全连接层，也是输出层，输出能耗预测值；
LeNet-5中所说的卷积是二维卷积，即与二维图像做卷积操作，简单的讲是二维滤 波器滑动到二维图像上所有位置，并在每个位置上与该像素点及其领域像素点做内积。以
Figure 818175DEST_PATH_IMAGE096
矩阵为例，
Figure 94436DEST_PATH_IMAGE097
是坐标
Figure 593550DEST_PATH_IMAGE098
的值，假设卷积核大小为
Figure 830628DEST_PATH_IMAGE099
，权重为
Figure 807811DEST_PATH_IMAGE100
,卷积的过程就是卷 积核与矩阵上滑动窗口中对应元素的计算，可以表示为：
Figure 594370DEST_PATH_IMAGE101
公式(2)；
网络中的激活函数选用的是非线性激活函数ReLU（Rectified Linear Unit）,可表示为：
Figure 998807DEST_PATH_IMAGE102
公式(3)
池化（pooling）层，是一种降采样操作。目前主要的pooling操作主要有最大值池化、平均值池化。最大值池化是指选取窗口中的最大值保留，平均值池化是选取窗口中的平均值做保留。本文选取的是最大值池化，不同的项目示例中，可更具需要调整。
本文采用平均绝对误差MAE（Mean Absolute Error）作为损失函数，即预测值与真实值的误差绝对值的平均值，来度量神经网络的输出与实际之间的差距。
Figure 113393DEST_PATH_IMAGE103
公式(4)；
公式中m为测试集样本的数量，
Figure 769634DEST_PATH_IMAGE104
为预测值，
Figure 20487DEST_PATH_IMAGE105
为期望值，h()为绝对值函数。
利用这个网络，经过多次迭代，得到训练好的LeNet-5网络，保存网络模型。
在不同的示例中，为了更好的适应需求，可通过改变输入样本的维度、以及卷积层层数等参数，选择适合的迭代次数来调整网络模型。以达到更好的学习效果，获得相对精确的预测模型。最后以训练好的网络模型为基础，获得相应时间的能耗预测值。

Claims (26)

1.医院后勤运营管理生态平台，包括用户端和服务器端，用户端和服务器端建立数据连接；其特征在于：所述服务器端包括数据管理单元、数据分析单元、应用中心、服务商管理单元、生态业务接入管理单元和生态技术接入管理单元；用户端根据用户类型的不同显示不同的界面，用户类型包括决策者用户、监管者用户和业务用户，决策者用户的用户端界面为管理中心界面，监管者用户的用户端界面为运维中心界面，业务用户的用户端界面为客服中心界面；
所述数据管理单元包括基础数据管理模块、业务运行数据管理模块、指标数据管理模块和系统运行数据管理模块；其中基础数据管理模块为整个生态平台提供基础数据支撑，其管理的数据包括用户数据、组织架构数据、设备设施数据和空间数据；
业务运行数据管理模块中的数据与生态业务接入管理单元中接入的各业务子系统对应，当有新的业务子系统接入到生态业务接入管理单元中，则业务运行数据管理模块中对应增加新接入的业务子系统的数据；
所述指标数据管理模块中的数据包括安全指标数据、品质指标数据、工单指标数据、成本指标数据和能耗指标数据；
所述数据分析单元包括数据处理模块和模型管理模块，所述数据处理模块对数据管理单元中各类数据进行数据清洗、数据建模和/或数据计算处理；所述模型管理模块中包括有安全指标模型、成本指标模型、品质指标模型、能耗指标模型、告警信息分配模型、医院后勤服务指标模型和工单指标模型；数据分析单元中的数据处理模块对数据管理单元中的各业务运行数据进行处理，并根据模型管理模块中设定的各模型分析得到各指标数据，并将分析得到的各指标数据对应存储于数据管理单元中的指标数据管理模块中；
所述应用中心用于展示生态业务接入管理单元中接入的各业务子系统；所述服务商管理单元用于管理生态业务接入管理单元中接入的各业务子系统的服务商；
所述生态业务接入管理单元包括接入管理模块和若干个已接入的业务子系统；所述接入管理模块为待接入的业务子系统提供接入权限管理和接入接口管理服务；接入管理模块获取待接入的业务子系统的对接接口路径信息，通过接口回调的方式将动态验证码、医院租户标识和服务商应用唯一标识传输给待接入的业务子系统中；当待接入的业务子系统调用接入管理模块中的接口时，需要在接口中向接入管理模块传入访问令牌，接入管理模块对待接入的业务子系统进行鉴权；当接入管理模块调用待接入的业务子系统的接口时，在接口中向待接入的业务子系统传入鉴权令牌，待接入的业务子系统根据接入管理模块传入的鉴权令牌进行鉴权认证，鉴权认证通过后，待接入的业务子系统接入到生态业务接入管理单元中；
所述生态技术接入管理单元用于对接入的成熟技术进行管理，包括BIM可视化展示模块、IOT物联网管理模块、CV机器视觉管理模块、知识图谱模块、室内定位模块和AGV机器人管理模块，生态技术接入管理单元根据数据管理单元中的数据对应生态技术接入管理单元中接入的技术模块，并通过该技术模块向用户端发送对应数据信息；
所述管理中心界面中包括安全指标分析菜单、品质指标分析菜单、服务指标分析菜单、人员指标分析菜单、财务指标分析菜单、指标报告报表菜单和综合评价菜单；所述综合评价菜单用于展示业务用户对生态业务接入管理单元中接入的各业务子系统的反馈和评价信息，并对业务子系统提供的服务和整体运营情况进行评价，为决策者用户提供管理决策数据和辅助分析；
所述运维中心界面中包括机电系统和能源系统实时监控菜单、设备告警监控菜单、巡检视频监控菜单和应急响应服务菜单；所述客服中心界面中包括报修工单下发菜单、巡检工单下发菜单、保洁工单下发菜单、工单管理服务菜单和历史工单分析菜单。
2.如权利要求1所述的医院后勤运营管理生态平台，其特征在于：所述数据分析单元汇聚业务运行数据管理模块中各接入的业务子系统产生的实时业务数据和业务运行数据管理模块存储的历史数据，对数据进行清洗和格式化处理，并将格式化处理后的数据按照时间、空间、人员、事件、设备和费用六个维度进行整理，并计算各维度下的二级指标的指标值，将指标计算结果反馈至数据管理单元中的指标数据管理模块中，并通过生态技术接入管理单元中对应接入的技术模块向对应的用户展示。
3.如权利要求1或2所述的医院后勤运营管理生态平台，其特征在于：所述生态平台的部署模式包括云端部署模式、院端部署模式和混合部署模式；所述云端部署模式是指将所述生态平台及其生态业务接入管理单元中接入的各业务子系统均部署在云服务器上且所有数据也均保存在云服务器上；所述院端部署是指将所述生态平台及其生态业务接入管理单元中接入的各业务子系统均部署在医院内部网络内的实体或虚体服务器中；所述院端部署根据服务器配置数量和组网模式分为标准模式、完整模式、外网简单模式和内网简单模式四个分支；所述混合部署是指所述生态平台部署在云服务器上，而生态平台的生态业务接入管理单元中接入的各业务子系统部署在医院内部网络内的实体或虚体服务器中。
4.如权利要求3所述的医院后勤运营管理生态平台，其特征在于：所述院端部署模式中的标准模式至少需两台服务器，一台服务器作为堡垒网关服务器部署在医院的DMZ区与互联网连通，另一台作为生态平台及其生态业务接入管理单元中接入的各业务子系统的应用服务器及数据库服务器部署在医院的核心区。
5.如权利要求3所述的医院后勤运营管理生态平台，其特征在于：所述院端部署模式中的外网简单模式至少需一台服务器，该服务器作为堡垒网关服务器、生态平台的应用服务器及数据库服务器，部署在医院的DMZ区与互联网连通。
6.如权利要求3所述的医院后勤运营管理生态平台，其特征在于：所述院端部署模式中的内网简单模式至少需一台服务器，该服务器作为生态平台的应用服务器及数据库服务器部署在医院的核心区，不与互联网连通。
7.如权利要求3所述的医院后勤运营管理生态平台，其特征在于：所述院端部署模式中的完整模式至少需要三台服务器，一台作为堡垒网关服务器部署在医院的DMZ区与互联网连通，另外两台分别作为生态平台的应用服务器和数据库服务器部署在医院的核心区。
8.如权利要求1或2所述的医院后勤运营管理生态平台，其特征在于：所述用户端的呈现方式包括App、BIM、WEB、微信公众号、微信小程序、企业微信和钉钉中的任意一种或多种的组合。
9.如权利要求1所述的医院后勤运营管理生态平台，其特征在于：所述综合评价菜单中展示的评价信息，是数据分析单元经过下述处理过程得到的：
数据分析单元中的数据处理模块采集接入到生态业务接入管理单元中各业务子系统产生的实时业务数据和存储于业务运行数据管理模块中的历史业务数据，对采集到的实时业务数据和历史业务数据进行校验，过滤掉非法记录后，汇聚成后勤业务数据，保存在数据管理单元的业务运行数据管理模块中，并将校验后的后勤业务数据传输至模型管理模块；
所述模型管理模块将接收到的后勤业务数据，根据按照人员、财务、物资、安全、质量和服务六个维度定义的医院后勤服务指标模型，计算出指标值，并将指标值保存在指标数据管理模块中，且计算出各指标值对应的权重值；
具体是采用层次分析法计算各个指标的权重值，对各个指标的指标值进行归一化处理，再根据各个指标的权重值使用加权平均法，计算出各个指标的加权平均值，最后将加权平均值作为医院后勤服务质量评分，并将医院后勤服务质量评分传输至综合评价菜单中，供决策者用户查看。
10.如权利要求9所述的医院后勤运营管理生态平台，其特征在于：所述数据分析单元可根据大量的医院后勤服务质量评分，使用统计学建立医院后勤服务质量评级模型；并将医院后勤服务质量评分输入医院后勤服务质量评级模型中得到医院后勤服务质量评级，将医院后勤服务质量评级结果传输至综合评价菜单中，供决策者用户查看。
11.如权利要求9或10所述的医院后勤运营管理生态平台，其特征在于：所述后勤业务数据包括生态业务接入管理单元中接入的综合监控类业务子系统的告警数据，业务运维类业务子系统的工单数据，患者服务类业务子系统的订单数据，财务管理业务子系统的后勤预算和成本数据、物资库存数据和工程项目数据。
12.如权利要求11所述的医院后勤运营管理生态平台，其特征在于：所述生态业务接入管理单元中接入的综合监控类业务子系统包括能耗计量监控、电梯监控、医用气体监控、变配电监控、给排水监控、锅炉监控、空调监控和消防监控；所述告警数据包括告警等级、告警设备名、告警类型、告警系统名、告警事件、告警时间和恢复时间。
13.如权利要求11所述的医院后勤运营管理生态平台，其特征在于：所述生态业务接入管理单元中接入的业务运维类业务子系统包括机电运维子系统、医废管理子系统、安保子系统、设备管理子系统、被服管理子系统、清洁服务子系统、运送管理子系统；所述工单数据包括工单类型、工单状态、工单位置、工单内容、工单下单人电话、工单下单人、工单下单部门、工单接单人员、工单下单时间、工单接单时间和工单完成时间。
14.如权利要求11所述的医院后勤运营管理生态平台，其特征在于：所述生态业务接入管理单元中接入的患者服务类业务子系统包括护工护理子系统、停车场管理子系统、便利店管理子系统、餐饮服务子系统、共享轮椅管理子系统和陪护床租赁子系统；所述订单数据包括订单类型、订单状态、订单商品、订单内容、订单金额、订单下单人电话、订单下单时间和订单完成时间。
15.如权利要求1所述的医院后勤运营管理生态平台，其特征在于：所述生态业务接入管理单元中接入的财务管理业务子系统包括预算管理模块、成本管理模块、物资管理模块和工程管理模块；所述预算和成本数据包括费用年度、费用科目、费用金额和费用时间；所述库存数据包括物资编码、物资名称、物资单位、物资数量、物资单价、物资操作人和物资操作时间；所述工程项目数据包括项目编码、项目名称、项目金额、施工单位、施工内容、项目操作人和项目操作时间。
16.如权利要求9或10所述的医院后勤运营管理生态平台，其特征在于：所述采用层次分析法计算各指标的权重值的具体过程如下：
对同一层次不同指标的重要性进行两两打分，构建判断矩阵，对判断矩阵进行一致性校验，当判断矩阵通过一致性校验的情况下，根据判断矩阵的最大特征根，求解出判断矩阵归一化后的特征向量，作为权向量，其中，所述权向量中包含各指标的权重值。
17.如权利要求16所述的医院后勤运营管理生态平台，其特征在于：各指标的指标值计算是利用数学方法将每一种指标通过数据转换公式变换到统一区间，数据转换公式为：
Figure 957977DEST_PATH_IMAGE001
，式中X（
Figure 457091DEST_PATH_IMAGE002
）是原实际指标值，[A,B]为指标对应 的取值范围，
Figure 84381DEST_PATH_IMAGE003
是将X转换到区间[N，M]后的指标值，所有指标都采用相同的N和M，N=0，M= 1。
18.如权利要求9或10所述的医院后勤运营管理生态平台，其特征在于：所述医院后勤服务质量评分表示为
Figure 812297DEST_PATH_IMAGE004
，式中，K为医院后勤服务质量评分，L表示指标数总数，
Figure 474223DEST_PATH_IMAGE005
表示第
Figure 878659DEST_PATH_IMAGE006
个指标的权重值，
Figure 993246DEST_PATH_IMAGE007
表示第
Figure 774120DEST_PATH_IMAGE006
个指标的转换值。
19.如权利要求18所述的医院后勤运营管理生态平台，其特征在于：所述数据分析单元获得多家医院的后勤服务质量的综合评价得分，即第i家医院评价得分记为
Figure 38355DEST_PATH_IMAGE008
，将这些医院的评价得分从小到大进行排序后计算出1/4分位数、1/2分位数、3/4分位数，分别记为
Figure 879272DEST_PATH_IMAGE009
、
Figure 215575DEST_PATH_IMAGE010
、
Figure 800140DEST_PATH_IMAGE011
；当医院评价得分
Figure 921811DEST_PATH_IMAGE012
则后勤服务质量评级为“不合格”；当医院评价得分
Figure 668050DEST_PATH_IMAGE013
，则后勤服务质量评级为“合格”；当医院评价得分
Figure 491650DEST_PATH_IMAGE014
，则后勤服务质量评级为“良好”；当医院评价得分
Figure 145485DEST_PATH_IMAGE015
，则后勤服务质量评级为“优秀”。
20.如权利要求1所述的医院后勤运营管理生态平台，其特征在于：所述数据分析单元中数据处理模块中包括有告警数据采集子模块，所述告警数据采集子模块采集已接入平台的各业务子系统的告警信息，将采集到的告警信息保存到数据管理单元中，并对告警信息进行过滤和分配；将告警信息输入模型管理模块中的告警信息分配模型中，并输出分配结果，并将分配结果反馈至数据处理模块，所述分配结果包括告警通知策略、推送策略和工单处理策略；
所述数据处理模块中的告警数据处理子模块依照模型管理模块反馈的分配结果，向监管者用户推送告警通知消息；告警数据处理子模块和数据管理单元跟踪告警信息的生命周期；告警数据处理子模块根据工单处理策略向对应工单管理模块提交工单派发请求；
所述工单管理模块将告警数据处理子模块提交的工单派发请求派发至与该工单业务对应的业务子系统中，业务子系统生成工单后，将工单信息传输至对应该业务子系统的用户的客户端上，该工单信息在该用户的客服中心界面的工单管理服务菜单中显示；所述工单管理模块跟踪该工单的全生命周期，当工单的状态为已关闭后，工单管理模块将该工单的处理结果回馈至模型管理模块，模型管理模块将回馈的工单处理结果作为告警信息分配模型的优化参数，对告警信息分配模型进行优化。
21.如权利要求20所述的医院后勤运营管理生态平台，其特征在于：所述告警数据采集子模块采集的告警信息的来源包括硬件设备告警信息、业务子系统告警信息和业务异常信息；所述硬件设备告警信息是指硬件设备中根据预设阈值的判断产生的告警信息；所述业务子系统告警信息是指生态业务接入管理单元中各业务子系统识别出的违反常态的业务信息；所述业务异常信息是指告警数据处理子模块和工单管理模块中工单状态或告警信息状态超出阈值的信息。
22.如权利要求20或21所述的医院后勤运营管理生态平台，其特征在于：所述告警数据采集子模块采集的告警信息的信息格式包括来源类型、来源系统、异常类型、预设阈值、对象信息、对象位置、异常描述和告警发生时间；
所述模型管理模块中告警信息分配模型输出的分配结果的信息格式包括推送方式、推送人员、来源类型、来源系统、告警级别、对象信息、派单判定结果和告警发生时间；
所述工单管理模块中收到的派发工单请求的信息格式包括接单系统、工单处理级别、工单指派人员、工单监督人员、异常描述和告警发生时间；
所述工单管理模块中工单的处理结果的信息格式包括推送人员、修正工单处理级别、工单指派人员、工单监督人员、工单派发时间和处理状态。
23.如权利要求22所述的医院后勤运营管理生态平台，其特征在于：所述告警信息分配模型的处理过程如下所示：
根据异常类型、预设阈值、对象信息、对象位置、异常描述，采用Apriori算法得出概率最高的级别值，作为告警级别和工单处理级别的输入内容；
根据来源类型、来源系统、对象信息、告警级别、告警发生时间和异常描述按照与预配置设定得出推送方式和推送人员信息；
根据来源类型、来源系统、对象信息、对象位置、异常描述，经过Apriori算法得出概率超过预设值的接单系统名，若无，则派单判定为否，若有则填入派单判定，若出现多个，则填入多个；
根据对象信息、对象位置、工单处理级别、系统当前时间和以上计算记过中得出的接单系统，经过Apriori算法得出概率超过预设值的派单人员列表和监督人员列表。
24.如权利要求23所述的医院后勤运营管理生态平台，其特征在于：模型管理模块将回馈的工单处理结果作为告警信息分配模型的优化参数，对告警信息分配模型进行优化，具体是指，根据工单处理结果中的修正处理级别和处理状态，对与该工单处理结果对应的原始告警信息同类的告警信息的工单处理级别进行优化。
25.如权利要求1所述的医院后勤运营管理生态平台，其特征在于：所述生态业务接入管理单元中接入有能源管理业务子系统，所述能源管理业务子系统包括能源数据采集模块、能源数据管理模块和能耗预测模块，所述能源数据采集模块通过Modbus、OPC或Socket接口协议采集底层能量计量设备的能耗数据，将采集到的能耗数据传输至能源数据管理模块进行汇总和监控，并保存在数据管理单元中；所述能耗预测模块将能源数据管理模块中汇总的一采集周期内的能耗数据输入到能耗预测模型中，得到未来一采集周期内的能耗预测数据。
26.如权利要求25所述的医院后勤运营管理生态平台，其特征在于：所述能耗预测模型的通过下述训练过程训练得到的：
将能源数据管理模块中汇总的分类能耗数据折算成总能耗，得到总能耗数据，将总能耗数据作为样本数据；对样本数据进行预处理，并搭建特征库，对特征进行整理；采用主成分析法对特征进行降维，降维之后的样本数据划分为训练集和测试集；搭建LenNet-5网络模型或CNN训练网络模型，从而得到所述能耗预测模型。
CN202110987399.7A 2021-08-26 2021-08-26 医院后勤运营管理生态平台 Active CN113436716B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110987399.7A CN113436716B (zh) 2021-08-26 2021-08-26 医院后勤运营管理生态平台

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110987399.7A CN113436716B (zh) 2021-08-26 2021-08-26 医院后勤运营管理生态平台

Publications (2)

Publication Number Publication Date
CN113436716A true CN113436716A (zh) 2021-09-24
CN113436716B CN113436716B (zh) 2021-11-30

Family

ID=77798049

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110987399.7A Active CN113436716B (zh) 2021-08-26 2021-08-26 医院后勤运营管理生态平台

Country Status (1)

Country Link
CN (1) CN113436716B (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114066332A (zh) * 2022-01-17 2022-02-18 融通地产物业管理有限公司 一种中央运送服务数字化管理方法和系统
CN114267440A (zh) * 2022-03-01 2022-04-01 四川大学华西医院 医疗订单信息处理方法、装置和计算机可读存储介质
CN115658675A (zh) * 2022-12-06 2023-01-31 遵义钟钟网络科技有限公司 应用于数据处理的噪声优化方法及ai系统
CN116307584A (zh) * 2023-03-20 2023-06-23 海口明邦实业有限责任公司 一种基于大数据的医疗洗涤供热监管系统及方法
CN117151695A (zh) * 2023-09-19 2023-12-01 武汉华康世纪医疗股份有限公司 一种基于关系图谱与时空轨迹的医院节能方法及系统
CN117236796A (zh) * 2023-11-13 2023-12-15 天津市城市规划设计研究总院有限公司 一种基于cs-topsis算法的医院后勤运维评价方法及系统
CN118246707A (zh) * 2024-05-28 2024-06-25 江苏细元科技有限公司 一种基于区块链技术的智慧后勤管理系统及方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102591310A (zh) * 2012-03-13 2012-07-18 江苏省人民医院 一种医院后勤综合监控系统
CN107426330A (zh) * 2017-08-08 2017-12-01 丹阳市人民医院 一种医院后勤管理系统和方法
CN107622790A (zh) * 2017-09-22 2018-01-23 国药医工（南通）医学工程技术有限公司 一种医疗设备全生命周期管理方法
CN107993706A (zh) * 2017-12-26 2018-05-04 哈尔滨普迪亚科技有限公司 一种医养健康管理信息服务系统
CN110706764A (zh) * 2019-08-22 2020-01-17 上海市第六人民医院 一种智慧医院信息交互系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102591310A (zh) * 2012-03-13 2012-07-18 江苏省人民医院 一种医院后勤综合监控系统
CN107426330A (zh) * 2017-08-08 2017-12-01 丹阳市人民医院 一种医院后勤管理系统和方法
CN107622790A (zh) * 2017-09-22 2018-01-23 国药医工（南通）医学工程技术有限公司 一种医疗设备全生命周期管理方法
CN107993706A (zh) * 2017-12-26 2018-05-04 哈尔滨普迪亚科技有限公司 一种医养健康管理信息服务系统
CN110706764A (zh) * 2019-08-22 2020-01-17 上海市第六人民医院 一种智慧医院信息交互系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
古河软件: "医院后勤综合管理平台解决方案", 《百度》 *
李新江: "基于云计算平台的医院后勤信息管理系统设计", 《粘接》 *
汪艳: "后勤运送平台建设与实践", 《经济师》 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114066332A (zh) * 2022-01-17 2022-02-18 融通地产物业管理有限公司 一种中央运送服务数字化管理方法和系统
CN114066332B (zh) * 2022-01-17 2022-04-19 融通地产物业管理有限公司 一种中央运送服务数字化管理方法和系统
CN114267440A (zh) * 2022-03-01 2022-04-01 四川大学华西医院 医疗订单信息处理方法、装置和计算机可读存储介质
CN114267440B (zh) * 2022-03-01 2022-06-14 四川大学华西医院 医疗订单信息处理方法、装置和计算机可读存储介质
CN115658675A (zh) * 2022-12-06 2023-01-31 遵义钟钟网络科技有限公司 应用于数据处理的噪声优化方法及ai系统
CN115658675B (zh) * 2022-12-06 2023-11-14 湖南风云通达信息科技有限公司 应用于数据处理的噪声优化方法及ai系统
CN116307584B (zh) * 2023-03-20 2023-09-29 海口明邦实业有限责任公司 一种基于大数据的医疗洗涤供热监管系统及方法
CN116307584A (zh) * 2023-03-20 2023-06-23 海口明邦实业有限责任公司 一种基于大数据的医疗洗涤供热监管系统及方法
CN117151695A (zh) * 2023-09-19 2023-12-01 武汉华康世纪医疗股份有限公司 一种基于关系图谱与时空轨迹的医院节能方法及系统
CN117151695B (zh) * 2023-09-19 2024-05-10 武汉华康世纪医疗股份有限公司 一种基于关系图谱与时空轨迹的医院节能方法及系统
CN117236796A (zh) * 2023-11-13 2023-12-15 天津市城市规划设计研究总院有限公司 一种基于cs-topsis算法的医院后勤运维评价方法及系统
CN117236796B (zh) * 2023-11-13 2024-02-02 天津市城市规划设计研究总院有限公司 一种基于cs-topsis算法的医院后勤运维评价方法及系统
CN118246707A (zh) * 2024-05-28 2024-06-25 江苏细元科技有限公司 一种基于区块链技术的智慧后勤管理系统及方法
CN118246707B (zh) * 2024-05-28 2024-07-26 江苏细元科技有限公司 一种基于区块链技术的智慧后勤管理系统及方法

Also Published As

Publication number Publication date
CN113436716B (zh) 2021-11-30

Similar Documents

Publication Publication Date Title
CN113436716B (zh) 医院后勤运营管理生态平台
CN113159339B (zh) 一种基于大数据的一台区一指标线损管理方法及系统
CN107256443B (zh) 基于业务和数据集成的线损实时计算方法
CN102882969B (zh) 一种工矿企业的安全生产云服务平台
CN105303306B (zh) 电力物资调度平台系统
CN102932419B (zh) 一种用于面向工矿企业的安全生产云服务平台的数据存储系统
CN102917032B (zh) 一种工矿企业的安全生产云服务平台
Poort et al. RCDA: Architecting as a risk-and cost management discipline
CN107220758B (zh) 一种电网规划辅助系统
WO2022144710A1 (en) Methods and systems for digital twin augmented reality replication of non-homogeneous elements in integrated environments
CN102929827A (zh) 一种用于面向工矿企业的安全生产云服务平台的无线传感器数据采集集群
CN102917031A (zh) 一种用于面向工矿企业的安全生产云服务平台的数据计算系统
CN117172641A (zh) 基于区块链与数字孪生的生产物流管理平台及实现方法
CN112200486A (zh) 一种供应链金融风险控制的方法
CN102903009B (zh) 一种用于面向工矿企业的安全生产云服务平台的基于广义规则推理的异常诊断方法
CN115271519A (zh) 一种电力抢修服务质量综合评价平台
Yousefnezhad et al. Product lifecycle information management with digital twin: a case study
US20240004361A1 (en) Building automation system with digital twin population from commissioning workflow
Si et al. Self-Organizing Optimization of Construction Project Management Based on Building Information Modeling and Digital Technology
KR102354181B1 (ko) 비쥬얼라이징 구현 가능한 건설 사업 정보 관리 시스템 및 이의 제어 방법
Ullberg et al. A tool for interoperability analysis of enterprise architecture models using Pi-OCL
Energy Edge driven Digital Twins in distributed energy systems
CN115857902A (zh) 一种基于数据中台和业务中台的低代码系统及其工作方法
Sahebjamnia et al. Designing a new model of distributed quality control for sub-assemble products based on the intelligent web information system
WO2022266509A1 (en) Building data platform with digital twin enrichment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant