Pharos Systems

Imaging infrastructure · PACS · RIS · Diagnostic viewer

The scanner does not stop when the line does.

Pharos Systems builds the archive, the worklist, the reporting desk and the diagnostic viewer that a radiology service runs on — as seven independent programs on hardware you control. Each one can fail without taking the others down. That is not a slogan; it is the reason a cut fibre costs you a network link instead of a working day.

Fig. 1 — the site loses its uplink observed behaviour
  1. The link drops

    No console shows an error. The worklist the machines query is held on the site, not in the cloud.

  2. Scanning continues

    Booked patients are already cached. Images store to the local archive under the identity the RIS issued.

  3. Walk-ins are still booked

    The front desk books locally. Identity is drawn from a numbering band the cloud never issues into, so nothing can collide.

  4. The link returns

    Local bookings replay upward under the exact numbers the machine already wrote into the images. No reconciliation step, no orphaned studies.

The failure that ends in a stranded study is a technologist typing a patient in by hand. The design removes the reason to do it.
Services
7, each fails alone
Worklist refresh
45 s, from local cache
Standards
DICOM · DICOMweb · HL7 v2
Runs on
Your hardware, your network

The premise

Two facts, and everything that moves between them.

Most imaging estates are hard to reason about because identity leaks: three systems each believe they can name a patient. Ours has one rule, and the whole architecture falls out of it.

SOURCE OF IDENTITY

The record system names things

The medical record number, the accession number and the study instance UID are issued at booking, once, by the RIS. No other component invents an identifier, and no component rewrites one it did not issue.

SOURCE OF PIXELS

The archive holds the images

The PACS is authoritative for image data and for nothing else. Because the technologist selects the patient from the worklist rather than typing one, arriving images already carry the identity the record system issued.

EVERY CONNECTION

Carries one of the two

Every link in the diagram below is one of those two facts travelling to somewhere that needs it. That is what makes a fault diagnosable: you can say which fact stopped moving, and where.

Identity flows from the images into the record, never the reverse. When a study cannot be matched to a booking it is queued for a human, not guessed at. Rewriting images to fit a booking is how a clerical error becomes a patient safety event.

Architecture

One record system in the centre. Sites that survive alone.

Fig. 2 — deployment topology, single site shown accent = the four links that matter
HOSPITAL HIS optional RECORD SYSTEM (RIS) bookings · identity · reports · billing one instance, cloud or your datacentre REMOTE READERS anywhere HL7 v2 report desk worklist ↓ pulled every 45 s study complete · offline bookings ↑ SECURE GATEWAY outbound tunnel from site THE SITE — ONE BUILDING, ONE BOX EDGE AGENT worklist cache · offline booking study reconciliation ARCHIVE (PACS) images · explorer · sharing C-STORE · Q/R · DICOMweb VIEWER · FILM diagnostic review print · report delivery MODALITIES CT · MR · XR · US · MG C-STORE MWL C-FIND complete web
Nothing inside the dashed boundary depends on the uplink to run. The record system is authoritative for identity and the archive for pixels; the two accent paths carry the worklist down and completion back up. Multi-site estates repeat the boundary, one per building, against the same record system.

The line-up

Seven programs, each with one job.

Licensed together or separately. A department that already has an archive can take the viewer and the reporting desk alone; one that has neither can take the whole chain.

Component What it does Speaks
Pharos PACS Stores, indexes and serves studies. Explorer interface, role-based access, share links, query/retrieve against remote nodes, CD and USB export. DICOM, DICOMweb
Pharos RIS Bookings, patient register, referrers, price lists per branch, payments, report workflow and staff roles. Issues every identifier the estate uses. HTTPS, HL7 v2
NextRad viewer Diagnostic review: window and level presets, multiplanar and oblique reformats, measurement and annotation that survive reorientation, volume rendering hand-off, dose and technique on the image. DICOMweb
Edge agent Serves the modality worklist from a local cache, books walk-ins while the uplink is down, and reconciles arriving studies against bookings. DICOM MWL
Reporting desk A full-page A4 sheet with the letterhead band reserved, bilingual headers, templates, key images by reference, signature and verification. HTTPS, PDF
FilmLink Receives print jobs from the modality as a DICOM printer, lays out film sheets, and delivers the finished report to the patient. DICOM Print
Mobile The same study list and viewer on a phone as an installable web app, with a packaged Android build for a launcher icon. HTTPS

Who we build for

Two buyers, one architecture.

For reading groups & individual radiologists

Read from anywhere, without shipping your archive to a vendor

A reader signs in once and lands on the study, already authenticated, with the report open beside it. The images stay where they were acquired.

  • Signed hand-off from the worklist straight into the viewer
  • Query/retrieve across the sites you are credentialed for, and no others
  • Reporting desk with templates, key images and verification
  • Phone access for a second look and for on-call triage
  • Per-reader scoping, so a locum sees one site and not the estate
For teleradiology

For ministries, public hospitals & tenders

Sovereign by construction, not by clause

The system installs on your servers, inside your network. There is no vendor cloud in the data path, and no per-study fee metering what you do with your own images.

  • Runs air-gapped or fully on-premises; the internet is optional
  • HL7 v2 into the hospital information system, with unmapped orders refused by name
  • Tenant separation down to the patient register
  • Retention and purge policy applied by the system, evidenced in its logs
  • Documented deployment, a runbook, and the failure modes written down
For the public sector

The shape of a day

What has to happen, and what happens by itself.

Six steps from a patient arriving to a report reaching them. Only the first and the fifth need a person. The rest is the system carrying identity and pixels to where they are needed, and it is the same sequence whether the site is online.

Matching is ordered, and it gives up honestly. An arriving study is matched by accession number, then by study instance UID, then by patient, day and modality. A study that matches none of the three is queued for review. A study carrying a different known patient's identifier is never auto-linked — it is flagged.
  1. The desk books

    The record system issues the medical record number, the accession number and the study instance UID. Nothing downstream invents an identifier.

  2. The worklist reaches the machine

    Within 45 seconds, from the cache on the site — not over the internet at the moment the technologist needs it.

  3. The technologist selects, and scans

    Because the patient was selected rather than typed, the images carry the identity the record system issued.

  4. The archive tells the record system

    The study lands locally; the edge agent sees it complete and reports back. The images indicator lights for the front desk and the reader.

  5. The radiologist reports

    From the reading desk or from anywhere, images one click away, on the same study the desk booked.

  6. The report reaches the patient

    Printed at the desk, delivered to the phone as a signed link, or returned to the ordering hospital as an HL7 result.

Deployment

Containers, one folder, one command.

Every service ships as a container with a compose file. The same artefacts install on a branch tower under a reception desk and on a rack in a government datacentre.

On-premises, per site

A single Linux or Windows box per building holds the archive, the agent and the viewer. Imaging continues whether or not the building can reach anything else.

Centralised

One archive and one record system in your datacentre, with sites attached over your own network. Same components, different placement.

Hybrid, and the usual answer

Pixels stay at the site; identity, reporting and billing sit centrally. Readers reach sites through an outbound tunnel, so no site needs a public address.

Updates and rollback

Versioned images, a migration step, and a health check against the live URL. Data lives in volumes and survives the update; a bad release rolls back to the previous tag.

Next step

See it running against your own studies.

Send us a de-identified study set and the shape of your estate — number of sites, modalities, whether there is a hospital system to talk to. We will stand up an instance and walk it through with you.