PDF医療記録をFHIRデータに自動変換するサーバーレスパイプライン構築ガイド（Bedrock + HealthLake）

はじめに：なぜ医療記録のデジタル化が重要なのか

日本の医療現場でも、未だに紙の診療録が広く使われています。患者が別の病院に転院するたびに、手動でデータを入力したり、FAXで紙を送ったりするケースが後を絶ちません。これにより診療の遅延、重複検査、患者安全上のリスクが生じています。

主な課題:

• 手動データ入力はコストが高く、エラーが発生しやすい
• 非構造化ドキュメント（PDF、スキャン画像）から臨床情報を抽出するのは技術的に困難
• 病院ごとに異なるフォーマットを処理するには、個別のMLモデルやテンプレートが必要

本記事では、Amazon Bedrock Data Automation (BDA) と AWS HealthLake を使用して、PDF医療記録をFHIR R4標準データに自動変換する 完全サーバーレスパイプライン の構築方法を解説します。別途MLモデルを学習させることなく、20分でデプロイ可能です。

注意: 本ソリューションは教育目的であり、合成データ(synthetic data)のみを使用してください。実際の患者データ(PHI)を扱う場合は、追加のHIPAAセキュリティ対策が必要です。詳細は原文ブログをご参照ください。

この記事で学べること

• サーバーレスイベント駆動型アーキテクチャの設計パターン
• Bedrock Data Automationを使ったAIベースのデータ抽出
• FHIR R4形式への変換とHealthLakeへの取り込み
• 実運用を想定したセキュリティ考慮事項とコスト管理

アーキテクチャ概要：イベント駆動型サーバーレスパイプライン

本ソリューションは完全にイベント駆動で動作します。スケジューラやオーケストレータを必要とせず、各ステップが自動的に次のステップをトリガーします。

コアAWSサービス

処理フロー

1. PDFアップロード → S3入力バケット
2. S3イベント → BDA Lambda関数トリガー
3. BDA処理 → 50+ 臨床フィールド抽出（信頼度スコア付き）
4. JSON保存 → S3出力バケット
5. S3イベント → FHIR Processor Lambdaトリガー
6. FHIR変換 → FHIR R4 Bundle (JSON + NDJSON) 生成
7. HealthLake Import → NDJSON取り込みと検証
8. FHIR APIアクセス → 標準エンドポイントでデータ照会

デプロイ手順

PoetryとAWS CLIがインストール済みであれば、以下の4コマンドでパイプライン全体をデプロイできます。

# 1. リポジトリのクローン
git clone https://github.com/aws-samples/amazon-bedrock-data-automation-healthcare-samples.git
cd amazon-bedrock-data-automation-healthcare-samples

# 2. Poetryで依存関係をインストール
poetry install

# 3. AWS認証情報を設定（既に設定済みの場合はスキップ）
aws configure

# 4. CloudFormationスタックをデプロイ（us-east-1またはus-west-2リージョン必須）
poetry run cdk deploy --region us-east-1

FHIRデータ照会のPythonコード例

import boto3
import requests
from requests_auth_aws_sigv4 import AWSSigV4

# AWS HealthLakeデータストアのエンドポイント
healthlake_endpoint = "https://your-healthlake-endpoint.east-1.healthlakeaws.com"
datastore_id = "your-datastore-id"

# SigV4認証
auth = AWSSigV4('healthlake',
                region='us-east-1',
                credentials=boto3.Session().get_credentials())

# 患者データの照会
response = requests.get(
    f"{healthlake_endpoint}/datastore/{datastore_id}/r4/Patient",
    auth=auth
)
print(response.json())

# 特定の診断名でConditionを検索
response = requests.get(
    f"{healthlake_endpoint}/datastore/{datastore_id}/r4/Condition?code=ICD-10:I10",
    auth=auth
)
print(response.json())

実務適用時の注意点と限界

1. 日本の医療IT環境における適用コンテキスト

日本では 医師法、個人情報保護法、そして 医療情報システムの安全管理に関するガイドライン が厳格に適用されます。AWS HealthLakeはHIPAA準拠サービスですが、日本の規制を満たすためには追加の検討が必要です。

• データローカライゼーション: 日本の医療機関では、患者データを国内で保存することが強く推奨されます（「医療情報システムの安全管理に関するガイドライン」第5版）。しかし、Amazon Bedrock Data Automationは現在 us-east-1 と us-west-2 でのみ利用可能であり、東京リージョン（ap-northeast-1）では直接使用できません。日本リージョンでのBDA提供が開始されるまでは、概念実証（PoC）に限定した利用が現実的です。
• SS-MIX2 / HL7v2との互換性: 日本の医療現場では標準的にSS-MIX2やHL7v2形式が使われていますが、本ソリューションはFHIR R4をターゲットとしています。両者を橋渡しするには、別途変換レイヤー（FHIRコンバータなど）が必要です。
• 個人情報保護法: 医療情報は「要配慮個人情報」に該当します。AWSとの間で 業務委託契約 を締結し、データ処理の目的・範囲を明確にする必要があります。

2. 技術的な限界と注意点

• 信頼度スコアの活用: BDAは各フィールドに0.0〜1.0の信頼度スコアを付与します。信頼度が低い（例：0.7未満）フィールドは自動変換せず、人間によるレビュー（Human-in-the-loop） に回す設計が安全です。以下はFHIR Processor Lambdaに追加するフィルタリングロジックの例です。

# 信頼度ベースのフィルタリング例
CONFIDENCE_THRESHOLD = 0.7

if field.confidence < CONFIDENCE_THRESHOLD:
    # 低信頼度フィールドは別のS3バケットに保存し手動レビュー
    send_to_review_queue(field)
else:
    # FHIR Bundleに含める
    add_to_fhir_bundle(field)

• PDF品質への依存: BDAはスキャンPDFでも良好に動作しますが、手書き文字が極端に不鮮明な場合や文書が破損している場合は抽出精度が低下します。そのようなケースでは、Amazon TextractなどのOCR前処理を追加することを検討してください。
• コスト管理: 100ページ/月で約$50-100、10,000ページ/月で約$2,000-3,000のコストが見込まれます。テスト後はCloudFormationスタックを削除し、AWS Budgetsアラートを設定することを推奨します。

3. 次のステップとしての学習方向

このパイプラインを拡張するには、以下を検討してみてください：

1. SQSバッファの追加: 大量PDFアップロード時のBDA同時実行制限を管理するため、S3イベントとLambdaの間にAmazon SQSをバッファとして挿入
2. StepFunctionsによるオーケストレーション: エラーハンドリング、リトライロジック、低信頼度抽出の人間レビューへのルーティングをAWS Step Functionsで実装
3. Kinesisによるリアルタイム処理: 複数ソースからの継続的な取り込みが必要な場合はAmazon Kinesis Data Streamsを使用
4. 既存EHRとの連携: FHIR APIを介して既存の電子カルテ（EHR）システムと統合

まとめ：今すぐ始められること

本チュートリアルでは、Amazon Bedrock Data AutomationとAWS HealthLakeを活用して、PDF医療記録をFHIR R4標準データに自動変換するサーバーレスパイプラインの構築方法を解説しました。

要点まとめ:

• テンプレート不要: BDAがドキュメント構造を自動理解するため、病院ごとに異なるフォーマットに対応するための個別MLモデルやテンプレートが不要
• 完全サーバーレス: Lambda + S3イベント駆動型アーキテクチャにより運用負荷が最小限で、各ステージが独立してスケール
• 標準準拠: FHIR R4標準に準拠しているため、既存のEHRシステムとの統合が容易
• 責任共有モデル: AWSはインフラセキュリティを担当し、お客様はデータセキュリティとコンプライアンスを担当します。実際の患者データを扱う前に、HIPAAおよび日本の規制要件を必ず確認してください。

日本の開発者へのアドバイス: 現時点では日本リージョンでBDAを利用できませんが、このアーキテクチャはクラウドニュートラルに設計されています。今後日本リージョンでBDAが提供開始されたとき、あるいは類似機能を持つ国産クラウドサービスが登場したときに、この構造をそのまま適用できます。今は合成データで概念実証（PoC）を進め、知見を蓄積しておくことをお勧めします。

合わせて読みたい記事

• スポティファイがAIコーディングエージェントで1,800のデータパイプラインを10週間で自動移行した方法
• 2026年第1四半期、世界中のインターネットを麻痺させた7つの衝撃的な出来事