Hospital logistics scheduling system and method based on large language model

Abstract

The application discloses a hospital logistics scheduling system and method based on a large language model, relates to knowledge question answering, and comprises the following steps: constructing a logistics service data warehouse; reading structured data from the logistics service data warehouse, performing semantic analysis on text data in the structured data by using a large language model, and generating knowledge triples; fusing knowledge in the knowledge triples by calculating vector similarity, and constructing a logistics service knowledge graph according to the fused knowledge triples; receiving a natural language service request of a user, performing intention recognition by using the large language model, and converting the extracted intention into structured query data; searching in the logistics service knowledge graph according to the structured query data, obtaining resource state data from the logistics service data warehouse, and generating a scheduling scheme by a scheduling intelligent agent based on a LangChain framework; and the application effectively solves the problem of low scheduling decision efficiency caused by information overload in hospital logistics equipment fault processing.

Description

Technical Field

[0001] This application relates to the field of knowledge-based question answering, and in particular to a hospital logistics scheduling system and method based on a large language model. Background Technology

[0002] With the rapid development of the healthcare industry and the continuous expansion of hospital scale, the types and complexity of hospital logistics services have increased significantly, encompassing various service types such as medical equipment repair, electromechanical equipment repair, security equipment repair, engineering repair, patient accompaniment during examinations, emergency cleaning, and hazard reporting. As a crucial support for ensuring the normal operation of medical activities, the efficiency of hospital logistics services directly impacts the quality of medical services. However, traditional manual dispatching methods require a large number of personnel to process various service orders, resulting in high human resource costs and long dispatch response times. Especially when dealing with emergency faults, the inability to quickly obtain and analyze relevant information often delays the optimal handling time.

[0003] While existing intelligent dispatching systems for hospital logistics have achieved a certain degree of information management, they face serious problems with dispatching decision-making efficiency in practical applications. Specifically:

[0004] First, scheduling decisions require consideration of a massive amount of information, including historical equipment failure records, maintenance personnel skill profiles, current task allocation status, equipment location information, and other multi-dimensional data. Traditional systems, when processing this vast amount of information, either rely on simple rule matching leading to poor decision-making quality, or require dispatchers to manually query multiple system interfaces to obtain information, severely impacting scheduling efficiency.

[0005] Secondly, the existing system lacks an effective mechanism for utilizing historical experience. A large number of historical fault handling cases and successful experiences are scattered and stored in different databases, which cannot be quickly retrieved and referenced when making scheduling decisions. This results in each scheduling process being like "starting from scratch," making it impossible to learn from past best practices.

[0006] Furthermore, with the rise of large language model technology, although its powerful semantic understanding and reasoning capabilities have provided new possibilities for intelligent scheduling, the inherent context window limitation of large language models has become a key bottleneck restricting their application in hospital logistics scheduling scenarios. When all relevant fault information, personnel information, historical cases, etc., need to be input into the model for comprehensive decision-making, information truncation often has to be performed due to exceeding the context limit, resulting in the loss of key information and seriously affecting the quality and feasibility of the scheduling plan.

[0007] Therefore, how to effectively organize and utilize massive amounts of logistics service data under the contextual constraints of a large language model to achieve rapid and accurate intelligent scheduling decisions has become a pressing technical challenge for hospital logistics service management. Summary of the Invention

[0008] To address the low scheduling efficiency of hospital logistics services in existing technologies, this application provides a hospital logistics scheduling system and method based on a large language model. It adopts a hierarchical information processing architecture and utilizes the Tool call mechanism and Prompt template of the LangChain framework to effectively solve the problem of low scheduling decision efficiency caused by information overload in the handling of hospital logistics equipment failures.

[0009] One aspect of this application provides a hospital logistics scheduling system based on a large language model, comprising: a data warehouse module, which receives raw data from hospital logistics services, extracts, transforms, and loads the raw data using ETL, and constructs a logistics service data warehouse using a star database architecture containing fact tables and dimension tables; a knowledge extraction module, which obtains structured data from the logistics service data warehouse, performs semantic parsing on the text data in the structured data using a large language model, identifies entities containing equipment names, fault types, handling measures, and handling personnel through named entity recognition, and obtains the relationships between entities through relation extraction to obtain knowledge triples containing entities and relations; a knowledge question answering module, which uses workflow orchestration based on the LangChain framework to construct a logistics service knowledge graph based on the knowledge triples; and receives natural language queries from users. The system comprises four modules: a request module, a visualization module, and a report generation module. The visualization module uses a large language model to obtain the user's query intent, retrieves results from the logistics service knowledge graph, and returns the results. The report generation module generates a logistics service analysis report with fault analysis and handling suggestions based on the visualization results, a preset report template, and user-customized requirements. The process management module stores hospital organizational structure data, employee information, job responsibilities, and standard logistics service processes as resource status data. The intelligent scheduling module builds a scheduling agent based on LangChain's Prompt and Agent modules, generating personnel scheduling plans based on the logistics service analysis report and resource status data. The data security module performs anonymization processing on the resource status data.

[0010] Another aspect of this application provides a hospital logistics scheduling method based on a large language model, comprising: S1, collecting raw data of hospital logistics services, preprocessing the raw data through data extraction, transformation and loading, storing the preprocessed data according to a star database architecture, and constructing a logistics service data warehouse; S2, reading structured data from the logistics service data warehouse, performing semantic parsing of the text data in the structured data using a large language model, identifying entities through named entities, obtaining the relationships between entities through relation extraction, and generating knowledge triples; S3, converting the entities and relations in the knowledge triples into... The system performs knowledge fusion by calculating vector similarity and constructs a logistics service knowledge graph based on the fused knowledge triples. Step S4 receives natural language service requests from users, performs intent recognition using a large language model, and converts the extracted intent into structured query data. Step S5 retrieves data from the logistics service knowledge graph based on the structured query data, and simultaneously obtains resource status data from the logistics service data warehouse. A scheduling scheme is then generated using a scheduling agent based on the LangChain framework. Step S6 visualizes the scheduling scheme and generates a logistics service analysis report based on the logistics service knowledge graph and the scheduling scheme.

