Time-controlled drug

Abstract

A method, computer program product, and computer system of providing medication to a patient with a time gap. The method includes determining a dissolution profile for the patient. The dissolution profile includes a medication dissolution rate for a first medication prescribed to the patient and a filler dissolution rate for a selected filler such that a time gap elapses before a second medication is provided after the first medication. The medication dissolution rate and the filler dissolution rate are patient specific. The method includes determining a size of the first medication to correspond to a dose of the prescribed first medication and determining a size of the filler to correspond to the time gap. The method includes providing a pill including at least the first medication and the filler, the first medication surrounding the filler, such that the first medication dissolves before the filler dissolves.

Description

TECHNICAL FIELD

[0001] Exemplary embodiments relate generally to medicine, and more particularly to pills manufactured based on a patient-specific determined dissolution pattern to prevent improper drug interactions. BACKGROUND

[0002] Medicine has been developed to treat or alleviate a variety of different diseases or conditions. A patient can have a plurality of these diseases and conditions. Accordingly, a physician can prescribe a respective medication for each of these diseases and conditions. The medication can be ingested or introduced into the patient in different forms. A conventional approach is to manufacture the medication in a pill or capsule form, where the patient ingests the pill based on a frequency indication by the prescribing physician at the patient's convenience. The medication can have side effects from use, which can or can not be experienced by the patient. The side effects can be determined from research efforts such as trial testing of a single or multiple medications. Further, a first medication can include a particular chemical that can interact with a particular chemical included in a second medication. Accordingly, if the patient is to ingest the first and second medications with overlap, an undesirable side effect can result. Thus, the patient must ingest the first and second medications separately to prevent any unintended side effects that can occur. SUMMARY

[0003] Exemplary embodiments disclose a method, computer program product, and computer system for providing medication to a patient with a time gap. The method includes determining a dissolution pattern for the patient. The dissolution pattern includes a drug dissolution rate for a first medication prescribed to the patient and a filler dissolution rate for a selected filler, such that a time gap elapses before the second medication is provided after the first medication. The drug dissolution rate and the filler dissolution rate are patient-specific. The method includes determining a size of the first medication to correspond to a dosage of the first medication prescribed, and determining a size of the filler to correspond to the time gap. The method includes providing a pill including at least the first medication and the filler, the first medication surrounding the filler, such that the first medication dissolves before the filler dissolves. BRIEF DESCRIPTION OF DRAWINGS

[0004] The following detailed description will best be understood in conjunction with the accompanying drawings, which are given by way of illustration and not limitation and wherein:

[0005] Figure 1 An exemplary schematic diagram of a medication system 100 is depicted in accordance with exemplary embodiments.

[0006] Figure 2 An exemplary signal pill 200 is depicted in accordance with exemplary embodiments.

[0007] Figure 3 An exemplary multi-medication pill 300 is depicted in accordance with an exemplary embodiment.

[0008] Figure 4 An exemplary flowchart of a method 400 is depicted in accordance with an exemplary embodiment, illustrating the operation of the mode program 132 of the medication manufacturing server 130 of the medication system 100 in determining the type of pill for a patient.

[0009] Figure 5 An exemplary flowchart of a method 500 is depicted in accordance with an exemplary embodiment, illustrating the operation of the size program 134 of the medication manufacturing server 130 of the medication system 100 in determining the size of the multi-medication pill for a patient.

[0010] Figure 6 An exemplary flowchart of a method 600 is depicted in accordance with an exemplary embodiment, illustrating the operation of the signal pill 110 of the medication system 100 in alerting a patient to take an additional dose of medication.

[0011] Figure 7 An exemplary block diagram of the hardware components of the medication system 100 is depicted in accordance with an exemplary embodiment. Figure 1

[0012] An exemplary cloud computing environment is depicted in accordance with an exemplary embodiment. Figure 8

[0013] An exemplary abstraction model layer is depicted in accordance with an exemplary embodiment. Figure 9 The drawings are not necessarily to scale. The drawings are merely schematic representations, not intended to portray specific

[0014] DETAILED DESCRIPTION

[0015] Detailed embodiments of the claimed structures and methods are disclosed herein; however, it is understood that the disclosed embodiments are merely examples of the claimed structures and methods and can be practiced in various forms. The exemplary embodiments are illustrative, but not limiting, of the range of structures and methods that can be practiced under the disclosure. Rather, these exemplary embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the exemplary embodiments to those skilled in the art. In the description, details of well-known features and techniques can be omitted to avoid unnecessarily obscuring the presented embodiments.

[0016] ​References in the specification to "one embodiment," "an embodiment,” “example embodiment,” etc., indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of those skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0017] In order not to obscure the presentation of the example embodiments, in the following detailed description, some processing steps or operations that are known in the art can have been combined together for presentation and for illustration purposes, and in some cases can not be described in detail. In other cases, some processing steps or operations that are known in the art can not be described at all. It should be understood that the following description is focused on the distinctive features or elements according to the various example embodiments.

[0018] The example embodiments relate to a method, computer program product, and system for providing medication to a patient with a time gap. As will be described in further detail below, the example embodiments provide a time gap between when a patient takes medication to prevent any unintended side effects from occurring. In providing the time gap, the example embodiments determine a time gap between a multi-medication pill and a signal pill. The example embodiments can determine a way to manufacture a multi-medication pill with a filler that creates a time gap for two different medications included in the multi-medication pill to avoid drug interactions. The example embodiments can determine a way to manufacture a signal pill with a first medication, a filler, and an edible electronic circuit, where the edible electronic circuit generates a signal indicating a time gap for taking a second medication to prevent a drug interaction with the first medication. Key benefits of the example embodiments can include preventing any unintended drug interactions involving a patient taking at least two medications, particularly for a patient mistakenly taking a first medication and taking a second medication too early for the first medication to still be present for a drug interaction to occur. The following is a detailed implementation of the example embodiments.

[0019] Drug interactions can occur when an individual (e.g., a patient) takes two or more different medications at the same time. In an exemplary case, the medications can be for the same ailment, such as tonsil inflammation, which is an abscess in the throat. Thus, a patient can need a combination of an antibiotic and a pain reliever. In another exemplary case, a patient can have two different conditions, such as high blood pressure and arthritis. Thus, a patient can need to take an anti-hypertensive agent and an anti-inflammatory agent. The medications will typically affect each other's function in the patient's body. That is, taking multiple medications can produce unexpected effects, such as an increase in the effect of one or more medications, a further reduction in side effects, a reduction in effectiveness, etc. The extent of the drug interaction can also depend on other factors (e.g., weight, age, health, sensitivity to various medications, sensitivity to medication dosages, etc.) that are subjective to the patient.

