Medical knowledge base version management and synchronization method and system, and medium and device

Abstract

Provided in the present invention are a medical knowledge base version management and synchronization method and system, and a medium and a device. The method comprises: by means of Git software, initializing a medical knowledge base into a Git repository that can be recognized and monitored by the Git software; monitoring the Git repository by means of the Git software, so as to acquire version update information of the medical knowledge base; on the basis of the acquired version update information, performing version management and update on the medical knowledge base by means of the Git software; and by means of the Git software, synchronizing an updated version of medical knowledge base to all devices using the medical knowledge base. By means of introducing Git software into a medical knowledge base and running multiple functional commands of the Git software in the medical knowledge base, the method in the present application realizes efficient version management, real-time monitoring and multi-device synchronization of the medical knowledge base, thereby effectively solving the problems existing in conventional management approaches, improving the management efficiency of the medical knowledge base, and providing strong support for the development of medical informatization.

Description

Medical knowledge base version management and synchronization method, system, medium and device TECHNICAL FIELD

[0001] The present application relates to the technical field of medical informatization, in particular to a medical knowledge base version management and synchronization method, system, medium and device, and especially to a method and system for efficiently managing, monitoring updates and synchronously publishing medical knowledge bases using a Git version control system. BACKGROUND

[0002] A medical knowledge base is an important component of medical informatization. It stores and organizes medical information such as disease diagnosis, treatment methods, drug information, and the latest medical research findings, providing a quick way for doctors and medical professionals to access the information they need, thereby improving diagnosis and treatment efficiency and quality. In addition, a medical knowledge base is also the basis for developing clinical decision support systems (CDSS), electronic health records (EHR), and other medical information technology solutions. With the development of artificial intelligence and machine learning technologies, medical knowledge bases are increasingly used in intelligent medical care, providing more personalized and precise medical services.

[0003] As medical knowledge continues to update and accumulate, the medical information in the medical knowledge base is also constantly updated. However, existing medical knowledge base management lacks effective version control and change tracking mechanisms. When a developer modifies the medical information in the medical knowledge base and updates it to form a new version of the medical knowledge base, other developers or users cannot learn about the update in a timely manner, nor can they learn about the specific update information, resulting in delayed learning of the update status and update information by developers and users, which is not conducive to the sharing and collaborative development of the medical knowledge base. As the amount of update information increases, this problem will become more serious. In addition, after the medical knowledge is updated, how to quickly and effectively form the latest version of the medical knowledge base and synchronize it to other users and developers is also a major problem to be solved.

[0004] In summary, how to effectively manage and synchronize the versions of the medical knowledge base has become an important problem. Traditional version management methods have low efficiency, synchronization difficulties, and other problems, and cannot meet the needs of modern medical knowledge base management.

[0005] SUMMARY

[0006] To overcome the defects in the prior art, the present application provides a medical knowledge base version management and synchronization method, system, medium and device.

[0007] According to the medical knowledge base version management and synchronization method provided by the present application, an electronic device is used, which includes:

[0008] initializing the medical knowledge base into a Git repository capable of being recognized and monitored by the Git software through the Git software;

[0009] monitoring the Git repository through the Git software to obtain version update information of the medical knowledge base;

[0010] managing and updating the version of the medical knowledge base based on the obtained version update information through the Git software;

[0011] synchronizing the updated version of the medical knowledge base to all devices using the medical knowledge base through the Git software.

[0012] The present application initializes the medical knowledge base into a Git repository through the Git software, so that the medical knowledge base becomes a standardized data structure. Through the standardization of the data structure, the data of the medical knowledge base is more neat and orderly, which facilitates the subsequent use of various functions of Git and provides a data structure foundation for the subsequent version control and synchronization of the medical knowledge base. Further, the present application continuously monitors the Git repository through the Git software, thereby timely capturing the update status and update information of the medical knowledge base, avoiding the problem of delayed acquisition of the update status and update information. Further, the present application manages and updates the version of the medical knowledge base through the Git software, thereby timely and effectively updating the version of the medical knowledge base, and forming the latest version of the medical knowledge base on the basis of preserving the original version information. Further, the present application synchronizes the latest version of the medical knowledge base to other users' or developers' devices through the Git software, thereby better realizing the shared use and collaborative development of the medical knowledge base.

[0013] Preferably, the initializing the medical knowledge base into a Git repository capable of being recognized and monitored by the Git software through the Git software comprises:

[0014] determining the directory where the medical knowledge base is located, the directory containing all medical knowledge files that need to be included in version control;

[0015] initializing the directory where the medical knowledge base is located into a Git repository through the git init command of the Git software, and recognizing and monitoring all files in the Git repository through the Git software.

[0016] Preferably, a.gitignore file is created under the root directory of the Git repository, listing files or directories that are not included in version control;

[0017] all files in the current directory are added to the staging area through the git add command of the Git software, and then all files are committed to the Git repository through the git commit command of the Git software.

[0018] The application excludes version control of unnecessary files and sensitive information files by creating a.gitignore file in the Git repository, saves the storage space occupied by the part of the files, guarantees the clarity and compactness of the version control history, and avoids the leakage of sensitive information. Further, the application initializes the submission of the medical knowledge base by using the git add command and the git commit command of the Git software, which is equivalent to setting a clear starting point, providing a benchmark for subsequent version control operations, facilitating the tracking of any changes of any files by the Git software, and further enabling better use of the core functions of the Git software to achieve better version management.

[0019] Preferably, the version update information of the medical knowledge base obtained by monitoring the Git repository through the Git software comprises:

[0020] The state change of the Git repository is monitored by running the git status command of the Git software;

[0021] When the state change is monitored, the version update information of the medical knowledge base is obtained by comparing the differences between the current working area and the staging area or the last submission through the git diff command of the Git software.

[0022] Preferably, a file system listener is set at the preset file system level, and when the preset file system changes, the file system listener triggers the git status command of the Git software to check the state of the Git repository;

[0023] Before running the git diff command of the Git software, the monitoring result of the git status is parsed by using a script to obtain the type of state change, and when the type of state change meets the preset condition of version update, the git diff command of the Git software is further executed;

[0024] The key information change in the medical knowledge base is identified by integrating an intelligent analysis algorithm, and a notification is sent to the device; the key information includes new disease diagnosis methods and drug updates.

[0025] The application sets a file system listener in a preset file system, takes the file system listener as a trigger condition for execution of a git status command, instead of simply executing the command periodically or in real time, thereby realizing intelligent monitoring, optimizing monitoring frequency, reducing unnecessary checking times, improving monitoring effectiveness, and improving response speed. Further, the application analyzes the monitoring result of the git status through a script, can more accurately determine the type of changed file, instead of only obtaining the state information that the file has changed, and according to the type of the analyzed file, can determine whether the git diff command needs to be further executed, avoids executing the git diff command on unnecessary files and sensitive files, reduces unnecessary difference comparison times, and improves the effectiveness of command execution.

