The present invention relates to medical safety monitoring of adverse events related to medical devices, drugs, medical procedures, etc.
In general, medical devices, drugs and/or medical practices and procedures (hereinafter medical entities) are regulated by the Food and Drug Administration (FDA). New medical entities typically must be approved by the FDA before entering the market for public use. The FDA performs various tests and studies on medical entities in an effort to ascertain whether the medical entity is safe for use. For example, the FDA may perform various tests on a new medical device (e.g., drug eluding stents, cardio-defibrillators, vascular closure devices, etc.) to demonstrate the medical device efficacy prior to approving the device for marketing. Similarly, a new drug typically must pass a battery of tests before it is approved to be marketed to the general public.
While pre-approval randomized clinical trials required for demonstrating medical device efficacy have important safety endpoints, it is generally observed that such trials may be inadequate to comprehensively assess the safety of new medical devices. The inability of randomized trials to ensure safety for the population at large are due in part to the preferential inclusion of highly selected patient populations (as opposed to the application of devices to populations outside of those studied in the trials, which commonly occurs after a device is approved and in the marketplace), the very low frequency of adverse events, and the rapid dissemination of the new technology to practitioners who may not be as expert in the device use or in patient selection as those involved in the trials.
The FDA currently relies on a collection of passive reporting systems for collecting information regarding medical device failures following approval for use. These systems, such as the medical device reporting (MDR) system, the MedSun system, MedWatch and the “Adverse Event Reporting System” rely on user initiated submission of adverse events to vendors, and mandatory submission of this information to the FDA. These reporting systems are plagued by their inability to assess accurate event rates due to under-reporting and an absence of mechanisms to collect accurate overall usage statistics. The U.S. General Accounting Office has estimated that less than one percent of adverse events involving medical devices are reported to the FDA. In addition, the FDA has limited access to the number of patients exposed to new devices, and often can make no accurate inferences regarding the true rates of adverse events.
Recent examples of problems associated with assessing post-market medical device safety have involved two FDA approved drug eluting coronary stent systems: Cypher™ (Cordis Corp., NJ) and Taxus™ (Boston Scientific Corp., Natick, Mass.). Cypher was approved for market release in April 2003. By December 2003, the FDA had received reports of over 300 cases of subacute stent thrombosis (SAT), a dangerous complication of stent implantation that typically leads to heart attack or, in some instances, death. These reports raised serious concerns regarding the safety of the device. Compounding this problem was the exponential growth in the use of the device in the U.S., with over 200,000 devices implanted per quarter by the beginning of 2004. Unfortunately, given the tools available for safety surveillance, the FDA lacked detailed clinical data on the types of patients who were receiving the devices as well as accurate information regarding the overall number of devices implanted.
In October 2003, the FDA issued a public health notification about the Cypher stent to remind clinicians to follow the labeled instructions for use for the device. After further review of post-market surveillance registries as well as the release of further randomized trial data, the FDA concluded that there was no increase in the risk of SAT over bare metal stents. Therefore, the FDA made a second notification to all U.S. cardiologists concluding that the Cypher Stent was safe.
In addition to the Cypher drug eluting stent SAT concern, the second drug eluting coronary stent approved for use in the U.S., the Taxus stent, was subject to three separate manufacturer recalls within 6 months of release for failures of balloon deflation, which were identified in 40 patients and associated with 18 serious injuries, including one death. Additionally, the very large and costly recalls of implantable cardio-defibrillators in 2005 have highlighted the deficiency in conventional safety surveillance programs.
As discussed above, pre-approval testing of medical entities (e.g., medical devices, drugs, medical procedures, etc.) may fail to prevent marketing of unacceptably unsafe and/or potentially dangerous medical entities. Post-market safety monitoring, therefore, may be an important feature of ensuring that such medical entities are generally safe (e.g., involve acceptable risks) and/or are not defective. However, there is no current methodology for implementing such a monitoring system. Moreover, there are relatively significant challenges involved in developing a system for effective post-market monitoring.
Rapid dissemination of new medical technology, lack of standards in data collection, and lack of information integration, at least in part, have frustrated development of anything beyond relatively crude and passive safety monitoring tools. For example, conventional post-market safety monitoring, if performed at all, has been achieved by analyzing historic data that has been compiled over a number of years to determine, for example, if an unsatisfactory rate of adverse events have occurred. That is, conventional monitoring, when performed at all, has been done retrospectively. Moreover, the only available historic data available even for retrospective analysis is often a local compilation of information, for example, obtained within a given hospital, and therefore may not be representative of events on a larger scale. Accordingly, it may be difficult to accurately identify the source of a problem or to correctly identify a problem at all. For example, it may be difficult to assess whether an identified problem resulted from improper use of a device, a defect in the device itself, an unknown side effect of device implementation, or some combination thereof.
In addition, conventional solutions are insufficient, in part, because even if a problem is identified, by the time a conventional retrospective analysis is performed on data obtained over a period of time, significant injury may have already resulted, including perhaps numerous serious injuries and/or deaths. For example, an analysis performed on post-market information collected over several years that identifies a defective device, or high rate of complications resulting from the use of the device may have already resulted in a significant number of injuries and/or deaths by the time the analysis is performed and one or more adverse events identified. Applicant has appreciated that by continuously analyzing post-market data, problems associated with various medical entities may be identified earlier and as they arise, rather than retrospectively after significant harm may have already occurred. One embodiment according to the present invention includes a medical safety monitoring system that performs substantially continuous analysis of safety information and generates generally real-time alerts of adverse events associated with one or more monitored medical entities.
The term “continuous” as it relates to analysis and/or monitoring refers herein to performing the associated acts generally contemporaneously with the time data or information becomes available. This is in contrast to conventional systems that perform retrospective analysis on historical data that has been compiled for some discrete amount of time. For example, a continuous monitoring system may perform one or more statistical analyses each time safety information is added to a database included as part of a monitoring system. The update of one or more databases, for example, may trigger the monitoring system to re-analyze the data in view of the new information to report on adverse events and/or determine whether one or more alerts should be generated.
Some embodiments according to the present invention include a medical surveillance system for monitoring the safety of at least one medical entity, the medical surveillance system comprising at least one database to store information related to the at least one medical entity, the at least one database being periodically updated with current information about the at least one medical entity, and at least one controller coupled to the database, the at least one controller configured to perform at least one statistical operation on at least a portion of the information stored in the at least one database, the at least one statistical operation being performed at least each time the at least one database is updated with the current information so as to generate at least one continuous outcome, the controller configured to trigger an alert when the at least one continuous outcome indicates the occurrence of at least one adverse event associated with the at least one medical entity.
Some embodiments according to the present invention include a method of monitoring the safety of at least one medical entity, the method comprising acts of obtaining periodically updated information relating to the safety of the at least one medical entity, performing, each time updated information is obtained, at least one statistical operation on at least a portion of the information to generate at least one continuous outcome, and generating an alert when the at least one continuous outcome indicates the occurrence of at least one adverse event associated with the at least one medical entity.
Some embodiments according to the present invention include a computer readable medium encoded with a program for execution on at least one processor, the program, when executed on the at least one processor, performing a method of monitoring the safety of at least one medical entity, the method comprising acts of obtaining periodically updated information relating to the safety of the at least one medical entity, performing, each time updated information is obtained, at least one statistical operation on at least a portion of the information to generate at least one continuous outcome, and generating an alert when the at least one continuous outcome indicates the occurrence of at least one adverse event associated with the at least one medical entity.
One impediment to the development of a medical safety monitoring system is the lack of available information. While safety information may be routinely collected, the information is often derived from different sources, and may only be reflective of a particular locality such a single hospital or relatively local region. To compound the problem, data collection is not integrated and there generally are no standards for format, the type of information collected and/or consistency in data collection. As discussed above, when information is available at all, it is typically compiled locally, for example, within a particular hospital and therefore is only indicative of activity that occurred within the hospital, thus resulting in data that is relatively sparse. Moreover, once this information is analyzed, the results may be published, but the data is typically not available outside of the hospital or organization responsible for collecting the data. Accordingly, the lack of available and/or satisfactory data sources has contributed to the failure of the concept of a continuous and automatic medical safety monitoring system from being envisioned and/or developed.
In recent years, new possible sources of safety information have arisen due, in part, to expanded use of voluntary post-market safety reporting, and due, in part, to recent government mandated post-market reporting. For example, some states have enacted regulations that require institutions to report information related to the use of various medical entities, such as medical devices, drugs, etc. In some instances, as a condition of using a particular medical entity, the FDA may require an institution to implement certain reporting mechanisms to carry out what is referred to as a post-approval surveillance study (PAS). Applicant has appreciated that newly available information sources may be used to facilitate a post-market medical safety monitoring system.
Regional voluntary database 120 refers generally to collaborations between a plurality of medical centers, typically in a particular geographic area, and/or industry coordinated clinical registries for a particular region or area of medicine. One example of a regional voluntary database is the NNE Cooperative. The regional voluntary information may be more reflective of actual safety, but is generally more expensive to collect, coordinate and evaluate. National voluntary database 130 may include voluntary registries such as the American College of Cardiology—National Cardiovascular Data Repository (ACC-NCDR), national prospective registries such as the National Heart, Lung & Blood Institute (NHLBI) Dynamic Registry, etc. As should be appreciated, national voluntary databases are more reflective of information on a wider scale, but may still suffer from reliability issues due, in part, to the voluntary nature of the data collection.
For example, in the Cypher™ stent case, Cypher™ was approved for market release in April 2003. As discussed above, by December 2003, the FDA had received reports of over 300 cases of SAT. As a result, in October 2003, the FDA issued a public health notification about the Cypher™ stent. After further review of detailed post-market surveillance registries as well as the release of further randomized trial data, the FDA concluded that there was no increase in the risk of SAT over bare metal stents. Therefore, the FDA made a second notification to all U.S. cardiologists concluding that the Cypher™ Stent was safe.
The notoriety of the events, coupled with the explosive growth in the use of drug-eluting stents in the U.S., led to a dramatic increase in the number of adverse events reported regarding Cypher™ stents after the first FDA notification. Upon review of the publicly available adverse event reports for the Cypher™ stents, a comparison was made of the number of device-associated events with the number of units sold during each quarter. The results showed that there was a dramatic increase in the number of reports per unit sold in each quarter following the initial FDA notification until the FDA's second, more reassuring notification, after which the adverse event rates dropped precipitously. This bias toward “stimulated reporting” highlights the difficulties in interpreting the frequency of events reported through voluntary registries.
Regional mandatory database 140 may include registries compiled as a result of, for example, state regulations mandating the reporting of medical entity information. At least New York, Pennsylvania, New Jersey and Massachusetts have passed regulations mandating medical entity reporting. Other regional mandatory databases include the Centers for Medicare and Medicaid Services (CMS) mandated registry, for example, that mandates reporting of carotid stents, ICDs, etc. In general, mandated registries yield higher reliability data due, in part, to the fact that all users of a medical entity must produce reports, rather than a selection of those that choose to voluntary provide the reporting information, thus avoiding the associated bias. No current national mandatory registries are in place, but federal regulation may change this in the future.
PAS repositories 160 are also a possible source of medical information. As discussed above, the FDA often requires a user (e.g., a hospital, clinic, medical center, etc.) of a particular medical entity to provide detailed reporting on the medical entity as a condition of using the device. PAS reporting provides the FDA with post-market data and may allow a medical entity to be marketed sooner, thus effectively balancing the public health and safety risks with the benefit of access to new medical entities. It should be appreciated that the above databases are merely examples of data sources that may be utilized to obtain information that can used by a medical safety monitoring system. However, any source of medical information may be used, as the aspects of the invention are not limited in this respect.
In one embodiment according to the present invention, a medical safety monitoring system is adapted to communicate with one or more databases to provide generally real-time assessment of the safety of monitored medical entities. The medical safety monitoring system may then exploit the data obtained from a variety of sources and perform one or more continuous statistical analyses on the data, as described in further detail below.
Following below are more detailed descriptions of various concepts related to, and embodiments of, methods and apparatus according to the present invention. It should be appreciated that various aspects of the invention described herein may be implemented in any of numerous ways. Examples of specific implementations are provided herein for illustrative purposes only. In addition, the various aspects of the invention described in the embodiments below may be used alone or in any combination, and are not limited to the combinations explicitly described herein.
Monitoring system 200 may also include a data warehouse 220. The data warehouse may be coupled to each of the plurality of data sources to provide a centralized repository of reporting information. The data warehouse may facilitate the collection of reporting information from a variety of different sources, formats and reporting mechanisms and convert them into a desired format to be analyzed (e.g., a flat file format). Accordingly, data warehouse 220 provides an abstraction layer between the data source and monitoring module 250. Data warehouse 220, for example, may include an on-line analytical processing (OLAP) design to facilitate relatively quick answers to analytical queries that are, for example, dimensional in nature. However, data warehouse 220 may be of any design, for example, on-line transaction processing (OLTP), or any multi-dimensional, navigational, hierarchical and/or relational database, etc., as the aspects of the invention are not limited in this respect.
Data warehouse 220 permits new data sources of any type to be added to the system without having to reconfigure and reprogram the monitoring module to interface with the data source. That is, the number, type and nature of the data sources may be invisible to monitoring module 250. It should be appreciated that data warehouse 220 is not required and may be eliminated according to some embodiments. For example, monitoring module 250 may be directly coupled to one or more data sources and configured to receive reporting data directly from the data source(s).
Monitoring module 250 includes one or more programs adapted to continuously monitor the data collected from data sources 110. In particular, when new data is entered into any of the data sources, monitoring module 250 may perform an analysis on the new data independently or in connection with previously entered data. For example, monitoring module 250 may be adapted to perform any number and type of programmed analytical queries to data warehouse 220 to accomplish a desired set of one or more monitoring or surveillance tasks, as described in further detail below.
Monitoring module 250 may be configured to generate an alert when the analysis suggests that an adverse event has occurred. The term “adverse event” refers herein to any numerical or statistical result that falls outside of a set threshold value, interval, level or expectation, etc. For example, an adverse event may be a reported number of deaths or complications that exceeds a predetermined expectation for the rate of such an event. An adverse event may be a trend (e.g., a velocity) in the rate of a particular occurrence that increases more rapidly than expected. An adverse event may be any occurrence or circumstance for which monitoring is desired.
In addition, the result of a particular analysis may be output as one or more reports 357. For example, results of an analysis may be graphed as a function of time, so that a user can view trends or otherwise visualize the results of the analysis. For example, an operator may examine the data in a report to determine whether additional action is necessary. Reports 357 may be of any form and contain any information, as the aspects of the invention are not limited in this respect. Some exemplary reports are discussed in further detail below.
In order for monitoring system 350 to generate reports and/or alerts, the monitoring system may be programmed to perform one or more analyses of the data (e.g., perform one or more analytical queries or series of queries to data warehouse 320). In addition, to generate an alert, monitoring system 350 may need to be instructed as to what amounts to an adverse event and what amounts to a so-called expected event. That is, monitoring system 350 may need to be programmed to understand what results or set of results justify an alert. For example, one statistic that may be important to safety monitoring is the ratio of the number of identified events to the number of patients using the medical entity. For example, in the context of drug eluding stents (DES), the number of patients who developed SAT complications to the number of patients with implanted stents may be a valuable measure in assessing the safety of the drug eluding stent. If the ratio should exceed some expected value, an alert may be raised to indicate the occurrence of an adverse event.
However, it is not always straight forward to determine what expectations should be. Some devices and/or procedures are inherently riskier than others. Similarly, complications, side-effects, effects of device failure, etc. may involve widely varying levels of seriousness; from relatively mild complications to serious injury or death. Accordingly, it may be difficult to properly assess what level of event rates should be tolerated, and which exceed the expectations for a particular device, drug, procedure, etc.
Moreover, there are many variables that can result in failure of the medical entity. For example, for a medical device, the event (e.g., complication, injury, death, etc.) may have resulted from one or any combination of device failure, improper use (user defect), improper implantation or installment (physician or operator defect), use outside or beyond the indicated use, etc. To further complicate matters, acceptable rates of events may change over time. For example, event rates may be expected to be higher at times nearer to the medical entity's appearance on the market. Improvements in technique and familiarity with a device, for example, may reduce the rate of events. In addition, improvements in the device may also tend to reduce the rate of events. Such factors are relatively difficult to account for.
The second column illustrates the respective methods using risk stratification. Risk stratification is a process by which a given sample is subdivided into discrete groups based on predefined criteria, creating separation in the data to allow concurrent and potentially different analyses to be performed on each subset. As discussed in further detail below, risk stratification may facilitate the discovery of patterns or unacceptable event rates for particular classes or strata, rather than the entire population. Risk stratification may facilitate generating alerts for a particular strata before corresponding alerts would have been generated if the data were considered as a whole, that is, considered uniformly as shown in the first column.
The third column illustrates the respective methods using risk adjustment. Risk adjustment performs analysis with expectations that change over time. That is, levels of event rates that are considered expected and levels that are considered adverse may change over time, for example, as function of the received data. In particular, threshold values, expectation intervals, etc., may be automatically adjusted based on the data accumulated at a given point in time. In this way, measures that trigger alerts may be adjusted to more adequately reflect true adverse events by considering the data upon which those alerts operate.
The various analysis methods may be used alone, or in any combination to implement a medical safety monitoring system. Uniform, risk stratified and risk adjusted methods are described below in connection with various statistical operations including Bayesian analysis, statistical process control (SPC), and logistic regression. However, it should be appreciated that other statistical processes and/or analysis may be used to facilitate generally continuous analysis of a medical entity, as the aspects of the invention are not limited in this respect.
In method 11 (i.e., row 1, column 1), an exemplary uniform expectation statistical method may be used. In particular, statistical process control (SPC), often used to identify product defect rates in manufacturing processes may be used to generate alerts and/or reports concerning the safety of one or more medical entities. SPC may be used to compare observed adverse event rates to alerting boundaries set according to expectations. For example, there may be an expectation of a certain number of adverse events in patients getting a certain medication, or the number of failures of a certain procedure and/or complications arising from use of a particular medical device.
Safety expectations may be derived from previously published trial data, data on similar devices/drugs/procedures, clinical trial data from pre-market testing or other observed empirical data, and/or via solicitation from one or more experts. The various expectation values obtained may be weighted in different ways, or used independently to run separate expectation analyses. Once one or more expectations are set, corresponding SPC analysis may be performed on the data. When event rates exceed the one more expectations, an alert may be generated to indicate the occurrence of an adverse event. Analysis may be performed on the data viewed over a particular time interval (i.e., periodically), or viewed over the entire span of the data, (i.e., cumulatively) as discussed in further detail below.
The SPC analysis, the results of which are illustrated in
The SPC analysis illustrated in
It is interesting to note that the cumulative report shows high percentage rates at the beginning of the interval and a steady decrease after May. The cumulative report highlights trending data that may not be immediately obvious when observing a periodic report, or may not be entirely clear from periodic alerts. For example, the trend in the results shown in
Accordingly, periodic and cumulative analyses may be used together to, amongst other things, identify both recent trends and overall trends in event rates. Evaluation of recent trends may have reduced power to detect significant shifts in event rates, due to the reduced sample size. However, periodic monitoring may serve as a very useful early warning indicator when, for example, cumulative event rates have yet to cross the alert threshold. Early warnings may be beneficial to encourage increased monitoring of the medical entity and to heighten awareness as to a potential problem.
Referring again to
In one embodiment, the information may be used to formulate a plurality of risk strata. For example, the patients may be categorized as low, medium or high risk. A set of rules may then be defined that determines which risk category or strata a patient belongs to. For example, age may be a indicator of risk. Accordingly, the risk strata may be defined purely on age. For instance, rules such as, if the age is less than 60, the patient may be categorized as low risk. If the age is greater than or equal to 60 and less than 80, the patient may be categorized as medium risk, and if the age is greater than or equal to 80, the patient may be categorized as high risk. Other information may be used to establish rules of any complexity. For example, whether a patient has diabetes may effect the risk level of the medical entity and may be incorporated into the rules. An exemplary rule may be that if the patient's age is less than 50, but has diabetes, the patient may be categorized as medium risk, instead of low risk as in the example above. Any number of factors may be used to establish rules to categorize patients into any number of strata, as the aspects of the invention are not limited in this respect.
It should be appreciated that the rules and the type of information used to define the risk strata may depend on the type of medical entity, and on what factors may be valuable in determining risk strata and in defining useful categories for the analysis. In addition, it should be appreciated that the strata need not be defined to categorize risk. For example, a practitioner may be interested in determining the effects of a particular medical entity based on gender, ethnicity, etc., independent of the associated risk. This information may assist in identifying a problem that pure risk stratification may miss, or not so clearly indicate. Accordingly, the data may be separated or categorized in any manner to achieve stratification, as the aspects of the invention are not limited in this respect.
SPC expectation analysis may then be performed on the data, in view of the risk strata, either periodically or cumulatively by any of the methods described above. In particular, different expectations may be set with respect to each strata. Moreover, different confidence intervals may be assigned to the expectations of the respective strata. For example, the low risk strata may be assigned a lower expectation of event rates (e.g., death) than the medium and high risk categories. However, empirical evidence may suggest that the variability of the low risk category is also less, such that a narrower confidence interval (e.g., 97%) may be tolerated for the low risk category. The expectation and thresholds may be set in any manner for the various defined strata, as the aspects of the invention are not limited in this respect.
Referring back to
Logistic regression typically applies maximum likelihood estimation, which estimates the probability of a certain event occurring. Accordingly, the probability of an event occurring can be used as an expectation of the rate of event occurrence. Similarly, the variance may be used to establish a confidence interval. LR analysis is based on a predictive model taking into consideration the significance of one or more covariate factors. The form of the logistic model can be expressed as:
Where B0 is a constant (i.e., the intercept) and Bi are coefficients of the predictor or covariate variables Xi (i.e., the factor). The computed value, P, is a probability in the range from 0 to 1. Accordingly, the probability is a function of the contribution of weighted factors forming a predictive model. The weighting (i.e., the values of the Beta coefficients) may be derived from any available information such as empirical data, published test results, expert opinion, etc. It should be appreciated that a single or multiple Beta values may be used to form the predictive model, and the number used may depend on the type of analysis being performed. Other predictive model formulations may be used as well, as the aspects of the invention are not limited in this respect.
It should be appreciated that different analyses corresponding to different medical entities will have a wide range of factors that may be important. The list of factors and the selected beta factors illustrated in
It should be appreciated that since the probability of an event occurring is computed as new data is received, the corresponding expectation is adjusted according to the new data. Accordingly, risk adjustment occurs implicitly using LR analysis. Similarly, since the amount of data used in LR computations increases as new data is received, the variance in the data is also subject to change. For example, the LR results illustrated in
Referring back to
In a second method, alerts are based on the evolution of updated risk estimates represented as probability density functions (PDF). In each period or epoch, a new PDF is generated based on the cumulative study event rate and baseline event rate. Alerting thresholds are generated by specifying minimum overlap of the distributions (e.g., by comparison of central posterior intervals). The first comparison PDF is the initial prior PDF, and the second PDF is the previous period's or epoch's PDF.
Priors for purposes of the Bayesian analysis may be obtained from any available empirical data, SPC results, previous publications and/or test results, etc.
BUS methods may be particularly useful in reducing the impact of early outliers in data, and may facilitate more accurate alerting when a limited amount of data exists (e.g., during intervals near the time the medical entity is released to the public.) BUS methods may provide a useful complement to other statistical methods as described in further detail below. In particular, alert algorithms based on BUS methods may be combined with one or more other alert methods (e.g., SPC and/or LR methods) to take advantage of the strengths and weaknesses of the each method.
The various alerting methods may have particular strengths and may also be vulnerable in some instances. Applicant has appreciated that by combining the various alerts, a meta-alert may be developed that provides a more accurate indication of when a true adverse event has occurred. Two characteristics of an alert that may be important include high sensitivity and high specificity. High sensitivity may be important for high risk events such as mortality, catastrophic device failure, etc. In particular, for high risk events, false positives may be tolerated to avoid missing a true adverse event. High specificity may be important for lower risk, low morbidity events such inflammatory or allergic reaction, non-fatal side-effects, etc. In these instances, it may be more important to only raise an alert when a true adverse event transpires. Other characteristics of alerts may be valuable and may be exploited by combining alerts generated by multiple analysis strategies.
In some embodiments according to the present invention, a combination of Bayesian Updating and SPC alerts are combined to optimize sensitivity and specificity for general safety surveillance. One exemplary meta-alert includes an alert rule that instructs the meta-alert to be generated if a Bayesian alert fires in one or more periods in an observation interval and an SPC alert fires in more than one third of the periods in the observation interval. It should be appreciated that any one or combination of Bayesian, SPC and LR alerts may used to define a meta-alert. The monitoring module may expose one or more interfaces that allow a user or operator to customize a meta-alert for a particular analysis using one or any combination of available alerts from available statistical processes. That is, an operator may be enabled to combine, weight and/or set up a series of rule alerts that define a meta-alert that may facilitate accurate detection of adverse events. The concept of combining, weighting or otherwise customizing alerts based on a set of rules may be applied to any type of alert or in any combination, as the aspects of the invention are not limited in this respect.
Various aspects of the invention derive from applicants appreciation that important information may be gleaned by analyzing safety data from a variety of sources. Obtaining information from the various data sources, in combination with a centralized data warehouse (e.g., the data warehouse described in connection with
To facilitate the distributive safety monitoring system, the safety monitoring module may be a network application. The front-end of the safety monitoring module may be a web-based application using an interface such as a browser. Accordingly, operators could access the database information, construct analyses, customize tests, view results, receive alerts, etc. through the browser installed on the operator's computer, while most of the distributive application resides elsewhere.
The root folder includes all the available information available through the DELTA system. If the hierarchy is expanded, folders representing the available data sources are listed as the next level. For example, the folder labeled “All Studies” may include all the safety information available to the system. Underneath, each folder in the hierarchy may represent a data source, or all of the information on a particular medical entity from a variety of data sources. Under each study (e.g., data available on a particular medical entity), the folders at the next level correspond to individual analyses that are being performed on the associated data. Accordingly, the DELTA system supports performing multiple analyses on multiple medical entities simultaneously.
Along the top of the screen shot in
Various other features of the DELTA system will be described below in connection with analyses of the risk of retroperitoneal hemorrhage with the use of a vascular closure device. In particular, reporting information for a particular vascular closure device may be collected at one or more data sources (e.g., one or more data sources 310 illustrated in
It should be appreciated that the operator can select when and under what circumstances the analysis is performed. For example, the operator may choose various analyses to be performed upon any change in the information in any of the corresponding data sources. Alternatively, the operator can choose to have the analyses performed on a periodic schedule, such as a daily, weekly, monthly analyses, etc. Accordingly, continuous (as opposed to retrospective) analyses may be performed on the reporting information available on one or more medical entities.
In the right hand column, a list of current reports are shown, which are provided as live links for viewing the reports. For example,
As illustrated above, numerous analyses using various statistical methods and alert structures were used on the same information. In some embodiments according to the present invention, the safety monitoring module is adapted to track an arbitrary number of analysis and prompt alerts to an arbitrary number of potential adverse events. It should be appreciated that any source of data relating to any medical entity may be used, and any type of statistical analysis may be performed to continuously analyze the information, as the aspects of the invention are not limited in this respect.
As should be appreciated from the foregoing, there are numerous aspects of the present invention described herein that can be used independently of one another or in any combination. In particular, any statistical method may be employed in any of numerous combinations and procedures. Moreover, any type of alert structure or formulation of one or more meta-alerts may be used with any type of analysis. It should also be appreciated that in some embodiments, all of the above-described operations can be used together in any sequence, or any combination or subset of the operations described above can be employed together in a particular implementation, as the aspects of the present invention are not limited in this respect. In addition, the various operations may be performed on any type of device or apparatus, and are not limited to any particular implementation.
The above-described embodiments of the present invention can be implemented in any of numerous ways. For example, the embodiments may be implemented using hardware, software or a combination thereof. When implemented in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers. It should be appreciated that any component or collection of components that perform the functions described above can be generically considered as one or more controllers that control the above-discussed functions. The one or more controllers can be implemented in numerous ways, such as with dedicated hardware, or with general purpose hardware (e.g., one or more processors) that is programmed using microcode or software to perform the functions recited above.
It should be appreciated that the various methods outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and/or conventional programming or scripting tools, and also may be compiled as executable machine language code. In this respect, it should be appreciated that one embodiment of the invention is directed to a computer-readable medium or multiple computer-readable media (e.g., a computer memory, one or more floppy disks, compact disks, optical disks, magnetic tapes, etc.) encoded with one or more programs that, when executed, on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above. The computer-readable medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above.
It should be understood that the term “program” is used herein in a generic sense to refer to any type of computer code or set of instructions that can be employed to program a computer or other processor to implement various aspects of the present invention as discussed above. Additionally, it should be appreciated that according to one aspect of this embodiment, one or more computer programs that, when executed, perform methods of the present invention need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present invention.
Various aspects of the present invention may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing, and the aspects of the present invention described herein are not limited in their application to the details and arrangements of components set forth in the foregoing description or illustrated in the drawings. The aspects of the invention are capable of other embodiments and of being practiced or of being carried out in various ways. Various aspects of the present invention may be implemented on any type of computer, computer system, or any type of network connecting one or more computers. Accordingly, the foregoing description and drawings are by way of example only.
Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.
Use of ordinal terms such as “first”, “second”, “third”, etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.
Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having,” “containing”, “involving”, and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.
This application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Application Ser. No. 60/780,437, entitled “AUTOMATED MEDICAL SAFETY MONITORING SYSTEMS AND METHODS,” filed on Mar. 8, 2006, which is herein incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
60780437 | Mar 2006 | US |