JP2012178153A - ヘルスケア環境で異種システムからデータを受け取り、マッピングし、構造化する方法およびシステム - Google Patents

Abstract

【課題】異種の臨床システムからのデータを標準フォーマットへ集約するシステムを提供する。
【解決手段】ヘルスケアメッセージ構造の異なるバージョンに関連するデータ入力を受け取る例のコンピュータ実施される方法は、単一のサービスインターフェースを介して第１フォーマットの第１データを受け取ることを含む。第１データの１つまたは複数のフィールドは、ヘルスケアメッセージ構造の異なるバージョンのうちの少なくとも１つによってサポートされない。例の方法は、単一のサービスインターフェースを介して第２フォーマットの第２データを受け取ることをも含む。第２データの１つまたは複数のフィールドは、ヘルスケアメッセージ構造の異なるバージョンのうちの少なくとも１つによってサポートされない。単一のサービスインターフェースは、インターフェースエンドポイントの個数を最小にするために第１データおよび第２データの受け取ることを可能にする。
【選択図】図８

Description

本願は、ヘルスケア環境で異種システムからデータを受け取り、マッピングし、構造化する方法およびシステムに関する。

病院および診療所などのヘルスケア環境は、通常、たとえば、患者既往歴、イメージングデータ、試験結果、診断情報、管理情報、財務情報、および／またはスケジューリング情報などの臨床情報を管理するために情報システム（たとえば、電子医療記録（ＥＭＲ）システム、検査室情報システム、外来患者および入院患者システム、病院情報システム（ＨＩＳ）、放射線情報システム（ＲＩＳ）、ストレージシステム、ピクチャ記録更新システム（ＰＡＣＳ）など）を含む。異なるヘルスケアエンティティは、それに関連して生成され、受信され、送信され、かつ／または処理される異なるフォーマットおよび／または構造のヘルスケア文書を有する場合がある。

Ｎａｙａｋら、「ＸＭＬ ｓｃｈｅｍｅ ｃｌｕｓｔｅｒｉｎｇ ｗｉｔｈ ｓｅｍａｎｔｉｃ ａｎｄ ｈｉｅｒａｒｃｈｉｃａｌ ｓｉｍｉｌａｒｉｔｙ ｍｅａｓｕｒｅｓ」、Ａｂｓｔｒａｃｔ、Ｖｏｌｕｍｅ ２０、ｉｓｓｕｅ ４、２００７年５月

発明の概要は特許請求の範囲に記載のとおりである。要約ならびにある種の例の次の詳細な説明は、添付図面と共に読まれる時によりよく理解される。本明細書で説明される例を示すために、ある種の例を図面に示す。しかし、本開示が、添付図面に示された配置および手段に限定されないことを理解されたい。

例のヘルスケア環境を示すブロック図である。 本明細書で説明される例を実施するのに使用できる例のメッセージ処理システムを示すブロック図である。 複数の既知のサービスインターフェースを介してルーティングされるメッセージを示す図である。 例のユニバーサルスキーマを介してルーティングされるメッセージを示す図である。 本明細書で説明される例に関連して使用できる例のツリー構造を示す図である。 本明細書で説明される例を実施するのに使用できる例のアーキテクチャを示す図である。 本明細書で説明される例に関連して使用できる例のツリー構造を示す図である。 本明細書で説明される例を実施するのに使用できる例の方法を示す流れ図である。 本明細書で説明される例を実施するのに使用できる例の方法を示す流れ図である。 本明細書で説明される例を実施するのに使用できる例の方法を示す流れ図である。 本明細書で説明される例を実施するのに使用できる例の方法を示す流れ図である。 本明細書で説明される例を実施するのに使用できる例の方法を示す流れ図である。 本明細書で説明される例を実施するのに使用できる例の方法を示す流れ図である。 本明細書で説明される例を実施するのに使用できる例の方法を示す流れ図である。 本明細書で説明される例を実施するのに使用できる例の方法を示す流れ図である。 本明細書で説明される例を実施するのに使用できる例の方法を示す流れ図である。 本明細書で説明される例の方法およびシステムのいずれかまたはすべてを実施するために使用でき、かつ／またはプログラムできる例のプロセッサプラットフォームを示す概略図である。

次では、他のコンポーネントの中でもハードウェア上で実行されるファームウェアおよび／またはソフトウェアを含む例の方法、装置、システム、および製造品を開示するが、そのような方法、装置、システム、および／または製造品が、単に例示的であって、限定的と解釈されてはならないことに留意されたい。たとえば、これらのファームウェアコンポーネント、ハードウェアコンポーネント、および／またはソフトウェアコンポーネントのいずれかまたはすべてを、排他的にハードウェアで、排他的にソフトウェアで、排他的にファームウェアで、またはハードウェア、ソフトウェア、および／もしくはファームウェアの任意の組合せで実施することができる。したがって、次では、例の方法、装置、システム、および／または製造品を説明するが、提供される例は、そのような方法、装置、システム、および／または製造品を実施する唯一の形ではない。

添付の請求項のいずれかが、純粋にソフトウェアの実施態様および／または純粋にファームウェアの実施態様を含むと解釈される時には、少なくとも１つの例の要素のうちの少なくとも１つが、これによって、そのソフトウェアおよび／またはファームウェアを格納する、メモリ、ＤＶＤ、ＣＤ、Ｂｌｕ−ｒａｙ、その他などの有形の媒体を含むと明白に定義される。

本明細書で説明される例は、ヘルスケア組織の異種の臨床システムからのデータを、たとえば臨床医によってアクセス可能な１つの中央位置に集中化することを可能にする。したがって、説明される例を使用して、特定の患者のデータにアクセスする臨床医は、その患者の関連データのすべてにアクセスでき、エンドユーザコンポーネントを使用して、そのデータのうちのどれを見たいのかを選択することができる。本明細書で説明される例は、異種臨床システムからの関連するデータを、データベース（たとえば、臨床データリポジトリ）に格納する前に、標準化されたおよび／または構造化されたフォーマットまたはモデルに集約することによって、異種臨床システム（たとえば、既存のアプリケーションおよび製品）のインターオペラビリティを可能にする。さらに、本明細書で説明される例は、データが受け取られた後に、そのデータを、カスタマイズ可能なダッシュボードユーザインターフェースを使用して表示することを可能にする。データは、電子医療記録（ＥＭＲ）、ＩＴソリューションに関連するデータなどを含むことができる。

いくつかの例では、ダッシュボードユーザインターフェースは、受け取られたデータが定義された臨床標準規格と異なる時に臨床医に通知するために警報および／または通知を含むことができる。データが異種臨床システムから受け取られる時に、データを他の臨床システムおよび／または臨床アプリケーションによって使用可能な構造化されたフォーマットまたはモデルに変換し、格納することを可能にするためにマッピングすることによって、データを正規化することができる。データが異種臨床システムから受け取られる時に、たとえばデータを臨床意思決定支援で他の臨床システムおよび／または臨床アプリケーションによって使用可能にすることを可能にするために、データ内の語彙を標準化することができる（たとえば、標準Ｈｅａｌｔｈ Ｌｅｖｅｌ Ｓｅｖｅｎ（ＨＬ７）言語）。本明細書で説明される例のプラットフォームのオープンアーキテクチャのゆえに、説明される例を使用する顧客は、彼ら自身のアプリケーションを作成するためにこれらのプラットフォームを活用し、他の提供されたアプリケーションと一緒にプラットフォームを使用し、かつ／または顧客の特定の好みおよび／もしくは必要に基づいてダッシュボードユーザインターフェースをカスタマイズすることができる。

本明細書で説明する例は、異なってフォーマットされたメッセージに単一のユニバーサルスキーマ内で対処し、異なるデバイスを接続することおよび／または異なる通信を情報システムの間でルーティングすることを可能にする。より具体的には、本明細書で説明する例のシステムおよび方法は、Ｈｅａｌｔｈ Ｌｅｖｅｌ Ｓｅｖｅｎ（ＨＬ７）のＡｄｍｉｔ Ｄｉｓｃｈａｒｇｅ Ｔｒａｎｓｆｅｒ（ＡＤＴ）、Ｏｂｓｅｒｖａｔｉｏｎ Ｒｅｓｕｌｔｓ（ＯＲＵ）、Ｍｅｄｉｃａｌ Ｄｏｃｕｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ（ＭＤＭ）、その他、ＡＤＴ、ＯＲＵ、ＭＤＭ、その他のさまざまな２．ｘ ＨＬ７バージョン、およびトリガ（たとえば、ＡＯ１、ＡＯ２など）などのメッセージ構造の異なるバージョンに関連するフィールドの集約を可能にする。いくつかの例では、例のユニバーサルスキーマ定義は、フィールドがＨＬ７構造のすべてのバージョンにまたがってサポートされるのではない可能性がある場合であっても、フォーマットのいずれかに関連して生成されたフィールドを制限しないことによって、第１のプログラムによって第１のＨＬ７フォーマットで作成されたメッセージを受け取り、第２のプログラムによって第２のＨＬ７フォーマットで作成されたメッセージをも受け取ることができる。いくつかの例では、例のユニバーサルスキーマ定義は、第１のＨＬ７フォーマットまたは第２のＨＬ７フォーマットのいずれかに関連して生成されたのではないフィールドがＨＬ７構造のすべてのバージョンにまたがってサポートされない場合に、それらのフィールドを要求しないものとすることができる。

既知の手法とは異なって、本明細書で説明される例は、異なるＨＬ７メッセージタイプ（たとえば、ＡＤＴ、ＯＲＵ、ＭＤＭ）のそれぞれのすべてのトリガについて単一のユニバーサルスキーマ定義を提供し、既存システムの異なるＨＬ７メッセージタイプのそれぞれに関連して使用されるインターフェースエンドポイントの数を減らすことができる。したがって、本明細書で説明する例を使用して、そのようなシステムを維持することの時間集約度および労働集約度を減らし、単純化することができる。

異なるフォーマットを有するメッセージが、ユニバーサルスキーマによって受け取られた後に、同一のまたは類似するビジネスロジックを使用して、受け取られたメッセージタイプに基づいて、メッセージをフォーマットし、編成し、かつ／または格納することができる。たとえば、受け取られたメッセージおよび／または内容に基づいて、例のシステムは、メッセージ内の異なるタイプのデータを検索し、１つまたは複数のオブジェクトの１つまたは複数のフィールドを含む構成ファイル（１つまたは複数）をセットアップすることができる。作成された構成ファイルを、受け取られたメッセージのトリガに関連付けることができ、オブジェクトを、作成された後に相関させることができる。その後、識別されたデータを、構造化されたフォーマットで格納されるフィールドおよび／またはオブジェクトに伝えることができる。フィールドおよび／またはデータに投入されるデータを識別するために着信メッセージを検索することによって、着信メッセージを、望まれるデータについて効果的にフィルタリングすることができる。いくつかの例では、顧客は、受け取られたメッセージおよび／または内容をどのように処理するのかをカスタマイズすることができる。たとえば、顧客は、特定のメッセージタイプが受け取られる場合に行われるアクションおよび／または作成されるオブジェクトを変更することができる。たとえば、ストレージデータ構造を、ランタイムに定義されるスキーマを使用してランタイムに動的に定義することができる。たとえば、ビジネスロジックをランタイムに動的に定義することができる。

異なるフォーマットを有するメッセージがユニバーサルスキーマによって受け取られた後に、受け取られたメッセージタイプと構成ユーザインターフェースのセッティングとに基づいて、メッセージを、異なるオブジェクトの異なるフィールドにマッピングし、データ構造に格納することができる。いくつかの例では、受け取られたデータを、受け取られたメッセージのフォーマットにかかわりなく、同一のまたは類似するビジネスロジックを使用して複数のオブジェクト内の異なるフィールドにマッピングすることができる。

本明細書で説明される例を使用する顧客は、構成ユーザインターフェースを使用して、システムおよび方法を顧客の特定の好みにあわせて調整するために、メッセージ、オブジェクト状態などが、メッセージが処理される時、特定のオブジェクトが操作される時などにどのように振る舞い、操作され、または変更されるのかを構成し、触れ、かつ／または規定することができる。本明細書で説明される例を、第１の顧客について、メッセージがデータを保存するための新しいオブジェクトを作成するように調整することができる。本明細書で説明される例を、同一のメッセージを受け取る第２の顧客について、メッセージ内のデータから更新される特定のオブジェクトが使用可能になるように調整することができる。いくつかの例では、顧客は、特定のメッセージを受け取る時に特定のオブジェクトが作成されるようにシステムを構成することができる。それに加えてまたはその代わりに、顧客は、特定のメッセージを受け取る時の特定のオブジェクトの作成を無視するようにシステムを構成することができる。

