Distributed storage method of electronic medical records based on hash algorithm

Abstract

The present application discloses a distributed storage method for electronic medical records based on a hash algorithm. The method is based on a microservice architecture. The method receives storage requests through a load balancing layer in the microservice architecture and allocates microservice instances to electronic medical records according to the load indicators of each microservice instance at the current moment, so as to optimize the load distribution of the microservice architecture and reduce the overload and resource waste of the microservice instances. Then, the electronic medical records are stored in the hash ring of the distributed storage layer through the microservice layer and the distributed storage layer to ensure uniform distribution and high availability of data. Finally, the real-time load of the physical storage node bound to the first target virtual node is collected through the containerized management layer. The load balancing layer determines the first target physical node to store the electronic medical record according to the real-time load of each physical node, so as to achieve uniform storage of data and improve storage efficiency, thereby improving the flexibility, availability and data processing capability of the storage system.

Description

Technical Field

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

[0002] Electronic medical record systems are a core component of healthcare informatization. With the rapid development of healthcare informatization, these systems need to process massive amounts of data, including medical records, imaging materials, and test reports. Furthermore, with the expansion of hospital services and the increase in the number of patients, electronic medical record systems need to support high-concurrency access, posing a pressing challenge in storing electronic medical records.

[0003] Currently, common methods of storing electronic medical records include centralized storage and distributed storage. However, centralized storage has poor resource utilization, cannot be expanded on demand, has high construction and maintenance costs, and has storage I / O bottlenecks when processing a large number of concurrent requests. Although distributed storage can solve some of the problems brought about by centralized storage, its data redistribution when nodes change dynamically can lead to performance degradation.

[0004] In the face of the above problems, a new storage method is needed to store electronic medical records so that it can improve the system's flexibility, availability and data processing capabilities. Summary of the Invention

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

[0006] In a first aspect, a method for distributed storage of electronic medical records based on a hash algorithm is provided. The method is applied to a microservice architecture, wherein the microservice architecture includes a distributed storage layer, a microservice layer, a load balancing layer, and a containerized management layer. The method includes:

[0007] Accessing storage requests through the load balancing layer to collect the load indicators of each microservice instance at the current moment, wherein the storage requests carry electronic medical records;

[0008] The load balancing layer determines the target microservice instance according to the load index of each microservice instance, and distributes the storage request to the target microservice instance;

[0009] The target microservice instance calls the microservice layer to parse the electronic medical record and generate a hash key;

[0010] The target microservice instance calls the distributed storage layer to map the hash key to the hash ring of the distributed storage layer through a consistent hashing algorithm, and determines a first target virtual node corresponding to the hash key from multiple virtual nodes on the hash ring;

[0011] The target microservice instance calls the containerized management layer to collect the real-time load of the physical storage node bound to the first target virtual node, selects the physical storage node with the smallest real-time load as the first target physical storage node, and stores the electronic medical record in the first target physical storage node.

[0012] This application provides a distributed storage method for electronic medical records based on a hash algorithm. This method takes into account the problems of current methods of storing electronic medical records, such as poor resource utilization, inability to expand on demand, high construction and maintenance costs, storage I / O bottlenecks when processing a large number of concurrent requests, and data redistribution leading to performance degradation. The present application provides a distributed storage method for electronic medical records based on a hash algorithm. The method is based on a microservice architecture. When a storage request for storing electronic medical records is received through the load balancing layer in the microservice architecture, the load index of each microservice instance at the current moment is used to allocate a suitable microservice instance to the electronic medical record to be stored, so as to optimize the load distribution of the microservice architecture and reduce the overload and resource waste of the microservice instance. After the target microservice instance is allocated to 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 hashing algorithm, so as to ensure 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 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 to achieve uniform storage of data and improve storage efficiency, thereby improving the flexibility, availability and data processing capability of the storage system. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Other features, objects and advantages of the present application will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0014] Figure 1 This is an application scenario diagram of a distributed storage method for electronic medical records based on a hash algorithm provided in this application;

[0015] Figure 2 A flowchart of a distributed storage method for electronic medical records based on a hash algorithm provided in this application;

[0016] Figure 3A flowchart of the steps of a distributed storage method for electronic medical records based on a hash algorithm provided in this application;

[0017] Figure 4 A flowchart of the steps of a distributed storage method for electronic medical records based on a hash algorithm provided in this application;

