CN116095624B

CN116095624B - Heart monitor data acquisition system

Info

Publication number: CN116095624B
Application number: CN202310380749.2A
Authority: CN
Inventors: 吴贤珺; 闫捷; 唐文政; 马印; 程龙飞; 李永发; 常丰森; 张佳俊; 陈陆陆
Original assignee: Suzhou Wushuang Medical Equipment Co ltd
Current assignee: Suzhou Wushuang Medical Equipment Co ltd
Priority date: 2023-04-11
Filing date: 2023-04-11
Publication date: 2023-06-13
Anticipated expiration: 2043-04-11
Also published as: CN116095624A

Abstract

The application belongs to the field of medical equipment, and discloses a heart monitor data acquisition system. The method comprises the steps that a Bluetooth gateway and an MQTT data transmission protocol are used, a heart monitor monitors electrocardiosignals and sends Bluetooth messages in a subpackage mode, and the Bluetooth messages contain electrocardiosignal data; the payload data in the Bluetooth message comprises a private message, wherein the private message comprises a data type, a check code and a batch packet number of the Bluetooth message; the Bluetooth gateway receives the Bluetooth message, converts the private message into an MQTT private message and sends the MQTT private message to the Internet; the cloud server receives the MQTT private message sent by the Internet; the cloud server further comprises a consumption task, wherein the consumption task checks the private message according to the data type and the check code of the private message, and returns a check result. Patient compliance problems are solved with the present application relative to the prior art.

Description

Heart monitor data acquisition system

Technical Field

The present application is in the field of medical devices, and in particular relates to improvements in cardiac monitor telecommunication technology.

Background

The cardiac monitor includes an implantable cardiac monitor and a non-implantable cardiac monitor.

Taking an implantable cardiac monitor as an example, an implantable cardiac monitor (Implantable Cardiac Monitor, abbreviated as ICM) is a medical device that is implanted in a patient's chest to enable long-term monitoring of cardiac electrical signals and cardiac rhythms.

ICM can be used to monitor symptoms such as abnormal cardiac rhythms, syncopes, tachycardia and bradycardia, atrial fibrillation, etc. ICM can continuously monitor heart activity in the patient's daily life so that doctors can timely discover heart problems and treat them.

Compared with the traditional heart monitoring equipment, the ICM has the advantages of small volume, low power consumption, wireless data transmission and the like, and a patient can conveniently carry the ICM and monitor the ICM at any time and any place without hospitalization.

Typically, an implantable cardiac monitor continuously monitors patient cardiac electrical signals and stores cardiac electrical signals corresponding to abnormal rhythms. In order to reduce power consumption and reduce the volume of the device, the memory of the memory for storing the electrocardiosignals is small, which is a cycle recorder, and when the memory data is full, new memory data can overwrite the earliest slave memory data.

Meanwhile, the ICM needs to synchronize abnormal data to the cloud server, the cloud server further analyzes and records the data, and meanwhile, a doctor at the far end can check electrocardiographic data uploaded by the ICM through a terminal connected with the cloud server, so that remote diagnosis is realized.

ICM is not able to communicate directly with a server due to its power consumption and size limitations, and it needs to be relayed through networking equipment. In the prior art, the communication data is connected with the ICM through Bluetooth communication through a handheld device (such as a smart phone), and the communication data is uploaded to a cloud server through the handheld device. However, this method requires manual operation by the patient, and is relatively cumbersome in terms of steps, and the patient may be reluctant to upload data frequently, resulting in poor patient compliance. At the same time, the patient may forget to make the data transmission less synchronous, and the data transmission is lost.

In the prior art, a combination of a Bluetooth gateway and MQTT technology is generally used as a means for identifying the Internet of things and communicating with the cloud. The data transmission can be automatically completed without user intervention. However, the technical stacks of the MQTT and the Bluetooth gateway are not directly applicable to the electrocardio monitoring equipment such as ICM and the like.

This is due to two key problems:

firstly, the problem of data real-time verification: the amount of electrocardiographic data stored in the ICM is large (several megabytes to several hundred megabytes per hour), and large data needs to be transmitted in packets because of the limitation of the size of the data packet transmitted each time by bluetooth low energy. The MQTT protocol is a lightweight communication protocol based on a publish/subscribe mode, and the sequency of transmission of a large data after packetization is not guaranteed, so the sequence of receiving the data may be out of order. For example, the data private messages sent in the order of 1, 2 and 3 are sent out, and the data private messages received in the order of 1, 3 and 2 are received. Meanwhile, packet loss is caused by sub-packaging. For example, the number of packets is 10, but only 9 packets reach the cloud. Meanwhile, data errors may occur due to network attacks and the like.

Secondly, the problem that the Bluetooth gateway automatically registers to background service: because the universal Bluetooth gateway has no control logic, a background service is needed to control the Bluetooth gateway, and full-automatic data collection is realized. It is therefore desirable that the bluetooth gateway be able to automatically register with the background service after power-on networking so that the background service can trigger automatic collection of data through the bluetooth gateway.

Therefore, when the combination of the Bluetooth gateway and the MQTT technology is applied to the ICM, the received data needs to be reordered and checked, and as the data transmission and response processes are real-time, the data checking problem needs to be solved in real time; automatic registration of the bluetooth gateway is also required.

Disclosure of Invention

The invention aims to provide a heart monitor data acquisition system realized by a Bluetooth gateway and an MQTT protocol technical stack. It has high patient compliance, and it can be automatic with data upload to high in the clouds server, need not the patient and operates. On the other hand, the problem of data verification of the Bluetooth gateway and the MQTT protocol technical stack is solved, and the problem of automatic registration of the Bluetooth gateway to background service is solved in the third aspect.

Specifically, the cardiac monitor data acquisition system of the present application comprises:

the heart monitor monitors electrocardiosignals and sends Bluetooth messages in a subpackage mode, wherein the Bluetooth messages comprise electrocardiosignal data;

the payload data in the Bluetooth message comprises a private message, wherein the private message comprises a data type, a check code and a batch packet number of the Bluetooth message;

the Bluetooth gateway receives the Bluetooth message, converts the private message into an MQTT private message and sends the MQTT private message to the Internet;

the cloud server receives the MQTT private message sent by the Internet;

the cloud server further comprises a consumption task, wherein the consumption task checks the private message according to the data type and the check code of the private message, and returns a check result.

In a preferred embodiment of the present application, the data types include fixed-length data and variable-length data.

In a preferred embodiment of the present application, when the data type is fixed-length data, the verifying, by the consuming task, the private message according to the data type and the check code of the private message includes:

returning a verification failure result to the private message which fails to pass the verification;

caching the private messages passing verification, and sequencing the private messages passing verification;

judging whether the private message contains the last group of private messages of the batch or not;

if so, judging whether the number of times of successfully received data is equal to the number of the packets of the batch, and if so, returning a success instruction.

In a preferred embodiment of the present application, if the number of times of successfully received data is not equal to the number of packets of the batch, repeatedly comparing the number of times of successfully received data with the number of packets after a predetermined time interval, and if the number of times of comparison exceeds a threshold value and the number of times of successfully received data is not equal to the number of packets all the time, returning a failure instruction.

In a preferred embodiment of the present application, ordering the private messages passing the verification includes: and sequencing the private messages passing the verification through the ordered set.

In a preferred embodiment of the present application, when the data type is variable-length data, the consumption task checks the variable-length data, and stores the checked data in a database, and records a failure log for the data that fails the check.

In a preferred embodiment of the present application, the check code is a CRC8 check code.

In a preferred embodiment of the present application, the cardiac monitor includes an electrocardiograph signal sensing circuit, a processor, a cycle recorder, and a bluetooth module, wherein the electrocardiograph signal sensing circuit is used for sensing electrocardiograph signals, and the processor is used for sending cardiac event data in the cycle recorder through the bluetooth module.

In a preferred embodiment of the present application, the cardiac monitor monitors the cardiac signal and identifies cardiac events therein, and stores cardiac signal data corresponding to the cardiac events in the cyclical logger.

In a preferred embodiment of the present application, the heart monitor is an implantable heart monitor.

In a preferred embodiment of the present application, the processor is awakened at regular time, and the processor broadcasts a bluetooth message through the bluetooth module and establishes a bluetooth connection with the bluetooth gateway.

In a preferred embodiment of the present application, the processor establishes a bluetooth connection with the bluetooth gateway after detecting a specific cardiac event.

In a preferred embodiment of the present application, the cloud server includes,

an MQTT Broker, which receives a subject message;

and the message queue is used for bridging the topic messages between the MQTT Broker and the consumption task, and the consumption task receives the subscribed topic messages from the message queue.

Compared with the prior art, the application has the following technical improvements:

patient compliance is high: the Bluetooth gateway can automatically establish connection communication with the MQTT by publishing and subscribing the subject message only by one-time configuration of the patient. The whole process of the patient does not feel when the data acquisition is carried out, and the problem of patient compliance is solved.

The problem of disorder of MQTT messages is solved: the scheme that the large-volume data is sent through the MQTT is realized by sending the data according to batches, checking the integrity of the batch data and the number of the data sub-packets and sequencing the data by means of an ordered set.

Support of indefinite length data types: for data of an indefinite data type, the system can check and store the checked data in a database, and record a failure log for the data which fails to check.

The system structure is clear: the system consists of a heart monitor, a Bluetooth gateway, a cloud server and a consumption task, and is clear in structure and easy to understand and maintain.

The expandability is strong: the system uses the MQTT protocol for message transmission, can support a plurality of consumption tasks to process data, and meanwhile, the message queue of the MQTT server can also support more message queue interfaces.

Highly automated: the system realizes the automatic processing of the functions of data transmission, data storage, data verification and the like, reduces human intervention and improves the reliability and stability of the system.

Drawings

FIG. 1 is a schematic diagram of an application scenario of a cardiac monitor data acquisition system.

