Digital therapy application time consistency test method and device and readable storage medium thereof

Abstract

The application provides a digital therapy application time consistency test method and device and a readable storage medium thereof, and aims at the problems that a real device time effect cannot be simulated and clinical constraint verification is lacked in long-period digital therapy testing. The method analyzes configuration information to obtain a time attribute set of a treatment task; a virtual time axis engine is constructed to run an independent simulation clock, time base deviation is simulated based on an acceleration factor and a clock drift amount is superimposed; a transparent proxy layer is constructed by using a system APIHook and a middleware agent, clock interfaces are intercepted and redirected to realize decoupling injection of the simulation clock and an absolute reference clock; application perception time stamps and real time stamps of triggered events are synchronously collected during running, and time consistency is automatically verified based on clinical time sequence constraint rules. The application is mainly used for reliability verification and compliance certification of time sequence sensitive medical digital therapy software.

Description

Technical Field

[0001] This invention relates to the field of computer software testing technology, and in particular to a method, apparatus and readable storage medium for testing the consistency of digital therapy application time. Background Technology

[0002] Digital Therapeutics (DTx), as a software-driven medical intervention, relies heavily on precise timing for its core treatment logic and intervention mechanisms. Typical scenarios include: delivering treatment intervention content to patients according to a fixed or dynamic schedule; collecting patients' physiological data or behavioral responses within a preset treatment window; dynamically adjusting the timing of subsequent interventions based on historical data; and strictly adhering to the timing rules such as minimum time intervals and timeout thresholds constrained by clinical protocols.

[0003] In existing software verification processes, manual testing or conventional automated testing frameworks are typically employed. When faced with long-term testing scenarios spanning weeks or even months, conventional automated testing frameworks usually accelerate the testing process by modifying a single system clock in the test environment or using simple clock fast-forwarding techniques. During the time-tracking process, the test system reads the current system clock to determine if a timer has triggered, thereby verifying whether the application layer functionality meets expectations.

[0004] However, this simple clock fast-forwarding method is entirely based on an idealized timeline. In real-world mobile terminals, industrial tablets, or medical devices, the real-time clocks generally exhibit complex clock drift effects, such as inherent offsets, nonlinear temperature drift, and noise wandering, due to the influence of ambient temperature fluctuations, voltage instability, and system scheduling interference on the hardware crystal oscillator. Simultaneously, application suspension in the background, device screen locking, or system hibernation often result in time base stagnation. Existing testing techniques cannot simulate these real physical characteristics, making it impossible to effectively expose software reliability vulnerabilities such as timing lockouts and window out-of-bounds errors under the cumulative effects of long-term time cycles during the testing phase.

[0005] Therefore, there is an urgent need for a method, device, and readable storage medium for testing the time consistency of digital therapy applications to address the problems existing in the prior art. Summary of the Invention

[0006] This invention provides a method, device, and readable storage medium for testing the time consistency of digital therapy applications. It addresses the problems of existing testing technologies that only use simple clock fast-forwarding for functional simulation, which fails to simulate the multidimensional clock drift and background suspension time base stagnation of real devices under complex operating environments, and lacks accurate quantitative verification and abnormal root cause tracing mechanisms for long-cycle clinical time constraints.

[0007] The core technology of this invention is to construct a virtual timeline engine that includes a configurable acceleration factor and a multi-dimensional composite clock drift model. It utilizes system interface interception and redirection to build a transparent proxy layer to achieve complete decoupling between the system's absolute reference clock and the application's simulation clock. Furthermore, it achieves automated quantitative verification of clinical timing constraints by comparing the application-aware timestamp with the absolute reference timestamp during the time progression process.

[0008] In a first aspect, the present invention provides a method for testing the consistency of digital therapy application over time, the method comprising the following steps:

[0009] Analyze the configuration information of the digital therapy application under test to obtain the set of time attributes of the treatment task; A virtual timeline engine is constructed, which maintains an independent simulation clock. The simulation clock advances time based on a configured acceleration factor and adds clock drift to simulate the time base deviation of the real device. The virtual timeline engine has built-in multiple configurable clock drift models for clock drift simulation, including one or more combinations of fixed offset model, random walk model and temperature drift model. The simulated clock is decoupled from the absolute reference clock. A transparent proxy layer is built between the digital therapy application under test and the system clock interface by using a combination of system API hook and clock interface middleware proxy. By intercepting and redirecting the system clock call interface of the digital therapy application under test, non-intrusive injection without modifying the source code of the digital therapy application under test is achieved, and the timestamp of the simulated clock is injected into the application layer of the digital therapy application under test. During the operation of the digital therapy application under test driven by the virtual timeline engine, the application-aware timestamps corresponding to the trigger events of the digital therapy application under test and the real timestamps recorded by the absolute reference clock are collected simultaneously. Based on the preset clinical time sequence constraint rules, the time consistency of the two is checked by multi-dimensional clinical time sequence constraint. The multi-dimensional clinical time sequence constraint check includes concurrent execution deviation violation check, time sequence lockout check, window boundary check and interval constraint check.

