A method for constructing a traditional Chinese medicine internal medicine knowledge graph based on clinical medical records

Abstract

The application provides a traditional Chinese medicine internal medicine knowledge graph construction method based on clinical medical records, comprising the following steps: receiving traditional Chinese medicine internal medicine clinical medical record data of brain disease patients through an intelligent chip deployed in a hospital internal data processing node, performing field unification, data content abstract generation, repeated data identification and unified treatment flow serial number mapping, forming a standardized diagnosis and treatment operation event set and an on-chip event index; constructing a diagnosis and treatment operation partial order chain according to a diagnosis and treatment operation dependency rule table, identifying a business path meeting a diagnosis and treatment operation partial order closed loop, determining an actual execution prescription version according to an effective medicine dispensing completion event, and packaging a diagnosis and treatment event package; extracting candidate entities from the diagnosis and treatment event package, generating direct candidate graph edges and derived candidate graph edges, training a behavior cloning model based on historical manual review logs; and outputting graph edge processing actions by using the behavior cloning model, combining a deterministic promotion check and a dependency check to form a main graph.

Description

Technical Field

[0001] This invention relates to the field of medical data processing technology, and in particular to a method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records. Background Technology

[0002] Traditional Chinese medicine (TCM) internal medicine clinical medical records typically include disease information, symptoms, syndromes, treatment methods, prescriptions, and the composition and dosage of Chinese herbal medicines. With the gradual improvement of hospital information systems, data generated during a single treatment session is often scattered across electronic medical record systems, doctor workstations, prescription systems, drug dispensing systems, and billing systems. To improve the efficiency of cross-referencing and unified management of clinical medical record data, it is necessary to convert this scattered data into a structured knowledge graph.

[0003] Existing knowledge graph construction methods typically aggregate data from different medical information systems based on patient identifiers, visit serial numbers, and data write times, then extract entities and relationships and write them into a graph database. However, different medical information systems experience asynchronous writes, delayed updates to older versions, multiple prescription modifications, changes in prescription review status, and batch dispensing. If the data sequence is determined solely based on write or update times, it is easy to incorrectly aggregate prescription versions that were not actually executed, expired prescription versions, or data that do not belong to the same treatment process, causing the entity relationships in the knowledge graph to deviate from the actual treatment process.

[0004] Furthermore, existing technologies typically write the extracted entity relationships directly into the graph database. When the source data is revised, the prescription version is replaced, or the execution status is revoked, it is difficult to accurately locate the affected graph edges and their derived relationships. Using methods such as batch deletion or rebuilding of local knowledge graphs not only increases the amount of data processing but may also mistakenly delete graph edges that still have valid source evidence. Therefore, this invention proposes a method for constructing a knowledge graph for Traditional Chinese Medicine internal medicine based on clinical medical records. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records, thereby solving the technical problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records includes the following steps: S1. Receive clinical medical record data of patients with brain diseases from the Department of Traditional Chinese Medicine by intelligent chips deployed in the data processing nodes of the hospital, perform field unification, data content summary generation, duplicate data identification and unified medical record number mapping, and form a standardized set of diagnosis and treatment operation events and on-chip event index. S2. Construct a partial order chain of diagnosis and treatment operations based on the diagnosis and treatment operation dependency rule table, identify partial order anomaly markers, determine the business path that satisfies the partial order closed loop of diagnosis and treatment operations, and determine the actual prescription version based on the effective drug dispensing completion event, and encapsulate the diagnosis and treatment event package. S3. Extract candidate entities from the diagnosis and treatment event package, generate direct candidate graph edges and derived candidate graph edges, bind source evidence and form state feature vectors, and train the behavior cloning model based on historical manual review logs; S4. Input the state feature vector into the behavior cloning model to obtain the graph edge processing actions and action confidence. Perform deterministic enhancement verification on direct candidate graph edges and dependency verification on derived candidate graph edges to form the main graph, edge-level evidence hosting layer, candidate graph edge retention area, rollback queue and edge-level dependency index. S5. Receive the newly added raw data, re-execute the event collection and diagnosis and treatment operation partial order chain construction, generate the failure event set and the supplementary diagnosis and treatment event package set, load the affected local subgraph according to the edge-level dependency index and perform local incremental correction, and generate the TCM internal medicine knowledge graph of brain diseases.

[0007] S1 specifically includes: receiving clinical medical record data of TCM internal medicine patients with brain diseases through a smart chip; writing data with missing required fields into the abnormal record area, the unmatched record area, or the diagnosis and treatment event unassignment area to form a set of original diagnosis and treatment data records; generating a data content summary based on the field mapping table, status mapping table, and unit mapping table to unify the field, status, time format, and dosage unit; identifying completely duplicate data and content-changed data to form diagnosis and treatment operation event data; completing the mapping based on the unified medical visit serial number mapping table; establishing an initial event group according to the patient identifier and the unified medical visit serial number; writing the on-chip event index item into the on-chip cache to form a standardized set of diagnosis and treatment operation events and an on-chip event index.

[0008] S2 specifically includes: reading the standardized set of diagnostic and treatment operation events and the on-chip event index; establishing a set of diagnostic and treatment operation dependencies based on the initial event group identifier, the diagnostic and treatment operation dependency rule table, the operation event type, the prescription version identifier, the predecessor version identifier, and the matching results of related fields; establishing a partial order graph of diagnostic and treatment operations with the diagnostic and treatment operation event data as event nodes and the set of diagnostic and treatment operation dependencies as directed edges; performing topological sorting; calculating the partial order closed loop completeness and marking partial order anomalies; identifying valid drug dispensing completion events based on the business path that satisfies the partial order closed loop of diagnostic and treatment operations; determining the actual prescription version; encapsulating the diagnostic and treatment event package; and writing the abnormal data into the diagnostic and treatment event pending attribution area.