[0026] Preferably, the version management and update of the medical knowledge base based on the obtained version update information through the Git software include:

[0027] The importance coefficient and the influence range coefficient of the version update information are evaluated, and based on the evaluation result, a preset version control strategy is adopted to update the version of the medical knowledge base; the version control strategy includes a trigger condition for updating and an updating method used when updating;

[0028] When updating the version, the git add command of the Git software is run to add the version update information to the staging area, and then the git commit command of the Git software is run to commit the content of the staging area to the Git repository; when committing, the commit information containing the update content and the update purpose is attached;

[0029] Based on the importance coefficient and the influence range coefficient of the version update information, the tag command of the Git is run to mark the level of the version.

[0030] The application evaluates the importance coefficient and the influence range coefficient of the version update information to determine the necessity and the updating method of the version update, when the importance coefficient and the influence range coefficient are lower than a preset threshold, no update is performed, when the importance coefficient and the influence range coefficient are higher than or equal to the preset threshold but lower than a single update required threshold, a multiple version update information merging update method is adopted, and when the importance coefficient and the influence range coefficient are higher than or equal to the single update required threshold, the version update is directly performed, thereby realizing more effective version update. Further, based on the above-mentioned importance coefficient and the influence range coefficient, the level of different versions is marked, thereby facilitating developers and users to find and obtain some key update version related information.

[0031] Preferably, the updating version of the medical knowledge base is synchronized to all devices using the medical knowledge base by the Git comprises:

[0032] The remote repository is associated with the Git repository by running the git remote add command of the Git software;

[0033] The updating version of the medical knowledge base is pushed into the remote repository of all devices by running the git push command of the Git software;

[0034] Wherein, the updating version of the medical knowledge base is tested and verified, and the git push command of the Git software is run for pushing after the test and verification are correct.

[0035] The application further provides a medical knowledge base version management and synchronization system comprising the following modules:

[0036] The Git version control integrated module is used for initializing the medical knowledge base as a Git repository capable of being recognized and monitored by the Git software through the Git software;

[0037] The difference comparison tool module is used for monitoring the Git repository to obtain the version update information of the medical knowledge base through the Git software;

[0038] The medical knowledge base management module is used for managing and updating the version of the medical knowledge base through the Git software based on the obtained version update information;

[0039] The pushing to the remote repository module is used for synchronizing the updating version of the medical knowledge base to all devices using the medical knowledge base through the Git software.

[0040] The application further provides a computer readable storage medium storing a computer program, and the computer program is executed by a processor to implement the steps of the medical knowledge base version management and synchronization method.

[0041] The application further provides an electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, and the computer program is executed by the processor to implement the steps of the medical knowledge base version management and synchronization method.

[0042] Compared with the prior art, the application has the following beneficial effects:

[0043] The method of the present application introduces Git software in the medical knowledge base, realizes efficient version management, real-time monitoring and multi-device synchronization of the medical knowledge base by running various function commands of the Git software in the medical knowledge base, effectively solves the problems existing in the traditional management mode, improves the management efficiency of the medical knowledge base, and provides strong support for the development of medical informatization. BRIEF DESCRIPTION OF DRAWINGS

[0044] Other features, objects and advantages of the present application will become more apparent from the following detailed description of non-limiting embodiments, read in conjunction with the accompanying drawings:

[0045] Fig. 1 is a schematic diagram of the step flow of the medical knowledge base version management and synchronization method of the present application;

[0046] Fig. 2 is a schematic diagram of the step flow of initializing the directory of the medical knowledge base;

[0047] Fig. 3 is a schematic diagram of the step flow of monitoring the medical knowledge base version update information;

[0048] Fig. 4 is a schematic diagram of the step flow of the medical knowledge base version management;

[0049] Fig. 5 is a schematic diagram of the step flow of pushing the updated version of the medical knowledge base;

[0050] Fig. 6 is a schematic diagram of the step flow of the medical knowledge base version management and synchronization method in an embodiment;

[0051] Fig. 7 is a schematic diagram of the module framework of the medical knowledge base version management and synchronization system in an embodiment;

[0052] Fig. 8 is a schematic diagram of the submodule framework of the Git version control integrated module;

[0053] Fig. 9 is a schematic diagram of the submodule framework of the medical knowledge base management module;

[0054] Fig. 10 is a schematic diagram of the module framework of the medical knowledge base version management and synchronization system in another embodiment;

[0055] Fig. 11 is a schematic diagram of the submodule framework of the branch and merge management module.

[0056] Figure shows: Git version control integration module 1 Effect monitoring submodule 303 Project initialization submodule 101 Branch and merge management module 4 Install Git submodule 102 Branch strategy submodule 401 Write.gitignore file submodule 103 Daily development process submodule 402 Add files to repository submodule 104 Code review submodule 403 First commit submodule 105 Merge branch submodule 404 Create remote repository submodule 106 Resolve merge conflicts submodule 405 Push to remote repository submodule 107 Audit log module 5 Difference comparison tool module 2 User interface module 6 Medical knowledge base management module 3 Permission and access control module 7 Knowledge base update submodule 301 System integration and coordination module 8 Update strategy development submodule 302 Deployment and maintenance module 9 DETAILED DESCRIPTION

[0057] The application will be described in detail below with specific embodiments. The following examples will help those skilled in the art to further understand the application, but do not limit the application in any form. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the application. These are within the scope of the present application.

[0058] The present application provides a medical knowledge base version management and synchronization method for electronic devices, comprising: initializing the medical knowledge base as a Git repository that can be recognized and monitored by the Git software through the Git software; monitoring the Git repository through the Git software to obtain version update information of the medical knowledge base; managing and updating the version of the medical knowledge base based on the obtained version update information through the Git software; and synchronizing the updated version of the medical knowledge base to the device sharing the medical knowledge base through the Git software.

[0059] The application initializes the medical knowledge base into a Git repository through Git software, so that the medical knowledge base becomes a standardized data structure. The standardization of the data structure makes the data of the medical knowledge base more neat and orderly, facilitating the subsequent use of various functions of Git and providing a data structure foundation for the subsequent version control and synchronization of the medical knowledge base. The application continuously monitors the Git repository through Git software, thereby timely capturing the update status and update information of the medical knowledge base, avoiding the problem of delayed learning of the update status and update information. The application manages and updates the version of the medical knowledge base through Git software, thereby timely and effectively updating the version of the medical knowledge base, and forming the latest version of the medical knowledge base on the basis of preserving the original version information. The application synchronizes the latest version of the medical knowledge base to the devices of other users or developers through Git software, thereby better realizing the shared use and collaborative development of the medical knowledge base.

