Skip to content
This repository has been archived by the owner on Apr 12, 2023. It is now read-only.

V3DiagnosisApiで陽性情報登録をすると本来意図しない日付の診断キーを配信することになる #1105

Open
keiji opened this issue Aug 9, 2022 · 13 comments
Labels
bug バグ。本来あるべき動作をしていないもの confirmed 開発内部管理用

Comments

@keiji
Copy link
Collaborator

keiji commented Aug 9, 2022

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

次バージョン(v2.1.0)で利用開始予定のV3DiagnosisApiを通じた陽性登録から診断キーの生成までの一連の流れを確認したところ、V3DiagnosisApiを通じて診断キーを生成したケースで、診断日・検査日から2日前までよりさらに古い期間(4日前から3日前)の診断キーを配信していることがわかった。

陽性情報登録は、次の内容で行った。

陽性情報登録で送信した日次キー 診断日 2022/08/08

"2022/08/09 16:48:35","Info","TemporaryExposureKey count: 12","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","53","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: RollingStartIntervalNumber: 2765088(1659052800), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: nHBV+tSftldTB4Fc1g6AEA== RollingStartIntervalNumber: 2765232(1659139200), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: rIXssHIci+HYJP8thjZGcQ== RollingStartIntervalNumber: 2765376(1659225600), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: jxpl6EGp9MqQQRphU76Alg== RollingStartIntervalNumber: 2765520(1659312000), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: ryMSJayZAHr34w1dBPrCOw== RollingStartIntervalNumber: 2765664(1659398400), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: l8nizj5f9ypNueOG0UixZw== RollingStartIntervalNumber: 2765808(1659484800), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: yL5odjPCIgjYjsZBoRKp6A== RollingStartIntervalNumber: 2765952(1659571200), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: lzqQIOd5P+sAfs9vQhJp2w== RollingStartIntervalNumber: 2766096(1659657600), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: gGF4P4WOTWwcZYC8/L1qfQ== RollingStartIntervalNumber: 2766240(1659744000), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: hoDNk2rDynp/AnT9N/+nSQ== RollingStartIntervalNumber: 2766384(1659830400), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: qbNdXj8dageaL+1AnBb9mQ== RollingStartIntervalNumber: 2766528(1659916800), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"
"2022/08/09 16:48:35","Info","TemporaryExposureKey: 4TkVuc+eiIV3PnuoBFq3sw== RollingStartIntervalNumber: 2766672(1660003200), RollingPeriod: 144, RiskLevel: Invalid","SubmitDiagnosisKeysAsync","/Users/keiji_ariyama/Projects/cocoa/Covid19Radar/Covid19Radar/Services/DiagnosisKeyRegisterServer.cs","56","Android","12","Pixel 3","Physical","APP_VERSION","5"

生成された診断キーは次の通り。

生成された診断キー
  • 1282.zip
    • created: 2022-08-09 20:00:11.966000+09:00 (1660042811966)
    • start_timestamp: 2022-08-04 09:00:00+09:00 (1659571200)
    • end_timestamp: 2022-08-05 09:00:00+09:00 (1659657600)
    • region: 440
    • batch_num: 1
    • batch_size: 1
    • 1 keys:
      • Index 0
        • type: v2
        • key_data: yL5odjPCIgjYjsZBoRKp6A==
        • transmission_risk_level: RISK_LEVEL_MEDIUM
        • rolling_start_interval_number: 2765952
        • rolling_period: 144
        • report_type: confirmedTest
        • days_since_onset_of_symptoms: -3
    • 0 revised_keys:
  • 1283.zip
    • created: 2022-08-09 20:00:14.838000+09:00 (1660042814838)
    • start_timestamp: 2022-08-05 09:00:00+09:00 (1659657600)
    • end_timestamp: 2022-08-06 09:00:00+09:00 (1659744000)
    • region: 440
    • batch_num: 1
    • batch_size: 1
    • 1 keys:
      • Index 0
        • type: v2
        • key_data: lzqQIOd5P+sAfs9vQhJp2w==
        • transmission_risk_level: RISK_LEVEL_MEDIUM
        • rolling_start_interval_number: 2766096
        • rolling_period: 144
        • report_type: confirmedTest
        • days_since_onset_of_symptoms: -2
    • 0 revised_keys:
  • 1284.zip
    • created: 2022-08-09 20:00:14.895000+09:00 (1660042814895)
    • start_timestamp: 2022-08-06 09:00:00+09:00 (1659744000)
    • end_timestamp: 2022-08-07 09:00:00+09:00 (1659830400)
    • region: 440
    • batch_num: 1
    • batch_size: 1
    • 1 keys:
      • Index 0
        • type: v2
        • key_data: gGF4P4WOTWwcZYC8/L1qfQ==
        • transmission_risk_level: RISK_LEVEL_MEDIUM
        • rolling_start_interval_number: 2766240
        • rolling_period: 144
        • report_type: confirmedTest
        • days_since_onset_of_symptoms: -1
    • 0 revised_keys:
  • 1285.zip
    • created: 2022-08-09 20:00:15.030000+09:00 (1660042815030)
    • start_timestamp: 2022-08-07 09:00:00+09:00 (1659830400)
    • end_timestamp: 2022-08-08 09:00:00+09:00 (1659916800)
    • region: 440
    • batch_num: 1
    • batch_size: 1
    • 1 keys:
      • Index 0
        • type: v2
        • key_data: hoDNk2rDynp/AnT9N/+nSQ==
        • transmission_risk_level: RISK_LEVEL_MEDIUM
        • rolling_start_interval_number: 2766384
        • rolling_period: 144
        • report_type: confirmedTest
        • days_since_onset_of_symptoms: 0
    • 0 revised_keys:
  • 1286.zip
    • created: 2022-08-09 20:00:15.081000+09:00 (1660042815081)
    • start_timestamp: 2022-08-08 09:00:00+09:00 (1659916800)
    • end_timestamp: 2022-08-09 09:00:00+09:00 (1660003200)
    • region: 440
    • batch_num: 1
    • batch_size: 1
    • 1 keys:
      • Index 0
        • type: v2
        • key_data: qbNdXj8dageaL+1AnBb9mQ==
        • transmission_risk_level: RISK_LEVEL_MEDIUM
        • rolling_start_interval_number: 2766528
        • rolling_period: 144
        • report_type: confirmedTest
        • days_since_onset_of_symptoms: 1
    • 0 revised_keys:
  • 1287.zip
    • created: 2022-08-09 20:00:15.231000+09:00 (1660042815231)
    • start_timestamp: 2022-08-09 09:00:00+09:00 (1660003200)
    • end_timestamp: 2022-08-10 09:00:00+09:00 (1660089600)
    • region: 440
    • batch_num: 1
    • batch_size: 1
    • 1 keys:
      • Index 0
        • type: v2
        • key_data: 4TkVuc+eiIV3PnuoBFq3sw==
        • transmission_risk_level: RISK_LEVEL_MEDIUM
        • rolling_start_interval_number: 2766672
        • rolling_period: 144
        • report_type: confirmedTest
        • days_since_onset_of_symptoms: 2
    • 0 revised_keys:

days_since_onset_of_symptoms が -3 の診断キーが配信されているが、これの示す範囲が  2022-08-04 09:00:00+09:00 から 08-05 09:00:00+09:00 。利用者として設定した診断日または検査日は8月8日なので、8月6日が含まれる日から配信されなければおかしい。

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

サーバー側の環境変数設定 "InfectiousFilterDaysSinceOnsetOfSymptomsFrom" と "InfectiousFilterDaysSinceTestFrom" をそれぞれ -2 に修正することで対応できると考える。

"InfectiousFilterDaysSinceOnsetOfSymptomsFrom": -3,
"InfectiousFilterDaysSinceOnsetOfSymptomsTo": 10,
"InfectiousFilterDaysSinceTestFrom": -3,
"InfectiousFilterDaysSinceTestTo": 7

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

サーバー側の環境変数設定ではなく、ExposureConfigurationのinfectiousness_for_days_since_onset_of_symptoms-3に対応する値を 0(感染性なし)に設定することでも対応可能。

その他 / Additional context

V3DiagnosisApiは現在までのバージョンでは利用されていない。
次バージョン(COCOA v2.1.0)で利用を開始する予定。


Internal IDs:

  • Bug 8498
@keiji keiji added the waiting-for-confirmation 関係者に確認中のもの label Aug 9, 2022
@keiji
Copy link
Collaborator Author

keiji commented Aug 9, 2022

これ InfectiousFilterDaysSinceOnsetOfSymptomsToInfectiousFilterDaysSinceTestTo も本当にこの値でいいのか。再確認した方がよさそう。

設定ファイルに分離しておいて良かったけど、つくづく時差がうらめしい。

@keiji keiji added the bug バグ。本来あるべき動作をしていないもの label Aug 9, 2022
@keiji
Copy link
Collaborator Author

keiji commented Aug 10, 2022

確認の結果、発症日は0日目で良いとのことでした。
ただ、時差を考慮して7日・10日をすべて含む形にするのに7・10の値でいいかは、やはり検討する必要があります。


InfectiousFilterDaysSinceOnsetOfSymptomsToInfectiousFilterDaysSinceTestTo の値の確認を進める上で、プログラム上は「発症日または検査日」を「0日目」と置いているけれど、厚生労働省が示す7日・10日は発症日を「1日目」として計算することがわかった。

days_since_onset_of_symptoms は接触通知APIの設定値なので「発症日または検査日」を「0」とすることは変えず、代わりにInfectiousFilterDaysSinceOnsetOfSymptomsToInfectiousFilterDaysSinceTestTo それぞれの値から1日引いて 6・9日とすることで対応することを検討する。

@kvaluation
Copy link
Contributor

時差がうらめしいことにつき、全面的に同意します。が、代替案は見つかりません。

■経緯 1.2.1から、陽性登録時に、発症日又は検査日が入力される。
https://www.mhlw.go.jp/content/10906000/000705649.pdf

「診断日」ではないという理解でよいでしょうか?

■2日前
もともと、COCOAで通知される接触が濃厚接触に区分し得ると想定されていた初期には、COCOAの要件を濃厚接触の定義と同様とする必要があったかと思います。
感染症法15条の「積極的疫学調査」で、国立感染症研究所による「新型コロナウイルス感染症患者に対する積極的疫学調査実施要領」に定義等があるかと思います。
https://www.niid.go.jp/niid/ja/2019-ncov/2559-cfeir/10800-covid19-02.html

「患者(確定例)の感染可能期間」とは、患者(確定例)が他者に新型コロナウイルスを感染させる可能性が あると考えられる期間であり、現時点の知見を踏まえ本稿では、発熱及び咳・呼吸困難などの急性の呼吸 器症状を含めた新型コロナウイルス感染症を疑う症状(以下参照)を呈した 2 日前から退院又は宿泊療 養・自宅療養の解除の基準を満たすまでの期間とする。

無症状の場合は、検体採取日から2日前。

■COCOAで通知を受けた者
2020年8月 事務連絡 新型コロナウイルス感染症に係る行政検査に関するQ&Aについて(その3) 問9
https://www.mhlw.go.jp/content/000661726.pdf
のころから(14日間の経過観察が必要な)「濃厚接触者」として取り扱うことはしない、とされてます。

上記積極的疫学調査実施要領では、
「利用者がお互いにはわからない形で 1 メートル以内 15 分以上 の近接を記録する」
「同アプリにより通知を受け取った場合は、患者(確定例)との一定の近接状態があったことを示すが、マスクや 会話の有無を捕捉できるものではない。」
と、特段定義を発見できない「近接状態」であるとされています。

COCOAの通知対象を発症日から2日前にしなければならない明文の根拠は、私は発見できませんでした。どこかにあるのでしょうか。

■1 発症日
 発症日ですと午前0時の発症や朝の8時30分の発症などもありえて、これはUTCで前日でしょうか。その2日前は、日本時間の配信日の3日前にもなりますが、基準がローカル時間ではないのかもしれず、良く判りません。3日前までにしておくのは安全な気もします。

■2 ExposureConfiguration
 ExposureConfigurationのinfectiousness_for_days_since_onset_of_symptomsの -3 に対応する値は、いま0ではなく2ですね。これが正しければ、サーバー側で古い診断キーをアップしても正常動作するように思います。

■3 近接状態を自由に定義できるなら
 和歌山県福祉保健部技監 野尻孝子「新型コロナウイルス感染者が他者に感染させたと推定されるタイミング(推定)」
https://www.pref.wakayama.lg.jp/prefg/041200/d00203179_d/fil/kouhyou14.pdf
 もっと新しいデータがあるかも知れませんが、この資料のスライドp.19には、発症2日前のみならず4日前にも感染していることが示されています。積極的疫学調査で4日前までたどるのは難しさがありますが、COCOAであれば問題無く記録されているので、COCOAならではとして通知対象にするような議論もありえるかなと思います。
 そうすると、ExposureConfigurationで制御できた方が、ご議論の結論から俊敏に対応できそうです。

@keiji
Copy link
Collaborator Author

keiji commented Aug 11, 2022

ありがとうございます。発症日または検査日を0日目として、

日本時間で2日前の00:00から24:00をカバーする。
有症状であれば、日本時間で10日後の00:00から24:00をカバーする。
無症状であれば、日本時間で7日後の00:00から24:00をカバーする。

というパラメーターを設定する予定です。一応、論理的にこの値というのはもうありますが、念のため設定した上で診断キーの生成までやってみます。

@cocoa-dev008 cocoa-dev008 added confirmed 開発内部管理用 and removed waiting-for-confirmation 関係者に確認中のもの labels Aug 15, 2022
@keiji
Copy link
Collaborator Author

keiji commented Aug 15, 2022

この設定で提案を進めます(決定したわけではありません)。

 "InfectiousFilterDaysSinceOnsetOfSymptomsFrom": -2, 
 "InfectiousFilterDaysSinceOnsetOfSymptomsTo": 11, 
 "InfectiousFilterDaysSinceTestFrom": -2, 
 "InfectiousFilterDaysSinceTestTo": 8 

「発症日または診断日」を 2022-08-10(日本標準時)と置き、
感染可能性のある期間始期については「発症日または診断日」の2日前「2022-08-08 00:00:00(日本標準時)」を含むように。
有症状の場合の療養終了日(この言い方が正しいかはわからない)については「発症日または診断日」から10日後が終わる時点「2022-08-20 23:59:59(日本標準時)」を含むように。
無症状の場合の療養終了日については「発症日または診断日」から7日後が終わる時点「2022-08-17 23:59:59(日本標準時)」を含むように。

それぞれ日次キーの日時情報(協定世界時)に割り当てたときのDaysSinceOnsetOfSymptomsを導きました。

days_since_onset_of_symptoms0
days_since_onset_of_symptoms1
days_since_onset_of_symptoms2
days_since_onset_of_symptoms3
days_since_onset_of_symptoms4

@kvaluation
Copy link
Contributor

@keiji 図示をありがとうございます。
発症日又は検体採取日が8月8日(日本時間)のときに、2022-08-04 09:00:00+09:00 から24時間に、なり得たことが分かりました。

動作として問題はないと思うのですが、時刻なしの日付入力に対して、なぜそのような振る舞いなのかは、良く判りませんでした。

図示のケースで、

"InfectiousFilterDaysSinceOnsetOfSymptomsFrom": -2

のとき、陽性登録の時刻に応じて、

 日本時間で8/6と8/7の場合があるのか、

 それとも、
   発症日の日本時間での日付を日本時間で0時として、

   UTC で2022-08-10 09:00:00+00:00 ではなく
   UTC で2022-08-10 00:00:00+00:00 になっていて、

 引用の-2が、UTCで 2022-08-06 と「常に」なるのか、

または、診断キーの照合時から-2で、照合時刻に応じて-2の対応日が日本時間で両日ありえるのか、

などです。

@keiji
Copy link
Collaborator Author

keiji commented Aug 16, 2022

動作として問題はないと思うのですが、時刻なしの日付入力に対して、なぜそのような振る舞いなのかは、良く判りませんでした。

時刻なしの日付入力に対して、どの時刻を当てるか。と言う話だと思います。

やりたいこととして、診断日または検査日に「日本時間の8月10日」を入力する例では、
日本時間の8月10日の00時00分を基準として、

