2.1.3.3.2. JP Core DiagnosticReport Radiology (放射線検査レポート) プロファイル

2.1.3.3.2.1. 概略

項目 内容
定義URL http://jpfhir.jp/fhir/core/StructureDefinition/JP_DiagnosticReport_Radiology
バージョン 1.0.0
名前 JPDiagnosticReportRadiology
タイトル JP Core Diagnostic Report Radiology Profile
ステータス アクティブ（2021-11-03）
定義 このプロファイルはDiagnosticReportリソースに関し放射線検査の１項目を対象として表現し、データを送受信するための基礎となる制約と拡張を定めたものである。
公開者 FHIR® Japanese implementation research working group in Japan Association of Medical Informatics (JAMI)
Copyright FHIR® Japanese implementation research working group in Japan Association of Medical Informatics (JAMI)
ソースリソース https://simplifier.net/jp-core-draftv1/jpdiagnosticreportradiology

本プロファイルは、DiagnosticReportリソース のうち、放射線画像検査における患者、患者群、機器、場所、およびこれらから得られた画像に対して実施された診断結果またはその解釈を示す「報告書」を表現するリソースの定義である。ここでは、DiagnosticReport リソースに対して本プロファイルに準拠する場合に必須となる要素や、サポートすべき拡張、用語、検索パラメータを定義する。 報告書は、依頼者や撮影の情報などの臨床的背景のほか、いくつかの計測値、画像、テキストおよびコード化された解釈、テンプレート化された診断報告書により構成される。

2.1.3.3.2.2. 背景および想定シナリオ

本プロファイルは、以下のようなユースケースを想定する。

  • 施設内で発生するオーダをもとに実施される画像検査に対する診断レポートの保存
  • 他のリソースからの放射線検査レポートの参照
    （例：ImagingStudyリソース やServiceRequestリソース のreasonReference エレメントで参照される放射線検査レポート）

2.1.3.3.2.2.1. スコープ

放射線検査レポートで取り扱う診断報告書は、検査の終了後に、検査の診断結果として提供される一連の情報である。 この情報には、テキストレポート、画像、コード、および計測値などが含まれる。この組み合わせは、診断手順や特定の検査の結果の性質に応じて変化する。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リソースは、シーケンスの構造化を含めレポートの完全なサポートをまだ提供できていないが、将来実装される予定である。

2.1.3.3.2.3. 関連するプロファイル

このプロファイルは、以下のリソースに対して定義された各プロファイルから参照される。

また，このプロファイルから直接参照されるリソースは以下の通りである。

また，以下のリソースは関連情報としてpresentedFormにて参照されるレポート内に保持される可能性がある。ただし、レポートシステムの仕様に依存するため、レポートシステムでは各リソースとの相互運用性の確保に配慮することが求められる。

運用のフローに関連する TASK、Procedure 等のリソース定義についてはここでは触れない。

2.1.3.3.2.4. リソース定義

identifierΣ0..*Identifier
basedOnI0..*Reference(CarePlan | ImmunizationRecommendation | MedicationRequest | NutritionOrder | ServiceRequest)
statusΣ ?!1..1codeBinding
categoryΣ0..*CodeableConcept
codeΣ1..1CodeableConceptBinding
subjectΣ I0..1Reference(Patient | Group | Device | Location)
encounterΣ I0..1Reference(Encounter)
effectiveDateTimedateTime
issuedΣ0..1instant
performerΣ I0..*Reference(Practitioner | PractitionerRole | Organization | CareTeam)
resultsInterpreterΣ I0..*Reference(Practitioner | PractitionerRole | Organization | CareTeam)
specimenI0..*Reference(Specimen)
resultI0..*Reference(Observation)
imagingStudyI0..*Reference(ImagingStudy)
comment0..1string
conclusion0..1string
conclusionCode0..*CodeableConcept
presentedFormI0..*Attachment

Narrativeなレポート内容はDomainResourceであるtextに保管される。

Textのリソース構造およびコーティングは以下を参照のこと。

2.1.3.3.2.4.1. 必須要素

次のデータ項目は必須（SHALL）である。

  • status ：レポートの状態・進捗状況
  • category ： “RAD”をデフォルトとし、特に検査種別を含む部門指定を指定したい場合は"RUS", "RX", "CT", "NMR", "NMS", "VUS", "OUS", "CUS"などを指定する．
  • code ：レポートの種別（画像診断レポート交換手順ガイドライン「5.1 レポート種別コード」に記載されているLOINCコード "Diagnostic imaging study" を指定）
  • effectiveDateTime ： レポート作成日時

2.1.3.3.2.4.2. MustSupport