[0011] Furthermore, S1 involves constructing a logistics service data warehouse, including: collecting raw hospital logistics service data from the business database of the hospital logistics management system, including equipment warranty records, maintenance logs, personnel schedules, and task completion records; performing data extraction processing on the raw data, extracting time fields, equipment identification fields, fault description fields, personnel handling fields, and processing result fields from different data sources; performing data transformation processing on the extracted data, including unifying time data in different formats to a standard time format, converting text-based equipment identification to a unified encoding, and cleaning fault description text to remove invalid characters; performing data loading processing on the transformed data, loading business data into the fact table according to a star database architecture, and loading equipment attributes, personnel attributes, and time attributes into the corresponding dimension tables; establishing the relationship between the fact table and the dimension tables, where the fact table is connected to each dimension table through foreign keys, forming a star structure with the fact table as the center and the dimension tables surrounding it, serving as the logistics service data warehouse.

[0012] In particular, traditional relational database designs, such as highly normalized snowflake architectures, while reducing data redundancy, require multiple table join operations when dealing with hospital logistics queries, making it difficult to meet the demands of emergency response. On the other hand, completely denormalized designs can lead to data update anomalies and wasted storage.

[0013] The core design philosophy of the star-based database architecture in this application is "centered on business facts and supported by analytical dimensions." In the context of hospital logistics services, every equipment failure handling, every preventative maintenance, and every emergency dispatch constitutes a specific business fact. These facts form the records in the fact table, which includes core metrics such as event ID, timestamp, equipment ID, failure type, handler ID, processing time, and processing result.

[0014] Four key dimension tables were constructed around the fact table. The equipment dimension table not only stores static attributes of equipment such as brand, model, and purchase date, but more importantly, records dynamic attributes such as department affiliation, maintenance status, and importance level—attributes that directly impact scheduling decisions. The personnel dimension table goes beyond a simple roster, constructing a complete skills matrix that records each engineer's certification level, area of ​​expertise, and historical performance ratings. The time dimension table fully considers the hospital's operational characteristics, marking hospital-specific time attributes such as holidays, night shifts, and peak surgical periods. The location dimension table adopts a hierarchical design, from the hospital area down to buildings, floors, departments, and rooms, supporting spatial analysis at different granularities.

[0015] In the star schema of this application, when an emergency fault report is received, the system only needs a single table join operation to obtain complete historical information: starting from the fact table, it connects to the device dimension table via device ID to obtain device details, connects to the personnel dimension table via personnel ID to obtain the engineer most proficient in handling this type of fault, connects to the time dimension table via time ID to determine if it is a special time period, and connects to the location dimension table via location ID to determine the device location. This "one-hop reachable" query pattern keeps the response time of complex queries within 100 milliseconds. Furthermore, the hospital's organizational structure, equipment types, and staffing are constantly changing. The star schema allows each dimension table to be updated independently without affecting the fact table and other dimension tables. For example, when a hospital adds a new department or introduces new equipment, it only needs to add a record to the corresponding dimension table without modifying the complex table structure. This flexibility is crucial for rapidly developing medical institutions.

[0016] Further, S2 generates knowledge triples, including: reading business data containing fault description and processing result fields from the fact table of the logistics service data warehouse, reading corresponding equipment attribute data and personnel attribute data from the dimension table, and combining the read data to form structured data; extracting text data of fault description and processing result fields from the structured data, inputting the text data into a large language model for semantic parsing, and obtaining parsed text with semantic annotations; performing named entity recognition on the parsed text to identify equipment name entities, fault type entities, processing measure entities, and processing personnel entities, and assigning a unique identifier to each entity; based on the identified entities, analyzing the contextual relationships of entities in the text through relation extraction, extracting the fault occurrence relationship between the equipment name entity and the fault type entity, the solution relationship between the fault type entity and the processing measure entity, and the executor relationship between the processing measure entity and the processing personnel entity; using entities as nodes and relations as edges, generating knowledge triples in the format of subject entity-relationship-object entity, where each knowledge triple is represented as a structure of <entity 1, relation, entity 2>.

[0017] Furthermore, S3, constructing a logistics service knowledge graph based on the fused knowledge triples includes: extracting entities and relations from each knowledge triple, mapping entities and relations to a vector space using word embeddings to generate fixed-dimensional vectors; calculating the cosine similarity between corresponding entity vectors for different knowledge triples, and determining that the corresponding entities are similar entities when the similarity is greater than a preset threshold; fusing knowledge triples of similar entities, including merging different descriptions pointing to the same entity, unifying entity naming, and eliminating duplicate relations to generate a fused knowledge triple set; and constructing a directed graph structure as the logistics service knowledge graph, using entities in the fused knowledge triple set as graph nodes and relations as graph edges, where each node stores entity attributes and each edge stores relation types.

[0018] In particular, there is a serious problem of "different names for the same thing" in the field of hospital logistics services. That is, the same equipment, the same fault, and the same maintenance measure may be described completely differently in records from different periods and by different personnel. For example, equipment names may be "ventilator," "breathing apparatus," "artificial ventilator," "ventilator," or "respiratory support equipment"; fault descriptions may be "abnormal pressure," "pressure alarm," "pressure value too high," or "pressure sensor failure"; and maintenance measures may be "replace sensor," "replace with a new sensor," "sensor replacement," or "install a new sensor." This diversity of descriptions renders traditional string matching methods completely ineffective, making it impossible to effectively accumulate and utilize historical experience.

[0019] This application employs a pre-trained medical domain word embedding model to map each entity and relation to a high-dimensional vector space. This mapping is not a simple character encoding, but rather based on deep semantic understanding: although "ventilator" and "ventilator" are completely different characters, they are very close in the vector space; "pressure abnormality" and "pressure sensor failure" can be identified as related concepts; and abbreviations of technical terms (such as "SpO2" and "blood oxygen saturation") can be correctly associated.

[0020] By calculating the cosine similarity between entity vectors, the system can intelligently identify different representations of the same entity: similarity > 0.85: highly similar, can be merged (e.g., "ventilator" and "artificial ventilator"); similarity 0.7-0.85: moderately similar, requires further verification (e.g., "abnormal pressure" and "abnormal flow"); similarity < 0.7: different entities, remain independent; this vector-based similarity calculation is better at capturing semantic similarity than traditional methods such as edit distance.

[0021] Further, in step S4, the extracted intent is converted into structured query data, including: receiving natural language service requests input by the user through a natural language interactive interface, such as equipment fault query requests, maintenance personnel query requests, historical fault statistics requests, or maintenance progress query requests; preprocessing the natural language service requests, including word segmentation, stop word removal, and part-of-speech tagging, to generate preprocessed request text; inputting the preprocessed request text into a large language model, guiding the large language model to identify the user intent through prompt word engineering, and extracting the intent type and query parameters, such as query intent, statistical intent, scheduling intent, or analysis intent; generating structured query data containing query type, query object, query conditions, and query time range based on the identified intent type and query parameters; verifying the structured query data, checking whether the query object exists in the logistics service knowledge graph constructed in step S3, and if it does not exist, returning a prompt message to prompt the user to re-enter the data, and if it exists, passing the verified structured query data to subsequent steps.

[0022] Furthermore, in step S5, a scheduling scheme is generated through an intelligent agent, including: parsing the query type and query object based on the structured query data generated in step S4, performing graph traversal retrieval in the logistics service knowledge graph to obtain entity nodes and relation edges related to the query object; performing similar case retrieval in the logistics service knowledge graph based on entity nodes, retrieving historical processing cases with similarity greater than a preset threshold by calculating the similarity between the current fault entity and historical fault entities; based on the retrieved historical processing cases, statistically analyzing the success rate and average processing time of different processing personnel when handling similar faults, identifying the optimal processing mode, and generating a personnel recommendation list and estimated processing time based on historical processing cases; obtaining current resource status data from the logistics service data warehouse, including real-time personnel location, current task status, and equipment operating status, and obtaining a list of personnel to be selected based on the personnel recommendation list; and generating a scheduling scheme based on the input scheduling information using a large language model based on the LangChain framework.

[0023] In particular, traditional scheduling systems often store historical data as isolated records, failing to effectively utilize the relationships and implicit experiences between cases. Step S5, through graph traversal retrieval in the knowledge graph, not only obtains directly related entity nodes, but more importantly, it acquires the experiential knowledge contained in the relational edges. Graph traversal can discover indirect but important connections, such as "ventilator malfunction → previously caused → abnormal oxygen supply → requires → check of backup oxygen supply equipment." This multi-hop reasoning can prevent cascading failures. Relational edges record implicit experiences such as "which failure usually accompanies which other failure" and "which handling method is most effective for which type of equipment," enabling the system to think like an experienced engineer.

[0024] Furthermore, by calculating the semantic similarity between current faulty entities and historical faulty entities, the system achieves experience transfer across time and device models. This vector space-based similarity calculation can identify fault patterns that appear different on the surface but are essentially similar. Even for faults in newer device models, similar fault handling experience from older models can be found through similarity matching, solving the "cold start" problem.

[0025] Furthermore, based on the LangChain framework, a scheduling scheme is generated through a large language model, including: constructing a hierarchical scheduling agent architecture based on the LangChain framework; configuring an Agent module for hierarchical information management; establishing a three-layer information structure consisting of a core information layer, an extended information layer, and a detailed information layer; defining the priority and invocation strategy for each layer; performing hierarchical processing of scheduling information, using the query object in the structured query data as the core information layer, the list of candidates and the estimated processing time as the extended information layer, and the detailed content of historical processing cases and current resource status data as the detailed information layer; and constructing a Prompt template system that supports hierarchical invocation, including initial decision templates and information... Supplementary and decision templates are used. The initial decision template only contains input placeholders from the core information layer to avoid exceeding the context window limit of the large language model on the first call. During the first round of scheduling decisions, the relevant entity nodes of the query object from the core information layer are input into the large language model to analyze the fault type and urgency, generating a preliminary scheduling strategy. Based on the preliminary scheduling strategy, the LangChain Tool call mechanism is used to extract candidates matching the initial scheduling strategy from the candidate list in the extended information layer, along with their corresponding estimated processing times. The current task status of the candidates is also obtained from the detailed information layer, generating a second-round decision context. Based on the second-round decision context, the final scheduling scheme is generated using the large language model. The large language model uses DeepSeek.

[0026] In particular, traditional large language model applications often adopt a "one-time full input" approach, attempting to cram all relevant information into a single Prompt. This approach encounters a fatal problem in hospital logistics scheduling scenarios: the complete context of a complex fault may contain tens of thousands of tokens (historical cases, personnel files, equipment parameters, etc.), far exceeding DeepSeek's 32K context limit.