[0009] S3 specifically includes: reading the set of diagnosis and treatment event packages and the actual prescription version; extracting candidate entities based on the entity type mapping table and terminology mapping table; generating candidate entity identifiers and standard entity keys to form a set of candidate entities carrying source anchors; generating direct candidate graph edges and derived candidate graph edges based on the candidate relationship rule table; binding source anchors, direct evidence identifiers, prior dependency edge identifiers, and state feature vectors to form a set of candidate graph edges carrying source evidence; reading historical manual review logs with final state confirmation markers to form a set of expert demonstration samples; training the behavior cloning model; generating model parameter files and verification information; and loading them into the smart chip for subsequent graph edge processing.

[0010] S4 specifically includes: reading the candidate graph edge set carrying source evidence and the behavior clone model loaded into the smart chip; verifying the model parameter file summary, state feature vector version, and action set version; outputting the graph edge processing action and action confidence; performing deterministic enhancement verification on direct candidate graph edges; executing main graph writing, edge-level evidence hosting, candidate graph edge retention or rollback request generation based on the enhancement verification result; and updating the list of valid source evidence according to the logical edge key; verifying derived candidate graph edges based on the derivation relationship rule table and the pre-dependent edge identifier, detecting corresponding directed loops, establishing edge-level dependency chains, and writing edge-level dependency index items into the on-chip cache to form an edge-level dependency index.

[0011] S5 specifically includes: receiving new raw data, completing field validation, field unification, summary generation, duplicate identification, unified medical record number mapping, and on-chip event index update; reconstructing the partial order chain of medical operations; calculating the partial order closed loop integrity and encapsulating medical event packages to form a set of failed events and a set of supplementary medical event packages; identifying affected basic edges and affected derived edges based on the set of evidence of failed sources and edge-level dependency indexes, and loading affected local subgraphs to form a set of local rollback requests; establishing local incremental correction transactions, migrating failed graph edges to the rollback area, updating entity node status, the list of valid source evidence, and edge-level dependency indexes, processing supplementary medical event packages, and generating a knowledge graph of traditional Chinese medicine internal medicine for brain diseases.

[0012] The beneficial effects of this invention are as follows: This invention establishes a partial-order chain of diagnostic and treatment operations based on a dependency rule table, eliminating the need to determine data sequence solely based on write or update times. This allows for accurate identification of the actual prescription version even with asynchronous writes, delayed writes, and multiple prescription modifications, improving the accuracy of clinical record data collection. Furthermore, by establishing an on-chip event index using a smart chip, the index fields and the original data storage address are stored only in the on-chip cache, avoiding the repeated loading of complete clinical record data, reducing data reads, and improving the efficiency of locating diagnostic and treatment operation events.

[0013] This invention binds the source anchor point, direct evidence identifier, and prior dependency edge identifier of candidate graph edges, ensuring that both basic and derived edges in the main graph have traceable data sources, thus reducing the risk of erroneous data spreading in the knowledge graph. It trains a behavioral cloning model using historical manual review logs and combines deterministic enhancement verification to perform layered writing of candidate graph edges. This preserves the experience gained from manual review while preventing low-confidence candidate graph edges from directly entering the main graph, thereby improving the efficiency of knowledge graph construction.

[0014] This invention identifies affected base edges and affected derived edges based on a list of valid source evidence and alternative dependency paths. It only loads the affected local subgraphs for incremental correction, avoiding the need for complete graph reconstruction or accidental deletion of graph edges that still possess valid source evidence. By synchronously updating the main graph, rollback region, and edge-level dependency index through local incremental correction transactions, it maintains consistency and traceability in the knowledge graph update process when source data is revised, prescription versions are replaced, or execution status is revoked. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of a method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Example: Figure 1 As shown in the figure, this embodiment provides a method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records, including the following steps: S1. Receive clinical medical record data of patients with brain diseases from the Department of Traditional Chinese Medicine by intelligent chips deployed in the data processing nodes of the hospital, perform field unification, data content summary generation, duplicate data identification and unified medical record number mapping, and form a standardized set of diagnosis and treatment operation events and on-chip event index. S2. Construct a partial order chain of diagnosis and treatment operations based on the diagnosis and treatment operation dependency rule table, identify partial order anomaly markers, determine the business path that satisfies the partial order closed loop of diagnosis and treatment operations, and determine the actual prescription version based on the effective drug dispensing completion event, and encapsulate the diagnosis and treatment event package. S3. Extract candidate entities from the diagnosis and treatment event package, generate direct candidate graph edges and derived candidate graph edges, bind source evidence and form state feature vectors, and train the behavior cloning model based on historical manual review logs; S4. Input the state feature vector into the behavior cloning model to obtain the graph edge processing actions and action confidence. Perform deterministic enhancement verification on direct candidate graph edges and dependency verification on derived candidate graph edges to form the main graph, edge-level evidence hosting layer, candidate graph edge retention area, rollback queue and edge-level dependency index. S5. Receive the newly added raw data, re-execute the event collection and diagnosis and treatment operation partial order chain construction, generate the failure event set and the supplementary diagnosis and treatment event package set, load the affected local subgraph according to the edge-level dependency index and perform local incremental correction, and generate the TCM internal medicine knowledge graph of brain diseases.

[0018] S1 specifically includes the following sub-steps: S110. By calling a preset interface through a smart chip deployed in the hospital's internal data processing nodes, the system receives clinical medical record data of patients with brain diseases from the electronic medical record system, doctor's workstation, prescription system, pharmacy prescription review system, drug dispensing system, and billing system. Patients with brain diseases are filtered based on the disease name field, disease code field, or existing disease tag field already stored in the electronic medical record system. This method only calls data already recorded in the hospital information system and does not re-determine whether a patient has a brain disease based on symptom entities, syndrome entities, treatment entity, or prescription data.

[0019] The preset interfaces include a clinical medical record data interface, a prescription data interface, a prescription review result interface, a dispensing result interface, and a billing confirmation interface. Each preset interface outputs incremental data according to the source system identifier, the source data record identifier, and the write-back time, or pushes a data change message when data changes occur in the corresponding medical information system.

