HIPAA Violator gets jail time

For the first time, a health care provider has been found guilty of a HIPAA violation and may be subject to jail time for looking at patient records. 

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.

HIPAA Requirements, Dates and Personal Health Information

HIPAA and Time-based Data

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.

Optimal Online Screening for Patient Recruiting

An online screening questionnaire is a great way to recruit potential study participants.  If done correctly, the questionnaire or survey can ensure that most of the preliminary screening criteria are determined prior to the patient recruiting process. 

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.

5 Keys to creating good patient recruiting sites

One of the most challenging aspects of completing a clinical research study is recruiting appropriate participants.  Based on developing many patient recruting sites, we have developed our top-five list of items to do.

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