JP4472740B2 - Information aggregation device and program therefor - Google Patents
Information aggregation device and program therefor Download PDFInfo
- Publication number
- JP4472740B2 JP4472740B2 JP2007256137A JP2007256137A JP4472740B2 JP 4472740 B2 JP4472740 B2 JP 4472740B2 JP 2007256137 A JP2007256137 A JP 2007256137A JP 2007256137 A JP2007256137 A JP 2007256137A JP 4472740 B2 JP4472740 B2 JP 4472740B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- aggregation
- cost
- data
- total
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Medical Treatment And Welfare Office Work (AREA)
Description
この発明は、集計対象情報を集計して複数の集計情報を作成するための情報集計装置及びそのためのプログラムに関する。 The present invention relates to an information totalization apparatus for totaling target information and creating a plurality of total information, and a program therefor.
医療機関の経営管理や業務管理を合理的に行うためには、患者の各々に対してどの程度の原価が掛けられているのかの原価管理を行うことが必要になる。この原価管理が可能になれば、患者毎の利益率を計算することが可能になり、原価の低減策を立案することによって利益率を増加させたり、利益率の高い患者の診療数を優先的に増加させることによって利益を増大させる等、経営改善策を立案することが可能になる。 In order to rationally manage and manage medical institutions, it is necessary to manage the cost of how much cost is applied to each patient. If this cost control becomes possible, it will be possible to calculate the profit rate for each patient, increase the profit rate by formulating cost reduction measures, or give priority to the number of treatments of patients with a high profit rate It is possible to plan management improvement measures, such as increasing profits by increasing the number of items.
このような点に鑑みて、従来から、医療機関における原価を計算するための方法が提案されていた。例えば特許文献１には、医療機関の部門別の収入と費用とを計算し、その結果を患者別に帳票出力する方法が開示されている。この方法では、患者疾患収支情報を作成し、設定された出力キーに応じて、患者別原価計算表、医師別原価計算表、あるいは、疾患別原価計算表を出力する点が開示されている（特許文献１の段落００２６等参照）。
In view of these points, methods for calculating costs in medical institutions have been proposed. For example,
しかしながら、特許文献１に記載の如き方法では、出力キーに応じた１種類の集計表のみを必要時毎に出力していたので、集計対象情報となる生データが数千万件のオーダになるような膨大な情報集計システムにおいては、集計表の出力を行う毎に長時間を要し、現実的な時間で出力を行うことができないため、集計機能の有用性が現実には毀損されるという問題があった。
However, in the method as described in
このような問題を解決するためには、集計対象情報が更新される毎に、必要になり得る全ての形態の集計表を予めバッチ処理で作成しておき、この中から必要な集計表のみをその都度出力させればよいとも考えられる。 In order to solve such a problem, every time the aggregation target information is updated, all forms of aggregation tables that may be necessary are created in advance by batch processing, and only the necessary aggregation tables are selected from these. It may be possible to output each time.
しかしながら、分析システムの性格上、出力時の集計軸は、特許文献１の如き患者別、医師別、疾患別の他、部門別、診断群別、月次別等の多岐に渡る。さらに実際には、これら集計軸を２次元あるいはそれ以上の次元にて組み合わせ、医師別疾患別や患者別疾患別等、多様な組み合わせで出力することが要望され得る。従って、これら集計軸やその組み合わせに基づいた膨大な種類の集計表を全て事前に作成すると、システム負荷が増大したり、システムコストを増加させる原因になるために好ましくない。 However, due to the nature of the analysis system, the summation axis at the time of output ranges from patient-specific, doctor-specific, disease-specific, department-specific, diagnostic-group-specific, monthly-specific, etc. Furthermore, in practice, it may be desired to combine these tabulation axes in two or more dimensions and output in various combinations such as by doctor-specific disease or by patient-specific disease. Therefore, it is not preferable to create in advance all the enormous types of aggregation tables based on these aggregation axes and combinations thereof because the system load increases or the system cost increases.
この発明は、このような従来技術による問題点を解消するためになされたものであり、システム負荷を増大させることなく、必要な集計表を迅速に取得することができる、情報集計装置及びそのためのプログラムを提供することを課題とする。 The present invention has been made in order to solve such problems caused by the prior art, and is capable of quickly obtaining a necessary tabulation table without increasing the system load, and an information tabulation apparatus therefor The challenge is to provide a program.
上述した課題を解決し、目的を達成するために、請求項１、４に記載の本発明は、一部の集計情報に基づいて算定可能な他の集計情報であって所定量以下の計算量で算定可能な集計情報を特定し、当該特定された集計情報以外の集計情報のみを事前に作成しておき、当該特定された集計情報の作成が所定方法で指示された場合には、当該作成が指示された集計情報を、事前に作成された集計情報に基づいて作成することを特徴とする。
In order to solve the above-described problems and achieve the object, the present invention described in
また、請求項２に記載の本発明は、他の集計情報を作成するために必要な集計キーが、一部の集計情報を作成するために必要な集計キーに全て包含されている場合に、当該一部の集計情報に基づいて当該他の集計情報が算定可能であると判定することを特徴とする。
Further, in the present invention described in
また、請求項３に記載の本発明は、一部の集計情報を作成するために必要な集計キーの内、他の集計情報を作成するために必要な集計キーに含まれていない集計キーを特定し、当該特定された集計キーに対応するデータ件数の積を、当該一部の集計情報に基づいて当該他の集計情報を作成するための計算量として算定することを特徴とする。 According to the third aspect of the present invention, a summary key that is not included in a summary key necessary for creating other summary information among a summary key required for creating some summary information is provided. A product of the number of data corresponding to the specified total key is specified and calculated as a calculation amount for creating the other total information based on the partial total information.
請求項１、４に記載の本発明によれば、比較的計算に時間を要する集計情報のみを事前に作成しておき、比較的計算に時間を要しない集計情報については事前に作成した集計情報に基づいて必要時に作成することで、システム負荷を増大させることなく、必要な集計表を迅速に取得することができる。 According to the first and fourth aspects of the present invention, only total information that requires a relatively long time for calculation is created in advance, and total information that does not require a long time for calculation is generated in advance. By creating it when necessary, it is possible to quickly obtain a necessary summary table without increasing the system load.
請求項２に記載の本発明によれば、集計キーの包含関係に基づいて、一部の集計情報に基づいて他の集計情報が算定可能であるか否かを容易かつ正確に判定することができる。 According to the second aspect of the present invention, it is possible to easily and accurately determine whether or not other aggregate information can be calculated based on some aggregate information based on the inclusion relationship of the aggregate keys. it can.
請求項３に記載の本発明によれば、集計キーに対応するデータ件数の積を計算量として用いることで、集計キーに対応するデータ件数のみを把握しておくことで、計算量を容易かつ正確に算定することができる。 According to the third aspect of the present invention, by using the product of the number of data items corresponding to the aggregation key as the calculation amount, it is possible to easily calculate the calculation amount by grasping only the number of data items corresponding to the aggregation key. It can be calculated accurately.
以下に添付図面を参照して、この発明を実施するための最良の形態について説明する。ただし、本実施の形態によって本発明が限定されるものではない。最初に本実施の形態を説明した後、本実施の形態に対する変形例について説明する。 The best mode for carrying out the present invention will be described below with reference to the accompanying drawings. However, the present invention is not limited by the present embodiment. First, after describing the present embodiment, a modification example of the present embodiment will be described.
〔Ｉ〕本実施の形態
まず、本実施の形態について説明する。
[I] This Embodiment First, this embodiment will be described.
（定義）
最初に、本実施の形態の説明に使用する用語を以下のように定義する。ただし、各用語の意味は、以下の定義に必ずしも限定されず、以下の定義と矛盾しない限りにおいて、当該各用語が通常有する意味を含み得る。「医業費用」とは、患者に対する診療行為を行った際に発生した全ての費用の総称である。「直接部門」とは、患者への医療サービスが直接認識される部門、「間接部門」とは、患者への医療サービスが直接認識されない部門である。「サービス区分」とは、直接部門をそのサービス形態に応じて区分したもので、ここでは「入院部門（病棟部門）」、「外来部門（診療部門）」、「中央診療部門」の３つに区分する。
(Definition)
First, terms used in the description of the present embodiment are defined as follows. However, the meaning of each term is not necessarily limited to the following definition, and may include the meaning that each term normally has as long as it does not contradict the following definition. “Medical costs” is a general term for all costs incurred when a medical practice is performed on a patient. The “direct department” is a department in which medical services for patients are directly recognized, and the “indirect department” is a department in which medical services for patients are not directly recognized. “Service category” is a division of direct departments according to their service type. Here, there are three categories: “inpatient department (ward department)”, “outpatient department (medical department)”, and “central medical department”. Break down.
本実施の形態では、医業費を、各患者に直接的に関連付けられる原価と、各患者に直接関連付けられない原価とに分けて算定する。前者を「直課分原価」、後者を「直課不可分原価」と称する。また、本実施の形態では、医業費を、当該医業費が生じた発生形態（ここでは医業費が生じた部門・科目）に応じた項目に分類し、各項目の特性に応じた計算パターンにて原価を計算している。この項目を「原価項目」と称する。 In the present embodiment, the medical expenses are calculated by dividing the costs into costs that are directly associated with each patient and costs that are not directly associated with each patient. The former is called “directly charged cost” and the latter is called “directly impossible cost”. Also, in this embodiment, medical expenses are classified into items according to the form in which the medical expenses were incurred (here, the department / subject in which the medical expenses were generated), and the calculation pattern according to the characteristics of each item Cost. This item is referred to as a “cost item”.
直課不可分原価の算定に際しては、直課不可分原価の算定の対象になる部門毎に医業費用を分け、この部門毎の費用に各部門に設定した係数（各サービス毎の重み付け）を乗算することで、各部門毎のサービス単位での原価を算定する。この係数を「積上係数」、このように算定されたサービス単位での原価を「サービス単位原価」と称する。より詳細には、積上係数は、特定のサービスの１回当たりの費用を１．００としたときの、他のサービスの１回当たりの費用との比である。なお、診療行為の費用に対して設定された積上係数としては、公的機関等が設定した係数（等価係数）を利用してもよい。このようなサービスの形態に応じた様々な原価の積上パターンを「原価積上パターン」、各原価積上パターンを一意に特定するために設定された情報を「原価積上パターンコード」と称する。なお、「特定保険医療材料」とは、医療機関における医療材料の支給に要する平均額が、診療報酬とは別に定められている医療材料（必要に応じて、「特保材料」と省略する）である。「物品」とは、医療機関で使用する物品を意味し、例えば、医薬品、材料、食料品を含む。「購入単位定価」とは、物品の購入単位（１箱、１ダース等）毎の定価、「購入単位購入価」とは、物品の購入単位（１箱、１ダース等）毎の購入価格である。「最小単位換算」とは、後述する物流システム１６において、医薬品や特定保険医療材料の購入単位を最小単位に変換するための係数であり、医薬品の場合には「１」に固定され、特定保険医療材料の場合には購入単位を使用単位で除算した数（購入単位が６本、使用単位が１本の場合には、最小単位換算＝６）が設定される。「医事単位変換換算」とは、後述する医事会計システム１３において、医薬品や特定保険医療材料の使用数量情報の単位を最小単位に変換するための係数であり、特定保険医療材料の場合には「１」に固定され、医薬品の場合には購入単位を使用単位で除算した数（購入単位が６本、使用単位が１本の場合には、最小単位換算＝６）が設定される。
When calculating direct-impossible costs, divide medical expenses for each department that is subject to calculation of direct-impartable costs, and multiply the costs for each department by the coefficient set for each department (weighting for each service). Then, the cost per service unit for each department is calculated. This coefficient is referred to as “rolling coefficient”, and the cost in the service unit thus calculated is referred to as “service unit cost”. More specifically, the roll-up factor is the ratio of the cost per service of a specific service to the cost per service of another service. Note that a coefficient (equivalent coefficient) set by a public institution or the like may be used as the increase coefficient set for the cost of medical practice. Such cost accumulation patterns according to the form of service are referred to as “cost accumulation patterns”, and the information set to uniquely identify each cost accumulation pattern is referred to as “cost accumulation pattern code”. . “Specified insurance medical materials” refers to medical materials whose average amount required to supply medical materials at medical institutions is determined separately from medical fees (abbreviated as “special insurance materials” as necessary) It is. “Article” means an article used in a medical institution, and includes, for example, pharmaceuticals, materials, and foodstuffs. "Purchase unit price" is the price for each purchase unit (1 box, 1 dozen, etc.), and "Purchase purchase price" is the purchase price for each unit of purchase (1 box, 1 dozen, etc.). is there. “Minimum unit conversion” is a coefficient for converting the purchase unit of pharmaceuticals and specified insurance medical materials into the minimum unit in the
特に、本実施の形態では、本システムによって作成された情報を元に、経営分析等に使用するための各種の集計表を作成する。この情報を「集計対象情報」、集計表を「集計テーブル（特許請求の範囲における集計情報に対応する）」と称する。 In particular, in the present embodiment, various tabulation tables for use in management analysis and the like are created based on information created by the present system. This information is referred to as “total object information”, and the total table is referred to as “total table (corresponding to total information in claims)”.
（本システムの概要）
次に、本発明に係る患者別原価計算装置及び患者別原価計算プログラムを用いて構築された患者別原価計算システム（以下、本システム）について概説する。図１は本システムの全体構成を概念的に示す説明図である。
(Outline of this system)
Next, a patient-specific cost calculation system (hereinafter, this system) constructed using the patient-specific cost calculation apparatus and patient-specific cost calculation program according to the present invention will be outlined. FIG. 1 is an explanatory diagram conceptually showing the overall configuration of the present system.
本システム１は、関連システム群１０に含まれる各システム１１〜２０、部門別原価計算サーバ３０、メンテナンス端末４０、及び、複数の参照端末５０を、構内ＬＡＮやインターネットの如きネットワーク６０を介して患者別原価計算サーバ（以下、本サーバ）１００に対して接続可能として構成されている。以下では、これら各機器の全てが１つの医療機関の管理下にあり、当該１つの医療機関における情報のみを取り扱う例について説明するが、複数の医療機関の各々に設置された関連システムに対して１台の患者別原価計算サーバ１００を接続して、これら医療機関の各々の患者原価を統合的又は個別的に計算することも可能である。またこれら各システム、各サーバ、及び、各端末は、必ずしも直接的に通信することを必要とせず、図示しない公知のシステムやサーバを介して間接的に接続してもよい。
This
（システム構成−関連システム群）
次に、本システム１の具体的構成について説明する。関連システム群１０は、原価の計算に必要な基本情報を提供する複数のシステムから構成されるもので、医業を行う上で使用される既存のシステムであり、特許請求の範囲における外部システムに対応する。例えば、関連システム群１０に含まれるシステムとしては、電子カルテシステム１１、看護ＰＤＡシステム１２、医事会計システム１３、財務会計システム１４、人事給与システム１５、物流システム１６、固定資産システム１７、購買システム１８、手術管理システム１９、及び、健診システム２０を挙げることができる。
(System configuration-related systems)
Next, a specific configuration of the
電子カルテシステム（オーダーシステム）１１は、診療現場で医師が発した指示を医療スタッフや事務担当者に伝達するための情報処理を行なう。看護ＰＤＡシステム１２は看護者がＰＤＡ（Personal Data Assistance）を介して看護情報を入力又は出力するための情報処理を行なう。医事会計システム１３は電子カルテや会計に関する情報を入力又は出力するための情報処理を行なう。財務会計システム１４は財務会計に関する情報を入力又は出力するための情報処理を行なう。人事給与システム１５は人事給与に関する情報を入力又は出力するための情報処理を行なう。物流システム１６は物品の管理に関する情報を入力又は出力するための情報処理を行なう。固定資産システム１７は医療機関の固定資産に関する情報を入力又は出力するための情報処理を行なう。購買システム１８は物品の購入に関する情報を入力又は出力するための情報処理を行なう。手術管理システム１９は手術管理に関する情報を入力又は出力するための情報処理を行なう。健診システム２０は健康診断に関する情報を入力又は出力するための情報処理を行なう。これら関連システム群１０の各システム１１〜２０は従来と同様に構成することができるためにその詳細な説明は省略するが、いずれのシステム１１〜２０も、当該システム１１〜２０が管理する情報を当該システム内部のデータベース（特許請求の範囲における一次情報格納手段に対応する）に格納すると共に、当該データベース（以下、ＤＢ）に格納した情報（特許請求の範囲における一次情報に対応する）を、部門別原価計算サーバ３０や患者別原価計算サーバ１００からの要求に応じて、当該部門別原価計算サーバ３０や当該患者別原価計算サーバ１００に送信する機能を有する。ただし、本実施の形態に示す関連システム群１０の構成は例示であり、他の任意のシステムから所望のデータを取得してもよく、あるいは、メンテナンス端末４０を介して患者別原価計算サーバ１００の管理者が必要なデータを必要時に手入力してもよい。また、関連システム群１０から取得されるものとして後述する各データについては、特記する場合を除いてその一部の取得を省略してもよく、この場合において原価計算精度は低下するものの原価計算自体は依然として可能である。
An electronic medical record system (order system) 11 performs information processing for transmitting instructions issued by a doctor at a clinical site to medical staff and office staff. The
（システム構成−部門別原価計算サーバ）
部門別原価計算サーバ３０は、公知の経営情報システムであり、関連システム群１０の各システムから取得した情報に基づいて、部門別原価の計算を行うものである。この部門別原価計算サーバ３０は従来と同様に構成することができるためにその詳細な説明は省略するが、当該部門別原価計算サーバ３０は、自己が管理する情報を、当該システム内部のＤＢに格納すると共に、当該ＤＢに格納した情報を、患者別原価計算サーバ１００からの要求に応じて、当該患者別原価計算サーバ１００に送信する機能を有する。
(System configuration-departmental cost calculation server)
The divisional
（システム構成−メンテナンス端末及び参照端末）
メンテナンス端末４０は、患者別原価計算サーバ１００の管理者が、当該患者別原価計算サーバ１００の各種処理に必要なデータの入力や更新を行ったり、当該患者別原価計算サーバ１００の保守運用に必要な情報の入力又は出力を行うための端末である。参照端末５０は、患者別原価計算サーバ１００のユーザが、当該患者別原価計算サーバ１００が管理する情報を表示や出力するための端末である。これらメンテナンス端末４０及び参照端末５０は従来の情報処理装置（例えばパーソナルコンピュータであり、ネットワーク接続機能、ブラウジング機能、及び、ローカルメモリを備えるもの）と同様に構成することができるためにその詳細な説明は省略する。
(System configuration-maintenance terminal and reference terminal)
The
（システム構成−患者別原価計算サーバ）
次に、患者別原価計算サーバ１００の構成について説明する。本サーバ１００は、機能概念的に、記憶部２００、制御部３００、及び、ネットワークインターフェース（以下「ネットワークＩＦ」）４００を、バス５００にて通信可能に接続して構成されている。
(System configuration-Cost calculation server by patient)
Next, the configuration of the patient-specific
記憶部２００は、患者別原価計算サーバ１００における各種処理に必要な情報やパラメータを揮発的又は不揮発的に格納する格納手段であり、例えば、ＨＤ(Hard Disk）にて構成される。具体的には、この記憶部２００は、マスタＤＢ群２１０と、データＤＢ群２５０とを含んで構成されている。
The
マスタＤＢ群２１０は、関連システム群１０や部門別原価計算サーバ３０から提供された各種の一次情報を、当該関連システム群１０の各サーバにおけるデータフォーマットの相違等を排除して、患者別原価計算サーバ１００における各種処理に必要な情報に変換するために、これら一次情報と基本情報との相互の対応関係を特定するための対応関係情報（マスタデータ）等を格納するＤＢ群である。このマスタＤＢ群２１０は、具体的には、原価積上マスタＤＢ２１１、原価積上パターンマスタＤＢ２１２、原価積上パターン設定マスタＤＢ２１３、原価部門マスタＤＢ２１４、原価部門変換マスタＤＢ２１５、原価科目変換マスタＤＢ２１６、特定保険医療材料マスタＤＢ２１７、他システム職員マスタＤＢ２１８、診療行為マスタＤＢ２１９、診療行為積上対象マスタＤＢ２２０、積上係数マスタＤＢ２２１、物品マスタＤＢ２２２、他システム物品マスタＤＢ２２３、及び、標準医薬品マスタＤＢ２２４を含んで構成されている。これら各ＤＢ２１１〜２２４のデータの構成例については後述する。
The
データＤＢ群２５０は、マスタＤＢ群２１０のマスタデータ等を用いて変換又は算定された基本情報を格納するＤＢ群である。このデータＤＢ群２５０は、具体的には、部門別原価計算データＤＢ２５１、職員情報ＤＢ２５２、職員別人件費情報ＤＢ２５３、職員タイムスタディ情報ＤＢ２５４、職員別患者別時間比情報ＤＢ２５５、患者入院データＤＢ２５６、患者別手術データＤＢ２５７、患者別サービスデータＤＢ２５８、患者食数データＤＢ２５９、サービス別件数データＤＢ２６０、サービス単位原価データＤＢ２６１、積上対象データＤＢ２６２、患者別物品消費データＤＢ２６３、患者別日別収益データマートＤＢ２６４、患者別原価計算データマートＤＢ２６５、患者別直課計算データＤＢ２６６、患者別日別データＤＢ２６７、患者別直課データＤＢ２６８、集計参照情報ＤＢ２６９（特許請求の範囲における集計参照情報格納手段に対応する）、及び、事前集計テーブルＤＢ２７０を含んで構成されている。これら各ＤＢ２５１〜２７０は、当該各ＤＢ２５１〜２７０の名称に示されている情報を格納するもので、例えば部門別原価計算データＤＢ２５１は部門別原価計算データを格納する。これら各ＤＢ２５１〜２７０のデータの構成例については後述する。
The
制御部３００は、患者別原価計算サーバ１００の各部を制御する制御手段であり、機能概念的に、Ｉ／Ｆ取込処理部３０１、サービス別件数データ作成部３０２、積上係数計算部３０３、直課不可分計算部３０４、直課計算部３０５、患者別原価計算部３０６、患者別原価出力部３０７を備える。さらに、患者別原価出力部３０７は、集計情報選別部３０７ａ、事前集計部３０７ｂ、及び、随時集計部３０７ｃを備える。これら各部の具体的処理内容については後述する。これら集計情報選別部３０７ａ、事前集計部３０７ｂ、及び、随時集計部３０７ｃは、特許請求の範囲における集計情報選別手段、事前集計手段、随時集計手段にそれぞれ対応する。この制御部３００は、具体的には、ＣＰＵ（Central Processing Unit）や、このＣＰＵ上で解釈実行される各種のプログラム（ＯＳなどの制御プログラムや、各種の処理手順などを規定したプログラム）、及び、所要プログラムや所要データを格納するための内部メモリを備えて構成される。
The
ネットワークＩＦ４００は、患者別原価計算サーバ１００がネットワーク６０を介した通信を行うための通信制御インターフェースであり、例えばネットワークボードとして構成される。
The network IF 400 is a communication control interface for the patient-specific
（処理内容）
次に、本サーバ１００にて行われる処理（以下、本処理）について説明する。本処理は任意のタイミングで、全体を一括して、あるいは任意の一部分の処理を個別的に行うことができる。例えば、各月毎に本処理を自動的に起動することで、各月の患者別原価を自動的に計算して計算結果情報ＤＢ群に格納することができる。なお、以下の各処理の説明において、情報の取得元や取得経路を特記しない場合については、公知のタイミング及び公知の方法にて、関連システム群１０の各システムや部門別原価計算サーバ３０から取得することができ、あるいは、メンテナンス端末４０を介して管理者が手入力する。
(Processing content)
Next, processing (hereinafter, this processing) performed in the
（処理内容−原価計算パターン）
本処理では、図２は本処理の原価計算パターンを示す図である。この図には、原価項目、種別、積上係数設定値、サービス単位原価の値、及び、積上方法を相互に関連付けて示す。
(Processing-Costing pattern)
In this process, FIG. 2 is a diagram showing a cost calculation pattern of this process. This figure shows the cost item, type, roll-up coefficient setting value, service unit cost value, and roll-up method in association with each other.
原価項目は、「診療行為（給与費）」、「診療行為（材料費）」、「診療行為（設備費）」、「診療行為（検査委託費）」、「診療行為（その他）」、「特定保険医療材料」、「ベッド面積」、「カルテ参照時間」、「食数」、「患者数」、「手術時間」、「手術室在室時間」、「医薬品及び材料」である。 Cost items include “medical practice (salary costs)”, “medical practice (material costs)”, “medical practice (equipment costs)”, “medical practice (examination commissions)”, “medical practice (others)”, “ Specific insurance medical materials, “bed area”, “medical chart reference time”, “number of meals”, “number of patients”, “operating time”, “operating room occupancy time”, “medicine and materials”.
種別とは、直課、又は、直課不可分（積上げによる計算）のいずれかを示す区分である。ここでは、原価項目「医薬品及び材料」のみが直課であり、その他の原価項目は直課不可分である。 The type is a category indicating either direct charge or indivisible (calculation by accumulation). Here, only the cost item “pharmaceuticals and materials” is directly charged, and other cost items are indivisible.
積上係数設定値とは、積上係数を設定する上での基準になる値である。本実施の形態では、積上係数を、原価項目に応じたグループ毎に異なる方法で算定又は取得する。第１のグループは、原価項目「診療行為（給与費）」〜「診療行為（その他）」である。第２のグループは、原価項目「特定保険医療材料」及び「ベッド面積」である。第３のグループは、その他の直課不可分の全ての原価項目である。積上係数設定値としては、例えば、「診療行為（給与費）」〜「診療行為（その他）」については「積上係数」、「特定保険医療材料」については「特定保険医療材料点数」、「ベッド面積」については「ベッド面積」、「カルテ参照時間」については「各医師毎の総カルテ参照時間」、「食数」については「全患者の総食数」、「患者数」については「診療行為（給与費）項目のサービス別件数データＤＢ２６０より患者数を抽出して取得された、部門毎の患者数」、「手術時間」については「職員（執刀医）毎の総執刀時間」、「手術室在室時間」については「全患者の総手術室在室時間」である。
The product factor setting value is a value that serves as a reference for setting the product factor. In the present embodiment, the increase coefficient is calculated or acquired by a different method for each group corresponding to the cost item. The first group includes cost items “medical practice (salary expenses)” to “medical practice (others)”. The second group is the cost items “specific insurance medical material” and “bed area”. The third group is all other cost items that cannot be directly charged. As the increase coefficient setting value, for example, for “medical practice (salary expenses)” to “medical practice (others)”, the “collision coefficient”, for “specific insurance medical material”, “specific insurance medical material score”, “Bed area” for “Bed area”, “Total chart reference time” for “Total chart reference time for each doctor”, “Number of meals” for “Total number of meals for all patients”, “Number of patients” “The number of patients for each department obtained by extracting the number of patients from the service
サービス単位原価の値とは、積上係数に対して乗算される値であり、各原価項目における原価単位の値である。サービス単位原価の値としては、例えば、「診療行為（給与費）」〜「診療行為（その他）」については「各診療行為１回当たりの単価」、「特定保険医療材料」については「各特定保険医療材料１つ当たりの単価」、「ベッド面積」については「各病室１泊当たりの単価」、「カルテ参照時間」については「医師毎のカルテ参照時間１分当たりの単価」、「食数」については「１食当たりの単価」、「患者数」については「部門毎の患者１人当たりの単価」、「手術時間」については「職員（執刀医）毎の執刀時間１分当たりの単価」、「手術室在室時間」については「手術室在室時間１時間当たりの単価」を用いる。 The value of the service unit cost is a value that is multiplied by the roll-up coefficient, and is the value of the cost unit in each cost item. The value of the service unit cost is, for example, “unit price per clinical practice” for “medical practice (salary expenses)” to “medical practice (other)”, and “specific each medical insurance material”. "Unit price per insurance medical material", "Bed area" is "Unit price per night for each room", "Medical chart reference time" is "Unit price per minute of medical chart reference time per doctor", "Number of meals" "For unit price per meal", "number of patients" for "unit price per patient per department", for "surgery time" "unit price per minute of operating time per staff (surgeon)" For “operating room occupancy time”, “unit price per operating room occupancy time per hour” is used.
積上方法とは、直課不可分の原価計算方法である。積上方法としては、例えば、「診療行為（給与費）」〜「診療行為（その他）」については、医事明細データから患者別日別診療行為情報を抽出した後、診療行為積上対象マスタＤＢ２２０により部門毎に抽出する診療行為を設定し、各診療行為１回当たりの単価を算出した後、この単価を各患者毎に積上げる。
The roll-up method is a cost calculation method that cannot be directly applied. As a loading method, for example, for “medical practice (salary expenses)” to “medical practice (others)”, the daily clinical practice information for each patient is extracted from the medical statement data, and then the clinical practice rollup
（処理内容−原価計算ロジック）
次に、各原価計算パターンに応じた原価計算ロジックを概念的に説明する。図３は本処理の原価計算ロジックの概要を示す図であり、（ａ）は直課不可分処理のロジック、（ｂ）は直課分処理のロジック、（ｃ）は患者別原価計算処理のロジックである。
(Processing-Costing logic)
Next, a cost calculation logic corresponding to each cost calculation pattern will be conceptually described. FIG. 3 is a diagram showing an outline of the cost calculation logic of this process, where (a) is the logic of the direct division indivisible processing, (b) is the logic of the direct division processing, and (c) is the logic of the cost calculation processing by patient. It is.
図３（ａ）に示すように、直課不可分処理では、「Ｉ／Ｆ取込処理」、「サービス別件数データ作成処理」、「積上係数計算処理」、「直課不可分計算処理」を順次実行する。これら各処理の具体的内容は、各原価項目に応じて異なり得る。例えば、積上係数計算処理として、原価項目が「診療行為（給与費）」〜「診療行為（その他）」の各原価を計算するためには「診療行為型」の積上係数計算処理を実行し、原価項目が「特定保険医療材料」や「ベッド面積」の各原価を計算するためには「原価積上係数型」の積上係数計算処理を実行し、その他の原価項目の各原価を計算するためには「サービス別件数型」の積上係数計算処理を実行する。同様に、他の処理についても、図３（ａ）に示す通り、各原価項目の特性に応じて、同一処理又は異なる処理を実行する。このように特性に適合した処理を行なうことで、各原価の発生形態に即した原価計算を行うことが可能になる。ただし、当該処理のパターンは、図３（ａ）に示した「診療行為（給与費）」〜「手術室在室時間」の１２パターンに限定されず、当該システムが利用される医療機関のアクティビティに応じてパターンの追加や削除を行ってもよい。例えば、図３（ａ）の例では健康診断関連のアクティビティを対象外としているので、当該アクティビティを実施している医療機関においては、当該アクティビティに応じたパターンを追加してもよい。 As shown in FIG. 3 (a), in the directly-directed inseparable process, “I / F acquisition process”, “number-of-services data creation process”, “rolling coefficient calculation process”, and “directly indivisible part calculation process” Run sequentially. The specific contents of each of these processes may vary depending on each cost item. For example, as the cost factor calculation process, to calculate each cost for the cost items "medical practice (salary expenses)" to "medical practice (others)", execute the "medical practice type" cost coefficient calculation process However, in order to calculate each cost for the cost item “specified insurance medical material” and “bed area”, the cost factor calculation processing of “cost increase factor type” is executed, and each cost of other cost items is calculated. In order to calculate, the “coefficient by service type” roll-up coefficient calculation process is executed. Similarly, for other processes, the same process or different processes are executed according to the characteristics of each cost item, as shown in FIG. By performing processing suitable for the characteristics in this way, it is possible to perform cost calculation in accordance with the generation form of each cost. However, the pattern of the processing is not limited to the 12 patterns of “medical practice (salary cost)” to “operating room occupancy time” shown in FIG. 3A, and the activity of the medical institution in which the system is used Patterns may be added or deleted depending on For example, in the example of FIG. 3 (a), activities related to health examinations are excluded, and therefore a medical institution performing the activities may add a pattern according to the activities.
図３（ｂ）に示すように、直課分処理は、「Ｉ／Ｆ取込処理」及び「直課計算処理」を順次実行するものである。本実施の形態では、医薬品費又は材料費のうち、直課できる原価を直課分処理で算定する。 As shown in FIG. 3B, the direct division processing sequentially executes “I / F acquisition processing” and “direct calculation processing”. In the present embodiment, the cost that can be directly imposed out of the pharmaceutical cost or the material cost is calculated by the direct charge processing.
図３（ｃ）に示すように、患者別原価計算処理において、直課不可分処理にて算定された直課不可分原価と、直課処理において算定された直課原価とを、患者別に加算することで、患者別原価を算定して出力する。 As shown in FIG. 3 (c), in the patient-specific cost calculation process, the direct-indivisible cost calculated in the direct-indivisible process and the direct-in cost calculated in the direct process are added for each patient. Then, calculate and output the cost for each patient.
（処理内容−直課不可分処理）
最初に、直課不可分原価を算定するための直課不可分処理について説明する。
(Processing content-Directly indivisible processing)
First, the direct indivisible processing for calculating the direct indivisible cost will be described.
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理）
まず、図３（ａ）に示したＩ／Ｆ取込処理の具体的内容について説明する。この処理は、主としてＩ／Ｆ取込処理部３０１により実行される。以下ではＩ／Ｆ取込処理に含まれる各処理について順次説明するが、以下の説明順序に限定されず、所要の計算結果を得るために採用し得る任意の順序にて、以下の各処理の全部又は必要な一部のみが実行される（この点は、Ｉ／Ｆ取込処理以外の後述する他の処理においても同じ）。また、以下のＩ／Ｆ取込処理の説明において情報の取得経路を明示した場合であっても、当該明示した取得経路に限定されず、理論的に情報が取得可能な限りにおける任意の経路で情報を取得することができる。なお、以下の各処理で使用する列定義は、予め記憶部２００に格納しておくことができ、あるいは、制御部３００を構成するプログラムに記述しておくことができる（Ｉ／Ｆ取込処理の各処理において同じ）。
(Processing content-Directly indivisible processing-I / F import processing)
First, the specific contents of the I / F acquisition process shown in FIG. This process is mainly executed by the I / F
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−部門別原価計算処理）
まず、部門別原価計算処理について説明する。図４は部門別原価計算処理のデータの構成例及びフローを示す図である。この処理においてＩ／Ｆ取込処理部３０１は、関連システム群１０の部門別原価計算サーバ３０より収集した部門別原価計算データＩ／Ｆを、所定の列定義に従ったマッピング作業を行い、部門別原価計算データＤＢ２５１に登録する。具体的には、部門別原価計算データＩ／Ｆに含まれる科目コードを、原価科目変換マスタＤＢ２１６を参照して本サーバ１００における科目コードに変換し、部門別原価計算データＩ／Ｆに含まれる部門コードを、原価部門変換マスタＤＢ２１５を参照して本サーバ１００における部門コードに変換し、部門別原価計算データＩ／Ｆに含まれるその他の情報についてはそのまま対応する科目コードに関連付けて登録する。なお、同一のＰＫ（Primary Key）に関連付けられた原価金額、当該部門原価金額、又は、間接部門原価金額のいずれかが複数ある場合には、これら複数の金額を加算した金額を登録する。これにて部門別原価計算処理を終了する。
(Processing content-Directly indivisible processing-I / F import processing-Departmental cost calculation processing)
First, the departmental cost calculation process will be described. FIG. 4 is a diagram showing a configuration example and a flow of data of departmental cost calculation processing. In this process, the I / F
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−人件費情報取込処理）
次に、図３（ａ）に示した人件費情報取込処理について説明する。図５は人件費情報取込処理のデータの構成例及びフローを示す図である。この処理では、人事給与システム１５より収集した人件費マスタＩ／Ｆを、所定の列定義に従ったマッピング作業を行い、職員人件費情報ＤＢ２５３に登録する。具体的には、人件費マスタＩ／Ｆに含まれる年月、職員ＩＤ、基準内（所定基準内における人件費。以下同じ）、基準外（所定基準外における人件費。以下同じ）、事業主負担を、そのまま相互に関連付けて登録する。また、基準内、基準外、及び、事業主負担を加算して、人件費計として登録する。部門コードは、原価部門変換マスタＤＢ２１５を参照して本サーバ１００における部門コードに変換して登録する。科目コードは、人件費マスタＩ／Ｆに含まれる部門別原価上のデータ区分、職種区分、職員区分、及び、部門コードを集約して患者別原価上の科目コードを生成する。これにて人件費情報取込処理を終了する。
(Processing content-Directly indivisible processing-I / F acquisition processing-Personnel cost information acquisition processing)
Next, the labor cost information take-in process shown in FIG. FIG. 5 is a diagram showing a data configuration example and flow of personnel cost information fetch processing. In this process, the labor cost master I / F collected from the
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−タイムスタディ情報取込処理）
次に、図３（ａ）に示したタイムスタディ情報取込処理について説明する。図６はタイムスタディ情報取込処理のデータの構成例及びフローを示す図である。この処理では、メンテナンス端末４０を介して管理者が手入力した職員タイムスタディ情報Ｉ／Ｆを、所定の列定義に従ったマッピング作業を行い、職員タイムスタディ情報ＤＢ２５４に登録する。具体的には、職員タイムスタディ情報Ｉ／Ｆに含まれる年月、職員ＩＤ、時間を、そのまま相互に関連付けて登録する。また、職員タイムスタディ情報Ｉ／Ｆに含まれる部門コードは、原価部門変換マスタＤＢ２１５を参照して本サーバ１００における部門コードに変換して登録する。また職員ＩＤに対応する科目コードを職員人件費情報ＤＢ２５３から取得して登録する。これにてタイムスタディ情報取込処理を終了する。
(Processing content-Directly inseparable processing-I / F capture processing-Time study information capture processing)
Next, the time study information fetching process shown in FIG. FIG. 6 is a diagram showing a data configuration example and a flow of time study information fetching processing. In this process, the staff time study information I / F manually input by the administrator via the
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−診療行為マスタ取込処理）
次に、図３（ａ）に示した診療行為マスタ取込処理について説明する。図７は診療行為マスタ取込処理の概要を示す図である。この処理では、医事会計システム１３より収集した点数マスタＩ／Ｆ（必要に応じて医事点数マスタＩ／Ｆと称する）から、データ区分が「診療行為」であるデータを抽出し、このデータを対象として所定の列定義に従ったマッピング作業を行い、各データを図示のように診療行為マスタＤＢ２１９に登録する。これにて診療行為マスタ取込処理を終了する。
(Processing content-Directly indivisible processing-I / F acquisition processing-Medical practice master acquisition processing)
Next, the medical practice master take-in process shown in FIG. FIG. 7 is a diagram showing an outline of the medical practice master take-in process. In this process, data whose data classification is “medical practice” is extracted from the score master I / F collected from the medical accounting system 13 (referred to as medical score master I / F if necessary), and this data is the target. As described above, mapping is performed according to a predetermined column definition, and each data is registered in the medical
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−特保材料マスタ取込処理）
次に、図３（ａ）に示した特保材料（医療材料。以下同じ）マスタ取込処理について説明する。図８は特保医材マスタ取込処理の概要を示す図である。この処理では、医事会計システム１３より収集した医事点数マスタＩ／Ｆから、データ区分が「材料」であるデータを抽出し、このデータを対象として所定の列定義に従ったマッピング作業を行い、各データを図示のように特定保険医療材料マスタＤＢ２１７に登録する。これにて特保医材マスタ取込処理を終了する。
(Processing content-Directly indivisible processing-I / F acquisition processing-Special protection material master acquisition processing)
Next, the special insurance material (medical material; the same applies hereinafter) master acquisition process shown in FIG. FIG. 8 is a diagram showing an outline of the special medical material master taking-in process. In this process, data whose data classification is “material” is extracted from the medical score master I / F collected from the
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−ベッド面積取込処理）
次に、図３（ａ）に示したベッド面積取込処理について説明する。図９はベッド面積取込処理の概要を示す図である。この処理では、メンテナンス端末４０を介して管理者が手入力した原価積上マスタＩ／Ｆを、所定の列定義に従ったマッピング作業を行い、各データを図示のように原価積上マスタＤＢ２１１に登録する。これにてベッド面積取込処理を終了する。
(Processing-Directly inseparable processing-I / F acquisition processing-Bed area acquisition processing)
Next, the bed area taking process shown in FIG. FIG. 9 is a diagram showing an outline of the bed area capturing process. In this process, the costing master I / F manually input by the administrator via the
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−医事明細データ取込処理）
次に、図３（ａ）に示した医事明細データ取込処理について説明する。図１０は医事明細データ取込処理のデータの構成例及びフローを示す図である。この処理では、医事会計システム１３より収集した医事明細情報Ｉ／Ｆについて、全レコードを対象とした各サービスのトータル回数を日別サービス別に抽出して患者別サービスＩ／Ｆとする。そして、この患者別サービスＩ／Ｆを、所定の列定義に従ったマッピング作業を行い、患者別サービスデータＤＢ２５８に登録する。具体的には、医事明細情報Ｉ／Ｆに含まれる患者番号、日付、内部コード、数量を、患者別サービスデータＤＢ２５８における患者ＩＤ、日付、医事内部コード、回数／使用数として相互に関連付けて登録する。また、入外（入院又は外来の識別情報。以下同じ）、診療科コード（従科）、法別番号、及び、診療区分コードの組み合わせに応じた所定の部門コードを特定し、この部門コードを、原価部門変換マスタＤＢ２１５を参照して本サーバ１００における部門コードに変換して登録する。これにて医事明細データ取込処理を終了する。
(Processing content-Directly indivisible processing-I / F import processing-Medical statement data capture processing)
Next, the medical statement data take-in process shown in FIG. FIG. 10 is a diagram showing a data configuration example and flow of medical statement data fetch processing. In this process, regarding the medical statement information I / F collected from the
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−患者入院データ取込処理）
次に、図３（ａ）に示した患者入院データ取込処理について説明する。図１１は患者入院データ取込処理のデータの構成例及びフローを示す図である。この処理では、医事会計システム１３より収集した患者入院情報Ｉ／Ｆを、所定の列定義に従ってマッピング作業を行い、患者入院データＤＢ２５６に登録する。具体的には、患者入院情報Ｉ／Ｆに含まれる患者番号、病室コード、入院日、退院日、転入日、転出日を、患者入院データＤＢ２５６における患者ＩＤ、病室コード、入院日、退院日、転入日、転出日として相互に関連付けて登録する。また、病棟コードを、原価部門変換マスタＤＢ２１５を参照して本サーバ１００における部門コードに変換して登録し、主治医を、他システム職員マスタＤＢ２１８を参照して本サーバ１００における主治医コードに変換して登録する。これにて患者入院データ取込処理を終了する。
(Processing content-Directly inseparable processing-I / F capture processing-Patient hospitalization data capture processing)
Next, the patient hospitalization data taking process shown in FIG. FIG. 11 is a diagram showing a configuration example and a flow of data of the patient hospitalization data take-in process. In this process, the patient hospitalization information I / F collected from the
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−医師別患者時間比取込処理）
次に、図３（ａ）に示した医師別患者時間比取込処理について説明する。図１２は医師別患者時間比取込処理のデータの構成例及びフローを示す図である。この処理では、電子カルテシステム１１より収集した医師別患者別時間比情報Ｉ／Ｆを、所定の列定義に従ってマッピング作業を行い、職員別患者別時間比情報ＤＢ２５５に登録する。具体的には、医師別患者別時間比情報Ｉ／Ｆに含まれる患者ＩＤ、日付、参照時間を、職員別患者別時間比情報ＤＢ２５５における患者ＩＤ、日付、参照時間として相互に関連付けて登録する。また、診療科コードを、原価部門変換マスタＤＢ２１５を参照して本サーバ１００における部門コードに変換して登録し、職員ＩＤを、他システム職員マスタＤＢ２１８を参照して本サーバ１００における職員ＩＤに変換して登録する。これにて医師別患者時間比取込処理を終了する。
(Processing content-Directly indivisible processing-I / F uptake processing-Patient time ratio uptake processing by doctor)
Next, the doctor-specific patient time ratio capture process shown in FIG. 3A will be described. FIG. 12 is a diagram illustrating a configuration example and a flow of data of a doctor-specific patient time ratio capturing process. In this process, the doctor-specific patient time ratio information I / F collected from the electronic
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−患者別手術データ取込処理）
次に、図３（ａ）に示した患者別手術データ取込処理について説明する。図１３は患者別手術データ取込処理の概要を示す図である。この処理では、手術管理システム１９より収集した患者別手術データＩ／Ｆを、所定の列定義に従ってマッピング作業を行い、各データを図示のように患者別手術データＤＢ２５７に登録する。これにて患者別手術データ取込処理を終了する。
(Processing content-Directly inseparable processing-I / F acquisition processing-Patient-specific operation data acquisition processing)
Next, the patient-specific operation data take-in process shown in FIG. FIG. 13 is a diagram showing an outline of the patient-specific operation data fetching process. In this process, the patient-specific operation data I / F collected from the operation management system 19 is mapped according to a predetermined column definition, and each data is registered in the patient-specific
（処理内容−直課不可分処理−Ｉ／Ｆ取込処理−食数取込処理）
次に、図３（ａ）に示した食数取込処理について説明する。図１４は食数取込処理の概要を示す図である。この処理では、医事会計システム１３より収集した入院カレンダＩ／Ｆを、所定の列定義に従ってマッピング作業を行い、各データを図示のように患者食数データＤＢ２５９に登録する。これにて食数取込処理を終了し、全てのＩ／Ｆ取込処理が終了する。
(Processing content-Directly indivisible processing-I / F acquisition processing-Number of meals acquisition processing)
Next, the meal number taking process shown in FIG. FIG. 14 is a diagram showing an outline of the meal number taking process. In this processing, the hospitalization calendar I / F collected from the
（処理内容−直課不可分処理−サービス別件数データ作成処理）
次に、図３（ａ）に示したサービス別件数データ作成処理の具体的内容について説明する。この処理は、主としてサービス別件数データ作成部３０２により実行される。
(Processing content-Directly inseparable processing-Service count data creation processing by service)
Next, the specific contents of the service-specific number data creation processing shown in FIG. This process is mainly executed by the service number
（処理内容−直課不可分処理−サービス別件数データ作成処理−第１データ作成処理）
まず、第１データ作成処理について説明する。図１５、１６は第１データ作成処理のデータの構成例及びフローを示す図である。この処理では、患者別サービスデータＤＢ２５８より、診療行為積上対象を抽出し、サービス別件数データＤＢ２６０に出力する。
(Processing content-Directly indivisible processing-Number-of-services data creation processing by service-First data creation processing)
First, the first data creation process will be described. 15 and 16 are diagrams showing a data configuration example and flow of the first data creation process. In this process, the medical treatment accumulation target is extracted from the patient-specific
ここで、本実施の形態において、診療行為は、実際にどの部門で行われたのかを患者別サービスデータＤＢ２５８の部門コードに基づいて判定できる診療行為と、実際にどの部門で行われたのかを患者別サービスデータＤＢ２５８の部門コードに基づいて判断することができない診療行為とに大別される。すなわち、部門コードは、図１０に示したように、医事会計システム１３より収集した医事明細情報Ｉ／Ｆから取得されるコードであるが、この医事会計システム１３は、その元来の目的が原価計算用ではなく医療費算定用であるため、部門コードで特定される部門が原価計算上の部門とは必ずしも合致しない場合がある。例えば、患者が内科医の診察を受けた場合、当該診察に対応する医療費は、医事会計システム１３では内科に計上されると共に、原価計算上も内科に計上されるべきであるため、医事会計システム１３で特定される部門は原価計算上の部門と一致する。一方、患者が内科医の指示によって中央診療部門に属する所定の診療行為（放射線科における画像診断や、手術室における各種の手術等）を受けた場合、当該診療行為に対応する医療費は医事会計システム１３では内科に計上されるが（医療費算定用の部門は診療科や病棟部門に限定され、中央診療部門が該当しないため）、原価計算上は中央診療部門（放射線科や手術室）に計上すべきである。そこで、本実施の形態では、実際にどの部門で行われたのかを医事会計システム１３で特定される部門に基づいて判定できる診療行為については、当該部門コードに基づいて部門を判定し、サービス別件数の記録を行う。この処理を図１５に示す。一方、実際にどの部門で行われたのかを医事会計システム１３で特定される部門に基づいて判定できない診療行為については、部門と診療行為との対応関係を予め診療行為積上対象マスタＤＢ２２０に格納しておき、この診療行為積上対象マスタＤＢ２２０を参照して部門を特定し（医事会計システム１３で特定される部門は使用せずに）、サービス別件数の記録を行う。この処理を図１６に示す。このような処理を行なうことで、医療費算定と原価算定との差異を補正し、一層正確な原価算定を行うことができる。
Here, in the present embodiment, the medical practice that can be determined based on the department code of the patient-specific
具体的には、図１５の処理では、患者別サービスデータＤＢ２５８に含まれる患者ＩＤ、日付、部門コード、医事内部コード、回数／使用数を、サービス別件数データＤＢ２６０における患者ＩＤ、日付、部門コード、原価積上コード、件数として相互に関連付けて出力する。また、患者別サービスデータＤＢ２５８の部門コードに基づいて原価部門マスタＤＢ２１４を参照し、当該部門コードに対応する診療行為件数作成種別が「部門参照」となっているか否かを判定し、「部門参照」となっている場合には（実際にどの部門で行われたのかを医事内部コードに基づいて判定できる所定の診療行為である場合には）、患者別サービスデータＤＢ２５８の部門コードに対応する部門を、原価部門変換マスタＤＢ２１５を参照して本サーバ１００における部門コードに変換し、対象の診療行為を抽出する。また、患者別サービスデータＤＢ２５８の医事内部コードに対応する原価積上名称を、診療行為積上対象マスタＤＢ２２０及び診療行為マスタＤＢ２１９を順次参照することで特定し、サービス別件数データＤＢ２６０に出力する。
Specifically, in the process of FIG. 15, the patient ID, date, department code, medical internal code, number of times / use number included in the patient-specific
これに対して図１６の処理では、患者別サービスデータＤＢ２５８の部門コードに基づいて原価部門マスタＤＢ２１４を参照し、当該部門コードに対応する診療行為件数作成種別が「部門参照」となっていない場合には（実際にどの部門で行われたのかを医事会計システム１３で特定される部門に基づいて判断することができない診療行為である場合には）、部門コードの変換を行わず、部門に関係なく対象の診療行為を抽出する。つまり、この場合には、患者別サービスデータＤＢ２５８の部門コードを用いず、診療行為積上対象マスタＤＢ２２０に入っている部門を用いて、サービス別件数データを作成する。例えば、患者別サービスデータＤＢ２５８において「診療行為＝画像診断」に対応する部門が「部門＝内科」や「部門＝病棟１」となっている場合であっても、診療行為積上対象マスタＤＢ２２０において「診療行為＝画像診断」に対応する部門が「部門＝放射線化」となっている場合、「部門＝放射線化」を「診療行為＝画像診断」に対応させてサービス別件数データを作成する。これにて第１データ作成処理を終了する。なお、診療行為積上対象マスタＤＢ２２０の情報（部門と診療行為との対応関係情報）については各医療機関に応じて異なる可能性があるため、各医療機関でヒアリングを行う等して、各医療機関の実情に合致した内容の診療行為積上対象マスタＤＢ２２０を設定することが好ましい。
On the other hand, in the process of FIG. 16, the cost
これら図１５、１６の各処理では、原価積上パターン設定マスタＤＢ２１３を参照し、原価積上パターン設定マスタＤＢ２１３で診療行為として必要であると特定されているものについてのみデータを作成する。この点は、以下の第２、第４、第５、第６、及び、第７のサービス別件数データ作成処理においても同じである。
In each of these processes of FIGS. 15 and 16, the cost accumulation pattern setting
（処理内容−直課不可分処理−サービス別件数データ作成処理−第２データ作成処理）
次に、第２データ作成処理について説明する。図１７は第２データ作成処理のデータの構成例及びフローを示す図である。この処理では、患者別サービスデータＤＢ２５８より、特定保険医療材料を抽出し、サービス別件数データＤＢ２６０に出力する。具体的には、患者別サービスデータＤＢ２５８に含まれる患者ＩＤ、日付、部門コード、医事内部コードを、サービス別件数データＤＢ２６０における患者ＩＤ、日付、部門コード、原価積上コードとして相互に関連付けて出力する。また、患者別サービスデータＤＢ２５８の医事内部コードに基づいて特定保険医療材料マスタＤＢ２１７を参照し、当該医事内部コードに対応する特保医材コードを、原価積上名称としてサービス別件数データＤＢ２６０に出力する。これにて第２データ作成処理を終了する。
(Processing content-Directly inseparable processing-Number-of-services data creation processing by service-Second data creation processing)
Next, the second data creation process will be described. FIG. 17 is a diagram showing a data configuration example and flow of the second data creation processing. In this process, specific insurance medical materials are extracted from the patient-specific
（処理内容−直課不可分処理−サービス別件数データ作成処理−第３データ作成処理）
次に、第３データ作成処理について説明する。図１８は第３データ作成処理のデータの構成例及びフローを示す図である。この処理では、患者入院データＤＢ２５６より、患者の日別病室情報を抽出し、サービス別件数データＤＢ２６０に出力する。具体的には、患者入院データＤＢ２５６に含まれる患者ＩＤ、部門コード（病棟）、病室コードを、サービス別件数データＤＢ２６０における患者ＩＤ、部門コード、原価積上コードとして相互に関連付けて出力する。また、患者入院データＤＢ２５６の病室コードに基づいて病室別床面積情報を参照し、当該病室コードに対応する病室名を原価積上名称としてサービス別件数データＤＢ２６０に出力する。また、患者入院データＤＢ２５６の入院日及び転入日を日別に展開し、日付としてサービス別件数データＤＢ２６０に出力する。なお、サービス別件数データＤＢ２６０の件数は１に固定する。病室別床面積情報は、例えば、メンテナンス端末４０を介して管理者が手入力した病院別床面積情報を、列定義に従ってマッピング作業を行い、原価積上マスタＤＢ２１１に登録しておく。これにて第３データ作成処理を終了する。
(Processing content-Directly inseparable processing-Number-of-services data creation processing by service-Third data creation processing)
Next, the third data creation process will be described. FIG. 18 is a diagram illustrating a data configuration example and flow of the third data creation process. In this process, the patient's daily room information is extracted from the patient
（処理内容−直課不可分処理−サービス別件数データ作成処理−第４データ作成処理）
次に、第４データ作成処理について説明する。図１９は第４データ作成処理のデータの構成例及びフローを示す図である。この処理では、職員別患者別時間比情報ＤＢ２５５より、患者カルテ参照時間を抽出し、サービス別件数データＤＢ２６０に出力する。具体的には、医師別患者別時間比情報に含まれる患者ＩＤ、日付、部門コード、職員ＩＤを、サービス別件数データＤＢ２６０における患者ＩＤ、日付、部門コード、原価積上コードとして相互に関連付けて出力する。また、医師別患者別時間比情報の職員ＩＤに対応する職員名を職員情報ＤＢ２５２から取得し、この職員名を原価積上名称として出力する。これにて第４データ作成処理を終了する。
(Processing content-Directly indivisible processing-Number-of-services data creation processing by service-Fourth data creation processing)
Next, the fourth data creation process will be described. FIG. 19 is a diagram illustrating a data configuration example and flow of the fourth data creation process. In this process, the patient chart reference time is extracted from the staff-specific patient-specific time
（処理内容−直課不可分処理−サービス別件数データ作成処理−第５データ作成処理）
次に、第５データ作成処理について説明する。図２０は第５データ作成処理のデータの構成例及びフローを示す図である。この処理では、患者別手術データＤＢ２５７より、患者手術執刀時間を抽出し、サービス別件数データＤＢ２６０に出力する。具体的には、患者別手術データＤＢ２５７に含まれる患者ＩＤ、日付、職員ＩＤを、サービス別件数データＤＢ２６０における患者ＩＤ、日付、原価積上コードとして相互に関連付けて出力する。また、患者別手術データＤＢ２５７の職員ＩＤに対応する職員名を職員情報ＤＢ２５２から取得し、この職員名を原価積上名称として出力する。なお、サービス別件数データＤＢ２６０の部門コードは手術室に割り当てられた所定の部門コードに固定する。これにて第５データ作成処理を終了する。
(Processing content-Directly indivisible processing-Number-of-services data creation processing by service-Fifth data creation processing)
Next, the fifth data creation process will be described. FIG. 20 is a diagram illustrating a data configuration example and flow of the fifth data creation process. In this process, the patient operation time is extracted from the patient-specific
（処理内容−直課不可分処理−サービス別件数データ作成処理−第６データ作成処理）
次に、第６データ作成処理について説明する。図２１は第６データ作成処理のデータの構成例及びフローを示す図である。この処理では、患者別手術データＤＢ２５７より、患者手術在室時間を抽出し、サービス別件数データＤＢ２６０に出力する。具体的には、患者別手術データＤＢ２５７に含まれる患者ＩＤ、日付を、サービス別件数データＤＢ２６０における患者ＩＤ、日付として相互に関連付けて出力する。また、患者別手術データＤＢ２５７の手術時間の積算値を件数（ここでは「件数」と称しているが実際には時間値）として出力する。また、原価積上マスタＤＢ２１１の原価積上コード、原価積上名称を、サービス別件数データＤＢ２６０における原価積上コード、原価積上名称として出力する。なお、サービス別件数データＤＢ２６０の原価積上コードは手術室に割り当てられた所定の部門コードに固定する。これにて第６データ作成処理を終了する。
(Processing content-Directly indivisible processing-Number-of-services data creation processing by service-Sixth data creation processing)
Next, the sixth data creation process will be described. FIG. 21 is a diagram showing a data configuration example and flow of the sixth data creation process. In this process, the patient operation occupancy time is extracted from the patient
（処理内容−直課不可分処理−サービス別件数データ作成処理−第７データ作成処理）
次に、第７データ作成処理について説明する。図２２は第７データ作成処理のデータの構成例及びフローを示す図である。この処理では、患者食数データＤＢ２５９より、患者の日別食数情報を抽出し、サービス別件数データＤＢ２６０に出力する。具体的には、患者食数データＤＢ２５９に含まれる年月、患者ＩＤ、各食数データに基づいて、各日別の食数を特定し、各日毎に、年月、患者ＩＤ、各日別の食数を相互に関連付けて出力する。すなわち、患者食数データＤＢ２５９の各データには、各月毎に、先頭のレコードには１日目の食数、２番目のレコードには２日目の食数・・・最終のレコードには月末に該当する日の食数が格納されているので、これを各月日毎のデータに展開する。また、患者食数データＤＢ２５９の患者ＩＤに対応する部門コードを、先の第３データ作成処理にて出力したサービス別件数データＤＢ２６０から取得して、本処理のサービス別件数データＤＢ２６０に出力する。また、原価積上マスタＤＢ２１１の原価積上コード、原価積上名称を、サービス別件数データＤＢ２６０における原価積上コード、原価積上名称として出力する。これにて第７データ作成処理を終了する。
(Processing content-Directly indivisible processing-Number-of-services data creation processing by service-Seventh data creation processing)
Next, the seventh data creation process will be described. FIG. 22 is a diagram illustrating a data configuration example and flow of the seventh data creation process. In this process, the daily meal number information of the patient is extracted from the patient meal
（処理内容−直課不可分処理−サービス別件数データ作成処理−第８データ作成処理）
次に、第８データ作成処理について説明する。図２３〜２５は第８データ作成処理のデータの構成例及びフローを示す図である。この処理では、図１０と同様に、医事会計システム１３より収集した医事明細情報Ｉ／Ｆについて、所定の列定義に従ったマッピング作業を行い、患者別サービスデータＤＢ２５８に登録する。そして、図１５、１６と同様に、患者別サービスデータＤＢ２５８から、診療行為積上対象マスタＤＢ２２０や診療行為マスタＤＢ２１９を参照して、患者診療行為データを抽出し、サービス別件数データＤＢ２６０に登録する。次いで、図２３に示すように、サービス別件数データＤＢ２６０を原価積上コードを除いて集計する。また、原価積上マスタＤＢ２１１の原価積上コード、原価積上名称を、サービス別件数データＤＢ２６０における原価積上コード、原価積上名称として出力する。件数は１に固定する。このように作成されたサービス別件数データ（以下、中間サービス別件数データ）を用いて、医療技術系用の患者数のサービス別件数データと、病院共通用の患者数のサービス別件数データとを作成する。医療技術系用のデータについては、図２４に示すように、原価部門マスタＤＢ２１４を参照して、部門種別「病棟」に対応する部門コードを特定し、この部門コードを含む中間サービス別件数データを抽出し、当該抽出した中間サービス別件数データを部門コードを除いて集計することにより作成する。部門コードは、医療技術系に固定する。病院共通用のデータについては、図２５に示すように、中間サービス別件数データを部門コードを除いて集計する。部門コードは、病院共通に固定する。これにて第８データ作成処理を終了し、全てのサービス別件数データ作成処理が終了する。
(Processing content-Directly indivisible processing-Number-of-services data creation processing by service-Eighth data creation processing)
Next, the eighth data creation process will be described. 23 to 25 are diagrams illustrating a data configuration example and a flow of the eighth data creation process. In this process, as in FIG. 10, the medical statement information I / F collected from the
（処理内容−直課不可分処理−積上係数計算処理）
次に、図３（ａ）に示した積上係数計算処理の具体的内容について説明する。この処理は、主として積上係数計算部３０３により実行される。この処理は、診療行為型処理、原価積上係数型処理、サービス別件数型処理の３つに大別される。診療行為型処理及び原価積上係数型処理では、予めマスタに設定された重み付けを参照して積上係数計算を行うのに対して、サービス別件数型処理では、予めマスタに設定された重み付けが存在せず、サービス別件数の件数を使用して積上係数計算を行う。ただし、診療行為型処理と原価積上係数型処理とでは、参照するマスタが異なること、及び、委託区分の参照の有無の処理が異なるため、相互に別処理としている。
(Processing content-Directly indivisible processing-Rolling coefficient calculation processing)
Next, the specific content of the calculation coefficient calculation process shown in FIG. This process is mainly executed by the product
（処理内容−直課不可分処理−積上係数計算処理−診療行為型処理）
まず、診療行為型処理について説明する。図２６は診療行為型処理のデータの構成例及びフローを示す図である。ここでは、前提として、積上係数マスタＤＢ２２１に、各診療行為の少なくとも一部に対応する積上係数として、本システム１が利用される医療機関毎に定められた積上係数、あるいは、公的機関等の定めた等価係数が予め格納されているものとする。そして、この診療行為型処理では、積上係数マスタＤＢ２２１に積上係数が未だ設定されていない診療行為（例えば、中央診療部門で実施される所定の診療行為（検査、画像診断、手術））についてのみ積上係数を計算し、この積上係数を積上係数マスタＤＢ２２１に登録する。
(Processing content-Directly indivisible processing-Rolling coefficient calculation processing-Medical practice type processing)
First, the medical practice type process will be described. FIG. 26 is a diagram illustrating a configuration example and a flow of data of medical practice type processing. Here, as a premise, in the increase
具体的には、サービス別件数データＤＢ２６０に含まれる各レコードの部門コード及び原価積上コードに基づいて積上係数マスタＤＢ２２１を参照し、これら部門コード及び原価積上コードに対応するレコードが積上係数マスタＤＢ２２１に既に存在するか否かを判定する。このようなレコードが存在する場合には、当該レコードに積上係数が既に登録されているので、積上係数の登録は不要である。
Specifically, the roll-up
一方、このようなレコードが存在しない場合には、サービス別件数データＤＢ２６０に含まれる部門コード、原価積上コードを、積上係数マスタＤＢ２２１における部門コード、原価積上コードとして相互に関連付けて出力する。また、サービス別件数データＤＢ２６０に含まれる原価積上コードに基づいて診療行為マスタＤＢ２１９を参照し、原価積上コードを診療行為コードとして保持するレコードのコード表番号及び点数を取得して、これらコード表番号及び点数に基づいて積上係数特定処理を行なうことで積上係数を計算して、積上係数マスタＤＢ２２１に登録する。
On the other hand, when such a record does not exist, the department code and the cost accumulation code included in the service-specific
（処理内容−直課不可分処理−積上係数計算処理−診療行為型処理−積上係数特定処理）
図２６の積上係数特定処理のフローチャートを図２７に示す。この処理では、診療行為マスタＤＢ２１９から取得したコード表番号に基づいて積上係数を計算する。具体的には、診療行為マスタＤＢ２１９の委託区分を参照し、原価積上パタ−ンが検査委託費の時において（ステップＳＡ−１、Ｙｅｓ）、委託区分が「委託」である場合には（ステップＳＡ−２、Ｙｅｓ）、積上係数＝当該診療行為の点数とし（ステップＳＡ−３）、委託区分が「委託」でない場合（「院内」である場合）には（ステップＳＡ−２、Ｎｏ）、積上係数＝０とする（ステップＳＡ−４）。また、原価積上パタ−ンが検査委託費以外の時において（ステップＳＡ−１、Ｎｏ）、委託区分が「委託」である場合には（ステップＳＡ−５、Ｙｅｓ）、積上係数＝０とし（ステップＳＡ−４）、委託区分が「委託」でない場合には（ステップＳＡ−５、Ｎｏ）、積上係数＝当該診療行為の点数とする（ステップＳＡ−３）。これは、検査委託費を院内に委託した場合の当該検査委託費や、他の費用を院外に委託した場合の検査委託費は実際には０だからである。このように積上係数を特定した後、当該積上係数を積上係数マスタＤＢ２２１に登録して、当該積上係数計算処理が終了する。そして、図２６に示すように、この積上係数計算処理で特定した積上係数を、積上係数マスタＤＢ２２１に登録して、診療行為型処理が終了する。
(Processing content-Directly indivisible processing-Rolling coefficient calculation processing-Medical practice type processing-Rolling coefficient identification processing)
FIG. 27 shows a flowchart of the increase coefficient specifying process in FIG. In this process, a roll-up coefficient is calculated based on the code table number acquired from the medical
なお、図２６の診療行為型処理では、積上係数マスタＤＢ２２１に積上係数が予め格納されているものとして説明したが、当該積上係数を新規に算定したり、初期値として設定された当該積上係数を更新することも可能である。例えば、図２８に示すように、算定対象の医療行為（ここでは手術Ａとする）の積上係数は、当該手術Ａの１回当たりの費用を、算定基準になる特定のサービスの１回当たりの費用（積上係数基準費用）で除算することで算定される。手術Ａの１回当たりの費用は、当該手術Ａを行うために用する各種の費用（例えば、給与費と設備関係費）を総計することで算定される。
In the medical practice type processing of FIG. 26, it has been described that the increase coefficient is stored in advance in the increase
手術Ａの１回当たりの給与費は、当該手術Ａに関与する各医療関係者の平均的な１回当たりの所要時間と、当該医療関係者の時給とを乗算することで算定される。例えば、医療関係者として、医師、看護師、技師の三者が関与する場合には、給与費＝（医師の平均的な１回当たりの執刀時間×医師の時給）＋（看護師の平均的な１回当たりの手術時間×看護師の時給）＋（技師の平均的な１回当たりの所要時間×技師の時給）となる。 The salary cost per operation A is calculated by multiplying the average required time of each medical person involved in the operation A by the hourly wage of the medical person. For example, when three people, a doctor, a nurse, and an engineer, are involved as medical personnel, salary cost = (average doctor operating time x doctor hourly salary) + (average nurse salary) 1 operation time x nurse's hourly wage) + (average time required per engineer x hourly wage of the technician).
手術Ａの１回当たりの設備関係費は、当該手術Ａの１回当たりにおける、医療用器械備品減価償却費、医療用器械備品賃借料、医療用器械備品修繕費、医療用器械備品保守料、及び、器械備品保険料を総計することで算定される。例えば、当該手術Ａの１回当たりにおける医療用器械備品減価償却費は、当該手術Ａに使用している全ての医療機器の１回当たりにおける医療用器械備品減価償却費を総計することで算定される。医療機器の１回当たりにおける医療用器械備品減価償却費は、当該手術Ａに使用している全ての医療機器のサービス別の原価償却費の総和として算定される。この手術Ａに使用している全ての医療機器のサービス別の原価償却費の総和は、図２８の式（１）にて算定される。これら各算定に使用する情報は、関連システム群１０やこれまでに登録したサービス別件数データＤＢ２６０から取得することができ、あるいは、このように取得した情報に基づいて算定することができる。例えば、医師の時給は、関連システム群１０の人事給与システム１５から取得でき、医師の平均的な１回当たりの執刀時間は、手術管理システム１９から取得することができ、医療用器械備品減価償却費は固定資産システム１７から取得することができる。このように積上係数を算定することで、原価の観点からの診療行為毎の重みの相違を反映させた原価算定を行うことができる。
The equipment-related costs per operation A are the medical equipment and equipment depreciation expenses, medical equipment and equipment rent, medical equipment and equipment repair costs, and medical equipment and equipment maintenance fees per operation A. And it is calculated by totaling the equipment and equipment insurance premiums. For example, the depreciation cost for medical instrument equipment per operation A is calculated by adding up the depreciation expenses for medical instrument equipment per operation for all medical devices used in operation A. The The medical instrument equipment depreciation cost per medical device is calculated as the sum of the cost amortization costs for each medical device service used for the operation A. The total cost amortization cost for each medical device used for this operation A is calculated by equation (1) in FIG. The information used for each calculation can be acquired from the
（処理内容−直課不可分処理−積上係数計算処理−原価積上係数型処理）
次に、図３（ａ）に示した原価積上係数型処理について説明する。図２９は原価積上係数型処理（特定保険医療材料の場合）のデータの構成例及びフローを示す図、図３０は原価積上係数型処理（ベッド面積の場合）のデータの構成例及びフローを示す図である。この処理では、原価積上マスタＤＢ２１１の係数を基本に積上係数を計算する。
(Processing-Directly Indivisible Processing-Rolling Factor Calculation Processing-Cost Rolling Factor Type Processing)
Next, the cost accumulation coefficient type process shown in FIG. FIG. 29 is a diagram illustrating a data configuration example and a flow of cost increase coefficient type processing (in the case of specific insurance medical materials), and FIG. 30 is a data configuration example and flow of cost increase coefficient type processing (in the case of bed area) FIG. In this process, the cost coefficient is calculated based on the coefficient of the cost
具体的には、特定保険医療材料の積上係数を算定する場合、図２９に示すように、サービス別件数データＤＢ２６０に含まれる部門コードを、積上係数マスタＤＢ２２１の部門コードとして設定する。また、サービス別件数データＤＢ２６０に含まれる原価積上コードに基づいて特定保険医療材料マスタＤＢ２１７を参照し、原価積上コードを特保医材コードとして保持するレコードの特保医材コード及び単位点数を取得して、これらを原価積上コード及び積上係数として積上係数マスタＤＢ２２１に登録する。
Specifically, when calculating the increase coefficient of the specific insurance medical material, as shown in FIG. 29, the department code included in the service-specific number-of-
ベッド面積の積上係数を算定する場合、図３０に示すように、サービス別件数データＤＢ２６０に含まれる部門コードを、積上係数マスタＤＢ２２１の部門コードとして設定する。また、サービス別件数データＤＢ２６０に含まれる原価積上パターンコード及び原価積上コードに基づいて原価積上マスタＤＢ２１１を参照し、これら原価積上パターンコード及び原価積上コードを保持するレコードの原価積上パターンコード、原価積上コード、及び、原価積上係数を取得して、これらを原価積上パターンコード、原価積上コード、及び、積上係数として積上係数マスタＤＢ２２１に登録する。これにて原価積上係数型処理が終了する。
When calculating the roll-up coefficient of the bed area, as shown in FIG. 30, the department code included in the service-specific
（処理内容−直課不可分処理−積上係数計算処理−サービス別件数型処理）
次に、図３（ａ）に示したサービス別件数型処理について説明する。図３１はサービス別件数型処理のデータの構成例及びフローを示す図である。この処理では、サービス別件数データＤＢ２６０の件数を基本に積上係数を計算する。具体的には、サービス別件数データＤＢ２６０に含まれる原価積上パターンコード、部門コード、原価積上コードを、積上係数マスタＤＢ２２１の原価積上パターンコード、部門コード、原価積上コードとして設定する。また、サービス別件数データＤＢ２６０に含まれる件数を合計した数を、積上係数として積上係数マスタＤＢ２２１に登録する。なお、このように件数の合計を積上係数とするのは、以下の理由による。すなわち、本来であれば合計の逆数が積上係数になるが、逆数とすると計算処理上の誤差が大きくなるので、ここでは合計値として求めておき、後述するサービス単位原価計算処理において当該合計値を除算の分母に用いることとしている。これにてサービス別件数型処理が終了し、全ての積上係数計算処理が終了する。
(Processing-Directly indivisible processing-Rolling coefficient calculation processing-Number-of-services processing by service)
Next, the number-of-services type process by service shown in FIG. FIG. 31 is a diagram illustrating a configuration example and a flow of data of the number-of-services type processing. In this process, the roll-up coefficient is calculated based on the number of cases in the service-specific case
（処理内容−直課不可分処理−直課不可分計算処理）
次に、図３（ａ）に示した直課不可分計算処理の具体的内容について説明する。この処理は、主として直課不可分計算部３０４により実行される。
(Processing content-Directly indivisible processing-Directly indivisible calculation processing)
Next, the specific contents of the direct charge indivisible calculation process shown in FIG. This process is mainly executed by the direct
（処理内容−直課不可分処理−直課不可分計算処理−サービス単位原価計算処理）
まず、図３（ａ）に示すサービス単位原価計算処理について説明する。図３２、３３はサービス単位原価計算処理のデータの構成例及びフローを示す図である。この処理では、図３２に示すように、原価積上パターン設定マスタＤＢ２１３を参照し、原価積上パターン設定の部門毎科目毎に、各原価積上パターンに応じて、積上係数を元にサービス単位原価を作成する。具体的には、原価積上パターン設定マスタＤＢ２１３に含まれる原価積上パターンコードに対応する係数計算区分を原価積上パターンマスタＤＢ２１２から取得する。また、原価積上パターン設定マスタＤＢ２１３に含まれる部門コード及び原価積上パターンコードに基づいてサービス別件数データＤＢ２６０を参照し、これら部門コード及び原価積上パターンコードの組み合わせに合致するレコードから件数を取得すると共に、このレコードに含まれる原価積上コードに対応する積上係数を積上係数マスタＤＢ２２１から取得する。
(Processing content-Directly indivisible processing-Directly indivisible calculation processing-Service unit cost calculation processing)
First, the service unit cost calculation process shown in FIG. 32 and 33 are diagrams showing a configuration example and a flow of data of service unit cost calculation processing. In this process, as shown in FIG. 32, the service refers to the cost accumulation pattern setting
次いで、図３３に示すように、原価積上パターン設定マスタＤＢ２１３に含まれる部門コード及び原価積上パターンコードに基づいて積上対象データＤＢ２６２を参照し、これら部門コード及び原価積上パターンコードの組み合わせに合致するレコードから積上金額を取得する。
Next, as shown in FIG. 33, referring to the
その後、図３（ａ）に示すように、原価積上パターンマスタＤＢ２１２から取得した係数計算区分に応じて、診療行為型及び原価積上係数型処理、タイムスタディ参照処理、積上対象データ参照処理のいずれかの処理を行うことで、サービス単位原価を算出する。このうち、診療行為型及び原価積上係数型処理では、診療行為型処理（図２６）や原価積上係数型処理（図２９）によって積上係数マスタＤＢ２２１に格納された積上係数を用いて原価計算を行う。タイムスタディ参照処理及び積上対象データ参照処理では、サービス別件数型処理（図３１）によって積上係数マスタＤＢ２２１に格納された積上係数を用いて原価計算を行うが、時間情報や数量情報を積上げることで単純に原価計算を行うことができるものは積上対象データ参照処理として原価計算を行い、単純に原価計算を行うことができないもの（後述する「積上対象データの補正」が必要になり得るもの）についてはタイムスタディ参照処理として原価計算を行う。
Thereafter, as shown in FIG. 3 (a), according to the coefficient calculation classification acquired from the cost accumulation
（処理内容−直課不可分処理−直課不可分計算処理−診療行為型及び原価積上係数型処理）
まず、診療行為型及び原価積上係数型処理について説明する。図３４は診療行為型及び原価積上係数型処理の構成例及びフローを示す図である。この処理では、原価積上パターン設定マスタＤＢ２１３を参照し、原価積上パターンの係数計算区分が診療行為型と原価積上係数型である各診療行為について、積上係数を元にサービス単位原価を作成する。具体的には、算定対象とする診療行為Ａについてのサービス単位原価＝当該診療行為Ａが属する部門コード及び科目コードの積上金額×診療行為Ａの積上係数／（当該診療行為Ａが属する部門の各診療行為についての積上係数×当該各診療行為についての実施件数を、当該診療行為Ａが属する部門の全ての診療行為について積算した値）とする。
(Processing content-Directly indivisible processing-Directly inseparable calculation processing-Medical practice type and cost increase factor type processing)
First, the medical practice type and cost increase coefficient type processing will be described. FIG. 34 is a diagram showing a configuration example and a flow of the medical practice type and cost increase coefficient type processing. In this process, referring to the cost accumulation pattern setting
例えば、図３５に示すように、部門が手術室であり、手術室の積上金額が１００万円であり、当該部門に属する診療行為が創傷処理、皮膚・皮下腫瘍摘出術、ヘルニア手術、骨髄移植であり、これらそれぞれの積上係数が１．５０、０．５０、１．００、２．００であり、これらそれぞれの実施件数が２０件、３０件、４５件、５件であった場合において、これらそれぞれのサービス単位原価は、１５，０００円、５，０００円、１０，０００円、２０，０００円と算定される。このように算定したサービス単位原価と、算定に使用した積上係数は、サービス単位原価データＤＢ２６１にサービス単位原価、算出時積上係数として格納される。
For example, as shown in FIG. 35, the department is an operating room, and the operating room has an accumulated amount of 1 million yen, and the medical practice belonging to the department includes wound treatment, skin / subcutaneous tumor extraction, hernia surgery, bone marrow When transplantation is performed, and each of these factors is 1.50, 0.50, 1.00, 2.00, and the number of implementations for each is 20, 30, 45, and 5 The service unit costs are calculated as 15,000 yen, 5,000 yen, 10,000 yen, and 20,000 yen. The service unit cost calculated in this way and the increase coefficient used for the calculation are stored in the service unit
（処理内容−直課不可分処理−直課不可分計算処理−タイムスタディ参照処理）
次に、図３（ａ）に示すタイムスタディ参照処理について説明する。図３６、３７はタイムスタディ参照処理の構成例及びフローを示す図である。この処理では、原価積上パターン設定マスタＤＢ２１３を参照し、原価積上パターンの係数計算区分がサービス別件数型（タイムスタディ参照）のパターンについて、積上係数を元にサービス単位原価を作成する。具体的には、図３６に示すように、原価積上パターンの係数計算区分がカルテ参照時間である場合には、所定の算出式により、積上係数計算処理で抽出した全ての原価積上コード（職員ＩＤ）毎にサービス単位原価を作成する。すなわち、原価積上パターン設定マスタＤＢ２１３に含まれる部門コード及び科目コードに対応する職員ＩＤ及び金額を職員タイムスタディ情報ＤＢ２５４から取得し、当該取得した職員ＩＤと原価積上パターン設定マスタＤＢ２１３に含まれる部門コード及び原価積上パターンコードとに対応する積上係数を積上係数マスタＤＢ２２１から取得し、当該取得した積上係数で、職員タイムスタディ情報ＤＢ２５４から取得した金額（人件費）を除算することで、サービス単位原価を算定する。このように算定したサービス単位原価と、算定に使用した積上係数は、サービス単位原価データＤＢ２６１にサービス単位原価、算出時積上係数として格納される。
(Processing content-Directly inseparable processing-Directly inseparable calculation processing-Time study reference processing)
Next, the time study reference process shown in FIG. 36 and 37 are diagrams showing a configuration example and a flow of the time study reference process. In this process, with reference to the cost accumulation pattern setting
ただし、上記算定方法で処理できない場合には、図３７に示すように、積上対象データの補正を行った後、上述した診療行為型及び原価積上係数型処理によって、サービス単位原価を算定する。上記算定方法で処理できない場合とは、「積上対象データの補正」が必要になり得る場合である。すなわち、人件費が発生しているにも関わらず医事会計システム１３において計上されていない場合（例えば、研修医に対しても給与が支払われているので人件費は発生しているが、主治医ではない為、医事会計システム１３では計上されない）。ここでは、このような場合に該当するか否かを、積上係数マスタＤＢ２２１と職員タイムスタディ情報ＤＢ２５４とを参照することで特定する。これらに該当する場合、原価積上パターン設定マスタＤＢ２１３に含まれる部門コード及び原価積上コードに対応する原価積上コード（職員ＩＤ）を積上係数マスタＤＢ２２１から取得し、当該取得した職員ＩＤと、原価積上パターン設定マスタＤＢ２１３に含まれる部門コード及び科目コードとに対応する金額を、職員タイムスタディ情報ＤＢ２５４から取得する。そして、当該取得した金額を職員タイムスタディ情報ＤＢ２５４の年月、科目コード、及び、部門コードに対応する積上金額から減算することで、当該積上金額を補正する。そして、補正された積上対象データＤＢ２６２を元にして、上述した診療行為型及び原価積上係数型処理を行ってサービス単位原価を算定し、当該算定したサービス単位原価と、算定に使用した積上係数を、サービス単位原価データＤＢ２６１にサービス単位原価、算出時積上係数として格納する。
However, if it cannot be processed by the above calculation method, as shown in FIG. 37, after correcting the data to be accumulated, the service unit cost is calculated by the above-mentioned medical practice type and cost accumulation factor type processing. . The case where the above calculation method cannot be used is a case where “correction of data to be accumulated” may be necessary. That is, when personnel expenses are incurred but are not recorded in the medical accounting system 13 (for example, salary is paid to the trainee, labor costs are incurred, It is not counted in the medical accounting system 13). Here, whether or not this is the case is specified by referring to the product
（処理内容−直課不可分処理−直課不可分計算処理−積上対象データ参照処理）
次に、図３（ａ）に示す積上対象データ参照処理について説明する。図３８は積上対象データ参照処理の構成例及びフローを示す図である。この処理では、原価積上パターン設定マスタＤＢ２１３を参照し、原価積上パターンの係数計算区分がサービス別件数型（積上対象データ参照）のパターンについて、積上係数を元にサービス単位原価を作成する。具体的には、原価積上パターン設定マスタＤＢ２１３の部門コード及び科目コードに対応する積上金額を積上対象データＤＢ２６２から取得する。また、原価積上パターン設定マスタＤＢ２１３の部門コード及び原価積上パターンコードに対応する積上係数を積上係数マスタＤＢ２２１から取得する。そして、当該取得した積上金額を当該取得した積上係数で除算することで、サービス単位原価を算定する。このように算定したサービス単位原価と、算定に使用した積上係数は、サービス単位原価データＤＢ２６１にサービス単位原価、算出時積上係数として格納される。これにて直課不可分計算処理が終了し、全ての直課不可分処理が終了する。
(Processing content-Directly inseparable processing-Directly inseparable calculation processing-Reference data reference processing)
Next, the accumulation target data reference process shown in FIG. FIG. 38 is a diagram illustrating a configuration example and a flow of the loading target data reference processing. In this process, with reference to the cost accumulation pattern setting
（処理内容−直課分処理）
次に、図３（ｂ）の直課分原価を算定するための直課分処理について説明する。ただし、特記なき処理については、直課不可分処理と同様の処理を行うことができる。
(Processing content-Direct processing)
Next, the direct charge processing for calculating the direct charge in FIG. 3B will be described. However, for the processing without special mention, the same processing as the direct-indivisible processing can be performed.
（処理内容−直課分処理−Ｉ／Ｆ取込処理）
まず、図３（ｂ）に示したＩ／Ｆ取込処理の具体的内容について説明する。この処理は、主としてＩ／Ｆ取込処理部３０１により実行される。以下ではＩ／Ｆ取込処理に含まれる各処理について順次説明する。
(Processing content-Direct processing-I / F import processing)
First, the specific contents of the I / F acquisition process shown in FIG. This process is mainly executed by the I / F
（処理内容−直課分処理−Ｉ／Ｆ取込処理−物品マスタ取込処理）
まず、物品マスタ取込処理について説明する。図３９、４０は物品マスタ取込処理のデータの構成例及びフローを示す図である。この処理では、物流システム１６より収集した物品マスタＩ／Ｆを、所定の列定義に従ったマッピング作業を行い、物品マスタＤＢ２２２及び他システム物品マスタＤＢ２２３に登録する。また、医事会計システム１３より収集した医事点数マスタＩ／Ｆより、収集した物品に対して物品のマッチングを行い、物品マスタＤＢ２２２に医事請求金額を登録する。具体的には、図３９に示すように、物品マスタＩ／Ｆの各データを、それぞれ物品マスタＤＢ２２２に登録する。ただし、物品マスタＩ／Ｆの科目コードについては、登録する原価科目を判定し、当該判定された原価科目に応じた科目コードを登録する。この判定は、取込対象の種類（例えば医薬品又は材料）毎に予め設定された分類コードと原価科目との対応テーブル（図示省略）を用いて行い、物品マスタＩ／Ｆの分類コードに対応する原価科目を当該対応テーブルを参照して特定する。また、医事単位変換換算については、医事点数マスタＩ／Ｆの内部コードの所定桁数部分のみを抽出して登録する。また、図４０に示すように、このように登録した物品マスタＤＢ２２２に含まれるデータのうち、システム種別、物品名を、他システム物品マスタＤＢ２２３におけるシステム種別、他システム物品名として登録する。物品マスタＤＢ２２２の物品コードについては、他システム物品マスタＤＢ２２３における他システム物品コード及び物品コードとして登録し、他システム種別、他システム単位換算については、それぞれ手術管理システムと１に固定する。これにて物品マスタ取込処理が終了する。
(Processing content-Direct processing-I / F acquisition processing-Article master acquisition processing)
First, the article master take-in process will be described. 39 and 40 are diagrams showing a configuration example and a flow of data of the article master take-in process. In this process, the article master I / F collected from the
（処理内容−直課分処理−Ｉ／Ｆ取込処理−他システム物品マスタ取込処理）
次に、他システム物品マスタ取込処理について説明する。図４１、４２は他システム物品マスタ取込処理のデータの構成例及びフローを示す図である。この処理では、医事会計システム１３より収集した医事点数マスタＩ／Ｆを、所定の列定義に従ったマッピング作業を行い、他システム物品マスタＤＢ２２３に登録する。具体的には、医薬品の場合には、図４１に示すように、医事点数マスタＩ／Ｆの中から、データ区分が医薬品であるデータを抽出し、当該抽出したデータの内部コード、表示名称、入力単位を、他システム物品マスタＤＢ２２３の他システム物品コード、他システム物品名、他システム単位として登録する。他システム物品マスタＤＢ２２３の他システム種別と他システム単位換算は、それぞれ「医事ＤＰＣシステム」と「１」に固定する。他システム物品マスタＤＢ２２３のシステム種別は、薬品管理システムに固定する。他システム物品マスタＤＢ２２３の物品コードには、医事点数マスタＩ／Ｆの個別医薬品コードを登録する。また、材料の場合にも、図４１とほぼ同様であるが、図４２に示すように、他システム物品マスタＤＢ２２３のシステム種別は、医事ＤＰＣシステムに固定し、他システム物品マスタＤＢ２２３の物品コードには、医事点数マスタＩ／Ｆの内部コードを登録する。これにて物品マスタ取込処理が終了し、全てのＩ／Ｆ取込処理が終了する。
(Processing content-Direct processing-I / F acquisition processing-Other system article master acquisition processing)
Next, the other system article master taking process will be described. 41 and 42 are diagrams showing a configuration example and a flow of data of another system article master take-in process. In this process, the medical score master I / F collected from the
（処理内容−直課分処理−直課計算処理）
まず、図３（ｂ）に示した直課計算処理の具体的内容について説明する。この処理は、主として直課計算部３０５により実行される。以下では直課計算処理に含まれる各処理について順次説明する。
(Processing content-Direct processing-Direct calculation processing)
First, the specific contents of the direct calculation process shown in FIG. This process is mainly executed by the
（処理内容−直課分処理−購入価格算出処理）
まず、購入価格算出処理について説明する。この処理では、物品マスタＤＢ２２２に登録済みの物品について購入価格を算出する。ここで、算出対象物品が医薬品である場合には、個別医薬品コード単位に購入価格を算出し、個別医薬品コード単位に、物品マスタＤＢ２２２にデータを生成する。一方、算出対象物品が材料である場合には、医事コード単位に購入価格を算出し、医事コード単位に、物品マスタＤＢ２２２にデータを生成する。
(Processing content-direct processing-purchase price calculation processing)
First, the purchase price calculation process will be described. In this process, a purchase price is calculated for an article registered in the
図４３は医薬品の購入価格算出処理のデータの構成例及びフローを示す図である。具体的には、物品マスタＤＢ２２２に登録済みの医薬品については、「その他コード１〜５」に当該医薬品のＪＡＮ（Japanese Article Number）コードが設定されているので、「その他コード１」から「その他コード５」まで順に、各ＪＡＮコードに対応する個別医薬品コードを標準医薬品マスタＤＢ２２４から取得する。そして、取得した個別医薬品コード単位で、個別医薬品単位の購入価格を算出すると共に、物品マスタＤＢ２２２へのデータの追加を行う。この際、個別医薬品コードを物品コードとして登録する。また、物品コードは、所定コード（ここでは薬品管理システム）に固定する。個別医薬品単位の購入価格の算出は、当該医薬品の（購入数×購入単位単価）の総和／当該医薬品の（購入数×最小単位換算×医事単位変換換算）の総和により行う。当該医薬品の全ての購入数が０である場合には、購入数は１として計算する。このような算定を行うことで、医薬品の購入実績に応じた単価を算定することが可能になる。
FIG. 43 is a diagram illustrating a configuration example and a flow of data of a drug purchase price calculation process. Specifically, for drugs already registered in the
図４４は材料の購入価格算出処理のデータの構成例及びフローを示す図である。具体的には、物品マスタＤＢ２２２に登録済みの材料については、「その他コード１」に当該材料の医事コードが設定されているので、この医事コード単位で、購入価格を算出すると共に、物品マスタＤＢ２２２へのデータの追加を行う。この際、医事コードを物品コードとして登録する。また、物品コードは、所定コード（ここでは医事ＤＰＣシステム）に固定する。また、医事コード単位の購入価格の算出は、上述した医薬品と同様である。このような算定を行うことで、材料の購入実績に応じた単価を算定することが可能になる。これにて購入価格算出処理が終了する。
FIG. 44 is a diagram illustrating a data configuration example and flow of the material purchase price calculation processing. Specifically, for the material registered in the
（処理内容−直課分処理−変換元材料原価計算処理）
次に、図３（ｂ）に示した変換元材料原価計算処理について説明する。図４５は変換元材料原価計算処理のデータの構成例及びフローを示す図である。この処理では、各部門システムの材料と購買上の材料のマッチングを行い、患者別物品消費データＤＢ２６３の購入価格を更新する。具体的には、物品マスタＤＢ２２２のシステム種別及び物品コードに対応する他システム種別及び他システム物品コードを他システム物品マスタＤＢ２２３から取得し、当該取得した他システム種別、他システム物品コードを患者別物品消費データＤＢ２６３におけるシステム種別、物品コードとして登録する。また、物品コードの科目コードを、患者別物品消費データＤＢ２６３における科目コードとして登録する。さらに、物品マスタＤＢ２２２の購入単位購入価と、他システム物品マスタＤＢ２２３の他システム単位換算とに基づいて、購入価格＝購入単位購入価／他システム単位換算として算定し、この購入価格を患者別物品消費データＤＢ２６３に登録する。なお、更新対象になる患者別物品消費データＤＢ２６３は、図１０の医事明細情報Ｉ／Ｆから取得した日付、患者番号、明細診区、明細金額を、患者別物品消費データの年月日、患者ＩＤ、物品コード（点数マスタＩ／Ｆを参照して変換）、購入価格として登録されたものである。ただし、物品の消費情報を一層正確に取得できるシステムがある場合には、当該システムから明細金額等を取得することが好ましい。これにて変換元材料原価計算処理が終了する。
(Processing-Direct processing-Conversion source material cost calculation processing)
Next, the conversion source material cost calculation process shown in FIG. FIG. 45 is a diagram showing a data configuration example and flow of conversion source material cost calculation processing. In this process, the material of each department system is matched with the material for purchase, and the purchase price of the patient-specific article
（処理内容−患者別原価計算処理）
最後に、図３（ｃ）に示した患者別原価計算処理の具体的内容について説明する。この処理は、主として患者別原価計算部３０６により実行されるもので、これまでの処理により算定された直課不可分と直課分とから、患者別原価の解析に必要になるデータを抜き出したデータ集合としての患者別原価計算データマートＤＢ２６５を作成する。そして、この患者別原価計算データマートＤＢ２６５を対象として、任意の視点（軸）から様々なデータの集計及び出力を行う。
(Processing-Cost calculation by patient)
Finally, the specific contents of the cost calculation process for each patient shown in FIG. This processing is mainly performed by the patient-specific
（処理内容−患者別原価計算処理−患者別原価計算データマート作成処理）
まず、患者別原価計算データマート作成処理について説明する。図４６〜５２は患者別原価計算データマート作成処理のデータの構成例及びフローを示す図である。この処理では、直課不可分原価計算や直課計算の各処理において作成したデータを、患者別原価計算データマートＤＢ２６５に追加する。
(Processing-Cost calculation processing by patient-Cost calculation data mart creation processing by patient)
First, patient-specific cost calculation data mart creation processing will be described. 46 to 52 are diagrams showing a configuration example and a flow of data of the cost calculation data mart creation processing by patient. In this process, the data created in each of the direct cost calculation and direct calculation is added to the patient-specific cost calculation
具体的には、図４６に示すように、直課不可分原価計算で作成したサービス別件数データＤＢ２６０の原価積上パターンコード、患者ＩＤ、日付、部門コード、原価積上コード、件数を、患者別原価計算データマートＤＢ２６５における原価積上パターンコード、患者ＩＤ、日付軸キー、部門コード、原価積上コード、件数として追加する。また、サービス別件数データＤＢ２６０の原価積上パターンコード、部門コード、及び、原価積上コードの組み合わせに対応するサービス単位原価をサービス単位原価データＤＢ２６１から取得し、当該取得したサービス単位原価と、サービス別件数データＤＢ２６０から取得した件数とを乗算することで収益金額を算定して、この収益金額を患者別原価計算データマートＤＢ２６５に追加する。入院日数は０に設定する。なお、図４６における"concat_key_domain"は、取得元の情報を患者別原価計算データマートＤＢ２６５に設定する際の文字列処理を示しており、病院ドメインの文字列と取得元の文字列とを結合して設定する処理であって、例えば、病院ドメインの文字列と日付の文字列とを結合して日付軸キーに設定する（後述する図５０〜５２において同じ）。
Specifically, as shown in FIG. 46, the cost accumulation pattern code, patient ID, date, department code, cost accumulation code, and number of cases in the case-by-service
また図４７に示すように、関連システム群１０、部門別原価計算サーバ３０、あるいは、手入力により収集した患者直課データＩ／Ｆから、原価部門変換マスタＤＢ２１５及び原価科目変換マスタＤＢ２１６を参照して、患者別直課データＤＢ２６８を作成する。
As shown in FIG. 47, the cost department
そして、図４８に示すように、患者別直課データＤＢ２６８を元に、患者別直課計算データ２６６へのレコードの追加を行う。また、図１０の医事明細情報Ｉ／Ｆから取得した日付、患者番号、明細診区、明細金額を、患者別物品消費データＤＢ２６３の年月日、患者ＩＤ、物品コード（点数マスタＩ／Ｆを参照して変換）、購入価格として登録する。
Then, as shown in FIG. 48, a record is added to the patient-specific
また、図４９に示すように、患者別物品消費データＤＢ２６３を元に、他システム物品マスタ２２３を参照しつつ、患者別直課計算データＤＢ２６６へのレコードの追加を行う。
Further, as shown in FIG. 49, a record is added to the patient-specific direct
次いで、図５０に示すように、患者別直課計算データＤＢ２６６の原価積上パターンコード、日付、患者ＩＤ、科目コード、部門コード、システム種別、直課内容コード、数、直課金額を、患者別原価計算データマートＤＢ２６５の原価積上パターンコード、日付軸キー、患者ＩＤ、科目コード、部門コード、システム種別、原価積上コード、件数、原価金額として追加する。なお、入院日数は０に設定する。
Next, as shown in FIG. 50, the cost calculation pattern code, date, patient ID, subject code, department code, system type, direct content code, number, and direct charge amount of the direct
また図５１に示すように、患者別日別収益データマートＤＢ２６４の年月日、患者ＩＤ、収益を、患者別原価計算データマートＤＢ２６５の日付軸キー、患者ＩＤ、収益金額として追加する。なお、入院日数は０に設定する。なお、患者別日別収益データマートＤＢ２６４は、医事会計システム１３より収集した医事明細情報Ｉ／Ｆから抽出したデータを、列定義に従ってマッピング作業を行うことで作成する。
Further, as shown in FIG. 51, the date, patient ID, and revenue of the patient-specific daily revenue
さらに図５２に示すように、患者別日別データＤＢ２６７の年月日、患者ＩＤ、職員ＩＤ、診断群分類番号、入院日数を、患者別原価計算データマートＤＢ２６５の日付軸キー、患者軸キー、職員ＩＤ、診断群分類番号、入院日数として追加する。これにて患者別原価計算データマート作成処理が終了する。入院日数は０に設定する。なお、患者別日別データＤＢ２６７は、患者入院データＤＢ２５６、職員別患者別時間比情報ＤＢ２５５、患者診断群分類データからから抽出したデータを、列定義に従ってマッピング作業を行うことで作成する。患者診断群分類データは、医事会計システム１３より収集した患者診断群分類適用情報Ｉ／Ｆを、列定義に従ってマッピング作業を行うことで作成する。
Further, as shown in FIG. 52, the date, patient ID, staff ID, diagnosis group classification number, and number of hospitalization days of the patient-specific
（処理内容−患者別原価計算処理−患者別原価出力処理）
次に、図３（ｃ）に示した患者別原価出力処理について説明する。この処理は、主として患者別原価出力部３０７によって行われるもので、先の患者別原価計算データマート作成処理で作成された患者別原価計算データマートＤＢ２６５に格納された情報（以下、集計対象情報）に対して、各種の分析を行うための集計テーブル（集計表）を作成する。
(Processing-Cost calculation by patient-Cost output by patient)
Next, the patient-specific cost output process shown in FIG. This processing is mainly performed by the patient-specific
この際、膨大な種類の集計テーブルを全て作成するのではなく、集計テーブルを２つのグループに区分し、その区分に応じて異なるタイミング及び集計方法で集計テーブルを作成する。第１のグループは、他の集計テーブルから作成可能な（他の集計テーブルに包含されている）集計テーブルであって、計算量が所定量以下の集計テーブルである。以下、このような集計テーブルを「随時集計テーブル」と称する。第２のグループは、随時集計テーブル以外の集計テーブルである。以下、このような集計テーブルを「事前集計テーブル」と称する。ただし、これら事前集計テーブルと随時集計テーブルとを相互に区別する必要がない場合には、両者を「集計テーブル」と総称する。この処理では、事前集計テーブルのみをバッチ処理で予め作成し、随時集計テーブルについては当該随時集計テーブルが必要になった時点で事前集計テーブルに基づいて作成する。 At this time, instead of creating all of the enormous types of aggregation tables, the aggregation tables are divided into two groups, and the aggregation tables are created at different timings and aggregation methods according to the divisions. The first group is a summary table that can be created from other summary tables (included in other summary tables), and is a summary table with a calculation amount equal to or less than a predetermined amount. Hereinafter, such a tabulation table is referred to as an “anytime tabulation table”. The second group is an aggregation table other than the aggregation table as needed. Hereinafter, such a tabulation table is referred to as a “preliminary tabulation table”. However, when it is not necessary to distinguish between these pre-aggregation tables and the occasional aggregation tables, they are collectively referred to as “aggregation tables”. In this process, only the pre-aggregation table is created in advance by batch processing, and the occasional aggregation table is created based on the prior aggregation table when the occasional aggregation table becomes necessary.
この集計テーブルの作成に際しては、集計参照情報ＤＢ２６９に格納されている情報を参照する。図５３には集計参照情報ＤＢ２６９に格納される集計参照情報の構成例を示す。この集計参照情報は、「集計キー」と「集計テーブル種別」とを相互に関連付けて構成されている。
When creating the total table, information stored in the total
「集計キー」は、集計対象情報から各集計テーブルを作成する際のキーであり、ここでは集計キーについての「グループ」、「レベル」、及び、「総数」が格納されている。「グループ」とは、集計キーを集計対象情報の種類に応じて分類するための区分であり、ここでは図示の７区分が設定されている。「ＤＰＣ」とは、診断群分類（Diagnosis Procedure Combination）であり、「積上」とは上述した各処理において積上げられたパターンやサービスを示す。「レベル」とは、各グループに属する集計キーの分類区分であり、例えばグループ「科目」に属する集計キーは、レベル「主科目」、レベル「補助科目」、レベル「細目科目」に分類される。なおＭＤＣとは、主要診断群の（Major Diagnostic Category）である。「総数」は、各レベルに区分される集計キーの数であり、例えば各レベル「患者」には患者の総数に対応する数（ここでは１７７０２）の集計キーがあり、レベル「主治医」には医師の総数（ここでは１６１）に対応する数の集計キーがある。各グループのレベルは、図示下方に示す程、細分化されたレベルであることを示し、例えば、レベル「主科目」を細分化したものがレベル「補助科目」であり、さらにレベル「補助科目」を細分化したものがレベル「細目科目」である。各グループに属する集計キーの総数（特許請求の範囲におけるデータ件数）は、当該グループの最細分化されたレベルの総数であり、例えばグループ「科目」に属する集計キーの総数は、レベル「細目科目」の集計キーの総数（ここでは５８）である。 The “aggregation key” is a key for creating each aggregation table from the aggregation target information. Here, “group”, “level”, and “total number” for the aggregation key are stored. The “group” is a category for classifying the aggregation key according to the type of the aggregation target information, and here, the seven categories shown are set. “DPC” is a diagnosis group combination (Diagnosis Procedure Combination), and “pile up” indicates a pattern or service accumulated in each process described above. “Level” is a classification category of aggregation keys belonging to each group. For example, aggregation keys belonging to the group “subjects” are classified into level “main subjects”, level “auxiliary subjects”, and level “detailed subjects”. . The MDC is a (Major Diagnostic Category) of the main diagnosis group. “Total number” is the number of total keys classified into each level. For example, each level “patient” has a total number of keys corresponding to the total number of patients (here, 17702). There are a total number of keys corresponding to the total number of doctors (161 in this case). The level of each group indicates that the level is subdivided as shown in the lower part of the figure. For example, the level “auxiliary subject” is obtained by subdividing the level “main subject”, and further the level “auxiliary subject”. Levels are “subject subjects”. The total number of aggregation keys belonging to each group (the number of data in the claims) is the total number of subdivided levels of the group. For example, the total number of aggregation keys belonging to the group “subject” "Is the total number (here 58).
「集計テーブル種別」は、集計テーブルの種別であり、ここでは図示の８種類の集計テーブルを作成することが想定されている。なお、各集計テーブルにはｑ０１〜ｑ０８の番号を示す。この「集計テーブル種別」の各項目には、当該各集計テーブルを作成するために必要になる集計キーを示す情報（図５３において「○」印を示している場合には、当該各集計テーブルを作成するために当該集計キーが必要になることを示している）が格納されている。例えば、「部門別費用別集計テーブル」を作成するためには、レベル「種別」に属する５個の集計キー、レベル「部門」に属する４８個の集計キー、レベル「主科目」に属する４個の集計キー、レベル「補助科目」に属する１６個の集計キー、及び、レベル「細目科目」に属する５８個の集計キーが必要である。 The “total table type” is a type of the total table, and here, it is assumed that eight types of total tables shown in the figure are created. Each tabulation table shows numbers q01 to q08. Each item of this “total table type” includes information indicating a total key necessary for creating each total table (in the case where “◯” is indicated in FIG. 53, each total table is displayed). Indicating that the key is required for creation). For example, in order to create a “division table by department”, five aggregation keys belonging to level “type”, 48 aggregation keys belonging to level “department”, and four belonging to level “main subject” Total key, 16 total keys belonging to the level “auxiliary subjects”, and 58 total keys belonging to the level “detailed subjects” are required.
ここで、各集計テーブルを作成するために必要になる集計キーを示す情報は、集計テーブルの相互間の包含関係を特定する情報としても機能する。すなわち、いずれか一つの集計テーブル（以下、非包含集計テーブル）を作成するために必要な集計キーの全てが、他の集計テーブル（以下、包含集計テーブル）を作成するために必要な集計キーに含まれている場合には、非包含集計テーブルは包含集計テーブルに含まれており、非包含集計テーブルは包含集計テーブルに基づいて集計することが可能である。例えば、部門別費用別集計テーブルを作成するために必要な集計キーは、診断群別患者別集計テーブルを作成するために必要な集計キーに全て包含されているので、部門別費用別集計テーブルは診断群別患者別集計テーブルに包含されており、部門別費用別集計テーブルは診断群別患者別集計テーブルに基づいて集計することができる。すなわち、各集計テーブルを作成するために必要になる集計キーを示す情報（図５３における「○」印）は、特許請求の範囲における包含関係情報に対応する。 Here, the information indicating the aggregation key necessary for creating each aggregation table also functions as information for specifying the inclusion relationship between the aggregation tables. That is, all of the aggregation keys necessary to create any one aggregation table (hereinafter referred to as a non-inclusion aggregation table) are converted into the aggregation keys required to create another aggregation table (hereinafter referred to as an inclusion aggregation table). When it is included, the non-included total table is included in the included total table, and the non-included total table can be calculated based on the included total table. For example, the summary key required to create the departmental cost summary table is all included in the summary key required to create the diagnostic group patient summary table. It is included in the total table by diagnosis group and by patient, and the total table by cost by department can be totaled based on the total table by patient by diagnosis group. That is, information (“◯” mark in FIG. 53) indicating the aggregation key necessary for creating each aggregation table corresponds to the inclusion relation information in the claims.
また、各集計キーの総数は、一つの集計テーブルに基づいて他の集計テーブルを作成するために必要な計算量を示している。すなわち、非包含集計テーブルを包含集計テーブルに基づいて集計する場合の計算量（近似値）は、包含集計テーブルの作成に要する集計キーと非包含集計テーブルの作成に要する集計キーとの差分の集計キー（以下、差分集計キー）の総数（各差分集計キーが属するグループの集計キーの総数）の積になる。例えば、診断群別患者別集計テーブルに基づいて部門別費用別集計テーブルを集計する場合、差分集計キーは、レベル「ＭＤＣ」、レベル「グループ」、及び、レベル「ＤＰＣ」が属するグループ「ＤＰＣ」の集計キーの総数「４６３」と、レベル「患者」が属するグループ「患者」の集計キーの総数「１７７０２」と、レベル「入院日数」が属するグループ「入院日数」の集計キーの総数「１１２」との積であり、４６３×１７，７０２×１１２＝９１７，９５４，９１２になる。すなわち、図５３の「総数」は、特許請求の範囲における計算量に対応する。 Further, the total number of each aggregation key indicates the amount of calculation required to create another aggregation table based on one aggregation table. In other words, the calculation amount (approximate value) when a non-inclusion total table is totaled based on the inclusion total table is the difference between the total key required to create the inclusion total table and the total key required to create the non-inclusion total table It is the product of the total number of keys (hereinafter referred to as difference aggregation keys) (total number of aggregation keys of the group to which each difference aggregation key belongs). For example, when the department-by-department expense-by-department aggregation table is aggregated based on the diagnosis group-by-patient aggregation table, the difference aggregation key includes the level “MDC”, the level “group”, and the group “DPC” to which the level “DPC” belongs. Total number of keys “463”, total number of total keys “17702” of the group “patient” to which the level “patient” belongs, and total number “112” of total keys of the group “days of hospitalization” to which the level “days of hospitalization” belongs. 463 × 17, 702 × 112 = 917, 954, 912. That is, the “total number” in FIG. 53 corresponds to the calculation amount in the claims.
以下、このような情報を用いた患者別原価出力処理を具体的に説明する。図５４は、患者別原価出力処理のフローチャートである。患者別原価出力部３０７の集計情報選別部３０７ａは、集計参照情報ＤＢ２６９に格納されている情報を参照して、事前集計テーブルと随時集計テーブルの判定を行ない、事前集計テーブルとして作成すべき集計テーブルを選択する（ステップＳＢ−１）。具体的には、図５３における各集計テーブルを作成するために必要になる集計キーを示す情報を参照して、非包含集計テーブルと包含集計テーブルとを判定する。そして、図５３における集計キーの総数を参照して、包含集計テーブルに基づいて非包含集計テーブルを集計する場合の計算量を算定する。この結果、非包含集計テーブルであって、当該非包含集計テーブルを包含集計テーブルに基づいて算定する場合の計算量が記憶部２００に予め設定された所定の計算量以下である場合には、当該非包含集計テーブルを随時集計テーブルであると判定し、それ以外の非包含集計テーブルや包含集計テーブルを事前集計テーブルであると判定する。
The patient-specific cost output process using such information will be specifically described below. FIG. 54 is a flowchart of patient-specific cost output processing. The total
図５５には、集計テーブルの包含関係と計算量とを概念的に示す。図中の番号ｑ０１〜ｑ０８は、図５３に示した各集計テーブルの番号に対応しており、各矢印の開始位置には非包含集計テーブルの番号、各矢印の終端位置には包含集計テーブルの番号、各矢印の途中に記載されている数値は当該各矢印にて結ばれた包含集計テーブルに基づいて非包含集計テーブルを集計する際の計算量を示している。例えば、診断群別患者別集計テーブル（番号ｑ０３）に基づいて部門別費用別集計テーブル（番号ｑ０１）を集計する際の計算量は、上述のように「４６３×１７，７０２×１１２（＝９１７，９５４，９１２）」であることが示されている。所定の計算量を例えば１０，０００とすると、当該計算量以下の計算量で集計可能な集計テーブルとしては、例えば、診断群別患者別集計テーブル（番号ｑ０３）に基づいて診断群別集計テーブル（番号ｑ０２）を作成する場合（計算量＝４８×１１２＝５，３７６）、診断群別患者別集計テーブル（番号ｑ０３）に基づいて患者別集計テーブル（番号ｑ０４）を作成する場合（計算量＝４８×５８＝２，７８４）、医師別疾患別集計テーブル（番号ｑ０７）に基づいて診断群別集計テーブル（番号ｑ０２）を作成する場合（計算量＝４８×１６１＝７，７２８）がある。この場合、診断群別集計テーブル（番号ｑ０２）や患者別集計テーブル（番号ｑ０４）を随時集計テーブルと判定し、他の集計テーブルを事前集計テーブルであると判定する。 FIG. 55 conceptually shows the inclusion relationship and calculation amount of the tabulation table. Numbers q01 to q08 in the figure correspond to the numbers of the respective aggregation tables shown in FIG. 53. The numbers of the non-inclusive aggregation tables are at the start positions of the arrows, and the numbers of the inclusion aggregation tables are at the end positions of the arrows. The number and the numerical value described in the middle of each arrow indicate the amount of calculation when the non-inclusive total table is aggregated based on the inclusion total table connected by each arrow. For example, as described above, the amount of calculation when totaling the department-specific total table (number q01) based on the patient-specific total table (number q03) is “463 × 17, 702 × 112 (= 917). , 954, 912) ". Assuming that the predetermined calculation amount is 10,000, for example, a tabulation table that can be tabulated with a calculation amount equal to or less than the calculation amount is, for example, a diagnosis group tabulation table (number q03) based on a diagnosis group patient total table (number q03). No. q02) is created (calculation amount = 48 × 112 = 5,376), and a patient-specific tabulation table (number q04) is created based on the diagnosis group-by-patient tabulation table (number q03) (calculation amount = 48 × 58 = 2,784), there is a case where the total table by diagnosis group (number q02) is created based on the total table by disease by doctor (number q07) (calculation amount = 48 × 161 = 7,728). In this case, the total table by diagnosis group (number q02) and the total table by patient (number q04) are determined as the total table, and the other total table is determined as the pre-total table.
その後、図５４に示すように、事前集計部３０７ｂは、事前集計テーブルの集計タイミング（例えば、集計対象情報が更新された場合や、各月末）が到来したか否かを判定し（ステップＳＢ−２）、到来した場合には（ステップＳＢ−２、Ｙｅｓ）、患者別原価計算データマートＤＢ２６５から必要な集計対象情報を取得して全ての事前集計テーブルを所定フォーマットで集計し、事前集計テーブルＤＢ２７０に格納する（ステップＳＢ−３）。
Thereafter, as shown in FIG. 54, the
次いで、随時集計部３０７ｃは、参照端末５０からの随時集計テーブルの集計指示を監視し（ステップＳＢ−４）、この集計指示があった場合には（ステップＳＢ−４、Ｙｅｓ）、当該集計が指示された１つ又は複数の随時集計テーブルを作成するための事前集計テーブルを事前集計テーブルＤＢ２７０から呼び出す（ステップＳＢ−５）。この時、随時集計テーブルの集計に必要な事前集計テーブルは、集計参照情報ＤＢ２６９に格納されている図５３の情報を参照して特定することができる。そして、この事前集計テーブルに基づいて所定フォーマットで随時集計テーブルを集計し、この随時集計テーブルを参照端末５０に送信する（ステップＳＢ−６）。なお、図５５に示すように、１つの随時集計テーブルを作成するための事前集計テーブルが複数存在する場合（例えば診断群別集計テーブル（番号ｑ０２）は、診断群別患者別集計テーブル（番号ｑ０３）と医師別疾患別集計テーブル（番号ｑ０７）のいずれからでも作成できる場合）には、最も計算量が少なくなる事前集計テーブルを１つ選択して、随時集計テーブルを作成することが好ましい。このように参照端末５０に送信された随時集計テーブルは、参照端末５０のモニタ等の出力装置にて出力される。
Next, the ad hoc
図５６には、原価を参照したい診断群のＭＤＣ（Major Diagnostic Category）コード及び診断分類コードをキーとして入力した際の出力結果を示す。この場合には、キーとして入力されたＭＤＣコード及び診断分類コードを含んだ診断群分類番号に対応する全てのレコードが患者別原価計算データマートＤＢ２６５から抽出され、当該抽出されたレコードに含まれる所定情報（ここでは診断群分類番号、患者ＩＤ、入院日数、原価（原価金額）、収益（収益金額））と、これら情報に基づいて所定方法で取得又は算定された情報（ここでは、診断群分類番号に基づいて所定ＤＢから取得された傷病名、原価及び収益に基づいて算定された利益及び利益率）とが出力される。これにて患者別原価出力処理が終了し、全ての患者別原価計算処理が終了する。
FIG. 56 shows an output result when a diagnostic group MDC (Major Diagnostic Category) code and a diagnostic category code of a diagnostic group whose cost is to be referred to are input as keys. In this case, all records corresponding to the diagnosis group classification number including the MDC code and diagnosis classification code input as keys are extracted from the patient-specific cost calculation
〔II〕実施の形態に対する変形例
以上、本発明の各実施の形態について説明したが、本発明の具体的な構成及び方法は、特許請求の範囲に記載した各発明の技術的思想の範囲内において、任意に改変及び改良できる。以下、このような変形例について説明する。
[II] Modifications to Embodiments Although the embodiments of the present invention have been described above, the specific configuration and method of the present invention are within the scope of the technical idea of each invention described in the claims. Can be arbitrarily modified and improved. Hereinafter, such a modification will be described.
（解決しようとする課題や発明の効果について）
発明が解決しようとする課題や発明の効果は、前記した内容に限定されるものではなく、本発明によって、前記に記載されていない課題を解決したり、前記に記載されていない効果を奏することもでき、また、記載されている課題の一部のみを解決したり、記載されている効果の一部のみを奏することがある。
(About problems to be solved and effects of the invention)
The problems to be solved by the invention and the effects of the invention are not limited to the above-described contents, and the present invention solves the problems not described above or produces the effects not described above. In addition, only a part of the described problems may be solved or only a part of the described effects may be achieved.
（構成及び制御について）
また、上記各実施の形態で自動的に行われるものとして説明した制御の全部または任意の一部を手動で行っても良く、逆に、手動で行われるものとして説明した制御の全部または任意の一部を公知技術または上述した思想に基づいて自動化しても良い。また、上記実施の形態において示した各構成要素の各機能ブロックの一部又は全部を、ハードワイヤードロジックにて構成しても良い。
(About configuration and control)
Further, all or any part of the control described as being automatically performed in each of the above embodiments may be performed manually, and conversely, all or any of the control described as being performed manually is performed. A part may be automated based on a known technique or the idea described above. Moreover, you may comprise a part or all of each functional block of each component shown in the said embodiment with a hard wired logic.
（分散や統合について）
また、上述した各電気的構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成できる。例えば、患者別原価出力処理の機能のみを出力処理専用のサーバに持たせたり、患者別原価計算サーバ１００の機能を複数のサーバ群に分散してもよい。
(About distribution and integration)
Further, each of the electrical components described above is functionally conceptual and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each part is not limited to the one shown in the figure, and all or a part thereof may be functionally or physically distributed / integrated in arbitrary units according to various loads and usage conditions. Can be configured. For example, only the patient-specific cost output processing function may be provided in a server dedicated to output processing, or the function of the patient-specific
（集計対象情報について）
本実施の形態では、医療機関の原価計算に関する情報を集計対象情報とする例を示したが、本発明は、任意の集計対象情報を集計することに適用することができる。
(About information subject to aggregation)
In the present embodiment, an example in which information related to cost calculation of a medical institution is used as the aggregation target information has been described. However, the present invention can be applied to the aggregation of arbitrary aggregation target information.
（包含関係情報や計算量情報について）
包含関係情報や計算量情報の具体的な形態や取得方法は任意である。例えば、包含関係を予めシステム構築者が判定しておき、包含関係を識別できるような番号を集計テーブルの種別に関連付けて集計参照情報ＤＢ２６９に記憶させておいてもよい。
(About inclusion relation information and calculation amount information)
The specific form and acquisition method of inclusion relation information and calculation amount information are arbitrary. For example, the system builder may determine the inclusion relationship in advance, and a number that can identify the inclusion relationship may be stored in the aggregation
（事前集計テーブルや随時集計テーブルを判定するための基準の計算量について）
この計算量として複数の値を設定しておき、これら複数の値を状況に応じて使い分けてもよい。例えば、患者別原価計算サーバ１００の処理負荷をモニタし、事前集計テーブルを作成する際において、当該処理負荷が記憶部２００に予め設定された所定負荷より大きい場合（処理負荷に余裕がない場合）には、複数の値の内の大きい値を基準の計算量として選択することによって事前集計テーブルの作成量を減らし、当該処理負荷が所定負荷より小さい場合（処理負荷に余裕がある場合）には、複数の値の小さい値を基準の計算量として選択することによって事前集計テーブルの作成量を増やしてもよい。
(Regarding the calculation amount of the standard for determining the pre-aggregation table and the occasional aggregation table)
A plurality of values may be set as the calculation amount, and the plurality of values may be used depending on the situation. For example, when the processing load of the patient-specific
１ 患者別原価計算システム
１０ 関連システム群
１１ 電子カルテシステム
１２ 看護ＰＤＡシステム
１３ 医事会計システム
１４ 財務会計システム
１５ 人事給与システム
１６ 物流システム
１７ 固定資産システム
１８ 購買システム
１９ 手術管理システム
２０ 健診システム
３０ 部門別原価計算サーバ
４０ メンテナンス端末
５０ 参照端末
６０ ネットワーク
１００ 患者別原価計算サーバ
２００ 記憶部
２１０ マスタＤＢ群
２１１ 原価積上マスタＤＢ
２１２ 原価積上パターンマスタＤＢ
２１３ 原価積上パターン設定マスタＤＢ
２１４ 原価部門マスタＤＢ
２１５ 原価部門変換マスタＤＢ
２１６ 原価科目変換マスタＤＢ
２１７ 特定保険医療材料マスタＤＢ
２１８ 他システム職員マスタＤＢ
２１９ 診療行為マスタＤＢ
２２０ 診療行為積上対象マスタＤＢ
２２１ 積上係数マスタＤＢ
２２２ 物品マスタＤＢ
２２３ 他システム物品マスタＤＢ
２２４ 標準医薬品マスタＤＢ
２５０ データＤＢ群
２５１ 部門別原価計算データＤＢ
２５２ 職員情報ＤＢ
２５３ 職員別人件費ＤＢ
２５４ 職員タイムスタディ情報ＤＢ
２５５ 職員別患者別時間比情報ＤＢ
２５６ 患者入院データＤＢ
２５７ 患者別手術データＤＢ
２５８ 患者別サービスデータＤＢ
２５９ 患者食数データＤＢ
２６０ サービス別件数データＤＢ
２６１ サービス単位原価データＤＢ
２６２ 積上対象データＤＢ
２６３ 患者別物品消費データＤＢ
２６４ 患者別日別収益データマートＤＢ
２６５ 患者別原価計算データマートＤＢ
２６６ 患者直課計算データＤＢ
２６７ 患者別日別データＤＢ
２６８ 患者別直課データＤＢ
２６９ 集計参照情報ＤＢ
２７０ 事前集計テーブルＤＢ
３００ 制御部
３０１ Ｉ／Ｆ取込処理部
３０２ サービス別件数データ作成部
３０３ 積上係数計算部
３０４ 直課不可分計算部
３０５ 直課計算部
３０６ 患者別原価計算部
３０７ 患者別原価出力部
３０７ａ 集計情報選別部
３０７ｂ 事前集計部
３０７ｃ 随時集計部
４００ ネットワークインターフェース
５００ バス
DESCRIPTION OF
212 Costing pattern master DB
213 Costing pattern setting master DB
214 Cost Department Master DB
215 Cost department conversion master DB
216 Cost item conversion master DB
217 Specified insurance medical material master DB
218 Other system staff master DB
219 Clinical practice master DB
220 Target DB for medical treatment accumulation
221 Rolling coefficient master DB
222 Article Master DB
223 Other system article master DB
224 Standard Drug Master DB
250
252 Staff Information DB
253 Personnel Cost DB by Staff
254 Staff Time Study Information DB
255 Time ratio information DB by patient by staff
256 Patient hospitalization data DB
257 Patient-specific surgery data DB
258 Patient-specific service data DB
259 Patient meal data DB
260 Number data DB by service
261 Service unit cost data DB
262 Data DB for loading
263 Patient consumption data DB by patient
H.264 Patient Revenue Daily Data Mart DB
265 Cost accounting data mart DB by patient
266 Patient direct calculation data DB
267 Patient-specific daily data DB
268 Direct data DB by patient
269 Total reference information DB
270 Pre-tabulation table DB
DESCRIPTION OF
Claims (4)
前記複数の集計情報の相互間の包含関係を特定する包含関係情報と、一部の前記集計情報に基づいて他の前記集計情報を算定する際の計算量を特定する計算量情報と、を格納する集計参照情報格納手段と、
前記集計参照情報格納手段にて格納されている前記包含関係情報及び前記計算量情報を参照することにより、前記一部の集計情報に基づいて算定可能な前記他の集計情報であって所定量以下の計算量で算定可能な集計情報を特定する集計情報選別手段と、
前記集計対象情報が所定方法で取得された場合に、当該取得された集計対象情報に基づいて、前記複数の集計情報の内、前記集計情報選別手段によって特定された前記集計情報以外の集計情報を作成する事前集計手段と、
前記集計情報選別手段によって特定された前記集計情報の作成が所定方法で指示された場合に、当該作成が指示された前記集計情報を、前記事前集計手段にて作成された前記集計情報に基づいて作成する随時集計手段と、
を備えることを特徴とする情報集計装置。 An information aggregation device that aggregates aggregation target information and creates a plurality of aggregation information,
The inclusion relation information for specifying the inclusion relation among the plurality of pieces of total information, and the calculation amount information for specifying the calculation amount when calculating the other total information based on a part of the total information are stored. Means for storing reference information to be stored;
The other aggregate information that can be calculated based on the partial aggregate information by referring to the inclusion relation information and the calculation amount information stored in the aggregate reference information storage unit, and is equal to or less than a predetermined amount Total information selection means for identifying the total information that can be calculated with the amount of calculation,
When the aggregation target information is acquired by a predetermined method, based on the acquired aggregation target information, aggregate information other than the aggregation information specified by the aggregation information selection unit is selected from the plurality of aggregation information. Pre-aggregation means to create,
When creation of the total information specified by the total information selection unit is instructed by a predetermined method, the total information instructed to create is based on the total information created by the pre-totaling unit. And any time counting means to create
An information totalizing device comprising:
前記集計情報選別手段は、前記他の集計情報を作成するために必要な前記集計キーが、前記一部の集計情報を作成するために必要な前記集計キーに全て包含されている場合に、当該一部の集計情報に基づいて当該他の集計情報が算定可能であると判定すること、
を特徴とする請求項１に記載の情報集計装置。 The inclusion relation information stored in the total reference information storage means is information for specifying a total key necessary for creating each of the plurality of total information,
The total information selection unit is configured so that the total key necessary for creating the other total information is included in the total key necessary for generating the partial total information. Determining that other aggregate information can be calculated based on some aggregate information;
The information totalization device according to claim 1 characterized by things.
前記集計情報選別手段は、前記一部の集計情報を作成するために必要な前記集計キーの内、前記他の集計情報を作成するために必要な前記集計キーに含まれていない前記集計キーを特定し、当該特定された集計キーに対応する前記データ件数の積を、当該一部の集計情報に基づいて当該他の集計情報を作成するための前記計算量として算定すること、
を特徴とする請求項１又は２に記載の情報集計装置。 The calculation amount information stored in the aggregation reference information storage means is information for specifying the number of data for each aggregation key necessary for creating each of the plurality of aggregation information,
The aggregation information selection means includes the aggregation key that is not included in the aggregation key that is necessary for creating the other aggregation information among the aggregation keys that are necessary for creating the partial aggregation information. Identifying and calculating a product of the number of data corresponding to the identified aggregation key as the amount of calculation for creating the other aggregation information based on the partial aggregation information;
The information totalization device according to claim 1 or 2 characterized by things.
前記情報集計装置には、
前記複数の集計情報の相互間の包含関係を特定する包含関係情報と、一部の前記集計情報に基づいて他の前記集計情報を算定する際の計算量を特定する計算量情報と、を格納する集計参照情報格納手段が設けられている場合において、
前記集計参照情報格納手段にて格納されている前記包含関係情報及び前記計算量情報を参照することにより、前記一部の集計情報に基づいて算定可能な前記他の集計情報であって所定量以下の計算量で算定可能な集計情報を特定する集計情報選別ステップと、
前記集計対象情報が所定方法で取得された場合に、当該取得された集計対象情報に基づいて、前記複数の集計情報の内、前記集計情報選別ステップにおいて特定された前記集計情報以外の集計情報を作成する事前集計ステップと、
前記集計情報選別ステップによって特定された前記集計情報の作成が所定方法で指示された場合に、当該作成が指示された前記集計情報を、前記事前集計ステップにおいて作成された前記集計情報に基づいて作成する随時集計ステップと、
を前記情報集計装置に実行させることを特徴とする情報集計プログラム。 A program for executing an information totaling method for creating a plurality of total information for an information totaling apparatus that totals target information and generates a plurality of total information,
In the information aggregation device,
The inclusion relation information for specifying the inclusion relation among the plurality of pieces of total information, and the calculation amount information for specifying the calculation amount when calculating the other total information based on a part of the total information are stored. In the case where a total reference information storage means is provided,
The other aggregate information that can be calculated based on the partial aggregate information by referring to the inclusion relation information and the calculation amount information stored in the aggregate reference information storage unit, and is equal to or less than a predetermined amount A total information selection step for identifying the total information that can be calculated with the amount of calculation,
When the aggregation target information is acquired by a predetermined method, based on the acquired aggregation target information, the aggregation information other than the aggregation information specified in the aggregation information selection step is selected from the plurality of aggregation information. A pre-aggregation step to create,
When the creation of the total information identified by the total information selection step is instructed by a predetermined method, the total information instructed to create is based on the total information created in the pre-aggregation step. An occasional aggregation step to create,
Is executed by the information totaling apparatus.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007256137A JP4472740B2 (en) | 2007-09-28 | 2007-09-28 | Information aggregation device and program therefor |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007256137A JP4472740B2 (en) | 2007-09-28 | 2007-09-28 | Information aggregation device and program therefor |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009087060A JP2009087060A (en) | 2009-04-23 |
| JP4472740B2 true JP4472740B2 (en) | 2010-06-02 |
Family
ID=40660395
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007256137A Expired - Fee Related JP4472740B2 (en) | 2007-09-28 | 2007-09-28 | Information aggregation device and program therefor |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4472740B2 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6203155B2 (en) * | 2014-09-30 | 2017-09-27 | セコム医療システム株式会社 | Management analysis device and management analysis program |
-
2007
- 2007-09-28 JP JP2007256137A patent/JP4472740B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2009087060A (en) | 2009-04-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4062910B2 (en) | HEALTH MANAGEMENT SUPPORT METHOD AND DEVICE AND HEALTH LIFE LIFE PREDICTION DATA GENERATION METHOD AND DEVICE | |
| Propper et al. | Does competition between hospitals improve the quality of care?: Hospital death rates and the NHS internal market | |
| Schreyögg et al. | Cost accounting to determine prices: how well do prices reflect costs in the German DRG-system? | |
| Lewis et al. | Measuring public hospital costs: empirical evidence from the Dominican Republic | |
| Laugesen | The resource-based relative value scale and physician reimbursement policy | |
| Puig‐Junoy et al. | Cost efficiency in primary care contracting: a stochastic frontier cost function approach | |
| JP4561790B2 (en) | HEALTH MANAGEMENT SUPPORT METHOD AND DEVICE AND HEALTH LIFE LIFE PREDICTION DATA GENERATION METHOD AND DEVICE | |
| CN108766542A (en) | A kind of data analysis processing method and system | |
| CN111816326A (en) | Hospital operation system | |
| JP2001319041A (en) | Management support system for medical institution and method for providing management support information to medical institution | |
| WO2020153207A1 (en) | System for assisting calculation of medical facility accounts | |
| JP4472740B2 (en) | Information aggregation device and program therefor | |
| US20140358577A1 (en) | Software for medical practitioners | |
| JP4548739B2 (en) | Patient-specific cost calculation apparatus and program therefor | |
| JP2019159643A (en) | Medical management support system, medical management support method, and medical management support program | |
| JP2018018494A (en) | Community comprehensive care business system | |
| US20160162650A1 (en) | Method for automating medical billing | |
| JP2004362556A (en) | Method and system of cost accounting by subject of medical treatment | |
| KR20220043710A (en) | Cost management system and method for hospital and medical care agency | |
| Fixler et al. | Health care output and prices in the producer price index | |
| Flessa et al. | Costing of Health Care Services in Three Provinces of Cambodia | |
| Poullier | Health care expenditure and other data | |
| CN101611421A (en) | The health care administration of patient-interactive | |
| JP5525170B2 (en) | Hospital management evaluation support device, hospital management evaluation support system, hospital management evaluation support program, and computer-readable recording medium recording the same | |
| Wouters | Quality of health care and cost recovery in Africa: Evidence from Niger and Senegal |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100202 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100303 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130312 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130312 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313115 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130312 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313115 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130312 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130312 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130312 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140312 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |