System and method for agreement management of patient-specific information

Abstract

There is provided a non-transitory computer-readable storage medium, a user device, and a computer-implemented method configured to execute a program for managing a plurality of medical conditions, the program comprising an agreement management module for managing access to patient-specific information; defining a plurality of user IDs and user roles in the program; assigning each of the user IDs to one or more of the user roles; associating a privilege level with each user role, the privilege level defining access to the patient-specific information; receiving a request to transmit the patient-specific information to an external device, the request associated with a first user ID; and in response to receiving the request: determining a user role assigned to the first user ID; and transmitting the requested patient-specific information to the external device when the permission level assigned for the user role of the first user ID allows access to the requested patient-specific information.

Description

Technical Field

[0001] The present specification relates to systems and methods for consent management of patient-specific information, and in particular, health-related user data, using multiple roles assignable to system users. Background Art

[0002] In the area of ​​data management, there are many issues to consider related to data privacy and consent management. This is especially true when the data is of a sensitive nature, such as a patient's personal health information. The issue of consent management is an important one when establishing a program to assist patients in managing their health conditions and communicating information to their healthcare professionals.

[0003] Current systems do not provide effective means for obtaining and managing patient consent for the use of their health-related data in different ways. Current systems also do not provide the level of configurability necessary to manage consent for sensitive data. This can negatively impact the range of functionality that the system can provide, and also negatively impact patient engagement and adherence to prescribed drug regimens, as well as patient understanding of factors that affect their disease progression and overall health.

[0004]

[0006] Therefore, there is a need for systems and methods that provide an efficient, configurable, and user-friendly system for obtaining and managing user consent. Summary of the invention

[0005] A first aspect of the present specification provides a computer-implemented method, the method comprising:

[0006] executing a program for managing a plurality of medical conditions, the program including a consent module for managing access to patient-specific information;

[0007] Define multiple user IDs within the program;

[0008] Define multiple user roles within the program;

[0009] assigning each user ID of the plurality of user IDs to one or more user roles of the plurality of user roles;

[0010] Assigning each user role a permission level that defines access to that patient-specific information;

[0011] receiving a request to transmit the patient-specific information to an external device, the request being associated with the first user ID; and

[0012] In response to receiving the request:

[0013] determining a user role assigned to the first user ID; and

[0014] When the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information, the requested patient-specific information is transmitted to the external device.

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

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

[0017] The method may further include: defining a time limit associated with the permission level assigned to a first role among the plurality of user roles; and revoking the permission level assigned to the first role among the plurality of user roles when the time limit is reached.

[0018] The method may further include assigning a permission level to a specific user ID among the multiple user IDs. The method may further include: defining a time limit related to assigning a permission level to the specific user ID; and when the time limit is reached, revoking the permission level assigned to the specific user ID.

[0019] The method may further include providing a consent template that associates a first role of the plurality of roles with a predefined permission level.

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

[0021] Patient-specific information can be categorized into different sensitivity levels.

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

[0023] Each resource may include a plurality of information fields. The method may further include granting access rights to a subset of the plurality of information fields within a resource. The information fields may include a user name, a user address, a medicament, and an injection device type.

[0024] A second aspect of the present specification provides a non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium comprising instructions, which when executed by a computer cause the computer to:

[0025] executing a program for managing a plurality of medical conditions, the program including a consent management module for managing access to patient-specific information;

[0026] Define multiple user IDs within the program;

[0027] Define multiple user roles within the program;

[0028] assigning each user ID of the plurality of user IDs to one or more user roles of the plurality of user roles;

[0029] Associating a permission level with each user role that defines access to that patient-specific information;

[0030] receiving a request to transmit the patient-specific information to an external device, the request being associated with the first user ID; and

[0031] In response to receiving the request:

[0032] determining a user role assigned to the first user ID; and

[0033] When the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information, the requested patient-specific information is transmitted to the external device.

[0034] 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.

[0035] A third aspect of the present specification provides a user device, the user device comprising a processing circuit system, the processing circuit system being configured to:

[0036] executing a program for managing a plurality of medical conditions, the program including a consent management module for managing access to patient-specific information;

[0037] Define multiple user IDs within the program;

[0038] Define multiple user roles within the program;

[0039] assigning each user ID of the plurality of user IDs to one or more user roles of the plurality of user roles;

[0040] Associating a permission level with each user role that defines access to that patient-specific information;

[0041] receiving a request to transmit the patient-specific information to an external device, the request being associated with the first user ID; and

[0042] In response to receiving the request:

[0043] determining a user role assigned to the first user ID; and

[0044] When the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information, the requested patient-specific information is transmitted to the external device. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to enable a more complete understanding of the general concepts set forth in the foregoing sections, embodiments thereof will be described with reference to the accompanying drawings, in which:

[0046] Figure 1 shows the overall architecture of a system in which a computer program runs;

[0047] Figure 2 It is a high-level schematic diagram of a consent management system;

[0048] Figure 3 is a simplified diagram showing the functionality of the consent module and the information stored;

[0049] Figure 4 It is a data flow diagram showing the application registration process;

[0050] Figure 5 is a data flow diagram that shows the "import" or application customization process;

[0051] Figure 6 is a data flow diagram showing the steps involved in report generation;

[0052] Figure 7 A user device for running a computer program is schematically shown;

[0053] Figure 8 is a flow chart of an example method for defining and managing consent within a program for managing multiple medical conditions.

[0054] Figure 9a shows a first consent screen displayed during the account creation process; and

[0055] Figure 9b shows the privacy statement screen.

[0056] 10a-10f illustrate exemplary screen shots displayed by a computer program relating to facilitating a user to prepare for an appointment with a healthcare professional; and

[0057] 11a and 11b show flow charts illustrating an example of an appointment preparation process. DETAILED DESCRIPTION

[0058] The present disclosure relates to an application that can be run on a user device and provides a user consent management system for obtaining and managing user consent for access to their data.

[0059] The application can be used to manage a variety of diseases treated with various different agents. Although some of the following specific embodiments are described with respect to the use of a single agent to treat atopic dermatitis and / or asthma, the application is not limited thereto. The application can also manage various other immunological indications, wherein one or more of these immunological indications can be treated by using a single agent approved for the treatment of one or more immunological indications. Such a single agent may include, for example, different doses of the same API, different volumes or concentrations of the same API, or different preparations containing the same API. In some embodiments, a single agent may include an anti-IL-4R mAb (e.g., Dupilumab). Further, the application can manage a variety of immune disorders. A user may be prescribed one or more drugs, and the application provides personalized support to the user based on the user's (multiple) specific drug prescriptions and health profiles. For example, the application can be configured to provide support for many diseases caused by type 2 inflammation. In the dermatologic context, this can include atopic dermatitis, prurigo nodularis, bullous pemphigoid, urticaria (e.g., chronic spontaneous urticaria or cold-induced urticaria), chiropodystrophy, or pruritus, each of which can be treated with injections. or other injectable medications, but can also be treated with some oral and topical medications. In the context of respiratory disease, this can include asthma, nasal polyps, sinusitis (e.g., chronic sinusitis with or without nasal polyps), allergic bronchopulmonary aspergillosis (ABPA), or allergic fungal sinusitis (AFRS) (which can be treated with injectable or other injectable medicines, but can also be treated with some oral medicines) and chronic obstructive pulmonary disease (COPD), which can be treated with injectable or other injectable medications). In the context of gastroenterology, this can include inflammatory bowel disease (IBD), eosinophilic esophagitis (EoE) and eosinophilic gastroenteritis (EGE), or ulcerative colitis, which can be treated with an injection of Or other injectable medications, but it can also be treated with some oral medications.

[0060] One or more medicaments can be administered by injection. As used herein, the term injection or self-injection is intended to encompass intravenous injection, intramuscular injection, infusion or any injection system based on a needle as described in ISO 11608-1:2014 (E) Section 5.2 Table 1. As described in ISO 11608-1:2014 (E), injection systems based on a needle can be roughly divided into multi-dose container systems and single-dose (partially or completely emptied) container systems. The container can be a replaceable container or an integrated non-replaceable container.

[0061] refer to Figure 1 , shows an overall architecture 100 of a disease management and drug regimen management system. The system architecture 100 shows a plurality of functional modules and data links between these functional modules. The system architecture 100 includes a user device 104 running an application having a plurality of functional modules, which are shown in the central box. The architecture 100 also shows how the application running on the user device 104 can interact with other service providers to enhance the information that can be provided to the user through the application. For example, by communicating with insurance / benefit provider systems and pharmacies.

[0062] One of the functional modules is a diary module 102. The diary module 102 is configured to allow a user to maintain a diary related to one or more medical conditions of the user. The diary may include multiple diary entries that detail the onset of one or more medical conditions, such as symptoms, user-specific health data, contextual information, etc. The diary may be used to monitor patterns of one or more medical conditions and to identify potential trigger conditions for the onset of the one or more medical conditions. The diary module 102 may communicate with an external service referred to as adverse events 134. The diary module may transmit patient information associated with the onset of one or more medical conditions to the adverse events 134 service.

[0063] The diary may further maintain a record of the user's compliance with a treatment regimen (e.g., a medication regimen). For example, a diary entry may include a record of the medication doses (e.g., predetermined doses) that the user has taken, such as an injection log. The record may form a dose record that includes various information associated with the doses administered by the user. The record may be stored as part of the diary entry, or stored independently of the diary entry.

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

[0065] The functional module may further include a memory module 106. The memory module 106 is configured to store user ID and role information and a consent template 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 the consent and permission. In some embodiments, the memory module 106 may be linked to the cloud and store information remotely.

[0066] The consent module may communicate with an external service known as 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 sending patient-specific information to third parties when the associated consent instructions permit.

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

[0068] Another module in the functional module is the content module. The content module 122 is responsible for receiving and recording personalized content and / or preferences set by the user. The content module can 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 can interact with the memory module 106 to store personalized content and / or settings.

[0069] Another module in the functional modules is a benefits module, which is responsible for managing the patient's access to healthcare in conjunction with other aspects of the system. The benefits module may include pharmacy integration services and / or benefits integration services. Information generated by the benefits module may be responsible for sending patient-specific information to third parties to indicate the patient's access to healthcare services. The benefits module may interact with external services such as benefit provider systems and pharmacy services.

[0070] Another module in the functional module is the analysis module. The analysis module is responsible for analyzing patient information associated with the status and / or treatment of the user's medical condition.

[0071] Another module in the functional module is a messaging system. The messaging system can communicate with the analysis module. For example, if the analysis module identifies the onset or onset trigger of one or more medical conditions of the user, the messaging system outputs a message that conveys this result. The messaging system can 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 about the user that can be stored by the application. For example, by communicating with patient support programs, insurance / benefits provider systems and pharmacies 130, adverse event services, etc.

[0072] 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 determined, for example, by a GPS function of the user's device. The weather module 108 may, for example, access an online weather forecast system to obtain current weather conditions, previous weather conditions, and / or predicted future weather conditions. The weather module 108 may provide the weather conditions to the diary module 102 for inclusion in the diary entry. In addition to weather conditions such as general weather conditions, temperature, humidity, air pressure, and UV index, the weather module may additionally obtain information such as pollen count, pollution index, NO 2 Air quality information such as air counts and / or air quality index.

[0073] Another module in the functional module is the user management module 110. The user management module 110 is responsible for obtaining user preferences and for generating notifications to be output on the user device 104. The necessary data for the notification scheme can be stored on the memory module 106. The user management module 110 can also update the information saved in the memory module 106 when using the application.

[0074] The user management module 110 can define and help implement notification schemes that determine when notifications should be generated and how they should be output on the user device 104. Notification schemes can have three main notification types: (i) silent notifications; (ii) bulk summary notifications; and (iii) push notifications.

[0075] In some embodiments, silent notifications may be pushed silently into the application and may only be viewed within the application. Silent notifications within the application may be presented to the user, for example, on the application home screen. In some embodiments, silent notifications may be presented to the user when certain requirements are met and no action on the part of the user is required. Bulk summary notifications may involve several different reminders and other notifications. The user may interact with the bulk summary notification to expand and show individual notifications. The bulk summary notification may indicate the number of notifications that exist for the user to view. Push notifications may involve 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 and actionable items that require the user's immediate attention. They are retained for actions related to the user's regular treatment, or as a follow-up action to an action that may affect the user's access to treatment / medication.

[0076] Notifications can be escalated, that is, the notification type can be raised based on the user's action (or lack of action). For example:

[0077] a. When a user is 5 days away from their next medication dose, their next medication reminder will appear as a silent notification in the app, such as below the carousel on the app home page.

[0078] b. In the days leading up to the medication, the app will push batch notifications to users to view an instructional video, schedule a call with a nurse, or review self-administration instructions.

[0079] c. On the day of medication and one hour before the scheduled time, the app will push a notification to the user to take the medication. If the user's medication is kept in the refrigerator, the notification will instruct the user to take their medication out of the refrigerator. Interacting with the notification will trigger a preheat timer set to the user's medication dose.

[0080] Another module in the functional module is the health / assessment module 112. The health / assessment module 112 is responsible for importing the user and obtaining detailed information about the user's medical conditions and the medications used to treat these conditions. The health / assessment module 112 can also collect information about the user's prescriptions and manage the delivery of medications.

[0081] Architecture 100 also illustrates how the application run by the functional module can interact with other service providers to enhance the information that can be provided to the user through the application (such as by communicating with insurance / benefit provider systems and pharmacies).

[0082] Another module in the functional module is the healthcare professional (HCP) service module. The HCP service module is responsible for facilitating contact with nurses, doctors, or other healthcare professionals, including scheduling reminders related to appointments and calls, prompting users to create reports or otherwise prepare for upcoming appointments or calls, initiating voice or video calls, providing follow-up notifications after calls or appointments, and initiating diary entries after calls or appointments. The HCP service module interacts with Internet-based patient support programs. Healthcare professionals can also access certain aspects and information saved by the patient support program to facilitate contact with users and monitor the user's treatment and / or disease progress.

[0083] Figure 21 is a high-level schematic diagram of a consent management system that can be defined in and controlled by the consent module 102 and / or the consent management service 108. Three different types of users are shown on the left side of the diagram. These users are patients 200, healthcare professionals 202, and service providers 204. These users are given only as examples of user types that can be defined in the system and do not represent an exhaustive list. The service provider 204 may include, for example, a legitimate manufacturer (of the application), a pharmaceutical company / biotech company, a pharmacy, an insurance company, or other organizations that are concerned with tracking or controlling information, licensing, or providing other aspects of patient support. In some systems, the legitimate manufacturer of the application may also be the manufacturer of the medicament. In some other embodiments, the manufacturer of the medicament may be included as a separate user or as a user with the same role options as the legitimate manufacturer. A user ID in any suitable format that identifies the user and / or user type is assigned to each of the different user types. The user ID is stored in the consent module 102 and / or the consent management service 108. Then, additional user types can be added to the system by updating the information in the consent management service 108 and / or by pushing the updated information to the consent module 102.

[0084] The consent management system also defines a number of different roles 206. These roles are Figure 2 1, 206-2, 206-3, etc. In the depicted embodiment, the patient is assigned to role 3 (206-3). Role 3 can be one of several roles that are authorized to give consent to store or share data and set permission levels for other roles. In some other embodiments, the "patient" role can only be assigned to registered users of the application. The patient role can give consent to store or share data and set permission levels for other roles. For example, roles 1 and 2 can be reserved to represent user IDs assigned to "parents" or "legal guardians." These roles may also be able to give consent to store or share data and set permission levels for other roles.

[0085] Both healthcare professional 202 and service provider 204 are assigned to two different roles. Healthcare professional 202 is assigned to role 5 (206-5) and role 6 (206-6), while service provider 204 is assigned to role 4 (206-4) and role 6 (206-6). User roles may include, for example, patients, physicians, parents, guardians, pharmacists, patient support programs, and dashboard observers, etc. For example, a provider of an application may be assigned to a dashboard observer role. The permissions associated with the dashboard observer role may allow the provider of the application to view anonymous analytical data about the user of the application, but will not allow access to more sensitive patient information. As another example, a service provider providing patient support may be assigned to a patient support program role. This role may access more sensitive patient data, which allows it to identify individual patients and access at least some of the health data of individual patients. Certain types of users may not be assigned to certain roles.

[0086] A pharmaceutical / biotech company (e.g., a manufacturer of a medication used by a patient) may have many defined entities assigned to different roles. Some entities associated with the pharmaceutical / biotech company may be assigned only as dashboard observers, while other entities may be assigned to roles with greater permissions, similar to the role of a pharmacist.

[0087] In some embodiments, by default, all roles except the "patient" role may have minimal permissions, especially those related to sensitive patient information. By default, some roles may have access to more general information, such as demographic information about the patient. As an example, the pharmacist role may be assigned to a dispensing pharmacy. The dispensing pharmacy requires information that identifies the patient, the patient's prescription, and optionally the patient's address. Therefore, the pharmacist role may have appropriate permissions set by default. The patient can then use the application to assign the pharmacist role to their dispensing pharmacy. The user's explicit consent may be required for the application to send this information to the dispensing pharmacy, and this consent may be obtained within the app during the registration process or when the user assigns the pharmacy role to the dispensing pharmacy.

