Health authority correspondence is the most under-managed record class in regulatory operations. Approval letters, information requests, complete response letters, meeting minutes, deficiency notices — the documents that determine what you have to do next, typically living in a shared mailbox, a network folder, and somebody’s Outlook.

Organisations that fix this usually fix it twice, and the second time is the problem.

How you end up with two places

Nobody decides to build two systems of record. It happens like this.

The planning function needs correspondence, because a submission plan without the agency’s letters is a plan with the interesting parts missing. So a correspondence log grows inside the planning tool — modest, fit for purpose, and correct at the time.

Later, correspondence handling moves into the document management system properly: email intake, filing, categorising, linking to an application, all with the version control and audit trail document management already provides.

At which point the planning tool’s log stops receiving anything. It does not stop being read. The correspondence view reads it. Triage reads it. The by-application summary reads it. The calendar’s milestones read it. Draft-response generation reads it. The information-request extract reads it. Precedent search reads it.

Seven different screens, all reading a log that no longer receives letters. A second version of the truth, quietly going stale beside a register that is quietly filling up.

The failure is worse than duplication

Two copies of a record is a data quality problem. Two copies where one has silently stopped updating is something else entirely.

The stale log still displays. It still shows letters. Nothing about the screen says “these are the letters up to March and none since”. Somebody checking whether the agency has responded sees a list, sees nothing new, and concludes nothing has arrived.

An empty answer and a stale answer look identical to a reader, and they mean opposite things. This is the same failure that appears everywhere in this domain — a check that did not run looking like a check that passed, a search that failed looking like no results.

One register, one place to look

DnXT reads correspondence from a single register, presented to the planning screens in the shape they already expect. Everything above that — triage, the calendar, draft responses — keeps working unchanged.

The important detail is what a letter reference points at. It points at the document. So a commitment linked to a letter, or an information-request package built from one, points at the actual document, in the system that holds it, with its version history and audit trail attached — rather than at an entry in a side log that points at nothing.

Two things get better rather than merely relocated. Draft-response generation and the information-request extract read the letter’s own text from the document system, instead of a summary somebody typed when the letter was logged. And precedent search returns what was actually sent — outbound letters as filed — rather than what was recorded about them.

Actions follow the letter

Consolidating what people read is the easy half. What people do is where these migrations usually go wrong, because a screen with buttons that no longer work is worse than a screen without them.

  • Linking a letter to an application sets it in the document system, where the link belongs.
  • Logging correspondence by hand goes to the document system’s intake as a message to confirm and file — the same path an emailed letter takes, so a manually logged letter is not a second-class record.
  • Delete and status changes respond clearly and say where the letter now lives.

That last one matters. An action that has moved should say so. Silently accepting a change that goes nowhere is how you get people confidently reporting that they updated something.

The screen shows the register with an open-in-document-system action — and when the register cannot be reached, it says so rather than showing an empty log.

Migrate, never delete

The contents of an older log move across in a migration that previews by default.

Each letter carries a reference derived from its original entry, which makes the migration safe to run more than once — run it twice and the second run recognises what it already moved. Migrated entries are marked with a pointer to their new home and never deleted.

For GxP records this is not caution, it is the requirement. A retention obligation does not care that you built something better. The old entries remain, annotated with where their content now lives, and the audit trail records who ran the migration and when.

What consolidation actually buys

Once every letter is in one register, things become possible that were not:

  • Market registrations read from approval letters, rather than typed into a tracker.
  • “What the agency keeps asking.” Pool every information-request item by topic and by the substance of the question, and the same ask in different words on different programmes counts as one recurring thing.
  • Precedent that is real. “Have we answered this before?” answered from what you actually sent, rather than from memory.

None of those work across two places. All of them are straightforward across one.

The lesson is not that a second log is always a mistake — it is usually the right call when it is built. It is that the moment a second log stops receiving anything, the screens still reading it become the liability. The log is easy to find. The seven screens are not.

DnXT builds eCTD publishing, submission planning, document management and dossier review software for regulatory operations teams. Book a demo to see a single correspondence register wired into planning against your own submissions.