JP2024512632A - 医療用画像ソリューションのための新しいデータ保存及び管理方式のための方法及びシステム - Google Patents

Abstract

【課題】医療用画像ソリューションのための新しいデータ保存及び管理方式のためのシステム及び方法を提供する。【解決手段】少なくとも分離プロセス及び回復プロセスを含む医療データ記憶及び管理プロセスが、医療データセットに適用され得る。分離プロセスは、医療データセット内のブロブデータ要素を識別し、識別されたブロブデータ要素のデータを対応する分離されたデータオブジェクトに移動し、識別されたブロブデータ要素のデータの移動を示し、移動されたデータの位置を追跡するためのデータを生成する。回復プロセスは、分離された医療データセット内の除去されたブロブデータ要素を識別し、識別された除去されたブロブデータ要素のデータを対応する分離されたデータオブジェクトに移動させ、識別された除去されたブロブデータ要素ごとに、対応する分離データに基づいて、対応する分離されたデータオブジェクトの位置を決定し、決定された位置に基づいて、除去されたブロブデータ要素のデータを検索する。【選択図】 図１

Description

本開示の態様は、医療撮像ソリューションに関する。より具体的には、特定の実施形態は、医療撮像ソリューションのための新しいデータ記憶及び管理方式のための方法及びシステムに関する。

人体内の臓器や軟部組織の撮像など、様々な医療撮像技術を使用することができる。医療撮像技術の例には、超音波撮像、コンピュータ断層撮影（ＣＴ）スキャン、磁気共鳴撮像（ＭＲＩ）などが含まれる。医療撮像中に画像が生成される方法は、特定の技術に依存する。

米国特許出願公開第２０１２／００６００３５号明細書

例えば、超音波撮像は、リアルタイムの非侵襲的な高周波音波を使用して、典型的には人体内部の器官、組織、物体（ｏｂｊｅｃｔｓ、例えば、胎児）の超音波画像を生成する。医療撮像中に生成又は生成される画像は、二次元（２Ｄ）画像、三次元（３Ｄ）画像、及び／又は四次元（４Ｄ）画像（本質的にリアルタイム／連続３Ｄ画像）であってもよい。医療撮像中、撮像データセット（例えば、３Ｄ／４Ｄ撮像中の体積撮像データセットを含む）が取得され、対応する画像を（例えば、ディスプレイを介して）リアルタイムで生成及びレンダリングする際に使用される。

場合によっては、医療撮像中に生成された撮像データを記憶する必要性が生じることがある。このような撮像データの保存は、特に、この撮像データが使用される１以上の医療撮像システムにおけるリソースの使用に関して、特定の課題をもたらす可能性がある。

従来及び従来のアプローチのさらなる制限及び欠点は、図面を参照して本願の残りの部分に記載されるように、そのようなシステムと本開示のいくつかの態様との比較を通じて、当業者には明らかになるであろう。

実質的に、特許請求の範囲により完全に規定されるように、少なくとも１つの図に示され、及び／又は少なくとも１つの図に関連して説明されるような、医療撮像ソリューションのための新しいデータ記憶及び管理スキームのためのシステム及び方法が提供される。

本開示のこれら及び他の利点、態様、及び新規な特徴、並びにその１つ又は複数の図示された例示的な実施形態の詳細は、以下の説明及び図面からより完全に理解されるであろう。

医療撮像ソリューションのための新しいデータ記憶及び管理方式をサポートするように構成され得る医療撮像配置の例を示す。 医療撮像ソリューションのための新しいデータ記憶及び管理方式をサポートするように構成され得る例示的な超音波システムを示す。 医療撮像ソリューションのための新しいデータ記憶及び管理スキームで使用するためのメタデータ分離のためのプロセス例を示す。 メタデータオブジェクトから撮像調査メタデータ文書を導出するための使用シナリオ例を示す。 ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）ベースのデータをブロブオブジェクト及びメタデータオブジェクトに分離するための使用シナリオ例を示す。 ヘルスケアエンタープライズ（ＩＨＥ）患者ケアデバイス（ＰＣＤ）デバイスエンタープライズ通信（ＤＥＣ）ベースのデータをブロブオブジェクト及びメタデータオブジェクトに分離するための使用シナリオ例を示す。 ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）ベースの符号化データセットの例を示す。 ブロブデータをブロブオブジェクトとメタデータオブジェクトに分離した後の、ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）ベースの符号化データセットの例を示す。 本開示に従った新しいデータ記憶及び管理方式に基づく分離及び回復処理の例のフローチャートを示す。

本開示に従った特定の実施態様は、医療撮像ソリューションのための新しいデータ記憶及び管理方式に向けられることがある。特に、特定の実施形態の以下の詳細な説明は、添付の図面と併せて読むとより良く理解されるであろう。図が様々な実施形態の機能ブロックの図を示す限りにおいて、機能ブロックは必ずしもハードウェア回路間の分割を示すものではない。したがって、例えば、機能ブロックの１つ以上（例えば、プロセッサ又はメモリ）は、単一のハードウェア（例えば、汎用信号プロセッサ又はランダムアクセスメモリのブロック、ハードディスクなど）又は複数のハードウェアに実装されてもよい。同様に、プログラムは、スタンドアロンプログラムであってもよいし、オペレーティングシステムのサブルーチンとして組み込まれていてもよいし、インストールされたソフトウェアパッケージの機能などであってもよい。様々な実施形態は、図面に示された配置及び器具に限定されないことを理解されたい。また、実施形態を組み合わせてもよく、他の実施形態を利用してもよく、様々な実施形態の範囲から逸脱することなく構造的、論理的、電気的な変更を加えてもよいことも理解されるべきである。したがって、以下の詳細な説明は、限定的な意味で捉えられるものではなく、本開示の範囲は、添付の特許請求の範囲及びその均等物によって定義される。

本明細書で使用される場合、単数形で記載され、「ａ」又は「ａｎ」という単語が先行する要素又はステップは、そのような除外が明示的に記載されない限り、当該要素又はステップの複数形を除外しないと理解されるべきである。さらに、「例示的な実施形態」、「様々な実施形態」、「特定の実施形態」、「代表的な実施形態」等への言及は、言及された特徴も組み込んだ追加の実施形態の存在を排除するものとして解釈されることを意図していない。さらに、反対のことが明示的に記載されていない限り、特定の特性を有する要素又は複数の要素を「含む：ｃｏｍｐｒｉｓｉｎｇ」、「備える：ｉｎｃｌｕｄｉｎｇ」、又は「有する：ｈａｖｉｎｇ」実施形態は、その特性を有しない追加の要素を含み得る。

また、本明細書で使用する場合、「画像：ｉｍａｇｅ」という用語は、表示可能な画像と表示可能な画像を表すデータの両方を広く指す。しかしながら、多くの実施形態は、少なくとも１つの閲覧可能画像を生成する（又は生成するように構成される）。さらに、本明細書で使用される場合、「画像」という語句は、Ｂモード（２Ｄモード）、Ｍモード、３次元（３Ｄ）モード、ＣＦモード、ＰＷドプラ、ＣＷドプラ、ＭＧＤ．及び／又はＢモード及び／又はＣＦのサブモードであるＳｈｅａｒＷａｖｅＥｌａｓｔｉｃｉｔｙＩｍａｇｉｎｇ（ＳＷＥＩ）、ＴＶＩ、Ａｎｇｉｏ、Ｂ－ｆｌｏｗ、ＢＭＩ、ＢＭＩ＿Ａｎｇｉｏ、場合によってはＭＭ、ＣＭ、ＴＶＤなどに使用される。

さらに、本明細書で使用する場合、「ピクセル」という語句は、データが「ボクセル」によって表される実施形態も含む。したがって、「画素」及び「ボクセル」という用語は、本明細書を通じて互換的に使用することができる。

さらに、本明細書で使用されるプロセッサ又は処理ユニットという用語は、シングルコア又はマルチコアなど、様々な実施形態に必要な計算を実行できる任意のタイプの処理ユニットを指し、ＣＰＵ、ＡＰＵ（Ａｃｃｅｌｅｒａｔｅｄ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、グラフィックボード、ＤＳＰ、ＦＰＧＡ、ＡＳＩＣ、又はそれらの組み合わせなどである。

画像を生成又は形成する本明細書に記載の様々な実施形態は、ある実施形態ではビームフォーミングを含み、他の実施形態ではビームフォーミングを含まない、画像を形成するための処理を含み得ることに留意されたい。例えば、復調データの行列に係数の行列を乗算して、その積が画像となるようにするなど、ビームフォーミングを行わずに画像を形成することができ、この場合、処理はいかなる「ビーム：ｂｅａｍｓ」も形成しない。さらに、画像の形成は、複数の送信イベントに由来するチャネルの組み合わせ（例えば、合成開口技術：ｓｙｎｔｈｅｔｉｃ ａｐｅｒｔｕｒｅ ｔｅｃｈｎｉｑｕｅｓ）を使用して実行することができる。

様々な実施形態において、ビームフォーミングを含む画像を形成するための処理は、ソフトウェア、ファームウェア、ハードウェア、又はそれらの組み合わせで実行される。図２に示されているように、様々な実施形態に従って形成されたソフトウェアビームフォーミングアーキテクチャを有する超音波システムの１つの例示的な実施形態が示されている。

図１は、三次元（３Ｄ）医療撮像の視覚化を改善するためにヒストグラムビューを利用することを支援するように構成され得る例示的な医療撮像処理配置を示す。図１に示されているのは、１つ以上の医療撮像システム（ｍｅｄｉｃａｌ ｉｍａｇｉｎｇ ｓｙｓｔｅｍ）１１０と１つ以上のコンピューティングシステム１２０とを含む例示的なセットアップ１００である。

医療撮像システム１１０は、医療撮像を支援する（すなわち、医療撮像検査中に画像を生成及び／又はレンダリングする際に使用されるデータを取得できるようにするための）適切なハードウェア、ソフトウェア、又はそれらの組み合わせから構成される。医療撮像の例には、超音波撮像、コンピュータ断層撮影（ＣＴ）スキャン、磁気共鳴撮像（ＭＲＩ）などが含まれる。これは、特定の態様で、特定のタイプのデータのキャプチャを伴う可能性があり、これは、画像のためのデータを生成する際に使用される可能性がある。例えば、医療撮像システム１１０は、超音波画像を生成及び／又はレンダリングするように構成された超音波撮像システムであってもよい。医療撮像システム１１０に対応し得る超音波システムの実施例を、図２に関してより詳細に説明する。

図１に示すように、医療撮像システム１１０は、携帯可能で移動可能なスキャナ装置１１２と、表示／制御ユニット１１４とから構成されてもよい。スキャナ装置１１２は、患者の身体（又はその一部）上を移動されることなどにより、特定の種類の撮像信号（及び／又はそれに対応するデータ）を生成及び／又は捕捉するように構成されてもよく、そのような機能を実行及び／又はサポートするための適切な回路を含んで構成されてもよい。スキャナ装置１１２は、超音波プローブ、ＭＲＩスキャナ、ＣＴスキャナ、又は任意の適切な撮像装置であってもよい。例えば、医療撮像システム１１０が超音波システムである場合、スキャナ装置１１２は、超音波信号を放射し、エコー超音波画像を撮像することができる。

表示／制御ユニット１１４は、（例えば、スクリーン１１６を介して）画像を表示するように構成されてもよい。いくつかの実施態様では、表示／制御ユニット１１４はさらに、表示された画像を少なくとも部分的に生成するように構成されてもよい。さらに、表示／制御ユニット１１４は、ユーザー入力／出力をサポートすることもできる。例えば、表示／制御ユニット１１４は、画像に加えて、ユーザフィードバック（例えば、システム、その機能、その設定などに関連する情報）を（例えば、スクリーン１１６を介して）提供してもよい。表示／制御ユニット１１４は、医療撮像の制御を可能にするように、ユーザ入力を（例えば、ユーザ制御部１１８を介して）サポートすることもできる。ユーザ入力は、画像の表示の制御、設定の選択、ユーザ嗜好の指定、フィードバックの要求などに向けられることがある。

