5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

LAMPで電子カルテ&レセコン作らね?

1 :1 ◆10UKulele6 :2007/11/29(木) 09:21:40
AjaxとFlashも使って。

2 :1 ◆10UKulele6 :2007/11/29(木) 11:27:10
基本はPHP。一部Ajax。
シェーマとかはFlashで作成→GIF保存。
自由なテキスト入力を認めつつ、
記載内容から指導や指導の点数を加算。
画面はWINE-STYLEみたいで良いと思うが、
あんな風にぽこぽこ画面は開かずに、
1患者1ウィンドウで完結させる。

データを、データベースに保存すべきか、
患者ごとのフォルダに1受診ごとの
ファイルにするべきか、考え中。
(検索性なら前者だし、可搬性なら後者)


3 :名無しさん@お腹いっぱい。:2007/11/29(木) 14:55:02
ワイビス

4 :1 ◆10UKulele6 :2007/11/29(木) 15:49:32
>>3
んー、それは何?

以前、レセコンを作りかけた時に思ったのは、
レセは診療報酬の仕組みが複雑で、追随が大変。
で、プラグインみたいにしてルールを追加できる
ように考えたんだけど。じゃあ、無数にあるルールを
だれがスクリプト化するんだ?ってところで挫折。

でも、電子カルテの部分に関しては、そういうのは
無いと思うので。まずはこちらから取り組むべき
だったと、ちょっと反省してる。

つーか。完全に独り言。チラシの裏だな。

5 :名無しさん@お腹いっぱい。:2007/11/29(木) 18:17:44
いやいや面白いぞ、もっと語れw

6 :名無しさん@お腹いっぱい。:2007/11/29(木) 19:39:43
あげ

7 :1 ◆10UKulele6 :2007/11/29(木) 20:20:09
語るのが目的じゃないんで・・・作ってみまっせ。

その前に、サンヨーのレセコンでも視察して来るわ。

8 :1 ◆10UKulele6 :2007/11/29(木) 22:56:07
つい「LAMP」って書いちまったが、Linuxに限るつもりはない。
むしろ、実際の開発環境はMac。PHPは常用中。

だけど、MySQLをシステムにインスコするのは嫌なので、
あえて久しぶりにMAMP1.7をインスコ。
文字化けの対策が不安だが。
とりあえず、データベースを使う事にする。


9 :1 ◆10UKulele6 :2007/11/29(木) 23:12:07
フレームワークは「ちいたん」
ttp://php.cheetan.net/

テンプレートエンジンは「MuMu」
ttp://qwik.jp/mumu/FrontPage.html

以前、FPDFを調べていたんだけど、
日本語を使うのに苦労したので、
どうしようか・・・と思っていたら。
最近、「TCPDF」なんてのが出てた。
ttp://www.tecnick.com/public/code/cp_dpage.php?aiocp_dp=tcpdf
日本語はまだ微妙なのか?

10 :名無しさん@お腹いっぱい。:2007/11/30(金) 00:53:55
それでそれで?

11 :1 ◆10UKulele6 :2007/11/30(金) 07:50:19
まず、データベースの構成を作り始めたので、
しばらく沈黙するかも。


12 :1 ◆10UKulele6 :2007/11/30(金) 11:31:50
まだ構想なんだけど。
例えば薬の併用禁忌とか、病名チェックとかの
データベースって、それぞれのローカルにも
保存するんだけど。
できれば、Wikiみたいに(?)共有・編集できるといい。


13 :名無しさん@お腹いっぱい。:2007/12/02(日) 17:36:19
きちんといたアイデアや構想があるのであれば一度会社で議論して
プロジェクトとして立ち上げれるのがベストじゃない?



14 :1 ◆10UKulele6 :2007/12/02(日) 19:36:11
会社じゃないんだもん。

15 :名無しさん@お腹いっぱい。:2007/12/04(火) 13:13:52
立ちあげればいいじゃない

16 :名無しさん@お腹いっぱい。:2007/12/04(火) 17:08:00
お菓子を食べればいいじゃない

17 :名無しさん@お腹いっぱい。:2007/12/08(土) 15:35:18
マリーアントワネットがいるな

18 :名無しさん@お腹いっぱい。:2007/12/29(土) 06:26:49
ルイルイ

19 :名無しさん@お腹いっぱい。:2007/12/29(土) 06:28:22
イノベ野郎は馬鹿社員

20 :名無しさん@お腹いっぱい。:2007/12/29(土) 09:46:26
>>1
それで結局完成したんか?

21 :名無しさん@お腹いっぱい。:2007/12/30(日) 12:14:37
Flushの電カルなんかウケるw

22 :名無しさん@お腹いっぱい。:2007/12/30(日) 15:15:39
何が可笑しい!?

23 :名無しさん@お腹いっぱい。:2008/01/13(日) 23:31:40
らんぷ亭

24 :名無しさん@お腹いっぱい。:2008/02/01(金) 20:19:25
頑張れ>>1

25 :1 ◆10UKulele6 :2008/02/02(土) 13:36:04
まだなんにも進んでません。人( ̄ω ̄;) スマヌ

そいで、各社メーカー製のレセコンを見まくってた。
正直言って、昔に比べて全然良い。でも高すぎる。

で、RsBaseってのがあるのを忘れてた。
あれ、ほとんど電子カルテっぽいのに、
そういう実装はしてないのな。もったいない。

車輪の再発明になりそうな悪寒。
つーか、RsBaseの良い所を参考にしたいが、
Perlは苦手なんだよな・・・

26 :名無しさん@お腹いっぱい。:2008/02/03(日) 13:04:49
>>25
Perlくらい楽勝じゃね?


27 :名無しさん@お腹いっぱい。:2008/03/01(土) 07:55:49
どうなった>>1


28 :名無しさん@お腹いっぱい。:2008/03/01(土) 13:42:59
まず電子カルテにしといたらどうですか?
レセコンは改訂の度に大変だし地域対応がありすぎる


レセ電算といってもまだ返戻やら総括やら紙が消えてない
あと二年で診療所までオンライン義務化だから
それまでにペーパーレスが進むと思うし


特定健診や特定指導むけのソフトでも面白いと思う
論議を戦わせて共同開発したい先生結構いるんじゃない?

29 :名無しさん@お腹いっぱい。:2008/03/08(土) 08:13:11
そういう人のためのスレでわ

30 :名無しさん@お腹いっぱい。:2008/03/15(土) 00:02:58
誰かLAMPでレセコン作ってくれ

31 :名無しさん@お腹いっぱい。:2008/03/16(日) 14:34:15
まずお前が作れ

32 :名無しさん@お腹いっぱい。:2008/03/24(月) 11:00:28
age

33 :名無しさん@お腹いっぱい。:2008/04/05(土) 22:52:13
age

34 :名無しさん@お腹いっぱい。:2008/04/19(土) 00:32:05
age

35 :名無しさん@お腹いっぱい。:2008/04/21(月) 08:56:02
誰かできた?

36 :名無しさん@お腹いっぱい。:2008/04/23(水) 09:25:26
無理

37 :名無しさん@お腹いっぱい。:2008/04/23(水) 10:47:45
各社電子カルテを見まくってるが。
案外、異業種(に見える)から新規参入も多いのな。
導入実績500件で、経営が成り立ってるのか?
導入実績100件なんてメーカーもある。

レセコンはORCAと、レセプトチェッカーの
組み合わせでもいいかとも思う。

38 :名無しさん@お腹いっぱい。:2008/04/23(水) 15:14:07
で、あなたはどの組みあわせなの?

39 :名無しさん@お腹いっぱい。:2008/04/23(水) 18:40:50
ORCAのやつORCA?いやいやマジで

40 :名無しさん@お腹いっぱい。:2008/05/07(水) 21:15:20
診療報酬改定で実感するが、仮にレセコン作成はできても、継続運用は無理。
制度を理解しきれないよぉ…。
しかも3月上旬から3月末までにマスタ設定&改修だなんて…。

LAMPで電子カルテ&オーダリング&レセコンならPHP+Symfonyのがいいんでは?
設定ファイル(YAML)多用するから、柔軟性あるし。

現状、医者の要望にこたえるため、iniファイルいじりまくりだから。
設定ファイルでの柔軟性は必須かと。

41 :名無しさん@お腹いっぱい。:2008/05/20(火) 17:46:04
souda

42 :名無しさん@お腹いっぱい。:2008/05/20(火) 23:59:43
Symfonyって知らないんだが。
Ajaxにも使えるの?

メインのウィンドウを3つの領域に区切って、
それぞれの領域毎に書き換え、ってしないと。
例えば過去カルテのページをめくるたびに
全画面を書き換えていたら効率が悪過ぎる。


43 :名無しさん@お腹いっぱい。:2008/05/22(木) 01:20:11
 今のところ、PHPのフレームワークは、symfony,cakePHP,ZendFramework
の3つが代表的。
 symfonyとZendFrameworkはPHP5にのみ対応しています。
 
 で、symfonyはもちろんAjaxに対応していて、というよりprototype.jsなどの
Ajaxライブラリが標準でインストールされていて、それらを簡単に呼び出すこと
ができます。

 3分割でそれぞれAjax通信するのも、結構簡単に実現します。

 div要素で3領域を指定→symfonyのlink_to_remoto()文で書き換えたいdiv要素
を指定するといった手順になり、XmlHttpRequest()など一切書く必要がありません。

 MicrosoftAccessやVBでいうところのサブフォーム的な使い方ができるので、
便利なんじゃないかなぁ。

44 :名無しさん@お腹いっぱい。:2008/05/22(木) 11:09:58
ブラウザの違いを吸収してもらえるだけでありがたい。

symfonyの日本語情報サイトが充実してきてるのも
うれしいが。やっぱり解説本が欲しいなぁ。

45 :名無しさん@お腹いっぱい。:2008/05/28(水) 15:02:08
リンクくれ

46 :名無しさん@お腹いっぱい。:2008/05/29(木) 21:58:31
>>37
ユーザ2件、創業3年で倒産したカルテメーカーを知っている
お気をつけあれ

47 :名無しさん@お腹いっぱい。:2008/05/29(木) 22:29:11
むしろ、ユーザー2件で、3年存続した事の方が不思議。

48 :名無しさん@お腹いっぱい。:2008/06/09(月) 22:19:56
え?オーダリングまでやるの?


49 :名無しさん@お腹いっぱい。:2008/06/09(月) 23:20:33
>>48
どこで聞いたんだ?そんな話ww

50 :名無しさん@お腹いっぱい。:2008/06/13(金) 19:33:26
風聞

51 :名無しさん@お腹いっぱい。:2008/06/14(土) 13:18:09
>>47
某オーダリングメーカーの開発部ボスが
開発とインストラクタを一人ずつ連れて独立
オーダリングを改造して電子カルテにして
付き合いのある病院に導入


その他には売れず資金繰り悪化

52 :名無しさん@お腹いっぱい。:2008/06/14(土) 15:07:19
symfonyの本を購入。明日届く。

レセプトチェッカーを使い始めたが、こいつよくできてる。
さすが、保険医協会が監修してるだけのことはある。


53 :名無しさん@お腹いっぱい。:2008/06/15(日) 21:33:31
symfonyの本と、
http://d.hatena.ne.jp/tolerance/20071222
を見ながら、MAMP1.71にsymfonyをようやくインストールできた。
(先に入れていたMAMP1.7は、なぜかpearが壊れていた)
インストールが面倒なのが良くないな。


54 :名無しさん@お腹いっぱい。:2008/06/19(木) 23:03:34
行動力あるなぁ…。
どうですかsymfonyは?

55 :名無しさん@お腹いっぱい。:2008/06/20(金) 10:41:58
とにもかくにも、インストールが厄介。しかもMAMPに入れたから尚更。
pearは大概どこでも入ってるんだろうけど、pear経由のインストールは
ターミナルを使うのが敷居が高い。また、apacheのhttpd.confの編集が
必要ってのも厄介。ymlでの設定も良し悪しかなぁ。
sandboxでのインストールは試してないけど、本稼働には向かないらしい。
本の副題に「大規模開発もサポートするsymfpny」って書いてあるけど、
逆に言うと、小規模な開発には大袈裟すぎるんじゃないかな、と思った。

一方、試しにCakePHPを入れてみた。CakePHP自体は、フォルダーを
入れるだけで完了。あまりの簡単さに笑った。しかも、DBへの接続は
見慣れたPHPのファイルにパスワードを書き込むだけで、あっさり
接続完了。これも簡単だった。
まだサンプルは試してないが、手軽さではCakePHPは好印象。

56 :名無しさん@お腹いっぱい。:2008/06/21(土) 23:49:38
そうかぁ…。
ま、対象とするシステムの規模によるってことかな?
診療所なのか、病院なのか、病院なら300床以上の中大規模なのか…とか。

中大規模の場合、手軽さより安定性・メンテナンス性を優先した方がいいとは思う。

57 :名無しさん@お腹いっぱい。:2008/06/22(日) 20:00:01
対象にするのは診療所。だから、小規模で良い。
「病院もカバーできるスケーラビリティ」とか言い出すと、
ORCAみたいに収拾がつかなくなる。

