HIPAAおよびHDS有効アカウント(総称して「ヘルスケア有効アカウント」):

本文書で使用されているすべての大文字の用語は、ZendeskのBusiness Associate Agreement(「BAA」)またはZendeskのマスターサブスクリプション契約に記載のHDS規約(英語)に記載されている意味を有するものとします。 「医療提供契約」)。

HIPAA対応アカウントの場合、「PHI」は「保護対象医療情報」を意味し、HDS対応アカウントの場合は「PHI」は「個人医療情報」を意味します。

Zendeskおよび「契約者」は、ユースケースに応じて、以下の構成、または「契約者」が評価した代替手段を評価し、1つまたはすべての「ヘルスケア有効アカウント」について、適用法の下で遵守要件を満たすべきと判断した場合は、「ヘルスケア契約」を締結することを推奨します。サービスにPHIを導入する前に、までに確認することもできます。

「契約者」が単独の裁量により、以下に推奨される設定のいずれかを実行しないことを選択した場合、「契約者」は、 「契約者」が推奨する設定からの違反。

加入者は適切なレベルでサービスプランを購入し、必要な関連アドオンを持っている必要があります(不明な場合は、営業担当者にお問い合わせください)。

加入者がHDS有効のアカウントを持っている場合、加入者は Zendeskのサブ処理者ポリシー の「フォローする」ボタンをクリックして、サービスを提供するために使用されるサブ処理者に変更の通知を受け取る必要があります。

Zendeskサービスでは、以下の最小セキュリティ構成が実施され、ヘルスケア有効アカウントのヘルスケア契約上、承認される必要があります。