いくつかの実施態様では、医療撮像システム１１０はまた、１つ又は複数のコンピューティングシステム１２０のような追加の専用コンピューティング資源（ａｄｄｉｔｉｏｎａｌ ａｎｄ ｄｅｄｉｃａｔｅｄ ｃｏｍｐｕｔｉｎｇ ｒｅｓｏｕｒｃｅｓ）を組み込むことができる。この点に関して、各コンピューティングシステム１２０は、データを処理、記憶、及び／又は通信するための適切な回路、インターフェース、ロジック、及び／又はコードを含んでいてもよい。コンピューティングシステム１２０は、特に医療撮像と共に使用するように構成された専用機器であってもよく、又は、コンピューティングシステム１２０に関して以下に説明する動作を実行するように設定及び／又は構成された汎用コンピューティングシステム（例えば、パーソナルコンピュータ、サーバ等）であってもよい。コンピューティングシステム１２０は、以下に説明するように、医療撮像処理システム１１０の動作をサポートするように構成されてもよい。これに関して、様々な機能及び／又は動作が撮像システムからオフロードされてもよい。これは、処理の特定の態様を合理化及び／又は集中化し、例えば、画像処理システムにおける処理リソースを増加させる必要性を回避することによって、コストを削減するために行われてもよい。

コンピューティングシステム１２０は、別の方法で使用のために設定及び／又は配置され得る。例えば、いくつかの実施態様では、単一のコンピューティングシステム１２０が使用され得る。他の実施態様では、複数のコンピューティングシステム１２０が、（例えば、分散処理構成に基づいて）一緒に動作するように構成されるか、又は別個に、各コンピューティングシステム１２０が、特定の態様及び／又は機能を処理するように構成されるか、及び／又は特定の医療撮像処理システム１１０のためのデータのみを処理するように構成される。更に、幾つかの実施態様では、コンピューティングシステム１２０は、ローカル（例えば、同じ施設内及び／又は同じローカルネットワーク内のような、１つ又は複数の医療撮像処理システム１１０と同位置にある）であってもよく、他の実施態様では、コンピューティングシステム１２０は、リモートであってもよく、従って、リモート接続（例えば、インターネット又は他の利用可能なリモートアクセス技法を介して）を介してのみアクセスすることができる。特定の実施態様において、コンピューティングシステム１２０は、クラウドベースの態様で構成されてもよく、他のクラウドベースのシステムがアクセス及び使用されるのと実質的に同様の方法でアクセス及び／又は使用されてもよい。

一旦データがコンピューティングシステム１２０において生成及び／又は構成されると、データは医療撮像システム１１０にコピー及び／又はロードされ得る。これは様々な方法で行うことができる。例えば、データは、医療撮像システム１１０とコンピューティングシステム１２０との間の有向接続又はリンク（ｄｉｒｅｃｔｅｄ ｃｏｎｎｅｃｔｉｏｎｓ ｏｒ ｌｉｎｋｓ）を介してロードされてもよい。これに関して、セットアップ１００内の異なる要素間の通信は、利用可能な有線及び／又は無線接続を使用して、及び／又は任意の適切な通信（及び／又はネットワーキング）標準又はプロトコルに従って行われてよい。代替的に、又は追加的に、データを医療撮像処理システム１１０に間接的にロードしてもよい。例えば、データは、適切な機械可読媒体（例えば、フラッシュカード等）に格納されてもよく、この媒体は、次に、データを医療撮像処理システム１１０にロードするために（システムのユーザ（例えば、撮像臨床医：ｉｍａｇｉｎｇ ｃｌｉｎｉｃｉａｎｓ）又は許可された要員によって）、或いは、データは、ローカル通信可能な電子装置（例えば、ラップトップ等）にダウンロードされてもよく、この電子装置は、次に、直接接続（例えば、ＵＳＢコネクタ等）を介して、医療撮像システム１１０にデータをアップロードするために、現場で（例えば、システムのユーザ又は許可された要員によって）使用される。

稼働中において、医療撮像処理システム１１０は、医用検査中の画像の生成及び提示（例えば、レンダリング又は表示）、並びに／又はそれに伴うユーザ入力／出力のサポートに使用され得る。画像は、２Ｄ、３Ｄ、及び／又は４Ｄ画像であってもよい。画像の生成及び／又は提示を容易にするために医療撮像システム１１０において実行される特定の操作又は機能は、システムのタイプ－即ち、画像に対応するデータが取得及び／又は生成される方法－に依存する。例えば、超音波撮像では、データは、図２に関してより詳細に説明するように、放出超音波信号及びエコー超音波信号に基づいている。

本開示に従って、医療撮像システム（例えば、医療撮像システム１１０）は、医療撮像ソリューションのための新しいデータ記憶及び管理方式をサポートするように構成されてもよい。この点に関して、医療データ、特に診断画像データは、多階層の階層型ストレージシステムにおいて「データブロブ：ｄａｔａ ｂｌｏｂｓ」としてアーカイブされ、データブロブの各々に対するメタデータの小さなレコードがリレーショナルデータベース（以下、「インデックス」と称する）に格納される場合がある。メタデータレコードは、対応するデータブロブが位置するファイルパスを含むことができる。このような方式は、様々な医療データアーカイブシステム、ベンダーニュートラルアーカイブ（ＶＮＡ：ｖｅｎｄｏｒ ｎｅｕｔｒａｌ ａｒｃｈｉｖｅ）、画像保存通信システム（ＰＡＣＳ：ｐｉｃｔｕｒｅ ａｒｃｈｉｖｉｎｇ ａｎｄ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｙｓｔｅｍ）等で採用されている。しかしながら、既存のデータ保存方式やそれに基づく解決策を使用する際には、様々な課題や問題が生じる可能性がある。

この点に関して、医療データの総量は、特に様々な高度な医療検査や画像処理に伴って、着実に（さらには指数関数的に）増加している。このような増加は、従来の１または複数のデータ記憶方式に特別な課題を生じさせている。これは、特に、従来の１または複数のデータ記憶方式に固有の非効率性による問題である。例えば、データアクセスは、多くの作業負荷において部分的なコンテンツしか必要とされず、かつ／又は要求されない可能性があるにもかかわらず、データブロブ全体レベルでサポートされる。さらに、内部の情報の一部が変更された場合、データブロブ全体を書き直す必要がある場合がある。さらに、データブロブ全体が同じストレージメカニズムで処理されることがあるが、内部の断片が異なれば、より効率的なメカニズムが異なる可能性がある。

したがって、本開示に従った様々な実施態様において、医療データ、特にデータブロブとしてアーカイブされたデータへのアクセス及び使用を改善するために、修正されたデータ記憶スキームが使用され得る。特に、新しいデータ記憶方式に従って、データブロブ全体をメタデータ部分とブロブデータ部分とに分離することができる。この点に関して、上述したように、従来の１または複数のデータ記憶方式は、典型的には、記憶されたデータオブジェクトのメタデータにアクセスするためにインデックス付きデータベースに依存する可能性があり、メタデータアクセスのためのインデックスコンテンツによって制限される可能性があり、また、大量のメタデータフェッチ（及び／又はそれに基づくデータ更新）が要求される可能性がある場合に性能の欠点に悩まされる可能性がある。

しかし、提案するデータスキームは、特に、医療データオブジェクトをメタデータ部分とブロブデータ部分とに分離し、さらに、明確に定義された標準フォーマットと高いデータ完全性保護とによって、それらを相互に双方向に参照することによって、このような問題に対処する。これにより、データ保存／管理システムにおいて、メタデータの作業負荷とブロブデータの作業負荷を分離し、リソースの利用を最適化し、操作性能を飛躍的に向上させ、柔軟なシステムアーキテクチャを実現することができる。さらに、メタデータとブロブデータに別々にアクセスするために、新しいアプリケーションプログラミングインターフェース（ＡＰＩ）を使用することもできる。さらに、データインデックス方式を更新することなく、豊富なメタデータ情報をアプリケーションに提供することができる。Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ（ＤＩＣＯＭ）に基づく実装例を図に示し、図に関して説明する。図３、４を参照して説明する。しかしながら、本開示は、ＤＩＣＯＭに基づく実装に限定されないことが理解されるべきである。

図２は、三次元（３Ｄ）医療撮像の視覚化を改善するためにヒストグラムビューの利用（ｕｔｉｌｉｚｉｎｇ ｈｉｓｔｏｇｒａｍ ｖｉｅｗｓ）を支援するように構成され得る例示的な超音波システムを示す。図２に示されているのは超音波システム２００である。

超音波システム２００は、超音波撮像（ｕｌｔｒａｓｏｕｎｄ ｉｍａｇｉｎｇ）を提供するように構成されることがあり、そのようなものとして、超音波撮像関連機能を実行及び／又は支援するための適切な回路、インターフェース、ロジック、及び／又はコードから構成されることがある。超音波システム２００は、図１の医療撮像システム１１０に対応することがある。超音波システム２００は、例えば、送信機２０２と、超音波プローブ２０４と、送信ビームフォーマ２１０と、受信機２１８と、受信ビームフォーマ２２０と、ＲＦプロセッサ２２４と、ＲＦ／ＩＱバッファ２２６と、ユーザ入力モジュール２３０と、信号プロセッサ２４０と、画像バッファ２５０と、表示システム２６０と、アーカイブ２７０と、トレーニングエンジン２８０とを含む。

送信機２０２は、超音波プローブ２０４を駆動するように動作可能な適切な回路、インターフェース、ロジック、及び／又はコードから構成され得る。超音波プローブ２０４は、圧電素子の二次元（２Ｄ）アレイから構成されることがある。超音波プローブ２０４は、通常は同じ素子を構成する送信トランスデューサ素子２０６と受信トランスデューサ素子２０８とから構成されてもよい。特定の実施形態では、超音波プローブ２０４は、心臓、血管、又は任意の適切な解剖学的構造などの解剖学の少なくとも実質的な部分をカバーする超音波画像データを取得するように動作可能であり得る。

送信ビームフォーマ２１０は、送信サブアパーチャビームフォーマ（ｔｒａｎｓｍｉｔ ｓｕｂ－ａｐｅｒｔｕｒｅ ｂｅａｍｆｏｒｍｅｒ）２１４を介して、関心領域（例えば、人間、動物、地下空洞、物理的構造など）に超音波送信信号を放出するように送信トランスデューサ素子２０６のグループを駆動する送信機２０２を制御するように動作可能な適切な回路、インターフェース、ロジック、及び／又はコードから構成され得る。送信された超音波信号は、血球や組織のような関心対象内の構造から後方散乱されてエコーを生成することができる。このエコーは、受信トランスデューサ素子２０８によって受信される。

超音波プローブ２０４内の受信トランスデューサ素子２０８のグループは、受信エコーをアナログ信号に変換するように動作可能であり得、受信サブアパーチャビームフォーマ（ｒｅｃｅｉｖｅ ｓｕｂ－ａｐｅｒｔｕｒｅ ｂｅａｍｆｏｒｍｅｒ）２１６によるサブアパーチャビームフォーミングを受け、次いで、受信機２１８に通信される。受信機２１８は、受信サブアパーチャビームフォーマ２１６からの信号を受信するように動作可能であり得る適切な回路、インターフェース、ロジック、及び／又はコードから構成され得る。アナログ信号は、複数のＡ／Ｄ変換器２２２のうちの１つ以上に伝達される。

複数のＡ／Ｄ変換器２２２は、受信機２１８からのアナログ信号を対応するデジタル信号に変換するように動作可能であり得る適切な回路、インターフェース、ロジック、及び／又はコードから構成され得る。複数のＡ／Ｄ変換器２２２は、受信機２１８とＲＦプロセッサ２２４との間に配置される。しかしながら本開示はこの点で限定されない。したがって、いくつかの実施形態では、複数のＡ／Ｄ変換器２２２は、受信機２１８内に統合されてもよい。

