電子聴診器 digital stethoscope

ちょっと興味があって、いわゆる「電子聴診器」を調べてみた。

日本だとパイオニアが U10 というのを製造・販売している。

以前に「これ、試作機ですか?」って感じの段階のものは、ネット上か何かで見かけたことがあったんだが、その頃より格段にデザイン性が向上していてびっくり。
ただし、データは専用アプリでしか閲覧できないようだ。

米国だと Eko というところが、かなり完成度の高いプロダクトを生産している。
見ての通りデザイン性はいい。
通常の聴診器としても使用でき、「電子聴診器」として使いたい場合は、トグルスイッチを押し込んでモードを変更するようだ。
デジタル化したデータは、ブルートゥースで iPhone・android の専用アプリに飛ばせるし、さらにそのデータに基づいて AI である程度の「自動診断」が可能なようだ。

さすが、リットマンの正規商品ラインナップに並んでいるだけはある。

おそらく、日本でも個人輸入で購入できるとは思うが、AI 判定などの機能は医療機器(電子聴診器だけでも日本の薬機法ではクラスII相当)に該当するので、この機能を日本の臨床現場でおおっぴらに使うのはちょっと差し障りがあるかもしれない。
アナログモードで使う分には問題ないと思いますが。
まあ、そこらへんは大人としての配慮を(笑)。

たぶん、こちらの方はデータも外部抽出できるかな。

 

ところで、なんで、「音」関係に興味を持ったかといえば、医療で出てくる波型データとしては、もっとも馴染み深いものだから。

同じ波型データとしては、心電図あたりはたびたび AI 研究の対象にもなっているが、こちらはあまり取り組まれていない。

電子カルテや DICOM ビューアを手がけている手前、こういったデータもデジタル化して取り込めないかと思った次第。

 

 

猪股弘明
医師:精神科医(精神保健指定医)
HorliX: developer
OpenDolphin-2.7m : developer

なお、心音図そのものの勉強は川崎先生の『心音図塾』などで。
非常によくまとまっています。

 

なぜ、西浦の予測は外れるのか?

8割おじさんこと西浦氏の評判は、周囲では最悪に近いのだが、その理由など。

感染症数理モデルの SEIR モデルは以下の通り。


すぐに気がつくのは再生産数 R は、このモデルには直接には入っていないことです。

細かい誘導は省略するが、R = β/γ (1/γ が平均感染期間、β は感染率)です。
βの方が基本的な指標なのは明らかでしょう。デルタ株では β が大きくなっているから、「結果」として R が増大しているんだ、と考えるのが自然です。

注目すべきなのは第二式で、その第二項を無視すれば

dE/dt = βSI

という高校生でもわかるような1階の常微分方程式になります。

これの意味するところは
「時間当たりのE(暴露者)の増分は、既に感染が成立している人数(I)とまだ感染していない人数(S)とβ(感染率)の積に比例する」
です。(だから、感染初期では指数関数的に陽性者が増えていくわけですね)
この時点でも確率的に考えているわけですから、E を増やしたくなければ β をコントロールして感染対策を考える、と思考を進めていかなくてはいけないはずです。

実際には β は、株の種類やワクチン接種率の関数になっていると思われますから、その関数型を仮定してモデルから予測→現実の数値と突き合わせる、というプロセスを踏まないと「科学」にはなりません。
反証可能性というのは、科学の基本だと思いますが、西浦の言い分は(モデルに基づいていないため)反証可能性が不十分です。

筋のいい人なら気がつくと思いますが、ある時点での結果として出てきた R をいじっても数理モデルとしては何の根拠もありません。
微分方程式の系は、それとは無関係に時間発展していくからです。

西浦の予測が外れる主な理由はこれでしょう。

 

猪股弘明
精神科医(精神保健指定医)
理学士(物理)

 

ウマ娘と Unity と物理法則

ちょっとした話題になっているウマ娘だが、少なくとも win 版は Unity というプラットフォームで開発されているようだ。
ウマ娘を win にインストールするとユーザーホーム直下に umamusume というディリクトリがつくられる。ここに Unityxxx というファイルが含まれているので推測できる。
試しに先ほど Unity をインストしてみた。これからちょっと触ってみようと思う。
なんかレーシングゲームのひな型はすでにあるような・・・。

日本人は Unity のような枠組みをつくるのは下手でも、それ使ってコンテンツつくるのは上手だなとは思う。
アイキャッチのスクショの左がウマ娘、右が Unity の画面。
ちなみにウマ娘はアグネスタキオンw

あと、気になったのは、ヲタ気味の人がつくっている「考察」動画の類で、私もプレイするときに参考程度にチラ見したが、ちょっと物足りないかな。

例えば、ある物体が等加速度運動をしている場合、時刻 t でのその速度 v は、初速度を v0、加速度を a とすると
v = v0 + a * t
で与えられる。

実際には推進力は変わるなどして等加速度運動しているわけではないだろうが、どこかにこのような基本方程式というものがある、という視点がないとちょっと物足りない。

というか、ないとゲーム自体がつくれないでしょ。

 