[0027] In this application, the core information layer (500-800 tokens) contains only the most critical fault identifiers, types, locations, and other necessary information, ensuring that the first call will never exceed the limit; the extended information layer (2000-3000 tokens) contains medium-granularity information such as brief information on candidates and preliminary statistical data; the detailed information layer (up to tens of thousands of tokens) contains complete historical cases, detailed personnel files, etc., stored externally but accessible on demand. This design decouples information storage and use, achieving the effect of "unlimited information pool, limited usage window".

[0028] Furthermore, LangChain's Tool invocation mechanism here is not a simple tool invocation, but rather the construction of an intelligent information scheduling system. The system dynamically determines which information to invoke and how much information to invoke based on the needs of the current decision. This application does not pre-determine which information is needed, but rather dynamically determines it based on the preliminary analysis results. For example, detailed information on personnel skilled in electronic repair will only be invoked when the preliminary judgment is "electronic fault." Each round of invocation is based on the results of the previous round, filtering information to avoid interference from irrelevant information. Even if the detailed information layer has 100 historical cases, the system will only extract the 3-5 most relevant ones, ensuring that it does not exceed the window limit.

[0029] Compared to existing technologies, the advantages of this application are:

[0030] In existing technologies, when using large language models for scheduling decisions, the limitations of the model's context window (e.g., 8K or 32K tokens) prevent the simultaneous input of all relevant fault information, historical cases, personnel files, and other data. This necessitates information truncation or random sampling, resulting in the discarding of a large amount of valuable historical experience and key information, making scheduling decisions akin to "the blind men and the elephant." This application addresses this by constructing a three-layer information architecture—a core information layer, an extended information layer, and a detailed information layer—and leveraging the LangChain framework's Tool invocation mechanism to achieve layered information management and dynamic loading. The initial decision-making process only inputs key data from the core information layer, ensuring it doesn't exceed context limitations. Subsequently, based on the preliminary decision results, the Tool precisely retrieves relevant information from the extended and detailed layers, achieving "on-demand loading." Testing shows that compared to the traditional one-time full input method, this solution effectively utilizes 3-5 times more information under the same context window limitations, ensuring that scheduling decisions fully consider multi-dimensional information such as historical experience, personnel skills, and real-time status.

[0031] Furthermore, this application utilizes a hierarchical Prompt system—comprising an initial decision template, an information supplement template, and a comprehensive decision template—combined with the semantic retrieval capabilities of a knowledge graph, to achieve a progressive decision-making process from coarse to fine. The system first rapidly generates a preliminary scheduling direction based on core information (taking only 2-3 seconds), then retrieves similar historical cases and best practices from the knowledge graph (taking 3-5 seconds), and finally generates a precise personnel allocation plan based on real-time resource status. The entire scheduling decision-making process takes an average of less than 10 seconds, improving efficiency by more than 60 times compared to manual scheduling. Simultaneously, by fully leveraging the experience of successful historical cases, it significantly reduces the need for secondary scheduling. Attached Figure Description

[0032] This application will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0033] Figure 1 This is an exemplary block diagram of a hospital logistics scheduling system based on a large language model, according to some embodiments of this application;

[0034] Figure 2 This is an exemplary flowchart of a hospital logistics scheduling method based on a large language model, according to some embodiments of this application;

[0035] Figure 3 This is an exemplary flowchart illustrating the construction of a logistics service data warehouse according to some embodiments of this application;

[0036] Figure 4 This is an exemplary flowchart illustrating the construction of knowledge triples according to some embodiments of this application;

[0037] Figure 5 This is an exemplary flowchart illustrating a method for constructing a logistics service knowledge graph according to some embodiments of this application. Detailed Implementation

[0038] The methods and systems provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0039] See Figure 1 and Figure 2 This embodiment provides a hospital logistics scheduling system 100 based on a large language model. The system innovatively adopts a hierarchical information processing architecture and effectively solves the problems of insufficient utilization of scheduling information and low decision-making efficiency caused by the limitation of the context window of the large language model in the prior art through the tool call mechanism and the Prompt template system of the LangChain framework.

[0040] Data warehouse module 101 serves as the data infrastructure for the entire system, responsible for receiving and processing raw data from various hospital logistics management subsystems. In its implementation, this module employs a mature ETL (Extract-Transform-Load) technology to ensure data integrity and consistency.

[0041] like Figure 3As shown, during the data extraction phase, the system collects raw data from multiple business databases, including the Hospital Information System (HIS), Equipment Management System, and Human Resources System, by configuring multiple data acquisition interfaces. The collected data types include: equipment warranty records (containing fields such as equipment number, failure time, failure description, and reporting personnel), maintenance logs (containing information such as maintenance time, maintenance content, maintenance personnel, and used parts), personnel shift schedules (containing employee ID, name, shift, and skill level), and task completion records (containing task number, completion time, processing result, and user evaluation).

[0042] The data transformation phase is a crucial step in ensuring data quality. The system implemented several data standardization processes: time fields were uniformly converted to the "YYYY-MM-DD HH:MM:SS" format to ensure the accuracy of time series analysis; equipment identification adopted a six-digit coding system of "department code + equipment type + serial number," such as "ICU-CT-001" indicating the first CT machine in the intensive care unit; fault description text was modified by using regular expressions to remove invalid information such as special characters, HTML tags, and extra spaces, and was converted between simplified and traditional Chinese characters to ensure text standardization.

