コンセプト

Sync for Science-J1 は、EHR-PGHD2情報連携により、個人に対する医療アウトカムを最大化するとともに、医学・薬学研究のデータリポジトリとしても貢献する医療情報プラットフォームです。（2024年3月現在論文投稿中）

特徴

  1. 医療機関で生成される医療情報（EHR）をQRコードに変換して患者に開示
  2. 患者自らがQRコードをスマートフォンにインストールしたモバイルアプリで読み取りEHRを取得
  3. モバイルアプリでは、スマートデバイスにより日常生活で取得される健康情報（PGHD : Patient Generated Health Data）を収集
  4. 医療従事者は、診察・検査で得られたEHRと日常生活におけるPGHDの統合データからより精密な医療を行うことが可能となる
  5. リアルワールドデータに加え、より精密な統合データをデータリポジトリとして、医薬品研究開発及び公衆衛生学的研究を促進

ユースケース

血糖コントロールが重要な「妊娠糖尿病」の患者を対象に、定期的な妊婦健診、血糖測定器等のデバイスを用いたPGHDを収集し、地域の産婦人科病院と大学病院が連携して患者の診療にあたる。診療においては適宜、オンライン診療も取り入れ、通院の負荷を軽減する。

患者は、自身のEHRやPGHDについて、どの医療機関で利用可能とするかを自身の考えに基づき選択する。この選択はアプリを通じていつでも変更可能である。また、他の臨床研究で研究参加を依頼したい場合や、その他の調査・研究等でデータを利用したい場合にリーチすることができ、また、患者側からもデータ提供について、いつでも設定したり変更したりすることができる（ダイナミックコンセント）。

図表１　Sync for Science-J ユースケース

今回のユースケースでは、妊娠糖尿病に関係する約200のデータ項目について、対応するLOINCコードの同定、FHIR形式の規定を行い、個人を起点とするQRコードによるデータ流通を実装した。

仕組み

Sync for Science-J QR code Edition は、以下３つのレイヤーから規定される。

第３層医療情報辞書；LOINC
第２層データ形式；HL7 FHIR仕様
第１層QRコード：Smart Health Cards 拡張仕様

この規定に準拠して、産科電子カルテよりQRコードを印刷して患者に渡し、患者が利用するヘルスケアアプリでQRコードを読み取り、診療データを取得する。

第１層　QRコード

QRコードは、ワクチン接種証明でも採用されている『Smart Health Cards3』（以下「SHC」）をベースに、ペイロード部分を暗号化（JWE : RFC75164）し、患者本人以外がQRコードを入手しても内容が読み取れないように拡張している。

図表２　SMART Health Cards 仕様のペイロード部分を暗号化

病院では、診療データのQRコードを患者本人に渡す前に、その患者専用の個人認証コード（秘密鍵）をQRコードに印刷して渡し、患者は、その個人認証コードをヘルスケアアプリに事前に登録しておく。以降、診療の度ごとに、患者はQRコードで診療データ・検査データを受け取り、ヘルスケアアプリに読み込む。診療データのQRコードは患者の個人認証コードと対になる公開鍵で暗号化されており、その患者の個人認証コードを持たない第三者が診療データのQRコードを読み取ろうとしても診療データを復号化することはできない。

この規格に準拠したQRコードであれば、複数の医療機関、複数のヘルスケアアプリがエコシステムを形成し、相互にデータ流通することが可能となる。

もちろん、具体的に、誰と情報を共有するかはデータ主体である患者自身の意向に沿ったものでなければならず、患者からの同意を得た場合のみデータ流通する仕組みを導入する必要がある。

図表３　個人を起点としたQRコードによる医療情報流通のながれ

第２層　HL7 FHIR仕様

医療情報をデータとして表現するデータ形式は、厚生労働省で標準規格5として採用しているHL7 FHIRを使用する。

データ構造
「Bundle」によるリソースのパッケージ化

SHC（正確には、SHCのペイロード部）に含める病院、患者、検査データなどの様々なデータ項目は、FHIRの「Bundle」リソースの“entry”項目内に配列として記述する。

