Electronic medical record distributed storage method based on Hash algorithm

Abstract

The invention discloses an electronic medical record distributed storage method based on a Hash algorithm, and the method is based on a micro-service architecture, a storage request is accessed through a load balancing layer in the micro-service architecture, and micro-service instances are distributed for electronic medical records according to the load indexes of the micro-service instances at the current moment. The load distribution of the micro-service architecture is optimized, and overload and resource waste of micro-service instances are reduced. Then, the electronic medical record is stored on a hash ring of the distributed storage layer through the micro-service layer and the distributed storage layer, uniform distribution and high availability of data are ensured, and finally, the real-time load of the physical storage node bound with the first target virtual node is collected through the containerization management layer. The first target physical node is determined to store the electronic medical record through the load balancing layer according to the real-time load of each physical node, so that uniform storage of data is realized, the storage efficiency is improved, and the flexibility, availability and data processing capability of the storage system are improved.

Description

Technical Field

[0001] The present disclosure generally relates to the field of medical information systems, and particularly to a distributed storage method for electronic medical records based on a hash algorithm. Background Art

[0002] The electronic medical record system is a core component of medical informatization. With the rapid development of medical informatization, this system needs to process a large amount of data, including medical record texts, imaging materials, inspection reports, etc. In addition, due to the expansion of hospital services and the increase in the number of patients, the electronic medical record system needs to support high-concurrency access. Therefore, how to store electronic medical records has become an urgent problem to be solved.

[0003] Currently, common ways to store electronic medical records include centralized storage and distributed storage. However, centralized storage has poor resource utilization, cannot be scaled on demand, has high construction and maintenance costs, and there are bottlenecks in storage I / O when processing a large number of concurrent requests; while distributed storage can solve some problems brought by centralized storage, but when the nodes change dynamically, the redistribution of data will lead to a decline in performance.

[0004] Facing the above problems, a new storage method for electronic medical records is needed to improve the flexibility, availability, and data processing ability of the system. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a distributed storage method for electronic medical records based on a hash algorithm to improve the flexibility, availability, and data processing ability of the system when storing electronic medical records.

[0006] In a first aspect, a distributed storage method for electronic medical records based on a hash algorithm is provided. The method is applied to a microservices architecture, and the microservices architecture includes a distributed storage layer, a microservices layer, a load balancing layer, and a containerization management layer. The method includes: Access a storage request through the load balancing layer, and collect the load metrics of each microservices instance at the current moment. The storage request carries the electronic medical record; The load balancing layer determines a target microservices instance according to the load metrics of each microservices instance, and allocates the storage request to the target microservices instance; Call the microservices layer through the target microservices instance to parse the electronic medical record and generate a hash key; Call the distributed storage layer through the target microservices instance to map the hash key to the hash ring of the distributed storage layer through a consistent hash algorithm, and determine a first target virtual node corresponding to the hash key from multiple virtual nodes on the hash ring; The target microservice instance is used to call the containerized management layer to collect the real-time load of the physical storage node bound to the first target virtual node, select the physical storage node with the minimum real-time load as the first target physical storage node, and store the electronic medical record in the first target physical storage node.

[0007] A distributed storage method for electronic medical records based on the hash algorithm provided by this application takes into account the problems existing in the current method of storing electronic medical records, such as poor resource utilization, inability to scale on demand, high construction and maintenance costs, bottlenecks in storage I / O when processing a large number of concurrent requests, and performance degradation caused by data redistribution. This application provides a distributed storage method for electronic medical records based on the hash algorithm. This method is based on the microservice architecture. When the load balancing layer in the microservice architecture accesses the storage request for storing electronic medical records, it allocates a suitable microservice instance for the electronic medical record to be stored according to the load metrics of each microservice instance at the current moment, so as to optimize the load distribution of the microservice architecture, reduce the overload of microservice instances and resource waste; after the target microservice instance is allocated for the storage request through the load balancing layer, the target microservice instance calls the microservice layer and the distributed storage layer to store the electronic medical record on the hash ring of the distributed storage layer through the consistent hash algorithm to ensure the uniform distribution and high availability of data. Finally, the target microservice instance will also collect the real-time load of the physical storage node bound to the first target virtual node for storing the electronic medical record through the containerized management layer, and determine the first target physical node to store the electronic medical record according to the real-time load of each physical node through the load balancing layer, so as to achieve the uniform storage of data, improve the storage efficiency, and thus improve the flexibility, availability and data processing ability of the storage system. Brief Description of the Drawings

