Réponse courte : CDS Hooks est une norme HL7 qui permet à un Dossier Patient Informatisé (DPI) d'appeler un service externe de support à la décision clinique à des moments définis (hooks) dans le flux de travail d'un clinicien : ouverture du dossier d'un patient (patient-view), choix d'une prescription (order-select), signature des prescriptions (order-sign), début ou fin d'une prise en charge. Le DPI envoie le contexte et, facultativement, des données FHIR pré-récupérées ; le service répond en quelques secondes avec des cartes : de courtes informations, des avertissements ou des suggestions, et des liens qui peuvent lancer une application SMART on FHIR. Le clinicien reste dans le DPI ; l'intelligence réside à l'extérieur.
Les trois étapes
CDS Hooks fonctionne en trois étapes. Premièrement, la découverte : le DME récupère GET /cds-services et apprend à quel hook chaque service répond et quelles données FHIR il souhaite pré-charger. Deuxièmement, l'appel du hook : lors d'un événement de flux de travail tel que la signature d'une commande, le DME envoie par POST le contexte et les ressources pré-chargées au service. Troisièmement, la réponse : le service renvoie des cartes que le DME affiche.
1. Découverte. Le DPI récupère GET https://cds.example.org/cds-services et reçoit la liste des services, chacun avec le hook auquel il répond et les requêtes FHIR qu'il souhaiterait pré-récupérer :
{
"services": [{
"id": "renal-dosing",
"hook": "order-sign",
"title": "Renal dosing check",
"description": "Flags drug orders whose dose needs review against the latest eGFR.",
"prefetch": {
"patient": "Patient/{{context.patientId}}",
"egfr": "Observation?patient={{context.patientId}}&code=http://loinc.org|98979-8&_sort=-date&_count=1"
}
}]
}
2. L'appel du hook. Lorsque le clinicien signe des prescriptions, le DPI POSTe à /cds-services/renal-dosing :
{
"hookInstance": "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
"hook": "order-sign",
"fhirServer": "https://ehr.example.org/fhir",
"fhirAuthorization": {"access_token": "…", "token_type": "Bearer", "expires_in": 300, "scope": "patient/*.read", "subject": "renal-dosing"},
"context": {
"userId": "Practitioner/42",
"patientId": "123",
"draftOrders": {"resourceType": "Bundle", "entry": [{"resource": {"resourceType": "MedicationRequest", "id": "draft-1", "status": "draft"}}]}
},
"prefetch": {
"patient": {"resourceType": "Patient", "id": "123"},
"egfr": {"resourceType": "Bundle", "type": "searchset", "entry": [{"resource": {"resourceType": "Observation", "id": "obs-9", "status": "final", "code": {"coding": [{"system": "http://loinc.org", "code": "98979-8"}]}, "valueQuantity": {"value": 38, "unit": "mL/min/1.73m2"}}}]}
}
}
Si un élément dont le service a besoin n'a pas été pré-récupéré, il peut interroger le serveur FHIR du DPI lui-même avec le jeton de courte durée dans fhirAuthorization.
3. La réponse. Cartes, et dans la version 2.0 également des actions système :
{
"cards": [{
"uuid": "9a1d2f3e-…",
"summary": "eGFR 38: dose review suggested",
"indicator": "warning",
"detail": "The most recent eGFR (38 mL/min/1.73m², 2026-03-10) is below the threshold in the local renal dosing guidance for this drug.",
"source": {"label": "Hospital renal dosing guidance", "url": "https://intranet.example.org/renal"},
"suggestions": [{"label": "Open renal dosing table", "uuid": "…", "actions": []}],
"links": [{"label": "Dosing calculator", "url": "https://apps.example.org/renal/launch", "type": "smart"}]
}]
}
summary est limité à 140 caractères ; indicator est info, warning ou critical ; source est obligatoire pour que le clinicien sache qui parle. suggestions peut proposer des modifications concrètes (créer, mettre à jour ou supprimer une ressource brouillon) que le clinicien accepte en un clic ; les links de type smart ouvrent une application SMART en contexte. Le DPI rend les cartes dans son propre style ; le service ne dessine jamais sa propre interface utilisateur à l'intérieur du DPI.
Ajouts de la version 2.0
La version 2.0 de CDS Hooks, publiée en 2022, a ajouté un point d'accès pour les retours d'information, via lequel le DME signale si une carte a été acceptée, ignorée ou remplacée avec des raisons ; les "systemActions", des modifications que le DME applique sans demander, pour des tâches de maintenance à faible risque ; le champ "fhirAuthorization.subject" ; et des règles "selectionBehavior" plus claires (at-most-one ou any) pour les suggestions.
Publiée en 2022 : un point d'accès feedback (POST /cds-services/{id}/feedback) par lequel le DPI signale si une carte a été acceptée, ignorée (avec les raisons) ou refusée ; systemActions, des modifications que le DPI applique sans demander, destinées à des tâches de maintenance à faible risque comme l'ajout d'une raison codifiée ; fhirAuthorization.subject ; et des règles plus claires sur selectionBehavior (at-most-one ou any) pour les suggestions.
Ce qu'est et n'est pas un service
Un service CDS Hooks est un logiciel qui lit le contexte du flux de travail et renvoie des informations sous forme de cartes ; ce n'est pas automatiquement un dispositif médical. Que les règles relatives aux dispositifs médicaux s'appliquent ou non dans l'UE et aux États-Unis dépend du contenu : rappeler à un clinicien qu'une valeur de laboratoire existe est une information, tandis qu'une recommandation de dose spécifique au patient est un support décisionnel réglementé.
Un service CDS est un logiciel qui lit le contexte et renvoie des informations. Le fait qu'il s'agisse d'un dispositif médical dépend de ce que disent les cartes : un rappel qu'une valeur de laboratoire existe est une information ; une recommandation de dose pour un patient spécifique est un support à la décision qui relève des règles des dispositifs médicaux dans l'UE et aux États-Unis. Voir Une application de santé est-elle un dispositif médical ?. La norme est neutre ; le contenu ne l'est pas.
Hooks définis aujourd'hui : patient-view, order-select, order-sign, order-dispatch, encounter-start, encounter-discharge, appointment-book, avec un catalogue public où de nouveaux hooks sont proposés.
Relation avec SMART on FHIR
CDS Hooks et SMART on FHIR sont complémentaires. SMART on FHIR lance une application qui prend en charge une partie de l'écran et interroge le serveur FHIR avec l'autorisation de l'utilisateur ; CDS Hooks s'exécute en arrière-plan et renvoie des cartes dans l'interface du DME. Une carte peut contenir un lien de lancement SMART lorsqu'une carte seule ne suffit pas.
SMART on FHIR lance une application qui prend le contrôle d'une partie de l'écran et communique avec le serveur FHIR avec l'autorisation de l'utilisateur. CDS Hooks fonctionne en arrière-plan et renvoie des cartes ; une carte peut contenir un lien de lancement SMART lorsqu'une carte seule ne suffit pas. La plupart des produits de support à la décision utilisent les deux : hooks pour la notification, une application SMART pour les détails.
Où se situe Anpheros
Anpheros n'offre pas de service CDS Hooks et ne produit pas de recommandations cliniques. Son dossier FHIR, avec le consentement du patient, peut être les données qu'un service de support à la décision de l'hôpital lit (médicaments, allergies, résultats récents), via la même API FHIR qu'un service de hook utiliserait. Voir Plateforme de consentement patient.
Pages associées
- Explication des abonnements FHIR
- Une application de santé est-elle un dispositif médical ? Règlement UE MDR 11
- Plateforme de consentement patient
- Explication de la recherche FHIR
- Backend SMART on FHIR (développeurs)
- Normes d'interopérabilité des soins de santé : la carte
- Explication du lancement d'application SMART
Sources
- Spécification HL7 CDS Hooks 2.0
- CDS Hooks : catalogue des hooks
- HL7 SMART App Launch
- HL7 FHIR R4 : MedicationRequest
Questions fréquentes
Est-ce que CDS Hooks fait partie de FHIR ?
C'est une spécification HL7 distincte qui utilise FHIR pour ses données : le préfetch et le contexte transportent des ressources FHIR, et l'autorisation réutilise les jetons SMART on FHIR. Elle est publiée par HL7 à côté de FHIR, pas à l'intérieur de la spécification FHIR.
Quelle est la rapidité de réponse attendue d'un service CDS ?
La spécification ne fixe pas de nombre, mais les DPI appliquent des délais d'expiration de quelques secondes et rejettent les réponses tardives, car le clinicien attend. Le préfetch existe précisément pour que le service ne passe pas ce temps à interroger.
Un service CDS peut-il modifier une prescription ?
Seulement en proposant une suggestion que le clinicien accepte, ou, dans la version 2.0, via des systemActions que le DPI a accepté d'appliquer automatiquement pour ce service. Le service n'écrit jamais dans le serveur FHIR du DPI de sa propre initiative pendant un hook.
Une application patient utilise-t-elle CDS Hooks ?
Non. CDS Hooks est conçu pour les flux de travail des DPI destinés aux cliniciens. Les applications patient utilisent directement l'API FHIR et SMART on FHIR pour la connexion.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →