翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
$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パラメータをサポートしています。
| パラメータ | タイプ | 必須 | 説明 |
|---|---|---|---|
|
患者 |
はい |
一致するメンバーの属性情報を含む患者リソース。 |
|
カバレッジ |
はい |
既存のレコードとの照合に使用されるカバレッジリソース。 |
|
カバレッジ |
いいえ |
一致するプロセス中にリンクされるカバレッジリソース。 |
|
同意 |
はい |
認可のための同意リソースも保存されます。これは、同意を必要としない個々の |
一括メンバー一致ジョブを送信する POST リクエスト
次の例は、一括メンバー一致ジョブを送信する POST リクエストを示しています。各メンバーは、必要な MemberPatient、CoverageToMatch、および 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 リクエストで送信されたすべてのメンバーは、シーケンシャルパイプラインを通じて評価されます。各ステップの結果によって、メンバーを配置する出力グループが決まります。
構造検証 — MemberBundle は必要なプロファイルに準拠していますか? 失敗時: エラー (どのグループでもない)。
患者のマッチング — HealthLake は、送信された属性に一致する患者を見つけることができますか? 失敗の場合: NonMatchedMembers。
カバレッジの確認 — HealthLake は、有効な CoverageToMatch を持つ 1 人の患者だけに絞り込むことができますか? 失敗の場合: NonMatchedMembers。
同意の評価 — 送信された同意は、現在受け入れられますか? (ステータス = アクティブ、期間は現在の日付をカバー、パフォーマーは検証可能)。失敗の場合: ConsentConstrainedMembers。
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で を呼び出しても、削除されたメンバーはエクスポート結果に表示されることがあります。
ワークフロー:
POST [base]/Group/{id}/$member-remove— メンバーを非アクティブにするPUT [base]/Group/{id}— グループのステータスを「最終」に更新する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 がそれを使用する方法 | 次の場合、検証は失敗します。 |
|---|---|---|
| デモグラフィック検索 | Missing (見つからない) |
| デモグラフィック検索 | 欠落 (少なくとも 1 つ必須) |
| デモグラフィック検索 | Missing (見つからない) |
| 人口統計検索。存在しない場合は、Birth Sex 拡張機能を使用 | 性別も性別も存在しない (hrex-pat-1) |
| 存在する場合は検索に含まれ、信頼度が向上 | 失敗を引き起こさない (オプション) |
CoverageToMatch / CoverageToLink
| フィールド | HealthLake がそれを使用する方法 | 次の場合、検証は失敗します。 |
|---|---|---|
| カバレッジが実行可能であることを確認する | Missing (見つからない) |
| 患者候補にカバレッジをリンクします | Missing (見つからない) |
| 複数の候補が存在する場合のあいまいさの排除 | 見つからない、または複数の支払者 |
| サブスクライバーと受取人の関係を確認します | Missing (見つからない) |
| 主な曖昧さ解消キー | どちらでもない |
同意
| フィールド | HealthLake がそれを使用する方法 | 次の場合、検証は失敗します。 |
|---|---|---|
| 同意範囲が患者プライバシーであることを確認する | 患者/プライベートコードがないか、ない |
| 開示分類を確認します | Missing (見つからない) |
| 同意サブジェクトを識別します | Missing (見つからない) |
| 同意するユーザーを特定します。 | Missing (見つからない) |
| 同意ソースを文書化します。 | Missing (見つからない) |
| データ共有の範囲を決定します | #regular または #sensitive で終わる URI がないか、URI がありません |
| HRex 同意プロファイルごとに「許可」である必要があります | 「許可」がないかないか (「拒否」を含む) |
| 同意に制約のあるチェックのためにステップ 4 で評価 | 開始/終了がないか、ない |
| ステップ 4 で評価 (ステップ 1 ではない) | ステップ 1 の失敗を引き起こさない — HealthLake は有効なステータスを受け入れ、ステップ 4 で評価します |
注記
HRex 同意プロファイルは、固定値が「アクティブ」のステータスを定義します。HealthLake は、非アクティブな同意が包括的な検証拒否ではなく意味のある分類 (ConsentConstrainedMembers) を受け取るように、この制約を意図的に緩和します。
マッチング動作
患者検索 (ステップ 2) — HealthLake は、
name.family+name.given(完全、大文字と小文字を区別しない)birthDate、 (完全)、gender(性別がない場合に使用される完全、性別を使用)、およびidentifier(存在する場合、オプション) を使用して検索します。カバレッジのあいまいさの排除 (ステップ 3) — 複数の患者候補が見つかった場合、
CoverageToMatchを使用して 1 つに絞り込みます。またはsubscriberIdidentifier(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: サーバー側の処理エラーがあるメンバーの数。
関連の オペレーション
$member-match HealthLake の オペレーション — 個々のメンバーマッチングオペレーション。
HealthLake の FHIR R4 $davinci-data-exportオペレーション — グループリソースを使用した一括データエクスポート。
HealthLake $operationsの FHIR R4 — サポートされているオペレーションの完全なリスト。