1.5. 検索

HL7®FHIR®規格では検索クエリに使用できるパラメータはSearchParameterリソースとして定義されており，検索クエリはSearchParameterリソースのname, valueを用いて

GET [base]/[type]?name=value&...

と表現される。

具体的には、

GET [base]/Patient?gender=male

という検索クエリにおける"gender"はPatientリソースにおけるgenderプロパティを指しているのではなく，Patientリソースに対応したid=individual-genderというSearchParameterリソースのname属性を示しており，このindividual-genderというSearchParameterリソースが検索対象としてPatient.genderを指定しているという構造になっている。

各SearchParameterにはtypeが定義されており、typeごとに検索条件や対象とするDatatype, 各Datatypeで検索するフィールドなどが定義されている。また，各typeには，検索時に使用できる:text, :notなどのmodifierを組み合わせて使用することもできる。

なお，サーバー側はクエリに一致するリソースを返すが，関連があると思われる追加の検索結果を返すことができる特権を有することに注意する。

本節では特に日本において問題となりうる機能に限って記載する。実装者は検索機能を実装するにあたり、SearchおよびSearchParameterについて十分に理解しておくよう勧められる。

1.5.1. 文字列検索

FHIR®におけるテキストについての検索は大きく4種類に分けることができる。ここではType:modifierと表すことにし，条件がある場合は適宜カッコで補足する。

case sensitiveな完全一致
- string:exact
- token (ただし2.の例外あり)
case insensitiveな完全一致
- token (CodeSystem.caseSensitiveなどによりcase insensitiveなことが示されているとき)
- token (対象のDatatypeがstringのとき)
通常のテキスト検索
- string
- string: contains
- token: text （code型などに対して、CodeableConcept.textなどのテキストデータを通常のstring型の検索を行う）
  基本的な文字列検索であり、患者名や住所，病名など検索がこのタイプである。FHIR®では，このタイプの検索において大文字小文字の同一視，アクセントや他の発音区別符号の無視，句読点と連続する空白の無視を規定している。JP Coreではこれに加えて、いわゆる全角文字（2バイト文字）と半角文字（1バイト文字）の正規化を必須とする（SHOULD）。なお、濁点半濁点の合成文字・結合文字については、発音区別符号の正規化としてFHIR®自体に規定されていると解釈される。実装上は、Unicodeの互換正規化（NFKCもしくはNFKD）に、大文字小文字の変換、句読点と連続する空白の処理を加えることで条件を満たすことができる。サーバーは検索のときに、丸付き文字（①⇔1）、数字（2⇔Ⅱ⇔II⇔二）、ひらがな⇔カタカナ、カタカナの正規化（末尾の長音記号の削除、ベ⇔ヴェなど）、新字体⇔旧字体、統合漢字⇔互換漢字、異体字セレクタの処理、住所の正規化、病名の正規化など、必要性に応じて自由に追加の正規化を行うことができる（MAY）。クライアントは、サーバーが関連があると思われる追加の検索結果を返すことができる特権を有することに注意する。
高度な全文検索(full text search)
- string: text
- _text
- _content
  _textと_contentはすべてのリソースに適応される共通のsearch parameterである。これらのSearchParameterは全文検索のためのSearchParameterであり、「テキストをインデックス化する高度な検索機能をサポートすべきである（SHOULD）」とされており，加えて類語検索やあいまい検索，AND検索・OR検索なども実装することが望ましい。

1.5.2. 人名の検索について

組織ごとに患者記録が作成，維持されており，複数の組織でケアを受けている患者は，その情報が複数のリソースに存在する可能性が高い。多くの場合は氏名による検索や、姓の変更があった場合でも下の名前＋生年月日などの検索である程度候補を絞ることが可能である。一方で日本語表記を持たない外国人など，氏名を表す音をカタカナで表現した場合その方法は一意ではなく，複数システムとの連携を行う場合において，同一人物の突合が困難になる恐れがある。

将来的に組織・システムをまたいだMaster Patient Index(MPI)が整備されることがあれば、MPIに患者の同一性を問い合わせるクエリを用いることができる。