[0010] Furthermore, obtain the set of time attributes for the treatment task, specifically including: Extract the trigger time of each intervention task, the minimum time interval between adjacent tasks, the start and end time of the treatment window, and the response timeout threshold from the treatment protocol configuration file of the digital therapy application under test.

[0011] Furthermore, various configurable clock drift models are used for clock drift simulation, specifically including: When multiple clock drift models are used in combination, the total clock drift is a linear algebraic sum of the drift values ​​calculated independently by each model. The drift of the fixed offset model is linearly related to the simulation runtime; the drift of the random walk model varies randomly according to a normal distribution; and the drift of the temperature drift model increases nonlinearly with the simulation runtime.

[0012] Furthermore, the process of the transparent proxy layer intercepting and redirecting the system clock call interface also includes: The absolute reference clock operates independently of the simulation clock, serves as a reference time for recording events, and does not drive the internal logic of the digital therapy application under test.

[0013] Furthermore, the deviation violation verification specifically includes: Calculate the difference between the perceived timestamp and the actual timestamp. If the difference exceeds the preset clinical tolerance range, it is marked as a deviation violation.

[0014] Furthermore, the timing lock loss verification specifically includes: Monitor the trigger status at preset time points. If a trigger that should have been triggered is not triggered, or a trigger that was not triggered at a preset time point, or a trigger sequence that is disordered, mark it as a timing lockout.

[0015] Furthermore, the window boundary verification and interval constraint verification specifically include: If the intervention task is triggered outside the treatment window, it is marked as a window out of bounds; if the time interval between two consecutive triggers is less than the minimum time interval constraint, it is marked as an interval violation.

[0016] Secondly, the present invention provides a digital therapy application time consistency testing device, comprising: The parsing module is used to parse the configuration information of the digital therapy application under test and obtain the time attribute set of the treatment task; The engine building module is used to build a virtual timeline engine. The virtual timeline engine maintains an independent simulation clock. The simulation clock advances time based on a configured acceleration factor and adds clock drift to simulate the time base deviation of real devices. The virtual timeline engine has built-in multiple configurable clock drift models for clock drift simulation. The clock drift models include one or more combinations of fixed offset models, random walk models, and temperature drift models. The clock decoupling module is used to decouple the simulated clock from the absolute reference clock. It adopts a combination of system API hook and clock interface middleware proxy to build a transparent proxy layer between the digital therapy application under test and the system clock interface. By intercepting and redirecting the system clock call interface of the digital therapy application under test, non-intrusive injection without modifying the source code of the digital therapy application under test is achieved, and the timestamp of the simulated clock is injected into the application layer of the digital therapy application under test. The verification module is used to synchronously collect the application-aware timestamps and the real timestamps recorded by the absolute reference clock corresponding to the trigger events of the digital therapy application under test during the operation of the virtual timeline engine. Based on the preset clinical time sequence constraint rules, the module performs multi-dimensional clinical time sequence constraint verification on the time consistency of the two. The multi-dimensional clinical time sequence constraint verification includes concurrent execution deviation violation verification, time sequence lockout verification, window boundary verification, and interval constraint verification.

[0017] Thirdly, the present invention provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the above-described digital therapy application time consistency test method.

[0018] Fourthly, the present invention provides a readable storage medium storing a computer program, the computer program including program code for controlling a process to execute the process, the process including the digital therapy application time consistency test method described above.

[0019] The main contributions and innovations of this invention are as follows: 1. This invention, by configuring an acceleration factor in the virtual timeline engine, can compress a complete treatment plan that originally required weeks or months into a few hours. While significantly shortening the testing cycle, it can effectively reproduce the software behavior under the long-term cumulative effect, and significantly improve the verification efficiency of long-cycle time-sensitive medical software.

[0020] 2. This invention incorporates a fixed offset model, a random walk model, and a temperature drift model, and supports the linear algebraic superposition of multiple models. It can accurately simulate the clock physical characteristics of real mobile terminals or medical terminals under harsh conditions such as low temperature, high temperature, and voltage fluctuations, effectively exposing timing anomalies under composite clock drift interference, and improving the authenticity and coverage of the test.

[0021] 3. This invention utilizes system API hooks and clock interface middleware proxy technology to establish a transparent proxy layer, completely isolating the simulated clock from the absolute reference clock. Under the premise that the application does not need to modify its source code and remains completely transparent in operation, the independently running absolute reference clock can provide an absolutely accurate calibration benchmark. By calculating the difference between the application's perceived timestamp and the absolute reference timestamp in real time to form a time base deviation log, continuous collection and root cause localization of time deviations are achieved.

