OpenLDAP と MacOS

dcm4chee-arc-light を触ってみて気がついたことをいくつか。

MacOS 特に arm マシンにデプロイするのは、以下の難所があるため、かなり難しい。

Apache Dirctory Studio が arm アーキテクチャに非対応

arm マシンでも動くことは動くのだが、これは JDK を x86_64 のものに変えた場合のみ。
以前から x86_64 と arm で JDK の挙動が違うというような報告はあったのだが、再度確かめられた格好だ。

ldap-utils を arm 向けにビルドできない

Linux 系では ldap-utils という便利なユーティリティソフトがあるし、そのソースコードも GitHub 上で公開されているので、arm 環境でビルドし直せばいいのかなと思ったのだが、bindletools で引っかかりますね。
ビルドしていると「OpenDirectory を使え」みたいなエラーを出してそこで止まる。

回避策

OpenDirectory で再度設定し直す、とかでしょうか。

いやあ、そんなんだったら、大人しく Ubuntu あたりにデプロイした方がいいような。

 

医師免許持ちで臨床をまったくやらない人はそれなりの理由がある場合が多い

それほど強く主張するわけではないが、この記事のタイトルみたいなことは医師界隈ではそれなりのコンセンサスは取れていると思う。

もちろん、ガチガチの基礎系の場合、意識的にやってないという人はいる
(それでも当直や老健あたりの診察業務程度ならやっている人が大半だと思うが)。

結論から言うと、キャリア初期に臨床畑に進もうとして果たせず、その後、臨床業務から離れている人は、それなりの問題を抱えている人が多い。

具体例を挙げるとわかりやすいでしょうか。

何ら経験がないのに患者さんの同意も得ずに難度の高いオペを施行して、当然、失敗。さらにそのことを隠蔽、裁判沙汰になっても自分の非を一切認めない医師。(これに近いことはたまにニュースにも取り上げられてますよね)

患者さんとまったくコミュニケーションが取れない医師。(そんな医師いないと思うでしょ? でもいるんですよ、実際。今だと面接でハジかれるとは思いますが)

・・・などなど。

で、こういった医師は、臨床現場の主流からオミットされ、いつの間にか消えているというか、行方知れずになっている場合が多い。

ところで、先日、フェイザーの方々が、こんなコメントの投稿などに関して注意喚起の記事を公開した。

著作権法違反が疑われるコメントの掲載はできかねます

細かいことには触れませんが、ここに至るまでに警告のようなことは発していたのに小林さん完全無視でしたから、しょうがないと言えるでしょう。

私も某MLに入会しようとしたとき、管理人の方から「小林慎治は喧嘩売るような感じできますから、気をつけてくださいね」とアドバイスをもらったことはある。

快く思っていなかった医師は多かったようですね。

 

ANN2b

(追記)これは某掲示板の書き込み。
出どころが出どころなので信頼性に乏しいし(まず、なにより「医者の資格はない」というのは明らかな誤り。愛媛大学第一内科に所属していたれっきとした医師)、この「小林慎治」が件の小林さんと同一かという保証はないんですが、医師-患者の信頼関係ができていないと、こういった感じの悪評立てられますね。(実際は、単なるちょっとした行き違いで患者さんが逆上して、腹いせに勢い任せで書いた、なんてのが多いんですが)

精神科なんて、こんな話は山ほどあるんで、いちいち気にしてたら身が持たないです(苦笑)。

(追記)これはある方tweet 。真偽のほどはわかりませんが、こういうことは医療現場ではよくあります。


それはともかく、旦那さんが受けた治療に大変深い憤りと不信感を持たれていることは伝わってきます。
このような事態を未然に防ぐのも医師の務めだと私は思っております。

OpenDolphin -wikipedia 風解説-

「医療用フリーソフト紹介」に OpenDolphin の項を追加しようかな?と思ってたら、LSC での販売終了のお知らせ

私がこの数奇?な運命を遂げたオープンソースの電子カルテに触ったのは比較的最近のことだ。具体的には、

猪股先生版 OpenDolphin https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m

を最近の Mac 環境に導入したときからだ。
参考:『OpenDolphin-2.7(m) を Mac OSX にインストールする

だから、きっちりとした記載をしようとするとえらく手間がかかる。
「日本初の Open Source の電子カルテ」というのがウリだったようなのだが、この点に関して「おや」と気になったことがあったので、前半はこの点を中心に気になったことを軽い感じでまとめていく。
現在では OpenDolphin をノーマルのまま単独で使う機会は減っていると思うので、後半では、これまでに明らかになった瑕疵やその改善策・発展形態に関して述べる。
なお、特別に断らない限り、ここでいう OpenDolphin とは Ver 2.7 系列をベースにしたバージョンを指しています。

歴史

経産省の助成を受けて・・・云々の話はネットで探せば出てくると思うので、省く。
ただし、地域医療ネットワークで使われていた時代と開業医向けの商用電子カルテで使われていた時代とでは、運用形態や使われている技術が大きく異なるのでこの区別は重要。

