Systems and methods for consent management of patient-specific information

Abstract

1. A non-transitory computer-readable storage medium, a user device, and a computer-implemented method configured to: execute a program for managing multiple medical conditions, the program including a consent management module for managing access to patient-specific information; define multiple user IDs and user roles within the program; assign each user ID to one or more user roles; associate a permission level with each user role defining access rights to the patient-specific information; receive a request to send the patient-specific information to an external device, the request being associated with a first user ID; and, in response to receiving the request, identify the user role assigned to the first user ID; and, if the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information, send the requested patient-specific information to the external device.

Description

[Technical Field]

[0001] The present disclosure relates to a system and method for consent management of patient-specific information, particularly health-related user data, using multiple roles that can be assigned to users of the system. [Background technology]

[0002] In the field of data management, there are many data privacy and consent management issues to consider. This is especially true when the data is sensitive, such as patients' personal health information. When building programs to help patients manage their health and communicate with their healthcare professionals, consent management issues are important.

[0003] Current systems do not provide an effective means for obtaining and managing patient consent to use their health-related data in different ways. Current systems also do not provide the level of configurability needed to manage consent for sensitive data. This can negatively impact the range of functionality the system can provide and can negatively impact patient engagement and adherence with prescribed medication regimens, as well as patient understanding of factors affecting their disease progression and overall health. Summary of the Invention [Problem to be solved by the invention]

[0004] Therefore, there is a need for a system and method that provides an effective, configurable, and easy-to-use system for obtaining and managing user consent. [Means for solving the problem]

[0005] A first aspect of the present specification is a computer-implemented method, comprising: executing a program for managing multiple medical conditions, the program including a consent module for managing access to patient-specific information; defining multiple user IDs within the program; defining a plurality of user roles within the program; assigning each of a plurality of user identities to one or more of a plurality of user roles; assigning a permission level to each user role that defines access rights to patient-specific information; receiving a request to transmit patient-specific information to an external device, the request being associated with a first user ID; In response to receiving the request, identifying a user role assigned to a first user ID; transmitting the requested patient-specific information to the external device if the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information; A computer-implemented method is provided, comprising:

[0006] The method may further include generating a notification prompting a user to prepare for an upcoming appointment, and preparing a report including the patient-specific information in response to receiving a user interaction with the notification. The patient-specific information may be health-related data.

[0007] The method may further include revoking a permission level assigned to a first one of the plurality of user roles.

[0008] The method may further include defining a time limit for the permission level assigned to a first role of the plurality of user roles, and revoking the permission level assigned to the first role of the plurality of user roles when the time limit is reached.

[0009] The method may further include assigning a permission level to a particular user ID of the plurality of user IDs. The method may further include defining a time limit for assigning the permission level to the particular user ID, and revoking the permission level assigned to the particular user ID when the time limit is reached.

[0010] The method may further include providing a consent template that links a first role of the plurality of roles to a predefined permission level.

[0011] The multiple user roles may be selected from a list including at least two of the following: patient, physician, guardian, pharmacist, dashboard viewer. The patient may be considered the sole owner of all patient-specific information. The patient may be the only user who can assign consent to other users and / or roles.

[0012] Patient-specific information can be classified into different levels of sensitivity.

[0013] The patient-specific information may include a plurality of resources, and the method may further include assigning access rights to a subset of the plurality of resources, and assigning the permission level may include granting access to the subset of the plurality of resources. A first resource of the plurality of resources may include information that can be used to identify a user, and a second resource of the plurality of resources may include one or more journal entries.

[0014] Each resource may include a plurality of information fields. The method may further include granting access to a subset of the plurality of information fields in the resource. The information fields may include a username, a user address, a medication, and an infusion device type.

[0015] A second aspect of the present specification is a non-transitory computer-readable storage medium, which, when executed by a computer, causes the computer to: Implementing a program for managing multiple medical conditions, including a consent management module for managing access to patient-specific information; Define multiple user IDs within a program, Define multiple user roles within the program, assigning each of a plurality of user identities to one or more of a plurality of user roles; Associating each user role with a permission level that defines access rights to patient-specific information; receiving a request to transmit patient-specific information to an external device, the request associated with a first user ID; In response to receiving the request, Identifying the user role assigned to the first user ID; A non-transitory computer-readable storage medium is provided that includes instructions for causing the requested patient-specific information to be transmitted to an external device if a permission level assigned to a user role of the first user ID allows access to the requested patient-specific information.

[0016] The instructions may further cause the computer to generate a notification prompting the user to prepare for an upcoming appointment, and, in response to receiving a user interaction with the notification, prepare a report including the patient-specific information.

[0017] A third aspect of the present specification is a user device, Implementing a program for managing multiple medical conditions, including a consent management module for managing access to patient-specific information; Define multiple user IDs within a program, Define multiple user roles within the program, assigning each of a plurality of user identities to one or more of a plurality of user roles; Associating each user role with a permission level that defines access rights to patient-specific information; receiving a request to transmit patient-specific information to an external device, the request being associated with a first user ID; In response to receiving the request, Identifying the user role assigned to the first user ID; and providing a user device comprising processing circuitry configured to transmit the requested patient-specific information to an external device if a permission level assigned to a user role of the first user ID grants access to the requested patient-specific information.

[0018] In order that the general concepts set forth in the preceding sections may be more fully understood, embodiments thereof will now be described with reference to the accompanying drawings. [Brief explanation of the drawings]

[0019] [Figure 1] FIG. 1 illustrates the overall architecture of a system on which a computer program runs. [Figure 2] 1 is a high-level schematic diagram of a consent management system. [Figure 3] FIG. 10 illustrates the functionality and stored information of the consent module. [Figure 4] FIG. 1 is a data flow diagram illustrating an application sign-up process. [Figure 5] FIG. 1 is a data flow diagram illustrating the "onboarding" or application customization process. [Figure 6] FIG. 1 is a data flow diagram showing the steps involved in generating a report. [Figure 7] FIG. 1 shows a schematic diagram of a user device for executing a computer program. [Figure 8] 1 is a flowchart of an exemplary method for defining and managing consent within a program for managing multiple medical conditions. [Figure 9A-9B] Figure 9A shows a first consent screen displayed during the account creation process, and Figure 9B shows a privacy notice screen. [Figures 10A-10B] 10A-10C illustrate exemplary screenshots displayed by a computer program relating to facilitating a user's preparation for an appointment with a healthcare professional. [Figure 10C] 10A-10C illustrate exemplary screenshots displayed by a computer program relating to facilitating a user's preparation for an appointment with a healthcare professional. [Figure 10D-10E] 10A-10C illustrate exemplary screenshots displayed by a computer program relating to facilitating a user's preparation for an appointment with a healthcare professional. [Figure 10F] 10A-10C illustrate exemplary screenshots displayed by a computer program relating to facilitating a user's preparation for an appointment with a healthcare professional. [Figures 11A-11B] FIG. 10 is a flowchart illustrating an example of a reservation preparation process. DETAILED DESCRIPTION OF THE INVENTION

