JP2002049698A - 医療データ配送システム - Google Patents

Abstract

(57)【要約】 【課題】医療情報システムで管理された検査結果等の医
療データを、結果参照用クライアントから参照するシス
テムでは、参照したい検査結果が未確定だった場合、検
査結果が確定するまで何度も参照しようとしなければな
らないという問題がある。 【解決手段】上記課題は、ユーザが要求した医療データ
が未確定だった場合、医療データが確定次第、医療デー
タを配送する手段を有するシステムにより解決できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ユーザの要求に応
じて医療データを配送する情報システムに関する。

【０００２】

【従来の技術】近年、医療情報システムで管理された検
査結果等の医療データを診察室や医局から電子データと
して参照したいという要望がある。このような要望に対
して、「高崎市医師会における情報ネットワーク構築に
ついて（医療とコンピュータVol.10 No.3 1999.3）」に
記載の検体検査システムのように、医師が結果参照用ク
ライアントを使用して、前記医療情報システムが管理す
る検査結果等の医療データを参照するシステムがある。

【０００３】

【発明が解決しようとする課題】しかし、上記システム
の場合、ユーザが参照したい検査結果等の医療データが
未確定だった場合、ユーザは医療データが確定するまで
何度も参照しようとしなければならないという問題があ
る。

【０００４】

【課題を解決するための手段】上記課題は、ユーザが参
照したい医療データが未確定だった場合、その要求が、
前記医療データが確定するまで受け付けられた状態にな
り、前記医療データが確定次第自動的に配送されるの
で、ユーザの利便性を向上しつつ、解決できる。

【０００５】また、上記課題は、ユーザが参照したい医
療データが未確定だった場合、未確定であることをユー
ザが即時に知ることができるので、ユーザの利便性を向
上しつつ、解決できる。

【０００６】また、上記課題は、ユーザの要求に応じた
医療データをユーザ毎に事前に登録された配送先アドレ
スに配送するので、患者のプライバシー情報の漏洩を防
止するセキュリティを向上しつつ、解決できる。

【０００７】また、上記課題は、電子メールで医療デー
タを配送することで、ユーザが時間や場所を問わずに医
療データを参照できるので、ユーザの利便性を向上しつ
つ、解決できる。

【０００８】また、上記課題は、電子メールでユーザの
要求を受け付けることで、ユーザが時間や場所を問わず
に参照したい医療データを要求できるので、ユーザの利
便性を向上しつつ、解決できる。

【０００９】また、上記課題は、要求内容の不備などが
原因で要求が受け付けられなかった場合、要求が受け付
けられなかったことをユーザが即時に知ることができる
ので、ユーザの利便性を向上しつつ、解決できる。

【００１０】

【発明の実施の形態】図1に、本発明の実施例である医
療データ配送システムの構成図を示す。

【００１１】本システムは、配送サーバ１００と、検査
結果等の医療データを格納する医療ＤＢ１４０と、ユー
ザを識別する情報を格納するユーザ情報ＤＢ１５０と、
要求された医療データが未確定だった場合にその要求を
格納する未処理要求ＤＢ１６０と、メールサーバ１３０
と、ユーザ端末２００と、ネットワーク３００と、ネッ
トワーク４００と、で構成される。

【００１２】前記ユーザ端末２００は、携帯電話、ＰＨ
Ｓ、ＰＤＡ、携帯型ＰＣなど、携帯可能な通信端末を想
定しているが、パソコンなどの設置型端末でもよい。

【００１３】前記ネットワーク３００は、インターネッ
トなどの広域なネットワークを想定しているが、院内Ｌ
ＡＮなどのローカルなネットワークでもよい。

【００１４】前記ネットワーク４００は、院内ＬＡＮな
どのローカルなネットワークを想定しているが、インタ
ーネットなどの広域なネットワークでもよい。また、前
記配送サーバ１００の一機能として前記配送サーバ１０
０に組み込んでもよい。前記配送サーバ１００は、制御
部１１０と、要求メール数確認部１１１と、要求メール
読み出し部１１２と、ユーザ認証部１１３と、要求内容
解析部１１４と、要求医療データ抽出部１１５と、結果
報告メール生成部１１６と、エラーメール生成部１１７
と、メール送信部１１８と、未処理要求ＤＢ制御部１２
０と、未処理要求ＤＢ登録部１２１と、登録要求数確認
部１２２と、未処理要求読み出し部１２３と、処理済要
求削除部１２４と、で構成される。

