JP7634007B2 - 医療機器、認証サーバ、及び機器ユーザ・インタフェースを介して機器へのアクセスをユーザに認可するための方法 - Google Patents

Description

本開示は、医療機器、認証サーバ、及び機器ユーザ・インタフェースを介して医療機器へのアクセスをユーザに認可するための方法に関する。本開示はまた、本方法を実施するコンピュータ・プログラム及びコンピュータ・プログラム製品に関する。

医療機器（以下、単に機器と呼ばれる）は典型的に、医療スタッフ又は技術者のようなユーザが機器にアクセスできるようになる前にユーザが認証されることを要求する。医療機器がオンライン、すなわちサービス・システムと通信しているならば、サービス・システムにログインするだけで、サービス・システムを介してユーザにアクセス権が与えられうる。

しかし、場合によっては、ユーザは、サービス・システムからオフラインである装置にアクセスする必要がある。今日、オフライン機器は典型的に、アクセスをユーザに認可するためにユーザ・インタフェースを介して入力されうるハードコードされたパスコード（例えば、ＰＩＮＳ、パスワード又はキー）を使用する。このタイプのアクセス認可は、いくつかの理由で、もはや安全であるとは考えられない。

例えば、制御されていない方法でユーザ間でパスワードが共有されるというリスクが常に存在する。また、パスコードによる解決策は、各機器が個々のパスコードで事前にプログラムされる必要があるので、追加の生産ステップを必要とする。一方、ＰＩＮやパスワードが失われると、まったくログインできなくなる。したがって、インフラストラクチャは、すべての機器についてパスコードを有するセキュアなデータベースを維持する必要があり、これには管理上の労力を要求する。

さらに、匿名パスコードは、各パスコードが単一のユーザによって使用されない限り、特定の機器に誰がアクセスしたかについての監査を与えることができない。しかし、各機器に複数のユーザのＩＤ及びパスコードを有することは、ユーザが変更したときに多くの保守を必要とする。

ユーザを識別するための別の方法は、ワンタイム・パスワードを使用することである。しかし、ワンタイム・パスワードは、ワンタイム・パスワード注文番号によるか、又は医療機器とパスワード生成器との間の時間同期による、何らかの種類の同期を必要とする。しかし、典型的に、これらの同期オプションのいずれも実際には管理可能ではない。ユーザＩＤを有しない注文ベースのワンタイム・パスワードについて、すべてのユーザはパスワード生成器に通信し直さなければならない。このパスワードは、各個別の機器に関して最後に用いられたパスワードであり、実現不可能である。ユーザＩＤを有する注文ベースのワンタイム・パスワードは、上述のように、各オフライン機器上のユーザ・データベースの保守を必要とする。また、時間ベースのワンタイム・パスワードは、医療機器のクロックがパスワード生成器の時刻と同期していることを保証できないので、実現可能ではない。

医療機器がサービス・システムに接続されている場合であっても、技術者が診療所の外部にいて、したがって病院のＩＴシステムを通じて認証されることができないことがあることにも留意されたい。

したがって、機器へのアクセスをユーザに認可する改善された方法の必要性が存在する。

既存の解決策による欠点の少なくともいくつかを軽減することが本開示の目的である。セキュアな方法でアクセスをユーザに認可する方法を提供することがさらなる目的である。この方法では、機器を個々の情報で設定する必要はない。特に、医療機器において個々のパスコードを設定する必要性を排除する解決策を提供することが目的である。

第１態様によれば、本開示は、医療機器において使用するための方法であって、機器ユーザ・インタフェースを介して医療機器へのアクセスをユーザに認可するための方法を提供する。本方法は、認証サーバに関連する機関非対称鍵ペアの機関公開鍵を記憶することと、医療機器で生成された一時的機器非対称鍵ペアの機器公開鍵を示す認可チャレンジを、機器ユーザ・インタフェースを介してユーザに提供することと、を有する。本方法はさらに、機関非対称鍵ペアの機関秘密鍵と、提供された機器公開鍵とから導出可能な共有鍵を使用して暗号化された有効性情報を含む応答コードを、機器ユーザ・インタフェースを介してユーザから受けることと、同じ共有鍵であるが、記憶された機関公開鍵と、一時的機器非対称鍵ペアの機器秘密鍵とを使用して医療機器において導出された共有鍵を使用して復号された有効性情報が有効であることに応じて、医療機器へのアクセスをユーザに認可することと、を有する。提案される方法は、事前に設定されたパスコードを使用することなく、ユーザ・インタフェースを介してオフライン・ユーザ機器へのアクセスをユーザに認可することを可能にする。実際には、これは、認証サーバによって認可されたすべてのユーザが認証サーバからパスコードを取得し、それによって医療機器にアクセスしてもよいことを意味する。それゆえ、医療機器へのアクセスを誰が認可されるかを制御するのは認証サーバである。すべての機器に共通の１つの公開鍵を使用することによって、生産における個別化されたステップが排除されてもよい。また、本方法は、機器ごとの秘密鍵又は対称鍵のデータベースの必要性、及び機器内のハードウェアを交換し、それによって新たな個別鍵を交換する際に発生する可能性があるすべての問題を排除する。最後に、本方法は、医療機器のクロックと認証サーバのクロックとが同期されることを要求しない。

いくつかの実施形態では、ユーザ・インタフェースは、ヒューマン‐マシン・インタフェース、又はユーザのユーザ・デバイスと通信するように構成されたマシン‐マシン・インタフェースである。それゆえ、ユーザは、手動で、又はリストバンド、スマートフォン、又はＵＳＢスティックのような携帯型データ・ストレージ・デバイスのようなユーザ・デバイスを介して、チャレンジ及び応答をやりとりしてもよい。

いくつかの実施形態では、認可することは、応答コードに含まれる情報に起因して、異なるレベルのアクセスをユーザに認可することを含む。それゆえ、通常は異なるパスコードを必要とする異なるタイプのユーザに対して、１つの単一の方法が使用されてもよい。その代わりに、アクセスのレベルは、認証サーバによって処理される。いくつかの実施形態では、認可することは、１つ以上のセッションへの所定のアクセスを認可することと、特定の用途のために医療機器をロック解除することと、一時的な非通常使用を認可することとのうちの少なくとも１つについてのユーザへの認可を含む。

いくつかの実施形態では、認可することは、所定の期間中にアクセスを認可することを含む。それゆえ、機器へのアクセスの認可は、１回、又は数回の使用に限定されてもよい。さらに、それは、時間に関して制限されてもよい。

いくつかの実施形態では、本方法は、ユーザへのアクセスの認可を開始するユーザ入力を受けることを含む。よって、認証は例えば、医療機器のボタンを押すユーザによって開始されてもよい。

いくつかの実施形態では、本方法は、一時的機器非対称鍵ペアを破棄にすることを含む。これにより、一回の使用後又は所定の時間後に、一時的鍵が有効でないことが保証される。それゆえ、次の認可について、新たな一時的機器非対称鍵ペアが作成されなければならない。これにより、セキュリティが向上する。

いくつかの実施形態では、本方法は、医療機器が認証サーバからオフラインであることを含む。よって、本方法は、オフライン医療機器においても使用されてもよい。

第２態様によれば、本開示は、認証サーバで使用される方法であって、サーバ・ユーザ・インタフェースを介して医療機器へのアクセスをユーザに認可するための方法に関する。本方法は、認証サーバに関連する機関非対称鍵ペアの機関秘密鍵を記憶することと、ユーザを認証することと、医療機器に関連する一時的機器非対称鍵ペアの機器公開鍵を示す認可チャレンジを、サーバ・ユーザ・インタフェースを介してユーザから受けることと、共有鍵を使用して暗号化された有効性情報を含む応答コードを、サーバ・ユーザ・インタフェースを介してユーザに提供することであって、共有鍵は、記憶された機関秘密鍵と、機器公開鍵とを使用して認証サーバにおいて導出される、ことと、を有する。本方法は、認証サーバにおけるユーザの認証に基づいて医療機器をロック解除するために使用されてもよい応答コードを作成することを可能にする。それゆえ、すべてのユーザ認証は、１か所、すなわち認証サーバにおいて処理されてもよい。そして、認証サーバは、医療機器へのアクセスが要求される場合に、ユーザのために動作する。言い換えると、提案される方法は、ネットワーク・インフラストラクチャとは無関係に、中央システムにログインされた（すなわち、医療機器においてクリアすることができない）ユーザごとの個々の認証を可能にする。

実際には、これは、ユーザが認証サーバに追加されると、ユーザは、認証サーバによって制御される任意の医療機器、すなわち、機関非対称鍵ペアの機関公開鍵を記憶し、第１態様に従って方法を実行するように構成されたすべての医療機器へのアクセスを許可されてもよいことを意味する。本方法は、リモート認証サーバが、スタッフが変わった場合などに、ユーザ、認可、及び認可解除を管理することを可能にする。変更は直ちに行われ、個々の機器の保守を必要としない。

いくつかの実施形態では、サーバ・インタフェースは、ヒューマン‐マシン・インタフェース、又はユーザのユーザ・デバイスと通信するように構成されたマシン‐マシン・インタフェースである。それゆえ、ユーザは、手動で、又はリストバンド又はスマートフォンのようなユーザ・デバイスを介して、チャレンジ及び応答をやりとりしてもよい。

いくつかの実施形態では、決定することは、ユーザの認可レベル、時間パラメータ、及びユーザの位置のうちの少なくとも１つに基づいて応答コードを決定することを含む。それゆえ、認証サーバは、異なるパラメータに基づいて、どのタイプのアクセスを許可するかを選択してもよい。例えば、医療スタッフ及び技術者は、異なるタイプのアクセスが与えられてもよい。また、いくつかのユーザは、特定の時刻に、又は特定の場所においてのみ、医療機器にアクセスすることを許可されてもよい。

いくつかの実施形態では、本方法は、認証に関連する情報をログに記録することを含む。認証サーバはどの医療機器へのアクセスがどのユーザにいつ許可されているかを知っているため、提供されたすべてのアクセスのログを生成することができ、これは多くの状況で有用でありうる。

いくつかの実施形態では、機関非対称鍵ペア及び機器非対称鍵ペアは、一方の非対称鍵ペアの秘密鍵を他方の非対称鍵ペアの公開鍵とともに使用する場合に、反対の場合と同じ共有鍵が導出されるように生成される。いくつかの実施形態では、共有鍵は、ディフィー‐ヘルマン関数を使用して導出される。いくつかの実施形態では、機関非対称鍵ペア及び機器非対称鍵ペアは、楕円曲線暗号方式（ＥＣＣ）、又はリベスト‐シャミア‐エーデルマン（ＲＳＡ）を使用して生成される。

いくつかの実施形態では、有効性情報は、医療機器のデバイス識別子と、医療機器のアドレスと、事前に規定されたデータ・シーケンスと、事前に規定されたルールを使用して決定されたデータ・シーケンスとのうちの少なくとも１つを含む。それゆえ、実際には、医療機器によって知られている任意の「文字列」が使用されてもよい。いくつかの実施形態では、有効性情報は、コントロール・サムを含む。コントロール・サム、それゆえチェックサムを使用することは、それが典型的に短いため、応答コードが手動で入力される場合に有用であってもよい。

第３態様によれば、本開示は、機器ユーザ・インタフェース及び制御装置を備える対応する医療機器に関する。制御装置は、認証サーバに関連する機関非対称鍵ペアの機関公開鍵を記憶し、医療機器において生成された一時的機器非対称鍵ペアの機器公開鍵を示す認可チャレンジを、機器ユーザ・インタフェースを介してユーザに提供するように構成される。制御装置はさらに、共有鍵を使用して暗号化された有効性情報を含む応答コードを、機器ユーザ・インタフェースを介してユーザから受けるように構成される。共有鍵は、機関非対称鍵ペアの機関秘密鍵と、提供された機器公開鍵とから導出可能である。制御装置はさらに、同じ共有鍵であるが、記憶された機関公開鍵と、一時的機器非対称鍵ペアの機器秘密鍵とを使用して医療機器において導出された共有鍵を使用して復号された有効性情報が有効であることに応じて、医療機器へのアクセスをユーザに認可するように構成される。

第４態様によれば、本開示は、サーバ・ユーザ・インタフェースを備える対応する認証サーバに関する。認証サーバは、認証サーバに関連付けられた機関非対称鍵ペアの機関秘密鍵を記憶し、ユーザを認証するように構成される。さらに、認証サーバは、医療機器に関連する一時的機器非対称鍵ペアの機器公開鍵を示す認可チャレンジを、サーバ・ユーザ・インタフェースを介してユーザから受けるように構成される。認証サーバはさらに、共有鍵を使用して暗号化された有効性情報を含む応答コードを、サーバ・ユーザ・インタフェースを介してユーザに提供するように構成され、共有鍵は、記憶された機関秘密鍵と、機器公開鍵とを使用して認証サーバにおいて導出される。

第５態様によれば、本開示は、コンピュータにおいて動作されると、コンピュータに第１態様又は第２態様による方法を実行させるコード手段を特徴とするコンピュータ・プログラムに関する。

第６態様によれば、本開示は、コンピュータ可読媒体及びコンピュータ・プログラムを含むコンピュータ・プログラム製品に関し、前記コンピュータ・プログラムは、コンピュータ可読媒体に含まれる。

第７態様によれば、本開示は、医療機器及び認証サーバを備えるシステムに関する。

本開示の実施形態は、本開示の実施形態の例を示す添付の図面を参照してより詳細に説明される。
概念的な医療機器を説明する。 図１ａの医療機器の制御構成をより詳細に説明する。 認証サーバを説明する。 図４及び図５の方法を実行する場合の医療機器と認証サーバとの間のシグナリングを説明する。 医療機器で使用される方法のフローチャートを説明する。 認証サーバで使用される方法のフローチャートを説明する。 開示された技術の実施形態を実施してもよい例示的な医療機器を説明する。 開示された技術の実施形態を実施してもよい別の例示的な医療機器を説明する。 開示された技術の実施形態を実施してもよいさらなる例示的な医療機器を説明する。

提案される解決策は、医療機器と応答生成器（認証サーバとも呼ばれる）という２つの当事者を伴う。認証サーバは例えば、リモート・アクセス可能なシステムであってもよく、又は、組織内（例えば、病院内）のセキュアなサーバであってもよい。認証サーバは、機関秘密鍵（ｄ_A）をセキュアに記憶し、提案されるチャレンジ応答アルゴリズムを実行できる。

提案される技術は、非対称暗号方式（「公開鍵」暗号方式とも呼ばれる）、特に鍵交換アルゴリズムを使用して上述の問題を解決する。公開鍵暗号方式は鍵ペアを使用することに基づいており、一方の鍵がデータの暗号化に使用され、もう一方がデータの復号に使用される。暗号鍵ではデータを復号できず、復号鍵では（意味のある方法で）データを暗号化できない。２つの当事者がそれぞれ１つの秘密鍵ｄ及び１つの公開鍵Ｑを有する場合、当事者は、自身の秘密鍵ｄを他の部分の公開鍵Ｑに組み合わせることによって、同じ共有鍵Ｋを算出できる。

上述したように、各医療機器に個々の暗号鍵を構成することは、余分な生産ステップと、そのような暗号鍵のデータベースを維持するためのインフラストラクチャを要求する。また、暗号鍵が記憶されている電子ボードを交換するなど、機器のハードウェアを変更する際にも問題が発生しうる。したがって、医療機器に記憶される個々の鍵を要求しない解決策が提案される。よって、提案される解決策では、医療機器は、開示された場合に信頼できないユーザのアクセスを可能にする秘密をまったく含まない。

提案される解決策は、非対称鍵の２つのペアを使用し、１つは一時的機器非対称鍵ペアであり、１つは機関非対称鍵ペアである。機関非対称鍵ペアは事前に生成される。製造者によって製造されるすべての医療機器は、機関非対称鍵ペアの機関公開鍵Ｑ_Bを使用して事前に構成されるか又はプログラムされる。機関公開鍵Ｑ_Bは秘密である必要はない。しかし、機関公開鍵Ｑ_Bは、少なくとも信頼されていない部分によっては変更できないような方法で記憶されなければならない。

機関非対称鍵ペアの機関秘密鍵ｄ_Bは、認証サーバにセキュアに記憶される。機関秘密鍵ｄ_Bは決して公開されない。さらに、機関秘密鍵ｄ_Bは変更されないが、同じ鍵が、例えば製造業者によってそのすべての医療機器へのアクセスを可能にするために使用される。医療機器に記憶された機関公開鍵Ｑ_Bに対応する機関秘密鍵ｄ_Bは、機器にアクセスするために要求される応答コードを作成するために要求される。よって、医療機器にアクセスすることを望むユーザは、医療機器にアクセスするために使用されてもよい有効な応答コードを得るために、認証サーバで自分自身を認証する必要がある。これは、どのユーザが医療機器にアクセスしたかを医療機器が知らないことを意味する。しかし、応答コードがいつ、どのユーザに対して、場合によってはどの医療機器に対して生成されたかをログに記録することによって、ユーザは認証サーバにおいて依然として追跡されうる。

一時的機器非対称鍵ペアは、ユーザが医療機器にアクセスすることを望むたびに、医療機器において生成される。一時的機器非対称鍵ペアは基本的に、応答コードがこの特定の医療機器について発行されたことを検証するために使用される。一時的機器非対称鍵ペアは、機関非対称鍵ペアを生成するために使用されたのと同じアルゴリズムを使用して生成される。１回の使用後、一時的機器非対称鍵ペアはもはや有効ではない。それゆえ、新たな一時的機器非対称鍵ペアが生成されなければならない。

機関非対称鍵ペアは、以下に説明するように、医療機器へのアクセスを認可するために、一時的機器非対称鍵ペアとともに使用される。しかし、非対称暗号化及び鍵交換のための数学的アルゴリズムもまた、本開示の一部ではなく、提案される解決策は特定のアルゴリズムに依存しないが、純粋に実用的な理由のために、いくつかは、他のものよりも、この目的のためにより良好に適合しうる。

以下では、医療機器、認証サーバ、及び機器ユーザ・インタフェースを介して医療機器へのアクセスをユーザに認可するための方法について説明する。提案される技術は、ユーザ・アクセスを制御することが要求される又は望ましい任意の医療機器に適用可能である。医療機器は、流体（例えば、栄養流体、静脈内治療流体、及び腫瘍学薬物）のための注入ポンプ、水浄化装置、及び医療撮像デバイスなどを含むが、これらに限定されない。

