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

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

緒言

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

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

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

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

そこで、「雰囲気で使わずきちんと理解する！整理してOAuth2.0を使う」を読んで、ブラウザー挙動から動きを探った。
（FIDO認証を想定、用語は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. ローカルでPrescriptionDocument要素を作って、6.のPrescriptionSign要素を付加して、電子署名付き処方箋.xmlが完成。

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

---

結語

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

---

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

加齢黄斑変性に対するアイリーア８ｍｇの使用経験 兵庫医大眼科学講師　佐藤孝樹先生

• ほかの薬剤で効果が不十分だった症例の中でも、効果がみられる症例が確かに存在する。
• いずれにしても発売後９か月しかたっていないので評価が定まっていない。

ＤＭＥに対するアイリーア８ｍｇの使用経験 神戸大学眼科学講師　楠原仙太郎先生

• アイリーアのターゲット:VEGF-A、VEGF-B、PIGF
• バビースモ:VEGF-A、Ang2
• 投与モル比
  ルセンティス　０．５
  アイリーア２mg　１
  バビースモ　２
  アイリーア8mg　４　薬価は一番高い。
  ベオビュ　１１　→　強すぎるのでいろいろ副作用が出るのかもしれない。
  
  以前の「硝子体注射薬の山城先生の感触」を上記と合わせて改訂すると

商品名	効き目
ルーセンティス	弱
ラニビズマブBS(≒ルーセンティスのゾロ)	弱
アイリーア２ｍｇ	中
バビースモ	中(～強)
アイリーア８ｍｇ	強
ベオビュー	強強

長崎大学　大石明生教授

• AMDの定義がまたまた変わった。
• 滲出型→新生血管型
• ５０歳の基準を撤廃。↓と関連す。
• pachychoroidを包含→PNV
• 典型AMDはなくなった。
• RAPに対するPDTは推奨されない。

PNV (Pachychoroid Neovasculopathy):パキコロイドに関連して発生するNVという概念が台頭してきているらしい。PDT治療が奏功するPCVはここに属する由。

感想

• かつては、「神経眼科やってると格好いい」だったのが、いまは「黄斑周りやっとります！😤」みたい。
• ここでは、日本人学者はPCVをパキコロイドに入れないように抵抗していると書いたが、欧米学派を受け入れつつあるのかな？
• 開業医的にはバビースモ最強と思ってたけど、アイリーア8mg最強説かもしれない。当院でもスイッチして奏功した例がある。
• バビースモとアイリーア8mgを交互にカクテルショットみたいな発表は聞いたことがないんだが、レセプターをかえモル比を変えるという戦略はアリかも。

 

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

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

 

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

電子処方箋の取り扱いには、電子署名、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は加えず」

参天製薬の｢近視進行抑制剤｣に注目が集まる理由 国内で初承認
をみつけ、参天製薬に問い合わせたところ、

現在発売時期なども未定の中なので提供できる資料などが非常に乏しい状態でございます。参天＋アトロピンでの論文となると現状下記の一報のみとなります。

光干渉断層撮影法と眼底写真によるアトロピン応答を予測する近視イメージングバイオマーカー 

要約は、

アトロピン点眼が眼軸長延長の抑制効果を予測するには、「OCT所見のGCL＋(≒GCC)、眼底写真のRGBのうちR要素」と相関があった。

この論点は初見だな。今後、アトロピン点眼を処方するときに有用かも。

---

この点眼薬の特徴は

• 濃度は０．２５％である。学童の近視進行抑制2023 – 眼科医のブログ　で述べたように「日本人を対象とした研究では、0.01%アトロピンの点眼の有効性が、他国人(≒欧州人、シンガポール人)よりも出にくい。」ことがあるのかもしれない。
• 使いきりである。：マイオピンとの差別化かな。
• 費用：自費診療で、４千円/月らしい。従来品はこちら。

☞ 当院では０．０１％、０．０２５％、０．０５％を調剤しています。全部２５０円ですが使いきりではないです。

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

１．オンライン資格認証の場合は、機器を手順書通りに設定すれば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サービスデスクに問い合わせると教えてくれることがある。(ただし、放置のこと甚だ多し）

---

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

Johnson&JohnsonからAR Eyeというアプリがリリースされました。

「AREye」は、拡張現実(AR)の技術を用い、白内障の術前・術後の見え方を擬似体験できま丸スマートフォンのカメラを通して現実の風景をもとにバーチャルな映像を再現。白内障の方だけでなく、ご家族が白内障の不自由さを体験し理解を深めることにも役立ちます。

 

当院でも、多焦点レンズを希望する患者さんには体験してもらうことにしています。

☞ハロー・グレアが若干強めに出るような設定にしてるとのことでした。

ビッセン宮島先生のお話が聞けるというので受講しました。

トーリックレンズの話

• 手術後の残余乱視は0.5D以下を目指す。
• 直乱視を残したほうが偽調節が働くということはない。調節が働く要因は小瞳孔と角膜のmutifocalityである。
• 日本ではトーリックレンズの採用率が1割程度。これは仕入価が高い+術前術中の操作が面倒なため。残余乱視≦0.5Dを目指すなら半分以上がトーリックとなるべき。

☞当院では半数弱がトーリックレンズ挿入しています

Odysseyの話

• 回折格子形状がちがう。詳細な話はなかったです。

• 術後オートレフ値はマイナスにでる。ので、自覚視力測定が大事である。Vivityもその傾向あり。
• SynergyはFirstPositiveだったが、FirstNegativeを選択する。ここで担当さんが言ってた話。

• デフォーカス曲線が-0.5D～+0.5Dまでほぼ直線である！そのためtargetずれに強い。

☞アイハンスやVivityの項でも書いたが、デフォーカス曲線のFar平坦化は今後トレンドになるんでは？

 

HOYAから多焦点レンズVivinexが発売されている。

PanOptix対抗だが違いは

1. 回折格子の範囲が3.2ｍｍである。PanOptixは4.5mm。したがって夜間運転時（瞳が散大する時）、グレハロが少ない。
2. 中間が+1.75D、近見が+3.5D加入である。PanOptixは中間+2.17D、近見+3.25D。したがって近見が強い。

後発なので、ライバル社の欠点を消しに来てる印象。

A:PanOptix B:Synergy C:FineVision D:Vivity

当院でも、オプションとしてご説明の上、御希望の方には適用する予定です。