What's Your Workflow?: The Submission Document Chase That Runs Itself
Coordinating a regulatory submission is like running a switchboard. It is a problem of coordinating dozens of stakeholder teams that each hold one piece of the package, each of them working to their own deadlines on their own studies, and every one of them working towards a goal. What makes the job hard is that one person is holding more parallel contexts than can be tracked and handled efficiently, so all the coordination has to live in their head and their inbox, and that cascades into a process that works in abrupt bursts.
That’s the workflow we’re looking at in this second post of What’s Your Workflow? In the first post we walked through the landing zone, where the workflow handles CRO data intake and hands the data manager a single decision. This one is structurally similar, but the pressure arrives from a different direction. In the landing zone the data showed up on its own and the hard part was judging it. Here the coordinator has to ask for everything first, and then keep track of what they asked for and who is still working on it.
Why this doesn’t scale
Every study pulls documents from multiple stakeholder teams working to different schedules, and the coordination involved stops scaling somewhere past a handful of studies.
Every request gets written by hand, so the coordinator composes and sends individual asks to each team responsible for a piece of the package, and then has to remember who was asked for what and by when. That memory is effectively the tracking system. Then there’s the fact that nothing tells you when a file arrives. Files land in a shared drive with no notification attached, so the coordinator checks daily and sometimes more often. The alternative is discovering something is missing on the day it’s due.
Wrong files are the third problem, and they’re the expensive one, and they usually arrive from somebody doing their best with an ambiguous spec. A mislabeled or mismatched document can sit quietly in the shared drive looking perfectly reasonable until somebody happens to open it. The wrong drug name on a template, say, or a version left over from the previous study. Caught early that’s a five-minute fix, and caught late it costs days. Finally, the follow-ups all land on one person. As the deadline approaches, following up with teams who haven’t got to it yet and drafting clarification requests becomes a repetitive job, with no system tracking who still needs a prompt.
None of this is difficult work, but it takes up most of the week. A senior coordinator spends their week doing something a well-organised checklist could mostly handle. The judgment that needs them, meaning whether a file is right and whether to wait or escalate, gets squeezed into whatever gaps are left over.
The six steps
The workflow runs the collection loop from end to end and surfaces only the decisions that need the coordinator’s judgment. There are six steps.
Defining the ask (human). The coordinator provides one JSON file covering which teams are responsible for which documents, what their deadlines are, and any study-specific requirements. This is the only manual data entry anywhere in the workflow. The JSON is a demo simplification, picked to keep the example readable: in a real deployment this step could be a Cowork step where the coordinator talks the requirements through with an agent, or an upload of whatever the team already keeps this in, a Word document or a spreadsheet. Mediforce is customisable to a fault! You bring your way of working to it and it adapts.
Filling the request email (script). A markdown email template lives in the same repository as the workflow, with placeholders for study details, file specifications, and deadlines. The workflow fills them in from the JSON values.
Preview and approval (human). Nothing leaves on a single click. The coordinator reviews the filled-in template and approves it, and the workflow then sends a preview of the real email to their own inbox so they can read it the way a stakeholder would. After that it presents a summary of everyone it is about to contact, and only on a second approval does the request go out to all of them.
Watching the drive (agent). Once the request is out, an AI agent checks the shared drive every fifteen minutes for incoming files. It analyses what has been submitted and prepares a report covering what’s present, what’s missing, and whether the content looks right. In the demo an IMPD template arrives and the agent flags it, because the drug named on the label isn’t the paracetamol the study is actually running. The file is there, it’s the right document type, and it’s still wrong.
The decision (human). Reading the agent’s report, the coordinator picks one of three outcomes. Give stakeholders more time, trigger a deadline reminder, or flag a file that needs correcting. On either of the last two they also set when the follow-up should go.
The follow-up (agent). When that time arrives, an agent drafts a scoped, factual email, either a deadline nudge or a clarification request naming the exact issue, and sends it. For the mislabeled IMPD it writes up the incorrect label, the file that was submitted, and the correction required. The loop then goes back to watching the drive, and repeats until every file is in and correct, at which point the workflow closes out with a completion summary and what the run cost.
Where the human sits
Mediforce sets a control mode on every step, and this workflow makes a choice the landing zone one doesn’t.
The initial request email runs under human review, behind two gates rather than one. The coordinator approves the drafted text, reads it again as a preview in their own inbox, and then approves the recipient list separately before anything leaves the building. First contact with a dozen stakeholder teams isn’t a step you’d want the workflow completing on its own, since getting it wrong means a dozen confused replies and a credibility problem you spend the rest of the study quietly repairing. The drive monitoring is human review as well. The agent analyses what has arrived and prepares its report, and then the run holds, because the agent has no authority to decide a file is unacceptable. The wait, remind, or request-fix decision comes down to three buttons and one judgment call from the coordinator.
The follow-up emails are the interesting case, because they run as an autonomous agent. Once the coordinator has chosen “remind,” the agent drafts the email and sends it at the scheduled time without asking again, which is a deliberate step up and defensible for the reason that mode exists. A deadline reminder to a colleague is low-stakes and easily reversible, so if the tone lands slightly off you send another one. Set that against the first email, or against the accept decision in the landing zone workflow, and the difference in mode tracks the difference in consequence. One workflow ends up using three of the five modes, which is what setting them per step is for.
What the coordinator does instead
The time saving is the easy part to see, since the coordinator stops checking a drive every morning and stops writing the same reminder email for the fourth time this month. The change in where their attention goes is the larger one.
At the moment a submission coordinator’s expertise competes directly with clerical work for the same hours in the day. That expertise is knowing which teams tend to run late, which documents usually come back wrong and in what particular way, and when something needs escalating rather than letting it ride. The clerical work almost always wins that competition, because it has deadlines attached. So the expensive judgment ends up applied thinly and late. Move the clerical work into the workflow and every time the coordinator gets asked to do something, it’s a decision rather than a task.
Coverage is the other thing that changes. A person tracking a dozen studies in their head will let something slip eventually, and the slip won’t be random. It’ll be the study with the quietest stakeholders, because quiet reads as fine. Every package now gets the same checks on the same cadence, and the ones that are drifting surface before the deadline rather than during it. And the record comes free, in the form an auditor actually asks for, covering who was asked, when, what they sent, what was wrong with it, and what got sent back.
What this means for your workflows
If your submission process today runs on one person’s memory, a shared drive with no notifications, and a folder full of half-written email drafts, then the shape here transfers. Define the ask once in a file, let the workflow handle the sending, the watching, and the checking, and keep the human on the three-way decision and on the first email going out the door. Your stakeholder teams, file specs, and escalation policy are your own, and the config maps onto those.
Mediforce is open source under Apache 2.0, and this is one of the reference workflows.
Next in this series we move from operational workflows to the two entries Appsilon submitted to the CDISC AI Innovation Challenge, starting with reproducible synthetic SDTM built from a ClinicalTrials.gov ID.
Related reading
The rest of What’s Your Workflow?:
- The Landing Zone for CRO Data Deliveries
- The Submission Document Chase That Runs Itself (you are here)
- Synthetic SDTM From an NCT ID (coming soon)
- Traceable TFLs From Protocol to Table (coming soon)
Before this series I wrote a run of posts working through the AI concepts these workflows rely on. If any of the terminology here was new, start at the top:
- What Is an AI Agent? Skills, MCP, and Harnesses Explained
- The Four Ways to Use AI: Chatbots, Apps, Agents, and Workspaces
- How to Get Useful Answers from AI: Prompting and Context
- What Is RAG? How AI Answers From Your Own Documents
- The Four Levels of AI Autonomy: Observer, Advisor, Drafter, Executor
- Human-in-the-Loop AI: Oversight a Regulator Accepts
And on the platform itself:
- Introducing Mediforce v1.0.0: AI-in-the-Lead Workflows for Pharma
- Mediforce x Databricks: Human-in-the-Lead AI Workflows While Your Data Stays in Databricks
Book a live walkthrough. Tell us which stakeholder teams and file types are involved and we’ll show you how the config maps onto your submission structure. Thirty minutes, with the people who built it.
