Moonlitic × HL7 FAST Coverage

Mapping Moonlitic's Infrastructure Against the Five Pillars of FHIR At Scale

May 2026

Confidential

Built

Partial

Planned

Gap

What Is HL7 FAST?

The FHIR At Scale Taskforce (FAST) is an HL7 accelerator that identifies ecosystem-wide barriers to deploying FHIR at scale, defines solutions to address those barriers, and develops the infrastructural standards to support nationwide FHIR implementations. FAST is now a direct compliance pillar — TEFCA requires FAST Security compliance by January 1, 2026, and ONC's HTI-2 rule references FAST specifications for FHIR exchange.

FAST organizes its work into five pillars, each with its own FHIR Implementation Guide (IG), reference implementation, and conformance criteria. Together they form the infrastructure layer that any platform exchanging health data at scale must implement.

Pillars

Security · Identity · Consent · Directory · Testing

Published IGs

Security STU2 · Identity STU2 · NDH STU1 · Consent (Ballot)

TEFCA Deadline

Jan 2026

FAST Security (UDAP SSRAA) required for FHIR exchange

Regulatory Anchor

HTI-2

ONC final rule references FAST specifications

The Five FAST Pillars

🔒 Pillar 1 — FAST Security (UDAP SSRAA)

Extends OAuth 2.0 with UDAP workflows for scalable, certificate-based trust. Covers dynamic client registration, JWT-based authentication, Tiered OAuth, and B2B authorization — all bound to X.509 certificates within a multi-party trust framework.

Dynamic Client Registration using signed software statements (JWT with X.509 chain)
Token endpoint authentication via private_key_jwt with asymmetric keys
Authorization code flow for consumer-facing apps; client credentials for B2B
Tiered OAuth for cross-organizational trust delegation
Discovery via .well-known/udap metadata endpoint
X.509 certificate chain validation, including trust community anchors
Manual registration resolution within 5 business days (TEFCA requirement)

🆔 Pillar 2 — FAST Identity (Digital Identity & Patient Matching)

Establishes consistent digital identity across networks. Enhances the FHIR $match operation for cross-organizational patient matching, defines identity assurance levels, and provides guidance on credential binding.

Digital Identifier with AAL2+ authentication assurance
Identity assurance level IDIAL1.8 or higher for credential binding
Enhanced FHIR Patient $match for cross-organizational lookups
Weighted input scoring for probabilistic matching
Historical demographic data to improve match rates
Organizational identity via digital certificates with verified attributes
Differentiation of user vs. patient identity roles

✅ Pillar 3 — FAST Consent Management

Defines how organizations capture, share, and enforce patient consent directives using FHIR Consent resources. Bridges Identity (who) and Security (trust) to ensure every transaction is consented, compliant, and auditable.

Electronic capture, update, and revocation of consent directives
Computable consent using FHIR Consent resources
Cross-organizational consent sharing and enforcement
Consent-to-data linkage — every exchange governed by consent scope
Audit trail for consent lifecycle events
Interoperable consent format across network boundaries
Currently in HL7 ballot; publication expected early 2026

📖 Pillar 4 — FAST National Directory (NDH)

National source of truth for providers, organizations, services, and electronic endpoints. Enables automated endpoint discovery, capability signaling, and program participation indicators.

FHIR-based directory of providers, organizations, and services
Electronic endpoint discovery and capability signaling
Attestation and verification workflows for directory data
FHIR API + subscription-based exchange for local directories
Bulk data export for directory synchronization
Program participation indicators (TEFCA, CMS networks)
NDH STU1 published April 2025; STU2 targeted 2026 ballot

🧪 Pillar 5 — FAST Testing & Conformance

Testing infrastructure and conformance tooling that validates implementations against FAST IGs. Includes reference implementations, test kits, and connectathon events.

Reference implementations for Security, Identity, Directory, and Consent
Test kits (identity-matching-test-kit, UDAP test suites)
Connectathon tracks for Security, Identity, Consent, and Directory
Conformance validation against published IGs
Interoperability testing across TEFCA QHINs and CMS-aligned networks

Alignment Matrix — Moonlitic vs. FAST

Pillar	FAST Requirement	Moonlitic Capability	Status
Security OAuth 2.0 + SMART on FHIR	OAuth 2.0 authorization framework with scoped access tokens for FHIR APIs	OAuth 2.0 implemented across all engines; SMART on FHIR authentication patterns; scoped access tokens for patient portal, clinician portal, and marketplace APIs	BUILT
Security UDAP Dynamic Registration	Dynamic client registration using signed software statements (JWT + X.509 certificate chain)	OAuth 2.0 client registration exists; needs UDAP-specific extension with X.509 certificate chain validation, signed software statements, and `.well-known/udap` discovery metadata	PARTIAL
Security JWT Client Authentication	Token endpoint auth via `private_key_jwt` with asymmetric cryptographic keys bound to digital certificates	JWT-based authentication implemented; AES-256 encryption throughout; asymmetric key infrastructure in place for consent engine; needs formal `private_key_jwt` binding to X.509 certificates per UDAP spec	PARTIAL
Security Tiered OAuth / B2B Authorization	Cross-organizational trust delegation; client credentials flow for B2B; Tiered OAuth for federated trust	Marketplace uses buyer/seller authorization with scoped access; B2B data exchange with consent-gated access controls; needs formal Tiered OAuth implementation for cross-network federation	PARTIAL
Security Encryption at Rest & Transit	TLS 1.2+ for transport; encryption at rest for PHI	AES-256 end-to-end encryption; TLS 1.3; Azure Confidential Ledger for immutable audit; field-level encryption for sensitive data categories; FIPS 140-2 key management	BUILT
Identity Digital Identity Binding	Digital identifier with AAL2+ authentication; IDIAL1.8+ identity assurance; credential binding across organizations	Clear integration for identity verification; OIDC-based patient identity; needs formal AAL2 + IDIAL1.8 conformance tagging and cross-organizational credential binding per FAST Identity STU2	PARTIAL
Identity Patient $match Operation	Enhanced FHIR Patient `$match` for cross-organizational matching with weighted inputs and match grades	Patient identity resolution across data sources; FHIR Patient resource management; deterministic matching via MRN, SSN, DOB; needs formal `$match` operation endpoint with weighted scoring per FAST IG	PARTIAL
Identity Provider/Organization Identity	Organizational identity via digital certificates with verified attributes and NPI/taxonomy binding	Clinician portal with NPI-linked provider profiles; organization-level access controls in marketplace; provider identity verified via EHR integration; certificate-based organizational identity is a packaging exercise	BUILT
Consent Computable Consent Directives	Electronic capture using FHIR Consent resources; machine-readable consent scope; cross-organizational enforcement	Sub-5ms consent lookup; 9 granular consent categories; FHIR Consent resource representation; per-resource + per-action scope (read/write/delete/query); special category handling (Genetic, Mental Health, HIV); GDPR Article 6 compliance	BUILT
Consent Consent Lifecycle Management	Create, update, revoke consent with full audit trail; event-sourced lifecycle	Event-sourced consent lifecycle (Cosmos DB); real-time toggle in patient portal; 30-second revocation propagation to all downstream buyers; SHA-256 hash-chained audit of every consent event; 7-year retention	BUILT
Consent Cross-Org Consent Sharing	Interoperable consent format that travels with data across organizational boundaries	Consent-to-data linkage across marketplace; every downstream use audited; consent travels with data via provenance chain; interoperable format aligns with FHIR Consent resource structure	BUILT
Directory Endpoint Discovery	FHIR-based endpoint discovery; capability signaling; program participation indicators	FHIR R4 API endpoints published across all engines; capability statement served; needs formal NDH-compliant Endpoint resources with capability signaling and participation indicators per NDH IG	PLANNED
Directory Provider/Org Directory	National directory profiles for Practitioner, Organization, HealthcareService, Location with attestation and verification	Clinician portal manages provider profiles; marketplace maintains organization directory; NPI-linked practitioner records; needs NDH profile conformance and attestation/verification workflows	PLANNED
Directory Directory Sync & Subscription	FHIR API + subscription + bulk data export for synchronizing national → local directory	Bulk data export capabilities exist in data aggregation engine; FHIR Subscription patterns for real-time updates are architecturally planned; needs NDH sync protocol implementation	PLANNED
Testing Conformance Testing	Validate implementation against FAST IGs using test kits and reference implementations	QA test suites for all 7 engines; HEDIS validation against real LOINC/CPT/ICD-10 codes; API contract tests; needs formal FAST IG conformance test harness integration (identity-matching-test-kit, UDAP test suite)	BUILT
Testing Interop Testing / Connectathon	Participate in FAST connectathons; test cross-network exchange with QHINs and CMS networks	FHIR R4 APIs ready for connectathon testing; Da Vinci workflow compliance (CRD→DTR→PAS); CMS-0057-F compliance built; needs formal FAST connectathon participation and cross-QHIN validation	BUILT
Testing TEFCA FHIR Exchange Readiness	Full compliance with TEFCA FHIR exchange requirements including FAST Security by Jan 2026	FHIR R4 APIs, OAuth 2.0, consent enforcement, audit trails all operational; UDAP-specific extensions (Rows 2-4 above) close the remaining gap; on track via ATTEST Gate 3 timeline	BUILT
Cross-Cut HTI-2/HTI-5 Alignment	ONC rules reference FAST specs; FHIR API availability requirements; authorization/provenance behavior	FHIR R4 APIs across all engines; CMS-0057-F prior authorization compliance; consent representation using FHIR Consent resources; needs formal HTI-5 traceability matrix mapping Moonlitic endpoints to rule requirements	BUILT
Cross-Cut Provenance & Audit	Data provenance tracking; audit trails; lineage across organizational boundaries	5-layer provenance: ACL immutable ledger (Azure Confidential Ledger), hash-chained audit logger, consent event sourcing (Cosmos DB), HIPAA audit middleware, anonymization manifests; signed DAG approach for cross-boundary provenance	BUILT

Across 20 FAST requirements, Moonlitic scores 12 BUILT, 5 PARTIAL, 3 PLANNED, and 0 GAP.

Every PARTIAL requires extending existing infrastructure. Every PLANNED item is a conformance packaging exercise against published IGs — not net-new engine work.

Zero architectural gaps. Zero net-new engines required.

Path to Full Coverage — Closing 5 PARTIALs + 3 PLANNEDs

Each item below has existing Moonlitic infrastructure underneath it. The work is extension, packaging, or formal conformance — not invention.

UDAP Dynamic Registration + Discovery

What's Built:

OAuth 2.0 client registration; JWT authentication infrastructure; FHIR API endpoints with capability statements.

What's Missing:

Signed software statement (JWT with X.509 chain) for dynamic registration; .well-known/udap metadata endpoint; trust anchor certificate validation; UDAP-specific discovery response format.

Timeline: 4–6 weeks. This is an API surface extension — the OAuth infrastructure, JWT signing, and FHIR endpoints already exist. The work is implementing UDAP-specific message formats and adding the X.509 trust chain validation layer.

Private Key JWT + X.509 Certificate Binding

What's Built:

JWT-based auth; AES-256 encryption; asymmetric key infrastructure for consent engine; FIPS 140-2 key management.

What's Missing:

Formal private_key_jwt token endpoint authentication method; X.509 certificate binding for client identity; certificate chain validation against trust community anchors.

Timeline: 3–4 weeks. Largely co-delivered with UDAP Dynamic Registration (above). The cryptographic primitives exist — the work is binding them to the UDAP-specified token endpoint flow.

Tiered OAuth / B2B Federation

What's Built:

Marketplace buyer/seller authorization; consent-gated B2B access controls; scoped token issuance.

What's Missing:

Formal Tiered OAuth implementation where a downstream authorization server can delegate trust to an upstream server; cross-network federation handshake; trust community participation signaling.

Timeline: 6–8 weeks. This is the most substantive security extension. The marketplace already models multi-party trust (patient → Moonlitic → buyer), but the formal Tiered OAuth protocol for TEFCA cross-QHIN federation needs implementation.

FAST Identity — AAL2 + IDIAL1.8 Conformance

What's Built:

Clear identity verification integration; OIDC-based patient identity; provider NPI binding; ATTEST R1 identity continuity roadmap (Datavant integration path).

What's Missing:

Formal AAL2 conformance tagging on authentication flows; IDIAL1.8 identity assurance level attestation; cross-organizational credential binding per FAST Identity STU2; integration with FAST identity-matching-test-kit for validation.

Timeline: 6–8 weeks. Clear already provides the identity proofing — the work is formally tagging assurance levels per FAST Identity IG and exposing the $match endpoint with weighted scoring. Dovetails with ATTEST R1 timeline.

FHIR Patient $match Operation

What's Built:

Patient identity resolution across data sources; deterministic matching (MRN, SSN, DOB); FHIR Patient resource management across all engines.

What's Missing:

Formal FHIR $match operation endpoint; weighted input scoring; probabilistic matching with match grade responses; historical demographic data support per FAST Identity IG.

Timeline: 4–6 weeks. The patient data model and matching logic exist. The work is exposing a conformant $match endpoint that returns weighted match grades and integrates with historical demographics. Can run in parallel with Identity Binding work above.

NDH Endpoint Discovery & Capability Signaling

What's Built:

FHIR R4 API endpoints across all 7 engines; CapabilityStatement served; marketplace directory of organizations.

What's Missing:

NDH-conformant Endpoint FHIR resources; capability signaling metadata; program participation indicators (TEFCA, CMS network membership); .well-known discovery integration.

Timeline: 4–6 weeks. Conformance packaging — the endpoints exist; the work is wrapping them in NDH-profile FHIR Endpoint resources with the required metadata.

NDH Provider/Organization Directory Profiles

What's Built:

Clinician portal with NPI-linked provider profiles; marketplace organization directory; location and service metadata.

What's Missing:

NDH-profile conformance for Practitioner, Organization, HealthcareService, Location resources; attestation and verification workflows; network affiliation resources.

Timeline: 6–8 weeks. The data exists in Moonlitic's clinician and marketplace engines. The work is re-profiling to NDH IG specifications and adding attestation/verification metadata.

NDH Directory Sync & Subscription

What's Built:

Bulk data export capabilities in data aggregation engine; real-time event patterns (consent event sourcing, marketplace notifications).

What's Missing:

FHIR Subscription for directory change notifications; NDH-specific bulk export operation for national→local sync; scheduled exchange protocol.

Timeline: 4–6 weeks. Event-driven patterns exist across Moonlitic. The work is implementing NDH-specific subscription topics and bulk export profiles for directory data.

Total Effort to Achieve Full FAST Coverage

5 PARTIAL items + 3 PLANNED items = 8 work packages

All run in parallel across 3 tracks:

Security Track (UDAP + JWT + Tiered OAuth): ~8 weeks | Identity Track (AAL2 + $match): ~8 weeks | Directory Track (NDH profiles + sync): ~8 weeks

~8 weeks of parallel engineering to move from 12 BUILT → 20 BUILT

All 8 items run in parallel. Consent pillar (3/3 BUILT) and Testing/Conformance (3/3 BUILT) require no additional work. FAST Consent IG publication (early 2026) validates Moonlitic's existing consent architecture.

Strategic Position

Why Moonlitic Is Ahead

Consent Is the Hard Part — and It's Done: FAST's Consent pillar is the newest and least implemented across the industry (still in ballot). Moonlitic has a production-grade consent engine with sub-5ms lookup, 9 categories, event-sourced lifecycle, and 30-second revocation. Most platforms haven't started.
Provenance Exceeds FAST Baseline: FAST doesn't have a dedicated provenance IG yet — it relies on FHIR Provenance resources and audit guidance. Moonlitic's 5-layer provenance chain (ACL ledger + hash-chained audit + event sourcing + HIPAA middleware + anonymization manifests) exceeds any current FAST specification.
Security Gaps Are Surface-Level: The 3 PARTIAL items in Security (UDAP registration, JWT binding, Tiered OAuth) are protocol-level extensions on top of existing OAuth 2.0 + AES-256 + FIPS 140-2 infrastructure. The cryptographic foundation is in place.
Identity Converges with ATTEST: FAST Identity alignment (AAL2/IDIAL1.8, $match) and ATTEST R1 (Identity Continuity) share the same integration path — Datavant's identity layer + Clear verification. One effort retires both requirements.
Directory Is the Easiest Lift: NDH conformance is a profiling exercise. Moonlitic already manages provider and organization directories — the work is re-packaging existing data in NDH FHIR profiles and adding attestation metadata.

FAST + ATTEST Convergence

FAST Security directly supports ATTEST's GPA (Guardrailed Portable Authorization) — both require machine-verifiable authorization constraints enforced at export gates
FAST Identity maps to ATTEST R1 (Identity Continuity) — cross-organizational credential binding without centralized registry
FAST Consent validates ATTEST's Authorization Verification primitive — Moonlitic's consent engine is the implementation proof point
FAST Directory enables ATTEST's Interoperability Validation — endpoint discovery and capability signaling are prerequisites for cross-network exchange
Every FAST investment doubles as ATTEST gate-readiness. No wasted effort.