昨日のライブデモンストレーション

昨日は一例慢性完全閉塞の治療をライブデモンストレーションで行いました。

症例は75歳くらいの男性で、CCS class 2の労作性狭心症患者さんでした。これまで、心筋梗塞の既往や、PCIあるいはCABGの既往はありませんでした。診断造影では、左主幹部遠位三分岐の病変+左冠動脈前下行枝入口部からの石灰化した慢性完全閉塞でした。

通常であれば、CABGに決まっていますが、患者さんが手術を拒否された、という理由でPCIになりました。

そのような状況ですので、順行性に行くにはあまりにも危険ですし、もちろん慢性完全閉塞部分はつるつるであり、何のとっかかりもありません。右冠動脈から良好な副血行が、conus branchを介して前下行枝心尖部に行っているのですが、これは蛇行がひどくとても使えません。PCIの時に造影して良く見ると中隔枝が使えそうです。一番遠位の中隔枝が比較的太いのですが、右冠動脈から分かれてすぐにhair-pin curveがありました。まずはそれから試みたのですが、案の定このヘアピンを越えません。その一つ手前の中隔枝を狙いました。ワイヤーは途中心室性期外収縮を出しながら何とか前下行枝近くまで行くのですが、前下行枝の中に入りません。そこでCorsairを進めるのですが、右冠動脈から中隔枝に入ったところで全く進みません。延長して、Finecrossに置換したのですが、同様に進みません。1.25mm balloonに交換しましたが同様でした。そうこうする内にワイヤーは中隔枝から抜けてしまいます。慌てずワイヤーをplastic-jacket hydrophilic wireに交換し、再度その中隔枝通過を狙いますが、今度は途中で行きません。そこで、先端造影して、ぐちゃぐちゃに既になっている中隔枝を造影で確認し、再度狙って今度はワイヤーを通過させました。しかし、そうは言っても同様にCorsiarなどが通過できないことは目に見えていたので、今度はワイヤー交換の時に思い切って7Fr guiding catheterの中に5Fr 子カテを入れて臨んだのです。もちろんこの時の予想される問題点は、Corsaiの長さが足りるか? というものですよね。可能な限り右冠動脈の中に子カテを進め、Corsairを押しこんだところ、今度は通過できなかった部分を越えていきました。しかし、もうCorsairがお尻にきいてます。そこで、メインの7Fr GCを右冠動脈内に深く挿入し、5Fr子カテも#4PD入口部まで進めました。もちろん患者さんは胸痛を訴え、ST II, III, aVFは上昇しました。それでも続けざるを得ませんでしたので、Corsairを押しこんでようやくCorsiarは前下行枝に抜けました。それから子カテをぎりぎりまで引いて虚血を解除し、Miracle 3により慢性完全閉塞部分の遠位から左主幹部への穿通をこ試みました。案の定慢性完全閉塞は固かったのですが、一か所通りやすい部分があり、その部分を通過して、左主幹部そして大動脈に抜けました。

問題はそれからです、順行性ガイディング・カテーテルからIVUSを入れて、逆行性ワイヤー (Miracle 3)が真腔を通過して大動脈に抜けていることを確認したのですが、何しろ長さが足りず、Corsairで慢性完全閉塞部分を通過することができないのです。従って、やわらかいワイヤーに置換して、順行性ガイディング・カテーテル内への逆行性ワイヤー挿入を試みるのは危険です。色々考えた末、順行性ガイディング・カテーテルから鈍角枝にワイヤーを挿入し、そのワイヤーを深く押しこんで順行性ガイディング・カテーテルを左主幹部で浮かし気味にして、ガイディング・カテーテルの向きを調整しながら逆行性Miracle 3を何とか順行性ガイディング・カテーテル内に回収しました。こうなればしめたものです。順行性ガイディング・カテーテル内で3.0mm balloonを拡張することによって traction anchoringを行い無理やりCorsairを順行性ガイディング・カテーテル内に引き込みました。それからは、300CMワイヤーを用いて型の通り行い、左主幹部から前下行枝にかけて Xience-Vを三本植え込み最終的には綺麗な仕上がりで終了しました。

みんな大喜びで、助手の先生からは、その時メインの助手と、それ以外に2名の助手、合計3名の中国人医師が助手について下さったのですが、「またファンが増えました」と、言われました。

