이 페이지는 Cloud Translation API를 통해 번역되었습니다.

FHIR 액세스 데이터 모델 및 제어 시스템

이 페이지에서는 Cloud Healthcare API FHIR 액세스 제어 시스템을 사용하여 의료 데이터를 관리하고 보호하는 방법을 설명합니다. FHIR 액세스 제어를 사용하여 동의 정책을 정의하고, 사용자 역할 및 컨텍스트에 따라 데이터 액세스를 제어하고, FHIR 저장소에서 이러한 정책을 적용할 수 있습니다.

데이터 모델 개요

액세스 제어를 위한 데이터 모델은 동의 리소스로 표현됩니다. 적용되는 규칙과 규칙이 적용되는 데이터를 정의합니다.

액세스 규칙은 FHIR 동의 리소스를 통해 표현됩니다. FHIR 동의는 의료 고객의 선택을 포착하는 FHIR 리소스의 한 가지 유형입니다. FHIR 동의는 특정 행위자 집합이 일정 기간 동안 지정된 환경에서 특정 목적에 따라 소비자에 영향을 주는 특정 조치를 수행하는 것을 허용하거나 거부합니다. 예를 들어 소비자는 의료 환자, 의료 환자를 대리하는 모든 사람, 동의 계약을 체결하는 다른 개인이 될 수 있습니다.

FHIR 동의에 기록된 조치는 광범위하고 고객의 전자 의료 기록(EHR) 데이터 이상을 다룰 수 있습니다. 하지만 Cloud Healthcare API 내에서의 동의 목적에 따라 데이터 액세스와 관련된 조치에 중점을 두고 있으며 이러한 조치의 시행은 FHIR 저장소에서 FHIR 데이터를 읽는 것으로 제한됩니다.

동의 리소스에는 동의의 현재 상태를 나타내는 상태가 포함됩니다. FHIR 저장소에 서로 다른 상태의 여러 동의가 포함될 수 있지만 Cloud Healthcare API는 활성 상태의 동의만 적용할 수 있습니다. 다른 상태의 동의는 적용 시 효과가 없습니다. 동의가 환자를 대리하여 제공된 경우에는 동의가 이행자에 의해 부여된 것으로 기록됩니다.

정책 유형

Cloud Healthcare API는 다음과 같은 동의 정책 유형을 지원합니다.

환자 동의는 Consent.patient(STU3, R4)를 사용하여 환자와 연결되며 환자 구획(STU3, R4)으로 정의된 만큼 많은 데이터를 바인딩합니다.
관리자 정책은 환자와 연결되지 않으며 확장 URL https://g.co/fhir/medicalrecords/ConsentAdminPolicy를 포함해야 합니다. 이 정책 유형은 리소스 기준으로 지정된 저장소의 모든 리소스 또는 하위 집합에 바인딩될 수 있습니다. 관리자 정책은 저장소의 모든 바인딩 리소스에 대해 기본 정책을 설정합니다.
관리자 단계식 정책: 확장 프로그램 URL https://g.co/fhir/medicalrecords/CascadingPolicy 및 관리 정책 확장 프로그램 URL이 필요한 관리자 정책 유형입니다. 이 정책 유형을 리소스 기준과 일치하는 리소스 구획에 바인딩할 수 있습니다. 다음과 같은 제한사항이 있습니다.
- 구획 기준으로 환자(STU3, R4) 또는 접촉(STU3, R4)만 지원합니다.
- 정책이 적용되는 FHIR 저장소에서는 disableReferentialIntegrity가 false로 설정되어 있어야 합니다. 참조 무결성이 없는 FHIR 스토어에 이 기능을 사용하려면 Cloud 지원팀에 문의하세요.

동일한 리소스 수준에서 정책 유형을 조합하여 리소스에 대한 액세스를 허용하거나 거부할 수 있습니다. 환자의 동의가 누락된 경우 관리자 정책으로 리소스에 대한 액세스를 승인할 수 있습니다.

동의 지시문은 수혜자 또는 접근자와 같은 허가된 대상에 대해 데이터 액세스를 허용하거나 거부하는 FHIR 동의 내에서 인코딩되는 지침입니다. 단일 FHIR 동의는 여러 동의 지시문을 인코딩할 수 있습니다. 각 지시문은 다음을 제공합니다.