[0043] During the data loading phase, the system employs a classic star schema for data organization. The central fact table stores detailed records of each logistical service event, including core business data such as event ID, timestamp, device ID, fault type, handler ID, processing time, and processing result. Around the fact table, four main dimension tables are constructed: a device dimension table (storing attributes such as device brand, model, purchase date, department, and maintenance status), a personnel dimension table (storing employee names, employee IDs, skill certificates, departments, and contact information), a time dimension table (organizing time information at multiple granularities such as year, quarter, month, week, and day), and a location dimension table (storing location information such as hospital buildings, floors, departments, and rooms). Through foreign key relationships, a star schema centered on the fact table is formed, supporting efficient multidimensional analysis and queries.

[0044] The knowledge extraction module 102 is the core component for building a hospital logistics knowledge graph. Its innovation lies in making full use of the semantic understanding capabilities of the DeepSeek large language model to achieve in-depth mining of unstructured text data.

[0045] This module first reads the text data of the fault description and handling result fields in batches from the fact table of the data warehouse, and at the same time, it queries the corresponding equipment attributes and personnel information to form complete contextual data. For example, a complete record may contain: "On March 15, 2024, the ICU ventilator had an 'abnormal tidal volume' alarm. It was restored to normal after Senior Engineer Zhang San replaced it with a spare flow sensor, which took 45 minutes."

[0046] like Figure 4 As shown, considering the specialized nature of hospital logistics, a dedicated Prompt template was built to guide DeepSeek in entity recognition. The template includes examples of medical equipment names (such as "ventilator," "monitor," and "defibrillator"), common fault types (such as "sensor failure," "power supply malfunction," and "software error"), and standard handling procedures (such as "replace parts," "system restart," and "parameter calibration"). Through a few-shot learning approach, the model can accurately recognize specialized terminology within the hospital logistics field.

[0047] During named entity recognition, the system not only identifies the text content of entities but also assigns structured metadata to each entity. Equipment entities include attributes such as equipment type, department, and importance level; fault entities include tags such as fault category, severity, and scope of impact; and personnel entities include information such as skill level, professional field, and years of service. This structured information provides rich decision-making basis for subsequent intelligent scheduling.

[0048] The relation extraction stage constructs knowledge triples by analyzing the semantic relationships between entities in the text. The system predefines 15 specific relation types for the hospital logistics domain, including "equipment-occurrence-failure," "failure-cause-symptom," "personnel-handling-failure," "measure-requirement-tool," and "equipment-location-department." Through DeepSeek's semantic analysis capabilities, the system can accurately extract these relations from complex descriptive texts, forming a structured knowledge representation.

[0049] The triples generated by the knowledge extraction module require further processing to form a high-quality knowledge graph. The system employs advanced word embedding technology, using a pre-trained BERT model for the medical domain to map entities and relations to a 768-dimensional vector space. For specialized terminology specific to hospital logistics, the system generates vector representations through character-level sub-word encoding, ensuring that all entities can be effectively vectorized.

[0050] Knowledge fusion is a key step in improving the quality of the knowledge map. The system calculates the cosine similarity of entity vectors from different sources. When the similarity exceeds a threshold of 0.85, they are identified as different representations of the same entity. For example, "CT machine," "computed tomography scanner," and "CT scanning equipment" will be identified as the same entity. The fusion process is not a simple merging; rather, it retains all valuable attribute information and selects the most accurate attribute value as the standard value after fusion through frequency statistics and credibility scoring of attribute values.

[0051] like Figure 5As shown, the constructed knowledge graph is stored and managed using the Neo4j graph database, fully utilizing its native graph structure features. Each entity serves as a node in the graph, storing all of its attribute information; relationships are directed edges connecting related entity nodes. The graph supports complex graph traversal queries, enabling rapid identification of multi-hop relationship paths, providing a foundation for subsequent similar case retrieval and knowledge reasoning.

[0052] The knowledge-based question-answering module 103, based on the LangChain framework, implements flexible workflow orchestration, enabling it to understand users' natural language queries and retrieve relevant information from the knowledge graph. The core innovation of this module lies in its multi-turn dialogue management and dynamic tool invocation mechanism.

[0053] When a user enters a query request through a natural language interface, the system first performs preprocessing, including basic NLP processing such as word segmentation, part-of-speech tagging, and named entity recognition. For example, if a user enters "What malfunctions have occurred in the operating room ventilators in the past month?", the system will identify key information such as the time range (the past month), location (operating room), equipment type (ventilator), and query intent (malfunction statistics).

[0054] Intent recognition employs a DeepSeek-based few-shot learning method. The system pre-prepared a set of examples containing various query intents, including equipment fault queries (querying the fault history of specific equipment), maintenance personnel queries (finding maintenance personnel with specific skills), historical fault statistics (statistically analyzing fault occurrence patterns), and maintenance progress queries (tracking the current maintenance task status). Guided by these examples, DeepSeek can accurately identify the user's true intent.

[0055] Based on the identified intent and extracted parameters, the system generates structured query statements for precise retrieval within the knowledge graph. For complex queries, the system supports multi-step reasoning. For example, to query "Which engineer has the highest success rate in handling ventilator malfunctions," the system first retrieves all ventilator malfunction records, then counts the number of times each maintenance worker has handled and succeeded, and finally calculates and ranks the success rates.

[0056] The visualization module 104 is responsible for presenting query results to users in an intuitive chart format. A key feature of this module is its use of DeepSeek's code generation capabilities to dynamically generate suitable visualization solutions based on data characteristics and user needs.

