Closed daisuke-nogami closed 1 year ago
「接触通知の発生状況(exposure_data.json)」と「提出者の属性」についてはIssueを分けるといいかなと思います。
とくに「接触通知の発生状況(exposure_data.json)」と「提出者の属性」をそれぞれ別個に(リンクせずに)収集するか。リンクして収集するのかでプライバシーへの影響度が変わってくると考えますので、この点も分けて検討していくのが良いと考えています。
「今後のために可能な限りデータをもらいたい」という気持ちはぼくも同じという前提で、利用者にお願いするに当たってクリアすべきポイントは、
くらいでしょうか(他にもあればご指摘ください)。
「こんな情報をとりたい!」「この情報があればこんなことが分析できる!」という合理的に必要性を伝えていくことも大切ですが「この内容だったら協力してもいいかな」と利用者に思ってもらえるような形を探していけるといいですね。
今回のIssueでは、「接触通知の発生状況(exposure_data.json)」を取得する際に、「提出者の属性」をリンクさせて収集するかを問うIssueですので同じIssueで語っています。
一方、リンクさせずに「提出者の属性」だけを収集するのは、ユーザ全体に占める属性別のユーザ数の割合を知るのが目的になり、Additional Textに書いたOutcomeの調査の話になると自分は整理しています。 自分の中ではアプリ内でOutcomeを調査しない前提だったのでIssueを立てていませんでしたが、言われてみれば、Outcomeに相当する事項をアプリ内で聞くべきか、は、確かにIssueですので、その点のIssueを別に立てますね!
今回のIssueでは、「接触通知の発生状況(exposure_data.json)」を取得する際に、「提出者の属性」をリンクさせて収集するかを問うIssueですので同じIssueで語っています。
だとすると、「提出者の属性と接触データの関連付けの可否を検討」というタイトルにした方がよりわかりやすいと思いますがいかがですか。
いまのIssueだとタイトルが「実装」で終わっているので、見る人に実装することが決まっているような印象を与える可能性があります。
実装してもリリースしない。という可能性もあるのですが、どちらにせよ当該機能をリリースするかどうかも含めて「検討」段階にあることはタイトルで明示するのが良いと考えます。
そうすると、解決策の中で語っている3つの課題を別々にIssueにした方がよかったですね(というか課題=Issueじゃん…)。接触通知の発生状況の把握自体の是非をこのIssueに残しつつ、把握を前提としたときに直面する論点を扱うIssueを分割しました!
調査検討(実装)にあたっての参考資料をこちらにも共有します。
Indicator framework to evaluate the public health effectiveness of digital proximity tracing solutions https://www.ecdc.europa.eu/en/publications-data/indicator-framework-evaluate-public-health-effectiveness-digital-proximity
ECDC(European Centre for Disease Prevention and Control: 欧州疾病予防管理センター)と、WHO(World Health Organization: 世界保健機関)の本部・欧州地域事務局が共同開発したデジタル接触追跡の評価フレームワークです。
This indicator framework, developed by ECDC together with the World Health Organization (WHO) through its Headquarters and Regional Office for Europe (WHO/Europe), is intended for use by relevant national health authorities, public health and related institutions and their partners involved in the planning, implementation, monitoring and evaluation of contact tracing activities. It will be of most relevance to those with responsibility and oversight for the development and deployment of national digital proximity tracing solutions.
"4. Options for data collection" の冒頭にあるとおり、収集できるデータは各国の事情によって異なるという前提があります。 COCOAというコンテキストで、どのような形で情報を収集、分析していくか(どのような形であれば情報を収集、分析できるか)を決めることは独立して行うことになると考えます。
The capacity to collect data for each of the indicators in this framework may vary across countries due to differences in design architecture, integration of the overall surveillance and response strategy, and the local legal, privacy and governance context. There is therefore variation in the type of data that can be collected and the sources they can be collected from (app controller, public health authorities, surveys, etc.). Different options for data collection in the context of digital proximity tracing are listed below.
その上で、次世代の接触追跡(Contact Tracing)のデジタル化(計画は現時点で存在しない)を検討するにあたっては、効果指標の設定や必要な情報の検討をする上での参考にできると考えています。
手前のコメントでの指摘(Issueのタイトルが調査を前提としている)への対応がもれていました。子Issueも含めて議論されている内容に合わせたタイトル修正をしました。
子Issueも踏まえて、調査を行うとしたときの調査概要を(子Issueでの整理も転記して)まとめました。
接触通知の発生状況データの期間・内容 https://github.com/cocoa-mhlw/cocoa/issues/1141#issuecomment-1254570795
回答者の属性 https://github.com/cocoa-mhlw/cocoa/issues/1143#issuecomment-1254576864 ※目的に沿うためには案①ないし案②とすべき
こちら、Github含めていろいろなところでの議論を踏まえて、
という流れで、以下の様な画面設計でコードをフリーズさせてテストを進めております。
調査が終了して、総括報告書で発生回数推計も公開することができましたのでCloseします。
その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?
関連Issue #1132
解決策についてお書きください / Describe the solution you'd like
機能停止版COCOAを用いて調査を実施する。
具体的には、機能停止版COCOAの停止処理の直後に、調査への任意での協力依頼を表示する。協力いただける方には、可能な範囲で提出者の属性もお答えいただき、exposure_data.jsonとともにサーバに送信する形式を取りたい。
本Issueでは、そもそもの是非や手段の選択肢(「代替案」の項で言及))について検討したい。
なお、これを実現するとすると、大きな課題が3点ほどあるため、別Issueで議論する。
あなたが考える代替案についてご説明ください / Describe alternatives you've considered
その他 / Additional context