歯科レセコン、電子カルテ？を語るスレ　7

従来の歯科レセコンと違って、社保庁の言うコードの複合、合成に対応
出来るということでしょうか。
　そういう意味では、鋭いのかも知れません。期待しています。

>>930
君言ってることおかしくないか？

>>927の開発に関しては知識がないので鵜呑みにしてしまうが、
保守に至ってはプライスレスって絶対おかしいだろ

脳座に関しても、俺が脳座使ってるから偏見かもしれんが、
他と比べて営業力が強いなんて感じたことは無い
つかあの会社の場合、昔はどうあれ今はそこじゃない気がする

さてさて現実にもどろう。
点数改定を振り返ってどうだろう。他に入れ替えたくなったか、問題なく継続するか？？
最後の買い替えが今から２０１１年３月までと思ってる。
あと３年間、さあどうだろう。

>>933
うん、同感。開発言語のウンチク垂れられてもしょうがないですねよ。
ウンチクは実現させてからにして貰いたいです。有言不実行はかっこ悪すぎです。
今までのいろんな事できるといろんなメーカーから言われて早数年。何一つ実現できていない。
２０１１年３月のレセプトオンライン対応を適切な値段で提供、保守してくれる
メーカーさんと今後は長いお付き合いをしたいと思っています。

>>932
レセ電用の厚労省マスターへの対応という意味でしたら、それとは
関係ありません。
レセプト・オンラインについては、今日ちょうど
ttp://www.nextftp.com/jdpa-kyushu/h20sem.html
こんな話をしてきたところですので、公開されている範囲では
お答えできます。

>君言ってることおかしくないか？
えーと、具体的にどこでしょうか？

>実現させてからにして貰いたいです。有言不実行はかっこ悪すぎです。
えぇ、もちろん、すべて実装済みです。
評価版がDLできますので、ぜひ、その目でお確かめください。

>>930
普段、患者さんに説明しているような
分かり易い言葉で説明してください。

>>937
あなたが理解できるレベルに合わせて発言してもらえるとでも？
わからない分野の発言に対してはスルーが基本でしょう。
わからない事に口出ししてなに甘えてるの君は？

それと一連のageレスはレスの方向性からして同一人物のような気がします。
下品なレスなのだから基本sage先行というのがマナーでは？

やれやれ、バレちまったか、しょうがない（笑）

でもねぇ、直販レセコンが売れてしまうと業界は困るんですよ実際。
それとここででよく脳挫のレセコンが叩かれるかちょっとは考えてみて。
みんなでお手手つないで仲良くやって行きませんか？
もちつ もたれつ 寄り添わず・・・・

>>937
はいはい。

oop（オブジェクト指向プログラミング）とは、
オブジェクト（＝物、もの、者）を中心に考えてソフトウエア
（だけではないですが）を作成する方法です。
オブジェクトとは、ものです。義歯とかインレーとかカルテとか
パソコンだとか、とにかく現実でも仮想でも物です。

「もの」には「属性（プロパティ、性質、変数）」と
「振る舞い（メソッド）」があります。

「私の犬」には「色：白い、体重：やせている、しっぽ：長い、。。。」
という属性があり「走る、吠える、食べる、。。。」等の振る舞いをします。

「私の犬」の振る舞いの「食べる」というメッセージを送ると、「私の犬」
は食べて太っていきます。結果として「体重」という属性が「太っている」
に変化します。

「私の犬」にメッセージを送っているのは「私」というオブジェクトかも
しれませんし、「私の母」というオブジェクトかもしれません。

オブジェクト指向のプログラミングとは、このように
「私の犬」以外の様々な必要な「もの（オブジェクト）」を作り
その「もの」の振る舞いを決め、
「もの」と「もの」との関係性を構築し、
一つの世界を創造することです。

ありゃ、ちょっと日本語おかしいですね。
まあ、いいか。

