HIPAA ドキュメントへのSNIP 検証の実装


SNIP 検証とは、EDI データがHIPAA に準拠していることを確認するために、EDI ドキュメントに適用することができる一連の制約を指します。したがって、SNIP 検証サポートは、EDI 処理ソリューションを選択する際に考慮すべき重要な要素です。


SNIP 検証を理解するためには、まず初めにEDI 仕様を理解することが大切です。このことを念頭に置きつつ、この記事の3つのセクションを見ていきます。

  • EDI 仕様の概要
  • SNIP 検証レベルの説明
  • CData Arc でSNIP 検証を実装するためのガイド

この記事の最初の2つのセクションは、CData Arc を使用しているユーザーだけでなく、EDI ソリューションを実装しているすべてのユーザーを対象としています。3つ目のセクションは、CData Arc を使用または評価していて、HIPAA への準拠を確認することに関心のあるユーザーのためのリソースとして使用できます。

EDI 仕様

EDI 仕様は、さまざまな企業が共有データ言語と理解を確立できるビジネスドキュメントを作成するためのガイドラインです。EDI ソリューションは、これらのドキュメントをいくぶん厳密に管理するガイドラインを実施できます。より緩やかな適用は、不必要なエラーがスローされるのを防ぎ、より厳格な適用は、将来のデータ処理の問題を未然に防ぎます。

結果としてEDI 仕様だけでは、どのEDI 処理ソリューションが有効または無効なのか、EDI データを考慮すべきなのかを判断することはできません。次のセクションで説明するSNIP 検証レベルでは、EDI 仕様を適用する方法に関する明示的なルールと、（より高いレベルでの）追加の適用ルールが追加されます。

初めにEDI 仕様を理解するには、さまざまな仕様を3つの階層に分割すると便利です。

  • EDI スタンダード
  • バージョン（リリース）
  • ドキュメントタイプ

EDI スタンダード

まず階層の最上位には、「EDI」の傘下に以下を含むいくつかの異なる標準があります。

  • X12（例：ANSI X12）
  • EDIFACT
  • TRADACOMS

これらの標準はすべて同じ目的を達成しています。つまり、当事者双方がビジネスデータの解釈方法について合意することを保証しますが、相互運用性はありません。たとえば、X12 標準に準拠するドキュメントは、有効なEDIFACT ドキュメントとは限りません。

バージョン

それぞれのEDI 標準には、複数のバージョンがあります。新たなバージョンは、標準によって定義されたルールのアップデートに合わせてリリースされます。EDI 交換の当事者は、使用するEDI 標準（X12 など）とその標準内のバージョンの両方に同意する必要があります。

新しいバージョンでリリースされるアップデートは、通常インクリメンタルであるため、各標準のコア要素は、それぞれのバージョンに関わらず同じです。X12 ドキュメントは、異なるバージョンの標準を使用している場合でも、他方のX12 ドキュメントと同じように見えます。ただし、EDI データによっては異なるバージョンを使用した際に、互いに理解できない場合があります。

以下は、X12 バージョンの一般的な例です。

  • 00401
  • 00403
  • 00501

以下は、EDIFACT バージョンの一般的な例です。

  • D96A
  • D96B
  • D97A
  • D97B

ドキュメントタイプ

各標準のそれぞれのバージョンは、ドキュメントタイプのセットを定義します。各ドキュメントタイプは、特定のビジネス交換を念頭に置いて設計されています。たとえば、発注書ドキュメントは、ヘルスケア登録申請ドキュメントとは異なる一連の規則によって管理されます。

それぞれのドキュメントタイプは、個々のスキーマファイルを介して定義されます。スキーマファイルには、個々のEDI セグメント / 要素の予想される数と順序に関する情報が含まれています。各バージョンには、ドキュメント固有のスキーマに加えて、すべてのドキュメントタイプに適用可能なセグメント / 要素に関する情報（特定の要素のための可能な値のセットなど）を含む一般的なスキーマファイルがあります。

