Modular digital therapeutic system and computer-implemented method

Abstract

1. A digital therapeutic system comprising: a core package; and a therapy package, the core package being software separated from the therapy package, the core package adapted to receive a therapy configuration from the therapy package and configure one or more patient treatment therapies based on the therapy configuration.

Description

[Technical field]

[0001] The present invention relates to methods and systems suitable for use in providing digital therapeutics, and in particular to a modular digital therapeutic system and its operation. [Background technology]

[0002] Patients may receive treatment for one or more diseases or conditions via digital therapeutics (DTx). DTx comprises software that can itself convey therapeutic benefit to the patient without the involvement of a human medical professional. Thus, DTx is effectively the use of "software as medicine". As a therapeutic, DTx may require regulatory approval from the drug regulator. As software, DTx also falls within the definition of a medical device as defined by the FDA (200 CFR 80) and the EU&UK (Regulation (EU) 2017 / 745).

[0003] The regulatory side is primarily concerned with three aspects of "Software as a Medical Device" (SaMD): ·Applications Effectiveness ·Safety

[0004] Uses are often defined by the manufacturer of the SaMD, and efficacy and safety are usually proven through clinical trials, which are expensive and time-consuming to conduct.

[0005] Latest Software 426 is a development paradigm that involves releasing software as early as possible and then rapidly iterating on incremental improvements while taking into account real-world end-user usage and feedback.

[0006] This is at odds with SaMD because manufacturers may not want to replicate SaMD once it enters clinical trials, given the burden (cost and time) associated with gaining regulatory approval, however this may preclude the ability to observe SaMD in use in the real world and improve it accordingly.

[0007] Regulatory burdens may also prevent SaMDs from incorporating the latest findings, research, or guidelines for a given treatment or therapy to avoid amending the SaMD package. This problem may be exacerbated for DTx or SaMDs that include coordinated therapies (multiple therapies) for each disease or condition. For example, DTx may include a dosing regimen for a pharmacological therapy combined with a non-pharmacological therapy, such as cognitive behavioral therapy (CBT) or an exercise regimen. This problem may be further exacerbated for SaMD-based digital therapeutic systems configured to treat multiple diseases or conditions.

[0008] In view of the above, there is a need for systems and methods for providing digital therapeutics that can be updated and improved based on new developments regarding the use of SaMDs and changing knowledge and guidance regarding one or more particular therapies, in a manner that is compliant with regulatory requirements without being undue burdensome. Summary of the Invention

[0009] According to a first aspect of the present disclosure, there is provided a digital therapeutic system, comprising: The core package, Treatment packages and an interface arranged to software split the core package from the treatment package; The core package is Receive a treatment configuration from a treatment package; and A digital therapeutic system is provided that is adapted to configure one or more patient treatment therapies based on the treatment configuration.

[0010] The software separation of the core package from the therapy package allows the two parts to be assessed independently for regulatory compliance. As a result, the two parts may also be updated independently if the impact on the other is within acceptable limits according to the regulations. Separating a digital therapy system into two (or more) parts allows for the separation of software components or modules depending on their regulatory burden and / or expected frequency of iteration.

[0011] The system can be partitioned to provide generic components in a core package and therapy-specific components in therapy packages. In this way, the core package can be used in conjunction with or independently of multiple therapy packages without requiring reapproval of the core package for each therapy.

[0012] The disclosed digital therapeutic system may provide one or more of the following advantages. For users: The system can provide a consistent user interface experience while supporting different treatments. The system can perform several different treatments simultaneously. The system can manage and streamline requests for action resulting from multiple therapies (e.g., two therapies may both require a blood pressure reading). The system can streamline data requirements and issue a single notification to the patient that can then relay that measurement to multiple therapies. The system may provide continuity of user personalization from one treatment to the next. For system providers: Separation of functionality can reduce the regulatory burden for new / updated treatments or functionality Allows easier / more frequent iteration of components that are not subject to high regulatory scrutiny

[0013] The digital therapeutic system may be a SaMD and may provide one or more digital therapeutics.

[0014] While the disclosure is susceptible to various modifications and alternative forms, details of which have been shown by way of example in the drawings and will be described in detail. It will be understood, however, that other embodiments beyond the specific embodiments described are likewise possible. All modifications, equivalents, and alternative embodiments falling within the spirit and scope of the appended claims are likewise covered.

[0015] The above discussion is not intended to represent every example embodiment or every implementation within the scope of the present or future claim set. The following figures and "Description of Preferred Embodiments" also illustrate various example embodiments. Various example embodiments may be more fully understood in view of the following detailed description in conjunction with the accompanying drawings.

[0016] According to a second aspect of the present disclosure, there is provided a digital therapeutic system, comprising: Treatment packages for patient therapy; a core package comprising a core platform, the core package adapted to configure a patient therapy; A plurality of software modules, One or more Core Modules in the Core Package, and / or a plurality of software modules, including one or more treatment modules in a treatment package; A digital therapeutic system is provided in which a core platform is configured to integrate multiple software modules such that the core package is a software separate from the therapeutic package.

[0017] The core platform may (securely) integrate multiple software modules by implementing an instrument registration and matching process, as described below in connection with Figure 4. The core platform may control communication between multiple software modules to provide software partitions.

[0018] In one or more embodiments, a computer program may be provided that, when executed on a computer, causes the computer to configure any apparatus, including the circuits, controllers, converters, or devices disclosed herein, or to perform any method disclosed herein. The computer program may be a software implementation, and the computer may be considered to be any suitable hardware, including, as non-limiting examples, implementations in digital signal processors, microcontrollers, and read-only memories (ROMs), erasable programmable read-only memories (EPROMs), or electronically erasable programmable read-only memories (EEPROMs). The software may be an assembly program.

[0019] The computer program may be provided on a computer readable medium, which may be a physical computer readable medium such as a disk or memory device, or may be embodied as a transitory signal. Such a transitory signal may be a network download, including an Internet download. One or more non-transitory computer readable storage media may be provided that store computer executable instructions that, when executed by a computing system, cause the computing system to perform any of the methods disclosed herein. [Brief description of the drawings]

[0020] One or more embodiments will now be described, by way of example only, with reference to the accompanying drawings. [Figure 1] 1 illustrates a digital therapeutic system in accordance with an embodiment of the present invention. [Diagram 2]1 illustrates another digital therapeutic system, according to an embodiment of the present invention. [Diagram 3] 1 illustrates a further digital therapeutic system, according to an embodiment of the present disclosure. [Figure 4] Illustrates a certification and contract specification process for use in a digital therapeutic system, according to an embodiment of the present disclosure. [Diagram 5] 1 illustrates an end-to-end process for user interaction with a digital therapeutic system, according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] The digital therapeutic system according to the first aspect defines a core package software separated from one or more therapy packages to configure a patient treatment regimen. The software separation of the core package from the therapy packages allows the two parts to be independently assessed for regulatory compliance. Separating the digital therapeutic system into two or more parts allows for the separation of software components or modules depending on their regulatory burden and / or expected frequency of iteration.

[0022] Software partitioning of digital therapeutics systems may include positioning components within a core package or therapeutics package depending on the expected level of regulatory scrutiny and / or frequency of updates. For example, machine learning algorithms may be subject to intense regulatory scrutiny and may result in high costs and approval delays if updated regularly (outside of pre-agreed model improvements).

[0023] A core package can be used with multiple treatment packages, such that the core package can provide common capabilities across a wide range of treatments, advantageously avoiding reevaluating the core package as new treatments are developed.

[0024] In one embodiment, the therapeutic package may include a high regulatory burden component. As described herein, the high regulatory burden component may include particularly high-risk medical device software and require regulatory scrutiny. For example, the high regulatory burden component may require one or more clinical trials and / or may not be updated without being subject to one or more further clinical trials. Stabilizing the therapeutic package allows the high burden cost to be as low as possible, ideally only once. The core package may then include components that do not undergo high regulatory scrutiny, such as non-medical components. Advantageously, some non-medical components can be rapidly iterated to the benefit of the combination (and ultimately the patient) while maintaining the use, expected efficacy, or proven safety of the DTx within acceptable limits.

[0025] In another embodiment, the core package may include a high regulatory burden component and receive regulatory approval only once or a few times. The core package may then advantageously interface with one or more new and improved therapeutic packages as they are developed without undergoing further clinical trials. The new therapeutic packages may be subject to their own independent regulatory assessment. In some embodiments, the therapeutic packages may also include a high regulatory burden component. However, the therapeutic packages may be independently assessed without requiring a complete reassessment of the core package or other approved therapeutic packages.

[0026] In further embodiments, the core package and / or the treatment package itself may be further subdivided into modules with differing requirements for regulatory scrutiny and update frequency.

[0027] FIG. 1 shows a schematic diagram of a digital therapeutic system 100 according to an embodiment of the present disclosure.

[0028] The digital therapeutic system 100 includes a core package 102 and a number of individual therapy packages 104-1, 104-2, 104-3, collectively referred to as therapy packages 104. The core package 102 is software that is partitioned (or separated) from the number of therapy packages 104. In other words, the core package 102 and the therapy packages 104 are separate, identifiable packages or blocks of code that are independently contained within the digital therapeutic system 100. In this embodiment, the core package 102 includes a therapy configurator 106. Each therapy package 104-1, 104-2, 104-3 includes a respective therapy configuration 108-1, 108-2, 108-3. The therapy configurator 106 can receive the therapy configuration 108 from each therapy package 104 and configure one or more patient therapies 111 based on the therapy configuration 108.

[0029] The digital therapeutic system 100 is subdivided into two parts: a core package 102 and one or more therapy packages 104. The two parts can communicate via an interface 117. The core package 102 can provide a set of common functionality to the one or more therapy packages 104. In this way, the core package 102 can enable different digital therapeutics to fulfill their applications. The digital therapeutic system 100 can be considered a medical device and can deliver safety-critical therapies.

[0030] By separating the treatment system 100 into two parts, the core package 102 and the one or more processing packages 104, the two parts can undergo independent regulatory assessments. The two parts can also be updated independently.

[0031] The concept of a core package 102 and separate treatment packages 104 can be likened to a handheld gaming machine, where the core package 102 represents the handheld gaming console and the treatment packages 104 represent the individual game cartridges.

[0032] The treatment package 104 may be viewed as a delivery mechanism used to make treatment software, application configurations, and related assets available to the core package 102 and the system 100 so that a particular treatment can be made available to a user.

[0033] The treatment package 104 includes: Definition of specific treatment modules required for treatment Executable code for the specific treatment modules required to deliver the treatment Treatment descriptors that define the clinical workflow and decisions that are made as part of a treatment · may include application configurations used to configure modules of the core package 102 or other parts of the system 100;

[0034] Further details regarding the components of the treatment package 104 are provided below.

[0035] The core package 102 can provide shared capabilities to the treatment package 104. These shared capabilities can include data management, prescription checking, and third party device integration. The capabilities can further include capabilities more closely related to treatment delivery, such as execution of a treatment configurator 108 by a treatment configurator 106, which will be described in more detail below.

[0036] The core package may configure one or more digital therapeutic regimens 111 by performing a number of operations associated with a treatment (as indicated by the treatment configuration). For example, the core package may acquire data, process treatment decisions, execute algorithms, notify patients or healthcare providers, perform user authentication, and monitor adherence as part of configuring one or more digital therapeutic regimens 111.

[0037] In some examples, the core package 102 may comprise a core platform having multiple core modules operating thereon. The core platform may comprise a platform application or application framework that provides a base system layer on which functionality may be provided by the core modules. Each core module may be a separate partition of software having one or more performance characteristics. These performance characteristics may include any of the module functionality provided by the module, module performance constraints required by the module of the digital therapeutic system (or other modules) to operate correctly and securely, inbound and outbound information constraints on data or information passed to and from the module, and descriptive characteristics to enable one or more other modules and / or the digital therapeutic system to determine compatibility of the module with the performance constraints of each other module or the digital therapeutic system as a whole. These performance characteristics are discussed further below in connection with Figures 3 and 4.

[0038] A core module may be a common module that provides functionality for two or more treatment packages.

[0039] The core modules may include a medical core module that provides medical device functionality for delivering a digital therapeutic. For example, a notification module may be considered a medical core module because notifying or instructing a user to perform an action, such as taking a medication or performing a therapy task, may comprise part of the treatment.

[0040] The core modules may include non-medical core modules that provide non-medical device functionality, for example, an authentication module may be considered a non-medical core module because authenticating a user account is not related to the delivery of actual therapy.

[0041] The core module may be considered a common module since it can be incorporated into many therapies via access from corresponding treatment packages. In some examples, the core module may comprise an IEC 62304 compliant software unit that can be "taken off the shelf" and included in the medical device system.

[0042] Each treatment package 104 may also include one or more modules in the form of treatment-specific treatment modules. Similar to the core module, the treatment module may also include an isolated partition of software having one or more performance characteristics. The core package 102 may execute the treatment module on the core platform.

[0043] Implementing the digital therapeutics system in a modular manner allows for independent updates and / or regulatory approval of parts of the system. That is, the platform, each core module, and each treatment package / module can be updated and / or approved independently. In this manner, the digital therapeutics system 100 can be partitioned according to regulatory burdens. Table 1 illustrates an exemplary partition of the system 100, indicating whether each partition is medical or non-medical, frequency of updates, and stability of interfaces. [Table 1] Table 1

[0044] Modular Architecture Figure 3 illustrates a digital therapeutic system according to an embodiment of the present disclosure. Features in Figure 3 that are also present in Figure 1 are given corresponding numbers in the 300 series and need not necessarily be described again here.

[0045] The digital therapeutic system 300 comprises a core package 302 and multiple therapeutic packages 304 (also referred to as therapeutic applications), each associated with a different disease / condition. The therapeutic packages 304 may comprise launchers and / or configurations.

[0046] In this example, core package 302 comprises a core platform in the form of a core application platform 340. Core platform 340 comprises a system layer 342, a platform layer 344, and a platform interface 345. Core package 302 further comprises a number of core modules 346 (also referred to as application modules).

[0047] The core module 346 (and any treatment modules in the treatment package 304) encapsulates a specific functionality of the system 300. Each module (or software unit) may be considered an independent or isolated piece of software code with clearly defined boundaries. As described below, a module may have one or more performance characteristics. In this manner, a module may have an associated risk profile and may be considered an atom for the purposes of classifying a medical device.

[0048] Platform interface 345 provides each module with a way to access the functionality of platform layer 344 and communicate with other modules. For many of the modules, direct communication between modules may be prevented and modules may only communicate with each other via core platform 340 and / or platform layer 344. For some modules, direct inter-module communication may be prevented only until the module registration process, as discussed below in connection with FIG.

[0049] The platform layer 344 manages communication between modules and may invoke module functionality through registered module interfaces 348. The platform layer 344 may also invoke elements of the system layer 342 to provide certain core capabilities. The system layer 342 may provide functionality of the core packages 302 that is not and does not have direct access to other parts of the application.

[0050] Each module may include a module interface 348. The module interface 348 may provide a way for the core platform 340 to interact with the respective module (e.g., via one or more callbacks). Each module may register the module interface 348 with the core platform 340 / core package 302. In this manner, each module may inform the core package 302 of its performance characteristics, i.e., the functionality provided, as well as any associated constraints.

