Architecture

How Pulse
is put together.

A radiology workflow platform — registration through to the signed report. This is the architecture, and why each piece is there.

Where you already are

Your department is already seven systems.

EMRthe chart

RISorders & scheduling

Reportingdictation & sign-off

HIEregional exchange

PACSimage archive

Worklistwhat the scanner queries

ScannerCT, MR, US, XR

…different vendors, bought at different times

The middle

One place where everything connects.

An order is placed. Images arrive. A report is signed. Each event lands in one place, which works out which of your systems needs to know.

You already have something doing this job. The difference is that we designed the product around it, instead of bolting it on afterwards.

so keeping your PACS is a configuration, not a project

The record

The clinical record isn't our database. It's the standard.

Patients, orders, studies, reports — stored as FHIR R5, the international standard for exchanging health data.

Your tools already read this format. Your integration team already knows it. Nothing here is in a shape only we understand.

The scanners

We speak the protocol your machines already speak.

The scanner queries the worklist — the patient is already there, nobody retypes a name at the console
Images go to the archive the normal way
No translation layer in between — nothing to drift out of sync

DICOM, directly. Nothing new to buy.

Staying in step

One number, running through everything.

One accession threading order, appointment, images, report and billing

If a system is down, it's retried. If ours restarts mid-delivery, the message is still there when it comes back.

The reading worklistwhat's waiting · and how long it has been waiting

Dictationwhat was said, above · a drafted impression, below · the radiologist signs

Where it runs

Residency isn't a setting. It's a separate deployment.

A separate deployment per region, plus on-premise

Who you are comes from your sign-in — never from anything the desktop can claim.

When something goes wrong

Imaging doesn't stop because a vendor is having a bad day.

The scanners keep scanning — the worklist and archive are standard DICOM
Images keep being stored
Nothing in flight is lost — it arrives when we're back
Prior reports stay readable by your other systems

And on-premise, our availability isn't part of your risk at all.

Leaving

There's no extraction, because there's nothing proprietary to extract from.

Everything is already FHIR and DICOM. Export all of it, and what comes out is readable by anything that speaks the standards — including whoever replaces us.

Everyone here has been through a migration where the last vendor's format turned two weeks into nine months. I'd rather say this now than have you find out later.

What the architecture buys you

Not features bolted on. Consequences of how it's built.

What you worry about

Why it can't happen

A study is acquired and nobody reads it

One accession threading every system

Someone is scanned who shouldn't be

Screening enforced in the server

A critical finding reaches nobody

Acknowledgement required, and recorded

The wrong person signs a report

Refused at the server, not the screen

Another hospital sees your patients

Identity from sign-in, never from the desktop

Data ends up in the wrong country

A separate deployment per region

Nobody can say who saw what

Every access recorded, reads included

That's how it's
put together.

We're building it in the open, unfinished parts included — and we check what our suppliers claim rather than taking it on trust.

If any of this sounded like your Tuesday, I'd like to talk. We're looking for a few departments willing to shape it while it's still being designed.

`→` `space`	next slide
`←`	previous
`N`	toggle speaker notes
`Home` `End`	first / last
`?`	close this

How Pulseis put together.