続けましょう。
「私の犬」は「犬」という「クラス」の「インスタンス」
です。「クラス」とは鋳型のようなもので、「犬」という
鋳型から「私の犬」や「あなたの犬」が作れます。
どれも「犬」ですが、色や体重が違うので、別のオブジェクト
になります。
また「クラス」は他の「クラス」から派生して性質を「継承」します。
「犬」のクラスが「ほ乳類」クラスから派生しているとすると、
子どもを産んで、乳で育てるという性質が「継承」されています。
その基本的な性質に「犬」であるための別の性質を加えたものが「犬」
クラスになるわけです。

世の中の仕事や仕組みは、案外基本は同じで、一部が少しずつ違う
ものです。ここで、すでに基本的な仕事をこなす部分が先陣たちの
努力で用意されていれば、今の仕組みに合わせて一部を修正するだけで
OKなはずです。
オブジェクト指向ではこのクラスの「継承」を利用して、その一部を
無理なく短期間で修正して新しい仕組みに合わせられます。

レセコンや電子カルテでも事情は同じです。他のアプリケーション
から基本部分を利用することで短時間で開発を行ことが可能であり。
改正時も、その変更点だけを修正するだけで時間や費用をかけずに
対応できるのです。

>>933
>保守に至ってはプライスレスって絶対おかしいだろ

オブジェクト指向プログラミングにより、プログラムの保守に要する時間は激減します。
これは従来のプロジージャー型プログラミングのそれと比較になりません。
ソフトウェア業界は製品を作るために必要な理論上の作業時間である工数＝金という
前提で成り立っています。単純に工数すなわちお金だけで計算できないという意味で
プライスレスという表現をしました。
「絶対におかしい」という強い確信がどこからくるのかわかりませんで適切な回答では
ないかも知れませんが。

脳座さんは今もって最強であると思います。偏見を排除するならばなおさらそのような
見解になるはずですが？
「他と比べて営業力が強いなんて感じたことは無い」、「昔はどうあれ今はそこじゃない
気がする」という発言こそ偏見ではないかと。「営業」の言葉の意味を狭義に解釈
されているのかも知れませんが・・・
確かにあそこが社内で色々あったことは知っていますし、スピンアウトした会社が
SOAPを提唱したカルテコンを開発し、それをどこが販売しているか等の裏のドロドロな
事情を説明しろと言われればある程度できますよ。ある程度の事は分かった上で
発言していますので悪しからず。

>>935
>ウンチクは実現させてからにして貰いたいです。有言不実行はかっこ悪すぎです。

実現はしていますのでご安心下さい。ただ、なぜ自分のところに情報が来ないのか？
特にこの業界の重鎮と自負されている方々は疑問視されることと思います。
とかくネットに強く依存している方々はネットの情報がすべてであると思いがちです。
ネットを過信しすぎると、知らぬ間に情報弱者になっていたりすることもあるでしょう。

今はオブジェクト指向などという言葉を持ち出した事を反省しています。
どんなに上手な説明をしても言葉の上では理解できてもプログラミングへの
関連性は理解できないと思います。自分がそうでしたから・・・

作者さんの「私の犬」の説明は，オブジェクト指向プログラミングの仕組みを直感的に
理解するのには適していると思いますが、実際にはこの説明は正しくありません。
オブジェクト指向のプログラムの世界では、「私の犬」クラスにnew指令を送ることで
個々のインスタンスが作られますが、現実世界の犬が生まれるのは妊娠したメス親
が出産するからです。また、プログラムのインスタンスはメッセージを受けると必ず
仕事をします（反対にメッセージを受けるまではただじっと待ち続けています）。
これに対して現実世界の「私の犬」は，「鳴け」と命令されても機嫌が悪ければ
飼い主を無視するでしょうし、命令されなくても鳴きたければ自分の意志で勝手に
鳴くでしょう。

従来のプログラミングスタイルは、呼び出される側を共通化するために共通サブルーチン
をつくりモジュール化していくものでした。それがオブジェクト指向における呼び出す側を
共通化するポリモーフィズムの仕組みは、ソフトウエアに大きな柔軟性をもたらす
ことになりました。現在フレームワークと呼ばれる大規模な再利用部品があるのは
この仕組みによるものです。革命と言ったのはこんな事も理由の一つにありました。

