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

この記事は約12分で読めます。

はじめに

国が推進している医療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プロトコルを通じてやり取りする。

Resource-formats - FHIR v5.0.0

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

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

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

  1. 患者情報(Patientリソース):
Patient - FHIR v5.0.0
JSON
{
  "resourceType": "Patient",
  "id": "example-patient-001",
  "name": [
    {
      "use": "official",
      "family": "山田",
      "given": ["太郎"]
    }
  ],
  "gender": "male",
  "birthDate": "1980-04-01"
}
  1. 病名(Conditionリソース):
Condition - FHIR v5.0.0
JSON
{
  "resourceType": "Condition",
  "id": "example-condition-001",
  "subject": {
    "reference": "Patient/example-patient-001"
  },
  "code": {
    "text": "糖尿病"
  },
  "onsetDateTime": "2022-01-01"
}
  1. 検査値(Observationリソース):
Observation - FHIR v5.0.0
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"
}
  1. 医師の診療録の自由記述(Encounterリソース):
Encounter - FHIR v5.0.0
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を取得している

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

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

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

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

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

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

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

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

2)電子カルテ未導入(=紙カルテ)の診療所(2024年時点で約半数)

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

診療報酬改定DX

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

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

マイナ保険証

マイナンバーカード保有者は9000万二を超えたが、マイナ保険証の利用率は5%程度。

マイナポータルで閲覧・取得できる保険医療情報の拡大

  • 2021.10月:特定健診・後期高齢者健診 / 薬剤情報
  • 2021.11月:医療費通知情報(医療機関で支払った医療費)
  • 2022.9月:診療情報(診療年月日・医療機関名・診療内容)
  • 2023.1月:電子処方箋(電子処方箋に対応した医療機関・薬局を受診した場合のリアルタイムの調剤情報)

これらはAPIとして国が提供しているものなので、実際には民間企業がPHRを開発して国民に提供する必要がある(すでに提供しているアプリあり)

今後提供予定の情報

  • 2024末:電子カルテ情報(検査値、アレルギー情報)
医療保険情報取得API|マイナポータル
マイナポータルAPI 医療保険情報取得APIに関するページです。

マイナンバーカードの安全性

  • 顔写真入りのため、対面での悪用は困難
  • マイナンバーカードの裏側に記載されているマイナバーを見られても、個人情報は盗まれない

ICチップ

  • カード面に記載されている情報(氏名・住所・生年月日・性別・個人番号・本人の写真など)や、公的個人認証の電子証明書が記録されている。
  • 税や年金などの個人情報は記録されない。
  • ICカードリーダ/ライタにかざすことで、ICチップに記録されている情報を確認できる
  • 不正に情報を盗み出そうとすると、ICチップが壊れる仕組み
マイナンバーカードとは|デジタル庁
デジタル庁は、デジタル社会形成の司令塔として、未来志向のDX(デジタル・トランスフォーメーション)を大胆に推進し、デジタル時代の官民のインフラを一気呵成に作り上げることを目指します。

コメント

タイトルとURLをコピーしました