歯科診療報酬請求事務システムの開発– 処理プログラムの自動生成を目的としたデータ分析 –2007MI103 川合 彩乃
指導教員

1 はじめにわれわれは，歯科診療報酬請求事務システム (以下，事務システム) の開発をおこなう．事務システムは，保険点数の算定や診療報酬明細書（以下，レセプト）の作成等の事務処理をおこなうシステムである．事務システ
ムは，厚生労働省が定める歯科診療報酬請求の制度に基づいた仕様書およびマスタを利用しシステムの処理を設計しなければならない．マスタとは，事務システムで扱う診療行為名称等の情報とその情報の処理方法を定義するデータ群である．厚生労働省は歯科診療報酬請求の制度を定期的に改定するので，仕様書およびマスタに変更が生じる．この変更に対応するために，事務システムの処理内容の変更を支援する環境を作成しなければならな
い．
本研究の目的は，制度の改定に対応するための処理内容の変更を支援する事務システムのアーキテクチャ設計とデータ分析方法の提案をおこなうことである．本研究では，事務システムの実現すべき処理のプログラムを自動生成する生成系を設け，処理内容の変更可能性に着目したデータ分析とソフトウェアアーキテクチャ設計をおこなう．
事務システムのアーキテクチャには GoF デザインパ
ターンの Visitor パターンを適用し，処理とデータ構造を分離する．また，歯科診療報酬請求制度に基づいた仕様書とマスタから抽出した情報を入力とすることでVisitor を生成する生成系を設ける．Visitor パターンの適用と生成系を用いることにより，歯科診療報酬請求の制度改定に伴う事務システムの処理内容の変更を支援するアーキテクチャを構築する．
生成系を作成するにあたり，生成系に必要な情報を分析する必要がある．処理内容の変更に対応可能な生成系を実現するために，生成する処理内容の変更可能性に着目したデータ分析を次の手順でおこなう．まず，処理内容に影響を与える情報の分析をおこなう．次に，処理内容の変更可能性に着目した分析をおこなう．最後に，変更が生じる可能性のある処理に対し可変性の実現方法の検討をおこなう．これらの分析の結果，歯科診療報酬請
求の制度に基づいた仕様書およびマスタのうち処理内容に影響を与える情報を処理内容を定義する情報であるとしてメタデータと定義した．そのうえで過去のメタデー
タの変更や歯科診療報酬請求の知識から事務システムで想定される処理内容の変更の種類を整理する．また，事務処理のうち変更の起こりうるメタデータによって定義される処理内容を変動部分，それ以外を固定部分と定義

2007MI174 丹羽 由梨香

沢田 篤史
し分類した．事務システムの処理の変動部分に対し，生成系による処理の可変性の実現方法を検討した．
事務システムで想定されるそれぞれの変更に対して用いた可変性の実現方法が妥当であるのか，他の可変性の実現方法と比較する．本研究で提案するデータ分析方法の効果を考察する．

2 研究の背景
歯科診療報酬請求制度の概要
歯科診療報酬請求の制度は，厚生労働省が定める．定められた内容は，複数の仕様書に自然言語で記述される．歯科診療報酬請求の仕様書は，制度改定に伴いそれぞれが年に一度変更される．これらの仕様書は，参考文
献 [3, 4] から得ることができる．
歯科診療報酬請求制度の概要を説明する．歯科医療機
関はレセプトを作成し保険者に請求することにより，診療報酬を受け取ることができる．診療報酬とは，保険者が歯科医療機関に支払う医療費のことである．診療報酬
は，医療行為ごとに決められた保険点数に基づいて計算する．被保険者は歯科医療機関を受診する際に医療費の一部を自己負担し，差額を保険者が支払う．レセプトには診療報酬の他に，患者情報，診療記録等を記載する．
これらの作業をおこなう上で必要な情報が，歯科診療報
酬請求の仕様書に記載されている．
2.2 マスタ厚生労働省は，歯科診療報酬請求の仕様書の他にマスタを管理している．マスタは，事務システムの開発促進を目的として発行されている [3]．マスタとは，事務シス
テムで扱う情報と，その情報の処理方法を定義するデータ群である．マスタ内の各項目と項目ごとの識別子の意
味は，マスタの仕様書に自然言語で記述されている．マスタは，制度改定に伴い歯科診療報酬請求の仕様書と同様に変更される．
2.3 歯科診療報酬請求事務システムの概要
事務システムは，歯科診療システムの一部である．歯科診療システムは，歯科診療所のスタッフがおこなう業務を作業の流れに沿ってサポートする．事務システムの他には，診療予約受付・清算システムと診療記録システムがある．事務システムと他のシステムの関連を図 1に示す．事務システムは，電子化したレセプトを作成する．事務システムがおこなう代表的な処理として以下の事務処理がある．