【００１５】前記未処理要求ＤＢ１６０は、要求ＩＤフ
ィールド１６１と、医療データ参照を要求したユーザを
識別するユーザＩＤを格納するユーザＩＤフィールド１
６２と、要求を格納する要求内容フィールド１６３と、
で構成される。図１では、未処理要求ＩＤ“０１”とし
て、ユーザＩＤ“Ｕ００１”のユーザが、患者を識別す
る患者ＩＤ“Ｐ００２”の患者の、検査日付“００／０
５／０２”に実施した検査の、検査項目“ＧＯＴ、ＧＰ
Ｔ”の結果の参照を要求したということを示す未処理要
求レコード１６４を格納している。

【００１６】図４に、前記医療ＤＢ１４０の例を示す。
前記医療ＤＢ１４０は、患者を識別する患者ＩＤを格納
する患者ＩＤフィールド１４１と、検査が実施された日
付を格納する検査日付フィールド１４２と、検査結果を
格納する検査結果フィールド１４３と、で構成される。
図４では、患者ＩＤ“Ｐ００１”の、検査日付“００／
０５／０１”に実施された検査結果が、“ＧＯＴ＝２
０，ＧＰＴ＝４５”であることを示しており、また、患
者ＩＤ“Ｐ００２”の、検査日付“００／０５／０２”
に実施された検査結果が、“ＧＯＴ＝２０，ＧＰＴ＝未
確定”であることを示している。

【００１７】前記医療ＤＢ１４０では、検査結果につい
ての情報を格納しているが、患者基本情報、検査画像情
報、診療情報、医事会計情報など、他の医療データを格
納してもよい。同様に、図１では検査結果の参照を要求
しているが、他の医療データの参照を要求してもよい。

【００１８】図５に、前記ユーザ情報ＤＢ１５０の例を
示す。前記ユーザ情報ＤＢ１５０は、ユーザを識別する
情報であるユーザＩＤを格納するユーザＩＤフィールド
１５１と、ユーザを認証するためのパスワードを格納す
るパスワードフィールド１５２と、医療データの配送先
を特定する配送先アドレスを格納する配送先アドレスフ
ィールド１５３と、で構成される。図７では、ユーザＩ
Ｄ“Ｕ００１”のユーザのパスワードが“ｐｗｄ００
１”で、配送先アドレスが“Ｕ００１＠・・・”である
ことを示している。

【００１９】図６に、前記メールサーバ１３０における
本システムのメールアドレスの例を示す。図６におい
て、前記メールサーバ１３０のメールボックス１３１に
おいて、ユーザは本システムの要求受付アドレス１３２
“Ｒｅｃｅｉｖｅ＠・・・”宛てに要求メール１３５を
送信し、前記配送サーバ１００が受け付ける。前記配送
サーバ１００は、前記要求受付アドレス１３２とは異な
る配送元アドレス１３３“Ｓｅｎｄ＠・・・”を送信元
として、前記要求メール１３５に応じた配送メール１３
６を送信する。また、図６では、前記配送元アドレス１
３２から送信した前記配送メール１３６に対する返信先
アドレス１３４が“Ｒｅｃｅｉｖｅ＠・・・”として設
定されており、前記配送メール１３６に対して返信する
と、その返信メールは自動的に前記要求受付アドレス１
３２宛てに送信する。

【００２０】本実施例では、電子メールで要求を受け付
けることを想定しているが、ｗｅｂブラウザからのデー
タ入力、プッシュ回線による数字のボタン入力、音声入
力など、電子メール以外の方法で入力された要求を受け
付けてもよい。

【００２１】図１において、ユーザは、前記ユーザ端末
２００を使用し、前記ネットワーク３００を通じ、医療
データ参照を要求する前記要求メール１３５を、本シス
テムの前記要求受付アドレス１３２宛てに送信する。こ
れにより、前記メールサーバ１３０は前記要求メール１
３５を前記メールボックス１３１に格納する。

【００２２】図７に、前記要求メール１３５の例である
要求メールＡの書式を示す。要求メールＡは、要求元ア
ドレス７０１と、要求先アドレス７０２と、主題７０３
と、本文７１０と、で構成される。前記本文７１０は、
ユーザＩＤ７０４と、パスワード７０５と、患者ＩＤ７
０６と、検査日付７０７と、結果の参照を要求する検査
項目７０８とで構成される。図７では、ユーザＩＤ“Ｕ
００１”のユーザが、患者ＩＤ“Ｐ００１”で識別され
る患者が検査日付“００／０５／０１”に受けた“ＧＯ
Ｔ”と“ＧＰＴ”の検査結果の参照を要求するメール
を、要求元アドレス“Ｕ００１＠・・・”から、要求先
アドレス“Ｒｅｃｅｉｖｅ＠・・・”（前記要求受付ア
ドレス）宛てに送信することを示している。

【００２３】図２に、本システムの動作を表すフローチ
ャートを示す。

【００２４】本システムが動作を開始すると、まず前記
制御部１１０が前記要求メール数確認部１１１を起動
し、前記ネットワーク４００を通じ、前記メールサーバ
１３０のメールボックス１３１に格納された本システム
の前記要求受付アドレス１３２宛ての要求メール数を確
認する要求メール数確認ステップ２０１を実行する。

【００２５】次に、前記制御部１１０は、前記要求メー
ル読み出し部１１２を起動し、前記メール１３１ボック
スから本システムの前記要求受付アドレス１３２宛ての
要求メールを読み出す要求メール読み出しステップ２０
３を実行する。

【００２６】次に、前記制御部１１０は前記ユーザ認証
部１１３を起動し、ユーザ認証ステップ２０４を実行す
る。

【００２７】前記ユーザ認証ステップ２０４でユーザ認
証された場合、前記制御部１１０は前記要求内容解析部
１１４を起動し、要求内容を解析する要求内容解析ステ
ップ２０５を実行する。

【００２８】前記要求内容解析ステップ２０５で要求内
容が解析された場合、前記制御部１１０は前記要求医療
データ抽出部１１５を起動し、要求医療データ抽出ステ
ップ２０６を実行する。

【００２９】前記要求医療データ抽出ステップ２０６
で、確定した要求医療データを前記医療ＤＢ１４０から
抽出することができた場合、前記制御部１１０は前記結
果報告メール生成部１１６を起動し、抽出した要求医療
データをメールに生成する結果報告メール生成ステップ
２０７を実行する。

【００３０】次に、前記制御部１１０は前記メール送信
部１１８を起動し、前記結果報告メール生成ステップ２
０７で生成された結果報告メールを、前記配送元アドレ
ス１３２を送信元として、前記ユーザ情報ＤＢ１５０に
登録された配送先アドレス宛てに送信するメール送信ス
テップ２１０を実行する。

【００３１】図８に要求医療データが確定していた場合
の結果報告メールＢの例を示す。前記結果報告メールＢ
は、配送元アドレス８０１と、配送先アドレス８０２
と、返信先アドレス８０３と、主題８０４と、本文８１
０とで構成される。前記本文８１０は、患者ＩＤ８０５
と、検査日付８０６と、検査結果８０７とで構成され
る。前記結果報告メールＢでは、患者ＩＤ“Ｐ００１”
で識別される患者が検査日付“００／０５／０１”に受
けた“ＧＯＴ”と“ＧＰＴ”の検査結果が、それぞれ
“２０”、“４５”であることを示し、配送先アドレス
“Ｕ００１＠・・・”宛てに送信することを示してい
る。

【００３２】また、図２において、前記要求医療データ
抽出ステップ２０６で抽出しようとした要求医療データ
が未確定であった場合、前記未処理要求ＤＢ制御部１２
０は前記未処理要求ＤＢ登録部１２１を起動し、未処理
要求ＤＢ登録ステップ２０９を実行する。

【００３３】これにより、ユーザが参照したい医療デー
タが未確定だった場合、その要求が、前記医療データが
確定するまで受け付けられた状態になるため、ユーザが
何度も参照しようとする必要がなく、ユーザの利便性を
向上することができる。

【００３４】次に、前記制御部１１０は、前記結果報告
メール生成部１１６を起動し、要求医療データが未確定
であることを伝えるメールに生成する結果報告メール生
成ステップ２０７を実行する。

【００３５】次に、前記制御部１１０は前記メール送信
部１１８を起動し、前記結果報告メール生成ステップ２
０７で生成された結果報告メールを前記ユーザ情報ＤＢ
１５０に登録された配送先アドレス宛てに送信するメー
ル送信ステップ２１０を実行する。

【００３６】これにより、ユーザが参照したい医療デー
タが未確定だった場合、未確定であることをユーザが即
時に知ることができ、ユーザの利便性を向上することが
できる。

【００３７】図９に要求医療データが未確定だった場合
の結果報告メールＣの例を示す。前記結果報告メールＣ
は、配送元アドレス９０１と、配送先アドレス９０２
と、返信先アドレス９０３と、主題９０４と、本文９１
０と、で構成される。前記本文９１０は、患者ＩＤ９０
５と、検査日付９０６と、検査結果９０７と、で構成さ
れる。前記結果報告メールＣでは、患者ＩＤ“Ｐ００
２”が、検査日付“００／０５／０２”に受けた“ＧＯ
Ｔ”と“ＧＰＴ”の検査結果が、それぞれ“２０”、
“？”（未確定の意味）であることを示し、配送先アド
レス“Ｕ００１＠・・・”宛てに送信することを示して
いる。

【００３８】また、図２において、前記ユーザ認証ステ
ップ２０４においてユーザ認証されなかった場合、ある
いは前記要求内容解析ステップ２０５において要求内容
に不備があり要求医療データを抽出できなかった場合に
は、前記制御部１１０は、前記エラーメール生成部１１
７を起動し、要求を受け付けられなかったことを伝える
メールに生成するエラーメール生成ステップ２０８を実
行する。

【００３９】次に、前記制御部１１０は、前記メール送
信部１１８を起動し、前記エラーメール生成ステップ２
０８で生成されたエラーメールを、要求元アドレス宛て
に返信するメール送信ステップ２１０を実行する。

【００４０】これにより、要求が受け付けられなかった
場合、要求が受け付けられなかったことをユーザが即時
に知ることができ、ユーザの利便性を向上することがで
きる。

【００４１】図１０に、要求が受け付けられなかった場
合のエラーメールＤの例を示す。前記エラーメールＤ
は、配送元アドレス１００１と、配送先アドレス１００
２と、返信先アドレス１００３と、主題１００４と、本
文１０１０と、で構成される。前記本文１０１０は、エ
ラーメッセージ１００５と、エラー内容１００６と、で
構成される。前記エラーメールＤでは、ユーザＩＤ“Ｕ
００１”をパスワード“ｐｗｄ００２”で認証しようと
したが認証できなかったことを示し、要求元アドレス宛
てに送信することを示している。

【００４２】前記エラーメールＤではユーザ認証時のエ
ラーを示しているが、要求された患者ＩＤが存在しなか
った場合や、要求された患者ＩＤと検査日付で検査が実
施されていなかった場合など、その他に原因があり要求
が受け付けられなかった場合でも、同様のエラーメール
を生成して送信するため、ユーザは即時に誤りに気付く
ことができる。

【００４３】また、前記ユーザ情報テーブルの配送先ア
ドレスが誤って登録されていた場合、本システムが送信
した結果報告メールは、エラーメールとして本システム
の前記配送元アドレス宛てに返信される。

【００４４】本システムでは、要求受付アドレスと配送
元アドレスの、異なる２つのアドレスを有しており、前
記要求受付アドレスに受信したメールのみ要求メールと
して処理し、前記配送元アドレス宛てに送信されたメー
ルの読み出しは行わない。

【００４５】このように、本システムは、受信したエラ
ーメールを要求メールとして処理しないので、エラーメ
ールの繰り返しによるシステムダウンを簡易に防止する
ことができる。

【００４６】また、要求受付アドレスと配送元アドレス
が同じシステムでもよい。その場合、受信したエラーメ
ールを要求メールとして解釈し、要求が受け付けられな
かったとして、新たにエラーメールを送信してしまわな
いように、エラーメールと要求メールを区別し、要求メ
ールのみを処理することで実現できる。

【００４７】また、前記配送元アドレスが送信したメー
ルに対する前記返信先アドレスとして、前記要求元アド
レスが設定されているため、ユーザが繰り返し本システ
ムへ要求メールを送信しようとした場合、前記配送元ア
ドレスからの結果報告メールやエラーメールに対してメ
ールの返信機能を利用することで、要求メールを容易に
送信することができ、ユーザの利便性を向上することが
できる。

【００４８】以上の処理が終了すると、前記制御部１１
０はメール数ループステップ２０２を実行する。前記要
求メール数確認ステップ２０１で確認したメール全ての
処理が終わると、前記未処理要求ＤＢ制御部１２０が、
未処理要求ＤＢ処理サブルーチン２１１を実行する。

【００４９】本実施例では、前記メール数ループステッ
プ２０２を実行し、前記要求メール数確認ステップ２０
１で確認したメール全ての処理が終わってから、前記未
処理要求ＤＢ処理サブルーチン２１１を実行している
が、未確定だった検査結果が確定し、前記医療ＤＢ１４
０に検査結果が登録されると同時に、前記未処理要求Ｄ
Ｂ処理サブルーチン２１１を実行してもよい。

【００５０】図３に、前記未処理要求ＤＢ処理サブルー
チン２１１を実行するときの本システムの動作を表すフ
ローチャートを示す。

【００５１】前記未処理要求ＤＢ処理サブルーチン２１
１では、まず前記未処理要求ＤＢ制御部１２０が、登録
要求数確認部１２２を起動し、前記未処理要求ＤＢ１６
０に登録されている要求数を確認する登録要求数確認ス
テップ３０１を実行する。

【００５２】次に、前記未処理要求ＤＢ制御部１２０
は、前記未処理要求読み出し部１２３を起動し、前記未
処理要求ＤＢ１６０から登録された要求を読み出す未処
理要求読み出しステップ３０３を実行する。

【００５３】次に、前記制御部１１０が、前記要求医療
データ抽出部１１５を起動し、要求医療データ抽出ステ
ップ３０４を実行する。

【００５４】前記要求医療データ抽出ステップ３０４
で、前記医療ＤＢ１４０から確定した要求医療データを
抽出できた場合、前記制御部１１０は、前記結果報告メ
ール生成部１１６を起動し、抽出した要求医療データを
メールに生成する結果報告メール生成ステップ３０５を
実行する。

【００５５】次に、前記制御部１１０は、前記メール送
信部１１８を起動し、前記結果報告メール生成ステップ
３０５で生成された結果報告メールを、前記ユーザ情報
ＤＢ１５０に登録された配送先アドレス宛てに送信する
メール送信ステップ３０６を実行する。

【００５６】これにより、ユーザが参照したい医療デー
タが要求当時未確定だった場合でも、前記医療データが
確定次第自動的に配送されるため、ユーザの利便性を向
上することができる。

【００５７】図１１に、要求受付時は未確定だった要求
医療データが確定した場合の、結果報告メールＥの例を
示す。前記結果報告メールＥは、配送元アドレス１１０
１と、配送先アドレス１１０２と、返信先アドレス１１
０３と、主題１１０４と、本文１１１０と、で構成され
る。前記本文１１１０は、患者ＩＤ１１０５と、検査日
付１１０６と、検査結果１１０７と、で構成される。前
記結果報告メールＥでは、前記結果報告メールＣ（図
９）で未確定であった“ＧＰＴ”の検査結果が“５０”
に確定したことを示している。

【００５８】図１１において、前記結果報告メールＥで
は、前記結果報告メールＣ（図９）で既に報告した“Ｇ
ＯＴ＝２０”という検査結果も再度報告しているが、未
確定だった“ＧＰＴ”の検査結果のみを報告してもよ
い。

【００５９】次に、前記未処理要求ＤＢ制御部１２０
が、前記処理済要求削除部１２４を起動し、前記未処理
要求読み出しステップ３０２で読み出された要求に対
し、前記未処理要求ＤＢ１６０の前記未処理要求レコー
ド１６４を削除する処理済要求削除ステップ３０７を実
行する。

【００６０】また、前記要求医療データ抽出ステップ３
０４で、抽出しようとした要求医療データが未確定であ
った場合、登録はそのまま保存される。

【００６１】以上の処理が終了すると、前記未処理要求
ＤＢ制御部１２０は、登録数ループステップ３０２を実
行する。前記登録要求数確認ステップ３０１で確認した
要求全ての処理が終わると、前記未処理要求ＤＢ処理サ
ブルーチン２１１は終了する。

【００６２】次に、本システムはｓｌｅｅｐステップ２
１２を実行して一定時間停止し、その後再び各処理が繰
り返し実行される。

【００６３】

【発明の効果】以上のように、本システムでは、ユーザ
が参照を要求した医療データが未確定だった場合、ユー
ザＩＤと要求内容を未処理要求として保存し、前記医療
データが確定次第、ユーザ毎に事前に登録された配送先
アドレス宛てに、前記ユーザにより要求された医療デー
タを配送する。