[0022] 4. This invention transforms complex clinical protocols into technical verification rules, concurrently executing deviation violation verification, timing lockout verification, window boundary verification, and interval constraint verification throughout the entire test lifecycle. It can automatically capture abnormal states such as missed triggers, incorrect triggers, window out-of-bounds, and interval violations, filling the technical gap in closed-loop verification of the reliability of complex timing logic in the field of digital therapy, and strongly supporting the compliance verification and reliability certification of medical device software.

[0023] Details of one or more embodiments of the present invention are set forth in the following drawings and description, so that other features, objects and advantages of the invention will be more readily understood. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is an overall architecture diagram of the digital therapy application time consistency testing method according to an embodiment of the present invention; Figure 2 This is a flowchart of the virtual timeline engine workflow according to an embodiment of the present invention; Figure 3 This is a schematic diagram of clock decoupling and deviation acquisition according to an embodiment of the present invention; Figure 4 This is a time consistency verification logic diagram according to an embodiment of the present invention; Figure 5 This is a time-base deviation trend curve for digital therapy applications according to embodiments of the present invention; Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0026] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0027] Digital Therapeutics (DTx), as a software-driven medical intervention, relies heavily on precise time-triggered mechanisms for its core treatment logic. Typical scenarios include: pushing treatment intervention content to patients according to a fixed or dynamic schedule; collecting patients' physiological data or behavioral responses within a preset treatment window; dynamically adjusting the timing of subsequent interventions based on patients' historical data; and strictly adhering to timing rules such as minimum time intervals and timeout thresholds constrained by clinical protocols. This invention achieves highly realistic, quantifiable, and automated verification of the above-mentioned timing scenarios through a virtual timeline engine and clock decoupling technology.

[0028] Example 1 This embodiment provides a method for testing the consistency of digital therapy application over time. See also... Figure 1 This embodiment is built on a fully isolated dual-clock architecture, and its core testing process includes the following steps: Step S1: Analysis of the Time Attributes of the Treatment Plan The configuration information of the digital therapy application under test is analyzed to obtain the set of time attributes for treatment tasks. Specifically, the treatment plan parsing module reads and parses the configuration file of the digital therapy application under test (the configuration file adopts a structured data format such as JSON or XML), and extracts all time-related clinical constraint attributes. The extracted time attributes include at least: the preset trigger time point of each intervention task; the minimum time interval constraint between adjacent tasks; the start and end times of each treatment window; the response timeout threshold; and the clinical tolerance range. Among them, the clinical tolerance range is used to define the maximum acceptable deviation between the application's perceived time and the absolute reference time.

[0029] The parsed time attribute set is stored in memory as structured data, serving as the baseline source for multi-dimensional validation rules in subsequent steps. If there are incomplete rule definitions or logical conflicts in the configuration file, the parsing module will synchronously output alarm messages to prompt corrections.

[0030] Step S2: Build a virtual timeline engine A virtual timeline engine is constructed, which runs independently and maintains a simulation clock unaffected by the system's real clock. The simulation clock advances time based on a configured acceleration factor to enable rapid simulation of long-cycle treatment protocols (i.e., simulating a complete treatment cycle of several months within a few hours of physical reality). This engine also supports a normal speed test mode with an acceleration factor of 1 to ensure compatibility with standard functional verification.

[0031] See Figure 2 After the virtual timeline engine starts and loads its configuration, the built-in clock drift simulator dynamically calculates and injects drift amounts based on the configured clock drift model at each time step, thereby generating a simulated timestamp with drift effects usable by the application. The clock drift models include a fixed offset model, a random walk model, and a temperature drift model, which can be enabled individually or in combination. When multiple models are enabled in combination, the total clock drift is a linear algebraic sum of the drift amounts calculated independently by each model; that is, each model is calculated independently and then directly summed and injected into the simulated clock, without weighting coefficients, priority sorting, or complex fusion algorithms. This direct summation simulation method closely matches the physical crystal oscillator characteristics of real hardware devices, exhibiting extremely high reproducibility and verifiability.

[0032] (1) Fixed offset model The drift amount in the fixed offset model is linearly related to the simulation runtime, and it is used to simulate the continuous cumulative drift of a real-time clock (RTC) due to the inherent frequency deviation of the crystal oscillator. Its mathematical expression is:

[0033] in, For a fixed offset drift, k is the drift rate (in seconds / hour), and t is the simulation runtime. The typical parameter configuration range for k is 0.1 s / h to 10 s / h.