では、今は「有言不実行」の「張り子の虎」の称号を甘受するとしましょう。
現実世界では「張り子の虎」が本物の虎になることはないでしょう。
でも、オブジェクト指向の世界では「張り子の虎」クラスをnewすれば
利用可能なインスタンスが出来るということを証明して差し上げましょう。

おっと、「多様性（polymorphism）」について先を越されちゃいました。
まあ、仮想の「犬」ということでご容赦を。

「私の犬」は「私」が「鳴け」と命令すると「ワン！」と鳴きます。
ここで、新しいオブジェクトの「隣の猫」がやってきました。
オブジェクト指向の住人の「隣の猫」は「私」の「鳴け」という
命令をちゃんと理解して「ニャー！」と鳴きました。

このように相手が違っても同じ命令が有効であるのは相手の猫や犬が
「多様性」を持っているからです。

これが従来のプログラムの世界では、
「隣の猫」に「鳴け」といっても応えてくれません。「隣の猫」は「私」の
「鳴け」という命令が理解できないからです。理解させるには「私」が変わって「（猫語で）ニャアニャ（鳴け）」と命令しなければいけません。

すなわち、一部プログラムに修正が必要な場合、その影響が広範囲に広がって
しまうのが従来の方法です。
改正時に、ここ一カ所ちょこっと修正すればいいと思っていたら、
あっちもこっちも修正しないとダメだぁ、どうしよう。という事に
なっていたわけですね。

長すぎて読む汽船。

では短めに行きましょう。　「オブジェクトまで読んだ」でもおｋｗｗｗｗｗ

オブジェクト指向の説明で問題となるのは現実モデルと相違する点だと思います。
新しい言語を覚える時、既知の言語との対応付けを試みようとします。
これと同じようにオブジェクト指向を理解しようとすると頓挫してしまいます。
「私の犬は」鳴けと言っても鳴きませんし、鳴いて欲しくないときに鳴きますし、
「隣の猫」はもっと言う事を聞きません。ならば言う事を何でも聞く既存の
プロシージャ−犬を大切にしようかと・・・
皮肉なことにオブジェクト指向の概念は、実際にオブジェクト指向を理解した後に
すんなりと理解できるようになります。

最初に英会話を勉強する時、どうしても英語を日本語と対比させようとしてしまいます。
いつまでも聞き取れず、自分の耳が腐っているのかと悲しくなります。
しかし続けているとある時すんなり英語が入ってくるようになる時があります。
英語習得に王道なしとはよく言われますが、オブジェクト指向のマスターに王道なし。
実体験からはそう思う次第であります。

「では」 まで読んだ。

>>946
やっぱりそうキタかｗ

特に今までのやり方で問題ありませんが何か？

現実問題として新しい技術を習得している余裕なんてありませんよ。
オブジェクト指向とやらでなければ開発できないなら別ですが。
C++で開発していますが何も不足してませんしこれからずっと無問題かと。

特にiMac全盛の時代に4Dなんて使う意味があるのでしょうか？
データベースは遅いし。肝心のオブジェクト指向の影も形もないし。。。
生きた化石相手に老体に鞭打って奮闘しているだけかと。。。

>>948
C++を使われているのであれば恐らくオブジェクト指向の恩恵は十分得てらっしゃるのでは？
プログラマの立場からはオブジェクト指向は理解する事より恩恵を得る事が大切なのであって、
そのものを理解する必要性は必ずしもないと思います。ですが習得しておいて損はないでしょう。

例えば医科の電子カルテの標準的な機能をオブジェクト指向で体系分析すると、
機能モデルが国際標準的なUML記法により記述できます。
歯科医師会からUMLで仕様が出されてから習得では遅いと思いますよ。歯科では有り得ない？
ええっと…過去にどこかでUML記法の歯科傷病マスタを見たことあるけどなぁ。
あれを見たときは歯科も捨てたもんじゃないと思ったものだけれど・・・

