Penggunaan Parameter yang didukung Permintaan POST untuk mengirimkan pekerjaan kecocokan anggota massal Menyelesaikan respon pekerjaan dengan output Bagaimana HealthLake mengklasifikasikan anggota ke dalam Grup keluaran Perilaku pencocokan cakupan Persetujuan penanganan referensi pemain Sumber daya Grup Keluaran Consent-Patient keterkaitan Apa yang disimpan vs. apa yang sementara Integrasi dengan $davinci-data-export Karakteristik kinerja Otorisasi Aturan validasi Perilaku pencocokan Penanganan kesalahan Operasi terkait

`Operasi $bulk-member-match` untuk HealthLake

AWS HealthLake mendukung $bulk-member-match operasi untuk memproses beberapa permintaan kecocokan anggota secara asinkron. Operasi ini memungkinkan organisasi perawatan kesehatan untuk secara efisien mencocokkan ratusan pengidentifikasi unik anggota di berbagai sistem perawatan kesehatan menggunakan informasi demografis dan cakupan dalam satu permintaan massal. Kemampuan ini sangat penting untuk pertukaran data pembayar-ke-pembayar skala besar, transisi anggota, dan persyaratan kepatuhan CMS dan mengikuti spesifikasi FHIR.

catatan

$bulk-member-matchOperasi ini didasarkan pada spesifikasi FHIR yang mendasari yang saat ini eksperimental dan dapat berubah. Seiring berkembangnya spesifikasi, perilaku dan antarmuka API ini akan diperbarui sesuai dengan itu. Pengembang disarankan untuk memantau catatan HealthLake rilis AWS dan pembaruan spesifikasi FHIR yang relevan agar tetap mendapat informasi tentang perubahan apa pun yang dapat memengaruhi integrasi mereka.

Operasi ini sangat berguna ketika Anda perlu:

Memproses pencocokan anggota pada skala selama periode pendaftaran terbuka
Memfasilitasi transisi anggota massal antar pembayar
Mendukung persyaratan pertukaran data kepatuhan CMS skala besar
Secara efisien mencocokkan kelompok anggota di seluruh jaringan perawatan kesehatan
Minimalkan panggilan API dan tingkatkan efisiensi operasional untuk skenario pencocokan volume tinggi

Penggunaan

$bulk-member-matchOperasi ini adalah operasi asinkron yang dipanggil pada sumber daya Grup menggunakan metode POST:


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

Setelah mengirimkan permintaan kecocokan massal, Anda dapat melakukan polling status pekerjaan menggunakan:


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

Parameter yang didukung

HealthLake mendukung $bulk-member-match parameter FHIR berikut:

Parameter	Tipe	Diperlukan	Deskripsi
`MemberPatient`	Pasien	Ya	Sumber daya pasien yang berisi informasi demografis agar anggota dicocokkan.
`CoverageToMatch`	Cakupan	Ya	Sumber daya cakupan yang akan digunakan untuk pencocokan dengan catatan yang ada.
`CoverageToLink`	Cakupan	Tidak	Sumber daya cakupan yang akan ditautkan selama proses pencocokan.
`Consent`	Persetujuan	Ya	Sumber daya persetujuan untuk tujuan otorisasi juga disimpan. Ini berbeda dengan `$member-match` operasi individu di mana Persetujuan tidak diperlukan.

Permintaan POST untuk mengirimkan pekerjaan kecocokan anggota massal

Contoh berikut menunjukkan permintaan POST untuk mengirimkan pekerjaan kecocokan anggota massal. Setiap anggota dibungkus dalam MemberBundle parameter yang berisi yang diperlukanMemberPatient,CoverageToMatch, dan Consent sumber daya, bersama dengan opsionalCoverageToLink.


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"
              }
            ]
          }
        }
      ]
    }
  ]
}

Menyelesaikan respon pekerjaan dengan output

Ketika pekerjaan selesai, respons mencakup metadata pekerjaan dan sumber daya Parameter FHIR yang berisi tiga sumber daya Grup yang mengkategorikan hasil pencocokan.


{
  "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"
              }
            }
          ]
        }
      }
    ]
  }
}

Bagaimana HealthLake mengklasifikasikan anggota ke dalam Grup keluaran