[0034] The range of this parameter is determined based on the fact that the typical inherent offset of a mobile device's real-time clock (RTC) at room temperature is ±0.5 to 5 seconds per day (approximately 0.02 to 0.2 seconds per hour). However, considering harsh clinical usage scenarios such as low temperatures, high temperatures, and battery voltage fluctuations, the crystal oscillator offset typically increases by 5 to 10 times. Therefore, to ensure complete engineering coverage, the range is set to 0.1 seconds per hour to 10 seconds per hour, thus comprehensively covering the clock deviation range of ordinary mobile phones, industrial tablets, and medical-specific terminals. The design of this model also references the publicly available accuracy specifications of RTC chip manufacturers and the ISO 8601 timing accuracy standard.

[0035] (2) Random walk model The drift in the random walk model varies randomly according to a normal distribution following a Wiener process. It is used to simulate clock phase noise caused by random dynamic factors such as sudden temperature jumps, power supply ripple noise, and microsecond-level scheduling interference at the system's lower levels. Its mathematical expression is:

[0036] in, This represents the random walk drift at the current moment. This represents the drift amount at the previous moment; To conform to a mean of 0 and a variance of The normally distributed random disturbance quantity, The disturbance intensity is represented by . The typical parameter range is configured from 1s to 10s.

[0037] The determination of this parameter range is based on the following: Mobile devices typically experience less than 10ms of time jitter under normal operation, but over long periods, the accumulated discrete phase noise over one hour can typically reach ±1s to ±10s; while medical-grade high-reliability devices typically require less than 5s / hour for short-period random disturbances in the crystal oscillator. Therefore, setting... It can perfectly cover system noise environments ranging from normal operating conditions to harsh medical-grade operating conditions within 1 to 10 seconds.

[0038] (3) Temperature drift model The drift of the temperature drift model increases non-linearly with the simulation runtime. It is used to fit the non-linear drift characteristics of the internal crystal oscillator of a mobile terminal under continuous operation, high-load computing, or continuous screen-on heat generation. Its mathematical expression is:

[0039] Where a, b, and c are configurable polynomial fitting coefficients, obtained by fitting the heating drift curve of the measured equipment over 24 hours. The cumulative temperature drift over a typical 24-hour simulation is controlled within the range of +30s to +90s.

[0040] The determination of this parameter range is based on the following: Actual test data shows that after smartphones have been running high-load medical software continuously for 24 hours or with the screen on, the temperature drift caused by heat generation is generally within the range of +20s to +100s; while mainstream medical terminal standards require that the upper limit of temperature drift fluctuation within 24 hours should not exceed ±60s. Therefore, this invention selects +30s to +90s as a typical engineering range, which can effectively simulate the nonlinear temperature drift effect and meets the reliability verification requirements of the IEC 62304 medical device software lifecycle standard.

[0041] Step S3: Decouple the simulation clock from the absolute reference clock The simulation clock is completely decoupled and isolated from the system's absolute reference clock. Specifically, after deploying the digital therapy application under test to the physical test equipment or simulator, the clock decoupling and injection module uses a combination of system API hooking and clock interface middleware proxying to build a transparent proxy layer between the digital therapy application and the system's underlying clock interface, enabling the interception and redirection of system clock call interfaces. After interception, the application layer no longer directly reads the physical device's system clock; all time information it obtains is uniformly provided by the timestamp of the simulation clock through the transparent proxy layer.

[0042] To achieve broad cross-platform compatibility, specialized adaptation solutions are provided for different operating system layers: On the Android platform, interfaces such as `System.currentTimeMillis()`, `System.nanoTime()`, and `SystemClock.elapsedRealtime()` are dynamically intercepted; on the iOS platform, interfaces such as `NSDate`, `CFAbsoluteTimeGetCurrent()`, and `mach_absolute_time()` are intercepted; and on embedded real-time operating systems (RTOS) or medical device platforms, `time()`, `gettimeofday()`, and the underlying read interfaces of the RTC driver are directly intercepted.

[0043] The transparent proxy layer redirects clock calls non-intrusively through runtime method swizzling, dynamic library injection (LD_PRELOAD / Dylib Injection), virtual machine proxies, or framework middleware. This process is entirely external, requiring no modification to the source code of the digital therapy application under test, nor recompilation, and has no intrusion into the application's business logic. Under various complex scheduling scenarios, including foreground / background switching, system hibernation, screen locking, and crash restarts, the digital therapy application remains unaware of the difference between the simulated clock and the system's real clock, thus ensuring absolute consistency between its test performance and the real production environment.

[0044] After decoupling, the two clocks operate in complete isolation: the absolute reference clock serves as the time base source for the entire test system, outputting an absolute reference timestamp and independently recording the absolute time when events actually occur. It is used specifically for subsequent legality verification and does not participate in driving any internal timing logic of the application; while the simulation clock continues to advance independently, only used to drive the internal logic of the application, and does not make any modification to the actual system time of the physical device itself.

