Requesting Clinical Data for Research

Every request goes through a governance review to confirm compliance with human subjects research regulations and URochester Medicine policy, then moves to ISD’s EDA Research team for data extraction. The steps below describe what you do and what happens on our side.

Step 1. Plan your data needs early, before IRB submission

What you do: Define your study population with explicit inclusion and exclusion criteria, including the study date range and any restrictions on age, facility, or clinical characteristics. List the domains of data your study needs, such as demographics, encounters, diagnoses, procedures, medications, laboratory results, vital signs, etc. Decide whether you need identifiable data, a limited data set, or de-identified data; this affects IRB review, and identifiers cannot be added to a de-identified or limited data set after release. Write all of this into your protocol: our governance review checks every data request against the IRB-approved protocol, and we cannot provide data that falls outside what the protocol describes until an amendment is approved.

How we help: Informatics consultation can help you identify which eRecord data elements are available for your research question.

Step 2. Obtain the required approvals

• IRB approval. The study must be active and approved in Click IRB, and the person submitting the request must be listed as a study team member.
• Preparatory to research. Submit Form 25.3 if any PHI is needed.
• Sharing data outside the University. Data use and data transfer agreements are reviewed by the Office of Research and Project Administration (ORPA). The PI is responsible for having agreements in place before data leaves the institution.

Step 3. Submit a service request in REDCap

Your REDCap request should include:

• The IRB-approved protocol and approval letter
• Population inclusion and exclusion criteria, with codes where known (e.g., ICD-10-CM, CPT, LOINC) and the date range
• Each data element and its time window
• The level of identifiability required, consistent with your protocol
• If you provide a patient list, written confirmation that it contains only study-eligible patients

Step 4: Governance Review and Request Summary

What happens: A dedicated clinical research informatician is assigned to your request for its full lifecycle, and you receive a unique 4-digit request number. The informatician verifies IRB approval and your study team membership, confirms that the requested population and variables align with the protocol, and prepares a Request Summary that translates your request into discrete eRecord data elements. The summary may take several rounds of questions and revisions. If regulatory issues arise, a protocol amendment may be recommended.

What you do: Review the Request Summary carefully; it is the specification used to build your dataset. Include your request number in all emails and use Reply All. Respond promptly, as requests without a response within a reasonable timeframe are closed due to inactivity. Emails containing PHI are permitted between URMC domain accounts when necessary for discussion.

Step 5. Data extraction

EDA Research developers build the query from the final Request Summary, drawing on the URMC OMOP Database or Epic databases as appropriate.

Step 6. Review before release

Extracted files return to CTSI, where the informatician confirms they align with the Request Summary. If your protocol specifies a limited data set or de-identified data, the Honest Broker process applies (see the R3 Data Service Governance Review Policy).

Step 7. Data delivery

Files are placed in a request-specific URMC Box folder with read-only access for the requester, and you receive an email with a secure link. Files are delivered in Excel, CSV, or text format, depending on volume. For large cohorts or datasets containing PHI, the informatician may recommend SERDA; with the PI’s approval, files are delivered to the study’s SERDA project share.

Step 8. Review your data within 20 business days

Evaluate the dataset and report any issues within 20 business days of delivery. After that, the request is considered fulfilled and closed, and revisions require a new request. Data are delivered as extracted from clinical systems; cleaning, transformation, and analysis are the study team’s responsibility.

Example: Anatomy of a clear data request

Less clear: “Diabetic patients and their labs.”

Clearer: “Patients with at least two outpatient visits with a type 2 diabetes diagnosis (ICD-10-CM E11.*) at URochester Medicine facilities between 1/1/2020 and 12/31/2024, aged 18 or older at the first qualifying visit (index date). Exclude patients with any diagnosis of type 1 diabetes (E10.*). For each patient: date of birth, sex, race, ethnicity; all hemoglobin A1c results (LOINC 4548-4) with result dates from 1/1/2020 to 12/31/2024; outpatient metformin prescriptions with order dates.”

Why it works: the population, code sets, index date, time windows, and each variable are stated explicitly so that the Request Summary can be finalized in fewer rounds.

Avoiding Common Delays

• Request exceeds the protocol. Compare your request to the approved protocol before submitting; missing variables require an amendment.
• Requester not on the study. Make sure you are listed as a study team member in Click IRB.
• Ambiguous definitions. Spell out acronyms and define terms such as “active patient” or “index visit.”
• Slow responses. Unanswered Request Summary questions stall the request and can lead to closure.
• Deciding identifiability late. Identifiers cannot be added to a de-identified dataset or limited data set after release; that requires a new request.
• Missing the review window. Issues raised after 20 business days require a new request.