Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics → Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Matrix Plug-and-play starting point Clinical & GCP

Matrix: Source Data Location List (Source Documentation Agreement)

A plug-and-play per-protocol source data location list: for each CRF data element it names the source, the originator, whether a certified copy is needed, and the eSource designation, with a filled specimen and the findings it prevents.

Document type: Matrix

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

This is a ready-to-use source data location list, the per-protocol table that names where the source lives for every data element. It is also called a source documentation agreement or data source matrix. Set it up before the first subject is enrolled and keep it current; inspectors ask for it and monitors live by it. Replace every <<FILL: ...>> placeholder with your specifics. A worked filled specimen follows.

Document control header

FieldEntry
Document titleSource Data Location List
Document number<<FILL: e.g. SDLL-<protocol>-01>>
Protocol number / title<<FILL>>
Site number / name<<FILL: single site, or "sponsor master" for a template>>
Version<<FILL: version>>
Effective date<<FILL: before first subject>>
Prepared by<<FILL: name, role>>

1. Purpose

This list defines, for each CRF domain and data element in <<FILL: protocol>>, where the source record lives, who or what originated it, and whether a certified copy is required. Its purpose is to remove ambiguity about which record is the source, so that source data verification is unambiguous and no CRF field exists without a defined source. A field in the eCRF with no entry on this list is a gap.

2. How to use this list

  • One row per data element or CRF page. Split a domain into rows where different elements have different sources.
  • Name the originator: the person or device that first recorded the element.
  • Mark certified copy needed where the source is an object that must be copied into the trial file (typically EHR pages), and eSource where a field is entered directly with no upstream record.
  • Update it under version control whenever the protocol, EDC, or a vendor changes.

3. Source data location list

CRF domain / data elementSource locationOriginatorCertified copy needed?eSource?
<<FILL>><<FILL>><<FILL>>Yes / NoYes / No
<<FILL>><<FILL>><<FILL>>
<<FILL>><<FILL>><<FILL>>

4. eSource designations

List every field designated as eSource (the eCRF is the source), with the validation and originator basis.

eSource fieldSystemOriginator captured how?System validation ref
<<FILL>><<FILL>><<FILL>><<FILL>>

5. Acceptance criteria

  • Every CRF domain and element appears with a defined source location and originator.
  • No eCRF field exists without a row here.
  • Certified-copy needs are marked wherever an original object must be copied into the trial file.
  • Every eSource field is listed with its validation and originator basis.
  • The list is version-controlled and dated before first subject, and kept current.

6. Signatures

RoleNameSignatureDate
Prepared by (sponsor/CRA)<<FILL>>
Principal Investigator<<FILL>>
Sponsor clinical operations<<FILL>>

7. References

ICH E6(R2)/E6(R3) Good Clinical Practice (source data, source documents, certified copies, essential records). FDA guidance, Electronic Source Data in Clinical Investigations (originator concept). 21 CFR 312.62 (investigator recordkeeping); 21 CFR Part 11 (electronic records).

Confirm the current version of each reference before issue.


Filled specimen

The following shows the list for an example phase 2 trial. The specifics are illustrative.

CRF domain / data elementSource locationOriginatorCertified copy needed?eSource?
Informed consent date and signaturesSigned paper ICF in subject binderSubject and investigatorNo, original retained at siteNo
Demographics, medical historySite EHR / subject chartInvestigator/coordinatorYes, certified copy of relevant EHR pagesNo
Vital signsPaper vitals worksheetStudy nurseNo, original worksheet retainedNo
Central lab chemistry/hematologyCentral lab electronic record / data file into EDCCentral lab analyzerLab is source of recordNo
Local safety labsSite EHR / printed analyzer reportLocal labYes if EHR, certified copyNo
ECGECG machine printout / vendor portalECG device / core labCertified copy of tracingNo
Investigational product accountabilityDrug accountability log (paper or IRT)PharmacyNo, original log retainedNo
Adverse eventsSite EHR progress notes + AE worksheetInvestigatorYes for EHR-sourced AEsNo
ePRO diaryePRO vendor systemSubjectVendor system is sourceYes
Pain score at visit (no prior paper)Validated eCRF fieldCoordinator (entered directly)n/aYes
Concomitant medicationsEHR medication list + subject reportCoordinatorYes for EHR portionNo

eSource designations: the ePRO diary (subject is originator; ePRO vendor system validated under ref VAL-ePRO-2026) and the direct-entry pain score (coordinator originator; EDC validated under ref VAL-EDC-2026).

In this example the two eSource rows are the ones with nothing upstream to source-verify against, so the list flags them explicitly and points to the system validation that replaces transcription SDV. Every other row names an independent source a monitor can compare the eCRF to. A field that appeared in the eCRF but not on this list would be unverifiable data waiting to be cited.

Common findings this matrix prevents

  • A CRF field with data but no defined source (“CRF as source by default”), which inspectors call unverifiable data.
  • eSource fields never designated, so a monitor tries to source-verify a value with no upstream record.
  • Certified-copy needs missed for EHR-sourced data, leaving no defensible source in the trial file.
  • An ad hoc, undocumented understanding of what is source, so gaps go unnoticed.

How to adapt this matrix

  1. Build a sponsor master version from the protocol, then site-specific versions where a site’s EHR or local lab differs.
  2. Complete and sign it before the first subject and re-issue on any EDC, vendor, or protocol change.
  3. Give it to every monitor; it is the reference SDV is executed against.
  4. Cross-check it against the eCRF field list so no field is missing a source.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.