[0045] Step S4: Time Advancement and Deviation Acquisition The virtual timeline engine drives the simulated clock forward according to the configured speedup factor and clock drift model, and dynamically injects virtual time events with drift increments into the application's system clock interface layer. See also Figure 3 The clock decoupling and deviation acquisition principle is that when the timer inside the digital therapy application layer is triggered or an intervention task response occurs, the time acquisition unit of the test environment will synchronously and concurrently capture two clock values ​​when the application under test triggers the event: the application-aware timestamp (the time value injected by the simulation clock and perceived by the application) and the real timestamp (baseline time value) recorded by the absolute reference clock at the same instant.

[0046] Upon receiving the dual clock timestamps, the system immediately calculates the difference between them (application-perceived timestamp - actual timestamp) to form a quantifiable and traceable time-base deviation log. Each time-base deviation log contains traceability information such as simulation time, actual timestamp, deviation value, task ID, anomaly type, and module location. In this invention, time-base deviation quantization constitutes a complete closed-loop measurement system, covering the entire process of real-time sampling, deviation calculation, log storage, violation judgment, trend curve plotting, and anomaly root cause localization, rather than a simple static numerical comparison.

[0047] During automated verification, this testing method possesses robust exception handling and boundary support mechanisms. For boundary scenarios such as crashes, restarts, active foreground / background switching, or system hibernation in the digital therapy application under test, this system employs a checkpoint-based state persistence mechanism to restore simulation time and drift states. The specific implementation scheme is as follows: During the virtual timeline-driven operation of the digital therapy application under test, the log and report generation module or engine control unit performs persistent backup of state data at preset simulation time step intervals (e.g., every 1 hour of equivalent simulation) or at the moment of triggering a key clinical time event (e.g., the opening of the treatment window or the triggering of an intervention task). During backup, the system captures the current running state dataset in real time. This dataset includes at least: the current simulation timestamp value, and the internal control variables of each clock drift model (including the current inherent absolute drift value, the current state value of the random walk, and the duration accumulation factor of the nonlinear temperature drift).

[0048] The control unit serializes the running status dataset, converts it into structured text or binary data stream, and persistently writes it to the non-volatile storage medium of the physical test device (specifically, through a local SQLite database or a specific disk configuration file), forming a dynamic checkpoint file covered by time series.

[0049] When the system detects a crash, restart after being killed by a process, or the device waking from a sleep / locked state in the digital therapy application under test, the virtual timeline engine first triggers the state recovery callback logic: it reads the last successfully fixed checkpoint file from the non-volatile storage medium, deserializes and parses it to extract the simulation timestamp value before the crash and the internal control variables of each drift model. Subsequently, the system uses the extracted data to reinitialize and forcibly overwrite the current count value of the software counter in the independent thread, and restores the internal control state of the clock drift simulator. This process is completely transparent to the application layer, thereby ensuring seamless and continuous verification of the simulation timeline and drift state without interrupting the overall testing process.

[0050] Step S5: Automatic Time Consistency Verification Throughout the entire lifecycle of digital therapy applications, the timing monitoring and verification module continuously and automatically verifies the timing deviation log based on the clinical timing constraint rules parsed in step S1. See also... Figure 4 The verification logic flow is as follows: after an event is triggered, the system automatically performs a judgment through the following four dimensions of the verification funnel: (1) Deviation violation verification Calculate the difference between the applied sensing timestamp and the actual timestamp in the current triggering event. If the absolute value of this difference exceeds the preset clinical tolerance range (i.e., applied sensing time - absolute reference time > clinical tolerance), the system automatically determines that an excessive displacement has occurred due to time drift, marks it as a deviation violation, and records the anomaly. This verification supports bidirectional detection, capable of capturing both negative drift due to application time being ahead and positive drift due to application time being behind.

[0051] (2) Timing lock loss check Based on the treatment plan attributes, verify whether the application is triggered precisely at the preset time point. If situations such as "failed to trigger at the preset time point (missed trigger)," "triggered at a non-preset time point (incorrect trigger)," or "disordered triggering order among multiple intervention tasks" occur, it is determined that the timing lock has failed and is marked as timing lockout.

[0052] (3) Window boundary validation Verify whether the actual trigger time or patient response time of the current intervention task falls within the clinically required treatment window. The specific judgment rule is: if the trigger time is less than the start time of the treatment window, or the trigger time is greater than the end time of the treatment window, then the treatment action is judged to be out of bounds and marked as window out of bounds.

[0053] (4) Interval constraint verification Verify the time density between adjacent intervention tasks. The specific judgment rule is as follows: calculate the difference between the current task trigger time and the previous successful trigger time. If the difference is less than the preset minimum clinical time interval constraint (current trigger time - previous trigger time < minimum time interval), it is marked as an interval violation.

[0054] The above four dimensions of verification can be executed concurrently by the verification module to comprehensively capture potential timing risks over long periods.

