Platform
Written down, because somebody has to keep it running.
This is the whole chain: what each program is, what it speaks, how the pieces find each other, and what each one does when the others are missing. Nothing here is a roadmap item.
Independence over integration
Seven programs rather than one, so a fault has a boundary.
Local first
Anything a technologist needs mid-shift is answered from the same building.
Refuse rather than guess
An unmatched study, an unmapped order code and an unknown sender are all refused by name and queued, never approximated.
Measure before shipping a fix
Every diagnosis in our runbook came from a number, not a theory.
Components
What each part is, and what it is not.
Pharos PACS — the archive
An imaging archive built on a proven open-source DICOM core with a PostgreSQL index, wrapped in our own explorer and application interface. Receives studies by C-STORE, serves them by DICOMweb, and handles authentication, roles, report storage, share links, query/retrieve against remote nodes, storage tiering, retention and export to CD or USB. It is authoritative for image data and for nothing else.
Pharos RIS — the record system
Bookings, the patient register, referrers, a per-branch price list with inheritance, payments, report workflow, staff and roles. It issues the medical record number, the accession number and the study instance UID, and it is the only component permitted to do so. Multi-tenant: a scan centre is a business, a branch is a building, and rows belong to exactly one centre.
NextRad viewer — diagnostic review
Window and level presets per modality, multiplanar and oblique reformats, measurement and annotation that survive reorientation, volume rendering hand-off for CT angiography and bone work, and patient age, sex, technique and estimated dose burned onto the display where a reader expects them. Opens from the explorer or from a signed link out of the record system.
Edge agent — the thing that saves the day
One small service on the site. It answers the modality worklist from a local cache, books walk-ins when the uplink is down, and watches the archive for completed studies to report upward. It is the reason a site keeps scanning through an outage, and the reason nothing has to be repaired afterwards.
Reporting desk
A full-page A4 sheet in the browser. The header is composed by the system and refreshed in place; a band at the top of the page is reserved for pre-printed letterhead, invisible on screen and exact on paper. Text direction follows the report, not the reader's interface language. Key images are uploaded and referenced rather than embedded, so a long report stays a light document.
FilmLink — print and delivery
Appears to the modality as a DICOM printer. Lays the selected images onto film sheets with the patient's name in the correct script, and can attach the finished report to a message to the patient. It reads through a deliberately narrow account: the appointment and the report, view only — no patient table, no financial data.
Mobile
The same study list and viewer, laid out for a phone and installable to the home screen, with a packaged Android build for sites that want a launcher icon and no address bar. It talks to the archive, not to the record system: it is for looking at images and reports, not for booking.
Worklist service
Two implementations, and they are not redundant. One answers from the live record database and is correct for a site on the same network as it. The other is the edge agent's cache and is correct everywhere else, because it keeps answering when the link does not. Both present the same application entity and match on the same keys.
How they find each other
Four links carry the whole system.
Everything else is detail. If you can say which of these four stopped, you have already diagnosed the fault.
-
Record system → edge agent worklist
The agent signs in and pulls its site's bookings into a local store every 45 seconds. Outbound only: nothing is opened on the clinic router, and no inbound address is required. The machines then query the agent, not the cloud, so a dead uplink never costs a console its worklist.
-
Modalities → archive images
Ordinary DICOM C-STORE to the archive in the same building. The images already carry the accession number and study instance UID the record system issued, because the patient was selected from the worklist rather than typed.
-
Archive → record system completion
The agent watches the archive's change feed for stable studies, matches each one back to its booking, and reports completion. That is what lights the images indicator and what makes the reader's link resolve.
-
Site → gateway reachability
A site with no public address dials out to a gateway you control, which then publishes it to authorised readers. Two transports are supported, because some networks block one of them outright; which a site uses is an operational fact, not a preference.
Offline continuity
Why nothing collides when the site books on its own.
Booking locally is easy. Booking locally in a way that cannot produce a duplicate identifier, without a lease protocol or a reconciliation pass, is the part that needed designing.
Three facts hold at once
- The central sequence never issues into the reserved band.
- The counter for that band lives in the agent's own store, on the site.
- One agent serves exactly one site.
Given those three, two sites cannot mint the same accession number even if both are offline for a week and neither can see the other. No coordination is required because none is possible.
| Accession | reserved prefix + site + sequence |
| Record number | site prefix + reserved band |
| Study UID | minted locally, handed to the machine |
| Worklist | visible on the console immediately |
| Payment | entered centrally when the link returns |
Integration surface
Standard interfaces, listed plainly.
Everything an estate connects to us with. Ports and application entity titles are configured per installation; a full conformance statement is issued with the tender pack.
| Interface | Role | Used for |
|---|---|---|
| DICOM Storage | SCP and SCU | Receiving studies from modalities; forwarding to another archive |
| DICOM Modality Worklist | SCP (C-FIND) | Serving the day's bookings to consoles, from cache or from the database |
| DICOM Query/Retrieve | SCP and SCU | Pulling priors from, and answering queries by, other institutions |
| DICOM Print | SCP | Accepting film jobs sent by the modality as if to a hardcopy printer |
| DICOMweb | WADO-RS, QIDO-RS, STOW-RS | The viewer, the phone, and third-party tools reading over HTTPS |
| HL7 version 2 | MLLP, inbound and outbound | Patient registration and orders in; verified results back out |
| REST over HTTPS | authenticated | Administration, reporting, sharing and anything you script yourself |
Operations
What breaks, and where to look.
We publish this because the alternative is a support call that starts with guessing. Every row is a real symptom with the place its cause is visible.
| Symptom | Where the answer is |
|---|---|
| Console shows an empty worklist | The agent's log records what was asked for against what it holds. It is almost always a mismatched application entity title, a date window, or a station title that does not match the booking. |
| Images indicator never lights | The agent's completion lines, then the unmatched studies queue. The study is in the archive; it has not been tied to a booking. |
| Site unreachable, every service healthy | The tunnel's restart count. A large number is the outage, not a symptom of one. |
| Report editor appears frozen | It is read-only rather than slow: either the reader lost a lock, or the browser's own writing assistant is re-scanning the document. |
| A whole site's interface returns errors | The front-end proxy is holding a stale address for a restarted service. Reload the proxy after recreating a container. |
Ask us the hard question about your estate.
Sites with no fixed address, a hospital system that only speaks HL7 version 2, a modality from 2009 that does one thing oddly. These are the normal cases, not the exceptions.