Importing & reconciling cases

Most surgeons already have years of cases sitting in hospital settlement sheets and eLogbook exports. You don’t have to retype them. Import a file and the app brings the cases in, matches their procedure names to a standard list, and — where a hospital’s own record confirms them — marks them verified.

To start an import, use the Import a spreadsheet link on your case list.

What an import brings in

A hospital settlement sheet or an eLogbook export brings in patient names, MRNs, and — where the sheet carries them — the billing and earnings figures, all at once. Every identifying and financial value is scrambled on your phone, with your backup password, as it comes in, so nothing readable about a patient or your earnings ever leaves the device.

Re-uploading the same file is safe: the app recognises cases it already has rather than duplicating them. This now holds even when a re-uploaded row is a day or two off the date you first recorded — a patient already in your logbook, matched by their hospital number around the same date and the same operation, updates the case you already have instead of becoming a second copy. On that match the app fills in only a missing name, age, or sex; it never changes the operation, the date, or any earnings figure. (A genuine second, different operation for the same patient on a nearby date is still kept as its own case — see Why a few duplicates can exist below.) And a case that arrives without a patient name isn’t a dead end — its name gets filled in later, through Reconcile or the next settlement sheet that covers the same MRN.

Importing a logbook without patient names

Many surgeons keep a personal logbook — an eLogbook export, or their own Excel sheet — that records the hospital number (MRN), date, and operation, but no patient names. These import fine. Each case comes in with its MRN and shows as “Unnamed” on your case list; nothing is made up to fill the gap.

The names arrive later, on their own: when you import a hospital settlement sheet that covers the same patients, the app matches each case by its MRN, fills in the name, and confirms the case at the same time. The import preview tells you up front how many cases will come in unnamed, so there are no surprises.

Filling in all the missing names at once

If you’d rather not wait for a settlement sheet — and you have the names in your EMR — Reconcile lets you do the whole batch in one pass, by spreadsheet. On the reconcile page, download a sheet of the cases that still need a name. It lists exactly those cases — each with its MRN and date — and three empty columns: Name, Sex, and Age.

Open it alongside your EMR, fill the three columns down the sheet, and upload it back — either on the reconcile page or through the bulk Import screen. The app recognises its own filled-in sheet and quietly matches every row in the background, so you’re never asked to line up columns. Every name, sex, and age lands on the right case in a single pass — no case-by-case typing.

A few things worth knowing:

The MRN is the key, and it stays fixed. Each row is matched to its case by the MRN that’s already on the sheet — the same thread the app uses everywhere — so a name can’t land on the wrong case. Leave the MRN column untouched.
Empty cells are left empty. Filling in only the names? Leave Sex and Age blank and nothing is touched there. A blank cell never clears a value that’s already on the case, and a filled cell only fills an empty field — your existing entries always win.
It’s safe to re-upload — it can only ever update names, never create cases. Bring the same completed sheet back in again and nothing changes; cases that are already named are simply recognised, not re-written. Because this is a sheet the app exported, re-uploading it can only update the cases it already has — it can never add new ones. If the app ever can’t recognise it as your own export (for example, you deleted its hidden columns), it stops with a clear message rather than risk creating duplicates.
There’s a “do not edit” column you can ignore. The sheet carries one internal key column the app uses to match each row back to its case. It’s pushed out to the far right, away from where you type, and its header says do not edit — leave it alone whether you open the file in Excel or Google Sheets. It’s also what tells the app the sheet is your own export, so keeping it intact is what guarantees a re-upload only updates names.
It’s scrambled on your device, as always. Every name, sex, and age is encrypted on your phone with your backup password as it comes back in — exactly as a settlement-sheet import is — so nothing readable about a patient ever leaves the device.

This is the quickest way to clear a long list of “Unnamed” cases when the names live in your EMR rather than on a sheet you can import.

Why a few duplicates can exist — and clearing them safely

Sometimes the same operation reaches the app twice. The usual reason is that the same case is recorded differently in your two sources: your eLogbook keeps your own clinical wording for the procedure, while the hospital settlement sheet carries the billing label — and when the app standardises that billing label it can occasionally land on a different (even wrong) procedure name. Same patient, same date, two slightly different-looking rows. Re-uploading a sheet through an older import screen could do it too.

This is by design, not a flaw: the app would rather let a duplicate through — where you can see it and clear it — than ever refuse a genuine case because it looked similar to one already there. A patient who really did have two procedures on one day, both sides operated (a bilateral case recorded as two rows), or a case re-entered under a corrected hospital number are all legitimate, and a strict “no two alike” rule would wrongly reject them. So the app keeps your record complete first, and gives you a safe place to remove the genuine duplicates by hand.

That cleanup lives under Settings → Remove duplicate cases. Tap Check for duplicates and the app shows you a reviewable list of what it found. Each group lists every copy of the patient — with the name and MRN, the date, the operation, and whether the case has earnings attached — and each copy has its own tick box, so you choose exactly which one (or ones) to remove and keep the rest.

That per-copy tick box lets you keep two and remove one where that’s right: a bilateral case where you operated both sides is two real procedures, so if one of them was logged twice you tick only the extra copy. The names are unlocked and read on your own device — the same way your Cases list shows them — so they match what you already see there; a case that genuinely has no name entered shows “(name not entered)“.

How the finder groups copies:

It matches by hospital number (MRN), read on your device — the same way your Cases list reads it: the encrypted number first, and if that’s empty, the copy held on your device. So the duplicates you can plainly see on the Cases list are the ones it matches. Because the matching happens on your phone, where the real hospital number can be read, it works even when those copies look different to the server.
A slightly different name spelling is caught — near-identical spellings are grouped, not split.
A duplicate hospital record (the same hospital appearing twice in the system) is caught.
A different procedure name across your two sources is caught too — the operation name is treated as a hint for your review, not a wall that splits the pair.
For a case with no hospital number at all, it matches on the name instead.

Every group is labelled so you know how confident the match is — and how its copies start out ticked:

Confident match — same patient, same date, same operation. The extra copy starts ticked for removal; untick it to keep both.
Needs your review — same patient, but two different operations on the same (or a close) date. This is the case that’s either “one operation recorded twice under two names” or “two real procedures in one sitting” — only you can tell. Nothing starts ticked: you tick only a copy that’s really a duplicate. (A genuine bilateral case is protected automatically — its rows can never be ticked.)
Dates far apart — review — the same patient appearing again much later (a year-apart re-import, or a mistyped date). Nothing starts ticked; tick only a copy you judge to be a duplicate.

A triplicate (three copies of one case — it happens) is labelled as such; tick each extra copy you want to remove. Where a group has more than one copy, a Select all copies shortcut ticks them together. The case being kept as the original is never offered for removal, and bilateral rows can never be ticked. If a group isn’t really a duplicate, just leave its copies unticked.

You can clear duplicates two ways:

One group at a time, right where you’re looking. Once you’ve ticked the extra copies in a group, tap its Remove button and confirm the quick “Remove N copies?” prompt. Only that group’s ticked copies go, the group disappears at once, and there’s no scrolling to the bottom of the list.
Several groups in one pass. An action bar pinned to the bottom of the screen stays in view as you scroll, always showing a live tally — N to remove · M kept — with a single Apply all. Because that commits everything you’ve ticked across the whole list at once, it asks you to type REMOVE there first.

After a removal runs, your case counts and Insights correct themselves straight away. Removals can be recovered from the database if ever needed, so it’s safe to run.

When a “needs your review” group is genuinely two real operations — not a duplicate at all — tap Keep both — not a duplicate on that group (when a group holds three or more copies the same control reads Keep all). The group disappears, and it stays gone: the next time you check for duplicates that pairing won’t come back to pester you, even after new sheets arrive. This is the opposite of REMOVE — nothing is deleted; you’re only telling the app these two cases are distinct, so both are kept and the app stops flagging them. (If a new, different operation later lands for the same patient, that fresh pairing can still surface for you to judge — only the pairs you’ve already cleared stay cleared.) The app remembers this with nothing more than the two cases’ internal reference codes — no name, number, or anything readable ever leaves your device.

If two copies sit under genuinely different hospital numbers — for example one was typed with a digit dropped (1380716 vs 138076) — that isn’t a duplicate to merge here; it’s a wrong number to correct. Open the case and use Correct MRN instead, which re-links the record cleanly. The finder flags these near-miss numbers so you can route them to the right place rather than puzzle over why they didn’t group.

If a pair you expected to match isn’t grouped, open the small “Why might a duplicate be missed?” panel under the result. It lists, for each case, the hospital number the finder used, where it read it from (the encrypted field or the copy on your device), the simplified operation name, the date, and the match key the finder built. Two cases now group on the patient’s hospital number (or name) and a close date — the operation name no longer splits them — so if a pair you expect to pair still shows different keys, that panel tells you which field (the number, or the date) differs: usually a genuinely different hospital number (correct it with Correct MRN, above) or dates too far apart to be a confident match. It shows no names you haven’t entered and no internal record ids.

Bringing in a standard eLogbook export

A standard eLogbook export is the same kind of file — anonymised, no patient names, just the hospital number, date, and operation — but it carries a lot more clinical detail per case. The app reads all of it and files it on the case:

The date. eLogbook stores dates as plain numbers (a “serial” like 43038). The app recognises these and turns each one back into a real date, so your cases land in the right month and year.
Your role. The Supervision column — Performed, Assisted, Supervised, or Observed — sets whether you were the primary surgeon, the assistant, or observing, and whether you operated independently or under supervision.
The side. Left, right, or bilateral, decoded from the export’s own coding.
Notes and complications. The operation notes (including any “Diagnosis:” line) come in as the case notes, and any complication note is filed as the complication.
Age and sex. Brought in and shown quietly beside the case, exactly as with a hospital sheet. Sex you didn’t record (a “U” in the export) is simply left blank.
ASA grade, urgency, and supervising consultant. These don’t have their own boxes yet, so the app tucks them into the front of the case notes — something like “ASA 1 · CEPOD 1 · Supervising consultant OM13943” — rather than dropping them. The eLogbook Consultant column is the consultant under whose name the case sat (a trainee’s responsible consultant), not the operating surgeon — so it’s preserved as a note, never filed as the surgeon.

A few things worth knowing:

It merges with your hospital records. Because the export carries the hospital number, an eLogbook case for the same patient lands on the same case as your hospital settlement records — the eLogbook fills in the clinical history, and a settlement sheet fills in the name and confirms the case. The two halves of each case find each other automatically, in whichever order they arrive.
The same hospital, by any of its names. If your hospital has been renamed over the years, the export may carry an older name (for example “KIMS Oman Hospital” for what is now KIMSHEALTH Oman). The import shows you which of your existing hospitals it’s filing under so you can confirm it — and remembers the old name, so it resolves on its own next time. This keeps a renamed hospital from splitting into two.
It comes in unconfirmed — and that’s intended. An eLogbook is your own record, so its cases are trusted for their clinical detail but not treated as confirmed: confirmation still comes only from a hospital settlement sheet. An export marked “Validated” in eLogbook stays unconfirmed here too — that tick is a consultant’s sign-off, a different thing from the hospital’s financial record we confirm against.
Re-importing changes nothing. Bring the same export in again and the app recognises the cases it already has rather than duplicating them.

The import preview shows you the mapping it worked out — which column became which field — so you can confirm or adjust it before anything is brought in.

How procedure names are matched

When you import a spreadsheet, the procedure names in it are usually the hospital’s billing wording — “ORTHO ORIF FRACTURE PKG” rather than the clinical name. In the background, the app matches each of these names to its standard procedure list, so your imported cases read like a clinical record and count properly in your case mix.

Three things to know:

The hospital’s original wording is always kept. A matched case shows the procedure in your own terminology — the wording the app has learned from your dictated cases, or a sensible default for where you practise (see Capturing cases for how that works and how to change it under Settings → Procedures). On the case page, the name from the standard list appears quietly beneath as “standardised as: …”, and the hospital’s original line beneath that in grey: recorded by hospital as: ORTHO ORIF FRACTURE PKG. Nothing is ever silently replaced.
If a match is wrong, fix it from the case. Open the case, tap the procedure, and pick the right one from the list. The app then asks how far your fix should reach — this case only, or all your cases recorded under that billing name. More on the choice below.
If the app isn’t sure, it doesn’t guess. A name it can’t confidently match is simply left exactly as the hospital recorded it. The import summary tells you how it went: “41 of 43 procedure names matched automatically · 2 left as recorded.” A glance, not a gate — nothing waits on you.
Close relatives are decided carefully, not quickly. Operations in the same family read as almost the same words — every “arthroplasty”/“replacement”, every “fusion” — so when a billing name’s two closest matches are siblings that differ only by which joint or site (a patellofemoral vs a total knee replacement), the quick text match steps back and hands the decision to the more careful check rather than freeze a confident-but-wrong sibling. If even that can’t be sure, the name is left exactly as the hospital recorded it. This is why a knee-replacement billing line is never quietly stamped as the wrong knee procedure.

Procedure names you’ve set yourself are never changed by any of this. Your wording always wins, on imported cases too.

Which version wins?

Sometimes two sources describe the same case differently — your own logbook says “ORIF distal radius”, the hospital’s billing sheet says “ORTHO ORIF FRACTURE PKG”. The rule is simple, and it always favours the surgeon:

Anything you typed or dictated yourself is never changed by an import. Not by your own logbook, not by a hospital sheet. Ever.
Your own logbook beats billing wording — automatically. When you import an eLogbook export or your personal Excel sheet over cases that originally came from a hospital billing sheet, your wording for the procedure, side, and site quietly replaces the billing version on the matched cases — no question asked per case. The preview tells you how many cases will be updated, and the new name is matched against the standard procedure list just like any other.
Two of your own records that disagree ask you. If a case already carries your wording — typed in, or from an earlier logbook of yours — and a new sheet of yours says something different, that’s a real disagreement, and you settle it with one tap.

Re-importing the same logbook again changes nothing — once your wording is on a case, it stays. None of this affects how a case gets confirmed: confirmation still comes only from a hospital settlement sheet, however good your own logbook’s wording is.

What the case list shows

Your case list shows the matched procedure name — the standard clinical name, shown plainly, because a matched case is the normal state. A billing name the app couldn’t match stays exactly as the hospital wrote it and appears dimmed, so the few unmatched ones stand out at a glance instead of hiding among hundreds of cases. The list itself is for reading only; to fix a name, open the case.

Reviewing your procedure names

Four years of imports usually come down to a few dozen distinct billing names — so the quickest way to audit your record is by name, not case by case. Settings → Procedures lists every billing name from your hospitals, side by side with:

the procedure it maps to,
how many of your cases it covers, and
how it was set — matched automatically, set by you, or set by a colleague at your hospital.

The screen is split into two lists. It opens on Unmatched — the billing names that still need your eye — with Matched collapsed beneath it. The counts in the two headings tell you how much is left, so you can stop a review halfway and pick up later exactly where you left off. The moment you confirm or correct a name, it moves to Matched. When Unmatched reaches zero, you’re done — new names appear there only after your next import.

Suggested matches. When the app isn’t sure enough about a match, it does not apply it to your cases. The name waits in Unmatched with the app’s best suggestion pre-filled. One tap confirms the suggestion — and fills in the cases that were waiting on it — or you can pick a different procedure instead. Either way, nothing touches your cases until you decide. A name the app left as recorded because its two closest matches were same-family siblings (the close-relatives case above) is shown here with that reason noted, so you know it was held back on purpose for your eye rather than missed.

“Auto-matched — check it.” Names the app matched automatically before this update appear once in Unmatched for a quick look-over. Your cases keep their match the whole time — confirming just tells the app you agree, and the name then stays in Matched for good. If a match is wrong, correct it — the fix reaches every case recorded under that name, as always. Names you set yourself, and names matched from your own dictionary, don’t need re-checking and stay in Matched.

Tap a name to correct it. A correction made from this screen always applies to all of your cases recorded under that billing name — the confirmation tells you exactly how many — and the same name matches correctly on every future import. One screen audits your whole history.

When one billing name means different operations

Some billing names are catch-alls. “K-WIRING OF ANY FRACTURE” might be a wrist one week and an ankle the next — there is no single right answer for it.

When you correct a case like that, choose “This case only.” That fixes the case in front of you without touching the others, and it teaches the app something important: this billing name varies by case. From then on the app stops matching it to a single procedure — future imports leave it as recorded (dimmed on your list) so you can set each case yourself, and Settings → Procedures shows it under Matched as varies by case, with a breakdown of which procedures your cases under that name actually were. It sits in Matched, not Unmatched, because there’s nothing pending on it — each case is set on its own.

Choose “All cases recorded as …” only when the billing name really does mean one procedure and the match was simply wrong.

When one billing name covers several procedures

Some billing names describe a combination — “ACL Reconstruction, ORTHO- Partial Meniscectomy” is two procedures in one sitting, every time. In Settings → Procedures you can map a name like that to all of them: the first procedure is the main one; add the others beneath it, just as you would on a case. Applying the correction then writes the complete set onto every case recorded under that name — the main procedure on your case list, the rest listed with it — and every future import gets the full set automatically.

This is the opposite of a catch-all: a combination name means the same set of procedures every time, while a catch-all means different things case by case — that one still shows varies by case and is fixed on each case.

As always, cases whose procedures you’ve set by hand yourself are never changed by a correction made here.

Age and sex from your hospital sheets

If your hospital sheet carries the patient’s age, sex, or date of birth, an import brings them in with the case. They appear quietly next to the patient’s name — on the case list and on the case page — as something like “45 · M”. Sex is shown exactly as your sheet recorded it; when a case has no age or sex recorded, nothing is shown at all.

Already imported your sheets before this existed? Re-import the same files once: existing cases fill in their missing age and sex, and nothing you have entered is ever overwritten or duplicated.

One patient, one set of details

Because one hospital number means one patient, the app now keeps that patient’s details consistent across all of their cases. If one of a patient’s cases has the name, age, or sex and another — the same hospital number — is blank, the blank one is filled from its populated twin automatically the next time you unlock the app. Nothing you’ve entered is changed: a value that’s already there is never overwritten with a different one.

The one exception is a genuine disagreement. If two cases under the same hospital number carry different names, ages, or sexes, that is a red flag — often a one-digit typo in the number, which can mean two different real patients quietly filed together. Rather than silently merge them, the app leaves both untouched and surfaces them for your review under Settings → Reconcile patient details, with a link straight to Correct the hospital number so you can split a mistyped number cleanly. Gaps are filled; disagreements are flagged.

If a lot of cases land on the same date

When you import, the app keeps an eye on the dates. If an unusually large number of cases come in on a single date — say dozens on one day — the preview shows a small amber heads-up before you apply: “⚠️ N cases fall on that date — this usually means the date column wasn’t read correctly; check the mapping.”

It’s almost always a sign that the spreadsheet’s date column wasn’t read the way you expected, so it’s worth a quick look at the mapping before you import. But it’s only a heads-up — it never blocks the import. If it really was a busy day, or you’re happy with the import as it is, go ahead.

This check runs entirely on your device and looks at nothing but the dates — it never sees a patient’s name or any other detail.

How a confirmed case differs from an unconfirmed one, and what “Lost in reset” means, is covered in Where your data lives. For capturing a case yourself, see Capturing cases.