接触確認アプリ cocoa とオープンソース

某所でコメントしたことの転載。


cocoa はバグが枯れてきた印象はあるんですが、今後も継続的に適切な保守開発が行われるかというと若干疑問もあります。
契約の詳細まではわかりませんが、実際に保守開発を行っているであろうデザイアードには405万の費用しか渡っていないからです。
https://www.tokyo-np.co.jp/article/87051/

エンジニアを一人 40 万/月でアサインして 10 ヶ月保守したら、予算尽きてしまいます。
今後どういう運営をするつもりなのかの説明がまったくないのでこのままでは信用できません。

そして、このプロジェクトが興味深い点は、元はオープンソースで、献身的なエンジニアがバグなどをボランティア的に見つけ、その改善策を提案しているところです。
今回の修正もおそらくそれらを参考になされたものだと思いますが、その点をいっさい伏せて、さも「自分たちで修正しました」というのは、ちょっとどうかと個人的には思います。

そして、これが一番ダメなんじゃないかと思うのは、プルリクエスト(コードの修正依頼)に対して、厚労省側のレビューが全くない点です。
これされると(=オープンソース性の喪失)今後バグが出てもその責任箇所を指摘できないし、どう修正していいかといった提案も当然できません。
これやって失敗したプロジェクトはけっこうあります。

最後に、ボランティアで参加したエンジニアの方の意見を一つあげておきます。

Issueとは直接関係ないのでコメントとして記載します。

現在のCOCOAの状況を大変、憂慮しています。

このIssueを見ている関係者の方は居られないのかもしれません。しかし、もし居られるならば、今一度、オープンソースのやり方でCOCOAを継続的に改善する方向へ舵を切ることを何卒ご検討ください。

もしそうなったならば、ぼくはAndroidアプリ開発に携わるソフトウェア開発者の一人として、お力になれるものと確信しています。

https://github.com/cocoa-mhlw/cocoa/issues/21?#issuecomment-780502093

 

猪股弘明
医師:精神科

 

オープンソースの世界 〜残酷な自由さ〜

オープンソース開発方式は理想の開発形態の一つとして語られることも多いが、現場寄りの人はかなりリアルな見解を持っている。

開発者目線では…

例えば、以前評判になったこの記事。

筆者の megamouth さんによれば、contributor(ソースコードを提供した者)にも序列があるという。


OSSへのコントリビューターにもカーストがあって、ついでに書いておくと

カーネルメンテナ>言語メンテナ>カーネルコミッター>言語コミッター>有名ライブラリメンテナ>色々>ユーザーグループ主催者>ブログでアプリへの文句だけ書奴~

みたいな序列である。

ある程度名の通ったプロジェクトの contributor になるだけでもけっこう苦労するよ、という挿話が語られている。

曰く、


アホみたいな量のコードを読み下し、コーディングスタイルを真似し、単体テストケースを書き、開発者とコミュニケーションをとってまで、自分のコードをマージしてもらう。

プルリクエスト(Pull Request PR, 自分の改変したコードを取り込んでもらう修正依頼のこと)送るだけでも大変なのだ。

さらに、新機能の提案などになると・・・

新機能にしても、同じようなことは過去の誰かが考えているものだ。それらの機能が今存在しないのは、何らかの経緯で却下されたか無視されたことによることがほとんどである。
もし彼が「ぼくのかんがえたすごいしんきのう」を拙いCコードで表現することに成功したとしても、Google翻訳を駆使して、なんとか英語圏の人間に読めるプルリクを送れたとしても、忙しいメンテナが一瞥して言うことは「過去ログ嫁」である。

単に PR 送るより大変なのがわかる。

きっかけは個人的な欲求から始まる

ところで、私がオープンソースの世界に足を踏み入れ始めたのは、2018 年の春頃からだ。
きっかけは horos という医療用画像ビューアのプロジェクトの存在を知ったとき。
医療画像ビューアは一般に高額で、レントゲンや CT の画像を「ちょっと」確認する程度であれば、オープンソースのプロジェクトの公開されているソースコードを自力でビルドして使った方が金銭的な節約になる。
おまけに自分で改変もできる。ちょっと使いにくいというところがあれば、そこを自分で改変したっていいのだ。
私の場合、改変したいくつかの機能は、horos の本プロジェクトにも PR を送り、マージしてもらった。


そういう意味では、私は「医療用の OSS」 というニッチな分野では contributor なのだが、上で述べられたようにすごく苦労したかといえば、そんなことはない。
OSS のカースト的にみれば「アプリケーション」レベルだし、何よりも「医療」と名が付くと開発寄りの参加者は極端に減る傾向がある
慢性的な人手不足なのだ。この分野では一定水準のプログラミングスキルを持った人なら、新機能の提案・実装は、(カーネルなどへ contribution するのに比べたら)かなり楽だ。

ある程度慣れたきた段階で、自分でもプロジェクトを持つようになった。

だから、けっこう短期間の割には PR を送る側の経験も受け取る側の経験も両方したことになる。

