Unified management method and server for biometric data

Abstract

The application relates to a unified management method and a server for biological recognition data, and the method comprises the following steps: receiving event sign data uploaded by a client, the event sign data being biological recognition data collected by a sign device and converted by the client according to a pre-agreed event data format; and storing event content corresponding to the biological recognition data in the event sign data in a database in an original format. The application inputs the sign data into the server in the form of event data structure, so that the unified format of various types of sign data can be flexibly contained in the structure, and special development and adaptation for different types of sign data are not needed, so that the expansibility of the vital sign data is improved.

Description

Technical Field

[0001] This invention belongs to the field of data management technology, specifically relating to a unified management method and server for biometric data. Background Technology

[0002] For input data into vital signs data platforms, there are often multiple input methods, such as RESTful APIs and batch file imports.

[0003] These input methods have clearly defined data structure, format, and type. When new vital sign data is input, the existing structure, format, and type must be redefined. If the entire design is a shared interface for all vital sign types, the existing structure, format, and type need to be modified and updated. If the design is a separate interface for each vital sign type, a new separate interface needs to be designed to implement it.

[0004] Because the structure, format, and type of vital sign data collected by different types of devices vary, their management methods also differ. This presents a challenge to integrating and managing data from various devices into a vital sign data platform: whenever a new device collects vital sign data, development and testing must be performed based on the new input data, resulting in additional development, testing, and time cycles. In other words, existing technologies for managing vital sign data suffer from poor scalability. Summary of the Invention

[0005] The purpose of this invention is to provide a unified management method and server for biometric data to improve the scalability of vital sign data.

[0006] To address the aforementioned technical problems, this invention discloses a unified management method for biometric data, comprising the following steps:

[0007] Receive event vital sign data uploaded by the client, wherein the event vital sign data is converted by the client from biometric data collected by the vital sign device according to a pre-agreed event data format;

[0008] The event content corresponding to the biometric data in the event vital signs data is stored in the database in its original format.

[0009] Furthermore, the event vital sign data includes fixed data attributes, event content converted from biometric data collected by the vital sign device, and context data corresponding to the biometric data.

[0010] Furthermore, the event content can be defined according to different biometric data characteristics.

[0011] Furthermore, storing the event content corresponding to the biometric data in the event vital sign data in the database in its original format specifically involves:

[0012] The event vital signs data are converted into a data format supported by the database, wherein the event content corresponding to the biometric data in the event vital signs data is stored in the database in its original format.

[0013] Furthermore, the event characteristic data uploaded by the receiving client specifically includes:

[0014] Receive and verify the event characteristic data uploaded by the client, and push the event characteristic data to the message queue after verification.

[0015] Extract event signature data uploaded by the client from the message queue.

[0016] To address the aforementioned technical problems, this invention discloses a unified management server for biometric data, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps:

[0017] Receive event vital sign data uploaded by the client, wherein the event vital sign data is converted by the client from biometric data collected by the vital sign device according to a pre-agreed event data format;

[0018] The event content corresponding to the biometric data in the event vital signs data is stored in the database in its original format.

[0019] Furthermore, the event vital sign data includes fixed data attributes, event content converted from biometric data collected by the vital sign device, and context data corresponding to the biometric data.

[0020] Furthermore, the event content can be defined according to different biometric data characteristics.

[0021] Furthermore, storing the event content corresponding to the biometric data in the event vital sign data in the database in its original format specifically involves:

[0022] The event vital signs data are converted into a data format supported by the database, wherein the event content corresponding to the biometric data in the event vital signs data is stored in the database in its original format.

[0023] Furthermore, the event characteristic data uploaded by the receiving client specifically includes:

[0024] Receive and verify the event characteristic data uploaded by the client, and push the event characteristic data to the message queue after verification.

[0025] Extract event signature data uploaded by the client from the message queue.

[0026] This invention transforms biometric data collected by vital sign devices into event vital sign data according to a pre-agreed event data format. This allows vital sign data to be input into the cloud in the form of event data structure, thus flexibly including a unified format for various types of vital sign data without the need for special development and adaptation for different types of vital sign data, thereby improving the scalability of vital sign data. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating the unified management method for biometric data according to an embodiment of the present invention.

[0028] Figure 2 This diagram illustrates the differences between the unified management method for biometric data according to an embodiment of the present invention and existing technologies in the data processing process.

[0029] Figure 3 This is a schematic diagram illustrating the interaction between the server and the client in the unified management method for biometric data according to an embodiment of the present invention.

[0030] Figure 4 This is a schematic diagram of the structure of the unified management server for biometric data according to an embodiment of the present invention.

[0031] 1. A unified management server for biometric data; 2. Storage; 3. Processor. Detailed Implementation

