Build a Mock eTMF for a Phase II Study

Create a mock eTMF, resolve QC gaps, and run an inspection retrieval drill.

Introduction

30 Second Summary

Important study records can end up spread across folders with unclear dates or duplicate copies. Finding the current document becomes difficult when nobody can trace what changed.

In this project, you will build an inspection-ready mock electronic Trial Master File for a fictional Phase II drug study. You will organize synthetic records across the study lifecycle before checking their quality and proving that you can retrieve them quickly.

What You'll Build

You open the study repository during a mock inspection request and retrieve the current approved record with its quality history visible in the tracker.

By the end of this project, you'll have:

  • A restricted Google Drive repository where you can locate synthetic records from study start-up through closeout using a clear filing structure.
  • A searchable Microsoft Excel tracker that identifies each expected record by lifecycle phase, owner, date, version, filing status, quality status, and folder location.
  • A documented quality and inspection-readiness trail that shows four findings, their remediation history, improved file-health metrics, and timed retrieval evidence.
  • A Secret Mission where you process a protocol amendment with a linked informed-consent update while preserving the superseded versions and retrieval trail.

Are there any prerequisites?

You need a Windows computer with Microsoft 365, Microsoft Word, Microsoft Excel, and access to Google Drive. Coursework-level knowledge of clinical research and ICH-GCP helps, but you do not need production eTMF experience.

This project uses fictional records with no participant data. It is a workflow simulation and does not represent experience with a validated production eTMF.

Before We Start

Before the hands-on work begins, this checkpoint helps you commit to what you are building. You will connect the simulation to the clinical research or eTMF role you are targeting.

Your eTMF workflow simulation covers fictional Phase II study MOCK-PH2-001. It uses synthetic records with no participant data.

A clear commitment statement names the mock study. It also explains how practicing document control supports your target role without claiming production eTMF experience.

Set Up the Mock eTMF Workspace

Clinical study records become difficult to review when filenames drift or documents sit in scattered locations. A defined filing plan prevents that confusion before the first record arrives.

A controlled mock eTMF gives every synthetic record a predictable home. This step creates that workspace for fictional study MOCK-PH2-001.

In this step, get ready to:
  • Confirm that Microsoft Excel and Microsoft Word can create and save your project files.
  • Create a restricted Google Drive repository with eight study folders.
  • Build the tracker workbook and reusable Word record-card template.
Create the restricted repository

The repository provides one controlled location for the simulation. Its numbered folder names keep the lifecycle records searchable as the file grows.

  • Press the Windows key to open the Windows search bar.
  • Type Microsoft Excel and press Enter.
  • Create a blank workbook from the Excel start screen.
  • Press the Windows key again to return to the search bar.
  • Type Microsoft Word and press Enter.
  • Create a blank document from the Word start screen.

You should see an editable Excel grid plus an editable Word page. You will use these blank files for the tracker and record card later in this step.

  • Visit drive.google.com in your browser.
  • Sign in to Google Drive if prompted.
  • Select New in the top-left corner.
  • Select Folder.
  • Enter Mock_eTMF_PHASE2 as the folder name.
  • Select Create.
  • Open the sharing settings for Mock_eTMF_PHASE2.
  • Set General access to Restricted.

You should see Restricted under General access. This confirms that the repository is not publicly accessible.

What this workspace represents

This Google Drive folder is a training repository for a fictional study. Describe the finished project as an eTMF workflow simulation because validated production eTMFs include additional system controls.

Every record remains synthetic. The repository contains no participant data or real sponsor information.

The numbered taxonomy separates study management, product, regulatory, site, safety, quality, and historical records. Consistent locations make later retrieval checks repeatable.

  • Open Mock_eTMF_PHASE2.
  • Select New.
  • Select Folder.
  • Enter 01_Trial_Management.
  • Select Create.
  • Create 02_Protocol_and_Product with the same folder control.
  • Create 03_Regulatory_and_Ethics with the same folder control.
  • Create 04_Site_Management with the same folder control.

Your first four subfolders now separate trial management, protocol, regulatory, and site records.

  • Create 05_Investigational_Product with the same folder control.
  • Create 06_Safety_and_Monitoring with the same folder control.
  • Create 07_QC_and_Inspection_Readiness with the same folder control.
  • Create 08_Superseded_and_Rejected with the same folder control.

You should now see all eight numbered subfolders inside Mock_eTMF_PHASE2.

Build the tracker workbook

The workbook acts as the index for your simulated file. Its metadata connects each future record to its study, lifecycle phase, status, and storage location.

  • Switch back to the blank Excel workbook from earlier.
  • Rename the first worksheet tab to Study_Profile.
  • Add five worksheet tabs using the plus control beside the existing tab.
  • Rename the second worksheet tab to Expected_Documents.
  • Rename the third worksheet tab to QC_Findings.
  • Rename the fourth worksheet tab to Change_Log.
  • Rename the fifth worksheet tab to TMF_Health.
  • Rename the sixth worksheet tab to Inspection_Request.

You should see six worksheet tabs in the required order. Each tab reserves one part of the document-control workflow.

How the tracker is organized

The study profile anchors the workbook to one fictional trial. The remaining sheets provide dedicated spaces for expected records, QC findings, changes, health metrics, and inspection requests.

  • Populate cells A1:B1 with Study ID followed by MOCK-PH2-001.
  • Populate cells A2:B2 with Phase followed by Phase II.
  • Populate cells A3:B3 with Product followed by Fictional oral investigational product.
  • Populate cells A4:B4 with Site followed by SITE-001.
  • Populate cells A5:B5 with Scope followed by Start-up through closeout simulation.
  • Populate cells A6:B6 with Data rule followed by No participant data.
  • Save the workbook to your Windows desktop as MOCK-PH2-001_eTMF_Tracker.xlsx.
  • Confirm that the Excel title bar shows MOCK-PH2-001_eTMF_Tracker.xlsx.

