Hello,

I dont exactly want to modify the WEBEAV but, is it possible that i
could get that visual sourcesafe file.

Thanks for your valuable support

Regards,
Govind


--- In trialdb@yahoogroups.com, Prakash Nadkarni
<Prakash.Nadkarni@...> wrote:
>
> It is looking for a Visual Sourcesafe file. Ignore this message if
you don't
> plan to modify the code and use source control.
>
> Prakash
>
>
>
>   _____
>
> From: trialdb@yahoogroups.com [mailto:trialdb@yahoogroups.com] On
Behalf Of
> GOVIND
> Sent: Tuesday, January 09, 2007 2:49 PM
> To: trialdb@yahoogroups.com
> Subject: [trialdb] can any one explain this
>
>
>
> hello,
>
> can any one explain how to open "WebEAV_2005" in visual 2005..
> its give error on opening and show error
>
> "WebEAV_2005 is under source control,associated control are not
> installed on the system,source control will be disabled for this
> project"
>
> can any one pls guide this how to use this source..
>
> thank you
>
> govind
>

hello,

can any one explain how to open "WebEAV_2005" in visual 2005..
its give error on opening and show error


"WebEAV_2005 is under source control,associated control are not
installed on the system,source control will be disabled for this
project"

can any one pls guide this how to use this source..


thank you


govind

Thank you very much for your reply.
I really appreciate it.
Just to confirm from you if we decide to use the web forms using SQL
schema. Do I need any software other than SQL Server 2000 and MS
Office?
Please let me know.
Thanks
Niti

--- In trialdb@yahoogroups.com, Prakash Nadkarni
<Prakash.Nadkarni@...> wrote:
>
> The way we have implemented DDE is that you create two studies with
> identical protocols (defining the first study and its forms, then
defining
> the second study with a DDE suffix and adding the newly created
forms to
> this one). Read our Web site, however, for reasons as to why we very
> strongly recommend against DDE as a means of QC.
>
>
>
> We only create Web forms now, not MS-Access forms. The very old
code that
> did this has been removed since 2000. (We moved to the Web in 1999,
we use
> Access only to define the metadata and generate the Web forms;
asking people
> to remember to download the latest Access client- and having them
repeatedly
> forget to do so and then sending us panic messages when their
client didn't
> work, was too much of a pain..)
>
>
>
>   _____
>
> From: trialdb@yahoogroups.com [mailto:trialdb@yahoogroups.com] On
Behalf Of
> H R
> Sent: Monday, January 08, 2007 11:02 AM
> To: trialdb@yahoogroups.com
> Subject: [trialdb] Can I use CSDMS only as Access client end?
>
>
>
> Hello
>
> I work here for a clinical trial system and developing the database
in
> access. The only major requirement that I have is to develop the
access
> forms with a double data entry feature. While browsing, I came
across your
> excellent TrialDB system, which has double data feature in it.
>
> I would like if know if I can use your system only to create my
access forms
> with double data entry feature in it.
>
> We do not data enter over the web, so we don't need the web
interface.
>
> Any inputs in this regard will be highly appreciated.
>
> Thank you very much.
>
> Regards
>
> Niti
>
>  __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Prakash, I was troubleshooting an error for Phillip and discovered
there is a unique index on the field SITE_ACRONYM in the SITES table.
While I understand the principle of this field in theory, I had to
remove in in our development server to get the client to be able to
add a site under the sites tab in administration. It kept bombing on
update due to it trying to insert a NULL value which had already been
assigned. My question is, since them SITE acronyms are assigned at
study design and stored in the STUDIES_SITES table, is the field even
needed in the SITES table, in other words, will a SITE ever need an
acronym not stored in the STUDIES_SITES table?

Thanks

As part of the code cleanup that is concurrent with the port to .NET, we
have created a TrialdBPrivileges object that is initialized and placed in
Session state after the logged on user selects a study. This contains
information about the user (contact info), the study (e.g., the study title,
whether patient names are to be shown, etc.) as well as the user's
privileges for that study - there are about 40 properties in all (though the
object probably doesn't take up more than 300 bytes in RAM on average).
Every page in the rest of the application fetches this object from session
state when it first opens (or more than once), so as to access the
individual properties that it may need.

This object eliminates the need to repeatedly shoot SQL to the database to
get information that is displayed on most pages, such as the study title,
the user name, study settings, etc - such statements littered the old code.

For this object to work correctly, you will have to make two changes to your
database:

1. Set the Default for the Site_ID column in Users_Privileges to 0 (zero).
This means that a user, by default, is not site-restricted.

2. To fix your legacy data, where this column could be null, run the SQL
query-

Update users_privileges set Site_ID = 0 where Site_ID is null

----
At the start of the new year, I will have a URL, which I will broadcast,
where you can work out the .NET version with the demo user account.
(Hopefully, we will also have the Help pages in place to provide assistance
for individual pages.) After we shake out the inevitable bugs, this will be
made generally accessible. (The only part of the system that will remain in
ASP, for at least a year, will be the dynamically generated case report
forms; in the test version, at present, the ASP page is shown within an
IFRAME embedded in a CRF "shell" ASPX page, which combines the old header
and toolbar. The two coexist nicely; eventually, however, we will replace
the generated ASP pages with generated ASPX pages, where the CRF shell page
serves as an ASP.Net Master Page. The browser-side code will still be
generated, as this is needed to provide near-instantaneous responses for
things like skip logic, without having to perform round-trips to the Web
server.)

Thanks,
Prakash

Hello Prakash and everyone,

Is there a way to do inter-form (across different forms) validation?

Thank you,

Mihai

nevermind, found it....:-)

--- In trialdb@yahoogroups.com, "Phillip Butts" <phillip.butts@...>
wrote:
>
> How do I remove the browser check so that we can use IE7?
>
>
>
> Thanks,
>
> PB
>

Good morning!

I should also mention that the ChangePassword module was developed with
localization considerations. So, as far as that piece of software is
concerned, globalization is ready to use, you just have to add the
resource files.

Mihai

--
http://www.cs.utah.edu/~mvirtosu

>>> Prakash.Nadkarni@... 07/20 6:48 AM >>>
I forgot to mention that Microsoft provides a toothcomb for checking
localization. The Visual Studio Team System, which we possess, lets you
turn
localization warnings on- it will identify every possible construct in
every
code module (such as a string literal assigned to the value of a label,
or
an error message displayed as a string constant as opposed to
consulting a
resource, or a date conversion that does not use the CultureInfo
class,
which is part of .NET) that is vulnerable to localization assumptions.
So,
while you still have to go through the process of moving every
localizable
entity into resources or a database, you will never miss anything, and
testing is less of a problem because localization errors are caught at
compile-time rather than postponed until runtime.



Prakash

   _____

From: trialdb@yahoogroups.com [mailto:trialdb@yahoogroups.com] On
Behalf Of
Prakash Nadkarni
Sent: Wednesday, July 19, 2006 8:33 AM
To: trialdb@yahoogroups.com
Subject: RE: [trialdb] Re: Double Data Entry



I should mention that I am actively at work on localizing Trialdb with
the
help of metadata, which would allow the Web interface to morph to
support
more than one language. (The Web server can sense the browser's
default
language, and most browsers allow the user to set the default
language.) We
have to eventually support a study in Colombia where no one speaks
English,
but the instruments, concerned with a clinical trial of a new drug for
leishmania tropica, also need to be looked at by researchers at Yale
who
speak little or no Spanish.



The current schema already have several tables that have a LANGUAGE_ID
column, and the idea is that form and question captions as well as
choice
set values, if stored in metadata, would support dynamic changing of
the
user interface. The static elements of the interface, such as the
error
messages and captions on buttons, etc. are being stored in resource
files -
..Net makes this task dramatically easier than anything else (though
"easy"
is a relative term because you have to go through your code with a
toothcomb, looking for English-language-specific assumptions).



Prakash

   _____

From: trialdb@yahoogroups.com [mailto:trialdb@yahoogroups.com] On
Behalf Of
mikejonathan77
Sent: Tuesday, July 18, 2006 7:19 PM
To: trialdb@yahoogroups.com
Subject: [trialdb] Re: Double Data Entry



Thanks - I lost track of this issue. The reason we were looking at DDE
was
that we have a
questionnaire with a lot of repetitive questions, and one version is
in
Spanish, which may
not be spoken by the person entering the data. These are validated
instruments with
answers between 1 and 5, and no way to "validate" the correctness of
any
choice of
response. So we were thinking this would be a case for considering
DDE.

--- In trialdb@yahoogroups <mailto:trialdb%40yahoogroups.com> .com,
Prakash
Nadkarni <Prakash.Nadkarni@...> wrote:
>
> The way we kludge (non-real-time) DDE is that we create two studies
with
an
> identical study design - one of these is named something like
"<study
name>
> DDE". After the same data is entered in both studies (maybe by
different
> people) we run a report comparing data in the two studies, patient
by
> patient, form by form, and question by question, and flag
discrepancies
that
> are then corrected in one study or the other. Repeat this until the
> discrepancy count is zero.
>
>
>
> However, see our Web site FAQ as to why the FTE invested in DDE is
better
> invested in achieving the same data quality using near-real-time
data
> audits. The preferred approach, based on random sampling, uses the
ideas
of
> the NYU Quality Control guru W. Edwards Deming (whose methods were
used
> successfully by Japanese electronics and car manufacturers to
overtake the
> US in the 1970s).
>
>
>
> Prakash
>
>
>
> _____
>
> From: trialdb@yahoogroups <mailto:trialdb%40yahoogroups.com> .com
[mailto:trialdb@yahoogroups <mailto:trialdb%40yahoogroups.com> .com]
On
Behalf Of
> mikejonathan77
> Sent: Tuesday, July 11, 2006 10:48 AM
> To: trialdb@yahoogroups <mailto:trialdb%40yahoogroups.com> .com
> Subject: [trialdb] Double Data Entry
>
>
>
> I have not been able to figure out whether TrialDB is able to handle
DDE
or
> not. I can think of
> some kludges to accomplish this, but I recall reading somewhere that
TrialDB
> has a way to
> facilitate this. Am I incorrect? Appreciate any direction someone
can
point
> me in.
>
> - Mike
>

Your last comment invites me to incite revolt against Microsoft and suggest
consideration
for moving the entire thing to Java using the Eclipse environment.  But it would
be a
monumentally monumental task, so I am mostly kidding!

--- In trialdb@yahoogroups.com, Prakash Nadkarni <Prakash.Nadkarni@...> wrote:
>
> I should mention that I am actively at work on localizing Trialdb with the
> help of metadata, which would allow the Web interface to morph to support
> more than one language. (The Web server can sense the browser's default
> language, and most browsers allow the user to set the default language.) We
> have to eventually support a study in Colombia where no one speaks English,
> but the instruments, concerned with a clinical trial of a new drug for
> leishmania tropica, also need to be looked at by researchers at Yale who
> speak little or no Spanish.
>
>
>
> The current schema already have several tables that have a LANGUAGE_ID
> column, and the idea is that form and question captions as well as choice
> set values, if stored in metadata, would support dynamic changing of the
> user interface. The static elements of the interface, such as the error
> messages and captions on buttons, etc. are being stored in resource files -
> .Net makes this task dramatically easier than anything else (though "easy"
> is a relative term because you have to go through your code with a
> toothcomb, looking for English-language-specific assumptions).
>
>
>
> Prakash
>
>   _____
>
> From: trialdb@yahoogroups.com [mailto:trialdb@yahoogroups.com] On Behalf Of
> mikejonathan77
> Sent: Tuesday, July 18, 2006 7:19 PM
> To: trialdb@yahoogroups.com
> Subject: [trialdb] Re: Double Data Entry
>
>
>
> Thanks - I lost track of this issue. The reason we were looking at DDE was
> that we have a
> questionnaire with a lot of repetitive questions, and one version is in
> Spanish, which may
> not be spoken by the person entering the data. These are validated
> instruments with
> answers between 1 and 5, and no way to "validate" the correctness of any
> choice of
> response. So we were thinking this would be a case for considering DDE.
>
> --- In trialdb@yahoogroups <mailto:trialdb%40yahoogroups.com> .com, Prakash
> Nadkarni <Prakash.Nadkarni@> wrote:
> >
> > The way we kludge (non-real-time) DDE is that we create two studies with
> an
> > identical study design - one of these is named something like "<study
> name>
> > DDE". After the same data is entered in both studies (maybe by different
> > people) we run a report comparing data in the two studies, patient by
> > patient, form by form, and question by question, and flag discrepancies
> that
> > are then corrected in one study or the other. Repeat this until the
> > discrepancy count is zero.
> >
> >
> >
> > However, see our Web site FAQ as to why the FTE invested in DDE is better
> > invested in achieving the same data quality using near-real-time data
> > audits. The preferred approach, based on random sampling, uses the ideas
> of
> > the NYU Quality Control guru W. Edwards Deming (whose methods were used
> > successfully by Japanese electronics and car manufacturers to overtake the
> > US in the 1970s).
> >
> >
> >
> > Prakash
> >
> >
> >
> > _____
> >
> > From: trialdb@yahoogroups <mailto:trialdb%40yahoogroups.com> .com
> [mailto:trialdb@yahoogroups <mailto:trialdb%40yahoogroups.com> .com] On
> Behalf Of
> > mikejonathan77
> > Sent: Tuesday, July 11, 2006 10:48 AM
> > To: trialdb@yahoogroups <mailto:trialdb%40yahoogroups.com> .com
> > Subject: [trialdb] Double Data Entry
> >
> >
> >
> > I have not been able to figure out whether TrialDB is able to handle DDE
> or
> > not. I can think of
> > some kludges to accomplish this, but I recall reading somewhere that
> TrialDB
> > has a way to
> > facilitate this. Am I incorrect? Appreciate any direction someone can
> point
> > me in.
> >
> > - Mike
> >
>

