みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
いつもお世話になっています。 FM15Ad Win7
患者情報T
ID
氏名
疾患名
デバイス情報T
ID
氏名
メーカー
型番
Aリード情報T
ID
氏名
メーカー
型番
と作成
リレーションを下のように設定してます
患者情報T::ID = デバイス情報T::ID
患者情報T::ID = Aリード情報T::ID
患者情報Tのレイアウトにポータルでデバイス情報とAリード情報を表示しています。
質問はここからです。
デバイスもしくはAリード、または両方にリコールが出たときに患者情報Tのレイアウトにリコールの情報を表示したいと考えています。そこで
リコール情報T
日付
メーカー
分類
型番
対応状況
を作成し、分類Fで「デバイス」か「Aリード」か選択し、型番を入力。
同じ型番を持つデバイスを使用している患者にリコール情報Tの内容を表示出来ればと思っています。
また、患者一人一人に対して対応済みかそうでないかのチェックを行いたいと考えています。
一人に対して複数のリコールが出ることがあります。
1リコールに対して対象者が全員対応済みになったらリコール情報T::対応状況に「済み」と入力されるようにしたいです。
このようなことが出来ますでしょうか？
稚拙な説明かとも思いますが、宜しくお願い致します。
Offline
デバイスとAリードを別テーブルにしているので、処理がややこしくなります。1テーブルにしておいた方が、今後も色々な処理は簡単になります。
そのテーブルに、型番情報を持たせた別テーブルを関連づけて、そこにリコール情報を持たせれば良いでしょう。必要ならば、デバイスとAリードのマスターテーブルをリレーションします。
リコールになると、おそらくデバイスやAリードを交換するでしょうから、患者側のデバイステーブルに交換情報を持たせておきます。これは、リコール情報が立てば1となり、交換情報が入れば0となるようにしておきます。型番テーブルからその合計を求めれば、0になれば全て交換済（処理済み）となります。
Offline
Shin様ありがとうございます。
デバイスだけ交換やAリードだけ交換という場合があったためにこのような構成にしておりました。
リコールの機能があとづけになっている状態です。
デバイスとAリードを別テーブルにしているので、処理がややこしくなります。1テーブルにしておいた方が、今後も色々な処理は簡単になります。
情報T
ID
氏名
デバイスメーカー
デバイス型番
Aリードメーカー
Aリード型番
というテーブルを作るという解釈でよろしいでしょうか？
そのテーブルに、型番情報を持たせた別テーブルを関連づけて、そこにリコール情報を持たせれば良いでしょう。必要ならば、デバイスとAリードのマスターテーブルをリレーションします。
これは上テーブルに対してデバイスのマスターテーブルとAリードのマスターテーブルを関連付け、マスターテーブルにリコール情報を持たせるということですか？
質問ばかりで申し訳ないですが宜しくお願い致します。
Offline
ごく簡単な概念だけのサンプル
https://www.dropbox.com/s/sg1qfdo54r3ja … 7.zip?dl=0
ペースメーカーの管理でしょうか。
メーカー名と型番だけの管理なのですか。普通ならば、シリアル番号等を管理されていると思いますが。
Last edited by Shin (2017-05-17 11:29:11)
Offline
Shin様
サンプルファイルまでありがとうございます。
おっしゃる通りでペースメーカー関連(ICD/CRT-D等含む)のデータベースです。
シリアル番号も管理しています。
今回は担当者より
①リコールが出た場合、対象型番もしくは対象メーカーを使用している患者の詳細画面にリコールの情報を表示したい
②リコール対象患者が複数いる場合、すべての患者への対応が終わったらそのリコールへの対応が終了としたい
③患者ごとにそのリコールへ対応したのかどうかを確認できるようにしたい
④リコール情報は同じ型番に対して2個以上発生する可能性がある(デバイスに対してもしくはプログラマに対して)
との要望がありました。
④に関しては個別に対応する必要があるのか確認中です。
Offline
リコールは，型番だけではなくシリアル番号の範囲の範囲を指定して通知が来ると思います。（プログラムの不具合でも、同じ様に来るのでしょうか，もしリビジョン番号を指定してくるのでしたら、その番号も管理しないといけなくなります）
その範囲を設定して，該当デバイスを抽出，全置換等でリコール対象を設定すれば良いでしょう。それに対して，済みを設定していけば，リコール情報に反映するはずです。
Offline
Shin様
ありがとうございます。
担当者の話ですと該当シリアルかどうかまでは入力が大変なのでやらないそうです。
患者情報テーブルで該当のリコールに当てはまっている人だけを抽出し、シリアルを照合するとのことでした。
また、話し合った結果、プログラマーのバージョンアップはそれ単体の情報とするとのことです。
なのでプログラマーの場合はデバイスやリード情報と関連付けしなくてよくなりました。
Offline
> 患者情報テーブルで該当のリコールに当てはまっている人だけを抽出
機器テーブルから使用機器テーブルをポータルで表示するだけで良いですね。この中でシリアル番号を確認して、リコール情報をセットしておけば良いでしょう。
ただ、シリアル番号はバーコードで読み取りできませんか。
Offline
Shin様
お返事遅くなってしまい申し訳ありません。
メーカーから来る情報は紙ベースなのでバーコードに置き換えるという作業がはいってしまいます。
同一機種の患者自体はまだ手動(?)で探せるので今回はシリアルまで入れなくて良いとのことでした。
いろいろ助言ありがとうございます。
Offline
デバイスには、バーコードで機種番号やシリアル番号が付属するはずです。とりあえずは、それを読み取ってDB内に保存しておくべきでしょうね。
リコール情報が紙で来るのは仕方ないでしょう。そこから先は、運用の設計ですので、施設内で考えられればいいです。
リコールの入力を行い、型番でリレーションしておき、対象患者にフラグを立てていく、ということで良いのでは。
Offline
Shin様
デバイス/リードの型番とシリアルは全てデータベース内に入力してあります。
紙ベースなのはリコール情報です。
Shin様のおっしゃるようにリコール情報の入力を行い、型番でリレーションしたデバイス/リードに対してのフラグを立てていこうと思っています。
Offline
人が確認する、という運用で、もしも見落としがあった場合の対処も考えておくべきでしょう。機械が判断するより格段に間違いが多くなります。
そこまで考えると、機械的な判断をメインにするべきだとは思いますが。
Offline
今考えたのですが
リコール情報T：「日付」「メーカー」「分類」「型番」「内容」
リコール対応T：「患者ID」「氏名」「分類」「型番」「対応状況」
を作成。
リレーション
①リコール情報T::型番=デバイス情報T::型番
②リコール情報T::型番=Aリード情報T::型番
③リコール情報T::型番=リコール対応T::型番
④患者情報T::ID=リコール対応T::ID
関連レコードを絞り込んだらデバイス情報/Aリード情報の「ID」「氏名」「型番」をリコール対応テーブルにインポート。
リコール情報Tからは③のポータル、患者情報Tからは④のポータルで表示させます。
対応したらリコール対応T::対応状況Fにチェックをすることでフラグをたて、関連レコードが全てチェックされたら対応終了とする
抽象的ですがこんなやりかたを考えてみました。
これだと難しいでしょうか？
Offline
Shin様
ありがとうございます。
人が確認する、という運用で、もしも見落としがあった場合の対処も考えておくべきでしょう。機械が判断するより格段に間違いが多くなります。
そこまで考えると、機械的な判断をメインにするべきだとは思いますが。
確かにそのとおりだと思います。
提案はしているので、メーカーからエクセルなどでもらえるかなど確認していただこうと思っています。
Offline
リコールがあれば、デバイスの交換ですよね。
リコール対象をインポートしてしまうと、元のテーブルから参照が必要になりますね。埋め込みデータ内に、リコール管理番号を保存して、それがあればリコール対象、さらに済みフラグを立てれば完了、という運用がいいかな、と思います。
Offline
Shin様
ありがとうございます。
アドバイスを元に試行錯誤しながらやってみます。
Offline
Pages: 1
[ Generated in 0.005 seconds, 9 queries executed - Memory usage: 599.45 KiB (Peak: 616.35 KiB) ]