The workbook should remain open with the six worksheet tabs visible. The Study_Profile sheet should display all six study-profile values.

Workbook name not staying?

Confirm that the filename ends with .xlsx. Check that you selected your Windows desktop before saving.

Help me troubleshoot saving the mock eTMF tracker in Excel.

Create and test the record card

A reusable record card gives every synthetic document the same visible identity and control fields. The wording also keeps the simulation boundary clear whenever someone opens a record.

  • Switch back to the blank Word document from earlier.
  • Type SIMULATION ONLY on the first line.
  • Add the identity fields Study ID, Record ID, and Document Type on separate lines.
  • Add the lifecycle fields Lifecycle Phase, Owner, and Document Date on separate lines.
  • Add the control fields Version, Status, and Sign-off Status on separate lines.
  • Add No participant data. Training artifact only. as the final line.
  • Save the document to your Windows desktop as Mock_Record_Card_Template.docx.

You should see Mock_Record_Card_Template.docx in the Word title bar. The document should contain the simulation label, nine fields, and the final training statement.

Why the simulation labels matter

The labels distinguish every record card from real clinical-trial documentation. They also support accurate career framing when you discuss the project later.

  • Save a second copy of the Word document as TEST_Record_Card.docx on your Windows desktop.
  • Return to Mock_eTMF_PHASE2 in Google Drive.
  • Open 01_Trial_Management.
  • Select New.
  • Select File upload.
  • Choose TEST_Record_Card.docx from your Windows desktop.
  • Open the uploaded TEST_Record_Card.docx from Google Drive.

You should see the Word record card with SIMULATION ONLY at the top. This proves that the reusable document survives the upload and opens from the repository.

  • Close the Google Drive preview.
  • Right-click TEST_Record_Card.docx.
  • Select Move to Trash.
  • Confirm that 01_Trial_Management no longer lists the test file.

The upload test is complete. The permanent template remains available on your Windows desktop.

Test file not opening?

Confirm that the upload has finished before opening the file. Check that the selected file is named TEST_Record_Card.docx.

Help me troubleshoot the Word record-card upload test in Google Drive.

Before the final check, do you expect the repository, workbook, and template to reopen without an access or format error?

  • Close MOCK-PH2-001_eTMF_Tracker.xlsx in Excel.
  • Close Mock_Record_Card_Template.docx in Word.
  • Return to Google Drive and open Mock_eTMF_PHASE2.
  • Use Windows File Explorer to open MOCK-PH2-001_eTMF_Tracker.xlsx from your Windows desktop.
  • Use Windows File Explorer to open Mock_Record_Card_Template.docx from your Windows desktop.

You should see the eight folders in Google Drive, the six tracker worksheets in Excel, and the complete record card in Word. All three artifacts should open without an access or format error.

You now have a restricted workspace with a working tracker and reusable record card. Next up, you will populate it with the first synthetic study records.

Build the First Study File

Your controlled workspace is ready. It now needs enough synthetic content to represent study start-up, conduct, and closeout.

A populated repository can look complete while hiding obsolete versions, incorrect metadata, misplaced records, or duplicates. This step creates that realistic first version so you can test its quality later.

In this step, get ready to:
  • Define twelve expected records in the study tracker.
  • Create a synthetic incoming record card for each expected record.
  • File the incoming bundle before retrieving the protocol through its tracker metadata.
Build the expected-document list

In this simulation, the expected-document list in Microsoft Excel acts as an index for the electronic Trial Master File. Its metadata defines what should exist before you compare that expectation with the repository.

  • Return to MOCK-PH2-001_eTMF_Tracker.xlsx in Excel.
  • Select the Expected_Documents worksheet.
  • Enter the following headers across row 1 from left to right:
  • Enter Record_ID in column A.
  • Enter Lifecycle_Phase in column B.
  • Enter Level in column C.
  • Enter Document_Type in column D.
  • Enter Owner in column E.
  • Enter Expected_Date in column F.
  • Enter Document_Date in column G.
  • Enter Version in column H.

The first eight columns describe the identity and expected state of each record. The remaining columns track filing, review, ownership, and resolution.

  • Enter Filing_Status in column I.
  • Enter QC_Status in column J.
  • Enter Folder_Path in column K.
  • Enter Issue_ID in column L.
  • Enter Action_Owner in column M.
  • Enter Due_Date in column N.
  • Enter Resolution_Status in column O.

How the record map works

Each row below follows the column order through Folder_Path. Keep the issue-management columns empty because no quality findings have been opened.

The twelve rows form a proportionate training sample across three lifecycle phases. They do not represent an exhaustive regulatory checklist.

  • Enter row 2 as R-001 | Start-up | Study | Protocol | Sponsor | expected 2026-01-05 | document 2026-01-05 | version 1.0 | folder 02_Protocol_and_Product.
  • Enter row 3 as R-002 | Start-up | Site | Protocol Signature Page | Principal Investigator | expected 2026-01-08 | document 2026-01-08 | version 1.0 | folder 02_Protocol_and_Product.
  • Enter row 4 as R-003 | Start-up | Study | Investigator's Brochure | Sponsor Medical | expected 2026-01-12 | document 2026-01-12 | version 3.0 | folder 02_Protocol_and_Product.
  • Enter row 5 as R-004 | Start-up | Site | Ethics Approval Letter | Ethics Committee | expected 2026-02-01 | document 2026-01-31 | version N/A | folder 03_Regulatory_and_Ethics.
  • Enter row 6 as R-005 | Start-up | Study | Informed Consent Form Template | Sponsor and Ethics Committee | expected 2026-02-10 | document 2026-02-10 | version 2.0 | folder 03_Regulatory_and_Ethics.
  • Enter row 7 as R-006 | Start-up | Site | Principal Investigator CV | Principal Investigator | expected 2026-02-15 | document 2026-02-15 | version N/A | folder 04_Site_Management.

Expected state versus incoming state

The Version cell records the expected current version. That is why R-005 remains at 2.0 even though its incoming record card uses 1.0.

The Folder_Path cell records the expected location. Keep R-002 mapped to 02_Protocol_and_Product when its file is placed elsewhere.

  • Enter row 8 as R-007 | Start-up | Site | Delegation Log | Site Coordinator | expected 2026-02-20 | document 2026-02-20 | version 1.0 | folder 04_Site_Management.
  • Enter row 9 as R-008 | Start-up | Site | Investigational Product Receipt Record | Site Pharmacist | expected 2026-02-05 | document 2026-02-05 | version 1.0 | folder 05_Investigational_Product.
  • Enter row 10 as R-009 | Conduct | Site | Investigational Product Accountability Log | Site Pharmacist | expected 2026-03-15 | document 2026-03-15 | version 1.0 | folder 05_Investigational_Product.
  • Enter row 11 as R-010 | Conduct | Study | Safety Notification | Sponsor Safety | expected 2026-04-10 | document 2026-04-10 | version 1.0 | folder 06_Safety_and_Monitoring.
  • Enter row 12 as R-011 | Conduct | Site | Monitoring Visit Report | Clinical Research Associate | expected 2026-05-12 | document 2026-05-12 | version 1.0 | folder 06_Safety_and_Monitoring.
  • Enter row 13 as R-012 | Closeout | Site | Site Closeout Checklist | Clinical Research Associate | expected 2026-06-20 | document 2026-06-20 | version 1.0 | folder 06_Safety_and_Monitoring.
  • Leave columns I through O empty until the incoming files are created.
  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.
  • Confirm that rows 2 through 13 contain one expected record each.

That is the first control layer complete. Your workbook now defines the twelve records against which the incoming repository can be assessed.

Create the synthetic incoming records

A reusable record card in Microsoft Word gives every synthetic file visible identity, date, ownership, and version information. The simulation labels keep the records separate from genuine clinical-trial documentation.

  • Return to Mock_Record_Card_Template.docx in Word.
  • Create twelve copies in the same local folder as the template.
  • Keep SIMULATION ONLY on every copy.
  • Keep No participant data. Training artifact only. on every copy.
  • Enter MOCK-PH2-001 as the Study ID on every copy.
  • Copy each record's ID, document type, lifecycle phase, and owner from its tracker row.
  • Copy each document date from the tracker except for R-004.
  • Copy each version from the tracker except for R-005.

Keep the cards synthetic

Use record cards only. Do not add participant identifiers, medical information, real signatures, or genuine sponsor details.

Use N/A for the version on R-004 and R-006. This keeps the card aligned with the expected-document list.

  • Set Status to Incoming on all twelve cards.
  • Set Sign-off Status to Not assessed in simulation on all twelve cards.
  • Enter 2026-02-01 as the Document Date on the R-004 card.
  • Enter 1.0 as the Version on the R-005 card.
  • Name each card with its record ID, document type, and document date separated by underscores.
  • Save the R-008 card as SITE-001_IP_Receipt_Record_2026-02-05.docx.
  • Save a content-identical copy of R-008 as SITE-001_IP_Shipment_Receipt_2026-02-05.docx.

Why the incoming bundle has gaps

The date mismatch, obsolete consent version, future filing-location error, and duplicate represent realistic control gaps. Keep each one in place so the first repository reflects an unchecked incoming bundle.

  • Return to the template's local folder in Windows File Explorer.
  • Count the new Word record cards.

You should see thirteen new files. Twelve represent expected records while the second R-008 file creates the additional duplicate.

Seeing fewer than thirteen files?

Check that every Record ID from R-001 through R-012 has one card. Confirm that both exact R-008 filenames are present.

A repeated filename may have replaced an earlier copy. Create the missing card again with a unique filename.

Help me find the missing synthetic record card.

File the bundle and test retrieval

A searchable repository depends on the relationship between tracker metadata and actual storage in Google Drive. You will now create the first filed state without reconciling its deliberate gaps.

  • Return to the restricted Mock_eTMF_PHASE2 repository in Google Drive.
  • Upload the R-002 record card to 01_Trial_Management.
  • Upload the R-001 and R-003 record cards to 02_Protocol_and_Product.
  • Upload the R-004 and R-005 record cards to 03_Regulatory_and_Ethics.
  • Upload the R-006 and R-007 record cards to 04_Site_Management.
  • Upload both R-008 files plus the R-009 card to 05_Investigational_Product.
  • Upload the R-010, R-011, and R-012 record cards to 06_Safety_and_Monitoring.
  • Return to Expected_Documents in the tracker workbook.
  • Enter Filed in cells I2 through I13.
  • Enter Not Reviewed in cells J2 through J13.
  • Keep the expected folder values in cells K2 through K13.
  • Leave cells L2 through O13 empty.
  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.

What the provisional statuses mean

A Filed status records that an incoming file is present. Not Reviewed preserves the fact that no document-level quality check has occurred.

These values describe the repository's current state. They do not certify that the records are correct or current.