[0051] Module interfaces 348 may include imported and exported instruments. An instrument may comprise a software artifact that can perform an action or generate data related to a single defined task. The interaction of functionality within a module with functionality outside the module may include: Exported instruments, including services and data that the module can provide to other parts of the digital therapeutic system 300; and Modules may be implemented through imported instruments that indicate the services and data they require from other parts of the digital therapeutic system 300.

[0052] The platform layer 344 may assess the exported instrumentation of a particular module for suitability for use with other modules, such as the availability of integration or contract testing results or other risk-related information. The exported instrumentation may include at least a portion of the performance characteristics of the module. In this manner, the platform layer 344 may be configured to impose one or more constraints on interactions between modules based on module performance characteristics, such as module functionality, performance constraints, and input / output requirements.

[0053] The module interface 348 may be associated with a set of limitations or constraints on the imported instruments based on the module performance characteristics. In other words, each module includes an allowable instrument policy to ensure that the imported instruments meet the module's constraints. In this manner, the module interface may be configured to impose one or more constraints on information or calls received from the rest of the system 300.

[0054] In addition, the platform may certify the imported instrument as suitable for import, meaning that the imported instrument meets the contract specification of the importing module. The contract specification defines how the imported instrument will be used and may impose request / response or message level constraints to ensure that the imported instrument behaves in a manner that meets the needs of the module. The contract specification may include or be based on one or more module performance characteristics. Example constraints include "metadata x must be returned with each blood pressure measurement" or "information about errors must be in format y."

[0055] Figure 4 illustrates a module registration process for a digital therapeutic system, according to an embodiment of the present disclosure. Features in Figure 4 that are also present in Figure 1 or Figure 3 are given corresponding numbers in the 400 series and need not necessarily be described again here.

[0056] The diagram illustrates the registration of an instrument of a first module 426 with the core platform 440 and the subsequent discovery of the instrument by a second module 446. As an example, the first module 426 may correspond to a therapy-specific module associated with a therapy package, and the second module 446 may correspond to a core module. Registration of a therapy-specific module may occur when a corresponding therapy package is installed or updated in the therapy system. However, the following process may relate to any module of a therapy system.

[0057] In a first step, the first module 426 may register one or more exported instruments (including one or more performance characteristics) with the core platform 440. The core platform 440 may register the exported instruments (or provided instruments) with the platform registry 441. In this way, the first module may register interface definitions, characteristics, constraints, and attributes. The exported instruments define the services and data that the module can provide to other parts of the digital therapeutic system. In an example of a therapy-specific module, the first module may register one or more exported instruments, for example, a calculated daily dosage regimen associated with a therapy.

[0058] In a second step, the second module 446 sends an appliance request to the core platform 440 in an attempt to discover appliances that meet the contract specifications 443 associated with the second module 446. The second module 446 may send or register the contract specifications to the core platform 440 as part of this process. In an embodiment where the second module is a notification module, the module may require a calculated daily dosage regimen provided by the treatment specific module 426 as an exported appliance. The core platform 440 may store or register the appliance request in the resolver 447. Although the first two steps are described as two distinct steps, in other embodiments, a module may discover appliances registered by other modules based on its module performance characteristics (proposed functionality and constraints) while simultaneously registering its exported appliances.

[0059] In a third step, the resolver 447 may communicate (or query) with the registry 441 to compare the offered instrument of the first module 426 (or any other module with registered instruments) with the instrument request of the second module 446. In a fourth step, the resolver may check the offered instrument of the first module 426 against the contract specification 443 of the second module 446. If the resolver determines that the instrument of the first module 426 meets the contract specification 443 of the second module 446, the resolver may provide details of the instrument to the second module 446.

[0060] The resolver 447 may provide the second module 446 with details of the first module 426's appliances in the form of reference information to enable communication. In this manner, the resolver provides the second module 446 with a reference interface for communicating with the first module 426. In some embodiments, the reference interface may correspond to direct communication between the first module 426 and the second module 446, in the form of references to objects that can be invoked, in memory. In other embodiments, the reference interface may correspond to an intermediate communication, such as through the core platform 440.

[0061] The module registration process of FIG. 4 and the subsequent establishment of reference interfaces can define the software partition between the core package and the therapy packages of the digital therapeutic system.

[0062] The modular structure of the digital therapeutics system outlined in Figures 3 and 4, including the platform, modules and associated instrument definitions, import policies, and certifications, can provide and enforce independence between modules. This, in turn, allows for independent variation of portions of the system 300 without requiring regulatory reapproval of the entire system 300. Elements of the system 300 can be integrated or combined to deliver therapy while allowing separation between medical / non-medical functions and independent variation of these elements.

[0063] Returning to FIG. 1 , the core package 102 may include multiple core modules, including a therapy configurator 106. The core package 102 may acquire or receive patient data 115, which may be acquired via the core platform and / or via one or more core modules and / or therapy specific modules. The patient data 115 may include biometric data, behavioral data, prescription data, physiological data such as physiological measurement data, medical record data, desired patient outcome data, patient feedback data, or any other relevant patient data. The patient data 115 may be acquired via one or more of patient input, readings from associated devices, and patient data collected from local or networked databases. Here, the term associated device may include any device that provides data, for example, regulated medical devices (e.g., glucose monitoring devices) or non-medical devices such as fitness trackers, smart watches, and similar devices known in the art. The core package 102 may be configured to acquire other relevant non-patient data, such as environmental data or regulatory data, for example, drug data or drug interaction data.

[0064] The therapy configurator 106 can receive therapy configurations 108 from each therapy package 104 and configure one or more digital therapeutics 111 associated with the therapy package 104. The one or more digital therapeutics 111 can include recommended dosages of pharmacological therapies, such as drugs. The pharmacological therapies can include drugs already prescribed to the patient. Additionally or alternatively, the one or more digital therapeutics 111 can include medical device instructions or non-pharmacological therapies, such as cognitive behavioral therapy. The core package 102 or a therapy-specific module can communicate the medical device instructions to the patient and / or an associated medical device. The non-pharmacological therapies can include therapies already prescribed to the patient.

[0065] The therapy configuration 108 may include an application configuration that may indicate a list of core modules required to deliver the respective therapy. The therapy configurator 106 may receive the application configuration and register the core modules required for that therapy. The therapy configurator 106 may include a therapy installer 107 for installing the therapy packages 104 on the core platform according to the application configuration. The application configuration is described in further detail below in connection with FIG. 2.

[0066] The therapy configuration 108 may include a therapy descriptor that includes therapy instructions in a computer-readable format. The therapy instructions may include a set of therapy decisions. The therapy decisions may include one or more clinical (or clinically significant) decisions. The therapy configurator 106 may include a therapy engine 109 for processing or executing the therapy decisions. In some embodiments, the therapy configurator 106 is a separate core module that includes the functionality of the therapy engine 109 and the therapy installer 107. In other embodiments, the therapy configurator 106 may include two separate core modules, the therapy engine 109 and the therapy installer 107. In embodiments where the digital therapy system includes only a single therapy package 104, the therapy engine 109 may be included as part of the therapy package 104.

[0067] The treatment instructions may also indicate patient data 115 and / or non-patient data to be acquired by the core package 102, the core module, and / or the treatment specific modules that suggest appropriate appliances. The prescribed data may be required to process one or more treatment decisions. The core package 102 may acquire the patient data 115 based on the treatment instructions in the treatment descriptor 108. In this manner, the treatment configuration 108 may include treatment instructions indicating the patient data 115 necessary to configure one or more digital therapeutics 111.

[0068] An exemplary clinical treatment decision is determining the appropriate dose of a medication for a patient, which may be based on biometric data collected over the previous week.

[0069] The therapy configuration 108 can describe the data and therapy decisions necessary to deliver one or more digital therapeutics 111 to a patient. As a result, the therapy configuration 108 can be subject to a high degree of regulatory scrutiny.