[0020] Traditional methods of delivering medications to a patient involve many different considerations and precautions. For example, conventional methods encapsulate a toxic core within a non-toxic region in oral medication dosages. Such conventional methods print three-dimensional medications to minimize airborne particles of toxic medications produced during manufacturing. In another example, conventional methods provide sensor-based containers for medication pills to reduce the likelihood of poisoning. However, these conventional methods do not address time gaps between two medications taken by a patient.

[0021] With respect to multiple medications, additional conventional methods provide some ways of providing respective medications. A common method involves a patient being responsible for taking each medication under the guidance of a prescribing physician or pharmacist. However, this method itself leads to patient errors that can cause drug interactions. In another example, conventional methods describe a three-dimensional printing mechanism for multi-component medication pills, particularly for "zero-order release" profile dosages. In yet another example, conventional methods describe a mechanism to release components in diffusion-controlled dosage forms manufactured with three-dimensional printing. However, a major technical challenge of conventional methods is developing a mechanism that can calculate the size of a pill with appropriate dosages and determine the type of material to separate each medication that can be included in a multi-medication pill. Another technical challenge is integrating edible sensing technology with personalized three-dimensional medication pills to inform a patient of the end of release of a first medication and the impending release of a second medication.

[0022] Exemplary embodiments are configured to provide a pill that allows sufficient time for the release of two or more drugs to be separated in order to prevent drug-drug interactions, particularly when the drug-drug interaction would produce a negative effect. Exemplary embodiments can determine patterns associated with medical absorption, dissolution of drugs and other materials, etc., which can be specific to a patient for a variety of different reasons. Based on the patterns, exemplary embodiments can manufacture pills (e.g., multi-drug pills or signal pills) in different forms that create the necessary time gap when two or more drugs are taken by a patient separately.

[0023] Thus, when multiple drugs (e.g., for one or several diseases) are taken within a short time gap, exemplary embodiments are configured to ensure that the time gap between any pair of drugs is long enough to reduce the likelihood of drug-drug interactions. Since different people have different absorption patterns for different types of drugs, and one person can have different absorption patterns for a single medication taken at different time ranges, exemplary embodiments can manufacture pills that are personalized. If the drugs are not taken within the appropriate time gap, the patient can be at an increased risk of drug-drug interactions, or the treatment can be unnecessarily delayed. In this way, exemplary embodiments identify the medical absorption patterns of any patient so that the patient can be informed of when the next drug can be taken or the next drug is taking effect to reduce the likelihood of negative drug-drug interactions.

[0024] Note that the description of the exemplary embodiments herein uses various terminology. However, some of these terms can be used interchangeably to essentially mean the same thing. For example, the terms "drug," "medication," "medicament," "ingredient," etc., are used interchangeably throughout the description of the exemplary embodiments.

[0025] Figure 1 A drug system 100 according to exemplary embodiments is depicted. According to exemplary embodiments, the drug system 100 can include a signal pill 110, a profile repository 120, a drug manufacturing server 130, and an Internet of Things (IoT) medication container 140, all of which can be interconnected via a network 108. While the programming and data of the exemplary embodiments can be stored and accessed remotely across several servers via the network 108, the programming and data of the exemplary embodiments can alternatively or additionally be stored locally on as few as one physical computing device or in other computing devices besides those depicted. The drug system 100 represents a communication apparatus, where its components are configured to exchange data with each other, either directly or indirectly.

[0026] As will be described below, components of the medication system 100 can operate with only select other components. For example, the signal pill 110 and the IoT medicine container 140 can operate in a cooperative manner. In another example, the medication manufacturing server 130 can operate in a cooperative manner with the profile repository 120. However, such an arrangement is for illustrative purposes only. In view of the description of the example embodiments, those skilled in the art will appreciate that various modifications can be made such that components of the medication system 100 can operate cooperatively with other components that can not otherwise be operatively associated.

[0027] In example embodiments, the network 108 can be a communication channel capable of transferring data between connected devices. Accordingly, components of the medication system 100 can represent network components or network devices interconnected via the network 108. In example embodiments, the network 108 can be the Internet, representing a worldwide collection of networks and gateways that support communications between devices connected to the Internet. Moreover, the network 108 can utilize various types of connections, such as wireline, wireless, fiber optic, or the like, which can be implemented as an intranet, a local area network (LAN), a wide area network (WAN), or a combination thereof. In further embodiments, the network 108 can be a Bluetooth network, a WiFi network, or a combination thereof. In further embodiments, the network 108 can be a telecommunications network for facilitating a two-party or more party telephonic call, including a landline network, a wireless network, a closed network, a satellite network, or a combination thereof. In general, the network 108 can represent any combination of connections and protocols that will support communications between connected devices. For example, the network 108 can also represent direct or indirect wired or wireless connections between components of the medication system 100 that do not use the network 108.

[0028] In example embodiments, the signal pill 110 can include an edible electronic circuit (EEC) 112 and represent any medication having a predetermined dosage configured to address a disease and / or condition (hereinafter collectively referred to as a “condition”) of a patient. The communication functions that the signal pill 110 can perform are described in reference to Figure 7 described in greater detail as a hardware implementation, in reference to Figure 8 described in greater detail as part of a cloud implementation, and / or in reference to Figure 9 described in greater detail as being handled with a functional abstraction layer.

[0029] As will be described in further detail below, the bolus provided to the patient for one or more conditions of the patient can be in the form of a multi-drug bolus or a signal bolus 110. The signal bolus 110 can include a drug portion surrounding a filler, where the filler surrounds the EEC 112. Examples of the signal bolus 110 will be described in further detail below. Based on various determinations that will be described below, the drug system 100 can be configured to determine whether a multi-drug bolus can be used or whether a signal bolus 110 can be preferred for a given patient.

[0030] In example embodiments, the EEC 112 can act as a client in a client-server relationship and can be a software, hardware, and / or firmware based application equipped component capable of measuring and exchanging time gap data via the network 108. In embodiments, the EEC 112 can perform operations when powered by contact with a chemical naturally produced within a patient’s body such that the operations allow for interaction with one or more components of the drug system 100 and utilize various wired and / or wireless connection protocols, including Bluetooth, 2.4gHz and 5gHz internet, near field communication, Z-Wave, Zigbee, etc., for data transmission and exchange associated with measuring patient-specific dissolution patterns.

[0031] The EEC 112 can be manufactured in any of a variety of ways as understood by those skilled in the art. For example, conventional methods utilize ingestible cameras for gastrointestinal surgery. In another example, conventional methods use sensors attached to drugs for studying how the drugs break down in the body. The edible sensors can help researchers and doctors better study gastrointestinal diseases. The digestible capsules or boluses (hereinafter collectively referred to as “boluses”) can be easily swallowed, subsequently dissolving in the stomach. Thus, conventional edible circuitry can help detect diseases, monitor digestion parameters, etc. in various ways of manufacturing the edible circuitry and how the edible circuitry generates power. The example embodiments can be utilized and / or modified to combine any type of edible circuitry with different ways of manufacturing and powering such edible circuitry.

[0032] According to one example embodiment, the EEC 112 can be equipped with a power source that is activated upon contact with a naturally occurring chemical in the patient's body. For example, the EEC 112 can be piezoelectric such that contact with stomach acid in the patient's body produces piezoelectricity that powers the components of the EEC 112. The EEC 112 can include circuit components configured to perform a selection operation. For example, the EEC 112 can include a signal generation component that is activated when the EEC 112 is powered. In another example, the EEC 112 can include a signal transmission component that is also activated when the EEC is powered. The signal generated by the signal generation component can then be transmitted using any of the transmission protocols described above. In a particular example implementation, the transmission protocol can include near field communication (NFC) transmission to the IoT medicine container 140. The EEC 112 can be manufactured with the same materials conventionally used in manufacturing vitamins.

[0033] In example embodiments, the profile repository 120 can include one or more patient profiles 122 and can be an enterprise server, a laptop, a notebook, a tablet, a netbook, a PC, a desktop computer, a server, a PDA, a rotary telephone, a key telephone, a smart phone, a mobile phone, a virtual appliance, a thin client, an IoT device, or any other electronic device or computing system capable of storing data to, receiving data from, and transmitting data to other computing devices. While the profile repository 120 is shown as a single device, in other embodiments, the profile repository 120 can be composed of clusters or multiple electronic devices that work together or independently in a modular fashion or the like. While the profile repository 120 is also shown as a separate component, in other embodiments, the profile repository 120 can be merged with one or more of the other components of the medicine system 100. For example, the profile repository 120 can be incorporated into the medicine manufacturing server 130. Accordingly, access to the profile repository 120 by the medicine manufacturing server 130 can be performed locally. Reference is made to Figure 7 The profile repository 120 is described in greater detail as a hardware implementation, reference is made to Figure 8 as part of a cloud implementation, and / or reference is made to Figure 9 as being processed with a functional abstraction layer.

[0034] In example embodiments, patient profiles 122 can each be associated with a respective patient and can be populated with various types of information that can be used to determine the type of signal pill 110 to use and the characteristics of the signal pill 110 to provide to the patient. In example embodiments, patient profiles 122 can include dissolution profile information. The dissolution profile information can be received during a monitoring phase. The monitoring phase can occur at a time prior to providing a multi-drug pill or signal pill 110. For example, a patient can be placed on a trial run that includes a monitoring pill with an embedded circuit to capture dissolution rates. Those skilled in the art will appreciate how such a monitoring pill can be manufactured, particularly based on the description of example embodiments. In a particular example, the embedded circuit can be substantially similar to EEC 112. The monitoring pill can have a drug portion surrounding the embedded circuit. Thus, during the trial run, the time of ingestion can be recorded and the time of receiving a signal from the embedded circuit can be recorded. The difference between these times and the physical properties of the drug portion can provide a dissolution profile for the drug being measured. Thus, for each drug being tested, the dissolution profile can include various types of drug dissolution rates in the selected composition (e.g., the material for the drug, physical properties such as density, the size of the monitoring pill and the drug portion of the monitoring pill, etc.). In another example, the dissolution profile can indicate a fill dissolution rate for a particular patient dissolving a fill. In a substantially similar manner, further monitoring pills can include an embedded circuit surrounded by a fill. Thus, for each fill being tested, the time and physical properties of the fill can provide a dissolution profile for the fill.

[0035] Patient profiles 122 can include other information. For example, patient profiles 122 can be populated with information recorded in an electronic health record (EHR). In another example, patient profiles 122 can be populated with standard information related to a patient medically or non-medically (e.g., demographic information, height, weight, allergies, sensitivities, etc.). As those skilled in the art will appreciate, this type of information can be applied to determining dissolution rates (e.g., to explain why a dissolution rate was observed) and drugs that can or can not be prescribed.

[0036] IoT medicine container 140 can represent any vessel configured to store medicine to be taken by a patient. IoT medicine container 140 can include multiple sections, each of which can be filled with the appropriate medicine to be taken at a given day, at a given time of day, etc. IoT medicine container 140 can be equipped with a locking component that locks IoT medicine container 140 or selectively locks the sections. IoT medicine container 140 can also include electronic components. For example, IoT medicine container 140 can include a processor (e.g., a simple processor that performs simple operations) that controls various components of IoT medicine container 140, generates signals, etc. In a particular example, the locking component can be controlled by the processor. In another example, IoT medicine container 140 can include a signal receiving component. The signal receiving component can be configured to receive signals from EEC 112. Upon receiving a signal from EEC 112, the processor can perform an operation to unlock IoT medicine container 140 or a section thereof. In another example, IoT medicine container 140 can include a sensor that measures sensing information about IoT medicine container 140 or a section thereof that is accessed (e.g., opened and closed) and whether an item in IoT medicine container 140 or a section thereof has been removed. In yet another example, IoT medicine container 140 can include an alert component that provides a sensory alert to the patient. The processor can have a schedule and a clock to trigger the alert component so that the patient knows when to take the medicine. The processor can also determine when to trigger the alert component as a result of receiving a signal from EEC 112 so as to take another medicine with a sufficient time gap. The alert component can be a visual alert (e.g., an LED that blinks or steadily lights up), an audible alert (e.g., a sound that can be played until the medicine is taken), a tactile alert (e.g., IoT medicine container 140 can vibrate), or a combination thereof.

[0037] According to an example implementation, signal pill 110 can utilize NFC signals with IoT medicine container 140. Thus, a direct communication path can be established between these components. However, the use of such an arrangement is merely illustrative. In another example implementation, the patient can have a smart device present. The smart device can be within a communication range to establish a communication path with signal pill 110 and IoT medicine container 140. In this way, the smart device can include an application that exchanges signals between these components of medicine system 100. The application on the smart device can also provide a user interface. Thus, the alert component can alternatively or additionally be configured on the smart device. The application on the smart device can also replace the operations described above for IoT medicine container 140. For example, the smart device can include a schedule and a clock. In this way, IoT medicine container 140 can be designed with lower complexity and leverage the processing power of the smart device.

