EN2 対応にあたっての検討事項

[tmurakami]

以下に COCOA の EN v2/ExposureWindow mode (以降 EN2、旧 API は EN1 と表記) 対応に関して、何らかの検討・対応が必要だと思われる点を列挙します。
すでに開発側で検討中・対応中の内容もあるかと思いますが、ご容赦下さい。

※ このような形で Discussion を使って良いものかわからないので、問題があればお手数ですがご指摘下さい。

[tmurakami]

TEK の days_since_onset_of_symptoms の設定

現在の TEK フォーマット には以下の項目が追加されています。

• TemporaryExposureKeyExport

  • revised_keys

• TemporaryExposureKey

  • report_type
  • days_since_onset_of_symptoms

ここでは TemporaryExposureKey の days_since_onset_of_symptoms について取りあげます。

days_since_onset_of_symptoms はコメントにある通り、発症日からの経過日数を示す項目です。

// Number of days elapsed between symptom onset and the TEK being used.
// E.g. 2 means TEK is 2 days after onset of symptoms.

そしてこの値は、経過日数と感染力のマップ (Android ならば DiagnosisKeysDataMapping、iOS ならば ENExposureConfiguration.infectiousnessForDaysSinceOnsetOfSymptoms) から感染力を確定させるために必要なのだと思います。

COCOA の場合、現状 HER-SYS から発症日 (もしくは検査日) を取得することができないようなので、当該項目を埋めるには陽性登録時に COCOA 利用者が入力した発症日 (もしくは検査日) を元に計算した結果をサーバーに送る必要があります。
また、経過日数を含んだ TEK を配信する必要もあります。
ですので、COCOA アプリ側だけではなくサーバー側でも、例えば V3DiagnosisApi の追加や TemporaryExposureKeyExportFileFormat.proto 等のアップデート (とそれに伴なう改修) といった作業が必要になるものと思われます。

もちろん、当該項目がない場合のフォールバックがあるにはある (Android ならば DiagnosisKeysDataMapping.getInfectiousnessWhenDaysSinceOnsetMissing()、iOS ならば ENDaysSinceOnsetOfSymptomsUnknown) のですが、iOS の ENDaysSinceOnsetOfSymptomsUnknown は deprecated なので、きちんと対応したほうが良いのだろうと思います。
※ 適当に filename:ENCommon.h API_DEPRECATED ENDaysSinceOnsetOfSymptomsUnknown で GitHub 検索すると、API_DEPRECATED( "Server must provide keys with days_since_onset_of_symptoms set.", ios( 14.0, 14.2 ) ) と出てきたりします。

EN1 で当該項目を含んだ TEK を使った接触チェックに問題がないかどうかの検証も必要かもしれません。
(ついでに言うと、EN2 でのリスク計算と同等のことを EN1 でやるとなると transmission_risk_level を使って感染力を表現する、といった対応も必要になってくるかもしれません)

[tmurakami]

@kvaluation

2021/8/10, -2
2021/8/11, -1
2021/8/12, 0
2021/8/13, 1
2021/8/14, 2 (陽性登録日の前日のTEKまでの場合)

EN API では時刻はすべて UTC です。
COCOA ではまるまる2日をカバーするために、UTC で2日+21時間をとっている (これは　

cocoa/Covid19Radar/Tests/Covid19Radar.UnitTests/Services/ExposureNotificationServiceTests.cs

Line 64 in 55277b0

public void FliterTemporaryExposureKeysTests_Success(string diagnosisDateTest, int expectedCount, string expectedFirst, string expedtedLast)

から判断できる) ようなので

2021/08/09 9時-33時　-3
2021/08/10 9時-33時　-2
2021/08/11 9時-33時　-1
2021/08/12 9時-33時　 0
2021/08/13 9時-33時　 1
2021/08/14 9時-33時　 2 (陽性登録日の前日のTEKまでの場合)

となるのではないかと思います。

[tmurakami]

@keiji

days_since_onset_of_symptoms のフォールバックが難しいということになると、COCOA サーバー側の DiagnosisApi の扱いをどうするのか決める必要かあるように思います。

現在、陽性登録ファンクションには

• DiagnosisApi
• V2DiagnosisApi

の2つがあり、V2 が追加されたのは 2021/02/17 です。つまり V2 は 2020/12/15 リリースの COCOA v1.2.1
https://www.mhlw.go.jp/stf/newpage_15512.html

今回の修正版では、保健所による積極的疫学調査との整合性を図る観点から、陽性者との接触の可能性について本アプリで通知を行う対象期間を、保健所が行う積極的疫学調査において濃厚接触者の探索を行う期間にあわせる改修を行いました。

のあとに作られたものなので、V2 では単純に TEK を rolling_start_interval_number の昇順で並べて days_since_onset_of_symptoms を設定することができそうですが、より古い DiagnosisApi に関しては、過去14日の TEK
が送信される可能性があるのでサーバー側の改修だけではうまく行かなそうです。

これらの移行をどうするか考える必要がありそうです。

ちなみに私がおすすめするのは DiagnosisApi をエラーにして、広報でアップデートを促す方法です。
(DiagnosisApi のステータスコードでアップデートを促すことができれば良いのですけど)

[keiji]

古いCOCOAからのDiagnosisApi宛ての陽性情報登録はエラーにして「最新のCOCOAにアップデートしてくださいとダイアログを出す」とか、そういったダイアログを起動直後に出す（アップデート強制）と言うことですね。とはいえ、今からそういった挙動を仕込んでも、それが反映される人はきっと自動アップデートしてくれているのではないかという気もします。

まずは現状DiagnosisApiがどの程度使われている実績があるのか、そういった情報を開発チームが持っているか確認します。

[kvaluation]

keiji/en-calibration-server#2
Missing系で想定と異なる挙動（ keiji/chino#108 ）が確認された（略）。

値が必要との検証、ありがとうございます。バグになるところでしたね。Googleの配慮不足に気付けて良かったです。

新型コロナウイルス感染症　COVID-19　診療の手引き　6.0版
https://www.mhlw.go.jp/content/000825864.pdf ←リンク切れを2021年11月11日に確認
https://www.mhlw.go.jp/content/000851077.pdf ←2021年11月11日に追記。頁番号は同じ

p.67退院基準で無症状者は「検体採取日」から10日なので、現状と同様検査日をいれておくとよいでしょうか。

検査日もなければ、アドバイザリーボードの資料だと診断確定日の2日前ぐらいが中央値のようで、さらに処理番号発行までの期間分を追加する感じでしょうか。どんな決めになっても、引き続き考え方を開示しておけると良いかと思います。

[keiji]

Googleの配慮不足ではなく、単純にぼくの検討が足りなかった。検証によりよりクリアになったと言うことですね。

v2DiagnosisKeyのまま何らかの手段でmissing扱いにできる可能性もあるので、引き続き検証をしていきます。

検体採取日を基準日とするとしてInfectousnessをどうするかなと言ったところです。

このあたりは最終的には感染症の専門家に確認して決定することになると思われます。
アプリサイドでは、最後に決まったときにサクッと割り当てて、また必要に応じて変更できる仕組みを作るのが妥当かと考えます。

[tmurakami]

取得できる接触情報リストの内容確認

Android の ExposureNotificationClient.getDailySummaries() 及び getExposureWindows()、iOS の ENExposureDetectionSummary.daySummaries 及び ENManager.getExposureWindows() で取得できる各接触情報リストの内容について。

Android については、過去 14 日間に token 無しの provideDiagnosisKeys() を実行して得られた 14 日分の全接触情報を含んだリストが帰ってくるのではないかと思っています。
理由ですが、まず token 有りの provideDiagnosisKeys() のドキュメントでは、同じ token を使い回すと接触情報を連結できる旨の記載があります。
https://developers.google.com/android/reference/com/google/android/gms/nearby/exposurenotification/ExposureNotificationClient#provideDiagnosisKeys(java.util.List%3Cjava.io.File%3E,%20com.google.android.gms.nearby.exposurenotification.ExposureConfiguration,%20java.lang.String)

A unique token for this batch can also be provided, which will be used to associate the matches with this request as part of getExposureSummary(String) and getExposureInformation(String). Alternatively, the same token can be passed in multiple times to concatenate results.

そして、token 無しの provideDiagnosisKeys() では内部的に ExposureNotificationClient.TOKEN_A を使っています。
つまり token 無しの provideDiagnosisKeys() 呼び出しは、実質的に provideDiagnosisKeys(keyFiles, new ExposureConfigurationBuilder().build(), ExposureNotificationClient.TOKEN_A) と同じです。

ですので、そのことを踏まえた改修が必要になるのではないかと思っています。
例えば exposure-notifications-android では前回の結果と比較して違いがあればプッシュ通知しているようです。
https://github.com/google/exposure-notifications-android/blob/610788eb3815d8ddb397332ba6f982308f7cde01/app/src/main/java/com/google/android/apps/exposurenotification/nearby/StateUpdatedWorker.java#L132-L133
さらに、接触情報 (ExposureEntity) のリストを delete insert していたりします。
https://github.com/google/exposure-notifications-android/blob/610788eb3815d8ddb397332ba6f982308f7cde01/app/src/main/java/com/google/android/apps/exposurenotification/nearby/StateUpdatedWorker.java#L299
https://github.com/google/exposure-notifications-android/blob/610788eb3815d8ddb397332ba6f982308f7cde01/app/src/main/java/com/google/android/apps/exposurenotification/storage/ExposureDao.java#L52-L55

iOS についてはよくわかりません。
ENExposureDetectionSummary は detectExposures() を呼び出して得られるオブジェクトなので、 detectExposures() に渡したキーリストと 1:1 で紐付いているのかもしれませんが、daySummaries は過去にチェックした全接触情報を含んでいるのかもしれません。

これらを呼び出した結果得られるリストはどういった内容なのか、(検証するにしても) 念のため Apple/Google に問い合わせておいたほうが良いのかもしれません。

[tmurakami]

当日キーの扱い

関連： #333

Android の ExposureNotificationClient.getTemporaryExposureKeyHistory()、iOS の ENManager.getDiagnosisKeys() について。

まず iOS についてですが、以下のコメントの通り、ENAPIVersion が 2 の場合は rolling period が 144 未満のキー (以降当日キー) が取れるようです。
https://developer.apple.com/documentation/exposurenotification/enmanager/3583725-getdiagnosiskeys

When ENAPIVersion is set to 2, this call returns a diagnosis key with a shortened rolling period.

Android に関しては、v1.7 で当日キーが取得できるようになっていますが、当該機能を有効にするには Google に依頼する必要がありそうです。
https://developers.google.com/android/exposure-notifications/exposure-notifications-api#gettemporaryexposurekeyhistory

In v1.7 and higher: Allowlisted apps support returning keys that include the current day’s key, which is tagged with an expiration date (rollingPeriod). When the current key is released, the device stops using it to generate BLE beacons, and replaces it with a new key. Calling this causes a new key to be selected for the remainder of the current day. As a result, if this method is called multiple times, several keys with different rollingPeriod and identical rollingStartNumber can be released for those days it was called on. To enable this feature, contact your Google representative.

纏めると

Android

• v1.6 までは前日までのキー (rolling period が 144)
• v1.7 以降は当日キー (但し Google への依頼が必要？)

iOS

• OS バージョン 13.5/13.6 または ENAPIVersion が 1 の場合は前日までのキー
• OS バージョン 12.5/13.7+ かつENAPIVersion が 2 の場合は当日キー

が取得できる、ということになるのかと思います。

ちなみに、iOS の getTestDiagnosisKeys() はテスト用なので、リリース版では使用できません。
https://developer.apple.com/documentation/exposurenotification/enmanager/3586333-gettestdiagnosiskeys#discussion

Warning

This method is only for developers while testing, and requires a special entitlement that is not allowed in the App Store. It’s only intended for testing without needing to wait 24 hours for a key to be released.

可能であれば、EN1 (リリース版)でも rolling period が 144 未満の TEK を受けつけることができるのかの検証はしておいたほうが良いのかもしれません。