[0008] By reading the detailed description of the non-restrictive embodiments with reference to the following drawings, other features, purposes and advantages of this application will become more obvious: Figure 1 It is an application scenario diagram of a distributed storage method for electronic medical records based on the hash algorithm provided by this application; Figure 2 It is a flowchart of a distributed storage method for electronic medical records based on the hash algorithm provided by this application; Figure 3 It is a step flowchart of a distributed storage method for electronic medical records based on the hash algorithm provided by this application; Figure 4 It is a step flowchart of a distributed storage method for electronic medical records based on the hash algorithm provided by this application; Figure 5 It is a step flowchart of a distributed storage method for electronic medical records based on the hash algorithm provided by this application; Figure 6 The flowchart of steps of a distributed storage method for electronic medical records based on the hash algorithm provided by this application; Figure 7 The system architecture diagram of a distributed storage method for electronic medical records based on the hash algorithm provided by this application. Detailed implementation manners

[0009] The following further elaborates on this application in conjunction with the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are merely used to explain the related invention rather than limit the invention. Additionally, it should be noted that for ease of description, only the parts related to the invention are shown in the drawings.

[0010] It should be noted that, without conflict, the embodiments in this application and the features in the embodiments can be combined with each other. The following will elaborate on this application in detail with reference to the drawings and embodiments.

[0011] Please refer to Figure 1 , Figure 1 which is an application scenario diagram of a distributed storage method for electronic medical records based on the hash algorithm provided by this application. The application scenario diagram includes a server 100 and a server cluster 200. The server 100 is equipped with a microservices architecture, which includes a distributed storage layer, a microservices layer, a load balancing layer, and a containerization management layer. The server 100 maps the electronic medical records to be stored onto the hash ring set thereon through the microservices architecture to ensure the uniform distribution and high availability of data. Additionally, through the load balancing process of the microservices architecture, the electronic medical records to be stored are stored on the server with the least load in the server cluster 200, realizing the storage of the electronic medical records to be stored.

[0012] Next, the distributed storage method for electronic medical records based on the hash algorithm provided by this application will be described.

[0013] As Figure 2 shown, Figure 2 which is the flowchart of steps of a distributed storage method for electronic medical records based on the hash algorithm provided by this application. Taking the application of this method to the microservices architecture of the above server as an example, this method will be described. The microservices architecture includes a distributed storage layer, a microservices layer, a load balancing layer, and a containerization management layer. This method includes: Step S20, access the storage request through the load balancing layer, collect the load metrics of each microservices instance at the current moment, and the storage request carries the electronic medical records; Among them, a medical information system can be installed on the server, and this medical information system needs to process a large number of storage requests for electronic medical records (such as patient visit records, inspection reports, etc.). This medical information system is based on a microservices architecture, and this microservices architecture includes a load balancing layer. The load balancing layer is both a traffic scheduling center and a stability cornerstone in the microservices architecture. In addition, as the system entry, the load balancing layer receives all externally initiated electronic medical record storage requests. It can not only achieve performance balance of microservice instances, but also reasonably allocate storage resources for each hardware storage through methods such as weighted round-robin according to the differences in server hardware configurations, achieving reasonable and effective utilization of resources, and ensuring high performance and high availability of the system in high-concurrency and complex scenarios.

[0014] The storage request is, for example, sent by a terminal device to the server and is used to store the electronic medical record from the virtual and physical levels through the server. This storage request carries the electronic medical record, and the electronic medical record includes, for example, structured or unstructured data such as patient ID, diagnosis record, and image data.

[0015] Multiple microservice instances can be deployed in the microservices architecture, and each microservice instance focuses on a specific business. For example, the first microservice instance is used to perform user authentication, the second microservice instance is used to perform product search, and the third microservice instance focuses on performing operations such as writing to the database. Of course, multiple microservice instances can serve each specific business.

[0016] The load metrics of the microservice instance include, for example: CPU utilization, memory usage, incoming traffic, outgoing traffic, number of connections, current queue length, error rate, response time, etc. The load balancing layer can execute the load balancing strategy by collecting any one of the above load metrics, or can collect any two of the above load metrics to execute the load balancing strategy, or can also collect all of the above load metrics to execute the load balancing strategy. This application does not limit this, and just select appropriate load metrics according to the usage scenario.

[0017] Since the load balancing layer needs to allocate microservice instances for the storage request according to the load balancing strategy in order to match a suitable microservice instance for the storage request faster, the load balancing layer can collect the load metrics of each microservice instance at the current moment when accessing the storage request, so as to select a suitable target microservice instance from multiple microservice instances according to the load metrics of each microservice instance to serve this storage request, so as to avoid single-point failures and improve system throughput. Exemplarily, the load balancing layer can collect the load metrics of each microservice instance through collection tools such as Prometheus and OpenTelemetry.