{
  "resourceType": "Bundle",
  "type": "document",
  "entry": [
    {
      "resource": {
        ＊＊＊
      }
    },
      ・
      ・
    {
      "resource": {
        ＊＊＊
      }
    }
  ]
}

「Bundle」リソースのタイプは、「診療情報提供書HL7FHIR 記述仕様(第1版)」に倣って「document」とする。「document」タイプでは、通常の文書のように各リソースの“目次立て”（Composition）を行うことができる。「Composition」リソース内では、”date”(作成日付)、”author”（作成者）、”subject”（対象物（患者の電子カルテ））などのメタ情報を記述したり、“section”で検査データ（血圧、心拍数）などを記述することができる。“section”の配下には、さらに“section”を置いて階層化できるので、文書の「章」「節」「項」のような構成を作ることが可能。

“subject”、”author”、“section”などの項目は、「Patient」「Organization」「Observation」などの各リソースへのポインター（ID参照）を持ち、実際のデータはポインターが指す参照先のリソースに記述されている。つまり、「Composition」リソースは、文書の「目次立て」の役割のみを担うものとして使われる。

{
  "resourceType": "Bundle",
  "identifier": {                     //「document」タイプの場合必須
    "system": "システムのURI", // URI QRコード発行のシステムの識別子
    "value": "ドキュメントID " //そのシステム内での発行番号
  },
  "type": "document",
  "timestamp": "2022-07-09T13:28:17.239+02:00", //「document」タイプの場合必須
  "entry": [
  // ■CompositionリソースStart■「document」タイプの場合Compositionが先頭
    {
      "resource": {
        "resourceType": "Composition",
        "status": "final",
        "type": {
          "coding": [
            {
              "system": "http://hl7.org/fhir/ValueSet/doc-typecodes",
              "code": "11503-0",
              "display": "Medical records"
            }
          ]
        },
        "subject": {
          "reference": "Patient/カルテID ",  //患者カルテIDへの参照
          "type": "Patient"
        },
        "date": "2022-07-01",
        "author": [
          {
            "reference": "Organization/医療機関ID ",  //病院への参照
            "type": "Organization"
          },
          {
            "reference": "Organization/診療科ID ",  //診療科への参照
            "type": "Organization" 
          },
          {
            "reference": "Practitioner/医療者ID ", //医療者名への参照
            "type": "Practitioner"
          }
        ],
        "title": "○○さんSHC電子カルテ",  //Compositionとしての必須項目
        "section": [
          {
            "title": "産科ー診療内容",
            "entry": [
              {
                "reference": "Encounter/診療番号"  //診察日への参照
              },
              {
                "reference": "Observation/obs001"  //脈拍データへの参照
              },
              {
                "reference": "Observation/obs002"  //血圧データへの参照
              },
                  ・
                  ・
                  ・
            ]
          },
          {
            "title": "検査データー初回",
            "entry": [
              {
                "reference": "Specimen/spc001"  // 検体の検査データ評価日への参照
              },
              {
                "reference": "Observation/obs003"  // Cre.データへの参照
              },
              {
                "reference": "Observation/obs004"  // eGFRデータへの参照
              },
                  ・
                  ・
                  ・
            ]
          }
        ]
      }
    },
  // ■CompositionリソースEnd■

図表4　SHCに含まれる医療情報のデータ構造

グループ化

このユースケースでは、患者は定期的に健診・検査を受け、そのデータをSHCを通じてアプリに取り込むことになる。１回の妊婦健診の中ではいくつもの診断結果のデータ項目が含まれ、また、１回の検査、たとえば感染症検査でも、複数の検査データが含まれる。このため、リソースとして表現される診療データは、グループ＞各健診データといった階層構造で表現される。2024/1時点では以下20のグループを規定している。

母体情報、月経、妊娠分娩歴、過去分娩、パートナー情報、家族歴、母体健診、超音波検査、尿検査、感染症検査、血液検査、負荷試験、子宮頸癌検査、分娩情報、胎児、産後（母体）、産後（新生児）、食事、症状（妊婦）、アプリ問診情報

データ項目の表現形式

各データ項目をFHIR形式で表現する。多くのデータ項目は、医療者の診断や検査結果に基づくもののため、resourceType = “observation” として表現される。200を超えるデータ項目対して、記述形式を規定。一例として、EFBW（胎児の推定体重）を以下に示す。

図表5　FHIR形式で表現されるデータ項目例

第３層　LOINC

各医療情報がどういうデータであるかを規定するためには、そのデータのメタデータとして、データ種別のコードを付与する必要がある。そのコード体系（医療情報辞書）として、LOINC6コードを使用する。ただし、LOINCで規定されていないデータ項目については独自にコードを付与している。

LOINCコードの一例

図表５で示した「EFBW（胎児の推定体重）」の場合は、「11727-5　Fetal Body weight estimated by US」を採用。

QRコード生成ライブラリ

「第1層QRコード」で示した医療情報をQRコードに包めて患者本人に開示する運用を実現するためには、産科カルテシステムからQRコードを生成する機能を具備する必要がある。そのため、我が国の代表的な産科カルテベンダー４社7に協力を求め、QRコード出力機能を実装いただいた。

実装については、各産科カルテベンダーが独自にQRコード生成機能を開発するのは効率的でもないし、また、生成されるQRコードの仕様統一のためにも、共通ライブラリ化し、それぞれの産科カルテシステムが同じライブラリを使用するようにした。ここでは、そのQRコード生成ライブラリについて説明する。

方針

図表３で示されるQRコードによる情報流通を実現するために、QRコード生成に関わる一連の機能をAPIで提供するライブラリの構築を目指す。これにより、産科カルテシステムの稼働環境が異なっても同じように組み込むことが可能となる。

システム構成

医療者が使用する産科カルテシステムのクライアントPCよりQRコードの発行が依頼され、医療者の最寄りのプリンタでQRコードが印刷されることを想定している。そのため、産科カルテシステムのサーバシステムと連携可能なウェブサーバーを構築し、本ライブラリの機能をWeb APIとして提供するのが理想的と考えられるが、すでに運用中の電子カルテシステムにウェブサーバーなどの常駐プロセスを新たに追加するのは非常に難しいという現実がある。

そのような制約のため、QRコード生成ライブラリを1つのプログラミング言語で開発し、プログラミング言語ごとにラッパーを開発する方式を採用する。つまり、各プログラミング言語から見ると、その言語のライブラリまたはモジュールという形で本ライブラリを提供することになる。ラッパーは各参加カルテシステムないしは、クライアントPCの動作環境に依存するため、QRコード生成ライブラリとしては考慮はしない。

情報セキュリティ

医療情報は非常にセンシティブなプライバシー情報であり、QRコードを通じて第三者に漏洩することなく、安全に本人だけがその情報を活用できる仕組みが必要となる。このような情報セキュリティには以下の3要素（CIAと呼ばれます）を実装する必要となる。

  • 機密性 (Confidentiality)
  • 完全性 (Integrity)
  • 可用性 (Availability)
機密性（Confidentiality）

本人のみの解読できる仕組みが必要。本システムでは、公開鍵と秘密鍵の鍵ペアによって医療情報を暗号化および復号化する。患者の鍵ペアは初診時に電子カルテシステムで生成し、鍵ペアのうち公開鍵は病院側で保管。そして、秘密鍵はQRコードにして患者に紙で渡す。患者は秘密鍵が入ったQRコードをスマートフォンアプリで読み取り、アプリ内で保管。医療情報は鍵ペアのうち公開鍵を使って暗号化され、暗号化されたデータはQRコードとして患者に紙で手渡される。患者はスマートフォンアプリにて、暗号化された医療情報を秘密鍵を使って復号化。この暗号化の仕組みとしてJWE (Json Web Encryption: RFC 7516) を採用。

SHCは生成したJWSをQRコード化する手順を規定しているが、SHCには暗号化の仕組みが用意されていない。そこで本システムではSHCを拡張することで暗号化を実現。

完全性（Integrity）

医療情報が病院から患者に引き渡される際に、そのデータの改ざんを防止する。確実にデータが完全な形で患者に引き渡されたことを確認する仕組みが必要。本システムでは、電子署名によって完全性を担保。認証局によって発行された電子証明書をシステムに保管し、患者に渡す医療情報には、その電子証明書を使った電子署名を付加する。患者はQRコードから暗号化データを受領し、スマートフォンアプリで読み取る。その際、受領したデータが完全なものかを、電子署名から検証。 本システムではこの署名の仕組みとしてJWS (Json Web Signature: RFC 7515) を採用。

可用性（Availability）

医療情報は、患者がいつでも使える状態であるべき。スマートフォンの故障や買い替えも想定する必要がある。いつでも産科カルテシステムを通して秘密鍵と医療データを再配布できる仕組みは必要。QRコード生成ライブラリは、いつでも鍵ペアを再発行し、再度、暗号化された医療データのQRコードを発行する仕組みを提供。

QRコードの仕様

QRコードの構造
図表６　QRコードの構造
JWS（JSON Web Signature）

JWSは次のように2つのドットで3つの領域に区切られる。先頭からヘッダー、ペイロード、署名。いずれの部分もBase64 URLエンコードされた文字列。

eyJhbGciOiJIUzI1Ni(略).eyJzdWIiOiIxMjM0NT(略).TJVA95OrM7E2cBab30(略)

　以下、ヘッダー、ペイロード、署名の各パーツについて説明。

ヘッダー

ヘッダーは、署名の検証に必要な情報をJSON形式にしたもの。

本ライブラリではalgをES256で固定。これは、署名アルゴリズムをP-256 および SHA-256 を使⽤した ECDSAとすることを意味する。本ライブラリではzipをDEF固定とする。これは、圧縮アルゴリズムにDeflateを採用することを意味する。kidは鍵を識別するためのデータです。Smart Health Cartdにおけるkidの仕様はRFC7638（JSON Web Key (JWK) Thumbprint）準拠。

{
  "alg": "ES256",
  "zip": "DEF",
  "kid": "e9bc097a..."
}
ペイロード

ペーロードとは、患者に手渡したい医療データそのもの。具体的には前述のHL7 FHIRのJSONデータ。このJSONは最小化しておく。そして、そのJSONをDeflateで圧縮し、それをBase64 URLエンコードしたものが、ペイロードに格納される。

署名

署名とは、秘密鍵を使って作った署名を意味する。署名の対象は、Base64 URLエンコード済みのヘッダーとペイロードをドットで連結したものを署名したもの。それをBase64 URLエンコードしたものが署名部分に格納される。

図表７　JWSの署名

このJWSのデータさえできれば、SHCの規定に基づいてQRコードを生成することができるが、前述の通りSHCには暗号化の仕組みが用意されていないので、本システムではSHCを拡張して暗号化を行う。

Base64 URLエンコード

これはBase64エンコードとは異なるので注意。Base64 URLエンコードは、エンコードされた文字列をURLに利用できる文字だけにしたもの。Base64 URLエンコードするには、Base64エンコードした後に以下の4つの変換を行う。

  • + (プラス記号) を – (ハイフン) に置換
  • / (スラッシュ)を _ (アンダーバー) に置換
  • パディングの = を削除
  • 改行 (CR+LF) を削除
JWE (JSON Web Encryption)

JWEは次のように4つのドットで5つの領域に区切られる。先頭からヘッダー、暗号化キー、初期化ベクトル、暗号文、認証タグ。いずれの部分もBase64 URLエンコードされた文字列。

eyJhbGciO(略).AAG-Mxcoy(略).HtGmVwOnL(略).cHUwotN3V(略).NGmNkNr5Q(略)

前述の医療データをJWS化したデータをコンテンツとして暗号化。

図表9　JWEの構造

JWEのヘッダー等の設定内容については、JWEの規定に準拠し、ここでは省略し、以下、JWE作成のための暗号化の流れを図示する。

図表10　JWE暗号化の流れ

QRコード生成手順

生成されたJWEトークンのQRコードの生成において、JWEトークンをそのままQRコード化するのではなく、Base-10 numeric digitsを使って10進数の数字のみで表現する。先頭にスキーム shcs:/ を加える。

shcs:/01234567890123456…

SHC仕様では、スキームは shc:/ と定められているが、本ライブラリでは暗号化のためにSHCを独自に拡張しているため、一般的なSHCリーダーでは読み取ることができない。そのため、本ライブラリで採用するスキームはshcs:/ としている（IANAには未登録の独自のスキーム）。

QRコードの最大情報量と分割

JWEトークンが1つのQRコードに収まらない場合は複数個のQRコードに分割して作成する。SHCデータが3つに分割された場合、次のようになり、利用者がどの順番でQRコードを読み取っても問題ない。

shcs:/1/3/01234567890123456
shcs:/2/3/78901234567890123
shcs:/3/3/45678901234567890

プログラミングインタフェース仕様

QR生成ライブラリは、以降で説明するプログラミング・インタフェースを提供する。本仕様は、クラス型オブジェクト指向プログラミングを採用。

本仕様ではクラス名、メソッド名などを定義しているが、キャメルケースやスネークケースのような大文字・小文字の扱いについては、プログラミング言語の規則や慣用を優先している。クラス名はアッパーキャメルケース (例: MyClass) を、メソッド名はローワーキャメルケース (例: myMethod) を、引数などの変数はスネークケース (my_variable) で記述する。

プログラミング言語によっては、以降で説明するメソッドの処理を非同期で実行する必要があるかもしれない。基本的にはコールバック関数の利用は避けることを推奨。例えば、node.js (JavaScript) を例にとれば、async/await の利用を推奨。

クラスおよびコンストラクタ
HealthDataManager()

[構文]

manager = new HealthDataManager(storage)

[引数]

引数名型必須説明
storageObject必須患者ごとの鍵ペアを保存するための永続的ストレージに関する情報を格納したオブジェクト

[説明]

storageの型は、プログラミング言語によって呼び方が異なるが、PHP/Perlの連想配列、JavaScriptのObjectオブジェクト、Pythonの辞書（dict）のこと。

メソッド

メソッドの詳細については、詳細設計書に譲り、ここではメソッドの一覧を提示する。

メソッド名称引数
1setSigPrivateKey()署名用秘密鍵 登録private_pem, kid
2getSigPrivateKey()署名用秘密鍵 取得なし
3deleteSigPrivateKey()署名用秘密鍵 削除なし
4createEncKeyPair()暗号化用鍵ペア 作成user_id
5generateEncPrivateKeyQr()暗号化用秘密鍵QRコード生成user_id
6getEncKeyPair()暗号化用鍵ペア 取得user_id
7deleteEncKeyPair()暗号化用鍵ペア 削除user_id
8generateHealthDataQr()医療データQR生成user_id, json
謝辞

本研究成果は、2021-2023 AMED 循環器疾患・糖尿病等生活習慣病対策実用化研究事業 『ダイナミック・コンセントを実装する先進的糖尿病デジタルデバイスの開発研究』（JP21ek0210162）の支援を受けた。

[ 注 ]
  1. Sync for Science-Jの発想は、米国NIH等で策定された医療情報連携の取り組み　http://syncfor.science ↩︎
  2. EHR（Electronic Health Record）、PGHD（Patient Generated Health Data）の略。PGHDはPHR（Personal Health Record）と呼称されることも多い。 ↩︎
  3. Smart Health Cards ボストン小児病院のコンピュテーショナル・ヘルス・インフォマティクス・プログラムで運営されているSMART Health ITプロジェクトで策定された規格で、QRコードを通じて医療情報を連携するために利用される。Covid-19のワクチン接種証明でもこの規格が採用されている。 ↩︎
  4. JWE（Json Web Encryption）は、Json形式でwebインタフェースでデータ連携する際の規格であるJWS（Json Web Signature、RFC7515）に暗号化を取り入れた規格。 ↩︎
  5. https://std.jpfhir.jp ↩︎
  6. https://loinc.org ↩︎
  7. 産科カルテベンダ4社は以下の通り（五十音順）。タック株式会社、トーイツ株式会社、株式会社ニューウェイブ、株式会社ミトラ ↩︎