[0060] As shown in FIG. 1, a medical knowledge base version management and synchronization method for an electronic device includes the following steps:

[0061] Step S1: initializing the medical knowledge base into a Git repository that can be recognized and monitored by Git software through Git software.

[0062] As shown in FIG. 2, the specific process of step S1 is as follows:

[0063] Step S101: determine the directory where the medical knowledge base is located, which contains all the medical knowledge files that need to be included in version control;

[0064] Step S102: initialize the directory where the medical knowledge base is located into a Git repository by running the git init command of Git software, and recognize and monitor all files in the Git repository through Git software.

[0065] Specifically, for the directory where the medical knowledge base is located, first determine the specific storage location of the medical knowledge base in the file system, that is, determine a directory that contains all the medical knowledge files that need to be included in version control. This directory should be designed to contain all medical-related documents, pictures, videos, and other multimedia materials, as well as possible scripts or code files, which together constitute the core content of the medical knowledge base. In addition, ensure that the directory name of the medical knowledge base is simple, clear, and can reflect its content or purpose, for example, use medical_knowledge_base or a more specific cardiology_knowledge_base. Organizing files into subdirectories according to the medical field or knowledge type (such as diagnosis, treatment, drug information, etc.) helps management and retrieval.

[0066] Specifically, for the running of the git init command, open the terminal or command line interface, navigate to the above-mentioned directory, and run the git init command of the Git software, which will convert the current directory into a Git repository, meaning that the Git software will start monitoring and managing the version history of all files under the directory. The initialization process will create a hidden.git directory, which contains the metadata and object database of the Git repository, used to store file version information, branch information, etc. After completing the initialization of the Git repository, the Git software will automatically start identifying and monitoring all files in the repository, meaning that any modification, addition or deletion of files in the repository will be recorded by the Git software as part of the version history.

[0067] In other embodiments, in step S1, there are also the following steps: a. Create a.gitignore file in the root directory of the Git repository, listing files or directories not included in version control. b. Add all files in the current directory to the staging area by running the git add command of the Git software, and then run the git commit command of the Git software to commit all files to the Git repository.

[0068] Specifically, for the creation and editing of the.gitignore file, open the terminal or command prompt to access the Git software command, use the cd command to change the current directory to the root directory of the Git repository, for example, if the repository is located at ~ / Documents / MyGitRepo, enter cd ~ / Documents / MyGitRepo. In the terminal or command prompt, use a text editor (such as nano, vim, touch followed by an editor) to create this file, for example, using the touch command and nano editor, use the touch.gitignore command to create an empty.gitignore file, then use nano.gitignore to open and edit this file, add the patterns of files or directories that you want the Git software to ignore, for example: *.log ignores all.log files, / temp / ignores the temp directory under the root directory and all its contents. Use the.gitignore file to exclude unnecessary files such as temporary files, log files, build outputs, etc. For a medical knowledge base, you may need to exclude files such as.DS_Store (Mac-specific), __pycache__ (Python cache directory), etc. For some classified files, you also need to exclude them, classified files can only be viewed by some authorized persons, and you want to avoid submitting classified files, which may lead to the leakage of file keys.

[0069] Specifically, for the running of the git add command and the git commit command, under the root directory of the Git repository, run the git add command, which will add all changes (new files, modified files, etc.) in the current directory (including subdirectories) to the staging area, but not including the files and directories specified in the.gitignore file. After running the git commit command after adding files to the staging area, run git commit-m "commit information" to commit these changes to the Git repository, replace "commit information" with a brief description of the changes made in this commit, for example, git commit-m "Initial commit, added.gitignore and initial files." After the commit is complete, the Git software will create a new commit containing all changes added to the staging area (except for the files and directories specified in.gitignore).

[0070] Step S2: Monitor the Git repository through Git software to obtain version update information of the medical knowledge base.

[0071] As shown in FIG. 3, the specific process of step S2 is as follows:

[0072] Step S201: Monitor the status change of the Git repository by running the git status command of the Git software.

[0073] Step S202: When the status change is monitored, compare the differences between the current working area and the staging area or the last commit by running the git diff command of the Git software to obtain the version update information of the medical knowledge base.

[0074] Specifically, for the running of the git status command, open the terminal or command prompt, navigate to the Git repository directory where the medical knowledge base is located, and run the git status command. The git status command will display the status of the current working directory and the staging area, including which files have been modified but not staged, which files have been staged but not committed, and whether there are new branches or tags, etc.

[0075] Specifically, for the acquisition of version update information, the files listed in the "Changes not staged for commit" section indicate that these files have been modified but have not been added to the staging area. The files listed in the "Changes to be committed" section indicate that these files have been added to the staging area but have not been committed. After understanding which files have changed, the git diff command can be used to view the specific content of these changes. If you want to view the differences between the current working area (i.e. the files being edited) and the staging area, you can run the git diff command on the files listed in the "Changes not staged for commit" section. If you want to view the differences between the staging area (i.e. the files that have been added to the staging area through the git add command) and the last commit, you can run the git diff --cached command on the files listed in the "Changes to be committed" section. The output of git diff will display the differences between the files, usually in Unified Diff Format, which includes which lines are added, deleted or modified, and the context of these changes.

[0076] In other embodiments, in step 2, there are also the following steps: a, setting a file system listener at the preset file system level, triggering the git status command of the Git software to check the status of the Git repository when changes occur in the preset file system through the file system listener. b, before running the git diff command of the Git software, use a script to parse the monitoring results of git status to obtain the type of status change, and when the type of status change meets the preset condition of version update, further execute the git diff command of the Git software. By integrating intelligent analysis algorithms to identify key information changes in the medical knowledge base, and sending notifications to the device; the key information includes new disease diagnosis methods and drug updates.

[0077] Specifically, for the running of the git status command and the setting of the file system listener, first, the file system path to be monitored is determined, which can be the entire disk partition, a certain directory, or a specific group of directories, the specific location of the Git repository is confirmed, and it is ensured that the git status command can be executed correctly in the directory. According to the operating system, the corresponding file system monitoring tool can be selected, for example, on Linux, tools such as inotifywait (from the inotify-tools package) or entr can be used; on Windows, the ReadDirectoryChangesW API or third-party libraries such as FileSystemWatcher (.NET environment) can be used. The listener is configured to monitor the directory or more extensive file system path where the Git repository is located, and according to the needs, the listener can be configured to respond to different types of file system events, such as file creation, deletion, modification, etc. For the git status command, usually pay attention to file modification and deletion events.