Thanks. That is pretty much what we were thinking too. This helps a lot.
Tell mihai thanks for the password change stuff. Works great in ptoduction

-----Original Message-----
From: "mikejonathan77"<mike.dean@...>
Sent: 7/18/06 8:39:32 PM
To: "trialdb@yahoogroups.com"<trialdb@yahoogroups.com>
Subject: RE: [trialdb] questions regarding HIPAA security

Matt - I have invested a lot of time into understanding HIPAA and its
regulations, and the
major issues are that passwords be changed on a regular basis, that the
systems time out
after a reasonable period of time, and that transmission is secure. We have
put our
TrialDB installation on an SSL server, which provides adequate encryption
for purposes of
HIPAA. Mihai has written a password routine that requires people to change
their
passwords, and even offers them the secret question method for maintaining
their
passwords, etc. We finally installed this earlier this summer. Finally, the
sessions already
time out.

There are a lot of people who are going overboard with HIPAA, not being
reasonable, in
my opinion. If your servers are locked up, and if you use reasonable IT
security
precautions, you should be ok.

--- In trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com> , Matt
Skelton <matt.skelton@...> wrote:
>
> On a side note, until then, we are using an overly secure network design,
> that prevents most access, but long term, it is self defeating. Works for
> now though.
>
>
>
> Matt Skelton
>
> Programmer / Analyst
>
> Univ. of Alabama at Birmingham
>
> Comprehensive Cancer Center
>
> <mailto:mskelton@...> mskelton@...
>
> _____
>
> From: trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com>
[mailto:trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com> ] On
Behalf Of
> Matt Skelton
> Sent: Monday, July 17, 2006 8:49 AM
> To: trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com>
> Subject: [BULK] RE: [trialdb] questions regarding HIPAA security
>
>
>
> For the connection string stuff. I have implemented it in the .net stuff.
> ASP does not like the standard stuff, so I have left it off until the
whole
> thing is .net/
>
>
>
> Matt Skelton
>
> Programmer / Analyst
>
> Univ. of Alabama at Birmingham
>
> Comprehensive Cancer Center
>
> <mailto:mskelton@...> mskelton@...
>
> _____
>
> From: trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com>
[mailto:trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com> ] On
Behalf Of
> Prakash Nadkarni
> Sent: Monday, July 17, 2006 8:40 AM
> To: trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com>
> Subject: RE: [trialdb] questions regarding HIPAA security
>
>
>
> IP restrictions are really implemented at the Web server OS level, and is
> not something that the TrialDB application code should be bothered about.
> Ditto for https and Verisign certificates.
>
>
>
> Encryption: We have some schema elements in place - against every user,
for
> example (ACTDBCRYPTO_KEY), as well as in EVENT_HEADER.(Digital_Signature,
> which is a hash of a message digest of the form's contents and the editing
> user's private key). The application code that will access this is waiting
> on .NET - I'd rather have my teeth pulled out without anesthesia than try
to
> do this stuff in ASP.
>
>
>
> We intend to add code that will encrypt HIPAA (PHI) fields for patient
> information.
>
>
>
> All of the encryption/decryption is best performed, as you know, in the
> middle tier, so that for PHI the database would only have encrypted
> information.
>
>
>
> Connection String encryption- I hope that you've implemented your stuff
> successfully by now.
>
>
>
> Prakash
>
>
>
>
>
> _____
>
> From: trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com>
[mailto:trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com> ] On
Behalf Of
> Matt Skelton
> Sent: Monday, July 17, 2006 9:13 AM
> To: trialdb@yahoogroups.com <mailto:trialdb%40yahoogroups.com>
> Subject: [trialdb] questions regarding HIPAA security
>
>
>
> I would like to pose a question. Our HIPAA regs and local reps are giving
> us a hard time. I would like to find out what measures, if any have been
> implemented on your ends to answer HIPAA concerns, FDA concerns, if any,
and
> any others. Obviously, we have implemented some already, but we were
> wondering what the best practice were for these tasks.
>
>
>
> Basically, I was wondering about database encryption, if any, web server
> lockdowns, IP restrictions, connection string encryption, security
> certificates, etc...
>
>
>
> We have already implemented a few, but we were wondering what on your
ends,
> were being considered overkill, what were actually being implemented,
etc...
>
>
>
> Thanks
>
>
>
> Matt Skelton
>
> Programmer / Analyst
>
> Univ. of Alabama at Birmingham
>
> Comprehensive Cancer Center
>
> <mailto:mskelton@...> mskelton@...
>

Matt - I have invested a lot of time into understanding HIPAA and its
regulations, and the
major issues are that passwords be changed on a regular basis, that the systems
time out
after a reasonable period of time, and that transmission is secure.  We have put
our
TrialDB installation on an SSL server, which provides adequate encryption for
purposes of
HIPAA.  Mihai has written a password routine that requires people to change
their
passwords, and even offers them the secret question method for maintaining their
passwords, etc.  We finally installed this earlier this summer.  Finally, the
sessions already
time out.

There are a lot of people who are going overboard with HIPAA, not being
reasonable, in
my opinion.  If your servers are locked up, and if you use reasonable IT
security
precautions, you should be ok.

--- In trialdb@yahoogroups.com, Matt Skelton <matt.skelton@...> wrote:
>
> On a side note, until then, we are using an overly secure network design,
> that prevents most access, but long term, it is self defeating. Works for
> now though.
>
>
>
> Matt Skelton
>
> Programmer / Analyst
>
> Univ. of Alabama at Birmingham
>
> Comprehensive Cancer Center
>
>  <mailto:mskelton@...> mskelton@...
>
>   _____
>
> From: trialdb@yahoogroups.com [mailto:trialdb@yahoogroups.com] On Behalf Of
> Matt Skelton
> Sent: Monday, July 17, 2006 8:49 AM
> To: trialdb@yahoogroups.com
> Subject: [BULK] RE: [trialdb] questions regarding HIPAA security
>
>
>
> For the connection string stuff. I have implemented it in the .net stuff.
> ASP does not like the standard stuff, so I have left it off until the whole
> thing is .net/
>
>
>
> Matt Skelton
>
> Programmer / Analyst
>
> Univ. of Alabama at Birmingham
>
> Comprehensive Cancer Center
>
>  <mailto:mskelton@...> mskelton@...
>
>   _____
>
> From: trialdb@yahoogroups.com [mailto:trialdb@yahoogroups.com] On Behalf Of
> Prakash Nadkarni
> Sent: Monday, July 17, 2006 8:40 AM
> To: trialdb@yahoogroups.com
> Subject: RE: [trialdb] questions regarding HIPAA security
>
>
>
> IP restrictions are really implemented at the Web server OS level, and is
> not something that the TrialDB application code should be bothered about.
> Ditto for https and Verisign certificates.
>
>
>
> Encryption: We have some schema elements in place - against every user, for
> example (ACTDBCRYPTO_KEY), as well as in EVENT_HEADER.(Digital_Signature,
> which is a hash of a message digest of the form's contents and the editing
> user's private key). The application code that will access this is waiting
> on .NET - I'd rather have my teeth pulled out without anesthesia than try to
> do this stuff in ASP.
>
>
>
> We intend to add code that will encrypt HIPAA (PHI) fields for patient
> information.
>
>
>
> All of the encryption/decryption is best performed, as you know, in the
> middle tier, so that for PHI the database would only have encrypted
> information.
>
>
>
> Connection String encryption- I hope that you've implemented your stuff
> successfully by now.
>
>
>
> Prakash
>
>
>
>
>
>   _____
>
> From: trialdb@yahoogroups.com [mailto:trialdb@yahoogroups.com] On Behalf Of
> Matt Skelton
> Sent: Monday, July 17, 2006 9:13 AM
> To: trialdb@yahoogroups.com
> Subject: [trialdb] questions regarding HIPAA security
>
>
>
> I would like to pose a question. Our HIPAA regs and local reps are giving
> us a hard time. I would like to find out what measures, if any have been
> implemented on your ends to answer HIPAA concerns, FDA concerns, if any, and
> any others. Obviously, we have implemented some already, but we were
> wondering what the best practice were for these tasks.
>
>
>
> Basically, I was wondering about database encryption, if any, web server
> lockdowns, IP restrictions, connection string encryption, security
> certificates, etc...
>
>
>
> We have already implemented a few, but we were wondering what on your ends,
> were being considered overkill, what were actually being implemented, etc...
>
>
>
> Thanks
>
>
>
> Matt Skelton
>
> Programmer / Analyst
>
> Univ. of Alabama at Birmingham
>
> Comprehensive Cancer Center
>
>  <mailto:mskelton@...> mskelton@...
>