HealthKitでヘルスケアレコードにアクセスする

（音楽）

（拍手） ヘルスチームの ジェイソン･モーリーです 同僚のペイトンと― iOS 12に搭載した新機能を これからご紹介します HealthKitです

今年の初め iOS 11.3で― ヘルスケアを紹介しました ユーザは医療機関から― ヘルスケアデータを安全かつ 速やかに入手し保管できます

複数の医療機関から データを集めて提供します 検査値や基準値など 重要なデータを― ユーザは検索できるのです 自分の体について 深く理解できます

500を超えるアメリカ国内の 病院や診療所と― 50を超える医療機関と 提携しています そして今も追加中です

HL７協会の標準規格が あったからこそー これが実現したのです

医療情報の 相互運用のためのリソース つまりFHIRとSMARTです

全ての始まりは健康です 医療機関と安全に接続し― デバイスにヘルスケアデータを 直接ダウンロードします

そしてHealthKitに保存し―

複数の機関のデータを集計します

iOS 12では― そのデータを利用できるよう APIを提供します

この機能をサポートする 新たなsampleTypeを紹介します 次にアプリケーションを承認し クエリを行う方法

そしてFHIRで何が可能になるか

最後に個人情報に関する― プライバシーの保護について 考えてみたいと思います

では始めましょう

HealthKitの使用経験があれば― HKSampleTypeをご存じでしょう 同じ種類のデータを グループ化します 例えばQuantityTypeは― 数値が主となるデータグループです 例えば歩数や心拍数などです 一方 CategoryTypeは 計測データです 睡眠時間や深さなどを測る 睡眠分析や 月経痛の程度が これ当たります

今回新しく紹介する HKClinicalTypeは― ヘルスケアレコードの分類です 体調や薬物治療を ヘルスケアで確認できます

データタイプは type identifierで区別されます

HKClinicalTypeIdentifierは― 一致するクリニカルタイプを 特定します

ここに挙げたように アレルギーや持病があります 妊娠のように期間が限られるもの ２型糖尿病のような治療中のもの

予防注射

毎年の健康診断での血糖値の結果

薬物治療

診断手順や外科手術歴 バイタルサイン つまり血圧や体重です

sampleTypeや sampleType identifierと― HKSampleのサブクラスを紹介します HKClinicalRecordです HealthKitのサンプルに 不慣れなら― それを補える講演や 詳細な資料を準備しています

HKClincalRecordには 重要なプロパティがあります

クリニカルタイプです これは与えられた記録を 定義するのに役立つのです 知りたいのは― 例えば予防注射の記録です

提供する表示名は― ユーザに記録を示す時に 使う文字列です FHIRで選択されます ユーザに分かりやすい表示名を 選びます

検査結果では― その代わりとなる表現が たくさんあります LOINCでの コーディングを含みます これは医療情報のための 標準基準で― FHIRに要求されます

LOINCでのコーディングと lookup関数で― 表示名として掲げる 正準名を提供します

そしてFHIRへのアクセスを 許可します HKClinicalRecordは とても有用です ですから この話は後で もう一度します

ヘルスケアデータの出どころや 元情報の全てがとても重要です 情報源を知りたいでしょう

HKSourceで 設計したHealthKitは― HKSampleで使用可能です

共有している医療機関の 名前を設定します そして複数のユーザに デバイスを介して― バンドルIDを提供します

以上が新しいsampleTypeです 次はアプリケーションの 承認方法です

ご覧のとおり医療記録の 情報量はかなり豊富です ユーザへ優れた提案をする いい機会です ヘルスケアデータを十分に 活用する機会を与えます

しかし ご承知のとおり これは個人情報を含みます

例えば服用中の薬の情報や― 日々の健康状態などです

親しい友人や家族でもあっても 共有を控える情報です 情報を医療機関と 相互利用するので― 新たな診断が つくかもしれません

アクセスやデータ管理を 容易にするため― ヘルスケアレコードの 承認フローを紹介します アプリケーションが 承認を求めると― クリニカルタイプ特有の 許可シートを提供します

情報の共有と その機密性について― ユーザに通知します

これは新たな承認フローです いつ依頼しても― そのタイミングを計り― 理解できるよう 十分な内容を伝えてください

その後 ユーザは 希望したカテゴリから― 共有するデータタイプを 選択できます

新しいpurpose stringや― プライバシーポリシーを 提供します ユーザに説明する絶好の機会です データにアクセスして 何をしたいのか データをどう守るか

自分の依頼が必要性と つり合っているか確認します 主要機能に関連性がなければ― ユーザは驚き 心配するはずです 最終的にユーザが医療機関と 情報交換するにあたって― 新しいデータの管理方法を 紹介します 新しいデータの共有前に 毎回 デフォルトで尋ねます

新しいデータを利用する時は― 常に許可シートの提示が必要です クエリを実行する場合は 事前の承認が必要です

では承認申請の方法を 案内します

HealthKitの経験者には おなじみのフローです まずプロジェクトを設定します

その後 承認依頼を行い― クエリを実行します

プロジェクト設定のため ヘルスケアレコードの―

Xcodeへの追加が必要です

それからHealth Records Usage Descriptionを― Info.plistに追加します

データを利用する理由を― ユーザに説明するいい機会です

この後 承認を依頼します

ここで アクセスするタイプを定義します 症状 予防注射 薬物治療

そしてHealthStoreで 承認を依頼します

エラーに対処した後は

クエリの実行です

ユーザの プライバシー保護のため― 彼らが許可または拒否する カテゴリを明かしません

次にクエリについて HKClinicalRecordは HKSampleなので― 既存のサンプルクエリ基盤を 利用できます AnchoredObjectQueryなどが 機能して― ユーザが連続呼び出しを 許可すると― バックグラウンドで作業します

クエリを実行したいタイプを 定義します

これはサンプルクエリです HealthStoreで実行できます

基本的な承認フローです ヘルスケアレコード特有の 追加のメカニズムを導入しました

Get Request Status for Authorizationは― 許可シートを提示する場合に 定義するAPIです

これによって― 承認シートの確認が ユーザに必要か決定し― コンテキスト提供のため 承認の前にUIを示します

そのためにHealthStoreで このAPIを呼び出し― エラーを処理します

依頼ステータスの要求により― 承認依頼の前に UIを示すことができます

アクセスを希望するデータには― 複数のタイプがあるかもしれません リサーチアプリケーションなら― 結果が偏らないよう 総合的なタイプが必要です

Info.plistの新たなキーで タイプを特定できます このタイプへのアクセスを 許可しなければ― 新しい要求タイプの エラーに戻ります そして対応方法を決定し このデータがなければ 続けられないと説明します

Info.plistに閲覧権限キーを 加えたら実行できます

アレルギー 症状 予防注射を 特定しています

そして新たなエラーを 処理します

これを賢く使い アプリケーション機能を― 限定しないでください 共有するデータ量にかかわらず 多くのユーザに― 恩恵を受けさせたいはずです

これが承認フローです 注目したい点があります データにアクセスしたいなら― まず毎回 承認依頼が必要です 新しいデータが入ると ユーザは承認シートを確認します ですので 許可シートを提示しましょう

必要なデータだけ 要求してください

最後に新しいAPIの利用を 検討してください コンテキストを提供し 承認のタイミングを計れます

では同僚のペイトンが― アプリケーションを紹介します ありがとう （拍手） ありがとう これは登山者向けの アプリケーションです HealthKitを使って― ウォーキングやハイキングを 管理します 広範囲に及ぶ市場調査の結果 登山者は山へ旅行する者だと 判断しました 旅行者は予防接種の状況を 知るべきです よって 推移特性により― 登山者は予防接種の状況を 知るべきです そのため 予防接種の ダッシュボードを制作中です タップしてみます

これがダッシュボードです ワクチンの接種状況が 表示されます 表示名で使うのは HKClinicalRecordsです ヘルスケアレコードの権限を 追加しました Purpose Stringを作って データの使用目的を示します ダッシュボードを実行します ImmunizationsViewControllerで タブが動きます アプリケーションを 使う時は常に― 承認依頼を出すことが基本です その点 viewWillAppearは 優れています

接種記録のサンプルに 興味があることを― ここで最初に明記します 次に―

requestAuthorizationを 呼び出します 成功したかどうかの確認や エラー処理をします

最終的に承認されたら― 接種メソッドに クエリを実行します

ここでサンプルクエリを作ります サンプルリターンを繰り返して― 私のデータソースへパスします

これがサンプルクエリです 接種記録のサンプルを使います

ユーザの全ての記録が要るので 属性はなし 同じ理由で― 制限もかけません 順番は問わないので ソートはしません 結果を確認し― エラーがあれば処理します 次にサンプルを繰り返し― 表示名で データソースにパスします

データソースの名前で― メインキューに飛びます そしてReload UIメソッドを 呼び出します

HealthStoreで サンプルクエリを実行します これで全部なので やってみましょう

トレーニングログが表示され 予防接種のタブをタップ 承認シートが提示されます データの使用方法を― ユーザに説明しています 続けてタップ 好みに従いカテゴリの 許可か拒否を選べます この画面にはPurpose Stringと プライバシーポリシーへの リンクも記載されています “全てを選択”ボタンはなく― カテゴリを一つ一つ 選択しなければなりません ではデモとして― 予防接種記録を共有します Ask Before Sharingを デフォルトで残し― “完了”をタップ

ユーザの全ての予防接種記録が 表示されます そして… （拍手） FHIRのおかげでより多くの 医療記録を引き出せます ジェイソンに代わります

ありがとう さて― アプリケーションでの 承認依頼の方法や― HKClinicalRecordの表示名の 利用方法が分かりました ユーザが知る方法で 情報提供が可能です

ではFHIRで何ができるのかを お伝えしましょう

ユーザは一生のうちで 複数の医療機関と関わります ですが医療記録システムが 異なることも多く― 必ずしも同じ手順で データを表せません 相互運用が難しい原因です

そこでArgonaut Projectが 開始されます JSONやOAuth 2.0を通じて― FHIRを 使用できるようにします 医療機関との安定した接続と 一般的な形式での― ダウンロードを可能にします そして複数の機関と関連づけます

FHIRはアレルギーから 処方箋までカバーする― ヘルスケアデータの 巨大な母集団です これをリソースと呼ばれる データに構造化します リソースには それぞれタイプがあり― 全ヘルスケアデータに該当します

選んだ８つのタイプは― Argonaut Projectで 定義されています これを７つの クリニカルタイプに分けます カテゴリに基づき“診察”を― 検査結果とバイタルサインに 振り分けます 複数の薬物リソースを “薬物治療”に入れます

つまりFHIRはJSONで データを表現し― 全てのFHIRリソースで キープロパティがあります リソースタイプは― “診察”で見ます

そして検査結果や バイタルサインを知らせます

全てのリソースタイプに IDがあります

リソースを特定できますが― 該当する医療機関の ドメイン内のみで― 固有な点にご注意ください

FHIRの基盤はコーディングです

外部の コーディングシステムで― IDやコードを参照できます FHIR特有のシステムは多数あり― 医療記録内の ある項目について調べたり 特定の項目について 複数の 医療機関を横断的に検索できます

カテゴリのコーディングです 検査結果だと分かります

計測中の場合のコードもあります

これはLOINCで定義される 血糖です データベースで検索すると― 別名や詳細が分かります

もちろん診察なので 数値もあります これは60mg/dlです 単位もコーディングされ― 状況を総合的に理解できます

FHIRリソースには 多くの追加データも存在します Argonaut Projectの説明書も ご一読ください 最後に詳細をお知らせします

HKFHIRResourceで FHIRを設計します 完全な生データにアクセスし キープロパティを提供します

リソースタイプやIDといった 共通要素を― 表に出します

SwiftやJSONで データにアクセス可能です 私のCodableの構造体と 診察を定義しています 前に見た値を 引き出すために使います

APIを通じてFHIRリソースを 共有するだけで― 適切にデータを構築できます

HKClinicalRecordの作業を 楽にするのは― データをリソースタイプ別に 検索する述語関数です 処方箋かFHIRの薬剤情報を 調べます

リソースタイプやIDで― 記録を特定できる 述語関数もあります FHIRリソース同士で 参照できるのは便利です 例えば薬剤で 治療の状況を参照します

ではFHIRを使う際に 必要な点を考えます

まずFHIRには 独自の日付があります 処方箋には処方日があります 症状には発症日や 症状が消えた日― 最初に処方箋が 出された日もあります リソースタイプ別に 直接アクセスして― FHIRを使ってください HKSampleのスーパークラスの 開始日と終了日は― リソースの最初の追加日が 設定されます

ヘルスケアレコードの 特定の際には― リソースタイプやIDを使います 更新は医療機関が行うので― 生涯にわたって確認できます

最後にFHIRとJSONは― 数値の精度の上で 完全に一致はしません FHIRは小数位で桁数に 重要性を見いだしますが― SwiftやJSONでは失われます 基本的にこの情報を アクセス可能にするなら― SwiftやJSONは 不適切かもしれません

では新しいAPIについて― ペイトンに語ってもらいます

（拍手） ありがとう 予防接種のダッシュボードです HealthKitで接種記録を取ります この段階でユーザが 内容を伝えるのは困難です

それをチェックリストで解決します ユーザは要約を 分かりやすい言葉で閲覧できます

混合ワクチンが免疫を作って― 病気を予防することを 知る必要があります

病気やワクチンの名称は 医療機関によって違います そこでFHIRの相互運用が 作動します FHIRは定義済みのコードを使い― 物事を特定します

FHIRの説明書を見て― 水ぼうそうワクチンで 特定するアルゴリズムです

まずJSONで接種記録を取ります

それをデシリアライズし CVXでコードを引き出します CVXは予防接種のための 一般的なコーディングで 領域が異なる薬剤は 別システムです

水ぼうそうを予防する ワクチンのリストと― CVXコードを比較してみます 一致すると 水ぼうそうの横が チェックされます

JSONの接種記録について―

構造はリソースタイプで 始まります

ワクチンコードです 中にコード配列が含まれます

多数あるので― 検索して CVXを探す必要があります 画面の例ではNDCなので― CVXが見つかるまで探します 手元のコードを見ます MMRVワクチンだと分かります

JSONの接種記録の構造です 実際にやってみます

ViewControllerに戻ります 事前にいくつか処理をしています showChecklistの プロパティで例示します

チェックリストに データを追加します ワクチンのメソッドへの クエリです matchCodedVaccineを 呼び出し― サンプルが FHIRのリソースならパスです やってみます

画面はmatchCodedVaccineです FHIRリソースデータを デシリアライズし― ワクチンコードで CVXを検索します そして異なる疾患のリストと 比較します

デシリアライズする方法は 自由に選べます 今日はSwift Codableにします 興味のあるキーを求めて Codableを定義します

できました ワクチンコードがあり― それはコード列を 持っています ワクチンのコーディングは システムとコードです

JSONデコーダの例示です これでFHIRリソースの データをデコードします

コーディングを繰り返して― システムはCVXか確認します

コードをパスして データソースに記録します 全てのメソッドで 疾患別のコードと比較します 一致したら その疾患のUIで― 記録を残します

ワクチンのチェックリストを 作ってみます トレーニングログです ワクチンのタブをタップ ワクチンの チェックリストができました （拍手）

FHIRの問題解決例です ユーザ同意について ジェイソンからお話しします ジェイソン （拍手） ありがとう ペイトンから―

FHIRデータの 呼び出し方の紹介でした ヘルスケアレコードについて 重要な情報を提供する― コーディングの活用の話題も ありました

ユーザのプライバシー保護について 少し考えてみたいと思います これらのデータは とてもデリケートです 徹底的にプライバシーを保護し― 直接医療機関へ 接続できるようにしています 情報はデバイスに ダウンロードでき― HealthKitで 安全に保管されます データへのアクセスには― 管理ツールも提供します

ユーザが求めるのは― 個人データの慎重な取り扱いです

どんな選択をしても 個人に直接影響を与えます プラスの影響です そのために このAPIを選びました ですが悪影響も否定できません データが扱えなくなったり― 同意なく 共有されたりしたら― 誠意を見せて 信頼関係を構築します データに関する ポリシーを提示し― 対応を知らせるのです これはアプリケーションを 作った時点で始まっています そしてデータを取り扱う限り― それは どの段階でも続くのです

例えばデータ管理の詳細を― ユーザに伝えることは大事です リテンションポリシーの公表や― データを削除できる ツールの提供も行うべきです

最終的には ユースケースに比例した― データを依頼するべきです 必要以上のデータを求めないこと

木曜の午後４時からの セッション― Better Apps Through Better Privacyもお薦めです エコシステムにも触れていて― いい気づきを得られます 新しいサンプルタイプを 見てきました entitlementやprivacy stringの 配列や― 承認依頼などを理解しました

FHIRをもっと知りたいと 思ってくれたらうれしいです

ユーザのプライバシーを 守る方法も伝えました

皆さんのアプリケーションに 驚き続けたいです ユーザに大きな権限を 与えるものです

これはHealthKitとの長い旅です ResearchKitやCareKitとの旅は まだ続きます Health RecordsやHealthKitと― 皆さんとの旅が続くことに 気持ちが弾みます 今後の展開が 楽しみでなりません

お話しした資料は 画面のURLで入手できます この後すぐ 健康に関するラボを行います 新しいAPIを始めましょう 明日の朝 同僚のニハリカと カリームが― 新たなワークアウトをご紹介します また明日の夜は 懇親会を予定しています お互いを知る いい機会ですので― ぜひ ご参加ください

他のセッションも どうぞ お楽しみを （拍手）