[0078] Specifically, for the triggering of the git status command by the file system listener, when the listener detects file system changes, it can trigger a script or program to execute the git status command, and this script or program needs to be able to locate the root directory of the Git repository. In the script or program, use appropriate shell commands (such as bash, PowerShell, etc.) to execute git status. Ensure that the execution environment of the Git command (such as the PATH variable) has been correctly set so that the Git executable file can be found. The script can be an inotifywait script or a bash script, for example, assuming that the Git repository is located at / home / user / repo, a bash script can be written to monitor changes in this directory and execute git status when changes occur. This script uses the -m (continuous monitoring), -r (recursive monitoring), and -e (specify event type) options of inotifywait, when it detects that a file has been modified or deleted, it will switch to the Git repository directory and execute git status.

[0079] Specifically, for the script to parse the monitoring results of git status, a shell script can be written to complete the parsing of the monitoring results of git status. For example, in a bash script, define a check_git_status function, which is used to execute the git status --porcelain command and parse its output. The --porcelain option makes the output of git status more machine-readable, making it easier for scripts to process. Define a variable pattern, which defines specific preset conditions in the pattern variable. You can adjust the regular expression in the pattern variable to match different types of status changes (such as newly added files, deleted files, and untracked files) as needed. Use the grep command to check if the output contains a specific pattern (such as a modified or newly added file). If a match is found, it indicates that there is a file status change that meets the preset conditions. Based on the return value of grep, the function returns 0 (found successfully) or non-0 (not found). Based on the return value of the check_git_status function, use an if statement to determine whether to execute the git diff command.

[0080] Specifically, for the intelligent analysis algorithm to identify key information changes, you can choose the appropriate intelligent analysis algorithm according to your needs, such as natural language processing (NLP) for understanding and parsing text data, machine learning or deep learning algorithms for identifying patterns, classification, and prediction. Train the algorithm model using historical medical knowledge base data to enable it to identify the characteristics of key information (such as new disease diagnosis methods and drug updates). Evaluate the model performance using cross-validation and other methods, adjust the model parameters based on feedback, and optimize the recognition accuracy. Integrate the algorithm to analyze the preprocessed new data in real time, identify key information related to disease diagnosis methods and drug updates, and extract specific content from the identified key information, such as disease names, new diagnosis processes, drug names, and updated usage instructions. Verify the accuracy of the extracted information through manual review or secondary algorithm verification to remove possible false positives. Clearly define the types of devices that need to receive notifications, such as medical personnel's handheld terminals and hospital information systems (HIS), design clear and concise notification templates to ensure that key information is easily understood, and consider the adaptability of different devices according to their characteristics and needs. Choose appropriate notification methods such as SMS, email, APP push, and system messages based on device characteristics and needs. Set trigger conditions to trigger the notification sending process as soon as new key information is identified and verified. Use encryption techniques during data transmission to ensure information security and privacy protection. Design a feedback mechanism to collect feedback from recipients on notifications to continuously optimize notification content and methods.

[0081] It should be noted that there are three ways to implement the step S2: the step of monitoring the Git repository through the Git software to obtain the version update information of the medical knowledge base. The first way is adopted in this embodiment, and the second or third way can be adopted in other embodiments.

[0082] The first way is local monitoring. The git status command is run periodically in the local directory where the knowledge base is located. It displays the status of the current working directory and the staging area, telling the user which files have been modified, which files have been staged for commit, and which files are not tracked. If there is new update, the command will show it explicitly. The git diff command can be executed to view the specific changes, which will show the differences between the working area and the last commit, including new content, modified content and deleted content. This helps the user to understand the specific update of the knowledge base in detail.

[0083] The second way is remote monitoring. If the knowledge base has a remote repository, you can check whether the remote repository service provider (such as GitHub, GitLab, etc.) provides notification function. Usually, you can set up email notification, Webhook, etc. When there is new commit, branch creation, merge request, etc. in the remote repository, the user will receive a notification. The git pull command is executed periodically in the local knowledge base directory to pull the latest update from the remote repository. This ensures that the local knowledge base is synchronized with the remote repository and discovers new updates in the remote repository in time. If you use an online Git service platform, you can directly log in to the platform to view the repository interface where the knowledge base is located. Usually, it will display the activity log, commit history, branch status, etc. of the repository. The user can intuitively understand whether there is new update.

[0084] The third way is to use tool assisted monitoring. There are many Git client software, such as SourceTree, GitKraken, etc. These tools usually provide more intuitive interface and some additional functions, such as visual branch diagram, update notification, etc. which can help you more conveniently monitor the update of the knowledge base. If the update of the knowledge base is related to the software development process, you can use CI / CD tools such as Jenkins, Travis CI, etc. These tools can be configured to automatically monitor the changes of the Git repository and trigger a series of automated tasks such as building, testing, deploying, etc. when detecting the update, and also provide notification mechanism to let you know that there is new update in the knowledge base.

[0085] Step S3: based on the obtained version update information, the version of the medical knowledge base is managed and updated through the Git software.

[0086] As shown in FIG. 4, the specific process of step S3 is as follows:

[0087] Step S301: Evaluate the importance coefficient and the influence range coefficient of the version update information, and based on the evaluation results, update the version of the medical knowledge base using the preset version control strategy; the version control strategy includes: the trigger condition of the update, the update method used when updating;

[0088] Step S302: When updating the version, add the version update information to the staging area by running the git add command of the Git software, and then run the git commit command of the Git software to commit the content of the staging area to the Git repository; when committing, the commit information containing the update content and the update purpose is attached.

[0089] Specifically, for the evaluation of the importance coefficient, the evaluation of the importance coefficient is based on the following dimensions: a, urgency, evaluating whether the update involves emergency medical event handling, patient safety and other urgent issues; b, bug fixing, determining whether the update fixes known bugs or vulnerabilities, especially those that may lead to misdiagnosis or treatment errors; c, function enhancement, evaluating whether the update adds new medical knowledge, treatment methods or diagnostic tools, and the importance of these new contents to medical practice; d, compliance requirements, checking whether the update meets the latest laws and regulations, industry standards or internal regulations of medical institutions.

[0090] Specifically, for the evaluation of the influence range coefficient, the evaluation of the influence range coefficient is based on the following dimensions: a, user group, analyzing the number and type of doctors, nurses, patients or other medical personnel affected by the update; b, system integration, evaluating the impact of the update on the integration of the medical knowledge base with other medical information systems (such as electronic medical record systems, diagnostic assistance systems, etc.); c, business process, considering whether the update requires adjustment of existing medical workflow or decision path; d, regional distribution, if the medical knowledge base serves multiple regions, the difference in the impact of the update in different regions needs to be evaluated.

