PrimeKarte > PkShochi
概要 †
守衛さんが応急処置で使った薬剤から、テレビの使用料、書類の手数料などなど、
なんでもオーダ的な存在の処置オーダ。
静岡市立固有機能 †
- リテラ
- 概要
前日〜当日の手術で使用された薬品や材料などをオーダに取り込む。
リテラカートと呼ばれるものから払い出された薬品等の情報が、
LITERA/OPE_YAKUHIN/OPE_ZAIRYO テーブルに格納される(んだと思う)。
- GUI
- リテラ(ファンクション)メニューを選択
- 前日〜当日のリテラ情報を取得(LITERA.JISSHI_DATE)
- 前日〜当日分が無い場合は「リテラ情報はありません」と表示して終了。
- 前日〜当日分が取得できても、全て取り込み済みの場合は、
「リテラ情報は取得済みです」
とメッセージを表示して終了。
- 未取り込み分を入力画面に展開
- 取り込んだものの、OPE_YAKUHIN/OPE_ZAIRYO.CONDITION_FLG⇒2にUPDATE
※要CONDITION_FLGの定義変更、もしくは取り込み済みフラグのカラムの新設?
- 制限事項
- 行為情報が設定されていなければ、
「行為が設定されていない伝票にはこの操作はできません」
というメッセージを表示して、処理を中断。
- 問題点
- 現行は、ファンクションを押して画面に表示された時点で取り込んだフラグをONにしているため、
発行前にクリアすると、取り込む手段がなくなってしまう。
そのため、発行時に取り込み済みフラグを立てるのと、他の端末から同時に取り込まれない制御が必要。
- 未作成テーブル
LITERA
OPE_YAKUHIN
OPE_ZAIRYO
- SHOCHI_YAKUHIN_JISSHI / SHOCHI_ZAIRYO_JISSHI テーブル
- 概要
実施情報を物流に送信するために作成
- 対応
- 送信にしか使用していないため、廃止。コンバートの必要もなし。
- PrimeKarteでは、SHOCHI_YAKUHIN/ZAIRYO.STEP_FLG=1の行を利用する。
- PrimeKarteでの方針
- 基本的には同じとのこと。
- 問題点の解決
- OPE_YAKUHIN、OPE_ZAIRYOのCONDITION_FLGの更新は発行時に行う。
CONDITION_FLG=2?
その際に各アイテムを特定するためのOrderNo、Seq、RowNoを項目上に持つ。
※更新はOrderNo、Seq単位で行うべきか…?
- 取得時にはOrderJournal上をチェックし、発行前だけれど取得済みのものの再取り込みを防止する。
PrimeKarte版リテラ †
DoctorX版からの変更点 †
- テーブル名称
- リテラ情報取得関連
- OPE_YAKUHIUN、OPE_ZAIRYOのCONDITION_FLG更新
- OPE_YAKUHIN、OPE_ZAIRYOのCONDITION_FLGは発行時に更新する。
- PRO_POSTPROCESS_0061(オーダ発行後の処理)にて後述するORDER_JOURNAL上にかかれたリテラ情報を元にUPDATEする。
- CONDITION_FLG = 1
- 二重取り込み防止のチェック
- CONDITION_FLG=1のものは取り込み済み(発行済みのもの)
- 発行前のデータは取得したリテラ情報とORDER_JOURNAL上にかかれたリテラ情報を比べ、同じものがすでに展開されていないかをチェックする。
- リテラテーブル・ORDER_JOURNALカラム対応表
| リテラ情報 | ORDER_JOURNAL |
| ORDER_NO | STR_12 (LITERA_ORDER_NO) |
| SEQ | STR_13 (LITERA_SEQ) |
| ROW_NO | STR_14 (LITERA_ROW_NO) |
| 項目種別 (薬品=11、材料=12) | ITEM_KIND |
定義値 †
アイテム種別 †
| 値 | 意味 |
| 10 | 伝票 |
| 11 | 薬品 |
| 12 | 材料 |
| 13 | コメント |
| 14 | 加算 |
| 15 | 部位 |
マスタ †
一覧 †
| MASTER_CODE_STR | TABLE_NAME | 名称 | 備考 |
| 00610001 | ITEM_SHOCHI | 部位 | |
| 00610002 | ITEM_SHOCHI | コメント | |
| 00610003 | ITEM_SHOCHI | 加算 | |
| 00610004 | COMMON_SHOCHI | 医事診療 | 行為に対する医事診療区分コード |
| 00610005 | COMMON_SHOCHI | タイミング | |
| 00610006 | YAKUHIN | 薬品 | |
| 00610007 | SHUGI_SHOCHI | 手技行為 | 手技情報の行為 |
| 00610008 | SHUGI_SHOCHI | 手技コメント | 手技情報のコメント |
| 00610009 | SHUGI_SHOCHI | 手技薬品 | 手技情報の薬品 |
| 00610010 | SHUGI_SHOCHI | 手技材料 | 手技情報の材料 |
| 00610011 | SHUGI_SHOCHI | 手技加算 | 手技情報の加算 |
| 00610012 | SHUGI_SHOCHI | 手技部位 | 手技情報の部位 |
| 00610014 | MATRIX_SHOCHI | 場所種別手技マトリクス | 場所毎の展開するタブ |
| 00610015 | MATRIX_SHOCHI | 診療科手技マトリクス | 診療科毎の展開するタブ |
| 00610017 | COMMON_SHOCHI | 単位 | |
| 00610018 | ITEM_SHOCHI | 医事コメント | |
| 00610050 | YAKUHIN_UNIT | 処置単位 | |
| 00610101 | COMMON_SHOCHI | コメント | |
| 00610102 | INDEX_SHOCHI | インデックス | 入力画面の検索インデックス |
| 00610104 | KOUI_SHOCHI | 行為 | |
| 00610107 | ZAIRYO_SHOCHI | 材料 | |
| 00610108 | MATRIX_SHOCHI | マトリックス | 処置行為の選択画面 |
手技処置(SHUGI_SHOCHI) †
| カラム | 意味 | 説明 |
| MASTER_CODE_STR | マスタコード | 手技に設定される項目のマスタコード。種別により異なる |
| CODE | 手技コード | MATRIX_SHOCHI.ITEM_CODEにはこのコードが設定される |
| NAME | 項目名称 | 設定されている項目の名称 |
| CODE_01 | 項目種別コード | 設定されている項目の種別 |
| CODE_DBL_01 | 項目用量 | 設定されている項目の用量 |
| FLG_01 | 項目デフォルトチェック | 設定されている項目の初期チェック状態 0:未選択 1:選択 |
| STR_01 | 項目用量単位 | 設定されている項目の用量単位 |
| CODE_02 | 項目コード | 設定されている項目のコード。ZAIRYO_SHOCHI.CODEなど紐付く |
- CODE単位で1つの手技の内容を取得できる。
- 手技コードに対する名称は、MATRIX_SHOCHI.NAMEとなる。
タイミング処置(COMMON_SHOCHI − TIMING_SHOCHI) †
処置を実施するタイミングを設定するマスタです。
マスタコードは00610005です。
| コード | 名称 | 時刻 | 備考 |
| CODE | NAME | DATE_01 | 列名称です。 |
| 0 | | | フリー入力とします。 |
| 1 | 朝 | 07:00 | 例えばこんなデータが格納されます。 |
行為処置(KOUI_SHOCHI) †
処置行為を設定するマスタです。
マスタコードは00610104です。
- COMMENT_CODE
- コメントコード
行為に紐付くコメントのコードを設定します。紐付くコメントが無い場合は0を設定しておきます。
- COMMENT_FLG
- コメント設定フラグ[0:不要/1:任意/2:必須]
- KASAN_FLG
- 加算設定フラグ[0:不要/1:任意/2:必須]
- BUI_FLG
- 部位設定フラグ[0:不要/1:任意/2:必須]
トランザクション †
一覧 †
| MASTER_CODE_STR | TABLE_NAME | 名称 | 備考 |
| 00610501 | SHOCHI_DENPYO | | |
| 00610502 | SHOCHI_ITEM | | |
処置伝票(SHOCHI_DENPYO) †
- TIMING_CODE_STR
- タイミングのコードを文字列で設定します。⇒タイミング処置
【例】1
- TIMING_NAME
- タイミングの名称を設定します。⇒タイミング処置
【例】朝
- TIMING_STR
- タイミングの時刻を文字列で設定します。⇒タイミング処置
【例】07:30
処置項目(SHOCHI_ITEM) †
- ITEM_KIND
- アイテム種別
- SELECT_FLG
- 選択フラグ[0:未選択/1:選択]
選択状態を設定します。
依頼で発行する時には実施する予定の項目に1が設定されます。
実施で発行する時には実施する項目に1が設定されます。実施で0のデータはありません。
オーダ入力画面 †
入力できる内容は手技(行為)、薬品、材料、コメント(定型/フリー)、加算、部位です。
- 手技(行為)
手技選択画面から手技を選択しオーダ入力します。
或いは検索文字列により検索し入力します。
コメント、加算、部位に必須の設定がある場合は各項目の入力が無ければオーダ発行できません。 ⇒ 行為処置(KOUI_SHOCHI)
又、任意、必須の場合、依頼から実施にした時に穴埋め画面を表示します。
- コメント(定型)
行為にただ1つのみ紐付き入力できます。
入力は穴埋め画面から行います。
- 部位
行為に紐付いて複数入力できます。
共通機能 †
共通で使用する機能です。
- 時刻入力
マスタからタイミング処置のリストを表示し、そこから時刻を選択します。
追加ボタンでフリーで名称、時刻を入力できる時刻を追加します。
画面をOKで閉じる時に同時刻があればメッセージを表示して確認します。
- 最大数制御
0:制限無し/1以上:設定値まで選択可
- 必須制御
必須の時は1つ以上の時刻が選択される必要がある。
単件入力 †
1伝票毎入力します。
- 期間入力
複数日、複数時刻を選択できます。
この伝票を発行すると日付×時刻の数の伝票が複製されて発行されます。
日付選択画面で日付を選択後、時刻を選択する画面を表示して時刻を選択します。
期間入力 †
※後々実装予定です………
今回の期間日付指定ダイアログには時刻の設定ができないので別ダイアログに作成する。
画面構成 †
- タイミング一覧
- COMMON_SHOCHI.MASTER_CODE='00610005'のマスタに設定されているTIMING_SHOCHIより、名称・時刻を表示する。
- 表示は同テーブルのDISP_ORDER順。
- 選択ボタン(ダブルクリック)
- 選択を行い、選択された項目が後述の選択時刻タイミング一覧に表示される。
- 選択時刻タイミング一覧
- 選択されたタイミング名称やフリー入力した時刻を表示する。
- フリー入力以外の名称、時刻は修正不可。
- 追加ボタン
- 時刻入力画面が表示され、フリーで時刻の入力を行える。
フリー入力データはCODE=0のデータとして扱う。
フリー入力データの名称欄は手入力可能。時刻欄をクリックすると時刻入力の画面が表示される。
- 削除ボタン(Deleteキー)
- 選択時刻タイミング一覧フレックスのフォーカスのあったっている行が削除される。
- ▲ボタン
- 選択時刻タイミング一覧フレックスのフォーカスが当たっている行を一行上に移動する。
- ▼ボタン
- 選択時刻タイミング一覧フレックスのフォーカスが当たっている行を一行下に移動する。
- 必須入力チェック
- プロパティにて必須が選択されている場合はチェックを行う。
- 最大選択数チェック
- プロパティの最大選択数に応じてチェックを行う。
- 時刻重複チェック
- 選択されている時刻が重複しているかをチェックする。重複している場合は警告メッセージを表示し、続行するか選択させる。
プロパティ †
| 属性 | 名称 | 日本語名称 | 型 | 説明 |
| IN | DlgTitleStr | タイトル文字列 | string | フォームタイトル部分に表示される文字列 |
| IN | HissuFlg | 必須入力フラグ | bool | true:必須 false:必須ではない |
| IN | MaxCount | 最大選択数 | int | 0:選択制限なし n:n個まで選択可能 |
| IN/OUT | TimingList | 選択リスト | List<CommonShochi> | 選択されたタイミングリスト。CODE,NAME,DATE_01にCOMMON_SHOCHIの値が設定される。 |
| ※DATE_01は時間のみ指定されるため、年月日部分は初期値(0001/01/01)が入力されているものとする。 |
※プロパティ名は格好良くつけて下さい。
指示歴 †
サマリ行 †
- タイミング文字列
- SHOCHI_DENPYO.TIMING_NAME_STR(SHOCHI_DENPYO.TIMING_STR)で表示する。
ただし、TIMING_NAME_STR.LENGTH=0の場合はTIMING_STRのみを表示する。()はなし。
- 状態
- SHOCHI_DENPYO.STEP_FLGより依頼(0)か実施(1)かを表示。
- 行為名称
- SHOCHI_DENPYO.KOUI_NAMEを表示。
詳細は下記リンク先を参照
新コメント処理 †
- →新コメント処理仕様へ?
- 新コメント処理は構想のため、実際には下記の仕様で動作している。