C++なら、自然とオブジェクト指向になりませんか？
もっもと拡張部分を使っていなければCと同じですけど。

>生きた化石相手に老体に鞭打って奮闘しているだけかと。。。

いや、本当、まさにその通りです。
だからせめて哲学だけはoopでと思っているんですよ。実際
効果ありますしね。
でも、いろいろ他の環境も試しているんですが、4Dの気楽さを味わって
しまうとねぇ。
WinとMacでほとんどソース変える必要ないし、コピペでインストール
できるし。ユーザーがデータベースやランタイム環境を別にインストール
する必要もないし。
全部一人でこなすには、やっぱり4Dじゃないと無理なんですよね。

そこで、若人にぜひ聞きたい。
これからはこれだぁ！っていう開発環境は何ですかね。

>>949
MFC で CWinApp を継承する時点ですでにオブジェクト指向の恩恵は得ていると思います。
でも、いまだにオブジェクト指向が何かわからずにコーディングしています。
英会話学校に何年通っていても、英語が聞き取れない人ということになるのでしょうか？
でも日本にいる限り、英語が出来なくても十分生きて行けるんですよね。
ならば出来なくてもいいかと。。。現実逃避。

>>950
4Dのように言語にすべて詰め込んでしまうと個々の機能の性能向上が望めなくなるのでは？
ユーザーがデータベースやランタイム環境を別にインストールする必要の有無は
インストーラの作り方次第であって、本来言語とは直接関係ない事だと思います。
InstallShield等を使えば出来る事は知っていますが。。。これまた現実逃避。

これからはこれだぁ！っていう開発環境はわかりませんが、これしかないっ！
というのは今使っている開発環境になると思います。
これはたぶん、作者さんが4Dを使いつづけるのと同じ理由です。

極論を言うと開発環境は自分で作るものだと思います。
たとえばifesでもEmでもフリーのでも好きなエディタとCコンパイラの組み合わせ。
今の時代Make Fileを自分で作ってる人ってどれくらいいるんだろう…

これからはこれだぁ！って言語はJavaだと思いますｗ
大学でJavaで遊んでくれていれば、幅広い分野でほぼ即戦力として使えます。
でも、個人的にはアセンブラをやっていたような人が欲しい。
矢沢久雄著の「プログラムはなぜ動くのか」なんて本がバカ売れする時代ですからｗ
「コンピュータはなぜ動くのか」、「Javaでなぜつくるのか」・・・
矢沢さんは面白い本を出していますね。ちょっと好きです。

ユビキタスやっと見つけたぜ。これかよ！
ttp://www.ss-class.com/entry.php

普段レセコン開発者の皆さんのお話なんてなかなか聞けませんから非常に興味深く
レス拝見しております>>902の「歯科ソフト」の作者です、皆さんオブジェクト指向で
歯科保険の算定をレセプトの請求（紙媒体と、将来のオンライン）にどう結びつけ（てい）るのか
あるいは、さらに電子カルテへと結びつけ(てい)るのか非常に興味ある所です。
私の場合、保険更新時にコーディングをなるべく避けたいので、一つの算定（例えば、歯科再診料）
をまるっきり単なるXMLタグのオブジェクトとして扱っております、そこから何の継承もしておりません、
そのタグオブジェクトにさらに制約のタグオブジェクトをぶら下げるだけです。
理由は将来どんなワイルドカードが歯科保険の登場するか想像もつかないからですが何か良い
知恵は無いでしょうか？まぁここが秘密の所よっていうのもありですが面白いポインタ等ありましたら
教えていただけませんか？

っと、>>954のつけたしです、一番怖い将来のワイルドカードが「点数X負担率=患者負担金」の関係が
まったく否定された場合ですね、こうなったら、会計部分の再コーディング必至です。

カルテメーカーって、作者さんがあぼーんしたらどうなるのでつか？

