# CMS Aligned Network Specification (can-spec) — normative-statement testability register

Source: https://github.com/icanbwell/cms-ns at commit `a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85` (can-spec/0.4-draft, editor's draft 2026-06-22), file sha256 `515959b162f8e7a2d81a69f99bdbef79d422d0f87d5e9cb9a65b0fadf5dec3e1`.

The draft publishes no license, so its sentences are never reproduced here: every row is our own paraphrase plus a line-anchored permalink to the pinned commit and a sha256 of the source line. Anyone can verify every claim against the same bytes we read.

This is an independent analysis, not affiliated with or endorsed by the specification's authors. It classifies statements for TESTABILITY and renders no verdict about any network or implementation — not a compliance assessment.

Classifications 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.

## The shape of the document

| Class | Count |
|---|---|
| Machine-testable | 18 |
| Testable with fixtures | 7 |
| Procedurally observable | 35 |
| Defers to a reference | 9 |
| Underspecified as written | 16 |
| Not a requirement | 17 |
| **Total** | **102** |

Mechanical flags: 11 statements sit outside the range the document's own conformance clause covers (§§3–14 + §15, which leaves all of §16's normative keywords formally unreachable); 4 carry keywords inside editorial callouts; 7 use a prose-cased keyword. The document defines no requirement identifiers, so this register mints stable ids (never renumbered; retired instead).

## The register

### §front Front matter

- `can04:sfront-01` (MUST) — **Not a requirement** — outside conformance scope · keyword unbolded
  - Front-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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L22 (line sha256 `14c48ba7b6301ad35a4927d5589ef30481f7433f8d18d8310c83d1c76d9c3ccc`)
### §1 Conformance

- `can04:s1-01` (MUST NOT, MUST, SHALL NOT, SHALL, SHOULD NOT, SHOULD, MAY, REQUIRED, RECOMMENDED, OPTIONAL) — **Not a requirement** — outside conformance scope
  - RFC-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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L40 (line sha256 `a8b16e976ce0234791de9249486c3e1e127702272e67f751ffc6b9671dd5ecb3`)
- `can04:s1-02` (MUST) — **Not a requirement** — outside conformance scope
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L42 (line sha256 `7d45a7e0c3725220e0cba714db32f6226d1c28a441736eb8b26e4b73b68f93a9`)
### §3.2 What Networks MUST Do

- `can04:s3.2-01` (MUST) — **Defers to a reference**
  - Master 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L116 (line sha256 `64a890e39e8e03913412d921bbd0649b747e9c3936d6c217d1db1bce94bc7d93`)
### §4.1 Respond to queries for data holders on the network

- `can04:s4.1-01` (MUST) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L138 (line sha256 `74bfbd3bdccf489c66711531dd5a1d25bfe8a4125f6d3b82c2211a3536ebd015`)
- `can04:s4.1-02` (MUST NOT) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L140 (line sha256 `c90b8b3ef038af9d88ef23c7628249b931a6a0def1e5c552a74f7ff9ca51a33c`)
### §4.2 Vouch for participants in good standing

- `can04:s4.2-01` (MUST) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L144 (line sha256 `488297320e0ea0f07cb4e820b4146ea30fff9a3743e4be631186b8a99911174d`)
- `can04:s4.2-02` (MUST NOT) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L146 (line sha256 `86383853224b3ee43eb30812f8a0d9a2b67f1858c7e4e5d4be62a877d0f8c565`)
- `can04:s4.2-03` (MUST) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L148 (line sha256 `ab0535c43705a157a784fe197b40de95d3d455ec91af982a1a9f6fee1101f0ba`)
### §4.3 Respond to credentialed tech solutions from other home networks

- `can04:s4.3-01` (MUST) — **Procedurally observable**
  - When 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L152 (line sha256 `b5d592fc8aa77a23f6bd77302c94f179f5c5ff0ba7871b1f23a2d9607f65a0e4`)
