翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # SQL を使用した HealthLake データのクエリ FHIR データを HealthLake データストアにインポートすると、ネストされた JSON FHIR データは同時に ETL プロセスを実行し、Amazon S3 の Apache Iceberg オープンテーブル形式で保存されます。HealthLake データストアの各 FHIR リソースタイプはテーブルに変換され、Amazon Athena を使用してクエリできます。SQL ベースのクエリを使用して、テーブルを個別にクエリすることも、グループとしてクエリすることもできます。データストアの構造のため、データは複数の異なるデータ型として Athena にインポートされます。これらのデータ型にアクセスできる SQL クエリの作成の詳細については、[「Amazon Athena ユーザーガイド」の「複雑な型とネストされた構造を持つ配列のクエリ](https://docs.aws.amazon.com/athena/latest/ug/rows-and-structs.html)」を参照してください。 *Amazon Athena * **注記** このトピックのすべての例では、Synthea を使用して作成された架空のデータを使用します。Synthea データでプリロードされたデータストアの作成の詳細については、「」を参照してください[HealthLake データストアの作成](managing-data-stores-create.md)。リソースタイプの各要素について、FHIR 仕様はカーディナリティを定義します。要素の基数により、この要素を表示できる回数の下限と上限が定義されます。SQL クエリを構築するときは、これを考慮する必要があります。たとえば、[リソースタイプ: 患者](https://hl7.org/fhir/R4/patient.html)の一部の要素を見てみましょう。 + **要素: Name** FHIR 仕様はカーディナリティをに設定します`0..*`。要素は配列としてキャプチャされます。 ``` [{ id = null, extension = null, use = official, _use = null, text = null, _text = null, family = Wolf938, _family = null, given = [Noel608], _given = null, prefix = null, _prefix = null, suffix = null, _suffix = null, period = null }] ``` Athena では、リソースタイプがどのように取り込まれたかを確認するには、**テーブルとビュー**でリソースタイプを検索します。この配列の要素にアクセスするには、ドット表記を使用できます。`given` との値にアクセスする簡単な例を次に示します`family`。 ``` SELECT name[1].given as FirstName, name[1].family as LastName FROM Patient ``` + **要素: MaritalStatus** FHIR 仕様では、基数をに設定します`0..1`。この要素は JSON としてキャプチャされます。 ``` { id = null, extension = null, coding = [ { id = null, extension = null, system = http: //terminology.hl7.org/CodeSystem/v3-MaritalStatus, _system = null, version = null, _version = null, code = S, _code = null, display = Never Married, _display = null, userSelected = null, _userSelected = null } ], text = Never Married, _text = null } ``` Athena では、リソースタイプがどのように取り込まれたかを確認するには、**テーブルとビュー**でリソースタイプを検索します。JSON のキーと値のペアにアクセスするには、ドット表記を使用できます。配列ではないため、配列インデックスは必要ありません。の値にアクセスする簡単な例を次に示します`text`。 ``` SELECT maritalstatus.text as MaritalStatus FROM Patient ``` JSON へのアクセスと検索の詳細については、*Athena ユーザーガイド*の「JSON の[クエリ](https://docs.aws.amazon.com//athena/latest/ug/querying-JSON.html)」を参照してください。 Athena データ操作言語 (DML) クエリステートメントは Trino に基づいています。Athena は Trino のすべての機能をサポートしているわけではなく、*大きな*違いがあります。詳細については、*Amazon Athena ユーザーガイド*」の[「DML クエリ、関数、演算子](https://docs.aws.amazon.com/athena/latest/ug/functions-operators-reference-section.html)」を参照してください。さらに、Athena は HealthLake データストアのクエリを作成するときに発生する可能性のある複数のデータ型をサポートしています。Athena のデータ型の詳細については、[Amazon Athena ユーザーガイド」の「Amazon Athena のデータ型](https://docs.aws.amazon.com/athena/latest/ug/data-types.html)」を参照してください。 *Amazon Athena * Athena での SQL クエリの仕組みの詳細については、[Amazon Athena ユーザーガイド」の「Amazon Athena の SQL リファレンス](https://docs.aws.amazon.com/athena/latest/ug/ddl-sql-reference.html)」を参照してください。 *Amazon Athena * 各タブには、Athena を使用して指定されたリソースタイプと関連する要素を検索する方法の例が表示されます。 ------ #### [ Element: Extension ] 要素は、データストアにカスタムフィールドを作成する`extension`ために使用されます。この例では、 `Patient`リソースタイプにある `extension`要素の機能にアクセスする方法を示します。 HealthLake データストアが Athena にインポートされると、リソースタイプの要素の解析は異なります。の構造`element`は可変であるため、スキーマで完全に指定することはできません。この変動性を処理するために、配列内の要素は文字列として渡されます。の表の説明には`Patient`、と`extension`記述されている要素が表示されます。つまり`array`、インデックス値を使用して配列の要素にアクセスできます。ただし、文字列の要素にアクセスするには、を使用する必要があります`json_extract`。以下は、患者テーブルにある `extension`要素からの 1 つのエントリです。 ``` [{ "valueString": "Kerry175 Cummerata161", "url": "http://hl7.org/fhir/StructureDefinition/patient-mothersMaidenName" }, { "valueAddress": { "country": "DE", "city": "Hamburg", "state": "Hamburg" }, "url": "http://hl7.org/fhir/StructureDefinition/patient-birthPlace" }, { "valueDecimal": 0.0, "url": "http://synthetichealth.github.io/synthea/disability-adjusted-life-years" }, { "valueDecimal": 5.0, "url": "http://synthetichealth.github.io/synthea/quality-adjusted-life-years" } ] ``` これは有効な JSON ですが、Athena はそれを文字列として扱います。この SQL クエリの例は、要素`patient-mothersMaidenName`と `patient-birthPlace`要素を含むテーブルを作成する方法を示しています。これらの要素にアクセスするには、異なる配列インデックスと `json_extract.` ``` SELECT extension[1], json_extract(extension[1], '$.valueString') AS MothersMaidenName, extension[2], json_extract(extension[2], '$.valueAddress.city') AS birthPlace FROM patient ``` JSON を含むクエリの詳細については、*Amazon Athena ユーザーガイド*[」の「JSON からのデータの抽出](https://docs.aws.amazon.com/athena/latest/ug/extracting-data-from-JSON.html)」を参照してください。 ------ #### [ Element: birthDate (Age) ] Age は、FHIR 内の患者リソースタイプの要素*ではありません*。年齢に基づいてフィルタリングする検索の 2 つの例を次に示します。 age は要素ではないため、SQL クエリ`birthDate`にはを使用します。要素が FHIR にどのように取り込まれたかを確認するには、テーブル**とビューでテーブル**名を検索します。**文字列**型であることがわかります。 **例 1**: 年齢の値を計算するこのサンプル SQL クエリでは、組み込みの SQL ツール `current_date`とを使用して、これらのコンポーネント`year`を抽出します。次に、これらを減算して、患者の実際の年齢をという列として返します`age`。 ``` SELECT (year(current_date) - year(date(birthdate))) as age FROM patient ``` **例 2**: 以前に生まれ`2019-01-01`、である患者のフィルタリング`male`。 SQL クエリでは、 `CAST`関数を使用して`birthDate`要素をタイプとしてキャストする方法と`DATE`、 `WHERE`句の 2 つの条件に基づいてフィルタリングする方法を示します。要素はデフォルトで型**文字列**として取り込まれる`CAST`ため、型として取り込む必要があります`DATE`。その後、 `<`演算子を使用して、別の日付と比較できます`2019-01-01`。を使用すると`AND`、 `WHERE`句に 2 番目の条件を追加できます。 ``` SELECT birthdate FROM patient -- we convert birthdate (varchar) to date > cast that as date too WHERE CAST(birthdate AS DATE) < CAST('2019-01-01' AS DATE) AND gender = 'male' ``` ------ #### [ Resource type: Location ] この例では、都市名がアトルボロである Location リソースタイプ内の場所を検索します。 ``` SELECT * FROM Location WHERE address.city='ATTLEBORO' LIMIT 10; ``` ------ #### [ Element: Age ] ``` SELECT birthdate FROM patient -- we convert birthdate (varchar) to date > cast that as date too WHERE CAST(birthdate AS DATE) < CAST('2019-01-01' AS DATE) AND gender = 'male' ``` ------ #### [ Resource type: Condition ] リソースタイプ条件は、懸念レベルに達した問題に関連する診断データを保存します。HealthLake の統合医療自然言語処理 (NLP) は、DocumentReference `Condition`リソースタイプで見つかった詳細に基づいて*新しい*リソースを生成します。新しいリソースが生成されると、HealthLake はタグを `SYSTEM_GENERATED` `meta`要素に追加します。このサンプル SQL クエリは、条件テーブルを検索し、結果が削除された`SYSTEM_GENERATED`結果を返す方法を示しています。 HealthLake の統合自然言語処理 (NLP) の詳細については、「」を参照してください[HealthLake の統合自然言語処理 (NLP)](integrating-nlp.md)。 ``` SELECT * FROM condition WHERE meta.tag[1] is NULL ``` 指定された文字列要素内で検索して、クエリをさらにフィルタリングすることもできます。`modifierextension` 要素には、一連の条件の生成に使用された`DocumentReference`リソースに関する詳細が含まれています。ここでも、 `json_extract`を使用して、文字列として Athena に取り込まれるネストされた JSON 要素にアクセスする必要があります。このサンプル SQL クエリは、特定のに基づいて`Condition`生成されたすべてのを検索する方法を示しています`DocumentReference`。`CAST` を使用して JSON 要素を文字列として設定し、 `LIKE`を使用して比較できるようにします。 ``` SELECT meta.tag[1].display as SystemGenerated, json_extract(modifierextension[4], '$.valueReference.reference') as DocumentReference FROM condition WHERE meta.tag[1].display = 'SYSTEM_GENERATED' AND CAST(json_extract(modifierextension[4], '$.valueReference.reference') as VARCHAR) LIKE '%DocumentReference/67aa0278-8111-40d0-8adc-43055eb9d18d%' ``` ------ #### [ Resource type: Observation ] リソースタイプ「オブザベーション」は、患者、デバイス、またはその他のサブジェクトについて行われた測定値と簡単なアサーションを保存します。HealthLake の統合自然言語処理 (NLP) は、`Observation`リソースで見つかった詳細に基づいて*新しい*`DocumentReference`リソースを生成します。このサンプル SQL クエリには`WHERE meta.tag[1] is NULL`コメントアウトが含まれています。つまり、`SYSTEM_GENERATED`結果が含まれます。 ``` SELECT valueCodeableConcept.coding[1].code FROM Observation WHERE valueCodeableConcept.coding[1].code = '266919005' -- WHERE meta.tag[1] is NULL ``` この列はとしてインポートされました[https://iceberg.apache.org/spec/#schemas-and-data-types](https://iceberg.apache.org/spec/#schemas-and-data-types)。したがって、ドット表記を使用して内部の要素にアクセスできます。 ------ #### [ Resource type: MedicationStatement ] MedicationStatement は、患者が使用した、使用している、または今後使用する薬剤の詳細を保存するために使用できる FHIR リソースタイプです。HealthLake の統合医療自然言語処理 (NLP) は、DocumentReference リソースタイプで見つかったドキュメントに基づいて、新しいMedicationStatement リソースを生成します。新しいリソースが生成されると、HealthLake はタグを `SYSTEM_GENERATED` `meta`要素に追加します。このサンプル SQL クエリは、識別子を使用して単一の患者に基づいてフィルタリングし、HealthLake の統合 NLP によって追加されたリソースを検索するクエリを作成する方法を示しています。 ``` SELECT * FROM medicationstatement WHERE meta.tag[1].display = 'SYSTEM_GENERATED' AND subject.reference = 'Patient/0679b7b7-937d-488a-b48d-6315b8e7003b'; ``` HealthLake の統合自然言語処理 (NLP) の詳細については、「」を参照してください[HealthLake の統合自然言語処理 (NLP)](integrating-nlp.md)。 ------