次のデータは送信システムに存在する場合はサポートされなければならないことを意味する（Must Support）。

  • text : (DiagnosticReport DomainResource) レポートのnarrative dataとして格納する。
  • basedOn ： レポートあるいは画像検査のServiceRequest
  • subject ： 患者リソース(Patient)への参照。殆どの場合存在するが、緊急検査等で患者リソースが確定していない場合が想定される
  • issued ： レポート確定日時
  • performer ： Practitionerでレポートの関係者（作成者、読影者、確定者など）を列挙
  • resultInterpreter ： Practitionerでレポート確定者を示す
  • imagingStudy ： 診断の対象となる画像
  • link ：キーイメージの参照先
  • conclusion ： 診断の結果、impression
  • presentedForm ：レポート本体（全体のイメージあるいは所見等のテキスト）

imagingStudyエレメントはCardinalityが0..1だが、放射線レポートでは画像が必ず存在することから、検査実施後には必須（複数の可能性もあり）である。しかし、検査実施前などのstatusによっては0もあることから、とりあえずMustSupportのままとする。将来的な議論の結果によっては、cardinalityを変更する可能性がある。

2.1.3.3.2.4.3. Extensions定義

本プロファイルはextensionを定義しない。

2.1.3.3.2.4.4. 用語定義

Path 定義 バインディング強度 バリューセット
DiagnosticReport.status レポートのステータス Required DiagnosticReportStatus
DiagnosticReport.category レポート（所見）を作成した部門 Preferred DiagnosticServiceSectionCodes
"RAD", "RX", "CT", "NMR", "NMS", "RUS", "VUS", "OUS", "CUS"などを指定。デフォルトは"RAD"。
DiagnosticReport.code レポートのフォーマット、種類など Preferred Diagnostic imaging study
DiagnosticReport.conclusionCode 診断レポートの結論・要約 Example ICD-10, ICD-11

2.1.3.3.2.5. 注意

2.1.3.3.2.5.1. Text

DiagnosticReportのドメインリソースの一つであるtextエレメントに見読可能なnarrativeデータとしてレポートの所見を中心とした情報を格納する。依頼情報や患者基本情報などを含んだレポート全体のデータは別途presentedFormエレメントに保持されるが、ここではPDF等のバイナリが保存される。よってレポート内容の見読性と検索性を担保するためにtextエレメントに保存されたデータが利用される。

NarrativeなtextにアクセスするためのDomainResource定義

(DiagnosticReportのResourceType直下に現れる。text以外のDomainResourceの詳細についてはこちらを参照のこと）

text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension

例：

{
  "resourceType": "DiagnosticReport",
  "id": "xxxxxxxxxx",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2020-10-25T17:00:03.903+00:00",
    "source": "xxxxxxxxxxxxxx"
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>胸部造影CT</p><p>依頼目的:10月20日の単純写真でひだり肺に異常陰影あり。精査目的。</p><p>所見:</p><p>心拡大は無く、心嚢液も見られない。</p><p>胸部大動脈は蛇行があるも径は正常範囲内。ひだり椎骨動脈が大動脈弓より直接分岐している。大動脈壁に小さな石灰化がみられ動脈硬化性変化が軽度見られる。</p><p>ひだり肺上葉に2.2 x 1.5 cm大の空洞性病変を認める(Image 31/110)。壁には充実性成分を含み不整な造影濃度を示す。みぎ肺上葉に気管支拡張を伴う線状影を認めるが、こちらは炎症性瘢痕として矛盾しない。気管には異常を認めず。肺尖部に炎症後変化と思われる胸膜肥厚は見られる。胸水は認めない。</p><p>腋窩，縦郭および肺門リンパ節の腫大は認めず。甲状腺は正常範囲。</p><p>スキャン範囲内の腹部には異常を認めず。明らかな骨病変も認めない。</p><p>インプレッション:</p><ol><li><p>ひだり肺上葉の空洞性病変。肺腺癌を疑う。</p></li><li><p>みぎ肺上葉陳旧性炎症性瘢痕。<p></li></ol></div>"
  },
  "identifier": [ {
    "use": "usual",
    "system": "http://www.acme.com/identifiers/patient",
    "value": "xxxxxxxxxxxxxxx"
  } ],
  "status": "final",
  "category": [ {
    "coding": [ {
      "system": "http://hl7.org/fhir/v2/0074",
      "code": "RAD"
    } ]
  } ], 
  "subject": {
    "reference": "Patient/pat2"
  },
  "effectiveDateTime": "2008-06-17",
  "issued": "2008-06-18T09:23:00+10:00",
  "performer": [
    {
      "reference": "Practitioner/3ad0687e-f477-468c-afd5-fcc2bf897809",
      "display": "田中太郎"
    }
  ],
  "imagingStudy": [
    {
      "display": "CHEST CT DICOM imaging study",
      "reference": "http://someserver/some-path"
  ],
　"conclusion": "インプレッション: ひだり肺上葉の空洞性病変。 肺腺癌を疑う。みぎ肺上葉陳旧性炎症性瘢痕。",
  "presentedForm": [{
    "contentType": "application/jpg",
    "language": "ja", 
    "data":"/9j/4AAQSkZJRgABAgAAZAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxwrh/9X/xP/Z9tYV8PiQ//2Q==",
    "title": "HTML Report"
  }]
}

2.1.3.3.2.5.2. Identifier

Identifier のデータタイプはオーダー依頼者であるPlacerあるいはオーダーの実施者であるFiller（HL7 Version 2 Messaging Standardにて'Placer'あるいは'Filler'として知られている）によって割り当てられた識別子を区別するために利用されるtypeエレメントを持っている。typeエレメントは以下の様に利用する。

2.1.3.3.2.5.2.1. Placerの場合

{
  "identifier":[{
    "type":{
      "coding":{
        "system":"http://terminology.hl7.org/CodeSystem/v2-0203",
        "code":"PLAC"
      },
      "value":"Placer"
    },
    "system":"urn:oid:1.2.3.4.5.6.7",
    "value":"2345234234234"
  }]
}

2.1.3.3.2.5.2.2. Fillerの場合

{
  "identifier":[{
    "type":{
      "coding":{
        "system":"http://terminology.hl7.org/CodeSystem/v2-0203",
        "code":"FILL"
      },
      "value":"Filler"
    },
    "system":"http://terminology.hl7.org/CodeSystem/v2-0203",
    "value":"567890"
  }]
}

DiagnosticReport_Radiology リソースではtypeエレメントを明示する際にはオーダ番号やレポート番号が格納される可能性がある点に留意して対応することが重要である。

2.1.3.3.2.5.3. 時間の指定

このプロファイルのリソースでは、effective[x]エレメントにはレポート作成時間をdateTimeで格納する。

2.1.3.3.2.5.4. 関連するObservation

DiagnosticReport.resultエレメントには関連する検体検査計測値などをしめすObservationリソースを含むことができる。

2.1.3.3.2.5.5. 参照画像

ImagingStudyやmediaは多少オーバーラップするが、使用される目的が異なる。用途に応じて使い分けること。DiagnosticReportではDICOM画像への参照としてImagingStudyが利用され、キー画像としてmediaが参照される。

2.1.3.3.2.5.6. レポートの内容

典型的には放射線レポートはnarrativeな構成でのレポートが作成される。DiagnosticReport_Radiologyでは標準的なnarrativeリソースの表現としてXHTMLやrich text表現として（典型的にはPDF）がpresentedFormに指定される。

Conclusionやコード化された診断結果は各々がレポートを構成する小さなデータであるが、これらはpresentedFormに保持されるnarrativeなデータ内に含まれると同時に、本リソースのエレメントに複製されなければならない（SHOULD)。