[0020] The intelligent chip is a Field-Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuit (ASIC). The intelligent chip physically divides its circuitry into a data interface unit, a digest calculation unit, an on-chip cache, and an index processing unit. The digest calculation unit directly performs calculations to generate a data content digest using internally deployed dedicated hardware hash circuitry. The on-chip cache is implemented using on-chip SRAM (Static Random Access Memory). The index processing unit controls the reading and writing of data in the on-chip cache through hardware logic instructions to establish and update the on-chip event index.

[0021] Each received data record is encapsulated with the patient identifier, local medical record number, source system identifier, source data record identifier, operation event type, operation object identifier, operation time, write-back time, execution status, and original data content. For data output from the prescription system, pharmacy prescription review system, and drug dispensing system, the prescription version identifier, previous version identifier, and dispensing batch identifier are further encapsulated. Operation event types include at least medical record creation, medical record modification, medical record signing, prescription temporary storage, prescription modification, prescription submission, pharmacy prescription review, drug dispensing, and payment confirmation.

[0022] Patient ID, source system ID, source data record ID, operation event type, operation time, write-back time, and execution status are set as general required fields. Prescription version ID is set as a required field for prescription-related data. Data lacking general required fields is written to the abnormal record area for re-integration into this step after field correction. Data lacking local medical record number but retaining patient ID is written to the pending match record area. Prescription-related data lacking prescription version ID is written to the medical event pending attribution area. Data that passes the required field validation is combined into the original medical data record set.

[0023] S120. Read the original medical data record set and unify the fields according to the field mapping table, status mapping table, and unit mapping table. The field mapping table is used to convert local field names in various medical information systems into unified field names; the status mapping table is used to convert local status codes into the corresponding statuses of creation, modification, temporary storage, submission, prescription approval, prescription return, dispensing completion, cancellation, and billing confirmation; the unit mapping table is used to uniformly convert the dosage of traditional Chinese medicine into grams, while retaining the original dosage and original dosage unit before conversion.

[0024] Convert operation time and write-back time to millisecond-level timestamps in the same time zone; standardize character encoding, line break format, and paragraph numbering for medical record text; remove consecutive spaces without business meaning; and retain negation words, degree words, and time words. For the i-th data record, generate a data content summary according to the following formula:

[0025] in, This represents a summary of the data content of the i-th data record; Indicates the source system identifier; Indicates the source data record identifier; Indicates the type of operation event; This indicates the prescription version identifier; for data that does not involve prescription versions, it should be set to null. This represents standardized data content after field unification; the symbol " " indicates that strings are concatenated according to the preset field order; This indicates that the SHA-256 hash algorithm is used to generate a fixed-length digest.

[0026] Data with identical source system identifier, source data record identifier, and data content summary is identified as completely duplicated data. Only the record with the earliest write-back time is retained for subsequent processing, and the remaining data is written to the duplicate data mapping table. Data with identical source system identifier and source data record identifier but different data content summaries is identified as content-changed data. Each content-changed data record is retained separately, without direct overwriting based on write-back time. For example, if the same source data record records "Danshen 10g" and "Danshen 15g" respectively, two records are retained, and the actual business order is determined by S210-S230 based on the prescription version inheritance relationship. Data that has undergone field unification, summary generation, and duplicate data identification is encapsulated as diagnostic and treatment operation event data.

[0027] S130. Read the registration records, consultation records, or primary index records already saved in the hospital information system and establish a unified patient visit serial number mapping table. The unified patient visit serial number mapping table includes at least the patient identifier, unified patient visit serial number, source system identifier, and local patient visit serial number. For medical operation event data that can find a unique mapping relationship in the unified patient visit serial number mapping table, convert its local patient visit serial number to the corresponding unified patient visit serial number; for data that cannot find a unique mapping relationship, write it to the unmatched record area and do not include it in any initial event group.

[0028] For the i-th diagnostic and treatment event data, the initial event group identifier is generated according to the following formula:

[0029] in, This represents the initial event group identifier corresponding to the i-th diagnostic and treatment operation event data; Indicates patient identification; This indicates a unified medical record number.

[0030] Clinical operation event data with the same initial event group identifier are grouped into the same initial event group to form a standardized set of clinical operation events. For the i-th clinical operation event data, an on-chip event index item is created:

[0031] in, This represents the on-chip event index item corresponding to the i-th diagnostic and treatment operation event data; This indicates the storage address of the original data content in the hospital's internal secure data storage area; the definitions of the other symbols are consistent with the aforementioned definitions.

[0032] The on-chip event index entries are written to the on-chip cache in an orderly manner according to the initial event group identifier, forming the on-chip event index. The original text and prescription details are stored in the hospital's internal secure data storage area and are not written to the on-chip cache. A standardized set of diagnostic and treatment operation events is provided by the S210 to establish business dependencies between these events; the on-chip event index allows the S210 to read diagnostic and treatment operation event data according to the initial event group and allows the S510 to locate existing diagnostic and treatment operation event data corresponding to newly added data; a duplicate data mapping table allows the S510 to identify duplicate data rewritten due to interface retries.

[0033] S2 specifically includes the following sub-steps: S210: Read the standardized set of diagnostic and treatment operation events and the on-chip event index generated by S130, and extract the diagnostic and treatment operation event data corresponding to the same patient and the same visit according to the initial event group identifier. A diagnostic and treatment operation dependency rule table is pre-established. This table is generated based on the business processes, preset interface fields, and status codes in the hospital information system, and does not infer based on patient symptoms, syndromes, or prescription content. The diagnostic and treatment operation dependency rule table includes at least the preceding operation event type, the following operation event type, the associated field type, the allowed status of the preceding event, the allowed status of the following event, necessary dependency relationship markers, and optional auxiliary relationship markers. Necessary dependencies are used to determine whether the partial-order closed loop of the diagnostic and treatment operation is complete, and optional auxiliary relationships are used to supplement the recording of the diagnostic and treatment process.

[0034] For the a-th and b-th diagnostic and treatment operation event data in the same initial event group, determine whether to establish a directed connection from the a-th diagnostic and treatment operation event data to the b-th diagnostic and treatment operation event data according to the following formula:

[0035] in, Indicates a directed connection identifier; and These represent the operation event types for the diagnosis and treatment operation event data in items a and b, respectively. This indicates the combination of operation event types that are allowed to establish directed connections in the diagnostic and treatment operation dependency rule table; and These represent the corresponding initial event group identifiers; This indicates the matching result of the associated fields.

[0036] Medical record creation, modification, and signature are matched based on the operation object identifier; prescription storage, modification, and submission are matched based on the prescription version identifier and the identifier of the preceding version; prescription submission, pharmacy review, and drug dispensing completion are matched based on the prescription version identifier; and drug dispensing completion and billing confirmation are matched based on the settlement association identifier or the prescription version identifier. Directed connections that meet the judgment criteria are grouped into a set of diagnostic and treatment operation dependencies.

[0037] S220. For each initial event group, establish a partial order graph of treatment operations, using the treatment operation event data as event nodes and the set of treatment operation dependencies as directed edges between event nodes. Perform topological sorting on the partial order graph to obtain the partial order chain of treatment operations. Operation time and write-back time are only used for display sorting between event nodes that do not have direct dependencies and for priority verification under the same business dependency conditions, and are not used alone to determine the actual prescription version to be executed.

[0038] For the g-th initial event group, the partial order loop completeness is calculated according to the following formula:

[0039] in, This represents the partial order loop completeness of the g-th initial event group; This represents the set of directed connections actually established based on diagnostic and treatment event data; Represents the set of necessary directed connections determined according to the diagnostic and treatment operation dependency rule table; the symbol " " indicates the number of elements in the set.

[0040] A partially ordered closed-loop diagnostic and treatment operation refers to a complete business path where all necessary directed connections associated with the completion of a drug dispensing event have been established, the prescription version inheritance relationship is continuous, and the partially ordered diagnostic and treatment operation graph does not contain directed loops. If the partial order graph of diagnosis and treatment operations does not contain directed loops, and there is at least one prescription version inheritance path that can connect to the drug dispensing completion event, and the corresponding drug dispensing completion event carries a prescription version identifier and a dispensing batch identifier, then the corresponding business path is determined to satisfy the partial order closed loop of diagnosis and treatment operations.

[0041] For data that cannot match necessary preceding events, a preceding event missing flag is set; for data whose preceding version identifier cannot match an existing prescription version, a version inheritance interruption flag is set; for data where the drug dispensing completion event lacks a prescription version identifier or dispensing batch identifier, an execution object missing flag is set; for data with directed loops in the partial order graph of diagnosis and treatment operations, a directed loop flag is set; for data with conflicting dispensing completion events of the same prescription version that cannot be distinguished by dispensing batch, a multi-endpoint conflict flag is set; for data where the operation time or write-back time is inconsistent with the business dependency order, but the associated fields are completely matched, a time conflict flag is set. The time conflict flag does not prevent the encapsulation of diagnosis and treatment events; data corresponding to other partial order anomaly flags are written to the diagnosis and treatment event pending attribution area.

[0042] S230. Read the business path that satisfies the partial-order closed loop of diagnosis and treatment operations, and determine the drug dispensing event that has the execution status of dispensing completed, carries the prescription version identifier and dispensing batch identifier, can be associated with the pharmacy prescription review pass event and prescription submission event and has not been revoked as a valid drug dispensing completion event.

[0043] For the m-th valid drug dispensing completion event in the g-th initial event group, the actual prescription version and treatment event package identifier are determined according to the following formula:

[0044] in, Indicates the actual version of the prescription being executed; This indicates the completion of the dispensing of the m-th valid drug; This indicates the prescription version identifier read from the valid drug dispensing completion event; Indicates the identifier of the medical event package; Indicates the initial event group identifier; Indicates the batch identifier for the transfer; symbol " The meaning of “” is consistent with the definition in S120.

[0045] For each valid drug dispensing completion event, the corresponding medical record data, prescription version inheritance path, pharmacy prescription review data, drug dispensing data, source data records, partial order chain of treatment operations, actual executed prescription version, time conflict marker, and non-blocking partial order anomaly marker are encapsulated into a treatment event package. For prescription versions returned by pharmacy prescription review, only their treatment operation event data and version inheritance relationship are retained, and they are not identified as the actual executed prescription version; for cases where the same prescription version corresponds to multiple dispensing batches, treatment event packages are generated separately for each dispensing batch.

[0046] The generated treatment event packages are grouped into a treatment event package set for S310 to extract candidate entities; the actual executed prescription version is used by S310 to limit the data source of prescription entities, traditional Chinese medicine entities and dosage attributes, and is used by S420 to verify candidate graph edges; the patient identifier, unified medical record number, source system identifier, source data record identifier, prescription version identifier, previous version identifier, partial order anomaly marker and the reason for assignment in the treatment event pending assignment area are saved together, so that S510 can re-execute S210-S230 after receiving supplementary data or status change data.

[0047] S3 specifically includes the following sub-steps: S310: Read the set of medical event packages generated in S230 and the actual executed prescription version, and extract candidate entities based on the entity type mapping table. The entity type mapping table records at least the entity type, allowed data sources, field names, extraction methods, and terminology mapping table.

[0048] Brain disease entities are read only from the disease name field, disease code field, or existing disease label field already saved in the electronic medical record system. New brain disease entities are not derived from symptom entities, syndrome entities, treatment entities, or prescription data. Symptom entities are extracted from the chief complaint, present medical history, and follow-up visit record fields. Syndrome entities are extracted from the syndrome differentiation record field. Treatment entities are extracted from the treatment record or treatment plan field. Prescription entities, traditional Chinese medicine entities, and dosage attributes are read only from the prescription name field and prescription details field corresponding to the actual prescription version.

[0049] For unstructured medical record text, it is segmented by paragraph, sentence, and punctuation, retaining paragraph numbers, sentence numbers, and character start and end positions, and performing longest-word priority matching based on the terminology mapping table. When a unique mapping relationship exists, the original term is converted into a standard entity name; when multiple mapping results exist, they are retained as multiple candidate entities with ambiguity tags attached; when no mapping relationship exists, the original term is temporarily written into the standard entity name field with a "to be reviewed" tag attached. For expressions like "left limb numbness has lessened compared to before," the symptom entity "limb numbness" is extracted, and "left side" and "lessened compared to before" are written into the orientation attribute and change state attribute, respectively.

[0050] For the j-th candidate entity, the candidate entity identifier is generated according to the following formula:

[0051] in, This represents the candidate entity identifier of the j-th candidate entity, used to locate the candidate entity in the corresponding diagnosis and treatment event package; Indicates the diagnostic event package identifier; Indicates the candidate entity type; Indicates the standard entity name.

[0052] For the j-th candidate entity, generate the standard entity key according to the following formula:

[0053] in, The standard entity key represents the j-th candidate entity and is used to identify the same standard entity across different diagnostic event packages; the definitions of the remaining symbols are consistent with the aforementioned definitions.

[0054] The candidate entity identifier, standard entity key, original term, standard entity name, entity type, source diagnosis and treatment event package identifier, source system identifier, source data record identifier, structured field path or original text location, ambiguity marker and pending review marker are bound to form a candidate entity set carrying the source anchor.

[0055] S320. Read the candidate entity set carrying the source anchor point, and generate candidate graph edges according to the candidate relation rule table. The candidate relation rule table records at least the relation type, the allowed head entity type and tail entity type, the direct evidence judgment condition, the derived evidence judgment condition, and the type of preceding dependency edge. Allowed candidate relations include brain disease entities associated with symptom entities, symptom entities corresponding to syndrome entities, syndrome entities corresponding to treatment entities, treatment entities corresponding to prescription entities, prescription entities containing traditional Chinese medicine entities, and traditional Chinese medicine entities having dosage attributes.

[0056] Candidate graph edges that can directly locate complete relationship evidence based on source data record identifiers, structured field paths, or original text locations are identified as direct candidate graph edges and bound to direct evidence identifiers. Direct evidence identifiers are generated by performing SHA-256 hash calculations on the corresponding source anchor point. Candidate graph edges that cannot directly locate complete relationship evidence but can be formed by combining one or more direct candidate graph edges are identified as derived candidate graph edges and bound to all preceding dependency edge identifiers. A relationship must not be established solely because two candidate entities reside in the same diagnostic event package.

[0057] The process proceeds in the order of generating direct candidate graph edges, followed by generating derived candidate graph edges. For the k-th candidate graph edge, the candidate graph edge identifier is generated according to the following formula:

[0058] in, Indicates the edge identifier of the candidate graph; and These represent the candidate entity identifiers for the head entity and the tail entity, respectively. Indicates the candidate relation type; Indicates the source anchor point. For direct candidate graph edges, It consists of the source data record identifier, structured field path, or original text location; For derived candidate graph edges As the source anchor, the source anchor is generated by concatenating all the preceding dependency edge identifiers in alphabetical order. After concatenation, the concatenated string is processed by SHA-256 hash calculation.

[0059] For each candidate graph edge, a state feature vector is established, sequentially recording the partial-order closed-loop state of the diagnosis and treatment operation, the state of the source prescription version, the state of direct evidence, the number of preceding dependent edges, the source system type, the partial-order anomaly marker state, the ambiguity marker state, and the pending review marker state. A condition is recorded as 1 if it is met, and 0 if it is not met; a negative 1 is recorded when the source prescription version is involved but not the actual executed prescription version; the source system type and the partial-order anomaly marker state are converted to integer codes according to a preset encoding table.

[0060] The pre-defined coding table specifies that the electronic medical record system, doctor workstation, prescription system, pharmacy prescription review system, drug dispensing system, and billing system are respectively encoded as integers 1 to 6; the preceding event missing flag, version inheritance interruption flag, execution object missing flag, directed loop flag, multi-endpoint conflict flag, and time conflict flag are respectively encoded as integers 1 to 6; when there are no partial order exception flags, they are uniformly encoded as 0.

[0061] The candidate graph edge set carrying source evidence is composed of candidate graph edge identifiers, head entity identifiers, relation types, tail entity identifiers, source diagnosis and treatment event package identifiers, source system identifiers, source data record identifiers, source prescription version identifiers, source anchors, direct evidence identifiers, preceding dependency edge identifiers, and state feature vectors.

[0062] S330. Read historical manual review logs with final state confirmation markers from the hospital knowledge graph maintenance module. These logs must include at least candidate graph edge identifiers, source evidence fields, state feature vectors, manual review time, and graph edge processing actions. Write historical manual review logs lacking necessary fields or containing conflicting final state actions into the review log exception area. Use the state feature vectors from the remaining historical manual review logs as expert demonstration inputs, and the corresponding graph edge processing actions as expert demonstration actions, forming an expert demonstration sample set.

[0063] Graph edge processing actions are limited to managed actions, boosting actions, retention actions, and rollback actions, representing the writing of edge-level evidence to the managed layer, the main graph, the candidate graph edge retention area, and the rollback queue, respectively. A behavioral cloning model is used as the imitation learning model. The behavioral cloning model consists of an input layer, a first fully connected layer with 16 nodes, a second fully connected layer with 8 nodes, and an output layer with 4 nodes. The two fully connected layers use modified linear unit functions as activation functions, and the output layer uses a normalized exponential function to output the probabilities corresponding to the four types of graph edge processing actions.

[0064] The expert demonstration sample set was divided into a training set and a validation set, with a ratio of 80% and 20% respectively. The initial learning rate was set to 0.001, the number of training samples per batch was set to 32, and the maximum number of training epochs was set to 100. Training was stopped when the validation set loss did not decrease for 10 consecutive epochs. The training objective was:

[0065] in, This represents the cross-entropy loss value of the behavioral cloning model; Indicates the parameters of the behavioral cloning model; N represents the number of expert demonstration samples; This represents a set of actions consisting of four types of graph edge processing actions; This indicates whether the nth expert demonstration sample corresponds to action o; the value is 1 if it corresponds, and 0 otherwise. The behavioral cloning model represents the state feature vector based on the nth expert demonstration sample. Output the probability of action o.