[0038] In example embodiments, the drug manufacturing server 130 can include a pattern program 132 and a sizing program 134. The drug manufacturing server 130 can be an enterprise server, a laptop, a notebook, a tablet, a netbook, a PC, a desktop computer, a server, a PDA, a rotary telephone, a key telephone, a smart phone, a mobile phone, a virtual appliance, a thin client, an IoT device, or any other electronic device or computing system capable of receiving data from and sending data to other computing devices. While the drug manufacturing server 130 is shown as a single device, in other embodiments, the drug manufacturing server 130 can include a cluster or multiple computing devices working together or independently. While the drug manufacturing server 130 is also shown as a separate component, in other embodiments, the operations and features of the drug manufacturing server 130 can be incorporated with one or more of the other components of the drug system 100. Reference is made to Figure 7 The drug manufacturing server 130 is described in greater detail as a hardware implementation, reference is made to Figure 8 as part of a cloud implementation, and / or reference is made to Figure 9 as being processed with a functional abstraction layer.

[0039] The drug manufacturing server 130 can provide operations involved in manufacturing the signal pill 110 and / or the multi-drug pill. For example, as described above, a patient can be in a trial run to determine drug treatment parameters, including the type of pill to be prescribed (e.g., between the signal pill 110 and the multi-drug pill), the size of the pill, the selection of components of the pill, etc. Accordingly, the drug manufacturing server 130 can provide a number of operations that can be performed prior to prescribing the pill to the patient. The drug manufacturing server 130 can also perform its operations at other intervals, particularly when the patient exhibits different dissolution patterns. In this way, the pill prescribed to the patient can remain to provide appropriate time intervals to prevent drug interactions.

[0040] In example embodiments, the pattern program 132 can be a software, hardware, and / or firmware application configured to determine a dissolution pattern associated with a patient. Accordingly, the pattern program 132 can be used during a monitoring phase (e.g., a trial run) in which metabolic characteristics of the patient are determined. Specifically, the pattern program 132 can determine a rate at which the patient dissolves ingested chemicals. The chemicals can include various types of drugs and various types of fillers (e.g., non-medical fillers).

[0041] As described above, during the monitoring phase, the patient can be instructed to ingest a monitoring pill. The monitoring pill can include an embedded circuit substantially similar to the EEC 112. In a first type of monitoring pill, the embedded circuit can be surrounded by the medication prescribed to the patient. The time at which the patient ingests the monitoring pill can be recorded. At a subsequent time, when the medication portion of the monitoring pill has dissolved, the embedded circuit can be powered. As a result of being powered, the embedded circuit can transmit a signal. The time at which the signal is received can also be recorded. Based on the duration of time between ingestion and receipt of the signal, the time required by the patient to dissolve the medication can be established. Thus, the pattern program 132 can establish the dissolution rate of the medication. This process can be repeated for each type of medication prescribed to the patient. In a second type of monitoring pill, the embedded circuit can be surrounded by a filler. The time at which the monitoring pill is ingested and the time at which the signal is received can also be recorded to create a duration of time required by the patient to dissolve the filler. Thus, the pattern program 132 can establish the dissolution rate of the filler. This process can be repeated for each type of filler that can be used to manufacture a pill according to exemplary embodiments. Through this trial run, the pattern program 132 can determine the dissolution pattern of the patient.

[0042] As also described above, this process performed by the pattern program 132 can be performed at various times. For example, the process can be performed at an initial time to establish an initial dissolution pattern for the patient. In another example, since the patient can change the dissolution pattern, the process can be performed at a subsequent time relative to the initial time to establish a current dissolution pattern for the patient. The subsequent time can be, for example, at a predetermined time gap (e.g., after a duration of time in which the patient takes the pill), upon a determined event (e.g., a determination that there is a drug interaction, a determination of a new prescription of medication or a new filler to be used), etc. For each performance of the process, the dissolution pattern can be stored in the patient profile 122 of the patient.

[0043] In exemplary embodiments, the sizing program 134 can be a software, hardware, and / or firmware application configured to determine the size of a pill to be prescribed to a patient. The sizing program 134 can determine the size of the pill as a whole and the size of the components of the pill.

[0044] In one manner of determining the size, the sizing program 134 can receive prescription information for a medication prescribed to a patient. The prescription information can include, for example, the dosage or amount of the medication to be ingested by the patient at a prescribed frequency. Based on the available concentration of the medication, the sizing program 134 can determine the volume of the medication to be included in a given pill for a given concentration.

[0045] In another manner of determining the size, the sizing program 134 can receive fill information for a fill to be included in a pill for the patient. Based on a fill dissolution rate of the given fill, the sizing program 134 can determine an amount of time that will elapse from use of a selected amount of the fill. The amount of time that will elapse can correspond to a time gap between a first medication to be taken and a second medication to be taken. Thus, the sizing program 134 can determine a volume of the fill to be included in a given pill for a time gap to be achieved, where the time gap indicates a minimum amount of time to prevent or minimize a drug product interaction between the first medication and the second medication.

[0046] In a further manner of determining the size, the sizing program 134 can receive information for the EEC 112, which can be included in a pill for the patient. The EEC 112 can be manufactured to have a known size so that all necessary components can be included. The size of the EEC 112 can be set to a standard size (e.g., an industry size).

[0047] Based on the volumes of the medications, the fill, and the EEC 112, the sizing program 134 can determine a minimum volume that a pill to be prescribed for the patient will occupy. For example, as a multi-medication pill, the sizing program 134 can determine a volume of an inner medication portion, a volume of a fill surrounding the inner medication portion, and a volume of an outer medication portion surrounding the fill. From this, the sizing program 134 can determine a total volume of the multi-medication pill. Based on the total volume of the multi-medication pill, the sizing program 134 can determine whether the multi-medication pill occupies an acceptable volume. For example, each patient can have a maximum pill size that can be prescribed. The maximum pill size can be determined based on various factors. In an example embodiment, during a trial run, patients can be provided with pills of various sizes. The patients can indicate a maximum size pill that the patients can comfortably ingest. In another example, crowd-sourced information can be used to determine a maximum pill size that can be prescribed for patients matching a particular patient characteristic profile (e.g., age, patient size, etc.). The maximum pill size can define a size threshold for the patient. Thus, when the total volume of the multi-medication pill is within the size threshold (i.e., the maximum pill size), the sizing program 134 can determine that the multi-medication pill can be manufactured according to the determined size and prescribed for the patient. Conversely, when the total volume of the multi-medication pill exceeds the size threshold, the sizing program 134 can determine that the multi-medication pill can have an unacceptable size. Thus, the sizing program 134 can determine that the signal pill 110 can be manufactured and prescribed for the patient. The sizing program 134 can determine the size of the signal pill 110 in a substantially similar manner as described above, where the volumes of the medications, the volume of the fill, and the EEC 112 volume are used to determine a total volume of the signal pill 110.

[0048] Figure 2An exemplary signal pill 200 is depicted in accordance with exemplary embodiments. The signal pill 200 can correspond to the signal pill 110 described above with reference to the medication system 100 Figure 1 . The signal pill 200 can include a medication portion 202, an EEC portion 204, and a filler portion 206. The EEC portion 204 can correspond to the EEC 112 described above with reference to the medication system 100 Figure 1 . As shown, the signal pill 200 can be arranged with the EEC portion 204 as a central portion, the filler portion 206 surrounding the EEC portion 204, and the medication portion 202 surrounding the filler portion 206. The medication portion 202 can include an appropriate dose of a first medication. The filler portion 206 can include an appropriate volume of filler to create a time gap. Specifically, upon ingestion of the signal pill 200, gastric acid can digest the signal pill 200 such that the medication portion 202 can dissolve. Upon dissolution of the medication portion 202, the patient can receive the first medication. When the medication portion 202 has dissolved, gastric acid can digest the filler portion 206. Based on the patient's dissolution pattern, the volume of the medication portion 202 and the volume of the filler portion 206 can be set such that the medication portion 202 and the filler portion 206 being dissolved create a time gap. Upon dissolution of the filler portion 206 after the time gap, the EEC portion 204 can be exposed to the patient's gastric acid. Since the EEC portion 204 is piezoelectric, the EEC portion 204 can be powered so as to generate and transmit a signal. The signal can be received by the IoT medication container 140 and / or the patient's smart device. The signal can trigger an alert for the second medication to be ingested. Since the time gap has passed, the patient can ingest the second medication with minimal or no drug-drug interactions.

[0049] Figure 3An exemplary multi-drug pill 300 according to exemplary embodiments is depicted. The multi-drug pill 300 can be manufactured as a result of determining a patient's dissolution pattern such that the overall size and constituent sizes correspond to the appropriate doses of drugs with sufficient time gaps. The multi-drug pill 300 can include an outer drug portion 302, an inner drug portion 304, and a filler portion 306. As shown, the multi-drug pill 300 can be arranged with the inner drug portion 304 as a central portion, the filler portion 306 surrounding the inner drug portion 304, and the outer drug portion 302 surrounding the filler portion 306. The outer drug portion 302 can include an appropriate dose of a first drug. The filler portion 306 can include an appropriate volume of filler to create a time gap. Specifically, upon ingestion of the multi-drug pill 300, gastric acid can digest the multi-drug pill 300 such that the outer drug portion 302 can dissolve. Upon dissolution of the outer drug portion 302, the patient can receive the first drug. When the outer drug portion 302 has dissolved, gastric acid can digest the filler portion 306. Based on the patient's dissolution pattern, the volume of the outer drug portion 302 and the volume of the filler portion 306 can be set such that the dissolving outer drug portion 302 and the filler portion 306 create a time gap. Upon dissolution of the filler portion 306 after the time gap, the inner drug portion 304 can begin to dissolve. Upon dissolution of the inner drug portion 304, the patient can receive a second drug. Since the time gap has elapsed, the patient can receive the second drug with minimal or no drug-drug interactions.

[0050] The above description of the multi-drug pill 300 involves including two drugs in a single pill. However, using only two drugs is merely exemplary. For example, a patient can be prescribed a first, second, and third drug. According to a first exemplary scenario, it can be known that the first drug has no drug product interactions with the second or third drug. However, it can be known that the second drug has a drug product interaction with the third drug. Accordingly, the multi-drug pill 300 can be manufactured such that the outer drug portion 302 can include, for example, only the second drug, while the inner drug portion 304 can include the third drug, or vice versa. Since the first drug has no drug product interactions, the first drug can be incorporated in either the outer drug portion 302 or the inner drug portion 304. In this manner, for this exemplary scenario, one of the outer drug portion 302 or the inner drug portion 304 can contain more than one drug. According to a second exemplary scenario, it can be known that each of the first, second, and third drugs has a drug product interaction with two of the other three drugs. Accordingly, the multi-drug pill 300 can be manufactured such that there are additional layers. For example, the multi-drug pill 300 can include an outer drug portion 302 (e.g., which can include one of the first, second, or third drugs), a filler portion 306, an inner drug portion 304 (e.g., which can include one of the remaining drugs), another filler portion (not shown), and another inner drug portion (not shown) (e.g., which can include the last remaining drug). The filler portion 306 and the other filler portion can be sized such that sufficient time gaps are created between the outer drug portion 302 and the inner drug portion 304, and between the inner drug portion 304 and the other inner drug portion, respectively. Furthermore, additional drugs can be incorporated in the various portions. Specifically, when it is determined that one of the additional drugs has no drug product interaction with a particular one of the drugs to be included in a respective portion, the additional drug can be combined with that non-reactive drug. Those skilled in the art will recognize that the multi-drug pill 300 can include any number of drug portions, with filler portions disposed therebetween.

[0051] Figure 4 An exemplary flowchart of a method 400 is depicted in accordance with exemplary embodiments, which illustrates the operation of the mode program 132 and the size program 134 of the drug manufacturing server 130 of the drug system 100 in determining the type of pill for a patient. The method 400 can involve a trial run performed for a patient to determine the type of pill to be prescribed for the patient. Accordingly, the method 400 will be described from the perspective of the drug manufacturing server 130.

[0052] The drug manufacturing server 130 identifies a patient (step 402). During a trial run, a patient can be enrolled such that a patient profile 122 can be created or retrieved. For example, when a patient is a new patient for which a dissolution pattern is to be determined, the drug manufacturing server 130 can create a new patient profile 122. In another example, when a patient updates a dissolution pattern for any of a variety of reasons (e.g., a scheduled update, an event trigger, etc.), the drug manufacturing server 130 can retrieve an existing patient profile 122 for the patient.

[0053] The drug manufacturing server 130 determines a monitoring bolus to provide to the patient (step 404). In an example monitoring bolus, the monitoring bolus can include a drug surrounding an embedded circuit, which can be substantially similar to the EEC 112. In another example monitoring bolus, the monitoring bolus can include a filler surrounding an embedded circuit.