[0018] Figure 5 A flowchart of the steps of a distributed storage method for electronic medical records based on a hash algorithm provided in this application;

[0019] Figure 6 A flowchart of the steps of a distributed storage method for electronic medical records based on a hash algorithm provided in this application;

[0020] Figure 7 This is a system architecture diagram of a distributed storage method for electronic medical records based on a hash algorithm provided in this application. DETAILED DESCRIPTION

[0021] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the invention are shown in the accompanying drawings.

[0022] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0023] Please refer to Figure 1 , Figure 1 This application provides an application scenario diagram of a distributed storage method for electronic medical records based on a hash algorithm. The application scenario diagram includes a server 100 and a server cluster 200. The server 100 is equipped with a microservice architecture. The microservice architecture includes a distributed storage layer, a microservice layer, a load balancing layer, and a containerized management layer. The server 100 maps the electronic medical records to be stored to the hash ring set thereon through the microservice architecture to ensure uniform distribution and high availability of data. In addition, the load balancing processing of the microservice architecture is used to store the electronic medical records to be stored on the server with the smallest load in the server cluster 200, thereby realizing the storage of the electronic medical records to be stored.

[0024] Below, the distributed storage method of electronic medical records based on the hash algorithm provided by this application is described.

[0025] like Figure 2 As shown, Figure 2This is a flowchart of the steps of a distributed storage method for electronic medical records based on a hash algorithm provided in this application. The method is described by taking the microservice architecture of the above-mentioned server as an example, wherein the microservice architecture includes a distributed storage layer, a microservice layer, a load balancing layer, and a containerized management layer. The method includes:

[0026] Step S20: Access the storage request through the load balancing layer, collect the load indicators of each microservice instance at the current moment, and the storage request carries the electronic medical record;

[0027] The server may be equipped with a medical information system that handles a large number of electronic medical record storage requests (such as patient visit records and examination reports). This medical information system is based on a microservices architecture, which includes a load balancing layer. This layer serves as both a traffic dispatching center and a cornerstone of stability. Furthermore, this load balancing layer serves as the system entry point, receiving all externally initiated electronic medical record storage requests. This layer not only ensures performance balancing among microservice instances but also rationally allocates storage resources to each hardware storage based on differences in server hardware configuration, for example through weighted round-robin. This ensures efficient and effective resource utilization and ensures high performance and availability in high-concurrency and complex scenarios.

[0028] A storage request, for example, is a request sent by a terminal device to a server to store electronic medical records at both a virtual and physical level. The storage request carries the electronic medical records, which may include structured or unstructured data such as patient ID, diagnosis records, and imaging data.

[0029] In a microservices architecture, multiple microservice instances can be deployed, each focusing on a specific business. For example, the first microservice instance can be used to perform user authentication, the second microservice instance can be used to perform product search, and the third microservice instance can be used to perform database write operations. Of course, each specific business can have multiple microservice instances serving it.

[0030] Load metrics for microservice instances include, for example, CPU utilization, memory usage, ingress traffic, egress traffic, number of connections, current queue length, error rate, response time, etc. The load balancing layer can collect only one of these load metrics to implement a load balancing strategy, or it can collect any two of these load metrics to implement a load balancing strategy, or it can collect all of these load metrics to implement a load balancing strategy. This application does not limit this, and you can select the appropriate load metric based on the usage scenario.

[0031] Because the load balancing layer needs to allocate microservice instances to storage requests based on the load balancing strategy to more quickly match storage requests with appropriate microservice instances, the load balancing layer can collect the load metrics of each microservice instance at the current moment when receiving a storage request. Based on the load metrics of each microservice instance, the load balancing layer selects the appropriate target microservice instance from multiple microservice instances to serve the storage request, thereby avoiding single points of failure and improving system throughput. For example, the load balancing layer can collect the load metrics of each microservice instance using collection tools such as Prometheus and OpenTelemetry.

[0032] Step S30: The load balancing layer determines the target microservice instance based on the load indicators of each microservice instance and distributes the storage request to the target microservice instance;

[0033] Among them, the load balancing layer can obtain the current load indicators of each microservice instance from the monitoring system (such as Prometheus) when receiving an HTTP POST request carrying electronic medical record data, and determine the target microservice instance based on the load balancing strategy. An example of using the load balancing strategy is: if the CPU utilization rate of instance A is less than 50%, the new request will be routed to instance A first.

