ueno-t 曰く、 "ITProより。「日本医師会がLinuxベースに診療報酬明細計算システム ORCA(仮称）のソフトウエアをオープン・ソース・ソフトウエアとして2002年1月に公開 すると発表した」。ゆくゆくは全国ネットで展開したいとの事。無償。詳しい背景とか知らないけど、応援したい感じですね。"診療報酬などのマスター・データについては改変不可とのことだが、この部分はそう簡単に変えられても困る。改変不可でも全然問題ないだろう。
日医主導というのは期待が持てるが... (スコア:3, 参考になる)
いっそXMLでの提出を受け付けてくれるようにするとか、どうしても紙ベースでなくてはならないのなら、全国で統一様式を作るとかしてくれればいいんですがねぇ。
あと、実際にレセコンを提供する業者側って、結構保守的な所が多いから、そういう所が乗ってくるかどうか...
Re:日医主導というのは期待が持てるが... (スコア:1)
Re:日医主導というのは期待が持てるが... (スコア:2)
トランザクションモニタとCOBOL? (スコア:2)
元オフコン屋のワシにもソソル＆使って見たいものがある。
これで業務アプリのフリーソフトが増えるかも。
結構凄いコンセプトかも (スコア:1)
その上 IPv6 ですって。これは、これで先見の明だと思うけど、導入のネックになったりして。
この企画考えた人ってかなり、世の中流れ分かってますね。
この手のシステム作って売ってるメーカの反応の方が気になります。全部オープンソースにしちゃったりして…。
裏話 (スコア:2, 興味深い)
某メーカでは、「誰がやっているか調べろ」と、全国の支店に命令を出したそうです。もうあの手この手で調査されました。幸いにして、記者会見の時までは、バレずに済みましたけどね。
かなりマジに、「闇夜は一人で歩くな」と言われてます。レセコンのASPとかネットワークとか、提案しているメーカは多数ありましたから。
しかし、Linuxがボトルネックかも？ (スコア:1)
導入から管理運営まで面倒見る商売が成り立ちそうですね。
誰か起業しませんか？;-)
サポート費用を出してくれるか? (スコア:3, 興味深い)
ちょっと前に今回よりは大きめの(大学病院クラスの)レセプトシステムの監査を行ったことがありますが, その少ない経験から見ても問題が多そうに見受けられます. 売りっぱなしというのではなく, ある程度良心的なサポートをするつもりで作業項目を洗い出してみると,
システムのサイジング
大まかにはベッド数で見積もれるとは思うのですが, 病院毎の運営方針(例えば外来受付が午前のみか通日か等)によっても影響されますので簡単にはいかないと思います. これを解決するためにはシステム事例のデータベース化が必要でしょう.
システム構成設計
このシステムがどの程度の規模までを想定しているのか分からないのですが, 通常レセプトシステムはIO性能依存が高いので, データベースのディスク配置設計が性能に大きく影響してきます. これについてもサイジングと同様の事例の蓄積が必要です.
システム運用コンサル
データのバックアップ等は病院システムでは最も軽視されている作業です(RAIDでもバックアップは必要だよ!). このあたりを病院側の体制に合わせて(場合によってはテープチェンジャの導入なども含めて)コンサル/システム設定することは必須です.
セキュリティ教育
経験的に最も困難なのがセキュリティ教育です. 医療の現場の作業者レベルで良いパスワードを設定するように強制することは, ほぼ不可能ではないかと思われます. ネットワーク内の全クライアントをシステム部で管理し, サーバへの接続を全て制御するようなシステムも有りますが, 多くはネットワークを外部から隔離することでセキュリティをなんとか確保している状態です. IPv6でカルテ情報を共有というのは技術的には面白いし, 便利ではありますが, 現実問題として最も厳重に管理されなければならない個人情報を流通させるインフラとしては, あまりにもお粗末すぎるでしょう.
ざっと作業項目を挙げてはみましたが, これだけのことをやった場合どの程度の費用がかかるか, ちょっとすぐには分かりません. 少なくともハードとは別にサポート費をもらわないとやっていけないのは確実でしょう. でもソフト自体はタダだとゴネられそうな気もしますし, あまり商売としてはおいしくなさそうです.
青いな (スコア:2)
ソフト技術者/企業にとって当たり前のことでも, それが相手にとって当たり前であるとは限りません. 説得するだけ無駄に終わることも決して少なくありません. 特に日本の病院というのは一部の先進的な所を除いて, 旧来の薬品メーカからのサポートと同等の物を情報部門についても求める傾向が強くあります. こういった所に対して純ソフト的なサービスを行う業者ができる対策は, 今のところ「相手にしない」ということだけです.
幸いにして, この不況の世の中でもソフト技術者/企業だけは食っていけることができていますから, いまの段階で自身に不利になることはやらなくても良いというのが私の考えです.
Re:しかし、Linuxがボトルネックかも？ (スコア:2)
今のレセコンでも、医院で全て入力→出力するのではなく、医院からは紙のカルテを渡して、レセコン屋さんが全部入力／レセプト作成してる場合も結構あります。
レセコンに医院で入力する場合でもレセコンのシステム自体を病院側が弄る事はまずありません。（アプリケーションのオペレーションをするだけ）
システム弄ると面倒見てくれなくなりますから(^^;
なので、レセコン屋さんがLinuxを受け入れてくれさえすれば、医院側がLinuxだからいやがるという事はあまり無いでしょう。
むしろ、お医者さんって新らしものズキな人が多いから(^^;、医者は「このシステムにしたい」って言ってもレセコン屋さんが拒否するという可能性が高そうな予感...
Re:しかし、Linuxがボトルネックかも？ (スコア:1)
しかし、レセコンって確か専用マシンですよね。というわけで、レセコン屋さんがLinuxに精通してるとは思えないんですよ。
＃少なくとも私の知っている限りでは。
要するにhttp://itpro.nikkeibp.co.jp/free/NOS/NEWS/20010622/1/ [nikkeibp.co.jp] の
>寡占状態もなくなるだろう。オープン・ソースにすることで，
>これまで，参入してこれなかった，地域のソフトハウスや，
>ベンチャ企業もレセプト・コンピュータに参入できるようになる。
にあるように、↑のチャンスだから、誰かベンチャーしないですか？ということです。
今までレセコン屋さんに独占されていた市場が開放されるわけです。電子カルテ化の動きも活発になってきてますので、統合的なサービスを提供できれば顧客は見つかると思うんですが。商売成り立ちそうだと思いませんか？
Re:しかし、Linuxがボトルネックかも？ (スコア:2)
なので「ソフトはあるんだから安くなるだろう」と言われても、そううまく行くかどうかはわかんない所がありますね。
ITProのページにあるような50万とか150万ぐらいで出しちゃうとサービスが悪いって言われるかも...
本気でレセコン売るのなら、厚いサービス体制とか、人脈とか(^^;ソフト以外の多くのハードルをクリアする必要があります。
むしろ既存のレセコン屋さんがLinux使えるようになる方がハードルは低いでしょう。
ですから、既存レセコン屋さんの淘汰にはなるかもしれませんが、新規参入が増える（そして継続できる）かどうかは、不明ですね。
Re:しかし、Linuxがボトルネックかも？ (スコア:1)
そういえば，健康診断で行った病院の受付で xlogo のスクリーンセーバが動いてる端末を見て，のけぞったことがあります :-)
Re:しかし、Linuxがボトルネックかも？ (スコア:2, 興味深い)
病院経営は数年後の規制緩和を見越して，厳しいコスト削減とその上でのIT化を迫られているので，Linux + PCサーバーというのは必然と言っても過言でないほどだそうです。
Re:しかし、Linuxがボトルネックかも？ (スコア:1)
日医IT化宣言 (スコア:1)
日医IT化宣言 [med.or.jp]はすばらしいですね。今後開発するソフトウェアもすべてオープンソースとするそうです。
ただし、オープンソースの定義 [opensource.jp]によると、改変の禁止という制限があると、オープンソースではないということになっています。(改変禁止にしたかった理由もわからないでもないので、「どうしても改変したければパッチという形で配布せよ」というふうにすれば、データベースの信頼性を維持すると同時に大手を振ってオープンソースだと宣言できたのに、と少し残念です。)
いずれにせよ、会員15万人を超える団体 [med.or.jp]が、このような画期的な決定を下すことができるだけの柔軟性と意思決定能力を持ちえたというのはすばらしいことです。
オープンソースやバザール形式の利点は、学問におけるピアレビューに例えられたりしますが、学術団体がこういう決定をしてくれると、オープンソース陣営としては非常に嬉しいことだと思います。
Re:日医IT化宣言 (スコア:1)
ソースコードの改変禁止とは読めないのですが。
Re:日医IT化宣言 (スコア:1)
おっしゃるとおり、ソースコードは完全にオープンソースです。ただ、ORCA ページ [med.or.jp] によると、データベースもすべてオープンソースにすると言ってます。マスターデータもこのデータベースに含まれると考えると、間違ったことを言っていることになります。「オープンソースという言葉には万人が合意する厳密な定義はなく、Open Source Initiative が主張している定義もそのひとつにすぎない。われわれはオープンソースという言葉を～という意味で使っている」と言って逃げることもできますが。
でも、ここまで画期的なことをしてくれたんだから、あとほんのすこし、「マスターデータは、改変禁止なので、厳密にはオープンソースの定義に合致しません」というただし書きをつけるくらいのことはしてくれてもいいのになあ、と思います。
Re:日医IT化宣言 (スコア:1)
要するに、「データベースのオープンソース」というのが何を指しているのか、ということになると思うのですが、これは単純にデータベースのスキーマ定義のことではないでしょうか？
マスターデータは、いわゆるソースコードの範疇に含まれないと思うのですが。
# だから当の日医の文章もいまひとつ意図がわからん、というのには同意します。
Re:日医IT化宣言 (スコア:1)
どこまでがデータでどこまでがソース(ルーチン)か？ってのは
一概に言えなくなってきたりするわけですよね。
#「普通のヤツラの上を行け」でも、それに近い話があるようです
つまりその境界線はアーキテクチャ(の解釈(^^;)に依存する、という。
で、マスターデータのうち公開可能な分をソースと同列に呼ぶ、ってのは
場合とか分野とかによってはアリなような気がします。
もっともその解釈にOSDやRMSが付いて来れるかどうかは謎ですが(^^;
で、そこから先の話なのですが、なにせ命を預かるシステムとなれば、
データの改悪(?)を「ライセンスで」禁じるだけでは、はっきりいって足りないのではないでしょうか？
ライセンス云々と関係無く、そのデータ内容の妥当性をチェックする仕掛けが
なにかしら要る様に思います。逆にいえばそのチェックシステムがもし出来れば、
ライセンスとかの縛りを入れる意味があまり無い、というような
ものなんじゃないか、と素人なりに憶測(^^;しときます。
ActiveXとJavaAppletのセキュリティ仕掛けの話と似てるような気がする。
問題は銘柄じゃなくて実質だ、という。
Re:このプロジェクトについては、 (スコア:1)
いや、アーキテクチャ「の解釈」って言ったのが味噌でして(^^;、
OODBを実際に採用しなかったとしても、(R)DBのどこからどこまでをソースと呼ぶかは
当事者の裁量次第じゃないかな？と思ったものでして。
CreateTableしてから初期値を突っ込むところ「まで」のSQLをソースと呼ぶってのは
有っても悪くないと思うので。
>このプロジェクトについては、この心配も当たっていません。なぜなら、データへのアクセスを、「ライセンスで縛る」とは一言も言っていないからです。
俺も「改変を禁ずるなどのガード」という言葉には
(我々の慣れ親しんだArchitecture解釈と比べての)曖昧さを感じました。
が、「一言も言ってない」から「心配には当たらない」というのは変で、
「違うやり方をする」と具体的にはっきりした時点ではじめて「心配の必要がなくなる」のでは？
現時点では「どっちか判らん」のが「心配」である、ということです。
>書込み禁止措置
思うにそれでもヌルイのでは。ライトプロテクト(どんな技術形態にせよ)を
覆したり詐称したりすることは、ある意味で容易なので。
一時配布物との同値性チェックとかが必要だと思う。改変がバレる仕掛けが。
#あれを書きこみ禁止と呼ぶんでしょうか最近は？
>だと思われます。
その希望的観測どおりになっていることを、俺も「期待します」。
「思う」ってのとはちょっと違います。期待通りの実装をしてると「思う」だけじゃ何にもならないので。
書き込み禁止措置 (スコア:1)
ライセンスによる縛りじゃなければ、ソフトウェア的なチェック機構だと 考えられます。もしそういうのがあったとすれば、 データベースに誤った修正を (過失で) 入れてしまう可能性を排除できます。
しかし、そのソフトウェア的なチェック機構 (「ガード」) もまたソフトウェアでありオープンソースで改変が自由なのなら、 故意にデータベースおよびそのチェック機構を改変するのを防ぐことはできません。
ライセンスによる縛りと、チェック機構とで、どちらのほうがより有効か、 という議論は、有効性の意味が違うので、意味をなしません。 チェック機構は、ついうっかりという事故を防ぐには、ライセンスよりも 有効ですが、チェック機構も含めてうっかりという事故を防ぐことはできませんし、 故意の改変を防ぎたい場合はまったく無力です。 一方、ライセンスは、ついうっかりという事故は全く防げませんし、 法的ペナルティをも辞さないつもり (あるいは逃げ切るつもり) で悪意ある改竄をされることを事前に防ぐ手立てにはなりません。 しかし普通の意味で改変してはならない、という意思表示をするのに、 ライセンスは最も適切だと思います。
どちらにせよ、もしそのようなチェック機構のことを言っているのだとしたら、 IT 化宣言でライセンスやオープンソースの話をしているところにこういう話題を持ってくる のは場違いな気がします。つまり、これはライセンスによる縛りのことを 言っているのだと解釈するのが自然に思えます。
Philosophy problems.... (スコア:1)
特に、GPL BasedなライセンスでCobol処理言語から(マスターデータを除く)処理系まで配布してしまうと言うのは非常な英断だと思います。
と同時に、このライセンスは、GPLの弱点…勝手に改変すると社会的な影響が大き過ぎる物への扱い方が視野から欠落していた…があぶり出されていると言う点で非常に興味を持ちました。
ソースコードを"FREE"にすると言う事は、勿論データも"FREE"になる事が避けられない訳ですが、しかし、医療報酬なんかの場合には下手に"FREE"にすると社会的な混乱を起こす事になってしまうし、
処理系についても下手な物を仕込まれた場合の危険性(例えば特定の治療や薬剤の点数計算に細工をされた物が、気づかぬ内に標準になってしまう危険性とか)もある訳です。
そういう「危険性」とGPL的な考え方が向き合う事になる事で、この「英断」は、社会的な実験となり得るのではないか。そんな風に考えるのですが、どうでしょうかね？
Re:Philosophy problems.... (スコア:1)
>ソースコードを"FREE"にすると言う事は、勿論データも"FREE"になる事が避けられない訳ですが
それ変な解釈じゃないですか？
もしそれが真なら、暗号ソフトや所謂Officeソフトは
FREEなものが今よりずっと流行りにくかったのではないかと。
余談：
またまたスラド大きなお世話だな。プレビュー必須だと？
ただでさえ遅くて不愉快なスラドのアクセスが、
更に遅くなって、どうしようってんだか？
「問題」を勘違いしているんじゃないか？
Re:Philosophy problems.... (スコア:1)
あ、少し言葉不足でしたね。
ソースコードがFREEならば、データをいくらClosedにしていても、Hackした成果でデータ自体も構造がOpen(FREE)になってしまう訳です。
確かに公開鍵暗号のような数学的に非常に難しい場合は、データも簡単にはOpenに出来ませんし、改変も困難ですが(とはいえ、旧いVersionのGNUPGの様に穴はある)、全く出来ない訳ではない。
ましてや、今回添付される診療報酬レコードなんかは、データ構造が簡単に解読できる訳ですから、幾らライセンスで縛りを入れても、Hack(と言うよりもCrack)されて改変された物がまかれるのは必然だし、プログラム自体に仕込まれる可能性も十分にある。
そういう場合、社会とGPLとの間で一種のモラルみたいな物の衝突が起きるのではないかと言う事を危惧すると同時に「社会的実験」として期待した訳です。
Re:Philosophy problems.... (スコア:1)
データ構造がオープンであっても，データ自体の秘密が守れればいいのではないか，とは思いますが，どうなんでしょ． PGP で暗号化したメイルはこれに当てはまりますね． つまり，ソースを読んで「プライバシーに関わるレコードを保持している」ということが周知されることと「プライバシーに関わるレコードの内容が外部に洩れる」というのは別の話ではないかな，と．
暗号とそのアルゴリズムのオープン化，という話については，暗号研究者の間では「closed な暗号，closed ということでセキュリティを確保している」という暗号は，マトモなものとはみなされていないそうです． 「その暗号について議論できないから」というのもあると思いますが，アルゴリズムが公開されていてなおかつセキュリティが確保できる，というのがホンモノ，らしい．
あと，「まがいもの」については，確かに問題ありますね． バックドアやトロイの木馬なんか仕込まれた偽物が出回ったら大変ですね． いくらソースが公開されている，とはいっても，精巧に組み込まれていたとしたら，ソースを読んで見破るのは困難かもしれません．
が，それこそ「電子署名」とかと組み合わせればある程度は解決できるのではないかな，とは思います． ソース（もしくはパッケージ）に対して開発者が電子署名する，と． ま，この場合は開発者を信用できないと意味がないわけですが．
Re:Philosophy problems.... (スコア:1)
実にこの辺が苦労したことで、「GPLの日本語版」にしようとしながら、そうなり切らなかったんです。やはり「日本医師会」と名の下に公開するわけなので、「無保証」を言い切るのは難しかろうと。だから、オープンソースと言いながら、かなり縛りのあるライセンスになってしまっています。内部ではGPLで公開とゆー話で動いてたのですけどね。
TPモニタやCOBOL処理系あたりは、GPLなのですが。
Re:Philosophy problems.... (スコア:1)
関係者のようですので、すこし意見を。
まず、「オープンソース」という言葉を、Open Source Initiative の定義以外の言葉で使うことは望ましくないと思います。 ですので、ライセンスはそのままでいくのなら「オープンソース」を 謳うのはウソになりますので「データ部分はソースを公開していますが オープンソースの定義には合致しません」と言わなければなりません。
オープンソースの定義では、TeX のように改変はパッチの形にすることを 要求したり、改変したものは名前を変えたりすることを要求しても 構わないことになっています。今回の目的を達成するためには、 このようなライセンスをとることで、オープンソースの定義に合致し、 同時に、日本医師会の社会的責任も果たせるということになるのでは ないでしょうか。
Re:Philosophy problems.... (スコア:1)
あの文書は、「大衆向け」に書かれたものであって、「オープンソース小姑」を満足させるためではありません。いや、私はギリギリまで(宣言当日の午前中まで)、「オープンソース小姑も満足させないと、不完全ですよ」と頑張ったのですが、「新聞記者はそこまで理解して書いてはくれない。それよりは、まず新聞記者を理解させやすいを言葉を使ってから、細いことは今後説明するように」ということで押し切られました(オープンソースの厳密な定義以前に「無償」という言葉がいくつもあるのも、いろいろアレです)。それにまぁ、あれは少なくとも「ザ・オープンソース」ではないけれど、「オープンソース」であることに違いはないでしょ？
理想を言うのはたやすいですが、それを理解してもらうには、まだまだ我々のやって来たことは足りないのだと理解して下さい。
Re:Philosophy problems.... (スコア:1)
そういうことなら、了解しました。
まず、ぼく自身は、改変の自由がないのはオープンソースじゃないと思っています。が、世間ではソースが公開されてさえすればオープンソースだと思われているようだ、ということや、それどころか、「無料」ということのみにしか目が行かない人のほうがむしろ大多数だという現状があるのは認識しています。
そういう現状で、「無料」ということよりは「ソースが公開されている」ということに、それからさらに「改変自由」というところに世間の関心を持っていくにはどうすればいいか、という戦略としては、今回の妥協は受け入れることができるものだと思います。
「IT 化宣言」にしても、改変自由の利点にまでかなり突っ込んだ内容で、これはすごい、と思いましたもん。
今後、利用者からのフィードバックや開発者コミュニティの形成へと進んでオープンソースならではの実績を積んだところで、利用者自身から、「これって厳密にはオープンソースじゃないよね」という声が出てくれば理想的なんでしょうが、なかなかそうはいかないのでしょうね。
日本では「オープンソース」って商標じゃなかったんでしたっけ... こんなページ [spi-inc.org]をみつけましたが、たぶんこれは米国での話ですね。
Re:Philosophy problems.... (スコア:1)
データについては、「某名前の一部にGnuを持つ人」から、「GPLちっくなライセンスにしない方が、扱いは楽になるし、いじれるメリットも少ない」という助言があったので、いわゆる「ザ・オープンソース」にこだわらなかったというのもあります。
Re:Philosophy problems.... (スコア:1)
健康保険組合（国保連合会だったっけ？）の側には、保険点数の内容に沿ってレセプト内容を点検するシステムがあるそうです。
現在、紙の書類でのレセプト提出のため国保連合会側で再度データを打ち込みし直していると訊いたことがあります。これが電子レセプトになれば、そのままチェックできるわけです。
こういうシステムが無くてもレセプトの内容は審査されているので医療機関側がレセプトの内容を改竄しても、病名と薬、手技の組み合わせが保険点数表に沿っていないと「○○に疑義」と送り返されることになります。
Linuxの理由が判った (スコア:1)
確か規模的には病床数200床位までの中規模あたりまでをカバーすることを目的にしていると訊いてます。これで安価にオーダリングシステムを組めるようになれば一気にオーダリングシステムの普及が進みますね。
某公立病院でオーダリングシステム他基幹システム一式の導入事業を一人で管理した経験から気になる点は、やはり運用体制。導入したあとどう維持していくのか。これは大問題です。
レセコンなら医事課だけですむけど、オーダリングは病院全体の業務に絡んできます。情報化の意味を理解している経営者が主体的に取り組んで職員全体で業務を改革していくという気概がないと、折角のシステムを有効活用して効率化することは難しいです。
あと電子カルテの場合、24時間・365日の稼働をどう保証するのか。
確かORCA計画に情報センターという記述もあったようですが、各都市にセンターを置くなどしないとコスト的・要員的に厳しいですよね。
地域のレセコン業者にも参加を呼びかけていて、公的機関と民間企業で共同して新しい事業を興すモデルになると、私は感じました。
医院向けや小規模病院のレセコンは、このシステムに急速にリプレースされるんだろうなぁ。
で標題。
なんでLinuxなのか、ここを見て理解できました。
個人的にはFreeBSDのほうがサーバOSには向いていると考えていたんですが。
どのみち専用端末になってしまうなら端末OSもLinuxのほうが管理上好ましいですね。高い金を出してWindowsを使って専用端末としてしか使わないなんてもったいないです。
Re:Linuxの理由が判った (スコア:1)
専用線を使って、リアルタイムにバックアップを取るようにもなっていて、二重三重の可用性追及になってるのです。
PC UNIXならではの可能性 (スコア:1)
私の携わったのは病床数500床以上の総合病院でした。
電子カルテまで行かないオーダリングでも、フル・オーダになってしまえばシステムをできるだけ止めないようにしないと実用性が減じてしまうんです。で、私としてはサーバのフォールトトレラントを実現したかったのですが、国産商用UNIXサーバでは、まだ技術的にも走りだったのと費用の問題で実現できませんでした。
PCサーバ自体の信頼性と処理能力が向上し、クラスタリング技術の信頼性が確立し、ロードバランシングなどが実用化されれば、今までの常識は激変しますね。問題は医療情報部門を確保できないところで、このようなシステムをどう管理するのか。オンライン保守機能は必須だと思いますし、データセンターで複数の医療機関のデータを一括管理し院内のキャッシュとして、このようなシステムを使うということも考えられるのでは？
今後の計画として、より規模の大きい医療機関向けに改良する計画はあるのでしょうか？
あと給食管理や検体検査などの部門システムとの連携について、どのような計画なのかも知りたいところです（日医のWebでは電子カルテしか見つけられず・・・）。病院では部門システムの導入も進んでいると思われるので、患者基本情報の共有が必須になると思います。
この計画は本当に期待しています。是非、成功して欲しいです。
追記
Linuxの大家の書き込みにFreeBSDと書いたのはまずかったかしら(^_^;)（FreeBSDってシンプルで理解しやすいんです）
Re:PC UNIXならではの可能性 (スコア:1)
某大学病院で使えるようにというオファーは既にあるので、その時には本格的なロードバランシングもさせたいと思います。まぁやるべきことはいっぱいあるので、当分楽しめます B)
コードはあまり変なことはしていないので、pthreadとglibが動いていれば、どこでも動かせるでしょう。TPモニタ自体はBSD系でも動かせると思いますが、COBOLが動かないかも知れませんね。
COBOL (スコア:0)
// なんで今更？やはりCOBOLer救済目的？
運良く担当落ちしたので詳しくは知らないけど本当にCOBOLで作ってあんのかな？
確か地方公費のインプリ部分でどうとかこうとか．．．うにゃむにゃ言っていたはず．
ま，なんにしても担当落ちして良かった．
MUMPS (スコア:2)
＃「産業界の言語」としてはCOBOL優れている思う
COBOLの理由 (スコア:1)
# こちら [nikkeibp.co.jp]も御覧あれ。
Re:COBOLの理由 (スコア:2, 参考になる)
# これが結構いてねぇ
あと、COBOLのありがたいのは、いろんな方法論が確立していて、プロジェクトとして動かしやすいということ。最近の手法はまだ「その辺の人」には浸透してないからね。
個人的には、金とか定型処理を書く時はCOBOL使いたいけど、他のことを書く時には他の言語を使いますという程度なんで、「シンパ」と言われるほどではない。あまり難しい命令は使えないし^^;
AIMを真似てると言っても、外部仕様の一部だけです。プログラマが富士通系な人が多いとゆー事情があって、だんだんAIMっぽくなってしまった。ただ、私はAIM自体を開発していたことはないので、それ以上を真似ようがないです。だから、残念ながら「沼津で会う」なんてことはないです。川崎工場では仕事してたけど、沼津は行ったことないです。
Re:COBOL (スコア:1)
ま、タイプ量が多いのが珠に傷ですけど。（笑）
FORTRANの代用品はあるかもしれんけど、COBOLの代用品って、
ちょいと思いつかないねぇ。
Re:COBOL (スコア:2)
でもCOBOLの数字関連の編集項目とか文字列操作とかをCとかでやろうとしたら、結局タイプ量増えません? (^^;
>FORTRANの代用品はあるかもしれんけど、COBOLの代用品って、
>ちょいと思いつかないねぇ。
xBASEやらMAPPERやらEAGLEやらの第四世代言語って今どうしてるのかなぁ。(あっ、dbMAGICのLinux版てのは聞いた憶えがあるな)
Re:COBOL (スコア:2)
但し汎用機限定ですが。
# Unices で動くのも探せばあるとは思いますが。
Re:COBOL (スコア:1)
PL/1人口がCOBOL人口よりも少ないのがネックになるし、「なければ作る」もPL/1だと大変だし...
Re:COBOL (スコア:2)
# ホストならハードのおまけでしょうから。
確かにプログラマ人口は COBOL に比べると少ないですが 他の言語に比べれば (BUGLES みたいな COBOL 派生の軟弱モノと比べても) 敷居は低いと思いますけど。 IBM 系なら今でも...とか思いますけどねぇ。
Re:COBOL (スコア:1)
DBを扱って、お金と帳票を相手というと、私ゃ RPG を思い付きますがねぇ。
＃フリーなRPG処理系(Postgresが使えるやつ)があったら、今すぐにで入れるんだけど。
＃それでも、レガシーな事には変わり無いですが。
wild wild computing
Re:ビジネスチャンスやで (スコア:1)
COBOLという言語を使うことは、まぁ他の言語が使える人にとっては、そんなに大変なことじゃないわけで、それ自体がスキルと言えるようなものじゃないんです。だから、「COBOLが書ける」ということをスキルと位置つけるためには、「COBOLという言語が使える」ということではなくて、「業務をCOBOLで表現出来る」ということが必要なのです。そして、そのためには、「COBOLという言語」の知識の他に、「その業務がわかる」ということが必要なわけです。だから、「銀行をやってるCOBOL屋」に、医療システムのプログラムは書けないのです。
# そりゃ業務を勉強すりゃ書けるけど
逆に要求スキルが、「COBOLで書ける」だけで済むのであれば、何もCOBOLなんて使う必要はありません。医療システムをやってる連中がCOBOL書きであったから、COBOLを採用したまでです。
Re:しかし改変不可っていうのは (スコア:1)
公には効果の認められていない薬をあえて使いたい時は、保険用の病名をつけるとか、処方から妥当な病名をつけるシステムとかあるそうですが、「ORCAでそれをやるとソースからそれがバレバレになるから」ということで、ロジックとしては入れてないはず。
Re:しかし改変不可っていうのは (スコア:1)
＞病名をつけるシステムとかあるそうです
レセプトを作成するときに、病名をつけ直すという古典的な方法があります。結構やっているところは多いと思います。 この場合、システムがいかに正当に作られていても提出されるレセプト自体の正当性は判らないです。 もしどこまでも保険点数で認められた内容しか金を出さない、というならば、アメリカのようにカルテを提出させるしかないと思います。
Re:しかし改変不可っていうのは (スコア:1)
カルテの提出云々については、「第8レイヤー」の話なんで、何とも言えませんわ^^;