[0070] In some embodiments, the therapy engine 109 may process therapy decisions using one or more algorithms. The one or more algorithms may include rule-based algorithms and / or machine learning algorithms. The algorithms may be stored locally to the core package 102 or in a memory separate from the core package 102.

[0071] In some embodiments, one or more algorithms are associated with the core package 102. For example, one or more algorithms may be associated with the therapy configurator 106, particularly the therapy engine 109, or one or more other core modules. In this manner, the algorithms will be subject to regulatory approval when the core package 102 and / or associated core modules are subject to regulatory approval. The therapy package 104 may use these approved algorithms without the algorithms being subject to reapproval when the therapy package 104 is subject to regulatory approval. Algorithms, particularly machine learning algorithms, may impose a high burden on regulatory approval. By including an algorithm in the core package 102 that is common to multiple therapy packages 104, the algorithm may require regulatory approval only once or a few times. New approved therapy packages 104 may be advantageously added or updated without requiring reapproval of the core package 102, the core modules, or the corresponding algorithms. The therapy package 104 may also include high regulatory burden functionality, including algorithms. The therapy package 104 may include such functionality within a therapy module that may be independently assessed by a regulator. In this manner, treatment packages 104 and / or treatment modules may be independently assessed without requiring reassessment of the core package 102 or other approved treatment packages 104 .

[0072] To enable independent approval of the algorithm within the treatment configurator 106, the treatment configurator 106 may include a safety module 113 for applying one or more safeguards to the digital therapeutic 111. The safety module may include one or more inherent safeguards and / or one or more inputs for receiving safeguards.

[0073] As an example of an inherent safeguard, the safety module 113 may impose a rule that a drug dosage cannot exceed a toxic dose for the patient. To enable this, the safety module 113 may include or have access to a drug database that contains a list of known drugs, drug interactions, safe dosage ranges, and other regulatory criteria. The drug database may be periodically updated to ensure continued regulatory compliance. When the therapy engine 109 of the therapy configuration 106 processes a therapy decision based on a therapy order from the therapy configuration 108, the safety module 113 may check any calculated drug dosage that may form part of the digital therapeutic 111 against the drug database. In this way, the safety module 113 may ensure that any calculated drug dosage is within recommended safety limits. The safety module 113 may check the calculated dosage against a particular entry in the drug database based on one or more parameters of the drug and patient data 115 (e.g., age, sex, ethnicity, comorbidities, other medications, etc.).

[0074] The safety module 113 may also include inputs for receiving safeguards from other components. For example, the safety module 113 may receive a specific treatment safeguard from the treatment configuration 108 (e.g., from a treatment descriptor or application configuration) or from a treatment module. In this manner, the treatment configuration 108 may declare one or more safeguards for the treatment configurator 106 to implement. The safety module 113 of the treatment configurator 106 may interpret the safeguards in the treatment configuration 108 and implement the safeguards on the digital therapeutic 111. The treatment configuration 108 may extend the inherent safeguards of the safety module 113 to consider safety scenarios that may only exist within the context of a particular treatment. For example, a treatment package may include prescribed medications and may include safeguards avoiding doses of other medications known to cause adverse events when combined with the prescribed medication.

[0075] The safety module 113 may apply one or more safeguards to limit or disable the functionality of a particular therapy (or therapies).

[0076] In one or more embodiments, one or more modules may include safeguards in their contract specifications. For example, the safety module 113, the therapy configurator 106, the therapy engine 109, or one or more therapy-specific modules may include a module contract specification that includes one or more safeguards.

[0077] In some embodiments, one or more algorithms for processing a treatment decision may be associated with a treatment package 104, for example, in a treatment module. In this manner, a particular treatment algorithm may be provided to the treatment configurator 106 for processing. In some embodiments, the treatment engine 109 may execute the treatment decision. In other embodiments, an associated treatment module may execute code and communicate associated data to the treatment configurator 106. A particular treatment algorithm may undergo regulatory approval along with the treatment package 104 and / or treatment module. Such an approach may allow new algorithms to be provided to the treatment configurator 106 while maintaining the regulatory independence of the core package 102, the core module, the treatment package 104, and the treatment module. In such embodiments, the safety module 113 may operate as described above for algorithms associated with the treatment configurator 106.

[0078] Each of the one or more treatment packages 104 may be suitable for treating a respective disease or condition. The treatment configuration 108 may provide treatment instructions to the treatment configurator 106 related to treatment decisions and / or acquisition of patient data 115 to configure one or more digital therapeutics 111 for treating the disease or condition.

[0079] The disease or condition may be pre-diabetes, diabetes, cardiovascular disease, neurodegenerative diseases such as mild cognitive impairment (MCI), Alzheimer's disease and Parkinson's disease, atrial fibrillation, attention deficit hyperactivity disorder (ADHD), autoimmune diseases such as ulcerative colitis, lupus erythematosus, Crohn's disease, celiac disease, Hashimoto's thyroiditis, bipolar disorder, cerebral palsy such as movement disorders and athetosis, chronic graft versus host disease, hepatitis, chronic kidney disease, arthritis and chronic bone and joint diseases such as osteoarthritis and rheumatoid arthritis, cancer, obesity, asthma, sinusitis, Cystic fibrosis, tuberculosis, chronic obstructive airways disease, bronchitis, bronchiolitis, pulmonary fibrosis, pain including chronic pain syndromes, depression, eating disorders, polycystic ovary syndrome, epilepsy, fibromyalgia, viral diseases such as HIV / AIDS, Huntington's disease, hypotension, hypertension, allergic rhinitis, multiple sclerosis, fatigue conditions including chronic fatigue syndrome, insomnia, narcolepsy, osteoporosis, periodontal disease, postural orthostatic tachycardia syndrome, sickle cell anemia and other hemoglobin disorders, sleep apnea, thyroid disease, reflux disease including gastroesophageal reflux disease, vomiting, irritable bowel syndrome (IBS), inflammatory bowel disease (IBD), peptic ulcers, acute urticaria, atopic dermatitis, contact dermatitis, seborrheic dermatitis, headaches such as migraine, cluster headaches, tension headaches, drug addiction, particularly opiate addiction, cocaine, alcohol or nicotine addiction and chronic use thereof, thromboembolic diseases, hair loss, hormone replacement therapy, psychiatric disorders such as psychosis, anxiety, depression, growth hormone deficiency, thyroid function hematological disorders including clotting factor deficiencies or low levels of white or red blood cells; neurodevelopmental delay (NDD) disorders including Autism Spectrum Disorder (ASD), Smith-Magenis Syndrome and ADHD; parasomnias including REM and NREM parasomnias and nightmare disorder; sleep movement disorders such as restless legs syndrome and periodic limb movement disorder; circadian rhythm disorders (including disorders caused by shift work and / or jet lag); chorea and tic disorders.

[0080] Figure 2 illustrates a schematic diagram of a digital therapeutic system 200, according to an embodiment of the present disclosure. Features in Figure 2 that are present in Figure 1 have been given corresponding numbers in the 200 series and will not necessarily be described again here.

[0081] System Architecture The digital therapeutic system 200 comprises software processes that run within one or more mobile applications 210 on a mobile platform 201 (Android, iOS, etc.) and as backend services on a cloud platform 203. The system 200 employs the modular architecture discussed above in connection with FIG.

[0082] In this example, the core package 202 comprises a mobile application, or mobile app 210 (which may also be referred to as a platform application). The mobile app 210 comprises a number of core modules of the core package 202 in the form of a core client module 246. The core package 202 further comprises a core backend module 212. In some examples, the core backend module 212 may be included in the mobile app 210.

[0083] The mobile app 210 may be made available to patients and installed through official distribution channels such as app stores, etc. The mobile app 210 may be installed on a wide range of local personal devices such as personal computers, mobile communication devices such as tablets, smartphones, smart watches, or other devices known in the art.

[0084] The mobile app 210 can host one or more treatment packages 204. The mobile app 210 can act as a primary user interface for treatment delivery. As mentioned above, the core package 202 can provide core modules 246 as shared capabilities to each of the treatment packages 204. These shared capabilities can include performing treatment configuration, data management, user account management, prescription checking, and third party device integration.

[0085] In some examples, the treatment packages 204 may be included (and integrated) in the mobile app 210 when installed by the patient. Access to the individual treatment packages 204 may then be unlocked accordingly. In other examples, the treatment packages 204 may be downloaded separately and integrated with the mobile app 210, or installed as separate mobile applications on the mobile platform 201. Thus, the digital therapeutic system 200 may offer one or more treatments to the user, ranging from a mobile app 210 dedicated to one treatment that cannot be modified, to a treatment store arrangement where the user or clinician can select or unlock a wide range of treatments via the mobile app 210.

[0086] The backend modules hosted on the cloud platform 203 may comprise backend services. In this example, the core package 202 and each treatment package 204 have their own respective backend services (core backend module 212 and treatment-specific backend module 214). The backend services hosted on the cloud platform 203 may also comprise support systems 216. The support systems may be non-SAMD modules. The backend services may provide support infrastructure for treatments such as long-term data storage or behavior monitoring. The mobile app 210 may communicate with the backend servers via a communication network such as the Internet or a cellular network. The backend services may constitute the "server" portion of a client-server architecture configuration.

[0087] The core backend module 212 may comprise web services that provide shared capabilities to the digital therapeutic system 200. The core backend module 212 may comprise common modules that can be called by web service clients running in the core client module 246 of the core package 202 or one or more of the therapeutic modules 226 of the therapeutic package 204. The core backend module 212 may provide server-based capabilities that apply across all therapeutics, such as data management and integration with broader systems.

[0088] The treatment packages 204 can each include treatment-specific backend modules 214 for aspects of the digital therapy provided by the treatment package 204 that may need to run on a backend server. Examples of treatment-specific backend services 214 include services that can be used to query video content (hosted and accessed via cloud services) or machine learning models that are too computationally intensive to run on a local personal device.

[0089] The support systems 216 can provide a set of supplemental functionality to the digital therapeutic system 200. Those skilled in the art will appreciate that a digital therapeutic system may include any, all, or none of the modules or components of the support systems.

[0090] The core module 246 and the therapy module may interface with any of the support systems 216 through a system integration module 266, which is a core platform and core backend module 266. Further details regarding each of the support systems 216 are provided below.

[0091] Installing the treatment package Installation of the therapy package 204 can be static or dynamic, i.e., the therapy package 204 can be installed at build time to create a completely self-contained executable binary, or can be installed at run time where the therapy package 204 is downloaded and dynamically integrated into the mobile application 210.

[0092] As described above in connection with FIG. 1, each treatment package 204 comprises a treatment configuration 208, which may include an application configuration 218 and a treatment descriptor 219.

[0093] The application configuration instructions (app configuration) 218 ​​can describe how the mobile application 210 or the core package 202 is configured to support a therapy or one or more digital therapeutics. The installation of the app configuration 218 can occur during installation of the therapy package 204. The core package 202 can read the app configuration 218 from the therapy package 204 and register the app configuration 218 with one or more core modules 246 of the core platform 202. At runtime, the one or more core modules 246 can read the app configuration 218 and update their state and behavior accordingly.

[0094] App configuration 218 is the core modules (and any treatment modules) required to deliver the treatment, and an indication of whether the modules provide any medical device or non-medical device functionality; and / or May contain instructions that define the module's behavior, appearance and personalization (for example, setting the type of notifications that should be generated each day).

[0095] For example, the app configuration 218 may configure the notification module 228 of the core package 202 to generate daily reminders for the patient to take their medication (as such, the notification module is a core medical module). The app configuration 218 may allow the patient to select a specific reminder time from a predefined range of values. In further examples, the app configuration 218 may determine the availability of a feedback form depending on the context in which the digital therapeutic is delivered.

[0096] As mentioned above, the treatment descriptor 219 may contain treatment instructions and an indication of the data required for each treatment package 204. The treatment descriptor 219 crosses the interface 217 from the treatment package 204 to the core package 202 by i) being registered as a treatment that must be performed by the treatment engine module 209, and ii) being digitally read by the treatment engine 209 at run-time. The treatment engine 209 can interpret the instructions in the treatment descriptor 219 and deliver the treatment.

[0097] The therapy package 204 may also include one or more custom therapy modules 226. The therapy modules 226 may include medical device compliance software developed to meet the use of the therapy package 204. The one or more therapy modules 226 may be installed through static linking (for build-time installation of the therapy package 204) or dynamic linking (for run-time installation of the therapy package 204). In this manner, the core platform of the core package 202 (or another therapy-specific module 226) may invoke one or more therapy modules 226 as needed. Instructions describing when a component of the core package 202, such as the therapy engine 209, should invoke the custom therapy module 226 may be provided or indicated by the application configuration 218 or therapy descriptor 219.

[0098] In one embodiment, the custom module 226 is a machine learning model and supporting algorithms that can classify patients according to their responses to a series of questions.

[0099] Each treatment module 226 may define one or more requirements. The core package 202 (e.g., core platform) may ensure that these requirements are met during installation of the treatment package 204 or during subsequent processing of the treatment package 204. The one or more requirements may include: Minimum required platform version, Required hardware versions and / or features; and · May include any additional system configuration required by the module.

[0100] Additionally, each exported instrument that may be output by the treatment module 226 may include information based on the module performance requirements. For example, the exported instrument may include: -Description of the equipment, Identifiers of exported instruments (in some embodiments, different modules may export instruments with the same identifier, allowing searching and matching of instruments); Data provided by exported instruments, action specifications, and other metadata used to perform instrument qualification; and · It may contain one or more representative use cases (such as test specifications and automated test cases).

[0101] The treatment module 226 may impose input constraints on each imported instrument based on the module performance requirements. Identification of the required equipment, · Acceptable equipment policies that must be met; and · A specification of required actions and data (contract specification).

[0102] The platform requirements, acceptable policies, and contract specifications of the therapy module 226 form an overall specification of required operating parameters. The core package 202 and / or therapy module can ensure compliance with the specifications to allow the therapy module 226 to be securely integrated into the digital therapy system 200.

[0103] The core package 202 and / or the treatment module 226 may include: the core package 202 or core platform on which the treatment module 226 runs is a valid version and configured according to the requirements of the treatment module 226; The hardware complies with version and feature set requirements, and · It may check that imported equipment required by the treatment module 226 exists, meets import policies, and can be certified against the treatment module's contract specifications.

[0104] The requirements of the custom treatment module 226 and associated instruments, and the monitoring of their compliance by the core package 202, provide and implement the modular separation described above in connection with FIG. 3. This then allows for partitioning of the digital treatment system 200, allowing the treatment packages and / or treatment modules to be updated and / or receive regulatory approval independently. Those skilled in the art will appreciate that in some embodiments, the requirements and compliance monitoring outlined herein in connection with the treatment module 226 may be equally applicable to any of the core modules 246. This then allows for independent updates and regulatory approval of either the core module 246 or the core platform, as shown above in connection with Table 1.

[0105] The digital therapeutic system 200 can personalize the digital therapeutic for the user during installation and can be further personalized during therapy delivery. Personalization can be divided into clinical and non-clinical, the former being adjustments to the therapy and the latter being adjustments to encourage adherence to the therapy.

[0106] For example, the system 200 may provide initial clinical personalization by setting a patient's starting dose based on the patient's age and weight. The system 200 may provide initial non-clinical personalization by setting the tone of voice used in notification messages based on the user's answers to onboarding questions.