ＲＦプロセッサ２２４は、複数のＡ／Ｄ変換器２２２によって出力されたデジタル信号を復調（ｄｅｍｏｄｕｌａｔｅ）するように動作可能であり得る適切な回路、インターフェース、ロジック、及び／又はコードから構成され得る。一実施形態に従って、ＲＦプロセッサ２２４は、デジタル信号を復調して、対応するエコー信号を代表するＩ／Ｑデータ対（Ｉ／Ｑ ｄａｔａ ｐａｉｒｓ）を形成するように動作可能な複素復調器（図示せず）を含んでもよい。ＲＦ又はＩ／Ｑ信号データは、その後、ＲＦ／ＩＱバッファ２２６に通信されることができる。ＲＦ／ＩＱバッファ２２６は、ＲＦプロセッサ２２４によって生成されるＲＦ又はＩ／Ｑ信号データの一時的な記憶を提供するように動作可能であり得る適切な回路、インターフェース、ロジック、及び／又はコードから構成され得る。

受信ビームフォーマ２２０は、例えば、ＲＦ／ＩＱバッファ２２６を介してＲＦプロセッサ２２４から受信された遅延チャネル信号を合計し、ビーム合計信号を出力するためのデジタルビームフォーミング処理を実行するように動作可能であり得る適切な回路、インターフェース、ロジック、及び／又はコードから構成され得る。結果として得られる処理された情報は、受信ビームフォーマ２２０から出力され、信号プロセッサ２４０に伝達されるビーム和信号（ｂｅａｍ ｓｕｍｍｅｄ ｓｉｇｎａｌ）であってもよい。幾つかの実施形態に従って、受信器２１８、複数のＡ／Ｄ変換器２２２、ＲＦプロセッサ２２４、及びビームフォーマ２２０は、デジタルであってもよい単一のビームフォーマに統合されてもよい。様々な実施形態において、超音波システム２００は、複数の受信ビームフォーマ２２０を備える。

ユーザ入力装置２３０は、患者データ、スキャンパラメータ、設定の入力、プロトコル及び／又はテンプレートの選択、トラッキングターゲットを選択するための人工知能セグメンテーションプロセッサ（ａｒｔｉｆｉｃｉａｌ ｉｎｔｅｌｌｉｇｅｎｃｅ ｓｅｇｍｅｎｔａｔｉｏｎ ｐｒｏｃｅｓｓｏｒ）との対話等に利用することができる。例示的な実施形態では、ユーザ入力装置２３０は、超音波システム２００内の１つ以上の構成要素及び／又はモジュールの動作を構成、管理及び／又は制御するように動作可能であり得る。これに関して、ユーザ入力装置２３０は、送信機２０２、超音波プローブ２０４、送信ビームフォーマ２１０、受信機２１８、受信ビームフォーマ２２０、ＲＦプロセッサ２２４、ＲＦ／ＩＱバッファ２２６、ユーザ入力装置２３０、信号プロセッサ２４０、画像バッファ２５０、表示システム２６０、及び／又はアーカイブ２７０の動作を構成、管理、及び／又は制御するように動作可能であり得る。

例えば、ユーザ入力装置２３０は、１以上のボタン、１以上のロータリーエンコーダ、タッチスクリーン、モーショントラッキング、音声認識、マウス装置、キーボード、カメラ、及び／又は１以上のユーザ指令を受信することができる他の任意の装置を含むことができる。 特定の実施形態では、ユーザ入力装置２３０の１つ以上は、例えば、表示システム２６０又は超音波プローブ２０４などの他の構成要素に統合されてもよい。

一例として、ユーザ入力装置２３０は、タッチスクリーンディスプレイを含むことができる。別の例として、ユーザ入力装置２３０は、患者の身体に対する１つ以上のプローブの圧迫、予め定義されたプローブの移動又は傾斜操作などを識別するために、プローブ２０４のジェスチャ動作認識（ｇｅｓｔｕｒｅ ｍｏｔｉｏｎ ｒｅｃｏｇｎｉｔｉｏｎ）を提供するために、プローブ２０４に取り付けられ、及び／又はプローブ２０４と一体化された加速度計、ジャイロスコープ、及び／又は磁力計（ａｎ ａｃｃｅｌｅｒｏｍｅｔｅｒ， ｇｙｒｏｓｃｏｐｅ， ａｎｄ／ｏｒ ｍａｇｎｅｔｏｍｅｔｅｒ）を含むことができる。一部の実施例では、ユーザ入力装置２３０は、追加的又は代替的に、取得された画像データを解析することによってプローブのジェスチャを識別するための画像解析処理を含むことができる。本開示に従って、ユーザ入力及びそれに関連する機能は、本開示で説明するように、新たなデータ記憶方式の使用をサポートするように構成されてもよい。例えば、ユーザ入力デバイス２３０は、本明細書に記載されるような分離プロセス（ｓｅｐａｒａｔｉｏｎ ｐｒｏｃｅｓｓ）の適用をトリガし、（必要に応じて）管理することに向けられたユーザ入力を受信すること、及び／又は、そのようなプロセスを実行する際に使用されるパラメータを提供又は設定することをサポートするように構成され得る。同様に、ユーザ入力デバイス２３０は、本明細書に記載されるように、回復プロセス（ｒｅｃｏｖｅｒｙ ｐｒｏｃｅｓｓ）の適用を（必要に応じて）トリガ及び管理することに向けられたユーザ入力を受信すること、並びに／又はそのようなプロセスを実行する際に使用されるパラメータを提供又は設定することをサポートするように構成され得る。

信号プロセッサ２４０は、表示システム２６０上に提示するための超音波画像を生成するための超音波スキャンデータ（すなわち、合計ＩＱ信号：ｓｕｍｍｅｄ ＩＱ ｓｉｇｎａｌ）を処理するように動作可能であり得る適切な回路、インターフェース、ロジック、及び／又はコードから構成され得る。信号プロセッサ２４０は、取得された超音波スキャンデータに対して複数の選択可能な超音波モダリティ（ｓｅｌｅｃｔａｂｌｅ ｕｌｔｒａｓｏｕｎｄ ｍｏｄａｌｉｔｉｅｓ）に従って１つ以上の処理動作を実行するように動作可能である。例示的な実施形態では、信号プロセッサ２４０は、とりわけ表示処理及び／又は制御処理を実行するように動作可能であり得る。取得された超音波スキャンデータは、エコー信号が受信されるスキャンセッション中にリアルタイムで処理されてもよい。加えて又は代替的に、超音波スキャンデータは、スキャンセッション中にＲＦ／ＩＱバッファ２２６に一時的に格納され、ライブ又はオフライン動作においてリアルタイム未満で処理されてもよい。様々な実施形態において、処理された画像データは、表示システム２６０において提示され得、及び／又は、アーカイブ２７０において記憶され得る。アーカイブ２７０は、ローカルアーカイブ、ＰＡＣＳ（Ｐｉｃｔｕｒｅ Ａｒｃｈｉｖｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）、又は画像及び関連情報を格納するための任意の適切な装置であってよい。

信号プロセッサ２４０は、１つ又は複数の中央処理装置、マイクロプロセッサ、マイクロコントローラ、及び／又はこれらに類するものであってよい。信号プロセッサ２４０は、統合されたコンポーネントであってもよいし、例えば、様々な場所に分散されていてもよい。信号プロセッサ２４０は、特に、ユーザ入力デバイス２３０及び／又はアーカイブ２７０から入力情報を受信し、表示システム２６０によって表示可能な出力を生成し、ユーザ入力デバイス２３０からの入力情報に応答して出力を操作するように構成されてもよい。信号プロセッサ２４０は、例えば、様々な実施形態に従って、本明細書で議論される１以上の方法及び／又は１以上の命令セットのいずれかを実行することが可能であり得る。

超音波システム２００は、問題の撮像状況に適したフレームレートで超音波スキャンデータを連続的に取得するように動作可能であり得る。典型的なフレームレートは２０～２２０の範囲であるが、より低くても高くてもよい。取得された超音波スキャンデータは、フレームレートと同じか、より遅いか又はより速い表示レートで表示システム２６０に表示され得る。画像バッファ２５０は、即座に表示されることが予定されていない取得された超音波スキャンデータの処理されたフレームを格納するために含まれる。好ましくは、画像バッファ２５０は、少なくとも数分分の超音波スキャンデータのフレームを格納するのに十分な容量である。超音波スキャンデータのフレームは、その順序又は取得時間に従ってその検索を容易にする方法で記憶される。画像バッファ２５０は、任意の公知のデータ記憶媒体として具現化することができる。

例示的な実施形態では、信号プロセッサ２４０は、データ管理モジュール２４２を含んでよく、このデータ管理モジュール２４２は、本開示に記載されるような、医療撮像ソリューションのための新しいデータ記憶及び管理方式に関連する、又はそれを支援する様々な機能又は動作を実行及び／又はサポートするように構成され得る、適切な回路、インターフェース、ロジック、及び／又はコードを含んでよい。

いくつかの実装形態では、信号プロセッサ２４０（及び／又はデータ管理モジュール２４２などのその構成要素）は、人工知能及び／又は機械学習技術を実装及び／又は使用して、撮像関連の機能又は動作を強化及び／又は最適化するように構成されてもよい。例えば、信号プロセッサ２４０（及び／又はデータ管理モジュール２４２等のその構成要素）は、ディープニューラルネットワーク（例えば、畳み込みニューラルネットワーク（ＣＮＮ：ｃｏｎｖｏｌｕｔｉｏｎａｌ ｎｅｕｒａｌ ｎｅｔｗｏｒｋ））の使用等によるディープラーニング技術及び／又はアルゴリズムを実装及び／又は使用するように構成されてもよく、及び／又は、特定の基準を満たし、及び／又は特定の特性を有する構造（又はその組織）を識別、セグメント化、ラベル付け、及び追跡する等、取得された超音波画像を解析するように構成されてもよい任意の好適な形態の人工知能画像解析技術又は機械学習処理機能を利用してもよい。

例示的な実装では、信号プロセッサ２４０（及び／又はデータ管理モジュール２４２などのその構成要素）は、例えば、入力層、出力層、及び入力層と出力層との間の１つ又は複数の隠れ層（ｈｉｄｄｅｎ ｌａｙｅｒｓ）から構成され得る、深層ニューラルネットワークとして提供され得る。各層は、ニューロンと呼ばれる複数の処理ノードで構成される場合がある。例えば、ディープニューラルネットワークは、解剖学的構造のスキャン面からの各画素又は画素群に対応するニューロンを有する入力層を含み、出力層は、予め定義された複数の構造又は構造（又はその中の１以上の組織）の種類に対応するニューロンを有する。各層の各ニューロンは処理機能を実行し、処理された超音波画像情報をさらなる処理のために下流層の複数のニューロンのうちの１つに渡すことができる。

一例として、第１の層のニューロンは、超音波画像データ中の構造のエッジを認識するように学習することができる。 第２の層のニューロンは、第１の層から検出されたエッジに基づいて形状を認識するように学習することができる。第３の層のニューロンは、超音波画像データ中のランドマークに対する認識された形状の位置を学習することができる。第４の層のニューロンは、特定の構造に存在する特定の組織タイプの特徴などを学習してもよい。このように、ディープニューラルネットワーク（例えば、畳み込みニューラルネットワーク（ＣＮＮ））によって実行される処理によって、超音波画像データ内の生物学的構造及び／又は人工的構造を高い確率で識別することができる場合がある。

いくつかの実装では、信号プロセッサ２４０（及び／又はデータ管理モジュール２４２などのその構成要素）は、ユーザ入力デバイス２３０を介したユーザ命令に基づいて、それによって実行される機能の少なくともいくつかを実行又は他の方法で制御するように構成され得る。一例として、ユーザは、音声コマンド、プローブジェスチャ、ボタン押下などを提供して、本開示で説明するように、人工知能（ＡＩ）ベースの動作を含む新しいデータ管理方式の様々な態様を開始及び／又は制御する、及び／又はそれに関連する様々なパラメータ又は設定を提供又は他の方法で指定するなどの特定の命令を発行することができる。

トレーニングエンジン２８０は、信号プロセッサ２４０（及び／又はデータ管理モジュール２４２などのその構成要素）の１以上のディープニューラルネットワークのニューロンをトレーニングするように動作可能であり得る適切な回路、インターフェース、ロジック、及び／又はコードを含んでよい。例えば、信号プロセッサ２４０は、超音波スキャン面内に提供される特定の構造及び／又は組織（又はそのタイプ）を識別するように訓練されてもよく、訓練エンジン２８０は、様々な構造の分類された超音波画像の１以上のデータベースを使用するなど、必要な機能の一部を実行するようにその１以上のディープニューラルネットワークを訓練する。

一例として、トレーニングエンジン２８０は、１以上の特定の構造のエッジの外観、エッジに基づく構造の形状の外観、超音波画像データ内のランドマークに対する形状の位置などの特定の構造の特性に関して、及び／又は特定の組織の特性（例えば、その柔らかさ）に関して、信号プロセッサ２４０（及び／又はデータ管理モジュール２４２などのその構成要素）をトレーニングするために特定の構造の超音波画像を利用するように構成され得る。様々な実施形態において、訓練画像のデータベースは、アーカイブ２７０又は任意の適切なデータ記憶媒体に記憶され得る。特定の実施形態では、トレーニングエンジン２８０及び／又はトレーニング画像データベースは、超音波システム２００に有線又は無線接続を介して通信可能に結合された１以上の外部システムであってもよい。

動作において、超音波システム２００は、二次元（２Ｄ）、三次元（３Ｄ）、及び／又は四次元（４Ｄ）画像を含む超音波画像を生成する際に使用され得る。この点に関して、超音波システム２００は、問題の撮像状況に適した特定のフレームレートで超音波スキャンデータを連続的に取得するように動作可能であり得る。例えば、フレームレートは２０～７０の範囲であってもよいが、より低くても高くてもよい。取得された超音波スキャンデータは、表示システム２６０上に、フレームレートと同じか、より遅いか又はより速い表示レートで表示され得る。画像バッファ２５０は、直ちに表示される予定のない取得された超音波スキャンデータの処理されたフレームを格納するために含まれる。好ましくは、画像バッファ２５０は、少なくとも数秒分の超音波スキャンデータのフレームを記憶するのに十分な容量である。超音波スキャンデータのフレームは、その順序又は取得時間に従ってその検索を容易にする方法で記憶される。画像バッファ２５０は、任意の公知のデータ記憶媒体として具現化することができる。

いくつかの実施態様では、超音波システム２００は、グレースケール及びカラーベースの動作をサポートするように構成され得る。例えば、信号プロセッサ２４０は、グレースケールＢモード処理及び／又はカラー処理を実行するように動作可能であり得る。グレースケールＢモード処理は、ＢモードＲＦ信号データ又はＩＱデータ対を処理することを含んでよい。例えば、グレースケールＢモード処理は、量（Ｉ２＋Ｑ２）１／２を計算することによって、ビーム和受信信号の包絡線を形成することを可能にし得る。エンベロープは、表示データを形成するために対数圧縮などの追加のＢモード処理を受けることができる。

表示データは、ビデオ表示のためにＸ－Ｙフォーマットに変換することができる。スキャン変換されたフレームは、表示のためにグレースケールにマッピングされ得る。画像バッファ２５０及び／又は表示システム２６０に提供されるＢモードフレーム。カラー処理は、カラーベースのＲＦ信号データ又はＩＱデータ対を処理して、画像バッファ２５０及び／又は表示システム２６０に提供されるＢモードフレーム上にオーバーレイするフレームを形成することを含み得る。グレースケール及び／又はカラー処理は、ユーザ入力（例えば、特定の領域のグレースケール及び／又はカラーの強化のためのユーザ入力デバイス２３０からの選択）に基づいて適応的に調整されてもよい。

いくつかの実施態様では、超音波撮像は、体積超音波画像の生成及び／又は表示を含むことがある－すなわち、物体（例えば、器官、組織など：ｏｒｇａｎｓ， ｔｉｓｓｕｅｓ， ｅｔｃ．）が３次元３Ｄ表示される。この点に関して、３Ｄ（及び同様に４Ｄ）撮像では、撮像された物体に対応するボクセルを含む体積超音波データセットが取得され得る。これは、例えば、音波を単に一方向（例えば、真下）に送信するのではなく、異なる角度で送信し、反射して戻ってくる音波を捕捉することによって行うことができる。次に、（異なる角度での送信の）反射エコーが捕捉され、（例えば、信号プロセッサ２４０を介して）処理されて、対応する体積データセットが生成され、この体積データセットは、ディスプレイ２５０を介するなどして、体積（例えば、３Ｄ）画像の作成及び／又は表示に使用され得る。これは、所望の３Ｄ知覚を提供するための特定の処理技術の使用を伴う場合がある。

例えば、ボリュームレンダリング技術は、ボリュームメトリック（例えば、３Ｄ）データセットの投影（例えば、２Ｄ投影）を表示する際に使用することができる。これに関して、３Ｄデータセットの２Ｄ投影をレンダリングすることは、表示されるオブジェクトに対する空間内の知覚角度（ｐｅｒｃｅｐｔｉｏｎ ａｎｇｌｅ）を設定又は定義し、データセット内のすべてのボクセルに対して必要な情報（例えば、不透明度及び色）を定義又は計算することを含む場合がある。これは、例えば、各ボクセルのＲＧＢＡ（赤、緑、青、アルファ）値を定義するための適切な伝達関数を用いて行うことができる。

様々な実施態様において、超音波システム２００は、本開示において説明されるような、医療撮像ソリューションのための新たなデータ記憶及び管理方式をサポートするように構成されてもよい。例えば、撮像データが取得又は生成されると、信号プロセッサ２４０（及び／又はデータ管理モジュール２４２等のその構成要素）は、処理された画像をアーカイブ２７０に格納してもよく、このアーカイブ２７０は、信号プロセッサ２４０（及び／又はデータ管理モジュール２４２等のその構成要素）から独立して、又は信号プロセッサ２４０（及び／又はデータ管理モジュール２４２等のその構成要素）の制御の下で、データにアーカイブベースの符号化（例えば、ＤＩＣＯＭベースの符号化）を適用し、次いで、本明細書で説明するような分離プロセスを適用して、結果として得られるデータオブジェクトを対応する格納場所（ローカル又はリモート）に送信するために必要な通信機能を実行することを含む、格納及び管理を行うように構成されてもよい。アーカイブ２７０はまた、データを送り返すように構成されてもよく、オンザフライ回復（ｏｎ－ｔｈｅ－ｆｌｙ ｒｅｃｏｖｅｒｙ）を含む回復プロセスを実行するように構成されてもよい。この点に関して、アーカイブ２７０は、対応するデータオブジェクトをストレージロケーション（ローカル又はリモート）から要求及び受信するために必要な通信機能を実行すること、及び表示システム２６０を介した表示など、対応する画像の生成を可能にするためにデータをデコードすることを含む、以前にアーカイブされたデータに回復プロセスを適用するように構成されてもよい。これらの機能は、信号プロセッサ２４０（及び／又はデータ管理モジュール２４２などのそのコンポーネント）によって制御又は管理されてもよい。あるいは、アーカイブ２７０は、これらの機能の少なくともいくつかを独立して実行するように構成されることもあり、そのような場合、プロセッサ２４０は、データが何らかの分離を受けたことを知らないこともある。場合によっては、プロセッサ２４０（及び／又はデータ管理モジュール２４２などのその構成要素）は、応答時間及びスループットをさらに向上させるために、スキーム（例えば、メタデータ及びブロブを別々に取得するように構成されるスキーム）に従ってデータを処理してもよい。

図３は、医療撮像ソリューションのための新しいデータ記憶及び管理方式で使用するためのメタデータ分離のための例示的なプロセスを示す。図３に示されるのは、ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）ベースのデータ構造による新しいデータ記憶及び管理スキームの使用を示すブロック図３００である。

この点に関して、新しいデータ記憶スキームは、多くのタイプの医療データ（例えば、画像、波形、臨床観察など：ｉｍａｇｅｓ， ｗａｖｅｆｏｒｍｓ， ｃｌｉｎｉｃａｌ ｏｂｓｅｒｖａｔｉｏｎｓ， ｅｔｃ．）に適用可能であり、これらは、捕捉された検査、測定、観察、及びモニタリングデータとその被験者及び臨床コンテキストとを表すように、属性の集合体としてモデル化され得るが、図３は、新しいデータ記憶スキームがどのように機能するかを説明するために、ＤＩＣＯＭサービスオブジェクトペア（ＳＯＰ：Ｓｅｒｖｉｃｅ Ｏｂｊｅｃｔ Ｐａｉｒ）インスタンスへの新しいデータ記憶スキームの適用例を示している。

図３に示すように、新しいデータ記憶方式に従って、ＤＩＣＯＭベースのデータブロブは、メタデータ部分とブロブデータ部分とに分離され得る。この点に関して、ＤＩＣＯＭヘッダとピクセルデータは、特に内部記憶フォーマットとして、いくつかの既存の解決策において分割されるかもしれないが、新しいデータ記憶スキームに従ってデータブロブに適用される分離は、それ以上のものを伴う。特に、オープンな業界標準を使用する新しいデータ記憶方式に従って、すべてのデータファイルは標準フォーマットに従って構造化され、したがって独立して検証可能であり、統一資源位置指定子（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）のような統一資源識別子（ＵＲＩ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ）を使用するなどして、一緒にリンクされる。これらは、高度なデータの完全性と回復力、データ管理とストレージの柔軟性の大幅な向上、パフォーマンスの改善、生産性の向上につながる。以下の文章では、考えられるいくつかの新しい用途の事案（ｐｏｓｓｉｂｌｅ ｎｅｗ ｕｓｅ ｃａｓｅｓ）について説明する。

データブロブをメタデータとブロブデータの部分に分離することに関して、最上位レベル（ｔｏｐ ｌｅｖｅｌ）では、ＤＩＣＯＭ ＳＯＰインスタンスをデータブロブ全体として扱う代わりに、画像ピクセルデータ（所望であれば、他のバイナリデータ）及び他の大きなサイズのタグ（標準タグとプライベートタグの両方）を削除し、別々のデータファイルに保存することができる。その結果得られるオブジェクトを、以下ではＤＩＣＯＭ ＳＯＰインスタンスメタデータ（ＤＩＣＯＭ ＳＯＰ ｉｎｓｔａｎｃｅ ｍｅｔａｄａｔａ）と呼ぶ。したがって、各ＤＩＣＯＭ ＳＯＰインスタンスは、１つのメタデータオブジェクト（「Ｄ（ｍｅｔａ）」と表記する）と０～Ｎ個のブロブデータオブジェクトに分割され、データは画像ピクセルデータ又は他のバイナリラージサイズデータタグコンテンツ（「Ｄ（ｂｌｏｂ）」と表記する）であってもよい。

