Kurze Antwort: CDS Hooks ist ein HL7-Standard, der es einem KIS ermöglicht, einen externen klinischen Entscheidungsunterstützungsdienst zu definierten Zeitpunkten (Hooks) im Arbeitsablauf eines Klinikers aufzurufen: beim Öffnen der Patientenakte (patient-view), bei der Auswahl einer Verordnung (order-select), beim Unterzeichnen von Verordnungen (order-sign), beim Starten oder Beenden einer Behandlung. Das KIS sendet den Kontext und optional vorab abgerufene FHIR-Daten; der Dienst antwortet innerhalb von Sekunden mit Karten: kurzen Informationen, Warnungen oder Vorschlägen und Links, die eine SMART on FHIR-App starten können. Der Kliniker bleibt im KIS; die Intelligenz lebt außerhalb davon.
Die drei Schritte
CDS Hooks funktioniert in drei Schritten. Erstens, Discovery: Das KIS ruft GET /cds-services auf und erfährt, auf welchen Hook jeder Dienst antwortet und welche FHIR-Daten vorab abgerufen werden sollen. Zweitens, der Hook-Aufruf: Bei einem Workflow-Ereignis wie order-sign sendet das KIS den Kontext und die vorab abgerufenen Ressourcen per POST an den Dienst. Drittens, die Antwort: Der Dienst gibt Karten zurück, die das KIS anzeigt.
1. Discovery. Das KIS ruft GET https://cds.example.org/cds-services ab und erhält die Liste der Dienste, jeweils mit dem Hook, auf den sie reagieren, und den FHIR-Abfragen, die sie vorab abrufen möchten:
{
"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. Der Hook-Aufruf. Wenn der Kliniker Verordnungen unterzeichnet, sendet das KIS eine POST-Anfrage an /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"}}}]}
}
}
Wenn etwas, das der Dienst benötigt, nicht vorab abgerufen wurde, kann er den FHIR-Server des KIS selbst mit dem kurzlebigen Token in fhirAuthorization abfragen.
3. Die Antwort. Karten und in Version 2.0 auch Systemaktionen:
{
"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 ist auf 140 Zeichen begrenzt; indicator ist info, warning oder critical; source ist obligatorisch, damit der Kliniker weiß, wer spricht. suggestions können konkrete Änderungen vorschlagen (Erstellen, Aktualisieren oder Löschen einer Entwurfsressource), die der Kliniker mit einem Klick akzeptiert; links vom Typ smart öffnen eine SMART-App im Kontext. Das KIS rendert die Karten in seinem eigenen Stil; der Dienst zeichnet niemals eine eigene Benutzeroberfläche innerhalb des KIS.
Ergänzungen in Version 2.0
CDS Hooks Version 2.0, veröffentlicht im Jahr 2022, fügte einen Feedback-Endpunkt hinzu, über den das KIS meldet, ob eine Karte akzeptiert, mit Gründen überschrieben oder ignoriert wurde; systemActions, Änderungen, die das KIS ohne Nachfrage vornimmt, für geringfügige Verwaltungsaufgaben; das Feld fhirAuthorization.subject; und klarere selectionBehavior-Regeln (at-most-one oder any) für Vorschläge.
Veröffentlicht im Jahr 2022: ein Feedback-Endpunkt (POST /cds-services/{id}/feedback), über den das KIS meldet, ob eine Karte akzeptiert, überschrieben (mit Gründen) oder ignoriert wurde; systemActions, Änderungen, die das KIS ohne Nachfrage anwendet, für risikofreie Verwaltungsaufgaben wie das Hinzufügen eines kodierten Grundes; fhirAuthorization.subject; und klarere Regeln für selectionBehavior (at-most-one oder any) für Vorschläge.
Was ein Dienst ist und was nicht
Ein CDS Hooks-Dienst ist eine Software, die den Workflow-Kontext liest und Informationen in Form von Karten zurückgibt; er ist nicht automatisch ein Medizinprodukt. Ob Medizinproduktregeln in der EU und den USA gelten, hängt vom Inhalt ab: Ein Hinweis an einen Kliniker, dass ein Laborwert vorliegt, ist eine Information, während eine patientenspezifische Dosisempfehlung eine regulierte Entscheidungsunterstützung ist.
Ein CDS-Dienst ist eine Software, die den Kontext liest und Informationen zurückgibt. Ob es sich um ein Medizinprodukt handelt, hängt davon ab, was die Karten sagen: Eine Erinnerung, dass ein Laborwert existiert, sind Informationen; eine Dosisempfehlung für einen bestimmten Patienten ist eine Entscheidungsunterstützung, die in der EU und den USA unter die Regeln für Medizinprodukte fällt. Siehe Ist eine Gesundheits-App ein Medizinprodukt?. Der Standard ist neutral; der Inhalt nicht.
Heute definierte Hooks: patient-view, order-select, order-sign, order-dispatch, encounter-start, encounter-discharge, appointment-book, mit einem öffentlichen Katalog, in dem neue Hooks vorgeschlagen werden.
Beziehung zu SMART on FHIR
CDS Hooks und SMART on FHIR ergänzen sich. SMART on FHIR startet eine App, die einen Teil des Bildschirms übernimmt und mit der Autorisierung des Benutzers den FHIR-Server abfragt; CDS Hooks läuft im Hintergrund und gibt Karten in die eigene Oberfläche des KIS zurück. Eine Karte kann einen SMART-Launch-Link enthalten, wenn mehr als nur eine Karte benötigt wird.
SMART on FHIR startet eine App, die einen Teil des Bildschirms übernimmt und mit der Zustimmung des Benutzers mit dem FHIR-Server kommuniziert. CDS Hooks läuft im Hintergrund und gibt Karten zurück; eine Karte kann einen SMART-Launch-Link tragen, wenn mehr als eine Karte benötigt wird. Die meisten Entscheidungsunterstützungsprodukte nutzen beides: Hooks für den Anstoß, eine SMART-App für die Details.
Wo Anpheros passt
Anpheros bietet keinen CDS Hooks-Dienst an und erstellt keine klinischen Empfehlungen. Seine FHIR-Akte kann mit Zustimmung des Patienten die Daten sein, die der eigene Entscheidungsunterstützungsdienst eines Krankenhauses liest (Medikamente, Allergien, aktuelle Ergebnisse) über dieselbe FHIR-API, die ein Hook-Dienst verwenden würde. Siehe Plattform für Patienteneinwilligung.
Verwandte Seiten
- FHIR-Abonnements erklärt
- Ist eine Gesundheits-App ein Medizinprodukt? EU MDR Regel 11
- Plattform für Patienteneinwilligung
- FHIR-Suche erklärt
- SMART on FHIR Backend (Entwickler)
- Standards für die Interoperabilität im Gesundheitswesen: die Karte
- SMART App Launch erklärt
Quellen
- HL7 CDS Hooks Spezifikation 2.0
- CDS Hooks: Hook-Katalog
- HL7 SMART App Launch
- HL7 FHIR R4: MedicationRequest
Häufige Fragen
Ist CDS Hooks Teil von FHIR?
Es ist eine separate HL7-Spezifikation, die FHIR für ihre Daten verwendet: Prefetch und Kontext tragen FHIR-Ressourcen, und die Autorisierung verwendet SMART on FHIR-Tokens wieder. Sie wird von HL7 neben FHIR veröffentlicht, nicht innerhalb der FHIR-Spezifikation.
Wie schnell muss ein CDS-Dienst antworten?
Die Spezifikation legt keine Zahl fest, aber KIS wenden Timeouts von einigen Sekunden an und verwerfen späte Antworten, da der Kliniker wartet. Prefetch existiert genau deshalb, damit der Dienst diese Zeit nicht mit Abfragen verbringt.
Kann ein CDS-Dienst die Verordnung ändern?
Nur durch Vorschlagen einer vom Kliniker akzeptierten Änderung oder, in Version 2.0, durch Systemaktionen, die das KIS für diesen Dienst automatisch anwenden soll. Der Dienst schreibt während eines Hooks nicht eigenmächtig in den FHIR-Server des KIS.
Verwendet eine Patienten-App CDS Hooks?
Nein. CDS Hooks ist für klinikerorientierte KIS-Workflows konzipiert. Patienten-Apps verwenden die FHIR-API direkt und SMART on FHIR für die Anmeldung.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →