（注意）下記の記事では
機能追加や細部の改変はしてもデータ構造や通信様態は本家を尊重する
と言い切ってますが、画像が JPEG でしか保存できないのは、今の時代にあってないので、今後はここら辺は変更する予定です。
そもそも java17 では、画像処理周りの古いコードが原因でサーバープログラムを少々手直しした程度ではアプリケーションサーバ（WildFly）にデプロイすらできないと思います。
Docker 版 OpenDolphin サーバは人気が高いようなので、OpenOcean クライアントとつないでみました。
クライアントのダウンロードページはこちら。
「機能追加や細部の改変はしてもデータ構造や通信様態は本家を尊重する」という方針なので、当初、「そんなに難しくない、何もしなくてもつながる」くらいに思っていたんですが、初試行では見事につながりませんでした。
ログイン情報が違ってます
の嫌なアラートが….。
しばらく、頭上に？浮かばせてましたが、Docker の Dolphin （WildFly）が吐き出してくれるログに手掛かりがありました。（Docker 版でも設定でログを表示させることができます）
web context '/dolphin'という見慣れぬ表記が。これ通常だと openDolphin なんですよね。
なのでソースの該当箇所を修正。Docker 版と商用版ではここがちがっていたわけですね。通りでつながらないわけだ。
修正後は、無事つながりましたが、当方の通信環境はそれほどよくなく（たぶんルータの性能がいまいち）一台のPC（win10）上に
- クライアント Ocean クライアント windows10 (ホスト)
- サーバ Dolphin サーバ(Docker) Ubuntu14 (VMWare の仮想マシン)
- ORCAサーバ ORCA Ver5 Ubuntu16 (VMWare の仮想マシン)
が混在するという二度とやりたくないような構成になりました。なりゆき上。
ただ、データ構造さえ同一に保っていれば、出自が異なっていたとしても接続は問題なくできるわけで（少々、苦労はしますが）、互換性という点でもオープンソースはメリットがあるなと思います。
なお、ここらへんの機種間の API の差を埋める目的で HL7 （エイチエルセブン）という団体が FHIR という仕様を公開してます。
一瞬、なるほど、と思ったのだが、これを採用しても、肝心かなめのデータの構造がやり取りする両者で同一でないと院内システムへは結局復号化できないまま終わってしまうような…。まあ、医療情報の「交換」規格というコンセプトが強いんでしょうね。
ユーロ圏内や北米などでは、圏内での人の移動や移民の問題などがあり、こういったシステムの構築は必要性が高いんでしょう。
同じ問題にぶつかり、これが問題であったのかとハッとさせられたのですが、修正するソースファイル名が何かがわかりません。恐れ入りますが教えていただけませんか？
いるかさん、投稿ありがとうございます。
かなり昔のことなんですが、クライアントのコンテクストを設定している箇所を変えた記憶があります。
現在、当直中ですので、回答までしばしばお待ちを。
とりあえず、覚えている点をメールしました。