Built for the problems hospitals actually have

• Retention gets cut to save money.
• Log sources get dropped.
• The tool that should answer "who touched what, and when" stops seeing everything.

That is not bad luck. It is the predictable result of paying by volume in a place that cannot afford to under-log.

Four pressures that make it worse here

• The law requires review you cannot actually do. 45 CFR 164.308(a)(1)(ii)(D) requires regular review of system activity. A mid-sized hospital produces tens of thousands of chart accesses every two weeks.
• Clinical and building systems share the network. Medical devices, HVAC, badge readers and generators sit next to clinical workstations. Most security tools cannot read those protocols at all.
• Each EHR logs differently. Building one integration per vendor means starting over when a vendor renames a product.
• AI tools arrived first. They are in use before anyone has counted them.

On top of that, most hospitals run four separate products: a SIEM, a behavior tool, a response tool and a compliance tool. Incidents live longest in the gaps between them.

On a real production system running about 100GB a day, that change did two things:

• Idle searches went from 1,200 milliseconds to 11 milliseconds.
• Files opened per search dropped from 466 to 10.

Older data moves to a sealed tier that is simply a folder. Months outside your search window are never opened at all. There is no separate index to rebuild before a search or an alert can reach that folder: detections and dashboards query it directly, measured at 172 milliseconds for an alert and 76 milliseconds for a dashboard panel over a million events.

What this means for you: "how far back can I search" becomes a storage question, not a performance question. You stop choosing between logging everything a hospital logs, the clinical systems and the building alike and staying inside budget.

Where your data sits

• In your own storage. AWS, Azure, Google, MinIO or Cloudflare. Your bucket, your keys.
• In an open format (OCSF Parquet). No proprietary index.
• Still readable if you leave. Other tools can query it directly.
• Required to be encrypted when you tell CAVER it holds clinical, evidence or CUI data. CAVER will not start against storage it cannot confirm is encrypted. See §11.

The endpoint agent and the collection reason

CAVER includes its own endpoint agent, Carbide, for Windows, Linux and macOS, on the same store, with no per-endpoint charge. Clinical workstations report process, network and driver activity, and updates are signed and staged. It runs in the install mode you choose per site: collection only, or with signed, audited response actions behind approval gates and a never-isolate list for clinical segments.

For design partners, every record also carries the reason it was collected, and CAVER shows which log volume serves no policy, so a minimum-necessary review is a report and not a project.

The medical content that ships with it

These are working dashboards, not a services engagement:

• PHI exposure map: where patient data is, and which of those places should not have it.
• Clinical systems overview: EHR access, HL7 traffic and imaging in one view.
• Imaging estate: every imaging system talking on your network, what it does, and how much data it moves.
• Imaging query and retrieve: led by retrieves to destinations you have never used.
• HIPAA posture: the mapping in §11, against your own environment, as a signed export.

They are written against the clinical class described below, so they work on your site without being rebuilt for your naming.

What works on day one, and what needs a baseline

Almost all of this works the day your data lands. One part does not, and it is worth being exact about which part, because the difference is usually explained badly.

• Day one, everything rule-based. Access after a termination date, break-glass with no justification recorded, an imaging retrieve to a destination you have never sent to, PHI sitting where it should not be, and the HIPAA mapping in §11. These are facts about your data rather than judgments about a person, so there is nothing to learn first.
• Two to four weeks, the behavioral detections only. Judging whether this nurse's access is unusual for this nurse means first knowing what usual looks like on your wards. That baseline is the only thing that waits, and it waits while everything above it is already running.
• While it learns, CAVER says so. The behavioral models report themselves as not ready. You do not get an empty dashboard.

That last point is the one that matters. "We found nothing" and "we are not ready yet" look identical on a screen, and only one of them is good news. A tool that does not distinguish them is quietly telling you that you are safe during the exact period it cannot tell.

How patient identity is handled

The problem: to spot a pattern you have to know it is the same patient. To be safe, you would rather not hold their name.

CAVER does both. Where it reads clinical traffic, it converts the patient identifier into a salted one-way key:

• The same patient produces the same key, so activity can be linked across HL7 messages, imaging studies and EHR records.
• The key cannot be turned back into a medical record number, by us or by anyone who obtains it.
• The salt is unique to your deployment, so the same patient at two different hospitals produces two different keys. The two sites cannot be cross-referenced, even by us.
• Carrying the real identifier is off by default and has to be switched on deliberately. When it is on, the system reports that it is on, so anyone auditing the deployment sees it without reading a config file.

The same discipline runs through the rest:

• HL7 traffic is read for metadata only. Who sent what kind of message, to whom, when, and how big. Names, dates of birth, diagnoses, medications and results are not carried at all by default.
• Imaging is read without the image. See §7.
• Finding PHI does not mean copying it. When CAVER identifies protected data sitting somewhere it should not be, it records that it was found, what type, and where. It never stores the value it matched. A tool that cataloged PHI by copying it into a second system would create the exposure it was bought to find.

One idea worth understanding: the clinical class

Hospitals name things differently. One site calls it epic_audit, another calls it ehr_prod.

CAVER groups related data into a class. The clinical class gathers EHR access records, HL7 traffic, imaging activity and data classification into one place to search.

Why it matters: our healthcare dashboards and rules are written against the class, not against your index names. They work whether you run Epic or Meditech, and whether your HL7 comes through Mirth or Rhapsody. Nothing has to be rewritten for your site.

We measured it rather than guessing. CAVER includes a synthetic hospital: staff with roles and shifts, patients with encounters, care teams and orders. Over three weeks it produces:

• About 1,700 chart accesses with no formal care relationship.
• Nearly all of them completely innocent.
• A handful that are real problems.

A rule that says "no relationship, therefore report it" reports all 1,700. That is what most EHR access reports are. That is why nobody reads them.

What CAVER does instead

• Compares each person to their own normal. An ER nurse opens far more charts than a billing clerk. One threshold either misses the clerk or buries the nurse, so CAVER learns what is normal per role and per department.
• Reports one finding per person, per patient. A nurse opening the same chart four times is one conversation, not four alerts.
• Judges emergency access on the justification. Break-glass is used properly every week. What matters is when the justification is missing.
• Keeps a few things as hard rules. Access after someone was terminated. One account used at two workstations further apart than a person can walk. Termination dates can come from the HR system or the directory, so access after termination is judged against the authoritative date and not the last audit field. That feed is delivered on request, typically within 30 days of order. Service accounts and shared clinical accounts are told apart from people, and password age is reported for each.
• Watches the charts that need watching. Access to a flagged patient record without a care relationship is escalated rather than averaged away. Every hospital has employees, relatives of staff, and the occasional name in the news.
• Shows its working. Every finding states what CAVER expected and what actually happened, and you can see the normal it learned for any role or department. A behavioral tool that cannot show its reasoning gets argued with instead of acted on. For design partners, baselines also account for seasonality such as flu season and holidays, and each model’s precision and recall are measured on the customer’s own labeled outcomes.

The result

On the same three weeks, from 40,933 chart accesses, the review queue is:

• 1 escalation
• 19 inquiries
• 54 items for routine review

That is a queue a compliance officer can work through on a Monday morning.

Three mistakes the test hospital caught before a customer could

• A family-lookup rule flagged anyone opening the chart of any colleague's relative. That produced 46 escalations in three weeks, nearly all wrong. Corrected, it produced one.
• An off-hours rule reported night nurses for working nights.
• A bulk-export rule never fired on the case it was written for, because one heavy exporter raised their own department's average past the threshold meant to catch them.

First question: was it really that person?

Everything above assumes the account is the person. In a hospital that assumption breaks constantly.

Most hospitals use tap-and-go sign-on, because typing a password at a bedside forty times a shift does not survive contact with clinical work. Shared credentials follow:

• A badge left sitting on a workstation.
• A colleague tapping in for someone whose hands are gloved.
• A cart nobody has logged out of since Tuesday.

This is what makes EHR audit logs lie, and it lies in the worst direction: the chart access is recorded against whoever the session belongs to, so the record is confident and wrong.

CAVER grades every access on whether it can be tied to a person at all:

CAVER also reports the same badge appearing in two places faster than a person can walk between them. That is a measurement here, not a guess, because a hospital has a floor plan and the distance from the ICU to the third-floor pharmacy is something somebody walked with a stopwatch. Where your floor plan does not cover a pair of locations, CAVER says nothing rather than inventing a distance to accuse a named clinician with.

Sessions that run past a shift change are flagged too. A session nobody closed across a shift change is a session more than one person used.

What CAVER does: it reads all four standard formats and turns them into one common record. The same nurse viewing the same chart produces the same result no matter which format it arrived in.

