Idea to Paper at Duke

Mon, 31 Aug 2026 00:00:00 +0000

A working guide for students, residents, and anyone else starting human subjects research at Duke. Written mainly for retrospective work, since that is where most first projects start. Departments handle some of this differently, so confirm the details with your division’s research office.

Step 0. Finish CITI and RCR now

You cannot be listed on a protocol or submit in iRIS until your CITI human subjects modules and RCR are complete. The DUHS IRB keeps the current requirements on its Training & Resources page, and Duke’s required training policy covers the rest. Add the two DOCR modules on IRB overview and PI responsibilities. Do this before you have a project. It is the only prerequisite you can clear while waiting on everything else, and an unfinished module holds up the whole team’s amendment.

Step 1. Get IRB coverage

Find a faculty PI first. Only regular-rank faculty can hold PI or co-PI on a Duke Health IRB protocol. Students, residents, and fellows go on as key study personnel. A department chair can petition the IRB Executive Director for an exception.

Ask what already exists. Umbrella and registry protocols are common at Duke and almost never advertised to trainees. Amending one takes days to a few weeks. A new protocol takes weeks to months. Ask your division before you draft anything.

If you need a new protocol:

Pick the IRB. Duke Health IRB for anything involving Duke Health patients, records, staff, or facilities. Campus IRB for non-health human subjects work. Both run on iRIS. If you are genuinely unsure which applies, Duke publishes guidance on selecting the appropriate IRB.
Pick the application type. Regular Study Application if you are unsure, since the IRB decides expedited versus full board itself. Application for Exemption if it plainly qualifies. External IRB application for multi-site work with another IRB of record.
Ask for the waivers explicitly. Retrospective chart review needs a waiver of consent and a waiver of HIPAA authorization, each with written justification. Omitting them is the most common reason a chart review comes back for revision.
Write it wide. Use the broadest population, date range, and variable list you can defend against the aims you state. Every follow-on question then becomes an amendment instead of a new submission. This is the single highest-leverage decision in the whole process.
Include the data plan. The Duke Research Data Lifecycle (DRDL) plan says where data live, who holds them, and what happens at closure. It is required for every DUHS IRB submission.

If you need counts before approval, file a Review Preparatory to Research. You can look at identifiable data under it to assess feasibility. You cannot record anything for the study.

Read the letter you get back. A Declaration of Exemption generally lets you begin. An approval notice may still require separate institutional sign-off before any activity involving participants.

Step 2. Add your people

Key study personnel status is what makes someone real to every other Duke system. Until a person is KSP on the approved protocol, they cannot be added to your REDCap project, granted study data access, or legitimately review a chart for you.

Personnel changes are amendments, so batch them. Adding six people once costs far less time than adding one person six times.
Add anyone plausibly involved in the next year, including the person who will build your database.
Everyone needs their own CITI, RCR, and LMS modules finished first. Duke Ortho’s research onboarding page is the clearest public checklist of what a new person actually has to clear.
External collaborators, adjunct faculty, undergraduates, and volunteers need a separate designation and often an agreement. Start those first, since they take longest.
Add a research coordinator even if they will do no work. It gives you someone with system access and standing when something breaks.

A student who joins in June, finishes CITI in July, and gets added by amendment in August has lost the summer. Work backward from when you want people abstracting.

Step 3. Stand up REDCap under the protocol

Build the instrument backward from the table you intend to publish. Every field should have a destination in an analysis, and every value should be coded rather than free text.

Development first, then production. Move the project to production before any live data are entered. Duke’s instance lives at redcap.duke.edu; the DOCR REDCap policies govern secure usage and user roles.
Match the protocol exactly. IRB number, PI, and personnel list. Divergence between the two is what audits find.
Decide who builds it. Do it yourself for a single-form chart review with roughly 60 fields or fewer. Use the DOCR data team for longitudinal designs, randomization, branching survey logic, eConsent, or external data feeds. DOCR work runs through the service center, which means an estimate and a fund code.
Line up funding early. A fund code is required for DOCR build work and for PACE access. Usual sources are the PI’s grant, division or department research funds, CTSI vouchers, and medical student research awards.
Write the data dictionary as you go. Field notes, validation ranges, and coded value labels are what let someone else reproduce the dataset.