[tmurakami]

レポートタイプの決定

関連： #26

レポートタイプの分類は以下のとおりです。

	Android (ReportType)	iOS (ENDiagnosisReportType)
confirmed_clinical_diagnosis	CONFIRMED_CLINICAL_DIAGNOSIS	confirmedClinicalDiagnosis
confirmed_test	CONFIRMED_TEST	confirmedTest
self_report	SELF_REPORT	selfReported
revoked	REVOKED	revoked
recursive	RECURSIVE	recursive
unknown	UNKNOWN	unknown

unknown を除いた 5 つのうち、recursive は未使用、revoked は取り消し、self_report は例えば検査キットを購入して陽性になった場合なんかに使えるとは思いますが、現状そのようなケースを想定していないと思うので、confirmed_clinical_diagnosis、confirmed_test のどちらかから選ぶことになるのだろうと思います。

この 2 つのうち、確度の高いレポートタイプは恐らく confirmed_test です。
revoked で取り消すことができるレポートタイプが self_report と confirmed_clinical_diagnosis だけであり、confirmed_test は取り消すことができないことから、そのように判断しました。
https://developer.apple.com/documentation/exposurenotification/endiagnosisreporttype/revoked#discussion

This case negates a previous self report or clinical diagnosis that may have been in error.

https://developers.google.com/android/exposure-notifications/exposure-notifications-api#data-structures

The following transitions are supported:

SELF_REPORT -> CONFIRMED_TEST, CONFIRMED_CLINICAL_DIAGNOSIS, REVOKED
CONFIRMED_CLINICAL_DIAGNOSIS -> CONFIRMED_TEST, REVOKED

ここで積極的疫学調査実施実施要領を見てみると、当該ドキュメント P2 の「用語の定義・解説」にて、以下の記載があります。
(PDF 注意)
https://www.niid.go.jp/niid/images/epi/corona/COVID19-02-210108.pdf

●「患者（確定例）」とは、「新型コロナウイルス感染症の臨床的特徴を有し、かつ、検査により新型コロナウイルス感染症と診断された者」を指す。
●「無症状病原体保有者」とは、「臨床的特徴を呈していないが、検査により新型コロナウイルスを保有していることが確認された者」を指す。
●「疑似症患者」とは、「臨床的特徴等から医師が新型コロナウイルス感染症を疑うが、新型コロナウイルス感染症の確定診断が得られていない者」を指す。

これらに対して、素直にレポートタイプを割り当てるとするならば

• 患者（確定例）: confirmed_test
• 無症状病原体保有者: confirmed_test
• 疑似症患者: confirmed_clinical_diagnosis

となるように思いますが、いかがでしょうか？

ちなみに、P2 の「濃厚接触者」の説明には

「患者（確定例）」（「無症状病原体保有者」を含む。以下同じ。）

とあり、次ページ P3 の COCOA の説明にて

同アプリの利用者が患者（確定例）となった場合に、当該患者（確定例）の同意に基づいて同アプリに登録することで、当該患者（確定例）と接触した同アプリ利用者が通知を受け取ることができる。

とあることから、この記述に従うのであれば、現状「患者（確定例）」「無症状病原体保有者」だけを考えれば良いのかもしれません。

もちろんレポートタイプをどのように扱うのかは各国・地域の保健当局に委ねられているのだろうとは思いますが、Apple/Google の思想としてそのように想定されているのであれば、それに従うのが良いのではないかと思います。

[tmurakami]

EN1 のサポートを継続するのかどうか

まず Android に関しては、ほとんどの端末の EN バージョンは v1.8 だろうと思うので、EN2 のみで良いのかなと思います。
(EN バージョン自体は [端末設定] -> [COVID-19 接触通知システム] で確認できます)

iOS については OS バージョン 13.5/13.6 のサポートをどうするか、という話になるかと思います。
少なくとも 13.5 に関しては 問④－10 で問題がある旨を公表しているので、(EN1 サポートを継続するとしても) OS アップデートを促すメッセージ等をアプリで表示すると優しいのかなと思っています。

