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

Abstract

The invention provides a medical knowledge base version management and synchronization method and system, a medium and equipment. The medical knowledge base version management and synchronization method comprises the steps that a medical knowledge base is initialized into a Git warehouse capable of being recognized and monitored by Git software through the Git software; monitoring the Git warehouse through Git software to obtain version updating information of the medical knowledge base; based on the obtained version updating information, managing and updating the version of the medical knowledge base through Git software; and synchronizing the medical knowledge base with the updated version to all devices using the medical knowledge base through Git software. According to the method, the Git software is introduced into the medical knowledge base, efficient version management, real-time monitoring and multi-device synchronization of the medical knowledge base are achieved by operating multiple function commands of the Git software in the medical knowledge base, the problems existing in a traditional management mode are effectively solved, the management efficiency of the medical knowledge base is improved, and the medical knowledge base management efficiency is improved. And powerful support is provided for the development of medical informatization.

Description

Technical Field

[0001] The present invention relates to the field of medical information technology, and specifically, to a medical knowledge base version management and synchronization method, system, medium and equipment, and in particular to a method and system for efficiently managing versions, monitoring updates and synchronously publishing a medical knowledge base using a Git version control system. Background Art

[0002] The medical knowledge base is an important part of medical informationization. It provides doctors and medical professionals with a way to quickly obtain the required information by centrally storing and organizing medical information, such as disease diagnosis, treatment methods, drug information, and the latest medical research results, thereby improving the efficiency and quality of diagnosis and treatment. In addition, the medical knowledge base is also the basis for the development of 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 being used more and more widely in intelligent medicine, providing more personalized and accurate medical services.

[0003] With the continuous updating and accumulation of medical knowledge, the medical information in the medical knowledge base is also constantly updated, but the 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 know in time that the medical knowledge base has been updated, nor can they know the specific update information, resulting in delayed knowledge of the update status and update information by developers and users, which is not conducive to the shared use and collaborative development of the medical knowledge base. As more and more updated information is available, this problem will become more serious. In addition, after the knowledge medical 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 that needs to be solved.

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

[0005] In view of the defects in the prior art, the object of the present invention is to provide a medical knowledge base version management and synchronization method, system, medium and equipment.

[0006] A medical knowledge base version management and synchronization method provided by the present invention is used in electronic devices, comprising:

[0007] Initialize the medical knowledge base into a Git repository that can be recognized and monitored by the Git software through the Git software;

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

[0009] Based on the obtained version update information, the version of the medical knowledge base is managed and updated through Git software;

[0010] The updated version of the medical knowledge base is synchronized to all devices using the medical knowledge base through Git software.

[0011] This application uses Git software to initialize the medical knowledge base as a Git warehouse, 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, which is convenient for 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. Furthermore, this application uses Git software to continuously monitor the Git warehouse, so that the update status and update information of the medical knowledge base can be captured in a timely manner, avoiding the problem of delayed knowledge of the update status and update information. Furthermore, this application uses Git software to manage and update the version of the medical knowledge base, so as to update the version of the medical knowledge base in a timely and effective manner, and form the latest version of the medical knowledge base on the basis of retaining the original version information. Furthermore, this 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.

[0012] Preferably, the initializing the medical knowledge base into a Git repository that can be recognized and monitored by the Git software through the Git software includes:

[0013] Determine the directory where the medical knowledge base is located, which contains all medical knowledge files that need to be included in version control;

[0014] By running the git init command of the Git software, the directory where the medical knowledge base is located is initialized as a Git repository, and all files in the Git repository are identified and monitored by the Git software.

[0015] Preferably, create a .gitignore file in the root directory of the Git repository to list the files or directories that are not included in version control;

[0016] Run the git add command of the Git software to add all files in the current directory to the staging area, and then run the git commit command of the Git software to submit all files to the Git repository.

[0017] This application creates a .gitignore file in the Git repository to exclude version control of unnecessary files and sensitive information files, saving the storage space occupied by these files while ensuring the clarity and compactness of the version control history and avoiding the leakage of sensitive information. Furthermore, this application initializes the submission of the medical knowledge base by executing the git add command and gitcommit command of the Git software, which is equivalent to setting a clear starting point, providing a benchmark for subsequent version control operations, making it easier for the Git software to track any changes to any file, and thus making better use of the core functions of the Git software to achieve better version management.

[0018] Preferably, the obtaining version update information of the medical knowledge base by monitoring the Git repository through Git software includes:

[0019] Monitor the status changes of the Git repository by running the git status command of the Git software;

[0020] When a status change is detected, the git diff command of the Git software is run to compare the difference between the current workspace and the staging area or the most recent submission to obtain the version update information of the medical knowledge base.

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

[0022] 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. When the type of status change meets the preset conditions for version update, further execute the git diff command of the Git software;

[0023] Through integrated intelligent analysis algorithms, key information changes in the medical knowledge base are identified and notifications are sent to the device; key information includes new disease diagnosis methods and drug updates.

[0024] This application sets a file system listener in a preset file system and uses the file system listener as a trigger condition for the execution of the git status command, rather than simply executing the command periodically or in real time, thereby achieving intelligent monitoring, optimizing the monitoring frequency, reducing the number of unnecessary checks, improving the effectiveness of monitoring, and improving the response speed. Furthermore, this application parses the monitoring results of git status through a script, and can more accurately determine the type of files that have changed, rather than just obtaining the status information that the file has changed, and based on the type of the parsed file, it can determine whether the git diff command needs to be further executed, avoiding the execution of the git diff command on unnecessary and sensitive files, reducing the number of unnecessary difference comparisons, and improving the effectiveness of command execution.

[0025] Preferably, the managing and updating the version of the medical knowledge base through Git software based on the obtained version update information includes:

[0026] Evaluate the importance coefficient and impact scope coefficient of version update information, and based on the evaluation results, use the preset version control strategy to update the version of the medical knowledge base; the version control strategy includes: the triggering conditions for the update and the update method used during the update;

[0027] When performing a version update, run the git add command of the Git software to add the version update information to the staging area, and then run the git commit command of the Git software to commit the contents of the staging area to the Git repository; when submitting, attach the commit information containing the updated content and the purpose of the update;

[0028] Based on the importance coefficient and impact scope coefficient of the version update information, the version is graded by running the Git tag command.

[0029] This application determines the necessity and update method of version update by evaluating the importance coefficient and impact range coefficient of version update information. When the importance coefficient and impact range coefficient are lower than the preset threshold, no update is performed. When the importance coefficient and impact range coefficient are higher than or equal to the preset threshold but lower than the threshold required for a single update, multiple version update information are merged and updated. When the importance coefficient and impact range coefficient are higher than or equal to the threshold required for a single update, the version update is performed directly, thereby achieving a more effective version update. Furthermore, based on the above-mentioned importance coefficient and impact range coefficient, the level marking of different versions is achieved, thereby facilitating developers and users to find and obtain relevant information of some key update versions.

[0030] Preferably, synchronizing the updated version of the medical knowledge base to all devices using the medical knowledge base through Git includes:

[0031] Use Git software to create a remote repository in all devices that use the medical knowledge base, and run the git add command of the Git software to associate the remote repository with the Git repository;

[0032] Run the git push command of the Git software to push the updated version of the medical knowledge base to the remote warehouse of all devices;

[0033] Among them, the updated version of the medical knowledge base is tested and verified. After the test and verification are correct, the git push command of the Git software is run to push it.

[0034] The present invention also provides a medical knowledge base version management and synchronization system, including the following modules:

[0035] A Git version control integration module, used to initialize the medical knowledge base into a Git repository that can be recognized and monitored by the Git software through the Git software;

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

[0037] A medical knowledge base management module, used to manage and update the version of the medical knowledge base through Git software based on the obtained version update information;

[0038] The push to remote repository module is used to synchronize the updated version of the medical knowledge base to all devices using the medical knowledge base through Git software.

[0039] The present invention also provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned medical knowledge base version management and synchronization method are implemented.

[0040] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the steps of the above-mentioned medical knowledge base version management and synchronization method when executed by the processor.

[0041] Compared with the prior art, the present invention has the following beneficial effects:

[0042] The method of the present invention introduces Git software into the medical knowledge base and realizes efficient version management, real-time monitoring, and multi-device synchronization of the medical knowledge base by running various functional commands of the Git software in the medical knowledge base, thereby effectively solving the problems existing in traditional management methods, improving the management efficiency of the medical knowledge base, and providing strong support for the development of medical informatization. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0044] Figure 1 A schematic diagram of the steps of the medical knowledge base version management and synchronization method of the present invention;

[0045] Figure 2 A flowchart of the steps for initializing the directory where the medical knowledge base is located;

[0046] Figure 3 A flowchart of the steps for monitoring the version update information of the medical knowledge base;

[0047] Figure 4 A flowchart of the steps for version management of medical knowledge base;

[0048] Figure 5 A flowchart showing the steps for pushing an updated version of the medical knowledge base;

[0049] Figure 6 1. It is a schematic diagram of the steps of the medical knowledge base version management and synchronization method in one embodiment;

[0050] Figure 7 It is a schematic diagram of the module framework of the medical knowledge base version management and synchronization system in one embodiment;

[0051] Figure 8 This is a schematic diagram of the submodule framework of the Git version control integration module;

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

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

[0054] Fig.11 Schematic diagram of the submodule framework of the branch and merge management module.

[0055] The figure shows:

[0056] Git version control integration module 1 Execution effect monitoring submodule 303

[0057] Project Initialization Submodule 101 Branch and Merge Management Module 4

[0058] Install Git submodule 102 Branch strategy submodule 401

[0059] Writing .gitignore files submodule 103 Daily development process submodule 402

[0060] Add files to repository submodule 104 Code review submodule 403

[0061] First commit submodule 105 Merge branch submodule 404

[0062] Create remote repository submodule 106 Resolve merge conflict submodule 405

[0063] Push to remote repository submodule 107 Audit log module 5

[0064] Difference Comparison Tool Module 2 User Interface Module 6

[0065] Medical Knowledge Base Management Module 3 Permission and Access Control Module 7

[0066] Knowledge base update submodule 301 System integration and coordination module 8

[0067] Update strategy formulation submodule 302 Deployment and maintenance module 9 DETAILED DESCRIPTION

[0068] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0069] The present application provides a medical knowledge base version management and synchronization method for electronic devices, including: initializing the medical knowledge base as a Git repository that can be recognized and monitored by the Git software through 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 through the Git software based on the obtained version update information; and synchronizing the updated version of the medical knowledge base to the device that shares the medical knowledge base through the Git software.

[0070] This application uses Git software to initialize the medical knowledge base as a Git warehouse, 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, which is convenient for 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. This application uses Git software to continuously monitor the Git warehouse, so that it can capture the update status and update information of the medical knowledge base in a timely manner, avoiding the problem of delayed knowledge of the update status and update information. This application uses Git software to manage and update the version of the medical knowledge base, so as to update the version of the medical knowledge base in a timely and effective manner, and form the latest version of the medical knowledge base on the basis of retaining the original version information. This 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.

[0071] like Figure 1 As shown, a medical knowledge base version management and synchronization method, used in electronic devices, includes the following steps:

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

[0073] like Figure 2 As shown, the specific process of step S1 is as follows:

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

[0075] Step S102: Initialize the directory where the medical knowledge base is located as a Git repository by running the git init command of the Git software, and identify and monitor all files in the Git repository through the Git software.

[0076] Specifically, for the directory where the medical knowledge base is located, first clarify the specific storage location of the medical knowledge base in the file system, that is, determine a directory that contains all 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. These files together constitute the core content of the medical knowledge base. In addition, ensure that the directory name of the medical knowledge base is concise, clear, and reflects its content or purpose, for example, use medical_knowledge_base or the more specific cardiology_knowledge_base. Organizing files into subdirectories according to medical fields or knowledge types (such as diagnosis, treatment, drug information, etc.) helps with management and retrieval.

[0077] Specifically, to run the git init command, open a terminal or command line interface, navigate to the above directory, and run the git init command of the Git software. This command converts the current directory into a Git repository, which means that the Git software will begin to monitor and manage the version history of all files in the directory. The initialization process will create a hidden .git directory, which contains the metadata and object database of the Git repository, which is used to store file version information, branch information, etc. After completing the initialization of the Git repository, the Git software will automatically begin to identify and monitor all files in the repository, which means that any modification, addition, or deletion of files in the repository will be recorded by the Git software and become part of the version history.

[0078] 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 to list files or directories that are not included in version control. b. Add all files in the current directory to the temporary storage 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.

[0079] Specifically, for the creation and editing of the .gitignore file, open the terminal or command prompt to access the command of the Git software, and use the cd command to change the current directory to the root directory of the Git repository. For example, if the repository is located in ~ / 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. Taking the touch command and nano editor as an example, use the touch.gitignore command to create an empty .gitignore file. Then, use nano.gitignore to open and edit this file, and add the pattern of the files or directories you want 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 medical knowledge bases, you may need to exclude .DS_Store (Mac-specific), __pycache__ (Python cache directory), etc. Some confidential files also need to be excluded. Confidential files can only be viewed by some authorized people. It is necessary to avoid submitting confidential files, which may lead to the leakage of file keys.

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

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

[0082] like Figure 3 As shown, the specific process of step S2 is as follows:

[0083] Step S201: monitor the status change of the Git repository by running the git status command of the Git software;

[0084] Step S202: When a status change is detected, the version update information of the medical knowledge base is obtained by running the git diff command of the Git software to compare the difference between the current workspace and the temporary storage area or the most recent submission.

[0085] Specifically, to run 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 staging area, including which files have been modified but not yet staged, which files have been staged but not yet committed, and whether there are new branches or tags.

