日医標準レセプトソフト API（HAORI）仕様書

日医標準レセプトソフト API（HAORI）
仕様書
（暫定版）
2014/11/14
ORCA PROJECT
改訂履歴
目次
1.
概要 ................................................................................................................................. 1
2.
目的 ................................................................................................................................. 1
3.
構成 ................................................................................................................................. 1
3.1.
API が適用されるハードウェア構成 ....................................................................... 1
3.2.
API のソフトウェア構成 ......................................................................................... 4
4.
動作条件 .......................................................................................................................... 5
5.
プロトコル階層 ............................................................................................................... 5
6.
通信手順 .......................................................................................................................... 6
6.1.
基本通信手順............................................................................................................ 6
6.2.
エラー処理の考え方................................................................................................. 8
6.3.
情報更新の排他制御の考え方 ................................................................................ 12
6.4.
エラー時の救済方法............................................................................................... 13
6.5.
ＡＰＩの状態遷移図と状態遷移表 ......................................................................... 14
7.
日レセとアプリケーションの機能分化 ......................................................................... 16
8.
運用手順 ........................................................................................................................ 19
8.1.
受付 API................................................................................................................. 20
8.2.
患者登録 API ......................................................................................................... 21
8.3.
予約 API................................................................................................................. 28
8.4.
診療行為 API ......................................................................................................... 29
8.5.
病名 API................................................................................................................. 32
8.6.
オフライン処理を行う API ................................................................................... 34
インターネットを介する場合のセキュリティ .............................................................. 37
9.
10.
API の詳細仕様 ......................................................................................................... 38
10.1.
API の一覧 ......................................................................................................... 38
10.2.
API のメッセージ（呼出、引数、戻り値） ...................................................... 38
11.
データ定義 ................................................................................................................. 38
1.
概要
本書は、日本医師会の「ORCA プロジェクト」において開発された「日医標準レセ
プトソフト（以下、
“日レセ”という）」に、HTTP プロトコルでアクセスできる API
（Application Programing Interface）を定義する仕様書である。
本仕様書は、日レセとの間で各種データ連携を行う電子カルテ等の外部システムを対
象とし、そのインタフェースを定義するものである。
2.
目的
日レセと電子カルテ等の連携システムとのデータ連携に関する仕様を明確に定義す
ることで、電子カルテ等の連携システムから日レセの各種機能を共通の手順で利用可
能とすることを目的とする。
本書で定義する API（HAORI）はすでに公開されている機能を包含しつつ、不足し
ている機能を追加したものであるが、そのためにメッセージ構文に一貫性が保たれて
いないところがある。今後、API（HAORI）の機能改善を継続していくなかでメッセ
ージ構文の統一を進めることになるであろうし、そのためには新旧のメッセージが混
在する時期を避けることはできないであろう。しかし、将来的にはメッセージ構文が
統一されたものに統合されることになるので、利用者においては仕様の変更があり得
ることを認識していただく必要がある。
3.
3.1.
構成
API（HAORI）が適用されるハードウェア構成
本仕様書で定義する API（HAORI）を利用するシステムは、日レセサーバが動作し
ているコンピュータ上、または日レセサーバが動作しているコンピュータとネットワ
ークで接続され日レセサーバとの HTTP 通信が可能なコンピュータ上で動作するもの
を想定している。
ハードウェア（ネットワーク）構成としては、以下の 3 つの形態が考えられる。
（１）日レセサーバが動作しているコンピュータ上での利用
電
子
カ
ル
テ
等
API
日
レ
セ
サ
ー
バ
日レセサーバが動作しているコンピュータ
API（HAORI）を利用するシステムが、日レセサーバと同じコンピュータ上で
1
運用される形態である。
（２）日レセサーバが動作しているコンピュータと LAN で接続されているコンピュ
ータからの利用
日レセサーバが動作しているコンピュータ
APIを利用するコンピュータ
電
子
カ
ル
テ
等
API
日
レ
セ
サ
ー
バ
API（HAORI）を利用するシステムが、LAN を介して日レセサーバにアクセ
スを行う形態である。
glclient2／monsiaj から日レセを使用する場合と同様に、LAN 上にリクエスト
／レスポンスのデータが流れることになるので、LAN の規模や求められるセキ
ュリティレベルによっては、glclient2／monsiaj～glserver の通信と同様に
「SSL による通信の暗号化」が必要になると考えられる。
2
（３）日レセサーバが動作しているコンピュータへインターネットを経由して接続す
るコンピュータからの利用
インターネット
VPN(IPSec)
APIを利用するコンピュータ
日レセサーバが動作しているコンピュータ
VPN(IPSec)
電
子
カ
ル
テ
等
API
日
レ
セ
サ
ー
バ
API（HAORI）を利用するシステムがインターネットを介して日レセサーバ
へアクセスを行う形態である。
比較的その通信路が長く、その際に経由する機器や回線の構成も複雑になり、
遅延等の影響でリクエスト／レスポンスの送受信の所要時間が変動する可能性
がある。利用するシステムはこの点を考慮した設計を行う必要がある。
また、インターネットを経由して API（HAORI）を利用する場合には、リクエ
スト／レスポンスに含まれる個人情報を守るため、何らかの方法により VPN
を構築し、通信路を暗号化する必要がある。
3
3.2.
API（HAORI）のソフトウェア構成
電子カルテ等
CLAIM利用システム
電子カルテ等
API利用システム
glclient2/monsiaj
接続毎に
プロセス作成
CLAIM
通信
HTTP/1.1
glserver
glserver
glserver
glserver
API I/F
ユーザ
認証
ソケット通信
glauth
ユーザ
認証
wfc　｝
“業務”
単位に
存在
受信プログラム
ruby
バッチ系
ruby／bash
マルチスレッド　wfc
wfc
wfc
・・・・・
aps
API専用の
wfc・aps
aps
aps
dbs
= HAKAMA
dbstub
PostgreSQL
dbredirector
API（HAORI）を含む日レセサーバソフトウェアの構成を上図に示す。
API（HAORI）のリクエストは、glclient2/monsiaj からの接続時と同様に、glserver
が受け付ける。glserver は受信したパケットの種別を判断し、HTTP の POST／GET
であった場合に API（HAORI）のリクエストであると認識する。
glserver は、API（HAORI）のリクエストを解釈し、そのリクエスト内容に応じて
適切な wfc プロセスへリクエストを渡す。wfc は日レセの“業務”単位に存在していて、
この“業務”単位で処理を行うべき API（HAORI）については、その“業務”を担当
する wfc にリクエストが渡されるが、その他の API
（HAORI）
については、
API（HAORI）
専用の wfc にリクエストが渡される。
また、
レスポンスについては、
リクエストと逆の流れで電子カルテ等の API（HAORI）
利用システムに処理結果が渡される。
4
4.
動作条件
API（HAORI）を利用するにあたって、電子カルテ等の利用システムに必要な条件
は以下の通りである。
ハードウェア
TCP/IP 通信可能なインタフェースを備えていること
OS
TCP/IP 通信のプロトコルスタックを備えていること
またその上で HTTP/1.1 プロトコルによる通信が行えること
5.
プロトコル階層
APIを利用する
アプリケーション
（電子カルテ等）
HTTP/1.1
TCP
IP
日レセサーバ
API（ポート8000）
ネットワークインタフェース
wfc
glserver
TCP
IP
ネットワークインタフェース
API（HAORI）を利用する電子カルテ等のシステムから日レセサーバへ API
（HAORI）によるアクセスを行う際に、利用されるプロトコル階層について上図に示
す。API（HAORI）を利用する電子カルテ等のシステムは、HTTP/1.1 プロトコルを
用い、日レセサーバの“glserver”へポート 8000 を使用した TCP/IP 通信でリクエス
トを送信する。また、この時確立したセッションを使用して、日レセサーバから API
（HAORI）を利用する電子カルテ等のシステムへレスポンスが送信される。WEB サ
ーバで使われるポート 80 とは異なるので、同じ HTTP プロトコルではあるが WEB サ
ーバとの同居は可能である。
5
6.
通信手順
API（HAORI）を利用する電子カルテ等のシステムから日レセサーバへ API（HAORI）
によるアクセスを行う際の通信手順について、以下に説明する。
なお、API（HAORI）のリクエストを受け付ける glserver は、接続を受ける毎に自
プロセスの複製を作成しそのプロセス内で以降の処理を行うため、同時に複数の API
（HAORI）のリクエストを受け付けることが可能である。
6.1.
基本通信手順
API（HAORI）には、HTTP の GET メソッドで通信を行うタイプと POST メソッ
ドで通信を行うタイプとが存在する。
GET メソッドで通信を行う API（HAORI）は、API（HAORI）呼び出し時の URL
にパラメータ（項目名=値）を付加してアクセスを行うことで、レスポンスとして応答
XML を返却する。
Ａ
Ｐ
Ｉ
（
電を
子利
カ用
ルす
テる
等シ
）ス
テ
ム
リクエスト（URL+”?”+項目名+”=”+値）
日
レ
セ
サ
ー
バ
レスポンス（応答XML）
また、POST メソッドで通信を行う API（HAORI）は、API（HAORI）呼び出し時
の URL に対して要求 XML を POST することで、レスポンスとして応答 XML を返却
する。
6
Ａ
Ｐ
Ｉ
（
電を
子利
カ用
ルす
テる
等シ
）ス
テ
ム
リクエスト（URLに要求XMLをPOST）
日
レ
セ
サ
ー
バ
レスポンス（応答XML）
また、API（HAORI）を利用するシステム側で、日レセサーバから直接接続できるイン
タフェースが用意できる環境（同一 LAN 環境、VPN で接続された環境、インターネット
から接続可能なグローバル IP の環境、等）においては、PUSH 型（便宜上 PUSH 型と記
述する）で通知を受けることが可能である。あらかじめ通知を受け取る URL 等を登録して
おくことで、日レセサーバが対象となる情報を更新したときにリクエストメッセージを送
信する動作となる。
Ａ
Ｐ
Ｉ
（
電を
子利
カ用
ルす
テる
等シ
）ス
テ
ム
リクエスト（URLに要求XMLをPOST）
レスポンス（応答メッセージ）
リクエスト（事前登録のURLに要求XMLをPOST）
レスポンス（応答メッセージ）
7
日
レ
セ
サ
ー
バ
6.2.
エラー処理の考え方
API（HAORI）を利用する電子カルテ等のアプリケーションにおいては、API
（HAORI）を利用する場合に発生する可能性のあるエラーに対して、処理を行う必
要がある。発生する可能性のあるエラーは以下の通りである。
（１） API（HAORI）処理が正常に行われた結果、レスポンスとしてエラー情報が返
却された
例えば、情報を取得する API（HAORI）において、指定した情報が存在して
いない場合等に発生することが考えられる。
API（HAORI）
の正常な動作の結果として返されたエラーであり、API（HAORI）
を利用する電子カルテ等のアプリケーション側ではこれに対する適切な処理を
行う必要がある。
Ａ
Ｐ
Ｉ
（
電を
子利
カ用
ルす
テる
等シ
）ス
テ
ム
リクエスト
日
レ
セ
サ
ー
バ
レスポンス（応答XMLにエラー情報）
（２） API（HAORI）処理中に日レセサーバ内で何らかのエラーが発生した
日レセサーバ内での API（HAORI）処理中に何らかの異常が発生した際に、
「HTTP STATUS 500」が返される場合がある。
API（HAORI）を利用する側としては、再度リクエストを送信し、同様のエ
ラーとなった場合には日レセサーバの動作状況または API（HAORI）側の不具
合を疑うべきである。
8
Ａ
Ｐ
Ｉ
（
電を
子利
カ用
ルす
テる
等シ
）ス
テ
ム
リクエスト
日
レ
セ
サ
ー
バ
HTTP STATUS 500
内部
エラー
（３） API（HAORI）リクエスト送信が終わらない
API（HAORI）リクエスト電文がネットワーク上を複数のパケットに分割して
送信されると、すべてのパケットが到達しない場合がある。通信上の問題で、
API（HAORI）リクエストの送信が完了できない場合である。一定時間内に利
用側からのリクエスト送信、つまり日レセサーバ側でのリクエスト受信が完了
できない場合には受信処理がリセットされるので、再度 API（HAORI）リクエ
ストの送信を行う必要がある。
Ａ
Ｐ
Ｉ
（
電を
子利
カ用
ルす
テる
等シ
）ス
テ
ム
リクエスト
日
レ
セ
サ
ー
バ
（４） API（HAORI）リクエストを送信後、一定時間が経過しても API（HAORI）
からのレスポンスがない
以下の 3 通りの場合が考えられるが、いずれの場合においても、
API（HAORI）
利用側では「レスポンスが返ってこない」という認識となる。
レスポンスが返ってこないため、API 利用側では、実際に処理が行われたか
否かについても、処理が行われた場合の結果についても知ることができないの
で、タイムアウト等で API（HAORI）リクエストを中止し、再度同じ内容での
9
API（HAORI）リクエストを行う必要がある。
その場合、特に登録系の API（HAORI）の場合に、状況によっては、登録済
みの情報に対して再度同じ内容を登録しようとすることがあり得るので、二重
登録を防止すると同時に、同じ内容のリクエストに対して「既に処理済み」で
あることを示すレスポンスを確実に返す必要がある。
これを実現するために、API（HAORI）利用側がリクエストを送信する際に、
そのリクエストを一意に特定できるような UID（Uniq ID）を含んでおき、こ
の UID を用いて日レセサーバ側で受付済みのリクエストであるか等を判断で
きるようにする。
1) 利用側は API（HAORI）リクエストの送信が完了したと認識しているが、日
レセサーバにはリクエストが届いていない
Ａ
Ｐ
Ｉ
（
電を
子利
カ用
ルす
テる
等シ
）ス
テ
ム
リクエスト(UID)
リクエスト(UID)※再送
日
レ
New! セ
サ
ー
バ
レスポンス
この場合、API（HAORI）利用側は一定時間内にレスポンスを受け取れない
ので、再度リクエストを送信することになる。再送により、日レセサーバにリ
クエストが届けば、日レセサーバで新しい UID が付加されたリクエストを受信
した、と認識できるので、処理を正常に行うことが可能となる。
2) API（HAORI）リクエストは日レセサーバに届いたが、正常に処理が行われな
かったため、利用側にレスポンスがない（日レセサーバ内部での処理で異常が
発生し、レスポンスが返せない状態）
10
Ａ
Ｐ
Ｉ
（
電を
子利
カ用
ルす
テる
等シ
）ス
テ
ム
リクエスト(UID)
リクエスト(UID)※再送
内部
エラー
日
レ
Retry? セ
サ
ー
バ
レスポンス
この場合も、API（HAORI）利用側は一定時間内にレスポンスを受け取れな
いので、再度リクエストを送信することになる。日レセサーバ側は、既に受付
済みの UID が付加されたリクエストを受信したので再送されたリクエストで
あること認識できるが、初回受信時にレスポンスを返せていないので再度処理
を行う。処理が正常に行えれば、レスポンスを返す。
3) API（HAORI）リクエストは日レセサーバに届き、正常に処理が行われたが、
レスポンスが呼び出し元に届かない（通信上の問題）
Ａ
Ｐ
Ｉ
（
電を
子利
カ用
ルす
テる
等シ
）ス
テ
ム
リクエスト(UID)
レスポンス（応答XML）
リクエスト(UID)※再送
日
レ
セ
サ
ー
Retry? バ
レスポンス（処理済み）
この場合も、API（HAORI）利用側は一定時間内にレスポンスを受け取れな
いので、再度リクエストを送信することになる。日レセサーバ側は、既に受付
済みの UID が付加されたリクエストを受信したので再送されたリクエストで
あり、既にレスポンスを返却済みであることを認識できるので、処理結果とと
もに処理済みであることを示すレスポンスを返す。
11
6.3.
情報更新の排他制御の考え方
API（HAORI）を使って ORCA の情報を更新する場合には、glclient や他アプリケーシ
ョンの API リクエストと競合する場面が考えられるので、同一患者に対する更新が重複し
ないように、現状のオンライン業務における排他制御と同等の制御を行う必要がある。
現在の日レセオンライン業務では、glclient の起動から終了まで（glserver と接続してか
ら切断するまで）が同一セションで動作しているため、端末 ID をキーとして排他制御をお
こなっている。例えば、「21 診療行為」では、画面から「患者番号」を入力した時点で、
端末 ID をキーとしてこの患者に対する排他情報を書き込み、別のクライアントでの同一患
者の操作を行えないように制御していて、この制御は、「21 診療行為」でこの患者の「患
者取り消し」又は「請求処理」が完了するまで継続している。
これに対し API（HAORI）においても、複数の API（HAORI）を実行しないと完結で
きない処理を行う場合には、同等の排他制御をおこなう必要があるが、1 つの API（HAORI）
の実行毎に接続／切断をおこなう（＝毎回セッションが異なる）ため、glclient の場合のよ
うに、端末 ID を利用することはできない。
そこで、この端末 ID の代わりに日レセサーバ側で UID（Uniq ID）を発行し、これをキー
として排他制御を実現する。複数の API（HAORI）を実行して一連の処理を行う必要があ
る場合、最初の API（HAORI）のレスポンスに日レセサーバが発行した UID を付加してお
き、API（HAORI）利用側は以降のリクエストにこの UID を付加しておく。これにより、
日レセサーバ側では、この UID を持つリクエストでのみ当該患者情報の更新を行い、UID を
持たないリクエストでの当該患者情報の更新処理は行わない、という排他制御を実現する
ことが可能となる。
この排他情報は、一連の処理が完結した時点で日レセサーバ側で解放する。また、一連
の処理を途中でキャンセルできるように、排他制御情報の削除を行うＡＰＩを提供する。
12
6.4.
エラー時の救済方法
API（HAORI）を経由した通信のなかでは、通信上のエラーが発生したとしても API
（HAORI）内部での再送信などの処理は行われないので、連携アプリケーションでの救済
方法について記述する。誤解のないように付け加えると API（HAORI）の通信では TCP/IP
プロトコルを採用しているので、TCP/IP での再送処理が行われている。
（１） API（HAORI）メッセージの再送による救済は注意すべき
一次的な障害により連携アプリケーションからのリクエストメッセージに対す
る日レセからのレスポンスメッセージが受信できなかったときは、リクエスト
メッセージが正常に完了しなかったと判断して、新たな UID を付加してリクエ
ストメッセージを送信すべきである。
たとえば、排他制御が必要な一連の処理では、異常終了した UID でキャンセル
メッセージを発行して、新たな UID で一連の処理を再開するべきである。
ただし、リクエストメッセージが日レセで正常に処理されている場合があるの
で、再送信をする前に中途終了データから当該データを削除するとか、データ
ベースに同一のデータが登録されていないか確認すべきである。
（２）連携アプリケーションからの履歴データの再送信による救済
障害により日レセからのレスポンスメッセージが受信できなかったときには、
障害が回復したあとに連携アプリケーションから履歴データが送信できるよう
にすべきである。
もし、障害が発生する直前のリクエストメッセージが日レセで正常に受信され
ており中途終了データに蓄積されているときは、履歴データの送信の前に中途
終了データを削除すべきである。また、障害の発生する直前にデータベースに
登録するリクエストメッセージが送信されているときは、当該データが日レセ
のデータベースに蓄積されていないか確認してから履歴データを送信すべきで
ある。
（３）日レセでの手動入力による救済
障害が復旧せず連携アプリケーションからのメッセージが日レセに送信できな
いときは日レセのＧＵＩでデータを登録することも考慮すべきである。
13
6.5.
API（HAORI）の状態遷移図と状態遷移表
日レセサーバで動作する API（HAORI）の処理プロセスの動作を下図に示す。
サーバ側では API（HAORI）メッセージを受信すると親プロセスが子プロセスを生成し
てメッセージの処理を開始する。メッセージが正常に受信されると日レセサーバ本体に処
理を依頼し、結果を受け取ると API（HAORI）の呼出し元に応答メッセージを返送する流
れとなる。
glserver（親プロセス）
初期状態
接続待ち
子プロセスの生成
終了処理
glserver（子プロセス）
/ タイマ起動
/ 受信完了／タイマ停止
初期状態
受信中
要求処理状態
/ タイムアウト／通信エラー　① / 応答送信／タイマー起動　②
終了処理
①　HTTPセッションの切断により状態は遷移する
②　HTTPのセッションが切れるまで受信処理を繰り返す
③　HTTPの送信処理の失敗の場合に遷移する
14
/ 送信失敗　③
/ 応答作成
応答送信中
Glserver
親プロセスの状態遷移表
状態
イベント
S0
S1
S2
S3
初期状態
接続待ち
子プロセスの生成
終了処理
ポート開放要求
0
ポート開放要求
／
→
／
／
／
／
S1：接続待ち
×
／
／
S1：接続待ち
1
接続要求
／
2
生成完了
×
3
終了要求
／
→
S2：子プロセスの生成
×
→
→
S3：終了処理
／：処理無し（無視）
×：イベントが入ることがないため不可
Glserver
子プロセスの状態遷移表
状態
イベント
S0
S1
S2
S3
S4
初期状態
受信中
要求処理状態
応答送信中
終了処理
×
×
×
×
×
×
×
×
×
×
×
×
×
×
タイマ起動
0
受信開始
×
→
S1：受信中
タイマ停止
1
受信完了
×
→
S2：要求処理状態
タイマ停止
2
タイムアウト
×
→
3
5
6
データ異常
（受信）
処理完了
応答送信
（成功）
S4：終了処理
タイマ停止
×
→
S4：終了処理
×
×
×
×
→
S3：応答送信中
タイマ起動
×
7 応答受信（失敗）
×
×
×
8
×
×
×
応答送信完了
15
×
→
S1：受信中
→
S5：終了処理
×
×
→S0：初期状態
日レセとアプリケーションの機能分化
7.
日レセ API（HAORI）を検討するにあたり、日レセに求められる機能と連携する各アプ
リケーションの機能分担を整理することにする。日レセ API（HAORI）は、日レセのクラ
ウド化やエンジン化を想定していることから医事会計機能に重点を絞って設計するべきと
考えた。日レセにはレセコンとしての機能を多く含んでいるが、それは、電子カルテなど
のアプリケーションが充実していない時代に求められた機能であり、世の中にはいろいろ
なアプリケーションが存在することから、これらのアプリケーションを有効に利用するこ
とは医療機関のＩＴ化にも繋がり、結果としては患者へのサービス提供にも繋がると考え
る。
したがって、この章ではレセコンに必須である機能と市場にあるアプリケーションで代
替えできる機能に分けて将来のシステムイメージを示すこととする。ただし、日レセにユ
ーザインタフェースが無くなることと示しているのではなく、日レセが単体でレセコンと
して機能することは当然であり、その機能は継承されていくことを前提としている。
ＯＲＣＡ
(1)　受付
(2)　登録
(3)　照会
(4)　予約
(5)　診療行為
(6)　病名
(7)　収納
(8)　会計照会
(9)　データチェック
(10)　明細書
(11)　請求管理
(12)　総括表・公費請求書
(13)　日次統計
(14)　月次統計
(15)　マスタ登録
(16)　マスタ更新
(17)　プログラム更新
電子カルテ
(1)　カルテ入力
図７－１既存のＯＲＣＡの機能
予約システム
(1)　予約
(2)　受付
ＰＯＳレジ
ＯＲＣＡ
電子カルテ
(1)　収納（現金管理）
(2)　領収書発行
(3)　診療明細書発行
(1)　登録
(2)　診療行為
(3)　病名
(6)　収納（再計算）
(7)　会計照会（保険変更等）
(8)　明細書
(9)　請求管理
(10)　総括表・公費請求書
(11)　日次統計（データ出力）
(12)　月次統計（データ出力）
(1)　患者呼出し
(2)　患者情報入力
(3)　カルテ入力
(4)　会計情報変更（カルテ変更）
(5)　禁忌薬剤チェック
(6)　明細書作成
(7)　請求管理
(8)　総括表・公費請求書作成
レセプトチェックシステム
(1)　データチェック
統計処理システム
(1)　日次統計（処理）
(2)　月次統計（処理）
(13)　マスタ登録
(14)　マスタ更新
(15)　プログラム更新
図７－２各アプリケーションとの機能分化（例）
また、日レセが医事会計エンジンと化すことによってさまざまのシステム構成を考える
16
ことができる。電子カルテにおいて医事会計エンジンに会計処理を依頼し結果を表示する
連携を実現したとき、電子カルテには医事会計に必要な情報を設定し結果を表示するとい
う機能が必要となることから診療報酬改定によって生じる会計処理の変更に追従しなけれ
ばならないという課題が生じる。本来であれば医事会計のエンジン化によって診療報酬改
定に影響を受けないようにシステムを構築することが望まれるが、医事会計処理のユーザ
インタフェースを電子カルテ側に実装する場合には診療報酬改定の影響を少なからず受け
る結果となる。そこで、ユーザインタフェースをＷＥＢアプリ側で実装し、会計処理を日
レセに任せ、その結果を電子カルテ等のアプリケーションが組み込み型ブラウザで実装す
る方式を提案する。
ＡＰＩ（HAORI）
WEBアプリケーション
日レセサーバが動作しているコンピュータ
ＡＰＩ（HAORI）
HTTP
電子カルテ等
電子カルテ
病歴
カルテ
既往歴・主訴・所見
処置・処方・手術等
狭心症
アダラートＣＲ錠20mg
1日1回　医師の指示通りに
2014.7.1
1錠
5日分
日レセサーバに送る情報
日レセサーバに送る情報
組み込みブラウザで結果を表示する
日レセ（会計確認）
再診
時間外対応加算
明細書発行体制等加算
76
---------------------------------------------外来管理加算
52
---------------------------------------------特定疾患療養管理料（診療所）
225
---------------------------------------------内服薬
【先】アダラートＣＲ錠20mg
1錠
【1日1回　医師の指示通りに】
5日分
---------------------------------------------処方せん料
68
---------------------------------------------特定疾患処方管理料（処方せん料）
18
----------------------------------------------
図７－３組み込みブラウザで日レセの画面を表示する電子カルテの画面例
17
図７－３の方式では、
医事会計処理に必要な病名や診療行為情報は日レセ API（HAORI）
で日レセに送信し、会計結果をブラウザで表示する流れとなる。この方式では診療報酬改
定に左右されるユーザインタフェースをＷＥＢサーバで吸収し、各アプリケーションが利
用できる仕組みとしている。この方式の利点としては、
(1) 各アプリケーションがブラウザ機能を持つことでサービスを利用できる
(2) ＷＥＢアプリケーションの機能を利用できるので拡張性に優れている
(3) ＷＥＢアプリケーションとしてのカスタマイズが容易にできる
がある。
18
8.
運用手順
以下に、API（HAORI）を使用して日レセ画面での操作に相当するような処理を行う際
の、具体的なフロー（API（HAORI）の仕様順序）を示す。
なお、以下のフローにおいて、
患者登録
(class=1)
は個々の API（HAORI）の処理（リクエスト～レスポンスの一連の処理）を表す。
また、個々の API（HAORI）においてエラーが発生した場合は、実際には
新規患者登録
患者登録
(class=1)
Yes
登録内容の修正
エラー
No
のような処理を行う必要があるが、以下のフローにおいては、エラー判定および修正処理
（上図の黄色枠内）は、特筆すべきものを除いて割愛する。
19
8.1.
受付 API
（１） API（HAORI）による患者受付登録のフロー
API（HAORI）を用いて患者受付登録を行う場合は、以下の流れで処理を行う必要が
ある。
1.
日レセの最新情報を取得するため、登録・変更目的で患者情報取得 API を呼び出
す。
2.
取得した最新情報を用いて、受付登録 API で受付処理を行う。
API（HAORI）を用いて患者受付登録を行う場合のフローを以下に示す。
なお、フローの途中で中断したい場合は、処理取消 API を呼び出す。
受付登録
患者情報取得
（Request_Number = 02）
患者単位で
排他制御
YES
中断する？
NO
受付登録
処理取消
終了
20
8.2.
患者登録 API
（１） API（HAORI）による新規患者登録のフロー
新規患者登録
患者登録
(class=1)
21
（２） API（HAORI）による患者基本情報変更のフロー
API（HAORI）を用いて患者基本情報変更を行う場合は、以下の流れで処理を行う
必要がある。
1.
日レセの最新情報を取得するため、登録・変更目的で患者情報取得 API を呼び
出す。
2.
取得した最新情報をもとに、患者登録 API で変更した患者情報を登録する。
患者情報を更新する際、生年月日を変更した場合に、保険公費登録の変更が必要
な場合や、過去の診療行為・会計に影響が出る可能性がある。必要に応じて、保険
公費の追加登録や変更を行い、会計に影響がある場合には、会計照会（保険一括変
更）と収納情報（更新）を実行して、患者登録情報と収納情報とを一致させておく
必要がある。
API（HAORI）を用いて患者基本情報の変更を行う場合のフローを以下に示す。
なお、フローの途中で中断したい場合は、処理取消 API を呼び出す。
22
患者情報更新
患者情報取得
（Request_Number = 02）
患者情報の変更
患者単位で
排他制御
患者登録
(class=2)
変更しても良いか？
No
Yes
患者登録
(class=2)
保険・公費登録の変更の
必要あり？
処理取消
No
Yes
保険公費登録変更
No
過去の診療行為・会計に
影響あり？
Yes
保険組合せ情報取得
会計照会
（保険一括変更）
収納情報
（更新）
23
（３） API（HAORI）による患者保険公費情報の更新（追加・変更・削除）のフロー
API（HAORI）を用いて患者保険公費情報の更新を行う場合は、以下の流れで処
理を行う必要がある。
1.
日レセの最新情報を取得するため、登録・変更目的で患者情報取得 API を呼び
出す。
2.
取得した最新情報をもとに、保険公費登録変更 API で変更した保険公費情報を
登録する。
患者保険公費情報を更新する場合に、過去の診療行為・会計に影響が出る可能性
がある。影響がある場合には、会計照会（保険一括変更）と収納情報（更新）を実
行して、患者登録情報と収納情報とを一致させておく必要がある。
API（HAORI）を用いて患者保険公費情報の更新を行う場合のフローを以下に示
す。
なお、フローの途中で中断したい場合は、処理取消 API を呼び出す。
24
保険公費情報更新
（追加、変更、削除）
患者情報取得
（Request_Number = 02）
患者保険公費情報の変更
患者単位で
排他制御
保険公費登録変更
変更しても良いか？
No
Yes
保険公費登録変更
処理取消
No
過去の診療行為・会計に
影響あり？
Yes
保険組合せ情報取得
会計照会
（保険一括変更）
収納情報
（更新）
25
（４） API（HAORI）による患者労災保険・自賠責保険情報の更新（追加・変更・削除）
のフロー
API（HAORI）を用いて患者労災保険・自賠責保険情報の更新を行う場合は、以
下の流れで処理を行う必要がある。
1.
日レセの最新情報を取得するため、登録・変更目的で患者情報取得 API を呼び
出す。
2.
取得した最新情報をもとに、患者労災自賠登録変更 API で変更した労災保険・
自賠責保険情報を登録する。
患者労災保険・自賠責保険情報を更新する場合に、過去の診療行為・会計に影響
が出る可能性がある。影響がある場合には、会計照会（保険一括変更）と収納情報
（更新）を実行して、患者登録情報と収納情報とを一致させておく必要がある。
API（HAORI）を用いて患者労災保険・自賠責保険情報の更新を行う場合のフロ
ーを以下に示す。
なお、フローの途中で中断したい場合は、処理取消 API を呼び出す。
26
労災・自賠責情報更新
（追加、変更、削除）
患者情報取得
（Request_Number = 02）
患者労災・自賠責情報の変更
患者単位で
排他制御
労災・自賠責登録変更
変更しても良いか？
No
Yes
処理取消
労災・自賠責登録変更
No
過去の診療行為・会計に
影響あり？
Yes
保険組合せ情報取得
会計照会
（保険一括変更）
収納情報
（更新）
27
8.3.
予約 API
（１） API（HAORI）による患者予約登録のフロー
API（HAORI）を用いて患者予約登録を行う場合は、以下の流れで処理を行う必要
がある。
1.
日レセの最新情報を取得するため、登録・変更目的で患者情報取得 API を呼び
出す。
2.
取得した最新情報を用いて、予約登録 API で受付処理を行う。
API（HAORI）を用いて患者予約登録を行う場合のフローを以下に示す。
なお、フローの途中で中断したい場合は、処理取消 API を呼び出す。
予約登録
患者情報取得
（Request_Number = 02）
患者単位で
排他制御
YES
中断する？
NO
予約登録
処理取消
終了
28
8.4.
診療行為 API
（１） API（HAORI）による診療行為登録（中途を使用する場合）のフロー
中途データのチェックの結果エラーがあり、診療行為の修正を行う場合には、い
ったん処理取消 API によってデータチェックをキャンセル（＝中途データ展開中の
状態をキャンセル）してから中途データの変更を行う必要がある。
API（HAORI）を用いて中途を使用した診療行為登録を行う場合のフローを以下
に示す。
なお、フローの途中で中断したい場合は、処理取消 API を呼び出す。
診療行為登録
（中途を使用する場合）
診療行為（中途終了データ）
(登録(class=1))
１
中途終了からの
展開とチェック
診療行為（中途終了データ）
(変更(class=3))
処理取消
診療行為
（中途データ診療行為チェック要求）
Yes
エラー？
１
２
中途終了
テーブル
他システム等から
登録された
同患者、同日の
診療行為
診療行為
（診療行為選択）
Yes
選択項目あり？
診療行為
（請求確認）
診療行為
（登録依頼）
29
患者単位で
排他制御
選択項目が
なくなるまで
繰り返す
（２） API（HAORI）による診療行為登録（中途を使用しない場合）のフロー
中途終了を使用しないで診療行為登録を行う場合には、まず今回の診療で算定し
たい初再診等の診察料を指定してそれが妥当であるかのチェックを行う。結果、初
診料の算定がないために再診料を算定できない場合には、算定履歴登録の API で初
診歴を算定後、再度チェックを実行する必要がある。
API（HAORI）を用いて中途を使用しない診療行為登録を行う場合のフローを以
下に示す。
なお、フローの途中で中断したい場合は、処理取消 API を呼び出す。
30
診療行為登録
（中途を使用しない場合）
診療行為
（算定履歴登録）
診療行為
（診察料返却）
Yes
再診が算定できない？
診療行為
（診療行為チェック要求）
Yes
患者単位で
排他制御
診療行為
（診療行為選択）
選択項目が
なくなるまで
繰り返す
選択項目あり？
診療行為
（請求確認）
診療行為
（登録依頼）
（３） API（HAORI）による登録済み診療行為の訂正のフロー
既に日レセに登録済み（会計確定済み）の診療行為の訂正を行う場合には、外来
の場合には伝票番号、入院の場合には診療日を指定して登録済み診療行為の取得を
行い、これに対して、追加・変更等必要な処理を行った後に、診療行為のチェック
を依頼する。これ以降の診療行為登録（中途を使わない場合）の処理と同等で行う。
API（HAORI）を用いて登録済み診療行為の訂正を行う場合のフローを以下に示
す。
なお、フローの途中で中断したい場合は、処理取消 API を呼び出す。
31
診療行為訂正
診療行為
（診療行為取得）
診療行為の追加・修正
診療行為
（診療行為チェック要求）
診療行為
（診療行為選択）
Yes
患者単位で
排他制御
選択項目が
なくなるまで
繰り返す
選択項目あり？
診療行為
（請求確認）
診療行為
（登録依頼）
8.5.
病名 API
（１） API（HAORI）による患者病名登録のフロー
API（HAORI）を用いて患者病名登録を行う場合は、以下の流れで処理を行う必要
がある。
1. 日レセの最新情報を取得するため、登録・変更目的で病名（取得）API を呼び
出す。
2. 取得した最新情報を用いて、病名（登録変更）API で病名登録処理を行う。な
お、複数の病名に対して処理を行うために病名（登録変更）API を複数回呼び
32
出してもよい。
API（HAORI）を用いて患者予約登録を行う場合のフローを以下に示す。
なお、フローの途中で中断したい場合は、処理取消 API を呼び出す。
病名の登録・更新
病名（取得）
（Request_Number = 02）
患者単位で
排他制御
YES
中断する？
NO
病名（登録変更）
処理取消
終了
33
8.6.
オフライン処理を行う API（HAORI）
日レセには、患者登録や診療行為登録などのオンライン業務とは別に、明細書作成、総
括処理、データチェック、日次／月次統計などの、処理を開始してからその結果が得られ
るまでに比較的長い時間が必要なオフライン処理が存在する。
これらの機能を API（HAORI）で実現することを考えた場合、単体の API（HAORI）
で、処理を開始してから処理が終了して結果を得られるまでその接続を維持することは、
日レセサーバ側の負荷の面からも現実的ではないと考えられるため、以下の 3 種類の API
（HAORI）を用意する。
(１) 処理を開始する API（HAORI）
オフライン処理が正常に開始できたら、処理 ID を含んだレスポンスを返却する。
(２) 処理の進捗状況を確認する API（HAORI）
（１）と同じ API（HAORI）で実行中／正常終了／異常終了の状態を確認する。
(３) 処理結果取得 API（HAORI）
処理結果として作成されるデータ（CSV ファイル、PDF ファイル等）を、処理 UID
を指定して取得する。
以下のフローは明細書作成の例である。
34
明細書作成
明細書作成
（Request_Number=1）
正常に開始した？
No
Yes
定期的に
繰り返す
処理状況の
確認
明細書作成
（Request_Number=3）
No
処理終了？
Yes
No
正常終了？
Yes
処理結果取得API
また、API（HAORI）を利用するシステム側で、日レセサーバから直接接続できるイン
タフェースが用意できる環境（同一 LAN 環境、VPN で接続された環境、インターネット
から接続可能なグローバル IP の環境、等）においては、処理の終了を PUSH 型通知で受
け取ることも可能である。
35
明細書作成
明細書作成
（Request_Number=1）
PUSH通知
（処理終了）
正常に開始した？
No
Yes
処理状況の確認
（終了ステータスの取得）
明細書作成
（Request_Number=3）
Yes
No
正常終了？
Yes
処理結果取得API
36
9.
インターネットを介する場合のセキュリティ
電子カルテ等のアプリケーションが、インターネットを経由したネットワークに存
在する日レセサーバの API（HAORI）を利用する場合には、API（HAORI）のリク
エスト／レスポンスに含まれる個人情報を保護するため、何らかの方法により VPN
を構築し通信路を暗号化する必要がある。
VPN を構築する場合、代表的な方法として、IPSec を利用する方式と SSL を利用
する方式とがあるが、インターネットを介して日レセ API（HAORI）を利用する場
合は、
「医療情報システムの安全管理に関するガイドライン」に則り IPSec に IKE の
暗号鍵交換手順を組み合わせた VPN を構築することを推奨する。
なお、SSL-VPN に関しては「医療情報システムの安全管理に関するガイドライン」
にも記述がある通り、その暗号化の仕組みから「経路を暗号化する過程で盗聴され、
適切でない経路を構築されるリスクが内在する」ことからも、インターネットを介し
た日レセ API（HAORI）の利用においては十分に注意が必要である。
37
10. API（HAORI）の詳細仕様
10.1. API（HAORI）の一覧
下記の表を参照して下さい。
表 10-1 日レセ画面と既存 API
表 10-2 日レセ API（HAORI）一覧
10.2. API のメッセージ（呼出、引数、戻り値）
メッセージ詳細は、
「日レセ API（HAORI）メッセージ詳細」を参照して下さい。
11. データ定義
日レセ API（HAORI）新タグ名一覧を参照してください。
38

Download Report