リスクスコアが15分未満の接触で閾値を越えたときの対応が考慮されていない

[daisuke-nogami]

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

確実に1m以内・15分以上の接触を拾うためのパラメータを設定しているので、特定の条件においては
14分以下であってもリスクスコアが閾値を超えることがある。
この場合、陽性者との接触確認画面で、14分未満の接触があった日が表示されて、
「15分以上の接触」が記載されることが期待されている状態と齟齬がでる。

これを無くすためにExposure WindowのScanInstanceの時間合計を判断条件に加えると、
今度は、閾値以下の信号受信が表示される画面に閾値以上のスコアが表示される日が出る。

解決策についてお書きください / Describe the solution you'd like

閾値に、Exposure Windowの時間合計の条件を加える。

あわせて、閾値以下の信号受信の画面で、「スコアが閾値を超えたが時間が14分以下」の場合には、
その日付のスコアの脇に （◯分間の接触のため通知対象外） と付記する。
また、画面末尾にある注釈に「一般的な条件では」を追加する。

※スコアは、受信した信号の強さと時間から算出しています。一般的な条件では1m以内・15分以上の接触で {0:#} {1:#}になるように設定しています。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

その他 / Additional context

[daisuke-nogami]

設定ファイルは、
cocoa/documents/static/exposure_configuration/risk_calculation_configuration.json
を以下の様になおす。

  "ExposureWindow_ScanInstance_SecondsSinceLastScanSum": {
    "op": ">=",
    "value": 900.0

[keiji]

やります

[keiji]

これ思ったんですが、14分とか基準値未満であればスコアを表示しなくていいのでは?

[keiji]

リストタイトルも「受信した信号と通知をしない理由」とかにして、日付の下に

スコア1200のため通知対象外

とか

14分間の接触のため通知対象外

と言う記載にする

[keiji]

@daisuke-nogami
こんな感じで、
電波を受信したことを利用者に示すことで接触確認の仕組み自体が正常に動作していることを示し、
下回った基準値に限定した値を示すことで、過剰な不安を与えないように配慮しています。

[daisuke-nogami]

危険であることをAND条件で判断するときに、いずれかの条件が否定されたので危険ではない、というのは理屈としては通ってますが、スコアという分かりにくいものがならぶの、なんとなく都合のよい部分だけみせてる感じがしてしまいます。

もともと、距離と時間で危険を判断しているので、そのどちらかを否定することがわかればよいとすると、スコアは距離・時間の合成変数なので、時間で割った値をスコアとしてみせるのはどうでしょうか。
（実際、閾値は、その「スコア」に900秒をかけて定義してます）

ただ、また新しいものが出てきちゃいますが…

[keiji]

わかりました。
この画面については引き続き、利用者の受け止め方を注視して、何かあればすぐに改善できるようにしましょう。

スコアを秒数で割る件については、そのままでも、割っても、利用者にわかりにくいのは変わりないと思うので（下部の注釈でカバーするとして）このままでよいと思います。

[keiji]

ちなみにスコア1100、時間が18分。みたいなパターンはないですか？

その場合はスコアだけ出す感じでしょうか。

[daisuke-nogami]

ありますね。数m以上の距離でも数時間などの場合には数十分というのは出てきてしまいます。
そういう場合には、やはりスコアだけが良いでしょうね、必要以上に不安になったり原因を探したくなると思います。

「信号の強さ・時間から算出したスコアで判断する」が大前提で、
「ただし、時間が15分未満なら（リスクが少ないので）通知は出さない」
※なんで15分未満でもスコアが基準値を超えるんじゃ ⇒ 技術的制約により安全を取りました
という考え方がにじみ出るようにはしたいですね。

[keiji]

まとめると、こんな感じでしょうか。

[daisuke-nogami]

はい！

[keiji]

見出しの「スコア」はどうしましょう。
「受信した信号」に変えましょうか

[daisuke-nogami]

そうしましよう！
スコアだとなにのことか分かりにくいですしね…

[keiji]

こんな感じでPull Request出します。改善点が見えたらまた変えると言うことで。

[keiji]

Pull Requestだしました。

[tmurakami]

すみません。少し気になったのでお聞かせください。

Duration の重みをつけなければ (immediate, near, medium を 100% に、other を 0% にすれば) ScoreSum はScanInstanceの時間合計になると思うので、新たに条件を加える必要はなくなるのではないかと思いますがいかがでしょうか？

Duration に重みをつけている意図は何かありますか？

[daisuke-nogami]

重みをつけないと1.0m以内という距離が判断できないからです。
距離⇒電波強度の分布を計算すると、以下の図の様に、1.0m/1.5m/2.0mにはかなり重なりがあり、
「特定の電波強度以上だけカウント」すると、検知しない/検知しすぎ、ということがおこります。
https://user-images.githubusercontent.com/71449929/148068023-b9909afc-b366-4a44-addc-64fe22eb98e4.png
（たとえば50dBを閾値にしてしまうと検知漏れが増え、55dBに閾値を置くと1.5mも相当数カウントしてしまう）

ですが、受信時間に掛けるWeightを、複数のDuration毎に変えてやることで、 スコア÷受信時間の値から
特定の距離であるかどうかの判別精度が上がる、という理由です。

画像初出：issue #605 の以下コメント
#605 (comment)

[tmurakami]

ご返答ありがとうございます。
意図はわかりました。

画像初出：issue #605 の以下コメント

失礼いたしました。
issue タイトルが画面作成についてでしたので見逃しておりました。

追記:
迷ったのですが、書いておきます。
あくまで個人的な感想ですが
https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0250826 の論文等を見る限り、「確実に1m以内」を判定するのは難しいと感じています。
バスや電車以外にも、例えばスマホケースの有無や湿度によっても電波強度に多少なりとも違いがでると思うので、個人的には厳密に距離を測定するのは難しいだろうと思っています。

[daisuke-nogami]

いえいえ、直近の開発の活発さの中で、変なところに埋もれているコメントまで拾うのは無理ですのでお気になさらず…

おっしゃるとおりで、「1m以内」というのを判定するのは非常に難しいです。
やり取りしている某社の技術者の方からも、全く同じ「1mを判定しようと思うな」というコメントを頂いています。
ただ、行政側と話すと、濃厚接触の基準として一度定着している「1m」を動かすことの重たさを感じます。
（積極的疫学調査実施要領でも、2mという距離があったりしますし、保健所の判定とは別、という位置づけに変えているのですが、どうにも関係者全ての記憶のキャッシュを上書きするのは難しいようです…）

まだ「2m以内」になればもう少し可能性がありそうなのですが、1mと2mを区別するのが至難の業で、
今回は、ある程度「1m～2m」も反応してしまうことを許容してパラメータ設定をしています。
（この距離判定については、丁寧にドキュメント化しないといけないと思う内容でして、近々どこかのタイミングでGithubのドキュメントには起こしたいと思っています）

なお、今回は生のBluetoothの電波強度ではなく、ENが補正したものを使う前提なので、
ENが出力する電波強度で判断をするために数十回以上の電波強度測定をしていますが、
一般的なカバンに入れた状態と入れない状態での電波強度の差分は（1m, 2mでは）ほとんど出ませんでした。
2m以内のような距離の場合は、人体で覆い隠される状態（≒満員電車）ぐらいでなければ、ある程度
「近くにいた」ということは分かるのではないか、とは感じています。

[kvaluation]

おおむね2m以内か、2mを超えているかという区分は、とても技術的にも社会的にもリーズナブルな気がします。

「近くにいた」はみなさん気にしてくれています。

一方、時間の方は、当然ですが、精度良く測定できます。
しかし、EN2ですと、ウェイトで時間相当の本当の時間ではない値に変換されてしまうので、医療ご関係者や行政とのコミュニケーションがより一層難しくなることを怖れています。

平均で2m以内のリアルな滞在時間（近接していた期間，ウェイト一切なし）を示せる方が、安定的な気がします。調べたい時に、1mか45cm以内の滞在時間も参考情報で示せたらより良いとは思います。

Apple | Googleの仕様では1mかどうか分かるかのようになっているけれど、日本の工業製品の品質との比較では1mと示せるような精度はでていない、というような説明ですと行政の納得も得やすいかも知れません。
（やっと体制が整ってこういう検証ができている。テストの予算や期間は非常に重要、というインプットもぜひ）

[daisuke-nogami]

時間の見せ方はなやましい所です。
ウエイト付けしていない時間も最初から出そうかとも思いましたが、

• 2台の端末と同時に接していれば時間は2倍になる
• 数時間といった非常に長い時間がでたときの恐怖感が大きい
• 人間の記憶が曖昧な場合には扱いに困る、異なるeventと紐付けられる恐れがある
  など、行政・医療での活用を考えると、クセがあるデータでもあると思いますので、今回のバージョンでの提示は、あくまで「アプリの動作状況表示」に抑制しています。

ただ、Exposure Dataの表現方法については、外部の力も借りながら適切な形を見いだせればと思っています。
Exposure Dataを出力できれば、リアルなデータを元に開発チーム外でも試行錯誤可能になるので、そのような見せ方をいろいろ頂きたいですし、データの正しい読み方については議論をしていければと思っています。

[kvaluation]

ありがとうございます。

時間の見せ方はなやましい所です。 ウエイト付けしていない時間も最初から出そうかとも思いましたが、

• 2台の端末と同時に接していれば時間は2倍になる

追っかけ通知の説明もしないといけないので、同時接触の陽性者が多いと時間も増えることは、普及させたいと思います。

• 数時間といった非常に長い時間がでたときの恐怖感が大きい

ExposureWindowの数（例えば、接触単位数）を一緒にだせたら良いかと思いました。
（説明の例：30分以内1名との接触で1個の接触単位数です。1名と50分接触で2個、2名と20分ずつの接触でも2個となります。）

• 人間の記憶が曖昧な場合には扱いに困る、異なるeventと紐付けられる恐れがある
  など、行政・医療での活用を考えると、クセがあるデータでもあると思いますので、今回のバージョンでの提示は、あくまで「アプリの動作状況表示」に抑制しています。

動作状況表示として、感染性の観点でのウェイトはいれないログに近いデータを示すというのも一案かと。

ただ、Exposure Dataの表現方法については、外部の力も借りながら適切な形を見いだせればと思っています。 Exposure Dataを出力できれば、リアルなデータを元に開発チーム外でも試行錯誤可能になるので、そのような見せ方をいろいろ頂きたいですし、データの正しい読み方については議論をしていければと思っています。

議論をうながすにせよ、資料整理いただくにせよ、シンポジウムなど日程にしてしまうと、省庁の決断力もさらに高まっていったりするような事例に触れたことがあります（笑）。

@daisuke-nogami 様、みなさまのご発表を楽しみにしています。