Linking Returning Patient Visits

At treatment hubs and GP-style clinic settings, athletes and patients often attend more than once — across different days or venues. This feature lets you identify a returning patient, link their visits together, and read their complete prior history without leaving the current record.

Overview

When a patient's date of birth and sex are entered on a job, IndieBase automatically checks whether anyone on the same team has been seen before with the same demographic details. If a match is found, a badge appears in the Patient Details panel so you can review it and decide whether it's the same person.

Once visits are linked, a Previous Records panel appears in the sidebar. You can open any prior visit and read the full patient report — observations, drugs, interventions, and all — in read-only view. The history is transitive: if a patient has been linked across five visits, all five appear together.

This feature is designed for continuity of care. Because it gives access to records beyond the normal information-governance window, every action — revealing a name, accepting a link, dismissing a match, and un-linking a visit — is recorded in the audit log.

Before You Start

• You need an Admin or Member role on the team. These roles include the linked-history permission.
• The job must have a patient record with at least Date of Birth and Sex filled in. Without both, no match check is performed.
• Viewing prior visit details requires an active internet connection. The Previous Records panel shows a "Linked history unavailable offline" message if you're offline.

How IndieBase Spots a Possible Match

You do not need to do anything to trigger the match check — it runs automatically in the background as soon as Date of Birth and Sex are entered on the Patient Details panel.

If one or more prior patients on the same team match those demographics, a Possible match (N) badge appears in the top-right corner of the Patient Details panel header. The number shows how many candidates have been found.

The badge is non-intrusive: it does not interrupt your documentation or create a popup. You can complete the rest of the record first and review the match whenever it suits.

Reviewing a Possible Match

Tap the Possible match (N) badge to open the match review dialog.

The dialog shows:

• This visit (left panel) — the current patient's date of birth, sex, and postcode.
• Prior visit (right panel) — the same fields from the matched previous record. Fields that match the current patient are highlighted in green. Fields that differ remain in the standard colour.
• Prior visit context — the date, event name, and venue for the previous visit, so you can tell at a glance when and where the patient was last seen.

Postcode is shown for comparison but is not required for a match to be suggested. Matches are identified on date of birth and sex alone. The postcode highlighting is an additional check to help you verify identity.

Multiple Candidates

If more than one prior patient matches the demographics, the dialog shows Match 1 of N and cycles through each candidate after you accept or dismiss the current one.

Revealing the Name to Verify

The prior patient's name is hidden by default. This is a deliberate information-governance safeguard — you should only access a prior patient's name when you genuinely need it to confirm identity.

To confirm you're looking at the right person, tap Reveal name to verify.

The prior patient's name is then displayed. At this point you can compare it with the name the patient has given you for the current visit.

This action is audited. Revealing a name is recorded in the system audit log against your account, along with the date, time, and which patient record was accessed. This is a minimum-necessary access control — the audit trail exists to ensure name disclosures can be reviewed if needed.

You do not have to reveal the name before making a decision. If the match keys (DOB, sex, postcode) and the prior visit context are sufficient to confirm or rule out a match, you can proceed without revealing the name.

Linking or Dismissing the Match

Once you've reviewed the match, you have two options at the bottom of the dialog:

Same person - link visits

Tap Same person — link visits to confirm the match.

Before you link: an amber warning at the bottom of the dialog reads "Linking shares this patient's full medical history across visits." Make sure you're confident in the match before proceeding.

Once linked, the current patient and the prior patient are associated together. A Previous Records panel appears in the sidebar showing the number of linked prior visits.

Not the same - dismiss

Tap Not the same — dismiss if the match is not the right person. This dismisses the suggestion for this specific patient combination and prevents it from reappearing. The current job is unaffected.

Reading Prior Visit History

Once visits are linked, the Previous Records panel appears in the sidebar. Tap it to open the panel.

The panel header reads All prior visits (N), where N is the number of linked prior visits.

Each prior visit appears as a row showing:

• The event name and venue (or "Visit" if no event name is available)
• The visit date

Tap a row to expand it and load the full patient report for that visit in read-only view.

The prior record is read-only — you cannot edit it from here. The patient's name and address are not shown in prior visit reports (they are masked server-side to preserve minimum-necessary access).

Visits You Cannot Open

Occasionally a row may appear as a grey locked placeholder instead of an expandable visit. This happens when a linked visit exists but you don't have permission to open it — for example, if it was recorded by a different team configuration or access has been restricted.

The placeholder is shown so you know the visit exists, even though its contents are not accessible to you.

Un-linking a Visit

If a visit was linked in error, you can remove the link from the Previous Records panel. Each prior visit row has an Un-link button.

1. Tap Un-link on the visit you want to remove.
2. A confirmation dialog appears, explaining that the action is audited and can be reversed later.
3. Tap Un-link visit to confirm, or Cancel to close without making changes.

Important: un-linking removes the visit from the shared history going forward, but it does not erase the fact that you viewed the prior record. If a wrong link was made and you already read the prior history, this should be reported through your normal incident-handling process so the disclosure can be logged appropriately.

Tips & Best Practices

• Fill in DOB and Sex early. The match check won't run until both are present. Entering them at the start of the job gives the system time to find matches before you've finished the rest of the record.
• Use the Prior visit context to orient yourself. The event name, venue, and date in the match dialog are often enough to confirm or rule out a match without needing to reveal the name — especially if the patient attended recently and you recognise the event.
• Reveal the name only when you need it. If the match keys are already unambiguous, there's no clinical reason to reveal the name. Keeping reveals to a minimum is good information-governance practice.
• Expanding a prior visit loads it from the server. If your connection drops while you're reviewing history, you may see a "record unavailable offline" message. Reconnect and tap the row again to reload.
• Check Prior Records before prescribing. For treatment-hub settings, reading the prior visit history is particularly useful for drugs and allergies. The Drugs panel from prior visits will show what was given previously.

Troubleshooting

The "Possible match" badge isn't appearing even though I know this patient has been seen before. The match check requires both Date of Birth and Sex to be filled in on the current job. Make sure both fields are saved. If they are and the badge still doesn't appear, the prior record may belong to a different team, or the demographics may not match closely enough. You can also try refreshing the page to re-run the check.

The match dialog closed before I could review all the candidates. If you accept or dismiss all the candidates in sequence, the dialog closes automatically. Any remaining accepted links are shown in the Previous Records panel. If you accidentally dismissed the wrong candidate, the system will not re-suggest that pairing automatically — contact your team admin if you need to re-link manually.

The Previous Records panel says "Linked history unavailable offline". Prior visit history is fetched from the server and cannot be cached for offline use. Return to the panel once you have a connection.

A prior visit shows as a locked placeholder. This means the visit is linked but your account doesn't have permission to open it. Speak to your team administrator if you believe you should have access.

I linked the wrong patient by mistake. Tap Un-link on the incorrect visit in the Previous Records panel and confirm. The link will be removed and the action audited. If you already viewed the prior history before realising the error, follow your team's incident-handling process to report the unintended access.

Related Features

• Filling In the Patient Record — working through all clinical panels on the current job
• Marking a Job as Done — completing and closing the patient record