Pj i j q Journal of the American Medical by the36chambers

VIEWS: 5 PAGES: 8

									:Pj :;i; $ :j# :.:.: ::::: $$ .;q

? $

Journal

of the American

Medical Informatics

Association

Volume 3 Number 2 Mar / Apr 1996

..‘:

j,,,

i

Application

of Technology

w

Development of a Replicated Database of DHCP Data for Evaluation of Drug Use :‘(‘:‘,‘,‘,‘,‘~,‘.‘,~;,’ :,.W.W.A~ y< 7 i.~.,V.,V... ‘<.. ...
';.~j".',','~,','.~~~~:~.::::~.:::::::::~.:~:::::~:::~:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::~::::::.:.:.:.~.~.:.:.:,

KARENO.

STANLEY E. GRABER, MD, JOHN A. SENEKER,PHARMD,ARCHIE A. STAHL, FRANKLIN,PHARMD,THOMAS E. NEEL, MS, RANDOLPH A. MILLER,MD

Abstract

case This report describes development and testing of a method to extract clinical information stored in the Veterans Affairs (VA) Decentralized Hospital Computer System (DHCP) for the purpose of analyzing data about groups of patients. The authors used a microcomputer-based, structured query language (SQL)-compatible, relational database system to replicate a subset of the Nashville VA Hospital’s DHCP patient database. This replicated database contained the complete current Nashville DHCP prescription, provider, patient, and drug data sets, and a subset of the laboratory data. A pilot project employed this replicated database to answer questions that might arise in drug-use evaluation, such as identification of cases of polypharmacy, suboptimal drug regimens, and inadequate laboratory monitoring of drug therapy These database queries included as candidates for review all prescriptions for all outpatients. The queries demonstrated that specific drug-use events could be identified for any time interval represented in the replicated database.

n

JAMIA. 1996;3:149- 156.

The Department of Veterans Affairs (VA) hospital computer system (Decentralized Hospital Computer

Program, or DHCP) is standardized throughout the VA and is operational at more than 170 sites.’ This system contains a large amount of detailed clinical data and plays a critical and central role in the dayto-day management of VA patients. However, this database is difficult to use for epidemiologic analyses. For example, a simple question of “how many patients with a diagnosis of tuberculosis within the past year are having their prescriptions for antituberculosis drugs regularly filled and have had timely chest xrays” would require considerable effort to answer using the DHCP database. There are several reasons for this. The VA database is optimized for retrieval of inAffiliations of the authors: Medical and Pharmacy Services, Veterans Affairs Medical Center, and Division of Biomedical Informatics, Vanderbilt University School of Medicine, Nashville, TN. Supported in part by general funds from VAMC Nashville and from the Nashville Research Institute. All MUMP’S routines used for data extraction and all SQL scripts have been placed in the public domain. Correspondence and reprints: Stanley E. Graber, MD, VA Medical Center. 1310 24th Avenue South, Nashville. TN 37212.

formation about individual patients, not about groups of patients. The tools that can be used to query the database are limited to the database management system, VA Fileman, or development of customized MUMPS routines. In addition, due to heavy daytime clinical usage, DHCP realistically can be queried only during “off hours,” i.e., at night or on weekends, which impedes and prolongs development of useful query or report formats. Replication of a subset of data from DHCP into a relational database that resides on a personal computer (PC) and supports Structured Query Language (SQL) can circumvent these problems. More specifically, database tables and relationships can be designed to facilitate queries about groups of patients, and sophisticated third-party tools that capitalize on the versatility and power of SQL can be used to analyze the data. Furthermore, once the database resides on a microcomputer, it can be queried conveniently and repetitively without degrading the performance of DHCP. The approach of replicating VA DHCP databases on a PC is applicable to a wide variety of tasks. However, the pilot project detailed in this report involves identification of patterns of drug use. The method described and the queries utilized demonstrate the po-

e-mail: graber.stanley@nashville.va.gov .
Received 11/6/95. for publication: 5/17/95; accepted for publication:

150

GRABER ET AL., Replicated

Database for Drug-use

Evaluation

PATIENT Flgure 1 Structure of the PC-DUE relational database. Each box corresponds to a table in the database, while the names within boxes represent the columns in each table. Primary keys are followed by a PK abbrevitvkxstat ation, while foreign keys are followed by Occumon an FK abbreviation. A double-arrowed line represents a one-to-many relationship, with DOD -A the arrows denoting the many sides. The primary keys in the PROVIDER and DRUG tables, i.e., the MD-ID and Drug-ID columns, are unique numbers that represent the internal DRUG entry numbers assigned by the DHCP database. The Pt-IEN column in the PATIENT table PRESCRIPTION zssl is also an internal entry number assigned CICISS by DCHP It provides a unique reference +J%gJ FOrm~Skrt to each patient entry within DCHP that is Drug-Name t independent of the patient’s social security number and is used to ensure that the PC-DUE database can be easily updated to reflect any correction of patients social security numbers in DCHP. Since each prescription can have refills, a single prescription number (Rx-Number) is often assigned to several fills. This means that both the Rx-Number and the Fill-Date columns are required to define a unique row in the PRESCFUPTION table and that this table contains a redundancy consisting of identical values of all non-primary key columns for each new prescription and any refills referenced to that prescription.

tential for automation

of the drug-use evaluation
at an institution can

(DUE) process. All prescriptions

be readily reviewed, thereby reducing sampling problems’ and the time required for manual review of records. Most VA sites running DHCP can use this method, and it can be expanded and applied to additional types of data within the DHCP database.

Development Replicated ofThe Database
Evaluation of drug use requires a significant subset of the DHCP database that includes prescription, patient, provider, drug, and laboratory data. This data set, except for the laboratory information, must be complete and must cover a considerable period of time. The size of the data set will depend on the size and nature of the institution from which it is derived. The Veteran Administration Medical Center (VAMC) in Nashville is a 334-bed acute-care hospital that has approximately 8,200 admissions and 148,000 outpatient visits per year. Over 60,000 outpatient prescriptions are filled each month, and there are more than 28,000 active patients. Thus, robust PC database software is necessary. Database Tools R:BASE version 4.5+ (Microrim, Bellevue, WA) was selected as the database development platform. This product uses a DOS extender to operate in 32-bit

mode in extended memory, fully meets the 1989 ANSI SQL standard: partially implements the ANSI SQL enhancements of the 1992 standard,’ has a programming language that supports embedded SQL, has a menu-driven application developer, and has a capable data-import/export utility. Moreover, the physical size of the database is limited only by the amount of hard-drive storage, i.e., each R:BASE database file must fit on a single drive. Several other commercial products that run under MS-DOS, Windows, OS/2, The Macintosh OS, or UNIX on workstations also meet these criteria and might be suitable choices for developers elsewhere. Database Structure Figure 1 shows the structure of the authors’ relational database, PC-DUE, including the structure of each individual table and the relationships between tables. The corresponding DHCP files and fields from which the data in each table are derived are shown in Table 1. The database consists of five tables, named PATIENT, PROVIDER, DRUG, PRESCRIPTION, and LAB (Figure 1). Each table is at least in first normal form, i.e., there am no repeating groups within the table, and it contains a column or combination of columns (primary key) that can uniquely identify each row. Also, all tables on the many side of a one-to-many relationship (PRESCRIPTION and LAB) contain linking columns (foreign keys) whose values match the primary keys in their parent tables. Indexes are built for all pri-

Journal

of the American

Medical

Informatics

Association

Volume 3

Number

2

Mar / Apr 1996

151

mary and foreign key columns and are necessary for reasonable performance. The drug description (Drug-Dscrpt) column in the DRUG table corresponds directly to the content of the “generic name” field in the DHCP Drug file. In addition to the generic drug name, each entry contains size and dose format information, e.g., “prednisone 5 mg tab” represents a single complete entry for the Drug-Dscrpt column, whereas “prednisone 10 mg tab” is another completely distinct entry. The generic drug name itself, i.e., “prednisone,” is obtained from the “NaTable 1
n

tional Drug File Entry” field, and loaded into the Drug-Name column. Extraction of Data from the DHCP The strategy for extracting data from DHCP involved using 1) DHCP routines to write information onto the screen of a PC (serving the role of a DHCP terminal) in ASCII comma-delimited format; 2) PC-based routines to capture this information in a DOS file; and 3) the data-import capability of the database product

