Continuous Change in Healthcare Systems, Architecture for Data, Security, and Mission Outcomes

Conversation with Khalil Zebdi, Executive Vice President of Federal Business Development, and Hannah Khan, Business Analyst.  

Hannah Khan (HK): Khalil, earlier this year you described healthcare cybersecurity as entering an “autonomy era,” where interoperability, continuous authorization, machine-readable evidence, and security telemetry converge to navigate the evolving cybersecurity landscape. Has that idea evolved further, or has the conversation shifted?

Khalil Zebdi (KZ): It’s the same trajectory, just more in-depth.

Previously, we talked about how cybersecurity functions in a continuously changing environment. You made a great point: it cannot remain periodic; it must become continuous. Evidence must be system-adjacent, authorization must reflect the current state, and security must be driven by telemetry, provenance, and machine-verifiable signals, but once that evidence is accepted, a larger architectural question emerges: Why is cybersecurity the only discipline engineered for continuous change?

Healthcare is modernizing everything at once… the cloud, APIs, FHIR, identity, observability, pipelines… if each evolves independently, we don’t prevent isolation; we multiply it.

The real problem is composition under continuous change.

From Cloud Migration to Platform Architecture

HK: Cloud adoption is now widespread. What actually distinguishes “being in the cloud” from being cloud-anchored?

KZ: The difference is in the way the architecture operates, not just where it's hosted, AKA capability versus location. Running workloads in cloud infrastructure does not, by itself, change architecture. In many cases, it simply relocates legacy systems into a new environment without altering their structural behavior. A cloud-anchored enterprise abstracts shared capabilities into a platform layer that is consumed consistently across the organization. This includes identity, compute orchestration, secrets management, API gateways, observability, configuration management, security policy enforcement, deployment automation, data services, and compliance telemetry.

At ASSYST, this model is implemented through the Green Accelerator, our Application Platform as a Service (aPaaS), which standardizes these capabilities into a governed platform layer designed for reuse and consistency.

This architectural shift is significant; infrastructure becomes code-focused rather than manually configured, environments become reproducible rather than uniquely constructed, configuration drift becomes detectable rather than implicit, artifacts become traceable across their lifecycle, and policy enforcement moves earlier into the build, deployment, and runtime process rather than being applied only after deployment.

In this model, cloud maturity is not measured by migration percentage; it is measured by how effectively shared capabilities are consumed across the enterprise.

Modernization as a Continuous System

HK: How does modernization continue to evolve beyond cloud adoption?

KZ: Traditional modernization assumes systems are static targets that can be incrementally replaced. That assumption breaks down in healthcare because the environment surrounding those systems is also continuously evolving; regulations, clinical workflows, integration requirements, and security expectations all change in parallel.

ASSYST’s modernization platform PhoenixGA treats modernization as a continuous engineering pipeline rather than a discrete project lifecycle. Systems are continuously analyzed for dependencies, decomposed into services where appropriate, reconstructed using API-first principles, embedded with security controls, and refactored as part of an ongoing delivery process. In this model, modernization is no longer a one-time transformation effort; it becomes a runtime capability embedded into the engineering system itself.

Interoperability as a Contract System

HK: Interoperability has been a long-standing goal. What has changed during the push to achieve it?

KZ: The most important change is the level of abstraction at which interoperability is defined. In the past, interoperability was treated as point-to-point data exchange, which led to interface proliferation and weak integration patterns. Modern interoperability is increasingly API-driven, identity-aware, and event-oriented, with FHIR serving as a foundational but still insufficient standard. True interoperability requires more than structural compliance. It requires consistent resource versioning, well-defined terminology binding, reliable identity efforts, enforceable consent mechanisms, traceable provenance, and clearly defined event semantics.

The objective is what we refer to as data liquidity; the ability for authorized data to move across systems without requiring repeated integration work. This aligns with federal direction from the Office of the National Coordinator for Health Information IT (ONC) and the Centers for Medicare & Medicaid Services (CMS), where interoperability is increasingly defined as operational behavior rather than static connectivity. In this context, ASSYST supports ONC eRx and Real-Time Prescription Benefit (RTPB) conformance testing, ensuring systems behave consistently under real-world transaction conditions rather than simply conforming to specifications in isolation.

Therefore, interoperability is not validated by implementation alone; it is validated by behavior under operational conditions.

The Architecture of Seven Contracts

HK: If we look beyond the basic transport of data, what else is required for true interoperability? 

KZ: Interoperability only becomes meaningful when it is expressed as a system of explicit contracts rather than implicit assumptions embedded in code. These seven contracts are transport, semantic meaning, identity resolution, authorization rules, provenance tracking, data quality expectations, and operational behavior such as latency, availability, and versioning. When these contracts are clearly defined and consistently enforced, integration stops being a collection of custom implementations; it becomes infrastructure that can be reused, governed, and evolved systematically.

Data Products as a Reusable Asset

HK: How do data products change the model?

KZ: Data products shift the focus from storage-centric to meaning-centric architecture. Instead of treating data as raw material stored in centralized systems, a data product defines ownership, semantics, quality expectations, freshness guarantees, lineage, and access policies as part of its design.

Without this structure, every consuming team must reinterpret the same data independently, leading to duplicated logic and inconsistent outcomes. 

With data products, the enterprise begins to reuse meaning itself rather than repeatedly reconstructing it through separate pipelines.

Composability and the Cost of Change

HK: Is composability more important than modernization?

KZ: In healthcare, composability is increasingly more important than traditional modernization because the system is never in a finished state. The primary objective is not architectural elegance in isolation, but reducing the cost of change over time.

Composable systems achieve this by enforcing loose coupling between components, supporting versioned interfaces, enabling observability across services, allowing components to be replaced without systemic disruption, and isolating policy enforcement from application logic. In this context, the value of architecture is not measured by the number of systems deployed, but by how easily those systems can evolve without destabilizing the broader environment.

Cybersecurity as a Runtime Property

HK: How does cybersecurity fit into this model?

KZ: We need to stop treating cybersecurity as a periodic audit and start treating it as a live, runtime feature of the system. Instead of relying on periodic assessments, the system should continuously emit evidence about its own state, including configuration integrity, identity posture, vulnerability exposure, dependency health, runtime behavior, and access patterns. The core risk in modern environments is not change itself, but the separation between documented state and actual state. This is why continuous validation has become central to emerging frameworks, such as FedRAMP 20x, which emphasizes machine-readable evidence and ongoing verification rather than static authorization artifacts.

Within this model, ASSYST’s ComplySyncATO platform connects CI/CD pipelines, vulnerability scanning, control mapping, POA&M workflows, and OSCAL-aligned artifacts into a continuous authorization system. The objective is not just to automate compliance processes, but to reduce the latency between technical change and risk understanding.

Drift: The Hidden System Failure

HK: Why is drift so important?

KZ: Drift represents the divergence between intended system state and actual system state, and it is one of the most significant failure modes in complex environments. It occurs across infrastructure, identity systems, APIs, data schemas, configuration layers, security controls, and dependencies. The risk is not that systems change, but that they change without being detected or reconciled against their expected state. In mature architectures, drift is treated as a first-class metric because it directly reflects system integrity over time.

Observability Beyond Monitoring

HK: Where does observability fit into the picture?

KZ: Observability extends beyond traditional monitoring by focusing not just on system status, but on system behavior. In healthcare environments, this requires correlating metrics, logs, traces, events, data quality signals, and security telemetry into a unified understanding of system performance. A system may appear operational from an infrastructure perspective while simultaneously failing at the level of clinical or operational outcomes. Observability is what allows those discrepancies to be detected and understood.

Continuous Assurance as a System Property

HK: Is continuous assurance a cybersecurity concept?

KZ: Continuous assurance is broader than cybersecurity. It’s a system-level property that ensures confidence in security, data integrity, service reliability, configuration correctness, and software trustworthiness at the same time. It sits at the intersection of engineering, operations, and governance, and depends on continuously correlating technical state with risk and compliance expectations.

Evidence as a By-Product of Engineering

HK: What is the most important design principle?

KZ: That evidence should be produced as a natural by-product of engineering activity rather than reconstructed after the fact. Modern systems already generate the necessary signals, code changes, build outputs, deployment records, test results, runtime behavior, access logs, and configuration states. The architectural requirement is to preserve, correlate, and make this information usable for assurance without requiring manual reconstruction.

From Modernization to Mission Capacity

HK: How do you measure success?

KZ: Success should be measured in terms of mission capacity rather than technology deployment. The key question is not how many systems have been modernized, but how effectively the organization can deliver outcomes. This includes improvements in delivery speed, integration efficiency, authorization timelines, system reuse, and responsiveness to change. In government healthcare environments, these improvements directly translate into faster policy execution and reduced operational overhead.

Overall  Perspective

HK: Do you have any final thoughts?

KZ: Healthcare transformation is no longer about modernization programs. It’s about building systems that can evolve continuously without losing control, visibility, or trust. Cloud makes infrastructure programmable, platform engineering makes capabilities reusable, interoperability makes exchange composable, data products make meaning reusable, observability makes system behavior visible, cybersecurity makes change governable, and continuous assurance makes trust continuous.

At ASSYST, these ideas converge across Green Accelerator, PhoenixGA, and ComplySyncATO, each addressing a different layer of the same challenge: operating healthcare systems under continuous change.

Modernization is no longer a transformation event; it is a system property.