2.1• レセプトチェック
患者情報，診療記録等が保険点数算定可能，また診療報酬請求が可能であるかをチェックする．
• 保険点数算定

レセプトチェックをおこなったデータの保険点数を算定する．

• 電子レセプト作成
保険者に提出する形式のレセプトを作成する．

図1

診療報酬請求事務システムと他のシステムの関連

可変性の実現方法
ソフトウェア開発において，可変性の実現方法が提唱されている [2]．可変性の実現方法とは，システムの中で変更が生じる可能性のある箇所において，変更に対応する方法を定義したものである．可変性の実現方法には
以下の 7 種類がある．

2.4• 多相型（Inheritance）• 拡張（Extensions）• 使用（Uses）• 構成（Conﬁguration）• パラメタ（Parameters）• テンプレート（Template Instantiation）• 生成（Generation）

3 システムの概念アーキテクチャ設計歯科診療報酬請求の制度改定に伴う処理内容の変更を支援する事務システムのアーキテクチャ設計をおこなう．事務システムは以下の二つの特徴を持つ．

• 共通のデータ構造に対し複数の事務処理が存在• 歯科診療報酬請求の制度の改定に伴い，事務シス適用することで，変更が想定される処理を局所化することができる．事務システムの処理をデータ構造から分離することにより，年度ごとの歯科診療報酬請求の制度改定に伴う処理内容の変更を柔軟におこなうことができる．図 3 に事務システムのデータ構造とデータ構造に対する Visitor の概要を示す．Visitor に多相型を用いて変更される可能性のある処理を局所化することにより，Visitor の変更に柔軟に対応可能なアーキテクチャを実現する．Visitor に含まれるメソッドはデータ構造の各クラスごとに存在する．データ構造に影響を与えることなく Visitor の変更をおこないたいので，メソッドの種類は変更しない．事務システムの処理を実現している
Visitor の処理内容は年度ごとの制度改定に伴い変更される．多相型を用いることによりサブクラスに変更の可能性のある処理を局所化する．

図3データ構造とデータ構造に対する Visitor の概要

年度ごとの制度改定に伴う処理内容の変更に対応した

Visitor を実現するために，可変性の実現方法のうちの生成を用いる．すなわち事務システムでは歯科診療報酬請求の仕様書から抽出した処理に係るパラメータを入力とし，事務処理を実現する Visitor を出力する生成系を設ける．歯科診療報酬請求の制度改定により変更が生じる可能性のある Visitor 内の処理部分は多岐にわたる．
Visitor は歯科診療報酬請求の制度改定に応じた事務処理を実現する必要がある．事務処理を実現する Visitorの生成系を設けることで，制度改定に伴う事務システムの処理内容の変更を支援するアーキテクチャの構築をおこなう．

4 処理内容の変更可能性に着目したデータ分析

テムの処理内容が変更
これらの特徴を踏まえ事務システムの概念アーキテク
チャを設計する．図 2 に事務システムの概念アーキテク
チャを示す．

図2

事務システムの概念アーキテクチャ

事務システムのアーキテクチャには GoF デザインパ
ターンの Visitor パターンを適用する．事務システムの処理内容は歯科診療報酬請求の制度改定に伴い変更されるが，事務処理の対象であるデータ構造は変更されることがない．GoF デザインパターンの Visitor パターンを処理内容の変更に対応可能な生成系を実現するために，生成する処理内容の変更可能性に着目した分析をおこなう．
4.1 処理内容に影響を与える情報の分析
歯科診療報酬請求の仕様書のうち，事務システムの処理内容に影響を与える情報をメタデータと定義する．これにより，仕様書と処理内容の関係を明確にする．
事務システムは歯科診療報酬請求の仕様書に基づき作成する．歯科診療報酬請求の制度改定による仕様書の変更に伴い，事務システムの処理内容を変更しなければならない．メタデータを定義し、メタデータがどのように変更されるのか整理することにより，仕様書に変更が生じた場合に変更しなければならない処理内容が明確になる．図 4 にメタデータと処理内容の関係を示す．図 4 に示すメタデータに変更が生じた場合，メタデータが定義する右側の処理論理を変更しなければならない．