Setiap anggota yang diajukan dalam $bulk-member-match permintaan dievaluasi melalui pipeline berurutan. Hasil dari setiap langkah menentukan keluaran Grup mana anggota ditempatkan.

Validasi struktural — Apakah MemberBundle sesuai dengan profil yang diperlukan? Pada kegagalan: Kesalahan (tidak di Grup mana pun).
Pencocokan pasien — Dapatkah HealthLake menemukan pasien yang cocok dengan demografi yang dikirimkan? Pada kegagalan: NonMatchedMembers.
Konfirmasi cakupan — Dapat HealthLake mempersempit tepat satu pasien dengan valid CoverageToMatch? Pada kegagalan: NonMatchedMembers.
Evaluasi persetujuan — Apakah Persetujuan yang diajukan terhormat saat ini? (status = aktif, periode mencakup tanggal saat ini, pemain dapat divalidasi). Pada kegagalan: ConsentConstrainedMembers.
Sukses — Semua cek lulus. Persetujuan disimpan di datastore. Anggota ditempatkan di MatchedMembers.

Prinsip utama: Anggota hanya dapat muncul di satu tujuan. Langkah gagal pertama menentukan penempatan. Anggota yang gagal Langkah 2 atau 3 tidak pernah ditempatkan di ConsentConstrainedMembers - Grup tersebut khusus untuk anggota yang berhasil dicocokkan tetapi yang persetujuannya tidak dapat dihormati.

Rincian evaluasi persetujuan (Langkah 4):

Periksa 1 — Status persetujuan: Apakah Consent.status sama dengan “aktif”? Jika tidak → ConsentConstrainedMembers.
Cek 2 — Periode ketentuan: Apakah provision.period mencakup tanggal saat ini? Jika tanggal saat ini sebelum period.start atau sesudah period.end → ConsentConstrainedMembers.
Periksa 3 - Validasi pemain: Dapatkah Consent.performer referensi divalidasi? Jika sumber daya yang direferensikan tidak ditemukan di datastore atau tidak terkait dengan pasien yang cocok →. ConsentConstrainedMembers

Semua cek harus lolos agar anggota ditempatkan MatchedMembers dan agar Persetujuan disimpan.

Perilaku pencocokan cakupan

Selama pencocokan anggota, hanya CoverageToMatch divalidasi terhadap datastore pembayar yang merespons. CoverageToLinkmilik new/requesting pembayar dan tidak divalidasi terhadap datastore pembayar lama. Termasuk CoverageToLink dalam permintaan tidak akan mempengaruhi hasil pencocokan.

Setiap kombinasi Pasien+Cakupan dalam permintaan diproses secara independen. Pasien yang sama dapat diajukan beberapa kali dengan rencana pertanggungan yang berbeda, dan setiap entri menerima hasilnya sendiri berdasarkan cakupan spesifiknya.

Persetujuan penanganan referensi pemain

Pembayar baru dapat mengirim referensi pasien sementara atau lokal di Consent.performer (misalnya, referensi yang sama digunakan dalamConsent.patient). HealthLake menyelesaikan referensi ini secara otomatis:

Jika Consent.performer berisi referensi lokal yang sama sepertiConsent.patient, HealthLake gantilah dengan referensi pasien yang cocok aktual setelah pencocokan berhasil.
HealthLake mendukung referensi pemain tipe Pasien, RelatedPerson, Praktisi PractitionerRole, dan Organisasi (referensi langsung dan referensi pengidentifikasi logis).
Jika validasi pemain gagal (sumber daya tidak ditemukan atau tidak terkait dengan pasien yang cocok), anggota ditempatkan di ConsentConstrainedMembers alih-alih mengembalikan kesalahan.

Sumber daya Grup Keluaran

Pekerjaan yang diselesaikan mengembalikan sumber daya Parameter yang berisi tiga sumber daya Grup:

MatchedMembers Kelompok: Berisi referensi Pasien untuk semua anggota yang berhasil dicocokkan yang persetujuannya aktif dan valid pada saat permintaan. Sumber daya Persetujuan dibuat dan disimpan di datastore untuk setiap anggota yang cocok. Grup ini dipakai di datastore dan dapat digunakan langsung dengan. $davinci-data-export
NonMatchedMembers Kelompok: Berisi referensi ke anggota di mana tidak ada kecocokan unik yang ditemukan. Anggota ditempatkan di sini ketika tidak ada pasien di datastore yang cocok dengan demografi yang disediakan, tidak ada cakupan yang valid untuk kandidat pasien yang cocok, atau beberapa pasien yang cocok dengan demografi dan beberapa memiliki cakupan yang valid (ambigu).
ConsentConstrainedMembers Kelompok: Berisi referensi Pasien untuk anggota yang berhasil dicocokkan (demografi dan cakupan dikonfirmasi) tetapi persetujuannya tidak dapat dihormati pada saat permintaan. Sumber daya Persetujuan tidak disimpan untuk anggota yang dibatasi persetujuan. Identitas anggota yang cocok (MemberIdentifier dan MemberId) masih disertakan sehingga pembayar yang meminta tahu siapa yang dibatasi.

Group.quantityBidang berisi jumlah total anggota di masing-masing kelompok masing-masing.

Referensi anggota grup:

Group.member.entity.reference— Untuk MatchedMembers dan ConsentConstrainedMembers, berisi ID Pasien dari anggota yang cocok dalam sistem pembayar yang merespons. Untuk NonMatchedMembers, referensi yang terkandung masukan Pasien.
Group.member.entity.extension (base-ext-match-parameters)— Berisi ID Pasien dari permintaan input asli (ID yang dikirimkan oleh pembayar yang meminta, berasal dari, Patient.idCoverage.beneficiary.reference, atauConsent.patient.reference).

penting

Sumber daya Persetujuan yang disimpan mempertahankan referensi pasien persis seperti yang dikirimkan oleh pembayar yang meminta. HealthLake tidak secara otomatis memperbarui bidang pasien Persetujuan untuk menunjuk ke Pasien yang cocok di datastore penerima.

Untuk menautkan Persetujuan yang disimpan ke Pasien yang cocok, gunakan output pekerjaan: setiap anggota dalam MatchedMembers Grup memiliki member.entity.reference penunjuk ke Pasien yang cocok dan member.entity.extension (base-ext-match-parameters) menunjuk ke masukan yang terkandung Pasien. Cross-reference ini dengan bidang pasien Persetujuan untuk membangun pemetaan di lapisan aplikasi Anda.

Apa yang disimpan vs. apa yang sementara

Tabel berikut mendokumentasikan apa yang HealthLake bertahan pada datastore selama $bulk-member-match pemrosesan dan apa yang hanya ada dalam respons pekerjaan:

Sumber daya	Disimpan?	Dapat ditanyai melalui REST?	Catatan
MemberPatient (masukan)	Tidak	Tidak	Digunakan hanya untuk pencocokan; tidak bertahan
CoverageToMatch (masukan)	Tidak	Tidak	Digunakan hanya untuk konfirmasi pertanggungan
CoverageToLink (masukan)	Tidak	Tidak	Tidak divalidasi terhadap datastore; milik pembayar baru
Persetujuan (anggota yang cocok)	Ya	Ya — DAPATKAN [dasar] /Persetujuan/ {id}	Disimpan sebagai-diterima dari pembayar yang meminta
Persetujuan (anggota terbatas)	Tidak	Tidak	Tidak disimpan. Identitas anggota masih termasuk dalam tanggapan.
MatchedMembers Grup (keluaran)	Ya	Ya — GET [base] /Group/ {id}	Instantiated; dapat digunakan dengan $davinci-data-export
NonMatchedMembers Kelompok	Tidak	Tidak	Respon Job saja
ConsentConstrainedMembers Kelompok	Tidak	Tidak	Respon Job saja

Integrasi dengan $davinci-data-export

Sumber daya MatchedMembers Grup yang dikembalikan oleh $bulk-member-match dapat langsung digunakan dengan $davinci-data-export operasi untuk mengambil data anggota massal:


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

Integrasi ini memungkinkan alur kerja yang efisien di mana Anda pertama kali mengidentifikasi anggota yang cocok secara massal, kemudian mengekspor catatan kesehatan lengkap mereka menggunakan sumber daya Grup yang dihasilkan.

Menggunakan $member-remove sebelum ekspor

Jika Anda perlu mengecualikan anggota tertentu dari ekspor setelah pencocokan (misalnya, anggota mencabut persetujuan antara pencocokan dan ekspor), gunakan $member-remove di MatchedMembers Grup.

penting

Menghapus anggota melalui $member-remove menandai anggota sebagai tidak aktif dalam Grup, tetapi $davinci-data-export hanya mengecualikan anggota yang tidak aktif setelah Grup diperbarui ke status “final”. Jika Anda memanggil $davinci-data-export Grup yang masih memiliki status default, anggota yang dihapus mungkin masih muncul di hasil ekspor.

Alur kerja:

POST [base]/Group/{id}/$member-remove— tandai anggota tidak aktif
PUT [base]/Group/{id}— perbarui status Grup ke “final”
POST [base]/Group/{id}/$davinci-data-export— ekspor sekarang tidak termasuk anggota yang dihapus

Karakteristik kinerja

$bulk-member-matchOperasi ini dirancang untuk pemrosesan volume tinggi dan berjalan secara asinkron:

Konkurensi: Maksimum 5 operasi bersamaan per penyimpanan data.
Skalabilitas: Menangani hingga 500 anggota per permintaan (batas muatan 5 MB).
Operasi paralel: Kompatibel dengan operasi impor, ekspor, atau penghapusan massal bersamaan.

Otorisasi

API menggunakan SMART pada protokol otorisasi FHIR dengan cakupan wajib berikut:

system/Patient.read— Diperlukan untuk mencari dan mencocokkan sumber daya pasien.
system/Coverage.read— Diperlukan untuk memvalidasi informasi cakupan.
system/Group.write— Diperlukan untuk membuat sumber daya Grup hasil.
system/Organization.read— Bersyarat, diperlukan jika cakupan referensi organisasi.
system/Practitioner.read— Bersyarat, diperlukan jika cakupan referensi praktisi.
system/PractitionerRole.read— Bersyarat, diperlukan jika cakupan referensi peran praktisi.
system/Consent.write— Bersyarat, diperlukan jika sumber daya persetujuan disediakan.

Operasi ini juga mendukung otorisasi AWS IAM Signature Version 4 (SiGv4) untuk akses terprogram.

Aturan validasi

Aturan validasi berikut diterapkan untuk masing-masing MemberBundle pada Langkah 1. Anggota yang gagal validasi dilaporkan sebagai kesalahan dan tidak muncul di Grup keluaran apa pun.

MemberPatient

Bidang	Bagaimana HealthLake menggunakannya	Kegagalan validasi jika...
`name.family`	Pencarian demografis	Hilang
`name.given`	Pencarian demografis	Hilang (setidaknya satu diperlukan)
`birthDate`	Pencarian demografis	Hilang
`gender`	Pencarian demografis; jika tidak ada, ekstensi Jenis Kelamin Kelahiran digunakan	Baik jenis kelamin maupun Jenis Kelahiran Seks hadir (hrex-pat-1)
`identifier`	Termasuk dalam pencarian saat hadir; meningkatkan kepercayaan diri	Tidak pernah menyebabkan kegagalan (opsional)

CoverageToMatch / CoverageToLink

Bidang	Bagaimana HealthLake menggunakannya	Kegagalan validasi jika...
`status`	Mengonfirmasi cakupan dapat ditindaklanjuti	Hilang
`beneficiary`	Menautkan cakupan ke kandidat pasien	Hilang
`payor`	Disambiguasi ketika ada banyak kandidat	Hilang, atau lebih dari satu pembayar
`relationship`	Mengonfirmasi hubungan pelanggan-penerima	Hilang
`identifier (MB) or subscriberId`	Kunci disambiguasi primer	Tidak ada yang hadir

Bidang	Bagaimana HealthLake menggunakannya	Kegagalan validasi jika...
`scope`	Mengonfirmasi ruang lingkup persetujuan adalah privasi pasien	Hilang atau tidak ada kode privasi pasien
`category`	Mengonfirmasi klasifikasi pengungkapan	Hilang
`patient`	Mengidentifikasi subjek persetujuan	Hilang
`performer`	Mengidentifikasi siapa yang setuju	Hilang
`sourceReference`	Dokumentasikan sumber persetujuan	Hilang
`policy.uri`	Menentukan ruang lingkup berbagi data	Hilang atau URI tidak berakhir di #regular atau #sensitive
`provision.type`	Harus “izin” per profil Persetujuan HRex	Hilang atau tidak “izin” (termasuk “tolak”)
`provision.period`	Dievaluasi pada Langkah 4 untuk pemeriksaan terbatas persetujuan	Hilang atau tidak start/end
`status`	Dievaluasi pada Langkah 4 (BUKAN Langkah 1)	Jangan pernah menyebabkan kegagalan Langkah 1 - HealthLake menerima status yang valid dan mengevaluasi pada Langkah 4

catatan

Profil Persetujuan HRex mendefinisikan status dengan nilai tetap “aktif”. HealthLake sengaja melonggarkan kendala ini sehingga Persetujuan non-aktif menerima klasifikasi yang bermakna (ConsentConstrainedMembers) daripada penolakan validasi menyeluruh.

Perilaku pencocokan

Pencarian pasien (Langkah 2) - HealthLake pencarian menggunakan name.family + name.given (tepat, tidak peka huruf besar/kecil), birthDate (tepat), gender (tepat; Jenis Kelamin Lahir digunakan jika jenis kelamin tidak ada), dan identifier (bila ada, opsional).
Disambiguasi cakupan (Langkah 3) — Ketika beberapa kandidat pasien ditemukan, CoverageToMatch digunakan untuk mempersempit menjadi satu. Cakupan “valid” ketika sumber daya Cakupan aktif ada di datastore yang cocok pada subscriberId atau identifier (tipe MB) DAN. payor
Evaluasi persetujuan (Langkah 4) — Hanya dilakukan setelah pertandingan unik yang sukses. Lihat bagian detail evaluasi persetujuan di atas.

Penanganan kesalahan

Operasi menangani kondisi kesalahan berikut:

400 Permintaan Buruk: Format permintaan tidak valid, parameter yang diperlukan tidak ada, atau muatan melebihi batas ukuran (500 anggota atau 5 MB).
422 Entitas yang Tidak Dapat Diproses: Memproses kesalahan selama eksekusi pekerjaan.

Kesalahan anggota individu: Ketika anggota tertentu gagal untuk memproses, operasi berlanjut dengan anggota yang tersisa dan mencakup rincian kesalahan dalam NonMatchedMembers Grup dengan kode alasan yang sesuai. Misalnya, MemberBundle dengan Pasien yang hilang birthDate parameter akan mengembalikan kesalahan berikut:


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

Detail kesalahan tersedia melalui titik akhir pemungutan suara status dan termasuk:

numberOfMembersWithCustomerError: Hitungan anggota dengan validasi atau kesalahan input.
numberOfMembersWithServerError: Hitungan anggota dengan kesalahan pemrosesan sisi server.

$member-matchoperasi untuk HealthLake— Operasi pencocokan anggota individu.
Operasi FHIR R4 $davinci-data-export untuk HealthLake— Ekspor data massal menggunakan sumber daya Grup.
FHIR $operations R4 untuk HealthLake— Daftar lengkap operasi yang didukung.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

$ bulk-hapus

$confirm-attribution-list

Operasi $bulk-member-match untuk HealthLake

catatan

Penggunaan

Parameter yang didukung

Permintaan POST untuk mengirimkan pekerjaan kecocokan anggota massal

Menyelesaikan respon pekerjaan dengan output

Bagaimana HealthLake mengklasifikasikan anggota ke dalam Grup keluaran

Perilaku pencocokan cakupan

Persetujuan penanganan referensi pemain

Sumber daya Grup Keluaran

Consent-Patient keterkaitan

penting

Apa yang disimpan vs. apa yang sementara

Integrasi dengan $davinci-data-export

Menggunakan $member-remove sebelum ekspor

penting

Karakteristik kinerja

Otorisasi

Aturan validasi

MemberPatient

CoverageToMatch / CoverageToLink

Persetujuan

catatan

Perilaku pencocokan

Penanganan kesalahan

Operasi terkait

`Operasi $bulk-member-match` untuk HealthLake