(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-02-01
(54)【発明の名称】クラウド基盤の電子処方送信システム及び方法
(51)【国際特許分類】
G16H 20/00 20180101AFI20220125BHJP
【ＦＩ】
G16H20/00
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2021529692
(86)(22)【出願日】2019-05-17
(85)【翻訳文提出日】2021-05-24
(86)【国際出願番号】 KR2019005955
(87)【国際公開番号】W WO2020105823
(87)【国際公開日】2020-05-28
(31)【優先権主張番号】10-2018-0146440
(32)【優先日】2018-11-23
(33)【優先権主張国・地域又は機関】KR
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
２．Ｅｎｔｒａ
(71)【出願人】
【識別番号】521225155
【氏名又は名称】レモン ヘルスケア リミテッド
【氏名又は名称原語表記】ＬＥＭＯＮ ＨＥＡＬＴＨＣＡＲＥ ＬＴＤ
【住所又は居所原語表記】＃１００５（Ｇａｓａｎ－ｄｏｎｇ），１４５，Ｇａｓａｎ ｄｉｇｉｔａｌ １－ｒｏ，Ｇｅｕｍｃｈｅｏｎ－ｇｕ，Ｓｅｏｕｌ ０８５０６，Ｒｅｐｕｂｌｉｃ ｏｆ Ｋｏｒｅａ
(74)【代理人】
【識別番号】100130111
【弁理士】
【氏名又は名称】新保 斉
(72)【発明者】
【氏名】ホン、ビョン ジン
(72)【発明者】
【氏名】ソ、ギョン ヒ
【テーマコード（参考）】
5L099
【Ｆターム（参考）】
5L099AA25
(57)【要約】
クラウド基盤の電子処方送信システム及び方法に関する。クラウドサーバがユーザ端末から電子処方の要請を受けると、病院サーバに電子処方を要請するステップと、前記病院サーバがＥＭＲ ＤＢ部に格納された患者情報及び処方情報を抽出し、ＡＰＩビルダー部で固有のＡＰＩによって前記処方情報を変換するステップと、前記病院サーバが変換された処方情報に病院電子署名を介して認証し、前記変換された処方情報を暗号化して、前記クラウドサーバに電子処方を送信するステップとを含む。
【選択図】図１
【選択図】図１
【特許請求の範囲】
【請求項1】
クラウド基盤の電子処方送信方法において、クラウドサーバがユーザ端末から電子処方の要請を受けると、病院サーバに電子処方を要請するステップと、
前記病院サーバがＥＭＲ ＤＢ部に格納された患者情報及び処方情報を抽出し、ＡＰＩビルダー部で固有のＡＰＩによって前記処方情報を変換するステップと、
前記病院サーバが変換された処方情報に病院電子署名を介して認証し、前記変換された処方情報を暗号化して、前記クラウドサーバに電子処方を送信するステップと、を含む
ことを特徴とするクラウド基盤の電子処方送信方法。
【請求項2】
前記クラウドサーバがＱＲコード（登録商標）を生成し、ユーザ端末から薬局が選択されれば、前記電子処方を仮に格納するステップと、前記クラウドサーバが前記ＱＲコード（登録商標）、前記電子処方、選択された薬局に関する薬局情報のうち、少なくとも１つを薬局サーバに送信するステップと、をさらに含む
請求項１に記載のクラウド基盤の電子処方送信方法。
【請求項3】
前記薬局サーバが前記電子処方を確認し、調剤可否を判断して調剤が行われれば、薬剤費を計算するステップと、前記薬局サーバが前記クラウドサーバに決済を要請し、前記クラウドサーバが、ユーザ端末から決済が完了すれば、決済完了を前記薬局サーバに送信するステップと、をさらに含む
請求項２に記載のクラウド基盤の電子処方送信方法。
【請求項4】
前記薬局サーバが、調剤が進まれ、調剤が完了すれば、前記クラウドサーバに調剤完了を知らせ、前記クラウドサーバが薬受領完了を薬局サーバに知らせるステップと、前記薬局サーバは、前記電子処方を格納し、前記クラウドサーバは、前記電子処方を削除するステップと、をさらに含む
請求項３に記載のクラウド基盤の電子処方送信方法。
【請求項5】
ＡＰＩビルダー部で前記処方情報を変換するステップにおいて、データソースを生成し、ＳＱＬクエリ作成ガイドを介しての簡便作成とＡＰＩビルダーを介しての標準データへの変換後、繰り返し検証を介して進行する請求項１に記載のクラウド基盤の電子処方送信方法。
【請求項6】
クラウド基盤の電子処方送信システムにおいて、ユーザ端末から電子処方の要請を受けると、病院サーバに電子処方を要請し、前記病院サーバから電子処方を受信すれば、生成されたＱＲコード（登録商標）、ユーザ端末から選択された薬局に関する情報、前記電子処方のうち、少なくとも１つを薬局サーバに送信し、ユーザ端末が薬を受領すれば、前記電子処方を削除するクラウドサーバと、
前記クラウドサーバから電子処方の要請を受けると、ＥＭＲ ＤＢ部から患者情報と処方情報とを抽出し、ＡＰＩビルダー部で固有のＡＰＩを利用して処方情報を変換し、変換された処方情報に病院電子署名を認証し、前記処方情報を暗号化して電子処方を前記クラウドサーバに送信する病院サーバと、
前記クラウドサーバからＱＲコード（登録商標）、電子処方、薬局情報のうち、少なくとも１つを受信すれば、前記電子処方を確認し、調剤可否を判断して薬剤費を計算した後、前記クラウドサーバに決済要請し、薬受領完了報知を受信すれば、前記電子処方を格納する薬局サーバと、を備える
ことを特徴とするクラウド基盤の電子処方送信システム。
【請求項7】
前記ＡＰＩビルダー部は、前記ＥＭＲ ＤＢ部から患者情報と処方情報とを受信してデータソースを生成する生成モジュールと、
ＳＱＬクエリを作成してテストモジュールに伝達するＳＱＬ作成モジュールと、を備える
請求項６に記載の電子処方送信システム。
【請求項8】
前記クラウドサーバは、電子処方格納部を備え、前記電子処方格納部は、病院サーバから電子処方を受信すれば、仮に格納してからユーザ端末から薬が受領されれば、格納した電子処方を削除する
請求項６に記載の電子処方送信システム。
【請求項9】
前記薬局サーバは、処方情報に基づいて薬剤費を計算する薬剤計算部と、
受信された電子処方を確認して調剤可否を判断する電子処方確認部と、を備える
請求項６に記載の電子処方送信システム。
【請求項10】
薬受領完了報知を受信すれば、薬局保管用電子処方を薬局電子署名して電子処方保管部に格納する薬剤電子署名部をさらに備える請求項９に記載の電子処方送信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、クラウド基盤の電子処方送信システム及び方法に関し、特に、クラウドコンピューティング環境でユーザに電子処方を提供し、ユーザがアプリケーション上で直接薬局を選択し、処方せんを薬局に送信可能なクラウド基盤の電子処方送信システム及び方法である。
【背景技術】
【0002】
紙の処方せんを持参して薬局に直接提出する場合には、医師が記録した処方医薬品の識別問題、処方または調剤エラーによる問題発生の責任所在などが不透明であり、患者の立場では、不便かつ面倒であって、近年、電子処方せんサービスが提案されている。
【0003】
一方、従来の電子処方せんサービスは、病院でユーザ端末機に患者保管用電子処方せんを送信すれば、ユーザが薬局に直接行ってユーザ端末機を見せるか、ＱＲコード（登録商標）を用いて薬を調剤してもらうので、依然として不便な点が多い。また、病院の閉鎖的なシステムと劣悪な情報保安の解決方案としてクラウド技術導入が求められているが、適用した事例が足りない。
【0004】
先行技術では、特許文献１があるが、固有情報を生成して、電子処方せんを患者の携帯電話端末に送信する技術を開示しているだけである。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】登録特許第１０－１３２９００３号（電子処方せんの患者用、薬局用伝達方法、これを行う患者クライアント装置及び中継装置）
【発明の概要】
【発明が解決しようとする課題】
【0006】
本発明が解決しようとする課題は、標準化ＡＰＩを介して病院サーバのＤＢＭＳと開発言語の種類に関係なく、電子処方の生成が可能であり、クラウドコンピューティング環境で電子処方提供が可能なクラウド基盤の電子処方送信システム及び方法を提供できる。
【課題を解決するための手段】
【0007】
本発明の実施形態に係るクラウド基盤の電子処方送信方法は、クラウドサーバがユーザ端末から電子処方の要請を受けると、病院サーバに電子処方を要請するステップと、前記病院サーバがＥＭＲ ＤＢ部に格納された患者情報及び処方情報を抽出し、ＡＰＩビルダー部で固有のＡＰＩによって前記処方情報を変換するステップと、前記病院サーバが変換された処方情報に病院電子署名を介して認証し、前記変換された処方情報を暗号化して、前記クラウドサーバに電子処方を送信するステップとを含む。
【0008】
本発明の実施形態に係るクラウド基盤の電子処方送信システムは、ユーザ端末から電子処方の要請を受けると、病院サーバに電子処方を要請し、前記病院サーバから電子処方を受信すれば、生成されたＱＲコード（登録商標）、ユーザ端末から選択された薬局に関する情報、前記電子処方のうち、少なくとも１つを薬局サーバに送信し、ユーザ端末が薬を受領すれば、前記電子処方を削除するクラウドサーバと、前記クラウドサーバから電子処方の要請を受けると、ＥＭＲ ＤＢ部から患者情報と処方情報とを抽出し、ＡＰＩビルダー部で固有のＡＰＩを利用して処方情報を変換し、変換された処方情報に病院電子署名を認証し、前記処方情報を暗号化して電子処方を前記クラウドサーバに送信する病院サーバと、前記クラウドサーバからＱＲコード（登録商標）、電子処方、薬局情報のうち、少なくとも１つを受信すれば、前記電子処方を確認し、調剤可否を判断して薬剤費を計算した後、前記クラウドサーバに決済要請し、薬受領完了報知を受信すれば、前記電子処方を格納する薬局サーバとを備える。
【発明の効果】
【0009】
本発明によれば、標準化ＡＰＩを介して病院サーバの異種ＤＢＭＳと開発言語の種類に関係なく、電子処方を生成することができる。
【0010】
また、本発明によれば、ユーザ端末機を利用して処方せんを受領し、薬局に伝達して処方せん受領のための待機時間、調剤時間、薬受領待機時間を短縮でき、ユーザ便宜性が高い。さらに、ユーザがモバイル端末機を介して処方せん照会及び薬代決済が可能である。
【図面の簡単な説明】
【0011】
【図1】本発明の実施形態に係るクラウド基盤の電子処方送信方法を説明する順序図である。
【図2】本発明の実施形態に係る電子処方送信システムの構成図である。
【図3】本発明の実施形態に係るＡＰＩビルダー部の動作方法を説明する順序図である。
【図4】本発明の実施形態に係るＡＰＩビルダー部の動作方法を説明する順序図である。
【図5】本発明の実施形態に係るＡＰＩビルダー部の構成図である。
【発明を実施するための形態】
【0012】
本明細書に開示されている本発明の概念による実施形態等についての特定の構造的または機能的説明は、単に本発明の概念による実施形態等を説明するための目的として例示されたものであって、本発明の概念による実施形態等は、様々な形態で実施されることができ、本明細書に説明された実施形態等に限定されない。
【0013】
本発明の概念による実施形態等は、様々な変更を加えることができ、種々の形態を有することができるので、実施形態等を図面に例示し、本明細書において詳細に説明しようとする。しかしながら、これは、本発明の概念による実施形態等を特定の開示形態等に対して限定しようとするものではなく、本発明の思想及び技術範囲に含まれるあらゆる変更、均等物、または代替物を含む。
【0014】
本明細書において使用した用語は、単に特定の実施形態を説明するために使用されたものであって、本発明を限定しようとする意図ではない。単数の表現は、文脈上明白に異なるように意味しない限り、複数の表現を含む。本明細書において、「含む」または「有する」などの用語は、本明細書に記載された特徴、数字、ステップ、動作、構成要素、部分品、またはこれらを組み合わせたものが存在することを指定しようとするものであり、１つまたはそれ以上の他の特徴や数字、ステップ、動作、構成要素、部分品、またはこれらを組み合わせたものなどの存在または付加可能性を予め排除しない。
【0015】
以下、本明細書に添付された図面を参照して本発明の実施形態等を詳細に説明する。
【0016】
図１は、本発明の実施形態に係るクラウド基盤の電子処方送信方法を説明する順序図である。
【0017】
図１に示すように、クラウド基盤の電子処方送信方法は、クラウドサーバ１００がユーザ端末４００から電子処方の要請を受けると、病院サーバ２００に電子処方を要請する（Ｓ１０１）。
【0018】
病院サーバ２００がＥＭＲ ＤＢ部２１０に格納された患者情報及び処方情報を抽出し（Ｓ１０３）、ＡＰＩビルダー部２２０でＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）によって前記処方情報を変換する（Ｓ１０５）。このとき、前記ＡＰＩは、異機種のＤＢＭＳ（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）と開発言語の種類に関係なく、標準化された処方情報に変換することができる標準化ＡＰＩである。ＡＰＩビルダー部２２０は、処方情報などの病院サーバ内のデータベース情報を標準化するためのＡＰＩを生成、管理、及びテストすることができる。ＡＰＩビルダー部２２０は、病院サーバ内に設けられて動作することができるが、これに対して限定するものではない。ＡＰＩビルダー部２２０は、ＥＭＲ ＤＢ部から処方情報を抽出してデータソースを生成し、ＳＱＬクエリを作成して、テストを繰り返し進行して処方情報を変換する。
【0019】
病院サーバ２００が変換された処方情報に病院電子署名を介して認証し（Ｓ１０７）、前記変換された処方情報を暗号化する（Ｓ１０９）。病院サーバ２００が電子処方をクラウドサーバ１００に送信する（Ｓ１１１）。前記電子処方は、変換された処方情報と患者情報とが含まれる。
【0020】
クラウドサーバ１００がＱＲコード（登録商標）を生成し（Ｓ１１３）、ユーザ端末４００から薬局が選択されれば（Ｓ１１５）、前記電子処方を仮に格納する（Ｓ１１７）。このとき、前記ＱＲコード（登録商標）は、処方情報の位置情報を提供するハッシュコードに代替されることができる。クラウドサーバ１００が前記ＱＲコード（登録商標）、前記電子処方、選択された薬局に関する薬局情報のうち、少なくとも１つを薬局サーバ３００に送信する（Ｓ１１９）。
【0021】
薬局サーバ３００が前記電子処方を確認し（Ｓ１２１）、調剤可否を判断し（Ｓ１２３）、調剤が行われれば、薬剤費を計算する（Ｓ１２５）。
【0022】
薬局サーバ３００がクラウドサーバ１００に決済を要請し（Ｓ１２７）、クラウドサーバ１００が、ユーザ端末４００から決済が完了すれば、決済完了を薬局サーバ３００に送信する（Ｓ１３１）。
【0023】
薬局サーバ３００が、調剤が進まれ（Ｓ１３３）、調剤が完了すれば、クラウドサーバ１００に調剤完了を知らせ（Ｓ１３５）、クラウドサーバ１００が薬受領完了を薬局サーバ３００に知らせれば（Ｓ１３９）、薬局サーバ３００は、前記電子処方を格納し、クラウドサーバ１００は、前記電子処方を削除する（Ｓ１４３）。
【0024】
すなわち、本発明は、クラウドサーバを介して処方情報を伝達し、オンライン上でいつ、どこでも利用することができ、クラウドサーバ上では、薬調剤が完了すれば、電子処方が削除されて保安性が高い。また、病院における処方せん受領、薬局調剤時間、薬受領待機時間を短縮でき、さらに、薬代決済が可能であって、ユーザ便宜性を高めることができる。
【0025】
図２は、本発明の実施形態に係る電子処方送信システムの構成図である。
【0026】
図２に示すように、電子処方送信システム１０は、クラウドサーバ１００、病院サーバ２００、薬局サーバ３００、ユーザ端末４００で構成される。ユーザ端末４００が電子処方を要請すれば、クラウドサーバ１００は、病院サーバ２００に電子処方を要請し、病院サーバ２００は、標準化ＡＰＩを利用して処方情報を変換し、暗号化して電子処方をクラウドサーバ１００に提供する。クラウドサーバ１００は、薬局サーバ３００に電子処方を伝達して、薬調剤、決済機能を行う。
【0027】
クラウドサーバ１００は、電子処方送受信部１１０、決済部１２０、認証部１３０、電子処方格納部１４０、ＱＲコード（登録商標）生成部１５０、通信部１６０、制御部１７０を備える。
【0028】
電子処方送受信部１１０は、ユーザ端末４００から電子処方が要請されれば、病院サーバ２００に電子処方を要請することができる。また、病院サーバ２００から電子処方を受信すれば、薬局サーバ３００に伝達することができる。決済部１２０は、薬局サーバ３００から薬剤費決済要請を受信すれば、ユーザ端末に決済サービスを提供できる。決済が完了すれば、薬局サーバ３００に決済完了を送信できる。認証部１３０は、ユーザ端末４００から受信された個人情報と病院サーバから受信された患者情報とを比較して認証をすることができる。電子処方格納部１４０は、病院サーバ２００から電子処方を受信すれば、仮に格納してから、ユーザ端末から薬が受領されれば、格納した電子処方を削除して保安性を強化することができる。ＱＲコード（登録商標）生成部１５０は、受信された電子処方に対応するＱＲコード（登録商標）を生成して薬局サーバ３００に送信することができる。このとき、ＱＲコード（登録商標）生成部１５０は、処方情報の位置情報を提供するハッシュコードを生成して提供することができる。通信部１６０は、病院サーバ２００、薬局サーバ３００、及びユーザ端末４００と有無線ネットワークを利用して通信することができる。制御部１７０は、クラウドサーバの各構成を制御できる。
【0029】
病院サーバ２００は、ＥＭＲ ＤＢ部２１０、ＡＰＩビルダー部２２０、病院電子署名部２３０、暗号化部２４０、通信部２５０、制御部２６０を備える。
【0030】
ＥＭＲ ＤＢ部２１０には、患者情報、診療情報、処方情報、医事情報、履歴情報が格納され得る。ＥＭＲ ＤＢ部２１０に格納される情報の種類が制限されるものではない。
【0031】
ＡＰＩビルダー部２２０は、ＥＭＲ ＤＢ部２１０から患者情報と処方情報とを抽出し、ＡＰＩを利用して処方情報と患者情報とを変換する。すなわち、ＡＰＩビルダー部でデータソースを生成し、ＳＱＬクエリ作成ガイドを介しての簡便作成とＡＰＩビルダーを介しての標準データへの変換後、繰り返し検証を介して進行することができる。これを介して異種ＤＢＭＳ間のデータと互いに異なる開発言語で開発されたデータとを標準化することができる。
【0032】
病院電子署名部２３０は、変換された処方情報に病院電子署名を介して認証を行う。暗号化部２４０は、変換された処方情報を暗号化して保安性を高めることができ、通信部２５０は、クラウドサーバ１００とデータを送受信でき、制御部２６０は、病院サーバの各構成を制御できる。
【0033】
薬局サーバ３００は、薬剤計算部３１０、電子処方確認部３２０、薬剤電子署名部３３０、電子処方保管部３４０、通信部３５０、制御部３６０を備える。
【0034】
薬剤計算部３１０は、処方情報に基づいて薬剤費を計算し、クラウドサーバ１００に要請することができる。電子処方確認部３２０は、受信された電子処方を確認して調剤可否を判断できる。薬剤電子署名部３３０は、薬局保管用電子処方を薬局電子署名して電子処方保管部３４０に格納することができる。通信部３５０は、クラウドサーバ１００とデータを送受信でき、制御部は、薬局サーバの各構成を制御できる。
【0035】
【0036】
図３と図４に示すように、ＡＰＩビルダー部は、アプリケーションサーバを構築する（Ｓ３０１）。ＡＰＩを開発し（Ｓ３０３）、ＨＴＴＰ要請を分析する（Ｓ３０５）。このとき、アプリケーションサーバは、ＩＩＳ、Ｔｏｍｃａｔ Ｔｕｘｅｄｏ、Ｅｎｔｒａ等で構築されることができるが、これに対して限定するものではない。前記ＡＰＩは、ＲＥＳＴ ＡＰＩであって、Ｎｅｔ ＡＳＰ、Ｊａｖａ、Ｃ言語で実現されることができる。
【0037】
その後、ＥＭＲ ＤＢから情報を受信してデータソースを生成し（Ｓ３０７）、ビジネスロジックを開発する（Ｓ３０９）。その後、ＳＱＬ文を呼び出し、クエリ結果を収集し、ＨＴＴＰ応答を作成する（Ｓ３１３）。テストを介して基準を満たすと終了するか、基準を満たすことができなければ、再度ビジネスロジック開発段階に戻る。
【0038】
また、他の実施形態においてＡＰＩビルダー部は、ＡＰＩ道具を設け（Ｓ４０１）、データソースを生成する（Ｓ４０２）。その後、ＳＱＬクエリを作成し（Ｓ４０３）、テストを繰り返す（Ｓ４０５）。
【0039】
図５は、本発明の実施形態に係るＡＰＩビルダー部の構成図である。
【0040】
図５に示すように、ＡＰＩビルダー部２２０は、生成モジュール２２１、ＳＱＬ作成モジュール２２２、テストモジュール２２３、分析モジュール２２４、収集モジュール２２５、制御モジュール２２６を備える。生成モジュール２２１は、ＥＭＲ ＤＢ部２１０内に格納された患者情報、診療情報、処方情報、医事情報、履歴情報のうち、患者情報と処方情報とを受信してデータソースを生成する。ＳＱＬ作成モジュール２２２は、ＳＱＬクエリを作成し、テストモジュール２２３に伝達してテストを行うことができる。分析モジュール２２４は、ＨＴＴＰ要請を分析することができる。収集モジュール２２５は、クエリ結果を収集し、ＨＴＴＰ応答を作成できる。制御モジュール２２６は、ＡＰＩビルダー部２２０の各モジュールを制御できる。すなわち、ＥＭＲ ＤＢ部２１０からデータが伝送され、ＡＰＩビルダー部２２０により標準化された出力形式にデータを変換することができる。
【0041】
発明は、図面に示された実施形態を参考に説明されたが、これは、例示的なものに過ぎず、本技術分野における通常の知識を有する者であれば、これから様々な変形及び均等な他の実施形態が可能である。したがって、本発明の本当の技術的保護範囲は、添付された登録請求の範囲の技術的思想により決められる。
【図1】
【図2】
【図3】
【図4】
【図5】
【国際調査報告】