Metadata-driven ad hoc query of patient data: meeting the needs of clinical studies

Abstract

Clinical study data management systems (CSDMSs) have many similarities to clinical patient record systems (CPRSs) in their focus on recording clinical parameters. Requirements for ad hoc query interfaces for both systems would therefore appear to be highly similar. However, a clinical study is concerned primarily with collective responses of groups of subjects to standardized therapeutic interventions for the same underlying clinical condition. The parameters that are recorded in CSDMSs tend to be more diverse than those required for patient management in non-research settings, because of the greater emphasis on questionnaires for which responses to each question are recorded separately. The differences between CSDMSs and CPRSs are reflected in the metadata that support the respective systems' operation, and need to be reflected in the query interfaces. The authors describe major revisions of their previously described CSDMS ad hoc query interface to meet CSDMS needs more fully, as well as its porting to a Web-based platform.

Figure 1

The overall architecture of the Ad Hoc Query Interface for TrialDB. In this “three-tier” architecture, the application resides on a Web server, which mediates between the Web browser and the database. An XML-based query specification is generated by the browser through the user's interaction with the metadata and search/identification of attributes of interest. This specification is then checked for correctness, and converted to a plan of action that generates SQL to create several temporary tables in the database, which can be viewed by the user. SQL generation is done with the help of metadata and “code templates,” which are parameterizable macros. Queries can be saved for later reuse by anyone with query privileges for that study.

Figure 2

The User Interface for a single-study query. Here the query requests baseline albumin and bilirubin, initial chemotherapy and dose, and (optionally) prior surgery information for patients who might have received any one of several concomitant medications (omeprazole, theophylline, coumadin, etc.) before onset of therapy; patients with impaired liver function, or low serum albumin, are predisposed to interactions between the drugs listed and specific cancer chemotherapeutic agents. The compound Boolean criterion (1 and 6) means that the selected patient must meet the criteria of having a bilirubin recorded in the pretreatment phase (row 1) AND having one of the medications on the list in the same phase (row 6). The user can drill down to an individual attribute via the forms within the study (and groups within the form) as well as by keyword search; the latter is accessed through the “Search” button above the list of forms. Selected attributes are displayed in a grid. Selection criteria may be applied by study-period restriction (start phase, end phase) or by relational/value operator, or both. (Although the user interface shows “time criteria” and “Boolean time criteria,” these are under development and their operation has been disabled; they are, therefore, not discussed in this paper.)

Figure 3

The results returned by the query in Figure 2▶. Only a single patient ID (1780979) matches the search criteria: This patient has received coumadin. (The ID is an anonymous one that is only meaningful within the study.) Notice that attributes are segregated by the use of co-occurrence metadata: Chemotherapy agent and dose are shown together, as are bilirubin and albumin. This patient has not had any prior surgery (the top table is empty), but that does not prevent this patient from being selected, since this field has been designated as optional in specification of the query. Also present in the output, but not shown here for space reasons, is a “key” for all coded data, such as the interpretation of all phase serial numbers for this study (here, 1=pretreatment, 2=cycle 1) as well as phrases corresponding to any choice set codes (such as gradations of adverse event severity). The patient ID is a hyperlink: Clicking on it takes the user to the TrialDB form that displays a list of available forms for that patient within this study.