Mapping of DHCP Files (MUMPS Globals) and Fields to PC-DUE Tables and Columns
DHCP File Name & (#) Patient Patient Patient Patient Patient Patient Patient Patient (2) (2) (2) (2) (2) (2) (2) (2) DATABASE Field Name & (#)’ SSN (0.09) Name (0.01) sex (0.02) Marital Status (0.05) Occupation (0.07) Date of Birth (0.03) Date of Death (0.351) Number (0.001) Number (0.001) Name (0.01) Provider Type (53.6) SSN (9) Number (0.001) Generic Name (0.01) VA Classification (2) Non-Formulary (51) National Drug File Entry (52) (52) (52) (52) (52) (52) (52) (52) PC -DUE Table Name PATIENT PATIENT PATIENT PATIENT PATIENT PATIENT PATIENT PATIENT PROVIDER PROVIDER PROVIDER PROVIDER DRUG DRUG DRUG DRUG DRUG PRESCRIPTION PRESCRIPTION PRESCRIPTION PRESCRIPTION PRESCRIPTIQN PRESCRIPTION PRESCRIPTION PRESCRIPTION LAB LAB LAB LAB LAB DATABASE Column Pt-SSN Pt-Name
Sex

Name

Mar-Stat Occupation, DOB DOD PttIEN MD-ID MD-Name MD-Class MD-SSN Drug-ID Dn4%Dscrpt Class Form-Stat Drug-Name Rx-Number Fill-Date Pt-SSN MD-ID Drug-ID Quantity Refills unit-cost PtSSN Test-Name Test _ Date Test-Time Test-Rslt

New Person (200) New Person (200) New Person (200) New Person (200) Drug (50) Drug W) -4 (50) kg (50) Dw3 (50) Prescription Prescription Prescription Prescription Prescription Prescription Prescription Prescription Lab Data Lab Lab Lab

