会社情報
採用情報
お問い合わせ
Article

医療業界のDX事例：電子カルテから遠隔医療まで

高田晃太郎
医療業界のDX事例：電子カルテから遠隔医療まで

統計では、米国の病院における電子カルテ（EHR）導入率は2019年時点で約96%に達し¹、日本でも400床以上の大規模病院では約9割が電子カルテを採用していると報告されています²。2020年以降は遠隔医療の利用が一時外来の約3割に達し³、その後も1割超で定着したという報告も見られます⁴。こうした数字は一過性のブームではなく、医療現場の恒常的なワークフローとしてデジタルが組み込まれた事実を示しています。CTOやエンジニアリーダーにとって重要なのは、製品名の羅列ではなく、標準と実装、そして運用で成果を出すための設計原則です。鍵はFHIR/SMARTによる相互運用、WebRTCを核とした通信の信頼性、クラウドにおける監査可能性、そしてROIを測れるKPI設計にあります。専門用語は最小限の説明を添えながら、現場で効く実装の勘所に絞って整理します。

電子カルテDXの現在地：FHIR/SMARTと実運用

電子カルテのDXは、HL7 v2メッセージ（院内システム間の連携に長年使われてきたテキストベースの規格）による連携を土台に、FHIRリソース（HTTPでやり取りできる医療データの標準モデル）によるAPI駆動の相互運用へと移行しています。FHIRはHTTPベースのリソースモデルで、読み出しと検索、部分更新、サブスクリプションまでを標準化し⁵、SMART on FHIRはOAuth2/OIDC（標準的な認可・認証の枠組み）によりアプリの認可・スコープ管理を定義します⁶。各種報告では、FHIRを用いた院外連携により重複検査の削減や紹介状作成時間の短縮が示唆され、生産性と安全性の両立に寄与する可能性が指摘されています⁵。実運用では、Read/Searchの主要クエリでp95 200ms前後（全リクエストの95%が200ms以内に完了する目安）をターゲットに設計すると、外来現場の体感レスポンス改善に直結します。ここでの要は、インデックス設計とスケーリング方針を早期に決め、監査と可観測性を同時に仕込むことです。

FHIRに触れる：最小のGETと検証の考え方

まずはFHIRサーバへの安全な読み取りです。開発段階ではダミーデータで個人情報を含まない環境を用意し、HTTPレベルとアプリレベルの両方で監査ログを残します。

# Example 1: PythonでFHIR Patientを取得（HAPI FHIR想定）
import os
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

BASE = os.getenv("FHIR_BASE", "https://fhir.example.org/fhir")
TOKEN = os.getenv("FHIR_TOKEN")

session = requests.Session()
retries = Retry(total=3, backoff_factor=0.3, status_forcelist=[429, 500, 502, 503, 504])
session.mount("https://", HTTPAdapter(max_retries=retries))

headers = {"Authorization": f"Bearer {TOKEN}", "Accept": "application/fhir+json"}

try:
    r = session.get(f"{BASE}/Patient", headers=headers, timeout=3, params={"_count": 10, "name": "tanaka"})
    r.raise_for_status()
    bundle = r.json()
    total = bundle.get("total", 0)
    print({"total": total, "first": bundle["entry"][0]["resource"]["id"] if total else None})
except requests.Timeout:
    print({"error": "timeout"})
except requests.HTTPError as e:
    print({"status": r.status_code, "body": r.text[:200]})

テストではp95 200msを超えたらスケール条件を見直し、_countやインデックス設定を再評価します。患者名での検索は部分一致のコストが高く、Phonetic検索やカスタムインデックスでの最適化が必要です。検索条件の節度とインデックス戦略は、FHIR運用の要です。

SMART on FHIRの認可：PKCE/OIDCを正しく扱う

EHRにアプリを組み込むには、SMARTが定めるスコープとコンテキスト（どの患者やどの利用者権限で動作するかの枠）を満たす必要があります。AuthZサーバはIDトークンでユーザー、Accessトークンでリソースアクセスを示し、患者コンテキストはlaunchパラメータで渡されます⁶。以下はPKCE（パブリッククライアントのための安全な認可コード取得手法）でのトークン取得の最小例です。

// Example 2: Node/TSでSMART on FHIRのPKCEフロー
import crypto from "crypto";
import fetch from "node-fetch";
import express from "express";
import querystring from "querystring";

const app = express();
const authz = process.env.AUTHZ_ENDPOINT!; // /.well-known/smart-configuration経由で取得
const token = process.env.TOKEN_ENDPOINT!;
const clientId = process.env.CLIENT_ID!;
const redirectUri = process.env.REDIRECT_URI!;

function sha256(b: Buffer) { return crypto.createHash("sha256").update(b).digest(); }

app.get("/login", (_req, res) => {
  const verifier = crypto.randomBytes(32).toString("base64url");
  const challenge = sha256(Buffer.from(verifier)).toString("base64url");
  const state = crypto.randomBytes(16).toString("hex");
  // セッション等でverifier/stateを保存（省略）
  const q = querystring.stringify({
    response_type: "code",
    client_id: clientId,
    redirect_uri: redirectUri,
    scope: "launch patient/*.read openid fhirUser",
    code_challenge: challenge,
    code_challenge_method: "S256",
    state
  });
  res.redirect(`${authz}?${q}`);
});

app.get("/cb", async (req, res) => {
  try {
    const code = req.query.code as string;
    const verifier = "...load-from-session...";
    const body = new URLSearchParams({
      grant_type: "authorization_code",
      code,
      redirect_uri: redirectUri,
      client_id: clientId,
      code_verifier: verifier
    });
    const r = await fetch(token, { method: "POST", body });
    if (!r.ok) return res.status(502).send(await r.text());
    const json = await r.json();
    // json.access_token, json.id_token, json.patient
    res.json({ ok: true, scope: json.scope, patient: json.patient });
  } catch (e: any) {
    res.status(500).send({ error: e.message });
  }
});

app.listen(3000);