商用利用されるようになってから、いわゆる「本家」と称されている dolphin-dev リポジトリの管理会社は

digital globe → Life Science Computing(LSC) → Medley(メドレー)

と変遷している。
ただ、調べていくと、LSC 時代のある時(2018頃?)から、開発方針や対外的な協力関係は大きく変わったようだ。
前半は、俗っぽい言い方をするなら「喧嘩っぱやい」会社。権利意識が強く、実際、訴訟などもおこしていた。
商標に関しては司法的な判断も公開されており、その解説などは以下の記事を参考にあげておきます。

オープンソースと知財権に関するちょっと小難しい話


要するに LSC OpenDolphin 派生版としてA社が DolphinEvolution というプロダクツを販売していたが、「これは OpenDolphin の周知性のタダノリである」として LSC がA社を訴えたもの。
残念ながら、その結果は LSC 社が意図していたようなものにはならず、特許庁は LSC の訴えを退け、A 社の商標の保持を完全に認めている。その影響なのか、これ以降、開発体制なども刷新されたようだ。
後半は、うってかわってマイルドな路線に切り替わる。

電子カルテとしての特徴

よく
・カルテ2号用紙をメタファーとしたリッチな GUI
・使用頻度の多い項目を簡易にドラッグ&ドロップで入力できる「スタンプ」機能
が特徴としてあげられている。
これは見てもらった方が早いでしょうか。

ただし、現在(2021年)では、こういった特徴はブラウザ型の電子カルテなどにも取りいれられている。
開発時期を考えると当時としては医師目線で使いやすいシステムであったとは言えるでしょう。

技術的特徴

技術的な話も少々。
開発言語は Java で、maven で管理されている。client, common, server という三つのプロジェクトからなる。この名称から予想されるようにクライアント・サーバーシステムである。
基本となる設計は、典型的な MCV(Model-Controller-Viewer) の三層アーキテクチャである。

ただし、サーバー-クライアントの通信は主に REST API を介して行われており、クライアントは必ずしもデスクトップアプリである必要はない(後述します)。

カルテ記載内容などを記録・保存しておく必要があるため、アプリケーションサーバー(WildFly)を介してデータベース(PostgreSQL)と連携して動作する。
保存形式を決めるモデルは、具体的には上記 common プロジェクト内の infomodel パッケージで定義されている。オブジェクトをデータベースに格納させる際には、ORM である hibernate を用いている。

なお、よく「Java で作成されているためマルチプラットフォームであり、クライアントが Windows/Mac/Linux で動作する」と紹介されているが、これはやや誤解を生む表現である。サーバープログラムも pure Java で書かれているため、適切に環境を整えればサーバープログラムを Windows/Mac/Linux に設置(デプロイ)し動作させることは可能である。
以下の動画は、サーバ・クライアント共に MacOS で動かしている例。
ターミナルよりサーバの起動コマンドを入力後、メッセージが返されているのでサーバープロセスが MacOS 上で動いているのがわかると思う。

ライセンス

ところで、オープンソースにつきものといえばライセンスだが、当初は GPL というかなり制約の厳しいライセンスを主張していた。が、これも体制の刷新を契機に取り扱いを変えてきている。
もちろん GitHub のリポジトリで謳われているライセンスは現在(2021年1月)でも GPL だが、メドレー本社はこれが妥当なものであるかは明言していない。

なお、ライセンスは曖昧ながらも、他社の商用利用(soso の GlassDolphinMIA の OpenDolphin)は原則許可、技術的特徴が明示されている猪股版(いわゆる OpenDolphin-2.7m)もその配布(や情報公開など)は許可されている。名称の利用に関しても、メドレー版との相違が誤認されないように情報公開されているなど適切に取り扱われていれば、許可されている。

これは以下のような事情があったためのようだ。

GitHub リポジトリでのプルリク・コードレビューがほぼない

この記事

開発者を限定する、というのはあってもいいのだが(ニッチな分野では不特定多数の開発者をアテにはできないことがしばしばある)、そうだとしてもプルリクやマージは普通に行われる。ところが、「イルカ」ではこのプロセスがつい最近まで一切なかった。ちょうど下請けや孫請けにつくらせたコードをそのままボンッとリポジトリに送りこむかのように突如としてバージョンアップ版が出現していた。

とあって、「んな、バカな」と思っていたのだが、調べたら本当だった。
こういう調べものをするとき、GitHub などの Git ホスティングサービスは便利で誰がいつどのような変更を行ったか容易に確かめることができる。
で、調べてみると・・・


確かにわずか3件。
また、この3件のうち GlassDolphin の linuxmania さんが送ったプルリクエスト(PR)は 2.6.3 時代のもので、2.7.0 アップデートにより現在ではほぼその痕跡は残していない。
MasudaNaika(増田茂医師  当時、開業中。現在、高槻病院勤務)が送った診療区分に関する bug fix はマージ(merge プルリクエストを取り込むこと)されて、現在でも生きているが、merge されたのは 2018/6/4 のことだ。
猪股版 OpenDolphin-2.7m のソースコードがこの bug を取り除いた形で GitHub 上に公開されたのは 2016/7/12 のことだから、この修正がどれほどの意味を持つのかという気はする。
実際、現在(2021/7)では、https://www.opendolphin.com/ では以下のように増田氏の名前は見当たらない。

Ver 2.2.1 時代のソースコードも
GitHub: https://github.com/nekop/opendolphin
に残されているが、このバージョンに至っては PR の痕跡は一切ない。

オープンソースのプロジェクトとしては運営形態がかなり特殊だったという指摘はもっともに思える。

https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m/network/members より

これは、猪股先生の OpenDolphin-2.7m の開発形態と比較するとわかりやすいかもしれない。
猪股先生のリポジトリにある
https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m/
が Fork 元になって、いくつかのリポジトリに分岐(Fork 先)しているのがわかると思う。