[0020] The present disclosure relates to an application that can be executed on a user device and provides a user consent management system for obtaining and managing user consent for access to the user's data.

[0021] This application can be used to manage a wide range of diseases treated with a variety of different medications. While some of the specific embodiments below are described with respect to the treatment of atopic dermatitis and / or asthma using a single medication, the application is not so limited. A variety of other immunological indications may also be managed by the application, and one or more of these immunological indications may be treated using a single medication approved for use in treating one or more immunological indications. Such a single medication may include, for example, different dosages containing the same API, different volumes or concentrations of the same API, or different formulations containing the same API. In some embodiments, the single medication may include an anti-IL-4R mAb (e.g., dupilumab). Furthermore, a wide range of immunological conditions may be managed by the application. A user may be prescribed one or more medications, and the application provides personalized support to the user depending on the user's particular medication prescription and health profile. For example, the application may be configured to provide support for several diseases caused by type 2 inflammation. In the dermatological context, this may include atopic dermatitis, Prurigo Nodularis, bullous pemphigoid, urticaria (e.g., chronic spontaneous urticaria or cold-induced urticaria), hand-foot disease, or prurigo eczema, each of which may be treated with injections of Dupixent® or other injectable drugs, but also with several oral and topical medications. In the context of respiratory diseases, this may include asthma, nasal polyps, sinusitis (e.g., chronic sinusitis with or without nasal polyps), allergic bronchopulmonary aspergillosis (ABPA), or allergic fungal rhinosinusitis (AFRS) (which may also be treatable by injection of Dupixent® or other injectable drugs, but may also be treated with several medications), and chronic obstructive pulmonary disease (COPD), which may be treatable by injection of Dupixent® or other injectable drugs.In the context of gastrointestinal diseases, this can include inflammatory bowel disease (IBD), eosinophilic esophagitis (EoE), and eosinophilic gastroenteritis (EGE), or ulcerative colitis, which may be treated by injection with Dupixent® or other injectable medications, but may also be treated with several oral medications.

[0022] The medication or medications may be administered by injection. As used herein, the term injection or self-injection is intended to encompass intravenous injection, intramuscular injection, infusion, or any needle-based injection system as described in Table 1 of Section 5.2 of ISO 11608-1:2014(E). As described in ISO 11608-1:2014(E), needle-based injection systems can be broadly divided into multi-dose container systems and single-dose (with partial or full discharge) container systems. The container can be a replaceable container or an integrated, non-replaceable container.

[0023] Referring to Figure 1, an overall architecture 100 for a disease management and medication regimen management system is shown. The system architecture 100 illustrates several functional modules and the data links between them. The system architecture 100 includes a user device 104 running an application with several functional modules shown in the center box. The architecture 100 also illustrates how the application run by the user device 104 interacts with other service providers to enhance the information that may be provided to the user via the application, for example, by communicating with insurance / benefit provider systems and pharmacies.

[0024] One of the functional modules is a journal module 102. The journal module 102 is configured to enable a user to maintain a journal related to the user's one or more medical conditions. The journal may include multiple journal entries detailing the occurrence of one or more medical conditions, such as symptoms, user-specific health data, and contextual information. The journal may be used to monitor one or more medical conditions for patterns and identify potential triggers for the occurrence of one or more medical conditions. The journal module 102 may communicate with an external service 134 called Adverse Events. The journal module may send patient information associated with the occurrence of one or more medical conditions to the Adverse Events 134 service.

[0025] The journal may further maintain a record of a user's adherence to a treatment regimen, such as a medication regimen. For example, the journal entries may include records, such as an injection log, that record the doses of medication taken by the user (e.g., scheduled doses). The records may form a dose record that includes various information associated with the doses administered by the user. The records may be stored as part of the journal entry or separately from the journal entry.

[0026] One of these functional modules is a consent module (also referred to herein as a consent management module), which, along with other aspects of the system, is responsible for managing consents and permissions to access patient-specific information, such as a user's health-related data.

[0027] The functional module may further include a memory module 106. The memory module 106 is configured to store user ID and role information, as well as consent templates for use by the consent module. The memory module 106 may also store consent and permission information entered by the user via the consent module, including any time limits set for consent and permission. The memory module 106, in some embodiments, may be linked to the cloud to store information remotely.

[0028] The consent module may communicate with an external service called a consent management service. The consent and permission information generated by the consent module may be stored or copied to the consent management service. The consent management service may also be responsible for transmitting patient-specific information to third parties if the associated consent indicates this is permitted.

[0029] The memory module 106 may be configured to store user ID and role information, as well as consent templates for use by the consent module 118 .

[0030] Another functional module is the content module. The content module 122 is responsible for receiving and recording personalized content and / or preferences set by a user. The content module may communicate with an external service called content management. The content management service is responsible for providing patient-specific content or settings from external users, such as healthcare professionals. The content module may interact with the memory module 106 to store the personalized content and / or settings.

[0031] Another functional module is the benefits module, which is responsible for managing patient access to medical care, along with other aspects of the system. The benefits module may include a pharmacy integration service and / or a benefits integration service. Information generated by the benefits module may be responsible for transmitting patient-specific information to third parties to indicate patient access to medical services. The benefits module may interact with external services, such as benefit provider systems and pharmacy services.

[0032] Another functional module is the analysis module, which is responsible for analyzing patient information associated with the status and / or treatment of a user's medical condition.

[0033] Another functional module is a messaging system. The messaging system may communicate with the analytics module. For example, if the analytics module identifies the occurrence of, or a trigger for, one or more care coordinators for the user, the messaging system outputs a message conveying this result. The messaging system may communicate with an external service called an information hub. The information hub can store data received from the messaging system. The information hub can also interact with other service providers to enhance the information that can be stored about the user through the application, for example, by communicating with patient support programs, insurance / benefit provider systems and pharmacies 130, adverse event services, etc.

[0034] In some embodiments, the functional modules may further include a weather module 108. The weather module 108 is configured to determine and / or record weather conditions at the user's location. The user's location may be identified, for example, by a GPS function of the user device. The weather module 108 may access an online weather forecasting system to obtain, for example, current weather conditions, previous weather conditions, and / or predicted future weather conditions. The weather module 108 may provide the weather conditions to the journal module 102 for inclusion in a journal entry. In addition to weather conditions such as general weather conditions, temperature, humidity, barometric pressure, and UV index, the weather module may additionally obtain air quality information such as pollen count, pollution index, NO2 count, and / or air quality index.

[0035] Another of the functional modules is the user management module 110. The user management module 110 is responsible for obtaining user preferences and generating notifications for output on the user device 104. Data required for the notification scheme may be stored in the memory module 106. The user management module 110 may also update the information held in the memory module 106 as applications are used.

[0036] The user management module 110 can help define and implement a notification scheme that determines when notifications should be generated and how they should be output on the user device 104. The notification scheme may have three main notification types: (i) silent notifications, (ii) batch summary notifications, and (iii) push notifications.