【００６４】これにより、ユーザが参照を要求した医療
データが未確定だった場合、その要求は前記医療データ
が確定するまで受け付けられた状態になり、前記医療デ
ータが確定次第、ユーザ毎に事前に登録された配送先ア
ドレス宛てに自動的に配送されるので、ユーザが何度も
参照する必要がなく、ユーザの利便性を向上することが
できる。

【００６５】また、ユーザが参照を要求した医療データ
が未確定だった場合、ユーザ毎に事前に登録された配送
先アドレス宛てに、要求した医療データが未確定である
ことを伝える電子メールを送信するので、ユーザは要求
した医療データが未確定であることを即時に知ることが
でき、ユーザの利便性を向上することができる。

【００６６】また、要求元に関わらず、ユーザの要求に
応じた医療データをユーザ毎に事前に登録された配送先
アドレスに配送するので、患者のプライバシー情報の漏
洩を防止することができる。

【００６７】また、電子メールで医療データを配送する
ことで、ユーザが時間や場所を問わずに医療データを参
照できるので、ユーザの利便性を向上することができ
る。

【００６８】また、電子メールでユーザの要求を受け付
けることで、ユーザが時間や場所を問わずに参照したい
医療データを要求できるので、ユーザの利便性を向上す
ることができる。

【００６９】また、ユーザ認証されなかった場合や、要
求内容に不備があった場合など、要求が受け付けられな
かった場合には、要求が受け付けられなかったことを示
すエラーメールを、要求メールを送信した要求メール送
信元アドレスに送信することで、ユーザは要求が受け付
けられなかったことを即時に知ることができ、ユーザの
利便性を向上することができる。

【００７０】また、本システムは、要求を受け付ける要
求受付アドレスと電子メールを配送する配送元アドレス
の、２つの異なるアドレスを使用するので、要求に応じ
た医療データを配送する配送先アドレスが誤って登録さ
れていた場合に、送信先不明のエラーメールを要求メー
ルと解釈して読み出すことがないので、エラーメールの
繰り返しによるシステムダウンを防止することができ
る。

【図面の簡単な説明】

【図１】本発明の実施例である医療データ配送システム
の構成図。

【図２】本システムの動作を表すフローチャート。

【図３】未処理要求ＤＢを処理するときの本システムの
動作を表すフローチャート。

【図４】医療ＤＢの例。

【図５】ユーザ情報ＤＢの例。

【図６】本システムの持つ２つの電子メールアドレスの
例。

【図７】ユーザが医療データの参照を要求する電子メー
ルの例。

【図８】要求医療データが確定していた場合に配送され
る電子メールの例。

【図９】要求医療データが未確定だった場合に配送され
る電子メールの例。

【図１０】要求が受け付けられなかった場合に配送され
る電子メールの例。

【図１１】要求受け付け時に未確定だった医療データが
確定した場合に配送される電子メールの例。

【符号の説明】

１００：配送サーバ、１３０：メールサーバ、１４０：
医療ＤＢ、１５０：ユーザ情報ＤＢ、１６０：未処理要
求ＤＢ、２００：ユーザ端末、３００：ネットワーク、
４００：ネットワーク １１０：制御部、１１１：要求メール数確認部、１１
２：要求メール読み出し部、１１３：ユーザ認証部、１
１４：要求内容解析部、１１５：要求医療データ抽出
部、１１６：結果報告メール生成部、１１７：エラーメ
ール生成部、１１８：メール送信部、１２０：未処理要
求ＤＢ制御部、１２１：未処理要求ＤＢ登録部、１２
２：登録要求数確認部、１２３：未処理要求読み出し
部、１２４：処理済要求削除部、１３１：メールボック
ス、１３２：要求受付アドレス、１３３：配送元アドレ
ス、１３４：返信先アドレス、１３５：要求メール、１
３６：配送メール、１４１：患者ＩＤフィールド、１４
２：検査日付フィールド、１４３：検査結果フィール
ド、１５１：ユーザＩＤフィールド、１５２：パスワー
ドフィールド、１５３：配送先アドレスフィールド、１
６１：要求ＩＤフィールド、１６２：ユーザＩＤフィー
ルド、１６３：要求内容フィールド、１６４：未処理要
求レコード、２０１：要求メール数確認ステップ、２０
２：メール数ループステップ、２０３：要求メール読み
出しステップ、２０４：ユーザ認証ステップ、２０５：
要求内容解析ステップ、２０６：要求医療データ抽出ス
テップ、２０７：結果報告メール生成ステップ、２０
８：エラーメール生成ステップ、２０９：未処理要求Ｄ
Ｂ登録ステップ、２１０：メール送信ステップ、２１
１：未処理要求ＤＢ処理サブルーチン、２１２：ｓｌｅ
ｅｐステップ、３０１：登録要求数確認ステップ、３０
２：登録数ループステップ、３０３：未処理要求読み出
しステップ、３０４：要求医療データ抽出ステップ、３
０５：結果報告メール生成ステップ、３０６：メール送
信ステップ、３０７：処理済要求削除ステップ、７０
１：要求元アドレス、７０２：要求先アドレス、７０
３：主題、７０４：ユーザＩＤ、７０５：パスワード、
７０６：患者ＩＤ、７０７：検査日付、７０８検査項
目、７１０ 本文、８０１：配送元アドレス、８０２：
配送先アドレス、８０３：返信先アドレス、８０４：主
題、８０５：患者ＩＤ、８０６：検査日付、８０７：検
査結果、８１０：本文、９０１：配送元アドレス、９０
２：配送先アドレス、９０３：返信先アドレス、９０
４：主題、９０５：患者ＩＤ、９０６：検査日付、９０
７：検査結果、９１０：本文、１００１：配送元アドレ
ス、１００２：配送先アドレス、１００３：返信先アド
レス、１００４：主題、１００５：エラーメッセージ、
１００６：エラー内容、１０１０：本文、１１０１：配
送元アドレス、１１０２：配送先アドレス、１１０３：
返信先アドレス、１１０４ 主題、１１０５：患者Ｉ
Ｄ、１１０６：検査日付、１１０７：検査結果、１１１
０：本文。

フロントページの続き (72)発明者 光山 訓 東京都国分寺市東恋ケ窪一丁目280番地 株式会社日立製作所中央研究所内 (72)発明者 島田 和之 東京都国分寺市東恋ケ窪一丁目280番地 株式会社日立製作所中央研究所内 Ｆターム(参考） 5B049 BB41 CC22 DD01 DD05 EE07 FF03 FF04 FF09 GG04 GG06 GG07

Claims (7)

【特許請求の範囲】
1. 【請求項１】ユーザの要求により医療データを配送する
   医療データ配送システムであって、ユーザが要求した医
   療データが未確定の場合、前記医療データが確定次第、
   前記医療データをユーザ宛てに配送する手段を有するこ
   とを特徴とする医療データ配送システム。
2. 【請求項２】請求項１に記載の医療データ配送システム
   であって、前記ユーザが要求した医療データが未確定の
   場合、要求した医療データが未確定であることをユーザ
   宛てに即時に配送する手段を有することを特徴とする医
   療データ配送システム。
3. 【請求項３】請求項１から２に記載の医療データ配送シ
   ステムであって、ユーザを識別するユーザＩＤと、ユー
   ザの要求に応じて医療データを配送するときの配送先を
   特定する配送先ユーザアドレスとを格納するユーザ情報
   データベースを有することを特徴とする医療データ配送
   システム。
4. 【請求項４】請求項１から３に記載の医療データ配送シ
   ステムであって、電子メールにより医療データを配送す
   ることを特徴とする医療データ配送システム。
5. 【請求項５】請求項１から４に記載の医療データ配送シ
   ステムであって、ユーザの要求を電子メールにより受け
   付ける手段を有することを特徴とする医療データ配送シ
   ステム。
6. 【請求項６】請求項５に記載の医療データ配送システム
   であって、要求内容の不備等で要求が受け付けられなか
   った場合、要求内容を記述した電子メールの送信元アド
   レスに、要求が受け付けられなかったことを示す電子メ
   ールを即時に配送する手段を有することを特徴とする医
   療データ配送システム。
7. 【請求項７】電子メールによりユーザの要求を受け付け
   る手段と、電子メールにより医療データを配送する手段
   と、を有する医療データ配送システムであって、要求を
   受け付ける要求受付アドレスと電子メールを配送する配
   送元アドレスとが異なることを特徴とする医療データ配
   送システム。