Healthcare Technology Architecture, keep Health Tech CALM: A new standard to accelerate development of Healthcare applications

Glenn Keighley
Aug 17
8 min read

Healthcare software in the United States lives at the intersection of safety, privacy and interoperability. Teams building EHR integrations, patient-facing apps, clinical decision support tools, revenue cycle systems and analytics platforms all face the same core challenge: How to make architecture explicit, consistent, auditable and automatable without slowing delivery to a crawl and drowning in documentation management

The Common Architecture Language Model (CALM), an open-source specification from the FINOS “Architecture as Code” community offers a pragmatic solution to these problems. By expressing architecture as machine-readable (and human-readable) code, CALM provides a common vocabulary, a validation toolchain and a runway to automate the governance that healthcare applications demands.

What is CALM?

CALM is a standardized model for describing software architectures as code. CALM captures the systems, components, interfaces and relationships in a structured format that tools can parse, validate and visualize. That same definition remains readable enough that architects, security teams and auditors can review and reason about it together.

CALM’s model is published alongside tooling that makes it practical:

A JSON Meta-Schema defines the shape and constraints of valid architectures. This lets you treat architecture definitions like code - lint, validate, and version them alongside application code.
The CALM CLI can generate architecture “skeletons” from reusable patterns and validate concrete architectures against those patterns, locally or in CI/CD.

The upshot: Creation of a single source of truth for architecture that is both human-meaningful and machine-actionable.

Development roots: Architecture as Code, born in FINOS

CALM emerged from the Architecture as Code (AaC) working group under FINOS (the Fintech Open Source Foundation), itself part of the Linux Foundation ecosystem. The group’s aim was straightforward but ambitious: move architecture into a version-controlled, automatable form to help complex, highly regulated organizations build safer systems faster. The initiative has since “graduated” into a standalone project with its own site and roadmap.

Why CALM fits U.S. healthcare development

U.S. healthcare software teams juggle an unusual mix of regulatory obligations (HIPAA, 21 CFR Part 11, state privacy laws), interoperability mandates (ONC’s Cures Act final rule; widespread FHIR adoption), and security frameworks(NIST 800-53/800-66, HITRUST CSF, SOC 2). Layer on class-of-risk considerations for clinical decision support or SaMD and the result is a development environment where traceability, repeatability, and evidence matter as much as features.

CALM aligns naturally with those pressures:

Traceable design decisions. By keeping architecture definitions in Git, each change to system boundaries, data flows, encryption posture, identity patterns, and third-party dependencies is reviewable, attributable and versioned thus providing the raw material of audit evidence.
Shift-left governance. CALM’s pattern-based validation enables “guardrails not gates.” You encode approved patterns e.g. a FHIR API facade, a PHI data lake ingestion pipeline, or a patient-consent micro-service and validate architectures against them during design and CI/CD.
Continuous compliance posture. Structural checks via JSON Schema plus policy linting via Spectral let you embed controls such as “encrypt PHI in transit and at rest,” “mutual TLS required on east-west links,” or “no egress from clinical subnet without DLP proxy” directly into the model and fail the build if the model violates them.
Interoperability by design. Because CALM is machine-readable, you can automate generation of consistent documentation (for vendor security reviews), visualizations for non-technical stakeholders, and even mappings to FHIR resources and endpoints specified in your architecture patterns.
Safer velocity. Healthcare orgs often hesitate to adopt new patterns (e.g., streaming ingestion for device data) because of governance drag. A pre-approved CALM pattern lets teams reuse a known-good template, cutting debate cycles while preserving safety.

The net effect is a measurable reduction in governance toil and better audit readiness without a hit to delivery speed.

What CALM can replace (or modernize)

CALM doesn’t demand you abandon every tool you already use. It replaces brittle artifacts and streamlines governance efforts that cause the most pain today:

Static diagrams (Visio, draw.io, one-off C4 exports) are replaced with CALM definitions that drive generated diagrams; these stay in sync with architecture because they’re derived from the same source.
Ad-hoc design docs in Confluence or SharePoint are replaced with versioned architecture files plus short, curated narratives. The model holds the “facts” while prose captures context and intent.
Manual Architecture Review Boards that review documentation artifacts in a variety of formats are replaced by automated checks in PRs and pipelines using the CALM CLI to validate against approved patterns and policy rules.
Inconsistent “security by checklist” approach to security is replaced by codified controls e.g. mTLS required between services of class X or “PHI never traverses public network segments” are enforced by schema and lint rules (JSON Schema + Spectral).
Spreadsheet inventories of services, data stores, and flows are replaced by CALM as living inventory, queryable by scripts and exportable to compliance evidence packs.
One-off “best practice” templates for API gateways, event streams, or data platforms
are replaced by reusable CALM patterns that teams can generate from, ensuring every new service starts compliant by default.

Where CALM fits in the SDLC

Think of CALM as a governing thread that runs from idea through operations:

Inception & architecture sketching
- Pick a relevant pattern (e.g. “External FHIR API with zero-trust gateway and token introspection”).
- Use [calm generate] to scaffold the architecture file and add system-specific details.
Design & security review (shift-left)
- Run [calm validate] against the pattern.
- Add custom Spectral rules for org-specific policies
- Iterate until validation passes.
Pull request discipline
- Keep the CALM file in the repo next to the service code or IaC.
- CI runs validation on every PR and blocks merges on violations; reviewers now see a consistent, diff-able architectural change set.
Implementation alignment
- Generate artifacts from the model (docs, diagrams, inventories, even seed configs).
- Map architecture elements to IaC modules and API specifications so drift is detectable.
Pre-release/continuous compliance
- Nightly pipeline re-validates the live “intended” architecture against patterns and policies. Discrepancies trigger alerts.
Operations & audit
- Use the model to answer auditors quickly: Data lineage, encryption posture, identity boundaries, vendor exposure and change history are all visible.
- When an incident happens, the blast radius and dependency graph are already modeled.

A five-minute “quick start” guide on the CALM site illustrates getting hands-on with the CLI and patterns; most teams can prototype a working flow within a sprint.

Concrete healthcare use cases

To make this less abstract, here are high-value scenarios where CALM pays off fast:

FHIR API platform governance
- Pattern: External API with SMART on FHIR/OAuth 2.0, token introspection, audited access logging and consent checks at the boundary.
- Validation: Ensure every external endpoint terminates at an approved API gateway.
  - Require mTLS on partner links
  - Require a PII/PHI data-classification tag on every resource and deny “open” routes.
- Outcome: New APIs ship without re-debating the basics. Variance is justified as an exception and auto-flagged.
Clinical data lake ingestion
- Pattern: Immutable storage with encryption at rest, key custody requirements, DLP-gated egress and audited transformation jobs.
- Validation: Prohibit public network paths from ingestion agents; require “break-glass” controls for re-processing PHI; enforce scrubbing/psuedonymization before analytics tiers.
SaMD feature isolation
- Pattern: Safety-critical components isolated with explicit runtime constraints and telemetry sinks; model includes rationale and traceability to hazards/risks.
- Validation: Required telemetry “safety” signals exist; dependencies don’t backdoor critical paths.
Vendor integration onboarding
- Pattern: Standard partner connectivity using managed integration platform with pre-approved data contracts.
- Validation: DPIA/TPRM tags attached; data scope constraints enforced at the boundary; no partner-controlled secrets.
Zero-trust rollout
- Pattern: Service-to-service identity using workload identities and policy enforcement points.
- Validation: Reject patterns that rely on network location alone; require mutual TLS and short-lived tokens.

Novel software development benefits unlocked by CALM

Plenty of frameworks promise “better architecture.” CALM’s specific combination of model + patterns + CLI validation yields several distinctive advantages:

Policy-as-Model, not just Policy-as-Code: Most orgs put policy in code (OPA, Gatekeeper, CI checks) or documents. CALM lets you declare policy expectations about architecture itself and validate them before code exists. You can make it impossible to define an architecture that routes PHI through an unapproved path. (CALM’s JSON Schema base plus Spectral rules make this dual-layer validation concrete.)
Reusable architecture patterns as “golden paths”: Instead of slide-deck blueprints, CALM lets you ship living patterns the CLI can generate from. Architects define once and many teams safely reuse. This is powerful in distributed technology organizations with dozens of product teams.
Automated evidence for auditors: Because architecture changes live in Git and pipelines, evidence can be produced on demand. E.g. Who approved the PHI boundary change, when the encryption standard was tightened, which systems expose FHIR endpoints and how consent enforcement is instrumented.
Fewer meetings, faster decisions: CALM shrinks “big-room” architecture review time. If you pass validation against approved patterns and policies, your change is presumptively okay. Reviewers can focus on the interesting 10% that truly needs discussion.
Safer platform evolution: Platform teams can iterate patterns (e.g., moving from API keys to OAuth, or rolling out mutual TLS or standardizing data-masking) and measure adoption across the portfolio by querying CALM models then nudge stragglers with facts.
Better cross-functional collaboration: Security, compliance, privacy, and clinical teams can read the same model the builders use. The vocabulary is consistent because diagrams are generated from the same source. This cuts translation errors and speeds alignment.
Foundation for automated controls: Community work has focused on pattern validation (AJV/JSON Schema) and linting. As the ecosystem matures, expect more generators (docs, diagrams, maybe even IaC stubs) and control integrations, a strong fit for organizations pursuing continuous compliance.

Practical adoption path for a health tech team

You don’t need a grand rewrite to extract value. A pragmatic rollout looks like this:

Pick one product area where governance pain is high (external APIs, data ingestion, or third-party integrations).
Define a CALM pattern that encodes your non-negotiables (e.g., “all external traffic terminates at gateway X; PHI only stored in Y; mTLS on service mesh; audit logs to Z”).
Install the CALM CLI and wire [calm validate] into the repo’s CI. Start in “warn” mode, then move to “fail on error.”
Scaffold a new service from the pattern using [calm generate] and compare the experience to your current “new service” template.
Publish the pattern and socialize it: Explain how and why it speeds delivery and strengthens safety.
Iterate rules as you learn (e.g. codify exceptions you keep seeing).
Expand pattern coverage to the next high-value domain (data platforms, messaging, or identity).
Track adoption by querying repos for CALM models and validation results; use those metrics in governance reporting.

Most organizations can pilot this approach within a sprint or two. The project quick-start provides a working example to copy.

FAQs

Is CALM tied to specific vendors or clouds?

No. The model is vendor-neutral. Your patterns can describe principles (e.g., “mutual TLS everywhere”) and approved implementations (e.g., “Istio PeerAuthentication: STRICT, Envoy SDS enabled”) while remaining portable.

We already use C4, ADRs, and IaC. Do we need another layer?

CALM complements these: C4 remains a great communication view; ADRs capture rationale; IaC implements infrastructure. CALM becomes the machine-readable architecture backbone that ties them together and keeps them consistent.

Is the tooling mature enough?

The project is active (recent CLI releases, pattern validation improvements, community sessions). As with any OSS, you’ll occasionally hit issues but the fundamentals (JSON Schema-based validation, Spectral linting, CLI workflows) are solid and already usable in pipelines today.

A brief comparison to legacy “standards”

Healthcare has long leaned on documentation standards (template SDDs/SADs), diagram notations (UML), and process gates (formal ARBs). These still have value, but they don’t enforce conformance or enable automation. CALM’s key differentiator is that it transforms architecture into a verifiable, enforceable artifact:

UML/C4 give you consistent pictures; CALM gives you consistent models you can test.
Checklists catch drift intermittently; CALM validation catches it continuously.
One-off templates guide teams loosely; CALM patterns generate compliant starting points and prove conformance on every change.

The bottom line

Healthcare’s challenge is not a shortage of architectural wisdom, it’s a shortage of consistency, visibility, and automation across many teams, vendors, and risk classes. CALM, born from the FINOS Architecture as Code community, offers a practical way to institutionalize good architecture through machine-readable models, reusable patterns, and automated validation. That aligns perfectly with health tech's need for auditability and interoperability, without forcing organizations to trade away speed.

Adopt CALM where governance friction is hurting delivery the most. External APIs, PHI data flows, or vendor connections. Encode what “good” means once, reuse it everywhere, and let the toolchain do the heavy lifting. Your architects will spend less time policing and more time solving real, clinical and operational problems. And when an auditor asks, “How do you know this system is safe?” you’ll have more than a diagram; you’ll have evidence.