投稿日:

診療報酬 20240601 改訂

2024 5/31 → 6/1 に日付が変わった頃、テスト用サイトのページ
https://phazor.jp/dolphorca/test/
に若干の手を加えた。

なんで変更したかわからない人もいたようだが、健康保険報酬の 6/1 改訂で診療行為によってはレセプト記載上、選択式のコメントを選ばないといけないが、これが各種アプリでうまく動くか確認したかったから。

ドルフィンもそうなのだが、設計の古い電カルはこれに対応できない。

あくまでレセプト記載上であって診療録に記載せよとは言ってないので、致命的というほどではないが、レセコンでいちいちコメント入力するのは不便なことこの上ない。

 

ところで、上記ページのシンプルな機能（使ったファイルは３つだけ）は実は「３層クラサバ」構成をとっている。
ブラウザからの検索語を受信して orca DB に問いかけているファイルが「バックエンドサーバー」にあたる。

かつて標準型電子カルテの厚労班会議で「３層クラサバ」だの「フロントサーバを院内に設置する」だのあーだこーだ言っていたのは、具体的にはこういうこと。

院内にオンプレの WebORCA が稼働していた場合、クラウド上のバックエンドと院内 WebORCA をダイレクトに通信させるのは難しいが、（上で言った）バックエンドを院内に設置した上で必要な情報だけを（クラウド）バックエンドと通信するのはそれほど難しくはない。

投稿日:

レセプトのコメント

ORCA の ML でも話題になったのだが、近年になってレセプトのコメントが複雑になってきた。

マスターを漁りに行く。（↓ のページ）

ところで、何でこんなことを気にしなければならないかというと、まだ、コメントがそれほど重視されていない時代に設計されたレセコンや電カルがそのままでは使えなくなってしまうから。

例えば、ドルフィンで言うなら、精神科で新設された 82 系のコメント（通院精神療法算定時に用いるコメント）には全く対応できていない。

診療行為が新設されても対応は比較的楽で、ドルフィンが参照している ORCA の tbl_tensu テーブルに新規のアイテムを挿入すればいい。
実際、そのようにすると新設されたアイテムを表示することはできる（下図参照）。

だが、その一方で新設されたコメントは、形式的には tbl_recekisai に格納するのが適当なので、当然のことながら、表示すらされない。

 

（続く）

投稿日:

HPKI signer For Mac

X(twitter) あたりでごちゃごちゃいってたやつは、結局、chrome 拡張にして chrome ウェブストアで公開しました。

NativeMessaging を使っているので、これだけだと何も機能しませんが「署名カードドライバ」などを設定すれば、Mac のブラウザから電子署名値（秘密鍵による暗号結果ですが）を取得することができます。

設定方法などは、このページで案内しています。

HPKI signer For Arm Mac になってますが、ドライバのビルド設定確認したらユニバーサルバイナリになっていたので、おそらく Intel Mac でも動くと思います。

 

猪股弘明

投稿日:

C 言語における 16 進表記文字列⇄バイナリ列変換

C 言語では、わかりやすい感じのフレームワークはそれほど多くないせいで、例えばタイトルのようなことをやらせようとすると苦労する。

16 進表記文字列→バイナリ列変換

これは、よくネット上で落ちている。

後利用しやすいように書けば

uint8_t* hex2bin(char* hex, size_t length) {
    static uint8_t* bin;
    bin = malloc(length/2);//need free(bin) later
    
    for (int i=0; i<length; i+=2) {
         unsigned int x;
         sscanf((char *)(hex + i), "%02x", &x);
         bin[i/2] = x;
    }
    
    return bin;
}

ポインタが hex である長さ length の文字列を渡せば、バイナリ列のポインタを返してくれる。

バイナリ列→16進表記文字列変換

この記事の発想にいたく感心した。

ポインタを使うと初学者はわかりにくくなると思い、一部配列表記にしている。

char* bin2hex(uint8_t* bin, size_t length){
    static char* magicarray = "0123456789ABCDEF";
  
    static char* hex;
    hex = malloc(length * 2 +1);//need free(hex) later
    
    for(int i = 0; i<length; i++){
        uint8_t octet = bin[i];
        hex[2 * i] = magicarray[octet / 0x10];
        hex[2 * i + 1] = magicarray[octet % 0x10];
    }
    hex[length * 2] = '\0';
    return hex;
    
}

要するに

「バイト列の一つの要素に注目したとき

（文字列表記上の）上位 4 bit 相当部分は、その要素を 0x10 (=16) で割った商

（文字列表記上の）下位 4 bit 相当部分は、その要素を 0x10 (=16) で割った余り

」

という論理。

その際に 16 進表記特有の文字（ A…F） を指定するのに、専用の配列を用いている。
上のコード上では、その配列を magicarray としたが、こうするとすっきり書けますね。

 

猪股弘明