OpenDolphin から OpenOcean に改名したので、今までの仕事をまとめておこうと思い、サイトを新調した。
その際に、ネット上で情報収集をおこなったのだが、けっこう興味深かったのが、
医療情報系の大学研究室のゼミの公開ブログのようなのだけど、題材として OpenDolphin が取り上げられている。将来的には Dolphin と繋がるオリジナルのスマホアプリをつくりたいらしい。それで、データ構造を把握するためにクライアント-サーバ 間で流れる通信パケットを WireShark でキャプチャして解析したという予備研究。
これはこれで SSL 通信の重要性を示すものとしてまあまあ意味はあると思うけど、目的に対するアプローチの仕方としてはどうなんだろう？
というのは…
・サーバを走らせた場合、キャプチャしなくても通信内容は同様のものが得られる
というのがその理由の一つ。上記記事を再現してみると「嘔吐・下痢の症状が見られる」という所見を SOA 欄に書き込み、サーバに送信。
ドッカーでは無理だが、普通にサーバを走らせていた場合、Java の（というか Java のライブラリの）ロガーは優秀なので、Win だろうが Mac だろうが Ubuntu だろうが、こんなログを吐き出してくれる（今回は Win10）。
所見の平文対応文字列「PD…（略）…4K」は（当たり前だが）まったくいっしょ。
だから、サーバを走らせれば、キャプチャする意味は（ほぼ）ないのだ。
他にも別の unix 系のコマンドを使えば、通信内容の取得は可能です。
また、トライアンドエラーでサーバの応答をある程度まで求め、それにあわせてクライアントをつくったとしても、
・LSC がサーバの仕様を変えてしまえば、そのアプリは使えなくなる
のではないかと思う。
そして、これは研究全体の方向性に対することだが、
・改変不能なドッカー版サーバを使っている限り、クライアントの仕様はサーバに規定され、クライアントの設計の自由度が落ちるのではないか
という疑問が湧く。
最終的にどういうスマホアプリを目指されているか私程度のものが知る由もないが、個人的には、われわれのように実務家的なちまちまとした工夫を重ねるのではなく、大学には、大学の研究らしくもっと自由で大胆な発想をしてほしいと思う。
まあ、私のおすすめは、自由にスマホアプリをつくりたければ、サーバ・クライアントともに Java ソース読んだ方がいいでしょう、ということです。
せっかくソースを公開してくれているのだから。
OpenDolphin で実現されている REST API の仕組みなどはこの分野の基本といってよく、勉強しておいて損のないところだと思います。
（追記）…beanbytes の処理に関しては、元町皮膚科の松村先生のブログ記事にわかりやすい解説があったので、追記しておく。
HealthInsuranceModel，StampModel，ModuleModel には beanBytes というフィールドがあり，bean object を xml 変換して，さらにbyte 配列に変換したものが入って永続化されている。今回，REST化で json を使ったため，object が xml に変換されてさらに byte 配列に変換された beanBytes が json 化でさらに Base64 の文字列に変換されて流されるという，何だかたいそう複雑なことになってしまっていた。
（追記２）なお、現在の開発元のメドレーによれば、松村哲理氏は contirbutor として認められていないので、念の為。
いわゆる「契約」問題の話はおいておいても・・・
beanBytes の説明自体は間違ってはいない（ただし、基本設計を考えるとこの通信形式はそんなにおかしくもない）。が、dolphin が画像を保存する際、jpeg に限定されてしまうのだが、ここらへんの不自然さに対する説明は一切なし。
シェーマエディタは、佐藤純三氏のコードの上に後付けで実装されたものなので、この機能を外してしまうと（外しても動作するし、外したバージョンの方が好評。たぶん、一部の診療科以外、この機能は不要なんでしょう）、彼の貢献はほぼなくなってしまう。
・・・といった理由からでしょうか。
そもそも、わざわざ実装した画像エディタの保存形式が（lossless でない） JPEG 限定とか、臨床に従事している医師の感覚ではちょっとあり得ない感じです。
（追記３）私の周囲のユーザーさんは「医療画像を情報損失のある JPEG で保存するのは論外だし、その上にのっている機能も不要」という声が多数を占めているので、DolphORCA では、ここら辺は修正予定。
（追記４）いわゆる java17 問題で、画像周りの問題はさらに顕在化。
OpenDolphin では、swing GUI コンポーネント上に強引に表示させた画像を hibernate で永続化する、という手法をとっています。
が、これは今となってはかなり無理のある構成なので、公開されている opendolphin のソースコードを少々手直しした程度では、（今のところ）サーバープログラムはアプリケーションサーバにデプロイできません。
ライブラリなどの開発元が古い swing コンポーネントの対応をしてくれれば解決はするんですが、現状では実現されていません。
自力運用している施設では java のアップデートに合わせて松村哲理氏、増田茂氏がクライアントアプリに付加した機能を取り外す方向で検討しているところが多いようです。