[0107] The treatment package 204 includes: · app configuration 218 instructions that the core package 202 can use to direct one or more core modules 246 required for a treatment; Treatment instructions in the treatment descriptor 219 that can be executed by the treatment engine 209; A treatment module 226 that initiates a unique personalization process; and Personalization may be initiated by providing personalization settings via any of the specific non-therapy personalization modules 222.

[0108] Personalization can be based on patient data obtained by the core package, for example, user-entered data or data from other sources such as an electronic health record (EHR).

[0109] The non-treatment personalization module 222 may include further configuration instructions for personalizing the delivery of the treatment for the patient (as opposed to personalizing the treatment itself). These instructions are a type of application configuration focused on optimizing non-clinical elements of the treatment, such as improving patient adherence to the treatment regimen. In some examples, the personalization settings 222 may include a set of default personalization settings 222 when the treatment package is first installed. The personalization settings 222 may be configured to automatically adapt based on patient behavior and / or may be configured for adjustment by the patient.

[0110] An example of a non-therapy personalization setting 222 may be to suggest or select a new notification time based on patient behavior or engagement. The notification module 228 may receive settings from a therapy package for personalizing the notification time. The therapy package 204 may include many other personalization settings 222 based on the capabilities of the core package 202 and / or therapy specific modules 226.

[0111] The core package 202 may propose a standard UI architecture with a core module 246 that includes standard UI displays, standard branding assets 230, standard pages 232, and standard navigation mechanisms shared across one or more treatment packages 204. For example, the UI assets 220 of an individual treatment package 204 may augment the standard UI architecture with one or more customized color schemes, branding, layouts, navigation structures, formatting configurations, UI displays, or other UI assets.

[0112] The UI assets 220 may be integrated into the mobile application 210 during installation of the treatment package. The core package 202 may then read the UI assets 220 at run time and render the UI. An example of a custom UI asset 220 is a visual widget for measuring a patient's visual response to collect treatment-specific biometrics related to the patient's cognitive function. The custom visual widget will form part of the treatment package 204.

[0113] In some cases, integration of the new screen may require low-level integration with, for example, a third-party user interface framework used by the platform.

[0114] The treatment package 204 may include media content 224 for delivery before, during, or after the digital therapy. The media content 224 may include rich text, audio, video, or other typical media. The media content 224 may be clinically significant, such as training videos for using a biometric device, digital CBT lessons, or patient information sheets.

[0115] The treatment package 204 may store the media content 224 locally on the mobile platform 201 or remotely on the cloud platform 203 as a processing backend service 214. During installation of the treatment package 204, the media content 224 may be extracted to either local or networked storage accessible to the core package 202. Alternatively, or in addition, the networked location of any remotely stored media content 224 may be registered with a suitable core module 246 (e.g., content manager 234) in the core package 202. The media content 224 may then be retrieved or streamed when accessed by the patient. The core package 202 may make the media content 224 available to the patient using mechanisms such as lesson lists or prompts to display content during patient onboarding.

