2026.10.22 業務システム

電子カルテ情報共有サービスとは：2文書5情報のFHIR送信と接続方式を実装視点で解説

電子カルテ情報共有サービスは、診療情報提供書や傷病名・アレルギー・検査結果をHL7 FHIR形式で登録し、全国の医療機関や薬局、患者本人が閲覧できるようにする国の仕組みです。この記事では、厚生労働省のシステムベンダ向け技術解説書2.1.0版（令和8年6月）と、FHIR実装ガイドJP-CLINS 1.13.0を読み、共有される「2文書5情報」の範囲、臨床情報を送るBundleの組み方、Bundle.identifierの発番、電子カルテからの接続3方式を整理します。送信前に仕様の機械的な規則を確かめるPythonと、公式Validatorの実行コマンドも併せて載せました。電子カルテそのものの種類や選び方は電子カルテの種類・機能と標準仕様対応の解説に任せます。

まとめ：電子カルテ情報共有サービスは仕様が固まる前に分担と識別子を決める

本サービスが扱うのは、診療情報提供書・退院時サマリーの2文書と、傷病名・感染症・薬剤アレルギー等・その他アレルギー等・検査の5情報、それに健診結果報告書と患者サマリーです。臨床情報は種類ごとにcollection型のBundleへまとめ、Patient以外の付帯情報はcontainedで埋め込みます。各Bundleには「保険医療機関番号^発行年^施設内ID」の識別子を振り、更新と取消の状態を電子カルテ側で持ち続ける必要があります。

技術解説書2.1.0版は、モデル事業以外での実装・導入を控えるよう明記した検証用の版です。運用開始用の版は令和8年度冬頃に出る予定なので、今のうちに進めるべきは、どのシステムがどのデータを持ちFHIRを組み立てるかの分担、識別子の採番ルール、接続方式の選定です。リソースの細部はその版を見てから実装します。

電子カルテ情報共有サービスの4つのサービスと2文書5情報の範囲

厚生労働省の電子カルテ情報共有サービスのページは、本サービスを「全国医療情報プラットフォーム」の仕組みの1つと位置づけ、提供する機能を4つ挙げています。

文書送受信・健診文書・臨床情報・患者サマリーの4サービスと利用施設

4つのサービスは、登録できる施設と取得できる施設が違います。システムベンダ向け技術解説書2.1.0版の2章の表を要約すると次のとおりです。

サービス	登録する施設	取得・閲覧する側
文書送受信	保険医療機関（医科）	保険医療機関（医科）
健診文書登録・閲覧	保険医療機関（医科）	医科・歯科・薬局・保険者・本人
臨床情報登録・閲覧	保険医療機関（医科）	医科・歯科・薬局・患者本人
患者サマリー登録・閲覧	保険医療機関（医科）	患者本人

登録するのは医科の保険医療機関だけです。歯科診療所や薬局のシステムは取得側の実装が中心になります。健診センター（単独型）、訪問看護ステーション、介護事業所は当面対象外とされています。サービスは24時間365日利用でき、利用の前提としてオンライン資格確認の導入が必要です。

処方が臨床情報から外れ「2文書5情報」になった経緯と保存期間の違い

以前は「3文書6情報」と呼ばれていました。JP-CLINS実装ガイド1.13.0（2026年8月31日）は、このうち健診結果報告書を別の実装ガイドに分け、2文書5情報を扱う構成です。6情報にあった処方は、5情報送信仕様で「単独でCLINSに送信されることはない」とされ、2文書の中で処方内容を書くためにだけ使います。

保存期間は情報ごとに違い、ここが閲覧側の画面設計に効きます。傷病名・感染症・薬剤アレルギー等・その他アレルギー等は登録日から5年間で、医師の判断で長期保存フラグを付けられます。救急・生活習慣病に関わる43項目の検査は「1年間もしくは直近3回分」、患者サマリーは180日間です。感染症は梅毒STS・梅毒TP抗体・HBs・HCV・HIVの5項目に限られます。

臨床情報を送るFHIR Bundleの構造とcontainedで埋め込む付帯情報

5情報の送信仕様は、JP-CLINSの5情報送信仕様と技術解説書の機能11にまたがって書かれています。2つを突き合わせると、臨床情報と文書情報ではBundleの作り方が根本から違います。

Bundle.typeとmeta.tagでリソース種別を1つに絞る臨床情報の送信単位

臨床情報のBundleは type を collection にし、meta.tag に登録するリソース種別（Condition・AllergyIntolerance・Observationのいずれか）を書きます。1つのBundleに複数種類を混ぜることはできず、傷病名と検査結果は別々のBundleで送ります。プロファイルはBundleがJP_Bundle_CLINS、傷病名がJP_Condition_eCS、アレルギーがJP_AllergyIntolerance_eCS、検査と感染症がJP_Observation_LabResult_eCSです。

薬剤とそれ以外のアレルギーは同じAllergyIntoleranceで書き、category の値（medication、foodやenvironment）で受信側が区別します。検査と感染症も同じObservationで、検査項目コードで分かれます。文字コードはBOM無しのUTF-8で、すべての文字列をNFCで正規化する決まりです。

Patient以外はcontainedに入れて#idで参照する規則と必須の付帯情報

Bundleの中で別のentryを参照できるのはPatientだけです。外来受診歴、医師、オーダ、検体といった付帯情報は、各リソースの contained に埋め込み、"reference": "#Encounter20240601001234101" のように先頭に # を付けたidで参照します。

必須の組み合わせは技術解説書5.3節に決まっています。ObservationにはEncounterと、オーダした医師の氏名・IDを持つPractitionerが必須です。ConditionはEncounterが必須、AllergyIntoleranceはどちらも任意です。Encounterは status を finished、class を入院IMPか外来AMBにします。containedのPractitionerは meta.lastUpdated を持てないため、JP-CLINS版ではなくJP-CoreのJP_Practitionerプロファイルを使う、という落とし穴もあります。

文書情報はdocument型のBundleでCompositionを起点に組み立てる

診療情報提供書と退院時サマリーは type を document にし、Compositionを中心にリソース間を自由に参照できます。技術解説書3.4節は、当面はCompositionの各セクションをNarrative（XHTMLの叙述）だけで書いてもよいとしています。構造化が必須なのは臨床情報と健診結果報告書です。

文書の中に5情報に当たる記述を入れる場合は、5情報と同じ仕様で書く必要があります。本サービスは文書から該当情報を取り出して管理するためです。退院時サマリーは診療情報提供書に添付する扱いで、別ベンダが作るときは両文書を1つのJSONにまとめ、Bundle.identifierを同じ値にそろえます。

Bundle.identifierの発番ルールと更新・取消を追える識別子テーブル

技術解説書の機能3は、本サービスに登録するすべての情報と文書に一意の識別子を求めています。採番と状態管理を後付けにすると、更新と取消の処理を作り直すことになります。

保険医療機関番号^発行年^施設内IDで組む識別子と複数ベンダの採番

Bundle.identifierは、保険医療機関番号10桁、識別子を発行した西暦年4桁、施設内で一意の英数字1〜36文字を、半角の ^ で連結します。JP-CLINSの公式作例では 1311234567^2024^0123-IDa-203949583949 のようにハイフンを含む値が使われています。発行年は情報の発生日ではなく発番した年です。

電子カルテ、検査システム、文書作成システムがそれぞれ登録する医療機関では、施設内IDが衝突しないよう、システムごとに先頭文字を割り当てるなどの命名規則を院内で統一します。技術解説書が推奨するのは、識別子を送信するシステムで一元的に保存・管理する方法です。閲覧画面の「登録医療機関名」は識別子の先頭10桁から引かれるので、番号の誤りはそのまま表示の誤りになります。

同一識別子での上書き更新と取消後の再利用禁止を管理する状態列

登録済みの情報を直すときは、同じBundle.identifierで送り直します。過去のデータは一式削除されて新しい内容に置き換わり、保存期間の起算日も最新の登録日になる仕組みです。保存期限を過ぎた識別子で変更を送ると、新規登録として扱われます。

取消は逆です。取消したデータと同種の情報を再登録するときに、過去の識別子を使い回すことは認められません。電子カルテ側の識別子テーブルには、識別子・リソース種別・患者・最終送信日時に加え、「有効」「取消済み」の状態列を持たせ、取消済みの値で発番しない制約をデータベースに置いておくと安全です。

送信前の事前チェックとFHIR公式Validatorで二段に検証する手順

本サービスは登録時にバリデーションを行い、規則に外れたデータはエラーで返します。JP-CLINSのValidationガイドはHL7公式Validatorでの検証手順を示していますが、技術解説書にしか書かれていない運用上の規則はそこに含まれません。そこで、公式Validatorの前に軽い事前チェックを1段挟みます。

日時5形式・NFC・必須のcontainedをPython標準ライブラリで先に弾く

技術解説書が定める日時の形式は、YYYY-MM-DD、時差付きの YYYY-MM-DDThh:mm:ss+zz:zz、ミリ秒付きの3種が原則で、YYYY と YYYY-MM はConditionの要素に限って許されます。次のスクリプトは、この日時形式に加え、Bundleの型とmeta.tag、識別子の形式、UUIDの重複、参照先、必須のcontained、BOMとNFCを検査します。実行に必要なのはPython 3.9系以降の標準ライブラリだけです。

import json
import re
import sys
import unicodedata

# 技術解説書2.1.0版（機能3・機能11・5.3節）の規則を、公式Validatorに掛ける前に確かめる
BUNDLE_ID = re.compile(r"\d{10}\^\d{4}\^[0-9A-Za-z-]{1,36}")
DATE_OK = [re.compile(p) for p in (
    r"\d{4}-\d{2}-\d{2}",
    r"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}[+-]\d{2}:\d{2}",
    # ③の「.SSSZ」は、公式作例が .000+09:00 で書かれているため Z と時差表記の両方を許す
    r"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}(Z|[+-]\d{2}:\d{2})",
)]
DATE_CONDITION_ONLY = [re.compile(r"\d{4}"), re.compile(r"\d{4}-\d{2}")]
KINDS = {"Condition", "AllergyIntolerance", "Observation"}


def is_date_key(k):
    return k.endswith("DateTime") or k in ("recordedDate", "birthDate")


def walk_dates(node, rtype, path, errs):
    if isinstance(node, dict):
        for k, v in node.items():
            if is_date_key(k) and isinstance(v, str):
                ok = any(p.fullmatch(v) for p in DATE_OK)
                if not ok and rtype == "Condition":
                    ok = any(p.fullmatch(v) for p in DATE_CONDITION_ONLY)
                if not ok:
                    errs.append(f"{path}.{k} の日時形式が許容5種に無い: {v}")
            walk_dates(v, rtype, f"{path}.{k}", errs)
    elif isinstance(node, list):
        for i, v in enumerate(node):
            walk_dates(v, rtype, f"{path}[{i}]", errs)


def check(raw):
    errs = []
    if raw.startswith(b"\xef\xbb\xbf"):
        errs.append("BOM付きUTF-8になっている（BOM無しが条件）")
    text = raw.decode("utf-8-sig")
    if unicodedata.normalize("NFC", text) != text:
        errs.append("NFCで正規化されていない文字列がある")
    b = json.loads(text)

    if b.get("type") != "collection":
        errs.append(f"臨床情報のBundle.typeはcollection（現在: {b.get('type')}）")
    tags = [t.get("code") for t in b.get("meta", {}).get("tag", [])]
    kind = tags[0] if len(tags) == 1 else None
    if kind not in KINDS:
        errs.append(f"Bundle.meta.tagに登録するリソース種別を1つだけ書く（現在: {tags}）")
    bid = b.get("identifier", {}).get("value", "")
    if not BUNDLE_ID.fullmatch(bid):
        errs.append(f"Bundle.identifierが「医療機関番号10桁^発行年^英数字36字以内」でない: {bid}")

    urls = [e.get("fullUrl") for e in b.get("entry", [])]
    if len(urls) != len(set(urls)):
        errs.append("Bundle内でfullUrlのUUIDが重複している")
    patient_urls = {e["fullUrl"] for e in b["entry"] if e["resource"]["resourceType"] == "Patient"}

    for i, e in enumerate(b.get("entry", [])):
        r = e["resource"]
        rt = r["resourceType"]
        if rt == "Patient":
            continue
        if rt != kind:
            errs.append(f"entry[{i}] の {rt} がmeta.tag（{kind}）と違う。種別ごとにBundleを分ける")
        inner = {"#" + c["id"]: c for c in r.get("contained", [])}
        # Patient以外のリソースはcontainedで埋め込み、#idで参照する
        for ref in re.findall(r'"reference":\s*"([^"]+)"', json.dumps(r, ensure_ascii=False)):
            if ref not in patient_urls and ref not in inner:
                errs.append(f"entry[{i}] の参照 {ref} がPatientでもcontainedでもない")
        kinds = {c["resourceType"] for c in inner.values()}
        if rt in ("Condition", "Observation") and "Encounter" not in kinds:
            errs.append(f"entry[{i}] {rt} にcontainedのEncounterが無い（必須）")
        if rt == "Observation" and "Practitioner" not in kinds:
            errs.append(f"entry[{i}] Observation にcontainedのPractitionerが無い（必須）")
        for c in inner.values():
            if c["resourceType"] == "Encounter":
                if c.get("status") != "finished" or c.get("class", {}).get("code") not in ("IMP", "AMB"):
                    errs.append(f"entry[{i}] Encounterはstatus=finished・class=IMPかAMB")
            if c["resourceType"] == "Practitioner" and "lastUpdated" in c.get("meta", {}):
                errs.append(f"entry[{i}] containedのPractitionerにmeta.lastUpdatedは書けない")
        walk_dates(r, rt, f"entry[{i}]", errs)
    return errs