[0037] In some embodiments, silent notifications may be silently pushed into an application and may only be viewable within the application. The user may be presented with silent notifications within the application, for example, on the application's home screen. In some embodiments, silent notifications are presented to the user when certain requirements are met and do not require any action on the part of the user. Batched summary notifications may relate to several different reminders and other notifications. The user can interact with the batched summary notifications to expand and view individual notifications. The batched summary notifications may indicate the number of notifications present for the user to review. Push notifications may relate to a single notification and are pushed to the lock screen or home screen of the user device 104. In some embodiments, push notifications are time-sensitive, actionable items that require the user's immediate attention. They are reserved for actions related to the user's treatment routine or as follow-up to actions that may affect the user's access to treatment / medication.

[0038] Notifications can be escalated, i.e. moved up the notification type, depending on the user's action (or lack thereof). For example: a. When the user is 5 days away from their next medication dose, the next dose reminder will appear as a silent notification within the application, for example below the carousel on the App homepage. b. In the days until the dose, the application pushes batch notifications to the user to review an instructional video, schedule a call with a nurse, or review instructions for self-administration. c. On the day of the dose and one hour before the scheduled time, the application pushes a notification to the user to take the dose. If the user's medication is stored in the refrigerator, the notification instructs the user to remove the medication from the refrigerator. Interacting with this notification triggers the warm-up timer set for the user's medication dose.

[0039] Another of the functional modules is the health / assessment module 112. The health / assessment module 112 is responsible for onboarding users and obtaining details about the user's medical condition and medications being used to treat the user. The health / assessment module 112 may also collect information about the user's prescriptions and manage medication delivery.

[0040] Architecture 100 also illustrates how the applications executed by the functional modules can interact with other service providers to enhance the information that may be provided to users via the applications, such as by communicating with insurance / benefit provider systems and pharmacies.

[0041] Another functional module is the Healthcare Professional (HCP) Services module. The HCP Services module is responsible for facilitating contact with nurses, doctors, or other healthcare professionals, including scheduling reminders for appointments and calls, prompting the user to generate reports or otherwise prepare for upcoming appointments or calls, initiating voice or video calls, providing follow-up notifications after a call or appointment, and initiating journal entries after a call or appointment. The HCP Services module interacts with an internet-based patient support program. Healthcare professionals can also access certain aspects and information maintained by the patient support program to facilitate contact with the user and monitor the user's treatment and / or disease progression.

[0042] FIG. 2 is a high-level schematic diagram of a consent management system that may be defined in and controlled by the consent module 102 and / or consent management service 108. On the left side of the diagram, three different types of users are shown: patient 200, healthcare professional 202, and service provider 204. These are provided merely as examples of the types of users that may be defined within the system and do not represent an exhaustive list. Service providers 204 may include, for example, legal manufacturers (of applications), pharmaceutical / biotechnology companies, pharmacies, insurance companies, or other organizations interested in tracking or controlling information, permissions, or other aspects of providing patient support. In some systems, the legal manufacturer of an application may also be the manufacturer of the drug. In some other embodiments, the drug manufacturer may be included as a separate user or as a user with the same role options as the legal manufacturer. Each of the different user types is assigned a user ID in any suitable format that identifies the user and / or user type. The user ID is stored in the consent module 102 and / or consent management service 108. Additional user types may then be added to the system by updating the information in the consent management service 108 and / or by pushing updated information to the consent module 102 .

[0043] The consent management system also defines several different roles 206, which are labeled in FIG. 2 as Role 1 (206-1), Role 2 (206-2), Role 3 (206-3), etc. In the illustrated embodiment, the patient is assigned to Role 3 (206-3). Role 3 may be one of several roles authorized to grant consent for data to be stored or shared and set permission levels for other roles. In some other embodiments, the "patient" role may be assigned only to registered users of the application. The patient role may grant consent for data to be stored or shared and set permission levels for other roles. Roles 1 and 2 may be reserved for user IDs assigned to, for example, a "parent" or "legal guardian." These roles may also grant consent for data to be stored or shared and set permission levels for other roles.

[0044] Both the healthcare professional 202 and the service provider 204 are each assigned to two different roles. The healthcare professional 202 is assigned to role 5 (206-5) and role 6 (206-6), and the service provider 204 is assigned to role 4 (206-4) and role 6 (206-6). User roles may include, for example, patient, physician, parent, guardian, pharmacist, patient support program, and dashboard viewer. For example, an application provider may be assigned to the dashboard viewer role. Permissions associated with the dashboard viewer role allow the application provider to view anonymized analytical data about users of the application but do not allow access to more sensitive patient information. As a further example, a service provider providing patient support may be assigned to the patient support program role. This role may have access to more sensitive patient data, thereby enabling them to identify individual patients and access at least some of their health data. Certain types of users may not be assigned to certain roles.

[0045] A pharmaceutical / biotech company, for example a manufacturer of drugs used by patients, may have several defined entities assigned to different roles: some entities associated with the pharmaceutical / biotech company may be assigned only as dashboard viewers, while other entities may be assigned to roles with greater permissions, such as that of a pharmacist.

[0046] In some embodiments, by default, all roles other than the "patient" role may have minimal permissions regarding particularly sensitive patient information. More generalized information about patients, such as demographic information, may be available by default for some roles. As an example, the pharmacist role may be assigned to a dispensing pharmacy. A dispensing pharmacy needs information identifying the patient, their prescriptions, and optionally the patient's address. Thus, the pharmacist role may have appropriate permissions set by default. The patient can then use the application to assign the pharmacist role to the dispensing pharmacy. The user's explicit consent may be required for such information to be sent by the application to the dispensing pharmacy, and this consent may be obtained during the sign-up process or within the app when the user assigns the pharmacy role to the dispensing pharmacy.

[0047] As shown, a user assigned to role 4 may request access to some user-specific data via the system's access control element 208. The access control element 208 queries the consent management element 210 (which may be the consent module 102 and / or the consent management service 108) to check whether role 4 has permission to access the requested information. The requested information may be one of a number of different resources 212, and the access control element 208 controls access to these resources 212. For example, one resource may contain information that can be used to identify a user and may include several fields such as "user name," "user address," "user phone number," and "user email address." Alternatively, the user's phone number and email address may be included in a separate resource containing information that can be used to contact the user. Another resource may contain the user's health-related information and may include many fields such as "medication," "infusion device type," "dosage," "dosage concentration," "user first health condition," and "user second health condition." The name and address of the user's doctor may also be included in the health-related information resource and / or the contact details resource, or in a separate resource. In some other embodiments, all of a user's personal information, including information that can be used to identify them, contact details and health-related information, is part of a single resource.

[0048] Consent may be granted or withheld for the entire resource 212 or for specific fields within a resource. Alternatively, or in addition, consent may be granted for a combination of selected fields from different resources. For example, consent may be granted to access the "User Name," "User Address," "Medication," and "Infusion Device Type" fields, while consent may be withheld to access the "User's First Health State" and "User's Second Health State," e.g., to facilitate delivery of the correct medication to the user.

[0049] Further examples of resources 212 defined in the system include written journal entries, health summary reports, user data from other applications such as images of the user stored as part of the journal entry or separately, biometric data from a smartwatch or other activity tracker, information regarding the last time the user took medication, and / or the user's prescribed drug regimen, patient demographics, or other information that can be used to uniquely identify the patient, proof of income, and insurance coverage.

