Skip to content

Terminology as a Service (TaaS) Gate

Intent

Run $expand/$validate-code/$lookup in CI against a pinned terminology environment.

Structure

A TaaS gate is a small CI suite that runs standard terminology operations against a pinned server/environment. Structurally it includes: endpoint configuration, pinned content versions, a cache policy, and golden test vectors.

  • Endpoint config: a documented base URL + auth approach (if needed), used consistently across CI and local runs
  • Pinned content: explicit versions of code systems/value sets required for deterministic results
  • Cache policy: rules for when cached expansions are allowed and how to detect drift
  • Golden vectors: small inputs with expected invariants/outcomes (including expected failures)
  • Reporting: CI artifacts that explain exactly what failed (operation, parameters, expected vs actual)

Key Components

Terminology server

  • Select a server that supports required operations ($expand/$validate-code)
  • Define availability and performance expectations
  • Ensure licensing/realm constraints are understood
  • Document endpoint usage and authentication
  • Provide a fallback strategy for outages

Pinned versions

  • Pin terminology content versions used for CI
  • Record versions in the repo and release notes
  • Avoid ‘latest’ expansions for critical ValueSets
  • Validate pinning in clean environments
  • Update pins intentionally with change impact checks

Cache strategy

  • Decide when cached expansions are acceptable
  • Prevent silent cache drift across environments
  • Document cache invalidation rules
  • Keep CI deterministic and reproducible
  • Monitor cache size/performance impacts

Golden test vectors

  • Create small, representative code sets for tests
  • Include edge codes and expected failures
  • Store expected outputs (or invariants) in repo
  • Run vectors across multiple servers where possible
  • Update vectors as part of controlled releases

Behavior

CI terminology verification

The gate runs fast checks on every PR and fuller checks on a cadence.

PR gate (fast)

  • Run $validate-code for high-risk bindings.
  • Run $expand for a small set of critical ValueSets.
  • Fail builds on unexpected drift or unavailable terminology operations.

Scheduled gate (deep)

  • Run broader expansion and mapping checks.
  • Compare results across servers if you support multiple environments.
  • Publish drift reports and propose pin updates via controlled PRs.

Benefits

  • Catches drift early
  • Cross-product consistency

Trade-offs

  • Requires stable CI environment

References