시행 유형: permit 또는 deny 지침
작업: 이 지시문이 적용되는 권한. 읽기 전용 액세스를 제공하기 위해 access만 지원됩니다.
접근자 기준: 지시문이 적용되는 API 요청자를 식별하는 속성 집합
리소스 기준: 지시문이 적용되는 리소스를 식별하는 속성 집합

접근자 기준

Cloud Healthcare API에서는 동의 지시문 내에서 사용하고 데이터 액세스 요청을 수행하는 접근자와 일치시키기 위해 세 가지 접근자 속성을 지원합니다. FHIR 서버에서 제공하는 액세스 결정의 일부로 접근자에 대해 지시문을 시행하려면 대소문자를 구분하는 일치검색이 있어야 합니다.

이러한 속성은 다음과 같이 인코딩됩니다.

행위자: 접근자 또는 접근자의 특성을 식별하는 개인, 그룹 또는 액세스 역할을 나타냅니다.
목적: 데이터 사용 의도를 나타냅니다.
환경: 접근자가 행동을 수행하는 환경 또는 조건을 설명하는 추상적인 식별자를 나타냅니다.

예를 들어 다음 속성에 따라 접근자를 표현할 수 있습니다.

작업 수행자: Practitioner/123
목적: ETREAT 또는 응급 치료 목적을 위한 액세스
환경: Application/abc

이 예시에서 이러한 속성은 abc라는 소프트웨어 애플리케이션을 사용하여 응급 치료를 수행할 때 데이터에 액세스하는 의사를 나타냅니다.

provision.actor 및 provision.purpose는 FHIR 표준의 일부로 정의되고 환경은 https://g.co/fhir/medicalrecords/Environment입니다. 이 링크를 확인할 수 없습니다.

모든 동의 지시문은 시행되기 위해 actor를 지정해야 하지만 purpose 또는 environment를 항상 지정할 필요는 없습니다. 예를 들어 environment가 동의 지시문에 지정되지 않았으면 다른 동의 지시문에 의해 아직 다뤄지지 않은 모든 environment와 일치합니다.

리소스 기준

Cloud Healthcare API에서는 동의 리소스의 일부로 다음 요소를 지원합니다.

리소스 유형(STU3, R4): 동의 정책에서 바인딩하는 유형을 나타냅니다(예: Encounter, Observation 또는 Immunization).
리소스 ID(STU3, R4): 동의 정책에서 바인딩하는 ID를 나타냅니다.
데이터 소스: meta.source 리소스에서 식별하는 리소스 원본을 나타냅니다(R4에서만 사용 가능).
데이터 태그: meta.tag 리소스(STU3, R4)의 설명대로 리소스의 커스텀 라벨을 나타냅니다.
보안 라벨: meta.security 필드(STU3, R4)에서 식별된 대로 영향을 받는 리소스를 정의하는 보안 레이블을 나타냅니다. 다음 코드 시스템이 지원됩니다.
- 비밀유지: 다음과 같이 무제한에서 최대 제한까지 순위가 매겨진 계층적 값: U, L, M, N, R, V. 동의가 R의 보안 라벨을 허용하는 경우 R 이하로 라벨이 지정된 모든 리소스에 적용됩니다. 동의가 보안 라벨 R을 거부하는 경우 적어도 R만큼 민감한 모든 리소스에 적용됩니다.
- ActCode: 보안 코드에서 정확한 문자열 일치.

액세스 워크플로

authorization_flow

