기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 자격 증명 및 동시성
<a name="managing-fhir-resources-idempotency"></a>

## 자격 증명 키
<a name="idempotency-keys"></a>

AWS HealthLake 는 FHIR `POST` 작업에 대한 멱등성 키를 지원하여 리소스 생성 중에 데이터 무결성을 보장하는 강력한 메커니즘을 제공합니다. 고유한 UUID를 요청 헤더에 멱등성 키로 포함하면 의료 애플리케이션은 네트워크 불안정 또는 자동 재시도와 관련된 시나리오에서도 각 FHIR 리소스가 정확히 한 번 생성되도록 보장할 수 있습니다.

이 기능은 중복 의료 기록이 심각한 결과를 초래할 수 있는 의료 시스템에 특히 중요합니다. 이전 요청과 동일한 멱등성 키로 요청이 수신되면 HealthLake는 복제본을 생성하는 대신 원본 리소스를 반환합니다. 예를 들어 재시도 루프 중에 또는 중복 요청 파이프라인으로 인해 발생할 수 있습니다. 멱등성 키를 사용하면 HealthLake가 데이터 일관성을 유지하면서 간헐적인 연결 문제를 처리하는 클라이언트 애플리케이션에 원활한 환경을 제공할 수 있습니다.

### 구현
<a name="implementation"></a>

```
POST /<baseURL>/Patient
x-amz-fhir-idempotency-key: 123e4567-e89b-12d3-a456-426614174000
{
    "resourceType": "Patient",
    "name": [...]
}
```

### 응답 시나리오
<a name="response-scenarios"></a>

첫 번째 요청(201 생성됨)  
+ 새 리소스가 성공적으로 생성됨
+ 응답에 리소스 ID 포함

중복 요청(409 충돌)  
+ 동일한 멱등성 키가 감지됨
+ 반환된 원본 리소스
+ 새 리소스가 생성되지 않음

잘못된 요청(400 잘못된 요청)  
+ 잘못된 UUID
+ 필수 필드 누락

### 모범 사례
<a name="best-practices"></a>
+ 각 새 리소스 생성에 대해 고유한 UUID 생성
+ 재시도 로직에 대한 멱등성 키 저장
+ 일관된 키 형식 사용: UUID v4 권장
+ 리소스 생성을 처리하는 클라이언트 애플리케이션에서 구현

**참고**  
이 기능은 엄격한 데이터 정확도를 요구하고 중복 의료 기록을 방지하는 의료 시스템에 특히 유용합니다.

## AWS HealthLake의 ETag
<a name="healthlake-etag"></a>

AWS HealthLake 는 FHIR 리소스의 낙관적 동시성 제어에 ETags 사용하여 동시 수정을 관리하고 데이터 일관성을 유지하는 신뢰할 수 있는 메커니즘을 제공합니다. ETag는 리소스의 특정 버전을 나타내는 고유 식별자로, HTTP 헤더를 통해 버전 관리 시스템으로 작동합니다. 리소스를 읽거나 수정할 때 애플리케이션은 ETags 사용하여 의도하지 않은 덮어쓰기를 방지하고 특히 잠재적 동시 업데이트가 있는 시나리오에서 데이터 무결성을 보장할 수 있습니다.

### 구현 예제
<a name="healthlake-etag-implementation"></a>

```
// Initial Read
GET /fhir/Patient/123
Response: 
ETag: W/"1"

// Update with If-Match
PUT /fhir/Patient/123
If-Match: W/"1"
{resource content}

// Create with If-None-Match
PUT /fhir/Patient/123
If-None-Match: *
{resource content}
// Succeeds only if resource doesn't exist
// Fails with 412 if resource exists
```

### 응답 시나리오
<a name="healthlake-etag-scenarios"></a>

성공한 작업(200 OK 또는 204 No Content)  
+ ETag가 현재 버전과 일치
+ 작업이 의도한 대로 진행됨

버전 충돌(412 사전 조건 실패)  
+ ETag가 현재 버전과 일치하지 않음
+ 데이터 손실을 방지하기 위해 업데이트가 거부됨

### 모범 사례
<a name="healthlake-etag-practices"></a>
+ 모든 업데이트 및 삭제 작업에 ETags 포함
+ 버전 충돌을 처리하기 위한 재시도 로직 구현
+ If-None-Match 사용: create-if-not-exists 시나리오의 경우 \$1
+ 수정하기 전에 항상 ETag 최신 상태 확인

이 동시성 제어 시스템은 특히 여러 사용자 또는 시스템이 동일한 리소스에 액세스하고 수정하는 환경에서 의료 데이터의 무결성을 유지하는 데 필수적입니다.