[0116] Core Module 246, 212 In this embodiment, the core package 202 comprises a core platform (not illustrated) and the following core modules 246 that operate on the core platform: Core Client Module 246 · An application framework 250 may provide a standard application user interface for hosting therapies. The application framework may provide application navigation, splash screens, and similar application features shared across all therapy packages. · Standard Pages Module 232 may include standard UI screens shared across treatment packages 204, such as a treatment dashboard screen showing available treatments, and a task screen that shows a consolidated view of the current tasks the user is performing. The branding assets module 230 may provide digital assets for display to the user. A default set of assets may be provided. A particular treatment package 204 may override some or all of the branding assets (or other similar UI assets that make up the application's theme). The content manager module 234 may be responsible for providing access to content required as part of a treatment, as described above in relation to the media content of the treatment package 204. The content may be local to the core package 202, may form part of the media content 224 of the treatment package 204, and / or may be accessed via the backend services 212, 214. The feature manager module 252 can enable or disable application features. The core package 202 can use the feature manager module 252 to allow for treatments to be delivered in either clinical trial or real-world settings. The feature manager module 252 can also allow for live adjustment of application features in A / B settings (if the adjustment is acceptable in the context, e.g., to account for randomization in a clinical trial). The therapy installer 207 may form part of the therapy configurator 206, as discussed above in relation to Figure 1. The therapy installer 207 may be responsible for downloading and installing therapy packages 204. The therapy installer may also detect required therapy updates and may lock a therapy if the therapy is discontinued. The therapy engine 209 may form part of the therapy configurator 206, as discussed above in relation to Figure 1. The therapy engine 209 may provide an execution environment and engine for the therapy package 204, including the therapy descriptors 219 and the therapy modules 226. The therapy engine 209 may take the form of a virtual machine sandbox environment for executing the therapy process. The authentication module 254 can integrate the mobile application 210 with standard authentication providers. This can include third-party API integration as well as user interface elements. The authentication module 254 can communicate with a user profile module 268 in a supporting system via a system integration module 266. A prescription checker module 256 can manage user access to the treatment package 204. The prescription checker module 256 can ensure that a user has an associated prescription or has purchased an associated treatment over the counter (OTC) before allowing access to the treatment package 204. The prescription checker module 256 can communicate with a prescription management module 272 in the support system 216 via a system integration module. The notification module 228 can manage aspects of the mobile application 210 related to notifications, such as registering specific notification needs, enabling / disabling notifications, or aggregating notifications to avoid user overload. The notification module can provide medical device functionality by instructing the patient to perform therapy tasks. The therapy data store module 236 can store therapy or patient data on the client device, including any of the following: user-entered data, readings from connected devices, and data retrieved from back-end services such as electronic health records. The therapy data store module 236 can also manage access to data stored for the core package 202, the core platform, other core modules 246, therapy packages 204, or therapy modules. The therapy data store module 236 can also integrate with the therapy data replica module 262 for backup / recovery purposes. The therapy data store module 236 can also enforce information governance policies. A device integration module 258 can integrate the digital therapeutic system with connected devices. The device integration module 258 can receive data from connected devices for use in the therapy, for example, in processing therapy decisions. In some embodiments, the device integration module can instruct connected devices to deliver therapy as part of the therapy. The error handler module 260 may log and send error information to a backend core module 212, such as a treatment monitoring module 264, or to a support system 216, such as a patient support module 276, for diagnosis and support.

[0117] Backend Core Module 214 The Treatment Data Replica module 262 includes services for replicating data captured in the mobile application 210, where appropriate, to ensure it is available for backup and recovery purposes (to ensure continuity of treatment) and for clinical use. The treatment monitoring module 264 comprises a server-side module for detecting problems in treatment, such as incompatibilities or failure to transmit data for backup. A system integration module 266 can provide a set of server-side integrations with the support systems 216 .

[0118] Support System 216 The support systems 216 can provide a set of supplemental functionality to the digital therapeutic system 200. Those skilled in the art will appreciate that a digital therapeutic system may include any, all, or none of the modules or components of the support systems.

[0119] In this embodiment, the support system 216 includes: · A user profile module 268 that may provide user authentication services to the mobile application 210. The user profile module may enable registration, authentication, profile lookup, and other general user profile management capabilities. A patient data module 270 with backend services and a user interface for managing access to patient data stored in the electronic health record system. The EHR may be provided externally or may form part of the patient health record module 274. The patient data module 270 may control access to patient data based on information governance policies. The prescription management module 272 can manage user access to treatment packages. The prescription management module 272 can integrate with external provider systems provided by the healthcare intermediary and use the resulting information to provide access control information to the mobile application 210. The patient records module 274 comprises a data repository of patient health records relating to a user. The health records may include those generated by the mobile application 210 as well as data retrieved from third party EHR systems. Records in the repository may be retrieved for use by the mobile application 210 for treatment, presented to clinicians (in a controlled manner, such as via the patient data module 270), or submitted for storage in a third party system. A patient support module 276 may provide support to the patient during treatment, for example, by reporting treatment status, adverse events, or other similar clinical information. The patient support module may be used by clinical staff to provide treatment support. The analytics module 278 can capture patient application usage data to support product development. The captured data can be anonymized and can include time spent on application screens, user actions, and similar data. Therapy Operations Module 280 may enable remote access for operational support to perform routine operational activities related to patient treatment, such as handling technical issues or non-clinical application usage issues. The clinical trial data store module 282 may provide a system for storing data captured during a clinical trial.

[0120] Delivery of treatment Following installation of the treatment package 204, the core package 202 can deliver the respective treatment. The treatment package 204 and the core package 202 can interact to deliver the treatment.

[0121] Data capture The core platform may configure one or more of the core modules 264 to capture the data. In some examples, the core platform may receive instructions to configure the core modules 264 via the application configuration 219 (in the treatment package 204). In other examples, the core platform may receive instructions from the treatment engine 209 when it determines that certain data is needed to execute the treatment descriptor 219. Thus, the treatment descriptor 219 itself may indicate the data needed to deliver the respective treatment.

[0122] As mentioned above, data may be captured using screen-based user input, such as a daily medication log, from an EHR, such as the patient's height or weight, or from attached (medical) devices, such as a blood pressure monitor, among other potential sources.

[0123] In some implementations where the core package 202 hosts multiple therapy packages 204, the core package 202 may consolidate the data capture requirements of the multiple therapy packages 204. For example, a core module, such as the therapy configurator 206 or the notification module 228, or a core platform, may determine that two therapy packages 202 require the same patient data, such as a blood pressure measurement. In response, the core platform may instruct the device integration module 258 to request a single data entry. The core platform may then communicate the resulting data entry to the therapy configurator 206 or associated therapy module 226 for use by both therapy packages 204.

[0124] Treatment decision In some embodiments, the therapy engine 209 may execute one or more therapy decisions by interpreting or otherwise executing the therapy descriptor 219. The therapy descriptor may include therapy instructions that describe the clinically significant and safety critical therapy decisions required to deliver the respective therapy. In other embodiments, the therapy engine 209 may be omitted or not used. One or more core medical modules or therapy modules may also execute the therapy decisions.

[0125] The therapy engine 209 can receive the therapy descriptor 219 and determine any data necessary to process a therapy decision. The therapy engine 209 can communicate with one or more core modules 246 (e.g., device integration module 258) (and / or therapy module 226) to obtain the necessary data. As outlined above, the app configuration 218 can configure the core module 246 (and / or therapy module 226) to obtain the data. The therapy engine 209 can then receive the obtained data, execute a therapy decision, determine one or more clinical conclusions, and provide corresponding results.

[0126] The therapy engine 209 may process therapy decisions and provide results at specific times or time intervals, for example, once a day. The therapy engine 209 may also process therapy decisions and provide results in response to one or more activities or events, such as an unexpected change in a biometric reading, such as blood pressure.

[0127] Personalization (in progress) As outlined above, the digital therapeutic system 200 may perform ongoing personalization for the user's therapy and application experience. The system 200 may adapt the personalization in response to newly collected data. Any component of the system 200 may be responsible for the personalization, for example, the therapy package 204 may perform the personalization and / or provide instructions to the core package 202 to perform the personalization. As an example, the system 200 may reduce the dosage of a drug in response to the severity of a patient-reported symptom. In another example, the notification module may modify the tone of voice used in therapy messages based on the observed level of adherence. The therapy personalization may be initiated according to instructions in the therapy descriptor 219 or by the core module or therapy module that delivers the therapy or patient experience. In some examples, the core package may provide continuity of user personalization from a first therapy package to subsequent therapy packages.

[0128] Treatment interactions The core package 202 may simultaneously host multiple therapy packages 204, thereby proposing multiple therapies to the patient simultaneously. The therapy configurations 206, e.g., therapy descriptors 219, may include interaction instructions designed to describe therapy interactions. The therapy interactions may include drug interactions, where the interaction instructions may indicate a lower dosage of a first drug if the patient is taking a certain other drug. The therapy configurator 206 or therapy engine 209 may read the interaction instructions from each therapy configuration 208 of the therapy packages 204 and determine one or more therapy interactions. The therapy configurator 206 may then set guardrails in a safety module (see FIG. 1) based on the interaction instructions. For example, the guardrails may ensure that an appropriate lower dose is indicated to the patient for a drug interaction.

[0129] In some examples, the core package 202 may run different instances of the treatment configurator 206, one for each treatment package 204. Each instance of the treatment configurator 206 may read and execute the treatment configurations 208 from a respective treatment package 204. The multiple instances of the treatment configurator 206 may then communicate with each other to exchange and determine interaction instructions.

[0130] Treatment Lifecycle Management The digital therapeutic system 200 can continually manage the installed treatment packages 204. For example, the digital therapeutic system 200 can update, lock, or discontinue a treatment.

[0131] update New versions of the treatment package may be released as a result of (for example) new clinical evidence, user interface enhancements, new product features, and / or changes to the capabilities of the shared core package 202.

[0132] Independent updating and regulatory approval of different elements of the digital therapeutic system 200 is a key advantage of the disclosed partitioned system. The system 200 can update various components and modules (see FIG. 3 and Table 1) independently of each other, as follows: Treatment Package 204 - As an example, the digital therapeutic system 200 may download an updated treatment package with a modified treatment configuration 206 with improved performance or a new version of a treatment specific module 226. Core (common) modules 246 - As an example, the digital therapeutic system 200 may download new versions of core modules used in some therapeutic packages, or download entirely new core modules that introduce new functionality. The core modules 246 may be core medical modules or core non-medical modules. Platform and System Layers - The digital therapeutic system 200 may update either the platform layer or the system layer to provide new or expanded capabilities. The two layers may be updated together or separately.

[0133] The digital therapeutic system 200 may only process updates to components that follow one or more operational checks to ensure that the safety and integrity of any therapy delivered is maintained. The system 200 may perform one or more of the following operational checks: · Version compatibility checking between Therapy Packages 204, modules (core and Therapy) and other software elements (platform and system layers). Imported instruments meet certification requirements and acceptable device policies. For example, a new version of a module may no longer meet the acceptable device policies of a second module that uses it. In such instances, the system 200 may reject the update or suspend the associated treatment package 204. Satisfying system-level constraints on module and platform configurations to ensure that the overall configuration is acceptable from a risk and regulatory perspective. Such constraints may include ensuring that the configuration is pre-approved from a risk management perspective, or checking that the memory footprint of the module combination is within the tolerances for each particular module.

[0134] It will be appreciated that one or more of the core modules (eg, the treatment installer 207, the feature manager 252), the platform layer, and / or the system layer may perform the updates and operational checks.

[0135] Lock / Stop Therapy In some examples, the digital therapeutic system 200 may discontinue a therapy package, for example, due to safety concerns. The core package 202 may interact with relevant backend services, such as the therapy monitoring module 264 or the patient support module 276, to detect the discontinuation of the therapy package 204. The system may then lock access to the therapy, if necessary.

[0136] Patient Onboarding 5 illustrates an end-to-end process for user interaction with a digital therapeutic system according to an embodiment of the present disclosure. The process begins with an initial encounter with a healthcare professional through the prescription, download, installation, and personalization of the digital therapeutic.

[0137] In a first step 584, the user receives an authentication token to access the digital therapeutic system and / or one or more therapeutic packages. For example, the user may be prescribed a drug / digital combination by a clinician who can explain to the patient that there is a digital component of their therapy with the digital therapeutic system. The medicine may be dispensed per existing channels (directly at the pharmacy or via delivery if a repeat prescription) and provide an authentication token such as a QR code, a product code on the packaging or an information leaflet. In other purely digital embodiments, the user may receive the authentication code directly from the clinician. The clinician may create a user profile in the user profile module on behalf of the user.

[0138] In a second step 586, the user downloads the mobile application. The mobile application may be downloaded from an application store or an internet link, as known in the art. The authentication token may comprise the download link. For example, the user may scan a QR code with the mobile device camera, which may initiate the download.

[0139] In a third step 588, the digital therapeutic system authenticates the user and installs or unlocks one or more authorized therapeutic packages. For example, the system may prompt the user to enter their authentication token. The system may then download, install and / or unlock one or more therapeutic packages as authorized by those authentication tokens.

[0140] In some embodiments, the authentication token may be a generalized code that allows access to treatment package x. In some embodiments, the authentication token may allow access to treatment package x in association with drug y. That is, the authentication token may encode details of the contents of the drug packet. The authentication may include patient data including name, address, and dosage instructions. As a result, the authentication token may allow access to treatment package x in association with drug y for patient z and prescription alpha. The authentication token may further provide user details that allow the system to access EHR and other patient data. Access to such data may also be established when the clinician creates a user profile. The authentication token may register and authenticate the mobile device or mobile application instance with a user profile in the user profile module 268. In some embodiments, the authentication token may be disposable to prevent abuse.

[0141] In a fourth optional step 590, in embodiments where the system installs a treatment package, the treatment configuration indicates any core modules that are required, and the core package registers these modules for the respective treatment.

[0142] In a fifth step 592, the system performs an onboarding process with the user. Data required for treatment may be collected directly from the user. Patient data may also be retrieved from the EHR, if available. The system may access the EHR via a user profile module, a patient data module, and / or a patient record module.

[0143] In a sixth step 594, the system may personalize the therapy for the user. The system may perform initial personalization and / or ongoing optimization based on the received data and / or data generated through the user's interaction with the application. As outlined above, therapy personalization may be performed through instructions in the application configuration that may modify the behavior of the module as a result of instructions in the therapy descriptor, and / or through therapy module specific processes that may be initiated independently. Patient data may influence the personalization.

Claims

1. A digital therapeutics system for delivering one or more patient treatment therapies to a patient, comprising: A core software package that provides common capabilities for a range of treatments; a therapy software package including a therapy configuration indicative of operation of the core software package associated with the one or more patient treatment therapies; the core software package being software separated from the therapy software package; When the computer-executable instructions are executed on a processor, the core software package: receiving the treatment configuration from the treatment software package; and and a digital therapeutic system adapted to configure the one or more patient treatment therapies based on the treatment configuration.

2. The digital therapeutic system of claim 1, wherein the computer-executable instructions define a core platform for a plurality of software modules and the core software package, and when the computer-executable instructions are executed, the plurality of software modules are configured to operate on the core platform.

3. 3. The digital therapeutic system of claim 2, wherein each of the plurality of software modules is an isolated partition of software having one or more associated module performance characteristics.

4. The one or more associated module performance characteristics are: the module functionality provided by said module; module performance constraints required by the module and / or one or more other modules of the digital therapeutic system; Inbound and outbound information constraints regarding data or information passed to and from said module; and The digital therapeutic system of claim 3, wherein the one or more other modules and / or the digital therapeutic system include any of descriptive characteristics to enable determining compatibility of the module with performance constraints of the respective other modules or digital therapeutic system.

5. The plurality of software modules: One or more core modules within the core software package; and / or 5. A digital therapeutic system according to any one of claims 2 to 4, comprising one or more therapeutic modules within the therapeutic software package.

6. When the computer-executable instructions are executed, each of the plurality of software modules is configured to register a module interface with the core platform, the module interface comprising:

6. The digital therapeutic system of claim 2, wherein the modules represent exported instruments containing services and / or data that they can provide to other parts of the digital therapeutic system.

7. The digital therapeutic system of claim 6, wherein when the computer-executable instructions are executed, the core platform is configured to match an instrument request from a first module with one or more exported instruments indicated by the registered module interface of a second module.

8. The method of claim 1, wherein when the computer-executable instructions are executed, the first module is configured to provide an appliance request to the core platform along with an associated contract specification indicating one or more constraints for the matched appliance; 8. The digital therapeutic system of claim 7, wherein the core platform is configured to match the instrument request from the first module based on the contract specifications.

9. When the computer-executable instructions are executed, the core platform is further configured to provide a reference interface to the first module for communication with the second module. The reference interface is a direct interface between the first module and the second module; or 8. The digital therapeutic system of claim 6 or 7, comprising an indirect interface comprising an intermediate portion between the first module and the second module.

10. The method of claim 1, wherein, when the computer-executable instructions are executed, the core software package is further adapted to receive patient data and configure the one or more patient treatment therapies based on the patient data; 10. The digital therapeutic system of claim 1, wherein the patient data includes one or more of biometric data, physiological data, behavioral data, prescription data, medical record data, desired outcome data, and patient feedback data.

11. The digital therapeutic system of claim 10, wherein when the computer executable instructions are executed, the core software package is configured to receive the patient data from one or more of patient input, readings from an associated device, and patient record data stored on a local device or a network device.

12. The method of claim 11, wherein, when the computer-executable instructions are executed, the core software package is adapted to receive non-patient data and configure the one or more patient treatment therapies based on the non-patient data; The digital therapeutic system of any one of claims 1 to 11, wherein the non-patient data includes one or more of environmental data, regulatory data, and drug data.

13. The treatment configuration includes one or more treatment instructions, the one or more treatment instructions comprising: one or more treatment decisions; an indication of one or more modules of said core software package necessary to configure said one or more patient treatment therapies; A representation of one or more treatment modules for enrollment in the core platform; and 13. The digital therapeutic system of claim 1, further comprising at least one of: a display of patient data required by a therapeutic engine to configure the one or more patient treatment therapies.

14. The digital therapeutic system of claim 13, wherein the computer-executable instructions further define the core software package to include a therapeutic engine, the therapeutic engine being configured, when the computer-executable instructions are executed, to process the one or more therapeutic decisions using one or more algorithms.

15. A digital therapeutic system as described in any one of claims 1 to 14, wherein the executable instructions further define the core software package to include a safety module, and when the computer executable instructions are executed, the safety module is configured to apply one or more safeguards when configuring the one or more patient treatment therapies.

16. The digital therapeutic system of claim 15, wherein the executable instructions define the safety module to include one or more specific safeguards for configuring the one or more patient treatment therapies.

17. The security module, when the computer-executable instructions are executed on a processor, accessing a drug database containing drug data; and and configured to determine one or more specific drug safeguards based on the drug data.

17. The digital therapeutic system of claim 16, wherein the drug data includes one or more of drug dosage limits, drug interaction data, and demographic-dependent drug dosage data.

18. 18. The digital therapeutic system of claim 16 or 17, wherein the treatment configuration includes one or more treatment specific safeguards for configuring the one or more patient treatment therapies.

19. the one or more patient treatment modalities include one or more digital therapeutic modalities; the one or more digital therapeutic modalities; Pharmacological therapy, including indications of dosing regimens; and 19. A digital therapeutic system according to any one of claims 1 to 18, comprising at least one non-pharmacological therapy.

20. 1. A computer-implemented method of configuring a digital therapeutic in a digital therapeutic system for delivering one or more patient treatment therapies to a patient, the method comprising: receiving a therapy configuration from a therapy package software partitioned from the core software package in the digital therapeutic system, the core software package providing common capabilities for a range of therapies, the therapy configuration indicating operations of the core software package associated with the one or more patient treatment therapies; and configuring one or more digital therapeutics based on the treatment configuration.

Images