That matters because it means the detections in §4 never have to be rewritten per vendor. If they did, you would be maintaining three sets of thresholds instead of one.

We tell you what your feed is missing

Not every format carries everything. Some can carry the care relationship only if the sender is configured to include it. Others cannot carry a department at all.

So every record CAVER reads reports what was missing, in plain terms:

• Not "relationship field absent" but "your detections have fallen back to counting."
• Coverage is reported as a fraction with the total. 3 records in 100 missing a field is a different situation from all 100.
• We separate what a format cannot carry from what your sender simply did not send, so you are not sent to argue with a vendor over something already supported.
• A refused access is not a disclosure. CAVER records the outcome separately, so failed attempts never inflate the numbers in a breach report.

You should find out your feed is thin during setup, not during an audit.

CAVER reads this traffic for metadata only: who sent what kind of message to whom, and when. The clinical content is not carried, and the patient is represented by the salted key described in §3.

Those are the same assumptions industrial control systems make. So CAVER applies the same behavior model it uses on factory equipment: learn the normal conversation between two systems, then flag what falls outside it.

What CAVER reports

• Two systems that have never spoken, suddenly speaking. The strongest signal available.
• A message type an interface has never carried before. Judged before it is learned, so the first one is reported rather than quietly accepted as normal.
• An interface that stopped. See below.
• Test traffic on a live interface. Someone pointed a test system at production, and test data is being written into real records.
• Master-file updates, which change reference data every downstream system trusts.

The stopped interface

An HL7 interface that quietly stops is a patient-safety event:

• Orders stop reaching the lab.
• Results stop reaching the chart.
• It is usually discovered hours later by a clinician looking for a result that never arrived.

Nothing about it looks like an attack, which is exactly why no security tool reports it. CAVER does, and it costs almost nothing extra, because the interface's normal rhythm had to be learned anyway.

You also get the interface inventory as a by-product: which systems talk to which, carrying what, at what rate. Most hospital integration teams do not have that list.

• Bulk downloads of studies.
• Transfers to a destination nobody recognizes.
• Imaging services reachable by anyone who can open a network connection.

What CAVER does: it watches DICOM traffic passively and records who connected, what they asked for, what they retrieved, and how much data moved.

Patients are represented by the same salted key as everywhere else (§3), so imaging activity links to chart activity without either one carrying an identifier.

The finding that matters most

A DICOM retrieve command sends images to a destination the requester names. That destination is right there in the request. So the entire theft case is visible in a single packet.

• A retrieve to a destination this hospital has never used before is the loudest alert CAVER produces.
• A retrieve to a known destination is treated as ordinary. Otherwise every legitimate image lookup becomes an alert and the system is switched off within a day.

Two things you probably are not told today

• "Caller not recognized." That is what your PACS says when something it does not know tries to connect. It is the signature of a scan or a misconfigured new device, and hospitals almost never hear about it.
• A DICOM system name proves nothing. The caller chooses its own name. It is the equivalent of the "From" line on an email. Worth remembering when reading any finding built on one.

Here is why the usual tools do not help:

• The tool reports a vulnerability.
• You cannot patch the device.
• Next month it reports the same vulnerability again.

A report you cannot act on teaches people to close the report.

What CAVER does: you cannot fix the device, so CAVER learns what each device normally does and tells you when that changes. An infusion pump that has only ever talked to its drug library server, suddenly talking to a workstation, is something you can act on today.

When two findings are equally urgent, CAVER ranks by clinical importance, not data sensitivity. The ventilator comes before the telemetry gateway.

The inventory is reconciled against the device list clinical engineering keeps, so devices the CMMS knows and the network has never seen are listed. If the hospital already runs an IoMT visibility platform, its inventory and alerts join the passive picture, and the unpatchable-device triage ranks across both. Published ICS advisories can be matched to the devices the passive inventory identified, so a Compensate row cites the advisory it is compensating for. That matching is delivered on request, typically within 30 days of order.

Nothing is scanned or probed

Actively scanning medical devices is itself a patient-safety risk. Several vendors have caused clinical outages doing it. That is why clinical engineering departments refuse to allow it, and why a product that requires scanning does not get deployed.

CAVER builds its device picture from watching traffic: no agent, no probe, no connection to any device. That is read-only mode. Interactive mode adds signed, audited Carbide response actions on hosts that run it. The network sensor stays passive in both modes, and an automatic check fails our build if anyone adds code to it capable of reaching a device.

Device identification reports its own confidence:

• A network port a device family always uses counts for more than a name the device chose for itself.
• A manufacturer code supports a guess but never settles it, because a manufacturer makes several kinds of device.
• When the evidence is split, the device stays unknown. An inventory that confidently mislabels a device is worse than one that admits it does not know.

• An isolation room must be at lower pressure than the corridor, so infectious air stays inside.
• A protective room for a patient with no immune system must be higher, so unfiltered air stays out.
• An operating room must hold its pressure and its air change rate, for every procedure.

Nobody is alarmed. Nothing is broken. The nursing staff cannot see it.

What CAVER does: it reads the building automation traffic it already decodes, and checks each room against what its clinical use requires. Requirements cite ASHRAE 170 and the FGI Guidelines, so an infection preventionist is reading the standard they already work from.

What CAVER refuses to guess

• You tell us what each room is for. Nothing in a building system name reliably says "isolation room". Guessing would produce infection-control findings about broom cupboards.
• Our requirements are defaults, not your building code. Your facility follows the code edition in force when it was permitted, and an older room may be legitimately commissioned lower. You can override every value.
• A sensor the system marks as faulty is not believed, and does not convict the room. A stuck sensor showing a perfect reading looks exactly like a healthy room.
• An alert is raised when the room changes state, not every thirty seconds. An alert that repeats constantly is an alert nobody keeps.

The problem nothing else finds

Consider a pump filling a 30,000 gallon tank at 11 gallons a minute, scheduled to run three hours a day.

• Nothing is broken.
• No alarm fires.
• 11 gallons a minute for three hours is 1,980 gallons a day.
• The tank will never fill.

That is a fault in the goals, not the equipment, and no tool that only compares traffic to known threats will ever see it.

The same arithmetic applies to your air handling. An air handler scheduled for sixteen hours a day cannot deliver twenty-four hours of air changes. CAVER states which setting is the limit, so you know whether you are looking at a schedule change or a capital project.

The same reading covers cold chain and pharmacy storage. A vaccine or blood-bank refrigerator that is held open or drifting out of range is a finding on the same board as the door and the temperature trend. CAVER produces signed evidence reports for Joint Commission Environment of Care, OSHA workplace violence and NRC radiation sealed-source tracking from the door, badge, environmental and radiation events in §10. The reports show what is evidenced and what is not.

• A badge opens the pharmacy door while that same account is active on a workstation two floors up, or its login says the person is at home.
• A door held open or a camera-confirmed tailgate into a restricted room, followed by a session that starts inside it.
• Controlled-substance diversion: med-room access, the dispensing cabinet event, and the chart, correlated, which is a cross-silo pattern no one system sees.
• People counts and occupancy from the cameras: emergency-department crowding, an evacuation, a room that should be empty at 3 a.m. and is not.

And it keeps the answer long after the footage is gone. A recorder overwrites video in weeks because it is enormous; the events that describe it are tiny, so years of door and count history sit on storage you already own. When a subpoena arrives eighteen months later, the record that says a door was held open for twelve minutes at 4:30 in the morning while six people passed, against a baseline of none, is the one Caver still has and the camera does not.

Weapons-screening systems such as Evolv, ZeroEyes and Omnilert feed the same board as the door and badge events, and people counts and location from Wi-Fi and Bluetooth can be added. Person-level data is held in a secured, access-controlled area of the lake. Delivered on request, typically within 30 days of order.

Biomedical engineering chases this today with a handheld analyzer walked to the floor after the fact. What CAVER does: a small passive receiver learns the floor's normal radio picture and reports what departs from it. It never transmits, and it reads the environment, not the traffic:

• A new emitter in a telemetry band, degrading the monitors, reported as it starts rather than after a nurse chases a quiet screen.
• A link weakening or dropping, so a failing transmitter or a coverage dead zone is an equipment finding, not a gap in the record.
• An unexpected Bluetooth or Wi-Fi radio next to a critical device, an infusion pump or a monitor, seen in the air rather than after it reaches the network.
• Jamming, a wide carrier or a rising noise floor that suppresses real medical radio, which on a hospital floor is a safety condition.

Two teams read the same feed. Biomedical and clinical engineering get the telemetry-uptime picture they have never had continuously, and security gets the rogue device and the jammer that no network tool can see, because none of it touches a switch. The device-security products a hospital already evaluates watch the network; none of them sense the spectrum.

Controller logs from the hospital's wireless vendor (Cisco, Aruba, Mist, Ruckus or Extreme) feed rogue access point findings beside the spectrum picture, available on request, typically delivered within 30 days of order.

A number is not a recommendation

"Handover is slow" is a chart, and you already have charts. What changes something is naming the cause:

"Handover on 4 West runs 28 minutes past shift change, because the outgoing staff are still writing notes for about 22 minutes after the incoming staff start. The limit is note completion, not staffing."

That is a sentence an operations director can act on this week.

What is law today

CAVER's compliance reports give counts with totals and never a bare compliance percentage, because "83% compliant" is a number that ends up in a contract. The privacy officer’s monthly HIPAA report is generated in the background, branded, signed and mailed, and a scheduled delivery to the compliance team is available on request.

Encryption: what we require, and what we cannot

Your data sits in your own storage. That means its encryption is whatever that storage has, and most sites are encrypted by accident rather than by decision, because the major cloud providers turn it on by default for new storage.

By accident is not a control. So CAVER checks.

• You declare which data classes this system holds (clinical, evidence, and CUI for defense work).
• CAVER asks your storage whether it is encrypted before it starts.
• If it cannot be shown to be encrypted, CAVER refuses to run. Not a warning in a log. A warning scrolls past once and nobody sees it again, which is the same as having no control at all.
• If your storage does not answer the question, that counts as unverified, not as safe. Some storage systems do not support the check. You can override it, and if you do, CAVER records that your encryption position is unconfirmed so it appears in any compliance report rather than being quietly assumed.
• We report who holds the key. Encrypted with the provider's key and encrypted with a key you control are different answers to an auditor, so they are not both reported as simply "encrypted".

Finding PHI where it should not be

CAVER classifies data against the 18 HIPAA identifiers at 45 CFR 164.514(b)(2), and every match cites the regulation.

But pattern matching is not the point. The point is the map of where PHI is sitting that should not be:

• A helpdesk ticketing system.
• A chat export.
• A developer's test database.

That is what organizations get fined for. Almost nobody can answer it today, and a data lake can, because it already holds everything.

Two things stop it becoming noise:

• Card numbers are check-digit verified, not just counted. In a hospital, order numbers, accession numbers and device serial numbers are all long strings of digits. Without the check, every one of them reads as a credit card.
• Every match says how sure it is. An IP address is a HIPAA identifier and it is also in every log line ever written, so it is not reported with the same confidence as a Social Security number.

Three rules make it usable:

• PHI in the EHR is not a finding. That is the EHR working. Reporting it buries the findings that matter.
• Severity is about where, not how much. One record in a chat tool outranks five hundred in a billing system.
• We record that PHI was present and where. We never store the value. A tool that classified PHI by copying it somewhere would create the exposure it was built to find.

The 2025 proposal is not law

The proposal would remove the difference between "required" and "addressable" safeguards. That is the biggest change in it: anything you currently document as handled by an alternative measure becomes a flat requirement.

CAVER's readiness view covers the proposed items on the same terms as the current ones, marking clearly which ones we help with and which we do not touch at all.

The asset inventory, generated for you

One proposed item is worth calling out. It would require a written technology asset inventory and network map, reviewed at least annually.

• It is the most tedious item on the list.
• Every hospital keeps it by hand or not at all.
• It is out of date the day after it is written.

CAVER builds both from what it observes: HL7 interfaces, imaging systems, EHR workstations, medical devices and building controllers, with a record of what saw each one. Systems it cannot identify are listed as unknown rather than guessed at.

Severity here comes from the relationship between the person looking and the person looked at, because every access on these screens succeeded. The clinician had a valid login, a current role and, usually, a real reason. That is the hospital problem, and it is not the shape of an ordinary SIEM screen, which is built around a failed authentication.

What is in it

