Over
time the master tables can get populated with redundant data and garbage
records that cannot be deleted if they have “child” records. Version 3.6 has a utility for the City, Medication,
and Medical History table that will let the user select a “preferred” code for
an existing record. The user is prompted
for whether they want all existing “child” records that have the current code
to be updated to the “preferred” code.
If the user chooses “yes,” the child records are updated, and the
current record can be deleted from the master table.
However,
the user may elect not to delete the record, so that it may remain in the
master table and be selected from input.
If it is selected at input, it will automatically be re-directed to the
preferred code. For example, if your
master medical history table has records for “Hypertension,” “High Blood
Pressure,” and “HTN,” you will recognize that you have a certain redundancy in
the master list. You may choose to set
the preferred code for “High Blood Pressure” and “HTN” to “Hypertension,” and
to reset all child records to the preferred value. But if you elect to remove the “HTN” and
“High Blood Pressure,” there is no guarantee that within a few new patients,
someone will come right in and add them back to the list. If you allow them to remain, users can still
select “HTN” on the patient medical history screen, but as soon as they leave
the field, it will be set to “Hypertension.”
We are currently
working on a similar utility for Procedures.
There is
an existing utility for Providers.
This is
not a common thing, but it does occur.
In version 3.0 and earlier, provider compensation was limited to
procedures – that is, if any third party, other than the patient, was to be
paid by the site, you had to use a procedure with a cost in the budget. This worked well, and will continue to work
for a vast majority of sites, since this is how they negotiate the payment to
these third parties. But consider the
case of the investigator who gets a percent of the visit. You can only do a true percentage at the
visit-level, but you can only attach a provider to a procedure. In 3.6, you can select a provider for a
visit-level item, and you will see the item in provider compensation.
On the Per Study tab of the study budget, you can
set a cap for a category, and Clinasyst will display
the remaining balance. It will display
as a negative number if you’ve exceeded the cap. For example, your budget may allow up to
$3000 for advertising. As long as you
spend less than $3000, you still have money available. You can set a budget category cap for the
Category “Advertising” of $3000 in cost and price, and as you spend the money,
record the actual amounts in the Per Study tab.
If you create two records, one for $1800 for radio advertising and the
other for $800 in newspaper advertising, your accumulated cost/price is $2600
under the category and you have $400 left.
In
version 3.0 and earlier, procedures were priced per provider per study. In 3.6, you can enter a default cost and
price, and you only have to make provider-specific entries if they vary from
the default.
3.6 allows procedures to be priced with an effective date. This is helpful for sites that may have no
control over costs, such as hospitals and universities.
In 3.6,
you can output scheduling information to an Outlook calendar and patient
information to an Outlook contacts file.
Using third-party software, you can download this information to a PDA.
Unconfirmed
incomplete appointments can now be visually differentiated from confirmed
incomplete appointments
In 3.0
we implemented resource scheduling. The
interface for the resource scheduler is a horizontally oriented time frame with
rows for individual resources, whether providers or other resources. One limitation of this view is the row height
for the resources. When the scheduler is
populated, appointments are displayed which occupy virtually the entire
row. If another appointment exists which
would occupy the same row and time-frame, it cannot be displayed. In effect, the row can only display one
time-bar per time period. In 3.6, where
there is a conflict between two or more appointments, we are displaying two
half-height time-bars to indicate this situation.
With
the limitations that still exist in the row-oriented scheduler,
we are implementing a multi-resource, multi-column scheduler that will be
vertically oriented, like the scheduler in Outlook. Multiple appointments for a resource and time
slot will simply share the available column width.
The
concept behind recruitment tracking in version 3.6 is that, rather than a
series of distinct, separate contacts with a potential subject, recruitment is
a dialog, with a beginning, a middle, and an end. With our recruitment effort, we want to be
able at any point to know where we are in the dialog and where we have been,
and, ultimately, we want to drive each dialog to some form of resolution. This concept could be done in version 3.0 by
creating one tracking record for each initial contact, changing the status of
that tracking record, and keeping good notes.
In 3.6, status codes themselves indicate whether the effort is resolved,
and as the user changes the status, the status history is updated. You can look back over the history of a
tracking record and see its history. Of
course, you can still keep good notes, but the status history tells much of the
story itself. Recruitment history can
also be viewed on patient master.