日本時間の8月8日の00時00分から、
日本時間の8月17日の23時59分59秒 または 日本時間の8月20日の23時59分59秒 まで。

の期間をカバーする日次キーを選択する。と言うことです。

この挙動を実現するために提案したのが上記の値です。

@b-wind
Copy link

b-wind commented Aug 16, 2022

対象期間の話なので、特定「時刻」に注目してしまうと混乱してしまいそうですね。

前提として「診断日または検査日」における時刻はおおよそ 00:00:00(JST) 〜 24:00:00(JST) が想定されますが、
診断キーの配信基準を定めるに当たって 時刻は特に考慮しないもの として扱うようです。
実際「診断日または検査日」及びその時間自体は区切りに使用しないのでこの扱いで問題無いものと思います。

@b-wind
Copy link

b-wind commented Aug 16, 2022

一方、範囲の開始時間としては本来2日前の 00:00:00(JST) 〜 10日後の 24:00:00(JST) を扱いたい様に見えます。
これは、DaysSinceOnsetOfSymptoms が 00:00:00(UST) を起点とする24時間区切りの時間単位であるためにどうしても正確には扱えないという理解です。

ここで2つの選択肢が出てきます。

  1. 本来意図しないデータが含まれても良いので幅広く時間間隔を定める。
  2. 意図しないデータを全く含まないために短い時間感覚を定める。

ここでは 1. の選択がなされているようです。

この為、DaysSinceOnsetOfSymptoms を -2 〜 +11 の物を対象とし、診断日または検査日を 8/10 と置いた場合以下の期間が対象になります。

8/8 00:00:00(UTC) 〜 8/19 24:00:00(UTC)

これは日本時間に表すと、以下の様になります。

8/7 15:00:00(JST) 〜 8/20 15:00:00(JST)

本来指定したい期間の前9時間と後15時間(合計24時間)の情報が余分に含まれる可能性がありますが、できる限りでの最小の誤差という感じでしょうか。

@b-wind
Copy link

b-wind commented Aug 16, 2022

注) 便宜上一日の終わりを 24:00:00 と表記していますが、正確にはその時刻自体は含まないものと読んで頂ければ。

@b-wind
Copy link

b-wind commented Aug 19, 2022

基準となる日付として 8/10 を設定した場合、DaysSinceOnsetOfSymptoms の値が 0 の場合の期間として、

  • 8/10 00:00:00(JST) 〜 24:00:00(JST)

となるのが理想であるが、前述の通りJSTでの指定は出来ない。

この場合、UST における対応する期間として以下の2パターンが想定されうる。

  1. 8/09 00:00:00(UTC) 〜 24:00:00(UTC)
  2. 8/10 00:00:00(UTC) 〜 24:00:00(UTC)

現状では 1. を採用している様であるけれど、 2. を採用するケースと比べて重複する時間が少ないようにも思える。

DaysSinceOnsetOfSymptoms をどのように想定すればいいかはドキュメント等からは読み切れないですね。

@keiji
Copy link
Collaborator Author

keiji commented Aug 20, 2022

DaysSinceOnsetOfSymptoms は日にちに応じて感染性を事細かに切り替えたいときに使うのですが、いまの運用だと0日目をどこに取るかより、始期と終期を日本時間に当てはめてどこにするかが大事に思います。

0日目として0-9時を取るか9-24時を取るか。少なくとも「0日目」「1日目」「-1日目」の感染性が変わらない現状ではあまり検討する意義はないと思います。仮に将来0, 1, -1で感染性が細かく変わることがあれば、そのときは現在のマップをベースに、それぞれ値を設定する流れになると考えています。

@b-wind
Copy link

b-wind commented Aug 20, 2022

DaysSinceOnsetOfSymptoms は日にちに応じて感染性を事細かに切り替えたいときに使うのですが、いまの運用だと0日目をどこに取るかより、始期と終期を日本時間に当てはめてどこにするかが大事に思います。

御意。
そのような判断があった上での設定なのですね。

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug バグ。本来あるべき動作をしていないもの confirmed 開発内部管理用
Projects
None yet
Development

No branches or pull requests

4 participants