A High-Level Overview of the Process

CRDW Data Request Process

Click to enlarge

To support the use of Banner clinical data for research purposes, a protocol entitled “Clinical Research Data Warehouse and Associated Honest Broker Processes” has been approved by the Banner IRB. The protocol details how Honest Broker staff, who are neutral intermediaries between the researcher and the electronic health record data, will take in requests for data, assess the feasibility of the requests and ultimately fulfill the requests. Requests are initiated using the research intake form.

For trainee (students, residents, fellows) requests, we provide only a list of medical record numbers in the interest of serving as many of the Banner – University Medical Center Phoenix research community members as possible.

Help and Questions

The CRDW is an extract of clinical data from Banner Enterprise Data Warehouse stored in a structured and validated database. It is anticipated that additional data sources will be added in the future (e.g. Cancer Registry).

The initial set of data from Banner Enterprise Data Warehouse includes:

  • Standard vocabularies and mappings (ICD, CPT, RxNorm, NDC, etc.).
  • Demographics.
  • Encounters.
  • Medications.
  • Diagnoses.
  • Procedures.
  • Measurements (labs, vitals, etc.).
  1. Requests that are preparatory for research – This is sometimes described as “cohort identification” and is the process by which an investigator assesses the number of subjects in the CRDW meeting given criteria to determine whether the planned research is feasible.
     
  2. Requests for de-identified data – An investigator may request de-identified data for a cohort, which may not include any protected health information (see Table 1 of this protocol for a complete list). Since the data set is de-identified, it will not be possible to re-identify the data, and therefore, it will not be possible to receive data updates or supplement the data set with additional data elements at a later date.
     
  3. Requests for coded data – This is similar to number 2, but in this case, the investigator may request the data for a cohort in a coded, rather than a de-identified, manner. The data request will not include any protected health information and will remain with the Honest Broker Staff. The investigator may not request and will not ever receive re-identification of the data set. Because the data are coded with an anonymous ID, updated data could be provided on an ongoing basis.
     
  4. Requests for a limited data set – This is similar to number 3, but may include specific dates, date ranges and zip codes as defined by HIPAA regulations (see definitions).The data request could be a snapshot of what is available at the time of request or updated data could be provided on an ongoing basis. The investigator may not request and will not ever receive additional subject identifiers.
     
  5. Subject identification for possible participation in a specific research project – In this purpose, individual patient contact information is provided to the investigator, such that subjects can be approached for their interest in participating in a clinical or translational research project.
     
  6. Data requests for an investigator defined identified cohort – The investigator defines a group of identified human subjects for which a specific set of data is requested. The identified cohort could be individuals that have provided consent in the context of an approved IRB protocol, individuals identified through one of the above processes or individuals identified through the investigator’s clinical activities. The data request could be a snapshot of what is available at the time of request or updated data could be provided on an ongoing basis.

Data elements available for each data request type are summarized in the table below:

CRDW Data Requests Table

De-Identification

Removal of medical record number and of patient identifiers will be conducted by following the HIPAA “safe harbor” method as defined by the HIPAA Privacy Rule, (CFR 164.415 (b) (2). This method results in removing the following data elements:

  • Names.
  • All geographic subdivisions smaller than a state, including street address, city, county, precinct, ZIP Code, and their equivalent geographical codes, except for the initial three digits of a ZIP Code if, according to the current publicly available data from the Bureau of the Census: 
    • The geographic unit formed by combining all ZIP Codes with the same three initial digits contains more than 20,000 people.
    • The initial three digits of a ZIP Code for all such geographic units containing 20,000 or fewer people are changed to 000.
  • All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date and date of death. In addition, all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older. 
  • Telephone numbers.
  • Facsimile numbers. 
  • Electronic mail addresses.
  • Social security numbers.
  • Medical record numbers.
  • Health plan beneficiary numbers.
  • Account numbers.
  • Certificate/license numbers.
  • Vehicle identifiers and serial numbers, including license plate numbers.
  • Device identifiers and serial numbers.
  • Web universal resource locators (URLs).
  • Internet protocol (IP) address numbers.
  • Biometric identifiers, including fingerprints and voiceprints.
  • Full-face photographic images and any comparable images.
  • Any other unique identifying number, characteristic, or code, unless otherwise permitted by the Privacy Rule for re-identification.

In order to de-identify dates, the CRDW staff will shift all dates from the EMR 1–365 days into the past. The shift will be different across records, but constant within the records of each patient. This will allow temporal analyses such as the development of adverse effects after a drug.

Re-Identification

The HIPAA Privacy Rule (CFR 164.514 (c) allows for the assignment of a code — referenced as anonymous ID — or other means of record identification to allow information de-identified under this section to be re-identified by the covered entity, provided that:

  • Derivation – The code or other means of record identification is not derived from or related to information about the individual and is not otherwise capable of being translated so as to identify the individual.
  • Security – The covered entity does not use or disclose the code or other means of record identification for any other purpose and does not disclose the mechanism for re-identification.

Faculty

This is highly dependent on the scope of the request. Upon receipt of the clinical research data request form, Honest Broker staff will provide an estimate as part of the feasibility review. On average, the process generally takes four to eight weeks — until the data is extracted to the investigator’s satisfaction. Often, there are other steps in the process — such as contracting — which can impact the overall time; we ask that you submit your request as early as possible.

Residents and Fellows

This is highly dependent on the length of the trainees’ request queue. The process generally takes a shorter amount of time than a detailed data request, since only a list of MRNs is extracted. Often, there are other steps in the process — such as contracting — which can impact the overall time; we ask that you submit your request as early as possible.

Properly securing the data is of the utmost importance. Please contact the University of Arizona (UA) HIPAA Privacy Program for assistance in coordinating with your departmental IT staff to ensure that the data is properly secured. Additional information is available through the HIPAA Privacy Program.

There will need to be a signed Data Sharing Agreement (DSA) between Banner and the University of Arizona. Banner is working with UA to make this a Master Agreement with each project being an addendum, but until this is complete, a DSA will need to be executed for each request. The turnaround time for the DSA alone is estimated at three weeks.

For status updates, please contact us and include the PI name and project title.