View a markdown version of this page

$bulk-member-match HealthLake の オペレーション - AWS HealthLake

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

$bulk-member-match HealthLake の オペレーション

AWS HealthLake は、複数のメンバー一致リクエストを非同期的に処理する $bulk-member-matchオペレーションをサポートします。このオペレーションにより、医療組織は、属性とカバレッジ情報を 1 回の一括リクエストで使用して、さまざまな医療システム全体で何百人ものメンバーの一意の識別子を効率的に照合できます。この機能は、大規模なpayer-to-payerデータ交換、メンバー移行、CMS コンプライアンス要件に不可欠であり、FHIR 仕様に従います。

注記

$bulk-member-match オペレーションは、現在実験段階にあり、変更される可能性のある基盤となる FHIR 仕様に基づいています。仕様が進化するにつれて、この API の動作とインターフェイスはそれに応じて更新されます。開発者は、AWS HealthLake リリースノートと関連する FHIR 仕様の更新をモニタリングして、統合に影響を与える可能性のある変更を常に把握することをお勧めします。

このオペレーションは、以下が必要な場合に特に役立ちます。

  • オープン登録期間中に大規模なメンバーマッチングを処理する

  • 支払者間の一括メンバー移行を容易にする

  • 大規模な CMS コンプライアンスデータ交換要件をサポート

  • 医療ネットワーク全体でメンバーコホートを効率的にマッチングする

  • API コールを最小限に抑え、大量のマッチングシナリオの運用効率を向上させる

使用方法

$bulk-member-match オペレーションは、POST メソッドを使用してグループリソースで呼び出される非同期オペレーションです。

POST [base]/Group/$bulk-member-match

一括一致リクエストを送信したら、以下を使用してジョブステータスをポーリングできます。

GET [base]/$bulk-member-match-status/{jobId}

サポートされているパラメータ

HealthLake は、次の FHIR $bulk-member-matchパラメータをサポートしています。

パラメータ タイプ 必須 説明

MemberPatient

患者

はい

一致するメンバーの属性情報を含む患者リソース。

CoverageToMatch

カバレッジ

はい

既存のレコードとの照合に使用されるカバレッジリソース。

CoverageToLink

カバレッジ

いいえ

一致するプロセス中にリンクされるカバレッジリソース。

Consent

同意

はい

認可のための同意リソースも保存されます。これは、同意を必要としない個々の$member-matchオペレーションとは異なります。

一括メンバー一致ジョブを送信する POST リクエスト

次の例は、一括メンバー一致ジョブを送信する POST リクエストを示しています。各メンバーは、必要な MemberPatientCoverageToMatch、および Consentリソースとオプションの を含むMemberBundleパラメータでラップされますCoverageToLink

POST [base]/Group/$bulk-member-match Content-Type: application/fhir+json { "resourceType": "Parameters", "parameter": [ { "name": "MemberBundle", "part": [ { "name": "MemberPatient", "resource": { "resourceType": "Patient", "identifier": [ { "system": "http://example.org/patient-id", "value": "patient-0" } ], "name": [ { "family": "Smith", "given": ["James"] } ], "gender": "male", "birthDate": "1950-01-01" } }, { "name": "CoverageToMatch", "resource": { "resourceType": "Coverage", "status": "active", "identifier": [ { "system": "http://example.org/coverage-id", "value": "cov-0" } ], "subscriberId": "sub-0", "beneficiary": { "reference": "Patient/patient123" }, "relationship": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship", "code": "self" } ] }, "payor": [ { "reference": "Organization/org123" } ] } }, { "name": "Consent", "resource": { "resourceType": "Consent", "status": "active", "scope": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/consentscope", "code": "patient-privacy" } ] }, "category": [ { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "IDSCL" } ] } ], "patient": { "reference": "Patient/patient123" }, "performer": [ { "reference": "Patient/patient123" } ], "sourceReference": { "reference": "http://example.org/DocumentReference/consent-source" }, "policy": [ { "uri": "http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#regular" } ], "provision": { "type": "permit", "period": { "start": "2024-01-01", "end": "2025-12-31" }, "actor": [ { "role": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type", "code": "performer" } ] }, "reference": { "identifier": { "system": "http://hl7.org/fhir/sid/us-npi", "value": "9876543210" }, "display": "Old Health Plan" } }, { "role": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType", "code": "IRCP" } ] }, "reference": { "identifier": { "system": "http://hl7.org/fhir/sid/us-npi", "value": "0123456789" }, "display": "New Health Plan" } } ], "action": [ { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/consentaction", "code": "disclose" } ] } ] } } }, { "name": "CoverageToLink", "resource": { "resourceType": "Coverage", "status": "active", "identifier": [ { "system": "http://example.org/coverage-link-id", "value": "cov-link-0" } ], "subscriberId": "new-sub-0", "beneficiary": { "reference": "Patient/patient123" }, "relationship": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship", "code": "self" } ] }, "payor": [ { "identifier": { "system": "http://hl7.org/fhir/sid/us-npi", "value": "0123456789" }, "display": "New Health Plan" } ] } } ] } ] }

完了したジョブレスポンスと出力

ジョブが完了すると、レスポンスにはジョブメタデータと、一致結果を分類する 3 つのグループリソースを含む FHIR パラメータリソースが含まれます。

{ "datastoreId": "datastoreId", "jobId": "jobId", "status": "COMPLETED", "submittedTime": "2026-03-20T18:45:26.321Z", "numberOfMembers": 3, "numberOfMembersProcessedSuccessfully": 3, "numberOfMembersWithCustomerError": 0, "numberOfMembersWithServerError": 0, "output": { "resourceType": "Parameters", "meta": { "profile": [ "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/pdex-parameters-multi-member-match-bundle-out" ] }, "parameter": [ { "name": "MatchedMembers", "resource": { "resourceType": "Group", "id": "group1", "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Matched members group</div>" }, "contained": [ { "resourceType": "Patient", "id": "1", "identifier": [ { "system": "http://example.org/patient-id", "value": "patient-0" } ], "name": [ { "family": "Smith", "given": ["James"] } ], "gender": "male", "birthDate": "1950-01-01" } ], "type": "person", "actual": true, "code": { "coding": [ { "system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS", "code": "match", "display": "Matched" } ] }, "quantity": 1, "member": [ { "entity": { "extension": [ { "url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters", "valueReference": { "reference": "#1" } } ], "reference": "Patient/patient123" } } ] } }, { "name": "NonMatchedMembers", "resource": { "resourceType": "Group", "id": "Group2", "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Non-matched members group</div>" }, "contained": [ { "resourceType": "Patient", "id": "1", "identifier": [ { "system": "http://example.org/patient-id", "value": "patient-501" } ], "name": [ { "family": "Carter", "given": ["Emily"] } ], "gender": "female", "birthDate": "1985-06-15" } ], "type": "person", "actual": true, "code": { "coding": [ { "system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS", "code": "nomatch", "display": "Not Matched" } ] }, "quantity": 1, "member": [ { "entity": { "extension": [ { "url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters", "valueReference": { "reference": "#1" } } ], "reference": "Patient/patient123" } } ] } }, { "name": "ConsentConstrainedMembers", "resource": { "resourceType": "Group", "id": "group3", "text": { "status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Consent constrained members group</div>" }, "contained": [ { "resourceType": "Patient", "id": "1", "identifier": [ { "system": "http://example.org/patient-id", "value": "patient-502" } ], "name": [ { "family": "Nguyen", "given": ["David"] } ], "gender": "male", "birthDate": "1972-11-22" } ], "type": "person", "actual": true, "code": { "coding": [ { "system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS", "code": "consentconstraint", "display": "Consent Constraint" } ] }, "quantity": 1, "member": [ { "entity": { "extension": [ { "url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters", "valueReference": { "reference": "#1" } } ], "reference": "Patient/123" } } ] } } ] } }

HealthLake がメンバーを出力グループに分類する方法

$bulk-member-match リクエストで送信されたすべてのメンバーは、シーケンシャルパイプラインを通じて評価されます。各ステップの結果によって、メンバーを配置する出力グループが決まります。

  1. 構造検証 — MemberBundle は必要なプロファイルに準拠していますか? 失敗時: エラー (どのグループでもない)。

  2. 患者のマッチング — HealthLake は、送信された属性に一致する患者を見つけることができますか? 失敗の場合: NonMatchedMembers。

  3. カバレッジの確認 — HealthLake は、有効な CoverageToMatch を持つ 1 人の患者だけに絞り込むことができますか? 失敗の場合: NonMatchedMembers。

  4. 同意の評価 — 送信された同意は、現在受け入れられますか? (ステータス = アクティブ、期間は現在の日付をカバー、パフォーマーは検証可能)。失敗の場合: ConsentConstrainedMembers。

  5. Success — すべてのチェックに合格します。データストアに保存された同意。MatchedMembers に配置されたメンバー。

主な原則: メンバーは 1 つの送信先にのみ表示できます。最初の失敗ステップによって配置が決まります。ステップ 2 または 3 に失敗したメンバーはConsentConstrainedMembersに配置されません。そのグループは、正常に一致したが、同意を尊重できないメンバー専用です。

同意評価の詳細 (ステップ 4):

  • チェック 1 — 同意ステータス: 「アクティブ」とConsent.status等しいか? そうでない場合 → ConsentConstrainedMembers。

  • チェック 2 — プロビジョニング期間: 現在の日付をprovision.periodカバーしていますか? 現在の日付が前period.startまたは後の場合 period.end → ConsentConstrainedMembers。

  • チェック 3 — パフォーマーの検証: Consent.performerリファレンスは検証できますか? 参照されたリソースがデータストアで見つからない場合、または一致した患者に関連付けられていない場合 → ConsentConstrainedMembers。

メンバーを MatchedMembers に配置し、同意を保存するには、すべてのチェックに合格する必要があります。

カバレッジマッチングの動作

メンバーのマッチング中、 CoverageToMatchは応答する支払者のデータストアに対してのみ検証されます。 は新規/リクエストする支払者にCoverageToLink属し、古い支払者のデータストアに対して検証されません。リクエストCoverageToLinkに を含めても、一致する結果には影響しません。

リクエストの各患者とカバレッジの組み合わせは個別に処理されます。同じ患者を異なるカバレッジプランで複数回送信でき、各エントリは特定のカバレッジに基づいて独自の結果を受け取ります。

同意パフォーマーのリファレンス処理

新しい支払者は、 で一時的またはローカルな患者参照を送信できます Consent.performer (たとえば、 で使用されているのと同じ参照Consent.patient)。HealthLake はこれらの参照を自動的に解決します。

  • に と同じローカルリファレンスConsent.performerが含まれている場合Consent.patient、HealthLake はマッチングが成功した後、実際に一致した患者リファレンスに置き換えます。

  • HealthLake は、タイプ Patient、RelatedPerson、Practitioner、PractitionerRole、および Organization (直接参照と論理識別子参照の両方) のパフォーマー参照をサポートしています。

  • パフォーマーの検証が失敗した場合 (リソースが見つからないか、一致する患者に関連付けられていない場合)、メンバーはエラーを返すのではなくConsentConstrainedMembers に配置されます。

出力グループのリソース

完了したジョブは、3 つのグループリソースを含む Parameters リソースを返します。

MatchedMembers グループ

リクエスト時に同意がアクティブで有効な、正常に一致したすべてのメンバーに対する患者リファレンスが含まれます。同意リソースは、一致するメンバーごとに作成され、データストアに保存されます。このグループはデータストアでインスタンス化され、 で直接使用できます$davinci-data-export

NonMatchedMembers グループ

一意の一致が見つからなかったメンバーへの参照が含まれます。データストア内のどの患者も指定された属性と一致しない場合、一致する患者候補に有効なカバレッジが存在しない場合、または複数の患者が属性に一致し、複数の患者が有効なカバレッジ (あいまい) を持っている場合、メンバーはここに配置されます。

ConsentConstrainedMembers グループ

正常にマッチングされた (人口統計とカバレッジが確認された) が、リクエスト時に同意を尊重できないメンバーに対する患者リファレンスが含まれます。同意リソースは、同意に制約のあるメンバーには保存されません。一致するメンバー ID (MemberIdentifier と MemberId) は引き続き含まれているため、リクエスト元の支払者は制約されたユーザーを認識します。

Group.quantity フィールドには、それぞれのグループのメンバーの合計数が含まれます。

グループメンバーリファレンス:

  • Group.member.entity.reference — MatchedMembers と ConsentConstrainedMembers の場合、応答する支払者のシステム内の一致したメンバーの患者 ID が含まれます。NonMatchedMembers の場合、 は含まれている入力患者を参照します。

  • Group.member.entity.extension (base-ext-match-parameters) — 元の入力リクエストからの患者 ID (Patient.id、、Coverage.beneficiary.referenceまたは から派生した、リクエスト元の支払者によって送信された ID) が含まれますConsent.patient.reference

重要

保存されている同意リソースは、リクエスト元の支払者から送信されたとおりに、患者リファレンスを保持します。HealthLake は、受信データストア内の一致する患者を指すように、同意の患者フィールドを自動的に更新しません。

保存されている同意を一致する患者にリンクするには、ジョブ出力を使用します。MatchedMembers グループ内の各メンバーには、一致する患者member.entity.referenceを指す と、含まれている入力患者を指す member.entity.extension (base-ext-match-parameters) があります。これらを同意の患者フィールドと相互参照して、アプリケーションレイヤーにマッピングを構築します。

保存されるものと一時的なもの

次の表は、$bulk-member-match処理中に HealthLake がデータストアに保持するものと、ジョブレスポンスにのみ存在するものを示しています。

[リソース] 保存済み? REST 経由でクエリ可能か? 注意事項

MemberPatient (入力)

いいえ

いいえ

マッチングにのみ使用され、永続化されません

CoverageToMatch (入力)

いいえ

いいえ

カバレッジの確認にのみ使用されます

CoverageToLink (入力)

いいえ

いいえ

データストアに対して検証されていません。新しい支払者に属しています

同意 (一致するメンバー)

あり

はい — GET [base]/Consent/{id}

支払者のリクエストから受け取ったとおりに保存されます

同意 (制約のあるメンバー)

いいえ

いいえ

保存されていません。メンバー ID は引き続きレスポンスに含まれます。

MatchedMembers グループ (出力)

あり

はい — GET [base]/Group/{id}

インスタンス化。$davinci-data-export で使用可能

NonMatchedMembers グループ

いいえ

いいえ

ジョブレスポンスのみ

ConsentConstrainedMembers グループ

いいえ

いいえ

ジョブレスポンスのみ

$davinci-data-export との統合

によって返される MatchedMembers Group リソース$bulk-member-matchは、一括メンバーデータを取得する $davinci-data-exportオペレーションで直接使用できます。

POST [base]/Group/{matched-group-id}/$davinci-data-export GET [base]/Group/{matched-group-id}

この統合により、一致したメンバーを最初に一括で識別し、結果のグループリソースを使用して完全なヘルスレコードをエクスポートする効率的なワークフローが可能になります。

エクスポート前に $member-remove を使用する

マッチング後にエクスポートから特定のメンバーを除外する必要がある場合 (たとえば、メンバーがマッチングとエクスポートの間の同意を取り消す場合)、MatchedMembers グループ$member-removeで を使用します。

重要

でメンバーを削除すると、そのメンバーはグループ内で非アクティブとして$member-removeマークされますが、グループがステータス「最終」に更新された後に$davinci-data-exportのみ非アクティブなメンバーを除外します。デフォルトのステータスのままのグループ$davinci-data-exportで を呼び出しても、削除されたメンバーはエクスポート結果に表示されることがあります。

ワークフロー:

  1. POST [base]/Group/{id}/$member-remove — メンバーを非アクティブにする

  2. PUT [base]/Group/{id} — グループのステータスを「最終」に更新する

  3. POST [base]/Group/{id}/$davinci-data-export — エクスポートで削除されたメンバーを除外するようになりました

パフォーマンス特性

$bulk-member-match オペレーションは大量の処理用に設計されており、非同期的に実行されます。

  • 同時実行数: データストアあたり最大 5 回の同時オペレーション。

  • スケーラビリティ: リクエストごとに最大 500 人のメンバーを処理します (5 MB のペイロード制限)。

  • 並列オペレーション: インポート、エクスポート、一括削除の同時オペレーションと互換性があります。

Authorization

API は、以下の必要なスコープで SMART on FHIR 認可プロトコルを使用します。

  • system/Patient.read — 患者リソースを検索して一致させるために必要です。

  • system/Coverage.read — カバレッジ情報を検証するために必要です。

  • system/Group.write — 結果グループリソースを作成するために必要です。

  • system/Organization.read — 条件付き。カバレッジが組織を参照する場合は必須です。

  • system/Practitioner.read — 条件付き、カバレッジが実務者を参照する場合は必須です。

  • system/PractitionerRole.read — 条件付き。カバレッジが実務者ロールを参照する場合は必須です。

  • system/Consent.write — 条件付き。同意リソースが指定されている場合は必須です。

オペレーションは、プログラムによるアクセスの AWS IAM 署名バージョン 4 (SigV4) 認可もサポートしています。

検証ルール

ステップ 1 では、各 MemberBundle に次の検証ルールが適用されます。検証に失敗したメンバーはエラーとして報告され、出力グループには表示されません。

MemberPatient

フィールドHealthLake がそれを使用する方法次の場合、検証は失敗します。

name.family

デモグラフィック検索

Missing (見つからない)

name.given

デモグラフィック検索

欠落 (少なくとも 1 つ必須)

birthDate

デモグラフィック検索

Missing (見つからない)

gender

人口統計検索。存在しない場合は、Birth Sex 拡張機能を使用

性別も性別も存在しない (hrex-pat-1)

identifier

存在する場合は検索に含まれ、信頼度が向上

失敗を引き起こさない (オプション)

CoverageToMatch / CoverageToLink

フィールドHealthLake がそれを使用する方法次の場合、検証は失敗します。

status

カバレッジが実行可能であることを確認する

Missing (見つからない)

beneficiary

患者候補にカバレッジをリンクします

Missing (見つからない)

payor

複数の候補が存在する場合のあいまいさの排除

見つからない、または複数の支払者

relationship

サブスクライバーと受取人の関係を確認します

Missing (見つからない)

identifier (MB) or subscriberId

主な曖昧さ解消キー

どちらでもない

フィールドHealthLake がそれを使用する方法次の場合、検証は失敗します。

scope

同意範囲が患者プライバシーであることを確認する

患者/プライベートコードがないか、ない

category

開示分類を確認します

Missing (見つからない)

patient

同意サブジェクトを識別します

Missing (見つからない)

performer

同意するユーザーを特定します。

Missing (見つからない)

sourceReference

同意ソースを文書化します。

Missing (見つからない)

policy.uri

データ共有の範囲を決定します

#regular または #sensitive で終わる URI がないか、URI がありません

provision.type

HRex 同意プロファイルごとに「許可」である必要があります

「許可」がないかないか (「拒否」を含む)

provision.period

同意に制約のあるチェックのためにステップ 4 で評価

開始/終了がないか、ない

status

ステップ 4 で評価 (ステップ 1 ではない)

ステップ 1 の失敗を引き起こさない — HealthLake は有効なステータスを受け入れ、ステップ 4 で評価します

注記

HRex 同意プロファイルは、固定値が「アクティブ」のステータスを定義します。HealthLake は、非アクティブな同意が包括的な検証拒否ではなく意味のある分類 (ConsentConstrainedMembers) を受け取るように、この制約を意図的に緩和します。

マッチング動作

  • 患者検索 (ステップ 2) — HealthLake は、name.family+ name.given (完全、大文字と小文字を区別しない)birthDate、 (完全)、 gender (性別がない場合に使用される完全、性別を使用)、および identifier (存在する場合、オプション) を使用して検索します。

  • カバレッジのあいまいさの排除 (ステップ 3) — 複数の患者候補が見つかった場合、 CoverageToMatch を使用して 1 つに絞り込みます。または subscriberId identifier (MB タイプ) と に一致するデータストアにアクティブなカバレッジリソースが存在する場合、カバレッジは「有効」になりますpayor

  • 同意評価 (ステップ 4) — 一意の一致が成功した後にのみ実行されます。上記の同意評価の詳細セクションを参照してください。

エラー処理

オペレーションは、次のエラー条件を処理します。

  • 400 不正なリクエスト: 無効なリクエスト形式、必須パラメータの欠落、またはペイロードがサイズ制限 (500 メンバーまたは 5 MB) を超えています。

  • 422 未処理のエンティティ: ジョブ実行中の処理エラー。

  • 個々のメンバーエラー: 特定のメンバーが処理に失敗した場合、オペレーションは残りのメンバーを続行し、適切な理由コードを使用して NonMatchedMembers グループにエラーの詳細を含めます。たとえば、 birthDateパラメータが欠落MemberBundleしている患者がいる は、次のエラーを返します。

    "errors": [ { "memberIndex": 1, "jsonBlob": { "resourceType": "OperationOutcome", "issue": [ { "severity": "error", "code": "invalid", "diagnostics": "MemberPatient.birthDate is required" } ], "statusCode": 400 } } ]

エラーの詳細は、ステータスポーリングエンドポイントを通じて利用でき、以下が含まれます。

  • numberOfMembersWithCustomerError: 検証エラーまたは入力エラーがあるメンバーの数。

  • numberOfMembersWithServerError: サーバー側の処理エラーがあるメンバーの数。