図１ａは、提案される技術が実施されてもよい概念的な医療機器１０を説明する。医療機器１０は例えば、透析機械のような医療機械である。これに代えて、医療機器は、注入ポンプのような、より小さい医療デバイスである。医療機器１０は、互いに接続された複数の個別のデバイスを含んでもよい。そして、提案される技術は、これらのデバイスのうちの１つ以上へのユーザ・アクセスを制御するために使用されてもよい。原理的に、医療機器１０は、医療用に意図された任意の機器であってもよい。

医療機器１０は、任意の医療処置を実行するように構成される。医療機器１０は、医療機器１０へのアクセスを認可しうるリモート・システムには接続されていない。それゆえ、医療機器はオフラインである。特に、これは、医療機器１０にアクセスするために要求される機関秘密鍵ｄ_Bを保持する認可システム２０（図２ｂ）からオフラインである。

説明される簡略化された例では、医療機器１０は、機器ユーザ・インタフェース１９と制御装置１６とを備える。医療機器はまた、医療処置を実行するために要求される構成要素（図示せず）を含む。機器ユーザ・インタフェース１９は、ユーザが医療機器へ及び／又は医療機器から情報をやりとりすることを可能にする。機器ユーザ・インタフェース１９は例えば、ディスプレイ及びボタン又はタッチスクリーンを含む。

図１ｂは、図１ａの例示的な医療機器のいずれかの制御装置１６をより詳細に説明する。制御装置１６は、プロセッサ１６１とメモリ１６３とを備える。プロセッサ１６１は、ＣＰＵ、ＤＳＰ、マイクロプロセッサ、ＦＰＧＡ、ＡＳＩＣ、又は任意の他の電子プログラマブル論理デバイス、又はそれらの組合せのような任意の商業利用可能な処理デバイスであってもよい。

制御装置１６はまた、ローカル・サーバ又はリモート・サービス・システムのような他のデバイス又はシステムとの通信を可能にするように構成された通信インタフェース１６２を備えてもよい。通信は、無線及び／又は有線であってもよい。有線通信は、有線イーサネット接続、ＲＳ－２３２、ＲＳ－４８５、又はＵＡＲＴを使用して実行されてもよい。無線通信は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ（登録商標）、Ｚｉｇｂｅｅ（登録商標）、Ｚ－Ｗａｖｅ（登録商標）、無線ユニバーサル・シリアル・バス（「ＵＳＢ」）、赤外線プロトコルのいずれか、又はその他の適切な無線通信技術を介して実行されてもよい。近距離通信インタフェース１６２は例えば、プロセッサ１６１によって制御されるように構成されたＢｌｕｅｔｏｏｔｈチップである。

メモリ１６３は、不揮発性メモリ又は揮発性メモリ、又はＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、リムーバブル・メモリ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、キャッシュ・メモリ、ハード・ドライブ、記憶媒体などの組合せを含んでもよいが、これらに限定されない。メモリ１６３は、プロセッサ１６１による実行のためのソフトウェア・コードを記憶する。ソフトウェア・コードは、例えば医療処置を実行し、医療機器へのユーザ・アクセスを可能にするように医療機器１０を制御するように構成される。

プロセッサ１６１及びメモリ１６３は、それらが個々に動作可能なユニットであるという意味で「別個」であるが、それらは例えば集積回路のような共通の基板上に任意の組合せで配置されてもよいし、配置されなくてもよい。簡単にするために、図２ａの制御装置１６は、ただ１つのプロセッサ１６１及びメモリ１６３を備えるものとして説明される。しかし、制御装置１６は、１つ以上のプロセッサ１６１を備えるプロセッサの集合を備えてもよく、メモリ１６３は、１つ以上のメモリ・デバイスによって実装されてもよいことが理解されなければならない。

制御装置１６は、医療機器１０の動作を制御するように、例えば医療機器１０の意図された医療処置を実行するように構成される。制御装置１６はまた、医療機器１０へのアクセスを制御するように構成される。

図２は、認証サーバ２０を説明する。認証サーバは、ユーザに医療機器へのアクセスを認証するように構成された制御装置である。認証サーバ２０は、オンサイト又はオフサイトに位置してもよい。認証サーバ２０は、いくつかの実施形態では、病院ＩＴシステム又は製造者サービス・システムのような別のシステムに統合される。認証サーバ２０は、コンピュータのような１つの物理的なデバイスであってもよいし、コンピュータ・クラウドのような複数の物理的なコンピュータ上で実行されるコンピュータ・システムであってもよい。いくつかの実施形態では、認証サーバ２０は、例えば医療機器１０が使用される病院のローカル・サーバである。認証サーバ２０は、サーバ・ユーザ・インタフェース２５を備える。認証サーバ２０は、プロセッサ２１と、通信インタフェース２２と、メモリ２３とを備える。プロセッサ２１は、ＣＰＵ、ＤＳＰ、マイクロプロセッサ、ＦＰＧＡ、ＡＳＩＣ、又は任意の他の電子プログラマブル論理デバイス、又はそれらの組合せのような任意の商業利用可能な処理デバイスであってもよい。

プロセッサ２１及びメモリ２３は、それらが個々に動作可能なユニットであるという意味で「別個」であるが、それらは例えば集積回路のような共通の基板上に任意の組合せで配置されてもよいし、配置されなくてもよい。簡単にするために、図２ｂの認証サーバ２０は、ただ１つのプロセッサ２１及びメモリ２３を備えるものとして説明される。しかし、認証サーバ２０は、１つ以上のプロセッサ２１を備えるプロセッサの集合を備えてもよく、メモリ２３は、１つ以上のメモリ・デバイスによって実装されてもよいことが理解されなければならない。通信インタフェース２２は、認証サーバ２０と他のデバイス、例えばインターネットを介したリモート・デバイスとの間の通信を可能にするインタフェースである。

ユーザは、サーバ・ユーザ・インタフェース２５を介して認証サーバ２０と対話してもよい。サーバ・ユーザ・インタフェース２５は、認証サーバ２０とユーザとの間の対話を可能にするように構成される。いくつかの実施形態では、サーバ・ユーザ・インタフェース２５は、ソフトウェア・ユーザ・インタフェース、例えば、ウェブ・インタフェース又はアプリケーション・プログラミング・インタフェース（ＡＰＩ）を含む。よって、サーバ・ユーザ・インタフェース２５は、外部ディスプレイ上やユーザ・デバイス（例えばパーソナル・コンピュータ）のような外部のデバイス上で、認証サーバ２０からレンダリングされてもよい。サーバ・インタフェース２５は、通信インタフェース２２を介してサーバ・ユーザ・インタフェース２５にアクセスするリモート（すなわちオフサイト）デバイス上で生成されさえしてもよい。いくつかの実施形態では、サーバ・ユーザ・インタフェース２５は、ユーザがグラフィカル・アイコンを通じて認証サーバ２０と対話することを可能にするグラフィカル・ユーザ・インタフェースである。

いくつかの実施形態では、サーバ・ユーザ・インタフェース２５は、キーボード、マウス及び／又はディスプレイ、例えばタッチスクリーンのような物理的な構成要素を使用してユーザが認証サーバ２０と対話することを可能にするハードウェア・インタフェースを備える。

ここで、図３及び図４を参照して、医療機器１０において使用される方法であって、機器ユーザ・インタフェースを介して医療機器１０へのアクセスをユーザ２に認可するための方法について説明する。図３は、機器ユーザ・インタフェースを介して医療機器１０へのアクセスをユーザ２に認可する提案された方法を実行する場合の医療機器１０と認証サーバ２０との間のシグナリングを説明する。図４は、医療機器１０において実行される方法ステップのフローチャートを説明する。本方法が医療機器１０で使用されるものであることは、本方法の方法ステップが、医療機器１０内の１つ以上の構成要素、例えば制御装置１６によって実行されることを意味する。本方法は、プログラム・コードとして実施され、医療機器１０のメモリ１６３に保存されてもよい。本方法のステップは、プログラムがコンピュータ、例えば制御装置１６によって実行された場合に、制御装置１６に本方法を実行させる命令を含むコンピュータ・プログラムにおいて規定されてもよい。

本方法は、ユーザが機器ユーザ・インタフェース１９を介して医療機器１０にアクセスすることを望むときにいつでも実行されてもよい。典型的に、これは、医療機器１０がインターネットに接続されていない場合、又は少なくともユーザにアクセスを自動的に許可してもよいサービス・システムに接続されていない場合である。言い換えれば、いくつかの実施形態では、医療機器１０は、認証サーバ２０からオフラインである。それゆえ、アクセスは、機器ユーザ・インタフェース１９を使用して提供される必要がある。医療機器は、上述したように、異なるタイプの機器ユーザ・インタフェース１９を有してもよい。いくつかの実施形態では、機器ユーザ・インタフェース１９は、ヒューマン‐マシン・インタフェースである。ヒューマン‐マシン・インタフェースは、ユーザ動作が機械のための信号として変換され、要求された結果を当該機械がユーザに提供することを可能にするインタフェースである。ヒューマン‐マシン・インタフェースは例えば、ボタン、１つ以上のディスプレイ、マイクロフォン、スピーカなどを含む。

