Menerapkan penomoran halaman dan total penelusuran dengan penelusuran FHIR

Implementasi penelusuran FHIR Cloud Healthcare API sangat skalabel dan berperforma cukup baik dengan tetap mengikuti panduan serta batasan REST dan spesifikasi FHIR. Untuk membantu mencapai hal ini, penelusuran FHIR memiliki properti berikut:

  • Total penelusuran berupa perkiraan hingga halaman terakhir ditampilkan. Hasil penelusuran yang ditampilkan oleh metode fhir.search mencakup total penelusuran (properti Bundle.total), yang merupakan jumlah total kecocokan dalam penelusuran. Total penelusuran merupakan perkiraan hingga halaman terakhir hasil penelusuran ditampilkan. Total pencarian yang ditampilkan dengan halaman hasil terakhir adalah jumlah akurat dari semua kecocokan dalam pencarian.

  • Hasil penelusuran memberikan penomoran halaman yang berurutan dan maju. Jika ada lebih banyak hasil penelusuran yang akan ditampilkan, respons akan menyertakan URL penomoran halaman (Bundle.link.url) untuk mendapatkan halaman hasil berikutnya.

Kasus penggunaan dasar

Penelusuran FHIR memberikan solusi untuk kasus penggunaan berikut:

Lihat bagian berikut untuk solusi yang memungkinkan untuk kasus penggunaan ini.

Menjelajah secara berurutan

Anda dapat mem-build aplikasi berlatensi rendah yang memungkinkan pengguna menjelajah maju secara berurutan melalui halaman hasil hingga pengguna menemukan kecocokan yang mereka inginkan. Solusi ini dapat dilakukan jika jumlah kecocokan cukup kecil sehingga pengguna dapat menemukan kecocokan yang diinginkan dengan menjelajahi halaman demi halaman tanpa melewati hasil. Jika kasus penggunaan Anda mengharuskan pengguna untuk menavigasi maju beberapa halaman sekaligus, atau menavigasi mundur, lihat Menavigasi ke halaman terdekat.

Solusi ini tidak dapat memberikan total penelusuran yang akurat hingga halaman terakhir hasil ditampilkan. Namun, alat ini dapat memberikan perkiraan total penelusuran dengan setiap halaman hasil. Meskipun total penelusuran yang akurat dapat menjadi persyaratan untuk proses latar belakang, perkiraan total penelusuran biasanya memadai untuk pengguna manusia.

Alur kerja

Berikut adalah contoh alur kerja untuk solusi ini:

  1. Aplikasi memanggil metode fhir.search, yang menampilkan halaman pertama hasil penelusuran. Respons akan menyertakan URL penomoran halaman (Bundle.link.url) jika ada lebih banyak hasil yang akan ditampilkan. Respons ini juga menyertakan total penelusuran (Bundle.total). Jika ada lebih banyak hasil yang dapat ditampilkan daripada yang ada dalam respons awal, total penelusuran hanyalah perkiraan. Untuk informasi selengkapnya, lihat Penomoran halaman dan pengurutan.

  2. Aplikasi menampilkan halaman hasil penelusuran, link ke halaman hasil berikutnya (jika ada), dan total penelusuran.

  3. Jika ingin melihat halaman hasil berikutnya, pengguna harus mengklik link, yang akan menghasilkan panggilan ke URL penomoran halaman. Responsnya akan menyertakan URL penomoran halaman baru jika ada lebih banyak hasil yang akan ditampilkan. Responsnya juga menyertakan total penelusuran. Ini adalah estimasi yang diperbarui jika ada lebih banyak hasil yang akan ditampilkan.

  4. Aplikasi akan menampilkan halaman baru hasil penelusuran, link ke halaman hasil berikutnya (jika ada), dan total penelusuran.

  5. Dua langkah sebelumnya akan diulang hingga pengguna berhenti melakukan penelusuran atau halaman hasil terakhir ditampilkan.

Praktik terbaik

Pilih ukuran halaman yang sesuai untuk dibaca manusia tanpa kesulitan. Bergantung pada kasus penggunaan Anda, kecocokan ini mungkin mencapai 10 hingga 20 per halaman. Halaman yang lebih kecil dimuat lebih cepat, dan terlalu banyak link di halaman bisa sulit dikelola pengguna. Anda dapat mengontrol ukuran halaman dengan parameter _count.

Memproses sekumpulan hasil penelusuran

Anda bisa mendapatkan sekumpulan hasil penelusuran dengan melakukan panggilan berturut-turut ke metode fhir.search menggunakan URL penomoran halaman. Jika jumlah hasil penelusuran cukup sedikit, Anda bisa mendapatkan serangkaian hasil lengkap dengan melanjutkan hingga tidak ada halaman lagi yang ditampilkan. Total penelusuran yang akurat dimasukkan di halaman terakhir hasil. Setelah mendapatkan hasil penelusuran, aplikasi Anda dapat membacanya dan melakukan pemrosesan, analisis, atau penggabungan apa pun yang Anda perlukan.

Perlu diingat bahwa jika Anda memiliki hasil penelusuran dalam jumlah yang sangat besar, Anda mungkin tidak dapat membuka halaman terakhir hasil penelusuran (dan total penelusuran yang akurat) dalam waktu yang singkat.

Alur kerja

Berikut adalah contoh alur kerja untuk solusi ini:

  1. Aplikasi memanggil metode fhir.search, yang menampilkan halaman pertama hasil penelusuran. Responsnya menyertakan URL penomoran halaman (Bundle.link.url) jika ada lebih banyak hasil yang akan ditampilkan.

  2. Jika ada lebih banyak hasil yang akan ditampilkan, aplikasi akan memanggil URL penomoran halaman dari langkah sebelumnya untuk mendapatkan halaman hasil penelusuran berikutnya.

  3. Aplikasi mengulangi langkah sebelumnya hingga tidak ada lagi hasil yang ditampilkan atau batas lain yang telah ditentukan tercapai. Jika Anda sampai di halaman terakhir hasil penelusuran, total penelusuran sudah akurat.

  4. Aplikasi memproses hasil penelusuran.

Bergantung pada kasus penggunaan, aplikasi Anda dapat melakukan salah satu hal berikut:

  • Tunggu hingga semua hasil penelusuran diterima sebelum memproses data.
  • Memproses data saat diterima dengan setiap panggilan berturut-turut ke fhir.search.
  • Menetapkan jenis batas, seperti jumlah kecocokan yang ditampilkan atau jumlah waktu yang berlalu. Ketika batas ini tercapai, Anda dapat memproses data, bukan memproses data tersebut, atau melakukan tindakan lainnya.

Opsi desain

Berikut beberapa opsi desain yang dapat mengurangi latensi penelusuran:

  • Tetapkan ukuran halaman yang besar. Gunakan parameter _count untuk menetapkan ukuran halaman yang besar, mungkin 500 hingga 1.000, bergantung pada kasus penggunaan Anda. Menggunakan ukuran halaman yang lebih besar akan meningkatkan latensi untuk setiap pengambilan halaman, tetapi dapat mempercepat proses secara keseluruhan, karena pengambilan halaman yang diperlukan lebih sedikit untuk mendapatkan seluruh kumpulan hasil penelusuran.

  • Membatasi hasil penelusuran. Jika yang Anda butuhkan hanyalah total penelusuran yang akurat (Anda tidak perlu menampilkan konten resource), tetapkan parameter _elements metode fhir.search ke identifier. Hal ini dapat mengurangi latensi kueri penelusuran Anda, dibandingkan dengan meminta ditampilkannya resource FHIR penuh. Untuk mengetahui informasi selengkapnya, lihat Membatasi kolom yang ditampilkan di hasil penelusuran.

Kasus penggunaan yang memerlukan pengambilan data dan penyimpanan dalam cache

Anda mungkin memerlukan fungsionalitas di luar yang memungkinkan, menggunakan mekanisme sederhana untuk memanggil metode fhir.search secara berurutan menggunakan URL penomoran halaman. Salah satu kemungkinannya adalah mem-build lapisan cache antara aplikasi Anda dan penyimpanan FHIR yang mempertahankan status sesi saat mengambil data dan meng-cache hasil penelusuran. Aplikasi dapat mengelompokkan hasil penelusuran ke dalam "halaman aplikasi" kecil dengan 10 atau 20 kecocokan. Selanjutnya, aplikasi dapat menayangkan halaman aplikasi kecil ini dengan cepat kepada pengguna secara langsung dan tidak berurutan, berdasarkan pilihan pengguna. Lihat Membuka halaman terdekat untuk mengetahui contoh jenis alur kerja ini.

Anda dapat membuat solusi latensi rendah yang memungkinkan pengguna menjelajahi sejumlah besar hasil penelusuran sampai menemukan hasil yang mereka cari. API ini dapat melakukan penskalaan hingga jumlah kecocokan yang hampir tak terbatas dengan tetap menjaga latensi tetap rendah dan menimbulkan peningkatan konsumsi resource yang relatif kecil. Pengguna dapat langsung membuka halaman hasil penelusuran, hingga sejumlah halaman maju atau mundur dari halaman saat ini yang telah ditentukan. Anda dapat memberikan estimasi total penelusuran dengan setiap halaman hasil. Sebagai referensi, desain ini mirip dengan desain untuk Google Penelusuran.

Alur kerja

Gambar 1 menunjukkan contoh alur kerja untuk solusi ini. Dengan alur kerja ini, setiap kali pengguna memilih halaman hasil untuk dilihat, aplikasi akan memberikan link ke halaman terdekat. Dalam hal ini, aplikasi memberikan link ke halaman hingga lima halaman mundur dari halaman yang dipilih dan hingga empat halaman maju dari halaman yang dipilih. Agar empat halaman maju dapat dilihat, aplikasi mengambil data 40 halaman tambahan yang cocok saat pengguna memilih halaman hasil.

pengambilan data dan cache

Gambar 1. Aplikasi mengelompokkan hasil penelusuran ke dalam "halaman aplikasi" yang di-cache dan tersedia bagi pengguna.

Gambar 1 menggambarkan langkah-langkah ini:

  1. Pengguna memasukkan kueri penelusuran ke frontend aplikasi, yang memulai tindakan berikut:

    1. Aplikasi memanggil metode fhir.search untuk mengambil data halaman pertama hasil penelusuran.

      Parameter _count disetel ke 100 agar ukuran halaman respons tetap relatif kecil, sehingga menghasilkan waktu respons yang relatif cepat. Respons akan menyertakan URL penomoran halaman (Bundle.link.url) jika ada lebih banyak hasil untuk ditampilkan. Responsnya juga mencakup total penelusuran (Bundle.total). Total penelusuran merupakan perkiraan jika ada lebih banyak hasil yang akan ditampilkan. Untuk informasi selengkapnya, lihat Penomoran halaman dan pengurutan.

    2. Aplikasi mengirimkan respons ke lapisan cache.

  2. Di lapisan cache, aplikasi mengelompokkan 100 kecocokan dari respons ke dalam 10 halaman aplikasi yang masing-masing berisi 10 kecocokan. Halaman aplikasi adalah pengelompokan kecil kecocokan yang dapat ditampilkan aplikasi kepada pengguna.

  3. Aplikasi menampilkan halaman 1 aplikasi kepada pengguna. Halaman aplikasi 1 menyertakan link ke halaman aplikasi 2-10 dan estimasi total penelusuran.

  4. Pengguna mengklik link ke halaman aplikasi yang berbeda (halaman aplikasi 10 dalam contoh ini), yang memulai tindakan berikut:

    1. Aplikasi akan memanggil metode fhir.search, menggunakan URL penomoran halaman yang ditampilkan dengan pengambilan data sebelumnya, untuk mengambil data halaman hasil penelusuran berikutnya.

      Parameter _count disetel ke 40 untuk mengambil data 40 kecocokan berikutnya dari kueri penelusuran pengguna. 40 kecocokan tersebut adalah untuk empat halaman aplikasi berikutnya yang disediakan aplikasi kepada pengguna.

    2. Aplikasi mengirimkan respons ke lapisan cache.

  5. Di lapisan cache, aplikasi mengelompokkan 40 kecocokan dari respons ke dalam empat halaman aplikasi yang masing-masing berisi 10 kecocokan.

  6. Aplikasi menampilkan halaman 10 kepada pengguna. Halaman aplikasi 10 menyertakan link ke halaman aplikasi 5-9 (lima halaman aplikasi mundur dari halaman aplikasi 10) dan link ke halaman aplikasi 11-14 (empat halaman aplikasi maju dari halaman aplikasi 10). Halaman aplikasi 10 juga menyertakan estimasi total penelusuran.

Ini dapat berlanjut selama pengguna ingin terus mengklik link ke halaman aplikasi. Perhatikan bahwa jika pengguna menavigasi mundur dari halaman aplikasi saat ini dan Anda sudah meng-cache semua halaman aplikasi di sekitar, Anda dapat memilih untuk tidak melakukan pengambilan data baru, bergantung pada kasus penggunaan Anda.

Solusi ini cepat dan efisien karena alasan berikut:

  • Pengambilan data yang kecil, dan bahkan halaman aplikasi yang lebih kecil, akan diproses dengan cepat.
  • Hasil penelusuran yang disimpan dalam cache mengurangi kebutuhan melakukan beberapa panggilan untuk hasil yang sama.
  • Mekanismenya tetap cepat terlepas dari seberapa tinggi skala jumlah hasil penelusuran.

Opsi desain

Berikut adalah beberapa opsi desain yang dapat dipertimbangkan, bergantung pada kasus penggunaan Anda:

  • Ukuran halaman aplikasi. Halaman aplikasi Anda dapat berisi lebih dari 10 kecocokan jika sesuai dengan kasus penggunaan Anda. Perlu diingat bahwa halaman yang lebih kecil dimuat lebih cepat, dan terlalu banyak link pada halaman dapat menyulitkan pengguna untuk mengelolanya.

  • Jumlah link halaman aplikasi. Dalam alur kerja yang disarankan di sini, setiap halaman aplikasi menampilkan sembilan link ke halaman aplikasi lain: lima link ke halaman aplikasi yang mengarah kembali dari halaman aplikasi saat ini secara langsung, dan empat link ke halaman yang diteruskan langsung dari halaman aplikasi saat ini. Anda dapat menyesuaikan angka ini sesuai dengan kasus penggunaan Anda.

Praktik terbaik

  • Gunakan lapisan cache hanya jika diperlukan. Jika Anda menyiapkan lapisan cache, gunakan lapisan tersebut hanya ketika kasus penggunaan Anda memerlukannya. Penelusuran yang tidak memerlukan lapisan cache akan mengabaikannya.

  • Kurangi ukuran cache. Untuk menghemat resource, Anda dapat mengurangi ukuran cache dengan menghapus permanen hasil penelusuran lama sekaligus mempertahankan URL halaman yang digunakan untuk mendapatkan hasil tersebut. Selanjutnya, Anda dapat merekonstruksi cache sesuai kebutuhan dengan memanggil URL halaman. Ingat bahwa hasil dari beberapa panggilan ke URL penomoran halaman yang sama dapat berubah seiring waktu, karena resource di penyimpanan FHIR dibuat, diperbarui, dan dihapus di latar belakang. Apakah akan menghapus permanen, cara menghapus, dan seberapa sering cache dihapus adalah keputusan desain yang bergantung pada kasus penggunaan Anda.

  • Menghapus cache Anda selama penelusuran tertentu. Untuk menghemat resource, Anda dapat menghapus sepenuhnya hasil dari penelusuran tidak aktif dari cache. Pertimbangkan untuk menghapus penelusuran tidak aktif terpanjang terlebih dahulu. Perlu diingat bahwa jika penelusuran yang dihapus permanen menjadi aktif lagi, hal ini dapat menyebabkan status error yang memaksa lapisan cache untuk memulai ulang penelusuran.

Jika Anda ingin pengguna dapat membuka halaman mana pun dalam hasil penelusuran, bukan hanya halaman di sekitar halaman saat ini, Anda dapat menggunakan lapisan cache yang mirip dengan yang dijelaskan di Membuka halaman terdekat. Namun, agar pengguna dapat membuka halaman aplikasi apa pun dari hasil penelusuran, Anda harus mengambil data dan meng-cache semua hasil penelusuran. Hal ini dapat dilakukan dengan jumlah hasil penelusuran yang relatif kecil. Dengan jumlah hasil penelusuran yang sangat besar, mengambil data semuanya dapat menjadi tidak praktis atau tidak mungkin dilakukan. Meskipun dengan hasil penelusuran yang sedikit, waktu yang diperlukan untuk mengambil data hasil tersebut bisa lebih lama daripada yang wajar jika pengguna menunggu.

Alur kerja

Siapkan alur kerja yang mirip dengan Membuka halaman di sekitar, dengan perbedaan utama ini: aplikasi terus mengambil data hasil penelusuran di latar belakang hingga semua kecocokan ditampilkan atau beberapa batas lain yang telah ditentukan tercapai.

