(57)【要約】      （修正有）【課題】クラウドサーバー上のクラウドリポジトリと前記クラウドサーバーに接続された医療施設の複数のローカルサーバー上の複数のローカルリポジトリとの間で医療データを同期するシステムにおいて医療データを事前取得する方法を提供する。【解決手段】医療データを事前取得する方法は、クラウドサーバーにより実行されるものであり、未来の診断日を示すタイミング情報と、診断予約情報をクラウドサーバーに保存されている医用画像と関連付ける診断情報と、を含む診断予約情報を受け取ることと、事前取得期間を含む事前取得要求を受け取ることと、事前取得要求を受け取ると、診断予約情報のタイミング情報が、事前取得期間と重複すると判断することと、医用画像が診断予約情報と関連付けられていると、医用画像及びデータを送信することと、を有する。【選択図】図１２
2019215844.tif 000002
【特許請求の範囲】
【請求項１】
クラウドサーバー上のクラウドリポジトリと前記クラウドサーバーに接続された医療施設の複数のローカルサーバー上の複数のローカルリポジトリとの間で医療データを同期するシステムにおいて医療データを事前取得する方法であって、
前記医療施設には、少なくとも、第１のローカルリポジトリを備える第１の医療施設と、第２のローカルリポジトリを備える第２の医療施設とが含まれ、
前記方法は、
前記クラウドサーバーが、前記第１の医療施設から、未来の診断日を示すタイミング情報と、診断予約情報を前記クラウドサーバーに保存されている医用画像と関連付ける診断情報と、を含む前記診断予約情報を受け取ることと、
前記クラウドサーバーが、前記第２の医療施設から、事前取得期間を含む事前取得要求を受け取ることと、
前記クラウドサーバーが、前記事前取得要求を受け取ると、前記診断予約情報のタイミング情報が、前記事前取得期間と重複すると判断することと、
前記医用画像が前記診断予約情報と関連付けられていると、前記クラウドサーバーが、前記第２のローカルリポジトリに、前記医用画像及びデータを送信することと、
を有する方法。
【請求項２】
前記医用画像が、前記第２のローカルリポジトリに一時的に保存される、請求項１に記載の方法。
【請求項３】
前記クラウドサーバーが、前記第２の医療施設から所定のペースで定期的に前記事前取得要求を受け取り、
前記事前取得期間は、前記各事前取得要求によって異なる、請求項１に記載の方法。
【請求項４】
前記第２の医療施設は、前記第１の医療施設よりも大規模である、請求項１に記載の方法。
【請求項５】
前記第１の医療施設は、１次診断が行われる場所であり、
前記第２の医療施設は、２次診断が行われる場所であり、
前記２次診断は、前記１次診断の追診断である、請求項１に記載の方法。
【請求項６】
前記各ローカルサーバーは、医療施設に配置されたアプリケーションプロキシサーバー（ＡＰＳ）である、請求項１に記載の方法。
【請求項７】
前記医用画像は、医療におけるデジタル画像と通信フォーマット（ＤＩＣＯＭフォーマット）の医用画像である、請求項１に記載の方法。
【請求項８】
前記診断予約情報は、前記医用画像のメタデータとして保存される、請求項７に記載の方法。
【請求項９】
前記各ローカルサーバーは、表示部を備えるローカルコンピューターと接続されている、請求項１に記載の方法。
【請求項１０】
前記クラウドサーバー上のクラウドリポジトリは、クラウドベースの画像保管通信システム（ＰＡＣＳ）用のリポジトリである、請求項１に記載の方法。
【請求項１１】
コンピューターと組み合わされたクラウドサーバーに、クラウドサーバー上のクラウドリポジトリと前記クラウドサーバーに接続された医療施設の複数のローカルサーバー上の複数のローカルリポジトリとの間で医療データを同期するシステムにおいて、医療データを事前取得する動作を実行させる指示を記憶した非一時的なコンピューター読み取り可能な媒体（ＣＲＭ）であって、
前記医療施設には、少なくとも、第１のローカルリポジトリを備える第１の医療施設と、第２のローカルリポジトリを備える第２の医療施設とが含まれ、
前記動作は、
前記クラウドサーバーが、前記第１の医療施設から、未来の診断日を示すタイミング情報と、診断予約情報を前記クラウドサーバーに保存されている医用画像と関連付ける診断情報と、を含む前記診断予約情報を受け取ることと、
前記クラウドサーバーが、前記第２の医療施設から、事前取得期間を含む事前取得要求を受け取ることと、
前記クラウドサーバーが、前記事前取得要求を受け取ると、前記診断予約情報のタイミング情報が、前記事前取得期間と重複すると判断することと、
前記医用画像が前記診断予約情報と関連付けられていると、前記クラウドサーバーが、前記第２のローカルリポジトリに、前記医用画像及びデータを送信することと、
を有するＣＲＭ。
【請求項１２】
前記医用画像が、前記第２のローカルリポジトリに一時的に保存される、請求項１１に記載のＣＲＭ。
【請求項１３】
前記クラウドサーバーが、前記第２の医療施設から所定のペースで定期的に前記事前取得要求を受け取り、
前記事前取得期間は、前記各事前取得要求によって異なる、請求項１１に記載のＣＲＭ。
【請求項１４】
前記第２の医療施設は、前記第１の医療施設よりも大規模である、請求項１１に記載のＣＲＭ。
【請求項１５】
前記第１の医療施設は、１次診断が行われる場所であり、
前記第２の医療施設は、２次診断が行われる場所であり、
前記２次診断は、前記１次診断の追診断である、請求項１１に記載のＣＲＭ。
【請求項１６】
医療データを同期するシステムであって、
クラウドサーバーと、
前記クラウドサーバー上のクラウドリポジトリと、
前記クラウドサーバーに接続された医療施設の複数のローカルサーバー上の複数のローカルリポジトリと、
を有し、
前記医療施設には、少なくとも、第１のローカルリポジトリを備える第１の医療施設と、第２のローカルリポジトリを備える第２の医療施設とが含まれ、
前記クラウドサーバーは、
前記第１の医療施設から、未来の診断日を示すタイミング情報と、診断予約情報を前記クラウドサーバーに保存されている医用画像と関連付ける診断情報と、を含む前記診断予約情報を受け取り、
前記第２の医療施設から、事前取得期間を含む事前取得要求を受け取り、
前記事前取得要求を受け取ると、前記診断予約情報のタイミング情報が、前記事前取得期間と重複すると判断し、
前記医用画像が前記診断予約情報と関連付けられていると、前記第２のローカルリポジトリに、前記医用画像及びデータを送信する、
システム。
【請求項１７】
前記医用画像が、前記第２のローカルリポジトリに一時的に保存される、請求項１６に記載のシステム。
【請求項１８】
前記クラウドサーバーが、前記第２の医療施設から所定のペースで定期的に前記事前取得要求を受け取り、
前記事前取得期間は、前記各事前取得要求によって異なる、請求項１６に記載のシステム。
【請求項１９】
前記第２の医療施設は、前記第１の医療施設よりも大規模である、請求項１６に記載のシステム。
【請求項２０】
前記第１の医療施設は、１次診断が行われる場所であり、
前記第２の医療施設は、２次診断が行われる場所であり、
前記２次診断は、前記１次診断の追診断である、請求項１６に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
医用画像及び医療データは、患者を診断するのに重要な役割を果たしている。医療施設（例えば、病院）では、電子的に保存された医用画像及び医療データの有益性が認識されるようになっている。医用画像及びデータをデジタル化すると、ユーザーが医用画像及び医療データに容易にアクセスできるようになるだけでなく、複数の医療施設の間で画像及びデータを容易に共有することができるようになる。
【０００２】
医療産業では、画像保管通信システム（「ＰＡＣＳ」）と呼ばれるシステムの使用が、医用画像の保存及びアクセスに便利であることから一般的になりつつある。一般的に、ＰＡＣＳには多数の装置が含まれ、これらが協働して、コンピューター断層撮影（ＣＴ）、核磁気共鳴映像法（ＭＲＩ）、ポジトロン放出断層撮影法（ＰＥＴ）、超音波、Ｘ線等の様々な撮像モダリティーにより生成された医用画像を取得、保存、管理、配布及び表示する。ＰＡＣＳによれば、内部又は外部で撮影されたあらゆる種類の画像を、様々な医療施設で共有することが可能となる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
より最近では、従来のＰＡＣＳの効率及びアクセス性を改善する手段として、クラウドベースのＰＡＣＳが出現している。一般に、「クラウド」とは、様々な場所にある複数のコンピューターやデバイスの要求に応じて、コンピューティングリソース及びデータへの遠隔アクセスをインターネット経由で提供するオンラインストレージシステムと理解することができる。クラウドベースＰＡＣＳは、様々な場所にある遠隔又はオフサイトのデータセンターを医用画像の保存に用いるベンダーによって提供されうる。
【課題を解決するための手段】
【０００４】
概して、一の態様では、本発明は、クラウドサーバー上のクラウドリポジトリと前記クラウドサーバーに接続された医療施設の複数のローカルサーバー上の複数のローカルリポジトリとの間で医療データを同期するシステムにおいて医療データを事前取得する方法に関し、前記医療施設には、少なくとも、第１のローカルリポジトリを備える第１の医療施設と、第２のローカルリポジトリを備える第２の医療施設とが含まれる。前記方法は、前記クラウドサーバーが、前記第１の医療施設から、未来の診断日を示すタイミング情報と、診断予約情報を前記クラウドサーバーに保存されている医用画像と関連付ける診断情報と、を含む前記診断予約情報を受け取ることと、前記クラウドサーバーが、前記第２の医療施設から、事前取得期間を含む事前取得要求を受け取ることと、前記クラウドサーバーが、前記事前取得要求を受け取ると、前記診断予約情報のタイミング情報が、前記事前取得期間と重複すると判断することと、前記医用画像が前記診断予約情報と関連付けられていると、前記クラウドサーバーが、前記第２のローカルリポジトリに、前記医用画像及びデータを送信することと、を有する。
【０００５】
概して、一の態様では、本発明は、コンピューターと組み合わされたクラウドサーバーに、クラウドサーバー上のクラウドリポジトリと前記クラウドサーバーに接続された医療施設の複数のローカルサーバー上の複数のローカルリポジトリとの間で医療データを同期するシステムにおいて、医療データを事前取得する動作を実行させる指示を記憶した非一時的なコンピューター読み取り可能な媒体（ＣＲＭ）に関し、前記医療施設には、少なくとも、第１のローカルリポジトリを備える第１の医療施設と、第２のローカルリポジトリを備える第２の医療施設とが含まれる。前記動作は、前記クラウドサーバーが、前記第１の医療施設から、未来の診断日を示すタイミング情報と、診断予約情報を前記クラウドサーバーに保存されている医用画像と関連付ける診断情報と、を含む前記診断予約情報を受け取ることと、前記クラウドサーバーが、前記第２の医療施設から、事前取得期間を含む事前取得要求を受け取ることと、前記クラウドサーバーが、前記事前取得要求を受け取ると、前記診断予約情報のタイミング情報が、前記事前取得期間と重複すると判断することと、前記医用画像が前記診断予約情報と関連付けられていると、前記クラウドサーバーが、前記第２のローカルリポジトリに、前記医用画像及びデータを送信することと、を有する。
【０００６】
概して、一の態様では、本発明は、医療データを同期するシステムに関する。前記システムは、クラウドサーバーと、前記クラウドサーバー上のクラウドリポジトリと、前記クラウドサーバーに接続された医療施設の複数のローカルサーバー上の複数のローカルリポジトリと、を有し、前記医療施設には、少なくとも、第１のローカルリポジトリを備える第１の医療施設と、第２のローカルリポジトリを備える第２の医療施設とが含まれ、前記クラウドサーバーは、前記第１の医療施設から、未来の診断日を示すタイミング情報と、診断予約情報を前記クラウドサーバーに保存されている医用画像と関連付ける診断情報と、を含む前記診断予約情報を受け取り、前記第２の医療施設から、事前取得期間を含む事前取得要求を受け取り、前記事前取得要求を受け取ると、前記診断予約情報のタイミング情報が、前記事前取得期間と重複すると判断し、前記医用画像が前記診断予約情報と関連付けられていると、前記第２のローカルリポジトリに、前記医用画像及びデータを送信する。
【０００７】
本発明の他の側面及び利点は、以下の説明及び添付の請求の範囲から明らかとなるであろう。
【図面の簡単な説明】
【０００８】
【図１Ａ】１つ以上の実施形態に係るシステムを示す。
【図１Ｂ】１つ以上の実施形態に係るシステムを示す。
【図２Ａ】１つ以上の実施形態に係る表示メッセージを示す。
【図２Ｂ】１つ以上の実施形態に係る表示メッセージを示す。
【図３】１つ以上の実施形態に係るデータテーブルを示す。
【図４】１つ以上の実施形態に係る図１Ａ及び図１Ｂのシステムの状態を示す。
【図５】１つ以上の実施形態に係る図１Ａ及び図１Ｂのシステムの状態を示す。
【図６】１つ以上の実施形態に係る図１Ａ及び図１Ｂのシステムの状態を示す。
【図７】１つ以上の実施形態に係る図１Ａ及び図１Ｂのシステムの状態を示す。
【図８Ａ】１つ以上の実施形態に係る実施例を示す。
【図８Ｂ】１つ以上の実施形態に係る実施例を示す。
【図８Ｃ】１つ以上の実施形態に係る実施例を示す。
【図９】１つ以上の実施形態に係るコンピューターシステムを示す。
【図１０】１つ以上の実施形態に係るコンピューターシステムを示す。
【図１１Ａ】１つ以上の実施形態の１つ以上に係るフローチャートを示す。
【図１１Ｂ】１つ以上の実施形態の１つ以上に係るフローチャートを示す。
【図１２】１つ以上の実施形態に係るフローチャートを示す。
【発明を実施するための形態】
【０００９】
ここで、添付の図面を参照しながら具体的な実施形態を詳細に説明する。一貫性を保つため、各図面における類似の要素には、類似の参照番号を付している。簡便のため、全ての図において類似の要素に符号を付しているわけではない。
【００１０】
本開示における実施形態の以下の詳細な説明には、本開示のより完全な理解のために、多数の細部が具体的に記載されている。しかし、当業者であれば、これらの具体的な細部がなくとも本開示を実施しうることが明らかであろう。他の例においては、説明が不必要に複雑になるのを避けるため、周知の特徴については詳細に記載しないこととした。
【００１１】
本出願を通して、序数（例えば、第１、第２、第３等）は、要素（すなわち、本出願におけるあらゆる名詞）の形容詞として用いうる。序数の使用は、例えば「前」、「後」、「単数の」や、その他の用語を使用して明示的に開示されていない限り、要素の特定の序列を示唆するものでも、要素に特定の序列をつけるものでもなく、ある要素を単数に限定するものでもない。むしろ、序数の使用は、要素の区別を目的としている。例えば、第１の要素は、第２の要素と区別され、また、第１の要素は、２つ以上の要素を含んでいてもよく、要素の順序付けとしては第２の要素の後（又は前）であってもよい。
【００１２】
文脈上明確に示されていない限り、単数形の「ａ」、「ａｎ」及び「ｔｈｅ」は、複数も対象として含まれると理解すべきである。よって、例えば「水平ビーム（a horizontal beam）」への言及には、１つ以上のビームへの言及が含まれる。
【００１３】
「おおよそ」、「実質的に」等の用語は、記載される特徴、パラメーター又は値が正確に達成される必要がないことを意味し、例えば許容度、測定誤差、測定の精度限界及びその他の当業者に公知の要因等を含む偏差又は変動が、その特徴により得られるとされる効果を阻害しない程度で起こりうることを意味する。
【００１４】
フローチャートに示す工程は、その１つ以上について、省略され、繰り返され、及び／又は記載とは異なる順序で実行されうることを理解すべきである。したがって、本発明の範囲は、フローチャートに示す具体的な工程順に限定されると解するべきではない。
【００１５】
多項従属クレームは導入していないものの、１つ以上の実施形態についての従属クレームの主題を、他の従属クレームと組み合わせうることは、当業者にとって明らかであろう。
【００１６】
概して、本発明の１つ以上の実施形態によれば、予定された患者の診断に先立って医用画像及びデータ（本明細書では単に「医用画像」とも言う。）を自動的に取得（すなわち、プリフェッチ及び／又は事前取得）する機構を備えた、医用画像及びデータのクラウドからローカル、ローカルからクラウドへの切り替えと同期のために構成された方法、非一時的なコンピューター読み取り可能な媒体及びシステムが提供される。１つ以上の実施形態に係るクラウドベースＰＡＣＳによれば、クラウドのデータリポジトリ又はデーターベース（「クラウドリポジトリ」）へのアクセスが許可された全ての医療施設、例えば同じ病院グループ内の施設において、医用画像及びデータを共有することが可能となる。医用画像及びデータには、患者の医用レポート（medical report）も含まれうる。例えば、医療施設は、「ネットワーク内の」（すなわち、クラウドリポジトリの同一部分へのアクセスが許可された）他の医療施設において得られた患者の医用画像及びデータにアクセスして、それを取得することができる。具体的には、１つ以上の実施形態によれば、ネットワーク内の医療施設は、クラウドベースＰＡＣＳをより効果的に利用して、１つ以上のネットワーク内の複数の医療施設を頻繁に訪れる患者について、医用画像及びデータを共有し、更新することができる。
【００１７】
さらに、従来のクラウドベースＰＡＣＳとは異なり、本発明の１つ以上の実施形態によれば、クラウドベースＰＡＣＳを利用する医療施設は、クラウドとのネットワーク接続が切れても、稼働を続けることが可能である。具体的には、１つ以上の実施形態を利用するネットワーク内の医療施設は、クラウドベースＰＡＣＳのユーザー（例えば、医療専門家）からの要請に基づき、ローカルサーバー上にある現場又はローカルのデータリポジトリ又はデータベース（「ローカルリポジトリ」）を、クラウドリポジトリに保存されている患者の最新の画像及びデータで自動的に更新して最新の状態に保つことができる。例えば、ある施設が、ある特定の患者の新たな医用画像を更新又は取得すると、クラウドリポジトリが、その更新された医用画像又は新たな医用画像により自動的に更新されてもよく、同じ患者を治療又は看護するネットワーク内の施設の全てのローカルリポジトリが、クラウドリポジトリと自動的に同期されてもよい。
【００１８】
１つ以上の実施形態によれば、接続が失われた場合、接続が切れた医療施設は、クラウドリポジトリに代えてローカルリポジトリへのアクセスに自動的に切り替える。これにより、医療施設は、ネットワークからの切断に起因するダウンタイムを被ることなく、連続して稼働することができる。ネットワーク内の施設は、そのローカルリポジトリがクラウドリポジトリと同期しているので、クラウドとの接続がなくとも、少なくとも一時的に最新のデータにアクセスして業務を行うことができる。しかし、クラウドリポジトリ上の全てのデータを同期する必要はない。１つ以上の実施形態によれば、各施設にとって必要なデータ又は興味のあるデータについてのみ同期が行われる。例えば、ある施設は、自己の施設の患者ではない人に関する医用画像によって、ローカルリポジトリが満杯になったり、ローカルサーバーに負担がかかったりするのを望まないかもしれない。
【００１９】
１つ以上の実施形態によれば、接続が再確立すると、ネットワークが切断されていた時にローカルリポジトリに保存された医用画像及びデータが、クラウドリポジトリに自動的にアップロードされる。これにより、ネットワーク内の他の全ての医療施設が、それぞれのローカルリポジトリを最新の医用画像及びデータで更新することが可能となる。
【００２０】
１つ以上の実施形態によれば、クラウドベースＰＡＣＳは、医療データの事前取得機能を備えて構成される。患者の診断に先立って、クラウドに保存されている医用画像及びデータが、医療施設のローカルサーバーにより自動的に取得される。これにより、予定された診断を受けるために患者が各医療施設に到着する前に、医用画像及びデータを取得することが可能となり、クラウドサーバーから医用画像及びデータを取得するのに時間を要する結果起こる、診断の無駄な遅延が防止される。例えば、患者Ａは、医療施設Ａにおいて第１の診断（すなわち、１次診断）を受ける。そして、患者Ａは、医療施設Ｂにおいて追診断（follow-up diagnosis）（すなわち、２次診断）を受けることが予定されている。追診断の予定日時に患者Ａが医療施設Ｂに到着する前に、医療施設Ａで生成された患者Ａの医用画像及びデータは、医療施設Ｂのローカルシステムにおいて容易に利用可能となっており、医療施設Ｂの医師は、効率的な診断を行うことができうる。
【００２１】
図１Ａ及び図１Ｂは、本発明の１つ以上の実施形態に係るシステム（１００）を示す。図１Ａ及び図１Ｂに示すように、システム（１００）は、クラウドリポジトリ（１０５）を備えるクラウドサーバー（１０３）を有するクラウド（１０１）と、種々のネットワーク内の医療施設（参照符号なし）に付随の複数のローカルサーバー（１０７）（例えば、アプリケーションプロキシサーバー（ＡＰＳ））及びローカルリポジトリ（１０９）とを有する。複数のローカルサーバー（１０７）は、クラウドサーバー（１０３）へのアクセス／閲覧が許可されている。クラウドサーバー（１０３）上のリモートデータへのアクセス権に加えて、特定のローカルサーバー（１０７）は、さらにリモートデータの編集権を持っていてもよい。各医療施設は、公共病院、民間病院、医療クリニック、歯科クリニック等の、医療を提供する施設の一種であってもよい。
【００２２】
また、図１Ａ及び図１Ｂに示すように、システム（１００）内の各医療施設は、ローカルサーバー（１０７）と接続された複数のユーザーコンピューター装置（１１１）（ここでは、「ローカルコンピューター」と称する。）を有する。各ローカルコンピューター（１１１）は、パーソナルコンピューター（ＰＣ）、ラップトップ、モバイルコンピューター装置（例えば、タブレットＰＣ、スマートフォン等）、サーバー、メインフレーム、キオスク等に相当しうる。
【００２３】
１つ以上の実施形態によれば、クラウドリポジトリ（１０５）を備えるクラウドサーバー（１０３）は、クラウドベースＰＡＣＳを提供するベンダー又はそうしたベンダーと関連する別のサードパーティによって運用されうる。１つ以上の実施形態によれば、クラウドサーバー（１０３）は、アプリケーション及び情報の処理を行う実際の及び／又は仮想のコンピューターインフラストラクチャーである。例えば、クラウドサーバー（１０３）は、インターネットを介してリモートアクセスされる仮想又は実際のサーバーであってもよい。１つ以上の実施形態によれば、クラウドリポジトリ（１０５）は、データのオンラインリポジトリである。例えば、クラウドリポジトリは、インターネットを介してリモートアクセスされる仮想データルーム（ＶＤＲ）又はデータベース（又はデータベース群）であってもよい。
【００２４】
１つ以上の実施形態によれば、クラウドサーバー（１０３）は、ローカルサーバー（１０７）から送信された医用画像及びデータを受け取り、その医用画像及びデータをクラウドリポジトリ（１０５）にリモートデータとして保存するよう構成されている。
【００２５】
１つ以上の実施形態によれば、各ローカルサーバー（１０７）は、それが付随する医療施設により運用される。ローカルサーバー（１０７）は、ローカルコンピューター（１１１）から受け取った医用画像及びデータをクラウドサーバー（１０３）上のクラウドリポジトリ（１０５）に送信するよう構成されている。各ローカルリポジトリ（１０９）は、それが付随する医療施設により運用・保守される。ローカルリポジトリ（１０９）は、ローカルサーバー（１０７）及びクラウドリポジトリ（１０５）から受け取った医用画像及びデータをローカルデータとしてローカルで保存しうる。
【００２６】
１つ以上の実施形態によれば、ローカルコンピューター（１１１）は、それぞれの医療施設の医療専門家により運用され、医療施設内の１つ以上のモダリティー（図示せず）から取得した医用画像及びデータをローカルサーバー（１０７）に送信するよう構成されている。１つ以上の実施形態によれば、ローカルコンピューター（１１１）は、ローカルサーバー（１０７）として構成されうる。１つ以上の実施形態によれば、ローカルコンピューター（１１１）は、ローカルリポジトリ（１０９）も有していてもよい。
【００２７】
１つ以上の実施形態によれば、ローカルコンピューターは、クラウド（１０１）を運営するベンダーにより提供されるアプリケーションを記憶するよう構成されている。１つ以上の実施形態によれば、当該アプリケーションは、ベンダーと関連するサードパーティにより提供される医用同期アプリケーションであってもよい。医用同期アプリケーションは、当該アプリケーションが記憶された装置（すなわち、クラウド（１０１）又はローカルサーバー（１０７））に登録された独立したソフトウェアアプリケーションであるか、又はグラフィカルユーザーインターフェース（「ＧＵＩ」）を持つウェブブラウザーベースのアプリケーションであってもよく、このアプリケーションによって、ローカルコンピューター（１１１）は、クラウド（１０１）にアクセスして医療データをクラウド（１０１）と同期することが可能となる。１つ以上の実施形態によれば、クラウドサーバー（１０３）及び各ローカルサーバー（１０７）は、それぞれのリポジトリに医用同期アプリケーションのコピーを記憶していてもよい。
【００２８】
図１Ａは、１つ以上の実施形態に係る、ネットワーク内の医療施設とクラウド（１０１）との接続が安定している例を示す。この状態では、ネットワーク内の複数の医療施設が、クラウド（１０１）と相互通信しうる。図１Ａに示すように、ネットワーク内の医療施設は、ローカルで取得した医用画像及びデータをクラウド（１０１）に送信して、それらをクラウドリポジトリ（１０５）に他のネットワーク内の医療施設がアクセス可能なリモートデータとして保存しうる。１つ以上の実施形態によれば、ネットワーク内の医療施設は、クラウド（１０１）から医用画像及びデータを取得して、それらをそれぞれのローカルリポジトリ（１０９）にローカルデータとして保存しうる。
【００２９】
１つ以上の実施形態によれば、クラウドリポジトリ（１０５）に保存されているリモートデータの全てを、ネットワーク内の医療施設が取得してローカルデータとして保存する必要はない。ローカルデータとして取得され保存されるリモートデータは、そのサイズや医療施設での必要性によって、あるいはローカルコンピューター（１１１）（例えば、医療専門家）の設定によって様々であってもよい。例えば、ネットワーク内のある医療施設は、その施設の患者である特定の個人に基づき、リモートデータを取得し、ローカルリポジトリ（１０９）にローカルデータとして保存しうる。よって、特定の個人がネットワーク内の特定の医療施設の患者ではない場合、当該医療施設は、当該患者の医用画像及びデータを、ローカルデータとしてクラウド（１０１）から取得し保存しなくてもよい。これは、記憶装置や処理能力が限られる小規模なローカルサーバー（１０７）及びローカルリポジトリ（１０９）を備える小規模な医療施設にとって特に有益でありうる。本発明の１つ以上の実施形態によれば、ネットワーク内のある医療施設は、当該施設の患者である特定の個人に基づくのではなく、特定の医用検査（medical study）、医用シリーズ（medical series）、医用画像又は医用レポートに基づいて、リモートデータを取得し、ローカルリポジトリ（１０９）にローカルデータとして保存してもよい。
【００３０】
１つ以上の実施形態によれば、ネットワーク内の各医療施設におけるローカルコンピューター（１１１）のユーザーは、クラウドサーバー（１０３）に記憶されているウェブブラウザーベースのバージョンのアプリケーションを介して、クラウドリポジトリ（１０５）に保存されている医用画像及びデータを閲覧しうる。ユーザーは、ローカルコンピューター（１１１）に記憶されているローカルバージョンのアプリケーションを介しても、画像を閲覧しうる。例えば、医療専門家は、ローカルリポジトリ（１０９）に保存されたローカルデータのいずれかが、ネットワーク内の他の医療施設に属する別の医療専門家により更新されたかどうかを判断し、クラウドリポジトリ（１０５）から更新されたデータを取得して現在のローカルデータと置き換えてもよい。１つ以上の実施形態によれば、こうしたローカルデータの更新は、例えばローカルコンピューター（１１１）に記憶されたアプリケーションを通して、システム（１００）によって自動的に行われてもよい。
【００３１】
例えば、ある個人は、ネットワーク内の複数の医療施設の患者でありうる。ネットワーク内のこれらの各医療施設は、その個人の医用画像及びデータをローカルデータとして保存しうる。１つ以上の実施形態によれば、ネットワーク内の医療施設の１つによって、その個人の医用画像及びデータがクラウドリポジトリ（１０５）において更新されると、その個人が患者であるネットワーク内の他の医療施設は、自動的にその個人の更新された画像及びデータを取得（同期）して、ローカルリポジトリ（１０９）のローカルデータを最新の状態に保ちうる。このクラウドリポジトリ（１０５）の自動更新及び／又は関連するローカルリポジトリ（１０９）の同期は、個人の医用画像又はデータがクラウド上で更新されるたびに行われても、あるいは所定の間隔で行われてもよい。
【００３２】
１つ以上の実施形態によれば、クラウドリポジトリ（１０５）に保存されている医用画像及びデータは、予定された患者の診断（すなわち、患者が診断を受ける予約）に先立って、ローカルコンピューター（１１１）が自動的に取得しうる。１つ以上の実施形態によれば、患者の医用画像及びデータが生成された医療施設のユーザーは、当該医療施設のローカルコンピューター（１１１）からクラウドサーバー（１０３）に当該医用画像及びデータ並びに診断予約情報を送信して、それらをクラウドリポジトリ（１０５）に保存しうる。
【００３３】
１つ以上の実施形態によれば、患者の診断が予定されている別の医療施設のユーザーは、当該医療施設のローカルコンピューター（１１１）から、予定された患者の診断に先立ってクラウド（１０１）に保存された患者の医用画像及びデータを取得するための事前取得要求（advanced-retrieval request）を送信しうる。１つ以上の実施形態によれば、事前取得要求には、予定された患者の診断に先立って医用画像及びデータを取得する日時の対象範囲（例えば、２０１８年３月１８日の午前９時００分から午後９時００分）である事前取得期間が含まれる。１つ以上の実施形態によれば、事前取得要求は、ローカルコンピューターにより、所定のペースで定期的に自動送信されうる。
【００３４】
１つ以上の実施形態によれば、診断予約情報には、他の医療施設で予定されている患者の診断日時を示すタイミング情報と、診断予約情報をクラウドリポジトリ（１０５）に保存された医用画像及びデータに関連付ける（すなわち、組み合わせる）患者情報を含む診断情報とが含まれる。診断情報に含まれうる患者情報の詳細は、図３を参照して後述する。
【００３５】
図１Ｂは、１つ以上の実施形態に係る、ネットワーク内の医療施設の１つとクラウド（１０１）との接続が切れた例を示す。この状態では、アプリケーションは、接続が切れた医療施設のローカルコンピューター（１１１）及びローカルサーバー（１０７）を自動的に設定して、これらがローカルリポジトリ（１０９）に保存されているローカルデータにアクセスするようにする。１つ以上の実施形態によれば、接続が切れた医療施設では、接続が切れている間に取得されたり更新されたりした医用画像及びデータは、引き続きローカルリポジトリ（１０９）に保存され続ける。これにより、接続が切れた医療施設を、クラウド（１０１）からの切断に起因するダウンタイムを被ることなく、連続的に稼働することができる。
【００３６】
そして、接続が切れた医療施設とクラウド（１０１）との接続が再確立されると、再接続された医療施設のローカルコンピューター（１１１）及びローカルサーバー（１０７）は、ローカルリポジトリに保存されている、接続が切れている間に取得されたり更新されたりした全ての医用画像及びデータをクラウド（１０１）に送信するようアプリケーションによって設定される。そうした医用画像及びデータは、新たなリモートデータとしてクラウドリポジトリ（１０５）に保存される。クラウド（１０１）が再接続された医療施設からの医用画像及びデータにより更新される際、ネットワーク内の他の施設のローカルコンピューター（１１１）に記憶されているアプリケーションは、それぞれのローカルリポジトリ（１０９）を新たなリモートデータで自動的に更新しうる。
【００３７】
図２Ａ及び図２Ｂは、１つ以上の実施形態に係る表示メッセージ（２０１）であり、これは、ローカルコンピューター（１１１）のアプリケーションによりポップアップウインドウの一部としてユーザーに表示されうる。この例では、表示メッセージ（２０１）には、ユーザー選択可能タブ（２０３ａ及び２０３ｂ）（例えば、ユーザーがマウスのクリックにより選択可能なタブ）及びカウントダウンタイマー（２０５）が含まれる。表示メッセージ（２０１）は、ローカルコンピューター（１１１）のディスプレイにポップアップウインドウとして出現しうる。表示メッセージ（２０１）には、ネットワーク内の医療施設のローカルサーバー（１０７）とクラウドサーバー（１０３）との間の現在の接続状況に関するメッセージが含まれていてもよい。
【００３８】
図２Ａは、ネットワーク内の医療施設の１つのローカルサーバー（１０７）とクラウドサーバー（１０３）との間の接続が切れた時の表示メッセージ（２０１）の例である。この表示メッセージ（２０１）には、クラウド（１０１）との接続が切れた旨と、カウントダウンタイマー（２０５）が時間切れになると、ローカルコンピューター（１１１）がローカルリポジトリ（１０９）に自動的にアクセスする旨のメッセージが含まれるであろう。本明細書の説明によっては、図示のために単一のローカルリポジトリが用いられているが、各医療施設におけるローカルコンピューター及びローカルリポジトリの数は様々でありうる。
【００３９】
１つ以上の実施形態によれば、ローカルコンピューター（１１１）を操作しているユーザーは、カウントダウンタイマー（２０５）が時間切れになるのを待つか、ユーザー選択可能タブ（２０３ａ）を直接クリックするかのいずれかにより、クラウドリポジトリ（１０５）に代えてローカルリポジトリ（１０９）にアクセスしうる（すなわち、ローカルリポジトリ（１０９）へのアクセスに切り替えうる。）。
【００４０】
図２Ｂは、接続が切れていたネットワーク内の医療施設の１つのローカルサーバー（１０７）とクラウドサーバー（１０３）との間の接続が再確立された時の表示メッセージ（２０１）の例を示す。この表示メッセージ（２０１）には、クラウド（１０１）との接続が再確立された旨のメッセージと、ユーザー（例えば、医療専門家）に引き続きローカルリポジトリ（１０９）を用いるか、それともクラウドリポジトリ（１０５）に再アクセスするかを選択するよう促すメッセージとが含まれるであろう。１つ以上の実施形態によれば、システム（１００）のアプリケーションは、ローカルリポジトリの使用について、一時的に（例えば、予め定められた又は所定の時間）使用する選択肢しかユーザーに与えない。このような場合、図２Ｂの例に示すように、表示メッセージ（２０１）には、カウントダウンタイマー（２０５）が時間切れになれば、ローカルコンピューター（１１１）がクラウドリポジトリ（１０５）に自動的に再アクセスする（すなわち、アクセスを切り替えてクラウドリポジトリ（１０５）へと戻す）旨のメッセージがさらに含まれうる。
【００４１】
また、図２Ｂにおいて、１つ以上の実施形態によれば、ユーザーは、ネットワークリポジトリ（１０５）に即座に再アクセスするユーザー選択可能タブ（２０３ａ）を選択するか、あるいはローカルリポジトリ（１０９）を用いてローカルでの作業を続けるユーザー選択可能タブ（２０３ｂ）を選択しうる。この例においても、クラウドとの接続が再確立した後にローカルリポジトリを引き続き使用することは、制限される。予め定められた時間がすぎると、ユーザーは、別の表示メッセージ（２０１）によりクラウド（１０１）に再接続するよう促される。
【００４２】
図３は、各医用画像に関連付けされたデータを含むデータテーブル（３００）の例を示す。１つ以上の実施形態によれば、データテーブル（３００）には、患者ＩＤ（３０１）、患者名（３０３）、所属施設ＩＤ（３０５）、レポート情報（３０７）及び画像情報（３０９）等の患者に関連する情報が含まれうるが、これらに限定されない。
【００４３】
１つ以上の実施形態によれば、患者ＩＤ（３０１）は、個人の患者識別番号である。各個人は、単一かつ固有の患者ＩＤ（３０１）を持つことになる。個人の患者ＩＤ（３０１）は、ネットワーク内の医療施設間で共有される。患者名（３０３）は、個人の実名である。
【００４４】
１つ以上の実施形態によれば、所属施設ＩＤ（３０５）は、個人が患者であるネットワーク内の医療施設の識別番号（例えば、個人と関連するネットワーク内の医療施設）であってもよい。ある個人が、ネットワーク内の複数の医療施設の２つ以上を頻繁に利用している場合、その個人は、２つ以上の所属施設ＩＤ（３０５）と関連付けられる。あるいは、１つ以上の実施形態によれば、所属施設ＩＤ（３０５）は、特定の患者について、クラウド（１０１）に最初にアップロードされた画像を取得したネットワーク内の医療施設の識別番号であってもよく、この場合、患者が２つ以上の所属施設ＩＤ（３０５）を持つことはない。１つ以上の実施形態によれば、所属施設ＩＤ（３０５）は、ネットワーク内の医療施設のユーザー（すなわち、医療専門家）によって直接付与されてもよい。
【００４５】
１つ以上の実施形態によれば、レポート情報（３０７）には、個人の医療診断の情報が含まれる。画像情報（３０９）には、医用画像の簡単な説明及び医用画像の生成に用いられたモダリティーの名称が含まれる。
【００４６】
１つ以上の実施形態によれば、データテーブル（３００）中のデータは、医用画像にメタデータとして埋め込まれており、この医用画像は、医用におけるデジタル画像と通信フォーマット（ＤＩＣＯＭフォーマット）の画像であってもよい。１つ以上の実施形態によれば、ＤＩＣＯＭは、システム（１００）を実施するための汎用画像フォーマットであってもよい。テーブル（３００）のデータは、ローカルコンピューター（１１１）に記憶された１つ以上の実施形態に係るアプリケーションを用いて、ＤＩＣＯＭフォーマットの画像から抽出することができる。１つ以上の実施形態によれば、データテーブル（３００）中のデータは、医療データ中にメタデータとして直接埋め込まれていてもよく、この医療データは、患者の医用画像又は患者の医用レポートのいずれであってもよい。
【００４７】
テーブル（３００）中のデータは、各種の方法により分類されうる。図３に示す例では、データは、患者により分類されている。しかし、データは、例えば医療専門家の好みに基づいて、患者に関連する情報のいずれか１つを用いる別の方法により分類することもできる。データテーブル（３００）のデータが医用画像から抽出されると、医療専門家は、１つ以上の実施形態に係るアプリケーションにより提供されるＧＵＩを用いて、当該データを編集／改変することができる。１つ以上の実施形態によれば、抽出したデータテーブル（３００）は、ローカルサーバー（１０７）に保存される。
【００４８】
図４から図７は、１つ以上の実施形態に係る図１Ａ及び図１Ｂのシステムの種々の状態を示す。クラウド（１０１）、クラウドサーバー（１０３）、クラウドリポジトリ（１０５）、ローカルサーバー（１０７）、ローカルリポジトリ（１０９）、ローカルコンピューター（１１１）、表示メッセージ（２０１）、ユーザー選択可能タブ（２０３ａ、２０３ｂ）及びカウントダウンタイマー（２０５）は、図１Ａ、図１Ｂ、図２Ａ及び図２Ｂについて上記したものと同一又は実質的に同様である。以下、このような同様の構成要素については、繰り返し詳細に説明しない。
【００４９】
図４及び図５は、ネットワーク内の複数の医療施設のうちの１つの医療施設とクラウド（１０１）との間の接続が切れた状態をそれぞれ示す。この場合、図４の右側に示すように、接続が切れた医療施設に付随するローカルコンピューター（１１１）は、まず最初に、クラウド（１０１）との接続が切れた旨の表示メッセージ（２０１）を表示しうる。次いで、表示メッセージ（２０１）によって、ユーザーは、ユーザー選択可能タブ（２０３ａ）を選択して、クラウドリポジトリ（１０５）へのアクセスを、接続が切れた医療施設のローカルリポジトリ（１０９）へのアクセスに切り替えるよう促される。加えて、又はそれに代えて、表示メッセージ（２０１）によって、ユーザーにカウントダウンタイマー（２０５）を示し、タイマーが時間切れになると自動的に切り替えが起こるようにしてもよい。図５の右側は、接続が切れた医療施設に付随するローカルコンピューター（１１１）及びローカルサーバー（１０７）が、アクセスをクラウドリポジトリ（１０５）からローカルリポジトリ（１０９）へと切り替えたことを示す。
【００５０】
図６及び図７は、接続が切れていた医療施設とクラウド（１０１）との間の接続が再確立された状態をそれぞれ示す。この場合、図６の右側に示すように、再接続された医療施設に付随のローカルコンピューター（１１１）は、まず最初に、クラウド（１０１）との接続が回復したこと示す表示メッセージ（２０１）を示してもよい。次いで、表示メッセージ（２０１）によって、ユーザーは、（ユーザー選択可能タブ（２０３ａ）を選択して）クラウドリポジトリ（１０５）へ再アクセスするか、（ユーザー選択可能タブ（２０３ｂ）を選択して）ローカルで作業を続けるかを選択するよう促される。加えて、又はそれに代えて、表示メッセージ（２０１）によって、ユーザーにカウントダウンタイマー（２０５）を示して、タイマーが時間切れになると自動的に再アクセスする（すなわち、ローカルリポジトリ（１０９）へのアクセスをクラウドリポジトリ（１０５）へのアクセスに戻す）ようにしてもよい。図７の右側は、再接続された医療施設に付随のローカルコンピューター（１１１）が、接続が切れていた時にローカルリポジトリ（１０９）に保存したデータをクラウドリポジトリ（１０５）に送信中であり、クラウドリポジトリ（１０５）がローカルリポジトリ（１０９）と同期している旨の表示メッセージ（２０１）を表示している状態を示す。
【００５１】
図８Ａから図８Ｃに、１つ以上の実施形態に係る医用画像及びデータの事前取得の実施例を示す。図８Ａから図８Ｃに示す実施例を、図１Ａ及び図１Ｂを参照して上述したシステム（１００）について説明する。
【００５２】
図８Ａは、クラウドベースＰＡＣＳに接続された医療施設に患者が訪れた初期状態を示す。医師は、患者の診断（すなわち、１次診断）を行い、患者の医用画像（８０３）をローカルに保存する。クラウド（１０１）と医療施設の間で医用画像及びデータの同期が行われると、ローカルに保存された患者の医用画像（８０３）は、クラウド（１０１）に送信され、保存される。１つ以上の実施形態によれば、患者が最初に訪れる医療施設は、患者を完全に診断するのに必要な設備を持たない小規模な診療所でありうる。診療所の医師は、患者に、より大規模な病院（ネットワーク内の病院）に行き、追診断（すなわち、２次診断）を受けることを勧めうる。医師は、患者がその大規模な病院の予約を取るのも手助けしうる。
【００５３】
図８Ｂは、医療施設での患者の診断が終了した状態を示す。該医療施設の医師は、医用同期アプリケーションのグラフィカルユーザーインターフェース（ＧＵＩ）（８０５）を用いて、他の医療施設（例えば、より大規模な病院）での患者の追診断の予定を入れうる。１つ以上の実施形態によれば、ＧＵＩは、カレンダー形式のデザインであってよく、カレンダー上の情報は、他のすべてのネットワーク内医療施設のカレンダー情報と同期されうる。
【００５４】
１つ以上の実施形態によれば、ＧＵＩ（８０５）に入力されたスケジュール情報は、患者が次に他の医療施設を訪れるタイミング情報（例えば日時）と、患者ＩＤ、患者名、所属施設ＩＤ等を含む診断情報とについての情報を含む診断予約情報へと編集される。１つ以上の実施形態によれば、診断情報には、図３を参照して上述したデータテーブル（３００）の情報が含まれうる。１つ以上の実施形態によれば、タイミング情報を含んだ診断予約情報は、医用画像（８０３）のメタデータとして保存されうる。
【００５５】
図８Ｃは、患者が追診断のために他の医療施設（例えば、より大規模な病院）に到着した状態を示す。医療施設のローカルサーバーは、定期的にクラウド（１０１）に事前取得要求を送信する。１つ以上の実施形態によれば、事前取得要求には、診断予約情報に含まれるタイミング情報と一致する（すなわち、重複する）日時の範囲を含む事前取得期間が含まれる。１つ以上の実施形態によれば、事前取得要求がクラウド（１０１）に送信される周期（すなわち、所定のペース）は、医用画像及びデータに関連付けられたいずれの診断の予定に対しても、それに先立ってクラウド（１０１）に保存された全ての医用画像及びデータを取得できるのであれば、いかなるタイミング（例えば、１日に２〜３回の要求を送信）に設定されてもよく、これは、各医療施設のユーザー（例えば、医師、システム管理者、医療スタッフ等）が設定しうる。あるいは、この周期は、クラウドベースＰＡＣＳのベンダーが設定しうる。１つ以上の実施形態によれば、事前取得要求の送信時刻に合わせて、事前取得期間を設定してもよい。
【００５６】
１つ以上の実施形態によれば、患者の医用画像（８０３）は、患者が医療施設に到着するのに先立ってクラウド（１０１）から取得されている。これにより、医療施設のローカルサーバーにおいて、医用画像（８０３）が医師により容易に利用可能となるため、医師が要する診断時間が減少する。１つ以上の実施形態によれば、患者の医用画像（８０３）は、予約された診断時間まで医療施設のローカルサーバーに一時的に保存されうる。
【００５７】
本発明の実施形態は、使用されるプラットフォームにかかわらず、実質的にいかなる種類のコンピューターシステム上で実行されてもよい。例えば、コンピューターシステムは、１つ以上のモバイル機器（例えば、ラップトップコンピューター、スマートフォン、パーソナルデジタルアシスタント、タブレットコンピューター又は他のモバイル機器）、デスクトップコンピューター、サーバー、サーバーシャーシのブレード又は他のあらゆる種類のコンピューター装置であってもよく、あるいは、少なくとも本発明の１つ以上の実施形態を実行するための最小限の処理能力、メモリー、出入力装置を備える装置であってもよい。例えば、図９に示すように、コンピューターシステム（９００）は、１つ以上のコンピュータープロセッサー（９０２）、付随するメモリー（９０４）（例えば、ランダムアクセスメモリー（ＲＡＭ）、キャッシュメモリー、フラッシュメモリー等）、１つ以上の記憶装置（９０６）（例えば、ハードディスク、コンパクトディスク（ＣＤ）ドライブ又はデジタルバーサタイルディスク（ＤＶＤ）ドライブ等の光学ドライブ、フラッシュメモリースティック等）及び他の多数の要素及び機能部を有する。コンピュータープロセッサー（９０２）は、指示を実行するための集積回路であってもよい。例えば、コンピュータープロセッサーは、プロセッサーの１つ以上のコア又はマイクロコアであってもよい。コンピューターシステム（９００）は、１つ以上の入力装置（９１０）も有し、これは、タッチスクリーン、キーボード、マウス、マイクロフォン、タッチパッド、電子ペン、又は他のあらゆる種類の入力装置等である。また、コンピューターシステム（９００）は、１つ以上の出力装置（９０８）を有し、これは、スクリーン（例えば、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、タッチスクリーン、陰極線管（ＣＲＴ）モニター、プロジェクター又はその他のディスプレイ装置）、プリンター、外部記憶装置又はその他のあらゆる出力装置等である。１つ以上の出力装置は、入力装置と同一であっても異なっていてもよい。コンピューターシステム（９００）は、ネットワークインターフェース接続（図示せず）を介して、ネットワーク（９１２）（例えば、ローカルエリアネットワーク（ＬＡＮ）、インターネット等のワイドエリアネットワーク（ＷＡＮ）、モバイルネットワーク又は他のあらゆる種類のネットワーク）に接続されうる。出入力装置は、コンピュータープロセッサー（９０２）、メモリー（９０４）及び記憶装置（９０６）に、ローカル又はリモート（例えば、ネットワーク（９１２）を介して）で接続されうる。広く種々のコンピューターシステムが存在し、上記の出入力装置は、他の形態であってもよい。
【００５８】
本発明の実施形態を実行するためのコンピューター読み取り可能なプログラムコードの形態のソフトウェア命令は、その全部又は一部が、一時的又は永久的に、ＣＤ、ＤＶＤ、記憶装置、ディスケット、テープ、フラッシュメモリー、物理メモリー又は他のあらゆるコンピューター読み取り可能な記憶媒体等の非一時的なコンピューター読み取り可能な媒体に記憶されうる。具体的には、ソフトウェア命令は、プロセッサーにより実行されると、本発明の実施形態を実行するように構成された、コンピューター読み取り可能なプログラムコードに相当しうる。
【００５９】
また、上記のコンピューターシステム（９００）の要素の１つ以上が、遠隔地に位置し、ネットワーク（９１２）を介して他の要素と接続されていてもよい。また、本発明の１つ以上の実施形態は、複数のノードを有する分散システムにおいて実施されてもよく、本発明の各部分は、分散システム内の異なるノード上に位置しうる。本発明の実施形態の１つによれば、ノードは、別個のコンピューター装置に相当する。あるいは、ノードは、付随の物理メモリーを備えるコンピュータープロセッサーに相当しうる。あるいは、ノードは、共有メモリー及び／又はリソースを備えるコンピュータープロセッサー又はコンピュータープロセッサーのマイクロコアに相当しうる。
【００６０】
図９のコンピューターシステムは、生データ及び／又は比較やその他の処理の結果等である加工データを提示するための機能部を有しうる。例えば、データの提示は、様々な提示方法により行いうる。具体的には、データは、コンピューター装置により提供されるユーザーインターフェースを通して提示されうる。ユーザーインターフェースには、コンピューターモニター又は携帯コンピューター装置のタッチスクリーン等のディスプレイ装置に情報を表示するＧＵＩが含まれる。ＧＵＩには、どのデータを見せるか、どのようにユーザーにデータを提示するかを構成する様々なＧＵＩウィジェットが含まれる。さらに、ＧＵＩは、データをユーザーに直接提示してもよく、例えば、実際のデータ値としてテキストで表したり、あるいは、コンピューター装置によって、データモデルの可視化等によりデータを視覚的な表示として描画したりしうる。
【００６１】
例えば、ＧＵＩは、まず最初に、特定のデータオブジェクトをＧＵＩ内に提示するよう要求する通知をソフトウェアアプリケーションから取得しうる。次に、ＧＵＩは、例えばデータオブジェクト型を識別するデータオブジェクト中のデータ属性からデータを取得することにより、特定のデータオブジェクトのデータオブジェクト型を判断しうる。そして、ＧＵＩは、そのデータオブジェクト型を表示するよう設計されたあらゆるルールを決定しうる。例えば、データオブジェクトクラス用のソフトウェアフレームワークにより特定されるルールや、ＧＵＩにより定義される当該データオブジェクト型を提示するためのあらゆるローカルパラメーターに従ったルールである。最後に、ＧＵＩは、特定のデータオブジェクトからデータ値を取得し、指定されたデータオブジェクト型用のルールに従って、ディスプレイ装置に当該データ値の視覚的な表示を描画する。
【００６２】
図１０に、１つ以上の実施形態に係るシステムの模式図を示す。システムは、クラウドサーバー上のクラウドリポジトリと、当該クラウドサーバーに接続された複数のローカルサーバー上の複数のローカルリポジトリとの間で医用画像及びデータを同期するよう構成されている。複数のローカルサーバーには、第１のローカルサーバー及び第２のローカルサーバーが含まれ、複数のローカルリポジトリには、第１のローカルサーバー上の第１のローカルリポジトリ及び第２のローカルサーバー上の第２のローカルリポジトリが含まれる。上述したように、序数の使用は、要素の特定の序列を示唆するものでも、要素に特定の序列をつけるものでもなく、ある要素を単数に限定するものでもない。例えば、「第１のローカルサーバー」及び「第２のローカルサーバー」は、クラウドサーバーに接続された複数のローカルサーバーのうちいずれのローカルサーバーであってもよく、説明のために「第１の」及び「第２の」と称されるにすぎない。
【００６３】
図１０に示すシステムは、例えば、（ｉ）第１のローカルサーバー、第２のローカルサーバー及びクラウドサーバー間の接続状況に基づいて以下のステップを行うよう構成された指示を実行するよう構成されたコンピュータープロセッサー（１００６）を備える処理モジュール（１００４）を有する。
【００６４】
一側面によれば、コンピュータープロセッサー（１００６）は、クラウドサーバーに、（１）第１の医療施設の第１のローカルサーバーから、未来の診断日を示すタイミング情報と、診断予約情報をクラウドサーバーに保存された医用画像に関連付ける診断情報とを含む診断予約情報を受け取らせ、（２）第２の医療施設の第２のローカルサーバーから、事前取得期間を含む事前取得要求を受け取らせ、（３）事前取得要求を受け取ると、診断予約情報のタイミング情報が、事前取得期間と重複すると判断させ、（４）医用画像が診断予約情報と関連付けられると、第２のローカルリポジトリに、医用画像及びデータを送信させる指示を実行する。
【００６５】
図１０に示すシステムは、さらに、（ｉｉ）医用画像及びデータをユーザーに提示するよう構成されたユーザー装置（１００２）を有する。システムは、さらに、ベンダー提供アプリケーションに関するＰＡＣＳアプリケーションデータ（すなわち、ＰＡＣＳ情報）（１０１０）、患者情報（１０１２）、医用画像及びデータ（１０１４）及び診断予約情報（１０１６）を保存するよう構成されたデータリポジトリ（１００８）を有していてもよい。
【００６６】
図１１Ａ及び図１１Ｂは、１つ以上の実施形態に係る方法のフローチャートを示す。１つ以上の実施形態によれば、図１１Ａ及び図１１Ｂに記載の方法は、コンピューターにより実施される方法である。図１１Ａ及び図１１Ｂに示す各ステップを以下に説明するが、ネットワーク内の複数の医療施設のうちの１つの医療施設のシステムのみについて説明する。当業者であれば、以下に説明する方法の各ステップは、ネットワーク内の複数の医療施設のシステムのいずれによっても実行できることが明らかであろう。
【００６７】
ステップ１１０５及び１１１０において、ネットワーク内の医療施設の１つに付随するローカルコンピューターは、当該医療施設のローカルサーバーとクラウド上のクラウドサーバーとの間の接続状況をチェックして、接続が正常であるかどうかを判断する。
【００６８】
ステップ１１１０におけるチェックの結果がＹＥＳの場合、ローカルコンピューターは、ステップ１１１５において、モダリティーにより生成されたデータを、ローカルサーバーを介してクラウドサーバーへアップロードし続け、ステップ１１２０において、ローカルリポジトリとクラウドリポジトリとの間でデータを同期する。次いで、処理は、ステップ１１０５に戻る。
【００６９】
１つ以上の実施形態によれば、ステップ１１１５においてクラウドサーバーが更新されると、ネットワーク内の他の施設のローカルコンピューター及びサーバーは、クラウドサーバーから更新されたデータの全て又は一部を受け取る。ネットワーク内の施設の各ローカルコンピューター及びサーバーは、更新されたデータを受け取ると、更新されたデータが以前に存在していなかったものであれば、それぞれのローカルリポジトリに当該更新されたデータを追加し、あるいは、更新されたデータに対応する以前から存在しているローカルに記憶されたデータを当該更新されたデータに置き換える。
【００７０】
ステップ１１１０におけるチェックの結果がＮＯであった場合、ステップ１１２５において、医療施設とクラウドとの間の接続が切れた旨のメッセージと、ローカルコンピューター及びサーバーのアクセスをローカルリポジトリへと切り替える旨のメッセージをユーザーに表示する。
【００７１】
ステップ１１３０において、接続が切れた医療施設のローカルコンピューター及びサーバーは、アクセスをローカルリポジトリへと切り替え、ステップ１１３５において、ローカルコンピューター及びサーバーに記憶されている、ローカルコンピューター及びサーバーのクラウドへのアクセスを可能にするアプリケーションを再起動する。この時点では、医用画像及びデータは、クラウドリポジトリに代えてローカルリポジトリとの間で保存・取得されている。
【００７２】
１つ以上の実施形態によれば、このメッセージがユーザーに表示されると、ユーザーは、ユーザー選択可能タブをクリックして、すぐさまアクセスをローカルリポジトリに切り替えるか、あるいはメッセージに表示されたカウントダウンタイマーが時間切れとなってローカルコンピューター及びサーバーが自動的にアクセスをローカルリポジトリに切り替えるのを待つことができる。
【００７３】
ステップ１１４０及び１１４５において、アプリケーションが再起動されると、接続が切れた医療施設のローカルコンピューターは、チェックを行ってローカルサーバーとクラウドサーバーとの間の接続が正常であるかどうかを判断する。
【００７４】
チェックの結果がＮＯであった場合、ローカルコンピューター及びサーバーは、引き続きローカルでの稼働を続ける。処理はステップ１１４０及び１１４５に戻り、ローカルコンピューターは、ローカルサーバーとクラウドサーバーとの間の接続状況をチェックする。
【００７５】
チェックの結果がＹＥＳであった場合、ステップ１１５０において、医療施設とクラウドとの間の接続が再確立された旨と、ローカルコンピューター及びサーバーが、アクセスを切り替えて、リモートリポジトリに戻す旨のメッセージをユーザーに表示する。
【００７６】
ステップ１１６０において、メッセージがユーザーに表示されると、ユーザーは、ローカルリポジトリを用いてローカルでの作業を続けたいかどうかを決定するよう促される。メッセージ中のカウントダウンタイマーが時間切れとなるまでにユーザーからの応答が検出されなかった場合、ローカルコンピューター及びサーバーは、自動的にクラウドサーバーに再アクセスする。
【００７７】
チェックの結果がＹＥＳであった場合、ローカルコンピューター及びサーバーは、予め定められた時間ローカル接続を続けるが、その際、ローカルコンピューターは、ステップ１１４０において、ローカルサーバーとクラウドサーバーとの間の接続状況をチェックし続ける。予め定められた時間が過ぎると、ユーザーは、別の表示メッセージでクラウドに再接続するよう促される。このときは、ユーザーは、ローカルリポジトリを用いてローカルで作業を続けることを選択できない。
【００７８】
チェックの結果がＮＯであった場合、ローカルコンピューター及びサーバーは、ステップ１１６５において、クラウドリポジトリに再アクセスするよう設定される。
【００７９】
次いで、ステップ１１７０において、ローカルコンピューター及びサーバーがクラウドリポジトリに再アクセスすると、クラウドリポジトリが同期される。すなわち、再接続の間にローカルリポジトリに保存されたデータや、クラウドサーバーとの再接続後に生成された新たなデータで更新される。接続が切れている間にコンフリクトが発生した場合（例えば、ネットワーク内の異なる医療施設の２人以上のユーザーが、リモートサーバー上の同一のリモートデータに関連付けられた患者情報を同時に更新しようとした場合）、当該コンフリクトは、アプリケーションにより自動的に解決されるか、アプリケーションが提供するＧＵＩを介してユーザーにより手動で解決される。
【００８０】
１つ以上の実施形態によれば、コンフリクトは、ネットワーク内の医療施設のローカルサーバーからのローカルデータがクラウドサーバーにアップロードされている時（例えば、各ローカルサーバーとクラウドサーバーとの間で医療データを同期している時）に起こりうる。また、コンフリクトは、ネットワーク内の異なる医療施設の異なるユーザーが、同一のリモートデータの患者情報の同一箇所を、対応するローカルデータ中の当該情報をローカルで編集又は更新することによって同時に更新しようとした時に起こりうる。この場合、クラウドサーバーが受け取った２つの編集済みローカルデータの情報を用いてリモートデータを更新しようとする際に、アプリケーションは、どちらの更新された患者情報が正しいかを判断できないかもしれない。
【００８１】
より具体的には、１つ以上の実施形態によれば、ある状況でのコンフリクトは、他の状況の場合よりも複雑である。例えば、２人のユーザーが同一のリモートデータを同時に更新して新たな患者名を反映させようとする場合において、ネットワーク内の医療施設Ａのユーザーが、患者名を「ＡＡＡＡＡ」から「ＡＡＡＢＡ」に更新し、ネットワーク内の異なる医療施設のユーザーが、同じ患者名を「ＡＡＡＡＡ」から「ＡＡＡＣＡ」に更新した場合、システムは、２つの新たな名前のどちらが正しいのか判断することができない。この場合、ユーザーは、コンフリクトを手動で解消しなければならない。しかし、２人のユーザーが同一のリモートデータを同時に更新して新たな患者名を反映させようとする場合において、ネットワーク内の医療施設Ａのユーザーが患者名を「ＡＡＡＡＡ」から「ＡＡＡＢＡ」に編集し、ネットワーク内の医療施設Ｂのユーザーが同じ患者名を「ＡＡＡＡＡ」から「ＡＣＡＡＡ」に編集した場合、アプリケーションは、患者名を「ＡＣＡＢＡ」に自動的に更新することができる。
【００８２】
また、接続が切れた医療施設のローカルコンピューター及びサーバーは、接続が切れていた時にネットワーク内の他の医療施設により更新されたデータをクラウドサーバーから受け取り、更新されたデータが以前に存在していなかったものであれば、ローカルリポジトリに当該更新されたデータを追加し、あるいは、更新されたデータに対応する以前から存在しているローカルに保存されたデータを当該更新されたデータで置き換える。
【００８３】
１つ以上の実施形態によれば、ステップ１１７０においてクラウドサーバーが更新されると、ネットワーク内の他の施設のローカルコンピューター及びサーバーは、クラウドサーバーから更新されたデータの全部又は一部を受け取る。ネットワーク内の施設の各ローカルコンピューター及びサーバーは、更新されたデータを受け取ると、更新されたデータが以前に存在していなかったものであれば、それぞれのローカルリポジトリに当該更新されたデータを追加し、あるいは、更新されたデータに対応する以前から存在しているローカルに保存されたデータを当該更新されたデータで置き換える。
【００８４】
ステップ１１７５において、再接続の間にローカルリポジトリに保存された全てのデータがクラウドリポジトリに送信されると、アプリケーションが再起動され、ローカルコンピューターはステップ１１１５に戻るように設定される。
【００８５】
図１２に、１つ以上の実施形態に係るフローチャートを示す。クラウドサーバーと、複数のネットワーク内の医療施設のうち２箇所の医療施設のシステムのみについて、図１２の各ステップを以下にまとめて説明する。当業者であれば、以下の方法の各ステップは、複数のネットワーク内の医療施設（すなわち、２箇所を超える医療施設）のいずれのシステムによっても実行可能であることがわかるであろう。
【００８６】
ステップ１２０５において、図１Ａ及び図１Ｂ並びに図８Ａから図８Ｃを参照して上述したように、クラウドサーバーは、第１の医療施設から、タイミング情報及び診断情報を含む診断予約情報を受け取る。１つ以上の実施形態によれば、クラウドサーバーは、診断予約情報をクラウドリポジトリに保存する。１つ以上の実施形態によれば、クラウドリポジトリには、複数の診断予約情報が保存されうる。
【００８７】
ステップ１２１０において、図１Ａ及び図１Ｂ並びに図８Ａから図８Ｃを参照して上述したように、クラウドサーバーは、第１の医療施設とは別の第２の医療施設から、事前取得期間を含む事前取得要求を受け取る。１つ以上の実施形態によれば、クラウドサーバーは、事前取得要求を所定のペースで定期的に受け取りうる。１つ以上の実施形態によれば、クラウドサーバーは、ネットワーク内の複数の医療施設から、複数の事前取得要求を受け取りうる。
【００８８】
ステップ１２１５において、図１Ａ及び図１Ｂ並びに図８Ａから図８Ｃを参照して上述したように、クラウドサーバーは、事前取得期間が、診断予約情報のタイミング情報と重複するかどうかを判定する。事前取得期間が診断予約情報のタイミング情報と重複しない場合は、事前取得処理が終了し、第２の医療施設には何も送信されない。
【００８９】
ステップ１２２０において、図１Ａ及び図１Ｂ並びに図８Ａから図８Ｃを参照して上述したように、事前取得期間が診断予約情報のタイミング情報と重複する場合、クラウドサーバーは、クラウドリポジトリに保存されている医用画像及びデータのいずれかが診断予約情報と関連付けられているかどうかを判定する。この判定は、診断予約情報に含まれる診断情報に基づいて行われる。クラウドサーバーが、クラウドリポジトリに保存されているいずれの医用画像及びデータも診断予約情報と関連付けられていないと判断した場合、処理は終了し、第２の医療施設には何も送信されない。
【００９０】
ステップ１２２５において、図１Ａ及び図１Ｂ並びに図８Ａから図８Ｃを参照して上述したように、クラウドリポジトリに保存されている医用画像及びデータの１つ以上が診断予約情報と関連付けられていると判断した場合、クラウドサーバーは、第２の医療施設のローカルサーバーに該医用画像及びデータを送信する。１つ以上の実施形態によれば、医用画像は、予約された患者の診断時間まで、第２の医療施設のローカルサーバーに一時的に保存されうる。
【００９１】
本発明の１つ以上の実施形態は、ネットワーク内の複数の医療施設間で医用画像及びデータを自動的に共有・更新する能力、同一の個人にサービスを提供するネットワーク内の全ての医療施設の全てのローカルリポジトリを、当該個人の最も新しい医用画像及びデータによって最新の状態に保つ能力、ネットワーク内のいずれかの医療施設と共有クラウドとの接続が切れたことに起因とするいかなるダウンタイムを被ることなく、ネットワーク内の全ての医療施設が連続して業務を行うことができる能力、医療施設が現場にてフルサイズのデータセンターを維持する必要がないように、ネットワーク内の各医療施設のローカルリポジトリに保存される医用画像及びデータを選択する能力、予約された患者の診断時間に先立って各患者の医用画像及びデータを取得することによって、各患者の診断に要する時間を減らす能力（これにより、診断において計算資源がより効率的に利用される）、医療施設が忙しくない時に必要な医用画像及びデータの取得を行うように予定し、前もって行う能力（これにより、医療施設が忙しい時に計算処理資源がより効率的に利用される）、手動での要求を行わずに、自動的に医用画像及びデータを取得する能力（これにより、人手不足の医療施設や働きすぎの人を抱える医療施設において、人員がより効率的に利用される）等の利点の１つ以上を有する。
【００９２】
以上、限られた数の実施形態により本発明を説明したが、本開示の利益を受ける当業者であれば、ここに開示される発明の範囲から逸脱しない範囲で、他の実施形態を考案できることがわかるであろう。したがって、本発明の範囲は、添付の請求の範囲によってのみ限定されるべきものである。
【図１Ａ】
2019215844.tif 000003
【図１Ｂ】
2019215844.tif 000004
【図２Ａ】
2019215844.tif 000005
【図２Ｂ】
2019215844.tif 000006
【図３】
2019215844.tif 000007
【図４】
2019215844.tif 000008
【図５】
2019215844.tif 000009
【図６】
2019215844.tif 000010
【図７】
2019215844.tif 000011
【図８Ａ】
2019215844.tif 000012
【図８Ｂ】
2019215844.tif 000013
【図８Ｃ】
2019215844.tif 000014
【図９】
2019215844.tif 000015
【図１０】
2019215844.tif 000016
【図１１Ａ】
2019215844.tif 000017
【図１１Ｂ】
2019215844.tif 000018
【図１２】
2019215844.tif 000019
【外国語明細書】
2019215844000001.pdf
2019215844000002.pdf
2019215844000003.pdf
2019215844000004.pdf