Biorepository
Data and Resources
-
Biorepository program description
Biorepository program description
Additional Info
| Field | Value |
|---|---|
| Access Contact | not yet specified, see Access Mechanism |
| Access mechanism | There will be a steering committee in charge of these pieces. As an Institutional resource, they will need to determine in what cases access is to be granted, and how (most likely they'll handle all queries, likely through the HBO). Will also be informed by the specific informed consent that governs the samples. The applicability of consent that is granted from each area is anticipated to be an issue that will have more impact than might be currently anticipated. |
| Access protocol | See "Access mechanism" |
| Attribution citation | |
| Business processes involved | |
| Collection mechanism(s) | Specified at the Study level. |
| Data Manager(s) | May be the LIMS business analyst, while this is TBD in the future, Larry Brucki is performing that role right now. |
| Data Provided By | |
| Data Steward(s) | may wind up being a group of folks led by Victoria Blanc, the Director. She already has a couple of higher-level steering committees, some subset of which might be utilized. |
| Data collection format(s) | As much as possible, we're trying to go with bar code scanning across the system, so avoiding keying to the degree possible. There are also surveys that the patients fill out. |
| Data element definitions | Not well automatically-defined, but this is something that we're working on with the mapping. |
| Data lineage / mapping from other sources | A primary source is the EMR. However, they also utilize folks who do medical abstraction folks to get information, often in places like the EMR Notes, for things that are pertinent to their research. |
| Data profile | Generally complete, since these are all people who've consented to be in a research study. This can vary on a case-by-case basis, so more analysis could be useful if warranted. |
| General guidelines for ability to access | See "Access mechanism" |
| Higher-level data models (logical and/or conceptual) | Contains data about subjects. Subject maps 1-1 to Person. A Subject may be enrolled in multiple studies (as a Participant). Demographic data is associated to Subject. Information is tracked separately around Subject independent of Sample. Information is tracked for Samples, associated with Participants. Certain detail is collected during Clinical encounters (thus Clinical data) as well as Survey data. Samples can be Aliquots (something that comes from the sample that has the same format as the sample. e.g. a smaller portion of the blood sample) or Derivatives. Then there are Assay results (relatively small, self-contained) from the Sample, that result from test(s) on the Sample. Then there can also be larger data that would come from things like DNA sequencing (generally Genomic Analysis, or Proteomic). These things can be quite large. |
| How is this data used? | Always used for specific studies. |
| Initial Creation Date | |
| Initial use cases/motivations for data collection | This probably goes down to the Study level. So obviously there are a number of possible elements here. Two mega use-cases: either collected through a study, or collected for various use cases (e.g. Michigan Genomics, trying to get up to 50K samples in future years). Folks who put together sample collections for specific studies may very well open the samples up to general use once their study completes. |
| Last Modified Date | |
| Physical Data Infrastructure | omitted |
| Physical data model, reverse-engineered | {needs link or other resource} |
| Primary Users / Customers | |
| Regulatory and other classifications | most has HIPAA, PHI but not all of it. E.g. chronic kidney disease has multiple sites that collect PHI but none of that is sent along to here, only the Participant ID goes with the other info (so it's essentially de-identified). There may be some more detail to get into here (e.g. collection by Subject vs. Participant; other masking of identity by PI) |
| Retention schedule | Essentially never going to be purged. |
| Roles / persons involved in collection | Generally: Clinical Data Capture, Clinical Data Manager, Laboratory Technician, then also PI. |
| Schedule for known changes to Access Conditions | Should be consistent. |
| Standards utilized | The central biorepository is trying to standardize processes for collecting samples as much as possible. This will be an ongoing evolution. There are many different ways these things happen now, and making them common to the degree possible will be part of the economies of scale savings that should result. |
| Storage Format | LabVantage DB, which is an Oracle DB. |
| Subject Matter Expert(s) | will come from each of the individual bio-bank's. |
| Time Frame Data Collected For | |
| Transformation details | none |
| URL | |
| Update Schedule |