縁際誠（えんぎわまこと）の日々の気づきと記録

タグ: 電子カルテ

  • 昔開発した電子カルテアプリを AWS 上で復元し、リモートDB接続するまでの全手順まとめ

    この記事は、2000年代の旧電子カルテアプリを AWS 上で再構築し、Windows2000の VM から リモートで PostgreSQL に接続するところまで成功した技術ログです。

    成功・失敗・試行錯誤すべてを “備忘録として残す” 目的でまとめています。

    1. 目的

    • 旧電子カルテ（Windows2000 + PostgreSQL）の環境を検証目的で復元したい
    • AWS 上に Windows Server を構築し、DB を立ち上げる
    • Windows2000（VM）の電カルアプリから リモートで DB に接続できるか検証
    • できればアプリも起動させたい
    • 最終的には DB を別用途で使えるようにすること

    2. AWS 側の構築

    ■ Windows Server 2022 を EC2 で構築

    • インスタンスタイプ：最初 t3.medium
    • ElasticIP：今回は 使用しない（検証環境のため割り切り）

    ■ ネットワーク設定

    • セキュリティグループで PostgreSQL ポート（5433）を開放
    • ただし 自分のグローバルIP のみに限定
      （→ リスク最小限でパブリックIP接続を許可）

    3. PostgreSQL 8.x の構築

    ■ 3-1. PostgreSQL 8.2 → インストールエラー

    管理者実行トラブル等あり断念

    ■ 3-2. PostgreSQL 8.4 で再構築

    安定して動作。

    ■ 設定（postgresql.conf）

    listen_addresses = '*'
port = 5433

    ■ pg_hba.conf

    host all all 127.0.0.1/32 md5
host all all <自分のグローバルIP>/32 trust

    AWS 内でも psql による接続確認：

    .\psql.exe -h 127.0.0.1 -p 5433 -U postgres
→ 接続成功

    DB が正常に起動していることを確認。

    4. Windows2000（VM）からのリモート接続テスト

    ここが今回の記事の中心となる「成功ポイント」。

    ✔ 4-1. 電カル側の接続先を AWS のパブリックIP に変更

    開発した電子カルテは起動時のログイン画面で DB 認証を行うため、
    以下を設定：

    Server = <AWSのパブリックIP>
Port = 5433
User = postgres（または設定したアカウント）

    ✔ 4-2. セキュリティグループで 5433 を “自分のIP のみ許可” に設定

    → 全世界に開くことはせず、
    　検証用途として最低限のリスクに限定

    ✔ 4-3. リモート接続結果 → 成功！

    Windows2000 上で電カルを起動すると：

    • ログイン画面が出現
    • 認証成功
    • DBと正常通信を開始

    つまり、

    Windows2000（VM） → AWS PostgreSQL（パブリックIP）

    という「リモートDB接続」に成功した。**

    これは今回の大きな成果。

    5. SSHポートフォワード方式も検証（結果：不採用）

    ■ 5-1. ホストPC から PowerShell で SSHトンネルを作成

    ssh -L 5433:127.0.0.1:5433 <AWSユーザー>@<EC2 Public IP>

    ■ 5-2. トンネル自体は成功（netstat の LISTENING も確認）

    Win2000 からの telnet も通った。

    ■ 5-3. しかし電カルアプリは DB に接続できず

    原因は複合的：

    • Windows2000 の TCP/IP スタックが現代 SSH トンネルと相性悪い
    • ODBC/INI の参照位置が複雑
    • VM の NAT → Host-only のルーティング
      など。

    結論：
    パブリックIP で接続できていれば、SSH トンネルにこだわる必要はない。

    → 今回の目的の範囲では“不採用”と判断。

    6. 電カルアプリ起動結果

    • ログイン：成功（リモートDB接続成功の証拠）
    • メイン画面：表示されるが ストアドプロシージャの互換性エラー多発
      • 電子カルテアプリのロジックが DB（PostgreSQL 8.4）に依存
      • 古い関数や PL/pgSQL の仕様変更で動作不可

    → アプリとしての実用は困難 と判断。

    7. 今後に向けて

    • 医療DBの構造分析研究
    • FHIRリソースへのマッピング研究
    • データ移行の検証
    • システム設計の参考資料
      として活用していこうと思う

    8. まとめ（今回得た成果）

    ✔ 電カル → AWSリモートDB接続に成功（パブリックIP経由）

    ✔ 電カルアプリ起動までは再現できた

    ✔ DBは完全に生きており、別用途で利用する予定

    ✔ SSHトンネルは技術的には張れたが、旧OSとの相性で実用不可

    ✔ 検証としては十分以上の成功

  • AMIコピーから電子カルテ用 Windows Server を再構築する手順（実践録）

    はじめに

    今日は、AWS 上に 電子カルテアプリを載せるための Windows Server を再構築する作業 を行いました。

    元となるサーバはすでに別用途で構築済みで、それを AMIコピーして流用する ところからスタート。
    ただ、コピーしただけではアプリや設定が残ってしまうため、

    「クリーンで、SSM だけで完全管理できる Windows Server テンプレート」

    を作ることを目的に作業しました。

    この記事では、その再構築の流れを記録としてまとめます。

    ■ 1. AMI コピーからの新規 EC2 起動

    まず、既存サーバの AMI をもとに新しいインスタンスを起動しました。

    • インスタンスタイプ：t2.medium
    • セキュリティグループ：インバウンドなし（後でRDP削除）
    • キーペア：既存のものを流用
    • IAM ロール：Systems Manager が動作するロールを再割り当て

    これにより、元サーバと同じ構成をもったインスタンス が立ち上がります。

    ■ 2. コピー元アプリ（RSBASE など）の完全削除

    AMI コピー元には、もともとテスト用途のアプリが入っていたため、
    新しいサーバではこれをすべて削除し、電子カルテ用サーバとしてクリーンにしました。

    • RSBASE のアンインストール
    • 対応フォルダの削除
    • 残存レジストリの確認（不要なものをクリア）

    この時点で、

    “アプリが何も入っていない、空の Windows Server”

    の状態に戻りました。

    ■ 3. ディスク構成の整理（Cドライブ + Dドライブ）

    コピーされたサーバは C:80GB / E:20GB の構成でしたが、
    内容を削除したため E ドライブをフォーマットし、新しい D ドライブとして再構成。

    結果：

    • Cドライブ：80GB
    • Dドライブ：20GB（アプリやログ用に利用）

    ※Cドライブは80GBより縮小できないため、今回は現状維持。

    ここは将来的に「スリム版テンプレート」を作るときに再検討します。

    ■ 4. Session Manager（SSM）が動作しない問題の修復

    AMI コピー直後は SSM Agent がオフライン になっており、
    Session Manager で接続できない状態でした。

    PowerShell で確認すると amazon-ssm-agent.exe がうまく動いていない。

    そこで以下の対処を実施：

    1. TLS 1.2 の有効化
    2. 正式 URL から SSM Agent を再インストール
    3. サービス再起動
    4. IAM ロールの再割り当て確認

    再インストールコマンド例：

    $installer = "$env:TEMP\AmazonSSMAgentSetup.exe"
Invoke-WebRequest "https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/latest/windows_amd64/AmazonSSMAgentSetup.exe" -OutFile $installer
Start-Process $installer -ArgumentList "/S" -Wait
Restart-Service AmazonSSMAgent

    これで SSM がオンラインに復帰。
    Session Manager 接続が無事成功しました。

    ■ 5. RDP ポートを完全に閉じる（インバウンド0）

    SSM が動作した時点で、RDP は管理上不要となったため、
    セキュリティグループの 3389 を削除。

    結果：

    • インバウンド完全ゼロ
    • Session Manager のみで管理
    • 医療機関でも安心して使えるセキュア構成

    AWS が推奨する「RDP を開けない運用」が実現しました。

    ■ 6. Session Manager での RDP（ポートフォワード）も同時検証

    必要に応じて RDP を使う場合は、
    Session Manager の ポートフォワード で利用できることも確認。

    例：

    aws ssm start-session \
  --target i-xxxxxxx \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["3389"],"localPortNumber":["23389"]}'

    これにより、

    • EC2 → 3389
    • ローカル → 23389

    のトンネルが張られ、
    localhost:23389 を RDP クライアントに入力すると GUI ログインが可能。

    重要なのは、

    AWS側の設定変更は不要で、ローカルポートを変えるだけで複数サーバへ同時接続できる

    という点。

    ■ 7. 電カル用の “初期 Windows Server AMI” を最終作成

    すべての不要要素を削ぎ落とし、SSMの動作も安定したタイミングで、

    • Windows Update 済み
    • インバウンド0
    • SSMのみで管理可能
    • 余計なアプリなし
    • ディスク整理済み

    という 理想的な“初期テンプレート” の状態が完成。

    この状態を改めて AMI 化し、今後
    電子カルテサーバの標準構築テンプレート
    として利用できるようにしました。

    ■ まとめ

    今回の作業で、

    「爽快なまでに真っさらな Windows Server」
    「SSMのみで完全管理できるセキュア構成」
    「即量産できる初期AMI」

    の3つが完成しました。

    電子カルテ、医療アプリ、オンプレ連携など、
    どんな用途にも適用できる理想的なベースサーバが手に入りました。

    今後は、このテンプレートを軸に構築を加速していきます。