[0018] Step S30: The load balancing layer determines the target microservice instance based on the load metrics of each microservice instance, and allocates the storage request to the target microservice instance; Among them, when the load balancing layer accesses an HTTP POST request carrying electronic medical record data, it can obtain the current load metrics of each microservice instance from a monitoring system (such as Prometheus), and determine the target microservice instance according to the load balancing policy. An example of the use of the load balancing policy is: if the CPU usage rate of instance A is lower than 50%, the new request will be preferentially routed to instance A.

[0019] The load balancing layer can not only dynamically allocate requests according to the load metrics of microservice instances, but also periodically detect the status of each microservice instance, eliminate unavailable microservice instances, ensure that subsequent incoming requests will not be sent to faulty microservice instances, and improve the response efficiency of requests.

[0020] In an optional embodiment, the load balancing layer adjusts the weights of each microservice instance using a dynamic weight adjustment mechanism based on the load metrics of each microservice instance, and selects any microservice instance with a weight lower than a preset threshold as the target microservice instance.

[0021] Among them, the load balancing layer adjusts the weights of each microservice instance using a dynamic weight adjustment mechanism based on the load metrics of each microservice instance, aiming to prevent some microservice instances from crashing due to excessive load, and can preferentially allocate storage requests to microservice instances with lower load, realizing balanced utilization of resources.

[0022] Suppose the microservice instance set is S = (S1, S2, S3, S4, S5), and the initial weight of each microservice instance is 1. After the system runs for a period of time, the load balancing layer uses the dynamic weight adjustment mechanism to adjust the weight of S1 to 2, the weight of S2 to 3, the weight of S3 to 4, the weight of S4 to 5, and the weight of S5 to 6 according to the load metrics of each microservice instance.

[0023] The preset threshold is a set upper limit of the weight (for example, a weight less than 8 is in a healthy state). In this application, microservice instances with weights higher than the preset threshold can be excluded, and these microservice instances are regarded as overloaded or unhealthy. Any microservice instance is selected from the remaining service instances as the target microservice instance. Exemplarily, the microservice instance with the lowest weight can be selected as the target microservice instance, that is, S1.

[0024] Step S40: The target microservice instance calls the microservice layer to parse the electronic medical record and generate a hash key; Among them, the electronic medical record data is huge and complex in structure (such as text, images, tables, numerical values, etc.). It is necessary to standardize and uniquely identify it to ensure the integrity of the data, prevent tampering, and also be able to achieve rapid retrieval of electronic medical records. At this time, it is necessary to locate the electronic medical records through a hash key.

[0025] This application uses the target microservice instance as the business entry point, receives the storage request of the electronic medical record, calls the downstream microservice layer to complete parsing and hash generation, and returns the hash key generated by the microservice layer.

[0026] The microservice architecture also includes a microservice layer, which can split the medical information system into multiple microservices, and each microservice is responsible for a specific functional module, such as format parsing service, data cleaning service, hash generation service, metadata extraction service, etc.

[0027] When the target microservice instance publishes a task (processing electronic medical records) to the message queue, it can call downstream services (such as cleaning and hash services) through RESTAPI, gRPC, etc. for asynchronous consumption processing through the microservice layer, which can decouple services and support high throughput.

[0028] The microservice layer can split the content of the electronic medical record into structured fields through the format parsing service, standardize each diagnosis name in the electronic medical record through the data cleaning service, calculate the hash value of the cleaned data through the hash generation service, and bind the hash key with the patient ID and timestamp through the metadata extraction service and write it into the database.

[0029] This application uses the hash key to uniquely identify the electronic medical record to avoid duplicate storage, and can also prevent the data in the electronic medical record from being tampered with. In addition, directly locating the storage location of the electronic medical record through the hash key can achieve rapid retrieval of the electronic medical record.

[0030] Step S50, the target microservice instance calls the distributed storage layer to map the hash key to the first target virtual node through the consistent hashing algorithm. The first target virtual node is one of the multiple virtual nodes on the hash ring of the distributed storage layer and corresponds to the hash key; Among them, the hash key is obtained through the above microservice layer. After the target microservice instance returns the hash key, further, the target microservice instance calls the distributed storage layer of the microservice architecture to complete the storage of the hash key.

[0031] It should be explained here that the target microservice layer is still responsible for calling the distributed storage layer. The distributed storage layer is responsible for storage. The distributed storage layer includes multiple physical nodes (such as servers), each physical node hosts multiple virtual nodes, and data is distributed to the virtual nodes in the form of hash keys and finally mapped to the physical nodes.

[0032] The hash ring is a logical ring formed by connecting the hash value space end to end (for example, 0 to 2^160 - 1, corresponding to the SHA-1 hash range). Each virtual node occupies a fixed position on the ring through hash calculation. Exemplarily, the hash value of virtual node V1 is A, the hash value of V2 is B, and the hash value of V3 is C, arranged in clockwise order.

[0033] The mapping rule is to calculate the hash value of the hash key, and then, for example, it can be to find the first target virtual node on the hash ring that is greater than or equal to this hash value in the clockwise direction and use it as the storage location of the hash key. Exemplarily, if H(key) = X, and B < X < C, the hash value of virtual node V1 is A, V2 is B, and V3 is C, then the data is mapped to virtual node V3. By setting virtual nodes on the hash ring, the problem of uneven load on physical nodes can be solved, and when a physical node fails, the data responsible for the virtual node will be evenly dispersed to other nodes.

[0034] Specifically, in this application, the hash key can be mapped to the first target virtual node in the following way: The target service instance calls the storage interface of the distributed storage layer, performs a secondary hash on the hash key through the distributed storage layer to obtain a hash value, and finally finds, for example, the virtual node on the hash ring that is the first to be greater than or equal to the hash value, and determines this virtual node as the first target virtual node, thus completing the mapped storage of the hash key.

[0035] Step S60, the target microservice instance calls the containerized management layer to collect the real-time load of the physical node bound to the first target virtual node, and the load balancing layer determines the first target physical node according to the real-time load of each physical node, and stores the electronic medical record in the first target physical node.

[0036] Among them, after mapping the hash key to the hash ring through the above steps, the storage of the electronic medical record on the virtual level is completed, but the electronic medical record itself also needs to be stored in the physical node (i.e., the memory space of the server) to complete the storage of the electronic medical record.

[0037] Here, the target microservice instance still actively invokes the containerized management layer interface of the microservice architecture as the business entry to obtain the real-time load of each physical node. The real-time load of each physical node includes, but is not limited to: CPU usage, memory occupancy, disk I / O, latency between nodes, bandwidth utilization, etc. Exemplarily, after the electronic medical record storage request is triggered, the target microservice instance can call the Kubernetes API to obtain the CPU usage of the physical node.

[0038] The containerized management layer uses containerization technologies (such as Docker and Kubernetes) to achieve dynamic scaling and resource management of microservices. The containerization technology provides an isolated running environment for microservices, ensuring the independence and stability of each service instance of the electronic medical record. Through container orchestration tools such as Kubernetes, the medical information system can automatically manage the lifecycle of microservices, including operations such as deployment, scaling, update, and rollback. The containerized management layer is also used to manage the binding relationship between virtual nodes and physical nodes and provide a physical node resource monitoring interface.

[0039] The load balancing layer can not only dynamically allocate microservice instances for each request through load balancing strategies, but also determine the first target physical node for storing electronic medical records through load balancing strategies. The load balancing layer realizes balanced physical storage through a decision-making algorithm. Among them, the decision-making algorithm is, for example: a physical node with a lower load obtains a higher weight, and a physical node with a higher weight is selected for storage; the node with the fewest current active requests is selected to avoid single-point overload, etc. Of course, no matter through what decision-making algorithm, generally a physical node with less real-time load will be selected as the first target physical node for electronic medical record storage, which will not be elaborated here.

[0040] In an optional embodiment, as Figure 3 shown, Figure 3 FIG. is a flowchart of steps for determining the first target virtual node in an exemplary embodiment of the present application. The step process includes the following: Step S301, calculating a first hash value of the hash key through a consistent hashing algorithm; Among them, the consistent hashing algorithm is used to evenly map data and storage nodes onto a hash ring during distributed storage, reducing the amount of data migration when nodes are added or removed. Compared with traditional hashing, when the consistent hashing algorithm performs data migration, only the data of adjacent virtual nodes is affected, significantly reducing the migration amount. The consistent hashing algorithm can select hash functions such as SHA-1 (160 bits), SHA-256 (256 bits), MD5 (128 bits), etc. to calculate the first hash value. Many common hash functions (such as MD5, SHA-1, etc.) output hash values of 128 bits or longer. In this application, in the consistent hashing algorithm, a smaller range will be selected to represent the hash value. For example, 32 bits. The 32-bit hash value range can provide sufficient precision and uniformity, while the calculation and storage costs are relatively low. Selecting a 32-bit hash value range can ensure that there is enough space on the hash ring to evenly distribute virtual nodes and data, while avoiding too high a probability of hash collisions.

