PHRとは？電子カルテ・EHRとの役割分担とデータ連携方式の選び方

PHR（Personal Health Record）は、本人が自分の健康・医療・介護の記録を手元に持ち、必要なときに見返したり提示したりできるようにする仕組みです。健診結果や処方された薬の履歴のように医療側から出てくる情報と、体重や血圧、歩数のように自分で測る情報が、同じ人の記録として時系列でつながります。読者がアプリやサービスを企画する立場なら、定義よりも先に知りたいのは「そのデータは実際どこから、どこまで取れるのか」でしょう。本稿では、PHRと電子カルテ（EMR）・EHRの役割分担、日本の基盤が2026年9月時点でどこまで来ているか、データを取り込む四つの経路とそれぞれの制約、そして自社で作るべきか見送るべきかの線引きまでを扱います。

まとめ：PHRの定義と電子カルテとの役割分担、連携方式を決める順序

結論を先に置きます。PHRは本人が管理主体である点で、医療機関が管理する電子カルテ（EMR）や、地域の医療機関どうしが共有するEHRとは別物です。同じ「健康情報」を扱っても、誰の所有物として保存し、誰の同意で動かすかが違います。この一点を企画の最初に固定しないと、後段の設計が全部ぶれます。

データの入手経路は実質四つ。マイナポータルの医療保険情報取得API、スマートフォンのヘルスプラットフォーム、本人の手入力、そして医療機関や保険者からの直接受領です。負荷の差は極端で、マイナポータルAPIはデジタル庁の審査を前提に申請から利用開始まで約半年から約1年を想定するとされています。企画の初期に選ぶべきは、審査を待たずに動く後者二つで薄く作り、APIは後付け前提で設計を空けておく順序です。

制度側の前提も押さえておきます。健診等情報を扱うサービスは「PHRサービス提供者による健診等情報の取扱いに関する基本的指針」（総務省・厚生労働省・経済産業省、令和3年4月策定、令和7年4月改定）の遵守対象になります。医療機関側では電子カルテ情報共有サービスが2026年度の冬頃をめどに本格運用を目指す段階で、PHR側から見ると「まだ全国どこでも同じデータが取れる状態ではない」というのが2026年9月時点の実態です。国の工程全体の位置づけは医療DXの定義と3本柱を整理した記事で扱っています。

PHRの定義と対象データの範囲、EMR・EHRとの三者の役割分担

PHRという語は、健康情報全般を指す漠然としたバズワードとして使われがちです。企画で使うなら、管理主体と保存単位で線を引いた狭い定義に絞ったほうが実務が回ります。

本人が生涯分を持ち歩く記録という定義と、医療記録との立場の違い

PHRの核は「本人が持つ」という位置づけです。医療機関の記録は受診した施設ごとに分断され、転院や引っ越しで途切れます。PHRはその断片を本人という単位でまとめ直し、乳幼児期の予防接種から現在の服薬までを1本の時系列として保持します。だから「生涯型」と呼ばれるのです。

保存の主体が本人であることは、権利関係にも直結します。医療機関の診療録は医師法・医療法の保存義務に紐づく施設の記録で、患者が自由に書き換えたり消したりはできません。PHRは本人が自分の意思で追加・訂正・削除でき、第三者へ渡すかどうかも本人が決めます。この非対称性が、後述する同意管理の設計を規定します。

EMR・EHR・PHRを分ける三軸は管理主体・保存単位・利用目的

三者の混同は、要件定義の段階で最も高くつく誤解です。三軸で切ると迷いません。

EMRの側で何が起きているかを押さえておくと、PHRに流れてくるデータの粒度が読めます。医療機関がどの製品を選び、どこまで標準化しているかで、外に出せる情報の形が変わるためです。導入側の事情は電子カルテの種類と選び方をまとめた記事に整理しました。

PHRに入る四系統のデータと、出所ごとに異なる精度と欠測の前提

PHRに集まるデータは、出所で四系統に分かれます。設計上の扱いは同列にできません。

• 医療保険者由来：特定健診結果、薬剤情報、診療情報、医療費通知。標準コードが付き精度は高いが、反映まで時間差がある
• 自治体由来：予防接種、乳幼児健診。マイナポータルで本人・家族が閲覧できる範囲が先行して整備された
• 医療機関由来：診療情報提供書、健康診断結果報告書。電子カルテ情報共有サービスの整備状況に依存する
• 本人由来：体重、血圧、歩数、食事、睡眠、服薬記録。連続性はあるが測定条件が揃わず、欠測が常態

実務でまず押さえるのはこの順序です。上の三系統は「正確だが遅くて穴がある」、本人由来は「速くて連続するが精度が保証されない」。この非対称を前提にしないと、グラフを重ねた瞬間に矛盾した数値が並びます。日次の体重と半年前の健診体重を同じ折れ線に置く設計は、その典型的な失敗です。

日本のPHR基盤の到達点、マイナポータルと電子カルテ情報共有サービス

国内のPHRは、マイナポータルを本人向けの窓口、電子カルテ情報共有サービスを医療機関間の配管とする二階建てで整備が進んでいます。2026年9月時点で、両者の完成度には差があります。

マイナポータルで本人が閲覧できる情報と遡れる期間の実際の上限

マイナポータルの医療保険情報取得APIで取得できるのは、薬剤情報、診療情報、処方情報、調剤情報、健診情報（第3期・第4期）、医療費通知情報です。遡れる期間には明確な上限が引かれています。診療情報と薬剤情報は約1か月半前から最大5年前まで、処方情報と調剤情報は処方行為の直後から最大100日前までとされています。

この「最大5年」「最大100日」という上限は、PHRアプリの価値提案を直接左右する条件です。生涯記録を謳いながら実際には5年分しか引けないなら、初回同期の時点で読者の期待を裏切ります。5年より前の履歴が要る企画なら、API以外の入力手段を最初から用意しておく必要があります。健診情報が第3期・第4期に限られる点も同じで、2020年度より前の健診結果はここからは出てきません。

電子カルテ情報共有サービスの本格運用時期と二文書六情報の範囲

電子カルテ情報共有サービスは、モデル事業を全国9地域・22医療機関で実施し、2026年度の冬頃をめどに全国展開を目指す段階にあります。厚生労働省は2026年3月に「概要案内2.0版」で仕様を見直し、2026年4月24日に開かれた第31回の医療等情報に関するワーキンググループで傷病名・アレルギー・感染症・検査それぞれの対応方針を示しました。実装ガイドの現行名称は「2文書6情報電子カルテ情報共有サービス実装ガイド（CLINS-IG）」で、Ver.1.13が2026年8月31日に公開されています。基盤となるJP Coreの正式版はVer.1.1.2（2023年10月31日）で、CLINS検証用にはVer.1.1.2-clinsの使用が指定されました。

企画側が誤解しやすいのが処方情報の扱いです。処方は電子処方箋管理サービスでのカバーが可能になったことを踏まえ、電子カルテ情報共有サービス側でメインでは扱わない方針が示されました。つまり「1つの基盤に全部ある」という前提は成り立たず、薬の履歴は別系統から取ることになります。医療機関側の普及の見通しは電子カルテ義務化のスケジュールと対応判断を整理した記事で追っています。

自治体・学校由来の健診データとFHIR記述仕様第1.7版の位置

本人の記録を「生涯分」にするうえで、乳幼児期と学齢期のデータは土台です。乳幼児健診と予防接種の記録は、すでにマイナポータルで本人・家族が閲覧できます。学校健康診断情報については、統合型校務支援システム等で電子化したデータを民間送達サービスで配信し、マイナポータルで結果を確認できる仕組みの構築が文部科学省の施策として進んでいます。

データ形式の側では、健康診断結果報告書のHL7 FHIR記述仕様（JAMI標準 JAMISDP03）が第1.7版として2026年2月に公開されました。厚生労働省が公表する特定健診項目コード表に基づいて区分番号と区分名称が記述されるため、健診値のマッピングを自前のコード体系で作る必要はありません。逆に言えば、独自コードで先に作り込んだ設計は、後から標準側に寄せる工数を丸ごと抱えます。健診値を扱うなら、最初からこの記述仕様の項目名で内部モデルを組むほうが安く済みます。

PHRサービスがデータを取り込む四つの経路と実装負荷・審査期間の差

ここからは実装の話です。PHRサービスが扱うデータの入手経路は四つあり、必要な体制と立ち上げ期間がまったく違います。

マイナポータルAPI経由の取得範囲と申請から利用開始までの期間

医療保険情報取得APIは、利用規約の確認、API利用申請フォームからの仕様書取得申請と利用申請、事前打合せ、デジタル庁による審査という手順を経て、承認後に開発できるようになります。デジタル庁の開発者向けドキュメントでは、申請からサービス利用開始まで約半年から約1年ほどを想定し、事業者の体制やAPIの種類によって変動するとされています。

この期間を工程表に入れ忘れる企画が少なくありません。半年から1年は、アプリ本体の開発期間より長いことがふつうです。したがって現実的な進め方は、API接続を待たずにリリースできる機能でサービスを立ち上げ、審査と並行して接続部分を後付けする二段構えになります。医療費通知情報を除く医療保険情報を扱う場合、基本的指針の遵守が前提条件として明記されている点も、申請前に社内体制を整える理由になります。

端末のヘルスプラットフォームと自己入力に頼る場合の精度の限界

iOSのHealthKitやAndroidのHealth Connectから取る自己測定データは、審査を待たずに使えます。ただし数値の性質が医療データとは違います。歩数は端末を持ち歩いた時間しか数えません。体重は測った日だけ入ります。睡眠は装着していた夜だけ記録されます。欠測が異常ではなく標準状態です。

設計での対処は二つに絞られます。第一に、欠測を0として扱わないこと。歩数0と未計測を同じ値で保存すると、平均値がそのまま壊れます。第二に、医療由来の値と自己測定値を同じ指標として混ぜないこと。家庭血圧と診察室血圧は基準値が別で、並べて1本の折れ線にすると誤った解釈を誘います。自己入力データを読み解いて助言に変える方向では生成AIの利用も検討されますが、その限界と前提はChatGPTによるヘルスケア機能の範囲を整理した記事で扱っています。

四つの入手経路の比較表と、企画の初期段階で選ぶべき経路の優先順位

四経路を、立ち上げに要する期間と得られるデータの性質で並べます。

優先順位は明確です。まず端末ヘルスプラットフォームと手入力で価値が成立するかを確かめ、続けて対象読者が実在する母集団で継続利用を検証し、そのうえでマイナポータルAPIの申請に入る。この順序を逆にした企画、つまりAPI承認を前提に全機能を設計した企画は、審査期間中に資金と社内の関心を失って止まります。医療機関からの直接受領は、相手方のシステム更新スケジュールに縛られるため、単発の実証実験を超える規模では最後に置くのが妥当です。

PHRサービス提供者に課される基本的指針の遵守事項と設計への反映

健診等情報を扱うと決めた時点で、守るべきルールは個人情報保護法だけではなくなります。3省が示す基本的指針が、設計と運用の両方に条件を付けます。

2025年4月の改定で対象が広がった指針の名称と主要な遵守事項

現行の名称は「PHRサービス提供者による健診等情報の取扱いに関する基本的指針」です。総務省・厚生労働省・経済産業省の3省が令和3年4月に策定し、令和7年（2025年）4月に改定しました。改定前の名称は「民間PHR事業者による健診等情報の取扱いに関する基本的指針」（令和3年4月、令和4年4月一部改正）で、2025年4月の改定で対象の呼称が「事業者」から「サービス提供者」へ広がりました。自社を狭義のPHR事業者と考えていなかった企業も、健診等情報を扱う限り射程に入ります。

指針は、法規制で遵守が求められる事項に加えて、適正な利用を進めるために遵守すべきと考えられる事項を含めて示す構成です。健診結果や病歴は個人情報保護法上の要配慮個人情報にあたり、取得には原則として本人の事前同意が必要になります。法令側の変更点は2026年7月公布の個人情報保護法改正で企業対応がどう変わるかを整理した記事にまとめました。

同意の粒度・撤回・退会時のエクスポートをDB設計に落とす手順

指針が求める事項のうち、後から作り直しになりやすいのは同意の管理と本人へのデータ返却です。実装の順序は次のとおりです。

1. 同意を「利用目的×データ種別×提供先」の組み合わせで持つテーブルを最初に切る。フラグ1本で持つと粒度を後から割れない
2. 同意には取得日時と同意文面のバージョンを必ず残す。文面を改定したとき、どの版で同意したかを再現できるようにする
3. 撤回を削除ではなく状態遷移として記録する。撤回後も「いつまで有効だったか」を追える形にする
4. 退会時に本人が記録を持ち出せるエクスポート機能を、機能追加ではなく初期要件に含める
5. 第三者提供の実績ログを、提供先・日時・データ種別の単位で保存する

この5点を後付けで入れる工数は、初期に組み込む場合の数倍になります。とくに1番目を怠った設計は、同意テーブルの作り直しが利用者データの移行を伴うため、稼働後の改修が現実的でなくなります。なお医療機関側で求められる安全管理の水準は別体系で、医療情報システム安全管理ガイドライン第7.0版への対応を整理した記事が参照先です。PHRサービス提供者はこのガイドラインの直接の対象ではありませんが、医療機関と接続する場面では相手方の基準に合わせる必要が出ます。

PHRを自社で作るべき条件と、着手すべきでない企画の見送り基準

ここは他の解説記事が踏み込まない領域です。判断を言い切ります。PHRは「あると良さそう」で始めると、ほぼ確実に使われないまま維持費だけが残ります。

自社開発が成立する三つの条件と、医療機関由来データへの依存度

自社でPHRを持つ意味があるのは、次の三つが同時に成り立つ場合だけです。

第一に、本人との継続的な接点をすでに持っていること。健保組合、フィットネス、生活習慣病の指導サービス、産業医の面談など、記録を見に来る理由が既存の関係にあることが前提になります。ゼロから利用者を集めて記録だけを続けさせる設計は成立しません。

第二に、企画の中核価値が医療機関由来データに依存していないこと。診療情報や検査値がなければ機能しない企画は、電子カルテ情報共有サービスの全国展開と各施設の対応を待つことになり、自社の裁量で完成させられません。第三に、記録を続けることが本人の具体的な行動に直結すること。指導の予約が取れる、保険料の還付につながる、通院時に医師へ提示できる、といった出口です。出口のない記録は3週間で止まります。

着手すべきでない三つの企画パターンと、見送りを決める判断基準

逆に、次の三パターンは着手を見送るべきです。条件付きで明記します。

ひとつ、マイナポータルAPIの承認を前提に主要機能を組む企画。承認までに約半年から約1年を要する想定である以上、それを工程の前提に置いた計画は破綻します。承認前にリリースできる機能が1つもないなら、企画自体を組み替えるべきです。

ふたつ、医師の診断や治療方針の判断材料として使わせる前提の企画。自己測定値は測定条件が揃わず、欠測が常態です。その値を診療判断の入力にする設計は、精度の保証責任を自社が負う構造になります。医療機器プログラムとしての規制も視野に入るため、この線を越える企画は医療領域の規制対応を専門とする体制がない限り着手しません。どこからが医療機器に当たるかの線引きは、プログラム医療機器の該当性の判断基準と承認区分を整理した記事で扱っています。

みっつ、「生涯にわたる記録の網羅性」を売り文句にする企画。2026年9月時点で、診療情報と薬剤情報はAPI経由で最大5年前まで、健診情報は第3期・第4期に限られ、学校健診の配信は整備途上です。網羅性を約束できる状態ではなく、初回同期で空白を見た利用者はそこで離脱します。訴求は網羅性ではなく、限られた範囲でも読者の行動が変わる用途に置いてください。

最初に作る範囲の決め方と、開発会社へ渡すべき要件定義の整理手順

作ると決めたら、初期リリースは薄く切ります。具体的には、自己入力と端末ヘルスプラットフォームからの取り込み、記録の一覧と時系列表示、本人が第三者に見せるための提示画面、そして同意管理の四つで十分です。グラフの種類を増やすより、既存の接点から流入した利用者が2週目も戻るかを見るほうが企画の生死を判定できます。

外部に開発を委ねる場合、渡すべき情報は画面案ではありません。扱うデータ種別と出所、同意の粒度、遡る必要のある期間、将来つなぐ予定の経路（マイナポータルAPIを含むか）、そして提示先が誰かの五点です。この五点が決まっていれば設計は始められ、決まっていなければ画面をいくら描いても手戻りします。要件の詰めから連携部分の実装まで含めた相談先としては、ヘルスケアアプリ開発として健康記録アプリと外部データ連携を請け負う体制を用意しています。

よくある質問

PHRの企画・開発で実際に寄せられる質問のうち、判断に直結するものを5つ取り上げます。

PHRとEHRの違いは何ですか？

管理主体が違います。EHRは地域や複数の医療機関が診療連携のために共有する基盤で、本人が書き込むことはできません。PHRは本人が管理主体で、自己測定した体重や血圧も含めて自分で追加・訂正でき、第三者に見せるかどうかも本人が決めます。保存単位も、EHRが施設間で共有する要約情報である一方、PHRは本人ごとの生涯記録として積み上がります。

PHRはマイナポータルとどう違うのですか？

マイナポータルは、国が用意した本人向けの閲覧窓口であり、PHRという考え方を実現する手段の一つです。薬剤情報や特定健診結果、予防接種、乳幼児健診の記録などを本人が確認できます。ただし自己測定データの記録や、生活指導と結びつけた読み解きは範囲外です。民間のPHRサービスは、医療保険情報取得APIでマイナポータル側の情報を取り込み、そこに自己測定データと用途別の機能を足す位置づけになります。

PHRのデータは要配慮個人情報にあたりますか？

健診結果、病歴、診療や調剤の情報は、個人情報保護法上の要配慮個人情報にあたります。取得には原則として本人の事前同意が必要で、オプトアウトによる第三者提供もできません。一方、自分で測った体重や歩数のような数値は、それ自体では要配慮個人情報に該当しないと整理されます。ただし特定の疾病の管理を目的として集めた場合、文脈から病歴が推認されうるため、実務では要配慮情報と同等の扱いで設計しておくほうが安全です。

電子カルテの情報をPHRアプリで直接読めますか？

2026年9月時点では、任意の医療機関の電子カルテへ直接つないで読む仕組みは一般提供されていません。医療機関側の情報は電子カルテ情報共有サービスを経由する形で整備が進み、同サービスは2026年度の冬頃をめどに全国展開を目指す段階にあります。実装ガイドはCLINS-IG Ver.1.13（2026年8月31日公開）が現行です。個別の医療機関と直接連携する場合は、相手方のシステム更新計画と個別の合意が前提になります。

PHRアプリの開発期間はどのくらい見ておくべきですか？

自己入力と端末ヘルスプラットフォーム連携、記録の一覧表示、同意管理までの初期リリースなら、要件が固まっている状態から数か月規模が目安です。工程で支配的なのはアプリ本体ではなく外部連携で、マイナポータルAPIを使う場合は申請から利用開始まで約半年から約1年を想定するとされています。したがって全体計画では、API接続を待たずに出せる範囲と、承認後に足す範囲を分けて組むことになります。

関連記事

• 電子カルテとは？種類・メリットと失敗しない選び方・開発判断を解説【2026年】：PHRの対岸にある医療機関側の記録システムを扱っています
• 電子カルテ義務化はいつから？2030年普及率100%目標と対応判断【2026年版】：医療機関由来データがいつ揃うかの見通しが分かります
• 医療DXとは？定義・3本柱・2026年度改定から進め方と受託開発の判断まで解説：PHRを含む国の工程全体の位置づけを整理しています
• 医療情報システムとは？種類・構成と安全管理ガイドライン第7.0版対応の判断【2026年版】：医療機関と接続する際に合わせる安全管理の基準です
• ChatGPTヘルスケアとは？AIによる健康管理機能の概要とできること：自己測定データを読み解く用途の限界を扱っています