Before you check the finished bundle, do you expect a correct file count and one successful retrieval to prove the entire study file is quality-ready?

  • Count the synthetic record files across the populated folders in Mock_eTMF_PHASE2.
  • Return to Expected_Documents in Excel.
  • Confirm that rows 2 through 13 contain twelve expected records.
  • Use the Folder_Path value for R-001 to locate 02_Protocol_and_Product in Google Drive.
  • Open the R-001 protocol record card from that folder.

You should count thirteen synthetic files in Google Drive. Rows 2 through 13 should contain the twelve expected records.

The R-001 card should display study ID MOCK-PH2-001, record ID R-001, document type Protocol, document date 2026-01-05, and version 1.0.

What the retrieval proves

The successful retrieval proves that the tracker can guide you to one expected record. It does not prove that every version, date, location, or duplicate status is correct.

That shortfall is intentional. The repository now looks populated while still containing gaps that require a repeatable quality check.

Cannot retrieve the protocol?

Confirm that the R-001 tracker row points to 02_Protocol_and_Product. Check that the protocol card was uploaded to that same folder.

Help me trace the missing protocol record.

Your first study file is populated and searchable. Next, you will test whether its visible completeness survives a formal quality check.

Run a TMF Quality Check

Your mock eTMF now contains the expected record set. A complete-looking file can still hide obsolete, mismatched, misplaced, or duplicated records.

A repeatable quality control review compares each Microsoft Word record card in Google Drive with its metadata in Microsoft Excel. The findings expose what the repository needs before it can support inspection-ready retrieval.

In this step, get ready to:
  • Review all twelve records against a document-level QC checklist.
  • Log four traceable findings with owners and due dates.
  • Calculate the three baseline TMF health measures.
Build the QC review structure

Document-level QC checks whether each record is usable and correctly controlled. Applying the same checklist to every record makes the review repeatable.

What does document-level QC test?

  • Identity confirms that the study ID and record ID match the tracker.
  • Document control confirms the document type, owner, date, and version.
  • Usability confirms that the record is readable and its required fields are complete.
  • Filing confirms that the actual folder matches the tracked folder path.
  • Lifecycle control confirms whether the record is current, superseded, or duplicated.
  • Switch back to MOCK-PH2-001_eTMF_Tracker.xlsx in Excel.
  • Select the QC_Findings worksheet.
  • Populate row 1 by pasting this header line into cell A1:
Issue_ID	Record_ID	Finding	Impact	Action_Owner	Date_Opened	Due_Date	Status	Resolution	Date_Closed

What do these columns capture?

The first eight columns identify the discrepancy and assign the follow-up work. The Resolution and Date_Closed columns preserve the eventual outcome.

Those final two fields remain empty while a finding has the status Open.

  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.
  • Confirm that cells A1:J1 begin with Issue_ID and end with Date_Closed.

Did the headers land in one column?

Undo the paste. Select cell A1 before pasting the tab-separated line again.

The tabs should place one header in each column from A through J.

Help me fix the QC header layout in Excel.

  • Return to the Expected_Documents worksheet.
  • Use Folder_Path in each row to locate the corresponding record card in the Google Drive repository from earlier.
  • Open records R-001 through R-012 one at a time.
  • Compare each opened record with its tracker row and the document-level checklist.
  • Compare SITE-001_IP_Receipt_Record_2026-02-05.docx with SITE-001_IP_Shipment_Receipt_2026-02-05.docx.
  • Keep every record in its current folder during this review.

That review has done its job. Four hidden discrepancies are now visible without changing the source records.

Reconcile the repository and log the gaps

A QC finding converts an observation into traceable follow-up work. Its ID, impact, owner, due date, and status make the discrepancy visible until remediation is documented.

How is each discrepancy proven?

  • The R-005 card shows version 1.0. Its expected tracker version is 2.0.
  • The R-004 card shows 2026-02-01. Its tracker metadata shows 2026-01-31.
  • The R-002 file is stored in 01_Trial_Management. Its expected folder is 02_Protocol_and_Product.
  • The two R-008 files contain the same record under different filenames.
  • Return to the QC_Findings worksheet.
  • Select cell A2.
  • Populate the four open findings by pasting these rows:
QF-001	R-005	R-005 is version 1.0, while the expected current template is version 2.0.	High	Sponsor	2026-06-15	2026-06-19	Open
QF-002	R-004	R-004 shows 2026-02-01 on the record but 2026-01-31 in tracker metadata.	Medium	Clinical Research Associate	2026-06-15	2026-06-18	Open
QF-003	R-002	R-002 is filed in 01_Trial_Management instead of 02_Protocol_and_Product.	Medium	Clinical Research Associate	2026-06-15	2026-06-17	Open
QF-004	R-008	R-008 has two content-identical files under different names.	Low	Site Pharmacist	2026-06-15	2026-06-17	Open

What does the findings log show?

Each row links one record to a specific discrepancy and a fictional action owner. The due dates create a visible remediation timeline.

The High, Medium, and Low impacts are project-created training labels. They carry no regulatory threshold.

  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.
  • Filter the Status column to Open.
  • Confirm that the filtered rows contain QF-001 through QF-004.

You should see four open findings. Each one points to a different document-control gap.

Are the findings split across the wrong columns?

Undo the paste. Select cell A2 before pasting the four tab-separated rows again.

Confirm that Issue_ID contains the finding IDs. Confirm that Status contains Open.

Help me correct the QC findings columns in Excel.

Calculate baseline TMF health

TMF health measures turn the review into a concise status view. Completeness measures expected records filed as current, while the QC pass rate measures records that passed the review.

  • Return to the Expected_Documents worksheet.
  • Set the Filing_Status for R-005 to Missing/Obsolete.
  • Confirm that the other eleven records retain Filed in Filing_Status.
  • Filter Filing_Status to Missing/Obsolete.