[0041] The first hash value is used to distinguish from the second hash value and is obtained by calculating the above hash key through the consistent hashing algorithm, and is used to determine the logical position of the electronic medical record on the hash ring.

[0042] Step S302, calculate the hash values of each virtual node through the consistent hashing algorithm to obtain the second hash value corresponding to each virtual node; Among them, calculating the hash values of each virtual node through the consistent hashing algorithm is to map the virtual nodes (logical storage spaces) onto the hash ring to form evenly distributed node positions.

[0043] Each physical node corresponds to multiple virtual nodes (such as 1000). The hash value is calculated through the consistent hashing algorithm for the identifier of the virtual node (such as physical node IP + serial number) by using a hash function to obtain the second hash value corresponding to each virtual node. It should be noted here that the second hash values of all virtual nodes are arranged in a certain sequence (such as ascending order) to form a hash ring.

[0044] Step S303, select the second hash value closest to the first hash value from each second hash value as the target second hash value, and determine the virtual node corresponding to the target second hash value as the first target virtual node.

[0045] Among them, after obtaining the first hash value and multiple second hash values through the above method, the method for determining the first target virtual node by comparing the first hash value and the second hash value can include: finding the first virtual node greater than or equal to the first hash value as the first target virtual node. If the first hash value exceeds the largest second hash value in the hash ring, the starting point of the hash ring can be returned and used as the first target virtual node.

[0046] In this application, the mapping relationship between data and storage nodes is optimized from hard coding to a dynamic ring logical structure through the consistent hashing algorithm, achieving high scalability and load balancing.

[0047] In an alternative embodiment, the second hash values of the respective virtual nodes may also be pre-stored in a hash value list. After calculating the first hash value, it may be directly matched with the hash value list to determine the target second hash value and the first target virtual node, thus avoiding the step of calculating the hash values of the virtual nodes and improving the efficiency of determining the first target virtual node.

[0048] In an alternative embodiment, as Figure 4 shown, Figure 4 FIG. is a flowchart of steps for determining a first target physical node in an exemplary embodiment of this application. The steps include the following: Step S401, adjusting the weights of the physical nodes through a dynamic weight adjustment mechanism according to the real-time loads of the physical nodes; Among them, based on the above description, it can be known that the real-time loads of the physical nodes include, for example, CPU utilization rate, memory occupancy rate, bandwidth usage rate, number of TCP connections, disk read / write rate, IOPS, etc. The container management layer may collect one of the loads, or may also collect all the loads in a timely manner as the data support for weight adjustment. This application does not limit this.

[0049] The dynamic weight adjustment mechanism is, for example: high-load nodes obtain higher weights, and low-load nodes obtain lower weights.

[0050] Exemplarily, the initial weight of each physical node is 1. After the medical information system runs for a period of time, the real-time loads of 5 physical nodes bound to the first target virtual node are collected through the container management layer. The weight of the first physical node is adjusted to 7, the weight of the second physical node is adjusted to 6, the weight of the third physical node is adjusted to 8, the weight of the fourth physical node is adjusted to 2, and the weight of the fifth physical node is adjusted to 4.

[0051] Step S402, selecting the physical node with the lowest weight as the first target physical node.

[0052] Among them, based on the above dynamic weight adjustment mechanism, this application may select the physical node with the lowest weight as the first target physical node. Through the dynamic weight adjustment mechanism, load balancing and resource utilization optimization are achieved, and combined with the weight sorting strategy, service stability in high-load scenarios is ensured.

[0053] Exemplarily, assume the initial weight assignment: the weight of each storage node , assuming uniform data distribution, then the initial load of each node is:

[0054] This means that each physical node initially stores 200 electronic medical record data entries.

[0055] Assume that during operation, the load of physical node 1 is too high and its weight needs to be dynamically adjusted. Adjust the weight of physical node 1 to , and keep the weights of other nodes unchanged. At this time, the load of each node is recalculated as follows:

[0056]

[0057] At this time, the load of physical node 1 is too high. Since the weights of other physical nodes are the same, any physical node other than physical node 1 can be selected as the first target physical node.

[0058] In another alternative embodiment, as Figure 5 shown, the present application further includes the following method: Step S501, call the distributed storage layer through the target microservice instance to collect the data volume stored in each virtual node; Among them, the data volume stored in the virtual node is, for example, disk occupancy rate, number of data entries, etc. The target microservice instance queries the data volume stored in each virtual node by calling the API interface provided by the distributed storage layer.

[0059] Step S502, adjust the weights of the virtual nodes based on the data volume stored in each virtual node, and determine the virtual nodes with weights greater than the preset weight as the second target virtual nodes; Among them, the present application can adjust the weights of the virtual nodes by means of positive feedback. For example, increase the weight of the virtual node with a higher data volume to prevent overload, and decrease the weight of the virtual node with a lower data volume to attract new data. Of course, it is also possible to increase the weight of the virtual node with a lower data volume to prevent overload and decrease the weight of the virtual node with a higher data volume to attract new data. The present application does not limit this.

[0060] The present application can also set a data adjustment threshold by setting a preset weight, and this preset weight is used to screen the second target virtual nodes that need to be adjusted. The preset weight can be set according to the application scenario and is not limited here.

[0061] Step S503, allocate part of the data volume on the second target virtual node to other virtual nodes.

[0062] After determining the second target virtual node according to the above method, some data shards (such as by hash range) on the second target virtual node are migrated to other virtual nodes with low load.

[0063] In addition, after completing the data migration, it is also necessary to adjust the mapping relationship of virtual nodes in the hash ring so that new requests are preferentially allocated to virtual nodes with low load.

[0064] Based on the flexible scheduling ability of the microservice architecture, the dynamic mapping mechanism of consistent hashing, and the monitoring and migration interface technology support of the distributed storage layer, this application realizes the automatic load balancing of distributed storage through dynamic weight adjustment and data migration, solves the problem of uneven data distribution, and ensures system stability and resource utilization.

[0065] In another optional embodiment, based on the fact that the containerized management layer has container orchestration tools such as Kubernetes, the system can automatically manage the lifecycle of microservices, including functions such as deployment, scaling, update, and rollback. Therefore, when there is a second target physical storage node whose real-time load of the physical storage node bound to the first target virtual node exceeds the load threshold, the containerized management layer is called through the target microservice instance to add a new virtual node to the second target physical storage node to achieve dynamic expansion of the virtual node, and part of the data volume on the virtual node bound to the second target physical storage node is migrated to the new virtual node, and the resource utilization rate is improved by automatically adjusting the resource allocation.

[0066] It can be understood that after the dynamic expansion of the virtual node is completed based on the above method, the new virtual node needs to be mapped to the hash ring to insert the hash value of the new virtual node into the appropriate position of the hash ring to maintain the orderliness of the hash ring. Here, the hash value of the new virtual node is calculated through the consistent hashing algorithm to complete the operation of mapping the virtual node to the hash ring. That is, the newly added virtual node (logical storage unit) is converted into a logical position on the hash ring through a hash function, providing a basis for subsequent data routing. The implementation method can be: using the hash function specified by the consistent hashing algorithm to calculate the hash value of the unique identifier of the new virtual node to generate an integer with a fixed length.

[0067] In an alternative embodiment, since the containerization management layer is also used to manage the binding relationship between virtual nodes and physical nodes, when the containerization management layer monitors the health status of each physical node and virtual node in real time through components and triggers a scheduling policy when a node is abnormal, that is, when the first target physical node fails or is network-isolated, some of the virtual nodes bound to it may be marked as unavailable and released to release resources by releasing virtual nodes (that is, reducing the number of virtual nodes). If the released virtual nodes are directly taken offline, the data stored on them may be permanently lost due to insufficient replicas. Therefore, migrating to the remaining virtual nodes can ensure that the data can still be accessed and the application can run normally.

[0068] In addition, the containerization management layer can also implement the expansion of microservice instances. In this application, if the load metrics of each microservice instance exceed the preset metric values at the current moment, new microservice instances are added through the containerization management layer, and some requests on each microservice instance are allocated to the new microservice instances. Through the automatic scaling ability of the containerization management layer, elastic computing resource allocation and dynamic balancing of request loads are achieved, ensuring the system stability in high-concurrency scenarios. The containerization management layer can trigger the expansion of microservice instances through the judgment logic that the same metric (such as CPU) of all microservice instances exceeds the preset metric value, avoiding mis-expansion caused by the abnormality of a single microservice instance. Exemplarily, the containerization management layer automatically increases the number of Pod replicas through the Kubernetes tool. When a new microservice instance starts, it pulls the image from the container image repository, mounts the storage volume, and confirms the service readiness through the Readiness Probe, and schedules the new microservice instance to a suitable node according to the preset resource constraints (such as CPURequest / Limit).

[0069] In an alternative embodiment, as Figure 6 shown, Figure 6 the steps for generating a hash key provided by the embodiment of this application are as follows: Step S601, the target microservice instance calls the microservice layer to parse the electronic medical record to obtain the unique identifier of the target object associated with the electronic medical record; Among them, parsing the electronic medical record is to call the natural language processing (NLP) component or pre-trained model (such as BERT) of the microservice layer by the microservice layer to perform semantic analysis on the unstructured electronic medical record text and extract keyword fields such as patient basic information and diagnosis records.

