Standards analysis
CAN-spec normative-statement testability register
The shape of the document
- 11 statements sit outside the range the document’s own conformance clause covers (§§3–14 + §15) — including every normative keyword in §16’s July 4, 2026 requirements.
- 4 statements carry normative keywords inside editorial callouts (proposals, TODOs, contingency notes).
- 7 statements use a prose-cased keyword where the rest of the document bolds them.
- The document defines no requirement identifiers — statements are addressable only by section — so this register mints stable ids (never renumbered; retired instead) with a line-anchored permalink each.
What this register is, and is not
The source is https://github.com/icanbwell/cms-ns at commit a05a1a73f9e7 (editor’s draft, 2026-06-22), file sha256 515959b162f8e7a2…. The draft publishes no license, so its sentences are never reproduced here: every row is our own paraphrase plus a permalink to the exact source line at that commit and a digest of the line — anyone can verify every claim against the same bytes we read.
Classifications are editorial judgments, reviewed 2026-07-27. Next expected event: A new can-spec draft publishing (0.5+ or a first published version) — re-extract at the new pin and re-curate. The spec file last moved 2026-06-22; the repo remains active around it. This is an independent analysis — not affiliated with, or endorsed by, the specification’s authors — and it is not a compliance assessment: statements are classified for testability, never scored against anyone’s implementation.
Download the register (markdown) — the same rows as one citable file, ids included.
All 102 statements, by section
§front Front matter
can04:sfront-01§front · MUSTnot a requirementoutside the conformance clause’s scopekeyword unboldedFront-matter scope sentence: the document sets out what a network is required to meet for CMS-Aligned recognition.
Describes the document's purpose rather than requiring behavior. The keyword is prose-cased, unbolded, and sits before the conformance clause's own scope begins.
§1 Conformance
can04:s1-01§1 · MUST NOT, MUST, SHALL NOT, SHALL, SHOULD NOT, SHOULD, MAY, REQUIRED, RECOMMENDED, OPTIONALnot a requirementoutside the conformance clause’s scopeRFC-2119 / BCP 14 boilerplate: the capitalized keywords carry their standard normative meanings.
Definitional interpretation clause enumerating the keyword vocabulary; it requires nothing of a network.
can04:s1-02§1 · MUSTnot a requirementoutside the conformance clause’s scopeThe conformance definition: satisfy every MUST in sections 3 through 14 and be in good standing under section 15.
A meta-clause defining what conformance means, not itself a testable network behavior. Notably its stated range stops at section 15, leaving the normative keywords in section 16 formally outside the definition — the register's scope flag marks those rows.
§3.2 What Networks MUST Do
can04:s3.2-01§3.2 · MUSTdefers to a referenceMaster checklist: thirteen enumerated duties, each cross-referencing the section that elaborates it (core obligations, pathways, matching, authorization, NPD, audit, fees, and more).
A hoisted MUST over thirteen internal cross-references; its substance is distributed to the referenced sections, whose own keyword lines this register indexes individually. Item 13 requires attesting to the rules of the road in section 17 — which is an empty placeholder in this draft, so that item currently has no content behind it.
Reference: internal cross-references to the spec's own sections 4 through 17 (section 17 is an unwritten placeholder at this pin) — version-pinned
§4.1 Respond to queries for data holders on the network
can04:s4.1-01§4.1 · MUSTprocedurally observableA network is required to answer authorized queries whenever one of its data holders has matching data, across the use cases its participants engage in, including patient access, treatment, and payment.
A conduct obligation over live query traffic. There is no artifact that proves it; it is observable only by exercising queries against a network in operation and watching whether answers come back.
can04:s4.1-02§4.1 · MUST NOTprocedurally observableA network may not refuse to respond just because the querying participant belongs to a different home network.
A negative conduct constraint on refusal behavior; only observable by originating cross-network queries and comparing treatment, not testable against any artifact.
§4.2 Vouch for participants in good standing
can04:s4.2-01§4.2 · MUSTprocedurally observableA network is required to track each onboarded participant's operational status and answer good-standing queries from other networks or the national provider directory.
An ongoing operational duty plus a query-response behavior. No interface or artifact for the good-standing query is specified here, so the check is behavioral observation of the reporting conduct.
can04:s4.2-02§4.2 · MUST NOTprocedurally observableA network may vouch only for operational status — never for a participant's legal standing under federal law.
A constraint on what the network's attestations may claim; verifiable only by inspecting what attestations the network actually issues in operation.
can04:s4.2-03§4.2 · MUSTprocedurally observableA network is required to suspend a participant's good-standing report when it has suspended or flagged the participant, or when the participant failed a health check the network publishes.
A conditional conduct rule tying the good-standing signal to internal state transitions; observable through the network's reporting behavior over time, not through any shipped artifact.
§4.3 Respond to credentialed tech solutions from other home networks
can04:s4.3-01§4.3 · MUSTprocedurally observableWhen a tech solution presents valid Federal Trust Signals and its home network reports it in good standing, the receiving network is required to answer its queries.
Cross-network response conduct predicated on two defined trust inputs; testable only by presenting credentialed traffic to a live network and observing whether it responds.
can04:s4.3-02§4.3 · MUST NOT, MAYunderspecified as writtenA receiving network may not add duplicative trust gating beyond the Federal Trust Signals and the home-network good-standing report, though operational coordination such as abuse contacts and rate-limit coordination may be required.
The prohibition turns on what counts as 'duplicative' gating, and the line offers examples of permitted coordination but no boundary test. Without a definition, two observers can disagree about whether a given onboarding step is prohibited gating or permitted coordination.
What would make it testable: An enumerated list of prohibited gating practices, or a decision rule separating them from the permitted operational-coordination items.
§5 Connectivity Pathways
can04:s5-01§5 · MUST, OPTIONALdefers to a referenceEvery network is required to support all three connectivity pathways; a fourth (bilateral peering) is optional and sits outside the obligation structure.
A roll-up whose substance lives in the pathway subsections; each pathway's own keyword lines are indexed separately in this register.
Reference: internal cross-references to the spec's own sections 5.1 through 5.4 — version-pinned
§5.1 Pathway 1 — Intranetwork
can04:s5.1-01§5.1 · MUSTprocedurally observableWithin its own network, a network is required to answer authorized queries for any of its data holders across applicable use cases.
Intranetwork response conduct; observable only by exercising authorized queries against a live network.
§5.2 Pathway 2 — RLS Network Search ($match)
can04:s5.2-01§5.2 · MUSTmachine-testableA network is required to expose a standardized record-locator-service endpoint at the address it publishes in the national provider directory.
Endpoint presence and reachability at a published address is directly probeable by tooling — read the directory entry, connect to the endpoint. Depends on the directory actually carrying the address (the spec's own open-questions list notes the directory currently operates as a static file).
can04:s5.2-02§5.2 · MUSTmachine-testableThe record-locator endpoint is required to accept authenticated FHIR $match requests from other CMS-Aligned networks.
The $match operation is a defined FHIR interaction; a credentialed test client can issue one and observe acceptance. Access credentials are an operational precondition, not a gap in the check procedure.
can04:s5.2-03§5.2 · MUSTtestable with fixturesAll Pathway-2 queries are required to go through the CMS patient-matching rule of section 6.
Whether the matching rule was applied is only visible through input/output behavior on known cases, and the spec ships no match test cases.
What would make it testable: A published test-case suite exercising the 26 matching combinations with expected outcomes per case.
can04:s5.2-04§5.2 · MAYnot a requirementData retrieval may use either federated or brokered FHIR; the spec accepts both.
An explicit permission establishing equivalence between two architectures; it creates no obligation to test.
can04:s5.2-05§5.2 · SHOULDnot a requirementin an editorial calloutAn editorial proposal (in a discussion callout): networks might accept either $match or XCPD for cross-network discovery, with testing requirements yet to be determined.
Sits inside a blockquoted 'proposed for discussion' callout and says its own testing requirements are to be determined — a draft note about a possible future requirement, not a requirement.
§5.3 Pathway 3 — Targeted Queries Against NPD
can04:s5.3-01§5.3 · MUSTmachine-testableA network is required to publish its participants' endpoints to the national provider directory in a form queryable by NPI or an equivalent identifier.
Directory content is inspectable: enumerate the network's participants in the published directory and query by NPI. The directory's current static-file form (noted in the spec's open questions) affects convenience, not checkability.
§5.4 Pathway 4 — Bilateral Network-to-Network Peering Agreement *(OPTIONAL)*
can04:s5.4-01§5.4 · MAYnot a requirementA network may enter bilateral peering agreements at its own discretion.
A pure permission; nothing to test.
can04:s5.4-02§5.4 · MUST NOTprocedurally observableA network may not use a voluntary bilateral peering arrangement as its only means of meeting the section-4 core obligations.
Satisfied by demonstrating the three mandatory pathways independently — which the register indexes as their own rows — so this adds a posture constraint observable through the same evidence rather than a separate test surface.
§6 Patient Matching
can04:s6-01§6 · MUSTdefers to a referenceA network is required to implement the CMS-approved patient-matching logic from the CMS Interoperability Framework; the current minimum standard is the 26-combination rule.
The matching rule's substance lives in an external CMS document, cited without a version or a stable identifier — testability inherits from whatever that document currently says.
Reference: CMS Interoperability Framework patient-matching rule (26-combination MVP) — no version pinned
can04:s6-02§6 · MUSTtestable with fixturesA network is required to respond when a query matches a patient on any of the 26 combinations — but only where section-9 authorization is satisfied; a match alone creates no response duty.
The behavior is precisely stated (match plus authorization implies response) but only checkable with concrete matched-patient cases and authorization context, which the spec does not ship.
What would make it testable: Match test cases per combination, each paired with an authorization context and the expected respond/withhold outcome.
§7.1 Auto-Registration
can04:s7.1-01§7.1 · MUSTmachine-testableA network is required to accept a valid CMS-signed software statement as sufficient for dynamic client registration — no extra per-network vetting — for client types where CMS publishes a registry and issues statements.
Dynamic client registration is RFC 7591 plumbing: present a signed statement, observe registration. The check is well-defined; a CMS-issued statement is an operational precondition supplied by the ecosystem, not a missing definition.
can04:s7.1-02§7.1 · SHOULDunderspecified as writtenAuthorization servers should route signature validation by issuer — CMS-published JWKS for CMS statements, the UDAP community CA chain for UDAP statements if UDAP remains a recognized path.
Half the recommendation is contingent on an architectural question the spec itself marks unresolved (whether UDAP is retained), so the expected validation behavior cannot be pinned down as written.
What would make it testable: Resolution of the UDAP-retention question and a per-issuer validation behavior matrix.
can04:s7.1-03§7.1 · MUSTunderspecified as writtenOnce one home network onboards a participant with a recognized credential, every other network is required to register that participant on a defined timeline without redundant onboarding.
The obligation hinges on 'a defined timeline' that the document never defines — there is no number to measure registration latency against.
What would make it testable: A stated registration deadline (a concrete duration or date rule) for cross-network registration.
can04:s7.1-04§7.1 · MUST NOT, MAYunderspecified as writtenNetworks may not stack duplicative trust gating on top of federally grounded credentials; operational coordination items such as abuse contacts and rate limits may still be coordinated.
Same shape as the section-4.3 row: 'duplicative' is undefined, and the line gives examples of permitted coordination but no decision rule separating them from prohibited gating.
What would make it testable: An enumerated list of prohibited gating practices, or a decision rule distinguishing them from permitted coordination.
can04:s7.1-05§7.1 · MUST, MAYmachine-testableManual registration is permitted only until October 1, 2026; after that every HTE participant is required to support auto or dynamic registration.
Date-scoped and mechanical: after the stated deadline, attempt dynamic registration against a participant and observe support. The deadline gives the check a concrete trigger.
§7.2 Presumptive Eligibility
can04:s7.2-01§7.2 · MUSTprocedurally observableA participant in good standing on one home network is required to be allowed a default 90-day presumptive-eligibility window on other networks without redundant onboarding.
Cross-network admission conduct over a defined period; the 90-day figure gives the observation a concrete threshold, but only live onboarding behavior can show it.
can04:s7.2-02§7.2 · MUST, MAYprocedurally observableA network may suspend presumptive eligibility for cause (abuse, security incidents, a home-network downgrade) — and if it does, it is required to report the suspension to the directory and the home network.
The obligation fires on suspension events and is visible only in the network's reporting conduct when they occur.
§8 Authentication
can04:s8-01§8 · MUSTprocedurally observableA network — and every EHR or data holder it routes to — is required to answer authorized queries from properly credentialed parties without demanding a portal login first.
The no-portal-login constraint is observable in live credentialed flows across the network's routed endpoints; there is no artifact that proves it for every routed data holder.
§8.1 Patient Access — B2C (IAL2 + SMART App Launch)
can04:s8.1-01§8.1 · MUSTmachine-testablekeyword unboldedThe B2C authorization request is required to use POST to the authorize endpoint with form encoding rather than GET.
A concrete protocol-level constraint a test client can exercise directly against the endpoint. The keyword is prose-cased rather than bolded — the register's formatting flag marks it — but its all-capitals form is normative under the BCP 14 clause.
§8.2 Provider and Payer Access — B2B
can04:s8.2-01§8.2 · MAYnot a requirementkeyword unboldedFor B2B workflows such as claim attachments, the HL7 CDex Task pattern may be used.
A prose-cased permission naming an optional pattern; it obliges nothing.
§9.0 Required Precondition: Network-Mediated Record Location
can04:s9.0-01§9.0 · SHALLprocedurally observableEvery network is required to support network-mediated record location or source discovery for patient access.
The headline capability for the section; the numbered conditions beneath it give it operational content and are indexed as their own rows. As a capability it shows up only in live discovery flows.
can04:s9.0-02§9.0 · SHALLprocedurally observableAn app listed in the CMS Medicare App Library is required to be able to initiate record location through each network, or through its own network.
An end-to-end capability demonstration with a recognized app; presupposes the CMS app library exists as ecosystem infrastructure.
can04:s9.0-03§9.0 · SHALLunderspecified as writtenThe app is required to authenticate as itself using a CMS-signed software statement from the CMS registry — a mechanism the spec itself marks as a proposed solution under review.
The credential route is explicitly contingent on the unresolved architecture question in section 7.1, so what a correct authentication looks like cannot be pinned as written.
What would make it testable: Resolution of the credential-route question and an operating CMS registry issuing statements.
can04:s9.0-04§9.0 · SHALLmachine-testableThe app is required to present a valid IAL2 patient identity token from a CMS-approved digital identity provider.
Token presence, issuer approval, and assurance-level claims are mechanically verifiable; the CMS-approved provider list is an ecosystem input, not a missing definition.
can04:s9.0-05§9.0 · SHALLprocedurally observableThe network is required to process record-location requests on app authentication plus IAL2 identity alone — no additional demands — subject to matching, law, and security controls.
The word 'alone' is the requirement: the absence of extra preconditions is only visible in live request handling.
can04:s9.0-06§9.0 · SHALL NOTprocedurally observableThe patient may not be required to interact separately with the network or its data holders to complete record location.
A user-experience constraint on the flow; observable by walking the flow as a patient.
can04:s9.0-07§9.0 · SHALL NOTprocedurally observableThe patient may not be required to already know which providers, payers, facilities, or networks hold their records before starting discovery.
Same shape as the previous row: a no-prior-knowledge constraint on the discovery experience, visible only in the flow itself.
can04:s9.0-08§9.0 · SHALLprocedurally observableEach network is required to answer record-location requests on behalf of the participating data holders it represents.
Response conduct per network; observable by exercising discovery against it.
can04:s9.0-09§9.0 · SHALLunderspecified as writtenThe record-location response is required to carry enough information for the app to proceed to retrieval through an approval path.
'Enough information' has no defined response format or minimum field set behind it, so two implementations can disagree about sufficiency.
What would make it testable: A defined record-location response shape — minimum fields, or a named FHIR profile for the response.
§9.1 Required Conditions for All Paths
can04:s9.1-01§9.1 · SHALLdefers to a referenceEvery patient-approval path is required to satisfy four shared conditions before retrieval proceeds; each path then adds only its own extras.
A hoisted requirement over the four shared conditions enumerated beneath it; the conditions carry the substance.
Reference: the four shared conditions enumerated under section 9.1 of the same document — version-pinned
§9.2.1 Path 1 — Preferred: CMS-Recognized App + IAL2 Patient Identity (SHOULD)
can04:s9.2.1-01§9.2.1 · SHOULDprocedurally observableNetworks, EHRs, and data holders should support the preferred path: a recognized app obtains patient-access tokens without per-holder onboarding and without portal login.
A recommended end-to-end capability; the two 'without' clauses are conduct constraints visible only in live flows.
can04:s9.2.1-02§9.2.1 · SHOULDunderspecified as writtenThe trust placed in recognized apps should be paired with monitoring, good-standing review, auditability, and post-July work toward stronger approval artifacts.
Governance aspirations with no criteria, artifacts, or thresholds to check against as written.
What would make it testable: Defined monitoring and review criteria, or named artifacts these activities must produce.
can04:s9.2.1-03§9.2.1 · SHALLtestable with fixturesThe cms_smart extension moves to version 2 with a consent_reference element carrying a FHIR bundle of the patient's recorded preferences; the bundle's required contents follow in a table.
An artifact-shape requirement expressed as a prose table rather than a validatable profile, and the spec ships no example bundle to check against.
What would make it testable: A formal profile or published example bundles for the consent_reference contents.
can04:s9.2.1-04§9.2.1 · SHALLmachine-testableThe bundle's Patient entry (exactly one, US Core-profiled) is required to be referenced by the Consent resource and carry an identifier binding the token issuer and subject; data holders are required to validate that binding.
Field-level checks over a concrete bundle instance — reference present, identifier system and value match the token — are mechanical. The US Core profile it leans on is cited without a version anywhere in the document.
Reference: HL7 FHIR US Core (Patient profile) — no version pinned
can04:s9.2.1-05§9.2.1 · MUSTmachine-testableThe id_token in the consent bundle is required to be an IAL2 token issued by an identity provider.
Assurance-level and issuer checks on a token are mechanical validation.
can04:s9.2.1-06§9.2.1 · SHALL, MAYtestable with fixturesAn app may request consent for sensitive or restricted information; if it obtains consent, it is required to convey the result to the data holder as a Consent resource in the token request.
The conveyance is artifact-shaped — a Consent resource in a defined position — but no example encoding ships, so implementers and testers have nothing concrete to compare against.
What would make it testable: Example Consent resources showing the expected encoding for granted and withheld sensitive-information consent.
can04:s9.2.1-07§9.2.1 · SHALLprocedurally observableA data holder is required to treat a positive Consent resource as authorization to disclose sensitive or restricted information, except where law prohibits disclosure.
Disclosure conduct with a legal carve-out; the exception makes outcomes context-dependent, so only operational behavior shows it.
can04:s9.2.1-08§9.2.1 · MAYnot a requirementAbsent positive consent in the token request, the data holder may withhold sensitive or restricted information.
A permission; it obliges nothing.
can04:s9.2.1-09§9.2.1 · MAYnot a requirementAs an alternative to the consent bundle, a network or recognized issuer may issue a signed SMART Permission Ticket, and data holders may honor it.
A pair of permissions describing an optional alternative the document elsewhere marks as under review; nothing is obliged.
§9.2.2 Path 2 — Allowed Alternative: Network-Level Consolidated Patient Approval (MAY)
can04:s9.2.2-01§9.2.2 · MAYnot a requirementA data holder that cannot meet the preferred path may rely on a network-level consolidated approval flow, subject to the shared section-9.1 conditions plus this path's additions.
The keyword grants the alternative path; the conditions it imports are indexed as their own rows.
can04:s9.2.2-02§9.2.2 · SHOULDprocedurally observablePatients should be able to approve all FHIR resources by default — select-all with uncheck-by-exception — rather than approving each data holder separately.
An approval-screen behavior; observable by walking the consolidated flow.
§9.2.3 Path 3 — July Bridge: Data Holder-Specific Patient Approval (MAY)
can04:s9.2.3-01§9.2.3 · MAYnot a requirementA data holder may use a holder-specific approval flow as a temporary July bridge, subject to the shared conditions plus this path's additions.
A permission establishing the bridge path; its constraints follow as separate rows.
can04:s9.2.3-02§9.2.3 · SHALL NOTprocedurally observableEven on the bridge path, the data holder may not require portal credentials.
A conduct prohibition observable in the approval flow.
can04:s9.2.3-03§9.2.3 · SHOULDprocedurally observableThe bridge path's approval screen should be limited to approving the app and the requested access.
A screen-content constraint; observable by inspection of the flow.
can04:s9.2.3-04§9.2.3 · SHALL NOTprocedurally observableThe app may not be required to complete separate developer onboarding for each data holder in the network.
A no-redundant-onboarding constraint on the developer experience; visible in how access is actually provisioned.
can04:s9.2.3-05§9.2.3 · SHALLunderspecified as writtenA data holder or network on the bridge path is required to identify what it would take to move beyond it.
No artifact, audience, format, or deadline is defined for this identification, so there is nothing concrete to check for.
What would make it testable: A named artifact and venue (to whom, in what form, by when) for the beyond-the-bridge statement.
can04:s9.2.3-06§9.2.3 · MAYnot a requirementWith a patient's blanket consent to their whole record, an app may automate the authorization screens data holders return.
A permission; it obliges nothing.
can04:s9.2.3-07§9.2.3 · MUSTprocedurally observableThe bridge path is required to be retired by November 1, 2026, and is not the target pattern.
Date-anchored: after the stated date, continued reliance on holder-specific approval screens is the observable fact that matters.
§9.3 Required July Outcome
can04:s9.3-01§9.3 · MUSTprocedurally observableBy July 4, 2026, a recognized app in good standing acting for an IAL2-verified patient is required to be able to complete the enumerated end-to-end outcomes.
A date-anchored end-to-end capability roll-up over the outcome list that follows; demonstrable only by running the full flow as that app.
can04:s9.3-02§9.3 · SHALL, SHOULDunderspecified as writtenNetworks and data holders are required to document which approval path they support, and should report adoption metrics by path.
Neither the venue nor the format of the path declaration is defined — there is no stated place a tester could look for it.
What would make it testable: A defined publication location and shape for the declaration (for example a directory field or a CapabilityStatement extension).
§9.4 Post-July Direction
can04:s9.4-01§9.4 · SHOULDnot a requirementPost-July, CMS and the working groups should focus on higher-assurance approval mechanisms that reduce holder-specific screens.
Roadmap prose addressed to CMS and working groups, not an obligation on any network.
§9.5 Token Validation Requirements
can04:s9.5-01§9.5 · SHALLunderspecified as writtenA data holder answering an identity-assured request is required to verify the relationship between the token's audience claim and the presenting app — with specifics deferred pending the credential-route choice.
The line itself defers its specifics ('to be added depending on cert vs. software statements route choice'), so the verification it requires is not yet defined.
What would make it testable: The promised specifics: which relationship between audience and app is valid, per credential route.
can04:s9.5-02§9.5 · SHALL NOTmachine-testableA data holder may not issue an access token when the id_token's auth_time shows the user authenticated more than 300 seconds before the request.
A concrete numeric threshold on a token claim: present a stale token and observe rejection. One of the most directly automatable statements in the document.
can04:s9.5-03§9.5 · SHALL NOT, SHALLmachine-testableA data holder is required to enforce token uniqueness — the same JWT ID and issuer combination may not be accepted twice within the token's validity window.
Replay-protection with a precise key (jti plus iss): replay a token and observe rejection.
can04:s9.5-04§9.5 · SHALLmachine-testableAccess tokens are required to be renewable via refresh tokens on a rolling 90-day basis.
Exercise the refresh grant and observe renewal; the rolling window is long-horizon but the mechanics are directly automatable.
can04:s9.5-05§9.5 · SHALLmachine-testableEach successful token refresh is required to reset the rolling 90-day expiration window.
Observable in the expiry metadata across successive refreshes.
can04:s9.5-06§9.5 · SHALLmachine-testableAccess tokens are required to have a lifetime of no more than one hour.
Inspect issued-token lifetimes; a concrete numeric bound.
§10 Query / Data Exchange
can04:s10-01§10 · MUST NOT, MUSTnot a requirementin an editorial calloutkeyword unboldedAn editorial TODO discussing whether the purpose-of-use material belongs in the authorization section or the query section.
A blockquoted, prose-cased drafting note about where requirements should live; the requirements it discusses are indexed at their own rows in section 10.3.
§10.1 Respond Completely
can04:s10.1-01§10.1 · MUSTtestable with fixturesAn authorized query's response is required to include all relevant data the responder holds for the patient — structured and unstructured — within the use case.
Completeness against an unknown inventory cannot be observed from outside; with seeded test patients whose full record is known, it becomes a concrete comparison.
What would make it testable: Seeded test-patient records with a known complete inventory to compare responses against.
can04:s10.1-02§10.1 · MUST, SHOULDdefers to a referenceThe structured-data floor is USCDI v3 — or whatever version is current at query time per the CMS Interoperability Framework — and in-scope unstructured artifacts are required where they exist.
The data floor inherits from USCDI, and the version is explicitly floating ('the version current at the time of the query'), so what the floor requires can change without this document changing.
Reference: USCDI v3, with a floating current-version clause governed by the CMS Interoperability Framework — no version pinned
§10.2 Use Case Coverage
can04:s10.2-01§10.2 · MUSTprocedurally observableA network is required to answer queries from the actor categories that apply to the use cases its participants engage in.
Response conduct per actor category; the enumerated categories follow, and observation means exercising queries as each.
can04:s10.2-02§10.2 · MUSTprocedurally observableIf a network's participants engage in a use case, the network is required to support queries for it.
A coverage rule keyed to what participants actually do — observable by comparing participant activity with supported query types in operation.
§10.3 Purpose of Use Propagation
can04:s10.3-01§10.3 · MUSTtestable with fixturesEvery request is required to declare its purpose of use; the network is required to support the HL7 purpose-of-use codes and apply the right disclosure rules per category.
Declaration presence is mechanical, but 'the correct disclosure rules' per category is only checkable with concrete allow/deny cases, which the document does not provide.
What would make it testable: Per-purpose-code disclosure test cases: a request with each code and the expected allow or deny outcome.
can04:s10.3-02§10.3 · REQUIREDmachine-testableThe enumerated purpose-of-use codes aligned to the approved use cases are required to be supported.
A closed code list: send each code and observe acceptance — directly automatable.
can04:s10.3-03§10.3 · MUSTprocedurally observableThe declared purpose of use is required to travel with the request to downstream systems.
Propagation through systems the observer does not control; visible only in downstream traffic or audit trails.
can04:s10.3-04§10.3 · MUST NOT, MUST, MAYprocedurally observableWith a trusted requester and a properly declared purpose, no additional authorization hurdles may be added — while patients may restrict data categories, and those restrictions are required to be honored.
Two interlocking conduct rules (no stacking, honor restrictions); both are visible only in how live requests are treated.
§10.4 Patient-Contributed Data
can04:s10.4-01§10.4 · SHOULDunderspecified as writtenNetworks and data holders should design APIs to accommodate future patient-write flows, with patient choice governing whether contributed data flows.
'Accommodate future flows' names no design property that could be checked now — the capability it anticipates is explicitly deferred.
What would make it testable: Named design constraints (reserved endpoints, capability declarations, or a write-profile) that accommodation means.
§11 National Provider Directory Publication
can04:s11-01§11 · MUSTmachine-testableA network is required to publish the enumerated items (endpoints, participants, trust metadata) to the national provider directory.
Directory content is inspectable: read the directory and check the enumerated items are present for the network.
can04:s11-02§11 · MUSTunderspecified as writtenin an editorial calloutIf UDAP is retained as a required path, the directory is required to publish the trust community CA URL and intermediate certificates — with the metadata schema still to be specified.
A contingency callout: the obligation depends on the unresolved section-7.1 architecture question, binds the directory rather than a network, and its own text defers the schema.
What would make it testable: Resolution of the UDAP question and the promised trust-metadata schema.
can04:s11-03§11 · MUST, SHOULDmachine-testablein an editorial calloutNetworks that onboard at the organization level satisfy the individual-practitioner publication duty by publishing their organizations with NPI cross-references to the practitioners' NPPES records.
An interpretive callout defining an acceptable satisfaction shape; the shape itself — organization records carrying NPI cross-references — is directory-inspectable.
can04:s11-04§11 · MUST, SHOULDunderspecified as writtenA network is required to ingest and publish directory updates routinely, at a cadence set by the CMS Framework — contingent, by the spec's own admission, on a CMS ingestion API that does not exist yet.
The document's own open-questions list (item A7) states the directory operates as a static file with no ingestion API, so the routine-updates duty cannot currently be exercised as written; the cadence also lives in an external document.
What would make it testable: The CMS ingestion API (open item A7) and a stated refresh cadence.
can04:s11-05§11 · MUSTmachine-testableThe national provider directory is required to be queryable by any network, auditor, or participant to confirm an actor's listing and credentials.
Queryability of a public directory is directly probeable — though the duty holder here is the directory itself (CMS infrastructure), not a network.
§12 Audit Logging
can04:s12-01§12 · MUSTprocedurally observableA network is required to produce audit logs for queries on its network, covering the enumerated fields.
Internal record-keeping; a third party sees it only through the patient-facing audit access the next rows require, or through an audit engagement.
can04:s12-02§12 · MUSTprocedurally observableAudit logs are required to be at least organization-level and retained at least seven years, or longer where law requires.
Retention conduct over a multi-year horizon; the seven-year floor is concrete but only an audit over time can show adherence.
can04:s12-03§12 · MUSTdefers to a referenceA network is required to give patients app-facing visibility into who queried their data, conforming to the IAS Audit Log API Specification v1.0 (February 2026).
The substance inherits from a named external API specification — and unusually for this document, the reference is pinned to a version and date.
Reference: IAS Audit Log API Specification v1.0 (February 2026) — version-pinned
§13 Security
can04:s13-01§13 · MUSTprocedurally observablekeyword unboldedA network is required to hold HITRUST certification scoped to the production environment handling PHI, covering at minimum identity, token validation, routing, audit generation, and matching reference data.
Certification status is an attested document check with a scope judgment, not an automatable probe. The keyword is prose-cased rather than bolded — the register's formatting flag marks it.
can04:s13-02§13 · MUST, MAYunderspecified as writtenkeyword unboldedBusiness associate agreements may be needed even without direct data brokering, and networks and participants are required to confirm their obligations under HIPAA.
'Confirm their obligations' names no artifact, attestation, or record that the confirmation happened — a legal-diligence duty with nothing checkable behind it. Also prose-cased.
What would make it testable: A named attestation or record that the confirmation occurred.
§14.1 Patient-Directed Access
can04:s14.1-01§14.1 · MUST NOTprocedurally observableA network may not structure fees in a way that gates a patient's federal right to access their own data.
Whether patient-directed access flows encounter fee barriers is observable in the flows themselves; fee-schedule inspection alone cannot show it.
§14.2 Above the Floor
can04:s14.2-01§14.2 · MAYnot a requirementAbove the federal floor, a network may set its own commercial terms for the enumerated services.
A permission delimiting the competitive space; it obliges nothing.
§14.3 Inter-Network Settlement
can04:s14.3-01§14.3 · MAYnot a requirementFor non-patient-access traffic, networks may negotiate commercial peering with settlement or transit terms above the floor.
A permission; it obliges nothing.
§15 Accountability
can04:s15-01§15 · MUSTunderspecified as writtenA network is required to publish operational metrics — response rates, query volumes, response times by use case — for comparison-shopping and CMS monitoring.
The measures are named but no venue, format, or cadence is defined, so there is no stated place or shape a checker could hold the publication to.
What would make it testable: A defined publication venue, format, and cadence for the named measures.
§16 July 4, 2026 Framework Requirements
can04:s16-01§16 · MUSTdefers to a referenceoutside the conformance clause’s scopeBy July 4, 2026, a network is required to satisfy the four framework requirements below.
A dated roll-up over subsections 16.1 through 16.4, indexed as their own rows. Notably the whole of section 16 sits outside the range the conformance clause in section 1 defines, so these keywords are formally unreachable from the document's own definition of conformance — the register's scope flag marks every row here.
Reference: internal cross-references to the spec's own sections 16.1 through 16.4 — version-pinned
§16.1 FHIR API Access
can04:s16.1-01§16.1 · MUSTdefers to a referenceoutside the conformance clause’s scopeA network is required to provide or facilitate FHIR API access adhering to the HL7 FHIR US Core implementation guide, including a complete and valid CapabilityStatement and USCDI v3 data elements.
Adherence inherits from US Core — cited by bare link with no version anywhere in the document. Which major version is meant changes the requirement surface materially: successive US Core versions differ by hundreds of element-level requirement changes and dozens of whole profiles.
Reference: HL7 FHIR US Core Implementation Guide — no version pinned
can04:s16.1-02§16.1 · SHOULDdefers to a referenceoutside the conformance clause’s scopeA network should use FHIR Bulk Data Exchange to reduce load and enable full-record exchange.
A recommendation whose substance lives in the Bulk Data specification, cited by bare link without a version.
Reference: HL7 FHIR Bulk Data Exchange — no version pinned
§16.2 Chart Notes and Clinical Documents
can04:s16.2-01§16.2 · MUST, SHOULDtestable with fixturesoutside the conformance clause’s scopeA network is required to return chart notes and clinical documents — radiology reports, scanned labs, outside notes — as human-readable FHIR attachments per USCDI v3; persisted ambient recordings should follow where a profile exists.
Retrieval-content behavior checkable only against seeded records containing each artifact class; the document ships none, and it marks the ambient-recording exchange profile as still to be determined.
What would make it testable: Seeded records containing each artifact class with the expected attachment renderings.
§16.3 Appointment and Encounter Notifications
can04:s16.3-01§16.3 · MUSTprocedurally observableoutside the conformance clause’s scopeA network is required to provide appointment and encounter notifications across care settings using FHIR Subscriptions, where law permits.
Notification conduct over live encounter events — but this subsection carries the draft's own deferral callout (not in scope for initial recognition), so the keyword is normative in form while the draft suspends its force.
§16.4 Record Locator Service
can04:s16.4-01§16.4 · MUSTunderspecified as writtenoutside the conformance clause’s scopeA network is required to implement record-locator functionality by collaborating with CMS to determine efficient and timely models.
The obligation is to help determine a model that does not yet exist — there is no defined target to check an implementation against.
What would make it testable: The determined record-locator model itself.
can04:s16.4-02§16.4 · MUSTprocedurally observableoutside the conformance clause’s scopeRecord-locator requests are required to be initiable by patients, providers, payers, and value-based care organizations.
Initiability per actor class needs credentialed flows for each class; observable by exercising the service as each actor type.
§A . Open Questions
can04:sA-01§A · MUSTnot a requirementoutside the conformance clause’s scopekeyword unboldedAn open-questions table row noting that the directory-update duty in section 11 cannot be met at scale until CMS provides an ingestion API.
Appendix inventory discussing a requirement rather than making one; the requirement it discusses is indexed at its own section-11 row, where this same gap drives the classification.