You should see only R-005 in the filtered view.

  • Clear the Filing_Status filter.
  • Set QC_Status to Fail for R-002, R-004, R-005, and R-008.
  • Set QC_Status to Pass for the remaining eight records.
  • Filter QC_Status to Fail.

You should see the four records linked to the open findings.

  • Clear the QC_Status filter.
  • Switch to the TMF_Health worksheet.
  • Select cell A1.

Before you calculate the baseline, which metric do you expect to show the largest gap?

  • Populate the three health measures by pasting this table into cell A1:
Completeness	=COUNTIF(Expected_Documents!I2:I13,"Filed")/12
QC pass rate	=COUNTIF(Expected_Documents!J2:J13,"Pass")/12
Open findings	=COUNTIF(QC_Findings!H2:H5,"Open")

How do the health formulas work?

The completeness formula counts Filed records in column I. It divides that count by the twelve expected records.

The QC formula counts Pass results in column J. The final formula counts findings whose status remains Open.

  • Format cells B1:B2 as percentages with one decimal place.
  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.
  • Return to QC_Findings.
  • Filter Status to Open.

You should see QF-001 through QF-004.

  • Return to the TMF_Health worksheet.
  • Read the three calculated results.

You should see 91.7% completeness, 66.7% QC pass, and 4 open findings.

Do the health results look different?

Confirm that R-005 is the only record without Filed in column I.

Confirm that exactly eight records show Pass in column J. Confirm that all four findings show Open in column H.

Help me troubleshoot my TMF health formulas and source statuses.

You have turned a complete-looking repository into a measurable QC baseline with four traceable findings. Next, you will remediate each gap without erasing its history.

Remediate Findings and Report Health

Your eTMF review turned a file that only looked complete into four specific findings. You now have a clear starting point for remediation.

The tracker in Microsoft Excel becomes the control record for each fix. Silent replacement would erase the evidence that a problem was found.

This step preserves the historical records. It also links each corrective action to documented ownership before reporting the new TMF health.

In this step, get ready to:
  • Resolve all four QC findings while retaining the superseded or rejected records.
  • Close the findings before updating the TMF health dashboard.
  • Write a cross-functional status update that reports the completed actions.
Resolve the four findings without erasing history

A documented remediation connects each finding to a corrective action. The former state stays available so another reviewer can reconstruct what changed.

Why keep superseded records?

Superseded final documents help reconstruct the study history. Keeping R-005 version 1.0 shows which template was replaced by version 2.0.

The superseded folder plus the change log creates visible traceability in this simulation. Google Drive does not turn the workbook into a validated eTMF audit trail.

Start with R-005 because its replacement affects both completeness and version control. The current card must preserve the same synthetic study details while showing version 2.0.

  • In Microsoft Word, save a copy of Mock_Record_Card_Template.docx as R-005_Informed_Consent_Form_Template_v2.0.docx.
  • In Windows File Explorer, confirm that R-005_Informed_Consent_Form_Template_v2.0.docx appears beside the template.

You now have a separate version 2.0 record card. The original template remains unchanged for future records.

  • Copy the unchanged study ID, record ID, document type, lifecycle phase, owner, document date, sign-off status, and training statements from the existing R-005 card.
  • Set the Version field to 2.0.

The copied card now represents the expected informed-consent version for R-005.

  • Update the Status field to show that version 2.0 is the current filed record.
  • Save R-005_Informed_Consent_Form_Template_v2.0.docx.
  • Review the saved card to confirm that it shows SIMULATION ONLY, record ID R-005, and version 2.0.

That is a careful fix. R-005 now has a distinct current version without changing the reusable template.

  • Upload R-005_Informed_Consent_Form_Template_v2.0.docx to 03_Regulatory_and_Ethics.
  • Open the uploaded file from 03_Regulatory_and_Ethics to confirm that version 2.0 displays correctly.

Moving a former current record can feel risky. The superseded folder keeps version 1.0 available as historical evidence.

  • Rename the former R-005 version 1.0 card to R-005_Informed_Consent_Form_Template_v1.0.docx.
  • Move R-005_Informed_Consent_Form_Template_v1.0.docx to 08_Superseded_and_Rejected.
  • Confirm that version 2.0 remains in 03_Regulatory_and_Ethics while version 1.0 appears in 08_Superseded_and_Rejected.

The next two corrections align the tracker date with the record card. They also restore the protocol signature page to its expected filing location.

  • Return to the Expected_Documents worksheet in MOCK-PH2-001_eTMF_Tracker.xlsx.
  • Correct the R-004 Document_Date value from 2026-01-31 to 2026-02-01.

The R-004 tracker metadata now matches the date displayed on its record card.

  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.
  • Move the R-002 Protocol Signature Page from 01_Trial_Management to 02_Protocol_and_Product.
  • Confirm that R-001, R-002, and R-003 now appear in 02_Protocol_and_Product.

The duplicate R-008 file needs a disposition instead of deletion. Keeping the extra copy proves that the duplicate was identified before it was rejected.

  • Move SITE-001_IP_Shipment_Receipt_2026-02-05.docx from 05_Investigational_Product to 08_Superseded_and_Rejected.
  • Confirm that SITE-001_IP_Receipt_Record_2026-02-05.docx remains in 05_Investigational_Product.

Can't see the remediated files?

  • Refresh the Google Drive browser page to load the latest folder contents.
  • Check that the two R-005 filenames end with the correct version values.
  • Search for the exact filename if a moved record is missing from the expected folder.

Ask for help with the filing changes using this troubleshooting prompt.

The Change_Log converts those file movements into an explanatory trail. Each row records the previous state plus the new state.

  • Return to the Change_Log worksheet.
  • Add the headers Change_ID, Change_Date, Record_ID, Previous_State, New_State, Reason, and Performed_By.
  • Confirm that all seven headers appear across the first row.

Use sequential change IDs. Use fictional change dates that follow the finding dates.

  • Add one change row for the creation of R-005 version 2.0 plus the supersession of version 1.0.
  • Add one change row for correcting the R-004 date to 2026-02-01.
  • Review the first two rows to confirm that each explains its previous state plus its new state.
  • Add one change row for moving R-002 to 02_Protocol_and_Product.
  • Add one change row for retaining the extra R-008 file in 08_Superseded_and_Rejected with the disposition Rejected duplicate.
  • Review the completed log to confirm that it contains four traceable action rows.
  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.
Close the findings and update TMF health

A corrected file does not close its related finding by itself. The findings log needs a factual resolution plus a close date before the dashboard can report zero open issues.

  • Return to the QC_Findings worksheet.
  • Enter a factual Resolution for each row from QF-001 through QF-004.
  • Enter a fictional Date_Closed for each resolved finding.
  • Review all four rows to confirm that every resolution matches the action recorded in Change_Log.

The findings now explain how each gap was resolved. Their open status still keeps them in the dashboard count.

  • Set the Status for QF-001 through QF-004 to Closed.
  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.

Before you check, what do you expect the open-findings formula to display now?

  • Return to the TMF_Health worksheet to check the open-findings result.

You should see 0 open findings. The completeness and QC pass values remain at their baseline until you update the expected-document statuses.

  • Return to the Expected_Documents worksheet.
  • Change the R-005 Filing_Status from Missing/Obsolete to Filed.

All twelve expected records now have a current filed record in the controlled taxonomy.

  • Change the QC_Status for R-002, R-004, R-005, and R-008 from Fail to Pass.
  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.

Before you check the dashboard, do you expect every metric to show its remediated target?

  • Return to the TMF_Health worksheet to check the existing formulas.

You should see 100% completeness, 100% QC pass, and 0 open findings.

That closes the operational loop. The repository state, findings log, expected-document tracker, and health metrics now tell the same story.

  • Add the comparison headings State, Completeness, QC Pass, and Open Findings to an empty area of TMF_Health.
  • Add a Baseline row with 91.7%, 66.7%, and 4.
  • Review the baseline row to confirm that it matches the values captured before remediation.
  • Add a Remediated row with 100%, 100%, and 0.
  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.

The before-and-after table now shows the measurable effect of the remediation work.

Metrics still show baseline values?

  • Check that every expected row uses the exact filing value Filed.
  • Check that every expected row uses the exact QC value Pass.
  • Check that every finding uses the exact status value Closed.

Use this troubleshooting prompt to diagnose a remaining mismatch.

Write the cross-functional TMF status update

A health dashboard gives the numbers. A cross-functional status update explains the issues, ownership, corrective actions, remaining risks, and next review date.

Keep the update concise enough for a fictional study team to scan. Every claim should trace back to the tracker or repository.

  • Return to Microsoft Word.
  • Create a blank document for the cross-functional status update.

You should see a blank Word document ready for the report.

  • Save the document as MOCK-PH2-001_TMF_Status_Update.docx.
  • Add SIMULATION ONLY at the top of the document.

The report is now clearly separated from real clinical-trial documentation.

  • Address the update to the fictional Clinical Trial Manager, Clinical Research Associate, and Site Pharmacist.
  • Create a four-row findings summary for QF-001 through QF-004 with each owner, due date, and completed action.

The findings section should account for all four issues. Each row should match the corresponding resolution in QC_Findings.

  • Add the current metrics of 100% completeness, 100% QC pass, and 0 open findings.
  • Add the next fictional review date.

The update now reports the current file health plus the next control point.

Keep the risks honest

Use remaining risks that genuinely apply to the simulation. The non-validated training environment plus the need to control future document changes are appropriate examples.

  • Add a short remaining-risks section based on the current simulation.
  • State that all data and names are fictional.

The report now distinguishes a transparent training simulation from production eTMF experience.

  • State that the document is a training simulation.
  • Save MOCK-PH2-001_TMF_Status_Update.docx.
  • Upload MOCK-PH2-001_TMF_Status_Update.docx to 07_QC_and_Inspection_Readiness.

Before the final check, do you expect the status update and tracker to report the same health state?

  • Return to TMF_Health to confirm 100% completeness, 100% QC pass, and 0 open findings.
  • Switch back to 07_QC_and_Inspection_Readiness in Google Drive.
  • Open MOCK-PH2-001_TMF_Status_Update.docx to confirm that it loads without an access or format error.

You should see the fictional recipients, four documented findings, completed actions, current metrics, remaining risks, next review date, and simulation limitations.

Can't open the status update?

  • Check that the upload has finished before opening the file.
  • Confirm that the filename ends with .docx.
  • Confirm that the file appears inside 07_QC_and_Inspection_Readiness.

Use this troubleshooting prompt to investigate the file problem.

What should be true now?

  • R-005 version 2.0 is current in 03_Regulatory_and_Ethics.
  • R-005 version 1.0 is retained in 08_Superseded_and_Rejected.
  • R-004 uses the tracker date 2026-02-01.
  • R-002 is filed in 02_Protocol_and_Product.
  • The extra R-008 file is retained with the disposition Rejected duplicate.
  • The tracker contains four change rows plus four closed findings.
  • All twelve expected rows show Filed plus Pass.
  • TMF health shows 100%, 100%, and 0 with the baseline comparison preserved.
  • The cross-functional status update is saved in 07_QC_and_Inspection_Readiness.

