HL7 FHIR JP Core ImplementationGuide
1.1.2 - release
HL7 FHIR JP Core ImplementationGuide - Local Development build (v1.1.2) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
項目 | 内容 |
定義URL | http://jpfhir.jp/fhir/core/StructureDefinition/JP_DiagnosticReport_Radiology |
Version | 1.1.2 |
Name | JP_DiagnosticReport_Radiology |
Title | JP Core DiagnosticReport Radiology Profile |
Status | Active ( 2023-10-31 ) |
Copyright | Copyright FHIR Japanese implementation research working group in Japan Association of Medical Informatics (JAMI) 一般社団法人日本医療情報学会NeXEHRS課題研究会FHIR日本実装検討WG |
このプロファイルはDiagnosticReportリソースに対して、放射線検査報告書(レポート)のデータを送受信するための制約と拡張を定めたものである。
本プロファイルは、DiagnosticReportリソース のうち、放射線画像検査における患者、患者群、機器、場所、およびこれらから得られた画像に対して実施された診断結果またはその解釈を示す「報告書」を表現するリソースの定義である。ここでは、DiagnosticReport リソースに対して本プロファイルに準拠する場合に必須となる要素や、サポートすべき拡張、用語、検索パラメータを定義する。 報告書は、依頼者や撮影の情報などの臨床的背景のほか、いくつかの計測値、画像、テキストおよびコード化された解釈、テンプレート化された診断報告書により構成される。
本プロファイルは、以下のようなユースケースを想定する。
放射線検査レポートで取り扱う診断報告書は、検査の終了後に、検査の診断結果として提供される一連の情報である。 この情報には、テキストレポート、画像、コード、および計測値などが含まれる。この組み合わせは、診断手順や特定の検査の結果の性質に応じて変化する。FHIRでは、レポートはドキュメント、RESTful API、メッセージングフレームワークなど、さまざまな方法で伝達することができる。これらの方法に含まれるのは、DiagnosticReportリソースそのものである。
DiagnosticReportリソースは、診断レポート自体の他に、患者など対象者に関する情報を持つ。また、オーダに関する情報や所見の詳細、画像を参照することもできる。レポートの結論は、テキスト、構造化されたコード化データ、またはPDFなどの完全に標準化された添付レポートとして表現することができる。
もっとも典型的にはレポートの診断結果をDiagnosticReport.conclusionエレメントに保持しDiagnosticReport.presentedFormエレメントでレポート全体のデータを持つ。また、キー画像等の添付データはDiagnosticReport.mediaエレメントにMediaリソースへのリンクとして保持する。
レポート全体のデータは、レポーティングシステム等により作成された多彩な表現型(PDF, RichText, xhtml等)でBase64のAttachmentとして提供される。ただし、結果参照や検索の汎用性を担保しHuman readableな形で提供されることを目的とし、レポートの内容はDomainResourceであるDiagnosticReport.textエレメントにも格納される。
DiagnosticReportリソースは、過去の結果(リソース内での過去および現在の結果)の提示をサポートすることを意図していない。DiagnosticReportリソースは、シーケンスの構造化を含めレポートの完全なサポートをまだ提供できていないが、将来実装される予定である。
以下のリソースは関連情報として presentedForm にて参照されるレポート内に保持される可能性がある。ただし、レポートシステムの仕様に依存するため、レポートシステムでは各リソースとの相互運用性の確保に配慮することが求められる。
Patient
)Practitioner
)Observation
)Observation
)AllergyIntorelance
)media
)Observation
)Observation
)RiskAssessment
) あるいは (Observation
) 運用のフローに関連する TASK、Procedure 等のリソース定義についてはここでは触れない。 なお、読影医・確定医の専門医資格情報については、Practitioner.qualificationエレメントでの対応を検討している。
Usage:
Description of Profiles, Differentials, Snapshots and how the different presentations work.
Other representations of profile: CSV, Excel, Schematron
次のデータ項目は必須(SHALL)である。
次のデータは送信システムに存在する場合はサポートされなければならないことを意味する(Must Support)。
imagingStudyエレメントはCardinalityが0..*で 0 が許容されているが、放射線レポートでは画像が必ず存在することから、検査実施後には必須(複数の可能性もあり)である。
本プロファイルで追加定義された拡張はない。
DiagnosticReportのドメインリソースの一つであるtextエレメントに見読可能なnarrativeデータとしてレポートの所見を中心とした情報を格納する。依頼情報や患者基本情報などを含んだレポート全体のデータは別途presentedFormエレメントに保持されるが、ここではPDF等のバイナリが保存される。よってレポート内容の見読性と検索性を担保するためにtextエレメントに保存されたデータが利用され、ここはxhtmlである事が求められる。 具体的な構造については 放射線読影レポートを参照のこと
(DiagnosticReportのResourceType直下に現れる。text以外のDomainResourceの詳細についてはこちらを参照のこと)
Codeエレメントは一つの値のみが許容される。一方でIVR等の手技で血管造影検査と超音波検査あるいはCT検査が併用されることがあるように、放射線画像検査では複数のモダリティと組み合わせた複合的な検査治療手技が構成されることがある。すべての組み合わせのコードを準備あるいは列挙することは困難であるため、本バージョンの実装ガイドでは放射線検査に対する画像診断レポートにはCodeに 18748-4(画像検査報告書)を指定することを原則としている。 Codeエレメントに利用されるコードとしてJP Core Document Codes Diagnostic に定義されるコードシステムが用意されているが、粒度の細かいコードはSS-MIX2等で既に定義されているデータとの後方互換を保つ目的で用意されている点に留意が必要である。
Codeエレメントで複合的要素を表現できない点を考慮し、Categoryエレメントにて、複数のモダリティコードを指定できるように設計している点をあわせて確認すること。
Identifier のデータタイプはオーダ依頼者であるPlacerあるいはオーダの実施者であるFiller(HL7 Version 2 Messaging Standardにて’Placer’あるいは’Filler’として知られている)によって割り当てられた識別子を区別するために利用されるtypeエレメントを持っている。typeエレメントは以下の様に利用する。
{
"identifier":[{
"type":{
"coding":{
"system":"http://terminology.hl7.org/CodeSystem/v2-0203",
"code":"PLAC"
},
"text":"Placer Identifier"
},
"system":"http://abc-hospital.local/fhir/PlacerIdentifier",
"value":"2345234234234"
}]
}
{
"identifier":[{
"type":{
"coding":{
"system":"http://terminology.hl7.org/CodeSystem/v2-0203",
"code":"FILL"
},
"text":"Filler Identifier"
},
"system":"http://abc-hospital.local/fhir/FillerIdentifier",
"value":"567890"
}]
}
DiagnosticReport_Radiology リソースではtypeエレメントを明示する際にはオーダ番号やレポート番号が格納される可能性がある点に留意して対応することが重要である。
このプロファイルのリソースでは、effective[x]エレメントにはレポート作成時間をdateTimeで格納する。
DiagnosticReport.resultエレメントには関連する検体検査計測値などをしめすObservationリソースを含むことができる。
ImagingStudyやmediaは多少オーバーラップするが、使用される目的が異なる。用途に応じて使い分けること。DiagnosticReportではDICOM画像への参照としてImagingStudyが利用され、キー画像としてmediaが参照される。
典型的には放射線レポートはnarrativeな構成でのレポートが作成される。DiagnosticReport_Radiologyでは標準的なnarrativeリソースの表現としてXHTMLやrich text表現として(典型的にはPDF)がpresentedFormに指定される。
Conclusionやコード化された診断結果は各々がレポートを構成する小さなデータであるが、これらはpresentedFormに保持されるnarrativeなデータ内に含まれると同時に、本リソースのエレメントに複製されなければならない(SHOULD)。
診断レポートの所見などnarrativeなデータはDiagnosticReportのドメインリソースとして定義されているtextにも保持すること。presentedFormとの内容の重複は許容されている。presentedFormはbase64のバイナリであるため、DiagnosticReportのtextが検索性の担保に利用される.また、見読性も同時に保たれる。
診断レポートの分野はAIによる診断補助やレポートの構造化を含め様々な変革がもたらされている。そのため、上記仕様は現時点でのリソース展開の例示であり、将来的に変更される可能性がある。
本プロファイルで再定義された検索パラメータの一覧である。DiagnosticReport共通の検索パラメータが利用されるが、重複するものについては以下の定義に従うこと。
コンフォーマンス | パラメータ | 型 | 説明 | 表現型 | 例 |
---|---|---|---|---|---|
SHALL | identifier | token | レポートに割り当てられた識別子 | DiagnosticReport.identifier | GET [base]/DiagnosticReport?identifier=http://myhospital.com/fhir/diagnosticreport-id-system|1234567890 |
MAY | based-on | reference | オーダ情報への参照 | DiagnosticReport.basedOn (ServiceRequest) | GET [base]/DiagnosticReport?ServiceRequest/12345 |
SHOULD | category | token | レポート種別 | DiagnosticReport.category (ValueSet) 第1コードは LP29684-5 (Radiology 固定) 第2コード以下は複数のコードを許容し、DICOMモダリティコードが格納される |
GET [base]/DiagnosticReport?category=LP29684-5&category=CT |
SHOULD | code | token | レポート全体を示すコード | DiagnosticReport.code LOINC 18748-4(固定) | GET [base]/DiagnosticReport?code=18748-4 |
MAY | media | reference | キー画像への参照 | DiagnosticReport.media.link (Media) | GET [base]/DiagnosticReport?media/12345 |
なお、検索パラメータは複合的に利用できる。詳細はSearch - Chained parametersを参照すること。
次の検索パラメータは必須でサポートされなければならない。
GET [base]/DiagnosticReport?identifier={system|}[code]
例:
GET [base]/DiagnosticReport?identifier=http://myhospital.com/fhir/diagnosticreport-id-system|1234567890
指定された識別子に一致するDiagnosticReportリソースを含むBundleを検索する。
本プロファイルそのものの定義には影響しないが、レポートの標準化に関し以下の情報が参考となる。presentedForm に収容するレポートのコンテンツを作成するレポーティングシステムにおいて、標準化に関する参考資料となる。