[0050] In some embodiments, a three-tier consent system may be used. Tier 1 consent may be used for doctors. Tier 1 consent may grant the highest level of access to sensitive user information. Tier 2 consent may be used for healthcare providers, such as pharmacies or surgeries. Some personal health information needs to be shared with pharmacies and surgeries, such as prescription information, but less so than with doctors. Tier 3 consent may be used for pharmaceutical companies that manufacture medications for patients and / or data providers, such as companies creating activity or health monitoring systems. Pharmaceutical companies may need to collect basic identifying information about patients taking medications, but may not have access to sensitive patient-specific health data. Similarly, it may be advantageous for users to be able to import activity or physiological data from third-party sources into the application, which may require the third-party source to grant certain consent to connect with the application and verify the user's identity, but not receive other patient-specific information from the application or associated systems.

[0051] Each role 206 may have an associated permission template that specifies the type of data the role can access by default. Having predefined roles and consent templates can greatly streamline and simplify the process of assigning appropriate consent levels to various users of the system. Additionally, a single user ID can be associated with multiple roles in the system. Templates can be defined using the roles described above. For example, a Dashboard Viewer role may have an associated Dashboard Viewer permission template that allows users assigned to this role to view only anonymized analytics data that cannot uniquely identify the patient. A Pharmacist role may have an associated Pharmacist permission template that allows users assigned to this role to view more sensitive patient information that can uniquely identify the patient and also details their medical condition, prescriptions, and address. A Physician template may have additional permissions set by default, such as permission to view any summary reports generated via the journal. A Physician template may not allow access to all information in the user journal, although patients may choose to allow access to specific information.

[0052] Figure 3 illustrates the functionality and stored information of the consent module 102. Figure 3 illustrates twelve different aspects of consent management that the consent module 102 may store or use to control. These are "Create User Roles," "Permission Types," "Consent Dates," "Create and Define Permissions," "Provide Consent," "Manage Consent Expiration and Dates," "Assign Permissions to User Roles," "Fine-Grained Consent Management," "Revoke Consent," "Access Control to Custom Services," "Consent Versioning," and "Access Control to Standard Platform Services." These categories are provided by way of example only, and the wording outlines the scope of information controlled via the consent module 102.

[0053] The consent module 102 and / or consent management service 108 may be queried and / or updated at various times during use of the application, as illustrated in the data flow diagrams of FIGS.

[0054] FIG. 4 is a data flow diagram illustrating the application sign-up process. A patient opens a health management application and performs initial setup of the application by following a series of steps indicated by oval boxes. At several points during the setup process, the application may record user consent. Some of these may be internal consents regarding application operation, such as allowing the application to access the user's biometric information already on the user device 104 to unlock the user device, or allowing the application to access the user's device's camera, gallery, and / or phone applications. At other points, the user is asked to agree to displayed terms and conditions. Once the user enters personal and / or health information as part of the sign-up process, the user may then be asked to consent to storing and sharing this information according to defined policies that are displayed to the user. For example, the first consent screen 900 shown in FIG. 9 a may be displayed after the user enters personal and / or health information during the account creation process. The first consent screen 900 provides a link to the privacy notice and asks the user to grant permission to process their health data as detailed in the privacy notice. When a user selects the link to view the privacy notice, the application may display the privacy notice screen 902 shown in Figure 9b. The privacy notice screen 902 has several sections, which may be in the form of FAQs. The user can select a section to expand it and view the information. Once the user's consents are recorded, they are sent to the consent management service 108.

[0055] Several levels of user consent may be defined and may be required for different actions the application may perform or different data the application may share with external systems. For example, a first level of consent may be required to send the user marketing information using the contact details the user provided during the sign-up process. A second level of consent may be required to allow the user to receive calls from a nurse as part of the onboarding process or medication administration training process. Neither the first level nor the second level of consent may require the user's signature; the user may simply be presented with a consent statement and may check a box or interact with a button to confirm consent. A third level of consent may be required to store the user's health-related data in an external system and / or share the user's health data with a pharmacy. The third level of consent may require the user's signature. A further level of consent may be required to combine the user's health information with the user's "consumer information," such as websites the user visits and / or purchases from. By combining this data, the application can provide the user with more personalized content.

[0056] Figure 5 is a data flow diagram illustrating the "onboarding" or application customization process a user goes through on an application. Figure 5 shows the request for user data entry in the oval box in the center of the diagram, and the movement of data (labeled arrows) between the application and external systems and services. API gateways are programmed into the application to exchange data with functional modules.

[0057] As part of the onboarding process, the user enters information about the trigger conditions of the underlying condition, which may be, for example, atopic dermatitis. The user can then enter steps they are currently taking to minimize the trigger conditions of the underlying condition. The user can then indicate which topics they are interested in learning about related to the underlying condition. The information entered by the user at each of these steps is communicated to an external account management service. The user may also enter information about any other medications they are using, and a check for efficacy discrepancies may be performed.

[0058] At the end of the process, the application asks for the user's consent to store the information entered as part of the customization process, and the user's consent information is communicated to the consent management service 108.

[0059] After collecting information related to the user's underlying condition, the process may be repeated to collect the same information related to a secondary condition, which may be asthma, for example. A separate consent request may be presented for the secondary condition, or the user's consent to all information input may be requested at the end of the onboarding process.

[0060] FIG. 6 is a dataflow diagram illustrating the steps involved in generating a report. Because this report contains user-specific health information and is intended to be shared at least with the user's healthcare provider, some aspects of consent management are involved. Generating the report involves the user entering answers to various questions about their symptoms. This information results in the generation of a report that may also include test scores. The application may request that the user share the generated report with their doctor or other healthcare provider, as described in more detail below with reference to FIGS. 10a-10f, 11a, and 11b. If the user agrees to this request, the consent module 102 and / or consent management service 108 are queried to check that the intended recipient has the appropriate permissions to view the information.

[0061] FIG. 7 schematically illustrates a user device 700 according to some embodiments. The user device 700 may be a mobile phone or a tablet computer. The user device 700 is an example of a wireless communication device. The user device may alternatively be referred to as a communication device, a computer, a computing device, or a mobile device, and is not necessarily associated with a single user. The user device 700 is configured to wirelessly communicate with a communication network using a wireless communication protocol, such as, but not exclusively, 3GPP LTE and / or New Radio (NR) or Wi-Fi (IEEE 802.11). The user device 700 may also be configured to communicate using Bluetooth, NFC, ZigBee, ultra-wideband, IrDa, or the like. The communication network may include one or more network nodes. The communication network may be further connected via a core network and / or intermediate networks to a host computer (not shown), which may be embodied in hardware and / or software of a standalone server, a cloud-implemented server, or a distributed server. The user device 700 and the host computer may be configured to communicate data.