[0091] Specifically, regarding the comprehensive evaluation of the importance coefficient and the influence range coefficient, detailed information about the version update content is collected, including update logs, test reports, user feedback, etc., according to the defined evaluation indicators and standards, each update is quantitatively scored, the specific values of the importance coefficient and the influence range coefficient are calculated, the importance coefficient and the influence range coefficient are combined to form a comprehensive evaluation result, which is used to guide the subsequent version control decision.

[0092] Specifically, regarding the trigger condition for updating the version control strategy, the trigger condition for updating is specifically as follows: a, automatic triggering, based on preset monitoring rules (such as the number of error reports, security vulnerability announcements, etc.), the system automatically triggers the update process; b, manual triggering: the medical knowledge base management team manually decides when to start the update process according to the comprehensive evaluation results and actual situation; c, conditional triggering: when the comprehensive evaluation result reaches the preset threshold, the update is triggered automatically or manually.

[0093] Specifically, regarding the update method adopted when updating the version control strategy, the update method adopted when updating is specifically as follows: a, full update, suitable for large-scale content changes, such as rebuilding the entire knowledge base or large-scale data migration, which requires users to download and install the new version; b, incremental update, only update the part that has changed since the last version, reduce the update time and bandwidth consumption, suitable for frequent small-scale updates; c, phased update, for updates with wide impact or high risk, adopt phased implementation strategy, first verify in small-scale test environment, then gradually promote to larger scale; d, instant push, for urgent and important updates, adopt instant push mechanism to ensure that all users receive update notification and perform update as soon as possible.

[0094] Specifically, regarding the operation of the git add command, executing the git add command tells Git software which files or directories have been changed and should be included in the next commit. The git add command can be used in several ways: a, add specific files, if you only want to add specific files, you can directly follow the command with the file name, such as git add filename.txt; b, add all modifications, if you want to add all modified files in the current directory (but not including newly created files that have not been tracked by git add), you can use git add. or git add-A, -A option is the abbreviation of --all, which will add all modified and new files, but not including files ignored by.gitignore; c, add specific directory, if you want to add modifications in a certain directory and all its subdirectories, you can specify the directory name, such as git add dirname / . After executing the git add command, the changes of the specified files or directories are staged to the staging area of Git software, also known as index area or staging area. The staging area is the area used by Git software to prepare changes for the next commit.

[0095] Specifically, regarding the operation of the git commit command, after adding changes to the staging area through the git add command, the git commit command can be used to commit these changes from the staging area to the Git repository. When committing, a commit message is attached, which is used to describe the update content and update purpose contained in this commit. After executing git commit in the command line, Git will open a text editor (default to the system configured editor, such as vim, nano, etc.), let input commit message, commit message should usually be concise and clear to explain what this commit does, especially when the project is collaborated by multiple people, clear commit message is very important for subsequent code review and version rollback. In order to be convenient and fast, you can also use the -m option directly after the git commit command followed by the commit message, such as git commit -m "Update documentation to reflect new API changes", which will skip the step of opening the text editor and directly complete the writing of the commit message in the command line. After the commit message is written (whether through the text editor or directly in the command line), Git will permanently save these changes to the Git repository and create a new commit object, which contains a pointer to the parent commit, a tree object (representing the snapshot of the staging area), author information, committer information and commit information.

[0096] In other embodiments, in step 3, there is also the following step: a, based on the importance coefficient and the influence range coefficient of the version update information, different levels of tags are marked on the version by running the tag command using Git.

[0097] Specifically, regarding the level marking, based on the importance coefficient and the influence range coefficient, several different tag levels can be designed to distinguish versions of different importance, for example: a, major version (Major), indicating a version containing major functional updates or architectural changes, which may break backward compatibility, the importance coefficient and the influence range coefficient of these versions are both high; b, minor version (Minor), adding new functions compatible with the downward, may contain some important bug fixes, the importance coefficient of these versions is higher, but the influence range coefficient may vary depending on the specific nature of the new function; c, revision version (Patch), mainly to fix bugs and make small improvements, with little impact on functions and user interfaces, the importance coefficient and the influence range coefficient of these versions are relatively low.

[0098] Specifically, regarding the operation of the tag command, once the version level is determined, the tag command of Git can be used to create the corresponding label, for example: a, for major version, use the format similar to vX.0.0 to mark, where X is the major version number, for example, git tag-a v2.0.0-m "Major release with breaking changes and new features"; b, for minor version, use the format of vX.Y.0, where Y is the minor version number, for example, git tag-a v1.2.0-m "Minor release with new features and bug fixes"; c, for revision version, use the format of vX.Y.Z, where Z is the revision number, for example, git tag-a v1.1.1-m "Patch release with critical bug fixes".

[0099] Specifically, regarding the role of level marking, in the life cycle of the project, the label can help the user quickly locate a specific version, whether it is for problem tracking, rollback to the old version or provide stable release version to the user. All labels can be listed using the git tag command, and the details of a specific label can be displayed using the git show <tag>To view the details of a particular tag, as well as use git checkout <tag>or git switch <tag>Switch to the commit pointed by a specific tag.

[0100] It should be noted that there are two ways to implement "Step S3: managing and updating the version of the medical knowledge base through Git software based on the obtained version update information", and the present embodiment adopts the first way, while the second way can be adopted in other embodiments.

[0101] The first way is daily update management. When adding, modifying or deleting content in the knowledge base, treat these changes as managing code. Add updated files to the staging area using git add<file name>. If you want to add all modified files, you can use git add.. Commit with a meaningful commit message, such as "added new knowledge points" or "corrected wrong explanation", etc. Execute git commit-m" detailed commit description".

[0102] The second way is branch update management. Branches can be created for different topics, tasks or versions. For example, create a "new feature development" branch to add new knowledge modules, or create a "bug fix" branch to fix errors in the knowledge base. Create a branch using git branch<branch name>, and switch to a specific branch using git checkout<branch name>. When a specific task is completed on a branch, merge the branch back to the master branch. Switch to the master branch using git checkout master, and merge the branch using git merge<branch name>. If conflicts occur during merging, manually resolve the conflicts and then commit. In Git, you can create branches for different topics, tasks or versions of the knowledge base by following these steps:

[0103] Step a, create a new branch step, determine the purpose of the branch, and specify which topic, task or version the branch is created for. For example, if it is for a new function topic, you can give the branch a descriptive name such as "feature-new-search-function". If it is for a specific task, such as fixing a critical bug, you can name it "bugfix-critical-error". For different versions, you can use a naming method such as "version-2.0". Create a branch using the command, in the command line, switch to the directory where your knowledge base is located. Run the following command to create a new branch: git checkout-b<branch_name>, where<branch_name> is the name of the branch.