[0034] The load balancing layer can not only dynamically distribute requests based on the load indicators of the microservice instances, but also regularly detect the status of each microservice instance, eliminate unavailable microservice instances, and ensure that subsequent access requests will not be sent to the faulty microservice instances, thereby improving the response efficiency of requests.

[0035] In an optional embodiment, the load balancing layer adjusts the weight of each microservice instance using a dynamic weight adjustment mechanism according to the load index of each microservice instance, and selects any microservice instance whose weight is lower than a preset threshold as the target microservice instance.

[0036] Among them, the load balancing layer uses a dynamic weight adjustment mechanism to adjust the weight of each microservice instance according to the load indicators of each microservice instance. The purpose is to prevent some microservice instances from crashing due to excessive load, and to prioritize storage requests to microservice instances with lower load to achieve balanced resource utilization.

[0037] Assume that the set of microservice instances 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 a 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 based on the load indicators of each microservice instance.

[0038] The preset threshold is a set weight upper limit (for example, a weight less than 8 is a healthy state). This application can be to exclude microservice instances with weights higher than the preset threshold, regard these microservice instances as overloaded or unhealthy, and select any one microservice instance from the remaining service instances as the target microservice instance. For example, the microservice instance with the lowest weight can be selected as the target microservice instance, that is, S1.

[0039] Step S40, calling the microservice layer through the target microservice instance to parse the electronic medical record and generate a hash key;

[0040] Electronic medical records (EMRs) are large and complex in structure (including text, images, tables, and numerical values). They need to be standardized and uniquely identified to ensure data integrity and prevent tampering. They also need to enable rapid retrieval of EMRs. This is where hash keys come in handy for locating EMRs.

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

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

[0043] 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 hashing services) through REST API, gRPC, etc. for asynchronous consumption processing through the microservice layer. This can decouple the services and support high throughput.

[0044] The microservice layer can split the content of the electronic medical record into structured fields through the format parsing service, standardize the diagnosis names 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 to the database.

[0045] This application uses hash keys to uniquely identify electronic medical records to avoid duplicate storage, and can also prevent data in electronic medical records from being tampered with. In addition, by directly locating the storage location of electronic medical records through hash keys, rapid retrieval of electronic medical records can be achieved.

[0046] Step S50: The target microservice instance invokes the distributed storage layer to map the hash key to a 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.

[0047] Specifically, the hash key is obtained through the above microservice layer. After the target microservice instance returns the hash key, further, the target microservice instance invokes the distributed storage layer of the microservice architecture to complete the storage of the hash key.

[0048] Here, it needs to be explained that the target microservice layer is still responsible for invoking 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 bears multiple virtual nodes, and data is distributed to the virtual nodes in the form of hash keys and finally mapped to the physical nodes.

[0049] 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.

[0050] The mapping rule is to calculate the hash value of the hash key, and then, for example, find the first virtual node on the hash ring that is greater than or equal to this hash value in clockwise order 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 of 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.

[0051] Specifically, in this application, the hash key can be mapped to the first target virtual node in the following way: The target service instance invokes the storage interface of the distributed storage layer, performs secondary hashing 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.

[0052] Step S60: The target microservice instance invokes 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 to the first target physical node.

[0053] Among them, after mapping the hash key to the hash ring through the above steps, the storage of electronic medical records from the virtual layer is completed. However, the electronic medical record itself still needs to be stored on the physical node (that is, the memory space of the server) to complete the storage of the electronic medical record.

[0054] Here, the target microservice instance still serves as the service entry point, actively calling the microservice architecture's containerized management layer interface to obtain the real-time load of each physical node. This real-time load includes, but is not limited to, CPU usage, memory usage, disk I / O, inter-node latency, and bandwidth utilization. For example, the target microservice instance might call the Kubernetes API to obtain the CPU usage of a physical node after a request to store an electronic medical record is triggered.

[0055] The containerized management layer leverages containerization technologies (such as Docker and Kubernetes) to enable dynamic scaling and resource management for microservices. Containerization provides an isolated operating environment for microservices, ensuring the independence and stability of each EMR service instance. Using container orchestration tools like Kubernetes, the medical information system can automatically manage the microservice lifecycle, including deployment, scaling, updates, and rollbacks. The containerized management layer also manages the binding between virtual nodes and physical nodes and provides an interface for monitoring physical node resources.