[0086] Specifically, for obtaining version update information, the files listed in the "Changes not staged for commit" section indicate that these files have been modified but not yet 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 yet been committed. After knowing which files have changed, you can use the git diff command to view the specific content of these changes. If you want to view the difference between the current working area (that is, the file 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 difference between the staging area (that is, the files that have been added to the staging area through the git add command) and the most recent 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 show the differences between the files, usually in a unified difference format (Unified Diff Format), which includes which lines are added, deleted, or modified, and the context of these changes.

[0087] In other embodiments, in step 2, there are also the following steps: a. Setting a file system listener at the preset file system level, and when the preset file system changes, triggering the gitstatus command of the Git software to check the status of the Git repository through the file system listener. b. Before running the git diff command of the Git software, using a script to parse the monitoring results of git status, obtain the type of status change, and when the type of status change meets the preset conditions for version update, further execute the git diff command of the Git software. Identify changes in key information in the medical knowledge base through an integrated intelligent analysis algorithm, and send notifications to the device; key information includes new disease diagnosis methods and drug updates.

[0088] Specifically, for the operation of the git status command and the setting of the file system listener, first clarify the file system path that needs to be monitored, which can be the entire disk partition, a directory, or a specific set of directories, confirm the specific location of the Git repository, and ensure that the git status command can be correctly executed in this directory. According to the operating system, you can choose the corresponding file system monitoring tool. For example, on Linux, you can use tools such as inotifywait (from the inotify-tools package) or entr; on Windows, you can use the ReadDirectoryChangesW API or third-party libraries such as FileSystemWatcher (.NET environment). Configure the listener to monitor the directory where the Git repository is located or a wider file system path. As needed, 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, file modification and deletion events are usually concerned.

[0089] Specifically, for the triggering of the git status command by the file system listener, when the listener detects changes in the file system, the git status command can be executed by triggering a script or program. This script or program needs to be able to locate the root directory of the Git repository. In the script or program, use the appropriate shell command (such as bash, PowerShell, etc.) to execute git status. Make sure that the execution environment of the Git command (such as the PATH variable) is correctly set so that the Git executable file can be found. The script can be selected as an inotifywait script or a bash script. Taking the bash script as an example, assuming that the Git repository is located in / home / user / repo, you can write a bash script to monitor changes in the directory and execute git status when it changes. 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 switches to the Git repository directory and executes git status.

[0090] Specifically, for the script to parse the monitoring results of git status, you can write a shell script to complete the parsing of the monitoring results of git status. Take the bash script as an example, 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 and convenient for script processing. Define a variable pattern, which defines specific preset conditions. You can adjust the regular expression in the pattern variable as needed to match different status change types (such as newly added files, deleted files, untracked files, etc.). Use the grep command to check whether the output contains a specific pattern (such as a file that has been modified or newly added). If a match is found, it means that there is a file status change that meets the preset conditions. According to the return value of grep, the function returns 0 (successfully found) or non-0 (not found). According to the return value of the check_git_status function, use the if statement to decide whether to execute the git diff command.

[0091] Specifically, for the identification of key information changes by intelligent analysis algorithms, appropriate intelligent analysis algorithms can be selected according to needs, such as natural language processing (NLP) for understanding and parsing text data, and machine learning or deep learning algorithms for identifying patterns, classification and prediction. Use historical medical knowledge base data to train the algorithm model so that it can identify the characteristics of key information (such as new disease diagnosis methods and drug updates). Evaluate model performance through methods such as cross-validation, adjust model parameters based on feedback, and optimize recognition accuracy. The integrated algorithm performs real-time analysis on the new data after preprocessing, identifies key information related to disease diagnosis methods and drug updates, and extracts specific content from the identified key information, such as disease name, new diagnostic process, drug name, updated instructions for use, etc. Verify the accuracy of the extracted information through manual review or secondary algorithm to remove possible false positives. Clarify the type of device that needs to receive notifications, such as medical staff's handheld terminals, hospital information systems (HIS), etc., design clear and concise notification templates to ensure that key information is clear at a glance, and consider the adaptability of different devices at the same time. Select appropriate notification methods according to device characteristics and needs, such as SMS, email, APP push, system messages, etc. Set trigger conditions to immediately trigger the notification sending process once new key information is identified and verified. Use encryption technology during data transmission to ensure information security and privacy protection. Design a feedback mechanism to collect feedback from recipients on notifications in order to continuously optimize notification content and methods.

[0092] It should be noted that there are three ways to implement "step S2: monitoring the Git repository through the Git software to obtain the version update information of the medical knowledge base". This embodiment adopts the method one. In other embodiments, the method two or the method three may be adopted:

[0093] Method 1: Local monitoring: Regularly run the git status command in the local directory where the knowledge base is located. It will display 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 submission, and which files are not tracked. If there are new updates, the command will clearly display them. Execute git diff to see what specific content has changed. It will show the difference between the workspace and the last submission, including new content, modified content, and deleted content. This helps users understand the specific updates of the knowledge base in detail.

[0094] Method 2: 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 a notification function. Usually, you can set up email notifications, Webhooks, etc. When there are new submissions, branch creations, merge requests and other activities in the remote repository, the user will receive a notification. Regularly execute the git pull command in the local knowledge base directory to pull the latest updates from the remote repository. This ensures that the local knowledge base is synchronized with the remote and new updates in the remote repository are discovered in a timely manner. If you use an online Git service platform, you can log in directly to the platform to view the warehouse interface where the knowledge base is located. Usually, the warehouse's activity log, submission history, branch status and other information will be displayed, and users can intuitively understand whether there are new updates.

[0095] Method 3: Use tools to assist monitoring. There are many Git client software, such as SourceTree, GitKraken, etc. These tools usually provide a more intuitive interface and some additional features, such as visual branch graphs, update notifications, etc., which can help you monitor updates to the knowledge base more conveniently. 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 changes in the Git repository and trigger a series of automated tasks such as building, testing, and deployment when updates are detected. At the same time, they can also provide a notification mechanism to let you know that there are new updates to the knowledge base.

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

[0097] like Figure 4 As shown, the specific process of step S3 is as follows:

[0098] Step S301: Evaluate the importance coefficient and impact scope coefficient of the version update information, and based on the evaluation results, use a preset version control strategy to update the version of the medical knowledge base; the version control strategy includes: trigger conditions for the update, and the update method used during the update;

[0099] Step S302: When performing a version update, the version update information is added to the temporary storage area by running the git add command of the Git software, and then the git commit command of the Git software is run to submit the contents of the temporary storage area to the Git repository; when submitting, the submission information including the update content and the purpose of the update is attached.

[0100] Specifically, the importance coefficient is evaluated based on the following dimensions: a. Urgency, evaluating whether the update involves urgent issues such as emergency medical event handling and patient safety; b. Error repair, judging whether the update fixes known errors or vulnerabilities, especially those that may lead to misdiagnosis or treatment errors; c. Functional 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.

[0101] Specifically, the evaluation of the impact scope coefficient is based on the following dimensions: a. User groups, analyzing the number and types of doctors, nurses, patients or other medical personnel that will be 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 processes, considering whether the update requires adjustment of existing medical workflows or decision-making paths; d. Geographical distribution, if the medical knowledge base serves multiple regions, it is necessary to evaluate the differences in the impact of the update in different regions.

[0102] Specifically, regarding the comprehensive evaluation combining the importance coefficient and the impact scope coefficient, detailed information about the version update content is collected, including update logs, test reports, user feedback, etc., and each update is quantitatively scored according to the defined evaluation indicators and standards. The specific values ​​of the importance coefficient and the impact scope coefficient are calculated, and the importance coefficient and the impact scope coefficient are combined to form a comprehensive evaluation result to guide subsequent version control decisions.

[0103] Specifically, regarding the trigger conditions for updating the version control policy, the update trigger conditions are 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 based on the comprehensive evaluation results and actual conditions; c. Conditional triggering: When the comprehensive evaluation results reach the preset threshold, the update is automatically or manually triggered.

[0104] Specifically, regarding the update methods used when updating the version control strategy, there are several specific update methods used when updating: a. Full update, which is suitable for large-scale content changes, such as the reconstruction of the entire knowledge base or large-scale data migration, which requires users to download and install the new version; b. Incremental update, which only updates the parts that have changed since the last version, reducing update time and bandwidth consumption, and is suitable for frequent small-scale updates; c. Phased update, for updates with a wide impact or high risk, a phased implementation strategy is adopted, first verifying in a small-scale test environment, and then gradually promoting to a larger range; d. Instant push, for urgent and important updates, an instant push mechanism is adopted to ensure that all users receive update notifications and execute updates as soon as possible.

[0105] Specifically, regarding the operation of the git add command, executing the git add command is to tell the Git software which file or directory changes should be included in the next submission. 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 changes. 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. The -A option is short for --all, which will add all modified and newly added files, but does not include files ignored by .gitignore; c. Add a specific directory. If you want to add changes in a 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 will be temporarily stored in the temporary storage area of ​​the Gi software, also known as the index area or staging area. The temporary storage area is the area used by the Git software to prepare changes to be submitted.

[0106] Specifically, regarding the operation of the git commit command, after adding changes to the staging area through the git add command, you can use the git commit command to commit these changes from the staging area to the Git repository. When submitting, a commit message will be attached, which is used to describe the updated content and update purpose included in this commit. After executing gitcommit in the command line, Git will open a text editor (the default is the editor configured by the system, such as vim, nano, etc.) to allow you to enter the commit message. The commit message should usually be concise and clear about what was done in this commit, especially when the project is collaborated by multiple people. Clear commit messages are very important for subsequent code reviews and version rollbacks. For convenience and speed, you can also directly use the -m option followed by the commit message in the git commit command, such as git commit-m "Update documentation to reflect new API changes". This will skip the step of opening the text editor and complete the writing of the commit message directly in the command line. Once the commit message is written (whether through a text editor or directly in the command line), Git will save these changes permanently to the Git repository and create a new commit object, which contains a pointer to the parent commit, a tree object (representing a snapshot of the staging area), author information, committer information, and commit information.

[0107] In other embodiments, in step 3, there are also the following steps: a. Based on the importance coefficient and impact scope coefficient of the version update information, the version is marked with different levels by running the tag command using Git.

[0108] Specifically, regarding level marking, based on the importance coefficient and the impact coefficient, several different label levels can be designed to distinguish versions of different importance, for example: a. Major version (Major), which means the version containing major functional updates or architectural changes, which may destroy backward compatibility. The importance coefficient and impact coefficient of these versions are very high; b. Minor version (Minor), which adds new backward-compatible features and may contain some important bug fixes. The importance coefficient of these versions is relatively high, but the impact coefficient may vary depending on the specific nature of the new features; c. Patch version (Patch), which mainly fixes bugs and makes minor improvements, with little impact on functions and user interfaces. The importance coefficient and impact coefficient of these versions are relatively low.

[0109] Specifically, regarding the operation of the tag command, once the version level is determined, you can use Git's tag command to create the corresponding tag, for example: a. For major versions, you can use a 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 newfeatures"; b. For minor versions, you can use the vX.Y.0 format, where Y is the minor version number, for example, git tag-av1.2.0-m "Minor release with new features and bug fixes"; c. For revised versions, use the vX.YZ format, where Z is the revision number, for example, git tag-a v1.1.1-m "Patch release withcritical bug fixes".

[0110] Specifically, regarding the role of level tags, during the life cycle of a project, tags can help users quickly locate a specific version, whether it is for problem tracking, rolling back to an old version, or providing users with a stable release version. You can use the git tag command to list all tags, and use git show <tag>View detailed information about a specific tag and use git checkout <tag>or git switch <tag>Switch to the commit pointed to by a specific tag.

[0111] 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". This embodiment adopts method one, and in other embodiments, method two can be adopted.

[0112] Method 1: Daily update management. When adding, modifying, or deleting content in the knowledge base, treat these changes as if they were code. Use git add <filename> to add the updated file to the staging area. If you want to add all modified files, you can use git add .. Use meaningful commit messages to commit, such as "added new knowledge points" or "corrected incorrect explanations", etc., and execute git commit -m "detailed commit instructions".

[0113] Method 2: Branch update management. You can create branches for different topics, tasks, or versions. For example, create a "new feature development" branch to add new knowledge modules, or create an "error correction" branch to fix erroneous content in the knowledge base. Use git branch <branch name> to create a branch, and git checkout <branch name> to switch to a specific branch. After completing a specific task on a branch, merge the branch back to the main branch. Use git checkoutmaster to switch to the main branch, and git merge <branch name> to merge branches. If there is a conflict during the merge process, you need to manually resolve the conflict before committing. In Git, you can create branches for different topics, tasks, or versions for the knowledge base by following the steps below:

[0114] Step a, create a new branch step, determine the purpose of the branch, and make it clear which topic, task or version to create the branch for. For example, if it is for a new feature 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 an important bug, you can name it "bugfix-critical-error". For different versions, you can use a naming method such as "version-2.0". Use the command to create a branch. In the command line, switch to the directory where your knowledge base is located. Run the following command to create a new branch: gitcheckout -b<branch_name> ,in<branch_name> This is the name given to the branch.

[0115] Step b. Work on a branch and switch to a new branch. After creating a 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 right branch. Work on a specific topic, task, or version, and make corresponding modifications, add or delete files according to the purpose of the branch. For example, if you are adding new document content for a new topic, add this content to the knowledge base. If you are fixing a bug, find the problem and make code modifications.

[0116] Step c, commit the changes on the branch, add the changes to the staging area, use git add<file_name> The command adds the modified files to the staging area. If you want to add all the changes, you can use git add.. To commit the changes, use the git commit -m "describe changes" command to commit the changes and provide a meaningful commit message so that other users can understand what was done.

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

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

[0119] Step S401: Using Git software, a remote repository is established in all devices that use the medical knowledge base, and the git remote add command of the Git software is run to associate the remote repository with the Git repository;

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

[0121] Specifically, regarding the establishment of a remote repository, determine the hosting location of the remote repository, which can be a Git hosting service such as GitHub, GitLab, Bitbucket, or a self-hosted Git server within the organization. Once the hosting service or server is determined, you need to create a new repository on the platform and record the URL of the repository. Make sure that the Git software is installed on all devices that need to use the medical knowledge base. On each device, if the Git repository has not yet been initialized for the medical knowledge base project, you need to perform this step first. Add the URL of the remote repository to the Git repository of each device. Select a name for a remote repository, followed by 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.

[0122] Specifically, regarding the operation of the git push command, before executing the git push command, you must first confirm that the current branch is the branch you want to push updates to. Git allows users to work on different branches, each of which can have its own history and changes. Use the git branch command to view all branches, and use the git checkout command to switch to the correct branch. Before pushing any changes to the remote repository, you need to make sure that these changes have been submitted 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 you are on the correct branch and all changes have been committed, you can use the git push command to push the changes to the remote repository.

[0123] Specifically, regarding the synchronous push of version update results, by collaborating with remote repositories, the results of medical knowledge base version updates can be synchronized to multiple devices. The local repository can be associated with the remote repository. Use git remote add <remote repository name> <remote repository address>. Push local updates to the remote repository so that others can get the latest version. Use git push <remote repository name> <branch name>. Pull updates from the remote repository to the local to keep the local and remote synchronized. Use git pull <remote repository name> <branch name> to achieve the update of the medical knowledge base of multiple devices.

[0124] In other embodiments, in step 4, there are also the following steps: a. Testing and verifying the updated version of the medical knowledge base, and after the test and verification are correct, running the git push command of the Git software to push it.

[0125] Specifically, regarding the creation of the test environment and the test verification of the updated version, first create a test environment that should simulate the production environment as much as possible, but not be directly connected to the production environment to avoid potential risks. Deploy the updated version of the medical knowledge base to the test environment, including checking out the code base to the test server and configuring necessary resources such as the database and file system. Design test cases to verify whether all key functions of the knowledge base work as expected, including search functions, data retrieval accuracy, user interface interaction, etc. Evaluate the performance of the new version, such as response time, load bearing capacity, etc., check whether the new version is compatible with the old version data, and whether it works properly on different browsers, operating systems, and devices, and ensure that the new version does not introduce new security vulnerabilities. Use automated testing tools to execute test cases as much as possible to improve test efficiency and accuracy. For scenarios that cannot be automated or require human judgment, perform manual testing and record the execution results of each test case 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, perform regression testing to ensure that the newly introduced changes do not damage the original functions.

[0126] like Figure 6 As shown, in other embodiments, a medical knowledge base version management and synchronization method includes the above steps S1 to S4, and further includes:

[0127] Step S5: medical knowledge base version update marking and release;

[0128] Step S6: backup and restore of medical knowledge base version;

[0129] Step S7: The medical knowledge base version is updated and displayed.

[0130] Specifically, for step S5, when the knowledge base reaches an important milestone or release version, you can use a tag to mark it. For example, use git tag v1.0 to create a tag called "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>. You can view the history of medical knowledge base version updates and compare the medical knowledge base version update records. For example, use git log to view the submission history of the knowledge base to understand the updated content and device information of each version.

[0131] Specifically, for step S6, use git diff <commit hash value 1><commit hash value 2> to 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 specific version, you can use the git reset or git checkout command combined with a specific commit hash value or tag to achieve it.

[0132] Specifically, for step S7, use 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, you can consider combining Git with continuous integration / continuous deployment (CI / CD) tools to achieve automated building, testing and deployment.

[0133] like Figure 7 As shown, a medical knowledge base version management and synchronization system is used to execute the above-mentioned medical knowledge base version management and synchronization method. The system can efficiently track, manage and display the change history of the knowledge base, support parallel development and collaboration, and the system includes: Git version control integration module 1, difference comparison tool module 2, and medical knowledge base management module 3.

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

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

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

[0137] The 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.

[0138] Specifically, the Git version control integration module 1 is used to integrate the Git version control function 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 the existing system, manage all versions of knowledge base files through the Git repository, and record each submitted change. The difference comparison tool module 2 is used to develop a visual difference comparison tool to display the changes between different versions, realize the difference display at the file and directory level, support side-by-side comparison and unified difference view, and transmit the difference comparison results to the user interface for users to view and analyze. Through the Git Fork client, it provides an intuitive user interface and practical tools such as real-time code difference comparison, and supports multi-warehouse management and task list management. The medical knowledge base management module 3 is used as the core component of the clinical decision support system (CDSS). It assists clinical personnel by providing real-time decision suggestions, thereby reducing the occurrence of medical errors. The construction of the knowledge base usually includes a standard terminology library, a static knowledge base, a medical rule library, and an AI model library, which together constitute a knowledge service platform that can quickly respond to clinical needs and support intelligent applications of specialties and special diseases.

[0139] like Figure 8 As shown, in other embodiments, the Git version control integration module 1 includes: project initialization submodule 101, Git installation submodule 102, .gitignore file writing submodule 103, adding files to the repository submodule 104, first submission submodule 105, creating a remote repository submodule 106, and pushing to a remote repository submodule 107.

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

[0141] like Fig. 9 As shown, in other embodiments, the medical knowledge base management module 3 includes a knowledge base updating submodule 301 , an updating strategy formulation submodule 302 , and an execution effect monitoring submodule 303 .

[0142] Specifically, the knowledge base update submodule 301 is used to realize the continuous update and maintenance of the knowledge base through content management tools and version control technology. Based on the results of time series analysis, new knowledge points and update information are regularly introduced. The accuracy and reliability of the updated content are ensured through the quality control process. Not only an updated TCM knowledge base is generated, but also the timeliness and scientificity of the knowledge content are guaranteed. The implementation of this module provides a solid foundation for the continuous dissemination and popularization of TCM knowledge, and ensures the high quality and high credibility of the knowledge content. The knowledge base update submodule uses content management tools to update the knowledge base based on the results of time series analysis, performs version control through Git, records the content of each update, including new knowledge points and update information, and generates a knowledge base update record. The update strategy formulation submodule 302 designs an update strategy based on the knowledge base update record, uses the pandas library in Python to automatically analyze the update requirements, and sets parameters based on the frequency and priority of the update, so that the timely update of the knowledge base matches the user needs, and generates an update strategy plan. The execution effect monitoring submodule 303 performs quality control of the updated content based on the update strategy scheme, 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 TCM knowledge base.

[0143] Specifically, in the knowledge base update submodule 301, the update of the traditional Chinese medicine knowledge base is managed and recorded through the automated script and the version control system Git. This submodule uses the timing analysis results as the update trigger point, integrates Git through the content management tool (such as the CMS system), and automatically records each submitted change, including the newly added knowledge points and updated information. The record is stored in the version control system, and a new version number is generated for each update to ensure 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.

[0144] Specifically, in the update strategy formulation submodule 302, by analyzing the knowledge base update record, Python's pandas library is used to automatically analyze the update requirements. This submodule automatically analyzes and determines the update strategy based on the content and frequency of the update record, as well as the user's feedback and needs. The strategy includes determining the priority of knowledge points, the frequency of updates, and the relevant responsibility allocation. In this way, the update strategy scheme can ensure that the update of the knowledge base not only meets user needs, but also effectively utilizes resources, so that the knowledge base is kept up to date, while avoiding waste of resources.

[0145] Specifically, in the execution effect monitoring submodule 303, the updated knowledge base is quality controlled by the automated testing tool Selenium. This submodule selects appropriate test cases according to the update strategy scheme, determines the frequency of the test, and automatically performs the test of the Web interface. In this way, it can be ensured that the knowledge base after each update can meet the expected quality standards, and potential problems can be discovered and corrected in time. The generated updated traditional Chinese medicine knowledge base is not only rich in content and high in accuracy, but also has a friendly interface and a good user experience, which further enhances the practicality and user satisfaction of the system.

[0146] like Fig.10 As shown, 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:

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

[0148] Specifically, the branch and merge management module 4 is used to use the branch and merge functions of Git, support parallel development and collaboration, implement graphical interface operations for branch creation, switching, merging and conflict resolution, manage changes in different branches, and ensure the correctness and consistency of merge operations. The audit log module 5 is used to provide an audit log to record historical changes and operations of the knowledge base, implement a log recording system, track each submission, branch operation, merge and other key activities, and 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 implement a friendly user interaction design, including operation instructions, real-time feedback and error handling, receive user operation requests, and display version control results and audit information. The authority and access control module 7 is used to control the user's access rights to the knowledge base version control operation, implement role-based access control (RBAC), ensure that users can only perform authorized operations, and control access and operations to version control functions according to user permissions. The system integration and coordination module 8 is used to ensure that the modules of the system work together, conduct system testing and performance evaluation, implement interface standardization and data synchronization mechanism between modules, conduct integration testing and stress testing, and feed back system integration and test results to each module to guide system optimization and upgrade. The deployment and maintenance module 9 is responsible for the deployment, monitoring and maintenance of the system, ensuring the stable operation of the system, integrating the monitoring system, tracking system performance indicators in real time, implementing automated deployment and rollback mechanisms, and collecting system operation data and maintenance logs for continuous system improvement.

[0149] like Fig.11 As shown, in other embodiments, the branch and merge management module 4 includes a branch strategy submodule 401, a daily development process submodule 402, a code review submodule 403, a merge branch submodule 404, and a merge conflict resolution submodule 405.

[0150] Specifically, the branch strategy submodule 401 is used to formulate branch strategies, such as using Gitflow or a simple functional branch strategy, to facilitate the management of feature development, bug fixes, and releases. The daily development process submodule 402 is used to create a new branch from the main branch (usually master or main) when developing new features or fixing bugs, develop and test on the new branch, use git commit to record each meaningful change, regularly use git pull or git fetch and git merge to synchronize changes to remote branches, and use git push to push changes to local branches to remote repositories. The code review submodule 403 is used to perform code reviews before merging branches to ensure code quality and project standards. The merge branch submodule 404 is used to merge changes in feature branches back to the main branch using git merge or git rebase. The resolve merge conflict submodule 405 is used to manually resolve conflicts if conflicts occur during merging, and submit the resolved changes.

[0151] It should be understood that the embodiments of the present invention can be implemented in hardware, software or a combination thereof. Software can be stored in a volatile or non-volatile storage device (regardless of whether the 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 disk, or a tape. Moreover, the embodiments of the present invention can be implemented in a computer or portable terminal having a controller and a memory, and the memory is an example of a non-temporary computer-readable storage medium suitable for storing one or more programs including commands for implementing the embodiments of the present invention. Therefore, the present invention includes a program having a code for implementing the device or method defined by the claims, and a machine-readable non-temporary storage medium storing the program. The program can be transferred electrically by a medium such as a communication signal transmitted via a wired or wireless connection, and the program and its equivalent are included in the present invention.

[0152] The device may receive a program from a program providing device connected via a cable or wirelessly and store the program. The program providing device may include a program containing commands for implementing the embodiments of the present invention, a memory for storing information required by the embodiments of the present invention, a communication module for communicating with the mobile device via a cable or wirelessly, and a controller for transmitting the program to the device automatically or upon request of the device.

[0153] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.< / tag> < / tag> < / tag>

Claims

1. A medical knowledge base version management and synchronization method, used in electronic equipment, characterized in that: include: Initialize the medical knowledge base into a Git repository that can be recognized and monitored by the Git software through the Git software; Monitor the Git repository through Git software to obtain version update information of the medical knowledge base; Based on the obtained version update information, the version of the medical knowledge base is managed and updated through Git software; The updated version of the medical knowledge base is synchronized to all other devices using the medical knowledge base through Git software.

2. The medical knowledge base version management and synchronization method according to claim 1, characterized in that: Initializing the medical knowledge base into a Git repository that can be recognized and monitored by the Git software by using the Git software includes: Determine the directory where the medical knowledge base is located, which contains all medical knowledge files that need to be included in version control; By running the git init command of the Git software, the directory where the medical knowledge base is located is initialized as a Git repository, and all files in the Git repository are identified and monitored by the Git software.

3. The medical knowledge base version management and synchronization method according to claim 2, characterized in that: Create a .gitignore file in the root directory of the Git repository to list the files or directories that are not included in version control; Run the git add command of the Git software to add all files in the current directory to the staging area, and then run the git commit command of the Git software to submit all files to the Git repository.

4. The medical knowledge base version management and synchronization method according to claim 1, characterized in that: The method of obtaining the version update information of the medical knowledge base by monitoring the Git repository through the Git software includes: Monitor the status changes of the Git repository by running the git status command of the Git software; When a status change is detected, the git diff command of the Git software is run to compare the difference between the current workspace and the staging area or the most recent submission 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, characterized in that: Set a file system listener at the preset file system level. When the preset file system changes, the file system listener triggers the git status command of the Git software to check the status of the Git repository. 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. When the type of status change meets the preset conditions for version update, further execute the gitdiff command of the Git software; Through integrated intelligent analysis algorithms, key information changes in the medical knowledge base are identified and notifications are sent to the device; key information includes new disease diagnosis methods and drug updates.

6. The medical knowledge base version management and synchronization method according to claim 1, characterized in that: The method of managing and updating the version of the medical knowledge base through Git software based on the obtained version update information includes: Evaluate the importance coefficient and impact scope coefficient of version update information, and based on the evaluation results, use the preset version control strategy to update the version of the medical knowledge base; the version control strategy includes: the triggering conditions for the update and the update method used during the update; When performing a version update, run the git add command of the Git software to add the version update information to the staging area, and then run the git commit command of the Git software to commit the contents of the staging area to the Git repository; when submitting, attach the commit information containing the updated content and the purpose of the update; Among them, based on the importance coefficient and impact scope coefficient of the version update information, the version is marked with different levels by running the Git tag command.

7. The medical knowledge base version management and synchronization method according to claim 1, characterized in that: The method of synchronizing the updated version of the medical knowledge base to all other devices using the medical knowledge base through Git includes: Use Git software to create a remote repository in all other devices that use the medical knowledge base, and run the git add command of the Git software to associate the remote repository with the Git repository; Run the git push command of the Git software to push the updated version of the medical knowledge base to the remote warehouse of all devices; Among them, the updated version of the medical knowledge base is tested and verified. After the test and verification are correct, the gitpush command of the Git software is run to push it.

8. A medical knowledge base version management and synchronization system, characterized in that: Includes the following modules: A Git version control integration module, used to initialize the medical knowledge base into a Git repository that can be recognized and monitored by the Git software through the Git software; The difference comparison tool module is used to monitor the Git repository through the Git software to obtain the version update information of the medical knowledge base; A medical knowledge base management module, used to manage and update the version of the medical knowledge base through Git software based on the obtained version update information; The push to remote repository module is used to synchronize the updated version of the medical knowledge base to all devices using the medical knowledge base through Git software.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the medical knowledge base version management and synchronization method described in any one of claims 1 to 7 are implemented.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the computer program is executed by a processor, the steps of the medical knowledge base version management and synchronization method described in any one of claims 1 to 7 are implemented.

Images