カテゴリー: 電子カルテ

  • openDolphin PoCとORCA連携を試みて分かったこと

    ― AWS/Ubuntu 22.04/CLAIMの壁 ―

    はじめに

    オープンソース電子カルテ openDolphin を用いた PoC(概念実証)として、AWS上に構築した ORCA との連携(CLAIM接続)を試みた。

    結論から言えば、
    今回の構成では openDolphin と ORCA の連携は見送りとした。

    ただしこれは「失敗」ではなく、
    技術的に確認すべき点をすべて確認した上での判断である。

    本記事は、
    その過程を 記録として整理したものであり、
    同様の検証を行う人への参考、
    また医療IT理解のための資料として残すことを目的としている。


    検証の前提条件

    openDolphin 側

    • Windows Server 2022
    • サーバ/クライアント同居構成
    • PoC用途(本番想定なし)

    ORCA 側

    • AWS EC2
    • Ubuntu 22.04 LTS(Jammy)
    • ORCA公式手順書(Jammy版)に従って構築
    • 診療データは自分自身のテストデータのみ

    目標

    • openDolphin と ORCA を CLAIM(8220/8221)で疎通確認
    • 本格連携ではなく「疎通レベル」での確認

    まず結論

    • AWS上の Jammy ORCA では、CLAIM受信が有効になっていなかった
    • openDolphin は実質的に CLAIM前提設計
    • 今回の ORCA 構成では、後付けで CLAIM を有効化するのはリスクが高い
    • よって openDolphin PoC は ORCA 非連携で進める という判断に至った

    実際に起きたこと(技術的事実)

    CLAIM疎通確認

    nc -vz <ORCA_PRIVATE_IP> 8221
    

    結果:

    Connection refused
    
    • ネットワーク到達性はある
    • しかし ORCA 側で 8221 が LISTEN していない

    CLAIM設定ファイルの不存在

    ls /etc/jma-receipt/claim/
    

    結果:

    No such file or directory
    
    • 従来の ORCA(CLAIM前提構成)で存在するはずのディレクトリがない

    jma-receipt パッケージの不在

    apt-cache policy jma-receipt
    

    結果:

    パッケージ jma-receipt が見つかりません
    
    • 旧来の CLAIM 前提 ORCA パッケージ体系ではなかったことが確定(自分のローカルPCで構築したVMのORCAとは違った)

    「同じ Ubuntu 22.04 なのに違う」問題

    ローカル VM 環境では、

    • Ubuntu 22.04 Jammy
    • ORCA × CLAIM
    • RSBASE 連携

    が成立している。

    一方、AWS では成立しない。

    違いは OSのバージョンではなかった


    違いの正体:Ubuntuの「育ち方」

    整理すると、差分は以下だった。

    • ローカルVM
      • ORCA推奨の Ubuntu インストーラ
      • ORCAが暗黙に前提としている環境が揃っている
    • AWS
      • AWS公式 Ubuntu AMI
      • クラウド最適化・最小構成
      • ORCA側が想定していない初期状態

    加えて、
    ORCAから公表されているが、「CLAIM非前提」の構成が標準になっているという背景もあるのだろうか。


    CLAIMを無理に有効化しなかった理由

    理論上は、

    • 旧来の ORCA リポジトリを追加
    • CLAIM関連パッケージを導入

    という道も考えられる。

    しかし今回は以下の理由から見送った。

    • ORCAを壊すリスクが高い
    • PoC環境とはいえ、検証対象が変質する
    • 「できるかどうか」ではなく「判断材料を集める」段階だった

    openDolphin PoC のスコープ再定義

    今回の判断を踏まえ、
    openDolphin PoC のスコープを以下に再定義した。

    In-Scope

    • 受付(来院の表現)
    • 診療録作成
    • 院内オーダ入力
    • 基本マスタの考え方

    Out-of-Scope

    • ORCA連携(会計・請求)
    • RSBASE連携(画像・検査結果)
    • 実運用・本番想定

    このPoCの位置づけ

    今回の検証は、

    • openDolphin を「導入する/しない」を決めるためではなく、電子カルテとは何か医療情報システムはどう分業されているか、を理解するための PoC である

    という位置づけに切り替えた。

    特に私が所属する法人では、

    • 「電子カルテ=全部入りシステム」
    • 「ORCA=電子カルテ」

    といった誤解が多く、
    このPoCは 勉強教材として非常に有効だと判断している。


    次のステップ

    • openDolphin PoC を 教育用途として活用
    • 電子カルテ/レセコン/検査/画像の役割分担を整理
    • 本格開発は openEHR を前提に再検討

    CLAIM連携については、
    「今やらない」だけであり、
    「不要」と判断したわけではない。


    おわりに

    今回の検証で一番大きかったのは、

    できる/できないを切り分け、
    無理に進まない判断ができたこと

    だと思っている。

    医療ITは、
    技術そのもの以上に 前提条件と設計思想が支配的だ。

    この記録が、
    同じ場所で悩む誰かの参考になれば幸いである。

  • OpenDolphin 構築ログ:WildFly, PostgreSQL, クライアント接続

    電子カルテクライアントが “沈黙” した原因と、接続成功までのすべて

    本記事は、私が OpenDolphin(2.7系)を自前環境で構築するという目的で行った作業と、その過程で遭遇した“接続しないクライアント問題”を、最初から最後まで一切省略せずに記録した技術ログである。

    「OpenDolphin を触るのが初めての人」
    「評価版クライアントでハマった人」
    「WildFly で動かしたい人」

    そうした方々の参考になれば幸いである。

    ただし、オープンソースである電子カルテ「OpenDolphin」は開発を終了している。現在は  株式会社メドレーが事業を承継し、開発・サポートを行っている


    1. 作業開始:OpenDolphin を「まず動かす」ことを目標に設定

    今回の PoC の目的はシンプルだった。

    • OpenDolphin の仕組みを理解する
    • 自前で構築したAWS上のWindowsServer2022に載せたい
    • クライアントが自前サーバに接続する流れを確認したい

    そのために、まずは OS 上に単純な構成を置いた。

    使用環境

    • Windows Server 2022(両方検証)
    • Java(OpenJDK 8)
    • WildFly
    • PostgreSQL
    • 評価版クライアント(2.7.1 とされる ZIPをGitHubからダウンロードした)

    「公式手順」を参考にしながら、“できるだけ純粋な構成に近い状態” を作ることを意識した。


    2. WildFly をインストールして起動する

    2.1 まず WildFly を入手

    ダウンロードサイト:https://adoptium.net/temurin/releases/?version=8

    OpenDolphin 2.7 系で最も安定なのは WildFly 10 〜 11 です

    2.2 配置

    C:\WildFly\wildfly-26.1.3.Final

    に展開。

    2.2 起動

    cd C:\WildFly\wildfly-26.1.3.Final\bin
    standalone.bat
    

    WildFly が 8080 で起動することを確認。

    ここまでは順調。


    3. PostgreSQL を準備する

    今回の OpenDolphin は、内部的に PostgreSQL を想定している。すでに過去の電子カルテサーバでPostgresql8.4をインストールしていたため、そちらを使用した。

    3.1 DB 作成

    DB名       : dolphin
    ユーザー名 : dolphin
    パスワード : 任意

    3.2 初期データ投入(最低限)

    OpenDolphin の認証にはテーブルが必要。

    デプロイが正常終了後に初期データを投入してください

    INSERT INTO d_facility
    INSERT INTO d_users
    INSERT INTO d_roles
    

    これで「サーバ側は動く状態」が整った。

    3.3 Postgresql JDBCドライバ設定

    ①pgjdbc (PostgreSQL JDBC Driver) を入手

    ダウンロードサイト:https://jdbc.postgresql.org/download/

    PostgreSQL 8.4 なら JDBC Driver 42.x 系でも基本動作します。


    ②WildFly の module として配置

    以下にディレクトリを作成:

    C:\wildfly-10\modules\org\postgresql\main

    配置するファイル:

    • postgresql-42.7.1.jar
    • module.xml

    ③module.xml の作成

    <?xml version="1.0" encoding="UTF-8"?>
    <module xmlns="urn:jboss:module:1.3" name="org.postgresql">
        <resources>
            <resource-root path="postgresql-42.7.3.jar"/>
        </resources>
        <dependencies>
            <module name="javax.api"/>
            <module name="javax.transaction.api"/>
        </dependencies>
    </module>
    ※ resource-root path= のファイル名は、実際に置いた JAR 名に合わせてください。

    ④参照先DBの設定(WildFlyのStandalone.xmlにDataSource設定)

    C:\wildfly-10\standalone\configuration\standalone.xml を編集します。

    <drivers> の中に JDBC ドライバ登録

    <driver name="postgresql" module="org.postgresql">
        <driver-class>org.postgresql.Driver</driver-class>
    </driver>

    <datasources> に DataSource を追加

    <datasource jndi-name="java:/jdbc/dolphinDS" pool-name="dolphinDS">
        <connection-url>jdbc:postgresql://localhost:5433/dolphin</connection-url>
        <driver-class>org.postgresql.Driver</driver-class>
        <driver>postgresql</driver>
        <security>
            <user-name>dolphin</user-name>
            <password>*****</password>
        </security>
    </datasource>

    ⑤WildFly を再起動して DataSource をテスト

    standalone.batを起動して、エラーが出ていないことを確認します。エラーがある場合は、Postgresqlドライバが認識されていないか、Standalone.xmlの記述に誤りがある状態です。

    4. dolphin.war の配置とデプロイ

    GitHubからOpenDolphinをCloneしOpenDolphinのサーバファイル(warファイル)をBuildします。Buildしたwarファイルを、わかりやすい名前(例:dolphin.war)に変更して、WildFly のdeployments へコピー。

    C:\WildFly\wildfly-26.1.3.Final\standalone\deployments\

    その後、WildFlyを再起動すると、.deployed ファイル生成 され、WildFly ログで “Deployed dolphin.war” が確認できるれば、サーバ側の起動は問題なし。もし、deployファイルが作成されていない場合は、deployファイルが作成されるまでトラブルシューティングしてください

    自分自身が経験したBuildエラートラブルです

    ①postgresql-9.2-1002.jdbc4.jarをext_libにコピーして再Build

    理由:OpenDolphinのソースがPostgresql9.2のJDBCを参照していたため

    こちらでいったんBuildは正常

    このあと、デプロイしてもfailedだけが作成し続け、deployedを作成するまで苦労しました

    ②OpenDolphinが期待しているDataSource名ではない
    以下のようにPostgresDSというDataSourceを追加した

    <datasources>
        <!-- 既存の ExampleDS は残しておいて構いません -->
    
        <datasource jndi-name="java:jboss/datasources/PostgresDS"
                    pool-name="PostgresDS"
                    enabled="true"
                    use-java-context="true">
            <connection-url>jdbc:postgresql://localhost:5433/dolphin</connection-url>
            <driver>postgresql</driver>
            <security>
                <user-name>dolphin</user-name>
                <password>*****</password>
            </security>
        </datasource>
    
        <drivers>
            <driver name="h2" module="com.h2database.h2">
                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
            </driver>
            <driver name="postgresql" module="org.postgresql">
                <driver-class>org.postgresql.Driver</driver-class>
            </driver>
        </drivers>
    </datasources>

    ③Standalone.xml内のJPA のデフォルトデータソースが 空(“”) だった

    <subsystem xmlns="urn:jboss:domain:jpa:1.1">
        <jpa default-datasource="java:jboss/datasources/PostgresDS"
             default-extended-persistence-inheritance="DEEP"/>
    </subsystem>

    ④ClassNotFoundException

    failedの中を確認すると、ClassNotFoundException: Could not load requested class : org.hibernate.type.StringClobTypeというエラーが出ていた

    OpenDolphinのソースを全検索して

    @Type(type=”org.hibernate.type.StringClobType”)

    の行を

    @Type(type=”org.hibernate.type.StringType”)

    に変更して再Build、再デプロイ

    ⑤NullPointer Exceptionエラー

    failedの中を確認すると、jboss.deployment.unit.”opendolphin-server-2.7.1.war”.component.PvtService.START … EJBException: NullPointerExceptionというエラーが出ていた

    解決として、

    C:\wildfly-10.1.0.Final\custom.properties

    というテキストファイルを作成します。

    最低限、ファイルの中身には、

    # OpenDolphin basic settings
    
    # 医療機関ID(DBに入れる予定の facilityId と合わせる想定)
    dolphin.facilityId=1.3.6.1.4.1.9414.70.1
    
    # ORCA連携用(今はダミーでOK)
    claim.host=localhost
    claim.port=8000
    claim.user=ormaster
    claim.password=ormaster
    
    # ログレベルなど(あってもなくてもよいが、一応)
    dolphin.logLevel=WARN

    と記述します

    standalone.xml<subsystem xmlns="urn:jboss:domain:logging:…"> の中には、以下の内容を記述しておきます(念のため)

    <logger category="open.dolphin">
        <level name="WARN"/>
    </logger>
    <logger category="dolphin.claim">
        <level name="WARN"/>
    </logger>
    

    この後、再デプロイして確認します

    こちらを行って、サーバは正常起動しました


    5. ここからさらに問題発生:クライアントが“完全に沈黙”

    5.1 初期データをDBに投入

    この時点で、OpenDolphinのテーブルは作成されているはずです。クライアント接続に必要な認証データを投入してください

    5.2 クライアントアプリを作成する

    サーバアプリをBuildしたように、OpenDolphinのソースからクライアントアプリケーションをBuildします

    5.3 クライアントアプリを実行する

    コマンドラインから

    java -jar OpenDolphi

    しかし、トラブル発生。ログイン画面が出る。しかし・・

    • WildFly には 1 つもリクエストが来ない
    • PostgreSQL 側にもクエリが飛ばない
    • クライアントには「接続できない」というエラーすら出ない
    • ログインしても無反応(沈黙)

    この時点で、サーバ側が悪いのか、クライアント側が悪いのか、判断がつかない。


    6. 切り分け開始:「サーバは問題ない」ことを確認

    まずサーバ側を確認した。

    • dolphin.war は正しく起動
    • WildFly ログには deploy エラーなし
    • PostgreSQL も正常に接続可能
    • DB 初期データも投入済み

    つまり サーバ側は正常

    ではなぜ接続が来ない?


    7. 次の仮説:

    「クライアントは接続先 URL が固定されているのでは?」

    ここで、OpenDolphin は接続先サーバが固定されているのでは?と疑い始める。

    実際、世の中には

    • クラウド用に URL を固定したビルド
    • 体験版として接続先変更不可のもの

    が存在する。

    このOpenDolphinクライアントも、その可能性が十分ある、と思った


    8. 設定画面を開く → 一見変更できそうだが、保存されない

    クライアント右下の [設定] を開いたところ、
    「サーバ」「スキーマ」「ポート」といった項目が並んでいた。

    しかもサーバの項目は、test.open.dolphinがデフォルト

    設定変更できる雰囲気がある。

    ところが:

    • http://localhost:8080 と入力 → 保存 → 値が消えている
    • http://192.168.10.5:8080 → 保存 → 消える
    • /dolphin を書いてみる → 保存 → 消える
    • localhost を書いてみる → 保存 → 消える
    • 127.0.0.1 を書いてみる → 保存 → 消える

    これは、設定項目が「見せかけ」で実際には固定 URL に接続しているのでは?
    という疑惑が深まっていく。

    ここでしばらく時間を消費した。


    9. hosts ファイルで出口を書き換える案(緊急回避策)

    万が一、本当に URL が固定なら、

    C:\Windows\System32\drivers\etc\hosts

    で名前解決を書き換えれば、
    強制的に自前サーバへ誘導できる

    しかし、

    • 固定 URL かどうかの確証がない
    • これは「根本解決ではない」

    ため、一時保留とした。


    10. さらに試行錯誤:クライアントを自前ビルドする案

    GitHub 上の OpenDolphin 2.7m(猪俣先生開発版?)のソースを clone し、クライアントだけ自前ビルドして差し替える案も検討した。本来、サーバもBuildしなおす必要があるかもしれないが、時間を割きたくないのでいったんクライアントだけ。


    11. 決定的瞬間:

    すると、サーバの設定ができた共に、正しい設定の仕方が偶然わかった

    設定画面をもう一度よく見ると、
    項目は次のように分かれている。

    項目入れるもの
    スキーマhttp / https
    サーバホスト名または IP だけ
    ポート数字だけ(例:8080)

    ここで気づいた。

    サーバ欄に “http://” や “:8080” を入れてはいけない。
    純粋なホスト名だけを書く仕様だった。

    つまり、正しい入力はこう:

    正しい例

    スキーマ:http
    サーバ:127.0.0.1
    ポート:8080

    正しくない例(保存されず消える)

    サーバ:http://localhost:8080
    サーバ:localhost:8080
    サーバ:http://192.168.x.x/dolphin
    

    これがすべての原因だった。


    12. 正しく設定して保存 → 接続成功!

    サーバ欄を 127.0.0.1のみにし、
    ポート欄に 8080 を入力して保存。

    期待半分、不安半分でログインボタンを押す。

    WildFly ログを見ると──

    POST /dolphin/login
    200 OK

    来た。初めてクライアントが喋った。

    沈黙状態が続いていたOpenDolphinクライアントが、ようやく自前サーバに接続を開始した。

    結局、当初BuildしていたOpenDolphinのソースは、サーバをDockerで構築する簡易版だったのかもしれない(推測)

    OpenDolphin 2.7mでBuildしたクライアントアプリで電子カルテを操作してみようと思う。もしかしたら、サーバも再構築する必要があるかもしれないが、問題があった時に対応するつもり。


    13. hosts の修正は不要に

    hosts 書き換え案は不要となり、即座に元に戻した。


    14. clone した OpenDolphin ソースの扱い

    clone していたソースは、

    • WildFly に影響なし
    • クライアント実行にも影響なし
    • 今後ビルドするなら Work に移動すればよい
    • 使わないなら削除して OK

    という結論に達した。


    15. 結果:

    この環境で OpenDolphin は問題なく動作する

    サーバ:WildFly
    DB:PostgreSQL

    という構成で、OpenDolphin の認証と画面まで通った。

    「クライアントは URL 固定されている」という疑いは誤りで、
    真の原因は 設定画面の入力仕様の誤解 だった。


    16. 今回の学び(技術的教訓)

    1. OpenDolphin クライアントの設定項目は“URL”ではなく“サーバ名””IPアドレス”を入れる欄である。
    2. プロトコル(http)とポート(8080)は別欄で指定する。
    3. WildFly 側が正常でも、クライアントが正しく設定されていなければ完全沈黙する。
    4. hosts 書き換え案は“最終手段”であり、本質的な解決ではなかった。
    5. 結局のところOpenDolphin 2.7mでクライアントは再Buildしただけで、いったんはサーバ再構築は不要でした。ただ、設定の仕方が問題の核心であることもわかりました。
  • 昔開発した電子カルテアプリを 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との相性で実用不可

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