いくつかの実施形態では、機器ユーザ・インタフェース１９は、ユーザのユーザ・デバイスと通信するように構成されたマシン‐マシン・インタフェースである。ユーザ・デバイスは例えば、スマートフォン又はウェアラブル・デバイスである。ユーザ・デバイスは例えば、光信号又は無線信号を読み取るように構成されてもよい。例えば、ユーザ・デバイスは、シンボルのシーケンス又はＱＲコード（登録商標）を読み取るように構成されてもよい。いくつかの実施形態では、ユーザ・デバイスは、ＵＳＢスティックのような携帯型データ・ストレージである。それゆえ、ユーザは、機器ユーザ・インタフェース１９から携帯型データ・ストレージにデータを読み出し、その後、それをさらにサーバ・ユーザ・インタフェース２５に転送してもよい。

上述のように、提案される解決策の前提条件は、医療機器１０が、認証サーバ２０に関連する機関非対称鍵ペアの機関公開鍵Ｑ_Bを記憶することである。機関非対称鍵ペアは、事前に規定されたアルゴリズムを使用して、認証サーバ２０において事前に生成される。鍵ペアを生成するために使用されてもよい多くのアルゴリズムが存在する。いくつかの例示的なアルゴリズムは、楕円曲線暗号方式（ＥＣＣ）又はリベスト‐シャミア‐エーデルマン（ＲＳＡ）である。

機関公開鍵Ｑ_Bは、医療機器１０の製造中に医療機器１０内に構成（すなわち、記憶）されてもよいし、又は医療機器１０のソフトウェア内に含まれてもよい。言い換えると、本方法は、認証サーバ２０に関連する機関非対称鍵ペアの機関公開鍵Ｑ_Bを記憶することＳ０を含む。機関公開鍵Ｑ_Bは、それを変更又は交換できないように記憶されなければならない。これは、任意の既知の一般の記憶方法によって、例えば、ソフトウェア内に機関公開鍵Ｑ_Bをハードコーディングするか、リード・オンリ・メモリ（ＲＯＭ）に記憶するか、又はアクセス不能（少なくとも書き込み不能）な内部ファイル・システム内のファイルに記憶することによって行われうる。実際には、機関公開鍵Ｑ_Bは、交換することが困難な任意の構成要素であり、交換することができない場所に記憶されてもよい。

アクセスの認可は例えば、ユーザが機器ユーザ・インタフェース１９を介して医療機器へのアクセスを要求した場合に開始される。これは、例えば、医療機器１０のディスプレイ１２上のボタン又はアイコンを押すことによって行われる。言い換えると、いくつかの実施形態では、本方法は、ユーザ２へのアクセスの認可を開始するユーザ入力を受けることＳ１を含む。これに代えて、例えばスタートアップ時にアクセスの認可が自動的に開始される。

ユーザ入力に応じて、又は自動化されたスタートアップにおいて、機関非対称鍵ペアを生成した場合と同じアルゴリズムを使用して、医療機器１０において一時的鍵ペアが生成されるＳ２。それゆえ、本方法は、機器公開鍵Ｑ_A及び機器秘密鍵ｄ_Aを含む一時的機器非対称鍵ペアを生成することＳ２を含む。機関非対称鍵ペア及び機器非対称鍵ペアは、非対称鍵ペアの一方の秘密鍵ｄを他方の非対称鍵ペアの公開鍵Ｑとともに使用した場合に、その反対の場合と同じ共有鍵が導出されるように生成される。

一時的機器非対称鍵ペアが生成された後、認証チャレンジがユーザに提示される。チャレンジは、認証サーバ２０が機器公開鍵Ｑ_Aを取得することを可能にする情報を含む。いくつかの実施形態では、チャレンジは、生成された機器公開鍵Ｑ_Aを備える又は含む。機器公開鍵Ｑ_Aは、認可セッションを識別し、応答コードが特定のチャレンジのために意図されていることを検証することを可能にする。チャレンジはまた、認証サーバ２０が医療機器１０を識別することを可能にする機器識別情報、例えば、デバイス識別子Ｉ又はアドレスのようなさらなる情報を含んでもよい。例えば、機器公開鍵Ｑ_Aは、デバイス識別子、例えばシリアル番号や媒体アクセス制御（ＭＡＣ）アドレスとともにユーザに提示される。この情報は、以下において「チャレンジ」と表される。提示は、オンスクリーンであってもよく、人間が読み取り可能な、例えばシンボルのシーケンスであってもよく、又は機械が読み取り可能な、例えばＱＲコード又は無線信号であってもよい。チャレンジは、楕円曲線暗号方式（ＥＣＣ）のような効率的な公開鍵暗号アルゴリズムを使用することによって、比較的短くてもよい。ＥＣＣ－１６０鍵は、２５文字の印刷可能文字で提示されうる２０バイトである。

例えば、デバイスＩＤが「１２３４５６」であり、機器公開鍵が「３６ＦＤ Ａ６Ａ２ １３ＤＣ ２７５４」であるならば、ユーザに提示されるチャレンジは、「１２３４５６３６ＦＤＡ６Ａ２１３ＤＣ２７５４」であってもよい。言い換えると、本方法は、医療機器１０において生成された一時的機器非対称鍵ペアの機器公開鍵Ｑ_Aを示す認可チャレンジを、機器ユーザ・インタフェースを介してユーザ２に提供することＳ３を含む。チャレンジは、秘密情報を何も含まず、有効な応答コードを生成するために必要な情報のみを含むので、暗号化されなくてもよいことに留意されたい。しかし、機器公開鍵Ｑ_A以外のチャレンジ内の任意の他のデータは、機器公開鍵Ｑ_Aを受信したこと応じて医療機器１によって導出されうる共有鍵Ｋで暗号化されてもよい。

ユーザがチャレンジを受けると、ユーザは、機関秘密鍵ｄ_Bを保持する認証サーバ２０から有効な応答コードを取得する必要がある。これを行うために、ユーザは自身を認証サーバ２０に対して認証するＳ２１。これは、サーバ・ユーザ・インタフェース２５を介して直接、又はユーザが知っている人物を介して行われてもよい。認証サーバ２０において、ユーザ・アイデンティティ及びアクセス・レベルがチェックされる。その後、ユーザは、チャレンジを認証サーバ２０へ転送し、認証サーバ２０は、チャレンジを受けるＳ２２。例えば、ユーザは、医療機器のディスプレイ上に提示されたチャレンジを読み取り、それをサーバ・ユーザ・インタフェース２５にタイプする。これにかえて、ユーザは、スマートフォン又はＵＳＢスティックのようなユーザ・デバイスを使用してチャレンジを転送する。チャレンジは、機器公開鍵Ｑ_Aを含み、機器公開鍵Ｑ_Aは、システムの秘密鍵ｄ_Bと組み合わされて、応答コードを暗号化するために使用される共有鍵Ｋ（Ｑ_A，ｄ_B）となり、これがユーザに戻される。ここで、Ｋ（Ｑ_A，ｄ_B）は、関数ｆ（Ｑ_A，ｄ_B）を使用して認証サーバ２０によって算出された場合の共有鍵Ｋを指す。いくつかの実施形態では、共有鍵Ｋ（Ｑ_A，ｄ_B）は、ディフィー‐ヘルマン関数を使用して導出される。

それゆえ、認証サーバ２０は、チャレンジを分析し、共有鍵Ｋ（Ｑ_A，ｄ_B）を算出する（すなわち、生成するＳ２３）。その後、認証サーバ２０は、応答コードを算出し（すなわち、決定しＳ２４）、その応答コードを共有鍵Ｋ（Ｑ_A，ｄ_B）で暗号化するＳ２５。応答コードは有効性情報を含む。有効性情報は、医療機器１０に知られている情報であって、正しい共有鍵Ｋ（Ｑ_A，ｄ_B）が使用されたことを検証するために医療機器１０が復号できる情報である。その後、応答コードは、サーバ・ユーザ・インタフェース２５を介してユーザに提示される（すなわち、提供されるＳ２６に）。有効な応答コードを生成するために認証サーバ２０によって実行される動作は、以下の図５に関連してさらに説明される。

その後、ユーザは、医療機器１０の機器ユーザ・インタフェース１９を介して応答コードを入力する。言い換えると、医療機器１０で使用するための方法は、機関非対称鍵ペアの機関秘密鍵ｄ_B及び提供された機器公開鍵Ｑ_Aから導出可能な共有鍵Ｋ（Ｑ_A，ｄ_B）を使用して暗号化された有効性情報を含む応答コードを、機器ユーザ・インタフェース１９を介してユーザ２から受けることＳ４を含む。

共有鍵Ｋ（Ｑ_A，ｄ_B）は、機関秘密鍵ｄ_Bと、チャレンジによって示される機器公開鍵Ｑ_Aとにアクセスできる応答生成器によってのみ導出されてもよい。有効性情報は、事前に合意されたデータである。それゆえ、医療機器１０は、どのような有効性情報が期待されうるかを知っている。よって、共有鍵Ｋ（Ｑ_A，ｄ_B）を使用して応答コード（又は応答コードの一部）を復号する場合に、事前に同意された有効性情報が得られたならば、このことは、妥当な疑いを超えて、応答コードが、信頼された応答生成器、すなわち認証サーバ２０に由来し、特定のチャレンジのために意図されていることを保証する。

