VSAC and PHIN VADS serve different value-set programs

Choose the authority from the program

Use VSAC when the governing artifact is a CMS electronic clinical quality measure or another program that explicitly identifies VSAC content. Preserve the measure and release, value-set object identifier, name, expansion or definition version, code-system versions, retrieval method and time, user or service account context, and the exact artifact consumed by the implementation. A current VSAC expansion is not automatically the expansion required by an older measure release. ^[1]

Use PHIN VADS when the governing public-health program, jurisdiction, or HL7 implementation guide points to a PHIN vocabulary or value set. Retain the program and guide version, value-set and code-system identifiers, concept status, distribution or web-service response, retrieval time, and any jurisdiction-specific constraint. Public-health content with a familiar label should not be substituted into a measure or message without that governing reference. ^[2]

Freeze the terminology package with the release

A governed terminology package should record its authority, program, release, canonical identifier, human-readable name, definition or expansion form, included concepts, excluded concepts where represented, code systems and versions, effective or publication dates where supplied, access method, checksum or immutable artifact reference, and local load result. Store the source response so a later browser view does not silently replace the evidence used in production. ^{[1] [2]}

Keep value-set definition, expansion, local mapping, validation result, and downstream decision as separate records. A definition can resolve differently when code-system content or expansion parameters change. A successful import proves that a file was accepted by one system; it does not prove that every concept, display, status, hierarchy, mapping, or workflow interpretation is correct. ^{[1] [2]}

Migrate by identifier and program evidence

When a service, access method, or program distribution changes, inventory every dependency before moving content. Identify the local artifact, authority, program, guide or measure release, source identifier, code systems, retrieval job, transformation, validation rule, interface, decision, owner, and consumer. Map the old artifact to the new authoritative artifact explicitly; similar names and overlapping concepts are candidate evidence, not an equivalence proof. ^{[1] [2]}

Test additions, removals, inactive codes, changed displays, code-system versions, expansion parameters, duplicate identifiers, empty or failed responses, authentication, rate or availability behavior, and rollback. Preserve the old package and comparison. Where equivalence is unresolved, keep the dependent workflow on its approved baseline or route the gap for program and clinical review rather than silently choosing the newest expansion. ^{[1] [2]}

Test one code across two program contexts

A representative evaluation should retrieve one versioned VSAC value set tied to a stated measure and one PHIN VADS value set tied to a stated public-health guide. Reviewers should reproduce the source identifiers and versions, compare definition and expansion behavior, load the artifacts into a controlled terminology service, validate present, absent, inactive, and changed codes, and show that each downstream workflow uses the program-approved package. ^{[1] [2]}

The reviewed official pages establish the services' stated roles and access paths. They do not establish equivalence between two value sets, current availability of every artifact, conformance of a local terminology server, correctness of a mapping, measure validity, message acceptance, public-health reporting compliance, or clinical safety. Those conclusions require the governing program artifacts, complete versions, and qualified terminology, clinical, informatics, and program review. ^{[1] [2]}

Limitations and unknowns

• No value-set definition, expansion, API response, code-system version, implementation guide, measure release, local terminology server, mapping, message, workflow, or outcome was independently tested.
• The reviewed pages do not establish equivalence or migration mapping between any VSAC and PHIN VADS artifacts.
• Program-specific availability, licensing or authentication, jurisdictional requirements, and downstream acceptance remain unverified.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.