投稿者: Koji

関西医大教授　今井　尚徳先生@西部地区眼科医会総会のご講演でした。

面白いと思ったのは

１．眼内レレズのフランジ手術を行う際に術中OCTを併用すると、眼内レンズの傾斜が抑制できる。

２．黄斑円孔に網膜フラップを設置するときも、術中OCTで正しくZ軸方向の位置同定が可能となる。

３．CME切開は、硝子体注射の難治症例のうちの50％～60％に対して効果がある。

教授就任式でいわれていた「単に手術がうまいだけというのではなく、それを定量的に科学に落とし込む」という意味合いがよく了解できました。

アイハンス(によく似たプロフィールのレンズで、EMとはEnhanced monofocalの意。

すなわち、「焦点深度深めで、farのdefocusが平ら気味、保険適応が効く」レンズである。

Defocus Curveは以下の通り。　アイハンスはこれ。

構造は　Vivinex Impress | Hoya Surgical Opticsによると、

同心円様の構造がわずかにみえる。

アイハンスは全くそのような構造物をもたない。

HOYAが主張する

アイハンスは0.5D～0.75D付加だが、EMは-1.0D付加できる。

というのは、このわずかな構造調整に依るのかもしれない。

多焦点眼内レンズの焦点深度を深める手段として、HOYAからParingという新手法が発表されています。

左右のレンズでdefocus曲線のpeak値を変えるという点が新しい。
peak値のみを変えるのであっって、peak位置を変えるわではないのも佳い。

Vivinex Gemetricが通常の３焦点レンズで、Vivinex Gemetric Plusが近見のpeak値を底上げした３焦点レンズ。

_{Vivinex GemetricとVivinex Gemetric Plus}

 

 

 

 

 

 

 

佐々木先生のFEST法を敷衍してるようでもあり、一眼手術後に近見満足度が高ければ対眼にもGemetricをいれ、不満ならGemtrci plusを入れる戦略である。（ただし、優位眼、非優位眼の選択は採らないらしい）

ミニウェルフュージョンシステムにも通じるが、回折格子の口径が全く同じというのが売り。
この部分が比較的小さいことにより、夜間ハログレをおさえ得るというのがHOYAの主張なのである。

---

後発なだけあって、いろいろと取り入れてるなとは思う。

日本ではようやく挿入され始めたばかりで、今度の日眼で一か月後の経過が発表される。
発表を聴いて、追ってご報告いたします。

 

前回までで、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なら楽勝。

---

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

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

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

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

• アイリーアのターゲット: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要素」と相関があった。

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

---

この点眼薬の特徴は

• 濃度は０．0２５％である。学童の近視進行抑制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サービスデスクに問い合わせると教えてくれることがある。(ただし、放置のこと甚だ多し）

---

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

 

2025/06/27追記。

「電子処方箋に力を入れていただいているようですが、電子処方箋の90％は使われていないようなので、どのように運用されているかを教えてください」と、社保の電子処方箋担当から電話がありました。

「電子処方箋=<issueType>1</issueType>でxml提出してたが、実際に電子処方箋を使う人はほぼいない」のが問題だったらしい。

1. 従来の紙処方箋を希望した場合
   <issueType>2</issueType>でxml提出 ⇒ 電子処方箋対応引換番号：xxxxを記載した紙処方箋のみを渡し、電子処方箋の処方内容(控え)は渡さない。
2. 本当に！電子処方箋を希望した場合
   <issueType>1</issueType>でxml提出 ⇒ 電子処方箋の処方内容(控え)のみを渡し、紙処方箋は渡さない。
   

従来発行した処方箋は取り消し操作しなくてはいけないかもとのこと。😢