OpenDolphinNext

以前にちょっぴり取り上げた OpenDolphinNext だが、結局、開発中止になったようです。

ちょっと目を話した隙に・・・。

ああ、なるほど、そうなっていたんですか。

A 先生=猪股弘明氏?

ところで、開発中止の告知がんされた Zenn の記事眺めていて、「A 先生=猪股弘明氏」かな?と思ったのだが、違うようです。
ご本人が ORCA ML と X ではっきりと否定していました。

確かに

OceanMini の WebORCA 連携先はデフォルトで WebORCA 公開サーバと接続する

という事実はあるのですが、

ORCAのAPIは、公式ページで公開されています。
ですが、この中にマスタデータを取得するAPIはありません。

マスタデータ取得用の隠しAPIとなっており、一般公開はされておらず、日医標準レセプトAPI協議会へ参加することで参照することができるようです。

ですが、このAPIの仕様を回避する方法があります。

WEB ORCAでは公開されていないようですが、オンプレでORCAを利用すると、PostgreSQLのデータベースコンテナが立ち上がります。
このコンテナからデータベースを直接読み出すことで、マスタデータとして利用することが、一応可能です。

クラウドにデプロイして運用する想定だと、素直にAPI通信したほうがいいと思いますが、、、

OpenDolphinNextでは、データベースをアップロードする仕様を暫定的につくったところで、終わってしまっています。

あたりの記述はとても猪股氏が言ったことのように思えず、違和感を感じていました。
しかし、上記の説明はちょっと理解しにくいですね。

・データベースコンテナを抱えている WebORCA は公式には存在しない

と認識していますし、仮にそのような ORCA があったとしても

・データベースをアップロードするのがなぜこの課題を解決することにつながるのか?

の説明に論理的飛躍があるように思えます。

OpenDolphin is finished?

一説によるとメドレーの OpenDolphinPro がサービス停止になるとのこと。
ドルフィンもその歴史的役割を終えつつあるのかなあと思います。

OceanMini の AI 連携機能

ところで、OceanMini には AI 機能(ollama 連携機能)がデフォルトで実装されているが、現状だとモデルは

model: pakachan/elyza-llama3-8b:latest

に固定である。
いわゆるエライザ。サイズが小さい割に医学分野にもそのまま使えて便利ではあった。

テストではこれでよかったのかもしれないが、そこは日進月歩の AI の世界。
モデルをユーザーが選べるようにできると応用が広がる。

先ほどリクエストをコミュニティページで提案してきた。

さて、どうなる。

 

 

 

PaxViewer

本館『Mac 向け無料 DICOM Viewer』でちらりと追記したのだが、OceanMini 開発陣が今度は DICOM Viewer をリリースした。

PaxViewer という。

導入は楽だし、使い方も直感的だしで、かなりおすすめです。

技術構成

形態としては MacOS で動作するスタンダアローンアプリ(.app)に分類されるのだが、アプリ自体にサーバを仕込んでいるので、実体はウェブアプリです。
同一 LAN 上の windows 機などはブラウザ経由でアプリが提供するサービスを利用する。

この構成は OceanMini といっしょ。
要するに「現在の LAN 環境では、Mac も win も混在している。タブレットやスマフォもある。それらデバイスにサービスを提供するにはウェブアプリしかない。これまでは Ubuntu や windows をサーバ機にすることが多かった。このアプリは、Mac をサーバマシンに仕立て上げるよ」ってことです。
意図が明快。

Mac だけで環境を構築したい、という潜在的な要望は多いので、そういう希望があるところにはうってつけです。

逆に言えば、(いないとは思うが)大規模なウェブサービスを提供したい、という用途には向かない。
そういう人は Orthanc や dcm4chee を自力で構築して頑張ってね、ということでしょう。

また、全くの個人用途で、重い画像処理をガシガシ動かしたい、なんて人も(おそらくは)対象にはしてない。
その場合には、デスクトップアプリを使えばいいので。

割り切りがいいんです。

操作感

申し分なし。

ちょっと前には HorliX を作っていた人たちですから、ここら辺はお手のものでしょう。

 

(続く)

 

2026-3

久方ぶりの日記風忘備録。

技術的コミュ障

コミュニケーション障害といえば、理系ヲタの専売特許と思われがちだが、われわれからすると「健常者の人が理系ワールドに踏み入れた時の方がひどい。ある種の人はコミュ障突き抜けて自閉症レベル」という認識だ。

最近だとここで取り上げた人がほぼ自閉症レベル。

もちろん、タームがわからないとか技術的なバックグランドがないので、単に話に乗れないという事態は除外している。

「未知の局面なのに、質問すらできない」・「自分が置かれている状況が理解できずに場にそぐわない言動をする」

あたりが特徴。

成因としては、論理的思考ができないあたりにあると思うが、そういう理論はまたの機会に。

OpenDolphin の次

結局、件のプロジェクトは大した成果も上げられず、開発中止になってしまいましたとさ。

いい話にしようという風潮もありますが、医療情報の実務よりクラスターからはボロクソ言われています。
いわく

「まるっきり、惜しくない」

「技術的な目処など全く立ってもいない」

「素人が素人に相談して解決するわけない」

などなど。

ただあ、個人的には政治的な問題もあったのかな?とは思う。
詳しい話は、これから色々出てくるでしょう。

 

AI(アシスト)製オープンソース電子カルテ

この記事この記事で話題になっている「AI(アシスト)製オープンソース電子カルテ」プロジェクトをこっそりウオッチ。

プロジェクトのオーナーは、「バイブコーディングによるオープンソースな電子カルテの制作」を狙ったようなのだが、ここでは「AI(アシスト)製オープンソース電子カルテ」とした。
完全無欠な「AI 製」ではなく「アシスト」付き。
なぜなら、データ構造の基本部分に有識者の助言ががっつり入っているから。

プロジェクト自体は、2025 年 11 月頃から始まったようなのだが、2026 年 3 月の時点で、テストの類は一切できていない。

この業界に慣れた人なら、「ああ(察し)」となると思う。

実際、kamuiOS だとか multi-agent-shogun とか流行りのツールを導入するのにほとんどのエネルギーを注いでいる。
「オーケストレーションを上手く組めば、アプリはできる」という信念があるんだろうな。
もちろん、現状の LLM の性質からしてオーケストレーションを工夫したからといってアプリができるという保証はない。
ここら辺の思考は謎だ。

たまにチェックしていこうと思う。

これ、仮に動いたところで、その瞬間に本家の方々がデータ互換性を持ったバージョンを公開すると思うので、普及する可能性は限りなく低いです。

参考

バイブコーディングで電子カルテはできまぁす!』さすがです。