FIG. 2 is a flow chart of a process for establishing MQTT communication between a heart monitor and a cloud server.

Fig. 3 is a flow chart of a bluetooth gateway registration process.

Fig. 4 is a schematic diagram of a heart monitor periodically communicating with a cloud server via the MQTT protocol via a bluetooth gateway.

Fig. 5 is a schematic diagram of the change in message structure of the cardiac monitor during transmission.

Fig. 6 is a schematic structural diagram of a private message data format.

Fig. 7 is a schematic diagram of a communication architecture of a plurality of heart monitors, a plurality of bluetooth gateways, and a cloud server.

FIG. 8 is a flow chart for consuming task check private messages and integrity checking.

Fig. 9 is a schematic structural diagram of a bluetooth gateway.

Detailed Description

The following technical solutions of the present application are further described in detail with reference to the accompanying drawings, and the embodiments of the present application are only illustrative of the technical solutions, and are not limiting on the technical solutions. The scope of the application is to be determined by the following claims.

Please refer to the application scenario of the heart monitor data acquisition system 100 shown in fig. 1.

The cardiac monitor data acquisition system 100 of the present application works automatically. The patient 200 wears, or an implanted heart monitor 101 monitors the electrocardiographic signals and communicates with a bluetooth gateway 103 through a bluetooth module (not shown). The patient 200 establishes a communication link with the bluetooth gateway 103 when entering a specific space, such as a bedroom as shown in the figure, or when entering the communication range of the bluetooth gateway 103. Typically, to reduce power consumption the heart monitor 101 remains in a sleep state, the heart monitor 101 periodically broadcasts bluetooth messages containing electrocardiographic signal data, the payload data in the bluetooth messages comprising private messages. The bluetooth gateway 103 continuously monitors bluetooth messages broadcast by the heart monitor 101, and establishes bluetooth connection with the heart monitor 101 after receiving the bluetooth messages.

Alternatively, in order to reduce standby power consumption of the heart monitor 101, a timer may be provided inside the heart monitor 101, and the timer wakes up the processor of the heart monitor 101 and the bluetooth module at a specific time, through which a signal is broadcast. For example, a bluetooth message is broadcast twice within 24 hours, preferably for 10 pm: 00 and 6 in the morning: 00, during this period, the patient generally enters a sleep state, the body remains stationary, and the communication signals between the heart monitor 101 and the Bluetooth gateway 103 are stable, which is beneficial to uploading and downloading communication data.

Optionally, the bluetooth message includes a time stamp for checking the heart monitor 101 so that the automatic wake-up time of the heart monitor 101 remains stable. The bluetooth gateway 103 may obtain the time on the timestamp through a network time service center.

Optionally, the cardiac monitor 101 determines whether to connect to the bluetooth gateway 103 based on the detected cardiac event, for example, the cardiac monitor 101 automatically records arrhythmia data after detecting arrhythmia. The heart events may be ranked by severity, with higher ranks indicating greater threat to human life, and may be set to the highest rank for severe malignant arrhythmias. Immediately after the occurrence of a malignant arrhythmia, the heart monitor 101 is connected with the bluetooth gateway 103 to upload heart event data. For lower-ranking cardiac events such as atrial fibrillation, the heart monitor 101 may sleep after storing the heart rhythm data and upload the data upon the next wake-up by connecting with the bluetooth gateway 103.

Optionally, the cardiac monitor packetizes a bluetooth message containing electrocardiographic signal data.

The bluetooth gateway 103 plays a role of data transparent transmission. The bluetooth gateway 103 is powered by the mains supply and is in a monitoring state for 24 hours, and establishes bluetooth connection with the heart monitor 101 after monitoring a bluetooth message for establishing bluetooth connection sent by the heart monitor 101. The heart monitor 101 is connected with the Bluetooth gateway 103 through Bluetooth, the Bluetooth gateway 103 is connected with the Internet 105 through the routing device 104, the Bluetooth gateway 103 converts private messages in Bluetooth messages sent by the heart monitor 101 into MQTT private messages and sends the MQTT private messages to the routing device 104, the routing device 104 sends the MQTT private messages to the cloud server 106 through the Internet 105, and the cloud server 106 establishes communication with the heart monitor 101 through the MQTT private messages.

Alternatively, the bluetooth gateway 103 can directly connect to the internet 105 without connecting to the routing device 104 to establish communication between the heart monitor 101 and cloud server 106.

Optionally, a doctor terminal (not shown in the figure) is further included, and the doctor terminal establishes a connection with the cloud server 106 through the internet 105, so that the doctor can view the data stored on the cloud server 106 by a specific patient through the doctor terminal, or set the device parameters of the patient through the doctor terminal, or the cloud server 106 includes an automated diagnosis platform, and sends a prompt or alarm message to the doctor through the doctor terminal after meeting the specific automated diagnosis standard.

A typical data synchronization scenario is that, when a patient sleeps, the heart monitor 101 automatically wakes up, establishes a connection with the bluetooth gateway 103 by broadcasting a bluetooth message, and then sends data to the cloud server 106 through the bluetooth gateway 103, and the cloud server 106 returns a response signal after receiving a private message in the bluetooth message.

