タグ: 医療IT

  • 標準化は、なぜいつも「遅れて」やってくるのか

    ― JPQRと標準型電子カルテ、そして医療の現実解 ―

    夕方、スーパーでゆうちょPayが使えなかった。

    エラーメッセージは「バーコードの有効期限が切れています」

    結局その場では理由が分からず、

    「ゆうちょPayのメンテナンスらしい」という説明で処理されたが、

    後で確認すると、ゆうちょPay側には障害もメンテナンスもなかった。

    実際、別の店舗では普通に使えた。

    SEとして見れば、原因はだいたい想像がつく。

    店舗側のPOS、あるいは決済ゲートウェイの一部不具合。

    特定の決済手段だけが落ちるのは、珍しい話ではない。

    それ自体は、正直どうでもいい。

    問題は技術トラブルそのものではなく、説明のされ方だった。

    「わからない」ではなく「誤った説明」

    現場のスタッフが原因を把握できないのは仕方ない。

    だが、「ゆうちょPayのメンテナンス」と断定的に説明されると話は変わる。

    本当は、こう言えば済んだはずだ。

    「当店側の決済システムで、一部の決済手段が不安定になっている可能性があります」

    この一言が言えない。

    あるいは言わせない運用設計になっている。

    この構造に、強烈な既視感があった。

    JPQRという「正しかったが遅すぎた標準」

    少し前、日本には JPQR という共通QR決済仕様があった。

    経産省主導で、QRコード決済を統一しようという試みだ。

    思想は正しかった。

    むしろ、かなり真っ当だった。

    店舗は1つのQRで複数決済に対応 実装の複雑さを減らす 利用者も現場も迷わない

    だが、結果としてJPQRは主役になれなかった。

    理由は単純だ。

    出てくるのが遅すぎた その時点でPayPayが市場を押さえていた 標準は「正しい」より「早い」が勝つ

    標準化は、後出しした瞬間に負けが決まる。

    そして、医療でも同じ構図が始まっている

    いま医療分野では「標準型電子カルテ」という言葉が踊っている。

    掲げられている理念は美しい。

    ベンダーロックインからの脱却、データ互換性の確保、医療DXの基盤整備、FHIR等を前提とした将来接続性

    思想そのものは、否定しようがない。

    JPQRと同じく、理念は100%正しい。

    だが、SEとして、そして医療情報学会に出席している立場から見ると、

    どうしても引っかかる点がある。

    医療の標準化で、本当に守るべき線

    ここで一つ、はっきり言っておきたい。

    医療の場合、内部DBは各社バラバラでいい。

    これは妥協ではない。

    現実を踏まえた設計判断だ。

    診療科ごとの業務差 施設規模の違い 既存資産(データ・運用・教育コスト) ベンダーごとの思想と強み

    内部DBまで標準化しようとすれば、

    移行コストは爆発し 現場は疲弊し 結局、誰も幸せにならない

    これは、医療情報学会に継続的に出ている人ほど共有している感覚だと思う。

    本当に標準化すべきなのは「その先」

    重要なのは、ここだ。

    内部は自由でいい。

    その先、データの出力先を標準にする。

    つまり、

    内部実装:各社自由 外部表現:厳密に標準 接続点(IF):明確な責任分界

    この考え方は、これまで医療情報分野で積み重ねられてきた、

    HL7 FHIR SSMIX2

    と完全に同じ系譜にある。

    標準とは、

    中を揃えることではなく、外に出すときに迷わないことだ。

    JPQRとの決定的な違いと、同じ失敗

    JPQRは、

    表(QR)を共通化しようとした しかし裏(実装・責務分界)が曖昧だった

    一方、医療で取るべき道は逆だ。

    中は触らない 外に出すところだけ縛る 責任の境界を明確にする

    もしここを誤れば、

    医療でもJPQRと同じ未来が待っている。

    看板だけの標準 実装は各社バラバラ しわ寄せは現場と情シスへ

    決済と医療の決定的な違い

    QR決済なら、使えなければ別の手段に逃げられる。

    医療は逃げられない。

    だからこそ、

    表面上は「進んでいるように見える」 問題は静かに蓄積する 最後に疲弊するのは現場

    これは技術の問題ではない。

    制度設計と標準化の哲学の問題だ。

    おわりに

    技術は嘘をつかない。

    だが、制度はときどき嘘をつく。

    「標準」という言葉は、

    現場を楽にするために使われるべきだ。

    もしそれが、

    現場を黙らせるための言葉になったとき、

    その標準化は、すでに失敗している。

  • 昔開発した電子カルテアプリを 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を推進する立場として、
    そして患者として、
    これからもこの問題を見続けていきたい。