DICOM 의료 뷰어 통합

이 페이지에서는 타사 의료 영상 뷰어를 Cloud Healthcare API와 통합하기 위한 개념과 권장사항을 설명합니다. Cloud Healthcare API는 Open Health Imaging Foundation (OHIF) 뷰어 및 Weasis 뷰어를 비롯한 여러 뷰어와 통합됩니다.

시작하기 전에

뷰어에서 사용할 DICOM 이미지를 저장하지 않은 경우 DICOM 데이터 저장 및 Cloud Storage를 사용하여 DICOM 데이터 가져오기 및 내보내기를 참조하여 시작하세요.

OAuth 2.0을 사용하여 요청 승인 및 인증

Google Cloud APIs는 인증 및 승인에 OAuth 2.0 프로토콜을 지원합니다.

의료 뷰어는 Cloud Healthcare API에 저장된 DICOM 데이터에 액세스하기 위한 인증 및 승인을 처리해야 합니다. 이러한 권한은 두 가지 방법으로 부여할 수 있습니다. 각 방법에는 다음과 같은 고유한 비용과 이점이 있습니다.

Google ID 서비스 OAuth 2.0 흐름 사용

  • 최종 사용자는 Cloud Healthcare API에 대한 의료 뷰어를 통해 자체적으로 인증합니다.
  • 의료 뷰어는 최종 사용자를 대신하여 Cloud Healthcare API에 액세스합니다.
  • 권한은 사용자 수준에서 관리되며 사용자의 작업은 사용자 고유 식별자와 함께 Cloud 감사 로그에 로깅됩니다.
  • Google ID 서비스 흐름 사용은 서비스 계정 사용보다 더 복잡합니다. 예를 들어 승인 토큰을 저장하기 위해 애플리케이션이 콜백을 처리해야 하므로 단순한 애플리케이션에 불필요한 복잡성이 가중될 수 있습니다.

서비스 계정 사용

  • 최종 사용자가 특정 Cloud Healthcare API 리소스를 볼 수 있는지 확인하기 위해 의료 뷰어가 자체적인 승인 및 액세스 제어 메서드를 사용하도록 구성합니다. 서비스 계정을 사용하는 것은 이미 자체 사용자 관리 및 인증 확인을 수행하는 뷰어가 있는 경우에 유용합니다.
  • 뷰어에서 수행된 작업은 Cloud 감사 로그에 로깅되지만 개별 최종 사용자 수준에서는 로그를 볼 수 없습니다.
  • 서비스 계정을 사용하는 인증은 Google ID 서비스 흐름 사용보다 간단합니다. 예를 들어 사용자에게 로그인하라는 메시지를 표시할 필요가 없으므로 액세스 토큰을 저장할 필요가 없습니다.

Google ID 서비스 OAuth 2.0 흐름을 사용하여 인증

Google ID 서비스 OAuth 2.0 흐름을 사용하여 의료 뷰어가 사용자 대신 Cloud Healthcare API에 저장된 DICOM 데이터에 액세스하도록 승인할 수 있습니다. 애플리케이션에 따라 다음 애플리케이션에서 사용할 수 있는 흐름이 있습니다.

로그인 과정에 대한 다음 설명은 뷰어에 액세스하는 사용자가 DICOM 저장소를 만들고 저장소에 DICOM 인스턴스를 저장했다고 가정합니다.

  1. 사용자가 의료 뷰어 애플리케이션을 엽니다. 뷰어는 Google에서 애플리케이션의 이름과 사용자의 승인 사용자 인증 정보에 대한 액세스 권한을 요청하는 Google API 서비스를 표시하는 동의 창을 표시합니다. 그러면 사용자는 애플리케이션에 대한 액세스 권한을 부여하는 데 동의하거나 거부할 수 있습니다.
  2. 사용자가 Google ID 서비스 페이지로 전송됩니다. 사용자가 애플리케이션에 요청된 액세스 권한을 부여하면 애플리케이션은 사용자의 데이터에 액세스할 권한을 얻습니다.

뷰어에 갱신 토큰을 저장하지 마세요. 사용자가 뷰어에 부여한 액세스 토큰은 수명이 짧아야 하며 토큰이 만료된 경우에만 교환해야 합니다.

다음과 같은 이유로 갱신 토큰도 필요하지 않습니다.

  • 뷰어를 사용할 때 사용자는 항상 존재합니다.
  • 갱신 토큰을 사용하면 토큰을 안전하게 저장하기 위해 추가 작업이 필요합니다.

서비스 계정을 사용하여 승인

서비스 계정으로 OAuth 2.0을 사용하여 최종 사용자 수준이 아닌 의료 뷰어 수준에서 인증 및 승인을 관리할 수 있습니다.

서비스 계정을 사용하여 Cloud Healthcare API에 대한 의료 뷰어를 인증하는 방법은 API 인증을 참조하세요.

필요한 역할

뷰어가 제대로 작동하려면 사용자에게 다음 역할이 있어야 합니다.

  • roles/healthcare.dicomViewer: DICOM 리소스 보기
  • roles/healthcare.dicomEditor: DICOM 리소스 보기, 수정, 만들기

로그인 흐름에서 사용자가 이미 이러한 역할을 구성했으며 뷰어가 다른 작업을 수행할 필요가 없습니다. 서비스 계정을 사용할 때는 서비스 계정에서 역할을 설정해야 합니다. 뷰어는 DICOM 저장소에 액세스하는 데 필요한 권한이 없는 사용자에게 적절한 PERMISSION_DENIED 오류를 반환해야 합니다.

DICOM 웹 엔드포인트 액세스

사용자가 뷰어에 인증하면 뷰어는 DICOMweb 엔드포인트에 요청할 수 있습니다. 각 DICOM 저장소는 단일 DICOMweb 엔드포인트를 노출합니다.

사용자가 뷰어에 있을 때 액세스하려는 프로젝트 및 DICOM 저장소를 지정해야 합니다. 가장 간단한 처리 방법은 사용자에게 액세스하려는 프로젝트, 데이터 세트, DICOM 저장소의 ID를 제공하도록 요청하는 것입니다. 하지만 개별 값을 각각 제공하면 사용자의 시간이 오래 걸릴 수 있습니다.

대안으로 뷰어에 사용자 입력과 자동 완성의 조합을 제공할 수 있습니다. 예를 들어 사용자가 프로젝트 ID를 입력하면 뷰어는 자동으로 프로젝트 내의 데이터 세트 및 DICOM 저장소의 목록을 채웁니다. 또는 사용자가 액세스할 수 있는 프로젝트, 데이터 세트, DICOM 저장소를 자동으로 채우는 단일 입력란을 제공할 수도 있습니다. 이러한 대안 중 하나를 설정할 때 다음 API 메서드가 유용할 수 있습니다.

사용자의 리소스 목록을 자동 입력하는 것도 좋습니다. 하지만 사용자가 수백 또는 수천 개의 DICOM 저장소 또는 데이터 세트를 가지고 있는 경우 목록을 자동 입력하고 표시하는 것이 불가능할 수 있습니다.

DICOMweb을 사용하여 뷰어의 리소스에 액세스

Cloud Healthcare API는 DICOMweb 표준을 지원합니다. 사용자가 데이터에 액세스할 수 있도록 하려면 뷰어가 기존 DIMSE 프로토콜 대신 DICOMweb RESTful HTTP 메서드를 구현해야 합니다.

모든 뷰어에는 다음과 같은 두 가지 주요 구성요소가 있습니다.

  • 작업 목록 제공자
  • 이미지 뷰어

두 구성 요소 모두에 DICOMweb 표준을 사용할 수 있습니다.

작업 목록 제공자 보기

일반적으로 사용자가 뷰어를 열 때 가장 먼저 보게 되는 것은 각 DICOM 저장소에서 사용 가능한 모든 연구 목록입니다. 뷰어는 검색 트랜잭션을 사용하여 이러한 연구를 검색할 수 있습니다.

Cloud Healthcare API에서 검색 트랜잭션이 구현되는 방법에 대한 자세한 내용은 Cloud Healthcare API DICOM 적합성 설명을 참조하세요.

인스턴스 보기

사용자가 작업 목록 제공자에 있으면 일반적으로 조회할 연구를 선택합니다. 연구를 렌더링하려면 뷰어가 연구의 원시 픽셀 바이트 및 DICOM 메타데이터에 액세스해야 합니다. 뷰어는 검색 트랜잭션 메서드 세트를 사용하여 이 정보를 검색할 수 있습니다. 검색 트랜잭션 메서드를 사용하면 원시 DICOM 파일 전체나 파일의 원시 픽셀 데이터를 검색할 수 있습니다. 검색 트랜잭션 메서드는 다양한 전송 문법 간의 트랜스코딩도 지원합니다.

Cloud Healthcare API에서 검색 트랜잭션 메서드가 구현되는 방법에 대한 자세한 내용은 Cloud Healthcare API DICOM 적합성 문을 참조하세요.

네트워크 처리량 극대화

간혹 CT 스캔을 렌더링하는 경우 등의 상황에서 뷰어는 이미지를 렌더링하기 위해 여러 인스턴스를 한번에 다운로드해야 할 수도 있습니다. 최상의 결과를 얻으려면 높은 동시 요청 수(예: 50개 이상)를 사용하여 각 인스턴스를 동시에 가져옵니다. 정확한 수치는 애플리케이션과 네트워크 대역폭에 따라 다릅니다.