＞歯科保険の算定をレセプトの請求（紙媒体と、将来のオンライン）にどう結びつけ（てい）るのか
あるいは、さらに電子カルテへと結びつけ(てい)るのか非常に興味ある所です。

これを含め、前回かすった内容でコメントしましたがユーザーも
興味のあるところです。多分どのメーカーも・・・・・・。

　ただ、将来を見据えれば、レセよりカルテでしょう。

>>951
>インストーラの作り方次第
その通りなのですが、それを作る手間が面倒というか、
時間がないというか。。。

>これしかないっ！ というのは今使っている開発環境になると思います。
至言ですなぁ。

>>952
やはりJavaですかね。

>個人的にはアセンブラをやっていた
歯医者で食えなかったら、ぜひ雇ってください。
ハンドアセンブルでアセンブラを作成した経験あります。(z80、8086)

>>954
>保険更新時にコーディングをなるべく避けたい
今までの度重なる保険改訂をくぐり抜けてきた経験から言えば、残念ながら
コーディングは避けられません。
如何にコーディングする箇所を局所にとどめることができるかが、レセコンの
メンテのしやすさを左右します。

基本的に、変更が考えられる部分（会計やレセプト集計等）は常に日付に
よって使うクラス（あるいはオブジェクト）を切り分けるようにします。

こうしておかないと、例えばH20年４月の改定後に、３月部分を修正した時に
会計がおかしくなります。

これがまさに呼び出し側を共通化するポリモーフィズムを上手く使いこなせるかどうかの分かれ目になります。

会計は本当に大変ですよ。昔で言えば薬剤一部負担金の導入と廃止がありましたし。今でも各県の公費なんて、様々な負担形式があります。２０種類以上の
負担パターンを用意して対応していますから。

以前にこのスレにも書きましたが、
私が開発を継続できない状況になり、後継者が無い場合は
ユーザーグループにソースが公開される手筈になっています。

すると、それからは無料で使えるんですか？

>>958ありがとうございます、やはり一人コーディングは大変ですよね

>常に日付によって使うクラス（あるいはオブジェクト）を切り分けるようにします。
>H20年４月の改定後に、３月部分を修正した時に会計がおかしくなります。
ですよね、ここはなんとかできております、今回の改訂は前々回の保険の考えに
戻ったような部分がかなりあったのでほとんどコーディングせずで対応できたのでよかったのですが。

>２０種類以上の負担パターンを用意して対応していますから。
公費負担ってそんなに種類あるんですか！いやーまったく未対応部分です、勉強します、
実装します。

>ポリモーフィズムを上手く使いこなせるかどうか

まさにこの言葉に尽きると思います。

コンピューターが判断できる要素はすべて自分で判断させて処理を切り替えさせる。
そんな自律システムの実現こそOOPの醍醐味です。
たとえば前年度算定の実施による処理変更、公費算定の切り替え等。このような事象は
すべてプログラムで判断し必要な時点で必要な仮想関数に自動的に切り替わる。
ほとんどかポリモーフィズムを実現させるためのロジックで成り立っています。

よく「お前が死んだらオワリ」じゃん！と言われます。リスクマネージメントお粗末と。
リリースはオープンソースです。しかしコーディングはC#です。
一応Java使いの方を最大限に配慮して違和感無なく理解できるように工夫を凝らしています。
しかしJavaでは逆立ちしても到底出来ない技がいくつかあります。
でもそれは全体の0.5%にも満たないのでおそらく無問題でしょう。
あとCSS等が理解できる人は腐るほどいるでしょうｗ

各社のレセコンを見ているとほとんど同じじゃないか？と思われる商品がいくつかあります。
しかも仕様の合理性から見て、ほぼ一人で作られたのではないかと思われます。
このようにOOPを利用せず、旧態依然の技術でもって、一人で数社のレセコンを力技で
開発されているような方のバイタリティーには本当に感服します。
でも40〜50代のプログラマーさんに聞くと、年を重ねるごとにそのようなバイタリティーが
持続しなくなるそうです。特に男性は弱いのことw