[0032] The present invention will be further described in detail below through embodiments, so that those skilled in the art can implement it based on the description.

[0033] It should be understood that terms such as “having,” “comprising,” and “including” as used herein do not exclude the presence or addition of one or more other elements or combinations thereof.

[0034] Example 1

[0035] like Figures 1 to 3 As shown, the unified management method for biometric data includes the following steps:

[0036] S1. Receive event vital sign data uploaded by the client. The event vital sign data is generated by the client converting the biometric data collected by the vital sign device according to the pre-agreed event data format.

[0037] In this embodiment, biometric data is vital sign data. Therefore, the event vital sign data in this embodiment includes fixed data attributes, event content converted from biometric data collected by the vital sign device, and context data corresponding to the biometric data.

[0038] The fixed data attributes are the common components shared by different types of vital sign devices. In this embodiment, the fixed data attributes include, but are not limited to: device ID (Identity document), event type, data acquisition time, firmware version, hardware version, device battery level, etc. The event type refers to the type of vital sign data, such as body temperature, electrocardiogram, blood pressure, and blood oxygen saturation.

[0039] The event content can be defined according to different biometric data characteristics, and can be expressed using non-pre-agreed name / value pairs (name / value pairs, a data structure of mapping relationships), for example:

[0040] (1) Body temperature: 36.6;

[0041] (2) Blood pressure is: "systolic": 120; "diastolic": 80;

[0042] (3) The electrocardiogram is: "ECG": [10,20,10,5,0,…….].

[0043] Among them, temperature refers to body temperature; systolic refers to systolic pressure, and the first English word is used to represent it here; diastolic refers to diastolic blood pressure, and the first English word is used to represent it here; ECG is an abbreviation for electrocardiogram, which means electrocardiogram.

[0044] The context data is flexibly compiled based on the event type to adapt to different types of vital sign data. In this embodiment, the context data is also represented using non-pre-agreed name / value pairs.

[0045] like Figure 3 As shown, for vital sign data, the process involves data transfer from the mobile device client to the cloud data server. For the client, the main steps are as follows:

[0046] On the client side, the acquired vital signs data from the vital signs device is prepared in JSON (JavaScript Object Notation, a lightweight data exchange format) format according to the pre-agreed event data format.

[0047] The client pushes the prepared JSON-formatted event data to the cloud's interface gateway via a RESTful (Representational State Transfer, a design style and development approach for web applications) data interface provided by the cloud. Throughout this process, the event data remains in JSON format.

[0048] The input format used by the client to push JSON-formatted event characteristic data to the cloud interface gateway can also be CSV (Comma-Separated Values) / Excel files, etc.

[0049] For the server, step S1, receiving the event signature data uploaded by the client, specifically involves:

[0050] S11. Receive and verify the event characteristic data uploaded by the client, and push the event characteristic data to the message queue after verification.

[0051] That is, when the server-side interface gateway receives event data in JSON format, it verifies the data format. If the verification is correct, it still pushes the data into the cloud message queue in JSON format.

[0052] S12. Extract the event signature data uploaded by the client from the message queue.

[0053] This means that the event data from the server is extracted from the message queue and prepared for consumption.

[0054] S2. Store the event content corresponding to the biometric data in the event vital signs data in the database in its original format.

[0055] In this embodiment, step S2 specifically includes:

[0056] The event vital signs data are converted into a data format supported by the database. The event content corresponding to the biometric data in the event vital signs data is stored in the database in its original format.

[0057] For the server, the event data extracted from the message queue undergoes a minor data format conversion, changing from JSON to a format compatible with NoSQL (Not Only SQL, non-relational databases) databases before being stored. This conversion is simply a conversion from JSON to a database table; the "Event Data" containing the event data is directly stored in JSON format.

[0058] Data in NoSQL databases can be queried, for example, by device ID, and the query result can be returned to the client directly as "Event Data".

[0059] The following is an example of database table design:

[0060]

[0061] The device ID, event type, collection time, device battery level, hardware version, and firmware version correspond to the aforementioned data attributes. The data is converted from JSON format to NoSQL database format for storage, while the event characteristics data retains the JSON format, so it can be directly returned during querying.

[0062] As can be seen from the table above, the specific event content can be automatically adapted according to the different types of vital sign data, so new types of vital signs can be included at any time.

[0063] Therefore, combined Figure 2 As can be seen, the differences between the data management in this embodiment and the prior art are explained below in terms of data import, data processing pipeline, and data services:

[0064] (1) Data import: Compared with the prior art, the technical solution of this embodiment adopts a more flexible event data format to express vital sign data (JSON), so new unknown vital sign data can be accessed at any time. In contrast, the data format of the prior art is fixed, so new unknown vital sign data needs to be updated and adjusted by the data access end.