[0104] Step b, work on the branch, switch to the new branch, after creating the branch, Git will automatically switch to the new branch. You can use the git branch command to view the current branch to ensure that you are working on the correct branch. Work on a specific topic, task, or version, and make the appropriate modifications, additions, or deletions of files, etc. according to the purpose of the branch. For example, if it is to add new document content for a new topic, add these contents to the knowledge base. If it is to fix a bug, find the problem and modify the code.

[0105] Step c, commit changes on the branch, add changes to the staging area, use the git add<file_name> command to add modified files to the staging area. If you want to add all changes, you can use git add.. Commit changes, use the git commit-m"change description" command to commit changes and provide a meaningful commit message so that other users can understand what has been done.

[0106] Step S4: synchronize the updated version of the medical knowledge base to all devices using the medical knowledge base through Git software.

[0107] As shown in Figure 5, the specific process of step S4 is as follows:

[0108] Step S401: Establish a remote repository in all devices using the medical knowledge base through Git software, run the git remote add command of Git software to associate the remote repository with the Git repository;

[0109] Step S402: Run the git push command of Git software to push the updated version of the medical knowledge base to the remote repository of all devices.

[0110] Specifically, regarding the establishment of the remote repository, determine the hosting location of the remote repository, which can be a Git hosting service such as GitHub, GitLab, Bitbucket, or an organization's own self-hosted Git server. Once the hosting service or server is determined, a new repository needs to be created on the platform, and the repository URL needs to be recorded. Ensure that Git software is installed on all devices that need to use the medical knowledge base, and if the Git repository for the medical knowledge base project has not been initialized on each device, this step needs to be performed first. Add the URL of the remote repository to the Git repository on each device. Choose a remote repository name and then follow the URL of the remote repository. To confirm that the remote repository has been successfully added to the local repository, you can use the git remote-v command to list all remote repositories and their URLs.

[0111] Specifically, regarding the running of the git push command, before executing the git push command, it is necessary to confirm that the branch currently located is the branch that wants to push the update. Git allows users to work on different branches, and each branch can have its own history and changes. The git branch command is used to view all branches, and the git checkout command is used to switch to the correct branch. Before pushing any changes to the remote repository, it is necessary to ensure that the changes have been committed to the Cit repository through the git commit command. Uncommitted changes will not be pushed to the remote repository by the git push command. When in the correct branch and all changes have been committed, the git push command can be used to push the changes to the remote repository.

[0112] Specifically, regarding the synchronization of the version update result, the result of the medical knowledge base version update is synchronized to multiple devices through collaboration with the remote repository. The local repository can be associated with the remote repository. Use git remote add<remote repository name><remote repository address>. Push the local update to the remote repository so that others can get the latest version. Use git push<remote repository name><branch name>. Pull the update from the remote repository to the local repository to keep the local and remote synchronized. Use git pull<remote repository name><branch name>, thereby realizing the update of the multi-device medical knowledge base.

[0113] In other embodiments, in step 4, there is also the following step: a, test and verify the updated medical knowledge base, and after the test and verification is correct, run the git push command of the Git software for pushing.

[0114] Specifically, for the creation of a test environment and the testing and verification of the updated version, a test environment is first created, which should simulate the production environment as much as possible, but is not directly connected to the production environment to avoid potential risks. The updated version of the medical knowledge base is deployed to the test environment, including checking out the code base to the test server, and configuring the necessary resources such as databases, file systems, etc. Test cases are designed to verify whether all key functions of the knowledge base work as expected, including search functions, data retrieval accuracy, user interface interactions, etc. The performance of the new version is evaluated, such as response time, load bearing capacity, etc., to check whether the new version is compatible with the old version data, and whether it works normally on different browsers, operating systems and devices, ensuring that the new version does not introduce new security vulnerabilities. Automated testing tools are used as much as possible to execute test cases to improve testing efficiency and accuracy. For scenarios that cannot be automated or require human judgment, manual testing is performed, and the execution results of each test case are recorded in detail, including pass / fail status, problem description, screenshots, etc. Based on the test results, analyze possible problems and defects, fix the problems found, and re-verify the repair effect in the test environment. After fixing the problems, regression testing is performed to ensure that the newly introduced changes do not break the original functions.

[0115] As shown in FIG. 6, in other embodiments, a medical knowledge base version management and synchronization method includes steps S1-S4 described above, and further includes:

[0116] Step S5: Medical knowledge base version update marking and release;

[0117] Step S6: Backup and recovery of medical knowledge base version;

[0118] Step S7: Display of medical knowledge base version update.

[0119] Specifically, for step S5, when the knowledge base reaches an important milestone or release version, a tag can be used to mark it. For example, use git tag v1.0 to create a tag named "v1.0". Push the tag to the remote repository so that others can identify the specific version. Use git push <remote repository name> <tag name>. The history of medical knowledge base version updates can be viewed and compared. For example, use git log to view the commit history of the knowledge base to understand the update content and device information of each version.

[0120] Specifically, for step S6, using git diff <commit hash 1> <commit hash 2> can compare the specific differences between two different versions. The distributed nature of Git makes it easy to back up the knowledge base. Each place where the knowledge base repository is cloned has a complete copy. If you need to restore to a certain version, you can use the git reset or git checkout command combined with a specific commit hash or tag.

[0121] Specifically, for step S7, using some Git client tools such as SourceTree, GitKraken, etc., these tools can provide a more intuitive interface to manage the Git repository of the knowledge base. If the knowledge base is related to the development process, consider combining Git with continuous integration / continuous deployment (CI / CD) tools to achieve automated building, testing, and deployment.

[0122] As shown in FIG. 7, a medical knowledge base version management and synchronization system for implementing the medical knowledge base version management and synchronization method described above, which can efficiently track, manage and display the change history of the knowledge base, support parallel development and collaboration, the system includes: Git version control integration module 1, difference comparison tool module 2, medical knowledge base management module 3.

[0123] Git version control integration module 1 is used to initialize the medical knowledge base as a Git repository that can be recognized and monitored by Git software through Git software.

[0124] Difference comparison tool module 2 is used to manage and update the version of the medical knowledge base based on the obtained version update information through Git software.

[0125] Medical knowledge base management module 3 is used to manage and update the version of the medical knowledge base based on the obtained version update information through Git software.

[0126] Git version control integration module 1 is also used to synchronize the updated version of the medical knowledge base to all devices using the medical knowledge base through Git software.

