この3か月間は、一向にクラウド電子カルテが発展しませんでした。

Myprodoc電子カルテのクラウド版をパソコンで運用することは完成していますが、レセプト版がうまくゆきません。途中でodbc中断してしまいます。

これは、レセプト版は保留にしました。

今、取り組んで来たことは、スマホで電子カルテの一部をwebカルテを作成することです。

井原先生が作成された　

ｐｈｐによるサーバーサイドカルテです。

ホームページにアップロードされておりましたが、winsows　XPの時の

古いPHPのバージョン５では使用できましたが、今はXSERVERではバージョン７ですので、ｍｙｓｑｌに接続できません。

php　古いファイルを新しいバージョンで書き換えようとしますが、相当詳しくないと困難です。一から勉強していますが、途方に暮れています。

１、ｐｈｐを使用するためには、

XAMPPなら

apache　php　mysql　今はmariadbになっていますが、設定がらくらくだろうと考えて、作成に取り掛かりましたが、これも難航しております。

２、phpの使用できる、web　サービスとして、

owncloudがありましたので、

これもやってみるのですが、web上で　データの管理はできそうですが、

サーバーサイドカルテとしての使用がうまくゆきません。

もっと簡単に

スマホで

今日の患者様のリストとsoap入力

ができればいい

のですが

誰か助けてください。

Webで電子カルテを閲覧したい。

ドクターがいつでも患者様の情報を確認して入力ができればいいのですが・・・

特にsoapとその人の特徴を覚えたいと思っています。

クラウド　レセプト作成は　odbc　5.1.13ですね。

レセプト作成は、本当は途中で　odbc　切断してばかりでした。

odbc　5.1.10が最も最速でおすすめと言い続けてきましたが、レセプト作成はうまくいっていなかたのです。

1ヶ月かけてなぜレセプト作成がうまくいかなかったのかをいろいろと検討しましたが、わかりませんでした。

そこで　odbc　選びをもう一度やりなおしました。

odbc　５．１．１３がいまのところ良いようです。

まだ検討を続けます。

2018/12/2

レセプトカルテが本当に、本当にうまくいきました。

実は、前回の成功を報告しましたが、追試を行うとなかなか同じように成功しません。どうしても　masterへのodbc接続が切断していまうのです。エラー番号は　9150でした。

そこで　odbc　administratorでの設定を見直しましたところ遂に完全に成功しました。エラーなく　紙レセプトカルテが成功しました。

いままでは　DNSを　0cloudmasterとしていましたところを

成功例は　DNS　を　master　としただけでした。

素直に　これまでやってきたように　マスターとすればいいのですね。その他の　datumとsupportはそうでなくでもいいかどうかを

確かめてみます。

2018/11/27　電子カルテのすべてのカルテが運用できるようになりました。

一番最後までうまくゆかなかったのは、レセプトでしたが、先ほど成功しました。

レセプトでうまくゆかなかったのは、作業時間が長いので、途中で　odbcが切れてしまって失敗したと思っていました。しかしあきらめずに再開するとゆっくりではありますが、作業はじわじわと進行していたのでした。

紙レセプトを作成するところが一番やまです。その後の電送レセプトはなんなく成功します。

これでmyprodocクラウド電子カルテは完成しました。

あとはもっとスピーディに動くように工夫を続けることです。！！！

Myprodoc電子カルテ　クラウドでデータ移動は可能！！

Xserverにodbd接続で電子カルテの運用が実用可能かが問題です。

そのスピードが遅いので、接続が切れてしまいます。

一日の最初のクエリ作業がデータ移動作業でしたが、これがやっと成功しました。

最善の　mysql　odbcのバージョンを実験してみましたところ

mysql-odbc　5.1.10が最速で動くことがわかりました。

mysql　5.7サーバーに最適の　odbcをずっと検証した結果がやっとでました。

しかしもっと複雑なクエリ作業をするのが　レセプト作業です。これがまだ成功しておりません。もうちょっと頑張ってみます。

基本的なクラウド電子カルテMyprodoc完成しましたが、臨床で実用化の実験を行いましたが、Myprodocの特徴の一つである毎日最初に行う作業　データ移動という作業がうまくいっていなかったのです。

この１ヶ月その不具合の解消に研究を進めてきました。

今朝やっとそのデータ移動がさくさくうまくいったのです。

前回　mysql　odbc　5.3ではなく　5.2　バージョンが最適ですという結論を報告したばかりでしたが、さらにふるいバージョン　５．１　がこの本当に最適の道であることがわかりました。

データは　mysql　4.0.18でつくられたデータであり、accessのオブジェクトすなわちクエリ、マクロ、モジュールは古いデータを動かしてきたのですので、新しいmysqlと古いデータを融合するにはできるだけ古いジョイント　odbc　の方がうまくいったのですね。

もうしばらく臨床で実用できるかを検証してゆきます。

あとは　レセプト運用ですね。

 

XSERVERに接続するaccessファイルがうまくいった例です。

皆様に役に立てるかどうかが問題ですので、その特徴がわかりやすようにまとめます。

皆様の疑問は

１）Microsoft　accessは32bitでも使用できますか？

大丈夫です。もちろん　64bitも使用可能のようです。

２）windowsのバージョンはwindows10　64bitは大丈夫ですか？

大丈夫です。32bitもだいじょうぶです。

３）mysqlのバージョンは選べますか？

残念ながら今は　5.7だけです。データ移行が必要となります。

４）データ移行は難しいですか？　時間がかかりますか？

　　　大丈夫です。

文字化け問題とtimestamp問題がありますが、大丈夫です。

Navicatを使用することにより、容易にデータ移行できます。

そしてデータ移行も可能です。慣れれば1時間でできます。

では、私の完成したXSERVER　Myprodocの基本事項をお示しいたします。

準備するもの　windowsPC　4台（mysql4.0.18用、mysql5.1用、mysql5.5用、mysql5.7用）

アプリ　winnows10（64bit）Microsoft　access(32bit)　mysql5.1、mysql5.5,mysql5.7、mysql-odbc5.2

Rlogin((32bit)

手続き　XSERVER　ネットで申し込み

作業　XSERVER設定とRlogin設定　文献の通りです。

mysqlデータ移行はNavicatを上手に利用する。

文字化けはしないし、timestampもデータ同期にクエリ使用し、一気に構造をmysql5.7形式に改造できるのが大助かりです。

最後は、運よく相性のよいodbcが見つかったことです。

試行錯誤で偶然出会ったこのodbcに感謝致します。

本当にmysqlの奥は深い恐ろしいものがありました。

いくら勉強してもネットで調べても泥沼でした。

mysql8.0の時代になりますが、もうしばらく5.7ですね。

XSERVERに接続できているのにカルテMyprodocがさくさく動かないので、苦労しておりましたが、遂にうまくいく道を発見しました。

クラウド電子カルテMyprodocが完成しました。

mysql　odbc　5.2　Unicodeが　myqsl　server　5.7には最適ということが今日わかりました。

Myprodocのカルテがさくさく動きます。カルテ移動もできました。いろいろなタイプの自作のカルテ　.accdb　.mdbもこれまでのクリニックのサーバーと同様の動きを確認しました。

これまで使用していたのは、mysql　odbdc　5.3　Unicodeでした。いろいろな観点からうまくいかない理由を探っていましたが、実にわかってしまえば簡単です。いろいろな設定を変更しなくでもこれまでどおりの作業でできることがわかりほっとしています。

 

Mysqlアップグレードの際のデータ移行問題はほぼ解決しました。

XSERVERをクラウドとするには、Mysql　4.0.18からMysql　5.7へのデータ移行が必要になったのです。mysqlの構造と設定が変化していくわけですが、Navicatのデータ移行機能を使えば、文字化けせずにデータ移行は可能でした。

しかし問題は、timestamp問題があり、mysql5.7では、空欄を絶対許さなくなり、defaultにCURRENT_TIMESTAMPと入力し、extraにupdate　on　CURRENT_TIMESTAMPと入力しないと許されなくなりました。

各テーブルでその入力をしても悲しい事態が起こるのです。

実はnavicatのデータ移行は、構造もデータも根こそぎソースがすげかわってしまうのですので、折角各テーブルの構造にtimestampの設定を入力してもまた元の木阿弥になってしまうのです。あーーあ骨折り損のくたびれ儲けとなりました。

そこで研究を致しました。

１）mysqldumpを研究しましたが、これはだめですね。変なデータがあれば中断して使い物になりません。いろいろなオプシヨンもありますが、これはその道のプロがおたくしかつかえませんね。

２）やはりnavicatでした。

その方法とは、navicatのデータ移行機能とデータ同期機能をうまく使うのです。

A)　データ移行開始：ソース（mysql4.0.18）からターゲット（myql5.1）にデータ移行する。

B)　データベースの構造改革：各データベースを内部検索し、TSで検索すると各テーブルのTSのプロパティを改革する。すはわち　空欄許さないとupdate　on　CURRENT_TIMESTAMPの二つにチェックし、defaultにCURRENT_TIMESTAMPと入力をする。

mysql5.5には、テーブル構造を完璧にした状態にしておく。

C)　データ同期開始：ソース(mysql5.5）とターゲット（mysql5.1）と比較して、同期させるためのクエリがすべてのテーブルについて作成されているので、それを選択するチェックをしクエリ実行する。

これにより見事　mysql5.1はデータも構造も完璧になっている。

D）あとは普通にデータ以降をソース（mysql5.1）ターゲット（mysql5.7）に行えば楽々いくのである。

ところが、この完璧と思われた　mysql5.7にodbcリンクしたaccess　myprodoc電子カルテは、まださくさく動きません。

入力しても　前みたいにはさくさく登録されずに、削除されましたとか　deleteとなり、更新ボタンを何度もおすと登録されます。

access　Myprodoc自体の　mysqlへのデータ保存させるクエリがうまくはたらいていないようである。ノーバ社に教えてもらう必要がでてきましたね。

Navicatまたまた素晴らしい威力？　timestampのチェック入力簡単です。

Mysql5.7では、テーブルの構造改革が必要となりました。

すなわち各テーブルのTS　timestampにひとつひとつnullを許さないというチェックをすることが必要となりました。これは一つ一つのテーブルを修正しないといけません。

Navicatには、テーブルの「データベース内の検索」という機能があります。

そこで　構造　TSで検索するとそのテーブルが検索され一覧で表示され、そこで　nullを許さないというチェックをして、保存するスイッチをおせば、自動的に　入力されるのです。

ここで一気に　datum、master、supportのテーブルにtimestampのnull　許さない　☑としました。