An outreach sync should preserve the question it cannot answer

Intermittent connectivity is often discussed as a problem of getting records from one place to another. That is part of the problem, but reconnection can create a second question: how should an arriving entry relate to what is already present? If a system treats transport success as the end of the process, it may hide a discrepancy at the moment the discrepancy becomes visible. I want synchronisation to preserve that uncertainty until somebody with the appropriate responsibility can resolve it.

At Fervali Hearing Services, a review of eighty-four outreach visits identified six duplicate entries. The entries had arrived, but their relationship to existing records required review. Some matching fields made automatic merging look attractive. A technical rule could reduce the visible queue quickly and save colleagues from examining cases individually. The question was whether those fields supplied enough authority to decide that the entries belonged together. I did not believe IT could make that professional decision merely because the data appeared similar.

Our support team favoured a matching rule for the known duplicates because the review queue was taking time from other work. Clinical director Rehana Veshmali wanted the disputed entries considered by clinical owners before their relationship changed. I supported that approach and accepted a slower route to closure. The decision gave up an immediate reduction in the queue in exchange for a record decision made by the appropriate people, with the technical team responsible for presenting the evidence clearly.

## Transport and interpretation need different evidence

We funded ₹36 lakh of synchronisation and reconciliation work. The technical design made origins and review status clearer. The service process assigned responsibility for decisions about disputed records. These were related changes, but they answered different questions. IT could show that an entry had arrived from a particular activity and that it remained under review. The clinical owner could examine what the entry meant and decide how it should relate to the existing record.

The distinction helped us avoid a misleading definition of completion. A successful sync meant the transfer had completed under the relevant technical checks. It did not mean every record question created by that transfer had been resolved. The system needed to show both states without making the service team infer one from the other. A single green indicator would have been simpler to display, but less faithful to the work that remained.

This is not an argument against automation. Automation can make relevant evidence easier to compare, flag a potential conflict and route it to the right owner. It can also carry out a decision once the appropriate authority and conditions are clear. The difficulty arises when a rule quietly moves from helping identify a question to deciding an answer it is not qualified to supply. That boundary should be discussed explicitly rather than discovered after an automatic action has altered the record.

The reviewed population also limits the claim. We reconciled the six identified duplicates within the eighty-four-visit review. That does not show that every future outreach entry will be unique, or that another setting could use the same matching criteria. The case establishes a response to a defined finding. A credible report should retain that scale, even when the method suggests useful questions for a wider service.

I learned to ask what the user can see while the review remains open. If a disputed entry appears indistinguishable from a settled record, colleagues may rely on it without knowing its status. If the warning is too broad or difficult to interpret, they may stop paying attention. The design needs a service explanation of the uncertainty, its owner and the next action. That is more useful than simply adding another technical error label to a screen.

Ownership must also be workable. Naming a professional role without providing time or a route to review can leave the queue permanently unresolved. The process needs to account for availability, escalation and the circumstances in which another qualified person can act. IT can support those arrangements, but it cannot create professional capacity merely by assigning a task in software. The operating cost of review belongs in the decision alongside the cost of the synchronisation work.

## A resolved exception should leave a trace

After reconciliation, the record should retain an understandable account of what happened. A future colleague may need to know why entries were linked, separated or corrected. Removing every sign of the original uncertainty can make the system look cleaner while making later investigation harder. The appropriate record of the decision depends on the service and its obligations, but the principle is practical: resolution should improve understanding, not erase the path by which the answer was reached.

That record is also useful for learning. If similar exceptions recur, the team can examine whether the cause lies in the outreach process, the interface, the transfer or the review criteria. Without a trace, recurring problems may look like unrelated support tickets. A service can then spend time resolving the same type of uncertainty repeatedly without recognising the pattern. The goal is not to collect detail for its own sake; it is to preserve enough context to improve the work.

For directors, the relevant question is how management distinguishes a transported record from a trustworthy basis for the next decision. That wording does not require directors to become database specialists. It asks management to explain the boundary between technical checks and professional interpretation. The board can then consider whether the owners, resources and escalation routes are appropriate for the service's responsibilities and the consequences of an unresolved discrepancy.

Our outcome was deliberately limited. The six known duplicates were reconciled through a process with clinical ownership, and the system made the status and origins easier to examine. We did not attach a clinical-benefit claim to that result. We also did not treat the absence of another identified duplicate at the checkpoint as proof that the problem could never recur. The value lay in a clearer and more accountable response to the question we actually found.

I now see reconnection as a handoff rather than a finish line. The technical link brings records together; the organisation must still decide what any conflict means. A well-designed system makes that distinction visible and supports the people entitled to resolve it. That is especially important when a service works across places, schedules and professional roles. The sync should carry the record faithfully, including the question that remains, instead of supplying an answer simply to make the queue disappear.