[0054] The drug manufacturing server 130 receives a time at which the patient ingests the monitoring bolus (step 406). The time can be recorded when the patient ingests the monitoring bolus. While there can be a slight deviation from the time at which the monitoring bolus actually begins to dissolve, the deviation can be minimal in terms of the total time it takes for the monitoring bolus to dissolve to expose the internal embedded circuit. The drug manufacturing server 130 receives a signal from the embedded circuit of the monitoring bolus (step 408). When the monitoring bolus begins to dissolve, a timer can track the duration of time it takes for the drug portion or the filler portion to dissolve to expose the embedded circuit. Once the embedded circuit is exposed to the patient's stomach acid, the embedded circuit can be powered to trigger the generation and transmission of a signal. The drug manufacturing server 130 determines a dissolution pattern for the patient (step 410). Based on the duration of time it takes for the monitoring bolus to dissolve, the drug manufacturing server 130 can determine a dissolution rate at which the patient dissolves a selected drug or a selected filler.

[0055] The drug manufacturing server 130 determines a size of the multi-drug bolus 300 based on the dissolution pattern of the patient (step 412). Based on the dissolution pattern and when at least two drugs are selected for the patient, the drug manufacturing server 130 can determine constituent sizes of the outer drug portion 302, the inner drug portion 304, and the filler portion 306. As will be described in further detail with respect to FIG. 5, the drug manufacturing server 130 can utilize a variety of factors to determine the sizes. Figure 5 The drug manufacturing server 130 can utilize a variety of factors to determine the sizes, as will be described in further detail.

[0056] The drug manufacturing server 130 determines whether the overall size of the multi-drug pill 300 is suitable for the patient (decision 414). As described above, the patient can have a maximum pill size that is acceptable for a prescription. Since the multi-drug pill 300 has an overall size that is suitable for the patient, such as within a size threshold defined by the maximum pill size (decision 414, “yes” branch), the drug manufacturing server 130 updates the patient profile 122 corresponding to the patient to indicate that the multi-drug pill 300 is to be used (step 416). In updating the patient profile 122, the drug manufacturing server 130 can include the determined sizes of the individual portions in the multi-drug pill 300. Since the multi-drug pill 300 has an overall size that is not suitable for the patient, such as outside of a size threshold defined by the maximum pill size (decision 414, “no” branch), the drug manufacturing server 130 updates the patient profile 122 corresponding to the patient to indicate that the signal pill 200 is to be used (step 418).

[0057] Figure 5 An exemplary flowchart of a method 500 is depicted that illustrates the operation of the size procedure 134 of the drug manufacturing server 130 of the drug system 100 in determining a size of a multi-drug pill for a patient, in accordance with exemplary embodiments. The method 500 can involve a trial run performed for a patient to determine an acceptable size of a multi-drug pill that can be prescribed to the patient. The method 500 provides further details regarding the operation of the method 400 (e.g., step 412). Accordingly, the method 500 will be described from the perspective of the drug manufacturing server 130.

[0058] The drug manufacturing server 130 identifies a patient (step 502). The drug manufacturing server 130 can identify the patient in a manner substantially similar to that described above with respect to the method 400. The drug manufacturing server 130 determines the medications prescribed to the patient (step 504). The patient profile 122 can include various types of information, such as information recorded in an EHR. The EHR can include a prescription for the patient that can have been selected by a prescribing physician. During the trial run, each of the medications corresponding to the prescription can be tested to determine a respective medication dissolution rate stored in the patient profile 122. Further, during the trial run, one or more fillers can have been tested to determine a respective filler dissolution rate stored in the patient profile 122. The drug manufacturing server 130 determines a dissolution pattern for the patient (step 506). In particular, the dissolution pattern can reflect the various medication dissolution rates and the filler dissolution rate.

[0059] The drug manufacturing server 130 selects a filler between the drugs to be placed in the multi-drug pill 300 to allow for sufficient time gaps between the drugs (step 508). For example, the multi-drug pill 300 can be manufactured with a pre-selected filler. Accordingly, the pre-selected filler can be selected. In another example, the multi-drug pill 300 can be manufactured with one of a plurality of fillers. The drug manufacturing server 130 can perform various measurements and calculations with respect to each available filler, where each available filler has been tested to have a corresponding filler dissolution rate.

[0060] The drug manufacturing server 130 determines the dimensions of the outer drug portion 302, the inner drug portion 304, and the filler portion 306 of the multi-drug pill 300 (step 510). The dimensions of the outer drug portion 302 and the inner drug portion 304 can be related to the total volume of the respective drugs to be included in the outer drug portion 302, such that an appropriate dose is provided to the patient. Depending on the selected shape of the multi-drug pill (e.g., a standard cylindrical pill with hemispherical end portions can be selected), the drug manufacturing server 130 can determine the dimensions of the inner drug portion 304 to exhibit the selected shape with a determined volume. The drug manufacturing server 130 can also determine the dimensions of the selected filler to exhibit the selected shape and to surround the inner drug portion 304 with the determined volume for providing the time gaps. The drug manufacturing server 130 can also determine the dimensions of the outer drug portion 302 to exhibit the selected shape and to surround the filler portion 306 with the determined volume. In this manner, the individual dimensions and the overall dimensions of the multi-drug pill 300 can be determined, such that the drug manufacturing server 130 can provide instructions (e.g., to a pill manufacturing entity) to manufacture the multi-drug pill 300 based on the determined dimensions (step 512).

[0061] Figure 6 An exemplary flowchart of a method 600 is shown in accordance with an exemplary embodiment, which illustrates the operation of the IoT medicine container 140 of the drug system 100 in alerting a patient to take an additional dose of a drug. The method 600 can be related to a time period after a trial run has been performed for a patient and a signal pill 110 has been determined to be the type of pill to be prescribed to the patient. Accordingly, the method 600 will be described from the perspective of the IoT medicine container 140, which can hold a plurality of pills that the patient can be taking. The method 600 will also be described with respect to an exemplary implementation, in which the signal pill 110 and the IoT medicine container 140 utilize a direct communication path (e.g., no smart device is utilized in the method 600). However, modifications to the method 600 when a smart device is incorporated into the process will be readily understood by one of skill in the art.

[0062] IoT medicine container 140 monitors for a signal from signal pill 200 (step 602). As described above, a patient can be prescribed signal pill 200, which includes a first drug in drug portion 202 around filler portion 206, which surrounds EEC portion 204. For example, for a particular patient, multi-drug pill 300 can have an overall size that does not satisfy a size threshold for the patient. Accordingly, signal pill 200 can be manufactured and provided to the patient. The patient can have ingested signal pill 200 at a prescribed time by a prescribing physician or pharmacist. Once ingested, signal pill 200 can begin to dissolve due to stomach acid of the patient. Once drug portion 202 dissolves, then filler portion 206 can begin to dissolve. Once filler portion 206 has dissolved, and the time gap for the drug prescribed to the patient has passed, EEC 112 in EEC portion 204 can be powered and activated. Accordingly, EEC 112 can begin to generate and transmit / broadcast a signal.

[0063] IoT medicine container 140 determines whether a signal from signal pill 200 is received (decision 604). That is, the first drug has dissolved and been provided to the patient, and the time gap has passed. As no signal from signal pill 200 is received (decision 604, “NO” branch), IoT medicine container 140 maintains a lock on IoT medicine container 140 (step 606). For example, IoT medicine container 140 can include a total lock such that the patient cannot access any drugs stored therein. In another example, IoT medicine container 140 can include multiple sections, with each section having a respective locking component. Without a signal, any locking components can be maintained. For example, by maintaining the lock, the patient can not inadvertently ingest a second drug or pill prematurely that can cause a drug-drug interaction.

[0064] As a result of receiving a signal from signal pill 200 (decision 604, “YES” branch), IoT medicine container 140 generates and transmits a warning to the patient to take an additional drug (step 608). With the first drug taken and the time gap having passed, a second drug that can have a drug-drug interaction with the first drug can be taken without concern for the drug-drug interaction. IoT medicine container 140 can include an alert component that is triggered to provide a sensory alert (e.g., visual, audible, tactile, etc.) to the patient. Further, IoT medicine container 140 unlocks IoT medicine container 140 (step 610). For example, a total lock of IoT medicine container 140 can be opened for the patient to access drugs stored therein. In another example, based on a time schedule of when to take the drugs, a particular section of IoT medicine container 140 can be unlocked such that the patient is only provided access to particular drugs stored in that section.

[0065] Within a predetermined time from providing the alert, the IoT medicine container 140 determines whether the second medicine has been removed from the IoT medicine container 140 (decision 612). As a result of no medicine being removed from the IoT medicine container 140 (decision 612, "No" branch), the IoT medicine container 140 can continue to provide the alert for the patient to take the second medicine (e.g., to maintain a schedule of taking medicines). As a result of receiving the signal from the IoT medicine container 140 (decision 612, "Yes" branch), the IoT medicine container 140 can determine that the patient can have taken the second medicine. The IoT medicine container 140 can relock the IoT medicine container 140 or its corresponding section. When the section including the second medicine is unlocked, the IoT medicine container 140 can not relock the section because no medicine is being held.

[0066] Exemplary embodiments can be provided that incorporate various considerations and can also be performed with various modifications. For example, medicines prescribed for a patient can be based on patient-specific characteristics (e.g., age, sex, comorbidities, vital signs, etc.). The prescribed medicines can be indicated with appropriate names, amounts, orders, time gaps, etc. In this way, exemplary embodiments can provide appropriate instructions in generating a multi-medicine pill 200 or a signal pill 300 using, for example, a three-dimensional medicine printing system to print a capsule or pill that allows for a time gap to be observed between medicines.

[0067] Exemplary embodiments are configured to provide multiple medicines with a time gap established between the multiple medicines to prevent drug-drug interactions. Exemplary embodiments can provide instructions to three-dimensionally print a pill as a multi-medicine pill or a signal pill based on whether a size of the resulting pill is acceptable for a patient (e.g., based on age, health, etc.). In a multi-medicine pill, a first medicine can be included in an outer medicine portion and a second medicine can be included in an inner medicine portion. A filler can be used to separate the outer medicine portion and the inner medicine portion. The filler can be selected to have a size (e.g., volume, thickness, etc.) such that a time gap is required to pass between the medicines. In a signal pill, a first medicine can be included in an outer medicine portion and an EEC can be included in an inner EEC portion. A filler can be used to separate the outer medicine portion and the inner EEC portion. The filler can be selected to have a size such that a time gap is required to pass before a signal is transmitted by the EEC. The signal can trigger an alert received by a patient to take a second medicine.

[0068] Figure 7 a block diagram of devices within a medicine system 100 in accordance with exemplary embodiments is depicted. It should be appreciated that Figure 1 Figure 7 ​Only a description of one implementation is provided, without implying any limitation on the environments in which different embodiments can be implemented.

[0069] The device used herein can include one or more processors 02, one or more computer-readable RAMs 04, one or more computer-readable ROMs 06, one or more computer-readable storage media 08, device drivers 12, read / write drives or interfaces 14, network adapters or interfaces 16, all interconnected by a communication structure 18, which can be implemented with any architecture designed for passing data and / or control information between processors, such as microprocessors, communications and network processors, system memory, peripheral devices, and any other hardware components within a system.

[0070] One or more operating systems 10 and one or more application programs 11 are stored on one or more of the computer-readable storage media 08 for execution by one or more of the processors 02 via one or more of the respective RAMs 04, which typically include cache memory. In the illustrated embodiment, each computer- readable storage medium 08 can be a magnetic disk storage device of internal hard disk drive, a CD-ROM, DVD, memory stick, magnetic tape, magnetic disk, optical disk, semiconductor memory device such as RAM, ROM, EPROM, flash, or any other computer-readable tangible storage device that can store a computer program and digital information.

[0071] The device used herein can also include a R / W drive or interface 14 to read from and write to one or more portable computer-readable storage media 26, such as a CD, DVD, memory stick, magnetic disk, magnetic tape, or other magnetic or optical storage mediums which can be used with the device, the application programs 11 on the device can be stored therein and read via the respective R / W drive or interface 14 and loaded into the respective computer-readable storage media 08.

[0072] The device used herein can also include a network adapter or interface 16, such as a TCP / IP adapter card or wireless communication adapter (such as a 4G wireless communication adapter using OFDMA technology). The application programs 11 on the device can be downloaded to the computing device from an external computer or external storage device via a network (for example, the Internet, a local area network or other wide area network or wireless network) and the network adapter or interface 16. From the network adapter or interface 16, the programs can be loaded into the computer-readable storage media 08, the network can include copper lines, fiber optics, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers.

[0073] The device used herein may also include a display screen 20, a keyboard or keypad 22, and a computer mouse or touchpad 24. The device driver 12 interfaces with the display screen 20 for imaging, with the keyboard or keypad 22, with the computer mouse or touchpad 24, and / or with the display screen 20 for pressure-sensing alphanumeric character input and user selection. The device driver 12, R / W driver or interface 14, and network adapter or interface 16 may include hardware and software (stored on computer-readable storage media 08 and / or ROM 06).

