HIPAA und HDS-fähige Konten (zusammen „Gesundheitswesen-fähige Konten“):
Alle in diesem Dokument verwendeten Begriffe haben die im Business Associate Agreement („BAA“) oder im Rahmen-Abonnementvertrag von Zendesk vorgegebene Bedeutung für die Art des Kontos (zusammen „Gesundheitsvereinbarung“).
Bei HIPAA fähigen Konten bezieht sich „PHI“ auf „geschützte Gesundheitsdaten“ und bei HDS-fähigen Konten bezieht sich „PHI“ auf „personenbezogene Gesundheitsdaten“.
Zendesk und der Abonnent haben eine Gesundheitsvereinbarung abgeschlossen, in der dem Abonnenten empfohlen wird, je nach Anwendungsfall die folgenden Konfigurationen oder Alternativen zur Erfüllung seiner Compliance-Anforderungen nach geltendem Recht für jedes Gesundheitswesen aktivierte Konto zu prüfen und zu implementieren (s) zu aktualisieren, bevor PHI in den Dienst eingegeben wird.
Wenn der Abonnent nach eigenem Ermessen auf die Implementierung einer der unten aufgeführten empfohlenen Konfigurationen verzichten sollte, übernimmt er die alleinige Verantwortung für den unbefugten Zugriff auf oder die missbräuchliche Verwendung der Servicedaten des Abonnenten, einschließlich PHI-Daten, die sich aus beliebigen Daten ergeben solche Abweichungen von den empfohlenen Konfigurationen durch den Abonnenten vorgenommen haben.
Der Abonnent muss Servicepläne auf der entsprechenden Stufe gekauft haben und über die erforderlichen Add-ons verfügen (im Zweifelsfall wenden Sie sich an Ihren Kundenberater).
Wenn der Abonnent ein HDS-fähiges Konto hat, muss der Abonnent in der Zendesk-Richtlinie für Unterauftragsverarbeiter auf die Schaltfläche „Folgen“ klicken, um Benachrichtigungen über Änderungen der für die Bereitstellung der Dienste eingesetzten Unterauftragsverarbeiter zu erhalten.
Die folgenden Mindest-Sicherheitskonfigurationen für Zendesk-Dienste sollten eingerichtet werden und sind in der Gesundheitsvereinbarung für alle aktivierten Konten aufgeführt
I Zendesk Support:
-
Sichere Agentenauthentifizierung mit einer der beiden folgenden Methoden:
- Verwenden von Zendesk Support mit Kennworteinstellungen: (i) auf „Empfohlen“; oder (ii) vom Abonnenten auf eine Weise angepasst werden, die Anforderungen festlegt, die nicht weniger sicher sind als die in der Einstellung „Empfohlen“. Darüber hinaus muss der Abonnent unter der Option in diesem Unterabschnitt die Zwei-Faktor-Authentifizierung („2FA“) nativ im Dienst aktivieren und durchsetzen. und dass administrative Kontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, deaktiviert werden; oder
- Verwenden einer externen Single-Sign-On (SSO)-Lösung mit festgelegten Anforderungen, die nicht weniger sicher sind als die unter der „empfohlenen“ Kennworteinstellung von Zendesk festgelegten Anforderungen, und Aktivieren und Durchsetzen der Zwei-Faktor-Authentifizierung in der ausgewählten Lösung für den Zugriff aller Agenten. Die administrativen Kontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, müssen deaktiviert sein.
- Bei allen Authentifizierungsoptionen mit SSO als Authentifizierungsmethode sollte der Kennwortzugriff deaktiviert werden.
- Die SSL-Verschlüsselung (Secure Socket Layer) muss bei Konten, bei denen das Gesundheitswesen aktiviert ist, immer aktiviert bleiben. Konten, die eine andere Domäne als Zendesk.com verwenden, müssen gehostetes SSL einrichten und pflegen.
- Der Agentenzugriff sollte nach Möglichkeit auf bestimmte IP-Adressen beschränkt werden, die unter der Kontrolle des Abonnenten stehen es sei denn, der Abonnent aktiviert die Multi-Faktor-Authentifizierung für Agenten wie oben in den Anforderungen 1.a oder 1.b beschrieben (entweder nativ im Dienst oder in der Abonnentenumgebung in Verbindung mit Enterprise-SSO). Zur Klarstellung: „Agentenzugriff“ bezieht sich auf den Zugriff, der einem menschlichen Agenten gewährt wird, der über die Benutzerschnittstelle („UI“) auf Dienstdaten zugreift.
-
In dem Umfang, in dem das für das Gesundheitswesen aktivierte Konto des Abonnenten Aufrufe an Zendesk-Anwendungsprogrammierschnittstellen (APIs) ermöglicht, übernimmt der Abonnent die volle Verantwortung für das Verständnis der Sicherheitsauswirkungen aller Abonnenten oder Dritten, die Daten erstellen, aufrufen, ändern oder löschen dürfen Servicedaten und personenbezogene Gesundheitsinformationen über diesen Zugriff und/oder Integrationen. Für den Zugriff auf die genannten APIs bietet Zendesk verschiedene Methoden an, die hier beschrieben werden. Der Abonnent ist verpflichtet, die folgenden bewährten Sicherheitspraktiken basierend auf dem verwendeten API-Modell zu implementieren:
- OAuth 2.0-Ansatz verwenden. Dieses Modell bietet die granularsten Sicherheitsfunktionen, setzt aber voraus, dass die Zugriffsberechtigungen von einem Endbenutzer akzeptiert werden. Der Abonnent sollte nach Möglichkeit den Ansatz und das Authentifizierungsschema von OAuth 2.0verwenden. Der Abonnent sollte jedem OAuth Client einen aussagekräftigen und eindeutigen Clientnamen sowie eine eindeutige Kennung geben. Die für jedes OAuth -Token gewährten Berechtigungen sollten die geringsten Berechtigungen zulassen, die zur Erfüllung der erforderlichen Aufgaben erforderlich sind.
- REST-API-Token-Ansatz verwendet. Dieses Modell ist am breitesten und ermöglicht es einem API-Token, die volle Funktionalität des API-Modells zu nutzen. Sie bietet den umfassendsten Zugriff und die umfassendsten Funktionen und sollte mit Bedacht eingesetzt werden. Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Dienst ein eindeutiges Token mit einer aussagekräftigen Funktion verwenden; (ii) API-Token nicht an Dritte weitergeben, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) anerkennen, dass das zugehörige Token sofort rotiert werden muss, wenn das API-Token an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) das Token mindestens häufig in Übereinstimmung mit den Organisationsrichtlinien des Abonnentenrotieren.
- Wenn möglich, sollte der Abonnent den Kennwortzugriff auf die API deaktivieren, da Benutzer bei jeder Anfrage Anmeldedaten erhalten, die allgemein sichtbar sind und somit leichter von bösartigen Parteien abgefangen werden können.
- Damit der Zugriff auf Anhänge authentifiziert werden kann, sollte der Abonnent die Option „Authentifizierung erforderlich, um Anhänge herunterzuladen“ aktivieren. Andernfalls kann jeder, der Zugriff auf die richtige URL des Anhangs hat, auf den uneingeschränkten Anhang zugreifen. In solchen Fällen übernimmt der Abonnent die gesamte Verantwortung für den Inhalt und Zugriff auf solche Anhangsdaten.
- Abonnenten sollten auf allen Endpunkten, auf die Agenten, Administratoren und Kontoinhaber zugreifen, systematisch einen kennwortgeschützten Bildschirmschoner oder Startbildschirm einrichten, der nach maximal fünfzehn (15) Minuten Inaktivität aktiviert wird.
- Der Abonnent sollte die Anzeigeberechtigungen, die es einem Benutzer ermöglichen, Aktualisierungen für eine gesamte Instanz/Marke/Organisation anzuzeigen, oder die Standardeinstellung, die einen Zugriff über die eigenen Tickets oder Gruppen des Benutzers hinaus ermöglicht, nicht ändern (es sei denn, der Abonnent übernimmt die gesamte Verantwortung dafür, sicherzustellen, dass diese Benutzer vom Abonnenten genehmigt werden auf alle nachfolgenden Daten zugreifen). Der Abonnent erkennt an, dass die Berechtigungen für Endbenutzerorganisationen im Benutzerprofil und in der Organisation selbst festgelegt werden können und dass die freizügigere Einstellung hat Vorrang vor der weniger freizügigen Einstellung.
- Der Abonnent erkennt an, dass Zendesk nicht dafür verantwortlich ist, E-Mail-Übertragungen von Endbenutzern und zugehörige Dienstdaten vor dem Eingang in seiner Zendesk Support Instanz zu schützen. Hierzu gehören alle personenbezogenen Gesundheitsinformationen, die per E-Mail über Antworten auf Zendesk Support -Tickets weitergegeben werden, einschließlich Ticketkommentare oder Anhänge.
- Der Abonnent erkennt an, dass Zendesk Support unter verschiedenen Umständen eine E-Mail an einen Endbenutzer sendet, z. B. wenn ein Agent des Abonnenten über den E-Mail-Kanal auf ein Zendesk Support -Ticket antwortet oder dies durch eine Automatisierung oder einen Auslöser ausgelöst wird. Standardmäßig enthält diese E-Mail die neuesten Tickets oder andere Informationen, die für eine automatische Benachrichtigung konfiguriert sind, darunter auch personenbezogene Informationen. Um den Abonnenten noch besser zu schützen, sollte seine Zendesk Support Instanz sein die so konfiguriert sind, dass der Endbenutzer nur benachrichtigt wird, dass ein Agent geantwortet hat, und dass der Endbenutzer sich bei Zendesk Support authentifizieren muss, um den Inhalt der Nachricht zu sehen.
-
Der Abonnent erkennt an, dass alle nach eigenem Ermessen in einem beliebigen Zendesk-Dienst eingesetzten SMS-Funktionen auf SMS und/oder verwandten Protokollen basieren, die die unverschlüsselte Übertragung von Nachrichten zwischen und in die jeweiligen Dienste ermöglichen. SMS-Funktionen sollten daher entweder:
- nicht in einem aktivierten Gesundheitsfürsorge-Konto* verwendet werden, oder
- der Abonnent übernimmt die gesamte Verantwortung für die Nutzung dieser Funktionen
- Der Abonnent erkennt an, dass bei Nutzung der Legacy-Funktionalität Umfragen zur Kundenzufriedenheit („Legacy CSAT“) mit dem Support -Ticket verknüpfte Servicedaten (möglicherweise mit PHI) per E-Mail gesendet werden, um die Bewertung des Benutzers zu erhalten, deren Verschlüsselungsstatus nicht kontrolliert wird von Zendesk entwickelt wurde. Daher sollte die Legacy- CSAT Funktion entweder:
- nicht in einem aktivierten Gesundheitsfürsorge-Konto* verwendet werden, oder
- der Abonnent übernimmt die gesamte Verantwortung für die Nutzung dieser Funktionen
-
Der Abonnent erkennt an, dass er die Kundenzufriedenheitsumfragen („CSAT“) des Dienstesgenutzt hat für den Ticketkanal konfiguriert ist, Servicedaten (die PHI enthalten können), die mit dem Support -Ticket verknüpft sind, per E-Mail sendet, um die Bewertung des Benutzers zu erhalten. Deren Verschlüsselungsstatus wird nicht von Zendesk gesteuert. Darüber hinaus hat jeder mit der entsprechenden CSAT URL Zugriff auf die Antworten auf das jeweilige Ticket. Daher sollten Sie die CSAT Funktionalität für den Ticketkanal verwenden
- Konfigurieren Sie den E-Mail-Text der CSAT Automatisierung so, dass potenzielle PHI-Informationen nicht enthalten sind, und verwenden Sie die {{satisfaction.survey_url}} exklusiv für den -Platzhalter
- Verwenden Sie nicht die Funktion „Offene Fragen“.
* Zur Klarstellung: Die in Abschnitt 10 zu SMS genannten Einschränkungen für personenbezogene Daten gelten nicht für die produktintegrierte Nutzung der 2FA (siehe Abschnitt 1.a), da diese Funktion lediglich eine numerische Zeichenfolge zur Identitätsprüfung sendet.
II. Zendesk Guide und Gather:
- Der Abonnent erkennt an, dass die Guide- und Gather-Dienste öffentlich sind (sofern keine beschränkten Beiträge genutzt oder eine geschlossene oder beschränkte Instanzverwendet werden) und der Abonnent daher sicherstellen sollte, dass Beiträge in Zendesk Guide oder Gather keine personenbezogenen Gesundheitsinformationen enthalten, auch nicht im Text von im Beitrag, als Anhang oder als Bild im Beitrag erscheinen.
- Der Abonnent sollte entweder die Möglichkeit für Endbenutzer deaktivieren, Kommentare in Zendesk Guide hinzuzufügen, oder die persönlichen Gesundheitsinformationen aus allen Kommentaren entfernen (wie in Abschnitt 3 unten beschrieben).
- Wenn der Zendesk Guide Dienst Guide Professional oder Enterprise ist, sollten Abonnenten die Möglichkeit, neue Posts zu erstellen, deaktivieren, indem sie die Gather-Funktionen mit Zendesk Guide deaktivieren bzw. Gather-Funktionen deaktivieren, weil die Absicht des Abonnenten besteht Anwendungsfall sollten Abonnenten die Inhaltsmoderation im Zendesk Guide Dienst aktivieren und die Einstellung „Alle Inhalte moderieren“ wählen. Es sollten keine Eingaben genehmigt werden, die PHI enthalten.
- Die Nutzung von Community-Moderatoren, die keine Mitarbeiter sind, sollte im Gather-Dienst nicht zulässig sein, es sei denn, der Abonnent übernimmt die Verantwortung für den potenziellen Zugriff dieser Benutzer auf Daten, einschließlich möglicher PHI-Daten (falls zutreffend).
- Der Abonnent erkennt an, dass „@Erwähnungen" von Gather-Community-Mitgliedern möglich sind, sofern Endbenutzern öffentliche Profile zugewiesen sind. Sollte diese Funktion in ihrem Anwendungsfall als Risiko eingestuft werden, sollten öffentliche Profile deaktiviert oder @Erwähnungen deaktiviert werden.
III. Zendesk Messaging:
- Der Abonnent sollte Social-Media-Messaging-Kanalintegrationen nur dann aktivieren, wenn er die volle Verantwortung dafür übernimmt, entweder (i) sicherzustellen, dass keine personenbezogenen Gesundheitsinformationen in Social-Media-Nachrichten enthalten sind, oder (ii) eine eigene BAA mit integrierten Messaging-Plattformen abzuschließen.
- Der Abonnent sollte die Fähigkeit von Endbenutzern deaktivieren, Dateien an Messaging-Konversationen anzuhängen, und muss die volle Verantwortung dafür übernehmen, entweder (i) sichere Anhänge zu aktivieren oder (ii) die Sicherstellung, dass Agenten keine Dateien mit ePHI an Messaging-Konversationen anhängen. Andernfalls kann jeder, der Zugriff auf die richtige URL des Anhangs hat, auf den uneingeschränkten Anhang zugreifen. In solchen Fällen übernimmt der Abonnent die gesamte Verantwortung für den Inhalt und den Zugriff auf solche URLs und/oder Anhangsdaten.
- Der Abonnent trägt die gesamte Verantwortung dafür, dass alle Agenten und Light Agents alle eingehenden Nachrichten von allen Endbenutzern sehen können.
- Wenn der Abonnent oder seine Agenten auf Integrationen für APIs und Webhooks zugreifen oder diese entwickeln (z. B. als Teil eines für KI Agenten erstellten Workflows) oder das Messaging-Erlebnis anpassen, übernimmt der Abonnent die volle Verantwortung, die Datenschutz- und Sicherheitsauswirkungen aller angepassten Workflows zu verstehen Abonnenten oder Drittanbieter (einschließlich Chatbot-Anbieter), die über diesen Zugriff und/oder diese Integrationen Servicedaten und ePHI erstellen, aufrufen, ändern oder löschen dürfen.
- Wenn der Abonnent einem Agenten die Berechtigung zur Teilnahme an einer Messaging-Konversation entziehen möchte, während die Messaging-Konversation aktiv ist, übernimmt er die gesamte Verantwortung für die Kündigung des Zugriffs des Agenten auf Zendesk.
- Standardmäßig werden Web-Widget-Konversationen mit Endbenutzern dauerhaft vorgenommen und können von Endbenutzern angezeigt werden, wenn sie vom selben Gerät zum Web-Chat zurückkehren. Der Abonnent ist verpflichtet, diese Funktion entweder zu deaktivieren oder dafür zu sorgen, dass Endbenutzer keine Geräte teilen.
-
Wenn der Abonnent eine Authentifizierung für Endbenutzer implementieren möchte, trägt er die gesamte Verantwortung dafür, dass dies auf sichere Weise im Einklang mit Best Practices und Industriestandards implementiert wird.
- Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Authentifizierungskanal einen eindeutigen JWT-Signaturschlüssel verwenden und dem Token eine aussagekräftige Namensfunktion geben; (ii) Sie geben JWT-Signaturschlüssel nicht an Dritte weiter, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) anerkennen, dass der Abonnent den zugehörigen JWT-Signaturschlüssel unverzüglich wechseln muss, wenn der JWT-Signaturschlüssel an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) der JWT-Signaturschlüssel zumindest häufig in Übereinstimmung mit den Organisationsrichtlinien des Abonnenten rotiert wird.
- Der Abonnent sollte das JWT-Ablaufattribut verwenden und seinen Wert auf maximal 15 Minuten setzen.
- Der Abonnent erkennt an, dass Interaktionen zwischen Endbenutzern und KI -Agenten, die nicht von einem menschlichen Agenten übergeben und in ein Ticket umgewandelt werden, weiterhin im System gespeichert sind und es in der Verantwortung des Abonnenten liegen, diese Interaktionen entsprechend seinen Verpflichtungen zu löschen (z. B. durch Implementierung einer einen Webhook, der den Abonnenten benachrichtigt, wenn diese Konversationen gespeichert werden, und über die Sunshine Conversations API (automatisch) das Löschen auslöst).
- Der Abonnent erkennt an, dass die Konversationen zwischen Endbenutzern und KI Agenten umgewandeltwurden in ein Ticket umgewandelt wurde, kann derzeit nicht geschwärzt werden. Zum Löschen wird das Ticket gelöscht.
- Der Abonnent erkennt an, dass Endbenutzeranhänge in Messaging-Kanälen in Zendesk derzeit nicht auf Malware gescannt werden. Der Abonnent trägt die volle Verantwortung für die Einrichtung von Verfahren und Richtlinien zur Risikominderung für seine Vermögenswerte.
- Der Abonnent erkennt an, dass bei Nutzung der Funktionalität „Nebenkonversationen“ untergeordnete Ticket- und/oder Nebenkonversationsnachrichten in der Support -Instanz des Abonnenten erstellt oder von dort aus per Ticket, E-Mail, Slack oder Integrationen (nach Ermessen des Agenten) an Empfänger gesendet werden können (je nach Ermessen des Agenten). . Wenn der Abonnent diese Funktionalität in einem für das Gesundheitswesen aktivierten Konto nutzt, übernimmt er die alleinige Verantwortung (i) dafür, dass in diesen Nachrichten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (ii) falls in diesen Nachrichten personenbezogene Gesundheitsinformationen enthalten sein könnten für jegliche Haftung, Kosten, Schäden oder Schäden im Zusammenhang mit dem unbefugten Erwerb, Zugriff, Verwendung oder Offenlegung von PHI infolge des Nachrichtenaustauschs über die Funktion „Nebenkonversation“.
IV. Zendesk Sunshine Conversations:
- Der Abonnent sollte die Integration von Drittanbieter-Kanälen nur dann aktivieren, wenn er die volle Verantwortung dafür übernimmt, dass entweder (i) keine personenbezogenen Gesundheitsinformationen in den Nachrichten von Drittanbieter-Kanälen enthalten sind oder (ii) eine eigene BAA mit integrierten Messaging-Plattformen abgeschlossen wird.
-
Der Abonnent übernimmt die gesamte Verantwortung für das Verständnis der Sicherheitsauswirkungen aller Abonnenten oder Dritten, die über die Sunshine Conversations APIs Dienstdaten und personenbezogene Gesundheitsinformationen erstellen, abrufen, modifizieren oder löschen dürfen. Für den Zugriff auf die genannten APIs muss der Abonnent die folgenden bewährten Sicherheitspraktiken auf Grundlage des verwendeten API-Modells implementieren:
- OAuth 2.0-Ansatz verwenden. Dieses Modell bietet die granularsten Sicherheitsfunktionen, setzt aber voraus, dass die Zugriffsberechtigungen von einem Endbenutzer akzeptiert werden. Wo möglich sollte der Abonnent dies tun Der OAuth 2.0-Ansatz und das Authentifizierungsschema. Der Abonnent sollte jedem OAuth Client einen aussagekräftigen und eindeutigen Clientnamen sowie eine eindeutige Kennung geben.
- REST-API-Token-Ansatz verwendet. Dieses Modell ist am breitesten und ermöglicht es einem API-Token, die volle Funktionalität des API-Modells zu nutzen. Sie bietet den umfassendsten Zugriff und die umfassendsten Funktionen und sollte mit Bedacht eingesetzt werden. Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Dienst ein eindeutiges Token mit einer aussagekräftigen Funktion verwenden; (ii) API-Token nicht an Dritte weitergeben, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) anerkennen, dass das zugehörige Token sofort rotiert werden muss, wenn das API-Token an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) das Token gemäß der Organisationsrichtlinie des Abonnenten häufig rotiert.
- Wenn der Abonnent oder seine Agenten auf Integrationen für APIs und Webhooks zugreifen oder diese entwickeln oder das Sunshine Conversations Erlebnis anpassen, übernimmt der Abonnent die volle Verantwortung, die Datenschutz- und Sicherheitsauswirkungen aller angepassten Workflows und aller zulässigen Abonnenten oder Drittanbieter (einschließlich Chatbot-Anbieter) zu verstehen über solche Zugriffe und/oder Integrationen Servicedaten und personenbezogene Gesundheitsinformationen zu erstellen, aufzurufen, zu modifizieren oder zu löschen.
- Der Abonnent erkennt an, dass die für Zendesk Support konfigurierten IP-Beschränkungen nicht auch für die Sunshine Conversations -API gelten. Die Abonnenten tragen die volle Verantwortung für die Beschränkung des Zugriffs auf die Sunshine Conversations -API und die API-Token wie unter 2.b beschrieben. und im Einklang mit den Richtlinien des Abonnenten steht.
- Der Abonnent sollte die Möglichkeit für Endbenutzer deaktivieren, Dateien an Sunshine Conversations Konversationen anzuhängen, und selbst die volle Verantwortung für die Aktivierung sicherer Anhängeübernehmen und auch sicherzustellen, dass Agenten keine Dateien mit PHI-Dateien an Messaging-Konversationen anhängen. Andernfalls kann jeder, der Zugriff auf die richtige URL des Anhangs hat, auf den uneingeschränkten Anhang zugreifen. In solchen Fällen übernimmt der Abonnent die gesamte Verantwortung für den Inhalt und Zugriff auf solche Anhangsdaten.
-
Wenn der Abonnent Authentifizierung für Endbenutzer implementieren möchte, übernimmt er die gesamte Verantwortung dafür, dass dies entsprechend den Best Practices zur Sicherheit und den Industriestandards erfolgt.
- Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Authentifizierungskanal einen eindeutigen JWT-Signaturschlüssel verwenden und dem Token eine aussagekräftige Namensfunktion geben; (ii) Sie geben JWT-Signaturschlüssel nicht an Dritte weiter, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) anerkennen, dass der Abonnent den zugehörigen JWT-Signaturschlüssel unverzüglich wechseln muss, wenn der JWT-Signaturschlüssel an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) der JWT-Signaturschlüssel zumindest häufig in Übereinstimmung mit den Organisationsrichtlinien des Abonnenten rotiert wird.
- Der Abonnent sollte das JWT-Ablaufattribut verwenden und seinen Wert auf maximal 15 Minuten setzen.
- Der Abonnent erkennt an, dass Interaktionen zwischen Endbenutzern und KI -Agenten, die nicht von einem menschlichen Agenten übergeben und in ein Ticket umgewandelt werden, weiterhin im System gespeichert sind und dass es in der Verantwortung des Abonnenten liegt, diese Interaktionen entsprechend seinen Verpflichtungen zu löschen, z. B. durch Implementieren eines Webhooks die den Abonnenten benachrichtigt, wenn diese Konversationen gespeichert werden, und (automatisch) die Löschung über die Sunshine Conversations -API auslöst
- Der Abonnent erkennt an, dass Konversationen zwischen Endbenutzern und KI -Agenten, die in Tickets umgewandelt wurden, derzeit nicht geschwärzt werden können. Zum Löschen wird das Ticket gelöscht.
- Der Abonnent erkennt an, dass über die Sunshine Conversations API gelöschte Nachrichten nur für Endbenutzer, nicht aber im Zendesk- Arbeitsbereich für Agenten gelöscht werden. Sie können hierzu das Ticket selbst löschen oder die Funktion „Schwärzung“ verwenden (Einschränkungen: siehe Abschnitt 7.).
- Der Abonnent erkennt an, dass derzeit nicht alle Anhänge in Sunshine Conversation-Kanälen in Zendesk auf Malware gescannt werden. Der Abonnent übernimmt die volle Verantwortung für die Einrichtung von Verfahren und Richtlinien zur Risikominderung für seine Mitarbeiter.
V. Zendesk Chat:
- Der Abonnement sollte den Zugriff von Agenten auf den Zendesk Chat -Dienst beschränken, indem er sich an den Zendesk Support -Dienst anmeldet und sich über diesen authentifiziert.
- Abonnenten sollten keine Chatprotokolle per E-Mail senden, indem sie (a) das E-Mail-Piping deaktivieren, (b) die Option Chatprotokoll per E-Mail senden im Classic Web Widget deaktivieren und (c) keine Exporte per E-Mail vom Chat-Dashboardaus teilen
- Der Abonnent übernimmt die volle Verantwortung dafür, dass (i) in Chats keine personenbezogenen Gesundheitsinformationen vorhanden sind und/oder (ii) alle Agenten diese Daten einsehen können.
VI. Zendesk Explore Dienst:
Der Abonnent erkennt an, dass personenbezogene Gesundheitsinformationen über Benutzernamen, Tickettitel, Feld- und Formularoptionen und Inhalte von Freitextfeldern in Explore angezeigt werden können.
- Bei jeder Serviceinstanz, die personenbezogene Gesundheitsinformationen enthält, sollte der Abonnent (i) nur solchen Agenten Zugriff auf die Explore-Oberfläche gewähren, die auf alle Tickets/Anrufe/Chats zugreifen können, die in der übergeordneten Instanz des Dienstes PHI enthalten können, und (ii) einen solchen Zugriff unter Berücksichtigung der geringsten Berechtigungen gewähren, die für die Nutzung von Explore in ihrer Umgebung erforderlich sind. Weitere Informationen zum Konfigurieren von Zugriffsebenen in Explore finden Sie hier.
- Bei Nutzung der Exportfunktion (i) erkennt der Abonnent an, dass personenbezogene Gesundheitsinformationen an ein Gerät übertragen werden können, dem der Abonnent Zugriff auf die Benutzeroberfläche des Agenten gewährt hat und dass alle damit verbundenen Steuerungen auf diesem Gerät in der Verantwortung des Abonnenten liegen, und dass (ii) der Abonnent die Verwendung verweigern sollte Exportfunktionen per E-Mail für die exportierten Berichte nutzen, es sei denn, sie sind dafür verantwortlich, entweder (a) sicherzustellen, dass in diesen Exporten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (b) dass die für solche Übertragungen verwendeten E-Mail-Dienste die Verschlüsselung über das zulässige Mindestprotokoll unterstützen der bis dato aktuellen PCI-Standards entspricht.
* Besondere Überlegungen bei Verwendung von Explore Enterprise:
Der Abonnent erkennt an, dass bei Nutzung des Explore Enterprise-Dienstes möglicherweise mehr Funktionen für die gemeinsame Nutzung von Daten und zum Export bereitgestellt werden können. Der Abonnent muss:
- entweder (i) sicherstellen, dass in diesen Dashboards keine personenbezogenen Gesundheitsinformationen vorhanden sind, und/oder (ii) Dashboards nur mit Agenten, Gruppen, Listen oder Endbenutzern teilen, die zum Anzeigen und Empfangen dieser Daten berechtigt sind.
- IP-Beschränkungen nutzen
- beim Teilen von Dashboards über einen einheitlichen Ressourcen-Locator (URL) anerkennt der Abonnent, dass die Daten nicht mit einzelnen Benutzer- oder Gruppenbenutzerkonten geteilt werden, sondern über einen Zugriffslink. Der Abonnent sollte daher (i) den Kennwortschutz aktivieren, (ii) sicherstellen, dass die Komplexität der Kommunikation, die Rotation, die Speicherung und die Verteilung der gewählten Kennwörter an die empfangende Partei im Einklang mit den Kennwortrichtlinien des Abonnenten zum Schutz der in solchen Dashboards enthaltenen Daten erfolgt und (c) die Absenderadresse rotiert und zwar ohne unangemessene Verzögerung bei Verdacht oder Bestätigung der Offenlegung
VII. Produktintegrierte Funktionen für bereitgestellte verknüpfte Dienste („Add-ons“):
- Collaboration Deployed Associated Service: „Nebenkonversationen“. Der Abonnent erkennt an, dass bei Nutzung der Funktionalität „Nebenkonversationen“ untergeordnete Ticket- und/oder Nebenkonversationsnachrichten in der Support -Instanz des Abonnenten erstellt oder von dort aus per Ticket, E-Mail, Slack oder Integrationen (nach Ermessen des Agenten) an Empfänger gesendet werden können (je nach Ermessen des Agenten). . Wenn der Abonnent diese Funktionalität in einem für das Gesundheitswesen aktivierten Konto nutzt, übernimmt er die alleinige Verantwortung (i) dafür, dass in diesen Nachrichten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (ii) falls in diesen Nachrichten personenbezogene Gesundheitsinformationen enthalten sein könnten für jegliche Haftung, Kosten, Schäden oder Schäden im Zusammenhang mit dem unbefugten Erwerb, Zugriff, Verwendung oder Offenlegung von PHI infolge des Nachrichtenaustauschs über die Funktion „Nebenkonversation“.
VIII. Mobile Zendesk-Anwendungen (oder Zugriff per Mobilgerät wie Smartphone oder Tablet):
- Die Nutzung umfasst die Verschlüsselung auf Geräteebene
- Bimetrische oder PIN-Zugriffe auf die höchste zulässige Geräteeinstellung sollten genutzt werden
- Benachrichtigungen, die es ermöglichen, dass Ticketkommentare auf den Sperrbildschirmen solcher Geräte angezeigt werden, sollten deaktiviert werden
- Die Bildschirminaktivitätssperre sollte aktiviert und so konfiguriert sein, dass sie bei Inaktivität von maximal 15 Minuten sperrt.
- Der Abonnent erkennt an, dass die Schwärzungsfunktion in der mobilen Support -App nicht verfügbar ist und dass sich Agenten über den Browser anmelden müssen, um die Schwärzungsfunktion zu nutzen.
- Wenn der Abonnent die Authentifizierung von Endbenutzern für Zendesk Messaging wählt, erkennt er an, dass der Authentifizierungsstatus eines Endbenutzers in der mobilen Support -App nicht angezeigt wird.
IX. Zendesk Insights: Die Unterstützung für diesen Dienst wurde zum 5. Februar 2021 eingestellt.
X. Hinweis zur KI Funktionalität von Zendesk („Zendesk KI“, „Fortschrittliche KI“, „Generative KI“ usw.):
- Der Abonnent erkennt an, dass die KI Funktionen von Zendesk zur Steigerung der Produktivität des bzw. der Zendesk-Dienste(s) bestimmt sind und nicht auf eine Weise verwendet werden sollten, die als (i) Bereitstellung von medizinischem Rat, (ii) Bereitstellung einer Diagnose des Zustands oder der Symptome zu entwickeln, (ii) eine Behandlung zu verschreiben oder (iv) den Nutzer in irgendeiner Weise daran zu hindern, einen Rat, eine Diagnose oder eine Behandlung eines Gesundheitsexperten in Anspruch zu nehmen, (v) einem Nutzer anderweitig Informationen bereitzustellen oder Entscheidungen zu treffen, um ihn einzuschränken oder auszuschließen Gesundheitspläne, Behandlungsprogramme, Testdienste oder andere Gesundheitsleistungen, die sich auf die Inanspruchnahme oder Inanspruchnahme von Gesundheitsdiensten auswirken könnten (es sei denn, der Abonnent übernimmt die volle Verantwortung für diese Entscheidung basierend auf seinem konkreten Anwendungsfall und seinen Interaktionen mit seinen Benutzern). sowie die potenziellen Auswirkungen eines solchen Einsatzes von KI .)
- Der Abonnent erkennt an, dass bei Verwendung generativer KI Funktionen die KI Ausgaben nicht von Menschen sondern von Computern generiert werden und daher zu ungenauen Ergebnissen führen können. Zendesk übernimmt keine Garantie für die Genauigkeit dieser Ergebnisse.
- Der Abonnent erkennt an, dass die Funktion „Variationen generieren“ nicht aktiviert werden darf, wenn ein Gruß eines KI -Agenten Konversations-Bot verwendet wird, um den Endbenutzern des Abonnenten einen erforderlichen Haftungsausschluss zu übermitteln.
- Der Abonnent erkennt an, dass durch Aktivierung der Funktion „Erweitertes Schreiben“ im Admin Center diese Funktion für alle Agenten in ihrer Instanz unabhängig von ihren Rollen und Berechtigungen aktiviert wird.
XI. Zendesk QA
- Der Abonnent erkennt an, dass die Zendesk QA KI Funktionen zur Steigerung der Produktivität der Zendesk-Dienste dienen und nicht in einer Weise verwendet werden sollten, die als (i) Bereitstellung von medizinischem Rat oder (ii) Bereitstellung einer Zustandsdiagnose verstanden werden könnte oder Symptome zu entwickeln, (ii) eine Behandlung zu verschreiben oder (iv) den Nutzer in irgendeiner Weise daran zu hindern, einen Rat, eine Diagnose oder eine Behandlung eines Gesundheitsexperten in Anspruch zu nehmen, (v) einem Benutzer anderweitig Informationen bereitzustellen oder Entscheidungen zu treffen, um ihn aufzunehmen oder auszuschließen eines Gesundheitsplans, eines Behandlungsprogramms, eines Testdienstes oder eines anderen Gesundheitsdienstes, die sich auf seine Suche nach oder Inanspruchnahme von Gesundheitsdiensten auswirken könnten (es sei denn, der Abonnent übernimmt die volle Verantwortung für diese Entscheidung basierend auf seinem konkreten Anwendungsfall und seinen Interaktionen mit seinen Benutzern, wie z. B sowie die potenziellen Auswirkungen eines solchen Einsatzes von KI .)
- Der Abonnent nimmt zur Kenntnis, dass Lösch- oder Schwärzungen in seiner Zendesk-Instanz nicht sofort mit der Zendesk QA synchronisiert, sondern in den folgenden 3-6 Stunden übernommen werden.
- Bei Verwendung der Umfragefunktion sollte der Abonnent (i) die KI Unterstützungsfunktion von Zendesk QA deaktivieren (oder sicherstellen, dass alle Agenten, die QA Arbeiten durchführen, freigegeben sind, um potenzielle Daten in dieser Transaktion zu sehen, und dass die Grundsätze von Punkt 1 befolgt werden). ii) die Umfrage so konfigurieren, dass in den Fragen oder Beschreibungen der Umfrage keine personenbezogenen Gesundheitsinformationen enthalten sind (oder in E-Mails, die über Gelegenheits-StartTLS versendet werden, die Verantwortung für diese Daten übernehmen);
- Bei Verwendung der angepassten Integration „Zendesk Chat“ sollte der Abonnent einen in seinen Richtlinien festgelegten Datenaufbewahrungszeitraum festlegen, um sicherzustellen, dass seine Daten nicht unbegrenzt lang gespeichert werden.
- Der Abonnent erkennt an, dass ein Löschen von Teilen einer Zendesk Messaging-Konversation mit der Sunshine Conversations -API nicht in die Zendesk QA übernommen wird. Stattdessen sollten die Informationen durch Schwärzung aus dem ursprünglichen Ticket entfernt oder die gesamte Konversation entfernt werden.
- Der Abonnent erkennt an, dass Zendesk QA die Zendesk-Funktion „Private Anhänge“ gegenwärtig nicht unterstützt. Das bedeutet, dass Anhänge von jedem zugegriffen werden können, der Zugriff auf die korrekte URL für den Anhang hat, und dass sie nicht mit sensiblen Daten, einschließlich PHI, verwendet werden sollten. Der Abonnent übernimmt die gesamte Verantwortung für den Inhalt und Zugriff auf derartige URLs und/oder Anhangsdaten.
- Der Abonnent erkennt an, dass eine erweiterte Verbindungskonfiguration im Rahmen der erstmaligen Bereitstellung der Zendesk QA erst nach der ersten Synchronisierung möglich ist.
XII. Zendesk Workforce Management "WFM":
- Der Abonnent erkennt dies an
- Die Standardrolle „WFM -Administrator“ hat Zugriff auf alle Agentenaktivitäten und Einstellungen in Bezug auf den WFM Dienst (einschließlich der unter Punkt 2 genannten Stichwörter).
- Die Standardrolle „Agent“ hat Zugriff auf die Aktivitäten des Agenten, es sei denn, die Administratoren haben durch Erstellung angepasster Rollen (siehe hier) einen anderen Zugriff konfiguriert
- Der Abonnent erkennt an, dass Stichwörter, die von Agenten, Administratoren oder vordefinierter Systemlogik in Support -Tickets angewendet werden, im WFM Produkt für alle Benutzer sichtbar sind, die zur Anzeige der betreffenden Ticketaktivität berechtigt sind. Wenn Stichwörter vom Abonnenten als sensibel eingestuft werden, sollte der Zugriff entsprechend konfiguriert werden.
Hinweis: Aufgrund gesetzlicher oder regulatorischer Änderungen oder Änderungen des Zendesk-Service können sich die Sicherheitskonfigurationen in diesem Dokument von Zeit zu Zeit ändern. Dieses Dokument enthält die Empfehlungen von Zendesk für die minimalen Sicherheitskonfigurationen zum Schutz personenbezogener Gesundheitsinformationen in den oben genannten Zendesk-Produkten. Dieses Dokument ist weder als umfassende Vorlage für die Kontrolle dieser Daten noch als Rechtsberatung gedacht. Jeder Zendesk-Abonnent sollte bezüglich der HIPAA oder HDS-Compliance-Anforderungen einen eigenen Rechtsberater hinzuziehen und die zusätzlichen Änderungen an den Sicherheitskonfigurationen im Einklang mit der eigenen unabhängigen Analyse vornehmen, solange diese Änderungen die Sicherheit von nicht beeinträchtigen oder beeinträchtigen die in diesem Dokument beschriebenen Konfigurationen konfiguriert werden.
Änderungsprotokoll:
24. Januar 2025
- Konsolidierte HIPAA und HDS-Konfigurationen
27. Dezember 2024
- Abschnitt XII hinzugefügt, um Zendesk Workforce Management (WFM) in den Anwendungsbereich aufzunehmen
16. Dezember 2024
- Abschnitt xi hinzugefügt, um die Zendesk QA in den Anwendungsbereich aufzunehmen
- Verschiedene Instanzen von „Answer Bot“ in „KI -Agenten“ geändert, um Änderungen der Namenskonvention und einen erweiterten Anwendungsbereich zu kennzeichnen.
10. Oktober 2024
- Abschnitt I, Support, Nummer 12 (CSAT) und Abschnitt I, Support, Nummer 11 (Legacy- CSAT) bearbeitet, um neue Funktionen zu berücksichtigen.
7. März 2024
- Abschnitt X, „Hinweis zur KI Funktionalität“ von Zendesk, wurde hinzugefügt
-
Abschnitt I, Support, Nummer 7 (Anzeigeberechtigungen):
- Klarstellung, dass sich „Anzeigeberechtigungen“ auf die gesamte Instanz/Marke/Organisation und nicht nur auf die gesamte Organisation beziehen.
- Neue Bestimmung für das Verhalten Endbenutzer-spezifischer Organisationen hinzugefügt.
-
Abschnitt I, Support, Nummer 9 (E-Mail):
- Die Fälle, in denen Zendesk Support eine E-Mail an einen Endbenutzer sendet, haben jetzt auch Antworten über den E-Mail-Kanal oder solche, die durch eine Automatisierung oder einen Auslöser ausgelöst werden, anstatt nur einen Agenten, der auf ein Ticket antwortet.
- Sie haben festgelegt, dass automatische Benachrichtigungen standardmäßig die jüngste Ticketkorrespondenz oder andere konfigurierte Informationen enthalten können, darunter auch personenbezogene Informationen.
25. Oktober 2023
- Einführung: Verfeinerung des Einführungstexts für HIPAA fähige Konten
- Abschnitt II, Guide und Gather, Nummer 1 (Help-Center-Beschränkungen): Wir haben die IP-Beschränkungen durch beschränkte Beiträge ersetzt
13. April 2023
-
Abschnitt I, Support, Nummer 4 (APIs):
- Zur besseren Übersicht wurde ein Link zu den Authentifizierungsmethoden hinzugefügt
- b) Empfehlungen für den genauen Zeitrahmen für die Rotation zur Anpassung an branchenspezifische Best Practices entfernt und Verweis auf allgemeine Geschäftsbedingungen für die REST-API (Redundanz)
- c) hinzugefügt, um vor der Verwendung der Standardauthentifizierung für die API zu warnen
-
Abschnitt II, Leitfaden:
- Nummer 1 (Help-Center-Beschränkungen): Verweis auf geschlossene oder beschränkte Help Center hinzugefügt, um an die Produktfunktionen anzugleichen
- Nummer 5 (@Erwähnungen): Option zum Deaktivieren von @Erwähnungen zur Anpassung an das Produkt hinzugefügt für mehr Funktionalität sorgen
-
Abschnitt III, Messaging:
- Nummer 1 und 2 (Drittanbieterkanäle und private Anhänge): Zur übersichtlicheren Darstellung wurdenAbschnittskennungen (i) und (ii) hinzugefügt
- Nummer 2 (private Anhänge): „URLs und/oder“ zur Klarstellung hinzugefügt
- Nummer 7-10 (Endbenutzer-Authentifizierung, Löschung von Answer-Bot-Konversationen, Schwärzung, Malware-Scanning): Aus Gründen der Transparenz wurden vollständige Abschnitte hinzugefügt
- Abschnitt IV. Sunshine Conversations: ganzer Abschnitt hinzugefügt, da Sunshine Conversations in der Zendesk Suite Teil der BAA wird
- Abschnitt V, Chat, Nummer 3 (Arbeitsbereich für Agenten): kleine Formulierungskorrekturen
- Abschnitt achten, Mobile Anwendungen, Nummer 5-7 (Malware-Scanning, Schwärzung, Endbenutzer-Authentifizierung): ganze Abschnitte aus Transparenzgründen hinzugefügt
24. Februar 2023
- Abschnitt I. Support, Nummer 3: die separate Unterscheidung zwischen IP-Beschränkungen für Support und Chat wurde entfernt, da die Benutzeroberfläche jetzt vereinheitlicht ist.
- Abschnitt I. Support, Nummer 5: Klarstellung im Fall der Nichterfüllung der Anforderung hinzugefügt
- Abschnitt I. Support, Nummer 7: „Abonnent darf nicht“ geändert in „Abonnent nicht“.
- Abschnitt IV. Chat, Nummer 2: stellt klar, dass jegliche Exportfunktion von Daten aus Chat per E-Mail verboten ist und sich nicht nur auf Protokolle und Piping beschränkt.
- Abschnitt III. Messaging: gesamter Abschnitt hinzugefügt, um die Zendesk Messaging-Funktionalität über den Umfang der Zendesk-Geschäftspartnervereinbarung hinaus zu berücksichtigen.
9. Juli 2021
- Fügt Punkt 3 im Chat-Abschnitt für Verantwortlichkeiten im Zusammenhang mit der Nutzung des Arbeitsbereich für Agenten hinzu.
21. Januar 2021
- Durch Hinzufügen von Nummer 1.11 wird keine CSAT zugelassen, es sei denn, der Abonnent übernimmt die Verantwortung für die Daten, die im Rahmen der Umfrage per E-Mail gesendet werden.
- Vorbehalt in Nummer 1.7, um zu berücksichtigen, dass Abonnenten die Anzeigeberechtigungen ändern, weil Benutzer bereits die Genehmigung zum Zugriff auf diese Daten erhalten haben.
- Gesamtes Dokument aktualisiert, damit es dem Unternehmensstil der eingebetteten Links im Text entspricht ( statt Inline-URLs) (keine Auswirkung auf Konfigurationsinhalte).
August 2020
- Explore Enterprise bietet jetzt zusätzliche Funktionen zum Teilen von Dashboards
- Aufhebung der Sperre für Chat-Anhänge (Support Authentifizierungsanforderungen jetzt erfüllt)
- Es ist klar, dass das Verbot von ePHI in angepassten Feldern speziell für die Nutzung von Insights gilt, nicht global
- Ein neuer Abschnitt über Add-ons für bereitgestellte Dienste wurde hinzugefügt, wobei „Nebenkonversationen“ die erste Wahl ist
- Verschiedene Grammatik-/Formatierungsänderungen (die sich nicht auf den Inhalt auswirken)
13. Juli 2020:
- Begriffsklärung bezüglich der Nutzung von SMS über den Dienst im Gegensatz zur nativen Nutzung von SMS für produktintegrierte 2FA. * Zur Klarstellung: Die in Abschnitt 10 zu SMS genannten Vorbehalte zu ePHI gelten nicht für die produktintegrierte Nutzung der 2FA (siehe Abschnitt 1.a), da diese Funktion lediglich eine numerische Zeichenfolge zur Identitätsprüfung sendet.
13. Dezember 2019
- ermöglicht den Verzicht auf Agenten-IP-Beschränkungen, wenn der Anwendungsfall dies nicht zulässt, solange MFA für den Agentenzugriff durchgesetzt wird.
17. Dezember 2019
- lässt Kommentare von Endbenutzern in Guide zu, solange Agenten diese Kommentare moderieren und alle PHI-Kommentare entfernen.
6. November 2019
- Beitrag aktualisiert, um die Änderung widerzuspiegeln, dass Abonnenten nach eigenem Ermessen auf eine bestimmte Konfiguration verzichten oder sie ersetzen können, solange sie die Verantwortung für diese Entscheidung übernehmen.
„Versäumt es ein Abonnent, eine bestimmte unten aufgeführte Konfiguration oder eine Reihe erforderlicher Konfigurationen unten zu implementieren und einzuhalten, ahnden wir als
auf eigenes Risiko und nach alleinigem Ermessen des Abonnenten; und ein solches Versäumnis entbindet Zendesk und seine Mitarbeiter, Agenten und verbundenen Unternehmen von jeglicher Verantwortung im Hinblick auf den unbefugten Zugriff auf oder die unsachgemäße Verwendung oder Offenlegung der Servicedaten des Abonnenten, einschließlich aller elektronischen geschützten Gesundheitsdaten, infolge eines solchen Versäumnisses durch den Abonnenten . "
-
Weitere Änderungen:
- 1. die Fähigkeit zur Nutzung von SMS, solange der Abonnent selbst dafür verantwortlich ist, sicherzustellen, dass keine personenbezogenen Gesundheitsinformationen in solchen Übertragungen enthalten sind.
- 2. Die Möglichkeit, Anhänge in Chat zu verwenden, solange der Abonnent die gesamte Verantwortung dafür trägt, dass in diesen Anhängen keine personenbezogenen Gesundheitsinformationen enthalten sind.
6. März 2019
- aktualisiert, um Einstellungen für Zendesk Explore hinzuzufügen
17. Januar 2019
- aktualisiert, damit in Chat keine Anhänge mehr zulässig sind.
Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.
Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.
0 Kommentare