いくつかの実施形態では、有効性情報は、医療機器１０のシリアル番号のような、チャレンジで提供された医療機器１のデバイス識別子Ｉを含む。いくつかの実施形態では、有効性情報は、医療機器１０のＭＡＣアドレスのような、チャレンジに提供された医療機器１のアドレスを含む。いくつかの実施形態において、有効性情報は、「ＢＸ」又は任意の事前に合意されたテキスト文字列のような、事前に規定されたデータ・シーケンスを含む。

いくつかの実施形態では、有効性情報は、事前に規定されたルールを使用して決定されたデータ・シーケンスを含む。データ・シーケンスは例えば、チャレンジに含まれる情報から算出されたハッシュ又は制御コードであってもよい。例えば、応答コードは、チャレンジの巡回冗長検査（ＣＲＣ）又はチャレンジの一部であってもよい。応答は、対称暗方式で暗号化されるため、元のメッセージよりも長い必要はない。チャレンジ‐応答トランザクションにおけるデータの長さは、ユーザが手動でメッセージを転送しなければならない場合に重要である。

よって、医療機器１０は、その一時的機器秘密鍵ｄ_Aを、認証サーバ２０（すなわち応答生成器）の記憶された機関公開鍵Ｑ_Bに組み合わせて、認証サーバ２０で使用されているのと同じ共有鍵Ｋ（Ｑ_B，ｄ_A）にし、応答コード、又は少なくとも、暗号化された有効性情報を復号するＳ６。ここで、Ｋ（Ｑ_B，ｄ_A）は、関数ｇ（Ｑ_B，ｄ_A）を使用して医療機器において算出された場合の共有鍵を指す。

よって、同じ共有鍵は、関数ｇ（Ｑ_B，ｄ_A）又は関数ｆ（Ｑ_A，ｄ_B）を使用して算出されてもよい。よって、共有鍵Ｋは、
Ｋ＝ｇ（Ｑ_B，ｄ_A）＝ｆ（Ｑ_A，ｄ_B）
として表現されてもよい。言い換えると、本方法は、記憶された機関公開鍵Ｑ_Bと、生成された機器秘密鍵ｄ_Aとを使用して、医療機器１０において同じ共有鍵Ｋ（Ｑ_B，ｄ_A）を導出することＳ５（すなわち、生成すること）を含む。導出することＳ５は、早期に、例えば一時的機器非対称鍵ペアを生成Ｓ２した直後にすでに実行されていてもよいことに留意されたい。その場合に、共有鍵は、認可サーバ２０が共有鍵を導出するために必要となる機器公開鍵Ｄ_Aとは別に、チャレンジに含まれる何らかの情報を暗号化するためにも使用されてもよい。いくつかの実施形態では、本方法はまた、導出された同じ共有鍵を使用して、応答コードに含まれる有効性情報を復号することＳ６を含む。

有効性情報が有効であれば、ユーザは、医療機器１０へのアクセスを認可される。いくつかの例示的な実施形態では、医療機器１０は、有効性情報を復号し、復号された有効性情報を、医療機器１０に記憶されているか又は代替的に医療機器１０がどのように算出するかを知っている、事前に合意された有効性情報と比較することによって、応答コードを検証する。応答コードが有効であるならば、すなわち、復号された有効性情報が、事前に合意された有効性情報と同じか又は等しいならば、アクセスが許可される。言い換えると、本方法は、同じ共有鍵Ｋ（Ｑ_B，ｄ_A）であるが、記憶された機関公開鍵Ｑ_Bと一時的機器非対称鍵ペアの機器秘密鍵ｄ_Aとを使用して医療機器１０において導出された共有鍵を使用して復号された有効性情報が有効であることに応じて、医療機器１０へのアクセスをユーザ２に認可することＳ７を含む。

応答コードは、追加の情報、例えば医療機器１０でのユーザの認可レベルを含んでもよい。例えば、医療スタッフは、医療機器１０に医療処置を実行させるために必要な１つの認可レベルを有してもよい。しかし、技術者は、医療機器１０に医療処置を実行させることを認可されなくてもよい。しかし、技術者は、医療機器１０を試験モードで動作し、ソフトウェアを更新し、サービスモード又は特権モードに入ることなどを認可されてもよい。よって、応答コードは、ユーザがどの機能にアクセスしてもよいかを示す追加情報を含んでもよい。言い換えると、いくつかの実施形態では、認可することＳ７は、応答コードに含まれる情報に依存して、異なるレベルのアクセスをユーザ２に認可することを含む。いくつかの実施形態では、認可することは、ユーザ２に、１つ以上のセッションへの特定のアクセス・レベルを認可することを含み、１つのセッションは例えば、１つの治療セッション又はサービス・セッションである。アクセス・レベル（例えば、応答コードによって規定される）に依存して、その後、ユーザは、臨床限界の調整、デフォルト値の調整、セッションのための治療設定の調整、及び医療処置の開始のような所定の動作を実行してもよい。

いくつかの実施形態では、認可することは、一時的な非通常使用を認可するためのユーザ２への認可を含む。非通常使用は例えば、正常限界外のセッションを実行すること、例えば、所定の監視又は安全システムをオフにすることを含む。非通常使用の別の例は、例えば非臨床デモンストレーション又はトラブルシューティングのために、専用ソフトウェアをインストールすることである。

いくつかの実施形態では、認可することは、所定の用途のために医療機器をロック解除することを含む。言い換えると、応答コードは、例えば医療機器内の所定の機能をロック解除してもよい商業情報のような他の情報も含んでもよい。このようにして、認証サーバは、医療機器１０を制御してもよい。１つの特定の例は、医療機器が以前にブロックされていたならば、医療機器が臨床使用のためにロック解除されてもよい。

上記のすべての例は基本的に、提案される方法が、認証されたデータを認証サーバから医療機器１０へ送信することを可能にすることに基づいている。

応答コードでは、「機関認証された」データを医療機器１０に伝達することさえ可能である。すなわち、認証されていないユーザであったとしても機器に入力することが認可されるデータを送信することができる。これは、例えば、（例えば、機器が、例えばデモンストレーションのための非臨床ソフトウェアも有しているならば）臨床使用の認可、拡張使用（例えば、基本構成では医療機器が承認されていない新生児使用）、又は何らかの商業オプションの購入でありうる。これにより、重要なデータが組織内で集中的に制御されてもよく、これは、個々のユーザに制御を委譲するよりもセキュアである。

上述したように、提案される方法は、典型的には１回の使用を意図したものである。それゆえ、応答コードは、所定の期間のみ有効であってもよい。時間は事前に規定されていてもよいし、応答コードに含まれる情報によって規定されていてもよい。期間は、絶対量であってもよい。例えば、それは、チャレンジが提供された時点Ｓ３、又は応答コードが最初に入力された時点で開始してもよい。これに代えて、医療機器１０における時刻に対して相対的に期間が決定されてもよく、これは、医療機器１０のクロックと認証サーバのクロックとが同期していることを要求する。言い換えると、いくつかの実施形態では、認可することＳ７は、所定の期間中にアクセスを認可することを含む。しかし、本方法は、同期されたクロックを要求しないことに留意されなければならない。

セキュリティを高めるために、一時的機器非対称鍵ペアは、１回の認証についてのみ有効であるべきである。それゆえ、アクセスをユーザに認可した後、一時的機器非対称鍵ペアは無効にされるべきである。これに代えて、これは、事前に決定された期間の後に行われてもよい。言い換えると、いくつかの実施形態では、本方法は、一時的機器非対称鍵ペアを破棄にすることＳ８を含む。例えば、一時鍵ペアは、削除されるか、任意の他の方法で無効にされる。

図５は、認証サーバ２０で使用されるための対応する方法のフローチャートを説明する。本方法が認証サーバ２０で使用されるためのものであることは、本方法の方法ステップが、認証サーバ２０内の１つ以上の構成要素によって、例えばプロセッサ２１によって実行されることを意味する。本方法は、認証サーバ２０のメモリ２３に記憶されたプログラム・コードとして実施されてもよい。本方法のステップは、コンピュータ・プログラムで規定されてもよく、コンピュータ・プログラムは、プログラムがコンピュータ、例えばプロセッサ２１によって実行される場合に、コンピュータに本方法を実行させる命令を含む。

本方法は典型的に、医療機器１０にアクセスすることを望むユーザが医療機器１０からチャレンジを受け、医療機器１０にアクセスするために有効な応答コードを必要とする場合に実行される。これは、例えば、医療機器１０がインターネットに接続されていない場合、又はアクセスを自動的に許可しうる任意のサービス・システムに少なくとも接続されていない場合であってもよい。言い換えると、いくつかの実施形態では、医療機器１０は、認証サーバ２０からオフラインである。

本方法は、ユーザがサーバ・ユーザ・インタフェース２５を使用して認証サーバ２０と対話することを要求する。これは、医療機器１０にアクセスしようとしているのと必ずしも同じ人である必要はないことに留意されなければならない。原理上は、医療機器１０にアクセスすることを望む技術者は、認証サーバ２０のサーバ・ユーザ・インタフェース２５にアクセスできる人に電話をかけてもよい。このような状況では、チャレンジ及び応答コードが電話を介して通信されてもよい。もちろん、これは、認証サーバ２０にアクセスできる人が技術者を認識し、その人が信頼されていることを保証できることを要求する。

上述したように、提案される解決策は、認証サーバ２０が機関秘密鍵ｄ_Bを記憶するという概念に基づいている。言い換えると、本方法は、認証サーバ２０に関連する機関非対称鍵ペアの機関秘密鍵ｄ_Bを記憶することＳ２０を含む。機関公開鍵Ｑ_Bを記憶しない認証サーバ２０はまた、他のデバイスとのセキュアな通信を確立するためが必要とされるかもしれないので、機関公開鍵Ｑ_Bを記憶してもよい。しかし、これは、提案される方法を実行するために要求されない。

チャレンジを得たユーザは、まず、認証サーバ２０にログインしなければならない。言い換えると、ユーザは、自分のアイデンティティを証明する必要がある。これは、クレデンシャルを使用するか、デジタル証明書のようなよりセキュアな認証方法を使用するような、任意の従来の方法で行われうる。しかし、認証サーバ２０は、例えば病院ＩＴシステム又は製造者サービス・システムのような別のシステムの一部であるので、このタイプの機能は典型的に、すでに配置済みであり、アクティブ・ユーザに関する最近の変更によっていかにしても更新されなければならない。言い換えると、本方法は、ユーザ２を認証すること２１をさらに含む。認証は、典型的に、ヒューマン‐マシン・インタフェースであってもよいサーバ・ユーザ・インタフェース２５、又はユーザのユーザ・デバイスと通信するように構成されたマシン・マシン・インタフェースを介して行われる。

本方法は、典型的に、ユーザによって開始される。ユーザは例えば、「アクセス・デバイス」又は同様のもののような特定の機能を選択する必要があってもよい。その後、ユーザは、医療機器１０から取得したチャレンジを入力するように要求される。言い換えると、本方法は、認証サーバが、医療機器１０に関連する一時的機器非対称鍵ペアの機器公開鍵Ｑ_Aを示す認可チャレンジを、サーバ・ユーザ・インタフェース２５を介してユーザ２から受けることＳ２２を含む。

認可サーバ２０は、チャレンジとユーザの認証とに基づいて、応答コードを作成する。言い換えると、本方法は、共有鍵Ｋ（Ｑ_B，ｄ_A）を使用して暗号化された有効性情報を含む応答コードを、サーバ・ユーザ・インタフェース２５を介してユーザ２に提供することＳ２６を有し、共有鍵は、記憶された機関秘密鍵ｄ_Bと機器公開鍵Ｑ_Aとを使用して認証サーバ２０において導出される。応答コードは、上述のように、チャレンジを生成した医療機器１０にアクセスする、すなわちロック解除するために使用されてもよい。これをさらに詳細に説明する。

受けられたチャレンジは、記憶された機関秘密鍵ｄ_Bと組み合わされて、ユーザに戻されるメッセージ、認証コードを暗号化するために使用される共有鍵Ｋとなる機器公開鍵Ｑ_Aを含む（すなわち、備える）。言い換えると、認証サーバ２０は、記憶された機関秘密鍵ｄ_Bと、受信された機器公開鍵Ｑ_Aとを使用して、共有鍵を生成するＳ２３。また、認証サーバ２０は例えば、認証することと、場合によってはチャレンジに含まれる他のパラメータとに基づいて、有効性情報を含む応答コードを決定するＳ２４。これらの他のパラメータは例えば、医療機器１のデバイス識別子Ｉ、医療機器１のアドレス、又は何らかの他の情報である。

認証サーバ２０は、典型的に、ユーザ及び様々な医療機器に関する多くのデータを有する。それゆえ、医療機器１０は、ユーザが例えば、１のデバイス識別子Ｉ又はチャレンジに含まれるアドレスによって識別される特定の医療機器１０にアクセスすることを信用されているか否かを判定してもよい。また、いくつかの実施形態では、認証されたユーザのアクセス、時刻に基づいて、異なるレベルのアクセスが決定される。いくつかの実施形態では、認可サーバ２０は、ユーザの位置を知っている。その場合、ユーザの位置が、ユーザがアクセスすることを望む医療機器１０の位置に対応する場合にのみ、アクセスが許可されてもよい。言い換えると、いくつかの実施形態では、決定することＳ２４は、医療機器１のデバイス識別子Ｉ、医療機器１のアドレス、ユーザ２の認可レベル、時間パラメータ、及び／又はユーザ２の位置に基づいて応答コードを決定することを含む。

認証サーバ２０は応答コードを作成し、これは、事前に同意された検証サーバと、場合によっては何らかの追加情報とを含む。上述のように、医療機器１０が認証有効性情報を検証することを可能にする情報は例えば、医療機器１のデバイス識別子Ｉ又は医療機器のアドレスのような、チャレンジに含まれる何らかの情報であってもよい。これに代えて、これは何らかの事前に合意されたデータ、又は事前に合意されたルールによって算出されたデータであってもよい。有効性情報に加えて、応答コードに他のデータが追加されてもよい。他のデータは、ユーザのアイデンティティ又はアクセスについて医療機器に通知してもよい。例えば、他のデータは、アクセス・レベルを指定してもよく、又は医療機器１０内の所定の機能をロック解除する商業情報を含んでさえいてもよい。１つの例示的な実施形態では、所定の医療用途のために医療機器をロック解除する情報が送信されてもよい。

その後、認証サーバ２０は、生成された共有鍵Ｋ（Ｑ_A，ｄ_B）を使用して、決定された応答コード（又は少なくとも有効性情報）を復号しＳ２５、暗号化された応答コードをサーバ・ユーザ・インタフェース２５上に表示する。いくつかの実施形態では、共有鍵Ｋ（Ｑ_A，ｄ_B）は対称暗号方式であり、よって、応答コードは元のメッセージ、例えば有効性情報よりも長い必要はない。チャレンジ‐応答トランザクションにおけるデータの長さは、ユーザが手動でメッセージを転送しなければならない場合に重要である。

医療機器１０がユーザのアイデンティティを認識しないので、認証サーバは、ユーザを追跡しなければならない。よって、作成されたすべての応答コードの記録が、典型的に、タイムスタンプ及びユーザ識別情報とともに認証サーバ２０に記憶されるべきである。このようにして、どのユーザが特定の医療機器１０にいつアクセスしたかを見つけることは非常に容易である。言い換えると、いくつかの実施形態では、本方法は、認証に関連する情報をログに記録することＳ２７を含む。

上述のプロトコルでは、保護される必要がある鍵は１つだけ、すなわち記憶された機関秘密鍵ｄ_Bだけである。公開鍵は、応答コードを生成するのに十分ではなく、機器公開鍵ｄ_Aは、医療機器１０内で一時的にのみ存続し、新たな機器非対称鍵ペアがトランザクションごとに生成される。１つの医療機器１０を分解し、ソースコードを逆コンパイルし、内部ストレージ内のすべてのデータを読み取ることは、機関公開鍵Ｑ_Bを明らかにするだけであり、これは、別の医療機器１０に侵入するのに十分でなく、認証が次回実行される際に同じ医療機器１０に侵入するのにさえ十分でない。

さらに、提案される方法は、鍵ペアが実用上任意の情報を転送するために使用されうるので、暗号化されたデータのデバイスから機関への転送、又はその反対の転送を可能にし、許可する。

本開示はまた、上述した方法（図４）の態様のいずれかを実行するように構成された対応する制御装置１６にも関する。例えば、制御装置１６のプロセッサ１６１は、これを実現するために、メモリ１６３に記憶されたコンピュータ・プログラムを実行するように構成される。よって、本書で言及される方法は、典型的に、プログラムとして実施される。

より具体的には、制御装置１６は、認証サーバ２０に関連する機関非対称鍵ペアの機関公開鍵Ｑ_Bを記憶し、医療機器１０で生成された一時的機器非対称鍵ペアの機器公開鍵Ｑ_Aを示す認可チャレンジを、機器ユーザ・インタフェースを介してユーザ２に提供することを医療機器１０に行わせるように構成される。

制御装置１６はまた、機関非対称鍵ペアの機関秘密鍵ｄ_Bと、提供された機器公開鍵Ｑ_Aとから導出可能な共有鍵を使用して暗号化された有効性情報を含む応答コードを、機器ユーザ・インタフェースを介してユーザ２から受け、同じ共有鍵であるが、記憶された機関公開鍵Ｑ_Bと、一時的機器非対称鍵ペアの機器秘密鍵ｄ_Aとを使用して医療機器１０において導出された共有鍵を使用して復号された有効性情報が有効であることに応じて、医療機器１０へのアクセスをユーザ２に認可するように構成される。

いくつかの実施形態では、ユーザ・インタフェースは、ヒューマン‐マシン・インタフェース、又はユーザのユーザ・デバイスと通信するように構成されたマシン‐マシン・インタフェースである。

いくつかの実施形態では、制御装置１６は、応答コードに含まれる情報に依存して、ユーザ２の異なるアクセス・レベルを認可するように構成される。

いくつかの実施形態では、制御装置１６は、１つ以上のセッションへの所定のアクセスを認可することと、特定の用途のために医療機器をロック解除することと、一時的な非通常用途を認可することとのうちの少なくとも１つについてアクセスをユーザ２に認可するように構成される。

いくつかの実施形態では、制御装置１６は、所定の期間中にアクセスを認可するように構成される。

いくつかの実施形態では、制御装置１６は、機器ユーザ・インタフェースを介して、ユーザ２へのアクセスの認可を開始するユーザ入力を受けるように構成される。

いくつかの実施形態では、制御装置１６は、一時的機器非対称鍵ペアを破棄にするＳ８ように構成される。

いくつかの実施形態では、医療機器１０は、認証サーバ２０からオフラインである。

本開示はまた、上述の方法（図５）のすべての態様を実行するように構成された認証サーバ２０に関する。例えば、認証サーバ２０のプロセッサ２１は、これを実現するために、メモリ２３に記憶されたコンピュータ・プログラムを実行するように構成される。

より詳細には、認証サーバ２０は、認証サーバ２０に関連する機関非対称鍵ペアの機関秘密鍵ｄ_Bを記憶し、ユーザ２を認証するように構成される。また、認証サーバ２０は、サーバ・ユーザ・インタフェース２５を介してユーザ２から、医療機器１０に関連する一時的機器非対称鍵ペアの機器公開鍵Ｑ_Aを示す認可チャレンジを受け、共有鍵を使用して暗号化された有効性情報を含む応答コードを、サーバ・ユーザ・インタフェース２５を介してユーザ２に提供するように構成され、共有鍵は、記憶された機関秘密鍵ｄ_Bと、機器公開鍵Ｑ_Aとを使用して認証サーバ２０において導出される。

いくつかの実施形態では、サーバ・インタフェースは、ヒューマン‐マシン・インタフェース、又はユーザのユーザ・デバイスと通信するように構成されたマシン‐マシン・インタフェースである。

いくつかの実施形態では、認証サーバは、ユーザ２の認可レベル、時間パラメータ、及びユーザ２の位置のうちの少なくとも１つに基づいて応答コードを決定するように構成される。

いくつかの実施形態では、認証サーバは、認証に関連する情報をログに記録するように構成される。

図６ａは、提案される技術が実施されてもよい医療機器１０、１０´を説明する。医療機器１０、１０´は例えば、血液透析、血液透析濾過、血液濾過、又は限外濾過のような腎代替療法の一部として、体外血液処置を実行する医療処置に関与されてもよい。１０で示される医療機器は血液処理装置であり、これは、例えば血管アクセスにおいて、対象１００の循環系に接続するための脱血ライン１１Ａ及び返血ライン１１Ｂを備える。矢印で示すように、医療機器１０は、対象１００（例えば、人間）から血液を抜き取り、血液を処理し、処理された血液を制御された方法で対象１００に戻すように動作可能である。１０´で示される医療機器は、血液処理装置１０によって使用される流体を準備するように動作可能であり、流体を血液処理装置１０に供給するための流体ライン１１を備える。一例では、医療機器１０´は、水調製装置であり、流体は精製水である。例えば、水処理装置１０´は、当技術分野で知られているように、逆浸透によって、入ってくる水を濾過してもよい。

図示の簡略化された例では、医療機器１０は、対象１００に接続するための流体ライン１１と、機器ユーザ・インタフェース１９と、制御装置１６と、流体ライン１１を介して対象１００に医療流体を制御送達するための１つ以上のアクチュエータ１７と、注入ポンプによって実行される注入プロセスを示すセンサ・データを提供するための１つ以上のセンサ１８とを備える。アクチュエータ１７及びセンサ１８は、医療機器１０の内部構成要素（破線で示す）又は外部構成要素、あるいはその両方を含んでもよい。機器ユーザ・インタフェース１９は、ディスプレイ１２と、制御ボタン１３（１つを図示）と、インジケータ・ランプ１４と、スピーカ１５とを備える。

アクチュエータ１７は例えば、医療処置を実行する間に使用されるバルブ、ポンプ及び／又はヒータを制御するように構成される。言い換えると、アクチュエータ１７は、医療処置を制御するように構成される。

制御装置１６は、血液処理装置の意図された医療処置を実行するために、ならびに医療処置に関連して必要に応じてディスプレイ１２、インジケータ・ランプ１４、及びスピーカ１５を動作させるために、アクチュエータ１７及びセンサ１８の動作を調整し、制御ボタン１３を介してユーザ入力を取得するように構成される。例えば、ディスプレイ１２は、医療機器１０のユーザに命令を提示するように動作されてもよく、インジケータ・ランプ１４は、医療機器の状態を示すように動作されてもよく、スピーカ１５は、アラーム信号などを発生するように動作されてもよい。

医療機器１０は、いかなるリモート・システムにも接続されていない。それゆえ、医療機器はオフラインである。特に、これは認証システム２０（図２ｂ）からオフラインである。

医療機器１０´は、図示された詳細レベルにおいて、医療機器１０と同様の構成要素の集合を有してもよく、これ以上説明しない。医療機器１０、１０´は、簡潔にするために本書では説明しない、図示されているよりも多くの構成要素を含んでもよい。

医療機器１０，１０´は、体外血液処理を行う医療処置に関与される。それゆえ、患者のセキュリティに起因して、信頼できるユーザのみが医療機器１０、１０´にアクセスすることが認可されることは、そのようなアクセスが将来の処置を危険にさらす可能性があるため、非常に重要である。

図６ｂは、両頭矢印によって示されるように、制御された方法で対象１００の腹腔に透析液を送達し、続いて、そこから透析液を除去するように動作可能である別の例示的な医療機器１０を説明する。この医療処置は自動腹膜透析として一般に知られており、医療機器１０はしばしば「ＰＤサイクラ」と呼ばれる。図６ｂの医療機器１０は、図６ａの医療機器１０と比較して、図示された詳細レベルで、同様の（しかし、典型的には低減された）構成要素の集合を有してもよい。

図６ｃは、矢印によって示されるように、制御された方法で、人間のような対象１００の身体に、例えば対象１００の循環系に、医療流体を送達するように動作可能であるさらなる例示的な医療機器１０を説明する。医療流体は、薬物及び／又は栄養素を含むがこれらに限定されない任意の適切な液体であってもよい。このタイプの医療機器１０は、一般に「注入ポンプ」として知られている。図６ｃの医療機器１０は、図示された詳細レベルで、図６ｂの医療機器１０と同様の構成要素の集合を有してもよく、これ以上説明しない。図６ｃの医療機器１０は、簡潔にするために本書では説明しない、図示されているよりも多くの構成要素を含んでもよい。

Claims (29)

1. 機器インタフェースを介して、認証サーバ（２０）からオフラインである医療機器（１０）へのアクセスをユーザ（２）に認可するための方法であって、前記医療機器（１０）において、
   ‐前記認証サーバ（２０）に関連する機関非対称鍵ペアの機関公開鍵（Ｑ_B）を記憶すること（Ｓ０）と、
   ‐ユーザが前記医療機器にアクセスすることを望むごとに、前記医療機器（１０）で生成された一時的機器非対称鍵ペアの機器公開鍵（Ｑ_A）を示す認可チャレンジを、前記機器インタフェースを介して前記ユーザ（２）に提供すること（Ｓ３）であって、前記認可チャレンジは、前記認証サーバ（２０）が前記医療機器（１０）を識別することを可能にする機器識別情報を含む、ことと、
   ‐前記機関非対称鍵ペアの機関秘密鍵（ｄ_B）と、前記提供された機器公開鍵（Ｑ_A）とから導出可能な共有鍵を使用して暗号化された有効性情報を含む応答コードを、前記機器インタフェースを介して前記ユーザ（２）から受けること（Ｓ４）と、
   ‐同じ共有鍵であるが、前記記憶された機関公開鍵（Ｑ_B）と、前記一時的機器非対称鍵ペアの機器秘密鍵（ｄ_A）とを使用して前記医療機器（１０）において導出された共有鍵を使用して復号された前記有効性情報が有効であることに応じて、前記医療機器（１０）へのアクセスを前記ユーザ（２）に認可すること（Ｓ７）と、を有する方法。
2. 請求項１に記載の方法であって、前記機器インタフェースは、ヒューマン‐マシン・インタフェース、又は前記ユーザのユーザ・デバイスと通信するように構成されたマシン‐マシン・インタフェースである、方法。
3. 請求項１又は２に記載の方法であって、前記認可すること（Ｓ７）は、前記応答コードに含まれる情報に依存して、異なるレベルのアクセスを前記ユーザ（２）に認可することを含む、方法。
4. 請求項１乃至３の何れか１項に記載の方法であって、前記認可することは、１つ以上のセッションへの所定のアクセスを認可することと、所定の用途のために前記医療機器をロック解除することと、一時的な非通常使用を認可することとのうちの少なくとも１つについての前記ユーザ（２）への認可を含む、方法。
5. 請求項１乃至４の何れか１項に記載の方法であって、前記認可すること（Ｓ７）は、所定の期間中にアクセスを認可することを含む、方法。
6. 請求項１乃至５の何れか１項に記載の方法であって、
   ‐前記ユーザ（２）へのアクセスの認可を開始するユーザ入力を受けること（Ｓ１）を有する、方法。
