Every word in LaraScan, explained.
LaraScan is a teleradiology platform: it carries a medical imaging study from the scanner in a clinic to a radiologist anywhere, and carries a signed report back. This reference explains every concept on that road — in plain words, with the reasoning behind each decision.
01What is LaraScan
One loop, guarded at every step.
Many imaging centres own scanners but not radiologists. Many radiologists can read for ten centres without visiting any of them. LaraScan is the road between the two, and everything it does serves one loop:
The platform's character in one sentence: constraints live in the database, not in good intentions. A signed report physically cannot be edited. A price physically cannot be rewritten. A study is billed once, ever. Whenever a rule matters, LaraScan enforces it at a level no application bug can reach.
02Who's who
Four nouns carry the whole platform: organizations, sites, devices, and people.
Organization
The legal party — a company. Every organization has a type that decides which side of the loop it lives on:
| Type | Meaning | Example |
|---|---|---|
imaging_center | Owns scanners, sends studies, receives reports, pays invoices. | Technoscan |
reading_group | A group of radiologists who read for others and sign reports. | Cairo Teleradiology Group |
both | Does both — a chain with its own reading department that also sells reads. | — |
A freelance radiologist is simply a reading group with one member — they can contract with any number of centres at once.
Site
A physical branch of an organization — “Technoscan, Mohandessin”. Sites matter because a chain is one organization with many branches, and studies are attributed to the branch that produced them. Each site holds its own gateway token, the credential its uploads authenticate with.
Device
One machine inside a site — an ultrasound cart, a CT scanner. Devices exist so that every study can honestly answer “which machine sent you?”. A study whose device cannot be identified is quarantined, never guessed at.
People and roles
A person is one account with an email; what they can do comes from memberships — “this person, in this organization, with this role”. One person can belong to several organizations (the freelancer model).
| Role | What it means |
|---|---|
radiologist | Reads studies and signs reports. The only role that opens images in the ordinary course of work. |
org_admin | Runs the organization: team, coverage (in a reading group, this is the coordinator), sites and devices (in a centre). |
technologist | Operates the scanners at a centre. |
front_desk | Reception at a centre. |
referring_physician | The doctor who ordered the scan. |
Above all organizations sits the platform administrator — LaraScan staff. Deliberately not a role anyone's org_admin can grant: it lives on the account itself. And deliberately not a reader: a platform admin cannot open patient images without breaking glass.
03The three doors
Three separate portals, one per audience, each with its own front page and its own sign-in.
| Portal | Path | Who | What's inside |
|---|---|---|---|
| The reading room | /reading | radiologists & coordinators | dashboard, worklist, coverage, team |
| The centre | /centre | imaging centre staff | dashboard, sent studies, access log, sites, devices, invoices, team |
| The operations desk | /platform | LaraScan staff | everything: organizations, studies, quarantine, contracts, billing, pricing |
Two absences are the design, not gaps. There is no viewer in the centre portal — the centre owns its studies and sees everything recorded about them, but looking at images is reading work, done inside the reading workflow where every access is on the record. And a coordinator sees every queue without being able to open a single study — watching that a study is late is a scheduling job; opening it is a clinical one.
04Speaking DICOM
The imaging world has its own language. Here is all of it that LaraScan uses.
- DICOM
- Digital Imaging and Communications in Medicine — the universal file format and network protocol of medical imaging. Every scanner on earth speaks it. A DICOM file carries the pixels and, in the same file, hundreds of labelled facts: patient name, study date, machine model.
- Study / Series / Instance
- The three-level hierarchy of DICOM. A study is one visit — “Mrs Martinez's carotid ultrasound on 21 Aug”. A series is one pass inside it. An instance is one file — usually one image. A real carotid study here is one US series of 28 images plus an SR.
- UID
- Unique identifier — long dotted numbers like
1.2.840.113619…that name every study, series and instance globally and forever. LaraScan trusts UIDs, never file names. - Modality
- The kind of machine:
USultrasound,CT,MR,CR/DXX-ray,MGmammography. Contracts, coverage and prices can all be scoped by modality. - PACS
- Picture Archiving and Communication System — the imaging store. In LaraScan the PACS holds pixels and serves them over DICOMweb; it holds no notion of who owns a study. Ownership, access and billing all live in LaraScan's own database.
- AE title
- Application Entity title — the short name a DICOM node announces
itself with on the network. LaraScan's gateway answers to one AE title:
LARASCAN. - C-STORE
- The classic DICOM network operation: “here is an instance, store it.” It is what a scanner does when a technologist presses send.
- DICOMweb — QIDO, WADO, STOW
- The modern, web-native face of DICOM. QIDO-RS searches (“what series does this study have?”), WADO-RS retrieves pixels, STOW-RS stores. LaraScan's viewers speak DICOMweb through an authenticated keyhole — never to the PACS directly.
- SR — Structured Report
- A DICOM file that carries measurements and findings instead of pixels — “peak systolic velocity, right CCA, 85 cm/s”. Ultrasound machines write one automatically; the advanced viewer writes one when a radiologist saves measurements.
- Accession number / MRN
- The centre's own order number for a study, and the patient's Medical Record Number in that centre's files. Both travel inside the DICOM tags.
05A study's journey
From the scanner's send button to “ready to read”, with a state recorded at every step.
The gateway is a small LaraScan program installed inside the clinic.
To the scanner it looks like any DICOM destination (AE title
LARASCAN); technologists change nothing about how they work. The
gateway receives each C-STORE, spools it locally — so a bad internet day
loses nothing — and uploads every instance over HTTPS, authenticated by its
site's token. If the cloud is unreachable, it holds its queue and retries;
an instance is only dropped from the queue after the cloud has confirmed
storage.
Ingest happens per instance: LaraScan verifies the bytes are genuine DICOM, stores them in the PACS, and creates or updates the study record — owner (the site's organization), source site, patient facts, modality. Ownership is set once, on first sight, and never moves.
Completeness is the question most systems skip: did everything arrive? A study is a folder of files; losing three of thirty images is silent unless somebody counts. LaraScan counts. Each study carries an ingest state:
| State | Meaning |
|---|---|
| receiving | Instances are still arriving. |
| validated | Counts agree everywhere; the study may be read and reported. |
| incomplete | Fewer instances than expected. Shown, never hidden. |
| quarantined | The sending device could not be identified — see below. |
A poller watches the PACS change feed every minute; an hourly reconciler re-checks everything the poller might have missed. Only a validated study can be opened or reported — reading half a study is how findings get missed.
06Quarantine
Nothing is ever dropped silently. It lands here instead.
The site token proves which site sent a study; the device is resolved from the calling AE title, or trivially when the site has exactly one machine. When neither works, the study is quarantined — never silently attributed to the wrong machine, and never discarded. The old world's failure was a clinic asking on WhatsApp whether their study had arrived, with no answer possible; quarantine is that answer, as a page in the platform panel.
Release is one button — Re-check & release — and it never force-flips state: it re-attempts the same device attribution rule the ingest uses, then re-runs the same validator every study goes through. If the device still cannot be named, the study stays put and the admin is told exactly what is missing.
07Contracts & routing
Who reads for whom is a written agreement between organizations, never an arrangement between individuals.
A reading contract says: Centre X's studies, in these modalities, go to Reading Group Y, with a report due within this many hours. The moment a matching study finishes arriving, it is assigned to the group automatically. The centre never picks a person; which of the group's radiologists opens the case is the group's own business.
Routing has one iron rule: never guess. A study that matches two active contracts is assigned to neither — it surfaces as needing a human routing decision, because sending a patient's scan to the wrong company is worse than a short delay. The same rule governs the backlog: a freshly created contract immediately claims studies that arrived before it existed — but only the unambiguous ones.
Coverage is the layer inside the group: the coordinator declares who is expected to read what — by modality, by site. A new radiologist starts covering everything; the Coverage screen narrows it. Coverage is what a radiologist's worklist is built from, and it is written by the coordinator, not by the radiologist — what you are on the hook for is the group's decision.
SLA — the clock on the contract, from one hour (stat) to 72. The worklist sorts by it, dashboards show the oldest waiting case, and a study running late is the single most important thing on a coordinator's screen.
08The worklist & claims
The radiologist's queue, and the lock that keeps two doctors off one case.
The worklist shows each radiologist exactly the studies their coverage says they should see — nothing else exists for them, enforced in the database itself. Alongside the ingest state, every study carries a read state:
Claiming is automatic and invisible: opening a study claims it, and a claimed study shows as taken to everyone else. Read state only ever moves forward — re-opening a signed report is a visit, not a regression. Release puts a case back in the queue; take over transfers it from a colleague who went home without releasing — deliberately a separate, recorded action, so recovering a stuck case is a decision somebody made, with a record of who took what from whom.
09The viewers
Two viewers, one keyhole, and a bridge that saves retyping numbers.
The basic viewer opens instantly for a quick look. The advanced viewer is OHIF — the leading open-source radiology viewer: window/level, cine, measurements, and more. Both reach pixels the same way: through LaraScan's DICOMweb keyhole, a proxy that checks this person may read this study on every request. The PACS itself is never exposed; the keyhole accepts a handful of read shapes and exactly one write.
That one write is Create SR: measurements made in the advanced viewer are saved back into the study as a Structured Report. The keyhole genuinely parses every byte before letting it pass — it must be an SR, and it must belong to the study named in the URL.
The measurements bridge closes the loop: in the report editor, one
button — Pull measurements — reads every SR in the study (the
machine's own and the viewer's) and lays each value into the Findings box
with its anatomical address: Right, Common Carotid Artery, Distal —
Peak Systolic Velocity: 85.01 cm/s. Prefill, not autopilot: the
doctor edits freely, and signing stays entirely their act. Retyping is how
6.2 becomes 6.5 in a signed medical document; the bridge makes the number
in the report the number measured on the image.
10The report
The product the whole platform exists to deliver.
A report is three sections of prose — Technique, Findings, Impression — prefilled from a template per modality. The impression is required to sign: it is the sentence the referring doctor acts on.
Signing is the moment everything changes. The exact content on screen is what gets signed (never a stale draft). From that instant:
- The report is frozen by a database trigger — no role can edit or delete it, the platform included. Medicine and law both require that the document the centre received is the document that was signed.
- The signer's name is copied onto the row as it was that day — accounts get renamed; documents must say who signed then.
- A sha-256 fingerprint of the content is computed, stored, and printed on the PDF — any copy can be checked against the record.
- The centre can collect the branded PDF, the billing ledger accrues, and the doorbell rings.
Corrections are addenda — new signed, dated entries appended to the original, never edits of it. One primary report per study, enforced by the database: the referrer needs a single document of record, and disagreement is an addendum with a signature, not a second truth.
Two gates, deliberately different: writing a report requires per-study reading access, like the viewers. Collecting the PDF requires only that the study is yours — the centre cannot open the images and must receive the report, because that is the entire point.
11Notifications
An email that is a doorbell, never a report.
The moment a report (or addendum) is signed, the owning centre's admins get a branded email: accession, modality, date, site, signer, and a button into the portal. Deliberately nothing clinical and no patient name — email is not a channel anyone controls end to end, so clinical content stays behind the sign-in and the email only announces it.
Signing never fails because an email could not be sent: the notification is queued after the state change, fenced off from the medical act.
12The money
Integers, append-only prices, a frozen ledger, and invoices that are voided — never edited.
The signature is the billable event. The report is the product, so signing writes exactly one ledger entry per study — a unique database index makes a second one impossible, forever. Addenda are corrections to a product already delivered and are never billed. In-house reads never accrue.
Money is integers. Amounts are stored in minor units (piastres, halalas, cents); floating point appears nowhere. Multi-currency from day one: the currency rides on every priced row.
Prices are append-only. A price says: this contract, this modality (or the fallback), from this date, this many minor units of this currency. Changing a price means writing a new row with a later effective date — the old row explains every invoice ever computed from it, so the database refuses to update or delete it outright. Resolution picks the row naming the modality over the fallback, then the most recent.
An unpriced read blocks its month. A study signed before a price was agreed accrues with empty amounts, and invoicing refuses the whole month until it is priced. Skipping it would drop money; zeroing it would give work away — both quietly wrong, so neither is possible.
Invoices are generated per centre, per month, per currency —
numbered sequentially (LS-202608-0001), rendered as a branded
PDF where every line is backed by a signed report. A wrong invoice is
voided: its entries return to the pool, the month regenerates under
a new number, and numbers are never reused. A daily reconcile sweep
accrues anything signing missed and prices anything that accrued early —
idempotent by construction, safe to run forever.
13Teams & invitations
Organizations run themselves; the platform only opens the door.
Onboarding a new customer touches no terminal: the platform creates the organization and adds its first admin from the Members tab. From then on that admin runs their own Team screen — inviting radiologists and staff, suspending and reactivating memberships.
- A new account never has a password anyone else chose. The invitation email carries a set-your-own-password link into the invitee's own portal. The admin never knows, picks, or transmits credentials.
- An existing account simply gains a membership — a radiologist reading for two groups is the freelancer model working.
- Leaving is suspension, never deletion. A suspended membership revokes access instantly, but the name stays on every report it ever signed — nobody is ever erased from history.
- Resend has manners: at most once per 24 hours, and once the invitee sets their password the button disappears for good — forgot-password on the sign-in page is their path from then on, no admin involved.
14Security by construction
The guarantees that hold even when the application is wrong.
Row-level security (RLS)
Tenant isolation is enforced by PostgreSQL itself: every query runs with
the caller's identity attached, and the database returns only the rows
that identity may see. A forgotten where clause in application
code leaks nothing, because the leak is stopped a layer below. This is why
a dashboard widget or a list screen here carries no scoping logic at all.
The audit log
Every meaningful act — a study arriving, being opened, claimed, signed, downloaded, invoiced — writes an append-only audit row with who, what and when. The audit table is frozen by the same trigger mechanism as signed reports. Centres see it too: Who accessed our studies is a page in their portal, not a promise.
Break glass
A platform administrator cannot open patient images — until they break glass: a per-study, time-limited access window that demands a written reason and shows that reason to the centre that owns the study. Support stays possible; silent browsing does not.
Content discipline
No patient identity or clinical content in any email. Tokens hashed at rest. The PACS reachable only through the authenticated keyhole. Passwords chosen only by their owners.
15Glossary A–Z
Every term in the platform, one line each. Terms explained at length above link back to their section.
- Accession number
- The centre's own order number for a study; printed on reports and invoices trace back to it.
- Addendum
- A signed, dated correction appended to a signed report — the only way a signed report ever changes. §10
- AE title
- The name a DICOM node announces on the network; the gateway answers to
LARASCAN. §04 - Assignment
- Which reading group a study is routed to, decided by exactly one matching contract — never by guessing. §07
- Audit log
- The append-only record of every meaningful act, frozen at the database. §14
- Break glass
- A written-reason, time-limited window that lets a platform admin see one study — visible to the study's owner. §14
- Claim
- The invisible lock a radiologist takes by opening a study, keeping colleagues off the same case. §08
- Completeness
- The verified answer to “did every image arrive?” — counted, not assumed. §05
- Contract (reading contract)
- The org-to-org agreement that routes studies: modalities, SLA, status. §07
- Coordinator
- The reading group's org_admin: sets coverage, watches queues and the clock — sees everything, opens nothing.
- Coverage
- Who in a group is expected to read what, by modality and site; the worklist is built from it. §07
- C-STORE
- DICOM's classic “store this instance” network operation — what a scanner sends. §04
- Device
- One machine at a site; every study must be attributable to one, or it quarantines. §02
- DICOM
- The file format and network protocol every medical scanner speaks. §04
- DICOMweb
- DICOM over HTTP: QIDO (search), WADO (retrieve), STOW (store). §04
- Doorbell
- The signed-report email: logistics and a button, never clinical content. §11
- Gateway
- The small program in the clinic that receives from scanners, spools locally, and uploads with the site's token. §05
- Ingest state
receiving → validated / incomplete / quarantined— has the study fully arrived? §05- In-house read
- A centre's own radiologist reading the centre's own study — no contract needed, never billed. §07
- Instance
- One DICOM file, usually one image. §04
- Invoice
- One centre's month in one currency, sequentially numbered, voided — never edited. §12
- Keyhole
- The authenticated DICOMweb proxy — the only road to the PACS, checked per request per study. §09
- Ledger entry
- One study's billable fact, written at signing, one per study forever, frozen at accrual. §12
- Measurements bridge
- The Pull measurements button: every SR value lands in Findings with its anatomical address. §09
- Membership
- Person + organization + role; suspension revokes it without erasing history. §02
- Modality
- The kind of machine: US, CT, MR, CR, DX, MG. §04
- MRN
- Medical Record Number — the patient's identifier in the centre's own files.
- OHIF
- The open-source advanced viewer integrated behind the keyhole. §09
- Organization
- The legal party: imaging centre, reading group, or both. §02
- PACS
- The imaging store: holds pixels, knows nothing about ownership. §04
- Platform administrator
- LaraScan staff; runs everything, reads nothing without breaking glass. §02
- Price
- An append-only row: contract, modality, amount in minor units, currency, effective date. §12
- Quarantine
- Where a study waits when its device can't be identified — visible, releasable, never silent. §06
- Read state
unread → assigned → in_progress → dictated → signed → addendum— forward only. §08- Reconcile
- The scheduled safety nets: studies re-checked hourly, money re-swept daily — idempotent, always safe.
- Release / Take over
- Returning a claimed study to the queue / transferring it from a colleague — both explicit, both recorded. §08
- Report
- Technique, Findings, Impression — signed, frozen, hashed, delivered as PDF. §10
- RLS
- Row-level security: PostgreSQL itself decides which rows each caller can see. §14
- Series
- One pass of one machine inside a study. §04
- sha-256
- The fingerprint computed at signing, stored and printed on the PDF, so any copy can be verified. §10
- Site
- A physical branch of an organization, holding its own gateway token. §02
- Site token
- The credential a gateway uploads with; re-issuing it deliberately cuts off the old one.
- SLA
- The contract's clock: how many hours until the report is due. §07
- SR
- Structured Report — a DICOM file of measurements, not pixels. §04
- STOW / QIDO / WADO
- Store / search / retrieve over DICOMweb. §04
- Study
- One patient visit: the unit of ownership, reading, reporting, and billing. §04
- UID
- The globally unique dotted identifier of every study, series and instance. §04
- Worklist
- A radiologist's queue — exactly what their coverage says, nothing more exists for them. §08