Showing papers in "Pharmaceutical Programming in 2008"
TL;DR: This paper briefly explains the definitions of compliance and persistence based on the guidance from the Medication Compliance and Persistence Special Interest Group of ISPOR, the International Society for Pharmacoeconomics and Outcomes Research, and provides analytic methods that are congruent with the preferred terminology.
Abstract: Compliance, adherence, and persistence are outcomes easily measured in pharmacy claims databases. However, these measures are used with differing taxonomies and the calculations are heterogeneous. The results can then lead to spurious interpretations. Therefore, the research community would benefit from a common set of definitions and methods to calculate compliance and persistence. This paper briefly explains the definitions of compliance and persistence based on the guidance from the Medication Compliance and Persistence Special Interest Group of ISPOR, the International Society for Pharmacoeconomics and Outcomes Research, and provides analytic methods that are congruent with the preferred terminology.
94 citations
TL;DR: An overview of evolution and status of the SDTM and the associated Implementation Guides, commonly referred to as the Study Data Tabulation Model Implementation Guide for Human Clinical Trials (SDTMIG) and the Standard for Exchange of Nonclinical Data (SEND).
Abstract: The Clinical Data Interchange Standards Consortium (CDISC) Study Data Tabulation Model (SDTM) is a standard for submitting data tabulations to the FDA in support of marketing applications. In July 2004, this standard became part of the FDA Study Data Specification referenced in the electronic Common Technical Document (eCTD) Guidance. This article will provide an overview of evolution and status of the SDTM and the associated Implementation Guides, commonly referred to as the Study Data Tabulation Model Implementation Guide for Human Clinical Trials (SDTMIG) and the Standard for Exchange of Nonclinical Data (SEND).
20 citations
TL;DR: The sub-team has come up with a model to fill-in the gaps in SDTM for medical device and diagnostic companies that is based on a custom Finding Observation Class domain that is simple and extensible.
Abstract: In May 2006, a CDISC SDTM Device sub-team was formed. This sub-team is made of industry experts, CDISC representatives and FDA representatives. This sub-team has been working on a model to fill-in the gaps in SDTM for medical device and diagnostic companies. The initial focus has been on developing a domain that would contain information (metadata) about devices and not on results from devices. The sub-team has come up with a model that is currently being reviewed by industry experts. The proposed model is based on a custom Finding Observation Class domain. The advantage of this proposed model is that it is simple and extensible.
6 citations
TL;DR: So far PhUSE has been an exciting initiative, with more than 273 papers presented in the following areas: 51 posters 36 application and development 31 technical solutions 22 coder corners 18 coding solutions (2006 and 2007 stream) 17 Statistics & Pharmacokinetics 17 Tutorials
Abstract: So far PhUSE has been an exciting initiative. European Pharmaceutical Software Users now have a place where they can present and share their experience. In the first two PhUSE conferences (2005 and 2006) and in the current one (2007), 273 papers were presented (89 in the 2005, 85 in the 2006 and 99 in 2007) in the following areas: 51 posters 36 application and development 31 technical solutions 22 coder corners 18 coding solutions (2006 and 2007 stream) 17 Statistics & Pharmacokinetics 17 Tutorials
2 citations
TL;DR: A collection of SAS® features and techniques that are not well known, somewhat counterintuitive or undocumented, but all are surprisingly useful once learned and mastered are demonstrated.
Abstract: Sometimes the simplest SAS® task can become unnecessarily complex. Often the complexity of SAS®, itself, is the cause. Crucial details are easily hidden among the thousands of pages of SAS® documentation, technical notes, release updates, etc. The authors demonstrate a collection of SAS® features and techniques that are not well known, somewhat counterintuitive or undocumented, but all are surprisingly useful once learned and mastered. Mysterious SAS® behavior that might have inspired ‘work-arounds’ should now become transparent. Topics include environment settings; system options; and operators, functions and statements from SAS Language®, Macro Language®, SCL® and SAS/Graph®. The authors intend, through this selective review of uncommon techniques, to inspire a general interest in leveraging the power and maximizing the efficiency of programming tools.
2 citations
TL;DR: This paper discusses various factors to be considered when making decisions regarding the properties of stored data, which extend beyond properties of the data files to include the context within which the data are used.
Abstract: This paper discusses various factors to be considered when making decisions regarding the properties of stored data. These factors extend beyond properties of the data files to include the context within which the data are used. Decisions about the stored length of numeric variables in SAS® data sets are used as an example of the decision-making process. Although the LENGTH statement in SAS is simple to use, what's going on behind the scenes is more complex, especially with respect to numeric variables. Understanding what happens when you specify the length of a numeric variable is essential for making informed decisions. SAS stores the value of all numeric variables in floating-point representation. This paper begins with a brief, practical, overview of floating-point representation and how it relates to programming questions regarding length, precision, and efficient use of disk space. We will discuss situations where numeric length should not be reduced, even if the range of integer values on ...
1 citations
TL;DR: There is a regulatory responsibility, 21 CFR Part 11, to analyze only the clinical data that have passed data acceptance testing or is considered 'clean data' after a database lock.
Abstract: With the recent news from FDA to push tighter safety reviews due to increased patient deaths caused by Viox, pharmaceutical companies need to develop systems for early detection of safety and clinical data issues. In the pharmaceutical industry, there is a regulatory responsibility, 21 CFR Part 11, to analyze only the clinical data that have passed data acceptance testing or is considered 'clean data' after a database lock. Clinical data acceptance testing procedure involves confirming the validity of critical data variables as well as early identification of health risk issues. These critical data variables might need to be non-missing, consist only of valid values, be within a range, or be consistent with other variables. If incorrect clinical data are analyzed, then invalid study conclusions can be drawn about the drug's safety and efficacy.
1 citations
TL;DR: This work utilizes a metadata database and XML tagsets to create an XML forms data format (XFDF) file for use with Adobe® Acrobat® Standard 7·0, and significantly increases the efficiency of data management activities during study start-up.
Abstract: Case report forms (CRF) are essential tools in clinical research, used to gather data during the course of a clinical study. A common and useful task of data management personnel is to annotate the CRFs with appropriate variable names from the study data dictionary. Various authors have written on the topic of using SAS® to automate the annotation of CRFs, but with different approaches. We utilize a metadata database and XML tagsets to create an XML forms data format (XFDF) file for use with Adobe® Acrobat® Standard 7·0. The XFDF file is built utilizing a SAS® macro with user-defined content; the XFDF file is then imported into a portable data format file (PDF) containing the CRFs and the annotations are manually placed in the appropriate locations on the page. This process significantly increases the efficiency of our data management activities during study start-up. We have decreased our annotation work effort from several days to a 3 hour period.
1 citations
TL;DR: It is argued that the best way to construct an easy-to-program in and CFR 21 part 11 compliant environment for SAS® programming is by using a version control system, specifically the IBM Rational product ClearCase®.
Abstract: This paper argues that the best way to construct an easy-to-program in and CFR 21 part 11 compliant environment for SAS® programming is by using a version control system, specifically the IBM Rational product ClearCase®. It concentrates on architectural issues to do with protecting data and outputs as well as programs, and stresses the importance of linking an output with its constituent parts. The main reasons for using ClearCase® are explained and illustrated with examples from a successful implementation. Enough information about ClearCase® is included to show why it is uniquely suited, among all Source Code Management Systems, for this task. Although this paper focuses on SAS®, the environment can also be used for other programs with little or no changes.
1 citations