JP2017513080A - 動的トランザクションデータストリーミングシステム及び方法 - 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. 前記医療取引データストリームは、ＡＳＣ Ｘ１２ ５０１０標準の区切りフォーマットを使用する、
    請求項１９に記載の方法。

Images