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

タグ: 医療IT

  • 昔開発した電子カルテアプリを 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つが完成しました。

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

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

  • 外来が軽症患者で溢れる日本の医療は、どこへ向かうのか

    今朝、急な眼の出血で近くの眼科へ駆け込んだ。
    初めて行くクリニックだったが、症状の緊急性を理解してもらい、
    比較的スムーズに診察に進むことができた。

    だが、この受診の体験と、日頃の自分の職業（医療IT）から見える現場の実態、
    そして中医協（中央社会保険医療協議会）の議論を聴いていると、
    日本の医療が抱える構造的な歪みがどうしても気になってしまう。

    1. 外来は“軽症患者”で溢れ、本来重症を診るべき医療機関の機能が崩れている

    眼科に限らない。
    耳鼻科も、消化器内科も、循環器内科も、
    どこに行っても外来は軽症の患者であふれている。

    • 「目やにが出た気がする」
    • 「ちょっと喉が痛い」
    • 「胸がチクッとした」

    もちろん受診する権利はある。
    だが、“自由にどこへでも受診できる日本の医療” は、
    結果として大学病院でさえ軽症患者でいっぱいになり、
    重症患者が埋もれかねない構造を生んでいる。

    本来、大学病院は：

    • 重症
    • 希少疾患
    • 高度治療が必要な人
    • 地域の医療機関では対応困難な症例

    こうした“濃い症例”だけ集まる場であるはずだ。

    だが現実はまったく逆で、
    大学病院が「便利な総合外来」になってしまっている。

    そりゃ、医療崩壊するよ──
    と感じざるを得ない。

    2. 外来の“軽症依存”が医師の診察の質を奪う

    日本の医師は1日40〜60人を診ることも珍しくない。
    その9割が軽症または一時的症状の患者だ。

    その環境に慣れると、
    医師は“省エネモード”の診療が身につく。

    • パターン化された問診
    • 一般論の説明
    • 深掘りしない病歴聴取
    • 断言しない（できない）説明
    • リスクを避ける言い回し

    でも、私のように眼圧コントロールのある患者が来ると、
    医師は一瞬、空気を変える。

    これは医師の表情に出ないようで出る。
    診察モードが切り替わる瞬間は、敏感な患者には分かる。

    逆に言えば、
    普段がいかに“軽症ルーティン診療”になっているかが分かる。

    そしてその切り替わりこそが、

    「本来はもっと深く診れる医師が、日常診療に甘えてしまっている」

    という構造を露呈させる。
    私はその瞬間が少し面白く感じることがある。

    3. 医師が一般論しか言わないのは“防衛本能”でもある

    今の時代、患者はネットで大量の医療情報を持ってくる。
    SNSで医師の発言が拡散される。
    医療訴訟やクレームのリスクも高い。

    だから医師は“断言”できなくなる。

    • 一般論を話す
    • 曖昧になる
    • 深い見立ては控える

    これは医師が悪いわけではない。

    情報過多社会が医師を萎縮させた結果なのだ。

    4. 私がマイナ保険証で情報提供を拒む理由

    私は医療ITを推進する仕事をしているが、
    自分が患者として医療にかかるときは、
    診療情報・薬剤情報を共有しない設定にしている。

    理由は単純。

    医師には、患者から“自分の力で”情報を取りに来てほしいから。

    機微な情報を最初から自動で渡すと、
    問診力が鈍る。

    医師はそのために6年学び、研修し、今も研鑽を積んでいる。
    ITが“医師の力”を奪うのは本末転倒だと私は思っている。

    もちろん、診療の幅を広げるためにITを活用するのは賛成だ。
    でも、ITが医師の思考の代わりになってはいけない。

    5. 中医協を聴くと、日本の医療の未来がますます不安になる

    今日の議論でも繰り返し出ていた。

    • 「医療機関の経営が危ない」
    • 「外来数が減って収益が維持できない」
    • 「地域医療が持たない」

    医療機関が経営不安を抱えれば、
    当然 患者を“数”で集める方向に走る。

    するとどうなるか？

    • 外来はさらに軽症患者で埋まる
    • 医師の時間が奪われる
    • 重症患者は十分に診てもらえない
    • 医師はますます萎縮し、一般論しか言わなくなる

    そしてこうして、
    日本の医療は静かに崩れていく。

    6. 私が心配しているのは、“医療の本質が失われていくこと”

    医療は本来、

    • 深い問診
    • 個別の見立て
    • 医師の経験と洞察
    • 患者の背景理解
    • 丁寧な診察プロセス

    これらの積み重ねによって成り立つものだ。

    だが、外来の軽症依存と医療機関の経営不安は、
    医師からこの“本質”を奪っていく。

    そして患者もまた、
    自分が本当に必要とする医療を受けられなくなる。

    いろいろ問題はある。
    でも私は、日本の医療がどこへ向かうのか、本気で心配している。

    ◆ 結び

    今日の眼科受診をきっかけに、
    ずっと胸の中にあった違和感が一つにつながった。

    「このままでは、日本の医療は本来の姿を失う」

    医療ITを推進する立場として、
    そして患者として、
    これからもこの問題を見続けていきたい。