OOPで今から楽をしている自分は、将来どうなってしまうのだろう？そう考えると不安です。

>自律システムの実現こそOOPの醍醐味

ウンウンウン、そこ、そこです。
もう２０年近く前になりますが、ハイパーカードで電子カルテ
を作り出した時からになりますが、カルテの書かれた処置項目
（印象、基本検査、インレー、SCなどなど）は各々が自律した
オブジェクトであると捉えるべきだと主張しています。

例えば「大臼歯パラインレー複雑」というオブジェクトは、自らの
判断で、「大臼歯」だけを選び、過去の履歴を見て、印象や形成という
オブジェクトがなければ警告を出すという振る舞いをするように
作ります。

そのオブジェクトが「カルテ」という「場」にある場合、「レセプト」と
いう「場」にある場合、「入力時のセットパターン内」という「場」に
おかれた時にどういう振る舞いをするかを知識として与えることで、自己
組織化し、最適な表現形式が得られ、ユーザーがカスタマイズする自由
を維持しつつ管理が簡単になるようなアプリケーションができると考えています。

まぁ、でも２０年もやってきて、まだまだ道半ばなんですけどねw

>自律システムの実現こそOOPの醍醐味
そうなんですよね、しかし私の悩みは、ここにまるっきり予期しなかった制約が
加わった場合、基底オブジェクト（あるいはインターフェイス）に新たに
定義、さらに新規にそれを計算するロジックの実装を書き加える、しかし、
そのロジックが今まで他のロジックと複雑に絡み合いオブジェクトで隠蔽していた
他のロジックをさらに細分化カプセル化したり再計算に伴うオーバーヘッドを避ける
ために、キャッシュに新たな変数の追加などどうするべ？って考えて結局、基底クラス
に自由度の高いXMLタグオブジェクトのみを作り継承もせず構造化？プログラミング（oopの反語と
とらえてください）のような実装をしてしまうのでしたってのがあるんですよね。

プログラミングに当たって一番大切なことは、解くべき問題を理解することです。
そして、問題の解法の大きな構造を理解し、解法の手順をプログラミング言語として具体化します。

プロジージャー型プログラミングの場合、これを怠って行き当たりばったりでコーディング
して行ってもそれなりに機能するものが作れました。ですが、OOPの場合、行き当たりばったりで
作っていってもそれなりに構築は出来ますが、余程ラッキーでない限りは破綻を来たします。
破綻を来たさないためには、問題の解法構造を完全に理解することはもちろんのこと、
問題の「本質」を理解する必要があると思います。

実際のところレセコンメーカーの開発者は先生方より保険の知識については詳しいと思います。
しかし処置ひとつをとってもその「本質」を理解していません。それゆえ歯科医師にとって
満足の行くレセコンに巡り合うのは難しいのではないでしょうか？

この観点からすると、おそらくOOPプログラミングでまともなレセコンを作れるのは、
歯科医師以外には有り得ないと思うのです。しかし、歯科医師でない者がそれをしなければ
ならない場合は、優れた製品をを見てお知恵を拝借したりしますｗ

日立のDental ASPってどうですか？

>>965問題の「本質」を理解する必要があると思います。
まったく同意です、こと歯科保険は総点数を下げるために官僚のおもちゃの
ごとくいじり倒されている感想をうけるんですよね、今後もしかりですよね。
私は、「本質」がそこにあたると思います、んで今後何が飛び出すのか
オブジェクト指向でどれだけ効率的にソースコードの保守をし、なおかつ
新規の制約に対応できるか、大げさに言えば、「本質」が上記の場合まるっきり
未知数に感じるんですよ、今までの改訂に無かったまるっきり保険の概念を
超越したすごい制約がくる可能性ってドウなんでしょうね？

>>966
ここにその将来が示されてると思われ
http://www.youtube.com/watch?v=tGIZGZBpaas

>>926
会員扶助って具体的にどんな形なんでしょうか？
興味があります。

