オンライン診療の案件はどこまでシステムが担う?汎用サービスとの違いと実施要件を整理
監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

📘 この記事でわかること
- オンライン診療専用に作られたシステムと、広く使われる汎用サービスとでは、開発側が担う機能の範囲が変わること
- 本人確認が患者側と医師側の双方向で求められることと、1対1の診療であることをログで確かめる仕組み
- 記録は診療の前から始まることと、認証・更新・責任の範囲まで実装段階で詰める必要があること
オンライン診療の案件は、ビデオ通話の画面を作る仕事に見えます。ところが指針を開くと、画面の外側に細かな要件が並んでいます。誰の本人確認をどう行うか、記録はいつから残すか、更新は誰と相談して当てるか。設計に着手する前にこの並びを知っておくと、要件の抜けを早い段階で見つけられます。
▶ あわせて読みたい
・医療DXの案件とは?電子カルテ情報共有とFHIRで関わる開発と必要スキルを解説
・医療DXの案件で扱う要配慮個人情報|境界の見分け方と取り扱いの注意点を解説
・パスキーとは?パスワードレス認証がフィッシングに強い理由と案件で問われる3つの実装
1. オンライン診療の案件で作るもの
見えている仕事と、指針が引く境界線は別物
オンライン診療の案件は、通話を作るだけの仕事ではありません。むしろ、画面の外側にある要件をどう設計に落とすかが本題です。通話機能を中心に見ていると、映像を届ける通話機能が動けば要件は満たせる、という見方では収まりません。
実際に指針を読み進めると、画面の向こう側に本人確認や記録の要件が控えていることに気づきます。まず押さえたいのは、指針が「システムの種類」で役割の線を引いているという点です。
指針は、オンライン診療で使うことを想定して作られたシステムを「オンライン診療システム」と呼びます1。汎用サービスとは区別された、専用の設計を前提にした枠組みです。
一方で、オンライン診療に限らず広く使われているサービスは「汎用サービス」という扱いになります1。同じ通話機能でも、どちらの枠に立つかで、システム側が背負う設計項目の量が変わってきます。
境界線を知らない設計開始と、後から積み上がる要件
通話がつながることをゴールにするよりも、専用システムか汎用サービスかを先に決めるほうが、途中の設計変更よりも手戻りが少なくなります。本人確認や記録の仕組みは、後から足す場合は、設計のやり直しが必要です。
案件に入る前にこの分類を確認しておくと、見積もりの段階で「どこまでを作るのか」がはっきりします。次の章では、この線引きが実装のどこに反映されるのかを具体的に見ていきます。
認証・映像配信・記録基盤の設計に関わってきた経験があるなら、その設計の型を指針の言葉に当てはめていく作業です。
参画が決まってから要件を洗い出すよりも、企画段階でこの前提を確認しておくほうが、クライアントとの認識のずれを防げます。どこまでを専用の設計として作り込み、どこから汎用の仕組みに委ねるかは、見積もりの根拠にもなる論点です。
2. 専用システムと汎用サービスの線引きと担う範囲
同じ通話機能で変わる設計の範囲
専用システムと汎用サービス、どちらを選ぶかは机上の分類に見えて、実装の設計図を大きく左右します。オンライン診療システムは、オンライン診療での利用を前提に作られています1。その前提があるぶん、オンライン診療向けの専用の設計を前提にした枠組みです。
汎用サービスは、オンライン診療に限らず広く使われている点が前提です1。本人確認や記録の仕組みは、周辺に別途組み合わせて用意する設計です。
ここで意識したいのは、便利さよりもリスクへの向き合い方です。指針は、使用するシステムに伴うリスクを踏まえた対策を講じることを重視しています1。通話の使い勝手よりも、リスクに応じた対策が整っているかどうかが選定の軸です。
比較表で役割の違いを整理する
専用システムと汎用サービスの違いを、位置づけと選定時に踏まえる点で並べると次のようになります。
| 比較項目 | オンライン診療システム | 汎用サービス |
|---|---|---|
| 位置づけ | オンライン診療での使用を想定して作られたシステム1 | オンライン診療に限らず広く用いられているサービス1 |
| 選定時に踏まえる点 | 想定した使い方の範囲で設計されている | 使用に伴うリスクを踏まえた対策が必要1 |
図の作成:Remogu編集部。指針が示す位置づけの違いを整理したもので、統計データではありません
表と図を見比べると分かるとおり、汎用サービスを選ぶ案件では、通話以外の要件を別の仕組みで補う設計判断が必要になります。専用システムを選ぶ案件よりも、周辺との接続点が増えることを見込んで見積もる姿勢が求められます。
どちらの前提を選ぶにせよ、後から線引きを変えるのは負担の大きい設計判断です。要件定義の早い段階で、専用システムとして作るのか、汎用サービスの上に薄い層を足すのかを、発注側とすり合わせておく価値があります。
汎用サービスを選ぶか専用システムを選ぶかは、案件ごとの制約や優先したい観点によって変わります。どちらが優れているという話ではなく、指針が求める要件をどちらの土台で満たすかという選択です。
運用が始まった後も、専用システムか汎用サービスかという前提は変わりません。保守や機能追加のたびに、この前提に立ち返って設計判断を行います。
認証・記録基盤の経験を活かせるリモート案件をチェックする →
線引きを理解したところで、次は本人確認そのものに目を向けます。誰が、どちらの立場で確認されるのかを押さえておくと、認証まわりの設計がぶれません。
3. 本人確認は双方向に要る——患者側と医師側
患者側の確認
本人確認というと、患者側だけの手続きに思えるかもしれません。指針は、初めての診療では顔写真の付いた身分証明書による確認を原則としています1。オンラインだからこそ、対面よりも確認の手順を明確に設計しておく必要があります。
顔写真付きの証明書をどう提示してもらい、どう確認するかは、システム側の画面設計に直結します。確認の手順があいまいなままだと、後から要件を足すことになりかねません。
医師側の確認
確認が必要なのは患者側だけではありません。指針は、医師の側にもなりすましを防ぐための本人証明の方法を定めています1。患者の確認だけでなく、医師の確認も設計の対象です。
医師のアカウントが本人のものであることを、どう継続的に担保するかは、認証設計の課題です。片方向の確認だけを整えるのではなく、双方向で確認の設計をそろえる必要があります。
患者側の確認と医師側の確認は、別々の手続きに見えて、同じシステムの中でどちらも欠かせない部品です。片方だけを厚くしても、もう片方が薄ければ、確認の仕組み全体としては弱いままになります。
患者側の確認は画面の入り口で完結させやすい一方、医師側の確認は運用の中で継続的に働かせる仕組みが必要です。入り口の設計と、継続的な認証の設計は、同じ「本人確認」という言葉でも作り方が異なります。
確認した本人情報を、診療の記録とどう紐づけるかも設計対象です。確認の仕組みと記録の仕組みが別々に動いていると、後から突き合わせる作業に手間がかかります。
図の作成:Remogu編集部。指針が定める確認の関係を整理したもので、統計データではありません
本人確認が双方向で整ったら、次に問われるのが「1対1」であることの証明です。確認と証明は似ているようで、システムに求められる仕組みが異なります。
4. 1対1であることを証明する仕組み
同時に複数の患者を診る診療の禁止
本人確認が済んでも、それだけでは1対1の診療は証明できません。指針は、情報通信機器を通じて同時に複数の患者の診療を行ってはならないとしています1。この前提は、セッション設計そのものに関わってきます。
同時進行のしやすさよりも、1つの通話セッションに1人の患者だけを紐づける設計のほうが、指針の前提に合います。複数の待機患者を同じ画面で切り替えるような作りは、この前提と相性がよくありません。
確認とログによる裏付け
指針は、医師と患者が1対1で診療を行っていることを確認する必要があるとしています1。確認の手段の一つとして位置づけられているのが、アクセスログです。
診療の開始時間と終了時間をアクセスログとして記録できるシステムが望ましいとしています1。ログは監査のためというより、1対1の診療であったことを裏付けるための記録という位置づけです。
同時実施の禁止・本人の確認・ログの記録という3つの要素を、指針の内容と実装への反映で整理すると、次のようになります。
| 要素 | 指針の内容 | 実装への反映 |
|---|---|---|
| 同時実施の禁止 | 情報通信機器を通じて同時に複数の患者を診てはならない1 | 1つのセッションに1人の患者を紐づける設計 |
| 本人の確認 | 医師と患者が1対1で診療を行っていることを確認する必要がある1 | セッション開始時に確認の手順を組み込む |
| ログの記録 | 開始時間・終了時間をアクセスログとして記録するシステムが望ましい1 | セッションの開始・終了をログに残す仕組み |
図の作成:Remogu編集部。指針が示す3つの要素を整理したもので、統計データではありません
3つの要素は、どれか1つを満たせば良いという関係ではありません。禁止事項と確認とログが揃って、はじめて1対1の診療が成り立っていると言えます。
アクセスログをどこにどれだけの期間保持するかは、この記事の範囲を超える論点ですが、開始・終了時刻を記録する仕組みそのものは、通話機能を作る初期段階から組み込んでおく要件です。後から足そうとすると、通話基盤の設計をやり直すことになりかねません。
同時に複数の患者を扱えないという前提を、システムの制約としてどう可視化するかも設計の一部です。医師側の画面に、今どの患者と接続しているかが常に分かる表示を置く設計が考えられます。
5. 診察の前から始まる記録
診療前の相談も記録の対象
記録は診療の後にまとめて整えるものではありません。むしろ、診療が始まる前から流れている情報の一部です。指針は、診療の前に行う相談で得た内容も、診療録に記載することを求めています1。
システム側から見ると、診療セッションが始まる前のやり取りをどこにどう残すかも、設計対象に含まれます。診療中の記録だけでなく、前段階のやり取りまで見渡して設計します。
患者がいつでも見られる医師の本人確認情報
記録とあわせて、指針が求めているのが情報公開の面です。患者がいつでも医師の本人確認ができる情報と、問い合わせ先をシステム上に掲載することを求めています1。
この要件は、記録の裏側にある「誰が診療を担当したか」を、患者側からも確認できる状態にしておくという発想です。管理画面の奥に置くよりも、患者が使う画面のどこかに、常時アクセスできる形で置いておく設計のほうが、この考え方に合います。
記録の起点を診療前まで広げ、確認できる情報を患者側にも開いておく。この2つを合わせて設計すると、診療前から患者側の確認までを1つの流れで扱えます。
問い合わせ先や医師の本人確認情報をシステム上に掲載することは、細かい画面設計に見えて、指針が明示している要件です。
問い合わせ対応とあわせて、記録の保存期間や、誰がその記録にアクセスできるかという権限設計も、実装段階で詰める項目です。誰に何を見せるかを最初に決めると、画面ごとの表示範囲を整理できます。
医療系システムの記録・認証設計に関わるリモート案件をチェックする →
記録は診療の後にまとめるものではなく、診療が始まる前から流れている情報の一部です。次の章では、この記録や通信を支える認証と更新の要件に話を進めます。
6. 認証と更新——実装に落ちる要件
更新は事業者との協議が前提
システムを作って終わりではなく、運用の中でOSやソフトウェアを更新していく場面が出てきます。指針は、こうした更新について、事業者と協議・確認した上で実施することを求めています1。
現場の判断だけで更新を当ててしまうよりも、事業者との連絡体制を先に決めておくほうが、運用開始後のトラブルを減らせます。更新の頻度や手順を、設計段階で事業者側とすり合わせておく価値があります。
望ましい多要素認証
ログインの仕組みについても、指針は方向性を示しています。システムを使う際は、多要素認証を用いることが望ましいとしています1。パスワードだけに頼る認証よりも、もう1つの要素を組み合わせる設計のほうが、指針の考え方に沿います。
更新前に検証環境で動作を確かめる工程を、事業者との協議の中に組み込むと、本番環境への反映の段取りを事業者と共有できます。多要素認証も、最初から選択肢に入れて設計できます。
更新履歴をどう記録に残すかも、認証や記録の設計とあわせて考える点です。いつ、どの内容の更新を、誰の合意のもとで行ったかを追える状態にしておくと、責任の範囲を説明する場面で使えます。
更新と認証、それぞれの要件と運用のポイントを整理すると、次のようになります。
| 要件 | 指針の内容 | 運用のポイント |
|---|---|---|
| 更新の進め方 | OSやソフトウェアの更新は事業者と協議・確認した上で実施する1 | 検証環境での確認と、事業者との連絡体制を先に決めておく |
| 認証の方式 | 多要素認証を用いるのが望ましい1 | パスワードだけに頼らない認証方式を組み込む |
認証と更新は、一度作って終わりではなく、運用のあいだずっと向き合い続ける項目です。最後に、責任の範囲をどう決めておくかを見ていきます。
7. 先に決めておく責任の範囲
分界点の事前の明示
システムに不具合が起きたとき、どこまでが医療機関の責任で、どこからが提供者の責任なのかがあいまいだと、対応が後手に回ります。指針は、診療の計画に、責任の範囲(責任分界点)と、その範囲が途切れないことの明示を含めるとしています1。
分界点は、患者に説明する項目の一つとして位置づけられています。分界点をあいまいにしておくよりも、医療機関・システムの提供者・回線の事業者という並びのどこにも切れ目や抜けを作らないほうが、指針の考え方に沿います。
図の作成:Remogu編集部。指針が示す責任の並びを整理したもので、統計データではありません
別のガイドラインによる安全管理の補完
システムを作る側には、もう一つ確認する点があります。医療情報を扱うシステムやサービスの提供者に向けた、別の安全管理ガイドラインが用意されています1。
この記事で扱った本人確認や記録、認証の要件は、指針の骨格にあたる部分です。実装を仕上げる段階では、安全管理のガイドラインもあわせて確認します。
医療の案件と聞くと、専門知識が要るのかと気になる場面があります。指針が並べているのは、本人確認や記録、認証といった要件です。いずれも、認証や記録の設計に関わってきた経験と重なる項目です。
認証や記録基盤の設計経験は、オンライン診療に限らず、ほかの案件でも使える設計の知識です。
線引き、本人確認、1対1の証明、記録、認証、責任の範囲。この6つが、通話画面の外側に並ぶ要件でした。自分が関わってきた認証や記録基盤の経験が、このうちどれに重なるかを書き出してみましょう。条件に合う案件があるかどうかは、Remoguに登録して案件の一覧で確かめられます。
8. よくある質問
アクセスログの記録は、指針で求められていますか
指針は、診療の開始時間と終了時間をアクセスログとして記録できるシステムが望ましいとしています1。
多要素認証は、指針で必須とされていますか
指針は、システムを使う際に多要素認証を用いることが望ましいとしています1。
初めての診療で、患者側にはどのような本人確認が求められますか
指針は、初めての診療では顔写真の付いた身分証明書による確認を原則としています1。
リモートワーク案件をお探しの方へ
Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。
画面の外側に並ぶ要件を読み解ける人は、医療の案件で重宝されます。認証や記録の設計に手ごたえがあるなら、案件の条件から確かめてみてください。
会員登録無料 / 案件閲覧・相談は無料
※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。
出典・参考情報