Fork 先で新たな機能を実装したり bug fix などを行って Fork 元(上流ブランチ)にそのコードを取り込んで欲しい場合、行われるのが Pull Request (PR などと略される)というものだ。
私も Fork 後、PRを送ったことがある。
https://github.com/ANN2b-MD/OpenDolphin-2.7m
が Fork したリポジトリ。
Mac ビルド用に軽微な変更が必要があったため、ローカルでコードを修正した後、リモートのリポジトリに上げた。
以下のように PR → merge が行われた。
( https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m/pull/6


このようなプロセスは GitHub 上の操作で比較的容易に実現できる。
この仕組みのおかげで、誰がいつどのような PR を行ったのか、また、それを merge する側はどのように評価(コードレビュー)したのかわかるようになっている。
上の場合は、コードレビューと言っても thanks だけですが(笑)。

通常のオープンソースのプロジェクトは、上記のように「本家」は大抵の場合、慣例的に一つであり、そこから各 Fork 先に枝分かれ状に分岐していく。逆に言えば、どれほど分岐しようとも、Fork 元をたどっていけば必ず一つの「源流」に行き着くことができる。
このように運営することのメリットは、分岐したブランチの開発者は誰でも本家に修正したコードを送ることができる、プロジェクトの最終産物(プロダクト)のバージョンの統一性が保たれる… などがある。
デメリットとしては、PR を送ったとしても必ずしも merge されるとは限らず、提案された機能などが最終プロダクトに取り込まれないといったことが挙げられる。(例えばこの記事の『マージされなかった Pull Request の例』参照)
なお、dolphin-dev は、当初、このポリシーを取らず、ソースコード提供者を特定の開発者に限定していた。この痕跡は dolphin-dev の README の以下ような記載からも窺い知れる。


OpenDolphinにはコミッターが存在しません。フォークされた場合はそれぞれ独立した開発者になっていただき、 GitHub 等でソースの共有をお願いしています。

このような開発形態にしたため、機能の異なるいくつかのバージョンが存在するようになった。
現在でもソースが一般公開されている猪股バージョンのほか、

・入院対応が(部分的に)可能なバージョン
・音声入力機能を具備したバージョン
・クライアントでの処方箋出力機能を持ったバージョン

などがあったようである。

なかには、データベースレベルでの互換性がなくなっているバージョンもあり、メドレーから関係者に対して、この点に関しての注意がなされたという。

 

誰がソースコード提供者なのかわかりにくい

oracle のサンプルコードや公式には開発者とはされていない人のコードが散見される。

Junzo SATO 氏のコード

これは以前から指摘されていたのだが、もうちょっと網羅的に調べてみた。

Panel2.java (client project)
私のリポジトリであれば、
https://github.com/ANN2b-MD/OpenDolphin-2.7m/blob/master/client/src/main/java/open/dolphin/client/Panel2.java

/**
 *
 * @author  Junzo SATO
 */
public class Panel2 extends JPanel implements Printable {
	
    private String patientName;

    private boolean printName;
    
    private int height;
    
    /** Creates a new instance of Panel2 */
    public Panel2() {
    }

しっかり読んでいるわけではないが、クライアントのエディタ画面を実装しているパネルはこの Panel2 のクラスが基本となっていたはずだ。

その他は以下のファイルに同氏の名前が残っていた。

SchemaHolder.java (client project)

public final class SchemaHolder extends AbstractComponentHolder implements ComponentHolder {
    
    private SchemaModel schema;
    
    //XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    // Junzo SATO
    // to restrict the size of the component,
    // setBounds and setSize are overridden.
    private final int fixedSize = 192;//160;/////////////////////////////////////////
    private final int fixedWidth = fixedSize;
    private final int fixedHeight = fixedSize;
    //XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    
    private boolean selected;
    
    private Position start;
    
    private Position end;
    
    private final KartePane kartePane;
    
    public SchemaHolder(KartePane kartePane, SchemaModel schema) {
        
        this.kartePane = kartePane;
        
        //XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        // Junzo SATO
        // for simplicity, the acpect ratio of the fixed rect is set to 1.
        this.setDoubleBuffered(false);
        this.setOpaque(true);
        this.setBackground(Color.white);
        //XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        this.schema = schema;
        //this.setImageIcon(schema.getIcon());
        setIcon(adjustImageSize(schema.getIcon(), new Dimension(fixedWidth, fixedHeight)));
        
    }

KarteViewer.java (client project)

// XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    // Junzo SATO
    public void printPanel2(final PageFormat format) {
        String name = getContext().getPatient().getFullName();
        boolean printName = true;
        if (pPane==null) {
            printName = printName && Project.getBoolean("plain.print.patinet.name");
        }
        panel2.printPanel(format, 1, false, name, getActualHeight()+60, printName);
    }

KarteEditor.java (client project)

   /**
     * Courtesy of Junzo SATO
     */
    private byte[] getJPEGByte(Image image) {

        byte[] ret = null;

        try {
            JPanel myPanel = getUI();
            Dimension d = new Dimension(image.getWidth(myPanel), image.getHeight(myPanel));
            BufferedImage bf = new BufferedImage(d.width, d.height, BufferedImage.TYPE_INT_RGB);
            Graphics g = bf.getGraphics();
            g.setColor(Color.white);
            g.drawImage(image, 0, 0, d.width, d.height, myPanel);

            ByteArrayOutputStream bo = new ByteArrayOutputStream();
            ImageIO.write(bf, "jpeg", bo);
            ret = bo.toByteArray();

        } catch (IOException e) {
            e.printStackTrace(System.err);
        }
        return ret;
    }

いずれも、クライアントのエディター上でカルテを表示・記載する際、かなり基本的となる部分で、特に Panel2.java では @author Junzo SATO と authoship を放棄していないことから、この方の著作権表記は retain していないとまずいと思われます。
そして、この時点での OpenDolphin の開発担当者は皆川和史ですから、彼らの理屈(ソースコード提供者は、すべてクレジットされなければいけないというような主張)からすれば、それを怠った皆川は GPL 違反をしていることになります。

なお、Juzo SATO 氏はこの資料から推測するに佐藤純三氏と思われます。


熊本大医療情報経営企画部→サイバーラボという経歴であることは分かりましたが、その後の足取りはネット上では掴めません。

funabashi 氏のコード

これは比較的最近(2022 春頃)になって見つかった。(猪股先生のツィート参照)

この方が提供したコードは探すとかなり大量に出てくるため、ここでは一例だけ挙げておきます。

IDocument2.java (server project)

// Module
ModuleModel soa = null;
ModuleModel p = null; // 20131206 add funabashi
if (model.getModules()!=null && model.getModules().size()>0) {

この箇所は OpenDolphin のデータ構造を決めているかなり基本的な部分です。

Junzo SATO 氏のコードにしても funabashi 氏のコードにしてもデータ構造のかなり基本的な部分に関与する部分で、基本設計のかなりの部分がこれまで公的には開発者としてアナウンスされていない人の手によるものであることが推測されます。

Kushiro 氏のコード

この方のコードもけっこうある。
一例を挙げておく。

DoseaseView.java (client project)

/**
 *
 * @author kushiro
 */
public class DiseaseView extends javax.swing.JPanel implements IDiseaseView {

    /** Creates new form Baka */
    public DiseaseView() {
        initComponents();
    }

miura 氏のコード

OpenDolphin はそれ自体では保険点数算定のロジックを持たないが、この部分を受け持つレセコンと連動させるためには、薬剤一つをとっても内部的にレセコンと共通の識別子(レセ電コードなど)を保持しておく必要がある。

薬剤処方のレセ電コードなどを処理している BundleMed というクラスがあるのだが、そこに miura 氏がソースコードを修正した箇所がある。

//miura^ test 院内と院外がまとまるのを防ぐ 211 and 212 のケース 2013/07/22
        if (!this.getClassCode().startsWith("21") || !other.getClassCode().startsWith("21") || !this.getClassCode().equals(other.getClassCode())) {
            return false;
        }
//miura$

機能的にはかなり細かい部分だが、保険点数の算定の仕組みとそれがプログラム的にどう処理されているかわかっていないと手を入れにくい箇所だ。

ORACLE のコード

これはわかりやすかった。
以下の open.dolphin.helper パッケージの SpringUtilities.java は、oracle が公開しているサンプルコード(https://docs.oracle.com/javase/tutorial/uiswing/examples/layout/SpringGridProject/src/layout/SpringUtilities.java)とファイル名も含めてまったく同一だったからだ。

/*
 * Copyright (c) 1995, 2008, Oracle and/or its affiliates. All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 *   - Redistributions of source code must retain the above copyright
 *     notice, this list of conditions and the following disclaimer.
 *
 *   - Redistributions in binary form must reproduce the above copyright
 *     notice, this list of conditions and the following disclaimer in the
 *     documentation and/or other materials provided with the distribution.
 *
 *   - Neither the name of Oracle or the names of its
 *     contributors may be used to endorse or promote products derived
 *     from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
 * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */ 

package open.dolphin.helper;

import javax.swing.*;
import javax.swing.SpringLayout;
import java.awt.*;

/**
 * A 1.4 file that provides utility methods for
 * creating form- or grid-style layouts with SpringLayout.
 * These utilities are used by several programs, such as
 * SpringBox and SpringCompactGrid.
 */
public class SpringUtilities {
    /**
     * A debugging utility that prints to stdout the component's
     * minimum, preferred, and maximum sizes.
     */
    public static void printSizes(Component c) {
        System.out.println("minimumSize = " + c.getMinimumSize());
        System.out.println("preferredSize = " + c.getPreferredSize());
        System.out.println("maximumSize = " + c.getMaximumSize());
    }

けっこうあるもんですね。

 

なぜソースコード管理が曖昧になってしまったのか

当然、この疑問は湧く。
これは、歴史的経緯を考えると分かりやすいかもしれない。
OpenDolphin には、地域医療ネットワークのクライアントとして使われていた時期とそこから一種のコンバートをして開業医さん向けのローカルなシステムとして使われていた時期がある(その後、クラウド化されるが、データベースをクラウドに上げただけで構成の本質は大きく変わっていない)。
このとき、永続化システムの切り替えは必須になってくるが、その移行方法に技術的に若干無理があったのかもしれない。
現在のコード上からも確認できるが、ローカル版(オンプレミス版)ではカルテ記載内容をかなり強引にバイナリ化して、データベースに格納している。
ソースコードにあたればわかると思うが、ここらへんのコードは極めて見通しが悪く可読性も低い。
また(これは個人的な推測になるが)この移行で担当者間で技術的な意図がうまく伝わってなかったのではないかと思われる。

ここは技術的な話になるので読み飛ばしてもらって結構だが、バイナリ化した理由は、初期設計の段階では PostgreSQL などで CLOB が上手く扱えなかったからだと思われる。

現状と今後の課題

まず、これまでの「本家」を引き継いだメドレーだが、今後、開発・販売を再開する予定はないとしている。
→結局、「運営などの権利はもつが積極的には普及させない」ということになったようですね。
実際、稼働クライアントマシンの OS アップデート(Mac であれば Monterey, Win であれば Win11)は非推奨であることが公式にアナウンスされている。
apple の BigSur サポート・マイクロソフトの Win10 のサポートが終了すれば、メドレーのサポートも実質的に終了することになるでしょう。

一方、商用利用している他の組織は、「新機能を盛り込みながら、開発・サービスの提供を継続していく」とアナウンスはしていたが、実際には目立った機能の追加はなされていない。(そもそも GlassDolphin クライアントは MacOS では動作保証外)

これは、従来のソースコードを Java17 でビルドするとそのままでは動かない(Java17 問題)といった基本的な文法上の古さに加え、従来の OpenDolphin のアーキテクチャの基本的な欠点・設計上の脆弱性が広く認知されてきたことに由来すると思われる。

上で「サーバー-クライアント間の通信は API を介して行われている」と書いたが、オープンソースである以上、通信を行う際の URI は特定されており、この点がサイバー攻撃の格好の対象になってしまう。
ローカルで使っている分にはこれは致命的な欠点にはならないが、商用利用されているクラウド型ではサーバの位置(URL)が特定されてしまうと、不特定多数からの攻撃をピンポイントで受けるリスクが生じる。
(商用利用のサーバの URL が公開されていないのはおそらくこれが理由)

また、ログイン認証の仕組み・データ構造も明らかにされているため、このロジックの透明性を逆手にとってシステムに検知されずにデータの改竄を行う余地があることが示されている。(『OpenDolphin は「真正性」すら満たしていないかもしれない』参照)

しかし、問題点が特定されているということは、解決策も講じやすいということでもある。

実際、

・ログイン認証などはソースコードをクローズドにしたウェブレイヤーに任せてしまい、本来のドルフィンサーバを外部から遮蔽して安全性を担保する(3層クライアントサーバーアーキテクチャの採用)

といった改善策が提案されている。(図は『WebDolphORCA』より)

また、この方法論はデスクトップアプリの画像の取り扱いに起因する Java17 問題の自然な解決になっている。

Java17 問題

公開されている OpenDolphin では、古い GUI ライブラリの一部が使われている。Java17 より前の Java では特に問題なくビルド・デプロイできたが、Java17 になって、デプロイ時にかなり致命的なエラーを出すようになった。
しかし、バックエンドのソースコードに手を入れることで基本的にはこの問題は解決した。

JakartaEE 環境への移行

Java のエンタープライズ環境は、JavaEE から JakartaEE へと変化した。
現在(2022)は、この移行の過渡期と考えられており、実際、ウェブアプリをデプロイするアプリケーションサーバは、JavaEE・JakartaEE 両対応になっているものが多い。

OpenDolphin では、2.7m 系列がいち早く JakartaEE への移行を果たした。Java17・JakartaEE 9.1 に対応したバージョンが『OpenDolphin Ver6』で案内されている。

バイナリ記録の問題

OpenDolphin はカルテエディター上の文字・画像などを最終的には Blob として記録している。

この保存形式のせいで

・データベース(DB)からカルテ情報を直接復号するのが難しくなっている

・システム稼働中であってもDB上の文字情報を再利用するのに手間がかかる

という問題が生じている。

OpenDolphin インスパイア系プロジェクト

現在の観点から見ると基本設計的には古くなった感のある OpenDolphin であるが、GUI リッチなエディタ・REST API の採用・ORM を利用した本格的な永続化システムなど当時としては最新の技術が採用され、現在でも通用する部分も多い。

そのため、これにインスパイアされたプロジェクトが存在する。

omcake

古林敬一先生が cakePHP で作成した「電子カルテもどき」(古林先生談)。
機能面での実装はまだ不十分であるが、カルテ記載内容の永続化方法は OpenDolphin の影響を受けている。

(参考)
古林先生のリポジトリ: https://github.com/keiichif/omcake

air-h-128k-il 氏のリポジトリ: https://github.com/air-h-128k-il/omcake 

WebDolphORCA

それまでしばしば問題とされてきた OpenDolphin のデータ抽出機能・閲覧機能を解決するため、猪股弘明氏を中心として OpenDolphin HTML/PDF Viewer プロジェクトが発足された。
このプロジェクトの目標はほぼ実現されたため、これをベースにして3層クラサバアーキテクチャの採用・ウェブ化・独自の WYSIWYG エディタの実装などがなされた電子カルテのプロトタイプが試験的に作成された。
まだ、完成はされていないが、プロトタイプの公開・進捗状況などは YouTube などで適宜アナウンスされている。

(適宜更新予定)

 

ANN2b

協力:猪股弘明

OpenDolphin -増田ファクト難民-

この頃、諸々あって OpenDolphin(オープンドルフィン) 関係を調べている。
→結局、『OpenDolphin -wikipedia 風解説-』にまとめました。

そこでいう OpenDolphin は OpenDolphin-2.7(m) 系列のことを指している。
というのは、現在(2020年年末)においてソースコードが公開されている最後のバージョンがそれだから。
ま、他にも理由はあったりするのだが、それは割愛。

それ以前は 2.3 系列や 2.5 系列がそれなりに普及していたようだ。

で、調べていたとき、「増田ファクト難民」という言葉を何回か耳にした。

「増田ファクト」というのは、和歌山の内科開業医(現在は閉院しているようですが)、増田茂 氏がフォーク(Fork ) したバージョンで、確かに以前はそれなりに普及していたようだ。

なのだが、私が調べた範囲では、使っている医師はまったくいなかった。
まあ、私の知り合いなんぞ東日本中心にかなり限られているけど。
(ちなみに、ほとんどは OpenDolphin-2.7 系列の自力運用。まあ、院内SE抱えていれば、運用はさほど難しくないでしょう。当然)

OpenDolphin-2.7m猪股先生も一時期は使っていたということで、それなりの質を維持していたんだと思う。
実際、猪股先生も

おそらくこういった「導入は増田ファクトで(当時としては、確かによくできた導入環境でした。ただし、導入手順書にしてももっぱら windows 前提で、Mac OSX へのインストールなどはまったく触れられていませんでした)。ある程度、様子がわかってきたら、さらにカスタマイズ。その後は、独自路線を突き進むなり本家に戻るなりして開発を継続」といったパターンは多かったと思います。

と『OpenDolphin について』の中で述べている。

 

で、「増田ファクト難民」ですよ。

なんでも、増田氏、ユーザーさんが何か気に入らないことをするとバッサリとアプリ(OpenDolphin-2.3m というらしい)の提供をやめていたとか。
また、電子カルテの乗り換え時に「増田ファクト」から他電子カルテに乗り換えるとき、データ移行の手段をまったく提供していなかったという(もちろん今はどうかは知らない)。

そういった「電子カルテはあれど、データが取り出せない」見捨てられたユーザーのことを隠語的に「増田ファクト難民」と言っていたらしい。

元商用開発元の方も「増田さんのバージョンからの乗り換え(データ移行)は何回か手伝ったことがある」と明言していたので、たぶん、そういった事情は本当にあったんだと思う。

もちろん増田さん自体はソフトを無償で提供していたので、このこと自体は咎められないと思うのだが(基本的には何か問題がおこったとしてもユーザーの自己責任)、問題はそのような運営状態にあるソフトを「電子カルテ」と呼んでいいのかってことなんだな。
ここらへんはややこしい問題も含んでいるので猪股先生が書いた『OpenDolphin と電子カルテの3要件とメドレー』を読んでみてください。ネット上ではかなり参照されている記事です。

 

そして、(これ書いていいか相当迷ったのだが)思い切って書いちゃうと、その後の増田さんの言動が周囲の評価を下げたと思う。

まず、猪股先生の OpenDolphin-2.7m がご自身の 2.3m のフォークだと主張した点。
これは完全に誤り。
OpenDolphin は、バージョンが上がるにつれテーブル数が増えていっている。
2.3 ベースのものと 2.7 ベースのものでは、そもそもテーブル数が違っている。
データベースを精査すればわかるが、OpenDolphin-2.7m は LSC 版 OpenDolphin-2.7 の直接フォークで、データベースの構造も 2.7 と何一つ変わっていない。
2.3 ベースの 2.3m からわざわざテーブルを増やして、2.7m に進化させるという手間のかかるアプローチを取る必然性はまったくないし、一般公開が中止された 2.3m をベースに 2.7 系に修正をはかるというのは不可能に近い。

次に、猪股先生版 OpenDolphinOpenDolphin-2.7m)のいわゆるファイルバックアップシステムを「役立たず」のように悪様に評価したこと。
どのような評価をしようが自由ではあるのだが、世間的に評価されているのはむしろこの機能だろう。
実際、ここまでデータ構造に関して理解している人はいないということで後期 LSC やメドレーからメンテナの打診があったのはよく知られた話だ。

開発者の猪股(弘明)先生が明らかにしているようにこの機能は元々はデータ抽出ツールが元になっている(参照:『ORCA, OpenDolphin, OsiriX は未だに話題になりますね』の「OpenDolphin カスタマイズの実際」の項)。
近年は、行政から電子カルテの修正履歴の開示まで求められるようになり、この手の機能はもはや必須といっていい。
一時的に普及した増田ファクトだが、次第に開業医からかえりみられなくなったのは、「クライアントに搭載されている(最終確定版の)PDF 印刷機能だけで十分。ファイルバックアップ機能は不要」といった開発ポリシーも一因にあげられるだろう。
現代では、データ操作機能が貧弱な増田ファクトでは電子カルテとしての実運用は難しいのだ。
これも私の個人的意見というより厚労省のガイドライン的な要請です。
このガイドラインでは

1.バックアップサーバ
システムが停止した場合でも、バックアップサーバと汎用的なブラウザ等を用いて、日常診療に必要な最低限の診療録等を見読できるようにすること。
2.見読性確保のための外部出力
システムが停止した場合でも、見読目的に該当する患者の一連の診療録等を汎用のブラウザ等で見読ができるように、見読性を確保した形式で外部ファイルへ出力できるようにすること。

電子カルテ本体とは別系統でバックアップシステムを備えておくことが推奨されています。
増田ファクトはクライアント経由でしかカルテデータを抽出できませんから、この基準を全く満たしていません。
一方、猪股版 OpenDolphin は、HTML/PDF Viewer と組み合わせて使うことで、この基準を完全にクリアしています。
仮に増田ファクトが電子カルテだとしても、ガイドラインの基準を満たしてないソフトの担当者(増田茂)が、基準を満たしているソフトを何の根拠も示さずに「そうではない」と否定しているようなものです。だから、周囲はその主張を受け入れることはできません。というより、そのような無茶な主張をしている人の評価を下げることはあっても、上げることはないでしょう。

さらにダメを押したのが増田茂が「OpenOcean は著作権違反行為だ」と誹謗中傷をしたことだろう。
その論理で言うなら 2.3m には dcm4che のコードがそのままの形で含まれていたのだから、増田ファクトの方が GPL 違反をしていたことになる(そしてそのことを増田茂は、一言も言及していない)。

また、ここから疑惑が生まれたように思う。
本当に自分でコーディングしているなら、こういった間違いはまずしないからだ。
もちろん昔書いたコードなどそのロジックを忘れることはけっこうあるのだが(バグの温床になります、はいw)、新規に追加した機能などはソースコードを何遍か見直せばほぼほぼその意図は思い出す。
猪股先生自身が「勘違いされてるんじゃないですか?」と指摘しても自分の主張を引っ込めなかったし、当時の商用開発元(私は後期 LSC とか呼んでますが)「増田ファクトと商用版とのデータ互換性はない」と明言しているにもかかわらずそのことを認めなかった。まあ、後者は「互換性」の定義にもよるのだけど。

実際、開発元が、後期 LSC 〜メドレーあたりになってから、増田さんは「開発者」としてはみなされていないそうです。
これもかなりおかしな話なんですよね。
過去のことであってもソースコードを提供したなら、contributor としての立場は変わらないはずなんですが、実務上はそういう取り扱いになってないようです。
経営陣が変わった途端、その立場を失うってのは商用ソフトならともかく(あ、商用ソフトでも本当はまずいかw)オープンソースの世界ではありえないはずなんですが。
GitHub でソースコードのやり取りしていれば、変に疑われることもなかったと思うんですが、その痕跡はまったくと言っていいほど残ってないし。
やっておけばよかったと思うんですけどね。

最後に付け加えると、メドレー的には「増田ファクトは危険」という認識らしいです。
OpenDolphin という名称は、特許庁による判断が下されてから、原則、他の団体が使っても問題なくなったんですが(air-h-128k-il 氏の『OpenDolphin と知財権に関するちょっと小難しい話』にかなり詳しい解説があります)、それはあくまで本家版との相違点が明示されている場合のみです。
「データ互換性がないのにあたかも互換性があるように広報するのは、容認し難い」そうです。
あ、これメドレーの言い分ですよ。
私じゃなくて(これ言っておかないと変に恨まれたりするんで)。
MIA も SOSO も猪股先生も、後期LSCとメドレーから許可取ってるんで、そうすればいいだけの話だと思うんですけどね。

(追記)長々と書いてましたが・・・

メドレーに開発元が移って状況はさらに変わりました。
メドレー自体が「OpenDolphin は GPL に従う必要はない」とかなりはっきり言うようになった。
増田さんの取り扱いに至っては(はっきりと言ったわけではないですが)「契約上、著作権者として取り扱っていただけ」のようです。
OpenDolphin について』より

あらら。
不自然なことは山ほどあったが、結局、そういうことだったわけですか。

(追記2)私なんぞドルフィンに手を出してからそんなに日が経ってないので遠慮してましたが、さすがにこれはダメでしょう。

現在(というか 2020 以来)、OpenDolphin という商標はメドレーが保持しているわけですから、配布などの際にはメドレーの名前をクレジットしないと(厳密には)商標権侵害にあたります。

(追記3)ところで、猪股先生を中心とする OpenDolphin-2.7m 開発コミュニティ、これまでもにも「設計が古い」と言われてきた OpenDolphin のアーキテクチャを大幅見直し。
諸々の理由で3層クライアントサーバ構成を採用。

フロントエンドサーバーをウェブサーバーにした関係上、クライアントはブラウザになっている。

プロトタイプを YouTube で公開している。

ところで、ここまでくると増田茂の主張がほとんど見当外れもいいところなのは明らかではないでしょうか。

デスクトップアプリをどんなにこねくり回してもクライアントがブラウザになることはありません

このウェブレイヤー(dolphorca と呼んでいる)は、

OpenDolphin-2.7m → OpenDolphin HTML/PDF Viewerdolphorca

の順に発展してきています。
増田ファクトのクライアント(私が聞いた話では windows でしか動かないみたいなんですが???)が入り込む余地はありません。

 

ANN2b

 

Laravel 〜PHP のモダンなフレームワーク〜 と世界最速 C++ drogon

Laravel

Laravel というのは、PHP で書かれたウェブフレームワーク。web アプリを構築するときによく用いられる。

Mac にインストール

そのインストール方法は検索すればよく出てくる。こことか。
ただ、 Mac にインストールする場合、『Mac Laravelの環境構築時にエラーが出た話』にもあるようにデフォだとインストール時にエラーが出る。
PHP を 7.4 にすると解決するようだ。

適当なサンプルを走らせる。

が出ればとりあえず環境は構築されている。

 

他のフレームワークとの比較

なお、Laravel は他言語で書かれたウェブ系フレームワークとの比較で言えば、いくら PHP を 7 系にしてもそれほど(レスポンスという意味では)パフォーマンスは良いものではないので、使い所に注意は必要だ。

上図は1位のフレームワークを 100 %としたとき、そのフレームワークの総合的な成績を数値化したもの。
誤解をおそれずに言えば、上位のフレームワークが 100 処理できるところを 3.6 くらいしか処理できないということを意味してます。
出典はここ

wordpress あたりに誰もそこまで速度を求めてはいないのと同様、高速レスポンスが必要なサイトには向かないかな。(それでもかつてのライバル CakePHP には勝っている)

Laravel は Ruby の Ruby on Rails 、Python の Django と合わせて3大フレームワークと呼ばれているらしいのだが、いずれにしても処理速度という点ではパフォーマンスはそれほど良くないことがわかる。

 

電子カルテで Laravel

無料で有名だったきりんの「カルテ zero 」は一部に Laravel を使用しているんじゃないかな。なんとなく、勘だけど。

 

drogon

では、世界最速のフレームワークは何かというと C++ で書かれた dorogon というものだ。

ところでその GitHub ページに行ったら、こんなものが・・・。

@Hiroaki-Inomata ってどこかで聞いたことのあるお名前(笑)。

確認したら、やはり猪股(弘明)先生でした、精神科の方の。

なんでも「ORCA のモディファイorz 関連で使った。けっこう使いやすかったし、開発者連中と気が合いそうだったので寄付した」とのことでした。

いやあ、立派、立派。

 

ANN2b