本番ではFHIRサーバとAuthZの監査ログを相関可能にし、patient/*.readなど最小特権の原則を徹底します。Consent（患者の同意）をスコープやトークンのクレームに還元して設計できるかが、ガバナンスの成否を分けます⁶。

HL7 v2からFHIRへのデータ統合：増分・正規化・MPI

現場では未だ多くのデータがHL7 v2メッセージで流れています。ADT、ORU、SIU等をイベントとして取り込み、MPI（Master Patient Index：同一人物照合）で同一人物を特定し、FHIRのPatient/Encounter/Observationへ正規化するパターンが実務的です。夜間バッチとストリーミングのハイブリッド構成は、帳票や請求の締め処理とリアルタイム医療の両立に有効です。

-- Example 3: Observationの増分UPSERT（PostgreSQL）
WITH src AS (
  SELECT
    o.event_id,
    o.patient_id,
    o.loinc_code,
    o.value_num,
    o.unit,
    o.observed_at,
    now() AS ingested_at
  FROM staging_hl7_oru o
  WHERE o.processed = false
)
INSERT INTO fhir_observation (event_id, patient_id, loinc_code, value_num, unit, observed_at, ingested_at)
SELECT event_id, patient_id, loinc_code, value_num, unit, observed_at, ingested_at FROM src
ON CONFLICT (event_id) DO UPDATE SET
  value_num = EXCLUDED.value_num,
  unit = EXCLUDED.unit,
  observed_at = EXCLUDED.observed_at,
  ingested_at = EXCLUDED.ingested_at;

UPDATE staging_hl7_oru SET processed = true WHERE processed = false;

同一人物照合は氏名・生年月日・住所・電話の組合せに重み付けを行う確率的マッチングを用いるのが一般的です。目安として、夜間バッチ10万件規模の正規化を数分程度で完了できると、朝の業務開始に与える影響を抑えやすく、日中はKafka等でイベント駆動に切り替えると遅延は数秒に収まります。性能要件は“現場の締め処理”に合わせて決めるのが正解です。

遠隔医療の実装：WebRTCと品質・安全性

遠隔医療ではWebRTCが事実上の標準です。エンドツーエンドのメディアはSRTPで暗号化され、シグナリングはアプリ層で制御します。NAT超えはSTUN/TURNで担保し、医療ではTURN必須と考えてよい。診療の解像度やフレームレート、レイテンシの目標を医療行為の種類と照らして設計する必要があります。たとえば皮膚科の静止画に近い観察中心なら720p/15fps、聴診支援やAI解析を伴うときは音声のジッタと欠落率を最優先で管理します（ジッタは遅延の揺らぎ、MOSは音声品質の主観評価尺度）。

// Example 4: WebRTC最小実装（TURN強制・基本のエラーハンドリング）
const pc = new RTCPeerConnection({
  iceServers: [{ urls: ["turns:turn.example.org:443"], username: "u", credential: "p" }],
  iceTransportPolicy: "relay" // TURN強制
});

async function start() {
  try {
    const stream = await navigator.mediaDevices.getUserMedia({ video: { width: 1280, height: 720 }, audio: true });
    stream.getTracks().forEach(t => pc.addTrack(t, stream));
    pc.ontrack = e => { document.getElementById("remote").srcObject = e.streams[0]; };

    const offer = await pc.createOffer({ offerToReceiveAudio: true, offerToReceiveVideo: true });
    await pc.setLocalDescription(offer);

    const res = await fetch("/signal", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ sdp: offer.sdp, type: offer.type }) });
    if (!res.ok) throw new Error("signal failed");
    const answer = await res.json();
    await pc.setRemoteDescription(answer);
  } catch (e) {
    console.error("webrtc error", e);
    alert("接続に失敗しました。再試行してください");
  }
}

pc.oniceconnectionstatechange = () => {
  if (["failed", "disconnected"].includes(pc.iceConnectionState)) {
    // フェイルオーバー、リトライ、切断ログ送出
    fetch("/metrics", { method: "POST", body: JSON.stringify({ evt: "ice_fail" }) });
  }
};

医療向けのSLA例として、接続確立p95 3秒以内、音声ジッタp95 30ms未満、動画フリーズ率1%未満、MOS 4.0以上といった目標を置くと現場満足度が高まりやすい。計測はクライアントのgetStatsとサーバ側のRTT/パケットロスから行い、閾値越え時は自動的にビットレート・解像度を段階的に下げて維持します。“切れない診療”はレイテンシの絶対値よりも変動の小ささで決まります。

セキュリティと同意：ゼロトラストとポリシー駆動

遠隔医療はデータの流通点が増えるため、ネットワーク境界に依存しないゼロトラストが前提になります。IdPで多要素認証、デバイス姿勢の検証、ネットワークはmTLS、リソースは属性ベースのアクセス制御（ABAC）で守る構えです。FHIR Consentをトークンのクレームに変換し、ポリシーエンジンで一貫して評価すると実装負債が減ります。日本の公的ガイドラインでも、情報システムにリモートアクセスする場合はVPN等の経路暗号化と多要素（ICカード・電子証明書・パスワード等）による強固な認証を求めています⁷。また、監査の観点では“誰が・いつ・何に・どの経路で”触れたかを明確化し、運用規程で役割と責任を定義することが示されています⁸。

# Example 5: OPA/RegoでConsentクレームを評価
package authz

default allow = false

allow {
  input.token.scope[_] == "patient/*.read"
  input.token.claims.consent == "active"
  input.resource_type == "Observation"
  input.action == "read"
}

deny[msg] {
  not allow
  msg := sprintf("deny %s on %s", [input.action, input.resource_type])
}

監査は“誰が・いつ・何に・どの経路で”触れたかを、アプリ・APIゲートウェイ・ネットワークの三層で相関可能に保つのが実務です。監査可能性は後付けでは達成できません。

クラウド基盤：セキュア・監査可能・コスト予測可能

医療データのクラウド移行は、暗号化・分離・監査の3点に尽きます。保存時暗号化はKMSの顧客管理キー、通信はTLS1.2+、実行はプライベートサブネットでのワークロード分離が基本です。ネットワークの外縁にはWAF/IdP連携を置き、データは用途ごとのレイクとマートを分け、アクセスは行・列レベルで制御します。コストはストレージと送受信、そしてTURNの転送費がボトルネックになりやすい。TURNは1セッションあたり上り下り合計で数百kbps〜数Mbpsを消費し、ピーク時の同時接続数に比例します。

# Example 6: Terraformで医療向け最小VPC + RDS
provider "aws" { region = var.region }

resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" }
resource "aws_subnet" "priv_a" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" map_public_ip_on_launch = false }
resource "aws_subnet" "priv_c" { vpc_id = aws_vpc.main.id cidr_block = "10.0.2.0/24" map_public_ip_on_launch = false }

resource "aws_db_subnet_group" "rds" { subnet_ids = [aws_subnet.priv_a.id, aws_subnet.priv_c.id] name = "rds-sg" }
resource "aws_db_instance" "ehr" {
  allocated_storage = 200
  engine = "postgres"
  engine_version = "14"
  instance_class = "db.m6g.large"
  db_subnet_group_name = aws_db_subnet_group.rds.name
  storage_encrypted = true
  kms_key_id = aws_kms_key.data.id
  publicly_accessible = false
  multi_az = true
}

resource "aws_kms_key" "data" { description = "EHR data CMK" }

resource "aws_cloudtrail" "trail" { name = "audit" s3_bucket_name = aws_s3_bucket.audit.id include_global_service_events = true }
resource "aws_s3_bucket" "audit" { bucket = "audit-logs-example" }

運用ではCloudTrail/Config/GuardDutyでの継続監査を行い、アラートはSOARで自動チケット化して対応の抜け漏れを防ぎます。性能のボトルネックはDB IOとAPIのインデックス戦略に収束するので、Query p95 200ms、API p95 300ms、WebRTC接続p95 3秒というベンチラインを置き、超過時は自動的にスケール・キャッシュ・インデックス再評価の順に適用します。クラウドの“伸縮”は、監査とSLAの文脈で制御してはじめて価値になります。

異常検知と内偵監査：行動分析の実装

不正閲覧やアカウント乗っ取りは“普通でない閲覧パターン”として現れます。患者と担当科の紐付け、時間帯、端末指紋、アクセスの地理が鍵になります。ルールと学習のハイブリッドで擬陽性を抑えつつ早期検知を目指します。

# Example 7: 監査ログからの簡易異常検知（Py）
import pandas as pd
from sklearn.ensemble import IsolationForest

logs = pd.read_parquet("s3://audit/logs/date=2025-08-29/")
features = logs[["hour", "dept", "patient_match", "device_risk", "geo_distance_km", "method"]].copy()
features["dept"] = features["dept"].astype("category").cat.codes
features["method"] = features["method"].astype("category").cat.codes

model = IsolationForest(n_estimators=200, contamination=0.005, random_state=42)
logs["anomaly"] = model.fit_predict(features)
alerts = logs[logs["anomaly"] == -1][["user", "resource", "timestamp"]]
print(alerts.head())

本番では役割に基づく許容リストと患者担当表とを付き合わせ、アラートの優先度を三段階に分けて運用します。異常検知の価値は“即応できる運用導線”とセットで生まれます。

ROIと導入ロードマップ：小さく始めて早く測る

医療DXの投資は、業務時間の短縮、重複検査の回避、請求エラーの減少、紹介・連携の高速化に回収ポイントがあります。海外事例では、紹介状作成の自動化や画像連携により作業時間の短縮が報告され⁴、遠隔医療は通院困難層の受診継続率を高め、一定の診療領域でキャンセル率の低下が観察されたとする報告もあります⁴。一般的な試算例として、FHIR対応APIとWebRTCのプラットフォームをマルチテナントで展開し、1施設あたり月500セッション・平均15分・TURN帯域平均1Mbpsで見積もると、ネットワーク費が全体コストの2〜3割を占めやすく、最適化の余地が大きい。動画ビットレートの動的制御と録画の選択制、オフピークに寄せたバッチを重ねるだけで、ピーク帯の転送費を約20〜30%圧縮できる可能性があります。

ロードマップは段階的に、まずFHIR Read/Searchのスライス導入で“見る”価値を早期に提供します。次にConsent/SMARTで“安全に使わせる”枠組みを固め、HL7 v2インジェストと増分正規化で“貯める”仕組みを整えます。その後WebRTCで“つなぐ”診療を実装し、最後に監査・異常検知で“守る”を強化すると、各段階で成果を可視化しながら進められます。1四半期ごとにKPIをレビューし、p95遅延・セッション成功率・作業時間短縮・重複検査率の4指標で投資対効果を測ると意思決定が鈍りません。

関連リソースと深掘り

FHIRの基本とスキーマ設計は概観できます。WebRTCのSFU/MCU選定や帯域制御は参考になります。ゼロトラストと医療データ保護の設計も併せてご覧ください。

まとめ：技術の“正しい小ささ”で始める

医療DXは壮大に見えますが、実装は驚くほど具体的な小さな積み重ねです。FHIRで必要な情報を確実に取り出し、SMARTで最小特権を守り、WebRTCで切れない会話を確保し、クラウドで監査とコストの見通しを立てる。“小さく始めて、確実に測り、継続して改善する”というエンジニアリングの王道が、最終的に患者の安全と現場の余裕を生みます。あなたの組織にとって最初の一歩は何か。次のスプリントで扱うKPIを一つだけ決め、この記事のコードを検証環境で動かしてみてください。手触りのある小さな成功が、現場の合意形成を最も速く前に進めます。

参考文献

  1. Office of the National Coordinator for Health Information Technology (ONC). National Trends in Hospital and Physician Adoption of Electronic Health Records. https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records
  2. WICレポート（厚生労働省 2023年医療施設調査の解説）一般病院における電子カルテ導入状況の概況. https://www.wic-net.com/report_view/4808/2.html
  3. The Commonwealth Fund. The Impact of the COVID-19 Pandemic on Outpatient Visits: 2020. https://www.commonwealthfund.org/publications/2020/apr/impact-covid-19-pandemic-outpatient-visits
  4. McKinsey & Company. Telehealth: A quarter-trillion-dollar post-COVID-19 reality? https://www.mckinsey.com/industries/healthcare/our-insights/telehealth-a-quarter-trillion-dollar-post-covid-19-reality
  5. HealthIT.gov. Fast Healthcare Interoperability Resources (FHIR). https://www.healthit.gov/topic/standards-technology/standards/fhir
  6. HL7. SMART App Launch: Scopes and Launch Context (v1.0.0). https://hl7.org/fhir/smart-app-launch/1.0.0/scopes-and-launch-context
  7. 厚生労働省. 医療情報システムの安全管理に関するガイドライン（2004年12月）リモートアクセスと暗号化・多要素認証に関する記載. https://www.mhlw.go.jp/shingi/2004/12/s1222-14c2.html
  8. 厚生労働省. 医療情報システムの安全管理に関するガイドライン（2004年12月）監査ログ・運用規程に関する記載. https://www.mhlw.go.jp/shingi/2004/12/s1222-14c2.html