Florence eISF Alternatives: Connecting the Site File to the Study Record

Florence alternatives are chosen on one question: whether a research team needs a better site file or one fewer system. Florence eBinders is an established electronic Investigator Site File, and Florence describes its intended use precisely. The published eBinders FAQ states the product “has been developed based on best practices in collaboration with leading research sites for the specific intended use of creating and maintaining documents and workflows.” Documents and workflows are the stated scope. Everything a study team holds beyond documents and workflows sits somewhere else.

That boundary decides the shortlist. A team whose binder is slow, paper-bound or scattered across a shared drive is comparing binders, and several good ones exist. A team whose study record is spread across a binder, a spreadsheet and a sponsor portal is comparing architectures. A better binder does not reduce the number of places the truth lives.

This guide sets out what Florence publishes about its own scope, the conditions that send teams looking, a named shortlist covering Veeva SiteVault, Complion, Advarra eReg, TransPerfect Trial Interactive, SharePoint and AQ, what a site file does not hold, what an inspection costs when one study sits in two systems, and how a move is planned. Every statement about a named product comes from that vendor’s own public documentation.

Key takeaways

• Florence states its own intended use. The eBinders FAQ describes the product as built for creating and maintaining documents and workflows, and names the systems it augments rather than replaces.
• The right alternative follows the layer that is failing. A slow site file and a fragmented study record are different problems, and they have different answers.
• Six named systems cover the realistic shortlist. Veeva SiteVault, Complion from RealTime, Advarra eReg, TransPerfect Trial Interactive, SharePoint and AQ, each described below in its own vendor’s published wording.
• Most site-file vendors draw the same line, and two cross it. Advarra names OnCore and Clinical Conductor, RealTime lists eReg and CTMS separately, and Florence names trial databases and staff tracking among the systems it augments. Veeva SiteVault and AQ each put study management on the same platform as the site file.
• A site file holds documents. Recruitment against target, milestone dates, visit windows, pharmacy accountability and CAPA status sit outside the binder in every architecture.
• System count has an inspection cost. MHRA guidance states that direct access must be made available to each system where multiple electronic systems constitute the complete Trial Master File.
• Portability is a contract question. Florence’s FAQ states the research site owns all information its staff input, so an exit plan turns on export format and effort rather than on permission.

What Does Florence State eBinders Is?

Florence presents eBinders as “The Complete Electronic Investigator Site File and Participant Binder for Research Sites” on its published product page. The site product set is eBinders, StudyOrganizer and eConsent. The sponsor and CRO product set is SiteLink for document exchange and remote monitoring, an electronic Trial Master File, and eConsent. Site teams get the binder. Sponsors get the channel into it.

The eBinders FAQ is more precise than the marketing page, and more useful to a buyer. Its statements define the product boundary more precisely than any comparison a competitor could write.

None of this reads as a weakness. It reads as a product with a clear edge, described honestly by the company that built it. The mistake buyers make is treating that edge as the edge of the study record.

The compliance position deserves one further note for UK readers. Florence’s United States compliance page states that Florence “meets all technical requirements to be a Part 11 compliant system”, and addresses HIPAA and CCPA. NHS procurement asks a different set: the Data Security and Protection Toolkit, Cyber Essentials and G-Cloud. Those questions carry different evidence, and any vendor can answer them. Put them in writing during the tender rather than inferring an answer from a page written for another market.

Why Do Teams Look for Florence Alternatives?

Search volume for a vendor’s name plus “alternatives” rarely signals a failing product. It signals a changed requirement. Five conditions account for most of it, and each one points at a different category of answer.

• The binder is solved and the record is not. Documents are current and retrievable, and the coordinator still keeps recruitment, milestones and visit windows in a spreadsheet. The remaining problem sits above the document layer, so a second document system will not touch it.
• Accountability moves from one site to a whole organisation. An NHS R&D office or an academic sponsor answers for a portfolio, not a study. Portfolio questions need a system that reports across studies, which a per-study binder structure answers one study at a time.
• The login count keeps rising. Each new sponsor arrives with a portal, and the site file becomes one of five places a coordinator signs into on a Monday. The cost lands as reconciliation time, and it grows with the number of open studies.
• UK and NHS assurance questions arrive. Procurement asks for DSPT, Cyber Essentials and G-Cloud evidence, hosting location and a UK GDPR position. A vendor’s answer to those questions is a procurement fact, so ask for it directly rather than reading it from a US compliance page.
• The commercial model changes. Florence’s FAQ notes that sponsors commonly reimburse sites for eBinders on a per-trial basis. That model works well for a commercial portfolio. Investigator-led and academic studies carry no sponsor to reimburse, so cost lands on the institution and the arithmetic changes.

The first condition is the one that misroutes buyers. It presents as dissatisfaction with the site file and resolves as a gap in study management.

Which Categories Do Florence Alternatives Fall Into?

Four categories cover the realistic shortlist, and the named systems in each are listed in the section that follows. Every description comes from that vendor’s own published materials and stays at the level those materials support.

• Site-centric eISF specialists. Florence eBinders sits here, alongside Complion from RealTime and Advarra eReg. These are built for the research site, and both vendors list their eRegulatory product and their CTMS as separate offerings.
• Sponsor-backed site platforms. Veeva SiteVault and TransPerfect Trial Interactive reach the site from the sponsor side, and acquisition cost can be low or zero. SiteVault carries a CTMS module as well as an eISF, so it reaches further than the category name suggests.
• General document platforms. SharePoint and equivalent tools store and share files, and most institutions already own one. Regulated use adds validation, a computer-generated audit trail and compliant electronic signatures, and the institution owns that work permanently.
• Connected clinical platforms. The site file is one module inside a shared study record that also holds study management, pharmacy, quality and delegation. The binder stops being a separate system. AQ sits here, and so do enterprise suites at a different scale and price point.

The table below compares the categories on what a buyer is accountable for after the purchase. It is a map of trade-offs rather than a scoreboard, and no column is right for everyone.

Which Named Alternatives Belong on the Shortlist?

Six named systems sit alongside Florence on a realistic shortlist. The description column below quotes each vendor’s own published wording, so the table states what each company says about its product rather than what a competitor says about it. Scope statements were read on 31 August 2026 and vendors revise them, so confirm the current position during a tender.

The roster splits in two, and each vendor’s own materials show where it stands. Advarra names OnCore and Clinical Conductor as the systems its eReg product integrates with. RealTime lists eReg and CTMS as separate offerings. Florence names trial databases and staff tracking among the systems eBinders augments. Those three draw the same line in the same place, and they are explicit about it.

Veeva sits on the other side of that line, and the comparison should say so. SiteVault now offers a CTMS module alongside its eISF, and Veeva presents the set as “one place to manage your clinical trial studies and work with sponsors”. A site evaluating Florence against SiteVault is therefore choosing between a site file and a site file with patient activity tracking attached. The line still exists. Two of the seven have crossed it.

That line is the category rather than a defect. A site-file system is built to hold documents to an inspectable standard, and the strongest ones say so plainly. The decision in front of a buyer is whether the study record on the far side of that line has an owner, or whether it stays in a spreadsheet.

Also Read: AQ vs Veeva, Florence, RealTime and SharePoint: choosing connected clinical trial software

What Does a Site File Not Hold?

An electronic site file closes the monitoring visit gap for documents. It holds the protocol, the approvals, the delegation log, the training certificates, the CVs, the consent versions and the correspondence. Those are artefacts with a filing location and an expiry date. A study also generates state, and state has no filing location.

• Recruitment against target. Screened, consented, randomised and withdrawn counts by site and by month, measured against the recruitment plan the sponsor agreed.
• Milestone dates. Date site confirmed, date site ready to recruit, first participant recruited, and the national reporting those dates feed.
• Visit windows. The protocol-defined window each participant visit must fall inside, and the compliance check applied before a booking is made.
• Monitoring visit actions. The findings raised at a visit, the owner of each, the due date, and the evidence that each one closed.
• Pharmacy accountability. Investigational product receipt, storage conditions, dispensing, returns and destruction, which belong in an electronic Pharmacy Site File rather than the regulatory binder.
• Deviations and their CAPA. A deviation, its root cause, the corrective and preventive action raised against it, and the training or process change that evidences closure.
• Capacity. Which staff are delegated to which studies, how many open studies each holds, and whether the site can take another.

Every architecture holds these somewhere. The design question is whether that somewhere is inside the same record as the documents, or in a spreadsheet a coordinator maintains by hand. A binder tells you the delegation log exists. A record tells you it is current.

Teams building the document half from scratch can start from the ISF essential documents checklist, then decide separately where the state above will live.

What Changes at Inspection When One Study Sits in Two Systems?

The MHRA is explicit about the practical consequence. Its Good Clinical Practice guidance states that you will need to provide any equipment and software needed to access electronic records, and that “where multiple electronic systems constitute the complete TMF direct access must be made available to each system.” The same guidance treats a TMF that is incomplete to the extent that it cannot form the basis of inspection as a critical finding. System count is therefore an inspection variable, not an IT preference.

Consider a hypothetical but routine sequence at a fictional site, Northgate General. Protocol amendment v4.0 is approved on 14 May. The amendment is one document. It creates five separate obligations, and only the first of them is a filing task.

1. File the approved version. Protocol v4.0 and the approval letter are filed in the site file, and v3.0 is superseded. The binder does this well.
2. Retrain the delegated team. Twelve delegated staff need protocol v4.0 training recorded with dates that fall before their next study activity, which the delegation of authority record has to agree with.
3. Move the consent version in use. The amendment changes the participant information sheet, so consent taken after a stated date must use v4.0, and participants already enrolled may need reconsent.
4. Adjust the visit schedule. A new assessment shifts two visit windows, and every future booking has to be checked against the revised window.
5. Report the change. The substantial amendment date feeds sponsor reporting and national milestone returns.

An inspector following that thread asks one question: show me that everyone who performed a study activity after 14 May was trained on v4.0 first. The document half of the answer is in the binder. The activity half is in the visit schedule and the delegation record. A team running two systems produces the answer in two exports and reconciles them in the room. A team running one record produces it as one view. The evidence is identical. The time and the risk of a mismatch are not.

Also Read: TMF Reference Model and the investigator site file: where the eISF fits

How Should a Move From Florence Be Planned?

Florence’s FAQ states that the research site owns all information its staff input, so the constraint on a move is effort rather than entitlement. Five steps keep a transition defensible.

1. Fix the cut-over date and freeze the source. Name the date the outgoing system becomes read-only. Records created after that date belong to the new system, and the read-only copy stays available for the retention period.
2. Export documents with their metadata. Filenames alone lose version, effective date, signature and approval status. Ask the outgoing vendor for the export schema in writing, and confirm the incoming system ingests those fields rather than flattening them.
3. Rebuild the structure, then map into it. Zone and folder structures rarely map one to one. Agree the destination structure against the TMF Reference Model first, then map the export into it, so the new file is organised to a shared standard rather than to the old tool’s habits.
4. Enter the study state once. Milestone dates, recruitment figures, visit schedules and open actions live in spreadsheets during a binder-only deployment. Those are entered rather than migrated, and that work is the real cost of the move.
5. Reconcile before you decommission. Count documents in and out, check a sample against the source for signature and version fidelity, record the check, and keep the audit trail from the outgoing system. Decommission only after that record exists.

Step four is the one that surprises people. The document migration is a project. The study state has never been in a system at all, so it is entered for the first time.

What Are the Risks of Choosing on the Wrong Layer?

A shortlist assembled from the wrong layer produces a system that works and a problem that persists. Four risks follow from it.

• The spreadsheet survives the purchase. A document system replaces a document system, and the recruitment and milestone tracker stays where it was, which means the reconciliation work is unchanged.
• Governance stays per study. An R&D office asking a portfolio question gets a per study answer, and someone assembles the portfolio view by hand each month.
• System count grows rather than falls. Each addition raises the number of systems an inspector must be given direct access to, and raises the chance that two of them disagree.
• Migration effort is spent twice. A move to a second binder consumes the export, mapping and verification effort, and the same effort is required again if the study record problem is addressed later.

Also Read: NHS R&D: governing site files across a trust’s studies

How Does AQ Sit Alongside a Florence Deployment?

AQ answers the second version of the question, where the aim is one fewer system rather than a better binder. The connected platform holds the eISF as one module beside the clinical trial management system, the eTMF, the ePSF, quality management, CAPA and Digital Delegation of Authority, and those modules share one record rather than exchanging copies of it.

• One record, one trail. The site file and the study record sit in the same system, which gives an inspector one place to be given direct access to instead of several to reconcile.
• Delegation updates once. An end date on a delegation entry is visible to the site file, the training matrix and the study record at the same moment, which removes the divergence a reconciliation step is meant to catch.
• Portfolio questions answer natively. Document completeness and delegation currency report across every open study, which gives an R&D office a trust-wide view without a monthly assembly job.
• Filing follows a shared standard. The eTMF is built on the DIA TMF Reference Model, so the site file and the sponsor file are organised against the same structure a monitor already knows.
• UK assurance is answered directly. AQ aligns to G-Cloud, DSPT and Cyber Essentials Plus, supports UK GDPR, and provides 21 CFR Part 11 electronic signatures and role-based access.

Veeva SiteVault also puts a CTMS beside its site file, so AQ is not alone in answering the second question. The difference between them is breadth and fit. AQ carries the eTMF, ePSF, quality management, CAPA and Digital Delegation of Authority in the same record as well, and it is built around UK and NHS assurance expectations. A site choosing between the two should compare module coverage against its own obligations rather than take either claim on trust.

A site running a commercial portfolio on sponsor-reimbursed eBinders has a working answer, and AQ does not claim otherwise. The case for a change appears when the organisation carries the accountability: an NHS trust R&D office, an academic sponsor, a CRO or a research network answering for many studies at once. That is the boundary of this comparison, stated plainly.

See what one record looks like across the site file, delegation, pharmacy, quality and study management. Book a live demo and evaluate AQ against the systems you already run.