Whoever builds the project has to be key study personnel before they open it.

Step 4. Build the data

Cohort identification and abstraction are separate problems. Validate them separately.

Identify the cohort two ways and reconcile the difference. SlicerDicer, the self-service reporting tool inside Maestro Care, gives population counts and needs either an approved protocol or an approved Review Preparatory to Research, plus the nonlicensed clinical research coordinator security template. DEDUCE handles self-service queries against the Duke data warehouse, including uploading a patient list or searching note text — something SlicerDicer cannot do. Both are catalogued under DiscoverData@Duke and the School of Medicine Data Services Catalog, which is the fastest way to work out which resource fits your question. Where the two disagree, your inclusion definition has a hole in it.
Request accounts early. DEDUCE goes through ServiceNow plus its LMS training. PACE, the Protected Analytics Computing Environment, requires an approved study, a fund code, and PACE training before the intake form, then runs over Citrix. You must be key study personnel on a study with approved or exempt status, and you will need a CoreResearch@Duke service request ID for billing. The PACE and DEDUCE portals themselves (pace.ori.duke.edu and deduce.duhs.duke.edu) resolve only from the Duke network or VPN, so open them from a Duke connection.
Keep unconsented PHI in PACE. Moving a de-identified extract out of the enclave requires an Honest Broker transfer request. Plan that into the timeline. Your statistician may have no enclave access at all; the BERD Methods Core can advise before that becomes a problem.
Double abstract a sample. Two abstractors on the first twenty charts, a kappa, and a written rule for adjudicating disagreements. It costs a day and it is the difference between a defensible methods paragraph and a reviewer question you cannot answer.
Log deviations as they happen. Charts excluded and why, definitions that shifted, fields that turned out unusable. This becomes your flow diagram and half your limitations section.

Step 5. Analyze, write, submit

Lock the analysis plan before you look at the outcome.
Write to the reporting guideline from the first draft. STROBE for observational work, CARE for case reports, PRISMA for systematic reviews, TRIPOD for prediction models. The EQUATOR Network indexes the rest. Many journals want the completed checklist at submission.
Settle authorship early, using the ICMJE authorship criteria, including order. Five minutes in month one, unrecoverable in month nine.
Plan the journal cascade before you write. A target, two realistic fallbacks, and a floor, with format requirements checked in advance.
Keep the protocol alive. File continuing review on schedule and amend for new aims or new personnel. A lapsed protocol can invalidate analyses run after the lapse, which is easy to trigger when a reviewer asks for an additional analysis during revisions.
Send the next question back through an amendment. That is the payoff for writing the protocol wide in step 1.

Four things that save the most time

Finish CITI and RCR before you have a project.
Ask your division what protocols already exist before drafting a new one.
Over-add personnel on the first amendment.
Identify a fund code before DOCR or PACE asks for one.

Where to go for each system

Training

CITI Program and RCR for DUHS IRB study personnel
DUHS IRB Training & Resources and Duke’s required training policy

IRB

Duke Health IRB — Getting Started, Researchers, iRIS
Campus IRB for non-health human subjects work
Selecting the appropriate IRB if you are unsure which one you need
Duke Research Data Lifecycle (DRDL) plan guidance

Data capture

REDCap at Duke and the instance itself
DOCR services and support and DOCR policies and procedures

Finding and holding the data

Maestro Care for Research — where SlicerDicer lives
DiscoverData@Duke and the Data Services Catalog — how to choose between DEDUCE, SlicerDicer, and the rest
PACE / School of Medicine Research Enclave and Honest Broker transfer agents
The PACE and DEDUCE portals (pace.ori.duke.edu, deduce.duhs.duke.edu) are reachable only from the Duke network or VPN

Analysis and writing

BERD Methods Core and CTSI consults
EQUATOR Network — STROBE, CARE, PRISMA, TRIPOD
ICMJE authorship criteria

Department-level write-ups

Duke Orthopaedics publishes the most detailed public account of the DEDUCE, PACE, and key-study-personnel mechanics — useful whatever your department:

Clinical research FAQ, research onboarding, and orthopaedic data resources

Links verified August 2026. Duke reorganizes these pages regularly; if one has moved, search from myResearchPath.

Medical Education on Dominic Tanzillo