カテゴリー: 電子処方箋

前回までで、HPKIカードの電子署名モジュールは自作できた。

が、本番カードが来ないので、セカンド証明書を使うしかない。
そして、その症例報告は皆無である。

緒言

• 物理HPKI証明書の知識は不要。☞ サーバーが署名して、ローカルにxmlを返却する仕組み。
• ローカルマシンとサーバー間のHandshakeが、分かりにくい。

ローカルマシンとサーバー間のHandshake

• 本態はOAuth2.0+OpenIDである。リモート署名クライアントアダプターインストール手順 によると

初見時の感想は「よう分からんナ～。分からんものを、使う気にならん～」

そこで、「雰囲気で使わずきちんと理解する！整理してOAuth2.0を使う」を読んで、ブラウザー挙動から動きを探った。
（FIDO(＝Fast IDentity Online)認証を想定、用語はOAuth2.0とOpenIDで異なるが、OAuth2.0用語に統一)

cf.  セカンドHPKI証明書の覚書きWiki

セカンド証明書署名ライブラリー

物理カードモジュールとは異なり、多業者が参入しているわけではない。
現状 HPKIセカンド証明書リモート署名ライブラリ一式Ver2.10 一択。

提供ライブラリーには、

1. ExamplePublisherClient.exe
2. RemoteSignatureClientAdapter.exe
3. RemoteSignatureClientService.exe

が含まれている。

うち、ソース提供があるのは 1.ExamplePublisherClient のみ。
2.3.は完全にブラックボックスで、リバースエンジニアリング厳禁とある。

役割分担の考察

1. RemoteSignatureClientAdapter.exeは、ポート番号3000を待ち受けするサービス。タスクスケジューラに登録する。
2. RemoteSignatureClientService.exeは、ポート番号5000を待ち受けするサービス。タスクスケジューラに登録する。
3. 上記ポートのリスニングは1.の起動時に走るNode.jsサーバーが担当する。
4. ExamplePublisherClient.exeは「OAuth2.0+PKCE+OpenID+スマホ認証」のHandshake図で記した煩雑なトークン処理をRemoteSignatureClientAdapterに投げる。🔹 KeyCloakで「生体認証」が完了。
5. 4.で受け取ったIDトークン＋「HPKIセカンド電子証明書管理サービスクライアント証明書」を、(WebAPI選択の場合は)RemoteSignatureClientService経由で管理サーバーに渡す。🔹 「生体認証」＋「所有認証」が完了。
6. 5までが成功すると、管理サーバー上の「HPKI セカンド電子証明書」を使う権利が生じ、PrescriptionDocumentのハッシュ値を管理サーバーに送付する。管理サーバーはこのPrescriptionDocumentのハッシュ値と、管理サーバーがもつKeyinfo要素とSignedProtperties要素の参照３要素を、管理サーバー上の「HPKI セカンド電子証明書」の秘密鍵で署名しPrescriptionSign要素としてJSONで返してくる。
7. ローカルで処方箋のcsvからPrescriptionDocument要素を作り、6.のPrescriptionSign要素を付加して、電子署名付き処方箋.xmlが完成。

大枠、こういう流れになってると思う。

---

結語

1. RemoteSignatureClientAdapterとRemoteSignatureClientServiceの相当物をスクラッチから作るのは、できなくはなかろうがかなりの難題であり、かつ、セキュリティホールができるだろう。MedisがFindexに委託したのもこの所以かもしれん。
2. ExamplePublischerClient.exeは、WebAPIを選択すると、署名APIUrlの5000ポート、つまり、RemoteSignatureClientServiceを使う。一方、ライブラリを選択すると、直接管理サーバーの署名APIをたたいているようにみえ、つまり、RemoteSignatureClientServiceを使わないようだが、うまくは動かない。
3. 2のWebAPI利用なら、セカンド証明書電子署名モジュールは自作できる。著作権は「一般財団法人 医療情報システム開発センター」および「株式会社ファインデックス」帰属なので、Github公開できないがC#erなら楽勝。

---

この一連のサービスは遠からず、有料化されるらしい。
有料化されるまでに、本番カード届くのかナ？！

前回、「市販モジュールで管理サーバーと交信」はできた。

自力ベンダーとしては、しかし、電子処方箋モジュールも自作したいところである。

 

と或る電子カルテメーカーに、問い合わせると

電子処方箋の取り扱いには、電子署名、ICカードのハンドリング等の技術が必須になりますので、 かなりハードルが高いです。

 

 

自分でできる範囲内のことを、やることにする。

---

目標

• ES型式の署名付き医師処方箋発行を目指す。調剤処方箋とか、ES-XLとかは一切触らない。

使用言語

• C#：Base64エンコード、exc-c14n正規化、SHA256hash計算はできそう。

電子署名、ICカードのハンドリング

APDU Handling

• HPKIカードで署名してみる は、APDUコマンドを直接カードに送り込んでいる。この手法は大部であるし、もっとオサレな方法はないのか？と調査したところ、、

High-Level API

• 電子署名に使えるHigh-LevelAPIがあると判明。

  	PKCS#11	CNG/CryptoAPI
  Cross-Platoform	Yes	No(Windows-only)
  Direct Token Aceess	Yes	Indirece(via middleware)
  Eas of Use	Moderate	High
  Dependency	Vendor’s PKCS#11 library	Windows CSP/KSP

  ☞　HPKIドライバーは提供されているので、PKCS#11でいく。

• BouncyCastle：有名なライブラリだが、直接スマートカードにアクセスはできない。スマートカードをPCに接続しHPKI driverをインストールすれば、証明書ストアに公開鍵関連データが保存される。そのストアにアクセスする仕様。従って、証明書取り出しと検証(←公開鍵要、秘密鍵不要)は可能で、そこに関してはPKCS#11系でやるより美しく書ける。
• 以上より、署名はPKCS#11で、証明書取り出しと検証はBouncyCastleを使う。

xmlの仕様

取り寄せた市販モジュールの出力xml、OSNに掲載されてる各社の電子処方箋xmlを諸所比較すると、結構違いがある。

• xmlの名前空間：xsかdsか。

	ds:	xs:
Namespace URI	http://www.w3.org/2000/09/xmldsig#	http://www.w3.org/2000/09/xmldsig#
Primary Usage	Digital signatures	XML Schema definitions
Scope	Ensures security (signatures, keys)	Defines structure and data types
Common Context	Security-related XML documents	XML Schema files or validation rules

xsを使ってる例のほうが多いようだが、XAdES(XML Advanced Electronic Signatures) 型式なんだから、dsのほうが良いんじゃね？ 仕様書もdsつかってるみたいだし。

• PrescriptionDcoumentをexc-c14nで正規化するかどうか。
  正規化してもしなくてもいいようで、正規化しない例のほうが多い。
  ただ、KeyInfoとSignedPropertiesは正規化必須なので、PrescriptionDcoumentも正規化するほうが整うと感じる。

• IssurerSerialをどうするか
  いれてない例もあるし、入れててもIssuerNameとSerialNumberを別々に載せている場合、IssuerNameとSerialNumberをくっつけるSigningCertificateV2を採用してる場合がある。
  SigningCertificateV2に移行するらしいので、これを使う。

完成したやつ

• HPKISigner.exe “入力csvのパス” “出力xmlのパス” PIN
• .net8.0なのでwin-64のみならず、linux・mac・mac-armとCross-platform(のはず)
• 今一、全く自信ないので、いつでも市販モジュールと交換できるようにしてる。
• Github に載せました。

---

これで、一安心の一歩手前。しかし、肝心の本番カードは未入手である。。

 

2025/2/18追記

セカンドHPKIは「xs:を使っており、PrescriptionDcoumentはexc-c14nで正規化しておらず、IssurerSerialは加えず」

厚労省は「オンライン資格認証の次は電子処方箋」というが、自力ベンダーにとって実施は困難を極める。

１．オンライン資格認証の場合は、機器を手順書通りに設定すればxmlが受信できた。IPv6とかルータの設定がややこしいくらい。

２．電子処方箋の場合は、自分で処方箋データをxml化して送信するので、設計仕様書や他人作のxmlを解読する必要がある。

３．電子処方箋署名モジュールを自作するならRSA暗号、PKI、OpenSSLなど理解・把握したうえでコーディングする必要がある。

---

オンライン資格確認と違って、ほとんど事例が見当たらぬ。
ホンマにできるんかぃな？！
ヤだけどORCA使うか😥。。と思って調べると

どうやら、ORCAも電子処方箋署名モジュールは外注しているらしい。厚労省も業者紹介してる。

「なぁ～んだ」と思って、各業者に問い合わせたら、ほぼ以下の返答の如し。

署名サービスの販売は、電子カルテ・レセコンの開発・SIベンダー様に対して販売をしております。
そのため、貴社に導入されています電子カルテまたはレセコンベンダー様に導入のお問い合わせを頂きたくよろしくお願いします。

自力ベンダー相手だと、サポートで割合わんのだろう。
かろうじて、以下3社のみ提供してくれそうだと判明。

 

	言語	価格	感想	対応
A社	java	6K/y サブスク	exeにcsvファイルの引数を渡せば、署名付きxmlを返してくれる	質問には一応答えてくれる様子。ドキュメントが充実している。
B社	java,.net	22k買切	dll型式で取り込み可能	WebORCAを自力実装した人にのみ売ってくれる。個人対象のサポートは一切ない。
C社	C++	16K位買切	試用したがエラー発生。謎	秘密保持契約書まで結んだが、自力ベンダーだというと、引かれてしまった。

ここで、A社製品をググって、電子処方箋 導入記  をみつけた。
この先生は、黎明期の紙の電子処方箋時代から取り組んでおられる由で、小生質問にも丁寧にご返答いただきました。
直接お会いしたことはないものの、自作カルテの先達と感じ入っております。改めて、御礼申し上げます。

---

勝手連的に記事をまとめると

1.確定前電子処方箋xml

• 院内カルテのcsv処方箋を、電子処方箋管理サービス記録条件仕様_処方編、一般処方名マスタ、用法マスタ に従って作成する。
• 文末の改行は\nにする。
• 電子署名処方箋モジュールに渡す。
• 得られた電子署名付き処方箋xmlをBase64でエンコードして、PrescriptionInfoというxmlエレメントにいれる。
• 必要なxmlエレメントを上下付加する。
• ファイル名は EPSsiPIR01req_xxxxxxxxxxxx.xml ( xxxxxxxxxxxxは１２～ ２０桁の数字アルファベット)

2.重複チェックxml

• 1と大筋同じ。
• ファイル名は EPSsiDMP02req_xxxxxxxxxxxx.xml

3.PDF要求xml

• 1.のresで帰ってきたPrescriptionIDを挿入する。
• ファイル名は EPSsiPIR06req__xxxxxxxxxxxx.xml

reqフォルダに上記のreq xmlを置くと、resフォルダに返答がかえってくる。
resエラー時には、医療機関等ONSサービスデスクに問い合わせると教えてくれることがある。(ただし、放置のこと甚だ多し）

---

とりあえず、上記手順で成功したので、まずは一安心の二歩手前。
次は、電子処方箋署名モジュールを自作してみる。