P r o d u c t   F e a t u r e s
Case Report Forms
Use web screens to define metadata about studies, data attributes, and case report forms (CRFs) containing the attributes.   
Automatic generation of CRFs from the metadata.  Use the defined CRFs to enter, edit and review clinical data.
CRFs may be simple layouts (1 row per data attribute), or, if you supply layout parameters, have data attributes laid out in groups, rows, and columns with indentation, prompts, format hints, and value units  for easier use and understanding.
"Skip fields": a CRF may block or allow use of an attribute based on the value of another attribute
CRF types may be grouped under a hierarchy of labels to aid in locating them.
Subject ID's
The ID of the study subject/patient, and the ID of the clinical center are concepts in the underlying system model.
System can generate new subject ID's with check character for minimizing identification errors.
Can designate primary keys for underlying data in a form to control how many unique records may be entered per subject.
Record retrieval
Filled-in CRFs may be retrieved by recency, completeness status, or subject ID.
Data attributes can have any of 15 different display/validation data types.
Data attributes can have any of 4 different internal storage types.
Data attributes can have coded values, with numeric or string codes.
Value code sets can be re-used by different attributes both within and between studies.
Metadata sharing
Data attributes are in a shared library.  You can use another study's attributes, or copy and modify them.
CRFs are in a shared library.  You can copy and use another study's CRF, and optionally modify it for your needs.
Value code sets are in a shared library; can be re-used by different attributes both within and between studies.
Comes with a set of standard attributes derived from caDSR.
Define single or multiple data collection sites, with data from one site invisible to users from other sites.
Only study admins can add new study sites and users.
Automated data entry
Subject ID's and clinical centers may be carried from a previous screen forward to a new instance of a CRF.
Data checking
Server-based data type checking
Server-based data range checking
Server-based skip field enforcement
Server-based required field checking
Server-based subject ID checking
Auditing and controlled editing
Each record (ie, a CRF being filled in) contains a modification timestamp and login identity of the modifying person.
Users designate a record as complete or incomplete.  Incomplete forms can be easily changed.  Complete forms must have changes approved by a study admin.
Requests to change data in complete CRFs are held in an audit table.  Only when they are approved is the primary data changed, and the audit table holds a complete record of the requested change and its resolution.
All logins and data are encrypted by SSL with a secure web server
Simplified login definition allows either LDAP (including Microsoft domain service) or local web server to validate logins
Simple model of access with two classes of users: study admins who can see, edit, and approve changes to all data in a study; and coordinators who can see and edit only their site's data
Web screen application for defining and administering login names and groups.
All data and metadata held in SQL Server, which gives atomic transactions, a variety of data backup options, and high degree of control over data access.
Value queries
Users can flag one or more items on a filled CRF as a value "query" and post messages concerning issues with the item value(s).
A query can be flagged as resolved, with pointer to any data edit that resolved it.
Self-entry of patient/subject data
Certain CRF types may be designated for patient use.
A patient can see and edit only his/her own CRF instances.
Study staff can generate automatic patient ID's and passwords used for login, with safeguards against duplicate ID's.  The patient's login is their subject ID in the system.
Study staff can define which CRF types may be used at a type of patient visit, and say which type of visit a patient will be having next.
Data extraction and reports
Each study has its own SQL Server database, which can be delivered to study staff at any time using SQL Server's tools.
On-demand download of all study data, or certain CRF types, in a neutral, delimited form for use in external programs.  Download respects clinical center boundaries.
Report by subject of which forms completed or incomplete.
Report on open or closed value queries
Search for approved and denied data changes by date range, subject ID, or CRF type
Notes on individual values
Any value on an instance of a CRF may have text notes attached to it, allowing for explanation, elaboration without having to plan a place for notes on a CRF definition.
User polling
Can conduct simple multiple-choice polls of system users about study isues.
Features available with additional, documented programming techniques or add-ons
Each study gets its own physical web site and its own SQL Server database. This allows various kinds of customization without affecting other sites.
Add outside links to the Study Manager pages
Customize aspects of the appearance of Study Manager home page and other screens
Add custom reports written in SQL to Study Manager 
Fields calculated from the value of other fields
Auditing of all changes, whether to completed OR incompleted records.
A shared file depot and message board
Email notification to users about data occurrences such as adverse events reported.
Produce a clone application for testing and training
Customize Study Manager to include search for familly by name or number in family studies
Customize Study Manager to lookup and display diagnostic images by subject.
Developed by: Nationa Jewish Health; Presented by Colorado Clinical and Translational Sciences Institute