>>962
各社のレセコンを見ているとほとんど同じじゃないか？と思われる商品がいくつかあります。
しかも仕様の合理性から見て、ほぼ一人で作られたのではないかと思われます。
このようにOOPを利用せず、旧態依然の技術でもって、一人で数社のレセコンを力技で
開発されているような方のバイタリティーには本当に感服します。
でも40〜50代のプログラマーさんに聞くと、年を重ねるごとにそのようなバイタリティーが
持続しなくなるそうです。特に男性は弱いのことw

開発者没ればオジャン！　ヒットマンに頼めば天下とれる可能性もあるんじゃない
Ｍ＆Ａとか早くなればいいんだよ、レセコン会社はこのさき三分の一になって従業員の総数は二分の一に
それでよし。

つぶれそうなレセコンメーカー
　　　　　　↓
http://society6.2ch.net/test/read.cgi/bio/1211646828/l50

そんなことより医師会の最強ASPレセコンについて話そうぜ

>>972
死科医師会のレセコンて、自民党寄りで、きっと技官寄りなんだろうな。

高いレセコン買って少ない保険点数しか得られない時代なら、いっそ、
カルテコンをメインにして、もちろんレセコンにも使えるし、自費の見積もりや
ﾌﾟﾚｾﾞﾝなどもできる奴を出したら需要があるのでは？

昨年の8月から、無料レセコンソフトのD-Byforを利用していますが、
使い勝手がとても良くて満足しています。
平成20年の4月の改定にも間に合い、4月分のレセプトも問題なく提出できました。
高価なレセコンを導入できない歯科医院には最適のフリーソフトだと思います。

>>975
>無料レセコンソフトのD-Byfor
無料ということはサポートも無料ですか？それって怖くない？今はよくても。。。

D-Byforは、パソコンが使える人なら誰でも簡単に操作できるため、
サポート契約しなくても問題なく使用できます。

また、99ページの内容の「ユーザーマニュアル」が、ソフトと同時にダウンロード
できますので、これを読めば最初から問題なく使用できます。

ソフトの製作者は歯科医師ですので、ソフトの使い勝手が利用者の立場に立って
作られており、とても親切な思いやりのあるソフトです。

それまでに使っていた有料ソフトに比べて、パソコンのフリーズも全く発生せず、
とても使い易いソフトです。

「ユーザーマニュアル」も至れり尽くせりの親切な内容になっています。

有料サポートも用意されてあり、年間72600円（税込）です。

有料サポート内容は、
「基本操作方法および障害に関する技術上の助言、対象製品の
バージョンアップに伴う技術的助言」となっています。

当方は、有料サポートなしで利用させて頂いています。
昔では考えられないことで、いつも感謝して利用させて頂いております。

>>977
趣旨はよく理解できました。それでもやはり不安があります。歯科医師が開発したとありますが、
その先生が突然や〜めたというリスクはないのでしょうか？

下記のサイトから、無料でソフトとマニュアルをダウンロード出来ますので、
一度お試しになってみることをお薦めいたします。

「ユーザーマニュアル」も太字部分になっている箇所だけ読めば、
初めての方でも直ぐに利用できるようになっています。
10分程度で読める内容です。

ダウンロードサイト
http://d-sqr.com/plus/in/dbyfor/

「D-Byfor無償導入バージョン「D-Byfor.F」が生まれた背景は、
歯科診療分野で「標準レセコン」を確立したいとの願いから
スタートしたものです。」
と、無償ソフトが生まれた背景が解説されていますので、そう簡単に
や〜めたというリスクはかなり少ないと思います。

「標準レセコン」ということは、殆どの歯科医師が利用することを
目標に置いているという意味ですので、今後も永続するはずです。

仮にそうなったとしても、D-Byforのデータは簡単に他のソフトに移植
できるように設計されていますので、問題は少ないと思います。

　

つぶれそうなレセコンメーカー
　　　　　　↓
http://society6.2ch.net/test/read.cgi/bio/1211646828/l50