(20)

Rx # (0.01)
Fill Date (22) & Refill Patient (2) + [Patient Provider (4) Drug 69 (52), Refill Date (O.Ol)t (2), SSN (0.09)]$

Qty VI
# of Refills (9) Unit Price of Drug (17) Name (0.03) + [Patient (2), SSN (0.09)]$ Lab Data-Chem (63.04), Test Name (x)ll Chem (4), Date/Time (0.01) Chem (4), Date/Tie (0.01) Chem (4), Test Result (x)7

Data (63) Dictionary§ Data (63) Data (63) Data (63)

*Multiple field names separated by commas represent sequential levels in the MUMPS global. The information desired is in the last identified field. t Both the Fill Date and the Refill Date fields contribute data that are stored in the Fill-Date column of the PRESCRIPTION table. $A right arrow indicates that the field contents are used as a pointer. The information to the right of the arrow in brackets represents the file name and number followed by the field name and number that contains the desired data. §The Data Dictionary file (global) is not assigned a number. IFinds the test name or the test result based on user input of a test-identification number, where (x) equals that number. For example, user input of 4 will find the test name of creatinine in the Data Dictionary global and creatinine results in the Lab Data global.

152

GRABER ET AL., Replicated

Database for Drug-use

Evaluation

to upload the data into a relational table. While it would have been possible to transfer files directly from the DHCP to a PC, a screen-capture technique was employed because it could be accomplished without modifying the standard DHCP-PC connection used at Nashville VAhK. The connection consists of a 9,600-baud serial link and a communications package (Procomm 2.0 for DOS) operating in terminal emulation (VT 102) mode. The “log” function of Pro-