[0062] The user device 700 may comprise hardware including a processing circuit 701. The processing circuit 701 may comprise a processor 702 and memory 704. The user device 700 may also comprise a wireless transceiver 706, a user input 708, a display 712, a camera 710, a microphone 716, as well as an RFID reader 718 and a speaker 714. The wireless transceiver 706 may be configured to set up and maintain a wireless connection to a network node. The wireless transceiver 706 may comprise one or more wireless transmitters and one or more wireless receivers. The display may be a touch-sensitive display or may be based on capacitive or resistive sensing technology. The processing circuit 701 may include, for example, a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc. The processor 702 may be configured to read from and / or write to the memory 704. The memory 704 may include volatile and / or non-volatile memory, such as cache, RAM (random access memory), and / or ROM (read only memory).

[0063] The user device 700 may include software stored, for example, in memory 704. The software may be executable by the processing circuitry 701. The software may include an application. In some embodiments, a host computer may communicate with the application. The application may request data from the host computer and / or provide user data to the host computer.

[0064] The processing circuitry 701 may be configured to perform or cause to be performed any of the methods described herein. In some embodiments, software / programs may include instructions that, when executed by the processing circuitry 701, cause the processing circuitry 401 to perform the methods described herein.

[0065] The memory 704 may include both program memory for storing program code (e.g., software or firmware) and main memory for storing data. The processing circuit 701 may be configured to execute program code stored in the program memory and to read, write, and delete data from the main memory. In some embodiments, the program code may be an application that can be downloaded and installed on the user device 700. The application may be a disease and treatment management and tracking tool for use by the patient. The program memory may be, for example, read-only memory (ROM), and the main memory may be, for example, random access memory (RAM).

[0066] The user device 700 includes one or more user inputs 708, such as a touchscreen, a keypad or keyboard, an accelerometer or gyroscope, a mouse or microphone 716 for receiving voice commands, etc. The user device 700 may also include a camera 710 configured to capture an image of the user and of labels, codes, etc. that may be found on the medication administration device, packaging, or preservative solution. The user device 700 may be configured to scan a medication administration device (such as an injection device or inhaler) using a scanning device. The scanning device may refer to either the camera 710 or the RFID reader 418. The term "scanning" as used with respect to the user device 700 may refer to using either of these components to read information provided externally or internally on the medication administration device.

[0067] FIG. 8 shows a flowchart of an exemplary method for defining and managing consent within a program for managing multiple medical conditions.

[0068] In operation 800, a program (also called an application) for managing multiple medical conditions is executed on a computing device / system. The program includes a consent module for managing access to patient-specific information. The patient-specific information may be health-related data such as details of the user's prescriptions or reports, and / or images of the user's disease progression. The user-specific health information may include one or more physiological measurements obtained from the user. The physiological measurements may include, for example, one or more of heart rate, blood pressure, blood glucose level, body temperature, blood oxygen level, etc. The user-specific health information may alternatively or additionally include one or more activity measurements, such as number of steps, sleep patterns, distance traveled, etc. The user-specific health information may alternatively or additionally include one or more dietary measurements, such as calorie intake, fat intake, and / or salt intake.

[0069] In operation 802, multiple user IDs are defined within the program. Patient IDs may be defined during the sign-up process shown in Figure 4. User IDs associated with the user's physician may also be defined during this setup process.

[0070] In operation 804, multiple user roles are defined within the program. The user roles may be defined in the application's consent module 102. The user roles may include, for example, patient, doctor, guardian, pharmacist, dashboard viewer, among others.

[0071] At operation 806, each of the plurality of user IDs is assigned to one or more of the plurality of user roles. Some of the associations may occur without direct user input. For example, a user ID associated with a user / patient may be automatically associated with the default "user" role. In some other examples, the association may occur indirectly, for example, by asking the user to enter details of a doctor. This may create a user ID for the doctor and automatically associate that user ID with the default "doctor" role.

[0072] In operation 808, each user role is assigned a permission level that defines access rights to patient-specific information. A user may be able to individually set the permission level for each role defined in the system. In addition, the system may provide one or more consent templates that link one or more roles with default permission levels. For example, a consent template may be provided that links the default "Doctor" role to a permission level that allows the doctor to access prescription details and reports generated by the application. A permission level may not allow access to some data, such as images stored within the application. However, a user can manually change the permission level assigned to the "Doctor" role or create a new role and assign the doctor's user ID to this new role.

[0073] In addition to the above operations, the application can also revoke permission levels assigned to roles. For example, a user may view the permission levels assigned to each of the roles defined in the system and then revoke or downgrade the permission levels. A user may also define a time limit associated with an assigned permission level. For example, a user may define that a "doctor" role has permission to access prescription details and reports generated by the application for a period of six months or one year. The application can automatically revoke the permission level assigned to a role once the time limit is reached.

[0074] Additionally, instead of assigning permission levels to roles, a user may use the application to assign permission levels to specific user IDs of multiple user IDs. For example, instead of assigning the same permission level to all healthcare professionals via the "healthcare professional" role, a user may assign permission levels individually to doctors, pharmacists, etc. using the user IDs of those entities. As before, a user may define a time limit associated with the permission level assigned to each user ID, and the application may automatically revoke the permission level assigned to a user ID once the time limit is reached.

[0075] When an external user requests access to any patient-specific information, the permission level that the user has assigned to a role or specific user ID may be checked. An exemplary embodiment of how patient-specific information is created and communicated to an external user, including checking consent, is described with reference to Figures 10a-10f. Figures 10a-10f show screenshots illustrating an application that facilitates preparing a user for an appointment with an HCP.

[0076] The application assists the user in creating reports and / or preparing for an upcoming appointment or call with a doctor, nurse, or other healthcare professional to provide support in the management, treatment, and / or progression of the user's medical condition or symptom. Hereinafter, the term "healthcare professional" is used to encompass all such professionals. The application prompts the user to prepare for an upcoming or requested appointment with the HCP. In particular, the application prompts the user to create a report and send the report to the HCP or an external device accessible by the HCP. The report may include information detailing patient information and / or recorded treatments and / or disease progression recorded by the user.

[0077] In the first screenshot 1000 shown in FIG. 10a, a screen is displayed with the Treatments tab 1002 selected. The application displays a number of user-selectable tabs at the bottom of the screen, including at least two of the following: Home Screen, Treatments, Journal, Learning, and Settings. The Treatments screen includes a notification area where silent notifications are displayed. A first silent notification 1004 is shown, informing the user that their next dose is due today. Alternatively, the first silent notification may inform the user that they have an appointment with their HCP. Interacting with the first silent notification 1004 can open a notification center where any further details related to the notification can be viewed, as well as any other notifications awaiting the user's review. The top of the home screen displays a second silent notification or a graphic indicating a recommended action. The content of the recommended action varies depending on the user's proximity to their next scheduled dose, a doctor's appointment, a prescription renewal / delivery date, etc. In the example of the first screenshot 1000 in FIG. 10a, the recommended action is to prepare a report for the next appointment. User selectable options 1006 are provided to prompt the user to prepare a report.

[0078] When the user interacts with the user selectable option 1006, the second screenshot 1008 of FIG. 10b or the third screenshot 1014 of FIG. 10c is shown.