[0055] Step S6: Generate Verification Report All verification anomalies and time base deviation logs captured throughout the entire test lifecycle are aggregated and sent to the log and report generation module for visualization and compliance assessment. The final output standardized time consistency verification report supports standardized output formats such as PDF, HTML, XML, and CSV.

[0056] The verification report includes anomaly distribution statistics, violation trend charts, dynamic root cause localization information for each anomaly record, and trend curves showing the accumulation of deviations over time. Each anomaly record in the report achieves end-to-end data traceability, complying with the requirements of medical software compliance certifications such as IEC 62304 (Medical Device Software Lifecycle Standard) and ISO 14971 (Medical Device Risk Management Standard).

[0057] Furthermore, this testing method possesses robust control during execution: when the application under test crashes, restarts, actively switches between foreground and background, or the physical device enters hibernation, screen locks, or is suspended in the background during testing, the transparent proxy layer and timeline engine can maintain the continuity of the simulation clock's timeline, automatically restoring the simulation time and drift state without interrupting the test; the system fully supports simulation calculations across days, months, years, and time zones, ensuring the continuity of long-term time sequences; when the total clock drift exceeds the system's preset safety protection threshold, the engine will automatically pause and properly solidify the current alarm log, ensuring that the integrity of the test data is not compromised.

[0058] Example 2 This embodiment, based on the method of Embodiment 1, provides a specific scenario for time consistency testing of digital therapy applications in chronic disease management with medium-precision timing triggering requirements. The configuration parameters of its test control terminal are as follows: With the virtual timeline engine's acceleration factor set to 1000x, running it for one hour in a real environment effectively simulates the application's complete treatment lifecycle of up to 41 days. Regarding the drift model selection, this embodiment only uses the temperature drift model, setting the nonlinear clock drift over a typical 24-hour simulation to be between +30s and +90s. Its temperature drift polynomial expression is:

[0059] The configurable coefficients a, b, and c in the formula are determined by fitting the measured drift curve of the target smartphone running under high load for 24 hours with continuous screen illumination.

[0060] According to the clinical protocol, the clinical tolerance range of the judgment threshold is set to ±60s, the sampling frequency is configured to 1 time / second, and the timing monitoring and verification module performs real-time recording and continuous verification.

[0061] See Figure 5 The graph shows the time-base deviation trend curve for digital therapy applications in this embodiment. The horizontal axis represents the simulation time (1–28 days), and the vertical axis represents the time-base deviation (seconds). The red dashed line represents the preset ±60s clinical tolerance boundary line. This curve clearly traces and quantifies the time deviation behavior throughout the entire long-term simulation process. During the first 7 days of the simulation, the curve showed that the deviation was slowly rising and stabilizing within the acceptable range of +20s to +60s. During the 7th to 14th days, due to the continuous accumulation and aggravation of the temperature drift effect of the simulated equipment crystal oscillator, the curve rose rapidly and nonlinearly, reaching a peak of +128s around the 14th day. Since this point broke through the red dashed line boundary, the verification module automatically marked it as a time deviation violation and triggered an alarm. During days 14–21, the time base deviation rapidly decreased to the +30s to +60s range because the test environment simulated the time synchronization operations of the application switching to the background and waking up in the foreground; during days 21–28, the deviation tended to stabilize, averaging around +40s. This example fully demonstrates the quantifiable and traceable ability of this invention to assess the cumulative effects over long periods.

[0062] Example 3 This embodiment, based on the method of Embodiment 1, provides a time consistency testing scenario for digital therapy applications in sleep monitoring and respiratory intervention with high sensitivity and high temporal response accuracy. The configuration parameters of its test control terminal are as follows: With the virtual timeline engine's acceleration factor set to 10,000, running one hour of real time in the physical world allows for a high-magnification simulation of an ultra-long treatment cycle of up to 138 days. Regarding the drift model selection, to simulate the complex high-frequency phase jitter caused by temperature jumps and power supply ripple, this embodiment only uses a random walk model, configuring normally distributed perturbation intensity parameters. =5s. The mathematical expression for its random walk model is:

[0063] Because respiratory intervention medical software is extremely sensitive to the boundaries of the time window, this embodiment narrows the clinical tolerance range and strictly sets it to ±30s, and maintains the sampling frequency at 1 time / second to perform high-frequency real-time dynamic acquisition and continuous verification of time base deviation.

[0064] During the test execution, the test control terminal used interface commands to force the simulation of typical edge scenarios such as application suspension in the background, device screen lock, system hibernation, and restart after process is killed. The timing monitoring and verification module concurrently performed timing lockout verification and window boundary verification to verify the timing stability and clinical protocol compliance of digital therapy applications under the dual effects of extreme hardware scheduling interference and uncertain random noise.

