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. 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.

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 standard procedure name, with the original line beneath it 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.

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.

“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.

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.