CN117581311A - 心脏泵控制器数据库与医院之间的接口 - Google Patents

心脏泵控制器数据库与医院之间的接口 Download PDF

Info

Publication number
CN117581311A
CN117581311A CN202280043557.6A CN202280043557A CN117581311A CN 117581311 A CN117581311 A CN 117581311A CN 202280043557 A CN202280043557 A CN 202280043557A CN 117581311 A CN117581311 A CN 117581311A
Authority
CN
China
Prior art keywords
data
identifier
heart pump
cloud
pump
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
CN202280043557.6A
Other languages
English (en)
Inventor
D·芭杜
A·埃尔卡特吉
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.)
Abiomed Inc
Original Assignee
Abiomed Inc
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 Abiomed Inc filed Critical Abiomed Inc
Publication of CN117581311A publication Critical patent/CN117581311A/zh
Pending legal-status Critical Current

Links

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/60—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 operation of medical equipment or devices
    • G16H40/67—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 operation of medical equipment or devices for remote operation
    • 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
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M1/00—Suction or pumping devices for medical purposes; Devices for carrying-off, for treatment of, or for carrying-over, body-liquids; Drainage systems
    • A61M1/36—Other treatment of blood in a by-pass of the natural circulatory system, e.g. temperature adaptation, irradiation ; Extra-corporeal blood circuits
    • A61M1/3621—Extra-corporeal blood circuits
    • A61M1/3666—Cardiac or cardiopulmonary bypass, e.g. heart-lung machines
    • 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
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/40—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to mechanical, radiation or invasive therapies, e.g. surgery, laser therapy, dialysis or acupuncture
    • 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
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Biomedical Technology (AREA)
  • Epidemiology (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Cardiology (AREA)
  • Vascular Medicine (AREA)
  • Hematology (AREA)
  • Pulmonology (AREA)
  • Anesthesiology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Animal Behavior & Ethology (AREA)
  • Veterinary Medicine (AREA)
  • Urology & Nephrology (AREA)
  • Surgery (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • External Artificial Organs (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

一种电子接口促进将数据从心脏泵控制器数据库自动传送到EMR系统，从而减少或消除护理人员将心脏泵操作数据从心脏泵控制器屏幕手动转录到EMR系统的需要。一些实施例减少或消除了周期性地访视患者以记录操作数据的需要。替代地，一旦被编程，该接口就可以自动地周期性地将操作数据发送到EMR系统。

Description

心脏泵控制器数据库与医院之间的接口
相关申请的交叉引用
本申请要求于2021年6月30日在美国专利局提交的美国临时申请No.63/216,931的权益和优先权，并且该申请通过引用并入本文。
技术领域
本发明涉及不同医疗系统之间的电子接口，并且更具体地，涉及心脏泵控制数据库和电子医疗记录(EMR)系统之间的电子接口，其中该接口自动地促进将数据从心脏泵控制数据库传送到EMR系统。
背景技术
血管内血泵是可以通过患者的血液循环系统(即，静脉和/或动脉)被推进到患者心脏中的位置或患者循环系统内的其他位置的泵。例如，血管内血泵可以经由导管插入并定位成跨越心脏瓣膜。血管内血泵通常设置在导管的端部处。一旦就位，泵就可以用于将血液泵送通过循环系统，并且因此暂时减少患者心脏的工作负荷，诸如以便使得心脏能够在心脏病发作之后恢复。示例性血管内血泵能够以商品名心脏泵从马萨诸塞州丹弗斯(Danvers,MA)的Abiomed公司获得。
每个血管内血泵通常连接到相应外部心脏泵控制器，该外部心脏泵控制器控制心脏泵(诸如马达速度)，并且收集和显示关于血泵的操作数据(诸如心脏信号水平、电池温度、血液流速和管道完整性)。示例性心脏泵控制器能够以商品名Automated Impella从Abiomed公司获得。当操作数据值落在预定值或范围之外时，例如如果检测到抽吸损失或泄漏，则控制器发出警报。控制器包括在其上显示操作数据和/或警报的视频显示屏作为人类用户接口。
电子医疗记录(EMR)系统通常经由计算机终端存储并促进关于患者的信息的输入。本质上，EMR系统是纸质记录、图表、临床医生笔记等的电子等效物。EMR系统通常存储关于患者的一般信息，诸如直系亲属、医生姓名、处方药和其他当前治疗和医疗历史，包括诊断测试的结果，诸如血压、脉搏率和实验室测试。随时间输入EMR数据，因为该信息由个体医疗从业者收集。EMR系统中的信息对于临床医生在回顾患者的进展和规划患者的治疗方面是有帮助的，有时是至关重要的。
具有血管内血泵的患者通常处于危急状况，并且因此需要频繁监测，因为患者的状况(例如，脉搏、血压等)可能非常快速地(有时在几分钟内)急剧变化。患者状况的变化可能需要血泵的操作参数的变化、药物的变化等。由于临床医生依赖于存储在患者EMR中的关于患者的信息，因此EMR应当及时且频繁地更新。
然而，保持EMR最新通常涉及劳动密集型且不准确的手动过程。通常，为了保持患者的EMR最新，护士或技术人员周期性地访视患者的病房，将在心脏泵控制器的显示屏上显示的操作数据记录在纸上，并且然后进入计算机终端(通常在护理站处)，并且将收集的操作数据输入EMR系统。
然而，护士和技术人员越来越忙于应对其他患者。因此，以频繁的规律间隔返回到心脏泵患者房间以记录操作数据是困难的。此外，如所指出的，心脏泵患者处于危急状况，并且因此需要休息。到患者房间的频繁访视者中断了患者的休息。此外，手动记录来自显示屏的操作数据并且然后将收集的操作数据手动输入到EMR系统中容易出错。
此外，手动输入到EMR系统中的数据通常被存储为不能被其他系统、有时甚至包括复杂自然语言处理器的系统读取的非结构化(自由文本)数据。例如，如果患者被转移或随后住进不同的医院，则一个医院EMR系统中的非结构化患者数据可能具有有限的用途。
另一方面，结构化数据遵循规定的数据模型和值集，限制用户例如仅输入或选择预定值或值类型或受控词汇表。一条结构化数据由两部分组成：变量名称和值，例如“身高：71”。结构化数据可由多个系统(诸如跨多个医院和临床医生办公室的数据库)使用。将结构化数据正确地手动输入到EMR系统并不总是可能的，并且在任何情况下都比输入非结构化数据困难得多。
然而，患者的临床医生依赖于EMR系统中的及时且完整的信息来监测患者并且通知关于调整患者的护理处方的决定。不幸的是，现有技术在很大程度上阻碍了临床医生获得他们所需的及时且准确的信息。因此，现有技术提出的技术问题是如何及时地且理想地自动地收集关于心脏泵患者和心脏泵的信息，并且将收集的信息作为结构化数据存储在EMR中。
发明内容
本公开的一个方面涉及一种用于时间相关的数据的心脏泵数据同步器。心脏泵数据同步器可以包括心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户，该心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户中的每一个被配置用于添加到被配置用于添加到电子医疗记录(EMR)系统并在电子医疗记录(EMR)系统内操作，电子医疗记录(EMR)系统可根据患者识别符访问，并且电子医疗记录(EMR)系统存储关于多个心脏泵患者和多个非心脏泵患者的信息。心脏泵识别器可以包括第一用户接口，该第一用户接口被配置为将针对心脏泵或具有植入的心脏泵的患者中的至少一个的本地输入的识别符的第一提示显示给用户。网络接口可以经由广域计算机网络与基于云的服务器通信，该基于云的服务器不同于EMR系统并且除此之外缺少与EMR系统的通信链路，并且该基于云的服务器存储关于多个植入的心脏泵的历史时间相关的操作数据，历史操作数据包括针对每个植入的心脏泵的多个数据类型。数据项目识别器可以包括第二用户接口，该第二用户接口被配置为将针对时间和多个数据类型中的至少一个数据类型的识别的第二提示显示给用户，时间和至少一个数据类型识别与本地输入的识别符相关联。控制器可以通信地耦接到心脏泵识别器、网络接口和数据项目识别器，并且被配置为响应于接收到本地输入的识别符、时间和至少一个数据类型识别而经由网络接口将本地输入的识别符、时间、至少一个数据类型识别和对与其对应的数据的请求发送到基于云的服务器。监测器可以通信地耦接到网络接口，并且被配置为经由网络接口从基于云的服务器接收由基于云的服务器响应于请求而传输的对应数据。输出门户可以通信地耦接到监测器，并且被配置为将从基于云的服务器接收的对应数据显示给用户。
在一些实施方式中，心脏泵数据同步器还可以包括数据选择器和EMR数据更新器，该数据选择器和EMR数据更新器两者都被配置用于添加到EMR系统并在EMR系统内操作。数据选择器可以包括第三用户接口，该第三用户接口被配置为将针对选择显示给用户的对应数据的至少一部分的指示的第三提示显示给用户。EMR数据更新器可以被配置为将显示给用户的对应数据的所选择的至少一部分作为结构化数据与患者识别符相关联地存储在EMR系统中。在一些实施方式中，监测器可以被配置为经由网络接口从基于云的服务器接收与由基于云的服务器响应于请求而传输的数据相对应的患者识别符，并且EMR数据更新器可以被配置为将对应数据的所选择的至少一部分与由监测器接收的患者识别符相关联地存储在EMR系统中。在一些实施方式中，本地输入的识别符可以包括患者识别符，并且EMR数据更新器可以被配置为将对应数据的所选择的至少一部分与本地输入的识别符相关联地存储在EMR系统中。
在一些实施方式中，每个植入的心脏泵可以机械地耦接到包括显示屏的相应心脏泵控制器，在显示屏上显示植入的心脏泵的操作数据，并且每个心脏泵控制器可以被配置为向基于云的服务器发送表示显示屏的内容的相应视频流。在一些实施方式中，由基于云的服务器存储的历史时间相关的操作数据至少部分地由基于云的服务器从来自相应心脏泵控制器的相应视频流导出。在一些实施方式中，由监测器从基于云的服务器接收的对应数据可以是非视频数据。在一些实施方式中，输出门户包括视频信号合成器，该视频信号合成器被配置为从对应数据至少部分地重新创建视频流，从而将对应数据显示给用户。
在一些实施方式中，本地输入的识别符可以包括相应植入的心脏泵的序列号。在一些实施方式中，本地输入的识别符可以包括患者识别符。在一些实施方式中，历史操作数据可以包括以下中的至少一个：由血泵测量的血压、血泵马达速度、血泵马达电流、血泵的肝素输注速率或血泵吹扫信息(blood pump purge information)。在一些实施方式中，网络接口可以被配置为经由基于云的服务器所提供的应用编程接口(API)与基于云的服务器通信。
在一些实施方式中，心脏泵数据同步器还可以包括扫描仪，该扫描仪被配置为读取表示心脏泵识别符的条形码并提供心脏泵识别符作为本地输入的识别符。在一些实施方式中，扫描仪无线通信地耦接到心脏泵识别器。在一些实施方式中，心脏泵数据同步器还可以包括相机，该相机被配置为读取表示心脏泵识别符的标记并提供心脏泵识别符作为本地输入的识别符。在一些实施方式中，相机无线通信地耦接到心脏泵识别器。
本公开的另一方面涉及一种用于时间相关的数据的心脏泵数据同步器。心脏泵数据同步器可以包括心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和电子医疗记录(EMR)数据更新器，该心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和电子医疗记录(EMR)数据更新器中的每一个被配置用于添加到EMR系统并在EMR系统内操作，该EMR系统可根据患者识别符访问，并且该EMR系统存储关于多个心脏泵患者和多个非心脏泵患者的信息。心脏泵识别器可以包括被配置为将针对心脏泵或具有植入的心脏泵的患者中的至少一个的本地输入的识别符的第一提示显示给用户的用户接口。网络接口可以被配置为经由广域计算机网络与基于云的服务器通信，该基于云的服务器不同于EMR系统并且除此之外缺少与EMR系统的通信链路，并且该基于云的服务器存储关于多个植入的心脏泵的历史时间相关的操作数据，历史操作数据包括针对每个植入的心脏泵的多个数据类型。数据项目识别器可以包括被配置为将针对多个数据类型中的至少一个数据类型的识别的第二提示显示给用户的用户接口，至少一个数据类型识别与本地输入的识别符相关联。控制器可以通信地耦接到心脏泵识别器、网络接口和数据项目识别器，并且被配置为响应于接收到本地输入的识别符和至少一个数据类型识别而经由网络接口将本地输入的识别符、至少一个数据类型识别和对与其对应的数据的请求发送到基于云的服务器。监测器可以通信地耦接到网络接口，并且被配置为经由网络接口从基于云的服务器接收由基于云的服务器响应于请求而传输的对应数据。EMR数据更新器可以被配置为将由监测器接收的对应数据作为结构化数据与患者相关联地自动存储在EMR系统中，该患者与本地输入的识别符相关联。
在一些实施方式中，多个数据类型可以包括以下中的至少两个：由血泵测量的血压、血泵马达速度、血泵马达电流、血泵的肝素输注速率或血泵吹扫信息。在一些实施方式中，数据项目识别器的用户接口还被配置为与至少一个数据类型的识别相关联地从用户输入更新间隔。在一些实施方式中，控制器还被配置为响应于接收到更新间隔而经由网络接口以更新间隔从基于云的服务器自动请求更新的对应数据。在一些实施方式中，EMR数据更新器还被配置为将由监测器接收的更新的对应数据作为结构化数据与患者相关联地自动存储在EMR系统中。
本公开的又一方面涉及一种用于控制心脏泵数据同步器的方法。心脏泵数据同步器可以包括心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户，该心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户中的每一个被配置用于添加到电子医疗记录(EMR)系统并在EMR系统内操作，该EMR系统可根据患者识别符访问并且存储关于多个心脏泵患者和多个非心脏泵患者的信息。网络接口可以被配置为经由广域计算机网络与基于云的服务器通信，该基于云的服务器不同于EMR系统并且除此之外缺少与EMR系统的通信链路，并且该基于云的服务器存储关于多个植入的心脏泵的历史时间相关的操作数据，历史操作数据包括针对每个植入的心脏泵的多个数据类型。该方法可以包括：利用心脏泵识别器的第一用户接口将针对心脏泵或具有植入的心脏泵的患者中的至少一个的本地输入的识别符的第一提示显示给用户；利用数据项目识别器的第二用户接口将针对时间和多个数据类型中的至少一个数据类型的识别的第二提示显示给用户，时间和至少一个数据类型识别与本地输入的识别符相关联；利用控制器经由网络接口将本地输入的识别符、时间、至少一个数据类型识别和对与其对应的数据的请求发送到基于云的服务器；利用监测器经由网络接口接收由基于云的服务器响应于请求而传输的对应数据；以及利用输出门户将对应数据显示给用户。在一些实施方式中，心脏泵数据同步器还包括EMR数据更新器，该EMR数据更新器被配置用于添加到EMR系统并在EMR系统内操作，并且该方法还包括利用EMR数据更新器将显示给用户的对应数据的至少一部分作为结构化数据与本地输入的识别符相关联地存储。
本公开的又一方面涉及一种其上存储有指令的非暂时性计算机可读存储介质，该指令在由一个或多个处理器执行时使一个或多个处理器控制心脏泵数据同步器。心脏泵数据同步器可以包括心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户，该心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户中的每一个被配置用于添加到电子医疗记录(EMR)系统并在EMR系统内操作，该EMR系统可根据患者识别符访问并且存储关于多个心脏泵患者和多个非心脏泵患者的信息。网络接口可以被配置为经由广域计算机网络与基于云的服务器通信，该基于云的服务器不同于EMR系统并且除此之外缺少与EMR系统的通信链路，并且该基于云的服务器存储关于多个植入的心脏泵的历史时间相关的操作数据，历史操作数据包括针对每个植入的心脏泵的多个数据类型。控制心脏泵数据同步器可以包括：控制心脏泵识别器的第一用户接口将针对(a)心脏泵或(b)具有植入的心脏泵的患者中的至少一个的本地输入的识别符的第一提示显示给用户；控制数据项目识别器的第二用户接口将针对时间和多个数据类型中的至少一个数据类型的识别的第二提示显示给用户，时间和至少一个数据类型识别与本地输入的识别符相关联；经由网络接口将本地输入的识别符、时间、至少一个数据类型识别和对与其对应的数据的请求发送到基于云的服务器；以及控制输出门户显示由基于云的服务器响应于请求而传输并由监测器经由网络接口接收的对应数据。在一些实施方式中，心脏泵数据同步器还包括EMR数据更新器，该EMR数据更新器被配置用于添加到EMR系统并在EMR系统内操作，并且控制心脏泵数据同步器还包括利用EMR数据更新器将显示给用户的对应数据的至少一部分作为结构化数据与本地输入的识别符相关联地存储。
附图说明
通过结合附图参考以下具体实施例的详细描述，将更全面地理解本发明，其中：
图1是根据现有技术的心脏泵控制器的前视图。
图2是根据现有技术的用于从如图1中的心脏泵控制器收集操作数据、将数据存储在数据存储装置中并且将数据提供给监测站的基于云的系统的示意性框图。
图3是根据现有技术的由图2的监测站提供的示例性假想显示。
图4是根据本发明的实施例的示例性心脏泵数据同步器的示意性框图。
图5图示了根据本发明的实施例的图4的心脏泵数据同步器的用户接口。
图6图示了根据本发明的另一实施例的图4的心脏泵数据同步器的用户接口。
图7是示意性地图示根据本发明的实施例的由图4的心脏泵数据同步器的心脏泵识别器执行的操作的流程图。
图8是示意性地图示根据本发明的实施例的由图4的心脏泵数据同步器的网络接口执行的操作的流程图。
图9是示意性地图示根据本发明的实施例的由图4的心脏泵数据同步器的数据项目识别器执行的操作的流程图。
图10是示意性地图示根据本发明的实施例的由图4的心脏泵数据同步器的控制器执行的操作的流程图。
图11是示意性地图示根据本发明的实施例的由图4的心脏泵数据同步器的监测器执行的操作的流程图。
图12是示意性地图示根据本发明的实施例的由图4的心脏泵数据同步器的输出门户执行的操作的流程图。
图13是示意性地图示根据本发明的实施例的由图4的心脏泵数据同步器的数据选择器执行的操作的流程图。
图14是示意性地图示根据本发明的实施例的由图4的心脏泵数据同步器的EMR数据更新器执行的操作的流程图。
具体实施方式
本发明的实施例包括心脏泵控制器数据库和EMR系统之间的电子接口。每个心脏泵控制器数据库经由计算机网络连接自动存储来自多个可能地理上分散的心脏泵控制器的时间相关的信息。例如，心脏泵控制器可以分布在多个非附属医院中。
心脏泵控制器数据库随时间存储信息。因此，心脏泵控制器数据库存储关于每个心脏泵及其相关联的控制器的历史和当前信息。心脏泵控制器数据库通常远离心脏泵及其相应控制器所在的医院或其他临床环境。通常，心脏泵控制器数据库由心脏泵制造商操作并位于心脏泵制造商的设施中。
本发明的实施例促进半手动或自动地将数据从心脏泵控制器数据库传送到EMR系统，从而减少或消除护士或技术人员将心脏泵操作数据从心脏泵控制器屏幕手动转录到EMR系统的需要。一些实施例减少或消除了周期性地访视患者以记录操作数据的需要。由于心脏泵控制器数据库存储历史信息，因此接口的实施例促进从心脏泵控制器数据库获得过去的信息并半手动地将过去的信息传送到EMR系统中，从而消除了及时访视每个心脏泵控制器以记录信息的需要。另一实施例一旦被编程就自动周期性地从心脏泵控制器数据库获取操作数据并将其发送到EMR系统，从而消除了周期性地访视每个心脏泵控制器或甚至访问过去的数据以将信息记录在EMR系统中的需要。
每个实施例可以被实施为具有若干能力中的一个或多个能力的软件应用。该应用可以在EMR系统内执行，并且因此可以经由患者房间外部(诸如临床医生的工作站处)的计算机终端可访问，从而消除了访视每个患者房间以记录信息并且因此干扰患者的需要。该应用远程访问心脏泵控制器数据库，并且可以显示关于用户选择的心脏泵的历史数据。
实施例被实施为显示网页的查看器，其中网页显示历史数据。查看器访问心脏泵控制器数据库并显示从其获取的用户选择的数据。因此，在该实施例中，用户可以从过去的所需时间查找数据，读取由查看器显示的数据，并且然后将该数据手动输入到EMR系统中，而不必访视心脏泵控制器以按精确的时间或间隔收集信息。
另一实施例实质上使得用户能够将如上由查看器显示的数据从心脏泵控制器数据库数据存储装置“复制并粘贴”到EMR系统，而不需要用户手动输入数据。由于该实施例提供了用户可以从中复制数据的具体字段，因此每个字段可以与特定的数据项目类型相关联。因此，本实施例对粘贴的数据施加结构，并且粘贴的数据可以作为结构化数据存储在EMR中。
又一实施例一旦被编程就周期性地自动从心脏泵控制器和/或存储在心脏泵控制器数据库中的历史信息中提取数据，根据需要重新格式化数据，并且将数据存储到EMR系统中。重新格式化可以涉及在将数据存储到EMR系统之前对实时或历史数据进行光学字符识别(OCR)。该实施例对粘贴的数据施加结构，并且数据可以作为结构化数据存储在EMR中。
图1图示了包括显示在显示屏104上的示例性操作数据102的示例性心脏泵控制器100，在该案例中是Abiomed Automated Impella控制器。如图2所示，为了促进医疗人员(由人员206和208例示)远程监测心脏泵患者(由患者200、202和204例示)诸如以便确保功效和患者安全，心脏泵控制器(由控制器210、212和214例示)可以经由计算机网络216耦接到一个或多个中央服务器(由服务器218例示)。每个服务器218可以位于心脏泵的制造商和/或心脏泵控制器210-214的制造商处，和/或由心脏泵的制造商和/或心脏泵控制器210-214的制造商操作。
心脏泵控制器210-214经由网络216将操作数据102(图1)发送到服务器218，服务器218将数据存储在时间相关的数据存储装置220中。也就是说，每个数据与指示数据何时被捕获的时间一起存储，或数据以可以计算捕获时间的方式存储。在一些情况下，服务器218经由网络216从心脏泵控制器210-214获取操作数据102，以代替或附加于心脏泵控制器210-214自发地发送数据102(即，不响应于来自服务器218的个体请求)。在任一种情况下，数据存储装置220存储关于心脏泵控制器210-214的历史数据，并且至少隐含地存储关于植入心脏泵的患者200-204的历史数据。
表1列出了可以存储在服务器218的数据存储装置220中并且因此可以由本发明的实施例访问的示例性类型的信息102。任何特定数据存储装置220不一定需要存储表1中列出的所有数据类型，并且一些数据存储装置220可以存储表1中未列出的附加数据类型。
服务器218可经由网络216由监测站(由监测站222和224(图2)例示)访问。每个监测站222-244可以是个人计算机(PC)。可选的web服务器226可以促进由监测站222-224对中央服务器218的访问。因此，监测站222-224可以从数据存储装置220获取，并且在显示屏上显示实时和/或历史操作数据和/或警报以供医疗人员206-208查看。中央服务器218可以包括应用编程接口(API)(未图示)，以促进从数据存储装置220获取数据。
图3是由图2的监测站222-224提供的示例性假想显示300。因此，服务器218提供基于云的系统228(图2)，医疗人员206-208可以通过该基于云的系统228监测患者200-204。在美国专利公开No.2020/0098473以及美国专利申请No.16/370,951、16/365,293、16/360,270和16/458,093中描述了基于云的系统228的一些方面，出于所有目的，这些专利公开和申请的全部内容通过引用并入本文。合适的基于云的系统228能够以商品名Impella远程心脏泵管理系统从Abiomed公司获得。
实施例I
本发明的实施例提供了一种促进人类用户识别存储在数据存储装置220(图2)中的数据的至少一个数据类型和时间或时间范围的心脏泵数据同步器。该实施例从数据存储装置220获得所识别的数据，并且在输出门户上显示数据。护士或技术人员(“用户”)可以观察显示在输出门户上的数据，并且将数据输入到耦接到EMR系统的计算机终端中。有利地，用户不需要访视患者200到204来获得数据。例如，输出门户可以被配置为在位于护理站处的计算机终端上操作。有利地，用户可以获得先前时间段的数据。因此，用户不必需要以规律或及时的间隔访问输出门户。替代地，当用户在其他方面不忙时，用户可以访问输出门户，但是用户能够访问以规定的间隔或时间捕获的数据。
图4是根据本发明的实施例的示例性心脏泵数据同步器400的示意性框图。心脏泵数据同步器400的一个或多个部分可以被配置用于添加到EMR系统402并在EMR系统402内操作。心脏泵数据同步器400为用户提供对存储在数据存储装置220(图2)中的时间相关的数据的访问，并且促进用户将用户指定的数据项目输入到EMR系统402中。
许多EMR系统提供备有证明文件的(documented)应用编程接口(API)以促进将应用(“附加组件(add-ons)”)集成到EMR系统中，因此在EMR系统内执行附加组件应用。这种附加组件应用在本文中被称为被配置用于添加到EMR系统并在EMR系统内操作。类似地，许多EMR系统提供API，以促进附加组件应用获取与所识别的患者相关的数据并将其存储在EMR中。一些EMR系统提供符合一个或多个众所周知的互操作性标准的接口，诸如统一CDA(C-CDA)、国际健康信息交换第七层协议(HL7)和快速医疗保健互操作性资源(FHIR)。FHIR是用于电子地交换医疗保健信息的标准。
心脏泵识别器404被配置用于添加到EMR系统402并在EMR系统402内操作。EMR系统402存储关于多个心脏泵患者200-204和多个非心脏泵患者(由非心脏泵患者230和232(图2)例示)的信息。心脏泵识别器404包括第一用户接口406。图5图示了根据一个实施例的第一用户接口406。第一用户接口406被配置为将第一提示500显示给用户并且在输入字段502中输入本地输入的识别符，诸如心脏泵识别符或患者识别符。心脏泵识别符可以例如包括心脏泵型号或名称、序列号和/或制造商名称等。在一些实施例中，本地输入的识别符是患者识别符，诸如患者识别号，并且第一提示500被适当地修改。如本文所使用的，“本地输入”是指在靠近显示第一提示500的显示设备的输入设备(诸如键盘、触摸屏等)上并且由观察第一用户接口406和第一提示500的用户输入识别符。
返回到图4，网络接口408被配置用于添加到EMR系统402并在EMR系统402内操作。网络接口408被配置为经由广域计算机网络(例如网络216(图2))与基于云的服务器(诸如基于云的系统228的服务器218)通信。通常，基于云的服务器218与EMR系统402不同，并且除此之外缺少与EMR系统402的通信链路。网络接口408可以经由基于云的服务器218所提供的应用编程接口(API)409与基于云的服务器218通信。
如关于图2所讨论的，基于云的服务器218存储关于多个植入的心脏泵210-214的历史时间相关的操作数据。时间相关是指收集数据的时间与数据相关联地存储，或时间可以被计算。因此，可以在基于云的服务器218内选择针对一时间或时间段的数据。
历史操作数据包括针对每个植入的心脏泵210-214的多个数据类型。在图1和图3中示出了数据类型的示例，包括泵类型、血液流速、最小血液流速、最大血液流速、肝素流速、血压和医院名称。也可以使用图1和图3中未示出的其他数据类型。本文关于表1讨论了这种数据的示例。
再次返回到图4，数据项目识别器410被配置用于添加到EMR系统402并在EMR系统402内操作。数据项目识别器410包括第二用户接口412。图5图示了根据一个实施例的第二用户接口412。第二用户接口412被配置为将第二提示503显示给用户。第二用户接口412还被配置为与本地输入的识别符502相关联地从用户输入由基于云的服务器218存储并且可从基于云的服务器218获得的多个数据类型中的至少一个数据类型504的识别。第二用户接口412还被配置为从用户输入时间506(例如，如由开始日期/时间508和结束日期/时间510所指定的)。如果用户仅输入或选择单个日期/时间，则时间506被认为是单个时间点。
数据类型504以及开始和结束时间508-510的各方面可以利用如通过图5中的向下定向的三角形所暗示的下拉列表从用户索取并由用户输入。可以基于可从基于云的服务器218获得的数据类型来填充下拉列表。在一些实施例中，数据项目识别器410向基于云的服务器218查询可以从基于云的服务器218请求的数据类型的列表。可以使用任何其他合适的用户接口图形或文本控制元素或元素的组合，诸如文本框、日历、滑块和/或旋转器。
图5图示了用于选择数据类型的一个数据类型提示503和一个下拉列表504。第二用户接口412的其他实施例(未示出)包括多个下拉列表或其他合适的用户接口图形或文本控制元素或其组合，以促进用户选择多个数据类型。替代地，第二用户接口412可以使用单个下拉504或其他用户接口控件来重复地索取来自用户的数据类型输入，直到用户指示用户已经完成输入数据类型，诸如通过点击“OK”按钮(未示出)。
在使用中，临床医生访问心脏泵识别器的第一用户接口406。临床医生在第一用户接口406中输入心脏泵识别符(诸如心脏泵序列号)或患者识别符(诸如患者识别号)。临床医生输入或选择一个或多个数据类型504和时间506。通过这些输入，临床医生指示哪个心脏泵或患者是感兴趣的。这些输入还指示从连接到心脏泵或感兴趣的患者200-204的心脏泵控制器210-214收集的哪个(哪些)数据类型是感兴趣的。这些输入还指定数据感兴趣所处的单个时间点506或时间跨度506。这些输入引导心脏泵数据同步器400从服务器218获取感兴趣的数据。
控制器414(图4)耦接到心脏泵识别器404、网络接口408和数据项目识别器410。控制器414被配置用于添加到EMR系统402并在EMR系统402内操作。控制器414还被配置为响应于接收到本地输入的识别符502、至少一个数据类型识别504和时间506，经由网络接口408将本地输入的识别符502、至少一个数据类型识别504、时间506、以及对与本地输入的识别502(心脏泵识别符或患者识别符)、(一个或多个)数据类型识别504和时间506相对应的数据的请求416发送到基于云的服务器218。如本文所使用的，“对应数据”或“与其对应的数据”是指关于通过本地输入的识别符502识别的患者和/或心脏泵的数据，其中数据具有由通过(一个或多个)数据类型识别符504识别的(一个或多个)类型，并且数据是在时间506的全部或一部分期间收集的。
监测器418耦接到网络接口406。监测器418被配置用于添加到EMR系统402并在EMR系统402内操作。监测器418被配置为经由网络接口408从基于云的服务器218接收由基于云的服务器218响应于请求416而传输的对应数据420。
输出门户422耦接到监测器418。输出门户422被配置用于添加到EMR系统402并在EMR系统402内操作。输出门户422被配置为诸如在显示屏上将对应数据420显示给用户。例如，输出门户422可以被实施为网页查看器，并且基于云的服务器218可以被配置为提供包含所请求的数据420的HTML格式的网页。
一旦将数据420显示给用户，用户就可以使用常规的EMR用户接口将数据手动输入到EMR系统中，或将数据用于另一目的。然而，如所指出的，手动输入到EMR系统中的数据通常是非结构化数据，并且因此对自动化系统的价值有限。尽管如此，该实施例使得临床医生能够将过去的心脏泵数据输入到EMR系统中，并且在不访视患者的情况下并且因此在不打扰患者的情况下输入该数据。
图7是示意性地图示由心脏泵识别器404执行的操作的流程图。在700处，心脏泵识别器404将第一提示500显示给用户。在702处，心脏泵识别器404输入本地输入的识别符502。如所指出的，本地输入的识别符502可以是心脏泵识别符或具有植入的心脏泵的患者200-204的识别符。
图8是示意性地图示由网络接口408执行的操作的流程图。在800处，网络接口408经由广域计算机网络216与基于云的服务器218通信。
图9是示意性地图示由数据项目识别器404执行的操作的流程图。可选地，在900处，数据项目识别器404向基于云的服务器218查询可用数据类型的列表。该信息可以用于生成第二提示503。在902处，数据项目识别器404将第二提示503显示给用户。在904处，数据项目识别器404输入时间506和多个数据类型中的至少一个数据类型的识别504。由于第一提示500和第二提示503同时或几乎同时显示在同一设备上，并且用户在同一设备上并且几乎同时输入本地输入的识别符502、时间506和至少一个数据类型的识别504，因此时间506和至少一个数据类型的识别504在本文中被称为是与本地输入的识别符502“相关联地”输入的。
图10是示意性地图示由控制器414执行的操作的流程图。在1000处，控制器414等待接收本地输入的识别符502、数据项目识别器410的至少一个数据类型识别504和时间506。在1002处，响应于接收到这些项目，控制器414将本地输入的识别符502、至少一个数据类型识别504和时间506发送到基于云的服务器218。在1004处，控制器414将对对应数据的请求416发送到基于云的服务器218。
图11是示意性地图示由监测器418执行的操作的流程图。在1100处，监测器418接收由基于云的服务器218响应于请求416而传输的对应数据420。本文描述了监测器418的附加操作。
图12是示意性地图示由输出门户422执行的操作的流程图。在1200处，输出门户422将从基于云的服务器218接收的对应数据420显示给用户。
实施例II
在另一实施例中，图形用户接口(GUI)使得用户能够以图形方式识别感兴趣的数据，诸如通过将鼠标光标拖过显示的数据，并且系统从数据存储装置220获取所识别的数据，并且然后将所选择的数据存储在EMR系统402中。本质上，该实施例使得用户能够将数据从数据存储装置220“复制并粘贴”到EMR系统402，而不需要用户手动输入数据。在一些实施例中，数据作为结构化数据存储在EMR系统402中。
在这样的实施例中，心脏泵数据同步器400(图4)包括数据选择器424。数据选择器424被配置用于添加到EMR系统402并在EMR系统402内操作。数据选择器424包括被配置为将第三提示显示给用户的第三用户接口426。数据选择器424还被配置为从用户输入识别显示给用户的对应数据的至少一部分的指示。如关于用户接口504所讨论的，可以使用任何合适的用户接口图形控制元素或元素的组合。
图5图示了数据选择器424、第三用户接口426和第三提示512的实施例。在该实施例中，复选框426或另一合适的图形或文本元素使得用户能够选择经由数据类型选择器504指示或选择的数据类型。具有多个数据类型选择器504的实施例可以具有等于数据类型选择器504的数量的复选框426的数量。
图6图示了第三用户接口426的另一实施例。在该实施例中，在用户使用第二用户接口412选择(一个或多个)数据类型之后，例如，如参考图5所讨论的，数据选择器424显示第三提示512和由基于云的服务器218返回的数据，例如每行一个数据类型，如图6所示。由复选框600和602表示的复选框使得用户能够选择数据项目中的一些数据项目。
替代地，在一些实施例中，数据选择器424显示光标(未示出)，并且用户将光标拖过显示的(一个或多个)数据项目以指示对应数据的至少一部分的识别。数据选择器424可以使拖过的数据显示为不同的颜色，以突出显示选择。
心脏泵数据同步器400还可以包括EMR数据更新器428(图4)。EMR数据更新器428可以被配置用于添加到EMR系统402并且在EMR系统402内操作。EMR数据更新器428可以被配置为将显示给用户或由用户选择的对应数据的至少一部分存储在EMR系统402中。换句话说，EMR数据更新器428可以被配置为将由用户选择的数据存储在EMR系统402中。
由于由基于云的服务器218返回的数据项目均源自数据存储装置220中的命名字段，因此如果用户选择了任何显示的数据类型，则字段名称可以用于识别存储在EMR系统中的数据的类型。也就是说，数据可以作为结构化数据存储在EMR系统中。
在任何情况下，由用户选择的数据与患者识别符相关联地存储在EMR系统中。如果本地输入的识别符502是患者识别符，则EMR数据更新器428可以使用本地输入的识别符502作为密钥/关键字(key)来指定EMR系统402中的患者记录，因此由EMR数据更新器428存储的数据与患者识别符相关联地存储在EMR系统402中。
存储在EMR系统402中的数据与患者相关。可选地，为了使用户免于输入患者识别符，心脏泵识别可以用于推断患者识别。通常，历史数据存储装置220中的数据包括心脏泵识别信息，诸如型号识别和序列号。此外，历史数据存储装置220通常与植入的心脏泵相关联地存储患者姓名或其他患者识别符。因此，心脏泵数据同步器400可以使用本地输入的心脏泵识别符502(图5)来查找与该心脏泵相关联的患者的识别。然后，心脏泵数据同步器400可以使用推断出的患者识别符将数据与正确的患者相关联地存储在EMR系统中。可以类似地使用自动推断的心脏泵识别符，诸如通过扫描或拍摄心脏泵而读取的那些识别符。
也就是说，如果本地输入的识别符502是心脏泵识别符，则由基于云的服务器218存储的数据可以包括针对每个心脏泵识别符的患者识别符。在这种情况下，基于云的服务器218发送患者识别符以及所请求的数据项目，并且EMR数据更新器428可以使用由基于云的服务器218发送的患者识别符作为密钥/关键字来指定EMR系统402中的患者记录，因此由EMR数据更新器428存储的数据与患者识别符相关联地存储在EMR系统402中。
可选地，每个植入的心脏泵可以机械地耦接到包括显示屏104(图1)的相应心脏泵控制器200-204。植入的心脏泵的操作数据102可以显示在显示屏104上。每个心脏泵控制器200-204可以被配置为向基于云的服务器218发送表示显示屏104的内容的相应视频流。
由基于云的服务器218存储的历史时间相关的操作数据可以至少部分地由基于云的服务器218从来自相应心脏泵控制器200-204的相应视频流导出。例如，每个视频流可以表示心脏泵控制器200-204的屏幕104的内容。由监测器418从基于云的服务器218接收的对应数据420可以是非视频数据。例如，对应数据420可以是包含直接表示对应数据420项目(诸如血压)的数字的网络分组的形式。
输出门户422可以包括被配置为从对应数据420至少部分地重新创建视频流从而将对应数据420显示给用户的视频信号合成器430。本质上，视频信号合成器430创建心脏泵控制器200-204的显示屏104的至少一部分的副本。通过该机制，用户可以在不进入患者房间的情况下基本上几乎实时地看到心脏泵控制器200-204的显示屏102或显示屏102的至少一部分。
本地输入的心脏泵识别符502可以包括相应植入的心脏泵的序列号。心脏泵数据同步器400还可以包括扫描仪432，该扫描仪432被配置为读取表示心脏泵识别符的条形码从而提供本地输入的心脏泵识别符502。条形码(包括快速响应(QR)码)是包含关于它所附接的项目的信息的机器可读光学标签。在这样的实施例中，用户不需要手动输入心脏泵识别符。由于这些识别符可以是长的和/或任意的，因此消除人类手动输入识别符的需要降低了错误的可能性。扫描仪432可以无线通信地耦接到心脏泵识别器404。
心脏泵数据同步器400可以包括相机434，该相机434被配置为读取表示心脏泵识别符的标记从而提供本地输入的心脏泵识别符。标记可以是文本或条形码。相机434可以是移动电话的相机。光学字符识别(OCR)软件可以用于处理由相机434产生的图像，以导出本地输入的心脏泵识别符。相机434可以降低输入本地输入的心脏泵识别符的人为错误的可能性。相机434可以无线通信地耦接到心脏泵识别器404。
网络接口408可以被配置为经由基于云的服务器218所提供的应用编程接口(API)与基于云的服务器218通信。如在维基百科中所指出的，应用编程接口(API)是定义其他部件或系统可以如何使用它的到软件部件或系统的计算接口。API定义了可以进行的调用或请求的种类、如何进行调用或请求、应当使用的数据格式、要遵循的约定等。一些API必须备有证明文件(documented)，而其他API被设计成使得它们可以被“询问”以确定所支持的功能。由于其他部件/系统仅依赖于API，因此提供API的系统可以(理想地)在该API“背后”改变其内部细节而不影响其用户。
图13是示意性地图示由数据选择器424执行的操作的流程图。在1300处，数据选择器424将第三提示512显示给用户。在1302处，数据选择器424输入选择显示给用户的对应数据的至少一部分的指示426或600。
图14是示意性地图示由EMR数据更新器428执行的操作的流程图。在1400处，如果本地输入的识别符502是患者识别符，则控制转到1402，其中本地输入的识别符502/患者识别符用作索引到EMR系统402中的密钥/关键字。可选地，如果本地输入的识别符502是心脏泵识别符，则控制转到1404。在1404处，本地输入的识别符502/泵识别符用于在基于云的服务器218中查找对应的患者识别符。例如，EMR数据更新器428可以将心脏泵识别符发送到基于云的服务器218，并且请求在数据存储装置220中与心脏泵识别符相关联的患者的识别。替代地，监测器418被配置为经由网络接口408从基于云的服务器218接收与由基于云的服务器218响应于请求而传输的数据相对应患者识别符，如本文所讨论的。
在1406处，EMR数据更新器428将所选择的数据存储在EMR系统402中。在一些实施例中，如在1408处指示的，所选择的数据作为结构化数据存储在EMR系统402中。在任何情况下，如在1402或1404处确定的，所选择的数据与患者识别符相关联地存储在EMR系统402中。
如所指出的，图11是示意性地图示由监测器418执行的操作的流程图。可选地，在1102处，监测器418从基于云的服务器218接收与由基于云的服务器218响应于请求416而传输的数据420相对应的患者识别符。该患者识别符可以由EMR数据更新器428用作EMR系统402的密钥/关键字。
如所指出的，图12是示意性地图示由输出门户422执行的操作的流程图。每个植入的心脏泵机械地耦接到包括显示屏的相应心脏泵控制器210-214，在显示屏上显示植入的心脏泵的操作数据。每个心脏泵控制器210-214可以被配置为向基于云的服务器218发送表示显示屏的内容的相应视频流。由基于云的服务器218存储的历史时间相关的操作数据可以至少部分地由基于云的服务器218从来自相应心脏泵控制器210-214的相应视频流导出。由监测器418从基于云的服务器218接收的对应数据420可以是非视频数据。可选地，在1202处，视频信号合成器430从对应数据420至少部分地重新创建视频流，从而将对应数据420显示给用户。
实施例III
一旦被编程，第三实施例周期性地自动从心脏泵控制器200-204和/或历史数据库220获取数据，根据需要重新格式化数据，并且将数据存储到EMR系统402中。重新格式化可以涉及在将数据存储到EMR系统402中之前对来自心脏泵控制器210-214的实时数据或来自数据存储装置220的历史数据进行光学字符识别(OCR)。数据可以作为结构化数据存储在EMR系统402中。
类似于本文所述的开始时间508和结束时间510(图5)的用户接口可以用于从用户索取和接受系统周期性地从心脏泵控制器200-204或数据存储装置220自动获取数据并将数据自动存储在EMR系统402中的时间框架(time frame)。可以使用类似的用户接口来索取和接受要获取数据的频率或连续获取之间的时段。可以利用类似于本文参考图4、图5和图6描述的用户接口504和426的用户接口来索取和接受要提取和存储的数据类型。
该实施例包括心脏泵识别器404、网络接口408、数据项目识别器410、控制器414、监测器418和EMR数据更新器428，如本文所述。
然而，数据项目识别器410的用户接口412还被配置为与至少一个数据类型的识别相关联地从用户输入更新间隔。图5示出了用于接收更新间隔的用户输入的示例性提示和输入字段514。控制器414还被配置为响应于接收到更新间隔514而经由网络接口以更新间隔从基于云的服务器218自动请求更新的对应数据。EMR数据更新器428还被配置为将由监测器418接收的更新的对应数据420作为结构化数据与患者相关联地自动存储在EMR系统402中。
如所指出的，图9是示意性地图示由数据项目识别器410执行的操作的流程图。在906处，数据项目识别器410输入更新间隔514。
如所指出的，图10是示意性地图示由控制器414执行的操作的流程图。虚线箭头1006表示由其他部件(诸如监测器418和EMR数据更新器428)执行的操作。在1008处，在更新间隔已经到期之后，控制返回到1004，并且控制器414经由网络接口从基于云的服务器218重复地自动请求更新的对应数据。如通过虚线箭头1006所指示的，监测器418接收(操作1100，图11)由基于云的服务器218响应于请求416而传输的对应数据420，并且EMR数据更新器428将更新的对应数据420自动存储(操作1406，图14)在EMR系统402中。
虽然通过上述示例性实施例描述了本发明，但是在不脱离本文公开的发明构思的情况下可以对所示出的实施例进行修改和变化。例如，虽然可以与公开的实施例相关地记载具体参数值，但是在本发明的范围内，所有参数的值可以在宽范围内变化以适应不同的应用。除非上下文中另有指示或者将被本领域普通技术人员理解，否则诸如“大约”之类的术语表示在±20％以内。
如本文所用，包括在权利要求书中，与项目列表结合使用的术语“和/或”意味着列表中的项目中的一个或多个，即列表中的项目中的至少一个，但不一定是列表中的所有项目。如本文所用，包括在权利要求书中，与项目列表结合使用的术语“或”意味着列表中的项目中的一个或多个，即列表中的项目中的至少一个，但不一定是列表中的所有项目。“或”并不意味着“排他的或”。
虽然可以参考流程图和/或框图来描述实施例的各个方面，但每个框或框的组合的全部或一部分的功能、操作、决定等可以被组合、分离成独立的操作或以其他顺序执行。对“模块”或“步骤”的引用是为了方便起见，并不旨在限制其实施方式。每个框、模块或其组合的全部或一部分可以被实施为计算机程序指令(例如软件)、硬件(例如组合逻辑、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、处理器或其他硬件)、固件或其组合。
心脏泵数据同步器400或其部分可以由一个或多个处理器实施，该处理器执行存储在存储器中的指令或由存储在存储器中的指令控制。每个处理器可以是通用处理器，诸如中央处理单元(CPU)、图形处理单元(GPU)、数字信号处理器(DSP)、专用处理器等，视情况而定，或其组合。
存储器可以是随机存取存储器(RAM)、只读存储器(ROM)、闪存或适用于存储控制软件或其他指令和数据的任何其他存储器，或其组合。定义本发明的功能的指令可以以多种形式被输送到处理器，包括但不限于永久存储在有形非暂时性不可写存储介质(例如，计算机内的只读存储器设备(诸如ROM)或计算机I/O附件可读的设备(诸如CD-ROM或DVD磁盘))上的信息，被可更改地存储在有形非暂时性可写存储介质(例如软盘、可移除闪存和硬盘驱动器)上的信息，或通过通信介质(包括有线或无线计算机网络)递送到计算机的信息。此外，虽然可以结合各种说明性数据结构来描述实施例，但可以使用各种数据结构来体现系统。
所公开的方面或其部分可以以上文未列出和/或未明确声明的方式进行组合。此外，本文公开的实施例可以在缺少本文没有具体公开的任何元素的情况下被适当地实践。因此，本发明不应被视为局限于所公开的实施例。
如本文所用，诸如“第一”、“第二”和“第三”的数字术语用于将相应提示彼此区分开，并且不旨在必然指示任何特定实施例中的提示的任何特定顺序或总数。因此，例如，给定的实施例可以仅包括第二提示和第三提示。

Claims (20)

1.一种用于时间相关的数据的心脏泵数据同步器，所述同步器包括：
心脏泵识别器，所述心脏泵识别器被配置用于添加到电子医疗记录系统即EMR系统并在所述EMR系统内操作，所述EMR系统能够根据患者识别符访问，并且所述EMR系统存储关于多个心脏泵患者和多个非心脏泵患者的信息，所述心脏泵识别器包括第一用户接口，所述第一用户接口被配置为将针对(a)心脏泵或(b)具有植入的心脏泵的患者中的至少一个的本地输入的识别符的第一提示显示给用户；
网络接口，所述网络接口被配置用于添加到所述EMR系统并在所述EMR系统内操作，并且经由广域计算机网络与基于云的服务器通信，所述基于云的服务器不同于所述EMR系统并且除此以外缺少与所述EMR系统的通信链路，其中所述基于云的服务器存储关于多个植入的心脏泵的历史时间相关的操作数据，所述历史操作数据包括针对每个植入的心脏泵的多个数据类型；
数据项目识别器，所述数据项目识别器被配置用于添加到所述EMR系统并在所述EMR系统内操作，所述数据项目识别器包括第二用户接口，所述第二用户接口被配置为将针对时间和所述多个数据类型中的至少一个数据类型的识别的第二提示显示给所述用户，所述时间和所述至少一个数据类型识别与所述本地输入的识别符相关联；
控制器，所述控制器通信地耦接到所述心脏泵识别器、所述网络接口和所述数据项目识别器，所述控制器被配置用于添加到所述EMR系统并在所述EMR系统内操作，所述控制器还被配置为响应于接收到所述本地输入的识别符、所述时间和所述至少一个数据类型识别而经由所述网络接口将所述本地输入的识别符、所述时间、所述至少一个数据类型识别和对与其对应的数据的请求发送到所述基于云的服务器；
监测器，所述监测器通信地耦接到所述网络接口，并且被配置用于添加到所述EMR系统并在所述EMR系统内操作，所述监测器被配置为经由所述网络接口从所述基于云的服务器接收由所述基于云的服务器响应于所述请求而传输的对应数据；以及
输出门户，所述输出门户通信地耦接到所述监测器，并且被配置用于添加到所述EMR系统并在所述EMR系统内操作，所述输出门户被配置为将从所述基于云的服务器接收的所述对应数据显示给所述用户。
2.根据权利要求1所述的心脏泵数据同步器，还包括：
数据选择器，所述数据选择器被配置用于添加到所述EMR系统并在所述EMR系统内操作，所述数据选择器包括第三用户接口，所述第三用户接口被配置为将针对选择显示给所述用户的对应数据的至少一部分的指示的第三提示显示给所述用户；以及
EMR数据更新器，所述EMR数据更新器被配置用于添加到所述EMR系统并在所述EMR系统内操作，并且将显示给所述用户的对应数据的所选择的至少一部分作为结构化数据与患者识别符相关联地存储在所述EMR系统中。
3.根据权利要求2所述的心脏泵数据同步器，其中：
所述监测器被配置为经由所述网络接口从所述基于云的服务器接收与由所述基于云的服务器响应于所述请求而传输的所述数据相对应的患者识别符；并且
所述EMR数据更新器被配置为将所述对应数据的所选择的至少一部分与由所述监测器接收的所述患者识别符相关联地存储在所述EMR系统中。
4.根据权利要求2所述的心脏泵数据同步器，其中：
所述本地输入的识别符包括患者识别符；并且
所述EMR数据更新器被配置为将所述对应数据的所选择的至少一部分与所述本地输入的识别符相关联地存储在所述EMR系统中。
5.根据权利要求1至4中的任一项所述的心脏泵数据同步器，其中：
每个植入的心脏泵机械地耦接到包括显示屏的相应心脏泵控制器，在所述显示屏上显示所述植入的心脏泵的操作数据，并且每个心脏泵控制器被配置为向所述基于云的服务器发送表示所述显示屏的内容的相应视频流；
由所述基于云的服务器存储的所述历史时间相关的操作数据至少部分地由所述基于云的服务器从来自相应心脏泵控制器的相应视频流导出；
由所述监测器从所述基于云的服务器接收的所述对应数据是非视频数据；并且
所述输出门户包括视频信号合成器，所述视频信号合成器被配置为从所述对应数据至少部分地重新创建视频流，从而将所述对应数据显示给所述用户。
6.根据权利要求1至5中的一项所述的心脏泵数据同步器，其中所述本地输入的识别符包括相应植入的心脏泵的序列号。
7.根据权利要求1至6中的一项所述的心脏泵数据同步器，其中所述本地输入的识别符包括患者识别符。
8.根据权利要求1至7中的一项所述的心脏泵数据同步器，还包括扫描仪，所述扫描仪被配置为读取表示心脏泵识别符的条形码并提供所述心脏泵识别符作为所述本地输入的识别符。
9.根据权利要求8所述的心脏泵数据同步器，其中所述扫描仪无线通信地耦接到所述心脏泵识别器。
10.根据权利要求1至9中的一项所述的心脏泵数据同步器，还包括相机，所述相机被配置为读取表示心脏泵识别符的标记并提供所述心脏泵识别符作为所述本地输入的识别符。
11.根据权利要求10所述的心脏泵数据同步器，其中所述相机无线通信地耦接到所述心脏泵识别器。
12.根据权利要求1至11中的一项所述的心脏泵数据同步器，其中所述网络接口被配置为经由所述基于云的服务器所提供的应用编程接口即API与所述基于云的服务器通信。
13.根据权利要求1至12中的一项所述的心脏泵数据同步器，其中所述历史操作数据包括以下中的至少一个：由血泵测量的血压、血泵马达速度、血泵马达电流、血泵的肝素输注速率或血泵吹扫信息。
14.一种用于时间相关的数据的心脏泵数据同步器，所述同步器包括：
心脏泵识别器，所述心脏泵识别器被配置用于添加到电子医疗记录系统即EMR系统并在所述EMR系统内操作，所述EMR系统能够根据患者识别符访问，并且所述EMR系统存储关于多个心脏泵患者和多个非心脏泵患者的信息，所述心脏泵识别器包括被配置为将针对(a)心脏泵或(b)具有植入的心脏泵的患者中的至少一个的本地输入的识别符的第一提示显示给用户的用户接口；
网络接口，所述网络接口被配置用于添加到所述EMR系统并在所述EMR系统内操作，并且经由广域计算机网络与基于云的服务器通信，所述基于云的服务器不同于所述EMR系统并且除此之外缺少与所述EMR系统的通信链路，其中所述基于云的服务器存储关于多个植入的心脏泵的时间相关的操作数据，所述操作数据包括针对每个植入的心脏泵的多个数据类型；
数据项目识别器，所述数据项目识别器被配置用于添加到所述EMR系统并在所述EMR系统内操作，所述数据项目识别器包括被配置为将针对所述多个数据类型中的至少一个数据类型的识别的第二提示显示给所述用户的用户接口，所述至少一个数据类型识别与所述本地输入的识别符相关联；
控制器，所述控制器通信地耦接到所述心脏泵识别器、所述网络接口和所述数据项目识别器，并且被配置用于添加到所述EMR系统并在所述EMR系统内操作，所述控制器还被配置为响应于接收到所述本地输入的识别符和所述至少一个数据类型识别而经由所述网络接口将所述本地输入的识别符、所述至少一个数据类型识别和对与其对应的数据的请求发送到所述基于云的服务器；
监测器，所述监测器通信地耦接到所述网络接口，并且被配置用于添加到所述EMR系统并在所述EMR系统内操作，所述监测器被配置为经由所述网络接口从所述基于云的服务器接收由所述基于云的服务器响应于所述请求而传输的对应数据；以及
EMR数据更新器，所述EMR数据更新器被配置用于添加到所述EMR系统并在所述EMR系统内操作，并且将由所述监测器接收的对应数据作为结构化数据与患者相关联地自动存储在所述EMR系统中，所述患者与所述本地输入的识别符相关联。
15.根据权利要求14所述的心脏泵数据同步器，其中所述多个数据类型包括以下中的至少两个：由血泵测量的血压、血泵马达速度、血泵马达电流、血泵的肝素输注速率或血泵吹扫信息。
16.根据权利要求14和15中的一项所述的心脏泵数据同步器，其中：
所述数据项目识别器的所述用户接口还被配置为与所述至少一个数据类型的所述识别相关联地从所述用户输入更新间隔；
所述控制器还被配置为响应于接收到所述更新间隔而经由所述网络接口以所述更新间隔从所述基于云的服务器自动请求更新的对应数据；并且
所述EMR数据更新器还被配置为将由所述监测器接收的所述更新的对应数据作为结构化数据与所述患者相关联地自动存储在所述EMR系统中。
17.一种用于控制心脏泵数据同步器的方法，其中：
所述心脏泵数据同步器包括心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户，所述心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户的每一个被配置用于添加到电子医疗记录系统即EMR系统并在所述EMR系统内操作，所述EMR系统能够根据患者识别符访问并且存储关于多个心脏泵患者和多个非心脏泵患者的信息；
所述网络接口被配置为经由广域计算机网络与基于云的服务器通信，所述基于云的服务器不同于所述EMR系统并且除此之外缺少与所述EMR系统的通信链路，并且所述基于云的服务器存储关于多个植入的心脏泵的历史时间相关的操作数据，所述历史操作数据包括针对每个植入的心脏泵的多个数据类型；并且
所述方法包括：
利用所述心脏泵识别器的第一用户接口将针对(a)心脏泵或(b)具有植入的心脏泵的患者中的至少一个的本地输入的识别符的第一提示显示给用户；
利用所述数据项目识别器的第二用户接口将针对时间和所述多个数据类型中的至少一个数据类型的识别的第二提示显示给所述用户，所述时间和所述至少一个数据类型识别与所述本地输入的识别符相关联；
利用所述控制器经由所述网络接口将所述本地输入的识别符、所述时间、所述至少一个数据类型识别和对与其对应的数据的请求发送到所述基于云的服务器；
利用所述监测器经由所述网络接口接收由所述基于云的服务器响应于所述请求而传输的对应数据；以及
利用所述输出门户将所述对应数据显示给所述用户。
18.根据权利要求17所述的方法，其中：
所述心脏泵数据同步器还包括EMR数据更新器，所述EMR数据更新器被配置用于添加到所述EMR系统并在所述EMR系统内操作；并且
所述方法还包括利用所述EMR数据更新器将显示给所述用户的对应数据的至少一部分作为结构化数据与所述本地输入的识别符相关联地存储。
19.一种其上存储有指令的非暂时性计算机可读存储介质，所述指令在由一个或多个处理器执行时使所述一个或多个处理器控制心脏泵数据同步器，其中：
所述心脏泵数据同步器包括心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户，所述心脏泵识别器、网络接口、数据项目识别器、控制器、监测器和输出门户的每一个被配置用于添加到电子医疗记录系统即EMR系统并在所述EMR系统内操作，所述EMR系统能够根据患者识别符访问并且存储关于多个心脏泵患者和多个非心脏泵患者的信息；
所述网络接口被配置为经由广域计算机网络与基于云的服务器通信，所述基于云的服务器不同于所述EMR系统并且除此之外缺少与所述EMR系统的通信链路，并且所述基于云的服务器存储关于多个植入的心脏泵的历史时间相关的操作数据，所述历史操作数据包括针对每个植入的心脏泵的多个数据类型；并且
控制所述心脏泵数据同步器包括：
控制所述心脏泵识别器的第一用户接口将针对(a)心脏泵或(b)具有植入的心脏泵的患者中的至少一个的本地输入的识别符的第一提示显示给用户；
控制所述数据项目识别器的第二用户接口将针对时间和所述多个数据类型中的至少一个数据类型的识别的第二提示显示给所述用户，所述时间和所述至少一个数据类型识别与所述本地输入的识别符相关联；
经由所述网络接口将所述本地输入的识别符、所述时间、所述至少一个数据类型识别和对与其对应的数据的请求发送到所述基于云的服务器；以及
控制所述输出门户显示由所述基于云的服务器响应于所述请求而传输并由所述监测器经由所述网络接口接收的对应数据。
20.根据权利要求19所述的非暂时性计算机可读存储介质，其中：
所述心脏泵数据同步器还包括EMR数据更新器，所述EMR数据更新器被配置用于添加到所述EMR系统并在所述EMR系统内操作；并且
控制所述心脏泵数据同步器还包括控制所述EMR数据更新器将显示给所述用户的对应数据的至少一部分作为结构化数据与所述本地输入的识别符相关联地存储。
CN202280043557.6A 2021-06-30 2022-06-28 心脏泵控制器数据库与医院之间的接口 Pending CN117581311A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202163216931P 2021-06-30 2021-06-30
US63/216,931 2021-06-30
PCT/US2022/035277 WO2023278413A1 (en) 2021-06-30 2022-06-28 Interface between heart pump controller database and hospital

Publications (1)

Publication Number Publication Date
CN117581311A true CN117581311A (zh) 2024-02-20

Family

ID=82742962

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280043557.6A Pending CN117581311A (zh) 2021-06-30 2022-06-28 心脏泵控制器数据库与医院之间的接口

Country Status (10)

Country Link
US (1) US20230011929A1 (zh)
EP (1) EP4364164A1 (zh)
KR (1) KR20240024080A (zh)
CN (1) CN117581311A (zh)
AU (1) AU2022301171A1 (zh)
CA (1) CA3221665A1 (zh)
DE (1) DE112022003325T5 (zh)
IL (1) IL309280A (zh)
TW (1) TW202313140A (zh)
WO (1) WO2023278413A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117524455B (zh) * 2024-01-05 2024-03-22 苏州同心医疗科技股份有限公司 植入式左心室辅助装置的智能化信息管理方法及其装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130317852A1 (en) * 2012-05-22 2013-11-28 Geneva Healthcare, LLC Medical device information portal
US11120908B2 (en) 2018-09-20 2021-09-14 Abiomed, Inc. Data storage and retrieval system for non-contiguous medical device operational data
US20200312450A1 (en) * 2019-03-30 2020-10-01 Abiomed, Inc. Medical Device Location and Tracking System
US11527322B2 (en) * 2019-06-30 2022-12-13 Abiomed, Inc. Context-based user interface to medical database

Also Published As

Publication number Publication date
CA3221665A1 (en) 2023-01-05
EP4364164A1 (en) 2024-05-08
IL309280A (en) 2024-02-01
KR20240024080A (ko) 2024-02-23
DE112022003325T5 (de) 2024-04-25
US20230011929A1 (en) 2023-01-12
WO2023278413A1 (en) 2023-01-05
AU2022301171A1 (en) 2023-12-14
TW202313140A (zh) 2023-04-01

Similar Documents

Publication Publication Date Title
US10332629B2 (en) Central station integration of patient data
JP2004243126A (ja) 患者医療パラメータユーザインターフェースシステム
US20170300649A1 (en) Systems, Methods, User Interfaces and Analysis Tools for Supporting User-Definable Rules and Smart Rules and Smart Alerts Notification Engine
US20180286500A1 (en) System for acquisition, processing and visualization of clinical data of patients
JP5834042B2 (ja) 診療情報表示制御装置および診療情報表示制御方法並びに診療情報表示制御プログラム
WO2006065374A1 (en) A graphical medical data acquisition system
US20080004818A1 (en) System for Monitoring and Managing Patient Fluid Input and Output
CN1650315A (zh) 用于自适应地提供患者医疗参数的趋势指示显示的系统和用户界面
WO2017192673A1 (en) Graphical user interfaces recommending care
EP2856370A1 (en) Systems and methods for organizing, storing, communicating, and verifying information throughout the process of providing healthcare services
CN117581311A (zh) 心脏泵控制器数据库与医院之间的接口
AU2022231758A1 (en) Medical care assistance device, and operation method and operation program therefor
US20140012597A1 (en) Automatically populating a whiteboard with aggregate data
US20170329919A1 (en) Personalized user interfaces presenting care tasks
JP6223810B2 (ja) 血糖管理支援装置、システム、方法及びプログラム
CN108122604A (zh) 用于图像采集工作流的方法和系统
JP6558678B2 (ja) 処方薬管理装置、処方薬管理方法、および、処方薬管理プログラム
KR102382541B1 (ko) 고객 정보를 처리하는 방법 및 디바이스
US20210098094A1 (en) Automatic patient record updating
JP2003044587A (ja) 医療リスクマネージメントシステム及びその制御方法、プログラム記憶媒体
CN114220529A (zh) 一种医院科室快速登记系统及登记方法
JP2017016254A (ja) 検査結果画面表示プログラム、検査結果画面表示装置および検査結果画面表示方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication