open-ocean-20

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

 かなり放置していたのだが、先日、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 というテーブル。おそらくここが患者さんの基本情報を永続化しているテーブルだと...

Medical note と Medley 以前は両社とも東大医卒外資コンサル会社出身という経営者を頂いているせいか最近まで個体識別ができなかった。 ただ、ここにきて、方向性に違いが出てきたようだ。   メドレー ここの良いところは自己修正がきくところだろう。 いつぞや、経営者がトンデモな発言をしたのだが、不興を買ったとみるや周囲のものがさりげなく　 developer.medley.jp 　とフォロー。 こういうことができているところは、健全だ。 メディカルノート などと言っていたら、メディカルノート、これまで代表取締役だった木畑氏を降ろして、派遣やコンサルのような事業は縮小廃止に向かうようだ。 この会社、社名にもあるように、そもそも「医師による情報発信のプラットフォーム」というのが基本であり、これは良い方向転換ではないだろうか。 最近では「医療ベンチャーのためのプラットフォーム」の看板を打ち出しており、成長を感じさせる。 （追記）メドレーは、例の文春の事件があったため、あえなくトップ交代。 どうなることやらと推移を見守っていたのだが、私の周囲では好評価。 CLINICS の技術情報なども開発者ブログで発信するようになったし、OpenDolphin の取り扱いも制約がある中では「よくやっている」という声をよく聞く。 「東大医卒外資コンサル会社出身」がいなくなった後の方が、のびのびやれている印象を受ける。 venture-spirit