診断レポートの所見などnarrativeなデータはDiagnosticReportのドメインリソースとして定義されているtextにも保持すること。presentedFormとの内容の重複は許容されている。presentedFormはbase64のバイナリであるため、DiagnosticReportのtextが検索性の担保に利用される．また、見読性も同時に保たれる。

診断レポートの分野はAIによる診断補助やレポートの構造化を含め様々な変革がもたらされている。そのため、上記仕様は現時点でのリソース展開の例示であり、将来的に変更される可能性がある。

2.1.3.3.2.6. 利用方法

2.1.3.3.2.6.1. Interaction一覧

DiagnosticReport リソースのインタラクション一覧の定義はユースケースに依存せず共通であるため、共通情報プロファイルに記載されている。

DiagnosticReport共通情報プロファイル#インタラクション一覧

2.1.3.3.2.6.1.1. 必須検索パラメータ

次の検索パラメータは必須でサポートされなければならない。

Name Type Description Expression
based-on reference オーダ情報への参照 DiagnosticReport.basedOn

(ServiceRequest)
category token レポート種別 DiagnosticReport.category (ValueSet)
"RAD", "RX", "CT", "NMR", "NMS", "RUS", etc.
default = “RAD”
code token レポート全体を示すコード DiagnosticReport.code
LOINC 18748-4
conclusion token コード化されたレポートの conclusion (interpretation/impression) DiagnosticReport.conclusionCode
date date レポート作成日 DiagnosticReport.effectiveDate
encounter reference オーダが発行された際の Encounter DiagnosticReport.encounter

(Encounter)
identifier token レポートの identifier（識別子） DiagnosticReport.identifier
issued date レポート発行日（確定日） DiagnosticReport.issued
media reference キー画像への参照 DiagnosticReport.media.link

(Media)
performer reference レポート確定者 DiagnosticReport.performer

(Practitioner)
result reference 関連する検査結果 (検体検査結果など) DiagnosticReport.result

(Observation)
results-interpreter reference 読影者 DiagnosticReport.resultsInterpreter

(Practitioner)
status token レポートの状態 DiagnosticReport.status
subject reference レポートの対象となる患者 DiagnosticReport.subject

(Patient)

2.1.3.3.2.7. その他、参考文献・リンク等

本プロファイルそのものの定義には影響しないが、レポートの標準化に関し以下の情報が参考となる。presentedForm に収容するレポートのコンテンツを作成するレポーティングシステムにおいて、標準化に関する参考資料となる。