Berikut adalah contoh alur kerja untuk solusi ini:

  1. Aplikasi memanggil metode fhir.search untuk mengambil data halaman pertama hasil penelusuran dari kueri penelusuran pengguna. Respons menyertakan URL penomoran halaman (Bundle.link.url) jika ada lebih banyak hasil yang akan ditampilkan. Respons ini juga mencakup total penelusuran (Bundle.total). Ini adalah perkiraan apakah ada lebih banyak hasil yang akan ditampilkan.

  2. Aplikasi mengelompokkan hasil yang cocok dari respons ke dalam halaman aplikasi yang berisi 20 kecocokan dan menyimpannya dalam cache. Halaman aplikasi adalah sekelompok kecil kecocokan yang dapat ditampilkan aplikasi kepada pengguna.

  3. Aplikasi menampilkan halaman aplikasi pertama kepada pengguna. Halaman aplikasi menyertakan link ke halaman aplikasi yang disimpan dalam cache dan perkiraan total penelusuran.

  4. Jika ada lebih banyak hasil untuk ditampilkan, aplikasi akan melakukan hal berikut:

    • Memanggil URL penomoran halaman yang ditampilkan dari pengambilan data sebelumnya untuk mendapatkan halaman hasil penelusuran berikutnya.
    • Mengelompokkan hasil yang cocok dari respons ke dalam halaman aplikasi yang masing-masing berisi 20 kecocokan dan menyimpannya dalam cache.
    • Memuat ulang halaman aplikasi yang saat ini dilihat pengguna dengan link baru ke halaman aplikasi yang baru saja diambil data dan di-cache.
  5. Aplikasi mengulangi langkah sebelumnya hingga tidak ada lagi hasil yang ditampilkan atau batas lain yang telah ditentukan tercapai. Total penelusuran yang akurat ditampilkan dengan halaman terakhir hasil penelusuran.

Saat aplikasi mengambil data dan meng-cache hasil yang cocok di latar belakang, pengguna dapat terus mengklik link ke halaman yang di-cache.

Opsi desain

Berikut adalah beberapa opsi desain yang dapat dipertimbangkan, bergantung pada kasus penggunaan Anda:

  • Ukuran halaman aplikasi. Halaman aplikasi Anda dapat berisi lebih atau kurang dari 20 kecocokan jika sesuai dengan kasus penggunaan Anda. Perlu diingat bahwa halaman yang lebih kecil dimuat lebih cepat, dan terlalu banyak link di suatu halaman dapat sulit dikelola oleh pengguna.

  • Muat ulang total penelusuran. Saat aplikasi mengambil data dan meng-cache hasil penelusuran di latar belakang, Anda dapat menampilkan total penelusuran yang secara bertahap lebih akurat kepada pengguna. Untuk melakukannya, konfigurasi aplikasi Anda untuk melakukan hal berikut:

    • Pada interval yang ditetapkan, dapatkan total penelusuran (properti Bundle.total) dari pengambilan data terbaru di lapisan cache. Ini adalah perkiraan terbaik saat ini dari total pencarian. Menampilkan total penelusuran kepada pengguna, yang menunjukkan bahwa itu adalah perkiraan. Tentukan frekuensi refresh ini berdasarkan kasus penggunaan Anda.

    • Mengenali kapan total penelusuran dari lapisan cache sudah akurat. Artinya, total penelusuran berasal dari halaman terakhir hasil penelusuran. Saat halaman terakhir hasil penelusuran tercapai, aplikasi akan menampilkan total penelusuran dan menunjukkan kepada pengguna bahwa total penelusuran akurat. Aplikasi kemudian berhenti mendapatkan total penelusuran dari lapisan cache.

    Perhatikan bahwa dengan banyak kecocokan, pengambilan data latar belakang dan penyimpanan cache mungkin tidak mencapai halaman terakhir hasil penelusuran (dan total penelusuran yang akurat) sebelum pengguna menyelesaikan sesi penelusuran mereka.