[0066] After training is completed, a model parameter file, a model version identifier, a model parameter file summary, a state feature vector version, and an action set version are generated; the model parameter file and its verification information are loaded into the smart chip for the S410 to use.

[0067] S4 specifically includes the following sub-steps: S410 reads the candidate graph edge set carrying source evidence generated by S320, and the behavior clone model, model version identifier, model parameter file summary, state feature vector version, and action set version loaded into the smart chip by S330. Before calling the behavior clone model, the smart chip recalculates the current model parameter file summary and verifies whether the current model parameter file summary is consistent with the model parameter file summary recorded by S330; verifies whether the state feature vector version of the candidate graph edge to be processed is consistent with the state feature vector version corresponding to the behavior clone model; and verifies whether the action set version simultaneously includes managed actions, boosting actions, retained actions, and rollback actions.

[0068] If any validation fails, the behavior cloning model is not invoked; instead, the corresponding candidate graph edge is written to the edge-level evidence hosting layer and marked as uncallable. If all validations pass, the state feature vector of the k-th candidate graph edge is input into the behavior cloning model, and the graph edge processing action and action confidence are determined according to the following formula:

[0069] in, This represents the graph edge processing action corresponding to the k-th candidate graph edge; Indicates the confidence level of the action; This represents the state feature vector of the k-th candidate graph edge; the definitions of the other symbols are consistent with those in S330.

[0070] Action confidence threshold Set to 0.80, where, This represents the minimum action confidence level required to allow automatic execution of subsequent processing. When At any time, regardless of the action taken to process the graph edge, the corresponding candidate graph edge is written into the edge-level evidence custody layer, awaiting manual review; when At that time, the candidate graph edge identifier, graph edge processing action, action confidence and model version identifier are combined into a candidate graph edge action set for S420 to perform hierarchical writing.

[0071] S420. Read the set of candidate graph edge actions and perform deterministic boosting verification on the direct candidate graph edges. For the k-th direct candidate graph edge, calculate the boosting verification result according to the following formula:

[0072] in, This represents the boosting verification result of the k-th direct candidate graph edge; Indicate whether the source diagnostic event package satisfies the partial-order closed-loop diagnostic operation; This indicates the source prescription version verification result. The value is 1 when the candidate graph edge involves prescription entity, Chinese medicine entity or dosage attribute and the source prescription version is the actual executed prescription version. The value is 1 when the candidate graph edge does not involve prescription version. The value is 0 in other cases. Indicates whether there is direct evidence. This indicates whether the action confidence level has reached the action confidence threshold. This indicates whether there are no unresolved ambiguity markers or markers awaiting review. Unless otherwise specified, each condition is 1 if it is met, and 0 otherwise.

[0073] When the graph edge processing action is a lifting action and When the corresponding direct candidate graph edge is written into the main graph and marked as a base edge, the graph edge processing action is a lifting action but... When an action is taken, the corresponding candidate graph edge is written to the edge-level evidence hosting layer. For a hosting action, the corresponding candidate graph edge is written to the edge-level evidence hosting layer; for a retention action, the corresponding candidate graph edge is written to the candidate graph edge retention area, and the retention reason is recorded; for a rollback action, the target graph edge in the main graph is queried according to the logical edge key. If the target graph edge exists, a rollback request is generated and written to the rollback queue. If the target graph edge does not exist, the corresponding candidate graph edge is written to the edge-level evidence hosting layer and a prohibition on promotion flag is attached.

[0074] For the k-th candidate graph edge, the logical edge key is generated according to the following formula:

[0075] in, Represents the logical edge key of the k-th candidate graph edge; and The standard entity keys representing the head entity and the tail entity, respectively; Indicates the candidate relation type.

[0076] When writing to the main graph, if no identical logical edge key exists, a new graph edge is added; if identical logical edge keys already exist but with different source anchors, the new source anchor and direct evidence identifier are appended to the list of valid source evidence; if both the logical edge key and the source anchor are the same, the edge is not written repeatedly. This results in the initial version of the main graph, the updated edge-level evidence hosting layer, the candidate graph edge reservation area, and the rollback queue.

[0077] S430 reads the initial version of the main graph, the updated edge-level evidence hosting layer, and the derived candidate graph edges generated in S320, and verifies the derived candidate graph edges according to the derivation relationship rule table. The derivation relationship rule table records at least the derivation relationship type, the type of the preceding dependency edge, the upper limit of the preceding dependency path length, and whether the preceding dependency edges are required to originate from the same diagnostic event package.

[0078] For the k-th derived candidate graph edge, the dependency verification result is calculated according to the following formula:

[0079] in, This represents the dependency verification result of the k-th derived candidate graph edge; This represents a list of preceding dependency edge identifiers; Indicates the identifier of the preceding dependency edge; This represents the set of graph edges in the main graph that are in a valid state. This indicates the identifier of the source diagnosis and treatment event package corresponding to the preceding dependency edge; The symbol “∧” represents the identifier of the source diagnosis and treatment event package corresponding to the edge of the derived candidate graph; the symbol “∧” represents the logical AND operation. This indicates an indicator function; the value is 1 if the condition within the parentheses is true, and 0 otherwise.

[0080] when The graph edge processing action is to improve the action. If the action confidence reaches the action confidence threshold and the newly added dependency will not create a directed loop, the derived candidate graph edge is written into the main graph and marked as a derived edge. If any condition is not met, it is retained in the edge-level evidence hosting layer. Before adding a dependency, starting from the derived candidate graph edge, the process traverses backward along the preceding dependency edge. If the traversal result returns a derived candidate graph edge, a directed loop is determined to exist; the corresponding dependency is not written, and a dependency loop marker is added.

[0081] Using basic edges and derived edges as dependency nodes, and the dependency relationship between derived edges and preceding dependent edges as directed connections, an edge-level dependency chain is established. For graph edges in a valid state in the main graph, an edge-level dependency index is created, recording at least the graph edge identifier, logical edge key, graph edge type, graph edge state, source medical event package identifier, source prescription version identifier, list of valid source evidence, list of preceding dependent edge identifiers, list of subsequent derived edge identifiers, main graph storage address, and edge-level evidence hosting layer storage address. The edge-level dependency index is written to the on-chip cache to form an edge-level dependency index, which allows the S520 to locate affected basic edges, identify affected derived edges, and load affected local subgraphs.