[0057] The system offers a variety of preset visualization templates, including line charts (showing fault trends), bar charts (comparing the fault frequency of different devices), pie charts (showing the distribution of fault types), heat maps (showing the distribution of faults in different areas of the hospital), and Gantt charts (showing the time schedule of maintenance tasks). DeepSeek automatically selects the most suitable chart type based on the data structure and semantic features of the query results.

[0058] For personalized visualization needs, users can describe their desired display effects using natural language, and the system will generate corresponding visualization configurations. For example, if a user says, "I want to see a comparison of the number of equipment malfunctions in each department, and mark the top three departments with the most malfunctions," the system will generate a bar chart with data annotations and use a prominent color to identify the top three departments.

[0059] The report generation module 105 can automatically generate professional logistics service analysis reports based on query and analysis results. This module integrates multiple data sources, including real-time fault data, historical processing records, and relevant best practices, and uses DeepSeek's text generation capabilities to produce well-structured and logically clear analysis reports.

[0060] The report is generated following a predefined template structure, typically including: an executive summary (summarizing key findings and recommendations), data analysis (detailed statistical analysis results), problem diagnosis (in-depth analysis of the causes of the failure), handling recommendations (optimal solutions based on historical experience), preventative measures (suggestions to avoid similar problems from recurring), and resource requirements (planning for resources such as personnel, spare parts, and tools).

[0061] The system adjusts the level of detail in the report based on the severity and scope of the malfunction. For malfunctions of critical equipment affecting patient safety, the report will include more detailed analysis and more specific action plans. Simultaneously, the system automatically references relevant industry standards, equipment manuals, historical case studies, and other supporting materials to enhance the report's professionalism and credibility.

[0062] The process management module 106 maintains various basic data required for hospital logistics management, which constitute the resource pool for intelligent scheduling. The hospital organizational structure data stored in the module adopts a tree structure, clearly reflecting the management hierarchy from the hospital level down to departments and work groups.

[0063] Employee information management not only includes basic personnel information, but more importantly, it maintains a detailed skills matrix. Each employee's skills certifications, professional expertise, and historical training records are systematically recorded. For example, an engineer may possess multiple skills tags such as "Advanced Certification in Ventilator Repair," "GE Equipment Specialized Training Certificate," and "Hyperbaric Oxygen Chamber Operation Qualification," and this information plays a crucial role in task allocation.

[0064] The digital storage of Standard Operating Procedures (SOPs) enables the system to provide standardized handling guidelines for different types of faults. Each SOP includes detailed information such as applicable conditions, operating steps, precautions, and a list of required tools and parts. The system automatically matches the appropriate SOP based on the fault type, assisting maintenance personnel in standardizing their operations.

[0065] The intelligent scheduling module 107 is the core innovation of the entire system. It is specifically designed with a hierarchical information processing architecture to address the context window limitation problem of large language models. This architecture organizes the massive amount of information required for scheduling into three layers and realizes on-demand loading of information and progressive decision-making through the agent orchestration capabilities of the LangChain framework.

[0066] The core information layer is designed to be extremely streamlined, containing only the critical information necessary to trigger scheduling: the query object identifier (such as device ID), fault type code, fault location, and urgency level flag. This information, after encoding, typically occupies only 500-800 tokens, far below DeepSeek's context limit.

[0067] The extended information layer contains medium-granularity information needed for initial decision-making: a personnel recommendation list (containing brief information on 5-10 candidates), estimated processing time (statistical values ​​based on historical data), key equipment parameters (such as service life and maintenance status), and statistical summaries of similar failures (such as average processing time and common causes). The amount of information in this layer is controlled to 2000-3000 tokens.

[0068] The detailed information layer stores complete historical cases, detailed personnel files, and complete equipment maintenance records. This information is normally stored in an external database and is only accessed when in-depth analysis is required. A single historical case may contain detailed descriptions of thousands of tokens; therefore, the system uses similarity retrieval to extract only the 3-5 most relevant cases.

[0069] The Prompt template system is designed with full consideration of the operational characteristics of hospital logistics. The initial decision template incorporates fault priority judgment rules, clearly defining the highest priority status of life support equipment, operating room equipment, and ICU equipment. The information supplement template is dynamically adjusted according to the type of the initial decision. If special equipment is involved, specific maintenance requirements for that equipment will be automatically added; if it is at night or on holidays, overtime costs for personnel will be considered.

[0070] LangChain's tool invocation mechanism plays a crucial role here. The system defines several dedicated tools: a personnel screening tool selects suitable maintenance personnel based on skill requirements and geographical location; a route planning tool calls the hospital's indoor navigation system to calculate the shortest path and estimated time for maintenance personnel to reach the fault location; an inventory query tool checks the inventory status of required spare parts in real time; and a load balancing tool assesses the current workload of each candidate to avoid excessive task concentration.

[0071] The multi-round decision-making process demonstrates the system's intelligence. The first round of decision-making quickly assesses the urgency of the fault and the basic handling direction based on core information, taking only 2-3 seconds. If it is an urgent fault, the system immediately triggers the emergency response process while conducting subsequent detailed analysis. The second round of decision-making calls on relevant tools to obtain candidate personnel information and resource status, generating a specific personnel allocation plan; this process takes 3-5 seconds. If necessary, a third round of decision-making is conducted, retrieving historical cases to verify and optimize the plan, ensuring that the generated scheduling plan is truly feasible.

[0072] The generated scheduling plan includes a wealth of execution information: designated maintenance personnel and their contact information, estimated arrival and completion times, a list of tools and spare parts to be carried, referenced historical success cases, potential problems and solutions, and verification criteria upon task completion. This comprehensive information support significantly improves the first-time success rate of maintenance tasks.

