How to prove HTI-1 readiness (most teams can't)

Here is the uncomfortable short answer: most healthcare teams cannot prove they are HTI-1 ready. They assume it. They read the rule, stand up a FHIR endpoint, get a 200 response, and move on. Then an audit, a procurement security review, or a breach turns "we thought we were fine" into a problem, because assumption is not evidence.

HTI-1 readiness is provable. This is how to actually pressure-test it before someone else finds the gaps for you.

What HTI-1 actually expects

The ONC HTI-1 final rule updated the certification program: adoption of USCDI v3, new and revised certification criteria, the information-blocking framework with its defined exceptions, and algorithm transparency for certified decision-support. Alongside it, the CMS interoperability and prior-authorization rules raise the bar on what your APIs must actually serve. Certification and "we built the API" are not the same thing as conforming to the guides under real conditions.

The five gaps that show up most

1. Capability discovery that does not resolve cleanly

The first thing any conformance check hits is your /metadata CapabilityStatement. If it does not resolve quickly, declare the right FHIR version, and list the resources you are required to serve, you have failed step one before anyone looks at the data.

2. Wrong profiles

Returning a valid FHIR resource is not the same as returning the required profile. Teams validate against generic US Core when the rule points at a specific implementation guide with must-support elements and extensions that generic validation never checks.

3. Missing must-support elements

"Must-support" is not optional. Data that omits required elements passes a casual eye and fails a conformance suite. This is the single most common silent gap.

4. Data that does not round-trip

An endpoint can accept a request, return a 200, and still hand back data that cannot be consumed, reconciled, or written back correctly. Round-trip testing surfaces what a single happy-path call hides.

5. Information-blocking exceptions with no documentation

If you withhold data, you must name which exception under the information-blocking framework you are claiming, with the conditions met. "We were not comfortable releasing that" is not an exception.

What "provable" actually looks like

Provable means citation-level evidence you can hand to a regulator, a procurement team, or your board on demand, not a binder you update once a year. For each requirement, you should be able to show: the rule, the specific test, the result, and the artifact that proves it. When that evidence is generated continuously rather than once, you also catch drift, the slow divergence that happens as code ships and rules change.

The patterns that fail interoperability surveillance are almost never "we did not build the API." They are "we built it, and the implementation has gaps that only show up under real load, real profiles, or real edge cases."

A 5-step readiness check you can run this week

1. Run capability discovery against your own endpoint. If it does not resolve cleanly, that is your starting point.
2. Validate against the specific implementation guide the rule names, not just US Core.
3. Test must-support elements explicitly, and round-trip the data, do not stop at a 200.
4. Document every information-blocking exception by name, with the conditions met.
5. Capture the evidence as you go, so readiness is something you can show, not something you assert.

This is exactly what we built TAP (the Technical Audit Protocol) to do: automated conformance and readiness auditing that produces citation-level, evidence-backed findings in minutes, with continuous monitoring as the rules change. The output is the thing you actually need under audit: proof.