Optionally, the heart monitor data acquisition system 100 further comprises a handheld terminal 107. The handheld terminal 107 is capable of establishing a connection with the bluetooth gateway 103, and the handheld terminal 107 may configure network parameters of the bluetooth gateway 103 through a bluetooth connection, for example, configure account password information of the bluetooth gateway 103 connection routing device 104. The handheld terminal 107 may establish a connection with the cloud server 106 through the routing device 104, and the analysis data, the chart, and the diagnostic information on the cloud server 106 may be directly checked through the handheld terminal 107, so as to facilitate the patient to communicate with the doctor during the outpatient service.

Referring to the flow chart of the MQTT communication process between the heart monitor and the cloud server shown in fig. 2, the communication between the heart monitor 103 and the cloud server 106 is established in three main steps, including step S201, in the working process of the heart monitor data acquisition system 103, the bluetooth gateway 103 and the cloud server 106 are first connected through the MQTT. Step S202, the Bluetooth gateway 103 is connected with the heart monitor 101 through the Bluetooth protocol. In step S203, the heart monitor 101 periodically communicates with the cloud server 106 via the bluetooth gateway 103 via MQTT protocol.

The bluetooth gateway 103 needs to be configured for two initialization before leaving the factory. One of the initialization configurations is to initialize a database, wherein the database sets a mapping relation table between a subscription topic subscore_topic1 and a release topic publish_topic1, and meanwhile, the database sets a presence state table.

Optionally, the subscription topic subscore_topic1, the publishing topic public_topic1 and the presence table are respectively three different fields of the same database table. The database table records the mapping relation among the subscription topic subscore_topic1, the release topic publish_topic1 and the online state table.

Optionally, the database is further provided with a plurality of topic message tables for storing specific topic messages issued by the bluetooth gateway 103. The primary key of the topic message table is a publishing topic field or a subscribing topic field (each column represents a field) in the mapping relation table between the subscribing topic subscore_topic1 and the publishing topic publish_topic1, and the primary key is a code which has a unique mapping relation with the publishing topic publish_topic1 or the subscribing topic subscore_topic1.

The second initialization configuration is to perform initialization configuration on the subscription topic subscore_topic1 and the release topic publish_topic1 when the bluetooth gateway 103 leaves the factory. The bluetooth gateway 103 has been configured with three key information at the time of shipment: the domain name address of the cloud server or the IP address of the internet 105, the publishing theme of the bluetooth gateway 103, and the subscription theme of the bluetooth gateway 103.

In this embodiment, the cloud server 106 includes MQTT Broker and a background service.

After the bluetooth gateway 103 is started for the first time, connection is established with the cloud server 106 through MQTT communication according to the initialization information when leaving the factory, so that registration is realized.

A flowchart of the bluetooth gateway registration process is shown in fig. 3.

In step S301, the bluetooth gateway 103 starts and networks. After the bluetooth gateway 103 is started for the first time, a bluetooth connection is established with the handheld terminal 107 through a bluetooth module, and network connection initialization parameters are configured through a special application program, a specific webpage access mode of a browser and the like, wherein the network connection initialization parameters comprise information such as broadcast signal names, passwords and the like of the routing equipment 104.

In step S302, the bluetooth gateway 103 subscribes to the theme subscore_topic1 from MQTT Broker. After subscribing to the theme, the bluetooth gateway 103 can receive the theme message from the MQTT Broker.

In step S303, the background service queries the topics subscribed by the bluetooth gateway, such as the subscription_topi1, from the MQTT Broker according to the mapping relationship table between the subscription topic subscription_topi1 and the release topic publish_topi1 set for the database.

In step S304, the database records the networking status of the bluetooth gateway 103, so that the online networking status of the bluetooth gateway 103 can be synchronized to the user through the handheld terminal 107, so that the user can know the current networking status of the bluetooth gateway 103. Alternatively, the bluetooth gateway 103 may maintain an online state by periodically sending "heartbeat signal" datagrams.

In step S305, the background service queries the publishing topic public_topic1 according to the subscription topic subscnibe_topic1 of the bluetooth gateway 103, where the query is based on the "mapping table between the database setting subscription topic subscnibe_topic1 and the publishing topic public_topic1" above.

In step S306, the data processing service starts a consumption task corresponding to the publishing_topic 1, and the consumption task receives and processes the topic message published by the bluetooth gateways 103 from the message queue, and each bluetooth gateway 103 starts a corresponding consumption task.

Step S307, completing bluetooth registration, indicates that step S304 and step S305, step S306 have been performed, i.e. the background service has recorded the status of the bluetooth gateway 103 and has started the consumption task for processing the messages issued by the bluetooth gateway 103. In step S307, the status message for completing bluetooth registration may be sent to the handheld terminal 107 through the cloud server 106.

Fig. 4 is a schematic diagram of the heart monitor periodically communicating with the cloud server 106 via the MQTT protocol via the bluetooth gateway 103.

