1. Easy to read.  It is critical that all medical jargon be very limited in the site.  While it is fine to include the terminology, make sure that it is defined clearly.

2. Describe your Team.  There is so much junk on the web today and much of it is misleading or designed to lure the unsuspecting.  Make sure that your team and institution are clearly described in your site.

3. Define your Inclusion and Exclusion Criteria Clearly.  If prospects attempt to enroll who are not qualified, it wastes recruting and assessment time.  Make sure that the criteria to participate are clearly outlined so the participant will realize the he or she isn’t eligible so you don’t have to.

4. Make the Participant Responsibilities Clear.  One of the most frustruating things is to screen a patient, complete the consent and then have them drop out because the requirements weren’t well understood.  Make sure that they are clearly outlined in the site and it will save everyone headaches.

5. Clear Call to Action.  Make sure that it is obvious what you want the propsective participant to do.  You might consider having the ‘I want to participate’ link clearly defined either on the header or the primary menu of the site

The online survey will ask about the age, gender and screen for the clear eliminators and also get some background in the patient’s condition to help make sure that he or she fits in your study.

Take them all of the way through — One element that we have learned after developing a significant number of these questionnaires, is that the survey should make the propective participant feel as though he or she is being considered even if you determine at the outset that there is not a fit.

For example, say you are doing a screening process where your study is looking for people with 10-20 pack-years of smoking (A pack-year is a person smoking one pack of cigarettes a day for a year).  Your trial is one where there is promising new treatment with people who have COPD.  Your screening process will likely determine the number of pack years, and then ask about exclusion (age, other diseases) and the nature of disease that the prospect has.

If your screen terminates the session with a message that the patient isn’t qualified as soon as the number of pack-years is determined, you will likely create some unwanted behavior.  This is assuming that your participant is motivated to participate either because of compensation or a promising treatment.
If you terminate them too early, they may try to re-enroll and adjust the answer to the eleminating question so that they qualify.  Or they may call or email a recruiter to understand why they aren’t qualified.  Both of those can have negative impact, the first being unqualified people participating in the study, and the second increasing the recruting time and cost for your study.

Once complete, thank them and let them know they will be considered — If you reject them in the session, many may want to call and argue the point.  It is best if you leave it open.  If you want to give those who do qualify additional feedback, that is fine, but don’t let people know immediately that they do not.

At the risk of glossing over details, it is fair to say that given current HIPAA regulatory restrictions and criminal penalties surrounding the release of personal health information (PHI), Dates and DateTime fields within a database need to be hidden from non-PHI privileged users. The rationale behind HIPAA date and datetime restrictions are that if someone knows a date and very little else that it is relatively easy to pinpoint the identity of a patient within your medical study. Dates-of-birth are too obviously useful pieces of information. Anyone calling into a health clinic these days is asked their name and DOB (and little else). If that person passes that simple telephone authentication exercise they have access all kinds of personal health information to which they should have no access whatsoever. Rightfully, HIPAA requirements cast dates of birth strictly into the PHI category.  For slightly more subtle reasons, HIPAA also places most other time-related data into this category as well.  Even an appointment date at a clinic with a little nefarious detective work can lead to personal health information.

So, if access to dates is PHI, how do you enable analysis of time-related medical information when that data cannot be seen by members of a study team who are chartered with statistical analysis?  Do you simply open patient dates up to a wider group of study team members?  By doing so what legal risks are you then exposing your study team, your institution and yourself to over the entire duration of the study?  HIPAA penalties are significant, and not just for institutions; individuals can be criminally prosecuted under these statutes as well.

How can statistical analysis be done if access to dates is so narrowly restricted?

Let’s first look at the what is important about dates in a medical/clinical context.   The fact that the onset of a symptom or the date of a baseline examination occurs on a particular date is not as significant one might, at first, believe.  What is often more significant is the duration between two dates, the distance in time between entry into an ER and onset of secondary symptoms; the age of a patient at onset of a particular illness and not that patient’s birth date. The medical significance of a thirty-two-year-old contracting breast cancer is higher than for an eighty-six-year-old, but their actual dates-of-birth are relatively insignificant.  It is the age of the patient at onset that can be significant to analysis.

What impact does this have on the kinds of data stored within a database?  Or more particularly – what can the presentation layer (EDC forms, reports, data extracts and the like) do to make access to time-related PHI information appropriate for subsets of users within a study team?

The first step is to identify PHI-related time-based information within your study’s database.  One obvious way to do this would be to cast a wide net over all fields defined within your database with the data type of DATE or DATETIME, but that may not gather a long enough list of PHI candidates as sometimes dates and date time values are stored within character storage fields that would be seen by the system a simply data type CHARACTER or TEXT fields.  So the ability to automatically assess PHI risk by also looking at the actual field names within the database’s data dictionary or like-minded meta data repository (see above screenshot).  Words such as ‘date’, ‘time’, or ‘DOB’ and be able to mark them automatically as PHI data.  Having a capability built into the layering of the application development mechanisms during the creation and maintenance of your study’s database that enables the easy setting of such institutional standards makes this otherwise onerous process nearly automatic is of obvious benefit.  Unforturnately, of-the-shelf systems, built for general database storage and maintenance do not offer such capabilities.

The next step is to have mechanisms built into the application toolset maintaining your study’s data that restrict access only to pre-authorized users.  From EDC forms to data extract mechanisms, to graphic reports – all outwardly facing interfaces to the system must be able to shield PHI from prying eyes.

