USCDI v3, v4 et HTI-1 pour les éditeurs de logiciels de santé : ce qui a changé et ce qu’il faut construire

Réponse directe

USCDI v3 est le socle de données obligatoire pour les logiciels certifiés par l'ONC. HTI-1 avait fixé l'échéance au 31 décembre 2025, et un avis de tolérance (enforcement discretion) a laissé aux éditeurs jusqu'au 28 février 2026. Pour l'API (g)(10), cela signifie US Core 6.1.0 et SMART App Launch 2.0.0. USCDI v4, v5 et v6 sont des montées de version facultatives via le SVAP, et la v7 a été publiée en juillet 2026. HTI-5, qui supprimerait 34 critères de certification, n'est encore qu'un projet de règle.

Les règles HTI et leur statut

L'ONC fonctionne désormais sous le nom ASTP/ONC. La page des règles HTI recense quatre règles définitives et un projet. La plupart mettent en œuvre le 21st Century Cures Act de décembre 2016, qui a créé l'interdiction du blocage d'information et les conditions de certification liées aux API.

Votre certification actuelle repose sur la règle finale HTI-1. Le projet de règle HTI-5 sert à anticiper. La presse spécialisée indiquait en août 2026 que la version finale de HTI-5 était en revue à l'OMB, mais elle n'était toujours pas parue au Federal Register début octobre 2026. N'engagez pas votre feuille de route sur son contenu avant sa publication.

Versions USCDI, versions US Core et statut de certification

USCDI est la liste ONC des classes et éléments de données. US Core est le guide d'implémentation HL7 FHIR qui les représente. Les critères de certification citent une version USCDI, et votre serveur FHIR embarque un package US Core. Les deux doivent figurer dans vos décisions d'architecture. La page de toutes les versions USCDI fait foi.

Le Standards Version Advancement Process (SVAP) permet à un éditeur de se certifier sur une version plus récente que celle exigée par la réglementation. Il reste facultatif. Le socle réglementaire demeure obligatoire : un module sur US Core 9.0.0 doit toujours satisfaire les exigences USCDI v3.

Deux avis de 2025 ont modifié la portée réelle d'« USCDI v3 ». Le 21 mars 2025, l'ASTP/ONC a annoncé une tolérance pour l'orientation sexuelle, l'identité de genre et les éléments associés, et autorisé la représentation du sexe avec les seuls codes 248152002 (Female) et 248153007 (Male). Le 24 novembre 2025, il a reporté l'échéance du 1er janvier 2026 au 28 février 2026 pour 15 critères, dont (g)(10), après la suspension de financement de l'automne 2025 qui avait mis hors ligne les outils de test. Les deux figurent sur la page des avis de tolérance.

Ce qu'USCDI v3 a ajouté et où cela se trouve dans US Core 6.1.0

Par rapport à la v2, USCDI v3 ajoute deux classes de données, Health Insurance Information et Health Status/Assessments, ainsi que de nouveaux éléments dans les classes existantes. La correspondance USCDI d'US Core 6.1.0 sert de référence élément par élément.

Coverage est la classe que la plupart des équipes sous-estiment : ces données vivent dans les systèmes d'admission et de facturation, qui n'alimentaient pas le serveur FHIR clinique. Une instance synthétique minimale :

{
  "resourceType": "Coverage",
  "meta": {
    "profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-coverage"]
  },
  "identifier": [{
    "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MB" }] },
    "system": "http://example.org/fhir/memberidentifier",
    "value": "M-000123"
  }],
  "status": "active",
  "type": { "coding": [{ "system": "https://nahdo.org/sopt", "code": "3712", "display": "PPO" }] },
  "subscriberId": "S-000456",
  "beneficiary": { "reference": "Patient/example-123" },
  "relationship": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship", "code": "self" }] },
  "payor": [{ "reference": "Organization/example-payer" }],
  "class": [{
    "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/coverage-class", "code": "group" }] },
    "value": "GRP-7781"
  }]
}

Le Group Number va dans class avec le type group, le Member Identifier est l'identifier typé MB, et le Payer Identifier se trouve sur l'Organization référencée. Une erreur fréquente consiste à mettre le numéro de groupe dans identifier. La ressource reste valide, mais le Group Number n'est pas à l'endroit où les consommateurs et les outils de test le cherchent.

L'API (g)(10) après HTI-1

Le guide de certification (g)(10) détaille les exigences en vigueur. Ce que HTI-1 a changé :

• US Core 6.1.0 et SMART App Launch 2.0.0, avec des options SVAP pour les versions ultérieures d'US Core et SMART 2.2.0.
• Les scopes SMART v2, y compris les scopes granulaires sur les catégories de Condition et d'Observation, par exemple patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory.
• La révocation de l'accès d'une application dans l'heure suivant la demande du patient, exigée depuis le 11 mars 2024.
• Des refresh tokens valables au moins trois mois pour les applications confidentielles et les applications natives capables de les protéger.
• L'authentification client asymétrique (client-confidential-asymmetric) et l'autorisation par POST (authorize-post).
• La publication des URL de base des services dans un format FHIR standardisé, exigée depuis le 31 décembre 2024.

Vérifiez votre document de découverte avant de lancer le kit de test :

GET /fhir/r4/.well-known/smart-configuration
Accept: application/json

{
  "capabilities": [
    "launch-ehr", "launch-standalone", "authorize-post",
    "client-public", "client-confidential-symmetric", "client-confidential-asymmetric",
    "sso-openid-connect", "context-banner", "context-style",
    "context-ehr-patient", "context-ehr-encounter", "context-standalone-patient",
    "permission-offline", "permission-patient", "permission-user", "permission-v2"
  ],
  "code_challenge_methods_supported": ["S256"]
}

Les flux de lancement, les scopes et PKCE sont détaillés dans SMART on FHIR : lancement d'applications. Pour la certification, le kit de test Inferno (g)(10) est la méthode approuvée. Avant de choisir une version SVAP, vérifiez quelles versions d'US Core la version courante du kit prend en charge : le support du kit peut avoir du retard sur l'approbation SVAP.

Interventions d'aide à la décision et condition Insights

HTI-1 a remplacé le critère d'aide à la décision clinique par celui des decision support interventions (DSI, 170.315(b)(11)). Les éditeurs devaient le livrer au 31 décembre 2024. Il impose 13 attributs sources pour les DSI fondées sur des preuves et 31 pour les DSI prédictives, ainsi que des pratiques de gestion des risques pour les DSI prédictives fournies par l'éditeur. Concrètement, cela ressemble à une fiche de modèle (model card) consultable par les clients.

HTI-5 propose de réviser (b)(11) et de supprimer les exigences d'attributs sources. Tant qu'aucune règle finale n'en décide autrement, le critère s'applique tel qu'il est rédigé.

La condition Insights prévoyait initialement plusieurs indicateurs à déclarer à partir de juillet 2027. Un avis de tolérance d'avril 2025 a limité la déclaration à un seul indicateur, l'usage de FHIR dans les applications via les logiciels certifiés, et HTI-5 propose d'inscrire cette limite dans la réglementation.

Blocage d'information : acteurs, exceptions, sanctions

Le blocage d'information vise trois types d'acteurs : les professionnels et établissements de santé, les éditeurs de logiciels certifiés, et les réseaux ou plateformes d'échange (HIN/HIE). Depuis le 6 octobre 2022, les données de santé électroniques (EHI) concernées ne se limitent plus à USCDI. Elles couvrent les ePHI d'un designated record set : une API limitée à USCDI ne suffit donc pas à remplir vos obligations.

Le 45 CFR Part 171 compte aujourd'hui dix exceptions :

HTI-1 a aussi défini la notion d'« offer health IT » et ajouté deux conditions à l'exception Infeasibility : les demandes de modification par un tiers et le cas où les modalités alternatives ont été épuisées. HTI-5 propose de supprimer la condition sur la modification par un tiers et l'exception TEFCA Manner, et d'exiger que les contrats relevant de l'exception Manner soient au prix du marché et sans clauses abusives. Pour les QHIN et le volet TEFCA, voir TEFCA expliqué et mise en œuvre d'US Core et TEFCA.

Les sanctions dépendent du type d'acteur :

• Éditeurs et HIN/HIE : sanctions pécuniaires civiles de l'OIG pouvant atteindre 1 million de dollars par infraction, en vigueur depuis le 1er septembre 2023. Un éditeur peut aussi perdre sa certification.
• Professionnels et établissements : désincitations CMS depuis le 31 juillet 2024. Les hôpitaux perdent le statut de meaningful EHR user, les cliniciens MIPS obtiennent zéro en Promoting Interoperability, et les participants au Shared Savings Program peuvent en être exclus pendant au moins un an (à partir du 1er janvier 2025).

Le 3 septembre 2025, le HHS a annoncé un durcissement des contrôles : l'OIG instruit les signalements et l'ASTP/ONC renforce la surveillance des certifications.

Liste de contrôle pour les éditeurs

• Figer USCDI v3 et US Core 6.1.0 comme plancher, et consigner toute version SVAP adoptée.
• Exposer Coverage, les observations d'état de santé, Specimen, MedicationDispense, RelatedPerson et ServiceRequest. Ce sont les ajouts v3 les plus souvent oubliés.
• Valider chaque ressource contre les profils, slices must-support comprises, avec le validateur HL7 avant de passer Inferno.
• Réussir le kit Inferno (g)(10) : lancement patient autonome, lancement depuis le DPI, scopes granulaires, renouvellement de jeton, révocation et export Bulk Data.
• Publier les URL de base des services au format FHIR standardisé.
• Tester la révocation de bout en bout : le patient révoque, et l'appel API suivant dans l'heure renvoie 401.
• Tenir une politique écrite sur le blocage d'information qui cite l'exception invoquée chaque fois que vous refusez ou limitez une demande.
• Si vous intégrez des flux payeurs, les critères HTI-4 (g)(31) à (g)(33) reposent sur Da Vinci CRD, DTR et PAS. Voir autorisation préalable Da Vinci.
• Si vous vendez aussi en Europe, gardez des jeux de profils séparés. EU Core et US Core ne sont pas interchangeables.

Pièges

• Prendre le SVAP pour une échéance. US Core 9.0.0 est facultatif. USCDI v3 sur US Core 6.1.0 est obligatoire.
• Lire HTI-5 comme du droit en vigueur. Les critères de sécurité, comme l'authentification multifacteur (d)(13), s'appliquent tant qu'une règle finale ne les a pas supprimés.
• Supposer que USCDI v4 est la prochaine étape. La proposition HTI-2 de l'adopter a été retirée, et HTI-5 propose la v3.1.
• Limiter le blocage d'information à l'API. La définition des EHI dépasse USCDI.

Pour une analyse d'écarts US Core, la préparation aux tests (g)(10) ou une façade FHIR devant un DPI existant, voir intégration HL7 FHIR.