たとえば、構成されるストレージデータ構造に基づいて、システムは、メッセージを、病院の健康情報システム（ＨＩＳ）からのものであり、Ａ０１メッセージタイプであるものとして識別することができる。さらに、システムは、そのメッセージに含まれるデータをオブジェクトフィールドにマッピングし、そのメッセージが処理される時に、関連するオブジェクト状態（たとえば、新規、アクティブ、インアクティブ）を変更することができる。いくつかの例では、少なくともいくつかのメッセージは、オブジェクトが特定の状態になるための前提条件を有することができる。患者入院（たとえば、Ａ０１）メッセージタイプの患者オブジェクトとして識別された着信メッセージについて、例のシステムおよび方法は、患者がシステムに以前に登録されているので、「Ｎｅｗ（新規）」および／または「Ａｃｔｉｖｅ（アクティブ）」であるものとして前提条件状態を有することができる。患者入院メッセージタイプが処理されつつある時に、患者オブジェクト状態は、その患者がヘルスケア施設でアクティブ患者であることを示す「Ａｃｔｉｖｅ」に変更される。また、患者入院メッセージタイプが処理されつつある時に、患者オブジェクトを、患者ＩＤ、エンティティ、相関、マッピング、その他などの患者入院タイプに含まれる情報を用いて更新することができる。患者登録（たとえば、Ａ０４）メッセージタイプとして識別される着信メッセージについて、例のシステムおよび方法は、患者がまだシステム内で患者として登録されていないので、患者オブジェクトが当初に存在しないと期待することができる。患者登録メッセージタイプが処理されつつある時に、患者オブジェクトが作成され、状態は、「Ａｃｔｉｖｅ」であるものとしてセットされる。

本明細書で説明される例は、ランタイムに展開される１つまたは複数のスクリプトを使用して、異なるフォーマットで受け取られる関連する検査室データおよび／または観察データを１つの構造化されたフォーマット（たとえば、Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）に再構成し、かつ／または集約することができる。たとえば、第１フォーマットで受け取られた第１データを解析し、構造化されたフォーマット（たとえば、親子関係を有するツリー構造）でフォーマットすることができ、第２フォーマットで受け取られ、第１データに関連する第２データを、解析し、構造化されたフォーマットでフォーマットし、第１データと共に集約することができる。データの解析は、関連するデータを識別し、かつ／または抽出し、将来の使用のために保存することを可能にする。いくつかの例では、観察は、実際のデータ、コメント、基準範囲などを含む異なるオブジェクト内のデータを含むことができる。本明細書で説明される例を使用して、観察に関連するデータを、解析し、意思決定支援で、および／または患者データを収集するために使用可能な１つの構造化されたオブジェクトに集約することができる。いくつかの例では、受け取られた臨床データに応じて、警報を、意思決定支援を助けるために生成し、データ構造化の親レベルおよび／または子レベルでヘッダに追加することができる。いくつかの例では、オブジェクト内に格納されるデータは、十分に検証されたコードおよび／または構造を含むことができる。

いくつかの例では、プロセスフローをインターセプトし、受け取られたデータに基づく構造化されたフォーマットへのデータの集約、変更、解析、フィルタリングなどを行うスクリプトを動的に導入するフックをプロセスフロー内で公表することができる。スクリプトを、プロセスフロー内の１つまたは複数のステージで実行されるカスタマイズ可能なプラグインとすることができる。ステージの１つを、データが内部データ構造に変換されかつ／またはマッピングされる前（たとえば、マッピング前スクリプト）とすることができ、かつ／あるいは、ステージの１つを、データが内部データ構造に変換されかつ／またはマッピングされた後（マッピング後スクリプト）とすることができる。データが内部データ構造に変換された後にプロセスフローをインターセプトできるスクリプトを、アペンダ（ａｐｐｅｎｄｅｒ）プラグインスクリプトとすることができる。いくつかの例では、アペンダプラグインスクリプトは、同一の観察に関連する着信メッセージからのすべての観察値（たとえば、それぞれが同一のキーコードおよび／または観察ＩＤを有する）を、システムによって永続される１つのオブジェクトとして格納できる１つのストリングにアペンドすることができる。そのような手法は、観察値がその末尾にキャリッジリターンを含む時に有利である可能性がある。アペンダを使用することによって、キャリッジリターンを観察値からフィルタリングすることができる。その後、キャリッジリターンを伴わない観察値を、格納のために集約し、かつ／またはアペンドすることができる。他の例では、微生物標本観察データを、異なってフォーマットされたセグメントで受け取ることができる。例のスクリプトを使用することによって、セグメントを、集約し、適用可能である場合にテキスト形式で埋め込まれたデータを分離することによって関連情報を抽出するために解析し、構造化されたフォーマットで格納することができる。いくつかの例では、関連するセグメントのデータは集約されるが、関連しないセグメントは集約されないものとすることができる。

スクリプトを、ユーザによって選択できるツリー構造内に表示することができる。選択されたスクリプトを、システムをシャットダウンする必要なしに、受け取られたメッセージタイプに基づいて実行することができる。たとえば、スクリプトを顧客に提供することができ、かつ／または、スクリプトを顧客が記述しかつ／もしくは変更することができる。

いくつかの例では、データを、システムをシャットダウンすることなく展開可能な例のカスタマイズ可能なデータ構造モデリングツールを使用して、受け取られたデータおよび／または内容に基づいて動的にモデリングすることができる。例のツールは、さまざまなシステムから受け取られた患者検査室データおよび／または患者観察データを集約し、このデータをカスタマイズ可能なおよび／または動的に構成可能なデータ構造に格納することができる。たとえば、本明細書で説明される例は、観察に関係し、異なるソースから受け取られるデータ（たとえば、異なるセグメント）を取り込み、解析し、かつ／または十分に検証できるコードおよび／もしくは構造を含む構造化された形での格納のための観察の単位に集約することができる。いくつかの例では、受け取られたデータに基づく意思決定支援を助ける警報を、セットアップすることができる。データを、格納された後に、臨床意思決定支援を助けるために取り出し、かつ／または使用することができる。異なるソースからのデータを構造化されたフォーマットで編成できるので、本明細書で説明される例は、国立保健局（ｎａｔｉｏｎａｌ ｈｅａｌｔｈ ｄｅｐａｒｔｍｅｎｔ）による国の健康統計に達するための特定の患者のステージ３メジャー（ｓｔａｇｅ ３ ｍｅａｓｕｒｅｓ）の意味のある使用を助けることができる。

いくつかの例では、インメモリのおよび／または永続的なデータストレージが、特定のデータ構造を作成するためにルックアップを検索することによって動的に構成されるデータ構造に基づいて作成され、永続することができる。いくつかの例では、インメモリのおよび／または永続的なデータストレージを、オブジェクトを作成するためのイベントで指定されたデータと受け取られたデータの内容とに基づいて作成することができる。イベントデータスキーマとデータモデルとの間のマッピングを、顧客の好みおよび／または必要に基づいてカスタマイズ可能とすることができる。

いくつかの例では、受け取られた入力メッセージに基づいて、例のシステムは、そのメッセージに関連するサービス識別子コードを識別し、識別されたコードについて指定されたモデルがあるかどうかを判定する。指定されたモデルがある場合には、例のシステムは、メッセージ内容からモデルを抽出し、そのモデルをメモリ内にパネルとして格納する。いくつかの例では、受け取られた入力メッセージに基づいて、例のシステムは、観察識別子コードを識別し、識別されたコードについて指定されたモデルがあるかどうかを判定する。指定されたモデルがある場合には、例のシステムは、メッセージ内容からモデルを抽出し、そのモデルをメモリ内に観察として格納する。

図１は、ヘルスケア情報を受け取り、処理し、かつ／または構造化するために本明細書で説明される例の方法、装置、システム、および／または製造品を実施できる、例のヘルスケア環境１００のブロック図である。例のヘルスケア環境１００は、病院１０２内で動作し、かつ／または病院１０２に関連する複数のエンティティを有する病院１０２を含む。病院１０２は、ピクチャ記録更新システム（ＰＡＣＳ）１０４、検査室情報システム１０６、心臓病科１０８、放射線情報システム（ＲＩＳ）１１０、および腫瘍科１１２を含む。しかし、病院１０２は、ヘルスケア情報システム（ＨＩＳ）を含むなど、図示されたものより多数の、より少数の、および／または異なるエンティティを含むことができる。

心臓病科１０８は、心臓病学関連の医療従業者、スタッフ、ならびに心臓病学の実践および治療をサポートするデバイスおよび／またはシステムを含む。心臓病科１０８は、ヘルスケア文書が生成され、送信され、受信され、かつ／または処理される特定のフォーマットおよび／または構造を有する場合がある。腫瘍科１１２は、癌関連の医療従業者、スタッフ、ならびに腫瘍学の実践および治療をサポートするデバイスおよび／またはシステムを含む。腫瘍科１１２は、心臓病科１０８に関連して使用されるフォーマットおよび／または構造とは異なる、ヘルスケア文書が生成され、送信され、受信され、かつ／または処理される特定のフォーマットおよび／または構造を有する場合がある。いくつかの例では、心臓病科１０８によって生成されるＡｄｍｉｔ Ｄｉｓｃｈａｒｇｅ Ｔｒａｎｓｆｅｒ（ＡＤＴ）メッセージが、第１フォーマットであり、腫瘍科１１２によって生成される類似するＡＤＴメッセージが、第２フォーマットである場合がある。いくつかの例では、心臓病科１０８によって生成されるＯｂｓｅｒｖａｔｉｏｎ Ｒｅｓｕｌｔｓ Ｍｅｓｓａｇｅ（ＯＲＵ）メッセージが、第１フォーマットであり、腫瘍科１１２によって生成される類似するＯＲＵメッセージが、第２フォーマットである場合がある。そのような相違が、ＰＡＣＳ １０４、検査室情報システム１０６、ＲＩＳ １１０、その他のいずれの間にも存在する可能性がある。

ＰＡＣＳ １０４は、たとえばデータベースまたはレジストリ内のディジタルイメージなどの医療イメージ（たとえば、Ｘ線、スキャン、３次元レンダリングなど）を格納する。イメージは、患者の医療イメージングの後に医療従業者（たとえば、イメージング技師、内科医、放射線科医）によってＰＡＣＳ １０４に格納される。それに加えてまたはその代わりに、イメージを、格納のために医療イメージングデバイスからＰＡＣＳ １０４に自動的に送信することができる。

ＲＩＳ １１０は、たとえば放射線医学レポート、メッセージ、警告、警報、患者スケジューリング情報、患者人口統計データ、患者追跡情報、ならびに／または内科医および患者状況モニタなどの放射線医学実践に関係するデータを格納する。さらに、ＲＩＳ １１０は、検査指示入力（たとえば、患者のＸ線の指示）、イメージ追跡、およびフィルム追跡（たとえば、フィルムを調査した１人または複数の人の身元の追跡）を可能にする。

検査室情報システム１０６は、検査室結果、試験スケジューリング情報、対応する従業者（１人または複数）、および／または対応するヘルスケア施設の１つもしくは複数の検査室の動作（１つまたは複数）に関係する他の情報などの臨床情報を格納する。情報の例のタイプが、上で、病院１０２のある種の要素に格納されるものとして説明されるが、異なるタイプのヘルスケアデータを、エンティティ１０４〜１１２のうちの１つまたは複数に格納することができる。さらに、エンティティ１０４〜１１２に格納される情報が、オーバーラップし、かつ／またはエンティティ１０４〜１１２のうちの１つまたは複数に組み合わされる場合がある。いくつかの例では、図１のエンティティ１０４〜１１２は、電子医療記録（ＥＭＲ）システム１１４と相互作用することができる。ＥＭＲ １１４は、たとえば病院１０２およびそのエンティティ１０４〜１１２に関連するヘルスケア記録の電子コピーを格納する。

例のヘルスケア環境１００は、外来診療所１１６をも含む。２つのヘルスケア事業（たとえば、病院１０２、外来診療所１１６）が、図１のヘルスケア環境に図示されているが、ヘルスケア環境１００は、任意の個数（１、２、３など）の類似するまたは異なるヘルスケア事業を含むことができる。例の外来診療所１１６は、例の病院１０２の対応するエンティティに似て動作する、検査室情報システム１１８およびＰＡＣＳ １２０を含む。例の外来診療所１１６の検査室情報システム１１８およびＰＡＣＳ １２０は、病院１０２とは異なってヘルスケア文書を生成し、受信し、送信し、かつ／または処理することができる。したがって、ヘルスケア文書のフォーマッティングおよび／または構造化の相違が、一般に、１つのヘルスケア事業のエンティティの間および／またはヘルスケア事業の間に存在する可能性がある。

病院１０２および外来診療所１１６は、ネットワーク１２４を介してＥＣＩＳ（Ｅｎｔｅｒｐｒｉｓｅ Ｃｌｉｎｉｃａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ）（たとえば、Ｑｕａｌｉｂｒｉａ（登録商標））１２２と通信する。ネットワーク１２４は、たとえば、私有ネットワークまたはインターネットなどの無線または有線の広域ネットワーク（ＷＡＮ）、イントラネット、仮想プライベートネットワーク、有線または無線のローカルエリアネットワークなどによって実施することができる。より一般的には、本明細書で説明される結合（１つまたは複数）のすべてを、ネットワークを介するものとすることができる。それに加えてまたはその代わりに、病院１０２および／または外来診療所１１６は、直接のまたは専用の伝送媒体１２６および１２８を介してＥＣＩＳ １２２と通信することができる。

ＥＣＩＳ １２２は、ヘルスケア事業（たとえば、病院１０２、外来診療所１１６など）のシステム、デバイス、アプリケーションなどによって実施されるヘルスケア情報処理をサポートすることができる。ＥＣＩＳ １２２は、異なるヘルスケア事業エンティティ（たとえば、エンティティ１０４〜１１４、１１８、１２０）に関連して生成されたメッセージ、内容、セグメントなどが、異なるフォーマット、構造、用語法、プロトコル、ポリシなどを含む場合であっても、それらのメッセージ、内容、セグメントなどを処理することができる。

いくつかの例では、ＥＣＩＳ １２２の処理は、臨床意思決定支援を助けるためにヘルスケア事業エンティティのすべてによって使用できる標準化されたおよび／または構造化されたフォーマットおよび／またはモデルにデータを集約することによって、ヘルスケア事業エンティティのインターオペラビリティを可能にする。いくつかの例では、ＥＣＩＳ １２２および、より具体的にはＥＣＩＳ １２２の例のメッセージ処理システム１３０は、すべてのメッセージ変形形態（たとえば、異なるＨＬ７メッセージ）に対処することによって、ユニバーサルスキーマを介して異なるメッセージタイプ（たとえば、ＡＤＴ：０１、ＡＤＴ：０２など）を含むデータを受信することができる。それに加えてまたはその代わりに、メッセージ処理システム１３０は、ランタイムに展開される１つまたは複数のスクリプトを使用して、着信データのプロセスフローをインターセプトすることができる。スクリプトは、異なってフォーマットされたデータをＥＣＩＳ １２２および／またはヘルスケア事業エンティティによってより使用可能な１つの構造化されたフォーマット（たとえば、ツリー構造）に再構成し、解析し、変更し、かつ／または集約することができる。それに加えてまたはその代わりに、メッセージ処理システム１３０は、受け取られるメッセージのフォーマットにかかわりなく、同一のまたは類似するビジネスロジックを使用して、着信メッセージの諸部分を異なるオブジェクトの異なるフィールドにマッピングすることができる。それに加えてまたはその代わりに、メッセージ処理システム１３０は、受け取られたデータをカスタマイズ可能なおよび／または動的に構成可能なデータ構造に動的にモデリングすることができる。メッセージ処理システム１３０を使用して構造化されたデータを、データベースまたはデータストア１３２に格納することができる。いくつかの例では、データベース１３２を、臨床データリポジトリとすることができる。

図２は、図１の例のメッセージ処理システム１３０および／またはデータベース１３２を実施するのに使用できる例のメッセージ処理システム２００のブロック図である。この例では、メッセージ処理システム１３０は、インターフェース２０２、識別子２０４、ユニバーサルスキーマ２０６、プリマッパ（ｐｒｅ−ｍａｐｐｅｒ）２０８、プロセッサ２１０、ポストマッパ（ｐｏｓｔ−ｍａｐｐｅｒ）２１２、およびデータストア２１４を含む。図１のメッセージ処理システム１３０およびデータベース１３２を実施する例の形が図１に示されたが、図２に示された要素、プロセス、および／またはデバイスのうちの１つまたは複数を、任意の他の形で組み合わせ、分割し、再配置し、省略し、除去し、かつ／または実施することができる。さらに、インターフェース２０２、識別子２０４、ユニバーサルスキーマ２０６、プリマッパ２０８、プロセッサ２１０、ポストマッパ２１２、およびデータストア２１４、ならびに／またはより一般的に、図２の例のメッセージ処理システム２００を、ハードウェア、ソフトウェア、ファームウェア、ならびに／あるいはハードウェア、ソフトウェア、および／またはファームウェアの任意の組合せで実施することができる。したがって、たとえば、インターフェース２０２、識別子２０４、ユニバーサルスキーマ２０６、プリマッパ２０８、プロセッサ２１０、ポストマッパ２１２、およびデータストア２１４、ならびに／またはより一般的に、図２の例のメッセージ処理システム２００のいずれをも、１つまたは複数の回路、プログラム可能プロセッサ（１つまたは複数）、特定用途向け集積回路（ＡＳＩＣ）（１つまたは複数）、プログラマブル論理デバイス（ＰＬＤ）（１つまたは複数）、および／またはフィールドプログラマブル論理デバイス（ＦＰＬＤ）（１つまたは複数）などで実施することができる。添付の請求項のいずれかが、純粋にソフトウェアの実施態様および／または純粋にハードウェアの実施態様を包含すると解釈される時に、インターフェース２０２、識別子２０４、ユニバーサルスキーマ２０６、プリマッパ２０８、プロセッサ２１０、ポストマッパ２１２、およびデータストア２１４、ならびに／またはより一般的に、図２の例のメッセージ処理システム２００のうちの少なくとも１つが、これによって、ソフトウェアおよび／またはファームウェアを格納する、メモリ、ＤＶＤ、ＣＤその他などの有形の媒体を含むと特に定義される。さらに、図２の例のメッセージ処理システム２００は、図２に示されたものに加えてまたはその代わりに１つまたは複数の要素、プロセス、および／またはデバイスを含むことができ、かつ／あるいは図示の要素、プロセス、およびデバイスのいずれかまたはすべてを複数含むことができる。

一般に、例のメッセージ処理システム２００は、ヘルスケア組織の異種臨床システムからのデータを臨床医、他のアプリケーション、プログラムなどによって使用可能な標準フォーマットで１つの位置で集中化し、かつ／またはフォーマットすることを可能にする。いくつかの例では、メッセージ処理システム２００は、これらの異種臨床システムから受け取られたメッセージのフォーマットおよび／または内容を解析し、フィルタリングし、標準化されたおよび／または構造化されたフォーマットおよび／またはモデルに変換し、集約し、アペンドし、構成し、かつ／または変更することができる。この構造化されたデータを、たとえばインターフェース２０２を使用して、表示し、かつ／または臨床医によって使用することができる。

いくつかの例では、メッセージ処理システム２００が、たとえばユニバーサルスキーマ２０６を介してメッセージを受け取る時に、識別子２０４は、メッセージタイプ、メッセージのフォーマッティング、および／またはメッセージ内に含まれる内容を識別することができる。識別子２０４は、第１フォーマッティング、第２フォーマッティングなどであるＡＤＴメッセージタイプとしてメッセージを識別することができる。識別子２０４は、第１タイプの内容、第２タイプの内容などを含むものとしてＡＤＴメッセージ内に含まれる内容を識別することができる。識別子２０４は、第１フォーマッティング、第２フォーマッティングなどであるＯＲＵメッセージタイプとしてメッセージを識別することができる。識別子２０４は、第１タイプの内容、第２タイプの内容などを識別するものとしてＯＲＵメッセージ内に含まれる内容を識別することができる。

いくつかの例では、プロセッサ２１０を使用してメッセージを処理し、マッピングし、かつ／または動的にモデリングする前に、プリマッパ２０８が、着信プロセスフローに１つまたは複数のスクリプトを適用することができる。スクリプトは、異なるフォーマットで受け取られたデータをプロセッサ２１０によってより使用可能な１つの構造化されたフォーマットにフィルタリングし、解析し、変更し、集約し、その他を行うことができる。たとえば、メッセージ処理システム２００が、異なるフォーマットの複数のセグメントからなり、同一の観察に関係するメッセージを受け取る場合がある。プリマッパ２０８を使用することによって、複数のセグメントを、メッセージ処理システム２００内で永続される単一のオブジェクトに集約することができる。この単一のオブジェクトを、親子関係を有するツリー構造にフォーマットすることができ、ここで、親は、より一般的な内容を含むことができ、かつ／または子は、より詳細な内容および／もしくはデータを含むことができる。たとえば、微生物学検査結果に関係する複数のセグメントを受け取る場合がある。微生物学検査結果は、定性的データ、定量的データ、および／またはその中に埋め込まれたコメントを有する微生物学標本およびスライド検査を含む場合がある。プリマッパ２０８を使用することによって、微生物学検査結果のデータを、ツリー構造にフォーマットすることができ、標本データがその標本データに関連するノードに格納され、マイクロスライド検査データが、そのマイクロスライド検査データに関連するノードに格納され、定性的データ、定量的データ、および／またはコメントが、その中のそれぞれのノードに格納されるようになる。構造化されたデータを、たとえば後の使用のためにデータストア２１４に保存することができる。

メッセージがプリマッパ２０８でフォーマットされた後に、ならびに／あるいはこのフォーマッティングが適用可能ではないおよび／または必要ではない場合に、メッセージを、プロセッサ２１０を使用して処理することができる。プロセッサ２１０は、システムをシャットダウンする必要なしに、データを動的にモデリングし、かつ／または構成することができる。プロセッサ２１０は、さまざまなシステムから受け取った患者データ（たとえば、ＡＤＴデータ、検査室データ、観察データなど）および／または内容をマッピングし、解析し、フィルタリングし、変更し、かつ／または集約し、その他を行うことができ、このデータをデータストア２１４でカスタマイズ可能なおよび／または動的に構成可能なデータ構造内に格納することができる。このデータ構造を、たとえばインターフェース２０２を使用して顧客および／またはプロバイダによってカスタマイズすることができる。

いくつかの例では、プロセッサ２１０は、マッピングによってデータおよび／またはメッセージの内容を正規化することができる。マッピングを、たとえばインターフェース２０２を使用して、顧客の好みおよび／または必要に基づいてカスタマイズ可能とすることができる。次に、この正規化されたデータを臨床意思決定支援で使用可能な構造化されたフォーマット、モデル、パネルなどに変換し、格納することができる。たとえば、病院のヘルスケア情報システム（ＨＩＳ）からの、Ａ０１メッセージタイプであるものとしてメッセージを識別する識別子２０４に基づいて、プロセッサ２１０は、メッセージからのデータをＡ０１メッセージタイプに関連する１つまたは複数のオブジェクトのフィールドにマッピングし、かつ／または抽出することができ、ここで、データを、その後、後の使用のためにデータストア２１４で構造化されたフォーマットで保存することができる。

たとえば、病院の心臓病科からの、観察メッセージであるものとしてメッセージを識別する識別子２０４に基づいて、プロセッサ２１０は、メッセージからのデータを観察メッセージに関連するパネルおよび／またはサブパネル内の１つまたは複数の観察項目にマッピングし、かつ／または抽出することができ、ここで、データを、その後、後の使用のためにデータストア２１４で構造化されたフォーマットで保存することができる。しかし、観察メッセージに関連するパネルがない場合には、データを、たとえば後の使用のために観察項目としてデータストア２１４で構造化されたフォーマットで保存することができる。

たとえば、腫瘍科からの、検査室メッセージであるものとしてメッセージを識別する識別子２０４に基づいて、プロセッサ２１０は、検査室メッセージに関連するモデルを生成するためにメッセージからのデータをマッピングし、かつ／または抽出することができ、ここで、データを、その後、後の使用のためにデータストア２１４で構造化されたフォーマットで保存することができる。いくつかの例では、異なるソースからのおよび／または異なるフォーマットのマッピングされたデータを、十分に検証できるコードおよび／または構造を含む構造化された形での格納のために単一の単位に解析し、かつ／または集約することができる。

プロセッサ２１０を使用してメッセージを処理した後に、ポストマッパ２１２が、プロセスフローに１つまたは複数のスクリプトを適用することができる。スクリプトは、受け取られたデータをフィルタリングし、解析し、変更し、集約することができる。たとえば、末尾にキャリッジリターンを含む観察値を、ポストマッパ２１２を使用してフィルタリングして、キャリッジリターンを除去することができる。次に、フィルタリングされた観察値を、たとえばデータストア２１４での格納のためにアペンドすることができる。

メッセージ処理システム２００は、データストア２１４を含む１つまたは複数の内部メモリおよび／またはデータストアを含むことができる。データストレージは、メッセージ処理システム２００と通信する、任意のさまざまな内部のおよび／または外部のメモリ、ディスク、リモートストレージを含むことができる。いくつかの例では、インターフェース２０２を、グラフィカルユーザインターフェース（ＧＵＩ）として構成することができる。

図３に、複数の既知のサービスインターフェース、サブスキーマ、および／またはスキーマ３０４を介してヘルスケア情報システム３０６にルーティングされる複数のＡＤＴメッセージ構造３０２を示す。複数のサービスインターフェース３０４が使用されているのは、着信ＡＤＴメッセージ（たとえば、Ａ０１、Ａ０２など）が異なってフォーマットされ、かつ／またはそれに関連するより少ない、より多い、および／もしくは異なるフィールドを有する場合があるからである。多数のサービスインターフェース３０４を含めることは、その保守が時間集中的であり労働集中的である多数のインターフェースエンドポイント３０８を生じる。

図４に、例の「ユニバーサル」スキーマまたはユニフォームスキーマ（たとえば、ユニバーサルＸＭＬスキーマ）４０４を介してヘルスケア情報システム４０６にルーティングされる複数のＡＤＴメッセージ構造４０２を示す。いくつかの例では、ユニバーサルスキーマ４０４を使用して、ＨＬ７メッセージ（たとえば、ＡＤＴメッセージ、ＯＲＵメッセージ、ＭＤＭメッセージなど）のすべてのバージョンおよび／またはトリガを処理することができる。いくつかの例では、ユニバーサルスキーマ４０４は、ＨＬ７のさまざまなバージョンに関連するＨＬ７メッセージ構造および／またはフィールドのすべての変形形態に対処する拡張的なメッセージングフレームワークを含む。たとえば、ユニバーサルスキーマ４０４は、すべてのＨＬ７バージョンおよび／またはＨＬ７構造にまたがってサポートされるのではない可能性があるフィールドを制限し、かつ／または要求することをしないことによって、２．ｘ ＨＬ７ ＡＤＴメッセージのさまざまなバージョンに関連するＨＬ７ ＡＤＴメッセージ構造および／またはフィールドのそれぞれのすべてのフィールドを集約することができる。図３の複数のサービスインターフェース３０４ではなくユニバーサルスキーマ４０４を使用することによって、ヘルスケア情報システム４０６でのインターフェースエンドポイント４０８の個数が、大幅に減らされ、これによって、そのようなシステムの保守の時間集約度および労働集約度が減らされる。

図５に、その中でメッセージをマッピングし、ルーティングし、構成し、フォーマットし、構造化し、かつ／または格納できる、親子関係を有する例のツリー構造５００を示す。この例では、ツリー構造５００は、親ノード５０２〜５１０および子ノード５１２〜５１４を含む。しかし、他の例では、ツリー構造５００は、より少数の、より多数の、および／または異なるノードを含むことができる。ノード５０２は、Ａ０１メッセージタイプに関係し、ノード５０４は、Ａ０１メッセージの患者オブジェクトタイプに関係し、ノード５１２〜５１６は、メッセージがオブジェクト状態を介して操作される時にその状態が変化し得る患者オブジェクトタイプのフィールドに関係する。ノード５０６は、外来診察オブジェクトタイプに関係し、ノード５１８および５２０は、メッセージがオブジェクト状態を介して操作される時にその状態が変化し得る外来診察オブジェクトタイプのフィールドに関係する。ノード５０８は、Ａ０４メッセージタイプに関係し、ノード５１０は、Ａ０４メッセージの患者オブジェクトタイプに関係し、ノード５２２および５２４は、メッセージがオブジェクト状態を介して操作される時にその状態が変化し得る患者オブジェクトタイプのフィールドに関係する。

いくつかの例では、顧客（たとえば、Ｍａｙｏ Ｃｌｉｎｉｃ（登録商標））５２６から受信したメッセージを、Ａ０１メッセージタイプとして識別することができ、それに応じてノード（１つまたは複数）５０２、５０４、および／または５０６にマッピングすることができる。いくつかの例では、Ａ０１メッセージタイプについて、患者オブジェクトタイプは、患者がシステム内で以前に登録されていることをシステムが期待するので、ノード５１４で「Ｎｅｗ」および／または「Ａｃｔｉｖｅ」であるものとして前提条件状態を有することができる。Ａ０１メッセージタイプが処理されている時に、患者オブジェクト状態を、ノード５１６で「Ａｃｔｉｖｅ」に変更し、その患者がヘルスケア施設でアクティブ患者であることを示すことができる。さらに、Ａ０１メッセージが処理されている時に、それに関連するデータおよび／または内容を、たとえばツリー構造５００の構造化フォーマットに集約し、フォーマットし、その他を行うことができる。

いくつかの例では、顧客（たとえば、Ｉｎｔｅｒｍｏｕｎｔａｉｎ Ｈｅａｌｔｈｃａｒｅ）５２６から受信したメッセージを、Ａ０４メッセージタイプとして識別することができ、それに応じてノード（１つまたは複数）５０８および／または５１０にマッピングすることができる。いくつかの例では、Ａ０４メッセージについて、患者オブジェクトタイプは、患者がヘルスケア施設で患者としてシステム内で登録されていないので、患者オブジェクトが当初に存在しないと期待することができる。患者登録タイプメッセージが処理される時に、患者オブジェクトが、ノード５２２で作成され、その後、状態が、ノード５２４で「Ａｃｔｉｖｅ」に変更される。

いくつかの例では、ツリー構造５００に関連する例のシステムのデータ構造を、構成ユーザインターフェースを使用して顧客および／またはプロバイダによって操作し、かつ／またはカスタマイズすることができる。いくつかの例では、ツリー構造５００に関連する例のシステムは、ストレージデータ構造（たとえば、ツリー構造５００）を動的に定義することができる。いくつかの例では、ツリー構造５００に関連する例のシステムは、ランタイムにスキーマを定義することおよび／またはフォーマットすることによって、任意のタイプの入力データを受け取ることができる。

いくつかの例では、ツリー構造５００を、異なる顧客、アプリケーション、および／またはプログラムから異なるフォーマットで受け取られたメッセージをマッピングし、フォーマットし、かつ／または構造化するビジネスロジックに関連付けることができる。ビジネスロジックを、ランタイムに動的に定義することができる。本明細書で説明する例のこのビジネスロジックは、顧客が異なるメッセージフォーマット、アプリケーション、および／またはシステムを使用する場合であっても、すべての顧客について同一および／または類似するものとすることができる。したがって、新規のおよび／または既存のクライアントまたは顧客を、たとえばシステムの基礎になるビジネスロジックを変更せずに、彼らの着信メッセージがマッピングされ、フォーマットされ、構成され、その他が行われるように、同期化することができる。

図６に、顧客に基づくスクリプトを含む例のアーキテクチャ６００を示す。いくつかの例では、アーキテクチャ６００は、着信メッセージにスクリプトを導入することができるプリマッピングプラグイン６０２を含むことができる。スクリプトは、データおよび／または内容をより使用可能な形にフォーマットし、かつ／または構造化するために着信メッセージのデータおよび／または内容をフィルタリングし、アペンドし、解析し、かつ／または集約することができる。いくつかの例では、複数のプラグインスクリプト（たとえば、観察群６０４、コメントパッケージャ６０６）を、顧客（たとえば、管理者）および／またはプロバイダによる使用のためにライブラリ内で使用可能にすることができる。他の例では、プラグインスクリプトを、顧客および／またはプロバイダが記述し、かつ／または変更し、ライブラリに追加することができる。

この例では、プリマッピングプラグイン６０２は、観察指示または観察群６０４およびコメントパッケージャ６０６を含む。観察指示または観察群６０４は、たとえば、スクリプトのうちの１つまたは複数がそれに作用する観察（１つまたは複数）の着信データ構造を表すことができる。コメントパッケージャ６０６は、関連する観察（たとえば、同一の観察）のさまざまなデータ構造からのコメントを識別し、集約し、かつ／または組み合わせ、組み合わされたデータをたとえばストレージデータ構造のフィールドにアペンドすることができる。

いくつかの例では、着信メッセージ６０８は、第１データ構造内の微生物学観察に関係する第１セグメントと、第２構造内の追加の標本データを含む第２セグメントとを含むことができる。プリマッピングプラグイン６０２を使用することによって、適用可能な場合に、着信メッセージ６０８を標準データ構造に集約し、解析することができる。いくつかの例では、解析は、セグメント内にテキスト形式で埋め込まれたデータを分離することを含むことができる。いくつかの例では、着信メッセージタイプ、フォーマット、および／またはメッセージがそこから受信された顧客に固有の１つまたは複数のスクリプトを追加することによって、データを標準データ構造に集約し、フォーマットすることができる。

アーキテクチャ６００は、さまざまなシステムから受け取られたデータをマッピングし、かつ／または集約し、そのデータを医療情報を保持するリポジトリ内のカスタマイズ可能なおよび／または動的に構成可能なデータ構造に格納する、例のマッピング／モデリングツール６１０を含むことができる。たとえば、ＯＳＧＩ（すなわち、ｏｐｅｎ ｓｅｒｖｉｃｅｓ ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）を使用することによって、マッピング／モデリングツール６１０は、コードにパッチ（たとえば、顧客の要求で製造業者によって生成されたカスタムパッチ）を全く適用せずに、ランタイムにデータのマッピングおよび／または構造化に対して行われる変更を適用することができる。いくつかの例では、データを、プリマッピングプラグイン６０２のスクリプト（１つまたは複数）の適用の後にマッピング／モデリングツール６１０を使用して処理することができる。

いくつかの例では、マッピング／モデリングツール６１０は、イベントデータスキーマとデータモデルとの間のカスタマイズされたマッピングを可能にする。いくつかの例では、マッピング／モデリングツール６１０は、ある観察に関係し、異なるソースから受け取られたセグメントに含まれるデータを取り込み、かつ／または構造化されたフォーマットでの格納のために解析できる観察の単位に集約することができる。構造化されたおよび／または一貫するフォーマットでのデータは、十分に検証されるコードおよび／または構造を含むことができる。データを、格納の後に、意思決定支援に有利に使用することができる。いくつかの例では、受け取られたデータが標準から変化する時に顧客および／またはプロバイダに警報を与える警報をセットアップすることができる。

アーキテクチャ６００は、マッピング／モデリングツール６１０を使用して処理された後にデータにスクリプトを導入できるポストマッピングプラグイン６１２を含むことができる。スクリプトは、たとえば格納の前にデータおよび／または内容をフィルタリングし、アペンドし、解析し、かつ／または集約することができる。いくつかの例では、複数のプラグインスクリプト（たとえば、観察群６１４、アペンダ６１６）を、顧客および／またはプロバイダによる使用のためにライブラリ内で使用可能とすることができる。いくつかの例では、プラグインスクリプトを顧客および／またはプロバイダが記述し、かつ／または変更し、ライブラリに追加することができる。

いくつかの例では、ポストマッピングプラグイン６１２は、観察指示または観察群６１４およびアペンダ６１６を含む。観察指示または観察群６１４は、たとえば、スクリプトのうちの１つまたは複数がそれに作用する観察（１つまたは複数）のデータ構造を表すことができる。アペンダ６１６は、同一の観察に関連する着信観察メッセージの観察値を、システム内で永続させられるオブジェクトにアペンドすることができる。たとえば、末尾にキャリッジリターンを含む観察値を、アペンダ６１６を使用してフィルタリングして、キャリッジリターンを除去することができる。次に、たとえば、フィルタリングされた観察値を、格納のためにアペンドすることができる。

図７に、例のプリマッピングプラグインを使用してメッセージを集約し、フィルタリングし、解析し、フォーマットし、構造化し、かつ／または格納することができる親子関係を有する例のツリー構造７００を示す。この例では、ツリー構造７００は、親ノード７０２、７０４、および７０６と、子ノード７０８〜７１６とを含む。しかし、他の例では、ツリー構造７００は、より少数の、より多数の、および／または異なるノードを含むことができる。ノード７０２は、マイクロパネルに関係し、ノード７０４は、ノード７０８の定性的データ、ノード７１０の定量的、およびノード７１２のコメントを含む標本データに関係する。ノード７０６は、ノード７１４の定性的データおよびノード７１６の定量的データを含むマイクロスライド検査データに関係する。

いくつかの例では、着信メッセージは、すべてが微生物学標本に関係する複数のセグメントを含むことができる。セグメントのうちのいくつかは、定性的データを含むことができ、セグメントのうちのいくつかは、定量的データを含むことができ、セグメントのうちのいくつかは、コメントを含むことができる。プリマッピングスクリプトを適用することによって、定性的データをフィルタリングし、集約し、組み合わせ、かつ／または解析し、ノード７０８で格納することができ、定量的データをフィルタリングし、集約し、組み合わせ、かつ／または解析し、ノード７１０で格納することができ、コメントをフィルタリングし、集約し、組み合わせ、かつ／または解析し、ノード７１２で格納することができる。

いくつかの例では、着信メッセージは、マイクロスライド検査に関係する複数のセグメントを含むことができる。セグメントのうちのいくつかは、定量的データを含むことができ、セグメントのうちのいくつかは、定性的データを含むことができる。プリマッピングスクリプトを適用することによって、定性的データをフィルタリングし、集約し、組み合わせ、かつ／または解析し、ノード７１４で格納することができ、定量的データをフィルタリングし、集約し、組み合わせ、かつ／または解析し、ノード７１６で格納することができる。他の例では、微生物学標本データおよびマイクロスライド検査データを含む複数のセグメントを受け取ることができる。

図８〜１６に、たとえばヘルスケアシステム内でデータをマッピングし、かつ／またはモデリングするのに使用できるコンピュータ可読命令を使用して実施できるプロセスを表す例の流れ図を示す。図８〜１６の例のプロセスを、プロセッサ、コントローラ、および／または任意の他の適切な処理デバイスを使用して実行することができる。たとえば、図８〜１６の例のプロセスを、フラッシュメモリ、読取り専用メモリ（ＲＯＭ）、および／またはランダムアクセスメモリ（ＲＡＭ）などの有形のコンピュータ可読媒体に格納されたコーディングされた命令（たとえば、コンピュータ可読命令）を使用して実施することができる。本明細書で使用される時に、用語有形のコンピュータ可読媒体は、すべてのタイプのコンピュータ可読ストレージを含み、伝搬する信号を除外すると特に定義される。それに加えてまたはその代わりに、図８〜１６の例のプロセスを、フラッシュメモリ、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、キャッシュ、または情報が任意の持続時間の間（たとえば、長い時間期間の間、永久的に、短い瞬間、一時的バッファリングのため、および／または情報のキャッシングのため）格納される任意の他の記憶媒体などの固定コンピュータ可読媒体に格納されたコーディングされた命令（たとえば、コンピュータ可読命令）を使用して実施することができる。本明細書で使用される時に、用語固定コンピュータ可読媒体は、すべてのタイプのコンピュータ可読媒体を含み、伝搬する信号を除外すると特に定義される。

その代わりに、図８〜１６の例のプロセスの一部またはすべてを、特定用途向け集積回路（ＡＳＩＣ）（１つまたは複数）、プログラマブル論理デバイス（ＰＬＤ）（１つまたは複数）、フィールドプログラマブル論理デバイス（ＦＰＬＤ）（１つまたは複数）、ディスクリート論理、ハードウェア、ファームウェア、その他の任意の組合せ（１つまたは複数）を使用して実施することができる。また、図８〜１６の例のプロセスの一部またはすべてを、手動でまたは前述の技法のいずれかの任意の組合せ（１つまたは複数）、たとえば、ファームウェア、ソフトウェア、ディスクリート論理、および／またはハードウェアの任意の組合せとして、実施することができる。さらに、図８〜１６の例のプロセスを、図８〜１６の流れ図を参照して説明するが、図８〜１６のプロセスを実施する他の方法を使用することができる。たとえば、ブロックの実行の順序を変更することができ、かつ／あるいは説明されるブロックのいくつかを、変更し、除去し、副分割し、または組み合わせることができる。さらに、図８〜１６の例のプロセスのいずれかまたはすべてを、順次および／またはたとえば別々の処理スレッド、プロセッサ、デバイス、ディスクリート論理、回路などによって並列に実行することができる。

図８に、着信メッセージのデータをマッピングし、動的にモデリングし、かつ／または構造化されたフォーマットで格納することを可能にする例の流れ図８００を示す。ブロック８０２では、方法８００は、入力メッセージが受け取られたかどうかを判定する。着信メッセージは、観察データ、検査室データなどを含むＯＲＵメッセージである場合がある。着信メッセージが受け取られた場合には、ブロック８０４で、方法８００は、メッセージに関連するサービス識別子コード（たとえば、ＯＢＲ−４．１）の用語法を識別する。ブロック８０６では、方法８００は、識別されたサービス識別子コードについて指定されたモデルおよび／または識別されたサービス識別子コードに関連するモデルがあるか（たとえば、ＯＢＲ−４．１について指定されたモデルがあるか）どうかを判定する。識別されたサービス識別子コードに関連するモデルがない場合には、制御はブロック８０８に移り、ここで、エラーメッセージを生成することができる。

しかし、方法８００が、識別されたサービス識別子コードに関連するモデルを識別する場合には、制御はブロック８１０に移り、方法８００は、メッセージの内容から関連するモデルを抽出する。ブロック８１２では、方法８００は、抽出されたモデルをパネルのためにメモリ内に格納することができる。

ブロック８１４では、方法８００は、メッセージに関連する観察識別子コード（たとえば、ＯＢＸ ３．２）の用語法を識別することができる。ブロック８１６では、方法８００は、識別された観察識別子コードについて指定されたモデルがあるか（たとえば、ＯＢＸ ３．２について指定されたモデルがあるか）どうかを判定する。識別された観察識別子コードについて指定されたモデルがないと方法８００が判定する場合には、制御はブロック８１８に移り、方法８００は、観察に関する総称的モデルを作成し、ブロック８２０で、観察に関するモデルをメモリ内に格納する。

しかし、識別された観察識別子コードについて指定されたモデルがあると方法８００が判定する場合には、制御はブロック８２２に移り、方法８００は、メッセージの内容から関連するモデルを抽出する。ブロック８２４では、方法８００は、抽出されたモデルを観察のためにメモリ内に格納することができる。ブロック８２６では、方法８００は、ブロック８０２に戻るべきか否かを判定する。そうでない場合には、例の方法８００を終了する。

図９に、着信メッセージのデータをマッピングし、動的にモデリングし、かつ／または構造化されたフォーマットで格納することを可能にする例の流れ図９００を示す。いくつかの例では、方法９００を使用して、パネルを用いて観察を処理することができる。ブロック９０２では、方法９００は、ＯＲＵ−Ｒ０１メッセージが受け取られたか否かを判定する。そのようなメッセージが受け取られた場合には、制御はブロック９０４に移り、方法９００は、メッセージ関連するＯＢＸ−３観察ＩＤを識別する。ブロック９０６では、方法９００は、識別されたＯＢＸ−３観察ＩＤのマッピングされた概念コードがあるかどうかを判定する。方法９００が、マッピングされた概念コードを識別しない場合には、制御はブロック９０８に移り、方法９００は、エラーメッセージを生成する。

しかし、方法９００がマッピングされた概念コードを識別する場合には、制御はブロック９１０に移り、方法９００は、識別されたＯＢＸ−３観察ＩＤのマッピングされた概念コードを入手する。ブロック９１２では、方法９００は、マッピングされた概念コードに関連するおよび／またはマッピングされた概念コードがポイントするパネルが作成済みであるかどうかを判定する。いくつかの例では、パネルを、収縮期血圧測定値、拡張期血圧測定値、平均動脈圧測定値、その他などの項目を含む血圧パネルとすることができる。いくつかの例では、パネルを、排出量測定値、流体記述評価（ｆｌｕｉｄ ｄｅｓｃｒｉｐｔｉｏｎ ｅｖａｌｕａｔｉｏｎ）、その他などの項目を含む尿排出量パネルとすることができる。パネルが作成されていないと方法９００が判定する場合には、制御はブロック９１４に移り、方法９００は、パネルマッピングを入手し、ブロック９１６では、方法９００がパネルを作成する。

ブロック９１８では、方法９００は、観察項目マッピングを入手し、ブロック９２０では、方法９００は、たとえばメッセージに含まれるデータを使用して、観察項目を作成する。ブロック９２２では、方法９００は、観察項目を関連するパネルに伝え、かつ／または置き、ブロック９２４では、方法９００は、パネルをメモリ内に格納する。ブロック９２６では、方法９００は、ブロック９０２に戻るべきか否かを判定する。そうでない場合には、例の方法９００を終了する。

図１０に、着信メッセージのデータをマッピングし、動的にモデリングし、かつ／または構造化されたフォーマットで格納することを可能にする例の流れ図１０００を示す。いくつかの例では、方法１０００を使用して、パネルを用いずに複数のセグメントを含む観察を１つのモデルに処理することができる。ブロック１００２では、方法１０００は、ＯＲＵ−Ｒ０１メッセージが受け取られたか否かを判定する。そのようなメッセージが受け取られた場合には、制御はブロック１００４に移り、方法１０００は、メッセージに関連するＯＢＸ−３観察ＩＤを識別する。ブロック１００６では、方法１０００は、識別されたＯＢＸ−３観察ＩＤに関するマッピングされた概念コードがあるかどうかを判定する。方法１０００がマッピングされた概念コードを識別しない場合には、制御はブロック１００８に移り、方法１０００は、エラーメッセージを生成する。

しかし、方法１０００がマッピングされた概念コードを識別する場合には、制御はブロック１０１０に移り、方法１０００は、識別されたＯＢＸ−３観察ＩＤに関するマッピングされた概念コードを入手する。ブロック１０１２では、方法１０００は、マッピングされた概念コードに関連するおよび／またはマッピングされた概念コードがポイントする観察項目が作成済みであるかどうかを判定する。いくつかの例では、観察項目を、温度測定値、人工呼吸器血管作用薬、または血圧とすることができる。方法１０００が、観察項目が作成されていないと判定する場合には、制御はブロック１０１４に移り、方法１０００は、観察項目マッピングを入手し、ブロック１０１６では、方法１０００は、たとえばメッセージに含まれるデータを使用して観察項目を作成する。

ブロック１０１８では、方法１０００は、観察項目マッピングを入手し、かつ／またはプラグイン修飾子処理を適用する。ブロック１０２０では、方法１０００は、たとえばメッセージに含まれるデータを使用して観察項目を作成する。ブロック１０２２では、方法１０００は、観察項目をメモリ内に格納する。ブロック１０２４では、方法１０００は、ブロック１００２に戻るべきか否かを判定する。そうでない場合には、例の方法１０００を終了する。

図１１に、着信メッセージのデータをマッピングし、動的にモデリングし、かつ／または構造化されたフォーマットで格納することを可能にする例の流れ図１１００を示す。いくつかの例では、方法１１００を使用して、パネルを用いずに観察を処理することができる。ブロック１１０２では、方法１１００は、ＯＲＵ−Ｒ０１メッセージが受け取られたか否かを判定する。そのようなメッセージが受け取られた場合には、制御はブロック１１０４に移り、方法１１００は、メッセージに関連するＯＢＸ−３観察ＩＤを識別する。ブロック１１０６では、方法１１００は、識別されたＯＢＸ−３観察ＩＤに関するマッピングされた概念コードがあるかどうかを判定する。方法１１００がマッピングされた概念コードを識別しない場合には、制御はブロック１１０８に移り、方法１１００は、エラーメッセージを生成する。

しかし、方法１１００がマッピングされた概念コードを識別する場合には、制御はブロック１１１０に移り、方法１１００は、識別されたＯＢＸ−３観察ＩＤに関するマッピングされた概念コードおよび／またはマッピングを入手する。ブロック１１１２では、方法１１００は、観察ベースタイプが総称的手続きであるかどうかを判定する。いくつかの例では、総称的手続きを、人工呼吸器モード評価、呼吸セッティングレート（ｂｒｅａｔｈ ｓｅｔｔｉｎｇ ｒａｔｅ）測定値、呼吸数測定値、終末呼気陽圧セッティング測定値、満了した訂正済み機械一回呼吸量（ｅｘｐｉｒｅｄ ｃｏｒｒｅｃｔｅｄ ｍａｃｈｉｎｅ ｔｉｄａｌ ｖｏｌｕｍｅ）測定値、吸入酸素濃度（ｆｒａｃｔｉｏｎ ｏｆ ｉｎｓｐｉｒｅｄ ｏｘｙｇｅｎ）測定値、圧補助（ｐｒｅｓｓｕｒｅ ｓｕｐｐｏｒｔ）セッティング測定値、心拍数測定値、中心静脈圧測定値、その他に関連付けることができる。方法１１００が、観察ベースタイプが総称的手続きではないと判定する場合には、制御はブロック１１１４に移り、方法１１００は、メッセージに関連する特定の観察に関するマッピングを入手する。ブロック１１１６では、方法１１００は、特定の観察を構築する。

しかし、方法１１００が、観察ベースタイプが総称的手続きであると判定する場合には、制御はブロック１１１８に移り、方法１１００は、総称的手続きに関するマッピングを入手する。ブロック１１２０では、方法１１００は、メッセージに関連する総称的手続きを作成し、かつ／または構築する。いくつかの例では、手続きを、単一の弁の手続き（たとえば、ＡＶＲ、ＭＶＲ、ＴＶＲなど）、冠状動脈バイパス手術（たとえば、ＣＡＢＧ）、中隔心筋切除、サーキュラアレスト（ｃｉｒｃｕｌａｒ ａｒｒｅｓｔ）を用いない近心上行大動脈瘤再建（ｐｒｏｘｉｍａｌ ａｓｃｅｎｄｉｎｇ ａｏｒｔａ ａｎｅｕｒｙｓｍ ｒｅｐａｉｒ）などに関連付けることができる。ブロック１１２２で、方法１１００は、キーコード（たとえば、ＣＥＴｙｐｅキーコード）を、ＯＢＸ−３観察ＩＤに関連するマッピングされた概念コードに置換する。ブロック１１２４で、方法１１００は、手続きおよび／または関連する情報をメモリ内に格納する。ブロック１１２６で、方法１１００は、ブロック１１０２に戻るべきか否かを判定する。そうでない場合には、例の方法１１００を終了する。

図１２に、着信メッセージのデータをマッピングし、動的にモデリングし、かつ／または構造化されたフォーマットで格納することを可能にする例の流れ図１２００を示す。いくつかの例では、方法１２００を使用して、検査室データを処理することができる。ブロック１２０２では、方法１２００は、ＯＲＵ−Ｒ０１メッセージが受け取られたか否かを判定する。そのようなメッセージが受け取られた場合には、制御はブロック１２０４に移り、方法１２００は、メッセージに関連するＯＢＲ−４サービスコード（たとえば、ユニバーサルＯＢＲ−４サービスコード）を識別する。ブロック１２０６では、方法１２００は、メッセージに関連するＯＢＸ−３観察ＩＤを識別する。ブロック１２０８では、方法１２００は、ＯＢＸ−３観察ＩＤに関するマッピングがあるかどうか、および／またはＥＣＩＳ用語法名前空間内にマッピングがあるかどうかを判定する。方法１２００がＯＢＸ−３観察ＩＤに関するマッピングを識別しない場合には、制御はブロック１２１０に移り、方法１２００は、エラーメッセージを生成する。

しかし、方法１２００が、ＯＢＸ−３観察ＩＤに関するマッピングを識別する場合には、制御はブロック１２１２に移り、そのようなマッピングを入手する。ブロック１２１４では、方法１２００は、メッセージが標準検査室領域および／または検査室観察領域内であるかどうかを判定する。メッセージが標準検査室領域および／または検査室観察領域内ではない場合には、制御はブロック１２１６に移り、方法１２００は、エラーメッセージを生成する。ブロック１２１８では、方法１２００は、どの総称的検査室モデルがメッセージに関連するのかを判定する。いくつかの例では、方法１２００は、メッセージに関連するＯＢＸ−２値タイプを識別し、そのＯＢＸ−２値タイプを使用して、データが標準検査室観察定量的（ｓｔａｎｄａｒｄ ｌａｂ ｏｂｓｅｒｖａｔｉｏｎｓ ｑｕａｎｔｉｔａｔｉｖｅ）モデル、標準検査室観察コーデッド（ｓｔａｎｄａｒｄ ｌａｂ ｏｂｓｅｒｖａｔｉｏｎｓ ｃｏｄｅｄ）モデル、標準検査室観察ナレーティブ（ｓｔａｎｄａｒｄ ｌａｂ ｏｂｓｅｒｖａｔｉｏｎｓ ｎａｒｒａｔｉｖｅ）モデル、その他にあることなどの結果のデータタイプを判定することができる。

しかし、方法１２００が、メッセージが標準検査室領域および／または検査室観察領域内にあると判定する場合には、制御はブロック１２２０に移り、方法１２００は、たとえばメッセージに関連するキーコード、関係文脈などに基づいて特定の検査室モデルを判定する。ブロック１２２２では、方法１２００は、メッセージ内容からモデルを生成し、ブロック１２２４では、方法１２００は、そのモデルをメモリ内に格納する。

ブロック１２２６では、方法１２００は、ＯＢＲ−４サービスコードに関する標準検査室パネル領域があるか（たとえば、コードが標準検査室パネル領域内に存在するか）どうかを判定する。ＯＢＲ−４サービスコードに関する標準検査室パネルがない場合には、制御はブロック１２１０に移り、方法１２００は、エラーメッセージを生成する。しかし、ＯＢＲ−４サービスコードに関する標準検査室パネルがある場合には、制御はブロック１２２８に移り、方法１２００は、メッセージ内容から検査室パネルを生成する。ブロック１２３０では、方法１２００は、パネルをメモリ内に格納し、ブロック１２３２では、方法１２００は、ブロック１２０２に戻るべきか否かを判定する。そうでない場合には、例の方法１２００を終了する。

図１３に、着信メッセージのデータをマッピングし、動的にモデリングし、かつ／または構造化されたフォーマットで格納することを可能にする例の流れ図１３００を示す。いくつかの例では、方法１３００を使用して、観察データを処理することができる。ブロック１３０２では、方法１３００は、ＯＲＵ−Ｒ０１メッセージが受け取られたか否かを判定する。そのようなメッセージが受け取られた場合には、制御はブロック１３０４に移り、方法１３００は、メッセージに関連するＯＢＲ−４サービスコード（たとえば、ユニバーサルＯＢＲ−４サービスコード）を識別する。ブロック１３０６では、方法１３００は、メッセージに関連するＯＢＸ−３観察ＩＤを識別する。ブロック１３０８では、方法１３００は、ＯＢＸ−３観察ＩＤに関するマッピングがあるかどうか、および／またはＥＣＩＳ用語法名前空間内にマッピングがあるかどうかを判定する。方法１３００がＯＢＸ−３観察ＩＤに関するマッピングを識別しない場合には、制御はブロック１３１０に移り、方法１３００は、エラーメッセージを生成する。

しかし、方法１３００が、ＯＢＸ−３観察ＩＤに関するマッピングを識別する場合には、制御はブロック１３１２に移り、そのようなマッピングを入手する。ブロック１３１４では、方法１３００は、メッセージが観察領域内であるかどうかを判定する。メッセージが観察領域内ではない場合には、制御はブロック１３１６に移り、方法１３００は、エラーメッセージを生成する。ブロック１３１８では、方法１３００は、どの総称的観察モデルがメッセージに関連するのかを判定する。

しかし、方法１３００が、メッセージが観察領域内であると判定する場合には、制御はブロック１３２０に移り、方法１３００は、メッセージ、ＯＢＸ−３コードなどに関連するキーコード、関係文脈などに基づいて特定の観察モデル（たとえば、特定の観察臨床要素タイプ（ＣＥＴｙｐｅ））を判定する。ブロック１３２２では、方法１３００は、メッセージ内容からモデルを生成し、ブロック１３２４では、方法１３００は、そのモデルをメモリ内に格納する。

ブロック１３２６では、方法１３００は、ＯＢＲ−４サービスコードに関する標準観察パネル領域があるか（たとえば、コードが標準観察パネル領域内に存在するか）どうかを判定する。ＯＢＲ−４サービスコードに関する標準観察パネルがない場合には、制御はブロック１３１０に移り、方法１３００は、エラーメッセージを生成する。しかし、ＯＢＲ−４サービスコードに関する標準観察パネルがある場合には、制御はブロック１３２８に移り、方法１３００は、メッセージ内容から特定の観察パネル（たとえば、特定の検査室ＣＥＴｙｐｅ）を生成する。ブロック１３３０では、方法１３００は、パネルをメモリ内に格納し、ブロック１３３２では、方法１３００は、ブロック１３０２に戻るべきか否かを判定する。そうでない場合には、例の方法１３００を終了する。

図１４に、着信メッセージのデータをマッピングし、動的にモデリングし、かつ／または構造化されたフォーマットで格納することを可能にする例の流れ図１４００を示す。いくつかの例では、方法１４００を使用して、代替データを処理することができる。ブロック１４０２では、方法１４００は、ＯＲＵ−Ｒ０１メッセージが受け取られたか否かを判定する。そのようなメッセージが受け取られた場合には、制御はブロック１４０４に移り、方法１４００は、メッセージに関連するＯＢＸ−３観察ＩＤを識別する。ブロック１４０６では、方法１４００は、識別されたＯＢＸ−３観察ＩＤに関する検査室ベースタイプがあるかどうかを判定する。識別されたＯＢＸ−３観察ＩＤに関する検査室ベースタイプがない場合には、制御はブロック１４０８に移り、方法１４００は、エラーメッセージを生成する。

しかし、方法１４００が、識別されたＯＢＸ−３観察ＩＤに関する検査室ベースタイプがあると判定する場合には、制御はブロック１４１０に移り、方法１４００は、メッセージ内容から標準検査室観察を生成する。標準検査室観察を、標準検査室観察定量的、標準検査室観察コーデッド、標準検査室観察オリジナル（ｓｔａｎｄａｒｄ ｌａｂ ｏｂｓｅｒｖａｔｉｏｎｓ ｏｒｉｇｉｎａｌ）、標準検査室観察読み（ｓｔａｎｄａｒｄ ｌａｂ ｏｂｓｅｒｖａｔｉｏｎｓ ｒｅａｄ）、標準検査室観察ナレーティブなどに関連付けることができる。

ブロック１４１２では、方法１４００は、ＯＢＸ−２値タイプを識別し、ブロック１４１４では、方法１４００は、ＯＢＸ−２値タイプがベース検査室データタイプと互換であるかどうかを判定する。ＯＢＸ−２値タイプがベース検査室データタイプと互換ではない場合には、制御はブロック１４１６に移り、方法１４００は、メッセージに関連するＯＢＸ−５観察値を識別する。ブロック１４１８では、方法１４００は、代替処理を開始し、警告メッセージを生成することができる。ブロック１４２０では、方法１４００は、研究室観察およびＯＢＸ−５（ＰＱに関する）単位を代替データとして格納する。

しかし、方法１４００が、ＯＢＸ−２値タイプがベース検査室データタイプと互換であると判定する場合には、制御はブロック１４２２に移り、通常処理を継続する。ブロック１４２４では、方法１４００は、検査室観察をメモリ内に格納し、ブロック１４２６では、方法１４００は、ブロック１４０２に戻るべきか否かを判定する。そうでない場合には、例の方法１４００を終了する。

図１５に、着信メッセージのデータをマッピングし、動的にモデリングし、かつ／または構造化されたフォーマットで格納することを可能にする例の流れ図１５００を示す。いくつかの例では、方法１５００を使用して、順序定量（Ｏｒｄｉｎａｌ Ｑｕａｎｔｉｔａｔｉｖｅ）（ＯｒｄＱｎ）データを処理することができる。ブロック１５０２では、方法１５００は、ＯＲＵ−Ｒ０１メッセージが受け取られたか否かを判定する。そのようなメッセージが受け取られた場合には、制御はブロック１５０４に移り、方法１５００は、メッセージに関連するＯＢＸ−３観察ＩＤを識別する。ブロック１５０６では、方法１５００は、ＯＢＸ−３観察ＩＤに関連する特定の検査室ベースタイプが定量的であるかどうかを判定する。検査室ベースタイプが定量的ではない場合には、制御はブロック１５０８に移り、方法１５００は、通常処理を継続する。ブロック１５１０では、方法１５００は、メッセージに関連する単位および／または他のデータをメモリ内に格納する。

しかし、特定の検査室ベースタイプが定量的である場合には、制御はブロック１５１２に移り、方法１５００は、メッセージ内容から標準検査室観察定量的を生成する。ブロック１５１４では、方法１５００は、標準検査室観察定量的をメモリ内に格納する。ブロック１５１６では、方法１５００は、メッセージに関連するＯＢＸ−２値タイプを識別し、ブロック１５１８では、方法１５００は、ＯＢＸ−２値タイプがＰＱデータタイプと互換であるかどうかを判定する。ＯＢＸ−２値タイプがＰＱデータタイプと互換である場合には、制御はブロック１５０８に移る。

ＯＢＸ−２値タイプがＰＱデータタイプと互換ではない場合には、制御はブロック１５２０に移り、方法１５００は、ＯＢＸ−２値タイプがＣＥ（ｃｏｄｅｄ ｅｘｃｅｐｔｉｏｎ）、ＣＷＥ（ｃｏｄｅｄ ｗｉｔｈ ｅｘｃｅｐｔｉｏｎ）、またはＣＯ（ｃｏｄｅｄ ｏｒｄｉｎａｌ）に関連するかどうかを判定する。ＯＢＸ−２値タイプがＣＥ、ＣＷＥ、またはＣＯに関連しない場合には、制御はブロック１５２２に移り、方法１５００は、代替データ処理を実行する。ブロック１５２４では、方法１５００は、代替データにアペンドされた単位を格納する。

ＯＢＸ−２値タイプがＣＥ、ＣＷＥ、またはＣＯに関連する場合には、制御はブロック１５２６に移り、方法１５００は、メッセージに関連するＯＢＸ−５観察値を識別し、ブロック１５２８では、方法１５００は、メッセージに関連するキャレットで区切られたデータを解析する。ブロック１５３０では、方法１５００は、メッセージに関連する最初のフィールドおよび／またはフィールド１に関するマッピングされた概念コードを入手する。フィールド１に関するマッピングされた概念コードが存在しない場合には、制御はブロック１５３２に移り、方法１５００は、エラーメッセージを生成し、ブロック１５３４では、方法１５００は、ＯＢＸ−５および単位を代替データとしてメモリ内に格納する。

方法１５００が、フィールド１に関するマッピングされた概念コードを入手する場合には、制御はブロック１５３６に移り、方法１５００は、マッピングされた概念コードが順序解釈（ｏｒｄｉｎａｌ ｉｎｔｅｒｐｒｅｔａｔｉｏｎ）値集合に含まれるかどうかを判定する。含まれない場合には、制御はブロック１５３２に移り、エラーメッセージを生成することができる。含まれる場合には、制御はブロック１５３８に移り、方法１５００は、コードと順序解釈修飾子からのオリジナルテキストと単位とを代替データ内に格納する。ブロック１５４０では、方法１５００は、ブロック１５０２に戻るべきか否かを判定する。そうでない場合には、例の方法１５００を終了する。

図１６に、着信メッセージのデータをマッピングし、動的にモデリングし、かつ／または構造化されたフォーマットで格納することを可能にする例の流れ図１６００を示す。ブロック１６０２は、検査室インターフェースキューを表し、ブロック１６０４は、検査室ＨＬ７ｖ２メッセージを表す。ブロック１６０６で、方法１６００は、ＯＢＲ−４ユニバーサルサービスコードを識別し、ブロック１６０８で、方法１６００は、ＯＲＢ−４コードがＥＣＩＳ名前空間へのマッピングを有するかどうかを判定することができる。そのようなマッピングが存在しない場合には、制御はブロック１６１０に移り、方法１６００は、例外をキャッチし、警報を送ることができる。これおよび／または任意の他の警報および／またはエラーメッセージが本明細書で説明するように生成されることに応答して、そのようなメッセージを、手動ユーザレビューを可能にするユーザインターフェースを介してユーザに伝えることができる。その後、制御はブロック１６１２に移り、概念が、ＥＣＩＳ名前空間内で作成され、マッピングが、コード（たとえば、ＯＲＢ−４コード）とＥＣＩＳ概念との間で作成される。ブロック１６１４では、方法１６００は、メッセージをキューに再サブミットすることができる。その代わりに、ブロック１６１６で、メッセージをマッピングし、適当なパネルに格納することができる。この代替案は、ブロック１６１４に接続されたブロックのいずれにも適用することができる。いくつかの例では、ブロック１６１６で格納されるデータを、臨床データリポジトリ（ＣＤＲ）とすることができる。

ＯＢＲ−４コードがＥＣＩＳ名前空間内にマッピングを有する場合には、制御はブロック１６１８に移り、方法１６００は、ＯＲＢ−４コードが用語法の「ＯｒｄｅｒａｂｌｅＬａｂＴｅｓｔ」領域内にあるかどうかを判定する。ＯＢＲ−４コードがそのような領域内にない場合には、制御はブロック１６２０に移り、方法１６００は、例外をキャッチし、警報を送ることができる。ブロック１６２２では、コードを用語法内の正しい領域に追加することができる。

ＯＢＲ−４コードが用語法の「ＯｒｄｅｒａｂｌｅＬａｂＴｅｓｔ」領域内にある場合には、制御はブロック１６２４に移り、方法１６００は、ＣＥＴｙｐｅ標準検査室パネルを使用し、ブロック１６１６で、そのパネルを格納することができる。

ブロック１６２６では、方法１６００は、ＯＢＸ−３観察ＩＤを識別することができ、ブロック１６２８では、方法１６００は、ＯＢＸ−３コードがＥＣＩＳ名前空間内の概念へのマッピングを有するかどうかを判定することができる。マッピングが存在しない場合には、制御はブロック１６３０に移り、方法１６００は、例外をキャッチし、警報を送ることができる。その後、制御はブロック１６１２に移り、ここで、概念が、ＥＣＩＳ名前空間内で作成され、マッピングが、コード（たとえば、ＯＢＸ−３コード）とＥＣＩＳ概念との間で作成される。

マッピングが存在する場合には、制御はブロック１６３２に移り、方法１６００は、ＯＢＸ−３コードが用語法の「ＳｔａｎｄａｒｄＬａｂＯｂｓ」領域内にあるかどうかを判定する。ＯＢＸ−３コードがそのような領域内にない場合には、制御はブロック１６３４に移り、方法１６００は、例外をキャッチし、警報を送ることができる。ブロック１６３６では、方法１６００は、適当なＬａｂ Ｏｂｓ領域にコードを追加することができ、特定のモデルを作成することができる。

ＯＢＸ−３コードが用語法の「ＳｔａｎｄａｒｄＬａｂＯｂｓ」領域内にある場合には、制御はブロック１６３８に移り、方法１６００は、識別されたＯＢＸ−３コードをキーとして使用する特定の検査室モデルがあるかどうかを判定する。どの特定の検査室モデルも識別されたＯＢＸ−３コードをキーとして使用していない場合には、制御はブロック１６４０に移り、方法１６００は、ＯＢＸ−３コードが検査室観察と考えられない概念であるかどうかを判定する。ブロック１６４２では、方法１６００は、例外をキャッチし、警報を送ることができる。ブロック１６４４では、方法１６００は、特定の検査室モデルを作成することができる。

方法１６００が、ＯＢＸ−３コードが検査室観察と考えられない概念コードではないと判定する場合には、制御はブロック１６４６に移り、方法１６００は、どの包括的ＳｔａｎｄａｒｄＬａｂＯｂｓ ＣＥＴｙｐｅを使用しなければならないのかを判定する。ブロック１６４８では、方法１６００は、識別されたＣＥＴｙｐｅの特定のマッピング構成ファイルをルックアップする。

方法１６００が、ＯＢＸ−３コードが検査室観察と考えられない概念コードであると判定する場合には、制御はブロック１６５０および１６５２に移る。ブロック１６５０では、方法１６００は、ＯＢＸ−３コードがＬａｂＣｏｍｍｅｎｔ領域内の概念であるかどうかを判定し、ＯＢＸ−３コードおよび／または任意の関連するデータをコメント修飾子として格納する。ブロック１６５２では、方法１６００は、ＯＢＸ−３コードが性別、年齢、または人種に関連するかどうかを判定し、用語法内のキーコードおよび関係によってＣＥＴｙｐｅをルックアップする。ブロック１６５４では、方法１６００は、ＣＥｔｙｐｅの特定のマッピング構成ファイルをルックアップする。

方法１６００が、識別されたＯＢＸ−３コードをキーとして使用する特定の検査室モデルがあると判定する場合に、制御はブロック１６５６に移り、方法１６００は、用語法内のキーコードおよび関係によってＣＥＴｙｐｅをルックアップする。ブロック１６５８では、方法１６００は、ＣＥＴｙｐｅオブジェクト内の「ベース」属性によってＣＥＴｙｐｅをルックアップし、ブロック１６６０では、方法１６００は、ＣＥＴｙｐｅの特定のマッピング構成ファイルをルックアップする。

図１７は、本明細書で説明されるシステムおよび方法を実施するために使用できる例のプロセッサシステム１７００のブロック図である。図１７に示されているように、プロセッサシステム１７００は、相互接続バス１７０４に結合されたプロセッサ１７０２を含む。プロセッサ１７０２は、任意の適切なプロセッサ、処理ユニット、またはマイクロプロセッサとすることができる。図１７には示されていないが、プロセッサシステム１７００は、マルチプロセッサシステムとすることができ、したがって、プロセッサ１７０２と同一であるかこれに類似し、相互接続バス１７０４に通信的に結合された１つまたは複数の追加のプロセッサを含むことができる。

図１７のプロセッサ１７０２は、チップセット１７０６に結合され、チップセット１７０６は、メモリコントローラ１７０８および入出力（Ｉ／Ｏ）コントローラ１７１０を含む。周知のように、チップセットは、通常、Ｉ／Ｏ管理機能およびメモリ管理機能ならびにチップセット１７０６に結合された１つまたは複数のプロセッサによってアクセス可能であるか使用される複数の汎用レジスタおよび／または特殊目的レジスタ、タイマなどを提供する。メモリコントローラ１７０８は、プロセッサ１７０２（または複数のプロセッサがある場合に複数のプロセッサ）がシステムメモリ１７１２およびマスストレージメモリ１７１４にアクセスすることを可能にする機能を実行する。

システムメモリ１７１２は、たとえばスタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、フラッシュメモリ、読取り専用メモリ（ＲＯＭ）、その他などの任意の所望のタイプの揮発性メモリおよび／または不揮発性メモリを含むことができる。マスストレージメモリ１７１４は、ハードディスクドライブ、光ドライブ、テープストレージデバイスなどを含む任意の所望のタイプのマスストレージデバイスを含むことができる。

Ｉ／Ｏコントローラ１７１０は、プロセッサ１７０２がＩ／Ｏバス１７２２を介して周辺入出力（Ｉ／Ｏ）デバイス１７１６および１７１８ならびにネットワークインターフェース１７２０と通信することを可能にする機能を実行する。Ｉ／Ｏデバイス１７１６および１７１８は、たとえばキーボード、ビデオディスプレイすなわちモニタ、マウス、その他などの任意の所望のタイプのＩ／Ｏデバイスとすることができる。ネットワークインターフェース１７２０は、たとえば、プロセッサシステム１７００が別のプロセッサシステムと通信することを可能にする、イーサネット（商標）デバイス、非同期転送モード（ＡＴＭ）デバイス、８０２．１１デバイス、ＤＳＬモデム、ケーブルモデム、セルラモデムなどとすることができる。

メモリコントローラ１７０８およびＩ／Ｏコントローラ１７１０が、図１７ではチップセット１７０６内の別々のブロックとして図示されているが、これらのブロックによって実行される機能を、単一の半導体回路内で一体化することができ、あるいは、複数の別々の集積回路を使用して実施することができる。

ある種の実施形態は、上で説明した機能性を実施するために方法、システム、および任意の機械可読媒体上のコンピュータプログラム製品を企図する。ある種の実施形態を、たとえば、既存のコンピュータプロセッサを使用して、これまたは別の目的のために組み込まれた特殊目的コンピュータプロセッサによって、またはハードワイヤドシステムおよび／もしくはファームウェアシステムによって実施することができる。

ある種の実施形態は、コンピュータ実行可能命令またはデータ構造を担持するかその上に格納されたコンピュータ可読媒体を含む。そのようなコンピュータ可読媒体は、汎用のもしくは特殊目的のコンピュータまたはプロセッサを有する他の機械によってアクセスできる任意の使用可能な媒体とすることができる。たとえば、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ、ＣＤ−ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、またはコンピュータ実行可能命令もしくはデータ構造の形で所望のプログラムコードを担持しもしくは格納するのに使用でき、汎用のもしくは特殊目的のコンピュータもしくはプロセッサを有する他の機械によってアクセスできる任意の他の媒体を含むことができる。上記の組合せも、コンピュータ可読媒体の範囲に含まれる。コンピュータ実行可能命令は、たとえば、汎用コンピュータ、特殊目的コンピュータ、または特殊目的処理機械にある機能または機能のグループを実行させる命令およびデータを含む。

一般に、コンピュータ実行可能命令は、特定のタスクを実行するか特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールは、本明細書で開示されるある種の方法およびシステムのステップを実行するためのプログラムコードの例を表す。そのような実行可能命令または関連するデータ構造の特定のシーケンスは、そのようなステップで説明される機能を実施するための対応する行為の例を表す。

本発明の実施形態を、プロセッサを有する１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク化された環境で実践することができる。論理接続は、限定ではなく例としてここで提示されるローカルエリアネットワーク（ＬＡＮ）および広域ネットワーク（ＷＡＮ）を含むことができる。そのようなネットワーキング環境は、オフィス全体または企業全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものであり、さまざまな異なる通信プロトコルを使用することができる。当業者は、そのようなネットワークコンピューティング環境が、通常は、パーソナルコンピュータ、ハンドヘルドコンピュータ、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な消費者エレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、および類似物を含む多数のタイプのコンピュータシステム構成を含むことを了解するであろう。本発明の実施形態を、通信ネットワークを介してリンクされた（ハードワイヤドリンク、無線リンク、またはハードワイヤドリンクもしくは無線リンクの組合せのいずれかによって）ローカル処理デバイスおよびリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、ローカルメモリストレージデバイスとリモートメモリストレージデバイスとの両方に配置することができる。

ある種の方法、装置、および製造品を本明細書で説明したが、本特許の包含の範囲は、それに限定されない。逆に、本特許は、文字どおりまたは均等論の下でのいずれかで添付の特許請求の範囲の範囲に公正に含まれるすべての方法、装置、および製造品を包含する。

１００ ヘルスケア環境
１０２ 病院
１０４ ピクチャ記録更新システム（ＰＡＣＳ）
１０６ 検査室情報システム
１０８ 心臓病科
１１０ 放射線情報システム（ＲＩＳ）
１１２ 腫瘍科
１１４ 電子医療記録（ＥＭＲ）システム
１１６ 外来診療所
１１８ 検査室情報システム
１２０ ＰＡＣＳ
１２２ Ｅｎｔｅｒｐｒｉｓｅ Ｃｌｉｎｉｃａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ（ＥＣＩＳ）
１２４ ネットワーク
１２６ 伝送媒体
１２８ 伝送媒体
１３０ メッセージ処理システム
１３２ データベースまたはデータストア
２００ メッセージ処理システム
２０２ インターフェース
２０４ 識別子
２０６ ユニバーサルスキーマ
２０８ プリマッパ
２１０ プロセッサ
２１２ ポストマッパ
２１４ データストア
３０２ ＡＤＴメッセージ構造
３０４ サービスインターフェース、サブスキーマ、および／またはスキーマ
３０６ ヘルスケア情報システム
３０８ インターフェースエンドポイント
４０２ ＡＤＴメッセージ構造
４０４ 「ユニバーサル」スキーマまたはユニフォームスキーマ
４０６ ヘルスケア情報システム
４０８ インターフェースエンドポイント
５００ ツリー構造
５０２〜５１０ 親ノード
５１２〜５１４ 子ノード
５２６ 顧客
６００ アーキテクチャ
６０２ プリマッピングプラグイン
６０４ 観察群
６０６ コメントパッケージャ
６０８ 着信メッセージ
６１０ マッピング／モデリングツール
６１２ ポストマッピングプラグイン
６１４ 観察群
６１６ アペンダ
７００ ツリー構造
７０２ 親ノード
７０４ 親ノード
７０６ 親ノード
７０８〜７１６ 子ノード
１７００ プロセッサシステム
１７０２ プロセッサ
１７０４ 相互接続バス
１７０６ チップセット
１７０８ メモリコントローラ
１７１０ 入出力（Ｉ／Ｏ）コントローラ
１７１２ システムメモリ
１７１４ マスストレージメモリ
１７１６ 周辺入出力（Ｉ／Ｏ）デバイス
１７１８ 周辺入出力（Ｉ／Ｏ）デバイス
１７２０ ネットワークインターフェース
１７２２ Ｉ／Ｏバス

Claims (22)

1. ヘルスケアメッセージ構造の異なるバージョンに関連するデータ入力を受け取るコンピュータ実施される方法であって、
   単一のサービスインターフェースを介して第１フォーマットの第１データを受け取ることであって、前記第１データの１つまたは複数のフィールドは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの少なくとも１つによってサポートされない、受け取ることと、
   前記単一のサービスインターフェースを介して第２フォーマットの第２データを受け取ることであって、前記第２データの１つまたは複数のフィールドは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの少なくとも１つによってサポートされず、前記単一のサービスインターフェースは、インターフェースエンドポイントの個数を最小にするために前記第１データおよび前記第２データの前記受け取ることを可能にする、受け取ることと
   を含むコンピュータ実施される方法。
2. 前記ヘルスケアメッセージ構造は、Ｈｅａｌｔｈｃａｒｅ Ｌｅｖｅｌ Ｓｅｖｅｎ構造を含む、請求項１記載のコンピュータ実施される方法。
3. 前記第１データは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの１つまたは複数によってサポートされる１つまたは複数のフィールドを含まない、請求項１記載のコンピュータ実施される方法。
4. 前記単一のサービスインターフェースは、前記第１データの前記１つまたは複数のフィールドまたは前記第２データの前記１つまたは複数のフィールドの前記受け取ることを制限しないことによって、前記それぞれのフォーマットの前記データの前記受け取ることを可能にする、請求項１記載のコンピュータ実施される方法。
5. 前記単一のサービスインターフェースは、前記第１データまたは前記第２データのうちの少なくとも１つに関連しないフィールドの前記受け取ることを要求しないことによって、前記それぞれのフォーマットの前記データの前記受け取ることを可能にする、請求項１記載のコンピュータ実施される方法。
6. 前記第２データは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの１つまたは複数によってサポートされる１つまたは複数のフィールドを含まない、請求項１記載のコンピュータ実施される方法。
7. 前記単一のサービスインターフェースは、ランタイムに定義される、請求項１記載のコンピュータ実施される方法。
8. 前記単一のサービスインターフェースをカスタマイズすることを可能にすることをさらに含む、請求項１記載のコンピュータ実施される方法。
9. 前記第１データは、第１ヘルスケアデバイスまたは第１情報システムに関連して生成され、前記第２データは、第２ヘルスケアデバイスまたは第２情報システムに関連して生成される、請求項１記載のコンピュータ実施される方法。
10. 前記第１データは、第１ヘルスケアエンティティに関連して生成され、前記第２データは、第２ヘルスケアエンティティに関連して生成される、請求項１記載のコンピュータ実施される方法。
11. 前記第１データは、第１Ａｄｍｉｔ Ｄｉｓｃｈａｒｇｅ Ｔｒａｎｓｆｅｒメッセージ構造に関連し、前記第２データは、第２Ａｄｍｉｔ Ｄｉｓｃｈａｒｇｅ Ｔｒａｎｓｆｅｒメッセージ構造に関連する、請求項１記載のコンピュータ実施される方法。
12. 前記第１データは、第１トリガを含み、前記第２データは、第２トリガを含む、請求項１記載のコンピュータ実施される方法。
13. ヘルスケアメッセージ構造の異なるバージョンに関連するデータを受け取るコンピュータ実施される方法であって、
    単一のサービスインターフェースを介して第１フォーマットの第１データを受け取ることであって、前記第１データは、１つまたは複数のフィールドを含み、前記第１データは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの１つまたは複数によってサポートされる１つまたは複数のフィールドを含まない、受け取ることと、
    前記単一のサービスインターフェースを介して第２フォーマットの第２データを受け取ることであって、前記第２データは、１つまたは複数のフィールドを含み、前記第２データは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの１つまたは複数によってサポートされる１つまたは複数のフィールドを含まず、前記単一のサービスインターフェースは、インターフェースエンドポイントの個数を最小にするために前記第１データおよび前記第２データの前記受け取ることを可能にする、受け取ることと
    を含む、コンピュータ実施される方法。
14. 前記第１データの１つまたは複数のフィールドは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの少なくとも１つによってサポートされず、前記第２データの１つまたは複数のフィールドは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの少なくとも１つによってサポートされない、請求項１３記載のコンピュータ実施される方法。
15. 前記単一のサービスインターフェースは、前記第１データの前記１つまたは複数のフィールドまたは前記第２データの前記１つまたは複数のフィールドの前記受け取ることを制限しないことによって、前記それぞれのフォーマットの前記データの前記受け取ることを可能にする、請求項１３記載のコンピュータ実施される方法。
16. 前記単一のサービスインターフェースは、前記第１データまたは前記第２データのうちの少なくとも１つに含まれないフィールドの前記受け取ることを要求しないことによって、前記それぞれのフォーマットの前記データの前記受け取ることを可能にする、請求項１３記載のコンピュータ実施される方法。
17. 前記単一のサービスインターフェースをカスタマイズすることを可能にすることをさらに含む、請求項１３記載のコンピュータ実施される方法。
18. 前記第１データは、第１ヘルスケアデバイスまたは第１情報システムに関連して生成され、前記第２データは、第２ヘルスケアデバイスまたは第２情報システムに関連して生成される、請求項１３記載のコンピュータ実施される方法。
19. 前記第１データは、第１ヘルスケアエンティティに関連して生成され、前記第２データは、第２ヘルスケアエンティティに関連して生成される、請求項１３記載のコンピュータ実施される方法。
20. 前記第１データは、第１トリガを含み、前記第２データは、第２トリガを含む、請求項１３記載のコンピュータ実施される方法。
21. ヘルスケアメッセージ構造の異なるバージョンに関連するデータを受け取るコンピュータ実施される方法であって、
    単一のサービスインターフェースを介して第１フォーマットの第１データを受け取ることであって、前記第１データは、１つまたは複数のフィールドを含み、前記第１データは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの１つまたは複数によってサポートされる１つまたは複数のフィールドを含まない、受け取ることと、
    前記単一のサービスインターフェースを介して第２フォーマットの第２データを受け取ることであって、前記第２データの１つまたは複数のフィールドは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの少なくとも１つによってサポートされず、前記単一のサービスインターフェースは、インターフェースエンドポイントの個数を最小にするために前記第１データおよび前記第２データの前記受け取ることを可能にする、受け取ることと
    を含む、コンピュータ実施される方法。
22. 実行された時に、機械に、
    単一のサービスインターフェースを介して第１フォーマットの第１データを受け取ることであって、前記第１データの１つまたは複数のフィールドは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの少なくとも１つによってサポートされない、受け取ることと、
    前記単一のサービスインターフェースを介して第２フォーマットの第２データを受け取ることであって、前記第２データの１つまたは複数のフィールドは、前記ヘルスケアメッセージ構造の前記異なるバージョンのうちの少なくとも１つによってサポートされず、前記単一のサービスインターフェースは、インターフェースエンドポイントの個数を最小にするために前記第１データおよび前記第２データの前記受け取ることを可能にする、受け取ることと
    を行わせる命令をその上に格納された有形の機械アクセス可能媒体。

Images