이 그림은 FHIR 액세스 제어가 사용 설정된 저장소에 대한 요청의 엔드 투 엔드 여정을 보여줍니다. 액세스 제어가 사용 설정된 FHIR 저장소에 대한 요청을 수행할 때 애플리케이션(#3)에 동의 범위(왼쪽)가 있는 외부 토큰이 사용됩니다(오른쪽).

데이터 액세스 요청을 수행할 때 접근자는 FHIR HTTP 요청과 관련된 actor, purpose, environment 속성을 나타내는 특정 동의 범위 내에서 작동합니다. 시행의 액세스 결정에 영향을 주기 위해서는 이러한 속성 값이 동의 내에 제공된 것과 대소문자를 구분하여 일치해야 합니다.

접근자는 액세스 결정과 관련된 여러 actor 식별자를 포함할 수 있습니다. 마찬가지로 특정 동의 컨텍스트 내에서 관련된 purposes 또는 environments가 여러 개 있을 수 있습니다. 따라서 동의 목적으로 해당 접근자를 올바르게 나타내려면 모든 동의 접근자 속성이 FHIR HTTP 요청의 일부로 제공되어야 합니다.

예를 들어 지정된 데이터 요청의 동의 범위가 다음과 같을 수 있습니다.

actor/Practitioner/444 actor/Group/999 purp/v3/TREAT purp/v3/ETREAT env/App/abc

특정 병원 내 한 부서의 실무자를 나타내는 999 그룹의 구성원인 444 실무자로 알려진 간호사나 의사를 나타냅니다. 실무자는 여기에서 정기 치료를 제공하지만 이러한 조치의 일환으로 응급 치료도 수행할 수 있습니다. 실무자는 abc라는 소프트웨어 애플리케이션을 사용합니다.

동의 범위는 접근자의 데이터 요청의 일부로 요청 동의 범위로 제공됩니다.

동의 범위 요청

FHIR 요청은 FHIR HTTP 요청 헤더를 사용하여 접근자의 동의 범위를 수신합니다. 이 동의 범위에는 접근자의 현재 ID, 자격, 사용 의도, 접근자가 작업하는 환경 제약 조건이 반영되도록 actor, purpose, environment 값 집합이 포함됩니다. 특정 순간의 접근자 동의 범위를 나타내는 이러한 각 속성이 두 개 이상 있을 수 있습니다.

동의 범위 항목은 다음과 같이 정의됩니다.

actor/{type}/{ID}: type 리소스가 ID와 함께 제공되는 actor 속성입니다. type 예시에는 다음이 포함됩니다.
- Practitioner
- Group
- Patient
예를 들어 projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID 형식의 저장소가 API를 호출하는 경우 Practitioner/123 행위자에 대한 로컬 참조가 projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123으로 해석됩니다.
purp/v3/{value}: purpose 속성입니다. 여기서 value는 FHIR 사용 목적(v3) 값 집합이나 해당 확장의 구성원입니다. value 예시는 다음과 같습니다.
- TREAT
- ETREAT
- HRESCH
env/{type}/{value}: environment 속성입니다. 여기서 type 및 value는 사전 정의된 분류가 없는 커스텀 문자열입니다. type 및 value 예시는 다음과 같습니다.
- App/my_app_1
- Net/VPN

또한 FHIR HTTP 요청 헤더는 다음과 같이 정의된 btg 및 bypass와 같은 특수 범위를 수신할 수도 있습니다.

btg: 긴급 상황 액세스(또는 BTG)를 사용하면 긴급 상황 발생 시 인간 사용자가 동의 확인을 건너뛸 수 있습니다. 긴급 상황에서만 사용해야 하며 감사 후 검토가 적용됩니다. 따라서 btg에는 actor가 1개 이상 필요합니다.
bypass: 신뢰할 수 있는 사용자(예: 관리자) 또는 신뢰할 수 있는 애플리케이션(예: ML 학습 파이프라인)이 동의 승인 없이 FHIR 저장소에서 작동할 수 있습니다. 따라서 bypass에는 actor와 env가 각각 최소 하나 이상 필요합니다.

액세스 시행 및 액세스 결정

여러 정책 및 동의가 공존하는 복잡한 의료 환경에서는 액세스를 적용하고 액세스 권한을 결정하는 것은 어려운 태스크가 될 수 있습니다. 다양한 이해관계자들이 환자 정보 사용 및 공개에 관해 서로 다른 기대치와 요구사항을 가질 수 있습니다. 이러한 복잡한 환경을 탐색하기 위해서는 액세스가 시행되는 방법과 액세스 결정을 제어하는 기본 논리에 대해 명확한 이해가 필요합니다.

집계된 동의 정책

환자 또는 관리자와 같은 의료 소비자는 단일 동의 리소스 내에 포함된 동의 지시문을 여러 개 가질 수 있습니다. 동의 리소스에는 permit 및 deny provision.type 지시문 혼합이 포함될 수 있습니다. 기본적으로 사용자는 동의 리소스를 여러 개 가질 수 있지만 한 번에 active 동의 리소스는 최대 200개까지 시행됩니다. 자세한 내용은 제약조건 및 제한사항을 참조하세요.

모든 동의 지시문은 특정 사용자가 집계된 동의 규칙 집합을 만들 수 있도록 active 동의 리소스에서 추출됩니다.

동의 지시문 속성

동의 시행은 목적 최대 1개와 프로비전 항목당 환경 최대 1개로 제한됩니다.

다음 규칙은 환자 동의, 관리자 정책, 관리자 단계식 정책의 공동 액세스 제어를 위한 원칙을 설명합니다.

일치하는 지시문이 없으면 기본적으로 모든 리소스에 액세스가 거부됩니다.
요청된 리소스가 없으면 리소스 유형 및 리소스 ID만 식별할 수 있습니다. 다른 모든 리소스 기준 및 리소스 소유자는 알려지지 않으며, 다음 규칙이 목록 순서에 적용됩니다.
- 리소스 유형이 환자 구획 또는 접촉 구획에 속하는 경우 액세스가 거부됩니다.
- 그 외의 경우에는 다음 안내를 따르세요.
  - 다른 리소스 기준에 관계없이 접근자 기준을 거부하는 관리자 정책이 있으면 액세스가 거부됩니다.
  - 식별 가능한 리소스 기준(즉, 리소스 유형과 리소스 ID)에 대한 접근자 기준을 허용하는 관리자 정책이 있으면 '리소스를 찾을 수 없음' 오류가 반환됩니다.
  - 다른 모든 경우에는 액세스가 거부됩니다.
관리자 정책은 저장소에서 리소스를 일치시키는 데 사용되는 기본 정책입니다.
환자에 속하지 않는 리소스는 관리자 정책으로만 결정됩니다.
환자 구획(STU3, R4) 또는 접촉 구획(STU3, R4)에 있는 리소스에는 환자 또는 관리자 정책 또는 관리자 단계식 정책당 하나 이상의 허용 동의 지시문이 필요하며 환자 및 관리자 정책 및 관리자 단계식 정책의 거부 동의 지시문은 필요하지 않습니다. 이 조건은 요청자가 액세스할 리소스에 이름이 지정된 모든 환자에 필요합니다.
- 일부 리소스는 여러 환자 참가자를 지원합니다. 예를 들어 예약은 환자일 수 있는 참가자 목록을 제공합니다. 이러한 리소스에서 이름이 지정된 모든 환자는 동의 지시문을 사용한 접근자에게 액세스를 허용해야 하며, 그렇지 않으면 리소스가 반환되지 않습니다. 리소스가 subject 필드(STU3, R4)를 통해 환자를 참조하는 접촉 계단식 정책의 권한을 가지고 있는 경우 해당 리소스는 환자가 허용한 것으로 간주됩니다.

설명된 규칙은 다음 의사코드로 요약됩니다.

공동 액세스 제어

if resource does not exist
  if resource is a patient-compartment or encounter-compartment resource:
    return "deny"
  else:
    if there is any admin policy denies access for accessor criteria regardless of resource criteria other than resource type and resource ID:
      return "deny"
    else if there is any admin policy permits access for accessor criteria based on the identifiable resource criteria:
      return "resource not found"
    else:
      return "deny"
else:
  let patients = list of patient references named in the patient compartment eligible fields of the requested resource
  if there is any matching deny from either patients's consents or admin policy or admin cascading policy:
    return "deny"
  if there is matching admin policy permits access:
    return "permit"
  if all patients have matching patient consents or admin cascading consent that permit access or are subject of encounters which permit the access through encounter cascading policy:
    return "permit"
  else:
    return "deny"
end

FHIR 저장소는 리소스 수준별로 동의 권한을 검사합니다. 리소스의 참조는 동의 액세스 검사를 위해 확인되고 하위로 전파되지 않습니다. 예를 들어 실무자가 전체 MedicationRequest 리소스에 액세스할 수 있지만 환자 개인 정보 보호로 인해 Patient/f001 리소스 자체에는 액세스할 수 없게 하는 Patient/f001로 식별된 환자를 가정해 보겠습니다. 이 시나리오에서 실무자는 Patient/f001 리소스를 참조하는 subject 필드가 포함된 전체 MedicationRequest 리소스를 볼 수 있지만 _include를 사용하여 FHIR 검색을 수행하는 경우에도 Patient/f001 리소스의 동의를 볼 수 없습니다.

충돌 해결 방법

여러 permit 및 deny 지시문 간에 충돌이 발생할 수 있습니다. 충돌하는 지시문 두 개가 리소스 하나와 일치하면 permit보다 deny 우선 모델을 통해 충돌이 해결됩니다.

동의 시행에는 active 동의만 포함됩니다.

리소스 액세스 적용 로직

FHIR 저장소에 동의 인식 요청을 수행할 때는 액세스 제어가 다음 순서로 발생합니다.

Cloud Healthcare API는 프록시에 구성된 Google Cloud 서비스 계정 (또는 주 구성원)에 대한 권한을 확인합니다. 서비스 계정에 FHIR 저장소에서 요청된 FHIR 메서드를 수행할 수 있는 올바른 IAM 권한이 있으면 요청이 처리됩니다.
동의 시행이 FHIR 저장소 구성에 사용 설정되어 있고 동의 인식 HTTP 헤더가 제공된 경우, Cloud Healthcare API가 환자 구획 리소스에 대해 동의 액세스 정책을 시행합니다. 동의 액세스 정책의 시행은 최신 ApplyConsents 및 ApplyAdminConsents 실행으로 포착된 동의 지시문에 따라 요청에 제공된 동의 범주를 기반으로 합니다.

참고: FHIR 저장소 구성에서 동의 헤더 처리를 REQUIRED_ON_READ로 정의하는 경우 동의 인식 헤더가 없이도 동의 액세스 제어가 적용(및 거부)됩니다.

FHIR 저장소에 동의 인식 요청을 수행할 때는 다음 규칙이 적용됩니다.

수행된 동의 작업과 관련된 actor 동의 범위를 최소 하나 이상 제공합니다.
수행된 동의 작업과 관련된 모든 추가 purpose 및 environment 범위를 제공합니다.
동의 범위 항목 수가 지원되는 한도를 초과하면 오류가 반환됩니다.
여러 리소스(예: fhir.Patient-everything, fhir.Encounter-everything, fhir.executeBundle, 또는 fhir.search 메서드)에 액세스하는 메서드를 호출하는 경우 동의 시행이 각 개별 리소스에 적용됩니다. 하지만 이러한 멀티 리소스 액세스 메서드에는 다음과 같은 미묘한 차이가 있습니다.
- 여러 리소스를 읽는 fhir.executeBundle은 동의 권한이 없는 개별 리소스에 대해 '동의 액세스가 거부되거나 액세스 중인 리소스가 존재하지 않음'이 수신됩니다 (동의 범위로 FHIR 리소스 가져오기의 예시 참고).
- fhir.search는 동의 권한이 없는 리소스를 건너뛰고 _id로 검색해도 동의 액세스 거부됨 오류를 반환하지 않습니다(동의 범위로 FHIR 리소스 가져오기의 예시 참조).
- fhir.Patient-everything 및 fhir.Encounter-everything는 호출자에게 요청된 환자 또는 진료 리소스에 대한 동의 권한이 없는 경우 각각 '동의 액세스가 거부되거나 액세스 중인 리소스가 존재하지 않음'을 반환한다는 점을 제외하면 fhir.search와 비슷하게 작동합니다.

동의 지시문에는 actor, purpose, environment가 각각 최대 하나씩만 포함되지만, 동의 범위에는 이들이 각각 여러 개 포함될 수 있습니다. 일부 동의 지시문은 세 가지 접근자 속성을 모두 지정하지 않습니다. 이 경우 충돌 해결 규칙에 따라 동의 범위 속성 값이 일치할 수 있습니다. 따라서 동의 범위가 하나를 초과하는 동의 지시문과 일치할 수 있습니다.

요청 동의 범위에 같은 동의 범위 유형(actor, purpose 또는 environment)의 항목이 두 개 이상 포함된 경우 동의 범위가 동의 지시문 여러 개와 일치할 수 있습니다. 일부 동의 지시문에서는 purpose 또는 environment를 지정하지 않습니다. 따라서 동의 범위가 이러한 범위 유형을 지정하지 않는 동의 지시문과도 일치해야 합니다.

예를 들어 동의 범위를 actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc로 설정하면 다음 permit 또는 deny 동의 지시문과 일치합니다.

actor/Practitioner/123 purp/v3/TREAT env/App/abc
actor/Practitioner/123 purp/v3/TREAT
actor/Practitioner/123 env/App/abc
actor/Practitioner/123
actor/Group/999 purp/v3/TREAT env/App/abc
actor/Group/999 purp/v3/TREAT
actor/Group/999 env/App/abc
actor/Group/999

다음 단계

FHIR 저장소에 대한 액세스 적용 방법 알아보기