AWS healthlake documentation change
Summary
Updated payload description, restructured operational steps, and reformatted consent classification rules into a table for clarity
Security assessment
Changes involve clarifications and structural improvements without altering security logic. The consent classification table reformatting maintains identical rules to previous bullet points (e.g., 400 Bad Request for invalid consent states). No vulnerability fixes or security incident references are present.
Diff
diff --git a/healthlake/latest/devguide/reference-fhir-operations-bulk-member-match.md b/healthlake/latest/devguide/reference-fhir-operations-bulk-member-match.md index 28f091583..9b21baf7f 100644 --- a//healthlake/latest/devguide/reference-fhir-operations-bulk-member-match.md +++ b//healthlake/latest/devguide/reference-fhir-operations-bulk-member-match.md @@ -44 +44 @@ After submitting a bulk match request, you can poll the job status using: -Each request supports up to 500 members (5 MB maximum payload). +Each request supports up to 500 members with a maximum payload of 5 MB. @@ -48 +48 @@ Each request supports up to 500 members (5 MB maximum payload). - 1. Submit: `POST [base]/Group/$bulk-member-match` with MemberBundles → receive jobId +To get started with bulk member match, follow these steps: @@ -50 +50 @@ Each request supports up to 500 members (5 MB maximum payload). - 2. Poll: `GET [base]/$bulk-member-match-status/{jobId}` until status = COMPLETED + 1. Submit a bulk match request with MemberBundles using the `Group/$bulk-member-match` operation. The response includes a job ID. @@ -52 +52 @@ Each request supports up to 500 members (5 MB maximum payload). - 3. Extract the MatchedMembers Group ID from the completed job response + 2. Poll the job status using the `$bulk-member-match-status` operation until the status is COMPLETED. @@ -54 +54,3 @@ Each request supports up to 500 members (5 MB maximum payload). - 4. Export: `POST [base]/Group/{matched-group-id}/$davinci-data-export` to retrieve clinical data + 3. Extract the `MatchedMembers` Group ID from the completed job response. + + 4. Export clinical data using the `Group/$davinci-data-export` operation on the matched Group. @@ -496,16 +498 @@ All checks must pass for the member to be placed in MatchedMembers and for the C -The `performer` reference is not cross-validated against `patient`. A parent/guardian consenting on behalf of a dependent is valid. - -**Consent classification decision table:** - - * `permit` \+ `#regular` \+ `active` \+ period covers now → **MatchedMembers (Consent stored)** - - * `permit` \+ `#sensitive` \+ `active` \+ period covers now → **MatchedMembers (Consent stored)** - - * `permit` \+ #regular or #sensitive + `active` \+ period expired/not started → **ConsentConstrainedMembers** - - * `deny` \+ any + any + any → **400 Bad Request (Step 1)** - - * `permit` \+ URI not ending in #regular or #sensitive + any + any → **400 Bad Request (Step 1)** - - * any + any + not active + any → **400 Bad Request (Step 1)** - +The operation does not validate the `performer` reference against the `patient` field. A parent or guardian can consent on behalf of a dependent. @@ -512,0 +500 @@ The `performer` reference is not cross-validated against `patient`. A parent/gua +The following table describes how consent classification determines member placement: @@ -513,0 +502,8 @@ The `performer` reference is not cross-validated against `patient`. A parent/gua +Provision type| Policy URI| Status| Period| Outcome +---|---|---|---|--- +`permit`| `#regular`| `active`| Covers current date| MatchedMembers (Consent stored) +`permit`| `#sensitive`| `active`| Covers current date| MatchedMembers (Consent stored) +`permit`| `#regular` or `#sensitive`| `active`| Expired or not started| ConsentConstrainedMembers +`deny`| Any| Any| Any| 400 Bad Request (Step 1) +`permit`| Not ending in `#regular` or `#sensitive`| Any| Any| 400 Bad Request (Step 1) +Any| Any| Not `active`| Any| 400 Bad Request (Step 1)