Cloud Healthcare API FHIR 검색 구현은 REST 및 FHIR 사양의 가이드라인과 한계를 따르지만 확장성과 성능이 뛰어납니다. 이를 달성하기 위해 FHIR 검색에는 다음 속성이 포함되어 있습니다.
검색 합계는 마지막 페이지가 반환되기 전까지의 추정 값입니다.
fhir.search메서드로 반환된 검색 결과에는 검색의 총 일치 항목 수에 해당하는 검색 합계(Bundle.total속성)가 포함됩니다. 검색 합계는 검색 결과의 마지막 페이지가 반환될 때까지의 추정 값입니다. 마지막 결과 페이지로 반환된 검색 합계는 검색에 포함된 모든 일치 항목이 정확하게 합산된 값입니다.검색 결과는 순차적인 정방향 페이지로 나누기를 제공합니다. 반환할 검색 결과가 더 있으면 응답에 다음 결과 페이지로 이동하기 위한 페이지로 나누기 URL(
Bundle.link.url)이 포함됩니다.
기본 사용 사례
FHIR 검색은 다음 사용 사례에 대한 솔루션을 제공합니다.
- 순차적으로 찾아보기. 사용자가 제한된 개수의 검색 결과 페이지 수를 통해 순차적으로 정방향으로 찾아봅니다. 예상된 검색 합계가 각 페이지와 함께 반환됩니다.
- 검색 결과 집합 처리. 앱이 검색 결과 집합을 가져오고, 결과를 읽고, 데이터를 처리합니다.
이러한 사용 사례에 가능한 솔루션은 다음 섹션을 참조하세요.
순차적으로 찾아보기
사용자가 원하는 일치 항목을 찾을 때까지 결과 페이지를 통해 순차적으로 정방향으로 찾아볼 수 있게 해주는 지연 시간이 짧은 애플리케이션을 빌드할 수 있습니다. 이 솔루션은 일치 항목 수가 충분히 적어서 사용자가 결과를 건너뛰지 않고도 페이지별로 찾아보는 방식으로 원하는 일치 항목을 찾을 수 있는 경우에 사용할 수 있습니다. 사용자가 한 번에 여러 페이지를 정방향으로 이동해야 하는 사용 사례의 경우에는 주변 페이지로 이동을 참조하세요.
이 솔루션은 마지막 결과 페이지가 반환될 때까지 정확한 검색 합계를 제공할 수 없습니다. 그러나 각 결과 페이지와 함께 대략적인 검색 합계를 제공할 수 있습니다. 정확한 검색 합계가 백그라운드 프로세스의 요구사항일 수 있지만 인간 사용자의 경우에는 일반적으로 대략적인 검색 합계만으로 충분합니다.
워크플로
이 솔루션의 워크플로 예시는 다음과 같습니다.
앱이
fhir.search메서드를 호출하고, 이 메서드는 검색 결과의 첫 페이지를 반환합니다. 반환할 추가 결과가 없으면 응답에 페이지로 나누기 URL(Bundle.link.url)이 포함됩니다. 또한 응답에 검색 합계(Bundle.total)가 포함됩니다. 초기 응답보다 반환할 결과가 더 있는 경우에는 검색 합계가 추정 값일 뿐입니다. 자세한 내용은 페이지로 나누기 및 정렬을 참조하세요.앱이 검색 결과 페이지, 결과의 다음 페이지 링크(있는 경우), 검색 합계를 표시합니다.
사용자가 결과의 다음 페이지를 보려면 링크를 클릭합니다. 그러면 페이지로 나누기 URL이 호출됩니다. 반환할 결과가 더 있으면 응답에 새로운 페이지로 나누기 URL이 포함됩니다. 또한 응답에 검색 합계가 포함됩니다. 반환할 결과가 더 있으면 이것이 업데이트된 추정 값입니다.
앱이 새 검색 결과 페이지, 결과의 다음 페이지 링크(있는 경우), 검색 합계를 표시합니다.
사용자가 검색을 중지하거나 마지막 결과 페이지가 반환될 때까지 앞의 두 단계가 반복됩니다.
권장사항
사람이 어려움 없이 읽을 수 있는 적합한 페이지 크기를 선택합니다. 사용 사례에 따라 일치 항목 수를 페이지당 10~20개 정도로 지정할 수 있습니다. 페이지가 더 작으면 더 빠르게 로드되고, 한 페이지에 링크가 너무 많으면 사용자가 관리하기 어려울 수 있습니다. _count 매개변수를 사용하여 페이지 크기를 제어합니다.
검색 결과 집합 처리
페이지로 나누기 URL을 사용해서 fhir.search 메서드를 성공적으로 호출하여 검색 결과 집합을 가져올 수 있습니다. 검색 결과 수가 충분히 작으면 반환할 페이지가 더 이상 없을 때까지 계속해서 전체 결과 집합을 얻을 수 있습니다. 정확한 검색 합계는 마지막 결과 페이지에 포함됩니다. 검색 결과를 가져온 후에는 앱이 결과를 읽고 처리, 분석, 집계 등 무엇이든 필요한 작업을 수행할 수 있습니다.
검색 결과 수가 많으면 적정 시간 내에 마지막 검색 결과 페이지(및 정확한 검색 합계)를 가져오는 것이 불가능할 수 있습니다.
워크플로
이 솔루션의 워크플로 예시는 다음과 같습니다.
앱이
fhir.search메서드를 호출하고, 이 메서드는 검색 결과의 첫 페이지를 반환합니다. 반환할 추가 결과가 없으면 응답에 페이지로 나누기 URL(Bundle.link.url)이 포함됩니다.반환할 결과가 더 있으면 앱이 이전 단계에서 페이지로 나누기 URL을 호출하여 검색 결과의 다음 페이지를 가져옵니다.
반환할 추가 결과가 없을 때까지 또는 다른 미리 정의된 한도에 도달할 때까지 앱이 이전 단계를 반복합니다. 검색 결과의 마지막 페이지에 도달하면 검색 합계가 정확하게 표시됩니다.
앱이 검색 결과를 처리합니다.
사용 사례에 따라 앱이 다음을 수행할 수 있습니다.
- 데이터를 처리하기 전 모든 검색 결과가 수신될 때까지 기다립니다.
fhir.search연속 호출에 따라 수신되는 대로 데이터를 처리합니다.- 반환된 일치 항목 수 또는 경과된 시간과 같은 일조의 한도를 설정합니다. 한도에 도달할 때 데이터를 처리하거나, 데이터를 처리하지 않거나, 기타 다른 작업을 수행할 수 있습니다.
설계 옵션
검색 지연 시간을 낮출 수 있는 몇 가지 설계 옵션은 다음과 같습니다.
페이지 크기를 크게 설정합니다.
_count매개변수를 사용하여 사용 사례에 따라 500~1,000 정도까지 페이지 크기를 크게 설정합니다. 페이지 크기를 더 크게 설정하면 각 페이지 가져오기에 대한 지연 시간이 늘어나지만 전체 검색 결과 집합을 가져오는 데 필요한 페이지 가져오기 수가 줄어들기 때문에 전체적인 프로세스 속도가 향상될 수 있습니다.검색 결과를 제한합니다. 리소스 콘텐츠를 반환할 필요 없이 정확한 검색 합계만 필요한 경우에는
fhir.search메서드의_elements매개변수를identifier로 설정합니다. 이렇게 하면 전체 FHIR 리소스의 반환을 요청할 때와 달리 검색 쿼리의 지연 시간이 감소할 수 있습니다. 자세한 내용은 검색 결과에 반환되는 필드 제한을 참조하세요.
미리 가져오기 및 캐싱이 필요한 사용 사례
일부 경우에는 페이지로 나누기 URL을 사용해서 fhir.search 메서드를 연속 호출하는 간단한 메커니즘보다 많은 기능이 필요할 수 있습니다. 한 가지 가능성은 앱과 FHIR 저장소 사이에 검색 결과를 미리 가져오고 캐시하는 동안 세션 상태를 유지 관리하는 캐싱 레이어를 빌드하는 경우입니다.
앱이 10개 또는 20개의 일치 항목이 포함된 작은 '앱 페이지'로 검색 결과를 그룹화할 수 있습니다. 그런 다음 앱이 사용자 선택에 따라 직접적이고, 비순차적인 방식으로 사용자에게 이러한 작은 앱 페이지를 빠르게 제공할 수 있습니다. 이러한 유형의 워크플로 예시는 주변 페이지로 이동을 참조하세요.
주변 페이지로 이동
사용자가 원하는 일치 항목을 찾을 때까지 많은 수의 검색 결과를 순회할 수 있게 해주는 지연 시간이 짧은 솔루션을 빌드할 수 있습니다. 지연 시간을 낮게 유지하고 리소스 소비 증가를 비교적 적게 발생시키면서도 거의 무제한의 일치 항목 수로 확장할 수 있습니다. 사용자는 현재 페이지에서 미리 결정된 정방향 또는 역방향 페이지 수까지 검색 결과 페이지로 직접 이동할 수 있습니다. 각 결과 페이지와 함께 예상된 검색 합계를 제공할 수 있습니다. 참고로 이 설계는 Google 검색의 설계와 비슷합니다.
워크플로
그림 1은 이 솔루션의 워크플로 예시를 보여줍니다. 이 워크플로에서는 사용자가 보려는 결과 페이지를 선택할 때마다 앱이 주변 페이지 링크를 제공합니다. 이 경우 앱은 선택한 페이지로부터 최대 5개까지 역방향 페이지와 선택한 페이지로부터 최대 4개까지 정방향 페이지에 대한 링크를 제공합니다. 4개의 정방향 페이지를 볼 수 있도록 제공하기 위해 앱은 사용자가 결과 페이지를 선택할 때 40개의 추가 일치 항목을 미리 가져옵니다.
그림 1. 앱이 검색 결과를 캐시되어 사용자에게 제공되는 '앱 페이지'로 그룹화합니다.
그림 1은 이러한 단계를 보여줍니다.
사용자가 앱 프런트엔드에 검색 쿼리를 입력하면 다음 작업이 시작됩니다.
검색 결과의 첫 번째 페이지를 미리 가져오도록 앱이
fhir.search메서드를 호출합니다.응답의 페이지 크기를 비교적 작게 유지하기 위해
_count매개변수가 100으로 설정되어, 응답 시간이 비교적 빨라집니다. 반환할 추가 결과가 없으면 응답에 페이지로 나누기 URL(Bundle.link.url)이 포함됩니다. 응답에는 또한 검색 합계(Bundle.total)가 포함됩니다. 반환할 결과가 더 있으면 검색 합계가 추정 값입니다. 자세한 내용은 페이지로 나누기 및 정렬을 참조하세요.앱이 응답을 캐싱 레이어로 전송합니다.
캐싱 레이어에서 앱은 응답의 100개 일치 항목을 각각 10개씩 일치 항목이 포함된 10개의 앱 페이지로 그룹화합니다. 앱 페이지는 앱이 사용자에게 표시할 수 있는 일치 항목이 포함된 작은 그룹입니다.
앱이 앱 페이지 1을 사용자에게 표시합니다. 앱 페이지 1에는 앱 페이지 2부터 10까지 링크와 예상되는 검색 합계가 포함됩니다.
사용자가 다른 앱 페이지(이 예시에서는 앱 페이지 10) 링크를 클릭하면 다음 작업이 시작됩니다.
검색 결과의 다음 페이지를 미리 가져오기 위해 앱이 이전 미리 가져오기로 반환된 페이지로 나누기 URL을 사용해서
fhir.search메서드를 호출합니다.사용자의 검색 쿼리로부터 다음 40개의 일치 항목을 미리 가져오도록
_count매개변수가 40으로 설정됩니다. 이 40개의 일치 항목은 앱이 사용자에게 제공하는 다음 4개의 앱 페이지를 위한 것입니다.앱이 응답을 캐싱 레이어로 전송합니다.
캐싱 레이어에서 앱은 응답의 40개 일치 항목을 각각 10개씩 일치 항목이 포함된 4개의 앱 페이지로 그룹화합니다.
앱이 앱 페이지 10을 사용자에게 표시합니다. 앱 페이지 10에는 앱 페이지 5~9까지의 링크(앱 페이지 10을 기준으로 5개의 역방향 앱 페이지)와 앱 페이지 11~14까지의 링크(앱 페이지 10을 기준으로 4개의 정방향 앱 페이지)가 포함됩니다. 앱 페이지 10에는 또한 예상되는 검색 합계가 포함됩니다.
이것은 사용자가 앱 페이지 링크를 계속 클릭하는 한 계속됩니다. 사용자가 현재 앱 페이지에서 역방향으로 이동할 때 주변 앱 페이지가 모두 캐시되어 있으면, 사용 사례에 따라 새로운 미리 가져오기를 수행하지 않도록 선택할 수 있습니다.
이 솔루션은 다음과 같은 이유로 빠르고 효율적입니다.
- 미리 가져오기가 작고, 앱 페이지는 더 작고, 빠르게 처리할 수 있습니다.
- 캐시된 검색 결과로 인해 동일 결과를 여러 번 호출할 필요가 줄어듭니다.
- 이 메커니즘은 검색 결과 수가 높은 값으로 확장되더라도 빠르게 유지됩니다.
설계 옵션
사용 사례에 따라 고려할 설계 옵션은 다음과 같습니다.
앱 페이지 크기. 사용 사례에 따라 앱 페이지에 일치 항목이 10개 넘게 포함될 수 있습니다. 페이지가 더 작으면 더 빠르게 로드되고, 한 페이지에 링크가 너무 많으면 사용자가 관리하기 어려울 수 있습니다.
앱 페이지 링크 수. 여기에 제안된 워크플로에서는 각 앱 페이지가 다른 앱 페이지에 9개의 링크를 반환합니다. 앱 페이지에 대한 5개 링크는 현재 앱 페이지를 기준으로 직접 역방향 페이지에 대한 링크이고, 4개 링크는 현재 앱 페이지를 기준으로 직접 정방향 페이지에 대한 링크입니다. 이러한 숫자는 사용 사례에 따라 조정할 수 있습니다.
권장사항
캐싱 레이어는 필요할 때만 사용합니다. 캐싱 레이어를 설정할 때는 사용 사례에 따라 필요한 경우에만 사용합니다. 캐싱 레이어가 필요하지 않은 검색은 이를 우회해야 합니다.
캐시 크기를 줄입니다. 리소스를 절약하기 위해서는 결과를 가져오는 데 사용된 페이지 URL은 유지하고 이전 검색 결과를 지워서 캐시 크기를 줄일 수 있습니다. 그런 다음 페이지 URL을 호출하여 필요에 따라 캐시를 다시 생성할 수 있습니다. 백그라운드에서 FHIR 저장소의 리소스가 생성, 업데이트, 삭제됨에 따라 동일한 페이지로 나누기 URL을 여러 번 호출한 결과가 시간에 따라 변경될 수 있습니다. 캐시 삭제 여부, 삭제 방법, 삭제 빈도는 사용 사례에 따라 달라지는 설계 시 의사 결정 요소입니다.
지정된 검색에 대해 캐시를 삭제합니다. 리소스를 절약하기 위해서는 비활성 검색의 결과를 캐시에서 완전히 삭제할 수 있습니다. 비활성 시간이 가장 긴 검색을 먼저 삭제하세요. 삭제된 검색이 다시 활성화되면 오류 상태가 발생하여 캐싱 레이어가 검색을 다시 시작하도록 강제할 수 있습니다.
페이지로 이동
사용자가 현재 페이지의 주변 페이지뿐만 아니라 검색 결과의 특정 페이지로도 이동할 수 있게 하려면 주변 페이지로 이동에 설명된 것과 비슷한 캐싱 레이어를 사용할 수 있습니다. 그러나 사용자가 검색 결과의 임의 앱 페이지로 이동할 수 있게 하려면 검색 결과를 모두 미리 가져오고 캐시해야 합니다. 검색 결과 수가 비교적 작으면 이것이 가능합니다. 검색 결과 수가 매우 크면 이를 모두 가져오는 것이 불가능하거나 비실용적일 수 있습니다. 검색 결과 수가 보통이더라도 이를 미리 가져오는 데 걸리는 시간은 사용자가 일반적으로 기다릴 수 있는 시간보다 오래 걸릴 수 있습니다.
워크플로
주변 페이지로 이동과 비슷한 방식으로 워크플로를 설정합니다. 여기에서 주요 차이점은 모든 일치 항목이 반환되거나 다른 미리 정의된 한도에 도달할 때까지 앱이 백그라운드에서 검색 결과를 계속 미리 가져온다는 것입니다.
이 솔루션의 워크플로 예시는 다음과 같습니다.
사용자의 검색 결과에서 첫 번째 검색 결과 페이지를 미리 가져오도록 앱이
fhir.search메서드를 호출합니다. 반환할 추가 결과가 없으면 응답에 페이지로 나누기 URL(Bundle.link.url)이 포함됩니다. 응답에는 또한 검색 합계(Bundle.total)가 포함됩니다. 반환할 결과가 더 있으면 이것이 추정 값입니다.앱이 응답의 일치 항목을 일치 항목 수가 각각 20개인 앱 페이지로 그룹화하고 이를 캐시에 저장합니다. 앱 페이지는 앱이 사용자에게 표시할 수 있는 일치 항목이 포함된 작은 그룹입니다.
앱이 사용자에게 첫 번째 앱 페이지를 표시합니다. 앱 페이지에는 캐시된 앱 페이지 링크와 예상된 검색 합계가 포함됩니다.
반환할 결과가 더 있으면 앱이 다음을 수행합니다.
- 이전 미리 가져오기로부터 반환된 페이지로 나누기 URL을 호출하여 검색 결과의 다음 페이지를 가져옵니다.
- 응답의 일치 항목을 일치 항목 수가 각각 20개인 앱 페이지로 그룹화하고 이를 캐시에 저장합니다.
- 새로 미리 가져오고 캐시된 앱 페이지에 대한 새로운 링크를 사용해서 사용자가 현재 보고 있는 앱 페이지를 새로고침합니다.
반환할 추가 결과가 없을 때까지 또는 다른 미리 정의된 한도에 도달할 때까지 앱이 이전 단계를 반복합니다. 검색 결과의 마지막 페이지와 함께 정확한 검색 합계가 반환됩니다.
앱이 백그라운드에서 일치 항목을 미리 가져오고 캐시하는 동안 사용자는 캐시된 페이지에 대한 링크를 계속 클릭할 수 있습니다.
설계 옵션
사용 사례에 따라 고려할 설계 옵션은 다음과 같습니다.
앱 페이지 크기. 사용 사례에 따라 앱 페이지에 20개 이상 또는 이하의 일치 항목을 포함할 수 있습니다. 페이지가 더 작으면 더 빠르게 로드되고, 한 페이지에 링크가 너무 많으면 사용자가 관리하기 어려울 수 있습니다.
검색 합계를 새로고침합니다. 앱이 백그라운드에서 검색 결과를 미리 가져오고 캐시하는 경우 점진적으로 더 정확한 검색 결과를 사용자에게 표시할 수 있습니다. 이렇게 하려면 다음을 수행하도록 앱을 구성합니다.
설정된 간격에 따라 캐싱 레이어에서 최근 미리 가져오기의 검색 합계(
Bundle.total속성)를 가져옵니다. 이는 검색 합계에 대한 현재 최상의 추정 값입니다. 검색 합계를 사용자에게 표시하고, 추정 값임을 나타냅니다. 사용 사례에 따라 이 새로고침의 빈도를 결정합니다.캐싱 레이어의 검색 합계가 정확한 시간을 인식합니다. 즉, 검색 합계가 검색 결과의 마지막 페이지에서 가져온 경우입니다. 검색 결과의 마지막 페이지에 도달하면 앱이 검색 합계를 표시하고 사용자에게 검색 합계가 정확하다는 것을 나타냅니다. 그런 다음 앱이 캐싱 레이어에서 검색 합계 가져오기를 중지합니다.
일치 항목 수가 많으면 백그라운드 사용자가 검색 세션을 완료하기 전에 미리 가져오기 및 캐싱이 검색 결과의 마지막 페이지(및 정확한 검색 합계)에 도달하지 못할 수 있습니다.
권장사항
포함된 리소스를 중복 삭제합니다. 검색 결과를 미리 가져오고 캐시할 때
_include및_revinclude매개변수를 사용할 경우 각 미리 가져오기 이후 캐시에서 포함된 리소스를 중복 삭제하는 것이 좋습니다. 이렇게 하면 캐시 크기를 줄여서 메모리를 절약하는 데 도움이 됩니다. 일치 항목을 앱 페이지로 그룹화할 때는 적합한 포함된 리소스를 각 앱 페이지에 추가합니다. 자세한 내용은 검색 결과에 추가 리소스 포함을 참조하세요.사전 가져오기 및 캐싱에 한도를 설정합니다. 검색 결과 수가 매우 크면 이를 모두 가져오는 것이 불가능하거나 비실용적일 수 있습니다. 사전 가져오기를 수행할 검색 결과 수에 한도를 설정하는 것이 좋습니다. 이렇게 하면 캐시를 관리 가능한 상태로 유지할 수 있고 메모리를 절약하는 데 도움이 됩니다. 예를 들어 캐시 크기를 10,000개 또는 20,000개의 일치 항목으로 제한할 수 있습니다. 또는 미리 가져올 페이지 수를 제한하거나 미리 가져오기가 중지되는 제한 시간을 설정할 수 있습니다. 설정할 한도 유형과 설정 방법은 사용 사례에 따라 달라지는 설계 시 의사 결정 요소입니다. 모든 검색 결과가 반환되기 전 한도에 도달할 경우 검색 합계가 추정 값이라는 것을 포함하여 이를 사용자에게 나타내는 것이 좋습니다.
프런트엔드 캐싱
웹브라우저 또는 모바일 앱과 같은 애플리케이션 프런트엔드는 아키텍처에 캐싱 레이어를 도입하는 대신 검색 결과 캐싱을 제공할 수 있습니다. 이 접근 방법은 AJAX 호출을 활용하고 검색 결과 또는 페이지로 나누기 URL을 저장하여 이전 페이지 또는 이동 기록의 임의 페이지에 대한 이동 기능을 제공할 수 있습니다. 이 접근 방법의 이점은 다음과 같습니다.
- 캐싱 레이어보다 리소스 집중도가 낮습니다.
- 캐싱 작업을 여러 클라이언트에 걸쳐 분산하므로 확장성이 뛰어납니다.
- 사용자가 탭을 닫거나 검색 엔터페이스를 벗어나는 경우와 같이 캐시된 리소스가 더 이상 필요하지 않은 경우 이를 쉽게 확인할 수 있습니다.
일반 권장사항
이 문서의 모든 솔루션에 적용되는 권장사항은 다음과 같습니다.
페이지를 _count 값보다 작은 값으로 계획합니다. 일부 상황에서는 지정한
_count값보다 적은 수의 일치 항목을 포함하는 페이지가 검색으로 반환될 수 있습니다. 예를 들어 특히 큰 페이지 크기를 지정할 경우에 이러한 상황이 발생할 수 있습니다._count값보다 작은 페이지가 검색으로 반환되고 앱에 캐싱 레이어가 사용되는 경우에는 (1) 앱 페이지에서 예상한 것보다 적은 수의 결과를 표시하거나 (2) 전체 앱 페이지에 충분하도록 조금 더 결과를 가져올지 여부를 결정해야 할 수 있습니다. 자세한 내용은 페이지로 나누기 및 정렬을 참조하세요.재시도 가능한 HTTP 요청 오류를 재시도합니다. 앱이
429또는500과 같은 재시도 가능한 HTTP 요청 오류를 예상하고 이를 수신한 후 다시 시도해야 합니다.
사용 사례 평가
모든 페이지로 이동, 정확한 검색 합계 가져오기, 예상 합계 업데이트와 같은 기능을 구현하면 앱의 복잡성과 개발 비용이 증가합니다. 이러한 기능은 또한 지연 시간을 늘리고, Google Cloud 리소스 사용에 대한 현금 비용을 늘립니다. 이러한 기능의 가치와 비용을 잘 따져서 사용 사례를 신중하게 평가하는 것이 좋습니다. 다음과 같은 사항을 고려해 보시기 바랍니다.
임의 페이지로 이동합니다. 사용자는 일반적으로 현재 페이지에서 특정 페이지나 많은 페이지로 이동할 필요가 없습니다. 대부분의 경우에는 주변 페이지로 이동하는 것이 적합합니다.
정확한 검색 합계. 검색 합계는 FHIR 저장소의 리소스가 생성, 업데이트 및 삭제됨에 따라 변경될 수 있습니다. 따라서 정확한 검색 합계는 검색 결과의 마지막 페이지와 함께 반환된 순간에 정확하지만 시간 경과에 따라 정확도가 유지되지 않을 수 있습니다. 따라서 사용 사례에 따라 해당 앱에서 정확한 검색 합계가 제한적일 수 있습니다.