インストールの容易さやメンテナンス性って意味でも、
外部ライブラリへの依存とかは少ない方が良いと思ってる。
極端に言えば、フレームワークさえも使わずにできれば
いいけど・・・間違いなく何らかのフレームワークを
使った方が、後のメンテナンス性は良くなるだろうと思う。


58 :名無しさん@お腹いっぱい。:2008/06/23(月) 01:57:08
 診療所規模のシステムだと、確かにsymfonyは大袈裟かもしれませんね。

 自分なんか、フレームワークに頼りっぱなし…。
 便利だけど、やっぱ習得までの壁があるのかなぁ。自由に書いてた人にとっちゃ
すごい規制が入るからなぁ。

 コードがりがり書きたいってのがあるんだろうか…。そういう意味じゃ、自分は
プログラマではないな。

59 :名無しさん@お腹いっぱい。:2008/06/23(月) 22:12:15
>>58
symfonyを勧めてくれた方?
私には合わないみたいだけど、参考にはなりました。ありがとう。

私とて、なんでもコードをがりがり書きたい訳では無いです。
特に、PHPのスクリプトの中にSQLを書き込むのが一番イヤ。
似たような機能をもっと上手に書いてる人がいるに違いない部分は
是非とも利用したい←これこそ、フレームワークの存在理由

余談だけど。大抵どんな言語でも、理解が進むうちに、
「こうすれば、こう動くな〜」ってイメージが出来るようになる。
だけど、symfonyは全くそういうイメージが出てこなかった。
ここまで相性が悪いのも珍しい。

60 :名無しさん@お腹いっぱい。:2008/06/29(日) 23:12:05
ようやくCakePHPの公式チュートリアルをやってみた。

「10分で作るCakePHP」のビデオでScaffoldingを使って作り上げるのをいくら見ても、
応用方法がさっぱり分からなかったが。ちゃんとチュートリアルを終わらせたら、
ようやく作り方が見えてきた。

Symfonyは、Symfonyの構成ファイルに混じって、自分のファイルをあっちこっちに
置く感じで分かりにくかったんだけど。

CakePHPは、自分が書くファイルはappフォルダの中にまとまっているので、分かりやすい。
そいで、おそらく、誰かにあげる時には、appフォルダを渡せばいいんだよね、きっと。

なにぶん、フレームワークは初めてなんで、とりあえずCakePHPで慣れてみるわ。
フレームワークに慣れてきたら、Symfonyの本を読んでも理解できなかった所が分かるよ
うになって、場合によっては乗り換えるかもしれんし。


61 :名無しさん@お腹いっぱい。:2008/06/30(月) 22:12:28
がんばれ〜

62 :名無しさん@お腹いっぱい。:2008/07/03(木) 05:28:30
電子カルテって3原則にそって作れば届け出とかいらんの
レセコンは社保とかに どのソフト使ってますって届けなきゃいかんけど
この辺の地域だけかな

63 :名無しさん@お腹いっぱい。:2008/07/03(木) 09:19:03
その心配する前に、物が出てこないことには

64 :名無しさん@お腹いっぱい。:2008/07/23(水) 19:37:27
某ファイリングソフトのサンプルデータを見た。
患者IDと思われる番号が名前になってるファイルに、
1年分の検査データがtab区切りテキストで入ってた。
1行目が検査日。
2行目以下は、1列目は検査名、2列目が基準値で、
以降がデータ。つまり、そのファイルをエクセルとかで
開けば、そのままその人の検査値のマトリックスですわ。
tableにはめ込めば、webで検査値の表を作るのも
簡単だわな。

別に他人と比較する必要も無い訳だし、ファイル形式で
管理するなら、手っ取り早い方法だよな・・・。
なんつーか、データベースの正規化とか考えるクセが
付いてたので、逆にシンプル過ぎてショックだわ。


65 :名無しさん@お腹いっぱい。:2008/07/23(水) 19:53:33
戯れ言ついでに。

検査値をリレーショナルデーターベースっぽく入れるなら、
患者ID>>検査依頼ID>>検査項目ID
って感じで繋ぐのが真っ当かな?と思っていたのだ。
一人の患者に対して、検査日は不定数だし、さらに
その回毎の検査項目はまちまちなので。
ただそうすると・・・一人の患者に対して、検査依頼が
年に4回で、一回の検査で20項目検査したら、
検査項目はそれだけで80個も個別に格納される。
これを、表示の度にマトリックスに組み上げるのは、
大変だなーと思ってた。

検査値を見る立場からすると、1回の検査依頼の
検査項目を個別にする意味は、無い。
だから、1回の検査依頼の分については、カンマ
区切りテキストなどで、まとめて放り込んでも
いいのかなーとも思ってた。
リレーショナルデーターベースとしては美しく無いけど。


66 :名無しさん@お腹いっぱい。:2008/07/24(木) 00:34:12
時系列で見ることの方が多いと思うよ

67 :名無しさん@お腹いっぱい。:2008/07/24(木) 01:38:21
その通りなんだけど。
でも、検査項目ごとに時系列で(タブ区切りとかで)
データを持っていたとしても、他の検査との兼合いがあり、
表にするのは、結構面倒。すると、某ファイリングソフト
みたいに、一つの巨大なテキストにしちゃった方が、
いいって事になる。なんとなく、美しくない気がするけど。


68 :名無しさん@お腹いっぱい。:2008/07/24(木) 09:04:46
わかります

69 :名無しさん@お腹いっぱい。:2008/07/24(木) 09:32:52
>一つの巨大なテキストにしちゃった方が、

だから医療系ではMUMPSのようなツリー構造のデータベースが
生き残ってるだね。

70 :名無しさん@お腹いっぱい。:2008/07/24(木) 11:46:10
MUMPS!昔習ったな〜。
もうすっかり忘れちまったよ。

つーことは。「理想的には」
RDBとXMLが混在できるDBを使えばいいが。
そんなの、大袈裟過ぎるので。

スキーマが決まってる所はRDBで組んで、
検査データとかはXMLでTEXTフィールドに
ぶち込むのが現実的かな。

ま、XMLである必要さえなさそうで、
それこそタブ区切りテキストでも
いいわけだが。

CakePHPのHTMLヘルパーを使うなら、
さくっと配列に入る形式が楽かな。

71 :名無しさん@お腹いっぱい。:2008/07/25(金) 17:14:06
なかなか画期的ですね・・・。

72 :名無しさん@お腹いっぱい。:2008/07/25(金) 18:06:00
画期的っつーより原始的?
DB使う意味さえなさげ

73 :名無しさん@お腹いっぱい。:2008/07/31(木) 17:41:26
DB作るだけじゃダメなのねん

74 :名無しさん@お腹いっぱい。:2008/08/01(金) 01:28:40
検査結果を見れるつーことはどっかの検査システムと接続するわけ?

75 :名無しさん@お腹いっぱい。:2008/08/01(金) 11:05:39
某ファイリングソフトの形式を参考にすれば良いのでは?

76 :名無しさん@お腹いっぱい。:2008/08/16(土) 22:43:15
おぉ、すばらしいProjectです。
期待してます!!

77 :名無しさん@お腹いっぱい。:2008/09/19(金) 14:20:45
どうなりましたかな?

78 : ◆jG/Re6aTC. :2008/09/23(火) 23:14:44
自分もフリーで使えるレセの開発を考えてます。
きっかけは、ORCAを触る機会があって、少しいじって、全体的にだいぶ古いインタフェイスかなぁと思って。
サーバー側もCOBOLで構築されてることやLinuxなど気軽に導入・運営するのに苦心しそうだと軽いカルチャーショックを受けたので。

サーバーサイドはJavaで、クライアントはFlexを考えてます。
ただ、医療系のシステム開発は未経験で専門知識も弱いため、時間が相当かかりそう。
仕様策定にアドバイス(といって良いのかな?)してくれそうな方がいらっしゃるコミュニティはココもふくめ、どのへんに首つっこめば良いですかね?


79 :名無しさん@お腹いっぱい。:2008/09/24(水) 06:56:52
>>78
素朴な疑問。
「レセ」の開発で、何故、「サーバーとクライアント」が必要なの?


80 :名無しさん@お腹いっぱい。:2008/09/24(水) 19:27:26
>>79
ORCAがそうだからじゃね?
っつーかレセというより電子レセプトシステムのことジャマイカン

81 :名無しさん@お腹いっぱい。:2008/09/24(水) 22:16:10
色んな回答方法があるわけで。回答によって>78の考えが分かる。

82 : ◆jG/Re6aTC. :2008/09/24(水) 23:15:21
こんばんは。
>>79
んー、まだ漠然と考えてるだけ&色々調査してる段階なので、
最終的にどういう構成になるかってのは決めてません。
ただ今までWebアプリの開発をずっとやってきたのでそう書いたまででした。
ひょっとしてスレ違いかな。

83 :名無しさん@お腹いっぱい。:2008/09/24(水) 23:26:31
>>79
ORCAってことだからレセコンなんじゃないの?
拡張性もたせるならクラサバでしょう

>>82
でも、レセコンを個人で開発するのは相当気合が必要かな
しょっちゅうある改定とかやってられないよ



84 :名無しさん@お腹いっぱい。:2008/09/25(木) 02:14:04
>>82
そうか・・・まだ、その程度か。

じゃあ、解答例。

ORCAを見てサーバー&クライアントだと思ったのなら、見識が狭過ぎる。
診療所のレセコンなら窓口に一台あればいいので、Windows用とかのスタンドアローン
(のアプリ)の方がインストールも簡単で、特にアンチORCAの人達に望まれている。
一方、電子カルテなら、診療所でも診察室と窓口にそれぞれ1台ずつ(以上)端末が
必要なので、サーバー&クライアントの形式の方が拡張性があって好ましい。

つまり、レセコンか?電子カルテか?ターゲットをどちらにするかで大違い。

だけど。これからの時代は、電子カルテでしょー。

85 :名無しさん@お腹いっぱい。:2008/09/25(木) 09:25:41
ひどく上目線な回答例だな
はははー、僕のいうことだけきーてりゃいーんだよみたいなw

86 : ◆jG/Re6aTC. :2008/09/26(金) 00:16:56
>>83
ありがとうございます。ORCAのボリュームと更新頻度をみれば大変そうだというのは伝わってきます。
>>84
アドバイスありがとうございます。
ハードウェアのC/Sというよりはソフトウェアモデルでのサーバー側/クライアント側ととらえてもらえたら良いと思います。
ともあれ数日で作り上げられる代物ではないことは解ってますから、色々と勉強しつつやってみたいとは思います。



87 :名無しさん@お腹いっぱい。:2008/09/26(金) 22:31:25
スタンドアロンにするメリットなんて全くないしクラサバでOKでしょ。
まずは好きにユーザインタフェース作ってみては?
基本的にはマウスなしでも使えないと、相手にされないと思うよ
マウスを使うなら、それなりのメリットをどれだけ見出せるか・・・

88 :名無しさん@お腹いっぱい。:2008/09/26(金) 23:53:06
>>87
スタンドアロンにするメリット:インストールが簡単