Referring to fig. 4, the heart monitor 101 sends data to the bluetooth gateway 103 through a first bluetooth private message msg1, the bluetooth gateway 103 generates a first MQTT private message msg2 according to the MQTT protocol, and sends the generated first MQTT private message msg2 to an MQTT Broker 1061 (a service in a cloud server), the MQTT Broker 1061 sends the received first message msg3 to a background service 1062, so as to complete a process of transferring a subject message issued by the bluetooth gateway 103 to the background service 1062, and then the background service 1062 processes the message according to information such as a message type.

The background service 1062 sends an MQTT theme message msg4 to the MQTT Broker 1061, the MQTT Broker 1061 converts the MQTT theme message msg4 into a second MQTT private message msg5 and sends the second MQTT private message msg5 to the bluetooth gateway 103, the bluetooth gateway 103 converts the second MQTT private message msg5 into data, and sends the data to the heart monitor 101 through the second bluetooth private message msg6, and the heart monitor 101 makes a corresponding response after receiving the second bluetooth private message msg 6.

A typical application is that the heart monitor 101 passes through several times: the first bluetooth private message msg1, the first MQTT private message msg2, and the first message msg3 send continuous cardiac monitor data, that is, electrocardiographic data corresponding to a cardiac event, to the background service 1062, where the background service 1062 reassembles the data received multiple times into complete data according to the sequence of sending, and stores the verified data in the cloud server 106. After the data is received, a message is sent to the heart monitor 101 as to whether the data is successfully received, specifically including that the background service 1062 is configured to: the MQTT theme message msg4, the second MQTT private message msg5, and the second bluetooth private message msg6 are sequentially transmitted to the heart monitor 101, and after the heart monitor 101 receives the sign that the message is successfully received, the space occupied by the transmitted electrocardiograph signal can be released. After receiving the indication of the failure of the message reception, the heart monitor 101 makes a retransmission indication of the transmitted electrocardiographic signal data.

Optionally, after the cardiac monitor 101 receives the indication of the failure of receiving the message, the cardiac monitor 101 retries to send the electrocardiographic signal data, and after several attempts, for example, 3 times, the cardiac monitor 101 enters a sleep state and retries after being awakened next time.

Optionally, after the heart monitor 101 receives the indication of the message reception failure, the heart monitor 101 directly enters the sleep state, and retries after being awakened next time.

Please refer to the schematic diagram of the message structure change of the heart monitor 101 in the transmission process shown in fig. 5, which illustrates the structure of the private message 501 of the heart monitor 101 in the data uploading process, and the schematic diagram of the structure of the private message in the transmission process of the cloud server 106 to the heart monitor 101.

At the beginning of the connection between the heart monitor 101 and the bluetooth gateway 103, the heart monitor 101 broadcasts a bluetooth message 500 to the outside, and the bluetooth message 500 is used for establishing a bluetooth connection. The bluetooth message 500 includes message data d1, where the message data d1 is used to establish bluetooth connection, and the message data d1 includes: broadcast address, broadcast type, service UDI (unique identification of medical instrument), device name, manufacturer data, etc.

Optionally, the heart monitor 101 broadcasts the bluetooth message 500 periodically, for example every 10 seconds-10 minutes.

Optionally, the heart monitor 101 includes a clock module (not shown in the figure) that wakes up a processor (not shown in the figure) of the heart monitor 101 at a specific time point, and the processor controls a bluetooth module (not shown in the figure) of the heart monitor 101 to send the bluetooth message 500 at the specific time point.

After the bluetooth connection is established, the heart monitor 101 sends data to the bluetooth gateway 103 via a bluetooth message 502, where the bluetooth message 502 is used for transmitting data. The bluetooth message 502 includes bluetooth data d2, where the bluetooth data d2 is used for communication, and the bluetooth data d2 includes: access address, control field, data length, data field, security related field, etc. The bluetooth message 502 includes a private message 501, where the private message 501 is used for transmitting electrocardiographic data by a user, and the private message 501 may be a part of data to be transmitted, that is, the cardiac monitor 101 sends complete data packets to the bluetooth gateway 103 through the bluetooth message 502 multiple times.

After the bluetooth gateway 103 receives the bluetooth message 502, the data portion of the private message 501 is parsed out, and is converted into the MQTT private message 504. As shown in fig. 5, the MQTT private message 504 includes data d3, the data d3 being for MQTT protocol communication, the data d3 comprising: packet identifier, topic, qoS class, payload, etc., where all payload parts are private packets 501.

The MQTT private message 504 is combined as a payload part in a TCP/IP message 503, the TCP/IP message 503 comprising data d4, the data d4 being for communication, the data d4 comprising: source IP address, destination IP address, version number, source port number, destination port number, serial number, acknowledgement number, data offset, reserved bits, flag bits, etc. After the TCP/IP message 503 is sent to the MQTT Broker 1601, the MQTT Broker 1061 obtains the message of the MQTT private message 504, and delivers the message to the specific consumption task 506 according to the release topic in the message.