[0074] The programs described herein are identified based on applications that implement them in one of the specific exemplary embodiments. However, it should be understood that any particular program terminology used herein is for convenience only, and therefore the exemplary embodiments should not be limited to use only in any particular application identified and / or implied by such terminology.

[0075] Based on the foregoing, a computer system, method, and computer program product have been disclosed. However, many modifications and substitutions can be made without departing from the scope of the exemplary embodiments. Therefore, the exemplary embodiments have been disclosed by way of example rather than limitation.

[0076] It should be understood that although this disclosure includes a detailed description of cloud computing, the implementation of the teachings set forth herein is not limited to a cloud computing environment. Rather, exemplary embodiments can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0077] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0078] The features are as follows:

[0079] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring manual interaction with the service provider.

[0080] Wide Area Network (WAN) Access: Capabilities are available on the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0081] Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but can be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).

[0082] Rapid elasticity: in some cases, capabilities can be provisioned and released in a very short period of time (e.g., within minutes). Consumers can have a sense of location independence in that the physical location of the resource is generally transparent to them, but can be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).

[0083] Measured service: cloud systems automatically control and optimize resource use by leveraging utilization of resources in an efficient manner. Consumers can acquire and rapidly provision what they need, in many cases only paying for drain they actually use.

[0084] Service models are as follows:

[0085] Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based e-mail). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0086] Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

[0087] Infrastructure as a Service (IaaS): the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

[0088] Deployment models are as follows:

[0089] Private cloud: the cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0090] Community cloud: the cloud infrastructure is shared by several organizations and supports mission-critical enterprise resources. It can be managed by the organizations or a third party and can exist on-premises or off-premises.

[0091] Public cloud: the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

[0092] Hybrid cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together using standard or proprietary technologies that enable data and application portability.

[0093] A cloud computing environment is service-oriented, with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure comprising a network of interconnected nodes.

[0094] Referring now to Figure 8 , an illustrative cloud computing environment 50 is depicted. As shown, cloud computing environment 50 includes one or more cloud computing nodes 40 with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone 54A, desktop computer 54B, laptop computer 54C, and / or automobile computer system 54N can communicate. Nodes 40 can communicate with one another. They can be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment 50 to offer infrastructure, platforms and / or software as services with Figure 8 The types of computing devices 54A-N shown in

[0095] Referring now to Figure 9 , a set of functional abstraction layers provided by cloud computing environment 50 Figure 8 are shown. It should be understood that Figure 9 the components, layers, and functions shown in

[0096] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframes 61; RISC (Reduced Instruction Set Computer) architecture based servers 62; servers 63; blade servers 64; storage devices 65; and networks and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0097] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0098] In one example, management layer 80 can provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing 82 provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 85 provide pre-arrangement for, and procurement of, cloud computing resources for which future usage is anticipated in accordance with an SLA.

[0099] Workloads layer 90 provides examples of functionality for which the cloud computing environment can be utilized. Examples of workloads and functions which can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and immersive

[0100] The present application can be a system, a method, and / or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application.

[0101] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted via a wire cable.

[0102] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions into the computing / processing device for storage in a computer readable storage medium within the respective computing / processing device.

[0103] Computer readable program instructions for carrying out operations of the present application can be assembly instructions, instruction-set-architecture (ISA) instructions, machine- related instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++ or the like, and a procedural programming language such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present application.

[0104] Aspects of the present application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0105] These computer readable program instructions can be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including

[0106] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0107] The flow and block diagrams in the drawings show the architectural, functional, and operational aspects of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flow or block diagrams can represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or in the reverse order, depending on the functionality involved. Such variation, function, and elaboration cannot be readily parted by those skilled in the art. Further, those skilled in the art will appreciate that blocks in the block diagrams and / or flow diagrams can represent a combination of dedicated hardware or a combination of hardware and software.

Claims

1. A computer-implemented method for providing medication to a patient with a time gap, the method comprising: determining a dissolution pattern for the patient, the dissolution pattern comprising a medication dissolution rate for a first medication and a second medication prescribed to the patient and a filler dissolution rate for a filler, the filler dissolution rate selected so that the time gap elapses between taking the first medication and taking the second medication after the first medication, the medication dissolution rate and the filler dissolution rate being patient-specific; determining a size of the first medication and a size of the second medication corresponding to a dose of the prescribed first medication and a dose of the prescribed second medication, respectively, and determining a size of the filler to achieve the time gap; and based on determining that a combination of the sizes of the first medication, the second medication, and the filler included in a multi-medication pill exceeds a maximum pill size threshold for the patient, three-dimensionally printing a signal pill comprising at least the first medication, the filler, and an edible electronic circuit (EEC), the filler surrounding the ECC, the first medication surrounding the filler, such that the first medication dissolves before the filler dissolves, wherein the first medication and the filler are three-dimensionally printed according to the determined sizes; wherein, after the filler has dissolved to expose the EEC, the EEC is powered to send a signal configured to provide an alert to the patient that the time gap has elapsed, and wherein the method further comprises: in response to monitoring the signal, unlocking an Internet of Things (IoT) medicine container for containing the second medication and controlling the IoT medicine container to issue a first alert indicating to take the second medication; and in response to sensing that the second medication has been removed from the IoT medicine container within a predetermined time, controlling the IoT medicine container to relock, and in response to not sensing that the second medication has been removed from the IoT medicine container within the predetermined time, controlling the IoT medicine container to issue a second alert indicating to take the second medication.

2. The computer-implemented method of claim 1, wherein, the multi-medication pill further comprises a second medication, the filler surrounding the second medication.

3. The computer-implemented method of claim 1, wherein, the EEC is piezoelectric such that exposure to stomach acid from the patient powers the EEC.

4. The computer-implemented method of claim 1, wherein, the determining the dissolution pattern is performed during a trial run, the trial run comprising providing a first monitoring pill comprising the first medication and a medication monitoring embedded circuit, further exposure of the medication monitoring embedded circuit generating a signal sent to define a medication duration for the patient to dissolve the first medication, the trial run comprising providing a second monitoring pill comprising the filler and a filler monitoring embedded circuit, further exposure of the filler monitoring embedded circuit generating a further signal sent to define a filler duration for the patient to dissolve the filler.

5. The computer-implemented method of claim 1, wherein, the time gap prevents a drug product interaction between the first medication and the second medication.

6. A computer program product for providing medication to a patient with a time gap, the computer program product comprising: program instructions capable of performing the method of any one of claims 1-5.

7. A computer system for providing medication to a patient with a time gap, the computer system comprising: One or more computer processors for program instructions executed by at least one of the one or more processors capable of performing the method according to any one of claims 1-5.

Images