CN116705259A - 城市大数据分析方法、装置、系统、电子设备 - Google Patents

城市大数据分析方法、装置、系统、电子设备 Download PDF

Info

Publication number
CN116705259A
CN116705259A CN202310658766.8A CN202310658766A CN116705259A CN 116705259 A CN116705259 A CN 116705259A CN 202310658766 A CN202310658766 A CN 202310658766A CN 116705259 A CN116705259 A CN 116705259A
Authority
CN
China
Prior art keywords
department
time
saturation
patient
target
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.)
Pending
Application number
CN202310658766.8A
Other languages
English (en)
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.)
Shanxi Custom Technology Co ltd
Original Assignee
Shanxi Custom Technology 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 Shanxi Custom Technology Co ltd filed Critical Shanxi Custom Technology Co ltd
Priority to CN202310658766.8A priority Critical patent/CN116705259A/zh
Publication of CN116705259A publication Critical patent/CN116705259A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT 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/20ICT 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2219Large Object storage; Management thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0631Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06312Adjustment or analysis of established resource schedule, e.g. resource or task levelling, or dynamic rescheduling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0631Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06313Resource planning in a project environment

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Operations Research (AREA)
  • Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Tourism & Hospitality (AREA)
  • Game Theory and Decision Science (AREA)
  • Quality & Reliability (AREA)
  • Marketing (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Public Health (AREA)
  • Biomedical Technology (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

本申请涉及一种城市大数据分析方法、装置、系统、电子设备,涉及数据分析的领域,该方法包括接收患者终端发送的挂号信息;调取目标科室在目标挂号时间对应日期的诊疗数据,预测对应的第一运行饱和度;若第一运行饱和度大于目标科室的饱和度阈值,则根据患者身份信息向患者终端发送目标科室过饱和提示以及就诊症状调研请求;基于就诊症状信息、病史信息,进行数据统计分析确定分诊科室;若分诊科室不为目标科室,则调取分诊科室在挂号时间对应日期的诊疗数据,预测分诊科室对应的第二运行饱和度;若第二运行饱和度小于分诊科室饱和度阈值,则向患者终端发送挂号科室调整建议。对医疗大数据科室饱和度的预测分析,提升患者的就诊体验。

Description

城市大数据分析方法、装置、系统、电子设备
技术领域
本申请涉及数据分析的领域,尤其是涉及一种城市大数据分析方法、装置、系统、电子设备。
背景技术
在大城市的某些大型医院,往往会出现患者流量大的情况,患者在挂号就诊时可能需要排长队等待就诊,或者需要等待很长时间才能得到医生的诊断和治疗,但是由于医疗资源不足,患者可能需要等待数小时或数天才能得到手术或其他治疗,耽误了治病疗程,此外医疗资源拥堵还可能导致医生和护士的工作负担加重,他们可能需要在疲惫的状态下工作,这可能会影响他们的工作效率和患者的治疗质量,因此需要缓解医疗资源的拥堵,提高患者的就诊体验。
发明内容
为了能够保证患者的就诊体验,本申请提供一种城市大数据分析方法、装置、系统、电子设备。
第一方面,本申请提供一种城市大数据分析方法,采用如下的技术方案:
一种城市大数据分析方法,包括:
接收患者终端发送的挂号信息;所述挂号信息包括患者身份信息、目标科室、目标挂号时间;调取所述目标科室在所述目标挂号时间对应日期的诊疗数据,预测所述目标科室在所述目标挂号时间对应的第一运行饱和度;
判断所述第一运行饱和度是否大于所述目标科室的饱和度阈值;
若所述第一运行饱和度大于所述目标科室的饱和度阈值,则根据所述患者身份信息向患者终端发送目标科室过饱和提示以及就诊症状调研请求;
基于患者终端反馈的就诊症状信息、所述患者身份信息,调取病史信息;
基于所述就诊症状信息、所述病史信息,进行数据统计分析确定分诊科室;
若所述分诊科室不为所述目标科室,则调取所述分诊科室在所述目标挂号时间对应日期的诊疗数据,确定所述分诊科室在所述目标挂号时间对应的第二运行饱和度;
判断所述第二运行饱和度是否大于所述分诊科室的饱和度阈值;
若所述第二运行饱和度小于分诊科室饱和度阈值,则向患者终端发送挂号科室调整建议,建议将所述目标科室调整为所述分诊科室。
通过采用上述技术方案,对患者终端的挂号数据进行分析,确定患者目标挂号的科室的饱和度,防止挂号过多导致医疗资源的拥堵,同时为了提高患者的就诊体验,对患者进行分诊调研,确保患者可以准确的挂到正确的科室,有效地避免患者就诊时等待时间过长或无法及时得到医疗服务,从而导致延误病情的情况。通过基于城市医疗大数据对患者挂号科室的饱和度预测和分析,能够快速、准确地将患者分诊到合适的科室,提高医院的就诊效率和医疗水平。同时,通过向患者终端发送提示和建议,也能够提升患者的就诊体验,增强医院的服务质量。
可选的,所述判断所述第二运行饱和度是否大于所述分诊科室的饱和度阈值的步骤之后,还包括:
若所述第二运行饱和度大于或者等于分诊科室饱和度阈值,则获取患者所在城市其他医院对应的分诊科室的第三运行饱和度,确定所述第三运行饱和度最低的对应医院,向患者终端发送挂号医院调整建议,建议患者挂号调整到对应医院的分诊科室。
通过采用上述技术方案,能够实现患者就诊的精准定向,避免了患者在饱和度高的医院排队等候的情况,增加了患者的就诊效率和体验。同时,通过获取各个平级医院或下级医院的分诊科室信息,可以实现医疗资源的合理分配和利用,提高了医疗资源的利用效率。
可选的,确定科室饱和度阈值的步骤,包括:
基于实时存储的历史挂号数据,获取科室的患者的接诊量、挂号时间、每个患者的开始就诊时间;
根据所述接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长;
基于医院科室运行数据确定所述科室对应的医师数量以及医师平均工作时长;
根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值。
通过采用上述技术方案,基于实时存储的历史挂号数据,通过数据分析和计算,能够准确地确定科室的患者接诊情况以及平均等待时长和平均就诊时长等指标,从而可以更加有效的确认科室的医护资源。同时,通过确定科室对应的医师数量和平均工作时长,以及根据实际情况精确的预测科室饱和度阈值,可以更加自动化的确定医院的资源配置方案,从而提高患者就诊体验。
可选的,所述根据所述接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长的步骤,包括:
根据挂号时间以及每个患者的开始就诊时间确定每个患者的等待时长;
通过每个患者的开始就诊时间差确定每个患者的就诊时长;
通过如下公式获取平均等待时长:
W为平均等待时长,n为接诊量,wi为每个患者的每个患者的等待时长;
通过如下公式获取平均就诊时长:
V为平均就诊时长,n为接诊量,vi为每个患者的就诊时长。
通过采用上述技术方案,确定基于历史数据确定每个患者的就诊时长和等待时长,从而能够跟踪就诊等待时间和就诊时长的变化趋势,进而确定患者的平均等待时长和就诊时长,方便后续进行饱和度阈值的预测。
可选的,所述根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值的步骤,包括:
通过如下公式确定科室饱和度阈值;
L为科室饱和度阈值,p为接诊量,V为平均就诊时长,R为医师数量,T为医师平均工作时长,W为平均等待时长。
通过采用上述技术方案,基于对历史诊疗数据的分析,获取大量就诊数据,针对当前科室的运行状态,对饱和度的变化趋势进行分析,确定最终的饱和度阈值,可以确定当前科室的运行状态不超负荷,从而提高医师工作效率。
可选的,所述调取所述目标科室在所述目标挂号时间对应日期的诊疗数据,预测所述目标科室在所述目标挂号时间对应的第一运行饱和度的步骤,包括:
判断目标挂号时间是否为当日时间;
若目标挂号时间为当日时间,则基于当日时间的目标科室对应的实时挂号数据以及目标医师的平均工作时间预测第一运行饱和度;
若所述目标挂号时间为当日之后的时间,则基于当日之后的挂号数据,以及当日之前历史就诊数据预测第一运行饱和度。
通过采用上述技术方案,预测患者在当日以及当日之后的挂号科室的运行饱和度,如果是当日挂号,则从当日已经存在的数据预测科室饱和度,帮助患者精准预测某个时间点的挂号科室饱和度值,增加患者的满意度。
可选的,所述方法,还包括:
确认患者终端是否接受调整挂号建议;
若患者终端不接受调整挂号建议,以预设时段作为采样间隔,对目标医师的历史接诊数据进行采样,获取医师在该时段内的坐诊时间以及诊断患者数量;
根据坐诊时间以及诊断患者数量确定医师的诊断速度;
根据第一运行饱和度以及目标挂号科室饱和度阈值确定阈值差;
通过所述阈值差以及医师的诊断速度确定等待时长;
获取患者终端的挂号位置,以及医院休息区分布信息,根据医院休息区分布信息确定距离患者位置最近的休息区,将所述等待时长以及所述休息区推荐发送给患者终端。
通过采用上述技术方案,该方法可以提高患者挂号的效率和体验,因为它可以根据医师的历史数据来确定医师的诊断速度和等待时间,从而确定患者的等待时间,并提供最接近患者位置的休息区信息,以便患者可以更好地休息和等待,满足患者的需求和时间要求。
第二方面,本申请提供一种城市大数据分析装置,采用如下的技术方案:
一种城市大数据分析装置,包括:
挂号信息接收模块,用于接收患者终端发送的挂号信息;所述挂号信息包括患者身份信息、目标科室、目标挂号时间;
饱和度预测模块,用于调取所述目标科室在所述目标挂号时间对应日期的诊疗数据,预测所述目标科室在所述目标挂号时间对应的第一运行饱和度;
所述饱和度预测模块,还用于判断所述第一运行饱和度是否大于所述目标科室的饱和度阈值;饱和提示模块,用于若所述第一运行饱和度大于所述目标科室的饱和度阈值,则根据所述患者身份信息向患者终端发送目标科室过饱和提示以及就诊症状调研请求;
病史信息调取模块,用于基于患者终端反馈的就诊症状信息、所述患者身份信息,调取病史信息;
症状调研模块,用于基于所述就诊症状信息、所述病史信息,进行数据统计分析确定分诊科室;
所述饱和度预测模块,还用于确定若所述分诊科室不为所述目标科室,则调取所述分诊科室在所述目标挂号时间对应日期的诊疗数据,确定所述分诊科室在所述目标挂号时间对应的第二运行饱和度;
所述饱和度预测模块,还用于判断所述第二运行饱和度是否大于所述分诊科室的饱和度阈值;科室调整建议模块,用于确定若所述第二运行饱和度小于分诊科室饱和度阈值,则向患者终端发送挂号科室调整建议,建议将所述目标科室调整为所述分诊科室。
可选的,所述装置还包括资源调度模块,用于:
若所述第二运行饱和度大于或者等于分诊科室饱和度阈值,则获取患者所在城市其他医院对应的分诊科室的第三运行饱和度,确定所述第三运行饱和度最低的对应医院,向患者终端发送挂号医院调整建议,建议患者挂号调整到对应医院的分诊科室。
可选的,所述装置还包括阈值数据分析模块,用于
基于实时存储的历史挂号数据,获取科室的患者的接诊量、挂号时间、每个患者的开始就诊时间;
根据所述接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长;
基于医院科室运行数据确定所述科室对应的医师数量以及医师平均工作时长;
根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值。
可选的,所述阈值数据分析模块在根据所述接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长时,具体用于;
根据挂号时间以及每个患者的开始就诊时间确定每个患者的等待时长;
通过每个患者的开始就诊时间差确定每个患者的就诊时长;
通过如下公式获取平均等待时长:
W为平均等待时长,n为接诊量,wi为每个患者的每个患者的等待时长;
通过如下公式获取平均就诊时长:
V为平均就诊时长,n为接诊量,vi为每个患者的就诊时长。
可选的,所述阈值数据分析模块在根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值的步骤,具体用于:通过如下公式确定科室饱和度阈值;
L为科室饱和度阈值,p为接诊量,V为平均就诊时长,R为医师数量,T为医师平均工作时长,W为平均等待时长。
可选的,所述阈值数据分析模块在根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值的步骤,具体用于:通过如下公式确定科室饱和度阈值;
L为科室饱和度阈值,p为接诊量,V为平均就诊时长,R为医师数量,T为医师平均工作时长,W为平均等待时长。
可选的,所述饱和度预测模块在调取所述目标科室在所述目标挂号时间对应日期的诊疗数据,预测所述目标科室在所述目标挂号时间对应的第一运行饱和度时,具体用于:
判断目标挂号时间是否为当日时间;
若目标挂号时间为当日时间,则基于当日时间的目标科室对应的实时挂号数据以及目标医师的平均工作时间预测第一运行饱和度;
若所述目标挂号时间为当日之后的时间,则基于当日之后的挂号数据,以及当日之前历史就诊数据预测第一运行饱和度。
可选的,所述装置还包括区域分析模块,用于:
确认患者终端是否接受调整挂号建议;
若患者终端不接受调整挂号建议,以预设时段作为采样间隔,对目标医师的历史接诊数据进行采样,获取医师在该时段内的坐诊时间以及诊断患者数量;
根据坐诊时间以及诊断患者数量确定医师的诊断速度;
根据第一运行饱和度以及目标挂号科室饱和度阈值确定阈值差;
通过所述阈值差以及医师的诊断速度确定等待时长;
获取患者终端的挂号位置,以及医院休息区分布信息,根据医院休息区分布信息确定距离患者位置最近的休息区,将所述等待时长以及所述休息区推荐发送给患者终端。
第三方面,本申请提供一种电子设备,采用如下的技术方案:
一种电子设备,该电子设备包括:
存储器,用于存储程序指令;
处理器,用于调用并执行所述存储器中的程序指令,执行根据第一方面任一种可能的实现方式所述的方法。
第四方面,本申请提供一种计算机可读存储介质,采用如下的技术方案:
所述计算机可读存储介质中存储有计算机程序;所述计算机程序被处理器执行时,执行第一方面任一项所述的方法。
综上所述,本申请包括以下至少一种有益技术效果:
1.对患者终端的挂号数据进行分析,确定患者目标挂号的科室的饱和度,防止挂号过多导致医疗资源的拥堵,同时为了提高患者的就诊体验,对患者进行分诊调研,确保患者可以准确的挂到正确的科室,同时若科室均达到饱和,则推荐其他医院的对应科室,患者若仍然想挂当前科室,则通过对医院等候区进行检测确定距离患者终端最近的位置,为患者提供路线,有效地避免患者就诊时等待时间过长或无法及时得到医疗服务,从而导致延误病情的情况;2.通过基于城市医疗大数据对患者挂号科室的饱和度预测和分析,能够快速、准确地将患者分诊到合适的科室,提高医院的就诊效率和医疗水平。同时,通过向患者终端发送提示和建议,也能够提升患者的就诊体验,增强医院的服务质量和口碑;
3.能够实现患者就诊的精准定向,避免了患者在饱和度高的医院排队等候的情况,增加了患者的就诊效率和体验。同时,通过获取各个平级医院或下级医院的分诊科室信息,可以实现医疗资源的合理分配和利用,提高了医疗资源的利用效率。
附图说明
图1是本申请实施例的一种城市大数据分析系统的架构图;
图2是本申请实施例的一种城市大数据分析方法的应用场景示意图;
图3是本申请实施例的一种城市大数据分析方法的流程示意图;
图4是本申请实施例的一种城市大数据分析方法的时序图;
图5是本申请另一实施例的一种城市大数据分析方法的路线规划图;
图6是本申请实施例的一种城市大数据分析装置的结构示意图;
图7是本申请实施例的一种电子设备的结构示意图。
具体实施方式
以下结合附图1-7对本申请作进一步详细说明。
本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改,但只要在本申请的范围内都受到专利法的保护。
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
另外,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,如无特殊说明,一般表示前后关联对象是一种“或”的关系。
下面结合说明书附图对本申请实施例作进一步详细描述。
本申请提供的城市大数据分析方法可以作为一个独立的软件系统运行,也可以作为一个城市大数据分析系统中的一个功能模块运行。
在一个场景中,此方法可以被集成为城市大脑平台中的一个功能模块。城市大脑平台即城市大数据分析系统,依托于城市大数据构建的数据分析决策系统,其可以具备多个功能模块,分别实现对不同类别的大数据的分析处理,辅助进行对应领域的相关决策,同时还可以以较为灵活高效的显示模式,对处理结果进行丰富的显示,作为一个信息整合平台及协同服务平台,面向城市管理者,从城市综合管理角度出发,将各类业务系统涉及的相关数据依据以统一的标准进行接入,实现城市运营管理信息资源的全面整合与共享、业务应用的智能协同,并依托于城市基础信息资源数据库、决策分析数据库,为城市管理者提供智能决策支持。以便于城市管理者能够及时全面了解城市运营管理各个环节的关键指标;以智能分析预测等手段,提高管理和服务的响应速度;逐步实现被动式管理向主动式响应的转型,增强城市运营管理能力,完善提升城市服务水平,增强城市的综合竞争能力。
具体的,该平台系统可以实现以下几个方面的功能。
1.全面整合各类资源,明确数据供需关系
通过对各类主题所在领域内部数据整合,以及对接条线部门数据,横向全面整合经济运行、社会管理、市场监管、环境保护、公共服务、营商环境、其他外部系统数据等各类资源,纵向整合国家、省、市、区/县、街道/乡镇等各类主题数据资源,明确数据提供方和需求方的关系。此功能可以被集成为数据采集模块,通过与相应数据系统的对接,建立数据传输双方的关联,及时高效地获取对应的数据资源。
2.大中小屏数据同源,互为补充
基于数据主题模型建设的专题库及应用,确保大中小屏的数据同源,增强数据可信度,构建起大屏观天下、中屏万数通、小屏随身行的多维度、立体化城市治理管理驾驶舱。此功能可以被集成为数据同步模块,针对该平台系统对应的多种终端,实现数据的同步和统一。
3.支撑上层数字应用高效运转
依托一网通办、一网统管等数字应用汇聚的数据,对其进行整合梳理与分析,进一步优化业务流程,分析发展趋势,为一网统管、一网通办等数字应用的深化建设指明方向,支撑上层数字应用的高效运转。从用户体验、用户评价、热点业务、办件能力等维度,分析当前一网通发展的瓶颈,从而采取措施提升或增强一网通办水平;围绕社会管理的现状、事件运转效率与民众诉求焦点,对高发事件类型、案件潮汐进行预测预警,推动职能部门之间高效协作,使一网统管业务运作有的放矢,进一步提升社会治理服务水平。此功能可以被集成为数据分析模块,依据不同的需求点,对相应基础数据进行相应的分析。例如,基于用户评价数据、业务办理进度数据,进行办件效率分析,确定其中存在的低效环节,并给出相应的提升建议。再例如,基于热点政策数据、办件效率数据、民众评论数据,进行高发事件分析、案件潮汐预警,确定潜在的数据爆发节点,并提前进行准备。
该平台系统的整体架构图可以参考图1。下面将分模块进行功能介绍。
大屏、中屏
通过建立城市分析模型,形成城市总体态势感知分析,全面掌握城市运营态势,让城市管理者能够快速、直观地获取城市管理运行体征的各类指标数据,反映城市运营的相关情况。一张图综合展示决策者重点关注的各类城市管理运行体征指标,如一网通办、一网统管、经济运行、民生保障等主题指标。每个主题板块展示该主题比较重要的评价指标数据,当指标达到预警值时标红提示。
通过运行态势感知系统实现“态势感知”业务,实现城市运行微观态势的实时监测与预警。基于主题库数据来源,围绕一网通办、一网统管、经济运行、民生保障等领域,结合地理信息,构建运行全景图。
一网通办感知与分析
一网通办态势感知
依据各区域部门汇聚的数据,对其进行整合梳理与分析,当前可展示的重要指标包括政务服务用户统计、政务办件能力统计,分别从用户角度、办件角度研究分析当前政务服务的水平,从而采取措施提升或增强政务服务水平。
一网通办态势感知包括政务服务总体概况、政务服务用户、办件能力、事项分析、服务办理热点地区、热点业务、评价分析、网上办理、服务评价、申请人、评价分析、服务评价、用户行为分析、用户全景画像。
通过城市通服务门户,提供面向公众的可视化分析界面,向公众发布政务服务相关的数据分析展示,供其办事时参考,也可用于了解本区域政务服务、社会发展等方面的动态。如:通过工作日人流量统计、各时段人流量统计信息,可以更合理地安排到大厅办事的时间;通过企业注册或投资项目审批一般所需时长和瓶颈的分析,提示办事人员提前做好准备工作。
一网通办决策分析
通过事项办件数据、业务运行数据、办事主体信息等资源数据的推送,从而实现运行监控、业务分析、决策参考、效能监管等大数据可视化分析功能。
业务能力分析
业务能力分析主要分为事项分析、办件分析、证照分析、用户分析、效能分析以及互动分析。
主题聚焦分析将主题聚焦分析划分主题,包括:网上服务主题、大厅服务主题、企业设立主题、项目审批主题以及服务延伸主题。
挖掘关联分析
挖掘关联分析则是涉及政务服务与民生、政务服务与经济和落实放管服内容的。
政务服务与民生对政务服务与民生进行挖掘关联分析,关注涉及民生和公共服务等领域服务过程,挖掘惠民情况。
政务服务与经济对政务服务与经济进行挖掘关联分析,从企业设立登记、双创服务、投资项目等政务服务过程数据分析,挖掘经济发展状况。
放管服落实对放管服落实进行挖掘关联分析,展示政务服务中心放管服相关工作情况。
业务资产感知与分析
通过数据看板等形式对全市信息化项目建设按照项目的状态、项目类型等特性值进行统计分析,全景化掌控项目建设和运行情况。通过对系统活跃度、相似度分析,为行政审批服务管理局、市政府领导决策提供辅助,为全市数字政府项目建设提供统一归口管理,同时满足全市数据资源的汇聚、共享、利用的直观分析。
一网统管感知与分析
以综合执法、网格化、12345相关数据形成的一网统管主题信息库,建设地区治理一张图,宏观上了解全地区态势,微观上可层层推进查看具体的隐患/风险内容。对地区社会管理进行主题精细化态势感知和分析预警。
一网统管态势感知
综合执法态势感知
从不同角度展示当前综合执法现状,从而促进政府部门采取措施提升社会治理服务管理水平。在此方面主要围绕运行要情、简易执法、一般执法等指标,对综合执法进行一个宏观的展示。
网格治理态势感知
从不同角度展示当前网格化现状,从而促进政府部门采取措施提升社会治理服务管理水平。在此方面主要围绕网格中心、网格事件、公众上报、人房信息、环保信息、治安信息、教育信息等指标,对网格化进行一个宏观的展示。
政务服务态势感知
从不同角度展示当前政务服务现状,从而促进相关部门采取措施提升社会治理服务管理水平。在此方面主要围绕话务情况、诉求情况、部门办理、工单监察等主题,对政务服务进行一个宏观的展示。
一网统管决策分析
网格案件潮汐分析
当前网格案件分散且量多,通过分析地区不同类型网格案件发生时间及其变化趋势,对其进行相关性计算得到各类网格案情与时间的相关性系数,掌握地区各类网格案件发生的时间规律及责任部门,协调相关部门合理制定政策提前预防加强公共管理。
群体投诉预警分析
对历史爆发的集中投诉事件进行展示,包括发生时间、发生地点、案件类型、案件数量、责任部门、处理满意度。
对集中投诉事件在开始阶段进行捕捉,在还未大规模爆发之前对事件进行提前发现预警,提前预警事件发生地点,事件名称,目前已发生案件数,责任部门。
对存在爆发苗头的集中投诉事件进行影响力预测,判断此类型事件影响力的大中小等级。
高发案件规律分析及预测预警
通过对地区及各区域各类高发案件规律分析,掌握地区各类高发案件发生的时间和地点规律,及时预测预警,为执法工作提供重点引导。
违建拆除优先级分析及预警
通过汇集区域内历史违建执法案件信息,对各区域的违建进行拆除的高贡献率影响因子权重计算,输出两层优先级评判系统。结合下阶段的拆违工作,提前预警违建优先级,为违建工作的进行提供优先拆违的建议。
公共服务感知与分析
公共服务,是公共行政和政府改革的核心理念,包括加强城乡公共设施建设,发展教育、养老、医疗卫生等公共事业,为社会公众参与社会经济、文化活动等提供保障等内容。
随着城市吸引越来越多的外来人口,户籍人口急剧增长也给城市医疗、教育等民生资源配套提出了更高要求;与些同时,从长远来看,要维持发展活力,吸引人、留下人,还是要在提升公共服务水平上持续下工夫。
此主题设计融合教育、医疗、养老等多方面公共服务信息,对不同区域的公共服务能力进行全面、深度的洞察,并从公共服务与人口、空间等多个维度剖析各类型公共服务供给能力,为优化设施配置及运行效率提供决策依据。
公共服务态势感知
教育服务态势感知
主要围绕教育资源概况、学生情况、升学情况、教育经费投入、教学设备投入、师资力量、教育科研等指标,对教育进行一个宏观的展示。
医疗服务态势感知
宏观展示本地区的医疗资源分布、医护人员数量、患者就诊状况、居民医疗支出等,结合各地区对比分析,体现本地区的医疗整体水平。同时,基于需求还可以进一步呈现局部地区数据,如某医院的资质、医护人员数、患者就诊情况等细节数据。
养老服务态势感知
将地区老年人口密度与各养老自由分布均在GIS地图上重叠展,汇聚了全地区60岁以上老年人的户籍、性别、年龄、居住情况、自理能力、收入情况等信息,构建全地区老年人口画像;同时,统计各类养老资源即人均拥有情况,对标长治市平均值,综合呈现全地区养老现状。
公共服务决策分析
学区容纳量预警分析
通过对未来五年学区内人口结构的测算,结合房产证信息与学区划分信息,得出每年各阶段的适龄户籍生数量,将各学区适龄户籍生数量与当年计划招生人数进行匹配计算学区容纳度,对容纳度超负荷的学校进行提示。
医疗资源区域饱和度
区域饱和度主要通过各医院床位饱和情况、患者就诊饱和情况、血库资源供求关系情况来综合计算各区域医疗资源饱和度情况。从卫建委的电子病历数据获取患者的挂号时间、开始就诊时间和下一位患者开始就诊时间,可以聚合计算得到科室的平均等待和平均就诊时间,再匹配各科室医师数量等人均医师资源信息,通过计算得到科室的接诊饱和度。通过卫健委电子病历,得到科室床位总数及科室床位使用量,这样就可以计算出科室床位饱和度。最后,通过血库资源存量情况结合各科血库资源使用申请信息,可以得到科室血库使用情况。将医院分布信息、科室床位使用饱和度、科室接诊饱和度和科室血库使用情况等信息结合,综合分析得出科室的运行饱和度信息。
养老设施合理性分析
在养老领域,基于GIS技术,以日间照料中心等设施卫基础点,与老年人口密度栅格图叠加,得出社区居家养老设施集聚分布与各服务区老年人口密度是否成正比,较老旧的小区一般欠缺基础的养老设施,同时这类小区的老龄化又较高,所以采用地理可达性的测度来衡量基础养老设施的覆盖度。将日间照料中心等分布栅格图与居民点进行叠加分析,得到每个街道距离最近的服务中心及相隔距离,基于城镇社区居家养老服务办件不宜大于1000米的原则,GIS一张图,推送养老设施规划还有待改进的小区。
市场监管感知与分析
围绕市场主体、商品交易、信用监管、市场安全监管、市场标准执行、市场注册管理等指标数据对市场进行监测感知以及决策分析。
市场监管态势感知
市场监管一张图通过构建以信用监管为核心的综合市场监管,重点实现对市场主体、商品交易的全面监管,实现对重点行业、商品的综合监管,实现多部门的协同监管。
市场主体监管主要围绕市场主体信息、重点领域监管、市场主体状态分析、食品药品分析、市场主体区域分析等维度对市场主体进行全方位监管分析。
商品交易监管围绕网络市场监管、农副产品监管、医药食品监管、打击传销和规范直销、农业生产资料市场等维度进行监管分析。
信用监管主要围绕先照后证、多证合一、双随机抽查、红黑名单监管、经营异常企业等维度进行分析预警。
环境保护感知与分析
随着时代的发展和社会的进步,社会各界开始关注环境问题,利用环保有关的数据进行模型的建构,对水资源、大气环境、土地土壤以及污染源等数据进行综合分析,实现对全县环境态势综合展现。
环境保护一张图环境现状(大气环境、土壤环境、水资源环境及固废污染等角度),环境治理(扬尘绿化治理、工地扬尘检查、渣土车监控、企业排污监控等)、治理成效等维度展现全县环境保护监测。
生态宜居主题从水环境、水资源、大气环境、土地土壤环境、声环境、生态环境、生活宜居等维度分析城市生态。
另外可围绕生态健康、环保舆情、环境治理、环境承载等方面进行主题预警监测分析。
空气监测
空气监测涵盖空气环境质量监测和污染源监测。空气监测包括测定风向、风速、气温、气压、湿度等。通过对区域内PM10、PM2.5、SO2、NO2、CO、O3等6项常规空气污染物等含量监测,对异常情况进行实时报警,保障空气质量安全。
经济运行感知与分析
通过经济态势总览与区域对标经济分析两个角度从地区生产总值、规模以上工业总产值、固定资产投资总额等数据进行县经济运行总体态势进行态势感知。呈现经济从宏观到微观、从总体到产业、行业的经济发展等运行情况。
从经济运行的总体态势层面进行经济态势的总览,以总体经济态势为核心逐渐展开,涵盖产业主题发展情况、各行业主题发展情况、区域与园区经济情况以及重点规上企业情况等。通过经济态势总览,能够从面到点再由点到面的全方位洞察,及时了解经济运行情况,支撑对整体经济发展的关键决策。
主要包括:总体经济态势、产业发展态势、行业发展态势、下辖地区态势、重点规上企业、区域对标经济分析等。
其它拓展专题感知与分析
通过建立城市分析模型,形成城市总体态势感知分析,全面掌握城市运营态势,让城市管理者能够快速、直观地获取城市管理运行体征的各类指标数据,反映城市运营的相关情况。一张图综合展示决策者重点关注的各类城市管理运行体征指标,如根据区域范围内常见的特殊情况,设计如疫情模式、汛情模式和寒潮模式等场景态势总览模式,聚焦特定场景下的信息感知和风险防控,实现高效精准的场景治理。每个主题板块展示该主题比较重要的评价指标数据,当指标达到预警值时标红提示。通过运行态势感知系统实现“态势感知”业务,实现城市运行微观态势的实时监测与预警。
在另一个场景中,如图2所示,本申请实施例提供的城市大数据分析方法,作为一个独立的软件系统由电子设备执行,该电子设备可以为服务器也可以为终端设备,其中,该服务器可以是独立的物理服务器,也可以是多个物理服务器构成的服务器集群或者分布式系统,还可以是提供云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机等,但并不局限于此,该终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接,本申请实施例在此不做限制。本申请的方法可以应用于患者就医挂号的场景下,患者终端的位置可以在医院内部也可以在医院外部,患者终端提交挂号数据信息,经过云服务器处理,确定对应挂号医院的科室信息,同时获取挂号医院的科室饱和度,云服务器通过对挂号数据以及患者终端反馈的信息进行分析后,对目标挂号医院对应科室的饱和度进行分析,确定目标挂号医院的饱和度是否能达到接诊新的患者的水平,若不能达到,则对患者病症进行数据分析,确定是否存在分诊科室,以及分诊科室的饱和度是否也能达到接诊新的患者的水平,分诊科室若也不能达到,调取当前城市医疗大数据信息,对其他医院的科室运行饱和度进行多次处理得到分析结果,从而给出能满足患者需求的推荐建议。基于城市医疗大数据对患者挂号科室的饱和度预测和分析,能够快速、准确地将患者分诊到合适的医院科室,进一步满足患者需求,提高患者的挂号就诊体验。
城市大数据分析方法的具体执行过程如图3所示,包括:步骤S101至步骤S109。
步骤S101,接收患者终端发送的挂号信息。
对于本申请实施例,需要说明的是,本申请的执行主体为电子设备,患者终端指的是患者进行挂号操作的终端。挂号信息包括患者身份信息、目标科室、目标挂号时间,可以理解的是,患者的身份信息指的是患者登录系统后上传的具体身份信息。当患者需要挂号时,可以通过手机,登录挂号平台,在相关页面填写个人信息和挂号信息,如姓名、手机号码、就诊科室、就诊医生、就诊日期和时间等,点击提交后,系统会实时根据这些信息通过服务器提取需要的信息。如图4所示,图4为本申请提供的一种时序图,患者登录后提交个人信息,后台经过服务器的验证,进行返回,同时服务器查询并返回患者的个人信息。患者进行挂号,后台判断是否可以挂到科室,通过服务器以及数据分析后获取挂号日期以及科室的饱和状态,返回给患者终端,同时服务器经过数据分析,提供患者挂号调整建议。
步骤S102,调取目标科室在目标挂号时间对应日期的诊疗数据,预测目标科室在目标挂号时间对应的第一运行饱和度。
对于本申请实施例,需要说明的是,目标挂号时间指的是目标挂号时间指的是患者预约的期望就诊的时间,目标挂号时间为一日之内的某个时间节点,这个时间节点是患者在终端设备上进行选择的节点。第一运行饱和度指的是对应科室进行接诊时的运行饱和状态,饱和度数值由多个数据确定,包括接诊量、平均就诊时长、医师数量、医师平均工作时长、患者平均等待时长。依据实际连续多日的医院具体饱和度数值情况,不同科室的运行饱和度最大值不同,例如呼吸科饱和度在1到5之间,心外科饱和度在1到7之间。
可以理解的是,确定目标挂号时间是为了确定挂号的日期,确定是当日还是当日之后,通过对应的挂号日期采用不同的历史诊疗数据预测挂号科室的运行饱和度。
步骤S103,判断第一运行饱和度是否大于目标科室的饱和度阈值。
对于本申请实施例,需要说明的是,目标科室的饱和度阈值指的是该科室可接受的最大运行饱和度值,表征医生可以实现正常工作的最大工作量。如果第一运行饱和度大于目标科室的饱和度阈值,则说明当前科室待诊断患者数量已经达到了冗余状态。
步骤S104,若第一运行饱和度大于目标科室的饱和度阈值,则根据患者身份信息向患者终端发送目标科室过饱和提示以及就诊症状调研请求。
对于本申请实施例,需要说明的是,过饱和提示指的是在目标科室医疗资源已经达到或者超过其承载能力所需资源的接待量上限时,向患者终端发送的提示信息。就诊症状调研请求指的是为了在科室饱和后,向患者终端发送的请求信息,通过了解患者的症状、疾病类型等信息确定患者需要挂号的科室。
具体的,监控目标科室的运行饱和度,并且与设定的饱和度阈值进行比较,例如此时目标科室的饱和度已经超过了阈值,系统会触发目标科室过饱和提示信心并向患者终端发送提示信息,同时向患者终端发送就诊症状调研请求信息,要求患者填写自己的相关基本情况及疾病症状等信息,系统会接收并处理患者填写的信息,对于其中的疾病情况进行分析得到患者应该挂号的科室。
步骤S105,基于患者终端反馈的就诊症状信息、患者身份信息,调取病史信息。
对于本申请实施例,需要说明的是就诊症状信息指的是通过患者终端设备反馈的与患者当前就诊相关的症状体征信息。病史信息指的是患者过去的医疗记录,包括既往患病、治疗和手术等相关信息,这些记录通常由患者的主治医生或医疗机构保存在电子病历等系统中。
具体的,系统接收患者终端反馈的就诊症状信息及身份信息,采用接口方式将数据传输到服务器端,服务器端进行数据鉴权和身份验证。在验证通过后,调用就诊记录管理模块的接口,按照患者身份信息进行数据查询得到病史信息。
步骤S106,基于就诊症状信息、病史信息,进行数据统计分析确定分诊科室。
对于本申请实施例,存储各种疾病的就诊症状、相关病史信息及分诊科室等相关信息到数据库。将就诊症状和病史信息与数据库进行匹配,基于匹配结果,将患者分类到相应的分诊科室。
步骤S107,若分诊科室不为目标科室,则调取分诊科室在目标挂号时间对应日期的诊疗数据,确定分诊科室在目标挂号时间对应的第二运行饱和度。
对于本申请实施例,可以理解的是,经过上述方式进行数据分析后确定分诊科室后,确定的科室会出现与患者挂号科室重复的情况,因此患者无需再进行分诊科室挂号。第二运行饱和度的操作方式与确定第一运行饱和度的方式相同,在此不进行赘述。
步骤S108,判断第二运行饱和度是否大于分诊科室的饱和度阈值。
对于本申请实施例,可以理解的是,分诊科室的饱和度阈值指的是该科室可接受的最大运行饱和度值,表征医生可以实现正常工作的最大工作量。
步骤S109,若第二运行饱和度小于分诊科室饱和度阈值,则向患者终端发送挂号科室调整建议,建议将目标科室调整为分诊科室。
对于本申请实施例,可以理解的是,比较目标科室和分诊科室的饱和度,若目标科室的饱和度小于分诊科室饱和度阈值,则说明目标科室的就诊情况比较空闲,建议将目标科室调整为分诊科室。向患者终端发送挂号科室调整建议,可以通过短信、APP消息等渠道发送给患者,建议内容包括分诊科室的区域、电话等提示患者将挂号科室调整为分诊科室。
在一些实施例中,判断第二运行饱和度是否大于分诊科室的饱和度阈值之后,还包括:若第二运行饱和度大于或者等于分诊科室饱和度阈值,则获取患者所在城市其他医院对应的分诊科室的第三运行饱和度,确定第三运行饱和度最低的对应医院,向患者终端发送挂号医院调整建议,建议患者挂号调整到对应医院的分诊科室。
对于本申请实施例,获取患者所在城市其他医院对应的分诊科室的第三运行饱和度,通过实时获取城市医疗数据并计算并在系统中预先保存各个医院、分诊科室的饱和度数据。确定第三运行饱和度最低的对应医院需要在查询得到各个医院分诊科室的饱和度之后,确定优先级、按照距离远近等进行排序,最终确定第三运行饱和度最低的医院。向患者终端发送挂号医院调整建议,建议患者挂号调整到对应医院的分诊科室,拿到需要推荐医院的数据后,可以通过微信、短信等方式向患者终端发送推荐信息,并提示其进行调整挂号操作。
在另一些实施例中,还可以调取医院的评级、区域数据,以及权威医师坐诊情况的数据,对这些数据进行处理和分析,通过建立一个评分系统来为每个医院进行基于优先级的评分,依据各个医院的评分情况,做出最优选择。除此之外,医院的评级、区域数据,以及权威医师是否坐诊优先级可以由患者确定,例如患者A更看重区域,患者B更看重医师专业度,聚合患者需求数据后,再对其他医院进行相应的优先级选择,最终为患者提供最适合他们需求的医疗服务的对应医院。
在另一些实施例中,上述方法确定科室饱和度阈值的步骤,还可以包括:基于实时存储的历史挂号数据,获取科室的患者的接诊量、挂号时间、每个患者的开始就诊时间;根据接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长;基于医院科室运行数据确定科室对应的医师数量以及医师平均工作时长;根据接诊量、医师数量、医师平均工作时长,平均等待时长和平均就诊时长确定科室饱和度阈值。
对于本申请实施例,实时存储历史挂号数据,在日志系统中及时记录患者的挂号时间、挂号科室、接诊医师、开始就诊时间等信息,为后续计算提供数据支持。通过对历史挂号数据进行分析,得到患者在科室的平均等待时长和平均就诊时长。实时查询并录入医师数量和平均工作时长等信息。在获取到需要的数据后进行自动化计算得到科室的饱和度阈值。
在一些实施例中,上述方法根据接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长的步骤,具体包括:根据挂号时间以及每个患者的开始就诊时间确定每个患者的等待时长;通过每个患者的开始就诊时间差确定每个患者的就诊时长;通过如下公式获取平均等待时长:
W为平均等待时长,n为接诊量,wi为每个患者的每个患者的等待时长;通过如下公式获取平均就诊时长:
V为平均就诊时长,n为接诊量,vi为每个患者的就诊时长。
在一些实施例中,根据接诊量、医师数量、医师平均工作时长,平均等待时长和平均就诊时长确定科室饱和度阈值的步骤,包括:
通过如下公式确定科室饱和度阈值;
L为科室饱和度阈值,p为接诊量,V为平均就诊时长,R为医师数量,T为医师平均工作时长,W为平均等待时长。
对于本申请实施例,获取历史挂号数据中每个患者的挂号时间、开始就诊时间等信息。根据每个患者的挂号时间和开始就诊时间,计算出每个患者的等待时长。等待时长可以用开始就诊时间减去挂号时间得到。根据每个患者的开始就诊时间差,计算出每个患者的就诊时长。就诊时长可以用后一个患者的开始就诊时间前一个患者的开始就诊时间得到。
在另一些实施例中,上述方法调取目标科室在目标挂号时间对应日期的诊疗数据,预测目标科室在目标挂号时间对应的第一运行饱和度的步骤,包括:判断目标挂号时间是否为当日时间;若目标挂号时间为当日时间,则基于当日时间的目标科室对应的实时挂号数据以及目标医师的平均工作时间预测第一运行饱和度;若目标挂号时间为当日之后的时间,则基于当日之后的挂号数据,以及当日之前历史就诊数据预测第一运行饱和度。例如当前科室有三位患者正在就诊,三位患者的就诊时间分别为30分钟,40分钟,50分钟,分别对应三位医师,医师的工作时间为60分钟,根据历史数据确定,患者平均就诊时间为40分钟,患者平均等待时间为20分钟,后面排队的挂号人员还有20位,则通过饱和度计算公式预测科室的饱和度为4。
对于本申请实施例,需要说明的是,由于患者挂号的日期不同,因此参与到计算中的历史数据也不同,如果患者挂号的时间段在当日,由于在挂号之前的诊断数据已经存储在今日的诊疗数据中,当日的诊疗数据更具有参考性,如果患者挂号的时间段在当日之后,可以通过数据库或其他数据存储方式获取历史的挂号数据。
在一些实施例中,上述方法与设备进行信号连接的步骤之后,还可以包括:确认患者终端是否接受调整挂号建议;若患者终端不接受调整挂号建议,以预设时段作为采样间隔,对目标医师的历史接诊数据进行采样,获取医师在该时段内的坐诊时间以及诊断患者数量;根据坐诊时间以及诊断患者数量确定医师的诊断速度;根据第一运行饱和度以及目标挂号科室饱和度阈值确定阈值差;通过阈值差以及医师的诊断速度确定等待时长;获取患者终端的挂号位置,以及医院休息区分布信息,根据医院休息区分布信息确定距离患者位置最近的休息区,将等待时长以及休息区推荐发送给患者终端。
对于本申请实施例,需要说明的是,若向患者终端确认是否接受推荐,则预先设置询问板块,询问板块用于向患者确认推荐是否符合患者需求。根据系统中保存的历史接诊数据,采用预先设定的采样间隔进行数据采样,得到医师在该时段内接诊的患者数量和工作时间。通过采样获得的数据,计算出目标医师在该时段内所用的坐诊时间和诊断的患者数量,医师的诊断速度由患者数量和坐诊时间的比值确定。由于饱和度的与患者数量成正相关,则当患者数量下降,饱和度也会下降。例如当前科室饱和度为4.2,基于历史诊疗数据确定饱和度阈值为4,则阈值差为1,由于平均就诊时长,医师数量,医师平均工作时长,平均等待时长都已经确定,以医生数量为3人,医师的工作时间为60分钟,患者平均就诊时间为40分钟,患者平均等待时间为20分钟,导入饱和度运算公式,确定阈值差对应的接诊量为1人,若目标挂号医生的诊断速度为每小时2人,则患者能够挂上号还需要等待0.5小时,将等待时间发送至患者终端。
可以理解的是,在患者终端得到等待时间后,为了给已经到达医院内部的患者更好的就诊体验,为患者提供等待休息区,通过患者终端发送的请求或使用用户授权的位置信息来获取患者位置。再使用室内地图或其他定位系统来获取休息区的分布信息。分布信息包括休息区的位置、大小、类型等信息,根据这些分布信息获取权值,如图5所示,图5为本申请提供的一种路线指引图,图中存在4个休息区,对应4个规划路径。检测到黑色格子对应的休息区域已经满员,在同一楼层内检测其他休息区域,基于医院的建筑设计数据得到休息区域的位置、大小、类型,以患者位置为起点,计算患者位置到4个休息区的权值长度,选择权值长度最小的休息区作为推荐休息区。
上述实施例从方法流程的角度介绍一种城市大数据分析方法,下述实施例从虚拟模块或者虚拟单元的角度介绍了一种城市大数据分析装置20,具体详见下述实施例。
本申请实施例提供一种城市大数据分析装置20,如图6所示,该城市大数据分析装置20具体可以包括:
挂号信息接收模块201,用于接收患者终端发送的挂号信息;所述挂号信息包括患者身份信息、目标科室、目标挂号时间;
饱和度预测模块202,用于调取所述目标科室在所述目标挂号时间对应日期的诊疗数据,预测所述目标科室在所述目标挂号时间对应的第一运行饱和度;
所述饱和度预测模块202,还用于判断所述第一运行饱和度是否大于所述目标科室的饱和度阈值;
饱和提示模块203,用于若所述第一运行饱和度大于所述目标科室的饱和度阈值,则根据所述患者身份信息向患者终端发送目标科室过饱和提示以及就诊症状调研请求;
病史信息调取模块204,用于基于患者终端反馈的就诊症状信息、所述患者身份信息,调取病史信息;
症状调研模块205,用于基于所述就诊症状信息、所述病史信息,进行数据统计分析确定分诊科室;
所述饱和度预测模块202,还用于确定若所述分诊科室不为所述目标科室,则调取所述分诊科室在所述目标挂号时间对应日期的诊疗数据,确定所述分诊科室在所述目标挂号时间对应的第二运行饱和度;
所述饱和度预测模块202,还用于判断所述第二运行饱和度是否大于所述分诊科室的饱和度阈值;
科室调整建议模块206,用于确定若所述第二运行饱和度小于分诊科室饱和度阈值,则向患者终端发送挂号科室调整建议,建议将所述目标科室调整为所述分诊科室。
可选的,所述装置还包括资源调度模块,用于:
若所述第二运行饱和度大于或者等于分诊科室饱和度阈值,则获取患者所在城市其他医院对应的分诊科室的第三运行饱和度,确定所述第三运行饱和度最低的对应医院,向患者终端发送挂号医院调整建议,建议患者挂号调整到对应医院的分诊科室。
可选的,所述装置还包括阈值数据分析模块,用于
基于实时存储的历史挂号数据,获取科室的患者的接诊量、挂号时间、每个患者的开始就诊时间;
根据所述接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长;
基于医院科室运行数据确定所述科室对应的医师数量以及医师平均工作时长;
根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值。
可选的,所述阈值数据分析模块在根据所述接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长时,具体用于;
根据挂号时间以及每个患者的开始就诊时间确定每个患者的等待时长;
通过每个患者的开始就诊时间差确定每个患者的就诊时长;
通过如下公式获取平均等待时长:
W为平均等待时长,n为接诊量,wi为每个患者的每个患者的等待时长;
通过如下公式获取平均就诊时长:
V为平均就诊时长,n为接诊量,vi为每个患者的就诊时长。
可选的,所述阈值数据分析模块在根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值的步骤,具体用于:通过如下公式确定科室饱和度阈值;
L为科室饱和度阈值,p为接诊量,V为平均就诊时长,R为医师数量,T为医师平均工作时长,W为平均等待时长。
可选的,所述阈值数据分析模块在根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值的步骤,具体用于:通过如下公式确定科室饱和度阈值;
L为科室饱和度阈值,p为接诊量,V为平均就诊时长,R为医师数量,T为医师平均工作时长,W为平均等待时长。
可选的,所述饱和度预测模块202在调取所述目标科室在所述目标挂号时间对应日期的诊疗数据,预测所述目标科室在所述目标挂号时间对应的第一运行饱和度时,具体用于:
判断目标挂号时间是否为当日时间;
若目标挂号时间为当日时间,则基于当日时间的目标科室对应的实时挂号数据以及目标医师的平均工作时间预测第一运行饱和度;
若所述目标挂号时间为当日之后的时间,则基于当日之后的挂号数据,以及当日之前历史就诊数据预测第一运行饱和度。
可选的,所述装置还包括区域分析模块,用于:
确认患者终端是否接受调整挂号建议;
若患者终端不接受调整挂号建议,以预设时段作为采样间隔,对目标医师的历史接诊数据进行采样,获取医师在该时段内的坐诊时间以及诊断患者数量;
根据坐诊时间以及诊断患者数量确定医师的诊断速度;
根据第一运行饱和度以及目标挂号科室饱和度阈值确定阈值差;
通过所述阈值差以及医师的诊断速度确定等待时长;
获取患者终端的挂号位置,以及医院休息区分布信息,根据医院休息区分布信息确定距离患者位置最近的休息区,将所述等待时长以及所述休息区推荐发送给患者终端。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
本申请实施例中提供了一种电子设备,如图7所示,图7所示的电子设备30包括:处理器301和存储器303。其中,处理器301和存储器303相连,如通过总线302相连。可选地,电子设备30还可以包括收发器304。需要说明的是,实际应用中收发器304不限于一个,该电子设备30的结构并不构成对本申请实施例的限定。
处理器301可以是CPU(Central Processing Unit,中央处理器),通用处理器,DSP(Digital Signal Processor,数据信号处理器),ASIC(Application SpecificIntegrated Circuit,专用集成电路),FPGA(Field Programmable Gate Array,现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。处理器301也可以是实现计算功能的组合,例如包含至少一个微处理器组合,DSP和微处理器的组合等。
总线302可包括一通路,在上述组件之间传送信息。总线302可以是PCI(Peripheral Component Interconnect,外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture,扩展工业标准结构)总线等。总线302可以分为地址总线、数据总线、控制总线等。为便于表示,图7中仅用一条粗线表示,但并不表示仅有一根总线或一型的总线。
存储器303可以是ROM(Read Only Memory,只读存储器)或可存储静态信息和指令的其他类型的静态存储设备,RAM(Random Access Memory,随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备,也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory,电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory,只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。
存储器303用于存储执行本申请方案的应用程序代码,并由处理器301来控制执行。处理器301用于执行存储器303中存储的应用程序代码,以实现前述方法实施例所示的内容。
其中,电子设备包括但不限于:移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。还可以为服务器等。图7示出的电子设备仅仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。
应该理解的是,虽然附图的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,其可以以其他的顺序执行。而且,附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,其执行顺序也不必然是依次进行,而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上仅是本申请的部分实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种城市大数据分析方法,其特征在于,包括:
接收患者终端发送的挂号信息;所述挂号信息包括患者身份信息、目标科室、目标挂号时间;调取所述目标科室在所述目标挂号时间对应日期的诊疗数据,预测所述目标科室在所述目标挂号时间对应的第一运行饱和度;
判断所述第一运行饱和度是否大于所述目标科室的饱和度阈值;
若所述第一运行饱和度大于所述目标科室的饱和度阈值,则根据所述患者身份信息向患者终端发送目标科室过饱和提示以及就诊症状调研请求;
基于患者终端反馈的就诊症状信息、所述患者身份信息,调取病史信息;
基于所述就诊症状信息、所述病史信息,进行数据统计分析确定分诊科室;
若所述分诊科室不为所述目标科室,则调取所述分诊科室在所述目标挂号时间对应日期的诊疗数据,确定所述分诊科室在所述目标挂号时间对应的第二运行饱和度;
判断所述第二运行饱和度是否大于所述分诊科室的饱和度阈值;
若所述第二运行饱和度小于分诊科室饱和度阈值,则向患者终端发送挂号科室调整建议,建议将所述目标科室调整为所述分诊科室。
2.根据权利要求1所述的方法,其特征在于,所述判断所述第二运行饱和度是否大于所述分诊科室的饱和度阈值之后,还包括:
若所述第二运行饱和度大于或者等于分诊科室饱和度阈值,则获取患者所在城市其他医院对应的分诊科室的第三运行饱和度,确定所述第三运行饱和度最低的对应医院,向患者终端发送挂号医院调整建议,建议患者挂号调整到对应医院的分诊科室。
3.根据权利要求1所述的方法,其特征在于,确定科室饱和度阈值的步骤,包括:
基于实时存储的历史挂号数据,获取科室的患者的接诊量、挂号时间、每个患者的开始就诊时间;
根据所述接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长;
基于医院科室运行数据确定所述科室对应的医师数量以及医师平均工作时长;
根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值。
4.根据权利要求3所述的方法,其特征在于,所述根据所述接诊量、挂号时间、每个患者的开始就诊时间确定患者的平均等待时长和平均就诊时长的步骤,包括:
根据挂号时间以及每个患者的开始就诊时间确定每个患者的等待时长;
通过每个患者的开始就诊时间差确定每个患者的就诊时长;
通过如下公式获取平均等待时长:
W为平均等待时长,n为接诊量,wi为每个患者的每个患者的等待时长;
通过如下公式获取平均就诊时长:
V为平均就诊时长,n为接诊量,vi为每个患者的就诊时长。
5.根据权利要求3所述的方法,其特征在于,所述根据所述接诊量、所述医师数量、所述医师平均工作时长,所述平均等待时长和所述平均就诊时长确定科室饱和度阈值的步骤,包括:通过如下公式确定科室饱和度阈值;
L为科室饱和度阈值,p为接诊量,V为平均就诊时长,R为医师数量,T为医师平均工作时长,W为平均等待时长。
6.根据权利要求1所述的方法,其特征在于,所述调取所述目标科室在所述目标挂号时间对应日期的诊疗数据,预测所述目标科室在所述目标挂号时间对应的第一运行饱和度的步骤,包括:
判断目标挂号时间是否为当日时间;
若目标挂号时间为当日时间,则基于当日时间的目标科室对应的实时挂号数据以及目标医师的平均工作时间预测第一运行饱和度;
若所述目标挂号时间为当日之后的时间,则基于当日之后的挂号数据,以及当日之前历史就诊数据预测第一运行饱和度。
7.根据权利要求1所述的方法,其特征在于,还包括:
确认患者终端是否接受调整挂号建议;
若患者终端不接受调整挂号建议,以预设时段作为采样间隔,对目标医师的历史接诊数据进行采样,获取医师在该时段内的坐诊时间以及诊断患者数量;
根据坐诊时间以及诊断患者数量确定医师的诊断速度;
根据第一运行饱和度以及目标挂号科室饱和度阈值确定阈值差;
通过所述阈值差以及医师的诊断速度确定等待时长;
获取患者终端的挂号位置,以及医院休息区分布信息,根据医院休息区分布信息确定距离患者位置最近的休息区,将所述等待时长以及所述休息区推荐发送给患者终端。
8.一种城市大数据分析装置,其特征在于,包括:
挂号信息接收模块,用于接收患者终端发送的挂号信息;所述挂号信息包括患者身份信息、目标科室、目标挂号时间;
饱和度预测模块,用于调取所述目标科室在所述目标挂号时间对应日期的诊疗数据,预测所述目标科室在所述目标挂号时间对应的第一运行饱和度;
所述饱和度预测模块,还用于判断所述第一运行饱和度是否大于所述目标科室的饱和度阈值;饱和提示模块,用于若所述第一运行饱和度大于所述目标科室的饱和度阈值,则根据所述患者身份信息向患者终端发送目标科室过饱和提示以及就诊症状调研请求;
病史信息调取模块,用于基于患者终端反馈的就诊症状信息、所述患者身份信息,调取病史信息;
症状调研模块,用于基于所述就诊症状信息、所述病史信息,进行数据统计分析确定分诊科室;
所述饱和度预测模块,还用于确定若所述分诊科室不为所述目标科室,则调取所述分诊科室在所述目标挂号时间对应日期的诊疗数据,确定所述分诊科室在所述目标挂号时间对应的第二运行饱和度;
所述饱和度预测模块,还用于判断所述第二运行饱和度是否大于所述分诊科室的饱和度阈值;科室调整建议模块,用于确定若所述第二运行饱和度小于分诊科室饱和度阈值,则向患者终端发送挂号科室调整建议,建议将所述目标科室调整为所述分诊科室。
9.一种电子设备,其特征在于,包括:存储器和处理器;
所述存储器,用于存储程序指令;
所述处理器,用于调用并执行所述存储器中的程序指令,执行如权利要求1-7任一项所述的方法。
10.一种城市大数据分析系统,其特征在于,包括:数据采集模块、数据同步模块、数据分析模块;
所述数据采集模块,用于采集城市中各医院各科室的医疗资源数据;
所述数据分析模块,用于基于采集到的医疗资源数据,分析确定各医院各科室对应的饱和度阈值,并在接收到患者终端发送的挂号信息后,执行如权利要求1-7任一项所述的方法,生成就诊建议;
所述数据同步模块,用于将所述就诊建议同步至患者终端进行显示。
CN202310658766.8A 2023-06-05 2023-06-05 城市大数据分析方法、装置、系统、电子设备 Pending CN116705259A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310658766.8A CN116705259A (zh) 2023-06-05 2023-06-05 城市大数据分析方法、装置、系统、电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310658766.8A CN116705259A (zh) 2023-06-05 2023-06-05 城市大数据分析方法、装置、系统、电子设备

Publications (1)

Publication Number Publication Date
CN116705259A true CN116705259A (zh) 2023-09-05

Family

ID=87830604

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310658766.8A Pending CN116705259A (zh) 2023-06-05 2023-06-05 城市大数据分析方法、装置、系统、电子设备

Country Status (1)

Country Link
CN (1) CN116705259A (zh)

Similar Documents

Publication Publication Date Title
Shapiro et al. Co-responding police-mental health programs: A review
Ratcliffe et al. The crime reduction effects of public CCTV cameras: a multi‐method spatial approach
CN103093106B (zh) 大型活动中多源数据的传染病症状监测与预警方法
Caplan et al. Risk terrain modeling: Brokering criminological theory and GIS methods for crime forecasting
Mason et al. Substance use, social networks, and the geography of urban adolescents
Haque et al. Modelling malaria treatment practices in Bangladesh using spatial statistics
Mukherjee et al. A comprehensive proposal for blockchain-oriented smart city
Higgs et al. Using Geographic Information Systems to investigate variations in accessibility to ‘extended hours’ primary healthcare provision
Balawanth et al. Assessing Kwa-Zulu-Natal’s progress towards malaria elimination and its readiness for sub-national verification
Fujita Geo-tagged Twitter collection and visualization system
McGuire et al. Travel patterns for government emergency dental care in Australia: a new approach using GIS tools
Smith et al. Can you model growth of trust? A study of the sustainability of a rural community health centre in North India
CN112308325A (zh) 热力图生成方法和装置
Scribner et al. Geospatial methods for identification of core groups for HIV/AIDS
CN116705259A (zh) 城市大数据分析方法、装置、系统、电子设备
Guintran et al. Systems for the early detection of malaria epidemics in Africa: an analysis of current practices and future priorities
Lwasa Geospatial analysis and decision support for health services planning in Uganda
Joshua et al. E-government integration through implementation of web-based GIS on community health monitoring in Jembrana Regency, Bali
Poirier Data (-) based ambivalence regarding NYC 311 data infrastructure
Pijper et al. Building neighbourhood-level resilience to crime: The case of Khayelitsha, South Africa
Lindqvist Motala Municipality–A sustainable safe community in Sweden
Lim et al. The development of a national surveillance system for monitoring blood use and inventory levels at sentinel hospitals in South Korea
Da Ros et al. Supporting Fair and Efficient Emergency Medical Services in a Large Heterogeneous Region
Scott et al. Tempest in a therapeutic community: Implementation and evaluation issues for faith-based programming
Santosa et al. Value of Smart City Services in Improving the Quality of Life: A Literature Review

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