I.Zendesk Support:

  1. 次の2つの方法のいずれかを使用して、エージェント認証を保護します。
    1. パスワードを設定したネイティブのZendesk Supportを使用する方法:(i) 「推奨」に設定する;または「推奨」設定で確立された要件よりも安全な要件を確立する方法で、「契約者」がカスタマイズした要件。さらに、このサブセクションのオプションでは、「契約者」は「サービス」内でネイティブに2要素認証(「2FA」)を有効にし、適用する必要があります。そして、管理者がエンドユーザーのパスワードを設定できるような管理コントロールは無効にする必要があります。または
    2. Zendeskの「推奨」パスワード設定で確立された要件よりも安全性の高い要件が設定された外部のシングルサインオン(「SSO」)ソリューションを利用し、すべてのエージェントのアクセスに対して、選択したソリューション内で2要素認証を有効にして実施すること。管理者がエンドユーザーのパスワードを設定できる管理コントロールは無効にする必要があります。
    3. 認証方法としてSSOを利用した場合は 、パスワードアクセスを無効にする必要があります。
  2. ヘルスケア有効アカウントのSecure Socket Layer(SSL)暗号化を、常に有効にしておく必要があります。ヘルスケア有効 zendesk.com以外のドメインを利用するアカウントは、 ホストSSLを確立し、維持する必要があります」でツリーベースの最大権限を有効にします。
  3. 可能であれば、エージェントのアクセスは「契約者」の管理下にある 特定のIPアドレスのみに制限される 必要があります。 ただし、上記の要件1.aまたは1.bに記載されているように、契約者がエージェントの多要素認証を有効にしている場合を除きます(ネイティブサービス内またはエンタープライズSSOと結合された契約者環境のいずれか)。  疑義が生じるのを避けるため、「エージェントアクセス」とは、ユーザーインターフェイス(「UI」)を介してサービスデータにアクセスする人間のエージェントに付与されたアクセスを示すものとします。
  4. 「契約者」のヘルスケア有効アカウントによりZendeskアプリケーションプログラミングインターフェイス(以下「API」)への呼び出しが可能になる範囲内で、「契約者」は作成、アクセス、修正、または削除が許可されたすべての「契約者」または「サードパーティ」のエンティティのセキュリティに及ぼす影響を理解する全責任を負うものとします。かかるアクセスおよび/またはインテグレーションを介したサービスデータおよびPHI。当該のAPIへのアクセスについては、以下に説明するようにZendeskがさまざまな方法を提供しており 、「契約者」は使用されているAPIモデルに基づいて以下のセキュリティのベストプラクティスを実装するものとします。
    1. OAuth 2.0アプローチ」でツリーベースの最大権限を有効にします。  このモデルは、最も詳細なセキュリティ機能を提供しますが、エンドユーザーがアクセス権限を受け入れる必要があります。  「契約者」は、可能な場合は、OAuth 2.0アプローチと認証スキーマを利用する必要があります。」でツリーベースの最大権限を有効にします。サブスクライバーは各OAuthクライアントに、説明的な一意のクライアント名と一意のID指定機能を提供する必要があります。各OAuthトークンに付与される権限は、必要なタスクを達成するために必要な最低限の権限のみを許可するものです。
    2. REST APIトークンアプローチ」でツリーベースの最大権限を有効にします。  このモデルは最も広範なモデルであり、APIトークンでAPIモデルのすべての機能を利用できます。メッセージングは、その性質上、最も広範なアクセスと機能を提供するため、慎重に使用する必要があります。このアプローチを使用する場合、「契約者」は(i)サービスごとに固有のトークンを使用し、トークンに説明的な名前指定機能を付与する必要があります。 (ii) 合理的に必要な場合およびエンドツーエンドで暗号化された転送方法に従った場合を除き、APIトークンを第三者と共有しないこと。 (iii) APIトークンがサードパーティと共有されており、「契約者」がサードパーティの「データ違反」を認識した場合、「契約者」は直ちに関連するトークンを回転させる必要があることを了承します。および (iv) 少なくとも、「契約者」の「組織ポリシー」に従って、トークンを頻繁にローテーションする。  
    3. 「契約者」は、APIへのパスワードアクセスを可能な限り無効にする必要があります。このアプローチでは、リクエストごとにユーザー資格情報を送信するため、一般に公開することで、ユーザーが悪意のある第三者によって傍受されやすくなるからです。  
  5. 添付ファイルへのアクセスに認証を要求するには、「ダウンロード時に認証が必要」を 有効にする必要があります」でツリーベースの最大権限を有効にします。これを行わない場合、制限のない添付ファイルは、当該添付ファイルの正しいURLにアクセスできる誰でもアクセスできるようになります。このような場合、「契約者」は添付ファイルの内容、および添付ファイルデータへのアクセスにすべての責任を負うものとします。
  6. 「契約者」は、「エージェント、管理者」および「オーナー」がエンドポイントにアクセスするすべてのシステムに対し、パスワードロック付きのスクリーンセーバーまたはスタートアップ画面を組織的に適用し、システムが非アクティブの状態が最大15分継続するように設定する必要があります。
  7. 加入者は、ユーザーがインスタンス/ブランド/組織全体の更新を表示できるようにする閲覧権限を変更したり、ユーザー自身のチケットまたはグループを超えたアクセスを許可するデフォルト設定を変更したりしないでください。ただし、加入者が、以降のすべてのデータへのアクセス)。「エンドユーザー」組織の権限は、ユーザープロフィールおよび組織自体の権限で設定できること、および設定が競合する場合は、 より許容度の高い設定は、許容度の低い設定を上書きします。
  8. 加入者は、エンドユーザーからの電子メール送信、および関連するサービスデータを、加入者のZendesk Supportインスタンスで受信する前に、セキュリティ保護に対してZendeskが責任を負わないことを承諾します。これには、 Zendesk Supportチケットへの返信を介してメールで渡されるすべてのPHI(チケットのコメントや添付ファイルを含みますが、これらに限定されません)が含まれます。
  9. 「契約者」は、「契約者」のエージェントがメールチャネル経由でZendesk Supportチケットに返信した場合や自動化やトリガによって開始された場合など、さまざまな状況でZendesk Supportがエンドユーザーにメールを送信することを了承します。デフォルトでは、このメールには、自動通知に含まれるように設定された最新のチケットの対応やその他の情報が含まれます。これらの情報にはPHIを含む可能性があります。「契約者」をさらに保護するには、 Zendesk Supportインスタンスを エージェントが応答したことをエンドユーザーに警告のみを表示し、メッセージの内容を確認するにはZendesk Supportへの認証を求めるように設定されています。
  10. 加入者は、Zendeskサービス内で単独の裁量で利用できるテキストメッセージ機能がSMSおよび/または関連するプロトコルによってサポートされることを了承します。これらの機能では、サービスへのメッセージの暗号化なし、またはサービス外でのメッセージの送信が含まれる場合があります。  したがって、テキストメッセージ機能には、次のいずれかが必要です。
    1. ヘルスケア有効のアカウント*で使用されないこと、または
    2. 使用されている場合、「契約者」はその機能の使用にすべての責任を負います。
  11. 加入者は、サービスの 旧バージョンの顧客満足度アンケート(「旧バージョンのCSAT」) 機能を使用して、ユーザーの評価を得るために、Supportチケットに関連付けられたサービスデータ(PHIを含む場合がある)をメールで送信することを了承します。このデータの暗号化ステータスは制御されません。 。したがって、旧バージョンのCSAT機能では、次のいずれかが必要です。
    1. ヘルスケア有効のアカウント*で使用されないこと、または
    2. 使用されている場合、「契約者」はその機能の使用にすべての責任を負います。
  12. 加入者はサービスの顧客満足度アンケート(CSAT)機能の使用を承諾します チケットチャネル:適切に設定されていない場合、ユーザーの評価を取得するために、 Supportチケットに関連付けられたサービスデータ(PHIを含む場合がある)をメールで送信します。その暗号化ステータスはZendeskでは制御されません。また、特定のCSAT URLがあれば、誰でも特定のチケットの回答にアクセスできます。このため、チケットチャネルでCSAT機能を使用する場合、「契約者」は
    1. CSAT自動化メールの本文にPHIを含まないように設定し、 {{satisfaction.survey_url}} プレースホルダのみ
    2. 自由回答形式の質問機能を使用しない

*疑義が生じるのを避けるため、SMSに関するセクション10のPHIに関連するデータに関する注意事項は、製品内2FAの使用には適用されません(セクション1.aで説明)。この2FA機能は、本人確認のための数値文字列の送信にすぎないためです。

II. Zendesk GuideおよびGather:

  1. 加入者は、GuideおよびGatherサービスが本来パブリックであることを確認し(制限付きの記事を利用しない 、 非公開型または制限付きのインスタンスを使用しない)、したがって、加入者はZendesk GuideまたはGatherサービスのテキストまたはテキストで、PHIが含まれないようにする必要があります。記事または記事への添付ファイル、または記事内の画像として メールを送信することができます
  2. 契約者は、エンドユーザーがZendesk Guideで コメントを追加できる機能を無効に するか、 またはすべてのコメントからPHIを削除する機能をモデレートし、削除する必要があります(以下のセクション3で説明)。
  3. Zendesk GuideサービスがGuide ProfessionalまたはEnterpriseの場合、「契約者」はできるだけ、 Zendesk Guideで Gather機能をオフにして 、エンドユーザーが新しい投稿を作成できるようにする必要があります。 または、契約者が意図してGatherの機能をオフにした場合は、その機能を追跡できなくなります。ユースケースでは、「契約者」は Zendesk Guideサービスでコンテンツの審査を有効にして、「すべてのコンテンツをモデレート」に設定する必要があります。」でツリーベースの最大権限を有効にします。PHIを含む投稿は承認しないでください。
  4. 加入者によるGatherサービス内での従業員以外の「コミュニティモデレーター」の使用は、PHI(該当する場合)の可能性のあるデータへのアクセスに対して、加入者が責任を負わない限り、許可されるべきではありません。
  5. サブスクライバーは、エンドユーザーにパブリックプロフィールを持つことを許可する場合、Gatherコミュニティメンバーの「@メンション」が可能であることを確認します。この機能がユースケースにリスクがあるとみなされた場合は、 パブリックプロフィールをオフにする か、@メンションを無効にする必要があります。

III.Zendeskメッセージング:

  1. サブスクライバーは、(i)ソーシャルメディアメッセージにPHIが存在しないことを確認すること、または(ii)統合されたメッセージングプラットフォームで独自のBAAを締結することについて全責任を負わない限り、ソーシャルメディアメッセージングチャネルのインテグレーションを有効にしてはなりません。
  2. 加入者は、メッセージングの会話にファイルを添付できるエンドユーザーの機能を無効にする必要があり、 安全な添付ファイルを有効にする(i)機能のいずれについても全責任を負うものとします。(ii) エージェントがメッセージングの会話にePHIを含むファイルを添付しないことを保証する。これを行わない場合、制限のない添付ファイルは、当該添付ファイルの正しいURLにアクセスできる誰でもアクセスできるようになります。  このような場合、「契約者」はURLおよび/または添付ファイルデータの内容、およびこれらへのアクセスに対してすべての責任を負うものとします。
  3. 加入者は、すべてのエージェントおよびライトエージェントがすべてのエンドユーザーからのすべての受信メッセージを閲覧できることを保証することに全責任を負うものとします。
  4. 加入者またはそのエージェントがAPIおよびWebhookのためのインテグレーション(例: AIエージェント用に作成されたフローの一部として)にアクセスまたは開発する場合、またはメッセージングエクスペリエンスをカスタマイズする場合、加入者はすべてのカスタムワークフローおよびサブスクライバーまたはサードパーティエンティティ(チャットボットプロバイダーを含む)は、かかるアクセスおよび/またはインテグレーションを介して「サービスデータ」およびePHIを作成、アクセス、変更、または削除することができます。
  5. 「メッセージングの会話」が進行中の状態で、「契約者」がエージェントのメッセージング会話への参加権限を削除したい場合、「契約者」はその「エージェント」のZendeskへのアクセスを強制的に終了させるすべての責任を負うものとします。
  6. デフォルトでは、エンドユーザーとのWeb Widgetの会話は永続的であり、エンドユーザーが同じデバイスからWebチャットに戻ったときに確認できるようになります。加入者は、この機能を無効にするか、またはエンドユーザーがデバイスを共有しないようにするためのすべての責任を負うものとします。
  7. 加入者がエンドユーザーに対して認証の実装を希望する場合、加入者はベストプラクティスおよび業界標準に従って安全な方法でこれを実装する全責任を負うものとします。
    1. このアプローチを使用する場合、「契約者」は(i)各認証チャネルに対して固有のJWT署名キーを使用し、トークンに説明的な名前指定機能を付与する必要があります。 (ii) 合理的に必要な場合およびエンドツーエンドで暗号化される転送方法に準拠する場合を除き、JWT署名キーを第三者と共有しないこと。 (iii) JWT署名キーが第三者と共有されており、「契約者」に第三者のデータ侵害を認識させた場合、「契約者」は直ちに関連するJWT署名キーを回転させる必要があります。および (iv) 少なくとも、「契約者」の組織ポリシーに従って頻繁にJWT署名キーを更新すること。
    2. サブスクライバーは期限切れJWT属性を使用し、15分以内に値を設定する必要があります。
  8. 加入者は、エンドユーザーとAIエージェントとの間で人間のエージェントに引き継がれ、チケットに転送されないインタラクションはまだシステムに保存されることを承諾します。加入者は、義務に従ってそれらを削除する責任があります。また、これらの会話が保存されたときにサブスクライバーに警告し、 Sunshine Conversations API経由で自動的に削除をトリガするWebhookを使用します。 
  9. 契約者は、エンドユーザーとAIエージェントとの間の会話が 変換されたことを了承する チケットへの追加は現在墨消しできません。チケットを削除することで削除が可能になります。 
  10. 契約者は、メッセージングチャネル上のエンドユーザーの添付ファイルは現在、Zendeskではマルウェアのスキャンが行われていないことを了承します。加入者は、加入者の資産に対するリスクを軽減するために、手続きおよびポリシーを導入することに全責任を負うものとします。 
  11. 加入者は、「サイドカンバセーション」機能を使用すると、「子チケット」および/または「サイドカンバセーション」メッセージが内で作成されるか、または加入者のSupportインスタンスからチケット、メール、 Slack、またはインテグレーションを介して受信者に送信される可能性があることを承諾します(エージェントの裁量で)。 」でツリーベースの最大権限を有効にします。「契約者」が「ヘルスケア有効」アカウントでこの機能を使用することを選択した場合、(i)そのようなメッセージにPHIが存在しないことを確認するか、または(ii)メッセージにPHIが含まれる可能性がある場合、「契約者」はいずれかの責任を負うものとします。 「サイドカンバセーション」機能を介したメッセージの交換に起因するPHIの不正な取得、アクセス、使用、または開示に関連する一切の責任、費用、損害または損害の保証を提供するものとします。

IV. Zendesk Sunshine Conversations:

  1. サブスクライバーは、(i)サードパーティのチャネルメッセージにPHIが存在しないこと、または(ii)統合されたメッセージングプラットフォームで独自のBAAを締結することについて全責任を負わない限り、サードパーティチャネルのインテグレーションを有効にしてはなりません。
  2. 加入者は、 Sunshine Conversationsアプリケーションプログラミングインターフェイス(以下「API」)を介してサービスデータおよびPHIを作成、アクセス、修正、または削除できるすべての加入者またはサードパーティエンティティのセキュリティへの影響を理解する全責任を負うものとします。上記のAPIへのアクセスについて、「契約者」は使用するAPIモデルに基づいて以下のセキュリティのベストプラクティスを実装するものとします。
    1. OAuth 2.0アプローチ」でツリーベースの最大権限を有効にします。  このモデルは、最も詳細なセキュリティ機能を提供しますが、エンドユーザーがアクセス権限を受け入れる必要があります。  「契約者」は、可能な場合は、 OAuth 2.0アプローチと認証スキーマ」でツリーベースの最大権限を有効にします。サブスクライバーは各OAuthクライアントに、説明的な一意のクライアント名と一意のID指定機能を提供する必要があります。 
    2. REST APIトークンアプローチ」でツリーベースの最大権限を有効にします。  このモデルは最も広範なモデルであり、APIトークンでAPIモデルのすべての機能を利用できます。  メッセージングは、その性質上、最も広範なアクセスと機能を提供するため、慎重に使用する必要があります。このアプローチを使用する場合、「契約者」は(i)サービスごとに固有のトークンを使用し、トークンに説明的な名前指定機能を付与する必要があります。 (ii) 合理的に必要な場合およびエンドツーエンドで暗号化された転送方法に従った場合を除き、APIトークンを第三者と共有しないこと。 (iii) APIトークンがサードパーティと共有されており、「契約者」がサードパーティの「データ違反」を認識した場合、「契約者」は直ちに関連するトークンを回転させる必要があることを了承します。 (iv) 「契約者」の組織ポリシーに従ってトークンを頻繁にローテーションすること。  
    3. 「契約者」または「そのエージェント」がAPIおよびWebhookのインテグレーションにアクセスしたり、 Sunshine Conversationsのエクスペリエンスをカスタマイズしたりする場合、「契約者」はすべてのカスタムワークフローおよび許可された「契約者」または「サードパーティ」のエンティティ(チャットボットプロバイダーを含む)のプライバシーとセキュリティの影響を理解する全責任を負うものとします。当該のアクセスおよび/またはインテグレーションを介して「サービスデータ」およびPHIを作成、アクセス、変更、または削除することができます。
  3. サブスクライバーは、 Zendesk Support用に設定されたIP制限がSunshine Conversations APIに拡張されないことを承諾します。加入者は、2.bに記載されている通り、 Sunshine Conversations APIおよびAPIトークンへのアクセスを制限することに全責任を負うものとします。クライアントのポリシーに従って機能します。 
  4. 加入者は、 Sunshine Conversationsの会話にファイルを添付できるエンドユーザーの機能を無効にする必要があり、 安全な添付ファイルを有効にすることについては全責任を負うものとします。 エージェントがメッセージングの会話にPHIを含むファイルを添付しないようにすることができます。これを行わない場合、制限のない添付ファイルは、当該添付ファイルの正しいURLにアクセスできる誰でもアクセスできるようになります。このような場合、「契約者」は添付ファイルの内容、および添付ファイルデータへのアクセスにすべての責任を負うものとします。
  5. 「エンドユーザー向け認証」の実装を希望される場合、「セキュリティのベストプラクティス」および「業界標準」に従って堅牢な方法でこれを実装する全責任を負うものとします。
    1. このアプローチを使用する場合、「契約者」は(i)各認証チャネルに対して固有のJWT署名キーを使用し、トークンに説明的な名前指定機能を付与する必要があります。 (ii) 合理的に必要な場合およびエンドツーエンドで暗号化される転送方法に準拠する場合を除き、JWT署名キーを第三者と共有しないこと。 (iii) JWT署名キーが第三者と共有されており、「契約者」に第三者のデータ侵害を認識させた場合、「契約者」は直ちに関連するJWT署名キーを回転させる必要があります。および (iv) 少なくとも、「契約者」の組織ポリシーに従って頻繁にJWT署名キーを更新すること。
    2. サブスクライバーは期限切れJWT属性を使用し、15分以内に値を設定する必要があります。
  6. 加入者は、エンドユーザーとAIエージェントとの間で人間のエージェントに引き継がれ、チケットに転送されたインタラクションはまだシステムに保存されていることを確認し、Webhookを実装するなどして、義務に従ってそれらを削除するのは加入者の責任となります。会話が保存されたときに「契約者」に警告し、 Sunshine Conversations APIを介して自動的に削除をトリガします。 
  7. 契約者は、チケットに変換されたエンドユーザーとAIエージェントとの会話は現在墨消しできないことを了承します。チケットを削除することで削除が可能になります。 
  8. 契約者は、 Sunshine Conversations API経由で削除されたメッセージは、エンドユーザーに対してのみ削除され、Zendeskエージェントワークスペース上では削除されないことを承諾します。これは、チケット自体の削除または墨消し機能の使用で達成できます(制限事項については7.を参照)。 
  9. サブスクライバーは、 Sunshine Conversationチャネルのすべての添付ファイルについて、現在Zendeskではマルウェアの検出は行っていないことを了承します。加入者は、加入者の従業員のリスクを軽減するために、手続きおよびポリシーを導入することに全責任を負うものとします。 

V. Zendesk Chat:

  1. 「Zendesk Supportサービス」との接続および認証を行って、 「Zendesk Chatサービスへのエージェントのアクセスを制限する」ようにします。
  2. サブスクライバーは、(a) メールパイピングを無効にする、 (b)従来版のWeb Widgetの メールチャットの会話ログオプションを無効にする 、および(c) Chatダッシュボードからメールでエクスポートを共有しないことによって、Chatの会話ログをメールで送信 しないでください 。
  3. サブスクライバーは(i)Chat内にPHIが存在しないこと、および/または(ii)サブスクライバーによってすべてのエージェントがそのようなデータを表示できることを保証することについて、全責任を負うものとします。

VI. Zendesk Exploreサービス:

加入者は、ユーザー名、チケットのタイトル、フィールドおよびフォームの選択、および自由フォームのテキストフィールドにあるコンテンツを介してPHIがExplore製品内に表示される可能性があることを承諾します。

  1. PHIを含む対象サービスインスタンスについて、「契約者」は(i)親サービスインスタンスにPHIを含む可能性のあるすべてのチケット/コール/チャットにアクセスできるエージェントにのみ、Exploreインターフェイスへのアクセスを許可するものとします。 (ii) アカウントの環境内でExploreを使用するために必要な最低限の権限を考慮して、権限を付与する必要があります。Exploreでアクセスレベルを設定する方法の詳細については、 こちらを参照してください。
  2. 「エクスポート」機能を利用する場合、(i)契約者は、エージェントのインターフェイスへのアクセスを許可したデバイスにPHIが転送される可能性があることを了承します。また、そのデバイスに関するすべての付随する管理は契約者の責任であり、(ii)契約者はその使用を拒否する必要があります。 (a)PHIがエクスポートに含まれていないことを確認する、または(b)そのような転送に使用されるメールサービスが最低限の暗号化プロトコルで暗号化に対応できるようにすることのいずれかの責任を負わない限り、そのエクスポートされたレポートにメール経由のネイティブエクスポート機能を提供できます。準拠かどうかを確認します。

* Explore Enterpriseの使用に関する特別な考慮事項:

サブスクライバーは、Explore Enterpriseサービスを使用することで、データ共有およびエクスポート機能が拡張される可能性があることを承諾します。加入者は:

  1. (i)そのようなダッシュボードにPHIが存在しないことを確認する、または(ii)そのようなデータの閲覧およびデータの受信を承認されたエージェント、グループ、リスト、またはエンドユーザーとのみダッシュボードを共有する。
  2. IP制限を活用
  3. URL(Uniform Resource Locator)を介してダッシュボードを共有する場合、「契約者」は、個別またはグループのユーザーアカウントと共有するのではなく、アクセスリンクによってデータを共有することを承諾します。(i)パスワード保護を有効にし、(ii)選択したパスワードの複雑さ、ローテーション、保管および受領者への配布を、ダッシュボードに含まれるデータの保護に関する「契約者」のパスワードポリシーに準拠していることを確認し、(iii)ローテーションを行う必要があります。情報開示請求の疑いまたは確認時に、必要な遅延を与えずに

VII. 展開中の関連サービス(「アドオン」)の製品内機能に関するお知らせ:

  1. コラボレーション展開関連サービス:「サイドカンバセーション」加入者は、「サイドカンバセーション」機能を使用すると、「子チケット」および/または「サイドカンバセーション」メッセージが内で作成されるか、または加入者のSupportインスタンスからチケット、メール、 Slack、またはインテグレーションを介して受信者に送信される可能性があることを承諾します(エージェントの裁量で)。 」でツリーベースの最大権限を有効にします。「契約者」が「ヘルスケア有効」アカウントでこの機能を使用することを選択した場合、(i)そのようなメッセージにPHIが存在しないことを確認するか、または(ii)メッセージにPHIが含まれる可能性がある場合、「契約者」はいずれかの責任を負うものとします。 「サイドカンバセーション」機能を介したメッセージの交換に起因するPHIの不正な取得、アクセス、使用、または開示に関連する一切の責任、費用、損害または損害の保証を提供するものとします。

VIII. Zendeskモバイルアプリケーション(またはスマートフォンやタブレットなどのモバイルデバイスからのアクセス):

  1. 使用には、デバイスレベルの暗号化も含まれます
  2. デバイスの上限値に設定された生体認証またはPINアクセスを活用する必要がある
  3. チケットコメントをそのようなデバイスのロック画面に表示できる通知は無効にする必要があります。
  4. 画面の非アクティブ時のロックを有効にし、非アクティブな状態が15分を超えないようにロックするように設定する必要があります。
  5. 加入者は、墨消し 機能が Supportモバイルアプリでは利用できないことを了承し、エージェントが墨消し機能を使用したい場合は、ブラウザ経由でログインする必要があります。
  6. Zendeskメッセージングで「エンドユーザー」を認証するよう「契約者」が選択した場合、「契約者」は「エンドユーザーの認証ステータスがSupportモバイルアプリに表示されない」ことを確認します。

IX.Zendeskインサイト: このサービスのサポートは2021年2月5日をもって提供を終了しています。   

X.Zendesk AI機能に関するお知らせ(「Zendesk AI」、「高度なAI」、「生成AI」など):

  1. 加入者は、Zendesk AI機能 がZendeskサービスの生産性を高めることを目的としており、(i) 医療または健康に関するアドバイスの提供、(ii) 状態の診断の提供、または兆候(iii)治療を指示すること、または(iv)ユーザーが医療専門家にアドバイス、診断、または治療を求めることを何らかの方法で妨げるもの。医療サービスの検索または受信に影響を与える可能性のある医療計画、治療プログラム、テストサービス、またはその他の医療サービス(ただし、「契約者」が独自のユースケースおよびユーザーとのやりとりに基づいてこの決定に全責任を負う場合を除く)。 (このような方法でAIを使用することの潜在的な意味)」を参照してください。
  2. 契約者は、生成AI機能を使用する場合、生成されるAI出力は人間によるものではなくコンピュータによって生成され、不正確な出力を生成する可能性があることを了承します。Zendeskは、これらの出力の正確性を保証していません。
  3. 加入者は、AIエージェントの会話ボットのメッセージ を使用して「加入者のエンドユーザー」に必要な免責事項のメッセージを提供する場合、メッセージの内容の完全性を確保するために、「バリエーションを生成する」機能がアクティブにされないことを了承します。 
  4. サブスクライバーは、管理センターで拡張テキスト機能を有効にすると、ロールと権限に関係なく、インスタンス内のすべてのエージェントがこの機能を有効にすることを承諾します。 

XI.Zendesk QA

  1. 加入者は、 Zendesk QA AI機能がZendeskサービスの生産性を向上させることを目的としており、(i) 医療またはヘルスケアに関するアドバイスの提供、(ii) 状態の診断の提供などに利用できる方法で使用しないものとします。 (iii) 治療を指示すること。または (iv) ユーザーが医療専門家にアドバイス、診断、または治療を求めることをあらゆる方法で妨げること。(v) またはその他の方法でユーザーに情報を提供し、またはそれらを適用または除外する意思決定を行うこと。 (ただし、「契約者」が独自のユースケースおよび「ユーザー」とのやりとりに基づいて決定した場合を除く)。およびこのような方法でAIを使用することの潜在的な影響についても説明します。
  2. 「契約者」は、Zendeskインスタンス内の削除または墨消しがZendesk QAと直ちに同期されず、その後3〜6時間後に引き継がれることを承諾します。
  3. アンケート機能を使用する場合、「契約者」は(i) Zendesk QA AI支援機能を無効にする必要があります(または、 QA作業を実行するすべてのエージェントがその取引内の潜在的なデータを参照できるようにするとともに、ポイント1の原則を満たしていることを確認する必要があります)。 ii) アンケートの質問や説明にPHIが含まれないようにアンケートを設定する必要があります(または、日後取引のStartTLS経由で送信されるメールの中でそのようなデータの責任を引き受けます)。
  4. 「Zendesk Chat」カスタムインテグレーションを使用する場合、「契約者」は、「データが無制限に保持されないように」、「契約者」のポリシーに沿ったデータ保持期間を設定することを検討する必要があります。
  5. サブスクライバーは、 Sunshine Conversations APIを使用してZendeskメッセージングの会話の一部を削除する場合、この変更はZendesk QAに反映されないことを了承します。代わりに、墨消し機能を使用して元のチケットから情報を削除するか、会話全体を削除する必要があります。
  6. 契約者は、 Zendesk QAが現時点ではZendeskの「プライベート添付ファイル」機能をサポートしていないことを了承します。つまり、添付ファイルの正しいURLにアクセスできる人なら誰でもアクセスすることができ、PHIを含む機密データを使用しないでください。加入者は、当該URLおよび/または添付ファイルデータの内容に、またこれらへのアクセスにすべての責任を負うものとします。
  7. 「契約者」は、 Zendesk QAの初期プロビジョニングでは、最初の同期後にのみ高度な接続構成が可能であることを了承します。

XII.Zendeskワークフォースマネジメント「WFM」:

  1. 契約者が再確認する場合
    1. デフォルトのWFM管理者ロールは、 WFMサービスに適用されるすべてのエージェントのアクティビティと設定にアクセスできます(下記のポイント2で説明したタグを含む)。
    2. デフォルトのエージェントロールは、管理者がカスタムロールの作成を介して別のアクセス権を使用できるように設定されていない限り、エージェントのアクティビティにアクセスできます。この設定は こちらで説明しています。
  2. 加入者は、エージェント、管理者、またはSupportチケット内に既定のシステムロジックによって適用されたタグが、 WFM製品内で、このようなチケットアクティビティを表示できるユーザーに表示されることを承諾します。「契約者」がタグの機密性を認識する場合、アクセス権限は適切に設定しなければなりません。

免責事項:法律や規制の変更やZendeskサービスの変更などにより、本文書のセキュリティ構成は今後変更される可能性があります。このドキュメントには、上記のZendesk製品内でPHIを保護するために有効な最低限のセキュリティ構成に関するZendeskの推奨事項が記載されています。本文書は、このようなデータに関するすべての管理の包括的なテンプレートを構成するものではなく、また法的アドバイスを構成するものでもありません。Zendeskの契約者は、 HIPAAまたはHDSのコンプライアンス要件に関して、自身の法律コンサルタントに相談する必要があります。また、契約者自身の独自の分析結果に従って、セキュリティ構成に追加の変更を行う必要があります。ただし、そのような変更がZendeskのセキュリティを妨げたり低下させたりしない限り、追加の変更を行う必要はありません。説明する設定のみです。

 


変更履歴:

2025年1月24日

  • HIPAAおよびHDSの統合構成

2024年12月27日

  • Zendeskワークフォースマネジメント(「WFM」)をスコープに組み込むために、セクションXIIを追加

2024年12月16日

  • Zendesk QAをスコープに組み込むために、セクションXIを追加
  • 「Answer Bot」のさまざまなインスタンスを「AIエージェント」に変更し、命名規則の変更と適用範囲を拡大。

2024年10月10日

  • セクションI、 Support、番号12(CSAT)を追加し、新しい機能に対応するためにセクションI、 Support、番号11(旧バージョンのCSAT)を編集しました。 

2024年3月7日

  • セクションX、Zendesk AI機能に関するお知らせを追加
  • セクションI - Support- 番号7(閲覧権限):
    • 「閲覧権限」は、「組織」に対してではなく、「インスタンス/ブランド/組織」全体に適用されることを明確にする。
    • エンドユーザー固有の組織の動作に関する新しい規定を追加しました。 
  • セクションI、Support、番号9(メール):  
    • Zendesk Supportがエンドユーザーにメールを送信する状況を拡張。エージェントがチケットに回答するだけでなく、メールチャネル経由の返信や、自動化やトリガによって開始された返信を含むようになりました。
    • デフォルトでは、自動通知に、最新のチケットの対応またはその他の設定済み情報(PHIなど)が含まれるように指定します。

2023年10月25日

  • はじめに:HIPAA対応アカウント向けの明確な開始言語
  • セクションⅡ「GuideとGather」の#1(ヘルプセンターの制限):説明のためにIP制限を制限付きの記事に置き換えました。

2023年4月13日

  • セクションI. Support番号4(API): 
    • 明確にするために認証方法へのリンクを追加しました 
    • b)業界のベストプラクティスに合わせてローテーションの推奨時間を正確に削除し、REST API利用規約(冗長性)への参照を削除しました。
    • を追加し、c)を使用して、APIの基本認証の使用について警告を追加。 
  • セクションⅡ、Guide:
    • 番号1(ヘルプセンターの制限):製品の機能に合わせて、非公開型または制限付きのヘルプセンターへの参照を追加します。
    • 番号5(@メンション):製品に合わせて@メンションを無効にするオプションの追加 機能 
  • セクション III メッセージング: 
    • 番号1と2(サードパーティチャネルとプライベート添付ファイル):明確のためにセクション ID (i)と(ii)を追加しました
    • 2(プライベート添付ファイル):説明のために「URLまたは」を追加しました。
    • 番号7-10(エンドユーザー認証、Answer Bot会話削除、墨消し、マルウェアスキャニング):透明性のために完全なセクションが追加されている
  • セクション*** Zendesk SuiteのSunshine Conversations Sunshine ConversationsがBAAの一部として追加されたため、セクション全体が追加されました 
  • セクションV. チャット番号3(エージェントワークスペース):ちょっとした言い回しの修正
  • セクションV III モバイルアプリ 番号5-7(マルウェアスキャニング、墨消し、エンドユーザー認証):透明性のためにセクション全体を追加

2023年2月24日

  • 「I. Support」セクション(No.3)では、UIの統一に伴い、 SupportとChatのIP制限間の個別の制限が削除されました。
  • セクションI.SupportNo.5:要件を満たせなかった場合の説明を追加 
  • セクションI.Support()、番号7:「契約者はその必要がない」は「契約者はその必要はありません」に変更されました。
  • セクション IV.Chat番号2:メールを使用したChatからのデータのすべてのエクスポート機能が禁止されており、会話ログとパイピングのみの対象ではないことを示しています。 
  • セクション III.メッセージング:Zendesk Business Associate Agreementの範囲に加え、Zendeskメッセージング機能のアカウントに追加されたセクション。

2021年7月9日

  • エージェントワークスペースの使用に関する責任についてChatセクションにポイント3.を追加します。

2021年1月21日

  • 番号1.11の追加により、アンケートの一部としてメールで送信されたデータについて「契約者」が責任を負わない限り、 CSATの利用は無効になります。 
  • 第1.7項:ユーザー側で当該データへのアクセスを既に行っているユーザーに対して、閲覧権限を変更する権限を「契約者」に拡大するための警告。
  • インラインURLではなく、テキスト内の埋め込みリンクを会社のスタイルに合わせて、ドキュメント全体を更新 (設定コンテンツには影響しない)。

2020年8月

  • Explore Enterpriseの追加で、ダッシュボード共有機能を拡張
  • Chatの添付ファイルの利用禁止の解除(Supportの認証要件の対象となる)
  • カスタムフィールドでのePHIの使用禁止が、インサイトの使用にのみ適用され、グローバルに適用されることはありません
  • 展開済みサービスのアドオンを提供する新しいセクションの追加。
  • さまざまな文法/書式の編集(コンテンツとは無関係)

2020年7月13日:

  • 製品内2FAとしてのSMSのネイティブ使用とは対照的に、サービス経由でのSMSの使用に関する曖昧さを排除: * 疑義が生じるのを避けるため、SMSに関するセクション10のePHIに関連するデータに関する注意事項は、製品内2FAの使用(セクション1.aで説明)には適用されません。なぜなら、この2FA機能は本人確認のために数字の文字列を送信するだけであるからです。」

2019年12月13日 

  • エージェントのアクセスに関するMFAが適用されている限り、このような制限は許可されません。

2019年12月17日 

  • エージェントがエンドユーザーのコメントをモデレートし、すべてのPHIを削除する限り、Guideのエンドユーザーのコメントを許可します。

2019年11月6日

  • 記事が更新され、「契約者」が単独の裁量で選択した変更を反映して、特定の構成を延期または置き換えることができるようになりました。

「以下に記載した特定の設定または以下に記載した一連の必要な設定を実装および遵守しなかった契約者は、

加入者自身の責任と加入者の単独の裁量:およびそのような失敗により、「Zendesk」およびその従業員、エージェント、および関連会社は、このような失敗に起因する「電子保護対象の医療情報を含む」の不正アクセスまたは不適切な使用または開示に関して、一切の責任を負わないものとします。 」でツリーベースの最大権限を有効にします。 "

  • その他の変更点:
    • 1. 契約者がSMSの送信にPHIが含まれないことを確認するすべての責任を負う場合において、SMSを使用する機能。
    • 2.Chatで添付ファイルを使用する場合、添付ファイルにPHIが含まれていないことを確認することを契約者が全責任を負う必要があります。

2019年3月6日 

  • が更新され、 Zendesk Exploreの設定も追加されました

2019年1月17日

  •  さんがを更新しました。これにより、Chatで添付ファイルを無効にすることができます。

翻訳に関する免責事項:この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。

翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。

Powered by Zendesk