WO2017136583A1 - Système d'adhésion à un traitement par hormone de croissance - Google Patents

Système d'adhésion à un traitement par hormone de croissance Download PDF

Info

Publication number
WO2017136583A1
WO2017136583A1 PCT/US2017/016267 US2017016267W WO2017136583A1 WO 2017136583 A1 WO2017136583 A1 WO 2017136583A1 US 2017016267 W US2017016267 W US 2017016267W WO 2017136583 A1 WO2017136583 A1 WO 2017136583A1
Authority
WO
WIPO (PCT)
Prior art keywords
patient
planned
dosage
growth hormone
administration
Prior art date
Application number
PCT/US2017/016267
Other languages
English (en)
Inventor
Eric HUMPHRISS
Keith LUI
Jeanne WILSON
Original Assignee
Versartis, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Versartis, Inc. filed Critical Versartis, Inc.
Publication of WO2017136583A1 publication Critical patent/WO2017136583A1/fr

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/40—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for data related to laboratory analysis, e.g. patient specimen analysis
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection

Definitions

  • rhGH recombinant human growth hormone
  • GHD growth hormone deficiency
  • rhGH recombinant human growth hormone
  • SC subcutaneous
  • Noncompliance can be significantly associated with reduced height velocity.
  • Fig. 1 is a block diagram of an exemplary system for hormone therapy management, consistent with embodiments of the present disclosure.
  • FIG. 2 is a block diagram of an exemplary computing device, consistent with embodiments of the present disclosure.
  • FIG. 3 is a block diagram of an exemplary electronic device, consistent with embodiments of the present disclosure.
  • FIG. 4 is a simplified block diagram illustrating an administration engine, consistent with embodiments of the present disclosure.
  • FIG. 5 is a simplified block diagram illustrating an administration logic module, consistent with embodiments of the present disclosure.
  • Figs. 6-10 are flowcharts representing exemplary methods for hormone therapy management, consistent with embodiments of the present disclosure.
  • Fig. 11 depicts an amino acid sequence for a long-acting growth hormone, consistent with disclosed embodiments.
  • Fig. 12 depicts a novel fusion protein with natural hydrophilic amino acid sequences attached to the N-and C-termini, consistent with disclosed embodiments.
  • Fig. 13 depicts dosing regimens for a long-acting growth hormone in a Phase lb/2a study evaluating three differing dosing regimens.
  • Fig. 14 depicts demographic characteristics and dosing regimens of patients enrolled in an open-label extension study.
  • Fig. 15 depicts treatment adherence of patients in an extension study.
  • the disclosed embodiments concern systems and methods for managing hormone therapy.
  • a long-acting hormone e.g., a long-acting human growth hormone
  • those administered to a subject less frequently than once per day e.g., injected once per week, every two weeks, every three weeks, every four weeks, twice a month (e.g. 15 days + 2 days) or once a month (e.g. 30 days+ 2 days).
  • growth hormone or “GH” means a growth hormone protein and species and sequence variants thereof, and includes, but is not limited to, the 191 single-chain amino acid sequence of human GH.
  • the GH can be the native, full-length protein or can be a truncated fragment or a sequence variant that retains at least a portion of the biological activity of the native protein.
  • hGH human GH
  • the 20kD HGH has an amino acid sequence that corresponds to that of 22kD hGH consisting of 191 amino acids except that 15 amino acid residues from the 32nd to the 46th of 22kD hGH are missing.
  • Some reports have shown that the 20kD hGH has been found to exhibit lower risks and higher activity than 22kD hGH.
  • the disclosed embodiments can use of the 22 kD, the 20kD hGH, as well as species and sequence variants and truncated fragments thereof as being appropriate for use as a fusion partner with other proteins in compositions.
  • the cloned gene for hGH has been expressed in a secreted form in Eschericha coli and its DNA and amino acid sequence has been reported.
  • Sequences with homology to GH sequences, sequence fragments that are natural, such as from humans and non-natural sequence variants that retain at least a portion of the biologic activity or biological function of GH and/or that are useful for preventing, treating, mediating, or ameliorating a GH-related disease, deficiency, disorder or condition in pediatric patients can be included in hGH-fusion protein compositions.
  • the hormone therapy may use a long-acting growth hormone.
  • the hormone therapy may use the long-acting growth hormone (SEQ ID NO: 1, FIG. 11), which includes a novel fusion protein (M.W. 119 kDa) with amino acid sequences (XTEN) attached to the N-and C-termini (FIG. 12).
  • SEQ ID NO: 1 the long-acting growth hormone
  • M.W. 119 kDa novel fusion protein
  • XTEN amino acid sequences
  • This long-acting growth hormone has rapid absorption and delayed clearance with a serum half-life >100 hours than rhGH in animals and adult GHD patients, as well as more durable insulin-like growth factor-1 (IGF-1 ) responses than those of previously studied rhGH products.
  • Compositions and methods related to VRS-317 are described in, for example, U.S. Patent No.
  • hGH long-acting variants of hGH include, but are not limited to LB03002, NNC126-0883, NNC0195-0092, MOD-4023, ACP-001, ACP-011, Lagova, hGH- CTP, Albutropin, ARX201, ALTU-238, PHA-794428, hGH-OctoDex, Nutropin Depot, Somatropin Biopartners, LAPS-hGH, NNC0195, TV-1 106 and profuse GH.
  • Treatment adherence refers to the extent to which a person's behavior coincides with medical or health advice.
  • Non-adherence to treatment presents a significant obstacle to achieving favorable health outcomes. For example, a patient may miss an injection because she forget or was unable to administer the medication. Once an injection is missed, the patient may be unable to determine a safe dosing schedule that transitions her back to the originally intended dosage and schedule. Because she cannot determine the appropriate administration date and administration amount, the patient may simply skip a dose. Skipping a dose may have significant negative effects when the doses are administered infrequently, for example when providing hormone therapy using a long-acting growth hormone.
  • Systems and methods are therefore required for automatically determining administration dates and administration dosages. These systems and methods may be configured to accommodate delayed or missed dosages, and may re-determine administration dosages and dates as necessary. These systems and methods may also enable a patient to receive patient medical information, instructional information, and external resource information. The disclosed systems and methods may notify the patients, caregivers, and healthcare providers of upcoming or missed administrations of the therapeutic agent. In this manner to disclosed systems and methods may not only help to improve treatment adherence, but may ultimately also enhance clinical outcome.
  • Fig. 1 is a block diagram representing exemplary system 100 for patient hormone therapy management, consistent with embodiments of the present disclosure.
  • the hormone therapy may comprise a long-acting growth hormone.
  • long-acting growth hormone refers to any growth hormone administered to a subject less frequently than once per day, e.g., injected once per week, every two weeks, every three weeks, every four weeks, twice a month (e.g. 15 days + 2 days) or once a month (e.g. 30 days+ 2 days).
  • System 100 can include data input engine 110 that can further include data extractor 11 1, data transformer 112, and data loader 113. Data input engine 110 can process data from data sources 101-104.
  • Data input engine 110 can also interact with data storage 120.
  • System 100 can include administration engine 130, app engine 141 , dashboard engine 143, and auxiliary device(s) 145.
  • System 100 can further include output terminals or displays 191 and 193.
  • This system may be accessible to users of a variety of languages. For example, the information provided by this system and the graphical user interfaces or other interfaces displayed by this system can be provided in English, Spanish, Japanese, French, German, or another suitable language.
  • each of data input engine 1 10, data extractor 111 , data transformer 1 12, data loader 1 13, administration engine 130, app engine 141, and dashboard engine 143, and auxiliary device(s) 145 can be a module, which is a packaged functional hardware unit (e.g., portions of an integrated circuit) designed for use with other components or a part of a program (stored on a computer readable medium) that performs a particular function of related functions.
  • a module which is a packaged functional hardware unit (e.g., portions of an integrated circuit) designed for use with other components or a part of a program (stored on a computer readable medium) that performs a particular function of related functions.
  • a server may provide software implementing the functionality of data input engine 1 10, data extractor 11 1, data transformer 1 12, data loader 113, administration engine 130, app engine 141, and dashboard engine 143, and/or auxiliary device(s) 145.
  • server can store a master copy of this software on a non- transitory computer readable medium of the server.
  • the server can receive a request from the device to download and/or install the software applications.
  • the server can transmit or distribute installation files for the software applications to the device.
  • the device after receiving the installation files from the server, the device can install a local copy of the software applications based on the installation files.
  • Data input engine 110 can be a module that retrieves data from a variety of data sources (e.g., data source 101, 102, 103, and 104) and process the data so that it can be used with the remainder of system 100.
  • Data input engine 110 can further include data extractor 1 11 , data transformer 1 12, and data loader 1 13.
  • Data extractor 1 11 retrieves data from data sources 101, 102, 103, and 104.
  • Each of these data sources can represent a different type of data source.
  • data source 101 can be a database.
  • Data source 102 can represent structured data.
  • Data sources 103 and 104 can be flat files. Further, data sources 101-104 can contain overlapping or completely disparate data sets.
  • data source 101 can contain information about a patient undergoing hormone therapy (e.g., medical record of the patient).
  • data source 101 can contain patient medical information. This patient medical information may include laboratory results; height; weight and height information; trunk or fat mass information; height velocity; body composition; pharmokinetic and pharmodynamic data; baseline IGF-1 levels, IGF-1 dose response data; treatment history information (e.g., medication adherence data, progress towards treatment goals).
  • Data source 101 can also include personalized administration information.
  • data source 101 may include at least one of a personalized base dosage of a therapeutic agent, a personalized
  • the personalized base dosage may be an expected dosage that depends on the patient information described above.
  • the personalized administration schedule may also depend on this information.
  • the personalized administration schedule may indicate administration of the therapeutic agent bi-weekly, weekly, bi-monthly, monthly, or at even greater intervals. The intervals may be constant, or may change. For example, multiple weekly intervals may be followed by two bi-weekly intervals, or several bi-weekly intervals may be followed by a weekly interval.
  • data sources 102, 103, and 104 can contain instructional information, external resource information, and gamification resources.
  • Instructional information can include information targeted to patients, caregivers, and other individuals that interact with a patient, such as teachers, classmates, and relatives.
  • such information can include instructional information about the therapy (e.g., how the therapeutic agent works), instructional information for administering the therapy, "Know your body animations"; growth hormone deficiency facts and answers to frequently asked questions; videos, books, or graphic novels describing patient experiences; discussion guides for patients and caregivers (e.g., when to initiate treatment for the condition using the therapy, what to expect from treatment and adherence, transitioning to self-care and to adult care); patient-oriented tips for talking to teachers, health care practitioners, classmates, friends, and other individuals; and medical terminology glossaries including growth hormone deficiency terminology.
  • instructional information about the therapy e.g., how the therapeutic agent works
  • instructional information for administering the therapy "Know your body animations"
  • growth hormone deficiency facts and answers to frequently asked questions videos, books, or graphic novels describing patient experiences
  • discussion guides for patients and caregivers e.g., when to initiate treatment for the condition using the therapy, what to expect from treatment and adherence, transitioning to self-care and to adult care
  • External resource information can include contact information for insurance providers, mentoring programs (e.g., programs that pair older and younger patients with the same or similar conditions), and clinicians. These contacts can be URLs, URIs, phone numbers, email addresses, post office addresses, or other contact information. External resource information can include external news sources, like news feeds (e.g., RSS feeds) concerning the condition or treatment, or patient newsletters. Clinician information can include lists of relevant healthcare providers (e.g., endocrinologists) and maps to clinics or other treatment centers. External resource information can include links to social media resources such a patient-, condition-, or treatment-oriented pages, profiles, or descriptors (e.g., hashtags).
  • Gamification resources can include online games or badges that encourage treatment adherence.
  • a patient may be associated with a point total, and additional points may be awarded for completing relevant actions, like attending checkups, taking medication, and filling out medical questionnaires. Points may also be subtracted from the point total for failure to take such relevant actions.
  • badges may be awarded for completing relevant actions.
  • a patient' s score and/or may be visible to other patients also using the system for hormone therapy management, or may be visible to the public. For example, a name or pseudonym of the patient may appear on a leaderboard, together with the point total and any badges.
  • Data extractor 1 1 1 can interact with the various data sources, retrieve the relevant data, and provide that data to data transformer 1 12.
  • Data transformer 112 can receive data from data extractor 11 1 and process the data into standard formats.
  • data transformer 1 12 can normalize data such as dates.
  • data source 101 can store dates in day-month-year format while data source 102 can store dates in year-month-day format.
  • data transformer 112 can modify the data provided through data extractor 1 1 1 into a consistent date format. Accordingly, data transformer 1 12 can effectively clean the data provided through data extractor 1 1 1 so that all of the data, although originating from a variety of sources, has a consistent format.
  • data transformer 1 12 can extract additional data points from the data. For example, data transformer can process a date in year-month-day format by extracting separate data fields for the year, the month, and the day. Data transformer can also perform other lineal" and non-linear transformations and extractions on categorical and numerical data such as normalization and demeaning. Data transformer 1 12 can provide the transformed and/or extracted data to data loader 1 13.
  • Data loader 1 13 can receive the normalized data from data transformer 112. Data loader 1 13 can merge the data into varying formats depending on the specific requirements of system 100 and store the data in an appropriate storage mechanism such as data storage 120.
  • Data storage 120 can be data storage for a distributed data processing system (e.g., Hadoop Distributed File System, Google File System, ClusterFS, and/or OneFS).
  • data storage 120 can be a Relational Database Management System (RDBMS) (e.g., Oracle Database, Microsoft SQL Server, MySQL, PostgreSQL, and/or IBM DB2), a non-relational database system (NRDBMS) (e.g., XML, Cassandra, CouchDB, MongoDB, Oracle NoSQL Database, FoundationDB, and/or Redis), or a graph database (e.g., Neo4j or Titan).
  • RDBMS Relational Database Management System
  • NRDBMS non-relational database system
  • data loader 1 13 can optimize the data for storing and processing in data storage 120.
  • information about a patient, external resource information, information about the condition and the therapy, and gamification resources can be stored by data loader 1 13 in data storage 120.
  • Administration engine 130 can facilitate treatment administration by providing relevant information. This information can be provided to another component of system 100 (e.g., app engine 141 , dashboard engine 143, auxiliary device(s) 145, and data storage 120). In some embodiments, administration engine 130 may determine the information provided using information retrieved from another component of system 100 (e.g., app engine 141, dashboard engine 143, auxiliary device(s) 145, and data storage 120). For example, administration engine 130 can determine planned dosages of a therapeutic agent and planned times of a therapeutic agent. This determination can be personalized based on the information about the patient obtained using data input engine 110, as described in detail below with regard to Fig. 5. Administration engine can also provide external resource information, information about the condition and the therapy, and gamification resources. This information can be provided in response to requests received from a user, as described below with regard to Fig. 9.
  • administration engine 130 may determine the information provided using information retrieved from another component of system 100 (e.g., app engine 141, dashboard engine 143, auxiliary device(s)
  • administration engine 130 can recommend an applicator for administering the dose (e.g., an injection pen, cartridge, or similar device containing the therapeutic agent). For example, administration engine 130 may determine that the patient requires a dose of 100 mg of the therapeutic agent. In this example, the therapeutic agent may be provided in single-use applicators with capacities of 50 mg, 100 mg, and 200 mg. The administration engine 130 can provide an indication that the patent should use the applicator with a 100 mg capacity for administering the dose.
  • an applicator for administering the dose e.g., an injection pen, cartridge, or similar device containing the therapeutic agent.
  • administration engine 130 may determine that the patient requires a dose of 100 mg of the therapeutic agent.
  • the therapeutic agent may be provided in single-use applicators with capacities of 50 mg, 100 mg, and 200 mg.
  • the administration engine 130 can provide an indication that the patent should use the applicator with a 100 mg capacity for administering the dose.
  • App engine 141 can facilitate output to display 191.
  • App engine 141 and display 191 can be part of the same device.
  • app engine 141 may communicate with other components of system 100 over a network or other communication system.
  • Display 191 can be, for example, a display associated with a computing device or electronic device.
  • this computing device or electronic device may be associated with a patient undergoing treatment.
  • this computing device may be owned, operated, or controlled by the patient, or a caregiver of the patient.
  • this computing device or electronic device may be associated with a healthcare provider.
  • this computing device may be owned, operated, or controlled by a practitioner coordinating or providing care to the patient.
  • App engine 141 may provide instructions to display 191 that facilitate the presentation of administration information, treatment progress information, personal health information, and product information (e.g., long-acting growth hormone information) to the patient, or a caregiver of the patient.
  • these instructions may cause display 191 to provide a graphical user interface.
  • This graphical user interface can display administration information, treatment progress information, personal health information, and product information (e.g., long-acting growth hormone information).
  • the graphical user interface can also display controls enabling a user to provide responses to displayed information, consistent with disclosed embodiments.
  • the graphical user interface may enable the user to provide actual administration information or patient information, or request display of administration information, treatment progress information, personal health information, and product information.
  • App engine 141 can enable a user to share information retrieved using system 100.
  • app engine 141 can be configured to allow users to share instructional infonnation and gamification resources retrieved using system 100.
  • users may create content, such as videos, and use app engine 141 to share this content with other accounts on system 100, or with external systems, such as social networks.
  • Dashboard engine 143 can facilitate output to display 193.
  • Dashboard engine 143 and display 193 can be part of the same device.
  • dashboard engine 143 may communicate with other components of system 100 over a network or other communication system.
  • Display 193 can be, for example, a display associated with a computing device or electronic device.
  • this computing device or electronic device may be associated with a healthcare provider.
  • this computing device may be owned, operated, or controlled by the healthcare provider.
  • Dashboard engine 143 may provide instructions to display 193 that facilitate the display information for configuring system 100. In some embodiments, these instructions may cause display 191 to provide a graphical user interface for configuring system 100.
  • a user may configure data input engine 110 to accept certain sources of information (e.g., data sources 101-104); access and/or modify data storage 120; access and/or modify user profiles for system 100 (e.g., by setting access privileges and available content);
  • sources of information e.g., data sources 101-104
  • data storage 120 e.g., data sources 101-104
  • user profiles for system 100 e.g., by setting access privileges and available content
  • dashboard engine 143 can enable a user to share information retrieved using system 100.
  • dashboard engine 143 can be configured to allow users to share instructional information and gamification resources retrieved using system 100.
  • users may create content, such as videos, and use dashboard engine 143 to share this content with other accounts on system 100, or with external systems, such as social networks.
  • Auxiliary device(s) 145 can be one or more devices that provide additional information regarding a patient undergoing hormone therapy management.
  • auxiliary device(s) 145 can be a scale that facilities communication of patient weight and/or body composition to other components of system 100, such as administration engine 130.
  • auxiliary device(s) 145 can be a delivery device for a therapeutic agent, such as an autoinjector, pump system, or similar device.
  • a therapeutic agent such as an autoinjector, pump system, or similar device.
  • Such a device may facilitate communication of an actual dose administered to the patient.
  • a device can explicitly or implicitly indicate the actual time and date the dose was administered.
  • the device can explicitly communicate the time or date to another component of system 100, or system 100 can record the day and time of the communication as the actual date and time of administration.
  • Fig. 2 is a block diagram of an exemplary computing device 200, consistent with embodiments of the present disclosure.
  • the functionality of system 100 can be implemented by a single computing device, multiple computing devices (to allow for distributed processing of the data), or a combination of computing devices and electronic devices as described in detail below with reference to Fig. 3.
  • computing device 200 can be a specialized server or workstation.
  • Computing device 200 can include one or more central processing units (CPUs) 203 and system memory 205. Computing device 200 can also include one or more graphics processing units (GPUs) 211 and graphic memory 213. Computing device 200 can include display device 209 and input/output (I/O) device(s) 217 (e.g., a keyboard, a mouse, or a pointing device) connected to I/O controller 207. Computing device 200 can include a network interface 201 to interface to a LAN, WAN, MAN, or the Internet. In some aspects, computing device 200 may be configured to implement an electronic diary.
  • CPUs central processing units
  • GPUs graphics processing units
  • GPUs graphic memory 213.
  • Computing device 200 can include display device 209 and input/output (I/O) device(s) 217 (e.g., a keyboard, a mouse, or a pointing device) connected to I/O controller 207.
  • I/O input/output
  • Computing device 200 can include a network interface 201 to interface to a
  • CPUs 203 can be single or multiple microprocessors, field-programmable gate arrays, or digital signal processors capable of executing sets of instructions stored in a memory (e.g., system memory 205), a cache, or a register.
  • CPUs 203 can contain one or more registers for storing variable types of data including, inter alia, data, instructions, floating point values, conditional values, memory addresses for locations in memory (e.g., system memory 205 or graphic memory 213), pointers and counters.
  • CPU registers can include special purpose registers used to store data associated with executing instructions such as an instruction pointer, instruction counter, and/or memory stack pointer.
  • CPUs 203 can execute
  • system memory 205 or other memory, operate on data stored in memory (e.g., system memory 205), communicate with GPUs 211 , and provide output via I/O device(s) 217 (e.g., through a printer, speakers, or other output devices).
  • System memory 205 can include a tangible and/or non-transitory computer-readable medium, such as a flexible disk, a hard disk, a compact disk read-only memoiy (CD-ROM), magneto-optical (MO) drive, digital versatile disk random-access memory (DVD-RAM), a solid-state disk (SSD), a flash drive and/or flash memory, processor cache, memory register, or a semiconductor memoiy.
  • System memory 205 can be one or more memory chips capable of storing data and allowing direct access by CPUs 203.
  • System memory 205 can be any type of random access memory (RAM), or other available memory chip capable of operating as described herein.
  • GPUs 21 1 can be any type of specialized circuitry that can manipulate and alter memory (e.g., graphic memory 213) to provide and/or accelerate the creation of images.
  • GPUs 211 can store images in a frame buffer for output to a display device such as display device 209.
  • GPUs 211 can have a highly parallel structure optimized for processing large, parallel blocks of graphical data more efficiently than general purpose CPUs 203.
  • GPUs 21 1 can be included in a chipset of a special purpose processing unit or a co-processor.
  • GPUs 211 can execute sets of instructions stored in memory (e.g., system memory 205), to manipulate graphical data stored in system memory 205 or graphic memory 213.
  • CPUs 203 can provide instructions to GPUs 211, and GPUs 211 can process the instructions to render graphics data stored in the graphic memory 213.
  • Graphic memory 213 can be any memory space accessible by GPUs 211, including local memory, system memory, on-chip memories, and hard disk.
  • GPUs 1 1 can enable displaying of graphical data stored in graphic memory 213 on display device 209.
  • System interface 219 can bridge communication between the various components of computing device 200. It is appreciated that CPUs 203 can also communicate with system memory 205 and other devices in manners other than through system interface 219, such as through serial communication or direct point-to-point communication. Similarly, GPUs 21 1 can communicate with graphic memory 213 and other devices in ways other than system interface 219. In some embodiments, CPUs 203, GPUs 211, system interface 219, or any combination thereof, are integrated into a single chipset or processing unit.
  • Network interface 201 can facilitate connections including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.21 , Tl, T3, 56 kb, X.25), broadband connections (e.g., ISDN, Frame Relay, ATM), wireless connections, or some combination of any or all of the above.
  • Network interface 201 can comprise a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interfacing computing device 200 to any type of network capable of communication and performing the operations described herein.
  • a computing device can implement data input engine 110.
  • processors e.g., CPUs 203 and GPUs 211
  • memory e.g., system memory 205, storage 215, and graphic memory 213.
  • Such memory can store computer-readable instructions for execution by processors to perform a variety of functions on computing device 200.
  • these software modules can include software applications for providing additional functionality to computing device 200, as described in detail below with in reference to Fig. 4.
  • such software applications can be designed to interface with a system for hormone therapy management, such as system 100 above.
  • such computing device can implement data input engine 110 by obtaining data from data sources 101 -104 (e.g., using I/O device(s) 217 and/or network interface 201). Further, computing device 200 can store this data during processing (e.g., using storage 215 and/or system memory 205). Moreover, computing device 200 can implement data storage 120 (e.g., using storage 215 and/or system memory 205, or another remote computing device). Similarly, computing device 200 can implement administration engine 130, app engine 141, and dashboard engine 143 (e.g., using storage 215 and/or system memory 205 for storing data and I/O device(s) 217 or network interface 201 for transmitting and/or receiving data).
  • data input engine 110 by obtaining data from data sources 101 -104 (e.g., using I/O device(s) 217 and/or network interface 201). Further, computing device 200 can store this data during processing (e.g., using storage 215 and/or system memory 205). Moreover, computing device 200 can implement data storage 120
  • Computing device 200 can be configured to implement display 191 and/or display 193, for example using display device 209.
  • app engine 141 and display 191 can be part of the same device.
  • app engine 141 can directly connect to system 100 or can be connected to system 100 over a network or other communication system. This connection can be provided by, for example, network interface 201 or I/O devices 217.
  • system 100 can include app engine 141 , and app engine 141 can provide a visual representation to display 191 using a network or some other communication link.
  • display 190, or components connected to display 190 can accept user input and provide that input to app engine 141. For example, user input can be captured by I/O devices 217 or network interface 201 of device 200.
  • additional computing devices can implement auxiliary devices 145.
  • a scale that facilitates communication of body weight and/or body composition may be implemented using an additional computing device.
  • an injector that facilitates communication of an actual amount injected may be implemented using an additional computing device.
  • auxiliary device(s) 145 can be configured to communicate with the other components of system 100 using I/O devices (e.g., I/O device(s) 217) or network interfaces (e.g., network interface 201 ).
  • Fig. 3 is a simplified block diagram illustrating an example electronic device 300, consistent with embodiments of the present disclosure.
  • the functionality of system 100 can be implemented by a single electronic device, multiple electronic device (to allow for distributed processing of the data), or a combination of electronic device and computing devices as described in detail above with reference to Fig. 2.
  • electronic device 300 can include a communication device having two-way or one-to-many data communication capabilities, audio communication capabilities, and/or video communication capabilities, and the capability to communicate with other computer systems, for example, via the Internet.
  • electronic device 300 may be a handheld device, a multiple-mode communication device configured for both data and voice communication, a smartphone, a mobile telephone, a laptop, a computer wired to the network, a netbook, a gaming console, a tablet, a smart watch, or a PDA enabled for wireless communication.
  • electronic device 300 may be configured to implement an electronic diary.
  • Electronic device 300 can include a case (not shown) housing component of electronic device 300.
  • the internal components of electronic device 300 can, for example, be constructed on a printed circuit board (PCB).
  • PCB printed circuit board
  • Electronic device 300 can include a controller comprising at least one processor 302 (such as a microprocessor), which controls the overall operation of electronic device 300.
  • processor 302 can be one or more microprocessors, field programmable gate arrays (FPGAs), digital signal processors (DSPs), or any combination thereof capable of executing particular sets of instructions.
  • Processor 302 can interact with device subsystems such as a
  • communication subsystem 304 for exchanging radio frequency signals with a wireless network to perform communication functions.
  • Processor 302 can also interact with additional device subsystems including a communication subsystem 304, a display 306 (e.g., a liquid crystal display (LCD) screen, a touch-screen display, or any other appropriate display), input devices 308 (e.g., a keyboard, a stylus, or control buttons), a persistent memory 310, a random access memory (RAM) 312, a read only memory (ROM) 314, auxiliary input/output (I/O) subsystems 316, a data port 318 (e.g., a conventional serial data port, a Universal Serial Bus (USB) data port, a 30-pin data port, a Lightning data port, or a High-Definition Multimedia Interface (HDMI) data port), a speaker 320, a microphone 322, camera 324, a short-range wireless communications subsystem 326 (which can employ any appropriate wireless (e.g., RF), optical, or other short range communications technology (for example, Bluetooth or NFC)), and other device subsystem
  • Communication subsystem 304 includes one or more communication systems for communicating with a network to enable communication with other external systems or devices (e.g., a server, not shown).
  • the particular design of communication subsystem 304 depends on the wireless network in which electronic device 300 is intended to operate (e.g., wireless network 304a).
  • Electronic device 300 can send and receive communication signals over the wireless network after the required network registration or activation procedures have been completed.
  • display 306 can be a touch-screen display.
  • the touch-screen display can be constructed using a touch-sensitive input surface, which is coupled to an electronic controller and which overlays the visible element of display 306.
  • the touch- sensitive overlay and the electronic controller provide a touch-sensitive input device and processor 302 interacts with the touch-sensitive overlay via the electronic controller.
  • Camera 324 can be a CMOS camera, a CCD camera, or any other type of camera capable of capturing and outputting compressed or uncompressed image data such as still images or video image data.
  • electronic device 300 can include more than one camera, allowing the user to switch, during a video conference call, from one camera to another, or to overlay image data captured by one camera on top of image data captured by another camera.
  • Image data output from camera 324 can be stored in, for example, an image buffer, which can be a temporary buffer residing in RAM 312, or a permanent buffer residing in ROM 314 or persistent memory 310.
  • the image buffer can be, for example, a first-in first-out (FIFO) buffer.
  • Short-range wireless communications subsystem 326 is an additional optional component that provides for communication between electronic device 300 and different systems or devices, which need not necessarily be similar devices.
  • short-range wireless communications subsystem 326 can include an infrared device and associated circuits and components, or a wireless bus protocol compliant communication device such as a Bluetooth® communication module to provide for communication with similarly-enabled systems and devices.
  • Processor 302 can be one or more processors that operate under stored program control and executes software modules 330 stored in a tangibly-embodied non-transitory computer-readable storage medium such as persistent memory 310, which can be a register memory, a processor cache, a Random Access Memory (RAM), a flexible disk, a hard disk, a CD-ROM (compact disk-read only memory), and MO (magneto-optical), a DVD-ROM (digital versatile disk-read only memory), a DVD RAM (digital versatile disk-random access memory), or other semiconductor memories.
  • persistent memory 310 can be a register memory, a processor cache, a Random Access Memory (RAM), a flexible disk, a hard disk, a CD-ROM (compact disk-read only memory), and MO (magneto-optical), a DVD-ROM (digital versatile disk-read only memory), a DVD RAM (digital versatile disk-random access memory), or other semiconductor memories.
  • persistent memory 310 can be a register memory, a processor cache,
  • Software modules 330 can also be stored in a computer-readable storage medium such as ROM 314, or any appropriate persistent memory technology, including EEPROM, EAROM, FLASH. These computer-readable storage mediums store computer-readable instructions for execution by processor 302 to perform a variety of functions on electronic device 300. Alternatively, functions and methods can also be implemented in hardware components or combinations of hardware and software such as, for example, ASICs and/or special purpose computers.
  • Software modules 330 can include operating system software 332, used to control operation of electronic device 300. Additionally, software modules 330 can include software applications 334 for providing additional functionality to electronic device 300. For example, software applications 334 can include applications designed to interface with systems like system 100 above (e.g., software applications 334 can include implementations of app engine 170, dashboard engine 180, and graph visualization engine 135 described above in reference to Fig. 1).
  • Software applications 334 can also include a range of applications, including, for example, an e-mail messaging application, an address book, a notepad application, an Internet browser application, a voice communication (i.e., telephony or Voice over Internet Protocol (VoIP)) application, a mapping application, a media player application, a health-related application, a benefits-related application, etc.
  • Each of software applications 334 can include layout information defining the placement of particular fields and graphic elements (for example, text fields, input fields, icons, etc.) in the user interface (e.g., user interfaces 300 shown in Fig. 3) according to that corresponding application.
  • Operating system software 332 can provide a number of application protocol interfaces (APIs) providing an interface for communicating between the various subsystems and services of electronic device 300, and software applications 334.
  • APIs application protocol interfaces
  • operating system software 332 provides a user interface API to any application that needs to create user interfaces for display on electronic device 300.
  • Accessing the user interface API can provide the application with the functionality to create and manage screen windows and user interface controls, such as text boxes, buttons, and scrollbars; receive mouse and keyboard input; and other functionality intended for display on display 306.
  • a camera service API can allow a video communication application to access camera 324 for purposes of capturing image data.
  • a patient using system 100 may capture image data as part of a video describing their personal experiences, including their experiences with at least one of the condition, the therapy, or system 100. Such image data that can be shared using a social networking service.
  • persistent memory 310 stores data 336, including data specific to a user of electronic device 300, such as patient medical information, instructional information, external resource information, and gamification resources. Persistent memory 310 can further store data relating to various applications with preferences of the particular user of, for example, electronic device 300.
  • persistent memory 310 can store data 336 linking a user's data with a particular Field of data in an application, such as for automatically entering a user's name into a username textbox on an application executing on electronic device 300.
  • data 336 can also include service data comprising information required by electronic device 300 to establish and maintain communication with a network.
  • auxiliary input/output (I/O) subsystems 316 comprise an external communication link or interface, for example, an Ethernet connection.
  • auxiliary I/O subsystems 316 can further comprise one or more input devices, including a pointing or navigational tool such as a stylus, a clickable trackball or scroll wheel or thumbwheel, or a human finger; and one or more output devices, including a mechanical transducer such as a vibrator for providing vibratory notifications in response to various events on electronic device 300 (for example, receipt of a notification or a message or an incoming phone call), or for other purposes such as haptic feedback (touch feedback); or any combination thereof.
  • a pointing or navigational tool such as a stylus, a clickable trackball or scroll wheel or thumbwheel, or a human finger
  • output devices including a mechanical transducer such as a vibrator for providing vibratory notifications in response to various events on electronic device 300 (for example, receipt of a notification or a message or an incoming phone call), or for other purposes such as hap
  • electronic device 300 can also include one or more removable memory modules 338 (e.g., FLASH memory) and a memory interface 340.
  • Removable memory module 338 can store information used to identify or authenticate a user or the user's account to a wireless network.
  • removable memory module 338 is referred to as a Subscriber Identity Module (SIM).
  • SIM Subscriber Identity Module
  • Memory module 338 can be inserted in or coupled to memory module interface 340 of electronic device 300 in order to operate in conjunction with the wireless network.
  • Electronic device 300 can also include a battery 342, which furnishes energy for operating electronic device 300.
  • Battery 342 can be coupled to the electrical circuitry of electronic device 300 through a battery interface 344, which can manage such functions as charging battery 342 from an external power source (not shown) and the distribution of energy to various loads within or coupled to electronic device 300.
  • a set of applications that control basic device operations can be installed on electronic device 300 during or after manufacture. Additional applications or upgrades to operating system software 332 or software applications 334 can also be loaded onto electronic device 300 through a wireless network, auxiliary I/O subsystem 316, data port 318, short-range wireless communication subsystem 326, or other suitable subsystem such as 328.
  • the downloaded programs or code modules can be permanently installed, for example, written into the persistent memory 310, or written into and executed from RAM 312 for execution by processor 302 at runtime.
  • Electronic device 300 can provide three principal modes of communication: a data communication mode, a voice communication mode, and a video communication mode.
  • a received data signal such as a text message, an e-mail message, Web page download, VoIP data, or an image file are processed by communication subsystem 304 and input to processor 302 for further processing.
  • a downloaded Web page can be further processed by a browser application, or data obtained from social networking services can be processed by a unified social networking application and output to display 306.
  • a user of electronic device 300 can also compose data items, such as contents for sharing using social networking services, e-mail messages, for example, using the input devices, such as auxiliary I/O subsystem 316, in conjunction with display 306.
  • electronic device 300 provides telephony functions and operates as a typical cellular phone.
  • electronic device 300 provides video telephony functions and operates as a video teleconference terminal.
  • electronic device 300 utilizes one or more cameras (such as camera 324) to capture video for the video teleconference.
  • Fig. 4 is a simplified block diagram illustrating components of administration engine 130.
  • Administration engine 130 can include, among other things, an account manager 410, an authentication module 420, a communication module 430, an input/output module 450, an administration logic module 470, and a services module 490. It will be readily appreciated that the particular apportionment of functionality between the disclosed components is not intended to be limiting. Therefore additional components can be added, and existing components can be removed, combined and/or divided without departing from the envisioned embodiments.
  • account manager 410 can enable a user to manage user accounts associated with the disclosed system for hormone therapy management.
  • Account manage 410 can facilitate creation of at least four types of accounts. These account types may include administrator accounts, healthcare provider accounts, caregiver accounts, and patient accounts.
  • patient accounts may be further divided into adult accounts and pediatric accounts. Multiple accounts may be linked to a patient. For example, a pediatric patient account (corresponding to the patient undergoing treatment), two caregiver accounts (e.g., corresponding to parents of the patient), and multiple healthcare provider accounts (e.g., correspond to a primary care physician, an endocrinologist, a nurse practitioner, etc.) may all be linked to a patient.
  • a pediatric patient account corresponding to the patient undergoing treatment
  • two caregiver accounts e.g., corresponding to parents of the patient
  • multiple healthcare provider accounts e.g., correspond to a primary care physician, an endocrinologist, a nurse practitioner, etc.
  • a component of administration engine may require that users with accounts provide contact information.
  • Each of these accounts may include differing restrictions on functionality and information provided.
  • a pediatric account may be able to access certain instructional information, and some gamification resources, but may not be able to access the information about the patient.
  • a pediatric account may be able to use system 100 to determine a planned dosage and planned administration date.
  • a caregiver account may have additional privileges, such as being able to re-determine a planned dosage and planned administration date, in the event that a dosage is missed.
  • a caregiver account may also be able to report actual dosages and dates of • administration to system 100.
  • Healthcare provider accounts may have additional privileges, such as additional access to information about the patient.
  • Administrator accounts may be able to configure system 100, for example by creating or deleting accounts, by linking accounts to patients, or changing account privileges, but may not be able to view information about patients in each account.
  • Caregiver accounts and healthcare provider accounts may be linked to multiple patients.
  • a parent may have multiple children with the condition, and a healthcare provider may be responsible for managing the treatment of multiple patients.
  • User accounts may have multiple types.
  • an account may be a caregiver account with respect to a first patient, and a patient account with respect a second patient.
  • the parent of a child with a condition may also have that condition.
  • Authentication module 420 can facilitate authentication of user credentials for users of system 100.
  • authentication module 420 may require users to provide credentials, such as a user name, a password, a token, a passcode, a pin number, etc., for establishing the identity of the user and for accessing user accounts of system 100.
  • Authentication module 420 can receive such credentials via, for example, input/output module 450 from the user. After receiving such credentials, authentication module 420 can authenticate the user according to methods known to one of skill in the art (e.g., challenge handshake authentication protocol or password authentication protocol). Alternatively, authentication module 420 can be configured to redirect a client device to a central authentication server, and may receive authentication or verification information provided by the central authentication server that indicates the user has successfully established her identity.
  • methods known to one of skill in the art e.g., challenge handshake authentication protocol or password authentication protocol.
  • authentication module 420 can be configured to redirect a client device to a central authentication server, and may receive authentication or verification information provided by the central authentication server that indicates the user has successfully established her identity.
  • Communication module 430 can facilitate communications between components of system 100.
  • a computing device e.g., computing device 200
  • an electronic device e.g., electronic device 300
  • communication module 430 can facilitate communications between the computing device and the electronic device using, for example, HTTP protocols, TCP protocols, Asynchronous JavaScript and XML (AJAX), UDP protocols, etc.
  • communication module 430 may facilitate provision of reminders regarding to administration of the therapeutic agent to at least one of a patient, a caregiver of the patient, and a healthcare provider of the patient.
  • Input/output module 450 can facilitate interactions between system 100 and users interacting with a display and associated input/output devices (e.g., display 191 and display 193). For example, input/output module 450 can cause electronic device to display a variety of user interfaces. Input/output module 450 can also detect, via the user interfaces, user inputs, obtain these user inputs, and/or store the user inputs.
  • input/output module 450 can cause electronic device to display a variety of user interfaces.
  • Input/output module 450 can also detect, via the user interfaces, user inputs, obtain these user inputs, and/or store the user inputs.
  • Administration logic module 470 can facilitate determination of dosages and administration dates of the therapeutic agent. Administration logic module 470 may use patient medical information in making these determinations. Administration logic module 470 can also facilitate re-determination of dosages and administration dates. For example, administration logic module 470 may re-determine dosages and administration dates when the user fails to administer the therapeutic agent in the planned amount or on the planned date and time. In some aspects, administration logic module 470 may be configured to determine a location of administration.
  • Administration logic module 470 may be configured to provide reminders to users with accounts linked to the patient. For example, Administration logic module 470 may use communication module 430 to contact users linked to a patient using the account contact information obtained by account manager 410. In some embodiments, administration logic module 470 may be agnostic to the form and content of the notification, which may be determined by communication module 430 based on the available contact information. For example, when the contact information includes a phone number, an SMS message indicating the failure to administer the therapeutic agent as planned may be provided. When the contact information includes an email address, an email message further including information about the planned dosage and planned administration date may be provided. As least one of administration logic module 470 and communication module 430 may have predetermined messages for use in such notifications.
  • administration engine 130 can also include services module 490.
  • Services module 490 can provide advertising and/or other services associated with administration engine 130.
  • services module 490 can facilitate the display of advertisements (e.g., banner advertisements, full screen advertisements, pop-up advertisements, etc.) on one or more of user interfaces.
  • Services module 490 can also provide other services, such as enabling users to make payments, directing users to the advertisers' websites or mobile applications, directing users to the Apple iTunes store, etc. It is appreciated that services module 490 can also perform or facilitate to perform any desired services associated with administration engine 130.
  • Fig. 5 is a simplified block diagram illustrating components of administration logic module 470.
  • administration logic module 470 can comprise modeling module 510, patient information module 530, and scheduling module 550. These components can estimate the response of the patient to administration of the therapeutic agent. It will be readily appreciated that the particular apportionment of functionality between the disclosed components is not intended to be limiting. Therefore additional components can be added, and existing components can be removed, combined and/or divided without departing from the envisioned embodiments.
  • Modeling module 510 can determine the administration dosage and administration date using one or more models, consistent with disclosed embodiments. Using these models, modeling module 510 can determine the administered dosage likely to cause, as a non- limiting example, a 1-1.2 standard deviation score (SDS) increase in average IGF-1 standard deviation score over the dosing interval. Moreover, modeling module 510 can determine the administered dosage likely to cause a normal range baseline IGF-1 SDS. These models can be personalized to the patient, for example incorporating information about the height, weight, age, duration of disease, baseline IGF-1 levels, IGF-1 dose response data and other prior treatment response data for the patient.
  • SDS standard deviation score
  • These models can be personalized to the patient, for example incorporating information about the height, weight, age, duration of disease, baseline IGF-1 levels, IGF-1 dose response data and other prior treatment response data for the patient.
  • the models may distinguish between pediatric patients and adult patients.
  • modeling module 510 can use weight-based dosage factors for the long-acting growth hormone in pediatric patients. Modeling module 510 can use smaller weight-based dosage factors for adult patients than for pediatric patients. In some aspects, modeling module 510 may not use weight-based dosage factors for adult patients.
  • Model 510 may determine higher doses of the long-acting growth hormone for adult patients with lower baseline IGF-1 SDS (e.g., patients with baseline IGF-1 SDS ⁇ -1).
  • modeling module 510 may determine higher doses of the long-acting growth hormone for adult patients with more years since diagnosis (e.g., patents with more than 5 years since diagnosis, more than 10 years since diagnosis, or more than 15 years since diagnosis). In some aspects, modeling module 510 may determine higher doses of the long-acting growth hormone for older adult patients. Thus modeling module 510 may be configured to assume a lesser sensitivity to the long-acting growth hormone when determining the planned dosage for adult patients with lower baseline IGF-1 SDS.
  • modeling module 510 may be configured to assume a greater sensitivity to the long-acting growth hormone when determining the planned dosage for pediatric patients with lower baseline IGF-1 SDS. In some aspects, modeling module 510 may determine higher doses of the long-acting growth hormone for older pediatric patients.
  • the models can be expressed using mathematical relationships. For example, they may be expressed using black box or biologically inspired models.
  • Modeling module 510 can track patient medical information, and use this patient medical information in the models.
  • modeling module 510 can track pharmokinetic and pharmodynamic data of the patient, including at least one of (i) the long-acting growth hormone concentration in the plasma of the patient, (ii) the IGF-1 concentration in the plasma of the patient, and (iii) the IGF-1 dose response for the patient.
  • Modeling module 510 can determine, in some aspects, the administered dosage using a pharmodynamic relationship between the administered dosage and the concentration of IGF-1 in the plasma of the patient.
  • the estimated dosage may depend in part on at least one of the maximal IGF-1 standard deviation score, maximal change in baseline of the IGF-1 SDS, and mean change in baseline of the IGF-1 SDS.
  • modeling module 510 may use a linear approximation of this pharmodynamic relationship in determining the planned dosage. Moreover, this linear approximation can depend on the administration schedule.
  • Modeling module 510 can additionally or alternatively determine, in some aspects, the planned dosage by estimating pharmacokinetic parameters of the patient. For example, modeling module 510 can estimate the concentration of the therapeutic agent in the plasma of the patient over time. Modeling module 510 can use this concentration to estimate the effect of the therapeutic agent on the patient. In some aspects, modeling module 510 can estimate this concentration using a one-compartment elimination model with a first-order input (e.g., administration of the therapeutic agent). As an additional example, modeling module 510 can use approximate relationships between the administered dosage and this concentration. For example, the administered dosage can correlate to the area under the concentration curve (AUC) of the therapeutic agent in the plasma of the patient over the dosing period.
  • AUC area under the concentration curve
  • the administered dosage can correlate to the peak concentration (C max ) of the therapeutic agent in the plasma of the patient. These correlations may be linear in the logarithm of the correlated variables.
  • the logarithm of the administered dosage can be linearly related to at least one of the logarithm of AUC and the logarithm of C max .
  • the models can be expressed as sets of rules for administering the therapeutic agent.
  • a model can indicate that a dose may be provided at the originally planned dosage within a two-day window on either side of the planned
  • a model can indicate that when a dose is administered at the original dosage more than five days after the planned administration date the amount of the next schedule dosage must be reduced. Furthermore, a model can indicate that the personalized base dosage must be scaled based on the most recently obtained weight of the patient.
  • the model may also calculate adjustments to the planned administration dosage based on a measured height, or height velocity, of the patient. For example, when the patient does not appear to be progressing towards treatment goals the planned dosage may be increased.
  • the model can also calculate adjustments to the planned administration dosage based on at least one of patient weight, patient body composition, IGF-1 concentration in the plasma of the patient, accumulation of long-acting growth hormone, and the peak and duration of an IGF-1 response to the long-acting growth hormone.
  • the models may be initialized for a patient using a dosing study.
  • a dosing study For example, an ascending dose study, in which the patient receives progressively greater dosages up to some maximum value, may be used to parameterize the models. It would be appreciated that other study designs may also be used to parametrize the models.
  • Modeling module 510 can re-determine the next scheduled dosage and administration date in response to an indication that a planned administration of the therapeutic agent did not occur. In some embodiments, this indication may be received from at least one of app engine 141 , data input engine 1 10, and dashboard engine 143. Modeling module 510 can also determine a location on the patient for administering the therapeutic agent. This
  • modeling module 510 can determine the next administration location as the back of the patient's right upper arm.
  • Patient infonnation module 530 can be configured to provision modeling module 510 with patient information. As described above, modeling module 510 can use this information to determine the planned administration dosage and administration date of the therapeutic agent.
  • patient information module 530 can retrieve patient medical information from data storage 120.
  • patient information module 530 can receive patient medical information provided by app engine 141 and/or dashboard 143. Information retrieved from data storage 120 or received from one of app engine 141 and/or dashboard 143 can be provided to data module 10 upon receipt, or may be stored by patient information module 530 until needed.
  • Patient information module 530 may be configured to process the retrieved information into a format useable by modeling module 10.
  • Scheduling module 550 can be configured to provision modeling module 510 with schedule information.
  • This scheduling information can describe a predetermined sequence of administrations.
  • a schedule can specify a sequence of administration dates.
  • a schedule can specify a starting date and an interval between administrations, or a sequence of intervals between administrations.
  • modeling module 510 can use this information to determine the planned administration dosage and administration date of the therapeutic agent.
  • scheduling module 550 can retrieve scheduling information from data storage 120.
  • scheduling module 550 can receive patient medical information provided by app engine 141 and/or dashboard 143.
  • Scheduling information retrieved from data storage 120 or received from one of app engine 141 and/or dashboard 143 can be provided to data module 510 upon receipt, or may be stored by patient information module 530 until needed.
  • Patient information module 530 may be configured to process the retrieved information into a format useable by modeling module 510.
  • Fig. 6 is a flowchart representing an exemplary method 600 for hormone therapy management. It will be readily appreciated that the illustrated procedure can be altered to delete steps or further include additional steps.
  • an administration engine e.g., administration engine 130
  • a computing device e.g., computing device 200
  • an electronic device e.g., electronic device 300
  • personalized administration information may concern a therapeutic agent, such as a hormone.
  • this personalized administration information may concern a long-acting growth hormone.
  • the personalized administration information may include a personalized base dosage of the therapeutic agent. This therapeutic base dosage may depend upon patient medical information, as described above with reference to Figs. 1, 4 and 5.
  • the personalized administration information may also include a personalized administration schedule.
  • This personalized administration schedule may specify predetermined administration dates, or may specify an interval between administrations. As described above with reference to Figs. 1, 4 and 5, this schedule may specify administration of the therapeutic agent on a bi-weekly, weekly, bi-monthly, or monthly basis. The scheduled intervals between administrations may vary.
  • the administration engine can cause the computing device and/or electronic device to determine (step 630) a planned date for administering the therapeutic agent to a patient.
  • the planned date can be based on the personalized administration schedule, and the planned date can correspond to the next administration date in the personalized administration schedule.
  • the planned date can differ from the next administration date in the personalized administration schedule.
  • the personalized administration schedule may describe a two week interval between administrations of the therapeutic agent.
  • the patient may have failed to receive the scheduled dose of the therapeutic agent five days earlier. This failure may cause the administration engine to determine one or more new administration dates.
  • the administration engine can determine adjustments to the next two scheduled dates. An additional administration date may be added for the current day, and the next scheduled administration date may be pushed back two days. In this manner, the administration engine can determine administration days that gradually return the patient to the planned administration schedule.
  • the administration engine can cause the computing device and/or electronic device to determine (step 640) a planned dosage of the therapeutic agent.
  • the planned dosage can depend on the personalized base dosage.
  • the personalized base dosage in turn, can depend on patient medical information, and may be determined by a healthcare practitioner. As a non-limiting example, the healthcare practitioner can determine this personalized base dosage based on the weight of the patient and a dosage factor. This dosage factor can depend on the length of time since initiation of the therapy, and the personalized administration schedule.
  • this dosage factor when a patient has undergone less than 6 months of treatment, this dosage factor can be 1.15 mg/kg for a patient on a weekly administration schedule, 2.5 mg/kg for a patient on a bi-monthly administration schedule, and 5.0 mg / kg for a patient on a monthly administration schedule. As an additional example, when a patient has undergone more than 6 months of treatment, this dosage factor can also be 3.5 mg/kg for a patient on a bi-monthly schedule.
  • a component of system 100 e.g., administration engine 130
  • the planned dosage may also depend on the planned date.
  • the administration engine when the administration engine causes the computing device and/or electronic device to re-determine one or more planned dates for administering the therapeutic agent to a patient, this may affect the planned dosage.
  • the administration engine can also determine adjustments to the next two schedule dosages.
  • the administration engine may cause the computing device and/or electronic device to determine an increment to the planned dosage for the newly added, additional administration date, and determine a decrement to the next, delayed administration date. In this manner, the administration engine can determine administration dosages that gradually return the patient to the planned administration dosage.
  • This dosage can also depend on other patient medical information, as described above with regard to Figs. 1, 4, and 5.
  • the dosage factor can depend on the duration of disease, the accumulation of long-acting growth hormone, and/or the peak and duration of an IGF-1 response to the long-acting growth hormone.
  • administration engine can also cause the computing device and/or electronic device to determine one or more planned dates based on one or more planned dosages.
  • administration engine may also specify times for administration of the therapeutic agent. Such times may be general (e.g., morning, afternoon, evening, nighttime), specific (e.g., 10:00 AM, 10.00 PM), or relative to other activities of daily living (e.g., after lunch, before dinner, before bed).
  • the administration engine can cause the computing device and/or electronic device to provide (step 650) an indication of the planned date and the planned dosage. Such an indication can be provided to the contact information for one or more accounts linked to the patient.
  • an account manager e.g., account manager 410
  • An administration logic module e.g., administration logic module 470
  • a communication module e.g., communication module 430
  • the administration engine can facilitate provision of these reminders in advance of the planned administration date. These reminders may be provided multiple times.
  • a first reminder may be provided using contact information associated with a caregiver two days in advance. Another reminder may be provided to the patient and the caregiver on the day of administration.
  • the administration engine can cause the computing device and/or electronic device to track prior administration locations. Such information about prior administration locations can be received using at least one of a data input engine (e.g., data input engine 110), an app engine (e.g., app engine 141), a dashboard engine (e.g., dashboard engine 143), and one or more auxiliary devices (e.g., auxiliary device(s) 145).
  • the administration engine can determine a planned administration location. This planned administration location can be a location where the patient has not recently administered the therapeutic agent. For example, when the last four dosages were administered to the left abdomen, the right thigh, the back of the upper left arm, and the left upper buttock, the administration engine can determine the planned
  • administration engine can depend on a set of potential locations.
  • This set of potential locations can be created, modified, or deleted based on input received by system 100 using at least one of the data input module, the app engine, and the dashboard engine.
  • This set of potential locations can be stored by the computing device and/or the electronic device.
  • this set of potential locations can be stored by a patient information module (e.g., patient information module 530) and provided to a modeling module (e.g., modeling module 510), which can determine the planned location.
  • a patient information module e.g., patient information module 530
  • modeling module e.g., modeling module 510
  • changing the administration location of the therapeutic agent may reduce the potential for occurrence of a localized adverse reaction, such as lipodystrophy and lipohypertrophy.
  • administration engine 130 can provide an indication of the planned administration location.
  • the administration engine can facilitate tracking of the available supply of the therapeutic agent.
  • the administrative engine can be initialized with a quantity of the therapeutic agent provided to the patient. The administration engine can then track the cumulative administered dose. Based on the originally supplied quantity and the cumulative administered dose, the administration engine can determine a remaining quantity of the therapeutic agent. When this remaining quantity falls below a quantity threshold, the administration engine can provide a notification. This notification can be provided by the communication module using contact information store by the account manager, or obtained by the account manager from data storage (e.g., data storage 120).
  • the quantity threshold may depend on an estimated time before the originally supplied quantity is exhausted, an estimated time until another supply can be provided to the patient, and a buffer time. For example, when a quantity equal to four weeks supply remains, providing another supply would require three weeks, and the buffer is two weeks, the administration engine may provide the notifications.
  • the administration engine can receive an indication to transition between a child-proof mode having reduced functionality and a normal mode having full functionality.
  • the child-proof mode may have functionality similar to the pediatric patient account described above with reference to Fig. 4.
  • the normal mode may have functionality similar to the caregiver or adult patient accounts described above with reference to Fig. 4.
  • the request may be received from at least one of the app engine and the dashboard engine.
  • the indication may be a password, such as the password associated with a caregiver or adult patient accounts linked to the patient. After step 650, process 600 can proceed to an end 660.
  • Fig. 7 is a flowchart representing an exemplary method 700 for hormone therapy management.
  • an administration engine e.g., administration engine 130
  • a computing device e.g., computing device 200
  • an electronic device e.g., electronic device 300
  • receives step 720
  • an indication of an actual date and actual dosage of a therapeutic agent administrated to a patient can be received using at least one of a data input engine (e.g., data input engine 110), an app engine (e.g., app engine 141), a dashboard engine (e.g., dashboard engine 143), and one or more auxiliary devices (e.g., auxiliary device(s) 145).
  • a data input engine e.g., data input engine 110
  • an app engine e.g., app engine 141
  • a dashboard engine e.g., dashboard engine 143
  • auxiliary devices e.g., auxiliary device(s) 145
  • the patient may interact with display 191 through a graphical user interface and associated I/O devices to indicate the actual date and actual dosage of administration of the therapeutic agent.
  • one or more of the actual date and the actual dosage can be implicitly provided.
  • the administration engine can receive an indication that the dosage was administered. Based on that indication, the administration engine can assume that the planned dosage was administered. Moreover, administration engine can assume that the date the indication was received was the actual administration date. In some aspects, one or more of the actual dosage and actual date may be expressly received by the administration engine.
  • the administration engine can cause the computing device and/or electronic device to determine (step 730) at least one of a second planned administration date and a second planned administration dosage.
  • a modeling module (510) of an administration logic module e.g., administration logic module 470
  • administration logic module 470 can determine the second planned administration date and a second planned administration dosage. This determination can use the actual administration date and the actual administration dosage.
  • the administration engine can cause the computing device and/or electronic device to provide (step 740) an indication of the second planned date and the second planned dosage. Such an indication can be provided to the contact information for one or more accounts linked to the patient. As described above with reference to Fig.
  • an account manager (e.g., account manager 410) can store contact information for each account linked with a patient.
  • An administration logic module e.g., administration logic module 470
  • a communication module e.g., communication module 430
  • the administration engine can facilitate provision of these reminders in advance of the second planned administration date. These reminders may be provided multiple times. For example, a first reminder may be provided using contact information associated with a caregiver two days in advance. Another reminder may be provided to the patient and the caregiver on the day of administration.
  • a notification of this failure may be provided to at least one of the patient, a caregiver, and a healthcare provider. For example, a nurse responsible for ensure adherence to the treatment regime may be notified of the failure to administer the planned dosage one the planned date of administration.
  • the indication of an actual date and actual dosage administered may be received from an auxiliary device (e.g., auxiliary device(s) 145).
  • this indication may be received from an electronic injector.
  • This electronic injector may be configured to estimate an amount of the therapeutic agent administered. It would be appreciated that this amount can differ from the actual amount injected due to administration errors or other factors.
  • the therapeutic agent is a long- acting growth hormone
  • the electronic injector can provide an estimated amount of the long- acting growth hormone injected.
  • This indication can be received by the computing device and/or the electronic device.
  • the indication can be received using an I/O device (e.g., I O devices 217), a network interface (e.g., network interface 201), and/or another component of the computing device.
  • the indication can be received using a communications subsystem (e.g., communications systems 304), a short-range wireless communication system (e.g., short-range wireless communications 326), and/or another component of the electronic device.
  • the indication of the actual date and actual dosage can comprise an indication that therapeutic agent was not administered to the patient.
  • This indication of a missed dosage can be express or implicit.
  • the administration engine can assume that the therapeutic agent was not administered.
  • the administration engine can assume that the therapeutic agent was not administered.
  • administration engine can receive an express indication that the therapeutic agent was not administered using at least one of the data input engine, the app engine, the dashboard engine (e.g., dashboard engine 143), and the one or more auxiliary devices.
  • the administration engine 130 in response to an indication of a missed dose, can provide instructions to contact the patient. These instructions may be provided to a healthcare provider and/or a caregiver.
  • the administration engine 130 can also provide a reminder to the patient. The instructions and/or the reminder may be provided by communications module 430 using contact information stored by account manager 410, as directed by administration logic module 470. After step 740, process 700 can proceed to an end 750.
  • Fig. 8 is a flowchart representing an exemplary method 800 for hormone therapy management.
  • an administration engine e.g., administration engine 130
  • a computing device e.g., computing device 200
  • an electronic device e.g., electronic device 300
  • step 820 at least one of actual dates and actual dosages of a therapeutic agent administrated to a patient.
  • the actual dates and actual dosages can be expressly or implicitly received, as described above with reference to Fig. 7.
  • the actual dates and actual dosages can be received using at least one of a data input engine (e.g., data input engine 110), an app engine (e.g., app engine 141), a dashboard engine (e.g., dashboard engine 143), and one or more auxiliary devices (e.g., auxiliary device(s) 145).
  • a patient information module e.g., patient information module 530
  • the patient information module can retrieve such data as needed from data storage (e.g., data storage 120).
  • the patent information module can provide this information to a modeling module (e.g., modeling module 510).
  • administration engine can assume that the date the indication was received was the actual administration date. In some aspects, one or more of the actual dosage and actual date may be expressly received by the administration engine.
  • the administration engine can cause the computing device and/or the electronic device to track (step 830) at least one of height velocity data and body composition data for the patient.
  • the height velocity data and body composition data for the patient can be received using at least one of the data input engine, the app engine, and the dashboard engine.
  • the patient information module can store the height velocity data and body composition data. Alternatively, the patient information module can retrieve such data as needed from the other data storage. The patent information module can provide this information to the modeling module.
  • the administration engine can cause the computing device and/or electronic device to re-determine (step 840) the personalized base dosage of the therapeutic agent for the patient.
  • the administration engine can re-determine the personalized base dosage using the at least one of actual dates and actual dosages.
  • the administration engine can also use the at least one of height velocity data and the body composition data.
  • the administration engine can determine that the patient is not adequately progressing towards treatment goals. For example, the height velocity of the patient may be below a predetermined height velocity.
  • the administration engine can determine that typical dosage administered of the therapeutic agent. In some instances, for example, the actual dosages delivered may have exceeded the predetermined base dose.
  • the administration engine may then re-determine the personalized base dosage using the progress towards treatment goals and the typical dosage. For example, when the typical dosage exceeds the personalized base dosage, the administration engine may increment the personalized base dosage. When the personalized base dosage exceeds the typical dosage, the administration engine may decrement the personalized base dosage. As an additional example, when the patient is not adequately progressing towards treatment goals, the administration engine may increment the personalized base dosage. Such increments and decrements may be additive, antagonistic, or synergistic.
  • the re-determined dosage can also depend on other patient medical information, as described above with regard to Figs. 1, 4, and 5.
  • body composition data for the patient can be received from an auxiliary device (e.g., auxiliary device(s) 145).
  • this measurement can be received by the computing device and/or the electronic device from an electronic body composition measurement device, such as an electronic scale configured to measure body composition using bio-impedance.
  • the measurement can be received using an I/O device (e.g., I/O devices 217), a network interface (e.g., network interface 201), and/or another component of the computing device.
  • the measurement can be received using a communications subsystem (e.g., communications systems 304), a short-range wireless communication system (e.g., short-range wireless communications 326), and/or another component of the electronic device.
  • the administration engine can receive IGF-1 concentration data for the patient.
  • the modeling module of the administration engine can use the IGF-1 concentration data to determine the personalized base dosage. For example, the modeling module can re-determine the personalized base dosage using a pharmokinetic and pharmodynamic model of the therapeutic agent. After step 840, process 800 can proceed to an end 850.
  • Fig. 9 is a flowchart representing an exemplary method 900 for hormone therapy management.
  • an administration engine e.g., administration engine 130
  • a computing device e.g., computing device 200
  • an electronic device e.g., electronic device 300
  • the pharmokinetic and pharmodynamic data can be received using at least one of a data input engine (e.g., data input engine 1 10), an app engine (e.g., app engine 141 ), a dashboard engine (e.g., dashboard engine 143), and one or more auxiliary devices (e.g., auxiliary device(s) 145).
  • a data input engine e.g., data input engine 1 10
  • an app engine e.g., app engine 141
  • a dashboard engine e.g., dashboard engine 143
  • auxiliary devices e.g., auxiliary device(s) 145
  • a patient information module (e.g., patient information module 530) can store the pharmokinetic and pharmodynamic data. Alternatively, the patient information module can retrieve such data as needed from data storage (e.g., data storage 120). The patent information module can provide this information to a modeling module (e.g., modeling module 510).
  • the pharmokinetic and pharmodynamic data of the patient can include the concentration and accumulation of the therapeutic agent in the plasma of the patient.
  • the pharmokinetic and pharmodynamic data of the patient can include the baseline IGF-1 levels in the blood of the patient and, the peak and duration of an IGF-1 dose response for the patient.
  • the IGF-1 dose response may describe the increase in IGF-1 in response to a predetermined administration of the therapeutic agent. This value may be used to determine an amount of the therapeutic agent and the intervals between doses used to maintain the desired levels of IGF-1 in the patient.
  • the administration engine can cause the computing device and/or electronic device to determine (step 930) at least one of a second planned administration date and a second planned administration dosage.
  • a modeling module (510) of an administration logic module e.g., administration logic module 470
  • the second planned administration date and a second planned administration dosage can be determined. This determination can use the received pharmokinetic and pharmodynamic data. This determination can also use the personalized base dosage and the personalized administration schedule, as described above with reference to Figs. 4, 5 and 6.
  • the second planned administration date can differ from the next date in the personalized administration schedule.
  • the second planned dosage can differ from the personalized dosage, and from the prior planned dosage.
  • the administration engine can cause the computing device and/or electronic device to provide (step 940) an indication of the second planned date and the second planned dosage, as describe above with reference to Fig. 7.
  • the administration engine may be configured to receive a numerical threshold.
  • This numeric threshold can concern the concentration of the therapeutic agent in the plasma of the patient.
  • This numerical threshold may be received using at least one of a data input engine (e.g., data input engine 110), an app engine (e.g., app engine 141), and a dashboard engine (e.g., dashboard engine 143).
  • the patient information module can store the numerical threshold. Alternatively, the patient information module can retrieve such data as needed from data storage. The patient information module can provide this information to the modeling module.
  • This numerical threshold can be a safety limit. For example, the numerical threshold can be determined by the onset of side effects, which may include fatigue, depression, lack of energy, and lack of sexual desire.
  • this numerical threshold can bound typical concentration values.
  • This bound on typical concentration values may be expressed as a statistical measure (e.g., an SDS threshold ranging between one and two, or greater than two).
  • This bound on typical concentration values may also be expressed as a concentration value (e.g., a concentration value more than two standard deviations above the median concentration value for a population, the population potentially limited to individuals demographically similar to the patient in age, sex, weight, etc.).
  • the determination of the second planned date and/or the second planned dosage can depend on the stored numerical threshold.
  • the modeling module can formulate an optimization problem with a loss function depending on the numerical threshold and the predicted concentration of the therapeutic agent in the plasma of the patient.
  • the modeling module can determine at least one combination of second planned date and second planned dosage based on this optimization problem.
  • Fig. 10 is a flowchart representing an exemplary method 1000 for hormone therapy management. It will be readily appreciated that the illustrated procedure can be altered to delete steps or further include additional steps.
  • an administration engine e.g., administration engine 130
  • a computing device e.g., computing device 200
  • an electronic device e.g., electronic device 300
  • step 1020 receiving at least one of patient medical information, instructional information, external resource information, and gamification resources, as described above with regard to Fig. 1.
  • the administration engine can receive this information and resources using at least one of data input engine (e.g., data input engine 110), an app engine (e.g., app engine 141), a dashboard engine (e.g., dashboard engine 143), and one or more auxiliary devices (e.g., auxiliary device(s) 145).
  • This information may be stored in at least one of data storage (e.g., data storage 120), a patient information module of the administration engine (e.g., patient information module 530), or a scheduling module of the administration engine (e.g., scheduling module 550).
  • the administration engine can cause the computing device and/or electronic device to receive (step 1030) a request to provide the at least one of patient medical information, instructional information, and external resource information.
  • This request may be provided using at least one of the app engine and the dashboard engine.
  • the administration engine may determine the extent to which the request may be fulfilled. For example, as described above with reference to Fig. 4, different accounts may have differing degrees of access to information. Requests for unauthorized information may be denied. Requests that would return both authorized and unauthorized information may only return authorized information.
  • the administration engine can cause the computing device and/or electronic device to provide (step 1040) instructions to display the requested information (to the extent such display is authorized).
  • the instructions may direct the app engine to display the results on display 191.
  • the instructions may direct the dashboard engine to display the results on display 193.
  • the source of the request e.g., the dashboard engine
  • the request is received from a device of the patient and the instructions to display at least of one the patient health indications are provided to the device of the subject.
  • app engine 141 may be implemented on an electronic device.
  • This electronic device may be owned, operated, or controlled by the patient.
  • this electronic device can be one of a smart phone, tablet, or wearable device, such as smart glasses, a smart watch, or a similar device.
  • the patient medical information can include at least one of laboratory results; height; weight; and trunk or fat mass information.
  • the patient medical information can be at least one of medication administration information and outcome measures.
  • the external resources can include contact information for insurance providers, mentoring programs, and clinicians, which may include hyperlinks.
  • Caregivers were trained on the preparation of the long-acting growth hormone, SC injection technique, and the electronic diary prior to any dosing events. In-clinic visits were conducted quarterly for patient follow-up, electronic diary reprogramming, and re-supply of the long- acting growth hormone and ancillary supplies. The electronic diary was programmed to provide both assigned injection volume and timing of injection. Caregivers used the electronic diary to indicate injection volume administered and date of administration. With at-home SC dosing and over 4000 injections administered, injection adherence was 99.5% for weekly, 99.4% for twice-monthly and 99.1% for the monthly dosing schedules. Overall dosing adherence was 99.7% in all regimens with 2217 of 2224 intended doses administered.
  • dosing events were reported by the caregiver using a smartphone-compatible electronic patient reported outcome diary.
  • caregivers Prior to at-home dosing, caregivers were trained on the preparation of the long-acting growth hormone, SC injection technique, and the electronic diary. In-clinic visits were conducted quarterly for patient follow-up, electronic diaiy reprogramming, and re-supply of the long-acting growth hormone and ancillary supplies.
  • the electronic diary was programmed to provide both assigned injection volume and timing of injection. Caregivers used the electronic diary to report injection volume administered and date of administration.
  • Fig. 15 depicts the treatment adherence of patients in the extension study. As shown, with at-home dosing and over 1600 doses administered at the 3.5 mg/kg TM dose and schedule, dosing adherence was 99.6%. Injection adherence at the initial schedule and dose was 99.5% for W, 99.5% for TM, and 99.1 for M, and was 99.4% with the 3.5 mg/kg TM dose. Overall dosing adherence was 99.7% in all regimens with 2217 of 2224 intended doses administered. Adherence to the long-acting growth hormone thus occurred at nearly 100% over 18 months of at-home dosing.
  • the disclosed embodiments can also be implemented as a computer program product for hormone therapy management.
  • Such management may include interactions with a patient receiving a periodic administration of the hormone.
  • the hormone may be a long-acting growth hormone.
  • use of the computer program product can enhance adherence of the subject to a growth hormone treatment schedule.
  • This computer program product can comprise a computer readable program or code configured to communicate with a computer, stored on a non-transitory computer readable medium.
  • non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM or any other flash memory, NVRAM, a cache, a register, any other memory chip or cartridge, and networked versions of the same.
  • the disclosed embodiments can be implemented as systems and devices thereof configured to carry out the subject methods, as described above.
  • kits that at least include the subject systems and devices, products or components thereof, e.g., as described above, and instructions for using the devices for hormone therapy management. For example, these instructions may describe steps for receiving a periodic administration of growth hormone.
  • a kit includes one or more doses of growth hormone, wherein each dose is contained in a vial.
  • a kit includes a computer program product.
  • a kit includes further a computer readable medium and software stored on the computer readable medium and adapted to be executed by a processor to record patient information consistent with disclosed embodiments.
  • a kit includes instructions regarding use of the computer program product.
  • the kit includes instructions in fixed (e.g., paper brochure) or electronic form.
  • the instructions for using the systems and devices as discussed above are generally recorded on a suitable recording medium.
  • the instructions may be printed on a substrate, such as paper or plastic, etc.
  • the instructions may be present in the kits as a package insert, in the labeling of the container of the kit or components thereof (i.e.
  • the instructions are present as an electronic storage data file present on a suitable computer-readable storage medium, e.g., a digital storage medium, e.g., a portable flash drive, a CD-ROM, a diskette, etc.
  • a suitable computer-readable storage medium e.g., a digital storage medium, e.g., a portable flash drive, a CD-ROM, a diskette, etc.
  • the instmctions may take any form, including complete instructions for how to use the systems and devices, or as a website address with which instructions posted on the Internet may be accessed.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Public Health (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Biomedical Technology (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Chemical & Material Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Medicinal Chemistry (AREA)
  • Medicines That Contain Protein Lipid Enzymes And Other Medicines (AREA)

Abstract

Conformément à des modes de réalisation, la présente invention concerne des procédés et des systèmes permettant une gestion de thérapie par hormone de croissance. Ces procédés et systèmes peuvent être utilisés avec une hormone de croissance à action prolongée. Ces procédés et systèmes peuvent consister à recevoir des informations d'administration personnalisées relatives à une hormone de croissance à action prolongée comprenant une posologie de base personnalisée et un calendrier d'administration personnalisé. Ils peuvent également consister à déterminer une date planifiée permettant d'administrer l'hormone de croissance à action prolongée à un patient présentant une insuffisance en hormone de croissance sur la base du calendrier d'administration personnalisé. Les procédés et systèmes peuvent en outre consister à déterminer une posologie planifiée de l'hormone de croissance à action prolongée sur la base de la posologie de base personnalisée et de la date planifiée, et à fournir une indication de la date planifiée et de la posologie planifiée.
PCT/US2017/016267 2016-02-02 2017-02-02 Système d'adhésion à un traitement par hormone de croissance WO2017136583A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201662290410P 2016-02-02 2016-02-02
US62/290,410 2016-02-02
US201662300747P 2016-02-26 2016-02-26
US62/300,747 2016-02-26
US201662317367P 2016-04-01 2016-04-01
US62/317,367 2016-04-01

Publications (1)

Publication Number Publication Date
WO2017136583A1 true WO2017136583A1 (fr) 2017-08-10

Family

ID=58046773

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/016267 WO2017136583A1 (fr) 2016-02-02 2017-02-02 Système d'adhésion à un traitement par hormone de croissance

Country Status (1)

Country Link
WO (1) WO2017136583A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021113971A1 (fr) * 2019-12-09 2021-06-17 Medhelper Inc. Procédé et système d'amélioration du traitement de niveau de suivi
US20220088147A1 (en) * 2019-03-04 2022-03-24 Ascendis Pharma Endocrinology Division A/S Long-acting growth hormone dosage forms with superior efficacy to daily somatropin

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100198142A1 (en) * 2009-02-04 2010-08-05 Abbott Diabetes Care Inc. Multi-Function Analyte Test Device and Methods Therefor
EP2473850A1 (fr) * 2009-09-02 2012-07-11 Merck Serono S.A. Compositions et procédés de traitement du déficit en hormone de croissance
US20120209241A1 (en) * 2011-02-10 2012-08-16 Medtronic, Inc. Medical fluid delivery device programming
US8703717B2 (en) 2009-02-03 2014-04-22 Amunix Operating Inc. Growth hormone polypeptides and methods of making and using same
US20140162949A1 (en) 2012-06-05 2014-06-12 Amunix Operating Inc. Treatment with human growth hormone analogues
US20140162954A1 (en) * 2012-12-12 2014-06-12 Teva Pharmaceutical Industries, Ltd Fusion of human growth hormone and albumin formulation and uses thereof
WO2014164568A1 (fr) 2013-03-11 2014-10-09 Amunix Operating Inc. Traitement du déficit en hormone de croissance chez l'enfant par des analogues d'hormone de croissance humaine
US20140379629A1 (en) * 2013-06-20 2014-12-25 Baxter International Inc. Method and apparatus for providing a pharmacokinetic drug dosing regime
US20150371000A1 (en) * 2014-06-23 2015-12-24 Mckesson Corporation Systems and Methods for Determining Patient Adherence to a Prescribed Medication Protocol

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8703717B2 (en) 2009-02-03 2014-04-22 Amunix Operating Inc. Growth hormone polypeptides and methods of making and using same
US20100198142A1 (en) * 2009-02-04 2010-08-05 Abbott Diabetes Care Inc. Multi-Function Analyte Test Device and Methods Therefor
EP2473850A1 (fr) * 2009-09-02 2012-07-11 Merck Serono S.A. Compositions et procédés de traitement du déficit en hormone de croissance
US20120209241A1 (en) * 2011-02-10 2012-08-16 Medtronic, Inc. Medical fluid delivery device programming
US20140162949A1 (en) 2012-06-05 2014-06-12 Amunix Operating Inc. Treatment with human growth hormone analogues
US20140162954A1 (en) * 2012-12-12 2014-06-12 Teva Pharmaceutical Industries, Ltd Fusion of human growth hormone and albumin formulation and uses thereof
WO2014164568A1 (fr) 2013-03-11 2014-10-09 Amunix Operating Inc. Traitement du déficit en hormone de croissance chez l'enfant par des analogues d'hormone de croissance humaine
US20140379629A1 (en) * 2013-06-20 2014-12-25 Baxter International Inc. Method and apparatus for providing a pharmacokinetic drug dosing regime
US20150371000A1 (en) * 2014-06-23 2015-12-24 Mckesson Corporation Systems and Methods for Determining Patient Adherence to a Prescribed Medication Protocol

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220088147A1 (en) * 2019-03-04 2022-03-24 Ascendis Pharma Endocrinology Division A/S Long-acting growth hormone dosage forms with superior efficacy to daily somatropin
WO2021113971A1 (fr) * 2019-12-09 2021-06-17 Medhelper Inc. Procédé et système d'amélioration du traitement de niveau de suivi

Similar Documents

Publication Publication Date Title
McDonnell Telemedicine in complex diabetes management
Little et al. Sustained reduction in severe hypoglycemia in adults with type 1 diabetes complicated by impaired awareness of hypoglycemia: two-year follow-up in the HypoCOMPaSS randomized clinical trial
Russell‐Jones et al. Identification of barriers to insulin therapy and approaches to overcoming them
Polonsky et al. Poor medication adherence in type 2 diabetes: recognizing the scope of the problem and its key contributors
Fuchs et al. Closed-loop control in insulin pumps for type-1 diabetes mellitus: safety and efficacy
Peyrot et al. Insulin adherence behaviours and barriers in the multinational Global Attitudes of Patients and Physicians in Insulin Therapy study
Anderson et al. What can we learn from patient-reported outcomes of insulin pen devices?
Matfin et al. Safe and effective use of the once weekly dulaglutide single-dose pen in injection-naive patients with type 2 diabetes
Sequeira et al. Continuous glucose monitoring pilot in low-income type 1 diabetes patients
Bradley et al. Severe hypoglycemia risk with long-acting insulin analogs vs neutral protamine Hagedorn insulin
Baser et al. Real-world outcomes of initiating insulin glargine-based treatment versus premixed analog insulins among US patients with type 2 diabetes failing oral antidiabetic drugs
Toschi et al. Utility of continuous glucose monitoring in type 1 and type 2 diabetes
Warshaw et al. The reference guide to integrate smart insulin pens into data-driven diabetes care and education services
Kalra et al. A practitioner’s toolkit for insulin motivation in adults with type 1 and type 2 diabetes mellitus: evidence-based recommendations from an international expert panel
Peyrot et al. Patient reported outcomes in adults with type 2 diabetes on basal insulin randomized to addition of mealtime pramlintide or rapid-acting insulin analogs
Magny-Normilus et al. Effects of an intensive discharge intervention on medication adherence, glycemic control, and readmission rates in patients with type 2 diabetes
Chan et al. Challenges and unmet needs in basal insulin therapy: lessons from the Asian experience
Cuddihy et al. Considerations for diabetes: treatment with insulin pen devices
Hyllested-Winge et al. NovoPen Echo® insulin delivery device
Avari et al. Safety and feasibility of the PEPPER adaptive bolus advisor and safety system: a randomized control study
Kalirai et al. Primary care physician perspectives on basal insulin initiation and maintenance in patients with type 2 diabetes mellitus
Peyrot et al. Perceived medication benefits and their association with interest in using inhaled insulin in type 2 diabetes: a model of patients’ cognitive framework
Ekberg et al. Smart pen exposes missed basal insulin injections and reveals the impact on glycemic control in adults with type 1 diabetes
WO2017136583A1 (fr) Système d'adhésion à un traitement par hormone de croissance
Ishii et al. The cost-effectiveness of dulaglutide versus insulin glargine for the treatment of type 2 diabetes mellitus in Japan

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17705532

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 11.12.2018)

122 Ep: pct application non-entry in european phase

Ref document number: 17705532

Country of ref document: EP

Kind code of ref document: A1