TW201506839A - State characterization based on multi-variate data fusion techniques - Google Patents

Abstract

The ingestible event marker data framework provides a uniform, comprehensive framework to enable various functions and utilities related to ingestible event marker data (IEM data). Included are a receiver adapted to be associated with a body of an individual, the receiver configured to receive IEM data; a hub to receive the IEM data; and at least one IEM data system to receive the data from the hub. Among other information, behavioral data and predictive inferences may be provided.

Description

State Characterization Based on Multivariate Data Fusion Technology [Cross Reference Related Applications]

The present application is filed in the U.S. Patent Application Serial No. 12/522,249, the entire disclosure of which is incorporated herein by reference. Part of the continuation case, the application is in the 371 application of PCT/US09/49618 filed on 2009/7/2, the application is based on 35 USC § 119(e), claiming to apply on 2008/7/8 The priority of U.S. Provisional Patent Application No. 61/079,082, the disclosure of which is incorporated herein by reference.

The present invention generally relates to the technical field of ingestible devices and communications. More specifically, and in various exemplary embodiments, the present invention is directed to a method, article, and system for generating, collecting, managing, distributing, and otherwise utilizing information associated with a swallowable event and responding to a swallowable event .

Information related to personal events is widely required in a variety of matters. Personal events are unique to individual events. Examples of personal events include the initiation of relevant physiological parameters, the ingestion of therapeutic agents, and the like.

There are many situations in which one may want to record a personal event. Examples of such situations include the initiation of one or more relevant physiological parameters, including the onset of disease symptoms, the administration of a drug, the ingestion of certain types of food, the initiation of motor control, the ingestion of a substance, and the like.

Various methods and techniques have been developed to record individual events. For example, techniques have been developed in which an individual can manually record data in a recording unit or physically input data via a computer device.

The accuracy of such records may depend on the accuracy of the data entry, the accuracy of the agent as an actual data replacement, and the like. As a result, inaccuracies may occur.

In one example, an individual may have one or more health conditions that require treatment with multiple medications. Multiple drugs can be specified based on complex and precise medication schedules. The complexity associated with multiple health conditions, multiple medications, and complex medication schedules can confuse patients, leading to inaccurate data capture.

In one instance, an individual may have physical or cognitive deficiencies that may result in difficulty in entering and capturing information. Individuals may forget to enter data or may enter data incorrectly.

In an example, an individual may not wish to cause inconvenience, and thus may deliberately refuse to enter data. Conversely, an individual may inadvertently or intentionally enter/record a completely incorrect material. For example, an individual may Receive periodic, scheduled reminders to take some medications. The reminder cannot take into account the actual swallowing of the drug. If the individual has taken the drug, the reminder has no practical meaning and may cause personal inconvenience. If you do not take the medicine, the inconvenience or unnecessary reminder or warning may prompt the user to input information or send a message, telling that the medicine has been taken only to calm the warning, but actually does not take the medicine. Individuals may deliberately save the data section.

In an example, the agent for data and information may also be inaccurate. For example, a "smart" drug container may contain a microchip that senses opening of a drug container. Based on the sensing behavior of the open container, it can be inferred that the drug associated with the drug container has been swallowed. However, the inference may be inaccurate because the drug is not necessarily swallowed by opening the drug container.

If a particular participant other than an individual wishes to use personal personal event data, the above situation may mature into a further problem. Examples of users and potential users of personal event data (sometimes collectively referred to herein as "participants") include family and professional care; communications companies; government agencies (eg, institutions associated with government-provided health care); Private insurance provider; Food and Drug Administration (FDA); Drug Control Agency (DEA); US Alcohol, Tobacco, and Firearms Bureau (ATF); Caregiver Provider; Medical Device Manufacturer; Patient; Clinician; Pharmacy; online community; software providers; marketing and financial analysts; and insurance companies.

Conflicting peers may exist between individuals' privacy interests in personal event data and by third parties to obtain and privately use personal event data.

In addition, different participants may have a compelling interest in receiving accurate and comprehensive information (eg, useful information), whether in isolation (information that is closely related to a particular individual) or experience (from different sources, individuals) Collection information of individual personal events, etc.).

However, in many cases, accurate personal event data cannot be obtained. Participants may have access to a rough approximation of the error data or information sought, as described above. Therefore, participants must rely on such a coarse agent to set conclusions. Then, following the above conclusions may themselves be skewed or inaccurate. Actions that rely on the above conclusions may prove to be misleading, error-prone, and/or harmful.

For example, when a patient actually provides information only and does not actually swallow the drug, the health care provider or family member may receive information from the patient indicating that the patient has taken the medication. If the health care provider notices a change in the patient's symptoms when it is close in time to receiving the wrong information about the recommended drug ingestion, the health care provider may erroneously infer that the patient's symptoms are the result of drug swallowing. Based on the erroneous inference, the health care provider may adjust the dose of the drug in an attempt to relieve the symptoms and may alleviate the patient's injury.

It is worth noting that the more widely disseminated and aggregated inaccurate data, the more dissemination and dependence on error-related information and conclusions derived therefrom.

In addition, recipients of personal event data may wish to receive and utilize the above information in a timely manner via easy-to-use, reliable and advanced tools. The recipient may wish to receive and/or utilize information in discrete areas, Integrate personal event information with other data and use personal event information for a variety of purposes.

Examples of various purposes include upgrading and optimizing data (such as patient population data); stimulating individuals or groups based on personal event data (eg, swallowable event marker data ("IEM data"); identifying and advancing decisions; supporting stakes Human decision making; use of IEM data in personalized products and services (eg, user applications on mobile phones); automatic re-preparation of drugs; management of drug lifecycle systems and controlled substances; compilation and transmission of IP news and information Supply; open source code to access anonymous patient population data; determine eligibility and permission for re-preparation; insurance coverage, etc.; use patient tools; participate in social networking systems; analyze aggregate data to obtain and/or generate forecasts Information; support and initiate financial transactions; identify direct and indirect causal failure points and predictive corrective actions in treatment; and provide dynamic, accurate history/scheduling capabilities.

Finally, participants may also wish to access personal event data in conjunction with existing systems (eg, commercial systems such as automated pharmacy systems, banking, and financial systems).

As can be seen, there is a need for methods and systems for seamlessly collecting, managing, and distributing personal event data to a variety of participants and systems.

Therefore, for various purposes, there is a need to controlly collect, manage, and transmit accurate personal event data to multiple profile participants.

Can be swallowed event marker data structure proposes a consistent, comprehensive The structure is designed to enable various functions and utilities related to the ingestion of event marker data (IEM data). Functions and utilities include information and/or information that has informational aspects derived, collected, aggregated, or otherwise associated from a swallowing event. In one example, the IEM data is generated via a swallowing device. The term "devour device" includes any device, mechanism, structure, combination structure, or article that can be swallowed by a human individual or a non-human subject.

The IEM data architecture is highly scalable and can be integrated with a variety of existing systems, such as systems with computer-related components. Specific examples of such systems include pharmacy systems, communication systems, financial and banking systems, school systems, medical systems, government agencies, online communities, and personal computer systems. The above existing systems are collectively referred to herein as "commercial systems."

The IEM data architecture enables multiple and various types of implementations. Implementation includes hardware, software, communication components, and/or various configurations of materials. For example, in one aspect, the IEM data architecture is based on a basic complement of core components (ie, swallowable event marker data), a hub for receiving swallowable event marker data, and is used to receive directly or indirectly from a hub. At least one ingestible event marker data system that ingests event marker data is implemented.

100‧‧‧Communication environment

102‧‧‧IEM data architecture

104‧‧‧IEM data environment

106‧‧‧Commercial system

200‧‧‧IEM information

202‧‧‧ hub

204‧‧‧IEM Information System

300‧‧‧IEM data source device

302‧‧‧Products

304‧‧‧ events

306‧‧‧ patient-specific parameters

308‧‧‧IEM data algorithm

310‧‧‧Storage repository

312‧‧‧Other sources

300a‧‧‧Candied device

300b‧‧‧IEM data receiver

300c‧‧‧Health device

302a‧‧‧Candied devices/drug products

306a‧‧‧ Personalized patient data

306b‧‧‧ Multiple patient data

400‧‧‧SMD Receiver

402‧‧‧Handheld devices

404‧‧‧Base Station

406‧‧‧Mobile Phone

204a‧‧‧Feedback loop system

204b‧‧‧Decision Support System

204c‧‧‧Automatic re-preparation system

204d‧‧‧Patient tools

204e‧‧‧Behavioral Medicine System

204f‧‧‧Incentive system

204g‧‧‧Personalized Commercial Products/Services

204h‧‧‧Automatic Billing System

204i‧‧‧Tracking System

204j‧‧‧Disabled system

204k‧‧‧Subscription system

204l‧‧‧IEM data collection system

204m‧‧‧License System

204n‧‧‧ forecasting system

204o‧‧‧Financial System

204p‧‧‧IEM data telephone system

204q‧‧‧Community Network System

500‧‧‧Server

502‧‧‧Software

504‧‧‧Database

506‧‧‧ patients

106a‧‧‧Health System

106b‧‧‧ pharmacy system

506a‧‧ patient

506b‧‧ patient

200a‧‧‧IEM information

200b‧‧‧IEM data

406a‧‧‧Mobile Phone

406b‧‧‧Mobile Phone

106c‧‧‧ dispensing system

106d‧‧‧University System

106e‧‧‧Financial Trading System

506c‧‧ patient

200c‧‧‧IEM information

106f‧‧‧Physician System

106g‧‧‧Home Care System

106h‧‧‧Online Community

106i‧‧‧Control Agency System

1402‧‧‧Scanner

1802‧‧‧Smart Pill Dispenser

106j‧‧‧Wholesaler/Retailer System

2302‧‧‧Data Logger

200a‧‧‧ Receiver data

200b‧‧‧data logger information

510‧‧‧Software module

510a‧‧‧ Analysis Module

510b‧‧‧Metric Module

510c‧‧‧ Forecasting Information Module

FIG. 1 provides a schematic diagram of a communication environment including an IEM data architecture in accordance with an embodiment.

Figure 2 provides an IEM fund according to Figure 1 of an embodiment. Schematic diagram of the material structure.

FIG. 3 illustrates an IEM data and an IEM data environment associated with the IEM data schema of FIG. 2, in accordance with an embodiment.

Figure 4 illustrates a hub associated with the IEM data architecture of Figure 2, in accordance with an embodiment.

FIG. 5 illustrates an exemplary IEM data system associated with the IEM data schema of FIG. 2, in accordance with an embodiment.

FIG. 6 illustrates an exemplary IEM data architecture with a feedback loop system in accordance with an embodiment.

FIG. 7 illustrates an exemplary IEM data architecture with a decision support system in accordance with an embodiment.

Figure 8 illustrates an exemplary IEM data architecture with an automatic re-dispensing prescription system in accordance with an embodiment.

Figure 9 illustrates an exemplary IEM data architecture with patient tools in accordance with an embodiment.

Figure 10 illustrates an exemplary IEM data architecture with a behavioral medical system in accordance with an embodiment.

Figure 11 illustrates an exemplary IEM data architecture with an incentive system in accordance with an embodiment.

Figure 12 illustrates an exemplary IEM data architecture with a personalized commercial product/service system in accordance with an embodiment.

Figure 13 illustrates an exemplary IEM data architecture with an automatic billing system in accordance with an embodiment.

Figure 14 illustrates a tracking system in accordance with an embodiment. Demonstrate the IEM data architecture.

Figure 15 illustrates an exemplary IEM data architecture with a blocking system in accordance with an embodiment.

Figure 16 illustrates an exemplary IEM data architecture with a subscription system in accordance with an embodiment.

Figure 17 illustrates an exemplary IEM data architecture with a swallowable event marker data collection system in accordance with an embodiment.

Figure 18 illustrates an exemplary IEM data architecture with a licensing system in accordance with an embodiment.

Figure 19 illustrates an exemplary IEM data architecture with a prediction system, in accordance with an embodiment.

Figure 20 illustrates an exemplary IEM data architecture with a financial system in accordance with an embodiment.

Figure 21 illustrates an exemplary IEM data architecture with a swallowable event tag data telephony system in accordance with an embodiment.

Figure 22 illustrates an exemplary IEM data architecture with a social networking system in accordance with an embodiment.

Figure 23 shows an exemplary module of the software of the exemplary IEM data system.

Figures 24a and 24b illustrate sample IEM data and sample metrics.

1.0 Overview

2.0 Swallowable Event Marker (IEM) Data Architecture

2.1 IEM data

2.1.1 IEM data environment

2.1.1.1 IEM data source device

2.1.1.2 Products

2.1.1.3 Events

2.1.1.4 patient specific parameters

2.1.1.5 IEM data algorithm

2.1.1.6 Storage repository

2.1.1.7 Other IEM sources

2.2 hub

2.3 IEM data system

2.3.1 Feedback loop

2.3.2 Decision Support System

2.3.3 Automatic re-preparation system

2.3.4 Patient Tools

2.3.5 Behavioral Medicine System

2.3.6 incentive system

2.3.7 Personalized Commercial Products/Services

2.3.8 Automatic Billing System

2.3.9 Tracking System

2.3.10 blocking system

2.3.11 subscription system

2.3.12 IEM data collection system

2.3.13 licensing system

2.3.14 prediction system

2.3.15 Financial System

2.3.16 IEM data phone

2.3.17 social network system

3.0 IEM Data Architecture Method

4.0 IEM data structure object

5.0 IEM Data Architecture System

6.0 IEM data architecture data modeling and regulatory results

1.0 Overview

The Swallowable Event Marker (IEM) data architecture provides an integrated, seamless solution to collect, manage, distribute, and utilize IEM data. The multi-purpose IEM data architecture facilitates the integration and implementation of IEM data with existing data and the use of IEM data with existing systems (ie, commercial systems). Information and communication systems include discrete systems, cross-configured systems, and hybrid systems.

In summary, various aspects of the IEM data architecture include basic complements of core components, such as IEM data; hubs; and at least one IEM data system. Any one or combination of these core components can be coupled, communicated, and/or integrated with various components of other information/communication systems. The terms "data" and "information" are used interchangeably herein.

IEM data includes information about swallowing events, responses Information about the event of ingestion, or both. Information about a swallowing event may include, for example, information about a swallowing event of a drug or group of drugs. Information regarding responses to swallowing events may include, for example, physiological parameters such as physiological states or physiological changes events based on swallowing events. The physiological state may be, for example, a heart rate, a blood pressure measurement, or the like that is determined in time close to the time of ingestion of the drug (and, therefore, may be affected by the result of the ingestion of the drug).

Examples of IEM data include data on the time of ingestion of the drug, identification of the type of drug that is swallowed at a particular time, the dose of the drug that is swallowed at a particular time, and the like.

Typically, IEM data can be generated and/or transmitted via an ingestible device such as an ingestible event marker (IEM) that generates and delivers data associated with a swallowing event. For example, the IEM may be associated with a receiver (ie, a device capable of receiving IEM data on a swallow and further capable of measuring additional IEM data in response to a swallow event). The IEM and receiver are discussed in detail below. In various aspects, swallowable event data may be derived from multiple swallow event markers. In various aspects, IEM data may be passed directly from the IEM to devices other than the receiver, for example, to an IEM commercial system that receives IEM data directly from the IEM via a communication channel.

In various aspects, IEM data may be associated with other data (eg, in conjunction with data related to events other than swallowing events or in response to swallowing events). Some examples of other materials are materials associated with various medical devices and materials associated with consumers and personal devices such as smart devices/devices. All of the content is discussed in more detail below.

In various aspects, IEM data may be related to the IEM data ring. And/or business system associations.

In various aspects, the IEM data may be associated with a unique identifier (eg, a sample data that reflects a physiological pattern associated with a particular individual, such as heart rate variability, respiratory rate, and/or heart rate (ECG) mode. For example, Some or all of the IEM data may be compared to a unique identifier generated by the receiver or stored on the receiver.

A hub includes any hardware device, software, and/or communication component, as well as systems, subsystems, and combinations thereof that are typically used to communicate IEM data. The communication of IEM data includes receiving, storing, disposing, displaying, processing, and/or transmitting IEM data.

In various aspects, the hub is also used to communicate (e.g., receive and transmit) non-IEM data. Non-IEM data includes non-IEM physiological data. One example is cardiac data generated by a separate cardiac related device, such as an implantable pacemaker, and delivered to the hub, for example, directly or indirectly via a receiver.

A wide variety of hubs include, for example, base stations, personal communication devices, and mobile phones.

For example, a hub includes a software application associated with a patient's mobile phone. The application and mobile phone are used to receive IEM data from the receiver, which in turn receives IEM data from the ingestible device that the patient swallows. The hub stores, handles, and/or forwards IEM data to the IEM data system, either alone or in combination with other data.

The IEM data system includes any hardware device, software, and/or communication components, and the above is generally used to provide information related to IEM data. Systems and subsystems of services or activities. For example, the IEM data system collects, processes, calculates, transmits, receives, stores, and/or delivers at least a portion of the IEM data.

Each IEM data system may be built around a predetermined function or service and may be initiated via an IEM data schema.

Integrate, interoperate, communicate with one or more IEM data systems, or otherwise share or facilitate the collection, management, distribution/distribution, billing, or other activities associated with IEM materials. An example of an IEM data system is a feedback loop system that enhances and optimizes IEM data and other materials, such as medical database data.

Various aspects of the IEM data architecture provide on-demand, accurate, and efficient services for the provision and utilization of IEM data, while reducing redundancy, errors, and inaccuracies associated with personal event data that is sometimes found in prior art techniques. degree. The various aspects of the IEM data architecture ensure that the accurate IEM data is generated and delivered in a timely manner.

In addition, the IEM data architecture can be adapted to any communication environment. The communication environment includes any internal communication with information or materials, or any environment associated with the communication of materials or materials.

Various aspects of the IEM data architecture utilize IEM data, hubs, and one or more IEM data systems to enable the useful, secure, and efficient use of IEM data among multiple profile participants in one or various communication environments.

FIG. 1 provides a schematic diagram of a communication environment 100 including an IEM data architecture 102, in accordance with an embodiment. The communication environment 100 can further include For example, the IEM data environment 104 and one or more business systems 106.

The communication environment 100 includes any environment in which information or materials are communicated internally or in connection with the communication of materials or materials. Communication includes any method, action, or vehicle of communication, and/or combinations thereof. For example, communication methods include manual, wired, and wireless. Wireless technologies include radio signals such as X-rays, ultraviolet light, visible spectrum, infrared, microwave, and radio waves. Wireless services include voice and communications, handheld and other network-enabled devices, data networks, and more.

The vehicle for communication includes the Internet, wired channels, wireless channels, communication devices including telephones, computers, wires, radios, optical or other electromagnetic channels, and combinations thereof, including other devices capable of communicating data/associated with the transmitted materials. And / or components. For example, the communication environment includes intra-body communication; various devices; various modes of communication such as wireless communication, wired communication, combinations of the above, and the like.

Intra-body communication includes any communication via the body's data or information, ie, via or in connection with a physical aspect, a physical aspect, and combinations thereof. For example, a physical aspect includes communication associated with a device designed to be attached to a body surface. In-vivo aspects include communication associated with information generated from within the body (eg, by the body itself or by implantation, swallowing, or otherwise localized, or partially in the body).

Communication includes and/or may be associated with software, hardware, circuitry, various devices, and combinations thereof.

The device includes data generation, transmission, reception, and communication with the IEM. Associated devices such as news. The device further includes various implantable, ingestible, insertable, and/or attachable devices associated with the human body or other living organisms. The device also includes multimedia devices such as telephones, stereo devices, audio players, PDAs, handheld devices, and multimedia players.

The wireless communication mode includes any communication mode between points that utilizes, at least in part, wireless technology, including various protocols and protocol combinations associated with wireless transmissions, data, and devices. Points include, for example, wireless devices such as wireless earphones; audio and multimedia devices and devices such as audio players and multimedia players; telephones, including mobile phones and wireless phones; and computer and computer related devices and components such as printers.

The wired communication mode includes any communication mode between points that utilizes wired technology, including various protocols and protocol combinations associated with wired transmissions, materials, and devices. Points include, for example, devices such as audio and multimedia devices and devices (such as audio players and multimedia players); telephones, including mobile phones and wireless phones; and computer and computer related devices and components, such as printers.

The IEM Data Architecture 102 enables the exchange, transmission, reception, handling, management, storage, and other activities and events associated with IEM materials. Such activities and events may be included within the IEM data schema 102, partially with the IEM data schema 102, or with external transactions (eg, activities, systems, components, etc. outside of the IEM data schema 102). External things include, for example, the IEM data environment 104 and the business system 106, either or both of which may be integral to, or partially integrated with, the IEM data architecture 102.

The IEM data environment 104 includes any source of information or information, including remote computer systems, local computer devices, and the like. Information or materials may contain all or part of the IEM data. Information or materials may also be independent of IEM data, for example, may be integrated and/or integrated with IEM data.

Commercial system 106 includes various existing systems that utilize one or more types of materials for a particular purpose. An example of a commercial system is a computerized pharmacy system for a pharmacy. A computerized pharmacy system can be used to automatically (eg, electronically) receive prescriptions, verify patient and prescription information, verify insurance coverage, process prescription orders, and generate invoices.

The IEM data schema 102, the IEM data environment 104, and the business system 106 are discussed in more detail below.

2.0 IEM Data Architecture

FIG. 2 provides a schematic diagram of an IEM data architecture 102 in accordance with FIG. 1 of an embodiment. The IEM data architecture 102 includes an IEM data 200, a hub 202, and one or more IEM data systems 204.

IEM data 200 includes data associated with a swallowing event (ie, a swallowing behavior). In addition, IEM data 200 can be included in, or incorporated in, data from other systems or sources (eg, medical devices, local or remote computer devices and systems, etc.). Examples of IEM data 200 are data that identify the type of drug being swallowed and the time of ingestion of the drug.

Hub 202 includes any hardware, software, and/or communication component of any combination/configuration that is typically used to communicate IEM data 200. An example includes passing IEM data 200 to an IEM data system 204. For example, hub 202 receives IEM data 200 from a swallowing device and forwards IEM data 200 to IEM data system 204, either alone or in combination with data from other sources.

The IEM data system 204 provides discrete services and/or activities related to the IEM data 200. Discrete services and/or activities include disseminating information, materials, etc. to a particular user, or group of users, for example via various system component configurations.

In an example, the automatic re-preparation system receives IEM data 200 from hub 202. The IEM data 200 includes an indication of the last remaining pill that has been swallowed. The automated re-preparation system uses this information to access local or remote sources with re-prescription information, verify re-subscription information, and automatically transmit requests to the pharmacy system (commercial system) for re-preparation.

2.1 IEM data

The Ingestible Event Marker (IEM) data 200 is associated with at least one of a swallowing event and a response to a swallowing event. The swallowing event may be associated with, for example, data associated with and/or collected during delivery through the digestive system (eg, mouth, pharynx, esophagus, stomach, small intestine, large intestine, anus, etc.). Examples of IEM data include the time of ingestion, the identification of the swallowed food, the expiration date of the relevant drug, the dose of the swallowed food, and the like. Information about a swallowing event may include, for example, information about a swallowing event of a drug or group of drugs. Information regarding the response to a swallowing event may include, for example, physiological parameters such as physiological status based on a swallowing event or a physiological change event. Physiological state may be an example Such as the heart rate, blood pressure measurement, etc. determined in time close to the swallowing time.

In various aspects, IEM data 200 can typically be generated via one or more of the ingestible event markers (IEMs) discussed in more detail below. The generation of IEM data via multiple IEMs ensures comprehensive data reporting, for example, data generated from multiple swallowing events of multiple IEMs over time intervals, data generated from multiple IEMs swallowed at approximately the same time, etc. Wait. In this way, comprehensive IEM data can be provided.

In various aspects, the IEM data can be passed to the receiver (ie, received by the receiver). Receivers may be implemented in a variety of ways, including implantable devices, semi-implantable devices such as subcutaneous devices, and external application devices such as personal signal receivers. One example of a personal signal receiver is a "patch" receiver that may be detachably secured to individual people, clothing, and the like.

In various aspects, the IEM data 200 can be associated with other data (eg, personal events not associated with a swallowing event or responses to a swallowing event). A personal event includes any parameter or condition associated with an individual, for example, any event associated with ingestion, inhalation, injection, implantation, insertion, and/or drinking of a device, substance, liquid, or the like. Personal events also include any event associated with personal data (eg, physiological parameters such as weight).

In various aspects, the IEM data may be associated with a unique identifier, such as a heart rate variability, a breathing rate, and/or an heart rate (ECG) pattern associated with a particular individual. Can be implemented differently Do not match. An example is a personal identifier assigned to an individual, such as a text number or the like. Another example is a unique identifier that reflects personal traits, such as a physiological pattern.

For example, a patient may swallow an IEM integrated into a drug (discussed below). The IEM can pass the IEM data to a receiver, such as the patch receiver (discussed below). The data may include, for example, a unique identifier that may be compared to the data associated with the receiver for verification purposes.

In one scenario, IEMs associated with drugs prescribed for a particular patient may each be encoded and deployed with corresponding unique identifiers. The unique identifier may be, for example, a predetermined physiological data sample associated with a particular patient. Various physiological data samples include data samples that reflect the variability of the heart rate of a particular patient, data samples that reflect the respiratory rate of a particular patient, data samples that reflect the heart rate (ECG) pattern of a particular patient, and the like.

When the receiver is fixed or otherwise associated with an individual, the programming logic associated with the receiver may, for example, receive an actual data sample of the individual from a data source such as a cardiac device. The receiver may pass the actual data samples received from the data source and the unique identifier received from the IEM to a computer-related device (eg, a server), which may compare the actual data sample of the individual with a unique identifier to verify that the drug is actually The specific patient being prescribed is swallowed. In various aspects, predetermined actions based on the results of the verification may be taken, for example, alerts may be sent to devices associated with the prescribing physician, and the like.

2.1.1 IEM data environment

In various embodiments, IEM data 200 is generated, received, aggregated, etc. from one or various sources and includes various structures, content, types, and the like. The IEM data environment includes at least one of an IEM source device, a product, an event, a patient-specific parameter, an IEM data algorithm, and a storage repository. Sources include, for example, various devices, storage reservoirs, and materials capable of generating, identifying, aggregating, or otherwise producing an environment associated with ingestion, swallowing (eg, a human or non-human individual's digestive system), and/or other personal events. system. Types include, for example, raw materials, processed materials, aggregated materials, combined materials, materials from various sources, and the like. Processing data includes, for example, data processed in accordance with various methods (e.g., algorithms for IEM data algorithms as discussed below).

FIG. 3 illustrates an IEM data environment 104 associated with the IEM data schema 102 of FIG. 2, in accordance with an embodiment. IEM data environment 104 includes, for example, IEM data source device 300, product 302, event 304, patient specific parameters 306, IEM data algorithm 308, storage repository 310, and other sources 312.

2.1.1.1 IEM data source device

Ingestible Event Indication (IEM) data source device 300 includes, for example, devices capable of aggregating, collecting, generating, receiving, storing, and/or transmitting IEM data. One example of such a device is a microchip capable of or otherwise enabling or facilitating the collection, generation, reception, transmission, etc. of data. The microchip described above can be integrated or associated with the IEM data source device 300. The IEM data source device 300 can be implemented as, for example, a swallowable device 300a, receiver 300b, and/or health device 300c.

In various aspects, IEM data may be associated with various devices. For example, the device may be an ingestible device, an inhalable device, an injectable device, an implantable device, an insertable device, and a drinkable device. The above may be implemented as, for example, microchips, alone or in combination with other structural elements, each capable of being ingested, inhaled, injected, implanted, inserted, and consumed by a human or non-human body.

The ingestible device may comprise, for example, a microchip. It is possible to deploy the microchip independently. The microchip can also be attached to, embedded in, or otherwise integrated with a drug (eg, a pill) (hereinafter referred to as an IEM system).

The inhalable device can comprise, for example, a microchip. The microchip can be deployed independently. The microchip can also be attached to, embedded in, or otherwise integrated with the device. The inhalable device is capable of determining parameters associated with inhalation, for example, measuring or calculating an inhaler dose. The inhalable device can also include, for example, a respirable microchip for determining parameters (e.g., inhalation time, identifying inhaled material, etc.).

The injectable device can comprise, for example, a microchip. The microchip can be deployed independently. The microchip can also be attached to, embedded in, or otherwise integrated with the device. The injectable device is capable of determining parameters associated with the injection, such as injection time, identification of the injected substance, and the like. In various aspects, the injectable device can be injected into the human body or non-human body, for example, into the circulatory system of the human body.

The implantable device can comprise, for example, a microchip. The microchip can be deployed independently. The microchip can also be attached to, embedded in, or otherwise The way is integrated with the device. The implantable device is capable of determining parameters associated with implantation, such as implantation time, such as heart rate, EKG data, activity management data, temperature, skin current response data, respiratory data, fluid status data, heart rate variability, etc. Physiological parameters such as.

In one aspect, the implantable device is implemented as an implantable receiver as described above for receiving various materials. The implantable receiver can also process, store, transfer and other data. Various other implantable devices include, for example, cardiac monitors having microchips for determining parameters (e.g., heart rate, heart pressure, etc.).

The pluggable device can comprise, for example, a microchip. The microchip can be deployed independently. The microchip can also be attached to, embedded in, or otherwise integrated with the device. The pluggable device is capable of determining parameters associated with the insertion, such as insertion time, physiological parameters such as environmental content/fluid identification, and the like. In one aspect, the insertable device is implemented as a microchip that is mechanically associated with a suppository for rectal insertion, vaginal insertion, and the like.

The drinkable device can comprise, for example, a microchip. The microchip can be deployed independently. The microchip can also be attached to, embedded in, or otherwise integrated with a substance (eg, a drinkable solution or fluid such as a beverage). The drinkable device is capable of determining parameters associated with drinking, such as drinking time, physiological parameters such as environmental content/fluid identification, and the like. In one aspect, the drinkable device is implemented as a microchip and is consumed with the beverage. Beverages may aid in swallowing, possibly as a medicine, and so on.

In addition, IEM data can be associated with the administration of a therapeutic agent. For example, administration includes, but is not limited to, parenteral administration, that is, in addition to Administration outside the system, such as by intravenous or intramuscular injection or inhalation.

In some aspects, the device can be swallowed, i.e., into the digestive system of the human or non-human body; inhaled (device or substance associated with the device, such as a nasal inhaler). In various aspects, the device can be injected, inserted, implanted, and/or drunk into the human body or non-human body/injected, inserted, implanted, and/or drunk by the human or non-human body.

The ingestible device 300a collects/collects/generates IEM data via various methods (eg, swallowing timing, contacting digestive system materials, sampling, etc.). In addition, various ingestible event marker data source devices 300 deliver IEM data via various methods (eg, wireless methods, conductive methods via body tissue, etc.). The following is an example of an ingestible device 300a.

A dispensing information system as described in PCT/US2006/016370, filed on Apr. 28, 2006, which is incorporated herein by reference in its entirety, is incorporated herein by reference in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in its entirety in Examples of ingredients include an identifier and an active agent.

The IEM system described in PCT/US2008/52845, filed on Feb. 1, 2008, includes an ingestible event marker (IEM) and a personal signal receiver. Aspects of the IEM include identifiers that may or may not be present in a physiologically acceptable carrier. The identifier is characterized by being activated when it contacts the internal physiological part of the target of the body, such as the target site inside the digestive tract. The personal signal receiver is configured to associate with a physiological location (eg, within or on the body) and receive signals from the IEM. During use, IEM is widely used The signal received by the personal signal receiver is broadcast.

The IEM data associated with the IEM system includes personal data, such as physiological data generated by the IEM. An instance is a derived metric, such as processed physiological data, used to derive various metrics, such as swallowing time data; combined metrics, for example, in conjunction with other derived metrics (eg, derivation time data in conjunction with data identifying the swallowing quality) And IEM data, for example, derived metrics and/or aggregated metrics of various physiological data (eg, swallowing time data combined with information identifying the quality of the swallowed food and physiological data such as ECG data, temperature, etc.).

The controlled start-up ingestible identifier described in PCT/US07/82563, filed on October 17, 2007, includes ingestible ingredients, such as ingredient-initiated ingredients. The controlled activation ingestible identifier includes a controlled activation element that provides an activation identifier in response to the presence of a predetermined stimulus in the relevant target site.

The life cycle dispensing information system described in U.S. Patent Application Serial No. 61/034,085, filed on Mar. 5, 2008, which is incorporated herein by reference in its entirety, is incorporated herein by reference in its entirety in its entire entire entire entire entire entire entire entire entire entire entire entire entire entire entire entire entire entire entire all The system further allows for the transfer of data within the body while addressing the potential for privacy and signal degradation associated with RFID technology.

The IEM data receiver 300b includes means capable of receiving IEM data 200. For example, the reception may be via a wireless or wired channel, and the like. The IEM data receiver 300b may also transfer or otherwise transfer data. In various aspects, the IEM data receiver 300b can perform, facilitate, or otherwise enable various types of IEM data 200 and/or other materials. He functions. In various aspects, the IEM data receiver 300b may be attached, implantable, semi-implantable, or otherwise associated with the human or non-human body.

The IEM data receiver 300b includes a personal signal receiver such as a patch receiver, for example, removably externally attached to a human body or a non-human body; a subcutaneous device; an implantable device; an external device, ie, not designed for attachment Connect or other devices that are permanently or semi-permanently in contact with the body, such as a mobile phone. The following is an example of an IEM data receiver 300b.

The IEM system (PCT/US2008/52845 above) includes a swallowable event marker (IEM) and/or a personal signal receiver.

An effective signal processing personal health signal receiver as described in PCT/US07/24225, filed on Nov. 19, 2007, includes a receiver associated with the body (eg, located in or near the body), configured to be located from the body The internal body transmitter receives and decodes the signal.

Health device 300c includes a plurality of devices (and methods associated with the devices) associated with IEM data 200. For example, health device 300c may aggregate, collect, aggregate, store, transmit, receive, or otherwise communicate data (including IEM data 200).

For example, the reception can be via a wireless or wired channel, and the like. The IEM data receiver may also transmit or otherwise transfer data. In various aspects, IEM data receiver 300b can perform, facilitate, or otherwise enable various other functions associated with IEM data and/or other materials. Examples include functions for storing data, processing data, and the like.

In various aspects, the health device 300c may be attachable, Implantable, semi-implantable or otherwise associated with the human or non-human body. For example, "smart" devices such as the Intelligence Scale, the Smart Blood Pressure Cuff, and the Smart Refrigerator can be integrated into various configurations. As used herein, the term "smart device" refers to one or more devices capable of generating and/or transmitting data (eg, wirelessly transmitted material) to a destination via a communication channel.

2.1.1.2 Products

The IEM data 200 also includes IEM data associated with the product 302. Product 302 includes, for example, an ingestible device/drug product 302a. One example of an ingestible device/drug product 302a is an IEM that is mechanically associated with the drug. IEM may be mechanically associated with the drug in a variety of ways, including external fixation to the drug, partial integration with the drug, and complete integration with the drug.

The IEM can be fixed via various tools (eg, with various adhesives or formulation materials). The IEM may be associated with the drug at different stages (eg, during the drug manufacturing process, at different points in time after the drug manufacturing procedure, etc.).

2.1.1.3 Events

The IEM data 200 further includes information related to events 304 (eg, personal events, event parameters, etc.). Other examples include the time of ingestion of the drug, the dosage and characteristics of the drug taken while ingesting, and the like. Events may include physiological events (eg, respiratory rate); environmental events (eg For example, date and time; use events (eg, swallow medication, use a cardiac resuscitation device), and so on.

2.1.1.4 patient specific parameters

The IEM data 200 further includes data relating to patient-specific parameters 306, such as personalized patient data 306a for individual patients and multiple patient data 306b for multiple patients. Examples of patient-specific parameters include physiological data and the like. The plurality of patient data includes aggregated patient data, patient demographic data, for example, combined patient data, including various predetermined aspects of information about at least one patient and excluding data that tends to identify a particular patient, or wherein the patient has privacy Interest (eg, name, age, diagnosis, and/or aspects of the patient's desire to retain other information that is confidential and/or not disclosed to the public).

2.1.1.5 IEM data algorithm

The IEM data 200 also includes information related to the IEM data algorithm 308, such as raw material, processed data, or a combination of the above (which is processed). In one example, IEM material 200 has one or more algorithms applied thereto, with the processed material being output. For example, the data includes personalized patient data 306a and a plurality of patient data 306b, for example, patient demographic data.

The IEM data algorithm can be related to data processing aspects as associated with IEM data 200 generated by one or more ingestible devices (eg, IEM systems).

Regarding IEM data processing associated with a swallowable device, aspects include, for example, transmission of IEM data 200, IEM data processing associated with the receiver, and post-processing of IEM data.

Transmission aspects of IEM data and algorithms may include, for example, modulation architecture, coding, and error code patterns.

Transmission patterns include analog, digital, spread spectrum, combination, and contention avoidance.

Analog transmission patterns include, for example, amplitude modulation, signal sideband modulation, frequency modulation, phase modulation, quadrature amplitude modulation, and spatial modulation methods, and the like.

Digital transmission patterns include on/off keying, frequency shift keying, amplitude shift keying, phase shift keying (eg, binary phase shift keying), quadrature phase shift keying, high order and differential encoding quadrature amplitude Modulation, minimum shift keying, continuous phase modulation, pulse position modulation, interleaving modulation, and orthogonal frequency division multiplexing.

Spread spectrum transmission patterns include, for example, frequency hopping spread spectrum and direct sequence spread spectrum.

The combined transmission aspect includes, for example, binary phase shift keying with carrier frequency modulation.

The competition avoidance transmission aspect includes, for example, duty cycle modulation and carrier frequency modulation.

The coding aspects include, for example, a wake-up architecture, a pre-architecture, a data packet architecture, and an error code architecture.

Wake-up architectures include, for example, multi-tone architectures and hum architectures.

The pre-architecture includes, for example, a unique identifier for the packet start architecture.

The data packet architecture includes, for example, information related to the type of pill, the duration of the pill, the manufacturer, the lot number, the number, the prescribing physician, the pharmacy, and the like.

Error code architectures include, for example, repetitive architecture, co-located architecture, checksum, cyclic redundancy check, Hamming distance architecture, and forward error correction architecture, such as Reed-Solomon code, binary Gray code, whirling code, turbo code, and many more.

Regarding IEM data processing and receivers, for example, location, energy efficient architecture, carrier identification, decoding, and error correction may be considered.

The location of the receiver includes, for example, the stomach, the side, and the xiphoid.

The energy-saving architecture includes an architecture for periodic wake-ups, for example, to sense IEM wake-ups such that energy (eg, battery resources) is conserved during non-warning periods.

Carrier identification aspects include, for example, Fourier transform analysis (eg, Fast Fourier Transform and Discrete Fourier Transform), phase-locked loops, filter banks, matched filters, and combinations that are tuned using prior knowledge about frequency.

Decoding aspects and error correction patterns include, for example, the iterative aspects described above.

With regard to post-processing of IEM data, aspects include, for example, pill detection, for example, multiple identification and time counting, adhesion metrics, and the like.

Regarding IEM data processing associated with physiological parameter metrics, such as electrocardiogram (EKG or ECG), impedance, acceleration, light, pressure, temperature, sound, biochemistry/biological, weight, location, derived electromyography ( EMG), and brain wave measurement technology (EEG).

IEM data processing associated with EKG includes, for example, compressed data (eg, wavelet and ICA/PCA, R-wave detection such as Hamilton-Tompkins, etc.), heart rate variability (eg, SDNN, standard deviation in a 24-hour period) , standard deviation of consecutive five-minute cycles, footprint heart rate versus standard heart rate, distribution-based histograms, etc.), arrhythmia, and respiration (eg, spindle modulation).

Impedance-related IEM data processing includes, for example, breathing, fluid status, skin electrical response, blood flow, and the like.

Acceleration related IEM data processing includes, for example, direct acceleration, which includes total activity and derived acceleration, which further includes activity types.

Light-related IEM data processing includes, for example, blood volume ratio, O2 saturation, pulse oximetry analyzer, and the like.

Temperature-related IEM data processing includes, for example, body temperature, heat flux, and the like.

Sound related IEM data processing includes, for example, heartbeat sounds, valve events, and the like.

Biochemical/biological related IEM data processing including, for example, lactose, glucose, antibodies, biological indicators, bacteria, permeability, etc. Wait.

The IEM data processing associated with the derived material includes, for example, sleep, total energy, and the like.

2.1.1.6 Storage repository

The ingestible event marker data also includes information relating to the storage repository 310, ie, a database and/or other storage practices, which temporarily and/or permanently retain, store, and the like, and information relating to the IEM data, including Ingestion of event marker data combined or aggregated data.

The storage may be in any form or format as known or will be known in the future. In various aspects, storage repository 310 may be implemented independently and/or may be partially or fully integrated with a computer related system. For example, storage repository 310 can be interoperable with, or otherwise associated with, various computer systems, software, hardware, communication components, and the like. For example, storage repository 310 may be part of a medical office computer system and may include IEM data 200 associated with medication control for a particular patient. At various times (eg, predetermined or temporary), various IEM materials 200 that are implemented as medical materials may be passed from different points/elements to storage repository 310 and/or from storage repository 310 to different points/elements.

In another illustration, a method, system, and composition for treating a patient according to a patient-customized treatment control as described in PCT/US2007/1068, filed on May 2, 2007, which is incorporated herein by reference. Information and use it to tailor treatments to patients and to prepare and transfer physiological drug doses to patients based on customized treatment controls. For example, from illness Human dosing information can be stored in database 306. IEM data 200 containing information about the time of ingestion of a particular drug can be combined with dosing information to customize treatment control.

2.1.1.7 Other IEM sources

Various other IEM data sources 312 can be included in various aspects. In addition, it is noted that data and/or IEM data 200 from multiple sources can be aggregated, integrated, and enhanced via various methods. For example, IEM data 200 such as swallowing data associated with a swallowed drug is generated from an IEM data source device 300, such as an IEM system. The swallowed data is transmitted wirelessly to the IEM receiver.

At the same time, or in another time period, physiological data such as cardiac parameters are generated by the health device 300c, such as a system for monitoring and treating hemodynamic parameters, which is generated and transmitted wirelessly to the IEM data receiver 300b. IEM data 200 and cardiac physiology data are collected for forward transfer to an IEM data system such as an automated re-preparation system.

For example, cardiac data is derived via various methods and systems. An example is continuous field tomography, for example, electrical tomography (ET). A continuous field tomography method is described in U.S. Patent Application Serial No. 60/797,403, filed on May 2, 2006. Cardiac data includes cardiac related parameters, as well as clinical data for clinical applications. Use ET to measure various cardiac parameters such as cardiac output, ejection fraction, dP/dt (maximum), myocardial injury rate (maximum), peak systolic mitral circumferential velocity, ventricular end-systolic volume, Ventricular end diastolic volume Product, and QRS length, and so on. Cardiac measurements can be used to derive or deduce various performance and health diagnoses/inferences. For example, the ejection fraction parameter may be used as a basis for predicting ventricular synchronization performance.

Metrics resulting from continuous field tomography include, for example, velocity, acceleration, and displacement.

Clinical data derived from metrics include, for example, left ventricular toughness and ET agents for other physiological parameters such as ejection fraction (EF) and dP/dt.

In various aspects, clinical data may be combined with IEM data to provide additional information. For example, information may be useful in the pursuit of various diagnostics and analysis. A comprehensive patient-relevant data with clinical data and IEM data is shown in U.S. Patent Application Serial No. 61/076,577, filed on Jun. 27, 2008, which is incorporated herein by reference. Displayed together with IEM data for the time of drug ingestion. According to the above display, the effect of drug treatment can be measured.

2.2 hub

Hub 202 includes any hardware device, software, and/or communication component, and systems, subsystems that are typically used to communicate IEM data 200 (including receiving, storing, processing, displaying, processing, and/or transmitting IEM data 200). And a combination of the above.

In various aspects, hub 202 receives, generates, communicates, and/or transmits IEM data 200, either alone or in combination with other materials (ie, non-IEM data from various sources). Non-IEM data includes non IEM physiological data. Examples of non-IEM data include heart rate, heart rate variability, respiration, physiological activity level, wake mode, temperature, and the like.

Passing IEM data 200 to hub 202 and passing IEM data 200 from hub 202 includes any transport tool or carrier, and combinations thereof, including wireless, wireline, RF, as is known in the art or as may become available in the future. Conductivity and the like.

FIG. 4 illustrates a hub 202 associated with the IEM data architecture 102 of FIG. 2, in accordance with an embodiment. Hub 202 includes various types of devices, such as personal communication devices, base stations, and mobile phones.

Personal communication devices include, for example, devices having communication and computer functions and are generally intended for personal use, such as mobile phones, sometimes referred to as "handheld devices."

The base station contains any device or device capable of receiving information such as IEM data. Examples include computers (such as desktops and laptops), and smart devices/devices.

Smart devices/devices include consumers and home devices and devices that are capable of receiving information such as IEM data. Smart devices/devices can also perform other data related functions, such as transferring, displaying, storing, and/or processing data. Examples of smart devices/equipment include devices and devices having refrigerators, weighing scales, washrooms, televisions, door frame activity monitors, bedside monitors, bed scales. Such devices and devices may include additional functions such as sensing or monitoring various physiological parameters such as weight, heart rate, and the like.

Mobile phones include telephone communications associated with various mobile technologies Device (for example, a cellular network).

In one aspect, hub 202 includes an IEM data receiver implemented as, for example, a receiver of patch receiver 400; a personal communication device such as handheld device 402; a base station 404; and a mobile telephone 406.

Patch receiver 400 includes, for example, a device capable of receiving at least data, signals, and the like. The patch receiver 400 may be attachable, for example, permanently or removably externally attachable to a human or non-human body. For example, the patch receiver 400 may include a receiver and an adhesive layer to provide attachment to and removal from the skin area. Additionally, the patch receiver 400 may be implantable or semi-implantable, for example, subcutaneously implanted. One such removable attachable patch receiver 400 is the personal signal receiver of the IEM system described in the aforementioned PCT/US2008/52845.

Handheld device 402 (also referred to as a "mobile computer") includes, for example, a computing device having computer-related functions (eg, a display screen that typically has a touch input function, a small keyboard, etc.). Types of handheld devices include, for example, personal digital assistants (PDAs) that incorporate inputs and outputs incorporated into the touchscreen interface; and integrated data capture such as bar codes, radio frequency identification (RFID), and smart card readers. The enterprise digital assistant of the device.

In various aspects, handheld device 402 includes software associated with IEM data 200, such as a software agent/application. In various embodiments of the handheld device 402, the soft system is pre-configured (ie, configurable by the manufacturer/retailer); can be configured by the consumer (ie, Station download); or a combination of the above.

An example of a software is an automated re-preparation application associated with or integrated with an automated re-preparation system to facilitate automated prescription re-prescription functions.

Base station 404 includes systems, subsystems, devices, and/or components that receive, transmit, and/or relay IEM data 200. In various aspects, the base station can interoperate with a receiver such as patch receiver 400 and a communication network such as the Internet. Examples of base station 404 are computers, such as servers, personal computers, desktop computers, laptops, smart devices/devices, and the like as discussed herein before.

In various aspects, base station 404 can be implemented as an integral unit or distributed component, such as a desktop computer and a mobile phone that communicate with one another and with a patch receiver and the Internet.

In some aspects, base station 404 includes an IEM for wirelessly receiving and/or wirelessly transmitting data (e.g., received from patch receiver 400 and the Internet and transmitted to patch receiver 400 and the Internet). The function of the data 200).

Additionally, in various aspects, base station 404 can be coupled to and/or associated with (eg, communicated with) various devices. The above apparatus may generate, receive, and/or communicate data (e.g., IEM data 200). Devices include, for example, clock radios, smart pill dispensers, pill managers (eg, devices capable of receiving various substances and producing binding substances, substance doses, etc.), drug measuring devices, "smart" devices such as gauges, blood pressure measurements Devices, sports equipment (eg, treadmills). Other examples include weight Sensors, motion sensors, position sensors, for example, bed sensors, chair sensors, entrances to doorways, refrigerators and food sets, bathroom fixtures, and the like.

The mobile telephone 406 includes, for example, a short range of devices, a portable electronic device for mobile voice or data communication over a network of dedicated cell website base stations. Mobile phone 406 is sometimes referred to as "action", "wireless", "cellular phone", "mobile phone", or "mobile phone (HP)".

In addition to the standard voice capabilities of the phone, various embodiments of the mobile phone can support many additional services and accessories, such as short message service (SMS) for text communication, email, and packet exchange for accessing the Internet. , java games, Bluetooth (short-range data/voice communication), infrared, cameras with cameras, and MMS for sending and receiving photos and videos. Some embodiments of mobile phones are connected to a cellular network of a base station (cell site) that in turn is interconnected to a public switched telephone network (PSTN) or satellite communications in the case of a satellite telephone. Various embodiments of the mobile phone can be connected to the Internet, at least a portion of which can be navigated using a mobile phone.

In various aspects, the mobile phone 406 includes software, such as a software agent/application associated with the IEM profile 200. One example is an automated re-preparation application associated with or integrated with an automated re-preparation system to facilitate automated prescription re-prescription. In various embodiments of mobile phone 406, the soft system is pre-configured (ie, configurable by the manufacturer/retailer); configurable by the consumer (ie, downloadable from the website); Or a combination of the above.

In addition, various embodiments of the hub ensure privacy requirements via a predetermined method, for example, the IEM data source device 300 swallowed by the individual transmits the sensitive IEM data 200 via body tissue to the patch that is removablely attached to the individual's body. The IEM data receiver 302 implemented in the device 400. The signal associated with the sensitive IEM data 200 is still not detectable outside of the individual's body. When received by patch receiver 400, the various computing elements of patch receiver 400 clear and/or encrypt IEM data 200 for later secure transmission. In this way, it is possible to avoid damaging sensitive data transmission and/or unauthorized access to sensitive data.

In addition, various aspects of the hub include a combination of devices. One such combination is the IEM data receiver 300b of the patch receiver 400 in communication with the handset 402 or mobile telephone 406. Thus, for example, patch receiver 400 wirelessly transmits IEM data 200 to mobile phone 406 having a receiver and a software agent available thereon. The receiver of the mobile telephone 406 receives the IEM data 200. A software agent (e.g., an application) processes the swallow report data 200 and displays various information related to the IEM data 200 via, for example, a customized graphical user interface (GUI). In some aspects, the software agent generates a display with a predetermined "look and feel" that the user can identify as belonging to a predetermined set of software programs, GUIs, source devices, communities, and the like.

To illustrate the above, the IEM data 200 may include information about the ingestion of the drug. When received by the mobile phone 406, the software agent can compare the information about the medication with the predetermined medication control. When verification is already in When the appropriate medication is swallowed at the appropriate time, the software can be scheduled to alert the individual to an audible alert of the medication that has been swallowed, thereby avoiding unnecessary reminders and removing the associated problems. The software agent displays standard information on the individual notification of the swallowed drug and the time of the next medication via the GUI.

In addition, the software agent may include functionality to generate or facilitate financial transactions. In one example, when an event occurs, such as verifying that the appropriate medication has been swallowed at the appropriate time, the software agent generates a predetermined fee for the ingested medication, the verification service, or both. The fee is transmitted to the financial system, for example, the patient's mobile phone transmits the fee via the IEM data system to a computer system associated with the patient's financial institution (where the patient's financial account is automatically charged).

In various other aspects, the trading model may be based on various parameters. In one example, the transaction is associated with a time-based model in which the product or service is charged for use based on the length of time the product or service is used. In another example, the transaction is associated with a measurement value transfer, wherein the value of the product or service is measured, measured, or otherwise valued and charged based on the value determined at the predetermined time interval. In yet another example, the transaction is associated with a treatment delivery (ie, delivery of a therapeutic substance, event, service, etc.). Examples of therapeutic substances include drugs. Examples of treatment events include cardiac defibrillation behavior and cardiac resynchronization behavior. Examples of therapeutic services include therapeutic administration, therapeutic counseling, and the like.

2.3 IEM data system

IEM data system 204 includes any hardware components, software elements The components, and/or communication components, and the networks, systems, and subsystems generally used to provide services, functions, activities, and the like associated with the IEM profile 200. For example, the IEM data system collects, processes, calculates, transmits, receives, stores, and/or otherwise communicates at least a portion of the IEM data.

Each IEM data system is built around a predetermined operational function or service and is enabled via an IEM data architecture. One or more IEM data systems may be integrated, interoperable, communicate with each other, or otherwise share or facilitate collection, management, distribution/distribution, billing, and/or other activities related to IEM materials.

Additionally, one or more IEM data systems can be associated with one or more business systems. For example, one or more IEM data systems can be integrated, interoperable, and/or in communication with one or more commercial systems. One or more IEM data systems may otherwise share or facilitate IEM material related activities with one or more commercial systems.

The IEM data system 204 includes at least one component (eg, hardware device, software, and/or communication component) that is typically used to provide services or activities related to the IEM profile 200, such as receiving IEM data 200 from the hub 202 and displaying IEM data 200 along with other information on the computer.

Examples of components include computers, receivers, transmitters, applications, software modules, data storage media, processors, memory components, personal communication devices, software, communication links, and handheld devices. Note that two or more IEM data systems 204 can be used cooperatively or independently One or more of the same components. For example, an automated re-preparation system and a licensing system can each access a data storage medium having IEM data associated with the patient and the prescription, and can utilize the IEM data for each intended purpose.

FIG. 5 illustrates an exemplary IEM data system 204 associated with the IEM data schema of FIG. 2, in accordance with an embodiment. The exemplary IEM data system 204 includes, for example, a feedback loop system 204a, a decision support system 204b, an automated re-preparation system 204c, a patient tool 204d, a behavioral medical system 204e, an incentive system 204f, a personalized commercial product/service 204g, an automated billing system 204h. The tracking system 204i, the blocking system 204j, the subscription system 204k, the IEM data collection 204l, the licensing system 204m, the prediction system 204n, the financial system 204o, the IEM data telephony system 204p, and the social network 204q.

2.3.1 Feedback loop system

The feedback loop system aggregates various sources of information (eg, IEM data), analyzes aggregate data, and/or provides feedback information to multiple profile recipients based on aggregation/analysis.

FIG. 6 illustrates an exemplary IEM data architecture 102 including a reverse loop system 204a, in accordance with an embodiment. Feedback loop system 204a includes, for example, a server 500 having an application 502 and a repository 504. The IEM data architecture 102 further includes an IEM profile 200 and a hub, which is implemented herein as a mobile phone 406. In various aspects, feedback loop system 204a can interoperate with, or otherwise be associated with, one or more IEM data systems 204 and/or one or more commercial systems 106.

In one scenario, patient 506 devours a drug with an ingestible device integrated therein. The ingestible device produces IEM data 200 in the form of drug identification and swallowing time information. The ingestible device transmits information to the receiver. The receiver sequentially passes the information to the hub 202 of the mobile telephone 406 that is implemented in association with the patient 506.

The software agent set present on the mobile phone 406 receives the drug identification and swallowing time information and blood pressure measurement information, and forwards the aggregate information to the feedback loop system 204a. The feedback loop system 204a having the server 500, the software 502, and the database 504 receives the aggregate data from the mobile phone 406, and compares the aggregated data with the patient information in the database 504 via the software 502 to determine whether the patient 506 is taking the most recent time. The dose of the drug, whether the patient 506 has taken the drug consistently and in a timely manner, and whether the blood pressure measurement meets the acceptable range of blood pressure measurement.

Based on the analysis of the data, the feedback loop system 204a generates additional IEM data 200 in the form of decisions regarding patient compliance and decisions on efficacy of the treatment. The IEM data 200 decision making system is stored in the database 504 for future reference and forwarded to a commercial system, such as a healthcare system 106a associated with a medical center computer system and having patient information such as a physician's medication indication.

The healthcare system 106a facilitates automated processing and feedback, enables accessibility to the IEM profile 200 (eg, via a healthcare provider), enables data entry (eg, via a healthcare provider's healthcare instructions), and the like.

For example, health care system 106a compares feedback loop systems 106a receives the decision information and the stored health care provider instructions, for example, medication control compliance is satisfactory, and no action is required at this time; medication control compliance is not satisfactory, and action is required at this time; Medication control compliance is compliant, but actions are required at this time (eg, titration, etc.) and comparison results are generated for review by the healthcare provider.

Health care providers use information to advantageously adjust patient treatment parameters, such as prescriptions and dosage requirements. The healthcare provider enters the data based on the comparison results (eg, adjusted treatment parameters). The input data is processed by the healthcare system 106a and forwarded to the feedback loop system 204a. The feedback loop system 204a receives the feedback loop data, conforms the feedback loop data to the patient information present in the database 504, and forwards the notification to the mobile phone 406 of the patient 506.

In various aspects, feedback loop system 204a and/or healthcare system 106a interacts with (eg, communicates with) at least one other IEM data system 204 and/or business system 106.

To continue the previous description, in addition to forwarding the adjusted medication control indication to the patient's mobile telephone 406, the feedback loop system 204a or healthcare system 106a also transfers the adjusted medication control in the form of a prescription to, for example, the pharmacy system 106b. Commercial systems for reconstitution. The pharmacy system 106b formulates a prescription and communicates the information to the feedback loop system 204a that is notified of the above. The feedback loop system 204a updates the patient data in the database 504 to reflect the implementation of the new prescription and prescription and communicates the notification to the patient's mobile phone 406.

2.3.2 Decision Support System

A decision support system (eg, a personal health system) can generate, store, and provide information (eg, IEM data) that can be used to notify and support decisions (eg, stakeholder decisions). In one example, multiple instances of personalized swallowable event marker data and physiological data are aggregated and combined into anonymous patient demographic data. Medical research and development groups, universities, etc. use information for various purposes, for example, to customize new product lines, adjust existing treatments, and the like. For example, data can be accessed by subscribing to a population data supply, accessing a database, and the like.

FIG. 7 illustrates an exemplary IEM data architecture 102 with a decision support system 204b, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM profile 200 and a hub 202, shown here as a mobile phone 406. In various aspects, feedback loop system 204a can interoperate with, or otherwise be associated with, one or more IEM data systems 204 and/or one or more commercial systems 106.

In one scenario, IEM data (eg, IEM data 200a and IEM data 200b) associated with a plurality of individuals (eg, patient 506a and patient 506b, respectively) via a hub (eg, mobile phone 406a and mobile phone 406b, respectively) It is passed to a decision support system 204b that includes, for example, server 500, software 502, and database 504. IEM data 200a and 200b can be encrypted. The decision support system 204b processes and stores the received data. For example, the software 502 anonymizes the patient profile, ie, removes all aspects of the profile that tend to identify the individual, and according to a predetermined architecture To remove all aspects of material that are designated as private, sensitive, confidential, and so on. The software 502 can provide various other functions, such as integrating the existing patient demographic data in the anonymous patient data and database 504.

The consolidated material in database 504 can be accessed by multiple systems and participants, transmitted to multiple systems and participants, or otherwise utilized by multiple systems and participants. Such systems include, for example, a commercial system 104, such as a dispensing system 106c and a university system 106d. Participants associated with dispensing system 106c may utilize patient demographic data, for example, for statistical analysis and reporting capabilities, such as determining the efficacy of a particular drug, cost efficiency, profit, etc. and from determining new product line concepts/therapy responses, and the like. Participants associated with the university can use patient demographic data to study symptoms, analyze medication risks, and more.

In various aspects, the decision support system 204b, the IEM data system, and/or the business system interoperate (e.g., communicate) therebetween.

To continue the previous description, in addition to providing decision support data such as patient demographic data, decision support system 204b also communicates patient demographic data to feedback loop system 204a. Feedback loop system 204a communicates patient population data to mobile phone 406a of patient 506a.

In one scenario, decision-making data derived from the patient population (eg, drug efficacy) may be associated with an individual's medication and delivered via a marketing system specific to that individual.

2.3.3 Automatic re-preparation system

The automatic re-preparation system automatically formulates or refills the prescription. In one example, IEM data identifying the swallowed medication is aggregated and consistent with current prescription information to identify depleted prescription supplies. If the supply is exhausted, the re-preparation order is automatically triggered for the appropriate pharmacy. Pharmacies automatically reorder orders, generate bills, and charge for appropriate accounts, for example, via instant, online financial transactions.

FIG. 8 illustrates an exemplary IEM data architecture 102 with an automatic re-preparation system 204c, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM data 200 and a hub 202, shown here as a base station 404. In various aspects, the automatic re-preparation system 204c can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, patient 506 incorporates a decoy device to swallow a prescription medication. The ingestible device identifies the drug type and dosage and transmits the IEM data 200 to the patch receiver 400 via, for example, conductive transmission, which may be removably attached to the patient 506. The tile receiver 400 transmits the IEM data 200 to the base station 404. Base station 400 forwards IEM data 200 to automatic re-distribution system 204c. The software 502 of the automatic re-preparation system 204c compares the drug type and dose of the IEM data 200 with the prescription information stored in the database 504. The prescription information may include, for example, the number of lozenges in the formula at the time of formulation, the dose indication, and the swallowed lozenge in total in accordance with the operation of each previously received information. If the comparison indicates that the prescription drug is exhausted, the database 504 is checked for the quantity of the remaining refilled prescription. If the prescription is left over, the sensitive data of the IEM data 200 is cleared (ie, removed), and The prescription re-subscription request with relevant information is compiled and transmitted to the commercial system 106, such as the pharmacy system 106b, via a predetermined channel in accordance with a predetermined security protocol. When received by the pharmacy system 106b, the reconstitution request is parsed and verified, and the prescription is refilled.

The reconstitution payment can be performed, for example, via an instant, online transaction between the pharmacy system 106b and the IEM data system 204 and/or the commercial system (eg, the financial transaction system 106e). For example, the financial transaction system 106e can receive financial transactions, such as prescription reissue fees, via a predetermined communication channel. The financial transaction system 106e verifies the patient account information and completes the transaction, notifying the pharmacy system 106b.

The status of the re-prescription and the notification of the re-subscription payment can be provided to the base station 300 via a predetermined communication channel, for example, an email for display on the laptop, a text message for the patient's mobile phone, etc. Wait.

2.3.4 Patient Tools

Patient tools include any information, information, software, websites, etc. that provide information or assist in the concentration of specific patients, for example, tracking tools to assist patients with cardiac health management, patient personalization of their own data, and the like. Various users can be associated with patient tools. Examples include various users within a patient community, such as patients, home care, and professional care as a physician.

FIG. 9 illustrates an exemplary IEM data schema 102 with a patient tool 204d, in accordance with an embodiment. IEM data architecture 102 is even more packaged The IEM data 200a-c and hub are shown here as a base station 404, a mobile phone 406, and a handheld device 402. In various aspects, patient tool 204d can interoperate with, or otherwise be associated with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, multiple participants, such as patients 506a-c, access patient tool 204d, which can be implemented as a server 500 having software 502 and a database 504 having IEM data 200 in the form of at least a patient tool. The patient 506a-c can access the patient tool 204d, for example, via the base station 404, the mobile phone 406, and the handheld device 402, respectively.

Patient 506b may search database 504 for patient tools associated with psychiatric management. Patient tools can be provided, for example, in the form of downloadable materials/applications to assist in tracking, monitoring, diagnosing, and notifying patient-related health issues, such as medication scheduling, and the like. Patient 506b can download the application to, for example, mobile phone 406. Patient 506b may further communicate with at least one commercial system, such as mobile phone 406, such as health care system 106a (which may provide further medical information, instructions, etc. related to the psychiatric management tracking of patient 506b).

In various aspects, patient tool 204d can be configured for and utilized by a variety of participants other than patients, such as patient communities, home care, and professional care.

2.3.5 Behavioral Medicine System

Behavioral medicine systems can collect, track, and analyze behavioral data to identify causal failure points in treatment and repair by prescription specific behavior Change to predict the corrective action. In various aspects, the behavioral medical system can assist the patient via questionnaires and patient profile assessments on the subject of symptoms or treatments, for example, in a variety of decision-making procedures that guide a series of questions and receive answers from patients by displaying a menu.

FIG. 10 illustrates an exemplary IEM data schema 102 with a behavioral medical system 204e, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM profile 200 and a hub, shown here as a base station 404 and a mobile phone 406. In various aspects, behavioral medical system 204e can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, behavioral medical system 204e (e.g., a software agent) may be located, in whole or in part, on a patient-related device, such as mobile phone 406. The software agent can make every effort (eg, diet choices, smoking cessation, etc.) to assist the patient. For example, assistance can be provided by generating a set of mobile phone 406 questions relating to diet and smoking cessation. The patient can answer questions, for example, from a variety of answer options. Based on the patient's answer to the question, the software agent can classify the patient according to a predetermined category. The software agent can provide language and menu selection based on patient classification.

In another scenario, patient behavior is tracked for various IEM data (eg, patient parameters), sometimes referred to herein as "healthy markers." Examples of healthy markers include medication adherence, weight, blood pressure, and the like. Healthy markers may be obtained, for example, from various health devices 300c (eg, intelligence scales, heart related devices, etc.).

For example, patient 506 devours the medicine according to the physician's instructions. Things. The IEM data 200 in the form of a swallowing information identifying the swallowed drug and the time of ingestion is retrieved via the ingesting device and delivered to the patient's mobile phone 406. The blood pressure and body weight of the patient are also taken through the health device 300c when the drug is swallowed. The timing of the above data capture can be synchronized via, for example, using a reminder system to alert the patient to the software for taking the medication at a particular time. When receiving swallowing information (eg, confirming swallowing), the software associated with mobile phone 406 can communicatively trigger health device 300c to determine blood pressure and weight, and forward the data to mobile phone 406 to aggregate with IEM data 200 as a swallowing information. Form.

The aggregate data can be forwarded to the behavioral medical system 204e, which can be configured, for example, as a mobile phone and software 406, a server 500 including the software 502 and the repository 504, and/or other configurations. Various processing can occur when receiving aggregate data.

An example of a treatment is to analyze the IEM data 200 to determine the extent to which the patient is following medication control, i.e., to determine if the patient is swallowing the prescribed medication at the correct dose for a prescribed time interval.

An example of another treatment is to analyze the IEM data 200 to determine if the blood pressure measurement meets the physician's expectations. Thus, the patient's notification of compliance with medication control and blood pressure measurements can be communicated to physician system 106f for examination by the patient's physician. The physician can update the IEM data 200 in sequence, for example, to determine if medication control needs to be adjusted, and to communicate the medication control 406 to the patient's mobile phone 406 and pharmacy system 106b via a behavioral medical system to formulate the updated prescription.

If it is a non-compliance judgment, the physician may pass the behavioral doctor The system 204e alerts the patient to an appointment for a physical examination. In various aspects, behavioral medical system 204e can generate and/or forward alerts to a hub (e.g., mobile phone 406 of patient 506). For example, reminders may include medication schedules, reminders for upcoming medications, instructions to follow if a medication is missed, and the like.

If the medication is insufficient/overdose, the behavioral medicine system 204e can interoperate with an alarm system (eg, the IEM data telephone system described above) and compare the current medication information with a predetermined threshold to determine whether a critical state medication event exists, eg, a patient Insufficient medication or overdose in critical situations. If the above determination is made, the appropriate system may alert the appropriate participant, for example, to generate a 911 emergency call for medical assistance, to generate an emergency alert to the physician system 106f, and to the home care system 106g (eg, a family member's mobile phone) Generate an alert.

In yet another scenario, the patient's communication mode/habit is analyzed to determine patient parameters, indicative actions, and the like. For example, an application such as software 502 present on mobile phone 406 tracks the patient's phone usage to determine the mode of communication. For example, home care, physicians, etc., may selectively configure parameters of the tracking application to determine various patient communication thresholds, modes, and the like. The software monitors communication from a selected device (e.g., the patient's mobile phone 406)/to a selected device (e.g., the patient's mobile phone 406). In various aspects, the application mines the mobile phone record of the associated carrier to determine the call and called party, a large amount of call time, no call time, etc., and establishes a profile for it. The application monitors the use of the mobile phone 406 and identifies the meaning, for example, the user selected and the profile Deviation. When the deviation is identified, the application initiates a predetermined action, for example, via the healthcare system 106a, the physician system 106f, and/or the home care system 106g to communicate the alert to the physician and/or home care.

Another example of processing is the analysis of IEM data 200 along with data from another source (eg, collection data). The aggregate material can be collected from various sources, aggregated at various and/or multiple points, and/or delivered to/from various devices via various channels.

For example, cardiac data is derived via electrical tomography, as discussed above. The cardiac data is transmitted, for example, directly or indirectly by the patch receiver 400 to a software application on a hub (e.g., mobile phone 406). The software application on the mobile phone 406 assembles the heart data and the IEM data (eg, the pill swallows related material) and displays the various materials via a graphical user interface (GUI).

After registration, the behavioral medicine system determines that the patient has neglected to take the medication at the appropriate time. A reminder alert for the upcoming medication take-up time is sent to the patient via a mobile phone. When an alarm is received, the patient swallows the medication in time, causing a change in the health marker.

2.3.6 incentive system

The incentive system provides incentives and discounts through a variety of programs. Incentives and discounts are based on IEM data or otherwise associated with IEM data. The IEM data can be analyzed via, for example, the IEM data system 204 to determine if a particular criterion/critical value/target is significant. Based on the decision, an incentive associated with or associated with the criterion/threshold/target can be generated.

11 illustrates an exemplary IEM data architecture 102 having an excitation system 204f, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM profile 200 and a hub, shown here as a mobile phone 406. In various aspects, the incentive system 204f can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, patient compliance is tracked for various patient parameters (eg, medication and compliance). This can be used to reward incentives. For example, patient 506 swallows the medication according to the physician's instructions. The IEM data 200 in the form of a swallowing information identifying the swallowing medication and the time of ingestion is retrieved via the ingesting device and transmitted to the patient's mobile phone 406, and the behavioral medical system 204e. The behavioral medical system 204e verifies that the patient 506 is in compliance with the prescription medication control and sends the verification to the incentive system 204f. The incentive system 204f determines the price paid for the medication via the software 502 and the repository 504 and issues a discount or owe to the cost. For example, a discount may be issued and the financial transaction in the discount amount is posted to the patient's financial account via the financial transaction system 106e.

In another example, the discount may be delivered and administered to an account associated with the patient via a pharmacy system 106b having, for example, a next re-subscription of the medication for the patient.

In another example, the patient's blood pressure and body weight can be retrieved via the health device 300 as the drug is swallowed. The timing of the above data capture can be synchronized by using a reminder system to alert the patient to the software for taking the medication at a particular time. When receiving swallowing information (for example, confirming swallowing), and action The software associated with phone 406 may communicatively trigger health device 300c to determine blood pressure and weight, and forward the data to mobile phone 406 to aggregate with IEM data 200 in the form of ingestion information. The aggregate data can be passed to the incentive system 204f, where the software 502 and/or the database 504 can be used to determine if the patient's weight and blood pressure meet an acceptable predetermined threshold. For example, if the weight exceeds an acceptable threshold, the incentive system 204f may generate an incentive in the form of a local fitness club discount member. Various data parameters and demographics (eg, patient location, subtracted body weight, health assessment based on personalized patient health parameters, participation in a health club's list) can be used to construct the offer.

The motivation can be communicated to the patient 506 via, for example, the patient's mobile phone 506.

2.3.7 Personalized Commercial Products/Services

Personalized commercial products/services provide basis or personalized commercial products and services for IEM materials.

FIG. 12 illustrates an exemplary IEM data architecture 102 having a personalized commercial product/service system 204g, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM profile 200 and a hub 202. In various aspects, the commercial product/service system 204g can be implemented as, for example, an IEM data device, such as a patch receiver. In various aspects, commercial product/service system 204g can interoperate with, or otherwise be associated with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, the commercial product/service system 204g includes A receiver that is easy for consumers to use, such as a patch receiver. The receiver contains a variety of accessories and combines various designs. For example, a child's patch receiver can include a cartoon character decal. Young people's patch receivers can include a tattoo-like design. Other examples include IEM data receivers that are implemented/integrated into accessories, such as earrings, navy rings, and other tools for accessories, and the like.

The commercial product/service system 204g also includes brand or "community" related products and services.

2.3.8 Automatic Billing System

The automated billing system receives, processes, and/or facilitates payments via a financial account. The automated billing application associated with the automated billing system and/or with the financial institution system seamlessly interoperates to generate bills, verify account holder information, charge for accounts, and the like. Update the report to reflect the payment information. Similar applications are available for prescriptions, consumer products, information via personal devices, and more.

FIG. 13 illustrates an exemplary IEM data architecture 102 with an automatic billing system 204h, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM profile 200 and a hub, shown here as a handheld device 402. In various aspects, the automatic billing system 204h can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, various participants (eg, patient 506, physician, pharmaceutical company, etc.) subscribe to the information provision/patient demographic data of IEM data 200 to facilitate operational goals, manage healthcare, and the like. Participants can Receiving information supply/accessing demographic data, etc. via various devices. For example, patient 506 can receive a supply of information via hub 202 implemented as handheld device 402, which may generate a financial transaction via a software agent in the form of an invoice for the information provided by patient 506. Payment can be made via automated methods.

In the patient selection method, for example, the patient selects various payment options via a software agent present on the handheld device 402. A payment transaction is generated and passed to the financial transaction system 106e. The financial transaction system 106e automatically charges the account associated with the patient 506. A confirmation of the payment along with a digital (eg, electronic) copy of the invoice is provided to a software agent present on the handheld device 402 for viewing by the patient 506, and the like.

In an automated method, for example, billing and/or financial transactions are automatically generated in accordance with predetermined criteria. Predetermined criteria include, for example, transmitting information associated with information feeds or other sources, accessing data collection (eg, patient population data stored in a database), and the like. The participants select various payment options via a software agent present on the handheld device 402, and the payment transaction is generated and passed to the financial transaction system 106e. The financial transaction system 106e automatically charges the account associated with the patient 506. The confirmation of the payment, along with a digital copy of the invoice, is provided to a software agent present on the handheld device 402 for viewing by the patient 506, and the like. For example, the healthcare provider can access patient demographic data stored in decision support system 204b via healthcare system 106a. The software of decision support system 204b can cooperate with software 502 and database 504 of automatic billing system 204h to identify the participants that will be billed for access. Once identified, the automatic billing system 204h may automatically generate billing and/or financial transactions for access via one or more of the above channels.

2.3.9 Tracking System

Tracking systems track and integrate product movement data. In one example, the life cycle of an ingestible device can range from manufacturing tracking to shipping, drug inventory, delivery to a patient, swallowing, and expelling.

Figure 14 illustrates an exemplary IEM data architecture 102 with a tracking system 204i, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM data 200 and a hub, shown here as a scanner 1402. In various aspects, tracking system 204i can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, the drug manufacturer produces an ingestible device 302a, such as a specific drug having an IEM system device inside. The IEM system device contains various IEM data 200, such as drug identification, lot number, lot number, and manufacturer identification. The scanner 1402 can be utilized at different times/locations to scan the ingestible device 302a and retrieve the IEM data 200 associated therewith. The IEM data 200 can then be stored, processed, etc. via software 502 and database 504, such as tracking system 204i. For example, the IEM data 200 can be read by the scanner at the point of shipment and when received by the pharmacy to ensure inventory control, distribution integrity, and chain of custody of restricted drugs, and the like.

For example, tracking information can be used by regulatory agency system 106i to determine strict controls, and the like.

2.3.10 blocking system

Block system tracking, coordination, and support blocking programs. Blocking programs include, for example, programs associated with drug identification and use detection, search and seizure activities by swearing personnel, and the like.

Figure 15 illustrates an exemplary IEM data architecture 102 with a blocking system 204j, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM data 200 and a hub, shown here as a scanner 1402. In various aspects, the blocking system 204j can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, the drug manufacturer produces an ingestible device 302a, such as a specific drug having an IEM system device inside. The IEM system device contains various IEM data 200, such as drug identification, lot number, lot number, and manufacturer identification. The scanner 1402 can be utilized at different times/locations to scan the ingestible device 302a and retrieve the IEM data 200 associated therewith. The IEM data 200 can then be passed to, for example, the software 502 and the repository 504 of the blocking system 204j, where the IEM data 200 can be accessed by the regulatory agency system 106i and passed to the regulatory agency system 106i to facilitate various regulatory and enforcement functions, to identify omissions. Controlled substances, intercepting contraband, identifying unknown substances, and otherwise supporting institutions and regulatory activities.

In various aspects, for example, IEM data 200 can be passed from tracking system 204i to blocking system 204j/from blocking system 204j to tracking system 204i for processing, storage, and the like. For example, IEM data 200 can be read by the scanner at the point of shipment and read by the pharmacy to ensure inventory control, distribution integrity, and chain of custody of restricted drugs, and the like. The scanned (read) IEM data 200 can be coordinated between the blocking system 204j and the tracking system 204i to ensure full shipment, tracking shipments through various jurisdictions, and the like. In one example, IEM data 200 such as identifier data, shipping information, patient information, recipient information, and business activities are tracked and coordinated to intercept contraband and otherwise support institutional and regulatory activities.

2.3.11 subscription system

The subscription system is able to subscribe to various IR information offerings and data/knowledge collections, such as the IEM data collection system. For example, patients subscribe to IEM data feeds and/or IEM data collections, which aggregate data sources and integrate data into integrated, personalized information based on user requirements. Information fusion can include, for example, personalized medication control and alerting applications, personal community information, music, and the like. For example, information can be automatically billed based on a single point of the charging model on a round-robin basis. The agent can be set up as part of an embedded device, such as a standard application on a mobile phone, and the like.

Figure 16 illustrates an exemplary IEM data architecture 102 having a subscription system 204k, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM profile 200 and a hub, shown here as a mobile phone 406. In various aspects, subscription system 204k can interoperate with one or more IEM data systems 204 and/or one or more business systems 106, or Associated in other ways.

In one scenario, patient 506 subscribes to various information feeds and/or IEM data collections, which are discussed in detail below. Information offerings include, for example, structured and unstructured information on various topics generated or transmitted from various sources (eg, websites, blogs, etc.). IEM data collection includes a storage repository with IEM data. The storage repository can be associated with the subscription system 204k (eg, constituting it as a whole or away). For example, the IEM data collection may be partially or fully present in the repository 504 of the subscription system 204k.

In one scenario, IEM data 200 is passed from a subscription source to a user (eg, a user's device). Subscription sources include, for example, IEM data system 204, for example, database 504 of subscription system 204k, feedback loop system 204a, patient tool 204d, and decision support system 204b; business system 106b, for example, online medical and business information/news sources, Health care system 106a; and other sources, such as devices associated with patient 506, hubs, and the like. Users include, for example, individuals, groups, or resources (eg, databases, computer systems, servers, networks, etc.).

In various aspects, the subscription service can be initiated via, for example, a software agent present on the hub or with a local or remote system, such as healthcare system 106a.

In various aspects, the subscription service can be billed and paid via, for example, the subscription system 204k and the financial transaction system 106e.

In various aspects, the subscription news feed/data can be combined or integrated into a single or multiple news feeds, for example, the softness of the subscription system 204k Body 502 and/or database 504 can enable data collection, and the like.

For example, patient 506 subscribes to a health news feed and a pharmacy news feed via subscription system 204k, with one or more having IEM data 200. The patient subscribes by selecting an application (e.g., a software agent present on the hub), illustratively implemented as a mobile phone 406. When the patient has selected the subscription option, the order is passed to the subscription system 204k, which authenticates, processes, stores, and bills the order via the software 502 and the repository 504. The user's financial account can be automatically charged, for example, by passing the invoice information to the financial transaction system 106e associated with the user's account. The confirmation of the fee can be communicated from the financial transaction system 106e to the user via the subscription system 204k and/or the mobile phone 406.

Based on the user parameters, the subscription system 204k receives health news feed information and pharmacy news feed information. The software 502 of the subscription system compares the user profile of the patient 506 in the repository 504 with the user profile found in the pharmacy news feed (eg, a patient prescribed for medication for cardiac therapy). Based on the comparison, the software 502 separates the information related to the user's pharmacy news feed, combines the relevant information with the health news feed information, and communicates the news feed information to the mobile phone 406 for access and display.

2.3.12 IEM data collection system

The IEM data collection system provides/promotes access/storage of IEM data. Examples of IEM data include patient demographic data and electronic medical records. In various aspects, IEM data collection may include functions related to the collection, management, disposal, storage, distribution, and billing of IEM data.

FIG. 17 illustrates an exemplary IEM data architecture 102 having an IEM data collection system 2041, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM profile 200 and a hub, shown here as a handheld device 402. In various aspects, IEM data collection system 204l can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, patient demographic data (eg, anonymous empirical patient data) is stored in one or more repositories (eg, database 504 of IEM data collection system 204l). The IEM data 200 associated with one or more patients 506, such as the IEM data system 204, such as the behavioral medical system 204e, the subscription system 204k, the patient tool 204d, and the like, and the health care system 106a, the dispensing system 106c, A business system such as university system 106d receives patient demographic data.

In various aspects, the IEM data collection system 204l can be incorporated into a single entity and/or logical location (eg, the repository 504 of the server 500 of the IEM data collection system 204l), or distributed across two or more systems or Locations (e.g., remotely distributed across multiple IEM data systems 204), associated with commercial system 106, and/or distributed between IEM data collection system 2041 and other systems/locations.

The multi-profile user can access, utilize, and/or provide the IEM data collection system 204l. Multiple profile users include, for example, individuals or groups that use various methods/devices for accessing, utilizing, and/or providing. Examples of multi-profile users include patient 506, family members and family care, professionals, academics, businesses, and the like. Method/apparatus These include hub devices such as mobile phones, base stations, handheld devices, and the like, as well as system components associated with IEM data systems and business systems, such as laptops associated with university networks, tables associated with home care system 106g Computer, and so on.

To continue the previous description, the researcher uses the university system 106d to access the IEM data collection system 204l via the Internet or the like, and to query the patient population data, extract various materials, and the like.

In various aspects, the IEM data collection system 204l includes privacy assurance, authentication, and authentication mechanisms for financial, medical, and other privacy information. For example, the software 502 can authenticate the user. Software 502 can clear/verify the data to ensure that the predetermined privacy threshold is met.

2.3.13 licensing system

The licensing system aggregates and/or analyzes the various materials to enable the notified licensing decisions.

Figure 18 illustrates an exemplary IEM data architecture 102 with a licensing system 204m, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM data 200, a hub, shown here as a handheld device 402, and an associated smart pill dispenser 1802. In various aspects, licensing system 204m can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, patient 506 turns on smart pill dispenser 1802, for example, a dispenser with microchips and communication capabilities. Patient 506 removes the drug with the IEM system from the smart pill dispenser 1802 pill. The smart pill dispenser 1802 senses the removal of the pill via its microchip, receives information from the IEM system that the patient 506 has swallowed the pill, and determines the remaining amount. If the remaining amount is less than the predetermined threshold amount, the smart pill dispenser 1802 passes the re-submission request to the licensing system 204m. The licensing system 204m verifies information associated with the patient 506 via, for example, the software 502 and the repository 504, such as patient name, prescription identification, drug swallow verification, re-subscription timing, and the like. The licensing system 204m can interoperate (e.g., communicate) with various IEM data systems 204 and/or business systems 106 to obtain/verify information. For example, the material provided to/present in the licensing system 204m may be consistent with the medical record of the healthcare system 106, the reconstitution prescription request granted by the licensing system 204m, and the refill prescription delivered to the pharmacy system 106b.

2.3.14 prediction system

Predicting system aggregate data and/or facilitating analysis of aggregate data/data collections to obtain/generate prediction information.

FIG. 19 illustrates an exemplary IEM data architecture 102 having a prediction system 204n, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM data 200 and a hub, shown here as a base station 404. In various aspects, prediction system 204n can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, for example, base station 404 receives IEM data 200 from an ingestible device associated with patients 506a-c. Base station 404 The IEM data 200 is passed to an IEM data collection system 204l, which anonymizes the IEM data 200 and aggregates the anonymous IEM data 200 with patient demographic data.

The IEM data collection system 204l communicates all or a portion of the patient population data to the prediction system 204n, wherein the software 502 (eg, one or more applications) processes the patient population data to obtain various statistics, conclusions, predictions based on predetermined requirements, goals, and the like. Wait. For example, software 502 processes patient demographic data and correlates various data such as blood pressure readings over a predetermined period of time with medications administered in accordance with medication control to determine the overall efficacy of medication control and to predict titration of patient dose based on overall efficacy findings.

A plurality of profile participants (e.g., an analyst using the medication system 106e, a mechanism using the regulatory agency system 106i, and a researcher using the university system 106d) access the prediction system 204n. A plurality of profile participants utilize various tools (e.g., software 502) to run an analysis and prediction application for the patient demographic data and a combined prediction system 204n to access the various predictive data available.

2.3.15 Financial System

The financial system supports and enables financial transactions associated with IEM materials. In various ways, the financial system can interoperate with existing automated banking systems and networks.

Figure 20 illustrates an exemplary IEM data architecture 102 having a financial system 204o, in accordance with an embodiment. The IEM data architecture 102 further includes an IEM data 200 and a hub, which is shown here as a mobile phone. 406. In various aspects, financial system 204o can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, patient 506 places an order for a product/service (eg, a news feed service) from subscription system 204k via mobile phone 406. Subscription system 204k interoperates with financial system 204o via its software. For example, the subscription system 204k securely communicates encrypted patient financial information (eg, an account number) and subscription information. The financial system 204o authenticates the patient information and securely interoperates with the patient's financial institution, for example via a business system 106, such as the financial transaction system 106e, to charge the patient's account, and to provide fee information/confirmation to the patient 506, for example, via the mobile phone 406.

2.3.16 IEM data phone

The IEM data phone launches the IEM data related application. For example, applications include a pill control scheduling application, an alert reminder application, an automated re-application for drugs, a patient tool application, a social networking application, an incentive tracker application, and an automated billing application. Programs, subscription applications, licensed applications, and financial trading applications. Applications can be integrated, associated, or independent of each other. The application may be further installed by the manufacturer on the IEM data phone, downloaded by a wholesaler, retailer, user, etc. or otherwise installed. Installation may be independent or bundled with other software, products, etc. In various aspects, the application is user configurable, downloadable, updatable, and the like.

In various aspects, IEM dataphones and/or their applications can share common features, such as a common user graphical user interface (GUI); a trademark brand, ie, a collection of ideas and ideas that represent economic producers. Make specific symbols for names, logos, slogans, design structures, etc.). IEM data telephony may also include various connectivity architectures (eg, internet and cellular); multimedia capabilities may be provided; and various hardware and software configurations may be implemented. The IEM data phone can be implemented in various devices (e.g., mobile phone 406, handheld device 402, etc.).

Figure 21 illustrates an exemplary IEM data architecture 102 having an IEM data phone 204p, in accordance with an embodiment. For example, the IEM data phone 204p can be used as a hub. The IEM data architecture 102 further includes an IEM data 200. In various aspects, the IEM data phone 204p can interoperate with, or otherwise be associated with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, the IEM data phone 204p includes software 502, such as a selection of branded applications, such as pill control schedules, alert reminders, automatic refill prescriptions, patient tools, social networks, incentive trackers, automatic billing , subscriptions, licenses, and financial applications.

The Pill Control Schedule application accepts, coordinates, schedules, and manages contraindications and interactions with medication control. For example, patient 506 can enter information related to one or more prescriptions, including the name of the medication and the dosage. The Pill Control Schedule application can check the input information and existing information stored on the IEM data phone 204p (e.g., in the database 504, or elsewhere (e.g., pharmacy 106b)). Pill control schedule The app provides information about contraindications, side effects, and prevention instructions. The Pill Control Schedule application can schedule medication information and generate alerts, such as reminders generated at appropriate times to alert patients to swallow medication. Alerts may be audible, visual, email, text messages, etc., and may be integrated with the alert reminder application or not subject to the alert alert application.

The alert reminds the application to accept or access various information associated with the schedule (including IEM data 200) and generate an alert at the appropriate time. Alerts may be audible, visual, email, text messages, etc., and may be integrated with the alert reminder application or not subject to the alert alert application. The alert application may be user configurable, for example, alert type, alert repeat, repeat interval, alert receiver. Alerts can be associated with various devices such as patients, home care, friends, and the like. In one example, patient 506 can schedule reminders that will be sent to the user's device (eg, IEM data phone 204p, handheld device 402, base station 404, mobile phone 406, etc.).

The alert reminder application can be integrated with other applications/systems. To illustrate the IEM system associated with patient 506, it may, for example, detect a drug ingestion event and communicate IEM data 200 associated with the drug ingestion event to an alert reminder application via IEM data phone 204p. The alert reminder application can interoperate with the pill control scheduling application and perform various checks, such as actually swallowing the drug for the person who swallows the drug; swallowing the swallowed drug at the correct dose; swallowing it at regular intervals Swallowing drugs; and so on.

Predetermined criteria can be used to determine if the alert reminds the application if/when an alert, reminder, etc. is generated. To continue the previous description, the alert reminder system generates an alert to a predetermined destination, for example, an alert in the form of a text message to associate with the home care system 106g when it is determined that the person who swallowed the drug has not swallowed the drug or swallowed the wrong dose. The mobile phone, an alert in the form of an email/text message to the healthcare system 106a and the physician system 106f. If the event is considered critical (eg, swallowing over-the-counter medication, overdose, etc.), the alert reminder application can generate a call from the IEM data phone 204p to the emergency assistance system, for example, call 911. Calls (pre-recorded audio, text messages, etc.) may include information such as the patient's name, the nature of the emergency, the details of the ingestion, the physician's and family care information, and the physical location of the person who swallowed the medication.

The automatic re-preparation application can facilitate reconstitution of the prescription medication via interoperation with, for example, the pharmacy system 106b.

The patient tool application can be located on the IEM data phone 204p or can be accessed from the IEM data phone 204p. For example, software tools for tracking dietary regulations and physical symptoms can facilitate users to enter dietary prescribed intakes and symptoms, collect physiological parameters associated with the device (eg, blood pressure, heart rate, etc.), data correlation/analysis, and based on Relevance/analysis to feedback. The patient tool application can provide data (eg, feedback) for display on the IEM data phone 204p, the IEM data system 204, and/or the business system 106.

Social networking applications promote social networking capabilities. For example, a social networking application can retain connections to various social networks. Various links to the profile, receipt of information related to the selected profile (eg, updating profile, facilitating communication and other communications, updating the user's profile, etc.), with the IEM data system 204, and/or the commercial system 106 (eg, Patient tool/community network 204d communicates with network community 106h).

The incentive tracker app collects, manages, tracks, updates, and more. For example, the incentive tracker application can coordinate the information associated with the IEM data collection system 204l and the wholesaler/retailer system 106j to determine incentive eligibility, such as a patient discount. The incentive tracker application can further bill points, notify patients 506 milestones, goals, incentive rewards, etc., based on various reward systems.

The automated billing application facilitates billing for various transactions. The automated billing application can interoperate with various applications/systems, including the IEM data system 204 and/or the business system 106, such as automatically re-booking via the pharmacy system, and the like.

The subscription application facilitates ordering, signing, management, etc. of various subscriptions, such as news feeds, access to various data collections based on a subscription basis, and the like. The subscription application can interoperate with various applications/systems (including IEM data system 204 and/or business system 106, such as subscription system 204k, IEM data collection system 204l, etc.).

License the application collection and/or analyze various sources of information to enable the notified licensing decisions. The licensed application can be associated with various applications/systems (including IEM data system 204 and/or business system 106, such as automatic re-preparation system 204c, subscription system 204f, financial system 204o, pharmacy system 106b, wholesaler/retailer system 106j) Wait) to operate each other.

The financial application supports and enables financial transactions associated with IEM data 200. The financial application can be associated with various applications/systems (including IEM data system 204 and/or commercial system 106, such as automatic re-preparation system 204c, incentive system 204f, subscription system 204k, licensing system 204m, financial system 204o, pharmacy system 106b) The wholesaler/retailer system 106j) operates with each other.

2.3.17 social network system

A social network consists of the social structure of one or more nodes (eg, elements of a website) accessed by an individual or organization. A social network is usually a combination of one or more specific types of relevance (eg epidemiology, treatment control, health management, etc.) and therefore attracts other unrelated individuals and groups that have a common interest in relevance. interest of. The social network may be built around various communities (eg, family care, patients, medical conditions, etc.).

One example of a social network is the patient information community, which provides information related to specific medical conditions, treatments, medications, controls, and side effects based on both provider and anecdotal information. The availability of the above information can provide a benchmark service, for example, a self-assessment that promotes personal progress and adjusts treatment and behavior by comparing and comparing the progress of the individual with those of others with similar conditions, similar treatments, and the like.

Figure 22 illustrates an exemplary IEM data architecture 102 having a social networking system 204q in accordance with an embodiment. The IEM data architecture 102 further includes an IEM data 200, and a hub, which is shown here as a base station. 404. In various aspects, the social networking system 204q can interoperate with, or otherwise associate with, one or more IEM data systems 204 and/or one or more business systems 106.

In one scenario, patient 506 has a cardiac condition. The patient 506 accesses the social networking system 204q, which may be implemented as a server 500 having a software 502 and a repository 504 having IEM data 200. Patient 506 can access social network system 204q, for example, via base station 404. Patient 506a searches database 504 for patient profiles that also have heart conditions similar to patient 506. The social networking system 204q provides multiple profiles for patients with similar conditions. Profiles include a variety of information about each patient, such as medications, personal behavior history, and more. Patient 506 requests to compare their medications, medication compliance, and behaviors and those listed in the profile. The social networking system 204q provides the requested comparison data in the form of a graphical display. Based on the display, patient 506 is able to determine the profile with the most favorable treatment outcome. Based on the profile described above, patient 506 and/or social networking system 204q analyzes the difference between their medication, medication compliance, behavior, and the like, and the corresponding relevance of the profile with the most favorable treatment outcome. The analysis can contrast the differences found in various aspects, as well as generate prescriptive recommendations, for example, in which aspects patient 506 may want to adjust a particular adjustment based on the analysis. Patient 506 can employ a prescribed recommendation (ie, adjust accordingly) to improve his own personal outcome. In addition, patient 506 may update the social networking system 204q with adjustments that may be used by other individuals in the future to track personal improvement and benchmarking purposes. In various aspects, the social networking system 204q may be communicative with other The online community 106h (eg, youth community, business community, etc.) is associated.

3.0 IEM Data Architecture Method

One aspect includes receiving, for example, a swallowable event data originating from a plurality of ingestion event markers via a hub; and transmitting at least a portion of the ingestible event marker data to the at least one ingestible event marker data system via the hub.

4.0 IEM data structure object

One aspect includes, for example, a storage medium having instructions that, when executed by a computing platform, result in performing a method of tagging data with a swallowable event, comprising: receiving, via a hub, a swallowable event originating from a plurality of swallowing event markers And transmitting, via the hub, at least a portion of the ingestible event marker data to at least one ingestible event marker data system.

5.0 IEM Data Architecture System

An aspect includes, for example, a receiving module for receiving ingestible event data originating from a plurality of ingestion event markers via a hub; and a delivery module for indicating at least a portion of the ingestible event marker data via the hub Passed to at least one ingestible event marker data system.

6.0 IEM data architecture data modeling and regulatory results

In various aspects of the invention, various techniques (e.g., based on state characterization of multivariate data fusion techniques) can be employed to generate various outputs, such as analysis, metrics, prediction information, and the like. For example, an aspect may include data that is captured and processed to establish a metric that describes and/or predicts an upcoming health event, such as a stroke or future behavioral selection indicator, for example, if a prescription is to be made in the future, is the individual Will follow the above medication control.

Referring to Figure 23 for illustration, exemplary software modules 510a-c of exemplary software 502 of exemplary IEM data system 204 are shown. More specifically, and with continued reference to the figures herein, the IEM data 200 may be a predetermined data set. In one example, the IEM data 200 is the material that the patch receiver 400 and the data logger 2302 (optionally) gather. The IEM data is provided to an IEM data system 204, such as prediction system 204n. The IEM data system 204 includes a software module 510 having one or more of an analysis module 510a, a metric module 510b, and a prediction information module 510c.

To continue the description, the sensor and data logger capture longitudinal data. In one example, patch receiver 400 aggregates physiological data (such as location data associated with a user of patch receiver 400) and provides receiver data 200a to analysis module 510a. In one example, the used location X, Y, Z data is retrieved at a predetermined rate or schedule. The data logger 2302 aggregates the data logger data 200b (e.g., sleep quality, etc.) and provides the data logger data 200b to the analysis module 510a. The analysis module 510a analyzes the location data and the data logger data 200b and provides the analytics data to the metrics module 510b for metric generation. In an example, at least by time Normalization and interpolation are used to analyze the acquired location data to produce a fixed time of the day square. This information is provided to the metrics module 510b to produce various metrics such as an average daytime mode, a standard deviation across days, and overall variability. Based on the metric, the prediction information module 510c generates prediction information. For example, metrics can be analyzed to predict that a user is likely to comply with medication control. In addition, for example, medication compliance data can be tracked via IEM event data collected from a swallowable sensor such as an IEM or RFID device, and when analyzed separately or with other data, the predictive information module 510c can generate concurrent medications. Characterization of patient stability in control or other treatment.

Those skilled in the art will recognize that software modules 510a, 510b, and 510c may be collectively associated with a single system component (e.g., IEM data system 204) or may span various system components (e.g., patch receiver 400, hub 202) And/or one or more IEM data systems 204) are distributed and/or associated with various system components (eg, patch receiver 400, hub 202, and/or one or more IEM data systems 204). In the foregoing examples and in various aspects of the invention, calculations and analysis may be implemented via one or more modules, or combinations thereof, and/or by other software.

Additional examples are presented in Table 1, the following titled "Instances."

With continued reference to Table 1 and with reference to Figures 24a and 24b, which illustrate sample IEM data and sample metrics as previously discussed, in Example 1, the analysis module and metrics are used to access the regularity of the day and night (day) mode of the individual. Sex and stability. These metrics are a surrogate for patient stability regularity and can describe and/or predict patient taking pill behavior.

Sensors, data loggers, and/or other IEM sources can be used to retrieve timestamp information about individuals. Data can be related to an individual's physiology (eg, heart rate, activity, sleep, body/skin temperature, etc.), behavior (eg, mobility, social, participation, technical use, etc.), cognitive status (eg, mood, stress, mood) The state, etc., and/or the environment (eg, position, temperature, ambient light, sound, etc.) are related. The sensor may be active in nature (ie, worn and/or carried by a person, etc.), or passive (ie, found in a person's environment).

The analysis module applies an algorithm to one or more sources to visualize and characterize the day and night (daytime) mode. Pre-processing can include time normalization and interpolation of data samples to fixed time of the day to characterize the regularity of the daily pattern. Various filters or transformations can be applied to emphasize time series features prior to metric calculations. The metrics associated with the variability of the daily pattern include the standard deviation of the cross-day calculations, the intrinsic dimensions calculated as the number of significant principal components in the data series, the daily deviations in the average pattern, and/or other time series descriptive statistics.

The example presented in Figure 24b relates to the variability of the circadian rhythm used to comply with medication control. Patient 1 has a regular, stable diurnal pattern and represents a high rate of medication compliance, while patient 2 represents irregular Day and night mode and taking pills.

The heat map represents the daily pattern of the gesture and the behavior of taking the pills after several days of taking. Patient 1 has a regular day and night mode with a lower standard deviation across the 12-day data. Individuals also exhibit high pill taking and timing compliance as reflected by the regularity of the number of medications and timing.

In contrast, Patient 2 has a more irregular pattern with a higher degree of time standard deviation than its average daily mode. Irregularities in the transition from standing to supine position are also evident in the longitudinal pose data. Individuals also showed irregular pill taking, different pill doses per day, and less controlled time in a day.

Additionally, any of the embodiments disclosed herein can be performed in a data processing system. According to an embodiment, for example, the schematic system includes, for example, a processor, a main memory, a static memory, a bus, a video display, an alphanumeric input device, a cursor control device, a driving unit, a signal generating device, and a network interface device. , machine readable media, instructions, and networks.

The illustrative system can represent a personal computer and/or data processing system in which one or more of the operations disclosed herein can be performed. The processor may be a microprocessor, a state machine, a dedicated integrated circuit, a field programmable gate array, and the like. The main memory may be the main memory of the dynamic random access memory and/or computer system. Static memory may be a hard drive, a flash drive, and/or other memory information associated with a data processing system.

The busbars may be interconnects between the various circuits and/or the structure of the data processing system. The video display provides an illustration of the information on the data processing system. The alphanumeric input device may be a keypad, keyboard, and/or Any other input device of text, for example, a special device to assist a disabled person. The cursor control device may be a pointing device such as a mouse. The drive unit may be a hard drive, a storage system, and/or other long term storage subsystem. The signal generating device may be a functional operating system for the basic input and output system and/or data processing system. The network interface device may be a device that performs interface functions such as transcoding, protocol conversion, and/or buffering required to pass to and from the network. A machine-readable medium can provide instructions for performing any of the methods disclosed herein. The instructions may provide source code and/or data code to the processor to initiate one or more of the operations disclosed herein.

While the present invention has been described with respect to the specific embodiments thereof, it is apparent that various modifications and changes can be made to the embodiments without departing from the scope of the invention. For example, any combination of hardware circuitry (eg, CMOS based logic circuitry), firmware, software, and/or hardware, firmware, and/or software (eg, implemented in a machine readable medium) can be used. To activate and operate the various devices, modules, and the like described herein.

For example, various electronic structures and methods can be implemented using transistors, logic gates, and electronic circuits, such as dedicated integrated circuits (ASICs) and/or in digital signal processor (DSP) circuits. For example, one or more of the techniques described herein can be used to activate the receiving module and the delivery module and other modules.

In addition, it will be appreciated that the various operations, procedures, and methods disclosed herein can be implemented in a machine-readable medium and/or machine-accessible medium compatible with a data processing system (eg, a computer system), and What order to proceed. Accordingly, the specification and figures are to be regarded as

For example, any or all of the materials associated with the apparatus and methods described above may be used alone or in combination with other materials to form IEM data (ie, data having an IEM profile).

In some embodiments, the system and/or method steps further comprise/utilize elements for storing data (ie, data storage elements), such elements being present in, for example, bedside monitors, PDAs, smart phones, computers On an external device such as a server. Typically, the data storage component is a computer readable medium. The term "computer-readable medium" as used herein refers to any storage or transmission medium that participates in providing instructions and/or materials to a computer for execution and/or processing. Examples of storage media include floppy disks, magnetic tapes, CD-ROMs, hard drives, ROM or integrated circuits, magneto-optical disks, or computer readable cards such as PCMCIA cards, whether or not such devices are internal or external to the computer. A file containing information can be "stored" on a computer readable medium, where "storing" means recording information so that the data can be accessed and retrieved by computer and/or computer related components. With regard to computer readable media, "permanent memory" refers to permanent memory. Permanent memory is not erased by power to the computer that terminates the processor. Computer hard drive ROM (ie, not as virtual memory), CD-ROM, floppy disk and DVD are all examples of permanent memory. Random access memory (RAM) is an example of non-permanent memory. Files in persistent memory may be editable and rewritable.

Computer-executable instructions (ie, programming) for performing the above methods are also provided, for example, for programming IEMs, receivers, and systems Other components. Computer executable instructions reside on a computer readable medium. Thus, various aspects provide a computer readable medium containing programming for providing ingestible event marker material.

Thus, in some embodiments, the system includes one or more of the following: a data storage component, a data processing component, a data display component, a data transmission component, a notification mechanism, and a user interface. These elements may be present or otherwise associated with at least one of the ingestible event marker data, the hub, and the IEM data system.

One of the above systems is viewed for the receiving module and the transmitting module. However, the aspect is not limited to this. In a broader sense, systems are communicated by one another (eg, using hub functions as reviewed above, for example, using IEM data in communications, for example, using the functionality of an IEM data system) composition.

It will be appreciated that the invention is not limited to the specific embodiments described, and thus may vary. It is also understood that the terminology used herein is for the purpose of describing the particular embodiments, and is not intended to

The range of values is provided here, and each intermediate value is known to one tenth of the unit of the lower limit, unless otherwise specified in the text, the upper and lower limits of the range and any other stated or stated range The intermediate values in the middle are included in the present invention. The upper and lower limits of these smaller ranges may be independently included in the <RTIgt; </ RTI> <RTIgt; </ RTI> <RTIgt; </ RTI> <RTIgt; </ RTI> <RTIgt; The range recited herein includes one or two limitations, excluding either or both of the limitations The scope is also included in the present invention.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning meaning Although any methods and materials similar or equivalent to those described herein can be used in the practice or testing of the present invention, the illustrative methods and materials are now described.

All publications and patents mentioned in this specification are hereby incorporated by reference as if individually and individually individually and individually The disclosure is incorporated herein by reference to disclose and describe the methods and/ or subject matter The disclosure of any publication is for its disclosure prior to the filing date, and should not be construed as an admission that the invention is entitled Moreover, the date of the proposed publication may differ from the actual publication date that may need to be separately confirmed.

It is to be understood that the singular forms "", "," It is further noted that the scope of the patent application may be written to exclude any optional components. Accordingly, this description is intended to serve as a basis for the use of such specific terms such as "only", "only", and the like.

It will be apparent to those skilled in the art that, in this disclosure, each of the individual embodiments described and illustrated herein can be readily adapted to any of the various embodiments without departing from the scope or spirit of the invention. By The features separate or combine separate components and features. Any method of presentation can be performed in the order of the stated events or in any other order that is logically possible.

Although the present invention has been described in considerable detail by way of illustration and example, the embodiments of the invention Make some changes and modifications to it.

Therefore, the foregoing merely illustrates the principles of the invention. It will be apparent to those skilled in the art that <RTIgt; </ RTI> <RTIgt; </ RTI> <RTIgt; </ RTI> <RTIgt; Furthermore, it is intended that the present invention be construed as being limited to the details Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to include structural and functional equivalents. In addition, it is contemplated that such equivalents include both currently known equivalents and equivalents that are developed in the future, that is, any element developed by the same function regardless of the structure. Therefore, the scope of the invention is not intended to be limited to the exemplary embodiments shown and described herein. Instead, the spirit and scope of the present invention is embodied by the scope of the appended claims.

100‧‧‧Communication environment

102‧‧‧IEM data architecture

104‧‧‧IEM data environment

106‧‧‧Commercial system

Claims (16)

A system comprising: a receiver adapted to be associated with a body of a person, the receiver configured to receive IEM data; a hub to receive the IEM data; and at least one IEM data system to receive from the hub Receive this information. The system of claim 1, wherein the receiver is selected from the group consisting essentially of a patch receiver, an implantable receiver, a receiver configured to be worn on the body, and a garment configuration. A receiver, and a group of receivers that are associated with the hub. A system as claimed in claim 2, wherein the receiver adapted for use with the hub comprises a mobile telephone accessory. The system of claim 3, wherein the hub is a mobile phone. The system of claim 1, wherein the at least one IEM data system further comprises software. The system of claim 3, wherein the software further comprises at least one of an analysis module, a measurement module, and a prediction information module. The system of claim 6, wherein the analysis module analyzes the IEM data. The system of claim 6, wherein the metric module generates a metric based on the IEM data. The system of claim 6, wherein the prediction information module generates prediction information based on the IEM data. The system of claim 6, wherein the IEM data further comprises physiological data, the analysis module analyzes the physiological data and generates a metric based on the physiological data, and the prediction module generates the prediction information based on the physiological data. . The system of claim 10, wherein the predictive information is based on a metric and is related to a prediction of a state of a user. The system of claim 2, wherein the at least one IEM data system comprises at least one of a feedback loop system and a decision support system. A system comprising: at least one IEM data system for receiving data, the at least one IEM data system comprising at least one software module, having at least one of an analysis module, a measurement module, and a prediction information module The at least one software module analyzes the data to generate prediction information. The system of claim 13, wherein the predictive information is associated with a likelihood of compliance with a medication control. The system of claim 13, wherein the predictive information is associated with a prediction of occurrence of a future health event. The system of claim 13, wherein the predictive information is associated with at least one of a patient state characterization, patient stability characterization, and treatment class selection information.