[0065] Example 4 This embodiment provides a system for testing the time-consistency of digital therapy applications. See also: Figure 1 The overall system architecture of the test system includes the following interconnected hardware or software functional modules: The parsing module (i.e., the treatment plan parsing module) is used to parse the configuration information of the digital therapy application under test and obtain the set of time attributes of the treatment task. Its input receives a structured application configuration file, and its output output contains a set of time attributes such as trigger time points, task interval constraints, treatment windows, and clinical tolerances.

[0066] The engine building block (i.e., the virtual timeline engine) is used to build and maintain an independent simulation clock, enabling it to advance time based on a configured acceleration factor and superimposing clock drift amounts generated by the clock drift simulator. Its inputs are connected to the configuration parameters (acceleration factor, drift model, simulation duration) of the test control terminal, and its outputs include simulation timestamps and advancement events with drift characteristics.

[0067] The clock decoupling module (i.e., the clock decoupling and injection module) is used to completely decouple the simulation clock from the system absolute reference clock. It intercepts and redirects clock calls by building a transparent proxy layer at the system call interface layer, transparently injecting the simulation clock's timestamp into the application layer under test. Its input connects to the simulation timestamp and drift amount output by the engine building module, and its output injects virtual time events into the application interface layer of the test environment.

[0068] The verification module (i.e., time series monitoring and verification module) is used to synchronously collect the application-aware timestamp and the real timestamp recorded by the absolute reference clock corresponding to the trigger event during application operation, and automatically verify the time consistency of the two based on preset clinical time series constraint rules, including deviation, lockout, window, and interval dimensions. Its input end connects to the application trigger event, dual clock timestamps, and constraint rules output by the parsing module, and its output end outputs multi-dimensional verification results and time base deviation logs.

[0069] The data flow and topological relationships between the above modules are as follows: Figure 1 As shown: The test control terminal distributes configuration commands to the engine build module; The time rules extracted by the parsing module are sent to the verification module as comparison criteria. The simulation clock signal output by the engine building module is injected into the digital therapy application in the test environment via the transparent proxy layer of the clock decoupling module to drive its operation; The runtime data generated after the application timer is triggered is sent to the verification module in real time for multi-dimensional verification and vulnerability determination. The time base deviation logs, anomaly records, and verification results output by the verification module are finally aggregated into the log and report generation module, which then draws trend curves and outputs standardized verification reports.

[0070] Example 5 This embodiment also provides an electronic device, see reference. Figure 6 It includes a memory 404 and a processor 402, wherein the memory 404 stores a computer program and the processor 402 is configured to run the computer program to perform the steps in any of the above method embodiments.

[0071] Specifically, the processor 402 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement embodiments of the present invention.

[0072] Memory 404 may include a mass storage device for data or instructions. For example, and not limitingly, memory 404 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 404 may include removable or non-removable (or fixed) media. Where appropriate, memory 404 may be internal or external to a data processing device. In a particular embodiment, memory 404 is non-volatile memory. In a particular embodiment, memory 404 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable read-only memory (EPROM), an electrically erasable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random-Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random-Access Memory (FPMDRAM), Extended Data Out Dynamic Random-Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0073] The memory 404 can be used to store or cache various data files that need to be processed and / or communicated, as well as possible computer program instructions executed by the processor 402.

[0074] The processor 402 reads and executes computer program instructions stored in the memory 404 to implement any of the digital therapy application time consistency testing methods in the above embodiments.

[0075] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408, wherein the transmission device 406 is connected to the processor 402, and the input / output device 408 is connected to the processor 402.

[0076] The transmission device 406 can be used to receive or send data via a network. Specific examples of the network described above may include wired or wireless networks provided by the communication provider of the electronic device. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 406 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0077] Input / output device 408 is used to input or output information.

[0078] Example 6 This embodiment also provides a readable storage medium storing a computer program, the computer program including program code for controlling a process to execute the process, the process including a digital therapy application time consistency test method according to Embodiment 1.

[0079] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0080] Generally, various embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention can be implemented in hardware, while others can be implemented by firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, by way of non-limiting example, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0081] Embodiments of the present invention can be implemented by computer software, which may be executable by a data processor of a mobile device, such as a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets, and / or macros can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. The computer program product may include one or more computer-executable components configured to perform the embodiments when the program is run. The one or more computer-executable components may be at least one piece of software code or a portion thereof. Additionally, it should be noted in this respect that, as Figure 1 Any box in the logical flow can represent a program step, or interconnected logic circuits, boxes and functions, or a combination of program steps and logic circuits, boxes and functions. Software can be stored on physical media such as memory chips or blocks of storage implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, CDs, etc. The physical medium is a non-transient medium.

[0082] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0083] The above embodiments are merely illustrative of several implementations of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the appended claims.

Claims