if __name__ == "__main__":
    ng = 0
    for path in sys.argv[1:]:
        with open(path, "rb") as f:
            errs = check(f.read())
        print(("NG " if errs else "OK ") + path)
        for msg in errs:
            print("  -", msg)
        ng += bool(errs)
    sys.exit(1 if ng else 0)

実行は python clins_precheck.py targets/*.json で、違反が1件でもあれば終了コード1を返します。JP-CLINSの公式作例Bundle-CLINS-Observations-Example-01のJSONに掛けるとOKを返し、識別子の区切りをハイフンに替える、採取日時を「2021/07/05 11:19」にする、containedからPractitionerを外す、のいずれかでNGになります。ミリ秒付きの形式は、技術解説書の表記が「.SSSZ」なのに対し公式作例が「.000+09:00」で書かれているため、Zと時差表記の両方を許しました。

JP-CLINS 1.13.0の検証パッケージで公式Validatorを実行する手順

事前チェックを通ったファイルを公式Validatorに掛けます。Validationガイドが推奨するのは、更新の頻繁な最新版ではなく動作確認済みのorg.hl7.fhir.coreのvalidator_cli 6.1.8版で、Java 17以上が必要です。FHIRコアパッケージをホームディレクトリの .fhir/packages に展開したうえで、次のように実行します。

# 作業フォルダを作り、CLINS検証用パッケージと公式Validatorを置く
mkdir -p vwork/pkgClins vwork/targets vwork/prog && cd vwork
curl -L -o pkgClins/jp-core.r4-1.1.2-clins.tgz https://jpfhir.jp/fhir/core/1.1.2-clins/jp-core.r4-1.1.2-clins.tgz
curl -L -o pkgClins/jp-eCSCLINS.r4-1.13.0.tgz https://jpfhir.jp/fhir/clins/pkghistory/jp-eCSCLINS.r4-1.13.0.tgz
curl -L -o prog/validator_cli_6.1.8.jar https://github.com/hapifhir/org.hl7.fhir.core/releases/download/6.1.8/validator_cli.jar
# jpfhir-terminology.r4-x.y.z.tgz は公開中の最新版を pkgClins に置く（x.y.z は取得した版に読み替える）

# 事前チェックを通ったJSONだけを公式Validatorに掛ける（Java 17以上）
python clins_precheck.py targets/*.json && \
java -jar prog/validator_cli_6.1.8.jar targets/*.json \
  -version 4.0.1 -language ja -locale ja-JP \
  -want-invariants-in-messages -no-extensible-binding-warnings \
  -display-issues-are-warnings -level warnings -best-practice ignore -tx n/a \
  -ig pkgClins/jp-core.r4-1.1.2-clins.tgz \
  -ig pkgClins/jpfhir-terminology.r4-x.y.z.tgz \
  -ig pkgClins/jp-eCSCLINS.r4-1.13.0.tgz

-tx n/a は外部の用語サーバーを参照しない指定で、JLAC10や標準病名マスターを含むterminologyパッケージをローカルで読みます。このパッケージは定期的に新しい版への差し替えが必要です。出力されたエラーを受入試験の合否にどう結びつけるか、傷病名Conditionの最小構成は電子カルテ情報共有サービス対応の実装要件を扱った章で解説しています。

電子カルテから本サービスへつなぐ接続3方式とクラウド型カルテの制約

技術解説書8.1節は、電子カルテ等から本サービスへの接続方法を3つ示しています。どれもオンライン資格確認のネットワークを使いますが、通信を担う場所が違います。

資格確認端末の連携ソフトを使うファイル連携と同時20セッションの上限

クライアントOS版のファイル連携は、資格確認端末にあるオンライン資格確認等連携ソフトが、電子カルテの書き出した要求ファイルを送り、結果ファイルを受け取る方式です。電子カルテ側の改修は最小で済みます。ただしWindowsの制約で同時接続は最大20セッションで、複数部門から同時に送る病院では待ちが出ます。

この方式で複数ベンダのアプリが同じ種類の要求を送ると、資格確認端末に結果ファイルが並び、他社の結果を取り込む事故が起こり得ます。技術解説書は、ファイル名のAPI識別IDに続く12〜20桁の任意文字列まで照合し、アプリ固有の値で一意にするよう求めています。

サーバーOS版の連携ソフトとWeb API方式を選ぶ条件と証明書の運用

サーバーOS版の連携ソフトは電子カルテのサーバーに入れて直接通信するため、セッション上限を受けません。Web API方式は連携ソフトを介さずに本サービスのAPIを呼ぶ方式で、柔軟ですが、機関認証用電子証明書を入れた端末かサーバーを経由し、本サービス用に追加されたIPアドレスへの通信をルータで許可する設定が要ります。証明書のインストールや更新計画はベンダが支援する前提です。

クラウド型の電子カルテも、施設内の証明書を入れた端末かサーバーを経由して接続します。クラウドのデータセンターから直接つなぐ仕組みは未提供で、検討中とされています。今の時点で設計に入れておく必要があるのは、施設内に中継の端末を置く構成です。

院内の複数システムで決める役割分担と臨床情報の登録タイミング

1つの医療機関に部門システムが並ぶ場合、どのシステムがFHIRを組み立てて送るかを決めないと、識別子の重複や登録エラーの押し付け合いが起きます。技術解説書8.2節は調整すべき項目を表にしています。

検体採取日時やJLACコードを持つシステムとFHIRを組み立てる側の分担

表で挙がる項目のうち、設計に直結するのは次の4つです。

データの所在：検体採取日時のように検査システムだけが持つ値を、どのシステムが受け取って組み立てるか
コードの対応：院内のJLACコードと本サービスの標準JLACコードの紐づけを、どのシステムが管理するか
被保険者番号：枝番まで含めた番号を、オンライン資格確認につながるレセコン等から正しく取得する経路
エラー対応：通信エラーやバリデーションエラーを誰が保持・通知し、再送するか

1つの文書を複数システムのリソースで組む場合は、FHIRプロファイルの版をそろえる取り決めも必要です。院内の連携方式そのもの（HL7 v2.5・SS-MIX2・FHIR APIの使い分け）は医療のデータ連携と院内4方式の比較、SS-MIX2の格納データからFHIR化の範囲を数える手順は医療情報システムとSS-MIX2・FHIR接続の実務で扱っています。

外来はリアルタイム推奨・入院は退院日当日中という登録時期とフラグ

外来の臨床情報は、病名リストやアレルギー欄を更新したとき、検査結果が電子カルテに入ったときに登録するのが目安で、受診当日に他院や薬局が見る場面を考えてリアルタイム処理が推奨されています。入院中の情報は退院日当日中まで（夜間登録も可）です。カルテを閉じたときに自動で送る作りも例示されています。

患者がマイナポータルで見る前提の制御もあります。患者へ未説明の傷病名には未告知フラグ（meta.tag のUNINFORMED）を付け、感染症は患者共有フラグ（PTS）を付けるまで患者には表示されません。2.1.0版では、傷病名は病名リストのものを原則すべて登録し、アレルギーはアナフィラキシー（疑いを含む）など重篤なものを対象とする方針に改められました。

技術解説書2.1.0は検証用：今着手する範囲と運用開始版を待つ範囲

概要案内v2.1によれば、モデル事業は令和7年2月から順に始まり、本サービスの接続検証環境と本番環境は令和8年9月頃にリリースされ、運用開始は令和8年度冬頃が目標です。医療機関の準備が済んだところから順に使い始める形になります。

運用開始用の技術解説書が出る前に進めてよい作業と止める作業の判断

今進めてよいのは、版が変わっても無駄にならない土台です。識別子テーブルと採番規則、院内のどのシステムが何を持つかの分担表、接続方式の選定と中継端末の配置、JLACコードや標準病名のマスタ対応表がこれに当たります。システムベンダ向けページには、2026年9月に公開されたFHIR記述データの手本へのリンクもあり、事前チェックの試験データに使えます。

止めるべきは、リソース要素の細部を前提にした本番向けの作り込みです。2.1.0版でも傷病名の登録基準、アレルギーの範囲、検査単位の扱いが変わりました。技術解説書は見直した項目ほど変わる可能性があるとし、正式な仕様確定を前提にした開発をしないよう求めています。加算の届出で接続がどう扱われるかは電子的診療情報連携体制整備加算の施設基準の解説にまとめています。

電子カルテ改修を外注に出す範囲の決め方と自前で作らないほうがよい場面

パッケージの電子カルテを使い、ベンダが本サービス対応版を出す予定なら、医療機関が独自にFHIR生成を作る理由はありません。対応版の時期を確かめ、院内の部門システムとの分担だけを詰めれば足ります。自前の開発が要るのは、独自の検査システムや文書作成システムが情報の出どころになっている場合、複数ベンダのシステムから送るため識別子と再送を一元管理する中継層が要る場合です。

この中継層は、事前チェック、識別子テーブル、エラーの再送をまとめて持つ小さなシステムとして切り出せます。電子カルテ本体の改修を待たずに作れる部分なので、要件を固めて見積もりたい場合は医療機関向けシステム開発で相談を受けています。

よくある質問

電子カルテ情報共有サービスについて、検索の多い質問を5つ取り上げます。

電子カルテ情報共有サービスはいつから使えますか？

厚生労働省の概要案内v2.1（令和8年7月）では、令和7年2月からモデル事業を順に始め、令和8年度冬頃からの運用開始を目標にしています。接続検証環境と本番環境のリリースは令和8年9月頃で、医療機関の準備が整ったところから順に運用を始める形です。利用にはオンライン資格確認の導入が前提です。義務化との関係や対応時期の判断は電子カルテ義務化の記事で扱っています。

他の医療機関が閲覧するとき、患者の同意はどう取りますか？

受診時にマイナ保険証で受付をし、情報提供に同意することで閲覧できるようになります。医療機関が閲覧できるのは患者が同意した項目に限られ、利用目的外の閲覧は認められません。診療情報提供書を電子で送る場合は、送付前に患者から口頭で同意を得ます。2.1.0版では診療情報提供書の同意区分から「閲覧保留」が削除され、「同意あり」だけになりました。

クラウド型の電子カルテでも電子カルテ情報共有サービスに接続できますか？

接続できますが、施設内に機関認証用電子証明書を入れた端末かサーバーを置き、そこを経由する必要があります。技術解説書2.1.0版の時点では、クラウドのデータセンターから本サービスへ直接つなぐ仕組みは提供されておらず、検討中です。クラウド型の製品を選ぶ際は、施設内の中継構成をベンダがどう提供するかを確認してください。

電子カルテに書いた記録はすべて他の医療機関に共有されますか？

共有されません。対象は診療情報提供書、退院時サマリー、健康診断結果報告書と、傷病名・感染症・アレルギー等・検査の臨床情報だけです。SOAP形式で書いた所見や診療上のメモは対象外です。傷病名は原則すべて登録しますが、他院にも患者にも共有しないと医師が判断したものは登録しなくて構いません。患者に知らせていない傷病名は未告知フラグで患者の画面から外せます。

診療情報提供書を送るときに電子署名は必要ですか？

本サービスでは、医療機関の判断で電子署名を行わずに共有できるとされています。概要案内のQ&Aは、なりすましや否認の防止、事故時の責任の所在の明確化の観点から電子署名を行うことを推奨しつつ、必須にはしていません。電子処方箋のようにHPKIカードでの署名が必須の仕組みとは扱いが違う点に注意してください。