open-ocean-20

 仕事の関係でブラウザベースの DICOM Viewer を作成する必要があり、そのまま廃棄するのもどうかと思ったので、簡易 PACS 機能を付け加えてアプリにしてみました。 PaxViewer (macOS) PaxViewer (windows) で案内しているので、よかったら使ってみてください。 猪股弘明

小林慎治という人が書いたいわゆる「OpenOcean 怪文書」というものがあるのですが、反論を試みてます。 『 OpenOcean 怪文書 -GPL 誤用による違法行為教唆- 』 などご参照ください。 ところで、一連の反論系記事で一番感心されたのは、 ORCA ML でぽろっと書いたこれ。 現在での OpenDolphin のソースコード利用の指針 になります。 ver 2.2（系列） までは、表立っては使わない方がいいでしょう。 権利関係がうるさい。 ver 2.7.0b ・2.7.1 は、おそらく大丈夫です。 LSC からは以前に「GPL に従わなくてもいい」と言われたことありますが、 今だったら、念の為、メドレーに連絡とった方がいいかもしれません。 確かに、こう言ったことを言った人は今までいなかったですね。 この考え方、けっこう、好評のようです。 『 OpenOcean/Dolphin GPL LICENSE に基づくソースコード利用の指針 』 がかなりよくまとまっています。

 かなり放置していたのだが、先日、HorliX のメンテを再開した。 今回の目標は arm Mac への対応。 あまり知られていないのだが、HorliX や Horos のソースコードの大半は、いわゆるサードパーティのライブラリからなる。 このうち DCMTK というダイコムのタグ解析を一手に引き受けているライブラリが arm Mac に対応しておらず、独自に手を入れるなどして解決を図っていたのだったが、 最近のバージョンではネイティブで対応してくれた 。 これなら、取り組みやすいと気をよくして、再開した、という次第だ。 → dcmtk に手を入れても描画周りは Metal に対応できていないので、結局、新規に PHORLIX Lite というアプリを制作。 Mac App Store でも配信してますので、よかったらどうぞ。

 今でもときおり電子カルテ OpenDolphin 2.7m 系列に関して質問などが寄せられるので、代表的なものを記しておきます。 なおこれまでにもメールなどでの問い合わせには可能な限り答えてきましたが、どうしても説明が断片的になってしまうので、ある程度体系的な解説を 『 OpenDolphin-2.7m コード解説 -FileBackUpSystem と電子カルテのデータ構造- 』 に載せておきましたので、よろしくお願いします。 余裕があれば、テキスト処理系ソフトのデータのデータベースへの格納方法や医療情報の２次利用方法に関しても触れる予定です。 Q1 カルテの実体はどこにあるのか？ A1 データベース（たいてい PostgreSQL）の BLOB 領域にバイナリの形で記録されてます。 「テーブルを探したがそれらしい箇所がない」ということでこの問い合わせは多いんですが、一般のテーブルに記録させたら改変し放題になってしまうということと下記の理由でこういった設計になっていると思われます。 BLOB は B inary L arge OB ject の略です。一般に、通常のカラムに収めきれない巨大なデータ（例えば、動画共有サイトに投稿される動画データなど）は LOB として扱います。電子カルテ１レコードは理屈の上では上限がないので、カラムに収容せず、LOB として扱ったものと思われます。 なお、慣例的に Binary 型のデータを BLOB、Character 型を CLOB と呼んでいます。 ちなみに、PotgreSQL の BLOB には bytea 型と oid 型がありますが、OpenDolphin では oid 型で設計されています。 OpenDolphin のデータ記載内容は、構造化されています。SOA 領域 と P 領域に大別され、さらにSOA はテキストと図版の項目、P はオーダー項目別に構造化されています。 dolphin データベースの関与するテーブル、つまり　d_karte -> d_document -> d_module をこの順に追っていくと、類推がつくかと思います。 Q2 2.7m のファイルバックアップシステムで <P> 処方内容も書き出すようにして欲しい。 A2 既に対応済みです。 Q3 カルテ記載...

最近  ORCA  （日本医師会がソースコードを配布・公開しているレセコンソフト）を触る機会が多かったので、ついでで画面っぽいものをつくってみる。 従来の GTK を使った画面構成 GTK というのは、Linux で GUI を使うときによく用いられるライブラリです。  えーと、 ORCA の構成がわかりにくいのは、この画面をサーバー側でつくってしまうから（正確には .xml に直してクライアントに送る）。 だから、クライアント側で画面構成を変更するというのは原則できない。また、この画面は COBOLで書かれた ORCA 本体の各機能と深く結びついている（COBOL で書かれた部分が一種のコントローラーにように振舞うわけですね）。  一般的にビュー（図のような画面、UI）とコントローラーが分離できていないと、大規模なシステムには不向きだとされている。 クリニックあたりで使っている分にはよかったんでしょうけど、という話かな。 （『 ORCA Plus というレセコンユーティリティソフトをつくっていて気がついたんだが 』あたりもご参考に） ところで、ORCA に関しては一家言持っている方も多いようで、某 SNS で元になった記事を公開したときは、みなさんあれこれコメントして色々教えてくれました。 「建て増し建て増しできているから、そろそろフレームワークを見直した方がいい」みたいな意見は多かったですね。 感心したのは「開発当初の基本設計思想は、クライアント・サーバシステムでもなく MVC（モデル・ビュー・コントローラ）でもなく 汎用機アーキテクチャ だった」というコメント。各種言語のウエブアプリ系のフレームワークが洗練されてきた今から見ると、全体の構成が「あれ？」というふうに感じたりもしますが、開発当初の状況を考慮すると「なるほどなー」という感じで納得しました。 銀行の勘定系システムや（電子化される前の）定期券発行システムみたいなノリで開発されていたわけですね。 フレームワークで一部 Web アプリ化する では、適当なフレームワークを持ってきて最も単純な CRUD 操作を試してみるとどうなるか？ 対象にしたのは、public スキーマの tbl_ptinf というテーブル。おそらくここが患者さんの基本情報を永続化しているテーブルだと...