JMDC TECH BLOG

JMDCのエンジニアブログです

業務(データ)知識の重要性を改めて考えてみた

こんにちは。
マスタ開発・運用保守チーム大塚です。

マスタ管理システム(以下、MMS)のユーザであるメンテナンス部署では、各サービス向けに分析に必要な分類や標準化の品質と生産性を高めるのに多種のデータソースを活用してメンテナンス作業を行っています。

今回はその中からレセプト電算処理システムマスタ(以下、レセ電マスタ)の業務(データ)知識を活用して作業を効率化した事例を紹介します。

活用事例

以前の仕様(Before)

MMSにはデータソースの更新ごとに追加・変更・削除のデータをメンテナンス候補として抽出する機能があるのですが、当時は単純に前回と今回を比較して差があったものを変更と判断してメンテナンス候補として抽出していました。 システム的な観点では問題のない仕様に見えます。

追加1件、変更3件、削除1件の場合

変更判断の例(前仕様)
変更判断の例(前仕様)

この仕様の問題点は何か

レセ電マスタにはデータの変更状態を表す「変更区分」の列を持っています。

変更区分 内容
0 前マスタの内容と同じ
1 抹消
2 復活
3 新規
5 変更
9 廃止

「変更区分」の値の変化に注目してデータソースの更新内容を改めて見ていきます。

前回更新 -> 追加1件、変更1件、廃止1件

  • 変更区分とともに他列の値が更新・追加されます
変更区分 コード 名称 点数
0:変更なし 1001 初診 80
5:変更 1002 再診 30
0:変更なし 1003 検査A 50
9:廃止 1004 検査B 70
3:新規 1005 検査C 100

今回更新 -> 追加1件、更新1件

  • 変更区分とともに他列の値が更新・追加されます(前回更新と同様)
  • データの変化がないレコードも「0:変更なし」に更新されます
  • 前回廃止のレコードは物理的に削除されます
変更区分 コード 名称 点数
0:変更なし 1001 初診 80
0:変更なし 1002 再診 30
5:変更 1003 検査A 60
0:変更なし 1005 検査C 100
3:新規 1006 検査D 120

今回の更新で他列に変更がなくても「変更区分」の値が変化するため、1002と1005のレコードが変更ありとして判断されます。
「変更区分」はメンテナンスに利用しないため、メンテナンス担当にとってはメンテナンス候補として抽出されると邪魔になるデータとなります。

前仕様の問題点例
前仕様の問題点例

このように「変更区分」は最新のデータだけを見てどのような変更があったかを判断するには便利ですが、前回と今回のデータ比較で差分を取る際には注意が必要です。
例は数件ですが、実際に繁忙期には1万件弱のデータが更新されることもあるため、メンテナンス担当の負荷が高まっていました。

改善後の仕様(After)

前回と今回の比較した差分に加えて変更判断には「変更区分」を利用する仕様としました。
(他にもいろいろと改善した仕様はあるのですがここでは割愛します。)
その結果、繁忙期のメンテナンス担当の作業負荷がかなり軽減されました。

変更判断の例(改善後仕様)
変更判断の例(改善後仕様)

まとめ

業務(データ)知識があるとユーザにとって最適な仕様を提案しやすくなります

★レセ電マスタの変更判断には「変更区分」を利用した方がよい

★「変更区分」はマスタのメンテナンスには利用していない

おわりに

今回は業務(データ)知識の大切さが伝わればよいかと思い書いてみましたがいかがでしたか。
マスタ開発・運用保守チームは日々の業務で得た知識をチーム間で連携しあう場として週1回勉強会を実施しています。
この記事を見て興味を持たれた方は下記も参照していただけると嬉しいです。

https://hrmos.co/pages/jmdc/jobs/0000160hrmos.co

blog.jmdc.co.jp

参考

メンテナンス作業の例

データソースMMSに取り込んで新規追加されたデータや名称が変更されたデータに対して英名付与を行っています。

また標準化作業は基本的に名称でマスタとマッチングするため名称が一意である必要がありますが、レセ電マスタは名称が重複しているデータが存在するため一定のルールに基づいて標準化に使用してはいけないマスタを特定するフラグを付与しています。

英名付与と使用禁止フラグ設定の例
英名付与と使用禁止フラグ設定の例

上記からもわかるように名称変更されたかはメンテナンス担当にとって重要な情報となります。

techblog.jmdc.co.jp