[0082] S5 specifically includes the following sub-steps: S510 continuously receives new raw data output from the electronic medical record system, doctor workstation, prescription system, pharmacy prescription review system, drug dispensing system, and billing system. For the new raw data, it sequentially performs the following steps: mandatory field validation in S110, field unification in S120, data content summary generation, and duplicate data identification; and unified patient visit serial number mapping, initial event group aggregation, and on-chip event index update in S130, to obtain new medical operation event data.

[0083] When the unified medical record number mapping table is updated, the data in the record area to be matched is read, and the unified medical record number mapping and initial event group collection in S130 are re-executed; for data that obtains a unique mapping result, it is removed from the record area to be matched and included in the corresponding initial event group.

[0084] Based on the duplicate data mapping table generated by S120, completely duplicate data generated by interface retries is excluded. Based on the on-chip event index generated by S130, the initial event group where data changes occurred is located, and delayed write-over, content revision, execution status revocation, prescription version replacement, dispensing batch addition, and change of ownership of treatment event packages are identified. Prescription version replacement refers to the addition of a prescription version that is associated with an existing prescription version through a previous version identifier, and the addition of the prescription version has already formed a valid drug dispensing completion event; when only a prescription version is added but drug dispensing has not yet been completed, the existing prescription version is not marked as invalid.

[0085] For the initial event group where data changes have occurred, re-execute S210-S230 to re-establish the set of diagnostic and treatment operation dependencies and the partial order chain of diagnostic and treatment operations, recalculate the partial order closure completeness, and encapsulate the diagnostic and treatment event package. The set of failed events includes diagnostic and treatment event packages that no longer satisfy the partial order closure of diagnostic and treatment operations, the actual executed prescription version that has been replaced or revoked, the source data records whose original data content summaries are no longer valid after revision, and the source anchor points whose attribution has changed. The set of supplementary diagnostic and treatment event packages includes newly formed packages or those formed due to the elimination of partial order anomalies. For data in the diagnostic and treatment event attribution area that matches the current initial event group, re-execute S210-S230.

[0086] S520 reads the failure event set, the rollback queue generated by S420, and the edge dependency index generated by S430, and forms a failure source evidence set based on the failure source anchor point and the failure source data record identifier.

[0087] For the e-th basic edge, determine whether it belongs to the affected basic edges according to the following formula:

[0088] in, This indicates the failure flag of the e-th basic edge; This indicates an indicator function; it takes the value 1 if the condition within the parentheses is true, and 0 otherwise. This represents a list of valid source evidence for the e-th basic edge; Indicates the set of evidence for the source of failure; symbol " " indicates the set difference operation.

[0089] when When, only remove evidence of the source of failure and retain the underlying edges; when When this happens, the corresponding basic edge is determined as the affected basic edge.

[0090] For the r-th derived edge, determine whether it belongs to the affected derived edges according to the following formula:

[0091] in, This indicates that the derived edge of the r-th derived edge is invalid. Let represent the set of all dependent paths of the r-th derived edge; This represents a dependency path; x represents the base edge or the preceding derived edge in the dependency path; when x is a base edge... Calculate according to the basic edge failure judgment formula; when x is a previous derived edge, let ,in, This indicates the failure flag of the derived edge corresponding to the preceding derived edge; the symbol " "Indicates multiplication; symbol " "" indicates summation.

[0092] when When, preserve derived edges and remove invalid dependency paths; when When this happens, the corresponding derived edge is identified as the affected derived edge.

[0093] The affected base edges, affected derived edges, entity nodes directly connected to the affected base edges and affected derived edges, supporting edges used to determine alternative dependency paths, a list of valid source evidence, and edge-level dependency index items are combined to form an affected local subgraph. Rollback requests triggered by the failure event set are merged with existing rollback requests in the rollback queue into a local rollback request set.

[0094] S530. Establish local incremental correction transactions for the set of local rollback requests. Each local incremental correction transaction includes at least the correction transaction identifier, the identifier of the main graph version before correction, the storage address of the affected local subgraph, the storage address of the rollback area, the edge-level dependency index correction record, the correction transaction status, the creation time, and the commit time. The correction transaction status includes the ready state, the executing state, the committed state, and the rolled back state.

[0095] After updating the local incremental correction transaction to the running state, incremental corrections are performed on the affected local subgraphs. For base edges that still have valid source evidence, only the list of valid source evidence is updated; for affected base edges whose list of valid source evidence is empty, their graph edge status is updated to the rolled-back state, and the graph edge data, logical edge key, failure reason, and migration time are written to the rollback area. For derived edges that still have complete valid dependency paths, only the failed dependency paths are removed; for affected derived edges that do not have complete valid dependency paths, they are migrated to the rollback area, and the list of preceding dependent edge identifiers and the list of subsequent derived edge identifiers are updated synchronously.

[0096] After the graph edges are migrated, entity nodes are not directly deleted. Entity nodes that are still connected to valid graph edges in the main graph are retained; entity nodes that are no longer connected to valid graph edges in the main graph but still have valid source anchors are marked as dormant nodes; entity nodes that are no longer connected to valid graph edges in the main graph and whose source anchors have all become invalid are migrated to the rollback area.

[0097] For the supplementary treatment event package set, execute steps S310, S320, and S410-S430 sequentially, and call the behavior cloning model loaded in S330. Regenerate state feature vectors for data matching the supplementary treatment event packages in the edge-level evidence hosting layer and the candidate graph edge retention area, and re-execute steps S410-S430. After completing graph edge migration, entity node state update, supplementary treatment event package writing, and edge-level dependency index synchronization update, update the local incremental correction transaction to the committed state. If an interruption occurs during execution, restore the main graph to its pre-correction version and update the local incremental correction transaction to the revoked state.

[0098] This generates an incrementally corrected knowledge graph of brain diseases in Traditional Chinese Medicine (TCM) internal medicine.

