第３章　機能・帳票要件

本章の構成は、以下のとおりである。

表3-1　機能・帳票要件の構成

１．機能・帳票要件

機能・帳票要件の具体的な要件は以下の事業について「（別紙２）機能・帳票要件」でまとめている。

１．介護保険共通

２．被保険者資格

３．保険料賦課

４．保険料収納

５．滞納管理

６．受給者管理

７．認定管理

８．給付管理

９．統計・報告等

10．総合事業

各事業の機能・帳票要件における考え方や留意事項は以下のとおりである。

（１）管理項目について

（２）「～等」の表記について

（３）一覧管理機能について

（４）EUC機能の要件について

（５）基幹系他システム連携機能について

（６）外部帳票と内部帳票について

（７）エラー・アラート（チェック条件）の考え方について

（８）操作権限管理について

（９）アクセスログ管理について

（10）バッチ処理について

（１）管理項目について　　　　　　　　　　　　　　　　　　

該当する機能で管理すべき項目として「管理項目」をまとめている。「管理」とはデータの設定・保持・修正ができることをいい、参照又は表示のみを目的とした項目は管理項目として定めないこととしている。そのため、参照・表示のみを目的とした項目については、参照要件又は表示要件として記載している。

図3-1　管理項目の該当例と非該当例

なお、住民税情報等の他システムからの連携で取得した情報のうち、介護保険システム側で保持・修正を行う場合は管理項目を定めている。同一のパッケージにより参照のみでも可能としている連携項目の場合は、管理項目を定めず、デジタル庁が整理する連携要件に連携できる項目を定めている。

例）負担限度額認定にて利用者負担段階の判定に必要な非課税年金情報を他システムから取得するが、取得した情報を介護保険システム内で保持して適宜修正等を行うこともあるため、受給者管理（負担限度額情報）の管理項目となる。

管理項目のうちコード管理（選択入力）を行う場合は、管理項目名に「コード」を付加している。具体的なコード管理内容は、機能・帳票要件に定めず、デジタル庁が整理するデータ要件（コード一覧）に定めている。

例）資格異動事由に関する管理項目は、「資格異動事由コード」となる。

管理項目のデータ型（全角文字、半角文字等）、桁数、データ入力出力条件等は、機能・帳票要件に定めず、デジタル庁が整理するデータ要件に定めているため、管理項目の入力条件（必須・条件付き必須・任意）やデータ移行時のデータ抽出条件はデータ要件を確認すること。

（２）「～等」の表記について　　　　　　　　　　　　　　　

機能・帳票要件の記載で「～等」と表現しているものがある。「～等」は性質別に考え方を次のとおり整理している。

表3-2　「～等」の表記と考え方

分類	記載箇所（例）	考え方
事務運用例として記載しているもの		左記事例では過去の認定情報を参照する事務運用の例として記載している。認定申請に対する処分は主に認定（新規・更新・区分変更）となるが、実際には認定以外の様々なケースがあり、全て列挙することも現実的ではない。一方、主に発生する事務運用例を記載することは具体的イメージの補助となるため、「等」をつけて記載をしている。
あえて全て列挙しなくても法令等により要件に齟齬が生じないもの		左記事例では負担割合の判定に必要な情報は法令・通知等で決まっているため、あえて全てを列挙せずとも要件に齟齬が生じないため、冗長とならないように「等」をつけて記載をしている。
要件を実現するための手段を参考として記載しているもの		左記事例では、大量帳票の印刷を外部業者に委託する場合に電子データを作成する要件であるが、委託先によって作成する電子データの形式は異なるため、実現手段の事例として「CSV形式のファイルやPDFファイル」を出しているだけで、実現方法は任意となる。（「等」を除くと記載したファイル形式以外のものが実装不可となるため、「等」をつけている。）

（３）一覧管理機能について　　　　　　　　　　　　　　　　

