Demonstration and Review of Metaclinic System

Basis Software

Oracle, Apache, mod_perl (increases speed by maintaining Perl and metadata in memory), Javascript

Features and Pros

• Metaclinic is organized around applications, forms, sections, data elements. The major tools included are Design, admin, import/export, access control tools. Access control to individual forms. The system is strong on repeating data types.
• Oracle Enterprise Manager is used to add users and change their permissions and other information.
• The database is populated with many meta tables including a table for system defaults.
• Dynamic html generated by Perl. There is a large table of default field formats. To change field characteristics, use Admin Tool to edit a table containing header, display attributes, order, etc., for form sections. Generates nice default html for data entry, and generates SQL field instantiations.
• Metadata for field form entry characteristics can include any html markups and Javascript functions to invoke
• Easy to edit field and value label presentation order, default values
• Save an old table and edit to create a new table, easy to compare field characteristics for comparing table structures, to catch errors. Nice table layout for code levels with a column specifying which level is the default, and a column with the display order.
• Point and click report generation with hyperlinks from output back to source data.
• Uses generic SQL, handles date strings, etc. in Perl for generality (as of now implements Oracle and Access back ends)
• DP: Does this mean it will be fairly easy to convert to other back ends?
• Javascript can make read-only fields e.g. age once birthdate entered. Javascript can catch errors as they are entered. Summary at bottom of forms showing who, when record was entered.
• Easy deletion of elements of repeated fields after data entry (by blanking out a required field)
• Value labels can be re-used by other fields
• As all metadata are in standard SQL tables, export of metadata for annotating analysis files is straightforward

Cons

• Each configuration has to have a unique configuration; need to edit Apache config files
• TC: Not quite true. The authorization system, which I did not discuss due to time constraints and which is completely independent of the metaclinic system, requires modifying the apache config file but that is necessary only if access control is desired for individual applciations (which is usually the case). If not using the authorization system, one would still need to configure apache at least once to designate mod_perl as the processing agent for the metaclinic applications, but this is standard whenever you decide to use mod_perl with apache. You could also elect to take a performance hit and run the applications under CGI with little, if any, apache configuation.
• A GUI admin tool similar to phpmysqladmin would make administration of the system more user-friendly.
• No audit trail other than original person who entered and last person who updated a record
• No separate units of measurement attribute for numeric fields
• Can use sections of forms from other projects but these must be semi-manually copied; there is no sections repository as in Oncore
• TC: I don't consider the lack of a sections repository nearly as detrimental as the lack of a forms repository, both of which, I believe, are available from Oncore.
• Coded fields use internal numeric coding that is a function of other fields' codings, so you can't query coded fields across different databases
• Code lists (value labels) can be exported though not in a single table
• TC: I am not quite sure what is meant by a 'single table' here. All exports are to delimited files at this point and it is indeed possible to dump the entire contents of the meta_code_data table which contains code lists. It is directly possible from the design tool, but end users will typically not have access to that tool. In which case the developer can create a report that details the meta_code_data table in about 2 minutes which I was doing when we ran out of time at the end of yesterday's demostration.

Conclusions

Metaclinic has a very well laid-out modular design with excellent response time. Hierarchical organization of forms, subforms, and data elements in metadata is very logical. The system is expected to function well when users are coupled with high-level database administrators. The system currently is not easy enough to use by mid-level database managers (e.g. research nurses with clinical data management experience) to allow them full access for defining or changing the structure of the database (consideration could be given to developing a team for new projects that includes at least one high-level data manager per group of projects). The metadata behind the system is well organized and clear. Consideration should be given to whether a scripting language could generate the metadata faster than entering it into tables, especially when hundreds of fields need to be defined for a new project.

• TC: I would like to thank Frank or Paul or the committee for the kind review of the brief demonstration that I gave yesterday. There were a couple of inaccuracies that were probably due to inadequacies in my presentation. I have tried to give better explainations below the points in question(as per previous discussions) and I corrected the explaination under 'basic software', slightly. We only hit on the tip of the iceburg yesterday and I encourage anyone who is really interested in the Metaclinic Database System to come by my office for a more in-depth presentation.