Fig. 6 is a schematic diagram of a data format of a private message 501, which includes a header portion, a data content portion, and a check location. The sequence of each part can be adjusted according to actual requirements. The header portion includes a length, a data type, a data batch number, a number of packets per batch, and a current data packet sequence number. The data content portion includes all or a portion of the electrocardiographic signal data. In a specific embodiment, the check location includes a CRC8 check code.

Similarly, the structure of the MQTT private message also includes the parts in fig. 6.

The field packet contained in the private message has a specific meaning, as shown in the following table:

wherein the data type further comprises an encoding for distinguishing the heart monitor 101. The encoding is suitable for distinguishing the messages sent by different heart monitors by the consumption task of the cloud server 106 when a plurality of heart monitors send messages to the cloud server 106 by using the same release subject.

Please refer to the communication architecture diagram of the plurality of heart monitors, the plurality of bluetooth gateways and the cloud server 106 shown in fig. 7. Wherein the MQTT Broker 1601 is connected to the first bluetooth gateway 1031, the second bluetooth gateway 1032, the third bluetooth gateway 1033, and the background service 1062 at the same time, where one bluetooth gateway may be connected to multiple cardiac monitors, for example, the second bluetooth gateway 1032 is connected to the second cardiac monitor 1012 and the third cardiac monitor 1013, and the multiple cardiac monitors use the same publishing theme topic2 to communicate with the cloud server 106; the first bluetooth gateway 1031 is connected to the first heart monitor 1011, and the first heart monitor 1011 communicates with the cloud server 106 using the release topic 1; the third bluetooth gateway 1033 is connected to the fourth heart monitor 1014, and the fourth heart monitor 1014 communicates with the cloud server 106 using the published topic3, and the background service 1062 distinguishes messages sent by different heart monitors by data type in private messages.

With continued reference to FIG. 7, the background service 1062 includes a message queue 10621, a consumption task module 10627, a Redis in-memory database 10625, and a relational database 10626. The consumption task module 10627 includes a first consumption task 10622, a second consumption task 10623, and a third consumption task 10624. Each consumption task subscribes to a different Topic, and the first consumption task 10622, the second consumption task 10623, and the third consumption task 10624 subscribe to Topic1, topic3, and Topic2, respectively, and process Topic messages. The message queue 10621 is used to bridge messages of different topics topic1, topic2, topic3 between the MQTT Broker 1061 and the first, second and

third consumption tasks

10622, 10623, 10624. Wherein the first consumption task 10622 also validates and integrity checks the subject message. After the subject message is authenticated, the authenticated subject message is stored in Redis in-memory database 10625. When the data in Redis in-memory database 10625 includes a complete batch of data, then the subject message is stored into relational database 10626.

The message queue 10621 is a kafka message server commonly used in the art and has the primary function of caching messages between the server and consuming tasks and ensuring reliable messaging. In addition, the Kafka message server can decouple the server and the consumption task, reduce the complexity of the system, improve the data throughput, realize distributed storage and processing, realize real-time data stream processing, data buffering, asynchronous processing and the like.

Taking the first consumption task 10622 as an example, after receiving the message of the private message 501, the first consumption task 10622 verifies the data first, and sends a return message to the heart monitor 101 after the verification is completed, as shown in fig. 7, the first consumption task 10622 issues a message of the topic1 to the MQTT Broker 1061, and the MQTT Broker 1061 sends the message of the topic1 to the first heart monitor 1011 subscribed to the topic.

Please refer to the flowchart of fig. 8 for consuming task verification private message and integrity check.

The consumption task checks the private message 501 according to the data type and the check code of the private message 501, and returns a check result.

In step S801, the consuming task module 10627 receives a message from the message queue 10621. More specifically, the consuming task module 10627 fetches the messages in the message queue 10621 at one time according to the topic to which it subscribes. After the message is fetched, the message contents with themes of Topic1, topic2 and Topic3 are processed. Different consumption tasks may be corresponded to different devices identified by different data types.

In step S802, the consumption task determines whether it is fixed-length data according to different data types. Step S803 is entered if the data type is fixed-length data, and step S815 is entered if the data type is variable-length data.

In step S803, CRC8 check is performed on the fixed-length data. It can be determined whether the data is erroneous during transmission by the CRC8 check. More specifically, the CRC8 check code is used for checking, where the CRC8 check is a check method commonly used by those skilled in the art, and the basic technical principle thereof will not be described herein.

In step S804, the verification result in the previous step S803 is judged. For the private message 501 that fails the verification, a result of failure in verification of the data of the present batch is returned in step S810. With continued reference to fig. 4, the result of the return check failure issues an MQTT theme message msg4 to the MQTT Broker 1061 through the consuming task, where the MQTT theme message msg4 includes a private message 501, the MQTT theme message msg4 is packaged into a second MQTT private message msg5 through the MQTT Broker 1061, the second MQTT private message msg5 is transmitted to the bluetooth gateway 103, the bluetooth gateway 103 converts the second MQTT private message msg5 into a second bluetooth private message msg6 containing the private message 501, and transmits the second bluetooth private message msg6 to the cardiac monitor 101, and the cardiac monitor 101 determines a further processing scheme according to the identifier of the return success or failure, where optionally, the cardiac monitor 101 may retransmit the batch data immediately or after the next wakeup.