7. 請求項１乃至６の何れか１項に記載の方法であって、
   ‐前記一時的機器非対称鍵ペアを破棄すること（Ｓ８）を有する、方法。
8. サーバ・ユーザ・インタフェース（２５）を介して、認証サーバ（２０）からオフラインである医療機器（１０）へのアクセスをユーザ（２）に認可するための方法であって、前記方法は、前記認証サーバ（２０）において、
   ‐前記認証サーバ（２０）に関連する機関非対称鍵ペアの機関秘密鍵（ｄ_B）を記憶すること（Ｓ２０）と、
   ‐前記ユーザ（２）を認証すること（Ｓ２１）と、
   ‐前記医療機器（１０）に関連する一時的機器非対称鍵ペアの機器公開鍵（Ｑ_A）を示し、ユーザが前記医療機器にアクセスすることを望むごとに前記医療機器（１０）において生成される認可チャレンジを、前記サーバ・ユーザ・インタフェース（２５）を介して前記ユーザ（２）から受けること（Ｓ２２）であって、前記認可チャレンジは、前記認証サーバ（２０）が前記医療機器（１０）を識別することを可能にする機器識別情報を含む、ことと、
   ‐共有鍵を使用して暗号化された有効性情報を含む応答コードを、前記サーバ・ユーザ・インタフェース（２５）を介して前記ユーザ（２）に提供すること（Ｓ２６）であって、前記共有鍵は、前記記憶された機関秘密鍵（ｄ_B）と、前記機器公開鍵（Ｑ_A）とを使用して前記認証サーバ（２０）において導出される、ことと、を有する方法。
9. 請求項８に記載の方法であって、前記サーバ・ユーザ・インタフェースは、ヒューマン‐マシン・インタフェース、又は前記ユーザのユーザ・デバイスと通信するように構成されたマシン‐マシン・インタフェースである、方法。
10. 請求項８又は９に記載の方法であって、前記方法は、前記ユーザ（２）の認可レベルと、時間パラメータと、前記ユーザ（２）の位置とのうちの少なくとも１つに基づいて、前記応答コードを決定すること（２４）を有する、方法。
11. 請求項８乃至１０の何れか１項に記載の方法であって、
    ‐前記認証に関連する情報をログに記録すること（Ｓ２７）を有する、方法。
12. 請求項１乃至１１の何れか１項に記載の方法であって、前記機関非対称鍵ペア及び前記一時的機器非対称鍵ペアは、前記機関非対称鍵ペア及び前記一時的機器非対称鍵ペアの一方の秘密鍵（ｐ）を、前記機関非対称鍵ペア及び前記一時的機器非対称鍵ペアの他方の公開鍵（Ｑ）とともに使用する場合に、反対の場合と同じ共有鍵が導出されるように生成される、方法。
13. 請求項１乃至１２の何れか１項に記載の方法であって、前記共有鍵は、ディフィー‐ヘルマン関数を使用して導出される、方法。
14. 請求項１乃至１３の何れか１項に記載の方法であって、前記機関非対称鍵ペア及び前記一時的機器非対称鍵ペアは、楕円曲線暗号方式（ＥＣＣ）、又はリベスト‐シャミア‐エーデルマン（ＲＳＡ）を使用して生成される、方法。
15. 請求項１乃至１４の何れか１項に記載の方法であって、前記有効性情報は、前記医療機器（１）のデバイス識別子と、前記医療機器（１）のアドレスと、事前に規定されたデータ・シーケンスと、事前に規定されたルールを使用して決定されたデータ・シーケンスとのうちの少なくとも１つを含む、方法。
16. 医療機器（１０）であって、
    ‐機器インタフェース（１９）と、
    ‐認証サーバ（２０）に、
    ・前記医療機器（１０）からオフラインである認証サーバ（２０）に関連する機関非対称鍵ペアの機関公開鍵（Ｑ_B）を記憶することと、
    ・ユーザが前記医療機器にアクセスすることを望むごとに、前記医療機器（１０）で生成された一時的機器非対称鍵ペアの機器公開鍵（Ｑ_A）を示す認可チャレンジを、前記機器インタフェースを介して前記ユーザ（２）に提供することであって、前記認可チャレンジは、前記認証サーバ（２０）が前記医療機器（１０）を識別することを可能にする機器識別情報を含む、ことと、
    ・前記機関非対称鍵ペアの機関秘密鍵（ｄ_B）と、前記提供された機器公開鍵（Ｑ_A）とから導出可能な共有鍵を使用して暗号化された有効性情報を含む応答コードを、前記機器インタフェースを介して前記ユーザ（２）から受けることと、
    ・同じ共有鍵であるが、前記記憶された機関公開鍵（Ｑ_B）と、前記一時的機器非対称鍵ペアの機器秘密鍵（ｄ_A）とを使用して前記医療機器（１０）において導出された共有鍵を使用して復号された前記有効性情報が有効であることに応じて、前記医療機器（１０）へのアクセスを前記ユーザ（２）に認可することと、
    を行わせるように構成された制御装置（１６）と、を備える医療機器（１０）。
17. 請求項１６に記載の医療機器（１０）であって、前記機器インタフェースは、ヒューマン‐マシン・インタフェース、又は前記ユーザのユーザ・デバイスと通信するように構成されたマシン‐マシン・インタフェースである、医療機器（１０）。
18. 請求項１６又は１７に記載の医療機器（１０）であって、前記制御装置（１６）は、前記応答コードに含まれる情報に依存して、異なるレベルのアクセスを前記ユーザ（２）に認可するように構成される、医療機器（１０）。
19. 請求項１６乃至１８の何れか１項に記載の医療機器（１０）であって、前記制御装置（１６）は、１つ以上のセッションへの所定のアクセスを認可することと、所定の用途のために前記医療機器をロック解除することと、一時的な非通常使用を認可することとのうちの少なくとも１つについてアクセスを前記ユーザ（２）に認可するように構成される、医療機器（１０）。
20. 請求項１６乃至１９の何れか１項に記載の医療機器（１０）であって、前記制御装置（１６）は、所定の期間中にアクセスを認可するように構成される、医療機器（１０）。
21. 請求項１６乃至２０の何れか１項に記載の医療機器（１０）であって、前記制御装置（１６）は、
    ‐前記ユーザ（２）へのアクセスの認可を開始するユーザ入力を、前記機器インタフェースを介して受けるように構成される、医療機器（１０）。
22. 請求項１６乃至２１の何れか１項に記載の医療機器（１０）であって、前記制御装置（１６）は、
    ‐前記一時的機器非対称鍵ペアを破棄するように構成される、医療機器（１０）。
23. サーバ・ユーザ・インタフェース（２５）を備える認証サーバ（２０）であって、前記認証サーバ（２０）は、
    ・前記認証サーバ（２０）に関連する機関非対称鍵ペアの機関秘密鍵（ｄ_B）を記憶することと、
    ・ユーザ（２）を認証することと、
    ・前記認証サーバ（２０）からオフラインである医療機器（１０）に関連する一時的機器非対称鍵ペアの機器公開鍵（Ｑ_A）を示し、ユーザが前記医療機器（１０）にアクセスすることを望むごとに前記医療機器（１０）において生成される認可チャレンジを、前記サーバ・ユーザ・インタフェース（２５）を介して前記ユーザ（２）から受けることであって、前記認可チャレンジは、前記認証サーバ（２０）が前記医療機器（１０）を識別することを可能にする機器識別情報を含む、ことと、
    ・共有鍵を使用して暗号化された有効性情報を含む応答コードを、前記サーバ・ユーザ・インタフェース（２５）を介して前記ユーザ（２）に提供することであって、前記共有鍵は、前記記憶された機関秘密鍵（ｄ_B）と、前記機器公開鍵（Ｑ_A）とを使用して前記認証サーバ（２０）において導出される、ことと、
    を行うように構成される、認証サーバ（２０）。
24. 請求項２３に記載の認証サーバ（２０）であって、前記サーバ・ユーザ・インタフェースは、ヒューマン‐マシン・インタフェース、又は前記ユーザのユーザ・デバイスと通信するように構成されたマシン‐マシン・インタフェースである、認証サーバ（２０）。
25. 請求項２３又は２４に記載の認証サーバ（２０）であって、前記認証サーバ（２０）は、前記ユーザ（２）の認可レベルと、時間パラメータと、前記ユーザ（２）の位置とのうちの少なくとも１つに基づいて、前記応答コードを決定するように構成される、認証サーバ（２０）。
26. 請求項２３乃至２５の何れか１項に記載の認証サーバ（２０）であって、前記認証サーバ（２０）は、前記認証に関連する情報をログに記録するように構成されること（Ｓ２７）を有する、認証サーバ（２０）。
27. コンピュータで動作された場合に、請求項１乃至７又は８乃至１５の何れか１項に記載の方法を前記コンピュータに実行させるコード手段を特徴とするコンピュータ・プログラム。
28. 請求項２７に記載のコンピュータ・プログラムが記憶されているコンピュータ可読媒体。
29. 請求項１６乃至２２の何れか１項に記載の医療機器（１０）と、請求項２３乃至２６の何れか１項に記載の認証サーバ（２０）とを備えるシステム。

Images