[0056] The load balancing layer not only dynamically assigns microservice instances to individual requests through load balancing strategies, but also determines the primary physical node for electronic medical record storage. The load balancing layer achieves balanced physical storage through decision-making algorithms. These algorithms may include: giving lower-load nodes higher weights, selecting high-weighted physical nodes for storage; selecting nodes with the fewest active requests to avoid single point overload. Regardless of the decision-making algorithm, physical nodes with the least real-time load are generally selected as the primary physical node for electronic medical record storage, which will not be discussed here.

[0057] In an optional embodiment, if Figure 3 As shown, Figure 3 This is a flowchart of the steps for determining the first target virtual node according to an exemplary embodiment of the present application. The steps include the following:

[0058] Step S301, calculating a first hash value of a hash key using a consistent hashing algorithm;

[0059] The consistent hashing algorithm is used to evenly map data and storage nodes onto a hash ring in distributed storage, reducing the amount of data migration when nodes are added or removed. Compared to traditional hashing, the consistent hashing algorithm only affects data from adjacent virtual nodes during data migration, significantly reducing the amount of migration. The consistent hashing algorithm can use hash functions such as SHA-1 (160 bits), SHA-256 (256 bits), and MD5 (128 bits) to calculate the first hash value. Many common hash functions (such as MD5 and SHA-1) output hash values ​​of 128 bits or longer. In this application, the consistent hashing algorithm uses a smaller range, such as 32 bits, to represent hash values. A 32-bit hash value range provides sufficient accuracy and uniformity, while also reducing computational and storage costs. Selecting a 32-bit hash value range ensures sufficient space on the hash ring to evenly distribute virtual nodes and data, while also reducing the probability of hash collisions.

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

[0061] Step S302: Calculate the hash value of each virtual node using a consistent hashing algorithm to obtain a second hash value corresponding to each virtual node;

[0062] Among them, calculating the hash value of each virtual node through the consistent hashing algorithm is to map the virtual node (logical storage space) to the hash ring to form a uniformly distributed node position.

[0063] Each physical node corresponds to multiple virtual nodes (e.g., 1,000). A consistent hashing algorithm is used to calculate the hash value of the virtual node identifier (e.g., the physical node IP address + serial number) using a hash function to obtain the corresponding second hash value for each virtual node. It should be noted that the second hash values ​​of the virtual nodes are arranged in a certain sequence (e.g., ascending order), forming a hash ring.

[0064] Step S303 : Select a second hash value closest to the first hash value from each second hash value as a target second hash value, and determine a virtual node corresponding to the target second hash value as a first target virtual node.

[0065] Among them, after obtaining the first hash value and multiple second hash values ​​through the above method, the method of continuing to determine the first target virtual node by comparing the first hash value and the second hash value may 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, then returning to the starting point of the hash ring and taking the starting point as the first target virtual node.

[0066] This application uses a consistent hashing algorithm to optimize the mapping relationship between data and storage nodes from hard-coded to a dynamic ring logical structure, achieving high scalability and load balancing.

[0067] In an optional embodiment, the second hash value of each virtual node can also be pre-stored in a hash value list. After the first hash value is calculated, it can be directly matched with the hash value list to determine the target second hash value and the first target virtual node. This can avoid the step of calculating the hash value of each virtual node and improve the efficiency of determining the first target virtual node.

[0068] In an optional embodiment, if Figure 4 As shown, Figure 4 This is a flowchart of the steps for determining the first target physical node according to an exemplary embodiment of the present application. The steps include the following:

[0069] Step S401, adjusting the weight of each physical node through a dynamic weight adjustment mechanism according to the real-time load of each physical node;

[0070] Based on the above description, the real-time load of the physical node includes, for example, CPU utilization, memory occupancy, bandwidth usage, number of TCP connections, disk read / write rate, IOPS, etc. The containerized management layer can collect one of the loads or all of the loads in a timely manner as data support for weight adjustment, which is not limited in this application.

[0071] The dynamic weight adjustment mechanism is, for example, that high-load nodes receive higher weights, and low-load nodes receive lower weights.

[0072] For example, the initial weight of each physical node is 1. After the medical information system has been running for a period of time, the real-time load of the five physical nodes bound to the first target virtual node is collected through the containerization management layer, and 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.