[0079] The second screenshot 1008 of FIG. 10b is shown when the application is assisting the user in the management and / or treatment of two or more diseases. In other words, the second screenshot 1008 of FIG. 10b may be displayed when the user is a co-morbidity user. The screen includes multiple (two or more) user-selectable options 1010, each associated with the user's medical condition. The user can choose to select one or more of these icons, resulting in an entry for each selected medical condition being included in the report. When the user selects one or more of these icons, user-selectable options 1012 may be activated or otherwise enabled to be selectable, allowing the user to select to continue. The user may choose to continue preparing the report or cancel the action. When the user interacts with the user-selectable options 1012, the third screenshot 1014 of FIG. 10c is shown.

[0080] Alternatively, the third screenshot 1014 of Figure 10c is shown when the application is assisting the user in the management and / or treatment of a single medical condition. In this example, when the user interacts with the user-selectable icon 1006 shown in Figure 10a, the second screenshot of Figure 10b is omitted and the third screenshot 1014 of Figure 10c is immediately shown.

[0081] In FIG. 10c, a third screenshot 1014 shows a report summary screen displaying several areas providing various information, including patient information and / or information detailing recorded treatments and / or disease progression recorded by the user. For example, the areas may include information detailing one or more of the report, patient information, medical conditions, prescription information, and the time period covered by the medical practice and / or doctor with which the user is registered. Other information may be provided in various combinations as well or omitted. For example, while the example shown in FIG. 10c shows two medical conditions, a user may equally have one medical condition or three or more medical conditions. The report summary screen includes a journal area in which one or more user-selectable icons 1016 representing journal entries are displayed. A selected journal entry can be opened by interacting with the user-selectable icon 1016. The journal area may also include user-selectable options (not shown) for completing the journal entry. Journal entries and the process of completing journal entries are described in further detail below.

[0082] The report summary screen includes a control tool area in which one or more user-selectable icons 1018 representing control tool questionnaire entries are shown. The control tool questionnaire provides a score related to the control or progression of the user's medical condition. Interacting with the user-selectable icon 1018 can open a report detailing the selected control tool questionnaire entry. An exemplary report is shown in the fourth screenshot 1022 of FIG. 10d. The control tool area may also include a user-selectable icon 1020 that provides information about the control tool questionnaire. The icon may be represented as an "i," although other graphics may be used as well. Interacting with the user-selectable icon 1020 can open a screen including a control tool information area, such as the screen shown in the fifth screenshot 1024 of FIG. 10e. The control tool information area provides further information to explain the purpose and function of the questionnaire and score associated with the control tool. The screen may also display additional links to provide the user with access to additional information about the tool. Referring back to FIG. 10c, the control tool area may also include additional user-selectable options 1026 for completing the control tool questionnaire.

[0083] In FIG. 10c, the report summary screen also includes a user-selectable option 1028 that allows the user to select to download the report. Interaction with user-selectable option 1028 may confirm to the user that the report is available for download, and the application downloads the report accordingly. Once the user interacts with user-selectable option 1028, sixth screenshot 1030 of FIG. 10f may be shown. Sixth screenshot 1030 includes a graphic confirming that the report has been downloaded. The application logs, saves, or otherwise stores the report. The application may store the report in memory on the user device. Alternatively, the application may be linked to the cloud and the report may be stored remotely.

[0084] If the user selects to download the report, the application may automatically send the report. Before the report is sent, the permission level associated with the recipient is checked by the consent module 102 and / or consent management service 108, as shown in Figure 6. If the recipient has the correct permission level to view the information contained in the report, the report is automatically sent. If the recipient does not have the correct permission level, the report is not sent. A warning may be displayed alerting the user to the lack of permission.

[0085] In another example, once a report is downloaded, the application may send the report only in response to a confirmation from the user that they have chosen to send the report to the HCP. The application may display a notification prompting the user to choose to send (or not send) the report to the HCP. In response to a positive user interaction with the notification to choose to send the report, the application sends the report to the HCP (and vice versa). The HCP's permission level is still checked via the same process as above. The application may send the report to the HCP directly or via a cloud or other external device that may be accessed by the HCP. In response to a negative user interaction with the notification, the application does not send the report.

[0086] In some embodiments, the report is sent to an external server or database. The HCP may then access the report from this external server or database. The HCP's permission level may also be checked at the time the external server or database attempts to access the report.

[0087] 11a and 11b, a flowchart 1100 illustrating the reservation preparation process is shown in FIG. 11a, and a flowchart 1110 illustrating the reservation preparation process, including several optional steps, is shown in FIG. 11b.

[0088] 11a, a report is generated in step 1102. The report is generated for an appointment with an HCP. The report may detail patient information and / or recorded treatments and / or information detailing disease progression recorded by the user. For example, the report may include one or more journal entries and / or control tool questionnaires.

[0089] The report may be generated in response to one or more different triggers. The report may be generated in response to user input selecting the generation of the report. Alternatively and / or additionally, the report may be automatically generated in response to a scheduled appointment or a newly requested appointment with an HCP. For example, the application may be configured to monitor a current appointment schedule set within the application. From this, the application can determine when an appointment is scheduled. For example, the application may determine that there is a scheduled appointment based on a calendar entry. The calendar entry may be associated with one or more of the date, day, or time of the appointment. In some examples, the report may be generated in response to a scheduled reminder. The reminder may be associated with the scheduled appointment or may be independent of the scheduled appointment. The reminder may be pre-set by the user. In another example, the application may also determine the time remaining before the appointment. The time may be measured in minutes, hours, or days. If it is determined that the time remaining until the appointment is less than a threshold time, the application generates a report. The threshold time may be measured in minutes, hours, or days. The threshold time may be preset by the application or may be set by the user.

[0090] In operation 1104, the program sends the report to the HCP. Once the report is generated, it is sent to the HCP automatically or in response to input from the user. The process for sending the report is substantially the same as that described above with respect to Figure 10c, including the steps associated with checking the HCP's permission level.

[0091] Referring now to FIG. 11b, in step 1112, a notification is generated prompting the user to prepare for an appointment with the HCP. The appointment may be scheduled or newly requested by the HCP and / or the user. In one example, the notification may be a push notification pushed to a lock screen or home screen of the user device. In another example, the notification may be a silent notification. A silent notification may be silently pushed to a screen and only viewable within that screen. The silent notification may be displayed on the screen as a reminder or recommendation to the user to prepare for an upcoming appointment with the HCP. For example, the screen may be the home screen of the application. Alternatively or additionally, the screen may be a treatment screen 1002, as shown in the first screenshot 1000 of FIG. 10a.

[0092] The notification prompts the user to prepare for the appointment by preparing a report. The report may detail information detailing patient information and / or recorded treatments and / or disease progression recorded by the user. The user can choose to prepare an appointment with the HCP by interacting with the notification. In response to interacting with the push notification, the application can open a new screen for preparing the report. For example, the application can display the treatment screen shown in the first screenshot 1000 of FIG. 10a.

[0093] The application can be configured to display the notification in response to one or more different triggers, which can be the same as those described above with respect to Figure 11a, and therefore a corresponding description will be omitted.