1. A method for testing the time consistency of digital therapy applications, characterized in that, Includes the following steps: Analyze the configuration information of the digital therapy application under test to obtain the set of time attributes of the treatment task; A virtual timeline engine is constructed, which maintains an independent simulation clock. The simulation clock advances time based on a configured acceleration factor and adds clock drift to simulate the time base deviation of a real device. The virtual timeline engine has built-in multiple configurable clock drift models for clock drift simulation, including one or more combinations of fixed offset models, random walk models, and temperature drift models. The simulated clock is decoupled from the absolute reference clock. A transparent proxy layer is built between the digital therapy application under test and the system clock interface by using a combination of system API hook and clock interface middleware proxy. By intercepting and redirecting the system clock call interface of the digital therapy application under test, non-intrusive injection without modifying the source code of the digital therapy application under test is achieved, and the timestamp of the simulated clock is injected into the application layer of the digital therapy application under test. During the process of the virtual timeline engine driving the digital therapy application under test, the application-aware timestamps corresponding to the trigger events of the digital therapy application under test and the real timestamps recorded by the absolute reference clock are collected synchronously. Based on the preset clinical timeline constraint rules, the time consistency of the two is checked by multi-dimensional clinical timeline constraint verification. The multi-dimensional clinical timeline constraint verification includes concurrent execution deviation violation verification, timeline lockout verification, window boundary verification and interval constraint verification. The various configurable clock drift models used for clock drift simulation specifically include: When multiple clock drift models are used in combination, the total clock drift is a linear algebraic sum of the drift values ​​calculated independently by each model. The drift of the fixed offset model is linearly related to the simulation runtime; the drift of the random walk model varies randomly according to a normal distribution; and the drift of the temperature drift model increases nonlinearly with the simulation runtime. The process of the transparent proxy layer intercepting and redirecting the system clock call interface also includes: The absolute reference clock operates independently of the simulation clock, is used to record the reference time of events, and does not drive the internal logic of the digital therapy application under test.

2. The method for testing the consistency of digital therapy application time as described in claim 1, characterized in that, Obtain the time attribute set of the healing task, specifically including: Extract the trigger time of each intervention task, the minimum time interval between adjacent tasks, the start and end time of the treatment window, and the response timeout threshold from the treatment protocol configuration file of the digital therapy application under test.

3. The method for testing the consistency of digital therapy application time as described in claim 1, characterized in that, The deviation violation verification specifically includes: The difference between the perceived timestamp and the actual timestamp is calculated. If the difference exceeds the preset clinical tolerance range, it is marked as a deviation violation.

4. The method for testing the consistency of digital therapy application time as described in claim 1, characterized in that, The timing lock loss verification specifically includes: Monitor the trigger status at preset time points. If a trigger that should have been triggered is not triggered, or a trigger that was not triggered at a preset time point, or a trigger sequence that is disordered, mark it as a timing lockout.

5. The method for testing the consistency of digital therapy application time as described in claim 1, characterized in that, The window boundary verification and interval constraint verification specifically include: If the intervention task is triggered outside the treatment window, it is marked as a window out of bounds; if the time interval between two consecutive triggers is less than the minimum time interval constraint, it is marked as an interval violation.

6. An apparatus for implementing the digital therapy application time consistency testing method according to claim 1, characterized in that, include: The parsing module is used to parse the configuration information of the digital therapy application under test and obtain the time attribute set of the treatment task; An engine building module is used to build a virtual timeline engine. The virtual timeline engine maintains an independent simulation clock, which advances time based on a configured acceleration factor and adds clock drift to simulate the time base deviation of a real device. The virtual timeline engine has built-in multiple configurable clock drift models for clock drift simulation, including one or more combinations of fixed offset models, random walk models, and temperature drift models. The clock decoupling module is used to decouple the simulated clock from the absolute reference clock. It adopts a combination of system API hook and clock interface middleware proxy to build a transparent proxy layer between the digital therapy application under test and the system clock interface. By intercepting and redirecting the system clock call interface of the digital therapy application under test, non-intrusive injection without modifying the source code of the digital therapy application under test is achieved, and the timestamp of the simulated clock is injected into the application layer of the digital therapy application under test. The verification module is used to synchronously collect the application-aware timestamps corresponding to the trigger events of the digital therapy application under test and the real timestamps recorded by the absolute reference clock during the process of the virtual time axis engine driving the digital therapy application under test. Based on the preset clinical time sequence constraint rules, the module performs multi-dimensional clinical time sequence constraint verification on the time consistency of the two. The multi-dimensional clinical time sequence constraint verification includes concurrent execution deviation violation verification, time sequence lockout verification, window boundary verification, and interval constraint verification.

7. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the digital therapy application time consistency test method according to any one of claims 1 to 5.

8. A readable storage medium, characterized in that, The readable storage medium stores a computer program, the computer program including program code for controlling a process to execute the process, the process including the digital therapy application time consistency test method according to any one of claims 1 to 5.

Images