Founding Partner program is open. 21 seats, locked pricing.Learn more →
Platform
Solutions
Resources
Solutions CatalogPricing
Log InLet's Talk Shop!
SPECOPS.AIpowered by AgileLeap.AI
Reference Architecture · Regional Health Systems · v1
Chapter 01 · Your single source of trust

One governed standard for health systems that adopt in silos.

We have spent two decades delivering inside regulated and federal environments, so we know the terrain. Health systems adopt in silos: a headquarters on one EHR, affiliated community hospitals on another, provider offices on a third, each with its own security tools and its own AI bolted on vendor by vendor. The fragmentation is the hard part, and it is where most systems struggle. We built the platform around that reality.

SpecOps sits above all of it as the governance plane: one policy, one audit standard, one place where every AI action is re-decided and signed, on the stack you already own. A modular, cloud-based build, designed to start at one site and extend across the system.

Context: the HIPAA Security Rule overhaul referenced throughout is a proposed rule (NPRM published January 6, 2025) and is not final as of mid-2026. It is the modernization driver, not an in-force mandate yet. Vendor names are illustrative of each category, not partnerships or endorsements.
Chapter 02 · Where SpecOps Sits

Patients, providers, payers, and records. One plane in the path.

Everyone in the ecosystem transacts through the same governed plane. The systems of record stay where they are. The AI stays where you chose it. SpecOps governs the actions that move between them.

Ecosystem map: actors, AI, SpecOps governance plane, and systems of record
Read it top to bottom: actors transact, AI acts, the SpecOps plane governs and signs each action, and the records and exchange fabric stay in place underneath.
Chapter 03 · The Current State

The problem is not the tools. It is that nothing governs across them.

A regional system grows by affiliation and acquisition. Each site kept its own EHR, its own security stack, and its own AI. The HQ has an audit standard. The affiliated sites have their own. No single plane sees, governs, or proves what AI is doing across the whole system.

Three silos: HQ Medical Center, Community Hospital, Provider Offices, with no shared governance
This is the pattern behind affiliation and acquisition: capability bought site by site, governance never unified. It is also where the proposed HIPAA asset-inventory and network-map requirements get hardest, because no one holds the whole map.
Chapter 04 · The Target Architecture

A cloud governance plane over the stack you already own.

SpecOps does not replace the EHR or the security tools. It adds the layer none of them provide: enforcement at the moment of action and signed evidence, deployed in a HIPAA-eligible cloud landing zone and wired to whatever each site already runs.

Target architecture: governed AI over the SpecOps plane over BYOL security stack on a HIPAA-eligible cloud landing zone, with HIPAA NPRM controls satisfied
The point of the picture: the gold plane is the only thing being added. It reads every layer below, governs the AI above, and produces the evidence the proposed HIPAA controls on the right will ask for.
Chapter 05 · The Modular Build

Five modules. Each one ships value on its own.

You do not buy the whole architecture at once. Each module is independently useful, maps to a proposed HIPAA requirement, and lands one of the use cases the system already cares about.

MODULE 0 · SHERPA

Discovery, asset inventory, network map

Scan each site's clinical and AI estate, produce the living technology asset inventory and the ePHI network map, and score governance readiness. This is the foundation every other module builds on.

Satisfies: asset inventory and network map · risk analysis
Lands: the whole-system view no single silo has
MODULE 1 · IDENTITY

Access governance at the action layer

Enforce MFA and single sign-on context on every AI action, so an action carries who authorized it. Works with the identity tools each site already runs rather than replacing them.

Satisfies: MFA · access change notification
Lands: who acted, under whose authority, on every action
MODULE 2 · ORCHESTRATOR

The AI governance and In-Flight Gate

Intercept each AI action, check it against live policy and live data, and let it proceed, route it to a clinician, or block it. The signed evidence package is produced as it runs.

Satisfies: continuous oversight · documentation
Lands: prior auth (CMS-0057-F), clinical decision support
MODULE 3 · OVERWATCH

Continuous monitoring and evidence

Watch for drift between approved policy, deployed behavior, and live state. Generate the scan-cadence and restoration evidence on the schedule auditors expect, not at document-recompilation time.

Satisfies: 6-month scans · 72-hour restore readiness
Lands: quality reporting, RADV-grade audit posture
MODULE 4 · FLEX

Interoperability and legacy bridge

Connect FHIR R4 and TEFCA exchange, and bridge the legacy MEDITECH, TruBridge, or office systems that cannot speak modern protocols, so a site joins the governed standard without a forklift migration.

Satisfies: data lineage · network segmentation support
Lands: program integrity, payer-to-payer exchange
ROLLOUT ECONOMICS

The first site funds the foundation

The first site stands up the shared cloud foundation. Every site after inherits it, so per-site work is configuration plus that site's specific adapters. Cost and risk drop with each replication.

Pattern: pilot, prove, replicate, standardize
STEP 1

Pilot one site

A single community hospital or provider group. Modules 0 through 2.

STEP 2

Prove the audit

Show the signed evidence and the asset map a real audit would ask for.

STEP 3

Replicate to affiliates

Each new site inherits the foundation and loads its own adapters.

STEP 4

Standardize at HQ

One policy and one audit standard across every silo, governed centrally.

Chapter 06 · The Compliance Map

Proposed HIPAA controls, mapped to the build.

The HIPAA Security Rule overhaul is still a proposed rule, but it is where the sector is heading. Here is how the architecture answers each major proposed requirement, using the stack you already own plus the governance plane.

Proposed requirementHow the architecture answers itWhere
Multi-factor authenticationEnforced on access and carried into the action context, so every governed AI action records the authenticated authority behind it.MODULE 1 + BYOL IAM
Encryption at rest and in transitCloud landing zone enforces encryption by default; the evidence store and FHIR gateway encrypt in transit.CLOUD ZONE
Network segmentationPer-site and per-tenant segmentation in the landing zone; the governance plane sits at the boundary between AI and data.CLOUD ZONE + FLEX
Asset inventory and network mapSHERPA produces and maintains the living technology asset inventory and the ePHI network map across every silo, reviewed on change.MODULE 0 · SHERPA
Continuous risk analysisOVERWATCH runs continuous monitoring rather than a point-in-time assessment, with risk surfaced as state changes.MODULE 3 · OVERWATCH
Vulnerability scans and penetration testingScan-cadence evidence generated on schedule; testing results tracked to remediation with documentation retained.MODULE 3 + BYOL vuln mgmt
72-hour restoration, 24-hour notificationBackup and recovery evidence and contingency activation signals are captured as governed, time-stamped records.MODULE 3 + BYOL backup
Written documentationPolicies, reviews, and decisions are produced as a byproduct of operation, not recompiled for an audit.GOVERNANCE PLANE

Mapping reflects the proposed rule (NPRM, January 6, 2025). Final requirements and timing may change. This is a positioning architecture, not a compliance opinion.

Chapter 07 · Engage

The platform is SpecOps. SDVOSB Consulting & Services powered by AgileLeap.AI. One governed engagement: the plane in the path, the modular rollout, and the people who stand it up and run it with you, starting at one site and scaling across the system.

Request a working session