Praktik terbaik

  • Hapus duplikat resource yang disertakan. Jika Anda menggunakan parameter _include dan _revinclude saat mengambil data dan meng-cache hasil penelusuran, sebaiknya hapus duplikat resource yang disertakan dalam cache setelah setiap pengambilan data. Ini akan membantu menghemat memori dengan mengurangi ukuran cache Anda. Saat Anda mengelompokkan kecocokan ke dalam halaman aplikasi, tambahkan resource yang disertakan yang sesuai ke setiap halaman aplikasi. Untuk informasi selengkapnya, lihat Menyertakan resource tambahan dalam hasil penelusuran.

  • Tetapkan batas pengambilan data dan penyimpanan cache. Dengan jumlah hasil penelusuran yang sangat besar, mengambil data semuanya dapat menjadi tidak praktis atau tidak mungkin dilakukan. Sebaiknya tetapkan batas jumlah hasil penelusuran yang akan diambil data-nya. Tindakan ini akan membuat cache Anda tetap dalam ukuran yang mudah dikelola dan membantu menghemat memori. Misalnya, Anda dapat membatasi ukuran cache hingga 10.000 atau 20.000 kecocokan. Atau, Anda dapat membatasi jumlah halaman untuk pengambilan data, atau menetapkan batas waktu setelah pengambilan data berhenti. Jenis batasan yang Anda terapkan dan cara menerapkannya adalah keputusan desain yang bergantung pada kasus penggunaan Anda. Jika batas ini tercapai sebelum semua hasil penelusuran ditampilkan, pertimbangkan untuk menunjukkan hal ini kepada pengguna, termasuk bahwa total penelusuran masih berupa perkiraan.

Cache frontend

Frontend aplikasi, seperti browser web atau aplikasi seluler, dapat menyediakan beberapa cache hasil penelusuran sebagai alternatif untuk memasukkan lapisan cache ke dalam arsitektur. Pendekatan ini dapat memberikan navigasi ke halaman sebelumnya, atau halaman apa pun di histori navigasi, dengan memanfaatkan panggilan AJAX serta menyimpan hasil penelusuran dan/atau URL penomoran halaman. Berikut adalah beberapa keuntungan dari pendekatan ini:

  • Fungsi ini dapat menjadi lebih sedikit menggunakan resource yang intensif daripada lapisan cache.
  • Penskalaan ini lebih skalabel karena mendistribusikan tugas caching di banyak klien.
  • Lebih mudah untuk menentukan kapan resource yang di-cache tidak lagi diperlukan — misalnya, saat pengguna menutup tab atau keluar dari antarmuka penelusuran.

Praktik terbaik umum

Berikut adalah beberapa praktik terbaik yang berlaku untuk semua solusi dalam dokumen ini.

  • Rencanakan untuk halaman yang lebih kecil dari nilai _count. Dalam beberapa situasi, penelusuran mungkin menampilkan halaman yang berisi lebih sedikit kecocokan daripada nilai _count yang Anda tetapkan. Misalnya, hal ini dapat terjadi jika Anda menentukan ukuran halaman yang sangat besar. Jika penelusuran menampilkan halaman yang lebih kecil dari nilai _count, dan aplikasi Anda menggunakan lapisan cache, Anda mungkin perlu memutuskan apakah akan (1) Menampilkan hasil yang lebih sedikit daripada yang diharapkan di halaman aplikasi, atau (2) Mengambil beberapa hasil lagi agar mendapatkan cukup untuk menyelesaikan halaman aplikasi. Untuk informasi selengkapnya, lihat Penomoran halaman dan pengurutan.

  • Mengulangi error permintaan HTTP yang dapat dicoba lagi. Aplikasi Anda akan mengalami error permintaan HTTP yang dapat dicoba lagi, seperti 429 atau 500, dan mencoba lagi setelah menerimanya.

Mengevaluasi kasus penggunaan Anda

Menerapkan fitur seperti membuka halaman mana pun, mendapatkan total penelusuran yang akurat, dan memperbarui estimasi total akan meningkatkan kompleksitas dan biaya pengembangan aplikasi Anda. Fitur ini juga dapat meningkatkan latensi dan menaikkan biaya uang untuk penggunaan resource Google Cloud. Sebaiknya evaluasi kasus penggunaan Anda dengan cermat untuk memastikan nilai fitur ini sesuai dengan biaya yang dikeluarkan. Berikut ini beberapa hal yang perlu dipertimbangkan:

  • Membuka halaman mana pun. Pengguna biasanya tidak perlu membuka halaman tertentu, banyak halaman dari halaman saat ini. Pada umumnya, Menavigasi ke halaman terdekat sudah cukup.

  • Total penelusuran yang akurat. Jumlah total penelusuran dapat berubah seiring dibuat, diperbarui, dan dihapus resource di penyimpanan FHIR. Karena alasan ini, total penelusuran yang akurat sudah akurat pada saat ditampilkan (dengan halaman terakhir hasil penelusuran), tetapi mungkin tidak tetap akurat dari waktu ke waktu. Oleh karena itu, total penelusuran yang akurat mungkin memiliki nilai terbatas untuk aplikasi Anda, bergantung pada kasus penggunaan Anda.