[0127] Specifically, the Git version control integration module 1 is used to integrate Git version control functions into the medical knowledge base management system, realize the tracking and management of knowledge base changes, encapsulate Git commands and operations, provide RESTful API or graphical interface integration into existing systems, manage all versions of knowledge base files through Git repositories, and record changes for each commit. The difference comparison tool module 2 is used to develop a visual difference comparison tool to show changes between different versions, realize file and directory level difference display, support side-by-side comparison and unified difference view, transmit the difference comparison result to the user interface for user viewing and analysis, provide intuitive user interface and real-time code difference comparison tools through the Fork client of Git, support multi-repository management and task list management. The medical knowledge base management module 3 is a core component of the clinical decision support system (CDSS), which assists clinical personnel by providing real-time decision recommendations to reduce medical errors. The construction of the knowledge base usually includes a standard terminology library, a static knowledge base, a medical rule base, and an AI model library, which together constitute a knowledge service platform that can quickly respond to clinical needs and support specialized and intelligent application of diseases.

[0128] As shown in FIG. 8, in other embodiments, the Git version control integration module 1 includes a project initialization submodule 101, a Git installation submodule 102, a.gitignore file writing submodule 103, a file addition to repository submodule 104, a first commit submodule 105, a remote repository creation submodule 106, and a remote repository pushing submodule 107.

[0129] Specifically, the project initialization submodule 101 is used to run the git init command in the project directory of the medical knowledge base management system to initialize a new Git repository. The Git installation submodule 102 is used to ensure that all members participating in the project have installed Git. The.gitignore file writing submodule 103 is used to create a.gitignore file to ignore files that do not need version control, such as compilation generated files, log files, configuration files, etc. The file addition to repository submodule 104 is used to use the git add command to add project files to the staging area of Git. The first commit submodule is used to use the git commit command to make the first commit of the changes in the staging area, which marks the beginning of the project history. The remote repository creation submodule 106 is used to create a remote repository on platforms such as GitHub, GitLab, or Bitbucket, and associate the local repository with it. The remote repository pushing submodule 107 is used to use the git push command to push the local commit to the remote repository.

[0130] As shown in FIG. 9, in other embodiments, the medical knowledge base management module 3 includes a knowledge base updating submodule 301, an update strategy making submodule 302, and an execution effect monitoring submodule 303.

[0131] Specifically, the knowledge base updating submodule 301 is used to realize the continuous updating and maintenance of the knowledge base through content management tools and version control techniques, introduce new knowledge points and update information based on the time series analysis results, and ensure the accuracy and reliability of the updated content through a quality control process. Not only is an updated traditional Chinese medicine knowledge base generated, but also the timeliness and scientificity of the knowledge content are ensured. The implementation of this module provides a solid foundation for the continuous dissemination and popularization of traditional Chinese medicine knowledge and ensures the high quality and high credibility of the knowledge content. Based on the time series analysis results, the knowledge base updating submodule uses content management tools to update the knowledge base, uses Git for version control, records the content of each update, including new knowledge points and updated information, and generates knowledge base update records. The update strategy making submodule 302 designs an update strategy based on the knowledge base update records, uses the pandas library in Python to automatically analyze the update requirements, and sets parameters according to the update frequency and priority, so that the timely updating of the knowledge base matches the user's needs, and an update strategy scheme is generated. Based on the update strategy scheme, the execution effect monitoring submodule 303 performs quality control of the updated content, uses the automated testing tool Selenium to perform Web interface testing, including selecting appropriate test cases and determining the test frequency, and generates an updated traditional Chinese medicine knowledge base.

[0132] Specifically, in the knowledge base updating submodule 301, an automatic script and a version control system Git are used to manage and record the updating of the traditional Chinese medicine knowledge base. This submodule uses the time series analysis results as the update trigger point, integrates Git through a content management tool (such as a CMS system), automatically records the changes of each submission, including new knowledge points and updated information. This record is saved in the version control system, and a new version number is generated each time the knowledge base is updated, ensuring that the change history of the knowledge base is accurately recorded and tracked. The generated knowledge base update record not only provides a detailed change log, but also supports backtracking and version comparison, enhancing the maintenance efficiency and accuracy of the knowledge base.

[0133] Specifically, in the update strategy formulation submodule 302, the update requirement is automatically analyzed by analyzing the knowledge base update records using the pandas library of Python. This submodule automatically analyzes and determines the update strategy based on the content and frequency of the update records, as well as the feedback and needs of the users. The strategy includes determining the priority of knowledge points, the frequency of updates, and the related responsibility allocation. In this way, the update strategy scheme can ensure that the update of the knowledge base not only meets the needs of the users, but also effectively utilizes resources, so that the knowledge base remains up-to-date while avoiding waste of resources.

[0134] Specifically, in the execution effect monitoring submodule 303, the updated knowledge base is subjected to quality control through the automated testing tool Selenium. This submodule selects appropriate test cases and determines the frequency of testing based on the update strategy scheme, and automatically executes the testing of the Web interface. In this way, it can ensure that the updated knowledge base after each update can meet the expected quality standards, and potential problems can be discovered and corrected in a timely manner. The generated updated traditional Chinese medicine knowledge base not only has rich content and high accuracy, but also has a friendly interface and good user experience, further improving the practicality and user satisfaction of the system.

[0135] As shown in FIG. 10, in other embodiments, a medical knowledge base version management and synchronization system includes the above-mentioned Git version control integration module 1, difference comparison tool module 2, medical knowledge base management module 3, and further includes:

[0136] branch and merge management module 4, audit log module 5, user interface module 6, permission and access control module 7, system integration and coordination module 8, deployment and maintenance module 9.

[0137] Specifically, the branching and merging management module 4 is used to support parallel development and collaboration using the branching and merging functions of Git, to realize graphical interface operations for branch creation, switching, merging and conflict resolution, to manage changes in different branches, and to ensure the correctness and consistency of merging operations. The audit log module 5 is used to provide an audit log that records the history of changes and operations of the knowledge base, to implement a logging system that tracks key activities such as each commit, branch operation, and merge, and to store the audit log in a secure location for system administrators and authorized users to query. The user interface module 6 is used to provide a user interface for users to perform version control operations, view changes and audit logs, and to implement a friendly user interaction design including operation instructions, real-time feedback and error handling, to receive user operation requests, and to display version control results and audit information. The permission and access control module 7 is used to control user access to knowledge base version control operations, to implement role-based access control (RBAC), to ensure that users can only perform authorized operations, and to control access and operation of version control functions according to user permissions. The system integration and coordination module 8 is used to ensure that the system modules work together, to perform system testing and performance evaluation, to implement interface standardization and data synchronization mechanisms between modules, to perform integration testing and stress testing, to feed back the system integration and testing results to each module, and to guide system optimization and upgrading. The deployment and maintenance module 9 is responsible for the deployment, monitoring and maintenance of the system, to ensure stable operation of the system, to integrate a monitoring system, to track system performance indicators in real time, to implement an automated deployment and rollback mechanism, to collect system operation data and maintenance logs, and to use them for continuous system improvement.