分離プロセス、及びそれに基づいて生成されたオブジェクトは、より効率的な、及び／又はその他の新しいデータ管理及びアーカイブパラダイム（ａｒｈｃｉｖｉｎｇ ｐａｒａｄｉｇｍｓ）を可能にする様々な有用な特性を有する可能性がある。このような特性には、例えば以下のようなものがある。１）Ｄ（ｍｅｔａ）にはＤ（ｂｌｏｂ）に関する被験者情報及び臨床コンテキスト情報が含まれる場合があり、ほとんどのコンシューマアプリケーションは通常、ブロブデータが必要かどうかを判断する前に、まずＤ（ｍｅｔａ）にアクセスする必要がある。２）Ｄ（ｍｅｔａ）とＤ（ｂｌｏｂ）は、データ管理やアクセス可用性の点で異なる性質を持つ場合がある。例えば、Ｄ（ｍｅｔａ）は修正（例えば、被験者情報の照合、研究／シリーズ構造、再編成など：ｓｕｂｊｅｃｔ ｉｎｆｏｒｍａｔｉｏｎ ｒｅｃｏｎｃｉｌｉａｔｉｏｎ， ｓｔｕｄｙ／ｓｅｒｉｅｓ ｓｔｒｕｃｔｕｒｅ ｒｅ－ｏｒｇａｎｉｚａｔｉｏｎ）の対象となる場合があり、アクセスに対して非常に高速な応答が要求される場合があるが、Ｄ（ｂｌｏｂ）は完全に不変である場合があり、アクセスに関して高いスループットが重視される場合がある。３）Ｄ（ｍｅｔａ）は完全な保護医療情報（ＰＨＩ：Ｐｒｏｔｅｃｔｅｄ Ｈｅａｌｔｈ Ｉｎｆｏｒｍａ）データであり、したがって極めて機密性の高い情報である可能性がある。しかし、これは必ずしもこれらのオブジェクトがＰＨＩでないことを示唆するものではなく、むしろ機密性のレベルが異なる可能性があり、特にハイブリッドクラウド、分散ストレージインフラでは重要な考慮事項かもしれない。４）Ｄ（ｍｅｔａ）のサイズ（例えばメガバイト（ＭＢ））は、Ｄ（ｂｌｏｂ）のサイズより劇的に小さいかもしれない。例えば、Ｄ（ｂｌｏｂ）に対するＤ（ｍｅｔａ）のサイズ比は１００以上である。分離スキーム（ｓｅｐａｒａｔｉｏｎ ｓｃｈｅｍｅ）では、このような特性を利用し、トレードオフなしにアクセス性能、ストレージ効率、及び高いセキュリティ標準を最適化することができる。

メタデータ分離プロセスの例が図３に示されており、バイナリ標準タグ（例えば、ピクセルデータ）及びラージサイズプライベートタグ値が元のＤＩＣＯＭ ＳＯＰインスタンス３１０から除去され、別個のバイナリデータファイルに保存される。具体的なデータ構造及びそれに基づくＵＲＩリンクも図示されており、ここで図３（特に右側）を参照してさらに説明する。

Ｄ（ｂｌｏｂ）は、ピクセルデータ又は他のバイナリデータから構成され得る。ピクセルデータの場合、それがシングルフレームであれマルチフレームであれ、Ｄ（ｂｌｏｂ）は、バイナリデータファイル内のフレームの連続リストとして符号化され得る。例えば、Ｄ（ｂｌｏｂ）は以下のフォーマットで符号化される。１）ファイル署名（ｆｉｌｅ ｓｉｇｎａｔｕｒｅ）、２）このブロブデータファイルが属するＳＯＰインスタンスＵＩＤを示す一意識別子（ＵＩＤ：ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ）、３）ファイルに連続的に格納される、テーブルの端からの相対的な各画像フレームのオフセットテーブル、４）オリジナルのＳＯＰインスタンスでエンコードされるのと同じ順序でフレーム毎に格納される画像フレーム、５）オリジナルのＳＯＰインスタンスと同じフォーマットで圧縮バイトストリーム（例えば、ＪＰＥＧファイル交換フォーマット（ＪＦＩＦ：ＪＰＥＧ Ｆｉｌｅ Ｉｎｔｅｒｃｈａｎｇｅ Ｆｏｒｍａｔ））に格納される画像フレームデータ。圧縮フレームバイトストリームは、ＤＩＣＯＭシーケンス項目が要求する偶数バイトの長さを有する。そのため、パディングバイト（ｐａｄｄｉｎｇ ｂｙｔｅ）が含まれてもよい。ＪＦＩＦストリームを保存することにより、データの整合性チェックが１つ追加される。他の（一般的な）バイナリブロブＤ（ｂｌｏｂ）は、元のＳＯＰインスタンスにあるのと同じバイトストリームのバイナリファイルに格納されてもよい。例えば、そのような場合、Ｄ（ｂｌｏｂ）は以下のフォーマットでエンコードされる。１）ファイル署名、２）このブロブデータファイルが属するＳＯＰインスタンスＵＩＤを表すＵＩＤ、３）メタデータコンテキストでエンコードされたバイナリブロブデータのバイトストリーム。したがって、Ｄ（ｂｌｏｂ）は、元のＳＯＰインスタンスの転送構文を適用することにより復号化されうる、有効なＤＩＣＯＭ符号化ストリームであってもよい。一実施例の実装では、ファイル署名は４バイトであり、一意識別子（ＵＩＤ）は６４バイトであり、オフセットテーブルは（Ｎ＋１）個の４バイト整数であり、最初の整数値はテーブルの長さを表し、その後にテーブルの終わりからの相対的な各画像フレームのオフセットが連続してファイルに格納される。

Ｄ（ｍｅｔａ）は、ＤＩＣＯＭＰａｒｔ１０ファイルで符号化されてもよいが、若干の修正を加えてもよい。例えば、Ｄ（ｍｅｔａ）は以下のように符号化される。１）ピクセルタグをピクセルデータプロバイダタグに置き換える、Ｄ（ｂｌｏｂ）ファイルを指すＵＲＩ（例えばＵＲＬ）を含む。２）バイナリブロブファイルに格納された、すべての大きなサイズのブロブデータ要素の値（データ）を削除する（したがって、１つ又は複数のＤ（ｂｌｏｂ）ファイルが作成される）。実装例では、ファイル署名は４バイト、一意識別子（ＵＩＤ）は６４バイトである。

元のＤＩＣＯＭ ＳＯＰインスタンスを回復することは、単に分離プロセスの逆の操作を実行することによって達成され得る。このような回復処理は、図４に示され、図４に関してより詳細に説明される。

図４は、メタデータオブジェクトから撮像学習メタデータ文書を導出するための例示的な使用シナリオを示す。図４に示されるのは、新しいデータ記憶及び管理スキームの実装に基づく使用シナリオを示すブロック図４００である。

新しいデータ記憶及び管理スキーム、並びにそれに基づいて生成されたデータ構造を使用することにより、既存のソリューションでは可能でない、又は利用できない可能性のあるさまざまな機能を実行できるようになる可能性がある。例えば、ブロブデータオブジェクトに全くアクセスすることなく、メタデータワークロードに基づいてのみ、様々な機能を有効にすることができる。例えば、画像検査メタデータ文書は、図４に示されるように、ビューアアプリケーションにワンストップショッピングを提供するために、検査の個々のＤＩＣＯＭ ＳＯＰインスタンスのメタデータオブジェクトから導出され得る。

この点に関して、元のＤＩＣＯＭ ＳＯＰインスタンスを回復することは、単に分離プロセスの逆操作（ｒｅｖｅｒｓｅ ｏｐｅｒａｔｉｏｎ）である可能性がある。特に、署名された署名（ｓｉｇｎｅｄ ｓｉｇｎａｔｕｒｅ）により、高水準のデータ保護を達成することができる。例えば、セキュリティポリシー、要求、及び利用可能なインフラストラクチャに基づいて、ブロックチェーンベースの台帳を含む追加のセキュリティ手段を使用して、Ｄ（ｍｅｔａ）及びＤ（ｂｌｏｂ）のすべてを保護することができる。例えば、特定のアクセスプロファイル構成に基づいて、ネットワークトラフィック及びデータスループットを最適化するために、大きなサイズのブロブデータ要素を有するか又は有さないＤＩＣＯＭ ＳＯＰインスタンスを再組み立てすることが可能であり得る。Ｄ（ｍｅｔａ）とＤ（ｂｌｏｂ）間の双方向リンクはデータの完全性をさらに高める。

ビューアアプリケーション（Ｖｉｅｗｅｒ ａｐｐｌｉｃａｔｉｏｎｓ、例えば、医療撮像診断の結果を分析するために使用されるシステムにおいて）は、インデックスデータベースへの高価な複数のクエリ（ｅｘｐｅｎｓｉｖｅ， ｍｕｌｔｉｐｌｅ ｑｕｅｒｉｅｓ）を行うことなく、ＤＩＣＯＭ ＳＯＰインスタンス提示を計画するために画像診断研究メタデータ文書を使用することができる。新たな記憶及び管理スキーム並びにそれに基づく分離プロセスは、多数の新たな使用例を可能にし得る。このような使用例の例には、システム性能のためのメタデータ作業負荷とブロブデータ作業負荷の分離、メタデータ及びブロブデータのための柔軟なストレージアーキテクチャ、メタデータ及びブロブデータのためのデータ保護及びセキュリティ実装が含まれる。

システム性能に基づくユースケースのためのメタデータ作業負荷とブロブデータ作業負荷の分離の実施例では、Ｄ（ｍｅｔａ）とＤ（ｂｌｏｂ）を元のＤＩＣＯＭ ＳＯＰインスタンスに再組み立てる（ｒｅａｓｓｅｍｂｌｅ）ことによって、標準ＤＩＣＯＭ ＡＰＩがサポートされる場合がある。ＡＰＩ（例えば、ＤＩＣＯＭ Ｗｅｂ）は、メタデータとブロブデータに別々にアクセスすることを可能にするために提供されてもよく、これは、大規模な研究の全ての画像が検索される場合であっても、メタデータへのはるかに高速なアクセスを可能にし、一方、画像ピクセルデータは、オンデマンドでアクセスされてもよい。データ管理機能は、データベース内のインデックス付けされたメタデータを修正し、後でＤＩＣＯＭ ＳＯＰインスタンスに修正を適用するのではなく、直接Ｄ（ｍｅｔａ）を修正することができる。メタデータオブジェクトは、データ発見のためにデータレイク／文書クエリ処理エンジン（ｄａｔａ ｌａｋｅ／ｄｏｃｕｍｅｎｔ ｑｕｅｒｙ ｐｒｏｃｅｓｓｉｎｇ ｅｎｇｉｎｅ）にロードすることができる。データオブジェクトのターゲットコレクションが見つかった後、メタデータ内のＵＲＩを使用してブロブデータをシームレスに検索することができる。

メタデータとブロブデータのための柔軟なストレージアーキテクチャの例では、メタデータは、ブロブデータベースのユースケースとは独立して保存することができる。メタデータは、ブロブデータベースのユースケースから独立して格納することができ、ユーザがそうすることを望む場合、メタデータはオンプレミス（ｏｎ－ｐｒｅｍｉｓｅｓ）で管理されるが、不変ピクセルデータはクラウドベースのストレージに移動することができる。これにより、ユーザはコンテキストデータ（メタデータ）を厳密に管理しながら、計算機とストレージのリソースを削減することができ、一方でコンテキストの（ほとんど）ないデータ（ブロブデータ）はクラウドストレージを活用することができる。より効率的な大量データアクセスとエクスポート。例えば、研究用やＡＩモデルのトレーニング用として、非識別化されたメタデータでアーカイブを設定し、運用アーカイブと分離されたストアで管理される不変のブロブデータを共有することができる。メタデータはエッジに配置され（レプリケートされるかもしれない）、ブロブデータはディープストレージにアーカイブされ、レスポンスタイムとスループットの両方の目標を達成することができる。

メタデータ及びブロブデータに基づくユースケースのための例示的なデータ保護及びセキュリティ実装では、メタデータ及びブロブデータは、基礎となるストレージメカニズム及びビジネスニーズを最もよく満たす異なるセキュリティ対策で取り扱われることができる。例えば、パブリッククラウドにアーカイブされたブロブデータは、ブロックチェーン台帳で監査追跡される可能性があり、ユーザが選択した鍵（ｕｓｅｒ－ｓｅｌｅｃｔｅｄ ｋｅｙｓ）は、自身のデータセンターでメタデータを暗号化するために使用される可能性がある。

図５は、ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）に基づくデータのブロブオブジェクト及びメタデータオブジェクトへの分離の使用シナリオ例（ｅｘａｍｐｌｅ ｕｓｅ ｓｃｅｎａｒｉｏ）を示す。図５に示されるのは、ＤＩＣＯＭデータセット５１０の分離例を示すブロック図５００である。

