Patient specialized snapshot construction method and system

Abstract

The embodiment of the invention provides a patient specialized snapshot construction method and system, and the method comprises the following steps: defining a specialized snapshot mode which is used for describing the feature domain and dimension of health data of a patient at a specific specialized perspective; converting the specialized snapshot mode into a data access instruction for an external data source; extracting corresponding patient data from an external system based on the data access instruction; the extracted patient data is processed and organized, and a structured specialized snapshot is generated and stored; and periodically calculating an update index based on the generation time and the access record of the specialized snapshot, and judging whether to trigger regeneration of the specialized snapshot according to the update index. Through the scheme of the embodiment of the invention, the key health data of the patient in the specialized perspective can be intelligently extracted and structured from a plurality of heterogeneous medical information systems, so that the efficiency of acquiring the core information of the patient by a specialist doctor is improved.

Description

Technical Field

[0001] This application relates to the field of health big data processing technology, specifically to a method and system for constructing patient specialty snapshots. Background Technology

[0002] With the deepening development of medical informatization, hospitals accumulate massive amounts of patient diagnosis and treatment data in their daily operations. This data typically originates from multiple heterogeneous data sources, including Hospital Information System (HIS), Laboratory Information System (LIS), Picture Archiving and Transmission System (PACS), Electronic Medical Record (EMR), and various specialty clinical information systems. Currently, the organization and management of patients' historical health data mainly follows two approaches: a timeline-based data organization model and a centralized management model based on business categories. While the former can comprehensively record the flow of medical events, when dealing with patients undergoing long-term cross-specialty treatment, medical staff need to manually sift through a large amount of time-series data to find key information relevant to the current specialty, which is inefficient and can easily lead to the obscuring of critical risk signals. The latter, although achieving structured data storage, still requires frequent switching and cross-comparison between different subsystems or interfaces during actual retrieval, which is cumbersome and prone to information omissions. Existing systems lack the ability to intelligently screen, structure, and dynamically update multi-source heterogeneous patient data from a specific specialty perspective, making it difficult to meet the needs of specialist medical staff to quickly and accurately obtain core patient health information, thus affecting clinical diagnosis and treatment efficiency and the accuracy of risk assessment. Summary of the Invention

[0003] In view of this, the present disclosure provides a method and system for constructing patient specialist snapshots, which at least partially solves the problems existing in the prior art.

[0004] This application discloses a method for constructing a patient specialty snapshot, comprising the following steps:

[0005] S1. Define a specialty snapshot mode, which is used to describe the feature domain and dimension of patient health data from a specific specialty perspective.

[0006] S2. Convert the specialist snapshot mode into a data access command for an external data source;

[0007] S3. Based on the data access command, extract the corresponding patient data from the external system;

[0008] S4. Process and organize the extracted patient data to generate and store structured specialist snapshots;

[0009] S5. Periodically calculate the update index based on the generation time and access records of the specialist snapshot, and determine whether to trigger the regeneration of the specialist snapshot based on the update index.

[0010] Preferably, the specialty snapshot mode includes one or more of the following feature domains: specialty disease, patient basic information, specialty status, diagnosis and medical history, recent hospitalization, recent outpatient records, specialty treatment, specialty key test reports, specialty key examination reports, specialty follow-up reports, and abnormal reports.

[0011] Preferred,

[0012] The specific disease categories are associated with International Classification of Diseases (ICD) codes;

[0013] The recent hospitalization information includes a "summary + full text" format formed after text summarization of the inpatient medical records.

[0014] Preferably, the specialist snapshot mode is defined by a formatted file, which includes JSON, YML, or XML format files.

[0015] Preferably, the specialist snapshot has two attributes: freshness vs. access activity as;

[0016] Among them, the freshness ΔTs represents the length of time the specialist snapshot has existed since its generation; the access activity level... w is the preset observation window duration. The length of time during which the specialist snapshot has been accessed for the i-th time within the observation window.

[0017] Preferably, step S5 specifically includes:

[0018] The generation time of the specialist snapshot and its access event records within the observation window w are periodically obtained;

[0019] Calculate the current freshness vs based on the generation time;

[0020] Calculate the current access activity level as based on the access event records;

[0021] When the condition as>vs is met, steps S3 and S4 are re-executed to update the specialist snapshot.

[0022] Preferably, after creating or modifying the specialist snapshot mode in step S1, steps S3 and S4 are immediately triggered to generate or update the specialist snapshot.

[0023] A patient specialty snapshot construction system for implementing the method described in any of the above embodiments, the system comprising:

[0024] The data source interface module is configured to connect to external systems and extract patient data based on data access commands.

[0025] The Specialty Snapshot Mode module is configured to provide functions for defining, modifying, and storing specialty snapshot modes;

