OpenDolphin Ver 7 インストール手順およびカルテデータの２次利用について等
OpenDolphin が Ver 7 になったため、以前の記事を Jakarta EE 10 環境向けに改変中です。
現在（2022）では、電子カルテ単体をインストールしただけでは、実臨床に供用するにはかなり無理があるため、データ移行ツールや HTML/PDF Viewer などの案内やセキュリティに関する事柄も厚めの記載にしました。
特にシステム停止時の見読性確保のためのバックアップツールは、ガイドラインでも推奨事項として明記されるようになったため、OpenDolphin とは独立して用意しておく必要があります。
また、従来（2.7 以前）の OpenDolphin 及び派生プロダクツは少々手直した程度では Java17 でビルドすると動きません。回避策として、クライアントをデスクトップアプリではなくブラウザにする構成が将来的には有力な選択肢ではないかと考えています。
この方針で dolphorca プロジェクトをスタートさせています。
ただし、従来のデスクトップアプリを延命する方法もありますので、これが唯一の解決策だということはないです。念の為。（→ Java17 問題として項目追加しました）
サンプルの徳川さんをインスペクタに表示させてみるとこんな感じ。
こうなれば成功。
＜方法＞
やり方は、基本的には以前の記事と一緒です。
スースコードを github リポジトリから取得してください。
なお、「 ソースコードを git で取ってくる」といった場合、コマンドラインから
git clone https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m.gitgit clone git@github.com:Hiroaki-Inomata/OpenDolphin-2.7m.gitなどとするのが普通です。
（ git のホスティングサイトは GitHub だけではありません。私たちは GitLab にもリポジトリを持っています。その場合はもちろん
git clone https://gitlab.com/Hiroaki-Inomata/OpenDolphin-2-7mになります）
git コマンドが入ってなければ、github リポジトリの該当ページの
「Download ZIP」をクリック、ダウンロード後、解凍して使っても問題ないです。
まず、Maven, Postgres などの環境を整える。
Maven や Postgres といってもピンとこない方は、
【微改訂】OpenOcean/OpenDolphin をカスタマイズするために知っておいた方が良いこと
をご参照のほどを。
アプリケーションサーバは WildFly 27.0.0.Final (WF27)にしてみました。
（なお、windows11 環境では WildFly26 と JDK17 の相性自体が悪そうです）WF27 をNetBeans から起動するとなかなか終了してくれなかったりするので、war ファイルをテストする時はその都度 Chrome ブラウザで 127.0.0.0:9990 にアクセスして管理画面からデプロイ。
WF27 への jdbc ドライバの登録は、
(WF27へのパス)\bin\jboss-cli.shでシェルスクリプトファイルをコマンドプロンプトから起動した後、
connect
module add --name=org.postgresql --resources=(パス)\postgresql-(バージョン).jar --dependencies=javax.api,jakarta.transaction.api
/subsystem=datasources/jdbc-driver=postgresql:add(driver-name="postgresql",driver-module-name="org.postgresql",driver-class-name="org.postgresql.Driver")というように打ち込みます。
connect
module add --name=org.postgresql --resources=/tmp/postgresql-42.7.2.jar --dependencies=javax.api,jakarta.transaction.api
/subsystem=datasources/jdbc-driver=postgresql:add(driver-name="postgresql",driver-module-name="org.postgresql",driver-class-name="org.postgresql.Driver")なお、Ubuntu や MacOS では、パーミッションの関係上、上のように /tmp においておくのが個人的には好み。
JakartaEE になって、名前空間が javax → jakarta になったため、以前の登録方法と微妙に違っています。
以下のように success が返って来れば OK です。
データソースの登録は、 standalone-full.xml を直接編集した方が楽でしょう。
（他にも WildFly の管理画面から登録する方法もあります）
– standalone-full.xml の編集 –
そういうわけで、データソースの登録。私はこんな感じで設定。
<subsystem xmlns="urn:jboss:domain:datasources:4.0">
<datasources>
<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
<driver>h2</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<datasource jta="true" jndi-name="java:jboss/datasources/PostgresDS" pool-name="PostgresDS" enabled="true">
<connection-url>jdbc:postgresql://localhost:5432/dolphin</connection-url>
<driver>postgresql</driver>
<security>
<user-name>dolphin</user-name>
<password>XXXXXXXX</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
<driver name="postgresql" module="org.postgresql"/>
</drivers>
</datasources>
</subsystem>user-name や password はデータベース作成時のもので。
続いて、ロガーの登録。
<subsystem xmlns="urn:jboss:domain:logging:3.0">
<console-handler name="CONSOLE">
<level name="INFO"/>
<formatter>
<named-formatter name="COLOR-PATTERN"/>
</formatter>
</console-handler>
<periodic-rotating-file-handler name="FILE" autoflush="true">
<formatter>
<named-formatter name="PATTERN"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="server.log"/>
<suffix value=".yyyy-MM-dd"/>
<append value="true"/>
</periodic-rotating-file-handler>
<logger category="open.dolphin">
<level name="INFO"/>
</logger>
<logger category="dolphin.claim">
<level name="INFO"/>
</logger>level は、WARN でも問題ないはずですが、反応が薄く（笑）なりますので INFO にしてみました。
最後に、IPアドレスの設定。
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:192.168.XXX.XXX}"/>
</interface>
<interface name="unsecure">
<inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
</interface>
</interfaces>ここは問題ないでしょう。
要するにサーバーが設置されたマシンがネットワーク内のクライアントなどから参照できるようにマシンに割り振られたIPアドレス（上の場合は 192.168.xxx.xxx ）をここで WF 自身に教えておくわけです。
管理画面にアクセスする場合は、安全のためにサーバマシン以外からアクセスできないように（そのマシンの自体のIPアドレスを意味する） 127.0.0.1 を設定しておきます。
– ソースの改変 –
ここらへんで、一回、
standalone.bat -server-config=standalone-full.xmlとしてWF10を起動してみるとよいでしょう。問題なければ、管理画面から war ファイルをデプロイしてみましょう。
なお、Linux(Ubuntuなど)では
standalone.sh -c standalone-full.xmlというコマンドになります。
ソースそのままだと、Clob がどうしたこうしたで class がロードできないというようなエラーが出るはずです。どうやら、ソースが WF10 に対応していないようです。
なので、ソースに若干の修正。
調べると、common プロジェクトのエンティティで clob を使っているのは、
LetterText.java, NurseProgressCourse.java, PatientFreeDocumentModel.java, PatientMemoModel.java
の 4 ファイルなので、各ファイルの StringClobType という（現在では）推奨されていない表記を StringType に変更。例えば、LetterText.java であれば
@Entity
@Table(name = "d_letter_text")
public class LetterText extends InfoModel implements Serializable {
private static final long serialVersionUID = 1L;
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@Column(nullable=false)
private String name;
@Lob
@Type(type="org.hibernate.type.StringClobType")
private String textValue;を
@Entity
@Table(name = "d_letter_text")
public class LetterText extends InfoModel implements Serializable {
private static final long serialVersionUID = 1L;
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@Column(nullable=false)
private String name;
@Lob
@Type(type="org.hibernate.type.StringType")
private String textValue;に変更。
これで再度コンパイル、デプロイすると今度はうまくいくはずです。
クライアントは（一部不具合を除いて）特に大きな修正の必要はなかったかと思います。template や custome.properties などを準備しましょう。ついに、起動の瞬間。
java -jar OpenDolphin.jar dolphinでログイン画面が立ち上がり、ドルフィン君がお出迎えしてくれると思います。
（まあ、アイコンダブルクリックでも立ち上がるんですが→ Ver6.3 系列はダブルクリックで立ち上がるのですが、不具合がでます。コマンドラインから立ちあげげてください）
お疲れ様でした。動画は、Mac （M1, BigSur）の場合ですが。
‥‥‥なのですが、細かい話をするとスタンプメーカーを起動した場合、診療行為とコメント系の組み合わせの取捨選択で一部不具合かなと思われる個所があります。
正しくは
のように動作しないといけないはずです。
設計の詳細がわからないため、きれいな形で直せなかったのですが、力技でごまかして動かしました（試しに使ってみる分にはまるで問題ない箇所です）。→ github
ライセンス – GPL とか LGPL とか –
あと、この画像見てて思いましたが、スプラッシュ画面の著作権表示は、そのプロジェクトをマネジメントした組織名になってますね。慣例的にこのように表記するプロジェクトが多いかと思います。GPLv3 でも初めてオープンソース化されたソフトやそこから派生した contributor version は著作権表記として “(C) Name of Author” を推奨しているように思えます。”Name of Authors” でも “Name of Contributors” でもありません。
OpenOcean のときに、著作権表記に関して GPL 違反だーとか批判した人がいるんですが（京大の小林慎治氏→問い合わせてみたところ、「京都大」の公式見解ではなく彼の個人的解釈とのことでした。Fork 順も完全に間違って理解してますね）、上記の理由でちょっと違うんではないかと思います（あと publish の解釈がまったく違いますね。ソースコード提供者がそれなりの人数であるためライセンスの観点から「一般」公開しておいた方がいいと考えています）。これで LSC さんからも了承もらってるし（当然、現在ではメドレーからも）、弁理士・弁護士さんからも問題なしと言われてます。というか LSC の言い分は「（リリース元がわかりにくくなるので）むしろ変えてください」でした。(なお、本家の更新がゆるやかになったあとでもアクティブに開発が続けられている GlassDolphin に至っては著作権表示すらされていません。Ver 3 あたりから、ソースコードの一般公開もしなくなったし、最近ではソースコードの開示もしていません。少なくとも商用開発元は、GPL を尊守するという意識は希薄になってきていると思います）
HorliX も同様に LGPL には違反していないと思います。
そもそも Fork 元の Horos 自体、過去に GPL → LGPL のライセンスの変更を行っています。これは、ライブラリがほぼすべて外部プロジェクトのもののであり、これらライブラリに関する部分はそれらのライセンスに従わなくてはいけないため、GPL ⇄ LGPL の変更をおこなっても実際的な取り扱い自体はほとんど変わらないからです。
なお、変更の理由は当時のユーザーさんから「プラグインのソースコードは公開したくないので、念の為、ライセンスを変更してくれないか」という要望がそこそこあったからです。プラグインが LGPL でいうところのライブラリに該当するかは微妙なところだと思いますが、臨床系の情報処理でアルゴリズムなどを伏せておきたいというのはもっともなことだと思い、そうしたまでです。おそらく Horos も同様の理由でライセンスを変更したと思います。
最近だと、東京都の新型コロナ（COVID-19）感染症対策サイトがオープンソースで公開され、これを元に各地域版が次々につくられリリースされました（ただし MIT ライセンスですが）。このときの各地域版の著作権表示は、
(C) Code For XX あるいは (C) XX市民有志
自治体公式ならば (C) XX prefecture
などでした。これを (C) Tokyo Metropolitan government としてしまうと、かえってユーザーに混乱を与えるだけだということは、直感的にもおわかりいただけるかと思います。
※・・ところで、小林慎治さんが所属している保健医療科学院というところから、「国家公務員法違反（守秘義務違反、信用失墜行為、政治的行為の制限違反）の疑いがあるので厳重注意した。不愉快な思いをさせてしまい、大変申し訳ありません」という主旨の謝罪のメールをいただきました。細かい経緯はよくわからないのですが、他のオープンソースのプロジェクトで行動規範を逸脱する言動があったようです。過去の SNS 上などでの表現にも不適切なものがあったということで、当方にもそれらの確認・照会がありました。明らかな事実誤認（上記の Fork 順や ライセンス変更に関するもの）などに関して軽く回答させていただきました。そういった経緯を所属機関の幹部が判断した上でのフィードバックのようでした。→経緯はこちらで。
＜謝辞＞
基本設計をされた方々、ならびに、オープンソースとして公開継続されているライフサイエンス コンピューティング株式会社様（LSC）に感謝いたします。
本家リポジトリの README などでは、特に強調はされてないのですが、Junzo SATO さん・funabashi さん・ oracle などが作成したコードが使われています（探せばもっと出てくるかもしれません→『OpenDolphin -wiki 風解説-』）。見方によっては OpenDolphin はこういった成果の集約とも言ってよく、やはり同様に感謝の念を捧げられないといけないでしょう。
（なお、有り難いことにLSC様からの訪問も受けました。この手の導入記事の公開・バイナリの配布などはまったく問題ないとのことでした。ファイルバックアップシステムやデータ移行ツールなども好意的に評価されました。「オープンソースだから、あれこれいう人は出てくるかもしれないが、あまり気にしないでください」という言葉もいただきました。重ね重ね感謝いたします）
また、現在の開発元（および商標権保有者）のメドレー様にも好意的に評価していただいているようです。ありがとうございます。
さらりと読んだだけですが、ソースにあたると「本当によくつくりこまれているな」という感想を持ちました。
また、ネット上で貴重な情報を提供している高東ソフトウェア様に深く感謝いたします。
猪股弘明（精神科医）
＜感想など＞
・評価するだけであれば、『無料電子カルテ OpenDolphinパーフェクトガイド』で紹介されている Docker 版を使用するのが便利でしょう。（→このレビューを見る限り、現在では若干調整が必要なようですね）
Docker版で実運用？ チャレンジャーですが頑張って欲しいものです
・標準的にはサーバは Ubuntu 上などで稼働させるべきなのでしょうが、操作性という点でみるとやはり win 機の方が楽ですね。
OpenDolphin と ORCA との接続・連携
ORCA Ver 5.0 とも接続させてみましたが問題なく通信できています（ORCA は VMWare というソフトを使って windows 上で Ubuntu仮想環境をつくって走らせています）。
なお、ORCA もオープンソースなので、少なくとも ORCA 自体はソースコードからコンパイル・インストールできます。
なお、この記事を書いた当時のオルカは、ローカルで動くいわゆる「オンプレミス版」で、かなり安定した動作をしていました。が、その後、オルカ自体のクラウド化・度重なる保険請求のフォーマット変更への対応のため、改修を余儀なくされ、最近ではデータベースレベルでのスキーマの不整合、動作不具合などの問題が出てきているようです。
上記の件に関しては、公式ML（特にここやここ）や『レセコンソフト ORCA を巡るあれこれ』、『ORCA Plus というレセコンユーティリティソフトを使っていて気がついたんだが』、『ORCA の日計表と関連テーブル・内部会計フローなどについて』などをご参照ください。
なお、現在（2022/4）、上記の問題を改善するためか WebORCA というサービスがリリースされました。
公式サイトの説明だけだとわかりにくいですが、MLの方で上野さんがユーザーからの疑問に応える形でかなり明確に開発方針を明らかにしています。
ORCA管理機構の上野です
> webORCAと言う名前を見ました
> 日レセクラウド版ともちがうのでしょうWebORCAは、私どもで次世代のORCAと位置づけており、
従来のクラウド版（ginbee）を
独自に開発した、Webアプリのフレームワークに移植したものです。
画面は同じまま、安定性や動作速度で大幅に優れています。> オンブレミスは廃止の方向ですか？
ginbee についてはWebORCAへの移行を進めておりますが
オンプレミス版は継続の方向です。
ただし、現状のオンプレミス版は、
近い将来、WebORCAのオンプレミス版（ブラウザで利用できる
ORCAのWebサーバ）としてリリースしたいと考えています。オンプレとクラウドのWebORCAスキームへの統一には、
メンテナンスコストを削減するという点以外に、
大規模な災害や障害に強いハイブリッドな環境を提供するという
目標があります。
ウェブフレームワークの採用は私（猪股）も提案していましたが、とうとう本格採用となったようです。
将来的には医療情報の類はクラウドに上げて一元管理・ビッグデータとしての活用を図る・・云々
みたいな話は、まあそうだろうなとは思うのですが、このとき医療機関側が欲しい情報を取ってこれる環境になっていないとデメリットの方が大きく、実際には誰も参加しないだろうなと思います。
（法的にも医療情報の管理責任は、現状だと医療機関側です。業者ではありません）
欲しい情報を効率よく取ってこれるかどうかは、データ構造の整合性に大きく依存するのではないでしょうか。
これを実現する割と有効な選択肢は現在だといわゆるウェブフレームワークの採用かなと思ったわけです。
ただし、YouTube の紹介動画を見る限りでは、ブラウザの画面が固定レイアウトのようで、一般的なウェブフレームワークとはまた違ったもののようです。
せっかくなので iPad につないでみた
せっかくなので SuperEHRTouch というアプリを iPad にインストール、上記のサーバにつないでみましょう。（なお、アプリは 2022 以降、公開停止になっていて使えません。現在、WebDolphORCA というドルフィンのウェブ化を目指したプロジェクトが進行中で、過去カルテの閲覧のみならば、既に実現しています。ブラウザで見れるものを、わざわざ、アプリで見る必要性はほとんどないでしょう）
一応、接続はできましたが、スタンプツリーが読み込めなかったり、アプリが落ちたりとかなり不安定でした。それでもアプリは直観的で操作性にすぐれ閲覧用としてみても十分なクオリティではないでしょうか。 それにしても徳川さん栄養状態悪化の一途。
さらにクライアントから処方せんを打ち出してみた
訪問診療・往診などでは、訪問先で処方せんを発行できた方が便利なので、できないか検討。メニューアイテムとして復活させるのが簡単なんでしょうが、リフレクションが性に合わないのと処理の流れを追いたいという気持ちがあって 、今回は client プロジェクトの適当な位置から open.dolphin.hiro パッケージの PrescriptionMaker を直接呼び出すことにしてみました。 すると通常版にはないダイアログが出現。
出力先のディレクトリを調べると….
できてましたね、処方せんが。 ソースを読むとこのフォーマットを作った苦労のあとが窺いしれます。
新宿ヒロクリニックの担当者の方、ありがとう。
その後、ヒロクリニックさんは OpenDolphin の使用をやめてしまったようです。訪問診療ではやはり（機能の充実した）ブラウザ型の方が便利でしょうか。
なんちゃってクラウド化・多施設化
クラウドブームなので OpenDolphin でもできないか検討。
デフォルトの 1.3.6.1.4.1.9414.70.1 のドルフィンクリニック（管理者 admin）の他に
追加で 1.3.6.1.4.1.9414.10.1 のイルカクリニックを登録（ついでに管理者 dolphin さんも登録しておく）。
（注）なお、適切にソースを改変すると医療機関 ID は 1.3.6.1.4.1.9414.* でなくてもかまいません。
クラウド上に設置したサーバに対して admin さんと dolphin さんが異なる場所から同時に接続を試みる。
するとサーバ側ではこんなログが取れる。
クライアントでもしっかりつながってました。
実運用では、セキュリティを高めるため VPN でつなぐなどやらなくてはいけないことはいろいろあるでしょうが、何もしなくてもクラウド化・多施設化ができるというのは便利ですね。
なお、現在は試験環境すら提供していません。さすがにクラウドマシンを常設するにはコストがかかるので（笑）。
ところで、クラウド上に飛ばしたカルテの各種データは、クラウドの管理者がどの程度把握できるのか？という疑問は当然出てくるかと思います。データ自体を暗号化しない限り、クラウド管理者からは「丸見え」、というのがその答えになります。クラウド上のデータの２次利用に関しては、ガイドラインに沿った制約があり、各クラウドサービス提供者によってもその取り扱いが異なってくると思われます。（Dolphin に限らず）クラウドを実利用される際には、一度、確認しておくことをおすすめします。
ファイルバックアップシステム・データ移行ツール・HTML/PDF Viewer
Dolphin は基本的に LAN 内で使うことを前提につくられているので、クラウド化でやったようにサーバとクライアントが同一 LAN 内にない場合、潜在的に通信障害のリスクが増します。
なので、OpenDolphin 2.7m ではクラアイントのホームフォルダに強制的にファイルバックアップを取ります。
例えば
のようなカルテを作成したとき、ユーザのホームディレクトリの OpenDolphin フォルダに BackUp フォルダとさらに 患者ID 子フォルダを作成し、その中に診察内容のテキスト文だけを記録した 作成時刻.txt というファイルをつくります。
上のカルテだと D_000001 フォルダ内に
とこんな感じのテキストファイル 2018-05-10-12-20.txt ができています。
カルテ記載内容を外部にプレーンテキストで書き出しているので、例えば以下のように grep コマンドなどと組み合わせて簡易な検索機能も実現できます。
他にも色々な用途に使えそうですが、ドルフィンから他電子カルテに乗り換える時などにも役に立つでしょう。あんまり考えたくはないですが、決して大手とはいえない開発元がプロジェクトを急遽中止することも考えられるわけです（→実際、2020 に開発元が変わりました。後述）。もしそうなっても慌てなくてすむようデータコンバートの手段は事前に準備しておくのがよいと思われます。
なお、この機能はソースコードにしてわずか 100 行程度の Java コードで実装しています。
ソースコードの働き自体は読めば何やっているかわかると思うのですが、どちらかといえば OpenDolphin のデータ構造の方が理解しにくいでしょうか。
一般的な文書処理系アプリのデータの永続化方法として重要な事項（とその限界）も含まれていると思うので、その辺を『OpenDolphin ソースコード解説』にまとめておきました。
・これだけだと、テキスト情報のみですが、より完全に（直貼りした画像やその位置まで）コンバートしたい場合は、次の記事をご参照ください。
このプログラムは、OpenDolphin や OpenOcean とは別の独立したソフトです。直接データベースを見にいって、一般的な形で（プレーンテキスト+画像、rtf 形式+画像、html など）電子カルテのデータを取り出します。
上でわざわざ「独立した」と断っているのは、まれに「OpenDolphin のデータは（dolphin の）サーバを経由しないと取り出せない」と誤解している人がいるからです。
インストールの手順からわかるように、OpenDolphin のサーバープログラムは WildFly と PostgreSQL に特別な制限を加えているわけではないので、データを格納しているデータベース（PostgreSQL）は、適切な手続きを踏めば（dolphin サーバや WildFly を経由せずとも）そのデータを吐き出してくれます。
こちらもぼちぼちとメンテ始めました。
『Save the DolphinS -OpenDolphin データ抽出ツール・プロジェクト-』
→ 出力形式には色々と迷ったのですが、閲覧の便を考えてテキスト情報と画像などの情報を同時に表示できる html と PDF にも対応させました。
何らかの事情で新しいシステムへのデータ移行を行わないとき（例えば、閉院する場合や移行期間を設定して新旧二つのシステムを併用する場合）つまり閲覧だけでいいというときには、視認性の面でこちらの方が便利でしょう。
こちらのソフトは『OpenDolphin HTML/PDF Viewer プロジェクト』で案内しています。
なお、データ抽出する際にはデータベースから抜いてくるのが本道だとは思いますが、ドルフィンの場合、（SSL 化してないと特に）通信まわりに隙があるため、これを利用してデータ抽出することも可能です。
・『2018 年末断捨離』という記事を見かけました。以前に配布していた OpenOcean クライアントを使ってデータ移行されたとか。苦労してますね。
クライアントホーム直下のバックアップフォルダかき集めてくれば、確かにできなくはないですが、この方法だと手間がかかります。
2010 年代前半くらいまでは、公立基幹病院のデータ移行などでも慣例的にこのレベルでも許されている節はあったのですが（ただし、電子カルテの３原則を厳密に尊守するなら「真正性」の点で引っかかります）、現在では（地域にもよるとは思いますが）行政の解釈的には原則 NG になっています。
つまり、「誰が記載したか」や「いつ内容が変更になったか」…etc、まで求められています。
これを実現するためには、上で紹介したプログラムを使うか、ファイルバックアップに関するコードをさらに修正するか（これはこれでロジック考える必要がありますが、それほど難しくはないでしょう）した方がいいと思います。
データ移行する際、カルテ記載確定版の PDF 文書を用いて・・・というのは避けた方がいいでしょう。
いわゆる e-文書法（電子文書法）と電子カルテの３要件を組み合わせて解釈すると、修正事項（とその履歴）などが表示・出力できないシステムは違法と考えられます。
自力でどうしてもできないという方は、コンタクトページよりご連絡ください。
（『OpenDolphin と電子カルテの３要件とメドレー』（HorliX とか OpenOcean とか）などもご参考に）
・クラウド型電子カルテを開発しているメドレーという会社がライフサイエンスコンピューター（LSC）から「電子カルテの資産及び顧客アカウントを譲り受ける」ことを公式に発表しました（2020/5/7）。OpenDolphin 自体の開発を継続していくのかどうかまでは不明ですが、気になるところです。
→開発継続とのことです。ただし、新規の販売は終了しており、開発が継続されるにしても既存ユーザーに対するメンテナンス程度と思われます。レセコン機能を受け持っていた ORCA も作り直すことが検討されていることから、データコンバートの準備はしておいた方がいいでしょう。（基本的には「新規の販売は終了しました」とのことです）
カルテデータの２次利用・AI 技術の適用
データベースから任意の情報をテキストで持ってこれるようになると、２次利用する際にも便利でしょう。
最近は日本語でも自然言語処理のノウハウが集積してきました。画像系に比べるとやや立ち遅れている感はありますが、AI （特に「機械学習」という手法）による自動診断などカルテデータの２次利用に関する研究は近年盛んになってきています。
簡単なプログラムを python で書いてみました。
これはあくまで試験的なプログラムですので、あまり診断精度はよくありません（出現する単語に反応している程度）。
ですが、こんな形で診断を支援するシステムが身近なものになってくると医療も変わっていくことでしょう。
（こういった方面にご興味のある方は『医療「AI」ソフト』・『OpenOcean』などもご参照ください）
FAQ
上のカルテデータ云々に関連してよく聞かれることなのですが、
Q1 カルテデータはデータベースのどこに記録されているのか？
というのがあります。一見、わかりにくいのですが
A1 blob 領域にバイナリで記録されています。
というのがその答えです。
データベース（PostgreSQL）からなら、
d_karte -> d_document -> d_module
の順に追っていくとよいでしょう。
さらに Java のソースコードを丹念に追っていけば類推つくかと思います。
『OpenDolphin 2.7 系列 FAQ 』
などを参考にしてください。
より体系的な解説は
『OpenDolphin コード解説 -FileBackUpSystem と電子カルテのデータ構造-』
を参照してください。
Q2 オープンソースソフトウェアはセキュリティ的にみて弱いのではないか？
A2 最近（2022）LockBit による半田病院へのランサムウェア攻撃が話題になり、その延長でこの質問を受けることがありました。
後述します。
OpenOcean
OpenDolphin 2.7m を継承したのが、（初代の）OpenOcean です。
インストール・デプロイ関係の記事は、
『OpenOcean/OpenDolphin をカスタマイズするために知っておいた方がよいこと』
『OpenOcean/OpenDolphin をカスタマイズするために知っておいた方がよいこと 2』
などをご参照ください。ソースを使って OpenOcean や OpenDolphin を自力でビルド・カスタマイズしたい人向けです。
手っ取り早く使いたい人は、ビルド済み OpenOcean クライアントを
で公開しているので（現在は配布停止中）、そちらをご利用ください。Docker 版の OpenDolphin サーバにもつながると思います。（OpenDolphinPro 版というのでしょうか商用版サーバとの接続は、試してないので不明です）
『OpenOcean クライアントと Docker 版 OpenDolphin サーバをつなげる』
完全にお約束はできませんが、OpenOcean は長期メンテを考えています・・・と以前は言っていましたが、諸々の事情で全面的に作り直すことを検討しています（ただし、グッズはこちらで健在）。
一部、UI らしきものを作成したところ、けっこう評判がよかったようなので、この路線（いわゆるブラウザ型ですね）でしばらくは、試作していこうかと思っています（『ORCA Plus から OpenOcean へ』など参照）。
いろいろ、ごちゃごちゃ書いてましたが、『WebDolphORCA』というプロジェクトに統合されそうです。
その他の応用
データ構造などがわかっているとデータベースレベルでの改変もできます。
最近（2022）、著者の一人（猪股）は聴診音関係の開発プロジェクトのクラウドファンディングのメンバーになり、ありがたいことにこのクラファンは目標の寄付額を達成しました。
計測した聴診音を電子カルテに保存しておくのも便利かなと思い、このコンセプトでデータベースを改変したバージョンを試作しました。
（『聴診音クラファンからの・・・OpenDolphin』参照）
臨床に供用する他にこういった（実験的な）プロトタイプとしての活用も有効な利用方法の一つでしょう。
今後の方向性など
メンテナンス不足で申し訳ないのですが、おかげさまで OpenDolphin-2.7m がネット上では支持されているようです。（たまにですが）開業医や開業準備中の医師の方からメールなどで連絡いただきます。
【参考】dolphin-md 『開業時のポイント 電子カルテ』
フォークした直後などは特にどこと協力するなどとは考えていなかったのですが、現在では商用版をリリースされている企業様などとも連絡は取っています。
今後の方針などは、関連企業様と相談しながら決めていきたいと思っております。
注意点
長々と説明してきましたが、上記の経緯で LSC 版 OpenDolphin-2.7.0b の改変を行ったものが OpenDolphin-2.7m です。GitHub などでも LSC 版の「bugfix + α」だと散々説明して誤解の余地はないはずなのですが、一部の人たちは間違って解釈しています。だから、いわゆる増田内科版（増田内科さんは一時的でしょうか？閉院しているようですが）とは直接の関係はありません。なお、増田内科版は本家 LSC 系列とはデータの互換性もないようです。「ないようです」というのは少々無責任な言い方かもしれませんが、少なくとも商用開発元はそのようにアナウンスしています。（『OpenDolphin について』などもご参考に）
Mac OSX へのインストール
前にもちらっと触れましたが、別サイトになりますが『OpenDolphin-2.7m を Mac OSX にインストールする』を参考にするとよいと思います。
M1(arm, apple silicon) Mac へのインストール
『OpenDolphin-2.7m を M1 Mac にインストールする』を参考にしてください。
インストール＆デプロイがうまく行けば↓のように起動できます。
一昔前、海外で Java の OpenDolphin と言ったら・・・
なお、一昔前に Java の世界で OpenDolphin と言ったら（特に海外）、
のロゴで有名な方の OpenDolphin だったと思います。もちろん、これは電子カルテの OpenDolphin とは無関係。
Java でクライアント・サーバシステムを組んだとき、その仲立ちをするライブラリだったようです。。
公式 リポジトリは 、
GitHub: https://github.com/canoo/open-dolphin
解説などは、ここやここにあります。
Java17 問題
Java 15 くらいまでなら、公開されているソースコードを少々手直しすれば（確か修正はクライアントのみでよかったと思います）、サーバー・クライアント共に上記の手順でビルド・デプロイは可能でした。
Java 17 になって、Java の古い GUI コンポーネントへのアクセスに制限が加わったため、この機能を呼び出している OpenDolphin は正常動作しません。
ただ、制限が加わったといっても一部ですので、その部分を適切に修正すれば、動きます。
バックエンドにも手を入れる必要があるため、若干、敷居が高くなるでしょうか？
でも、dolphin が画像をどう扱っているかわかっていれば、それほど難しくはないので、興味のある方はチャレンジされたらいいのではと思います。
医療向けオープンソースソフトウェアのセキュリティに関する問題点
一般的に言って弱いでしょう。
オープンソースソフトウェア（OSS）はその定義からいって、セキュリティ的に重要な
・データ構造
・ログイン認証の機構
などが第三者に解読されてしまいます。
この点に何の対策もしていないと、そこを突かれる可能性はあります。
OpenDolphin に関していうと、サーバーの出来が良すぎるが故に弱点になってしまっているところもあります。
例えば、通常にクライアントからアクセスする場合、ログインの試行回数は５回まででクライアントを一端終了するしかありませんが、クライアントを経由せずにサーバー本体にログインを試みる場合、この制約はありません。
そして登録しているユーザーのログインIDとパスワードが一人でも解明されてしまうと、これを使ってデータベースに記録されているほぼ全ての情報を引き出せてしまいます。
単純なクライアントサーバーシステムでは、サーバーの API などは基本的には外部に開放されていますから、この点に何の対策もしていないとセキュリティに関してはかなり脆弱と言えるでしょう。
具体例を一つあげておきます。
以下の偽？カルテは、サーバー経由でドルフィンのデータベースに入れ込んだ例です。
オープンソース版のドルフィンクライアントでは、文字の色は８色に制限されていますから、このカルテがクライアントで生成されたものではないことはわかるでしょう。
なお “LockBit” のフォントの大きさも正規版のそれと微妙に変えています。
気がついたでしょうか？
前にも書きましたが
・データ構造
・ログイン認証の機構
がわかっていると、データの引き出しはおろか偽造カルテの生成・登録までできてしまうわけです。
怖いですね。
もちろん、回避策もあります。
サーバーの API が外部開放されているから、この手の情報漏洩・破壊のリスクが増すわけですから、回避策として「外部開放をやめてしまう」という手があります。
例えばクライアント-サーバの間にもう一つサーバ（中間サーバ）を入れ、本来のサーバの API は新たに入れ込んだ中間サーバにのみ開放すれば、一般的に外部開放しておく必要はなくなるわけです。
このような構成は３層クライアントサーバシステムと言われ、最近見直されていいる設計のようです。
また、この設計を取ると本来のサーバのソースコードはオープンにしておいてもいいので、オープンソースソフトウェアとの相性もいいように思います。
どの程度までやるかは未定なのですが、３層クラサバによる再設計は WebDolphORCA の基本設計となっています。
その他
質問などお問い合わせはこちらからどうぞ。
フェイザー合同会社（PHAZOR, LLC）
『OpenDolphin wiki風解説』OpenDolphin で GitHub がどう使われてきたか参考になると思います。その他の項目も充実しており、現在、もっとも網羅的な解説記事でしょう。