[0088] As depicted, a user assigned as role 4 can 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 can 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 can be one of many different resources 212, and the access control element 208 controls access to these resources 212. For example, one resource can include information that can be used to identify a user, and can contain many fields, such as "user name", "user address", "user phone number", and "user email address". Alternatively, the user's phone number and email address can be included in a separate resource that includes information that can be used to contact the user. Another resource can include health-related information for the user, and can include many fields, such as "medication", "injection device type", "dose volume", "dose concentration", "user first health condition", and "user second health condition". The name and address of the user's doctor can also be included in the health-related information resource and / or the contact information resource, or in a separate resource. In some other embodiments, all user personal information (including information that can be used to identify the user, contact information, and health-related information) are part of a single resource.

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

[0090] Additional examples of resources 212 defined in the system include: written diary entries, health summary reports, images of the user stored as part of diary entries or stored separately, user data from other applications (such as biometric data from a smart watch or other activity tracker), information about the last time the user took their medication and / or the user's prescribed dosage regimen, patient demographics or other information that can be used to uniquely identify a patient, proof of income, and insurance coverage status.

[0091] In some embodiments, a three-level consent system can be used. The first level of consent can be used for doctors. The first level of consent can grant the highest level of access to sensitive user information. The second level of consent can be used for healthcare providers (such as pharmacies or clinics). Some personal health information needs to be shared with pharmacies or clinics, such as prescription information, but not as much as shared with doctors. The third level of consent can be used for pharmaceutical companies that manufacture patient medications and / or data providers (such as companies that make activity or health monitoring systems). Pharmaceutical companies may need to collect basic identity information about patients taking medications, but cannot access any 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 applications, which may require granting certain consent to third-party sources to interface with the application and verify the user's identity, but not receive any other patient-specific information from the application or related systems.

[0092] Each of the roles 206 may have an associated permission template that specifies the data types that 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. In addition, a single user ID can be associated with multiple roles within the system. The above roles can be used to define templates. For example, the dashboard observer role may have an associated dashboard observer permission template that allows users assigned to the role to only view anonymous analytical data that does not uniquely identify the patient. The pharmacist role may have an associated pharmacist permission template that allows users assigned to the role to view more sensitive patient information that allows unique identification of the patient and details of their medical conditions, prescriptions, and addresses. The physician template may have further permissions set by default, such as the permission to view any summary reports generated via the diary. The physician template may not allow access to all information in the user's diary, but the patient can choose to allow access to specific information.

[0093] Figure 3 is a simplified diagram showing the functionality of the consent module 102 and the information stored therein. Figure 3 Twelve different consent management aspects are shown that the consent module 102 can store or use to control. These aspects are "Create User Roles", "Permission Types", "Consent Dates", "Create and Define Permissions", "Provide Consent", "Consent Expiration and Date Management", "Assign Permissions to User Roles", "Granular Consent Management", "Revoke Consent", "Access Control to Custom Services", "Consent Version Management", and "Access Control to Standard Platform Services". These categories are shown as examples only, and their wording outlines the scope of information controlled via the consent module 102.

[0094] The consent module 102 and / or the consent management service 108 may be queried and / or updated at various times during use of the application, such as Figures 4 to 6 As shown in the data flow diagram.

[0095] Figure 4 is a data flow diagram showing the application registration process. The patient opens the health management application and follows a series of steps as indicated in the oval box to perform the initial setup of the application. At several points during the setup process, the application can record the user's consent. Some of these consents can be internal consents related to the operation of the application, such as the application's permission to access the user's biometric information already on the user device 104 for unlocking the user device, or permission to access the user device camera, gallery and / or phone application. At other points, the user is requested to agree to the displayed terms and conditions. When the user enters personal information and / or health information as part of the registration process, the user may be requested to agree to store and share the information according to the defined policy displayed to the user. For example, during the account creation process and once the user enters personal information and / or health information, the first consent screen 900 shown in FIG. 9a can be displayed. The first consent screen 900 provides a link to the privacy statement and requests the user to give permission to process the user's health data as described in detail in the privacy statement. If the user selects the link to view the privacy statement, the application can display the privacy statement screen 902 shown in FIG. 9b. The privacy statement screen 902 has many sections, which may take the form of a FAQ. The user may select a section to expand and view the information. Once the user's consent is recorded, it is transmitted to the consent management service 108.

[0096] Several user consent levels may be defined and requested for different actions that the application may perform or different data that the application may share with external systems. For example, a first level of consent may be required to send marketing information to the user using the contact information provided by the user during the registration process. A second level of consent may be required to allow the user to receive a call from a nurse as part of an import process or a medication administration training process. The first or second levels of consent may not require a user signature; the user may simply be presented with a consent statement and the user may tick a box or interact with a button to confirm their consent. A third level of consent may be required to store the user's health-related data on 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. Combining the user's health information with the user's "consumer information" (such as the websites the user visits and / or shops on) may require further levels of consent. Combining this data may allow the application to provide more personalized content to the user.

[0097] Figure 5 Is a data flow diagram that illustrates the "import" or application customization process performed by the user on the application. Figure 5 The diagram shows a request for user data input in the oval in the center of the diagram, and the movement of data between the application and external systems and services (marked with arrows). An API gateway is programmed into the application to exchange data with the functional modules.

[0098] As part of the "import" process, the user enters information about the triggers for the primary condition, which may be, for example, atopic dermatitis. The user may then enter what steps they are currently taking to minimize the triggers for the primary condition. The user may then indicate what topics they are interested in learning about regarding their primary condition. The information entered by the user in each of these steps is transmitted to the external account management service. The user may also enter information about any other medications they are taking, and a check for conflicts may be performed.

