Healthcare
Keep clinical teams moving. Keep IT work accountable.
A waiting room does not pause for a maintenance window. The work that keeps a practice running has to happen at 09:38 on a Tuesday, on machines that sit next to patient data, with access scoped to the operation. Seraph helps run the fix inside clinic hours and produces a record of who allowed it, what rights it used, and what the machine itself said afterwards.
The pressure
The day is the constraint, not the ticket.
Most environments get to say "we will look at it tonight". A clinic cannot. Check-in stops, the schedule slips, and by 10:15 the delay is measured in patients rather than minutes. So the real question is not how fast a fix is. It is which fixes are allowed to happen while people are in the building — and whether anything records the difference.
The characteristic ticket
The front-desk printer, at the worst possible time.
This is the illustration we use across this site, because it is the most ordinary thing that happens in a clinic and it exposes every part of the problem at once. Dana works the check-in desk at a multi-site practice. At 09:38 the encounter forms and the wristbands stop printing.
-
09:38 — Dana asks in the channel she already uses
She does not open a portal or look up a phone number. She types it into the Teams channel the practice already runs its IT questions through, and the request becomes a typed outcome instead of a paragraph someone has to interpret.
-
09:39 — a fix that was already proven gets selected
The planner picks a certified runbook first. It carries its preconditions, the check that defines success, and the way back — all written down before it is eligible to run. Nothing is improvised on a server that sits behind a clinical workflow.
-
09:40 — Marcus authorizes it
Your technician sees what will run, on which machine, with what rights, and for how long. One click. His name is on the work from that moment, and it stays attached to it.
-
09:40 — eight minutes of admin rights appear
Scoped to this operation on this one server, with the reason recorded, and set to expire on the clock rather than when the job happens to finish. No shared admin account was used, because there is not one.
-
09:43 — the job runs, and the model never held the password
The connection is authenticated before any generated step exists. The planner works from the operation, the target and the outcome to reach; the credential is resolved by the executor and is never delivered to the model.
-
09:46 — the server answers, and that is what the record carries
An independent check runs on SRV-ACCT-02 itself. Service running, queue clear — the machine's answer, not the platform's opinion of its own work. At 09:48 the record seals. At 09:50 Dana is told, in the channel she asked in.
Scope
How small the access actually was.
A clinic network is unusual in one respect: almost every box on it holds or touches patient data. That is why a standing domain admin account is such an expensive convenience, and why the interesting number is not "how many rights" but "how few, and for how long".
- No shared admin account. There is no "the IT password" for a technician to remember, share, or leave behind when they change jobs.
- The reason is recorded with the grant. Not in a spreadsheet next to it — in the record the work produced.
- Expiry is on the clock. Rights end at a time, not on a job status, so a stalled operation cannot quietly hold privilege open.
- A technician can take the wheel mid-operation, under a fresh lease in their own name, in the same operation and the same record.
The person who asks
What your practice manager can answer on her own.
Priya runs the practice. She is the one who sits with the annual security risk analysis, the vendor questionnaires that arrive with every new system, and the cyber-insurance renewal. Today her answer to "who touched that server, and what were they allowed to do" is a phone call to you. It does not have to be.
| What Priya gets asked | Where the answer is produced | What she can hand over |
|---|---|---|
| Who touched the system, and when? | the authorization | A named person and a timestamp, in the same record as the work |
| What rights did they hold, and for how long? | the lease | Eight minutes, scoped to one server, expired 09:47 |
| Did it actually work, or did someone say so? | the target's own check | The server's answer, not ours |
| What if it had made things worse? | the declared undo | Written down before it ran; availability depends on the runbook |
| Could this record have been edited afterwards? | the chain | Every later record would stop agreeing |
| Can I send this to our security officer? | the export | PDF, CSV or JSON, unmetered, under your branding |
Straight about scope
What this is, and what it is not.
Clinical software is not our layer. Seraph works at the machine, service, identity and update layer underneath it — which is where the tickets that stop a clinic actually live.
- Services, print queues, profiles and drive mappings on the machines a practice runs on.
- Accounts — directory and local managed accounts, including rotation of the ones you designate.
- Updates as a governed wave with gates that open on verified results, not on a job being sent. See patching.
- Governed remote access when a person has to be on the machine, launched under authorization and bound to the operation. See sessions.
- Not an EHR integration. We do not connect to, read from, or write to your clinical system, and we do not process patient data.
- Not your risk analysis. Seraph produces evidence for it. It does not perform it, and it is not a substitute for one.
- Not complete session recording. We are deliberately narrow about what a session record covers today rather than promising replay we do not ship.
- Not certified against any framework. No badge, no attestation, no third-party audit report to wave at you.
One more line we would rather say out loud. A record proves what the operation did; it does not prove the absence of everything else. A technician in a governed session on a machine can still see what is on that screen. What changes is that the session was asked for, authorized by a named person, scoped, time-boxed, and written down — so the question "who was on that machine on the 14th" has an answer that does not depend on anyone's memory. If your counsel needs a business associate agreement in place before any of this matters, bring that to the demo. We would rather answer it in front of you than in a brochure.
Fifteen minutes, on a live system
Bring the question your last risk assessment could not answer.
We will run an operation end to end, open the record it produces, and execute the declared undo while you watch.