- `can04:s4.3-02` (MUST NOT, MAY) — **Underspecified as written**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L154 (line sha256 `1a6dc75efab217a82a6177d7b6352620700a38f0876a2eb7973698a2005d3eb6`)
### §5 Connectivity Pathways

- `can04:s5-01` (MUST, OPTIONAL) — **Defers to a reference**
  - Every 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L160 (line sha256 `6a20396f7488002aeef9d581ef1baea54df4cc18eeceb8370efe872f6de6ad23`)
### §5.1 Pathway 1 — Intranetwork

- `can04:s5.1-01` (MUST) — **Procedurally observable**
  - Within 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L171 (line sha256 `deab67aac7a3c3df1c31f8115ad3c1a1b9b566f6694a5351c684553667b6844d`)
### §5.2 Pathway 2 — RLS Network Search ($match)

- `can04:s5.2-01` (MUST) — **Machine-testable**
  - A 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).
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L183 (line sha256 `3fa80aa5247027942ac97242de0fcd5ccf9e1675dea80575ccbebe5165d8ba4f`)
- `can04:s5.2-02` (MUST) — **Machine-testable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L184 (line sha256 `1034d6d22160e2a66f38475baa6fee1d7482560e4f6268d408bdcc92716ed9a0`)
- `can04:s5.2-03` (MUST) — **Testable with fixtures**
  - All 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L185 (line sha256 `ee890998bb15c46d93212a2205b3a06d138486bb27ea636582b05224138fd5e3`)
- `can04:s5.2-04` (MAY) — **Not a requirement**
  - Data 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L186 (line sha256 `321445c818ad1b28b7f990a6de23b6830a3f2eb299d5a374b96323f577bca3c0`)
- `can04:s5.2-05` (SHOULD) — **Not a requirement** — editorial callout
  - An 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L195 (line sha256 `d7a23ad21c49a79d039cf427ae50dad481bd59dc3e816151f8fbc28ea7797a83`)
### §5.3 Pathway 3 — Targeted Queries Against NPD

- `can04:s5.3-01` (MUST) — **Machine-testable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L212 (line sha256 `a12bc61706599b49e9a136a9a249ce6e206b6a2a2c416c58e0cae5ba7de22ca4`)
### §5.4 Pathway 4 — Bilateral Network-to-Network Peering Agreement *(OPTIONAL)*

- `can04:s5.4-01` (MAY) — **Not a requirement**
  - A network may enter bilateral peering agreements at its own discretion.
  - A pure permission; nothing to test.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L228 (line sha256 `de74620cea3eaf72e26aab9c8de2f4fc9b682f9db66df412cc5701e505ab9006`)
- `can04:s5.4-02` (MUST NOT) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L229 (line sha256 `00bacbc6140a870b9aeee231c89671f6e6c44b33e01258b6cab3468a039d0833`)
### §6 Patient Matching

- `can04:s6-01` (MUST) — **Defers to a reference**
  - A 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L235 (line sha256 `4c33ea5e09b9e354cacba90e8bddebb7478e46cdf7eb10045e8488a86fd05d6a`)
- `can04:s6-02` (MUST) — **Testable with fixtures**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L237 (line sha256 `d4620673fb07727ed58827695ab5b5fcb58f49394acbc8adc84d26e4a2122a0a`)
### §7.1 Auto-Registration

- `can04:s7.1-01` (MUST) — **Machine-testable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L251 (line sha256 `09ddcc06de5e14db487927f113015a48704a59edcd3795c4943235144ace9b72`)
- `can04:s7.1-02` (SHOULD) — **Underspecified as written**
  - Authorization 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L261 (line sha256 `288d99de36bbce43bb0ea45e7ab52f5a900fd86739a7d9f5f2a6164280c04d49`)
- `can04:s7.1-03` (MUST) — **Underspecified as written**
  - Once 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L263 (line sha256 `b73a48a954b56b54be7e86d2e35a5a0d63ccd7b1815f90b2f0fcecb03ac8b610`)
- `can04:s7.1-04` (MUST NOT, MAY) — **Underspecified as written**
  - Networks 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L267 (line sha256 `0e27e0d0c10ecaeda101d9983924b2a1ce8f36fea5c263d1a7412f8a04fbeca1`)
- `can04:s7.1-05` (MUST, MAY) — **Machine-testable**
  - Manual 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L269 (line sha256 `191994d8fdc8ab6a2dbf8fc1b467b3b2c60a74f82178f29180a63465ae4795ad`)
### §7.2 Presumptive Eligibility

- `can04:s7.2-01` (MUST) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L273 (line sha256 `08b5f7299199cc3d05f3aa7fb55525e1b50840d567f63fee5a41bc96fda01ed2`)
- `can04:s7.2-02` (MUST, MAY) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L283 (line sha256 `ff80782253f4b63a43a72562c8efc4cfae50c552d77e2521123329685a0b308c`)
### §8 Authentication

- `can04:s8-01` (MUST) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L289 (line sha256 `8b4e98c5e1f291304895f5dbee903bd61559bf96897c3d86d683e66b488c2ec4`)
### §8.1 Patient Access — B2C (IAL2 + SMART App Launch)

- `can04:s8.1-01` (MUST) — **Machine-testable** — keyword unbolded
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L317 (line sha256 `f6b3d1efbf69ab0cb2a0cc6c7568899d1b3574471303f2224523882a8c74654a`)
### §8.2 Provider and Payer Access — B2B

- `can04:s8.2-01` (MAY) — **Not a requirement** — keyword unbolded
  - For 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L350 (line sha256 `0b02d8d9a1dbc32e9ff9e0c6f2c12c3f380584b69a050fb6db2512c7dcc034d2`)
### §9.0 Required Precondition: Network-Mediated Record Location

- `can04:s9.0-01` (SHALL) — **Procedurally observable**
  - Every 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L370 (line sha256 `b5cb55a1f4754951cf4fd873738888ea8f4b5fbb5f7045c191cc5385ab43e6be`)
- `can04:s9.0-02` (SHALL) — **Procedurally observable**
  - An 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L374 (line sha256 `d25118e839ef661f925b7bca1b2d15eb60546aea5d496a58388fe84c5e919288`)
- `can04:s9.0-03` (SHALL) — **Underspecified as written**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L375 (line sha256 `3f68a8fefe7cb367795cb2b62428c91457026bad994c97bf79f4c8ce8380cb1d`)
- `can04:s9.0-04` (SHALL) — **Machine-testable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L376 (line sha256 `083d7e04c18a730566f68f3e0b2b8d6a260640e9f762826d747121586ba06069`)
- `can04:s9.0-05` (SHALL) — **Procedurally observable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L377 (line sha256 `3a43381f9eb11d55714d5e0f290ded9596a86904ad37632a87f2d4c1c51943f9`)
- `can04:s9.0-06` (SHALL NOT) — **Procedurally observable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L378 (line sha256 `9c0793f7e9690d17a16049f5f8aac90e0d0b0e98896e3d9b4e9eb9e6d903ecb5`)
- `can04:s9.0-07` (SHALL NOT) — **Procedurally observable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L379 (line sha256 `015946e8c272c4d6eeef2830be38d7f3e5c06a09d4e82f135bb16e4cea014b95`)
- `can04:s9.0-08` (SHALL) — **Procedurally observable**
  - Each 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L380 (line sha256 `6683c71da2bdf2c45630685cb01e49e5abaadc31e94095ca95adf105ab5016a8`)
- `can04:s9.0-09` (SHALL) — **Underspecified as written**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L381 (line sha256 `3b3cedd9d5c60426f330800bd1d31f9470161dac7c1833916792026b905c1910`)
### §9.1 Required Conditions for All Paths

- `can04:s9.1-01` (SHALL) — **Defers to a reference**
  - Every 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L386 (line sha256 `19f7813b29656e491de5db918ea550c1d99f76c7209dc6c5d1213aefce799596`)
### §9.2.1 Path 1 — Preferred: CMS-Recognized App + IAL2 Patient Identity (SHOULD)

- `can04:s9.2.1-01` (SHOULD) — **Procedurally observable**
  - Networks, 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L397 (line sha256 `c1e0ccb62f10997f478874cef67abe2577cdae1037b1d259dfe06344a72128dd`)
- `can04:s9.2.1-02` (SHOULD) — **Underspecified as written**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L408 (line sha256 `87ccf80090eccf2793991e87440f0693a8a14e9a38c542d293fee08b5a3357f3`)
- `can04:s9.2.1-03` (SHALL) — **Testable with fixtures**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L412 (line sha256 `ce80fa85eb992b4d4be7a61c69d02186705dbfce0e4aaf1433bf06a675f5aa0a`)
- `can04:s9.2.1-04` (SHALL) — **Machine-testable**
  - The 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L417 (line sha256 `42cd2707b91337761d6e9b66bbfb4d41e61d57d9694071386856ed6b334e03eb`)
- `can04:s9.2.1-05` (MUST) — **Machine-testable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L429 (line sha256 `09630c8d98221cc49ad9fa0c00f83b4c3b1169756e91d4d0f58f0cad03380e48`)
- `can04:s9.2.1-06` (SHALL, MAY) — **Testable with fixtures**
  - An 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L435 (line sha256 `be7923db95c1067bebef2b9cd7ecccf5ae4577b3dd96062da6a2c0ce0c3f8b17`)
- `can04:s9.2.1-07` (SHALL) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L437 (line sha256 `605f2f11ac979d8194accf1f280a0321b0835d1554d062be5796ed3d979dac52`)
- `can04:s9.2.1-08` (MAY) — **Not a requirement**
  - Absent positive consent in the token request, the data holder may withhold sensitive or restricted information.
  - A permission; it obliges nothing.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L439 (line sha256 `4cc698ee5a8c8040713b57bad33932e7cc18774199d29b48b2244c99a28d9a88`)
- `can04:s9.2.1-09` (MAY) — **Not a requirement**
  - As 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L443 (line sha256 `8ff3188835bac9c1198ed9e686f2d81ff2a62c8545c0a470c8f92f6ca3e3cfa6`)
### §9.2.2 Path 2 — Allowed Alternative: Network-Level Consolidated Patient Approval (MAY)

- `can04:s9.2.2-01` (MAY) — **Not a requirement**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L447 (line sha256 `32a27a4595c3d972619d4251fa0a9f7182e2f1dab475359dcd1105ef1ddabe9d`)
- `can04:s9.2.2-02` (SHOULD) — **Procedurally observable**
  - Patients 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L450 (line sha256 `e10ff22ee0eaab7915cec42ab26a71db1939125252fb18d932d27daeaa413880`)
### §9.2.3 Path 3 — July Bridge: Data Holder-Specific Patient Approval (MAY)

- `can04:s9.2.3-01` (MAY) — **Not a requirement**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L458 (line sha256 `b48ee7de975343733d85772690609b75b07700346b286ae0e1435466d5195b05`)
- `can04:s9.2.3-02` (SHALL NOT) — **Procedurally observable**
  - Even on the bridge path, the data holder may not require portal credentials.
  - A conduct prohibition observable in the approval flow.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L460 (line sha256 `087fdb0364334c3c69581ba1f8fc2bb8a35af58865b9298af20404c257699c01`)
- `can04:s9.2.3-03` (SHOULD) — **Procedurally observable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L461 (line sha256 `b74a506c5ca448b23e50e1785bc1e5a2bddcf5b90344fab3cf52646f7bc91593`)
- `can04:s9.2.3-04` (SHALL NOT) — **Procedurally observable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L462 (line sha256 `0fec723f59078be7ab32647819ba58eede0dda7bf0309a7f5006c425c3b24f8e`)
- `can04:s9.2.3-05` (SHALL) — **Underspecified as written**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L463 (line sha256 `428072788e928af409a671e73b4708046b5a66882c25b3255a11fd64dcfe48a1`)
- `can04:s9.2.3-06` (MAY) — **Not a requirement**
  - With a patient's blanket consent to their whole record, an app may automate the authorization screens data holders return.
  - A permission; it obliges nothing.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L464 (line sha256 `bcf924cd48aaaf22721b4016bbe03fa5512d79e3948f4cac902c21bf5f4c8096`)
- `can04:s9.2.3-07` (MUST) — **Procedurally observable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L466 (line sha256 `ccc43408d28f6fe6ac34fa38810377ee4ddb19119218e62ad1b2d633c09dd72b`)
### §9.3 Required July Outcome

- `can04:s9.3-01` (MUST) — **Procedurally observable**
  - By 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L470 (line sha256 `d4718117d8371121f8e2b272c1b25072bb6eb609835038e1a5535e83d2b5e8dd`)
- `can04:s9.3-02` (SHALL, SHOULD) — **Underspecified as written**
  - Networks 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).
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L479 (line sha256 `5d7a1a5d377ff7d7bd67115f7bf2adc8ed6ad5a5a3325c7b9c3d2799558f62bf`)
### §9.4 Post-July Direction

- `can04:s9.4-01` (SHOULD) — **Not a requirement**
  - Post-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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L483 (line sha256 `6cda5f59cdc746d9c9347af66f9c39d9d0634e85b70885f59c86ddec9b799ab6`)
### §9.5 Token Validation Requirements

- `can04:s9.5-01` (SHALL) — **Underspecified as written**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L495 (line sha256 `721831bb4a85f03f67271301b14283649430d71f577d576a32451f3add582cc8`)
- `can04:s9.5-02` (SHALL NOT) — **Machine-testable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L496 (line sha256 `b3ac917e35c267a43ed565bd8b111ba1033bfcbfb5ebbd42e8ed749b230443e2`)
- `can04:s9.5-03` (SHALL NOT, SHALL) — **Machine-testable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L497 (line sha256 `72a3940071945965875df95e017d974a698291d0efbe5ce509478f585569b605`)
- `can04:s9.5-04` (SHALL) — **Machine-testable**
  - Access 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L501 (line sha256 `f440ab94e38d0d764b65e4bb9f9c328aa6971d379cdd5ca0675cd2fc24834123`)
- `can04:s9.5-05` (SHALL) — **Machine-testable**
  - Each successful token refresh is required to reset the rolling 90-day expiration window.
  - Observable in the expiry metadata across successive refreshes.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L502 (line sha256 `b62183cc79f04ae1d59714c627b63ec46a4f9e876c000c93fa60be60293eb1af`)
- `can04:s9.5-06` (SHALL) — **Machine-testable**
  - Access tokens are required to have a lifetime of no more than one hour.
  - Inspect issued-token lifetimes; a concrete numeric bound.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L503 (line sha256 `53d16a19c54111dbeac18f2539d184fec9cbc801cc68bba78ef5597ccfa8420a`)
### §10 Query / Data Exchange

- `can04:s10-01` (MUST NOT, MUST) — **Not a requirement** — editorial callout · keyword unbolded
  - An 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L509 (line sha256 `e8889c15c79d5b77a8d1e2b073278831ca04d231125259f8348d740758e07daf`)
### §10.1 Respond Completely

- `can04:s10.1-01` (MUST) — **Testable with fixtures**
  - An 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L513 (line sha256 `f3d1fdaa812ae7e21d2e4805a6712b18571d5e6c7eea023fc4e69a1556ff4607`)
- `can04:s10.1-02` (MUST, SHOULD) — **Defers to a reference**
  - The 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L515 (line sha256 `fc5f431b7784e92fa0b93f9944521f2c370e5187a2380531e595c53407d1d0a2`)
### §10.2 Use Case Coverage

- `can04:s10.2-01` (MUST) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L533 (line sha256 `1cabf61cc9806b32e0e456ea1de5099dee5e24170a68befe52ec14c065955ef8`)
- `can04:s10.2-02` (MUST) — **Procedurally observable**
  - If 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L541 (line sha256 `d397f41292b2ba881663453f4256e5f031e400aae762210f36af685b7f12c00d`)
### §10.3 Purpose of Use Propagation

- `can04:s10.3-01` (MUST) — **Testable with fixtures**
  - Every 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L545 (line sha256 `4b54c5542ea01772bee6a45bfd18f8d0657d00a5b9a4362d5c1d83d66b11d5f0`)
- `can04:s10.3-02` (REQUIRED) — **Machine-testable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L547 (line sha256 `0fea2ecb4f759e8087e81895bd4ea76a352e604b96a6fcbfc60c8b6bb833411f`)
- `can04:s10.3-03` (MUST) — **Procedurally observable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L558 (line sha256 `8f7598484685ba822e3785347eee93a310fab528d3ec44a522b9217af968c0ff`)
- `can04:s10.3-04` (MUST NOT, MUST, MAY) — **Procedurally observable**
  - With 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L560 (line sha256 `ff072e7c4a0dcc165138ff473757337b83c96201edffc7df70914977b94f53d3`)
### §10.4 Patient-Contributed Data

- `can04:s10.4-01` (SHOULD) — **Underspecified as written**
  - Networks 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L566 (line sha256 `0188068a982f7aeefe57d861565bdd704ac56951d4532d83be59fc8070b28890`)
### §11 National Provider Directory Publication

- `can04:s11-01` (MUST) — **Machine-testable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L572 (line sha256 `c070af24764e7e934fc1067eea1d18db5cdc8cce2e593a711ba4674f16cb9b61`)
- `can04:s11-02` (MUST) — **Underspecified as written** — editorial callout
  - If 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L582 (line sha256 `8d83e9afb752470027ccc1b45f4f67065554d99bff77eefa897ee59f8ae6a9b7`)
- `can04:s11-03` (MUST, SHOULD) — **Machine-testable** — editorial callout
  - Networks 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L586 (line sha256 `864312f40443d542a7e0ac0bb70fb279ea45b9bd4abd9e8f755679d92e231b0f`)
- `can04:s11-04` (MUST, SHOULD) — **Underspecified as written**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L588 (line sha256 `2dcd363a1ee4c8b339b07351183c564652453d9ef8fbb78e9d9050a62ece5d48`)
- `can04:s11-05` (MUST) — **Machine-testable**
  - The 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L590 (line sha256 `52a75f1e537384ad18c8e193518f1c241ec2299a4a6c2e273f6491fb612b24ee`)
### §12 Audit Logging

- `can04:s12-01` (MUST) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L596 (line sha256 `f82ff6fd9b56936dcf9f115096016beae17e8b4e0f655d90b0f94d02a08fac4b`)
- `can04:s12-02` (MUST) — **Procedurally observable**
  - Audit 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L603 (line sha256 `a24b9410c31113068ee2b3efcf18592dbb7d486df7b96ba0b2ac7f8eb469a11f`)
- `can04:s12-03` (MUST) — **Defers to a reference**
  - A 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L605 (line sha256 `af7c60de548ab139f89b5ba134edae83082735659ae62fa191eb5e0c3adfc5d1`)
### §13 Security

- `can04:s13-01` (MUST) — **Procedurally observable** — keyword unbolded
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L617 (line sha256 `8b7dd4c9fc649f94b8a5993f8338af8aafd753cd95b330b04550df25bed7d193`)
- `can04:s13-02` (MUST, MAY) — **Underspecified as written** — keyword unbolded
  - Business 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L621 (line sha256 `1ce5d3d450f3a357f57aeca3f2271d53ee66b2fa7a7ba7cc6f15d9ab6f0434cb`)
### §14.1 Patient-Directed Access

- `can04:s14.1-01` (MUST NOT) — **Procedurally observable**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L629 (line sha256 `793550f921b1205b993e24b55aa0144248b19a642d12cabe8a785e96bbb12b3c`)
### §14.2 Above the Floor

- `can04:s14.2-01` (MAY) — **Not a requirement**
  - Above the federal floor, a network may set its own commercial terms for the enumerated services.
  - A permission delimiting the competitive space; it obliges nothing.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L635 (line sha256 `21a1bf930f9a951abbd7d0cb548abc7252464337a09ab2fcad84e46b9f025799`)
### §14.3 Inter-Network Settlement

- `can04:s14.3-01` (MAY) — **Not a requirement**
  - For non-patient-access traffic, networks may negotiate commercial peering with settlement or transit terms above the floor.
  - A permission; it obliges nothing.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L646 (line sha256 `22ac10ceff57bd96c166197f2686a24ac838a5375ece3502d23c9ab5e229ad8f`)
### §15 Accountability

- `can04:s15-01` (MUST) — **Underspecified as written**
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L656 (line sha256 `b696520676319afe8b1229c4e00d17170dbd3302e3bcb935f2e5f384731d5458`)
### §16 July 4, 2026 Framework Requirements

- `can04:s16-01` (MUST) — **Defers to a reference** — outside conformance scope
  - By 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L664 (line sha256 `5b22fd52f32e4efe158765f050dbe164d2a90899c04ad22d4f385d7fd60cb9f9`)
### §16.1 FHIR API Access

- `can04:s16.1-01` (MUST) — **Defers to a reference** — outside conformance scope
  - A 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L668 (line sha256 `aaa537db17439d4e90ef2a7169fb533502832050f05ca19d2b8f77f7a6ddf591`)
- `can04:s16.1-02` (SHOULD) — **Defers to a reference** — outside conformance scope
  - A 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
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L673 (line sha256 `23ecf3d9150a443207c18e2637cd74585df23ee3734b6269ba7a0dd84409467e`)
### §16.2 Chart Notes and Clinical Documents

- `can04:s16.2-01` (MUST, SHOULD) — **Testable with fixtures** — outside conformance scope
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L677 (line sha256 `361afef9c641f346f9cbefd8c3557ef512af69715318bbbf97e988984426ca8f`)
### §16.3 Appointment and Encounter Notifications

- `can04:s16.3-01` (MUST) — **Procedurally observable** — outside conformance scope
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L681 (line sha256 `0c8dfcea450ccff003567952fbbc22234129dd9ad8fa70f871f301d1591a2f50`)
### §16.4 Record Locator Service

- `can04:s16.4-01` (MUST) — **Underspecified as written** — outside conformance scope
  - A 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L689 (line sha256 `7fcc88bca4e3d384454fee350b838783d9004b4543921186006db01987217ff4`)
- `can04:s16.4-02` (MUST) — **Procedurally observable** — outside conformance scope
  - Record-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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L694 (line sha256 `a4199132951c10e970902df810d668cfea517d10a3e1298017103b64a2a5cec3`)
### §A . Open Questions

- `can04:sA-01` (MUST) — **Not a requirement** — outside conformance scope · keyword unbolded
  - An 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.
  - Source: https://github.com/icanbwell/cms-ns/blob/a05a1a73f9e7ff2a1abb57dc6666a6f9bce62f85/can-spec.md#L715 (line sha256 `725fca1c7241c2d5010fcb920e77d8fd10b5ed6d6e0ef2805a09d39cf85fdc8a`)