Tutorial ID | T-02 |
Section | Foundation |
Title | Uploading Records and Files Into a Case |
Subtitle | Upload files correctly the first time to avoid gaps and errors that surface later in your reports. |
Before You Begin
You have created the case in Case Chronology® that you want to upload files into.
You know whether any of your files are password-protected or larger than 5GB.
What You Will Accomplish
By the end of this tutorial, every file you upload will be complete and correctly batched. You will know how to catch a skipped or rejected file before it becomes a gap in a report, and how to tell an expected page-count difference from a genuine upload error.
Why Does this Tutorial Matter
Uploading is the first action taken on a new case, and it sets the foundation for everything the platform produces afterwards — the chronology, the report, the AI analysis. Catching a missing or misplaced file at this stage takes minutes to fix.
Miss it here, and the same gap resurfaces later as an inaccurate finding, a chronology error, or an omission that has to be traced back to its source at a much greater cost of time and effort. A disorganized or incomplete document set does not just slow down review — it undermines the accuracy of the AI output and the credibility of the final report.
What to Do if Something Goes Wrong
The list below covers the most common problems that happen during upload. Each entry follows the same pattern: what you'll notice, why it likely happened, a real example, and how to fix it.
Problem: A file was skipped during upload because it exceeded the 5GB size limit (the page count for a batch is lower than expected for the records you prepared).
Likely cause: The platform automatically skips any file larger than 5GB without always making this obvious.
Example: A single hospital file covering several years is submitted as one document over 5GB. The platform skips it, and the report reflects only part of the medical history.
Fix:
After the upload finishes, open the batch and check its page count.
Identify the file that appears to be missing and check its file size.
If the file is larger than 5GB, split it into smaller sections at a logical point, such as by month or treatment episode.
Name each section to show its content and its place in the original file, for example Hospital Records — Part 1 — January to June 2022.
Upload each section as its own batch and confirm its page count matches what you expect.
Once every section is uploaded, review the full document list and confirm it represents the complete original file.
Problem: A password-protected PDF or ZIP file was uploaded but was not accepted by the platform. (file does not appear anywhere in the case after upload).
Likely cause: The platform rejects password-protected .pdf and .zip files without always making the rejection obvious.
Example: A hospital sends a password-protected .pdf of imaging reports. The file is rejected on upload, and the gap isn't noticed until the report is missing those findings.
Fix:
Compare each batch's page count and note any file that seems to be missing.
Check whether the missing file is password-protected — this is the most common cause of a silent rejection.
Open the file using the correct password.
Save a new version of the file without password protection, and confirm it holds the full original content.
Upload the unprotected version to the correct batch and confirm its page count.
If you don't have the password, contact the provider and request the password or an unprotected copy.
Do not run workflows on the case until the file has been uploaded successfully.
Problem: Files were uploaded into the wrong batch. (a batch contains files that don't match the provider, document type, or date range you expect for it).
Likely cause: Files intended for one batch were accidentally added to another during a session with multiple batches.
Example: A specialist consultation report ends up inside a hospital records batch, and a reviewer later can't trace a statement back to its source without extra digging.
Fix:
Open each batch and check the provider name, document type, and date range of its files.
Identify any batch containing files that don't belong to it.
Delete the batch that contains the misplaced files.
Upload the batch again with the correct files.
Open the new batch and check the provider name, document type, and date range again.
Problem: The upload was completed, but the note that irrelevant pages may be removed was not communicated to the team. (a document looks shorter on the platform than it does in the original file.)
Likely cause: The platform removes pages it identifies as irrelevant, such as blank pages or cover sheets, and this wasn't communicated to the team.
Example: A reviewer notices a hospital file is ten pages shorter on the platform and spends an hour looking for an upload error that never happened.
Fix:
Compare the page count of each batch against the original files.
For each batch with a lower count, check whether blank pages, cover sheets, or separators explain the difference.
If the difference looks larger than expected, open the batch and compare it against the originals to identify the missing pages.
If relevant pages are missing, contact the platform support team before continuing.
Do not run workflows on a batch where relevant pages may be missing.
Tell the team about the page-count difference and confirm everyone understands this is expected behavior, not an upload error.
Tip Check batch page counts right after every upload session — catching a gap here takes minutes; catching it after a report has been generated takes much longer. |
Summary
Every file in your case is now uploaded and correctly batched — so the chronology, the report, and the AI analysis that follow are built on a complete document set.