翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
$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}
各リクエストは最大 500 のメンバーをサポートし、最大ペイロードは 5 MB です。
クイックスタート
一括メンバーマッチングを開始するには、次の手順に従います。
Group/$bulk-member-matchオペレーションを使用して MemberBundles で一括一致リクエストを送信します。レスポンスにはジョブ ID が含まれます。ステータスが完了するまで、
$bulk-member-match-statusオペレーションを使用してジョブステータスをポーリングします。完了したジョブレスポンスから
MatchedMembersグループ ID を抽出します。一致するグループの
Group/$davinci-data-exportオペレーションを使用して、臨床データをエクスポートします。
サポートされているパラメータ
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。
同意評価 — 現在の日付
provision.periodは対象ですか? 失敗の場合: ConsentConstrainedMembers。Success — すべてのチェックに合格します。データストアに保存されている同意。MatchedMembers に配置されたメンバー。
主な原則: メンバーは 1 つの送信先にのみ表示できます。最初の失敗ステップによって配置が決まります。ステップ 2 または 3 に失敗したメンバーはConsentConstrainedMembersに配置されません。そのグループは、正常に一致したが、同意を尊重できないメンバー専用です。
同意評価の詳細 (ステップ 4):
プロビジョニング期間: は現在の日付を
provision.periodカバーしていますか? 現在の日付が前period.startまたは後の場合period.end→ ConsentConstrainedMembers。
メンバーを MatchedMembers に配置し、同意を保存するには、すべてのチェックに合格する必要があります。
注記
オペレーションは、 patientフィールドに対してperformer参照を検証しません。親または後見人は、扶養家族に代わって同意できます。
次の表は、同意分類がメンバーの配置を決定する方法を示しています。
| プロビジョニングタイプ | ポリシー URI | ステータス | Period | 結果 |
|---|---|---|---|---|
|
|
| 現在の日付をカバー | MatchedMembers (同意の保存済み) |
|
|
| 現在の日付をカバー | MatchedMembers (同意の保存済み) |
|
|
| 有効期限切れまたは開始されていない | ConsentConstrainedMembers |
| いずれか | すべて | すべて | 400 不正なリクエスト (ステップ 1) |
|
| いずれか | すべて | 400 不正なリクエスト (ステップ 1) |
いずれか | すべて | いいえ | いずれか | 400 不正なリクエスト (ステップ 1) |
カバレッジマッチングの動作
メンバーマッチング中、 CoverageToMatchは応答する支払者のデータストアに対してのみ検証されます。 は新規/リクエストする支払者にCoverageToLink属し、古い支払者のデータストアに対して検証されません。リクエストCoverageToLinkに を含めても、一致する結果には影響しません。
リクエストの各患者とカバレッジの組み合わせは個別に処理されます。異なるカバレッジプランで同じ患者を複数回送信でき、各エントリは特定のカバレッジに基づいて独自の結果を受け取ります。
同意パフォーマーのリファレンス処理
新しい支払者は、 で一時的またはローカルな患者参照を送信できます Consent.performer (たとえば、 で使用されているのと同じ参照Consent.patient)。HealthLake はこれらの参照を自動的に解決します。
に と同じローカルリファレンス
Consent.performerが含まれている場合Consent.patient、HealthLake はマッチングが成功した後、実際に一致した患者リファレンスに置き換えます。HealthLake は、タイプ Patient、RelatedPerson、Practitioner、PractitionerRole、および Organization (直接参照と論理識別子参照の両方) のパフォーマー参照をサポートしています。
performerリファレンスは に対して交差検証されませんpatient。扶養家族に代わって同意する親/後見人は有効であり、メンバーを 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 グループリソース$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 で評価 | 開始/終了がないか、ない |
| レプリケート元とレプリケート先の支払者を識別します。 | HRex プロファイルごとに必要なソースと受信者のアクターがないか、含まれていない |
| 開示アクションを確認します | 「開示」コードがないか、ない |
| HRex IG ごとに「アクティブ」である必要があります | Not "active" — 400 の検証エラーを返します |
注記
HRex IG に従って、 Consent.statusは「アクティブ」に固定されます。HealthLake は、ステップ 1 (構造検証) でこれを適用し、他のステータスが指定されている場合は 400 検証エラーを返します。非アクティブな同意は処理されず、ConsentConstrainedMembersに分類されません。事前に拒否されます。
マッチング動作
患者検索 (ステップ 2) — HealthLake は、
name.family+name.given(完全、大文字と小文字を区別しない)birthDate、 (完全)、gender(性別が存在しない場合は完全、性別が使用される分娩)、およびidentifier(存在する場合はオプション) を使用して検索します。カバレッジのあいまいさの排除 (ステップ 3) — 複数の患者候補が見つかった場合、
CoverageToMatchを使用して 1 つに絞り込みます。subscriberIdまたはidentifier(MB タイプ) に一致するデータストアにアクティブなカバレッジリソースが存在する場合、カバレッジは「有効」になります。同意評価 (ステップ 4) — 一意の一致が成功した後にのみ実行されます。上記の同意評価の詳細セクションを参照してください。
エラー処理
オペレーションは、次のエラー条件を処理します。
400 不正なリクエスト: 無効なリクエスト形式、必須パラメータの欠落、またはペイロードがサイズ制限 (500 メンバーまたは 5 MB) を超えています。
422 未処理のエンティティ: ジョブ実行中の処理エラー。
個々のメンバーエラー: 特定のメンバーが処理に失敗すると、オペレーションは残りのメンバーで続行され、エラーの詳細と適切な理由コードが含まれます。たとえば、患者が
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 — サポートされているオペレーションの完全なリスト。