第３章　機能・帳票要件

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

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

１．機能・帳票要件

「（別紙１）機能・帳票要件」で、次に示す事業の機能・帳票要件の具体的な要件についてまとめている。

１．共通

２．被保険者資格

３．保険料賦課

４．保険料収納

５．滞納管理

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

（１）管理項目について

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

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

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

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

（６）統合収滞納管理システムとの連携について

（７）統合収納・統合滞納管理機能の導入パターンについて

（８）多様な収納方法への対応について

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

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

（１１）健康管理事業の取り扱いについて

（１２）指定都市要件の実装類型について

（１）管理項目について

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

参照・表示のみを目的とした項目は、参照要件、表示要件として、管理項目には記載しない。参照・表示要件について網羅的に記載することは行っていない。

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

なお、固有の要件があり、他システム連携で取得した情報であっても、後期高齢支援システムで保持・修正を行う場合は管理項目となる。

例）年額保険料については、原則、広域標準システムで決定されているものであり、修正することはない。ただし、広域連合で保険料の更正が発生することが判明している場合にデータ連携の前に更正後の保険料年額を反映し、再度期割を行いたい等の要件がある場合は、当該項目は例外的に管理項目とする。

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

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

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

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

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

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

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

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

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

一覧の確認機能とEUC機能は一部機能として重複する部分があるが、運用上最低限必要となる業務固有の一覧確認要件は「○○を一覧で確認できること」と明記している。その上で、その他の要件に関しては、EUC機能で対応する形で整理する。ただし、業務固有の一覧確認要件もEUC機能による対応でも問題はない（EUC機能で業務固有の一覧確認要件を満たせればよい）。

なお、EUC機能の要件については、デジタル庁の規定する共通要件の中で定められたものを基本的には記載しているが、当該要件で不足すると考えられるものを補記している。

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

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

基幹系業務との他システム連携機能において、後期高齢用宛名情報／税務情報等の情報については、後期高齢支援システム内での保持・不保持のいずれであっても機能上の影響はないと考えられる。そのため、どの方式（主に次の図のパターン）での実装も可能として定義している。連携方式については次に示す資料を参照することとする。

• 「地方公共団体情報システム標準化基本方針」

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

（６）統合収滞納管理システムとの連携機能について

統合収滞納管理システム（全庁的に行う収納管理及び滞納管理を行うためのシステムをいう。）と、個別収滞納管理機能（後期高齢支援システムの標準仕様書において規定している収納管理及び滞納管理を実現するための機能をいう。）との関係については、次に示す資料を参照することとする。

• 「地方公共団体情報システム共通機能標準仕様書」

また、機能・帳票要件に「他システムを参照し利用している場合、登録・修正の処理は対象外。」等と注釈を記載している機能は、保険料収納の情報を広域標準システムに連携する必要がある機能等について記載しているものであり、統合収滞納管理システムの機能として実装可能な機能を示すものではない。

（７）統合収納・統合滞納管理機能の導入パターンについて

統合収納・統合滞納管理機能について後期高齢支援システムの標準仕様書において規定する機能・帳票要件等は、以下の導入パターンのうち、「対象」列が「対象」となっているものを前提として機能・帳票要件等を規定している。

表3-2　統合収納・統合滞納管理機能の導入パターン

これにより統合収納管理機能のみの導入を禁止するものではないが、機能・帳票要件上、当該運用を前提とした記載が行われてないことについては留意されたい。

上記の導入パターンNo.2、No.3についてそれぞれのパターンごとに、機能・帳票要件を規定する上で各インタフェースの要否について整理している。整理した結果については、参考資料として本仕様書の「付録 １．導入パターンごとの連携インタフェース」に示す。

（８）多様な収納方法への対応について

保険料の納付方法には、口座振替のみならず、コンビニ収納や、クレジットカード払い、請求書払いといわれるスマートフォンのアプリを使用して支払う方法など、複数の方法が存在している。現状、これらの収納消込データは、「収納代行業者」ごとに連携されるインタフェースの仕様が異なっており、統一が図られていない状況にある。

ペイジーを利用する場合は、共同利用センターで、決済ごとの消込データを統合するサービスがあるが、これもあくまでマルチペイメントネットワークサービスを活用することが前提となる。

これを踏まえ、eLTAX以外の収納機関から連携される各種収納データを収納消込が可能となる形に成型する処理については、収納機関ごとの統一標準がないことから「標準化の対象外」とする。利用するシステムにおいて活用する収納代行業者との連携インタフェースに改変が必要な場合、その改変を適宜実施いただくことは可能である。

図3-6　多様な収納方法を利用する場合の標準化範囲のイメージ

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

帳票要件として定義する帳票は外部帳票とする。担当主管課内の確認用等の内部帳票は、機能要件におけるEUC機能等を活用することとし、帳票要件としてレイアウト等は原則定めないものとする。

なお、外部帳票と内部帳票の定義は次のとおりである。

図3-7　外部帳票と内部帳票の考え方

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

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

表3-3　矛盾の分類

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

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

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

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

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

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

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

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

（１１）健康管理事業の取り扱いについて

　現在、機能・帳票要件においては、健康管理事業に関しての機能として機能ID:250499及び250504において以下の要件を規定している。

　・健康管理システム及び特定健診等システムに、後期高齢者医療保険情報（異動情報を含む）を、提供できること。

　この内容は、健康管理システム及び特定健診等システムにおいて当該情報を取り込みし、健康管理システム及び特定健診等システムで利用する要件が規定されていることを受けて機能・帳票要件として規定している。

　健康管理事業について、市区町村にて実施する事業は以下のような事業に分類されるが、その事業をどの所管課がどのシステムを活用して実施しているかは市区町村により異なっており、事業の実施内容とシステムが1対1となっていない。

そのため、以下の条件において標準仕様書（※）の記載有無に関わらず、継続して現在利用しているシステムで実装されている機能を利用することを許容するものとする。

期間：本事業についていずれかの標準準拠システムに実装されるまでの間

業務要件の範囲：健康増進法及び高齢者の医療の確保に関する法律に規定される業務並びに健康管理システム標準仕様書の市区町村拡張事業として規定されている業務範囲

条件：現行の後期高齢システムで既に業務を実現するための要件が実装されている場合

（※）後期高齢支援システム、健康管理システム及び特定健診等システムの標準仕様書

（１２）指定都市要件の実装類型について

　一般市と指定都市の実装区分は原則としては同一でありこれらを区別するものではないが、政令指定都市向け機能要件について整理を行った結果、指定都市要件において指定都市として実装必須となる機能を識別するための欄を設けている。

図3-8　機能・帳票要件の指定都市実装類型欄

指定都市の場合のみ実装必須機能となる機能については、「指定都市必須機能」欄に必須機能であることを示す。記載のない機能については、一般市の実装類型に従うものとする。

２．帳票詳細要件・帳票レイアウト

２．１．帳票詳細要件・帳票レイアウトの記載内容について

帳票詳細要件では、原則として「１（９）外部帳票と内部帳票について」にて示した外部帳票を対象とし、「（別紙２）帳票詳細要件」で、機能・帳票要件で定義した帳票におけるシステムからの印字項目等をまとめている。また、「（別紙３）帳票レイアウト」で、帳票詳細要件として定義した帳票の様式（レイアウト）をまとめている。

なお、システムからの印字項目（以下「システム印字項目」という）とは、業務システムにて対象情報により編集し印字する項目のことをいい、固定文言等の帳票レイアウトに直接設定されている項目は含まない。

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

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

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

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

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

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

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

なお、出力領域としては実装必須であっても、その領域の中で特定の項目について、標準オプションとして規定している場合は、該当項目を水色としている。

例）宛名の出力領域自体は必須だが、その項目（住所、氏名等）の中で「対象者を特定できる任意の番号」は実装必須とせず、標準オプションとする場合等

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

図3-9　システム印字項目の編集方法

5. 帳票については、カスタマイズの発生を抑止するために「文言マスタ」という概念を用いて作成することを前提としている。「文言マスタ」とは、帳票上は固定の文言を表記せず、値が出力される領域として規定し、ユーザが「文言マスタ」を編集することで、その登録した内容が帳票に反映される機能等のことを指す。 そのため、帳票レイアウトを参照しただけでは、その帳票にどのような文言が出力されるのか判別できない場合がある。

これについては、帳票詳細要件の編集欄に記載している（印字例）の記載内容を参照することで、想定している出力内容が確認できるようにしている。

なお、「印字例」については、あくまで内容をイメージしやすいように作成しているものであり、このとおり印字しなければいけないものではない（初期設定値として想定されるものであり、文言マスタの機能により変更を可能とするものである）。

また、文言マスタに設定する文言について、帳票詳細要件上に記載のないパターンで文言の設定を細分化するようなケースは、標準化対象の範囲外での対応（外付けシステム等での細分化等）を実施する。

（例：１つの通知書において設定する文言マスタは１つの文言設定が可能と規定されているような場合に、特徴者のみに別の文言を設定するなど条件設定を細分化するなど行う場合）

タイトル１や案内文２など具体的出力内容が表されていないものは文言マスタで規定された文言が出るエリアとなる。

システム印字項目で、帳票レイアウトに記載がないと印字場所が特定できない項目は、□で囲んで明示する。

図3-10　帳票レイアウトと文言マスタの関係

6. 帳票の宛名領域（窓あき宛名とレイアウト上は記載）のサイズは、住民記録システム標準仕様書で提示されている次のサイズ等に準じることとするが、長６封筒、長３封筒、洋０封筒は、窓あき位置が同じであり、どの封筒を使用するかは各自治体において選択できるものとする。また、窓あき箇所が複数ある封筒や窓あきのない封筒等、次に示す封筒以外を利用することも差し支えない。

また、帳票レイアウトに標準オプションで規定している二次元コード等を活用する場合は、現在の規定の窓あき宛名サイズでは、宛名の領域と二次元コードの印字領域を確保することができない場合がある。このようなケースで異なるサイズの窓あき封筒を使用することを本標準仕様書は妨げるものではない。

郵便還付先を帳票レイアウトに設ける場合、以下に示す左の余白を確保するともう1つの窓あき部分を作成できない場合がある。郵便還付先は全ての自治体において使用するものではないことから標準オプションとしているが使用する場合、余白の位置調整等についても適宜変更を行うことを想定している。

図3-11　住民記録システム標準仕様における宛名の位置

なお、次に示す広域標準システムにおける帳票の設計基準では、上記で規定されているサイズとは窓あき封筒の位置やサイズの規定が異なっている個所がある（主に紙の端からのサイズが異なる）。

そのため、市区町村で使用する通知書等と広域連合から市区町村分割された市区町村用に連携される通知書等では宛名印字の位置が異なることになる。封筒を作成する場合は、これらの差を考慮して作成する必要がある。

図3-12　広域標準システムにおける宛名の位置

7. 視覚障がい者等への対応において帳票に個別に点字の印字、音声コードの印字及びその位置を表すための切り欠き加工等を実施することが想定される。これらの対応については、標準準拠システムのアプリケーションで実施するものではなく、印刷の外部委託等により実現されるものであることから、本仕様書内において帳票レイアウト上、当該内容をお示しする等の対応は行っていない。上記のような対応については仕様書に規定がないことによりその実施を妨げるものではない。

8. 帳票レイアウトについてはその印刷内容の量の関係上、1枚ではレイアウトが完結せず、2枚目以降に印刷内容が渡るものがある。これらについては、帳票詳細要件上、「次紙」と記載しているが印刷が2枚に渡ったときに「両面印刷」してはならないことを示すものではない。地方自治体において導入されているプリンタにおいては「両面印刷」が行えないものもあるため、基本的には2枚目が出るような表現としているが、これについても標準準拠システムの機能によるものではなく、印刷時に片面印刷するか、両面印刷するかを判断することになるため、「両面印刷」実施については、各自治体の判断で実施いただくことを想定している。

9. 一体型様式について

複数帳票を特定の用紙にまとめる一体型の様式について、定型用紙については標準仕様として規定を行っている。定型用紙以外のハガキ様式・納付書等との一体型への対応については、自治体から意見のあった様式については規定を行っているが、専用紙での印刷となることから標準準拠システムのアプリケーションで印刷せずに印刷の外部委託等により実現されるものである。外部印刷においては標準準拠システム外での対応となることからその実施を仕様書に規定がないことにより妨げるものではない。

10. 連帳様式について

標準仕様書の規定するレイアウト以外に基本的に連帳様式を使用することはない。ただし、納入通知書と納付書の組み合わせにおいては以下の考え方にて実現することを可能とする。なお、標準化の考え方において帳票については原則定型用紙を用いることとし、必然性がある場合に専用紙やハガキを用いることとしていることから、専用のレイアウトを標準仕様書として規定することは行わない。

• 納入通知書のレイアウトについては既に規定されているものの並び、位置を変更することなく複数枚に印字を分割して印刷することとする。

• 連帳とする際に使用する納付書の様式は「連帳納付書１（カク公）」又は「連帳納付書２（マル公）」を用いるものとする。

• 連帳様式を使用する際には、帳票の罫線を印字しないようにするなどの対応が必要となることから調達時に連帳様式とすることを明記の上、印字データをもとに作成するのか、PDFまで作成が必要なのかを明確に自治体にて規定した上で要件をベンダに提示すること。

11. 帳票へ印字する文字のサイズ及び文字数については、市区町村毎に外国人の氏名の表記方法や取扱いに差異があることから、特段の定めはしないこととする。ただし、どのような文字サイズとしても文字切れが生じるケースは想定されるため、文字切れが生じた場合の挙動として、機能・帳票要件にそれぞれ以下を記載している。

・機能ID「250080」：文字切れ時のエラーリスト出力に関する機能を規定

・機能ID「250322」：文字切れした項目の帳票印字に関する取扱いを規定