[0094] The notification provided in step 1112 is optional and may be omitted. In some examples, the user may independently choose to prepare for an appointment with the HCP by creating a report without receiving a notification. For example, the user may interact with user-selectable option 1006 shown in first screenshot 1000 of FIG. 10a.

[0095] In step 1114, user input to select one or more medical conditions to include in the report is detected. For example, the user may select one or more of the user-selectable options 1010, as shown in the second screenshot 1008 of FIG. 2b. This step is optional and may be omitted. For example, it may be omitted if the user has only one medical condition being treated.

[0096] In step 1116, a screen is displayed showing a report summary for the selected medical condition. The report summary may correspond to the summary shown in the third screenshot 1014 of FIG. 10c. The report summary indicates the information to be included in the report. The report summary provides the user with options to review and / or edit the information included in the report.

[0097] In step 1118, the user may choose to edit the report. Step 1118 is optional, and the user may choose not to edit the report. The user may edit the report by modifying, adding, or deleting information. For example, the user may add additional information by completing a journal entry and / or a control tool questionnaire for inclusion in the report. The user may complete the journal entry by selecting a user-selectable option (not shown) from the screen of, for example, third screenshot 1014 of FIG. 10c. The process for completing the journal entry may correspond to that described above.

[0098] Alternatively or additionally, the user may complete the control tool entry by selecting a user selectable option 1026 shown on the screen of the third screenshot 1014 of FIG. 10c, for example.

[0099] In step 1120, the report is completed or finalized. The report may be finalized in response to detecting a user input to download the report. The user input may select a user-selectable option 1028 shown on the screen of the third screenshot 1014 of FIG. 10c. The process of downloading the report is substantially the same as that described above with respect to FIG. 10c, and therefore a corresponding description will be omitted.

[0100] Optionally, in response to detecting that the report has been finalized, a record of the report is stored in step 1122. The application may store the report in memory on the user device. Alternatively, the application may be linked to the cloud and the report may be stored remotely.

[0101] In step 1124, the application sends the report to the HCP. The application may send the report automatically, for example, in response to a user selecting to download the report. Alternatively, the program may send the report in response to user input. The process for sending the report is substantially the same as that described above with respect to FIG. 10c, including steps associated with checking the HCP's permission level before access to the report is granted. The HCP may receive the report directly or may access the report via a remote database.

[0102] The terms "drug" or "medicament" are used synonymously herein to describe a pharmaceutical formulation containing one or more active pharmaceutical ingredients or pharmaceutically acceptable salts or solvates thereof, and optionally a pharmaceutically acceptable carrier. An active pharmaceutical ingredient ("API"), in its broadest sense, is a chemical structure that has a biological effect on humans or animals. In pharmacology, drugs or agents are used to treat, cure, prevent, or diagnose disease, or otherwise improve physical or mental well-being. Drugs or agents may be used for a limited period of time or periodically for chronic conditions.

[0103] As described below, drugs or pharmaceutical agents can contain at least one API or a combination thereof in various types of formulations to treat one or more diseases. Examples of APIs include small molecules with a molecular weight of 500 Da or less, polypeptides, peptides, and proteins (e.g., hormones, growth factors, antibodies, antibody fragments, and enzymes), carbohydrates and polysaccharides, as well as nucleic acids, double-stranded or single-stranded DNA (including naked and cDNA), RNA, antisense nucleic acids such as antisense DNA and RNA, small interfering RNA (siRNA), ribozymes, genes, and oligonucleotides. Nucleic acids can be incorporated into molecular delivery systems such as vectors, plasmids, or liposomes. Mixtures of one or more drugs are also contemplated.

[0104] The drug or agent may be contained within a primary package or "drug container" adapted for use with a drug delivery device. The drug container may be, for example, a cartridge, syringe, reservoir, or other sturdy or flexible container configured to provide a chamber suitable for storage (e.g., short-term or long-term storage) of one or more drugs. For example, in some cases, the chamber may be designed to store the drug for at least one day (e.g., from one day to at least 30 days). In some cases, the chamber may be designed to store the drug for about one month to about two years. Storage may occur at room temperature (e.g., about 20°C) or at refrigerated temperatures (e.g., from about -4°C to about 4°C). In some cases, the drug container may be or include a dual-chamber cartridge configured to separately store two or more components of a pharmaceutical formulation to be administered (e.g., an API and a diluent, or two different drugs), one in each chamber. In such cases, the two chambers of the dual-chamber cartridge may be configured to allow mixing of the two or more components prior to and / or during administration to a human or animal body. For example, the two chambers may be configured so that they are in fluid communication with each other (e.g., by a conduit between the two chambers) to allow a user to mix the two components if desired prior to administration. Alternatively or additionally, the two chambers may be configured to allow mixing upon administration of the components into the human or animal body. Drugs or medicaments contained in drug delivery devices as described herein may be used in the treatment and / or prevention of many different types of medical disorders.

[0105] As used herein, the term "antibody" refers to an immunoglobulin molecule or an antigen-binding portion thereof. Examples of antigen-binding portions of immunoglobulin molecules include F(ab) and F(ab')2 fragments that retain antigen-binding ability. An antibody may be a polyclonal antibody, a monoclonal antibody, a recombinant antibody, a chimeric antibody, a deimmunized or humanized antibody, a fully human antibody, a non-human (e.g., murine) antibody, or a single-chain antibody. In some embodiments, an antibody has effector function and is capable of fixing complement. In some embodiments, an antibody has reduced or no binding ability to Fc receptors. For example, an antibody may be an isotype or subtype, antibody fragment, or variant that does not support Fc receptor binding, e.g., has a mutagenized or deleted Fc receptor binding region. The term antibody also includes antigen-binding molecules based on tetravalent bispecific tandem immunoglobulins (TBTIs) and / or dual variable region antibody-like binding proteins with a crossover binding region orientation (CODV).

[0106] The term "fragment" or "antibody fragment" refers to a polypeptide derived from an antibody polypeptide molecule (e.g., an antibody heavy and / or light chain polypeptide) that does not include the full-length antibody polypeptide but still comprises at least a portion of the full-length antibody polypeptide capable of binding to an antigen. Antibody fragments can include truncated portions of a full-length antibody polypeptide, but the term is not limited to such truncated fragments. Antibody fragments useful in the present invention include, for example, Fab fragments, F(ab')2 fragments, scFv (single-chain Fv) fragments, linear antibodies, monospecific or multispecific antibody fragments, such as bispecific, trispecific, tetraspecific, and multispecific antibodies (e.g., diabodies, triabodies, tetrabodies), monovalent or multivalent antibody fragments, such as bivalent, trivalent, tetravalent, and multivalent antibodies, minibodies, chelating recombinant antibodies, tribodies or bibodies, intrabodies, nanobodies, small modular immunopharmaceuticals (SMIPs), binding domain immunoglobulin fusion proteins, camelized antibodies, and VHH-containing antibodies. Additional examples of antigen-binding antibody fragments are known in the art.

[0107] The term "complementarity-determining region" or "CDR" refers to short polypeptide sequences within the variable regions of both heavy and light chain polypeptides that are primarily responsible for mediating specific antigen recognition. The term "framework region" refers to amino acid sequences within the variable regions of both heavy and light chain polypeptides, rather than CDR sequences, and is primarily responsible for maintaining the correct positioning of the CDR sequences to enable antigen binding. Although the framework regions themselves typically do not directly participate in antigen binding, as is known in the art, certain residues within the framework regions of a particular antibody can be directly involved in antigen binding or can affect the ability of one or more amino acids in the CDRs to interact with the antigen.

[0108] Examples of antibodies are anti-PCSK-9 mAb (e.g., Alirocumab), anti-IL-6R mAb (e.g., Sarilumab), and anti-IL-4R mAb (e.g., Dupilumab).

[0109] Pharmaceutically acceptable salts of any of the APIs described herein are also contemplated for use with the drugs or medicaments in the drug delivery devices. Pharmaceutically acceptable salts include, for example, acid addition salts and base salts.

[0110] Those skilled in the art will appreciate that modifications (additions and / or deletions) to the various components of the APIs, formulations, devices, methods, systems and embodiments described herein may be made without departing from the full scope and spirit of the invention, which encompasses such modifications and any and all equivalents thereof.

[0111] An exemplary drug delivery device may include a needle-based injection system as described in Table 1 of Section 5.2 of ISO 11608-1:2014(E). As described in ISO 11608-1:2014(E), needle-based injection systems may be broadly divided into multi-dose container systems and single-dose (with partial or full discharge) container systems. The container may be an interchangeable container or may be an integrated, non-interchangeable container.

[0112] As further described in ISO 11608-1:2014(E), a multi-dose container system may include a needle-based injection device with replaceable containers. In such a system, each container holds multiple doses and may be fixed or variable in size (pre-set by the user). Another multi-dose container system may involve a needle-based injection device with integrated non-replaceable containers. In such a system, each container holds multiple doses and may be fixed or variable in size (pre-set by the user).

[0113] As further described in ISO 11608-1:2014(E), a single-dose container system may involve a needle-based injection device with replaceable containers. In one example of such a system, each container holds a single dose, thereby dispensing the entire deliverable amount (full discharge). In a further example, each container holds a single dose, thereby dispensing a portion of the deliverable amount (partial discharge). As also described in ISO 11608-1:2014(E), a single-dose container system may include a needle-based injection device with an integrated, non-replaceable container. In one example of such a system, each container holds a single dose, thereby dispensing the entire deliverable amount (full discharge). In a further example, each container holds a single dose, thereby dispensing a portion of the deliverable amount (partial discharge).

Claims

1. 1. A computer-implemented method comprising: executing a program for managing multiple medical conditions, the program including a consent module for managing access to patient-specific information; defining a plurality of user identities within the program; defining a plurality of user roles within the program; assigning each of the plurality of user identities to one or more of the plurality of user roles; assigning each user role a permission level that defines access rights to said patient-specific information; receiving a request to transmit the patient-specific information to an external device, the request being associated with a first user ID; In response to receiving said request, Identifying the user role assigned to the first user ID; transmitting the requested patient-specific information to the external device if the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information; 11. A computer-implemented method comprising:

2. The method comprises: generating a notification to prompt the user to schedule an upcoming appointment; preparing a report including the patient-specific information in response to receiving a user interaction with the notification; The computer-implemented method of claim 1 , further comprising:

3. The computer-implemented method of claim 1 or 2, wherein the patient-specific information is health-related data.

4. The computer-implemented method of any one of claims 1 to 3, further comprising the step of revoking a permission level assigned to a first role of the plurality of user roles.

5. The method comprises: defining a time limit associated with a permission level assigned to a first one of the plurality of user roles; revoking the permission level assigned to the first role of the plurality of user roles when the time limit is reached; The computer-implemented method of any one of claims 1 to 4, further comprising:

6. The computer-implemented method of any one of claims 1 to 5, further comprising assigning a permission level to a particular user ID of the plurality of user IDs.

7. The method comprises: defining a time limit associated with the assignment of a permission level to the particular user ID; revoking the permission level assigned to the particular user ID when the time limit is reached; The computer-implemented method of claim 6 further comprising:

8. 8. The computer-implemented method of claim 1, wherein the method further comprises providing a consent template that links a first role of the plurality of roles to a predefined permission level.

9. The computer-implemented method of any one of claims 1 to 8, wherein the plurality of user roles are selected from a list comprising at least two of: patient, doctor, parent, pharmacist, and dashboard viewer.

10. 10. The computer-implemented method of claim 9, wherein the patient is considered the sole owner of all patient-specific information.

11. The computer-implemented method of claim 10 , wherein the patient is the only user who can assign consent to other users and / or roles.

12. The computer-implemented method of any one of claims 1 to 11, wherein the patient-specific information is classified into different sensitivity levels.

13. 13. The computer-implemented method of claim 1, wherein the patient-specific information includes a plurality of resources, and the method further comprises assigning access rights to a subset of the plurality of resources, and wherein assigning a permission level comprises granting access to the subset of the plurality of resources.

14. 14. The computer-implemented method of claim 13, wherein a first resource of the plurality of resources includes information that can be used to identify the user, and a second resource of the plurality of resources includes one or more journal entries.

15. 15. A computer-implemented method according to claim 13 or 14, wherein each resource comprises a plurality of information fields.

16. The computer-implemented method of claim 15 , wherein the method further comprises granting access to a subset of the plurality of information fields within a resource.

17. 17. The computer-implemented method of claim 16, wherein the information fields include a username, a user address, a medication, and an infusion device type.

18. A non-transitory computer-readable storage medium that, when executed by a computer, causes the computer to: Implementing a program for managing multiple medical conditions, including a consent management module for managing access to patient-specific information; defining a plurality of user IDs within the program; defining a plurality of user roles within said program; assigning each of the plurality of user identities to one or more of the plurality of user roles; associating the permission level with each user role, which defines access rights to the patient-specific information; receiving a request to transmit the patient-specific information to an external device, the request being associated with a first user ID; In response to receiving said request, Identifying the user role assigned to the first user ID; If the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information, then transmitting the requested patient-specific information to the external device. A non-transitory computer-readable storage medium comprising instructions to cause

19. The instructions further include causing the computer to: generating a notification to prompt the user to prepare for an upcoming appointment; 20. The non-transitory computer-readable storage medium of claim 18, wherein in response to receiving a user interaction with the notification, a report including the patient-specific information is prepared.

20. 1. A user device, comprising: Implementing a program for managing multiple medical conditions, including a consent management module for managing access to patient-specific information; defining a plurality of user IDs within the program; defining a plurality of user roles within said program; assigning each of the plurality of user identities to one or more of the plurality of user roles; associating the permission level with each user role, which defines access rights to the patient-specific information; receiving a request to transmit the patient-specific information to an external device, the request being associated with a first user ID; In response to receiving the request, Identifying the user role assigned to the first user ID; If the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information, then transmitting the requested patient-specific information to the external device. A user device comprising a processing circuit configured to:

Images