89 : ◆jG/Re6aTC. :2008/09/27(土) 00:18:51
>>87
ありがとうございます。
マウスオペレーション無しのインタフェイスですか、なかなかに難しそうですね(苦笑
がんばってみます

>>88
C/Sもインストール用のスクリプトをきちんと書けば簡単ですよ。
MacOS X ですとMAMPはApplicationディレクトリに配置するだけで
指定ポートでApacheやMySQLを稼働させることができます。

インストールが簡単であることとは導入敷居が低いことを意味しますが、
ORCAはその点をマニュアルの丁寧さでカバーしてるのは高く評価してます。



90 :名無しさん@お腹いっぱい。:2008/09/27(土) 00:50:08
ORCAのインストールマニュアルは秀逸だ・・・そう思ってた時期が私にもありました

91 :名無しさん@お腹いっぱい。:2008/10/07(火) 20:23:36
電子レセプト作って今月から提出しまっせ。

92 :名無しさん@お腹いっぱい。:2008/10/08(水) 01:21:40
kwsk

93 :名無しさん@お腹いっぱい。:2008/10/08(水) 13:15:38
桐でれせこん、やってますた。
なんとなく時期がきたのでレセプト、電算化しますた

94 :名無しさん@お腹いっぱい。:2008/10/21(火) 00:38:21
なんでこの板にこういうの詳しい人が集まるんだ?w

95 :名無しさん@お腹いっぱい。:2008/10/22(水) 17:57:41
キモヲタの巣窟だからじゃね

96 :名無しさん@お腹いっぱい。:2008/10/25(土) 22:14:34
あ〜あ…。
俺、中規模病院のフル電子カルテ1人で担当してんだけど、いいかげん疲れた…。
心臓に悪いョ。
と愚痴ってみた。

97 :名無しさん@お腹いっぱい。:2008/10/25(土) 22:54:04
>>96
それは「電子カルテ」のみ?
レセコン機能もあり?
一人で作った物?

98 :名無しさん@お腹いっぱい。:2008/10/26(日) 02:55:28
電子カルテ、オーダリング、医事会計、PACS、検査その他全領域。
パッケージだけどサ…。

99 :名無しさん@お腹いっぱい。:2008/10/27(月) 23:56:25
たんなる電算担当でしょ
場違い

100 :名無しさん@お腹いっぱい。:2008/10/29(水) 00:09:00
担当してみないと、運用の難しさは解らないよ。
システム作って、後の地味な運用はよろしくってこと?

101 :名無しさん@お腹いっぱい。:2008/10/29(水) 00:17:17
それで、日々の業務と、請求も出来てるんでしょ?
だったら、大したもんだと思うよ。

102 :名無しさん@お腹いっぱい。:2008/10/29(水) 18:44:20
面白そうなモノ作ってますね
陰から応援してます

103 :名無しさん@お腹いっぱい。:2008/10/29(水) 23:20:36
ありがとうございます。自分は褒められて伸びる性格ですのでどんどん期待寄せてくだしぁ

104 :名無しさん@お腹いっぱい。:2008/10/30(木) 05:04:28
>>96
やっぱりたんなる電算担当。
場違い

運用を簡単にできるコードでも書いたらどうじゃ

105 :名無しさん@お腹いっぱい。:2008/11/01(土) 15:12:03
医療関連の知識を勉強中の初心者ですけど、
Airでインタフェイスから作ってみたいと思ってます
まずは患者の登録と管理から…
やっぱマウスオペレーションメインって嫌われがちですか?

106 :名無しさん@お腹いっぱい。:2008/11/01(土) 18:42:19
ORCAはテンキー操作で『オフコンっぽい』って批難されてるがな。

ところで、Airの開発環境って無料なんけ?
というより、実行環境って無料なんけ?

107 :106:2008/11/01(土) 20:05:15
FlexBuilder3という有料ツールがありますけど、
オープンソースの開発環境もあります(SDKは無料です)。実行環境も無料です。
バックエンド側はJava、PHP、Rubyなど選べます。

108 :名無しさん@お腹いっぱい。:2008/11/01(土) 20:32:27
マウスオペレーションも微妙なんだよ
馴れない間は取っ付き易くて評判良いけど
慣れてくるとマウス操作が面倒だと言われる

オフコンっぽい操作もできる余地は有ったほうが良いよね?

109 :106:2008/11/01(土) 20:43:21
参考になります。ありがとうございます。
WindowsやMacOS X の操作がキーボードで操作できるのと同じように、
双デバイスでの操作ができるよう検討してみます

110 :名無しさん@お腹いっぱい。:2008/11/01(土) 21:38:22
AirはUIだよね。

ちなみに、prototype.jsとかを直接叩いて
UIを作るのは流行らないのか?

111 :106:2008/11/01(土) 22:23:53
どうでしょう。Webブラウザ上でかっこいいインタフェイス作るぞ〜ってな時にゃ必須なJavaScriptライブラリだと思います
今回(UI)はAirといえもどもFlexとActionScriptでいくつもりです


112 :名無しさん@お腹いっぱい。:2008/11/01(土) 23:01:12
とりあえず、UI設計が基本だよ。
UI作って使用者の意見を聞き微調整をする。

UIが明確になればDB設計も自ずと見えてくる。

113 :106:2008/11/01(土) 23:34:30
ありがとうございます。106に書いた通り、レセプトや関連知識は
まだレベル2ぐらいの絶望的な状態だと思いますので
色々ご意見いただいてたたき上げて行ければと思ってます
ともあれ、ゆっくりやります(;´д`)

114 :TK ◆jG/Re6aTC. :2008/11/01(土) 23:45:17
うわ、106じゃないや、105だ(°ω°)
106の人すいません。トリップつけます

115 :名無しさん@お腹いっぱい。:2008/11/03(月) 09:02:15
ttp://karinto2.mine.nu/ulink/down/1225669687.png
画面のレイアウトは、こんな感じか?

どこの電子カルテも、大まかな配置は同じと思った。
でも、どのレセコンでも大なり小なりあって不満なのが、
操作の時に所見欄が見えなくなったり移動したりする事。
今日の所見がすべての源なんだから、隠すなっつーの。


116 :名無しさん@お腹いっぱい。:2008/11/03(月) 09:24:57
お、面白そうなスレだね。

個人的な意見だけど、やはりXML(MML)は無視出来ないと思うよ。
おいらは治験関係なんで、電子カルテに直接かかわりは”今の所”無いんだけど、

電子カルテ→EDCに直接読み込み→MMLでDB化→製薬会社から電子カルテにリモートアクセス

この流れが確立したら、治験もかなり進むと思ってます。
Flashは7からXMLとの互換性が高くなったしね。

応援します。がんばって。

117 :名無しさん@お腹いっぱい。:2008/11/03(月) 09:25:04
診察中も前回所見はもちろんだけど、過去数回分は一覧で見たいよなー
なんとか、紙カルテの利便性に追いつきたいものです

118 :TK ◆jG/Re6aTC. :2008/11/03(月) 23:22:06
>>115
参考になる画像ありがとうございます。所見欄のリッチテキストを扱えるようにするというところは良いですね、
AirでもRitchTextEditorというコンポーネントがあるので実現しやすいと思います。

>>116
ありがとうございます。電子カルテは未開拓な分野なのですが(レセもですけどw)、
他システムとのXML連携については、Air(ActionScript)でやるより、
連携するバックエンド側システムでやるつもりです。JavaやPHPであれば大きな問題は無いと思います。
ご指摘のように、技術論よりは流れをどう確立するかが問題…なのかな。

>>117
医療の現場に立ったことがないので、紙カルテの利便性をどう実現するかを肌で感じ取れれば良いのですが、
難しいと思いますので、色々とご意見いただければと思います。


えーと、恥ずかしいのですが、現時点での成果です。
ttp://karinto2.mine.nu/ulink/down/1225721444.png
ORCAを参考・評価してたので文言などがORCAっぽくなってますが、
AirをUIにするとこんな感じになって、タブコンポーネントやマルチウィンドウも可能になって、
サーバー側ロジックを経由して処理ができるんだよ、っていうのが解ってもらえればと思います。
今週末には患者管理(患者情報の登録、編集)の基本的なところのUIが出来ればと思ってます。

119 :名無しさん@お腹いっぱい。:2008/11/03(月) 23:25:55
>>116
「何を」書き出すのか分かれば、そんなに難しくないと思いますよ。

>>117
正直、一覧性で紙に勝るのは難しいと思う。スピードも損ないたくないし。

120 :名無しさん@お腹いっぱい。:2008/11/03(月) 23:39:53
>>118
綺麗だなww

でも、電子カルテなら、ORCAを参考にしちゃダメかも。
それに対象となる診療所(病院?)の規模も決めておかないと。
受付、診察室、検査室、リハ室、調剤室、それぞれで
見られる内容が違うわけだから・・・というヒント。

121 :名無しさん@お腹いっぱい。:2008/11/03(月) 23:56:40
マックは画面キレイだなぁ。

122 :名無しさん@お腹いっぱい。:2008/11/04(火) 00:13:34
>>119
いつも同じこと言われてますw
個人的な考えなんですが、放射線の検査画像みたいに、
狭量な参照データと詳細な実データで別ければ良いと常々考えてるんですよ。

診療の際にスグ見たいデータって、過去数回分じゃないですか
保存するデータ量を決めておけばDB圧迫にもならないし・・・

作るのが大変なのは骨身に凍みてますが、利便性を考えれば
これくらいの工夫は必要じゃないかと思っています。

>>118
本当にきれいだね、今後の画面が楽しみ

123 :名無しさん@お腹いっぱい。:2008/11/04(火) 09:27:38
>>122
カルテのデータなんて、テキスト中心ならどんなに書いても
データの量なんて知れてる。ただ件数だけは、再診の数だけ
どんどん増えていくから、1回の観覧でどこまでのインデックス
を用意するか?が肝。ページ開くたびに、初診からの全ての
インデックスを準備するのは、パフォーマンスが悪そう。

でも、紙のカルテって、どんなにページ数がたくさんあっても、
任意のページを「一瞬で」開けるんだよね。これに勝つのは
かなり難しい。
電子書籍も同じ理由で使い難いと思ってるので。

124 :名無しさん@お腹いっぱい。:2008/11/04(火) 09:42:00
途上でもいいから試してみたいな
どこかにアップしてほすぃ
マック専用?

125 :名無しさん@お腹いっぱい。:2008/11/04(火) 18:20:26
いろんなライブラリを使う事になるんだろうけど。
GPLはやめておいて欲しい。なんとなく。
MITの物でお願いします。できれば。

って、気にしすぎか?

126 :TK ◆jG/Re6aTC. :2008/11/04(火) 19:57:53
ううう、TKがタイホされちまったぜ、このプロダクトも名前替えようかな(;´д`)
122、123さんのご意見が参考になります。ORCAを評価してると電子レセってのは事務的なものだから
最低限の使い勝手あれば良いもんなのかなと思ってたんです
120さんのご意見にある通り、利用対象を決めないといけませんね、システム作りの基本からだ(汗
サーバ側はJavaを使おうと思っているのである程度の規模や負荷でも耐えうる作りはそう難しくないと
思ってます。ただ、そのぶん機能が複雑になってメンテできなくなるのも避けたいですから、まずは
入院が絡まない診療所をターゲットにという感じでしょうか。

もしご存じの方がいたら教えて欲しいのですが、診療所〜小規模な病院ですと、
年間の新規患者数、一ヶ月のレセプト数…ぐっと踏み込んで診療行為総件数など…はどれぐらいになるのでしょう。
ここを気にして設計するのは先のことなんですが以前から気になっていたので

127 :TK ◆jG/Re6aTC. :2008/11/04(火) 20:11:19
もう一件、幸か不幸か自分はレセコンはORCAしか評価してません(オープンソースだったので)。
ORCAも量が多いので全てを評価してるわけではないのですが。。
ググってみると他にもいくつかのレセコンがあるものの、有料なので簡単に手が出せそうもない感じです。
もし、お試し版なんてのをダウンロードできるソフトがあったらぜひ、と思います。

>>124
なーんにも出来ていないものでよければ、
ttp://tkrezept.jpn.org/tkrezept/TKRezept20081103.air.zip
Airなどインストールは自己責任でお願いします。明日ぐらいには削除したいです(w
(開発者へのメッセージは一応機能します)


>>125
微妙なところです(汗 ライセンス関連に強いくないので適当なことは言えないのですけど、
「利用者の手を極力煩わせないよう」最終的には諸々のリソースをパッケージ化して入れ替えるだけ
といった形態にしたいものです



128 :名無しさん@お腹いっぱい。:2008/11/04(火) 21:19:27
>>126
新規患者数なんて、ピンキリとしか言えないぜ。

それと、診療所関係でやっかいなのが、健康診断。
健康保険は効かないけど、健保が一部負担するとか、そのタイプ。
会社の健康診断なんてのは、小さな診療所では大きな利鞘なんで、
その扱いは無視できないと思う。

追加検査で、○○の項目だけは全額自己負担とか出ると頭破裂しそうになる。

まぁ、健康診断は治療では無いんで、完全に無視するってのも手かもね。

ちなみに診療所なんかだと、経年で受けてほしいんで、検診データをDB化して、
経年での変動を見られます!って売りにしてる所も多いよ。
ただ、会社によってはより安い病院で受けさせようと、毎年変える所もあるんだわ。

こればかりは、何とも言えないな。

129 :名無しさん@お腹いっぱい。:2008/11/04(火) 22:05:48
>>126
クリニックなんかだと、先生の知名度で患者数が天地ほど変わるからな。
知ってる単科病院の場合、外来200/日、初診80/日くらいが最高かな?

>>128
診療行為ごとに、どの保険を主にするのかフラグで持って置けば
自費が混在しても。それほど頭爆発させなくても計算できるよ。

保険も健康保険+(労災、自賠責)での同時併用も良くあるから
診療行為ごとに主保険を決めれないと使い物にならないしね。


130 :名無しさん@お腹いっぱい。:2008/11/04(火) 22:30:00
面白そうなスレ発見。
スレ主はレセを自作したいのか?
それとも電子カルテを自作?

131 :TK ◆jG/Re6aTC. :2008/11/04(火) 23:42:46
>>128-129
ありがとうございます。参考になります。
健康診断は盲点でした、というか先日自分も健康診断受の結果送られてきて尿に潜血反応があってちょっと驚いてたり(汗
健康診断を含め点数や自己負担などのパターンを全て網羅するのも無理だと思うので(しかも毎年変わるものでしょうし)、
どうやって汎用的にするかで悩みそうな気がします

>>130
自分は>>1では無いのですけど、レセ自作を目指してます。何かと難しいことは承知してるつもりです
最終的には電子カルテも視野に入れたいのですが、あれこれ手を出して自爆する最悪のシナリオは避けたいので
まずは最低限の所から、、です。



132 :名無しさん@お腹いっぱい。:2008/11/05(水) 08:09:54
今はタイミング悪いかな

133 :名無しさん@お腹いっぱい。:2008/11/05(水) 08:34:43
>>132
紙提出にも対応しないといけないから?

私は逆の意見。
オンラインで、みんな一旦ORCAを使い始めたら、
移行が面倒で、なかなか他には移らないと思う。
だから、ORCAを使い始める前に食い込むべきかと。

134 :sage:2008/11/05(水) 09:06:29
いやTKが逮捕されたからじゃねw

135 :名無しさん@お腹いっぱい。:2008/11/05(水) 09:09:36
なるほど

136 :名無しさん@お腹いっぱい。:2008/11/05(水) 09:40:10
いきなりハードルを上げるようで申し訳ないが、
レセ作るなら、まずはレセ電算のファイルを見る
ソフトから作ってみてはどうか。
ORCAのおまけで、そういうソフトがあるので、
見たことあるかもしれんけど。意外と大変そう。

137 :名無しさん@お腹いっぱい。:2008/11/05(水) 12:10:03
WinORCA PLUS 見てたら、もうコレでいいんじゃね?とか思ったw
ORCA用のGUIを作ったら使ってくれる人が多そうだよ。

step1: 自家製GUI->ORCA
step2: 自家製GUI->改造ORCA
step3: 自家製GUI->自家製レセ
〜略〜
stepX: 電子カルテ実装

私個人の思いつきだけど・・・
1人(or 有志?)で開発するならコッチの方が楽?

138 :名無しさん@お腹いっぱい。:2008/11/05(水) 13:03:50
レセコンをどれだけ弄っても、電子カルテにはならんよ。


139 :名無しさん@お腹いっぱい。:2008/11/05(水) 13:45:40
>>138
レセコンやオーダリングの知識なしに電子カルテ作るのは無理だろ?

140 :名無しさん@お腹いっぱい。:2008/11/05(水) 14:20:51
あった方が良い。
でも、電子カルテ→ORCAへCLAIM接続って方法もある
と思うので、必ずしも電カルに内蔵する必要はない。
ま、CLAIMと保険請求のどっちが複雑か?ってのも問題か。


141 :TK ◆jG/Re6aTC. :2008/11/05(水) 19:32:58
>>136-137
アドバイスありがとうございます。ビューワからこしらえるのもアリかもしれませんが、
今のところ、レセを作ると決めたので(w
ORCAのGUIも考えたのですが、すでにORCA-PLUSやMacOS X 向けクライアントがある以上、
あまり意味が無いのかなと感じてます。ORCAの実装量は素晴らしいものがあると思っていますが、
導入や拡張開発時の敷居を下げたい意図もあることと、自分で実装して理解を深めたいというのもあります。

142 :名無しさん@お腹いっぱい。:2008/11/05(水) 19:40:35
>>141
>MacOS X 向けクライアント
そんなの、あんの?

143 :TK ◆jG/Re6aTC. :2008/11/05(水) 19:53:15
>>142
http://www.extem.com/maclientproduct.html

144 :名無しさん@お腹いっぱい。:2008/11/05(水) 21:32:09
>>143
へー。内容は同じでも、Macってだけで綺麗だなww

145 :名無しさん@お腹いっぱい。:2008/11/05(水) 22:48:41
TKRezeptとやらをWindowsXPで動かしてみた.
.airっていう拡張子わからなくてさまよった.
>>118のキャプチャが綺麗すぎてWindowsXP版が汚すぎテラワロス
開発者へメッセージ送ってみたが届いてる?おすぎって名前で送った

146 :名無しさん@お腹いっぱい。:2008/11/06(木) 13:04:22
印刷どうするのかな?
Excelで作ったテンプレートに診療行為データを自動でセットしてくれる機能とかあると嬉しいw

147 :名無しさん@お腹いっぱい。:2008/11/06(木) 14:17:08
xml書き出しが欲しい

148 :TK ◆jG/Re6aTC. :2008/11/07(金) 20:09:58
>>145
とどいてます、ありがとうございます。
>>146
PDFをサーバー側で生成して表示・・・ってのを考えてます。
Excelテンプレ方式は、生成後に改ざんが容易になってしまいますが、運用としてありなんですかね?
>>147
技術的には可能ですけど、どういった時につかうのでしょう


いろいろ検索などして患者登録画面を考えているのですが、
公費入力って固定なんですかね?レセプトとして固定されてるものなんでしょうか。

入力要素数が多いと、なんでもかんでも画面に詰め込んでみづらくなりますし、
逆にボタンやタブなどで分けてしまうと入力しづらい…なんていうことにならぬかと。
難しいな…

149 :TK ◆jG/Re6aTC. :2008/11/07(金) 20:11:16
訂正デス:公費入力って固定→公費の入力件数です。あるレセコンのキャプチャをみると2件固定になっていたので…

150 :名無しさん@お腹いっぱい。:2008/11/07(金) 20:27:30
>>148
俺もXMLアウトプットが欲しい。
XMLは世界標準のスキーマと言っても過言ではないかと。

実務で何に使うの?って言われたら、
excelで開いてチェックする。って答える。

151 :名無しさん@お腹いっぱい。:2008/11/07(金) 22:50:30
>>148
現状では、PDF生成が良いと思う。
プリンタの制御はヤヤコシイ

レセなんて、改ざんされてもカンケイナイ
電子カルテは改ざんできたらダメよ

公費は、レセだけなら2つで充分じゃない?
電子カルテの場合は・・・履歴として
残せる方がいいのかもしらん

152 :名無しさん@お腹いっぱい。:2008/11/07(金) 22:55:51
紙でレセを見るのは慣れてるから、
ディスプレーで見るのよりも良いように思ってるけど。
改めてレセの用紙を見ると、カオスだよ。
病名がたくさんだと、摘要欄に続いてくなんて。
画面に
病名|点数|摘要欄
の3ペインで表示される方が便利だと思う。


153 :名無しさん@お腹いっぱい。:2008/11/11(火) 04:07:21
厚労省のマスター、あほほどにカラムがあるな。
以前Delphiで読込むソフトを作った時は、必要そうなカラムを
選別して読込んでみたんだが。今回はCSVをまるっとdbに
読込む事にした。カラム名は適当な連番。これなら楽だ。

こんな無手順の登録でも、すんげー時間がかかる。
ましてや、差分を調べてupdateするとなると・・・
(((( ;゜Д゜)))ガクガクブルブル

154 :名無しさん@お腹いっぱい。:2008/11/11(火) 21:30:28
絡むのほとんどはカス。功労賞が安全パイにとっていると思われ。
重要な絡むの数はぜいぜいが5個か6個辺り。

155 :名無しさん@お腹いっぱい。:2008/11/11(火) 22:29:58
んだ。
だが、下手に修正して、マスター提出しろって言われた時に
面倒だとイヤだし。VIEW作っちまえばいいんだし。
エロ動画でも1つ数十メガの時代に、マスターの数メガなんて
ディスクスペースとしては屁でも無い。

156 :縊死貝:2008/11/12(水) 23:48:36
レセコンはどこのメーカのシステムで、
どこの販売店がよいですか?

157 :TK ◆jG/Re6aTC. :2008/11/16(日) 23:18:58
ぅぅぅ、年末デスマに突入っぽい.今日も地下にもぐってたorz
誰か私に自由に開発できるぐらい投資しておくれw


158 :名無しさん@お腹いっぱい。:2008/11/18(火) 00:56:08
自慢げにデスマの話するのはやめろ。
自分に管理能力が無い、もしくは上司に管理能力が無い事を他人に話して何の得になる?
バカにされるだけで気分悪いだろ。



159 :TK ◆jG/Re6aTC. :2008/11/18(火) 06:55:45
自慢してるつもりはさらさらないんですがね、わかりました、余計な話はしません。

160 :名無しさん@お腹いっぱい。:2008/11/18(火) 08:32:34
デスマの話は興味ないけど。

>自由に開発できるぐらい投資しておくれ

この言葉、何気に重大な意味があると思うんだな。

レセコンは作って終り・・・じゃない。
診療報酬の改定に追随する必要がある。
情報が出てから実施までは非常に短くて、
それこそデスマになる。そういう開発まで
フリーで成り立つか??という問題。

161 :名無しさん@お腹いっぱい。:2008/11/18(火) 10:04:28
レセコンギョーシャ乙
オレも夜勤明けだ文句あっかw
みんな大変なんだよ


162 :名無しさん@お腹いっぱい。:2008/11/18(火) 10:19:48
業者じゃねーよww

改定対応も含めて、維持するなら、
ユーザー数はどれくらいで、年間いくらで、
開発が何人雇えるか・・・とかまで考える
必要があるのかなーと思ったり。


163 :名無しさん@お腹いっぱい。:2008/11/18(火) 11:30:25
データだけORCAから拝借。

164 :名無しさん@お腹いっぱい。:2008/11/18(火) 20:22:06
>情報が出てから実施までは非常に短くて

短くたってほとんど関係なし。ホントにアルゴリズムで頭使ったの、ここ15年間で一回だけ。

165 :名無しさん@お腹いっぱい。:2008/11/18(火) 21:34:47
改訂があるのは確実なんだから、基幹システム作ってパッチ当てるスタイルにすりゃ良いんでない?
俺はレセプトとか携わった事ないけど、計算式が変わる程度の変更でプログラム組み換えなんてありえないぜ。

最初にがんばって、あとは保守費用でのんびり。

166 :名無しさん@お腹いっぱい。:2008/12/03(水) 23:29:33
あると思います

167 :名無しさん@お腹いっぱい。:2008/12/04(木) 01:49:33
レセコンシステムは構築意欲がわかない。
一部の机上で診療報酬を策定される方の道具を作るなんて
商売以前にやる気がおきない。
法改正?崩壊せぇ!

168 :名無しさん@お腹いっぱい。:2008/12/06(土) 23:34:18
どうも今度開業予定の者です。
自分も、約一年かけて電カル&レセコン相当研究しました。
きっかけは先輩勤務医からの『ファイルメーカープロで電子カルテ自作している先生がいるよ』のひとこと。
自分もVB、C#、java位は多少かじったことがあるので挑戦しようと思いました。

VBもつかえるデーターベースソフトということでアクセス。
アクセス+電子カルテ もいっちょおまけに ORCAとの連携ということで
中山先生のサイトにたどりつく
ttp://www5f.biglobe.ne.jp/~nakayamahiroo/

いやいや、アクセス=ダイナミクスですよ というコアな方もおられると思うので
吉原先生のサイトもどうぞ
ttp://www7a.biglobe.ne.jp/~dynamics/

いえいえ、もっと綺麗でMACでもつかえてついでにjavaでもちろんORCAと連携という夢の電カルテはこれ。
ttp://opendolphin.blogspot.com/


以上、もし細々と診療所やるなら
OpenDolphin + ORCAの組み合わせが最高だと思いました。

しかし、もし、もしですよ自分のクリニックの総売上が相当以上あったとしたら、こんなことに経費ケチってなんのメリットがあるのか、そう考えました。
しかもシステムダウンしたら自分が徹夜で復旧作業をしなくてはならない。
翌日は100人以上の患者が待っているかもしれない。
あるいは、そのような事態に対応してくれる業者さんはたしかにいるかもしれない。
しかし、OpenDolphin + ORCAの維持のために月10万円近く払いつづけなければならないのは金額的メリットが薄れてしまう。
しかも、かなりの零細業者さん(失礼)で10年ご20年後はつぶれているかもしれない・・・・

プログラム的にも絶対の命題は持続可能な鉄壁のシステム。
鉄壁なというのは、プログラム作ったことがあるひとなら、素人レベルには不可能なはなし。
ましてや、トライアンドエラーで実際の患者さんに適用するのは怖すぎる。
持続可能というのは、Windows等OSがコロコロ変わるときどう対応するのかが重要。
LINUX?ORCAだって医師会が億単位の金出して維持しているからある程度保障されているようなもので、個人では不可能。


結局大手メーカーにしました。
結論は趣味と実益は両立しない、トホホ。
いまでも自宅にサーバー組んだORCAがデモ用としてカタカタ動いてます。悲しいな。クワッドORCAシステムつくりたかったなぁ。


169 :名無しさん@お腹いっぱい。:2008/12/07(日) 07:43:54
作るだけなら作れるけど、保証の問題が個人や中小レベルだと無理なんだよね。
デスマで乗り切れるとか、そう言う話でも無いからなぁ。


170 :名無しさん@お腹いっぱい。:2008/12/22(月) 03:18:58
デスマでいけ

171 : 【大吉】 【714円】 :2009/01/01(木) 00:50:36
あけおめ、ことよろ。今年こそはっ!

172 :名無しさん@お腹いっぱい。:2009/01/06(火) 01:12:45
LAMP亭とか

173 :名無しさん@お腹いっぱい。:2009/01/10(土) 01:16:27
>>167

同意。
だが、それを承知で新規に作成しようとしているんだから生暖かい目でいやらしく見守ろうぜ



174 :名無しさん@お腹いっぱい。:2009/01/10(土) 05:06:07
いやらしくですか:::

175 :名無しさん@お腹いっぱい。:2009/01/22(木) 00:02:02
おう

47 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)