Your mock file is complete, reconciled, and supported by a visible remediation trail. Next, you will test whether those healthy metrics translate into fast record retrieval during an inspection-readiness drill.

Complete an Inspection-Readiness Drill

Your mock eTMF now reports 100% completeness. It also reports 100% QC pass with zero open findings.

Inspection readiness also depends on retrieving the right record through its tracker path. This drill tests that workflow under a timer.

In this step, get ready to:
  • Prepare the Inspection_Request sheet for four requested records.
  • Retrieve each record through its tracker path while recording timing evidence.
  • Publish the inspection-readiness summary as editable Microsoft Word and shareable PDF files.
Prepare the inspection request log

The Inspection_Request worksheet turns each retrieval into structured evidence. Microsoft Excel captures what was requested plus how you found it.

  • Switch back to MOCK-PH2-001_eTMF_Tracker.xlsx from earlier.
  • Select the Inspection_Request worksheet tab.

How should the columns be arranged?

  • Column A is Request_ID.
  • Column B is Requested_Record.
  • Column C is Request_Time.
  • Column D is Tracker_Path.
  • Column E is Retrieval_Time.
  • Column F is Elapsed_Seconds.
  • Column G is Version_Checked.
  • Column H is Outcome.
  • Column I is Notes.
  • Enter the column layout across row 1.
  • Confirm that cells A1 through I1 display the nine headers.

What does each evidence field prove?

  • The request time establishes when the inspection-style request began.
  • The tracker path proves that you used the index instead of browsing from memory.
  • The retrieval time captures when the requested record became available for review.
  • The version check proves that the opened record matches the current tracker entry.
  • The outcome records whether the retrieval met the request.
  • The notes preserve context for any delay or improvement action.

Which records are being requested?

  • Request IR-001 identifies the current protocol record R-001.
  • Request IR-002 identifies the ethics approval letter R-004.
  • Request IR-003 identifies the current informed-consent template R-005 v2.0.
  • Request IR-004 identifies the investigational product accountability log R-009.

The timing fields stay empty until the drill begins. This keeps planned requests separate from measured retrieval evidence.

  • Populate four request rows using the request mapping above.
  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.
  • Confirm that IR-001 through IR-004 appear in the request log.
Run the timed retrieval drill

The tracker should lead you directly to each current record in Google Drive. The two-minute target is a project-created learning benchmark.

Before you start the timer, do you expect all four tracker paths to lead directly to the current records?

  • Start a timer for the four-record request.
  • Enter the starting time under Request_Time for all four rows.
  • Switch to the Expected_Documents worksheet.
  • Locate the row for R-001.
  • Copy its Folder_Path value into the matching Tracker_Path cell.
  • Return to the Mock_eTMF_PHASE2 repository from earlier.
  • Use the recorded folder path to locate R-001.
  • Open the current protocol record card.

Keep the timer running across the request bundle. Each retrieval time then shows how quickly that record became available after the same request began.

Capture the evidence immediately

Record each result as soon as its file opens. Immediate recording prevents the elapsed times from becoming estimates.

  • Enter the time when R-001 opened under Retrieval_Time.
  • Calculate the elapsed time in seconds under Elapsed_Seconds.
  • Record the opened version under Version_Checked.
  • Record whether the file opened with the expected identity under Outcome.
  • Repeat the tracker-led retrieval cycle for R-004.
  • Repeat the tracker-led retrieval cycle for current R-005 v2.0.
  • Repeat the tracker-led retrieval cycle for R-009.
  • Stop the timer after the fourth record opens.

You should have opened R-001 v1.0. You should also have opened R-004 with document date 2026-02-01.

The other current records should be R-005 v2.0 and R-009 v1.0. Each row should contain its measured elapsed time.

  • Enter Within project benchmark in Notes for each retrieval completed within two minutes.
  • Document the reason in Notes for each retrieval that exceeded two minutes.
  • Add one improvement action to each missed row.
  • Save MOCK-PH2-001_eTMF_Tracker.xlsx.

That is a meaningful result. Your tracker now demonstrates record retrieval with measured evidence instead of relying on a healthy dashboard alone.

Did a tracker path lead to the wrong file?

Compare the recorded path with the matching Expected_Documents row. Make sure you followed the current filing location.

If R-005 v1.0 opened, return to 03_Regulatory_and_Ethics for current R-005 v2.0.

Help me diagnose a tracker path or current-version mismatch in this mock eTMF drill.

Create the inspection-readiness summary

The summary connects your repository structure with the evidence produced during QC. The editable source preserves the document for later updates.

The final static file gives you a consistent version to open or share. The transparency statement keeps your simulation experience accurately framed.

  • Return to Microsoft Word from earlier.
  • Create a blank document.
  • Save it locally as MOCK-PH2-001_Inspection_Readiness_Summary.docx.

You should see MOCK-PH2-001_Inspection_Readiness_Summary.docx in the Word title bar.

What must the summary contain?

  • The Study Profile identifies fictional Phase II study MOCK-PH2-001.
  • The Repository Map explains the eight-folder taxonomy.
  • The QC Method explains the document-level review and expected-record reconciliation.
  • The Four Findings section covers QF-001 through QF-004.
  • The Remediation Evidence section explains the retained history and four change-log entries.
  • The Before-and-After Metrics section compares 91.7% completeness with 100% completeness. It also compares 66.7% QC pass with 100% QC pass plus four open findings with zero.
  • The Inspection Results section summarizes the four timed retrievals and any improvement actions.
  • The Skills Demonstrated section covers Clinical Research, eTMF / Documentation, Operational Skills, and Technical Skills.
  • The Outcome paragraph says: This simulation provided practical exposure to how an eTMF can be structured, maintained, reviewed, and quality-checked during a clinical study, while strengthening documentation discipline, attention to detail, organizational skills, and understanding of clinical trial operations.
  • The transparency statement says: Self-directed eTMF workflow simulation using synthetic records. This project does not represent use of a validated production eTMF and contains no participant data.