[0073] Step S402: Select the physical node with the lowest weight as the first target physical node.

[0074] Based on the above dynamic weight adjustment mechanism, this application can select the physical node with the lowest weight as the first target physical node. The dynamic weight adjustment mechanism achieves load balancing and resource utilization optimization, and combines the weight sorting strategy to ensure service stability in high-load scenarios.

[0075] For example, assuming the initial weight distribution: the weight of each storage node , assuming that the data is evenly distributed, the initial load of each node is for:

[0076]

[0077] This means that each physical node initially stores 200 pieces of electronic medical record data.

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

[0079]

[0080]

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

[0082] In another optional embodiment, Figure 5 As shown, this application also includes the following methods:

[0083] Step S501: Calling the distributed storage layer through the target microservice instance to collect the amount of data stored in each virtual node;

[0084] The amount of data stored in the virtual node is, for example, disk occupancy, number of data entries, etc. The target microservice instance queries the amount of data stored in each virtual node by calling the API interface provided by the distributed storage layer.

[0085] Step S502: adjusting the weight of each virtual node based on the amount of data stored in each virtual node, and determining a virtual node with a weight greater than a preset weight as a second target virtual node;

[0086] Among them, the present application may adjust the weight of each virtual node through a positive feedback method, for example, the weight of the virtual node with a higher data volume is increased to prevent overload, and the weight of the virtual node with a lower data volume is reduced to attract new data. Of course, the weight of the virtual node with a lower data volume can also be increased to prevent overload, and the weight of the virtual node with a higher data volume can be reduced to attract new data, and this application is not limited to this.

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

[0088] Step S503: distribute part of the data on the second target virtual node to other virtual nodes.

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

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

[0091] This application is based on the flexible scheduling capabilities of the microservice architecture, the dynamic mapping mechanism of consistent hashing, and the monitoring and migration interface technology support of the distributed storage layer. Through dynamic weight adjustment and data migration, it realizes automatic load balancing of distributed storage, solves the problem of uneven data distribution, and ensures system stability and resource utilization.

[0092] In another optional embodiment, based on the containerized management layer's ability to leverage container orchestration tools such as Kubernetes, the system can automatically manage the microservice lifecycle, including deployment, scaling, updates, and rollback functions. Therefore, when the real-time load of the physical storage node bound to the first target virtual node exceeds a load threshold for a second target physical storage node, the target microservice instance invokes the containerized management layer to add a new virtual node to the second target physical storage node, thereby dynamically scaling the virtual nodes. The system also migrates some of the data on the virtual node bound to the second target physical storage node to the new virtual node, automatically adjusting resource allocation to improve resource utilization.

[0093] It's understandable that after dynamically expanding virtual nodes using the aforementioned method, the new virtual node needs to be mapped to the hash ring to insert its hash value into the appropriate position within the ring and maintain order. Here, the consistent hashing algorithm is used to calculate the hash value of the new virtual node, completing the mapping of the virtual node to the hash ring. In other words, the newly added virtual node (logical storage unit) is converted to a logical location on the hash ring using a hash function, providing a basis for subsequent data routing. This can be achieved by computing a hash value on the unique identifier of the new virtual node using the hash function specified by the consistent hashing algorithm to generate a fixed-length integer.

[0094] In an optional embodiment, since the containerized management layer is also used to manage the binding relationship between virtual nodes and physical nodes, when the containerized management layer monitors the health status of each physical node and virtual node in real time through components and triggers the scheduling policy when the node is abnormal, that is, when the first target physical node goes down 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 node is directly taken offline, the data stored in it may be permanently lost due to insufficient copies, so by migrating to the remaining virtual nodes, it can be ensured that the data can still be accessed and the normal operation of the application can be maintained.

[0095] The containerized management layer can also scale microservice instances. For example, if the load metrics of all microservice instances exceed a preset value, the containerized management layer adds a new microservice instance and allocates some requests from each microservice instance to the new microservice instance. The containerized management layer's automatic scaling capabilities enable elastic computing resource allocation and dynamic balancing of request load, ensuring system stability in high-concurrency scenarios. The containerized management layer can trigger scaling microservice instances based on logic that determines if a single metric (e.g., CPU) exceeds a preset value for all microservice instances, preventing erroneous scaling caused by a single microservice instance failure. For example, the containerized management layer automatically increases the number of pod replicas using Kubernetes tools. When a new microservice instance starts, it pulls images from the container image repository, mounts storage volumes, confirms service readiness using a readiness probe, and schedules the new microservice instance to an appropriate node based on preset resource constraints (e.g., CPU Request / Limit).

