Pharmaceutical User Research Compliance Guide: FDA, IRB, and HIPAA Requirements for Product Teams

Pharmaceutical software user research operates under a triple compliance framework that no other industry faces simultaneously. The FDA requires human factors validation for software that affects patient safety. HIPAA requires safeguards whenever research involves protected health information. And IRB review is expected (and often required) when research involves healthcare professionals, patients, or clinical data.

Missing any one of these requirements can invalidate your research findings, delay regulatory submissions, or create legal liability. A usability study that produces excellent design insights but was not conducted under IRB oversight cannot be included in an FDA submission. A study that captured clinician workflows but did not follow HIPAA protocols exposes your organization to federal penalties. A formative study that found critical use errors but was not documented per IEC 62366-1 will not satisfy regulatory reviewers.

This guide covers how product and UX teams conduct user research for pharmaceutical software while satisfying FDA, IRB, and HIPAA requirements simultaneously. It is not a substitute for regulatory counsel, but it provides the practical framework that research teams need to plan compliant studies.

For HIPAA-specific compliance details applicable across all healthcare products, see our HIPAA-compliant research guide. For research consent best practices, see our consent guide.

Key takeaways

Pharmaceutical software research must satisfy three overlapping compliance frameworks: FDA human factors (if the software affects patient safety), HIPAA (if the research involves PHI), and IRB (if participants are human subjects in a regulated context)
FDA distinguishes between formative studies (iterative design research) and summative studies (validation for regulatory submission). Both require documentation, but summative studies have stricter protocols
21 CFR Part 11 applies when your pharma software uses electronic records or electronic signatures. Research involving these systems must document that the software maintains data integrity
Always use synthetic patient data in prototypes and test scenarios. Real patient data in a usability study creates HIPAA exposure that is entirely avoidable
Plan 8-16 weeks for the compliance preparation phase (IRB submission, protocol development, BAA execution) before recruiting a single participant

Understanding the three compliance layers

Layer 1: FDA human factors requirements

The FDA requires human factors engineering for medical devices and software that qualifies as a medical device (SaMD, Software as a Medical Device). Many pharmaceutical software products fall under this scope: clinical trial management systems (CTMS), electronic data capture (EDC), pharmacovigilance systems, drug safety databases, and clinical decision support tools.

When FDA human factors applies to your pharma software:

Software type	FDA classification	Human factors required?
Clinical trial management (CTMS)	May be regulated as part of clinical trial infrastructure	Formative recommended, summative if part of submission
Electronic data capture (EDC)	21 CFR Part 11 regulated	Formative recommended, data integrity validation required
Pharmacovigilance / drug safety	Regulated if it affects safety reporting decisions	Formative + summative if safety-critical workflows
Clinical decision support (CDS)	SaMD if it makes clinical recommendations	Full human factors per FDA CDS guidance
Lab information management (LIMS)	GxP regulated in pharma contexts	Formative recommended, validation required
Electronic common technical document (eCTD)	Submission tool, not directly patient-facing	Formative recommended for usability, not FDA-mandated
Randomization and trial supply (RTSM/IRT)	Critical to trial integrity, affects patient safety	Formative + summative if randomization errors could harm patients

Formative vs. summative studies:

Dimension	Formative study	Summative study
Purpose	Identify and fix usability issues during design	Validate that the final design is safe and effective for regulatory submission
When	Early and mid-development (iterative)	Late development, pre-submission
Participants	5-8 per round, multiple rounds	15-25 representative users per user group
Protocol rigor	Flexible, can adapt between sessions	Fixed protocol, no changes mid-study
Documentation	Summary report with findings and design changes	Full human factors validation report per IEC 62366-1
Regulatory use	Informs design decisions (not submitted directly)	Included in regulatory submission (510(k), PMA, or equivalent)
Use error documentation	Document and address critical use errors	Document all use errors, close calls, and mitigations with traceability

Layer 2: HIPAA requirements for pharma research

HIPAA applies when your research involves protected health information from participants who are patients, clinicians handling patient data, or clinical trial subjects.

When HIPAA applies in pharma research:

Scenario	HIPAA applies?
Testing a CTMS with clinical research coordinators using mock trial data	No (mock data, no PHI)
Interviewing clinicians about their prescription workflows (no patient data shared)	Generally no (general workflow discussion)
Testing an EDC system with real clinical trial data visible	Yes (clinical trial data is PHI)
Usability testing a pharmacovigilance system with real adverse event reports	Yes (adverse event reports contain PHI)
Testing a patient-facing app with patients who share their health information	Yes (patient-disclosed health information)

For detailed HIPAA compliance protocols, tool requirements, and consent form templates, see our HIPAA-compliant research guide.

Layer 3: IRB requirements for pharma research

IRB review is required when your research involves human subjects and the findings will be used for regulatory submission, published academically, or when participants are from vulnerable populations (patients, clinical trial subjects).

IRB requirements for pharma UX research:

Requirement	What it means for UX research
Protocol review	Submit your research plan, screener, consent form, task scenarios, and data handling procedures for IRB review before recruiting
Informed consent	HIPAA-compliant consent that includes: study purpose, procedures, risks, PHI handling, right to withdraw, and contact information for the IRB
Risk assessment	Document the risks of participation (minimal for most usability studies) and mitigation strategies
Vulnerable population considerations	If participants are patients, children, or cognitively impaired, additional protections apply
Adverse event reporting	If a participant experiences distress or harm during the study, report to the IRB per their reporting requirements
Continuing review	For studies lasting more than 12 months, annual renewal with the IRB is required

IRB timeline: Plan 6-12 weeks for initial IRB submission, review, and approval. Expedited review (for minimal-risk studies) may take 4-6 weeks. Full board review (for studies involving patients or higher-risk protocols) may take 8-12 weeks.

How to conduct FDA-compliant formative usability studies

Formative studies are the bread and butter of pharma software UX research. They are iterative, relatively flexible, and do not require the rigid protocols of summative validation.

Formative study protocol

Participants: 5-8 per round, from the intended user population. For pharma software, this typically includes:

Clinical research coordinators (CRCs) for CTMS/EDC
Pharmacovigilance specialists for safety databases
Lab technicians for LIMS
Data managers for EDC/data review tools
Clinicians/investigators for CDS and patient-facing tools

Session structure (60-90 minutes):

Phase	Duration	Activities
Introduction and consent	10 min	Review consent form, confirm understanding, address questions. Record consent verbally and in writing
Background interview	10 min	Current role, tools used, experience level. Establishes participant context for the use environment
Task scenarios	40-50 min	5-8 realistic tasks using the prototype or working software. Think-aloud protocol. Observe use errors, difficulties, and workarounds
Post-task questionnaire	10 min	SUS (System Usability Scale) or task-specific satisfaction ratings
Debrief	10 min	Open-ended feedback, severity ranking of observed issues, suggestions for improvement

Use error documentation (critical for FDA):

For every observed use error or difficulty, document:

Field	Description
Task	Which task was the participant performing?
Use error description	What did the participant do wrong or struggle with?
Root cause	Why did the error occur? (UI design, labeling, workflow, training gap)
Severity	Could this error cause patient harm, data integrity loss, or regulatory non-compliance?
Frequency	How many participants encountered this error?
Mitigation	What design change addresses this error?
Verification	Was the mitigation tested in a subsequent round? Did it resolve the error?

This documentation creates the traceability that regulatory reviewers expect: from observed problem to root cause to design change to verification.

What makes formative studies different in pharma

Use-related risk analysis. Before designing tasks, conduct a use-related risk analysis (URRA) that identifies which software interactions could lead to patient harm, data integrity failures, or regulatory non-compliance. Focus your test scenarios on these high-risk interactions.

Representative use environment. Test in conditions that match the actual use environment: the same hardware (if the software runs on specific workstations), the same data volumes (if the system handles thousands of patient records), and with appropriate interruptions (clinical environments are noisy and interrupt-heavy).

Critical task identification. Identify the 10-15 tasks that are most critical for patient safety and regulatory compliance. These must be tested in every formative round. Non-critical tasks can rotate across rounds.

How to conduct FDA-compliant summative validation studies

Summative studies validate that the final design is safe and effective for its intended users, uses, and use environments. These studies are included in regulatory submissions.

Summative study requirements

Participants: 15-25 per user group. If your software has 3 distinct user groups (e.g., investigators, CRCs, data managers), plan for 45-75 total participants. The FDA human factors guidance recommends 15 participants per user group as a minimum for summative studies.

Protocol: Fixed and documented before the study begins. No protocol changes mid-study. If you discover a critical issue during the study, document it but do not change the protocol. Changes require IRB amendment and potentially re-starting the study.

Tasks: All critical tasks identified in the URRA must be tested. Tasks must be realistic, not simplified. Include realistic data volumes, time pressures, and environmental conditions.

Documentation: The summative validation report must include:

Study objectives and rationale
Description of the intended users, uses, and use environments
Participant demographics and screening criteria
Full protocol with task descriptions, success criteria, and observation procedures
Results for every critical task: completion rate, use errors, close calls, and difficulties
Root cause analysis for each use error
Risk assessment: which residual use errors could cause patient harm?
Conclusion: does the evidence support that the design is safe and effective?

Common summative study mistakes

Insufficient participants. Fewer than 15 per user group is likely insufficient for regulatory reviewers
Simplified tasks. Tasks that do not reflect real-world complexity produce artificially high success rates
Coaching during sessions. If the moderator provides hints or guidance during a summative study, the data is compromised. Summative sessions must be strictly hands-off
Protocol deviations. Any deviation from the approved protocol must be documented and justified. Multiple deviations can invalidate the study
Missing root cause analysis. Documenting that a use error occurred without explaining why is insufficient. Regulatory reviewers expect root cause analysis and mitigation for every critical use error

21 CFR Part 11 considerations for pharma software research

21 CFR Part 11 governs electronic records and electronic signatures in FDA-regulated industries. If your pharma software uses e-signatures or generates electronic records that are part of regulatory submissions, Part 11 applies.

How Part 11 affects UX research

Part 11 requirement	Research implication
Audit trails	Test whether users can identify who made changes, when, and why. Is the audit trail comprehensible?
Electronic signatures	Test the e-signature workflow: is it clear what users are signing? Do they understand the legal significance?
Access controls	Test role-based access: can users access only what their role permits? Do access restrictions confuse or frustrate users?
Data integrity	Test whether the software maintains data accuracy through user workflows. Can users accidentally corrupt data?
System validation	The software itself must be validated. Usability testing is one component of the overall validation strategy

Part 11 usability test scenarios

“Sign off on this clinical data entry using your electronic signature. What does this signature mean legally?”
“Review the audit trail for this patient record. Who made the last change, and why?”
“Try to access a record that is outside your role’s permissions. What happens?”
“Enter data, then correct an error. Does the system preserve the original entry and the correction?”

How to test pharma software with clinical users

Clinician and healthcare professional participants

Pharma software users span multiple clinical and research roles:

Role	Software they use	Research focus
Clinical research coordinator (CRC)	EDC, CTMS, RTSM, e-consent	Data entry speed, protocol compliance, error prevention
Principal investigator (PI)	EDC (review), CDS, e-consent	Data review, clinical decision-making, study oversight
Pharmacovigilance specialist	Safety databases, MedDRA coding	Adverse event coding, signal detection, case processing
Data manager	EDC, data review tools, CDISC	Query management, data cleaning, edit check handling
Lab technician	LIMS, instrument integration	Sample tracking, result entry, equipment interface
Regulatory affairs specialist	eCTD, submission tools	Document compilation, submission assembly, compliance checks
Clinical pharmacist	Medication management, drug interaction tools	Prescription review, dosing calculation, interaction alerts

Adapting sessions for clinical participants

Scheduling: Clinicians have unpredictable schedules. Offer multiple session times including early morning (before clinic), lunch, and evening. Expect 20-25% cancellation rate due to clinical emergencies. Over-recruit accordingly.

Session length: 45-60 minutes maximum. Clinicians will not commit to 90-minute sessions. Design your protocol to complete critical tasks within 45 minutes, with optional additional tasks if time permits.

Technical environment: Many clinicians access software through hospital IT systems with specific browsers, screen resolutions, and security configurations. If possible, test on hardware that matches their clinical environment.

Language: Use clinical terminology that matches participants’ vocabulary. “Patient record” not “data entry form.” “Adverse event report” not “safety form submission.” Mismatched terminology creates confusion that is an artifact of the research, not the product.

How to handle mock data in pharma research

Creating pharma-realistic synthetic data

Real patient data must never appear in usability testing prototypes. Synthetic data must be realistic enough that clinical participants engage with it authentically.

Requirements for pharma synthetic data:

Data element	Realistic characteristics	What to avoid
Patient demographics	Realistic names (not “Test Patient 1”), plausible age/gender distributions, realistic medical history complexity	Obvious placeholder names, unrealistic demographic combinations
Clinical trial data	Realistic visit schedules, lab value ranges, adverse event frequencies	Perfect data with no queries or discrepancies (real clinical data is messy)
Lab results	Values within and outside normal ranges, realistic units, plausible trends over time	All values perfectly normal (unrealistic)
Adverse events	MedDRA-coded events at realistic frequencies, varying severity grades	Only mild events (real pharmacovigilance data includes serious events)
Medication data	Realistic drug names, dosing regimens, interaction potential	Made-up drug names that clinicians do not recognize

The messiness principle: Real clinical data is messy. It has queries, missing values, protocol deviations, and inconsistencies. Synthetic data that is too clean does not engage clinicians the way real data does, and it misses the usability challenges that arise from data quality issues.

How to recruit pharma professionals for research

Where to find participants

Internal recruitment (for existing customers). Partner with pharma companies’ clinical operations, IT, or innovation teams to identify willing participants
Clinical research organizations (CROs). CROs employ large numbers of CRCs, data managers, and project managers. Partner with CRO training or quality departments
Professional associations. ACRP (clinical research professionals), DIA (drug information), ISPE (pharma engineering), RAPS (regulatory affairs), ISMP (medication safety)
LinkedIn targeting. Search by title (Clinical Research Coordinator, Pharmacovigilance Specialist, Data Manager) + industry (Pharmaceuticals, Biotechnology, CRO)
CleverX verified B2B panels. Pre-screened pharma professionals filtered by role, system experience, and therapeutic area
Pharma conferences. DIA Annual Meeting, SCOPE Summit, ACRP conferences

Incentive benchmarks

Role	Rate range	Notes
Clinical research coordinator	$125-200/hr	Schedule around site visits and study activities
Pharmacovigilance specialist	$150-250/hr	Specialized role, harder to recruit
Data manager	$125-200/hr	Often more available than clinical roles
Principal investigator / physician	$300-500/hr	Extremely limited availability. Premium rate essential
Lab technician	$100-175/hr	More accessible than clinical roles
Regulatory affairs specialist	$150-275/hr	Specialized compliance knowledge

Screening questions

Which pharmaceutical or clinical research software do you use at least weekly? (Open text. Names specific systems like Medidata Rave, Veeva Vault, Oracle Argus, LabWare)
What is your primary role in pharmaceutical research or operations? (Open text)
Describe a task you completed in your pharma software in the last week. (Articulation check)
How many years in a pharmaceutical or clinical research role? (Range)
What therapeutic areas do you work in? (Multi-select. Provides context for data realism)

Compliance checklist for pharma user research

Pre-study (8-16 weeks before first session)

During study

Obtain signed consent (written + verbal confirmation on recording) before each session
Use synthetic data only in all prototypes and scenarios
Document all use errors, close calls, and difficulties using the URRA framework
Conduct sessions on HIPAA-compliant platforms with BAAs
Monitor for adverse events (participant distress, unexpected safety concerns)
Follow fixed protocol for summative studies (no deviations without IRB amendment)
Encrypt all session recordings and store on access-controlled systems

Post-study

Review recordings for accidental PHI exposure. Redact if found
Complete use error analysis with root causes and mitigations
De-identify all data per HIPAA safe harbor method
Prepare formative report (design recommendations) or summative validation report (regulatory submission)
Submit findings to IRB if required by approval conditions
Retain consent forms and audit trails for minimum 6 years
Archive study materials per GxP document retention requirements

Frequently asked questions

Does all pharmaceutical software require FDA human factors testing?

No. FDA human factors requirements apply primarily to software classified as a medical device (SaMD) or software that directly affects patient safety decisions. Administrative pharma software (project management, budgeting, HR) does not require FDA human factors testing. However, even for non-SaMD pharma software, formative usability testing is best practice because it improves the product and reduces training costs.

Can formative study findings be included in an FDA submission?

Yes, but formative and summative studies serve different purposes. Formative study findings demonstrate that you identified and addressed usability issues during development (design history file). Summative study findings validate that the final design is safe and effective. Both contribute to the regulatory submission, but the summative study is the primary evidence of usability validation.

How do you handle use errors that create patient safety risk during testing?

Document the use error immediately with full details (task, error description, root cause, potential patient impact). If the error reveals a critical safety risk in the current product design, escalate to the product and regulatory teams before continuing the study. For summative studies, critical use errors may require design changes and re-testing, which means restarting the summative study after IRB amendment. This is expensive and time-consuming, which is why thorough formative testing (catching these issues early) is essential.

Is IRB approval required for pharma usability testing that is not published?

It depends on the regulatory context. If the usability study will be included in an FDA submission, IRB review is strongly recommended because regulatory reviewers expect it. If the study involves patients or clinical trial subjects, IRB review is required regardless of publication intent. If the study involves only pharma professionals (not patients) testing commercial software with synthetic data, IRB review may not be formally required but is still best practice for liability protection. Consult your regulatory affairs team.

How do you balance rigorous compliance with agile UX research?

Use formative studies for agile iteration and summative studies for regulatory validation. Formative studies are flexible: you can change the protocol between rounds, adjust tasks based on findings, and iterate rapidly. Summative studies are rigid: fixed protocol, no changes, thorough documentation. Run multiple formative rounds during development (agile-compatible), then one definitive summative round before submission (waterfall-compatible). This hybrid approach satisfies both agile product development and regulatory requirements.

What external links should pharma UX researchers bookmark?

FDA Human Factors Guidance: The primary FDA guidance on human factors for medical devices and SaMD
HHS HIPAA Research Guidance: HHS guidance on HIPAA compliance for research
21 CFR Part 11: Electronic records and signatures regulation
IEC 62366-1: Usability engineering standard for medical devices
FDA CDS Guidance: Clinical decision support software classification
OHRP IRB Guidance: HHS Office for Human Research Protections FAQ on informed consent