[0073] Data security module 108 is responsible for protecting sensitive information in the system, ensuring compliance with data security standards in the healthcare industry. The module employs a multi-layered anonymization strategy: for employee personal information, it retains employee ID and skill information while hiding private data such as ID card numbers and home addresses; for equipment information, it retains model and functional parameters while encrypting commercially sensitive information such as serial numbers and purchase prices; and for indirect patient-related information, such as the ward number for a particular device service, it is obfuscated.

[0074] The system also implements role-based access control (RBAC), ensuring that users at different levels can only access data within their authorized scope. Audit logs record every data access and scheduling decision in detail, supporting post-event traceability and accountability.

[0075] Example 2

[0076] Based on the above system, the scheduling method in this embodiment is implemented through the following steps:

[0077] When an emergency request for an "operating room ventilator alarm" is received:

[0078] The system first converts the fault information into structured query data;

[0079] Searching for similar failure cases in the knowledge graph revealed 15 similar cases in history.

[0080] Through a hierarchical scheduling architecture, only the core information of "ventilator / alarm / operating room" is input in the first round;

[0081] DeepSeek identified it as a high-priority fault and generated an initial strategy that "requires immediate handling by qualified ventilator maintenance personnel";

[0082] In the second round, the tool was used to select 5 qualified personnel from 30 maintenance personnel and calculate their arrival time.

[0083] The final result is a complete scheduling plan that includes designated maintenance personnel, an estimated arrival time of 15 minutes, and a spare motherboard.

[0084] As can be seen from the above specific implementation methods, this system successfully overcomes the contextual limitations of large language models and achieves effective utilization of massive amounts of information through a hierarchical information processing architecture and LangChain's tool invocation mechanism. Multi-round progressive decision-making not only improves scheduling efficiency but also ensures decision quality. The construction of the knowledge graph allows for the accumulation and inheritance of historical experience, with each successful processing serving as a reference for future decisions.

[0085] The foregoing illustrative description of the present application and its embodiments is not restrictive and can be implemented in other specific forms without departing from the spirit or essential characteristics of the present application. The accompanying drawings are only one embodiment of the present application, and the actual structure is not limited thereto. Therefore, if those skilled in the art are inspired by this description and design similar structures and embodiments without departing from the spirit of the present application, such designs should fall within the scope of protection of this application. Furthermore, the word "comprising" does not exclude other elements or steps, and the word "a" preceding an element does not exclude the inclusion of "a plurality" of that element. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A hospital logistics scheduling method based on a large language model, characterized in that, include: S1: Collect raw data of hospital logistics services, preprocess the raw data through data extraction, transformation and loading, and store the preprocessed data according to the star database architecture to build a logistics service data warehouse. S2 reads structured data from the logistics service data warehouse, uses a large language model to perform semantic parsing on the text data in the structured data, identifies entities through named entities, obtains the relationships between entities through relation extraction, and generates knowledge triples. S3 converts the entities and relations in the knowledge triples into vectors, performs knowledge fusion by calculating vector similarity, and constructs a logistics service knowledge graph based on the fused knowledge triples. S4 receives the user's natural language service request, uses a large language model to perform intent recognition, and converts the extracted intent into structured query data. S5: Based on the structured query data, retrieve information from the logistics service knowledge graph and obtain resource status data from the logistics service data warehouse. Then, generate a scheduling scheme through a scheduling agent based on the LangChain framework. S6 visualizes the scheduling scheme and generates a logistics service analysis report based on the logistics service knowledge graph and the scheduling scheme. S5 generates scheduling schemes through intelligent agents, including: Based on the structured query data generated in step S4, the query type and query object are parsed, and a graph traversal retrieval is performed in the logistics service knowledge graph to obtain the entity nodes and relationship edges related to the query object. Based on entity nodes, similar cases are retrieved in the logistics service knowledge graph. By calculating the similarity between the current fault entity and historical fault entities, historical processing cases with similarity greater than a preset threshold are retrieved. Based on the retrieved historical processing cases, the success rate and average processing time of different personnel when handling similar faults are statistically analyzed to identify the best processing mode and generate a recommended list of personnel and estimated processing time based on historical processing cases. The current resource status data is obtained from the logistics service data warehouse. The current resource status data includes the real-time location of personnel, the current task status, and the equipment operation status. Combined with the personnel recommendation list, a list of personnel to be selected is obtained. Based on the LangChain framework, a scheduling scheme is generated using a large language model based on the input scheduling information. Based on the LangChain framework, a scheduling scheme is generated using a large language model, including: Construct a hierarchical scheduling agent architecture based on the LangChain framework, configure the Agent module for hierarchical information management, establish a three-layer information structure consisting of a core information layer, an extended information layer, and a detailed information layer, and define the priority and invocation strategy of each layer of information. The scheduling information is processed in layers: the query object in the structured query data is used as the core information layer, the list of personnel to be selected and the estimated processing time are used as the extended information layer, and the detailed content of historical processing cases and the current resource status data are used as the detailed information layer. Construct a Prompt template system that supports hierarchical invocation, including initial decision templates, information supplementation templates, and decision templates. In the first round of scheduling decisions, the relevant entity nodes of the query objects in the core information layer are input into the large language model to analyze the fault type and urgency and generate a preliminary scheduling strategy. Based on the initial scheduling strategy, the LangChain Tool call mechanism is used to extract the candidates matching the initial scheduling strategy and their corresponding estimated processing time from the list of candidates to be selected from the extended information layer, and to obtain the current task status of the candidates from the detailed information layer to generate the second round of decision context. Based on the decision context of the second round, the final scheduling scheme is generated through a large language model.