図4

メタデータと処理の関係

処理内容の変更可能性に着目したデータ分析
処理内容の変更可能性に着目した分析では，事務システムの処理の変更の種類と，変更が生じる可能性のある処理部分を明確にする．4.1 節で整理したメタデータの変更に伴い，事務システムの処理内容を変更する必要がある．歯科診療報酬請求の知識と過去のメタデータの変更を整理し，事務システムの処理内容の変更の種類を明確にする．事務システムの処理内容のうち，変更の起こりうるメタデータによって定義される処理内容を変動部分，それ以外を固定部分と定義する．
歯科診療報酬請求の知識と過去のメタデータの変更を整理した結果，事務システムの処理内容の変更は次の 2種類であることがわかった．

4.2• 処理内容の構成要素の組合せの変更• 構成要素内の一部の処理内容の変更
図 5 は，電子レセプト作成処理の概念構造である．電子レセプト作成処理は，レコードの作成処理等の構成要素の組合せによって成る．歯科診療報酬請求の制度改定により構成要素の組合せに変更が生じるので，組合せは変動部分である．構成要素の組合せの変更は生じるが，図 5 に示した処理の概念構造が変更されることはない．
よって，処理の概念構造やその組合せのバリエーションは固定部分である．

合せを実現するために，可変性の実現方法のうちの構成を用いる．構成要素内の一部の処理内容の変更に対する実現は処理の流れの枠組みが固定部分であるので，可変性の実現方法のうちのテンプレートを用いる．
事務システムでは，処理内容の構成要素の組合せをおこなう必要のある変更が想定される．構成要素を選択するパラメータにより，処理内容の構成を決定する．また，事務システムでは構成要素内の一部の処理内容の変更が想定される．固定部分である処理の流れの枠組みをテンプレートとし，変動部分である一部の処理内容を定義するパラメータを与える．パラメータを変更することで，構成要素内の一部の処理内容の変更に対応する．パラメータの一つとして，対応表を設ける．変動部分である一部の処理内容において，マスタの項目に含まれる識別子と処理内容が一対一対応している処理部分がある．
マスタの項目ごとに対応表を作成し，一部の処理内容を定義するパラメータとして与えることにより変更に対応する．

5 考察
可変性の実現方法の妥当性の考察
制度改定に伴い事務システムで想定される変更に対して用いた可変性の実現方法が妥当であるか，他の可変性の実現方法と比較し考察する．
5.1.1 概念アーキテクチャレベルでの処理の可変性の実現
3 章で説明した通り，本事務システムでは多相型を用いることで Visitor の変動部分を局所化し，Visitor に可変性を持たせている．表 1 に，Visitor の可変性を実現する方法に対して多相型を用いた場合と他の可変性の実現方法を用いた場合の比較結果を示す． Visitor の可変

5.1

表 1 Visitor の可変性を実現するための実現方法の比較

可変性の実現方法

Visitor の可変性を実現するための実現方法の評価

図5

多相型（本提案）

○

拡張×

使用×

構成×

パラメタ×

テンプレート△生成×電子レセプト作成処理の概念構造

図 5 で示した処理の構成要素内の一部の処理内容に変更が生じる．構成要素内は，処理の流れの枠組みは共通であり，一部の処理内容の変更内容は明確でない．よって処理の流れの枠組みは固定部分であり，一部の処理内容は変動部分である．
4.3 可変性の実現方法の検討
4.2 節の結果から，生成系が生成する処理に可変性を持たせる実現方法を検討する．処理内容の構成要素の組性の実現方法として，多相型とテンプレートが適用できる．しかし，事務システムでは年度ごとの事務処理を実現する Visitor を保持する必要がある．多相型を用いる
場合，年度ごとの事務処理を実現する Visitor をそれぞれサブクラスに定義することで対応可能である．一方テンプレートでは対応できない．よって多相型が適している．
制度改定に応じた Visitor の実現方法に生成を適用することで，Visitor 内の多岐にわたる処理部分の変更に対応する．生成以外の可変性の実現方法は，多岐にわたる処理部分の変更の実現方法として不適切である．
5.1.2 コードレベルでの処理の可変性の実現
生成系の実現方法として用いた処理の可変性の実現方法が妥当であるかを考察する．生成系で実現すべき変更は以下の 2 種類である．