機能・帳票要件における一覧管理機能について、機能の考え方及び記載方針を次のとおり整理している。

表3-3　一覧管理機能の考え方と記載方針

ただし、事務運用上、明記をしないと支障が出ると認められるものは明記する。

また、上記３つの観点を踏まえて、「（４）EUC機能の要件について」で、一覧管理機能とEUC機能の関連性を整理している。

（４）EUC機能の要件について　　　　　　　　　　　　　　　

一覧管理機能とEUC機能は一部機能が重複する部分があるが、運用上最低限必要となる業務固有の一覧確認要件は「○○を一覧で確認できること」と明記した上で一覧管理機能での対応とすることとし、その他の要件については、EUC機能での対応という形で整理している。

図3-2　機能・帳票要件におけるEUC機能の記載例

（５）基幹系他システム連携機能について　　　　　　　　　　

基幹系業務との他システム連携機能において、介護保険用宛名情報／税務情報等の情報については、介護保険システム内での保持・不保持のいずれであっても機能上の影響はないと考えられるため、いずれの方式（主に下図パタン）での実装も可能として定義している。

図3-3　基幹系他システムとの連携イメージ

（６）外部帳票と内部帳票について　　　　　　　　　　　　　

帳票要件として定義する帳票は外部帳票を基本とする。担当主管課内の決裁用等の内部帳票は機能要件におけるEUC機能等を活用することとする。なお、外部帳票と内部帳票の定義は次のとおりである。

表3-4　外部帳票と内部帳票の考え方

（７）エラー・アラート（チェック条件）の考え方について　　

機能・帳票要件に定める各機能において、不正な状態で情報が管理されると事務運用に影響が発生するため、適宜データの矛盾をチェックする必要がある。主な矛盾の分類としては次のとおりである。

表3-5　矛盾の分類

これらの矛盾に対して、エラー又はアラートのチェックを行い、不正なデータの登録を抑止することや操作者（入力者）への注意喚起を行う必要がある。エラー・アラートのチェック観点は、次のとおりである。

表3-6　エラー・アラートのチェック観点

本仕様書におけるエラー・アラート（チェック条件）において主に留意すべき事項は、次のとおりである。

① エラー・アラートは機能・帳票要件に定める。

② エラーチェックは「不正データを作成しない」という観点からデータ入力時にチェックすることを基本とするが、必要な情報を用いて帳票やデータ等を出力するまでに整備されれば影響がないケースも考えられるため、必ずしも入力時にチェックすることを求めるものではないこととする。

③ エラーチェックの内容は必ずしもメッセージによる表示に限定するものではなく、データの入力内容が一定条件を満たすまでデータ保存を不可にする、といった方法等でも問題ないこととする。

④ 文字列／数値といったデータの属性やデータの項目長に対するチェックは、データ要件で定められるデータ形式に準拠することとし、矛盾するものはエラーチェックとする。

⑤ 検索条件未入力のチェックや入出力ファイルの格納先（フォルダ）パスの存在確認チェック等は、画面要件に含まれるものであるため、本仕様書におけるエラー・アラートの要件としては定めないこととする。

⑥ アラートについては、制度改正等により従前まで必要とされていたチェックが不要となる場合や、地方自治体の運用により必要とするチェックの設定が異なる等も想定されることから、アラートの設定は切り替え可能（アラートを表示しない設定も含む）とすることを考慮する必要がある。

⑦ エラーについては、システム内部管理項目や帳票への印字項目・集計項目などのアウトプットとして必要となる項目を除き、エラーの設定は切り替え可能（エラーを表示しない設定も含む）とすることを考慮する必要がある。

（８）操作権限管理について　　　　　　　　　　　　　　　　

操作権限管理は地方自治体で利用する事務処理システムとして共通した要件とすることが基本であることから、デジタル庁が整理した要件を基本とする。加えて、介護保険システムに必要とされたものは固有の要件として追加する必要がある。これらの考え方を踏まえて、以下のとおり定める。