[0138] As shown in FIG. 11, in other embodiments, the branching and merging management module 4 includes a branching strategy sub-module 401, a daily development process sub-module 402, a code review sub-module 403, a merging branch sub-module 404, and a merging conflict resolution sub-module 405.

[0139] In particular, the branching strategy submodule 401 is used to formulate branching strategies, such as using Gitflow or simple feature branching strategies, in order to manage feature development, bug fixing, and releases. The daily development process submodule 402 is used when developing new features or fixing bugs, creating a new branch from the main branch (usually master or main), developing and testing on the new branch, using git commit to record each meaningful change, periodically using git pull or git fetch and git merge to synchronize changes from remote branches, and using git push to push changes from the local branch to the remote repository. The code review submodule 403 is used to perform code reviews before merging branches, ensuring code quality and project standards. The merging branches submodule 404 is used to merge changes from feature branches back to the main branch using git merge or git rebase. The resolving merge conflicts submodule 405 is used to manually resolve conflicts if conflicts occur during merging, and commit the resolved changes.

[0140] It is to be understood that the embodiments of the present application can be realized in hardware, software, or a combination of them. The software can be stored in a volatile or non-volatile storage device (whether data is deletable or rewritable) like a ROM, in a memory like a RAM, a memory chip, a device, or an integrated circuit, or in a storage medium on which data can be optically or magnetically recorded and from which data can be read by a machine (e.g., a computer), such as a compact disc (CD), a digital versatile disc (DVD), a magnetic disk, or a magnetic tape. Also, the embodiments of the present application can be realized in a computer or a portable terminal having a controller and a memory, and the memory is an example of a non-transitory computer-readable storage medium suitable for storing one or more programs including commands for implementing the embodiments of the present application. Accordingly, the present application includes a program having a code for implementing an apparatus or a method defined by claims, and a machine-readable non-transitory storage medium storing the program. The program can be electronically transferred through a medium such as a communication signal transmitted via a wired or wireless connection, and the program and its equivalents are included in the present application.

[0141] The device can receive a program and store the program from a program providing device connected through a cable or wirelessly. The program providing device can include a program including commands for implementing the embodiments of the present application, a memory for storing information required for the embodiments of the present application, a communication module for communicating with the mobile device through a wired or wireless connection, and a controller for automatically or upon request of the device, transferring the program to the device.

[0142] The specific embodiments of the present application are described above. It needs to be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which does not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be combined with each other at will without conflict.< / tag> < / tag> < / tag>

Claims

1. A method for version management and synchronization of a medical knowledge base, used in electronic devices, characterized in that, The method comprises the following steps: initializing the medical knowledge base into a Git repository that can be monitored by the Git software through the Git software; monitoring the Git repository through the Git software to obtain version update information of the medical knowledge base; managing and updating the version of the medical knowledge base based on the obtained version update information through the Git software; synchronizing the updated version of the medical knowledge base to all devices using the medical knowledge base through the Git software.

2. The medical knowledge base version management and synchronization method according to claim 1, characterized in that, The step of initializing the medical knowledge base into a Git repository that can be monitored by the Git software through the Git software comprises the following steps: determining the directory where the medical knowledge base is located, and the directory contains all medical knowledge files that need to be included in version control; initializing the directory where the medical knowledge base is located into a Git repository through the git init command of the Git software, and monitoring all files in the Git repository through the Git software.

3. The medical knowledge base version management and synchronization method according to claim 2, wherein, creating a.gitignore file in the root directory of the Git repository, and listing the files or directories that are not included in version control; adding all files in the current directory to the staging area through the git add command of the Git software, and then committing all files to the Git repository through the git commit command of the Git software.

4. The medical knowledge base version management and synchronization method of claim 1, wherein, The step of monitoring the Git repository through the Git software to obtain version update information of the medical knowledge base comprises the following steps: monitoring the state change of the Git repository through the git status command of the Git software; when the state change is monitored, comparing the differences between the current working area and the staging area or the last commit through the git diff command of the Git software to obtain the version update information of the medical knowledge base.

5. The medical knowledge base version management and synchronization method according to claim 4, wherein, setting a file system listener at the preset file system level, and triggering the git status command of the Git software to check the state of the Git repository when changes occur in the preset file system; before running the git diff command of the Git software, parsing the monitoring results of git status using a script to obtain the type of state change, and when the type of state change meets the preset conditions of version update, further executing the git diff command of the Git software; identifying the key information changes in the medical knowledge base through integrated intelligent analysis algorithm, and sending a notification to the device; the key information includes new disease diagnosis methods and drug updates.

6. The medical knowledge base version management and synchronization method of claim 1, wherein, The step of managing and updating the version of the medical knowledge base based on the obtained version update information through the Git software comprises the following steps: evaluating the importance coefficient and influence range coefficient of the version update information, and based on the evaluation results, updating the version of the medical knowledge base using a preset version control strategy; the version control strategy includes the trigger condition of the update and the update method used during the update; when updating the version, adding the version update information to the staging area through the git add command of the Git software, and then committing the content of the staging area to the Git repository through the git commit command of the Git software; when committing, the commit information containing the update content and the update purpose is attached. The tag command using Git is run to mark the version with different levels based on the importance coefficient and the influence range coefficient of the version update information.

7. The medical knowledge base version management and synchronization method according to claim 1, wherein, The updated version of the medical knowledge base is synchronized to all devices using the medical knowledge base through Git, including: A remote repository is established in all devices using the medical knowledge base through Git software, and the remote repository is associated with the Git repository by running the git remote add command of the Git software; The updated version of the medical knowledge base is pushed to the remote repository of all devices by running the git push command of the Git software; The updated version of the medical knowledge base is tested and verified, and the git push command of the Git software is run for pushing after the test and verification are correct.

8. A medical knowledge base version management and synchronization system, characterized by, The computer program is executed by the processor to implement the steps of the medical knowledge base version management and synchronization method in any one of claims 1 to 7. The computer program is executed by the processor to implement the steps of the medical knowledge base version management and synchronization method in any one of claims 1 to 7. ​ ​ ​ 9. A computer readable storage medium storing a computer program, characterized in that, ​ 10. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, ​

Images