[0070] Furthermore, the globally unique ID allocated within the system for identifying the patient (such as the ID card number, medical insurance number, etc.) is obtained as the unique identifier of the target object associated with the electronic medical record.

[0071] Step S602: Generate a hash key based on the unique identifier of the target object associated with the electronic medical record.

[0072] Among them, the design of the hash key is used to quickly locate the shard or physical node where the data of the target object is located in the distributed storage. In addition, the hash operation can also desensitize the unique identifier of the sensitive target object, improving the security of data storage.

[0073] This application realizes the efficient retrieval, privacy compliance, and high-performance access of electronic medical records through the standardized parsing and hash key generation of electronic medical records.

[0074] A distributed storage method for electronic medical records based on the hash algorithm provided by this application takes into account the problems existing in the current way of storing electronic medical records, such as poor resource utilization, inability to scale on demand, high construction and maintenance costs, bottlenecks in storage I / O when processing a large number of concurrent requests, and performance degradation caused by data redistribution. This application provides a distributed storage method for electronic medical records based on the hash algorithm. This method is based on the microservice architecture. When the load balancer layer in the microservice architecture accesses the storage request for storing electronic medical records, it allocates a suitable microservice instance for the electronic medical record to be stored according to the load metrics of each microservice instance at the current moment to optimize the load distribution of the microservice architecture and reduce the overload and resource waste of microservice instances; after the target microservice instance is allocated for the storage request through the load balancer layer, the target microservice instance calls the microservice layer and the distributed storage layer to store the electronic medical record on the hash ring of the distributed storage layer through the consistent hash algorithm to ensure the uniform distribution and high availability of data. Finally, the target microservice instance will also collect the real-time load of the physical storage node bound to the first target virtual node for storing the electronic medical record through the container management layer, and the load balancer layer determines the first target physical node to store the electronic medical record according to the real-time load of each physical node to achieve the uniform storage of data and improve the storage efficiency, thereby improving the flexibility, availability, and data processing ability of the storage system.

[0075] The following combines Figure 7 to give an overall exemplary description of the distributed storage method for electronic medical records based on the hash algorithm provided by this application.

[0076] The distributed storage method for electronic medical records based on the hash algorithm provided by this application depends on the microservice architecture, which includes a distributed storage layer, a microservice layer, a load balancer layer, and a container management layer.

[0077] Among them, the distributed storage layer uses the consistent hashing algorithm to evenly distribute electronic medical records to multiple storage nodes. The specific implementation method is as follows: under the call of the microservice instance, the distributed storage layer performs secondary hashing on the hash key of the electronic medical record to obtain a hash value, and finally finds the virtual node that is, for example, the first virtual node greater than or equal to the hash value on the hash ring, and determines the virtual node as the first target virtual node, that is, completes the mapped storage of the hash key.

[0078] The microservice layer splits the electronic medical record system (that is, the above-mentioned medical information system) into multiple microservices, and each microservice instance is responsible for a specific function module, such as patient information management, medical record document storage, imaging data processing, etc. When the target microservice instance calls the microservice layer, it can perform the operation of parsing the electronic medical record to generate a hash key through one of the microservices. In addition, when the microservice layer starts, it registers with the service registry and realizes service discovery through the consistent hashing algorithm. The service registry maintains the instance information and location information of all microservices, and the client can obtain the address of the required microservice through the service registry.

[0079] The load balancing layer is used to access storage requests, and based on the load metrics of each microservice instance, adjusts the weights of each microservice instance through the consistent hashing algorithm combined with the dynamic weight adjustment mechanism, so as to determine the target microservice instance from multiple microservice instances, and call the microservice layer through the target microservice instance, thereby realizing the efficient allocation of storage requests. The specific implementation method is as follows: the load balancing layer adjusts the weights of each microservice instance by using the dynamic weight adjustment mechanism according to the load metrics of each microservice instance, and selects any microservice instance with a weight lower than the preset threshold as the target microservice instance.

[0080] The containerized management layer uses containerization technology to realize the dynamic expansion and resource management of microservices. The containerization technology provides an isolated running environment for microservices, ensuring the independence and stability of each service instance of the electronic medical record. Through container orchestration tools such as Kubernetes, the system can automatically manage the life cycle of microservices, including operations such as deployment, expansion, update, and rollback. When the system detects that the load of a certain microservice instance is too high, it can automatically start a new microservice instance and migrate part of the data to the new microservice instance through the consistent hashing algorithm, thereby realizing the dynamic expansion of the system. In addition, the containerized management layer can also automatically adjust the resource allocation of each microservice instance according to the overall load situation of the system, improving the resource utilization rate of the system. The technical solution of this application not only solves the challenges of existing electronic medical record systems in aspects such as high-concurrency access, data consistency, dynamic expansion, and load balancing, but also realizes the high efficiency, security, and scalability of the system through the combination of the consistent hashing algorithm and the microservices architecture. This innovative solution provides new ideas and technical support for the electronic medical record management of smart hospitals, and has broad application prospects and important practical significance.