comm was used to redirect data written to the screen to a file on the hard drive of the PC. Both VA Fileman and MUMPS routines were used to write data to the screen. Fileman templates (stored search and format logic) are relatively simple to create and work well when data from “multiple or sub-fields” are not required. They were used to obtain data in the correct format for the PATIENT, DRUG, and PROVIDER tables. Since the refill data are stored in a “sub-field” in the

L. sckct Pt SSN

~+-wI PRESCRIPTION
where Drug-ID in ((drug-id I ) , { drugid2)) group by IY-SSN having count (distinct Drug-ID) = 2 I. select Pt-SSN,Drug-Name,coun/ (distinct Rx-Number),counr (Fill-Date),min (Fill~Date),mur (Fill-Date) from PRESCRIPTION Tl ,DRUG T2 wd Drug-Name in where Tl .Drug-ID = T2:Drug-ID ((drug~namel },(drug~name2},(drug~name3} ,(etc.})ond Fill-Date < = (interval_entl_date) group by Pt-SSN,Drug-Name having count (Fill-Date) > 1 and Max (Fill-Date) > = {interval-start-date} 3. select count (distinct Pt-SSN),counr (Fill-Date) from PRESCRIPTION where Fill-Date between {07/01/93} and ( 12/31/93) and Pt-SSN in (select Pt-SSNfrom PRESCRIPTION where Fill-Date

between {01/01/93) and {06/30/93})

I. sekcl Ti . Pt-SSN,mor (Pt Nn~ne).nrtrr (DOB),C~WI/ (Fill~Dntc).ntirr (I~ill_I~alc).rrrtrr (Fill~Dalc) jionr PRESCRIPTION~I’I ,PATIENT ‘1’2 where Tl.IY-SSN = T2,IY-SSN cmd ((((interval-end-date} - DOB)/365.25) > (65)) and Drug-ID in (select Drug-IDfrom DRUG where Drug-Name = {‘chlorpropamide’}) and Fill-Date < = (interval-end-date} group by Tl .Pt-SSN having mar (Fill-Date) > = (interval-start-date]

F I g ure 2 SQL queries used to perform evaluations of drug use. SQL keywords are in italics, while lower-case items enclosed in brackets represent variables that can be changed at run time. A. Query used to identify patients receiving any two drugs in the database. The where clause limits the rows to prescriptions for medications identified as drugid1 and drug-id2 and works with the “count (distinct Drug-ID) = 2” condition in the having clause to return Pt-SSNs of only those patients who have had fills for both drugs. These are stored in a temporary table, which is then updated with the first and last fill dates for each drug so that the data for both drugs are ln one row. A final query selects those patients with overlapping prescription date ranges within a defined time interval. B. Query used to detect simultaneous use of any number of drugs in the database for any time interval. It invokes a join between the PRESCRipton and DRUG tables, which allows the prescription data to be grouped by drug name within each Pt-SSN. The where clause restricts the data to prescriptions filled prior or equal to the end date of a defined interval, while the having clause returns only those records where the prescription data range encompasses at least two fills and ends after or equal to the start date of the designated interval. C. Query used to determine the total number of fills and unique patients for various time intervals for a cohort of patients referenced to an initial interval. The count (distinct Pt-SSN) function returns the number of unique patients for a particular interval, while count (Fill-Date) returns the total number of fills. Both a select statement and a subquery of the PRESCRIPTION table with the new and original date ranges are used to ensure that the Pt-SSNs are present in both intervals. D. Query used to identify patients who are receiving a specific drug for a specific interval and are older than a particular age. It uses a join between the PRESCRIPTION and PATIENT tables, a sub-query of the DRUG table, and the time interval logic described in item B to find all patients over age 65 with a prescription date range for chlorpropamide that ends within the defined interval. The join is necessary to retrieve the patient’s date of birth (DOB), which is used in the where clause to calculate each patient’s age and exclude those less than or equal to 65 years old. The sub-query restricts the Drug-IDS to the set associated with chlorpropamide.