12. 帳票へ印字する文字のフォントについては、氏名等の印字については、デジタル庁においてIPAmj明朝フォントを使用することが規定されているがその他の文言を印字する際には使用するフォントや大きさが規定されているわけではないため、レイアウトの改変を伴わない範囲でベンダによる実装の創意工夫の範囲とする。また、同様に外部印刷業者に委託する場合においては標準準拠システムのアプリケーションにおける改修の範囲外の要件となるためその実施を妨げるものではない。

13. 二次元コード等の活用について

返送管理や業者委託時の管理用途として宛名領域において二次元コードの配置をレイアウト上規定している。（バーコードについては位置規定はなし。後述参照。）本二次元コード等の取り扱いについては以下の考え方としている。

• 二次元コード等の規格はISO(ISO/IEC 18004)」又は「JIS(JIS X 0510)」に限ることとする。用途は委託する業者などにより種々想定されるため、特定の用途を規定はしない。

• 二次元コード等の生成自体は、通常、帳票印刷用ソフトウェアの機能範囲で実現されるもののため、標準準拠システムのアプリケーションとして二次元コード等の生成機能自体を規定はしない。

• 二次元コード等の生成要件については、通常帳票を印刷するためのデータファイルの中に設定されている値（例：被保険者番号等）を活用して生成することが想定される。そのため、二次元コード等を生成するためのデータを作成する機能要件を個別に規定することはしていない。通常、帳票印刷する項目以外の値を個別に設定する必要がある場合、標準化対象の範囲外とし、外部委託印刷業者に引き渡すためのファイル整形を行う外付けの処理で実現されることを想定している。

• 印字した二次元コード等を読み込んで入力補助を行う機能要件について二次元コード等の読み込みは外部接続機器で実現されるものであり、また、その機器は一般的にはキーボードによる入力の代替物であることからこれらの読み込み機能について機能要件として規定はしない。読み込み⇒登録を円滑に行うための機能は画面要件の一環であり、ベンダの創意工夫の範囲とする。

• なお、「二次元コード等」にはバーコードも含む。バーコードの場合、レイアウトで示している二次元コードの位置では印字領域が補えないため適宜宛名の窓サイズを変更するなどしてレイアウト調整を実施することを想定している。

14. 罫線のシステム印字について

罫線のシステム印字については、一般的に白紙の用紙に印刷する場合においては通常、出力されることが期待される一方、専用紙等で色つきの紙を使用する場合や、ユニバーサルデザイン帳票等を使用する場合は罫線をシステムとして出力する印字が不要となるケースがある。これを踏まえて罫線のシステム印字については以下の考え方で取り扱うものとする。

１） 帳票データをPDFに出力する場合、罫線は出力する前提で提供するものとし、A4、A3用紙については原則、印刷される罫線を使用すること。

２） １）の例外として専用紙、ハガキ、ユニバーサルデザイン帳票等特殊な印刷を要件とする様式においては、以下のいずれかとする。

• １）と同様にあらかじめ印刷されている罫線を使用する。

• 実装必須機能として提供される印刷データを用いて外部委託業者に印刷を依頼する。

• 提供された帳票定義に対し、罫線を取り除いた帳票定義を利用する。

なお、罫線を取り除く作業自体は帳票のカスタマイズに該当するとせず、自治体においては調達時にどの帳票を罫線不要とするか明示の上、調達するものとする。

15. 納付書の様式について

• カク公／マル公いずれも選択可能な納付書の様式について「参考」として、本仕様書の帳票レイアウトに示すこととする。

• カク公／マル公のマークについて、配置位置の参考として本仕様書の帳票レイアウトに示している。また、ゆうちょ銀行の取扱いが必要な場合、規格に応じて余白等の調整を行った上で使用することとする。

• ペイジーマークについては、ペイジーを導入済みの地方団体のみが使用できる。使用する際は、MPN標準帳票ガイドライン等の仕様書に沿う必要がある。

• 二次元コードについては地方税統一QRコード又はJPQRのどちらかを使用できる。使用する際は、各種仕様書に沿う必要がある。また、地方税統一QRコードを出力する際は二次元コード等と別に「eL-QR」文言を出力する。

• OCRの誤読を防止するため、印字される項目名、枠等をプレ印字しておく必要があり、帳票レイアウトを示した上で、各市区町村において希望する様式を選択し、用紙の作成を実施することを想定している。

２．２．帳票レイアウトのユニバーサルデザイン対応について

標準仕様書については原則、標準準拠システムから帳票が出力されることを想定している。ただし、外部印刷委託業者などを活用して帳票のデザインについてユニバーサルデザイン対応を採用しているケースを勘案し、ユニバーサルデザインを考慮した帳票レイアウトもサンプルで提供している。これらの考え方や帳票の取り扱いについては、参考資料「後期高齢支援システム　帳票デザイン基本方針書」に記載を行っている。