[0099] At the end of the process, the application requests the user's consent to store the information entered by the user as part of the customization process. The user's consent information is transmitted to the consent management service 108.

[0100] After collecting information about the user's primary condition, the process can be repeated to collect the same information about a secondary condition (which can be, for example, asthma). A separate consent request can be made for the secondary condition, or the user's consent to all information input can be requested at the end of the import process.

[0101] Figure 6 is a data flow diagram illustrating the steps involved in report generation. Because the report contains user-specific health information and is intended to be shared with at least the user's healthcare professional, some aspects of consent management are involved. Report generation involves the user entering answers to various questions related to their symptoms. This information results in the generation of a report, which may also include test scores. As described in more detail below with reference to Figures 10a to 10f, Figure 11a, and Figure 11b, the application may request that the user share the generated report with their doctor or other healthcare professional. If the user agrees to the request, the consent module 102 and / or the consent management service 108 are queried to check whether the indicated recipient has appropriate permissions to view the information.

[0102] Figure 7Schematically 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 communicate wirelessly with a communication network using a wireless communication protocol (e.g., 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 further be connected to a host computer (not shown) via a core network and / or an intermediate network, which may be embodied in the 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 transmit data.

[0103] The user device 700 may include hardware including a processing circuit system 701. The processing circuit system 701 may include a processor 702 and a memory 704. The user device 700 may also include a wireless transceiver 706, a user input 708, a display 712, a camera 710, a microphone 716, and an RFID reader 718 and a speaker 714. The wireless transceiver 706 may be configured to establish and maintain a wireless connection to a network node. The wireless transceiver 706 may include one or more radio transmitters and one or more radio receivers. The display may be a touch-sensitive display and may be based on capacitive or resistive sensing technology. The processing circuit system 701 may, for example, include 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 and / or write from the memory 704. The memory 704 may include volatile and / or non-volatile memory, such as a cache, a RAM (random access memory) and / or a ROM (read-only memory), etc.

[0104] User device 700 may include software stored, for example, in memory 704. The software may be executed by processing circuit system 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.

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

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

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

[0108] Figure 8 A flow chart of an example method for defining and managing consent within a program for managing multiple medical conditions is shown.

[0109] At operation 800, a program (also referred to as 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 a user's prescription or report and / or images of the user's disease progression. User-specific health information may include one or more physiological measurements obtained from the user. The physiological measurements may, for example, include one or more of the following: 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.

[0110] At operation 802, multiple user IDs are defined within the program. The patient ID can be Figure 4 The user ID associated with the user's physician may also be defined during the registration process.

[0111] At operation 804, multiple user roles are defined within the program. The user roles may be defined in the consent module 102 of the application. The user roles may include, for example: patient, physician, guardian, pharmacist, and dashboard observer, etc.

[0112] At operation 806, each of the plurality of user IDs is assigned to one or more of the plurality of user roles. Certain associations may be made without direct user input. For example, a user ID associated with a user / patient may be automatically associated with a predefined "user" role. In some other cases, the association may be done indirectly, for example by requesting the user to enter details of their physician. This may create a user ID for the physician and automatically associate the user ID with a predefined "physician" role.

[0113] At operation 808, each user role is assigned a permission level that defines access to patient-specific information. The 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 associate one or more roles with predefined permission levels. For example, a consent template may be provided that associates a default "physician" role with a permission level that allows the physician to access prescription details and reports generated by the application. The permission level may not allow access to some data, such as images stored within the application. However, the user can manually change the permission level assigned to the "physician" role or create a new role and assign its physician user ID to this new role.

[0114] In addition to the operations mentioned above, the application can also revoke the permission level assigned to a role. For example, a user can view the permission level assigned to each of the roles defined in the system, and then revoke or downgrade the permission level. The user can also define time limits related to the assigned permission levels. For example, a user can define that the "physician" role has access to prescription details and reports generated by the application for 6 months or 1 year. When the time limit is reached, the application can automatically revoke the permission level assigned to the role.

[0115] Additionally, instead of assigning permission levels to roles, the user can use the application to assign permission levels to specific user IDs among multiple user IDs. For example, instead of assigning the same permission level to all healthcare professionals via the "Health Care Professional" role, the user can individually assign permission levels to their physicians, pharmacists, etc. using the user IDs of those entities. As previously discussed, the user can also define a time limit for each user ID related to the assigned permission level, and when the time limit is reached, the application can automatically revoke the permission level assigned to the user ID.

[0116] When an external user requests access to any patient specific information, the permission level assigned by the user for a role or a specific user ID can be checked. An exemplary embodiment of how patient specific information is created and communicated to an external user, including a consent check, will now be described with reference to FIGS. 10 a to 10 f. FIGS. 10 a to 10 f show screenshots of an application that facilitates a user to prepare an appointment with an HCP.

[0117] The application assists the user in creating a report and / or otherwise preparing for an upcoming appointment or call with a doctor, nurse or other healthcare professional, in which support is provided for the management, treatment and / or progress of one or more medical conditions of the user. Hereafter, the term healthcare professional is used to cover all such professionals. The application prompts the user to prepare for an upcoming or requested appointment with an HCP. In particular, the application prompts the user to create a report and transmit the report to the HCP or an external device accessible to the HCP. The report may include patient information and / or detailed description of the recorded treatment and / or disease progression recorded by the user.

[0118] In the first screenshot 1000 shown in FIG. 10a, a screen is shown in which a treatment tab 1002 is selected. The application shows a number of user-selectable tabs at the bottom of the screen, including at least two of the home screen, treatment, diary, learning, and settings. The treatment screen has a notification area in which silent notifications are shown. A first silent notification 1004 is shown to remind the user that his next dose is due today. Alternatively, the first silent notification can remind the user that his appointment with the HCP is coming soon. Interacting with the first silent notification 1004 opens the notification center, where any further details related to the notification and any other notifications waiting for the user to view can be seen. At the top of the home screen, a second silent notification or a graphic with a suggested action is displayed. The content of the suggested action changes depending on the proximity of the user's next scheduled dose, doctor's appointment, prescription renewal / delivery date, etc. In the example of the first screenshot 1000 of FIG. 10a, the suggested action is to prepare a report for the upcoming appointment. A user-selectable option 1006 is provided to prompt the user to prepare a report.

[0119] 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.

[0120] If the application is assisting the user in managing and / or treating more than one disease, a second screenshot 1008 of Figure 10b is shown. In other words, if the user is a co-morbid user, a second screenshot 1008 of Figure 10b may be shown. The screen includes multiple (two or more) user selectable options 1010, each of which is associated with a certain medical condition of the user. The user may select one or more of these icons so that an entry for each of the selected medical conditions will be included in the report. When the user selects one or more of these icons, a user selectable option 1012 that allows the user to select to continue may be activated or otherwise made selectable. The user may choose to continue preparing the report or cancel the action. When the user interacts with the user selectable option 1012, a third screenshot 1014 of Figure 10c is shown.

[0121] Alternatively, the third screenshot 1014 of Figure 10c is shown when the application assists the user in managing and / or treating 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.

[0122] In Figure 10c, the third screenshot 1014 shows a report summary screen, which displays many areas providing various information, including patient information and / or detailed description of the recorded treatment and / or the information of the disease progression recorded by the user. For example, these areas can include information describing one or more of the following in detail: the time period covered by the report, patient information, medical conditions, prescription information, and the medical practice and / or doctor registered by the user. Similarly, other information can be provided or omitted in various combinations. For example, in the example shown in Figure 10c, two medical conditions are shown, but the user can also have a single medical condition or more than two medical conditions. The report summary screen includes a diary area, wherein one or more user-selectable icons 1016 representing diary entries are shown. Interacting with the user-selectable icon 1016 will open the selected diary entry. The diary area can also include user-selectable options (not shown) for completing the diary entry. The diary entry and the process of completing the diary entry will be discussed in more detail below.

[0123] The report summary screen includes a control tool area, wherein one or more user selectable icons 1018 representing the control tool questionnaire input are shown. The control tool questionnaire provides a score associated with the control or progress of the user's (multiple) medical conditions. Interacting with the user selectable icon 1018 will open a report describing the selected control tool questionnaire input in detail. An example report is shown in the fourth screenshot 1022 of Figure 10d. The control tool area can also include a user selectable icon 1020, which provides information about the control tool questionnaire. The icon can be represented by "i", but other graphics can also be used. Interacting with the user selectable icon 1020 will open a screen including a control tool information area, such as the screen shown in the fifth screenshot 1024 of Figure 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 can also display additional links to provide the user with access to additional information about the tool. Referring back to Figure 10c, the control tool area can also include additional user selectable options 1026 to complete the control tool questionnaire.

[0124] In FIG. 10c, the report summary screen also includes a user selectable option 1028 to allow the user to select to download the report. Interacting with the user selectable option 1028 provides confirmation from the user that the report is ready to be downloaded, and in response, the application downloads the report. When the user interacts with the user selectable option 1028, the sixth screenshot 1030 of FIG. 10f may be shown. The sixth screenshot 1030 includes a graphic confirming that the report has been downloaded. The application records, saves, or otherwise stores the report. The application may store the report in a memory of the user device. Alternatively, the application may be linked to the cloud and the report may be stored remotely.

[0125] In response to the user selecting to download the report, the application can automatically transmit the report. Before transmitting the report, the consent module 102 and / or the consent management service 108 checks the permission level associated with the recipient, such as Figure 6 If the recipient has the correct level of permissions to view the information contained in the report, the report is automatically transmitted. If the recipient does not have the correct level of permissions, the report is not transmitted. A warning can be displayed to alert the user to the lack of permissions.

[0126] In another example, once the report has been downloaded, the application may transmit the report only in response to a confirmation from the user that the report is selected to be transmitted to the HCP. The application may display a notification prompting the user to select to transmit (or not transmit) the report to the HCP. In response to a positive user interaction with the notification selecting to transmit the report, the application transmits the report to the HCP (and vice versa). The HCP's permission level is still checked via the same process as described above. The application may transmit the report to the HCP directly or via the cloud or other external device that can be accessed by the HCP. In response to a negative user interaction with the notification, the application does not transmit the report.

[0127] In some embodiments, the report is transmitted to an external server or database. The HCP can then access the report from the external server or database. When attempting to access the report, the HCP's authority level can also be checked by the external server or database.

[0128] Referring now to FIGS. 11 a and 11 b , FIG. 11 a shows a flowchart 1100 illustrating an appointment preparation process, and FIG. 11 b shows a flowchart 1110 illustrating an appointment preparation process including some optional steps.

[0129] In FIG. 11a, a report is generated at step 1102. The report is generated for an appointment with an HCP. The report may detail patient information and / or detail recorded treatment and / or disease progression information recorded by a user. For example, the report may include one or more diary entries and / or a control tool questionnaire.

[0130] The report may be generated in response to one or more different trigger conditions. The report may be generated in response to a user input selecting to generate the report. Alternatively and / or in addition, the report may be automatically generated in response to a scheduled appointment or a newly requested appointment with the HCP. For example, the application may be arranged to monitor the current appointment schedule set within the application. Thus, the application may determine when the scheduled appointment is made. For example, the application may determine that there is a scheduled appointment based on a calendar entry. The calendar entry may be related to 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 independent of the scheduled appointment. The reminder may be set in advance 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. In response to determining that the time remaining before 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 pre-set in the application or set by the user.

[0131] At operation 1104, the program transmits the report to the HCP. Once the report is generated, it is transmitted to the HCP automatically or in response to input from the user. The process of transmitting the report is substantially the same as the process discussed above with respect to FIG. 10c, including the steps associated with checking the HCP's authority level.

[0132] Referring now to FIG. 11b, at 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 that is pushed to the lock screen or home screen of the user's device. In another example, the notification may be a silent notification. A silent notification may be pushed silently into a screen and may only be viewed within that screen. A silent notification may be displayed on a screen as a reminder or suggestion 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 in addition, the screen may be a treatment screen 1002, as shown in the first screenshot 1000 of FIG. 10a.

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

[0134] The application may be arranged to display a notification in response to one or more different trigger conditions. The trigger conditions may be the same as those discussed above with respect to FIG. 11a, and thus the corresponding description shall be omitted.

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

[0136] At step 1114, user input is detected for selecting one or more medical conditions to be included in the report. For example, the user may select one or more of the user selectable options 1010, such as Figure 2 b is shown in the second screenshot 1008. This step is optional and can be omitted. For example, this step can be omitted when the user only has one medical condition being treated.

[0137] At step 1116, a screen showing a report summary for the selected medical condition is displayed. 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 the option of viewing and / or editing the information to be included in the report.

[0138] At 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 removing information. For example, the user may add additional information to be included in the report by completing a diary entry and / or a control tool questionnaire. The user may complete the diary entry, for example, by selecting a user selectable option (not shown) from the screen in the third screenshot 1014 of FIG. 10c. The process of completing the diary entry may correspond to the process described above.

[0139] Alternatively or in addition, the user may complete the control tool input, for example by selecting the user selectable option 1026 shown on the screen in the third screenshot 1014 of Figure 10c.

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

[0141] At step 1122, optionally, in response to detecting that the report is finally completed, a record of the report is stored. The application may store the report in a memory of the user device. Alternatively, the application may be linked to the cloud and the report may be stored remotely.

[0142] At step 1124, the application transmits the report to the HCP. The application may automatically transmit the report, for example, in response to a user selecting to download the report. Alternatively, the program may transmit the report in response to user input. The process of transmitting the report is substantially the same as the process described above with respect to FIG. 10c, including steps associated with checking the HCP's permission level before granting access to the report. The HCP may receive the report directly or may access the report via a remote database.

[0143] The terms "drug" or "medicament" are used synonymously herein and describe a pharmaceutical preparation comprising one or more active pharmaceutical ingredients or a pharmaceutically acceptable salt or solvate thereof and optionally a pharmaceutically acceptable carrier. In the broadest sense, an active pharmaceutical ingredient ("API") is a chemical structure that has a biological effect on humans or animals. In pharmacology, a drug or medicament is used to treat, cure, prevent, or diagnose disease or to otherwise enhance physical or mental health. A drug or medicament may be used for a limited duration, or periodically for a chronic disorder.

[0144] As described below, a drug or medicament may include at least one API or a combination thereof in various types of formulations for treating one or more diseases. Examples of APIs may include small molecules (having 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; and 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 may be incorporated into molecular delivery systems (such as vectors, plasmids, or liposomes). Mixtures of one or more drugs are also contemplated.

[0145] The drug or medicament can be included in a primary package or "drug container" suitable for use with a drug delivery device. The drug container can be, for example, a cartridge, a syringe, a reservoir or other solid or flexible vessel, which is configured to provide a suitable chamber for storing (e.g., short-term or long-term storage) one or more drugs. For example, in some cases, the chamber can be designed to store the drug for at least one day (e.g., 1 day to at least 30 days). In some cases, the chamber can be designed to store the drug for about 1 month to about 2 years. It can be stored at room temperature (e.g., about 20 ° C) or refrigerated temperature (e.g., about -4 ° C to about 4 ° C). In some cases, the drug container can be or can include a dual-chamber cartridge, which is configured to store two or more components (e.g., API and diluent, or two different drugs) of the pharmaceutical preparation to be applied separately, one of which is stored in each chamber. In such a case, the two chambers of the dual-chamber cartridge can be configured to allow mixing between two or more components before and / or during distribution to the human or animal body. For example, the two chambers can be configured so that they are in fluid communication with each other (e.g., by a conduit between the two chambers) and allow the two components to be mixed when the user needs before dispensing. Alternatively or in addition, the two chambers can be configured to allow mixing when the components are dispensed into the human or animal body. The drugs or medicaments contained in the drug delivery device as described herein can be used to treat and / or prevent many different types of medical disorders.

[0146] As used herein, the term "antibody" refers to an immunoglobulin molecule or its antigen binding portion. Examples of antigen binding portions of immunoglobulin molecules include F (ab) and F (ab ') 2 fragments, which retain the ability to bind antigens. The antibody can be a polyclonal antibody, a monoclonal antibody, a recombinant antibody, a chimeric antibody, a deimmunized antibody or a humanized antibody, a fully human antibody, a non-human (e.g., mouse) antibody or a single-chain antibody. In certain embodiments, the antibody has effector functions and can fix complement. In certain embodiments, the ability of the antibody to bind to Fc receptors is reduced or there is no such ability. For example, the antibody can be an isotype or subtype, an antibody fragment or a mutant, which does not support binding to Fc receptors, for example, its Fc receptor binding region has been mutated or missing. The term antibody also includes antigen binding molecules based on tetravalent bispecific tandem immunoglobulins (TBTI) and / or dual variable region antibody-like binding proteins with cross-binding region orientation (CODV).

[0147] The term "fragment" or "antibody fragment" refers to a polypeptide derived from an antibody polypeptide molecule (e.g., an antibody heavy chain and / or light chain polypeptide), which does not include a full-length antibody polypeptide, but still includes at least a portion of a full-length antibody polypeptide that can bind to an antigen. Antibody fragments can include cleavage portions of full-length antibody polypeptides, but the term is not limited to such cleavage 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., double-chain antibodies, three-chain antibodies, four-chain antibodies)), monovalent or multivalent antibody fragments (such as bivalent, trivalent, tetravalent and multivalent antibodies), mini antibodies, chelated recombinant antibodies, three antibodies or double antibodies, intracellular antibodies, nano antibodies, small modular immunopharmaceuticals (SMIP), binding domain immunoglobulin fusion proteins, camelized antibodies and antibodies comprising VHH. Additional examples of antigen-binding antibody fragments are known in the art.

[0148] The term "complementarity determining region" or "CDR" refers to short polypeptide sequences within the variable region 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 region of both heavy and light chain polypeptides that are not CDR sequences and are primarily responsible for maintaining the correct positioning of the CDR sequences to permit antigen binding. Although the framework region itself is typically not directly involved in antigen binding as known in the art, certain residues within the framework region of certain antibodies may be directly involved in antigen binding or may affect the ability of one or more amino acids in the CDR to interact with the antigen.

[0149] Exemplary of antibodies are anti-PCSK-9 mAb (eg, Alirocumab), anti-IL-6R mAb (eg, Sarilumab), and anti-IL-4R mAb (eg, Dupilumab).

[0150] Pharmaceutically acceptable salts of any API described herein are also contemplated for use in a drug or medicament in a drug delivery device. Pharmaceutically acceptable salts are, for example, acid addition salts and basic salts.

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

[0152] An example drug delivery device may involve a needle-based injection system as described in Table 1, 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 (partially or completely emptied) container systems. The container may be a replaceable container or an integrated non-replaceable container.

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

[0154] As further described in ISO 11608-1:2014 (E), a single-dose container system may relate to a needle-based injection device with a replaceable container. In one example of such a system, each container holds a single dose, thereby discharging the entire deliverable volume (completely emptying). In another example, each container holds a single dose, thereby discharging a portion of the deliverable volume (partially emptying). As also described in ISO 11608-1:2014 (E), a single-dose container system may relate to 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 discharging the entire deliverable volume (completely emptying). In another example, each container holds a single dose, thereby discharging a portion of the deliverable volume (partially emptying).

Claims

1. A computer-implemented method, the method include: executing a program for managing a plurality of medical conditions, the program including a consent module for managing access to patient-specific information; Define multiple user IDs within the program; Define multiple user roles within the program; assigning each user ID of the plurality of user IDs to one or more user roles of the plurality of user roles; Assigning each user role a permission level that defines access to that 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; as well as In response to receiving the request: Determining a user role assigned to the first user ID; and When the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information, the requested patient-specific information is transmitted to the external device.

2. The computer-implemented method of claim 1, in, The method further comprises: generating a notification prompting the user to prepare for an upcoming appointment; and In response to receiving a user interaction with the notification, a report is prepared that includes the patient-specific information.

3. A computer-implemented method according to claim 1 or claim 2, in, This patient-specific information is health-related data.

4. The computer-implemented method of any preceding claim, further comprising revoking a permission level assigned to a first role in the plurality of user roles.

5. A computer-implemented method according to any preceding claim, further comprising: include: defining a time limit associated with a permission level assigned to a first role in the plurality of user roles; as well as When the time limit is reached, the permission level assigned to the first role in the plurality of user roles is revoked.

6. The computer-implemented method of any preceding claim, further comprising assigning a permission level to a particular user ID of the plurality of user IDs.

7. The computer-implemented method of claim 6, further comprising: include: defining time limits associated with assigning permission levels to that particular user ID; as well as When the time limit is reached, the permission level assigned to that particular user ID is revoked.

8. A computer-implemented method according to any preceding claim, further comprising providing a consent template associating a first role of the plurality of roles with a predefined permission level.

9. A computer-implemented method according to any preceding claim, in, The plurality of user roles are selected from a list comprising at least two of: patient, physician, guardian, pharmacist, and dashboard observer.

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

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

12. A computer-implemented method according to any preceding claim, in, This patient-specific information is categorized into different sensitivity levels.

13. A computer-implemented method according to any preceding claim, in, The patient-specific information includes a plurality of resources, and wherein the method further includes assigning access rights to a subset of the plurality of resources, and wherein assigning permission levels includes granting access rights to the subset of the plurality of resources.

14. The computer-implemented method of claim 13, in, 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 diary entries.

15. A computer-implemented method according to claim 13 or claim 14, in, Each resource includes multiple fields of information.

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

17. The computer-implemented method of claim 16, in, These information fields include user name, user address, medication, and injection device type.

18. A non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: executing a program for managing a plurality of medical conditions, the program including a consent management module for managing access to patient-specific information; Define multiple user IDs within the program; Define multiple user roles within the program; assigning each user ID of the plurality of user IDs to one or more user roles of the plurality of user roles; Associating a permission level with each user role that defines access to that patient-specific information; receiving a request to transmit the patient-specific information to an external device, the request being associated with the first user ID; and In response to receiving the request: Determining a user role assigned to the first user ID; and When the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information, the requested patient-specific information is transmitted to the external device.

19. The non-transitory computer readable storage medium of claim 18, in, These instructions further cause the computer to: generating a notification prompting the user to prepare for an upcoming appointment; and In response to receiving a user interaction with the notification, a report is prepared that includes the patient-specific information.

20. A user device comprising a processing circuit system, the processing circuit system being configured to: executing a program for managing a plurality of medical conditions, the program including a consent management module for managing access to patient-specific information; Define multiple user IDs within the program; Define multiple user roles within the program; assigning each user ID of the plurality of user IDs to one or more user roles of the plurality of user roles; Associating a permission level with each user role that defines access to that patient-specific information; receiving a request to transmit the patient-specific information to an external device, the request being associated with the first user ID; and In response to receiving the request: Determining a user role assigned to the first user ID; and When the permission level assigned to the user role of the first user ID allows access to the requested patient-specific information, the requested patient-specific information is transmitted to the external device.

Images