technology

HTI-1 changed certified health IT—not every pharmacy connection

ONC's rule advances certification, USCDI, information sharing, and algorithm transparency. An integration claim still needs an account-specific test of the named systems, versions, fields, direction, failure path, and implementation scope.

Team reviewing a healthcare data-flow diagram
A national interoperability standard does not replace an account-specific data-flow test.

Start with the exact certification claim

ONC says HTI-1 updates certification criteria, algorithm transparency, information-sharing provisions, and interoperability standards. USCDI version 3 becomes the certification-program baseline as of January 1, 2026. Those are meaningful rule facts, but they are not a description of every pharmacy product or connection.

The rule does not prove that a consultant-pharmacy application is certified, connected to a facility's system, or entitled to every desired data element. When a seller invokes HTI-1, USCDI, or certification, ask which named product, version, component, and criterion support the statement.

Keep the vendor's answer attached to its source and date. 'Built for,' 'compatible with,' 'uses,' 'connects to,' and 'certified under' are different claims. Do not compress them into one interoperability score or infer a live connection from standards language alone.

Translate the claim into one account-specific data map

Name the source and destination systems, their versions, the data classes and fields, direction, trigger, cadence, identity-matching method, error path, and source of truth. Draw manual steps too. An export, import, one-time conversion, API, and supported ongoing interface may all move data, but they create different operating work.

  • Systems: the exact products, versions, modules, and environments in the proposed route.
  • Data: the classes and fields expected to move, including what is explicitly out of scope.
  • Direction and timing: one way or two way, event driven or scheduled, and the expected cadence.
  • Identity: how residents and facilities are matched and how possible duplicates are held for review.
  • Authority: which system is the source of truth when values conflict and who may resolve them.
  • Failure: what users see when a message is late, rejected, incomplete, duplicated, or corrected.

Separate technical possibility from supported implementation

Ask who contracts, configures, maps, tests, accepts, monitors, supports, and pays for the connection. Identify dependencies on the facility, dispensing pharmacy, another vendor, or a service partner. A standard may make exchange more feasible without making this account's route available or complete.

Put the answers beside the proposal. If a connection requires scoped work, record the deliverables, owners, test data, acceptance criteria, estimated sequence, and handling of later source-system changes. Do not describe roadmap work or an unconfirmed partnership as live functionality.

Demonstrate the exception path, not only a clean message

Use a synthetic resident transfer or order change and include a possible duplicate, missing identifier, delayed message, and later correction. Follow the item from the source through the consultant's worklist, report, and export. Inspect what each permitted user sees and who receives the exception.

Then interrupt the route. Ask how the team knows the flow stopped, which records remain queued, how replay or correction is handled, and whether earlier reports change. The test should preserve the original event and later action rather than make the history look as though the error never occurred.

Record what the evidence establishes—and what it does not

Use four states: demonstrated in the named environment; available with scoped work; unavailable; or still to confirm. Add the observation date, system versions, evidence, implementation owner, and unresolved dependency. A public claim that cannot be tested may remain unconfirmed without being scored as absent.

A successful demonstration shows that the tested route behaved as observed on that date. It does not establish continuous production performance, complete data quality, certification of every component, or fitness for every workflow. Reconcile the result with contracts, support terms, security review, and the practice's own requirements.

Let the acronym open the test, not decide it

HTI-1 and USCDI provide important policy and standards context. The buyer's operational question remains narrower: will the named systems move the required information, surface exceptions, preserve corrections, and assign responsibility in this implementation?

Answer that question with a data map, demonstration, written scope, and unresolved-issues list. That is more useful than treating national standards progress as proof of a connection the practice has not seen.

About the author

Theo Bennett

Theo covers health technology and software buying, focusing on integrations, data portability, implementation, security questions, and what vendors can actually demonstrate.

Read Theo Bennett's editorial profile

Signed by Theo Bennett