In step S805, the private messages passing the verification are cached in the Redis memory database 10625, and the private messages passing the verification are ordered by the ordered set. The ordered set is ordered according to the sequence number of the current data packet in the private message, and the ordering can be positive or reverse according to the sequence number.

The use of the Redis memory database 10625 to buffer data has two benefits, the direct storage of data in memory improves the communication efficiency, and the ordered collection in the Redis memory database 10625 can realize the sequencing of data for batch transmission, so that the data in the message can be conveniently combined into complete electrocardiogram data in sequence.

In step S806, it is determined whether the sequenced private message includes the last group of private messages of the batch. The determining step compares the current packet sequence number in the private message with the number of packets actually received in the batch, if the two are equal, the step S807 is entered, and if the two are not equal, no processing is performed in step S811.

In step S807, it is determined whether the present batch data is complete. The number of times of successful reception (the number of lines buffered in the dis) is compared with the number of packets of the batch, and if the number of times of successful reception (the number of lines buffered in the dis) is equal to the number of packets of the batch, the batch is considered to be received completely, and the data may be stored in the dis in-memory database 10625 in step S808. In step S809, the consuming task returns a success instruction by way of the release of the subject message. The heart monitor 101 enters a sleep state after receiving the success instruction, and waits for the next wake-up data transmission.

If it is determined in step S807 that the present lot data is incomplete, the process advances to a wait determination step S813.

In step S813, if the number of times of successfully received data (the number of lines buffered in the dis) is not equal to the number of packets, the number of times of successfully received data (the number of lines buffered in the dis) and the number of packets are repeatedly compared after a predetermined time interval, and if the number of times of comparison exceeds a threshold and the number of times of successfully received data (the number of lines buffered in the dis) is not equal to the number of packets all the time, a failure instruction is returned in step S814. In fig. 8, the threshold is 3.

More specifically, a waiting number counter i=0 is set in step S812, and when the determination result in step S813 is no, the process proceeds to step S812, where the waiting counter performs a self-increment operation, so that i=i+1, and in step S812, the thread consuming the task (which may be a synchronous or asynchronous thread) waits for 1 second, and then proceeds to step S807, where it is determined whether the batch of data is complete. If it is determined in step S813 that the number of waiting times has reached 3, the flow advances to step S814 to return a failure instruction.

In step S815, if the data type is variable-length data, in step S816, the consuming task checks the variable-length data, optionally while still performing a CRC8 check on the data. Judging whether the verification is passed in step S817, if so, storing the data in the database in step S818; if not, the data is logged for failure in step S819.

The heart monitor 101 comprises an electrocardiosignal sensing circuit, a processor, a circulation recorder and a Bluetooth module, wherein the electrocardiosignal sensing circuit is used for sensing electrocardiosignals, and the processor is used for sending heart event data in the circulation recorder in a subpackage mode through the Bluetooth module. The cardiac monitor 101 monitors the cardiac signal and recognizes cardiac events therein, and stores cardiac signal data corresponding to the cardiac events in a circulation recorder.

The electrocardiosignal sensing circuit converts the electrocardiosignal into a digital signal which can be processed by a processor through steps of filtering, amplifying, analog-to-digital conversion and the like. Wherein the digital signal contains a QRS wave reflecting the QRS wave generated when the heart is depolarized, and the processor diagnoses the heart rate based on the QRS wave.

The processor identifies cardiac events therein from the QRS wave and stores cardiac events to be recorded in the cycle recorder. Cardiac events that can be diagnosed by the processor include, but are not limited to: sinus tachycardia, sinus tachycardia and sinus arrest; premature atrial contractions, atrial fibrillation and flutter, premature sexual contractions, ventricular tachycardia and ventricular fibrillation, etc., primary and tertiary atrioventricular blocks, QT interval abnormalities, electrocardiogram ST-segment and T-wave abnormalities.

Optionally, the processor is awakened at regular time, and the processor broadcasts a bluetooth message through a bluetooth module and establishes a bluetooth connection with the bluetooth gateway.

Optionally, the processor establishes a bluetooth connection with the bluetooth gateway after detecting a specific cardiac event.

The principle of the circular recorder is to treat one continuous memory block as a circular buffer, and use two pointers to represent the start and end positions of the buffer. Specifically, the circular recorder has two pointers, one pointing to the beginning of the buffer, called the "head pointer", and the other pointing to the end of the buffer, called the "tail pointer". When data is written to the buffer, they are written to the location pointed to by the tail pointer and the tail pointer is moved one bit backward. When the buffer is full, the tail pointer will return to the starting position of the buffer, overwriting previously written data. Similarly, when data is read, they are read by the position pointed to by the head pointer and the head pointer is moved one bit back. When the buffer is empty, the head pointer will return to the starting position of the buffer, reading the previously unread data.

The Bluetooth module establishes Bluetooth communication according to the request of the processor. The process of establishing bluetooth communication includes discovery, connection, pairing, establishing communication.

The discovery includes searching surrounding Bluetooth gateways nearby by taking the heart monitor as a main device and sending broadcast signals to the heart monitor to find connectable Bluetooth gateways, wherein the broadcast signals can comprise specific connection identifiers.

Wherein connecting includes sending a connection request to a bluetooth gateway when the heart monitor finds an available bluetooth gateway, the bluetooth gateway can accept or reject the request.

The pairing process is mainly used for ensuring the security of communication and preventing other unauthorized devices from being connected. During pairing, the bluetooth gateway and the heart monitor exchange some information with each other and use some algorithm to encrypt the information, ensuring that only the paired bluetooth gateway and heart monitor can communicate.

Referring to the schematic diagram of the bluetooth gateway shown in fig. 9, the bluetooth gateway 103 includes a gateway bluetooth module 1302, a gateway processor 1303, a gateway power module 1304, a network communication module 1305, and a status indicator 1301.

Similarly, the gateway Bluetooth module 1302 receives the electrocardio signal data sent by the heart monitor 101, and the gateway processor 1303 converts the electrocardio signal data into MQTT data and sends the MQTT data to the Internet 105 through the network communication module 1305.

The gateway power module 1304 converts ac mains to dc and provides power to the gateway bluetooth module 1302, gateway processor 1303, network communication module 1305, etc. The bluetooth gateway 103 can be kept on-line for a long time by a gateway power module 1304.

The status indicator 1301 indicates the state in which the bluetooth gateway 103 or the heart monitor 101 is currently located. The status indicator 1301 gives different indications according to the different states in which the bluetooth gateway 103 is located.

Optionally, after the bluetooth connection is established, and before the data transmission is completed, the status indicator 1301 indicates the status of the bluetooth gateway 103.

Optionally, the status indicator 1301 indicates a network connection status.

Optionally, the status indicator 1301 includes an LED that identifies a network connection status, a bluetooth connection status, a data acquisition status. The LEDs can be used for identifying different states by normally-on, normally-off, flashing, running light, breathing light and the like so as to inform the state of the user equipment or possible faults, and the user can conveniently and timely process the faults.

Optionally, the status indicator 1301 includes an indicator light that identifies the status of the heart monitor 101, including an indicator light that identifies the battery level, an indicator light that identifies the stored status, to inform the user of the status of the heart monitor at that time.

Claims

1. A cardiac monitor data acquisition system, comprising:

the payload data in the Bluetooth message comprises a private message, wherein the private message comprises a data type, a check code, a current data packet sequence number and the batch packet number;

the heart monitor sends private messages according to batches and numbers the sub-packets of the private messages;

the cloud server receives the MQTT private message sent by the Internet;

the cloud server further comprises a consumption task, and the consumption task verifies the private message according to the data type and the verification code of the private message; sorting the private messages passing the verification, verifying the integrity of the private messages in the batch, and returning a verification result;

the consuming task verifying the private message according to the data type and the check code of the private message further comprises:

caching private messages passing verification;

if so, judging whether the number of times of successfully received data is equal to the number of the batches of the packets, and if so, returning a success instruction;

if the number of times of successfully received data is not equal to the number of sub-packets of the batch, repeatedly comparing the number of times of successfully received data with the number of sub-packets after a plurality of times of intervals for a preset time, and if the number of times of comparison exceeds a threshold value and the number of times of successfully received data is not equal to the number of sub-packets all the time, returning a failure instruction;

the ordering of the private messages passing the verification comprises the following steps: and sequencing the private messages passing the verification through the ordered set.

2. The cardiac monitor data acquisition system of claim 1, wherein the check code is a CRC8 check code.

3. The cardiac monitor data acquisition system of claim 1, wherein the cardiac monitor comprises an electrocardiograph signal sensing circuit, a processor, a cycle recorder, and a bluetooth module, the electrocardiograph signal sensing circuit is configured to sense electrocardiograph signals, and the processor is configured to packetize cardiac event data in the cycle recorder via the bluetooth module.

4. A cardiac monitor data acquisition system according to claim 3, wherein the cardiac monitor monitors cardiac electrical signals and identifies cardiac events therein, and the cardiac electrical signal data corresponding to the cardiac events is stored in a cycle recorder.

5. The cardiac monitor data acquisition system of claim 4, wherein the cardiac monitor is an implantable cardiac monitor.

6. The cardiac monitor data acquisition system of claim 4, wherein the processor is awakened at regular intervals, wherein the processor broadcasts bluetooth messages via the bluetooth module and establishes a bluetooth connection with the bluetooth gateway.

7. The cardiac monitor data acquisition system of claim 4, wherein the processor establishes a bluetooth connection with the bluetooth gateway after detecting a specific cardiac event.

8. The heart monitor data collection system of claim 1, wherein the cloud server comprises,

an MQTTBroker which receives a subject message;