2. The hospital logistics scheduling method based on a large language model according to claim 1, characterized in that: S1, Building a logistics service data warehouse, including: Raw data on hospital logistics services are collected from the business database of the hospital logistics management system. The raw data includes equipment warranty records, maintenance logs, personnel schedules, and task completion records. The raw data is processed by data extraction, extracting time field, equipment identification field, fault description field, personnel field and processing result field from different data sources; The extracted data undergoes data transformation processing, including unifying time data in different formats into a standard time format, converting text-based device identifiers into a unified encoding, and cleaning the fault description text to remove invalid characters. The transformed data is loaded into the fact table according to the star database architecture, and the equipment attributes, personnel attributes and time attributes are loaded into the corresponding dimension tables respectively. Establish relationships between fact tables and dimension tables, where fact tables are connected to each dimension table through foreign keys, forming a star schema with fact tables at the center and dimension tables surrounding them, serving as a logistics service data warehouse.

3. The hospital logistics scheduling method based on a large language model according to claim 2, characterized in that: S2 generates knowledge triples, including: Read business data containing fault description and processing result fields from the fact table of the logistics service data warehouse, and read the corresponding equipment attribute data and personnel attribute data from the dimension table. Combine the read data to form structured data. Text data of fault description and processing result fields are extracted from structured data. The text data is then input into a large language model for semantic parsing to obtain parsed text with semantic annotations. Named entity recognition is performed on the parsed text to identify the device name entity, fault type entity, handling measure entity, and handling personnel entity, and a unique identifier is assigned to each entity. Based on the identified entities, the contextual relationships of the entities in the text are analyzed through relation extraction to extract the fault occurrence relationship between the device name entity and the fault type entity, the solution relationship between the fault type entity and the handling measure entity, and the executor relationship between the handling measure entity and the handling personnel entity. Using entities as nodes and relations as edges, knowledge triples are generated according to the format of subject entity-relation-object entity. Each knowledge triple is represented as the structure <entity1, relation, entity2>.

4. The hospital logistics scheduling method based on a large language model according to any one of claims 1 to 3, characterized in that: S3, constructs a logistics service knowledge graph based on the fused knowledge triples, including: Extract the entities and relations from each knowledge triple, and use word embedding to map the entities and relations to a vector space to generate a fixed-dimensional vector; For different knowledge triples, calculate the cosine similarity between the corresponding entity vectors. When the similarity is greater than a preset threshold, the corresponding entities are judged to be similar entities. Knowledge fusion is performed on knowledge triples of similar entities. Knowledge fusion includes merging different descriptions that point to the same entity, unifying entity naming, and eliminating duplicate relationships to generate a fused set of knowledge triples. Using entities in the merged set of knowledge triples as graph nodes and relations as graph edges, a directed graph structure is constructed as a logistics service knowledge graph. Each node stores the attributes of the entity, and each edge stores the relation type.

5. The hospital logistics scheduling method based on a large language model according to claim 4, characterized in that: S4 utilizes a large language model for intent recognition, converting the extracted intent into structured query data, including: The system receives natural language service requests from users through a natural language interactive interface. These requests include requests for equipment fault inquiries, requests for maintenance personnel inquiries, requests for historical fault statistics, or requests for maintenance progress inquiries. Natural language service requests are preprocessed, including word segmentation, stop word removal, and part-of-speech tagging, to generate preprocessed request text. The preprocessed request text is input into the large language model. The prompt word engineering guides the large language model to identify the user intent, extract the intent type and query parameters. The intent types include query intent, statistical intent, scheduling intent or analysis intent. Based on the identified intent type and query parameters, generate structured query data containing query type, query object, query conditions, and query time range; Verify the structured query data and check if the query object exists in the logistics service knowledge graph constructed in step S3. If it does not exist, return a prompt message to the user to re-enter the data. If it exists, pass the verified structured query data to the subsequent steps.

6. The hospital logistics scheduling method based on a large language model according to claim 1, characterized in that: The large language model uses DeepSeek.

7. The hospital logistics scheduling method based on a large language model according to claim 1, characterized in that: The initial decision template contains only input placeholders for the core information layer to avoid exceeding the context window limit of the large language model on the first call.

8. A hospital logistics scheduling system based on a large language model, used to execute the method described in any one of claims 1 to 7, characterized in that, include: The data warehouse module receives raw data from hospital logistics services, extracts, transforms, and loads the raw data through ETL, and uses a star database architecture containing fact tables and dimension tables to build a logistics service data warehouse. The knowledge extraction module acquires structured data from the logistics service data warehouse, performs semantic parsing on the text data in the structured data using a large language model, identifies entities containing equipment names, fault types, handling measures, and handling personnel through named entity recognition, and obtains the association relationships between entities through relation extraction, resulting in knowledge triples containing entities and relations. The knowledge question answering module is based on the workflow orchestration of the LangChain framework and constructs a logistics service knowledge graph based on knowledge triples. Receive natural language query requests from users, obtain the user's query intent through a large language model, retrieve the query results from the logistics service knowledge graph based on the query intent, and return the query results. The visualization module generates visualization results based on the user's natural language query request and the returned query results using a large language model; The report generation module generates a logistics service analysis report that includes fault analysis and handling suggestions based on the visualization results, a preset report template, and user-customized requirements. The process management module stores hospital organizational structure data, employee information, job responsibilities, and standard logistics service processes as resource status data. The intelligent scheduling module builds a scheduling agent based on LangChain's Prompt and Agent modules, and generates personnel scheduling plans based on logistics service analysis reports and resource status data. The data security module performs anonymization processing on resource status data.

Images