ところで、ネットを見ていると「どうやったら PR をマージしてもらえるか?」みたいな記事は見つかるのだが、逆に「これやっちゃあかん!」というような記事はあまりない。
参考になるかどうかわからないが、一つ例示したいと思う。

マージされなかった Pull Request の例

以下は、私たちが OpenOcean という OpenDolphin 由来の電子カルテのプロジェクトで、クライアントバイナリを配布してきた時にもらった PR 。
公開するのもはばかれるような内容な気もするが、当人たちは open にしろしろと主張しているのでここで取り上げても問題ないでしょう。


一目でわかる通り、単純に特定行を delete したのみ(文頭の – は削除した印)。
この場合で言えば、public static int expired( ) という関数が関与する部分を削除しましたってだけの内容。

一般にコード書きが何かを実装する場合、たいてい、狙った機能というものがある。
上記のコードでは特定時刻と現在の時刻を比較し、現在時刻が特定時刻より先に進んでいた場合、そのプログラム自体を終了せよというのが狙った機能だ。
要するにこのアプリの使用期限を設定している。(この時点で元のプロジェクトにはれっきとした商用版が存在しており、こちらはちょっとした機能の提案をしたかっただけ。気合い入れて継続的に開発していく意思がなかったというのがその理由)

だから、これは bug (バグ)ではない。

確かに、プログラムが複雑になってくると、深刻なバグがあるにもかかわらずそれがどこにあるかわからないといった場合はよくある。このような場合、それを特定するだけでも貴重な情報になる。
だが、これはそういった類のものではない。

だから、この PR はマージできない。

逆に、「残り XX 日で使用不能になります」といったアラートダイアログなどを表示させるようなコードの場合、おそらくコードの書き方が少々稚拙であってもこちらで手直ししてマージしたのではないかと思う(例え、この噂が本当であったとしても、だ)。

つまり、相手(レビュアーやメンテナー:PR を評価しリポジトリを管理する人たち)の意図を汲み取ってプロジェクトにとってプラスの価値を与えるようなプルリクには大概のメンテナーは寛容でありマージもされやすいが、単に自分の願望を押し付けるだけでは考慮もされないのだ。実際このときもそれが主な理由でマージはしなかった。

(付記)その他の理由 -著作権に対する配慮-

上で「主な理由」と書いたが、他にも気になった点はあった。
というのは、このとき PR 送ってきた相手の GitHub アカウントのアバターが、全世界でかなりの人気を誇るアニメのキャラだったから。漫画・アニメなどで人気のあるキャラの2次利用は、たいていの場合制限されている。
実際、このキャラクターは基本的には2次利用を許していない。
もしかすると、この人と著作権管理団体などで使用許諾の契約がなされているのかもしれないが、基本的には第三者にはそんなことはわからない。
そして、PR を送ってきた相手はまったく知らない人だ。信用できる人なのかどうかもわからない。
一応、名前や所属などは確認したが(京都大の小林慎治という人。現在は、保健医療科学院に所属)、ここらへんの権利関係に関してはまったく気にしていないようだった。
私が気になったのはこの点だ。
OpenOcean プロジェクトに関しては特に行動規範(CODE of CONDUCT)のようなものは定めてはいなかったが、やはり「知的財産権に関して一定の配慮ができる」というのが最低限の暗黙の前提になる。
どんなオープンソースのプロジェクトでもそうだが、ネット接続環境を持っていて、アカウントさえあれば、議論に参加するくらいのことはできる。有意義な議論になることもあれば、まったく不毛な質の低いものになることもある。ネットで不特定多数を相手にするというのはそういうことなのだ。そして、意味のある議論ができるかどうかは実社会のステータスとは相関しない場合が多い。主張している内容や実際に書いたコードでその人の能力を推し量るしかないのだ。(蛇足かもしれないが、それはオープンソースの可能性でもあるだろう。全く無名の人でも活躍できることに繋がるのだから。)
だから、何かをしたい・信用を勝ち得たいというならば、その資質を実践で示す必要がある。それ以外の基本的な部分でレビュアーやメンテナに不信感を持たせては、まず PR は拒否されるし、以降はまともには相手にしてもらえないだろう。

Fork の効用・意味

また、付け加えておくと、アプリケーションレベルのOSSでは、「エンドユーザーに近い」という特性ゆえ、異なるバージョンの開発が並行して進められるということはよくある(当たり前だがユーザーには「好み」があるから)。
特に、電子カルテのように施設毎でのカスタマイズが前提になる場合はその傾向が顕著になる。実際、元になったプロジェクト自体、施設毎での独自カスタマイズを奨励していた。自分で既存のプロジェクトにはない機能を付加したいというなら、元プロジェクトを fork して独自プロジェクトをおこせばいいだけだ。

まとめ? 残酷でもあるが自由でもある

既存のプロジェクトに自分の提案を受け入れて欲しいというなら、相手の意図にはある程度意識的になる必要がある。もし、それが叶わないというのなら、自分で独立してプロジェクトおこせ、ということになる。
タイトルに「残酷」と入れたが、ある意味、それはオープンソースの世界の自由さとも言える。

 

他にも面白い話もあるので、また続き書きます。

 

猪股弘明