Two boards, one project — when a hospital or employer reviews alongside Aspen, and which reads first

Where the organisation hosting your work runs a review board of its own, Aspen’s guidance sets the order plainly: that approval is ordinarily sought before the application reaches Aspen. The complications begin when the site has something other than a board, or wants a letter from Aspen before it will read anything at all.

Charlotte Devereux, MSN, RN · filed 2026-08-23

In short. Where your site runs its own IRB, Aspen’s handbook has you seek that approval first and file it with your application. Establishing whether one exists is your job. If the site insists on Aspen first, ask the IRB office.

Does your site actually have a board?

Fewer places do than people assume, and more places have something board-shaped than people expect. A large hospital system usually operates a full IRB. A community hospital may instead run a nursing research council, an evidence-based practice committee, or a research review that sits inside the quality office. A school district, a clinic group, a care home or an employer may have no such structure at all, and grant or refuse access purely through a manager with authority.

Aspen’s handbook puts the burden of finding out squarely on the applicant: work with your faculty chair to determine which approvals are required, and it is your responsibility to establish whether there is IRB oversight at your project site. That sentence is worth taking literally. Ask the site, in writing, three questions: does an IRB or research committee review projects like this; if so, what does it need from an outside applicant; and who signs the permission letter if it does not review at all.

Note also what the site letter is not. Aspen’s handbook is explicit that the permission letter submitted with your application is a separate document from any immersion or placement agreement signed earlier — different purpose, different signature, different reader. Our piece on the site permission letter covers what it has to name.

Which board reads first?

Aspen’s default is the site first: where the entity hosting your project has its own IRB, you will typically seek its approval before submitting to Aspen. There is a practical reason as well as a policy one. An outside board can attach conditions — a different consent template, a restriction on what data leaves, an extra confidentiality undertaking, a limit on recruitment — and every one of those changes the documents Aspen will read. Filing at Aspen first risks approval of a version that the site then modifies, which means going back with a change request before you have started.

The awkward case is the deadlock: the organisation says it will not review until it sees something from the university, while the university reviews once the site has approved. Aspen’s handbook anticipates that exactly, and the answer is not to improvise — where the organisation requires a conditional approval from Aspen before it will review, the handbook directs you to contact the IRB office for guidance, copying your faculty chair. Ask early, because a deadlock discovered at submission is a deadlock that has already cost a pass.

Four site situations, and the order they imply
What the site has	Order	What your Aspen file carries
A full IRB of its own	Site first, ordinarily	Its approval or determination letter, plus the permission letter and any conditions it imposed
A research or nursing council, not an IRB	Council first — it is a gate even where it is not a board	Its written sign-off, and a clear description of what it reviewed
No review structure, access granted by a manager	Permission first, then Aspen	The signed permission letter naming the site, the activities and the data
A site insisting on university approval first	Ask before assuming	Whatever the IRB office advises, and a note in the application of how the sequence was resolved

Is that duplicate review — and could one board cover both?

Sometimes, and occasionally yes. Federal rules on cooperative projects — ones involving more than one institution — require reliance on a single IRB for the portion carried out in the United States, but that mandate attaches to work a federal agency conducts or funds. Most capstone and doctoral projects are neither, so it does not reach them. What does reach them is the neighbouring provision: institutions outside that requirement may enter a joint review arrangement, rely on another institution’s board, or make similar arrangements to avoid duplicated effort. Structures such as SMART IRB exist to make exactly that kind of reliance workable without negotiating a fresh agreement for every project.

In practice, reliance is decided by the institutions, not by you. A hospital may be unwilling to cede review of work happening on its wards; a university may be unwilling to accept an outside determination for a project it is accountable for. Neither position is unreasonable, and neither is yours to settle. Ask whether reliance is possible; plan for two reviews if the answer is no or slow in coming.

How can a site require review without being “engaged” in the research?

This is the distinction that confuses most applicants, and understanding it saves arguments. Federal engagement guidance describes institutions as generally not engaged where their involvement amounts to permitting use of their facilities for work carried out by investigators from elsewhere — the guidance offers a school allowing an outside researcher to distribute a survey, or a business allowing recruitment on its premises. Institutions releasing identifiable information to investigators at another institution are also generally treated as not engaged — while the guidance notes in the same breath that the releasing institution may have its own requirements to satisfy first.

So “not engaged” is a statement about federal assurance obligations, not a statement that the site has no say. A hospital that is not engaged may still, entirely properly, require its research council to read your protocol, insist on its own consent template, demand a data-use agreement before a single record leaves, route you through its privacy office, or refuse access altogether. Those are conditions of entry rather than regulatory review, and they bind you just as firmly. What changes is who has to hold a federal assurance — which is the institutions’ problem, not yours.

What each board wants that the other does not

The overlap is large but not complete, and the gaps are where files get held up:

Aspen wants its own application, the approved plan behind it, consent built to its template where consent applies, training certificates, the permission letter, HIPAA authorisation where medical records feature, and instrument permissions where an instrument is adapted.
A hospital board or council often wants its own submission format, evidence of local sponsorship — frequently a named clinician or manager who takes responsibility on site — onboarding or credentialing for anyone touching patients or records, its own consent and privacy wording, and a description of how findings will be reported back to the organisation.
Both want the same protocol. Not two protocols with the same title, and not the same protocol at two different versions.

That last point is the one that trips otherwise careful files. Where one board asks for a change, the other has to be told. Aspen’s change-request process requires approval before any alteration to an approved project takes effect — instrument, consent, location or recruitment method alike — and a modification demanded by a hospital committee is exactly such an alteration. Keep one version number across both files, and let every document in each carry it.

Running two reviews without losing the thread

Ask the site’s question first. Before drafting anything, establish what structure exists, what it needs, and who signs. Every other decision hangs off the answer.
Draft to the stricter standard. Where the templates differ, build the document that satisfies both readers rather than the one that satisfies the first reader.
Stamp everything to one version. A single protocol version, carried in the footer of every document in both submissions.
Carry conditions across. Anything a board attaches to its approval becomes text in the other board’s file — not a private understanding.
Report to both. Deviations, unanticipated problems and amendments go to whichever bodies approved the work, on each one’s form. Aspen’s events form carries its own three tests: the event was unexpected, it connects to taking part, and it leaves people or others exposed to more risk.
Keep the letters. Both approvals, both sets of conditions, filed where they can be produced on request.

The sequence in full, from the first read to the board’s determination, is set out at how it works; the route by stage in our step-by-step piece; and the practical arithmetic of it all in gates and passes.

What to do next

Write the site’s question today, even if the protocol is nowhere near ready: does anything at this organisation review projects like mine, and who signs if not? That answer sets the order everything else follows — and it is the one piece of the route that cannot be recovered later.

Send us the file and the name of the organisation. We will read both files the way each board will, and write the findings first.

Request the free application review

The whole IRB process can then be ours to carry — the determination, the documents, the submission and every reply — while the project, its data and its findings stay yours and each decision stays with the board that makes it. More in the questions answered first.