表3-7　操作権限管理（実装必須機能）

認証に係る機能については、標準準拠システムで実装するか、認証基盤等で実装するかを問わない。

表3-8　操作権限管理（標準オプション機能）

（９）アクセスログ管理について　　　　　　　　　　　　　　

アクセスログ管理は地方自治体で利用する事務処理システムとして共通した要件とすることが基本であることから、住民記録システム標準仕様書の「10.2 アクセスログ管理」に準拠することを基本とする。加えて、住民記録システム標準仕様書において住民記録システム固有の機能や表現が記載されている部分については、介護保険システムに固有の要件として置き換える必要がある。これらの考え方を踏まえて、以下のとおり定める。

表3-9　アクセスログ管理（実装必須機能）

表3-10　アクセスログ管理（標準オプション機能）

（10）バッチ処理について　　　　　　　　　　　　　　　　　

バッチ処理の実行方法は、手動による実行の他に設定による自動実行があるが、地方自治体で利用する事務処理システムとして共通した要件とすることが基本であることから、デジタル庁が整理した要件を基本とする。加えて、介護保険システムに必要と整理されたものは固有の要件として追加する必要がある。これらの考え方を踏まえて、以下のとおり定める。

表3-11　バッチ処理（標準オプション機能）

２．帳票詳細要件

帳票詳細要件では、原則として「１（６）外部帳票と内部帳票について」にて示した外部帳票を対象とし、機能・帳票要件で定義した帳票におけるシステムからの印字項目等を「（別紙３）帳票詳細要件」でまとめている。また、帳票詳細要件として定義した帳票の様式（レイアウト）を「（別紙４）帳票レイアウト」でまとめている。なお、システムからの印字項目（以下「システム印字項目」という。）とは、業務システムにて対象情報により編集し印字する項目のことをいい、固定文言等の帳票レイアウトに直接設定されている項目は含まない。

帳票詳細要件及び帳票レイアウトの考え方や留意事項は以下のとおりである。

① 帳票詳細要件には、機能・帳票要件にて定義した帳票（主に外部帳票）のシステム印字項目等をまとめている。内部帳票は基本的にEUC機能等を活用し作成することとするため、帳票詳細要件及び帳票レイアウトは定めない。

② 帳票詳細要件に定義されたシステム印字項目は項目単位の類型に従うこととし、編集条件等は定義すべき内容のみを記載している。

③ 帳票における「第１章 ３（１）標準化範囲内の類型」（実装類型）の取扱いは次のとおりである。

・帳票自体の出力における実装類型は、「１．機能・帳票要件」のとおりである。

・帳票詳細要件のシステム印字項目で項目単位における類型の取扱いは次のとおりである。

表3-12　帳票詳細要件における類型の取扱い

④ システム印字項目の編集方法は、次のとおりである。なお、項目固有に編集方法を定義する場合は、帳票詳細要件の「印字編集条件など」で示す。

表3-13　システム印字項目の編集方法

⑤ 窓空宛名部分の場所や大きさ、窓空宛名を含む帳票に対応した封筒レイアウトは、全庁的に統一したほうがよいため、住民記録システム標準仕様書に準拠する。

⑥ 帳票に印字する文字フォントは、データ要件・連携要件標準仕様書（総論）に準拠する。

⑦ 帳票に印字する文字サイズは、帳票タイトルを14ポイント、他の項目は10.5ポイントを基本とすること。帳票によっては所定枚数に収める必要がある等の理由により教示文等の項目の文字サイズの縮小が必要な個所は7ポイントを最小とする。

⑧ システムから印字する各項目の文字数は、デジタル庁で定めるデータ要件のデータ項目の桁数が最大となる。機能・帳票要件に個別に定める場合を除き、⑦に定める文字サイズでは印字枠に収まらない文字数の場合は、印字枠に収まるように文字サイズを縮小や改行をして印字すること。