The final step is to be able to represent PHI in a non-PHI fashion to users that do not have PHI privileges.  One conceptually simple way to do this is to define calculated fields  that stand “next” to your PHI time-related fields that can distill that which is analytically relevant to the study, leaving PHI data hidden, encapsulated beneath and within the calculation. These calculated fields must be flexible enough to enable arbitrarily complex mathematical calculation, database lookup, traversal and analysis during the calculation, and enable customized presentation of the calculation to meet a wide variety of potential study requirements.  Finally, these fields must be defined and maintained in a central data dictionary so that all elements responsible for data access, maintenance and presentation comply with institutional/study-wide standards.

-Bill Hedge, QuesGen Systems, Inc.

Click here to read the article. The short version is that a doctor who was terminated from UCLA spent time looking at patient records prior to his departure.  His intentions may have been completely reasonable, but if he had access and was looking at the data for personal interest and not for the execution of the study, then his is in the wrong.  If his defense is that he didn’t think that he was doing anything wrong, he may learn a difficult lesson.  Not knowing it is wrong is not a valid reason and would leave the institution open for more scrutiny.

The upshot is that the courts are taking HIPAA violations seriously, and these types of things are always a good reminder to make sure that your systems are as secure as possible and the members of your team are well trained and aware.

Random Date Shifting - One approach is to use an automatic date shifting function in the extract.  They way that these work is that an offset value is generated based on a participant key (for example, the Patient Identifier).  RedCap has implemented this, and will allow a number from -1 to -364 to be generated and each participant’s date will be modified by that amount of time.

Pros

• This is pretty easy to implement, if your package supports it.  Just indicated that dates should be shifted at extract time
• Since all dates are shifted by the same number of days, the relative durations all stay intact.

Cons

• Since all dates are shifted by up to a year, any changes that may have occured during the study (for example, changes to the screening process or adjustments to the protocol), those all become lost.
• If there is any benefit to comparing earlier participants to later, that can’t be done with this approach.
• Data still contains dates, and individuals that receive it may feel that PHI has been shared.  Documentation about how the dates has been obscured must be included.

For many applications, this is an easy-to-implement process and can work well.


Generalizing Dates - Most Institutions Review Boards (IRBs) will accept that a month and year do not constitute enough specificity for a date to be consider PHI.


Pros

• The event period is not lost
• It is obvious that the information is not PHI

Cons

• In most cases, this does not provide enough information about when something occured.  If a follow-up is done seven days, 14 days and 21 days after injury, they could all occur in the same period.
• It may require additional variables or programming to convert the raw data into Month/Year periods.

In some situations, this can be worthwhile.  For example, a DOB could be presented as 05/1970 and that would be adequate for most uses.

Convert Dates to Durations – Rather than store specific dates, calculate durations and provide those.  For example, rather than have HospitalDischargeDate, you could provide HospitalStayDays that would be calculated from Admit and Discharge date.


Pros

• Clearly not PHI, yet preserves the integrity.
• May be easier in doing data analysis since most inquires are looking at durations rather than specific dates.
• Could be combined with a Generalized Date approach (e.g. MonthYear of Injury, TransportDurationHours, ICUDurationDays.

Cons

• Could be a significant amount of work to implement, if the data management application does not provide this automatically.

The QuesGen data management platform supports automatic duration calculations.  Users have requested date shifting functionality and we are considering implementing it.  If you have an opinion about what you would like, please send us an email at support@quesgen.com or leave a comment here.

Our old login look was functional and secure. However, it didn’t have a very modern look.  Our new login screen provides the ability for users to get help when logging in, and also looks a little more current.

Our old login look was functional and secure.

However, it didn’t have a very modern look. Our new login screen provides the ability for users to get help when logging in, and also looks a little more current.

We have also provided some additional navigation options. Since we’ve started, we have provided the left-hand menu as depicted below. It is functional and gets the job done.

Now, users have the option of moving the menus to the top of the screen and seeing their menu options in a drop-down format. The new look also provides for recently selected items and favorites to be available on a left hand pop-out menu. This provides for much more usable screen area. Users can opt for the new menu option or the “classic” look to suit their preference.

In any case, we welcome your feedback and ideas.

“The estimated lifetime risk of developing diabetesfor individuals born in 2000 is 32.8% for males and 38.5% forfemales. Females have higher residual lifetime risks at allages. The highest estimated lifetime risk for diabetes is amongHispanics (males, 45.4% and females, 52.5%). Individuals diagnosedas having diabetes have large reductions in life expectancy.For example, we estimate that if an individual is diagnosedat age 40 years, men will lose 11.6 life-years and 18.6 quality-adjustedlife-years and women will lose 14.3 life-years and 22.0 quality-adjustedlife-years.”

The source for this is JAMA.  Click here for the Citation.

If you have childred, or if you eat food, you should check out this YouTube video on how we metabolize sugar.  Very interesting presentation from a prominent UCSF investigator.

Dates can be entered in any format, and will be converted to the desired type. For example, you can enter 6/5 15:00 and the system will convert it to 05-Jun-2011 03:00 pm. Notice that if you don’t enter the year, it will default to the current year.

To select the way that you would like to see your date, open up your profile (click on My Profile in the upper right), and near the bottom, you will be able to select.