Journal

of the American

Medical

Informatics

Association

Volume 3

Number

2

Mar / Apr 1996

153

prescription global, it was not possible to use Fileman to format the prescription data in a manner that suitably linked the refill date to the original prescription. Thus, a MUMPS routine was written that could extract and correctly format all prescription data within a user-defined date range. A MUMPS routine was also used to extract the laboratory data. This code was capable of capturing the data for a specific test and date range as defined by user input. Prescription data (60,000-70,000 entries) are extracted monthly. The transfer requires approximately 5.5 hours-l.5 hours to extract the data from DHCP and 4 hours to load it into the PC-DUE database. In contrast, extracting the patient, drug, and provider data was primarily a one-time occurrence. These tables are expanded monthly to include any new patient, drug, or provider information. However, the number of new entries and their load times are small. The laboratory data are extracted periodically and selectively as needed for a particular drug use analysis, i.e., no attempt is made to replicate the complete set of laboratory data available in DHCP, The accuracy of each extract is verified monthly by manually comparing a sample (approximately 40 records) of the prescription data in PC-DUE against the original data in DHCP. This comparison is done in both directions, i.e., records are selected from both PC-DUE and DHCP and checked against the other database. After 26 months (over 1,000 records), no error related to the extraction process had been detected. Also, after 26 months (11/l/92-12/31/94), the size of the database by rows per table was PATIENT, 28,978; PROVIDER, 6,497; DRUG, 4201; PRESCRIPTION, 1,605,502; and LAB, 159,819, while the size by bytes of disk space was 246,022,144 for the three RBASE files. Data Integrity Referential integrity requires that every entry in a table on the many side of a one-to-many relationship reference a single entry in the parent table. Entity integrity requires that each row in a database table have a primary key consisting of one or more columns that uniquely identifies that row. Both of these constraints have been maintained in the PC-DUE database-it contains no orphaned records; no keyed columns are null; and the primary key for every row in each table is unique. These integrity rules were enforced by running specific SQL queries against the database each time new data were loaded. For example, the query, “select distinct Pt-SSN from PRESCRIPTION where Pt-SSN not in (select Pt_SSN from PATIENTS),” checks referential integrity by identifying any patient in the PRESCRIPTION table who is not in the PATIENT

table. Similar queries are used to check for orphan PROVIDER, DRUG, or LAB data. If any row is returned, then the appropriate Fileman template is used to obtain the missing data from DHCP. The query, “select Rx-Number, Fill-Date from PRESCRIPTION group by Rx-Number, Fill-Date having count (Fill-Date) > 1," checks entity integrity by returning rows from the PRESCRIPTION table that have identical Rx-Number and Fill-Date columns, i.e., the same primary key. Such rows could either be true replicates, in which case all but one is deleted, or represent multiple fills of the same prescription on the same date. In the latter case, which occurs approximately once per 5,000 fills and is documented by manually checking the replicates against the DHCP database, one or more fill dates is incremented by the fewest number of days (usually one) necessary to make the rows unique. While this compromise alters the data, the changes are minimal and almost certainly not significant in terms of DUE analysis. Similar queries are used to check for replicates in the other tables. In these cases, any identical rows represent true replicates and all but one are deleted. There are other data-integrity issues that are primarily related to nuances of the DHCP database structure and management policy. For example, a major problem at Nashville VAMC has to do with allowing multiple entries of the same physician in the DHCP New Person file. One can correct this problem by screening the PROVIDER table for multiple instances of the same provider with entries in the PRESCRIPTION table each time new prescription data are loaded into PC-DUE. This screening is based on a combination of attributes, including the provider’s social security number, name, and class (full-time, part-time, housestaff, etc.). Any ambiguous occurrence is investigated to the degree necessary to determine the correct provider entry and the PC-DUE database is appropriately updated so that all prescriptions by a single provider reference a single entry in the PROVIDER table.