[0099] All the above formulas are performed using dimensionless numerical calculations; the relevant formulas are based on empirical models that approximate the real situation, obtained through extensive data collection and software simulation fitting. The preset parameters and thresholds involved in the formulas can be conventionally set and adjusted by those skilled in the art according to the physical constraints of the actual application scenario.

[0100] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0101] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0102] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records, characterized in that, Includes the following steps: S1. Receive clinical medical record data of patients with brain diseases from the Department of Traditional Chinese Medicine by intelligent chips deployed in the data processing nodes of the hospital, perform field unification, data content summary generation, duplicate data identification and unified medical record number mapping, and form a standardized set of diagnosis and treatment operation events and on-chip event index. S2. Construct a partial order chain of diagnosis and treatment operations based on the diagnosis and treatment operation dependency rule table, identify partial order anomaly markers, determine the business path that satisfies the partial order closed loop of diagnosis and treatment operations, and determine the actual prescription version based on the effective drug dispensing completion event, and encapsulate the diagnosis and treatment event package. S3. Extract candidate entities from the diagnosis and treatment event package, generate direct candidate graph edges and derived candidate graph edges, bind source evidence and form state feature vectors, and train the behavior cloning model based on historical manual review logs; S4. Input the state feature vector into the behavior cloning model to obtain the graph edge processing actions and action confidence. Perform deterministic enhancement verification on direct candidate graph edges and dependency verification on derived candidate graph edges to form the main graph, edge-level evidence hosting layer, candidate graph edge retention area, rollback queue and edge-level dependency index.

2. The method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to claim 1, characterized in that, Also includes: S5. Receive the newly added raw data, re-execute the event collection and diagnosis and treatment operation partial order chain construction, generate the failure event set and the supplementary diagnosis and treatment event package set, load the affected local subgraph according to the edge-level dependency index and perform local incremental correction, and generate the TCM internal medicine knowledge graph of brain diseases.

3. The method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to claim 1, characterized in that, S1 specifically includes: The system receives clinical medical records of patients with brain diseases from the Department of Traditional Chinese Medicine through a smart chip. Data with missing required fields is written into the abnormal record area, the unmatched record area, or the diagnosis and treatment event unassigned area to form a set of original diagnosis and treatment data records. Based on the field mapping table, status mapping table, and unit mapping table, the fields, status, time format, and dosage unit are unified to generate a data content summary, identify completely duplicate data and content change data, and form diagnostic and treatment operation event data.

4. The method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to claim 3, characterized in that, It also includes: completing the mapping based on the unified medical record number mapping table, establishing an initial event group according to the patient identifier and the unified medical record number, writing the on-chip event index item into the on-chip cache, and forming a standardized set of diagnosis and treatment operation events and an on-chip event index.

5. The method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to claim 1, characterized in that, S2 specifically includes: Read the standardized set of diagnostic and treatment operation events and the on-chip event index, and establish a set of diagnostic and treatment operation dependencies according to the initial event group identifier, the diagnostic and treatment operation dependency rule table, the operation event type, the prescription version identifier, the predecessor version identifier, and the matching results of the associated fields. A partial order graph of diagnostic and treatment operations is constructed using diagnostic and treatment operation event data as event nodes and a set of diagnostic and treatment operation dependencies as directed edges. Topological sorting is performed, the partial order closed loop integrity is calculated, and partial order anomalies are marked. Based on the business path that satisfies the partial-order closed loop of diagnosis and treatment operations, identify valid drug dispensing completion events, determine the actual prescription version, encapsulate the diagnosis and treatment event package, and write abnormal data into the diagnosis and treatment event pending attribution area.

6. The method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to claim 1, characterized in that, S3 specifically includes: Read the set of diagnosis and treatment event packages and the actual prescription version, extract candidate entities based on the entity type mapping table and terminology mapping table, generate candidate entity identifiers and standard entity keys, and form a set of candidate entities carrying source anchors; Based on the candidate relationship rule table, direct candidate graph edges and derived candidate graph edges are generated, and source anchors, direct evidence identifiers, prior dependency edge identifiers and state feature vectors are bound to form a set of candidate graph edges carrying source evidence.

7. The method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to claim 6, characterized in that, Also includes: Read the historical manual review logs with final state confirmation markers, form an expert demonstration sample set, train the behavior cloning model, generate model parameter files and verification information, and load them into the smart chip for subsequent graph edge processing.

8. The method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to claim 1, characterized in that, S4 specifically includes: Read the candidate graph edge set carrying source evidence and the behavior clone model loaded into the smart chip, verify the model parameter file summary, state feature vector version and action set version, and output the graph edge processing action and action confidence. Perform deterministic enhancement verification on direct candidate graph edges, and based on the enhancement verification results, execute main graph writing, edge-level evidence hosting, candidate graph edge retention or rollback request generation, and update the list of valid source evidence according to the logical edge key; Based on the derivation relationship rule table and the preceding dependency edge identifier, the edges of the candidate graph are verified, the corresponding directed loops are detected, the edge-level dependency chain is established, and the edge-level dependency index items are written to the on-chip cache to form the edge-level dependency index.

9. A method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to claim 2, characterized in that, S5 specifically includes: Receive new raw data, complete field validation, field unification, summary generation, duplicate identification, unified medical visit serial number mapping and on-chip event index update, rebuild the partial order chain of medical operation, calculate the partial order closed loop integrity and encapsulate the medical event package to form a set of failure events and a set of supplementary medical event packages. Based on the failure source evidence set and edge-level dependency index, the affected base edges and affected derived edges are identified, and the affected local subgraphs are loaded to form a local rollback request set.

10. A method for constructing a knowledge graph of traditional Chinese medicine internal medicine based on clinical medical records according to claim 9, characterized in that, Also includes: Establish local incremental correction transactions, migrate failed graph edges to the rollback area, update entity node states, valid source evidence lists, and edge-level dependency indexes, process supplementary diagnosis and treatment event packages, and generate a knowledge graph of traditional Chinese medicine internal medicine for brain diseases.

Images