ＤＩＣＯＭデータセット５１０は、データ要素の集まりから構成されることがある。本明細書で説明されるような別個のプロセスの適用の結果として、共通メタデータオブジェクト５２０（例えば、図３に関して説明されるようなＤ（ｍｅｔａ））及び分離されたブロブデータ５３０が生成されることがある。これに関して、分離されたブロブデータ５３０は、上述のように、バイナリデータ及びメディアデータを含む１以上のブロブデータオブジェクトと、オフセットテーブルとから構成される場合がある。

分離に関して、ブロブ要素（図５では「他のブロブ：ｏｔｈｅｒ ｂｌｏｂ」と表記）を決定するための閾値が定義される場合があり、そのデータ値は別のブロブデータファイル又はオブジェクトに移動される。ブロブ要素はメタデータに残るが、その値はＮＵＬＬに設定されてもよい。これらの要素を追跡し、ＵＲＩを使用するなどして、対応する移動されたブロブデータ値へのリンクを提供するために、追跡用の新しい要素（「ブロブデータＵＲＩシーケンス：Ｂｌｏｂ Ｄａｔａ ＵＲＩ Ｓｅｑｕｅｎｃｅ」と表記）が追加されてもよい。ピクセルデータ要素は、新しい要素（「ピクセルデータプロバイダ：Ｐｉｘｅｌ Ｄａｔａ Ｐｒｏｖｉｄｅｒ」と表記）で直接置き換えられてもよい。

ブロブデータには、メタデータコンテキストでのみ有用な汎用バイトストリームと、メタデータコンテキスト（ＪＰＥＧなど）とは無関係に有用なＭＩＭＥ型アクセス可能データ（ＭＩＭＥ－ｔｙｐｅ ａｃｃｅｓｓｉｂｌｅ ｄａｔａ）とがある。特に、汎用バイトストリームは、ＤＩＣＯＭデータ要素コンテキスト（ＤＩＣＯＭ ｄａｔａ ｅｌｅｍｅｎｔ ｃｏｎｔｅｘｔ）においてのみ有用である。圧縮される場合、圧縮形式は、包含するデータセットの特定の転送構文の下で、ＤＩＣＯＭデータ要素コンテキストに適合しなければならない。ＭＩＭＥ型データは、包含するデータセットの転送構文（ｔｒａｎｓｆｅｒ ｓｙｎｔａｘ）に適合したメディア形式に基づいて、圧縮されていても平文（ｃｏｍｐｒｅｓｓｅｄ ｏｒ ｐｌａｉｎ）であってもよい。このようなデータは、ＤＩＣＯＭデータ要素のコンテキストとは無関係に有用である。

場合によっては、ブロブデータ（及びメタデータも）は、保管及び管理の効率化のために、より大きなブロブにさらに統合されることがある。

図６は、統合ヘルスケアエンタープライズ（ＩＨＥ）患者ケアデバイス（ＰＣＤ）デバイスエンタープライズ通信（ＤＥＣ）ベースのデータをブロブ及びメタデータオブジェクトに分離するための使用シナリオ例を示す。図６に示されるのは、ＩＨＥ ＰＣＤ ＤＥＣデータセット６１０の分離例（ｅｘａｍｐｌｅ ｓｅｐａｒａｔｉｏｎ ｏｆ ＩＨＥ ＰＣＤ ＤＥＣ ｄａｔａｓｅｔ）を示すブロック図６００である。

ＩＨＥ ＰＣＤ ＤＥＣデータセット６１０は、データ要素の集まりから構成され得る。本明細書で説明されるような別個のプロセスの適用の結果として、共通メタデータオブジェクト６２０（たとえば、図３に関して説明されるようなＤ（ｍｅｔａ））及び分離されたブロブデータ６３０が生成され得る。これに関して、分離されたブロブデータ６３０は、上述したように、バイナリブロブデータ、メディアブロブデータ、プロトコルブロブデータ、及びオフセットテーブルを含む、１以上のブロブデータオブジェクトから構成され得る。

分離は、図５に関して説明したのと実質的に同じ方法で適用することができる。これに関して、バイナリブロブデータ及び画素ブロブデータは、図５に関して説明したのと同じブロブデータと実質的に同様であってよい。ブロブデータの第３のタイプは、ＩＨＥ ＰＣＤ ＤＥＣデータセット６１０に適用される分離プロセスにおいて追加される、すなわち、メタデータコンテキストにおいてのみ有用であり、基礎となるアプリケーションプロトコルに従って解析される、アプリケーションプロトコルフォーマットされたデータブロック（例えば、ＨＬ７（Ｈｅａｌｔｈ Ｌｅｖｅｌ Ｓｅｖｅｎ）フォーマットされたデータセグメント）からなり得るプロトコルブロブデータである。標準プロトコルによるこのようなデータセットは、包含するプロトコルデータセットに直接挿入されてもよく、汎用ツールで圧縮されてもよい。

場合によっては、ブロブデータ（及びメタデータも）は、ストレージ及び管理の効率化のために、より大きなブロブにさらに統合されることがある。

図７は、ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）に基づく符号化データセットの例を示す。図７に示されているのは、ＤＩＣＯＭデータセット７００である。

ＤＩＣＯＭデータセット７００は、データ要素の集まりである。各データ要素は、タグ、値タイプ（ＶＲ：ｖａｌｕｅ ｔｙｐｅ）、値の長さ、及び値などのフィールドで構成され、及び／又は指定され得る。データ要素の値タイプ（ＶＲ）が「ＳＱ」（シーケンスを示す）である場合、そのデータ要素は多数の項目を含む。この点で、始点と終点を持つ各項目は、実際には通常のＤＩＣＯＭデータセットであり、データ要素の集合から順番に構成される。図７に示されるように、（１つのレベルの）シーケンスの項目内のデータ要素もＳＱである場合があり、これは（次のレベルの）いくつかの項目を含む場合がある。

図８は、ブロブデータをブロブオブジェクト及びメタデータオブジェクトに分離した後の、ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）ベースの符号化データセットの例を示す図である。図８に示されているのは、本開示に従った分離プロセスの適用後のＤＩＣＯＭデータセット８００である。これに関して、ＤＩＣＯＭデータセット８００は、分離プロセスの適用前の図７のＤＩＣＯＭデータセット７００と同様であってよい。分離プロセスは、特に図３及び図５に関して上述したように適用されてもよい。

図８に示すように、分離プロセスの適用後、識別されたすべてのブロブデータ要素はデータセットに残るが、これらのブロブデータ要素のそれぞれの値フィールドはＮＵＬＬに設定されてもよい。さらに、値の変更を反映するために、これらのブロブデータ要素のそれぞれの値の長さが「０」に設定されてもよい。ただし、タグと値タイプ（ＶＲ）フィールド、及びデータセット内のブロブデータ要素の位置は変更されないままである。ブロブデータ要素のバイナリ値は、ユニフォームリソースロケータ（ＵＲＬ：ｕＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）のようなユニフォームリソース識別子（ＵＲＩ：ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）を介して検索可能な、分離されたファイルに保存されてもよい。新しいシーケンス要素（「ブロブデータＵＲＬシーケンス」と表記）が、ＮＵＬＬ値のブロブ要素とその実際の値の場所を追跡するために追加される。たとえば、ブロブデータＵＲＬシーケンスは、それぞれが２つのフィールド（データセット内の特定のＮＵＬＬ値ブロブ要素の位置を追跡するための「タグパス」フィールドと、ＮＵＬＬ値ブロブ要素の実際の値が格納されている位置を指すＵＲＩ）を含む要素のリストから構成される。ピクセルデータ要素も、上述のようにピクセルデータプロバイダＵＲＩに置き換えられる。

図９は、本開示に従った新しいデータ記憶及び管理方式に基づく分離及び回復処理の例のフローチャートを示す。

図９に示されているのは、フローチャート９００及び９５０であり、それぞれ、医療撮像ソリューションのための新しいデータ記憶及び管理方式に基づいて撮像データセットを分離及び検索するために、好適なシステム（例えば、図１の医療撮像システム１１０及び／又はコンピューティングシステム１２０）において実行され得る複数の例示的なステップ（ブロック９０２～９１２及び９５２～９６２として表されている）から構成されている。

フローチャート９００に関して、開始ステップ９０２では、システムがセットアップされ、動作が開始されることがある。ステップ９０４において、アーカイブ符号化（例えば、ＤＩＣＯＭ、ＩＨＥ ＰＣＤ ＤＥＣ等）が撮像データに適用されてもよい。これに関して、撮像データは同じシステムで生成されてもよいし、別のシステムから取得されてもよい。ステップ９０６では、符号化データセット内のブロブ要素が識別され（ｉｄｅｎｔｉｆｉｅｄ）てもよい。これは、例えば、閾値を使用することによって行われてもよい。閾値はあらかじめ定義されていてもよいし、オペレータが設定又は調整してもよい。ステップ９０８では、特定されたブロブ要素に基づいて、メタデータ及びブロブデータオブジェクトが生成及び／又は更新される場合がある。これは、例えば、識別されたブロブ要素の値（データ）を別々のブロブデータオブジェクト（ｓｅｐａｒａｔｅ ｂｌｏｂ ｄａｔａ ｏｂｊｅｃｔｓ、バイトブロブデータ、メディアブロブデータ、プロトコルブロブデータなど、場合によっては異なるタイプを含む）に移動することを含んでよい。このステップはまた、識別されたブロブデータ要素内の残りのフィールドを更新すること（例えば、値をＮＵＬＬに設定すること、データオブジェクトへのリンクを追加すること等）、新しいフィールド／要素（例えば、ブロブデータＵｒｉシーケンス、ピクセルデータプロバイダ要素等）を追加することを含んでよい。ステップ９１０では、メタデータ及びブロブデータオブジェクトを（ローカル及び／又はリモートに）格納する。ステップ９１２では、オフセットテーブルが生成及び／又は更新されてもよい。

フローチャート９５０に関して、開始ステップ９５２では、システムがセットアップされ、動作が開始されることがある。ステップ９５４では、符号化されたデータセット内の必要なブロブ要素（ｒｅｑｕｉｒｅｄ ｂｌｏｂ ｅｌｅｍｅｎｔｓ ）が識別され（ｉｄｅｎｔｉｆｉｅｄ）る。これに関して、場合によっては、データセットの全体が必要とされることがあり、したがって、データセット内のすべてのブロブ要素の値（データ）が必要とされる。しかしながら、他の実施例では、データセットは、以前に得られた画像の一部（又はその一部）だけが閲覧（又は検査）のために必要とされ得る場合など、より選択的な方法で使用され得る。したがって、データセット内のブロブ要素の一部のみが必要とされ、したがって回復（ｒｅｃｏｖｅｒ）される場合がある。ステップ９５６では、識別されたブロブ要素を処理することができる。これは、これらのブロブ要素のフィールドを評価し、その値（データ）がどこに保持されているか（例えば、データセット内又はデータオブジェクト内に直接保持されているか）を判断することを含む。たとえば、値がＮＵＬＬに設定されている場合、ＵＲＩ及び／又はオフセットテーブルを使用するなどして、実際の値の場所を決定することができる。ステップ９５８では、データセットとは別に維持されている識別されたブロブ要素の値を、取得する。この取得は、ＵＲＩ及びオフセットテーブルを使用して行うことができる。ステップ９６０では、必要な復号化及び圧縮解除（ｒｅｑｕｉｒｅｄ ｄｅｃｏｄｉｎｇ ａｎｄ ｄｅｃｏｍｐｒｅｓｓｉｏｎ）を適用する。ステップ９６２では、データセット又はその一部の値（データ）に基づいて撮像データを生成（再構成）することができる。

本開示に従った例示的な方法は、医療データ（例えば、医療撮像データを含む）を記憶及び管理するために、プロセッサによって、１つ以上の医療データ記憶及び管理ベースのプロセスを適用することを含む。医療データ記憶及び管理ベースのプロセスは、少なくとも分離プロセス及び回復プロセスを含む。このプロセスは、少なくとも分離プロセス及び回復プロセスを含む。分離プロセスは、医療データセット内の１つ又は複数のブロブデータ要素を識別する工程と、識別された１つ又は複数のブロブデータ要素のデータを対応する分離されたデータオブジェクトに移動する工程と、識別された１つ又は複数のブロブデータ要素のデータの移動を示すためのデータ、及び識別された１つ又は複数のブロブデータ要素の移動されたデータの位置を追跡するためのデータを生成する工程とを含む、回復プロセスは、分離された医療データセット内の１つ又は複数の除去されたブロブデータ要素を識別する工程であって、識別された１つ又は複数の除去されたブロブデータ要素のデータは、対応する１つ又は複数の分離されたデータオブジェクトに移動される、前記工程と、識別された１つ又は複数の除去されたブロブデータ要素の各除去されたブロブデータ要素について、分離された医療データセットに関連付けられた対応する分離データに基づいて、対応する分離されたデータオブジェクトの位置を決定する工程と、決定された位置に基づいて、除去されたブロブデータ要素のデータを検索する工程とを備える。医療データセットは、医療撮像操作中に得られた医療撮像データに基づいて構成され、及び／又は生成され得る。

例示的な実施態様では、分離プロセスは、移動したデータを追跡するためのデータロケータ要素を生成する工程をさらに含み、データロケータ要素は、識別された１つ又は複数のブロブデータ要素の各々を追跡するためのマッピングデータと、対応する移動したデータの位置を特定するための位置情報とを含む。

例示的な実施態様では、分離プロセスはさらに、識別された１つ又は複数のブロブデータ要素の各々を更新する工程を含み、更新は、識別された１つ又は複数のブロブデータ要素のデータが移動されたことを示すために少なくとも１つのフィールドを修正することを含む。

一実施例では、分離プロセスは、医療データセット、分離プロセス、及び対応する分離されたデータオブジェクトに関連する情報を含む共通メタデータブロックを生成し、入力する工程をさらに含む。

一実施例では、分離プロセスは、分離されたデータオブジェクトのストレージを追跡するためのオフセットテーブルを生成し、入力する工程をさらに含む。

例示的な実施形態では、分離プロセスは、分離されたデータオブジェクトの少なくとも一部の移動されたデータを異なる記憶場所に記憶することをさらに含み、異なる記憶場所はローカル記憶場所とリモート記憶場所の一方または両方を含む。

一実施例では、医療データセットは、ＤＩＣＯＭ（ＤｉｇｉｔａｌＩｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）ベースのデータセット又はヘルスケアエンタープライズ（ＩＨＥ）患者ケアデバイス（ＰＣＤ）デバイスエンタープライズ通信（ＤＥＣ）ベースのデータセットとを含む。

本開示に従った例示的な非一過性のコンピュータ可読媒体は、少なくとも１つのコード部を有するコンピュータプログラムを含む。少なくとも１つのコード部は、少なくとも１つのプロセッサを含む機械によって実行可能であり、該機械に、医療データ（例えば、医療撮像データ）を保存および管理するための１つ以上のステップを実行させる。保存および管理するための１つ以上のステップは、少なくとも分離プロセスと回復プロセスプロセスとを含む。分離プロセスは、医療データセット内の１つ又は複数のブロブデータ要素を識別する工程と、識別された１つ又は複数のブロブデータ要素のデータを対応する分離されたデータオブジェクトに移動する工程と、識別された１つ又は複数のブロブデータ要素のデータの移動を示すためのデータ、及び識別された１つ又は複数のブロブデータ要素の移動されたデータの位置を追跡するためのデータを生成する工程とを含む。回復プロセスは、分離された医療データセット内の１つ又は複数の除去されたブロブデータ要素を識別する工程であって、識別された１つ又は複数の除去されたブロブデータ要素のデータは、対応する１つ又は複数の分離されたデータオブジェクトに移動される、前記工程と、識別された１つ又は複数の除去されたブロブデータ要素の各除去されたブロブデータ要素について、分離された医療データセットに関連付けられた対応する分離データに基づいて、対応する分離されたデータオブジェクトの位置を決定する工程と、決定された位置に基づいて、除去されたブロブデータ要素のデータを検索する工程とを備える。医療データセットは、医療撮像操作中に得られた医療撮像データに基づいて構成され、及び／又は生成され得る。

このデータロケータ要素は、識別された１つ又は複数のブロブデータ要素の各々を追跡するためのマッピングデータと、対応する移動データの位置を特定するための位置情報とを含む。

例示的な実施態様では、分離プロセスは、識別された１つ又は複数のブロブデータ要素の各々をさらに更新し、更新は、識別された１つ又は複数のブロブデータ要素のデータが移動されたことを示すために、少なくとも１つのフィールドを修正する工程を含む。

一実施例では、分離プロセスは、医療データセット、分離プロセス、及び対応する分離されたデータオブジェクトに関連する情報を含む共通メタデータブロックを生成し、入力する工程をさらに含む。

一実施例では、分離プロセスは、分離されたデータオブジェクトのストレージを追跡するためのオフセットテーブルを生成し、入力する工程をさらに含む。

一実施例では、分離プロセスは、分離されたデータオブジェクトの少なくとも一部の移動データを異なる記憶場所に記憶する工程をさらに含み、異なる記憶場所は、ローカル記憶場所とリモート記憶場所の一方又は両方を含む。

一実施例では、医療データセットは、ＤＩＣＯＭ（ＤｉｇｉｔａｌＩｍａｇｉｎｇａｎｄＣｏｍｍｕｎｉｃａｔｉｏｎｓｉｎＭｅｄｉｃｉｎｅ）ベースのデータセット又はヘルスケアエンタープライズ（ＩＨＥ）患者ケアデバイス（ＰＣＤ）デバイスエンタープライズコミュニケーション（ＤＥＣ）ベースのデータセットを含む。

本開示に従った例示的なシステムは、医療データ（例えば、医療撮像データを含む）を格納し管理する。システムは、１つまたは複数の医療データの保管および管理に基づくプロセスを適用するように構成された少なくとも１つのプロセッサを備える。医療データの保管および管理に基づくプロセスは少なくとも分離プロセスと回復プロセスとを含む。分離プロセスは、医療データセット内の１つ又は複数のブロブデータ要素を識別する工程と、識別された１つ又は複数のブロブデータ要素のデータを対応する分離されたデータオブジェクトに移動する工程と、識別された１つ又は複数のブロブデータ要素のデータの移動を示すためのデータ、及び識別された１つ又は複数のブロブデータ要素の移動されたデータの位置を追跡するためのデータを生成する工程とを含む。回復プロセスは、分離された医療データセット内の１つ又は複数の除去されたブロブデータ要素を識別する工程であって、識別された１つ又は複数の除去されたブロブデータ要素のデータは、対応する１つ又は複数の分離されたデータオブジェクトに移動される、前記工程と、識別された１つ又は複数の除去されたブロブデータ要素の各除去されたブロブデータ要素について、分離された医療データセットに関連付けられた対応する分離データに基づいて、対応する分離されたデータオブジェクトの位置を決定する工程と、決定された位置に基づいて、除去されたブロブデータ要素のデータを検索する工程とを備える。医療データセットは、医療撮像操作中に得られた医療撮像データに基づいて構成され、及び／又は生成され得る。

例示的な実施態様では、分離プロセスは、移動したデータを追跡するためのデータロケータ要素を生成する工程をさらに含み、データロケータ要素は、識別された１つ又は複数のブロブデータ要素のそれぞれを追跡するためのマッピングデータと、対応する移動したデータの位置を特定するための位置情報とを含む。

例示的な実施態様では、分離プロセスは、識別された１つ又は複数のブロブデータ要素の各々をさらに更新し、更新は、識別された１つ又は複数のブロブデータ要素のデータが移動されたことを示すために、少なくとも１つのフィールドを修正する工程を含む。

一実施例では、分離プロセスは、医療データセット、分離プロセス、及び対応する分離されたデータオブジェクトに関連する情報を含む共通メタデータブロックを生成し、入力する工程をさらに含む。

一実施例では、分離プロセスはさらに、分離されたデータオブジェクトのストレージを追跡するためのオフセットテーブルを生成し、入力する工程を含む。

一実施例では、分離プロセスは、分離されたデータオブジェクトの少なくとも一部の移動データを異なる記憶場所に記憶する工程をさらに含み、異なる記憶場所は、ローカル記憶場所とリモート記憶場所の一方又は両方を含む。

本明細書で使用する場合、「回路：ｃｉｒｃｕｉｔｓ」及び「回路構成：ｃｉｒｃｕｉｔｒｙ」という用語は、物理的な電子部品（例えば、ハードウェア）、及びハードウェアを構成し、ハードウェアによって実行され、又は他の方法でハードウェアに関連する可能性のある任意のソフトウェア及び／又はファームウェア（「コード：ｃｏｄｅ」）を指す。本明細書で使用されるように、例えば、特定のプロセッサ及びメモリは、第１の１つ又は複数のコード行を実行するときに第１の「回路」を構成し、第２の１つ又は複数のコード行を実行するときに第２の「回路」を構成することができる。本明細書で使用する場合、「及び／又は」は、「及び／又は」で結合されたリスト内の項目のいずれか１つ以上を意味する。一例として、「ｘ及び／又はｙ」は、３要素セット｛（ｘ），（ｙ），（ｘ，ｙ）｝の任意の要素を意味する。言い換えれば、”ｘ及び／又はｙ”は”ｘとｙの一方又は両方”を意味する。別の例として、「ｘ、ｙ、及び／又はｚ」とは、７要素集合｛（ｘ）、（ｙ）、（ｚ）、（ｘ、ｙ）、（ｘ、ｚ）、（ｙ、ｚ）、（ｘ、ｙ、ｚ）｝のいずれかの要素を意味する。言い換えれば、”ｘ、ｙ及び／又はｚ”は、”ｘ、ｙ及びｚのうちの１つ以上”を意味する。本明細書で利用されるように、用語「ブロック：ｂｌｏｃｋ」及び「モジュール：ｍｏｄｕｌｅ」は、１つ又は複数の回路によって実行され得る以上の機能を指す。本明細書で使用される場合、「例示的」という用語は、非限定的な例、実例、又は例示としての役割を果たすことを意味する。本明細書で利用されるように、「例えば：ｆｏｒ ｅｘａｍｐｌｅ」及び「例示的には：ｅ．ｇ．」という用語は、１つ又は複数の非限定的な例、実例、又は例示のリストを設定する。本明細書で利用されるように、回路は、機能の実行が（例えば、何らかのユーザ設定可能な設定、工場出荷時のトリムなどによって）無効化されているか、又は有効化されていないかにかかわらず、回路が機能を実行するために必要なハードウェア（及び必要であればコード）を構成するときはいつでも、機能を実行するために「動作可能：ｏｐｅｒａｂｌｅ」である。

本発明の他の実施形態は、非一過性のコンピュータ可読媒体及び／又は記憶媒体、並びに／又は非一過性の機械可読媒体及び／又は記憶媒体であって、機械及び／又はコンピュータによって実行可能な少なくとも１つのコードセクションを有する機械コード及び／又はコンピュータプログラムをその上に記憶させ、それによって機械及び／又はコンピュータに本明細書に記載されるような処理を実行させる、非一過性の機械可読媒体及び／又は記憶媒体を提供することができる。

したがって、本開示は、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせで実現することができる。本発明は、少なくとも１つのコンピューティングシステムにおいて集中型方式で実現されてもよいし、異なる要素が複数の相互接続されたコンピューティングシステムにまたがる分散型方式で実現されてもよい。本明細書に記載された方法を実施するために適合されたあらゆる種類のコンピューティングシステム又は他の装置が適している。ハードウェアとソフトウェアの典型的な組み合わせは、ロードされ実行されると、本明細書に記載された方法を実施するようにコンピューティングシステムを制御するプログラム又は他のコードを有する汎用コンピューティングシステムであってもよい。別の典型的な実装は、特定用途向け集積回路又はチップで構成される場合がある。

本開示に従った様々な実施形態は、本明細書に記載された方法の実施を可能にするすべての機能を含み、コンピュータシステムにロードされるとこれらの方法を実行することができるコンピュータプログラム製品に組み込むこともできる。本明細書におけるコンピュータプログラムとは、情報処理能力を有するシステムに、直接的に、又は以下のいずれかもしくは両方の後に、特定の機能を実行させることを意図した命令の集合を、任意の言語、コード又は表記法で表現したものを意味する。ａ）別の言語、コード又は表記法への変換、ｂ）別の物質的形態での複製。

本発明を特定の実施形態を参照して説明したが、本発明の範囲から逸脱することなく、様々な変更を加えることができ、等価物を代用することができることは、当業者には理解されるであろう。さらに、本発明の範囲から逸脱することなく、特定の状況又は材料を本発明の教示に適合させるために、多くの変更を行うことができる。したがって、本発明は、開示された特定の実施形態に限定されるものではなく、添付の特許請求の範囲に属するすべての実施形態を含むことが意図される。

１００：セットアップ １１０：医療撮像システム １１２：スキャナ装置 １１４：表示／制御ユニット １１６：スクリーン １１８：ユーザ制御部 １２０：コンピューティングシステム ２００：超音波システム ２０２：送信機 ２０４：超音波プローブ ２０６：送信トランスデューサ素子 ２０８：受信トランスデューサ素子 ２１０：送信ビームフォーマ ２１４：送信サブアパーチャビームフォーマ ２１６：受信サブアパーチャビームフォーマ ２１８：受信機 ２２０：受信ビームフォーマ ２２２：Ａ／Ｄ変換器 ２２４：ＲＦプロセッサ ２２６：ＲＦ／ＩＱバッファ ２３０：ユーザ入力モジュール ２４０：信号プロセッサ ２４２：データ管理モジュール ２５０：画像バッファ ２６０：表示システム ２７０：アーカイブ ２８０：トレーニングエンジン ３００：ブロック図 ３１０：ＤＩＣＯＭ ＳＯＰインスタンス ５１０：ＤＩＣＯＭデータセット ５２０：共通のメタデータオブジェクト ５３０：分離されたブロブデータ ６１０：ＩＨＥ ＰＣＤ ＤＥＣデータセット ６２０：共通のメタデータオブジェクト ６３０：分離されたブロブデータ ７００：ＤＩＣＯＭデータセット ８００：ＤＩＣＯＭデータセット

Claims (20)

1. 医療データを保存及び管理する方法であって、
   プロセッサが、１つ又は複数の医療データ保存及び管理に基づくプロセスを適用するステップを含み、
   前記医療データ保存及び管理に基づくプロセスは、少なくとも分離プロセス及び回復プロセスを含み、
   前記分離プロセスは、
   医療データセット内の１つ又は複数のブロブデータ要素を特定するステップと、
   前記特定された１つ又は複数のブロブデータ要素のデータを、対応する分離されたデータオブジェクトに移動するステップと、
   前記特定された１つ又は複数のブロブデータ要素のデータの移動を示し、かつ、前記特定された１つ又は複数のブロブデータ要素の移動したデータの位置を追跡するためのデータを生成するステップと、
   を含み、
   前記回復プロセスは、
   分離された医療データセット内の１つ又は複数の削除されたブロブデータ要素を特定するステップであって、前記特定された１つ又は複数の削除されたブロブデータ要素のデータは、対応する１つ又は複数の分離されたデータオブジェクトに移動される、前記ステップと
   前記識別された１つ又は複数の削除されたブロブデータ要素の各削除されたブロブデータ要素について、
   前記分離された医療データセットに関連する対応する分離データに基づいて、対応する分離データオブジェクトの位置を決定するステップと、
   決定された位置に基づいて、前記削除されたブロブデータ要素のデータを検索するステップと、
   を含む、方法。
2. 前記分離プロセスは、移動したデータを追跡するためのデータロケータ要素を生成するステップをさらに含み、前記データロケータ要素は、識別された１つ以上のブロブデータ要素の各々を追跡するためのマッピングデータと、対応する移動したデータの位置を特定するための位置情報とを含む、請求項１に記載の方法。
3. 前記分離プロセスは、前記識別された１つ又は複数のブロブデータ要素のそれぞれを更新し、前記更新は、前記識別された１つ又は複数のブロブデータ要素のデータが移動したことを示す少なくとも１つのフィールドを修正することを含む、請求項１に記載の方法。
4. 前記分離プロセスが、前記医療データセット、前記分離プロセス、及び前記対応する分離されたデータオブジェクトに関連する情報を含む共通メタデータブロックを生成し、入力するステップをさらに含む、請求項１に記載の方法。
5. 前記分離プロセスが、前記分離されたデータオブジェクトのストレージを追跡するためのオフセットテーブルを生成し、入力するステップをさらに含む、請求項１に記載の方法。
6. 前記分離プロセスは、前記分離されたデータオブジェクトの少なくとも一部の移動データを異なる記憶場所に記憶するステップをさらに含み、前記異なる記憶場所は、ローカル記憶場所とリモート記憶場所の一方又は両方を含む、請求項１に記載の方法。
7. 前記医療データセットが、ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）ベースのデータセット又はＩＨＥ（Ｈｅａｌｔｈｃａｒｅ Ｅｎｔｅｒｐｒｉｓｅ）のＰＣＤ（Ｐａｔｉｅｎｔ Ｃａｒｅ Ｄｅｖｉｃｅ）ＤＥＣ（Ｄｅｖｉｃｅ Ｅｎｔｅｒｐｒｉｓｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）ベースのデータセットを含む、請求項１に記載の方法。
8. 少なくとも１つのコード部を有するコンピュータプログラムを格納する非一過性のコンピュータ可読媒体であって、前記少なくとも１つのコード部は、少なくとも１つのプロセッサを含む機械によって実行可能であり、該機械に、医療データを記憶し管理するための１つ以上のステップを実行させ、
   １つ又は複数の医療データ保存及び管理に基づくプロセスを適用するステップを含み、前記医療データ保存及び管理に基づくプロセスは、少なくとも分離プロセス及び回復プロセスとを含み、
   前記分離プロセスは、
   医療データセット内の１つ又は複数のブロブデータ要素を識別するステップと、
   識別された前記１つ又は複数のブロブデータ要素のデータを、対応する分離されたデータオブジェクトに移動するステップと、
   識別された前記１つ又は複数のブロブデータ要素のデータの移動を示し、識別された前記１つ又は複数のブロブデータ要素の移動したデータの位置を追跡するためのデータを生成するステップと、
   を含み、
   前記回復プロセスは、
   分離された医療データセット内の１つ又は複数の削除されたブロブデータ要素を識別するステップであって、識別された１つ又は複数の削除されたブロブデータ要素のデータは、対応する１つ又は複数の分離されたデータオブジェクトに移動される、前記ステップと、
   前記識別された１つ又は複数の削除されたブロブデータ要素の各削除されたブロブデータ要素について、
   前記分離された医療データセットに関連する対応する分離データに基づいて、対応する分離データオブジェクトの位置を決定するステップと、
   決定された位置に基づいて、前記削除されたブロブデータ要素のデータを検索するステップと、
   を含む、非一過性のコンピュータ可読媒体。
9. 前記分離プロセスは、移動したデータを追跡するためのデータロケータ要素を生成するステップをさらに含み、前記データロケータ要素は、識別された１つ以上のブロブデータ要素の各々を追跡するためのマッピングデータと、対応する移動したデータの位置を特定するための位置情報とを含む、請求項８に記載の非一過性のコンピュータ可読媒体。
10. 前記分離プロセスは、識別された前記１つ以上のブロブデータ要素の各々をさらに更新し、前記更新は、識別された前記１つ以上のブロブデータ要素のデータが移動したことを示すように少なくとも１つのフィールドを修正するステップを含む、請求項８に記載の非一過性のコンピュータ可読媒体。
11. 前記分離プロセスが、前記医療データセット、前記分離プロセス、及び前記対応する分離されたデータオブジェクトに関連する情報を含む共通メタデータブロックを生成し、入力するステップをさらに含む、請求項８に記載の非一過性コンピュータ可読媒体。
12. 前記分離プロセスは、前記分離されたデータオブジェクトの格納を追跡するためのオフセットテーブルを生成し、入力するステップをさらに含む、請求項８に記載の非一過性のコンピュータ可読媒体。
13. 前記分離プロセスは、前記分離されたデータオブジェクトの少なくとも一部の移動データを異なる記憶場所に記憶するステップをさらに含み、前記異なる記憶場所が、ローカル記憶場所とリモート記憶場所の一方又は両方を含む、請求項８に記載の非一過性のコンピュータ可読媒体。
14. 前記医療データセットは、ＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｍｅｄｉｃｉｎｅ）ベースのデータセット又はＩＨＥ（Ｈｅａｌｔｈｃａｒｅ Ｅｎｔｅｒｐｒｉｓｅ）のＰＣＤ（Ｐａｔｉｅｎｔ Ｃａｒｅ Ｄｅｖｉｃｅ）ＤＥＣ（Ｄｅｖｉｃｅ Ｅｎｔｅｒｐｒｉｓｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）ベースのデータセットとを含む、請求項８に記載の非一過性コンピュータ可読媒体。
15. 医療データを保存及び管理するシステムであって、
    １つ又は複数の医療データ保存及び管理に基づくプロセスを適用するように構成された少なくとも１つのプロセッサを含み、前記医療データ保存及び管理に基づくプロセスは、少なくとも分離プロセス及び回復プロセスを含み、
    前記分離プロセスは、
    医療データセット内の１つ又は複数のブロブデータ要素を識別するステップと、
    識別された前記１つ又は複数のブロブデータ要素のデータを、対応する分離されたデータオブジェクトに移動するステップと、
    識別された前記１つ又は複数のブロブデータ要素のデータの移動を示し、識別された前記１つ又は複数のブロブデータ要素の移動したデータの位置を追跡するためのデータを生成するステップと、
    を含み、
    前記回復プロセスは、
    分離された医療データセット内の１つ又は複数の削除されたブロブデータ要素を識別するステップであって、識別された１つ又は複数の削除されたブロブデータ要素のデータは、対応する１つ又は複数の分離されたデータオブジェクトに移動される、前記ステップと、
    識別された前記１つ又は複数の削除されたブロブデータ要素の各削除されたブロブデータ要素について、
    前記分離された医療データセットに関連する対応する分離データに基づいて、対応する分離データオブジェクトの位置を特定するステップと、
    特定された前記位置に基づいて、前記削除されたブロブデータ要素のデータを検索するステップと、を含む、システム。
16. 前記分離プロセスは、移動したデータを追跡するためのデータロケータ要素を生成するステップをさらに含み、前記データロケータ要素は、識別された前記１つ以上のブロブデータ要素の各々を追跡するためのマッピングデータと、対応する移動したデータの位置を特定するための位置情報とを含む、請求項１５に記載のシステム。
17. 前記分離プロセスは、識別された前記１つ又は複数のブロブデータ要素のそれぞれをさらに更新するステップを含み、前記更新は、識別された前記１つ又は複数のブロブデータ要素のデータが移動したことを示す少なくとも１つのフィールドを修正することを含む、請求項１５に記載のシステム。
18. 前記分離プロセスは、前記医療データセット、前記分離プロセス、及び前記対応する分離されたデータオブジェクトに関連する情報を含む共通メタデータブロックを生成し、入力するステップをさらに含む、請求項１５に記載のシステム。
19. 前記分離プロセスは、前記分離されたデータオブジェクトの格納を追跡するためのオフセットテーブルを生成し、入力するステップをさらに含む、請求項１５に記載のシステム。
20. 前記分離プロセスは、前記分離されたデータオブジェクトの少なくとも一部の移動データを異なる記憶場所に記憶するステップをさらに含み、前記異なる記憶場所は、ローカル記憶場所とリモート記憶場所の一方又は両方を含む、請求項１５に記載のシステム。