• PHI access, built as a review queue rather than an alert list. Break-glass is legitimate emergency access and the workflow is access first, attest after, so the product owes you a reviewable backlog with an age on it. The finding is the attestation that never arrived.
• Patient journey, one patient across every system that touched them, from registration through pharmacy, naming the identifier each stage is keyed on. That is where the join quietly fails, and it is the question everyone asks after a breach notification. Registration and orders are counted as two stages rather than one, split on the HL7 message class, so an admission feed and a results feed that share an interface no longer share a number.
• Access path, for the ward where identity is shared by design. A workstation is tapped in and out all shift, so attribution has to come from the tap rather than the account name, and the product's job is to carry attribution across that sharing rather than to flag the sharing itself.
• Controlled substances, the reconciliation between dispensed, administered and wasted. Nobody breaks in: a licensed nurse removes a vial they are entitled to remove, so it is arithmetic across three ledgers rather than an intrusion to detect.
• Imaging estate, modalities and query-retrieve, because the patient identity travels inside the study file and a copied study is a disclosure even when no database row moved.
• Evidence and coverage, which states what your estate cannot prove, in writing, per system. Reportable-condition assurance is on this screen as a register of feeds with a verdict per prerequisite, so a green list of sites cannot pass for a running control.

Nineteen of the thirty-six are clinical. Break-glass used without an attestation following it. A lookup with no recorded care relationship. A bulk export. An interface that has fallen silent. An imaging query burst. A controlled-substance chain that does not reconcile. A portal takeover. A badge that says one thing and a chart that says another.

Silence is a result, and it is written down

An agent that speaks only when it finds something is indistinguishable from one that is broken, and the second is far more common than anyone admits. Every run is recorded whether or not it found anything, carrying what it checked and over what window. A quiet Sunday becomes evidence rather than an absence of evidence, which is the difference between a privacy officer who can attest and one who can only hope.

Not one of them needs a language model

Twenty of the thirty-six are rules, joins and thresholds: the same data gives the same answer on any day, and it can be explained to an auditor as a query. The other sixteen are baselines, peer groups and rarity, which is still arithmetic over your own history. Five can use a model to write their summary in prose; switch it off and you lose the wording, not the finding. Every competitor selling an "agentic SOC" means a language model with a prompt. This is the opposite claim, and it is checkable.

They arrive switched off, and you switch them on

Every agent ships disabled and you enable them one at a time, from the product, with the decision recorded. That is deliberate. These make findings about named clinicians, so a hospital agrees its exclusion list and its relationship rules before a single one of them speaks. An agent that switched itself on at install would produce its first wall of accusations from a half-configured join, and nobody gives it a second week.

Compression: 48 to 1, and how we measured it

• The top number is raw bytes received, which is what a per-gigabyte license would charge you for.
• The bottom number is the actual stored file size, taken from a storage listing.
• Our own system's internal logs are excluded from both.
• The ratio varies with your data mix.

Ask any vendor, including us, for the range across your own data types during a trial. Not just one blended figure.

Searches are scheduled by priority with a reserved lane for urgent ones, and costly searches queue rather than fail.

Where the incumbents still win

An established SIEM has real advantages we will not pretend away:

• A large consulting ecosystem.
• A hiring pool that already knows its query language.
• A decade of your own custom content.

Those are genuine switching costs. Our answer is the parallel-run and collector-only options above, which let you measure the difference instead of taking it on faith.

• Every item carries a cryptographic fingerprint and a signature covering the content, time, case and the person who filed it. A signature cannot be moved onto different content.
• Custody records are append-only. They are never edited.
• The ledger uses the same proven construction that underpins internet certificate transparency.
• Every read and every check is logged, with who, when and why.
• Verification does not need CAVER. A separate signed program checks the whole chain offline, so an opposing expert, outside counsel or an auditor can verify it without touching your systems.
• Export bundles can be encrypted with AES-256 under a password you set.

What this means for you: a record a hospital's privacy officer, an OCR investigator, or outside counsel can verify without trusting the vendor

Evidence is written to object-lock storage (WORM), and a legal hold needs two authorizers. Retention is set per data class and ages from the time CAVER received a record, not the time the record claims. Every search is audited with the access scope applied, and an analyst's index access is enforced as a row-level filter, so a billing analyst never sees a chart-access index.

What is included: 24 content packs and over 200 rules, covering prompt manipulation, data leaving through an AI tool, misuse of connected tools, and runaway automation.

CAVER can also sit in front of your AI traffic as a checkpoint, with a full audit trail, per-user limits and blocking of unapproved AI services. A hospital can put CAVER in front of a clinical AI assistant, with per-user limits and a full audit trail, before it is trusted with a chart.

Two postures, and you choose

• Sealed. Fully self-hosted. On-site vendor access only. No remote connection out of your environment. Nothing leaves. A hospital that will not run a vendor tunnel into a clinical network runs it sealed: nothing leaves the building.
• Managed. The conventional arrangement, with remote monitoring and vendor-assisted operations.

This is your risk decision. Both are real products. Neither is a discouraged version of the other.

Signing in with what you already have

SAML 2.0 and OpenID Connect are both configured in the product: paste or fetch your identity provider's SAML metadata, or point at your OIDC issuer for discovery, then map the attributes or claims to roles. Test against the live provider before you can turn it on: enable is refused without a successful test in the last 24 hours. A saved change or a disable takes effect on the next request, no restart, and local login stays reachable so an identity-provider outage cannot lock your operators out. An OIDC client secret is sealed in the product's credential vault, never stored in the clear.

Provisioning through SCIM

SCIM provisioning is configured the same way: an operator mints a bearer token for the identity provider, shown once and stored only as a hash, revoked on the very next request rather than the next restart. Group membership from SAML, OIDC, or SCIM maps to roles by the same rule.

Four ways to start

• Full migration, with a practice run before cutover.
• Run alongside your current SIEM while your team checks coverage. CAVER can register as a Splunk search peer, or federate with Elastic, Sentinel, Sumo Logic or Datadog, so both systems answer the same question and you compare the answers.
• Collection only, sitting in front of your current tool with no disruption.
• One piece at a time. Take the Evidence Locker, AI monitoring or compliance reporting without replacing anything.

A health system runs one CAVER per hospital or one for the system. Each hospital is a tenant, content rolls out in canary stages, and a disaster-recovery restore brings back dashboards, rules, users and playbooks.

Medical record systems

The reason the list is short is that CAVER reads the standards rather than each vendor. A system nobody has heard of that emits FHIR AuditEvent works on day one. A vendor connector would not.

Imaging

CAVER reads DICOM on the wire, which every imaging device and archive speaks. That covers the estate regardless of badge:

• Modalities: GE HealthCare, Siemens Healthineers, Philips, Canon Medical, Fujifilm, Samsung, Hologic, Konica Minolta, Carestream, Mindray, and anything else DICOM-conformant.
• Archives and viewers: Sectra, Agfa, Fujifilm Synapse, GE Centricity, Philips Vue, Merative, Hyland, Intelerad.

No vendor cooperation is required, and no image is ever read.

Medical devices and building equipment

CAVER identifies these from their network behavior and their manufacturer's hardware address. Recognized device families:

Which direction each connection runs

The question underneath "do you integrate with Epic" is usually a different one: can this thing change anything in a clinical system? For everything clinical the answer is no, and it is enforced rather than promised.

And everything else

• Anything that keeps a log. Syslog, a log file, Windows events, a cloud audit trail, a database table.
• Anything with an API. If it can be polled or can push, CAVER can take it.
• Anything that talks on a network you can mirror to us. Even with no log and no API.
• Custom collectors are built to order. That is ordinary work here, not a special request. If you have a system that matters and nothing off the shelf reads it, say so during the trial and it gets built.

More than 400 ready-made vendor packs ship for the common systems, so the bespoke work is the exception rather than the starting point.

• Windows event logs from nursing and registration workstations arrive through Windows Event Forwarding over HTTPS with no collector box.
• Ticketing and paging. A privacy finding opens a ServiceNow or Jira case with the evidence attached, and acknowledgement from Teams or Slack is checked against the user’s role.
• Clinical secure-messaging platforms (Vocera, TigerConnect, Epic Secure Chat) and the laboratory, pharmacy and blood-bank systems are connected on request, typically within 30 days of order.
• Federal health. VA VistA and MHS GENESIS audit feeds are available to design partners at federal health sites.
• Existing IoMT visibility platforms (Armis Centrix, Claroty, Forescout eyeInspect, Microsoft Defender for IoT, Radiflow, Tenable OT, Nozomi) land their inventory and alerts beside the passive device picture. Adapters for Armis and Tenable OT are delivered on request, typically within 30 days of order.

1. Point it at a de-identified slice of your EHR audit log and see whether the access story reads before you trust it with the live one.
2. Ask what it shows during the learning period. It should tell you it is not ready, not draw a confident dashboard.
3. Ask what CAVER shows during the learning period. It should tell you it is not ready, not show you a clean dashboard. This is the claim that is easiest to fake.
4. Verify an evidence export yourself. Run our offline checker against a real export without touching the CAVER console.
5. Ask for the compression range across your data types, and for the load ceiling next to any speed figure.
6. Run it alongside your current SIEM so migration risk is measured during the trial rather than assumed afterward.