Dictionary data management method for insomnia cognitive behavioral therapy management system
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-14
- Publication Date
- 2026-08-14
AI Technical Summary
1.缓存管理混乱：仅采用单一 Object 格式存储，兼容差，且无自动化过期校验，缓存失效后仍读取脏数据，导致CBTI系统中疗法类型、评估维度等核心字典数据展示错误；
[0015]本发明的有益效果：该字典数据管理方法，基于Pinia管理框架实现。通过智能缓存四层校验与自动过期管控、可配置字典数据优化引擎、防抖锁控机构+惰性加载机构、数据安全兜底、支持热更新的全链路重置、统一缓存格式转换引擎、多版本缓存可扩展架构等构成一套适用于CBTI系统的可配置、高稳定、多场景适配的前端字典数据智能化管理体系及方法。
Smart Images
Figure CN122570580A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of medical device technology, and in particular to a dictionary data management method for a cognitive behavioral therapy management system for insomnia. Background Technology
[0002] Currently, dictionary data management in Cognitive Behavioral Therapy for Insomnia (CBTI) systems generally adopts a traditional approach based on front-end storage (such as localStorage / sessionStorage) + synchronous interface requests. The core implementation method is as follows: Data storage: Store dictionary data in the browser cache as a JSON object. Loading logic: The dictionary interface is called synchronously during system initialization; Data processing: Directly use the data returned by the original interface; Data query: Directly read the original cached data.
[0003] The existing technology has the following shortcomings: 1. Disorganized cache management: It uses only a single Object format for storage, which has poor compatibility and lacks automatic expiration verification. Dirty data is still read after the cache expires, resulting in errors in the display of core dictionary data such as therapy type and assessment dimension in the CBTI system. 2. Concurrency issue: Without request debouncing and locking mechanisms, the CBTI system is prone to repeated calls to dictionary interfaces during multi-page initialization, increasing server load and potentially causing data overwriting due to interface return timing issues; 3. Poor data quality: The raw data is not filtered for invalid items and is not standardized in sorting / duplicate removal. The business layer needs to process it repeatedly, which increases the development cost of the CBTI system and is prone to statistical errors in patient assessment results due to dirty data. 4. Low loading efficiency: Synchronous loading mode blocks page rendering and lacks lazy loading logic. It triggers interface requests even when dictionary data is not used, reducing the front-end response speed of the CBTI system. Summary of the Invention
[0004] The purpose of this invention is to provide a dictionary data management method for an insomnia cognitive behavioral therapy management system, in order to solve one or more of the above-mentioned technical problems.
[0005] To achieve this objective, the present invention adopts the following technical solution: The dictionary data management method for the insomnia cognitive behavioral therapy management system includes the following steps: Cache validation steps: In response to a dictionary data request triggered by a business request, multi-level cache validation is performed based on the Pinia management framework. The multi-level cache validation is as follows: check whether there is valid data in the dictionary mapping table in memory. If it exists, proceed directly to the data return step. If the dictionary mapping table in memory does not contain valid data, then check if the local cache exists and has not expired. If the local cache is valid, the cached data is read and its format is converted, and then the process proceeds to the data return optimization step or the data return step. If the local cache has expired or there is no cache, proceed to the dictionary loading and building step; Dictionary loading and building steps: Call the backend dictionary interface to obtain raw dictionary data, and build standardized dictionary data; Data optimization steps: Perform data cleaning on cached data and / or standardized dictionary data, and then proceed to the cache update step; Cache update steps: Update the cached data and / or normalized dictionary data to the dictionary mapping table in memory, set it to persistent local cache, and then proceed to the data return step; Data return steps: In response to the business query request, retrieve the target dictionary data.
[0006] In some implementations, during the cache verification step, if the local cache is valid, the cached data is read and its format is converted. Among them, the format conversion engine is compatible with the reading and storage of two cache data types, Object and Map, and the cache data is uniformly converted into the standard Map format.
[0007] In some implementations, a cache lazy loading mechanism is initiated during the cache verification step.
[0008] In some implementations, the raw dictionary data is obtained by asynchronously calling the backend dictionary interface during the dictionary loading and building step.
[0009] In some implementations, debouncing and locking mechanisms are activated during the dictionary loading and building step.
[0010] In some implementations, the data cleaning step in the data optimization process includes at least: filtering invalid items, sorting according to preset business rules, and deduplication.
[0011] In some implementations, during the cache update step, the cache timestamp is recorded while the local cache settings are persisted.
[0012] In some implementations, during the data return step, a copy of the standardized dictionary data is returned while the target dictionary data is being acquired, and fallback data is provided if the target dictionary data is missing.
[0013] In some implementations, a multi-version cache extension step is also included; Multi-version cache extension steps: Build a multi-version cache entity containing dictionary data, creation timestamps, and version numbers, and write the entity into a local storage key name with version identifiers.
[0014] In some implementations, a full-link reset step is also included; End-to-end reset steps: In response to an externally triggered reset command, the current configuration is overwritten based on the new configuration parameters passed in, and the forced refresh flag determines whether to clear all caches and reload dictionary data, or to only update configuration parameters and retain existing valid caches.
[0015] The beneficial effects of this invention are as follows: This dictionary data management method is implemented based on the Pinia management framework. It constitutes a configurable, highly stable, and multi-scenario adaptable intelligent management system and method for front-end dictionary data, including intelligent four-layer cache verification and automatic expiration control, a configurable dictionary data optimization engine, a debouncing locking mechanism + lazy loading mechanism, data security safeguards, full-link reset supporting hot updates, a unified cache format conversion engine, and a multi-version cache scalable architecture. Attached Figure Description
[0016] Figure 1 This is one of the step diagrams of the dictionary data management method of the insomnia cognitive behavioral therapy management system of the present invention; Figure 2 A flowchart of the dictionary data management method of the insomnia cognitive behavioral therapy management system of the present invention; Figure 3 This is the second step diagram of the dictionary data management method of the insomnia cognitive behavioral therapy management system of the present invention. Detailed Implementation
[0017] The present invention will now be described in further detail with reference to the accompanying drawings.
[0018] refer to Figure 1 and Figure 2 The dictionary data management method of the insomnia cognitive behavioral therapy management system includes: Cache validation steps: In response to a dictionary data request triggered by a business, multi-layer intelligent cache validation is performed based on the Pinia management framework; the multi-layer intelligent cache validation is as follows: check whether there is valid data in the dictionary mapping table dictMap in memory; if it exists, proceed directly to the data return step. If the dictionary mapping table dictMap in memory has no valid data, then check if the local cache exists and has not expired; If the local cache is valid, the cached data is read and its format is converted, and then the process proceeds to the data return optimization step or the data return step. If the local cache has expired or there is no cache, proceed to the dictionary loading and building step; Dictionary loading and building steps: Call the backend dictionary interface to obtain raw dictionary data, and build standardized dictionary data; Data optimization steps: Perform data cleaning on cached data and / or standardized dictionary data, and then proceed to the cache update step; Cache update steps: Update the cached data and / or normalized dictionary data to the dictionary mapping table dictMap in memory, set it to persistent local cache, and then proceed to the data return step; Data return steps: In response to the business query request, return the query results to obtain the target dictionary data.
[0019] In the cache verification step, if the local cache is valid, the cached data is read and its format is converted. Among them, the format conversion engine is compatible with the reading and storage of two cache data types, Object and Map, and the cache data is uniformly converted into the standard Map format.
[0020] As a result, a unified caching format was achieved, improving compatibility: the format conversion engine ensured compatibility with both Object and Map types, eliminating or reducing type exceptions, and increasing the success rate of dictionary data reading in the CBTI system from 85% to 100%.
[0021] In the cache verification step, the cache lazy loading mechanism is started.
[0022] The lazy loading mechanism for cache is an on-demand loading strategy. In the Cognitive Behavioral Therapy for Insomnia (CBTI) management system, the system does not actively preload all dictionary data when the page is initialized or the application starts. Instead, it waits until a certain business module (such as assessment scales or patient management) actually needs to use a specific type of dictionary data before triggering the loading, caching, and return operations for that type of dictionary data.
[0023] Solved the following issues: In existing technologies, synchronous loading blocks page rendering: Traditional solutions synchronously call all dictionary interfaces during system initialization, forcing the page to wait for all dictionary data to return before rendering, resulting in excessively long white screen times. Solved the following issues: In existing technologies, indiscriminate loading wastes resources: Even if some dictionaries (such as a specialist assessment scale) are not needed on the current page, the system still initiates requests, wasting network bandwidth and server resources. Solved the following issues: In existing technologies, slow front-end response speed: The CBTI system needs to respond quickly to user operations (such as doctors viewing patient lists), and excessive initial loading severely impacts user experience.
[0024] As a result, lazy loading of the cache reduces resource consumption: loading is triggered only when data is used, reducing the number of initial interface requests for the CBTI system by 70% and shortening the front-end loading time from 500ms to 100ms.
[0025] In the dictionary loading and building step, standardized dictionary data is constructed to achieve standardized data processing and reduce development costs: the cleaning / sorting logic is uniformly encapsulated, and the business layer does not need to repeat coding, reducing the workload of dictionary-related development in the CBTI system by about 80%.
[0026] In the dictionary loading and building step, the raw dictionary data is obtained by asynchronously calling the backend dictionary interface.
[0027] As a result, asynchronous loading is adapted to modern frameworks: by using Promise to make asynchronous loading logic compatible with the asynchronous programming paradigm of Vue / Pinia, the page rendering blocking rate is reduced from 40% to around 0.
[0028] During the dictionary loading and building process, debouncing and locking mechanisms are activated.
[0029] Before initiating a dictionary interface request, check the request lock status. If the lock is occupied, wait for or discard duplicate requests. If there are no ongoing requests, acquire the lock and call the interface. Release the lock after the request is completed or fails. The debouncing mechanism merges multiple requests for the same dictionary type within a preset debouncing time window.
[0030] To resolve concurrent request conflicts: Debouncing and locking mechanisms prevent duplicate interface calls. The duplicate request rate of the CBTI system dictionary interface has been reduced from 60% to around 0, and the server load has been reduced by about 50%.
[0031] In the data optimization process, data cleaning includes at least: filtering invalid items, sorting according to preset business rules, and deduplication.
[0032] For example, remove dictionary items with empty values, empty labels, or those marked as disabled; Sorting according to preset business rules specifically means: sorting in ascending or descending order based on the sort number field in the dictionary item; Deduplication specifically involves filtering duplicate items based on the unique value field of the dictionary entry.
[0033] As a result, intelligent data cleaning improves data quality: by automatically filtering invalid dictionary entries and deduplicating and sorting, the dirty data rate of the CBTI system has been reduced from 25% to about 0, and the statistical accuracy of patient assessment results has been improved to about 100%.
[0034] During the cache update step, the local cache settings are persisted while the cache timestamp is recorded for subsequent expiration determination.
[0035] For example, the validity of local cache is determined by automatically checking the cache expiration time based on the cache timestamp and the preset cache expiration time; The method also includes a configurable engine for dynamically adjusting cache expiration time, sorting switch, deduplication switch, and debouncing time parameters, and the configuration adjustments take effect in real time without restarting the application.
[0036] This enables automated expiration management and ensures data real-time performance: the timestamp-based cache expiration determination mechanism automatically cleans up expired caches, improving the real-time performance of CBTI system dictionary data by about 90% and avoiding the display of dirty data.
[0037] In the data return step, while retrieving the target dictionary data, a copy of the standardized dictionary data is returned, and fallback data is provided if the target dictionary data is missing.
[0038] Therefore, data security protection: returning a copy of the standardized dictionary data prevents the original data from being tampered with, and the data consistency guarantee rate of the CBTI system is improved by about 100%.
[0039] The fallback data is an empty array to prevent front-end business processes from being interrupted due to missing data; in addition, the returned copy of the standardized dictionary data is a deep copy of the original data to prevent the business layer from tampering with the original data in the cache.
[0040] As a result, the fault tolerance mechanism has been improved: when the interface fails or data is missing, an empty array is automatically returned as a fallback. The error rate caused by dictionary problems in the CBTI system has been reduced from 30% to about 0, and the continuity of core business processes has been improved by about 100%.
[0041] refer to Figure 3 The method also includes a multi-version cache extension step; Multi-version cache extension steps: Construct a multi-version cache entity containing dictionary data, creation timestamps, and version numbers, and write this entity into a local storage key name with version identifiers to achieve isolation and coexistence of dictionary data of different versions.
[0042] This enables support for multi-version cache extensions: configurable multi-version cache switches adapt to the data isolation requirements of different versions of the CBTI system, improving scalability by approximately 100%.
[0043] refer to Figure 3 The method also includes a full-link reset step; End-to-end reset steps: In response to an externally triggered reset command, the current configuration is overwritten based on the new configuration parameters. A forced refresh flag determines whether to clear the entire cache and reload dictionary data, or simply update the configuration parameters and retain the existing valid cache. This achieves efficient reset and update.
[0044] The dictionary data management method of the CBTI Insomnia Cognitive Behavioral Therapy System is suitable for the basic scenario of CBTI system general practice clinics, meets the basic availability of dictionary data, requires no complex configuration, and meets the requirements of "low development cost and high stability".
[0045] The implementation steps are explained below: 1. Initialization configuration (default optimal parameters): In the store directory of the CBTI system front-end project, initialize the dictionary configuration to the basic default values: The cache expiration time is set to 300 seconds (5 minutes) to adapt to the scenario where the general practice clinic dictionary data is updated infrequently; Enable dictionary item sorting to ensure that the dictionary display, including treatment types, is orderly. Enable request debouncing to prevent multiple components from making concurrent requests to the dictionary interface; The stabilization time is set to 300 milliseconds to balance response speed and concurrency control.
[0046] 2. Cache validation steps and dictionary loading and construction steps: When the CBTI system's general practice outpatient module (such as the patient's basic information page) triggers dictionary requests such as "insomnia type": First, check if there is valid data in the dictionary mapping table (dictMap) in memory. If it exists, return it directly. If there is no valid data in memory, check if the local cache has expired: if it has not expired, read the dictionary cache in local storage (localStorage) and convert the cached data into a standard Map format using a format conversion method; If the cache has expired, trigger the dictionary initialization method: first, add a request lock to prevent multiple components from making requests at the same time, and then call the dictionary interface to obtain basic dictionary data such as "insomnia type, treatment stage".
[0047] 3. Data optimization steps, cache update steps, and data return steps: Perform intelligent optimization operations on the dictionary data returned by the dictionary interface: filter dictionary items in the disabled state (such as obsolete therapy types), sort the "insomnia type" dictionary by sort number (sortNum), and remove duplicates based on the value field; The standardized dictionary data is updated in the dictionary mapping table in memory and written to the local cache (expiration time 5 minutes). The business layer calls the method of querying the dictionary by type to obtain the dictionary data of the specified type or the target dictionary (such as the insomnia type). The method returns a copy of the standardized dictionary data (to prevent the original data from being tampered with by the business layer). If the target dictionary data does not exist, an empty array is returned as a fallback.
[0048] This dictionary data management method is applicable to the sleep center specialty scenario of the CBTI system. It needs to support multi-version caching, dynamic configuration, and high-frequency data updates to meet the needs of refined diagnosis and treatment in the specialty (such as multi-version assessment scale dimension dictionaries).
[0049] The implementation steps are explained below: 1. Customized configuration initialization: Initialize a custom configuration for the frequently updated dictionaries such as "assessment scale dimensions" and "treatment plans" used by the sleep center: The cache expiration time has been shortened to 60 seconds (1 minute) to ensure the real-time performance of dictionary data; Preserve sorting, invalid data filtering, and request debouncing functionality; The image stabilization time is set to 500 milliseconds.
[0050] 2. Multi-version cache extension steps: The existing dictionary initialization method is extended with multi-version caching logic, adding version identifiers for different versions of the CBTI evaluation scale dictionary: If multi-version caching is enabled, construct a multi-version cache entity that includes dictionary data, creation time, and version number; Write multiple versions of cached entities to local storage, and concatenate the version number with the cache key name to avoid data conflicts between different versions; If multi-version caching is not enabled, write to the regular cache according to the original logic.
[0051] 3. Full-link reset steps (hot update configuration adjustment): When the sleep center needs to temporarily adjust configurations such as dictionary cache time, it calls the dictionary reset method to dynamically update the configuration: The dictionary reset method accepts two parameters: "force refresh" and "new configuration". When a new configuration is passed in (such as changing the cache expiration time to 30 seconds), the original configuration will be overwritten; If a forced refresh is not required, the existing cache will be retained, and only the configuration will be updated and the dictionary will be reinitialized. Configuration updates take effect immediately without requiring an application restart.
[0052] This dictionary data management method is implemented based on the Pinia management framework. It features intelligent four-layer cache verification and automatic expiration control, a configurable dictionary data optimization engine, a debouncing locking mechanism plus a lazy loading mechanism, data security safeguards, full-link reset support for hot updates, and a unified cache format conversion engine. Value-added capabilities include precise dictionary value-tag lookup and a multi-version cache scalable architecture.
[0053] The protection boundary is limited to the front-end dictionary management of the CBTI system, forming a closed-loop system around caching, data processing, loading control, and configuration management, adapting to multiple scenario requirements. This constitutes a configurable, highly stable, and multi-scenario-adaptable intelligent management system for front-end dictionary data suitable for the CBTI system.
[0054] A configurable dictionary data intelligent management device for an insomnia cognitive behavioral therapy management system includes: Memory, which stores executable instructions; and The processor is configured to execute executable instructions to implement the dictionary data management method of the aforementioned cognitive behavioral therapy management system for insomnia.
[0055] A computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement a dictionary data management method for an insomnia cognitive behavioral therapy management system.
[0056] The above description only discloses some embodiments of the present invention. For those skilled in the art, various modifications and improvements can be made without departing from the inventive concept of the present invention, and these all fall within the scope of protection of the invention.
Claims
1. Dictionary data management methods for the insomnia cognitive behavioral therapy management system, including: Cache validation steps: In response to dictionary data requests triggered by business logic, multi-layer cache validation is performed based on the Pinia management framework; The multi-layered cache verification process proceeds as follows: First, it checks whether there is valid data in the dictionary mapping table in memory. If there is, it proceeds directly to the data return step. If the dictionary mapping table in memory does not contain valid data, then check if the local cache exists and has not expired. If the local cache is valid, the cached data is read and its format is converted, and then the process proceeds to the data return optimization step or the data return step. If the local cache has expired or there is no cache, proceed to the dictionary loading and building step; Dictionary loading and building steps: Call the backend dictionary interface to obtain raw dictionary data, and build standardized dictionary data; Data optimization steps: Perform data cleaning on cached data and / or standardized dictionary data, and then proceed to the cache update step; Cache update steps: Update the cached data and / or normalized dictionary data to the dictionary mapping table in memory, set it to persistent local cache, and then proceed to the data return step; Data return steps: In response to the business query request, retrieve the target dictionary data.
2. The dictionary data management method of the insomnia cognitive behavioral therapy management system according to claim 1, characterized in that, In the cache verification step, if the local cache is valid, the cached data is read and its format is converted. Among them, the format conversion engine is compatible with the reading and storage of two cache data types, Object and Map, and the cache data is uniformly converted into the standard Map format.
3. The dictionary data management method of the insomnia cognitive behavioral therapy management system according to claim 1, characterized in that, In the cache verification step, the cache lazy loading mechanism is started.
4. The dictionary data management method of the insomnia cognitive behavioral therapy management system according to claim 1, characterized in that, In the dictionary loading and building step, the raw dictionary data is obtained by asynchronously calling the backend dictionary interface.
5. The dictionary data management method of the insomnia cognitive behavioral therapy management system according to claim 1, characterized in that, During the dictionary loading and building process, debouncing and locking mechanisms are activated.
6. The dictionary data management method of the insomnia cognitive behavioral therapy management system according to claim 1, characterized in that, In the data optimization process, data cleaning includes at least: filtering invalid items, sorting according to preset business rules, and deduplication.
7. The dictionary data management method of the insomnia cognitive behavioral therapy management system according to claim 1, characterized in that, During the cache update step, the local cache settings are persisted while the cache timestamp is recorded.
8. The dictionary data management method of the insomnia cognitive behavioral therapy management system according to claim 1, characterized in that, In the data return step, while retrieving the target dictionary data, a copy of the standardized dictionary data is returned, and fallback data is provided if the target dictionary data is missing.
9. The dictionary data management method of the insomnia cognitive behavioral therapy management system according to claim 1, characterized in that, It also includes a multi-version cache extension step; Multi-version cache extension steps: Build a multi-version cache entity containing dictionary data, creation timestamps, and version numbers, and write the entity into a local storage key name with version identifiers.
10. The dictionary data management method of the insomnia cognitive behavioral therapy management system according to claim 1, characterized in that, It also includes a full-link reset step; End-to-end reset steps: In response to an externally triggered reset command, the current configuration is overwritten based on the new configuration parameters passed in, and the forced refresh flag determines whether to clear all caches and reload dictionary data, or to only update configuration parameters and retain existing valid caches.