関係者の怒り方が半端なかったため、やむなく投下。
まあ、ちゃんとソースコードにあたって検証していれば、間違えないところですからね。
にもかかわらず、あたかも自分がオープンソースの代表者のように振る舞うのはどうなんだろう？
オープンソースに関わられている方には一読をおすすめします。
オープンソースに関わられている方には一読をおすすめします
本日の外来は２人、粛々と診療。。
本日の外来は２人、粛々と診療。。
ということではなく、ORCA というレセコンから受付情報を取得、サーバプログラムで扱えるか試してみた。
第一、私は内科医でもなんでもないし、スマフォでカルテ入力する医者がいたら怖い。
最近のウェブ周りの技術の進歩は著しく、適当なライブラリを組み込むだけで、各種情報をスマフォらしく表示してくれる。
「スマフォらしく」とは書いたが、いったん組み込んでおくとタブレットでもPCでもその画面幅に応じて適宜デザインをよしなに調整してくれる。例えば、外来待受画面の「秋場 太郎」さん（もちろんテスト患者）をクリックするとカルテ記載画面に遷移するが、そのPC表示は以下のようになる。
メニューバーが変化しているのがわかるだろうか？
こういった細工がライブラリを組み込んでおくだけで実現できるので、とても便利だ。
実際、コーディングに要した時間は、２-３時間程度。
少々、脱線したが、こういった便利な道具があるおかげで、どちらかといえば、どういうデータ構造にしたらいいか？と考えを巡らせていた時間の方が遥かに長い。
今回は時間が取れたせいか、シンプルで使いやすい設計になったような気がする。
この手の設計で、おそらく、一番簡単なのは、国民一人一人に ID を振り。。。ということなんだろうが（将来的には国もそうしたいんだろうけど）、現状だとそれではやり過ぎなので、従来通りの施設 id とその施設が用いる患者 id の組み合わせでユニークな識別子とした。
具体的には、
施設 A( 施設id=10000) で 患者id=00001 に秋場さん
施設 B( 施設id=10001) で 患者id=00001 に秋場さん
がいた場合、このままだと患者id だけでは両者を識別できないので、通常、複合キーという手法を使う。
施設 A の方の秋場さんを表現するのに 10000:00001 という表記を採用すると、これは 10001:00001 と区別できるのでユニークな識別子となるわけです。
この複合 ID から、再度、元の二つの id を取り出したければ、
String[] cid = ID.split(":");//ID: 複合 ID
String facilityid = cid[0];// 施設id
String patientid = cid[1];// 患者id
などとするわけです（上は Java で書いた場合）。ちなみに OpenDolphin もこの方式を採用してました。
レセコンが単施設にしか対応していなくても、電カルの方で多施設対応にできているのは、こういう小ワザを使っているからです。
でも、将来的にはどうなるんでしょうね？
興味深いところです。
猪股弘明
精神科医
OpenDolphin-2.7m 開発者
DolphORCA Ver1.3
SOA 領域は前回で目処がついた感があるので、お次は P 領域。
SOA 領域には、理屈の上で情報量に上限はないが、これは CLOB を使うことで解決できる。
カルテの P 欄の面倒くさいところは、項目（処方とか検査とか）の数が理屈の上で上限がないこと。
まあ、１回の外来で手技を２０も３０もやる先生はいないと思うが、ここを数量限定にしてしまうとなんか負けた感じがするので、意地でもそうはしなかった。
結局、カルテのドキュメントに相当するクラスの中に P の項目に相当するクラスを複数埋め込める設計にした。
DB から情報の取得→シリアライズ→画面への表示
あたりはできている。
あとは
・デシリアライズ
（逆順ができないと編集した P の情報を DB に記録できない）
・レセコンとの連動
あたりが課題。
連動させるレセコンですぐに思い浮かぶのは ORCA だが、ORCA 限定にはしたくないなあ。
ところで、私事ですが、変な感じで擦り寄ってきた胡散臭い感じのビジネスパーソンの方々はバッサリ切りました。
「先生、あとどれくらいかかるんですか？」とか聞くのは反則だと思う。
こんなの義務でもないし、とりわけそういった人々のためにやっているのでもなんでもない。
進行管理したければ、自分で調べればいいだけの話。
進行状況などオープンにしているし、それで工程数を予測できないのは素人レベルでしょう。
さらに言えば、最終的には html に書き出すので、本当にプロジェクトを先に進めたければ、フロントエンド周りのレイアウトやらなんやらは自分でやればいいだけの話。
そのためにバックエンドサーバーはフリーで公開しているんだが？
html なんて凝った機能を使わなければ、中学生でも書けるでしょう。
猪股弘明
DolphORCA Ver 1.2
先日、DolphORCA のバックエンドサーバーが公開されたので、早速、自分でも使ってみる。
適当にフロントエンドサーバーをでっち上げ、以前に作成した HTML の WYSWYG エディタを再調整して搭載。さらに、SOA 領域をブラウザ幅の 50%になるように指定して・・・等等やって、現在はこんな表示になっている。
これくらいの表現力は欲しいなあというのが本音。
商用のクラウド型の電子カルテのそれは、現状だといまいちの感が拭えないので。
まあまあ形にはなったと思うので、次はカルテ右半分（P欄などと言われる）の検討。
ところで、何のこの段階でフリーにしたのか？と訊かれたことがあったのだが、答えておくと、「（多分）テキスト文書保管用ソフトとしてはこの段階が最も汎用性があるから」というのがその理由。
確かにキー項目の一つは soahtml というかなり医療を意識したネーミングになっているのだが、だからと言って保存できるのがカルテ SOA 欄の html 形式のテキスト文書に限られるということはない。
ここを document_text あたりに変えてしまって一般的なテキスト文字列を格納しても問題ないのだ。
ここから先、手を入れていくと、カルテっぽくはなってくると思うのだが、汎用的な文書管理システムとして見た場合は、余計な機能が付加されていくことになる。
なお、ソースコードは GitHub で公開している。
（限定公開に変更。一般公開しても、結局、あれこれ言ってくれる人は、周囲の人に限られるため、無駄だと思いやめました。それ以外の深い意味はないです。興味持ってくれれば、普通にお招きいたします）
猪股弘明
進行状況
OpenDolphin Ver7
OpenDolphin の JakartaEE 9.1, Java17 対応バージョンである OpenDolphin Ver 6 を関係者向けにリリースしたんだが、Java の EE 環境自体は JakartaEE 10 へと向かっている。
当然、OpenDolphin の JakartaEE 10 対応（OpenDolphin Ver7）も考えている。
が、これまでのように（EE 環境などの）仕様変更に伴いソースコードを単純に再調整する、という風にはならなそう。
内輪向けにプロトタイプバージョンなども披露しているが、こちらの方がどうも評判がいい。
以前から、三層クラサバ化などは図（↓）などを提示した上で提案していたのだが、具体的な形が見えた方がより反応がいいようだ。
まあ、これだと確かに概念的すぎるか。
具体的にバックエンドサーバー・フロントエンドサーバーがどのように動くか雰囲気掴んでもらうために、以下のような図を提示した。
API の出力を単純にブラウザ上に表示させているだけなんだが、どういうわけかこちらの方がウケがいい。
上の場合だと id=3 のカルテを表示してね（データベースから取ってきてブラウザ上で表示してね）ってことなのだが、この時、このリクエストやサーバーからのレスポンスは
ブラウザ⇄フロンエンドサーバ⇄バックエンドサーバー⇄データベース
という感じで流れる。
この流れが視覚的にわかりやすいってことなんでしょうか。
一般の人に基本設計がどうしただの REST がどうしただのと言っても通じないもんなんだなあと（笑）。
猪股弘明