個人医療記録（PHR）データは HL7 FHIR 形式で保存されます。
PHR は、次の Fast Healthcare Interoperable Resources（FHIR）バージョンをサポートしています。
医療リソースの種類
FHIR は、リソースと呼ばれる一連のモジュラー コンポーネントで構成されています。サポートされている FHIR リソースのセットと対応するカテゴリは、おおまかに 国際患者概要セクションに基づいています。
これらのリソースは、ヘルスコネクトのデータカテゴリ（API では医療リソースの種類）にマッピングされます。観測リソースは、Logical Observation Identifiers Names and Codes（LOINC）コードや FHIR カテゴリなどのコンテンツに基づいてマッピングされます。
これらのカテゴリのいずれにも属さない測定値は、ヘルスコネクトに書き込まれません。
| ヘルスコネクトの医療リソースの種類 | FHIR リソース |
|---|---|
| アレルギー | AllergyIntolerance |
| 条件 | 条件 |
| ラボ | 問題点
|
| 服用している薬 | Medication、MedicationRequest、MedicationStatement |
| 個人の詳細 | 焦らない |
| 医療従事者の詳細 | 施術者、PractitionerRole |
| 妊娠 | 問題点
|
| 治療 | 手順 |
| 社会歴 | 問題点
|
| ワクチン | 予防接種データ |
| 受診 | 遭遇、場所、組織 |
| バイタルサイン | 問題点
|
患者向けリソース
現時点では、ヘルスコネクトは 1 人の個人の PHR データのみを保存することを目的としています。したがって、作成されたすべての FHIR リソースは同じユーザーに属している必要があります。
1 人の個人に対して複数の FHIR 患者リソースがシステムに存在することは珍しくありません。アプリでデータを調整し、単一の患者リソースをヘルスコネクトに書き込むことをおすすめします。ただし、存在する可能性のあるさまざまな組織構造に対応するため、これは強制されません。
データの検証
PHR API は、サポートされているバージョンの有効な FHIR リソースを受け入れます。Health Connect は、サポートされている各バージョンの FHIR 仕様が遵守されていることを確認するために、いくつかの検証を行います。
[近日提供予定] とマークされた検証チェックはまだ適用されていませんが、今後のリリースで適用される予定です。今後のリリースとの互換性を維持するため、リストされているすべての検証チェックに対して開発することをおすすめします。
| ステータス | 妥当性チェック | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| 有効な JSON | データが JSON 形式に準拠している。 | ||||||||
| サポートされている FHIR | 作成アプリケーションによって宣言された FHIR バージョンがサポートされています。ヘルスコネクトでサポートされている FHIR バージョンは次のとおりです。
|
||||||||
| サポートされている FHIR | リソース インスタンスに記録された FHIR リソースタイプがサポートされています。ヘルスコネクトでサポートされている FHIR リソースタイプは次のとおりです。
|
||||||||
| 一意のリソース ID | リソースの ID フィールドに、正規表現の要件を満たす値が含まれている。 | ||||||||
| 一意のリソース ID | リソースが、同じ MedicalDataSource の同じリソースタイプの別の FHIR リソースと ID を共有していない。 |
||||||||
| ビジネスルール | 含まれている FHIR リソースは含まれません。含まれるリソースは、「親」リソース内にネストされた FHIR リソースです。親リソースが別のリソースを参照する必要があるが、独立した存在としてスタンドアロン リソースとして作成するのに十分な情報がシステムにない場合に使用されます。 | ||||||||
| 有効なベース FHIR | FHIR JSON の最上位フィールドは、特定のリソースタイプの FHIR 仕様に存在します。 | ||||||||
| 有効なベース FHIR | トップレベル フィールドには JSON null 値がありません。 | ||||||||
| 有効なベース FHIR | 最上位の必須フィールドがすべて存在する。 | ||||||||
| 有効なベース FHIR | FHIR 内の繰り返し要素として定義されたトップレベル フィールドには、JSON array データ型があります。 |
||||||||
| 有効なベース FHIR | FHIR で複合型として定義されたトップレベル フィールド（JSON array 内の要素を含む）には、JSON object データ型があります。 |
||||||||
| 有効なベース FHIR | FHIR でプリミティブ型として定義されている最上位フィールド（JSON array 内の要素を含む）には、正しい JSON データ型が設定されています。
|
||||||||
| 有効なベース FHIR | FHIR でプリミティブ型として定義されたトップレベル フィールドは、正規表現の要件を満たしています。近日提供予定 | ||||||||
| 有効なベース FHIR | プリミティブ型の拡張は FHIR 仕様に存在し、JSON object データ型を持ちます。 |
||||||||
| 有効なベース FHIR | 選択フィールド（fieldname[x]）には、1 つ以上のフィールドが記録されません。たとえば、effectiveDateTime と effectivePeriod の両方を同じリソース インスタンスに存在させることはできません。 |
||||||||
| 有効なベース FHIR | 複雑なデータ型には、FHIR 仕様に一致するフィールドとデータ型が含まれています。近日提供予定 | ||||||||
| 有効なベース FHIR | バックボーン要素（および複合型内の要素）には、FHIR 仕様に一致するフィールドとデータ型が含まれています。近日提供予定 | ||||||||
| 有効なベース FHIR | Extensions 要素
value[x] フィールドは有効な型であり、そのデータ型に応じたコンテンツが含まれます。拡張機能要素は、ベース仕様に含まれない追加情報を表すために任意のリソースに含めることができます。拡張機能要素には、拡張機能の定義にリンクするフィールド url と、拡張機能の値を含むフィールド value[x] が含まれています。value[x] は、許可されるデータ型の設定リストから選択する必要があります。
近日提供予定 |
変換された FHIR データ
一部のアプリは、独自の要件を満たすように FHIR データを変換します。例:
- さまざまなソース（通常は FHIR API）のデータを統合する。
- コードをグローバルな用語（SNOMED、LOINC、ICD など）にマッピングし、単位を標準化する。
- データの統合と重複除去。
- 書式設定やその他のデータ品質の問題を修正する。
- アプリ固有のビジネスルールに基づいてレコードをフィルタリングする。
変換前または変換後の FHIR データは、FHIR R4 仕様に準拠していれば、ヘルスコネクトに書き込むことができます。可能な限り、変換されたデータを書き込むことをおすすめします。ただし、次の点に注意してください。
- ユースケースが限定的なアプリでは、エコシステム内の他のアプリがユーザー価値を生み出す可能性のある大量のレコードが除外される可能性があります。このような場合は、より完全な変換されていない FHIR を記述することをおすすめします。ただし、この広範なデータセットが共有されることをユーザーに必ず伝えてください。
- 異なるソースからのデータの統合の場合は、ヘルスコネクトの単一の
MedicalDataSourceにデータを書き込むことができます。また、競合を回避するために各リソースに新しい ID を割り当て、新しい ID を参照するようにリソース参照を更新する必要があります。 - 複数のソースのデータを 1 つの
MedicalDataSourceに統合すると、データの元が不明になる可能性があります。データ コンシューマがデータの来歴を把握することがよくあるため、各リソースのmeta.sourceフィールドにレコードの元のソース（通常は FHIR ベース URL）を入力することをおすすめします。