[0026] The snapshot engine module is configured to drive the data source interface module to extract data according to the specialist snapshot mode, process and generate structured specialist snapshots, and record the generation time and access events of the specialist snapshots.

[0027] The specialty snapshot library module is configured to store specialty snapshots generated by the snapshot engine module and provide query and read services for the specialty snapshots.

[0028] Preferably, the snapshot engine module is further configured to:

[0029] Periodically query the generation time and access events of the specialist snapshots stored in the specialist snapshot library module;

[0030] Calculate the freshness vs. access activity as of the specialist snapshot;

[0031] When the condition is satisfied that as>vs, the corresponding specialist snapshot is regenerated.

[0032] This disclosure provides a method for constructing a patient specialty snapshot, comprising the following steps: S1, defining a specialty snapshot pattern, wherein the specialty snapshot pattern is used to describe the feature domains and dimensions of patient health data from a specific specialty perspective; S2, converting the specialty snapshot pattern into data access instructions for external data sources; S3, extracting corresponding patient data from external systems based on the data access instructions; S4, processing and organizing the extracted patient data to generate and store a structured specialty snapshot; S5, periodically calculating update indicators based on the generation time and access records of the specialty snapshot, and determining whether to trigger the regeneration of the specialty snapshot based on the update indicators. Through the solution of this disclosure, key health data from a patient specialty perspective can be intelligently extracted and structured from multiple heterogeneous medical information systems, thereby improving the efficiency of specialists in obtaining core patient information. Attached Figure Description

[0033] To more clearly illustrate the technical solutions of the exemplary embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this disclosure and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a flowchart of a method for constructing a patient specialty snapshot;

[0035] Figure 2 This is a block diagram of a patient specialist snapshot construction system. Detailed Implementation

[0036] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0037] First, refer to Figure 1 The present invention describes the process of constructing a patient specialty snapshot.

[0038] S1. Define a specialty snapshot mode, which is used to describe the feature domain and dimensions of patient health data from a specific specialty perspective.

[0039] The implementation will be carried out using the diagnosis and treatment of diabetes in the Department of Endocrinology as an example. First, a specialist or system administrator defines and describes the feature domains and dimensions of patient health data from a specialist perspective, creating a configurable specialist snapshot model. This model is defined and stored in a structured formatted file (such as a JSON file). The model content explicitly includes the following feature domains: specialist disease (e.g., "diabetes," and associated with ICD-10 codes E10, E11, etc.), basic patient information (name, gender, age, height, etc.), specialist status (including immediate status such as serum glucose and comprehensive assessment status such as complication risk level), diagnosis and medical history, recent hospitalization, recent outpatient records, specialist treatment, specialist key test reports (e.g., serum glucose, glycated hemoglobin, etc.), specialist key examination reports, specialist follow-up reports, and abnormal reports. The model file may also include management information such as the model name, the specialty, and the creator.

[0040] S2. Convert the specialist snapshot mode into a data access instruction for an external data source.

[0041] The system parses the predefined JSON-formatted specialist snapshot schema file. Based on the specific requirements of each feature domain in the schema, it converts it into specific executable data access instructions or query statements for various heterogeneous external data sources within the hospital (such as HIS, LIS, PACS, EMR, and the hospital data platform). This process essentially maps the feature dimensions in the schema to specific data tables, fields, or API interfaces of the external data sources. For example, "Patient Basic Information" is mapped to an SQL instruction to query fields such as name and gender from the HIS "Patient Registration Table"; "Diagnosis and Medical History" is mapped to an instruction to query from relevant tables in the EMR or medical record homepage, using the ICD code related to "diabetes" as a filter condition.

[0042] S3. Based on the data access command, extract the corresponding patient data from the external system.

[0043] Through a specially constructed data source interface module, the data access instructions generated in the previous step are executed to connect to and access external systems such as HIS, LIS, and EMR through direct database access and API calls. As required by the instructions, original patient data related to the target patient and the specified specialty disease (diabetes) is extracted from the corresponding database tables of each system (such as outpatient visit forms, medical orders, laboratory records, examination records, discharge follow-up forms, etc.).

[0044] S4. Process and organize the extracted patient data to generate and store structured specialist snapshots.

