[orca-users:15048] Re: API受付処理からの資格確認リクエスト

[Hiroaki Inomata <inomatah0612@xxxxxxxxx>]

ソースコードにあたることのメリットをもう一つ。

ORCA ではなくて、ドルフィンの方なんですが、今回、カルテ画面を
html 化や PDF 化するにあたっては、当然、元のソースコードは参考として読んでます。

探索していくと画面の大元を定義しているのは、Panel2 というクラスです。
https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m/blob/master/client/src/main/java/open/dolphin/client/Panel2.java

その冒頭はこういうものです。

package open.dolphin.client;

import java.awt.Color;
import java.awt.Font;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.print.PageFormat;
import java.awt.print.Printable;
import java.awt.print.PrinterException;
import java.awt.print.PrinterJob;
import javax.swing.JPanel;
import javax.swing.SwingUtilities;
/**
*
* @author Junzo SATO
*/
public class Panel2 extends JPanel implements Printable {

このクラスの設計及びコーディングをした Junzo SATO さんは他の場所でも
度々出てきて、かなり基本設計に近い部分を受け持っています。
その割には商用版では全く言及されることはなく、私も以前からどういった方
なのか興味深く思ってました。

最近になって、どういう方なのか判明してきました。
『電子カルテeDolphinにおけるMML3.0専用パーサー/レンダラーの開発と課題』
https://jglobal.jst.go.jp/detail?JGLOBAL_ID=200902284360909417
の筆頭著者が「佐藤純三」さんです。

演題の内容やソースコードの署名からして、この方でほぼ間違いないでしょう。

内容に関しても
Panel2 extends JPanel implements Printable
となってますから、Panel2 自体が JPanel や Printable といった
昔の Java の GUI の仕様の制約を受けていることがわかります。

ここまでわかれば、実現したい目標から照らし合わせて
「このクラス及びこの派生クラスは最終的には廃棄せざるを得ないだろう。
新規に実装し直すしかない」
といった実装上の基本的な方針が立つわけです。

また、こういった理解の仕方をしていると、巷間言われていることに
左右されずに済むといったメリットもあります。
OpenDolphin に関しては、従来は
「皆川和史氏及び（クレジットされている）数名の contributor が全てを
作成した」
というような解釈がされていたようです。
が、実際、ソースコードにあたるとそんなことはなく、特に基本設計に
近い部分に関しては、むしろクレジットされていない人の寄与の方が大きい
ように思えます。

ここら辺はけっこう混沌とした状況はあったんですが、メドレーの担当者の
方がうまく捌いていてくれて、私も助かりました。


で、ORCA に話を戻すと、ちょっと前に話題になった薬剤名称などの
インクリメンタルサーチの件などは、ここら辺の基本設計をしたと
思われる ogochan こと生越氏がいたら話はもっとスムーズにいったの
ではと思います。
ある機能を追加するのに、できるできないの判断はやはり基本設計を
した人に聞くのが一番手っ取り早いと思います。
越生氏がプロジェクトを離れた理由はなんとなくは想像はつくんですが、
プロジェクトを離れた後でも何らかの関係性を維持しておくことは
できなかったのかなあとは思います。
ちょっと惜しいなと。



猪股弘明
精神科医（精神保健指定医）


2022年6月16日(木) 6:57 Hasegawa Tsukasa <hasegawa@xxxxxxx>:

>
> 竹内様、猪俣様
>
> > >ただし、希望していたAPIからのPUSH通知及び資格確認処理ですが今月パッチで提供予定されると
> > >サポートセンタ様よりご連絡をいただきました。
>
> APIからPUSH通知ができないことは１年前を思い出しました。
> APIから外部プログラム実行や、Claimはできたので、急遽ドクターキューブ、
> 電子カルテ連携プログラムを書き換えたことを思い出しました。
> PUSH通知は、この時の要望を忘れた頃に対応いただいたものでしょう。
>
> > >
> > >外部システム側で処理するよりもスマートなのでパッチ提供を待った方が良いみたいです。
> >
> > なるほど。
> > この状況なら待った方がいいでしょうね。
> >
> >
> > ところで、ソースコードを読むことのメリットの一つとして、
> > そのシステムの設計思想を感じ取れる（場合もある）というのが
> > あるかと思います。
> >
> > ORCA の場合は、ogochan という人がよく出てきます。
> > 感心することもあれば、（現在から見ると）なんでこんな古臭い書き方してるのか
> > と疑問に思うこともあります。
> > ところで、元ORCAの中の人に聞いたら、ogochan というのは
> > 生越正己氏という方のようです。
> > ブログもお持ちのようで、拝読したらけっこう興味深い記事がありました。
> >
> > 『マルチユーザーなしに現代に必要なセキュリティを確保するのは困難すぎる」のか？』
> > http://www.nurs.or.jp/~ogochan/essay/archives/5729#more-5729
> >
> > シングルユーザー/マルチユーザーと UID の関係など、ああ、こういう発想だったのか
> > と納得する部分があります。
> >
> > ただ、多施設/単一施設という発想はまるでないようで、これは現在の ORCA の設計にも
> > 未だに根深く影響を与えているように思えます。
> >
> > 単なる感想ですが。
> >
> >
> > 猪股弘明
> > 精神科医（精神保健指定医）
> >
> > 2022年6月15日(水) 11:07 HeartBase <support@xxxxxxxxxxxx>:
> >
> > >
> > > 猪股様
> > >
> > > アドバイスありがとうございます。
> > >
> > > オンライン資格確認側に送る<ArbitraryFileIdentifier>で使われているUUIDですが、
> > > ORCA 側で確認処理リクエスト依頼の際、レスポンスを識別するために保持しています。
> > >
> > > 外部プログラム（電カルなど）で処理する際にもレスの患者識別に利用しますが、独自に患者IDとUUIDを振っても問題なく
> > > 利用できるのですがORCA側で保持している値と違うとORCA の[オン資格]機能には反映されません
> > >
> > > ただし、希望していたAPIからのPUSH通知及び資格確認処理ですが今月パッチで提供予定されると
> > > サポートセンタ様よりご連絡をいただきました。
> > >
> > > 外部システム側で処理するよりもスマートなのでパッチ提供を待った方が良いみたいです。
> > >
> > > 猪股様及びサポートセンタ様に感謝です。
> > > ありがとうございました。
> > >
> > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
> > > _/　Anbe Heart Corporation
> > > _/　竹内健治（Kenji Takeuchi）
> > > _/　埼玉県ふじみ野市大井621-12
> > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
> > > _/  mail:support@xxxxxxxxxxxx
> > > _/  Phone:049-256-0675
> > > _/  Mobile:090-6103-1136
> > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_
> > >
> > > 2022年6月15日 10:49 +0900、ORCA全般の話題 <orca-users@xxxxxxxxxxxxxx> のメール:
> > > >
> > > > 猪股
>
> ★★★☆☆☆★★★☆☆☆★★★☆☆☆★★★☆☆☆
> 株式会社スカイ・エス・エイッチ http://www.sky.sh/
> 日医総研日医IT認定サポート事業所
> 長谷川 司 hasegawa@xxxxxxx
> 京都市伏見区新町５丁目４９５北本ビル４Ｆ４０１
> TEL 075-622-7385 FAX 075-622-7403
>