[0081] It should be noted that although the operations of the method of the present invention are described in a specific order in the drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the order of execution of the steps depicted in the flowchart can be changed.

[0082] The above description is only a preferred embodiment of this application and an explanation of the applied technical principles. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solution formed by the specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the inventive concept. For example, the technical solutions formed by mutually replacing the above features with the (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A distributed storage method for electronic medical records based on a hash algorithm, characterized in that, The method is applied to a microservice architecture, which includes a distributed storage layer, a microservice layer, a load balancing layer, and a containerization management layer. The method includes: Accessing a storage request through the load balancing layer, and collecting the load metrics of each microservice instance at the current moment. The storage request carries an electronic medical record; The load balancing layer determines a target microservice instance according to the load metrics of each microservice instance, and allocates the storage request to the target microservice instance; Calling the microservice layer through the target microservice instance to parse the electronic medical record and generate a hash key; Calling the distributed storage layer through the target microservice instance to map the hash key to a first target virtual node through a consistent hashing algorithm. The first target virtual node is one of multiple virtual nodes on the hash ring of the distributed storage layer and corresponds to the hash key; Calling the containerization management layer through the target microservice instance to collect the real-time load of the physical node bound to the first target virtual node. The load balancing layer determines a first target physical node according to the real-time load of each physical node, and stores the electronic medical record on the first target physical node.

2. The method according to claim 1, wherein The load balancing layer determines a target microservice instance according to the load metrics of each microservice instance, including: The load balancing layer adjusts the weights of each microservice instance by using a dynamic weight adjustment mechanism according to the load metrics of each microservice instance, and selects any microservice instance with a weight lower than a preset threshold as the target microservice instance.

3. The method according to claim 1, wherein Determining the first target virtual node corresponding to the hash key from multiple virtual nodes on the hash ring, including: Calculating a first hash value of the hash key through the consistent hashing algorithm; Calculating the hash values of each virtual node through the consistent hashing algorithm to obtain second hash values corresponding to each virtual node; Selecting, from each of the second hash values, the second hash value that is the first to be greater than or equal to the first hash value as the target second hash value, and determining the virtual node corresponding to the target second hash value as the first target virtual node.

4. The method according to claim 1, characterized in that, Determining the first target physical node through the load balancing layer according to the real-time load of each physical node, including: Adjusting the weights of each physical node through a dynamic weight adjustment mechanism according to the real-time load of each physical node; Selecting the physical node with the lowest weight as the first target physical node.

5. The method according to claim 1, wherein The method further includes: Calling the distributed storage layer through the target microservice instance to collect the data volume stored in each virtual node; Adjusting the weights of each virtual node based on the data volume stored in each virtual node, and determining the virtual nodes with weights greater than a preset weight as second target virtual nodes; Allocating a part of the data volume on the second target virtual node to other virtual nodes.

6. The method according to claim 1, characterized in that, The method further includes: When there is a second target physical storage node whose real-time load of the physical storage node bound to the first target virtual node exceeds the load threshold, the target microservice instance calls the containerized management layer to add a new virtual node to the second target physical storage node, and migrates a part of the data volume on the virtual node bound to the second target physical storage node to the new virtual node.

7. The method according to claim 6, wherein The method further includes: Calculating the hash values of the new virtual nodes through the consistent hashing algorithm, and mapping the new virtual nodes to the hash ring.

8. The method according to claim 1, wherein The method further includes: If it is monitored by the containerized management layer that the number of virtual nodes bound to the first target physical node decreases, the data volume on the released virtual node is migrated to the remaining virtual nodes bound to the first target physical node.

9. The method according to claim 1, wherein The method further includes: If the load metrics of all the microservice instances at the current moment exceed the preset metric values, the containerized management layer adds new microservice instances, and allocates a part of the requests on each microservice instance to the new microservice instances.

10. The method according to claim 1, wherein The step of the target microservice instance calling the microservice layer to parse the electronic medical record and generate a hash key includes: The target microservice instance calls the microservice layer to parse the electronic medical record to obtain the unique identifier of the target object associated with the electronic medical record; Generating the hash key according to the unique identifier of the target object associated with the electronic medical record.

Images