医療DX令和ビジョン2030：電子カルテ情報共有・標準化・診療報酬改定DX

はじめに
医療DX令和ビジョン2030：3つの柱
電子カルテ情報共有サービス
電子カルテの標準化・標準型電子カルテ
診療報酬改定DX
マイナ保険証
1. マイナポータルで閲覧・取得できる保険医療情報の拡大
2. マイナンバーカードの安全性

はじめに

国が推進している医療DX令和ビジョン2030を、3つの柱別に整理（2024年3月時点）

医療DX令和ビジョン2030：3つの柱

全国医療情報プラットフォームの創設
電子カルテの標準化・標準型電子カルテの開発
診療報酬改定DX：共通算定モジュールの開発

https://www.mhlw.go.jp/content/10808000/000992373.pdf

点数によるインセンティブ

医療DX情報採用加算点数の新設（在宅医療・訪問看護）

果たして、政府は2030年までにすべての医療機関で電子カルテを導入できるのか？

電子カルテ情報共有サービス

国際的電子カルテ標準規格のFHIR規格を、電子カルテベンダーが導入して情報共有できるようにする。
HL7によって策定された FHIRでのデータ出力機能を義務付け、入力項目の標準化（6情報と3文書）義務付け
電子カルテシステムは2000年代以降、大病院で普及したが、高度にカスタマイズされたため（ベンダーロックイン）、病院間の情報共有が困難な現状

6情報と3文書とは？

6情報（医療情報）
① 傷病名
② アレルギー情報
③ 感染症情報
④ 薬剤禁忌情報
⑤ 検査情報（救急時に有用な検査、生活習慣病関連の検査）
⑥ 処方情報

3文書：上記6情報を踏まえた文書情報
① 診療情報提供書
② キー画像等を含む退院時サマリー
③ 健康診断結果報告書
（※画像情報については、すでに標準規格（DICOM）が規定されており、今後、キー画像以外の画像についても、医療現場で限られた時間の中で必要な情報を把握し診療を開始する際の有用性等を考慮して検討を進める。としている）

HL7 FHIR規格とは!?

HL7は、HL7協会（Health Level Seven International）の略。FHIRはFast Healthcare Interoperability Resourcesの略。

具体的には、FHIR規格に従ったシステムは、リソースと呼ばれる情報の単位をXMLまたはJSON形式で表現し、これらのリソースをHTTPプロトコルを通じてやり取りする。

https://www.hl7.org/fhir/resource-formats.html

ベンダーに対してFHIR規格に準拠するということは、具体的には、下記システムを設計、実装することを求めている。

データ出力機能の義務付け: ベンダーは、自社の医療情報システムがFHIR規格に基づいてデータを出力できるようにする必要がある。これにはXMLまたはJSON形式でのデータ出力が含まれる。システムがこれらの形式でデータを正しく出力できることを保証する必要がある。
入力項目の標準化: 6情報と3文書の標準化は、共通のデータセットと文書の構造を定義しているす。ベンダーはこれらの標準に従い、システム内で扱う情報がこれらの共通のフォーマットやタグに準拠していることを保証する必要がある。
タグ名の統一: FHIRリソースを使用する際、特定のデータ項目を表すために定義されたタグ名を使用する必要がある

以下は、患者情報に加えて病名（Conditionリソース）、検査値（Observationリソース）、および医師の診療録の自由記述（Encounterリソース）を含むFHIRリソースのJSON例。

患者情報（Patientリソース）:

https://www.hl7.org/fhir/patient.html

JSON

{
  "resourceType": "Patient",
  "id": "example-patient-001",
  "name": [
    {
      "use": "official",
      "family": "山田",
      "given": ["太郎"]
    }
  ],
  "gender": "male",
  "birthDate": "1980-04-01"
}

病名（Conditionリソース）:

https://www.hl7.org/fhir/condition.html

JSON

{
  "resourceType": "Condition",
  "id": "example-condition-001",
  "subject": {
    "reference": "Patient/example-patient-001"
  },
  "code": {
    "text": "糖尿病"
  },
  "onsetDateTime": "2022-01-01"
}

検査値（Observationリソース）:

https://www.hl7.org/fhir/observation.html

JSON

{
  "resourceType": "Observation",
  "id": "example-observation-001",
  "subject": {
    "reference": "Patient/example-patient-001"
  },
  "code": {
    "text": "血糖値"
  },
  "valueQuantity": {
    "value": 150,
    "unit": "mg/dl",
    "system": "http://unitsofmeasure.org",
    "code": "mg/dL"
  },
  "effectiveDateTime": "2023-03-25"
}