Querles Support to Drug-use Evaluation
The PC-DUE database was used to perform a variety of DUE analyses that included screening for potential drug interactions or potentially redundant drug therapies, identification of possible polypharmacy, assessment of the use of potentially dangerous drug regimens, and checking for appropriate monitoring of drug levels or pertinent laboratory tests. The queries supporting these analyses are illustrated in Figure 2 and generally entail identifying the total number of unique patients or events in a sub-group of the outpatient population (denominator) and the number

154

GRABER ET AL., Replicated

Database for Drug-use

Evaluation

Date

Date

E

Figure 0 3 Possible prescription date ranges (time from first fill to last fill) for a single drug for a specific time interval. Start Date and End Date labels define the boundaries of the interval of interest, while “s” and “E” represent the start and end of each possible prescription date range. Ranges 1 through 4 must be included for each drug in any two-drug comparison of overlap of prescription date ranges referenced to a specific interval. Notice that as the interval between Start Date and End Date decreases,prescription date ranges ending within the interval are more likely to overlap, and that, if prescriptions filled after the End Date are excluded, the
number of possible prescription date ranges decreases to ranges 1, 2, and 5.

matory drugs (NSAIDs), requires a different strategy. Two queries are used for any number of comparisons and involve: (1) defining a time interval that is sufficiently narrow so that prescription date ranges ending within that window would very likely overlap; (2) limiting the prescriptions to those filled prior or equal to the end date of the defined time interval; and (3) selecting only those records where the maximum (most recent) date of the prescription date range for each individual drug was within the defined time interval. The major query that demonstrates this approach is shown in Figure 28. By changing the end date, which excludes all prescriptions after that date and thus has the effect of simulating the conditions that existed at that particular time, and the start date, this strategy can be used to evaluate any time interval within the database. A second query then simply identifies those patients who have multiple prescription date ranges ending within the interval of interest. The results of such an analysis for gastric acid suppressants, benzodiazepines, and NSAIDs are shown for several two-month intervals in Table 2 and demonstrate that this type of analysis can measure the total number of unique patients (denominator) as well as the number with simultaneous prescriptions for all of the drug classes. A more global way to evaluate polypharmacy is to determine the total number of fills and the total number of unique patients for successive time intervals and then calculate average number of fills per patient for each interval. This type of analysis can be done for all patients for each interval or for only those patients followed chronically at the medical center. The query used to retrieve the appropriate counts for a chronically-followed cohort, i.e., a group of patients seen at least once in each of two succeeding intervals, is shown in Figure 2C. A specific example of a potentially dangerous drug regimen is the use of chlorpropamide in elderly diabetics. This drug has the highest incidence of producing hypoglycemia of all the oral sulfonylurea agents” and is particularly dangerous in geriatric patients.’ The query used to return the pertinent data is shown in Figure 2D. When run for the interval 12/01/94 to 01/31/95, this query identified 34 patients over age 65 who were receiving chlorpropamide. By combining the query with an SQL update statement, a list of such patients was generated that included their names, social security numbers, ages, prescription data, and provider information. A final category of DUE involves appropriate monitoring of drug levels or pertinent lab tests. The example implemented detects patients receiving levo-

that met DUE specific criteria (numerator) for various intervals represented in the database. The duration of the intervals evaluated in the analyses was influenced by the prescription rules at VAMC Nashville, i.e., each prescription is limited to five refills (6 total fills) and each fill contains up to a 30-day supply of medication. A specific case of redundant and possibly dangerous drug therapy involves individuals with simultaneous prescriptions for multiple beta-adrenergic agonist inhalers.” Since only albuterol and metaproterenol inhalers are dispensed at Nashville VAMC, the primary strategy utilized drug-identification numbers (Drug-IDS) to select patients receiving a specific twodrug combination during a given time interval. It was implemented with the general query shown in Figure 2A and involved determining overlap of prescription date ranges (time from first to last fill) within a defined interval (Figure 3). The complexity of this approach increases rapidly with increasing drug number. Thus, identification of use of multiple drugs from the same functional class, e.g., patients on multiple benzodiazepines or multiple nonsteroidal anti-inflam-

Journal

of the American

Medical

Informatics

Association

Volume

3

Number

2

Mar / Apr 1996

155

thyroxine replacement for more than one year who have not had a thyrotropin (TSH) assay within that year. An initial query similar to the one in Figure 2D was used, except that the data were not limited by age. When run for four sequential two-month intervals, this analysis not only determined the total number of patients with active prescriptions for levothyroxine (239 to 302) and the number receiving the drug for more than one year (186 to 210), but also determined the number from the latter group without a TSH assay (34 to 39) during that year. In contrast to the other analyses, the incidence of individuals lacking an event was measured. The total computer run time necessary to obtain the data in Table 2 was 168 min for the 12 analyses, while the times required for the other DUES ranged from less than 2 min for the chlorpropamide evaluation to approximately 10 min for each levothyroxine-thyrotropin analysis.

anisms involved in capturing DHCP data (Fileman templates or MUMPS routines that write ASCII delimited text to the screen), while not particularly elegant, are straightforward, and do not involve any alteration to the structure or function of DHCl? The method described could be used at many of the more than 170 VAMC sites running DHCl? Furthermore, the database structure and queries can be customized to meet the needs of each institution. Several factors should be considered prior to any decision to implement the PC-DUE method. First, the MUMPS routines (available from the authors) used to extract the prescription and lab data from DHCP are designed to work with the standard VA global structure. Thus, any local or national modification to the pertinent globals may render the routines useless or require that they be rewritten to reflect these changes. Second, implementation will require considerable effort on a continual basis from at least one employee who has substantial expertise in both DHCP and relational database structure and function. Third, the VA is attempting to develop a relational database that uses extracts of DHCP data from all sites and that will provide considerable decision-support functionality, including the ability to evaluate cohorts of patients. This system, known as DSS,” is currently being evaluated at ten sites, is scheduled to be implemented throughout the VA in 1996 and 1997, and may be fully operational in 1998. Finally, there are certain hardware

A method for replicating a large subset of Nashville VAMC DHCP data into a relational database located on a microcomputer that fully supports SQL has been developed and implemented. The replicated database has a simple logical structure consisting of five tables with one to many relationships. Moreover, the mechTable 2
n

Incidences of Patients with Concurrent Prescriptions within a Single Therapeutic Class for Various Time Intervals and Classes
Interval 6/l/93-7/31/93 Acid suppressants* Unique patients Multiple-fill number Multiple-fill percent Benzodiazepinest Unique patients Multiple-fill number Multiple-fill percent NSAIDs$ Unique patients Mulitple-fill number Multiple-fill percent
TCJTALUNIQUEPATIENTS

12/1/93-I/31/94 3,167 45 1.42%

6/l/94-7/31/94 3,503 so 1.43%

12/I/94-1/31/95 3,764 56 1.49%

2,934 35 1.19%

2,118 98 4.63%

2,169 103 4.75%

2,194 110 5.01%

2,273 113 4.97%

3,624 72 1.99% 13,887

3,949 87 2.20% 14,196

4,259 99 2.32% 14,756

4,460 119 2.67% 15,032

*Cimetidine, ranitidine, and omeprazole. t Alprazolam, chlordiazepoxide, clonazepam, diazepam, flurazepam, lorazepam, oxazepam, temazepam, and triazolam. SNonsteroidal anti-inflammatory drugs, including diclofenac, fenoprofen, flurbiprofen, ibuprofen, indomethacin, ketorolac, fenamate, nabumetone, naproxen, phenylbutazone, piroxicam, salsalate, sulindac, and tolmetin.

meclo-

156

GRABER

ET AL.,

Replicated

Database for Drug-use

Evaluation

and software requirements. This is probably the least important factor in that the PC-DUE database runs acceptably well on a 90-MHz Pentium PC with 16 megabytes of RAM and a l-gigabyte hard drive. This type of machine is widely available for $2,500 or less, while the cost of the relational database and terminal emulation software is about $600. The various DUE analyses reported in this paper demonstrate how standard SQL queries used with a PC-based subset of the current DHCP databank have the potential to circumvent several of the problems traditionally associated with DUE. These analyses used all prescriptions for all outpatients during multiple defined time intervals, thereby diminishing sample size and selection errors. Both the presence and the absence of DUE events could be measured, i.e., the lack of appropriate drug use as well as the presence of undesirable therapy could be detected. The method can identify individual “at-risk” patients as well as provide aggregate statistical data. Next Steps It is anticipated that use of the PC-DUE database will be expanded to include analyses that extend the traditional DUE role. For example, since angiotensinconverting-enzyme (ACE) inhibitors have been shown to slow the progression of diabetic renal disease,“,” all diabetics, i.e., those outpatients with active prescriptions for insulin and/or oral hypoglycemic agents, could be screened to determine whether they have had a timely urinalysis to check for urinary protein. Those who have proteinuria could then be evaluated to determine whether they were receiving an ACE inhibitor. Moreover, if an effective intervention arm could be developed, then compliance with accepted medical practice for the entire outpatient population would be enhanced, and the DUE process

would begin to take on some characteristics of a decision-support system.

Rej2rencesn
1. Ginsburg RE. Organizational analysis of the Veterans Administration decentralized hospital computer system: the challenge of innovation in a bureaucratic setting. Milit. Med. 1995;160:161-7. 2. Longo DR, Bohr D. Quantitative Methods in Quality Management: A Guide for Practitioners. 1st ed. Chicago, IL: American Hospital Publishing, 1991:3-7. 3. American National Standards Institute: ANSI X3.135-1989: Information Systems Database Language SQL with Integrity Enhancement. New York: American National Standards Institute, 1989. 4. American National Standards Institute: ANSI X3.135-1992: Database Language SQL. New York: American National Standards Institute, 1992. 5. Crane J, Pearce N, Flatt A, et al. Prescribed fenoterol and death from asthma in New Zealand, 1981-83: case-control study. Lancet. 1989;1:917-22. 6. Spitzer WO, Suissa S, Ernst P, et al. The use of B-agonists \ and the risk of death and near death from asthma. N Engl J Med. 1992;326:501-6. 7. Gerich JE. Oral hypoglycemic agents. N Engl J Med. 1989; 321:1231-45. 8. Seltzer I-IS. Drug-induced hypoglycemia: a review of 1,418 cases. Endocrinol Metab Clin North Am. 1989;18:163-83. 9. Beers MH, Ouslander JG, Rollingher I, Reuben DB, Brocks J, Beck JC. Explicit criteria for determining inappropriate medication use in nursing home residents. Arch Intern Med. 1991;151:1825-32. 10. VI-IA introduces DSS. BDC Newsline 1994;4(3):1-7. 11. Ravid M, Savin H, Jutrin I, Bental T, Katz B, Lishner M. Long-term stabilizing effect of angiotensin-converting enzyme inhibition on plasma creatinine and on proteinuria in normotensive type II diabetic patients. Arm Intern Med. 1993;118:577-81. 12. Marre M, Chatellier G, Leblanc H, Guyene IT, Menard J, Passa I? Prevention of diabetic nephropathy with enalapril in normotensive diabetics with microalbuminuria. Br Med J. 1988;297:1092-5.


								
To top