[0045] The snapshot engine module processes and organizes the raw data extracted from various systems. First, for time-series data such as inpatient records and outpatient records, the top-K most recent records are retrieved (K=5 in this example). Next, these data are correlated and integrated, such as sorting multiple test results by time and associating inpatient summaries with the full text, to form a complete and structured "Endocrinology Diabetes Specialty Snapshot." This snapshot is assigned two core attributes: freshness vs (defined as the reciprocal of the snapshot's existence time ΔTs since its generation) and access activity as (defined as the sum of the reciprocals of the time elapsed since each access event within a preset observation window w). Finally, this structured specialty snapshot is stored in the specialty snapshot library module, and its generation timestamp is recorded.

[0046] S5. Periodically calculate the update index based on the generation time and access records of the specialist snapshot, and determine whether to trigger the regeneration of the specialist snapshot based on the update index.

[0047] The snapshot engine module periodically (e.g., every 5 minutes) performs a status check task. For a stored snapshot, the engine queries its creation time and all access event records within a preset observation window w (e.g., 5 days). Based on the difference ∆Ts between the current time and the creation time, the current freshness of the snapshot is recalculated. At the same time, based on the length of time since each access within the window occurred. Calculate the current access activity. The engine continuously compares these two metrics. When it determines that the condition as>vs (i.e., access activity exceeds freshness, meaning that the snapshot is frequently used and may no longer be "fresh") is met, it automatically triggers the re-execution of steps S3 and S4 above to re-extract data for the patient and generate an updated specialist snapshot. This achieves intelligent and on-demand data updates, optimizing system computing and storage resources while ensuring information timeliness.

[0048] In a specific embodiment, the defined specialty snapshot model explicitly includes multiple specific feature domains. For example, in the endocrinology diabetes snapshot model, these feature domains are specifically "specialty disease" (e.g., diabetes), "patient basic information" (e.g., name, age, BMI), "specialty status" (e.g., serum glucose, complication risk level), "diagnosis and medical history," "recent hospitalization," "recent outpatient records," "specialty treatment" (e.g., list of hypoglycemic drugs), "specialty key test reports" (e.g., glycated hemoglobin), "specialty key examination reports," "specialty follow-up reports" (e.g., medication, diet), and "abnormal reports" (e.g., abnormal test indicators). These feature domains together constitute a complete data framework for examining the patient's health status from a specific specialty perspective.

[0049] Furthermore, in this application, the "specialty disease" is not a simple textual description, but is associated with the International Classification of Diseases (ICD10) code to achieve accurate computer identification and data filtering. For example, in the embodiment, "diabetes" is associated with the codes "E10" and "E11". Secondly, for the feature domain of "recent hospitalization status", in order to overcome the problem of lengthy inpatient medical records, text summarization technologies such as ClinicalBERT+CRF are used to process the original medical records and generate concise summaries. Finally, the summaries are presented in a form that combines "summary" with links to the "full text", thereby improving the efficiency of information acquisition while retaining key information.

[0050] Furthermore, in this application, the specialty snapshot schema is not directly embedded in the database table, but is defined and stored in a separate, human-readable, and machine-parseable formatted file. This schema is described in a well-structured JSON file, which not only lists all feature fields and their specific contents (such as "Key Test Report": ["Serum Glucose", "Glycated Hemoglobin"...]) hierarchically and in key-value pairs, but also includes management metadata such as "Schema Name", "Specialty Department", and "Creator". This file-based definition method avoids database normalization constraints, greatly enhancing the flexibility and maintainability of schema configuration.

[0051] In another specific embodiment of this application, the engine is configured to automatically run a status check process every 5 minutes. First, it queries the specialist snapshot library module to obtain metadata for all stored specialist snapshots, including the unique identifier of each snapshot and its generation timestamp. Simultaneously, for each snapshot, the engine retrieves a list of timestamps of all access events recorded within a preset observation window w (e.g., 5 days). These access events are recorded in real-time by the snapshot library module when healthcare workers view the snapshot through the system interface. Next, the engine performs a dual calculation: for freshness vs., it takes the difference between the current system time and the snapshot generation timestamp to obtain... (In days, which may be converted to decimal form in the embodiment to maintain precision), then calculate vs = 1 / ΔTs. For access activity as, it iterates through the timestamps of each access event within the observation window and calculates the length of time since each event occurred. (Also in days), then calculate 1 / τi for each event and sum them up to obtain... After all snapshot attributes have been calculated, the engine compares the as and vs values ​​of each snapshot. When as > vs, it means that the access activity of the snapshot within the most recent window exceeds the "aging" level represented by its freshness, and the system determines that the snapshot needs to be updated to reflect potentially changed patient data. At this point, the engine immediately triggers a snapshot regeneration process for that specific patient and specialty: based on the specialty snapshot mode (such as diabetes mode) corresponding to the snapshot, it drives the data source interface module to re-extract the latest data from external systems such as HIS and LIS (i.e., step S3), and then performs the same processing and organization on the extracted data (i.e., step S4), generating a brand new structured specialty snapshot, which overwrites or replaces the original snapshot in the library, while resetting the generation timestamp and clearing the access event records (or retaining historical records but restarting statistics). This periodic mechanism ensures that the timeliness of snapshot content dynamically adapts to the user's access patterns: for frequently viewed patient snapshots, the system updates more proactively to avoid doctors seeing outdated information; while for less frequently accessed snapshots, the system reduces unnecessary update operations, saving computing and storage resources. The entire process is illustrated in this embodiment using an endocrinology diabetes snapshot as an example, but its logic applies to snapshots of all specialties, reflecting the core idea of ​​intelligent resource optimization.

[0052] Furthermore, when a healthcare institution's specialty needs change or a new specialty perspective needs to be added, authorized users (such as department administrators or system administrators) can create a new specialty snapshot mode (e.g., define a hypertension snapshot mode for cardiology) or modify an existing mode (e.g., a diabetes mode for endocrinology) through the system's configuration interface. This modification could include adding a new feature field, "echocardiography report," or adjusting the list of key laboratory tests. The mode module saves these changes in formatted files such as JSON. After a mode is modified, the original mode is marked as obsolete (but not necessarily deleted immediately; version history may be retained). Importantly, once the mode module detects that a creation or modification operation is complete and successfully stored, it immediately sends a trigger signal to the snapshot engine module. This signal carries information about the affected mode (such as the mode ID and version). Upon receiving this signal, the snapshot engine module immediately initiates a snapshot generation task for all relevant patients covered by the new or updated mode, without waiting for periodic status checks. Specifically, the engine first translates the new pattern definition into corresponding data access instructions (i.e., execute step S2). Then, for all patients associated with that specialty (e.g., all patients diagnosed with diabetes), it drives the data source interface module in parallel or in batches to extract the latest data of these patients from the external system (step S3). Next, it processes and organizes the data to generate structured specialty snapshots (step S4) and stores them in the snapshot library. This immediate triggering mechanism ensures that changes in system configuration are reflected in the data layer in real time: for example, when "serum C-peptide" is added as a key test report in the diabetes pattern, all snapshots of diabetic patients will include this new indicator before the next access, without requiring doctors to manually refresh or wait for periodic updates. In this embodiment, this mechanism is also used to handle data consistency after pattern correction, because after the original pattern is abandoned, snapshots generated based on the old pattern may no longer meet clinical needs. Immediate regeneration ensures that all active snapshots are consistent with the latest pattern definition. In this way, agile response between system configuration and data services is achieved, enabling specialty snapshots to flexibly adapt to updates in medical knowledge, clinical guidelines, or hospital policies, thereby continuously providing accurate and relevant decision support.

[0053] Next, we will focus on describing the two core dynamic attributes of the specialty snapshots in this application—freshness vs and access activity as. During the snapshot generation phase, the snapshot engine module records a precise generation timestamp when storing structured specialty snapshots (such as integrated data of diabetic patients) into the specialty snapshot library, serving as the basis for freshness calculation. Freshness vs is quantified as the reciprocal of the length of time the snapshot has existed since its generation, ΔTs, i.e., vs = 1 / ΔTs. Here, ΔTs is calculated from the generation time to any checkpoint, typically measured in "days" in the embodiments to ensure consistency across snapshot comparisons. For example, a snapshot generated 2 days ago has ΔTs = 2, then vs = 0.5; as time progresses, the vs value monotonically decreases, intuitively reflecting the natural "aging" of the data content. Access activity as is designed to capture the recent usage frequency and popularity of the snapshot. The system presets a configurable observation window w (e.g., 5 days) and tracks all access events to the snapshot within this window. Each time a visit occurs (such as when a doctor views the snapshot), the specialist snapshot library module records the visit timestamp. The activity level is calculated using the formula as... τi represents the time elapsed since the i-th access event within window w. This means that the closer an access is to the current time, the larger its reciprocal 1 / τi, and the greater its contribution to as. For example, if a snapshot was accessed 3 times in the last 5 days, occurring 1 day, 3 days, and 4 days ago respectively, then τ1=1, τ2=3, τ3=4, and as is calculated to be approximately 1.583. In system implementation, the generated timestamps and access event logs are persistently stored. The snapshot engine module reads this time data in periodic tasks and calculates and updates vs and as in real time. This implementation not only transforms abstract attributes into computable metrics but also, through time-driven design, enables the system to continuously quantify the "timeliness value" and "usage demand" of each snapshot, providing accurate and dynamic data support for subsequent intelligent decision-making.

[0054] In addition, in this application, the engine is configured to automatically run a status check process every 5 minutes. First, it queries the specialist snapshot library module to obtain metadata for all stored specialist snapshots, including the unique identifier of each snapshot and its generation timestamp. Simultaneously, for each snapshot, the engine retrieves a list of timestamps of all access events recorded within a preset observation window w (e.g., 5 days). These access events are recorded in real-time by the snapshot library module when healthcare workers view the snapshot through the system interface. Next, the engine performs a double calculation: for freshness vs, it takes the difference between the current system time and the snapshot generation timestamp to obtain ΔTs (in days, which can be converted to decimal form in this embodiment to maintain precision), and then calculates vs = 1 / ΔTs. For access activity as, it iterates through the timestamps of each access event within the observation window, calculates the time length τi since each event occurred (also in days), then calculates 1 / τi for each event and sums them to obtain as = Σ(1 / τi). After all snapshot attributes have been calculated, the engine compares the as and vs values ​​of each snapshot one by one. When the condition as > vs is met, it means that the access activity of the snapshot within the most recent window exceeds the "aging" level represented by its freshness. The system determines that the snapshot needs to be updated to reflect potentially changed patient data. At this time, the engine immediately triggers a snapshot regeneration process for that specific patient and specialty: based on the specialty snapshot mode corresponding to the snapshot (such as the diabetes mode), it drives the data source interface module to re-extract the latest data from external systems such as HIS and LIS (i.e., execute step S3), and then performs the same processing and organization on the extracted data (i.e., step S4), generating a brand new structured specialty snapshot, which overwrites or replaces the original snapshot in the library, while resetting the generation timestamp and clearing the access event record (or retaining the historical record but restarting the statistics). This periodic mechanism ensures that the timeliness of the snapshot content dynamically adapts to the user's access patterns: for frequently viewed patient snapshots, the system will update more actively to avoid doctors seeing outdated information; while for less frequently accessed snapshots, the system reduces unnecessary update operations, saving computing and storage resources. The entire process is illustrated in this embodiment using an endocrinology diabetes snapshot as an example, but its logic applies to snapshots of all specialties, reflecting the core idea of ​​intelligent resource optimization.

[0055] Furthermore, when a healthcare institution's specialty needs change or a new specialty perspective needs to be added, authorized users (such as department administrators or system administrators) can create a new specialty snapshot mode (e.g., define a hypertension snapshot mode for cardiology) or modify an existing mode (e.g., a diabetes mode for endocrinology) through the system's configuration interface. This modification could include adding a new feature field, "echocardiography report," or adjusting the list of key laboratory tests. The mode module saves these changes in formatted files such as JSON. After a mode is modified, the original mode is marked as obsolete (but not necessarily deleted immediately; version history may be retained). Importantly, once the mode module detects that a creation or modification operation is complete and successfully stored, it immediately sends a trigger signal to the snapshot engine module. This signal carries information about the affected mode (such as the mode ID and version). Upon receiving this signal, the snapshot engine module immediately initiates a snapshot generation task for all relevant patients covered by the new or updated mode, without waiting for periodic status checks. Specifically, the engine first translates the new pattern definition into corresponding data access instructions (i.e., execute step S2). Then, for all patients associated with that specialty (e.g., all patients diagnosed with diabetes), it drives the data source interface module in parallel or in batches to extract the latest data of these patients from the external system (step S3). Next, it processes and organizes the data to generate structured specialty snapshots (step S4) and stores them in the snapshot library. This immediate triggering mechanism ensures that changes in system configuration are reflected in the data layer in real time: for example, when "serum C-peptide" is added as a key test report in the diabetes pattern, all snapshots of diabetic patients will include this new indicator before the next access, without requiring doctors to manually refresh or wait for periodic updates. In this embodiment, this mechanism is also used to handle data consistency after pattern correction, because after the original pattern is abandoned, snapshots generated based on the old pattern may no longer meet clinical needs. Immediate regeneration ensures that all active snapshots are consistent with the latest pattern definition. In this way, agile response between system configuration and data services is achieved, enabling specialty snapshots to flexibly adapt to updates in medical knowledge, clinical guidelines, or hospital policies, thereby continuously providing accurate and relevant decision support.

[0056] In addition, such as Figure 2 As shown, this application also provides a patient specialty snapshot construction system, which is used to implement the method described in the above method embodiments. The system includes:

[0057] The data source interface module is configured to connect to external systems and extract patient data based on data access commands.

[0058] The Specialty Snapshot Mode module is configured to provide functions for defining, modifying, and storing specialty snapshot modes;

[0059] The snapshot engine module is configured to drive the data source interface module to extract data according to the specialist snapshot mode, process and generate structured specialist snapshots, and record the generation time and access events of the specialist snapshots.

[0060] The specialty snapshot library module is configured to store specialty snapshots generated by the snapshot engine module and provide query and read services for the specialty snapshots.

[0061] In addition, the snapshot engine module is also configured as follows:

[0062] Periodically query the generation time and access events of the specialist snapshots stored in the specialist snapshot library module;

[0063] Calculate the freshness vs. access activity as of the specialist snapshot;

[0064] When the condition is satisfied that as>vs, the corresponding specialist snapshot is regenerated.

[0065] Since the functionality of the system has been described above with reference to the method embodiments, it will not be repeated here.

[0066] This invention provides a method and system for constructing patient specialty snapshots, comprising: first, defining a specialty snapshot pattern to describe the characteristic domains and dimensions of patient health data from a specific specialty perspective; then, converting this pattern into data access instructions for external data sources, thereby achieving compatibility and data acquisition across different medical information systems; subsequently, based on these data access instructions, extracting relevant patient data from heterogeneous systems such as HIS, LIS, PACS, and EMR; then, processing and organizing the acquired data to generate and store structured specialty snapshots; finally, periodically calculating update indicators based on the generation time and access records of the specialty snapshots, and determining whether to regenerate the specialty snapshots to ensure the timeliness and accuracy of the data. This method, by defining a configurable specialty snapshot pattern and combining data extraction, processing, and structured organization technologies, effectively solves the problem of intelligently extracting and structured organizing key health data from multiple heterogeneous medical information systems from a patient specialty perspective. By selectively filtering, aggregating, and optimizing patient data, this invention significantly improves the efficiency of specialists in obtaining core patient information, reduces the burden on doctors in searching for key information in complex data environments, and thus improves the quality of clinical diagnosis and treatment and decision-making efficiency. Meanwhile, the system supports switching between multiple specialty perspectives to adapt to the needs of different departments and provide patients with more comprehensive and efficient medical services.

[0067] In other words, in this application, the method for constructing a patient specialty snapshot according to the present invention includes:

[0068] Step 1: In this example, we define and describe the health characteristics and dimensions of diabetic patients from the perspective of an endocrinologist, and create an endocrinology-based diabetes snapshot model.

[0069] The Endocrinology Department's diabetes snapshot mode consists of feature domains including specialty disease, patient basic information, specialty status, diagnosis and medical history, recent hospitalization, recent outpatient records, specialty treatment, specialty key test reports, specialty key examination reports, specialty follow-up reports, and abnormal reports.

[0070] The specialty disease is set as "diabetes" for patients primarily treated by the endocrinology department, and the corresponding ICD10 disease code is set as " “E11” “E12” “E13” “E14” " The symbol "" indicates that it covers the subcategories under this catalog.

[0071] Basic information for diabetic patients includes, but is not limited to, name, gender, age, patient identification, medical record, height, weight, body mass index (BMI), and contact information.

[0072] The immediate status of the specialist condition includes, but is not limited to, serum glucose, glycated hemoglobin, and blood pressure; the comprehensive assessment status includes, but is not limited to, pancreatic function, osteoporosis, arteriosclerosis, diabetic nephropathy, fundus vascular disease, and other comorbidities and comorbidity risk levels.

[0073] In the examples, the primary diagnosis and medical history include, but are not limited to, the diagnosis and first diagnosis time of major diseases related to specialties such as type 1 diabetes, type 1 diabetic ketoacidosis, type 1 diabetic pre-nephropathy, type 2 diabetes, type 2 diabetic ketoacidosis, and type 2 diabetic pre-nephropathy. Other secondary diagnoses include, but are not limited to, hypertension, hyperlipidemia, and chronic obstructive pulmonary disease.

[0074] Recent hospitalization information includes the last 5 hospitalization progress reports and discharge reports, mainly for specialist diseases. To further address the issue of numerous and lengthy inpatient medical records, a text summarization algorithm is used to generate summaries of the inpatient medical records. In this example, the pre-trained medical model ClinicalBERT+CRF is used to determine whether sentences in the medical record documents should be included in the medical record summary, forming a summary + full text representation of recent hospitalization information.

[0075] Recent outpatient records include the outpatient medical records of the last 5 outpatient visits, primarily for diagnoses of specific diseases.

[0076] Specialty treatment includes treatment methods such as medication, surgery, and procedures adopted by clinical specialists. In this example, diabetes is mainly treated with medication. Diabetes medications include, but are not limited to, metformin, glibenclamide, repaglinide, acarbose, insulin aspart, insulin glargine, and insulin degludec.

[0077] Specialty critical test reports refer to the key test items and results related to the diagnosis and risk assessment of specialty diseases. Key test items related to diabetes include, but are not limited to, serum glucose, glycated hemoglobin, serum insulin, serum C-peptide, serum uric acid, serum triglycerides, and low-density lipoprotein cholesterol.

[0078] Specialty key examination reports refer to key examination items and results related to the diagnosis and risk assessment of specialty diseases. Key examination items related to diabetes include, but are not limited to, fundus examination, foot examination (including nerve sensation and vascular pulsation), electrocardiogram, carotid ultrasound, and nerve conduction velocity examination.

[0079] The specialist follow-up report includes the patient's prognosis medication, diet, exercise and specialist indicators. In the example, medication includes, but is not limited to, oral hypoglycemic drugs (such as metformin, glibenclamide, repaglinide, acarbose, etc.) and dosage, injected insulin (such as insulin aspart, insulin glargine, insulin degludec, etc.) and dosage, diet includes the types and amounts of staple foods, exercise includes the type and amount of exercise, and specialist indicators include serum glucose and blood pressure values.

[0080] Abnormal reports refer to abnormal signs, test results, and examination findings of patients, organized in reverse chronological order by specialty. Examples include, but are not limited to, abnormal results for BMI, serum glucose, glycated hemoglobin, serum triglycerides, low-density lipoprotein cholesterol, serum uric acid, and lower extremity arteriosclerosis.

[0081] In this embodiment, the specialty snapshot pattern is described in JSON format. To make the pattern file complete, elements such as pattern name, specialty department, creator, creation time, and modification time are also added, as shown below:

[0082] {"Mode Name":"Endocrinology Department Diabetes Specialist Snapshot Mode",

[0083] Specialty Department: Endocrinology

[0084] "Specialty Disease":{"Diabetes":["E10" ","E11 ","E12 ","E13 ","E14 "]},

[0085] Basic Information: ["Name", "Gender", "Age", "Patient Identifier", "Visit Identifier", "Height", "Weight", "BMI", "Contact Information"]

[0086] "Status": ["Serum glucose", "Glycated hemoglobin", "Blood pressure", "Pancreatic function", "Osteoporosis", "Arteriosclerosis", "Diabetic nephropathy"],

[0087] "Diagnosis and Medical History": ["Type 1 Diabetes Mellitus", "Type 1 Diabetic Ketoacidosis", "Type 1 Diabetic Prediabetic Nephropathy", "Type 2 Diabetes Mellitus", "Type 2 Diabetic Ketoacidosis", "Type 2 Diabetic Prediabetic Nephropathy"],

[0088] "Recent Hospitalization Information":["Summary","Full Text"],

[0089] "Recent Outpatient Record": ["Chief Complaint", "Symptoms", "Physical Examination", "Prescription"],

[0090] "Treatment":{"Medications":["Metformin","Glibenclamide","Repaglinide","Acarbose","Insulin Aspart","Insulin Glargine","Insulin Degludec"],"Surgery":["None"],"Procedure":["None"]},

[0091] Key Test Results: ["Serve Glucose", "Glycated Hemoglobin", "Serve Insulin", "Serve C-peptide", "Serve Uric Acid", "Serve Triglycerides", "Low-Density Lipoprotein Cholesterol"]

[0092] "Key Inspection Report":[],

[0093] Follow-up Report: {"Medication":["Metformin","Glibenclamide","Repaglinide","Acarbose","Insulin Aspart","Insulin Glargine","Insulin Degludec"],"Diet":[],"Exercise":[],"Specialist Indicators":["Serve Glucose","Blood Pressure"]},

[0094] "Abnormal Report": ["BMI", "Serve Glucose", "Glycated Hemoglobin", "Serve Triglycerides", "Low-Density Lipoprotein Cholesterol", "Serve Uric Acid", "Lower Extremity Arteriosclerosis"],

[0095] Creator: "Zhang San"

[0096] Creation time: "2025-10-31 08:30:00",

[0097] "Modified Time":"2025-11-10 09:00:00"}

[0098] Step 2: Convert the definition of the specialist snapshot mode into data query commands for patient basic information, diagnosis and medical history, inpatient records, outpatient records, treatment orders, laboratory reports, examination reports, follow-up reports, etc.

[0099] Furthermore, step two includes:

[0100] The features and dimensions in the specialist snapshot mode are mapped to data tables and fields of external data sources, with diabetes as the filtering condition.

[0101] Step 3: Extract patient data from external systems such as HIS, LIS, PACS, and EMR using direct database access. Further, read basic patient information from the patient registration form, diagnosis and medical history from the medical record cover sheet, inpatient records from the inpatient record sheet, outpatient records from the outpatient visit form, treatment orders from the doctor's order sheet, laboratory reports from the laboratory record sheet, examination reports from the examination record sheet, follow-up reports from the discharge follow-up form, and extract abnormal result items from the laboratory record sheet and examination record sheet.

[0102] Step 4: Take the top 5 most recent records from all data, perform correlation operations on the extracted data to generate a structured specialist snapshot and save it.

[0103] Furthermore, step four includes:

[0104] The specialist snapshot settings have two attributes: 1) Freshness vs. ,in 2) Access activity as the time the snapshot was generated Where w is set to 5 days, The length of time since the i-th specialist snapshot within the observation window was accessed.

[0105] Step 5: Check the specialist snapshot status every 5 minutes. Calculate the freshness by querying the snapshot generation time and the elapsed access time of specialist snapshots within the past 5 days. And access activity as, when as If necessary, a new snapshot will be generated. Furthermore, a snapshot generation operation will be triggered immediately after a new or modified specialist snapshot mode is defined.

[0106] A patient specialty snapshot construction system of the present invention includes:

[0107] like Figure 2 As shown, the data source interface module is adapted to connect to external data sources, including but not limited to HIS, LIS, PACS, EMR systems, and databases or API interfaces of hospital data platforms.

[0108] The Specialty Snapshot Mode module is used to create, modify, and save specialty snapshot modes. Once a specialty snapshot mode is modified, the original mode is discarded.

[0109] The snapshot engine module is used to generate, update, and save specialist snapshots, recording the generation time and the time each specialist snapshot has been accessed.

[0110] The snapshot engine module checks the specialist snapshot status every 5 minutes, calculating freshness by querying the snapshot generation time and the elapsed time of access events to the specialist snapshot within 5 days. and visit activity When satisfied The snapshot is then regenerated, and the new generation time and snapshot access time of the specialist snapshot are recorded, continuously in a loop.

[0111] The Specialty Snapshot Library module is used to store, query, and read specialty snapshots, and to create indexes on specialty diseases.

[0112] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all 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.

Claims

1. A method for constructing a patient specialty snapshot, characterized in that, Includes the following steps: S1. Define a specialty snapshot mode, which is used to describe the feature domain and dimension of patient health data from a specific specialty perspective. S2. Convert the specialist snapshot mode into a data access command for an external data source; S3. Based on the data access command, extract the corresponding patient data from the external system; S4. Process and organize the extracted patient data to generate and store structured specialist snapshots; S5. Periodically calculate the update index based on the generation time and access records of the specialist snapshot, and determine whether to trigger the regeneration of the specialist snapshot based on the update index.

2. The method for constructing a patient specialty snapshot according to claim 1, characterized in that, The specialist snapshot mode includes one or more of the following feature domains: specialist disease, patient basic information, specialist status, diagnosis and medical history, recent hospitalization, recent outpatient records, specialist treatment, specialist key test reports, specialist key examination reports, specialist follow-up reports, and abnormal reports.

3. The method for constructing a patient specialty snapshot according to claim 2, characterized in that: The specific disease categories are associated with International Classification of Diseases (ICD) codes; The recent hospitalization information includes a "summary + full text" format formed after text summarization of the inpatient medical records.

4. The method for constructing a patient specialty snapshot according to claim 1, characterized in that, The specialist snapshot mode is defined by a formatted file, which may include JSON, YML, or XML format files.

5. The method for constructing a patient specialty snapshot according to claim 1, characterized in that, The specialist snapshot has two attributes: freshness vs. access activity as; Among them, the freshness , The term "specialty snapshot" refers to the length of time the snapshot has existed since its generation; the term "access activity" refers to... w is the preset observation window length. The length of time during which the specialist snapshot has been accessed for the i-th time within the observation window.

6. The method for constructing a patient specialty snapshot according to claim 5, characterized in that, Step S5 specifically includes: The generation time of the specialist snapshot and its access event records within the observation window w are periodically obtained; Calculate the current freshness vs based on the generation time; Calculate the current access activity level as based on the access event records; When the condition as>vs is met, steps S3 and S4 are re-executed to update the specialist snapshot.

7. The method for constructing a patient specialty snapshot according to claim 1 or 6, characterized in that, After creating or modifying the specialist snapshot mode in step S1, steps S3 and S4 are immediately triggered to generate or update the specialist snapshot.

8. A patient specialty snapshot construction system, characterized in that, The system for implementing the method as described in any one of claims 1-7 comprises: The data source interface module is configured to connect to external systems and extract patient data based on data access commands. The Specialty Snapshot Mode module is configured to provide functions for defining, modifying, and storing specialty snapshot modes; The snapshot engine module is configured to drive the data source interface module to extract data according to the specialist snapshot mode, process and generate structured specialist snapshots, and record the generation time and access events of the specialist snapshots. The specialty snapshot library module is configured to store specialty snapshots generated by the snapshot engine module and provide query and read services for the specialty snapshots.

9. The patient specialty snapshot construction system according to claim 8, characterized in that, The snapshot engine module is also configured to: Periodically query the generation time and access events of the specialist snapshots stored in the specialist snapshot library module; Calculate the freshness vs. access activity as of the specialist snapshot; When the condition is satisfied that as>vs, the corresponding specialist snapshot is regenerated.

Images