Make the evidence easy to scan

Use a clear heading for every required section. Place the baseline and remediated metrics in a compact table.

Keep the findings connected to their resolution evidence. That structure makes the quality story easy to follow.

  • Write the summary using every required section above.
  • Save MOCK-PH2-001_Inspection_Readiness_Summary.docx.
  • Confirm that each required section appears in the document.
  • Confirm that the transparency statement appears exactly as provided.
  • Return to 07_QC_and_Inspection_Readiness in the Google Drive repository from earlier.
  • Upload MOCK-PH2-001_Inspection_Readiness_Summary.docx.
  • Confirm that the Word summary appears beside MOCK-PH2-001_TMF_Status_Update.docx.
  • Return to the Word summary.
  • Create its PDF version using Word's PDF export option.
  • Name the exported file MOCK-PH2-001_Inspection_Readiness_Summary.pdf.
  • Return to 07_QC_and_Inspection_Readiness.
  • Upload MOCK-PH2-001_Inspection_Readiness_Summary.pdf.
  • Confirm that both inspection-readiness summary formats are listed.

Is the PDF missing or failing to open?

Check that the PDF export finished before uploading the file. Confirm that the filename ends with .pdf.

If the uploaded file still fails to open, export a fresh copy from the saved Word source.

Help me troubleshoot exporting or opening my inspection-readiness PDF.

Before the final check, do you expect the tracker and both summary formats to tell one consistent inspection-readiness story?

  • Switch back to MOCK-PH2-001_eTMF_Tracker.xlsx from earlier.
  • Confirm that Inspection_Request contains four completed evidence rows.
  • Return to 07_QC_and_Inspection_Readiness.
  • Open MOCK-PH2-001_Inspection_Readiness_Summary.docx.
  • Confirm that the Word summary contains the required transparency statement.
  • Open MOCK-PH2-001_Inspection_Readiness_Summary.pdf.
  • Confirm that the PDF opens without an access or format error.

You should see four completed retrieval rows for R-001 through R-009 as requested. You should also see the editable Word summary and its matching PDF in the inspection-readiness folder.

You have closed the evidence loop. Your simulation now shows organized filing, documented remediation, measured retrieval, and transparent career framing.

Secret mission

Process a Protocol Amendment Without Breaking the File

An approved protocol amendment can affect several linked records at once. Build a controlled amendment package that updates the current file without losing its previous versions or retrieval trail.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep your mock eTMF available, archive it for later, or delete it entirely. This project creates no paid cloud resources or ongoing charges.

Resources you used:

  • The restricted Google Drive repository Mock_eTMF_PHASE2 contains the synthetic records, tracker workbook, status update, Word and PDF inspection-readiness summaries, retained history, and linked amendment package.

Keep everything running

No action is needed. Choose this option if you want the repository ready for more practice or interview preparation.

  • Keep the repository's General access set to Restricted.
  • Retain MOCK-PH2-001_Inspection_Readiness_Summary.docx beside MOCK-PH2-001_Inspection_Readiness_Summary.pdf so the editable source remains available.
  • Share only MOCK-PH2-001_Inspection_Readiness_Summary.pdf when you need a portfolio artifact.
  • Keep all synthetic record cards inside Mock_eTMF_PHASE2 so the evidence trail stays complete.

Pause - I'll come back to this later

There are no running processes to shut down. Pausing means preserving a local backup while keeping the restricted repository available for later practice.

  • Select Mock_eTMF_PHASE2 in Google Drive.
  • Use the download option to save a local backup to the location chosen by your browser.
  • Rename the Google Drive repository to ARCHIVED_SIMULATION.
  • Confirm its General access remains Restricted.
  • Stop editing the archived copy until you resume the simulation.

Delete - I don't want to use this again

This removes only the synthetic training repository. It does not affect real study or participant data.

  • Select Mock_eTMF_PHASE2 in Google Drive.
  • Open the selected folder's menu.
  • Choose the option that moves the selected folder to Google Drive trash.
  • Open the trash area in Google Drive.
  • Select Mock_eTMF_PHASE2 in the trash area.
  • Choose the permanent deletion option if you intend to erase the repository completely.

That clears the online copy once Google Drive confirms deletion. Local downloads remain separate on your Windows computer.

  • Press the Windows key to open Windows search.
  • Type File Explorer into the search field.
  • Press Enter to open Windows File Explorer.
  • Search Windows File Explorer for Mock_eTMF_PHASE2.
  • Delete each local copy of the repository shown in the results.

Nice Work!

Nice Work!

You did it! You built an inspection-ready mock eTMF workflow for fictional Phase II study MOCK-PH2-001. Your finished simulation demonstrates document control without overstating production-system experience.

What you learned:

  • Built a structured mock eTMF covering study start-up, conduct, and closeout records. You organized synthetic records by lifecycle phase while keeping the repository restricted.
  • Applied document QC and remediation to identify obsolete content, mismatched metadata, incorrect filing, and duplicate records. You preserved traceability while moving TMF health from the baseline to 100% completeness, 100% QC pass, and zero open findings.
  • Completed a timed inspection-readiness drill using tracker-based retrieval. You also produced a transparent portfolio summary that separates this training simulation from validated production eTMF experience.
  • Secret Mission: Managed a linked protocol amendment package with an updated informed-consent template. You retained superseded versions while preserving change-log links, QC evidence, health metrics, and retrieval history.

Ready to quiz yourself?