僕の手技が放映される前に日本人のある医師が講演していました。術者として当然マイクとイヤフォンをつけているので、その内容が聞こえます。最初は慢性完全閉塞に対するTRIの効用について、続けて慢性完全閉塞に対する逆行性アプローチについての講演だったようです。内容は問題ありません。しかし、その医師の普段の診療に対する姿勢を伝え聞いていましたのでとても評価できませんでした。そんなことを思いながら黙々とPCIを続けました。最後にその患者さんが、とても嬉しそうに「ありがとうありがとう」と言って下さったことが良かったな、と思いました。

今 羽田空港国際線

これから CHC (China Heart Conference)という阜外国立循環器病センターが開催している学会に招かれて一泊二日の北京行きです。

本日到着したらばそのまま阜外病院に直行し、慢性完全閉塞のライブデモンストレーション症例を治療します。羽田便は便利になった反面、こんなことが可能となり、余裕が無くなりますね。

積年の謎が溶けかかりつつあります それは Canonical Huffman Code

自分の尊厳というか、誇りをかけて CないしC++を用いて、DICOM XA viewerを自分が死ぬまでに作成したいのです。何回も何回も挑戦しては、挫折の連続でした。

その挫折の原因は分かっているのです、どうしてもそこで使用されている Huffman Codeの decodingアルゴリズムを理解できないのです。

DICOM XAは要するにパラパラ漫画です。一枚の漫画は、JPEG Losslessで格納されているのです。JPEG Losslessという企画はもう何十年も昔に制定された国際規格であり、その企画書も読みました。そこでは、HUFFTABという領域に、Huffman Codeによる圧縮をdecodeするためのキーが書かれているのです。そこまでは掴みました。

しかし、どんなアルゴリズムの解説書を読んでも、ハフマン圧縮されたデータをデコードするためには、ハフマン木のデータが必要としか書いていません。ところが、このHUFFTABにはそんな木構造のデータは無く、表形式のデータしか無いのです。

その謎が、急に溶け始めました。まず、以前購入して難しくて読めなかった、もう廃刊となっている書籍 オーム社刊行の「映像情報符号化」という本です。

昨日この本を読んでいて、あっと思いました。そこには、ハフマン圧縮を行って実際に画像情報を圧縮するためには、いちいちハフマン木を作成しては効率が悪いので、テーブル参照法を用いると書いてありました。どうやらこれが求める回答のようでした。どうしてこんな大切なこと、他のアルゴリズムの数ある書籍には一言も記載が無いのでしょうか。

そして、本日届いた英語の書籍 “Managing Gigabytes” という本をチラチラ見ていたら、ついに見つけました。そのアルゴリズムを Canonical Huffman Codes と呼ぶらしいのです。あー 時間を相当そうですね、かれこれ4年間無駄にしました。最初にこれを知っていれば・・・

もっとも、JPEG Losslessなんて今時デジカメにも使用しないし、 DICOM XAでしか残っていない過去の遺物なので、それに用いる Canonical Huffman Codesなんてものも、世間から忘れ去られているのでしょうね。

ようやく分かった – Unix/Linuxコマンド解説にある()で囲まれた番号の意味

Unix/Linuxのターミナル・コマンドの解説には必ず

$ls(1)

のようにコマンドの後ろにカッコで囲まれた数字がついてきます。これが何なのか? コマンドの解説本にも記載は無いのです。
ずっと疑問に思っていましたが、Linuxのメモリ管理Cライブラリである glib.c について勉強していてようやく分かりました。

セクション#	トピック
1	ユーザに利用可能なコマンド
2	 UnixとCのシステムコール
3	 Cプログラム用のCライブラリルーチン
4	特殊ファイル名
5	のUnixで使用されるフ​​ァイルのファイル形式と規則
6	ゲーム
7	ワープロパッケージ
8	システム管理コマンドと手順

ということらしいのです。要するにUnix/Linuxのオンライン・マニュアルである “man”コマンドで記載されているセクション番号なのです。このセクション番号は上記のように、その役割によって分類されているのです。

何と

昨日の外来でもう10年間以上も診させて頂き、また困難な治療もさせて頂いている患者さんに初めてお二人の娘さんがご一緒に来診されました。思えば、つかの間の外来診療ではありますが、その背景には患者さんの人生がある訳です。もちろん、その人生と干渉しながら歩む私自身の人生もある訳です。
昨日、その娘さんから、このブログをご覧になっていることを知らされました。恥ずかしいやら、驚くやら、いやー どこで複雑に色々なことが絡み合っているか分かりませんね。