したがって、二者がEDI 取引関係を設定するには、EDI 標準、その標準内のバージョン、およびデータ交換に関連する特定のドキュメントタイプ（スキーマ）について合意する必要があります。

SNIP 検証

SNIP 検証は、前のセクションでも触れたスキーマに関連するデータ検証の異なる7つのレベルを説明します。各レベル（タイプ）によって、ドキュメントのデータ制約の厳格さが増します。タイプは累積型であるため、SNIP 検証タイプ4 を適用するには、タイプ3、2、および1 内のルールも適用する必要があります。

EDI 処理ソリューションにSNIP 検証を追加すると、EDI ドキュメントがEDI 標準で定義されたスキーマにどの程度準拠する必要があるかを明示的に判断するために役立ちます。さらに、より高いレベルのSNIP 検証により、EDI ドキュメントに含まれるデータが、HIPAA 準拠のEDI ソリューションなどの機密性の高い、または規制された環境での使用に対して有効であることを確認できます。このセクションには、SNIP 検証タイプによって設定される制約の概要についての説明が含まれています。

SNIP Type 1

SNIP Type 1 は、EDI データの基本的な構文の整合性を検証します。これには、有効なEDI セグメントのみがドキュメントに表示され、EDI スキーマで定義された順序に従って表示されるという要件が含まれます。

Type 1 だけでは、EDI ドキュメントスキーマによってすでに課せられている制約に追加の制約は課せられません。EDI の正常な解析には、これらの制約を適用する必要があります。したがって、すべてのEDI 処理ソリューションは、デフォルトでSNIP Type 1 をサポートする必要があります。

SNIP Type 2

SNIP Type 2 は、EDI セグメント、要素、および修飾子がドキュメントに表示される回数を検証します。これには、必要なセグメント / 要素が存在すること、および繰り返されるセグメントの繰り返し回数が許容範囲内にあることの確認が含まれます。

Type 2 はType 1 と同様に、EDI ドキュメント・スキーマで定義されたルールを適用しますが、これらのルールはEDI データの解析に必ずしも必要ではありません。緩やかなEDI 処理ソリューションは、デフォルトでType 2 検証を実施しない場合があります。

SNIP Type 3

SNIP Type 3 は、各請求明細の合計が請求金額の合計に等しいことを検証します。Type 3 では、SNIP 検証が単純なEDI ドキュメントスキーマに対するEDI セグメントの構造の検証から、これらのセグメント内のデータコンテンツの検証へと進みます。請求の合計が正しいと確認することは、問題になる財務上の矛盾を防止するために役立ちます。

Type 3 は、SNIP 検証をHIPAA の対象となるEDI ドキュメントを処理する目的で実装していないEDI 処理ソリューションではサポートされない可能性があります。

SNIP Type 4

SNIP Type 4 は、セグメント間の値の関係を検証します。要素A の値が「X」の場合、要素B の値は「Y」または「Z」である必要があります。Type 4 の検証により、EDI ドキュメント内のデータがEDI スキーマに関して有効であるだけでなく、同じドキュメント内の他の値に対しても有効であることが保証されます。

Type 4 は、Type 3 と同様に、一般的なEDI 処理ソリューションではサポートされていない可能性が高いヘルスケア分野固有のデータ検証を必要とします。さらに、Type 4 の検証に関連する特定のコードとif-then の関係は、ドキュメントごと、および実装ごとに異なる場合があります。

SNIP Type 5

SNIP Type 5 は、HIPAA が受け入れる範囲内の値について特定のコードセットを検証します。一部のEDI フィールドにはコード値が含まれており、HIPAA 標準では特定のコードセットのみが有効です。SNIP Type 5 は、コードフィールドにこれらの標準で認識されるコードが含まれていることを確認します。

