[orca-users:14682] Re: ptid のデータベース上での定義について

[Hiroaki Inomata <inomatah0612@xxxxxxxxx>]

ORCA管理機構
上野様


ちょうどよく別スレで「データを２次利用したい」という投稿もあったので、それを踏まえて
いいますが、「速度」だけを気にして投稿したのではありません。

今回の例（tbl_uketuke まわり）でいうと、「お行儀よく」api を使えば、指定した日の
受付情報は取ってこれます。（ですよね？）
ですが、「直近一ヶ月の受付情報を持ってきたい」などという場合、けっこう面倒くさい
処理をさせなくてはならないので、それだったら、該当テーブルを直接覗いた方が速いと
考えたわけです。

そのときに integer 型だと思い込んでいた ptid が numeric 型だったので、原因不明の
エラーがでて気がついた、という次第です。
（その時はまったく理由がわからなかった。思い込みは怖い）

臨床に即していうと、「外来通院中の独居患者さんが不幸にも自宅で亡くなられた。不審死の
疑いもあるため、警察から問い合わせがきた」などという例は多いと思います。
たいていカルテを参照して最終受診日や処方内容などを答えると思うのですが、「外来予約は
していたのだが、受診していなかった」などという情報もあるとなおよいわけです。

実際、オルカ（オンプレミス版の方）のデータベースに直接問い合わせてデータ活用をはかる
ユーティリティソフトの類は多いと思います。

別に api がダメだと言っているわけではなく、きめ細かい処理をしようとすると現状だとそうなって
しまうという意味です。

またフレームワークの話に触れたのもこれが理由です。
将来的には医療情報の類はクラウドに上げて一元管理・ビッグデータとしての活用を図る・・云々
みたいな話は、まあそうだろうなとは思うのですが、このとき医療機関側が欲しい情報を取ってこれる
環境になっていないとデメリットの方が大きく、実際には誰も参加しないだろうなと思います。
（法的にも医療情報の管理責任は、現状だと医療機関側です。業者ではありません）
欲しい情報を効率よく取ってこれるかどうかは、データ構造の整合性に大きく依存するのではないで
しょうか。
これを実現する割と有効な選択肢は現在だといわゆるウェブフレームワークの採用かなと思ったわけです。

オルカの職人芸的なデータベースの使い方も嫌いではありませんが（笑）、この後の展開を考えると
なるべくデータ間の「辻褄が合うように」整合性をはかっておく、モデル化しやすいように準備しておく、
というのはあっていいのかなと思った次第です。


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

2020年10月2日(金) 17:59 ueno <t.ueno@xxxxxxxxxxxx>:

>
> 猪股先生
>
> 言い訳です・・
> 確かに型が一致していないことは問題ですが、
> 当時に比べpostgresqlの性能もマシン性能も上がり、
> 型による速度の問題もなく、又そして型を変換するデータ量も膨大になり、
> この件に関して言えば、優先度はかなり落ちてしまっています。
> なので完全に日レセをリニューアルするといったことになれば、
> 当然このあたりも解消させなければいけないと考えております。
>
> 上野拝
>
> 2020年10月2日(金) 10:45 Hiroaki Inomata <inomatah0612@xxxxxxxxx>:
> >
> > ORCA管理機構
> > 上野 智明様
> >
> >
> > お世話になっております。
> >
> > 明快な回答ありがとうございます。
> >
> > >開発スタート当初に、ミドルウェアの仕様とCOBOLの特性から
> > >integer型ではなくnumeric型で定義することとなりました。
> >
> > GnuCOBOL（当時のOpenCOBOLでしょうか）は固定小数点を扱えるという
> > 話は聞いております。
> > その仕様が反映されていたわけですね。
> >
> >
> > >その後の改修やデータ肥大化対応のためinteger型に変更する
> > >ことになりましたが、スキーマを変更するテーブル数と
> > >パッチ処理の兼ね合いで変更するテーブルを絞ったために
> > >numeric型のままのものも存在している、という状況です。
> >
> > もちろんデータ型は統一されていた方がいいと思いますが、作業量の問題から
> > 適宜修正、というように受け取りました。
> > おそらく関係者のみなさんの間では散々議論されていることなのでしょうが、
> > どこかの段階で適当なフレームワークを導入してある程度大規模な改修を図る、
> > という方向性もあるかと思います。
> > そのような検討はなされているでしょうか？
> >
> >
> >
> > 猪股弘明
> > 精神科：精神保健指定医
> >
> > 2020年10月1日(木) 13:16 ueno <t.ueno@xxxxxxxxxxxx>:
> > >
> > > 猪股先生
> > > ORCA管理機構の上野と申します
> > >
> > > お世話になっております。
> > > 本件について長年の経緯をひもといてみると、
> > > 開発スタート当初に、ミドルウェアの仕様とCOBOLの特性から
> > > integer型ではなくnumeric型で定義することとなりました。
> > > その後の改修やデータ肥大化対応のためinteger型に変更する
> > > ことになりましたが、スキーマを変更するテーブル数と
> > > パッチ処理の兼ね合いで変更するテーブルを絞ったために
> > > numeric型のままのものも存在している、という状況です。
> > >
> > > 上野拝
> > >
> > > 2020年9月30日(水) 2:06 Hiroaki Inomata <inomatah0612@xxxxxxxxx>:
> > > >
> > > > このMLで扱うトピックスとして適当かどうか不明ですが、最近、ORCA のデータベースを
> > > > 眺めていて疑問に思ったことがあるので、質問させてください。
> > > >
> > > > ptid に関することです。
> > > >
> > > > 患者さんの基本情報は、public.tbl_ptinf に記録されていると思うのですが、
> > > > ここでの ptid の型定義は bigint です。
> > > >
> > > > ところが、患者さんの外来受付を記録していると思われる public.tbl_uketuke では
> > > > ptid の型定義は numeric(10,0) で、特に外部制約も付けられていません。
> > > >
> > > > PostgreSQL の numeric 型は、小数点を含むような数値を精度よく記録させる
> > > > ときに使うものと理解していました。
> > > > 例えば numeric(6,4) で定義されたカラムに 12.3456 を挿入するような場合です。
> > > > 精度よく記録できるかわりにクエリー時の実行速度が遅くなったかと思います。
> > > >
> > > > 一般に ID が小数点になる場合は考えにくく、なぜこのような定義になっているのか
> > > > 疑問に思いました。
> > > >
> > > > COBOL プログラム側の制約か何かでこのような定義になっているのでしょうか？
> > > >
> > > >
> > > >
> > > > 猪股弘明
> > > > 精神科：精神保健指定医
> > >
> > >
> > >
> > > --
> > > 日本医師会ORCA管理機構
> > > 上野 智明
> > > t.ueno@xxxxxxxxxxxx
> > > 03-5981-9681
> > > 080-4912-6787
> > > http://www.orcamo.co.jp/
> > > http://www.orca.med.or.jp/
> > > @orcadays
> > >
> > > ◆◆◆日本医師会ＯＲＣＡ管理機構　カタログサイト開設◆◆◆
> > >　 ◇医療機関が必要とするＩＣＴ関連機器、サービスを一堂に掲載する
> > >　　　 カタログサイト『メディカタログ』を開設しました
> > >　　　 ⇒ http://medi-catalog.com/
>
>
>
> --
> 日本医師会ORCA管理機構
> 上野 智明
> t.ueno@xxxxxxxxxxxx
> 03-5981-9681
> 080-4912-6787
> http://www.orcamo.co.jp/
> http://www.orca.med.or.jp/
> @orcadays
>
> ◆◆◆日本医師会ＯＲＣＡ管理機構　カタログサイト開設◆◆◆
>　 ◇医療機関が必要とするＩＣＴ関連機器、サービスを一堂に掲載する
>　　　 カタログサイト『メディカタログ』を開設しました
>　　　 ⇒ http://medi-catalog.com/