[0096] In an optional embodiment, if Figure 6 As shown, Figure 6 The steps for generating a hash key provided in the embodiment of this application are:

[0097] Step S601: The target microservice instance calls the microservice layer to parse the electronic medical record and obtain the unique identifier of the target object associated with the electronic medical record;

[0098] Among them, the electronic medical record is parsed by the microservice layer calling the natural language processing (NLP) component or pre-trained model (such as BERT) of the microservice layer to perform semantic analysis on the unstructured electronic medical record text and extract key fields such as patient basic information and diagnosis records.

[0099] Furthermore, a globally unique ID (eg, ID card number, medical insurance number, etc.) assigned within the system to identify the patient is obtained as a unique identifier of the target object associated with the electronic medical record.

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

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

[0102] This application achieves efficient retrieval, privacy compliance, and high-performance access to electronic medical records by performing standardized parsing and hash key generation on electronic medical records.

[0103] This application provides a distributed storage method for electronic medical records based on a hash algorithm. This method takes into account the problems of current methods of storing electronic medical records, such as poor resource utilization, inability to expand on demand, high construction and maintenance costs, storage I / O bottlenecks when processing a large number of concurrent requests, and data redistribution leading to performance degradation. The present application provides a distributed storage method for electronic medical records based on a hash algorithm. The method is based on a microservice architecture. When a storage request for storing electronic medical records is received through the load balancing layer in the microservice architecture, the load index of each microservice instance at the current moment is used to allocate a suitable microservice instance to the electronic medical record to be stored, so as to optimize the load distribution of the microservice architecture and reduce the overload and resource waste of the microservice instance. After the target microservice instance is allocated to 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 hashing algorithm, so as to ensure 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 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 to achieve uniform storage of data and improve storage efficiency, thereby improving the flexibility, availability and data processing capability of the storage system.

[0104] The following combination Figure 7 An overall exemplary description of a distributed storage method for electronic medical records based on a hash algorithm provided in this application is provided.

[0105] The distributed storage method for electronic medical records based on a hash algorithm provided in this application relies on a microservice architecture, which includes a distributed storage layer, a microservice layer, a load balancing layer, and a containerized management layer.

[0106] The distributed storage layer uses a consistent hashing algorithm to evenly distribute electronic medical records across multiple storage nodes. Specifically, when called by a microservice instance, the distributed storage layer performs a secondary hash on the hash key of the electronic medical record to obtain a hash value. Finally, it finds the first virtual node on the hash ring that is greater than or equal to the hash value and identifies it as the first target virtual node, completing the mapping and storage of the hash key.

[0107] The microservices layer splits the electronic medical record system (also known as the medical information system) into multiple microservices. Each microservice instance is responsible for a specific functional module, such as patient information management, medical record storage, and image data processing. When a target microservice instance calls the microservices layer, it can execute the operation of parsing the electronic medical record and generating a hash key through one of the microservices. Furthermore, the microservices layer registers with the service registry upon startup and implements service discovery through a consistent hashing algorithm. The service registry maintains instance information and location information for all microservices. Clients can obtain the address of the required microservice from the service registry.

[0108] The load balancing layer receives storage requests and adjusts the weights of each microservice instance based on its load metrics using a consistent hashing algorithm combined with a dynamic weight adjustment mechanism. This determines the target microservice instance from multiple microservice instances and calls the microservice layer through the target microservice instance, achieving efficient distribution of storage requests. Specifically, the load balancing layer adjusts the weights of each microservice instance based on its load metrics using a dynamic weight adjustment mechanism, selecting any microservice instance with a weight below a preset threshold as the target microservice instance.

[0109] The containerized management layer leverages containerization technology to enable dynamic scaling and resource management of microservices. Containerization provides an isolated operating environment for microservices, ensuring the independence and stability of each EMR service instance. Using container orchestration tools like Kubernetes, the system automatically manages the microservice lifecycle, including deployment, scaling, updates, and rollbacks. If the system detects excessive load on a microservice instance, it automatically launches a new microservice instance and migrates some data to it using consistent hashing, enabling dynamic system scaling. Furthermore, the containerized management layer automatically adjusts resource allocation for each microservice instance based on the overall system load, improving resource utilization.

[0110] The technical solution in this application not only addresses the challenges of existing electronic medical record systems in terms of high-concurrency access, data consistency, dynamic expansion, and load balancing, but also achieves system efficiency, security, and scalability through the combination of a consistent hashing algorithm and a microservices architecture. This innovative solution provides new ideas and technical support for electronic medical record management in smart hospitals, and has broad application prospects and important practical significance.

[0111] It should be noted that although the operations of the present invention are described in a particular order in the accompanying drawings, this does not require or imply that these operations must be performed in this particular order, or that all the operations shown must be performed to achieve the desired results. On the contrary, the steps depicted in the flowchart can be performed in a different order.

[0112] The above description is merely a preferred embodiment of the present application and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of the invention herein is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also encompasses other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the inventive concept. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features having 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 is a dedicated architecture for electronic medical record storage. The microservice architecture includes a distributed storage layer, a microservice layer, a load balancing layer, and a containerized management layer. The method includes: Accessing storage requests through the load balancing layer to collect the load indicators of each microservice instance at the current moment, wherein the storage requests carry electronic medical records; The load balancing layer determines the target microservice instance based on the load indicators of each microservice instance and distributes the storage request to the target microservice instance. The load indicators include: CPU utilization, memory usage, ingress traffic, egress traffic, number of connections, current queue length, error rate, and response time. The target microservice instance calls the microservice layer 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, where 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 containerized management layer through the target microservice instance to collect the real-time load of the physical node bound to the first target virtual node, determining the first target physical node according to the real-time load of each physical node through the load balancing layer, and storing the electronic medical record in the first target physical node; The method further comprises: Calling the distributed storage layer through the target microservice instance to collect the amount of data stored in each virtual node; Adjusting the weight of each virtual node based on the amount of electronic medical record data stored in each virtual node, and determining a virtual node with a weight greater than a preset weight among the virtual nodes as a second target virtual node; Allocate part of the data on the second target virtual node to other virtual nodes.

2. The method according to claim 1, characterized in that The load balancing layer determines the target microservice instance according to the load index of each microservice instance, including: The load balancing layer adjusts the weight of each microservice instance using a dynamic weight adjustment mechanism according to the load index 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, characterized in that The method further comprises: Calculate a first hash value of the hash key using the consistent hashing algorithm; Calculate the hash value of each virtual node using the consistent hashing algorithm to obtain a second hash value corresponding to each virtual node; A first second hash value that is greater than or equal to the first hash value is selected from each of the second hash values ​​as a target second hash value, and a virtual node corresponding to the target second hash value is determined as a first target virtual node.

4. The method according to claim 1, wherein The determining the first target physical node according to the real-time load of each physical node through the load balancing layer includes: Adjusting the weight of each physical node through a dynamic weight adjustment mechanism according to the real-time load of each physical node; The physical node with the lowest weight is selected as the first target physical node.

5. The method according to claim 1, wherein The method further comprises: When the real-time load of the physical storage node bound to the first target virtual node exceeds the load threshold of a second target physical storage node, the containerization management layer is called through the target microservice instance to add a new virtual node for the second target physical storage node, and part of the data on the virtual node bound to the second target physical storage node is migrated to the new virtual node.

6. The method according to claim 5, characterized in that The method further comprises: The hash value of each new virtual node is calculated by a consistent hashing algorithm, and each new virtual node is mapped to the hash ring.

7. The method according to claim 1, characterized in that The method further comprises: If it is detected through the containerization management layer that the number of virtual nodes bound to the first target physical node is reduced, the data volume on the released virtual nodes is migrated to the remaining virtual nodes bound to the first target physical node.

8. The method according to claim 1, characterized in that The method further comprises: If the load indicators of each of the microservice instances at the current moment exceed the preset indicator value, a new microservice instance is added through the containerization management layer, and part of the requests on each of the microservice instances are allocated to the new microservice instance.

9. The method according to claim 1, characterized in that The calling the microservice layer through the target microservice instance to parse the electronic medical record and generate a hash key includes: Invoking the microservice layer through the target microservice instance to parse the electronic medical record and obtain a unique identifier of a target object associated with the electronic medical record; The hash key is generated according to a unique identifier of a target object associated with the electronic medical record.

Images