ちなみに EN2 利用可否は以下の条件で判断できるかと思います。

Android
ExposureNotificationClient.getVersion() の結果の上位二桁が 16 以上 (getVersion() が利用できるのは v1.6 から)
※ ExposureNotificationClient.getStatus() を使うのであれば 17 以上
https://developers.google.com/android/exposure-notifications/release-notes#new_getstatus_method
※ Preauthorization API を使うのであれば 18 以上
https://developers.google.com/android/exposure-notifications/release-notes#preauthorization_of_tek_release

iOS
ENAPIVersion が 2 かつ OS バージョンが 12.5/13.7+
※ Preauthorization API を使うのであれば OS バージョンが 14.4+
https://developer.apple.com/documentation/exposurenotification/enmanager/3644440-preauthorizediagnosiskeys

[yoshitomo-g]

Appleが公開しているアップデートリストによると、13.x・14.x・15.x のどれも iPhone 6s 以降の対応になっています。ストレージ不足やどうしても必要なアプリが対応していないなどの理由がない限りは、アップデートできないということはないと思います。
https://support.apple.com/ja-jp/HT201222

余談ですが、13系最後となる13.7の公開が2020年9月1日ですので、セキュリティの面からも14系または15系に移行するべきだと思います。

[daisuke-nogami]

ありがとうございます。

13.5/13.6がインストールされている端末は最新の15.xに更新可能である、という本意をお二人に補足していただけていますが、元々の記載が文章としては不適切でしたので修正いたします（修正した記録としてもcommentを残します）。

iOS 13.5/13.6の利用者が、EN2をサポートしている13.7 以降のiOS に移行することの障害もない

[b-wind]

ご返答ありがとうございます。

ご存じかとは思いますが、現時点でアップデート可能な対象としては iOS 14.8.1 および iOS 15.1 の二つのみです。
従来なら新バージョンが出た時点で過去バージョンのアップデートは（事実上）放棄されていましたが、iOS 15 から一つ前のメジャーバージョンも積極的なサポートを行う様になったようです。

懸念としては iOS のバージョン間互換は比較的低く、利用アプリケーションの都合で積極的にアップグレードしないユーザーが居る事です。
そのような選択をしたユーザーはCOCOAのサポート対象外と見なす、とも捉えられます。
どのような判断だったとして異議を唱えるつもりは全くないですが、そこまで含めて検討されているかどうかの確認をさせて戴きたいです。

[daisuke-nogami]

はい、iOSのバージョン間の互換性の低さ、特にメジャーバージョン間の互換性の低さは認識していて、その不利益からメジャーバージョンを上げないユーザが多いことも認識しています。
そのため、現在のリリース前のテスト指示では、COCOAがこれまで動作対象としてきたiOS13・14・15のいずれの系列でも動作することを担保するよう、 ユーザ数の大小にかかわらず 、リグレッションテストの対象にはiOS 13.7も残し続けていますし、この方針をv2移行時に変える予定はありません。

一方、マイナーバージョンについては、個人が 日頃持ち歩く 端末で特定のマイナーバージョンに固定しなければならない状況は非常に少ないと考えています。
COCOAのOSバージョン別デバイス数の推移をみても、

• メジャーバージョンが上がるとき：旧バージョンで様子見をするのは約半数のユーザ。様子見の期間も1-2ヶ月程度と長い。
• マイナーバージョンが上がるとき：旧バージョンで様子見をするのは1割程度。様子見の期間も半月から1ヶ月程度と短い。
  と明確に違いがみられています（この感覚は私の本業の方での経験からも同じ感覚です）。
  加えて、全てのマイナーバージョンをテスト対象とすると、テスト負荷が数倍に跳ね上がります。
  そのため、過去のメジャーバージョンにおいては、最終マイナーバージョンのみをテスト対象としています。

このような検討を踏まえて、冒頭の方針としております。

[b-wind]

質問の意を汲んで頂き、また明確かつ丁寧な返答を戴きありがとうございます。

また、ご返答戴いた内容からも十分な検討が行われている事が伺われ、得心しました。
重ねてお礼申し上げます。