医師の診療録の自由記述（Encounterリソース）:

https://www.hl7.org/fhir/encounter.html

JSON

{
  "resourceType": "Encounter",
  "id": "example-encounter-001",
  "subject": {
    "reference": "Patient/example-patient-001"
  },
  "type": [
    {
      "text": "外来診療"
    }
  ],
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "AMB",
    "display": "ambulatory"
  },
  "period": {
    "start": "2023-03-25T09:00:00Z",
    "end": "2023-03-25T09:30:00Z"
  },
  "reasonCode": [
    {
      "text": "定期検診"
    }
  ],
  "participant": [
    {
      "individual": {
        "reference": "Practitioner/example-practitioner-001"
      },
      "type": [
        {
          "text": "主治医"
        }
      ]
    }
  ],
  "location": [
    {
      "location": {
        "reference": "Location/example-location-001"
      },
      "status": "completed"
    }
  ],
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">患者は疲れを感じ、定期検診のために来院した。血糖値は高めで、糖尿病の管理についてさらに議論した。</div>"
  }
}

既存の電子カルテシステムは独自のデータモデルを持っている場合が多く、これをFHIRのリソースベースのモデルにマッピングする必要がある。各種データ（患者情報、診療記録、検査結果など）をFHIRのリソース構造に適合させるための詳細なマッピングと変換プロセスが必要で、これが大変（と推測）。

あとは、既存のシステムがAPIを持っていないか、既存のAPIがRESTfulではない場合、新たにFHIR準拠のAPIを設計し、実装する必要がある。これには、エンドポイントの定義、認証と認可のメカニズムの導入、データのセキュリティ保護、エラーハンドリングなども含まれる。

日本の電子カルテの特徴とレベル

日本の場合は、診療録作成と同時に、診療報酬請求の根拠の作成（複雑な算定の多い医学管理料）をしなければならないのが特徴。それに合わせる形で、電子カルテメーカーも算定支援機能を追加しており、複雑で使いにくくなっている
世界水準の電子カルテ（HIMSSとCDSS）では、日本国内では世界基準のlevel6-7（level7が最高）を取得した医療機関・電子カルテベンダーはいない。Level5が最高。ちなみに世界では12カ国、約300病院がlevel7を取得している

現状、電子カルテ乗り換え時にどのようにデータを移行しているのか？

旧態依然としているが、現状全ての電子カルテがFHIR規格に準拠していないため、電子カルテを乗り換える際に簡単にデータ移行できない。

実は、古いカルテのデータをPDF化して吐き出し、それをOCRでデジタル化し、乗り換え先の電子カルテシステムに読み込むという前近代的で超アナログな仕組みで、データを移行している。そして、その作業に膨大な費用が発生し、クリニックが負担しなければんらない。

これは移転コストを高めることで顧客を囲い込んでいるからであり、2000年代からいまだに変わっていない。

救急時に医療情報を閲覧する仕組みの整備

https://www.mhlw.go.jp/content/10808000/001144746.pdf

災害時にはマイナンバーカードがなくても、患者本人が同意すれば、医師が2要素認証でログインして、オンライン資格確認システムに患者情報を要求し、オンライン資格確認システムが必要な患者情報を医師に提供する。

今後はこの仕組みを救急など患者さんが意識不明の場合にも活用していく。

患者の医療情報は膨大なので、救急時には必要な情報のみ様理として表示する

電子カルテの標準化・標準型電子カルテ

１）電子カルテがすでに入っている医療機関

病院において、電子カルテ情報共有サービスに接続することを前提に、電子カルテ情報・文書をFHIR形式に変換し、電子的に送受信するために必要な回収などにかかる費用を補助金で支援（補助率・上限あり）→インセンティブ施策

２）電子カルテ未導入（＝紙カルテ）の診療所（2024年時点で約半数）

デジタル庁と厚労省共同で標準型電子カルテを開発中（下記）→その後どのように導入していくかは未発表（オンライン資格確認みたいに強制力働かせる!?）

診療報酬改定DX

ちなみに、2024年度診療報酬改定における、医療DX新設加算

医療DX推進体制整備加算８点、６点（歯科）、４点（調剤）：電子処方箋及び電子カルテ情報共有サービスの整備、マイナ保険証の利用率を要件とし、医療DXを推進する体制を評価
病変検出支援プログラム加算 60点：内視鏡的大腸ポリープ・粘膜切除術において、病変検出を支援するプログラム医療機器を用いて実施した場合
プログラム医療機器等指導管理料 90点・導入期加算 50点：プログラム医療機器を用いた療養に係る指導管理