A. 処理内容の構成要素の組合せの変更
B. 構成要素内の一部の処理内容の変更
4.3 節で説明した通り A の変更に対しては構成を，B の変更に対してはテンプレートを用いることにより可変性を実現している．
表 2 に，A の変更に対して構成を用いた場合と他の可変性の実現方法を用いた場合の比較結果を示す． A の
表 2 A の変更に対する実現方法の比較

可変性の実現方法

A に対する実現方法の評価

多相型×

拡張×使用

×

構成（本提案）○パラメタ△

テンプレート×生成−• 処理を定める制度が存在• 処理方法を定義する情報が存在• 処理を定義する情報が年度ごとに変更
これらの特徴を満たすドメインに対し，われわれが提案するデータ分析方法が有効であると考える．

6 おわりに変更の実現方法として，構成とパラメタが適用できる．
パラメタで実現する場合は構成要素の変更が起こりうる箇所ごとに構成要素を全て保持する必要があるので，冗長なソースコードになる．よって構成が適している．
表 3 に，B の変更に対してテンプレートを用いた場合と他の可変性の実現方法を用いた場合の比較結果を示す． B の変更の実現方法として，多相型とテンプレー
表 3 B の変更に対する実現方法の比較

可変性の実現方法

こなう．
本研究では，変更の起こりうるメタデータにより定義される処理内容を変動部分，変更の生じる可能性のないメタデータにより定義される処理内容を固定部分と定義した．この定義により，歯科診療報酬請求の制度が改定された際に変更すべき処理部分を特定することが可能になった．また変動部分における処理内容の変更の種類を整理した．これにより，生成系の実現方法を検討することができた．
5.3 提案するデータ分析が適用できるドメインの特徴
本研究におけるデータ分析は，事務システムにおける生成系に対しておこなったものである．どのような特徴をもつシステムに対して，われわれの提案するデータ分析方法が有効であるかを考察する．歯科診療報酬請求事
務のドメインの特徴は，以下のとおりである．

B に対する実現方法の評価

多相型

△

拡張×

使用

×

構成×

パラメタ

×

テンプレート（本提案）○

生成−トが適用できる．多相型を用いる場合は変動部分をサブクラスに記述することで対応できるが，生成系のソースコードを書き換える必要がある．よってテンプレートが適している．
5.2 提案するデータ分析方法の効果
提案するデータ分析をおこなうことで，仕様変更に伴う処理の変更に対応するために必要な情報を抽出することができる．処理内容の変更に対する実現方法に着目し，データ分析をおこなう．処理内容の変更可能性に着目したデータ分析では，変動部分と固定部分の定義をお本研究では，制度改定に対応するための処理内容の変更を支援する事務システムのアーキテクチャ設計とデータ分析方法の提案をおこなう．アーキテクチャには GoF デザインパターンの Visitor パターンを適用し，データ構造と処理を分離した．また，歯科診療報酬請求の仕様とマスタから抽出した情報を入力とすることで，Visitor を生成する生成系を設けた．データ分析では，処理内容の変更可能性に着目した分析をおこなった．処理内容の変更の種類を明確にし，変更が生じる可能性のある処理部分を特定した．これにより，生成系の実現方法を検討することができた．
今後の課題は，われわれが提案するデータ分析方法が他のドメインに対して適用することができるかを検証することである．

参考文献[1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,
Design Patterns: Elements of Reusable ObjectOriented Software, Addison-Wealey, 1995.
[2] I. Jacobson, M. Griss, P. Jonsson, SOFTWARE
REUSE: Architecture, Process, and Organizationfor Business Success, Addison-Wesley, 1997.
[3] 厚生労働省保険局，“診療報酬情報提供サービス，”
http://www.iryohohoken.go.jp/shinryohoshu/，2010．
[4] 社会保険診療報酬支払基金，“社会保険診療報酬支払基金，” http://www.ssk.or.jp/ ，2010．