以下は、受け入れられるコードのセットを定義するHIPAA 標準の例です。

  • NDC（National Drug Code）コード
  • ICD（International Statistical Classification of Diseases and Related Health Problems）コード
  • CPT（Current Procedural Terminology）コード

Type 5 の検証では、EDI データを外部リソースと相互参照する必要があるため、実装には、これらの外部リソースの知識と、これらのリソースをEDI 処理ソリューションに提供するための追加構成の両方が必要です。

SNIP Type 6

SNIP Type 6 は、請求データレコードを作成するときに、ヘルスケアサービスの違いが考慮されることを検証します。たとえば、EDI ドキュメントがサイキアトリックサービスではなくカイロプラクティックサービスに関連している場合、EDI セグメント（レコード）の要件が異なる場合があります。Type 6 検証では、EDI データの構造が、EDI ドキュメントが対象とするサービスと一致していることを確認します。

Type 6 の検証には、より具体的なデータ値の検証が含まれ、EDI 処理ソリューションでこれらの検証ルールを実装するためには、追加作業が必要になる場合があります。

SNIP Type 7

SNIP Type 7 は、特定のEDI 取引先に対する特別な要件を検証します。

  • Medicare
  • Medicaid
  • Indian Health

SNIP Type 7 のルールはこれらの特定の取引先のための実装ガイドに記載されており、民間保険会社などのほかの取引先とEDI ドキュメントを交換する場合には関係ありません。

CData Arc でのSNIP 検証の実装

Arc のEDI 処理機能には、より低いレベルのSNIP 検証サポートが組み込まれています。より高いレベルのSNIP 検証では、データ処理の追加ステップとして検証コネクタを構成する必要があり、最高レベルのSNIP 検証では、検証ロジックを実装するためのスクリプトが必要になる場合があります。

このセクションでは、Arc 内でSNIP 検証の各レベルを達成する方法について説明します。これらの各レベルを説明する前に、Arc の新規ユーザーや予期されるユーザーには、アプリケーションがEDI 処理をどのように扱うかを説明すると便利です。

Arc のEDI コネクタ

Arc には、さまざまなEDI フォーマットをXML に変換したり、XML からEDI ドキュメントを生成したりする多くのEDI コネクタが含まれています。EDI データをXML に変換するこのプロセスは、統合フローで中間データフォーマットとしてXML を使用するというArc の一般的なアプローチに従います。XML を共通のデータフォーマットとして使用すると、XML Map コネクタを介したデータ変換が合理化されるだけでなく、異なるデータソースやフォーマットのデータをArc で統合することもできます。したがって、多くの場合、データはフローの初期にXML に変換され、途中で変換されてから、フローの最後に向かってXML から何らかのターゲットフォーマットに変換されます。

EDI コネクタでEDI データをXML に変換する際、Arc は適切なEDI ドキュメントスキーマに対してEDI 構造の検証も実行します。デフォルトでは、この検証には、EDI をXML に正しく変換するために必要なもの（セグメントの順序付け、セグメントの開閉など）のみが含まれます。EDI コネクタには、「Advanced」設定タブにSNIP 検証と呼ばれる設定もあります。SNIP 検証を有効にすると、EDI データの検証要件が厳しくなります。

以下のサブセクションで説明するように、EDI コネクタでSNIP 検証設定を有効にするだけで、最初の3つのレベルのSNIP 検証を保証できます。

より高いレベルのSNIP 検証を実現するには、追加のValidate コネクタまたはカスタムArcScript が必要になる場合があります。フローへのこれらの追加はEDI コネクタの後に行われるため、検証されるデータはXML になります（EDI コネクターはすでにEDI をXML に変換しています）。この追加の検証の詳細は、以下のとおりです。

SNIP Type 1 の実装

Arc は、組み込みのEDI 処理によってSNIP Type 1 を自動的に実装します。設定を有効にする必要はなく、さらなる手順を実行する必要もありません。

SNIP Type 2 & 3 の実装

SNIP Type 2 & 3 検証を確実に行うには、EDI をXML に変換するEDI コネクタの「Advanced」タブでSNIP 検証設定を有効にする必要があります。さらなる手順は必要ありません。

SNIP Type 4 の実装

SNIP Type 4 検証では、インバウンドEDI データを処理するフローにValidate コネクタを追加する必要があります。Validate コネクタは、Type 4 ロジックを実装するように構成できます。要素A に値「X」が含まれる場合、要素B は「Y」や「Z」などの値のセットの一つである必要があります。Validate コネクタは、XML 入力を想定しているため、受信EDI ファイルをXML に変換するEDI コネクタの後に追加する必要があります。

Validate コネクタでこのロジックを正しく実装するには、関連するEDI データをある程度理解する必要があります。ユーザーは、この「if A, then B」関係を持つ特定のEDI 要素に精通しており、翻訳されたXML 内でこれらの要素へのxpath をトレースできる必要があります。

xpath とEDI 要素間の関係がわかれば、これらの要件をArc フローに実装するルールを使用してValidate コネクタを構成できます。これらのルールは、両方のxpaths の値が期待されるセット内にあることをチェックし、演算子「not equals」、「regex match」、ブール演算子「OR」を使用して「if-then」ロジックを実行します。以下はこのロジックの実装例です。

例

例としてシンプルなType 4 要件を取り上げます。要素A が値「IL」を持つ場合、要素B は、必ず「40」「41」「42」のいずれかになります。

Validate コネクタにこれを実装する場合、以下の2つのステップを考慮してください。

  1. 関連する値が保持されているxpaths を検索する
  2. 「equals」、「regex match」、「OR」を使用してif-then 関係を実装します。

この例のために、2つの関連要素への単純なxpath を考えます。

  • /Items/path/elementA
  • /Items/path/elementB

これらは、Validate コネクタルールの「xpath」フィールドで使用されます。

次に、これらの要素間の論理的な関係について考えます。要素A に特定の値（「IL」）がある場合、要素B には特定の値（40~42 の範囲の数値）が必要です。この関係を別の言葉で説明すると、次のようになります：要素A が特定の値（「IL」）ではない、もしくは要素B が必ず特定の値（40~42）を持つ。この関係の定式化は、「OR」を介して接続されたValidate コネクタの2つのルールで表すことができます。

elementA notequals 'IL'
OR
elementB regex matches (40|41|42)

Validate コネクタでこの関係を実装し、要素A と要素B の両方のxpaths を理解するには、次のようにします。

検証ルールに対するこのアプローチは、「Type 4」の検証関係を備える必要がある要素の各ペアに対して実装できます。

SNIP Type 5-7 の実装

より高いレベルのSNIP 検証では、要件を実装するためにカスタムArcScript を作成する必要があります。このセクションでは、各検証レベルでスクリプトを開始するために必要な概念の概要を説明します。実装スクリプトに関する具体的なヘルプは、サポートチームにいつでもお問い合わせください。

検証に関連する一般的なスクリプトの概念

ArcScript は、EDI ファイルをXML に変換した後に適用するのが最適です。これには、指定したxpath でXML データをループするxmlDOMSearch などの操作が含まれます。したがって、推奨されるArc フローデザインは、EDI ドキュメントをXML に変換するEDI コネクタの直後にScript コネクタを配置し、適切な検証スクリプトを使用してScript コネクタを設定します。

xmlDOMSearch 内では、xpath フォーマッタは指定されたxpath (xmlDOMSearch 呼び出しで指定されたxpathからの相対パス) で値を取得できます。このフォーマッタの使用例は、このサブセクションの下部にあります。

arc:set キーワードは、属性（変数）に値を格納するために使われます。arc:if キーワードを使用することで、条件付きロジックを使用できます。arc:select キーワードは、ケースの指定されたセット内に値があるかどうかを確認するために使用できます。

検証スクリプトが検証に失敗したEDI データを検出したときには、エラーをスローする必要があります。ArcScript でのエラーは、arc:throw キーワードによってスローされます。

検証ルールのスクリプト作成に必要なロジックの種類を表すサンプルArcScript のスニペットを次に示します。

<!-- set input parameters of xmlDOMSearch -->
<arc:set attr="input.uri" value="[FilePath]" />
<arc:set attr="input.xpath" value="/Interchange/FunctionalGroup/TransactionSet/TX-00501-837">

<!-- loop over the input file at the given xpath -->
<arc:call op="xmlDOMSearch" in="input">
  <!-- retrieve specific values from the XML; elementA and elementB -->
  <arc:set attr="elementA" value="[xpath('HLLoop1/NM1Loop2/NM1/NM101')]" />
  <arc:set attr="elementB" value="[xpath('HLLoop1/NM1Loop2/NM1/NM103')]" />

  <!-- check elementA against a list of possible values with a 'select' statement -->
  <arc:select value="[elementA]">

    <!-- for each possible elementA value, see if elementB has a valid value -->
    <arc:case value="IL">
      <arc:if exp="[elementB | notequals(40)] && [elementB | notequals(41)] && [elementB | notequals(42)]">
        <!-- invalid value detected, throw an error -->
        <arc:throw code=1 desc="ElementB had an invalid value of [elementB]." />
      </arc:if>
    </arc:case>
    <arc:case value="PR">
      <arc:if exp="[elementB | notequals(43)] && [elementB | notequals(44)]">
        <!-- invalid value detected, throw an error -->
        <arc:throw code=1 desc="ElementB had an invalid value of [elementB]." />
      </arc:if>
    </arc:case>
  </arc:select>
</arc:call>

SNIP Type 5 スクリプト

SNIP Type 5 では、可能な値の範囲を確認するために外部リソースを読み取る必要があります。ユーザーは、これらの外部リソースを取得するプロセスに責任があります。

取得した値は、特定のリソースタイプに応じてArcScript のさまざまな機能を使用し、これらのリソースから読み取ることができます。

  • データベースは、dbQuery 操作でクエリできます。
  • テキストファイルは、fileRead 操作で読み取ることができます。
  • CSV ファイルは、csvListRecords 操作で読み取ることができます。

外部機関からの値が読み取られると、これらの制限事項を実装するプロセスは、前のサブセクションで説明したスニペットと同様の構文に従います。

SNIP Type 6 スクリプト

SNIP Type 6 では、EDI ファイルにリストされているサービスに基づいて特定の値の関係を検証する必要があります。この検証のスクリプト作成アプローチは、他のデータ検証スクリプトと同じ原則に従いますが、個々のデータ要素の検証時に使用するヘルスケアサービスの値を最初に取得するという追加手順があります。

これらのスクリプトは、前述の「arc:select」および「arc:if」と同じ種類のアプローチに従う必要がありますが、実際のロジックツリーには、より多くのレベルと要素が含まれる場合があります。

SNIP Type 7 スクリプト

SNIP Type 7 は、外部EDI 取引先からの直接入力が必要です。したがって、これらのルールの実装の詳細はパートナーによって異なりますが、同じ条件付きロジックツール（「arc:select」「arc:if」）を使用してこれらのチェックを実装する必要があります。

結論

SNIP 検証は、ヘルスケアドキュメントを処理するEDI 処理ソリューションの重要な考慮事項であり、HIPAA の制限の対象となります。Arc には、SNIP 検証のベースラインレベルの簡単なワンクリックサポートが含まれており、Validate コネクタとArcScript を提供して、より具体的な検証ルールを実装します。

独自の検証コネクタの構成または検証スクリプトの作成については、サポートチームにお問い合わせください。



Ready to get started?

Use CData Arc's free 30-day trial to start building your own custom workflows today:

Download Now