[0065] (2) Data Channel: After data is imported into the cloud, it is stored in a cloud database in the format of vital sign event data, accepting operations such as querying and data archiving. Simultaneously, the data itself undergoes cleaning and processing before being placed into the data lake of the corresponding data service platform. In the data lake, the vital sign data is represented in a unified schema to provide basic data services for data analysis and algorithms. Current technology still uses a fixed storage format, which is not conducive to subsequent data analysis, etc.

[0066] (3) Data Services: Event data, or unified data in a data lake, can provide various data services to other applications and third parties, including rule engines, advanced queries, business intelligence, and artificial intelligence applications. Weling's design, benefiting from event data and a unified model, can provide better services to third-party applications compared to existing technologies.

[0067] Therefore, when a vital signs data service platform is developed based on the server side, new vital signs data can be directly accessed in the form of events and structures, without the need for special development and adaptation for different types of vital signs data, thereby improving the scalability of vital signs data.

[0068] Example 2

[0069] like Figure 2 The unified management server 1 for biometric data includes a memory 2, a processor 3, and a computer program stored on the memory 2 and capable of running on the processor 3. When the processor 3 executes the computer program, it implements the steps in Embodiment 1 above.

[0070] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and embodiments shown and described herein.

Claims

1. A unified management method for biometric data, characterized in that, Includes the following steps: In the client, the acquired vital signs data from the vital signs device is prepared in JSON format according to the pre-agreed event data format. The client then pushes the prepared JSON format event vital signs data to the cloud interface gateway through the RESTful data interface provided by the cloud. The server-side interface gateway receives the event vital sign data in JSON format, verifies the data format, and, if correct, pushes it to the cloud message queue in JSON format. Specifically, it receives the event vital sign data uploaded by the client. This event vital sign data is generated by the client converting biometric data collected by the vital sign device according to a pre-agreed event data format. The event vital sign data includes fixed data attributes, event content converted from the biometric data collected by the vital sign device, and context data corresponding to the biometric data. The fixed data attributes are common to different types of vital sign devices and include, but are not limited to: device ID, event type, data collection time, firmware version, hardware version, and device battery level. The event type refers to the type of vital sign data, which includes: body temperature, electrocardiogram (ECG), blood pressure, and blood oxygen saturation. The event vital sign data is converted into a data format supported by the database. The event content corresponding to the biometric data within the event vital sign data is stored in the database in its original format. Conversion methods include: The event data extracted from the message queue undergoes a minor data format conversion, changing from JSON to a format compatible with NoSQL databases before being stored in the database. The context data is flexibly compiled according to the event type to adapt to different types of vital sign data; wherein, the context data is expressed using non-pre-agreed name / value pairs; The event content is defined according to the different biometric data types and is expressed using non-pre-agreed name / value pairs; The event content and the context data are stored in the NoSQL database in JSON format; For the data in the NoSQL database, queries are performed by device ID, and the query results are returned to the client in the form of Event Data.

2. A unified management server for biometric data, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it performs the following steps: In the client, the acquired vital signs data from the vital signs device is prepared in JSON format according to the pre-agreed event data format. The client then pushes the prepared JSON format event vital signs data to the cloud interface gateway through the RESTful data interface provided by the cloud. The server-side interface gateway receives the event vital sign data in JSON format, verifies the data format, and, if correct, pushes it to the cloud message queue in JSON format. Specifically, it receives the event vital sign data uploaded by the client. This event vital sign data is generated by the client converting biometric data collected by the vital sign device according to a pre-agreed event data format. The event vital sign data includes fixed data attributes, event content converted from the biometric data collected by the vital sign device, and context data corresponding to the biometric data. The fixed data attributes are common to different types of vital sign devices and include, but are not limited to: device ID, event type, data collection time, firmware version, hardware version, and device battery level. The event type refers to the type of vital sign data, which includes: body temperature, electrocardiogram (ECG), blood pressure, and blood oxygen saturation. The event vital sign data is converted into a data format supported by the database. The event content corresponding to the biometric data within the event vital sign data is stored in the database in its original format. Conversion methods include: The event data extracted from the message queue undergoes a minor data format conversion, changing from JSON to a format compatible with NoSQL databases before being stored in the database. The context data is flexibly compiled according to the event type to adapt to different types of vital sign data; wherein, the context data is expressed using non-pre-agreed name / value pairs; The event content is defined according to the different biometric data types and is expressed using non-pre-agreed name / value pairs; The event content and the context data are stored in the NoSQL database in JSON format; For the data in the NoSQL database, queries are performed by device ID, and the query results are returned to the client in the form of Event Data.

Images